对于通过系统的例如互联网协议(IP)多播、IP数据播送(IPDC) 以及多媒体广播/多播服务(MBMS)的点对多点(PtM)服务(也 称作一对多服务)来说，例如诸如多媒体文件下载的文件传递是一 项重要的服务。
然而，用于通过例如诸如文件传输协议(FTP)和超文本传输协 议(HTTP)的点对点(PtP)协议传送文件的许多特征对于PtM情 境来说是有问题的。特别地，利用例如传输控制协议(TCP)的类似 PtP确认(ACK)协议进行文件的可靠传递，即文件的有保证传送不 是切实可行的。
国际工程任务组(IETF)的可靠多播传输(RMT)工作组目前 处于对两类错误弹性多播传输协议进行标准化的过程中。在第一分 类中，可靠性通过(主动式)前向纠错(FEC)的使用来实施，即通 过发送能够帮助接收机重构错误数据的一定量冗余数据；在第二分 类中，可靠性通过使用接收机的反馈来实施，即，由接收机发送关 于接收到的数据的确认(ACK)或非确认(NACK)。
异步分层编码(ALC)是属于第一分类的协议实例，而面向NACK 的可靠多播(NORM)协议属于第二分类。这些协议可在接入网络 上使用，该接入网络包括但不限于无线多址网络，例如通用移动通 信系统(UMTS，包括全球移动通信系统演进无线接入网(GERAN， Global System for Moblie Communications Evolution Radio Access Network)和UMTS陆地无线接入网(UTRAN，UMTS Terrestrial Radio Access Network))、无线局域网(WLAN)、数字视频广播-陆地 (DVB-T)网络和数字视频广播-卫星(DVB-S)网络。
NACK消息一般不是NORM特定的，但它们也可结合其他协议 或系统使用，例如结合支持由基于单向传输的文件传递(FLUTE， File Delivery over Unidirectional Transport)协议控制的会话的系统。
FLUTE是在FEC和ALC构建块上构建的一对多传输协议。其 旨在用于通过单向系统从发射机至接收机的文件传递。其具有使其 适于无线PtM系统的专门作用。在由上述的IETF的RMT工作组所 准备的标题为“FLUTE-基于单向传输的文件传递”(互联网草案) 的公开物中更加详细地描述了该FLUTE协议的细节。
FLUTE的使用例如由第三代合作伙伴(3GPP)规定以用于 MBMS系统会话中的文件下载。FEC可能用于或可能不用于这种 FLUTE会话中。不管怎样，不是会话中的所有接收机都能够被期望 当在会话结束时接收整个文件。为此，3GPP处于定义PtP修复会话 的过程中，其中允许接收机经由NACK消息向发射机或修复服务器 进行关于修复数据符号的传输的信号请求(所述修复数据符号例如 为没有被接收机正确接收的数据符号)，以便接收足够的数据符号 并且接着能够重构下载的内容。在所述的NACK消息中，所述接收 机所需的所述修复数据符号必须被充分地标识，从而修复服务器能 够确定哪些数据符号必须被传送或重传。
当接收机被预定用于修复会话时，则在接收机和修复服务器之 间建立例如HTTP会话的PtP会话，其中所需的修复数据符号被传送 到接收机。
尽管数据符号在基于例如用户数据报协议(UDP)的不可靠协 议的PtM会话中被传送，并且修复数据符号在基于例如传输控制协 议(TCP)的可靠协议的PtP会话中被传送，目前修复数据符号被配 备成与数据符号具有相同报头信息。该报头信息包括：
-默认的分层编码传输(LCT)报头，
-LCT报头扩展段，以及
-FEC净荷ID段。
LCT报头包括：
-具有一排标记的第一段，LCT报头长度字段和用于表示FEC编 码ID的码点字段，
-拥塞控制信息(CCI)，
-传输会话标识符(TSI)，
-传输对象标识符(TOI)，
-发送方当前时间(SCT)，以及
-期望剩余时间(ERT)。
然而，修复数据符号应该以最有效的方式发送使得接收机能够 容易地识别修复数据符号并且完成对在多播/广播PtM会话期间部分 下载的文件的解码。因此应该保持少量的在修复数据符号传输中带 来的开销，所述开销通常代表已经发送的数据符号的重传，以减小 PtP响应时间而同时保持接收机操作简单。

