Software-Defined Vehicles (SDVs) are reshaping the automotive industry, delivering safer, greener, and more engaging self-driving experiences. Ethernet-based in-vehicle networks (IVNs) provides the connectivity, security, scalability, and control SDVs require, enabling over-the-air (OTA) updates that continually enhance vehicle utility and the driving experience, while unlocking new, recurring revenue streams for OEMs.

Ethernet End-to-End: The Automotive Backbone of SDVs

Ethernet has evolved over decades to meet real-world networking demands, accumulating a rich set of standards and features that address performance, reliability, and security, ranging from precise time synchronization and deterministic scheduling to robust access control and encryption. As the automotive industry began adopting Ethernet around 2014, propelled by single-pair automotive Ethernet (e.g., 100BASE‑T1 and 1000BASE‑T1) that reduces cabling weight and cost while boosting bandwidth, it quickly became the dominant in-vehicle backbone for high-data-rate functions like ADAS, perception, and infotainment. Modern automotive Ethernet leverages Time-Sensitive Networking (TSN) to guarantee bounded latency, supports service-oriented communication and diagnostics, and integrates security mechanisms such as MACsec and 802.1X to help mitigate cyber threats and comply with emerging regulations.

When every in-vehicle device - processors, controllers, actuators as well as sensors and cameras - communicates over Ethernet, the core promise of the SDV is realized: the ability to reprogram the network and adjust its key characteristics for advanced applications. We call this “Ethernet End-to-End.”

Ethernet attributes for SDV

Ethernet features enable four key attributes that are crucial for SDV: Flexibility, Scalability, Redundancy and Controllability.

  • Flexibility: Ethernet provides the ability to change data flow in the network and share devices (like cameras and sensors) between domains, processors and other shared resources (e.g., storage).
  • Scalability: This is related to both the software and hardware of the SDV. Software-driven feature updates often require reconfiguration in how data and control traffic are routed, which Ethernet switches can handle through simple configuration changes. Hardware can be also modified over time in the SDV, and in many cases, the network will often need adjustments to accommodate new link speeds and QoS requirements. These updates are straightforward with Ethernet-based architecture.
  • Redundancy: To meet functional safety requirements, redundancy must cover both mission-critical processors and the data paths between devices to protect the network. Ethernet’s switching and multipath capabilities enable path diversity as well as load balancing across the IVN backbone, delivering this redundancy through standardized hardware and protocols.
  • Controllability: Real-time diagnostics and link-level debugging enable continuous self-diagnosis and fault management - tracking channel quality, link margin/degradation, and EMC vulnerability - using Ethernet Operations, Administration, and Maintenance (OAM). With advanced AI/ML analytics, network health can be predicted more accurately, supporting higher safety goals and delivering significant economic benefits.

Cameras and the Ethernet Edge

As noted above, realizing the full capability of in‑vehicle SDN requires most devices in the car to be connected over Ethernet. In today’s advanced vehicle architectures, the high‑speed backbone is already Ethernet, but camera interfaces largely remain proprietary, point‑to‑point (P2P) links based on Low‑Voltage Differential Signaling (LVDS) physical layer technology. The two most common ones are GMSL (ADI) and FPD-Link (TI). Newer solutions, such as MIPI A‑PHY and ASA, are being developed, attempting to replace LVDS, yet they still operate as point‑to‑point solutions.

Cameras and the Ethernet Edge (Figure 1)

In Figure 1, we show an example of a typical zonal car network with the focus on the two domains that use camera sensors: ADAS and Infotainment (IVI). 
Cameras and the Ethernet Edge (Figure 1)

In Figure 1, we show an example of a typical zonal car network with the focus on the two domains that use camera sensors: ADAS and Infotainment (IVI). 
Cameras and the Ethernet Edge (Figure 1)

In Figure 1, we show an example of a typical zonal car network with the focus on the two domains that use camera sensors: ADAS and Infotainment (IVI). 

As the diagram shows, most ECUs, sensors, and other devices (marked as small white circles) connect to - and benefit from - the zonal Ethernet backbone. However, cameras still use direct point-to-point links into the SoC devices, using long cables. These P2P connections make it difficult to share camera streams across ADAS and IVI domains. In addition, the topology lacks scalability, and redundancy is weak: because cameras are directly connected to one processor, a fault in that processor can sever access to those camera feeds.

Automotive Ethernet camera bridge

