CN102090040B - 传输和接收供多媒体流使用的控制信息 - Google Patents

Abstract

生成按照第一协议版本生成的、用于配置视听设备以表现多媒体流的第一控制信息。生成具有指定第一控制信息是第一协议版本的控制信息的第一数据结构。生成和传输包括多媒体流、第一控制信息和第一数据结构的多个分组。生成按照第二协议版本生成的、用于配置视听设备以表现多媒体流的第二控制信息。可修改第一数据结构，以包括和第二控制信息有关的信息。生成第二多个分组，所述第二多个分组包括修改后的第一数据结构、第一控制信息、由第一控制信息指定的多媒体流、第二控制信息和由第二控制信息指定的多媒体流。

Description

传输和接收供多媒体流使用的控制信息

技术领域

本发明涉及配置通信系统，更具体地说，在一个实施例中，涉及一种信令配置信息的可重新配置方法。

背景技术

在传统的通信系统中，只能按照预定方式改变数据流和控制流的格式。几个比特专供增加功能之用，几个列举的参数支持多种选项，不过总的来说，支持的变化非常有限。开发人员把这种有限的灵活性增加到系统中他们认为可能变化的地方。需要的变化中有两种是不能计划的；无法预料的系统问题，和新的技术创新。对不确定变化的支持要求向前兼容。

为了解决对会随着时间发展的数据和控制协议的需要，发明了灵活、可扩展的数据构成方法，不过这些方法存在局限性。这样的语言包括XML、JSON和YAML。这些语言以树形格式构成数据，对可扩展性来说，这是有利的，不过如果未考虑到比特效率而精心设计的话，那么会需要相当大的开销。为了支持人类可读性，XML和相关协议的格式是基于文本的。这使数据是人类可读的，但是使语言负担更多的开销。在通信系统中，非常希望具有高的带宽效率。需要一种高效得多的可扩展通信方法。

ATSC(高级电视制式委员会)标准涉及将代替模拟NTSC电视制式的数字电视格式。ATSC标准是一种产生大小一直到1920×1080像素(是早期NTSC标准的显示分辨率的6倍多)的标准4∶3或宽屏16∶9图像的高清晰度电视标准。ATSC标准为在单一的6MHz TV频道上传送多个标准清晰度“虚拟频道”广播作好准备。ASTC标准还包括利用Dolby Digital AC-3格式提供5.1声道环绕声的“影院品质”音频。ATSC标准还提供众多的辅助数据广播服务。在ATSC标准的信令(signalling)和版本管理(versioning)方面，需要各种改进。

发明内容

本发明的实施例涉及生成供供和多媒体流一起传输给视听设备之用的控制信息的系统和方法。本发明的实施例还涉及按照接收的控制信息，接收和表现多媒体内容的系统和方法。本发明的实施例可以和数字移动广播电视，以及向各种移动/手持设备，比如蜂窝电话机、智能电话机等的数字多媒体内容的提供一起使用。

在传输实施例中，所述方法生成一组以上(例如，多组)的控制信息。每组控制信息用于配置视听设备，以表现多媒体流。每组控制信息可按照不同的协议版本生成。此外，每组控制信息用于配置视听设备，以按照不同的方式表现多媒体流。

所述方法还生成第一数据结构(可称为服务描述符)。第一数据结构包含每组控制信息的位置信息。第一数据结构还规定每组控制信息的协议版本。多组控制信息中的每组控制信息的位置可以协议版本和/或服务种类为基础。第一数据结构被配置成是可扩展的，例如，以增加与附加控制信息相关的附加信息。例如，可以增加附加控制信息，以适应未来的标准变化，或者新标准，可据此扩展第一数据结构，以包括和所述新的控制信息有关的信息。另外，可在后续传输中包括附加数据结构(服务描述符)，以适应附加控制信息。

包含在第一数据结构中的信息可被接收视听设备用于确定哪个控制信息与该视听设备兼容，哪个控制信息应被忽略。

所述方法随后生成和传输第一多个分组，所述第一多个分组包含第一数据结构、所述多组控制信息和多媒体流。这里，分组的“传输”包括分组的广播传输，比如在无线广播电视系统中。分组的“传输”还包括通过网络，比如因特网，从服务器计算机向客户端(例如，移动设备)提供分组。

第一数据结构可被视听设备用于忽略相应的一组或多组控制信息，如果该视听设备未被配置成理解所述相应的一组或多组控制信息的协议版本的话。

在接收实施例中，视听设备可接收第一多个分组，其中第一多个分组包含第一多媒体流、第一控制信息、第二控制信息和第一数据结构。可按有线或无线的方式接收所述分组。

第一数据结构(例如，服务描述符)包含第一控制信息和第二控制信息的位置信息。第一数据结构还指定第一控制信息的第一协议版本，和第二控制信息的第二协议版本。

视听设备分析第一数据结构，以确定第一控制信息和第二控制信息的位置信息，及第一控制信息和第二控制信息的第一和第二协议版本。在视听设备未被配置成理解第二协议版本的情况下，视听设备利用第二控制信息的位置信息来忽略第二控制信息。

视听设备随后按照第一控制信息配置它自己，从而使视听设备能够表现第一多媒体流。在被配置之后，视听设备随后可表现第一多媒体流。

提供给视听设备的用于配置视听设备以表现多媒体流的控制信息可按照具有多个节点的树形结构来组织，其中所述节点中的至少一些节点是叶节点。叶节点存储用于配置视听设备的数据值。控制信息可包含多个命令。至少一些的命令可由视听设备执行，以导航树结构的节点，从而定位于保存在叶节点的数据值。一些命令是可执行的，以相对于树形结构中的当前位置对树形结构导航。另一方面或者另外，一些命令是可执行的，以相对于树形结构的根节点对树形结构导航。一个或多个命令可以是修饰符命令。修饰符命令可指定树形数据结构中，在当前节点位置之下的所有叶节点的参数值。例如，修饰符命令可指定树形结构中，在当前节点位置之下的所有数据值是可选的数据值，或者是强制性的数据值。一些叶节点均可保存用于配置视听设备的多个数据值。

在一个实施例中，控制信息包含多个命令，其中所述命令的至少一个子集具有相关的数据字段。一个或多个命令可以是包括长度值并且指定参数值的修饰符命令，所述参数值被应用于在与修饰符命令相隔由所述长度值指定的长度距离内的所有数据值。例如，修饰符命令可指定在与修饰符命令相隔由所述长度值指定的长度距离内的所有数据值是可选的数据值，或者是强制性的数据值。

本发明的实施例可利用各种比特效率更高效地生成控制信息。例如，控制信息可包含多个命令，其中所述命令的至少一个子集具有相关的数据字段。每个命令可包含长度统一的多个比特部分。另外，每个数据字段可包含长度统一的多个比特部分。在一个实施例中，命令的各个比特部分的第一比特(例如MSB)可具有指示该比特部分是命令的第一值(例如，“0”)。数据字段的各个比特部分的第一比特(例如，MSB)可具有指示该比特部分是数据字段的第二值(例如，“1”)，其中第二值不同于第一值。这提供一种不需要专用长度字段而指示命令和数据的长度的高效方法。

附图说明

当结合附图，参考优选实施例的下述详细说明时，能够更好地理解本发明，其中：

图1图解说明按照一个实施例的数字电视广播系统；

图2是按照一个实施例，图解说明生成供和多媒体流一起传输给视听设备之用的控制信息的方法的流程图；

图3是按照一个实施例，图解说明视听设备接收多媒体流的控制信息的方法的流程图；

图4是按照本发明的一个实施例的具有内嵌信令的体系结构的说明图；

图5是按照一个实施例的树形数据结构的说明图；

图6是按照一个实施例的ATSC M/H系统的基本版本功能块的说明图；

图7是按照一个实施例，包含ATSC M/H功能块的版本管理的树形数据结构的示意图；

图8是按照一个实施例的具有独立版本管理的体系结构的说明图；

图9是按照一个实施例，具有结合的版本管理和信令块的体系结构的说明图；

图10是描述按照一个实施例的分组格式的说明图；

图11是按照一个实施例，定义控制分组的字段的表格；

图12是按照一个实施例的服务描述符的格式的说明图；

图13是按照一个实施例，定义服务描述符字段的子字段的表格；

图14是按照一个实施例，图解说明例证的服务描述符字段的表格；

