Industry Solutions

Why In-Vehicle Zonal Positioning Is Becoming a Platform Decision

Two regulatory and user-experience forces are converging on the vehicle cabin at the same time. First, child presence detection (CPD) is moving from a premium differentiator to a mandated safety function in multiple markets, with requirements that demand detection of a breathing infant left in a parked car under direct sunlight. Second, the digital key is shifting from a convenience feature to the primary access credential, which means the vehicle must know not just that an authorized phone is nearby, but where it is — inside the cabin, at the driver door, in the trunk, or walking away. Both problems are, at their core, high-precision zonal positioning problems inside a metal enclosure full of reflectors.

This article evaluates the emerging architecture that pairs automotive-grade Ultra-Wideband (UWB) with Bluetooth Channel Sounding (CS) — the ranging feature introduced in Bluetooth 6.0 and refined in the 6.1/6.2 core specification line — as a combined in-vehicle positioning platform. It focuses on what an OEM, Tier-1, or fleet integrator actually needs to decide: which radio does which job, what the real-world accuracy and latency look like, how the two technologies compare for specific cabin use cases, and what to specify in an RFQ. Where the Bluetooth SIG's own validation work is still in draft form, we say so explicitly rather than treating it as settled.

The Two Radios Are Not Competitors — They Solve Different Halves of the Problem

A common procurement mistake is to frame UWB and BLE Channel Sounding as alternatives and run a bake-off. In the cabin they are complementary, and the complementarity is structural rather than a matter of vendor preference.

UWB delivers centimeter-class ranging using very wide bandwidth (typically 500 MHz or 1 GHz channels in the 6.5–8 GHz region), which gives fine time resolution and strong multipath rejection. It is the natural anchor for the digital key because it supports secure ranging with distance-bounding properties that resist relay attacks. Its weaknesses in-vehicle are power, cost, antenna placement complexity, and the fact that a metal cabin is a reverberant chamber — but its precision is the reason it owns the security-critical ranging role.

BLE Channel Sounding is the newer entrant. Rather than measuring received signal strength (which is what legacy BLE RSSI-based proximity does, badly, in a car), CS performs a two-way phase-based and/or time-of-flight measurement across multiple channels in the 2.4 GHz band. The Bluetooth 6.0 specification introduced CS as a core feature, and subsequent core specification revisions (6.1, and the draft 6.2 work) have continued to refine the measurement and calibration model. Because it runs on the same 2.4 GHz radio already present for phone-as-key, telematics, and cabin connectivity, it adds ranging capability with far less incremental BOM than a second UWB subsystem — at lower precision than UWB, but with much better coverage and cost profile.

The practical division of labor that is emerging:

• UWB anchors handle secure entry/exit authorization, precise exterior zone discrimination (driver vs. passenger vs. rear door approach), and trunk/frunk presence.
• BLE CS handles continuous, low-power in-cabin occupancy and zone tracking — which seat, which row, whether a device or tag is present in the rear cabin — and serves as a coverage and cost backstop where UWB anchor geometry is poor.
• Fusion layer combines both range sets with cabin geometry and seat occupancy models to produce a zone decision with a confidence score.

What Each Technology Actually Delivers In-Cabin: A Benchmark Comparison

The table below reflects typical published capability ranges for the two radio families and the practical in-cabin performance an integrator should plan around. Treat the "in-cabin realistic" figures as engineering planning numbers, not datasheet guarantees — multipath in a metal cabin degrades both technologies relative to open-field specs.

The Standardization Caveat You Must Factor Into Your Schedule

BLE Channel Sounding is real and shipping in silicon, but the specification ecosystem around it is still in motion. The Bluetooth SIG's Core Specification Work Group has published validation specifications — for example, the Channel Sounding Inline Phase Correction Term Transfer validation specification (document VSr00_PR, version dated 2025-12-02), which proposes changes to the Bluetooth Core Specification Version 6.2. That document is explicitly labeled a working draft: "This document is a working draft of a potential Bluetooth specification. It is subject to change and Bluetooth SIG is not required to finalize or adopt it."

What this means commercially: the inline phase correction term transfer work matters because phase-based CS accuracy depends on calibrating out systematic phase errors across the channel sweep. If the calibration transfer mechanism changes between draft and final, early implementations may need firmware updates or re-qualification. Plan for this in your program schedule. Do not lock a safety-critical CPD certification to a draft-stage measurement procedure without a fallback path. A defensible posture is to design the CS subsystem for field-updatable calibration and to keep the UWB path as the certified safety anchor until CS validation specs stabilize.

Real-World Scenario: Child Presence Detection in a Parked Vehicle

Consider the canonical CPD scenario: a vehicle parked in an open lot at 35 °C ambient, cabin interior exceeding 50 °C, an infant in a rear-facing seat in row 2. The system must detect a breathing occupant within a defined time window after lock, and must not false-alarm on a forgotten bag or a sun-warmed seat cushion.

Neither radio detects breathing directly. The positioning layer contributes occupancy and micro-motion evidence: is there a body-mass object in the rear zone, and does its reflected signal show the low-frequency micro-displacement of respiration? UWB's fine time resolution can, with appropriate processing, detect sub-centimeter periodic displacement from chest motion — this is the strongest technical argument for UWB in CPD. BLE CS contributes persistent zone occupancy and a second, independent measurement modality that reduces false negatives when UWB geometry is shadowed by a folded seat or a blanket.

A realistic fused pipeline:

• Stage 1 — Zone occupancy (both radios). UWB ranges from 3–4 cabin anchors plus BLE CS ranges from the phone/telematics radio establish which seat zones contain reflecting mass. Latency target: under 2 s after lock event.
• Stage 2 — Vital-sign corroboration (UWB primary). Phase/amplitude micro-Doppler processing on the UWB return from the occupied zone. Requires a stable anchor-to-zone geometry; a blanket over the infant attenuates but does not eliminate the signature at UWB frequencies.
• Stage 3 — Confidence fusion and escalation. If zone occupancy is high-confidence but vital-sign confidence is low, escalate to vehicle-level alerts (horn, hazard lights, telematics push) rather than suppress. False-negative cost in CPD is catastrophic; design the fusion logic asymmetrically.

Benchmark expectation to specify: detection of a simulated infant (breathing simulator) in row 2 within 30 s of lock, with false-alarm rate below one per 1,000 lock cycles in a parked-lot test matrix covering direct sun, shade, and post-rain humidity. These are demanding but achievable numbers for a fused UWB+CS design with good anchor placement; a BLE-CS-only design will struggle to hit the false-alarm target because its micro-motion sensitivity is lower.

Real-World Scenario: Digital Key Zone Discrimination

The second workload is the digital key. Here the requirement is different: the vehicle must authorize unlock when the phone approaches the driver door, must NOT unlock when the phone is on the other side of a wall in the owner's house, and must prevent a relay attack where an attacker bridges the phone's signal to the car.

UWB owns this. The CCC Digital Key specification and IEEE 802.15.4z secure ranging provide the distance-bounding primitive. BLE CS is useful here as a corroborating measurement — if UWB says 0.4 m and CS says 4 m, something is wrong and the system should refuse. This cross-check is cheap to implement and materially raises the bar for relay attacks, because an attacker must now spoof two independent physical measurements consistently.

Practical specification guidance:

• Require UWB ranging for all unlock/start authorization decisions.
• Use BLE CS as a consistency check with a defined tolerance envelope (e.g., reject if |UWB range − CS range| exceeds a geometry-derived threshold).
• Log both range sets for post-incident forensics; OEMs increasingly want this for warranty and security investigations.

Hardware and Software Architecture: What to Put in the RFQ

The fused solution is only as good as its partitioning. A workable reference architecture:

┌─────────────────────────────────────────────────────────┐
│                  Fusion / Decision Layer                 │
│  zone classifier · confidence scoring · escalation FSM   │
└───────────────┬─────────────────────┬───────────────────┘
                │                     │
      ┌─────────▼─────────┐  ┌────────▼──────────┐
      │  UWB Subsystem     │  │  BLE CS Subsystem │
      │  anchors (3–4)     │  │  2.4 GHz radio    │
      │  secure ranging    │  │  multi-channel    │
      │  micro-Doppler     │  │  phase/RTT meas.  │
      └─────────┬─────────┘  └────────┬──────────┘
                │                     │
      ┌─────────▼─────────────────────▼──────────┐
      │        Cabin Geometry Model               │
      │  seat zones · anchor positions · shadowing │
      └───────────────────────────────────────────┘

Key RFQ line items that separate a working design from a demo:

• Anchor count and placement study. Demand a multipath simulation (ray-tracing) of the specific cabin with the proposed anchor positions, including seat-fold and cargo-load variants. Three anchors is a minimum for 2D zone resolution; four enables 3D and better shadowing tolerance.
• Calibration transfer mechanism. Ask explicitly how the vendor handles CS phase calibration transfer and whether it is field-updatable given the draft status of the SIG validation specs.
• Fusion API contract. The decision layer must expose per-radio range, confidence, and timestamp so the OEM can tune fusion logic without vendor involvement. Black-box "zone output only" APIs are a trap for CPD certification.
• Power budget at always-on. CPD requires monitoring after lock. Specify average current for the CS subsystem in occupancy-tracking mode and the UWB duty cycle for vital-sign monitoring. A design that wakes UWB continuously will drain the 12 V battery in days.
• Security logging and update path. OTA-capable firmware for both radios, with signed updates, is non-negotiable for a safety function.

Comparing Competing Approaches: Three Architectures Head-to-Head

An OEM evaluating this space will typically see three proposals. Here is how they compare on the dimensions that decide a program.

The fused architecture wins on the safety-critical use case, but it is not the right answer for every vehicle line. A cost-sensitive B-segment platform that needs a regulatory CPD checkbox and a basic phone key may be better served by BLE CS alone plus a legacy ultrasonic or pressure-mat CPD sensor — accepting lower precision in exchange for a much shorter integration cycle. Reserve the fused UWB+CS platform for vehicles where the digital key is a marketed feature and CPD must meet the highest detection-confidence tier.

Actionable Recommendations

For OEM program managers: treat the positioning subsystem as a platform, not a feature. Specify the fusion API and the calibration-update path in the RFQ, and require a cabin-specific ray-tracing study as a deliverable. Budget schedule contingency for CS validation-spec finalization — the draft status of the SIG's inline phase correction work is a real schedule risk, not a theoretical one.

For Tier-1 suppliers: the differentiator is not the radio silicon (which will commoditize) but the fusion logic and the cabin geometry model. Invest in a reusable, vehicle-parameterized zone model and a CPD test matrix that covers thermal, cargo, and seat-configuration variants. Publish measured false-alarm rates under a defined protocol — procurement teams are starting to ask for exactly this.

