Telematics & eCall

Intermediate9 min read

Assumes: 7.1 AMSS/MPSS

TL;DR

Telematics turns the vehicle into a connected node: GPS position, remote services, fleet data, and crash response over the AMSS modem. The TCU (Telematics Control Unit) role is the connectivity hub: manage SIM, data sessions, voice, and SDK APIs for application code on QNX or AAOS. eCall (EU-mandated) auto-dials 112 with GPS coordinates on crash detection, plus a manual SOS button. Application developers use TelAF (Telematics Application Framework), C++ APIs for calls, SMS, data, location, and firmware update. V2X adds vehicle-to-everything radio: C-V2X (cellular-based, Qualcomm’s path forward) vs legacy DSRC (802.11p, mostly deprecated in new programs).

AMSS gives you bars on the status icon. Telematics is what the vehicle does with those bars, and it’s where regulatory requirements (eCall), OEM connected services, and your application code all meet.

The TCU Role: Connectivity Hub

In modern centralized architectures, the “TCU” is often not a separate box. It’s a software role running on the cockpit SoC alongside QNX and AAOS, backed by the integrated modem (AMSS/MPSS). “Have you tried turning it off and on again?” is much more powerful when you can do it from 500 miles away.

TCU Responsibility	What It Means in Practice
SIM / subscription management	eUICC profiles, carrier provisioning, APN config
Data session lifecycle	Bring-up PDP/PDU contexts, reconnect on tunnel loss
Voice call control	VoLTE, emergency call routing, in-band modem
Location services	GNSS fusion, dead reckoning assist for eCall
Application API surface	TelAF SDK for OEM telematics apps
Regulatory compliance	eCall, ERA-GLONASS (Russia), regional SOS variants
Security boundary	Credentials, TLS to cloud, certificate rotation

On a Qualcomm cockpit platform (SA8155P, SA8295P), the TCU stack typically spans:

flowchart TB
    subgraph APPS["Application Layer"]
        OEM["OEM Telematics App<br/>(QNX or AAOS native)"]
        ECALL["eCall / SOS Handler"]
        CLOUD["Cloud Agent · OTA Client"]
    end

    subgraph TELAF["TelAF SDK (C++)"]
        VOICE["Voice Service"]
        DATA["Data Service"]
        SMS["SMS Service"]
        LOC["Location Service"]
        FWU["Firmware Update Service"]
    end

    subgraph MODEM["AMSS / MPSS (Modem Subsystem)"]
        QMI["QMI Voice · WDS · NAS · LOC"]
        RF["LTE / 5G / GNSS RF"]
    end

    subgraph V2X["V2X (Optional)"]
        CV2X["C-V2X PC5 / Uu"]
    end

    OEM --> TELAF
    ECALL --> VOICE
    ECALL --> LOC
    CLOUD --> DATA
    TELAF --> QMI
    V2X --> MODEM
    RF --> ANT["Antenna Farm<br/>Cellular · GNSS · V2X"]

Think About It

eCall must work even if the infotainment system crashes. How is this possible if both share the same SoC?

Reveal Answer

eCall runs on the QNX telematics daemon via TelAF, not through AAOS — crash sensor GPIO → QNX → TelAF Voice → QMI IMS on AMSS, a path that never waits for Android framework boot. QNX and AAOS are separate hypervisor VMs with independent crash domains; the modem subsystem is a third domain that keeps running when either guest VM dies. To verify, kill or hang the AAOS VM on bench and trigger eCall test mode from the airbag/SOS path — the 112 IMS session and MSD should still fire while the center stack is frozen.

Mental Model

Think of telematics as the vehicle’s 911 dispatcher desk. AMSS is the phone network in the wall. TelAF is the dispatcher’s console — buttons for “make call,” “send data,” “where am I,” “update phone firmware.” eCall is the red panic button wired to the airbag sensor — it must work even if the infotainment UI is frozen. Cloud services are the regional call center receiving the vehicle’s data. Your job is making sure the dispatcher desk (TelAF integration) correctly uses the phone network (QMI/AMSS) under crash and tunnel-failure stress.

TCU = the car’s smartphone. eCall = the car’s emergency speed dial.

eCall: When Crash Meets Regulation

eCall is an EU mandate (Regulation 2015/758, mandatory for new vehicle types from 2018 onward, type-approved under UN ECE regulations) requiring in-vehicle emergency calling. It’s not optional for vehicles sold in scope, and it has hard real-time requirements that survive infotainment failure.

Automatic Trigger (Crash)

On qualified crash detection (typically from ACN — Automatic Crash Notification sensor fusion, often airbag deployment signal + accelerometer):

