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 (r): 2 位长，其值须为 0。
● Transport Session Identifier flag (S) 与 TSI: S 是 1 位的字段，其与另一个 1 位的Half-word flag (H) 字段，共同决定了 Transport Session Identifier (TSI) 字段的长度。TSI 的位长度 = 32 x S + 16 x H。
● Transport Object Identifier flag (O) 与 TOI: O 是 2 位的字段，其与前述的 H 字段，共同决定了 Transport Object Identifier (TOI) 字段的长度。TOI 的位长度 = 32 x O + 16 x 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 开始后经过的时间，单位为 1ms。
● Expected Residual Time present flag (R) 与 ERT: R 是 1 位的字段，其决定了 Expected Residual Time (ERT) 字段的存在与否。若 R = 0，则表示 ERT 字段不存在，若 R = 1，则表示 ERT 字段存在。ERT 字段用来指定 FLUTE session 中由 TOI 指定的 ALC 对象，还会被继续传送多少时间，单位也为 1ms。
● 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。图八是 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的传输参数记录格式。
还有，由于FLUTE/ALC原本是设计在Internet上使用的，因此，一个FLUTE session可提供多个传输率不同的 FLUTE channel，让FLUTE接收端依其接收状况与合适的传输率，选择要接收哪些FLUTEchannel。不过，在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 广播网络传送。第三种方法则是透过重传机制，该机制包含在 DVB-IPDC CDP 标准内所定义的相关传送程序中，只适用于当双向的点对点 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格式的档案修复请求讯息，要求修复服务器将指定的一个或数个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 广播网络上可能的传送模式。
由于 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 (r): 2 位长，其值须为 0。
● Transport Session Identifier flag (S) 与 TSI: S 是 1 位的字段，其与另一个 1 位的Half-word flag (H) 字段，共同决定了 Transport Session Identifier (TSI) 字段的长度。TSI 的位长度 = 32 x S + 16 x H。
● Transport Object Identifier flag (O) 与 TOI: O 是 2 位的字段，其与前述的 H 字段，共同决定了 Transport Object Identifier (TOI) 字段的长度。TOI 的位长度 = 32 x O + 16 x 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 开始后经过的时间，单位为 1ms。
● Expected Residual Time present flag (R) 与 ERT: R 是 1 位的字段，其决定了 Expected Residual Time (ERT) 字段的存在与否。若 R = 0，则表示 ERT 字段不存在，若 R = 1，则表示 ERT 字段存在。ERT 字段用来指定 FLUTE session 中由 TOI 指定的 ALC 对象，还会被继续传送多少时间，单位也为 1ms。
● 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。图八是 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的传输参数记录格式。
还有，由于FLUTE/ALC原本是设计在Internet上使用的，因此，一个FLUTE session可提供多个传输率不同的 FLUTE channel，让FLUTE接收端依其接收状况与合适的传输率，选择要接收哪些FLUTEchannel。不过，在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 广播网络传送。第三种方法则是透过重传机制，该机制包含在 DVB-IPDC CDP 标准内所定义的相关传送程序中，只适用于当双向的点对点 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格式的档案修复请求讯息，要求修复服务器将指定的一个或数个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 广播网络上可能的传送模式。
