This post opens the series on the AUTOSAR module AUTOSAR_CP_SWS_IEEE1722Transport
and is aimed at anyone already familiar with the existing
EthSwt/EthTrcv series who
now wants to understand what AVTP streaming over a TSN Ethernet backbone
actually means.
The full IEEE 1722-2025 text is paywalled (IEEE Standards Store) and not freely accessible. As a reliable, freely available secondary source, this series relies on COVESA/Open1722 — a BSD-licensed open-source reference implementation that explicitly cites concrete tables from the standard in its README. |
What is AVTP?
AVTP (Audio Video Transport Protocol) is the core protocol from IEEE 1722 — originally developed for professional audio/video streaming over Ethernet (the AVB/TSN space), but now also relevant as a transport mechanism for field-bus tunneling (ACF, see Part 2 of this series) in an automotive context.
The basic idea: instead of transmitting audio, video, or sensor data over classic IP-based protocols, AVTP defines a lean frame format sitting on top of Layer 2, with a built-in timestamp — exactly what’s needed for deterministic, low-latency transmission on a TSN network.
AVTP isn’t a replacement for TSN itself, it builds on TSN mechanisms. Stream identification (covered in the EthSwt series) and time-aware shaping/frame preemption (also covered there) are what make sure an AVTP stream is actually forwarded deterministically by the switch — AVTP itself only defines the frame format and the timestamp mechanism on the sender/receiver side. |
AVTPDU formats at a glance
All AVTP packets (AVTPDUs — AVTP Data Units) share a common header, but differ in the payload format that follows:
| Format | Purpose |
|---|---|
AAF (Audio AVTP Format) | Uncompressed audio samples (PCM), e.g. for microphone/speaker streams in the vehicle |
CRF (Clock Reference Format) | Distributes a clock reference between sender and receiver — important when audio/video streams need to run in sync with each other but don’t share a common hardware clock |
IIDC (61883_IIDC — IEC 61883/IIDC over AVTP) | Video data using IEC 61883/IIDC encapsulation, e.g. for camera streams (rear-view camera, surround view) |
RVF (Raw Video Format) | Uncompressed raw video data — a different encapsulation than IIDC, without compression latency and artifacts |
The AUTOSAR module |
For an automotive project, IIDC (camera streams) and AAF (audio) are the
formats most commonly relevant in practice. CRF is usually resolved
implicitly via the |
Another AVTPDU format that’s especially relevant for automotive applications, but doesn’t fall into these four categories, is ACF (AVTP Control Format) — the mechanism for tunneling field-bus data (CAN, CAN-XL, FlexRay, LIN, MOST) over a TSN backbone. ACF gets its own dedicated section in Part 2 of this series.
Native Ethernet framing vs. optional UDP encapsulation
AVTPDUs can be transported in two ways:
| Native (EtherType 0x22F0) | UDP encapsulation | |
|---|---|---|
Overhead | Minimal — just Ethernet header + AVTPDU | Additional IP and UDP headers |
Routability | Only within the same L2 segment | Routable across IP networks |
Determinism | Directly benefits from TSN mechanisms (stream identification, time-aware shaping) | TSN guarantees are lost at an L3 boundary, unless the IP network itself is TSN-capable |
Typical use | Within a TSN backbone (the normal case in the vehicle) | When a stream needs to cross a routed boundary (e.g. toward a diagnostic tester outside the vehicle) |
Within a vehicle’s TSN backbone, native framing is the normal case — UDP encapsulation shouldn’t be chosen by default just because it "seems more flexible." Every additional encapsulation layer costs determinism that the upstream TSN mechanisms just built up. |
Interaction with TSN
AVTP streaming only works reliably in interaction with the TSN mechanisms already covered in the EthSwt series:
| Mechanism | Role for AVTP |
|---|---|
Maps an AVTP stream (identified via the | |
Reserves time slots in the switch during which the AVTP stream is guaranteed to be forwarded — the actual mechanism behind "deterministic" delivery |
Without these two TSN building blocks, AVTP remains a pure frame format with no real-time guarantee — the actual determinism promise comes from the switch, not from the AVTPDU header itself.
Overview of the series
This post lays the foundation. The following parts build on it:
| Part | Topic |
|---|---|
1 (this post) | Fundamentals — what AVTP is, AVTPDU formats, native framing vs. UDP, interaction with TSN |
ACF_CAN and ACF_LIN in the AUTOSAR module | |
Container structure of the | |
Tunneling a camera stream (IIDC) and a CAN subnet via ACF.CAN over a TSN backbone — followable with Open1722 | |
5 — Hands-on project: ACF-CAN kernel module between two real BeagleBone Black | Cross-compiling and loading the Open1722 ACF-CAN kernel module, and testing it between two physical BeagleBone Black boards over Ethernet |
Summary
| Aspect | Key takeaway |
|---|---|
AVTP | A lean, Layer-2-based frame format with a built-in timestamp for deterministic audio/video/sensor streaming |
AVTPDU formats | AAF (audio), CRF (clock reference), IIDC (video), RVF (raw video) — plus ACF as its own subtype for field-bus tunneling (Part 2) |
Framing | Native Ethernet framing (EtherType 0x22F0) is the normal case on a vehicle backbone, UDP encapsulation only when routing across IP boundaries is needed |
Interaction with TSN | Stream identification and time-aware shaping deliver the actual determinism guarantee — AVTP only defines the frame format |
Next step | Part 2 covers ACF in detail — the mechanism for tunneling CAN/LIN (in the AUTOSAR module) or additional field buses (in the general standard) over the same TSN backbone |
Next in the series: IEEE 1722 Part 2 — ACF (AVTP Control Format)