1. Modem initiates an IMS emergency voice session to 112 (EU emergency number)
2. Minimum Set of Data (MSD) transmitted, including GPS/GNSS coordinates, vehicle VIN, direction of travel, timestamp
3. Voice channel opens even if MSD send fails (voice is mandatory fallback)
4. Call must proceed without user interaction. The driver may be unconscious.

Manual Trigger (SOS Button)

The SOS button (often overhead console or center stack) triggers the same emergency call path. Regulatory testing verifies:

• Button works with ignition off (within battery budget)
• Button works when infotainment is crashed or booting
• No accidental triggers (long-press, cover, self-test)

Why eCall Lives Close to the Modem

eCall is not implemented as an Android app making a normal phone call. It routes through modem IMS/voice QMI paths with priority queuing that bypasses AAOS media framework latency. Put eCall logic purely in AAOS Java and you fail homologation. The call must work when Android is down.

Common Gotcha

Beginner thinks eCall is just the SOS app on the center stack. Reality: the UI button is one piece. eCall certification covers the full chain: crash sensor → telematics daemon → TelAF/QMI voice → AMSS IMS → RF antenna → 112 PSAP reception with valid MSD. A beautiful SOS UI with a broken modem voice path is a homologation failure, not a feature.

TelAF: The SDK You Actually Integrate

TelAF (Telematics Application Framework) is Qualcomm’s C++ SDK that wraps QMI into application-friendly services. Your OEM telematics binary on QNX (or sometimes AAOS native) links against TelAF. You don’t raw-pack QMI structs in product code.

TelAF Service	API Capability	Typical Use
Voice	Dial, answer, hang up, emergency call	eCall, concierge, RSA (roadside assist)
SMS	Send/receive text	Fleet notifications, fallback messaging
Data	Start/stop data calls, APN management	Cloud connectivity, OTA download
Location	GNSS fix, fused location	Navigation assist, stolen vehicle tracking
Device Management	IMEI, signal strength, modem reset	Factory test, field diagnostics
Firmware Update	Stage and apply modem images	Modem OTA (Module 7.3)

TelAF vs Android Telephony

	TelAF (QNX / native)	Android Telephony (AAOS)
Runs on	QNX telematics process, sometimes native AAOS daemon	Android framework + TelephonyManager
Modem access	Direct QMI via TelAF	rild + vendor RIL HAL → QMI
eCall suitability	Primary path for safety-regulated builds	Usually not the certified eCall path
Your daily touch	QNX telematics integration, factory EOL	adb shell dumpsys telephony, carrier apps

MSD Payload — What's in the Crash Packet

The Minimum Set of Data eCall packet (standardized in EN 15722) includes: vehicle type, VIN, propulsion type (ICE/EV/hybrid), timestamp, recent locations (current + optional previous), direction, and optional passenger count. It’s sent in-band over the voice call (modem tones) or out-of-band depending on generation and PSAP capability. Getting MSD encoding wrong fails type approval even if the voice call connects. QA teams test this with eCall simulators and PSAP lab benches, not just “does 112 dial.”

V2X: C-V2X vs DSRC

V2X (Vehicle-to-Everything) lets the car exchange messages with other vehicles (V2V), infrastructure (V2I), pedestrians (V2P), and networks (V2N): intersection collision warnings, work zone alerts, traffic light timing.

	DSRC (802.11p)	C-V2X (3GPP)
Radio technology	Wi-Fi-like direct radio (ITS-G5 in EU)	PC5 sidelink (direct) + Uu via cellular network
Qualcomm stance	Legacy, supported on older programs	Current path, integrated with Snapdragon modem
Range / latency	~300 m direct, low latency	Similar direct range; network mode adds cloud relay
Spectrum	Dedicated 5.9 GHz (region-dependent)	PC5 reuses cellular bands / 5.9 GHz (region-dependent)
Your daily touch	Maintaining legacy fleets, dual-radio TCUs	New platform bring-up, coexistence with LTE/5G antenna

On Qualcomm automotive platforms, C-V2X typically shares RF planning with the cellular modem: antenna isolation, calibration, and regulatory testing are joint exercises. DSRC programs often required a separate 802.11p radio. Know which your variant ships.

Connect the Dots

Module 1.4 linked Connected (CASE) to OTA and telematics. Module 7.1 explained AMSS, the modem world TelAF talks to. This page is the application layer above QMI: regulatory (eCall), OEM services (cloud, fleet), and optional V2X. Module 7.3 covers modem firmware updates via TelAF’s Firmware Update Service. Module 8 covers OTA architecture for AAOS/QNX, a separate path from modem updates.

Quick recap

