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.

NOTE : eCall has first started and deployed in 2G/3G era, but as all 2G/3G voice call has been evolved into packet call (IMS), eCall has been evolved to IMS call as well in later 3GPP specification (Release 14). For general introduction for IMS based eCall, check out this blog. For further details, check out this note.

This page follows one eCall from the crash to the PSAP screen. It first compares eCall with a normal emergency call and shows how the IVS marks the call as an eCall. It then explains the HLAP exchange inside the voice channel, its timers, the MSD and the in-band modem. The last part covers testing and eCall over IMS.

Followings are the topics to be covered in this page.

• Overall eCall Process
• Difference Between Emergency Call and eCall
• How does the network know that a CS call is an eCall ?
• Higher Layer Application Protocol - HLAP
• PSAP PUSH Mode
• PSAP PULL Mode
• LL/HL ACK Operation
• Timers in eCall
• What kind of information is transferred during eCall ?
• Which Voice Call Codec to use ?
• How to test eCall ?
• What to test ?
• Test Examples
• Specification List
• IMS based eCall
• Which one to choose from ? CS or PS - IMS ?
• Reference

Overall eCall Process

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.

Overall eCall process. The MSD reaches the PSAP over the same voice channel that later carries the conversation.

Two points in the picture are easy to miss. First, the eCall Data arrow and the Voice arrow run through the same cellular network, because the MSD is sent inside the voice channel rather than on a separate data bearer. Second, step 2 shows three triggers. The SOS button starts a manually initiated eCall, while the air bag and the collision sensor start an automatically initiated eCall. The network sees this difference at call setup, as the section on CS signalling explains.

• An eCall is an emergency voice call plus the MSD : the IVS sets up the call and then sends the MSD before the conversation starts.
• The MSD travels in-band : it uses the voice channel of the emergency call, so no data bearer is needed.
• Manual and automatic eCalls are told apart : the trigger type is signalled to the network and to the PSAP.

Difference Between Emergency Call and eCall

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.

Emergency call and eCall compared. The signalling is common, and only the content of the voice channel changes.

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

• Setup and release are the same : both calls use the cellular signalling for emergency call setup and release over the GSM/WCDMA voice channel.
• Only the traffic differs : a human talks in the emergency call, while the IVS sends the eCall protocol and the MSD in the eCall.
• HLAP runs inside the voice channel : the cloud labelled "HLAP sequence Explained in next section" marks where the HLAP exchange sits.

How does the network know that a CS call is an eCall ?

The voice channel looks the same for both calls, so the network needs another way to recognize an eCall. The answer is in the call setup. An eCall is a TS12 emergency call, and the IVS adds an eCall flag to the Service category IE.

The IVS starts the call with EMERGENCY SETUP, like any TS12 emergency call. 22.101 requires the IVS to mark the call as a Manually Initiated eCall, MIeC, or an Automatically Initiated eCall, AIeC. 24.008 carries this mark in octet 3 of the Service category IE, as the table below shows.

A UE that starts an eCall sets either bit 6 or bit 7, and sets all other bits to 0. An MSC that supports eCall uses these two bits to route the call to an operator defined emergency call centre. If the MSC cannot match the value, or if no bit is set, it routes the call to the default emergency centre. So an IVS that sends no flag still reaches a PSAP, but possibly not the one that handles eCalls.

Many IVS units are also eCall only devices. The USIM configures such a UE for eCall only mode, and the UE then avoids MM signalling when no call is active. After an emergency call it starts T3242, and after a test or reconfiguration call it starts T3243. In the usual case both run for 12 hours. When they expire, the UE performs the eCall inactivity procedure. It detaches if the network requires it, deletes its LAI and TMSI, and enters the MM Idle state eCALL INACTIVE. In that state the UE ignores paging, so a PSAP can call the IVS back only until T3242 expires.

• An eCall is a TS12 call with a flag : bit 6 of the Service category marks a manual eCall, and bit 7 an automatic one.
• The MSC routes on the flag : an unknown value or no flag goes to the default emergency centre.
• An eCall only IVS goes silent after the call : T3242 or T3243 runs for 12 hours, and the UE then ignores paging in eCALL INACTIVE.

Higher Layer Application Protocol - HLAP

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

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. The IVS asks the PSAP to pull the MSD, and the rest of the exchange is the same as in PULL mode.