图15是按照一个实施例的一系列命令/数据的格式的说明图；

图16是按照一个实施例，定义XCL命令集的表格；

图17是按照一个实施例，定义XCL命令集修饰符的表格；

图18是按照一个实施例，描述ATSC M/H树的一部分的说明图；

图19是按照一个实施例，描述ATSC M/H树的说明图；

图20是按照一个实施例，描述供图19中的ATSC M/H树之用的FIC数据树的说明图；

图21是按照一个实施例，描述导航FIC树的例证命令序列的说明图；

图22是按照一个实施例，描述供图19中的ATSC M/H树之用的SMT数据树的说明图；

图23是按照一个实施例，描述导航SMT树的例证命令序列的说明图；

图24和25是定义XCL命令集和命令修饰符的备选实施例的表格；

图26-28是描述FIC和SMT数据树的备选实施例的说明图。

虽然本发明可以有各种修改和备选形式，不过在附图中举例表示了本发明的具体实施例，并在这里详细说明了这些具体实施例。不过，应明白附图及其详细说明并不意图把本发明局限于公开的特定形式，相反，本发明覆盖在由附加的权利要求限定的本发明的精神和范围内的所有修改、等同物和备选方案。

具体实施方式

诸如广播系统之类的通信系统一般包括传送某种类别的内容或服务的架构。通信系统另外可包括向接收机提供和所述内容或服务有关的信息的信令架构。复杂性即使最低的或者预期随着时间而变化的任何通信系统都需要提供这样的信息，以使接收机能够使用所述内容或服务；例如，信令架构使接收机能够调谐到提供的服务，从传送中提取服务，和向用户表现所述服务。通信系统的一个具体例子是视听广播系统，例如数字电视广播系统。可按照这样的例证系统，举例说明这里描述的许多实施例，不过这些实施例也适用于其它通信系统。

信令可包括和对接收机使用服务来说，有用或者必需的特定组件有关的信息。信令还可包括版本管理信息。系统的一个或多个组件(在系统的任意层次，一直到和包括整个系统)可包括协议版本。接收机需要知道这样的版本管理信息，以使其可以正确地重构服务。例如，如果在发射机，用版本比安装在接收机的当前功能更新的功能构成服务，那么接收机不能正确地处理和表现该服务。于是，在服务的处理和表现中所涉及的功能的版本信息需要被包括在信令信息中。由于通信系统中的带宽有限，因此高效的信令架构同样重要，以便为实际的内容和/或服务节约尽可能多的带宽。

在给定的通信系统中使用的信令架构和方法对通信系统的目前和未来实现的向前和向后兼容性具有重大影响。对通信系统来说，一个特别期望的特征是能够提供陈旧(传统)的设备和服务，同时能够提供新服务，和能够支持所述新服务的设备。在新服务中有效地提供这种向后兼容性(例如，开发能够与传统的设备和服务一起工作的新服务和设备)的一种最有效途径是建立一种非常向前兼容的信令架构(例如，所述信令架构被设计成高效并且有效地为通信系统，包括信令架构本身中的不确定变化作准备)。从而，对改善通信系统的整体功能，以及延长通信系统的组件(例如，提供的服务，和用于接收这些服务的消费者组件)的有效寿命来说，使用灵活、可扩展和高效的信令架构可能是关键性的。

本发明的各个实施例涉及可产生通信系统的灵活、可扩展和高效的版本管理和信令系统的这种架构和方法。这种架构的一个关键是向传统的接收机提供一种得体地识别它们是否能够支持一部分的信令/版本数据，并忽略或跳过这样的各部分信令/版本管理数据。这允许更自由地开发新的服务，和能够支持这些新服务的接收机，而不削弱传统接收机的接收内容的能力。

这种架构的均可用各种方式实现的组件有几种。一些或者全部的这些组件可一起工作，以产生可扩展并且高效的信令和版本管理架构。在一些实施例中，一个或多个组件可被单独实现，例如，在没有其它组件的情况下，不过在一些实施例中，一起使用一些或全部的组件可获得更大的好处。所述组件可以包括下述任意之一，每个都将在下面进一步说明。存在一种构成信令/版本管理数据，以致传统接收机能够得体地检测和跳过在结构中插入的不支持数据的手段。存在一种把信令/版本管理数据划分成多个兼容的组，以致这些组的目标(例如，接收机)可支持分组的功能的手段。存在一种索引到这些信令/版本管理组，以致只支持接收机访问是解码和正确表现支持的服务所需要的数据，并且以致在尝试表现内容之前，接收机知道所述内容的表现得到完全支持的手段。存在确定如果一些部分未得到支持，那么要跳过多少数据的手段。存在导航或以其它方式参考信令/版本管理数据的结构，以致能够修改和/或扩展数据的结构的手段。存在对导航或以其它方式参考信令/版本管理数据的结构的手段进行扩展的手段。

构成信令/版本管理数据，以致传统接收机能够得体地检测和跳过在结构中插入的不支持数据，意味着对于结构的可独立于所述结构的任意其它部分被修改的每个部分，所述结构包括用信号通知接收机(即，包括传统接收机)它们是否能够支持所述结构的该部分的元件。实际上，必须存在用版本标记结构的不同部分的途径。这可用多种方式来实现。一种实现涉及用树形格式构成信令/版本管理数据，其中可对任何给定的叶或节点(例如，包括一个或多个叶和/或子节点)单独进行版本管理。另一种实现包括用一个或多个表构成信令/版本管理数据，其中表的每个部分具有直接或间接标记信令/版本管理数据的该部分的版本的表头或指针。另外，结构本身应是可扩展的，即，必须存在插入另外的信令/版本管理数据的途径。树形结构容易适合于这种追加要求，因为能够创建另外的节点或叶，而不影响结构的剩余部分。不过，表也能够适应这种要求。

把信令/版本管理数据划分成多个兼容的组，以致所述组的目标可支持分组的功能，这可提高信令架构的效率。这种分组的例子可包括给定标准的协议版本，服务的类别，音频/视频信息种类，标准种类等等。例如，如果信令/版本管理数据被划分成协议版本组，那么兼容特定协议版本的接收机可从单个组获得该协议版本的所有信令/版本管理数据。

索引到信令/版本管理组可允许接收机找到它支持的组，和识别它不能支持的组，从而忽视不能支持的组。对接收机来说，与迫使接收机自己开始解析信令/版本管理数据，以发现是否支持信令/版本管理数据相比，这是一种更加高效的发现信令/版本管理数据的哪个或哪些部分与该特定接收机相关和得到该特定接收机支持的方式。这种索引的一个例证实现是提供这种索引信息的“服务描述符”或者“服务发现表”，例如与信令/版本管理数据分离的数据结构。另一种可能的实现是把这种索引信息包括在信令版本管理数据内，不过对信令架构本身未来的变化来说，这不太灵活。

如果接收机跳过或忽略不支持的数据，那么它必须具有确定要跳过多少数据的途径。换句话说，接收机不仅需要能够认识到它不支持一部分的数据，而且需要知道要被跳过的数据的起点和终点。在一个实施例中，这可被结合到索引功能中，例如，索引可包括定位每个组的起点和终点的信息。在一些实施例中，尽管组可具有相同的基本协议版本，不过理想的是在组中包括具有不同(例如，更高)协议版本的一些可选组件。这种情况下，把这些组件标记为可选的方式也是合乎需要的。

为了进行通信系统的未来协议版本修订和产生新的协议版本，有益的是导航或以其它方式参考信令/版本管理数据的结构，以致能够修改和/或扩展数据的手段。例如，如果结构是树形结构，那么对所述树进行导航的手段必须包括导航到树中的新的或者修改的节点或叶的能力；否则，对所述树结构进行导航的手段不能支持修改后的树。在一种实现中，这可以是对树形结构进行导航的一组命令，所述一组命令支持导航到树的任意节点或叶。参考图15-17更详细地说明这种命令集的例子。这里把这种命令集称为“可扩展控制语言”或者“XCL”。不论哪种结构被用于信令/版本管理数据(例如，树形结构、表结构或任意结构)，导航或以其它方式参考该结构的手段应允许对该结构的修改和/或扩展。

