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等技術和機制才能實現穩定的實時音視頻數據傳輸。具體使用哪種方案,是使用所有機制還是選擇性使用,還需要根據車型和應用場景,具體案例具體分析,藉助時間分析工具進行仿真優化,才能呈現出最優的傳輸效果。

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章