The best way to overcome the limitations of point‑to‑point (P2P) camera links is to convert the video to Ethernet right at the camera. Why wasn’t Ethernet used from the start? Historically, ADAS cameras avoid compression to minimize latency and preserve image quality, which pushes very high raw data rates. For many years, those camera rates exceeded what in‑vehicle Ethernet could deliver, as show in the figure below, so OEMs relied on proprietary serializers like GMSL and FPD‑Link (LVDS). While LVDS‑based links typically scaled by about 2× each generation, Ethernet tends to jump by an order of magnitude, and with the arrival of Multi‑Gig automotive Ethernet PHYs (2.5, 5, and 10Gbs), Ethernet finally caught up. Looking ahead, Ethernet is moving to even higher speeds - up to 25 Gbps - for next‑generation cameras.

ETH-vs-LVDS-chart-Blog
ETH-vs-LVDS-chart-Blog
ETH-vs-LVDS-chart-Blog

With these Multi‑Gig PHYs, a new class of bridge devices can sit at the sensor, package the video using the IEEE 1722 audio/video standard, and carry it across the car’s Ethernet network with the right timing and quality. 

IEEE 1722

IEEE 1722 is a standard for sending time-sensitive audio and video over Ethernet so streams arrive when and where they should.

How IEEE 1722 works in this context:

  • For video, the camera bridge acts as an AVTP “talker,” and the ADAS or IVI SoCs are “listeners.” AVTP (Audio Video Transport Protocol), defined by IEEE 1722, is a Layer 2 transport for time-sensitive audio/video streams that standardizes payload format and timing over Ethernet
  • It segments each video frame into AVTP protocol data units carried in Ethernet frames, tagging them with a unique Stream ID and sequence numbers for identification and loss detection.
  • Each packet includes a presentation timestamp locked to the car’s clock (based on gPTP/IEEE 802.1AS), ensuring bounded latency and synchronized data with other sensors (radar, lidar, etc.) for accurate sensor fusion - critical for driver assistance.
  • QoS is applied via VLAN priority and Stream, optionally with TSN shaping/scheduling (e.g., 802.1Qav/Qbv) so video gets guaranteed bandwidth and priority.
  • Streams can be multicast to a group MAC address and, optionally using VLAN IDs, allowing multiple processors to subscribe to the same camera video without duplicating it at the source.
  • For safety, resilience features like redundant paths and Frame Replication and Elimination for Reliability (IEEE 802.1CB) keep video flowing if a link or switch fails.

In addition, IEEE 1722 supports Controls and GPIO signals from the SoC to the camera:

  • Using IEEE 1722.1, the computer discovers the camera bridge, reads its descriptors, establishes connections, and sends control commands (start/stop, exposure, gain, mode changes) alongside the video stream.
  • GPIO is mapped to control/event messages. Inputs and outputs can be time-stamped to the gPTP clock for precise, synchronized triggers across multiple cameras.
  • Control traffic is prioritized (and can use redundant paths/802.1CB) to ensure low-latency, reliable delivery even under load.

In short, IEEE 1722 lets camera video move across the car’s Ethernet network with the right timing, priority, and reliability, while IEEE 1722.1 provides simple, synchronized control and GPIO, enabling sharing across domains and robust redundancy. IEEE 1722 also includes provisions for radar-over-Ethernet, including support for SPI-based radar control.

As illustrated below, once camera or radar outputs are converted to Ethernet, they can connect to central switches or dedicated Ethernet aggregators, allowing streams to be shared across multiple SoCs. When it’s cost-effective, cameras and radars can instead be attached to zonal switches using short, lightweight cables.

IEEE 1722
IEEE 1722
IEEE 1722

But this is only the tip of the iceberg. Once the underlying technology for the camera interface is Ethernet, these links automatically gain access to all the other IEEE Ethernet standards, like:

  • Switching and virtualization - IEEE 802.1
  • Security – authentication and encryption – IEEE 802.1AE MACsec
  • Time-Synchronization over network – IEEE PTP 1588
  • Power over cable – IEEE PoDL 802.3bu
  • Audio/Video Bridging – IEEE 802.1 AVB/TSN
  • Asymmetrical transmission, using Energy Efficient Ethernet protocol – IEEE 802.3az
  • Support for all topologies: Mesh, star, ring, daisy-chain, point-to-point

In addition, when a camera outputs Ethernet, the camera vendor can leverage the existing Ethernet test infrastructure/houses – covering compliance, interoperability, EMC, and more – that has been proven and accepted by the automotive industry for many years.

Ethernet End-to-End

The next phase of Ethernet in the car, as shown in the next figure, is to bring all high-data-rate devices onto the network, including displays and central high-end compute units (SoCs). Future vehicles are expected to host two to five high‑resolution displays, which today often use proprietary point‑to‑point links such as LVDS. Migrating these displays to Ethernet allows them to benefit from the Ethernet capabilities discussed above (deterministic timing, QoS, security, diagnostics, and more) while reducing cost through a standards‑based, multi‑vendor ecosystem.