Let's read the PUSH sequence from the top. In 26.267, push mode is simply a request from the IVS to the PSAP to pull the MSD.

• The IVS application sends Push-REQ ("ecall Indicator") to its link layer, which sends the Initiation signal to the PSAP.
• The PSAP link layer detects UL sync, gives Push-IND to its application, and receives Pull-REQ back.
• The PSAP may first send the optional NEC tone, which disables the network echo canceller. It then sends SEND-MSD (= START).
• The IVS link layer detects DL sync and gives Pull-IND to its application. The application answers with Data-REQ, and the link layer starts MSD tx.
• The PSAP detects UL sync, checks the CRC and gives Data-IND (MSD) to its application. It sends LL-ACK, the IVS stops the MSD tx and returns Data-CNF, and the PSAP finally sends AL-ACK (HL ACK).

In PUSH mode the PSAP has to wait for UL sync of the Initiation signal before it starts to send SEND-MSD. It may send the NEC tone before SEND-MSD, but not before it has detected the Initiation signal.

PSAP PULL Mode

PSAP PULL 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 that there is no Initiation signal, and the sequence starts with the SEND-MSD (START) signal from the PSAP. 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).

PSAP PULL mode. The PSAP starts with SEND-MSD as soon as the call is connected, without waiting for an Initiation signal.

In PULL mode the PSAP starts to send SEND-MSD (START) right after the eCall is connected. It may put the NEC tone in front of it, typically 3.6 seconds long. The IVS cannot know in advance whether the PSAP works in PUSH or PULL mode. So the IVS always sends the Push-REQ at the start of the eCall, and it stops as soon as it detects SEND-MSD. From the MSD tx onward, the two modes are the same.

LL/HL ACK Operation

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 >

26.969 Figure 1. The MSD transmission time used as the Figure-of-Merit covers only the part from START detection to MSD detection.

The timeline splits one eCall into three processing blocks. Block 1 is the time added by IVS initiated signalling, from Tx first SEND at the IVS to SEND detected at the PSAP. Block 2 is the eCall with PSAP initiated signalling, without HL-ACK. It runs from Tx first START to Tx last LL-ACK. Block 3 is the time added by the HL-ACK confirmation, up to Tx last HL-ACK.

Only a part of block 2 is the MSD transmission time. That part runs from START detected at the IVS to MSD detected at the PSAP, and 26.969 uses it as the Figure-of-Merit. The service requirement is that the whole 140-byte MSD is sent within 4 seconds in optimal conditions. Those conditions are an error-free radio channel with the GSM FR codec or the AMR 12.2 kbit/s mode. Block 1 is not always there, because the IVS initiated signalling can be omitted in an alternate modem configuration.

• PUSH is a request to be pulled : the IVS sends the Initiation signal, and the PSAP then pulls the MSD with SEND-MSD.
• PULL starts at the PSAP : the PSAP sends SEND-MSD as soon as the call is connected, and the IVS stops its Push-REQ when it hears it.
• Two acknowledgements close the transfer : LL-ACK stops the MSD tx, and AL-ACK (HL ACK) confirms the MSD at application level.

Timers in eCall

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.

HLAP timers on the eCall sequence. Each timer guards one wait, so a lost signal cannot block the voice path.

The red dots and dashed lines mark where each timer starts and stops. They read as follows.

• T3 on the IVS runs from the start of the Initiation signal to the dashed line level with Push-IND and Pull-REQ at the PSAP.
• T5 on the IVS runs from the start of the Initiation signal to Pull-IND, which is the wait for SEND-MSD.
• T4 on the PSAP runs from Answer Call to Pull-REQ, which is the wait for the Initiation signal.
• T8 on the PSAP runs from Pull-REQ to Data-IND (MSD), which is the wait for a correct MSD.
• T7 on the IVS runs from the start of the MSD tx to LL-ACK.
• T6 on the IVS runs from LL-ACK to AL-ACK (HL ACK). Both sides then unmute their audio, and the 2 way voice communication starts.

The timer values are in Table A.1 of CEN EN 16062, and ETSI TS 103 428 Annex A applies that table unchanged. The CEN document is not freely available, so this page gives a value only where an ETSI test states it. ETSI TS 103 428 clause 7.3.1 tests T4 with 5 seconds. If no valid Initiation signal arrives within that time, the PSAP unmutes its audio and routes the call to an operator.

