基于车载以太网的音视频传输 AVB vs RTP

背景

问：近些年，随着智能驾驶技术的发展和车内影音娱乐系统的丰富，越来越多的音视频数据需要在车内网络进行传输。现在车载以太网日渐成熟，那么，我们可以使用车载以太网在车内网络传输音视频数据吗？

王师傅：答案是肯定的。而且由于成本、传输带宽等方面的因素，在有些场景下，也许只有车载以太网才能满足我们的传输需求。

问：既能传输普通数据又能传输音视频数据，感觉很方便啊。那么，传输音视频数据和其他普通数据采用的传输协议相同吗？

王师傅：是不同的，网络上有专门适用音视频传输的协议。目前，在车载以太网中常用的方案有两个，分别是 RTP 和 AVB。

• RTP（Real-time Transport Protocol），实时传输协议，采用 RTP 和 RTCP（Real-time Transport Control Protocol，实时传输控制协议）两个子协议实现音视频数据的传输，遵循的标准为 RFC 3550。

• AVB（Audio Video Bridging），音视频桥接技术，采用 IEEE 1722，IEEE 802.1AS，IEEE 802.1Qav，IEEE 802.1Qat（802.1 Qav 和 802.1 Qat which have subsequently been incorporated into IEEE 802.1Q）等一系列 IEEE 标准，通过保证带宽、控制传输延时、精准时钟同步等功能和机制实现音视频数据在网络上的实时传输。

这里要注意的是，不管采用哪种技术，这里所传输的有效载荷数据（payload）是一样的，都是音视频媒体数据（e.g. H.264），不同的是所采用的传输方式。

方案选择

问：那么具体应该选择哪种方案呢，或者说什么时候用 RTP，什么时候用 AVB 呢？

王师傅：这个取决于网络架构，应用场景和成本等因素，需要具体问题具体分析。RTP 的机制相对比较简单，而 AVB 的机制会复杂一些。下面我们详细介绍一下。

下图是 OSI 网络模型，左边是 AVB 架构，右边是基于 TCP/IP 的传统架构。

RTP

我们可以看到 RTP 协议位于模型的 5 至 7 层，底层为传输层，在 RFC 3550中推荐使用 UDP 为其底层传输协议，有的同学可能知道 IEEE 1733，（一份将 RTP 协议和 AVB 相关机制整合使用的标准），但由于过于小众，今天这里就不过多介绍了。RTP 协议本身没有连接的概念，为端到端的传输模式，无法保证数据的传输质量。我们知道在复杂的网络环境中，采用 UDP传输的数据有可能出现丢包的情况，RTP 可以借助 RTCP 提供的传输质量反馈信息，调整数据发送行为，从而尽可能的保障传输服务。但是，如果车内网络环境简单，通过合理的设计，我们可以规避传输过程中有可能出现的种种问题，从而使用 RTP 在车内进行音视频数据传输。

比如下面的应用场景：

图1

摄像头和显示屏直连，摄像头采集视频数据，通过以太网传输至显示屏，显示屏实时显示摄像头所捕获到的视频画面。类似这样一对一直连的网络拓扑，如果这条链路上的带宽充裕，可以直接使用 RTP 进行音视频传输。

问：感觉 RTP 很简单啊，是不是直连的网络拓扑，一般都可以使用RTP进行传输呢？

王师傅：是的，可以这么说。如果不是直连，但场景中 Switch 节点转发延时可控，在链路带宽充裕的情况下，RTP 一般也都可以满足传输需求。

AVB

问：了解了，那网络环境复杂就需要使用 AVB 吗？

王师傅：和 RTP 相比，在 OSI 模型中，我们可以看到 AVB 的一系列协议是直接基于数据链路层进行传输的，简单的层级架构，使数据的处理时间更加可控。AVB 共有四个子协议，分别是：

•  IEEE1722，音视频传输协议 AVTP
•  IEEE 802.1AS，精准时间同步协议 gPTP
•  IEEE 802.1Qav，时间敏感数据转发和队列优化协议 FQTSS
•  IEEE 802.1Qat，流预留协议 SRP

我们通过下面的场景具体介绍下AVB技术的应用情况：

图2

如图所示，车内网络中摄像头、显示屏、ECU1 和 ECU2 通过 Switch 相互连接，同时，摄像头、ECU1 和 ECU2 均有与显示屏通信的需求。如果 ECU1 和 ECU2 有突发的数据需要发送至显示屏，那么 Switch 和显示屏之间的链路带宽就会被大量占用，导致摄像头的视频数据无法准确传输。其次，我们知道车载以太网传输路径上的延时主要来自于 Switch 的转发延时，如果有大量数据在 Switch 队列中等待，网络就会出现拥塞，导致延时，从而影响数据的传输质量。以上场景，想要实现实时视频传输，有两个问题需要解决：其一是保证链路的传输带宽；其二是要控制 Switch 的转发延时。

这种情况下，基于 UDP 的 RTP 传输就很难满足需求了，需要 AVB 技术来解决这些问题。首先要获取多流并发时各个数据流量的所需带宽并静态配置，其次再将数据划分出不同优先级，保证高优先级数据优先转发。AVB 中，FQTSS 可以通过基于信用的转发方式（CBS，credit-based shaper），在保证高优先级数据转发的同时，也可以转发其他低优先级数据。优先级可划分为 SR class A，SR class B 等级别，在这个场景中，如果视频数据的优先级较高，可以将其划分为 SR class A，在 7 跳之内，SR class A 数据默认的最大传输时间仅为毫秒级别，完全可以满足实时视频传输的需求。通过以上方法，场景中的带宽和延时问题都可以用 AVB 技术解决，进而就可以实现流畅的视频数据传输了。

结束语

通过以上应用实例，我们简单的介绍了 RTP 和 AVB 两种在车内网络传输音视频数据的方案。如果网络环境简单，有足够的传输带宽，那么基于 TCP/IP 架构的 RTP 可以直接满足端到端的音视频传输需求，简单方便，性价比高。但是如果车内音视频数据的传输路径上有一个或多个 Switch 节点，存在多流并发的场景，或者有时钟同步的需求，就需要借助 AVB 技术中的 gPTP，FQTSS，AVTP 等技术和机制才能实现稳定的实时音视频数据传输。具体使用哪种方案，是使用所有机制还是选择性使用，还需要根据车型和应用场景，具体案例具体分析，借助时间分析工具进行仿真优化，才能呈现出最优的传输效果。

仿真分析工具推荐 RTaW
欢迎留言与车载网络王师傅交流讨论