类似地，有益的是提供一种对导航或以其它方式参考所述结构的手段进行扩展的手段。换句话说，信令方法本身应是灵活和可扩展的。这可以简单到为未来的导航或参考信息保留固定数目的比特或值，不过，优选不确定的可扩展系统。例如，再次考虑上面关于信令/版本管理数据所述的树形结构，和用于对树进行导航的命令集。可以固定长度字段中的值的形式，列举命令集中的任意给定命令。代替为未知的未来应用保留几个值，和对于任何新的命令局限于(在该信令协议版本内)这几个值，可以定义一个命令，用于用另一个固定增量扩展该字段。扩展的字段可被用于新的命令，直到扩展字段的所有值都被定义为止，并可用该“扩展字段”命令再次扩展该字段；这可以无限地继续下去，而不破坏向后兼容性。

下面关于广播系统，例如，数字电视广播系统，说明这种可扩展信令架构的实施例和例证实现。不过应再次指出的是，尽管上面说明的方法可以和广播系统，比如图1中描述的，并且下面按照各个实施例说明的广播系统一起使用，不过更一般地，这些方法也可酌情和任何通信系统一起使用。

图1数字电视广播系统

图1图解说明按照本发明的一个实施例的例证广播系统100。在一个实施例中，广播系统可以是数字电视广播系统。这里描述的广播系统100(包括这里描述的各种方法)可被用于广播任意各种数据，包括视听信息以及其它数据。这里使用的术语“广播”意图包含本领域的技术人员所了解的该术语的各种各样的普通含意。

