13 of 17

Case study 3 – Emergency call

In this case, the goal is to implement an “emergency call” application, to demonstrate transparent, bidirectional IP services based on the open SafeTRIP Platform.

The use case would be as follows: the driver of the vehicle, or a passenger, activates a button on a simple panel, which triggers a call to be established with the pre-configured Public Service Answering Point (PSAP) or Third-Party Service Provider (TPSP) of emergency services. After this first call, the emergency authorities can make a call back to the vehicle to request additional information or obtain a more up-to-date description of the situation.

Figure 21: Emergency Call components

In parallel to the voice call, a Minimum Set of Data (MSD) message is sent to a centralized server, carrying information on the emergency location, type of vehicle, number of occupants, etc.

The following enabling services provided by the SafeTRIP Platform are used in this application:

-     Positioning service – included in the MSD

-     Voice proxy services – used to simplify voice calls and encapsulate VoIP configuration aspects

-     IP gateway – required (as in the messaging case study) to relay data through the satellite or an alternative ground network.

Even though there are data flows of different types between the OBU and the service centre (messages, voice streams, etc.), all of them can be supported in a transparent way on top of the bidirectional communications service provided by the SafeTRIP Platform.

Once the application and the application needs are defined, the developer can define the overall architecture of the system.

As in the case study 1, the application on the OBU can be implemented as a standard web-servlet (see figure above) interacting with the user through the web browser and with the underlying Service Enabling Layer. In this case, the application interacts directly with the positioning service (just as in case study 1), the voice services and the IP Gateway.

Voice services are implemented at both the OBU side and the server side and provide all applications with a simple interface to establish and terminate VoIP calls based on the standard SIP protocol, including straightforward configuration of functionalities such as auto-answering, registration, authentication and accounting. Voice services at the server side also provide capabilities to route calls not only to other VoIP endpoints but also to the public switched telephone network.

On a lower level, the IP Gateway ensures that application (and middleware) data is delivered to the server side, no matter which network is available at any given time: either the satellite link or an alternative ground network. As in the case study 1, the decision to choose one network over another is left to the IP Gateway.

Applications can transmit various types of traffic flows, e.g. from SIP/RTP sessions all the way to MSD messages, over this IP layer without having to deal with the different networks. This allows existing applications to be adapted to the SafeTRIP Platform without major changes.

This transparent IP Gateway also enables straightforward testing of applications. Developers can test their applications over UMTS links, and then deploy them on an OBU equipped with satellite communications terminals for better coverage and higher availability/performance through redundant links.

13 of 17

SAFETRIP.eu is a project co-funded by the European Commission, DG Research

© Copyright 2012 SafeTRIP