• The IVS timers guard the in-band exchange : T3, T5, T7 and T6 cover the Initiation signal, SEND-MSD, MSD tx and AL-ACK.
• The PSAP timers guard the reception : T4 waits for the Initiation signal, and T8 waits for the MSD.
• T4 expiry falls back to voice : the PSAP operator talks to the caller even when no MSD arrives.

What kind of information is transferred during eCall ?

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.

• vehicleIdentificationNumber
• isowmi
• isovds
• isovisModelyear
• isovisSeqPlant
• vehiclePropulsionStorageType
• gasolineTankPresent
• dieselTankPresent
• compressedNaturalGas
• liquidPropaneGas
• electricEnergyStorage
• hydrogenStorage
• otherStorage
• timestamp
• vehicleLocation
• positionLatitude
• positionLongitude
• vehicleDirection
• recentVehicleLocationN1
• latitudeDelta
• longitudeDelta
• recentVehicleLocationN2
• latitudeDelta
• longitudeDelta
• numberOfPassengers

The in-band modem always carries a field of 140 bytes, which is 1120 bits. A shorter MSD is padded, for example with zeros, before it enters the IVS transmitter. The IVS appends a 28-bit CRC, so 1148 bits are protected by the channel coding. A longer message would need segmentation, and 26.267 does not define it.

The MSD is the reason the call exists, but it must never block the call. 22.101 states that a missing, corrupted or lost MSD shall not affect the speech part of the TS12 emergency call. The PSAP can also ask the IVS to send its most recent MSD again during the call.

• The MSD is at most 140 bytes : location, time stamp, VIN and the number of passengers are the core fields.
• A 28-bit CRC protects it : the PSAP asks for more redundancy until the CRC passes.
• Voice has priority over data : a failed MSD transfer leaves the emergency voice call intact.

Which Voice Call Codec to use ?

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.

A speech codec is built to compress speech, not data. So a normal modem signal is distorted by the codec, by radio errors and by the frame error concealment of the speech decoder. The eCall in-band modem of 26.267 uses waveforms designed to pass through the GSM Full Rate codec and the AMR codec modes with only moderate distortion. CTM, the text telephone modem, was also evaluated for this job and did not meet the eCall requirements.

The modem has two modulator modes. The fast modulator mode uses 2 ms symbols and gives 1500 bit/s. The robust modulator mode uses 4 ms symbols and gives 750 bit/s, and it serves as a backup when a transmission fails in difficult conditions. Each symbol carries 3 bits. The MSD is protected by turbo coding with HARQ. Every retransmission adds a new redundancy version, and the PSAP soft-combines them until the CRC passes.

The codec still changes the transmission time. The table below is taken from 26.969 v19.0.0 Table 1. It gives the average MSD transmission time at C/I = 7 dB, the one channel condition where all nine codec modes were measured.

At this C/I the AMR 7.4 and 7.95 modes are the fastest, and the lowest AMR modes take the longest. With an error-free channel, GSM FR takes 1.37 seconds and AMR 12.2 takes 1.35 seconds. Both are well inside the 4 second target for the whole 140-byte MSD. So the IVS does not choose the codec, but the codec the network chooses decides how long the PSAP waits for the MSD.

• The network selects the codec : the eCall modem has to work with GSM FR and every AMR mode.
• The modem has a fast and a robust mode : 1500 bit/s with 2 ms symbols, or 750 bit/s with 4 ms symbols.
• Low AMR modes are slower : at C/I = 7 dB, AMR 4.75 needs 3.12 seconds on average, against 1.68 seconds for AMR 7.4.

How to test eCall ?

An eCall involves three parties: the IVS, the cellular network and the PSAP. A test setup has to provide or simulate the two parties that are not under test. That choice decides how much of the call you can control and repeat.

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.

eCall test over a live network. The IVS simulator and the PSAP simulator are both boards controlled from a PC.

• The IVS simulator on the left is a PC with the MSD, connected by USB to a LEON EVK that acts as the IVS.
• The PSAP simulator on the right is a LISA EVK connected by USB to a PC with the MSD.
• The two simulators meet only through the live cellular network, which is where the uncontrolled issues come from.

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.

eCall test with a network simulator. The tester replaces both the live network and the PSAP.