这里使用的术语“视听信息”和“多媒体流”包括包含视频数据和/或音频数据的任意各种信息或数据。术语“视频数据”包括运动视频(例如，电视，电影，流式视频等，以及诸如JPEG之类的图像数据。术语“视听信息”和“多媒体流”还包括当被执行时，使设备表现视频数据(在显示器上)和/或音频数据(在扬声器上)的任意各种信息或程序指令。例如，术语“视听信息”和“多媒体流”包括可被使用和/或执行，以在表现设备上表现游戏内容(例如，图像，视频和/或音频)的任意各种游戏内容(包括程序指令和/或数据)。

在一组实施例中，广播系统可按照ASTC(高级电视标准委员会)标准，例如利用8-VSB调制工作。另一方面，广播系统可按照改进版本的ATSC标准，或者按照另一种标准工作。例如，ATSC标准的移动/手持(M/H)改进可用于对移动接收机的视听信息的传输。这里公开的实施例的具体例子可以基于，或者包括ATSC标准的M/H改进的各个部分，或者还可包括M/H和ATSC标准的其它变化和改进。不过，这里公开的与视听信息的传输相关的实施例不一定局限于和ATSC或M/H系统一起使用，同样适用于按照其它标准和/或调制方案，比如DVB-T/H，ISDB-T，DMB-T/H等等的视听信息的传输。

如图所示，系统100包括传输系统(或发射系统)102，和一个或多个视听设备112(例如，一个或多个固定设备，比如112A，和/或一个或多个移动设备，比如112B-112E)。如上所述，图1只是例证性的，例如，例证系统可包括一个或多个传输系统102，多个移动设备，和多个固定设备。这里描述的任意各种方法可按需要和移动设备和/或固定设备一起使用。

传输系统102可被配置成按照有线或无线方式，向一个或多个视听设备112传输视听信息。在一个特别的实施例中，传输系统102可被配置成向移动设备112B-112E无线传输数字电视信号/频道。移动设备112B-112E可接收和表现视听信息，例如，接收和表现数字电视信号/频道。传输系统102还可被配置成按照有线或者无线方式，向固定设备112A(例如，固定电视机)传输视听信息。在一些实施例中，视听设备能够充当传输系统；例如，视听设备可能能够接收传输，并本地向其它视听设备重新广播所述传输。从而，在一些实施例中，传输系统102也可以是视听设备。

传输系统102包括发射机106，以及与发射机106耦接的传输逻辑104。传输逻辑104可包括任意各种逻辑，比如一个或多个计算机系统(具有附带软件)，数字逻辑，模拟逻辑，可编程门阵列等，或者它们的组合。传输逻辑104适合于接收和/或保存视听信息(例如，电视数据)，和生成包含视听信息的分组。传输逻辑104可按照任意各种标准，比如ATSC(高级电视标准委员会)标准，例如利用8-VSB调制，生成分组。传输系统102可以使用其它调制方案，比如DVB-T/H，ISDB-T，DMB-T/H等。传输逻辑104可被配置成生成包含如这里所述的控制信息(例如信令/版本管理数据)的分组。在一个实施例中，一个或多个数字电视频道可预定用于诸如电视机之类的固定接收机。一个或多个数字电视频道也可预定用于移动和/或手持(M/H)(这里集体称为“移动”)设备112B-E。在一个实施例中，一个或多个数字电视频道可预定用于固定接收机或者移动设备。

移动设备112可以是任意各种设备，比如便携式计算机系统(膝上型计算机)112B，无线电话机112C(例如，黑莓，iphone等)，个人数字助手112D，车载电视设备112E，和能够显示接收的视听信息的其它各种便携式设备。

固定设备112A可以是打算放置在固定位置的任意各种设备(称为固定或“非移动”设备)，比如传统的电视机，例如，液晶显示器(LCD显示器)，等离子体显示器，等等。

视听设备112被配置成接收由发射机106传输的包括视听信息和控制信息的分组。相应的移动设备112还可包括处理接收的视听信息的接收机逻辑，以及表现视频信息的显示器，和表现音频信息的一个或多个扬声器。从而，每个视听设备112可包括如这里所述的表现接收的电视频道的电视似的能力。

图2传输流程图

图2是描述向视听设备传输供多媒体流之用的控制信息的方法的流程图。所述方法可由如上所述，并且示于图1中的传输系统，例如包括传输逻辑和发射机的系统执行。多媒体流可供移动设备接收；另一方面，多媒体流可供固定设备接收，或者供移动设备和固定设备接收。应注意的是，按照各个实施例，一个或多个步骤可被省略、重复或者按照与示于图2中，和下面说明的顺序不同的顺序执行。

在202，可生成按照第一协议版本的第一控制信息。第一控制信息可用于配置视听设备，以按照第一种方式(例如，按照第一服务种类)表现多媒体流。第一控制信息可以是一系列命令和数据，供视听设备导航树形数据结构，和设定所述树的一个或多个叶节点的参数值。例如，第一控制信息可以是用于导航和定义ATSC M/H树(例如关于图19、20或22所示和描述的树)的一系列XCL命令(例如关于图15-17所示和描述的命令)。从而，第一控制信息可如图22或24中所示或者类似地被编码。另一方面，第一控制信息可以是用于配置视听设备，以表现多媒体流的任意种类的控制信息。可按照第一协议版本生成第一控制信息。例如，在一个实施例中，可按照1.0版XCL，生成第一控制信息。

在204，可生成第一数据结构，包括与第一控制信息有关的信息。第一数据结构可规定第一控制信息是第一协议版本的控制信息。换句话说，如果第一控制信息是1.0版XCL，那么第一数据结构可以指出这一点。第一数据结构还可(或者另一方面)指示与第一控制信息有关的任意各种其它信息，比如第一控制信息的位置信息(比如偏移量)，和/或第一控制信息规定的多媒体流的服务的类别或种类。例如，第一控制信息可用于配置视听设备，以3-D或2-D地表现多媒体流。第一数据结构还可包括定义它自己，例如，规定其大小，协议版本，结构等的信息。

在一个实施例中，第一数据结构可以是服务描述符，比如下面关于图12-14说明的服务描述符。从而，在这种情况下，数据结构会包括定义它自己(例如，协议版本、长度、列数、列长度)的信息，以及与第一控制信息有关的信息(信息的种类，和每种信息的数据)。另一方面，第一数据结构可以是任意种类的数据结构。

在206，可生成第一多个分组。第一多个分组可包括由第一控制信息规定的多媒体流(例如，视听信息)，第一控制信息和第一数据结构。可在包括多媒体流的分组的生成之前，接收和/或保存多媒体流。第一多个分组可包括分组的独立子集，其中一个子集包括多媒体流，而一个子集包括第一控制信息和第一数据结构。所述子集可以是分离的，或者可被混合在一起(例如，被复用)。另一方面，信息可按照不同的方式被分离，或者可被生成到包含多媒体流、第一控制信息和第一数据结构的类似分组中。可按照任意各种格式，例如IPv4、IPv6、MPEG-2或其它格式生成分组。

在208，可传输第一多个分组。第一多个分组可由传输系统，比如按照各个实施例，关于图1说明的传输系统传输。在一些实施例中，第一多个分组可由服务器，例如因特网服务器提供。从而，传输系统可以是单向通信系统(例如，广播系统)，或者双向通信系统(例如，通过因特网，蜂窝网络，或者任意双向通信系统)。

在210，可生成按照第二协议版本的第二控制信息。第二控制信息可用于配置视听设备，以按照第二种方式，例如，按照第二服务种类表现多媒体流。非常类似于第一控制信息，第二控制信息可以是一系列的命令和数据，用于导航树形数据结构，和设定树的一个或多个叶节点的参数值。例如，第二控制信息可以是用于导航和定义ATSCM/H树(例如关于图19、20或22所示和描述的树)的一系列XCL命令(例如关于图15-17所示和描述的命令)。从而，第二控制信息可如图22或24中所示或者类似地被编码。另一方面，第二控制信息可以是用于配置视听设备，以表现多媒体流的任意种类的控制信息。可按照第二协议版本生成第二控制信息，第二协议版本可不同于第一协议版本。例如，如果第一控制信息是按照1.0版XCL生成的，那么可按照2.0版XCL，或者控制信息的完全不同的命令语言或形式生成第二控制信息。

第二控制信息可用于配置视听设备，以表现第一控制信息对其规定视听设备的配置信息的相同多媒体流。另一方面，第二控制信息可用于配置视听设备，以表现不同于第一控制信息的多媒体流(例如，不同种类的多媒体流，比如按照与第一多媒体流不同的协议版本的多媒体流)。

在212，可修改第一数据结构，以包括与第二控制信息相关的附加信息。例如，如果第一数据结构是服务描述符(如同关于图12-14，按照各个实施例说明的服务描述符)，那么可以修改列长度字段，以指示每列中的一个附加项目。随后，与第二控制信息有关的信息可作为第二项目被包括在每列中。从而，修改后的第一数据结构可包括与第一控制信息相似的第二控制信息的信息，例如，第二控制信息的协议版本，服务的种类或类别，主/副频道号，位置信息(例如，偏移量)等等。应注意的是，除了被修改以包括与第二控制信息有关的附加信息之外，第一数据结构可保留与第一控制信息有关的信息。在一个实施例中，可以修改数据结构的格式。例如，第一数据结构可以是1.0版服务描述符，而修改后的第一数据结构可以是2.0版服务描述符。修改后的第一数据结构可包括规定其格式的信息，例如，可包括修改后的第一数据结构的版本信息，和/或修改后的第一数据结构的大小信息。另一方面，该数据结构可以是一种不同于服务描述符的数据结构，并且可按照任意多种方式被修改，以包括和第二控制信息有关的附加信息。

在另一个实施例中，可不修改第一数据结构，而是生成第二数据结构。第二数据结构可以类似于第一数据结构，不过具有与第二控制信息有关的信息，而不是与第一控制信息有关的信息；另一方面，第二数据结构可以是一种不同的数据结构。例如，第二数据结构可以是不同协议版本的服务描述符，或者是完全另一种的数据结构。这样的第二数据结构仍可包含与第一数据结构类似的、不过是关于第二控制信息的信息，例如第二控制信息的协议版本信息，位置信息(比如偏移量)等等；另一方面，第二数据结构可包括与第二控制信息有关的任意各种不同的信息。

在一个实施例中，与第一和第二控制信息有关的数据结构中的信息可被接收机(例如，接收视听设备)用于确定它能够使用或者应使用什么控制信息，和它能够忽略或者应忽略什么控制信息。例如，第一数据结构可把第一控制信息识别为第一协议版本的控制信息，和提供第一控制信息在多个分组中的位置；从而，如果视听设备未被配置成解析第一协议版本的第一控制信息，那么该视听设备能够利用第一数据结构中的信息忽略该第一控制信息。类似地，如果存在多批或多组控制信息，那么视听设备可以使用诸如服务描述符之类的数据结构来确定该视听设备未被配置成了解其协议版本的多于一组的控制信息，从而，视听设备能够使用该数据结构忽略它未被配置成了解其协议版本的各组控制信息。

在214，可生成第二多个分组，包括修改后的第一数据结构，第一控制信息，第二控制信息，由第一控制信息指定的多媒体流，和由第二控制信息指定的多媒体流。可在包含多媒体流的分组的生成之前，接收和/或保存每个多媒体流。由第二控制信息指定的多媒体流可以是和由第一控制信息指定的多媒体流相同的多媒体流；另一方面，它们可以是两个不同的多媒体流。例如，由第一控制信息指定的多媒体流可以是按照第一协议版本生成的，而由第二控制信息指定的多媒体流可以是按照第二协议版本生成的。

第二多个分组还可包括其它信息，比如附加的多媒体流，附加的控制信息(例如，附加的多媒体流的控制信息)，和/或附加的数据结构(例如，提供与附加的控制信息有关的信息，比如位置和协议版本信息)。另外应注意的是，第一数据结构(或第二数据结构)还可包括与附加的控制信息有关的附加信息，例如，单个数据结构可包括和多批或多组控制信息有关的信息，其中每批或每组控制信息可以是不同协议版本的控制信息，和/或具有可用于索引该组控制信息的一个或多个其它定义特性。在一个实施例中，第二多个分组可包括规定包含在第二多个分组中的许多数据结构的信息，例如，如果存在两个以上的数据结构的话。

第二多个分组可包括分组的独立子集，其中存在关于每个多媒体流的一个子集，而一个子集包括第一控制信息和第一数据结构。子集可以是分离的，或者可被混合在一起(例如，被复用)。另一方面，可按照不同的方式分离信息，或者生成的所有分组可类似地包含每个多媒体流、第一控制信息和第一数据结构的多个部分。可按照任意各种格式，例如IPv4、IPv6、MPEG-2或其它格式生成分组。

在216，可传输第二多个分组。第二多个分组可由传输系统，比如按照各个实施例，关于图1说明的传输系统传输。在一些实施例中，“传输”第一多个分组可包括由服务器，例如因特网服务器提供第一多个分组。从而，传输系统可以是单向通信系统(例如，广播系统)，或者双向通信系统(例如，通过因特网，蜂窝网络，或者任意双向通信系统)。

在一些实施例中，当开发和/或发布新的协议版本，服务等时，可以生成和传输另外的各多个分组(例如，第三，第四多个等)，包括附加的控制信息，附加的或者修改的数据结构，附加的多媒体流等。

上面说明的向视听设备传输供多媒体流之用的控制信息的方法可由按照各个实施例，向视听设备传输多媒体流的控制信息的系统执行。例如，所述系统可包括接收一个或多个多媒体流的输入，生成和/或修改控制信息、数据结构和/或分组的传输逻辑，和/或传输分组的发射机。

图3接收流程图

图3是描述视听设备接收多媒体流的控制信息的方法的流程图。该方法可由任意种类的视听设备执行。例如，该方法可由上面说明并示于图1中的移动设备(例如，便携式计算机系统(膝上型计算机)，无线电话机(例如，黑莓，iphone，等)，个人数字助手，车载电视设备，和能够显示接收的视听信息的其它各种便携式设备)执行。另一方面，在一些实施例中，该方法可由固定设备，比如同样示于图1中和上面说明的固定设备(例如，常规电视机，比如液晶显示器(LCD显示器)电视机，等离子体显示器电视机等)执行。应注意的是，按照各个实施例，一个或多个步骤可被省略、重复或者按照与示于图3中，和下面说明的顺序不同的顺序执行。

在302，可接收第一多个分组。第一多个分组可包括第一多媒体流，第一控制信息，第二控制信息和第一数据结构。第一数据结构可包括第一和第二控制信息的位置和协议版本信息。第一和第二控制信息可以是按照不同的协议版本生成的。每组控制信息可以用于第一多媒体流，或者可以用于不同的多媒体流。例如，第一多个分组可包括一个或多个附加的多媒体流。在各个实施例中，数据结构可以是服务描述符。第一和/或第二控制信息可以是按照XCL的各个实施例，例如XCL的不同协议版本生成的。如果存在多个多媒体流，那么一些多媒体流的协议版本可不同于其它多媒体流的协议版本。

在304，可分析第一数据结构，以确定第一和第二控制信息的位置和协议版本信息。视听设备可以利用第一数据结构(例如，位置和协议版本信息)确定它能够或者应该利用哪些控制信息配置它自己，以及相反地，它能够忽略哪些控制信息。从而，视听设备可不被配置成理解第二协议版本的第二控制信息，于是可利用控制信息的位置信息忽略第二控制信息。

在306，可按照第一控制信息配置视听设备。视听设备可被配置成理解第一协议版本。从而，视听设备能够利用数据结构中的信息确定第一控制信息的位置，和解析第一控制信息。从而，视听设备能够按照第一控制信息配置它自己。配置视听设备使视听设备能够表现第一多媒体流。

在308，可表现第一多媒体流。表现第一多媒体流可包括在显示器上表现视频信息，和/或在一个或多个扬声器上表现音频信息。

图4内嵌信令的体系结构

图4图解说明现有技术中常用的内嵌信令的系统体系结构。在通信系统中，通常用与服务的处理有关的许多系统块处理信令信息，从而，在不破坏向后兼容性的情况下，这些系统块在其变化能力方面受到限制。例如，FLUTE是一种文件管理协议。它用于管理基于文件的内容，包括诸如OMA BCAST和DVB-H之类许多无线标准中的信令。信令信息按FLUTE文件格式，从发射机传给目标接收机。这意味不能以非向后兼容的方式改变FLUTE功能，并且它不能被替换。如果目标接收机具有1.0版的FLUTE功能，而发射机按FLUTE 2.0版本格式(假定不是向后兼容的)发送信令信息，那么接收机将在FLUTE功能丢弃该分组，信令功能将根本看不到曾经收到该信息的任何指示。为此，更有意义的是把信号处理包含在较低的层次，例如像示于图8和9，和关于图8和9所述的系统体系结构中那样。

图5树形数据结构

如上所述，可扩展信令/版本管理架构的一个方面是一种信令/版本管理信息的结构，它允许按照不支持新的/修改的信令/版本管理数据的接收机(例如，视听设备)能够跳过或忽略所述新的/修改的信令/版本管理数据的方式，插入新的或者修改的信令/版本管理数据。

目前的信令方案一般依赖于静态表来传递系统参数和其它系统配置信息。这样的表可具有用于传送参数(包括原始二进制值和列举种类的混合物)的比特定义结构。可为未来的应用保留几个比特，不过一般没有办法扩展或改变这样的表，而不破坏向后兼容性。这种表的一个例证形式可如下所示：

语法                                    比特数

----------                              ----------

List Header(){

Parameter 1                            3

Parameter 2                            1

Parameter 3                            16

Parameter N                        4

}

这种表已在ATSC M/H系统中用于传送传输参数信道(TPC)，快速信息信道(FIC)和服务地图表(SMT)。TPC提供在M/H通信协议中的配置和相对位置。FIC提供M/H服务(例如，虚拟信道)和M/H总体(ensemble)(M/H数据结构)之间的绑定信息。SMT提供M/H服务(例如，虚拟信道)和IP数据报之间的绑定信息。

这些表是对信令信息来说，比特效率较高的格式，不过几乎没有为修改或扩展该格式留下任何空间。如图所示，这种方案不支持协议版本管理；包括在表中的版本管理比特被用于用信号通知(signal)是否存在对用信号通知的数据的改变，不是对与协议本身相关的信令或其它功能的改变。

提供期望的可扩展性的一种选择是简单地把表(或者表的各个部分)的版本管理信息包括在表内。

使用静态数据表的另一种备选方案是使用树形数据结构。图5图解说明例证的树形数据结构。数据树可包括根节点，一个或多个“子节点”(或“分枝”)，和每个分枝的一个或多个叶。根据需要，树也可具有另外的多层，例如“亚子节点”(或者“细枝”)。

树形数据结构便于关于每个节点和/或叶的版本管理信息和一个或多个实际值(例如，参数值)，单独定义每个节点和/或叶。树形数据结构还允许增加节点，而不破坏向后兼容性。从而，与静态数据表相比，树形数据结构可提供明显更高的可扩展性和向前兼容性。取决于和树一起使用的命令集，利用树形数据结构的通信可能招致相当大的额外开销，例如，与静态表相比，比率效率较低。不过，借助比特效率高的命令集，比如下面关于图15-17说明的命令集，可显著减轻该问题，例如，在比特效率高的命令集的条件下，利用树形数据结构的通信在比特效率方面与利用数据表相当。

图6和7ATSC M/H功能块

图6图解说明ATSC M/H系统到一组用于版本管理的功能块的例证划分。这里术语“版本管理”被用于指定向功能的更新分配修订编号，和按照同时支持与传统接收机和当前形式的接收机的鲁棒通信的方式，传送修订编号的方法。所述方法随后可被用于同时把来自给定发射机的服务扩展到传统接收机和当前一代接收机。

如图6中所示，功能块可被划分成协议栈的多层。从而，在一个实施例中，存在表现层、管理层和物理层。每个协议层可包括许多元件；例如，如图所示，表现层可包括服务指南，图形元件，字幕，音频编解码器，视频编解码器。也可预想各种其它协议栈，包括不同的协议层和/或协议层内的不同元件。例如，应注意的是本发明的一些实施例为修改或替换接收机的协议栈作准备。从而，在一个实施例，新的协议版本可指定协议栈的一个或多个元素的增加、替换、退出或者重新排列。在一个实施例中，树形结构，比如图7中的树形结构可被用于按照修订后的协议栈(例如，如果支持新的协议版本的话)，或者按照先前的协议栈(例如，如果不支持新的协议版本的话)，导航和配置设备。

图7图解说明在图6中描述的ATSC M/H协议栈的一部分的树形形式。可以树(例如，协议栈)的相应节点(例如，协议层)的叶的形式，列举每个协议元件。从而，能够分别对每个节点和元件进行版本管理。

图8和9例证的体系结构

图8和9图解说明信令和/或版本管理处理功能在系统中位于下部，和/或与服务的处理分离的例证接收机系统体系结构。这可减轻关于图4讨论的问题。图8和9只是例证性的，从而应注意其它接收机体系结构也是可能的。

图10分组格式

图10图解说明按照一个实施例，可用于传送多媒体流的信令/版本管理数据(或者简单地说“控制信息”)的分组格式。如图所示，分组可包括报头字段，长度字段，片段数字段，服务描述符字段，命令/修饰符字段，数据字段和CRC 16字段。报头、长度、片段数、服务描述符和CRC 16的位置可以是固定的。服务描述符的内容可以是可配置的。控制流本身可包括级联的一系列命令/修饰符/数据半位元组(nibble)。尽管图10表示一个例证的分组格式，不过任意许多的其它分组格式也是可能的，包括具有不同大小的字段，追加的字段，更少的字段，类似但修改后的字段，和/或任意许多其它差别的分组。下面关于图11，提供该例证分组格式的各个字段的定义和进一步说明。

图11控制分组字段的表格

图11是按照一个实施例，定义控制分组的各个字段的表格。如上关于图10所述，在一个实施例中，所述各个字段包括报头、长度、片段数、服务描述符、命令/修饰符、数据和CRC 16。

报头的长度可以为4比特(1个半位元组)。报头可包括控制分组的版本号。换句话说，这提供一种用信号通知信令方法本身的版本管理信息的手段。从而，尽管下面说明的各个字段可定义1.0版控制分组中的各个字段，不过，未来的版本可不同地定义各个字段，或者可包括不同的字段；通过用信号通知信令方法的版本，接收机能够应付未来对信令方法的更新(例如，通过更新接收机的软件以适应所述新版本，或者如果不兼容新版本的话，那么忽略所述新版本)。

长度字段的长度可以为8比特(2个半位元组)。长度字段以字节为单位，给出分组主体的长度(分组主体被定义为在分组长度字段之后开始，并且结束于分组的最后一个字节的各个字段)。依据分组报头认识到它不支持该分组的接收机至少能够解析长度字段，以确定该分组的大小，从而，确定它应跳过多远，以开始尝试解析控制流中的下一个分组。

片段数字段的长度可以为4个比特(1个半位元组)。片段数字段给出分组中的片段的数目，起始于值0001(例如，而不是起始于值0000)。值0000可以是指示未使用任何片段的特殊值。

服务描述符可以是可变数量的比特。服务描述符字段把版本管理的信令流映射到由服务标识符(IP地址)，主频道号等参考的服务。服务描述符，或者服务发现表可被用于索引控制信息，以致接收机可确定它能够和不能支持控制信息中的哪个或哪些部分，和/或控制信息的哪个部分可能与接收机尝试表现的特定服务相关。下面参考图12-14，给出服务描述符的实施例的更多细节。

命令字段、修饰符字段和数据字段构成控制分组的控制信息。换句话说，这些字段中的命令、修饰符和数据可以是导航用于配置视听设备，以表现伴随的多媒体流的信令/版本管理信息的结构(例如，树形结构)的手段。按照一个实施例，每个命令、修饰符或数据字段可以为4比特(1个半位元组)，或者可以半位元组为增量无限扩展。从而，这些手段是可扩展的。下面参考图15-17，给出这里称为“可扩展控制语言”(“XCL”)的命令集的实施例的更多细节。

CRC 16是在分组的整个长度范围内计算的16比特循环冗余检验，它可用于检错/纠错。

图12服务描述符格式

图12按照一个实施例，图解说明XCL分组中的服务描述符字段的格式。服务描述符可被格式化成具有可配置的列类型的表格。服务描述符字段可包括分别用于：服务描述符种类，服务描述符长度，列数，和列长度的子字段。服务描述符字段还可包括表中的每一列的列类型子字段和数据子字段。

图13服务描述符字段的表格

图13是按照一个实施例，定义构成XCL分组的服务描述符字段的子字段的表格。如上关于图12所述，可存在服务描述符种类子字段，服务描述符长度子字段，列数子字段，列长度子字段，列类型子字段，和数据子字段。每个子字段的长度可以为4比特(1个半位元组)，或者可以半位元组为增量无限扩展。

服务描述符种类可用于对服务描述符进行版本管理。换句话说，可独立于整个控制分组的版本管理(或者除此之外)，独立地对服务描述符进行版本管理。从而，尽管下面说明的字段可定义一个版本的服务描述符的子字段，不过，未来的版本可不同地定义下面的字段，或者可包括不同的字段；通过作为报头用信号通知版本，在实际尝试解析服务描述符的主体之前，接收机能够确定它是否能够解析该服务描述符。从而，如果接收机未被配置成解析特定的服务描述符，那么它可更新其软件，以适应新版本，或者如果接收机不能适应新版本，那么忽略新版本。

服务描述符长度子字段以半位元组为单位，规定服务描述符字段的长度。依据服务描述符种类认识到它不能支持该服务描述符的接收机至少能够解析服务描述符长度子字段，以确定服务描述符的大小，从而它应跳过多远，以开始尝试解析控制流中的下一条信息(比如，它能够解析的另一个服务描述符)。

列数(或者说“NumColumns”)子字段规定表中的列数，它实际上还规定跟随的列类型子字段和数据子字段的数目。列长度子字段指定每个列中项的数目。所有各列可以长度相同。通过包括规定列数和各列的长度的字段，服务描述符实质上能够定义它自己。从而，服务描述符可以是设计非常灵活的数据结构，可能允许格式方面、从而提供的信息方面的相当大量的修改和/或变化，而不需要新的协议版本。

列类型子字段规定下一个数据字段中的信息的类型。对于给定的服务描述符版本，可以列举各种可能类型的信息；例证的类型可以是版本号，流ID，IP地址，主频道号，或者副频道号。

数据子字段规定列的每一项的值。如上所述，项数由列长度子字段规定。每一项的长度可被规定(例如定义)成列类型的一部分。例如，如果列类型为IPv4，那么项目可以为32比特。

图14例证的服务描述符字段

图14是表示用子字段分解的例证服务描述字段的表格。在这个例子中，服务描述符种类的值可为指示基本版本的“0000′。服务描述符长度可为“1011′，指示在服务描述符中存在11(二进制的1011)个半位元组。列数可以为“0011”，指示存在3(二进制的0011)列。列长度可以为“0001”，指示每列包含1项。接下来可以是后面分别是1项数据子字段的三个列类型子字段。在这个例子中，列类型是版本号(列举为“0000”)，主频道号(列举为“0001”)和偏移向量(0010)。换句话说，该服务描述符规定主频道“0001”的控制信息(基本版本“0000”的控制信息)位于偏移向量0010。

可以使用单个服务描述符来索引控制信息的多个部分。例如，服务描述符可以指向可能用于特定服务和/或具有特定协议版本的第一组命令，还可指向可能用于不同的服务和/或具有不同协议版本的第二组命令。从而，如果存在多组命令，但是只有一组命令具有1.0的基本版本，所有其它各组命令具有更高的基本版本，那么只能支持基本版本1.0的传统接收机可解析该服务描述符，从而确定它能够支持具有1.0的基本版本的一组命令，但是不支持(于是能够忽略或跳过)具有更高基本版本的各组命令。

另外或者另一方面，在一些实施例中，可以使用多个服务描述符。例如，可以与较老的协议版本的服务描述符一起使用新协议版本的服务描述符，以使传统设备能够确定它可接收的服务，还使当前设备能够利用具有新协议版本的服务描述符来确定它可接收的服务。在一些实施例中，当前设备可利用多于一个的(例如，在这个例子中，新的和旧的)服务描述符来确定它可接收的服务。

图15命令序列格式

图15是图解说明一系列命令/数据的一种可能格式的表格。如图所示，存在下述字段：待执行的命令，以字节为单位的命令有效负载的长度(例如，使传统接收机可以跳过未知命令)，指定待规定的参数所位于的叶或节点的一个或多个导航字段，和要设定的实际参数。

图16XCL命令集

如上所述，在控制分组中的服务描述符字段之后，可存在级联的一系列命令/修饰符/数据半位元组。图16是定义传送和导航树形数据结构的一组可能命令的表格。如上所述，这里把命令语言的这个实施例称为“XCL”。

XCL语言是一种灵活、可扩展的数据构成方法，更具体地说，是一种以比特效率非常高的方式编码基于树的信息的方法。所述方法可包括后面是可变的许多数据字段的一组命令，用于传达树中的节点和位于每个节点的对应参数值。所述方法类似于把数据表分成各组参数，并把每组封装在规定参数集在表中的位置的表头中。事实上，应该存在另一种可能的实施例。这种结构化格式的参数的表示支持以向前兼容的方式，增加或减少参数集。遇到未被识别的节点的传统接收机能够跳过，随后继续解析它们支持的数据。

所述语言还可包括一组修饰符，所述一组修饰符是能够跨越树的多个部分应用的参数，能够实现一种表达众多节点具有类似性质的值的简化方式，从而不需要单独表述到每个节点的路径，和每个修改参数的值。这种能力与用表头封装多组参数的表头相当。这种能力的例证用途可包括用于规定树的某一部分上的所有参数兼容ATSC M/H1.0版，或者树的某一部分上的参数与树的另一部分上的参数相同，差异极小的修饰符。当使用修饰符来规定后一种用途时，可以只规定相当节点的位置以及差异。

在一个实施例中，可在半位元组，字节或者任何其它固定的边界组织命令和数据字段。以半位元组边界作为一个例证实施例，每个半位元组中的一个比特可用于把该半位元组标记为命令或者数据。例如，在一个实施例中，可以使用最高有效位(MSB)。从而，在这个实施例中，如果MSB为“0”，那么这标记命令，而作为MSB的“1”标记数据。这种、或者如此标记命令和数据半位元组的任何类似约定可能有益于使接收机能够解析命令和数据信息，例如，接收机能够确定均始于“0”的一系列半位元组是命令，跟在这些命令之后的均始于“1”的一个或多个半位元组是由这些命令规定的数据。从而，接收机可解析后面是数据(例如，树中的一个节点或叶的参数)的一系列命令(例如，导航到所述节点或叶)，和可识别数据结束于何处，下一系列的命令以MSB为“0”的下一个半位元组为起点。在一些实施例中，这可节约利用专用长度字段向接收机指出每个命令序列有多长的开销。在一些实施例中，长度字段仍可与一些或全部的命令一起使用。命令或数据字段的三个最低有效位(LSB)可指示字段的列举命令或数据值是什么。

如果需要，那么通过把三个LSB设定为“111”，或者在其它实施例中，设定为规定表示字段扩展的任何其它值，可以扩展命令或数据字段。这样，可无限扩展命令集，而不干扰传统接收机的解析命令流的能力。即，即使接收机不认识扩展字段中的命令，接收机仍然能够认识到该字段被扩展，并跳到下一个字段。

图16包括按照一个实施例的每个命令的简要描述。下面更详细地说明这些可能命令中的每个命令。

节点(或组)指针指向分层树形结构中的参数(或一组参数)。节点命令结合导航与参数指定。节点命令包括数目可变的数据字段，一些数据字段规定遍历过的节点，一个数据字段规定叶位置，最后一个数据字段规定参数/函数集。当利用节点命令时，当前节点位置被设定为刚好在为设定该参数而引用的叶之上的节点。例如，如果接收机位于默认节点0，并且我们期望把在位置0.1.0.0的叶设为value_1，那么命令会是0001(命令)，1001(数据)，1000(数据)，1000(数据)，value_1(数据)。最后的数据字段是参数值。倒数第二个数据字段是叶位置，当前节点刚好在0.1.0之上。

下降命令规定到分层树形结构中，在当前位置之下的参数位置的相对路径(向下的路径)。该命令用于导航到树中的新节点。下降命令包括数目可变的数据字段，每个数据字段指定要遍历的一个节点。依据在下降命令之后，在下一个命令半位元组之前跟随有多少个数据字段，可确定要遍历的节点的总数。例如，如果接收机目前指向默认节点0，并且期望指向节点0.1.1，那么下降命令应是0100(命令)，1001(数据)，1001(数据)。显示命令和数据值，同时按其类型(例如，命令或数据)设定其MBS。接收机可跟踪当前节点位置，从而可相对于当前节点，配置所有导航命令。另一方面，每个导航命令可从根节点开始；这种情况下，下面描述的上升命令是不必要的。

上升命令规定在分层树形结构中，要遍历(向上)的层数。上升命令依据规定的层数，反转下降命令。由于树中的每个子节点只有一个父节点，因此不需要任何进一步的指定。

修饰符命令规定应用于分层结构中，在当前位置之下的所有参数的值。修饰符命令是用于指定在树的多个部分，而不只是在一个位置的参数的特殊命令。使用修饰符命令的第一步骤是利用下降命令，导航到树中的期望节点位置。随后通过在下降命令之后增加修饰符命令和相关字段，应用所述修饰符。修饰符可被插入XCL命令中的任意地方，不过当这样放置修饰符，以致指定参数的导航和指定修饰符的导航被结合时最高效。当按照这样的方式排列树化数据，以致能够用公共值设定的参数被一起聚集在相同节点下时，修饰符也是最高效的。

尽管该组命令是XCL的一个可能实施例，不过，许多其它变化，比如图24中所示的命令集也是可能的。

图17XCL命令集修饰符

如上所述，修饰符命令规定接下来的数据包括应用于当前节点之下的树的所有节点的特定修饰符和一个或多个对应的修饰符值。图17是按照一个实施例，列举和定义每个这些修饰符的表格。下面进一步说明所有这些可能的修饰符。

子版本(或者说协议世代)修饰符指定在当前节点之下的各个节点上指定的参数的协议子世代。这是特定的基本子系统的世代。整个服务的协议世代可由被导航的树的根位置指定。

例外修饰符指定在当前节点之下的各个节点上的数据参数是最近指定的修饰符的例外。

可选修饰符指定在当前节点之下的各个节点上的任意数据参数是可选的扩展。除非借助后面是应用于参数所存在的节点的“可选”数据字段的修饰符命令另有说明，否则需要指定的所有参数。该修饰符有益于在服务中包括可选组件，例如，基本协议版本与整体服务不同的组件。这会使传统设备可以在无可选组件的情况下利用服务，而更新的接收机可使用(例如，服务增强)可选组件。

复制修饰符指定在该位置复制的分层节点。即，来自指定节点的所有参数可被复制到当前位置。

可为未来的应用保留一个或多个值，以及用于扩展修饰符字段，例如，即使保留的所有值都被使用，仍然允许定义多个修饰符的值。在所示的实施例中，关于修饰符的“扩展字段”值为“1111”。

尽管图17表示了一组可能的命令修饰符，不过许多实施例也是可能的；例如，一种备选实施例示于图25中。

图18ATSC M/H树

图18按照一个实施例，图解说明树形形式的ATSC M/H协议栈的一部分。利用上面说明的命令，能够对这样的树进行导航，可按照比特效率高的方式提供版本管理和参数信息。

图19ATSC M/H树

图19图解说明ATSC M/H树的另一种表示。注意该树包括所有的系统配置信令“表”，例如，FIC，SMT，CIT，STT，SLT和GAT的叶，以致这些表(或树)也可被版本管理。在一些实施例中，具体地可按照利用命令语言(例如，XCL)的优点的方式排列这样的树，所述命令语言将被用于对所述树编码。例如，可最佳地构成表数据，以通过使所需节点数降至最小，和使在每个节点的叶的数目达到最大，充分利用XCL能力。这可使导航开销降至最低。取决于使用的命令语言，某些规则也可应用于这种树的构成。例如，对上面说明的XCL实施例来说，可应用下述规则：

1)节点仅仅用于导航，不包含参数(数据)。

