FLUTE通信協(xié)議原理構架

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

　　在正式開始談 FLUTE 之前，在此先跟讀者們介紹一下 DVB-IPDC 的CDP 標準，所規(guī)范的網(wǎng)絡架構與通信協(xié)議， DVB-H 廣播網(wǎng)絡 (單向 IP 網(wǎng)絡) 是必備的，至于雙向的點對點 IP 網(wǎng)絡，則僅是一種非必備的選擇性功能。由于 TCP 通信協(xié)議無法在僅具備單向 IP 網(wǎng)絡的環(huán)境下運作，因此在 DVB-H 廣播網(wǎng)絡上的通信協(xié)議，如負責傳送影音串流的 RTP (Real-time Transport Protocol，實時傳輸協(xié)議)，以及 FLUTE，均是建構在 UDP 通信協(xié)議之上的。在 DVB-IPDC 標準的服務平臺上，F(xiàn)LUTE 通信協(xié)議除了傳送一般的使用者檔案之外，同時也負責傳送 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 不需要接收端回饋的運作特性，是它后來會被應用在 DVB-H 單向 IP 網(wǎng)絡上的主因。

　　FLUTE是建構于另一個 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ù)結構，里面記錄了 ALC 對象的檔案屬性。

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

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

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

FLUTE 通信協(xié)議的運作原理

　　在此，我們先跟讀者們介紹 FLUTE session 的觀念?；旧?，一個 FLUTE session 所代表的是一個 FLUTE 的傳送端，在一段指定的時間區(qū)間內(nèi)，透過 FLUTE 通信協(xié)議傳送一群對象的行為。因此，代表一個 FLUTE session 的 ID，是由 FLUTE session 傳送端的 IP 地址，再加上 FLUTE session 的 TSI (Transport Session Identifier) 所組成。在一個 FLUTE session 內(nèi)，會包含一個或多個 FLUTE channel (頻道)。基本上，這些 FLUTE channel 的來源 IP 地址就是 FLUTE session 傳送端的 IP 地址。另外，不同的 FLUTE channel 會有各自的目的 IP 地址及通信阜 (port)。在一個 FLUTE channel 中所傳送的每一個 FLUTE 封包，其來源 IP 地址、目的 IP 地址及通信阜的值，都會與其所屬的 FLUTE channel 相同。FLUTE 接收端可選擇加入一個 FLUTE channel，以接收 FLUTE channel 內(nèi)所傳送的 FLUTE 封包?；旧希現(xiàn)LUTE 接收端加入或離開一個 FLUTE channel 的方法，跟加入或離開一個 IP multicast 群組 (group) 是完全相同的。

　　在一個 FLUTE session 內(nèi)所傳送的每個檔案，基本上都是一個 ALC 對象 .而且，F(xiàn)LUTE session 中的每個 ALC 對象，都會有一個獨一無二的 TOI (Transport Object ID)。每個 ALC 對象在傳送前，都會經(jīng)過分割及加入 FEC 信息的流程，然后才會被放入 FLUTE 封包中被傳送。而且，每個 ALC 對象均可以自由實行不同的FEC 算法。在計算 FEC 信息之前，ALC 對象會被分割成一到數(shù)個 source block (來源區(qū)塊)?；旧?，F(xiàn)EC 信息是針對每個 source block 獨立計算的。首先，一個 source block 會被分割成大小相同的 source symbol (來源符號)。接著，F(xiàn)EC 算法再由這些 source symbol，計算出該 source block 的 parity symbol (檢查碼符號)。因為 source symbol 與 parity symbol 的大小是一致的，因此，它們也被統(tǒng)稱為 encoding symbol (編碼符號)。

　　在一個 FLUTE 封包內(nèi)，可裝入一個到數(shù)個屬于同一個 ALC 物件的 encoding symbol。至于 encoding symbol 如何被裝入 FLUTE 封包內(nèi)的實際方式，則與 ALC 對象所實行的 FEC 算法有關。例如，若 ALC 對象未經(jīng) FEC 編碼 (Compact No-Code FEC)，則一個 FLUTE 封包內(nèi)，可裝入一個到數(shù)個連續(xù)的 encoding symbol。在該 FLUTE 封包的標頭 (header) 內(nèi)，會記錄該 ALC 對象的 TOI，以及傳送該 ALC 對象之 FLUTE session 的 TSI。此外，該 FLUTE 封包的標頭內(nèi)也會記錄被傳送的第一個 encoding symbol 的 source block number (SBN，來源區(qū)塊編號) 及 encoding symbol identifier (ESI，編碼符號 ID)。

　　至于將 ALC 對象分割成 source block 的區(qū)塊化算法 (blocking algorithm)，也是由 ALC 對象所實行的 FEC 算法決定的。因此，針對每一個 ALC 對象，會有一份 FEC-OTI (FEC Object Transmission Information，F(xiàn)EC 對象傳遞信息)，里面記錄了該 ALC 對象所實行的 FEC 算法 (稱作 FEC encoding ID，F(xiàn)EC 編碼 ID)，以及其它區(qū)塊化算法所需要的參數(shù)。例如，若 ALC 對象未經(jīng) FEC 編碼 (Compact No-Code FEC)，則該對象的 FEC-OTI 包括了: ALC 對象的原始長度、FEC encoding ID (值為 零)、encoding symbol 的大小、以及一個 source block 所能包含的 encoding symbol 的最大數(shù)量。因此，一旦 FLUTE 接收端收到一個 ALC 對象的 FEC-OTI 后，即可得知該 ALC 對象會被分割成幾個 source block、每個 source block 內(nèi)包含了幾個 source symbol、以及 source symbol (encoding symbol) 的大小。這些信息可協(xié)助 FLUTE 接收端，解碼與重組屬于該 ALC 物件的 encoding symbol。