因此在用于以点对多点和点对点会话二者来传送数据符号的系 统中需求更为有效的方法、系统、发射机、网元、接收机和软件应 用。
提出了一种用于传送数据符号的方法，包括在点对多点传输会 话中将一个或多个数据符号从发射机传送到一个或多个接收机，其 中所述数据符号配备有服从文件传递协议的第一类型报头；以及在 点对点修复会话中将一个或多个修复数据符号从修复服务器传送到 所述接收机中的一个特定接收机，其中所述修复数据符号配备有至 少部分地服从所述相同文件传递协议的一个或多个第二类型报头。
所述系统可表示任何无线或有线系统，其中数据符号从至少一 个发射机传送到一个或多个接收机。所述点对多点传输可以是广播 传输，其中所述发射机寻址所有接收机，或者所述点对多点传输可 以是多播传输，其中所述发射机仅寻址所有接收机的一个子群。所 述系统例如可以在UMTS、LAN、WLAN、DVB-T或DVB-S的环境 中部署，并且可旨在将例如多媒体文件的内容分布于多个接收机。 所述一个或多个数据符号的所述传输可在单向或双向的传输链路上 执行。
所述传送的数据符号例如可涉及将要被传输到所述接收机的内 容。该内容可被分段并被处理以允许到所述接收机的传输，而所述 数据符号将被理解为该分段和处理的结果。例如，一个数据符号可 表示一个或多个编码符号(例如，编码分组)，该编码符号通过例 如多媒体文件或其部分的传输对象的FEC编码来获得。其中，每个 数据符号仅可表示一个信息携带单元，例如一个二进制数字(位) 或多个信息携带单元。
所述数据符号配备有服从例如FLUTE协议的文件传递协议的第 一类型报头。所述配备可通过将所述报头添加到所述数据符号或通 过创建在所述第一类型报头和所述数据符号之间的关联的其他技术 来执行。所述第一类型数据符号和它们的关联数据符号例如可以形 成FLUTE分组。第一类型报头例如可包含有关所述接收机和所述发 射机处的协议实体之间的所述数据符号的逻辑传输的信息。
至少在一个所述接收机(其被称作特定接收机)处，需要接收 修复数据符号，这归因于例如诸如所传送的数据符号的不正确接收 或丢失的多种原因。所述特定接收机可在数据符号的所述传输期间 或在数据符号传输完成以后意识到需要接收修复数据符号。
所述修复数据符号例如可以是没有被特定接收机接收到的传送 数据符号的简单副本。同样，它们关于编码和实际内容可以不同。 修复数据符号用于向所述特定接收机提供所述特定接收机所需的一 定量信息。
为了触发来自所述修复服务器的修复数据符号的传输，所述特 定接收机可在修复请求消息中将修复数据信息向所述修复服务器进 行信号发送。这可发生在点对点传输中。因此修复服务器能够生成 合适的修复数据符号并且将它们传送到特定的接收机。该修复数据 符号的传输在点对点修复会话中执行。
所述修复数据符号配备有至少部分地服从相同文件传递协议的 一个或多个第二类型报头。因此所述第二类型数据符号报头例如可 完全服从所述文件传递协议，这样其需要定义至少两种不同类型的 数据符号报头。同样，所述第二类型报头可表示由所述文件传递协 议所定义的一个或多个数据符号报头的修改，其中所述修改可包括 对所述第一类型报头的参数的所有形式的添加、删除或改变以及组 合几种可能修改的第一类型报头。优选地，所述修改可仅包括通过 删除所述第一类型报头的至少一个参数的所述第一类型报头的缩 减。所述配备例如可通过将第二类型报头添加到修复数据符号或通 过将所述修复数据符号与所述第二类型报头关联的其他技术来完 成。例如，几个修复数据符号可组合成一个HTTP分组，并且一个 第二类型报头还可包括在所述HTTP分组中，其中所述第二类型报 头包括对于所述HTTP分组中所有修复数据符号都有效的信息。
因此本发明一方面提出针对数据符号的传输使用不同类型的报 头，并且另一方面修复数据符号。该建议考虑到这样的事实，即在 点对多点会话中传送的数据符号是基于不可靠协议(例如UDP)的， 而在点对点会话中传输的数据符号是基于可靠协议(例如TCP)的， 因此必须包括在用于该数据符号的第一类型报头中的至少一些参数 不必包括在由修复数据符号使用的第二类型数据符号报头中。根据 本发明的该方法考虑在具有明显减小的开销的情况下更为有效地传 输修复数据符号。利用至少部分地服从所述文件传递协议的第二类 型报头，在修复服务器和接收机的协议实例处以及相应的实施可能 不需要或仅需要少量的改变。
根据本发明，所述第一类型报头可包括在所述第二类型报头中 没有包括的至少一个参数，并且所述参数可以与点对多点传输相关。 所述参数例如可以是拥塞控制信息(CCI)、发送方当前时间(SCT)、 期望剩余时间(ERT)以及一些情况下的传输会话标识符(TSI)。
根据本发明，在所述点对多点传输会话中，所述文件传递协议 可使用用户数据报协议的服务。
根据本发明，在所述点对点修复会话中，所述文件传递协议可 使用传输控制协议的服务。
根据本发明，在所述点对点修复会话中，所述文件传递协议可 使用超文本传输协议的服务。该协议又可使用传输控制协议的服务。
根据本发明，所述文件传递协议可以是基于单向传输的文件传 递(FLUTE)协议，并且所述数据符号和所述修复数据符号可表示 FLUTE编码符号。所述FLUTE编码符号例如可通过对传输对象的 部分进行前向纠错编码来获得，所述传输对象将被传递到所述点对 多点会话中的所述一个或多个接收机。每个数据符号例如可表示一 个或几个编码符号。
根据本发明，所述FLUTE协议可使用超文本传输协议(HTTP) 的服务，并且所述HTTP可在所述修复服务器和所述特定接收机之 间传输HTTP分组。为此，所述数据符号和它们关联的一个或多个 第二类型报头可以被作为净荷并入所述HTTP分组。
根据本发明的第一实施方式，一个FLUTE编码符号和一个关联 的第二类型报头的组合形成压缩FLUTE分组，并且至少一个所述 HTTP分组包括HTTP分组报头和一个或多个所述压缩FLUTE分组。
根据本发明的所述第一实施方式，所述压缩FLUTE分组的所述 第二类型报头至少包括分层编码传输报头的一部分、所述压缩 FLUTE分组中的所述FLUTE编码符号的标识符以及所述FLUTE编 码符号的大小。所述分层编码传输报头可来自于分层编码传输构建 块，FLUTE协议层构建于其上。所述FLUTE编码符号的所述标识 符例如可以是提供源块号(SBN)的FEC净荷ID和对应于所述 FLUTE编码符号的编码符号标识符(ESI)。
根据本发明的第二实施方式，所述至少一个HTTP分组具有多部 分多用途互联网邮件扩展(MIME)结构，并且所述压缩FLUTE分 组通过MIME边界彼此隔开并与所述HTTP分组报头隔开。则由 MIME边界构成的隔开可允许在所述第二类型报头中跳过关于编码 符号大小的参数。
根据本发明的第二实施方式，所述压缩FLUTE分组的所述第二 类型报头包括分层编码传输报头的一部分，以及所述压缩FLUTE分 组中所述FLUTE编码符号的标识符。
根据本发明的第三实施方式，至少一个所述HTTP分组包括 HTTP分组报头、包括至少两个FLUTE编码符号和相应的关联标识 符的一个或多个块、以及每个所述块的一个相应的第二类型报头， 其中每个相应第二类型报头对于相应块的所有FLUTE编码符号是有 效的。FLUTE编码符号与块的组合允许每个块仅使用一个第二类型 报头而不必每个FLUTE编码符号提供一个第二类型报头。与块组合 的所述FLUTE编码符号有利地具有相同的特性，例如相同的大小、 相同的TOI和相同的TSI，并且针对每个FLUTE编码符号而不同的 特性则可被并入FLUTE编码符号的所述块中。
根据本发明的所述第三实施方式，所述至少一个HTTP分组具有 MIME结构，以及所述HTTP分组报头、所述块和所述第二类型报 头由MIME边界相互隔开。然后可以不需要显式地传输FLUTE编码 符号的块的大小。
根据本发明的所述第三实施方式，所述相应的第二类型报头包 括在所述相应块中的所述FLUTE编码符号的大小和分层编码传输报 头的一部分。
根据本发明的所述第三实施方式，至少一个所述块包括FLUTE 编码符号、相应的关联标识符、相应的分层编码传输报头长度和至 少一个分层编码传输报头扩展。所述LCT报头扩展例如可以是 EXT_FTI或EXT_FDT。所述相应的LCT报头长度可指示是否存在 一个或多个所述LCT报头扩展。
根据本发明的第四实施方式，至少一个所述HTTP分组包括 HTTP分组报头、一个第二类型报头和包括至少两个FLUTE编码符 号的一个或多个块。接着仅一个第二类型报头用于包括在所述HTTP 分组中的所有FLUTE编码符号，其用作为所有所述FLUTE编码符 号提供所有报头信息的索引对象。接着所述第二类型报头例如可以 被分段成与FLUTE编码符号的所述块的每一个相关的子报头。
根据本发明的所述第四实施方式，所述至少一个HTTP分组具有 MIME结构，并且所述HTTP分组报头、所述一个第二类型报头以 及所述一个或多个块由MIME边界互相隔开。这可以允许跳过 FLUTE编码符号的块的尺寸的显式(explicit)传输。
根据本发明的所述第四实施方式，所述第二类型报头包括在所 述HTTP分组中的每个相应块的一个相应子报头，并且每个所述的 相应子报头包括分层编码传输报头的一部分、所述相应块中所述 FLUTE编码符号的大小，所述相应块中FLUTE编码符号的数目以 及所述相应块中每个FLUTE编码符号的一个标识符。
根据本发明的所述第四实施方式，至少一个所述子报头包括所 述相应块中每个FLUTE编码符号的一个分层编码传输报头长度、以 及用于所述相应块中至少一个所述FLUTE编码符号的至少一个分层 编码传输报头扩展。所述LCT报头扩展例如可以是EXT_FDT或 EXT_FTI。所述LCT报头长度可以指示是否存在一个或多个所述 LCT报头扩展。
根据本发明，所述第二类型报头可进一步包括所述点对多点传 输会话的标识符。所述标识符例如可以是传输会话标识符(TSI)。 然而，如果仅存在一个传输会话或如果从上下文完全清楚所述 FLUTE编码符号所涉及的是哪些传输会话，则所述传输会话的所述 标识符可以不需要。
根据本发明，所述第二类型报头可进一步包括与所述FLUTE编 码符号相关的传输对象的标识符。该标识符例如可以是传输对象标 识符(TOI)。然而，如果每个传输会话仅一个传输对象被传送，则 所述标识符可以不需要。
根据本发明，所述第二类型报头可进一步包括分层编码传输报 头扩展。这些LCT报头扩展例如可以是EXT_FTI或EXT_FDT。
根据本发明，所述分层编码传输报头的所述部分可包括分层编 码传输版本号、拥塞控制标记、预留空间、传输会话标识符标记、 传输对象标识符TOI标记、半字标记、发送方当前时间标记、期望 剩余时间标记、关闭会话标记、关闭对象标记、分层编码传输报头 长度以及码点。所述分层编码传输报头的所述部分例如可以是4个 字节的长度。
进一步提出一种用于传输数据符号的系统，该系统包括发射机、 一个或多个接收机和修复服务器，其中在点对多点传输会话中将一 个或多个数据符号从所述发射机传送到所述一个或多个接收机，其 中所述数据符号配备有服从文件传递协议的第一类型报头，其中在 点对点修复会话中将一个或多个修复数据符号从所述修复服务器传 送到所述接收机的一个特定接收机，并且其中所述修复数据符号配 备有至少部分地服从所述相同文件传递协议的一个或多个第二类型 报头。
根据本发明的系统，所述第一类型报头可包括在所述第二类型 报头中没有包括的至少一个参数，并且所述参数可以与点对多点传 输相关。
进一步提出一种用于传送数据符号的系统中的发射机，该发射 机包括被设置用于在点对多点传输会话中将一个或多个数据符号从 所述发射机传送到一个或多个接收机的装置，其中所述数据符号配 备有服从文件传递协议的第一类型报头，其中在点对点修复会话中 将一个或多个修复数据符号从修复服务器传送到所述接收机的一个 特定接收机，并且其中所述修复数据符号配备有至少部分地服从所 述相同文件传递协议的一个或多个第二类型报头。所述发射机和所 述修复服务器可以共同定位或甚至是相同的。
根据本发明的发射机，所述第一类型报头可包括在所述第二类 型报头中没有包括的至少一个参数，并且所述参数可以与点对多点 传输相关。
进一步提出一种用于传送数据符号的系统中的网元，其中在点 对多点传输会话中将一个或多个数据符号从所述发射机传送到一个 或多个接收机，并且其中所述数据符号配备有服从文件传递协议的 第一类型报头，所述网元包括被设置用于在点对点修复会话中将一 个或多个修复数据符号从所述网元传送到所述接收机的一个特定接 收机的装置，其中所述修复数据符号配备有至少部分地服从所述相 同文件传递协议的一个或多个第二类型报头。所述发射机和所述网 元可以共同定位或甚至是相同的。所述网元例如可以是修复服务器。
根据本发明的网元，所述第一类型报头可包括在所述第二类型 报头中没有包括的至少一个参数，并且所述参数可以与点对多点传 输相关。
进一步提出一种可在用于传输数据符号的系统的网元中执行的 软件应用，其中在点对多点传输会话中将一个或多个数据符号从发 射机传送到一个或多个接收机，并且其中所述数据符号配备有服从 文件传递协议的第一类型报头，该软件应用包括用于使得网元在点 对点修复会话中将一个或多个修复数据符号从所述网元传送到所述 接收机的一个特定接收机的程序代码，其中所述修复数据符号配备 有至少部分地服从所述相同文件传递协议的一个或多个第二类型报 头。
所述软件应用也可以是计算机程序产品，该计算机程序产品包 括存储在例如所述网元的存储器那样的介质上的程序代码。
根据本发明的软件应用，所述第一类型报头可包括在所述第二 类型报头中没有包括的至少一个参数，并且所述参数例如可以与点 对多点传输相关。
进一步提出一种用于传送数据符号的系统中的接收机，该接收 机包括被设置用于接收在点对多点传输会话中从发射机向一个或多 个接收机传送的一个或多个数据符号的装置，其中所述数据符号配 备有服从文件传递协议的第一类型报头；以及被设置用于接收在点 对点修复会话中来自修复服务器的一个或多个修复数据符号的装 置，其中所述修复数据符号配备有至少部分地服从所述相同文件传 递协议的一个或多个第二类型报头。
根据本发明的接收机，所述第一类型报头可包括在所述第二类 型报头中没有包括的至少一个参数，并且所述参数可以与点对多点 传输相关。
进一步提出一种可在用于传送数据符号的系统的接收机内执行 的软件应用，该软件应用包括用于使得接收机接收在点对多点传输 会话中从发射机传送到一个或多个接收机的一个或多个数据符号的 程序代码，其中所述数据符号配备有服从文件传递协议的第一类型 报头；以及用于使得接收机接收在点对点修复会话中来自修复服务 器的一个或多个修复数据符号的程序代码，其中所述修复数据符号 配备有至少部分地服从所述相同文件传递协议的一个或多个第二类 型报头。
所述软件应用也可以是计算机程序产品，该计算机程序产品包 括存储在例如所述接收机的存储器那样的介质上的程序代码。
根据本发明的软件应用，所述第一类型报头可包括在所述第二 类型报头中没有包括的至少一个参数，并且所述参数例如可以与点 对多点传输相关。
结合下面描述的实施方式，本发明的这些和其他的方面将变得 明显并且得到阐明。
附图说明
在附图中表示出：
图1a：根据本发明的点对多点(PtM)传输会话中的数据符号的 传输的示意图；
图1b：根据本发明的点对点(PtP)修复会话中的针对修复数据 符号的请求的信令的示意图；
图1c：根据本发明的PtP修复会话中的修复数据符号的传输的 示意图；
图2a：根据本发明的用于在PtM传输会话中传输数据符号的协 议栈的示意图；
图2b：根据本发明的用于在PtP修复会话中传输修复数据符号 的协议栈的示意图；
图3a：根据本发明的第一实施方式的压缩FLUTE分组的示意图；
图3b：根据本发明的第一实施方式的将压缩FLUTE分组嵌入 HTTP分组的示意图；
图4a：根据本发明的第二实施方式的压缩FLUTE分组的示意图；
图4b：根据本发明的第二实施方式的将压缩FLUTE分组嵌入 HTTP分组的示意图；
图5a：根据本发明的第三实施方式的HTTP分组的示意图；
图5b：根据本发明的第三实施方式的公共FLUTE报头的示意图；
图5c：根据本发明的第三实施方式的编码符号的块的示意图；
图5d：根据本发明的第三实施方式的在使用LCT报头扩展情况 下的编码符号的可选块的示意图；
图6a：根据本发明的第四实施方式的HTTP分组的示意图；
图6b：根据本发明的第四实施方式的索引对象报头的示意图；
图6c：根据本发明的第四实施方式的编码符号的块的示意图；
图7：根据本发明的方法的示意性流程图。