• The DUT on the left can be an IVS module, a TCU or a whole car.
• The network simulator in the middle is labelled Anritsu MD8475A or B, and it provides the cellular network.
• The PSAP simulator on the right is labelled Anritsu MX703330E, and it runs the PSAP side of the HLAP.

ETSI TS 103 428 lists the same two options for a test site. One option is a test tool that simulates both the PLMN and the PSAP, connected in a shield case or by cable. The other option is a call to 112 in real conditions, where the local authorities allow the test to reach the real PSAP. When the PSAP is reachable only by a long number, a test may use TS11 instead of TS12.

• A live network gives little control : coverage, codec and routing are decided by the operator, not by the test.
• A simulator gives full control : the tester plays the network and the PSAP at the same time.
• Test calls may use TS11 : a long number replaces TS12 when the PSAP has no emergency route for testing.

What to test ?

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.

Test points on the HLAP sequence. Each red label is a check or a fault that the PSAP simulator can apply.

• Signal Quality Check sits at each UL Sync Detection, where the PSAP measures the IVS signal.
• Delay, marked with a red D, is inserted before the NEC tone and before the LL-ACK.
• Omit, Retry and Noise are applied to SEND-MSD and to LL-ACK, so the IVS has to handle a lost or repeated message.
• Timing Check measures the time from SEND-MSD to the start of the MSD tx.
• Message Format Check and CRC Check verify the MSD itself.

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.   

• Function tests come first : they follow the HLAP sequence and are defined by each manufacturer.
• Conformance tests are defined by ETSI : ETSI TS 103 428 gives the HLAP interoperability test descriptions.
• Regional tests come last : each market can add its own regulatory test cases.

Test Examples

A test example makes the HLAP sequence concrete. It gives the stimulus, the expected response and the verdict for one scenario, so it is a good way to check the sections above against a real procedure.

Followings are the examples of how eCall is being testing during the development or for conformance test before commercialization.

• ETSI 103.428  : 7.1.2 MSD transmission / reception / acknowledgement with PSAP in Push mode

The linked example is test 7.1.2, TD_MAN_02. The PSAP is configured for PUSH mode and waits for the Initiation message without sending SEND-MSD. The IVS then starts an eCall and sends the Initiation message within 5 seconds. The test verifies that the PSAP answers with SEND-MSD (START), that the IVS stops the Initiation message, and that the MSD arrives and decodes correctly. It finally checks that the MSD content at the PSAP is identical to what the IVS sent, that the PSAP sends the acknowledgement, and that the IVS stops the MSD transmission.

ETSI TS 103 428 V1.1.1 splits its test scenarios into four groups. Clause 7.1 holds 17 mandatory scenarios, from MSD transfer in Pull and Push mode to call back, clear-down, audio muting and the NEC disabling tone. Clause 7.2 holds 3 optional IVS scenarios, such as auto redial and eCall only service. Clause 7.3 holds 3 optional PSAP scenarios, including the T4 test above. Clause 7.4 holds 1 optional performance scenario with many parallel eCalls.

• 7.1.1 and 7.1.2 are the basic cases : they check the MSD transfer with the PSAP in Pull mode and in Push mode.
• 7.1.10 to 7.1.12 check the MSD indicators : automatic, manual and test call.
• 7.1.15 checks the MSD format : the encoded and decoded MSD must follow CEN EN 15722.

Specification List

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.  

For a UMTS or GSM IVS, three documents cover most of the work. 26.267 defines the in-band modem, ETSI TS 103 428 defines the HLAP test sequences, and 24.008 defines how the call is set up. The CEN documents define the MSD and the HLAP timers, but they are not freely available.

• 26.267 to 26.269 define the modem : description, reference code and conformance testing.
• ETSI TS 103 428 defines the HLAP tests : most of them are based on CEN EN 16062.
• CEN EN 15722 and EN 16062 define the MSD and the HLAP : the 3GPP documents build on them.

IMS based eCall

Overall IMS signaling for eCall is basically similar to regular PSAP (emergency call)  or illustrated at high level as shown belw, but traffic part would be different from regular human subcriber emergency call.

<  23.167 - Figure 7.1: Terminal Detected Emergency Calls >

23.167 Figure 7.1. Steps 1 to 6 prepare the emergency session, and step 7 establishes it.

The traffic part for eCall is also MSD as explained in previous sections of this note.