2)新节点只能够被增加到另一个节点上(而不是增加到叶上)。

3)节点被放置在树中未来需要增加参数的位置。

4)参数位于叶上。叶是位于节点的端头的位置。

这些规则只是例证性的，从而要请注意的是，取决于使用的命令集，不同的一组规则可能是必需的，或者有助于提高信令架构的效率。

在一些实施例中，一般每代协议，可定义一次给定树(例如，FIC树)。可在保持顺序的情况下，作为对原始树的修改，实现对表格的后续增加和减小，以致树中的位置表达信息(例如，起源于节点0的树始终是第一代协议服务)。

当构成数据的信令结构时，数据被树化的程度控制数据的灵活性和可扩展性。为了最高的灵活性，每个参数可以位于独立的叶上(例如，对树进行完全分解)。另一方面，通过在每个叶对参数分组(例如，对树进行部分分解)，可获得更高效的信令结构。

图20FIC树

图20图解说明FIC的部分分解的树形表示，包括在每个节点的供未来扩展该树之用的假设节点。该树可以与图19的树结合使用(例如，FIC根节点是图19中所示的系统配置树中的节点0.8.0)。例如，如图所示、但是没有“未来字段”的树可以是1.0版FIC树。1.1版FIC树可包括其中表示一个或多个“未来字段”的一个或多个附加字段。这种情况下，附加节点和/或叶是1.1版，而初始节点和叶保持1.0版。2.0版FIC树可具有完全不同的结构，例如，重新排列的结构，或者包括不同的字段。

