FLUTE通信協(xié)議的基本架構(gòu)

　　在正式開始談 FLUTE 之前，在此先跟讀者們介紹一下 DVB-IPDC 的CDP 標(biāo)準(zhǔn)，所規(guī)范的網(wǎng)絡(luò)架構(gòu)與通信協(xié)議， DVB-H 廣播網(wǎng)絡(luò) (單向 IP 網(wǎng)絡(luò)) 是必備的，至于雙向的點對點 IP 網(wǎng)絡(luò)，則僅是一種非必備的選擇性功能。由于 TCP 通信協(xié)議無法在僅具備單向 IP 網(wǎng)絡(luò)的環(huán)境下運作，因此在 DVB-H 廣播網(wǎng)絡(luò)上的通信協(xié)議，如負責(zé)傳送影音串流的 RTP (Real-time Transport Protocol，實時傳輸協(xié)議)，以及 FLUTE，均是建構(gòu)在 UDP 通信協(xié)議之上的。在 DVB-IPDC 標(biāo)準(zhǔn)的服務(wù)平臺上，F(xiàn)LUTE 通信協(xié)議除了傳送一般的使用者檔案之外，同時也負責(zé)傳送 ESG 的數(shù)據(jù)。

　　FLUTE 原本是由 IETF (Internet Engineering Task Force) 所制訂的一套通信協(xié)議 (RFC 3926 - File deLivery over Unidirectional Transport)，可將檔案由傳送端 (sender) 以多點傳送方式，透過 Internet 傳送至多個接收端 (receiver) 上。和傳統(tǒng)的多點傳送通信協(xié)議不同的是，F(xiàn)LUTE 在運作時并不需要任何由接收端回傳至發(fā)送端的回饋信息 (feedback)，因此，接收端的數(shù)量幾乎可以說是沒有限制的，不管是數(shù)10萬個或是數(shù)100萬個都沒有問題。FLUTE 不需要接收端回饋的運作特性，是它后來會被應(yīng)用在 DVB-H 單向 IP 網(wǎng)絡(luò)上的主因。

　　FLUTE是建構(gòu)于另一個 IETF 通信協(xié)議 - ALC (Asynchronous Layered Coding，異步分層編碼) 之上發(fā)展的; 而且，甚至我們可以說，ALC 通信協(xié)議才是 FLUTE 通信協(xié)議的主體。兩者的主要差別在于，ALC 是一套單向的 “對象” (object) 多點傳送通信協(xié)議，而FLUTE 則是一套單向的 “檔案” 多點傳送通信協(xié)議。由于 ALC 所傳送的對象本身，并不具任何的屬性 (attribute)，因此，F(xiàn)LUTE 通信協(xié)議針對 ALC 的最主要擴充，就是將 ALC 傳送的對象視為檔案，并為每個對象加上檔案所需要的屬性，例如文件名稱、檔案長度及檔案類型。為此，F(xiàn)LUTE 額外定義了一種叫 FDT (File Description Table，檔案描述表) 的數(shù)據(jù)結(jié)構(gòu)，里面記錄了 ALC 對象的檔案屬性。

　　ALC是以IP multicast通信協(xié)議 (即多點傳送的 UDP 通信協(xié)議)為基礎(chǔ)發(fā)展的?；旧?，IP multicast只是一種 “盡最大所能傳送” (best effort delivery)的多點傳送通信協(xié)議，本身并沒有對話管理 (session management)、壅塞控制 (congestion control)、以及提供可靠傳輸 (reliable transmission) 的能力。ALC 通信協(xié)議建構(gòu)于 IP multicast 之上，同時也填補了 IP multicast 前述的3個缺點。而且，ALC通信協(xié)議可同時適用于 IPv4 與 IPv6 這兩種不同版本的 IP 通信協(xié)議。

　　LCT 是可以說是 ALC 通信協(xié)議的主體，負責(zé)提供前述的 session 管理的功能。CC 則是一個選擇性的組成組件，負責(zé) ALC 在 Internet 上的壅塞控制。不過，因為在 DVB-H 廣播網(wǎng)絡(luò)上并不會發(fā)生壅塞的問題，所以 CC 在 DVB-IPDC 標(biāo)準(zhǔn)內(nèi)是不會被使用到的。至于 FEC 則是與 ALC 可靠傳輸功能相關(guān)的組成組件。由于 ALC 在運作時，不需要來自接收端的回饋信息，因此，ALC 主要依靠 FEC 組成組件所提供的前向糾錯功能，來彌補 ALC 封包在傳送時所發(fā)生的遺失或錯誤。而且，ALC 在設(shè)計時，已保留未來可采用各種不同的 FEC 算法的彈性。因此，F(xiàn)EC 組成組件的實際格式，主要是由采用 ALC 的標(biāo)準(zhǔn) (如 DVB-IPDC CDP 標(biāo)準(zhǔn))，依其所選擇的 FEC 算法而決定的。

　　在目前的 DVB-IPDC CDP 標(biāo)準(zhǔn)中，僅定義了兩種 FEC 組成組件，第一種是必備的 Compact No-Code FEC (意即沒有 FEC)，第二種則是非必備的 Raptor FEC。DVB-IPDC CDP 標(biāo)準(zhǔn)將 Compact No-Code FEC 納入標(biāo)準(zhǔn)的必備功能，筆者猜測可能有以下3點原因: 1、便于進行 FLUTE 通信協(xié)議的兼容性測試。2、在 DVB-H 標(biāo)準(zhǔn)中，由于 MAC 層已提供 MPE-FEC 的前向糾錯功能，因此，DVB-H 的 IP 封包傳送錯誤率，以數(shù)據(jù)傳送的角度來說，尚在可接受的范圍內(nèi)。3、由于 Raptor FEC 是 Digital Fountain 公司所擁有的專利技術(shù)，除非真的非常必要，不然不會被納入標(biāo)準(zhǔn)的必備功能。