For fleet and aftermarket integrators: if retrofitting CPD to existing vehicles, BLE CS is the pragmatic path because it reuses the 2.4 GHz infrastructure already present in telematics units. But do not market it as equivalent to a factory UWB system for vital-sign detection; the sensitivity gap is real. Position it as zone-occupancy and door-open alerting, and be honest about the detection envelope.

For security architects: implement the UWB/CS cross-check for digital key authorization now. It is inexpensive, it raises the relay-attack bar meaningfully, and the log data it produces is valuable for incident response. Require signed OTA for both radio stacks.

Bottom Line

UWB and BLE Channel Sounding are not a bake-off; they are a division of labor. UWB provides the secure, centimeter-class anchor for the digital key and the micro-motion sensitivity that makes credible child presence detection possible. BLE CS provides broad, low-power, low-incremental-cost zone occupancy that fills UWB's coverage gaps and corroborates its measurements. The fused architecture is the only one that credibly meets a high-tier CPD specification while also serving as a secure digital key platform — but it carries the longest integration schedule and a real standardization risk around CS calibration that must be managed explicitly. Specify the fusion API, demand cabin-specific multipath studies, keep the CS calibration field-updatable, and design the CPD escalation logic asymmetrically toward false alarms rather than missed detections. Those four decisions will matter more to the program outcome than the choice of radio vendor.

💬 Join the discussion on our forum: Share your thoughts or ask questions

From "Better Hearing" to "Connected Hearing": The Auracast Inflection Point

For decades, the hearing aid industry's innovation story was told in a narrow vocabulary: channels, compression strategies, feedback cancellation, receiver-in-canal versus behind-the-ear form factors, and battery chemistry. Those remain important, but they describe a product category optimized around amplifying the right sound. The Bluetooth SIG's Auracast broadcast audio initiative changes the question entirely. The question is no longer only "can this device make speech intelligible?" but "can this device join the audio fabric of a public space, a car cabin, a lecture hall, or a multi-screen home without a dedicated loop system, a proprietary streamer, or a smartphone in the middle?"

The commercial significance is straightforward: when all five major hearing aid manufacturers — Demant (Oticon), Sonova (Phonak), WS Audiology (Signia/Widex), GN Hearing (ReSound), and Starkey — ship Auracast-capable products, the feature stops being a differentiator and becomes table stakes. That transition is the moment buyers should start paying attention, because it forces every vendor to compete on implementation quality, battery behavior, assistive-listening ecosystem support, and real-world usability rather than on a checkbox.

This article is written for the practical evaluator: the audiologist specifying a fitting, the procurement lead equipping a venue, the embedded developer integrating LE Audio, and the informed consumer comparing quotes. It focuses on what is verifiable in the Bluetooth specifications, what is observable in field use, and where the genuine trade-offs lie.

What Auracast Actually Is (and What It Is Not)

Auracast is the Bluetooth SIG's consumer-facing brand for broadcast audio built on the LE Audio architecture. Technically, the broadcast path is defined by the Basic Audio Profile (BAP) broadcast procedures, coordinated by the Common Audio Profile (CAP), which "specifies procedures to start, update, and stop unicast and broadcast Audio Streams on individual or groups of devices using procedures in the Basic Audio Profile (BAP)." CAP v1.0.1, adopted by the Bluetooth SIG Board of Directors on 2025-02-11, is the profile that lets a source and a set of sinks agree on how a broadcast stream is started, updated, and stopped, and it also references the Common Audio Service (CAS) and the volume/microphone control profiles (VCP, MICP) used to manage groups of devices.

The discovery and joining side is handled by the Broadcast Audio Scan Service (BASS). Per the specification, BASS "is used by servers to expose their status with respect to synchronization to broadcast Audio Streams and associated data, including Broadcast_Codes used to decrypt encrypted broadcast Audio Streams." In plain terms: a hearing aid (or earbud, or phone acting as an assistant) can act as a BASS server and tell a client — typically a phone or a remote control — which broadcast it is synchronized to, and provide the Broadcast_Code needed to decrypt an encrypted stream. The client can also "observe and/or request changes in server behavior," which is how a phone app can steer a hearing aid from one Auracast stream to another.

This architecture matters for evaluation because it separates three capabilities that buyers routinely conflate:

• Broadcast reception — the hearing aid itself can synchronize to and decode an Auracast stream (BAP broadcast sink role).
• Broadcast assistance — a phone or accessory can scan for broadcasts, obtain Broadcast_Codes via BASS, and hand the stream to the hearing aid. This is often how encrypted venues are joined.
• Broadcast transmission — a device can originate a stream (BAP broadcast source). Hearing aids almost never do this; venues, TVs, and phones do.

What Auracast is not: it is not a replacement for telecoil in every jurisdiction, it is not guaranteed to work with every "Auracast-ready" logo you see on a venue door, and it is not a single global standard for encryption key distribution. Those gaps are where real-world evaluation gets interesting.

The Five-Maker Landscape: What "Support" Means in Practice

Announcing Auracast support and shipping a robust implementation are different things. Across the Big Five, the pattern has been: flagship RIC and custom products get LE Audio/Auracast first, followed by a firmware or app update cycle, with the phone ecosystem determining when the feature is actually usable. The practical evaluation criteria are consistent regardless of brand:

• Firmware maturity: Does the shipping firmware include broadcast sink support, or is it "coming soon"? Ask for the exact firmware version and the release note that lists Auracast.
• Phone dependency: Can the aid join an unencrypted broadcast directly via its own controls, or does it require the vendor app and a compatible phone?
• Encrypted venue support: Does the app implement BASS client behavior to retrieve Broadcast_Codes, and is the venue's key distribution compatible?
• Multi-stream handling: Can the aid hold a unicast connection (phone call, TV streamer) while a broadcast is available, and how does it arbitrate?
• Battery impact: Broadcast reception is a continuous radio + DSP load. Measure it, don't trust the datasheet.

Because vendor roadmaps shift, the responsible approach for a buyer is to demand a demonstration in the actual venue or a simulated one, with the actual phone the user owns. A feature that works only on a flagship Android phone with a specific OS build is not the same product as one that works on the user's three-year-old handset.

Scenario 1: Public Spaces — Airports, Stations, Theatres, Places of Worship

This is Auracast's headline promise: walk into a space, see the broadcast in a list, tap once, and hear the announcement or the stage feed directly in your aids at your own volume and EQ. The technical enablers are BAP broadcast and BASS-assisted joining. The practical enablers are venue infrastructure and signage.

What to test. In a large hall, evaluate:

• Discovery latency: time from opening the broadcast list to the stream appearing. Good implementations surface streams in a few seconds; poor ones require a manual rescan and can miss low-duty-cycle advertisers.
• Join time: time from selection to audible audio. Expect a few seconds for synchronization and codec setup; anything approaching ten seconds feels broken in a live announcement context.
• Range and robustness: walk to the back of the hall and into the lobby. Broadcast uses periodic advertising and an isochronous stream; range is broadly comparable to other 2.4 GHz LE links but is sensitive to body shielding and venue RF congestion.
• Volume independence: confirm the user's volume control affects only their aids, not the venue feed. CAP's group volume procedures (via VCP) are designed for this, but implementation quality varies.
• Encryption handling: in venues that encrypt, confirm the app retrieves and applies Broadcast_Codes without exposing them in logs or requiring manual entry.

Venue-side reality check. A venue that advertises "Auracast available" must have a transmitter, an antenna plan, and a key-management policy. Ask three questions before trusting the signage: Is the stream encrypted? How does a user obtain the code (app, QR code, front desk)? Is there a fallback (telecoil loop, FM, or a loaner receiver) for users whose aids lack the feature or whose phones are incompatible? The last question is the one that separates accessibility compliance from marketing.

Scenario 2: The Car Cabin — An Automotive Angle That Actually Matters

The automotive category is where Auracast's business case is most underappreciated. Modern vehicles already contain multiple audio zones: front and rear infotainment, rear-seat entertainment, navigation prompts, and increasingly, passenger-specific media. Today, hearing aid users in a car typically face a choice between streaming everything through a single phone connection (which mixes navigation, calls, and media) or relying on cabin acoustics (which reintroduces the exact problems the aids were fitted to solve).

Auracast offers a cleaner model: the vehicle's infotainment head unit or a rear-seat entertainment module acts as a broadcast source, and each passenger's aids join the stream they want. Passengers with normal hearing use the speakers or their own headphones; hearing aid users join the broadcast directly. This is a genuine accessibility improvement, not a gimmick, because it decouples the hearing aid user's audio from the cabin's single mix.

Evaluation points for automotive integration:

• Source role support: confirm the head unit implements BAP broadcast source and CAP procedures, not merely a proprietary "hearing aid" mode.
• Latency budget: broadcast audio has an inherent latency. For media playback this is tolerable; for lip-synced rear-seat video it must be managed. Ask for the measured end-to-end latency and whether the source compensates video timing.
• Multi-zone isolation: verify that two passengers can join two different broadcasts without crosstalk, and that joining a broadcast does not mute the cabin speakers for everyone else.
• Power and thermal: continuous broadcast transmission in a parked vehicle is a real 12V load; confirm the vehicle manages it with ignition state.
• Pairing and re-join behavior: the best implementations remember a passenger's aids and re-join automatically on the next trip; the worst require a full scan every time.

For fleet buyers — shuttle services, accessible transport, ride-hail — the procurement question is whether the vehicle's audio system exposes a standards-based broadcast rather than a vendor-specific app. Standards-based is the only version that survives a mixed fleet of hearing aid brands, which is exactly the situation every operator faces.

Scenario 3: Multi-Device and Multi-User Listening at Home

Auracast's second commercial pillar is multi-device connectivity. The classic pain point: a hearing aid user wants TV audio, a phone call, and a tablet video, and the aids can hold only a limited number of unicast links. Broadcast changes the topology. A TV or a small transmitter can broadcast; any number of aids and earbuds can join; the phone remains available for calls.

What good looks like:

• TV as broadcast source: the TV or a set-top transmitter advertises a stream; the aids join without a dedicated streamer box. This removes a device, a power supply, and a pairing ritual from the user's life.
• Simultaneous unicast + broadcast: an incoming call should pre-empt or duck the broadcast cleanly, then return. Test this explicitly — it is the most common failure mode.
• Multi-user: two hearing aid users (or a user plus a partner with earbuds) join the same TV broadcast at independent volumes. This is a strong selling point for couples where one partner has hearing loss.
• Privacy: an unencrypted home broadcast is receivable by anyone in range. For a house, that is usually acceptable; for an apartment building, consider encryption and Broadcast_Code management via the app.

Software and Hardware Comparison: Where the Differences Hide

Because all five makers now support Auracast, the comparison shifts to implementation. The table below is a framework for evaluation rather than a brand ranking; fill it in with the specific models and firmware you are considering.