Ethernet End-to-End
Ethernet End-to-End
Ethernet End-to-End

A parallel trend accelerating Ethernet end‑to‑end is the emergence of SoCs with native, high‑speed Ethernet ports, scaling up to 25 Gbps, plus dedicated hardware engines to depacketize IEEE 1722 video streams. This offloads the CPU, lowers latency, and enables seamless, scalable media transport over the in-vehicle network.

Replacing MIPI CSI-2 with native 25G Ethernet ports on the SoC delivers several concrete advantages for performance, architecture, security, and scalability:

  • Consolidated bandwidth and fewer pins: A single 25G Ethernet port can aggregate multiple camera and radar streams, reducing high-speed lanes/pins, simplifying PCB/package, and eliminating external serializers over long reaches.
  • Shareable and scalable: Ethernet enables multicast so ADAS, IVI, and logging can use the same stream; adding or re‑routing cameras becomes a software task, not a board redesign.
  • Deterministic and low-overhead: gPTP/TSN provide tight timing. Hardware-based IEEE 1722 depacketization with DMA to ISP/GPU offloads the CPU and cuts latency.

Net result: Native 25G Ethernet makes the SoC a high-throughput, time-synchronized node in a programmable network, cutting pin count and PCB complexity while improving performance, resilience, and ease of adding and updating features over the vehicle’s lifetime.

Early multi-gigabit camera-to-Ethernet bridges used the symmetric single-pair PHYs defined in IEEE 802.3ch (e.g., 2.5/5/10GBASE‑T1). However, camera links are inherently asymmetric - high-rate video flowing from the camera to the SoC, with only low-rate control traffic in the reverse direction. To better match this traffic pattern and reduce PHY size and power, a new standard, IEEE 802.3dm, introduces asymmetrical single-pair Ethernet PHYs tailored for camera applications.

IEEE 802.3dm

IEEE 802.3dm focuses on bringing asymmetric single‑pair Ethernet PHYs to automotive, tailored for links where traffic predominantly flows in one direction -such as cameras and displays. 802.3dm targets higher downstream data rates from the sensor to the processor (in the case of camera), paired with a lower upstream rate for control and status. The goal is to deliver the bandwidth needed for high‑resolution, low‑latency video while cutting PHY power, silicon area, and cost by not over‑provisioning the return path.

Technically, 802.3dm builds on the existing 802.3 automotive and adapts it for asymmetric operation over a single balanced pair. It aims to preserve the behaviors system designers rely on: full‑duplex operation, automotive‑grade EMC robustness, deterministic latency compatible with TSN at Layer 2, and optional features such as Power over Data Line (PoDL). It also targets typical automotive reaches and harnesses of 15m, supporting both STP and coax cables. By matching link rates to actual traffic patterns, 802.3dm helps save power at the edge, simplifies thermal design, and enables smaller camera modules without sacrificing image quality or timing.

From a system perspective, standardizing asymmetric PHYs enables true Ethernet end‑to‑end architectures for vision: cameras and displays can plug into zonal or central switches, share streams with multiple ECUs, and take advantage of the broader Ethernet ecosystem (TSN for scheduling, MACsec for security, PTP for time sync, PoDL or power-over coax (PoC) for power). This reduces the need for proprietary serializers, lightens wiring, and fosters a multi‑vendor supply chain.

Current status: 802.3dm is an active IEEE 802.3 project under development, with objectives that include downstream speeds of 2.5G, 5G and 10Gbps, and upstream of 100Mbps. The task force is refining technical parameters and draft text through the normal IEEE process (proposal evaluation, draft creation, and balloting). Draft 2.0 and starting the ballot phase is planned for May 2026.

Summary

Converting camera links to Ethernet at the edge unlocks Ethernet End-to-End for SDVs: video and control are encapsulated with IEEE 1722/1722.1, making streams shareable across ADAS and IVI, precisely time-aligned via gPTP/TSN, secured with MACsec, and observable with mature OAM, while benefiting from established automotive Ethernet compliance and EMC test ecosystems. As native 10–25 Gbps Ethernet and IEEE 1722 offload become standard in SoCs, the network delivers simpler scaling through software rather than rewiring. The emergence of asymmetric single‑pair PHYs in IEEE 802.3dm further optimizes camera links for power, size, and cost by matching high downstream video with lightweight upstream control. Together, these advances replace proprietary point‑to‑point chains with a programmable, resilient, and standards‑based fabric - reducing wiring and BOM, boosting reliability and safety, and accelerating OTA feature delivery throughout the vehicle’s life.