图21FIC树的例证编码

图21按照上面关于图15-17说明的XCL实施例，表示图20中所示的FIC表的一部分的例证编码。图21仅仅表示控制分组(例如，控制信息)的命令/数据部分；应注意在一些实施例中，这只是还包括其它字段(例如，比如图10中说明的分组报头，长度等等)的控制分组的一部分。

图22SMT树

图22图解说明SMT的部分分解的树形表示，包括在每个节点的供未来扩展该树的假定节点。该树可以与图19的树结合使用(例如，SMT根节点是图19中所示的系统配置树中的节点0.5.0)。例如，如图所示、但是没有“未来字段”的树可以是1.0版SMT树。1.1版SMT树可包括其中表示一个或多个“未来字段”的一个或多个附加字段。这种情况下，附加节点和/或叶可以是1.1版，而初始节点和叶可保持1.0版。2.0版SMT树可具有完全不同的结构，例如，重新排列的结构，或者包括不同的字段。

图23SMT树的例证编码

图23按照上面关于图15-17说明的XCL实施例，表示图22中所示的SMT表的一部分的例证编码。图23中所示的代码可以是由在图23的顶部所示的“报头”、“长度”、“片段数”和“服务描述符”字段指示的更大的控制分组的一部分。

图24和25XCL命令的备选实施例