• Radio and antenna: LE Audio broadcast reception is a continuous load. Devices with well-tuned antennas and efficient radio scheduling show materially better battery life and range. Ask for measured current draw during broadcast reception, not just "up to" battery figures.
• DSP headroom: broadcast audio arrives as an LC3 stream; the aid must decode, apply gain and compression, and mix with any alert sounds. Devices with limited DSP headroom may degrade sound quality or drop features when a broadcast is active.
• Firmware update path: can the aid be updated over the air, or does it require a clinic visit? Auracast is a moving target (CAP and BASS were both revised to v1.0.1 in February 2025), so updateability is a long-term value factor.
• App quality: the phone app is the BASS client in most deployments. Evaluate scan reliability, stream naming, code entry, and error messages. A cryptic "connection failed" is an accessibility failure.
• Ecosystem breadth: does the maker's accessory line (TV streamers, remote mics) also support Auracast, or only proprietary protocols? Mixed support creates user confusion.

Performance Benchmarks You Can Actually Run

Vendor datasheets are not a substitute for measurement. The following benchmarks are reproducible with modest equipment and are the ones that predict satisfaction:

• Join latency: stopwatch from stream selection to first audible syllable, repeated ten times in the same location. Report median and worst case.
• Battery delta: full charge, then four hours of broadcast reception at typical volume versus four hours of quiet. The delta is the real cost of the feature.
• Range walk: in a venue, measure the distance at which dropouts begin, both line-of-sight and through a crowd. Repeat with the phone in a pocket versus in hand.
• Coexistence: with a phone call active and a broadcast joined, measure how quickly the call is answered and how cleanly audio returns afterward.
• Encrypted join: time to join an encrypted stream including code retrieval, and whether the code persists across sessions.
• Multi-user: two aids plus two earbuds on one broadcast; check for independent volume and no crosstalk.

For developers, the conformance angle is equally practical: CAP v1.0.1 and BASS v1.0.1 define the procedures and the attribute behavior. If your product claims Auracast support, your BASS server or client behavior should be testable against those specifications, and your broadcast source should follow BAP broadcast procedures. The Bluetooth Qualification Process is the mechanism that keeps the ecosystem interoperable; skipping it is how "works with my phone" becomes "doesn't work with yours."

Buying Guide: A Decision Framework

If you are a consumer replacing aids in the next 12 months: prioritize Auracast support, but verify it in person. Bring your own phone, ask the clinic to demonstrate joining a broadcast, and confirm the firmware version. Treat "Auracast-ready" without a working demo as a future promise, not a feature. If you frequently attend venues with loops, keep telecoil as a fallback — Auracast coverage is growing but not universal.

If you are an audiologist: add a broadcast test to your fitting protocol. Use a clinic transmitter or a phone-based source to verify join behavior, volume independence, and call pre-emption. Document the firmware version you validated so that a later update does not silently regress the feature. Counsel patients on the difference between direct join and app-assisted join, because that difference determines whether they can use the feature independently.

If you are a venue operator: specify standards-based Auracast, not a proprietary "assistive listening" mode. Require encryption with a documented code-distribution method, a fallback system, and signage that explains how to join. Budget for an RF survey; a single transmitter in a concrete hall is not a plan.

If you are an automotive OEM or Tier 1: treat broadcast source support as an accessibility requirement, not a premium audio feature. Define latency budgets for video sync, multi-zone isolation, and re-join behavior in the requirements document. Test with aids from more than one manufacturer — interoperability is the whole point.

Risks and Open Questions

Three risks deserve honest treatment. First, the phone bottleneck: many joining workflows depend on a companion app, and app quality varies. A user who cannot operate the app is locked out of encrypted venues. Second, encryption key distribution: BASS defines how Broadcast_Codes are exposed, but not how a venue tells a user the code. QR codes, front-desk scripts, and app integrations are all in use; there is no universal convention yet. Third, the "ready" label: marketing language outpaces firmware. The only defense is a demonstration with the user's own devices.

None of these undermine the direction of travel. They simply define the diligence a serious buyer should apply.

Bottom Line

The Big Five embracing Auracast is the moment hearing aids stop being a closed amplification system and become participants in a standards-based audio ecosystem. For users, the payoff is concrete: direct access to public-space audio, a cleaner multi-device topology at home, and a credible path to in-car audio that respects individual hearing needs. For the industry, the payoff is a shift in competition from proprietary lock-in to implementation quality — battery efficiency, join latency, encryption handling, and interoperability.

The practical recommendation is uniform across roles: demand a demonstration, measure the benchmarks that matter, and insist on standards conformance rather than logo compliance. Auracast is a genuine accessibility advance; the work now is making the shipped experience match the specification.

💬 Join the discussion on our forum: Share your thoughts or ask questions

Securing Automotive Ethernet: A Survey of In-Vehicle Protocol Threats and Defense Mechanisms from CAN to 5G

The modern vehicle has stopped being a closed electromechanical system. A mid-range 2024 model typically carries 60–120 electronic control units (ECUs), several gateway domains, a telematics unit with cellular connectivity, and a growing number of wireless entry points. The attack surface now spans legacy buses (CAN, LIN, FlexRay, MOST), a backbone that is increasingly switched Automotive Ethernet, and external interfaces such as USB, Bluetooth Classic/BLE, Wi-Fi, and 5G. The commercial stakes are concrete: a single unpatched gateway vulnerability can trigger a recall covering hundreds of thousands of vehicles, and the UN R155/R156 regulatory framework now makes a cybersecurity management system (CSMS) a condition of type approval in the EU.

