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等一系列 IEEE 标准，通过保证带宽、控制传输延时、精准时钟同步等功能和机制实现音视频数据在网络上的实时传输。

 

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

 

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

 

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

 

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

 

 

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

 

        比如下面的应用场景：

 

Figure 1

 

 

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

 

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

 

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

 

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

 

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

•  IEEE1722，音视频传输协议AVTP

•  IEEE 802.1AS，精准时间同步协议gPTP

•  IEEE 802.1Qav，时间敏感数据转发和队列优化协议FQTSS

•  IEEE 802.1Qat，流预留协议SRP

 

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

 

Figure 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等技术和机制才能实现稳定的实时音视频数据传输。具体使用哪种方案，是使用所有机制还是选择性使用，还需要根据车型和应用场景，具体案例具体分析，借助时间分析工具进行仿真优化，才能呈现出最优的传输效果。