作为初始说明，应该注意到本专利申请的介绍性部分的主题可 用于支持该详细的描述。
本发明提出使用两种不同的报头类型，一方面用于从发射机至 多个接收机的数据符号的PtM传输，以及另一方面用于从修复服务 器至所述接收机之一的修复数据符号的PtP传输。这考虑了这样的 事实，即数据符号的传输基于例如UDP的不可靠协议，并且由于修 复数据符号的传输因而需要更多的开销信息，其中该修复数据符号 的传输基于例如TCP的更为可靠的协议。
在本发明的该详细描述中，经常对FLUTE/UDP被用于PtM传 输情形以及HTTP/TCP被用于PtP传输情形的情况进行参考。应该 注意到该选择的本质仅是示例性的并且本发明可同样很好地在类似 的情境中应用，其中服从某个协议并且首先以PtM情境传送的数据 符号接着必须在PtP情境中重传，并且其中至少部分地必须遵守所 述协议。
图1a示出PtM会话，其中数据符号从发射机1传送到多个接收 机3-1...3-3。发射机连接到例如互联网的网络2，并且因此访问待分 布于广播或多播会话中的所述多个接收机的内容，例如在3GPP MBMS系统的范围内。为此，发射机包括处理器10、存储器11和 传输/接收(Tx/Rx)实例。内容在处理器10的控制下从网络2收集， 可能立即存储在存储器11中并接着被编码和调制用于经由Tx/Rx实 例12传输到接收机3-1...3-3的Tx/Rx实例32。所述处理器10被理 解为实施ISO/OSI协议栈的所有层的功能，尤其将内容编码到 FLUTE编码符号，连同FLUTE报头形成FLUTE分组，并且这些 FLUTE报头的生成由所述处理器10执行。
在所述接收机3-1...3-3处，其中仅特定的接收机3-1被详细地示 出，FLUTE分组经由Tx/Rx实例32被接收，由处理器30解调和解 码并且存储在存储器31中作为在所述接收机或附属设备中运行的任 意类型的应用的输入。
图1b示出当在所述特定接收机3-1处没有正确地接收FLUTE 分组时的情况，或当在所述特定接收机处3-1处没有接收到足够的 FLUTE分组时的情况，从而必须请求修复数据符号的传输，所述修 复数据符号允许所述特定接收机3-1重构由所述发射机1所分布的 完整内容。为此，从接收机3-1向修复服务器4发送修复请求消息， 该修复服务器具有与发射机1类似的结构(set-up)并甚至可以与所 述发射机1相同。所述修复请求消息的传输例如可以在HTTP会话 中发生。接着所述修复服务器4处理所述修复请求消息，该消息包 括关于所述特定接收机3-1所需的FLUTE分组的信息。
图1c示出修复服务器4的该处理的结果。当修复服务器4已确 定必须被发送到特定接收机3-1作为修复响应中的修复数据符号的 FLUTE编码符号时，它从网络2获取生成这些修复数据符号所需的 信息，例如所需FLUTE编码符号相关的传输对象或其部分。基于该 传输对象，修复数据符号(FLUTE编码符号)由处理器40生成，其 配备有压缩FLUTE报头以获得压缩FLUTE分组，并且接着在修复 响应消息中将其传送到特定的接收机3-1。
根据本发明，与用于FLUTE分组中的数据符号的FLUTE报头 相比，修复服务器4因而使用用于修复数据符号的压缩FLUTE报头， 即，压缩FLUTE报头包括比所述的FLUTE报头更少的参数或信息。 例如，PtM传输特定于并且在PtP传输中不需要的所有参数可在所述 压缩FLUTE报头中被跳过。还可能若干FLUTE编码符号共享相同 的压缩FLUTE报头。
图2a示意性地示出用于从发射机1处的FLUTE协议实体到接 收机3-1..3-3处的对等FLUTE协议实体的FLUTE编码符号(包括在 FLUTE分组中)的PtM传输的协议栈。为了传输FLUTE分组，FLUTE 层51使用UDP层53的服务，其接着又使用互联网协议(IP)层53 的服务。接着IP分组的实际传输由协议栈的更低层54完成。其中， 使用与FLUTE协议一致的FLUTE报头。
图2b示意性地示出用于从修复服务器4处的FLUTE协议实体 到特定接收机3-1处的对等FLUTE协议实体的FLUTE编码符号(包 括在压缩FLUTE分组中)的PtP传输的协议栈。在这种情况下，使 用压缩FLUTE报头。与图2a的协议栈相比较，FLUTE协议层51 现在使用下面的HTTP层55的PtP传输服务，该HTTP层驻留于TCP 层56之上。为此，压缩FLUTE分组被嵌入到HTTP分组中，该HTTP 分组接着在特定接收机3-1和修复服务器4处的对等HTTP实体之间 传输。为了该传输，HTTP/TCP使用下面的IP层53的服务。类似于 图2a，IP分组接着由更低层54传输。
本发明的第一实施方式
图3a示出根据本发明的第一实施方式的压缩FLUTE分组8。该 压缩FLUTE分组8包括压缩FLUTE报头6和作为净荷的一个编码 符号7。
在PtM传输中使用的FLUTE分组中的某些字段在PtP修复会话 中不再需要，因为与通过不可靠的UDP链路传递的PtM会话中的 FLUTE分组相反，修复响应通过可靠的TCP链路传递。因此本发明 提出将FLUTE分组拆分至仅有的最低限度，同时确保仅有必要的字 段包括在修复会话中使用的PtP响应净荷格式中。
图3a的压缩FLUTE报头包括默认分层编码传输(LCT)报头 61的前4个字节。相应的字段6100-6111以及它们的含意保持相同。 字段TSI标记6103、TOI标记6104和半字标记6105提供关于TSI 字段62和TOI字段63的大小的信息。字段码点6111用于将FEC 编码ID如由FLUTE协议指定的那样进行信号发送。如拥塞控制标 记6101、发送方当前时间标记6106、期望剩余时间标记6107、关闭 会话标记6108以及关闭对象标记6109的一些字段可以不在PtP响 应中发送，因为当通过可靠的PtP连接发送时，它们是没有用的。 以LCT报头段61的字段的比特数表示的大小和内容可总结如下：
V＝LCT版本号(4比特)
C＝拥塞控制标记(2比特)
R＝预留(2比特)
S＝TSI标记(1比特)
O＝TOI标记(2比特)
H＝半字标记(1比特)
T＝发送方当前时间标记(1比特)
R＝期望剩余时间标记(1比特)
A＝关闭会话标记(1比特)
B＝关闭对象标记(1比特)
HDR_LEN＝LCT报头长度(8比特)
CP＝码点(8比特)
压缩FLUTE报头6的TSI字段62可具有0、16、32、或48比 特的大小。该TSI需要用来标识该会话。特定的接收机可在PtP修 复会话之前加入到来自相同发射机的多于一个的FLUTE下载会话 中。因此特定的接收机必须指定在其PtP修复请求中请求PtP修复的 会话。修复服务器在PtP修复响应中发送TSI，使得特定接收机将能 够识别修复数据符号所属于的会话。发射机的地址和TSI唯一地标 识该会话。
压缩FLUTE报头6的TOI字段63可具有0、16、32、48、64、 80、96或112比特的大小。需要TOI来标识会话中的传输对象。FLUTE 下载可在单个会话中包括多于一个的传输对象(文件)。例如，音 频文件和视频文件可在相同FLUTE会话中被下载。特定的接收机必 须指定请求PtP修复的传输对象。(TOI，TSI)唯一地标识该传输 对象。
压缩FLUTE报头6的FEC净荷ID64取决于FEC编码ID。FEC 编码ID和FEC净荷ID之间的映射与由IETF在出版物RFC3452 “Forward Error Correction Building Block”和在出版物RFC3695 “Compact Forward Error Correction(FEC)Schemes”中以及由Digital Fountain的M.Luby于2004年6月7日在最新IETF互联网草案 “Simple Forward Error Correction Schemes”(可在 http://www.ietf.org/mailarchive/web/rmt/current/msg00312.html处获 得)中所定义的相同。例如，根据RFC3695(由MBMS FLUTE所 采用)，对于FEC编码ID＝0(No_Code(无码)FEC)，FEC净荷 ID包括以下：
SBN＝源块号(2字节)
ESI＝编码符号ID(2字节)。
压缩FLUTE报头6的字段编码符号大小65具有2字节的长度 并且包括在压缩FLUTE分组8中包含的作为净荷的编码符号7的大 小。
显然，根据本发明的第一实施方式的压缩FLUTE报头6不再包 括拥塞控制信息(CCI)、发送方当前时间(SCT)和期望剩余时间 (ERT)，尽管这些参数存在于用于FLUTE/UDP PtM传输的FLUTE 报头中。这些参数支持不可靠传输以及大规模可伸缩性，并且因此 不必被包括在用于FLUTE/HTTP PtP传输的压缩FLUTE报头6中。
如图3a中所给出的压缩FLUTE报头6的信息可以被认为是在 特定接收机3-1处重构所需的基本信息。本发明的其他实施方案可以 将任意数目的字段添加到该最小量信息中。然而，本发明的不同实 施方式可使用在一些方面可以与图3a所示的压缩FLUTE分组8不 同的压缩FLUTE分组。例如，不是所有的字段都存在，如果它们可 以从上下文中得出。例如，如果假定仅一个单独对象(文件)在FLUTE 会话中传递，则TOI字段63可被省略。在本发明的大多数普通实施 方式中，在多于一个的传输会话中很可能特定的接收机不需要请求 修复数据。。在这种情况下，从上下文来看，TSI是隐式的并且对在 PtP修复响应中发送的所有分组保持相同。因此TSI字段可以从压缩 FLUTE报头中省略。如图3中所给出的FLUTE分组报头6也可包 括另外的段，例如诸如EXT_FTI和EXT_FDT的LCT报头扩展段。
另外，修复服务器4还可发送PtM传输会话的发射机1的IP地 址，以便如果不能从环境中得知，则通过发射机的IP地址和TSI完 全识别该会话。
图3b示出将图3a的多个压缩FLUTE分组8-1...8-M嵌入HTTP 分组9中，其接着由在特定接收机3-1和修复服务器4处的对等协议 实体之间的HTTP/TCP传输。其中，HTTP分组9进一步包括具有试 验性的内容类型“x-flutePtP/compressedFlutePkt”的HTTP报头9， 其表示HTTP分组9的消息体包括压缩FLUTE分组8-1...8-M。
接着从修复服务器4传送到特定接收机3-1的PtP HTTP响应采 用下面各项：
HTTP/1.1 200 OK
Content-Type：x-flutePtP/compressedFlutePkt
Content-Length：TOTAL_LENGTH
Content_Transfer_Encoding：binary
Compressed FLUTE Packet-1
Compressed FLUTE Packet-2
…   
…
Compressed FLUTE Packet-M
其中，TOTAL_LENGTH是所有压缩FLUTE分组的大小。
本发明的第二实施方式
根据本发明的第一实施方式，在HTTP分组9中包括的信息(参 见图3a和图3b)可以不同的方式压缩或重新设置。
例如，根据本发明的第二实施方式，多部分-MIME结构可用于 隔开和发送压缩FLUTE分组。在多部分MIME结构中，“边界字符 串”隔开组成部分。所以图3a的压缩FLUTE报头6的编码符号大 小字段65可被省略，得到根据图4a的包含在压缩FLUTE分组8’ 中的压缩FLUTE报头6’。
图4b示出相应的HTTP分组9’。其中，HTTP报头字段 “Content-Type(内容类型)”被设置成“多部分/混合”。多部分的 主要子类型“混合”旨在当HTML体部分是独立的并且需要以特定 的顺序打包时被使用。其他的相关内容类型，例如“多部分/并列” 或“多部分/相关”也可被使用。特别地，在“多部分/并列”实体中， 体部分的顺序不是太重要。“多部分/相关”内容类型提供用于表示 聚集了相关MIME体部分的对象的公共机制。实施不能识别的任何 多部分子类型必须被视为子类型“多部分/混合”。
根据本发明的第二实施方式，常规边界字符串 (BOUNDARY_P2P_REPAIR_RESPONSE)92被这样限定，以标记 图4b的HTTP分组9’中的多部分-MIME结构的每一部分的开始。该 边界字符串82可长至70个字符。有利地，可以选择这样一种方式， 即它不在任何体部分中出现(或具有消失可能性的出现)。最终部 分后的边界字符串之后是“--”。
由于压缩FLUTE分组8’本质上是每次可被读取一个字节的二进 制对象，所以多部分MIME的每个部分的Content-Transfer-Encoding (内容传输-编码)被设置成“binary(二进制)”。“binary”编码 方案不涉及任何开销。例如“base64”的其他相关编码方案也是可以 使用的。“base64”编码可导致33％的开销。
包括HTTP报头91、边界字符串92和压缩FLUTE分组8’-1..8’-M 的图4b的HTTP分组9’则可借助于下面的伪代码表示为：
HTTP/1.1 200 OK
Content-Type：multipart/mixed；
boundary＝BOUNDARY_P2P_REPAIR_RESPONSE
--BOUNDARY_P2P_REPAIR_RESPONSE
Content-Type：x-flutePtP/compressedFlutePkt
Content-Transfer-Encoding：binary
Compressed FLUTE Packet-1
--BOUNDARY_P2P_REPAIR_RESPONSE
Content-Type：x-flutePtP/compressedFlutePkt
Content-Transfer-Encoding：binary
Compressed FLUTE Packet-2
…  
…
--BOUNDARY_P2P_REPAIR_RESPONSE
Content-Type：x-flutePtP/compressedFlutePkt
Content_Transfer_Encoding：binary
Compressed FLUTE Packet-M
--BOUNDARY_P2P_REPAIR_RESPONSE--
本发明的第三实施方式
根据本发明的第三实施方式，与第二实施方式相比较，多部分 MIME PtP HTTP响应的信息也可以更为有效的方式进行传送。现在 参考图5a到图5c对该第三实施方式进行描述。
修复服务器4可处理具有相同TSI和TOI的所有FLUTE分组并 且将它们的FLUTE编码符号7组合到共享相应公共FLUTE报头 6”-m的FLUTE分组M块7”-m中，其中整数m范围从1到M。通 过这种方式，避免了压缩FLUTE报头的相同部分的重复。
这可例如通过使用已经由HTTP支持的多部分MIME结构来实 施。为此，引入下面实验性的内容类型以标识多部分MIME结构中 的每一部分的内容：
“x_flutePtP/encSyrnbolHdr”表示包含公共FLUTE报头6”-m 的消息体，所述公共FLUTE报头6”-m对于多部分MIME结构的下 一部分(FLUTE编码符号的块7”-m)中的所有编码符号都是公共的。
“x-flutePtP/encSymbolVideo”表示消息体包含对应于视频对象 的FLUTE编码符号7-1-m..7-Mm-m(以及它们相应的FEC净荷ID 64-1-m..64-Mm-m，其中Mm表示每个块7”-m的FLUTE编码符号 的数目)。
“x_flutePtP/encSymbolAudio”表示消息体包含对应于音频对象 的FLUTE编码符号7-1-m..7-Mm-m(以及它们相应的FEC净荷ID 64-1-m..64-Mm-m)。
“x_flutePtP/encSymbolOther”表示消息体包含对应于“Other(其 他)”对象的FLUTE编码符号7-1-m..7-Mm-m(以及它们相应的FEC 净荷ID64-1-m..64-Mm-m)。
可选地，一些实施方式可以选择在不同的媒体类型之间不进行 区分，并且例如使用像“x_flutePtP/encSymbolData”的普通内容类 型。
图5a中示出得到的PtP HTTP响应9”的结构，在图5b中表示 出公共FLUTE报头6”-m，并且在图5c中表示出FLUTE编码符号 的块7”-m的格式。从图5c可以看到，针对每个FLUTE编码符号 7-1-m..7-Mm-m(以m定义从1到M的整数范围)的FEC净荷ID 64-1-m..64-Mm-m有利地被移入FLUTE编码符号的块7”-m中，因 为其是FLUTE-encoding-symbol-specific(特定的FLUTE编码符号)。 另外，由于FLUTE编码符号不是由MIME边界彼此隔离的，所以 FLUTE编码符号7-1-m..7-Mm-m的大小65-m必须在公共FLUTE报 头6”-m中定义，参见图5b。
图5a的HTTP响应9”可借助于伪代码来表述(注释以双正斜杠 开始)为：
HTTP/1.1 200 OK
MIME Version：1.0
Content-Type：multipart/mixed；
Boundary＝--BOUNDARY_P2P_REPAIR_RESPONSE
--BOUNDARY_P2P_REPAIR_RESPONSE
Content-Type：x-flutePtP/encSymbolHdr
Content-Transfer-Encoding：binary
//包括下面部分的所有FLUTE编码符号公共的
//TSI、TOI和编码符号大小。
//(在本例子中，下面的部分包含属于视频对象的所有编码符号)。
--BOUNDARY_P2P_REPAIR_RESPONSE
Content-Type：x-flutePtP/encSymbolVideo
Content-Transfer-Encoding：binary
//包括属于视频对象的所有FLUTE编码符号
//(以及它们的FEC净荷ID)
FEC Payload ID-1，Encoding Symbol-1
FEC Payload ID-2，Encoding Symbol-2
…
…
FEC Payload ID-M1，Encoding Symbol M1.
--BOUNDARY_P2P_REPAIR_RESPONSE
Content-Type：x-flutePtP/encSymbolHdr
Content-Transfer-Encoding：binary
//包括下面部分的所有FLUTE编码符号公共的
//TSI、TOI和编码符号大小。
//(在本例子中，下面的部分包含属于音频对象的所有编码符号)。
--BOUNDARY_P2P_REPAIR_RESPONSE
Content-Type：x-flutePtP/encSymbolAudio
Content-Transfer-Encoding：binary
//包括属于音频对象的所有FLUTE编码符号
//(具有它们的FEC净荷ID)。
FEC Payload ID-1，Encoding Symbol-1
FEC Payload ID-2，Encoding Symbol-2
…
…
FEC Payload ID-M2，Encoding Symbol-M2.
…
…
…
--BOUNDARY_P2P_REPAIR_RESPONSE
Content-Type：x-flutePtP/encSymbolHdr
Content-Transfer-Encoding：binary
//包括下面部分的所有FLUTE编码符号公共的
//TSI、TOI和编码符号大小。
//(在本例子中，下面的部分包含属于音频对象的所有编码符号)。
--BOUNDARY_P2P_REPAIR_RESPONSE
Content-Type：x-flutePtP/encSymbolOther
Content-Transfer-Encoding：binary
//包括属于音频对象的所有FLUTE编码符号
//(具有它们的FEC净荷ID)
FEC Payload ID-1，Encoding Symbol-1
FEC Payload ID-2，Encoding Symbol-2
…
…
FEC Payload ID-MM，Encoding Symbol-MM.
--BOUNDARY_P2P_REPAIR_RESPONSE-
到目前为止，本发明的第三实施方式假设没有例如EXT_FTI 和EXT_FDT的LCT报头扩展包含在FLUTE报头中。因此图5c中 所示的FLUTE编码符号的块7”-m不包括任何的LCT报头扩展。
然而，如果LCT报头扩展由至少一些FLUTE编码符号使用， 则目前参照图5a到图5c表示出的本发明的第三实施方式仅必须参 照FLUTE编码符号的块7”-m的结构而改变。这在图5d中示例性地 示出，其用作图5c的块的替代方式并且因此保持了相同的编号。
根据图5c，FLUTE编码符号的块7”-m还包括编码符号 7-1-m..7-Mm-m，其中整数m的范围从1到M，并且其中Mm是每 个块m的编码符号的数目，而M是块的总数。如图5c，在所述块中 包括针对每个编码符号的FEC净荷ID 64-1-m..64-Mm-m，并且所述 FEC净荷ID 64-1-m..64-Mm-m位于相应编码符号之前。然而，为了 解决由至少一些编码符号对LCT报头扩展的使用，针对每个相应编 码符号7-1-m..7-Mm-m的LCT报头长度字段(HDR_LEN)6110-1-m.. 6110-Mm-m被引入块7”-m中。这些LCT报头长度字段指示LCT报 头扩展是否被使用，并且它们中的多少与每个编码符号关联。接着 这些LCT报头扩展68-1-m..68-Mm-m分别在LCT报头长度字段后被 包括。
在图5d的例子中，在第一编码符号中出现两个EXT_FTI，在 第二编码符号中没有EXT_FTI，并且在块的最后一个编码符号中出 现一个EXT_FTI。在这种情况下，在公共编码符号报头(图5b中示 出的6”-m)中包括的HDR_LEN字段6110可能没有意义。
容易理解用于支持LCT报头扩展使用的上述方法也对 EXT-FDT LCT报头实例有效，当编码符号属于文件分布表(FDT) 实例时，使用这些报头实例。
本发明的第四实施方式
本发明的又一个实施方式通过重新设置在PtP HTTP响应中包 括的信息得到，如以下参照图6a至图6c所描述。
根据本发明的该实施方式，与相同的TSI和TOI关联的FLUTE 编码符号被再次存储在FLUTE编码符号(具有范围从1到M的m) 的块7-m中，并且公共FLUTE报头用于每个块的FLUTE编码符 号；然而，与第三实施方式相比较，所有公共FLUTE报头的字段被 组合到一个索引对象6中，并且在FLUTE编码符号的一个块7-m 中包括的所有FLUTE编码符号的FEC净荷ID也不再如在第三实施 方式中那样存储在FLUTE编码符号的所述块中，而是存储到FEC 净荷ID 64-1-m...64-Mm-m的特定块排列中，其也被并入所述索引对 象6中。这就允许对PtP HTTP响应9中的每个期望的FLUTE编 码符号的随机访问。
在图6a中示出该HTTP响应(分组)9。再次，具有MIME 边界92的多部分MIME结构可用于隔开索引对象6和不同类型的 FLUTE编码符号的块7-m。此处定义了新的内容类型 “xflutePtP/IndexObject”，其表示消息体包括索引对象6。
图6b表示在HTTP响应9中发送的所有编码符号的信息 (TSI、TOI，编码符号长度、FEC净荷ID)的索引对象6的格式。 索引对象6可以被理解为包括索引为m＝1...M的M个子报头(第 三实施方式的修改的公共FLUTE报头)，其中每个所述的子报头涉 及特定的TSI、TOI、FLUTE编码符号大小并且自然涉及FLUTE编 码符号的每个块7-m的FLUTE编码符号Mm的数目，并且其中这 些量值分别存储在字段62-m、63-m、65-m和67-m中。每个所述子 报头还包括LCT报头61-m的一部分以及FEC净荷ID 64-1-m..64-Mm-m的所述块特定排列。
通过该信息，特定接收机3-1可将每个FEC净荷ID映射到接 收到的字节流中的唯一字节范围。因此特定的接收机3-1可随机地访 问任意期望的编码符号。FLUTE编码符号的块7-m的格式(其中， m的范围从1到M，并且M表示FLUTE编码符号的块的数目)在 图6c中示出。显然，与本发明的第三实施方式相比较，在FLUTE 编码符号的块中没有包括FEC净荷ID，因为现在这些都没有包括在 索引对象6中。
图6a的HTTP响应9可以伪代码表述(注释以双正斜杠开始) 为：
HTTP/1.1 200 OK
MIME Version：1.0
Content-Type：multipart/mixed；
boundary＝--BOUNDARY_P2P_REPAIR_RESPONSE
--BOUNDARY_P2P_REPAIR_RESPONSE
Content-Type：x-flutePtP/IndexObject
Content-Transfer-Encoding：binary
//包括索引对象，
//该索引对象包含访问由(TSI、TOI、FEC净荷ID)
//唯一标识的任何FLTUE编码符号所需的所有信息。
--BOUNDARY_P2P_REPAIR_RESPONSE
Content-Type：x-flutePtP/encSymbolVideo
Content-Transfer-Encoding：binary
//包括属于视频对象的所有FLUTE编码符号。
Encoding Symbol-1
Encoding Symbol-2
…
…
Encoding Symbol-M1.
--BOUNDARY_P2P_REPAIR_RESPONSE
Content-Type：x-flutePtP/encSymbolAudio
Content-Transfer-Encoding：binary
//包括属于音频对象的所有FLUTE编码符号。
Encoding Symbol-1
Encoding Symbol-2
…
…
Encoding Symbol-M2.
…
…
…
--BOUNDARY_P2P_REPAIR_RESPONSE
Content_Type：x-flutePtP/encSymbolOther
Content-Transfer-Encoding：binary
//包括属于“Other”对象的所有编码符号。
Encoding Symbol-1
Encoding Symbol-2
…
…
Encoding Symbol-MM.
--BOUNDARY_P2P_REPAIR_RESPONSE
本发明的第四实施方式的描述假设没有像EXT_FTI和 EXT_FDT的LCT报头扩展与编码符号相关联。然而应该注意到如 本发明的第三实施方式应用到的类似技术(见图5d)也可应用于本 发明的第四实施方式。为此，在每个子报头中简单地包括LCT报头 长度的排列，该子报头为每个编码符号指示LCT报头扩展是否被使 用以及被使用多少。则该排列的条目表示存储在每个子报头的编码 符号特定的数据结构中的LCT报头扩展的数目。
图7描述根据本发明的用于传送数据符号的方法的示例性流 程图。在该流程图中，为了简化表示，假设发射机1和修复服务器4 由同一设备实现。
在第一步骤701中，例如通过对在PtM会话中将被传输到多 个接收机3-1...3-3的传输对象的部分进行FEC编码，发射机1生成 FLUTE编码符号。接着在步骤702中，这些FLUTE编码符号被配 备有服从FLUTE协议的FLUTE报头(第一类型报头)，生成FLUTE 分组，并接着在步骤703中被传送到所述多个接收机。这例如可通 过使用UDP和下层IP协议的服务来完成。接着在接收机3-1...3-3 处以及在至少所述接收机之一即特定接收机3-1处接收所传送的 FLUTE分组，由于分组的丢失或不正确的接收或由于其他的原因， 发现将需要修复数据分组的附加接收。接着特定接收机3-1将修复请 求通过信号发送到修复服务器，在该示例性的情况下其与发射机相 同。
在所述修复服务器4处，在步骤704中所述修复请求被接收， 并且包括在其中的修复信息，例如丢失FLUTE编码符号的TSI、TOI、 SBN和ESI的四元组，用于确定哪些FLUTE编码符号必须生成作为 修复数据符号。这在步骤705中由修复服务器中4执行。在步骤706 中，生成的FLUTE编码符号接着被配备成具有服从FLUTE协议的 压缩FLUTE报头(第二类型报头)，例如根据图3a的本发明的第 一实施方式的压缩FLUTE报头6。接着FLUTE编码符号和压缩 FLUTE报头形成图3a的压缩FLUTE分组8。接着该压缩FLUTE分 组8由修复服务器传送到PtP修复会话中的特定接收机，参见步骤 707，例如通过将多个压缩FLUTE分组8-1、..8-M嵌入用于响应修 复请求的一个HTTP分组9中(参见图3b)，以及通过使用HTTP/TCP 的服务来在特定接收机3-1和修复服务器4的实体之间传输这些 HTTP分组。
以上通过优选实施方式对本发明进行了描述。应该注意到存在 对于本领域技术人员显而易见的可选方式和变形并且可以被实施且 不会背离所述权利要求书的范围和精神。特别地，本发明的范围不 应限于3GPP MBMS系统或FLUTE协议的环境中的应用。这归因于 这样的事实，即本发明的原理不限于任何特定的协议或系统，其中 所述原理一方面针对PtM传输而另一方面针对PtP传输使用相同协 议的不同类型的报头。