AVB傳輸協議數據包分析
AVB傳送協議改進了之前二層通訊協議（如CobraNet或EtherSound）的固有“先天性不足”。在控制能力大幅提升的前提下，借鑒了IEEE1394技術，在三層協議下傳輸同步的專業音/視頻信號，并將傳輸延時壓縮到微秒級。AVB傳送協議對數據流的三個主要定義：
1、多媒體格式及封裝方法。包括原始數據流和壓縮音、視頻流，以及附帶傳輸IEEE1394（火線）的信號。
2、流媒體傳送的同步機制。包括基準時鐘的同步和丟失重建，以及同步時鐘延時控制和優化。
3、多播地址的分配。包括為AVB數據流分配ID以及媒體時鐘發生器的分配方式。
AVB傳送協議在OIS模型中的位置如圖一所示：
圖一AVB協議集在OSI模型中的層次
從圖一看出AVB協議組基本上跨越了TCP/IP協議組的全部層次，而不僅僅是二層協議傳輸，且為可路由協議，這就從傳輸本質上區別于二層的CobraNet和EtherSound協議。盡管AVB可以支持三層路由，但是并非意味著它可以發送到Internet公網中去，或者架構在Internet架構下的VPN上去。這是因為遠距離傳輸的基準時鐘延時問題沒有根本得到解決，網絡直徑依然無法超過7個hop。這么說來，那這個三層協議好處在哪里呢？由于QoS的介入，使得數據管理和傳輸效率大大提高，更多的基于TCP/IP的硬件、管理軟件可以支持AVB。這使得AVB的各方面能力都是非常強大而靈活的。盡管剛才說AVB協議集包含的數據包類型繁多，但是每種不用用途的AVB數據包的基本框架結構是一樣的，如圖二所示。
圖二AVB數據包構成
上述的AVB數據包結構只是它的二層結構類型，也就是針對二層以太網傳送的協議結構，而針對三層傳輸和控制協議則封裝在AVB以太網荷載（Payload）的46~1500字節當中另外定義。如果不理解這句話的意思，可以查閱相關TCP/IP數據結構相關書籍，或者參考本連載之前的關于CobraNet數據結構封裝的章節。簡單來說，網絡數據包封裝就是一個“嵌套”結構，二層底層是最外層封裝，三層結構則被鑲嵌在內等等，如圖三：
圖三網絡封裝的“嵌套”結構
圖二中從DA高位地址一直到AVB以太網類型之間的18個字節就是圖三的以太網報頭部分，圖二中的AVB以太網荷載46~1500字節，就是對應圖三的二層荷載（Payload）。也就是說圖二分析了整個以太網數據包的數據結構，但是對于二層AVB荷載（46~1500字節）并未展開分析里面包含了什么數據，那么下面我們就單獨分析這個AVB荷載的結構，這也是AVB技術和以前CobraNet及EtherSound技術完全不同的地方。AVB數據包按照包類型可以分為命令/控制數據包和流媒體數據包兩大類，下面我們分兩部分展開來討論。
1、命令/控制數據包：
圖四命令/控制數據包結構
這種數據包包含了命令發布和控制信號、數據流預約等除流媒體信號以外的其它數據結構包，屬于第三層數據封裝包（路由器層次）。第一個bit數據位稱為CD數據位，只有兩種表示狀態，“0”表示流媒體數據，“1”表示控制型數據。4~11這8個字節的802.1Qat預約數據協議ID號碼，它相當于TCP/IP協議集中的IP地址（比如192.168.0.1是4個字節“0xC0A80x0001”，表示的是目的地地址，后面緊接的192.168.0.1則是發送端地址，這樣一共是8個字節。在AVB協議中，由于發送端和接收端不再使用IP地址的命名方法，而是使用標識ID來區別不同的設備，但是其作用和在數據包中的位置是與TCP/IP協議集類似的）。最后的1~3個字節的補足位是當荷載數據較短的時候（即三層荷載不足34個字節的時候），AVB控制設備自動添加足夠的“0”來補足位數，稱為“Padding”，以防止超短幀的形成。超短幀是指以太網數據包低于64字節（或者超過1518個字節）的時候，以太網傳送機制CSMA/CD無法判斷相鄰接收幀的間距而形成網絡沖突，為避免這種沖突出現，以太網規定了每個數據包的最小和最大長度。
2、流媒體數據流包：
圖五流媒體數據包結構
流媒體數據的數據結構顯然比控制數據包復雜很多，但是基本含義沒有太多的復雜性，和圖四類似。以前提過AVB傳輸的媒體流數據可以是很多種類型，包含壓縮和不壓縮的音頻及視頻以及衛星電視數據等不同種類，這些不同類型的數據在媒體流數據包中在7bit的協議類型中得以體現，參見下圖六：
圖六AVB協議類型
上表中提到的61883的全稱是IEC61883，要想了解這個規范，先簡單介紹一下什么是IEC。IEC標準即國際電工委員會（InternationalElectricalCommission），是由各國電工委員會組成的世界性標準化組織，其目的是為了促進世界電工電子領域的標準化。國際電工委員會的起源是1904年在美國圣路易召開的一次電氣大會上通過一項決議。根據這項決議，1906年成立了IEC，它是世界上成立最早的一個標準化國際機構。IEC對很多電氣規范做出國際標準，其中針對工業音頻、視頻等傳輸和接口方式作出定義（電腦中常用的1394火線接口就是IEC61883-6定義的），我們現在討論的AVB以太網傳輸協議，只是從傳輸層面上作出一個新的規范，但是在AVB內部傳輸的流媒體數據則是按照IEC61883規定的格式進行的。IEC61883包含的數據格式有：
•61883-2SD-DVCR標清視頻記錄數據流格式
•61883-4MPEG2-TS壓縮視頻數據流格式
•61883-6非壓縮音頻數據格式（即IEEE1394傳輸格式）
•61883-7衛星電視MPEG壓縮格式
•61883-8Bt.601/656視頻流格式
•IIDC非壓縮工業級攝像頭視頻流傳輸格式
當然上述的只是幾個我們可能會用到的數據格式，還有很多我們沒有一一例舉。簡單地說也就是所有IEC61883定義的音視頻數據流都可以通過AVB進行傳送。這里我們重點討論一下非壓縮音頻數據的傳輸，也是就是IEC61883-6即IEEE1394格式的數據流是怎樣傳輸的。
由于1394信號和AVB傳輸協議的兼容性，所以直接通過火線轉換成以太網信息也是可以加入到AVB網絡中來，他們的相互傳輸見圖七：
圖七AVB傳送IEEE1394數據橋兼容性
從圖七我們可以看出AVB和IEEE1394之間的兼容性還是相當的不錯，無論是從AVB發送器還是1394發送器發送的信號，都可以從兩者的接收端接受（同步）。這樣跨越AVB和1394之間的傳輸本身并沒有太多的實際應用，這主要是用來分析IEC61883定義的媒體數據流可以兼容地通過AVB網絡。
在AVB發送和接收端，流媒體數據和標準時鐘信號是怎樣結合起來并打包形成以太網數據包的呢？詳細的打包和解包的過程參見圖八和圖九：
圖八AVB數據流的合成過程
圖九AVB信號的解包過程
圖八的AVB數據包合成過程中，本地晶振相對時鐘和IEEE1588絕對時鐘之間做時基比較和校正，確保時鐘上升和下降沿的準確。由這兩個時鐘運算形成AVB時間戳，用來和流媒體數據進行綁定。那么圖八中的模擬流媒體信號為什么還要和晶振時鐘相乘呢？這是因為模擬信號在進行AD轉換的時候，要必須和采樣時鐘進行卷積，如果另外再為這個流媒體模擬信號再建一個晶振，那么當這個模數轉換后的信號又必須重新和時間戳進行相互校正，反而變得復雜了。所以此處巧妙的利用了生成時間戳的本地晶振信號，直接發出AD卷積所需的采樣頻率（例如AVB傳輸音頻信號時，會按照IEEE1394格式的48kHz，24bit音頻格式進行量化，那么采樣頻率就直接將AVB時間戳的晶振信號轉換到48kHz），這樣在數據流信號AD變換以后就可以無縫地和時間戳合并發送了。
圖九的過程基本上是和圖八相反的過程，接收端接收到的數據和本地晶振時鐘做反變換，就可以通過DA變化輸出模擬媒體流信號了。
在流媒體時鐘的管理上，一個接收點可以接收多達256個獨立的媒體時鐘。這就意味著一個網絡中可以同時存在多達256個完全不同的流媒體文件，例如可以同時存在：48kHz音頻采樣數據、44.1kHz音頻采樣數據以及同步鎖相的視頻數據流甚至壓縮MPEG2視頻數據流等等。盡管它們之間采用完全不同的AVB時間戳，但是由于每種不同的AVB數據包可以采用不同的本地晶振進行解包，使得不同數據類型的數據在相同的網絡中交叉傳遞稱為了現實。這是二層數據傳輸時代（如Cobranet，EtherSound技術）所無法超越的。一般地來說，不同采樣的音頻數據源在進行AD變化的時候，采用不同的采樣頻率或者轉換采樣頻率不是很困難的事情，但是在很多的實際工程中，視頻信號的傳遞格式確實是五花八門，有壓縮的，不壓縮的，有高清的，標清的，攝像機以及監控系統等等，所以一個大型傳輸控制系統能同時兼容不同格式的數據確實顯得十分重要。
延時控制上，如果一個流媒體源的接收端橫跨在不同的hop上面（也就是不同接收點在網絡的不同位置，經過的電纜長度和交換機數量都不相同），那么在接受一個廣播的同源信號在會放上能否保持同步呢？這個也是AVB在設計之初已經考慮過的事情了，由于網絡的最長容忍延時是2毫秒，所以第一個接收端在收到信號以后不會立刻轉換解包，而是要等到網絡中所有接收端都在時鐘上確認了同步，才會一起向外發送流媒體數據。
關于多播地址配置協議。要求媒體流地址必須是唯一的；其次就是多播流媒體地址必須是2層以上的地址，例如IP、RTP、UDP等；在AVB上可以支持IPv4或者IPv6兩種不同的多播地址，以適應未來的需要。
本期我們主要講述了AVB發送和接受數據流的數據包結構，通過這些包結構和之前的二層傳輸技術相比，主要區別在：
•系統的延時大大降低至2毫秒以下
•系統的傳輸質量有QoS保證，包括軟件和硬件均支持
•AVB作為流媒體的一個載體，可以傳送包括壓縮和非壓縮等多種音視頻流媒體，并能保證同步傳輸，突破以往的瓶頸
•多達256種不同格式的音視頻數據流（包括采樣頻率）可以在同一個網絡中共存傳輸，而互不干擾
•支持其它3層協議的高級功能
這些特點都表明它將是下一代流媒體文件傳輸的標準之一，無論是專業還是民用領域，都將展現出它的強大魅力。