1. TCU = connectivity hub role: SIM, data, voice, location, APIs, often on the cockpit SoC, not a separate ECU.
2. eCall auto-dials 112 with GPS/MSD on crash; SOS button triggers the same regulated path, not a normal Android phone call.
3. TelAF provides C++ APIs (voice, SMS, data, location, FW update) over QMI: your integration surface on QNX telematics.
4. V2X: C-V2X is Qualcomm’s forward path; DSRC is legacy 802.11p. Know your program’s radio.

Where You'll See This

Telematics bugs land in your queue disguised as “navigation can’t get GPS” or “connected services offline”:

• Distinguish GNSS from cellular: TelAF Location Service vs NAS/WDS data session. GPS fix without cloud = data/APN problem. No GPS at all = antenna or LOC QMI path.
• eCall test mode: Factory builds have eCall simulation that must never dial live 112 on the line. Know your project’s test PSAP number and how to enable/disable test mode before bench work.
• SOS button wiring: Often GPIO to QNX telematics daemon, not AAOS input event. If SOS works in factory menu but not from physical button, suspect hardware/GPIO mapping, not TelAF.
• Carrier variance: Same TelAF build, different APN/SIM profiles per region. “Works in DE, fails in US” is usually provisioning, not code.

When integrating a new cloud feature, trace the full path: your app → TelAF Data Service → QMI WDS → AMSS → carrier APN → internet. Breakage at any hop looks like “no connectivity” from the app team’s perspective.

Check Your Understanding

1. EU eCall requires which behavior on automatic crash detection?

Recall

A. Display an SOS dialog on the AAOS center stack for user confirmationB. Send an SMS to the OEM cloud server onlyC. Enable Wi-Fi hotspot for emergency responder accessD. Auto-dial 112 with GPS/MSD data without user interaction

2. In a centralized cockpit architecture, what role does the TCU play?

Recall

A. The connectivity hub: SIM, data, voice, location, and regulatory servicesB. A separate CAN gateway ECU that only forwards OBD-II diagnostic requestsC. The hypervisor host VM that schedules AAOS vCPUs and manages VM isolationD. The ADAS perception processor responsible for sensor fusion and object lists

3. C-V2X differs from legacy DSRC (802.11p) primarily in that:

Recall

A. Both are identical protocols — the difference is only in marketing namingB. C-V2X is cellular-based (PC5 sidelink / Uu); DSRC is 802.11p direct radioC. DSRC uses the cellular modem stack; C-V2X requires a separate Wi-Fi chipD. DSRC is Qualcomm's current automotive standard; C-V2X has been deprecated

4. Where should regulated eCall voice routing primarily execute on a Qualcomm cockpit platform?

Applied

A. QNX telematics daemon via TelAF Voice Service → QMI → AMSS IMSB. Hexagon DSP audio FastRPC pathC. AAOS Java app using TelephonyManagerD. QNX cluster VM rendering an emergency UI

5. Connected services work in Germany but fail in the US on the same TelAF build. QXDM shows successful LTE attach in both regions. Most likely cause?

Applied

A. QNX hypervisor pinning the telematics process to the wrong vCPU affinityB. V2X PC5 sidelink transmission is blocking the Uu data bearer attachmentC. MPSS firmware region lock — reflash modem NV items for US band planD. Carrier provisioning mismatch — APN/eUICC profile differs, not a code defect

6. eCall must auto-dial 112 when the airbag deploys, even if AAOS is still booting. How does the architecture satisfy this safety requirement across OS boundaries?

Synthesis

Connects to: Module 9 — eCall Safety Requirements

A. Android TelephonyManager registers a high-priority broadcast receiver at bootB. Crash GPIO → QNX TelAF Voice → QMI IMS on AMSS — no AAOS dependencyC. The QNX cluster VM renders an emergency UI that triggers the voice callD. eCall uses V2X PC5 sidelink direct messaging instead of cellular voice

Further Reading

• 3GPP Specifications Catalog — Official catalog for cellular and C-V2X standards (LTE-V2X, 5G NR-V2X) that define the modem protocols TelAF rides on.
• EU Regulation 2015/758 (eCall) — Legal text for mandatory in-vehicle emergency calling (112) with Minimum Set of Data — the regulatory basis for eCall on this page.
• ETSI Intelligent Transport Systems — European ITS standards for CAM, DENM, and C-ITS message formats used alongside telematics services.
• Qualcomm TelAF SDK — Qualcomm’s Telematics Application Framework documentation for voice, SMS, data, location, and firmware update APIs.
• Qualcomm Automotive Connectivity — Product landing page for Snapdragon automotive modem platforms integrating telematics, eCall, and C-V2X.
• EN 15722 — eCall MSD Standard — ETSI standard defining the Minimum Set of Data payload transmitted during emergency calls.
• GSMA eSIM for Automotive — eUICC and remote SIM provisioning concepts relevant to TCU subscription management across regions.