What is 'eCall' ? In other words, you may ask 'what does the letter 'e' stands for ? Does it mean 'emergency' ? or 'electronic' ? or something else ?
Even though I haven't seen any formal documents that explicitely defines the letter 'e' in eCall, I think it would not be wrong if you say the 'e' mean 'emergency', i.e, 'eCall' would mean 'emergency Call'. But this interpretation would confuse a lot of people. Then, how does eCall differ from what we normally call 'Emergency Call (like 911)' ?
I will explain on the details of this difference later, but simply put, the biggest difference would be the usual 'Emergency call' is a kind of voice call between a human and Emergency Call Center (usually another person in Emergency Call Center)' but 'eCall' is a call between a machine (called IVS : In Vehicle System within an automobile) and Emergency Center;.
For the persons who likes formal definition, I would quote some descriptions from a couple of international standards as follows :
ETSI 103.428 defines eCall as follows :
eCall is a manually or automatically initiated emergency call, (TS12 : teleServiceCode 12) from a vehicle, supplemented with a minimum set of emergency related data (MSD), as defined under the EU Commission's eSafety initiative
ETSI TS 126.267 describes as follows :
eCall provides reliable full-duplex data communications between IVS and PSAP in addition to emergency voice call (E112) via the cellular network, and can be initiated either automatically or manually. The eCall In-band Modem uses the same voice channel as used for the emergency voice call. eCall allows reliable transmission of MSD alternating with a speech conversation through the existing voice communication paths in cellular mobile phone systems. The expected benefit is that emergency services will be made aware of accidents much more rapidly, will get precise information on location, vehicle type etc. and therefore will be able to reach accident victims faster, with the potential to save many lives annually.
Followings are the topics to be covered in this page.
Before we talk of the technical details of eCall, let's take a 10000-feet overview (high level view) on how eCall go through. You may find a lot of illustrations, cartoons on eCall from internet and following is my own version of illustration. I put the number labels on each of the steps and I would put a short descriptions on what's happening at each step.
(1) A Car Accident (e.g, Crash) happens
(2) eCall is triggered. eCall can be triggered in many ways. It can be triggered automatically by Air Bag or internal sensors. Or a person (e.g, driver) in the car can push the emergency button in the car to trigger the eCall.
(3) The eCall device installed in the car (called IVS : In-Vehicle System) go through Emergency Voice Call setup process to establish the voice call channel. Once the voice call channel is established, the IVS send eCall Data (MSD : Minimal Set of Data) to PSAP (Public Safety Answering Point)
(4) Once the eCall Data(MSD) is received by PSAP, the information would show up automatically on the screen at PSAP center.
(5) The personnel at PSAP center may try voice contact to the person in the car if possible. But there would be many cases where this is not possible when person in the car is injured badly.
For those who came from Cellular protocol and new to eCall, it would be a little confusing on figuring out the difference between eCall and another type of Emergency Call (like 911 in North America) which we are familiar with in daily life. For those people, I think it would be easier / clearer to explain the difference in terms of overall protocol sequence. Following is my understanding (the image formed in my brain when I first got trained about this).
As you see here in the following illustration, there is common portions and different portions between eCall and Emergency Call.
NOTE : IVS stands for In-Vehicle System. It is the eCall / Cellular module that are installed within Car (within Telematics module in most case). In terms of testing, this is a DUT
eCall Higher Layer Application Protocol (HLAP) is very simple (at least comparting to Cellular Protocol). Actually there is only one critical data to be transferred. The critical data is called MSD(Minimal Set of Data). All the remaining part is just to get MSD delivered to PSAP (Emergency Call Center) with reliability.
As in Cellular Voice Call, in HLAP there are two different type of call mode depending on who (IVS or PSAP) initiates call. The eCall initiated by IVS is called 'PUSH mode' and this is similar concept as MO(Mobile Originating) call in cellular voice call.
The eCall initiated by PSAP is called 'PULL mode' and this is similar concept as MT(Mobile Terminating) call in cellular voice call.
The two illustrations in this section is based on ETSI 103.428 Figure 2. The ETSI diagram is a single diagram showing both PUSH and PULL mode in single sequence. It looked a little confusing to me, so I split the digram into two separate diagram as shown below.
NOTE 1 : IVS stands for In-Vehicle System. It is the eCall / Cellular module that are installed within Car (within Telematics module in most case). In terms of testing, this is a DUT
NOTE 2 : PSAP stands for Public Safety Answering Point. This is a kind of Emergency Call Center.
PSAP PUSH Mode Call is like MO call in celluar terminology. This is the call initiated by IVS (the mobile unit installed inside the car). I think in most case of eCall, the eCall goes in PUSH mode as illustrated below.
PSAP PUSH Mode Call is like MT call in celluar terminology. This is the call initiated by PSAP (the call center). If you compare this with PUSH mode sequence, you would notice that most of the part are same. The only difference is the SEND-MSD (START) signal before the Initiation signal. This is also very much like cellular protocol. If you compare the MO Call and MT Call sequence in cellular protocol, you would notice that most part of the two are almost same. The main difference is that in MT Call the cellular network send 'Paging' (a kind of trigger for UE to initiate the call).
Another sequence that illustrate the eCall process with a little low layer point of view (especially in terms of LL/HL ACK operation) is shown below. This applies to both PUSH and PULL model.
< ETSI TR 126.969 - Figure 1: Timeline of eCall with IVS initiated signalling and HL-ACK in normal operation >
There are various timers in eCall protocol which should be met in order to guarantee the normal functionality of the eCall. Some of these timers are an important criterial of testing eCall functionality.
As mentioned above, the only one fundamental goal for eCall is to deliver MSD(Minimal Set of Data) with reliability. Then you may ask what kind of information is in the MSD. High level description of the imformation in MSD can be find from following description. As you see, the most important information in the MSD is the location data and vehicle information.
ETSI TS 126.267 4.1 eCall system overview describes as follows :
The eCall modem allows to transfer a data message from the IVS over the cellular network to the PSAP which is denoted as eCall MSD. The MSD can include, e.g. vehicle location information, time stamp, number of passengers, Vehicle Identification Number (VIN), and other relevant accident information
ETSI TS 126.267 3.1 Definitions describes as follows :
The Minimum Set of Data forming the data component of an eCall sent from a vehicle to a Public Safety Answering Point or other designated emergency call centre. The MSD has a maximum size of 140 bytes and includes, for example, vehicle identity, location information and time-stamp.
One example of the set of information carried by a MSD is shown below.
Before we think of this, let's think of why we need to care of this. We should care of this because eCall signaling message and data are delivered in the form of Voice call data of GSM or WCDMA cellular network.
In GSM / WCDMA, various different types of codecs are used. Basically the codec selection is a job for the specific Radio Access Network equipment(RAN Equipment) that is communicating with the eCall device. The RAN Equipment (Network) would select the codec that would give the best performance in a specific situation. 'Performance' mean 'How fast the eCall data can be delivered' and 'How reliably it can be delivered under a specific channel condition'. It would be too much (or too boring) to present the full details on these performance here. If you are really interested in the details, refer to ETSI TR 126.969 and it would give you a lot of test data for various different Codecs.
Now let's think of how to test eCall functionality.
In theory, you can use a live network and PSAP Simulator to test your eCall Device (IVS). But theory is just a theory. You would come across a lot of issues to overcome if you go for this option even though I cannot say it is impossible.
Another way of testing the eCall device is to construct test setup as described in ETSI 103.428 section 6 Test Configurations. In this document, it is described to use a private cellular network for various Interoperability and Conformance Testing.
The most practical solution (Test setup) that will be used in the industry would be to use Cellular Network Simulator and PSAP simulator as illustrated below.
Assuming that you have a test setup and you need to determine what to test. As in most of other wireless and cellular device device, you may think of general test that tend to happen during the development or system integration stage. We often call these test in various different name such as function test, integration test or smoke test etc. Usually test specification / procedure tend not to be clearly defined or the procedure changes often depending on situations. Also those test procedure / test item may vary depending on manufacturer. Therefore, it would not be easy to clearly define on what to test for this stage. However, if you just take a close look at the overall eCall protocol, you would easily guess high level test items even without looking into any specification. My personal version of the guess work about the first level test are shown below. You may come up with different idea, but I don't think there would be any big difference between your idea and my idea.
Once you complete the general function test during development and system integration level and have a stable device, you would forward the device to conformance test. Once you are at the stage of conformance test, you don't have to worry about what to test because a lot of other people (standard body) put a lot of effort and energy and came out with well defined document. In 3GPP/ETSI, those test procedures are defined in ETSI TS 103.428.
After completing the conformance, if you are trying to sell the device (acutually Automakers trying to sell cars) in a specific region (e.g, Europe, Asia, America etc), you may need to go through a specific set of test cases specified by the regulatory body in that specific region.
Followings are the examples of how eCall is being testing during the development or for conformance test before commercialization.
Followings are the list of the specifications for eCall. I think the most fundamental specifications are CEN documents. But it is not free to get those spec. Recently 3GPP / ETSI has released various specifications. I think most part of the 3GPP specification are based on CEN specification.