Portal de Periódicos da CAPES

Interoperability of eCall and ERA‐GLONASS in‐vehicle emergency call systems

2015; Institution of Engineering and Technology; Volume: 9; Issue: 6 Linguagem: Inglês

10.1049/iet-its.2014.0209

1751-9578

Risto Öörni, Evgeni Meilikhov, Timo Korhonen,

Transportation Systems and Safety

IET Intelligent Transport SystemsVolume 9, Issue 6 p. 582-590 Special Issue: Highlights from the ITS Europe Congress in Helsinki (2014)Open Access Interoperability of eCall and ERA-GLONASS in-vehicle emergency call systems Risto Öörni, Corresponding Author Risto Öörni [email protected] VTT Technical Research Centre of Finland, P.O. Box 1000, FI-02044 VTT, FinlandSearch for more papers by this authorEvgeni Meilikhov, Evgeni Meilikhov Non-for-profit Partnership for Development and Use of Navigation Technologies (Glonass Union), Office 1508, World Trade Center, 12 Krasnopresnenskaya nab., Moscow, 127083 RussiaSearch for more papers by this authorTimo Olavi Korhonen, Timo Olavi Korhonen Department of Social Research, Helsinki University, P.O. Box 54, FI-00014 Helsinki, FinlandSearch for more papers by this author Risto Öörni, Corresponding Author Risto Öörni [email protected] VTT Technical Research Centre of Finland, P.O. Box 1000, FI-02044 VTT, FinlandSearch for more papers by this authorEvgeni Meilikhov, Evgeni Meilikhov Non-for-profit Partnership for Development and Use of Navigation Technologies (Glonass Union), Office 1508, World Trade Center, 12 Krasnopresnenskaya nab., Moscow, 127083 RussiaSearch for more papers by this authorTimo Olavi Korhonen, Timo Olavi Korhonen Department of Social Research, Helsinki University, P.O. Box 54, FI-00014 Helsinki, FinlandSearch for more papers by this author First published: 01 August 2015 https://doi.org/10.1049/iet-its.2014.0209Citations: 6AboutSectionsPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onFacebookTwitterLinkedInRedditWechat Abstract The objective of this study is to analyse the interoperability between pan-European eCall and Russian ERA-GLONASS in-vehicle emergency call systems. The analysis is based on a definition of interoperability from International Telecommunication Union and related system standards of eCall and ERA-GLONASS. The authors results indicate that the core functions of both systems – minimum set of data (MSD) transmission at the start of the call and establishing the related voice connection between vehicle occupants and a public safety answering point – will be available in the interworking scenarios analysed in this study. However, not all features of both systems will be available in use cases with interworking between the systems, such as SMS-based MSD retransmission. The study indicates that further empirical tests are required to obtain more information on practical interoperability between the systems. 1 Introduction 1.1 eCall and ERA-GLONASS eCall [1-4] is a pan-European in-vehicle emergency call system that is expected to be mandatory in new vehicle models type-approved in the EU after October 2015 [5]. In the future, deployment of a public safety answering point (PSAP) infrastructure capable of receiving and processing eCalls will become mandatory for EU member states [6, 7]. An overview of the standards of eCall is given in Fig. 1. Fig. 1Open in figure viewerPowerPoint Overview of standards of pan-European eCall [8] (PLMN: public land mobile network, TPS-eCall: third party services supported eCall) Meanwhile, Russia is developing the ERA-GLONASS system, which also provides in-vehicle emergency call functionality [9-12]. This will be made mandatory in new vehicle types of categories M and N after 1 January 2015 by the Amendment to the Technical Regulation of the Customs Union adopted by the Eurasian Economic Commission on 30 January 2013 [13]. Highlights of the regulation are given elsewhere [14]. Both systems provide an in-vehicle emergency call function, and their deployment has been scheduled to take place almost simultaneously. An overview of the core standards of ERA-GLONASS is given in Fig. 2. Fig. 2Open in figure viewerPowerPoint Overview of core standards of ERA-GLONASS (adapted from [15, 16]) Both systems provide very similar functionalities, and there is a clear need to analyse the interoperability between them. Interoperability would improve access of travellers to emergency services both in the EU and in countries that have decided to implement the ERA-GLONASS system. Notably, it would be important to provide an interoperable in-vehicle emergency call service for users of eCall in Russia and users of ERA-GLONASS in Finland. The ability to make an in-vehicle emergency call is a safety feature that in some cases could be vitally important. It should be available during all types of trips independently of the user's physical location, as with emergency call services based on a general emergency number (112 in the EU). Interoperability of eCall and ERA-GLONASS is especially important for users travelling abroad because of language difficulties and challenges in expressing one's location accurately in unfamiliar environments. 1.2 Interoperability There are several definitions for interoperability in the context of data communications [17] and computing [18]. International Telecommunication Union (ITU) recommendation Y.101 [19] defines interoperability as: 'The ability of two or more systems or applications to exchange information and to mutually use the information that has been exchanged.' The European Telecommunications Standards Institute (ETSI) white paper on interoperability [17] presents three alternate definitions for interoperability. One of them that we apply in this paper is used by the 3rd Generation Partnership Project. It is essentially similar to the ITU definition and refers to 'the ability of two or more systems or components to exchange data and use information'. In the case of pan-European eCall realisation and ERA-GLONASS, important questions of interoperability relate to the quality of the joint service. The ETSI white paper on interoperability [17] describes briefly the different levels of interoperability: technical, syntactical, semantic and organisational (Fig. 3). Fig. 3Open in figure viewerPowerPoint Levels of interoperability [17] Technical interoperability allows the transmission of bits from one communicating entity to another, and is usually related to software and hardware components and to communication protocols [17]. Syntactical interoperability is associated with data formats and encoding of information, whereas semantic interoperability covers the meaning of the content being transmitted [17]. Organisational interoperability is 'the ability of organisations to effectively communicate and transfer (meaningful) data (information) …' [17]. In case of in-vehicle emergency call services such as eCall or ERA-GLONASS, technical interoperability covers aspects such as call establishment, transmission and retransmission of data, call cleardown and opening of a call from PSAP to in-vehicle system (IVS) (call-back). Syntactical interoperability covers the coding and decoding of the minimum set of data (MSD). Semantic interoperability is mostly related to human interpretation of information received as MSD or via voice connection. Organisational interoperability can be understood as the capability of vehicle occupants and the PSAP to communicate efficiently and in a coordinated manner, and will include aspects such as call handling practices of PSAPs and user behaviour. The primary focus of this paper is on technical interoperability, and aspects related to syntactical interoperability are discussed as they are closely related to technical interoperability. The other layers are related mainly to human factors and organisational aspects of the service, and are therefore outside the scope of this paper with its main focus on technology. 1.3 State machines, state diagrams and sequence diagrams Communication protocols can be seen as mechanisms that transfer information and propagate the system state between communicating entities. It would have been possible to describe eCall and ERA-GLONASS elements of the interworking use cases as finite state machines such as Mealy machines. For example, a modelling of eCall with state diagrams can be found in CEN technical specification (TS) 16454 [20], which describes conformance test points for eCall. State machines described with state diagrams are most suitable for describing the internal states and state transitions of the communicating entities, but they are less practical for visualising messages or data flows exchanged between systems. Systematic description of eCall and ERA-GLONASS as finite state machines would require describing a large number of states. This is seen in CEN TS 16454, where the conformance test points for pan-European eCall are described as transitions between the states possible for the system. Any attempt to accurately describe both systems and their states with state machines could therefore lead to overspecification. If two entities communicate using the same communication protocol, it may be possible to present the operation of both entities with the same state machine diagram. However, this is not the case when the systems have different specifications. Connection state diagrams such as those in RFC793 [21] have been used to describe the operation of communication protocols. Many of the limitations of state machines apply also to connection state diagrams: they are impractical for visualising data flows and messages exchanged between systems. Sequence diagrams can be used to present data flows and messages exchanged between systems. Sequence diagrams have means to present system states, but they are not primarily intended for describing or modelling system states or state transitions. This means that sufficient explanatory text has to be provided when system states are concerned and relevant for interoperability between systems. Tools such as specification and description language (SDL) and unified modelling language (UML) can be used to describe communication protocols and other distributed systems as state machines. SDL has been developed for description and analysis of communication protocols, but it can be used for other kinds of distributed systems [22]. SDL allows modelling of the interactions between entities as sequence diagrams and the statuses of the communicating entities as state machines. UML is mainly intended for analysis, design and implementation of software-based systems, and it can also be used for modelling of business and other similar processes [23]. UML includes a variety of tools such as use cases, sequence diagrams and state machines. A comparison of SDL-2000 and UML 1.3 when applied in a case study is provided elsewhere [24]. 1.4 Structure of this study The introduction provides an overall description of pan-European eCall and Russian ERA-GLONASS in-vehicle emergency call systems analysed in this study, and is followed by the main objectives of this study. The methods section describes the analysis of interoperability between the systems. The section 'Core functions of the systems' discusses the functionalities of eCall and ERA-GLONASS emergency call services. The results of this study are presented as use cases involving interworking between the systems. This study closes with a discussion of the results, conclusions and recommendations for further research. 2 Objectives The objective of this paper is to analyse the interoperability between pan-European eCall and the Russian road accident emergency response system, ERA-GLONASS. The main question is what kind of mutual interoperability can be expected and where potential problems may reside. The focus of the analysis is on typical use cases involving interworking of the two systems: (a) where an eCall IVS (in-vehicle system) interacts with ERA-GLONASS PSAP and (b) where ERA-GLONASS IVS interacts with a PSAP supporting pan-European eCall. Detailed analysis of scenarios involving non-standard implementations of the IVS or PSAP or failures in network registration or call setup are not included here, because of a current lack of respective equipment and in order to focus on standardisation related interoperability issues. The general framework for the analysis is the one presented in the ETSI white paper on interoperability [17]. The main focus of this paper is on telecommunications related technical interoperability between the two systems. We have discussed the interoperability issues relevant to this paper in a paper describing the results of eCall and ERA-GLONASS interoperability tests performed in spring 2012 in Finland [25]. This provided some early results on the interoperability between the two systems. However, many important standardised features of pan-European eCall and ERA-GLONASS such as MSD retransmission requested by a PSAP needed more focus, which we provide here. 3 Methods The analysis of interoperability between the two systems is performed mainly from information available in their core standards (Figs. 1 and 2). This approach was chosen for three reasons. First, the results of theoretical analysis support the planning of empirical pilot tests, where the interoperability of the two systems can be verified and unclear points clarified. Second, full implementations of both systems were not available for empirical testing at the time of writing. Third, it is reasonable to assume that both systems will be implemented according to their own standards. The analysis is based on the framework presented in the ETSI white paper on interoperability [17] and the definition of interoperability as defined in ITU Y.101 [19]. Interoperability between the systems is analysed by referring to the respective protocol stack and sequence diagrams, which are commonly used tools in communications engineering in the design of communication protocols. The analysis is carried out for typical use cases involving interworking between the two systems: an eCall IVS interacting with an ERA-GLONASS PSAP and an ERA-GLONASS IVS interacting with a PSAP supporting pan-European eCall. The results are presented as figures and text indicating what features of both systems are available in each of the cases. Before analysing the interoperability, the core functionalities of both systems are summarised as tables. Several factors had to be taken into account when selecting the analysis approach and the method for presenting the results. First, interworking use cases of eCall and ERA-GLONASS include several interacting telecommunication network layers of the International Organisation for Standardisation (ISO) open systems interconnection model (ISO-OSI model) and are therefore complex. This requires an appropriate level of detail in the analysis, while applying both the analysis and the presentation methods consistently. Second, the results must be presented concisely yet be easily understood by the reader. Third, we wished to focus on the interface between the two interworking systems, and to consider the internal states of the systems only as far as they are relevant to interoperability. For the reasons explained above, the approach based on sequence diagrams was considered most suitable for this paper. 4 Core functions of the systems 4.1 Pan-European eCall The objectives of conformance tests for a PSAP operating according to the standards of pan-European eCall are defined in EN16062. These objectives can be used also in the assessment of interoperability between eCall and ERA-GLONASS. The main functionalities of pan-European eCall have been summarised based on the objectives for conformance tests specified in EN16062 and the related conformance testing points. The main functionalities analysed here are summarised in Table 1. Table 1. Core functionalities of pan-European eCall as defined in EN16062 Number Functionality 1 IVS activates the eCall discriminator depending on the type of alarm and opens an emergency call to emergency number 112 2 the mobile network routes the call to the most appropriate PSAP 3 eCall is prioritised in mobile and fixed-line networks such as any 112 emergency call 4 MSD is transmitted using the in-band modem according to ETSI specifications and timer values 5 a voice connection is opened between vehicle occupants and the PSAP 6 the PSAP is able to request MSD retransmission during the voice connection 7 the PSAP is able to receive the MSD and visualise its contents 8 the PSAP is able to clear down the call either by hanging up or sending an AL-ACK (application layer acknowledgment) with cleardown 9 the PSAP is able to call-back the IVS after the eCall has ended Functionality 2 refers to routing of the call to the most appropriate PSAP. The organisation of PSAPs is different in different EU member states. There are also differences in the way eCalls are handled by PSAPs. Therefore the most appropriate PSAP to receive and process eCalls in a given geographical area is defined at member state level. 4.2 ERA-GLONASS The core functionalities of ERA-GLONASS can be summarised on the basis of GOST R 54721 (base service description) and GOST R 54620 (general technical requirements). The core functionalities of ERA-GLONASS are summarised in Table 2. Table 2. Core functionalities of ERA-GLONASS Number Functionality Reference 1 IVS activates the eCall discriminator depending on the type of alarm and opens an emergency call to emergency number 112 GOST R 54620:2011, 7.5.3, 9.1, 2 2 the regional switching node of the ERA-GLONASS service receives the 112 call and receives the emergency message from the vehicle using the in-band-modem. An emergency message from the IVS, accepted by the regional commutation centre, is directed to the relative (according to territory) navigation-information centre of the ERA-GLONASS system (second level navigation information centre), where it is decoded, reformatted and stored in the database with assignment of a unique reference identifier to the message GOST R 54721 3 the operator of the ERA-GLONASS service opens a voice connection between the vehicle and the filtering contact centre of the ERA-GLONASS system to verify that the call needs to be transferred to System 112 [PSAP]. In the case of a legitimate emergency call, a voice connection is established between the vehicle and the System 112 centre [PSAP] GOST R 54721, 5.4.4, 5.4.7 4 once the call for the service is determined as legitimate by the filtering contract centre, the full dataset, supplemented where possible by the operator, is placed in the database of the navigation-information centre to which the call for the service has come. The full dataset is formed on the basis of supplementary information received from the ERA-GLONASS system concerning the road accident GOST R 54721, Annex A, 5.4.6, 5.4.7 the emergency message from the ERA-GLONASS system is formed at the information navigation centre based on the full dataset concerning the road accident, which is considered in a fixed manner and is transmitted to the interactive system 112 call centre, with assignment of a brief reference identifier to the message 5 an emergency call [emergency message from IVS to ERA-GLONASS infrastructure] is transmitted through an IVS built-in in-band tonal modem (ETSI TS 126 267, Release 8), the requirements for which are fixed in GOST R 54620 (Section 8.6) GOST R 54721, 5.2.5 GOST R 54620, 8.6 6 when the MSD fails to be transferred using the tone modem, the IVS transfers the MSD to the system operator sending an SMS to an ECALL_SMS_FALLBACK_NUMBER configured number GOST R 54620:2011, 7.5.3.35 GOST R 54721, 5.2.10 7 when the relevant command is received from the system operator, then the IVS transfers the current MSD to the system operator by sending an SMS. Receipt of the SMS from the system operator is possible after the IVS performs the emergency call within the period during which it is registered in the network GOST R 54620:2011, 7.5.3.36 8 the system operator transmits a command to the IVS to transmit the MSD with the data on the road accident using the tone modem GOST R 54620:2011, Table 7 9 once the connection with the system operator is set (if any external power supply), the dual-tone multi-frequency tone is generated to the dial-up line as follows: corresponding to '0' on the first push of the emergency call button, corresponding to '1' on the second push and corresponding to '2' on the third push. Subsequent pushing of the emergency call button is ignored GOST R 54620:2011, 7.5.3.38 The messages exchanged between the ERA-GLONASS IVS and the ERA-GLONASS back-office system are summarised in Table 7 of GOST R 54620. 5 Use cases involving interworking between the systems 5.1 Pan-European eCall IVS initiating a call to PSAP based on ERA-GLONASS Fig. 4 is a use case sequence diagram in which an IVS complying with the standards of pan-European eCall is activated either automatically or manually and the respective interaction is accomplished with a mobile network supporting ERA-GLONASS and the ERA-GLONASS back-office system. Fig. 4Open in figure viewerPowerPoint Interworking of eCall IVS and the ERA-GLONASS back-office system The figure is based on the text of GOST R 54721 (Chapter 5.4) and standards related to pan-European eCall [1-3]. The current version of the eCall MSD as defined in EN15722 will be replaced with a new version (version 2) [26]. However, the existing standards of ERA-GLONASS describe the current version (version 1) of MSD defined in EN15722:2011 (GOST R 54620-2011, Appendix B). Updating ERA-GLONASS standards is expected to be initiated once EN15722 for MSD version 2 is approved. Owing to the reverse compatibility, a possible interim period should not critically affect interoperability, as long as both MSD versions are supported by the PSAP software. This applies also in the use case in which an ERA-GLONASS IVS initiates a call to a PSAP supporting pan-European eCall. A SIM card is mandatory for an eCall IVS. Therefore the IVS will be able to initiate a TS12 emergency call (Teleservice 12, Emergency Calls [27]) even in cases where emergency calls are not allowed without a SIM card. One should also note that the value of the setting application layer acknowledgement (AL-ACK) period ('ALACKPERIOD') in Table A.1 of GOST R 54620-2011 is 2 s. The value of the corresponding timer for eCall, T6 (IVS wait for AL-ACK period), defined in Annex A of EN16062, is 5 s. This is an interoperability issue, but is not likely to lead to catastrophic consequences. The fact that the ERA-GLONASS back-office system stops transmitting AL-ACKs after 2 s may reduce the probability that the eCall IVS successfully detects an AL-ACK. In practice, an eCall IVS sending an MSD to the ERA-GLONASS back-office system will simply open the voice channel 3 s later than an ERA-GLONASS IVS in cases where a link layer acknowledgment (LL-ACK), but no AL-ACK has been received by the IVS. 5.2 ERA-GLONASS IVS initiating a call to eCall PSAP The use case in which an ERA-GLONASS IVS initiates a call to a PSAP supporting pan-European eCall is illustrated in Fig. 5. Fig. 5Open in figure viewerPowerPoint Interworking of ERA-GLONASS IVS and eCall back-office system An ERA-GLONASS IVS is required to have a SIM card installed and can therefore legally make a TS12 emergency call also in countries that do not allow emergency calls without a SIM card. In the case of pan-European eCall, this has been solved with a requirement that the IVS must have a SIM card installed. The exact SIM profile structure is not relevant to this capability. The need for international roaming is under discussion. A TS12 emergency call can be made even without full roaming capabilities, but the call-back feature will not be available in cases without a roaming agreement. This is a limitation to interoperability, although seldom a critical one. Given the issue with ALACKPERIOD and T6 mentioned above, an ERA-GLONASS IVS sending an MSD to a PSAP conforming to the standards of eCall will simply quit listening for AL-ACK and transfer to voice mode too early. This can result in unreliable or even no detection of AL-ACK at all in situations, in which the IVS has already detected the LL-ACK. Whether an AL-ACK will eventually be detected depends on the configuration of the PSAP, in other words, how many LL-ACKs and AL-ACKs are sent, and the successes and failures of transmissions of individual acknowledgments. 5.3 Call-back from PSAP based on ERA-GLONASS to eCall IVS Sometimes, the PSAP may attempt to obtain further information about the incident after the eCall has already been closed by it, or the call has been disconnected for some other reason, but the IVS has not made a redial attempt as specified by the standards of eCall. Information about the location of the incident may be ambiguous, for example, if the call has been initiated by a passer-by (Good Samaritan calls and calls related to animals or obstacles on the road). In these situations, the PSAP may open a call to the IVS that initiated the emergency call. The requirement that the PSAP should be able to call-back the IVS is part of the functionality of both eCall and ERA-GLONASS. For this reason, the call-back functionality has to be described together with the main use cases analysed in this paper. Operation of the call-back feature in an interworking scenario involving an eCall IVS and ERA-GLONASS back-office system is outlined in Fig. 6. Fig. 6Open in figure viewerPowerPoint High-level description of the operation of call-back functionality in an interworking scenario involving an eCall IVS and ERA-GLONASS back-office system The possibility to make the call-back from an ERA-GLONASS back-office system to an eCall IVS will depend on the existence of a roaming agreement between the mobile network operator that provided the SIM card used in the IVS (mobile network operator (MNO)1) and the mobile network operator serving the IVS in the area where the emergency call was made (MNO2). Let us first focus on the scenario in which there is a roaming agreement between MNO1 and MNO2. When the IVS is powered up, (global system for mobile communications) GSM mobility management is activated and the IVS enters the state 'PLMN SEARCH'. After performing a PLMN search, it enters the state 'ECALL INACTIVE' as defined in chapter 4.2.1.1 of [28], and no location updates are made. The IVS may leave the 'ECALL INACTIVE' state by attempting to establish an emergency call, at which point the GSM mobility management layer moves to the state 'MM-IDLE', and a location update is attempted (chapter 4.4.7 of [29]). As part of the procedure, the home location register (HLR) of MNO1 and visitor location register of MNO2 are updated with the current location of the IVS. A roaming agreement between MNO1 and MNO2 is required for a successful location update. After performing the location update, a circuit-switched emergency call is established with the standard mobility management and connection management procedures of GSM and third generation (3G) networks [28] and related protocols in public switched telephone network [30]. The PSAP receives the mobile subscriber integrated services digital network number (MSISDN number) of the IVS from the mobile switching centre (MSC) as part of the normal call setup procedure as the calling line identification (CLI). CLI presentation (CLIP) is available in second generation (2G) and 3G networks as a supplementary service [31, 32]. The services for which CLIP is applicable in 2G and 3G are defined in Table A.1 of ETSI TS 122 004 [29, 33]. It should be noted that CLIP has not been marked in ETSI TS 122 004 as applicable to emergency calls (TS12, [27]), although it may in fact be supported in real-life implementations of the standards. The interworking of CLIP provided by 2G and 3G networks with fixed-line networks is discussed briefly [31, 32] as follows: 'According to national network specific rules, the CLIP supplementary services need not be applicable, if at least one of the two parties is not an integrated services digital network (ISDN) or PLMN subscriber.' The transmission of CLI in fixed-line networks between the MSC of MNO2 and the PSAP takes place as a normal call setup procedure as defined in ITU Q.731.3 [34] and Q.764 [30]. When the operator of the ERA-GLONASS back-office system attempts to call-back the IVS, it initiates a normal call setup procedure using the ISDN user part protocol [30] to the MSISDN number of the IVS. The call is first connected to the gateway MSC of MNO1. The MSC of MNO1 then performs a lookup in the HLR of MNO1. If the location update performed by the IVS was successful, a voice call between the IVS and the PSAP is established correctly. The situation is completely different if MNO1 (the MNO which provided the SIM card) and MNO2 (the Russian MNO serving the IVS) have no roaming agreement. In this case, there will be no location update from MNO2 to the HLR of MNO1, and the MSC of MNO1 has no means to route the call from the PSAP to MNO2 serving the IVS. The unavailability of call-back in case the location update is not successful is confirmed in a specific note in chapter 4.4.7 of [28]: 'If an eCall device has not successfully completed a location update procedure, PSAP call-back will not be possible because of its calling line identity being unavailable at the PSAP.' 5.4 Call-back from eCall PSAP to ERA-GLONASS IVS The issue with roaming is essentially similar to that in the use case with eCall IVS interacting with an ERA-GLONASS back-office system. In other