图24和25分别表示XCL命令和命令修饰符的备选实施例。从而，尽管关于图15-17表示和说明的XCL是用于对基于树的信息编码的命令集的一个实施例，不过另一方面，图24和25中所示的命令集，或者任何这样的命令集可根据需要，被用作以比特效率非常高的方式对基于树的信息编码的灵活且可扩展的方法。

图26-28FIC和SMT数据树的备选实施例

图26-28表示数据树的几个备选实施例。图26表示按照一个实施例的完全分解的树形表示。完全分解数据树使树的灵活性和可扩展性达到最大，仍可利用“复制”命令修饰符有效地利用冗余，以使因完全分解数据树而产生的额外导航开销降至最小。

另一方面，代替完全分解数据树，也可以部分分解数据树，如图27中所示。这样，类似的或者可以同时或用相同方式修改的各组叶可被用于减少对树进行导航时所涉及的开销。不过，这限制了树的灵活性和可扩展性，必须恰当地设计分组，以预期哪些叶可能同时和按相同方式改变。

图28表示部分分解的SMT数据树的一个备选实施例。

尽管上面相当详细地说明了实施例，不过一旦充分理解上面的公开内容，对本领域的技术人员来说，众多的变化和修改将是显而易见的。下面的权利要求意图包含所有这样的变化和修改。

