使用文件系统提取、广播调度消息和选择性接收的通过广播网络的文件传递的制作方法

专利名称：使用文件系统提取、广播调度消息和选择性接收的通过广播网络的文件传递的制作方法
使用文件系统提取、广播调度消息和选择性接收的通过广播网络的文件传递相关申请本申请要求于2010年5月28日提交的题为“File Delivery Over ABroadcastNetwork Using File System Abstraction，Broadcast ScheduleMessages And SelectiveReception”的美国临时申请No. 61/349,598的优先权的权益，其全部内容由此通过参考并入本文中。
背景技术：
无线通信技术在过去的几年中爆炸性地增长。这个增长受到向移动公众提供移动的自由，并切断了与硬连线的通信系统的束缚的无线服务的推动。作为服务增强的结果，无线服务的普及预计会继续迅速增长。无线通信服务最近的增加是向接收机设备广播电视及其它内容的能力。移动仅前向链路广播服务允许用户使用被配置为接收移动广播传输的移动接收机设备，来观看诸如电视显示之类的多媒体节目，以及接收新闻、娱乐、体育、商业及·其它广播节目的移动编辑。多媒体广播服务的增长代表了用于传送各种内容并与用户交互的有吸引力的通信平台。

发明内容
各个实施例提供了用于利用基于广播和/或多播的文件传递架构(filedeliveryframework, FDF)来向运行在接收机设备上的应用传递文件的系统、设备和方法。具体地，各个实施例提供了用于使用广播和/或多播网络的FDF服务，有效地通过广播系统向接收机设备传递文件的机制和系统。可以由广播网络广播广播调度消息(Broadcast ScheduleMessage，BSM)来预先公布要广播和/或接收的文件和数据报分组。可以预先发送BSM，以向接收机设备通知将会在将来的特定时间广播的文件和数据报分组。各个实施例利用由FDF服务提供的内置冗余性、纠错和可靠性机制来以更为及时、相关和有效的方式传递文件。