This article is written for engineers and product decision-makers who need to evaluate security architectures, not for readers who want a generic introduction to the topic. We focus on what is practically exploitable, what mitigations actually cost in latency and BOM, and how competing approaches compare. Automotive Ethernet occupies the center of the discussion because its best-effort, switched nature changes the threat model fundamentally compared with the broadcast, deterministic CAN bus it replaces.

1. Why the Bus Topology Determines the Threat Model

The security posture of an in-vehicle network is largely a function of its physical and logical topology. Legacy buses are broadcast media: every node sees every frame, and arbitration is by identifier priority, not by sender identity. Ethernet is switched and point-to-point, with MAC addressing, VLANs, and IP routing. This shift matters for three reasons.

• Observability: On CAN, any compromised node passively receives all traffic on its bus. On a switched Ethernet backbone, a compromised ECU sees only traffic routed to it unless it performs VLAN hopping, MAC flooding, or ARP/NDP spoofing.
• Determinism: CAN provides bounded worst-case latency through priority arbitration. Standard Ethernet is best-effort, which is why TSN (IEEE 802.1Qbv/802.1Qav) and Audio Video Bridging extensions exist. Security controls that add processing delay directly threaten timing budgets on safety-critical paths.
• Blast radius: A CAN bus is a single collision domain; a fault or attack propagates to every node instantly. A switched backbone allows segmentation (zones), but a misconfigured switch or gateway becomes a single point of failure that bridges zones.

The practical consequence is that defense-in-depth must be layered per domain, and the gateway between domains is the highest-value target in the vehicle. Any security evaluation that does not start at the central gateway and the telematics ECU is misallocated.

2. Threat Survey by Protocol

2.1 CAN and CAN FD

CAN remains the workhorse for powertrain, chassis, and body domains. Its known weaknesses are well documented and still relevant:

• No authentication or encryption. Any node can inject frames with any identifier. A classic demonstration is injecting a forged frame with a high-priority ID to override a legitimate command.
• No sender identity. The identifier denotes message content, not origin, so spoofing and replay are trivial once an attacker has bus access.
• Bus-off attacks. Deliberately transmitting error frames can force a target ECU into bus-off state, causing denial of service on safety functions.
• Physical access. The OBD-II port exposes CAN directly. Diagnostic sessions (UDS over ISO-TP) are a common entry vector, and security access seeds are sometimes weak or static across a fleet.

CAN FD increases payload to 64 bytes and improves throughput, which helps security because it enables message authentication codes (MACs) to be carried in-frame. The trade-off is bandwidth: a 4-byte truncated MAC plus a freshness counter consumes a meaningful fraction of an 8-byte classic CAN frame, which is why authentication on classic CAN is usually limited to safety-critical IDs and uses truncated MACs with counter-based freshness.

2.2 LIN, FlexRay, and MOST

LIN is a single-wire, low-speed bus for actuators and sensors (mirrors, seats, climate flaps). It has no security mechanisms at all and is typically bridged to CAN through a LIN master ECU. Attacks on LIN are usually local (physical access to a harness) but can be used to manipulate sensor readings that feed higher-level functions. FlexRay offers 10 Mbit/s and time-triggered determinism for chassis and steer-by-wire applications; it has no native authentication, and its static and dynamic segments can be disrupted by a malicious node that transmits in the wrong slot. MOST (Media Oriented Systems Transport) is largely legacy infotainment; it is being displaced by Ethernet AVB/TSN, but vehicles in service still carry it, and its ring topology means a single compromised node can disrupt the whole ring.

2.3 Automotive Ethernet

Automotive Ethernet (100BASE-T1, 1000BASE-T1, and emerging 10GBASE-T1) is now the backbone for ADAS sensor fusion, infotainment, and OTA updates. Its switched nature gives defenders new tools (VLANs, ACLs, port security) but also introduces Ethernet-specific attack classes that do not exist on CAN:

• ARP/NDP spoofing and MAC flooding: a compromised ECU can poison neighbor caches to intercept traffic between zones, or flood the switch's MAC table to force fallback to hub-like flooding behavior.
• VLAN hopping: misconfigured trunk ports allow an attacker to reach zones that should be isolated (e.g., from infotainment into the chassis domain).
• DoS via broadcast/multicast storms: best-effort Ethernet has no inherent congestion control at layer 2; a storm can starve time-critical TSN traffic if priority scheduling is not enforced correctly.
• Timing attacks on TSN: manipulation of gPTP (IEEE 802.1AS) synchronization can shift time gates and disrupt scheduled traffic, which is a safety issue as much as a security one.
• Protocol stack vulnerabilities: the IP stack (TCP/IP, SOME/IP, DoIP, DDS) introduces the same class of memory-safety and parsing bugs found in IT systems, now on a safety-critical network.

This is the core reliability-and-security tension the survey highlights: Ethernet's best-effort delivery means a security control that drops or delays packets can break a safety function, and a switch that prioritizes availability over integrity can be exploited to cause exactly the timing failures TSN was designed to prevent. Defenders must therefore treat bandwidth, latency, and jitter budgets as security constraints, not just performance targets.

2.4 External Interfaces: USB, Bluetooth, Wi-Fi, 5G

External interfaces are the most exposed part of the vehicle because they are reachable without physical disassembly.