IMS protocol with focus on MSD(eCall traffic) transfer / update are described in 23.167 as follows. For the details of MSD itself, refer to previous sections in this note.

<  23.167-Figure 7.7.1-1: NG-eCall Scenario with PSAP supporting NG-eCall  >

With an NG-eCall PSAP, the initial MSD travels inside the SIP INVITE and is acknowledged in the 200 OK.

• Step 1 repeats steps 1 to 6 of Figure 7.1.
• In step 2 the UE sends an emergency INVITE that carries the initial MSD and the eCall type of emergency service indicator, automatic or manual.
• In steps 3a to 3c the IMS core routes the INVITE to the NG-PSAP. The 200 OK returns a positive or negative acknowledgement for the initial MSD.
• Steps 4 and 5 complete the call and open the audio media.

<  23.167-Figure 7.7.2-1: eCall Scenario with PSAP not supporting NG-eCall  >

With a CS PSAP, the call is routed through an MGCF, and the MSD falls back to the in-band modem.

• In step 2 the INVITE carries the eCall type of emergency service indication. It carries the initial MSD only if the UE has received the "eCall supported" indication.
• In steps 3a and 3b the IMS core sends the INVITE to an MGCF/MGW, which sends an IAM to the PSAP in the CS domain.
• In step 5 the UE sends the MSD in-band with the eCall modem of 26.267, if the MSD was not sent or not acknowledged in step 2.

The PSAP can also ask for an updated MSD during the session. In that case the IMS core forwards the request to the UE, and the UE returns its most recent MSD. So the in-band modem of the earlier sections is still needed for eCall over IMS whenever the PSAP sits in the CS domain.

• NG-eCall puts the MSD in SIP : the INVITE carries the initial MSD, and the 200 OK acknowledges it.
• A CS PSAP still needs the in-band modem : the MSD is sent in the voice path after the MGCF interworking.
• The eCall type indicator drives routing : the IMS core routes on it and on the location, not on the MSD content.

Which one to choose from ? CS or PS - IMS ?

Now we have two ways of doing eCall. CS and PS. Which one should be used when eCall is necessary. Simple logic of selection criteria is defined in 23.167 as follows.

Both tables below follow 23.167 v20.0.0. Table H.1 is the general rule for emergency calls, and 23.167 states that it does not apply to NG-eCall. Table H.2 is the rule for eCall over IMS, and it adds the column ECL, the eCall over IMS support indicator of the network. The last two columns of each table are what the UE does, and the other columns are the conditions.

< 23.167 - Table H.1: Domain Selection Rules for emergency session attempts for UTRAN, E-UTRAN or NG-RAN radio access networks >

< 23.167-Table H.2: Domain Selection Rules for eCall over IMS session attempts for E-UTRAN or NG-RAN radio access networks >

Table H.2 is simple once you look at ECL. With ECL = Y, the first attempt can use PS. With ECL = N, the UE first uses CS if it is available, because only a CS eCall carries the MSD to every PSAP. A UE in eCall only mode falls back to a PS emergency session with ECL = N only after it failed to find another PLMN with ECL = Y or with CS. There is also one stop rule. If a PSAP rejects the eCall over IMS but positively acknowledges the MSD, the UE does not try again on another RAT or on CS, and waits for a call back.

On UMTS itself the choice is even simpler for an eCall only IVS. 24.008 states that an eCall only device uses the CS domain for an emergency call in A/Gb or Iu mode, even if it can do eCall over IMS. So on GSM and UMTS the eCall of this page is always a CS call.

• Table H.1 is not for NG-eCall : eCall over IMS follows Table H.2 with its ECL column.
• ECL decides the first attempt : PS with ECL = Y, CS if available with ECL = N.
• An eCall only IVS on UMTS uses CS : the in-band modem stays the MSD path there.

Reference

• eCall over IMS - WirelessMoves
• 3GPP TS 26.267 v19.0.0 - eCall data transfer; In-band modem solution; General description
• 3GPP TR 26.969 v19.0.0 - eCall data transfer; In-band modem solution; Characterization report
• 3GPP TS 24.008 v20.0.0 - clauses 4.4.7 and 10.5.4.33
• 3GPP TS 23.167 v20.0.0 - clause 7.7 and Annex H
• ETSI TS 103 428 V1.1.1 - Mobile Standards Group; eCall HLAP Interoperability Testing