Claims (18)

1.一种生成供和多媒体流一起传输给视听设备之用的控制信息的方法，所述方法包括：

生成第一控制信息，其中第一控制信息用于配置视听设备，以表现多媒体流，其中第一控制信息是按照第一协议版本生成的；

生成第一数据结构，其中第一数据结构包含和第一控制信息有关的信息，其中第一数据结构指定第一控制信息是第一协议版本的控制信息；

生成和传输第一多个分组，第一多个分组包含由第一控制信息指定的至少一个多媒体流、第一控制信息和第一数据结构；

生成第二控制信息，其中第二控制信息用于配置视听设备，以表现多媒体流，其中第二控制信息是按照第二协议版本生成的；

修改第一数据结构，以包括与第二控制信息有关的附加信息，其中修改后的第一数据结构指定第二控制信息是第二协议版本的控制信息，其中修改后的第一数据结构保留与第一控制信息有关的信息；

生成和传输第二多个分组，其中第二多个分组包含修改后的第一数据结构、第一控制信息、由第一控制信息指定的多媒体流、第二控制信息和由第二控制信息指定的多媒体流；

其中第一数据结构与第一控制信息分离。

2.按照权利要求1所述的方法，

其中第一控制信息用于把视听设备配置成按照第一方式表现多媒体流；

其中第二控制信息用于把视听设备配置成按照第二方式表现多媒体流。

3.按照权利要求1所述的方法，

其中第一数据结构指定第一控制信息位于的第一多个分组之中的一个或多个位置；

其中修改后的第一数据结构指定第二控制信息位于的第二多个分组之中的一个或多个位置。

4.按照权利要求1所述的方法，

其中与第一控制信息有关的信息指定第一控制信息中的第一命令的一个或多个种类以及一个或多个位置；

其中与第二控制信息有关的附加信息指定第二控制信息中的命令的一个或多个种类以及一个或多个位置。

5.按照权利要求1所述的方法，

其中所述修改第一数据结构包含修改第一数据结构的格式；

所述方法还包括修改指定第一数据结构的格式的信息，以反映所述修改第一数据结构。

6.按照权利要求5所述的方法，

其中所述修改指定第一数据结构的格式的信息包含对修改后的第一数据结构的版本信息进行修改。

7.按照权利要求5所述的方法，

其中所述修改指定第一数据结构的格式的信息包含对修改后的第一数据结构的大小信息进行修改。

8.按照权利要求1所述的方法，

其中所述修改第一数据结构包含修改第一数据结构的格式；

其中第一数据结构包含指定第一数据结构的格式的信息；

所述方法还包括对修改后的第一数据结构中的、指定第一数据结构的格式的信息进行修改，以反映所述修改第一数据结构。

9.按照权利要求1所述的方法，还包括：

生成第三控制信息，其中第三控制信息用于配置视听设备，以表现多媒体流，其中第三控制信息是按照第三协议版本生成的；

生成第二数据结构，以包含和第三控制信息有关的信息；

生成和传输第三多个分组，其中第三多个分组包含修改后的第一数据结构、第一控制信息、由第一控制信息指定的多媒体流、第二控制信息、由第二控制信息指定的多媒体流、第三数据结构、第三控制信息和由第三控制信息指定的多媒体流。

10.按照权利要求1所述的方法，其中第一数据结构包含识别第一控制信息的第一协议版本和第一控制信息的位置的信息，其中识别第一控制信息的第一协议版本和第一控制信息的位置的信息能被视听设备用于忽略第一控制信息，如果视听设备未被配置成解析第一控制信息的第一协议版本的话。

11.按照权利要求1所述的方法，

其中第一数据结构被配置成是可扩展的，以增加与附加控制信息相关的附加信息。

12.按照权利要求1所述的方法，其中第一数据结构包含多个字段，其中至少一个字段是可扩展的。

13.按照权利要求12所述的方法，其中至少一个可扩展字段是通过把该字段的值设定为特定值而扩展的，其中所述特定值向视听设备指出该可扩展字段被扩展。

14.按照权利要求1所述的方法，

其中第一数据结构能配置为包括与在随后生成的分组中的附加控制信息相关的附加信息。

15.按照权利要求1所述的方法，其中第二多个分组包含指定包含在第二多个分组中的许多数据结构的信息。

16.一种把多媒体流的控制信息传输给视听设备的系统，所述系统包括：

传输逻辑，所述传输逻辑被配置成：

生成第一控制信息，其中第一控制信息用于配置视听设备，以表现多媒体流，其中第一控制信息是按照第一协议版本生成的；

生成第一数据结构，其中第一数据结构包含和第一控制信息有关的信息，其中第一数据结构指定第一控制信息是第一协议版本的控制信息；

生成和传输第一多个分组，第一多个分组包含按照第一协议版本的多媒体流、第一控制信息和第一数据结构；

生成第二控制信息，其中第二控制信息用于配置视听设备，以表现多媒体流，其中第二控制信息是按照第二协议版本生成的；

修改第一数据结构，以包括与第二控制信息有关的附加信息，其中修改后的第一数据结构指定第二控制信息是第二协议版本的控制信息，其中修改后的第一数据结构保留与第一控制信息有关的信息；

生成和传输第二多个分组，其中第二多个分组包含修改后的第一数据结构、第一控制信息、按照第一协议版本的多媒体流、第二控制信息和按照第二协议版本的多媒体流；

其中第一数据结构与第一控制信息分离。

17.一种由视听设备执行的接收和表现多媒体内容的方法，所述方法包括：

接收第一多个分组，第一多个分组包含第一数据结构、第一控制信息和由第一控制信息指定的至少一个多媒体流；

其中第一数据结构包含和第一控制信息有关的信息，其中第一数据结构指定第一控制信息是第一协议版本的控制信息；

利用第一控制信息配置视听设备，以表现所述至少一个多媒体流，其中第一控制信息是按照第一协议版本格式化的；

接收第二多个分组，其中第二多个分组包含修改后的第一数据结构、第一控制信息、由第一控制信息指定的多媒体流、第二控制信息和由第二控制信息指定的多媒体流；

其中修改后的第一数据结构包括和第二控制信息有关的附加信息，其中修改后的第一数据结构指定第二控制信息是第二协议版本的控制信息，其中修改后的第一数据结构保留和第一控制信息有关的信息；

利用第二控制信息配置视听设备，以表现多媒体流，其中第二控制信息是按照第二协议版本格式化的；

其中第一数据结构与第一控制信息分离。

18.一种接收多媒体流的控制信息的系统，所述系统包括：

接收第一多个分组的输入，其中第一多个分组是用无线方式传输的，其中第一多个分组包含第一多媒体流、第一控制信息、第二控制信息和第一数据结构；

其中第一数据结构包含第一控制信息和第二控制信息的位置信息，其中第一数据结构还指定第一控制信息的第一协议版本，和第二控制信息的第二协议版本；

与所述输入耦接的接收机逻辑，其中接收机逻辑被配置成：

分析第一数据结构，以确定第一控制信息和第二控制信息的位置信息，及第一控制信息和第二控制信息的第一和第二协议版本；

按照第一控制信息配置视听设备，所述配置使视听设备能够表现第一多媒体流；

在所述配置之后，表现第一多媒体流；

其中视听设备未被配置成理解第二协议版本；

其中视听设备利用第二控制信息的位置信息忽略第二控制信息；

其中第一数据结构与第一控制信息分离。