NG eCall certification from solution selection to certificate issuance consists of three main stages: UN R144 type approval, EN 17184 end-to-end functional testing, and notified body technical review. The system runs on 4G/5G IMS packet-switched domains – test equipment and simulation environments are completely different from legacy CS eCall – old experience does not apply.
1.1 Component certification vs. whole-vehicle certification
First, decide the申报 route. T-BOX and AECS module manufacturers can obtain UN R144 component-level type approval; vehicle OEMs can reference this component certificate during WVTA whole-vehicle certification – provided the hardware and firmware remain identical. Even with referencing, the notified body retains the right to request additional vehicle-level integration verification – do not assume a component certificate eliminates all vehicle-level retesting.
1.2 NG eCall vs. CS eCall
From 2026, several EU member states no longer accept new CS eCall type-approval applications for new vehicle types. Plan new projects around NG eCall. Confirm the local implementation policy with the target market authority before starting – to avoid having an old CS plan rejected.
2. NG eCall Technical Solution and Documentation
2.1 System architecture design document
Compile complete technical documentation – IVS terminal hardware architecture, communication module selection, GNSS positioning solution, and backup power supply design. The communication module must support 4G VoLTE or 5G VoNR IMS packet-domain access. GNSS positioning must meet EU 2017/79 Annex VI requirements – dynamic positioning CEP95 horizontal error ≤ 50 m.
2.2 MSD V3 dataset design
NG eCall uniformly mandates MSD V3 – following EN 15722 Ed.3 – with a total of 32 fields. Compared to MSD V2, new fields include powertrain type and battery-related information. MSD encoding and population logic should be locked during firmware development – adjusting at the testing stage risks missing fields.
2.3 Notified body selection
Prioritise NBs with proven capability in EN 17184 and EN 17244 assessment. Not all E-mark-accredited NBs can handle NG eCall. Confirm the NB's scope and current scheduling before signing.
3. NG eCall Lab Testing
3.1 IMS registration and SIP signalling testing
NG eCall relies on IMS packet-domain communication – the lab must verify IVS terminal IMS registration, SIP signalling interaction, and VoLTE AMR-WB voice codec. The test environment requires a PSAP emulator, cellular network tester (e.g., CMW500, MD8475B), and dedicated EN 17184 eCall simulation software for full end-to-end validation.
3.2 MSD transmission and voice link
Automatic crash trigger and manual SOS trigger paths are tested separately. When the PSAP initiates a callback, the in-vehicle terminal must auto-answer and re-establish the voice channel. The widely quoted "4-second MSD delivery" split-time threshold is not a mandatory EN 17184 clause – do not constrain development with this single metric. Many NBs adopt a 5-min call + 56-min standby + 5-min call duty-cycle for backup-power assessment – confirm the criteria with the lab before starting.
3.3 GNSS positioning testing
GNSS testing must use signal generators – not outdoor live-sky reception. EN 17184 focuses on whether positioning data is correctly populated into the MSD packet. The often-cited -145 dBm sensitivity is not a standard-mandated threshold – it is an internal lab reference – do not treat it as a hard development target.
3.4 Network compatibility testing
Prioritise lab simulation of various band scenarios – no need for large-scale field testing with multiple operator SIMs – covering major EU bands and modes is sufficient.
3.5 Test timeline reference
Component-level full EN 17184 testing – no remediation: 6–8 weeks. Multi-band, multi-system GNSS solutions: 10–12 weeks. Whole-vehicle projects with integration verification take longer.
4. NG eCall Notified Body Review
4.1 Technical file review
After all lab tests pass, submit the complete test report, hardware technical files, and firmware version record to the NB. Review focus: system architecture, MSD design, GNSS solution, backup-power test data, and risk assessment. Standard review: 4–6 weeks – missing or contradictory documents extend the timeline.
4.2 UN R155 boundary
UN R155 (vehicle cybersecurity) is a mandatory WVTA requirement for whole vehicles – component-level UN R144 certification does not mandate UN R155. Component suppliers should not be misled into unnecessary testing. Also distinguish: EN 18030 (RED 3.3 cybersecurity) is a separate compliance line from UN R144 vehicle type approval – do not mix them in budgeting.
4.3 DoC signing note
The DoC signing rules under UNECE R-regulations are not identical to EU CE DoCs – strictly follow your NB's template.
5. NG eCall Certification Issuance and Ongoing Maintenance
5.1 Certificate issuance
After final NB approval, the UN R144 type-approval certificate is issued. There is no unified statutory validity period. The "3-year" figure often heard is an internal NB CSMS surveillance cycle – not a WP.29 regulation.
5.2 Change management rules
Replacing a communication module with the same architecture and identical RF parameters does not necessarily require full retesting – difference testing may apply. Localised MSD field parsing adjustments typically only require retesting of MSD interaction items. Annual functional regression self-testing is an internal control recommendation – not an EU regulatory obligation. Only hardware changes, major firmware upgrades, or official standard updates trigger reassessment.
5.3 Medium/long-term planning note
Rumours of 2028 regulatory additions – OBD reading eCall status and voice self-check – are still draft proposals – not legislated. Treat as long-term directional reference – do not make hardware investments based on non-effective drafts – regulatory risk must be factored in.
For NG eCall certification steps, contact BlueAsia at 13534225140 (King) or king.guo@cblueasia.com.
Related News