• USB: media ports in the head unit parse filesystem images and media codecs. Malformed files or USB descriptor abuse have historically been a route into the infotainment OS. Mitigation is strict input validation, sandboxing of the media stack, and disabling USB data (charging-only) when not needed.
• Bluetooth: pairing, key exchange, and profile implementations (HFP, A2DP, PBAP) are a large attack surface. BLE adds GATT-based services that must be authenticated. The Bluetooth Core Specification 6.2 adds Channel Sounding Amplitude-based Attack Resilience, which is directly relevant to secure ranging in digital key and passive entry systems — an attacker attempting to amplify or relay ranging signals is now addressed at the specification level. Version 6.2 also introduces Shorter Connection Intervals, which reduces the latency window available to a relay attacker, and HCI USB LE Isochronous Support plus LE Test Mode Enhancements, which matter for validating LE Audio and for RF conformance testing of security-relevant timing behavior. For product teams, the practical takeaway is that digital-key and phone-as-a-key designs should target Core 6.2-capable controllers rather than retrofitting relay mitigation in application software.
• Wi-Fi: in-vehicle hotspots and Wi-Fi-based OTA create a large layer-2/3 surface. WPA3 and proper network isolation between the hotspot and the vehicle's internal zones are baseline requirements.
• 5G: the telematics unit (TCU) is the primary remote attack path. Threats include SIM/eSIM compromise, misconfigured APNs exposing internal services, and vulnerabilities in the cellular modem's baseband or its IP stack. The 5G network itself provides strong subscriber authentication, but the vehicle-side trust boundary is the TCU's firewall and the OTA client's signature verification, not the radio link.

3. Defense Mechanisms and Their Practical Costs

Security controls on in-vehicle networks fall into four layers: network segmentation, message authentication, intrusion detection, and secure update/identity management. Each has measurable cost in latency, bandwidth, and BOM, and the right mix depends on the domain.

3.1 Segmentation and Gateways

Domain/zonal architecture with a central gateway and Ethernet backbone is the dominant 2024–2026 design. Practical recommendations:

• Enforce VLAN separation between infotainment, telematics, ADAS, and chassis domains, with default-deny ACLs on the gateway.
• Disable unused switch ports and lock MAC learning on access ports (port security) to blunt MAC flooding.
• Use a firewall with deep packet inspection for SOME/IP and DoIP at the central gateway; this is where most commercial IDS/IPS products (e.g., from automotive cybersecurity vendors) are deployed.
• Keep the OBD-II diagnostic path behind an authentication gateway (gateway-level security access), not directly bridged to powertrain CAN.

Benchmark note: an inline gateway firewall performing SOME/IP DPI typically adds tens to low hundreds of microseconds per frame depending on rule complexity and hardware acceleration. On a 100BASE-T1 link carrying ADAS sensor fusion traffic, this must be validated against the end-to-end latency budget (often single-digit milliseconds for safety functions). Hardware offload or a dedicated security MCU is usually required to keep jitter within TSN bounds.

3.2 Message Authentication (SecOC and MACsec)

On CAN/CAN FD, AUTOSAR SecOC provides per-PDU authentication using a truncated MAC and a freshness counter. On Ethernet, IEEE 802.1AE MACsec provides hop-by-hop link encryption and integrity at layer 2, and IPsec/TLS protect end-to-end flows above it.

• SecOC on classic CAN: feasible for a limited set of critical IDs. A 24–32-bit truncated MAC plus a 4–8-bit freshness counter is a common compromise. Full authentication of all traffic is not bandwidth-feasible on classic CAN.
• SecOC on CAN FD: much more practical; 64-byte payloads allow stronger MACs and larger counters, at the cost of payload capacity for application data.
• MACsec on Ethernet: line-rate integrity and confidentiality with hardware support, but it is hop-by-hop — every switch must terminate and re-originate, so trust in intermediate switches is required. For end-to-end protection across zones, combine MACsec at layer 2 with TLS/IPsec for application flows (e.g., OTA, diagnostics).

Commercial trade-off: MACsec-capable automotive switches carry a BOM premium and require key management infrastructure (MKA, 802.1X). For many OEMs the pragmatic path is MACsec on the backbone and SecOC on the CAN domains behind the gateway, rather than attempting uniform end-to-end authentication.

3.3 Intrusion Detection and Prevention (IDS/IPS)

Host-based IDS on ECUs (monitoring CAN traffic for unexpected IDs, frequency anomalies, and payload ranges) and network-based IDS at the gateway are now standard in production programs driven by UN R155. Practical evaluation criteria:

• Detection latency: host-based CAN IDS typically detect anomalies within a few frames; network IDS at the gateway adds the forwarding path latency. For bus-off and DoS attacks, detection must be fast enough to trigger mitigation before safety functions degrade.
• False positive rate: rule-based IDS on CAN produces false positives when legitimate traffic patterns change (diagnostics, OTA, mode transitions). ML-based approaches reduce this but require fleet data and careful validation; they are harder to certify.
• Response actions: detection without a response (rate limiting, quarantine of a zone, logging to a secure element) has limited value. Define the response policy per attack class.

3.4 Secure Boot, Key Management, and OTA

Hardware root of trust (HSM or secure element) with secure boot, signed firmware, and per-vehicle key provisioning is the foundation. OTA update pipelines must verify signatures end-to-end and support rollback protection. The TCU's cellular link is the highest-risk path, so the OTA client should verify signatures independently of the transport and never trust the 5G network as an authentication boundary.

