用于多点播送或广播中的增强型文件分布的方法和设备的制作方法

专利名称：用于多点播送或广播中的增强型文件分布的方法和设备的制作方法
技术领域：
本发明大体上涉及数据通信，且更明确地说涉及多点播送或多点播送环境中数据通 信系统中的增强型文件分布。
背景技术：
全球网络互连使得不管地理距离如何都能快速地存取信息。图1展示由参考标号20 表示的一般称为因特网的全球网络连接的简化示意图。因特网20本质上为许多具有链接 在一起的不同级别的阶层架构的网络。因特网20在由因特网工程工作小组(IETF)发布 的因特网协议(IP)下操作。IP的细节可查阅由正TF发行的意见请求(Request for Comments' RFC) 791。
连接到因特网20的为各种个别网络，其取决于网络尺寸而有时称为局域网(LAN) 或广域网(WAN)。图1中展示某些此种网络22、 24和26。
在网络22、 24和26的每一者内，可存在彼此连接且彼此通信的各件设备。仅举出 的几个实例为计算机、打印机和服务器，其一般称为节点。当节点经由因特网20在其自 身网络以外通信时，节点需要依据IP将数据包发送到其它网络中的相应节点。类似地， 由其它网络中相应节点发出到起始节点的数据包也必须符合IP 。
不同类型的应用使得不同级别的协议有必要结合IP进行操作。举几个实例说明。假 设网络22中的节点28试图从网络26中的另一节点30下载文件。对于文件传送，极为 经常地使用称为文件传送协议(FTP)的较高等级协议。FTP可査阅由IETF发行的RFC 959。如此，由节点30发送到节点28的数据包尤其必须符合FTP和IP。
作为另一实例，假设网络22中的节点28经由因特网20浏览由网络24中的另一节 点32提出的网站。此时，节点28和32可能使用另一较高等级协议，称为超文本传送协 议(HTTP)。 HTTP可査阅由正TF发行的RFC 2616。同样，所交换的数据包尤其必须符合HTTP和IP。
示范性协议FTP和HTTP经由称为传输控制协议(TCP)的另一中间级别协议来承 载。TCP可查阅RFC 793。在TCP下，目标为准确地传输数据。如此，错误数据始终被 重新传输。TCP和依靠TCP的协议(例如FTP禾B HTTP) —般用于一对一应用。
技术发展使得数据密集的数据传送成为可能。举例来说，能够处理高带宽的网络允 许多媒体文件交换，例如通常保存大量数据的音频和视频文件。当大量节点接收所述多 媒体文件时，经由常规单点播送方法进行的文件传递可能效率较低。文件尤其首先需经 复制且随后个别地传递到每一节点。因此，需要开发适用于广播或多点播送服务的其它 类型的协议来解决对于一对多应用的增加的需要。
为了满足所述需要，己设计了特定地适于多点播送文件分布应用的单向传送文件传 递(FLUTE)协议。FLUTE协议可查阅2003年11月14日由正TF发行的题为"FLUTE-File Delivery over Unidirectional Transport"的RFC 3926。在多点播送对话中，业务流或多或 少地为单向的。g卩，如果根本上存在的话，反向数据业务受到限制。所述单向使用在存 在一个将数据发送到许多接收器的通信源的广播或多点播送应用中较常见。
在FLUTE协议下传输的数据承载于用户数据报协议(UDP)上，而非如在HTTP和 FTP协议中一样承载于TCP上。在UDP下，错误数据通常并不重新发送。为了进行准 确数据传输，FLUTE协议通常以冗余的方式传输数据并使用错误校正方案。
使用FLUTE协议，在文件传递对话期间传送一个或一个以上文件。文件承载于具有 异步分层编码(ALC)形式的数据包(称为ALC包)中。视文件长度而定，每一文件可 在一个或一个以上ALC包中传输。所述文件称为对象。可由包含于文件传递表(FDT) 中的文件属性识别对象。在接收器端，依赖文件属性从ALC包重建原始文件。在正确接 收到相应文件属性之前不可处理所接收的文件对象。为了实现FDT接收的较高可靠性， 复制的FDT实例(instance)通常插入有发送到接收器的ALC包中的有效负载数据。到 此，FDT和内容文件或多或少地同时传输。如此，即使正确地接收到内容文件(通常情 况并非如此)，接收器也需要正确地接收FDT，从FDT提取文件属性且随后处理所接收 的内容文件。即，所接收的文件的成功解码和随后呈现或多或少地同时取决于处理ALC 包所需的文件属性的成功下载。所述依赖性不可避免地导致延迟且经常不利地影响内容 呈现的质量。另外，不具有正确文件属性的用户极为经常地作出多次尝试以获得所需文 件属性，藉此测试通信信道类型。因此，这可能并非对可用通信资源的最有效使用。
因此，需要提供更有效的方案来获得较佳质量的广播，且另外需要更经济地利用通
信资源。

发明内容
在提供广播服务的通信系统中，广播服务中用于广播的文件可由用户存取。在一个 通信对话中发送广播文件的内容。在另一通信对话中单独发送处理广播文件所需的文件 属性。根据配置，在内容文件之前接收文件属性使得更有效地下载并处理广播文件。
所属领域的技术人员参看附图从以下具体实施方式
将易了解这些和其它特征与优 点，附图中相同参考标号表示相同部件。


图1为全球网络连接的示意图2为包含于本发明的示范性实施例中的节点和网络的示意图； 图3为展示阶层式等级的协议堆栈的示意图； 图3A为FLUTE协议的更详细示意表示；
图4为展示在FLUTE协议下操作的CFD方法的一套方法的示意图 图5为展示根据本发明的示范性实施例而操作的CFD方法的示意图； 图6为展示在不同时间窗口期间执行的文件传递和呈现的时序图； 图7为展示根据本发明的示范性实施例的文件检索和处理的流程图； 图8为展示根据本发明的示范性实施例的文件传递的流程图； 图9为展示示范性紧密ALC数据包的示意图
图IO为展示适于经由无线通信的文件传递的另一紧密包格式的示意图； 图11为根据本发明的示范性实施例经配置以接收并处理广播文件的节点的电路的一 部分的示意图；以及
图12为根据本发明的示范性实施例经配置以传递广播文件的节点的电路的一部分 的示意图。
具体实施例方式
提供以下描述使得所属领域的技术人员能够制造并使用本发明。在以下描述中为了 解释的目的而陈述细节。应了解，所属领域的一般技术人员将意识到可实践本发明而不 使用这些特定细节。在其它实例中，为了避免不必要的细节混淆对本发明的描述而未详 述众所周知的结构和过程。因此，本发明并不希望限于所展示的实施例，而是应符合与 本文所揭示的原理和特征一致的最广泛范围。
图2展示本发明的示范性实施例的简化示意图。整个系统通常由参考标号40表示。
在通信系统40中，为了说明的简洁和明确，仅展示两个网络42和44。网络42和44由 基干网络46 (例如内部网络或因特网)链接。
假设在此实施例中，网络42由服务提供者操作。服务提供者在网络42中安装节点 48。在此实例中，节点48称为广播服务分布器(BSD)。内容服务器48可经设计以保存 广播内容以及由服务提供者提供的相关广播信息。
在网络44中，存在订户节点50，其能够接收服务，包括由服务器节点48经由基干 网络46提供的服务。在此实施例中，将节点50描绘为无线装置，(仅举几个实例)例如 个人数字助理(PDA)、移动计算机或蜂窝式电话。网络44支持无线技术，例如由3GPP2 (第三代合作伙伴计划2)陈述的cdma2000标准，其中3GPP2为若干国际标准机构的协 会，包括美国TIA/EIA (电信工业协会/电子工业协会)。应注意，网络40还可支持其它 标准，例如由3GPP (第三代合作伙伴计划)发布的WCDMA (宽带码分多址)标准，其 由不同的欧洲标准机构协调并支持。另一实例为由前向链路(FLO)论坛开发的标准， FLO论坛为促进用于FLO网络中的标准化的无线工业中各种机构的协会。
订户单元50经由无线电存取网络(RAN) 52而与网络44通信。RAN 52包括连接 到多个基站(BS) 66A到66N的基站控制器/包数据控制功能(BSC/PDF) 54。在网络 44中，建构有包数据服务节点(PDSN) 68和广播服务节点(BSN) 70。 PDSN 68禾卩BSN 70均提供在基干网络46与网络44中的RAN 52之间进行介接的功能。安装BSN 70更 多地用于多点播送或广播使用，而PDSN68大部分处理单点播送应用。在本说明书中， 术语多点播送和广播可互换使用。
在网络44中，存在连接到BSN70的另一服务器，称为广播多点播送服务(BCMCS) 内容服务器63。通常，BCMCS内容服务器63预先存储广播内容和广播内容的相关数据， 包括由内容服务器48提供且经由基干网络46传递的数据。
在示范性实施例中，将某些节点之间的通信描绘为以无线的方式执行。然而应了解， 无需总是如此。经由那些节点之间各种其它装置而进行的非无线通信也适用。举例来说， 替代无线装置，节点50可为固定计算机或经由光学链路或常规导电电缆而与网络44通 信的另一服务器。
假设在此实施例中，基干网络46支持因特网协议(IP)。在描述操作细节之前，有 必要首先大体上解释在经由各种级别的不同阶层架构的协议进行包数据通信期间对于数 据包的处理，及其在IP下操作的相互关系。
在网络通信技术中，根据如由国际标准化组织(ISO)和国际电信联盟-电信标准部
门(ITU-T)陈述的开放系统互连(OSI)模型，将协议层级化。此目的在于促进多供应 商设备的可交互操作性。即，每一级别的协议阶层架构具有其自身规格。如此，只要满 足特定阶层架构级别的规格，即可确保此级别的产品的开发与其它级别的其它产品相容。 图3示意展示阶层式等级的协议的堆栈，其通常称为"协议堆栈"，且通常由参考标 号72表示。依据因特网工程工作小组(正TF)模型构建IP协议堆栈72，所述因特网工 程工作小组模型类似于OSI模型但不精确地与OSI模型相同。根据正TF模型，IP协议 堆栈72具有五层，从层i开始到层5。因此，由节点(例如图2中所展示的节点48或 50)发出的数据包必须经由协议堆栈72处理。协议堆栈72以软件或硬件或其组合的形 式内建于节点中。类似地，由相同节点接收的数据包必须经由相同协议堆栈72但以反向 次序进行处理。
举一实例说明。假设数据包经处理以便从一节点(例如，节点48 (图2))发出，首 先根据应用层(即，层5)中的协议的一者来建立所述数据包。层5包括超文本传送协 议(HTTP)、服务邮件传送协议(SMTP)、文件传送协议(FTP)、实时传送协议(RTP) 和单向传送文件传递/异步分层编码(FLUTE/ALC)协议。进一步假设数据包为VoIP (因 特网语音协议)对话的产物。因此必须根据层5中的RTP格式化数据包。
例如根据层5中的RTP产生的数据包的时间敏感数据包需经实时处理。明确地说， 通常不重新发送缺陷包而是将其简单地丢弃，以免阻塞其它即将到来的数据包的传输。 RTP数据包因此通常经由层4 (传输层)中的用户数据包协议(UDP)而承载。因此，须 进一步根据层4中的UDP来明确表示来自层5中RTP的数据包。
另一方面，如果数据包源自层5中的其它协议(例如FTP)，那么通常经由层4中的 传送控制协议(TCP)来发送所述数据包。在TCP下，数据包的正确传递最为重要。如 此，总是重新发送缺陷包，虽然可能减缓整个数据传输过程。
经过此传送层(层4)之后的数据包被添加有例如源和目的地端口号的信息。
在经过传送层(层4)之后接着将数据包发送到网络层(层3)以供进行处理。在此 特定情况中，从层4所得的数据包必须根据IP (例如，根据添加的数据包的源和目的地 地址)再次格式化。
随后，必须构造所述数据包以使其适合链路层(层2)中适用的无论何种协议。举 例来说，如果服务器节点48经由以太网而连接到所述网络，那么层2将为如由电气电子 工程师协会(正EE)发行的第正EE 802.3号文献中所陈述的以太网协议的形式。
图5中协议堆栈72的最底层为物理层(层l)，其处理数据包传输的物理实施方案。
举例来说，在图2中，如果节点48与网络42之间的通信链接为常规有线链接，那么物 理层(层1)关注节点48上的硬件电路和网络42的接口电路两者。作为另一实例，在 图2中，如果节点50与BS 66A之间的通信链接为空中接口。在此情况下，物理层(层 1)与大气空间和经由大气空间收发信号的RAN52的硬件电路相关。
现在返回参看图3。对于由示范性节点50 (图2)接收的数据包，所述数据包必须 经由相同协议堆栈72但以反向次序(即，从层1到层5)处理。
本文描述系统40中示范性广播过程的操作。在图2中，如先前所提及，假设节点 48 (即BSD)是由将广播服务提供到订户的服务提供者安装于网络42中，其中节点50 为所述订户中的一者。举例来说在此情况中，节点50可从另一网络漫游到网络44并寻 求对于新闻剪辑的存取，例如对于可从操作网络42的服务提供者获得的7:00 p.m.新闻的 存取。
如果网络44支持广播服务，网络44时常为可用服务维持广播信道。可用服务的信 息可以可下载文件的形式组织。或者，相同信息可以实时可视数据连续流的形式呈现。
假设在此示范性实施例中，可用服务以类似于广播服务指南(SG)的方式而集合为 可下载文件，其中广播服务指南(SG)由包括服务提供者、硬件和软件供应商和网络操 作者等无线工业中各种实体的协会开放移动联盟(OMA)发布，用于统一无线通信系统 中各种标准的目的。由OMA发行的出版物OMA-TS-BCAST匿Service-Guide-Vl. ~@弁$@@ 中陈述了 SG的细节。
到此，当在网络44中时，节点50的用户需要参考SG以获得可用服务。为了此目 的，必须从网络44下载SG。节点50的用户接着从SG选择所寻求的服务，并随后调谐 到承载如SG中所提供的所述服务的信道。
对于某些服务(例如音乐下载)，节点50的用户可首先下载所寻求的文件并稍后欣 赏所下载的文件。对于其它服务(例如新闻广播对话)，所寻求的文件的内容被下载并或 多或少地同时呈现。S卩，所寻求的服务实时呈现，与服务关联的文件下载同样如此。所 述方法带来若干缺点。尤其是，因为文件内容的成功呈现不仅取决于内容本身的成功下 载，而且取决于处理内容文件所需的文件属性的成功下载。所述依赖性不可避免地导致 延迟且经常不利地影响用户对于内容呈现的体验。另外，为了更好地确保可靠的数据包 接收，通常发送冗余数据。因此，如下文进一步解释，这可能不会促成对可用通信资源 的最有效使用。
假设所寻求的服务的文件内容经由FLUTE/ALC协议传送。为了确保正确的数据传
送，常规地将圆盘式文件分布(Carousel File Distribution) (CFD)方法与FLUTE/ALC 协议结合使用。图3A展示FLUTE/ALC协议的更详细示意表示，且稍后将进行进一步论 述。图4展示在FLUTE/ALC协议下操作的CFD方案的方法。
在图4中，参考标号74表示一文件。 一则多媒体内容(例如此实例中的新闻剪辑) 可包含多个文件。在文件74中，数据包#1到#5中的每一者表示一 ALC数据包。包含同 样以ALC协议格式配置的文件传递表(FDT) 78的ALC数据包与每一文件74的传递关 联。
在FDT78中，包括解码数据包#1到#5所需的各种参数或属性。所述参数可包含(但 不限于)文件名称、文件识别符(ID)、文件的源位置(即，URI)、呈现时间、文件大 小、内容类型、编码方案、前向误差校正(FEC)类型和FEC相关参数，以及安全相关 参数(如果可应用)。
在CFD方法中，文件被多次传输。在此实例中，包括内容包#1到#5的文件74与关 联的FDT78 —起第一次在首次通过73中传输，且接着第二次在第二次通过75中传输。 在首次通过73中，FDT 78在内容包#1到#5之前传输。在第二次通过75中，相同FDT 78 在内容包#1到#5结束时传输。
重复地传输每一文件的一个目的是，消除所有接收器为了接收文件完全地时间对准 的需要。即，不需要为了接收文件的目的而使接收器同步。
重复地传输每一文件的另一理由是，在未安装FEC方案或即使安装但FEC机制不能 操作的事件中确保数据传送期间的正确性。为了达到此目的，CFD方法经设计以包含如 由图4中所展示的场景A、 B和C表示的三个场景。除了三个场景A、 B和C外，可通 告失败的文件下载。
在场景A中，假设节点50试图下载文件74。在首次通过73期间，节点50需要成 功地接收FDT 78。假设首次通过73中FDT 78的下载成功且无误差。接着节点50接收 后续的数据包弁1到#5。假设首次通过73中所有数据包并1到#5的下载也成功。节点50 可使用从首次通过73下载的FDT78中的信息来解码所有包#1到#5中的数据，用于整个 文件74的组合。
在场景B中，在首次通过73中下载文件74期间，假设FDT包78的检索成功。首 次通过中所有内容包弁l到#5的检索除了数据包#3外也成功。假设所实施的FEC机制不 发挥作用。在此情况下，节点50必须等待直到第二次通过75发生才可在第二次通过75 期间接收相同数据包并3以补偿在首次通过73中接收的相应缺陷包#3。随后，节点50可
使用来自从首次通过获得的FDT78的信息来解码所有数据包，用于文件74的重构。
在场景C中，即使在首次通过73中正确下载了所有数据包弁1至!J弁5,节点在首次通 过73中也未能正确地接收FDT 78。在此情况下，节点50必须等待直到第二次通过75 发生才可检索相应FDT 78以补偿来自首次通过73的错误FDT 78，用于对文件74的所 有数据包的正确解码。
在不适宜的信号接收条件下，如以上在场景A、 B和C中描述的在FEC顶部实施的 额外步骤可能不能够校正任何错误数据。即，如先前所提及，可通告文件74的下载失败。 在场景B中，数据包#3的损失可能仅影响在呈现期间文件74的质量。然而，在场景C 中，FDT78的不成功检索可导致整个文件74的损失，因为如果无FDT78，那么不可处 理整个文件74。在此情况下，节点50可能必须仅为了具有另一机会获得FDT78而等待 直到下一圆盘式循环出现，所述圆盘式循环可为许多时间周期，例如由时间通过73和 75延展的时间周期。如果发生此情况，那么不可避免额外的时间延迟和通信信道占用。 如果装置50为如在此实例中的移动装置，那么额外的时间延迟转化为装置50的电池的 额外功率消耗。在移动通信中，电池寿命的维持极其重要。
根据本发明的示范性实施例，FDT和内容数据包未如常规实践那样在频带内接收。 事实上，如稍后将描述，文件属性和内容数据在频带外接收。
下文中，术语"频带内"解释为表示经由相同传输信道且进一步大体上在同一传输 对话内的信息传送。频带内信息传送的实例如图4的传输过程中所展示和描述。另一方 面，术语"频带外"解释为表示经由不同传输对话的信息传送，其与所述传送经过相同 传输信道还是不同传输信道无关，如图5中展示的传输过程所例示且如下文所描述。
现参看图5。在此实施例中，与有效负载数据(例如数据包M到#5)相比，文件属 性82 (例如先前所提及的包括于FDT 78中的文件属性)被分离地传输，即在频带外而 非在频带内传输。
优选地，FA经由网络44 (图2)且在广播信道中传输。举例来说，FA可为先前所 提及的SG的一部分。SG且因此FA首先由寻求广播服务的节点50获得。即，在第一通 信对话81期间获得FA82。在正确检索FA82之后，节点50接着可根据SG中所提供的 信息而调谐到所述信道以获得内容文件(例如文件84)。即，在第二通信对话86期间获 得内容文件。如图5中所展示，不存在插入有内容文件包的FDT。事实上，内容文件(例 如，文件83和84)经设计以连续且不间断地传输。换句话说，只有在确认节点50较早 在通信对话81期间已正确检索FA 82之后才在通信对话86期间下载内容文件。因此，
可避免当文件和FDT两者均在频带内并如以上所描述而被接收时文件的成功处理受相应 FDT的成功下载支配的情况。
在传输过程期间，如果发现缺陷数据包(例如，在首次通过85期间文件84中的数 据包#4，且由图5中的参考标号90表示)，且进一步假设安装的FEC机制未能校正缺陷 包#4，那么可检索第二次通过87中的相应数据包#4以供进行修复。如果修复过程不成 功，那么在呈现期间文件84的质量可能存在某一程度的降级。然而，如图4中所展示的 失败场景C中和如上文所描述的情况可能从不会发生。原因是，如先前所陈述较早在通 信对话81期间己成功接收到FA 82。
以如上文所描述的方式操作，不需要占用用于FDT传输的任何频带内信道。藉此可 更确定地执行内容文件检索。文件获得时间也可大体上縮减。因此，可减轻通信信道中 的拥塞，这又可促成对可用通信资源的更有效使用。另外，如果节点50 (图2)为移动 装置，那么较短的文件获得时间意味着在下载内容文件期间唤醒节点50的电池所需的时 间较短。因此，可节省电池电力。
应进一步注意，图5中所展示的FA 82为需经获得以用于适当地解码所寻求的服务 对话的所有文件而所需的许多FA中的一者，其中文件84为所述文件中的一者。然而， FA 82具有不仅用于文件84而且用于例如邻近文件83的其它文件的检索的许多共同属 性。因此，可将所有FA组织为适于在传输对话中所有文件的文件检索的一个主FA。或 者，替代主FA,可将聚集的FA划分为两个部分。第一部分可保存视为长期的文件属性。 所述属性可包括文件名称、文件ID、文件位置、呈现时间和分布时间窗口。另一方面， 认为相对短期的属性可放置于FA的第二部分中。短期属性可包括应用程序文件大小、传 输文件大小、内容类型、编码方案、FEC类型和参数以及安全相关参数。第一部分可保 持于SG中而随着时间过去相对不发生改变。第二部分可在SG中周期性地更新以反映不 断变化的条件。
如先前所提及，某些文件首先可经下载并稍后由用户在由用户选定的时间执行。实 例为音乐文件和软件更新文件。其它文件可首先经下载但优选在特定时间呈现。实例为 如下文将描述的新闻广播对话。在任一情况中，根据本发明的另一方面，内容文件获得 和呈现不需要同时执行。相反，文件获得可分离地并在文件呈现过程之前执行。
为了便于解释，说明更具体的实例。现返回参看图2。假设在此实例中，节点50的 用户想要观看通常在7:00 p.m.经由定期电视广播可用的新闻广播。在经由网络44广播的 SG中，关于7:00 p.m.新闻剪辑的相关信息通常可用。网络44经由基干网络46而具有来
自服务提供网络42的此信息。在SG中，可指定两个时间窗口，艮卩，"分布窗口 (DW)" 和"呈现窗口 (PW)"。图6展示所述配置。
在DW中，指定一时间窗口 ，其中需启动节点50以便接收7:00 p.m.新闻对话的文件。 举例来说，在此实例中，从5:00 p.m.到6:30 p.m.,其为节点50可通电以接收新闻文件的 时间区间。另一方面，PW识别所下载的新闻对话的呈现时间，在此实例中，其为从7:00 p.m.到7:30 p.m.。即，在此时间间隔期间，所下载的文件将呈现为7:00 p.m.新闻。将DW 与PW分离的额外益处为，允许订户在呈现时间之前下载文件，以避免在通常与峰值时 间重合的呈现时间期间发生业务信道过载。即使在DW期间网络44中大量业务负载的情 况下，个别文件下载仍可缓慢地以小流量流到其各自的接收器，并恰当地在PW开始之 前完成。
基于由SG提供的信息，假设节点50通电并在从5:25p.m.到5:37 p.m.的时间周期期 间起动用于接收新闻剪辑。如果实施适当的文件压缩技术，那么下载所需的时间(在此 实例中为12分钟)可短于呈现时间(在此情况下为30分钟)。
图7的流程图中展示节点50的先前提及的方法。图8展示由网络44实践的相应方法。
根据本发明的又一方面，可进一步流线化有效负载数据的传送。
对于文件内容下载，可使用FLUTE/ALC协议。如先前所提及，与在FTP中数据包 经由TCP传送层(图3)传送不同，FLUTE/ALC中的数据包承载于UDP传送层上。FTP 更倾向于适合一对一应用，且通常重新传输错误包，但这减缓整个传输过程。经由UDP 承载的FLUTE/ALC协议经设计以适于多点播送或广播应用。通常不重新传输错误数据。 事实上，通过使用适当的前向误差校正(FEC)方案来减少数据传输中的错误。
现参看图3A，其示意展示通常由参考标号96表示的FLUTE/ALC协议。FLUTE协 议的数据包由ALC协议承载传送。2002年12月由IETF发行的题为"Asynchronous Layered Coding(ALC) Protocol Instantiation "的出版物RFC 3450中陈述了 ALC协议。ALC 协议是为多点播送传送而提议的基本协议之一。包含ALC的数据传送不需要上行链路信 号传输(即，从接收器传输信号到发射器)，并使用FEC来进行可靠的数据检索。ALC 还利用分层编码传送(LCT)结构块98来进行多速率拥塞控制(CC) 97，且利用FEC 结构块99来进行可靠的内容传递。2002年12月题为"Layered Coding Transport(LCT) Building Block"的IETF出版物RFC 3451中描述了 LCT。同样由IETF发行的RFC 3453 中描述了 FEC。
FLUTE协议表示用于多点播送文件传递的ALC的应用。然而，常规FLUTE/ALC协
议主要经设计用于非移动环境。在需要节省电池功率且空气链接带宽较为珍贵的无线环 境中，可进一步流线化文件下载过程。为了达到此目的，可将有效负载中每一数据包设 计得更紧密。
图9展示由参考标号94识别的示范性紧密ALC数据包，其经格式化以更加符合RFC 3450中所详述的常规ALC包。ALC包格式94经设计与由3GPP2发布在公开的文献3GPP TS 23.346中的广播/多点播送服务(MBMS)相同。数据包84中所展示的格式与文献3GPP TS 23.346中详述的格式之间的主要差异是缺少文件描述信息(即，处理数据包94的有 效负载所需的文件属性)的任何频带内传输。
图10展示由参考标号96表示的另一示范性紧密包格式。数据包96大体上经流线化 且适用于无线通信环境中。尤其免除了拥塞控制信息。如在无线环境中，无线媒体为单 一存取装置，用于以不同数据速率调节多个存取装置的拥塞控制不是必需的。在图9中 所展示的数据包94中，额外开销为16字节。对于图10中所展示的数据包％，额外开 销仅为8字节。
图11示意展示根据本发明的示范性实施例的设备(例如图2中展示的节点50)的硬 件实施方案的一部分，其由参考标号100表示。可以各种形式建造且并入设备100，例 如(仅举几例说明)膝上型计算机、PDA或蜂窝式电话。
设备100包含将若干电路链接在一起的中央数据总线102。所述电路包括CPU (中 央处理单元)或控制器104、接收电路106、发射电路108和存储器单元110。
如果设备100为无线装置的一部分，那么接收和发射电路106和108可连接到射频 (RF)电路，但图式中未展示。接收电路106在将所接收的信号发出到数据总线102之前 处理并缓冲所述信号。另一方面，发射电路108在从装置100发出来自数据总线102的 数据之前处理并缓冲所述数据。CPU/控制器104执行数据总线102的数据管理功能并进 一步执行一般数据处理功能，包括执行存储器单元110的指令性内容。
替代如图11中所展示分离地安置，作为替代方案，发射电路108和接收电路106可 为CPU/控制器104的部分。
存储器单元110包括一组指令，其通常由参考标号101表示。在此实施例中，所述 指令包括例如尤其能够处理如上文所描述的FLUTE/ALC协议的协议堆栈功能112的部 分。所述组指令还包括能够执行图7中所展示和描述的方法的广播客户端功能114。
在此实施例中，存储器单元IIO为RAM (随机存取存储器)电路。示范性指令部分112和H4为软件常用程序或模块。存储器单元110可连接到易失性或非易失性类型的另 一存储器电路(未图示)。或者，存储器单元110可由其它电路类型组成，例如EEPROM (电可擦可编程只读存储器)、EPROM (电可编程只读存储器)、ROM (只读存储器)、 ASIC (专用集成电路)、磁盘、光盘和此项技术中已知的其它类型。
图12示意展示广播服务器(例如图2中所展示的BSN设备70)的硬件实施方案的 一部分，其由参考标号120表示。设备120包含将若干电路链接在一起的中央数据总线 122。所述电路包括CPU (中央处理单元)或控制器124、接收电路126、发射电路128、 数据库存储单元129和存储器单元131。
接收和发射电路126和128可连接到网络数据总线(未图示)，设备120链接到所述 网络数据总线。接收电路126在将从网络数据总线(未图示)接收的信号路由到内部数 据总线122之前处理并缓冲所述信号。发射电路128在从设备120发出来自数据总线122 的数据之前处理并缓冲所述数据。或者，发射电路128和接收电路126可共同称为接口 电路。CPU/控制器124执行数据总线122的数据管理职责并执行一般数据处理功能，包 括执行存储器单元131的指令内容。数据库存储单元129存储数据，例如具有各种参数 的SG和内容文件。
存储器单元131包括一组指令，其通常由参考标号121表示。在此实施例中，所述 指令尤其包括协议堆栈132和广播主机134等若干部分。存储器单元131可由如上文所 提及的存储器电路类型组成，且不再进一步重复。协议堆栈121和广播主机134的功能 包括根据本发明例如图3和图8中所展示且如先前所描述的指令组。
应进一步注意，如上文图7和图8中所描述和展示的过程也可编码为在此项技术中 已知的任何计算机可读媒体上执行的计算机可读指令。在本说明书和随附的权利要求书 中，术语"计算机可读媒体"表示参与将指令提供到任何处理器(例如图11和图12中 分别展示和描述的CPU/控制器104和124)以供执行的任何媒体。所述媒体可为存储类 型的，并可采取同样如先前所描述的易失性或非易失性存储媒体的形式，例如分别在图 11和图12中描述的存储器单元110和131的形式。所述媒体也可为传输类型的，并可包 括同轴电缆、铜线、光缆和承载能够承载由机器或计算机可读取的信号的声波或电磁波 的空中接口。
最后，如在此实施例中所描述，节点BSD48描述为安装于服务提供者的网络42中。 情况可能并非始终如此。可能将BSD48安装于不属于服务提供者的另一网络中。另外， 如示范性实施例中所描述的频带外传输信道可如通常在扩频通信技术中所实践而逻辑地
或物理地加以区分。另外，不同频带外对话可由不同端口号而非如先前所提及的时间分 离来识别。因此，例如在图5中，FDT可在层4 (图3)的UDP上经由对应于第一传输 对话的一个目的地端口而传输。内容文件可在层4的UDP上在第二传输对话期间经由另 一目的地端口号传输。另外，还应清楚，图7和图8中的流程图也适应于根据用户选择 来下载并执行文件，例如音乐文件。举例来说，用户可从SG收集并自主地确定文件分 布和文件呈现窗口。另外，如示范性实施例中所描述，基干网络描绘为在IP下操作。除 了 IP以外的其它协议是可能的。举例来说，在FLO网络中，根据由FLO论坛发行的题 为"FLO Air Interface Specification"的文献(floforum 2005.001)的协议将为适用的。在 FLO网络中，替代SG，相应文件属性可放置于系统信息(SI)中，SI的细节可查阅由 FLO论坛发行的文献floforum 2006.005。另外，结合实施例而描述的任何逻辑块、电路 和算法步骤可实施于硬件、软件、固件或其组合中。所属领域的技术人员将了解，可作 出形式和细节上的这些和其它改变而不背离本发明的范围和精神。
权利要求
1.一种用于通信系统中的广播的文件下载方法，其包含在第一通信对话中接收用于处理所述广播的至少一个文件的文件属性；以及在第二通信对话中与所述文件属性分离地接收所述广播的所述至少一个文件。
2. 根据权利要求1所述的方法，其进一步包含经由第一通信信道接收所述文件属性；以及 经由第二通信信道接收所述至少一个文件。
3. 根据权利要求1所述的方法，其中所述通信系统支持因特网协议(IP)，所述方法进 一步包含通过所述IP的用户数据报协议(UDP)经由第一端口号来接收所述文件属性；以及通过所述IP的所述UDP经由第二端口号来接收所述至少一个文件。
4. 根据权利要求l所述的方法，其进一步包含在所述第二通信对话中连续地接收所述 广播的多个文件，以及在所述第一通信对话中接收用于处理所述多个文件的所述文 件属性，其中所述第一通信对话早于所述第二通信对话。
5. 根据权利要求1所述的方法，其中所述至少一个文件包括多个数据包，所述方法进 一步包含在所述数据包的每一者中不接收任何文件属性用于处理所述至少一个文 件。
6. 根据权利要求l所述的方法，其进一步包含在所述第二通信对话中接收所述广播的 多个文件，且进一步包含使用某些所述文件属性来处理所述多个文件，其中所述某 些文件属性通常在所述多个文件之间共享以用于处理所述多个文件。
7. 根据权利要求l所述的方法，其进一步包含在所述文件属性中提供用于呈现所述广 播的所述至少一个文件的时间信息以便允许在预定时间呈现所述至少一个文件。
8. —种用于通信系统中的广播的文件传递方法，其包含在第一通信对话中发送用于处理所述广播的至少一个文件的文件属性；以及 在第二通信对话中与所述文件属性分离地发送所述广播的所述至少一个文件。
9. 根据权利要求8所述的方法，其进一步包含经由第一通信信道发送所述文件属性；以及经由第二通信信道发送所述至少一个文件。
10. 根据权利要求8所述的方法，其中所述通信系统支持因特网协议(IP)，所述方法进 一步包含-通过所述IP的用户数据报协议(UDP)经由第一端口号来发送所述文件属性；以及通过所述IP的所述UDP经由第二端口号来发送所述至少一个文件。
11. 根据权利要求8所述的方法，其进一步包含在所述第二通信对话中连续地发送所述 广播的多个文件，以及在所述第一通信对话中发送用于处理所述多个文件的所述文 件属性，其中所述第一通信对话早于所述第二通信对话。
12. 根据权利要求8所述的方法，其中所述至少一个文件包括多个数据包，所述方法进 一步包含在所述数据包的每一者中不提供任何文件属性用于处理所述至少一个文 件。
13. 根据权利要求8所述的方法，其进一步包含在所述第二通信对话中发送所述广播的 多个文件，且进一步包含在所述第一通信对话中提供某些所述文件属性，其中所述 某些文件属性通常在所述多个文件之间共享以用于处理所述多个文件。
14. 根据权利要求8所述的方法，其进一步在所述文件属性中包含用于呈现所述广播的 所述至少一个文件的时间信息。
15. —种经配置以在通信系统中接收广播的设备，其包含用于在第一通信对话中接收用于处理所述广播的至少一个文件的文件属性的装 置；以及用于在第二通信对话中与所述文件属性分离地接收所述广播的所述至少一个文 件的装置。
16. 根据权利要求15所述的设备，其进一步包含用于经由第一通信信道接收所述文件属性的装置；以及 用于经由第二通信信道接收所述至少一个文件的装置。
17. 根据权利要求15所述的设备，其中所述通信系统支持因特网协议(IP),所述设备 进一步包含用于通过所述IP的用户数据报协议(UDP)经由第一端口号来接收所述文件属性 的装置；以及用于通过所述IP的所述UDP经由第二端口号来接收所述至少一个文件的装置。
18. 根据权利要求15所述的设备，其进一步包含用于在所述第二通信对话中连续地接收所述广播的多个文件的装置，以及用于在所述第一通信对话中接收用于处理所述 多个文件的所述文件属性的装置，其中所述第一通信对话早于所述第二通信对话。
19. 根据权利要求15所述的设备，其中所述至少一个文件包括多个数据包，其中所述 数据包中的每一者不包括任何用于处理所述至少一个文件的文件属性。
20. 根据权利要求15所述的设备，其进一步包含用于在所述第二通信对话中接收所述 广播的多个文件的装置，且进一步包含用于使用某些所述文件属性来处理所述多个 文件的装置，其中所述某些文件属性通常在所述多个文件之间共享以用于处理所述 多个文件。
21. 根据权利要求15所述的设备，其中所述文件属性包含用于呈现所述广播的所述至 少一个文件的时间信息以便允许在预定时间呈现所述至少一个文件。
22. —种用于通信系统中的广播的文件传递设备，其包含用于在第一通信对话中发送用于处理所述广播的至少一个文件的文件属性的装 置；以及用于在第二通信对话中与所述文件属性分离地发送所述广播的所述至少一个文 件的装置。
23. 根据权利要求22所述的设备，其进一步包含用于经由第一通信信道发送所述文件属性的装置；以及 用于经由第二通信信道发送所述至少一个文件的装置。
24. 根据权利要求22所述的设备，其中所述通信系统支持因特网协议(IP)，所述设备 进一步包含用于通过所述IP的用户数据报协议(UDP)经由第一端口号来发送所述文件属性 的装置；以及用于通过所述IP的所述UDP经由第二端口号来发送所述至少一个文件的装置。
25. 根据权利要求22所述的设备，其进一步包含用于在所述第二通信对话中连续地发 送所述广播的多个文件的装置，以及用于在所述第一通信对话中发送用于处理所述 多个文件的所述文件属性的装置，其中所述第一通信对话早于所述第二通信对话。
26. 根据权利要求22所述的设备，其中所述至少一个文件包括多个数据包，所述设备 进一步包含用于在所述数据包的每一者中不提供任何文件属性用于处理所述至少 一个文件的装置。
27. 根据权利要求22所述的设备，其进一步包含用于在所述第二通信对话中发送所述 广播的多个文件的装置，且进一步包含用于在所述第一通信对话中提供某些所述文 件属性的装置，其中所述某些文件属性通常在所述多个文件之间共享以用于处理所 述多个文件。
28. 根据权利要求22所述的设备，其中所述文件属性包含用于呈现所述广播的所述至 少一个文件的时间信息。
29. —种在通信系统中的广播中使用的设备，其包含处理器；以及耦合到所述处理器的存储器单元，所述存储器单元包括计算机可读指令，所述计 算机可读指令用于在第一通信对话中接收用于处理所述广播的至少一个文件的文 件属性，以及在第二通信对话中与所述文件属性分离地接收所述广播的所述至少一 个文件。
30. 根据权利要求29所述的设备，其中所述存储器单元进一步包含计算机可读指令， 所述计算机可读指令用于经由第一通信信道接收所述文件属性，以及经由第二通信 信道接收所述至少一个文件。
31. 根据权利要求29所述的设备，其中所述通信系统支持因特网协议(IP)，所述存储 器单元进一步包含计算机可读指令，所述计算机可读指令用于通过所述IP的用户数 据报协议(UDP)经由第一端口号来接收所述文件属性，以及通过所述IP的所述 UDP经由第二端口号来接收所述至少一个文件。
32. 根据权利要求29所述的设备，其中所述存储器单元进一步包含计算机可读指令， 所述计算机可读指令用于在所述第二通信对话中连续地接收所述广播的多个文件， 以及在所述第一通信对话中接收用于处理所述多个文件的所述文件属性，其中所述 第一通信对话早于所述第二通信对话。
33. 根据权利要求29所述的设备，其中所述至少一个文件包括多个数据包，且其中所 述数据包中的每一者不包括任何用于处理所述至少一个文件的文件属性。
34. 根据权利要求29所述的设备，其中所述存储器单元进一步包含计算机可读指令， 所述计算机可读指令用于在所述第二通信对话中接收所述广播的多个文件，以及使 用某些所述文件属性来处理所述多个文件，其中所述某些文件属性通常在所述多个 文件之间共享以用于处理所述多个文件。
35. 根据权利要求29所述的设备，其中所述文件属性包含用于呈现所述广播的所述至 少一个文件的时间信息以便允许在预定时间呈现所述至少一个文件。
36. —种用于通信系统中的广播的文件传递设备，其包含处理器；以及耦合到所述处理器的存储器单元，所述存储器单元包含计算机可读指令，所述计 算机可读指令用于在第一通信对话中发送用于处理所述广播的至少一个文件的文 件属性，以及在第二通信对话中与所述文件属性分离地发送所述广播的所述至少一 个文件。
37. 根据权利要求36所述的设备，其中所述存储器单元进一步包含计算机可读指令， 所述计算机可读指令用于经由第一通信信道发送所述文件属性，以及经由第二通信 信道发送所述至少一个文件。
38. 根据权利要求36所述的设备，其中所述通信系统支持因特网协议(IP)，其中所述 存储器单元进一步包含计算机可读指令，所述计算机可读指令用于通过所述IP的用户数据报协议(UDP)经由第一端口号来发送所述文件属性，以及通过所述IP的所 述UDP经由第二端口号来发送所述至少一个文件。
39. 根据权利要求36所述的设备，其中所述存储器单元进一步包含计算机可读指令， 所述计算机可读指令用于经由所述IP的单向传送文件传递(FLUTE)结合所述IP 的所述UDP来发送所述至少一个文件。
40. 根据权利要求36所述的设备，其中所述存储器单元进一步包含计算机可读指令， 所述计算机可读指令用于在所述第二通信对话中连续地发送所述广播的多个文件， 以及在所述第一通信对话中发送用于处理所述多个文件的所述文件属性，其中所述 第一通信对话早于所述第二通信对话。
41. 根据权利要求36所述的设备，其中所述至少一个文件包括多个数据包，其中所述 数据包中的每一者不包括任何用于处理所述至少一个文件的文件属性。
42. 根据权利要求36所述的设备，其中所述存储器单元进一步包含计算机可读指令， 所述计算机可读指令用于在所述第二通信对话中发送所述广播的多个文件，以及在 所述第一通信对话中提供某些所述文件属性，其中所述某些文件属性通常在所述多 个文件之间共享以用于处理所述多个文件。
43. 根据权利要求36所述的设备，其中所述文件属性包含用于呈现所述广播的所述至 少一个文件的吋间信息。
44. 一种包括计算机可读指令的计算机可读媒体，所述计算机可读指令用于在第一通信对话中接收用于处理广播的至少一个文件的文件属性；以及在第二通信对话中与所述文件属性分离地接收所述广播的所述至少一个文件。
45. 根据权利要求44所述的计算机可读媒体，其进一步包含计算机可读指令用于经由第一通信信道接收所述文件属性；以及 经由第二通信信道接收所述至少一个文件。
46. 根据权利要求44所述的计算机可读媒体，其中所述通信系统支持因特网协议(IP), 所述计算机可读媒体进一步包括计算机可读指令用于通过所述IP的用户数据报协议(UDP)经由第一端口号来接收所述文件属性；以及通过所述IP的所述UDP经由第二端口号来接收所述至少一个文件。
47. —种包括计算机可读指令的计算机可读媒体，所述计算机可读指令用于在第一通信对话中发送用于处理广播的至少一个文件的文件属性；以及 在第二通信对话中与所述文件属性分离地发送所述广播的所述至少一个文件。
48. 根据权利要求47所述的计算机可读媒体，其进一步包括计算机可读指令用于经由第一通信信道发送所述文件属性；以及 经由第二通信信道发送所述至少一个文件。
49. 根据权利要求47所述的计算机可读媒体，其进一步包括计算机可读指令用于通过所述IP的用户数据报协议(UDP)经由第一端口号来发送所述文件属性；以及通过所述IP的所述UDP经由第二端口号发送所述至少一个文件。
全文摘要
在提供广播服务的通信系统中，广播服务中用于广播的文件可由用户存取。分离地发送所述广播文件的内容和处理所述广播文件所需的文件属性。根据配置，在所述内容文件之前接收所述文件属性使得更有效地下载并处理所述广播文件。
文档编号H04L29/06GK101189851SQ200680019627
公开日2008年5月28日 申请日期2006年4月10日 优先权日2005年4月8日
发明者克里斯·贝内特, 兰吉特·贾亚拉姆, 基尔提·古普塔, 戈登·肯特·沃克, 查尔斯·N·罗, 萨迪·纳加拉杰 申请人:高能股份有限公司