包含在本文中并构成本说明书的一部分的附图示出了本发明的示例性实施例，连同以上给出的总体说明和以下给出的详细说明一起，用于解释本发明的特征。图I是示出了适合用于实施例中的移动多媒体广播通信系统和蜂窝“单播”通信系统的通信系统方框图。图2是仅前向链路广播系统的广播通信系统方框图的可替换表示。图3是广播通信系统的元件的系统方框图，其示出根据实施例的经由广播网络传递文件所涉及的功能块。图4是示出各个实施例的主要功能组件的概况系统方框图。图5是示出根据实施例的用于特定应用(天气应用)的文件的摄取(ingestion)和接收的系统方框图。
图6是示出根据实施例的用于特定应用(iTV应用)的文件的摄取和接收的系统方框图。图7和8是示出如何可以发送广播调度消息以向接收机设备通知在广播管道(pipe)中发送的特定文件的时序和接收参数的时序图。图9是适合用于广播调度消息中的示例性数据结构。图10是适合用于广播调度消息中的另一个示例性数据结构。图11是示出如何可以使用广播调度消息的下一个监视时间数据字段来更新在下一个广播调度周期(BSP)的广播调度流(BSF)中的广播调度消息(BSM)的时序图。图12是用于处理广播调度消息的实施例方法的过程流程图。图13是用于实现在广播调度流上的更新检测的实施例方法的过程流程图。 图14是示出接收机设备可以在不同时间在广播网络的和/或广播流的覆盖区域外的时序图。图15是示出用于在支持初始获取流(initial acquisition flow, IAF)的系统上检测对广播调度流(BSF )的更新的实施例方法的时序图。图16是示出用于在同一超帧内接收广播调度消息的两个不同版本的实施例方法的时序图。图17是用于在来自初始获取流(IAF)系统的支持的情况下处理广播调度消息(BSM)的实施例方法的过程流程图。图18是示出用于确定在接收机设备与广播服务器之间广播更新的广播调度消息(BSM)的时间的实施例方法的时序图。图19是示出在接收机设备上的文件传递架构(FDF)的分层视图的系统方框图。图20是用于实现支持在不同应用之间的文件共享的文件传递架构(FDF)的实施例方法的过程流程图。图21是示出可以用于在不同应用之间共享文件的结构、数据流和高级步骤的系统方框图。图22是示出在接收机设备上的文件传递架构(FDF)的结构和数据流以及该文件传递架构选择接收或拒绝文件的决策过程的系统方框图。图23是示出在接收机设备上的文件传递架构(FDF)的结构和数据流以及接收机设备上的文件传递架构接收和存储文件的过程的系统方框图。图24是用于选择性地接收仅是应用感兴趣的元素(element)的实施例方法的过程流程图。图25是用于处理广播调度记录的实施例方法的过程流程图。图26是示出在接收机设备上的文件传递架构(FDF)的结构和数据流以及处理广播调度记录的过程的系统方框图。图27是示出用于在文件传递架构上接收文件的实施例方法的系统方框图。图28是示出暂存空间管理(scratch space management)的结构、数据流以及可以在文件传递核心(FDC)中实现的过程的系统方框图。图29是用于处理和存储元素的实施例方法的过程流程图。图30是用于选择要从暂存空间删除的项目的实施例方法的过程流程图。
图31是示出用于对数据进行排序和组织的实施例方法的结构和数据流的系统方框图。图32是示出如何可以在紧急数据流上同时地传递紧急文件的时间线图。图33是示出如何可以为分开的广播服务流上的流来处理文件的消息流程图。图34是示出在多频网络中(MFN)接收机设备如何可以检测存在对广播服务流的更新，但同时确定其不能接收该更新的时间线图。图35是示出如何可以强制正在向新的多路复用(multiplex)移动的接收机设备接收用于该新的多路复用的BSM的时间线图。
图36是示出其中在同一射频上有一个以上多路复用的文件传递架构配置的时间线/方框图。图37是示出其中文件传递核心(FDC)被配置为独立地在不同射频上调度文件下载的文件传递架构配置的时间线/方框图。图38是示出文件传递管道(file delivery pipe, FDP)的结构的系统方框图。图39是示出文件名称到存储名的文件传递架构映射的消息流程图。图40是示出受管理元素表(MET)的方框图。图41是用于管理用于应用的存储空间的实施例方法的过程流程图。图42是用于检查用于要为应用接收的元素的存储空间的实施例方法的过程流程图。图43是示出用于检查用于要为应用接收的元素的存储空间的、在应用层与文件传递架构之间的数据流与交互的流程图。图44是用于将接收的文件移动到应用存储空间的实施例方法的过程流程图。图45是示出在将接收的文件移动到应用存储空间的同时，在应用层(App层)、文件传递核心(FDC)层与文件传递文件管理(FDM)层之间的数据流与交互的流程图。图46是用于将多个文件名称映射到文件传递文件管理(FDM)层的受管理元素表中的同一存储名称的实施例方法的过程流程图。图47是用于处理对于接收的文件没有足够的应用存储空间的情况的实施例方法的过程流程图。图48是示出在处理对于接收的文件没有足够的应用存储空间的情况时在应用层(App层)与文件传递架构(FDF)之间的数据流与交互的流程图。图49是用于处理删除功能的实施例方法的过程流程图。图50是用于在文件传递架构上实现文件打包(bundling)特征的实施例方法的过程流程图。图51是示出在文件传递架构上的文件打包特征中，在应用层(App层)、文件传递核心(FDC)层与文件传递文件管理(FDM)层之间的数据流与交互的流程图。图52是用于产生由文件传递文件管理层用来在要保存的文件包(filebundle)中选择文件的选择字符串的实施例方法的过程流程图。图53是示出在确定由文件传递架构上的文件打包特征使用的选择字符串时，在应用层(App层)、文件传递核心(FDC)层与文件传递文件管理(FDM)层之间的示例性数据流与交互的流程图。
图54是用于确定是否应接收文件包的实施例方法的过程流程图。图55是示出在确定是否应接收文件包时，在应用层(App层)、文件传递核心(FDC)层与文件传递文件管理(FDM)层之间的示例性数据流与交互的流程图。图56是示出在保存在文件包中的文件时，在应用层(App层)、文件传递核心(FDC)层与文件传递文件管理(FDM)层之间的示例性数据流与交互的流程图。图57是示出在受管理元素表(MET)中的示例性文件包条目的消息流程图。图58是用于将文件包接收并保存在应用存储空间中的实施例方法的过程流程图。图59是示出在将文件包接收并保存在应用存储空间时，在应用层(App层)、文件传递核心(FDC)层与文件传递文件管理(FDM)层之间的示例性数据流与交互的流程图。·
图60是用于删除从文件包中接收的文件的实施例方法的过程流程图。图61是示出在删除从文件包中接收的文件时所包括的逻辑和示例性数据流的流程图。图62示出在接收先前已接收到的文件包时，在应用层(App层)、文件传递核心(FDC)层与文件传递文件管理(FDM)层之间的示例性数据流的流程图。图63是示出用于在文件传递核心(FDC)与文件传递文件管理(FDM)层之间交换数据的多种文件传递核心有效负荷格式的数据结构图。图64是示出另一个示例性文件传递核心有效负荷格式的数据结构图。图65是示出用于作为具有两个名称的单个文件的元素的示例性文件传递核心有效负荷格式的数据结构图。图66是示出用于作为具有两个名称的文件的文件包的元素的示例性文件传递核心有效负荷格式的数据结构图。图67是用于产生并发送广播调度消息的实施例方法的过程流程图。图68是示出根据实施例的用于多个应用的文件的摄取和接收的系统方框图。图69和70是根据实施例的适用于向文件摄取系统提交文件的示例性数据图表。图71是示出根据实施例的作为文件摄取系统的组成部分的文件发送调度的时间线图。图72A-72D是示出文件发送的调度与文件传递服务如何可以是动态的，以便能够在广播调度中容纳由文件摄取系统接收的新的紧急文件的时间线图。图73和74是关于文件摄取系统的文件摄取如何导致产生广播调度消息并导致在广播调度消息中列出的调度时间发送摄取文件的图示说明。图75是用于摄取并处理文件以通过广播文件传递服务传递的实施例方法的过程流程图。图76示出了如何可以在不同的本地运行基础架构中广播由广域多路复用(widemultiplex)与局域多路复用(local multiplex)构成的不同信号多路复用。图77是根据实施例的如何可以在不同的广域多路复用信号中分配不同容量的文件传递管道的图示说明。图78A和78B示出了如何可以通过不同容量的文件传递管道发送文件传递传输。图79A是示出根据实施例的数据传输组织方案的时间线图。
图79B-79D示出了如何可以对文件传递传输进行分割并在通过不同的文件传递
管道来发送。图79E-79F是示出根据多个实施例的数据传输组织的细节的另外的时间线图。图80示出了如何可以调度不同的文件以便在并行文件传递管道上进行广播。图81A-81C示出了可以在文件传递管道内发送文件的不同方式。图82A-82B示出了传递管道内的大文件的传输如何可以被紧急文件的传输中断。
图83A和83B是用于调度并通过文件传递管道发送文件的实施例方法的过程流程图。图84是适合于与多个实施例一起使用的移动接收机设备的软件架构图。图85是在接收机设备内运行的应用如何可以指定文件以便由文件传递服务模块接收的图示说明。图86是根据实施例的可以用于文件传递目录中的示例性数据图表。 图87A和87B是可以在接收机设备内实现的用于接收通过广播文件传递服务所传递的文件的实施例方法的过程流程图。图88是适合用于实施例中的接收机设备的组件方框图。图89是适合用于实施例中的服务器设备的组件方框图。
具体实施例方式将参考附图详细说明多个实施例。只要有可能，相同的参考标号将在附图通篇中用于指代相同或相似的部分。对特定实例和实现方式的参照是用于说明性目的的，并非旨在限制本发明或权利要求的范围。本文使用词语“示例性的”表示“充当示例、例子或举例说明”。本文中被描述为“示例性的”任何实现方式都并非必然解释为对于其它实现方式而言是优选的或有优势的。术语“移动设备”和“接收机设备”在本文中可互换地使用，以指代以下任意一个或全部移动媒体广播接收机、蜂窝电话、个人电视设备、个人数据助理(PDA)、掌上电脑、无线电子邮件接收机(例如，Blackberry_$WPTreo 设备)、有多媒体互联网功能的蜂窝电话(例如，Blackberry Storm )、全球定位系统(GPS)接收机、无线游戏控制器、车载(例如汽车)接收机、以及类似的具有可编程处理器和存储器和/或仅前向链路移动TV广播接收机电路以便接收和处理诸如MediaFLO FLO TV 广播之类的移动TV广播传输的个人电子设备。然而，术语“移动设备”和“接收机设备”不应局限于所列举的接收机列表，并且可以包括能够接收任何移动广播电视服务和/或实现下述的任何广播标准的任何设备。词语“广播”和“多播”在本文中可互换地使用，以表示数据(信息分组)的传输，以使得其可以由大量接收设备同时接收。广播消息的实例是移动电视服务广播信号，包括内容广播(内容流)和开销信息广播(开销流)，诸如元数据消息。本文使用的术语“文件”指代可以存储在计算设备上的任意各种数据结构、数据和数据库文件的集合。在本文及附图中使用了以下术语和缩写广播调度消息(BSM);广播调度记录(BSR);广播调度周期(BSP);广播调度流(BSF);广播调度监视记录(BSMR);条件性接入解决方案(CAS);恒定或可变比特率(CBR/VBR);目录信息消息(DM) ；DIST (分发组件，其以所配置的速率发送文件和开销消息)；文件传递架构(FDF);文件传递管道(FDP);文件摄取系统(FIS);流广播调度记录(FBSR);前向纠错(FEC)码；FLO服务节点或FSN (实际OTA传输中所涉及的组件，其可以是用于FLO的传输网络特定FSN，或者可用于其它广播技术的一般性BSN，其提供了对于特定传输技术的适应性)；初始获取流(IAF) ;IP数据服务(IroS)；局域多路复用(LM);本地运行基础架构(LOI);服务质量(QoS);开销调度服务器或OSS (用于管理和公布开销消息、元数据和/或版本变化的组件);射频(RF);实时(RT);类型值长度(Type-Value-Length, TLV);视频点播(VOD)应用(vodApp);及广域多路复用(WM)。将来可以获得或设想多种不同移动广播电视服务和广播标准，其全都可以依据多个实施例而实现和获益。这些服务和标准包括例如，开放移动联盟移动广播服务推动者套件(OMA BCAST)、MediaFL0 、数字视频广播IP数据广播(DVB-IH)C)、数字视频广播一手持设备(DVB-Η)、数字视频广播一卫星服务到手持设备(DVB-SH)、数字视频广播一手持设备2(DVB-H2)、先进电视系统委员会一移动/手持设备(ATSC-M/H)、和中国多媒体移动广播(CMMB)0这些广播格式中的每一种都涉及广播通信信道。为了易于参考，参考MediaFLO 系统来说明多个实施例，其在FLO TV 广播系统中实现。然而，对MediaFLO 术语和技术细节的参考仅是出于说明性的目的，并非旨在将权利要求的范围局限于特定FLO通信系 统或技术，除非在权利要求文字中明确表述了。多个实施例提供了用于通过广播系统向移动设备有效地传递文件的机制和系统。可以将用于广播和接收的文件在逻辑上被标识为属于文件系统中的目录。为了将这个文件系统提取(file system abstract)以电池高效的方式用于向接收机设备广播文件,广播系统可以使用用于传送与可下载获得的文件有关的信息以及要广播这些文件的时间的机制。在各个实施例中，这可以通过在文件的广播之前或者与文件的广播一起来广播广播调度消息(BSM)来完成。通常，BSM向接收机设备通知将在将来广播的文件，以及接收机设备可以预期要在其中广播所述文件的特定时间帧。每一个BSM都可以包括文件内容和广播调度信息，诸如被广播的文件与各种服务或应用的关联(例如，服务ID或应用专用目录上的文件名称)；关于被广播的文件是新的、被更新的还是重复文件的标识(例如，文件ID/元素ID或版本号)；可以在其中接收文件的广播传输流(例如，流ID、由IP地址和UDP端口号标识的IP流);将广播文件的时间(例如，传递窗口)；和何时可以以新的信息更新传递调度信息(例如，BSM)0BSM可以作为开销传输流(例如，其由流ID、IP地址和UDP端口号等所定义)的组成部分来传送，开销传输流提供关于以下的传输调度信息在给定频率上(例如，信道55)、该频率中的发射谱的一部分上(例如，MediaFLO 局域对比于广域多路复用)的文件广播、和/或关于传输技术(例如,MediaFLO 或ATSC)。可以通过引导开销流(bootstrpoverhead flow)(例如，MediaFLO 传输中的IAF)来发现用于此类传输的这些开销流、信道、流或频率的可用性、信号或超帧中用来广播BSM的部分、及用于发送BMS的传输技术。根据实施例配置的接收机设备可以利用BSM消息来从被公布的不同文件广播中选择文件。接收机设备可以基于与特定文件相关联的服务或应用、该文件是新的还是对先前接收的文件的重传或更新、或者各种其它因素，使用BSM来接收该文件。在多个实施例中，BSM可以支持对应用/服务ID的别名和/或文件的传输包的说明。在多个实施例中，每一个BSM都可以在某个时间仅公布广播调度信息的一部分。这提供了在内容刷新与接收机设备为保持跟踪上BSM的最新版本所必须消耗的电池电量之间的折衷。多个实施例可以包括在广播网络内或者与广播网络通信的文件摄取系统(FIS)，广播网络可以提供接口，内容提供方可以使用所述接口来向广播系统通知要广播新的文件。内容提供方可以使用文件摄取系统来指定对文件的广播传输要求，诸如每一个文件的时间线要求(例如，容许时延)和传输鲁棒性要求(例如，前向纠错级别或重传数量)。文件摄取系统可以在新文件摄取时使用由内容提供方所指定的传输要求，并尝试将新文件连同已被接受并被调度进行传输的文件一起打包到广播发送流中。在多个实施例中，当没有成功地将新文件打包到广播传输流中时(即，新文件不能连同已被调度进行传输的文件一起放置到发送流内)，可以考虑文件摄取已经失败。在多个实施例中，文件摄取系统可以考虑文件之间的优先级，以便当打包最初不成功时，以抑制先前所摄取的文件的传输为代价成功进行新文件摄取。一旦由文件摄取系统处理了新文件，文件摄取系统就可以产生BSM，其仅公布在广播调度周期(BSP)上成功调度的文件的一小部分。接收机设备可以使用BSM中的该信息来 计划其对文件广播的接收。这样，当接收机设备确定对该设备上的应用而言感兴趣的文件将会被广播时，接收机设备可以调度在所公布的广播调度周期中启动接收机电路。通过仅公布成功调度的文件的一小部分，可以通过将新文件插入到由最近广播的BSM覆盖的时间段之后的广播调度中，并以修改的调度来广播新的BSM，来满足新文件摄取。在多个实施例中，广播系统可以基于现有调度信息来控制对BSM的更新和文件的发送。如上所述，在任意给定时间，BSM都可以仅公布广播调度信息的一小部分。这提供了在一方面的内容刷新和调度灵活性与另一方面的接收机设备的功耗之间的折衷。可以通过限制在每一个BSM中的广播调度信息的量来使得内容刷新最大化。这实现了更大的文件传输调度灵活性，因为可以调整该广播调度的更大部分(即，在BSM中没有通告的部分)以插入新摄取的文件。通过允许BSM频繁地改变，广播方可以以更短的通知来广播文件，并容纳文件传递优先级和调度中的变化。然而，频繁地改变BSM需要接收机设备更经常地通电以接收新的BSM。每一次通电都消耗额外的接收机设备的电池电量。因此，对BSM的频繁更新会导致接收机设备消耗更多的电池功率。因此，可以通过使得每一个BSM中呈送的广播调度的量最大，来使得接收机设备的功耗最小。因此，广播方可以在调度灵活性与设备功耗之间达成针对BSM的更新频率的平衡，以便增强用户体验。文件摄取系统还可以支持与文件相关的属性的摄取。文件摄取系统可以格式化文件属性，因此可以借助开销消息(例如，BSM)来传送它们。在多个实施例中，接收机设备可以使用这些文件属性来选择接收和下载的文件。在多个实施例中，接收机设备可以基于文件的文件属性，使用过滤标准来选择文件。在多个实施例中，文件摄取系统可以支持一次摄取一个以上的文件。在这些实施例中，文件摄取系统可以将两个或更多个文件打包在一起来作为单个文件发送，或者作为较大文件的较小集合来发送。如果不能将文件打包在一起，文件摄取系统就可以独立地调度每一个文件来发送。将文件打包在一起允许更有效地应用前向纠错(FEC)保护，并提高了包含在所发送的文件内的数据的完整性。在多个实施例中，可以将广播资源(例如，广播信号的带宽或分段)组织在文件传递“管道”中，所述文件传递“管道”是一种业务工程工具，用来提高系统的总体效率和资源预留目的(例如，存在用于小文件的管道和用于大文件的管道)。文件传递管道捕获用于文件传输的资源分配，并支持将多个不同文件多路复用到一个或多个传输流上。将广播资源组织到文件传递管道中可以通过实现用于在总体分配的资源上时分复用文件的集中式文件调度来提高效率。因此，组织资源的方式应有效且应对与不同文件传递应用相关的不同要求。在多个实施例中，可以将资源组织到多个文件传递管道中，并且可以向文件摄取系统通知在广播系统中定义的多个文件传递管道。被这样通知后，文件摄取系统可以采用应对为每一个文件所指定的应用专用的传递要求的方式，并根据可驱动不同管道的设置的业务工程目标(例如，用于小文件的管道和用于大文件的管道，以避免在大文件传送期间的小文件的队头阻塞)，来在多个传输资源上调度文件进行广播。多个实施例支持实施各种策略来定义文件传递管道和在不同管道上调度文件进行发送。例如，在多个实施例中，应用的类可以映射到特定管道，例如，可以在专用管道上广播具有低等待时间要求的小文件。在多个实施例中，文件摄取系统可以将大文件的传输分割到多个分开的广播窗口中，以实现短文件发送。在多个实施例中，文件摄取系统可以经由不同流在同一管道上调度多个并发文件传输。
在多个实施例中，广播方应用或服务可以向文件摄取系统提交大量的文件，以便组装到适于传输的一个或多个文件中。相应的接收机方应用或服务可以仅兼容或关注被广播的文件的一个小子集。在此情况下，广播方应用或服务可以向文件传递服务提供适用性元数据，以使得系统能够构造BSM或类似的开销文件(例如，目录文件)，其包括可以由接收机方应用或服务使用的标识元数据。例如，BSM开销文件可以列出将在一个广播周期内广播的全部文件，以及用于要被广播的文件的标识或适用性信息。此类标识元数据可以包括应用专用属性，诸如能够或者应该接收文件的应用或服务的名称或标识符。在接收机设备上，BSM开销文件可以由接收机设备接收，并由相应的接收机方应用用于选择要接收的文件。在多个实施例中，接收机方应用可以基于多个应用专用逻辑和可用属性，并通过使用包含在BSM开销文件中的标识或适用性信息，来进行这个选择。在多个实施例中，接收机方应用可以通过向接收机设备上的文件传递服务模块指示预期的应用或服务文件名称、或者预期文件的标识符，来请求从文件传递服务接收所选择的在BSM中描述的文件。接收机设备上的文件传递服务模块可以依据BSM确定包含预期文件的被指示文件将会在何时且在哪一个信道/流/广播资源上广播。仅当广播有可能包含接收机方应用所请求的或者与接收机方应用兼容的文件时，接收机设备中的处理器才可以使用这个信息来“唤醒”接收机电路。BSM中的信息也可以使得接收机设备上的处理器能够精确定出接收机需要在其中开启并监听数据的准确时间帧。通过精确定出接收机需要在其中开启的准确时间帧，接收机设备可以节省大量电池功率，同时使得处理资源可用于其它任务。在多个实施例中，使用文件传递服务(例如，FDF服务)的广播方应用可以在向文件摄取系统提交文件来进行发送时，提供与文件相关的应用专用属性。这种应用专用属性可以借助BSM传输到接收机设备。接收机方应用可以通过指示在表征感兴趣文件的应用专用参数内的常规表述或逻辑表述，来请求从接收机设备的文件传递服务模块进行文件捕获。通过使用常规表述或逻辑表述来表征感兴趣的文件，接收机设备可以使用应用专用参数作为过滤标准选择要接收的文件。接收机设备的文件传递服务模块可以通过从BSM中确定预期文件的特性(日期/时间、流ID等)，使用这种过滤标准来仅接收正在广播的文件的一个子集。可以在各种移动多媒体广播系统内实现多个实施例，图I中示出了其一个实例。诸如MediaFLO 广播网络的移动多媒体广播网络I通常包括多个广播发射机2，其受移动广播网络控制中心的控制，移动广播网络控制中心在本文中被称为广播运行中心4(或者附图中的“B0C”)。广播网络I从广播发射机2广播内容，作为移动广播传输3来由接收机设备10进行接收，接收机设备诸如为移动电视接收机、智能电话、蜂窝电话、个人数字助理(PDA)、交互式游戏设备、笔记本电脑、智能本、上网本、数据处理装置，或者其他此类电子设备。在移动广播网络控制中心4内(也称为广播运行中心或“B0C”)通常会有一个或多个服务器和系统，用于管理实时内容广播、电子服务向导、与内容广播相关的目录消息和BSM的产生、以及经由多媒体广播网络I的开销流进行广播的元数据消息的产生。除了普通内容传递系统以外，移动广播网络I还可以包括文件摄取系统服务器 (FIS)31，用于接收、存储、调度和格式化经由移动广播网络I广播的文件。文件摄取系统服务器31可以经由直接网络连接或者诸如互联网7的间接网络连接，从文件内容提供方9接收要广播的文件。除了移动多媒体广播网络I以外，接收机设备10通常被配置为经由诸如蜂窝电话网络之类的单播网络11进行通信。典型的蜂窝电话网络包括多个蜂窝基站12，其耦合到网络运行中心14，网络运行中心14操作以连接在移动设备10以及其他网络目的地之间的语音和数据呼叫，例如，经由电话陆上线路(例如，POTS网络，未示出)和互联网7。在接收机设备10与单播网络11之间的通信借助诸如4G、3G、CDMA、TDMA及其他蜂窝电话通信技术之类的双向无线通信链路13来完成。为了有利于互联网数据通信，单播网络11通常包括一个或多个服务器16，其耦合到网络运行中心14或者在网络运行中心14内，网络运行中心14提供到互联网7的连接。在进一步的实施例中，单播网络11可以是无线广域网，诸如WiFi、WiMAX等。接收机设备10可以借助单播网络11与广播网络I通信，例如借助经由互联网7到广播网络服务器6的IP数据呼叫，以便订购广播服务并向广播装置发送用户交互消息。图2示出了根据实施例的在广播网络I的一部分(例如，MediaFLO 广播网络)内的信息流。文件内容提供方9可以经由广播文件传递服务向文件摄取服务器31提供要发送的文件。文件摄取服务器31可以调度并存储要广播的文件，如以下更充分说明的。在调度广播时间，文件摄取服务器31可以向广播运行中心4 (BOC)提供所调度的文件，在广播运行中心4产生广播信号，作为包括内容流26和开销流28的信息的多路复用。这样，要借助文件传递服务发送的文件可以作为内容流26的组成部分来发送，同时将BSM作为一个或多个开销流28的组成部分来发送。接收机设备10接收多路复用信号，并能够分别接收包括BSM的开销流28及其它开销信息流(例如，控制信道)，并使用BSM中的信息来从内容流26接收特定文件。在典型的多媒体移动广播系统中，在被组织到多个超帧中的无线信号中发送信息。每一个超帧都包括多个信号，这些信号按照频带内的频率和规定时间边界(例如，超帧边界)内的时间来组织，其编码传送广播内容和开销信息的多个数据分组。例如，在MediaFLO 广播系统中，将广播传输组织到跨度6MHz频带(例如，716MHz到722MHz)的1/2超帧中。MediaFLO 广播信号可以在其它频带上发送，并且可以通过使用多个不同的频带来同时发送多个信号。每一个超帧都可以包括开销流专用的部分和用来传送与内容流相关的多个信道的部分。如上所述，该开销流及其它开销流(例如，控制信道)内的信息向接收机设备通知可以在超帧内的何处获得该特定内容流，以及多个分组如何与该内容流(content)的流(streams)相关联。图3示出了在适合于实现借助文件传递服务来传递文件的多个实施例的广播通信系统的广播装置方上的系统功能组件。实时内容提供方服务器8可以向广播运行中心4内的实时编码器39发送实时内容(例如，音频、视频、文本等)。文件内容提供方9可以借助文件传递服务向文件摄取服务器31提供要传递的文件。文件摄取服务器31可以在本地数据库31中存储接收的文件，并调度接收的文件进行广播。与所调度的广播时间有关的信息以及文件属性数据可以提供给开销信令服务器(OSS) 34，其是用于管理并公布BSM中开销版本变化的组件。如以下更充分说明的，文件摄取服务器31的文件摄取和发送调度可以是动态的，以使得可以将对所调度的广播时间的频繁变化传送到开销信令服务器34。开销信令服务器34可以向分发服务器33提供更新的BSM，分发服务器33是用于以所配置的速率发送文件和开销消息的组件。分发服务器33可以向仅前向链路(FLO)服·务节点(FSN) 35提供要发送的BSM，仅前向链路(FLO)服务节点(FSN) 35将BSM引导到开销数据传递系统36，以便经由广播网络I发送。在接近所调度的用于发送文件的时间时，文件摄取服务器31连同本地数据库32可以向分发服务器33提供要发送的文件。分发服务器33可以向FLO服务节点35提供这些文件，以及用于指定何时广播每一个文件的控制数据。FLO服务节点35可以向文件传递系统38传递要发送的文件，文件传递系统38经由广播网络I发送文件。移动设备10随后可以经由无线数据传输从广播网络I接收文件。尽管图3示出了作为分开的单元或服务器的文件传递系统的多个组件，但本领域技术人员会理解，可以在单个服务器或比图3所示的更少的服务器内来实施这些不同功能过程。例如，可以在单个服务器设备内连同文件摄取系统31 —起实现开销服务服务器34、分发服务器33和流服务节点35，由不同软件模块或者集成的软件系统来完成这些功能中的每一个。作为多个实施例的图示说明，图4显示了 MediaFLO文件传递架构(FDF)40中包括的最高级别(top-level)上的组件。文件传递架构40可以同时提供对不同文件传递应用的支持。逻辑概念形式上的文件的传递涉及用于在文件从内容提供方被接收、经由广播系统发送以及由接收机设备接收时进行文件的操作和管理的实施例方法。在高级别上，广播文件传递系统40包括前端，其是通信系统的广播方；及接收机设备，其选择性地接收并存储被发送的文件。在前端中，本文称为“前端应用”42、43的提供要发送的文件的应用定义要传递的文件。在前端中的服务器内，文件摄取系统31可以从文件内容提供方或前端应用42、43接收要传递的文件，并在广播调度中调度文件来进行传递。文件摄取系统31还可以在存储器中存储成功调度的文件，以便稍后通过文件传输网络41发送。由前端应用42、43提供的文件可以打包到一个或多个传输文件中以便经由文件摄取系统31摄取，并经由文件传输网络41传递到接收机设备。在诸如MediaFLO 接收机设备的接收机设备上，设备应用45、46可以表征或指示要接收的文件，并从文件传递服务模块44请求这些文件。可以在接收机设备中将文件传递服务模块44实现为被配置为向设备应用45、46提供文件捕获服务的软件。文件传递服务模块44可以响应于对文件的请求，使用传递和调度信息来捕获所请求的流，并将其存储在存储器中。文件传递服务模块44可以管理文件的接收、存储和维护。在组合得到要发送的文件时，文件摄取系统31可以使用文件系统模拟来产生传输文件，在文件系统模拟中，应用专用目录结构中的文件路径名称唯一性地标识用于一组应用的文件。如上所述，在广播系统的前端中的服务器内，可以提供文件摄取系统31以接收要传输的文件，针对在广播调度中的传递时机调度文件，并在存储器中存储成功调度的文件以便稍后通过广播网络的文件传输网络41进行发送。文件摄取系统31可以指定与文件有关的额外属性，诸如文件名称、文件的参数描述(例如，风格、文件类型等)、文件内容的参数描述(例如，在文件中包含的数据报分组的各个数据报分组的源和位置、身份、应用或文件类型等)、及与要发送的文件的内容相关联的其它信息。文件摄取系统31还可以指定用于说明每一个文件的广播传递要求的参数。在多个实施例中，文件摄取系统31可以向文件分配唯一性的标识符(例如，文件ID)，其可以用于版本目的，及用于将所提交的文件打包到组合分组中以便有效地应用前向纠错(FEC)码。文件摄取系统31还可以将前向纠错(FEC) 码应用于所摄取的文件，以提高其广播传输可靠性。在一个实施例中，文件摄取系统31可以为新接收的要发送的文件调度广播传递时机。作为该过程的组成部分，文件摄取系统31可以基于多个参数来确定发送调度。例如，在一个实施例中，文件摄取系统31可以根据文件大小和可用资源来产生发送调度。在另一个实施例中，发送调度也可以考虑由内容提供方分配给文件的优先级。在多个实施例中，可以以算法的形式完成对文件广播时间的调度，以确定发送的开始时间，以便满足对新接收的文件和先前摄取的文件的广播传递要求。文件摄取系统31可以存储成功调度的文件，以便稍后通过文件传输网络41进行发送。文件摄取系统31可以根据由文件摄取系统31先前确定的文件调度信息，在适当的时间向广播网络分派所调度的文件。在调度文件的发送时，文件摄取系统31可以知道发送资源，诸如在文件传输网络41中定义的文件传递管道。使用与文件传递管道的可用性有关的信息，文件摄取系统31可以在多个发送资源中调度文件，以便应对由文件内容提供方定义的应用专用传递要求。在一些实施例中，文件摄取系统31可以被配置为将特定管道用于特定类的应用。例如，可以在专用发送管道上广播具有低等待时间要求的小文件。可替换地，文件摄取系统31可以将大文件的传输划分到多个分开的广播窗口中，以允许具有减小的延迟的短文件发送。文件摄取系统31还可以调度经由不同发送管道的同一类型的多个同时发送。在多个实施例中，文件传输网络41可以是MediaFLO 网络或其它广播网络。在多个实施例中，文件传输网络41可以是广播和单播网络的组合。当传输网络是广播网络时，可以调度文件发送，以使得可以在正在发送的所有不同文件之间有效地共享广播信道。另外，如果广播信道可以同时支持多个媒体流，数据文件的发送可以与多个媒体流中的一个相关联。作为文件传递架构40的组成部分，可以在广播传输网络中可获得的开销消息流中广播一系列BSM。如上所述，BSM可以提供使得接收机设备能够将广播的文件与特定服务或应用相关联的信息。BSM还可以包括与广播的文件有关的文件ID/元素ID或版本信息，与能够在其中接收文件的传输流有关的信息，与将何时广播文件有关的信息(例如，传递窗口)，和与何时将以新信息更新传递调度或BSM有关的信息。如上所述，用于广播和接收的文件可以在逻辑上被标识为属于文件系统中的目录。在多个实施例中，这个文件系统提取允许将文件定义为属于应用专用目录结构，在该应用专用目录结构中，根(最上面的)目录指示了应用。例如，属于应用testApp的文件testFile可以定义为“/testApp/testFile”。在多个实施例中，可以将文件进一步组织到子目录中，作为用于描述文件的语义属性的机制。例如，可以基于在文件的内容与广播信道(例如，CNN、ABC等)之间的关联来组织文件。这样,用于视频点播应用(vodApp)的文件可以组织为属于某个应用专用目录，例如/vodApp/CNN/或/vodApp/ABC/等。作为文件系统提取的进一步的实例，天气应用(weaApp)可以在每个城市的基础上组织与天气更新有关的文件，并且使用子文件夹来指示与特定城市相关联的文件。例如，包括短语“/weaApp/LA/”的文件名称可以包括与洛杉矶的天气更新有关的文件，而包括短语“/weaApp/NY/”的传输文件名称可以包括与纽约的天气更新有关的文件。例如，weaApp文件可以被命名为“weaApp/LA/fl. jpg”与“/weaApp/NY/f4. jpg”,以便能够确定特定文件并按照城市对其进行分组。 这个文件系统提取简化了通过广播文件传递服务传输的文件的定义和管理。文件系统提取还简化了应用开发过程，因为应用开发者无需自身关心广播传输系统的细节。图5示出了文件系统提取的实现方式。具体地，图5示出了可以用于经由文件传输网络41传输文件以便由天气应用44使用的文件名称。在所示实例中，发送方天气应用43可以通过发出具有适当命名的文件的发送命令来请求发送文件。例如，天气应用43可以使用命令 sendFiIe(/weaApp/LA/0125IOUpdate. jpg)(发送文件(/weaApp/LA/012510Update.jpg))来请求发送LA天气文件。文件摄取系统31接收这些文件，并将文件名称包括在BSM消息内。在接收机设备方上，在接收机设备的处理器内运行的设备应用可以通过使用与在前端方使用的相同的文件名称结构来请求文件。这在图5中示出了，在此显示了客户机天气应用46可以向文件传递服务44注册，并用单个命令来请求捕获所有相关文件。例如，如果接收机设备位于纽约市附近(例如可以基于用户偏好或如GPS的位置确定能力来确定)，设备应用46就可以通过发出捕获命令并提供适当命名的目录，来请求接收所有与纽约市相关的天气文件。在所示实例中，客户天气应用46可以发出“captureAll (全部捕获)”命令，提供“/weaApp/NYC/”作为所请求的目录名称(“/”可以用作用以区分目录名称与文件名称的约定。这样，在所示实例中，客户机应用46仅需要发出“captureAll (/weaApp/NYC/)”命令，以从前端应用42接收所有相关的纽约市天气文件。这个通过使用文件系统提取来请求和发送文件的方法极大地简化了文件发送和应用开发过程。图6示出了文件系统提取的另一个实现方式。具体地，图6示出了前端交互式应用(iTVApp) 60提交作为开销文件的图像文件和目录的情形。目录文件(/itv/sig/cat.xml)提供与从交互式应用可获得的文件有关的信息。当前端交互式应用60提交要传输的新文件时，也可以连同这些文件一起提交更新后的交互性目录。更新后的交互性目录可以描述新增加的交互性文件。这样，在所示实例中，交互式应用服务器60连同发送命令一起向文件摄取系统31提供目录文件和三个交互性文件。在所示实例中，发送命令可以是“sendFiIe(/itv/sig/cat. xml;/itv/res/svc_5/fI. jpg;/itv/res/svc_5/f2. jpg;/itv/res/svc5/f3. jpg) ”。在接收机方，客户机应用62可以向文件传递服务模块44发出请求命令，用于对目录文件的更新的连续捕获。在所示实例中，这个请求命令可以是“captureAll (/itv/sig/cat. xml); ”,在此将文件名称而不是目录名称(参数不是由“/”终止)用作对服务请求的参数。在发出该请求命令后，客户机应用62可以发出请求命令，以按照对目录文件中应用专用信息的应用专用处理，基于对目录信息的更新来捕获特定文件。例如，客户机应用62可以发出“singleCapture(/itv/res/svc_5/f2. jpg) ”命令来捕获感兴趣的单个文件“f2. jpg ; ”。由于预计这些文件的内容不改变，singleCapture O不继续监视对所请求的文件的更新。在多个实施例中，实现上述文件系统提取系统的应用可以与实现发现和请求可经由文件传输网络41接收而获得的文件的其它方式的应用混合。这样，在多个实施例中，可以利用混合系统，其使用实现不同文件提取和/或文件请求/发送技术的客户机和前端应用。这个混合系统可以对在单一架构上同时支持不同类型的文件传递应用的文件传递架构(FDF)的能力有贡献。
图7示出了在文件传递管道中通过时分复用文件以便共享发送资源，来调度所摄取的文件。如上所述，在多个实施例中，可以将资源组织到文件传递管道中以提高系统的总体效率。将资源组织到文件传递管道中提高了效率，这是因为提供文件传输服务(例如，FDF服务)的大多数广播网络通常是资源绑定的。在多个实施例中，文件传递管道可以是特定的一组资源，其专用于发送过程。在多个实施例中，文件传递管道可以是专用的广播资源。在多个实施例中，专用资源可以包括专用于特定的文件传输过程的网络资源。在多个实施例中，一个或多个文件传递管道可以用于通过文件传递网络传输一个或多个文件。图7还示出了文件传递管道72，其被调度来传送一系列文件。以不同的传输文件ID和/或元素ID (例如，fID_l到fID_4)来标识每一个文件。传输文件ID和/或元素ID可以唯一地标识文件，并提供一种形式的隐含的版本支持(即，可以为文件的每一个提交的版本分配一个新的文件ID/元素ID)。图7示出了可以调度每一个文件以在特定广播窗口(Bff)内广播，其中，每一个广播窗口(例如，Bff fID_2)都对应于一个时间段，在该时间段期间可以发送文件(例如，fID_2)。在多个实施例中，通过专用管道发送每一个文件所需的广播窗口可以根据传输管道数据速率和所发送的文件的大小来定义。在多个实施例中，广播窗口可以与文件大小除以文件管道数据速率的商成比例。图7还示出了广播调度流(BSF)70可以用于传送广播调度消息(BSM)，其描述了要传输的文件、其广播窗口以及发送元数据。在多个实施例中，广播调度流70可以是与内容流分离的开销流。在多个实施例中，可以在文件前发送广播调度消息，以使得接收机设备可以及时启动接收机电路，以接收其预期的文件。在多个实施例中，可以频繁地重播相同的广播调度消息，例如在每一个超帧中，以确保由接收机设备可靠地接收广播调度消息。如上所述，在多个实施例中，每一个广播调度消息(BSM)都可以仅描述所调度的文件的一小部分。这用于支持这样的情况有大量文件可用并可以为无线发送而调度，在单个广播调度消息中定义所有所调度的文件是不现实的。在广播调度消息中仅公布所调度的文件的一小部分还支持这样的情况由于不断提交要发送的新文件，调度可能频繁地改变。这样，在多个实施例中，可以产生广播调度消息，以使得它们仅描述所调度的文件的一小部分。在这些实施例中，广播调度消息可以描述其将在给定的广播调度周期(BSP)内广播的一系列文件。图7还示出了每一个BSM都可以描述每一个广播调度周期(BSP)内的一系列文件。具体地，图7示出了在第一广播调度周期(BSP1)中仅广播三个唯一文件(fID_l到fID_3)的实例。在多个实施例中，每一个广播调度周期都可以定义表示在相应的广播调度消息中包含的公布的文件广播调度的数量的量。可以在同一广播调度流70内反复发送这些广播调度消息。例如，如BSM70a到BSM70d所示的，图7示出了在广播调度流70中几次广播相同的BSM1消息，其描述为在BSP1周期内广播而调度的所有文件。在多个实施例中，可以配置文件传递系统，以使得广播调度周期(BSP)相对较短，并在广播调度流(BSF) 70内有规律地更新广播调度消息(BSM)。通过配置系统以使用短广播调度周期并有规律地更新广播调度消息，可以极大地提高文件传递系统的效率和灵活性，以及其管理不断更新的文件的能力。图7示出了有规律地更新包括在广播调度流(BSF)70内的广播调度消息(BSM)的实例。具体地，图7示出了 BSMJOd可以被更新到BSM270e，其对应于将在BSP2内广播的文 件。图7还示出了可以在两个BSP (例如，BSPJP BSP2)的边界更新的广播调度消息(例如，BSMl 和 BSM2)。应注意，图7示出了在用于单个文件的广播调度周期(BSP)中存在多个广播窗口的情形，例如针对fID_l所示的。当反复发送文件以提高文件发送的成功率时，如适用于高优先级文件的情况，可以使用用于单个文件的多个广播窗口。当文件很大以致于必须将其划分为多个分离的片段以便能够同时发送其它文件时，用于单个文件的多个广播窗口也是必要的。当存在用于单个文件的多个广播窗口时，这些多个广播窗口可以出现在同一广播调度周期内或者不同的广播调度周期内。图8示出了可以有规律地重复每一个广播调度消息(例如，BSM1和BSM2),例如在每一个超帧中，以便为广播调度周期内广播的多个文件提供广播窗口和接收信息。图8还示出了在文件传递管道数据流中发送的文件可以具有不同的广播持续时间，因为文件可以具有不同的大小。如上所述，BSM提供了用于公布发送调度的机制。BSM还可以向接收机设备提供附加信息的阵列。图9中示出了示例性BSM的高级格式。如图9所示，广播调度消息可以包括广播调度监视记录(BSMR)。广播调度监视记录可以包括下一个监视时间数据字段(Next_Monitor_Time)，其指定接收机设备应为更新的BSM而监视广播调度流的下一个时间。这个数据字段也可以定义下一个广播调度周期可以开始的时间。如以下更充分论述的，指定BSM将被更新的时间使得接收机设备能够通过当在广播调度流(BSF)70上传送冗余的BSM时停用其接收机电路，来保留电池功率。图9示出了 BSM还可以包括流广播调度记录(FBSR)。流广播调度记录可以描述用于当前广播调度周期(BSP)中在内容流(例如，在文件广播管道内)上广播的文件的广播调度。BSM可以包括多个流广播调度记录。每一个流广播调度记录都可以是类型一数值一长度(TLV)结构的形式，具有包括两个主要部分的数值部(即，记录数据)流广播调度记录报头(FBSR报头)；和流广播调度记录主体(FBSR主体)。流广播调度记录报头(FBSR报头)可以传送与传输流、频率、和/或广播系统有关的信息。流广播调度记录报头可以包括流ID和流数据速率。流ID可以是用于文件的发送的广播流的标识符。流数据速率可以是要发送根据流ID的在广播调度消息中描述的文件的数据速率。流广播调度记录主体(FBSR主体)可以传送一个或多个广播调度记录，如BSR1与BSR2K示的。每一个广播调度记录(BSR)可以提供与在给定广播调度周期(BSP)70内在内容流上广播的单个文件有关的广播信息。广播调度记录主体(BSR主体)可以包括广播数字记录类型(BSR_Type)、文件ID和/或元素ID (例如，File_ID)、调度信息和以类型-数值-长度编码来编码的一系列参数。广播数字记录类型(例如，BSR_Type)可以提供与被广播的文件的类型有关的信息，诸如单个文件、文件包等。文件ID和/或元素ID(例如，File_ID)可以标识被广播的文件内容。调度信息可以描述用于给定文件的广播窗口，并可以描述在整个广播调度周期中的许多个广播发送。广播窗口可以由广播窗口开始时间(BW_Start_Time)和广播持续时间(BW_Duration)来定义。广播窗口开始时间可以定义为文件的广播开始的时间。广播持续时间可以定义为将被广播的文件从广播窗口开始时间延续的时间长度。流广播调度记录主体可以进一步包括采用类型一数值一长度(TLV)编码的一系列 参数，其提供了 BSM传送额外信息的可扩展性，所述额外信息可以以有利于接收机设备进行过滤和选择的方式来进一步标识具有特定文件ID和/或元素ID的文件。以下说明了可以被包括在流广播调度记录主体中的三类参数。在第一类中(例如，类型=1)，可以包括前缀匹配字符串，其标识可能的多个文件或者目录名称，由文件ID和/或元素ID标识的文件内容可以与这些可能的文件或者目录名称相关联。例如，广播调度记录可以仅包括一个前缀匹配字符串，其中的数据是文件名称，诸如“/itv/res/svc_5/f 2. jpg”。作为另一个实例,广播调度记录可以包括多个前缀匹配字符串，其中，每一个TLV都具有不同的文件名称，例如在一个TLV中的“/itv/res/svc_5/f2. jpg”,在另一个 TLV 中的 “/itv/res/svc_15/f2. jpg”。该情形可以是交互性(itv)应用的情况，其在服务5 (例如，ESPN)和服务15 (例如，ESPN2)上使用用于交互性的同一文件“f2. jpg”，因此“f2. jpg”在“/itv/”文件目录结构中具有两个别名。在第三实例中，接收机设备可以接收关于按照单个捕获SingleCapture (/itv/res/svc_15/f2. jpg)或者全部捕获CaptureAll (/itv/res/svc_5/)形式来捕获文件的请求,在此情况下,接收设备可以以前缀匹配字符串LTV中的值执行双向前缀匹配。在第二类型中(例如，类型=2)，属性字符串可以提供多个属性(例如，性别=男；年龄=20 - 30等)，其表征由文件ID和/或元素ID标识的文件内容，或者文件内容所适合的应用或接收机设备。在此情况下，使用属性字符串的接收机设备将已经接收到关于捕获匹配多个属性上的逻辑表述的文件的请求，诸如CaptureAll (性别=男&&年龄=20 一30)，其中，&&表示逻辑“与(AND)”运算。在第三类型中(例如，类型=3)，为文件提供应用或服务专用标识符(例如，itv: 123，或者svc_3:2234等)，其标识在给定的应用或服务的范围中的文件ID和/或元素ID。使用应用或服务标识符的接收机设备会使用目录文件来描述可用文件、相关属性和用于文件的相应应用或服务标识符。应用或服务于是可以请求按照单个捕获来捕获感兴趣文件，诸如 SingleCapture (itv: 123)。图10示出了用于另一个示例性广播调度消息的高级格式。如图10所示的，BSM可以包含多个广播调度信息记录(BSIR1到BSIRm)。每一个广播调度信息记录都可以包含与一个或多个流上的广播调度有关的信息。每一个广播调度信息记录也可以包含监视调度，其可以由接收机设备用来接收更新后的广播调度。如图10所示，每一个广播调度信息记录(例如，BSIR1到BSIRm)可以具有报头部(BSIR报头)和主体部(BSIR主体)。报头部可以包括下一监视时间(例如，Next_Monitor_Time)字段和监视周期(例如，Monit0ring_Peri0d)字段。在多个实施例中，报头部中的字段(例如，Next_Monitor_Time> Monitoring_Period等)可以用于允许文件传递架构(FDF)在不同等待时间的情况下传递数据。在多个实施例中，一个监视周期内的所有广播调度信息记录(BSIR)都可以以降序排列，以使得接收机设备仅处理第一个广播调度信息记录。在多个实施例中，广播调度信息记录可以被配置为，仅当确定系统不支持初始获取流(IAF)系统时才包括下一监视时间(例如，Next_Monitor_Time)字段。在多个实施例中，广播调度信息记录的主体部((BSIR主体)可以包括多个流广播调度记录(FBSR1到FBSRn)。流广播调度记录是用于描述在广播调度周期(BSP)内的流上广播的元素的广播调度的文件传递数据流记录。每一个流广播调度记录都可以具有类型一数·值一长度(TLV)结构，其中，数值部分包括报头部(FBSR报头)和主体部(FBSR主体)。流广播调度记录的报头部可以包含与数据流有关的信息，诸如流ID、数据速率等。流广播调度记录的主体部可以包含一个或多个广播调度记录(BSR1到BSRn)。在多个实施例中，流广播调度记录的主体部可以包含用于在广播调度周期(BSP)内的流上广播的每一个元素的广播调度记录。在多个实施例中，每一个广播调度记录都可以具有用于每一个元素(即，在数据流上广播的数据单元)的元素ID (Element_ID)、用于元素中的一个(或多个)文件的一个或多个文件/目录名称、和广播调度信息。在一个实施例中，文件和目录名称可以遵循基于UNIX的文件命名规范。在一个实施例中，由元素ID (例如，Element_ID)表示的元素可以对应于文件的特定版本或者由多个文件组成的文件包的特定版本。在多个实施例中，同一文件或文件包的不同版本可以对应于不同元素。在多个实施例中，元素ID可以是由文件传递架构(FDF)分配给每一个元素的全局唯一 ID。图11示出了用于使用BSM的下一监视时间数据字段的实施例方法。如上所述，BSM可以包括下一监视时间数据字段(例如，图10中的Next_Monitor_Time字段),其指定接收机设备应为更新的BSM而监视广播调度流的下一个时间。图11示出了如何可以使用第一BSM (BSM1)的下一监视时间数据字段来更新下一个广播调度周期(下一 BSP)的广播调度流(BSF) 70中的第二 BSM (BSM2)0图11示出了，当接收机设备接收到BSM (例如，BSM1)时，接收机可以根据BSM1中的下一个监视时间调度下一个唤醒时间来监视广播调度流(BSF)。图12是用于处理广播调度消息的实施例方法1200。图12示出了，在确定步骤1201中，接收机设备可以首先确定接收的BSM是否具有与先前处理的广播调度消息相同的版本属性。如果版本相同(即，确定步骤1201 =“是”)，则接收机设备就可以进行确定步骤1216。如果版本不同(即，确定步骤1201 =“否”)，则在步骤1202中，接收机设备可以删除先前的BSM，并保存新接收的BSM。保存新的BSM是必要的，因为每一次文件传递架构(FDF)从应用接收对于捕获文件的请求时，它就应使用在该请求中的新信息来再次处理所保存的BSM。在确定步骤1204中，接收机设备可以尝试从广播调度消息中读取广播调度消息记录。如果成功(即，确定步骤1204 =“是”)，则在确定步骤1206中，接收机设备可以处理BSM中的记录(例如，BSMR、FBSR),并确定记录是否是广播调度监视记录(BSMR)。如果记录是广播调度监视记录(即，确定步骤1206 =“是”)，则在步骤1208中，设备可以使用广播调度监视记录中的下一监视时间字段(例如，NEXT_MONITORING_TIME)作为新的下一监视时间。如果记录不是广播调度监视记录(即，确定步骤1206 = “否”)，则在确定步骤1212中，接收机设备可以确定记录是否是流广播调度记录(FBSR)。如果记录不是流广播调度记录(即，确定步骤1212 =“否”)，则接收机设备就返回确定步骤1204，来读取新的广播调度消息记录。如果记录是流广播调度记录(即，确定步骤1212 =“是”)，则在步骤1214中，设备可以处理流广播调度记录，并做出数据过滤决策，并随后返回确定步骤1204，以读取新的广播调度消息记录。如果在确定步骤1204中，接收机设备从BSM读取广播调度消息记录失败(S卩，确定步骤1204 = “否”)，则在步骤1210中，接收机设备取消新BSM中没有指定的先前所调度的下载，并进行确定步骤1216。在多个实施例中，文件传递核心(FDC)可以取消新BSM中没有指定的先前所调度的下载。在多个实施例中，广播服务器可以使用这个特征，通过发送更新的BSM来取消广播元素。以下参考图19更详细地论述文件传递核心。 返回图12，在处理了广播调度消息中的全部字段后或者在接收先前处理的BSM(即，确定步骤1201 =“是”)后，在确定步骤1216中，接收机设备可以检查下一监视时间(例如，NEXT_M0NIT0RING_TIME)是否晚于当前时间一以及在当前时间与下一监视时间之间的差是否不大于由设备配置参数所指定的一个时间段(例如，MAX_BSF_M0NIT0RING_PERI0D)o如果下一监视时间不晚于当前时间(即，确定步骤1216 =“否”)，则该过程结束，并且设备可以停止监视广播调度流，并等待接收下一个更新的BSM。如果下一个监视时间晚于当前时间，并且在当前时间与下一个监视时间之间的差不大于所指定的时间段(即，确定步骤1216=“是”)，则在步骤1218中，接收机设备可以注销该广播调度流(即，停止接收当前广播调度流)并调度在下一个监视时间接收广播调度流。否则，设备可以继续接收该广播调度流。图13示出了用于在广播调度流(BSF)70上实现更新检测的实施例方法1300。图13示出了，在确定步骤1301中，设备可以首先检查接收的广播调度消息(BSM)中第一个广播调度信息记录(BSIR)的版本是否与先前处理的广播调度信息记录的版本相同。如果版本相同(即，确定步骤1301 =“是”)，它就可以进行确定步骤1310。如果版本不同(即，确定步骤1301=“否”)，则在步骤1302中，接收机可以删除先前保存的广播调度信息记录，并保存新的广播调度信息记录。保存新的广播调度信息记录允许在每一次文件传递架构(FDF)从应用接收到新文件捕获请求时，文件传递架构使用在请求中的新信息来再次处理所保存的广播调度信息记录。在步骤1304中，设备可以使用广播调度信息记录中的下一监视时间字段(例如，NEXT_M0NIT0RING_HME)作为新的下一监视时间。在步骤1306中，接收机设备可以处理广播调度信息记录中的所有流广播调度记录(FBSR)。在多个实施例中，设备可以使用对流广播调度记录的处理来做出数据过滤决策。在步骤1308中，文件传递核心(FDC)可以取消在新广播调度信息记录中没有指定的先前所调度的下载。在多个实施例中，广播服务器可以使用这个特征，通过发送更新的广播调度消息来取消元素广播。在处理了广播调度信息记录(BSIR)中的所有字段后，在确定步骤1310中，接收机设备可以检查下一监视时间是否晚于当前时间一及在当前时间与下一监视时间之间的差是否不大于某个设备配置参数(例如，MAX_BSF_M0NIT0RING_PERI0D)o在多个实施例中，如果下一监视时间不晚于当前时间(即，确定步骤1310 =“否”)，则设备可以停止监视广播调度流70。如果下一个监视时间晚于当前时间，并且在当前时间与下一个监视时间之间的差不大于设备配置参数(MAX_BSF_MONITORING_PERIOD)(即，确定步骤1310 =“是”)，则在步骤1312中，接收机设备可以注销该广播调度流(即，停止接收BSF)并调度在下一个监视时间接收广播调度流70。否则，设备可以继续接收该广播调度流70。在以上参考图12和13说明的实施例方法中，如果接收机设备在所指定的监视时间在流覆盖之外，则设备会不知道应何时再次唤醒来接收广播调度流70。这是图14中示出的情况，其显示了接收机设备可以在多个时刻在覆盖区域以外。图14是示出接收机设备如何可以在与广播调度流发送的时序相关的多个时刻在广播网络的和/或广播流的覆盖区域以外(1401，1402)的时间线图。在这种情况下，接收机设备可以在下一个指定监视时间前再次进入覆盖区域，如由块1401所示的。在其他时间，接收机设备可以不再次进入覆盖区域，直到已经经过了所指定的下一个监视时间，如由 块1402所示的。图14示出了，在多个实施例中，接收机设备可以在脱离流覆盖区域后的每一次它再次进入流覆盖时接收广播调度流70。在一些实施例中，接收机设备可以基于对接收机设备在所指定的监视时间在流覆盖以外的确定，来做出关于接收机设备是否应接收广播调度流70的独立决定。在多个实施例中，当接收机设备返回到流覆盖区域时，可以强制接收机设备接收广播调度流70 (示出为“强制接收BSF”)。在其他实施例中，接收机设备可以被配置为，每一次服务核心开启就接收广播调度流70。在其他实施例中，接收机设备可以确定所指定的下一个监视时间是否已经经过，并在必要时做出调整，以确保接收机设备接收到广播调度流的最新版本。图15示出了用于在支持初始获取流(IAF)的系统上检测对广播调度流(BSF) 70的更新的实施例方法。具体地，图15示出了用于基于初始获取流检测广播调度流70的更新的时间线。在多个实施例中，对广播调度流70上的广播调度消息(BSM)的更新的检测可以基于在初始获取流上的目录信息消息(DM)消息的内容。在多个实施例中，接收机设备可以根据在先前的目录信息消息中指定的下一监视时间值(例如，NEXT_M0NIT0RING_HME)周期性地唤醒。在多个实施例中，接收机设备可以从初始获取流接收最新的目录信息消息，并将广播调度消息版本信息(例如，BSM_VERSI0N)与最新的未到期的处理过的广播调度消息的版本信息相比较。在这些实施例中，如果比较的版本不同，则接收机设备可以确定存在对广播调度消息的更新，并启动接收机设备中的接收机电路，以接收广播调度流70上的更新的广播调度消息。在多个实施例中，接收机设备可以使用公共开销流接收机制来接收更新的广播调度消息。在多个实施例中，接收机设备上的文件传递架构(FDF)可以设定广播调度消息设备参数(例如，FDF_BSM_EXPIRY_TIME),以指示广播调度消息已经到期，在该广播调度消息被处理后经历的秒数。在这些实施例中，通过指示广播调度消息已经到期，接收机设备可以应对设备在一个时间段内在流覆盖以外并且具有陈旧的广播调度消息的情况。在多个实施例中，只要接收机设备检测到其具有陈旧的广播调度消息时，接收机设备就可以启动接收机电路以接收新的广播调度消息。图16是示出用于在同一超帧内接收两个不同版本的广播调度消息(例如，BSM1,BSM2)的实施例方法的时间线图。如上所述，在多个实施例中，可以在被组织到多个超帧中的无线信号中发送信息。每一个超帧都可以包括在频带内和在设定时间边界内的信号，其包括传送广播内容的多个数据分组。图16示出了可以在单个超帧的设定时间边界内接收两个不同版本的广播调度消息(BSM1、BSM2)。图17示出了用于在来自初始获取流(IAF)系统的支持下处理广播调度消息(BSM)的实施例方法1700。在确定步骤1701中，接收机设备可以确定广播调度消息中的版本参数(例如，BSM_VERSI0N)与目录信息消息(DM)中指示的版本参数是否相同。如果版本不同(即，确定步骤1701 =“否”)，则设备可以忽略接收的广播调度消息并结束处理。在多个实施例中，这是必要的，因为设备可以在图16所示的超帧内接收到相同广播调度消息的多个版本。在这种情况下，设备可以仅处理由目录信息消息指示的最新的版本(例如，BSM2)。在多个实施例中，服务器可以通过在初始获取流的下一监视时间之前的数秒(或者微秒)广播更新的广播调度消息来避免在同一超帧内的多个版本的广播调度消息。返回图17，如果确定版本参数相同(S卩，确定步骤1701 = “是”)，则在步骤1702中， 接收机设备可以删除先前保存的广播调度消息，并保存新的广播调度消息。在多个实施例中，保存新的广播调度消息是重要的，因为每一次文件传递架构从应用接收到对于捕获文件的请求时，它就可以使用请求中的新信息来再次处理所保存的广播调度消息。在确定步骤1704中，接收机设备可以尝试从广播调度消息中读取广播调度消息记录(BSMR)。如果BSMR读取成功(B卩，确定步骤1704 =“是”)，则在确定步骤1706中，接收机设备可以处理所接收的广播调度消息中的记录(例如，BSMR)，并确定记录是否是流广播调度记录(FBSR)。如果是(即，确定步骤1706 = “是”)，则在步骤1708中，接收机设备可以处理流广播调度记录，并做出数据过滤决策。这个处理可以通过返回到确定步骤1704而重复，直到已经处理了广播调度消息中的所有字段，其将由失败的BSMR读取尝试来确定。如果在确定步骤1704中接收机设备不能成功地读取广播调度消息(即，确定步骤1704 =“否”)，则文件传递核心(FDC)可以在步骤1710中取消在新的广播调度消息中没有指定的先前所调度的下载。图18是示出用于控制在接收机设备与广播服务器之间的更新的广播调度消息(BSM)的广播的时序的实施例方法的时间线图。图18示出了，在多个实施例中，广播服务器可以将下一监视字段设备配置参数(例如，NextMonitoring Time (下一监视时间))设定为在广播调度周期(BSP)开始时间之前的一个可变的秒数(例如，BSF_M0NIT0RING_ADVANCE_TIME)。这可以允许接收机设备有足够的时间来检测广播调度消息的更新，并在相应的广播调度周期的开始之前接收更新的广播调度消息。图18还示出了，在多个实施例中，服务器可以使用用于指示从服务器到设备的延迟的最大网络延迟设备配置参数(例如，Max Network Delay (最大网络延迟)),来为服务器确定开始时间，以开始发送更新的广播调度消息。在多个实施例中，服务器可以将局域广播调度消息和广域广播调度消息中的下一监视时间设定为相同值。这允许设备节能。由于接收机设备可以在多路复用(例如，一个广播区域到另一个广播区域)之间移动，接收机设备可以在每一次接收机移动到新的多路复用时，接收新的多路复用上的广播调度流(BSF) 70。如果下一监视时间晚于当前时间不超过数秒(例如，MAX_BSF_M0NIT0RING_PERIOD)，接收机设备就可以在处理了接收的广播调度消息中的字段后注销广播调度流70。在处理了接收的广播调度消息中的字段后，在下一监视时间不晚于当前时间的条件下，接收机设备可以继续接收广播调度流70。在处理了接收的广播调度消息中的字段后，如果下一监视时间晚于当前时间超过数秒(例如，MAX_BSF_MONITORING_PERIOD),则设备可以继续接收广播调度流70。接收机设备可以在下一监视时间调度接收广播调度流(BSF)70。如果在广播调度流的监视时间设备在流覆盖以外，则设备可以在其再次进入流覆盖区域时接收广播调度流70。只要接收机设备上的文件传递架构(FDF)开始，接收机设备就可以接收广播调度流70。在已经处理了广播调度消息(BSM)数秒(例如，FDF_BSM_EXPIRY_TIME)后，设备上的文件传递架构可以使广播调度消息(BSM)到期。如果在最新的广播调度消息中不再指定某个先前所调度的下载，则设备上的文件传递架构可以取消该先前所调度的下载。服务器可以将局域和广域广播调度消息中的下一监视时间设定为相同值。服务器可以将用于广播调度流70的下一监视时间设定为相应广播调度周期开始时间之前数秒(例如，BSF. MONITORING,ADVANCE_TIME)0当用于从初始获取流(IAF)接收的目录信息消息(DIM)中的给定的多路复用的广播调度消息的版本(例如，BSM_VERSI0N)与用于设备已经处理的同一多路复用的最新的广播调度消息的版本不同时，接收机设备可以接收广播调度流70上的更新的广播调度消息。
在多个实施例中，服务器可以将初始获取流(IAF)的下一监视时间设定为在下一广播调度周期(BSP)的开始时间之前数秒(例如，BSF_MONITORING_ADVANCE_TIME) 服务器可以在提升下一监视时间在目录信息消息(DIM)中的更新的广播调度消息的版本标识符(例如，BSM_VERSI0N)之前，广播该更新的广播调度消息。如果在广播调度流70上接收的广播调度消息的版本标识符(例如，BSM_VERSI0N)等于在最新的目录信息消息中同一广播调度流70的版本标识符，则接收机设备就可以处理该在广播调度流70上接收的广播调度消息。如果在广播调度流70上接收的广播调度消息的BSM_VERSI0N等于在最新的目录信息消息中同一广播调度流70的BSM_VERSI0N，则设备就可以保存该在广播调度流70上接收的广播调度消息。当设备移动到新的多路复用时，其可以在该新的多路复用上接收广播调度流70。图19示出了在接收机设备上的文件传递架构(FDF)的软件体系结构。具体地，图19示出了文件传递架构可以包括文件传递核心(FDC)层和文件传递文件管理(FDM)层。文件传递核心可以负责传输数据(例如，处理BSF)、从数据流接收数据、和对所接收的数据执行各种其他功能(例如，FEC解码)。文件传递文件管理层可以负责将由文件传递核心层接收的数据作为文件来管理。由于文件管理依赖于设备平台(例如，Linux和WindowsMobile具有不同的文件名称规范)，因此在多个实施例中，每一个应用都可以是其自身的文件传递文件管理层的实例。这允许文件传递核心在其上运行的通用移动接收机(UMR)设备与不同类型的设备上的应用合作。图20示出了用于实现支持在不同应用之间的文件共享的文件传递架构的实施例方法2000。图20示出了，在步骤2002中，应用可以向文件传递文件管理层发出关于捕获文件或目录的请求。这个捕获请求可以是“捕获一次”请求或者“自动捕获”请求。在步骤2004中，文件传递文件管理层向文件传递核心传送文件和目录名称，在此，文件传递核心在表中将它们存储为“期望字符串(wanted string)”。在步骤2006中，文件传递核心可以从具有一个或多个广播调度记录(BSR)的广播调度流(BSF)接收更新的广播调度消息(BSM)，对于相应的广播调度周期(BSP)中广播的每一个元素有一个广播调度记录。在步骤2008中，文件传递核心针对每一个广播调度记录，比较广播调度记录中的文件/目录名称与期望字符串。如果存在匹配，则在步骤2010中，文件传递核心可以向文件传递文件管理(FDM)层进行检查，以了解设备是否具有由匹配的广播调度记录中的元素ID所标识的元素。如果没有，则在步骤2014中，文件传递核心(FDC)可以根据匹配的广播调度记录(BSR)中的广播调度信息来调度接收该元素。在步骤2016中，文件传递核心可以在所调度的时间接收用于期望元素的一个或多个文件传递协议(FDP)和/或文件传递控制协议(FDCP)消息，并执行前向纠错(FEC)解码以恢复元素数据。在步骤2018中，文件传递核心可以向文件传递文件管理层转发接收到的元素。在步骤2020中，文件传递文件管理层可以根据应用的存储策略，在应用的存储空间中保存所述元素(以文件形式)。在多个实施例中，文件传递文件管理层还可以维护几条额外信息，诸如存储元素的存储位置和元素的ID。在步骤2022中，文传递文件管理可以向应用通知已经为其接收到文件。图21 — 23是示出接收机设备上的文件传递架构(FDF)的结构和数据流的软件体系结构图。图21示出了可以由架构用于管理在不同层之间的交互并保持追踪和维护“期望字符串”表的结构、数据流和高级步骤。具体地，图21示出了在文件传递文件管理(FDM)·层与文件传递核心(FDC)层之间的实施例功能分割，其中，文件传递文件管理层向文件传递核心层传送应用请求。例如，图20示出了应用可以向文件传递文件管理层发出关于捕获文件一次或者自动捕获文件或目录的请求(箭头2101)。这个请求2101对应于以上参考图20所述的步骤2002。在图21所示的实施例中，文件和目标可以由其名称来指定。在其他实施例中，可以通过使用各种命名和/或标识规范来指定文件和目录，以下论述其一些实例。参考图21，一旦请求由应用发出，文件传递架构(FDF)就可以维护被请求捕获一次的文件或目录的名称(例如，借助Capture_0nce命令),直到成功接收到该目录中的文件或一些文件为止。文件传递架构还可以维护应用请求自动捕获的(例如,借助Auto_Capture命令)文件或目录的名称，直到应用取消该请求为止。文件传递文件管理层可以向文件传递核心传送(箭头2102)文件和目录名称。文件传递核心可以在表中将文件和目录名称存储为“期望字符串”。图22示出了在接收机设备上的文件传递架构(FDF)的结构和数据流，以及文件传递架构选择接收文件的决策过程。例如，文件传递核心(FDC)层可以从广播调度流(BSF)接收(箭头2201)更新的广播调度消息(BSM)。广播调度消息可以具有一个或多个广播调度记录(BSRp BSR2),对于相应广播调度周期(BSP)中广播的每一个元素有一个广播调度记录。广播调度记录可以包含用于相应元素的元素ID、用于元素中文件的一个或多个文件/目录名称、和广播调度信息。文件传递核心可以针对每一个广播调度记录比较(箭头2202)广播调度记录中的文件/目录名称与期望字符串。如果存在匹配，则文件传递核心可以向文件传递文件管理层进行检查(箭头2203)，以了解设备是否已经具有由匹配的广播调度记录中的元素ID所标识的元素。如果没有，则文件传递核心可以根据匹配的广播调度记录中的广播调度信息来调度接收所述元素。应注意，在多个实施例中，不同版本的文件可以具有不同的元素ID。还应注意，在多个实施例中，可以使用基于元素ID的过滤来使得文件传递架构能够接收对已经存在于设备上的文件的更新，如以下更详细论述的。图22还示出了，在多个实施例中，文件传递文件管理(FDM)层可以维护受管理元素表(MET)。受管理元素表可以包含与文件传递架构所接收的所有元素有关的信息。在多个实施例中，受管理元素表还可以包含多条额外信息，诸如元素ID、文件名称、别名(在元素可以具有多个文件名称的实施例中)、存储名称及其它属性。以下参考图40和57更详细的论述受管理元素表。返回图22，在多个实施例中，文件传递文件管理(FDM)层可以维护期望字符串表(例如，期望字符串)。期望字符串表可以包括多条信息，诸如应用请求的文件或目录名称(例如，字符串)。期望字符串表还可以包括请求句柄(request handle)(例如,Req Inst(请求实例))，其唯一地标识来自应用的请求。在多个实施例中，在文件传递核心接收与特定请求匹配的元素时，文件传递核心可以使用请求句柄来识别应被告知的文件传递文件管理层实例。图22还示出了文件传递核心(FDC)可以接收广播调度流(BSF)上的更新的广播调度消息(BSM)。文件传递核心还可以具有数据过滤单元2210，其选择性地仅接收应用感兴趣的元素。就是说，按照广播调度消息所确定的，数据过滤单元2210可以负责选择性接收 应用已经登记要接收的元素。在多个实施例中，数据过滤单元可以处理最新的广播调度消息中的流广播调度记录(FBSR)，以确定是否将广播应用感兴趣的任何元素。在多个实施例中，数据过滤单元可以使用流广播调度记录以及包含在广播调度消息中的广播调度信息，来调度接收机设备下载应用感兴趣的元素。在多个实施例中，文件传递核心可以使用这个调度在所调度的时间唤醒接收机电路，以接收应用感兴趣的元素。图23示出了接收机设备上的文件传递架构(FDF)的示例性结构和数据流，以及接收机设备上的文件传递架构借以可以接收并存储文件的过程。在所示实例中，文件传递核心(FDC)在所调度的时间接收用于期望元素的FDP/FDCP消息(箭头2301)，并将其存储在暂存空间2310中。在一些实施例中，文件传递核心还可以对FDP/FDCP消息(分别传送FEC编码符号和FEC编码信息)执行前向纠错解码，以恢复元素数据。文件传递核心可以向文件传递文件管理(FDM)层转发(箭头2302)接收到的元素。根据应用的存储策略，文件传递文件管理层可以在应用的存储空间2315中以文件形式保存元素(箭头2303)。在多个实施例中，文件传递文件管理层还可以维护多条信息，诸如存储元素的位置(Storage)和元素的ID (EID)0在将元素保存在应用的存储空间中后，文件传递文件管理层可以向应用通知(箭头2304)已经为应用接收到文件。图24示出了用于在文件传递核心中实现数据过滤单元2210，以选择性地仅接收应用感兴趣的元素的实施例方法2400，其中基于广播调度消息中的信息来决定接收。在步骤2402中，数据过滤单元2210处理流广播调度记录(FBSR)报头，以确定广播调度记录(BSR)的名称或特性。在确定步骤2404中，数据过滤单元2210可以确定在所接收的广播调度消息中是否存在任何未处理的感兴趣广播调度记录(即，记录满足由发出请求的应用所指定的命名规范或选择标准)。如果没有(即，确定步骤2404 =“否”)，则数据过滤单元2210就可以关闭。然而，如果存在未处理的感兴趣广播调度记录(即，确定步骤2404 =“是”)，则在步骤2406中，数据过滤单元2210可以从流广播调度记录主体(例如，FBSR主体)中读取未处理的广播调度记录。在步骤2408中，数据过滤单元2210可以处理广播调度记录，并返回确定步骤2404，以确定是否已经处理了感兴趣的所有流广播调度记录。这个过程可以继续，直到已经处理感兴趣的所有流广播调度记录(即，确定步骤2404 = “否”)。
图25示出了用于处理流广播调度记录中的广播调度记录的实施例方法2500。在确定步骤2502中，文件传递核心的数据过滤单元2210确定在广播调度记录中是否存在任何未处理的字段。如果有(即，确定步骤2502 =“是”)，则文件传递核心确定它是否应接收由广播调度记录所描述的元素。在多个实施例，文件传递核心可以在以下情况下决定接收元素相应广播调度记录具有至少一个与期望字符串双向令牌前缀匹配(two-ways-token-prefix-match)的属性字符串；元素没有存在于文件传递核心的暂存空间中；及元素没有存在于应用的存储空间中。以下更详细地论述文件传递核心借以决定接收元素的过程。返回图25，确定是否应接收元素可以在步骤2504以数据过滤单元2210从未处理的广播调度记录中读取感兴趣的字段开始。在确定步骤2506中，数据过滤单元2210可以确定感兴趣的字段或者元素是否是前缀匹配字段。如果元素不是前缀匹配字段(即，确定步骤2506 = “否”)，则数据过滤单元2210就可以返回到确定步骤2502，以确定广播调度记录中是否存在任何未处理的字段。然而，如果感兴趣的字段是前缀匹配字段(即，确定步骤2506=“是”)，则在确定步骤2510中，数据过滤单元2210可以确定元素是否与期望字符串“双向令牌前缀匹配”。 在多个实施例中，只要字符串Si是字符串s2的令牌前缀(token-prefix)，或者字符串s2是字符串Si的令牌前缀，字符串Si就与字符串s2 “双向令牌前缀匹配”。在多个实施例中，文件传递架构中的令牌前缀匹配可以基于被定义为文件中的组件的令牌，或者基于被定义为由斜线“/”标点符号分割的目录名称的令牌。例如，在此类实施例中，将确定文件名称“/cnn/tech/fl. mp4”具有三个令牌cnn ；tech ;和fl.mp4。因此,如果以下任意条件为真，则文件传递架构可以考虑字符串si是字符串s2的如缀sl具有令牌tl、l、tl、
2、…、K ；s2具有令牌t2、l、t2、2、t2、3、…、L ；k小于或等于L ;tl、j等于t2、j，其中，j =I、2、…、K。在这些实施例中，如果广播调度记录指示针对“/cnn/tech/”广播文件，且应用期望在“/cnn/”下的任何文件一则文件传递核心应接收针对/cnn/tech/广播的文件。类似地，如果广播调度记录指示针对“/cnn”广播文件，且应用期望在“/cnn/tech/”下的任何文件，那么文件传递核心就应接收针对/cnn广播的文件，以便避免遗漏可能在“/cnntech/”下的任何文件。在一个实施例中，所有字符串匹配可以是区分大小写的。在一个实施例中，文件传递核心可以应用相同的字符串匹配算法，而不用考虑广播调度记录是用于文件还是用于文件包的。返回图25，如果与期望字符串双向前缀匹配(B卩，确定步骤2510 =“是”)，则流就可以进行确定步骤2512，在确定步骤2512中，数据过滤单元2210可以确定文件传递文件管理(FDM)层是否已经包含所述元素。如果是(即，确定步骤2512=“是”)，则处理停止。如果文件传递文件管理层没有包含所述元素(即，确定步骤2512 = “否”)，如果还没有调度接收相应的元素，则数据过滤单元2210就可以在步骤2514中调度接收相应的元素。在多个实施例中，可以按照流ID (例如，FL0ff_ID)上的广播调度记录(例如，BCAST_SCHEDULE_RECORD)来调度相应的元素。在步骤2516中，数据过滤单元2210可以处理广播调度记录中的其它字段。图26示出了接收机设备上的文件传递架构(FDF)的结构和数据流，以及用来处理广播调度记录的过程。如上所述，如果相应广播调度记录(BSR)具有与期望字符串双向令牌前缀匹配的至少一个属性字符串，并且元素没有存在于文件传递核心的暂存空间中，则文件传递核心(FDC)可以接收所述元素。箭头2601示出了文件传递核心的数据过滤单元2210借以从未处理的广播调度记录中读取元素，确定元素是否是前缀匹配字段，及确定元素是否与期望字符串双向令牌前缀匹配的数据流和过程。箭头2602示出了文件传递核心的数据过滤单元2210借以确定文件传递文件管理(FDM)层是否已经包含所述元素的数据流和过程。如果文件传递文件管理层未包含所述元素，如果尚未调度接收相应的元素，则文件传递核心就可以调度接收相应的元素。如果决定接收所述元素，则文件传递核心中的调度器2605就可以调度在广播调度记录中所指定的广播窗口接收元素。在多个实施例中，如果广播调度记录具有与应用所请求的文件或目录名称双向令牌前缀匹配的至少一个属性字符串，且元素没有存在于设备上，则接收机设备上的文件传递架构可以调度接收由广播调度记录描述的元素。图27是示出在广播文件的时间期间中断文件的接收的情况的时间线图。在多个实施例中，通过在暂存空间2310中存储部分文件，文传递核心可以等待文件传送恢复，并做出与对下载的文件应用前向纠错码的可行性有关的第二决定。
图28示出了下载的数据2805如何可以被传送并存储到暂存空间存储器2310中。如上所述，文件传递核心可以具有暂存空间存储器2310，用于在对下载的文件应用前向纠错(FEC)解码前存储下载的文件，以及用于保存解码的文件。在多个实施例中，文件传递核心在暂存空间2310中存储未完成的下载、完成但未解码的下载、和解码的下载。在各种情况下，暂存空间2310都可以存储未完成的下载。例如，下载的数据存储在暂存空间中用于前向纠错解码(即，下载未完成)。在多个实施例中，可以将下载的数据保存在暂存空间2310中，直到广播结束，这可以适应图27所示的中断数据接收的情况。如上所述，暂存空间2310也可以存储完成但未解码的下载。就是说，在多个情况下，下载可以具有足以用于成功的前向纠错(FEC)解码的数据，但前向纠错解码尚未完成(即，下载完成，但未解码)。在这些情况下，文件传递核心可以在暂存空间中存储这些文件，直到其能够被解码。在一些实施例中，为了限制处理器的使用，前向纠错解码器可以一次解码一个文件。在一些实施例中，可以避免前向纠错解码器在设备正在下载文件传递数据时解码文件。在一些实施例中，暂存空间2310可以存储尚未传递给发出请求的应用的已解码的下载。在一个实施例中，暂存空间2310可以位于接收设备的内部存储器上。在其它实施例中，接收机设备可以具有在内部和外部存储器二者上的暂存空间2310。在这些实施例中，文件传递架构应用可以具有内部存储器存储策略以及外部存储器存储策略。在多个实施例中，文件传递核心可以将内部暂存空间用于使用内部存储器存储策略的那些应用，并将外部暂存空间用于使用外部存储器存储策略的那些应用。在多个实施例中，暂存空间管理策略可以包括用于在多个存储位置中移动数据的策略和功能。暂存空间管理策略可以包括用以将成功解码的元素从暂存空间2310移动到应用存储空间的功能。暂存空间管理策略可以包括用以周期性删除暂存空间2310上的无用数据的功能。暂存空间管理策略可以包括用以当暂存空间2310用完或者即将用完空间时删除暂存空间2310上的数据的功能。设备上的文件传递架构可以将内部存储器或外部存储器中的暂存空间2310用于多个应用。设备上的文件传递架构可以将内部存储器中的暂存空间2310用于使用内部存储器存储策略的应用。设备上的文件传递架构可以将外部存储器中的暂存空间2310用于使用外部存储器存储策略的应用。设备上的文件传递架构可以以内部和外部存储器与存储策略的任意组合来使用暂存空间2310。图29示出了用于处理和存储元素的实施例方法2900。在步骤2902中，文件传递核心成功地前向纠错(FEC)解码对应于单个文件的元素。在步骤2904中，文件传递核心可以向文件传递文件管理(FDM)层通知已经接收到元素。在步骤2906中，文件传递文件管理层可以为元素中的文件确定存储位置。在步骤2908中，文件传递文件管理层可以指导文件传递核心将元素从暂存空间2310移动到所述存储位置。在步骤2910中，如果应用的存储空间中有足够的空间，则设备上的文件传递架构可以在为应用成功接收到元素后，将元素移动到应用的存储空间2310。在多个实施例中，文件传递核心可以周期性删除暂存空间上的无用数据。在多个实施例中，文件传递核心可以通过删除未完成下载中的数据来周期性地清理暂存空间，所述未完成下载的广播已经结束，且没有用于它们的单播回退(fallback)机制。在多个实施例中，文件传递核心可以通过删除不能被移动到应用存储空间且在暂存空间中已经存在了·设备配置参数所指示的数秒(例如，FDF_MAX_ELEMENT_HME_IN_SCRATCH_SPACE)的、成功解码的元素中的数据，来周期性地清理暂存空间。在多个实施例中，清理周期可以由诸如FDF_SCRATCH_SPACE_CLEAN_UP_PERIOD的设备配置参数来控制。在多个实施例中，周期性暂存空间清理机制可以将暂存空间的占用面积保持较小。在一个实施例中，文件传递架构每隔几(例如，FDF_SCRATCH_SPACE_CLEAN_UP_PERIOD)秒就删除一次未完成的下载数据(数据不足以成功地进行FEC解码)，所述未完成的下载数据的广播已经结束且没有用于它们的单播回退。在一个实施例中，文件传递架构删除大于一个可变数量的数秒(例如，DF_MAX_ELEMENT_TIME_IN_SCRATCH_SPACE秒)之前成功解码的、并且不能被移动到应用存储空间的数据。在多个实施例中，如果暂存空间大小达到上限阈值，则文件传递核心就可以确定其已经用完了暂存空间。如果暂存空间所在的存储空间满了，则文件传递核心也可以确定其已经用完了暂存空间。在一个实施例中，内部暂存空间上限可以由原始设备制造商(OEM)配置设备参数(例如，FDF_MAX_INTERNAL_SCRATCH_SPACE_SIZE)指定。如果不存在OEM配置设备参数(例如，FDF_MAX_INTERNAL_SCRATCH_SPACE_SIZE)，接收机设备就可以使用该参数的缺省值作为内部暂存空间上限。在多个实施例中，外部暂存空间上限可以由设备调试参数来指定，诸如 FDF_MAX_EXTERNAL_SCRATCH_SPACE_SIZE。图30示出了用于选择用以从暂存空间存储器中删除的项目的实施例方法3000。在多个实施例中，文件传递核心使用一系列规则来确定何时需要将数据从暂存空间中删除和应删除哪一个数据。例如，文件传递核心可以使用多个有优先顺序的规则(例如，规则I和规则2)以确定应删除那一个数据，其中，以优先级的顺序来实施所述规则(例如，规则I具有比规则2更高的优先级)。例如，第一规则(规则I)可以是解码的元素具有最高优先级，而第二规则(规则2)可以是完成的下载具有高于未完成的下载的优先级。在多个实施例中，文件传递核心可以维护一个经排序的列表，其具有用于暂存空间中每一个数据段的条目。在多个实施例中，文件传递核心可以使用有优先顺序的规则(例如，规则I和规则2)来对列表进行排序，诸如图30所示。在图30的步骤3002中，文件传递核心可以应用第一规则(规则I)来对列表进行排序。在步骤3004中，文件传递核心可以产生几个级I存储块(bucket)，以使得相同级(例如，级I)的存储块中的条目具有按照第一规则(例如，规则I)的相同顺序或优先级。在步骤3006中，文件传递核心可以将第二规则应用于在步骤3004中产生的每一个第一级(例如，级I)存储块。这会将每一个第一级(例如，级I)存储块划分为几个较小的第二级存储块，如步骤3008中所示的。这可以导致相同级(例如，级2)的存储块中的条目具有按照第一和第二规则(例如，规则I和规则2)的相同顺序或优先级。在一个实施例中，可以继续这个过程，直到所有规则都已应用于存储在暂存空间中的项目列表中的条目为止。图31示出了方法3000在存储在暂存空间中的项目列表中的应用。具体地，图31示出了第一规则(例如，规则I)可以应用于暂存空间中的符合删除条件的所有数据。第一规则的应用将暂存空间中的数据划分到多个第一级存储块中(级I存储块)。第二规则(规则2)随后应用于每一个第一级存储块，以进一步将数据划分到多个第二级存储块中(级2存储块)。在一个实施例中，可以根据第二级存储块的最大空间大小来组织第二级存储块。在多个实施例中，每一次文件传递核心从数据流接收元素的数据时，文件传递核 心可以确定其是否将用完暂存空间，并且当为前向纠错(FEC)解码选择暂存空间中完成但未解码的下载时再一次进行该确定。后一检查是必要的，因为不同大小的编码元素针对前向纠错解码会需要暂存空间中不同量的临时存储器。在多个实施例中，如果文件传递核心检测到其将用完暂存空间，文件传递核心就可以删除在排序的列表中具有最低顺序的数据。文件传递核心可以继续删除数据，直到可以满足新的空间要求为止。在多个实施例中，如果存在具有最低顺序的多个数据单元，则文件传递核心就可以随机挑选一个或多个来删除。如果需要删除未完成的下载，且其下载仍在进行中，则FDF就可以在删除前中止所述下载。当文件传递核心开始下载元素时，它可以向该排序的列表中为其增加条目。如果由于用完暂存空间而选择删除正在下载的元素，则文件传递架构可以取消其下载。在多个实施例中，设备上的文件传递架构可以基于以字节计的内部暂存空间大小是否等于或者大于OEM配置设备参数(例如，FDF_MAX_INTERNAL_SCRATCH_SPACE_SIZE)，来确定其将用完内部暂存空间。在一个实施例中，如果设备上不存在OEM配置设备参数(例如，FDF_MAX_INTERNAL_SCRATCH_SPACE_SIZE),则设备可以使用所述参数的缺省值作为内部暂存空间的上限。在一个实施例中，设备上的文件传递架构可以基于外部暂存空间大小是否等于或者大于设备调试参数(例如，FDF_MAX_EXTERNAL_SCRATCH_SPACE_SIZE)，来确定其将用完外部暂存空间。在一个实施例中，设备上的文件传递架构可以基于暂存空间所在的存储卡是否用完空间来确定其将用完暂存空间。在一个实施例中，设备上的文件传递架构可以在其从数据流接收用于使用内部存储器存储策略的应用的数据时，检查以确定其是否将用完内部暂存空间。在一个实施例中，设备上的文件传递架构可以在其从数据流接收用于使用外部存储器存储策略的应用的数据时，检查以确定其是否将用完外部暂存空间。在一个实施例中，设备上的文件传递架构可以在其开始前向纠错(FEC)解码暂存空间中的元素时，检查以确定其是否将用完暂存空间。在一个实施例中，如果设备上的文件传递架构用完暂存空间，设备上的文件传递架构可以停止向暂存空间写入数据。在一个实施例中，当检测到对于新的需要没有足够的暂存空间时，设备上的文件传递架构可以从暂存空间中仅删除能够满足新存储要求的最小必要数量的数据。在一个实施例中，当响应于用完暂存空间而从暂存空间删除数据时，设备上的文件传递架构可以删除具有按照以下两条规则所确定的最低顺序或优先级的数据规则I-解码后的元素具有最高优先级；规则2-完成的下载具有高于未完成的下载的优先级，其中，规则I具有高于规则2的优先级。在一个实施例中，如果响应于用完暂存空间而选择删除正在下载的元素，则设备上的文件传递架构可以取消其下载。在多个实施例中，文件传递架构可以使用多个文件传递数据流来充分支持文件传递服务的需要。这可以是这样的情况存在多个多路复用(例如，广域多路复用和局域多路复用，或者在多频网络部署中多个射频上的一个以上的多路复用)，并且一个以上的多路复用具有一个或多个文件传递数据流。在多个实施例中，这些多路复用可以全都使用诸如MediaFLO 技术的相同的广播技术，不同的广播技术(例如，MediaFLO 、ISDB-T等)，或者多种广播技术的任何组合。如上所述，当存在多个多路复用时，文件传递架构可以使用多个文件传递数据流。在一个实施例中，当存在具有一个以上数据流的单个多路复用时，文件传递架构也可以使 用多个文件传递数据流。例如，图32是示出如何可以在具有两个用于传送文件发送的数据流的单个多路复用上使用多个文件传递数据流的时间线图。具体地，图32示出了如何提供第一数据流以传送常规文件发送和提供另一个数据流以传送更紧急的文件发送。在这个实施例中，如果在正发送较大的低优先级文件(例如，文件I)的同时，接收到要发送的紧急文件(例如，文件2)，可以在不必等待另一个低优先级文件(B卩，文件I)的发送结束的情况下，在紧急数据流上发送该紧急文件(即，文件2)。以此方式，文件传递架构可以适应低优先级文件和高优先级文件，以及在使用单个多路复用的同时促成晚到达的紧急文件的发送。在多个实施例中，文件传递架构可以包括用于具有至少一个文件传递数据流的每一个多路复用的广播调度流。如图33所示的，在广播调度流上广播的广播调度消息可以仅描述用于各自多路复用上的数据流的广播调度。换句话说，在多个实施例中，每个多路复用可以仅存在一个广播调度消息(BSM)。因此，在多个实施例中，单个广播调度消息可以传送用于不同多路复用上的发送的广播调度信息。图33示出了，在这些实施例中，如何可以由目录信息消息(DM)中的不同记录来通知不同多路复用(WM1、WM2)上的或者甚至在不同广播网络上的广播调度流(BSF1、BSF2)的不同版本(版本I、版本2)。接收机设备可以独立于其他广播调度流(例如，BSF2)来检测并接收广播调度流(例如，BSFl)上的更新的广播调度消息。因此，如图33所示，目录信息消息(DIM)可以指定第一广域多路复用(例如，WMl)包括第一版本(例如，版本I)的第一广播调度流(例如，BSFl)，第二广域多路复用(例如，WMl)包括第二版本(例如，版本2)的第二广播调度流(例如，BSF2)。在多个实施例中，可以在不同射频网络(例如，RF1、RF2)上同时广播多个广播调度流(例如，BSF1、BSF2)。在多个实施例中，目录信息消息可以是在初始获取流(IAF)中传送的开销消息，用以提供与这样的广播网络有关的引导信息(bootstrapping information),即在所述广播网络中，这些网络中的传输流标识符(例如，用于广播调度流的流ID)用于传送广播调度消息。图34示出了在多频网络(MFN)中接收机设备如何有可能检测存在对广播调度流的更新，但同时确定它不能接收该更新的实例。在图34所示的实例中，初始获取流(例如，IAF)指示在第二射频网络(例如，RF2)上的广播调度流(例如，BSF2)被更新。然而，设备不能切换到第二射频网络(例如，RF2)。在这种情况下，文件传递架构会经历额外的数据丢失，因为接收机设备不能接收在第二射频网络(例如，RF2)上的文件传递数据流(由BSF2描述)。在一个实施例中，接收机设备可以检测到更新的存在，并将更新确定为是不可接收的。在一个实施例中，当接收机设备将更新确定为是不可接收的时，接收机设备可以启动恢复过程来减轻数据丢失。图35示出了可以如何配置接收机设备，以使得当设备移动到新的多路复用时，可以迫使设备针对该新的多路复用接收广播调度消息。在多个实施例中，可以实现这个移动性行为，以便适用于局域多路复用(例如，LM1、LM2)和广域多路复用(例如，丽I、丽2)。图36示出了支持在同一射频上的一个以上多路复用的文件传递架构配置。就是说，在多个实施例中，不同的多路复用不必在不同的射频上。例如，第一射频(例如，RFl)可以包含局域多路复用(例如，LM_B)和广域多路复用(例如，丽I)。当文件传递核心在同一射频上接收多个数据流时，这些流的总速率应不大于设备平台专用参数(例如，FDF_MAX_FDRECEIVE_RATE)0由于文件传递架构可以在后台中运行，因此该总流速率上的这个限制可以减小文件传递架构对诸如实时视频接收和显示的前台任务的影响。在多个实施例中，可 以在广播调度消息中以通知或指定数据流速率。在一个实施例中，如果按照数据过滤决策，文件传递核心需要同时在同一射频上接收多个数据流，并且这些流的总速率大于特定参数(例如，FDF_MAX_FD_RECEIVE_RATE)，则文件传递核心可以随机挑选数据流的一个子集来接收，以使得挑选的数据流的总速率不大于该特定参数(例如，FDF_MAX_FD_RECEIVE_RATE)。在多个实施例中，文件传递架构可以通过从流协议堆栈(FPS)获得在两个不同多路复用上的两个数据流的射频ID，来确定它们是否在同一射频上。图37示出了文件传递架构配置，在该文件传递架构配置中，文件传递核心被配置为独立地在不同射频上调度文件下载。就是说，在多频网络部署中，文件传递核心可以在一个射频(例如，RFl)上调度接收文件传递数据流(例如，数据流I 一 2)，并将它们注册到流协议堆栈(例如，FPS)，而不用考虑其它射频的存在(例如，RF2)。如果存在将在不同射频(例如，RF1、RF2)上同时广播的多个文件(例如，文件I 一 4)，文件传递核心可以调度接收全部这些文件，即使其仅能够接收一个射频。在这个实施例中，由流协议堆栈来决定其可以接收哪一个射频，这是因为只有流协议堆栈拥有与设备需要处理的所有服务(包括具有高于文件传递服务的优先级的实时服务)有关的信息。在一个实施例中，当设备上的文件传递架构需要在同一射频上同时接收多个数据流，并且这些流的总数据速率大于特定参数(例如，FDF_MAX_FD_RECEIVE_RATE)时，文件传递架构可以随机挑选数据流的一个子集来接收，以使得挑选的数据流的总速率不大于该特定参数(例如，FDF_MAX_FD_RECEIVE_RATE)。在一个实施例中，设备上的文件传递架构可以调度接收射频上的一个(或多个)文件传递数据流，而无需考虑其它射频的存在。图38示出了文件传递管道(FDP)有效载荷(B卩，由FDCP/FDP子层执行的FEC解码的输出)如何可以包括两个部分文件传递核心有效载荷(FDC有效载荷)；和循环冗余校验(CRC)尾部。文件传递管道有效载荷包括元素和文件传递核心有效载荷尾部。在一个实施例中，循环冗余校验尾部可以是使用标准CRC-CCITT生成多项式产生的16位校验和。在多个实施例中，文件传递核心可以基于16位循环冗余校验校验和尾部，对接收的文件传递核心有效载荷执行循环冗余校验。如果循环冗余校验成功，则文件传递核心可以剥离循环冗余校验校验和，并将文件传递核心有效载荷传送到文件传递文件管理(FDM)层。在一个实施例中，设备上的文件传递架构可以基于有效载荷中的16位循环冗余校验校验和，使用CRC-CCITT生成多项式来对接收的文件传递核心有效载荷执行循环冗余校验。在一个实施例中，如果对接收的文件传递核心有效载荷所执行的校验和失败，则设备上的文件传递架构可以丢弃接收的文件传递核心有效载荷。在多个实施例中，当应用退出时，文件传递架构可以释放分配给它的资源。所释放的被分配资源可以包括在期望字符串表中的条目。如上所述，文件传递文件管理(FDM)层可以负责管理由文件传递核心(FDC)作为文件所接收的数据。由文件传递架构传递的每一个文件都可以具有一个或多个独立于设备平台的文件名称，其遵循UNIX文件命名规范(例如，根目录由“/”表示，目录或文件基本名称由“/”分开)。由设备上的文件传递架构接收的每一个文件也可以具有存储名称，其指定文件的物理存储位置。存储名称可以依赖于设备平台。例如，在基于WindowMobile和Linux的设备上，具有文件名称“/tad/fl. mp4”的文件分别可以存储在“c: \fdroot\tad\f I. mp4”和“/ext/fdroot/tad/fl. mp4”。应注意,在多个实施例中,在文件传递架构与设备应用之间的通信可以基于独立于设备平台的文件名称，而不基于依赖于设备平台的存储名称。
当文件传递架构为应用接收文件时，它可以根据应用的存储策略，自动将其文件名称映射到存储名称，并将文件存储在由存储名称所指出的位置。应用的存储策略可以指定文件传递架构可以用于存储其为应用所接收的文件的存储器的类型(内部或外部)。在一个实施例中，当向文件传递架构注册时，应用可以指定以下存储策略之一仅内部存储器；首先内部存储器随后外部存储器；仅外部存储器；和首先外部存储器随后内部存储器。在一个实施例中，接收机设备可以被配置为仅支持“仅内部存储器”策略。在另一个实施例中，接收机设备可以被配置为仅支持“仅内部存储器”和“仅外部存储器”策略。在再另一个实施例中，接收机设备可以被配置为支持所有存储策略或者其任意组合。图39示出了根据实施例的示例性文件命名规范和文件名称到存储名称的映射。在这个实施例中，文件传递架构按照如下将文件名称映射到存储名称将文件名称中的每一个分隔符“/”转换为依赖于设备平台的分隔符(例如，“\”)；及在与由应用的存储策略选择的存储器类型相对应的物理基本目录(例如，C:、D:)后面附加所转换的字符串。在一个实施例中，应用可以在注册阶段期间提供所述物理基本目录。在一个实施例中，在应用第一次访问由文件传递架构接收的文件之前，应用可以请求文件传递架构将其文件名称映射到存储名称，随后使用存储名称来访问文件。图40示出了示例性的受管理元素表(MET)。如上所述，每一个应用的文件传递文件管理(FDM)层都可以维护受管理元素表，其具有与文件传递架构为应用所接收到的并且仍存在于设备上的所有元素(文件或文件包)有关的信息。受管理元素表可以包含多条信息，诸如元素ID (EID)、文件名称(Name)、存储名称(Storage)、参考号(Ref)及其它属性(Attr)。在一个实施例中，文件传递架构可以通过将文件名称中的根目录“/”映射到在根据存储策略选择的物理存储器的根处的“fdroot”，将文件名称中根目录“/”后的剩余部分中的每一个分隔符“/”转换为依赖于设备平台的分隔符，并在“fdroot/”后附加所转换的字符串，来将文件名称映射到存储名称。在一个实施例中，设备上的文件传递架构可以通过将文件名称中的每一个分隔符“/”转换为依赖于设备平台的分隔符，随后在与由应用的存储策略选择的存储器类型相对应的物理基本目录后面附加所转换的字符串，来将文件名称映射到存储名称。在一个实施例中，设备上的文件传递架构可以支持用于应用的“仅内部存储器”存储策略。在一个实施例中，设备上的文件传递架构可以支持用于应用的“仅外部存储器”存储策略。在多个实施例中，当应用向文件传递架构注册时，它可以指定以下应用的存储策略；应用的物理基本目录，文件传递架构可以在该物理基本目录中保存为应用所接收的所有文件；及应用的存储限额(quota)。在多个实施例中，可以存在多个基本目录，每一个存储器类型有一个基本目录。在这些实施例中，文件传递架构可以使用应用的存储策略来决定应使用哪一个基本目录。在一个实施例中，注册可以由文件传递文件管理层来处理。在一个实施例中，设备上的文件传递架构可以支持具有存储策略、物理基本目录和存储限额的应用注册。在一个实施例中，设备上的文件传递架构可以强化在注册期间所指定的应用的存储空间上的限额。图41示出了实施例方法4100，使用该方法，文件传递文件管理(FDM)层可以被配置为管理应用的存储空间并与之交互。在步骤4102中，文件传递文件管理层可以处理应用向文件传递架构(FDF)的注册，并允许应用在注册期间指定其存储策略。在步骤4104中， 文件传递文件管理层可以检查是否存在用于要接收的文件的应用存储空间。在步骤4106中，文件传递文件管理层可以根据应用的存储策略将接收的文件保存到应用存储空间。在步骤4108中，文件传递文件管理层可以在每次应用请求时，删除存储在应用的存储空间中的文件。图42示出了可以在文件传递架构(FDF)中实现的实施例方法4200，用于检查用于要接收的元素的应用的存储空间。在步骤4201中，文件传递架构可以从FDP/FDCP消息获得元素大小信息，并确定应用的存储空间中是否有足够空间用于所述元素。在步骤4202中，如果没有足够的应用存储空间来存储要接收的元素，则文件传递架构可以通知应用。在步骤4203中，文件传递架构可以继续接收元素，除非由应用取消所述下载。图43示出了在应用层(App Layer)与文件传递架构(FDF)之间的数据流与呼叫流交互，其可以在上述的方法4200中实现，用于确定应用的存储器是否具有足够用于要接收的元素(例如，文件或文件包)的空间，所述元素与广播调度记录中的属性字符串相匹配。在操作4301中，文件传递架构可以从FDP/FDCP消息中获得元素大小信息，并确定应用的存储空间中是否没有足够用于接收和存储所述元素的空间。在呼叫流4302中，如果没有足够的应用存储空间来存储要接收的元素，则文件传递架构可以通知应用。在操作4303中，文件传递架构可以等待应用从其存储空间删除一些数据并继续接收所述元素。在呼叫流4303中，应用可以向文件传递架构发出取消通知，指示其停止接收所述元素。图44示出了可以在文件传递架构中实现的实施例方法4400，用于将接收的文件移动到相应的应用的存储空间。在步骤4402中，文件传递核心成功接收对应于文件的文件传递核心有效载荷。在步骤4404中，文件传递核心可以向文件传递文件管理层通知已经接收了文件传递核心有效载荷，并将其在暂存空间中的存储位置告知文件传递文件管理层。在步骤4406中，文件传递文件管理层可以处理文件传递核心有效载荷中的尾部，并确定传送的文件传递核心有效载荷中的元素是否对应于单个文件。文件传递文件管理层可以将文件的名称映射到存储名称(例如，PU。在一个实施例中，如果文件具有多个名称，则文件传递文件管理层可以仅将第一个名称映射到存储名称。在步骤4408中，文件传递文件管理层可以确定是否有足够用于文件传递核心有效载荷的应用存储空间，并可以将有效载荷从暂存空间存储器移动到由存储名称(例如，Pl)所指示的应用存储空间位置。在一个实施例中，如果文件名称之一在受管理元素表(MET)中已经存在，则可以使用用于文件传递核心有效载荷的额外存储器，以确定是否有足够的应用存储空间。在一个实施例中，这个额外存储器可以被定义为表示两个变量的值之间的差的位置，诸如在FDC_payIoacLsize (FDC有效负荷大小)与old_file_size (旧文件大小)之间的差。在步骤4410中，文件传递文件管理层可以向文件传递核心通知文件的移动已经完成。在步骤4412中，文件传递文件管理层可以从存储的文件传递核心有效载荷(例如，存储在Pl的有效载荷)剥离尾部，并在受管理元素表中为文件增加条目(例如，见图40)。在一个实施例中，如果文件传递核心有效载荷中的尾部指示文件具有多个文件名称，则文件传递文件管理层可以向受管理元素表增加信息，其将所有文件名称映射到所命名的存储位置(例如，P1)。在步骤4414中，文件传递文件管理层可以向应用通知文件已经被捕获。图45示出了当文件传递架构(FDF)将接收的文件移动到应用存储空间时，可以在方法4400中发生的在应用层(App Layer)、文件传递核心(FDC)层与文件传递文件管理(FDM)层之间的数据流与交互。在操作4501中，文件传递核心接收文件传递核心有效载荷。在呼叫流4502中，文传递核心向文件传递文件管理层通知已经接收文件传递核心有效载·荷。在操作4503中，文件传递文件管理层将文件名称映射到存储名称(例如，P1)。在操作4504中，如果存在足够的存储空间，文件传递文件管理层就将文件传递核心有效载荷从暂存空间移动到存储位置(例如，PD。在呼叫流4505中，文件传递文件管理层向文件传递核心通知已完成文件传递核心有效载荷的移动。在操作4506中，文件传递文件管理层将尾部从存储在存储位置(例如，Pl)的文件传递核心有效载荷剥离。在呼叫流4507中，文件传递文件管理层向应用层通知已完成捕获。在一个实施例中，如果确定接收的文件将替换已经存在于设备上的文件的旧版本，并且替换失败(例如，在图45的第五步骤4505处，旧版本被锁定)，文件传递核心可以在呼叫流4507中向文件传递文件管理层发送错误消息。在接收到这个错误消息后，文件传递文件管理层可以在呼叫流4505中周期性地重发该请求，直到其从文件传递核心接收到“移动完成”消息，或者直到它在呼叫流4505中已经将该请求重发了预定次数(例如，FDF_MAX_FILE_REPLACE_RETRY_NUM)。在一个实施例中，重发周期(或者次数)可以由诸如秒数之类的设备参数(例如，FDF_FILE_REPLACE_RETRY_PERIOD)来定义。如果所有尝试都失败，文件传递架构可以放弃将数据从暂存空间移动到应用存储空间。在一个实施例中，可以以周期性的清理机制删除已经在暂存空间中存在了超过预定秒数(诸如由设备参数(例如，FDF_MAX_ELEMENT_TIME_IN_SCRATCH_SPACE)所指示的)的已完成下载。在一个实施例中，如果设备上的文件传递架构不能将接收的文件移动到应用存储空间，其可以继续每隔几秒重试移动文件一次，直到移动成功为止，或者直到已经尝试了预定的最大数量的重试为止。此后，周期性清理机制可以在适当时间从暂存空间删除未移动的文件。图46是示出多个文件名称如何可以被映射到单个存储名称的软件体系结构和数据结构图。具体地，图46示出了将多个文件名称(例如，/mpv/cnn/fl. mp4、/mpv/cnnhl/fl. mp4)映射到受管理元素表(MET)中的同一存储名称(例如，D:\fdroot\cnn\fl.mp4)的实施例。当接收到文件时(呼叫流4602)，可以将其重命名，可以将文件名称和存储位置保存到受管理元素表(呼叫流4603)。该图还示出了如何将多个文件名称映射到在受管理元素表中所支持的单个存储名称。图47示出了可以在文件传递架构中实现的实施例方法4700，用于处理没有足够的应用存储空间来存储接收到的文件的情况。如上所述，如果文件传递文件管理(FDM)层确定没有足够的应用存储空间来存储文件传递核心有效载荷，或者应用存储空间满了，则文件传递文件管理层可以在步骤4702向应用层发出请求，以请求应用释放空间。响应于这个消息，在步骤4704中，应用可以删除一些文件。在步骤4706中，应用可以向文件传递架构通知通过文件删除已经释放了一些存储空间。在步骤4708中，文件传递架构可以将接收到的文件从暂存空间移动到应用存储空间。在步骤4710中，文件传递文件管理层可以向应用通知文件已经被捕获。如果文件传递架构从未从应用接收到关于已经释放存储空间的通知，接收到的文件可以保存在暂存空间中，直到由暂存空间周期性清理机制将其删除。图48示出了方法4700的执行中在应用层(App Layer)与文件传递架构(FDF)之间的数据流与呼叫流交互。在呼叫流4801中，文件传递架构向应用层发送通知，以便向应 用层通知应用没有足够的存储空间来存储文件传递核心有效载荷。在呼叫流4802中，应用层直接向文件传递网络发送指令，以从应用存储空间删除一些文件。在呼叫流4803中，应用层向文件传递架构发送通知，以指示已经可以获得存储空间(例如，通过删除文件)。在操作4804中，文件传递架构将文件从暂存空间移动到应用存储空间。在呼叫流4805中，文件传递架构向应用层通知已经完成文件捕获。图49示出了可以由文件传递架构实现的示例性方法4900，用于响应于应用请求文件传递架构删除文件，从应用存储空间删除文件。响应于来自应用的、删除由文件名称所标识的文件的请求，在步骤4902中，文件传递架构可以在受管理元素表(MET)中搜索并找到对应于该文件名称的条目。在确定步骤4903中，文件传递架构可以依据受管理元素表确定该文件是否具有一个以上的文件名称。如果条目具有一个以上的文件名称(即，确定步骤4903 =“是”)，则在步骤4904中，文件传递架构可以将该文件名称从条目简单地移除并结束处理。这样，在一个实施例中，如果指定要删除的文件具有多个文件名称，则文件传递架构可以移除该文件名称而不删除文件。如果文件传递架构确定与指示要删除的文件相关联的文件名称仅有一个(即，确定步骤4903 =“否”)，则在步骤4906中，文件传递架构可以删除存储位置中的文件，并将该条目从受管理元素表移除。在确定步骤4908中，文件传递架构可以确定文件删除是否成功。如果删除成功(即，确定步骤4908 =“是”)，过程可以结束。如果删除不成功(即，确定步骤4908 =“否”)，则在步骤4910中，文件传递架构可以向应用返回错误并结束该过程而不重发删除请求。在一个实施例中，设备上的文件传递架构可以提供接口，应用可以通过该接口来请求删除由文件名称指定的文件。如上所述，文件传递架构可以支持将多个文件打包在一起并作为单个元素来广播该文件包。如前所述，这有助于减小前向纠错(FEC)开销(即，元素越大,所需FEC开销越小)，并提高了传递可靠性(即，元素越大，时间分集越多)。文件打包对于传递多个小文件尤其有用。在多个实施例中，文件打包特征可以实现为文件传递文件管理层特征，其对于文件传递核心影响最小。在多个实施例中，文件打包特征可以以使得该特征对于应用透明的方式来实现。图50示出了示例性方法5000，其可以实现为文件传递架构内的文件打包特征。在步骤5002中，文件传递核心可以使用双向前缀匹配方案来确定用于文件包的广播调度记录(BSR)是否匹配任何应用请求。在一个实施例中，这可以是与在各个文件上使用的相同的双向前缀匹配方案，诸如以上参考图25 - 26所述的。在确定步骤5004中，文件传递核心可以确定是否存在双向前缀匹配。如果不存在匹配(即，确定步骤5004 = “否”)，则文件传递核心可以忽略该文件包。如果存在匹配(即，确定步骤5004 = “是”)，则在步骤5006中，文件传递核心可以将选择字符串传送到文件传递文件管理层。这个选择字符串可以指定在该文件包内应用感兴趣接收的文件。在步骤5008中，文件传递核心可以向文件传递文件管理层发送消息，以请求文件传递文件管理层确定是否应接收该文件包。在一个实施例中，可以将选择字符串作为步骤5008中这个请求的一部分传送到文件传递文件管理层。在一个实施例中，步骤5006和5008可以合并为一个单元/功能呼叫，其将选择字符串作为请求的一部分来传送，以确定是否应接收文件包。在确定步骤5010中，文件传递文件管理层可以确定文件传递文件管理层是否能够接收该文件包，以及是否需要接收该文件包。如果文件传递文件管理层确定无需接收该文件包(即，确定步骤5010 =“否”)，则可以忽略该文件包。如果需要由文件传递文件管理层接收该文件包(即，确定步骤5010 =“是”)，则在步骤5012中，文件传递文件管理层可以 维护用于与该文件包相对应的元素的元素ID和选择字符串。在步骤5014中，文件传递核心接收与该文件包相对应的文件传递核心有效载荷，并可以将其传送到文件传递文件管理层。在步骤5016中，文件传递核心可以向文件传递文件管理层传送文件传递核心有效载荷。在步骤5018中，文件传递文件管理层可以处理文件传递核心有效载荷尾部，并确定文件传递核心有效载荷是否是文件包。在步骤5020中，文件传递文件管理层可以使用其为文件包保存的选择字符串来指示在该文件包内的应保存的文件。图51示出了在实现方法5000的操作时，应用层(App Layer)、文件传递核心(FDC)层与文件传递文件管理(FDM)层之间的数据流与交互呼叫流。在操作5101中，文件包广播调度记录(BSR)由文件传递核心接收，并进行双向前缀匹配，以产生广播调度记录匹配条目。在呼叫流5102中，文件传递核心向文件传递文件管理层传送选择字符串、元素ID和元素类型，文件传递文件管理层检查文件是否已经存在以及文件传递文件管理层是否应接收文件包。在操作5103中，与文件包相对应的元素或文件传递核心有效载荷由文件传递核心接收，并传送到文件传递文件管理层。在操作5104中，文件传递文件管理层处理文件传递核心有效载荷，以从接收到的文件包中选择特定文件并将所选择的文件保存在存储器中。图52示出了示例性方法5200，其可以用于产生选择字符串，所述选择字符串由文件传递文件管理层用于在接收的文件包中选择文件来保存。在步骤5202中，文件传递核心可以确定广播调度记录中的字符串是否与期望字符串(即，由应用指示的用于选择文件进行接收的字符串)双向令牌前缀匹配。如果是，则在步骤5204中，文件传递核心可以将最长的字符串设定为其选择字符串，并将选择字符串传送给文件传递文件管理层。在步骤5206中，文件传递文件管理层可以检查文件是否已经存在。在步骤5208中，文件传递文件管理层确定是否应由文件传递文件管理层接收文件包。如果文件传递文件管理层确定应接收文件包，则在步骤5210中，文件传递文件管理层就维护用于与文件包相对应的元素的选择字符串。图53示出了在方法5200中的在应用层(App Layer)、文件传递核心(FDC)层与文件传递文件管理(FDM)层之间的数据流和交互呼叫流的实例。如上所述，选择字符串可以由文件传递文件管理层用于选择文件包中要保存的文件。如果广播调度记录上的字符串与期望字符串双向令牌前缀匹配，则文件传递核心可以使用二者中最长的字符串作为选择字符串，并将其传送到文件传递文件管理层。在图53所示的实例中，在操作5301中，文件包广播调度记录(具有字符串“/itv/cnn/”)由文件传递核心接收，并与期望字符串“/itv/cnn/el/”进行双向前缀匹配。在操作5302中，文件传递核心产生选择字符串“/itv/cnn/el/”，并将选择字符串、元素ID和元素类型传送到文件传递文件管理层，用于确定文件是否已经存在以及是否应由文件传递文件管理层接收文件包。如果文件传递文件管理层确定文件包能够且需要由文件传递文件管理层接收，则在操作5303中，文件传递文件管理层维护用于与文件包相对应的元素的选择字符串“/itv/cnn/el/”。在一个实施例中，如果设备上的文件传递架构确定文件包广播调度记录中的属性字符串是期望字符串的前缀，设备上的文件传递架构就使用该期望字符串作为用于文件包的选择字符串。图54示出了可以用于确定是否应接收文件包的示例性方法5400。在步骤5402中，文件传递核心可以向文件传递文件管理(FDM)层发送包括文件包信息和选择字符串的请求，以请求文件传递文件管理层指示是否应接收文件包。在确定步骤5404中，文件传递 文件管理层可以确定在受管理元素表中是否存在用于与文件包相对应的元素的条目。如果这个条目不存在(即，确定步骤5404 = “否”)，则在步骤5406中，文件传递文件管理层可以向文件传递核心指示应接收文件包。如果在受管理元素表中存在所述条目(即，确定步骤5404 =“是”)，则在确定步骤5408中，文件传递文件管理层可以确定在文件传递核心请求中是否存在这样的至少一个选择字符串即所述至少一个选择字符串不是与受管理元素表中的所述条目相关联的任何现有选择字符串的前缀。如果是(即，确定步骤5408 =“是”)，则文件传递文件管理层可以在步骤5406中向文件传递核心指示应接收文件包。否则(即，确定步骤5408 =“否”)，文件传递文件管理层可以在步骤5410中向文件传递核心指示不应接收文件。图55示出了可以在方法5400中出现的在应用层(App Layer)、文件传递核心(FDC)层与文件传递文件管理(FDM)层之间的示例性数据流和交互呼叫流。在操作5501中，具有字符串“/itv/cnn/”的文件包广播调度记录(BSR)可以由文件传递核心接收，并与期望字符串“/itv/cnn/el/”进行双向前缀匹配。在呼叫流5502中，文件传递核心可以产生选择字符串“/itv/cnn/el/”，并将选择字符串、元素ID和元素类型传送到文件传递文件管理层，文件传递文件管理层可以使用这个字符串来确定文件是否已经存在以及是否应由文件传递文件管理层接收文件包。就是说，在呼叫流5502中，文件传递核心向文件传递文件管理层发送关于决定是否应接收文件包的请求。在操作5503中，文件传递文件管理层确定是否接收文件。如果在受管理元素表(MET)中不存在用于与文件包相对应的元素的条目，则文件传递文件管理层可以做出接收文件的决定。如果文件传递文件管理层确定在受管理元素表中存在用于文件包的条目，如果至少一个选择字符串不是所述条目中任何现有选择字符串的前缀，则文件传递文件管理层就可以仍选择接收文件。这在图55中示出了，其中，设备的文件传递文件管理层已经具有/itv/cnn/el下的文件。这由受管理元素表的第二行(EID = 1988)的选择字符串列中的选择字符串值“/itv/cnn/el/”来指示。由于应用发出了关于接收/itv/cnn/下的所有文件的新请求，且字符串“/itv/cnn/”比字符串“/itv/cnn/el/”更宽泛，因此设备需要再次下载整个文件包。因此，在呼叫流5504中，文件传递文件管理层可以请求文件传递核心接收文件包，以使得设备可以再次下载文件包。这样，在一个实施例中，在以下情况下，设备上的文件传递架构可以调度接收由广播调度记录描述的文件包元素广播调度记录具有与期望字符串双向令牌前缀匹配的至少一个属性字符串，数据包存在于设备上，以及选择字符串之一将被广播(按照依据广播调度记录所确定的)；以及期望字符串不是与现有文件包相关的任何现有选择字符串的令牌前缀。图56示出了如何可以基于文件名称前缀选择并保存文件包中的文件。如上所述，如果由应用请求的文件名称/目录名称之一是文件名称的前缀，则文件传递文件管理层可以保存文件包中的文件。这在图56中示出了，其显示了仅保存那些具有文件名称前缀“/itv/att”的文件，导致包中四个文件中的两个被保存。如果应用要接收“/itv/vzw/sl/f3”，则文件传递架构就必须再次接收该文件包。
图57是示出在受管理元素表(MET)中的示例性文件包条目的数据结构图。如图57所示，在一个实施例中，在受管理元素表中的用于与文件包相对应的元素的条目可以具有以下信息与文件包相对应的元素的ID (EID);指示元素是文件包的标志(FB);指定文件包中的哪些文件已经被保存的选择字符串(Selection Strings);及具有用于文件包中每一个元素的文件名称、元素ID和存储名称的子条目。图58示出了用于接收文件包并将其保存在应用存储空间中的示例性方法5800。如上所述，在成功接收了与文件包相对应的元素后，文件传递架构可以在应用存储空间中保存文件包中的文件。在步骤5802中，文件传递核心成功接收了与文件包相对应的文件传递核心有效载荷。在步骤5804中，文件传递核心可以向文件传递文件管理层通知已经接收到文件传递核心有效载荷，并将其在暂存空间中的位置通知文件传递文件管理层。在步骤5806中，文件传递文件管理层可以确定是否有足够的空间用于文件传递核心有效载荷，并将其从暂存空间移动到应用的存储空间。在步骤5808中，文件传递文件管理层可以向文件传递核心通知已经从暂存空间移除了文件传递核心有效载荷。在步骤5810中，文件传递文件管理层可以将尾部从存储在存储器(例如，Pl)中的文件传递核心有效载荷剥离。在步骤5812中，文件传递文件管理层可以根据应用的存储器管理策略，在适当的位置处保存文件包中的文件。在步骤5814中，文件传递文件管理层可以将用于文件包的条目增加到受管理元素表中。在步骤5816中，文件传递文件管理层可以向应用通知文件已经被捕获。图59是方法5800中的在应用层(App Layer)、文件传递核心(FDC)层与文件传递文件管理(FDM)层之间的数据流和交互呼叫流的实例。在操作5901中，文件传递核心成功接收到与文件包相对应的文件传递核心有效载荷。在呼叫流5902中，文件传递核心向文件传递文件管理层通知已经接收到文件传递核心有效载荷。文件传递核心随后将文件传递核心有效载荷在暂存空间中的位置传送到文件传递文件管理层。在操作5903中，文件传递文件管理层确定是否有足够的空间用于文件传递核心有效载荷，并将文件从暂存空间移动到应用的存储空间。在呼叫流5904中，文件传递文件管理层向文件传递核心通知已经将文件传递核心有效载荷从暂存空间移除。在操作5905中，文件传递文件管理层将尾部从存储在存储器(例如，Pl)中的文件传递核心有效载荷剥离，存储文件包中的文件，并向受管理元素表增加用于文件包的条目。在呼叫流5906中，文件传递文件管理层向应用通知文件已经被捕获。在一个实施例中，设备上的文件传递架构可以在成功地保存了包含在文件包内的文件后，删除接收的文件包。图60示出了用于删除从文件包接收的文件的示例性方法6000。在步骤6002中，应用可以向文件传递架构发出用以删除在文件包中接收的文件的请求。在步骤6004中，文件传递文件管理层可以在受管理元素表中找到具有用于该文件的子条目的文件包条目。在确定步骤6006中，文件传递文件管理层可以确定该子条目是否具有一个以上与之相关的文件名称。如果文件传递文件管理层确定该子条目具有一个以上文件名称(即，确定步骤6006 =“是”)，则文件传递文件管理层就可以在步骤6008中从该子条目移除该文件名称。如果子条目没有一个以上文件名称(即，确定步骤6006 =“否”)，则在步骤6010中，文件传递文件管理层可以删除存储位置中的文件，并从受管理元素表移除该子条目。如果在文件包条目中没有文件子条目(即，已经删除在文件包中接收的所有文件)，则在步骤6012中，文件传递文件管理层可以从存储器删除该文件包条目。在一个实施例中，如果已经删除其文件的子集，则可以认为文件包元素存在。在一个实施例中，只要由应用启动文件删除过程就可以通知文件传递架构，以使得不再再次下载删除的文件。在一个实施例中，当文件包中的 至少一个文件存在于设备上时，设备上的文件传递架构就可以认为文件包元素存在。图61是示出在删除从文件包接收的文件时所涉及到的逻辑的和示例性的数据流的数据结构图。图61示出了当子条目仅具有与之相关的一个文件名称(例如，EID2009)时，文件传递文件管理层如何可以删除存储位置中的文件并移除整个子条目(由通过EID2009的线指示)。图61还示出了如果子条目具有一个以上与之相关的文件名称(例如，EID1988)，文件传递文件管理层如何可以从子条目仅移除文件名称(由通过文件名称/itv/att/sl/fl2001和存储路径D:/fdroot/att/sl/fl的线指示)。图62示出了在接收先前已经接收的文件包时,在应用层(App Layer)、文件传递核心(FDC)层与文件传递文件管理(FDM)层之间的示例性数据流和交互呼叫流。在操作6201中，文件包广播调度记录(BSR)由文件传递核心接收并进行双向前缀匹配。在呼叫流6202中，文件传递核心向文件传递文件管理层传送选择字符串、元素ID和元素类型，以使得其可以确定文件是否已经存在以及确定是否应接收该文件包。在操作6203中，文件传递文件管理层维护用于与该文件包相对应的元素的选择字符串(“/itv/vwz/sl/f3”和“/itv/wz/sl/f4”)。在呼叫流6204中，与文件包相对应的元素或文件传递核心有效载荷由文件传递核心接收，并传送到文件传递文件管理层。如图62所示的，该文件包可以具有四个文件/itv/vzw/sl/f3、/itv/vzw/sl/f4、/itv/att/sl/fI 和 /itv/att/sl/tf2。在所不实例中，文件传递文件管理层确定文件传递架构先前已经接收了该文件包，但仅保存了两个文件/itv/vzw/sl/f3和/itv/vzw/sl/f4。例如,这可以是以下情况运行在应用层上的应用先前请求了文件包中的两个文件(例如，/itv/att/sl/fl和/itv/att/s2/f2),并随后发出对两个新文件(例如，/itv/vzw/sl/f3和/itv/vzw/sl/f4)的另一个请求,这两个新文件恰好在与前两个文件相同的文件包中。在呼叫流6203中，文件传递文件管理层从文件传递核心再次接收该文件包，并在存储器中仅保存该文件包中的新请求的两个文件(例如，/itv/vzw/sl/f3 和 /itv/vzw/sl/f4)。图63示出了可以用于在文件传递核心与文件传递文件管理层之间交换数据的示例性文件传递核心有效载荷格式。在一个实施例中，文件传递核心与文件传递文件管理层可以被配置为同时支持多个文件传递核心有效载荷格式。在一个实施例中，可以由广播调度记录中的参数、标志或位(例如，FD_MODE)来指定文件传递核心有效载荷格式。在一个实施例中，设定FD_MODE位为O选择第一格式，而设定FD_MODE位为I选择第二格式。图64示出了对应于图63所示的后向兼容格式(BCF)的示例性文件传递核心有效载荷格式。图64所示的文件传递核心有效载荷格式可以包含单个文件或者可以包含具有多个文件的文件包。BCF文件传递核心有效载荷格式可以包括在结尾处的片段元数据(clipmeta data)。文件传递核心有效载荷格式可以包括可选的元素ID和一个(或多个)文件名称，其被增加到用于片段元数据中clip_def_rec XML元素中的用于文件包中的该一个文件或多个文件的non_realtime_presentation XML元素。在多个实施例中，接收机设备可以接收并可以使用所述元素ID和文件名称。在一个实施例中，接收机设备可以忽略其未识别的任何新字段。图65和66示出了对应于图63所示格式的示例性文件传递核心有效载荷格式。具体地，图65示出了用于一个元素的示例性文件传递核心有效载荷格式，其中该元素是具有两个名称的单个文件。图66示出了用于一个元素的示例性文件传递核心有效载荷格式，其·中该元素是包含具有两个名称的文件(例如，文件I)的文件包。图65和66中所示的文件传递核心有效载荷格式可以包含这样的元素部分即其是单个文件或者是包含连串文件的文件包。所示的文件传递核心有效载荷格式具有尾部区，其包含以下信息字段尾部数据长度；尾部数据；和元素ID。尾部数据字段可以进一步包括压缩类型(Compression Type)字段，其指定在文件传递核心有效载荷的该元素部分上要实施哪个压缩方案。在一个实施例中，元素类型(ElementType)字段可以指示该元素是文件还是文件包。如果该元素是文件，如图65所示的，则尾部还可以包括用于元素类型和文件名称的额外的信息字段。如果该元素是文件包，如图66所示的，则尾部可以包括用于该文件包中每一个文件的元素ID、偏移和文件名称的信息字段。如以上参考图4所述的，应用(例如，前端应用42、43)向文件摄取服务器31提供要发送的文件。文件摄取服务器31经由文件传输网络41向接收机设备传递所述文件和广播调度消息。图67示出了用于摄取文件、调度文件的发送、产生广播调度消息并广播所产生的广播调度消息的示例性方法6700。在方法6700中，在步骤6702，诸如文件摄取服务器31的前端系统中的服务器可以从一个或多个前端应用42、43接收要发送的文件。在步骤6704中，作为摄取过程的组成部分，服务器可以产生文件和/或元素，并可以获得/产生用于要广播的文件的文件或元素标识符。在步骤6706中，作为摄取过程的组成部分，服务器可以获得文件大小以及与文件有关的其他信息，诸如文件属性字符串、或者如上所述的应用/服务标识符。在步骤6708中，作为摄取过程的组成部分，服务器可以确定将传送数据文件的内容流的数据速率。数据速率可以根据广播资源可用性而改变。数据速率也可以保持固定，例如如果为特定的文件传递类型而指定了数据速率。作为摄取过程的组成部分，在步骤6710中，服务器可以确定每一个文件的广播持续时间，例如通过将文件大小除以文件传递数据速率来确定。在步骤6711中，服务器可以基于该发送持续时间，确定在下一个广播调度周期(BSP)内要广播哪些文件。应注意，调度过程和BSM产生过程是分开的过程，在此仅是出于简要目的而一起加以说明。例如，文件调度过程可以不限于下一个15分钟周期(例如，可以将文件调度为从摄取开始3个小时后发送)，而BSM产生过程可以将BSM的内容周期性地(例如，每隔15分钟)确定为为下一周期(例如，15分钟)定义的当前发送调度。以下更进一步详细地论述在摄取和BSM产生中的文件调度的过程。在步骤6712中，服务器可以调度文件在广播调度周期内的发送。作为调度文件在广播调度周期内的发送的操作的组成部分，在步骤6714中，服务器可以为在广播调度周期内的每一个文件确定广播窗口开始时间。在步骤6716中，服务器可以产生广播调度消息和广播调度监视记录(BSMR)，其指定了记录类型、记录数据链和对广播调度消息的下一次更新的时间(例如，下一个监视时间)。作为产生广播调度消息的操作的组成部分，在步骤6718中服务器可以产生一个或多个流广播调度记录(FBSR)。作为产生广播调度消息的操作的组成部分，在步骤6720中，服务器于是可以从接收的和产生的信息组合得到广播调度消息，包括为将在BSP内广播的每一个文件确定广播窗口。在步骤6722中，服务器可以向广播网络提交组合得到的广播调度消息，以开始在广播调度流上的重复发送，并且在步骤6724中，服务器可以向广播 网络提交要广播的文件，以便可以根据在广播调度消息中指定的广播调度，在文件传递数据流上发送所述文件。可以通过服务器返回到步骤6702以开始为下一个BSP逐步产生广播调度消息来重复这个过程。如上所述，一旦文件内容提供方9内的文件传递应用提交了用于在广播网络I上传输的文件，文件摄取系统31就可以使用专用于文件传输的广播资源调度这些文件的广播。这些专用广播资源可以概念性地视为文件传递管道。如上所述，在多个实施例中，可以将一个以上文件传递管道用于在广播网络上广播文件。图7中示出了在一个或多个文件传递管道中调度所摄取的文件以及文件的时分复用。如上所述，文件摄取系统31可以采用各种不同格式从各种不同源(B卩，前端应用)接收文件。文件摄取系统31调度多个接收的文件，产生广播调度消息，并与文件传输网络41协作，以确保在广播调度消息内所公布的广播窗口内广播所述文件。图68示出了示例性实施例，在其中，两个前端应用向文件摄取系统31提交文件，用于在文件传输网络41上传输。在这个所示实例中，两个前端应用是天气应用43和交互式应用49。在这个实例中，天气应用43使用文件传输网络41来向运行在接收机设备上的天气应用46传递应用文件。类似地，交互式应用49使用文件传输网络41来向接收机设备上的交互式应用47传递交互资源和文件。在多个实施例中，前端应用43、49可以简单地通过连同适当文件命令一起提供文件，来与文件摄取系统31交互，所述文件命令例如图68 所示的数据图表中的 sendFile (/weaApp/LA/fl. jpg)(发送文件(/weaApp/LA/fl. jpg))及其它参数。为了发送一系列文件，前端应用43、49可以在单个命令中指定多个文件，例如 sendFile(/itv/sig/cat. xml;itv/res/svc_5/fI. jpg;/itv/res/svc_5/f2. jpg;/itv/res/svc_5/f3. jpg)。如图68所示，一些应用可以仅提交内容文件(例如，天气应用可以提交jpeg图像)，而其它应用可以提交内容文件和开销文件(例如，交互式应用可以提交jpeg图像和cat. xml开销文件)。再其它的应用可以将内容文件连同附加属性信息一起提交(例如，交互式应用可以可替换地提交jpeg图像及为文件描述特性的相关属性)。应用向文件摄取系统提交开销文件对于这种开销文件可以具有不同的目的。这个开销文件可以用于向接收机设备提供与可用于设备应用的文件有关的信息。在一个实施例中，这个开销文件可以是目录文件或cat. xml文件的形式。cat. xml文件可以用于提供属性的列表，所述属性的列表可以使得接收机设备能够选择要接收的文件。也可以经由摄取接口使相同的属性列表信息可用，例如，通过提供图69中所示的数据图表。另外或者可替换地，可以在广播调度消息中传送属性列表。图69和70中示出了可用用于向文件摄取系统31提交文件的示例性数据图表。文件摄取系统也可以提供用于接收与要发送的文件有关的信息，例如传递标准，的接口。例如，如图70所示的数据图表中示出的，文件摄取接口文件传递请求可以为要发送的文件指定期望的开始时间和截止时间、或者广播调度。如果指定了广播调度，则文件传递请求可以指示应在期间发送文件的周期和应尝试文件发送的次数。广播调度还可以包括结束时间，在所述结束时间之后不应发送文件。文件传递请求操作可以为文件传递应用提供以下特征用以指示为发送提交的文件的机制；用以同时提交多个文件的机制；用以对可以在应用级关联在一起的文件进行分组的机制；用于每一组相关文件的不同传递标准要求的定义；及使得能够将第二次提交的 文件识别为再提交，以便可以更新先前提交的项目的传递标准的机制。可以经由文件摄取操作来提交用以指示为发送提交的文件的机制。在这个操作中，可以指示用来提供位置的内容统一资源定位符(URL)，其中文件摄取服务可以从该位置取得要广播的文件。该机制还可以指示进一步与为广播而摄取的文件的内容和上下文相关联的额外的参数。例如，所述额外的参数可用包括文件名称，其可以用于指示在应用目录结构中文件的目录。所述额外的参数可以包括属性列表，其提供了用来表征文件以使得接收机设备能够过滤并选择要接收的特定文件的参数。实现多个文件的同时提交的机制可以允许应用识别相关的那些文件。例如，在文件传递请求中单个文件信息单元上的特定目录下的所有交互性文件可以认为是相关的。前端应用能够确保有可能将具有交叉相关性的文件打包并调度一起进行广播。例如，当接收机设备可以获得新文件时，图68中列出的交互性文件可以更新交互性目录文件。利用这个接口，在发送目录/itv/res/svc_5/下的新文件(有可能作为文件包来发送)之前，可以请求发送/itv/sig/cat. xml文件,并使其在接收机设备处可用。用以使得相关的文件能够在应用层分组在一起的机制可以确保对相关的文件应用相同的传递标准，并所述相关的文件由接收机设备同等地需要。当无线发送文件时，文件摄取系统可以打包类似的文件，以便更有效地使用前向纠错编码。文件注入服务可以使用这个相关性信息来将相关的文件打包在一起。也可以考虑用以对文件打包做出决定的其它标准。例如，文件摄取系统可以将与服务的订购相关联的不同文件分组在一起。这样，有资格为一个服务接收一个文件的接收机设备也可以有资格接收用于一起订购的其它服务的文件。使得前端应用能够为每一组相关文件的发送要求定义不同的传递标准的机制可以允许应用为所摄取的文件广播请求服务质量(QoS)级别或者发送要求。服务质量可以表示相对于及时性(timeliness)(例如,刷新)和成功的传递(例如,冗余发送以确保克服传递失败)而言，到预期用户人群的传输服务的质量。文件摄取系统31可以调度每一组相关文件，以便满足它们请求的传递标准。如果调度新文件，当考虑优先级调度时，文件摄取系统可以确保不损害先前摄取的文件的传递标准。在基于优先级的调度中，可以丢弃先前调度的文件，来为新文件让出空间。文件摄取系统可以被配置为，使得当第二次或第三次提交相同文件时，其被识别为先前发送的文件的再提交或更新，以便可以重复使用用于先前提交的文件的传递标准。
随着文件摄取系统31接收要摄取的文件，诸如在第一广播调度周期期间，可以被调度发送的新文件最早是在下一个广播调度周期中，如图71所示的。例如，随着在第一广播调度周期(BSPl)期间从文件内容提供方9接收文件f8、f9和f 10，文件摄取系统31针对下一个或者更靠后的广播调度周期(BSP2)调度文件发送。随着文件被调度发送，可以将文件存储在数据存储器32中。所得到的更新的广播调度也可以存储在诸如数据库的存储器中。
如图71所示的，在当前广播调度周期期间接收的文件仅允许被调度为在下一个或者随后的广播调度周期中的发送。这是因为已经经由当前广播调度消息向接收机设备公布了当前广播调度周期中的调度信息。一旦一个广播调度消息被广播，接收机设备会不能检测在由该广播调度消息覆盖的广播调度周期中的随后调度变化，这是因为，如果在广播调度期间在针对发送的广播调度消息中没有列出感兴趣的文件，则接收机设备可以停用接收机电路以便保留功率。因此，对广播调度周期的持续时间的选择可以是在内容的可能刷新与设备需要多频繁地接收更新的广播调度消息之间的折衷。较小的广播调度周期允许较快地发送新接收的文件；然而，对接收机设备频繁地接收更新的广播调度消息的要求会影响其电池寿命。
因此，文件摄取系统31中的调度器认为当前广播调度周期对于传送新接收的文件而言是不可用的。然而，在当前广播调度周期之后的任何时间段都可以被修改，因为该调度尚未向接收机设备公布。图72A - 72D示出了如何可以根据何时接收文件及其急迫性来修改广播调度。
例如，图72A示出了在向文件摄取服务31提交要传输的新文件f8_fl0之前的调度状态。图72B示出了用于文件&指定了紧急传递要求的情况的调度状态。在该情况中， 文件摄取系统31可以导致延迟具有较低优先级或者较少限制性时间传递要求的其它文件 (例如，f51)(例如，其已调度的广播窗口被推迟)。不重新调度不能容忍更进一步延迟的其它文件(例如，f5)，并且继续在这些文件的原始广播窗口中调度其进行广播。图72C示出了在下一广播调度周期中的文件不能容忍长度为摄取文件4所用时间的进一步延迟，所以在随后的广播调度周期中调度文件f9的发送的情况。图72D示出了在下一个广播调度周期中的文件不能容忍进一步延迟时摄取文件f1(l，且文件f1(l比文件f9更紧急，结果将文件f9推入更迟的广播调度周期中的情况。
文件摄取系统还可以负责协调文件到广播网络的传递或广播发送。这个过程可以包括广播调度消息(BSM)信息的广播，如图73所示的。这个过程可以包括将文件分派到广播网络，如图74所示的。
图73中示出了在更新无线发送的广播调度消息时所涉及的过程，并且该过程在图75所示的示例性方法7500的过程流程图中结束。在当前广播调度周期的结束之前的某个时刻，文件摄取系统31可以从其存储设备32读取当前调度信息，步骤7502，并可以在步骤7503中(操作A)产生新广播调度消息，以描述下一个广播调度周期。在步骤7504中，文件摄取系统可以利用OSS更新广播调度消息版本，OSS是用于管理和公布开销版本变化的组件。在步骤7506中，文件摄取系统可以向分发服务器(DIST)发送更新的广播调度消息， 分发服务器是用于以配置的广播速率发送文件和开销消息的组件。在步骤7508中，OSS可以向在初始获取流(IAF)中传送的消息增加更新的广播调度消息版本，并可以在步骤7510 中(通信B)向分发服务器发送更新的IAF消息。分发服务器可以在广播调度流上以配置的广播调度流数据速率向流服务节点(FSN)发送更新的广播调度消息，流服务节点是在广播网络内的发送上实际涉及的组件。
图74和75中示出了在更新发送的广播调度消息时所涉及的过程。文件摄取系统 31也可以利用当前广播调度消息上的调度信息，其中当前广播调度消息的版本经由OSS来公布，并且其内容经由分发服务器发送，如上所述。在步骤7516中，文件摄取系统可以通知分发服务器(操作I)开始发送文件，以使得根据公布给接收机设备的广播调度消息，以无线方式广播文件。在如此进行时，文件摄取服务可以与在当前广播调度消息中描述的信息一致地描述在发送文件时使用的流ID和数据速率。在步骤7518中，分发服务器可以读取接下来要广播的文件内容(操作2)，并且随后在步骤7520中，以为文件发送所使用的流ID定义的数据速率向FSN发送文件(操作3)。
如上所述，诸如MediaFLO 技术广播网络的广播网络中的发送资源可以按照超帧内的OFDM符号来定义，超帧在MediaFLO 中具有一秒的持续时间。可以将在这种超帧上的符号进一步划分为局域多路复用符号和广域多路复用符号。不同广播网络可以将其它时 分、频分或码分复用机制(即，不同于0FDM)用于在共享广播资源上的媒体传输。本文使用的术语“多路复用(multiplex)”通常指代可用于经由广播网络的媒体传输的广播资源(例如，在给定的射频带宽上)。可以用于传输文件的广播资源的量可以是基于射频带宽、传输编码机制、以及同样由广播信号传送的诸如实时内容和开销数据之类的其它媒体或数据的量。
在诸如MediaFLO 网络的多媒体广播网络中，可以同时广播各种内容，包括 为局部区域指定的内容，其被称为局域内容或者局域多路复用(LM)，以及提供给多个局域广播器的内容，其称为用于广域多路复用(WM)的广域内容。局域多路复用和广域多路复用可以是使用给定的射频带宽的多路复用的不同的部分(例如，OFDM帧的不同部分)。局域内容可以是专用于本地操作基础结构(LOI)的内容，诸如区域广播。
图76示出了，在任意给定的本地操作基础结构中可以存在多个射频信号。在所示实例中，本地操作基础结构I (LOIl)包括单个射频信号(RF1)，其包括第一广域多路复用 (丽I)和第一局域多路复用(LMl)分量。本地操作基础结构2 (L0I2)包括两个射频信号 (RF2和RF3)，每一个都由广域多路复用(丽2、丽I)和局域多路复用(LM2、LM1)组成。在所示实例中，局域操作基础结构3 (L0I3)包括单个射频信号(RF4)，其由广域多路复用(WM2) 和局域多路复用(LM3)组成。
如图76所示，在任意射频信号中传送的广域多路复用分量和局域多路复用分量可以相同或不同于其它射频信号中的广域多路复用分量和局域多路复用分量。另外，不同射频信号还可以使用不同的传输技术，诸如MediaF LO 技术、ISDB-T、ATSC-M/H等。图76 示出了可以在不同本地操作基础结构中的不同射频信号中传送给定的多路复用(例如，WMl 或LM2)。此外，给定的本地操作基础结构可以具有可用的多个射频信号。CN 102948159 A书明说42/54 页
图77示出了每个多路复用可以定义的多个文件传递类型。如上所述，可以以共享单个公共资源池(诸如每秒、每个多路复用的符号(例如，OFDM符号)的量)的文件发送来实现多个实施例。如上所述，这种资源池可以是抽象的，并可以被定义为文件传递架构内的一个或多个文件传递管道(FDP)。图77示出了这些文件传递管道中的多个文件传递管道都可以定义在单个多路复用中。具体地，图77示出了广域多路复用(WMl)可以包括两个文件传递管道(FD管道1、FD管道2)，允许剩余的多路复用带宽专用于发送实时和IP数据服务 (RT+IPDS)。类似地，第二广域多路复用(WM2 )可以包括三个文件传递管道(FD管道3 — 5 )， 剩余的多路复用带宽专用于发送实时和IP数据服务。
在多个实施例中，可以在广播网络内将文件传递管道组织为由多路复用(例如，文件传递管道的地理区域)、发送数据速率和一组管道流ID所定义的逻辑实体。为管道定义的发送数据速率可以取决于分配给该管道的多路复用带宽的组成部分。在多个实施例中， 分配给文件传递管道的资源的量是可配置的，该配置取决于由部署的接收机设备所支持的数据速率。
图77还示出了，在多个实施例中，文件传递管道可以按照其数据速率来定义和组织。文件传递管道的数据速率中的变化由每一个管道的直径来示出(例如，WMl中的文件传递管道具有较高数据速率，因此比WM2中的文件传递管道更快)。将文件传递管道定义和组织到具有较高和/或较低数据速率的组中有助于应对由一组不同的部署的接收机设备所引起的限制。例如，早期的接收机设备通常支持有限的最大数据速率，而后期的·接收机设备能够支持更高的数据速率。按照文件传递管道的数据速率来定义和组织文件传递管道允许文件传递服务支持早期和后期的接收机设备。
图78A和78B示出了文件传递管道还可以被改变大小并被组织，以应对时间分集考虑。例如，可以对多路复用中的文件传递管道进行组织，以提供用于传送大文件的高带宽 /高容量文件传递管道，以及用于传送较小文件的低带宽/低容量文件传递管道。在请求广播系统周期性地传输小的紧急文件时，这种组织方式会是有用处的。在多个实施例中，文件传递管道可以定义为图78A所示的“胖”文件传递管道，或者图78B所示的“瘦”文件传递管道。通过在多路复用内定义“瘦”文件传递管道，广播网络可以在接收到这种紧急文件时接纳它们，而不会存在延迟或者中断在“胖”文件传递管道上传送的大文件发送。
还可以对文件传递管道进行组织，以便将不同类型的文件业务分离开，例如用以支持一个管道上的低等待时间的小文件，同时在分离的管道上传送高等待时间的大文件， 如图79A-79G所示的。在多个实施例中，文件传递管道可以被配置为支持用于传输信息的 “对等待时间敏感的”数据广播。在多个实施例中，系统可以被配置为，使得其提供对所有数据广播传输的一致的处理。在多个实施例中，可以将低等待时间的业务聚集在一个或多个传递管道上。在多个实施例中，可以使用多个BSM，以便支持多个预置和动态的等待时间目标。在多个实施例中，应用可以在传输对等待时间敏感的数据之前实施前向纠错(FEC)保护。
图79A示出了可以定义文件传递管道以支持不同的特定等待时间要求，例如分别为具有15分钟、一分钟和30秒等待时间限制的文件定义分开的文件传递管道。将文件提供给特定文件传递管道也可以是基于优先级的。例如，图78A-B和79A示出了一些文件传递管道可以专用于低等待时间(即，紧急的)应用文件，而其它文件传递管道可以专用于传48送中等到高等待时间(即，非紧急的)应用文件。
图79B示出了可以按照流或集中地从多路复用中为实时(RT)内容分配带宽。可以为对等待时间容忍的内容分配在一组FD管道(FD管道I 一 2)上的集中带宽，其中该组FD 管道在不同的对等待时间容忍的数据广播流之间共享。对等待时间敏感的内容可以在专用于相应的对等待时间敏感的数据广播流的IPDS流(IPDS流I 一 4)上发送。由于管道带宽会受到设备限制的约束，因此可以基于峰值和平均数据速率以及突发大小要求来为对等待时间敏感的内容分配带宽。这在图79C中示出，其显示了集中带宽可以基于峰值(Bwpeak)和平均(Bwavs)数据速率以及突发大小要求。然而，在某些情况下，可能难以基于峰值(Bwpeak) 和平均(Bwavs)数据速率来估计最佳集中带宽。例如，如果估计过于保守，则所丢失的过多带宽就难以恢复。如果带宽分配策略过于激进，则在不同流上的同步突发会导致分组丢失或者影响实时发送。因此，在多个实施例中，可以使用数据广播传递架构(DDF)将集中的对等待时间敏感的流在管道中“分组化”和流化，其中数据广播传递架构可以经由BSM公布数据广播。例如，图79D示出了用于传输对等待时间容忍和敏感的内容的统一系统，其中，将对等待时间敏感的数据、对等待时间容忍的数据和实时数据分开并在相应的流上发送。图 79D示出了可以在一组管道上(对等待时间敏感的数据管道I 一 2)上发送对等待时间敏感的数据，而可以在另一组管道(对等待时间容忍的数据管道1-2)上发送对等待时间容忍的数据。
如上所述，在多个实施例中，可以经由BSM公布数据广播。在多个实施例中，BSM可以仅在较小的广播调度周期上( bsp 30秒到5分钟)(BSP通常是15分钟)公布调度信息。 在多个实施例中，多个调度周期可以用于支持应对不同的等待时间要求。这提高了用于低等待时间数据的电池效率，并提供了数据变化的大得多的周期(例如，不必每秒监视一次系统)。此外，对于具有低等待时间(30 +秒)的CBR流数据，数据的分组化允许系统不必每秒监视一次数据流。
图79E示出了用于传输对等待时间容忍和敏感的内容的另一个统一系统。图79E 示出了可以为对等待时间容忍和敏感的内容的统一传输增加多个级别的调度广播粒度并进行分层化。例如，在第一级中，广播调度周期可以指定长期调度周期。这些长期调度周期可以是5分钟的倍数。在一个实施例中，长期调度周期的长度可以是15分钟。在多个实施例中，可以为可以容忍超过15分钟的等待时间的应用指定长期调度周期。在第二级中，可以使用中等调度周期。这个中等调度周期可以与IAF监视周期相同。在多个实施例中，中等调度周期可以是比长期调度周期短的任何持续时间。例如，在一个实施例中，中等调度周期的长度可以是5分钟，并用于适应具有5分钟BSP等待时间约束的应用。图79E还示出了，除了第一和第二级以外，在多个实施例中，除了长期和中等调度周期以外还可以使用多个短期调度周期。这些短期调度周期可以比IAF监视周期小得多(30秒一 5分钟)，并可以被定义来支持低等待时间(30秒一 5分钟)数据。
图79F不出了用于传输对等待时间容忍和敏感的内容的再另一个统一系统。图 79F示出了，在支持多个短期调度周期时，BSF可以传送多个逻辑BSM。每一个BSM都可以描述覆盖了特定目标等待时间的调度，并且每一个BSM都可以传送用以指示下一次何时更新 BSM的下一个监视时间。在一个实施例中，BSM的数量和周期可以由应用配置并驱动。在多个实施例中，在周期变化时可以更频繁地发送BSM，并且此后可以不太频繁地发送BSM。在多个实施例中，设备应用可以请求按照期望的等待时间进行监视。例如，图79G示出了设备 /服务器数据广播应用可以知道等待时间要求，并且数据广播传递架构可以将传输/捕获请求映射到满足等待时间要求的BSM周期。在多个实施例中，设备数据广播传递架构(DDF) 可以按照满足应用的等待时间请求的最低更新周期来监视BSM。
图80示出了还可以对文件传递管道进行组织，以使得发送资源(即，管道)专用于特定内容提供方和/或无线网络运营商，以使得这些组织方式能够平衡广播网络的传输服务。例如，图80示出了在一个管道中总是传送来自给定内容提供方和/或无线网络运营商的文件(例如，eID_l到eID_4)的内容，不竞争其它管道的使用。
文件传递管道可以由一组管道流ID来定义，其标识用于在逻辑文件传递管道上传输文件的实际发送流。图81A到81C示出了用于文件传递管道的三个可替换的组织方式。 例如，如图8IA所示的，文件传递管道流ID可以专用于特定应用或服务(例如，每一个应用可以具有单独的管道流ID)。对这种服务的接入可以局限于对这种应用或服务的订购，并且可以借助有条件接入解决方案来保护对该文件传递管道流的接入。在多个实施例中，可以借助诸如系统信息发送之类的独立机制来进行有条件接入解决方案的专用资源的应用或服务发现。例如，在一个实施例中，广播调度消息可以描述用于每一个发送的流ID。
作为另一个实例，图81B示出了一种实现方式，在该实现方式中，可以在未受订购的不同应用或服务之间共享一些流，以使得有条件接入解决方案保护不是必需的，且无需基于系统信息的服务发现(例如，对于不同应用存在单个/共享的管道流ID)。这种应用无需专用流ID分配，并且因此可以在对文件传递管道的时分复用上共享相同的流ID。
作为第三实例，图18C示出了一种组织方式，在该组织方式中，文件摄取系统上的文件传递管道调度算法可以被配置具有同时调度不同文件的额外灵活性，其中以较低的数据速率发送较小的文件，只要不超过集中型资源就无需中断较大文件的发送，如图82A/B 中所示的。就是说，可以使用不同的和独立的管道流ID，以便可以在同一管道中调度多个小文件，作为避免中断较大文件的发送的一种方式。在这个实现方式中，文件传递管道可以被配置具有多个流ID，以适应多个同时发送。
由于引入多个文件传递管道，会发生接收机设备上文件的同时检测的问题。这在图78A/B、79A和80中示出了，其示出了一种系统，在该系统中，可以利用多个管道，并且因此可以同时发送多个文件，每一个文件经由一条管道(假定设备有权使用来自使用不同管道的不同提供方的内容)。
图82A和82B示出了用以处理小文件连同大文件一起的发送的备选方案。如前提及的，具有文件传递管道的广播网络将需要一个方法来将文件关联到管道，并调度文件广播。文件摄取系统调度器可以使用配置和输入参数的组合来将文件关联到管道，并调度它们的发送。在多个实施例中，可以以到管道的位置所及范围(即，广播管道文件的位置)来配置管道。在多个实施例中，应用/服务可以具有地理上的方面。例如，使用文件系统提取的天气应用可以将目录中的文件名称定义为/weaApp/East/NYC/或/weaApp/West/LA/。在此情况下，用于天气应用的文件的配置可以是将在美国的东部广播的广域多路复用上管道 X上的/weaApp/East/,以及将在美国的西部广播的广域多路复用上管道Y上的/weaApp/ West。在多个实施例中，可以存在优先级管道(例如，用于低等待时间应用文件)。在多个实施例中，多个管道可以以不同文件大小和等待时间要求(例如，15分钟、I分钟和30秒)为目标。在多个实施例中，文件摄取系统可以有权使用管道配置信息。在多个实施例中，一旦接收到要广播的文件，文件摄取系统就可以在基于所配置的地理所及范围和策略的适当管道上调度文件；或者在最适合于确保等待时间要求的管道上调度文件。在多个实施例中，文件摄取系统可以根据文件的大小来调度文件。例如，文件摄取系统可以挑选低带宽管道，或者选择以低数据速率调度发送的胖管道上的流ID。在一个实施例中，文件摄取系统可以分割在胖管道上的较大文件的发送，如图82A和82B所示的。这个分开的发送可以将用于文件的发送窗口分割到由其他文件的发送所分隔的几个分开的窗口中，如图82B中所示的。在多个实施例中，BSM可以包括描述这种分开的发送的特征和信息。在多个实施例中，接收机设备可以被配置为在不同的分开的窗口中收集文件。
因此，在多个实施例中，文件摄取系统可以包括调度器，其试图基于配置和输入参数的组合(例如，可以同时调度不同无线运营商的设备可以利用的文件)来同时地调度文件 (在不同管道中)。可替换地，调度器可以计划可以同时发送的文件的多个传输，作为允许已选择接收在第一发送中的多个并发文件之一的设备仍能够接收在第二发送上的其他文件的一个方式。
在多个实施例中，文件摄取系统可以基于每一个文件的数据管道的广播所及区域 (即，可以接收文件传递管道的地理区域)来配置文件。就是说，利用这些文件传递能力的应用和服务可以具有多个地理上的考虑。例如，使用文件系统提取的天气应用可以定义用以指示预报文件所相关的区域的文件名称和目录。这样，基于文件传递管道是否会将文件传递到所指示区域，文件摄取系统可以使用天气应用文件名称来将每一个天气应用文件配置给特定的文件传递管道。例如，可以将具有文件目录字符串“/weaApp/East/NYC/”的文件引导到将在美国东部广播的广域多路复用内的文件传递管道，而将具有文件目录字符串“/ weaApp/West/LA/”的文件引导到将在美国西部广播的广域多路复用内的文件传递管道。
还可以使用策略考虑来定义如何将文件配置给特定的一组文件传递管道。例如，视频剪辑传递应用可以根据视频剪辑的源而将其文件组织到文件目录中，例如，用于ABC频道ABC和Disney上的视频剪辑的文件的“/clipApp/ABC/abc/”和“/clipApp/ ABC/Disney/”，以及用于ESPN频道上的视频剪辑的文件的“/clipApp/ESPN/espn/”和 “clipApp/ESPN/eSpn2/”。如此进行组织，策略考虑可以指示应在文件传递管道I上配置来自ABC的文件，而应在文件传递管道2上配置ESPN视频剪辑文件。
文件到特定文件传递管道的配置也可以基于时间分集要求。例如，可以多次发送小文件，并且在重传之间具有一定的时间间隔，从而实现较高的接收可靠性，或者以较低数据速率在较长时间段上发送小文件。
在多个实施例中，文件摄取系统可以有权使用文件传递管道配置信息。在经由广播网络接收到要传输的文件后，文件摄取系统可以基于地理所及范围和策略考虑，来将接收到的文件配置给适当的文件传递管道。另外或者可替换地，文件摄取系统可以将接收到的文件配置给文件传递管道，以确保满足为接收到的文件所指定的等待时间要求。另外或者可替换地，在图81C中示出了，文件摄取系统可以根据文件的大小、挑选低带宽管道、或者选择高带宽(“胖”)文件传递管道上的流ID并指定低数据速率发送，来将接收到的文件配置给文件传递管道。
另外，文件摄取系统可以调度大文件以分开的方式发送，如图82B所示的，以使得51可以将大文件分割到多个分开的发送窗口中，从而使得可以在其间发送其他较小文件。与分开的发送窗口的组织方式有关的信息可以包括在广播调度消息中，以使得接收机设备能够从不同的分开的广播窗口接收文件部分，并在接收后将这些文件部分再组合为原始文件。可以使用文件传递管道数据速率和每一个文件的大小来为在特定文件传递管道内调度的所有文件定义广播窗口。
图83A示出了根据实施例的可以在文件摄取系统内实现的、用以将接收到的文件分配给文件传递管道的示例性方法8300。在方法8300的步骤8302中，文件摄取系统可以确定文件传递管道标识符，例如带宽特性(例如，数据速率)和策略限制。在步骤8304中，文件摄取系统可以使用与可用文件传递管道有关的这个知识来将接收的文件分配给特定文件传递管道。如上所述，文件到传递管道的这个分配可以基于多个覆盖区域(例如，用以确保将文件传递到包含目标接收机设备的地理区域)、文件等待时间限制(即，文件急迫性)、 文件大小、管道数据速率、以及其他策略考虑。一旦已经将文件分配给特定传递管道，文件摄取系统就可以在步骤8306中，根据所请求的传输质量，为由每一个文件传递管道传送的文件确定广播调度(即，广播窗口)。如上所述，广播调度可以基于用于每一个文件的广播持续时间，其可以通过将文件大小除以文件传递管道数据速率来确定。可以基于文件的相对急迫性来调度文件在广播调度周期内广播，例如通过在周期内较早地广播更紧急的文件。 在步骤8308中，文件摄取服务可以将文件传递管道ID连同文件标识符、文件广播窗口、文件参数等一起包含在广播调度消息中。在步骤8310中，文件摄取系统可以指示广播系统在广播调度流中广播广播调度消息，并且在步 骤8312中，使得广播系统开始根据在广播调度消息中指定的广播窗口、经由所指示的文件传递管道发送文件。
图83B示出了用于支持调度文件在多个管道上发送的调度器的示例性方法8350。 这个调度器选择性地允许根据作为文件摄取过程的一部分在文件摄取时所提供的调度约束条件，在多个管道上同时发送文件。该多管道调度器可以应对多个重叠情况，包括在多个管道上调度文件的单个实例的非重叠情形、不同文件的两个实例重叠的重叠多文件、以及同一文件的两个实例重叠的重叠单文件情况，该重叠单文件情况可以用于推送具有紧迫的发送最后期限的文件，或者用于在不同线路(lane)中发送同一文件的不同实例。参考图 83B，在步骤8352中，多管道调度器可以在开始时间计算一组剩余文件(R)，从剩余文件中减去所删除的文件，在剩余文件中加入额外的文件，计算目录文件并将它们包含在剩余文件中。
调度器可以在步骤8354中为要调度的每一个目录和文件的第一个实例计算调度窗口(SW)。在步骤8356中，调度器随后可以选择具有时间上最早的调度窗口的可用文件实例K，从而打破关联性以支持目录信息文件。在步骤8358中，调度器随后可以产生虚幻广播窗口，并针对当前调度约束条件解码持续时间窗口。在步骤8360中，调度器可以基于图 83B中所示的计算来选择单个文件。在步骤8362中，调度器随后可以选择具有最早可调度时间的线路或管道。在这么做时，其可以通过选取在调度窗口开始时间与先前调度的文件之间具有最小间隙的线路，来在同等条件的线路中进行选择。如果这会产生关联性，调度器就可以随机挑选一个。
在确定步骤8364中，调度器可以确定广播窗口是否与现有广播窗口重叠，并解码持续时间(如果有的话)。如果是(即，确定步骤8364 =“是”)，则调度器可以在步骤8366中使文件j的第k个实例的解码窗口和时间前进到重叠传递窗口的时间，并返回步骤8360中挑选文件j的下一个实例k。如果广播窗口不存在重叠(即，确定步骤8364 =“否”)，则调度器可以在步骤8368中更新可用的文件实例，并在确定步骤8370中确定文件j的第k个实例的解码窗口和时间是否在任何可用的文件实例的调度窗口之外。如果是(即，确定步骤 8370 =“是”)，则在步骤8372中，调度器可以放弃变化，并指示调度失败。如果不是(即，确定步骤8370 = “否”)，则在步骤8374中，调度器可以确定文件j的当前实例是否小于文件目录中直接实例的数量。如果不是(即，确定步骤8374 = “否”)，则在步骤8380中，调度器可以从剩余文件中去除该文件。在确定步骤8382中，调度器可以确定剩余文件是否为空。 如果剩余文件现在为空(即，确定步骤8382 =“是”)，则在步骤8384中，调度器可以实施变化并指示调度成功。如果剩余文件不为空(即，确定步骤8382 =“否”)，则调度器可以返回到步骤8356，以选择具有最早调度窗口结束时间的可用文件实例。
如果调度器确定实例K小于文件目录的实例数量(即，确定步骤8374 = “是”)，则在步骤8376中，调度器可以将当前实例设定为一，并分割文件，调整其他片段最后期限。在返回到步骤8356以选择具有最早调度窗口和时间的可用文件实例之前，在步骤8378中，所述调度随后为文件j的第K个实例计算所调度的时间并计算调度窗口。
文件内容提供方可以使用sendFileRequest (发送文件请求)操作来向文件摄取系统提供文件。sendFileRequest操作可以包括用以指示为发送而提交的文件(例如，借助 fileFetchlnfo (文件读取信息))的机制，以及用以为每一个文件或文件组定义不同传递标准或发送要求的机制。可以基于内容URL来确定文件，内容URL提供可以从中取得要广播的文件的位置。文件的确定还可以确定用于进一步将内容分配给被摄取的文件或者与之相关联的额外参数，这些额外参数例如用于指示在应用目录结构的文件的目录的文件名称 (例如，/itv/res/svc_5/fl. jpg),以及可以提供表征文件的参数的属性列表(例如，风格= 戏剧，性别=男；年龄=20-30等)。可以在广播调度消息中传输这些额外的参数，以允许在接收机设备上实施的接收机应用确定应该捕获的被广播文件。
属性列表是在cat. xml中传送还是直接在广播调度消息中传送是根据提交文件的应用希望什么服务来确定的。如果提交应用优选管理目录文件以便向用户提供目录文件以使得接收机设备能够更好地选择要下载的文件，则应用可以管理该目录文件并在接收机设备中(例如，在意图接收该文件的设备应用中)提供有关于如何使用目录的逻辑。如果应用需要具有用于性能较差的接收机设备的简单实现方式，或者接收机设备未被配置具有相应的设备应用，则其可以依赖于广播调度消息，使用上述的方法来传送属性列表。
图84示出了可以在适合于实施多个实施例的接收机设备10内实现的功能模块。 可以在类似于图84所示的软件体系结构8400中组织接收机设备10的软件模块。广播发送可以由接收机设备物理层接收，并由诸如FLO传输网络模块8401的广播接收机模块处理。 由文件传输网络8401接收的视频和音频流可以由媒体接收机模块(未示出)处理。在文件传输网络8401上接收的文件传送流可以提供给文件管理器模块44，并由其处理，文件管理器模块44运行以接收文件分组，并将文件分组引导到设备软件体系结构8400内的适当模块和应用。开销数据流可以传送到开销数据获取模块8408，开销数据获取模块8408运行以处理开销数据分组，并将接收的元数据和开销数据引导到设备系统体系结构8400内的适当模块。服务SI获取模块8407可以从开销数据流中获取服务SI数据，并将这个信息转发到文件传递系统模块44和开销数据获取模块8408。依据接收的服务SI数据，文件传递系统模块44可以为传送交互性资源数据的文件数据流确定流ID。依据接收的服务SI数据， 开销数据获取模块8408可以确定传送交互性信令数据的信令流。为了支持交互性事件，设备软件体系结构8400可以包括文件接收服务8402，其充当在用户接口(Π )应用8404与文件传输网络8401之间的接口，用于接收、管理和存储交互性事件。可以将交互性服务8402 与UI应用8404 —起组织为交互式应用8502。用户接口应用模块8404可以包括多个交互式应用和一个用户代理。
在多个实施例中，文件传递服务模块44可以向设备应用提供多个服务。单个文件捕获服务可以允许设备应用请求对单个文件的捕获。为此，设备应用为文件传递服务模块 44提供应用专用文件名称,例如在像singeCapture (/itv/res/svc_5/f2. jpg)(单个捕获 (/itv/res/svc_5/f2. jpg))的请求中。
如上所述，可以由文件传递服务模块44提供的另一个服务是连续文件捕获服务， 其允许设备应用请求对单个文件名称的多个更新或者对给定目录下的所有文件的连续捕获。设备应用可以在全部捕获请求(capture allrequest)中指定应用专用文件名称，以指示应接收指定文件的所有更新。这个服务的一般使用会是追踪诸如目录文件之类的应用开销文件中的变化。例如，为了接收交互式应用目录文件的所有更新，应用可以发出 captureAll (/itv/sig/cat. xml)请求。当应用希望接收在一个应用专用目录中当前没有存储在接收机设备上的所有文件时，设备应用可以指定该应用专 用目录。在大多数情况下，这会是预期目录下的所有新文件。例如，在天气应用中，这个请求会是captureAll (/weaApp/ NYC/)，以请求下载具有NYC子目录文件名称的所有文件。与单个文件捕获服务不同，全部捕获服务持续监视所请求文件的新传输或者指定目录下的新文件。这个服务取决于文件传输网络不能通知何时有新文件可用于接收或者何时有文件的新版本可用。可以以新文件名称或者具有包括在文件元数据中的更新的版本编号的相同文件名称的形式，在广播调度消息中提供这种信息。接收机设备上的文件传递服务模块44可以被配置为保持追踪存储在存储器中的文件的版本，并追踪在广播调度消息中提供的版本信息，以避免多次接收相同文件，因为这样会不必要地耗尽设备电池。
如图85所示，诸如服务图标应用8501和交互式应用8502以及多呈现列表视图 (MPV)应用8503之类的设备应用可以指定要获取的文件以及要执行的文件获取类型(即， 捕获一次或者自动捕获)。为了确定文件名称或文件扩展名，设备应用可以从信道系统信息 (SD8504和/或服务SI8505、8506接收这种信息，其是作为部分开销广播发送的组成部分而提供的。一些设备应用还可以由订购管理器8507来支持，订购管理器8507可以是用于管理对由多个设备应用订购的广播服务的注册和订购的应用。
可以在文件传递服务模块44中提供的第三个服务是取消服务，其允许设备应用取消对文件的单个捕获(singleCapture)或者取消对文件或目录的连续捕获 (captureAlI)。当启用时，所述取消服务使文件传递服务模块44停止对被取消的与原始请求相关联的文件的获取。
图86示出了根据实施例的示例性数据图表8600，其可以用于为广播而调度的文件的目录中的文件。如图86所示，目录文件(catalog file)8601可以包括文件信息8602， 文件信息8602自身可以包括文件名称数据字段8603以及可选的过滤属性数据字段8604，以及可选的应用参数数据字段8605。文件名称数据字段8604可以包括完全受限的提取文件名称，诸如包括根目录和子目录的文件名称字符串。可选的过滤属性数据字段8604可以包括对过滤有用的额外信息，诸如子目录、文件类型或文件扩展名，或者其他适合的文件描述参数。可选的应用参数数据字段8605可以包括与要使用所述数据文件的应用有关的信息，其对于确定是否应接收各个文件是有用的。
为了提供文件捕获服务，文件传递服务模块44使用在广播调度消息中提供的信息来确定接收哪些文件及何时接收这些文件。图87A示出了接收机设备的处理器或集成接收机/处理器芯片可以响应于从设备应用接收到singleCapture服务文件下载请求而实施的实施例方法8700a。在方法8700a的步骤8702中，接收机设备的处理器可以从设备应用 (即，运行在接收机设备的处理器内的应用)接收文件下载请求。
如上所述，广播调度消息包括将被广播的文件的名称，以及文件传递服务模块44 为了选择要接收的文件所需的信息。所以在步骤8704中，在处理器内实现的文件传递设备模块44监视接收的广播调度消息。步骤8704可以包括暂时启动接收机设备的接收机电路，其时间长得足以从开销流接收到广播调度消息，以及处理接收到的广播调度消息以获得其包括的信息。在步骤8706中，处理器可以获得要广播的一个或多个文件的名称(包括其文件扩展名)。如上所述，作为文件扩展名的这种文件名称可以被包括在广播调度消息的广播调度记录(BSR)内。在步骤8708中，处理器可以将从广播调度消息获得的文件名称或文件扩展名字符串与在步骤8702中提供的由请求设备应用所指定的文件名称或文件扩展名相比较。在确定步骤8710中，处理器可以确定在广播调度消息中指定的文件名称或文件扩展名与设备应用所请求的文件名称或文件扩展名之间是否存在匹配。如果不存在匹配 (即，确定步骤8710 =“否”)，则在步骤8711中，处理器就可以等待直到在广播调度消息中所指示的将更新广播调度消息的时间。如上所述，可以重复广播相同的广播调度消息直到更新时间为止。通过在广播调度消息中指定何时将广播更新的消息，接收机设备可以通过保持其接收机电路停用直到发送新的广播调度消息为止，来节省电池功率。在当前时间等于所指示的广播调度消息更新时间时，处理器可以返回到步骤8704，以接收并处理更新的广播调度消息。
如果处理器确定在广播调度消息中指定的文件名称或文件扩展名与由设备应用在步骤8702中指定的文件名称或文件扩展名匹配(即，确定步骤8710 = “是”)，则处理器可以调度对所匹配文件的接收。这可以通过以下来完成在步骤8712中从广播调度消息获得关于匹配的文件的广播时间和接收信息(例如，流ID、使用IP地址的IP流标识符、和/或 UDP端口号)，并在步骤8714中基于广播时间调度对匹配的文件的接收。调度对匹配的文件的接收可以在确定步骤8716中完成，例如，通过在存储器寄存器中存储所获得的广播时间，经常将该广播时间与当前时间相比较，以便在当前时间与存储在存储器中的时间相匹配时产生中断，以启动文件接收例程。在当前时间与调度的广播时间不匹配时(即，确定步骤8716 =“否”)，处理器可以执行步骤8711，等待更新广播调度消息的时间，这是因为广播调度消息的接收处理(如上参照步骤8704到8711所说明的)可以以并行方式继续。就在调度广播时间之前(即，在确定步骤8716 =“是”时)，在步骤8718中，处理器可以唤醒接收机设备的接收机电路，并在步骤8720中从公布的传输流接收所选择的文件。作为步骤8720 的组成部分，如上所述，在处理器内运行的文件传递服务模块44可以在存储器中存储接收的文件，并且在一些实施例中，注明其版本号。在步骤8722中，在处理器内运行的文件传递服务模块44可以使用上述的过程将接收到的满足原始应用请求的文件传送到发出请求的应用。在接收文件后，处理器可以停用接收机电路并返回步骤8711，以等待广播调度消息将被更新的时间。
当设备应用使用singleCapture服务请求文件下载时，可以由设备应用在步骤 8702中指定一个或多个特定文件名称。一旦接收到指定的文件并存储在存储器和/或传送到请求设备应用，处理器就可以取消该文件下载请求，以便不会接收相同文件的后续广播。
当在由提交要传输的文件的前端侧应用所提供的目录文件中指示了与经由广播网络传输的文件有关的信息时，该目录文件可以包括在图86所示的数据图表中所指示的信息。使用在这个目录文件中提供的信息，设备应用可以基于使用文件系统提取时的文件的文件名称，和/或可以与每一个文件相关联的过滤属性，来指定要捕获的文件。接收机设备上的应用随后可以使用接收的目录文件结合应用已知的信息(诸如接收机设备用户的性别和年龄)，来选择其属性与接收机设备或用户的属性匹配的下载文件。由于文件名称可以包括在目录文件中，因此设备应用可以在singleCapture操作中使用文件的文件名称来请求对该文件的捕获。
图87B示出了可以在接收机设备的处理器内实现以完成全部捕获服务的实施例方法8700b。当设备应用使用连续捕获请求服务(例如，autoCapture(itv/sig/cat. xml)或 autoCapture(itv:l))请求文件下载，以便持续接收对特定文件的所有更新时，可以执行以上参考图87A说明的操作，不同之处在于在接收到匹配的文件并存储在存储器后，不自动取消该文件下载请求。由于该文件下载请求保持有效，因此处理器可以继续接收与文件扩展名标准相匹配的文件。为了通过避免冗余文件的接收(由于文件可能被多次广播以确保可靠的接收)而节省电池功率，处理器可以执行额外的确定步骤8713，该步骤将在广播调度消息中指定的所匹配文件的文件名称或版本号与存储器中存储的文件名称和/或版本号相比较。如果所匹配文件具有与存储器中存储的文件相同的文件名称、文件ID/元素ID 或版本号(即，确定步骤8713 =“是”)，就无需再次接收该文件，所以处理器可以进行步骤 8711，等待直到更新广播调度消息为止。然而，如果在广播调度消息中指示的所匹配文件的文件名称、文件ID/元素ID或版本号具有不同于存储器中存储的文件名称或版本号(S卩，确定步骤8713 =“否”)，则处理器就可以通过进行以上参考图87A说明的步骤8712到8722 来进行调度对所确定的文件的接收。由于在接收到所匹配的文件时不自动取消文件传递请求，因此在处理器内运行的文件传递服务模块44可以继续监视广播调度消息并捕获所有所匹配的文件的更新，只要该请求保持有效。
将文件名称提取用于经由广播系统、单播网络或广播和单播网络的组合的文件传递实现了能够简单部署的文件传递服务。使用这种通信网络的应用更易于开发，因为可以利用常见的文件扩展名概念。通过提供前端系统用于摄取文件(例如，文件摄取系统)和命名要广播的文件作为文件系统中的路径的组成部分，可以在现有广播系统内实现多个实施例。文件摄取系统提供用于摄取文件的接口，调度文件传输时机(如果通过广播网络发送)， 并经由诸如广播网络中的广播调度消息开销流的某种解决方案专用信令机制向设备公布可用的文件。在接收机设备内可以实现文件传递服务模块(例如在软件更新中)，以便理解前端信令，并接收关于捕获广播文件的设备应用请求，以及维护适当的状态信息以避免重复文件接收和检测文件更新。在这个系统中，由于应用仅需获知其根目录和应用专用子目录组织形式来指定要从广播服务接收的文件，因此简化了设备应用开发。应用于是可以在不要求进一步的发现机制或诸如系统信息的广播系统的知识的情况下，请求捕获文件。可以借助注册过程或通过应用到文件的传递架构接口或API，来做出该文件捕获请求。对于应用开发者，这个文件扩展名范例类似于请求访问文件系统上的文件，或者经由如FTP的文件传送协议读取文件。
以广播调度消息形式发送开销信息的广播文件传输网络向接收设备提供与将要广播的文件有关的信息，以及用以将上下文关联到每一个文件的额外的信息(例如，应用目录空间上的目录名称，或者属性特性的列表等)。这种上下文信息可以由接收设备用于从所公布的不同文件广播中选择接收与位于接收机设备上的服务或应用相关的那些文件。在广播调度消息中提供的文件ID和/或元素ID信息还可以允许接收机设备确定文件是新文件还是对先前接收的文件的更新。该广播调度消息结构支持描述应用文件名称或属性字符串的别名。该广播调度消息结构还允许指示所传输的文件的类型，例如，单个文件相对于文件包。使用在广播调度消息中或者可选地在文件传递目录系统中可利用的信息，接收机设备可以确定接收(即，过滤和选择)期望接收的文件，以使得接收机电路仅被启动来接收对位于接收机设备上的应用有用的那些文件。
文件摄取系统通过使得文件内容提供方能够指示并表征要通过广播网络传输的文件，并定义用来指定需要如何及时地或如何可靠地通过共享且常常是稀有的广播资源传送文件的发送要求，实现了对所述文件的摄取。时间线或接收机电池约束条件可以要求广播系统一次仅公布少量的调度信息。文件摄取系统的调度功能可以通过在新文件发送要求与先前摄取的文件的文件发送要求之间进行平衡，来满足新文件发送要求。此外，文件摄取系统可以被配置为，确保使得采用诸如规律性更新的广播调度消息形式的刷新调度信息的流可以及时地用于接收机设备，并且按照公布的调度来发送文件。
为了实现在有限广播资源内文件的有效发送，可以将文件传递组织到文件传递管道中，作为用以概念性捕获用于广播网络上文件传输的资源分配的机制。可以实施不同策略以调整多个管道配置和供应，以便在应用使用本文所述的文件系统提取时将应用文件绑定到管道。调度算法可以利用不同管道配置来在广播网络的带宽和运行条件内满足应用传递要求。
不同实施例提供了针对广播、接收和处理文件的多个优点和有用的特征。这些特征包括用于在通过广播分发网络传递文件时使用文件系统提取来命名文件的机制、用于当提交文件以通过广播传递系统摄取和传输时作为指示文件的一个手段来通知文件名称的机制、用于借助文件系统提取从描述可用文件的广播传递系统请求文件的下载的机制、 以及用于基于与应用相关的目录和子目录将文件绑定到文件传递应用的机制。
文件传递架构(FDF)提供一个灵活的机制来在后台中向设备传递文件。其具有以下关键设计目标灵活的文件广播调度-文件广播窗口可以被动态地调度并通知给设备； 可扩展到大量应用-其可以将来自多个应用的数据多路复用到同一流中，以显著减小系统中数据流的数量；以及功率效率-设备仅在选择性接收用户感兴趣的数据时消耗能量。
广播调度消息提供了用来公布对通过广播网络发送文件的调度的机制，其借助文件名称、属性和应用/服务标识符将文件与服务或应用相关联。广播调度消息还可以指示被广播的文件是新的、更新的还是重复的文件，以使得能够配置接收机设备以捕获文件的单个或者所有更新的版本。除了广播窗口和在广播文件时可能的多个实例的指示以外，广播调度消息可以通知能够在其中接收到文件的传输流。广播调度消息还可以指示何时用新的调度信息来更新广播调度消息。广播调度消息还可以描述用于被传输的文件的应用/服务ID和别名信息。广播调度消息可以一次仅公布文件广播调度信息的未改变部分，以便使内容刷新与对接收机设备的电池影响保持平衡。
多个实施例还提供了一种机制，其使得接收机设备能够发现广播网络传输技术、 所用的频率、传输在给定频率中的部分、以及在该技术与频率中用来为在通过广播技术发送的文件提供传递调度信息的传输流。接收机设备可以利用所公布的、在广播调度消息中提供的调度，基于文件相关联的服务或应用以及文件是新的还是对先前接收的文件的更新，来选择要接收的文件。
多个实施例可以包括使广播发送资源专用于不同传递和不同地理覆盖要求的文件的多路复用传输、划分可用于在不同文件传递管道上进行文件传输的资源，以便应对不同传递要求、不同的接收机约束条件、或者提供业务分割。可以将不同类的文件绑定到一组文件传递管道，以便满足不同传递要求、不同接收机约束条件、或提供业务分割。可以对用来传送不同文件的传输流进行多路复用，以便最大限度地利用专用资源进行文件传输。 传输流可以进一步被配置为实现通过不同的不连续发送来传输文件，以允许较小文件的交织。文件的类可以被绑定到一组资源，以便满足不同传递要求、不同接收机约束条件或提供业务分割。可以基于文件传递要求、可用文件传递管道、文件的类到一组资源的绑定来将文件分配给文件传递管道。发送方上的应用和服务可以使用广播系统的文件传递服务来构造开销文件、目录文件，其列出了应用使之可用于广播或其他(例如，单播)传输的所有文件以及应用专用属性。
文件摄取系统可以连同其他应用专用文件一起从文件内容提供方接收并传输目录文件，并且接收机设备可以被配置为基于在这种目录文件中的信息选择要接收的文件。 位于接收机设备上的应用可以使用更新的目录文件，基于在表征目录中列出的每一个文件的可用属性上所施加的应用专用逻辑，来确定感兴趣的文件。
图88是适合于与任意实施例一起使用的接收机设备的系统方框图。典型的接收机设备8800可以包括处理器8801，其耦合到内部存储器8802、显示器8803和扬声器8854。 另外，接收机设备8800可以包括天线8804，用于发送和接收电磁辐射，天线8804可以连接到被耦合到处理器8801的无线数据链路和/或蜂窝电话接收机8805以及耦合到处理器 8801的移动多媒体广播接收机8806。接收机设备8800通常还包括用于接收用户输入的菜单选择按钮或摇臂开关8808。
用于接收和处理交互式事件信令消息的多个实施例方法可以由多媒体广播接收机8824以及处理器8801及存储器8802的组成部分来执行。在多媒体广播接收机8824内的或耦合到多媒体广播接收机8824的可替换地专用模块可以执行实施例方法。
上述的广播方上的多个实施例可以在任何各种市场上可购买的服务器设备上实现，诸如图89中所示的服务器8900。这个服务器8900通常包括处理器8901，其耦合到易失性存储器8902和诸如磁盘驱动器8903的大容量非易失性存储器。服务器8900还可以包括耦合到处理器8901的软盘驱动器、紧致盘(⑶)或DVD盘驱动器8906。服务器8900还58可以包括网络接入端口 8904，其耦合到处理器8901，用于与网络8905建立数据连接，网络 8905例如为耦合到其他广播系统计算机和服务器的局域网。
处理器8801和8901可以是任何可编程微处理器、微型计算机或多处理器芯片，其可以由软件指令(应用)来配置以执行各种功能，包括以下说明的多个实施例的功能。在一些移动接收机设备中，可以提供多个处理器8901，例如一个处理器专用于无线通信功能，一个处理器专用于运行其他应用。通常，在访问软件应用并将其载入处理器8801、8901之前， 可以将其存储在内部存储器8802、8902、8903中。处理器8801、8901可以包括足够用来存储应用软件指令的内部存储器。
前述方法说明和过程流程图仅是作为示例性实例而提供的，并非旨在要求或暗示必须以所呈现的顺序来执行多个实施例的步骤。如同本领域技术人员会理解的，可以以任意顺序来执行前述实施例中的步骤的顺序。诸如“此后”、“随后”、“接下来”等的词语并非旨在限制步骤的顺序；这些词语仅仅用于引导读者阅读方法的说明。此外，对权利要求元素的单数方式的任何提及，例如使用冠词“一(a，an)”或“所述(the)”不应解释为将元素限制为单个。
结合本文公开的实施例描述的各种示例性的逻辑块、模块、电路、和算法步骤均可以实现成电子硬件、计算机软件或其组合。为了清楚地表示硬件和软件之间的这种可互换性，上面在其功能方面对各种示例性的组件、块、模块、电路、和步骤进行了总体描述。至于这种功能是实现成硬件还是实现成软件，取决于特定的应用和对整个系统所施加的设计约束条件。熟练的技术人员可以针对每个特定应用，以变通的方式实现所描述的功能，但这种实现方式决策不应理解为导致脱离本发明的范围。
用于实现结合本文公开的实施例描述的各种示例性逻辑、逻辑块、模块和电路的硬件可以以通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列 (FPGA)或者其它可编程逻辑器件、分立的门或晶体管逻辑、分立硬件组件，或者被设计为执行本文所述功能的它们的任何组合来实现或执行。通用处理器可以是微控制器，但可替换地，该处理器可以是任何传统处理器、控制器、微控制器或者状态机。处理器还可以实现为计算设备的组合，例如，DSP和微处理器的组合、多个微处理器、一个或多个微处理器结合 DSP内核，或者任何其它这种结构。可替换地，一些步骤或方法可以由专用于给定功能的电路来执行。
在一个或多个示例性实施例中，所述的功能可以在硬件、软件、固件或其任意组合中实现。如果在软件中实现，则所述功能可以作为一个或多个指令或代码在计算机可读介质上进行存储或传送。本文公开的方法或算法的步骤可以体现在处理器可执行软件模块中，其可以位于实体的非暂时性计算机可读存储介质上。实体的非暂时性计算机可读存储介质可以是可由计算机访问的任意可用介质。示例性地而非限制性地，这种非暂时性计算机可读介质可以包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储器、磁盘存储器或其它磁存储设备或者可用于以指令或数据结构的形式存储预期程序代码并且可由计算机访问的任意其它介质。本文使用的盘片(disk)和盘(disc)包括紧致盘(⑶)、激光盘、光盘、数字多功能盘(DVD)、软盘和蓝光盘，其中盘片常常以磁性方式再现数据，而盘通过激光以光学方式来再现数据。上述介质的组合也包括在非暂时性计算机可读介质的范围内。另外，方法或算法的操作可以作为代码和/或指令的一个或任意组合或者代码集和/或指令集驻留在实59体的非暂时性机器可读机器和/或计算机可读介质上，其可以包含在计算机程序产品中。
提供了对于公开的实施例的以上描述，以使得本领域技术人员能够实现或使用本发明。在不脱离本发明的精神或范围的情况下，本领域技术人员将会容易地获知对这些实施例的各种修改，并且可以将本文定义的一般原理应用于其它实施例。因此，本发明并不旨在限于本文所示的实施例，而应被给予与随后的权利要求和本文公开的原理和新颖特征相一致的最大范围。
权利要求
1.一种用于经由广播通信网络向接收机设备传递文件的方法，包括 从内容提供方接收要传输的文件，所接收的文件具有文件名称并包含与文件内容和通信要求有关的信息； 调度所述所接收的文件，用于经由广播发送内的文件数据流进行发送； 产生广播调度消息，所述广播调度消息指示何时将在广播调度周期内广播文件、与这些文件有关的信息、以及用于每一个文件的被调度广播时间窗口 ； 经由所述广播网络，来广播所产生的广播调度消息；以及 根据在所述广播调度消息内包含的所述被调度广播时间窗口，借助于所述广播网络的所述文件数据流来广播所述所接收的文件。
2.根据权利要求I所述的方法，其中，基于相对急迫性，调度所述所接收的文件用于广播。
3.根据权利要求I所述的方法，其中，在被组织到一个或多个文件传递管道中的发送资源上广播所述所接收的文件。
4.根据权利要求I所述的方法，进一步包括 从在接收机设备内运行的应用接收对于捕获文件的请求，所述请求指定一个或多个接收标准； 在所述接收机设备中接收所述广播调度消息； 在所述接收机设备中针对与所述接收标准相匹配的文件而监视所述广播调度消息； 当与所述接收标准相匹配的文件将被广播时，从所述广播调度消息中确定所述被调度广播时间窗口； 在为所匹配的文件而确定的被调度广播时间窗口，启动所述接收机设备的接收机电路； 基于在所接收的广播调度消息中的文件信息，来选择要接收的文件； 在所述接收机设备中从所述广播发送中接收所选择的文件；以及 将所述所选择的文件传送到运行在所述接收机设备内的发出请求的所述应用。
5.根据权利要求4所述的方法，其中，在所述接收机设备中从所述广播发送中接收所选择的文件进一步包括在所述接收机设备中的存储器中存储版本标识信息，所述版本标识信息标识所接收的文件的版本，所述方法进一步包括 在所述接收机设备中，针对具有指示了正在广播所述所接收的文件的较新或更新版本的版本标识信息的文件而监视所述广播调度消息；及 当所述广播调度消息指示正在广播所述文件的新的或更新的版本时，在所述接收机设备中从所述广播网络接收所请求的文件的更新的版本。
6.根据权利要求4所述的方法，其中，从在接收机设备内运行的应用接收对于捕获文件的请求进一步包括由所述接收机设备接收捕获请求，所述捕获请求采用了对于捕获一次包含被请求文件的文件的命令的形式，或者是作为对于捕获所述文件的所有实例的命令。
7.根据权利要求4所述的方法，其中，所述所产生的广播调度消息进一步指定将更新所述广播调度消息的时间，所述方法进一步包括 在所述广播调度周期内多次广播所述广播调度消息；在接收到所述广播调度消息后，停用所述接收机设备中的接收机电路； 确定当前时间何时等于将更新所述广播调度消息的时间； 在所述当前时间等于将更新所述广播调度消息的时间时，重新启动所述接收机设备中的所述接收机电路 '及 接收更新的广播调度消息。
8.根据权利要求4所述的方法，其中，将所述所选择的文件传送到运行在所述接收机设备内的发出请求的所述应用包括采用不将运行在所述接收机设备内的所述应用暴露给用于向所述接收机设备传递所述文件的传递方法的方式，将所述文件传送到运行在所述接收机设备内的所述应用。
9.根据权利要求4所述的方法，其中 从在接收机设备内运行的应用接收对于捕获文件的请求包括接收指定了文件目录的、对于捕获文件的请求；及 基于在所接收的广播调度消息中的文件信息来选择要接收的文件包括基于与所指定的文件目录相匹配的文件标识符来选择要接收的文件。
10.根据权利要求I所述的方法，其中，广播所产生的广播调度消息包括作为开销传输流的组成部分来广播所述广播调度消息，所述开销传输流提供了关于在给定频率上的文件广播的传递调度信息。
11.根据权利要求I所述的方法，其中，广播所产生的广播调度消息包括作为开销传输流的组成部分来广播所述广播调度消息，所述开销传输流提供了关于在在给定频率上的文件广播的传递调度信息，所述传递调度信息设定由所述广播调度消息公布的传递调度。
12.根据权利要求11所述的方法，其中，所述广播调度消息公布在广播调度周期上所有成功调度的文件。
13.根据权利要求11所述的方法，其中，所述广播调度消息仅公布在广播调度周期上成功调度的文件的一小部分。
14.根据权利要求13所述的方法，进一步包括 确定已经被接受来进行发送、但其传递调度尚未由所述广播调度消息公布的文件；以及 修改已经被接受来进行发送、但其传递调度尚未由所述广播调度消息公布的文件的传递调度信息。
15.根据权利要求3所述的方法，其中，所述内容提供方为每一个所述所接收的文件指定广播传输要求。
16.根据权利要求15所述的方法，进一步包括 借助文件摄取系统摄取所述所接收的文件； 从所述文件摄取系统发送通知，以便向所述广播网络通知所摄取的文件以及所述所摄取的文件的所述广播传输要求；及 在所述文件摄取系统中调度所述所摄取的文件在一个或多个广播发送流上的发送时间。
17.根据权利要求16所述的方法，进一步包括 将两个或更多个所摄取的文件组合到适于在广播发送流上传输的一个或多个传输文件中。
18.根据权利要求16所述的方法，其中，由所述内容提供方指定的每一个所述广播传输要求都包括及时性要求和鲁棒性要求。
19.根据权利要求18所述的方法，其中，所述及时性要求包括所摄取的文件的等待时间容忍程度。
20.根据权利要求18所述的方法，其中，所述鲁棒性要求包括所摄取的文件所需的前向纠错级别。
21.根据权利要求16所述的方法，其中，所述广播调度消息公布对所述所接收的文件的传递调度，所述方法进一步包括 确定已经被调度来在所述广播发送流上进行发送、但尚未由所述广播调度消息公布的文件；及 使用由所述内容提供方指定的所述传输要求，来将新摄取的文件连同所确定的文件一起打包到所述广播发送流中。
22.根据权利要求16所述的方法，进一步包括使用所述文件传递管道将多个不同文件多路复用到每一个所述广播发送流上。
23.根据权利要求22所述的方法，进一步包括采用应对由所述内容提供方指定的应用专用传递要求的方式，在所述文件传递管道中调度所述所摄取的文件，其中，由运行在所述接收机设备上的应用将所述应用专用传递要求发送到所述内容提供方。
24.根据权利要求22所述的方法，进一步包括 将发送方应用组织到类中；及 将应用的所述类映射到特定的文件传递管道。
25.根据权利要求3所述的方法，进一步包括 将每一个所接收的文件与用于唯一地标识该文件并提供版本支持的传输文件ID相关联；及 基于所述传输文件ID，调度每一个文件传递管道以传送所述所接收的文件的序列。
26.根据权利要求3所述的方法，其中，调度每一个文件以便在专用文件传递管道上在广播窗口内广播，每一个广播窗口都具有一大小。
27.根据权利要求26所述的方法，其中，每一个文件传递管道的所述广播窗口的大小是根据该文件传递管道的数据速率与在该文件传递管道上发送的文件的大小来计算的。
28.根据权利要求26所述的方法，其中，每一个文件传递管道的所述广播窗口的大小与在该文件传递管道上发送的文件的大小除以该文件传递管道的数据速率的商成比例。
29.根据权利要求I所述的方法，其中，产生广播调度消息包括产生所述广播调度消息，以描述将在所述广播调度周期内广播的一系列文件，每一个广播调度周期都定义一个表示在所述广播调度消息中包含的、所公布的文件广播调度的数量的量。
30.根据权利要求I所述的方法，其中，至少一个所接收到的文件被调度为在单个广播调度周期中在一个以上广播时间窗口内广播。
31.根据权利要求I所述的方法，其中 产生广播调度消息包括产生所述广播调度消息，以包含关于要在单个广播调度周期内广播的多个文件的接收信息；并且经由所述广播网络广播所产生的广播调度消息包括在同一广播时间窗口中重复发送所述广播调度消息。
32.根据权利要求12所述的方法，其中，在每一个广播超帧中重复广播所述广播调度消息。
33.根据权利要求32所述的方法，其中，在与在所述文件数据流上发送的单个文件相关联的广播调度周期内存在多个广播窗口。
34.根据权利要求33所述的方法，其中，将所述单个文件分割为多个分开的片段，所述多个分开的片段与其他文件交织，并且在所述文件数据流上与其他文件一起发送。
35.根据权利要求I所述的方法，其中，产生广播调度消息包括产生所述广播调度消息，以包括广播调度监视记录，所述广播调度监视记录具有下一监视时间数据字段，所述下一监视时间数据字段指定所述接收机设备应针对更新的广播调度消息而监视广播调度流的下一个时间。
36.根据权利要求I所述的方法，其中，产生广播调度消息包括产生所述广播调度消息，以包括流广播调度记录，所述流广播调度记录描述关于在所述文件数据流上广播的文件的广播调度。
37.根据权利要求I所述的方法，其中，产生广播调度消息包括产生所述广播调度消息，以包括用来指示多个文件的前缀匹配字符串，其指示了与在所述文件数据流上广播的文件相关联的文件内容。
38.根据权利要求I所述的方法，其中，产生广播调度消息包括产生所述广播调度消息，以包括用来指示多个目录名称的前缀匹配字符串，其指示了与在所述文件数据流上广播的文件相关联的文件内容。
39.根据权利要求37所述的方法，其中，所述广播调度记录准确地包括一个前缀匹配字符串，其指示了与文件名称相关联的文件内容。
40.根据权利要求37所述的方法，其中，所述接收机设备被配置为与在所述前缀匹配字符串中的值执行双向前缀匹配。
41.根据权利要求38所述的方法，其中，所述广播调度记录准确地包括一个前缀匹配字符串，其指示了与文件名称相关联的文件内容。
42.根据权利要求38所述的方法，其中，所述接收机设备被配置为与在所述前缀匹配字符串中的值执行双向前缀匹配。
43.根据权利要求I所述的方法，其中，产生广播调度消息包括产生所述广播调度消息，以包括属性字符串，其提供了用以表征文件内容的多个属性。
44.根据权利要求I所述的方法，其中，产生广播调度消息包括产生所述广播调度消息，以包括广播调度信息记录。
45.根据权利要求44所述的方法，其中，产生所述广播调度消息以包括广播调度信息记录包括产生所述广播调度消息的所述广播调度信息记录，以包括报头部分和主体部分。
46.根据权利要求45所述的方法，其中，产生所述广播调度信息记录包括产生所述广播调度信息记录的所述报头部分，以包括下一监视时间数据字段和监视周期数据字段。
47.根据权利要求46所述的方法，进一步包括 从所述广播调度信息记录的所述报头部分提取所述下一监视时间数据字段和所述监视周期数据字段 '及 使用所提取的下一监视时间数据字段和所提取的监视周期数据字段，以不同的等待时间来传递数据。
48.根据权利要求45所述的方法，其中，产生所述广播调度信息记录包括 确定系统是否支持初始获取流(IAF)系统；以及 产生所述广播调度信息记录的所述报头部分，以包括监视周期数据字段，并且在确定所述系统不支持初始获取流(IAF)系统的情况下包括下一监视时间字段。
49.根据权利要求46所述的方法，其中，产生所述广播调度信息记录的所述报头部分包括产生所述报头部分，以包括包含与所述文件数据流有关的信息的信息字段。
50.根据权利要求49所述的方法，其中，产生所述报头部分以包括信息字段包括产生所述信息字段，以包括流ID数据字段和数据速率数据字段。
51.根据权利要求46所述的方法，其中，所述下一监视时间数据字段指定所述接收机设备应针对更新的广播调度消息而监视所述广播调度流的下一个时间。
52.根据权利要求I所述的方法，进一步包括 使用初始获取流(IAF)系统来通知所述广播调度消息的新版本。
53.根据权利要求I所述的方法，进一步包括在所述接收机设备中从初始获取流(IAF)接收最新的目录信息消息，并且执行比较操作，所述比较操作将从所述最新的目录信息消息中提取的所接收的广播调度消息的版本信息与未终止的被处理的广播调度消息的版本信息进行比较。
54.根据权利要求53所述的方法，进一步包括如果所述比较操作的结果指示所述版本不同，则启动在所述接收机设备中的接收机电路，以接收更新的广播调度消息。
55.根据权利要求I所述的方法，进一步包括在所述接收机设备中接收所述广播调度消息，并且将在所接收的广播调度消息中的版本参数与目录信息消息单元中的版本参数相比较，并且如果被比较的版本不同，则忽略所接收的广播调度消息。
56.根据权利要求12所述的方法，其中，所述广播网络将下一监视字段设备配置参数设定为在所述广播调度周期的开始时间之前的可变秒数，所述方法进一步包括在所述接收机设备中检测广播调度消息更新，并且在所述广播调度周期开始之前接收更新的广播调度消息。
全文摘要
用于在广播系统上将文件有效地传递到移动设备的方法、系统和设备提供机制和系统。可以将用于广播的文件在逻辑上标识为属于文件系统中的目录。广播调度消息可以向接收机设备通知将在特定时间广播的文件，并且描述所述文件。文件可以在文件传递管道中发送，文件传递管道可以具有不同带宽和数据速率。根据实施例配置的接收机设备可以基于与文件相关联的服务或应用，以及文件是新的还是对先前接收的文件的更新，利用广播调度消息来选择要接收的文件。接收机设备启动接收机电路，以在其公布的广播窗口内捕获文件，并将接收的文件传送到请求所述文件的应用或服务。
文档编号H04N21/443GK102948159SQ201180026570
公开日2013年2月27日 申请日期2011年5月27日 优先权日2010年5月28日
发明者C·M·D·帕索斯, R·萨乌塔, Q·高, M·K·吉韦尔, T·M·纳佳拉杰, D·G·卡文迪什, J·斯瓦米, R·A·戈尔米 申请人:高通股份有限公司