How To: Verifying eCall Service

As the Internet of Things (IoT) grows and expands, the number of different elements that will have to consistently connect to any given network is expanding with it. Of course, some of these elements are more impactful than others. For instance, as of March of 2018, an EU directive requires that all new passenger cars be equipped with an EU eCall system. Because every second can be vital after a serious accident, it’s essential that in case of an accident the eCall device transmits emergency data to the nearest emergency center (PSAP, or “public safety answering point”) and/or trigger an emergency call. This means that in every EU country your network must automatically relay relevant information (e.g. vehicle type, direction, number of passengers, engine type, VIN, GPS coordinates, etc.) from the eCall modem to the correct emergency center in case the driver is too incapacitated to speak.

Needless to say, this is a high stakes area for testers, who need to be absolutely certain that in the event of a crash all relevant information is relayed correctly and that the call is routed to the nearest emergency operation center. Not only is this a matter of complying with EU law, it’s a matter of the health and safety of the users on your network. This means that performing high quality tests on an ongoing basis isn’t something you can treat as optional.

The Challenge

The assumption when testing is that emergency calls will have the highest signalling priority and (which means proper verification must involve signalling analysis), that the system will transmit the correct data (MSD, or “minimum set of data”) to the network, and that the data itself won’t become lost or adulterated by the time it reaches the emergency center—and each of these facets has to be verified in turn to ensure functioning service. Since the data is being transported via the voice channel, your mobile switching centers/media gateways need to ensure it isn’t damaged by transcoding and conversion between different voice codecs, different bitrates, etc. Naturally, because network conditions and network element configurations change all the time, it’s important that device testers not simply validate this functionality and forget about it, but that you check the status of the eCall service on a regular basis in order to ensure continued service, i.e. you need to make eCall verification a part of your standard test flow.

Because this service is so critical, SEGRON has been working to assist testers in automating verification for this unique service offering. Our goal is to put our customers in a position to address the other hurdle that tends to crop up in any manner of telco testing: time. If these tests were performed manually, there could be considerable costs associated with the engineer-hours required to maintain them on an ongoing basis.

The Approach

Automating tests for this use case requires 2 PCS operator SIM cards, an ATF (Automated Test Framework—SEGRON’s Robot Framework-based test solution) instance, and LTE modules with eCall functionality. One module is configured to act as the IVS (using the same LTE chip that would be in the vehicle itself), and another would ostensibly simulate the PSAP modem receiving the signal on the other end , in order to verify the encoded emergency messages. This situates the operator network between two relevant endpoints, such that testers can examine the way that their radio access network and core network (including media gateways and mobile switching centers) would actually transport the eCall data and voice in the event of an emergency.  From there, the tests can be configured to the customer’s unique needs in less than a day, aimed at a few specific goals:

• To detect any possible misconfigurations in the call set-up
• To ensure that the relevant information is being transmitted to the network and then on to the emergency center without any errors in transmission
• To direct the attention of dedicated network engineer resources and skills from routine testing to make corrective actions in call set-up
• To ensure fulfillment of legal obligations toward authorities

By running a series of automated tests, testers can determine both the existence and the location of any gaps in service. For instance, if the network were scrambling or damaging the emergency information payload (i.e. the MSD) due to some special voice codec settings or voice transcoding, the tests would make that fact fairly obvious. Likewise if the network were somehow failing to send the data to the appropriate emergency center. And because signalling priority is a factor, our final tests need to move beyond the end-point results to incorporate signaling and/or CDR data collected from various network elements. In this way, we can identify issues in the network tuning for eCall support that might otherwise not have revealed themselves until it was too late.

And again, this is the type of testing that needs to be performed repeatedly and frequently in order to ensure service quality. If our client had decided to stick with manual testing, that would have meant a significant ongoing outlay of valuable engineer-hours.  Luckily, once these test are automated, it’s easy to run them again and again as needed. The result is that, in addition to ensuring high quality of service in an area that’s critical to the safety of the company’s users.

ROI for Test Automation

Obviously, when it comes to something like eCall service, the potential costs of a service outage are obvious and significant. If your eCall service malfunctions in an emergency, your users may not get the care they need quickly enough, potentially leaving you with PR trouble and legal liabilities that would be costly to mitigate. This reasoning applies not just to this particular use case, but to any number of IoT devices that rely on constant communication to maintain important functionality like temperature control or home security.

In addition to staving off the high costs associated with disasters and disruptions, of course, automating this kind of test can bring value in the form of more optimal resource allocation. For instance, if automation frees up your engineers to focus on something more value-additive during the hours when they would otherwise be running laborious regression tests, you can apply that added value to the ROI for the automation itself. If the time saved verifying eCall functionality gives an engineer the time and mental energy to develop a cheaper way of producing your connected devices, for instance, you might be poised to make back the costs associated with automation in record time.

Learn More About Test Automation

Click below to see how SEGRON’s ATF can help you automate testing.