FLUTE是IP化的行動電視系統中，負責以廣播或多點傳送模式，傳遞ESG資料與使用者檔案的基礎通訊協定。在本文中，我們以DVB-IPDC標準的角度出發，說明了FLUTE應用於DVB-H廣播網路上的系統架構、運作原理、封包格式，以及DVB-IPDC CDP標準對FLUTE的一些擴充與限制。
FLUTE通訊協定的封包格式
由於ALC通訊協定本身是一個未被完整定義(under-specified)的標準，而FLUTE通訊協定則是由ALC所衍生的一個完整定義(fully-specified)的標準，因此，FLUTE通訊協定的封包，採用的是和ALC封包完全一樣的基本結構，只是增加了在FLUTE中才會使用到的LCT標頭擴充欄位 - EXT_FDT和 EXT_CENC(EXT_CENC只在FDT instance本身的內容也被編碼時使用，但因 DVB-IPDC CDP標準不支援此功能，故在本文中先略去不談)。圖6是ALC封包格式的一個概觀，如圖所示，ALC封包會被裝載在UDP通訊協定的封包內，而 ALC 封包本身，則由以下的三個部分組成: LCT header(LCT標頭)、FEC Payload ID(FEC酬載ID)、以及一個或數個連續的Encoding Symbol。
LCT header對應到ALC的LCT組成元件，如圖7所示，LCT header可以再被細分成default LCT header(預設的LCT標頭)，以及LCT header extension(LCT標頭擴充)。至於圖6及圖7中的FEC Payload ID及 Encoding Symbol，則對應到ALC的FEC組成元件。而ALC的CC組成元件，在ALC封包中所使用的欄位，只有default LCT header中的Congestion Control flag(C)與Congestion Control Information(CCI)。而且，LCT header及FEC Payload ID的兩者的長度，都必須是32位元的倍數。另外，為了避免ALC封包在傳送的過程中被分割重組，DVB-IPDC CDP標準建議 ALC封包的總長度(包含IP/UDP/ALC標頭)，最好不要超過FLUTE傳送端到 DVB-H的IPE(IP Encapsulator，IP裝載器)間，所經過之網路的最小MTU(Maximum Transmission Unit，最大傳輸單元)；在RFC 1812中的建議值是1500位元組。
LCT default header的設計是非常有彈性的，有些欄位的長度可以調整，而有些欄位的則是可以關閉不用的。採取這種設計的主因是ALC並不是被完整定義的標準，仍須針對實際的應用進行調校。因此，在這裡我們會順便介紹一下，DVB-IPDC CDP標準對這些欄位的使用限制。以下是LCT default header的欄位介紹:
* ALC version number(V):4位元長，為ALC與LCT的版本號碼，目前版本(RFC 3450) 的值為1。
* Congestion Control flag(C)與CCI：C是2位元的欄位，其值決定了 Congestion Control Information (CCI)欄位的長度。C = 0，CCI為32位元；C = 1，CCI 為64位元；C = 2，CCI為96位元；C = 3，CCI為 128位元。因為 DVB-H廣播網路上沒有壅塞控制的問題，所以 CCI欄位是用不到的。也因此，DVB-IPDC CDP標準規定C欄位的值須為 1，CCI為32位元，且CCI欄位內的值須為0。
* Reserved：2位元長，其值須為0。
* Transport Session Identifier flag(S)與TSI：S是1位元的欄位，其與另一個1位元的Half-word flag(H)欄位，共同決定了Transport Session Identifier(TSI)欄位的長度。TSI的位元長度 = 32 * S + 16 * H。
* Transport Object Identifier flag(O)與TOI：O是2位元的欄位，其與前述的H欄位，共同決定了Transport Object Identifier(TOI)欄位的長度。TOI的位元長度 = 32 * O + 16 * H。因此，H欄位存在的目的，是為了讓TSI與TOI的位元長度和為32位元的倍數。
* Sender Current Time present flag(T)與SCT：T是1位元的欄位，其決定了Sender Current Time(SCT)欄位的存在與否。若T = 0，則表示 SCT欄位不存在; 若T = 1，則表示SCT欄位存在。SCT是一個32位元的欄位，裡面記錄了FLUTE session開始後經過的時間，單位為1毫秒(ms)。
* Expected Residual Time present flag(R)與ERT：R是1位元的欄位，其決定了Expected Residual Time(ERT)欄位的存在與否。若R = 0，則表示ERT欄位不存在，若R = 1，則表示ERT欄位存在。ERT欄位用來指定FLUTE session中由TOI指定的ALC物件，還會被繼續傳送多少時間，單位也為1毫秒。
* Close Session flag(A)：為1位元的欄位。若將A設定為1，則表示該 FLUTE session會"立刻"或"即將" 結束。一旦A欄位被設為1，該FLUTE session之後傳送的ALC封包，其A欄位也都會被設為1。FLUTE接收端只要收到A欄位為1的ALC封包，即可假設該FLUTE session的傳送已經結束。
* Close Object flag(B): 為1位元的欄位。若將B設定為1，則表示該 FLUTE session中由TOI欄位所指定的ALC物件，其傳送會"立刻"或"即將" 結束。一旦B欄位被設為1，FLUTE session中傳送該ALC物件的ALC封包，其B欄位也都會被設為1。FLUTE接收端只要收到B欄位為1的ALC封包，即可假設TOI欄位指定之ALC物件的傳送已經結束。
* LCT header length(HDR_LEN)：8位元長。本欄位指定了LCT header 的長度，包含default LCT header與LCT header extension，單位為 32位元(這是LCT header的長度必須是32位元的倍數的原因)。因此，可由此欄位直接參考到FEC Payload ID。而且，只要分析HDR_LEN之前的旗標欄位與HDR_LEN，即可知道該LCT header內是否包含LCT header extension。
* Codepoint(CP)：8 位元長。本欄位記錄了ALC物件所採行的FEC演算法之FEC encoding ID。
附帶一提，在DVB-IPDC CDP標準中，對TSI與TOI欄位的長度做了以下的限制：第一種許可的長度是TSI與TOI均為16位元，第二種許可的長度則是TSI與TOI均為32位元。
另外，如圖7所示，在FLUTE通訊協定中，會使用到的LCT header extension主要為EXT_FDT與EXT_FTI。EXT_FDT只會存在於傳送FDT instance的ALC封包(TOI為0)中，負責記錄該FDT instance的FDT instance ID。圖8是EXT_FDT的欄位格式，基本上，EXT_FDT是一個固定長度的資料結構，以下為其所包含之欄位的說明:
* Header Extension Type(HET)：8位元長。EXT_FDT的HET為192。
* Version of FLUTE(V)：4位元長。為FLUTE的版本號碼，目前版本 (RFC 3926)的值為1。
* FDT Instance ID：20位元長。在每個FLUTE session開始運作時，FDT instance ID會均從0開始，然後依次遞增。當FDT instance ID的值從220 - 1變為0時，0會被視為大於220 - 1；換句話說，就是FLUTE接收端必須用大於20位元的欄位，來記錄接收到的FDT instance的ID。因此，FLUTE標準中也建議，在一個ID為n的FDT instance過時(expire)前，FLUTE發送端不可以重用n這個ID，來傳送其他的FDT instance。
在FLUTE中會使用到的第二種LCT header extension為EXT_FTI，用以承載ALC物件的FEC OTI。由於FEC OTI與ALC物件所採行的FEC演算法有關，因此，EXT_FTI的格式可再被細分成兩個部分：第一個部分是EXT_FTI的通用格式(general EXT_FTI format)，為圖9中最後一個欄位之外的其他所有欄位。對所有的FEC演算法來說，其EXT_FTI的通用格式都是一致的。第二個部分則是與FEC演算法相關的格式，為圖9中的FEC Encoding ID Specific Format欄位，此部分的格式對不同的FEC演算法來說則可能是不同的。以下是圖9中EXT_FTI所包含之欄位的說明:
* Header Extension Type(HET)：8位元長。EXT_FTI的HET為64。
* Header Extension Length(HEL)：8位元長。本欄位指定了EXT_FTI 的總長度，包含了FEC Encoding ID Specific Format欄位的部分。長度的計算單位為32位元。
* Transfer Length：48位元長。指定了ALC物件的原始長度，或是ALC物件經GZip編碼後的長度。長度的計算單位為1位元組。
* FEC Instance ID：16位元長。這個欄位只在FEC encoding ID為 128 ~ 255時，才會被使用到。在DVB-IPDC標準中，這個欄位的值都會被設定為0。
* FEC Encoding ID Specific Format：此部分的格式由ALC物件所採行的FEC演算法之FEC encoding ID決定。
在DVB-IPDC CDP標準中，僅納入了兩種FEC演算法：第一種是必備的 Compact No-Code FEC，FEC Encoding ID為0。第二種則是選擇性的 Raptor FEC，FEC Encoding ID為1。圖10是Compact No-Code FEC的 EXT_FTI專屬格式；基本上，這些欄位中的資訊，會被Compact No-Code FEC的區塊化演算法使用。至於Raptor FEC的EXT_FTI專屬格式，則請讀者參考DVB-IPDC CDP標準。以下為Compact No-Code FEC之EXT_FTI專屬格式的說明:
* Encoding Symbol Length：16位元長，為一個ALC物件中，每個 encoding symbol(即source symbol)的長度，單位為1位元組。不過，ALC物件的最後一個encoding symbol，可能會短於前述的長度。
* Maximum Source Block Length：32 位元長，為每個source block 中最多所能包含的encoding symbol的數目。
圖6及圖7中的FEC Payload ID，是在ALC封包中，標示其包含了哪些 encoding symbol的辨識資訊。至於FEC Payload ID的實際格式，則是由作用於ALC物件的FEC演算法決定的。基本上，DVB-IPDC CDP標準中所納入的兩種FEC演算法，兩者所定義的FEC Payload ID之格式是相同的，如圖11所示。以Compact No-Code FEC來說，在一個FLUTE封包內，可包含一個或數個連續的encoding symbol。Source Block Number欄位定義了前述的 encoding symbol，所歸屬的source block之號碼。Encoding Symbol ID欄位則為開始的第一個encoding symbol的編號。另外，若有讀者對 Raptor FEC之FEC Payload ID欄位的說明有興趣，請參考DVB-IPDC CDP 標準。
其他DVB-IPDC CDP標準所指定的特性
在DVB-IPDC CDP標準中，對RFC 3926所定義的FLUTE通訊協定，做了一些功能上的擴充與使用上的限制。首先，針對FDT instance的XML文件格式，DVB-IPDC CDP標準新增了定義檔案群組的功能。一個檔案可歸屬於一個或數個檔案群組，只要FLUTE接收端上的使用者，選用了檔案群組中的某個檔案，則該檔案群組所包含的所有檔案，都會被下載及儲存在FLUTE接收端上。檔案群組可應用在下載一組網頁的檔案，或是下載某個包含了數個檔案之軟體。
另外，FLUTE接收端需要FLUTE session的傳輸參數，以連上FLUTE session所包含的FLUTE channel，接收FDT instance及其他的ALC物件。在FLUTE標準(RFC 3926)中，只提出了FLUTE session傳輸參數應包含的種類，如下所示:
* FLUTE session傳送端的IP位址。
* FLUTE session的TSI。
* FLUTE session所包含的FLUTE channel數。
* 每個FLUTE channel的目的IP位址與通訊阜號碼。
* FLUTE session的開始與結束時間。
* FLUTE session或FLUTE channel預設的FEC演算法。
不過，在RFC 3926中，並沒有定義該用什麼格式來記錄前述的傳輸參數。因此，在DVB-IPDC CDP標準中，定義了基於SDP(Session Description Protocol，對話描述協定)的傳輸參數記錄格式。
還有，由於FLUTE/ALC原本是設計在Internet上使用的，因此，一個 FLUTE session可提供多個傳輸率不同的FLUTE channel，讓FLUTE接收端依其接收狀況與合適的傳輸率，選擇要接收哪些FLUTE channel。不過，在 DVB-H廣播網路上，由於每個FLUTE接收端的接收狀況，遠比在Internet上要相近得多，因此，DVB-IPDC CDP標準，只把FLUTE session僅包含一個 FLUTE channel的選項，定義為FLUTE傳送端與FLUTE接收端必備的功能。至於FLUTE session內包含多個FLUTE channel，僅被定義成一種選擇性的功能。
在DVB-IPDC CDP標準內，把FLUTE session的SDP檔案中，第一個出現的 FLUTE channel，稱之為基礎FLUTE channel(base FLUTE channel)。由於FLUTE接收端可能僅能接收基礎FLUTE channel，因此，若FLUTE傳送端希望在一個FLUTE session內，包含一個以上的FLUTE channel，FLUTE 傳送端必須能確保前述的FLUTE接收端，可以透過基礎FLUTE channel收到足夠的資料。另外，在基礎FLUTE channel內所傳送的FDT insatnce，也不能包含在其他FLUTE channel內傳送之ALC物件的屬性。
最後，我們再來探討一下FLUTE如何提供可靠傳輸的方法，亦即如果有 FLUTE接收端少收了某些該收到的encoding symbol，該怎麼辦呢？第一種方法是前面提過的，透過ALC下層的FEC組成元件，傳送額外的FEC資訊到 FLUTE接收端。第二種方法則是透過廣播網路上常使用的輪播方式(data carousel)，將所有的encoding symbol重複透過DVB-H廣播網路傳送。第三種方法則是透過重傳機制(retransmission)，該機制包含在DVB-IPDC CDP標準內所定義的相關傳送程序(associated delivery procedure) 中，只適用於當雙向的點對點IP網路存在時。由於FLUTE通訊協定主要的設計哲學，是希望FLUTE接收端不要傳送回饋資訊給FLUTE傳送端，因此，FLUTE的重傳機制，僅是一種選擇性的功能。而且，只能使用於當FLUTE session 內的某個ALC物件，在DVB-H廣播網路上已經停止傳送時。此外，FLUTE的重傳機制也不能用來傳送過時版本的FLUTE檔案。
FLUTE的重傳機制需要在雙向IP網路上，建置所謂的修復伺服器(repair server)。為了減少修復伺服器的負載，每個FLUTE session可使用超過一個以上的修復伺服器。當某個ALC物件已經停止傳輸之後，FLUTE接收端需等待一段隨機的後退時間(back-off time)，然後，再選擇一部修復伺服器，透過雙向IP網路發送HTTP格式的檔案修復請求訊息(file repair request message)，要求修復伺服器將指定的一個或數個encoding symbol傳送給FLUTE接收端。修復伺服器有以下的兩種回應方式：第一種是透過HTTP格式的檔案修復回應訊息(file repair response message)，將encoding symbol透過雙向IP網路傳回給FLUTE接收端。第二種方式則是透過原本的FLUTE session，或另一個FLUTE session，將encoding symbol透過DVB-H廣播網路傳送給所有的FLUTE接收端。
結論
FLUTE是IP化的行動電視系統中，負責以廣播或多點傳送模式，傳遞ESG資料與使用者檔案的基礎通訊協定。在本文中，我們以DVB-IPDC標準的角度出發，說明了FLUTE應用於DVB-H廣播網路上的系統架構、運作原理、封包格式，以及DVB-IPDC CDP標準對FLUTE的一些擴充與限制。在不影響行文清晰度的前提下，筆者略去了一些技術細節，例如：Raptor FEC、FDT instance詳細的XML檔案格式、FLUTE session的SDP檔案格式、FLUTE重傳機制的細節、以及FLUTE在DVB-H廣播網路上可能的傳送模式。對前述內容有興趣的讀者，可參考筆者在文中附帶的文獻引用資訊，去研讀更進一步的技術細節。
FLUTE通訊協定的封包格式
由於ALC通訊協定本身是一個未被完整定義(under-specified)的標準，而FLUTE通訊協定則是由ALC所衍生的一個完整定義(fully-specified)的標準，因此，FLUTE通訊協定的封包，採用的是和ALC封包完全一樣的基本結構，只是增加了在FLUTE中才會使用到的LCT標頭擴充欄位 - EXT_FDT和 EXT_CENC(EXT_CENC只在FDT instance本身的內容也被編碼時使用，但因 DVB-IPDC CDP標準不支援此功能，故在本文中先略去不談)。圖6是ALC封包格式的一個概觀，如圖所示，ALC封包會被裝載在UDP通訊協定的封包內，而 ALC 封包本身，則由以下的三個部分組成: LCT header(LCT標頭)、FEC Payload ID(FEC酬載ID)、以及一個或數個連續的Encoding Symbol。
LCT header對應到ALC的LCT組成元件，如圖7所示，LCT header可以再被細分成default LCT header(預設的LCT標頭)，以及LCT header extension(LCT標頭擴充)。至於圖6及圖7中的FEC Payload ID及 Encoding Symbol，則對應到ALC的FEC組成元件。而ALC的CC組成元件，在ALC封包中所使用的欄位，只有default LCT header中的Congestion Control flag(C)與Congestion Control Information(CCI)。而且，LCT header及FEC Payload ID的兩者的長度，都必須是32位元的倍數。另外，為了避免ALC封包在傳送的過程中被分割重組，DVB-IPDC CDP標準建議 ALC封包的總長度(包含IP/UDP/ALC標頭)，最好不要超過FLUTE傳送端到 DVB-H的IPE(IP Encapsulator，IP裝載器)間，所經過之網路的最小MTU(Maximum Transmission Unit，最大傳輸單元)；在RFC 1812中的建議值是1500位元組。
LCT default header的設計是非常有彈性的，有些欄位的長度可以調整，而有些欄位的則是可以關閉不用的。採取這種設計的主因是ALC並不是被完整定義的標準，仍須針對實際的應用進行調校。因此，在這裡我們會順便介紹一下，DVB-IPDC CDP標準對這些欄位的使用限制。以下是LCT default header的欄位介紹:
* ALC version number(V):4位元長，為ALC與LCT的版本號碼，目前版本(RFC 3450) 的值為1。
* Congestion Control flag(C)與CCI：C是2位元的欄位，其值決定了 Congestion Control Information (CCI)欄位的長度。C = 0，CCI為32位元；C = 1，CCI 為64位元；C = 2，CCI為96位元；C = 3，CCI為 128位元。因為 DVB-H廣播網路上沒有壅塞控制的問題，所以 CCI欄位是用不到的。也因此，DVB-IPDC CDP標準規定C欄位的值須為 1，CCI為32位元，且CCI欄位內的值須為0。
* Reserved：2位元長，其值須為0。
* Transport Session Identifier flag(S)與TSI：S是1位元的欄位，其與另一個1位元的Half-word flag(H)欄位，共同決定了Transport Session Identifier(TSI)欄位的長度。TSI的位元長度 = 32 * S + 16 * H。
* Transport Object Identifier flag(O)與TOI：O是2位元的欄位，其與前述的H欄位，共同決定了Transport Object Identifier(TOI)欄位的長度。TOI的位元長度 = 32 * O + 16 * H。因此，H欄位存在的目的，是為了讓TSI與TOI的位元長度和為32位元的倍數。
* Sender Current Time present flag(T)與SCT：T是1位元的欄位，其決定了Sender Current Time(SCT)欄位的存在與否。若T = 0，則表示 SCT欄位不存在; 若T = 1，則表示SCT欄位存在。SCT是一個32位元的欄位，裡面記錄了FLUTE session開始後經過的時間，單位為1毫秒(ms)。
* Expected Residual Time present flag(R)與ERT：R是1位元的欄位，其決定了Expected Residual Time(ERT)欄位的存在與否。若R = 0，則表示ERT欄位不存在，若R = 1，則表示ERT欄位存在。ERT欄位用來指定FLUTE session中由TOI指定的ALC物件，還會被繼續傳送多少時間，單位也為1毫秒。
* Close Session flag(A)：為1位元的欄位。若將A設定為1，則表示該 FLUTE session會"立刻"或"即將" 結束。一旦A欄位被設為1，該FLUTE session之後傳送的ALC封包，其A欄位也都會被設為1。FLUTE接收端只要收到A欄位為1的ALC封包，即可假設該FLUTE session的傳送已經結束。
* Close Object flag(B): 為1位元的欄位。若將B設定為1，則表示該 FLUTE session中由TOI欄位所指定的ALC物件，其傳送會"立刻"或"即將" 結束。一旦B欄位被設為1，FLUTE session中傳送該ALC物件的ALC封包，其B欄位也都會被設為1。FLUTE接收端只要收到B欄位為1的ALC封包，即可假設TOI欄位指定之ALC物件的傳送已經結束。
* LCT header length(HDR_LEN)：8位元長。本欄位指定了LCT header 的長度，包含default LCT header與LCT header extension，單位為 32位元(這是LCT header的長度必須是32位元的倍數的原因)。因此，可由此欄位直接參考到FEC Payload ID。而且，只要分析HDR_LEN之前的旗標欄位與HDR_LEN，即可知道該LCT header內是否包含LCT header extension。
* Codepoint(CP)：8 位元長。本欄位記錄了ALC物件所採行的FEC演算法之FEC encoding ID。
附帶一提，在DVB-IPDC CDP標準中，對TSI與TOI欄位的長度做了以下的限制：第一種許可的長度是TSI與TOI均為16位元，第二種許可的長度則是TSI與TOI均為32位元。
另外，如圖7所示，在FLUTE通訊協定中，會使用到的LCT header extension主要為EXT_FDT與EXT_FTI。EXT_FDT只會存在於傳送FDT instance的ALC封包(TOI為0)中，負責記錄該FDT instance的FDT instance ID。圖8是EXT_FDT的欄位格式，基本上，EXT_FDT是一個固定長度的資料結構，以下為其所包含之欄位的說明:
* Header Extension Type(HET)：8位元長。EXT_FDT的HET為192。
* Version of FLUTE(V)：4位元長。為FLUTE的版本號碼，目前版本 (RFC 3926)的值為1。
* FDT Instance ID：20位元長。在每個FLUTE session開始運作時，FDT instance ID會均從0開始，然後依次遞增。當FDT instance ID的值從220 - 1變為0時，0會被視為大於220 - 1；換句話說，就是FLUTE接收端必須用大於20位元的欄位，來記錄接收到的FDT instance的ID。因此，FLUTE標準中也建議，在一個ID為n的FDT instance過時(expire)前，FLUTE發送端不可以重用n這個ID，來傳送其他的FDT instance。
在FLUTE中會使用到的第二種LCT header extension為EXT_FTI，用以承載ALC物件的FEC OTI。由於FEC OTI與ALC物件所採行的FEC演算法有關，因此，EXT_FTI的格式可再被細分成兩個部分：第一個部分是EXT_FTI的通用格式(general EXT_FTI format)，為圖9中最後一個欄位之外的其他所有欄位。對所有的FEC演算法來說，其EXT_FTI的通用格式都是一致的。第二個部分則是與FEC演算法相關的格式，為圖9中的FEC Encoding ID Specific Format欄位，此部分的格式對不同的FEC演算法來說則可能是不同的。以下是圖9中EXT_FTI所包含之欄位的說明:
* Header Extension Type(HET)：8位元長。EXT_FTI的HET為64。
* Header Extension Length(HEL)：8位元長。本欄位指定了EXT_FTI 的總長度，包含了FEC Encoding ID Specific Format欄位的部分。長度的計算單位為32位元。
* Transfer Length：48位元長。指定了ALC物件的原始長度，或是ALC物件經GZip編碼後的長度。長度的計算單位為1位元組。
* FEC Instance ID：16位元長。這個欄位只在FEC encoding ID為 128 ~ 255時，才會被使用到。在DVB-IPDC標準中，這個欄位的值都會被設定為0。
* FEC Encoding ID Specific Format：此部分的格式由ALC物件所採行的FEC演算法之FEC encoding ID決定。
在DVB-IPDC CDP標準中，僅納入了兩種FEC演算法：第一種是必備的 Compact No-Code FEC，FEC Encoding ID為0。第二種則是選擇性的 Raptor FEC，FEC Encoding ID為1。圖10是Compact No-Code FEC的 EXT_FTI專屬格式；基本上，這些欄位中的資訊，會被Compact No-Code FEC的區塊化演算法使用。至於Raptor FEC的EXT_FTI專屬格式，則請讀者參考DVB-IPDC CDP標準。以下為Compact No-Code FEC之EXT_FTI專屬格式的說明:
* Encoding Symbol Length：16位元長，為一個ALC物件中，每個 encoding symbol(即source symbol)的長度，單位為1位元組。不過，ALC物件的最後一個encoding symbol，可能會短於前述的長度。
* Maximum Source Block Length：32 位元長，為每個source block 中最多所能包含的encoding symbol的數目。
圖6及圖7中的FEC Payload ID，是在ALC封包中，標示其包含了哪些 encoding symbol的辨識資訊。至於FEC Payload ID的實際格式，則是由作用於ALC物件的FEC演算法決定的。基本上，DVB-IPDC CDP標準中所納入的兩種FEC演算法，兩者所定義的FEC Payload ID之格式是相同的，如圖11所示。以Compact No-Code FEC來說，在一個FLUTE封包內，可包含一個或數個連續的encoding symbol。Source Block Number欄位定義了前述的 encoding symbol，所歸屬的source block之號碼。Encoding Symbol ID欄位則為開始的第一個encoding symbol的編號。另外，若有讀者對 Raptor FEC之FEC Payload ID欄位的說明有興趣，請參考DVB-IPDC CDP 標準。
其他DVB-IPDC CDP標準所指定的特性
在DVB-IPDC CDP標準中，對RFC 3926所定義的FLUTE通訊協定，做了一些功能上的擴充與使用上的限制。首先，針對FDT instance的XML文件格式，DVB-IPDC CDP標準新增了定義檔案群組的功能。一個檔案可歸屬於一個或數個檔案群組，只要FLUTE接收端上的使用者，選用了檔案群組中的某個檔案，則該檔案群組所包含的所有檔案，都會被下載及儲存在FLUTE接收端上。檔案群組可應用在下載一組網頁的檔案，或是下載某個包含了數個檔案之軟體。
另外，FLUTE接收端需要FLUTE session的傳輸參數，以連上FLUTE session所包含的FLUTE channel，接收FDT instance及其他的ALC物件。在FLUTE標準(RFC 3926)中，只提出了FLUTE session傳輸參數應包含的種類，如下所示:
* FLUTE session傳送端的IP位址。
* FLUTE session的TSI。
* FLUTE session所包含的FLUTE channel數。
* 每個FLUTE channel的目的IP位址與通訊阜號碼。
* FLUTE session的開始與結束時間。
* FLUTE session或FLUTE channel預設的FEC演算法。
不過，在RFC 3926中，並沒有定義該用什麼格式來記錄前述的傳輸參數。因此，在DVB-IPDC CDP標準中，定義了基於SDP(Session Description Protocol，對話描述協定)的傳輸參數記錄格式。
還有，由於FLUTE/ALC原本是設計在Internet上使用的，因此，一個 FLUTE session可提供多個傳輸率不同的FLUTE channel，讓FLUTE接收端依其接收狀況與合適的傳輸率，選擇要接收哪些FLUTE channel。不過，在 DVB-H廣播網路上，由於每個FLUTE接收端的接收狀況，遠比在Internet上要相近得多，因此，DVB-IPDC CDP標準，只把FLUTE session僅包含一個 FLUTE channel的選項，定義為FLUTE傳送端與FLUTE接收端必備的功能。至於FLUTE session內包含多個FLUTE channel，僅被定義成一種選擇性的功能。
在DVB-IPDC CDP標準內，把FLUTE session的SDP檔案中，第一個出現的 FLUTE channel，稱之為基礎FLUTE channel(base FLUTE channel)。由於FLUTE接收端可能僅能接收基礎FLUTE channel，因此，若FLUTE傳送端希望在一個FLUTE session內，包含一個以上的FLUTE channel，FLUTE 傳送端必須能確保前述的FLUTE接收端，可以透過基礎FLUTE channel收到足夠的資料。另外，在基礎FLUTE channel內所傳送的FDT insatnce，也不能包含在其他FLUTE channel內傳送之ALC物件的屬性。
最後，我們再來探討一下FLUTE如何提供可靠傳輸的方法，亦即如果有 FLUTE接收端少收了某些該收到的encoding symbol，該怎麼辦呢？第一種方法是前面提過的，透過ALC下層的FEC組成元件，傳送額外的FEC資訊到 FLUTE接收端。第二種方法則是透過廣播網路上常使用的輪播方式(data carousel)，將所有的encoding symbol重複透過DVB-H廣播網路傳送。第三種方法則是透過重傳機制(retransmission)，該機制包含在DVB-IPDC CDP標準內所定義的相關傳送程序(associated delivery procedure) 中，只適用於當雙向的點對點IP網路存在時。由於FLUTE通訊協定主要的設計哲學，是希望FLUTE接收端不要傳送回饋資訊給FLUTE傳送端，因此，FLUTE的重傳機制，僅是一種選擇性的功能。而且，只能使用於當FLUTE session 內的某個ALC物件，在DVB-H廣播網路上已經停止傳送時。此外，FLUTE的重傳機制也不能用來傳送過時版本的FLUTE檔案。
FLUTE的重傳機制需要在雙向IP網路上，建置所謂的修復伺服器(repair server)。為了減少修復伺服器的負載，每個FLUTE session可使用超過一個以上的修復伺服器。當某個ALC物件已經停止傳輸之後，FLUTE接收端需等待一段隨機的後退時間(back-off time)，然後，再選擇一部修復伺服器，透過雙向IP網路發送HTTP格式的檔案修復請求訊息(file repair request message)，要求修復伺服器將指定的一個或數個encoding symbol傳送給FLUTE接收端。修復伺服器有以下的兩種回應方式：第一種是透過HTTP格式的檔案修復回應訊息(file repair response message)，將encoding symbol透過雙向IP網路傳回給FLUTE接收端。第二種方式則是透過原本的FLUTE session，或另一個FLUTE session，將encoding symbol透過DVB-H廣播網路傳送給所有的FLUTE接收端。
結論
FLUTE是IP化的行動電視系統中，負責以廣播或多點傳送模式，傳遞ESG資料與使用者檔案的基礎通訊協定。在本文中，我們以DVB-IPDC標準的角度出發，說明了FLUTE應用於DVB-H廣播網路上的系統架構、運作原理、封包格式，以及DVB-IPDC CDP標準對FLUTE的一些擴充與限制。在不影響行文清晰度的前提下，筆者略去了一些技術細節，例如：Raptor FEC、FDT instance詳細的XML檔案格式、FLUTE session的SDP檔案格式、FLUTE重傳機制的細節、以及FLUTE在DVB-H廣播網路上可能的傳送模式。對前述內容有興趣的讀者，可參考筆者在文中附帶的文獻引用資訊，去研讀更進一步的技術細節。
