打印
[传感器]

AVB vs. RTP

[复制链接]
394|0
手机看帖
扫描二维码
随时随地手机跟帖
跳转到指定楼层
楼主
问:近些年,随着智能驾驶技术的发展和车内影音娱乐系统的丰富,越来越多的音视频数据需要在车内网络进行传输。现在车载以太网日渐成熟,那么,我们可以使用车载以太网在车内网络传输音视频数据吗?

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

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

答:是不同的,网络上有专门适用音视频传输的协议。目前,在车载以太网中常用的方案有两个,分别是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等技术和机制才能实现稳定的实时音视频数据传输。具体使用哪种方案,是使用所有机制还是选择性使用,还需要根据车型和应用场景,具体案例具体分析,借助时间分析工具进行仿真优化,才能呈现出最优的传输效果。






使用特权

评论回复

相关帖子

发新帖 我要提问
您需要登录后才可以回帖 登录 | 注册

本版积分规则

439

主题

452

帖子

3

粉丝