4. Comparison: Legacy Bus vs. Ethernet Security Posture

The following table summarizes the practical security comparison for engineering and procurement decisions. Entries reflect commonly deployed mechanisms, not theoretical maxima.

• CAN/CAN FD: Native security — none. Practical controls — SecOC (partial), gateway filtering, host IDS. Latency cost — low to moderate. Key weakness — broadcast, no identity.
• LIN: Native security — none. Practical controls — physical protection, master-side validation. Latency cost — negligible. Key weakness — fully trusted local bus.
• FlexRay: Native security — none. Practical controls — schedule monitoring, gateway isolation. Latency cost — low. Key weakness — time-slot disruption.
• MOST: Native security — none. Practical controls — ring isolation, replacement with Ethernet. Latency cost — N/A. Key weakness — legacy, limited tooling.
• Automotive Ethernet: Native security — MACsec, VLANs, ACLs, 802.1X. Practical controls — gateway DPI, TSN-aware firewalls, IDS. Latency cost — moderate (hardware offload required). Key weakness — best-effort timing, IP stack exposure.
• Bluetooth/BLE: Native security — pairing, LE Secure Connections; Core 6.2 adds Channel Sounding amplitude attack resilience and shorter connection intervals. Practical controls — authenticated GATT, ranging validation. Key weakness — relay attacks on passive entry.
• Wi-Fi: Native security — WPA3. Practical controls — network isolation, hotspot segmentation. Key weakness — large L2/L3 surface.
• 5G: Native security — strong subscriber auth, encrypted air interface. Practical controls — TCU firewall, OTA signature verification, APN isolation. Key weakness — TCU and modem stack as trust boundary.

5. Real-World Scenarios and What They Reveal

Scenario A — OBD-II dongle compromise. A third-party insurance dongle plugged into OBD-II bridges CAN to a cellular modem. If the dongle's firmware is unsigned and its diagnostic access is not gated, it becomes a remote CAN injection path. Mitigation: gateway-level diagnostic authentication and restricting OBD-II to a filtered, rate-limited diagnostic VLAN.

Scenario B — Infotainment to chassis lateral movement. A malicious media file exploits the head unit's codec stack. If the head unit shares a VLAN with the chassis domain or the gateway ACLs are permissive, the attacker can reach safety-critical ECUs. Mitigation: strict VLAN separation, default-deny gateway ACLs, and sandboxing of the media stack.

Scenario C — Digital key relay attack. An attacker relays BLE ranging signals between the phone and the vehicle to unlock and start it. Core 6.2's Channel Sounding amplitude-based attack resilience and shorter connection intervals directly reduce this window, but the vehicle-side implementation must actually enable and validate these features, and the phone must support them. Procurement should require evidence of ranging validation testing, not just spec compliance.

Scenario D — OTA supply-chain compromise. A signed but malicious update is pushed through a compromised build server. Mitigation: multi-party signing, reproducible builds, and staged rollout with rollback. The 5G link is not the weak point here; the signing pipeline is.

6. Actionable Recommendations

• Start at the gateway. Treat the central gateway and TCU as the primary trust boundaries. Deploy DPI-capable firewalls with default-deny ACLs and validate latency against TSN budgets with hardware offload.
• Segment by domain, not by convenience. VLANs between infotainment, telematics, ADAS, and chassis; disable unused ports; enforce port security.
• Authenticate selectively. SecOC on the highest-risk CAN IDs and on CAN FD where bandwidth allows; MACsec on the Ethernet backbone; TLS/IPsec for OTA and diagnostics.
• Deploy IDS with a response policy. Host-based CAN IDS plus gateway network IDS, with defined quarantine/rate-limit actions and logging to a secure element.
• Harden external interfaces. Charging-only USB by default, authenticated GATT for BLE services, WPA3 and hotspot isolation for Wi-Fi, and a hardened TCU firewall for 5G.
• Target current Bluetooth Core for digital key. Specify Core 6.2-capable controllers to obtain Channel Sounding amplitude attack resilience and shorter connection intervals, and require ranging validation test evidence from suppliers.
• Build the CSMS around UN R155/R156. Threat analysis and risk assessment per domain, documented mitigations, and a monitored incident response process are now procurement and type-approval requirements, not optional extras.

7. Buying and Evaluation Guide

For OEMs and Tier-1s evaluating security solutions, the following criteria separate credible products from marketing claims:

• Latency evidence: demand measured per-frame latency and jitter for gateway firewall and IDS functions at line rate on 100BASE-T1 and 1000BASE-T1, not just throughput numbers.
• Certification readiness: ISO/SAE 21434 process compliance and UN R155 CSMS evidence from the supplier.
• Key management: HSM-backed provisioning, secure boot, and rollback protection demonstrated end-to-end, including the OTA signing pipeline.
• Standards currency: for wireless components, confirm support for Bluetooth Core 6.2 features where digital key or ranging is in scope; for Ethernet, confirm TSN and MACsec hardware support with 802.1X/MKA.
• Fleet operability: IDS tuning workflow, false-positive management, and OTA remediation path across the vehicle lifetime.

The bottom line: Automotive Ethernet gives defenders better tools than CAN ever could, but its best-effort nature means every security control must be validated against timing budgets, and the highest-value investments remain the gateway, the TCU, and the OTA signing pipeline. Protocol-level features such as Bluetooth Core 6.2's ranging attack resilience help, but only if the product actually implements and tests them.

💬 Join the discussion on our forum: Share your thoughts or ask questions