发送广播信号的设备和方法以及接收广播信号的设备和方法

本申请是2016年8月31日提交的国际申请日为2016年2月29日的申请号为201680000809.1(PCT/KR2016/001994)的，发明名称为“用于发送广播信号的设备、用于接收广播信号的设备、发送广播信号的方法和接收广播信号的方法”的专利申请的分案申请。

技术领域

本发明涉及用于发送广播信号的设备、用于接收广播信号的设备、发送广播信号的方法以及接收广播信号的方法。

背景技术

随着模拟广播信号传输终结，已经开发用于发送/接收数字广播信号的各种技术。数字广播信号与模拟广播信号相比可包括更大量的视频/音频数据，并且除了视频/音频数据以外还包括各种类型的附加数据。

发明内容

技术问题

即，数字广播系统可提供高清晰度(HD)图像、多声道音频和各种附加服务。然而，用于大量数据的传输的数据传输效率、发送/接收网络的鲁棒性以及考虑移动接收设备的网络灵活性需要被改进以用于数字广播。

技术方案

根据本发明的目的，如在此包括和简要地描述的，本发明提出在使用陆地广播网络和互联网协议(IP)网络支持下一代混合广播的环境中有效地支持下一代广播服务的系统，和有关信令方案。

有益效果

本发明提出使用广播网络和IP网络有效地提供混合广播的方法。

本发明提出基于用于基本广播服务的应用提供基于应用的增强的方法。

本发明提出提供与广播服务同步的基于应用的增强的方法。

本发明提出根据主装置(PD)和配套装置(companion device，CD)之间的各种协议和应用之间的通信方案提供架构。

本发明提出从PD侧到CD侧有效地递送关于电子服务指南(ESG)、紧急报警系统(EAS)等的信息的架构。

附图说明

附图被包括以提供对本发明的进一步理解，附图示出本发明的实施例并且与说明书一起用于说明本发明的原理。

图1示出根据本发明的实施例的接收机协议栈。

图2示出根据本发明的实施例的SLT与SLS之间的关系。

图3示出根据本发明的实施例的SLT。

图4示出根据本发明的实施例的SLS引导和服务发现处理。

图5示出根据本发明的实施例的用于ROUTE/DASH的USBD分段。

图6示出根据本发明的实施例的用于ROUTE/DASH的S-TSID分段。

图7示出根据本发明的实施例的用于MMT的USBD/USD分段。

图8示出根据本发明的实施例的链路层协议架构。

图9示出根据本发明的实施例的链路层分组的基本头的结构。在下文中，将会描述报头的结构。

图10示出根据本发明的实施例的链路层分组的附加头的结构。

图11示出根据本发明的另一实施例的链路层分组的附加头的结构。

图12示出根据本发明的实施例的用于MPEG-2TS分组的链路层分组的头结构及其封装处理。

图13示出根据本发明的实施例的IP头压缩中的适配模式的示例(发送侧)。

图14示出根据本发明的实施例的链路映射表(LMT)和RoHC-U描述表。

图15示出根据本发明的实施例的发送机侧的链路层的结构。

图16示出根据本发明的实施例的接收机侧的链路层的结构。

图17示出根据本发明的实施例的通过链路层的信令传输的配置(发送侧/接收侧)。

图18是示出根据本发明的实施例的用于未来广播服务的广播信号发送设备的配置的框图。

图19是示出根据本发明的实施例的比特交织编译和调制(BICM)块的框图。

图20是示出根据本发明的另一实施例的BICM块的框图。

图21是示出根据本发明的实施例的物理层信令(PLS)的比特交织处理的图。

图22是示出根据本发明的实施例的用于未来广播服务的广播信号接收设备的配置的框图。

图23是示出根据本发明的实施例的帧的信令层次结构的图。

图24是示出根据本发明的实施例的PLS1数据的表。

图25是示出根据本发明的实施例的PLS2数据的表。

图26是示出根据本发明的另一实施例的PLS2数据的表。

图27是示出根据本发明的实施例的帧的逻辑结构的图。

图28是示出根据本发明的实施例的PLS映射的图。

图29是示出根据本发明的实施例的时间交织的图。

图30是示出根据本发明的实施例的扭曲行-列块交织器的基本操作的图。

图31是示出根据本发明的另一实施例的扭曲行-列块交织器的操作的图。

图32是示出根据本发明的实施例的根据各个FFT模式的包括主伪随机二进制序列(PRBS)生成器和次PRBS生成器的交织地址生成器的框图。

图33是示出根据本发明的实施例的用于所有FFT模式的主PRBS的图。

图34是示出根据本发明的实施例的用于FFT模式的次PRBS和用于频率交织的交织地址的图。

图35是示出根据本发明的实施例的时间交织器的写入操作的图。

图36是示出根据PLP的数量应用的交织类型的表。

图37是包括混合时间交织器的结构的第一示例的框图。

图38是包括混合时间交织器的结构的第二示例的框图。

图39是包括混合时间解交织器的结构的第一示例的框图。

图40是包括混合时间解交织器的结构的第二示例的框图。

图41图示根据本发明的实施例的应用相关的广播服务。

图42图示根据本发明的实施例的ApplicationList元素的一部分。

图43图示根据本发明的实施例的ApplicationList元素的另一部分。

图44图示根据本发明的实施例的事件消息表(EMT)。

图45图示根据本发明的实施例的通过发送侧提供广播服务的方法。

图46图示根据本发明的实施例的用于通过发送侧提供广播服务的设备。

图47图示根据本发明的实施例的通过广播网络发送的AST。

图48图示根据本发明的实施例的通过宽带网络发送的AST。

图49图示根据本发明的实施例的通过广播网络以EventStream元素的形式发送事件。

图50图示根据本发明的实施例的通过广播网络以emsg盒的形式发送事件。

图51图示根据本发明的实施例的通过宽带网络以EventStream元素的形式发送事件。

图52图示根据本发明的实施例的以emsg盒的形式发送事件。

图53图示根据本发明的实施例的API和事件监听器。

图54是根据本发明的实施例的电子装置的框图。

图55是用于根据本发明的实施例的第一客户端的连接的描述的图。

图56是用于根据本发明的实施例的第二客户端的连接的描述的图。

图57是用于根据本发明的实施例的在第一和第二客户端之间的连接的描述的图。

图58是根据本发明的实施例的用于附加连接请求的描述的图。

图59是根据本发明的实施例的用于当IP地址不存在时在客户端之间的连接的描述的图。

图60是根据本发明的实施例的用于在应用之间的连接的备用连接的描述的图。

图61是根据本发明的实施例的用于对于与第二客户端的连接的新连接请求的描述的图。

图62是用于根据本发明的实施例的当包括IP地址时第一客户端的设置的描述的图。

图63是根据本发明的实施例的用于当包括IP地址时第一客户端和第二客户端的设置的描述的图。

图64是用于当包括IP地址时到多个第二客户端的连接的实施例的描述的图。

图65是根据本发明的实施例的控制电子装置的方法的流程图。

图66是图示根据本发明的实施例的主物理装置和配套物理装置的配置的图。

图67是图示根据本发明的实施例的用于支持混合广播服务的协议栈的图。

图68是图示根据本发明的实施例的UPnP方案的行为机制的图。

图69是图示根据本发明的实施例的REST机制的图。

图70是图示使广播接收机和配套装置交换电子服务指南(ESG)的服务的图。

图71是图示根据本发明的实施例的ESGData状态变量的图。

图72是图示根据本发明的实施例的ESGData状态变量的图。

图73是图示根据本发明的实施例的将ESGData状态变量递送给配套装置的过程的图。

图74是图示根据本发明的实施例的LastChangedESGData状态变量的图。

图75是图示根据本发明的实施例的其中根据GetESGData行为将ESG数据递送给配套装置的过程的图。

图76是图示根据本发明的实施例的根据GetServiceIds和GetESGbyServiceIds行为将ESG数据递送给配套装置的过程的图。

图77是图示根据本发明的实施例的根据GetCurrentServiceId行为将ESG数据递送给配套装置的过程的图。

图78是图示根据本发明的实施例的其中根据SearchESG行为将ESG数据递送给配套装置的过程的图。

图79是图示根据本发明的实施例的用于根据DoAuthenticationForESG行为递送ESG数据的认证过程的图。

图80是图示根据本发明的另一实施例的根据GetServiceIds和GetESGbyServiceIds行为将ESG数据与装置认证同时递送给配套装置的过程的图。

图81是图示根据本发明的实施例的根据GetService行为将ESG数据递送给配套装置的过程的图。

图82是图示根据本发明的实施例的根据SetChangeChannel行为通过配套装置改变广播接收机的服务的过程的图。

图83是图示根据本发明的实施例的提供广播服务的方法的图。

图84是图示根据本发明的实施例的广播接收机的图。

图85是图示根据本发明的基于UPnP的PD-CD架构的图。

图86是图示根据本发明的实施例的基于UPnP的PD-CD架构的图。

图87是图示根据本发明的另一实施例的基于UPnP的PD-CD架构的交互图。

图88图示根据本发明的实施例的基于UPnP的PD-CD架构的交互图。

图89是图示根据本发明的实施例的基于Websocket的PD-CD架构的图。

图90是图示根据本发明的实施例的基于Websocket的PD-CD架构的图。

图91是图示根据本发明的实施例的基于Websocket的PD-CD架构的图。

图92是图示根据本发明的实施例的在基于Websocket的PD-CD架构的应用到应用通信的图。

图93是图示根据本发明的实施例的基于HTTP的PD-CD架构的图。

图94是图示根据本发明的另一实施例的基于HTTP的PD-CD架构的图。

图95是图示根据本发明的实施例的基于Websocket&HTTP的PD-CD架构的图。

图96是图示被用于主装置(PD)的发现的消息的格式的图。

图97是图示使用装置描述文档(DDD)的Websocket端点或者HTTP服务URL的发现过程的图。

图98图示根据本发明的实施例的在使用DDD的Websocket端点或者HTTP服务URL的发现过程中的DDD请求消息和DDD格式。

图99图示根据本发明的实施例的在用于使用DDD的Websocket端点或者HTTP服务URL的发现过程中的DDD的格式。

图100图示根据本发明的另一实施例的在使用DDD的Websocket端点或者HTTP服务URL的发现过程中的DDD的格式。

图101图示根据本发明的实施例的使用对于DDD请求的响应报头的Websocket端点或者HTTP服务URL的发现过程。

图102图示根据本发明的另一实施例的在使用对于DDD请求的响应报头的Websocket端点或者HTTP发现URL的发现过程中的响应报头的格式。

图103图示根据本发明的实施例的使用对于DDD请求的响应报头的URL的Websocket端点或者HTTP服务URL的发现过程。

图104是图示根据本发明的实施例的在使用对于DDD请求的响应报头的URL的用于Websocket端点或者HTTP服务URL的发现过程中的GET请求和根据请求的响应消息的格式的图。

图105是图示根据本发明的另一实施例的用于在使用对于DDD请求的响应报头的URL的用于Websocket端点或者HTTP服务URL的发现过程中用于递送地址信息的响应消息的格式的图。

图106是图示根据本发明的实施例的基于Websocket的握手&连接过程(在发现之后)的图。

图107是图示根据本发明的实施例的用于基于Websocket的应用对应用通信的握手&连接过程的图。

图108是图示根据本发明的实施例的基于Websocket的双向通信过程(在连接之后)的图。

图109是图示根据本发明的实施例的基于Websocket的应用对应用双向通信过程(在连接/CD到PD之后)的图。

图110是图示根据本发明的实施例的基于Websocket的应用对应用双向通信过程(在连接/PD到CD之后)的图。

图111是图示根据本发明的实施例的基于HTTP的请求响应过程(在发现之后)的图。

图112图示根据本发明的另一实施例的XML格式的ESGData状态变量转换成JSON格式的ESGData状态变量的转换。

图113是图示根据本发明的另一实施例的使用Websocket协议将JSON格式的ESGData状态变量递送给配套装置的过程的图。

图114是图示根据本发明的实施例的服务/内容识别消息的图。

图115是图示根据本发明的实施例的在PD中提供广播服务的方法的图。

图116是图示根据本发明的实施例的用于提供广播服务的设备的图。

具体实施方式

现在将详细参考本发明的优选实施例，其示例示出于附图中。下面将参考附图给出的详细描述旨在说明本发明的示例性实施例，而非示出可根据本发明实现的仅有实施例。以下详细描述包括具体细节以便提供对本发明的彻底理解。然而，对于本领域技术人员而言将显而易见的是，本发明可在没有这些具体细节的情况下实践。

虽然从在本领域中广泛地使用的一般术语中已经选择在本发明中选择的大多数术语，通过申请人已经任意地选择一些术语并且根据需要在下面的描述中详细地解释它们的意义。因此，应基于除了它们的简单的名称或者意义之外的术语的所预期的意义理解本发明。

本发明提供用于发送和接收用于未来广播服务的广播信号的设备和方法。根据本发明的实施例的未来广播服务包括地面广播服务、移动广播服务、UHDTV服务等。根据一个实施例，本发明可通过非多输入多输出(MIMO)或MIMO来处理用于未来广播服务的广播信号。根据本发明的实施例的非MIMO方案可包括多输入单输出(MISO)方案、单输入单输出(SISO)方案等。

图1示出根据本发明的实施例的接收机协议栈。

在通过广播网络的广播服务传送中可使用两种方案。

在第一种方案中，基于MPEG媒体传输(MMT)利用MMT协议(MMTP)来发送媒体处理单元(MPU)。在第二方案中，可基于MPEG DASH利用经由单向传输的实时对象传送(ROUTE)来发送HTTP动态适配流(DASH)片段。

利用ROUTE传送包括NRT媒体、EPG数据和其它文件的非时序内容。可经由MMTP和/或ROUTE传送信令，而通过服务列表表格(SLT)提供引导信令信息。

在混合服务传送中，在宽带侧使用经由HTTP/TCP/IP的MPEG DASH。ISO基本媒体文件格式(BMFF)的媒体文件用作传送、媒体封装和同步格式以用于广播和宽带传送二者。这里，混合服务传送可表示通过宽带路径传送一个或更多个节目要素的情况。

利用三个功能层传送服务。这些功能层是物理层、传送层和服务管理层。物理层提供经由广播物理层和/或宽带物理层传输信令、服务声明和IP分组流的机制。传送层提供对象和对象流传输功能。通过MMTP或ROUTE协议允许经由广播物理层在UDP/IP多播上操作，通过HTTP协议允许经由宽带物理层在TCP/IP单播上操作。服务管理层使得诸如线性TV或HTML5应用服务的任何类型的服务能够由下面的传送层和物理层承载。

在该图中，广播侧的协议栈部分可被分成通过SLT和MMTP发送的部分以及通过ROUTE发送的部分。

SLT可通过UDP层和IP层来封装。这里，SLT将在下面描述。MMTP可发送以MMT中定义的MPU格式来格式化的数据以及根据MMTP的信令信息。这些数据可通过UDP层和IP层来封装。ROUTE可发送以DASH片段形式格式化的数据、信令信息以及诸如NRT数据等的非时序数据。这些数据可通过UDP层和IP层封装。根据给定实施例，根据UDP层和IP层的一些或所有处理可被省略。这里，所示的信令信息可以是与服务有关的信令信息。

通过SLT和MMTP发送的部分和通过ROUTE发送的部分可在UDP层和IP层中处理，然后在数据链路层中再次被封装。链路层将在下面描述。在链路层中处理的广播数据可在物理层中通过诸如编码/交织等的处理作为广播信号进行多播。

在该图中，宽带侧的协议栈部分可如上所述通过HTTP来发送。以DASH片段形式格式化的数据、信令信息、NRT信息等可通过HTTP发送。这里，所示的信令信息可以是与服务有关的信令信息。这些数据可通过TCP层和IP层处理，然后被封装到链路层中。根据给定实施例，TCP层、IP层和链路层中的一些或所有可被省略。随后处理的宽带数据可通过用于在物理层中传输的处理在宽带中通过单播来发送。

服务可以是聚合地呈现给用户的媒体组件的收集；组件可以是多种媒体类型；服务可以是连续的或间歇的；服务可以是实时的或非实时的；实时服务可由TV节目的序列组成。

图2示出根据本发明的实施例的SLT和SLS之间的关系。

服务信令提供服务发现和描述信息，并且包括两个功能组件：经由服务列表表格(SLT)和服务层信令(SLS)的引导信令。这些表示发现和获取用户服务所需的信息。SLT使得接收机能够构建基本服务列表，并且针对各个服务引导SLS的发现。

SLT可允许基本服务信息的非常快速的获取。SLS使得接收机能够发现和访问服务及其内容组件。SLT和SLS的细节将在下面描述。

如上文所述，SLT可通过UDP/IP来发送。在这种情况下，根据给定实施例，与SLT对应的数据可通过在此传输中最鲁棒的方案来传送。

SLT可具有用于访问通过ROUTE协议传送的SLS的访问信息。换言之，SLT可根据ROUTE协议被引导至SLS中。SLS是在上述协议栈中位于ROUTE的上层中的信令信息，并且可通过ROUTE/UDP/IP来传送。SLS可通过ROUTE会话中所包括的LCT会话之一来发送。可利用SLS访问与期望的服务对应的服务组件。

另外，SLT可具有用于访问通过MMTP传送的MMT信令组件的访问信息。换言之，SLT可根据MMTP被引导至SLS中。SLS可通过MMT中定义的MMTP信令消息来传送。可利用SLS访问与期望的服务对应的流服务组件(MPU)。如上文所述，在本发明中，NRT服务组件通过ROUTE协议来传送，并且根据MMTP的SLS可包括用于访问ROUTE协议的信息。在宽带传送中，SLS被承载于HTTP/TCP/IP上。

图3示出根据本发明的实施例的SLT。

首先，将描述服务管理、传送和物理层的各个逻辑实体之间的关系。

服务可作为两个基本类型中的一个来用信号通知。第一种类型是线性音频/视频或者仅音频服务(可具有基于应用的增强)。第二种类型是其呈现和构成通过在获取服务时执行的下载的应用来控制的服务。后者可被称为“基于应用的”服务。

关于用于承载服务的内容组件的ROUTE/LCT会话和/或MMTP会话的存在的规则可如下。

对于没有基于应用的增强的线性服务的广播传送，服务的内容组件可通过(1)一个或更多个ROUTE/LCT会话或者(2)一个或更多个MMTP会话中的任一者(但非二者)来承载。

对于具有基于应用的增强的线性服务的广播传送，服务的内容组件可通过(1)一个或更多个ROUTE/LCT会话和(2)零个或更多个MMTP会话来承载。

在特定实施例中，可允许在同一服务中使用MMTP和ROUTE二者来用于流媒体组件。

对于基于应用的服务的广播传送，服务的内容组件可通过一个或更多个ROUTE/LCT会话来承载。

各个ROUTE会话包括一个或更多个LCT会话，该一个或更多个LCT会话整体或部分地承载构成服务的内容组件。在流服务传送中，LCT会话可承载诸如音频、视频或隐藏字幕流的用户服务的各个组件。流媒体被格式化为DASH片段。

各个MMTP会话包括一个或更多个MMTP分组流，该一个或更多个MMTP分组流承载MMT信令消息或者整体或部分地承载内容组件。MMTP分组流可承载MMT信令消息或者被格式化为MPU的组件。

对于NRT用户服务或者系统元数据的传送，LCT会话承载基于文件的内容项。这些内容文件可由NRT服务的连续的(基于时间的)或者离散的(非基于时间的)媒体组件或者诸如服务信令或ESG分段的元数据组成。诸如服务信令或ESG分段的系统元数据的传送也可通过MMTP的信令消息模式来实现。

广播流是对按照在指定带宽内居中的载波频率定义的RF信道的抽象。它通过[地理区域，频率]的对来标识。物理层管道(PLP)对应于RF信道的一部分。各个PLP具有特定调制和编译参数。它通过在它所属于的广播流内唯一的PLP标识符(PLPID)来标识。这里，PLP可被称作DP(数据管道)。

各个服务通过两种形式的服务标识符来标识：紧凑形式，用在SLT中并且仅在广播区域内唯一；和全局唯一形式，用在SLS和ESG中。ROUTE会话通过源IP地址、目的地IP地址和目的地端口号来标识。LCT会话(与其所承载的服务组件关联)通过在父ROUTE会话的范围内唯一的传输会话标识符(TSI)来标识。在称为基于服务的传输会话实例描述(S-TSID)的ROUTE信令结构(是服务层信令的部分)中给出了LCT会话所共有的性质以及各个LCT会话所独特的特定性质。各个LCT会话被承载于单个物理层管道上。根据给定实施例，一个LCT会话可通过多个PLP来发送。ROUTE会话的不同的LCT会话可被包含在不同的物理层管道中或者可不被包含在不同的物理层管道中。这里，ROUTE会话可通过多个PLP来传送。S-TSID中描述的性质包括各个LCT会话的TSI值和PLPID、传送对象/文件的描述符和应用层FEC参数。

MMTP会话通过目的地IP地址和目的地端口号来标识。MMTP分组流(与它所承载的服务组件关联)通过在父MMTP会话的范围内唯一的packet_id来标识。SLT中给出了MMTP分组流所共有的性质以及MMTP分组流的特定性质。各个MMTP会话的性质通过MMTP会话内可承载的MMT信令消息来给出。MMTP会话的不同MMTP分组流可被包含在不同物理层管道中或者可不被包含在不同物理层管道中。这里，MMTP会话可通过多个PLP来传送。MMT信令消息中所描述的性质包括各个MMTP分组流的packet_id值和PLPID。这里，MMT信令消息可具有MMT中所定义的形式，或者根据下面将描述的实施例具有变形的形式。

以下将描述低级信令(LLS)。

具有专用于此功能的熟知地址/端口的IP分组的有效载荷中所承载的信令信息被称作低级信令(LLS)。可根据实施例不同地配置IP地址和端口号。在一个实施例中，可在具有地址224.0.23.60和目的地端口4937/udp的IP分组中传输LLS。在上述协议栈上，LLS可位于由“SLT”表示的部分中。然而，根据给定实施例，LLS可通过信号帧中的单独的物理信道(专用信道)来发送，而不经受UDP/IP层的处理。

传送LLS数据的UDP/IP分组可按照被称作LLS表的形式来格式化。传送LLS数据的各个UDP/IP分组的第一字节可对应于LLS表的开始。任何LLS表的最大长度受到可从PHY层传送的最大IP分组(65507字节)限制。

LLS表可包括标识LLS表的类型的LLS表ID字段以及标识LLS表的版本的LLS表版本字段。根据LLS表ID字段所指示的值，LLS表可包括上述SLT或者分级区域表(RRT)。RRT可具有关于内容分级的信息。

以下将描述SLT。LLS可以是支持接收机的快速信道扫描和服务获取的引导的信令信息，SLT可以是用于构建基本服务列表并且提供SLS的引导发现的信令信息表。

SLT的功能类似于MPEG-2系统中的节目关联表(PAT)以及见于ATSC系统中的快速信息信道(FIC)。对于首次遇到广播发射的接收机，就从这里开始。SLT支持快速信道扫描，其允许接收机构建它可接收的所有服务的列表(带有其信道名称、信道号等)，SLT提供允许接收机针对各个服务发现SLS的引导信息。对于ROUTE/DASH传送服务，引导信息包括承载SLS的LCT会话的目的地IP地址和目的地端口。对于MMT/MPU传送服务，引导信息包括承载SLS的MMTP会话的目的地IP地址和目的地端口。

SLT通过将关于各个服务的以下信息包括在广播流中来支持快速信道扫描和服务获取。首先，SLT可包括允许对于观看者有意义并且可支持经由信道号或者上/下选择的初始服务选择的服务列表的呈现所需的信息。其次，SLT可包括定位所列的各个服务的服务层信令所需的信息。即，SLT可包括与传送SLS的位置有关的访问信息。

所示的根据本实施例的SLT被表示成具有SLT根要素的XML文档。根据给定实施例，SLT可按照二进制格式或XML文档来表示。

图中所示的SLT的SLT根要素可包括@bsid、@sltSectionVersion、@sltSectionNumber、@totalSltSectionNumbers、@language、@capabilities、InetSigLoc和/或Service。根据给定实施例，SLT根要素还可包括@providerId。根据给定实施例，SLT根要素可不包括@language。

服务要素可包括@serviceId、@SLTserviceSeqNumber、@protected、@majorChannelNo、@minorChannelNo、@serviceCategory、@shortServiceName、@hidden、@slsProtocolType、BroadcastSignaling、@slsPlpId、@slsDestinationIpAddress、@slsDestinationUdpPort、@slsSourceIpAddress、@slsMajorProtocolVersion、@SlsMinorProtocolVersion、@serviceLanguage、@broadbandAccessRequired、@capabilities和/或InetSigLoc。

根据给定实施例，SLT的属性或要素可被添加/改变/删除。SLT中所包括的各个要素可另外具有单独的属性或要素，并且根据本实施例的一些属性或要素可被省略。这里，用@标记的字段可对应于属性，没有用@标记的字段可对应于要素。

@bsid是整个广播流的标识符。BSID的值可在区域层面为唯一的。

@providerId可以是使用该广播流的部分或全部的广播商的索引。这是可选属性。当它不存在时，表示该广播流由一个广播商使用。图中未示出@providerId。

@sltSectionVersion可以是SLT区段的版本号。当SLT内承载的信息发生变化时，sltSectionVersion可增加1。当它达到最大值时，它返回0。

@sltSectionNumber可以是SLT的该区段的编号，从1开始计数。换言之，@sltSectionNumber可对应于SLT区段的区段号。当不使用此字段时，@sltSectionNumber可被设定为默认值1。

@totalSltSectionNumbers可以是此区段作为其一部分的SLT的区段的总数(即，具有最高sltSectionNumber的区段)。sltSectionNumber和totalSltSectionNumbers一起可被认为指示当按照分段发送时SLT的一部分的“N中的部分M”。换言之，当发送SLT时，可支持通过分段的传输。当不使用此字段时，@totalSltSectionNumbers可被设定为默认值1。不使用此字段的情况可对应于SLT不通过分段来发送的情况。

@language可指示此slt实例中所包括的服务的主语言。根据给定实施例，此字段的值可具有ISO中所定义的三字符语言代码。此字段可被省略。

@capabilities可指示用于解码并有意义地呈现该slt实例中的所有服务的内容所需的能力。

InetSigLoc可提供告知接收机它可从哪里经由宽带从外部服务器获取任何请求的类型的数据的URL。此要素可包括@urlType作为下级字段。根据@urlType字段的值，可指示由InetSigLoc提供的URL的类型。根据给定实施例，当@urlType字段具有值0时，InetSigLoc可提供信令服务器的URL。当@urlType字段具有值1时，InetSigLoc可提供ESG服务器的URL。当@urlType字段具有其它值时，字段可被预留以用于未来使用。

service字段是具有关于各个服务的信息的要素，并且可对应于服务入口。可存在与SLT所指示的服务的数量对应的服务要素字段。以下将描述service字段的下级属性/要素。

@serviceId可以是在此广播区域的范围内唯一地标识此服务的整数。根据给定实施例，@serviceId的范围可改变。@SLTserviceSeqNumber可以是指示服务ID等于上述serviceId属性的SLT服务信息的序列号的整数。SLTserviceSeqNumber值对于各个服务可从0开始并且每当此服务要素中的任何属性改变时可增加1。如果与具有特定值的ServiceID的先前服务要素相比没有属性值改变，则SLTserviceSeqNumber将不增加。SLTserviceSeqNumber字段在达到最大值之后返回0。

@protected是可指示用于服务的有意义再现的一个或更多个组件是否处于受保护状态的标志信息。当被设定为“1”(真)时，有意义呈现所需的一个或更多个组件受到保护。当被设定为“0”(假)时，此标志指示服务的有意义呈现所需的组件未受保护。默认值为假。

@majorChannelNo是表示服务的“主”信道号的整数。该字段的示例可具有1至999的范围。

@minorChannelNo是表示服务的“次”信道号的整数。该字段的示例可具有1至999的范围。

@serviceCategory可指示此服务的类别。此字段可指示根据实施例而变化的类型。根据给定实施例，当此字段具有值1、2和3时，所述值可分别对应于线性A/V服务、仅线性音频服务和基于应用的服务。当此字段具有值0时，所述值可对应于未定义类别的服务。当此字段具有除了1、2和3之外的其它值时，该字段可被预留以用于未来使用。@shortServiceName可以是服务的短字符串名称。

@hidden可以是布尔值，当其存在并被设定为“真”时指示服务旨在用于测试或专有用途，并且将不被普通TV接收机选择。当不存在时默认值为“假”。

@slsProtocolType可以是指示此服务所使用的服务层信令的协议类型的属性。此字段可指示根据实施例而变化的类型。根据给定实施例，当此字段具有值1和2时，各个对应服务所使用的SLS的协议可分别为ROUTE和MMTP。当此字段具有除了0之外的其它值时，该字段可被预留以用于未来使用。此字段可被称作@slsProtocol。

BroadcastSignaling及其下级属性/要素可提供与广播信令相关的信息。当BroadcastSignaling要素不存在时，父服务要素的子要素InetSigLoc可存在，并且其属性urlType包括URL_type 0x00(至信令服务器的URL)。在这种情况下，属性url支持查询参数svc＝，其中service_id对应于父服务要素的serviceId属性。

另选地，当BroadcastSignaling要素不存在时，要素InetSigLoc可作为slt根要素的子要素而存在，并且该InetSigLoc要素的属性urlType包括URL_type 0x00(至信令服务器的URL)。在这种情况下，URL_type0x00的属性url支持查询参数svc＝，其中service_id对应于父服务要素的serviceId属性。

@slsPlpId可以是表示整数的字符串，其指示承载此服务的SLS的物理层管道的PLP ID。

@slsDestinationIpAddress可以是包含承载此服务的SLS数据的分组的dotted-IPv4目的地地址的字符串。

@slsDestinationUdpPort可以是包含承载此服务的SLS数据的分组的端口号的字符串。如上文所述，可通过目的地IP/UDP信息执行SLS引导。

@slsSourceIpAddress可以是包含承载此服务的SLS数据的分组的dotted-IPv4源地址的字符串。

@slsMajorProtocolVersion可以是用于传送此服务的服务层信令的协议的主版本号。默认值为1。

@SlsMinorProtocolVersion可以是用于传送此服务的服务层信令的协议的次版本号。默认值为0。

@serviceLanguage可以是指示服务的主语言的三字符语言代码。此字段的值可具有根据实施例而变化的形式。

@broadbandAccessRequired可以是指示接收机需要宽带访问来进行服务的有意义的呈现的布尔值。默认值为假。当此字段具有值真时，接收机需要访问宽带以用于有意义服务再现，这可对应于混合服务传送的情况。

@capabilities可表示用于解码并有意义地呈现服务ID等于上述serviceId属性的服务的内容所需的能力。

InetSigLoc可提供用于经由宽带(如果可用的话)访问信令或声明信息的URL。其数据类型可以是任何URL数据类型的扩展，增加了指示URL允许访问什么的@urlType属性。此字段的@urlType字段可指示与上述InetSigLoc的@urlType字段相同的含义。当属性URL_type0x00的InetSigLoc要素作为SLT的要素存在时，它可用于做出对信令元数据的HTTP请求。HTTP POST消息主体可包括服务项。当InetSigLoc要素出现在区段层面时，该服务项用于指示所请求的信令元数据对象所应用于的服务。如果不存在服务项，则请求区段中的所有服务的信令元数据对象。当InetSigLoc出现在服务层面时，则不需要服务项来指定期望的服务。当提供属性URL_type 0x01的InetSigLoc要素时，它可用于经由宽带检索ESG数据。如果要素作为服务要素的子要素出现，则URL可用于检索该服务的ESG数据。如果要素作为SLT要素的子要素出现，则URL可用于检索该区段中的所有服务的ESG数据。

在SLT的另一示例中，SLT的@sltSectionVersion、@sltSectionNumber、@totalSltSectionNumbers和/或@language字段可被省略。

另外，上述InetSigLoc字段可被@sltInetSigUri和/或@sltInetEsgUri字段代替。这两个字段可分别包括信令服务器的URI和ESG服务器的URI信息。与SLT的下级字段对应的InetSigLoc字段以及与service字段的下级字段对应的InetSigLoc字段可按照相似的方式被代替。

所建议的默认值可根据实施例而变化。所示的“用途”列涉及各个字段。这里，“1”可指示对应字段是必要字段，“0..1”可指示对应字段是可选字段。

图4示出根据本发明的实施例的SLS引导和服务发现处理。

以下将描述SLS。

SLS可以是提供用于服务及其内容组件的发现和获取的信息的信令。

对于ROUTE/DASH，用于各个服务的SLS描述了服务的特性，例如其组件的列表及哪里获取它们以及进行服务的有意义呈现所需的接收机能力。在ROUTE/DASH系统中，SLS包括用户服务绑定描述(USBD)、S-TSID和DASH媒体呈现描述(MPD)。这里，USBD或用户服务描述(USD)是SLS XML分段之一，并且可用作描述特定描述性信息的信令herb。USBD/USD可被扩展超过3GPP MBMS。USBD/USD的细节将在下面描述。

服务信令聚焦于服务本身的基本属性，特别是获取服务所需的那些属性。旨在用于观看者的服务和节目的性质作为服务声明或ESG数据出现。

各个服务具有单独的服务信令允许接收机获取感兴趣的服务的适合SLS，而无需解析广播流内承载的整个SLS。

为了服务信令的可选宽带传送，如上所述，SLT可包括可获得服务信令文件的HTTPURL。

LLS用于引导SLS获取，此后，SLS用于获取在ROUTE会话或MMTP会话上传送的服务组件。所描述的图示出以下信令序列。接收机开始获取上述SLT。经由ROUTE会话传送的service_id所标识的各个服务提供SLS引导信息：PLPID(#1)、源IP地址(sIP1)、目的地IP地址(dIP1)和目的地端口号(dPort1)。经由MMTP会话传送的service_id所标识的各个服务提供SLS引导信息：PLPID(#2)、目的地IP地址(dIP2)和目的地端口号(dPort2)。

对于使用ROUTE的流服务传送，接收机可获取在IP/UDP/LCT会话和PLP上承载的SLS分段；而对于使用MMTP的流服务传送，接收机可获取在MMTP会话和PLP上承载的SLS分段。对于使用ROUTE的服务传送，这些SLS分段包括USBD/USD分段、S-TSID分段和MPD分段。它们与一个服务相关。USBD/USD分段描述服务层性质并且提供对S-TSID分段的URI参考以及对MPD分段的URI参考。换言之，USBD/USD可参考S-TSID和MPD。对于使用MMTP的服务传送，USBD参考MMT信令的MPT消息，其MP表提供分组ID的标识以及属于服务的资产的位置信息。这里，资产是多媒体数据实体，并且可表示数据实体，该数据实体被组合成一个唯一ID并且用于生成一个多媒体呈现。资产可对应于一个服务中所包括的服务组件。MPT消息是具有MMT的MP表的消息。这里，MP表可以是具有关于内容和MMT资产的信息的MMT分组表。详情可类似于MMT中的定义。这里，媒体呈现可对应于建立媒体内容的有界/无界呈现的数据的收集。

S-TSID分段提供与一个服务关联的组件获取信息以及见于与该服务的组件对应的MPD中和TSI中的DASH表示之间的映射。S-TSID可提供TSI和关联的DASH表示标识符的形式的组件获取信息、以及承载与DASH表示关联的DASH片段的PLPID。通过PLPID和TSI值，接收机从服务收集音频/视频组件并且开始缓冲DASH媒体片段，然后应用适当的解码处理。

对于在MMTP会话上传送的USBD列表服务组件，如所描述的图中的“服务#2”所示，接收机还获取具有匹配MMT_package_id的MPT消息以完成SLS。MPT消息提供包括服务和各个组件的获取信息的服务组件的完整列表。组件获取信息包括MMTP会话信息、承载会话的PLPID以及该会话内的packet_id。

根据给定实施例，例如，在ROUTE中，可使用两个或更多个S-TSID分段。各个分段可提供与传送各个服务的内容的LCT会话有关的访问信息。

在ROUTE中，S-TSID、USBD/USD、MPD或者传送S-TSID、USBD/USD或MPD的LCT会话可被称作服务信令信道。在MMTP中，USBD/UD、MMT信令消息或者传送MMTP或USBD/UD的分组流可被称作服务信令信道。

与所示的示例不同，一个ROUTE或MMTP会话可通过多个PLP传送。换言之，一个服务可通过一个或更多个PLP传送。如上文所述，一个LCT会话可通过一个PLP传送。与该图不同，根据给定实施例，包括在一个服务中的组件可通过不同的ROUTE会话传送。另外，根据给定实施例，包括在一个服务中的组件可通过不同的MMTP会话传送。根据给定实施例，包括在一个服务中的组件可独立地通过ROUTE会话和MMTP会话传送。尽管未示出，包括在一个服务中的组件可经由宽带传送(混合传送)。

图5示出根据本发明的实施例的用于ROUTE/DASH的USBD分段。

以下将描述基于ROUTE的传送中的SLS。

服务层信令向接收机提供详细的技术信息以允许发现和访问服务及其内容组件。它可包括在专用LCT会话上承载的一组XML编码的元数据分段。该LCT会话可如上所述利用包含在SLT中的引导信息来获取。SLS按照服务级别定义，它描述服务的特性和访问信息(例如，其内容组件的列表以及如何获取它们)以及进行该服务的有意义呈现所需的接收机能力。在ROUTE/DASH系统中，对于线性服务传送，SLS由以下元数据分段组成：USBD、S-TSID和DASH MPD。SLS分段可在具有TSI＝0的专用LCT传输会话上传送。根据给定实施例，传送SLS分段的特定LCT会话(专用LCT会话)的TSI可具有不同的值。根据给定实施例，传送SLS分段的LCT会话可利用SLT或者另一方案来用信号通知。

ROUTE/DASH服务层信令可包括用户服务绑定描述(USBD)和基于服务的传输会话实例描述(S-TSID)元数据分段。这些服务信令片分段用于线性服务和基于应用的服务二者。USBD分段包含服务标识、装置能力信息、对访问服务和构成媒体组件所需的其它SLS分段的参考、以及使得接收机能够确定服务组件的传输模式(广播和/或宽带)的元数据。被USBD参考的S-TSID分段提供传送服务的媒体内容组件的一个或更多个ROUTE/LCT会话的传输会话描述以及那些LCT会话中承载的传送对象的描述。USBD和S-TSID将在下面描述。

在基于ROUTE的传送中的流内容信令中，SLS的流内容信令组件对应于MPD分段。MPD通常与用于作为流内容的DASH片段的传送的线性服务关联。MPD以片段URL的形式提供线性/流服务的各个媒体组件的资源标识符，以及在媒体呈现内所标识的资源的上下文。MPD的细节将在下面描述。

在基于ROUTE的传送中的基于应用的增强信令中，基于应用的增强信令属于基于应用的增强组件的传送，例如应用逻辑文件、本地缓存的媒体文件、网络内容项或者通知流。当可用时，应用还可经由宽带连接检索本地缓存的数据。

以下将描述图中所示的USBD/USD的细节。

顶层或入口点SLS分段是USBD分段。所示的USBD分段是本发明的示例，根据给定实施例可另外提供图中未示出的USBD分段的基本字段。如上文所述，所示的USBD分段具有扩展形式，并且可具有增加到基本配置的字段。

所示的USBD可具有bundleDescription根要素。bundleDescription根要素可具有userServiceDescription要素。userServiceDescription要素可对应于一个服务的示例。

userServiceDescription要素可包括@serviceId、@atsc:serviceId、@atsc:serviceStatus、@atsc:fullMPDUri、@atsc:sTSIDUri、name、serviceLanguage、atsc:capabilityCode和/或deliveryMethod。

@serviceId可以是标识服务的全局唯一的URI，其在BSID的范围内唯一。此参数可用于链接到ESG数据(Service@globalServiceID)。

@atsc:serviceId是对LLS(SLT)中的对应服务条目的参考。此属性的值与指派给该条目的serviceId的值相同。

@atsc:serviceStatus可指定此服务的状态。该值指示此服务是活动的还是不活动的。当被设定为“1”(真)时，指示服务是活动的。当没有使用此字段时，@atsc:serviceStatus可被设定为默认值1。

@atsc:fullMPDUri可参考MPD分段，其包含经由广播并且可选地还经由宽带传送的服务的内容组件的描述。

@atsc:sTSIDUri可参考S-TSID分段，其提供对承载此服务的内容的传输会话的访问相关参数。

name可指示由lang属性给出的服务的名称。name要素可包括lang属性，该lang属性指示服务名称的语言。可根据XML数据类型来指定语言。

serviceLanguage可表示服务的可用语言。可根据XML数据类型来指定语言。

atsc:capabilityCode可指定接收机能够创建此服务的内容的有意义呈现所需的能力。根据给定实施例，此字段可指定预定义的能力组。这里，所述能力组可以是用于有意义呈现的一组能力属性值。可根据给定实施例省略此字段。

deliveryMethod可以是属于经由广播和(可选地)宽带访问模式的服务内容的传输相关信息的容器。参考服务中所包括的数据，当数据的数量为N时，各个数据的传送方案可由此要素来描述。deliveryMethod可包括r12:broadcastAppService要素和r12:unicastAppService要素。各个下级要素可包括basePattern要素作为下级要素。

r12:broadcastAppService可以是遍及附属媒体呈现的所有周期经由广播以复用或非复用的形式传送的DASH表示，其包含属于服务的对应媒体组件。换言之，各个字段可指示通过广播网络传送的DASH表示。

r12:unicastAppService可以是遍及附属媒体呈现的所有周期经由宽带以复用或非复用的形式传送的DASH表示，其包含属于服务的构成媒体内容组件。换言之，各个字段可指示经由宽带传送的DASH表示。

basePattern可以是接收机用来与DASH客户端在其包含周期下请求父表示的媒体片段所使用的片段URL的任何部分匹配的字符图案。匹配暗指所请求的对应媒体片段经由广播传输承载。在用于接收由r12:broadcastAppService要素和r12:unicastAppService要素中的每一个表示的DASH表示的URL地址中，URL等的一部分可具有特定图案。该图案可由此字段来描述。一些数据可利用此信息来区分。所建议的默认值可根据实施例而变化。图中所示的“使用”列与各个字段有关。这里，M可表示必要字段，O可表示可选字段，OD可表示具有默认值的可选字段，CM可表示条件性必要字段。0...1至0...N可指示可用字段的数量。

图6示出根据本发明的实施例的用于ROUTE/DASH的S-TSID分段。

以下将详细描述图中所示的S-TSID。

S-TSID可以是SLS XML分段，其为承载服务的内容组件的传输会话提供总会话描述信息。S-TSID是SLS元数据分段，其包含零个或更多个ROUTE会话以及传送服务的媒体内容组件的构成LCT会话的总传输会话描述信息。S-TSID还包括服务的LCT会话中承载的传送对象或对象流的文件元数据，以及关于有效载荷格式和那些LCT会话中承载的内容组件的附加信息。

S-TSID分段的各个实例在USBD分段中由userServiceDescription要素的@atsc:sTSIDUri属性参考。根据本实施例所示的S-TSID被表示为XML文档。根据给定实施例，S-TSID可被表示为二进制格式或者XML文档。

所示的S-TSID可具有S-TSID根要素。S-TSID根要素可包括@serviceId和/或RS。

@serviceID可以是USD中的参考对应服务要素。此属性的值可参考具有service_id的对应值的服务。

RS要素可具有关于用于传送服务数据的ROUTE会话的信息。服务数据或服务组件可通过多个ROUTE会话来传送，因此RS要素的数量可为1至N。

RS要素可包括@bsid、@sIpAddr、@dIpAddr、@dport、@PLPID和/或LS。

@bsid可以是承载broadcastAppService的内容组件的广播流的标识符。当此属性不存在时，默认广播流是PLP承载此服务的SLS分段的那一个广播流。其值可与SLT中的broadcast_stream_id相同。

@sIpAddr可指示源IP地址。这里，该源IP地址可以是用于传送服务中所包括的服务组件的ROUTE会话的源IP地址。如上文所述，一个服务的服务组件可通过多个ROUTE会话传送。因此，可利用用于传送S-TSID的ROUTE会话以外的另一ROUTE会话来发送服务组件。因此，此字段可用于指示ROUTE会话的源IP地址。此字段的默认值可以是当前ROUTE会话的源IP地址。当服务组件通过另一ROUTE会话传送，因此需要指示ROUTE会话时，此字段的值可以是ROUTE会话的源IP地址的值。在这种情况下，此字段可对应于M，即，必要字段。

@dIpAddr可指示目的地IP地址。这里，目的地IP地址可以是传送服务中所包括的服务组件的ROUTE会话的目的地IP地址。对于与@sIpAddr的以上描述相似的情况，此字段可指示传送服务组件的ROUTE会话的目的地IP地址。此字段的默认值可以是当前ROUTE会话的目的地IP地址。当服务组件通过另一ROUTE会话传送，因此需要指示ROUTE会话时，此字段的值可以是ROUTE会话的目的地IP地址的值。在这种情况下，此字段可对应于M，即，必要字段。

@dport可指示目的地端口。这里，目的地端口可以是传送服务中所包括的服务组件的ROUTE会话的目的地端口。对于与@sIpAddr的以上描述相似的情况，此字段可指示传送服务组件的ROUTE会话的目的地端口。此字段的默认值可以是当前ROUTE会话的目的地端口号。当服务组件通过另一ROUTE会话传送，因此需要指示ROUTE会话时，此字段的值可以是ROUTE会话的目的地端口号值。在这种情况下，此字段可对应于M，即，必要字段。

@PLPID可以是RS所表示的ROUTE会话的PLP的ID。默认值可以是包括当前S-TSID的LCT会话的PLP的ID。根据给定实施例，此字段可具有用于传送ROUTE会话中的S-TSID的LCT会话的PLP的ID值，并且可具有ROUTE会话的所有PLP的ID值。

LS要素可具有关于用于传送服务数据的LCT会话的信息。服务数据或服务组件可通过多个LCT会话来传送，因此LS要素的数量可为1至N。

LS要素可包括@tsi、@PLPID、@bw、@startTime、@endTime、SrcFlow和/或RprFlow。

@tsi可指示用于传送服务的服务组件的LCT会话的TSI值。

@PLPID可具有LCT会话的PLP的ID信息。此值可被覆写在基本ROUTE会话值上。

@bw可指示最大带宽值。@startTime可指示LCT会话的开始时间。@endTime可指示LCT会话的结束时间。SrcFlow要素可描述ROUTE的源流。RprFlow要素可描述ROUTE的修复流。

所建议的默认值可根据实施例而变化。图中所示的“使用”列与各个字段有关。这里，M可表示必要字段，O可表示可选字段，OD可表示具有默认值的可选字段，CM可表示条件性必要字段。0...1至0...N可指示可用字段的数量。

以下将描述用于ROUTE/DASH的MPD。

MPD是SLS元数据分段，其包含与广播商所定义的给定持续时间的线性服务(例如，单个TV节目或者在一段时间内邻接的线性TV节目的集合)对应的DASH媒体呈现的形式化描述。MPD的内容提供片段的资源标识符以及媒体呈现内所标识的资源的上下文。MPD分段的数据结构和语义可根据MPEG DASH所定义的MPD。

在MPD中传达的一个或更多个DASH表示可经由广播来承载。MPD可描述经由宽带传送的附加表示，例如在混合服务的情况下或者为了在由于广播信号劣化从广播至广播切换(例如，穿过隧道行驶)时支持服务连续性。

图7示出根据本发明的实施例的用于MMT的USBD/USD分段。

用于线性服务的MMT服务层信令包括USBD分段和MMT分组(MP)表。MP表如上所述。USBD分段包含服务标识、装置能力信息、对访问服务和构成媒体组件所需的其它SLS信息的参考、以及使得接收机能够确定服务组件的传输模式(广播和/或宽带)的元数据。USBD所参考的MPU组件的MP表提供传送服务的媒体内容组件的MMTP会话的传输会话描述以及那些MMTP会话中承载的资产的描述。

MPU组件的SLS的流内容信令组件对应于MMT中所定义的MP表。MP表提供MMT资产的列表，其中各个资产对应于单个服务组件以及此组件的位置信息的描述。

USBD分段还可包含如上所述对S-TSID和MPD的参考，以用于分别通过ROUTE协议和宽带传送的服务组件。根据给定实施例，在通过MMT的传送中，通过ROUTE协议传送的服务组件是NRT数据等。因此，在这种情况下，MPD可能是不必要的。另外，在通过MMT的传送中，关于用于传送经由宽带传送的服务组件的LCT会话的信息是不必要的，因此S-TSID可能是不必要的。这里，MMT分组可以是利用MMT传送的媒体数据的逻辑收集。这里，MMTP分组可表示利用MMT传送的媒体数据的格式化单元。MPU可表示可独立解码的时序/非时序数据的一般容器。这里，MPU中的数据是媒体编解码器不可知性。

以下将描述图中所示的USBD/USD的细节。

所示的USBD分段是本发明的示例，可根据实施例另外提供USBD分段的基本字段。如上文所述，所示的USBD分段具有扩展形式，并且可具有增加到基本结构的字段。

根据本发明的实施例所示的USBD被表示为XML文档。根据给定实施例，USBD可被表示为二进制格式或者XML文档。

所示的USBD可具有bundleDescription根要素。bundleDescription根要素可具有userServiceDescription要素。userServiceDescription要素可以是一个服务的实例。

userServiceDescription要素可包括@serviceId、@atsc:serviceId、name、serviceLanguage、atsc:capabilityCode、atsc:Channel、atsc:mpuComponent、atsc:routeComponent、atsc:broadbandComponent和/或atsc:ComponentInfo。

这里，@serviceId、@atsc:serviceId、name、serviceLanguage和atsc:capabilityCode可如上所述。name字段下面的lang字段可如上所述。atsc:capabilityCode可根据给定实施例被省略。

根据实施例，userServiceDescription要素还可包括atsc:contentAdvisoryRating要素。此要素可以是可选要素。atsc:contentAdvisoryRating可指定内容分级。此字段在图中未示出。

atsc:Channel可具有关于服务的信道的信息。atsc:Channel要素可包括@atsc:majorChannelNo、@atsc:minorChannelNo、@atsc:serviceLang、@atsc:serviceGenre、@atsc:serviceIcon和/或atsc:ServiceDescription。@atsc:majorChannelNo、@atsc:minorChannelNo和@atsc:serviceLang可根据给定实施例被省略。

@atsc:majorChannelNo是指示服务的主信道号的属性。

@atsc:minorChannelNo是指示服务的次信道号的属性。

@atsc:serviceLang是指示服务中所使用的主语言的属性。

@atsc:serviceGenre是指示服务的主体裁的属性。

@atsc:serviceIcon是指示用于表示此服务的图标的统一资源定位符(URL)的属性。

atsc:ServiceDescription包括服务描述(可能为多种语言)。atsc:ServiceDescription可包括@atsc:serviceDescrText和/或@atsc:serviceDescrLang。

@atsc:serviceDescrText是指示服务的描述的属性。

@atsc:serviceDescrLang是指示上面serviceDescrText属性的语言的属性。

atsc:mpuComponent可具有关于以MPU形式传送的服务的内容组件的信息。atsc:mpuComponent可包括@atsc:mmtPackageId和/或@atsc:nextMmtPackageId。

@atsc:mmtPackageId可参考作为MPU传送的服务的内容组件的MMT分组。

@atsc:nextMmtPackageId可参考针对作为MPU传送的服务的内容组件时间上在@atsc:mmtPackageId所参考的一个MMT分组之后使用的MMT分组。

atsc:routeComponent可具有关于通过ROUTE传送的服务的内容组件的信息。atsc:routeComponent可包括@atsc:sTSIDUri、@sTSIDPlpId、@sTSIDDestinationIpAddress、@sTSIDDestinationUdpPort、@sTSIDSourceIpAddress、@sTSIDMajorProtocolVersion和/或@sTSIDMinorProtocolVersion。

@atsc:sTSIDUri可以是对提供对承载此服务的内容的传输会话的访问相关参数的S-TSID分段的参考。此字段可与上述ROUTE的USBD中参考S-TSID的URI相同。如上文所述，在通过MMTP的服务传送中，通过NRT等传送的服务组件可通过ROUTE来传送。此字段可用于参考用于其的S-TSID。

@sTSIDPlpId可以是表示整数的字符串，其指示承载此服务的S-TSID的物理层管道的的PLP ID。(默认：当前物理层管道)。

@sTSIDDestinationIpAddress可以是包含承载此服务的S-TSID的分组的dotted-IPv4目的地地址的字符串。(默认：当前MMTP会话的源IP地址)。

@sTSIDDestinationUdpPort可以是包含承载此服务的S-TSID的分组的端口号的字符串。

@sTSIDSourceIpAddress可以是包含承载此服务的S-TSID的分组的dotted-IPv4源地址的字符串。

@sTSIDMajorProtocolVersion可指示用于传送此服务的S-TSID的协议的主版本号。默认值为1。

@sTSIDMinorProtocolVersion可指示用于传送此服务的S-TSID的协议的次版本号。默认值为0。

atsc:broadbandComponent可具有关于经由宽带传送的服务的内容组件的信息。换言之，atsc:broadbandComponent可以是基于混合传送的假设的字段。atsc:broadbandComponent还可包括@atsc:fullfMPDUri。

@atsc:fullfMPDUri可以是对包含经由宽带传送的服务的内容组件的描述的MPD分段的参考。

atsc:ComponentInfo字段可具有关于服务的可用组件的信息。atsc:ComponentInfo字段可具有关于各个组件的类型、角色、名称等的信息。atsc:ComponentInfo字段的数量可对应于各个组件的数量(N)。atsc:ComponentInfo字段可包括@atsc:componentType、@atsc:componentRole、@atsc:componentProtectedFlag、@atsc:componentId和/或@atsc:componentName。

@atsc:componentType是指示此组件的类型的属性。值0指示音频组件。值1指示视频组件。值2指示隐藏字幕组件。值3指示应用组件。值4至7被预留。此字段的值的含义可根据实施例不同地设定。

@atsc:componentRole是指示此组件的角色或类型的属性。

对于音频(当上面的componentType属性等于0时)：componentRole属性的值如下：0＝完整主体，1＝音乐和效果，2＝对话，3＝解说，4＝视觉障碍，5＝听觉障碍，6＝画外音，7-254＝预留，255＝未知。

对于视频(当上面的componentType属性等于1时)，componentRole属性的值如下：0＝主视频，1＝另选相机视图，2＝其它另选视频组件，3＝手势语插件，4＝跟随主题视频，5＝3D视频左视图，6＝3D视频右视图，7＝3D视频深度信息，8＝的视频阵列的部分，9＝跟随主题元数据，10-254＝预留，255＝未知。

对于隐藏字幕组件(当上面的componentType属性等于2时)，componentRole属性的值如下：0＝正常，1＝易阅读，2-254＝预留，255＝未知。

当上面的componentType属性介于3至7(含)之间时，componentRole可等于255。此字段的值的含义可根据实施例来不同地设定。

@atsc:componentProtectedFlag是指示此组件是否受保护(例如，被加密)的属性。当此标志被设定为值1时，此组件受保护(例如，被加密)。当此标志被设定为值0时，此组件不受保护(例如，被加密)。当不存在时，componentProtectedFlag属性的值被推断为等于0。此字段的值的含义可根据实施例来不同地设定。

@atsc:componentId是指示此组件的标识符的属性。此属性的值可与此组件所对应的MP表中的asset_id相同。

@atsc:componentName是指示此组件的人可读名称的属性。

所建议的默认值可根据实施例而变化。图中所示的“使用”列与各个字段有关。这里，M可表示必要字段，O可表示可选字段，OD可表示具有默认值的可选字段，CM可表示条件性必要字段。0...1至0...N可指示可用字段的数量。

以下将描述用于MMT的MPD。

媒体呈现描述是SLS元数据分段，其与广播商所定义的给定持续时间的线性服务(例如，单个TV节目或者在一段时间内邻接的线性TV节目的集合)对应。MPD的内容提供片段的资源标识符以及媒体呈现内所标识的资源的上下文。MPD的数据结构和语义可根据MPEGDASH所定义的MPD。

在本实施例中，通过MMTP会话传送的MPD描述经由宽带传送的表示，例如在混合服务的情况下或者为了在由于广播信号劣化从广播至广播切换(例如，在山下或者穿过隧道行驶)时支持服务连续性。

以下将描述用于MMT的MMT信令消息。

当MMTP会话用于承载流服务时，根据MMT所定义的信令消息模式通过MMTP分组来传送MMT所定义的MMT信令消息。除了承载资产所特定的MMT信令消息的MMTP分组(其可被设定为与承载资产的MMTP分组相同的packet_id值)以外，承载服务层信令的MMTP分组的packet_id字段的值被设定为“00”。参考各个服务的适当分组的标识符如上所述通过USBD分段来用信号通知。具有匹配的MMT_package_id的MMT分组表(MPT)消息可在SLT中用信号通知的MMTP会话上传送。各个MMTP会话承载其会话或者MMTP会话所传送的各个资产所特定的MMT信令消息。

换言之，可通过指定具有用于SLT中的特定服务的SLS的分组的IP目的地地址/端口号等来访问MMTP会话的USBD。如上文所述，承载SLS的MMTP分组的分组ID可被指定为诸如00等的特定值。可利用USBD的上述分组IP信息来访问具有匹配的分组ID的MPT消息。如下所述，MPT消息可用于访问各个服务组件/资产。

以下MMTP消息可通过在SLT中用信号通知的MMTP会话来传送。

MMT分组表(MPT)消息：此消息承载MP(MMT分组)表，其包含如MMT定义的所有资产的列表及其位置信息。如果资产通过不同于传送MP表的当前PLP的PLP传送，则可在MP表中利用物理层管道标识符描述符来提供承载资产的PLP的标识符。物理层管道标识符描述符将在下面描述。

MMT ATSC3(MA3)消息mmt_atsc3_message()：此消息承载如上所述包括服务层信令的服务所特定的系统元数据。mmt_atsc3_message()将在下面描述。

如果需要，以下MMTP消息可通过在SLT中用信号通知的MMTP会话来传送。

媒体呈现信息(MPI)消息：此消息承载包含整个文档或者呈现信息的文档的子集的MPI表。与MPI表关联的MP表也可通过此消息来传送。

时钟关系信息(CRI)消息：此消息承载CRI表，该CRI表包含用于NTP时间戳与MPEG-2STC之间的映射的时钟相关信息。根据给定实施例，CRI消息可不通过MMTP会话来传送。

以下MMTP消息可通过承载流内容的各个MMTP会话来传送。

假想接收机缓冲模型消息：此消息承载接收机管理其缓冲所需的信息。

假想接收机缓冲模型去除消息：此消息承载接收机管理其MMT开封缓冲所需的信息。

以下将描述与MMT信令消息之一对应的mmt_atsc3_message()。MMT信令消息mmt_atsc3_message()被定义为如上所述根据本发明来传送服务所特定的信息。该信令消息可包括与MMT信令消息的基本字段对应的消息ID、版本和/或长度字段。信令消息的有效载荷可包括服务ID信息、内容类型信息、内容版本信息、内容压缩信息和/或URI信息。内容类型信息可指示信令消息的有效载荷中所包括的数据的类型。内容版本信息可指示有效载荷中所包括的数据的版本，内容压缩信息可指示应用于该数据的压缩的类型。URI信息可具有与通过该消息传送的内容有关的URI信息。

以下将描述物理层管道标识符描述符。

物理层管道标识符描述符是可用作上述MP表的描述符之一的描述符。物理层管道标识符描述符提供关于承载资产的PLP的信息。如果资产通过与承载MP表的当前PLP不同的PLP来传送，则物理层管道标识符描述符可用作所关联的MP表中的资产描述符以标识承载资产的PLP。除了PLP ID信息以外，物理层管道标识符描述符还可包括BSID信息。BSID可以是传送该描述符所描述的资产的MMTP分组的广播流的ID。

图8示出根据本发明的实施例的链路层协议架构。

以下将描述链路层。

链路层是物理层与网络层之间的层，并且在发送侧从网络层到物理层传输数据，在接收侧从物理层到网络层传输数据。链路层的目的包括把所有输入分组类型抽象成单一格式以便于物理层处理，确保灵活性以及还未定义的输入类型的未来可扩展性。另外，链路层内的处理确保了输入数据可按照有效的方式发送(例如，通过提供压缩输入分组的头中的冗余信息的选项)。封装、压缩等的操作被称作链路层协议，利用此协议创建的分组被称为链路层分组。链路层可执行诸如分组封装、开销降低和/或信令传输等的功能。

以下将描述分组封装。链路层协议允许任何类型的分组(包括诸如IP分组和MPEG-2TS的分组)的封装。利用链路层协议，独立于网络层协议类型(这里我们考虑MPEG-2TS分组作为一种网络层分组)，物理层仅需要处理一个单一分组格式。各个网络层分组或输入分组被转换成一般链路层分组的有效载荷。另外，当输入分组大小特别小或特别大时，可执行级联和分割以便有效地使用物理层资源。

如上文所述，分割可用于分组封装。当网络层分组过大从而不易于在物理层中处理时，网络层分组被划分成两个或更多个片段。链路层分组头包括协议字段以执行发送侧的分割和接收侧的重组。当网络层分组被分割时，各个片段可按照与网络层分组中的原始位置相同的顺序被封装到链路层分组。另外，包括网络层分组的片段的各个链路层分组可因此被传输至PHY层。

如上文所述，级联可用于分组封装。当网络层分组足够小以使得链路层分组的有效载荷可包括多个网络层分组时，链路层分组头包括协议字段以执行级联。级联是将多个小大小的网络层分组组合成一个有效载荷。当网络层分组被级联时，各个网络层分组可按照与原始输入顺序相同的顺序被级联到链路层分组的有效载荷。另外，构造链路层分组的有效载荷的各个分组可以是整个分组，而非分组的片段。

以下将描述开销降低。链路层协议的使用可导致用于物理层上的数据传输的开销显著降低。根据本发明的链路层协议可提供IP开销降低和/或MPEG-2TS开销降低。在IP开销降低中，IP分组具有固定的头格式，然而，通信环境中需要的一些信息在广播环境中可能是冗余的。链路层协议提供通过压缩IP分组的头来降低广播开销的机制。在MPEG-2TS开销降低中，链路层协议提供同步字节去除、空分组删除和/或公共头去除(压缩)。首先，同步字节去除提供每TS分组一个字节的开销降低，空分组删除机制去除188字节的空TS分组，使得它们可在接收机处被重新插入，最终是公共头去除机制。

对于信令传输，在链路层协议中，可针对链路层信令提供信令分组的特定格式(将在下面描述)。

在根据本发明的实施例所示的链路层协议架构中，链路层协议以诸如IPv4、MPEG-2TS等的输入网络层分组作为输入分组。未来扩展指示其它分组类型和链路层中还可输入的协议。链路层协议还指定任何链路层信令的格式和信令，包括关于至物理层的特定信道的映射的信息。附图还示出ALP如何包含经由各种头压缩和删除算法改进传输效率的机制。另外，链路层协议可基本上封装输入分组。

图9示出根据本发明的实施例的链路层分组的基本头的结构。以下将描述头的结构。

链路层分组可包括跟随有数据有效载荷的头。链路层分组的头可包括基本头，并且可根据基本头的控制字段而包括附加头。可选头的存在由附加头的标志字段指示。根据给定实施例，指示附加头和可选头的存在的字段可位于基本头中。

以下将描述基本头的结构。用于链路层分组封装的基本头具有层次结构。基本头可为两字节的长度并且是链路层分组头的最小长度。

根据本实施例所示的基本头可包括Packet_Type字段、PC字段和/或length字段。根据给定实施例，基本头还可包括HM字段或S/C字段。

Packet_Type字段可以是指示在封装成链路层分组之前输入数据的原始协议或分组类型的3比特字段。IPv4分组、压缩IP分组、链路层信令分组和其它类型的分组可具有基本头结构并且可被封装。然而，根据给定实施例，MPEG-2TS分组可具有不同的具体结构并且可被封装。当Packet_Type的值是“000”、“001”、“100”或“111”时，ALP分组的原始数据类型是IPv4分组、压缩IP分组、链路层信令或扩展分组之一。当MPEG-2TS分组被封装时，Packet_Type的值可为“010”。Packet_Type字段的其它值可被预留以用于未来使用。

Payload_Configuration(PC)字段可以是指示有效载荷的配置的1比特字段。值0可指示链路层分组承载单个完整的输入分组，随后的字段是Header_Mode字段。值1可指示链路层分组承载不止一个输入分组(级联)或者大的输入分组的一部分(分割)，随后的字段是Segmentation_Concatenation字段。

Header_Mode(HM)字段可以是1比特字段，当被设定为0时可指示不存在附加头，并且链路层分组的有效载荷的长度小于2048字节。该值可根据实施例而变化。值1可指示跟随Length字段之后存在下面所定义的单个分组的附加头。在这种情况下，有效载荷的长度大于2047字节和/或可使用可选特征(子流标识、头扩展等)。该值可根据实施例而变化。仅当链路层分组的Payload_Configuration字段具有值0时，此字段可存在。

Segmentation_Concatenation(S/C)字段可以是1比特字段，当被设定为0时可指示有效载荷承载输入分组的片段并且跟随Length字段之后存在用于下面所定义的分割的附加头。值1可指示有效载荷承载不止一个完整输入分组并且跟随Length字段之后存在用于下面所定义的级联的附加头。仅当ALP分组的Payload_Configuration字段的值为1时，此字段可存在。

Length字段可以是11比特字段，其指示链路层分组所承载的有效载荷的长度(字节)的11最低有效位(LSB)。当随后的附加头中存在Length_MSB字段时，length字段与Length_MSB字段级联并且是提供有效载荷的实际总长度的LSB。length字段的比特数可被改变为另一值，而非11比特。

因此，分组配置的以下类型是可能的：没有附加头的单个分组、具有附加头的单个分组、分割分组和级联分组。根据给定实施例，可通过各个附加头、可选头、用于下面所述的信令信息的附加头和用于时间扩展的附加头的组合进行更多分组配置。

图10示出根据本发明的实施例的链路层分组的附加头的结构。

可存在各种类型的附加头。以下将描述用于单个分组的附加头。

当Header_Mode(HM)＝“1”时，用于单个分组的该附加头可存在。当链路层分组的有效载荷的长度大于2047字节时或者当使用可选字段时，Header_Mode(HM)可被设定为1。图中示出用于单个分组的附加头(tsib10010)。

Length_MSB字段可以是5比特字段，其可指示当前链路层分组中的总有效载荷长度(字节)的最高有效位(MSB)，并且与包含11最低有效位(LSB)的Length字段级联以获得总有效载荷长度。可用信号通知的有效载荷的最大长度因此为65535字节。length字段的比特数可被改变为另一值，而非11比特。另外，Length_MSB字段的比特数可改变，因此最大可表示有效载荷长度可改变。根据给定实施例，各个length字段可指示整个链路层分组的长度，而非有效载荷。

SIF(子流标识符标志)字段可以是1比特字段，其可指示在HEF字段之后是否存在子流ID(SID)。当此链路层分组中不存在SID时，SIF字段可被设定为0。当链路层分组中在HEF字段之后存在SID时，SIF可被设定为1。SID的细节在下面描述。

HEF(头扩展标志)字段可以是1比特字段，其在被设定为1时可指示存在附加头以用于未来扩展。值0可指示不存在此扩展头。

以下将描述当使用分割时的附加头。

当Segmentation_Concatenation(S/C)＝“0”时，此附加头(tsib10020)可存在。Segment_Sequence_Number可以是5比特无符号整数，其可指示链路层分组所承载的对应片段的顺序。对于承载输入分组的第一片段的链路层分组，此字段的值可被设定为0x0。此字段可随着属于分割的输入分组的各个附加片段而增加一。

Last_Segment_Indicator(LSI)可以是1比特字段，其在被设定为1时可指示此有效载荷中的片段是输入分组的最后一个片段。值0可指示不是最后片段。

SIF(子流标识符标志)可以是1比特字，其可指示在HEF字段之后是否存在SID。当链路层分组中不存在SID时，SIF字段可被设定为0。当链路层分组中在HEF字段之后存在SID时，SIF可被设定为1。

HEF(头扩展标志)可以是1比特字段，其在被设定为1时可指示在附加头之后存在可选头扩展以用于链路层头的未来扩展。值0可指示不存在可选头扩展。

根据给定实施例，可另外提供分组ID字段以指示各个片段是从相同的输入分组生成的。当片段按照顺序发送时，此字段可能是不必要的，因此被省略。

以下将描述当使用级联时的附加头。

当Segmentation_Concatenation(S/C)＝“1”时，此附加头(tsib10030)可存在。

Length_MSB可以是4比特字段，其可指示此链路层分组中的有效载荷长度(字节)的MSB比特。对于级联，有效载荷的最大长度是32767字节。如上文所述，具体数值可改变。

Count可以是可指示链路层分组中所包括的分组的数量的字段。链路层分组中所包括的分组的数量2可被设定为此字段。因此，链路层分组中的级联分组的最大值为9。count字段指示数量的方案可根据实施例而变化。即，可指示从1至8的数量。

HEF(头扩展标志)可以是1比特字段，其在被设定为1时可指示在附加头之后存在可选头扩展以用于链路层头的未来扩展。值0可指示不存在扩展头。

Component_Length可以是12比特长度字段，其可指示各个分组的长度(字节)。除了最后组件分组以外，Component_Length字段按照与存在于有效载荷中的分组相同的顺序被包括。长度字段的数量可由(Count+1)指示。根据给定实施例，可存在数量与count字段的值相同的长度字段。当链路层头由奇数个Component_Length组成时，四个填充比特可跟随在最后Component_Length字段之后。这些比特可被设定为0。根据给定实施例，指示最后级联的输入分组的长度的Component_length字段可不存在。在这种情况下，最后级联的输入分组的长度可对应于从整个有效载荷长度减去各个Component_length字段所指示的值之和而获得的长度。

以下将描述可选头。

如上文所述，可选头可被添加到附加头的后面。可选头字段可包含SID和/或头扩展。SID用于在链路层层面滤除特定分组流。SID的一个示例是承载多个服务的链路层流中的服务标识符的角色。如果适用的话，可在SLT中提供服务与该服务所对应的SID值之间的映射信息。头扩展包含扩展字段以用于未来使用。接收机可忽略它们不理解的任何头扩展。

SID(子流标识符)可以是可指示链路层分组的子流标识符的8比特字段。如果存在可选头扩展，则附加头与可选头扩展之间存在SID。

Header_Extension()可包括下面所定义的字段。

Extension_Type可以是可指示Header_Extension()的类型的8比特字段。

Extension_Length可以是8比特字段，其可指示从下一字节到Header_Extension()的最后字节计数的Header Extension()的长度(字节)。

Extension_Byte可以是表示Header_Extension()的值的字节。

图11示出根据本发明的另一实施例的链路层分组的附加头的结构。

以下将描述用于信令信息的附加头。

链路层信令如何被并入链路层分组中如下。当基本头的Packet_Type字段等于100时标识信令分组。

图(tsib11010)示出包含用于信令信息的附加头的链路层分组的结构。除了链路层头以外，链路层分组可由两个附加部分、用于信令信息的附加头和实际信令数据本身组成。链路层分组头中示出链路层信令分组的总长度。

用于信令信息的附加头可包括以下字段。根据给定实施例，一些字段可被省略。

Signaling_Type可以是可指示信令的类型的8比特字段。

Signaling_Type_Extension可以是可指示信令的属性的16比特字段。此字段的细节可在信令规范中定义。

Signaling_Version可以是可指示信令的版本的8比特字段。

Signaling_Format可以是可指示信令数据的数据格式的2比特字段。这里，信令格式可表示诸如二进制格式、XML格式等的数据格式。

Signaling_Encoding可以是可指定编码/压缩格式的2比特字段。此字段可指示是否不执行压缩以及执行哪种类型的压缩。

以下将描述用于分组类型扩展的附加头。

为了提供允许在未来通过链路层承载几乎无限数量的附加协议和分组类型的机制，定义附加头。如上所述，当在基本头中Packet_type为111时可使用分组类型扩展。图(tsib11020)示出包含用于类型扩展的附加头的链路层分组的结构。

用于类型扩展的附加头可包括以下字段。根据给定实施例，一些字段可被省略。

extended_type可以是16比特字段，其可指示作为有效载荷封装在链路层分组中的输入的协议或分组类型。此字段无法用于Packet_Type字段已经定义的任何协议或分组类型。

图12示出根据本发明的实施例的用于MPEG-2TS分组的链路层分组的头结构及其封装处理。

以下将描述当作为输入分组输入MPEG-2TS分组时的链路层分组的格式。

在这种情况下，基本头的Packet_Type字段等于010。多个TS分组可被封装在各个链路层分组内。TS分组的数量经由NUMTS字段来通知。在这种情况下，如上文所述，可使用特定链路层分组头格式。

链路层提供用于MPEG-2TS以增强传输效率的开销降低机制。各个TS分组的同步字节(0x47)可被删除。还提供删除NULL分组和相似TS头的选项。

为了避免不必要的传输开销，TS空分组(PID＝0x1FFF)可被去除。删除的空分组可在接收机侧利用DNP字段恢复。DNP字段指示删除的空分组的计数。下面描述使用DNP字段的空分组删除机制。

为了实现更高的传输效率，MPEG-2TS分组的相似的头可被去除。当两个或更多个连续的TS分组具有顺序增加的连续性计数器字段并且其它头字段相同时，所述头在第一分组中发送一次，其它头被删除。HDM字段可指示是否执行头删除。下面描述公共TS头删除的详细过程。

当执行所有三种开销降低机制时，可按照同步去除、空分组删除和公共头删除的顺序执行开销降低。根据给定实施例，各个机制的执行顺序可改变。另外，根据给定实施例，一些机制可被省略。

图(tsib12010)中描绘了当使用MPEG-2TS分组封装时链路层分组头的总体结构。

以下将描述各个示出的字段。Packet_Type可以是3比特字段，其可如上所述指示输入分组的协议类型。对于MPEG-2TS分组封装，此字段可总是被设定为010。

NUMTS(TS分组的数量)可以是4比特字段，其可指示此链路层分组的有效载荷中的TS分组的数量。一个链路层分组中可支持最多16个TS分组。NUMTS＝0的值可指示链路层分组的有效载荷承载16个TS分组。对于NUMTS的所有其它值，识别相同数量的TS分组，例如NUMTS＝0001表示承载一个TS分组。

AHF(附加头标志)可以是可指示是否存在附加头的字段。值0指示不存在附加头。值1指示长度1字节的附加头存在于基本头之后。如果空TS分组被删除或者应用TS头压缩，则此字段可被设定为1。用于TS分组封装的附加头由随后的两个字段组成，并且仅当此链路层分组中的AHF的值被设定为1时存在。

HDM(头删除模式)可以是1比特字段，其指示是否可对此链路层分组应用TS头删除。值1指示可应用TS头删除。值“0”指示不对此链路层分组应用TS头删除方法。

DNP(删除空分组)可以是7比特字段，其指示在此链路层分组之前的删除空TS分组的数量。最多128个空TS分组可被删除。当HDM＝0时，DNP＝0的值可指示128个空分组被删除。当HDM＝1时，DNP＝0的值可指示没有空分组被删除。对于DNP的所有其它值，识别相同数量的空分组，例如DNP＝5表示5个空分组被删除。

上述各个字段的比特数可改变。根据改变的比特数，字段所指示的值的最小/最大值可改变。这些数量可由设计者来改变。

以下，将描述SYNC字节去除。

在将TS分组封装到链路层分组的有效载荷中时，从各个TS分组的开头的SYNC字节(0x47)可被删除。因此，封装在链路层分组的有效载荷中的MPEG2-TS分组的长度总是为长度187字节(代替原来的188字节)。

以下将描述空分组删除。

传输流规则要求发送机的复用器的输出处和接收机的解复用器的输入处的比特率在时间上恒定，并且端对端时延也恒定。对于一些传输流输入信号，可存在空分组以便适应恒定比特流中的可变比特率服务。在这种情况下，为了避免不必要的传输开销，TS空分组(具有PID＝0x1FFF的TS分组)可被去除。该处理按照去除的空分组可在接收机中被重新插入它们原来所在的精确位置的方式执行，因此保证了恒定比特率并且避免了对PCR时间戳更新的需求。

在生成链路层分组之前，称为DNP(删除空分组)的计数器可首先被重置为零，然后针对要被封装到当前链路层分组的有效载荷中的第一非空TS分组前面的各个删除的空分组增加。然后，一组连续有用的TS分组被封装到当前链路层分组的有效载荷中，并且可确定其头中的各个字段的值。在将所生成的链路层分组注入物理层之后，DNP被重置为零。当DNP达到其最大允许值时，如果下一分组也是空分组，则此空分组作为有用分组被预留并被封装到下一链路层分组的有效载荷中。各个链路层分组可在其有效载荷中包含至少一个有用TS分组。

以下将描述TS分组头删除。TS分组头删除可被称作TS分组头压缩。

当两个或更多个连续TS分组具有顺序增加的连续性计数器字段并且其它头字段相同时，头在第一分组处被发送一次，其它头被删除。当两个或更多个连续TS分组中包括重复的MPEG-2TS分组时，在发送机侧无法应用头删除。HDM字段可指示是否执行头删除。当执行TS头删除时，HDM可被设定为1。在接收机侧，利用第一分组头，恢复删除的分组头，并且通过按照从第一头开始的顺序增加来恢复连续性计数器。

图中所示的示例tsib12020是TS分组的输入流被封装到链路层分组中的处理的示例。首先，可输入包括具有SYNC字节(0x47)的TS分组的TS流。首先，可通过同步字节删除处理来删除同步字节。在此示例中，假定不执行空分组删除。

这里，假定除了CC(即，连续性计数器字段值)以外，八个TS分组的分组头具有相同的字段值。在这种情况下，可执行TS分组删除/压缩。除了与CC＝1对应的第一TS分组头以外，删除剩余的七个TS分组头。处理后的TS分组可被封装到链路层分组的有效载荷中。

在完成的链路层分组中，Packet_Type字段对应于输入TS分组的情况，因此可具有值010。NUMTS字段可指示所封装的TS分组的数量。由于执行分组头删除，AHF字段可被设定为1以指示附加头的存在。由于执行头删除，HDM字段可被设定为1。由于不执行空分组删除，DNP可被设定为0。

图13示出根据本发明的实施例的IP头压缩中的适配模式的示例(发送侧)。

以下将描述IP头压缩。

在链路层中，可提供IP头压缩/解压缩方案。IP头压缩可包括两个部分：头压缩器/解压缩器和适配模块。头压缩方案可基于鲁棒头压缩(ROHC)。另外，对于广播用途，增加适配功能。

在发送机侧，ROHC压缩器减小各个分组的头的大小。然后，适配模块提取上下文信息并且从各个分组流构建信令信息。在接收机侧，适配模块解析与所接收到的分组流关联的信令信息并且将上下文信息附到所接收到的分组流。ROHC解压缩器通过恢复分组头来重构原始IP分组。

头压缩方案可如上所述基于RoHC。具体地讲，在本系统中，RoHC框架可在RoHC的单向模式(U模式)下操作。另外，在本系统中，可使用由0x0002的简档标识符标识的RoHC UDP头压缩简档。

以下将描述适配。

在通过单向链路的传输中，如果接收机没有上下文信息，则解压缩器无法恢复所接收到的分组头直至接收到完整上下文。这可导致信道改变时延和打开时延。因此，压缩器与解压缩器之间的上下文信息和配置参数可总是随分组流发送。

适配功能提供配置参数和上下文信息的带外传输。带外传输可通过链路层信令来进行。因此，适配功能用于减少由于上下文信息的损失引起的信道改变时延和解压缩错误。

以下将描述上下文信息的提取。

可根据适配模式利用各种方案来提取上下文信息。在本发明中，将在下面描述三个示例。本发明的范围不限于下面将要描述的适配模式的示例。这里，适配模式可被称作上下文提取模式。

适配模式1(未示出)可以是不对基本RoHC分组流应用附加操作的模式。换言之，在此模式下适配模块可用作缓冲器。因此，在此模式下，链路层信令中可不包括上下文信息。

在适配模式2(tsib13010)下，适配模块可从ROHC分组流检测IR分组并且提取上下文信息(静态链)。在提取上下文信息之后，可将各个IR分组转换为IR-DYN分组。所转换的IR-DYN分组可代替原始分组按照与IR分组相同的顺序被包括在ROHC分组流内并被发送。

在适配模式3(tsib13020)下，适配模块可从ROHC分组流检测IR和IR-DYN分组并且提取上下文信息。可从IR分组提取静态链和动态链，并且可从IR-DYN分组提取动态链。在提取上下文信息之后，各个IR和IR-DYN分组可被转换为压缩分组。压缩分组格式可与下一IR分组或IR-DYN分组相同。所转换的压缩分组可代替原始分组按照与IR或IR-DYN分组相同的顺序被包括在ROHC分组流内并被发送。

可基于传输结构来封装信令(上下文)信息。例如，上下文信息可被封装到链路层信令。在这种情况下，分组类型值可被设定为“100”。

在上述适配模式2和3下，用于上下文信息的链路层分组可具有分组类型字段值100。另外，用于压缩IP分组的链路层分组可具有分组类型字段值001。所述值指示信令信息和压缩IP分组中的每一个如上所述被包括链路层分组中。

以下将描述发送所提取的上下文信息的方法。

所提取的上下文信息可与ROHC分组流独立地随信令数据一起通过特定物理数据路径来发送。上下文的传输取决于物理层路径的配置。上下文信息可随其它链路层信令一起通过信令数据管道发送。

换言之，具有上下文信息的链路层分组可随具有其它链路层信令信息的链路层分组一起通过信令PLP来发送(Packet_Type＝100)。提取上下文信息的压缩IP分组可通过一般PLP来发送(Packet_Type＝001)。这里，根据实施例，信令PLP可表示L1信令路径。另外，根据实施例，信令PLP可不与一般PLP分离，可表示发送信令信息的特定PLP和一般PLP。

在接收侧，在接收分组流之前，接收机可能需要获取信令信息。当接收机将初始PLP解码以获取信令信息时，还可接收上下文信令。在进行了信令获取之后，可选择接收分组流的PLP。换言之，接收机可通过选择初始PLP来获取包括上下文信息的信令信息。这里，初始PLP可以是上述信令PLP。此后，接收机可选择用于获取分组流的PLP。这样，可在接收分组流之前获取上下文信息。

在选择了用于获取分组流的PLP之后，适配模块可从所接收到的分组流检测IR-DYN分组。然后，适配模块从信令数据中的上下文信息解析静态链。这类似于接收IR分组。对于相同的上下文标识符，IR-DYN分组可被恢复成IR分组。所恢复的ROHC分组流可被发送给ROHC解压缩器。此后，可开始解压缩。

图14示出根据本发明的实施例的链路映射表(LMT)和RoHC-U描述表。

以下将描述链路层信令。

通常，链路层信令在IP级别下操作。在接收机侧，链路层信令可比诸如服务列表表格(SLT)和服务层信令(SLS)的IP级别信令更早获得。因此，可在会话建立之前获得链路层信令。

对于链路层信令，根据输入路径可存在两种类型的信令：内部链路层信令和外部链路层信令。内部链路层信令在发送机侧的链路层中生成。并且链路层从外部模块或协议取得信令。这种类型的信令信息被视为外部链路层信令。如果一些信令需要在IP级别信令之前获得，则以链路层分组的格式发送外部信令。

链路层信令可如上所述被封装到链路层分组中。链路层分组可承载任何格式的链路层信令，包括二进制和XML。对于链路层信令可不按照不同的格式发送相同的信令信息。

内部链路层信令可包括用于链路映射的信令信息。链路映射表(LMT)提供PLP中承载的上层会话的列表。LMT还提供用于处理链路层中的承载上层会话的链路层分组的附加信息。

示出根据本发明的LMT的示例(tsib14010)。

signaling_type可以是指示该表所承载的信令的类型的8比特无符号整数字段。用于链路映射表(LMT)的signaling_type字段的值可被设定为0x01。

PLP_ID可以是指示与该表对应的PLP的8比特字段。

num_session可以是8比特无符号整数字段，其提供上面的PLP_ID字段所标识的PLP中承载的上层会话的数量。当signaling_type字段的值为0x01时，此字段可指示PLP中的UDP/IP会话的数量。

src_IP_add可以是32比特无符号整数字段，其包含PLP_ID字段所标识的PLP中承载的上层会话的源IP地址。

dst_IP_add可以是32比特无符号整数字段，其包含PLP_ID字段所标识的PLP中承载的上层会话的目的地IP地址。

src_UDP_port可以是16比特无符号整数字段，其表示PLP_ID字段所标识的PLP中承载的上层会话的源UDP端口号。

dst_UDP_port可以是16比特无符号整数字段，其表示PLP_ID字段所标识的PLP中承载的上层会话的目的地UDP端口号。

SID_flag可以是1比特布尔字段，其指示承载上面4个字段Src_IP_add、Dst_IP_add、Src_UDP_Port和Dst_UDP_Port所标识的上层会话的链路层分组是否在其可选头中具有SID字段。当此字段的值被设定为0时，承载上层会话的链路层分组可在其可选头中不具有SID字段。当此字段的值被设定为1时，承载上层会话的链路层分组可在其可选头中具有SID字段，并且SID字段的值可与该表中随后的SID字段相同。

compressed_flag可以是1比特布尔字段，其指示是否对承载上面4个字段Src_IP_add、Dst_IP_add、Src_UDP_Port和Dst_UDP_Port所标识的上层会话的链路层分组应用头压缩。当此字段的值被设定为0时，承载上层会话的链路层分组可在其基本头中具有值为0x00的Packet_Type字段。当此字段的值被设定为1时，承载上层会话的链路层分组可在其基本头中具有值为0x01的Packet_Type字段并且可存在Context_ID字段。

SID可以是8比特无符号整数字段，其指示承载上面4个字段Src_IP_add、Dst_IP_add、Src_UDP_Port和Dst_UDP_Port所标识的上层会话的链路层分组的子流标识符。当SID_flag的值等于1时，此字段可存在。

context_id可以是8比特字段，其提供对ROHC-U描述表中所提供的上下文id(CID)的参考。当compressed_flag的值等于1时，此字段可存在。

示出根据本发明的RoHC-U描述表的示例(tsib14020)。如上文所述，RoHC-U适配模块可生成与头压缩有关的信息。

signaling_type可以是指示该表所承载的信令的类型的8比特字段。ROHC-U描述表(RDT)的signaling_type字段的值可被设定为“0x02”。

PLP_ID可以是指示与该表对应的PLP的8比特字段。

context_id可以是指示压缩IP流的上下文id(CID)的8比特字段。在该系统中，8比特CID可用于大CID。

context_profile可以是指示用于压缩流的协议的范围的8比特字段。此字段可被省略。

adaptation_mode可以是指示该PLP中的适配模块的模式的2比特字段。适配模式上面已描述。

context_config可以是指示上下文信息的组合的2比特字段。如果该表中不存在上下文信息，则此字段可被设定为“0x0”。如果static_chain()或dynamic_chain()字节被包括在该表中，则此字段可分别被设定为“0x01”或“0x02”。如果static_chain()和dynamic_chain()字节二者均被包括在该表中，则此字段可被设定为“0x03”。

context_length可以是指示静态链字节序列的长度的8比特字段。此字段可被省略。

static_chain_byte()可以是传达用于将ROHC-U解压缩器初始化的静态信息的字段。此字段的大小和结构取决于上下文简档。

dynamic_chain_byte()可以是传达用于将ROHC-U解压缩器初始化的动态信息的字段。此字段的大小和结构取决于上下文简档。

static_chain_byte可被定义为IR分组的子头信息。dynamic_chain_byte可被定义为IR分组和IR-DYN分组的子头信息。

图15示出根据本发明的实施例的发送机侧的链路层的结构。

本实施例假定处理IP分组。从功能角度，发送机侧的链路层可大体包括处理信令信息的链路层信令部分、开销降低部分和/或封装部分。另外，发送机侧的链路层可包括用于控制和调度链路层的总体操作和/或链路层的输入和输出部分的调度器。

首先，上层的信令信息和/或系统参数tsib15010可被传送至链路层。另外，包括IP分组的IP流可从IP层tsib15110被传送至链路层。

如上所述，调度器tsib15020可确定和控制包括在链路层中的多个模块的操作。所传送的信令信息和/或系统参数tsib15010可由调度器tsib15020过滤或使用。接收机所需的与所传送的信令信息和/或系统参数tsib15010的一部分对应的信息可被传送给链路层信令部分。另外，链路层的操作所需的与信令信息的一部分对应的信息可被传送至开销降低控制器tsib15120或封装控制器tsib15180。

链路层信令部分可收集要作为信号在物理层中发送的信息，并且以适合于传输的形式来转换/配置该信息。链路层信令部分可包括信令管理器tsib15030、信令格式化器tsib15040和/或信道缓冲器tsib15050。

信令管理器tsib15030可接收从调度器tsib15020传送来的信令信息和/或从开销降低部分传送来的信令(和/或上下文)信息。信令管理器tsib15030可确定用于所传送的数据的信令信息的传输的路径。信令信息可通过信令管理器tsib15030所确定的路径来传送。如上文所述，要通过所划分的信道发送的信令信息(例如，FIC、EAS等)可被传送至信令格式化器tsib15040，其它信令信息可被传送至封装缓冲器tsib15070。

信令格式化器tsib15040可按照适合于各个划分的信道的形式将相关的信令信息格式化，使得信令信息可通过单独划分的信道来发送。如上文所述，物理层可包括单独的物理/逻辑划分的信道。所划分的信道可用于发送FIC信令信息或EAS相关信息。FIC或EAS相关信息可由信令管理器tsib15030排序并被输入到信令格式化器tsib15040。信令格式化器tsib15040可基于各个单独的信道将信息格式化。当物理层被设计为通过单独划分的信道发送FIC和EAS以外的特定信令信息时，可另外提供用于该特定信令信息的信令格式化器。通过此方案，链路层可与各种物理层兼容。

信道缓冲器tsib15050可将从信令格式化器tsib15040接收的信令信息传送至单独的专用信道tsib15060。单独的信道的数量和内容可根据实施例而变化。

如上文所述，信令管理器tsib15030可将没有被传送至特定信道的信令信息传送至封装缓冲器tsib15070。封装缓冲器tsib15070可用作接收没有被传送至特定信道的信令信息的缓冲器。

信令信息封装块tsib15080可对没有被传送至特定信道的信令信息进行封装。发送缓冲器tsib15090可用作将封装的信令信息传送至用于信令信息的DP tsib15100的缓冲器。这里，用于信令信息的DP tsib15100可表示上述PLS区域。

开销降低部分可通过去除被传送至链路层的分组的开销来允许高效传输。可配置与输入到链路层的IP流的数量对应的开销降低部分。

开销降低缓冲器tsib15130可接收从上层传送来的IP分组。所接收到的IP分组可通过开销降低缓冲器tsib15130被输入到开销降低部分。

开销降低控制器tsib15120可确定是否对输入至开销降低缓冲器tsib15130的分组流执行开销降低。开销降低控制器tsib15120可针对各个分组流确定是否执行开销降低。当对分组流执行开销降低时，分组可被传送至鲁棒头压缩(RoHC)压缩器tsib15140以执行开销降低。当不对分组流执行开销降低时，分组可被传送至封装部分以在没有开销降低的情况下执行封装。是否执行分组的开销降低可基于传送至链路层的信令信息tsib15010来确定。信令信息可通过调度器tsib15020被传送至封装控制器tsib15180。

RoHC压缩器tsib15140可对分组流执行开销降低。RoHC压缩器tsib15140可执行压缩分组的头的操作。各种方案可用于开销降低。可利用本发明所提出的方案来执行开销降低。本发明假定IP流，因此使用表达“RoHC压缩器”。然而，该名称可根据实施例而改变。操作不限于IP流的压缩，可通过RoHC压缩器tsib15140来执行所有类型的分组的开销降低。

分组流配置块tsib15150可从具有压缩头的IP分组分离要发送至信令区域的信息与要发送至分组流的信息。要发送至分组流的信息可表示要发送至DP区域的信息。要发送至信令区域的信息可被传送至信令和/或上下文控制器tsib15160。要发送至分组流的信息可被发送至封装部分。

信令和/或上下文控制器tsib15160可收集信令和/或上下文信息并且将该信令和/或上下文信息传送至信令管理器以便将信令和/或上下文信息发送至信令区域。

封装部分可执行以适合于向物理层传送的形式封装分组的操作。可配置与IP流的数量对应的封装部分。

封装缓冲器tsib15170可接收分组流以用于封装。当执行开销降低时可接收经受开销降低的分组，当不执行开销降低时可没有改变地接收输入IP分组。

封装控制器tsib15180可确定是否封装输入分组流。当执行封装时，分组流可被传送至分割/级联块tsib15190。当不执行封装时，分组流可被传送至发送缓冲器tsib15230。是否封装分组可基于传送至链路层的信令信息tsib15010来确定。信令信息可通过调度器tsib15020被传送至封装控制器tsib15180。

在分割/级联块tsib15190中，可对分组执行上述分割或级联操作。换言之，当输入IP分组比与链路层的输出对应的链路层分组长时，一个IP分组可被分成多个片段以配置多个链路层分组有效载荷。另一方面，当输入IP分组比与链路层的输出对应的链路层分组短时，多个IP分组可被级联以配置一个链路层分组有效载荷。

分组配置表tsib15200可具有分割和/或级联的链路层分组的配置信息。发送机和接收机可在分组配置表tsib15200中具有相同的信息。发送机和接收机可参考分组配置表tsib15200的信息。分组配置表tsib15200的信息的索引值可被包括在链路层分组的头中。

链路层头信息块tsib15210可收集在封装处理中生成的头信息。另外，链路层头信息块tsib15210可收集包括在分组配置表tsib15200中的头信息。链路层头信息块tsib15210可根据链路层分组的头结构来配置头信息。

头附接块tsib15220可将头添加到分割和/或级联的链路层分组的有效载荷。发送缓冲器tsib15230可用作将链路层分组传送至物理层的DP tsib15240的缓冲器。

各个块、模块或部分可被配置为链路层中的一个模块/协议或多个模块/协议。

图16示出根据本发明的实施例的接收机侧的链路层的结构。

本实施例假定处理IP分组。从功能角度，接收机侧的链路层可大体包括处理信令信息的链路层信令部分、开销处理部分和/或解封装部分。另外，接收机侧的链路层可包括用于控制和调度链路层的总体操作和/或链路层的输入和输出部分的调度器。

首先，通过物理层接收的信息可被传送至链路层。链路层可处理信息，恢复在发送机侧被处理之前的原始状态，然后将信息传送至上层。在本实施例中，上层可以是IP层。

在物理层中分离并且通过特定信道tsib16030传送的信息可被传送至链路层信令部分。链路层信令部分可确定从物理层接收的信令信息，并且将所确定的信令信息传送至链路层的各个部分。

信道缓冲器tsib16040可用作接收通过特定信道发送的信令信息的缓冲器。如上文所述，当物理/逻辑划分的单独的信道存在于物理层中时，可接收通过信道发送的信令信息。当从单独的信道接收的信息被分割时，分割的信息可被存储，直至配置完整信息。

信令解码器/解析器tsib16050可核实通过特定信道接收的信令信息的格式，并且提取链路层中要使用的信息。当通过特定信道接收的信令信息被编码时，可执行解码。另外，根据给定实施例，可核实信令信息的完整性等。

信令管理器tsib16060可将通过多个路径接收的信令信息整合。通过用于信令的DP tsib16070(将在下面描述)接收的信令信息可在信令管理器tsib16060中被整合。信令管理器tsib16060可传送链路层中的各个部分所需的信令信息。例如，信令管理器tsib16060可将用于恢复分组的上下文信息等传送至开销处理部分。另外，信令管理器tsib16060可将用于控制的信令信息传送至调度器tsib16020。

没有通过单独的特定信道接收的一般信令信息可通过用于信令的DP tsib16070来接收。这里，用于信令的DP可表示PLS、L1等。这里，DP可被称作PLP。接收缓冲器tsib16080可用作接收从用于信令的DP传送来的信令信息的缓冲器。在信令信息解封装块tsib16090中，可将所接收到的信令信息解封装。解封装的信令信息可通过解封装缓冲器tsib16100被传送至信令管理器tsib16060。如上文所述，信令管理器tsib16060可校对信令信息并且将校对的信令信息传送至链路层中的必要部分。

调度器tsib16020可确定并控制包括在链路层中的多个模块的操作。调度器tsib16020可利用接收机信息tsib16010和/或从信令管理器tsib16060传送的信息来控制链路层的各个部分。另外，调度器tsib16020可确定各个部分的操作模式等。这里，接收机信息tsib16010可表示先前存储在接收机中的信息。调度器tsib16020可使用由用户改变的信息(例如，信道切换等)来执行控制操作。

解封装部分可过滤从物理层的DP tsib16110接收的分组，并且根据分组的类型来分离分组。可配置与物理层中可同时解码的DP的数量对应的解封装部分。

解封装缓冲器tsib16100可用作从物理层接收分组流以执行解封装的缓冲器。解封装控制器tsib16130可确定是否将输入分组流解封装。当执行解封装时，分组流可被传送至链路层头解析器tsib16140。当不执行解封装时，分组流可被传送至输出缓冲器tsib16220。从调度器tsib16020接收的信令信息可用于确定是否执行解封装。

链路层头解析器tsib16140可标识所传送的链路层分组的头。可通过标识头来标识链路层分组的有效载荷中所包括的IP分组的配置。例如，IP分组可被分割或级联。

分组配置表tsib16150可包括分割和/或级联的链路层分组的有效载荷信息。发送机和接收机可在分组配置表tsib16150中具有相同的信息。发送机和接收机可参考分组配置表tsib16150的信息。可基于包括在链路层分组中的索引信息来寻找重组所需的值。

重组块tsib16160可将分割和/或级联的链路层分组的有效载荷配置为原始IP流的分组。片段可被收集并重新配置为一个IP分组，或者级联的分组可被分离并重新配置为多个IP分组流。重组的IP分组可被传送至开销处理部分。

开销处理部分可执行将经受开销降低的分组恢复为原始分组的操作，作为发送机中执行的开销降低的逆操作。该操作可被称作开销处理。可配置与物理层中可同时解码的DP的数量对应的开销处理部分。

分组恢复缓冲器tsib16170可用作接收解封装的RoHC分组或IP分组以执行开销处理的缓冲器。

开销控制器tsib16180可确定是否恢复和/或解压缩解封装的分组。当执行恢复和/或解压缩时，分组可被传送至分组流恢复块tsib16190。当不执行恢复和/或解压缩时，分组可被传送至输出缓冲器tsib16220。是否执行恢复和/或解压缩可基于调度器tsib16020所传送的信令信息来确定。

分组流恢复块tsib16190可执行将从发送机分离的分组流与分组流的上下文信息整合的操作。此操作可以是恢复分组流以使得RoHC解压缩器tsib16210可执行处理的处理。在此处理中，可从信令和/或上下文控制器tsib16200接收信令信息和/或上下文信息。信令和/或上下文控制器tsib16200可确定从发送机传送来的信令信息，并且将该信令信息传送至分组流恢复块tsib16190，使得信令信息可被映射至与上下文ID对应的流。

RoHC解压缩器tsib16210可恢复分组流的分组的头。可通过头的恢复将分组流的分组恢复成原始IP分组的形式。换言之，RoHC解压缩器tsib16210可执行开销处理。

输出缓冲器tsib16220可用作在输出流被传送至IP层tsib16230之前的缓冲器。

本发明中所提出的发送机和接收机的链路层可包括上述块或模块。这样，链路层可独立地操作，而不管上层和下层，可有效地执行开销降低，并且可容易地定义/增加/删除根据上层/下层可支持的功能。

图17示出根据本发明的实施例的通过链路层的信令传输的配置(发送侧/接收侧)。

在本发明中，多个服务提供商(广播商)可在一个频带内提供服务。另外，服务提供商可提供多个服务，并且一个服务可包括一个或更多个组件。可认为用户使用服务作为单位来接收内容。

本发明假定使用基于多个会话的传输协议来支持IP混合广播。通过信令路径传送的信令信息可基于各个协议的传输配置来确定。根据给定实施例，各种名称可被应用于各个协议。

在所示的发送侧的数据配置tsib17010中，服务提供商(广播商)可提供多个服务(服务#1、#2、…)。通常，用于服务的信号可通过一般传输会话来发送(信令C)。然而，根据给定实施例，信号可通过特定会话(专用会话)来发送(信令B)。

服务数据和服务信令信息可根据传输协议来封装。根据给定实施例，可使用IP/UDP层。根据给定实施例，可另外提供IP/UDP层中的信号(信令A)。此信令可被省略。

使用IP/UDP处理的数据可被输入到链路层。如上文所述，可在链路层中执行开销降低和/或封装。这里，可另外提供链路层信令。链路层信令可包括系统参数等。上面已描述了链路层信令。

经受上述处理的服务数据和信令信息可在物理层中通过PLP来处理。这里，PLP可被称作DP。图中所示的示例假定使用基本DP/PLP的情况。然而，根据实施例，可在没有基本DP/PLP的情况下仅利用一般DP/PLP来执行传输。

在图中所示的示例中，使用诸如FIC、EAC等的特定信道(专用信道)。通过FIC传送的信号可被称作快速信息表(FIT)，通过EAC传送的信号可被称作紧急报警表(EAT)。FIT可与上述SLT相同。根据实施例可不使用特定信道。当没有配置特定信道(专用信道)时，FIT和EAT可利用一般链路层信令传输方案来发送，或者作为其它服务数据经由IP/UDP利用PLP来发送。

根据给定实施例，系统参数可包括发送机相关参数、服务提供商相关参数等。链路层信令可包括IP头压缩相关上下文信息和/或上下文所应用于的数据的标识信息。上层信令可包括IP地址、UDP号、服务/组件信息、紧急报警相关信息、服务信令的IP/UDP地址、会话ID等。上面已描述了其详细示例。

在所示的接收侧的数据配置tsib17020中，接收机可仅利用信令信息将用于对应服务的PLP解码，而不必将所有PLP解码。

首先，当用户选择或改变期望接收的服务时，接收机可被调谐至对应频率并且可读取存储在DB等中的与对应信道有关的接收机信息。存储在接收机的DB等中的信息可通过在初始信道扫描时读取SLT来配置。

在接收SLT和关于对应信道的信息之后，更新先前存储在DB中的信息，并且获取关于用户所选择的服务的传输路径的信息以及关于获取组件信息或者发送获取信息所需的信号的路径的信息。当利用SLT的版本信息确定信息没有改变时，可省略解码或解析。

接收机可通过解析可通过物理信令的特定字段指示的对应广播流(未示出)中的PLP的物理信令来核实PLP中是否包括SLT信息。可通过访问SLT信息来访问发送特定服务的服务层信令的位置。服务层信号可被封装到IP/UDP中并通过传输会话来传送。可利用该服务层信令获取关于服务中所包括的组件的信息。特定SLT-SLS配置如上所述。

换言之，可利用SLT获取传输路径信息，以用于接收与信道上当前发送的多个分组流和PLP中的一个对应的服务的接收所需的上层信令信息(服务信令信息)。传输路径信息可包括IP地址、UDP端口号、会话ID、PLP ID等。这里，根据实施例，IANA或系统先前指定的值可用作IP/UDP地址。可利用访问DB或共享存储器等的方案来获取信息。

当链路层信号和服务数据通过相同的PLP发送，或者仅操作一个PLP时，在链路层信号被解码的同时，通过该PLP传送的服务数据可被临时存储在诸如缓冲器等的装置中。

可利用要接收的服务的服务信令信息来获取关于实际上发送服务的路径的信息。另外，所接收到的分组流可利用诸如要接收的PLP的开销降低等的信息经受解封装和头恢复。

在所示的示例(tsib17020)中，使用FIC和EAC，并且假定基本DP/PLP的概念。如上文所述，可不使用FIC、EAC和基本DP/PLP的概念。

尽管为了描述方便，在下文中MISO或MIMO使用两个天线，但是本发明适用于使用两个或更多个天线的系统。本发明提出了被优化以在获得特定使用情况所需的性能的同时使接收机复杂度最小化的物理简档(或系统)。根据本发明的实施例的物理(PHY)简档(基本简档、手持简档和高级简档)是对应接收机应该实现的所有简档的子集。PHY简档共享大多数功能块，但是在特定块和/或参数方面略有不同。为了系统演进，在单个射频(RF)信道中也可通过未来扩展帧(FEF)将未来的简档与现有的简档复用。根据本发明的实施例的基本简档和手持简档是指不应用MIMO的简档，高级简档是指应用MIMO的简档。基本简档可用作地面广播服务和移动广播服务二者的简档。即，基本简档可用于定义包括移动简档的简档的概念。另外，高级简档可被分成用于具有MIMO的基本简档的高级简档以及用于具有MIMO的手持简档的高级简档。此外，简档可根据设计者的意图而改变。

以下术语和定义可应用于本发明。以下术语和定义可根据设计而改变。

辅助流：承载可用于未来扩展的还未定义的调制和编译或者广播商或网络运营商所需的数据的信元序列

基本数据管道：承载服务信令数据的数据管道

基带帧(或BBFRAME)：形成对一个FEC编码处理(BCH和LDPC编码)的输入的K

信元：由正交频分复用(OFDM)传输的一个载波承载的调制值

编码块：PLS1数据的LDPC编码块或者PLS2数据的LDPC编码块之一

数据管道：承载服务数据或相关的元数据的物理层中的逻辑信道，其可承载一个或多个服务或者服务组件。

数据管道单元(DPU)：向帧中的DP分配数据信元的基本单元。

数据符号：帧中的非前导码符号的OFDM符号(数据符号涵盖帧信令符号和帧边缘符号)

DP_ID：此8比特字段唯一地标识由SYSTEM_ID标识的系统内的DP

哑信元：承载用于填充未用于PLS信令、DP或辅助流的剩余容量的伪随机值的信元

紧急报警信道(EAC)：承载EAS信息数据的帧的部分

帧：以前导码开始并以帧边缘符号结束的物理层时隙

帧重复单元：属于相同或不同的物理层简档的帧(包括FEF)的集合，其在超帧中被重复八次

快速信息信道(FIC)：帧中的逻辑信道，其承载服务与对应基本DP之间的映射信息

FECBLOCK：DP数据的LDPC编码比特的集合

FFT大小：用于特定模式的标称FFT大小，等于以基本周期T的循环表示的有效符号周期T

帧信令符号：具有更高导频密度的OFDM符号，其用在FFT大小、保护间隔和分散导频图案的特定组合中的帧的开始处，承载PLS数据的一部分

帧边缘符号：具有更高导频密度的OFDM符号，其用在FFT大小、保护间隔和分散导频图案的特定组合中的帧的结尾处

帧组：超帧中具有相同PHY简档类型的所有帧的集合

未来扩展帧：超帧内的可用于未来扩展的物理层时隙，其以前导码开始

Futurecast UTB系统：所提出的物理层广播系统，其输入是一个或更多个MPEG2-TS、IP或一般流，其输出是RF信号

输入流：由系统传送给终端用户的服务集的数据流

正常数据符号：除了帧信令符号和帧边缘符号以外的数据符号

PHY简档：对应接收机应该实现的所有配置的子集

PLS：包括PLS1和PLS2的物理层信令数据

PLS1：具有固定大小、编译和调制的帧信令符号(FSS)中所承载的PLS数据的第一集合，其承载关于系统的基本信息以及对PLS2解码所需的参数

注释：在帧组的持续时间内PLS1数据保持恒定

PLS2：FSS中发送的PLS数据的第二集合，其承载关于系统和DP的更详细的PLS数据

PLS2动态数据：逐帧动态地改变的PLS2数据

PLS2静态数据：在帧组的持续时间内保持静态的PLS2数据

前导码信令数据：由前导码符号承载的信令数据，用于标识系统的基本模式

前导码符号：承载基本PLS数据的固定长度的导频符号，其位于帧的开始处

前导码符号主要用于快速初始频带扫描以检测系统信号、其时序、频率偏移和FFT大小。

为未来使用预留：本文献未定义，但是可在未来定义

超帧：八个帧重复单元的集合

时间交织块(TI块)：执行时间交织的信元的集合，与时间交织器存储器的一次使用对应

TI组：执行针对特定DP的动态容量分配的单元，由数量动态变化的整数个XFECBLOCK构成

注释：TI组可被直接映射至一个帧，或者可被映射至多个帧。TI组可包含一个或更多个TI块。

类型1DP：所有DP按照时分复用(TDM)方案被映射至帧的帧的DP

类型2DP：所有DP按照频分复用(FDM)方案被映射至帧的帧的DP

XFECBLOCK：承载一个LDPC FECBLOCK的所有比特的N

图18示出根据本发明的实施例的用于未来广播服务的广播信号发送设备的配置。

根据本实施例的用于未来广播服务的广播信号发送设备可包括输入格式化块1000、比特交织编译和调制(BICM)块1010、帧构建块1020、OFDM生成块1030和信令生成块1040。将描述广播信号发送设备的各个块的操作。

在根据本发明的实施例的输入数据中，IP流/分组和MPEG2-TS可以是主要输入格式，其它流类型作为一般流处理。除了这些数据输入以外，管理信息被输入以控制各个输入流的对应带宽的调度和分配。另外，本发明允许一个或多个TS流、IP流和/或一般流的同时输入。

输入格式化块1000可将各个输入流解复用为一个或多个数据管道，对各个数据管道应用独立的编译和调制。DP是用于鲁棒控制的基本单元，其影响QoS。一个DP可承载一个或多个服务或服务组件。DP是用于传送服务数据或者相关元数据的物理层中的逻辑信道，其能够承载一个或多个服务或服务组件。

另外，DPU是用于向一个帧中的DP分配数据信元的基本单元。

对物理层的输入可包括一个或多个数据流。各个数据流通过一个DP传送。输入格式化块1000可将通过一个或更多个物理路径(或DP)输入的数据流转换为基带帧(BBF)。在这种情况下，输入格式化块1000可对输入数据(TS或IP输入流)执行空分组删除或头压缩以便增强传输效率。接收机可具有头的特定部分的先验信息，因此可从发送机删除该已知信息。空分组删除块3030可仅用于TS输入流。

在BICM块1010中，增加奇偶校验数据以用于纠错，并且编码的比特被映射至复值星座符号。将这些符号遍及用于对应DP的特定交织深度交织。对于高级简档，在BICM块1010中执行MIMO编码，并且在输出处增加附加数据路径以用于MIMO传输。

帧构建块1020可将输入DP的数据信元映射至帧内的OFDM符号，并且为了频域分集，特别是对抗频率选择性衰落信道，执行频率交织。帧构建块1020可包括时延补偿块、信元映射器和频率交织器。

时延补偿块可调节DP与对应PLS数据之间的时序以确保DP与对应PLS数据在发送机侧同时序。通过解决由输入格式化块和BICM块导致的数据管道的时延，使PLS数据延迟与数据管道相同的量。BICM块的时延主要是由于时间交织器。带内信令数据承载下一TI组的信息以使得在要用信号通知的DP前面一个帧承载该信息。时延补偿块相应地延迟带内信令数据。

信元映射器可将PLS、DP、辅助流、哑信元等映射至帧中的OFDM符号的有效载波。信元映射器7010的基本功能是将各个DP的TI所生成的数据信元、PLS信元和EAC/FIC信元(如果有的话)映射至与帧内的各个OFDM符号对应的有效OFDM信元的阵列中。信元映射器的基本功能是将通过各个DP和PLS信元的时间交织生成的数据信元映射至与一个帧中的各个OFDM符号对应的有效OFDM信元的阵列(如果存在的话)。可通过DP单独地收集并发送服务信令数据(例如，节目特定信息(PSI)/SI)。信元映射器根据调度器所生成的动态信息以及帧结构的配置来操作。频率交织器可将从信元映射器接收的数据信元随机地交织以提供频率分集。另外，频率交织器可利用不同的交织种子顺序在包括两个顺序OFDM符号的OFDM符号对上进行操作以在单个帧中获得最大交织增益。

OFDM生成块1030通过帧构建块所生成的信元来调制OFDM载波，插入导频，并且生成时域信号以用于传输。另外，此块随后插入保护间隔并且应用峰平均功率比(PAPR)降低处理以生成最终RF信号。

具体地讲，在各个帧的开始处插入前导码之后，OFDM生成块1030可以以循环前缀作为保护间隔应用传统OFDM调制。为了天线空间分集，遍及发送机应用分布式MISO方案。另外，在时域中执行PAPR方案。为了灵活的网络规划，本发明提供各种FFT大小、保护间隔长度和对应导频图案的集合。

另外，本发明可在时域中将多个广播发送/接收系统的信号复用，使得提供广播服务的两个或更多个不同的广播发送/接收系统的数据可在相同的RF信号带宽中同时发送。在这种情况下，所述两个或更多个不同的广播发送/接收系统是指提供不同的广播服务的系统。不同的广播服务可表示地面广播服务、移动广播服务等。

信令生成块1040可创建用于各个功能块的操作的物理层信令信息。此信令信息也被发送以使得在接收机侧正确地恢复所关注的服务。根据本发明的实施例的信令信息可包括PLS数据。PLS向接收机提供访问物理层DP的手段。PLS数据包括PLS1数据和PLS2数据。

PLS1数据是具有固定大小、编译和调制的帧中的FSS符号中所承载的PLS数据的第一集合，其承载关于系统的基本信息以及将PLS2数据解码所需的参数。PLS1数据提供基本传输参数，包括允许PLS2数据的接收和解码所需的参数。另外，在帧组的持续时间内PLS1数据保持恒定。

PLS2数据是FSS符号中发送的PLS数据的第二集合，其承载关于系统和DP的更详细的PLS数据。PLS2包含提供足够信息以便于接收机将期望的DP解码的参数。PLS2信令进一步包括两种类型的参数：PLS2静态数据(PLS2-STAT数据)和PLS2动态数据(PLS2-DYN数据)。PLS2静态数据是在帧组的持续时间内保持静态的PLS2数据，PLS2动态数据是逐帧动态地改变的PLS2数据。PLS数据的细节将稍后描述。

上述块可被省略或者被具有相似或相同功能的块取代。

图19示出根据本发明的实施例的BICM块。

图19所示的BICM块对应于参考图18描述的BICM块1010的实施例。

如上所述，根据本发明的实施例的用于未来广播服务的广播信号发送设备可提供地面广播服务、移动广播服务、UHDTV服务等。

由于QoS取决于根据本发明的实施例的用于未来广播服务的广播信号发送设备所提供的服务的特性，所以与各个服务对应的数据需要利用不同的方案来处理。因此，根据本发明的实施例的BICM块可通过独立地对分别与数据路径对应的数据管道应用SISO、MISO和MIMO方案来独立地处理各个DP。因此，根据本发明的实施例的用于未来广播服务的广播信号发送设备可控制通过各个DP发送的各个服务或服务组件的QoS。

(a)示出应用于没有应用MIMO的简档(或系统)的BICM块，(b)示出应用了MIMO的简档(或系统)的BICM块。

没有应用MIMO的BICM块和应用了MIMO的BICM块可包括多个处理块以用于处理各个DP。

将描述没有应用MIMO的BICM块和应用了MIMO的BICM块的各个处理块。

没有应用MIMO的BICM块的处理块5000可包括数据FEC编码器5010、比特交织器5020、星座映射器5030、信号空间分集(SSD)编码块5040和时间交织器5050。

数据FEC编码器5010对输入的BBF执行FEC编码以利用外编译(BCH)和内编译(LDPC)生成FECBLOCK过程。外编译(BCH)是可选的编译方法。数据FEC编码器5010的详细操作将稍后描述。

比特交织器5020可将数据FEC编码器5010的输出交织以在提供高效可实现的结构的同时利用LDPC码和调制方案的组合实现优化的性能。比特交织器5020的详细操作将稍后描述。

星座映射器5030可利用QPSK、QAM-16、非均匀QAM(NUQ-64、NUQ-256或NUQ-1024)或者非均匀星座(NUC-16、NUC-64、NUC-256或NUC-1024)映射对来自基本简档和手持简档中的比特交织器5020的各个信元字或者来自高级简档中的信元字解复用器5010-1的各个信元字进行调制，以给出功率归一化的星座点e

时间交织器5050可在DP层面操作。时间交织(TI)的参数可针对各个DP不同地设定。时间交织器5050的详细操作将稍后描述。

应用了MIMO的BICM块的处理块5000-1可包括数据FEC编码器、比特交织器、星座映射器和时间交织器。

然而，处理块5000-1与没有应用MIMO的BICM块的处理块5000的区别之处在于处理块5000-1还包括信元字解复用器5010-1和MIMO编码块5020-1。

另外，处理块5000-1中的数据FEC编码器、比特交织器、星座映射器和时间交织器的操作对应于上述数据FEC编码器5010、比特交织器5020、星座映射器5030和时间交织器5050的操作，因此省略其描述。

信元字解复用器5010-1用于高级简档的DP以将单个信元字流划分成双信元字流以便于MIMO处理。

MIMO编码块5020-1可利用MIMO编码方案来处理信元字解复用器5010-1的输出。MIMO编码方案被优化以用于广播信号传输。MIMO技术是获得容量增加的有前景的方式，但是它取决于信道特性。特别是对于广播，信道的强LOS组件或者由不同的信号传播特性导致的两个天线之间的接收信号功率差异使得难以从MIMO获得容量增益。所提出的MIMO编码方案利用MIMO输出信号之一的基于旋转的预编码和相位随机化而克服了这一问题。

MIMO编码旨在用于在发送机和接收机二者处需要至少两个天线的2x2 MIMO系统。本发明的MIMO编码模式可被定义为全速率空间复用(FR-SM)。FR-SM编码可提供容量增加并且接收机侧的复杂度的增加相对较小。另外，本发明的MIMO编码方案对天线极性配置没有限制。

在DP层面应用MIMO处理。与成对的星座映射器输出对应的NUQ(e

上述块可被省略或者被具有相似或相同功能的块取代。

图20示出根据本发明的另一实施例的BICM块。

图20所示的BICM块对应于参考图18描述的BICM块1010的另一实施例。

图20示出用于物理层信令(PLS)、紧急报警信道(EAC)和快速信息信道(FIC)的保护的BICM块。EAC是承载EAS信息数据的帧的一部分，FIC是承载服务与对应基本DP之间的映射信息的帧中的逻辑信道。EAC和FIC的细节将稍后描述。

参考图20，用于PLS、EAC和FIC的保护的BICM块可包括PLS FEC编码器6000、比特交织器6010和星座映射器6020。

另外，PLS FEC编码器6000可包括加扰器、BCH编码/零插入块、LDPC编码块和LDPC奇偶校验穿孔块。将描述BICM块的各个块。

PLS FEC编码器6000可对加扰的PLS 1/2数据、EAC和FIC区段进行编码。

加扰器可在BCH编码以及缩短和穿孔的LDPC编码之前对PLS1数据和PLS2数据进行加扰。

BCH编码/零插入块可利用缩短BCH码对加扰的PLS 1/2数据执行外编码以用于PLS保护，并且在BCH编码之后插入零比特。仅针对PLS1数据，可在LDPC编码之前对零插入的输出比特进行置换。

LDPC编码块可利用LDPC码对BCH编码/零插入块的输出进行编码。为了生成完整编码的块，从各个零插入的PLS信息块I

[式1]

LDPC奇偶校验穿孔块可对PLS1数据和PLS2数据执行穿孔。

当缩短被应用于PLS1数据保护时，在LDPC编码之后对一些LDPC奇偶校验比特进行穿孔。另外，为了PLS2数据保护，在LDPC编码之后对PLS2的LDPC奇偶校验比特进行穿孔。不发送这些被穿孔的比特。

比特交织器6010可将各个缩短和穿孔的PLS1数据和PLS2数据交织。

星座映射器6020可将比特交织的PLS1数据和PLS2数据映射至星座。

上述块可被省略或者被具有相似或相同功能的块取代。

图21示出根据本发明的实施例的PLS的比特交织处理。

各个缩短和穿孔的PLS1和PLS2编码块如图22中所述被逐比特地交织。附加奇偶校验比特的各个块利用相同的块交织结构但是单独地交织。

在BPSK的情况下，比特交织存在两个分支以将FEC编码比特复制在实部和虚部中。各个编码块被首先写入上面的分支。通过利用循环移位值floor(N

在诸如QSPK、QAM-16和NUQ-64的其它调制情况下，FEC编码比特被顺次写入交织器列方向，其中列数与调制阶数相同。

在读取操作中，用于一个星座符号的比特从行方向被依次读出并且馈送至比特解复用器块中。继续这些操作装置列结束。

在星座映射之前在组中逐比特地将各个比特交织组解复用。根据调制阶数，存在两个映射规则。在BPSK和QPSK的情况下，符号中的比特的可靠性相等。因此，从比特交织块读出的比特组在没有任何操作的情况下被映射至QAM符号。

在被映射至QAM符号的QAM-16和NUQ-64的情况下，操作规则描述于图23的(a)中。如图23的(a)所示，i是与比特交织中的列索引对应的比特组索引。

图21示出QAM-16的比特解复用规则。此操作继续，直至从比特交织块读取了所有比特组。

图22示出根据本发明的实施例的用于未来广播服务的广播信号接收设备的配置。

根据本发明的实施例的用于未来广播服务的广播信号接收设备可对应于参考图18描述的用于未来广播服务的广播信号发送设备。

根据本发明的实施例的用于未来广播服务的广播信号接收设备可包括同步和解调模块9000、帧解析模块9010、解映射和解码模块9020、输出处理器9030和信令解码模块9040。将描述广播信号接收设备的各个模块的操作。

同步和解调模块9000可通过m个接收天线接收输入信号，针对与广播信号接收设备对应的系统执行信号检测和同步，并且执行与广播信号发送设备所执行的过程的逆过程对应的解调。

帧解析模块9010可解析输入信号帧并且提取发送用户所选择的服务的数据。如果广播信号发送设备执行交织，则帧解析模块9010可执行与交织的逆过程对应的解交织。在这种情况下，可通过将从信令解码模块9040输出的数据解码以恢复由广播信号发送设备生成的调度信息，来获得需要提取的信号和数据的位置。

解映射和解码模块9020可将输入信号转换为比特域数据，然后根据需要将其解交织。解映射和解码模块9020可执行为了传输效率而应用的映射的解映射，并且通过解码来纠正在传输信道上生成的错误。在这种情况下，解映射和解码模块9020可通过将从信令解码模块9040输出的数据解码来获得解映射和解码所需的传输参数。

输出处理器9030可执行由广播信号发送设备应用以改进传输效率的各种压缩/信号处理过程的逆过程。在这种情况下，输出处理器9030可从信令解码模块9400所输出的数据获取必要控制信息。输出处理器9030的输出对应于输入至广播信号发送设备的信号，并且可以是MPEG-TS、IP流(v4或v6)和通用流。

信令解码模块9400可从由同步和解调模块9000解调的信号获得PLS信息。如上所述，帧解析模块9010、解映射和解码模块9020和输出处理器9030可利用从信令解码模块9040输出的数据来执行其功能。

根据本发明的实施例的帧被进一步划分成多个OFDM符号和前导码。如(d)所示，帧包括前导码、一个或更多个帧信令符号(FSS)、正常数据符号和帧边缘符号(FES)。

前导码是允许快速Futurecast UTB系统信号检测的特殊符号并且提供用于信号的有效发送和接收的基本传输参数的集合。前导码的细节将稍后描述。

FSS的主要目的是承载PLS数据。为了快速同步和信道估计进而PLS数据的快速解码，FSS具有比正常数据符号密集的导频图案。FES具有与FSS完全相同的导频，这允许FES内的仅频率插值以及紧靠FES之前的符号的时间插值(无外插)。

图23示出根据本发明的实施例的帧的信令层次结构。

图23示出信令层次结构，其被切分成与前导码信令数据11000、PLS1数据11010和PLS2数据11020对应的三个主要部分。每一个帧中的前导码符号所承载的前导码的目的是指示该帧的传输类型和基本传输参数。PLS1使得接收机能够访问并解码PLS2数据，该PLS2数据包含用于访问所关注的DP的参数。PLS2被承载于每一个帧中并且被切分成与PLS2-STAT数据和PLS2-DYN数据对应的两个主要部分。如果需要，PLS2数据的静态部分和动态部分之后是填充。

根据本发明的实施例的前导码信令数据承载使得接收机能够访问PLS数据并且跟踪帧结构内的DP所需的21比特的信息。前导码信令数据的细节如下。

FFT_SIZE：此2比特字段指示帧组内的当前帧的FFT大小，如下表1中所述。

[表1]

GI_FRACTION：此3比特字段指示当前超帧中的保护间隔分数值，如下表2中所述。

[表2]

EAC_FLAG：此1比特字段指示当前帧中是否提供EAC。如果此字段被设定为“1”，则当前帧中提供紧急报警服务(EAS)。如果此字段被设定为“0”，则当前帧中没有承载EAS。此字段可在超帧内动态地切换。

PILOT_MODE：此1比特字段指示对于当前帧组中的当前帧，导频模式是移动模式还是固定模式。如果此字段被设定为“0”，则使用移动导频模式。如果该字段被设定为“1”，则使用固定导频模式。

PAPR_FLAG：此1比特字段指示对于当前帧组中的当前帧，是否使用PAPR降低。如果此字段被设定为值“1”，则音预留用于PAPR降低。如果此字段被设定为值“0”，则不使用PAPR降低。

预留：此7比特字段被预留以用于未来使用。

图24示出根据本发明的实施例的PLS1数据。

PLS1数据提供包括允许PLS2的接收和解码所需的参数的基本传输参数。如上所述，对于一个帧组的整个持续时间，PLS1数据保持不变。PLS1数据的信令字段的详细定义如下。

PREAMBLE_DATA：此20比特字段是除了EAC_FLAG以外的前导码信令数据的副本。

NUM_FRAME_FRU：此2比特字段指示每FRU的帧数。

PAYLOAD_TYPE：此3比特字段指示帧组中承载的有效载荷数据的格式。PAYLOAD_TYPE如表3中所示来用信号通知。

[表3]

NUM_FSS：此2比特字段指示当前帧中的FSS的数量。

SYSTEM_VERSION：此8比特字段指示所发送的信号格式的版本。SYSTEM_VERSION被划分成两个4比特字段：主版本和次版本。

主版本：与SYSTEM_VERSION字段的四个比特对应的MSB指示主版本信息。主版本字段的改变指示不可后向兼容的改变。默认值为“0000”。对于此标准中所描述的版本，该值被设定为“0000”。

次版本：与SYSTEM_VERSION字段的四个比特对应的LSB指示次版本信息。次版本字段的改变可后向兼容。

CELL_ID：这是唯一地标识ATSC网络中的地理小区的16比特字段。根据每Futurecast UTB系统所使用的频率的数量，ATSC小区覆盖区域可包括一个或更多个频率。如果CELL_ID的值未知或未指定，则此字段被设定为“0”。

NETWORK_ID：这是唯一地标识当前ATSC网络的16比特字段。

SYSTEM_ID：此16比特字段唯一地标识ATSC网络内的Futurecast UTB系统。Futurecast UTB系统是地面广播系统，其输入是一个或更多个输入流(TS、IP、GS)，其输出是RF信号。Futurecast UTB系统承载一个或更多个PHY简档和FEF(如果有的话)。相同的Futurecast UTB系统在不同的地理区域中可承载不同的输入流并且使用不同的RF，从而允许本地服务插入。在一个地方控制帧结构和调度，并且对于Futurecast UTB系统内的所有传输均为相同的。一个或更多个Futurecast UTB系统可具有相同的SYSTEM_ID，这意味着它们全部具有相同的物理层结构和配置。

下面的循环包括用于指示各个帧类型的FRU配置和长度的FRU_PHY_PROFILE、FRU_FRAME_LENGTH、FRU_GI_FRACTION和RESERVED。循环大小是固定的，从而在FRU内用信号通知四个PHY简档(包括FEF)。如果NUM_FRAME_FRU小于4，则利用零填充未用字段。

FRU_PHY_PROFILE：此3比特字段指示所关联的FRU的第(i+1)(i是循环索引)帧的PHY简档类型。此字段使用如表8所示的相同信令格式。

FRU_FRAME_LENGTH：此2比特字段指示所关联的FRU的第(i+1)帧的长度。将FRU_FRAME_LENGTH与FRU_GI_FRACTION一起使用，可获得帧持续时间的准确值。

FRU_GI_FRACTION：此3比特字段指示所关联的FRU的第(i+1)帧的保护间隔分数值。根据表7来用信号通知FRU_GI_FRACTION。

RESERVED：此4比特字段被预留用于未来使用。

以下字段提供用于将PLS2数据解码的参数。

PLS2_FEC_TYPE：此2比特字段指示由PLS2保护使用的FEC类型。根据表4来用信号通知FEC类型。LDPC码的细节将稍后描述。

[表4]

PLS2_MOD：此3比特字段指示PLS2所使用的调制类型。根据表5来用信号通知调制类型。

[表5]

PLS2_SIZE_CELL：此15比特字段指示C

PLS2_STAT_SIZE_BIT：此14比特字段指示当前帧组的PLS2-STAT的大小(比特)。该值在当前帧组的整个持续时间期间恒定。

PLS2_DYN_SIZE_BIT：此14比特字段指示当前帧组的PLS2-DYN的大小(比特)。该值在当前帧组的整个持续时间期间恒定。

PLS2_REP_FLAG：此1比特标志指示当前帧组中是否使用PLS2重复模式。当该字段被设定为值“1”时，PLS2重复模式被激活。当该字段被设定为值“0”时，PLS2重复模式被去激活。

PLS2_REP_SIZE_CELL：此15比特字段指示C

PLS2_NEXT_FEC_TYPE：此2比特字段指示用于下一帧组的每一个帧中承载的PLS2的FEC类型。根据表10来用信号通知FEC类型。

PLS2_NEXT_MOD：此3比特字段指示用于下一帧组的每一个帧中承载的PLS2的调制类型。根据表11来用信号通知调制类型。

PLS2_NEXT_REP_FLAG：此1比特标志指示下一帧组中是否使用PLS2重复模式。当此字段被设定为值“1”时，PLS2重复模式被激活。当此字段被设定为值“0”时，PLS2重复模式被去激活。

PLS2_NEXT_REP_SIZE_CELL：此15比特字段指示C

PLS2_NEXT_REP_STAT_SIZE_BIT：此14比特字段指示下一帧组的PLS2-STAT的大小(比特)。该值在当前帧组中恒定。

PLS2_NEXT_REP_DYN_SIZE_BIT：此14比特字段指示下一帧组的PLS2-DYN的大小(比特)。该值在当前帧组中恒定

PLS2_AP_MODE：此2比特字段指示当前帧组中是否为PLS2提供附加奇偶校验。该值在当前帧组的整个持续时间期间恒定。下表6提供该字段的值。当该字段被设定为值“00”时，在当前帧组中PLS2不使用附加奇偶校验。

[表6]

PLS2_AP_SIZE_CELL：此15比特字段指示PLS2的附加奇偶校验比特的大小(被指定为QAM信元的数量)。该值在当前帧组的整个持续时间期间恒定。

PLS2_NEXT_AP_MODE：此2比特字段指示在下一帧组的每一个帧中是否为PLS2信令提供附加奇偶校验。该值在当前帧组的整个持续时间期间恒定。表12定义了该字段的值。

PLS2_NEXT_AP_SIZE_CELL：此15比特字段指示下一帧组的每一个帧中的PLS2的附加奇偶校验比特的大小(被指定为QAM信元的数量)。该值在当前帧组的整个持续时间期间恒定。

RESERVED：此32比特字段被预留以用于未来使用。

CRC_32：32比特纠错码，其被应用于所有PLS1信令。

图25示出根据本发明的实施例的PLS2数据。

图25示出PLS2数据的PLS2-STAT数据。PLS2-STAT数据在帧组内相同，而PLS2-DYN数据提供当前帧特定的信息。

下面描述PLS2-STAT数据的字段的细节。

FIC_FLAG：此1比特字段指示当前帧组中是否使用FIC。如果此字段被设定为“1”，则在当前帧中提供FIC。如果此字段被设定为“0”，则当前帧中没有承载FIC。该值在当前帧组的整个持续时间期间恒定。

AUX_FLAG：此1比特字段指示当前帧组中是否使用辅助流。如果此字段被设定为“1”，则当前帧中提供辅助流。如果此字段被设定为“0”，则当前帧中没有承载辅助流。该值在当前帧组的整个持续时间期间恒定。

NUM_DP：此6比特字段指示当前帧内承载的DP的数量。此字段的值的范围从1至64，DP的数量为NUM_DP+1。

DP_ID：此6比特字段唯一地标识PHY简档内的DP。

DP_TYPE：此3比特字段指示DP的类型。这根据下表7来用信号通知。

[表7]

DP_GROUP_ID：此8比特字段标识当前DP所关联的DP组。这可由接收机用来访问与具有相同的DP_GROUP_ID的特定服务关联的服务组件的DP。

BASE_DP_ID：此6比特字段指示承载管理层中所使用的服务信令数据(例如PSI/SI)的DP。由BASE_DP_ID指示的DP可以是承载服务信令数据以及服务数据的正常DP或者仅承载服务信令数据的专用DP。

DP_FEC_TYPE：此2比特字段指示关联的DP所使用的FEC类型。根据下表8来用信号通知FEC类型。

[表8]

DP_COD：此4比特字段指示关联的DP所使用的码率。根据下表9来用信号通知码率。

[表9]

DP_MOD：此4比特字段指示关联的DP所使用的调制。根据下表10来用信号通知调制。

[表10]

DP_SSD_FLAG：此1比特字段指示关联的DP中是否使用SSD模式。如果此字段被设定为值“1”，则使用SSD。如果此字段被设定为值“0”，则不使用SSD。

仅当PHY_PROFILE等于“010”(指示高级简档)时以下字段才出现：

DP_MIMO：此3比特字段指示哪一种类型的MIMO编码处理被应用于所关联的DP。MIMO编码处理的类型根据下表11来用信号通知。

[表11]

DP_TI_TYPE：此1比特字段指示时间交织的类型。值“0”指示一个TI组对应于一个帧并且包含一个或更多个TI块。值“1”指示一个TI组被承载于不止一个帧中并且仅包含一个TI块。

DP_TI_LENGTH：此2比特字段(允许值仅为1、2、4和8)的使用由DP_TI_TYPE字段内设定的值如下确定。

如果DP_TI_TYPE被设定为值“1”，则此字段指示P

如果DP_TI_TYPE被设定为值“0”，则此字段指示每TI组的TI块的数量N

[表12]

DP_FRAME_INTERVAL：此2比特字段指示所关联的DP的帧组内的帧间隔(I

DP_TI_BYPASS：此1比特字段确时序间交织器5050的可用性。如果时间交织未用于DP，则此字段的值被设定为“1”。如果使用时间交织，则该值被设定为“0”。

DP_FIRST_FRAME_IDX：此5比特字段指示超帧中的当前DP出现的第一帧的索引。DP_FIRST_FRAME_IDX的值从0到31。

DP_NUM_BLOCK_MAX：此10比特字段指示此DP的DP_NUM_BLOCKS的最大值。此字段的值具有与DP_NUM_BLOCKS相同的范围。

DP_PAYLOAD_TYPE：此2比特字段指示给定DP所承载的有效载荷数据的类型。DP_PAYLOAD_TYPE根据下表13来用信号通知。

[表13]

DP_INBAND_MODE：此2比特字段指示当前DP是否承载带内信令信息。带内信令类型根据下表14来用信号通知。

[表14]

DP_PROTOCOL_TYPE：此2比特字段指示给定DP所承载的有效载荷的协议类型。当选择输入有效载荷类型时，协议类型根据下表15来用信号通知。

[表15]

DP_CRC_MODE：此2比特字段指示输入格式化块中是否使用CRC编码。CRC模式根据下表16来用信号通知。

[表16]

DNP_MODE：此2比特字段指示当DP_PAYLOAD_TYPE被设定为TS(“00”)时关联的DP所使用的空分组删除模式。DNP_MODE根据下表17来用信号通知。如果DP_PAYLOAD_TYPE不是TS(“00”)，则DNP_MODE被设定为值“00”。

[表17]

ISSY_MODE：此2比特字段指示当DP_PAYLOAD_TYPE被设定为TS(“00”)时关联的DP所使用的ISSY模式。ISSY_MODE根据下表18来用信号通知。如果DP_PAYLOAD_TYPE不是TS(“00”)，则ISSY_MODE被设定为值“00”。

[表18]

HC_MODE_TS：此2比特字段指示当DP_PAYLOAD_TYPE被设定为TS(“00”)时关联的DP所使用的TS头压缩模式。HC_MODE_TS根据下表19来用信号通知。

[表19]

HC_MODE_IP：此2比特字段指示当DP_PAYLOAD_TYPE被设定为IP(“01”)时的IP头压缩模式。HC_MODE_IP根据下表20来用信号通知。

[表20]

PID：此13比特字段指示当DP_PAYLOAD_TYPE被设定为TS(“00”)并且HC_MODE_TS被设定为“01”或“10”时的TS头压缩的PID号。

RESERVED：此8比特字段被预留以用于未来使用。

仅当FIC_FLAG等于“1”时以下字段才出现。

FIC_VERSION：此8比特字段指示FIC的版本号。

FIC_LENGTH_BYTE：此13比特字段指示FIC的长度(字节)。

RESERVED：此8比特字段被预留以用于未来使用。

仅当AUX_FLAG等于“1”时以下字段才出现。

NUM_AUX：此4比特字段指示辅助流的数量。零表示没有使用辅助流。

AUX_CONFIG_RFU：此8比特字段被预留以用于未来使用。

AUX_STREAM_TYPE：此4比特被预留以用于未来用于指示当前辅助流的类型。

AUX_PRIVATE_CONFIG：此28比特字段被预留以用于未来用于用信号通知辅助流。

图26示出根据本发明的另一实施例的PLS2数据。

图26示出PLS2数据的PLS2-DYN数据。PLS2-DYN数据的值可在一个帧组的持续时间期间改变，而字段的大小保持恒定。

PLS2-DYN数据的字段的细节如下。

FRAME_INDEX：此5比特字段指示超帧内的当前帧的帧索引。超帧的第一帧的索引被设定为“0”。

PLS_CHANGE_COUNTER：此4比特字段指示配置改变之前的超帧的数量。配置改变的下一超帧由此字段内用信号通知的值指示。如果此字段被设定为值“0000”，则它表示预见没有调度的改变。例如，值“1”指示下一超帧存在改变。

FIC_CHANGE_COUNTER：此4比特字段指示配置(即，FIC的内容)改变之前的超帧的数量。配置改变的下一超帧由此字段内用信号通知的值指示。如果此字段被设定为值“0000”，则它表示预见没有调度的改变。例如，值“0001”指示下一超帧存在改变。

RESERVED：此16比特字段被预留以用于未来使用。

以下字段出现在NUM_DP上的循环中，描述与当前帧中承载的DP关联的参数。

DP_ID：此6比特字段唯一地指示PHY简档内的DP。

DP_START：此15比特(或13比特)字段利用DPU寻址方案指示第一DP的起始位置。DP_START字段根据PHY简档和FFT大小而具有不同的长度，如下表21所示。

[表21]

DP_NUM_BLOCK：此10比特字段指示当前DP的当前TI组中的FEC块的数量。DP_NUM_BLOCK的值从0至1023。

RESERVED：此8比特字段被预留以用于未来使用。

以下字段指示与EAC关联的FIC参数。

EAC_FLAG：此1比特字段指示当前帧中的EAC的存在。此比特是与前导码中的EAC_FLAG相同的值。

EAS_WAKE_UP_VERSION_NUM：此8比特字段指示唤醒指示的版本号。

如果EAC_FLAG字段等于“1”，则随后的12比特被分配给EAC_LENGTH_BYTE。

如果EAC_FLAG字段等于“0”，则随后的12比特被分配给EAC_COUNTER。

EAC_LENGTH_BYTE：此12比特字段指示EAC的长度(字节)。

EAC_COUNTER：此12比特字段指示在EAC到达的帧前面的帧的数量。

仅当AUX_FLAG字段等于“1”时以下字段才出现。

AUX_PRIVATE_DYN：此48比特字段被预留以用于未来用于用信号通知辅助流。此字段的含义取决于可配置的PLS2-STAT中的AUX_STREAM_TYPE的值。

CRC_32：32比特纠错码，其被应用于整个PLS2。

图27示出根据本发明的实施例的帧的逻辑结构。

如上所述，PLS、EAC、FIC、DP、辅助流和哑信元被映射至帧中的OFDM符号的有效载波。PLS1和PLS2被首先映射至一个或更多个FSS。此后，EAC信元(如果有的话)被映射至紧随PLS字段之后，随后是FIC信元(如果有的话)。接下来DP被映射至PLS之后或者EAC或FIC(如果有的话)之后。首先映射类型1DP，接下来映射类型2DP。DP的类型的细节将稍后描述。在一些情况下，DP可承载EAS的一些特殊数据或者服务信令数据。辅助流(如果有的话)跟随在DP之后，然后跟随着哑信元。当按照上述顺序(即，PLS、EAC、FIC、DP、辅助流和哑数据信元)将PLS、EAC、FIC、DP、辅助流和哑数据信元全部一起映射时，准确地填充了帧中的信元容量。

图28示出根据本发明的实施例的PLS映射。

PLS信元被映射至FSS的有效载波。根据PLS所占据的信元的数量，一个或更多个符号被指定为FSS，并且由PLS1中的NUM_FSS来用信号通知FSS的数量N

PLS信元按照上下方式被映射至FSS的有效载波，如图所示。PLS1信元首先从第一FSS的第一信元开始按照信元索引的增序映射。PLS2信元紧随PLS1的最后信元之后，并且向下继续映射直至第一FSS的最后信元索引。如果所需的PLS信元的总数超过一个FSS的有效载波的数量，则映射进行至下一FSS并且按照与第一FSS完全相同的方式继续。

在PLS映射完成之后，接下来承载DP。如果当前帧中存在EAC、FIC或这二者，则EAC和FIC被设置在PLS与“正常”DP之间。

以下将描述根据本发明的实施例对FEC结构进行编码。如上所述，数据FEC编码器可利用外编译(BCH)和内编译(LDPC)对输入的BBF执行FEC编码以生成FECBLOCK过程。所示的FEC结构对应于FECBLOCK。另外，FECBLOCK和FEC结构具有与LDPC码字的长度对应的相同值。

如上所述，对各个BBF应用BCH编码(K

N

下表22和表23分别示出长FECBLOCK和短FECBLOCK的FEC编码参数。

[表22]

[表23]

BCH编码和LDPC编码的操作的细节如下。

12纠错BCH码用于BBF的外编码。通过将所有多项式一起相乘来获得短FECBLOCK和长FECBLOCK的BCH生成多项式。

LDPC码用于对外BCH编码的输出进行编码。为了生成完成的B

[式2]

长FECBLOCK和短FECBLOCK的参数分别在上表22和23中给出。

计算长FECBLOCK的N

1)将奇偶校验比特初始化

[式3]

2)在奇偶校验矩阵的地址的第一行中指定的奇偶校验比特地址处累加第一信息比特-i

[式4]

3)对于接下来的359个信息比特i

[式5]

{x+(s mod 360)×Q

这里，x表示与第一比特i

[式6]

4)对于第361信息比特i

5)按照类似的方式，对于每一组的360个新信息比特，使用来自奇偶校验矩阵的地址的新的一行来寻找奇偶校验比特累加器的地址。

在所有信息比特被耗尽之后，获得最终奇偶校验比特如下。

6)从i＝1开始依次执行以下操作。

[式7]

这里，p

[表24]

短FECBLOCK的此LDPC编码过程依据长FECBLOCK的t LDPC编码过程，不同的是用表25代替表24，用短FECBLOCK的奇偶校验矩阵的地址代替长FECBLOCK的奇偶校验矩阵的地址。

[表25]

图29示出根据本发明的实施例的时间交织。

(a)至(c)示出TI模式的示例。

时间交织器在DP层面操作。可针对各个DP不同地设时序间交织(TI)的参数。

出现在PLS2-STAT数据的部分中的以下参数配置TI。

DP_TI_TYPE(允许值：0或1)：此参数表示TI模式。值“0”指示每TI组具有多个TI块(不止一个TI块)的模式。在这种情况下，一个TI组被直接映射至一个帧(没有帧间交织)。值“1”指示每TI组仅具有一个TI块的模式。在这种情况下，TI块可被散布在不止一个帧上(帧间交织)。

DP_TI_LENGTH：如果DP_TI_TYPE＝“0”，则此参数是每TI组的TI块的数量N

DP_NUM_BLOCK_MAX(允许值：0至1023)：此参数表示每TI组的XFECBLOCK的最大数量。

DP_FRAME_INTERVAL(允许值：1、2、4和8)：此参数表示承载给定PHY简档的相同DP的两个连续帧之间的帧的数量I

DP_TI_BYPASS(允许值：0或1)：如果对于DP未使用时间交织，则此参数被设定为“1”。如果使用时间交织，则此参数被设定为“0”。

另外，来自PLS2-DYN数据的参数DP_NUM_BLOCK用于表示由DP的一个TI组承载的XFECBLOCK的数量。

当对于DP未使用时间交织时，不考虑随后的TI组、时间交织操作和TI模式。然而，仍可能需要用于来自调度器的动态配置信息的延迟补偿块。在各个DP中，从SSD/MIMO编码接收的XFECBLOCK被组成TI组。即，各个TI组是整数个XFECBLOCK的集合，并且包含数量可动态变化的XFECBLOCK。索引n的TI组中的XFECBLOCK的数量由N

各个TI组被直接映射至一个帧或者被散布在P

[表26]

通常，时间交织器还可在帧创建的处理之前用作DP数据的缓冲器。这通过用于各个DP的两个存储库来实现。第一TI块被写入第一库。第二TI块被写入第二库，而从第一库读取，等等。

TI是扭曲行-列块交织器。对于第n TI组的第s TI块，TI存储器的行数N

图30示出根据本发明的实施例的扭曲行-列块交织器的基本操作。

图30的(a)示出时间交织器中的写入操作，图30的(b)示出时间交织器中的读取操作。如(a)所示，第一XFECBLOCK按照列方向被写入TI存储器的第一列中，第二XFECBLOCK被写入下一列中，依此类推。然后，在交织阵列中，在对角线方向上读出信元。如(b)所示，在从第一行(从最左列开始沿着行向右)到最后行对角线方向读取期间，读出N

[式8]

GENERATE(R

{

R

T

}

这里，S

[式9]

对于

结果，要读取的信元位置通过坐标z

图31示出根据本发明的另一实施例的扭曲行-列块交织器的操作。

更具体地讲，图31示出当N

可变数量N

[式10]

TI组的数量被设定为3。在PLS2-STAT数据中通过DP_TI_TYPE＝“0”、DP_FRAME_INTERVAL＝“1”和DP_TI_LENGTH＝“1”(即，N

在与单个OFDM符号对应的数据上操作的频率交织器的目的是通过随机地交织从帧构建器接收的数据信元来提供频率分集。为了在单个帧中得到最大交织增益，针对由两个连续的OFDM符号组成的每一个OFDM符号对使用不同的交织序列。

因此，根据本实施例的频率交织器可包括用于生成交织地址以将对应数据应用于符号对的交织地址生成器。

图32示出根据本发明的实施例的包括根据各个FFT模式的主伪随机二进制序列(PRBS)生成器和次PRBS生成器的交织地址生成器。

(a)示出用于8K FFT模式的交织地址生成器的框图，(b)示出用于16K FFT模式的交织地址生成器的框图，(c)示出用于32K FFT模式的交织地址生成器的框图。

用于OFDM符号对的交织处理利用单个交织序列被描述如下。首先，对于l＝0，...，N

对于OFDM符号对，交织的OFDM符号对由

图33示出根据本发明的实施例的用于所有FFT模式的主PRBS。

(a)示出主PRBS，(b)示出各个FFT模式的参数Nmax。

图34示出根据本发明的实施例的用于FFT模式的次PRBS以及用于频率交织的交织地址。

(a)示出次PRBS生成器，(b)示出用于频率交织的交织地址。根据本发明的实施例的循环移位值可被称作符号偏移。

图35示出根据本发明的实施例的时间交织器的写入操作。

图35示出针对两个TI组的写入操作。

图中左边的方框示出TI存储器地址阵列，图中右边的方框示出当虚拟FEC块和一个虚拟FEC块被分别插入两个邻接的TI组的报头中时的写入操作。

以下将描述时间交织器的配置以及使用卷积交织器(CI)和块交织器(BI)二者或者根据物理层管道(PLP)模式选择性地使用CI或BI的时间交织方法。根据本发明的实施例的PLP是与上述DP相同的概念对应的物理路径，PLP的名称可由设计者来改变。

根据本发明的实施例的PLP模式可根据由广播信号发送机或广播信号发送设备处理的PLP的数量而包括单PLP模式或多PLP模式。单PLP模式对应于广播信号发送设备处理一个PLP的情况。单PLP模式可被称作单个PLP。

多PLP模式对应于广播信号发送设备处理一个或更多个PLP的情况。多PLP模式可被称作多个PLP。

在本发明中，根据PLP模式应用不同的时间交织方案的时间交织可被称作混合时间交织。在多PLP模式中针对各个PLP(或者在各个PLP层面)应用根据本发明的实施例的混合时间交织。

图36示出根据表中的PLP的数量应用的交织类型。

在根据本发明的实施例的时间交织中，可基于PLP_NUM的值来确定交织类型。PLP_NUM是指示PLP模式的信令字段。当PLP_NUM具有值1时，PLP模式对应于单个PLP。根据本实施例的单个PLP可仅应用于CI。

当PLP_NUM具有大于1的值时，PLP模式对应于多个PLP。根据本实施例的多个PLP可被应用于CI和BI。在这种情况下，CI可执行帧间交织，BI可执行帧内交织。

图37是包括上述混合时间交织器的结构的第一示例的框图。

根据第一示例的混合时间交织器可包括BI和CI。本发明的时间交织器可位于BICM链块与帧构建器之间。

除了时间交织器5050以外，图37和图38所示的BICM链块可包括图19所示的BICM块的处理块5000中的块。图37和图38所示的帧构建器可执行与图18的帧构建块1020相同的功能。

如上文所述，可根据PLP_NUM的值确定是否根据混合时间交织器的结构的第一示例应用BI。即，当PLP_NUM＝1时，不应用BI(BI被关闭)并且仅应用CI。当PLP_NUM>1时，可应用BI和CI二者(BI被打开)。当PLP_NUM>1时应用的CI的结构和操作可与当PLP_NUM＝1时应用的CI的结构和操作相同或相似。

图38是包括上述混合时间交织器的结构的第二示例的框图。

混合时间交织器的结构的第二示例中所包括的各个块的操作与图37中的以上描述相同。可根据PLP_NUM的值确定是否根据混合时间交织器的结构的第二示例应用BI。根据第二示例的混合时间交织器的各个块可根据本发明的实施例执行操作。在这种情况下，在PLP_NUM＝1的情况和PLP_NUM>1的情况之间，所应用的CI的结构和操作可不同。

图39是包括混合时间解交织器的结构的第一示例的框图。

根据第一示例的混合时间解交织器可执行与根据上述第一示例的混合时间交织器的逆操作对应的操作。因此，根据图39的第一示例的混合时间解交织器可包括卷积解交织器(CDI)和块解交织器(BDI)。

当PLP_NUM>1时应用的CDI的结构和操作可与当PLP_NUM＝1时应用的CDI的结构和操作相同或相似。

可根据PLP_NUM的值确定是否根据混合时间解交织器的结构的第一示例应用BDI。即，当PLP_NUM＝1时，不应用BDI(BDI被关闭)并且仅应用CDI。

混合时间解交织器的CDI可执行帧间解交织，BDEI可执行帧内解交织。帧间解交织和帧内解交织的细节与上面的描述相同。

图39和图40所示的BICM解码块可执行图37和图38的BICM链块的逆操作。

图40是包括混合时间解交织器的结构的第二示例的框图。

根据第二示例的混合时间解交织器可执行与根据上述第二示例的混合时间交织器的逆操作对应的操作。混合时间解交织器的结构的第二示例中所包括的各个块的操作可与上面图39中的描述相同。

可根据PLP_NUM的值确定是否根据混合时间解交织器的结构的第二示例应用BDI。根据第二示例的混合时间解交织器的各个块可根据本发明的实施例执行操作。在这种情况下，在PLP_NUM＝1的情况和PLP_NUM>1的情况之间，所应用的CDI的结构和操作可不同。

图41图示出根据本发明的实施例的应用相关广播服务。

本发明提出了上述广播服务之中的与应用有关的广播服务中的信令方案和同步方案。在这里，应用相关的广播服务可指代对应于基本广播服务的提供与应用相关的情况的广播服务。具体地，其示例可包括线性服务，其包括基于应用的增强和/或独立的基于应用的服务。根据给定实施例，可将本发明的信令方案应用于使用应用的另一服务形式。

首先，将给出包括基于应用的增强的线性服务的描述。在这里，线性服务可指代一般广播服务。增强可指代增强服务或交互式服务，其递送用于一般广播服务的附加信息。另外，基于应用的增强可指代其中基于应用来提供和/或控制上述附加信息的情况。

例如，其中当在广播足球比赛(一般广播服务服务)时球员信息应用提供关于所有足球球员的信息的情况(基于应用的增强)可对应于包括基于应用的增强的线性服务。

将描述独立的基于应用的服务。独立的基于应用的服务可指代仅包括基于应用的增强的广播服务。换言之，其中应用提供服务而不是基于应用的增强向基本广播服务提供附加信息的情况可对应于独立的基于应用的服务。广播无关应用等可以是提供独立的基于应用的服务的应用的示例。

基于应用的增强可包括多个组件。基于应用的增强的组件可包括一个或多个应用、零个或更多激活通知、零个或更多非实时(NRT)内容项目和/或零个或更多点播项目。

在这里，每个应用可对应于可以在应用运行时环境中执行的NRT内容项目。在这里，将由应用执行的行为可由通过广播网络/宽带网络递送的通知发起，并且这些通知可对应于上述激活通知。这些通知可称为“事件”。在这里，附加NRT内容项目和/或点播项目可指代将被应用使用的数据。

根据给定实施例，可将包括在基于应用的增强中的应用中的一个设定为主应用。当主应用存在时，可在选择包括基于应用的增强的广播服务时执行主应用。可通过经由广播网络/宽带网络的信令来执行除主应用之外的应用。替换地，除主应用之外的应用可通过已被执行的其它应用执行。在这种情况下，除主应用之外的应用可被JavaScript的createApplication()执行。

如前文所述，本发明提出了一种用于各种类型的基于应用的增强的信令方案。另外，本发明提出了一种与时基同步地递送激活通知的方案。应用的行为可被同步激活通知同步。

在这里，应用可指代包括在增强/交互式服务中的一组文档(HTML、CSS、JavaScript等)。

在这里，内容项目可指代意图被服务提供商视为用于呈现的一个单元的一个或多个文件的集合。

在这里，事件可指代定时通知，其指示将在DASH客户端或应用中执行的行为。

在这里，事件流可指代上述事件流。

在这里，NRT内容项目可指代被提前递送以便在未来呈现或应用中另外使用的内容项目。

在这里，点播内容项目可指代在由用户请求的时间点下载并呈现的内容项目。

图42图示出根据本发明的实施例的ApplicationList元素的一部分

图43图示出根据本发明的实施例的ApplicationList元素的另一部分。

虽然两个图最初对应于一个图，但这一个图由于空间约束而被划分成两个图。

如前文所述，广播服务可包括零个或更多基于应用的增强。例如，线性服务可包括基于应用的增强，其具有在后台中执行以管理定向广告插入的一个应用。另外，线性服务还可包括基于应用的增强，其具有提供与音频/视频节目有关的交互式观看体验的一组应用。

在这里，可单独地用信号发送每个基于应用的增强。因此，制造各种应用的制造商可不在其信令中相互合作。

可用应用信令表(AST)来用信号发送包括在一个基于应用的增强中的一组应用。AST是XML文档中的一个，并且可包括ApplicationList元素作为根元素。一个AST可包括在一个基于应用的增强中包括的应用的信令信息。根据给定实施例，可将一个AST扩展以用信号发送多个基于应用的增强。

一个服务的服务信令信息可包括用于包括在服务中的每个基于应用的增强中的AST。换言之，当一个服务包括多个基于应用的增强时，服务的服务信令信息可包括多个AST。

将描述图中所示的AST的示例。根据给定实施例，可添加/省略/改变AST的每个元素/属性。

AST可包括ApplicationList元素作为根元素。ApplicationList元素可包括Application元素列表。亦即，ApplicationList元素可包括至少一个或更多Application元素。

每个Application元素可包括appName元素、applicationDescriptor元素、applicationSpecificDescriptor元素、applicationUsageDescriptor元素、applicationBoundary元素、applicationTransport元素、applicationLocation元素、atsc:Capabilities元素、atsc:liveEventSource元素、atsc:ContentItems元素、@applicationIdentifier属性、@atsc:serviceId属性和/或@atsc:protocolVersion属性。

appName元素可指示Application元素所指示的应用的名称。此元素可省略。可用各种语言来表示应用名。appName元素还可包括@lang属性。@lang属性可指示应用名称的语言。

applicationDescriptor元素可包括相应应用的信息。applicationDescriptor元素可包括一般地可以包括在所有应用中的信息。applicationDescriptor元素可包括图标元素、@type属性、@controlCode属性、@visibility属性、@serviceBound属性、@priority属性、@version属性、@mhpVersion属性、@storageCapabilities属性和/或@trickModeTolerance属性。

图标元素可指示可以用来表示相应应用的图标。此元素可省略。该图标元素可包括指示应用图像(图标)的MIME类型的@mimeType属性和/或使用像素来指示应用图像的宽度/高度/深度的@width/@height/@depth属性。该图标元素还可包括具有用于下载应用图像的HTTP URL信息的@url属性。

@type属性可指示相应应用的类型。例如，此属性可指示相应应用是根据ATSC或DVB的应用。

@controlCode属性可包括用于控制相应应用的状态的信息。例如，此属性可具有关于自动发起(autolaunch)、杀灭(kill)等的信息。可使用该信息来控制相应应用的状态。

@visibility属性可指示相应应用是否对用户和/或另一应用可见。在这里，在广义上，相应应用是否对用户和/或另一应用可见可指示相应应用是否出现在用户界面中。除相应应用是否可见之外，此属性还可指示相应应用是否可听或可感知。根据给定实施例，可通过单独地设定@audibility属性来指示相应应用是否通过扬声器对用户等可听见。此属性可被省略。

@serviceBound属性可指示相应应用是否是服务有界的。相应应用在其属性被设置成真时可以是服务有界的，并且当此属性被设置成假时可不是服务有界的。此属性可具有真值作为默认值。此属性可被省略。当此属性被省略时，其可意味着相应应用是服务有界的。

@priority属性可包括相应应用与其它应用相比时的相对优先级。@version属性可指示相应应用的版本。@mhpVersion属性可指示相应应用所需的平台或版本。此属性可被省略。

@storageCapabilities属性可指示缓存相应应用所需的存储量。此属性可被省略。根据给定实施例，此属性可用来指示相应应用是否可以被缓存。

@trickModeTolerance属性可指示相应应用是否与某个特效模式兼容。兼容性可指代相应应用是否可以在某个特效模式被执行时容忍该某个特效模式。该特效模式的示例可包括暂停、FF、缓慢模式、后退等。此属性可被省略。在具有应用增强的广播服务中，当用户针对广播服务执行特效播放时，可执行信号发送，使得经受特效播放的基本程序可以被正常地增强。

applicationSpecificDescriptor元素可具有仅用于某个类型的应用的所需信息，不同于上述applicationDescriptor元素。亦即，此元素的信息可受制于应用类型。此元素可根据应用类型而是不必要的，并且因此此元素可被省略。

applicationUsageDescriptor元素可指示相应应用的功能。例如，此元素可指示相应应用可以被用于图文电视(teletex)。此元素可根据应用类型而是不必要的。此元素可省略。

applicationBoundary元素可指示定义相应应用的应用边界的扩展的URL信息。此元素可省略。

applicationTransport元素可指示被用来递送相应应用的协议。例如，此元素可指示相应应用是通过ROUT、MMT或HTTP递送的。根据给定实施例，此元素可指示当递送AST时使用的协议。根据本发明的递送服务数据的上述方法，此元素的可允许值可对应于ROUTE、MMT、HTTP等。

applicationLocation元素可指示提供将可以获取相应应用的位置的URL。根据给定实施例，此元素可指示可以获取相应应用的URL。

atsc:Capabilities元素可指示用于有意义地处理相应应用/基于应用的增强的能力信息。在这里，用于有意义处理的能力可指代接收侧能够有意义地执行渲染/解码/再现等的能力。根据给定实施例，可用预置能力代码来指示能力信息。

atsc:liveEventSource元素可提供用于在实时情况下接收上述事件的信息。例如，在实时广播节目中，需要实时地改变并递送事件以便根据实时地改变的广播节目的内容来提供增强。不同于预先产生的内容，在实时情况下可能需要上述操作。此元素可提供用于在此情况下实时地接收事件的信息，诸如URL等。此元素可包括@url属性、@shortPollingPeriod属性和/或@targetDevice属性。

@url属性可指示用于在实时情况下接收事件的URL。@shortPollingPeriod属性可指示当在宽带网络的短轮询中获取事件时的轮询时段。@targetDevice属性可指示被实时事件确定为目标的装置。例如，主装置(PD)或配套装置(CD)可对应于目标装置。@shortPollingPeriod属性和/或@targetDevice属性可被省略。

atsc:ContentItems元素可包括关于将被相应应用使用的每个内容项目的信息。ContentItems元素的数目可对应于各内容项目的数目。atsc:ContentItems元素还可包括位置元素、@ContentLinkage属性、@updatesAvailable属性、@TFAvailable属性、@contentSecurityCondition属性、@availableInBroadcast属性、@availableOnInet属性、@playbackLengthInSeconds属性、@playbackDelay属性、@expiration属性、@size属性、@name属性和/或timeSlotInfo元素。

该位置元素可指示关于可以获取内容项目的位置的信息。此信息可根据给定实施例而具有一种URL。位置元素可被省略，或者可存在多个位置元素。

@ContentLinkage属性可指示其中将使用内容项目的应用。可使用此属性的值和关于下面将描述的事件的信息(EventStream元素、emsg盒等)来执行某个应用的信令。例如，此属性可提供用于某个应用的应用标识符或者指示其中将递送该应用的应用数据的某个LCT会话。

@updatesAvailable属性可指示内容项目是否可以被更新。此属性可具有真或假的值。@TFAvailable属性可指示在用于内容项目的信令信道上是否存在文本分段。

@contentSecurityCondition属性可指示内容项目的安全状态。@availableInBroadcast属性可指示是否可以通过广播网络获取内容项目。@availableOnInet属性可指示是否可以通过互联网协议网络来获取内容项目。

@playbackLengthInSeconds属性可指示当内容项目被再现时的内容项目的以秒为单位的长度。此属性可被省略。@playbackDelay属性可指示内容项目的再现延迟。此属性可被省略。@expiration属性可指示内容项目的到期时段。此属性可被省略。@size属性可指示内容项目的大小。此属性可被省略。@name属性可指示内容项目的名称。此属性可被省略。

timeSlotInfo元素可包括内容项目的时隙相关信息。timeSlotInfo元素还可包括@time_slot_start属性、@time_slot_length属性、@acquisition_time属性、@repeat_period属性和/或@slot_count属性。

@time_slot_start属性可指示时隙的开始时间。此时间可从1980年1月6日的00:00:00UTC开始以GPS秒为单位来表示。当此字段具有0的值时，此字段可指示该时隙从不确定的过去开始。

@time_slot_length属性可指示时隙的以分钟为单位的长度。

@acquisition_time属性可指示其中确保至少一个内容项目的传输的最小时间间隔长度。可以用分钟来表示此时间间隔。在这里，此时间间隔被假定为从时隙中的任意事件开始，并且可包括时隙的结尾。当在时隙期间重复发送一个大的内容项目时，此属性可对应于当发送内容项目的一个实例时花费的时间。当在传送带(carousel)中发送多个小的内容项目时，此属性可对应于传送带的循环时间。

@repeat_period属性可指示时隙的以分钟为单位的重复间隔。

@slot_count属性可指示时隙发生的次数。从起始于@time_slot_start属性所指示的时间的时隙开始指示该次数。当此属性具有0的值时，可假定重复将无限地继续。

Application元素可直接地包括@ContentLinkage属性和/或timeSlotInfo元素。亦即，可将@ContentLinkage属性和/或timeSlotInfo元素包括在Application元素和atsc:ContentItems元素两者中。

在Application元素的属性之中，@applicationIdentifier属性可指示应用的标识符。此值可以是全局唯一值。

@atsc:serviced属性可指示与相应应用相关的服务的服务标识符。

@atsc:protocolVersion属性可指示相应应用的协议版本。根据给定实施例，可将相应字段划分成包括主要协议版本和次要协议版本的两个字段。替换地，此字段可同时地提供主要/次要协议版本。

除所述多个Application元素之外，ApplicationList元素还可包括@ASTVersionNumber属性、@timeSpanStart属性和/或@timeSpanLength属性。

@ASTVersionNumber属性可指示整个相应AST的版本号。根据给定实施例，可将相应字段划分成包括主要协议版本和次要协议版本的两个字段。替换地，此字段可同时地提供主要/次要协议版本。

@timeSpanStart属性可指示被相应AST实例覆盖的时间间隔的开始。AST可被划分成多个实例并发送。每个AST实例可包括用于每个时间间隔的信令信息。

@timeSpanLength属性可指示被相应AST实例覆盖的时间间隔的长度。可以计算被相应AST实例覆盖的时间间隔以及@timeSpanStart属性的值。

根据上述实施例的AST的各字段可被省略或改变。另外，根据给定实施例，可向AST添加附加字段。可用具有相同/类似意义的字段来替换AST的各字段。

可通过广播网络和宽带网络来发送上述AST。

当通过广播网络来发送AST时，可通过应用增强与之相关的广播服务的服务信令信道来递送用于应用增强的AST。在这里，服务的服务信令信道可指代通过其递送上述SLS的路径。例如，在ROUTE中，由tsi＝0指定的LCT传输会话可将AST作为专用信令信道递送。在MMT中，由packet_id＝00指定的MMP分组流可将AST作为专用信令信道递送。

当通过宽带网络来递送AST时，可通过查询来获取AST。此查询可使用上述SLT中的URL信息来生成。基础URL可对应于用于获取AST的URL信息。在这里，SLT可对应于包括用于与AST有关的广播服务的引导信息的SLT。在使用水印的情形中，可通过水印或通过使用水印的自动内容识别(ACR)过程来获取基础URL。

图44图示出根据本发明的实施例的事件消息表(EMT)。

如前文所述，可用通过广播网络/宽带网络递送的通知来发起将由应用指定的行为。这些通知可称为“事件”。根据上下文，可将由通知发起的应用的操作、行为或被操作状态称为“事件”。另外，应用的可执行行为可称为“事件”。

这些事件可通过广播网络或宽带网络递送。在这种情况下，每个事件或由事件执行的行为可能需要与基本广播服务/广播节目同步。本发明提出了事件的递送方案和同步方案。

将给出通过广播网络来递送事件的情况的描述。

当通过广播网络来递送事件时，可将该事件作为DASH事件递送。在这种情况下，可以EventStream元素或emsg盒的形式递送事件。通过EventStream元素来递送事件的情况可对应于将事件作为在MPD的Period元素中出现的EventStream元素的形式递送的情况。将事件以emsg盒的形式递送的情况可对应于通过在表示段中出现的emsg盒来递送事件的情况。

两个事件递送机制可以是可互换的。例如，一个事件流可包括通过EventStream元素递送的多个事件和/或通过emsg盒递送的其它事件。

通过EventStream元素递送的事件可对应于将在对应于某个时段的时间间隔期间递送到接收侧的事件。换言之，MPD可以称为时段的服务的时间间隔提供信令信息作为某个服务的服务信令信息。用于该时段的信令信息被包括在MPD Period元素中，并且此Period元素可包括EventStream元素。EventStream元素可提供该服务时段期间的应用操作所需的信令(事件)。

EventStream元素可对应于Event元素列表。每个EventStream元素可具有schemeIdUri属性和/或值属性。这两个属性可指示EventStream中的事件的类型。根据给定实施例，这两个属性可识别事件。在这里，可使用预定义值作为schemeIdUri属性和/或值属性的值。替换地，服务提供可另外定义并使用schemeIdUri属性和/或值属性的值。schemeIdUri属性的“所有者”需要唯一地定义schemeIdUri属性，并且需要定义事件的值属性的语义。值信息可受制于应用并被用来识别一个服务中的某个事件流。

EventStream元素还可包括时标属性。此属性可指示持续时间和事件呈现时间中的参考时标。

EventStream元素的每个Event子元素可包括presentationTime属性、持续时间属性和/或id属性。presentationTime属性可指示每个事件的开始时间，持续时间属性可指示每个事件的持续时间，并且id属性可指示每个事件的标识符。在本文中，事件可指代由通知发起的应用的行为或由该行为引起的现象(弹出窗口等)。

Event子元素可不具有用于相应事件的数据。然而，根据给定实施例，Event元素可具有附加数据元素或属性。此数据元素/属性可提供执行由事件发起的行为所需的数据。

根据给定实施例，在一个时段中可存在具有不同类型的多个EventStream元素。

当以emsg盒的形式递送事件时，可如前文所述地通过在Representation片段中出现的emsg盒来递送事件。在这种情况下，MPD的Representation的InbandEventStream元素可用信号发送在各片段中的emsg盒中是否存在事件。

InbandEvent element可包括schemeIdUri和/或值。这两个字段可指示emsg盒中的事件的类型。根据给定实施例，这两个字段可用来识别事件。

InbandEvent元素还可包括时标字段。此字段可指示与事件有关的参考时标。

另外，InbandEvent元素还可包括presentation_time_delta信息、event_duration信息和/或id信息。presentation_time_delta信息可指示相应事件的开始时间。在这里，可用相对于Representation的开始时间的相对值来表示开始时间。event_duration信息可指示相应事件的持续时间。id信息可识别相应事件的实例。

InbandEvent元素还可以可选地包括message_data信息。message_data信息可提供执行由相应事件发起的行为所需的数据。

将给出通过宽带网络来递送事件的情况的描述。

已相对于通过广播网络的事件的递送来描述通过MPD的使用批量的批量递送和使用emsg盒的递增递送。同样地，可相对于通过宽带网络的事件的递送而提出批量递送和递增递送。

当通过宽带网络使用批量递送来递送事件时，可通过事件流表(EST)来递送事件。根据给定实施例，可将此EST称为EMT。作为XML文档，EST可包括EventStreamTable元素作为根元素。

EventStreamTable元素可对应于EventStream元素列表。每个EventStream元素可与通过上述广播网络进行的事件递送中的EventStream元素相同。EventStream元素的列表可包括用于一个服务的所有事件流。

根据本发明的另一实施例，所示EMT是EMT(EST)。EMT可包括@mpdId属性、@periodId属性以及EventStream元素。

@mpdId属性可对应于与EMT所描述的事件有关的MPD的标识符。MPD可被用作相应事件的时间参考。

@periodId属性可对应于与EMT的事件有关的MPD的时段的标识符。该时段可被用作相应事件的时间参考。

EventStream元素中的各字段如上所述。在这里，每个Event元素可根据@schemeIdURi和/或@value的值而具有适合于其类型的值。@presentationTime属性将是事件的开始时间指示为相对于时段的开始时间的相对值，并且此时段可对应于@mpdId和@periodId属性所识别的时段。

可如上所述地通过查询来获取EST。可用SLT中的基础URL信息来生成查询。上文已给出了其描述。

当使用通过宽带网络的递增递送来递送事件时，可通过实时事件服务器来单独地递送事件。可使用实时事件服务器周期性地执行轮询。当存在要在相应时段中发送的事件时，事件服务器可将事件递送到接收机。实时事件服务器的信息(诸如URL、轮询时段等)可能已被上述AST或EST或另一信令对象递送到接收机。

在这种情况下递送的事件可具有与使用emsg盒的事件的上述递送中的emsg盒的格式相同的格式。根据给定实施例，可将对应于上述InbandEvent元素的信令信息连同实时事件一起递送。

SchemeIdUri信息和值信息可对应于在用于事件流的流事件收听器的添加和删除的API中的targetURI和eventName宗量。根据上述各实施例的事件还可包括可选数据属性。该数据属性可提供被用来执行由相应事件发起的行为的数据。该数据属性可对应于当事件发生时被返回到已注册收听器的StreamEvent接口的数据属性。

在NRT内容项目的递送中，可使用ATSC的NRT递送方法。然而，在这种情况下，使用AST来代替NRT-IT，并且可识别将由AST递送的内容项目。另外，应用可发起NRT内容项目的宽带递送，即使当在AST中并未列出NRT内容项目时。

可通过宽带网络来递送点播内容项目。点播内容项目的宽带递送可由应用发起。

将描述应用的同步。

可能需要在多个方面使应用同步。例如，可能需要使应用的行为与预定音频/视频服务同步。另外，可能需要根据预定音频/视频服务来发起和中止应用。除基本广播服务之外，可能需要使应用和应用的行为与所记录内容、NRT内容等的再现同步。另外，可能需要根据记录内容、NRT内容等来发起或中止应用以有效地增强用户体验。

另外，可能需要使CD中的应用与在PD中再现的音频/视频内容同步，使得由CD提供的应用增强可以被有效地同步和提供。

将描述用户体验。

根据给定实施例，用户可控制应用的操作以实现高效的应用增强，因为该增强在操作不能被控制时可能妨碍观看。作为示例，可使用用户的许可。用户可共同地许可所有服务或某些特定服务。替换地，用户可逐个情况地许可各服务或多个服务的应用。

当用户逐个情况地给出许可时，可能需要首先在应用被激活之前显示应用通知。通过此通知，应用可从用户获得激活许可。该应用可处于被阻断状态直至获得许可为止。

用于此许可的通知的格式和位置可由设备制造商确定。用于许可的实际用户界面可由设备制造商确定。参考这些问题，可由某个实体从行业观点出发提出某个格式等。

用于许可的通知可超时或者被用户取消。这样，即使当用户并未立即确定是否要许可应用的激活时，也可防止用户连续地被此通知妨碍观看。即使当通知超时或者被取消且因此不可见时，用户可通过设置等来激活或阻断应用。用户可终止被激活的应用。在这种情况下，即使当接收到用于激活应用的信号时，该应用可连续地被阻断。

将给出行为的同步和行为参数的描述。

应用的下载、应用的激活、应用的终止和/或应用的某个行为可能需要与基本广播节目等同步。

相对于应用的行为，可能需要行为参数以执行行为。可使用参数的信息来执行行为。行为参数的示例可包括用于识别与行为有关的应用的应用标识符参数、指示将执行行为的时间的时间参数和/或与行为的同步层级有关的同步层级参数。在这里，时间参数可将行为的开始时间指示为相对于时基或媒体时线的相对值。在这里，同步层级参数可指示同步层级，诸如节目层级同步、小于两秒的同步、唇形同步、帧同步等。

关于与应用的下载有关的行为，此行为可包括与目标装置有关的行为参数和/或与抖动间隔有关的行为参数。与目标装置有关的行为参数可包括关于下载的应用是用于PC还是CD的信息。与抖动间隔有关的行为参数可包括与用于获取应用的抖动间隔有关的信息。

关于与应用的开始有关的行为，此行为可包括与目标装置有关的行为参数和/或与抖动间隔有关的行为参数。与目标装置有关的行为参数可包括关于开始的应用是用于PC还是CD的信息。

如前文所述，行为参数的示例可包括提供执行应用所需的数据的行为参数。此行为参数可包括执行相应行为所需的数据。

图45图示出根据本发明的实施例的由发送侧来提供广播服务的方法。

根据本实施例的由发送侧来提供广播服务的方法可包括生成服务数据和服务信令信息，生成服务列表，在传输分组中处理流组件、增强组件、服务信令信息和/或服务列表，生成链路层分组和/或在物理上处理链路层分组以生成并发送广播信号。

首先，发送侧的第一模式可生成广播服务的服务数据和用于用信号发送服务数据的服务信令信息。在这里，服务数据可包括具有与广播服务的实时内容有关的数据的流组件和/或具有实时内容的与基于应用的增强有关的数据的增强组件。

流组件可具有再现实时内容所需的数据。例如，流组件可对应于视频组件、音频组件或隐藏字幕组件。如在前文中所述，基于应用的增强可为广播服务提供交互式观看体验。如前文中所述，基于应用的增强可通过用于广播节目的应用等来提供交互式服务。增强组件可包括用于提供基于应用的增强的数据。增强组件可对应于应用，并且可对应于用于使用应用的数据/内容项目。在这里，增强组件可对应于NRT组件并被通过ROUTE协议等递送。

另外，服务还可包括多个服务组件。在这里，服务信令信息可指代上述SLS。

用于发送侧的第二模块可生成服务列表。该服务列表可对应于上述SLT。SLT可包括引导信息，其指示在其中递送SLS的传输会话。在这里，传输会话可对应于ROUTE会话或MMTP会话。引导信息可指的是ROUTE会话或MMTP会话的IP地址、UDP端口号等。第一模块和第二模块可对应于充当管理服务的生成的服务提供商的模块

发送侧的第三模块可在传输分组中处理流组件、增强组件、服务信令信息和/或服务列表。此步骤可对应于用于对服务组件数据、SLS和SLT进行UDP/IP处理并将服务组件数据、SLS以及SLT封装在IP分组中以便通过广播网络来递送服务数据的步骤。在这里，传输分组可对应于IP分组。在这里，假设FIC未被使用且SLT被封装在IP分组中并通过PLP递送。第三模块可对应于管理UDP/IP层的硬件模块。

发送侧的第四模块可对传输分组执行链路层处理以输出至少一个链路层分组。上文已描述了链路层处理。在这里，第四模块可对应于执行与链路层对应的操作的模块。第四模块可执行报头压缩/开销缩减或分组封装。

发送侧的第五模块可在物理上处理所述至少一个链路层分组。第五模块可对应于管理物理层的操作的模块。第五模块可从链路层分组生成BB分组，并对BB分组执行编码、比特交织、星座映射等。然后，可以执行时间交织、帧构建、频率交织等以及然后的根据OFDM方案的调制过程。另外，第五模块可发送包括经过物理处理的数据的广播信号。在这里，第四模块可被包括在第五模块中。第四和第五模块可被一个集成模块替换。第五模块可包括多个内部块。第四模块可被包括在第五模块的块中的一个中。

在根据本实施例的由发送侧来提供广播服务的方法中，服务信令信息可包括用信号通知提供基于应用的增强的应用的AST。上文已描述了AST。如前文中所述，可将AST连同用于广播服务的SLS一起递送。换言之，可通过在其中递送SLS的ROUTE/LCT会话来递送AST。根据给定实施例，可通过宽带网络等来递送AST。在这种情况下，可使用STL的URL信息来请求AST。

另外，在本实施例中，增强组件可对应于广播服务的NRT组件。如前文所述，增强组件可包括相对于用于广播服务的应用增强而言的相关应用或内容项目。

在根据本发明的另一实施例的由发送侧提供广播服务的方法中，服务信令信息可包括用户服务捆绑描述(USBD)、基于服务的传输会话实例描述(S-TSID)和/或接替呈现描述(MPD)。如前文所述，USBD可包括用于参考S-TSID的URI信息和/或用于参考MPD的URI信息。S-TSID可包括与在其中递送广播服务的流组件和增强组件的传输会话有关的传输会话描述信息。S-TSID可提供关于在其中递送某个服务的服务组件的LCT会话的信息。此信息的示例可包括ROUTE会话的tsi信息和/或IP/UDP信息。MPD可包括广播服务的流组件的再现相关信息。MPD可提供用于再现包括在视频和音频组件中的DASH表示的描述信息。换言之，MPD可提供服务组件的片段URL信息和媒体片段的上下文信息。

在根据本发明的另一实施例的由发送侧来提供广播服务的方法中，AST可包括应用元素，其包括关于提供基于应用的增强的应用的信息。AST可包括如在上述实施例中的应用元素。这些应用可用来提供应用增强。各应用增强可包括内容项目元素，其包括关于应用所使用的内容项目的信息。内容项目元素可作为上述应用元素的子元素而存在。各内容项目元素可描述应用所使用的内容项目。至少一个内容项目元素可描述在增强组件中包括的内容项目。上述增强组件可具有某个应用所使用的某个内容项目。可用AST来描述此内容项目。这样，可使用通过AST获取的内容项目来提供基于应用的增强。

在根据本发明的另一实施例的由发送侧来提供广播服务的方法中，S-TSID可包括传输会话标识符信息，其指示在其中递送增强组件的传输会话。S-TSID可指示在其中递送对应于NRT组件的增强组件的传输会话。可提供tsi信息以指示传输会话。根据情况，可提供用于识别ROUTE会话的IP/UDP信息。接收系统可通过S-TSID来获取用于提供基于应用的增强的增强组件。AST的至少一个内容项目元素还可包括内容链接信息，并且该内容链接信息可用来指示使用包括在增强组件中的内容项目的应用。如前文所述，可在应用元素的下层元素怒和/或AST的内容项目元素中包括@ContentLinkage属性。此属性可用来指示在其中使用在增强组件中递送的内容项目的应用。此属性可用来将AST连接到内容项目。替换地，此属性可用来将AST连接到应用。这样，使用S-TSID获取的内容项目可被用来与应用相结合地提供基于应用的增强。

在根据本发明的另一实施例的由发送侧提供广播服务的方法中，MPD还可包括时段元素，其描述实时内容的某个间隔的再现相关信息。在媒体内容的呈现中，时段是与通过在时间方面划分呈现而获得的部分相对应的概念，并且时段元素可提供对应于该部分的媒体再现描述信息。如在前文所述，时段元素可具有事件流元素。此事件流元素可包括多个事件元素。这些事件元素可包括关于用信号通知将由应用执行的行为的事件的信息。另外，各事件元素可包括呈现时间信息和事件的事件标识符。事件标识符可识别事件实例。呈现信息可指示事件的开始时间，并且可基于时段的时间来指示该开始时间。例如，可将时段的开始时间设置成偏移，并且可使用与时段的开始时间的差来指示行为的开始时间。可根据上下文将此行为称为事件。

在根据本发明的另一实施例的由发送侧提供广播服务的方法中，服务信令信息还可包括EMT，并且EMT可包括事件流元素。每个事件流元素可包括事件元素。这些事件元素可包括关于用信号通知将由应用执行的行为的事件的信息。同样地，每个事件元素可包括节目时间信息和事件的事件标识符。

在根据本发明的另一实施例的由发送侧提供广播服务的方法中，EMT还可包括时段标识符和MPD的MPD标识符。在这里，MPD标识符可识别与EMT有关的MPD。换言之，MPD标识符可识别与相应事件有关的MPD。时段标识符可识别描述实时内容的某个间隔的再现相关信息的时段元素。此时段元素可识别与相应事件相关的时段。呈现时间信息可相对于MPD标识符和时段标识符所识别的时段元素基于时段元素所描述的媒体呈现中的间隔来指示行为的开始时间。可根据上下文将此行为称为事件。

将给出根据本发明的实施例的由接收侧提供广播服务的方法的描述。这种方法未在任何图中示出。

根据本实施例的由接收侧提供广播服务的方法可包括由接收侧的第一模块接收广播信号、由接收侧的第二模块在物理上处理广播信号以输出链路层分组、由接收侧的第三模块对链路层分组进行链路处理以输出传输分组、由接收侧的第四模块获取SLT并访问SLS，和/或由接收侧的第五模块获取使用SLS通过广播网络递送的流组件和/或增强组件。在这里，物理处理、链路处理等可对应于发送侧的那些的相反操作。在这里，服务数据可包括：包括关于广播服务的实时内容的数据的流组件和/或包括关于实时内容的基于应用的增强的数据的增强数据。服务信令信息可包括用信号通知提供基于应用的增强的应用的AST。

根据本发明的实施例的由接收侧提供广播服务的方法可对应于上文所述的根据本发明的实施例的由发送侧提供广播服务的方法。由接收侧提供广播服务的方法可由与在由发送侧提供广播服务的方法中使用的模块(例如，发送侧的第一、第二、第三、第四和第五模块等)相对应的硬件模块执行。由接收侧提供广播服务的方法可具有与上文所述的由发送侧提供广播服务的方法的实施例相对应的实施例。

根据给定实施例，上述步骤可被省略或者被执行相同/类似操作的其它步骤替换。

图46图示出根据本发明的实施例的用于由发送侧提供广播服务的装置。

根据本实施例的用于由发送侧提供广播服务的装置可包括上文所述的发送侧的第一、第二、第三、第四和/或第五模块。上文已描述了各块和模块。

根据本实施例的用于由发送侧提供广播服务的装置和内部模块/块可执行上文所述的本发明的由发送侧提供广播服务的方法的实施例。

将给出根据本发明的实施例的用于由接收侧提供广播服务的装置的描述。此装置未在任何图中示出。

根据本实施例的用于由接收侧提供广播服务的装置可包括上文所述的接收侧的第一、第二、第三、第四和/或第五模块。上文已描述了各块和模块。

根据本实施例的用于由接收侧提供广播服务的装置和内部模块/块可执行上文所述的本发明的由接收侧提供广播服务的方法的实施例。

上文所述的装置的内部模块/块可对应于用于执行存储在存储器中的连续过程的处理器，并且可对应于位于根据给定实施例的装置内部/外部的硬件元件。

根据给定实施例，上述模块可被省略或者被用于执行相同/类似操作的其它模块替换。

图47图示出根据本发明的实施例的通过广播网络发送的AST。

当通过广播网络来发送AST时，可通过应用增强与之相关的广播服务的服务信令信道来发送用于应用增强的AST。在这里，服务的服务信令信道可指代通过其递送上述SLS的路径。

具有某个频率的广播信号(广播流)可包括用于服务的服务数据和/或信令数据。例如，可用某个频率来识别广播信号。

广播信号可包括第一ROUTE会话(sIP#A/dIP#A/dPort#A)。可通过第一ROUTE会话来发送用于服务的服务数据。

服务数据可包括用于服务的视频组件和/或音频组件。视频组件可包括具有视频数据的至少一个视频片段。音频组件可包括具有音频数据的至少一个音频段。该视频组件可通过第一ROUTE会话的某个传输会话发送。音频组件可通过第一ROUTE会话的另一传输会话发送。

信令数据可包括低层级信令数据和/或服务层信令数据。例如，低层级信令数据可包括FIT和/或SLT。可将低层级信令数据包括在IP/UDP分组中并发送。可将服务层信令数据称为SLS。服务层信令数据可包括USBD、MPD、S-TSID和/或AST。USBD、MPD、S-TSID和/或AST可通过某个传输会话发送。例如，可通过包括在第一ROUTE会话(sIP#A/dIP#A/dPort#A)中的某个LCT传输会话来发送SLS。具体地，SLS可通过由tsi＝0指定的第一传输会话(tsi-sls)发送。

可通过源IP地址(sIP#A)、目的地IP地址(dIP#A)以及目的地端口号(dPort#A)的组合来识别第一ROUTE会话(sIP#A/dIP#A/dPort#A)。另外，可通过至少一个PLP来发送第一ROUTE会话。例如，可通过第一PLP(PLP#A)来发送第一ROUTE会话。此外，第一ROUTE会话可包括第一传输会话(tsi-sls)、第二传输会话(tsi-app)和/或第三传输会话(未示出)。

第一传输会话(tsi-sls)可包括至少一个服务层信令信息。例如，服务层信令信息可包括上文所述的USBD、MPD、S-TSID和/或AST中的至少一个。

第二传输会话(tsi-app)可包括至少一个应用。例如，应用可指代包括在增强/交互式服务中的文档(HTML、CSS、JavaScript等)的集合。

第三传输会话可包括视频组件。例如，视频组件可包括至少一个视频片段。用于视频片段的传输对象标识符可具有某个值。

在下文中，将描述SLT(或FIT)。

SLT使得接收机能够针对每个服务创建SLS的基本服务列表和引导发现。可通过UDP/IP来发送SLT。SLT可包括用于获取与服务相关的基本信息和服务层信令信息的引导信息。

例如，SLT可包括Broadcast_Stream_id属性和第一服务元素(服务#A)。

Broadcast_Stream_id属性是整个广播流的标识符。Broadcast_Stream_id字段的值在区域层级处可以是唯一的。

第一服务元素(Service#A)可包括serviceId属性和/或signaling_broadcast元素中的至少一个。

serviceId属性可以是用于在广播区域的范围内唯一地识别相应服务的整数。

signaling_broadcast元素可包括用于针对通过广播网络发送的服务的信令信息的信息。signaling_broadcast元素使得接收机能够针对每个服务引导SLS的发现。

signaling_broadcast元素可包括与用于每个服务的源IP地址、目的地IP地址、目的地端口号、PLPID以及SLS有关的传输会话标识符(TSI)。

例如，源IP地址、目的地IP地址和/或目的地端口号可指示第一ROUTE会话(sIP#A/dIP#A/dPort#A)。另外，PLPID可指示第一PLP(PLP#A)。此外，TSI可指示第一传输会话(tsi-sls)。

在下文中，将描述SLS。

可通过广播网络来发送SLS。可通过包括在第一ROUTE会话(sIP#A/dIP#A/dPort#A)中的某个LCT传输会话来发送SLS。具体地，可通过由tsi＝0发送的第一传输会话(tsi-sls)来发送SLS。SLS可包括USBD、MPD、S-TSID和/或AST中的至少一个。

USBD可描述服务层属性。另外，USBD可包括参考MPD和/或S-TSID的参考信息(或URI)。USBD(C620210)的细节可包括关于上述USBD的全部内容。

MPD可包括用于线性/流式传输服务的单独媒体组件的资源标识符。例如，MPD可包括用于通过移动广播网络、一般广播网络和/或互联网协议网络发送的所有组件的DASHMPD。DASH MPD可包括DASH媒体呈现的形式化描述。DASH MPD可包括用于线性/流式传输服务的单独媒体组件的资源标识符。另外，DASH MPD可包括在媒体呈现中识别的资源的上下文。例如，资源标识符可对应于用于识别与用于服务的组件有关的表示的信息。例如，资源标识符可具有片段URL的形式。

S-TSID是一种SLS XML分段，其提供针对用于发送服务的至少一个内容组件的至少一个传输会话的所有会话描述信息。

S-TSID可包括第一ROUTE会话元素(RS)，其提供关于用于服务和/或包括在服务中的组件的ROUTE会话的信息。第一ROUTE会话元素(RS)可包括用于第一ROUTE会话的传输路径信息。另外，第一ROUTE会话元素(RS)可包括关于在ROUTE会话中包括的传输会话(或分层编译传输会话)的信息。例如，第一ROUTE会话元素(RS)可包括第二传输会话元素(LS)，其包括关于第二传输会话的信息。第二传输会话元素(LS)可包括用于第二传输会话的传输路径信息。

具体地，第二传输会话元素(LS)可包括用于识别在其中发送用于服务的内容组件的传输会话的tsi属性和描述在ROUTE会话中包括的源流的SrcFlow元素。SrcFlow元素可包括nrt属性，其指示SrcFlow元素发送NRT服务数据。替换地，SrcFlow元素可包括rt属性，其指示SrcFlow元素是否发送了流媒体数据。换言之，nrt属性可执行与rt属性相同的功能。此外，nrt属性和rt属性可彼此替换。例如，当tsi属性对应于“tsi-app”时，相应传输会话元素可包括用于第二传输会话的信息。另外，当nrt属性对应于“真”时，SrcFlow元素可发送NRT服务数据。

AST可包括用于应用的信令信息。AST的细节可包括所有上述内容。

AST可包括ContentLinkage属性。ContentLinkage属性可指示使用相应内容项目的应用。用于某个应用的信令可由此属性的值和关于下面将描述的事件的信息(EventStream元素、emsg盒等)来执行。

例如，ContentLinkage属性可提供用于识别通过第二传输会话发送的应用的应用标识符。替换地，ContentLinkage属性可提供用于识别第二传输会话(或LCT会话)的传输会话标识符。

广播接收机可基于信令数据来获取服务。具体地，广播接收机可获取低层级信令数据，并且基于该低层级信令数据来获取服务层信令数据。

另外，广播接收机可使用服务层信令数据(USBD)来获取服务的属性。此外，广播接收机可使用USBD来参考和/或获取MPD和/或S-TSID。

另外，广播接收机可使用服务层信令数据(USBD和/或MPD)来获取关于用于服务的至少一个组件(或表示)的信息。例如，广播接收机可获取关于视频组件的信息。

另外，广播接收机可使用服务层信令数据(S-TSID)来获取至少一个组件的传输路径信息。此外，广播接收机可使用服务层信令数据(S-TSID)来获取用于至少一个组件的另一组件的传输路径信息。例如，用于至少一个组件的另一组件可包括应用。

另外，广播接收机可基于服务层信令数据(传输路径信息)来获取用于服务的服务数据。例如，广播接收机可通过第二传输会话(tsi-app)来非实时地接收应用。

另外，广播接收机可基于服务层信令数据(AST)来获取用于识别应用的信息。

广播接收机可在再现视频组件的同时在预定时序操作应用。

图48图示出根据本发明的实施例的通过宽带网络发送的AST。

当通过宽带网络来发送AST时，可通过查询来获取AST。此查询可使用关于SLT中的基础URL的信息来生成。此基础URL可对应于用于获取AST的URL信息。在这里，SLT可对应于包括用于与AST有关的广播服务的引导信息的SLT。

具有某个频率的广播信号(广播流)可包括用于服务的服务数据和/或信令数据。广播信号可包括第一ROUTE会话(sIP#A/dIP#A/dPort#A)。可通过第一PLP(PLP#A)来发送第一ROUTE会话。另外，第一ROUTE会话可包括第一传输会话(未示出)、第二传输会话(tsi-app)和/或第三传输会话(未示出)。第一传输会话可包括至少一个服务层信令信息。第二传输会话(tsi-app)可包括至少一个应用。第三传输会话可包括视频组件。关于第一ROUTE会话(sIP#A/dIP#A/dPort#A)、第一PLP(PLP#A)、第一传输会话、第二传输会话(tsi-app)和/或第三传输会话的内容可包括关于第一ROUTE会话(sIP#A/dIP#A/dPort#A)、第一PLP(PLP#A)、第一传输会话、第二传输会话(tsi-app)和/或第三传输会话的所有上述内容。

在下文中，将描述STL(或FIT)。

根据本发明的实施例的关于SLT的内容可包括SLT的所有上述内容。在下文中，将集中于差别而给出描述。

例如，SLT可包括Broadcast_Stream_id属性和第一服务元素(服务#A)。

第一服务元素(Service#A)可包括serviceId属性和/或signaling_broadband元素中的至少一个。

serviceId属性可对应于用于在广播区域的范围内唯一地识别相应服务的整数。

signaling_broadband元素可包括用于访问用于内容的互联网信令信息(例如，SLS)的路径信息(或URL)。signaling_broadband元素使得接收机能够针对每个服务引导SLS的发现。在这种情况下，可通过宽带网络来发送SLS。

signaling_broadband元素可包括broadbandServerURL_AST，其包括用于访问用于服务的AST的路径信息(或URL)。在这种情况下，可通过宽带网络来发送AST。

在下文中，将描述SLS。

SLS可包括USBD、MPD、S-TSID和/或AST中的至少一个。与SLS有关的内容可包括关于SLS的所有上述内容。然而，一个差别是可通过宽带网络来发送SLS。

根据本实施例的广播接收机可通过广播网络来接收广播信号，该广播信号包括用于服务的服务数据和信令数据(例如，低层级信令数据或SLT)中的至少一个。

根据本实施例的广播接收机可基于信令数据而获取服务。具体地，广播接收机可获取低层级信令数据，并且基于该低层级信令数据来获取服务层信令数据。可通过宽带网络来发送服务层信令数据。

另外，广播接收机可使用服务层信令数据(USBD)来获取服务的属性。此外，广播接收机可使用USBD来参考和/或获取MPD和/或S-TSID。

另外，广播接收机可使用服务层信令数据(USBD和/或MPD)来获取关于用于服务的至少一个组件(或表示)的信息。例如，广播接收机可获取关于视频组件的信息。

另外，广播接收机可使用服务层信令数据(S-TSID)来获取至少一个组件的传输路径信息。此外，广播接收机可使用服务层信令数据(S-TSID)来获取用于所述至少一个组件的另一组件的传输路径信息。例如，用于所述至少一个组件的另一组件可包括应用。

另外，广播接收机可基于服务层信令数据(传输路径信息)来获取用于服务的服务数据。例如，广播接收机可通过第二传输会话(tsi-app)来非实时地接收应用。

另外，广播接收机可基于服务层信令数据(AST)来获取用于识别应用的信息。

广播接收机可在再现视频组件的同时在预定时序操作应用。

图49图示出根据本发明的实施例的以EventStream元素的形式通过广播网络发送的事件。

可以在MPD的Period元素中出现的EventStream元素的形式发送事件。关于通过广播网络发送的EventStream元素的内容可包括关于EventStream元素的所有上述内容。

具有某个频率的广播信号(广播流)可包括用于服务的服务数据和/或信令数据。广播信号可包括第一ROUTE会话(sIP#A/dIP#A/dPort#A)。可通过第一PLP(PLP#A)来发送第一ROUTE会话。另外，第一ROUTE会话可包括第一传输会话(未示出)、第二传输会话(tsi-sls)和/或第三传输会话(未示出)。第一传输会话(tsi-sls)可包括至少一个服务层信令信息。例如，服务层信令信息可包括上文所述的USBD、MPD、S-TSID和/或AST中的至少一个。第二传输会话(tsi-app)可包括至少一个应用。第三传输会话可包括视频组件。关于第一ROUTE会话(sIP#A/dIP#A/dPort#A)、第一PLP(PLP#A)、第一传输会话、第二传输会话(tsi-app)和/或第三传输会话的内容可包括关于第一ROUTE会话(sIP#A/dIP#A/dPort#A)、第一PLP(PLP#A)、第一传输会话、第二传输会话(tsi-app)和/或第三传输会话的所有上述内容。

在下文中，将描述SLT。

SLT使得接收机能够针对每个服务创建SLS的基本服务列表和引导发现。例如，SLT可包括用于第一ROUTE会话(sIP#_A/dIP#_A/dPort#_A)的路径信息。另外，SLT可包括用于第一传输会话(tsi-sls)的路径信息。根据本实施例的关于SLT的内容可包括SLT的所有上述内容。

在下文中，将描述SLS。

SLS可包括USBD、MPD、S-TSID和/或AST中的至少一个。与SLS有关的内容可包括关于SLS的所有上述内容。在下文中，将更详细地描述MPD。

MPD对应于用于某个服务的服务信令信息，并且可以称为时段的服务的一定时间间隔提供信令信息。与时段有关的信令信息被包括在MPD Period元素中，并且此Period元素可包括EventStream元素。EventStream元素可提供该服务时段期间的应用操作所需的信令(事件)。

EventStream元素可包括schemeIdUri属性、值属性、时标属性和/或至少一个Event子元素。每个Event子元件可包括presentationTime属性、持续时间属性和/或id属性。EventStream元素的细节可包括关于EventStream元素的所有上述内容。

例如，schemeIdUri属性可具有“urn:uuid:XYZY”的值。另外，值属性可具有“调用(call)”的值。此外，时标属性可具有“1000”的值。

另外，关于第一事件，presentationTime属性可具有“0”的值，持续时间属性可具有“10000”的值和/或id属性可具有“0”的值。此外，数据元素/属性可对应于“+1 80010101010”。关于第二事件，presentationTime属性可具有“20000”的值，持续时间属性可具有“10000”的值和/或id属性可具有“1”的值。此外，数据元素/属性可对应于“+1 80010101011”。关于第三事件，presentationTime属性可具有“40000”的值，持续时间属性可具有“10000”的值和/或id属性可具有“2”的值。此外，数据元素/属性可对应于“+1 80010101012”。关于第四事件，presentationTime属性可具有“60000”的值，持续时间属性可具有“10000”的值和/或id属性可具有“3”的值。此外，数据元素/属性可对应于“+1 80010101013”。

根据本实施例的广播接收机可通过广播网络来接收广播信号，该广播信号包括用于服务的服务数据和信令数据(例如，低层级信令数据或服务层信令数据)中的至少一个。

根据本实施例的广播接收机可基于信令数据而获取服务。具体地，广播接收机可获取低层级信令数据，并且基于该低层级信令数据来获取服务层信令数据。

另外，广播接收机可使用服务层信令数据(USBD)来获取服务的属性。此外，广播接收机可使用USBD来参考和/或获取MPD和/或S-TSID。

另外，广播接收机可使用服务层信令数据(USBD和/或MPD)来获取关于用于服务的至少一个组件(或表示)的信息。例如，广播接收机可获取关于视频组件的信息。

另外，广播接收机可使用服务层信令数据(S-TSID)来获取至少一个组件的传输路径信息。此外，广播接收机可使用服务层信令数据(S-TSID)来获取用于所述至少一个组件的另一组件的传输路径信息。例如，用于所述至少一个组件的另一组件可包括应用。

另外，广播接收机可基于服务层信令数据(传输路径信息)来获取用于服务的服务数据。例如，广播接收机可通过第二传输会话(tsi-app)来非实时地接收应用。

另外，广播接收机可基于服务层信令数据(AST)来获取用于识别应用的信息。

另外，广播接收机可基于事件来操作应用。例如，可以在Period元素中出现的EventStream元素的形式来发送事件。广播接收机可在再现视频组件的同时在预定时序操作应用。

图50图示出根据本发明的实施例的以emsg盒的形式通过广播网络发送的事件。

该事件可以在Representation的各片段(或Representation片段)中出现的emsg盒的形式发送。关于通过广播网络发送的emsg盒的内容可包括关于emsg盒的所有上述内容。

具有某个频率的广播信号(广播流)可包括用于服务的服务数据和/或信令数据。广播信号可包括第一ROUTE会话(sIP#_A/dIP#_A/dPort#_A)。可通过第一PLP(PLP#_A)来发送第一ROUTE会话。另外，第一ROUTE会话可包括第一传输会话(未示出)、第二传输会话(tsi-sls)和/或第三传输会话(tsi-v)。第一传输会话(tsi-sls)可包括至少一个服务层信令信息。例如，服务层信令信息可包括上文所述的USBD、MPD、S-TSID和/或AST中的至少一个。第二传输会话(tsi-app)可包括至少一个应用。第三传输会话可包括视频组件。视频组件可包括包含视频数据的至少一个视频片段。所述至少一个视频片段可包括emsg盒。

关于第一ROUTE会话(sIP#_A/dIP#_A/dPort#_A)、第一PLP(PLP#_A)、第一传输会话、第二传输会话(tsi-app)和/或第三传输会话(tsi-v)的内容可包括关于第一ROUTE会话(sIP#_A/dIP#_A/dPort#_A)、第一PLP(PLP#_A)、第一传输会话、第二传输会话(tsi-app)和/或第三传输会话(tsi-v)的所有上述内容。

在下文中，将描述包括在各片段中的emsg盒。

emsg盒可提供用于与meticulously呈现时间有关的一般事件的信令信息。emsg盒可包括schemeIdUri字段、值字段、时标字段、presentationTimeDelta字段、eventDuration字段、id字段和/或messageData字段中的至少一个。关于emsg盒的内容可包括emsg盒的所有上述内容。

在下文中，将描述SLT。

SLT使得接收机能够针对每个服务创建SLS的基本服务列表和引导发现。例如，SLT可包括用于第一ROUTE会话(sIP#_A/dIP#_A/dPort#_A)的路径信息。另外，SLT可包括用于第一传输会话(tsi-sls)的路径信息。根据本实施例的关于SLT的内容可包括SLT的所有上述内容。

在下文中，将描述SLS。

SLS可包括USBD、MPD、S-TSID和/或AST中的至少一个。与SLS有关的内容可包括关于SLS的所有上述内容。在下文中，将更详细地描述S-TSID和/或MPD。

S-TSID可第一ROUTE会话元素(RS)，其提供关于用于服务和/或包括在服务中的组件的ROUTE会话的信息。第一ROUTE会话元素(RS)可包括用于第一ROUTE会话的传输路径信息。另外，第一ROUTE会话元素(RS)可包括关于包括在ROUTE会话中的传输会话(或分层编译传输会话)的信息。例如，第一ROUTE会话元素(RS)可包括第二传输会话元素(LS)，其包括关于第二传输会话的信息。第二传输会话元素(LS)可包括用于第二传输会话的传输路径信息。另外，第一ROUTE会话元素(RS)可包括第三传输会话元素(LS)，其包括关于第三传输会话的信息。第三传输会话元素(LS)可包括用于第三传输会话的传输路径信息。

具体地，第二传输会话元素(LS)和/或第三传输会话元素(LS)中的每一个可包括用于识别在其中发送用于服务的内容组件的传输会话的tsi属性和描述包括在ROUTE会话中的源流的SrcFlow元素。

SrcFlow元素可包括nrt属性，其指示SrcFlow元素发送NRT服务数据。替换地，SrcFlow元素可包括rt属性，其指示SrcFlow元素是否发送了流媒体数据。换言之，nrt属性可执行与rt属性相同的功能。此外，nrt属性和rt属性可彼此替换。

SrcFlow元素还可包括appID属性，其包括被映射到通过传输会话发送的服务(或应用服务)的附加信息。appID属性可称为ContentInfo元素。ContentInfo元素可包括被映射到通过传输会话发送的服务(或应用服务)的附加信息。例如，ContentInfo元素可包括DASH内容的表示标识符(ID)和/或DASH媒体再现的适配集参数以便选择用于再现的LCT传输会话。表示ID是与用于服务的组件有关的ID，并且可称为id属性。因此，可使SrcFlow元素中的appID属性与MPD的Representation元素中的id属性匹配。

关于第二传输会话元素(LS)，当tsi属性对应于“tsi-app”时，传输会话元素可包括用于第二传输会话的信息。另外，当nrt属性对应于“真”时，SrcFlow元素可发送NRT服务数据。换言之，可通过第二传输会话(tsi-app)非实时地发送应用。

关于第三传输会话元素(LS)，当tsi属性对应于“tsi-app”时，传输会话元素可包括用于第三传输会话的信息。另外，当nrt属性对应于“假”时，SrcFlow元素可实时地发送NRT服务数据。此外，当appID属性对应于“rep_v1”时，视频组件的表示ID可对应于“rep_v1”。换言之，可通过第三传输会话(tsi-v)实时地发送“rep_v1”所识别的视频组件的至少一个视频片段。

MPD可包括用于线性/流式传输服务的单独媒体组件的资源标识符。MPD可包括Period元素。Period元素可包括包含关于视频组件的信息的AdaptationSet元素。AdaptationSet元素可包括至少一个Representation元素。Representation元素可包括关于与组件有关的表示的信息。

Representation元素可包括用于识别该表示的id属性。例如，id属性可具有“rep_v1”的值。换言之，id属性可指示通过第三传输会话(tsi-v)发送的视频组件。

另外，Representation元素还可包括InbandEventStream元素，其指定相关表示中的带内事件流的存在。在这种情况下，MPD的Representation元素的InbandEventStream元素可用信号发送在各片段中的emsg盒中是否存在事件。

InbandEventStream元素可包括schemeIdURI属性和/或值属性。这两个属性可指示emsg盒中的事件的类型。根据给定实施例，这两个属性可用来识别事件。可使包括在InbandEventStream元素中的schemeIdURI属性和/或值属性与emsg盒中的schemeIdURI属性和/或值属性匹配。例如，schemeIdURI属性可具有“event_URI的值，并且值属性可具有“abc”的值。

根据本实施例的广播接收机可通过广播网络来接收广播信号，该广播信号包括用于服务的服务数据和信令数据(例如，低层级信令数据或服务层信令数据)中的至少一个。

根据本实施例的广播接收机可基于信令数据而获取服务。具体地，广播接收机可获取低层级信令数据，并且基于该低层级信令数据来获取服务层信令数据。

另外，广播接收机可使用服务层信令数据(USBD)来获取服务的属性。此外，广播接收机可使用USBD来参考和/或获取MPD和/或S-TSID。

另外，广播接收机可使用服务层信令数据(USBD和/或MPD)来获取关于用于服务的至少一个组件(或表示)的信息。例如，广播接收机可获取关于视频组件的信息。在这种情况下，MPD的Representation元素可包括InbandEventStream元素，其指定视频组件中的emsg盒(或带内事件流)的存在。

另外，广播接收机可使用服务层信令数据(S-TSID)来获取至少一个组件的传输路径信息。此外，广播接收机可使用服务层信令数据(S-TSID)来获取用于所述至少一个组件的另一组件的传输路径信息。例如，用于所述至少一个组件的另一组件可包括应用。

另外，广播接收机可基于服务层信令数据(传输路径信息)来获取用于服务的服务数据。例如，广播接收机可通过第二传输会话(tsi-app)来非实时地接收应用。此外，广播接收机可实时地通过第三传输会话(tsi-v)来接收“rep_v1”所识别的视频组件的至少一个视频片段。所述至少一个视频片段可包括emsg盒。

另外，广播接收机可基于服务层信令数据(AST)来获取用于识别应用的信息。

另外，广播接收机可基于事件来操作应用。例如，可以emsg盒的形式将事件包括在片段中。广播接收机可在再现视频组件的同时在预定时序操作应用。

图51图示出根据本发明的实施例的以EventStream元素的形式通过宽带网络发送的事件。

可以包括在通过宽带网络发送的EST中的EventStream元素的形式来发送事件。当通过宽带网络来发送EST时，可通过查询来获取EST。可使用ALT中的URL信息来生成此查询。此URL信息可以是用于获取EST的URL信息。关于通过宽带网络发送的EventStream元素的内容可包括关于EventStream元素的所有上述内容。

具有某个频率的广播信号(广播流)可包括用于服务的服务数据和/或信令数据。广播信号可包括第一ROUTE会话(sIP#_A/dIP#_A/dPort#_A)。可通过第一PLP(PLP#_A)来发送第一ROUTE会话。另外，第一ROUTE会话可包括第一传输会话(未示出)、第二传输会话(tsi-sls)和/或第三传输会话(未示出)。第一传输会话(tsi-sls)可包括至少一个服务层信令信息。例如，服务层信令信息可包括上文所述的USBD、MPD(未示出)、S-TSID和/或AST中的至少一个。第二传输会话(tsi-app)可包括至少一个应用。第三传输会话可包括视频组件。根据给定实施例，可省略MPD。根据本实施例的关于第一ROUTE会话(sIP#_A/dIP#_A/dPort#_A)、第一PLP(PLP#_A)、第一传输会话、第二传输会话(tsi-app)和/或第三传输会话的内容可包括关于第一ROUTE会话(sIP#_A/dIP#_A/dPort#_A)、第一PLP(PLP#_A)、第一传输会话、第二传输会话(tsi-app)和/或第三传输会话的所有上述内容。

在下文中，将描述SLT。

SLT可包括用于第一ROUTE会话(sIP#_A/dIP#_A/dPort#_A)的路径信息。另外，SLT可包括用于第一传输会话(tsi-sls)的路径信息。根据本实施例的关于SLT的内容可包括SLT的所有上述内容。

在下文中，将描述SLS。

SLS可包括USBD、MPD、S-TSID和/或AST中的至少一个。关于SLS的内容可包括关于SLS的所有上述内容。在下文中，将更详细地描述AST。

AST可包括ContentLinkage属性。ContentLinkage属性可指示使用相应内容项目的应用。用于某个应用的信令可由此属性的值和关于下面将描述的事件的信息(EventStream元素、emsg盒等)来执行。

例如，ContentLinkage属性可提供用于识别通过第二传输会话发送的应用的应用标识符。替换地，ContentLinkage属性可提供用于识别第二传输会话(或LCT会话)的传输会话标识符。

AST还可包括BroadbandStaticEventURL属性。BroadbandStaticEventURL属性可包括用于访问用于服务的EST的路径信息(或URL)。在这种情况下，可通过宽带网络来发送EST。EST可包括EventStream元素。EventStream元素可提供应用的操作所需的信令(事件)。

EventStream元素可包括schemeIdUri属性、值属性、时标属性和/或至少一个Event子元素。每个Event子元件可包括presentationTime属性、持续时间属性和/或id属性。EventStream元素的细节可包括关于EventStream元素的所有上述内容。

例如，schemeIdUri属性可具有“urn:uuid:XYZY”的值。另外，值属性可具有“调用”的值。

此外，时标属性可具有“1000”的值。另外，关于第一事件，presentationTime属性可具有“0”的值，持续时间属性可具有“10000”的值和/或id属性可具有“0”的值。此外，数据元素/属性可对应于“+1 800 10101010”。关于第二事件，presentationTime属性可具有“20000”的值，持续时间属性可具有“10000”的值和/或id属性可具有“1”的值。此外，数据元素/属性可对应于“+1 800 10101011”。关于第三事件，presentationTime属性可具有“40000”的值，持续时间属性可具有“10000”的值和/或id属性可具有“2”的值。此外，数据元素/属性可对应于“+1 800 10101012”。关于第四事件，presentationTime属性可具有“60000”的值，持续时间属性可具有“10000”的值和/或id属性可具有“3”的值。此外，数据元素/属性可对应于“+1 800 10101013”。

根据本实施例的广播接收机可通过广播网络来接收广播信号，该广播信号包括用于服务的服务数据和信令数据(例如，低层级信令数据或服务层信令数据)中的至少一个。

根据本实施例的广播接收机可基于信令数据而获取服务。具体地，广播接收机可获取低层级信令数据，并且基于该低层级信令数据来获取服务层信令数据。

另外，广播接收机可使用服务层信令数据(USBD)来获取服务的属性。此外，广播接收机可使用USBD来参考和/或获取MPD和/或S-TSID。

另外，广播接收机可使用服务层信令数据(USBD和/或MPD)来获取关于用于服务的至少一个组件(或表示)的信息。例如，广播接收机可获取关于视频组件的信息。

另外，广播接收机可使用服务层信令数据(S-TSID)来获取至少一个组件的传输路径信息。此外，广播接收机可使用服务层信令数据(S-TSID)来获取用于所述至少一个组件的另一组件的传输路径信息。例如，用于所述至少一个组件的另一组件可包括应用。

另外，广播接收机可基于服务层信令数据(传输路径信息)来获取用于服务的服务数据。例如，广播接收机可通过第二传输会话(tsi-app)来非实时地接收应用。

另外，广播接收机可基于服务层信令数据(AST)来获取用于识别应用的信息。此外，广播接收机可基于服务层信令数据(AST)通过宽带网络来获取EST。

另外，广播接收机可基于事件来操作应用。例如，可以包括在通过宽带网络发送的EST中的EventStream元素的形式来发送事件。

广播接收机可在再现视频组件的同时在预定时序操作应用。

图52图示出根据本发明的实施例的以emsg盒的形式通过宽带网络发送的事件。

可以通过宽带网络发送的emsg盒的形式发送事件。在这种情况下，可通过实时事件服务器来递送事件。可使用实时事件服务器周期性地执行轮询。当存在要在相应时段中发送的事件时，事件服务器可将事件递送到接收机。关于通过宽带网络发送的emsg盒的内容可包括关于emsg盒的所有上述内容。

具有某个频率的广播信号(广播流)可包括用于服务的服务数据和/或信令数据。广播信号可包括第一ROUTE会话(sIP#_A/dIP#_A/dPort#_A)。可通过第一PLP(PLP#_A)来发送第一ROUTE会话。另外，第一ROUTE会话可包括第一传输会话(未示出)、第二传输会话(tsi-sls)和/或第三传输会话(未示出)。第一传输会话(tsi-sls)可包括至少一个服务层信令信息。例如，服务层信令信息可包括上文所述的USBD、MPD(未示出)、S-TSID和/或AST中的至少一个。第二传输会话(tsi-app)可包括至少一个应用。第三传输会话可包括视频组件。根据给定实施例，可省略MPD。根据本实施例的关于第一ROUTE会话(sIP#_A/dIP#_A/dPort#_A)、第一PLP(PLP#_A)、第一传输会话、第二传输会话(tsi-app)和/或第三传输会话的内容可包括关于第一ROUTE会话(sIP#_A/dIP#_A/dPort#_A)、第一PLP(PLP#_A)、第一传输会话、第二传输会话(tsi-app)和/或第三传输会话的所有上述内容。

在下文中，将描述SLT。

SLT可包括用于第一ROUTE会话(sIP#_A/dIP#_A/dPort#_A)的路径信息。另外，SLT可包括用于第一传输会话(tsi-sls)的路径信息。根据本实施例的关于SLT的内容可包括SLT的所有上述内容。

在下文中，将描述SLS。

SLS可包括USBD、MPD、S-TSID和/或AST中的至少一个。关于SLS的内容可包括关于SLS的所有上述内容。在下文中，将更详细地描述AST。

AST可包括ContentLinkage属性。ContentLinkage属性可指示使用相应内容项目的应用。可使用此属性的值和关于下面将描述的事件的信息(EventStream元素、emsg盒等)来执行用于某个应用的信令。

例如，ContentLinkage属性可提供用于识别通过第二传输会话发送的应用的应用标识符。替换地，ContentLinkage属性可提供用于识别第二传输会话(或LCT会话)的传输会话标识符。

AST还可包括BroadbandStaticEventURL属性。BroadbandStaticEventURL属性可包括用于访问用于服务的emsg盒的路径信息(或URL)。在这种情况下，可通过宽带网络来发送emsg盒。emsg盒可提供应用的操作所需的信令(事件)。

emsg盒可提供用于与meticulously呈现时间有关的一般事件的信令信息。emsg盒可包括schemeIdUri字段、值字段、时标字段、presentationTimeDelta字段、eventDuration字段、id字段和/或messageData字段中的至少一个。关于emsg盒的内容可包括emsg盒的所有上述内容。

例如，schemeIdUri字段可具有“urn:uuid:XYZY”的值。

根据本实施例的广播接收机可通过广播网络来接收广播信号，该广播信号包括用于服务的服务数据和信令数据(例如，低层级信令数据或服务层信令数据)中的至少一个。

根据本实施例的广播接收机可基于信令数据而获取服务。具体地，广播接收机可获取低层级信令数据，并且基于该低层级信令数据来获取服务层信令数据。

另外，广播接收机可使用服务层信令数据(USBD)来获取服务的属性。此外，广播接收机可使用USBD来参考和/或获取MPD和/或S-TSID。

另外，广播接收机可使用服务层信令数据(USBD和/或MPD)来获取关于用于服务的至少一个组件(或表示)的信息。例如，广播接收机可获取关于视频组件的信息。

另外，广播接收机可使用服务层信令数据(S-TSID)来获取至少一个组件的传输路径信息。此外，广播接收机可使用服务层信令数据(S-TSID)来获取用于至少一个组件的另一组件的传输路径信息。例如，用于至少一个组件的另一组件可包括应用。

另外，广播接收机可基于服务层信令数据(传输路径信息)来获取用于服务的服务数据。例如，广播接收机可通过第二传输会话(tsi-app)来非实时地接收应用。

另外，广播接收机可基于服务层信令数据(AST)来获取用于识别应用的信息。此外，广播接收机可基于服务层信令数据(AST)通过宽带网络来获取emsg盒。

另外，广播接收机可基于事件来操作应用。例如，可以通过宽带网络发送的emsg盒的形式发送事件。

广播接收机可在再现视频组件的同时在预定时序操作应用。

图53图示出根据本发明的实施例的API和事件收听器。

图53(a)图示出收听器。

事件处理器可对应于响应于事件的发生而执行的代码。例如，事件处理器可对应于用于当事件发生时执行的JavaScript代码。事件处理器可包括事件收听器(或侦听器)。不同于针对一个元素只能处理一个事件的事件句柄，事件收听器可针对一个元素处理至少一个事件。

收听器可包括文档对象模型(DOM)事件收听器的一般特征。在这里，DOM指代支持事件句柄、使得该事件句柄可连接到所有元素节点的模型(系统)。

根据本实施例的收听器可包括StreamEvent类型的对象作为参数。例如，收听器可具有诸如收听器(StreamEvent事件)之类的形式。

递送到收听器的StreamEvent类型的对象具有一般DOM事件类型的对象的扩展形式。

StreamEvent类型的对象可包括名称属性、数据属性、文本属性、状态属性和/或时间属性。

名称属性可指示事件的名称。名称属性是只读属性，并且可对应于串类型。

数据属性可指示被编码为十六进制数的事件的数据。例如，数据属性可具有“0A10B81033”的值。数据属性是只读属性，并且可对应于串类型。

文本属性可指示事件的文本数据。例如，当数据属性包括文本时，文本属性可具有采取ASCII码的值。另外，文本属性可对应于用于事件激活的Event元素的子元素，并且包括在触发器中指定或者在EMT的Event元素中指定的数据标识符(dataID)所识别的数据。文本属性是只读属性，并且可对应于串类型。

状态属性可指示事件的状态。当事件响应于触发器而被激活时，状态属性可指示“触发”。当发生多个类型的错误时，状态属性可指示“错误”。状态属性是只读属性，并且可对应于DOMString类型。

时间属性可指示事件发生的时间。时间属性是只读属性，并且可具有整数类型。

图53(b)图示出用于事件收听器(或侦听器)的添加和/或删除的API。

根据本发明的实施例的处理事件的方法可包括将事件收听器连接到对象的方法的方案。这种方法是将事件收听器连接到对象的方法并在然后事件发生时执行对象的方法的方法。

根据本发明的实施例的AddStreamEventListener API和/或removeStreamEventListener API可用来支持处理事件的这种方法。

AddStreamEventListener API可添加用于事件的收听器(例如，事件收听器或流事件收听器)。AddStreamEventListener API可向AST添加用于由在一定范围的当前执行html应用内的事件标识符(例如，eventID)指定的事件的收听器。当事件被触发器激活时，收听器被调用。另外，可递送TriggerEvent类型(或StreamEvent类型)的对象。可仅在视频/广播对象处于呈现和/或停止状态时才可添加收听器。

AddStreamEventListener API可包括targetURL参数、eventName参数和/或Listener参数中的至少一个。例如，addStreamEventListener API可具有诸如addStreamEventListener(targetURL、eventName、收听器)之类的形式。

targetURL参数可指示描述事件的StreamEvent对象的URL。替换地，可将targetURL参数映射到DASHEventStream元素的schemeIdURI属性。

eventName参数可指示要订阅的事件的名称。替换地，可将eventName参数映射到DASHEventStream元素的值属性。

Listener参数可指示用于事件的收听器。Listener参数可对应于回调函数。当事件发生时，可将Listener参数作为参数并连同递送的StreamEvent对象一起调用。

targetURL参数和eventName参数可对应于用于识别事件的事件标识符。例如，addStreamEventListener API可包括事件标识符(eventId)参数和收听器参数。例如，addStreamEventListener API可具有addTriggerEventListener(String eventId、EventListener收听器)的形式。事件标识符可对应于存在于EMT中的事件元素中的事件的标识符(例如，EventID属性或id属性)。另外，事件标识符可对应于被触发器动态地更新的事件的标识符(例如，emsg盒的id字段)。

RemoveStreamEventListener API可删除用于事件的收听器。RemoveStreamEventListener API可删除用于由事件标识符(例如，eventID)指定的事件的收听器。

RemoveStreamEventListener API可包括targetURL参数、eventName参数和/或Listener参数中的至少一个。例如，removeStreamEventListener API可具有诸如removeStreamEventListener(targetURL、eventName、收听器)之类的形式。

targetURL参数可指示StreamEvent对象的URL。替换地，可将targetURL参数映射到DASH EventStream元素的schemeIdURI属性。

eventName参数可指示事件的名称，该事件的订阅需要被删除。替换地，可将eventName参数映射到DASH EventStream元素的值属性。

收听器参数可指示用于事件的收听器。Listener参数可对应于回调函数。当事件发生时，可将Listener参数作为参数并连同递送的StreamEvent对象一起调出。

targetURL参数和eventName参数可对应于用于识别事件的事件标识符。例如，removeStreamEventListener API可包括事件标识符(eventId)参数和收听器参数。例如，removeStreamEventListener API可具有removeTriggerEventListener(String eventId、EventListener收听器)的形式。事件标识符可对应于存在于EMT中的事件元素中的事件的标识符(例如，EventID属性或id属性)。另外，事件标识符可对应于被触发器动态地更新的事件的标识符(例如，emsg盒的id字段)。

根据本实施例的广播接收机可基于addStreamEventListener API而添加用于事件的收听器。另外，广播接收机可基于removeStreamEventListener API而添加用于事件的收听器。AddStreamEventListener API和/或removeStreamEventListener API可支持用于广播节目的html应用行为的同步。

图54是根据本发明的实施例的电子装置的框图。

参考图54，电子装置100包括控制器110和通信单元120。控制器110可与配套装置建立通信连接。另外，当建立了与配套装置的通信连接时，通信单元120可与配套装置交换数据。

另外，控制器110可包括网络处理器111和应用处理器112。应用处理器112可从网络连接器111请求与配套装置的连接。

网络处理器111可将从应用处理器112接收到的连接请求置于备用状态，因为网络连接器111尚未与配套装置相连。然后，网络处理器111可从配套装置接收连接请求。网络处理器111可基于从配套装置接收到的信息从应用处理器112搜索匹配的连接请求。在找到匹配连接请求时，网络处理器111可将配套装置连接到应用处理器112。

作为示例，应用处理器112可对应于应用模块或应用浏览器。替换地，应用处理器112可对应于HbbTV应用。作为示例，网络处理器111可被实现为网络模块。替换地，网络处理器111可对应于WebSocket服务器。网络处理器111可将应用处理器112和配套装置互连。作为示例，当网络处理器111被实现为WebSocket服务器时，应用处理器112和配套装置中的每一个可被视为一个客户端。换言之，WebSocket服务器可连接第一客户端和第二客户端。替换地，可将第一客户端和第二客户端中的每一个称为对端。根据情况，可将WebSocket服务器实现为电子装置外部的单独设备。

同时，应用处理器112可操作一个应用。另外，配套装置可操作一个应用。应用处理器112可通过网络处理器111连接到配套装置。配套装置可从应用处理器112接收数据并接收且驱动正在被应用处理器112驱动的应用。替换地，应用处理器112和配套装置中的每一个可驱动应用。应用处理器112可连接到配套装置以与配套装置交换数据。在这种情况下，可认为电子装置100和配套装置将执行应用间通信。

WebSocket服务器可被用作重发器，并且可生成应用之间的通信信道。一般通信信道可使得电子装置100和配套装置能够相互通信。WebSocket服务器可使用期望执行通信以生成通信信道的应用的名称ID和起点ID而在请求相同信息的应用之间连接信道。例如，上述方法可在不修正HbbTV 2.0中的WebSocket API的情况下将应用(客户端)和应用(客户端)连接。

在本说明书中，各术语是可互换的。

图55是用于根据本发明的实施例的第一客户端的连接的描述的图。

图55图示出电子装置100a和配套装置200a。电子装置100a可包括应用处理器和网络处理器。作为示例，应用处理器可对应于HbbTV应用或第一应用，并且网络处理器可对应于HbbTV WebSocket服务器。配套装置200a可包括配套装置处理器。作为示例，配套装置处理器可对应于配套应用或第二客户端。可能需要改变WebSocket服务器以连接客户端。在下文中，将描述与WebSocket服务器的改变有关的操作。可在HbbTV 2.0TV中驱动已改变的WebSocket服务器。

通常，在伴随WebSocket连接升级报头的初始GET请求中，WebSocket客户端指定其希望与之建立连接的远程主机，以及用于该主机上的期望服务的相对URI。然而，在HbbTV中，不能假设将与之建立通信的对端已连接WebSocket服务器。在特殊的客户端至客户端模式下来自客户端的连接请求因此需要保持活跃直至另一适当的对端到达为止。

为此，我们针对WebSocket协议升级GET请求的两个字段定义特殊用途。作为Request-Line的一部分的Request-URI采取具有公共前缀串的预定义格式。此字段被用来匹配相应通信对端。Host请求报头字段可指代运行WebSocket服务器的电视机(在这种情况下，将建立与具有匹配Request-URI的任何对端的通信)或特定配套装置(在这种情况下，将仅建立与指定设备以及与匹配Request-URI的通信)。

用于Request-URI字段的格式可以是根据以下ABNF语法：

HbbTV-Request-URI＝"/hbbtv/"org-id"."app-id

org-id＝8HEX

app-id＝4HEX

响应于这样的请求，HbbTV WebSocket服务器可创建作为半开放连接的流报头，其与由客户端在升级GET请求中供应的Request-URI相关联。服务器可不立即用WebSocketProtocol Handshake响应进行响应，而是替代地等待其它对端出现，并且从而保持第一客户端等待。如果服务器希望实现超时，则其可用504 Gateway Timeout响应进行响应。

客户端在请求客户端至客户端连接时可不适用Sec-WebSocket-Protocol报头。服务器可忽视用于客户端至客户端连接的请求中的Sec-WebSocket-Protocol报头。如果客户端至客户端连接请求中的Host报头字段并未指定服务器被附着到的本地子网络中的任何一个上的装置，则服务器可用403Forbidden响应进行响应。所有HbbTV 2.0 WebSocket客户端可使用在本节中描述的方法而从HbbTV 2.0 WebSocket服务器请求客户端至客户端连接。

图56是用于根据本发明的实施例的第二客户端的连接的描述的图。

图56图示出电子装置100a和配套装置200a。电子装置100a可包括应用处理器和网络处理器。网络处理器(例如，WebSocket服务器)可从HbbTV应用和配套应用接收连接请求。

当另一客户端使用上述方法来请求客户端至客户端连接时，服务器还可如图3中所示地创建用于该新请求的流报头。在创建新的流报头之后，服务器可在当前等待被连接的流报头的集合中搜索与新创建流报头的那些匹配的Request-URI和Host报头字段值。如果未发现匹配，则服务器可向当前等待被连接的流报头的集合添加新创建的流报头，并且可保持等待进一步的客户端至客户端连接请求。

图57是用于根据本发明的实施例的第一和第二客户端之间的连接的描述的图。

图57图示出电子装置100a和配套装置200a。电子装置100a可包括应用处理器和网络处理器。网络处理器(例如，WebSocket服务器)可连接HbbTV应用和配套应用。

如果新创建的流报头跟与当前等待被连接的流报头集合中的流报头相同的Request-URI和Host报头字段值相关联，则服务器可将匹配的流报头从集合去除，并且可在两个流报头之间建立全双工通信信道。

一旦两个流报头被连接，则服务器立即输出从一个流报头接收到的所有数据而没有对各其它流报头的改变。从而，在两个客户端之间建立透明通信信道。

如果两个客户端中的一个发送Close帧，则服务器可向另一客户端发送相应的Close帧。如果两个客户端中的一个在没有发送Close帧的情况下断开连接，则服务器可生成Close帧，并且可将其发送到另一客户端。

换言之，网络处理器可生成应用处理器的流报头，并且响应于来自应用处理器的连接请求而将该流报头包括在流报头组中。另外，响应于来自配套装置的连接请求，网络处理器可生成配套装置的流报头并验证是否存在匹配的流报头。当匹配流报头存在时，网络处理器可将应用处理器的流报头与从流报头组匹配的配套装置的流报头相连。在这种情况下，网络处理器可将应用处理器的匹配流报头或配套装置的匹配流报头从流报头组去除。

图58是用于根据本发明的实施例的用于附加连接请求的描述的图。

参考图58，HbbTV应用(客户端)被连接到配套装置200a的配套应用(客户端)。另外，HbbTV应用可生成用于另一客户端的另一流报头。HbbTV应用可另外被连接到另一应用。如果在建立客户端至客户端连接之前，任何流报头被从可用于连接的流报头的集合去除，则这样的客户端至客户端连接仅仅是一对一的。如果客户端希望与超过一个其它客户端通信，则其可向服务器发布进一步的连接请求直至已达到其能够处理的客户端至客户端连接的最大数目为止。

WebSocket服务器可不允许用于具有相同Request-URI和Host的同一客户端的超过一个流报头在当前等待被连接的流报头的集合上。如果客户端发布具有相同Request-URI和Host的另一客户端至客户端连接请求，则在先前的那个被成功地连接或者已超时之前，服务器可用403 Forbidden响应进行响应。

客户端可具有多个客户端至客户端连接请求，其具有处于等待连接状态的不同Request-URI/Host组合。在先前的客户端被成功地连接或已超时之前，客户端可不尝试用同一Request-URI/Host组合来请求另一客户端至客户端连接。

可使用用于Request-URI的“/hbbtv/orgid.appid scheme”作为进入特殊服务器客户端至客户端行为的逃离(escape)，以便允许其被连同其它的标准WebSocket服务器功能一起实现，并且没有与之相干扰。匹配Request-URI和Host报头字段的选择允许有两个方法：如果特定设备被Host报头确定为目标，则客户端只希望与该特定其它客户端进行交谈。其可能已通过其它手段(例如作为UPnP的一部分的SSDP)获悉其存在。其次，如果Host报头字段将服务器确定为目标，则其对于将该服务器确定为目标的所有客户端而言都将是相同的。这将仅导致Request-URI是用于选择适当通信对端的区别因素。因此，在Host报头字段中将服务器确定为目标有效地提供与具有同一Request-URI且也将该服务器确定为目标的任何其它客户端的通配符匹配。同样地，专用型和机会型连接建立策略两者都是可能的。

由于HbbTV 2.0 WebSocket服务器并未执行任何认证、授权或其它验证，所以没有信任可以与客户端至客户端连接或者在客户端与WebSocket服务器之间相关联。希望通过WebSocket服务器来交换私人或者另外敏感信息的客户端因此应采用端到端加密来确保通信的保密性。同样地，这样的客户端应采用密码方法来确立其希望通过WebSocket服务器与之通信的任何通信对端的标识和真实性。由于HbbTV 2.0 WebSocket服务器将仅建立到已经指示了被连接的意图的客户端的连接，所以可以通过HbbTV WebSocket服务器针对另一客户端而执行成功的服务拒绝攻击是非常不可能的。被攻击的客户端可以简单地停止让服务器连接到其它客户端。

由于定义了服务器可拒绝对尚未连接Request-URI/Host组合的同时连接尝试，所以可能针对服务器本身尝试服务拒绝攻击。这可以通过重复地发送同一连接请求以引起错误响应或者通过发送随机连接请求以尝试通过创建许多开放流报头而耗尽服务器的资源来完成。两个技术都是用于攻击HTTP服务器的一般策略，并且不是WebSocket或HbbTV特定的。因此可预期的是任何WebSocket服务器实施方式(无论其是否是HbbTV类型的)将具有适当的缓解机制(例如通过停止发送响应或创建流报头)。

图59是用于根据本发明的实施例的当IP地址不存在时的客户端之间的连接的描述的图。

图59图示出在客户端之间建立通信连接的方法。基于WebSocket的上述应用间通信方法可使得WebSocket服务器能够连接应用(其URI路径(不包括主机名的路径)是相同的)以执行应用间通信。客户端间通信可划分在电子装置中驱动的应用(例如，TV应用)和在配套装置中驱动的应用(例如，CS应用)，从而选择性地执行应用间通信。

作为示例，在HbbTV中，可在不包括IP地址的情况下配置Request-URI。URI路径可从根(“/”)之后的指示HbbTV的保留字(“hbbtv”)开始，并且可在其之后包括组织或公司ID(org-id)和应用ID(app-id)。WebSocket服务器(网络处理器)可连接应用，其WebSocketAPI调用URI路径是相同的。

语法)GET"/hbbtv/"org-id"."app-id

示例)GET/hbbtv/org.mychannel.myapp

同时，请求连接的各客户端可使用相同端口或不同端口。当客户端使用相同端口时，WebSocket服务器在调用WebSocket API的应用的IP相同的情况下可认识到被调用的应用是HbbTV应用，并且如果IP相互不同则可认识到被调用的应用是配套装置应用。当使用相同端口时，WebSocket服务器可简化服务器实现和测试，并且发现是不必要的。

接下来，将给出客户端使用不同端口的情况的描述。这种情况指的是其中由TV驱动的应用和由配套装置驱动的应用使用相同URI路径且使用不同端口的情况。作为示例，由TV驱动的HbbTV应用可使用端口8900，并且由配套装置驱动的应用可使用端口8901。当WebSocket服务器知道TV应用和配套应用所使用的端口时，可以区别TV应用与配套应用之间的通信和配套应用间通信。当使用不同端口时，如果多个配套装置被使用同一主机请求报头连接到TV，则可通过区别配套装置和TV来容易地连接客户端。由于TV与配套装置在主机请求报头相同的同时通过经由不同端口连接到WebSocket服务器而相互通信，所以可以区别配套装置和TV。因此，就安全而言可以采取补充措施。

图60是用于根据本发明的实施例的用于应用之间的连接的备用连接的描述的图。

图60图示出电子装置100a和配套装置200a。电子装置100a的TV应用可向WebSocket服务器发送连接请求。TV应用被包括在电子装置中，并且因此WebSocket服务器可将TV应用识别为本地应用。另外，配套应用存在于电子装置外面，并且因此WebSocket服务器可将配套应用识别为远程应用。作为实施例，应用可在请求连接时使用下面的方法。

[表27]

[表28]

作为实施例，网络处理器可执行W3C WebSocket API，并且可支持最少200个同时的WebSocket连接。

网络处理器可提供由WebSocket协议规范的服务器侧执行的两个服务端点。本地端点被HbbTV应用用于到网络处理器的连接。远程端点可被另一设备的应用连接到家庭网络，并被用来包括远程配套应用或被另一HbbTV设备驱动的HbbTV应用。HbbTV应用可被连接到应用在其中操作的网络处理器的本地服务端点或者同一家庭网络中的另一混合终端的远程服务端点。优选的是网络处理器未被连接到家庭网络中的另一设备的本地服务端点。例如，这可以通过放置网络处理器的本地回环(loopback)接口的本地服务端点来实现。当另一服务端点执行WebSocket协议规范的服务侧且HbbTV应用或配套应用使用服务端点时，混合终端不应将服务端点放置在与另一服务端点相同的主机和端口组合上。

用于应用之间的服务端点的基本URL可以是WebSocket URL。WebSocket URL可定义服务端点的主机、端口、安全以及资源名称。客户端需要连接到由服务端点的WebSocketURL指定的主机和端口。由客户端在初始协议请求中使用的资源名称符合ANBF语法。

resource-name＝base-url-resource-name app-endpoint

Base-url-resource-name是从服务端点的WebSocket URL导出的资源名称。app-endpoint是应用规范且可被用于对应于客户端的客户端连接匹配过程。可通过WebSocket协议来递送相应客户端的消息。app-endpoint可由应用开发者选择以避免冲突。因此，app-endpoint从以与HbbTV应用、配套应用或其开发者唯一地相关的相反DNS符号格式化的ID开始。混合终端可支持包括在资源名称中以1000字符的最小程度许可的某个字符和WebSocket协议规范的app-endpoint。

服务端点可支持来自客户端的至少十个同时TCP套接字连接。当客户端尝试打开服务器与TCP套接字之间的连接时，服务器可拒绝请求，如果服务器不能管理同时连接的话。否则，服务器可批准TCP套接字连接，并且开始WebSocket协议握手。当服务器从客户端接收到请求握手时，服务器可不立即用握手响应进行响应。替代地，服务器可等到连接被配对或者客户端电连接被取消。在这种状态下，可将备用连接配置为连接。当服务器尝试执行超时时，服务器可用504网关超时响应进行响应。

服务器可忽视由客户端发送的请求握手的某个起点报头。客户端在请求客户端之间的连接时可不使用Sec-WebSocket-Protocol报头。服务器可忽视用于客户端之间的连接的请求中的Sec-WebSocket-Protocol报头。服务器可不批准用于使用Sec-WebSocket-protocol报头的协议扩展的来自客户端的请求。当客户端使用Sec-WebSocket扩展报头时，服务器可不使用在WebSocket协议规范中定义的方案来建立连接。

如图60中所示，充当客户端的HbbTV应用可尝试与本地服务端点的连接，其具有“org.mychannel.myapp”的app-endpoint和/hbbtv/的base-url-resource-name。与配套装置的连接可被保持在备用状态，因为配套应用尚未使用同一app-endpoint而被链接到应用之间的通信。

图61是用于根据本发明的实施例的用于与第二客户端的连接的新连接请求的描述的图。

参考图61，HbbTV应用(客户端)被连接到配套装置200a的配套应用(客户端)。另外，HbbTV应用可生成用于另一客户端的另一流报头。

服务器不能许可来自具有同一app-endpoint的同一原始IP地址的一个或多个同时备用连接。当成功连接时或者当终止之前的IP地址的客户端使用同一app-endpoint发布另一连接请求时，服务器可用403Forbidden响应进行响应。

客户端可期望使用不同的资源名称组合通过同一服务端点进行的多个同时客户端之间的连接的建立。客户端不能在用以连接服务端点的备用成功或者超时或连接被取消之前尝试从现有服务端点请求另一连接。客户端的此操作可由WebSocket协议规范定义。

根据图8，当客户端期望与一个或多个客户端通信时，客户端可等到现有备用连接被配对为止。在这种情况下，可向服务器发布附加连接请求直至达到可处理客户端间通信的最大数目为止。换言之，HbbTV应用可生成新的备用连接请求以允许建立应用间通信。

同时，客户端可在URI路径中包括IP地址。

图62是用于根据本发明的实施例的当包括IP地址时的第一客户端的设置的描述的图。

作为实施例，上述URI路径在根(“/”)之后从指示HbbTV的保留字(“hbbtb”)开始，并且可在其之后包括组织/公司ID(org-id)和应用ID(app-id)。期望执行应用间通信的应用可向URI路径添加被驱动装置的IP地址以指定目标应用。WebSocket服务器可连接应用，根据被用于通信的IP，该应用的WebSocket API调用URI路径是相同的。

语法)GET"/hbbtv/"target IP"/"org-id"."app-id

示例)GET/hbbtv/1.1.1.1/org.mychannel.myapp

作为实施例，TV应用A可在IP 1.1.1.1中被驱动，配套应用B可在IP 1.1.1.2(第一用户终端)中被驱动，并且配套应用C可在IP 1.1.1.3(第二用户终端)中被驱动。在这种情况下，TV应用A可尝试与配套应用C通信。TV应用A可包括其中在被包括在WebSocket请求中的URI路径中驱动配套应用C的IP(1.1.1.3)。另外，配套应用C可在被包括在WebSocket请求中的URI路径中包括TV应用A的IP(1.1.1.1)。

根据图62，URI路径可对应于hbbtv/192.0.2.7/org.mychannel.myapp HTTP/1/1。在这里，192.0.2.7可对应于目标应用的IP地址。192.0.2.110可对应于其IP地址。另外，org.mychannel.myapp可对应于应用ID。

图63是用于根据本发明的实施例的当包括IP地址时的第一客户端和第二客户端的设置的描述的图。

WebSocket服务器可从每个客户端接收参考图62所述的URI请求。参考图63，第一客户端具有192.0.2.110的IP地址，并且第二客户端具有192.0.2.7的IP地址。当第一客户端从第二客户端请求连接时，起始点(From Host(来自主机))是192.0.2.110，并且目的地(To Host(到主机))是192.0.2.7。另外，应用ID可以是org.mychannel.myapp。当第二客户端从第一客户端请求连接时，起始点(From Host(来自主机))是192.0.2.7，并且目的地(ToHost(到主机))是192.0.2.110。另外，应用ID可以是org.mychannel.myapp。亦即，第一客户端和第二客户端的起始点和目的地可彼此相对。然而，应用ID可以是相同的。WebSocket服务器可将匹配的客户端相互连接。

另外，可使用包括主机IP地址的URI路径。

例如，可如下使用URI路径。

语法)GET“/”hbbtv”/"host_address”/”org-id"."app-id,

示例)GET/hbbtv/192.0.2.7/org.mychannel.myapp.

图64是用于当包括IP地址时的到多个第二客户端的连接的实施例的描述的图。

参考图64，HbbTV具有某个IP地址且包括org.mychannel.myapp的应用ID。第一配套应用IP地址是192.0.2.7，并且第二配套应用IP地址是192.0.2.1。第一和第二配套应用的应用ID对应于org.mychannel.myapp。如上文参考图63所述，WebSocket服务器可将匹配的客户端相互连接。因此，WebSocket服务器可响应于来自各客户端的请求而将匹配的客户端相互连接。

这样，当在URI路径中使用IP地址时，两个客户端都指定要连接的对象。因此，改善了安全性，客户端可被相互连接，并且所有信息可被匹配而无需额外努力。同时，即使当在URI路径中使用IP地址时，各客户端也可使用同一端口，或者可使用不同端口。

图65是根据本发明的实施例的控制电子装置的方法的流程图。

参考图65，在S1210中，电子装置被连接到配套装置。电子装置可包括网络处理器和应用处理器。在电子装置中，应用处理器可从网络处理器请求到配套装置的连接。在从配套装置接收到连接请求时，网络处理器可将请求连接的应用处理器连接到配套装置。

如前文所述，应用处理器可对应于应用模块或应用浏览器。替换地，应用处理器可对应于HbbTV应用。网络处理器可被实现为网络模块。替换地，网络处理器可对应于WebSocket服务器。当网络处理器被实现为WebSocket服务器时，可将应用处理器和配套装置中的每一个视为一个客户端。替换地，第一客户端和第二客户端中的每一个可称为对端。

应用处理器可向网络处理器发送关于在网络处理器中操作的电子装置的信息或指示配套装置信息的主机请求报头信息。另外，响应于来自应用处理器的连接请求，网络处理器可生成应用处理器的流报头并将该流报头包括在流报头组中。在从配套装置接收到连接请求时，网络处理器可生成配套装置的流报头，并且将生成的流报头连接到从流报头组匹配的应用处理器的流报头。在这种情况下，网络处理器可将匹配应用处理器的流报头或配套装置的流报头从流报头组去除。同时，应用处理器可发送要连接的配套装置的IP地址，并且各应用可使用同一端口。

在S1220中，电子装置可与配套装置交换数据。通过此过程，可将电子装置连接到配套装置以执行通信。

根据本说明书的电子装置和控制方法不限于上述实施例的配置和方法，并且各实施例中的全部或某些可被选择性地组合并以各种方式改变。

图66是图示出根据本发明的实施例的主物理装置和配套物理装置的配置的图。

本发明的实施例可在陆地广播或移动广播环境中提供服务指南。另外，本发明的实施例可基于陆地广播网络与IP网络之间的连接来提供用于在下一代混合广播环境中可用的服务的服务指南。

本发明的实施例可将在下一代混合广播环境中可提供的各种服务和包括在该服务中的内容和/或组件元素告知用户。这样，用户可方便地检查、选择和欣赏服务。

本发明的实施例可将一个服务和包括在服务中的各种内容和/或组件元素结构化并形成服务与内容和/或组件元素之间的参考配置。这样，广播接收机可容易地配置和提供服务并使得用户能够容易地理解服务。

本发明的实施例可扩展一个服务和包括在该服务中的各种内容和/或组件元素被相互链接的参考配置，从而允许广播接收机和用户节省为了搜索包括在服务中的内容和/或组件元素而耗费的资源和/或时间。

本图图示出根据本实施例的主物理装置和配套物理装置的总体配置。

根据本实施例的主物理装置L25010是用于交互式服务的装置，并且一般地可对应于由配套物理装置L25020控制的装置。主物理装置可称为主装置、主接收装置、主接收机、主显示器、主屏幕等。

根据本实施例的主物理装置L25010可包括广播接口L25030、网络接口L25040、存储器单元L25050、控制单元L25060、显示单元L25070、多媒体模块L25080、储存器L25090、电源L25100和/或用户输入接口L25110。

广播接口L25030可对应于物理装置，其使得能够在广播公司与装置之间发送消息和/或数据，诸如AV流、服务指南、通知等。广播接口可从广播公司接收广播信号、信令信息、数据等。

用户接口L25040可对应于物理装置，其使得能够在装置(例如，主物理装置和配套物理装置)之间发送消息、广告和/或数据，诸如命令、请求、行为、响应等。网络接口可从互联网服务提供商接收广播服务、广播内容、信令信息、应用、数据等。

存储器单元L25050可对应于在各种类型的装置中实现的选择性的装置，并且可对应于能够临时存储各种类型的数据的易失性物理装置。

控制单元L25060是控制源装置和/或宿装置的装置，并且可对应于软件或硬件。在这里，源装置可对应于发送消息和/或数据的装置，并且宿装置可对应于接收消息和/或数据的装置。因此，根据本实施例的主物理装置和配套物理装置可对应于源装置或宿装置。

显示设备L25070可在屏幕上显示通过网络接口接收到的数据或存储在储存器中的数据。在这种情况下，显示单元可在控制单元的控制下操作。

多媒体模块L25080可再现各种类型的多媒体。多媒体模块可被包括在控制单元中或者可与控制单元分离。

储存器L25090可对应于能够存储各种类型的数据的易失性物理装置。例如，SD卡可对应于储存器。

电源L25100可对应于接收外部电力和/或内部电力以供应在控制单元的控制下的其它组件的操作所需的电力的设备。

用户输入接口L25110可对应于能够从用户接收诸如命令之类的输入的装置。

根据本实施例的配套物理装置L25020是用于交互式服务的装置，并且可对应于控制主装置的装置。一般地，配套物理装置可直接地从用户接收输入。可将配套物理装置称为配套装置、第二装置、附加装置、辅助装置、配套接收装置、配套接收机、配套显示器、第二屏幕等。

根据本实施例的配套物理装置L25020可包括网络接口、存储器单元、控制单元、显示单元、多媒体模块、储存器、电源和/或用户输入接口。

在包括在根据本实施例的配套物理装置中的组件之中，具有与包括在主装置中的组件相同的名称的组件可执行与包括在主装置中的组件相同的功能。

图67是图示出根据本发明的实施例的用于支持混合广播服务的协议栈的图。

物理层可接收陆地广播信号并将此信号转换成适当形式。

IP封装可使用从物理层获取的信息来获取IP数据报。另外，IP封装可将所获取的IP数据报转换成某个帧(例如，RS帧、GSE等)。

MPEG-2TS封装可使用从物理层获取的信息来获取MPEG-2TS。另外，MPEG-2TS封装可将所获取的MPEG-2TS转换成某个帧(例如，RS帧、GSE等)。

快速信息通道(FIC)可递送用于访问服务和/或内容的信息(例如，关于服务ID与帧之间的映射的信息等)。

信令可包括用于支持服务和/或内容的有效获取的信令信息。可用二进制和/或XML格式来表示信令信息，并且可通过陆地广播网络和/或宽带网络来发送。

可用ISO基础媒体文件格式(ISOBMFF)等来表示实时广播音频/视频(A/V)内容和数据，并且可通过陆地广播网络和/或宽带网络来实时地发送。可基于IP/UDP/FLUTE来发送NRT内容。另外，可使用DASH等通过IP网络来实时地发送实时广播A/V内容、数据和/或信令信息。在这种情况下，可响应于请求而发送实时广播A/V内容、数据和/或信令信息，或者可通过实时流式传输来发送。

本实施例可通过将通过上述协议栈递送的数据组合而为观看者提供各种增强服务，诸如交互式服务、第二屏幕服务等。

图68是图示出根据本发明的实施例的UPnP方案的行为机制的图。

首先，将给出本发明中的装置间通信的描述。

装置间通信可指代装置之间的消息/命令/呼叫/行为/请求/响应的交互。

除IP之外还可应用各种协议，诸如互联网控制消息协议(ICMP)、互联网组管理协议(IGMP)等，以便稳定地向期望的目标装置递送消息。在这种情况下，本发明不限于某个协议。

可应用各种协议，诸如超文本传输协议(HTTP)、实时传输协议(RTP)、可扩展消息传递和存在协议(XMPP)、文件传输协议(FTP)等，以便在被用于装置间通信的消息中包含各种类型的信息。在这种情况下，本发明不限于某个协议。

当递送被用于装置间通信的消息时，可使用由每个协议定义的各种组件，诸如消息报头/消息主体等。亦即，可将数据存储在每个消息组件中并递送，并且本发明不限于某个消息组件。另外，可用由每个协议定义的各种类型(串、整数、浮点、布尔值、字符、阵列、列表等)来递送由消息递送的数据。可应用诸如可扩展标记语言(XML)、超文本标记语言(HTML)、可扩展超文本标记语言(XHTML)、JavaScript对象符号(JSON)等等标记方案、文本、图像格式以便在结构上表示/递送/存储复杂内容的数据。在这种情况下，本发明不限于某个方案。

另外，可将被用于装置间通信的消息压缩并递送，并且本发明不限于某个方案的压缩技术的应用。

将给出本发明中的装置间通信的以上描述中的UPnP方案的描述。UPnP方案可对应于其中在装置间通信的以上描述中将IP-TCP/UDP-HTTP的协议组合的情况。

根据本实施例的UPnP方案的行为机制可指的是UPnP控制点t87010与UPnP装置t87020之间的通信机制。在这里，UPnP控制点t87010可对应于HTTP客户端，并且UPnP装置t87020可对应于HTTP服务器。UPnP控制点t87010可向UPnP装置t87020递送称为行为的消息类型，使得UPnP装置t87020可执行某个操作。

在这里，可将UPnP控制点t87010与UPnP装置t87020配对。可通过在各装置之间递送发现和描述的过程来执行配对。UPnP控制点t87010可通过配对过程来获取控制URL。

UPnP控制点t87010可以XML格式来表示每个行为。UPnP控制点t87010可使用在HTTP中定义的POST方法t87030来向所获取的控制URL递送行为。每个行为可对应于实际上将作为一种消息递送的数据，并且可在HTTP POST消息主体中以XML格式递送。在这里，每个行为可包括名称、宗量以及相关数据。HTTP POST消息主体可递送每个行为的名称和/或宗量。

在这种情况下，每个行为可被递送到同一控制URL。UPnP装置t87020可使用XML解析器来解析递送的行为。UPnP装置t87020可根据解析的行为来执行相应操作。

在UPnP协议中，可用名称来定义并使用每个行为。另外，在HTTP POST消息主体中递送行为名称。因此，即使当对于目标装置而言仅存在一个URL且仅使用一个HTTP POST方法时，也可交换无穷多类型的行为。

图69是图示出根据本发明的实施例的REST机制的图。

将给出本发明中的装置间通信的以上描述中的REST方案的描述。

根据本发明的所示REST机制可指代REST客户端t88010与REST服务器t88020之间的通信机制。在这里，REST客户端t88010可对应于HTTP客户端，并且REST客户端t88020可对应于HTTP服务器。类似于以上描述，REST客户端t88010向REST服务器t88020递送称为行为的一种消息，使得RST服务器t88020可执行某个操作。

在本实施例中，REST客户端t88010可通过URI向REST服务器t88020递送每个行为。行为名称在每个行为中可能是不必要的。每个行为可仅包括宗量和数据。

在这里，在HTTP方法之中，除POST之外，还可使用多个方法，诸如GET、HEAD、PUT、DELETE、TRACE、OPTIONS、CONNECT、PATCH等。另外，可定义访问执行通信的目标装置的多个URI。由于这些特性，可在不定义行为名称的情况下递送行为。可在递送发现或描述的过程中获取此REST方案所需的多个URI值。

可通过附加到URI来递送需要递送的数据或宗量，或者可通过以各种形式(XML、JSON、HTML、TEXT、IMAGE等)包括在HTTP主体中来递送。

REST服务器t88020可根据递送的行为来执行某个操作。

上述装置间通信仅仅是示例，并且在本发明中提出的所有内容不限于UPnP方案等。

图70是图示出使得广播接收机和配套装置能够交换电子服务指南(ESG)的服务的图。

ESG是一种信道或信息，其可以在某个会话中通过服务指南递送描述符等来递送，并且可为广播、无线电或其它媒体的应用提供服务指南。ESG可以菜单等形式向用户提供与服务的调度表或节目有关的信息。可通过广播信道或互联网信道(宽带)来提供ESG。

用户可通过ESG来执行操作，诸如服务提供调度、当前可用服务的入口点的发现、根据偏好的服务过滤等。内容提供商可通过ESG来表示关于处于可用状态的服务和/或内容的信息、与购买/订阅有关的信息、服务访问信息等。可将ESG称为服务指南或电子节目指南(EPG)。

在常规方案中，当用户在观看广播接收机中的广播节目的同时执行诸如ESG之类的服务指南时，ESG覆盖观看的广播，引起不便。

本发明提供了一种通过在配套装置中执行诸如ESG等服务指南而在不妨碍用户观看广播节目的情况下访问ESG信息的方案。在这种情况下，用户可在观看广播节目时访问ESG而不会经历不便。另外，如果用户使用个人配套装置来探索ESG，则可保护用户的隐私。此外，可通过经由配套装置的UI而不是麻烦的广播接收机的UI来探索ESG而增强方便性。

*714本发明可通过基于陆地广播网络与IP网络之间的连接来定义用于在下一代混合广播环境中从广播接收机向配套装置递送ESG信息的协议而解决上述问题。另外，本发明提出了一种当用户通过在配套装置中提供的ESG来选择新服务时允许通过配套装置中的信道信息递送来改变广播接收机的服务的协议。

为了便于描述而基于UPnP来描述本发明的实施例。然而，用于广播接收机与配套装置之间的通信的协议不限于此。另外，为了便于描述而使用基于XML ESG作为示例来描述本发明的实施例。然而，ESG的格式不限于此。

可将用于交换ESG的所示服务的示例称为ESG服务。

ESG服务可以是用于在广播接收机与配套装置之间交换ESG的服务。根据给定实施例，可将ESG服务的服务类型定义为atsc3.0ESG-1，并且可将ESG服务的服务ID定义为urn:atsc.org:serviceId:atsc3.0ESG。

对于ESG服务而言可能需要各装置之间的兼容性。根据给定实施例，可定义UPnP装置类型。广播接收机具有urn:atsc.org:device:atsc3.0rcvr的设备类型，并且可充当UPnP控制设备。配套装置可充当UPnP控制点。

*719下面将描述用于ESG服务的状态变量行为等。

图71是图示根据本发明的实施例的ESGData状态变量的图。

可以为上述ESG服务定义被称为ESGData的状态变量。ESGData状态变量可以是指示ESG的状态变量。ESGData状态变量可以存储通过广播/IP网络接收的ESG的ESG数据。所图示的ESGData被以XML格式创建。

ESGData状态变量可以存储表达ESG的ESG数据，即，ESG中的元素、属性和子元素。

ESGData状态变量中的service元素t54010可以是在包括在ESG中的内容中具有与由ESG所指示的服务有关的信息的元素。这个元素的下层信息的示例可以包括指示服务ID的Service@id、指示服务的版本的Service@version、指示服务名称的Service@version、与服务的描述相对应的Service.Description和/或指示服务类型的Service.ServiceType。这里，A.B可以是指B元素与A元素的下层元素相对应，并且A@a可以是指@a与A元素的下层属性相对应。

这里，与服务的下层元素相对应的Service.ServiceType(即，ServiceType元素)可以指示由该服务所指示的服务类型。根据给定实施例，0可以是未指定的，1可以是指基本TV，2可以是指基本无线电，...，14可以是指线性服务，15可以是指基于应用的服务，并且16可以是指配套屏幕服务。由这个元素指示的值可以根据实施例而变化。

ESGData状态变量中的schedule元素t54020可以是在包括在ESG中的内容中具有由ESG指示的服务/节目的时间表信息的元素。这个元素的下层信息的示例可以包括诸如指示时间表ID的Schedule@id、指示时间表版本的Schedule@version等的信息。此外，这个元素的下层信息的示例可以包括诸如指示与时间表有关的服务Schedule.ServiceReference、指示与时间表有关的互动数据的Schedule.InteractivityDataReference、指示与时间表有关的内容的Scheudule.ContentReference等。

ESGData状态变量中的content元素t54030可以是在包括在ESG中的内容中具有由ESG指示的内容信息的元素。这个元素的下层信息的示例可以包括诸如指示内容ID的Content@id、指示内容版本的Content@version、指示内容名称的Content.Name、与内容的描述相对应的Content.Description、指示内容的再现开始时间的Content.StartTime、指示内容的再现结束时间的Content.EndTime等的信息。此外，与content元素的下层元素相对应的ComponentReference可以包括引用与内容有关的内容的组件的信息。以这种方式，可以验证相关组件，并且可以参考与ESG中的组件有关的信息。

ESGData状态变量中的component元素t54040可以是在包括在ESG中的内容中具有由ESG指示的内容的组件信息的元素。这个元素的下层信息的示例可以包括诸如指示组件ID的Component@id、指示组件版本的Component@version等的信息。此外，这个元素的下层信息的示例可以包括诸如指示组件的语言的Language、指示组件的长度的Length、指示组件的评级的ParentalRating、指示组件的类型的ComponentType、指示组件的作用的ComponentRole、指示由组件作为目标的装置的TargetDevice元素等的信息。此外，可以取决于组件是否对应于可再现的视频、音频、隐藏字幕或应用在这个元素中包括诸如PresentableVideoComponent、PresentableAudioComponent、PresentableCCComponent、PresentableAppComponent等的信息。

根据给定实施例，可以使用事件方案或行为方案将ESGData状态变量递送给配套装置。

上述元素、属性等仅仅是ESGData的示例，并且可以根据ESG的配置、格式等添加、改变或者删除ESGData中的元素/属性等。

图72是图示根据本发明的另一实施例的ESGData状态变量的图。

所图示的ESGData状态变量与上述ESGData状态变量类似。然而，所图示的ESGData状态变量与上述ESGData状态变量不同之处在于component元素被包括作为content元素的下层元素。

多个组件被组合以配置一条内容，并且因此component元素可以被包括作为content元素的下层元素。此外，其中支持每个组件的设备的能力可以被定义为下层元素DeviceCapability并且被包括作为component元素的下层元素。

图73是图示根据本发明的实施例的使用事件方案将ESGData状态变量递送给配套装置的处理的图。

首先，图示的CD可以是指配套装置，并且图示的主装置(PD)可以是指接收机或广播接收机。本实施例假定两个设备被配对。此外，假定配套装置订阅上述ESG服务。在这种初始状态t56010下，ESGData状态变量可以没有值。

在t56020中，服务/内容提供方可以通过广播网络或宽带信道来运送ESG。可以通过接收机的接收单元或网络接口来接收ESG。这里，接收单元可以对应于上述广播接口或调谐器。

在t56030中，接收机可以发信号通知所接收到的ESG。在t56040中，可以将ESG数据存储在ESGData状态变量中。

在t56050中，可以通过事件将ESGData递送给配套装置。接收到ESGData状态变量的配套装置可以在t56060中解析ESGData状态变量，然后可以在t56070中根据解析的值通过UI使ESG展示给配套装置。在这种情况下，为了向用户示出ESG，可以以配套装置的负水平表达UI或者在配套装置的应用中表达UI。

在配套装置中表达ESG的方案可以包括各种实施例。根据给定实施例，配套装置可以响应于所接收到的ESG以任何形式直接使ESG展示给用户。根据另一实施例，响应于所接收到的ESG，配套装置可以向用户发送通知消息，并且可以响应于由用户执行而使ESG展示。根据另一实施例，响应于所接收到的ESG，配套装置可以使ESG信息保持在后台中，并且在用户直接执行能够在期望的时间查看ESG的应用时使ESG展示给用户。

图74是图示根据本发明的实施例的LastChangedESGData状态变量的图。

可以为上述ESG服务定义被称为LastChangedESGData的状态变量。如上文所述，如果整个ESG被递送给配套装置，则即便当ESG数据的仅一部分改变了时也可能递送所有ESG数据。因此，它可能是低效的。在这方面，可以定义仅存储经改变的ESG数据的LastChangedESGData状态变量。当与先前的ESG相比时，LastChangedESGData状态变量可以仅将添加/改变/删除的ESG数据存储在重新接收的ESG中。

在t57010中，LastChangedESGData状态变量可以包括addition元素。时这个元素可以存储与先前的ESG数据相比在重新接收的ESG中的添加的ESG数据。新添加的ESG数据，即，元素/属性，可以作为这个元素的子元素被存储。例如，当与具有新服务ID的新服务有关的ESG数据被添加到新接收的ESG时，可以在addition元素的下层树中包括与新服务有关的元素或属性。在所图示的实施例中，新添加了具有ID为“atsc.org/esg/service/3”的服务。因此，能够理解的是，服务的service元素被包括addition元素中。此外，具有名称为ABC的服务是以“atsc.org/esg/service/4”的ID新添加的。因此，能够理解的是，服务的service元素被包括addition元素中。此外，可以在这个元素中包括诸如Service、Content、Schedule等的信息。

在t57020中，LastChangedESGData状态变量可以包括modification元素。这个元素可以存储与先前的ESG数据相比在新接收的ESG中的改变的ESG数据。改变的ESG数据，即，元素/属性，可以作为这个元素的子元素被存储。例如，当具有ID为“atsc.org/esg/schedule/3”的时间表的下层信息改变了时，可以在modification元素中存储该时间表的schedule元素。此外，可以在这个元素中包括诸如Service、Content、Schedule等的信息。

在t57030中，LastChangedESGData状态变量可以包括deletion元素。这个元素可以存储与先前的ESG数据相比在新接收的ESG中的删除的ESG数据。删除的ESG数据，即，元素/属性，可以作为这个元素的子元素被存储。例如，当具有ID为“atsc.org/esg/content/1”和“atsc.org/esg/content/2”的content元素被从新接收的ESG中删除时，可以将所对应的内容的content元素存储在deletion元素中。此外，可以在这个元素中包括诸如Service、Content、Schedule等的信息。

根据给定实施例，可以使用事件方案或行为方案将LastChangedESGData状态变量递送给配套装置。如果使用事件方案来递送LastChangedESGData状态变量，则可以在该状态变量的值改变了时将这个状态变量递送给配套装置。如果使用行为方案来递送LastChangedESGData状态变量，则LastChangedESGData状态变量可以被配置为在接收对这个状态变量的值的请求的时间点的最新ESG数据的改变，并且可以被递送给配套装置。

配套装置可以参考所接收到的LastChangedESGData状态变量仅更新与先前存储的ESG相比改变的ESG数据。以这种方式，当与整个ESG被递送的情况相比时可以执行高效的递送。

上述元素、属性等仅仅是LastChangedESGData的示例，并且可以根据ESG的配置、格式等进一步添加、改变或者删除LastChangedESGData中的元素/属性等。

图75是图示根据本发明的实施例的ESG数据根据GetESGData行为被递送给配套装置的处理的图。

如上文所述，可以使用事件方案来将ESGData状态变量递送给配套装置。然而，当每当ESG在接收机侧改变而执行对配套装置的事件时，网络可能过载或者配套装置侧可能负担重。因此，可以定义GetESGData()行为，使得能够只有当配套装置想要时才递送ESG数据。

GetESGData()行为可以是用于在行为方案中将ESGData状态变量递送给配套装置的ESGData状态变量的行为。换句话说，当配套装置请求接收机通过这个行为来发送ESG数据时，接收机可以将ESGData状态变量递送给配套装置。这个行为的输入宗量可能不存在，并且这个行为的输出宗量可以是ESGData状态变量。

可以在用户期望在配套装置中查看ESG并且执行ESG应用等时执行GetESGData()行为。在这种情况下，作为行为的结果而接收ESG数据，并且可以通过ESG应用使所接收到的ESG数据展示。此外，根据给定实施例，可以使用周期性轮询方案来执行GetESGData()行为以将ESG数据存储在配套装置中，并且然后可以响应于ESG应用的执行而使所存储的ESG数据展示给用户。

即便当ESGData状态变量支持事件方案时也可以同时支持GetESGData()行为。然而，在这种情况下，当每当ESG数据改变时使用事件方案来接收ESG数据，并且再次通过该行为接收ESG数据时，可能在ESG数据之间存在重叠。因此，当同时支持行为方案和事件方案时，能够采用只有当订阅初始ESG服务时才使用事件方案来接收ESG数据、并且然后周期性地或者在ESG应用被执行时使用GetESGData()行为来接收ESG数据的策略。

首先，在本实施例中，假定两个装置先前被配对。此外，假定配套装置订阅上述ESG服务。

在t58010中，接收机可以具有ESG数据。可以将ESG数据存储在ESGData状态变量中。在t58020中，用户可以采取执行ESG应用的特定行为等。该特定行为可以是使用ESG数据的特定行为。

在t58030中，配套装置可以通过执行GetESGData()行为从接收机请求ESGData状态变量。在t58040中，接收机可以与响应于请求而发送200OK的回调同时地将作为GetESGData()行为的输出变量的ESGData状态变量输出给配套装置。

在t58050中，配套装置可以解析所接收到的ESG数据，并且通过ESG应用使用ESG数据来执行展示操作。当ESG数据被展示时，配套装置可以像在上述实施例中一样立即使ESG数据展示，或者可以在使ESG数据展示之前存储ESG数据。

所图示的实施例是当用户执行特定行为时执行GetESGData()行为的实施例。然而，根据给定实施例，如上所述，可以周期性地执行GetESGData()行为(不管特定行为如何)，并且然后，可以在用户在特定时间点执行ESG应用等时通过该行为使所接收且存储的ESG数据展示。

*762

图76是图示根据本发明的实施例的根据GetServiceIds和GetESGbyServiceIds行为将ESG数据递送给配套装置的处理的图。

可以将仅与特定服务有关的ESG数据递送给配套装置，以便使广播接收机与配套装置之间的网络负担和/或用于在配套装置中处理整个ESG数据的负担最小化。为此目的，可以定义ServiceIdsList状态变量和A_ARG_TYPE_ESGData_by_ServiceIds状态变量。

ServiceIdsList状态变量可以是用于将由ESG描述的服务的ID递送给配套装置的状态变量。换句话说，这个状态变量可以包括被解析并存储在接收机中的ESG数据中的服务ID信息。这个状态变量可以具有字符串的列表或URI的列表的类型。这里，可以忽视URI的类型。根据给定实施例，可以以CSV形式表达这个状态变量。例如，这个状态变量可以用atsc.org/esg/service/1、atsc.org/esg/service/2等加以表达。

A_ARG_TYPE_ESGData_by_ServiceIds状态变量可以是用于存储ESG的部分ESG数据的状态变量。可以将这个状态变量定义成仅将部分ESG数据递送给配套装置。这个状态变量可以具有用于表达ESGData状态变量的特定形式的标记语言的分段类型。例如，当ESGData状态变量是XML文档时，这个状态变量可以具有XML分段类型。

可以使用上述状态变量将包括在接收机中的ESG的服务ID首先递送给配套装置，并且可以将响应于递送而请求的仅必要的ESG数据递送给配套装置。为此目的，可以定义GetServiceIds行为和GetESGbyServiceIds行为。

GetServiceIds行为可以是用于使得配套装置能够从接收机接收服务ID的行为。接收机可以在与由接收机中包括的ESG描述的服务有关的信息中以列表形式递送服务ID。这个行为的输入变量可能不存在，并且这个行为的输出变量可以是ServiceIdsList状态变量。

可以在用户期望在配套装置中查看ESG并且执行ESG应用等时执行GetServiceIds行为。在这种情况下，作为行为的结果而接收ESG数据，并且可以通过ESG应用使所接收到的ESG数据展示。此外，根据给定实施例，可以使用周期性轮询方案来执行GetServiceIds行为以将ESG数据存储在配套装置中，并且然后可以响应于ESG应用的执行而使所存储的ESG数据展示给用户。

可以将GetESGbyServiceIds行为定义成使得配套装置能够从接收机仅接收与特定服务相对应的ESG数据。配套装置可以通过利用通过GetServiceIds行为接收到的服务ID的列表来对期望的服务的服务ID进行分类。此后，可以使用服务ID的列表作为输入变量来执行这个行为，以便接收所期望的服务的ESG数据。结果，配套装置可以接收到与所期望的服务有关的ESG数据。这个行为的输入变量可以是ServiceIdsList状态变量，并且这个行为的输出变量可以是A_ARG_TYPE_ESGData_by_ServiceIds状态变量。

可以在用户期望在配套装置中查看ESG并且执行ESG应用等时执行GetESGbyServiceIds行为。在这种情况下，作为行为的结果而接收ESG数据，并且可以通过ESG应用使所接收到的ESG数据展示。此外，根据给定实施例，可以使用周期性轮询方案来执行GetServiceIds行为以将ESG数据存储在配套装置中，并且然后可以响应于ESG应用的执行而使所存储的ESG数据展示给用户。

根据给定实施例，当在GetESGbyServiceIds行为中输入变量被设置为“*”时，所有ESG数据可以被设置成都被请求而不管服务ID。此外，根据给定实施例，当在GetESGbyServiceIds行为中输入变量被设置为“空”时，当前查看的服务的ESG数据可以被设置成被请求。

首先，在本实施例中，假定两个装置先前被配对。此外，假定配套装置订阅上述ESG服务。

在t59010中，接收机可以具有ESG数据。可以将ESG数据存储在ESGData状态变量中。在t59080中，存储在ESGData状态变量中的ESG数据可以是与由“atsc.org/esg/service/1”和“atsc.org/esg/service/2”标识的两个服务有关的ESG数据。在t59020中，用户可以采取执行ESG应用的特定行为等。该特定行为可以是使用ESG数据的特定行为。

在t59030中，配套装置可以通过GetServiceIds行为来请求服务ID的列表。在t59040中，接收机可以将ServiceIdsList与200OK一起输出给配套装置。在本实施例中，ServiceIdsList的值可以等于(atsc.org/esg/service/1、atsc.org/esg/service/2)。

在t59050中，当由用户或配套装置所期望的特定服务是由“atsc.org/esg/service/1”标识的服务时，可以使用“atsc.org/esg/service/1”作为输入变量来执行GetESGbyServiceIds。在t59060中，接收机可以将A_ART_TYPE_ESGData_by_ServiceIds与200OK一起输出给配套装置。在本实施例中，A_ART_TYPE_ESGData_by_ServiceIds的值可以是与在t59090中由“atsc.org/esg/service/1”标识的服务有关的ESG数据。如该图中所图示，不仅具有atsc.org/esg/service/1作为服务ID值的service元素而且具有atsc.org/esg/service/1作为参考值的schedule元素以及content元素可以被包括在输出变量中。这里，schedule元素和content元素可以是与由atsc.org/esg/service/1所标识的服务有关的时间表和内容信息。

在t59070中，配套装置可以解析所接收到的ESG数据，并且通过ESG应用使用ESG数据来执行展示操作。当ESG数据被展示时，配套装置可以像在上述实施例中一样立即使ESG数据展示，或者可以在使ESG数据展示之前存储ESG数据。

所图示的实施例对应于用户执行特定行为的情况。然而，如上所述，可以首先执行一个行为(不管特定行为如何)，并且然后可以在用户在特定时间点执行ESG应用等时通过该行为使先前接收且存储的ESG数据展示。

图77是图示根据本发明的实施例的根据GetCurrentServiceId行为将ESG数据递送给配套装置的处理的图。

由接收机当前查看的服务的ESG数据可能需要被递送给配套装置。为此目的，可以将当前查看的服务的服务ID递送给配套装置。为此目的，可以定义CurrentServiceId状态变量和GetCurrentServiceId行为。

CurrentServiceId状态变量可以将在接收机中当前查看的服务的服务ID存储在接收机的ESG数据中。这个状态变量可以对应于字符串或特定URI类型。

GetCurrentServiceId行为可以是用于使得配套装置能够接收在接收机中当前查看的服务的服务ID的行为。这个行为的输入变量可能不存在，并且这个行为的输出变量可以是CurrentServiceId状态变量。

可以在用户期望在配套装置中查看ESG并且执行ESG应用等时执行GetCurrentServiceId行为。在这种情况下，作为行为的结果而接收ESG数据，并且可以通过ESG应用使所接收到的ESG数据展示。此外，根据给定实施例，可以使用周期性轮询方案来执行GetCurrentServiceId行为以将ESG数据存储在配套装置中，并且然后可以响应于ESG应用的执行而使所存储的ESG数据展示给用户。

首先，在本实施例中，假定两个装置先前被配对。此外，假定配套装置订阅上述ESG服务。

在t60010中，接收机可以具有ESG数据。可以将ESG数据存储在ESGData状态变量中。在t60090中，存储在ESGData状态变量中的ESG数据可以是与由“atsc.org/esg/service/1”和“atsc.org/esg/service/2”所标识的两个服务有关的ESG数据。接收机可以通过周期性地发信号通知当前查看的广播来用当前查看的服务的服务ID更新CurrentServiceId状态变量。在t60030中，用户可以采取执行ESG应用的某个行为等。该某个行为可以是使用ESG数据的某个行为。

在t60040中，配套装置可以通过GetCurrentServiceId行为来请求服务ID的列表。在t60050中，接收机可以将CurrentServiceId状态变量与200OK一起输出给配套装置。在本实施例中，CurrentServiceId状态变量的值可以等于“atsc.org/esg/service/1”。

在t60060中，配套装置可以通过执行GetESGbyServiceIds行为来请求与当前查看的服务有关的ESG数据。在本实施例中，GetESGbyServiceIds行为的输入变量可以是atsc.org/esg/service/1。在t60070中，接收机可以将A_ART_TYPE_ESGData_by_ServiceIds状态变量与200OK一起输出给配套装置。在本实施例中，A_ART_TYPE_ESGData_by_ServiceIds的值可以是与在t60100中由“atsc.org/esg/service/1”标识的服务有关的ESG数据。如该图中所图示，不仅具有atsc.org/esg/service/1作为服务ID值的service元素而且具有atsc.org/esg/service/1作为参考值的schedule元素以及content元素可以被包括在输出变量中。这里，schedule元素和content元素可以是与由atsc.org/esg/service/1标识的服务有关的时间表和内容信息。

在t60080中，配套装置可以解析接收到的ESG数据，并且通过ESG应用使用ESG数据来执行展示操作。当ESG数据被展示时，配套装置可以像在上述实施例中一样立即使ESG数据展示，或者可以在使ESG数据展示之前存储ESG数据。

所图示的实施例对应于用户执行特定行为的情况。然而，如上所述，可以首先执行一个行为(不管特定行为如何)，并且然后可以在用户在特定时间点执行ESG应用等时通过该行为使先前接收且存储的ESG数据展示。

图78是图示根据本发明的实施例的ESG数据根据SearchESG行为被递送给配套装置的处理的图。

在配套装置请求接收机递送ESG数据的情况下，配套装置可以请求接收机只有当ESG数据的某个字段具有特定值(目标值)时才递送ESG数据。为此目的，可以定义A_ART_TYPE_SearchField状态变量、A_ART_TYPE_TargetValue状态变量和SearchESG行为。

A_ART_TYPE_SearchField状态变量可以指示要由配套装置指定的特定字段。换句话说，这个状态变量可以是ESGData状态变量的元素/属性的名称的列表。例如，可以在这个状态变量中存储诸如Service@id、Service.Genre等的值。这个状态变量可以具有字符串的列表类型。这个状态变量可以被称为SearchField。

A_ART_TYPE_TargetValue状态变量可以存储由配套装置指定的某个字段的某个值，即，目标值。可以在所指示的某个字段具有目标值时使用这个目标值。可以使用这个目标值来检索接收机的ESG数据。这个状态变量可以具有字符串的列表类型。这个状态变量可以被称为TargetValue。

SearchESG行为可以是用于使得配套装置能够利用并请求接收机中的ESG数据的行为。某个字段(SearchField)和/或目标值(TargetValue)可以被定义为这个行为的输入变量。接收机可以基于某个字段是否具有目标值来利用ESG数据。当接收机利用满足所有条件的ESG数据时，接收机可以向配套装置输出所有相关的ESG数据。当数据不匹配时，将不输出任何东西。根据给定实施例，只有当ESG数据的一部分匹配时才可以递送ESG信息。

A_ART_TYPE_ESGData状态变量可以被定义为输出值。这个状态变量可以是与上述A_ART_TYPE_ESGData_by_ServiceIds状态变量类似地存储ESG的部分ESG数据。A_ART_TYPE_ESGData状态变量可以被称为SearchedESGData。

可以在用户期望在配套装置中查看ESG并且执行ESG应用等时执行SearchESG行为。在这种情况下，作为行为的结果而接收ESG数据，并且可以通过ESG应用使所接收到的ESG数据展示。此外，根据给定实施例，可以使用周期性轮询方案来执行SearchESG行为以将ESG数据存储在配套装置中，并且然后可以响应于ESG应用的执行而使所存储的ESG数据展示给用户。

首先，在本实施例中，假定两个装置先前被配对。此外，假定配套装置订阅上述ESG服务。

在t61010中，接收机可以具有ESG数据。可以将ESG数据存储在ESGData状态变量中。在t61050中，存储在ESGData状态变量中的ESG数据可以是与由“atsc.org/esg/service/1”来标识并且具有Drama的Service.Genre值的服务以及由“atsc.org/esg/service/2”来标识并且具有体育的Service.Genre值的服务有关的ESG数据。

在t61020中，配套装置可以使用SearchESG行为来请求ESG数据。这里，该行为的输入变量可以等于(“Service@id,Service.Genre”、“atsc.org/esg/service/1,Drama”)以便利用服务ID是atsc.org/esg/service/1并且service元素的子元素genre的值是Drama的ESG数据。

在t61030中，接收机可以利用和所对应的条件匹配的ESG数据，并且将该ESG数据与200OK一起输出给配套装置。在本实施例中，可以输出和所对应的条件匹配的与由“atsc.org/esg/service/1”所标识的服务有关的ESG数据。

在t61040中，配套装置可以解析所接收到的ESG数据，并且通过ESG应用使用ESG数据来执行展示操作。当ESG数据被展示时，配套装置可以像在上述实施例中一样立即使ESG数据展示，或者可以在使ESG数据展示之前存储ESG数据。

图79是图示根据本发明的实施例的用于根据DoAuthenticationForESG行为来递送ESG数据的认证处理的图。

当在接收机与配套装置之间交换ESG数据时，非意图的应用(例如，用于入侵的应用)可能请求ESG数据。为了防止这种情况，可能需要用于安全的认证过程。为此目的，可以定义CompanionDeviceId状态变量、CompanionDeviceAppId状态变量、CompanionDeviceAppVersion状态变量、PrimaryDeviceId状态变量以及DoAuthenticationForESG行为。

CompanionDeviceId状态变量可以是用于存储配套装置的ID信息的状态变量。可以在这个状态变量中存储用于区分配套装置的唯一值。MAC地址等可以被用作装置ID，并且可以为了安全对这个MAC地址进行加密(例如，散列MAC地址)。这个状态变量可以对应于字符串或特定URI类型。

CompanionDeviceAppId状态变量可以是用于存储能够被执行以在配套装置中使用ESG的应用的ID信息的状态变量。这里，应用可以对应于包括配套装置的本机应用或基于浏览器的应用的概念。这个变量可以对应于字符串或特定URI类型。

CompanionDeviceAppVersion状态变量可以是用于存储能够被执行以在配套装置中使用ESG的应用的版本信息的状态变量。接收机可以使用这个版本信息来确定是否提供ESG信息。这个状态变量可以对应于hexBinary或整数类型。

PrimaryDeviceId状态变量可以对应于用于存储接收机(即，主装置)的装置ID信息的状态变量。配套装置可以使用这个状态变量来区分接收机。配套装置可以使用这个状态变量来确定是否从非意图的接收机接收到信息或者当在家庭网络中找到多个接收机时确定请求ESG的特定接收机。这个变量可以对应于字符串或特定URI类型。

DoAuthenticationForESG行为可以是用于在配套装置从接收机请求ESG数据之前执行用于安全的认证过程的行为。可以通过这个认证过程来确定是否能够交换ESG数据。配套装置的ID、配套装置的应用ID和/或配套装置的应用版本信息可以作为输入变量被输入并且发送给接收机。这个信息可以被称为认证信息。在接收到认证信息时，接收机可以确定请求ESG数据的配套装置，并且确定ESG的应用是否请求ESG数据。当从正常配套装置的应用请求ESG数据时，接收机可以向配套装置输出接收机的装置ID。配套装置可以参考接收到的接收机的ID来验证接收机是否是配套装置意图从其请求ESG的对象。在这个认证过程结束之后，可以使用本发明中所提出的诸如行为/事件等的机制来接收实际的ESG数据。这个行为的输入变量可以对应于CompanionDeviceId、CompanionDeviceAppId以及CompanionDeviceAppVersion状态变量，并且这个行为的输出变量可以对应于PrimaryDeviceId状态变量。

可以在用户期望在配套装置中查看ESG并且执行ESG应用等时执行DoAuthenticationForESG行为。此外，根据给定实施例，可以在周期性轮询方案中执行DoAuthenticationForESG行为以执行认证过程。

首先，在本实施例中，假定两个装置先前被配对。此外，假定配套装置订阅上述ESG服务。

在t62010中，接收机可以具有ESG数据。可以将ESG数据存储在ESGData状态变量中。在t62020中，用户可以采取执行ESG应用的特定行为等。该特定行为可以是使用ESG数据的特定行为。

在t62030中，配套装置可以执行DoAuthenticationForESG行为。以这种方式，可以将认证信息递送给接收机。在t62040中，接收机可以使用所接收到的认证信息来确定配套装置是否被认证。当配套装置被认证时，在t62050中接收机可以将接收机的装置ID与200OK一起输出给配套装置。在t62060中，配套装置可以使用所接收到的接收机的ID来确定接收机是否是配套装置能够从其请求ESG数据的接收机。

此后，在t62070和t62080中，可以根据本发明的实施例请求和接收ESG数据。在t62070中配套装置可以解析所接收到的ESG数据，并且通过ESG应用使用ESG数据来执行展示操作。当ESG数据被展示时，配套装置可以像在上述实施例中一样立即使ESG数据展示，或者可以在使ESG数据展示之前存储ESG数据。

所图示的实施例对应于用户执行特定行为的情况。然而，如上所述，可以首先执行一个行为(不管特定行为如何)。此后，当用户在某个时间点执行ESG应用等时，认证过程预先结束，并且因此可以立即执行用于递送ESG数据的操作。

图80是图示根据本发明的另一实施例的根据GetServiceIds和GetESGbyServiceIds行为与设备认证同时地将ESG数据递送给配套装置的处理的图。

如上文所述，可以为认证定义单独的行为。本实施例可以允许通过在无需定义单独的行为的情况下扩展现有行为来与认证同时地实现现有行为的原始目的。这里，要扩展的行为可以是本发明中引入的所有行为。在要扩展的行为中，除先前定义的输入/输出变量之外，可以添加CompanionDeviceId、CompanionDeviceAppId、CompanionDeviceAppVersion状态变量作为输入变量，并且可以添加PrimaryDeviceId状态变量作为输出变量。

本实施例扩展GetServiceIds行为和GetESGbyServiceIds行为。本发明不限于行为的扩展。

可以将GetServiceIds行为扩展成除具有现有的ServiceIdsList状态变量之外还具有CompanionDeviceId、CompanionDeviceAppId、CompanionDeviceAppVersion状态变量作为输入变量并且具有PrimaryDeviceId状态变量作为输出变量。接收机可以根据这个行为接收认证信息，并且在接收机确定能够递送ID时将服务的ID与接收机的装置ID一起递送给配套装置。配套装置可以参考所接收到的接收机的装置ID来确定是否能够使用所接收到的服务ID。

可以将GetESGbyServiceIds行为扩展成具有除现有的ServiceIdsList状态变量之外还具有CompanionDeviceAppId和CompanionDeviceAppVersion状态变量作为输入变量并且具有除现有的A_ART_TYPE_ESGData_by_ServiceIds状态之外的PrimaryDeviceId状态变量作为输出变量。接收机可以根据这个行为接收认证信息和服务ID，并且在接收机确定能够递送ESG数据和装置ID时将相关服务的ESG数据与接收机的装置ID一起递送给配套装置。配套装置可以参考所接收到的接收机的装置ID来确定是否能够使用所接收到的ESG数据。

可以在用户期望在配套装置中查看ESG并且执行ESG应用等时执行扩展的行为。在这种情况下，作为行为的结果而接收ESG数据，并且可以通过ESG应用使所接收到的ESG数据展示。此外，根据给定实施例，可以使用周期性轮询方案来执行扩展的行为以将ESG数据存储在配套装置中，并且然后可以响应于ESG应用的执行而使所存储的ESG数据展示给用户。

首先，在本实施例中，假定两个装置先前被配对。此外，假定配套装置订阅上述ESG服务。

在t63010中，接收机可以具有ESG数据。可以将ESG数据存储在ESGData状态变量中。在t63100中，存储在ESGData状态变量中的ESG数据可以是与由“atsc.org/esg/service/1”和“atsc.org/esg/service/2”所标识的两个服务有关的ESG数据。在t63020中，用户可以采取执行ESG应用的特定行为等。该特定行为可以是使用ESG数据的某个行为。

在t63030中，配套装置可以通过GetServiceIds行为来请求服务ID的列表。以这种方式，可以将认证信息递送给接收机。在t63040中，接收机可以使用认证信息来确定配套装置是否被认证。当配套装置被认证时，在t63050中接收机可以将ServiceIdsList与200OK一起输出给配套装置。在本实施例中，ServiceIdsList的值可以等于(atsc.org/esg/service/1、atsc.org/esg/service/2)。在这种情况下，可以递送接收机的装置ID。在t63060中，配套装置可以使用所接收到的接收机的ID来确定接收机是否是配套装置能够从其请求ESG数据的接收机。

在t63070中，当由用户或配套装置所期望的特定服务是由“atsc.org/esg/service/1”标识的服务时，可以使用“atsc.org/esg/service/1”作为输入变量来执行GetESGbyServiceIds。在这种情况下，可以将认证信息递送给接收机。根据给定实施例，这个认证处理可以被认为是重叠处理并且被省略。当认证处理被省略时，可以执行现有的一般GetESGbyServiceIds行为。当配套装置被认证时，在t63080中接收机可以将A_ART_TYPE_ESGData_by_ServiceIds与200OK一起输出给配套装置。在本实施例中，A_ART_TYPE_ESGData_by_ServiceIds的值可以是与在t63110中由“atsc.org/esg/service/1”所标识的服务有关的ESG数据。如该图中所图示，不仅具有atsc.org/esg/service/1作为服务ID值的service元素而且具有atsc.org/esg/service/1作为参考值的schedule元素以及content元素可以被包括在输出变量中。这里，schedule元素和content元素可以是与由atsc.org/esg/service/1标识的服务有关的时间表和内容信息。

在t63090中，配套装置可以解析所接收到的ESG数据，并且通过ESG应用使用ESG数据来执行展示操作。当ESG数据被展示时，配套装置可以像在上述实施例中一样立即使ESG数据展示，或者可以在使ESG数据展示之前存储ESG数据。

所图示的实施例对应于用户执行特定行为的情况。然而，如上所述，可以首先执行一个行为(不管特定行为如何)，并且然后可以在用户在某个时间点执行ESG应用等时通过该行为使先前接收且存储的ESG数据展示。

图81是图示根据本发明的实施例的根据GetService行为将ESG数据递送给配套装置的处理的图。

在ESG数据中的服务中，可能不太频繁地更新(添加/删除等)新服务。因此，对与服务有关的ESG数据的连续请求和/或与服务有关的ESG数据的递送可能导致不必要的网络过载。为了解决这个问题，可以定义NumOfServices状态变量、A_ARG_TYPE_ESGData_Service状态变量和GetService行为。此外，可以定义上述GetESGbyServiceIds行为的另一示例。

NumOfServices状态变量可以是用于存储由接收机的ESG所描述的服务的总数的状态变量。当服务列表被配置时可以参考这个状态变量的值。例如，当服务列表被配置时这个状态变量的值可以被用来验证有效性。这个状态变量可以具有整数类型。

A_ARG_TYPE_ESGData_Service状态变量可以是用于仅将与service元素相对应的ESG数据存储在接收机的ESG中的状态变量。这个状态变量可以具有用于表达ESGData状态变量的特定形式的标记语言的分段类型。例如，当ESGData状态变量是XML文档时，这个状态变量可以具有XML分段类型。

GetService行为可以是用于允许配套装置在ESG信息中从接收机接收与服务有关的ESG数据的行为。配套装置可以使用通过这个行为接收的ESG数据(service元素)来接收与特定服务有关的ESG数据(除service元素以外的ESG数据)。配套装置可以将由NumOfServices状态变量指示的服务的总数与接收到的service元素的数目进行比较，并且在配置服务列表时使用比较的结果。在这个处理中，可以使用上述认证过程。也就是说，GetService行为可以具有包括用于认证的附加输入/输出变量的扩展形式。根据给定实施例，可以使用排除用于认证的附加变量的GetService行为。

这个行为的输入变量的示例可以包括与上面所描述的认证信息相对应的状态变量。其输出变量的示例可以包括PrimaryDeviceId状态变量、NumOfServices状态变量以及A_ARG_TYPE_ESGData_Service状态变量。

此外，可以定义上述GetESGbyServiceIds行为的另一示例。根据另一个示例的GetESGbyServiceIds行为可以是用于允许配套装置使用特定服务的服务ID作为输入来接收与特定服务有关的其它ESG数据的行为。这里，其它ESG数据可以是排除对应的service元素的ESG数据，即，与和服务有关的内容和时间表元素相对应的ESG数据。类似地，可以以包括用于认证的上述附加变量的扩展形式定义这个行为。

可以在用户期望在配套装置中查看ESG并且执行ESG应用等时执行GetService和GetESGbyServiceIds行为。在这种情况下，作为行为的结果而接收ESG数据，并且可以通过ESG应用使所接收到的ESG数据展示。此外，根据给定实施例，可以使用周期性轮询方案来执行GetService和GetESGbyServiceIds行为以将ESG数据存储在配套装置中，并且然后可以响应于ESG应用的执行而使所存储的ESG数据展示给用户。

首先，在本实施例中，假定两个装置先前被配对。此外，假定配套装置订阅上述ESG服务。

在t64010中，接收机可以具有ESG数据。在t64100中，可以将ESG数据存储在ESGData状态变量中。在t59080中，存储在ESGData状态变量中的ESG数据可以是与由“atsc.org/esg/service/1”和“atsc.org/esg/service/2”标识的两个服务有关的ESG数据。在t64020中，用户可以采取执行ESG应用的某个行为等。该某个行为可以是使用ESG数据的某个行为。

在t64030中，配套装置执行GetService行为以请求与服务有关的ESG数据。当在t64040中接收机确定配套装置是认证的配套装置和/或应用时，在t64050中接收机可以将A_ARG_TYPE_ESGData_Service状态变量与200OK一起输出给配套装置。这里，在t64110中，A_ARG_TYPE_ESGData_Service状态变量可以在接收机的ESG数据中仅包括与service元素有关的ESG数据。在t64060中，配套装置可以通过使用接收到的接收机的装置ID来执行认证而确定信息是否是可靠的。

在t64070中，配套装置可以执行GetESGbyServiceIds行为以请求与特定服务有关的剩余的ESG数据。在本实施例中，GetESGbyServiceIds行为的ServiceIdsList输入变量值可以是atsc.org/esg/service/1。当接收机确定配套装置是认证的配套装置和/或应用时，在t64080中接收机可以与200OK一起输出A_ARG_TYPE_ESGData_by_ServiceIds状态变量。在本实施例中，所输出的A_ARG_TYPE_ESGData_by_ServiceIds状态变量可以是与在t64120中由atsc.org/esg/service/1标识的服务有关的ESG数据。如该图中所图示，可以在输出变量中包括具有atsc.org/esg/service/1作为参考值的content元素和schedule元素。可以不将由atsc.org/esg/service/1标识的service元素包括在输出变量中。

在t64090中，配套装置可以解析所接收到的ESG数据，并且通过ESG应用使用ESG数据来执行展示操作。当ESG数据被展示时，配套装置可以像在上述实施例中一样立即使ESG数据展示，或者可以在使ESG数据展示之前存储ESG数据。

所图示的实施例对应于用户执行特定行为的情况。然而，如上所述，可以首先执行一个行为(不管特定行为如何)，并且然后可以在用户在特定时间点执行ESG应用等时通过该行为使先前接收且存储的ESG数据展示。

图82是图示根据本发明的实施例的由配套装置根据SetChangeChannel行为来改变广播接收机的服务的处理的图。

可以通过UI使递送给配套装置的ESG信息展示给用户。出现在ESG中的服务可以由用户识别和选择。在这种情况下，接收机是实际上提供服务的装置，并且因此需要将用于改变服务的信息递送给接收机以改变服务。为此目的，可以定义A_ARG_TYPE_SelectedServiceId状态变量和SetChangeChannel行为。

A_ARG_TYPE_SelectedServiceId状态变量可以是用于在配套装置中存储由用户通过ESG选择的服务的服务ID的状态变量。这个状态变量可以对应于字符串或特定URI类型。

SetChangeChannel行为可以是用于使得配套装置能够改变由接收机提供的服务的行为。输入变量可以是A_ARG_TYPE_SelectedServiceId状态变量。用户可以通过配套装置来查看ESG并且选择特定服务。在这种情况下，服务的ID可以作为输入变量被存储。当行为被执行时，接收机可以根据输入变量的值将信道改变为具有服务ID的服务。可以不存在输出变量。

首先，在本实施例中，假定两个装置先前被配对。此外，假定配套装置订阅上述ESG服务。

在t65010中，接收机可以具有ESG数据。可以将ESG数据存储在ESGData状态变量中。在t65030中，用户可以采取执行ESG应用的特定行为等。该特定行为可以是使用ESG数据的特定行为。

在t65040中，配套装置可以通过上述GetESGData行为来请求ESG数据，并且接收该ESG数据。所图示的实施例对应于用户执行特定行为的情况。然而，如上所述，可以首先执行一个行为(不管特定行为如何)，并且然后可以在用户在某个时间点执行ESG应用等时通过该行为使先前接收且存储的ESG数据展示。

在t65050中，配套装置可以解析所接收到的ESG数据，并且通过ESG应用使用ESG数据来执行展示操作。当ESG数据被展示时，配套装置可以像在上述实施例中一样立即使ESG数据展示，或者可以在使ESG数据展示之前存储ESG数据。

在t65060中，用户可以在查看ESG的同时通过配套装置的UI来选择服务。例如，用户可能已尝试改变到NBCU信道。在t65070中，配套装置可以执行SetChangeChannel。通过这个行为，可以将与NBCU信道相对应的服务ID递送给接收机。

在t65080中，接收机可以将信道改变到使用所接收到的服务ID的服务。在t65090中，服务可以被改变为NBCU并且提供给用户。

图83是图示根据本发明的实施例的提供广播服务的方法的图。

根据本发明的实施例的由广播接收机提供广播服务的方法可以包括使广播接收机与配套装置配对和/或接收ESG。

在t66010中，广播接收机的网络接口单元可以与配套装置配对。这里，网络接口单元可以对应于广播接收机的上述网络接口。可以将诸如UPnP等的技术用于配对。然而，用于配对的技术不限于此。

广播接收机的接收单元可以接收ESG或特定服务指南。这里，接收单元可以对应于广播接收机的上述广播接口或网络接口。当通过广播网络来接收ESG时接收单元可以对应于广播接口，而当通过IP网络来接收ESG时接收单元可以对应于网络接口。换句话说，根据给定实施例，网络接口单元和接收单元可以对应于同一块/模块。

在本实施例中，ESG可以包括与至少一个广播服务有关的ESG数据。这里，ESG数据可以是指包括在ESG中的数据或ESG中的元素/属性。广播服务可以对应于上述服务或信道。

在根据本发明的另一实施例的提供广播服务的方法中，ESG数据可以对应于服务类型信息、时间表信息、相关内容信息，或上述至少一个广播服务的相关组件信息。ESG数据可以对应于上面所描述的service元素、schedule元素、content元素或component元素的类型属性。这里，相关内容和相关组件可以是指与由ESG所描述的服务有关的内容以及与其有关的组件。

根据本发明的另一实施例的提供广播服务的方法还可以包括将关于所接收到的ESG的改变的信息递送给配套装置。这个操作可以由上述网络接口单元执行。这里，关于与先前存储的ESG数据相比改变的信息可以包括所接收到的ESG的添加、修改或删除的ESG数据。这里，关于改变的信息可以对应于上述LastChangedESGData状态变量。经添加、修改以及删除的ESG数据可以分别对应于addition、modification以及deletion元素。

根据本发明的另一实施例的提供广播服务的方法还可以包括将包括在所接收到的ESG中的广播服务的ID列表递送给配套装置、从配套装置接收对与由至少一个ID标识的特定广播服务有关的ESG数据的请求以及将所请求的与特定广播服务有关的ESG数据递送给配套装置。可以通过上述GetServiceIds行为来递送服务ID列表。可以使用ID通过上述GetESGbyServiceIds行为来请求和递送ESG数据。

根据本发明的另一实施例的提供广播服务的方法还可以包括接收用于将当前查看的广播服务的ID递送给配套装置的对当前查看的广播服务的ID的请求、接收对与当前查看的广播服务有关的ESG数据的请求以及将所请求的与当前查看的广播服务有关的ESG数据递送给配套装置。可以通过上述GetCurrentServiceId行为来递送当前查看的广播服务的ID。可以使用ID通过上述GetESGbyServiceIds行为来请求和递送ESG数据。

根据本发明的另一实施例的提供广播服务的方法还可以包括从配套装置接收指示ESG数据的特定字段的搜索字段以及该特定字段的目标值、由控制单元对由搜索字段指示的特定字段具有目标值的ESG数据进行分类以及将经分类的ESG数据递送给配套装置。搜索字段以及特定字段的目标值可以分别对应于上述A_ART_TYPE_SearchField状态变量和A_ART_TYPE_TargetValue状态变量。可以通过上述SearchESG行为来对ESG数据进行分类和递送。这里，控制单元可以对应于广播接收机的主物理装置的上述控制单元。

根据本发明的另一实施例的提供广播服务的方法还可以包括从配套装置接收包括配套装置的装置ID信息的配套装置的认证信息、由认证模块使用认证信息来验证配套装置是否被认证以及在配套装置的认证被确认时将广播接收机的装置ID信息递送给配套装置。这里，认证信息可以对应于上述CompanionDeviceId、CompanionDeviceAppId和/或CompanionDeviceAppVersion状态变量。广播接收机的装置ID可以对应于上述PrimaryDeviceId状态变量。可以通过上述DoAuthenticationForESG行为来执行递送认证信息、验证认证、递送装置ID等的操作。这里，认证模块可以是定位在广播接收机内部/外部以执行与上面所描述的认证有关的操作的块/模块。根据给定实施例，认证模块可以与上述控制单元或网络接口合并。

根据本发明的另一实施例的提供广播服务的方法还可以包括将ID列表递送给配套装置、从配套装置接收对包括配套装置的认证信息的ID列表的请求、由认证模块使用认证信息来验证配套装置是否被认证，以及在配套装置的认证被确认时将广播接收机的ID列表和装置ID信息递送给配套装置。这个实施例可以对应于GetServiceIds行为被扩展使得能够在通过服务ID列表递送ESG的上述实施例中执行认证的情况。

根据本发明的另一实施例的提供广播服务的方法还可以包括从配套装置接收用于基于所递送的ESG数据改变当前查看的广播服务的请求，以及由控制单元响应于用于改变广播服务的请求而在广播接收机中改变所查看的广播服务。可以接收对改变的请求，并且可以基于该请求通过上述SetChangeChannel行为来改变服务。

可以从配套装置的观点描述提供广播服务的上述方法。本发明包括从配套装置的观点执行上述实施例的情况。例如，配套装置可以接收关于ESG的改变的信息，请求服务的ID列表，并且使用ID列表的ID来接收相关ESG数据。此外，配套装置可以请求当前查看的服务的ID，并且使用该ID来接收相关ESG数据。配套装置可以将指示特定字段和特定值的搜索字段递送给接收机以接收匹配ESG数据，并且向接收机发送认证信息以执行认证。此外，配套装置可以请求当前查看的服务的改变。与接收机的通信可以由配套装置内部/外部的上述网络接口来执行。诸如与搜索字段有关的操作、与对服务的改变的请求的操作、与ESG数据有关的处理操作等的总体操作可以由配套装置内部/外部的上述控制单元来执行。另外，配套装置可以包括用于执行认证相关操作的认证模块。

上述相应的步骤可以被省略或者由用于执行相同或类似的操作的其它步骤代替。

图84是图示根据本发明的实施例的广播接收机的图。

根据本实施例的广播接收机可以包括网络接口单元和/或接收单元。根据本发明的另一实施例的广播接收机还可以包括控制单元和/或认证模块。已经在上面描述了相应的块、模块和单元。

根据本实施例的广播接收机以及该广播接收机内部的模块/块/单元可以执行由广播接收机提供广播服务的方法的上述实施例。

根据本发明的实施例的配套装置可以包括网络接口单元和/或接收单元。根据本发明的另一实施例的配套装置还可以包括控制单元和/或认证模块。已经在上面描述了相应的块、模块和单元。

根据本实施例的配套装置以及该配套装置内部的模块/块/单元可以执行由配套装置提供广播服务的方法的上述实施例。

广播接收机和配套装置内部的上述模块/块/单元等可以对应于用于执行存储在存储器中的连续处理的处理器，并且可以对应于被定位在根据给定实施例的设备内部/外部的硬件元件。

上述相应的模块/块/单元可以被省略或者由用于执行相同或类似的操作的其它模块/块/单元代替。

图85是图示根据本发明的实施例的基于UPnP的PD-CD架构的图。

主物理装置可以对应于TV接收机(广播接收机，PD)。配套物理装置可以对应于前述配套装置(CD)。这两个设备是物理装置并且在物理意义上可以是指PD和CD。

在这个实施例中，主物理装置可以包括主装置。在本文中，主装置可以对应于UPnP中定义的受控装置。为了简单，在以下描述中主装置将被称为受控装置。

在这个实施例中，配套物理装置可以包括主控制点。在本文中，主控制点可以对应于UPnP中定义的控制点。主控制点可以是指与主受控装置进行通信的控制点。

受控装置通常可以被定位在UPnP架构中的TV接收机处以执行各种操作。如果TV接收机加入整个网络，则受控装置可以组播通告消息或者将从PD提供的UPnP服务的描述递送给控制点。此外，受控装置可以根据事件方案将状态变量的值递送给控制点，或者可以在控制点根据行为方案请求特定操作时将信息递送给控制点。诸如TV接收机的PD可以被称为受控装置。

受控装置可以提供可以为由该受控装置提供的UPnP服务中的一个的应用管理服务和/或连接建立服务。应用管理服务可以是指与正在受控装置和控制点上运行的应用的管理有关的服务。这些服务可以包括app到app通信以及特定信息到应用的递送。在所图示的实施例中，PD apps(App#1和App#2)以及CD Apps(App#1和App#3)可以通过这些服务执行诸如与彼此通信的操作。

连接建立服务可以是与受控装置与控制点之间的连接的建立和管理有关的服务。受控装置与控制点之间的发现过程可能符合UPnP中定义的发现过程。

一旦PD加入家庭网络，PD就可以组播用于通告PD的发现消息。如果CD稍后加入网络，则CD可以向任何PD组播搜索消息(单播消息)。接收到这个搜索消息的PD能够向CD单播响应消息。能够来回地发送这些通告和搜索消息无论哪些装置(PD、CD)首先加入家庭网络以及这些装置何时加入它。并且能够周期性地发送这些消息。

在从PD接收到发现消息或搜索消息时，CD可以发送HTTP get请求消息以请求关于例如由PD提供的UPnP服务的信息。PD可以响应于HTTP get消息而向CD递送关于服务的描述信息。然后，CD可以订阅PD的服务。CD可以使用行为来获得期望的信息，发送信息，或者将使用事件方案来接收信息。

根据实施例，主装置和主控制点分别可以被称为屏幕装置和屏幕控制点。

图86是图示根据本发明的实施例的基于UPnP的PD-CD架构的图。

在这个实施例中，主物理装置(PD)可以包括主受控装置和/或配套控制点。此外，配套物理装置(CD)可以包括主控制点和/或配套受控装置。

一般而言，对于UPnP架构，受控装置的操作或功能与控制点的操作或功能不对称。也就是说，受控装置能够执行的操作在控制点情况下可能不是可能的。

为了解决这个问题，配套物理装置(CD)可以具有配套受控装置，这与具有主受控装置的物理装置(PD)的情况类似。主物理装置可以具有与其受控装置相对应的配套控制点，并且配套物理装置可以具有与其受控装置相对应的主控制点。主受控装置可以与主控制点进行通信，并且配套受控装置可以与配套控制点进行通信。

配套受控装置和配套控制点还可以交换发现消息并且执行诸如事件/行为的操作。因此，CD还可以主动地执行通信。然而，配套受控装置和配套控制点可能在操作、功能和权限方面不同于主受控装置/控制点。操作的细节和权限的范围可能取决于设计者。

根据实施例，配套受控装置和配套控制点可以被分别称为屏幕(受控)装置和屏幕控制点。

图87是图示根据本发明的另一实施例的基于UPnP的PD-CD架构的图。

在这个实施例中，主物理装置(PD)可以包括主受控装置和/或主控制点。此外，配套物理装置(CD)可以包括主控制点和/或主受控装置。

如上所述，PD和CD可以执行有关其操作的不对称功能。为了解决这个问题，架构可以被配置为使得PD除了具有主受控装置之外还具有主控制点，并且CD除了具有主控制点之外还具有主受控装置。在这种情况下，与配套受控装置/控制点执行与主受控装置/控制点的功能不同的功能的前一个实施例相比，PD和CD两者可以具有等效的主受控装置/控制点。因此，架构可以被配置为使得TV接收机和配套物理装置在与彼此进行通信时被给予相等的状态。

图88图示根据本发明的实施例的基于UPnP的PD-CD架构的交互图。

所图示的图示出前述基于UPnP的PD-CD架构的示例。在第一示例t408010中，前述PD具有受控装置，并且CD具有控制点。在第二示例t408020中，PD具有主受控装置和配套控制点，并且CD具有主控制点和配套受控装置。在第三示例t408030中，PD具有主受控装置和主控制点，并且CD具有主控制点和主受控装置。

在第一示例t408010中，受控装置可以通过UPnP事件将诸如状态变量的信息递送给控制点。同时，控制点可以通过UPnP行为向受控装置做出对信息或特定操作的请求。这个示例可以对应于最基本架构。

在第二示例t408020中，主受控装置可以与主控制点进行通信，并且配套受控装置可以与配套控制点进行通信。主受控装置可以通过UPnP事件将诸如状态变量的信息递送给主控制点。同时，主控制点可以通过UPnP行为向主受控装置做出对信息或特定操作的请求。此外，配套受控装置可以通过UPnP事件将诸如状态变量的信息递送给配套控制点。同时，配套控制点可以通过UPnP行为向配套受控装置做出对信息或特定操作的请求。如上所述，配套受控装置和配套控制点可以在操作、功能和权限方面不同于主受控装置/控制点。

在第三示例t408030中，PD和CD的主受控装置可以分别与所对应的主控制点进行通信。主受控装置可以通过UPnP事件将诸如状态变量的信息递送给主控制点。同时，主控制点可以通过UPnP行为向主受控装置做出对信息或特定操作的请求。因此，可以执行app到app通信。

图89是图示根据本发明的实施例的基于Websocket的PD-CD架构的图。

在基于Websocket的架构中，可以在正在PD和CD中执行的apps之间执行通信。基于Websocket的架构，PD可以包括Websocket服务器，并且CD可以包括相应的apps。在本文中，CD apps可以被称为Websocket客户端。

PD中的Websocket服务器可以具有用于由PD提供的相应操作/功能的端点。端点可以连接到CD apps以递送ESG，递送媒体时间线，并且使得能实现PD和CD的app之间的通信。

首先，可以在正在PD和CD中执行的app之间执行发现过程。将稍后描述发现过程。在这个过程中，可以将关于Websocket服务器的端点的信息递送给CD app。

对于每个端点，CD app以及PD的Websocket服务器可以执行握手过程。如果CD app请求握手的发起，则Websocket服务器发送对请求的响应。因此，可以通过端点连接Websocket服务器和CD app。

在Websocket架构中，一旦通过端点连接了Websocket服务器和CD app，就可以通过该端点交换信息。可以以双向方式无限制地在PD和CD的app之间中继消息。

此后，当需要断开时，CD app可以请求端点的断开(断开请求)。Websocket服务器可以对请求做出响应(断开响应)，并且可以确定到端点的连接。连接的终止可以由PD执行，或者可以在各种情形下被自动地执行。

前述过程可以是与Websocket端点交互的过程。当存在多个端点时，可以针对这些端点中的每一个独立地执行前述过程以激活必要的端点。可以针对端点同时或顺序地执行这个过程。

在这个实施例中，Websocket服务器可以具有针对每个提供的功能的端点。也就是说，可以为一个功能提供一个端点。

端点可以包括服务/内容标识端点、ESG信息端点、服务/示出/分段数据端点、媒体时间线端点、媒体回放状态端点、EAS端点和/或ApptoApp端点。

服务/内容标识端点可以是用来递送用于标识当前被再现或者将在PD中被再现的服务/内容的信息的端点。CD app可以通过这个端点接收信息。

ESG信息端点可以是用于CD接收ESG的端点。CD app可以通过这个端点接收信息。服务/示出/分段数据端点可以是用于为服务而接收各种类型的递送的数据的端点。

媒体时间线端点可以是用于递送当前时间以及关于当前被再现的服务/内容的媒体信息的端点。可以通过这个端点来递送前述服务类型信息。媒体回放状态端点可以是用于递送关于当前被再现的服务/内容的再现相关信息的端点。再现相关信息可以指示服务/内容正以正常速度再现、以正常速度三倍的速度快进还是快退。可以通过这个端点将前述回放状态信息递送给CD app。

EAS端点可以是用于将EAS信息递送给CD的端点。如果TV接收机接收到EAS信息，则接收机可以将这个信息中继到CD以更高效地预告危险情形。ApptoApp端点可以是用于正在PD和CD中执行的app之间的认证的端点。使用这个端点，PD app和CD app可以通过以双向方式交换消息来交换信息。

因为每个功能被提供有一个端点，所以CD app可以访问每个端点并执行连接过程，以通过该端点获得期望的信息或者与PD app进行通信。

在下文中，为了简单前述架构将被称为基于Websocket的架构示例#1。这个示例可以与其它基于Websocket的架构、基于UPnP的架构以及基于HTTP的架构的各种示例组合。

图90是图示根据本发明的实施例的基于Websocket的PD-CD架构的图。

在所图示的实施例中，与前一个实施例相比可能未为每个功能提供一个端点。在这个实施例中，PD的Websocket服务器可以提供一个端点，并且这个端点可以执行所有前述功能。这个端点可以被称为配套端点。Websocket架构的配置的其它细节可以与前一个实施例中的那些细节相同。

这个端点可以执行被图示为在前一个实施例中由多个端点执行的所有功能。也就是说，这个端点可以执行包括前述服务/内容标识端点、ESG信息端点以及服务/示出/片段数据端点的这些端点的所有功能。因此，CD app可能只有当app连接到这个端点时才被允许接收ESG或媒体时间线信息或者执行包括与PD app通信的所有操作。然而，在这种情况下，需要标识在这个CD app与Websocket服务器之间交换的消息所意在的功能，并且因此消息可以包括更详细的信息或者被进一步扩展。

因为这个配套端点执行所有功能，所以可以在建立到这个端点的连接时执行这些功能。连接到这个端点的过程可以与如上所述的连接到正常端点的过程相同。在这种情况下，因为提供了一个端点，所以即使对这些功能中的任一个的访问是不必要的，也不能够部分地终止到该端点的连接。此外，如果这些功能中的任一个是必要的，则可能需要建立到这个配套端点的连接。

在下文中，为了描述的简单前述架构将被称为基于Websocket的架构示例#2。这个示例可以与其它基于Websocket的架构、基于UPnP的架构以及基于HTTP的架构的各种示例组合。

图91是图示根据本发明的实施例的基于Websocket的PD-CD架构的图。

在所图示的实施例中，n个端点被提供，并且可以总共执行m个功能。在本文中，n可以小于或者等于m，并且n和m两者可以是整数。也就是说，在这种情况下，可以提供多个(n个)端点，其中的每一个可以执行一个或多个功能。

在这个实施例中，执行服务/内容标识和ESG递送的功能的端点可以作为配套端点被提供，而执行App到App功能的端点可以作为单独的“ApptoApp端点”被提供。

这个实施例的架构可以是基于Websocket的架构#1和#2的组合。可以根据n和m的值来配置各种架构。提供的端点的数目可以变化并且每个端点可以提供不同数目的功能。

可能需要针对端点中的每一个执行连接到前述端点以及从前述端点断开的过程。也就是说，当提供了n个端点时，可能需要执行这个过程n次。

在下文中，为了描述的简单这个架构将被称为基于Websocket的架构示例#3。这个示例可以与其它基于Websocket的架构、基于UPnP的架构以及基于HTTP的架构的各种示例组合。

图92是图示根据本发明的实施例的基于Websocket的PD-CD架构中的app到app通信的图。

可以在正在PD中执行的app与正在CD中执行的app之间执行App到app通信。在基于Websocket的架构中，这些app可以经由Websocket服务器与彼此进行通信。在这种情况下，可以使用前述ApptoApp端点。可替选地，根据实施例，可以使用用于并行执行app到app通信和其它功能的配套端点。

CD app可以通过前述过程连接到Websocket服务器的App到App通信端点。正在PD中执行的app对应于Websocket客户端并且可以连接到Websocket服务器的App到App通信端点。当Websocket服务器从两侧接收到匹配连接请求时，Websocket服务器可以连接CD和PD，使得CD和PD能够交换消息。

一旦CD和PD的apps彼此连接，它们就可以经由Websocket服务器交换消息。可以以双向方式递送这个消息。Websocket服务器可以将消息从一侧中继到在另一侧的app。

图93是图示根据本发明的实施例的基于HTTP的PD-CD架构的图。

在基于HTTP的架构中，可以在正在PD和CD中执行的app之间执行通信。在基于HTTP的架构中，PD可以包括HTTP服务器，并且CD可以包括app。在本文中，CD中的apps可以被称为HTTP客户端。

PD中的HTTP服务器可以执行各种操作/功能。为了访问服务器的功能，可能需要对应的服务的服务URL。CD app可以通过向对应的服务URL发送请求来接收期望的信息。

首先，可以在正在PD和CD中执行的app之间执行发现过程。在这个过程中，可以将关于HTTP服务器的URL的信息递送给CD app。CD的HTTP客户端可以使用所接收到的URL信息来接收访问对应URL所需的信息。

在这个实施例中，HTTP服务器对于相应的功能可以具有不同的URL。也就是说，可以给每个功能提供一个URL。

通过这些服务URL提供的服务可以与由前述Websocket服务器提供的功能类似。例如，如果CD app访问服务/内容标识服务URL，则CD app可以接收用于标识当前被再现或者将在PD中被再现的服务/内容的信息。也就是说，CD app可以向服务/内容标识服务URL发送对服务/内容标识信息的请求，并且PD的HTTP服务器可以将所请求的信息中继到CD app。可以定义与由前述ESG信息端点、媒体时间线端点等所提供的功能相同的ESG信息服务、媒体时间线服务等。CD app可以通过向相应的服务URL发送请求来接收期望的信息。

因为服务URL是为相应的服务而提供的，所以CD app可以识别相应的URL信息并且只有当CD app访问对应的URL时才可以获得期望的信息或者与PD app进行通信。

在下文中，为了描述的简单前述架构将被称为基于HTTP的架构示例#1。这个示例可以与其它基于HTTP的架构、基于UPnP的架构以及基于Websocket的架构的各种示例组合。

图94是图示根据本发明的另一实施例的基于HTTP的PD-CD架构的图。

在所图示的实施例中，与前一个实施例相比可能未给每个服务提供服务URL。在这个实施例中，PD的HTTP服务器可以提供一个服务URL，并且所提供的服务URL可以执行所有前述功能。服务URL可以被称为配套服务URL。HTTP架构的配置的其它细节可以与前一个实施例的那些细节相同。

这个服务URL可以执行被图示为在前一个实施例中通过多个服务URL来执行的所有功能。也就是说，服务URL可以执行通过包括服务回退/内容标识服务URL、ESG信息服务URL以及服务/示出/片段数据服务URL的前述服务URL所执行的所有功能。因此，CD app可以简单地通过向服务URL发送请求来接收ESG或媒体时间信息。

在这种情况下，当请求被发送到HTTP服务器时，可以扩展请求消息，使得新变量被添加到查询项。这是因为有必要标识请求被发送到配套服务URL的信息。HTTP服务器可以分析请求并且将期望的信息递送给CD app。

在下文中，为了描述的简单前述架构将被称为基于HTTP的架构示例#2。这个示例可以与其它基于HTTP的架构、基于UPnP的架构以及基于Websocket的架构的各种示例组合。

图95是图示根据本发明的实施例的基于Websocket与HTTP的PD-CD架构的图。

上面所描述的基于UPnP的架构、基于Websocket的架构以及基于HTTP的架构可以彼此组合。例如，PD可以同时具有HTTP服务器和Websocket服务器。根据实施例，当PD具有HTTP服务器和Websocket服务器时，PD还可以执行UPnP架构上的受控装置的功能。

此外，经组合的UPnP架构可以是前述UPnP架构的第一示例、第二示例以及第三示例中的一个。经组合的Websocket架构可以是基于Websocket的架构#1、#2和#3中的一个，并且HTTP架构可以是基于HTTP的架构#1和#2中的一个。

在这个实施例中，PD可以同时具有HTTP服务器和Websocket服务器，基于HTTP的架构#2可以被用作HTTP架构，并且基于Websocket的架构#3可以被用作Websocket架构。也就是说，在HTTP服务器中，一个服务URL地址可以执行多个功能。Websocket服务器可以提供n个端点，并且该n个端点可以执行多个功能。具体地，在这个实施例中，可以提供两个端点：这些端点中的一个可以用作用于app到app通信的端点，而另一个端点可以用作执行所有其它功能的端点。

虽然在本说明书中提供了仅前述实施例，但是其所有组合也在本发明的范围内。各种架构可以根据这些组合被设计，并且可以由设计者选择和使用。

在这个实施例的架构中，可以将相应的功能分布到HTTP服务器和Websocket服务器。也就是说，HTTP服务器可以被用来执行特定功能，并且因此HTTP的单个服务URL可以被用来接收用于实现这些功能的请求。此外，Websocket服务器可以提供用于执行其它功能的端点。

可以根据功能的特性来执行功能的分布。HTTP可以被用于异步通信，然而Websocket可以被用于同步通信。

根据实施例，可以通过HTTP来执行ESG信息递送以及服务/示出/片段递送的功能。也就是说，通过向HTTP服务器的服务URL发送请求，可以获取诸如ESG或服务数据的信息。

此外，可以通过Websocket来执行服务/内容标识、媒体回放状态以及app到app通信的功能。Websocket服务器可以提供能够执行服务/内容标识和媒体回放状态的功能的配套端点以及能够执行app到app通信的ApptoApp端点。

根据实施例，可以通过HTTP和/或Websocket来执行媒体时间线功能。该功能可以由HTTP和Websocket中的一个或两者来提供。可以通过Websocket或者通过PD中的组播发送方来执行EAS信息递送的功能。当使用了组播发送方时，PD中的组播发送方可以将EAS信息组播给组播组中的设备。

图96是图示用于发现主装置(PD)的消息的格式的图。

PD可以具有ST(搜索目标)值以标识PD符合的技术标准。例如，PD可以使用urn:atsc:device:atsccompanion:3或urn:atsc:service:atsccompanion:3的值作为设备类型或其服务类型。可以在发现过程中通过ST匹配使用这些值。

PD可以代表发现过程向CD通告它本身。可替选地，CD可以通过搜索操作来发现PD。

当PD向CD通告它本身时，PD可以组播发现消息。可以使用NOTIFY方法来发送发现消息。可以像在所图示的示例t413020中一样配置用于通告PD的发现消息。

如果CD通过搜索操作发现PD，则CD或正在CD中执行的app可以组播发现消息。可以使用M-SEARCH方法来发送发现消息。可以像在所图示的示例t413020中一样配置用于CD的搜索操作的发现消息。

使用前述ST值，CD app可以发现符合特定技术标准的PD。PD可以接收上面所描述的搜索消息。如果PD的ST值和消息中的ST值匹配，则PD可以向已发送搜索消息的CD app发送响应(200OK)。可以像在所图示的示例t413030中一样配置这个响应消息。

所图示的消息格式仅是本发明的实施例，并且根据实施例包含在消息中的变量可以具有不同的值。

所图示的发现过程不仅适用于Websocket架构而且适用于HTTP架构。

图97是图示使用设备描述文档(DDD)的Websocket端点或HTTP服务URL的发现过程的图。

如上所述，PD可以组播用于通告它本身的发现消息或者向CD发送所接收到的M-SEARCH消息的响应消息。CD app可以从组播的发现消息的LOCATION报头或针对M-SEARCH消息的响应消息中获得URL。这个URL能够获取设备描述文档(DDD)。CD app可以使用URL来获取DDD，从而获得装置描述信息等。

如上所述，PD可以使用NOTIFY方法来组播用于通告它本身的发现消息。在这个操作中，用于获取DDD的URL信息可以被递送给正在CD中执行的app。可替选地，如果CD app使用M-SEARCH方法来组播用于搜索操作的发现消息，则作为响应PD可以向CD发送响应消息。在这个操作中，可以将用于获取DDD的URL信息递送给CD app(t417010)。

此后，CD app可以使用HTTP GET来向所获取的URL发送对DDD的请求。PD可以通过HTTP响应消息将DDD递送给CD app(t417020)。可以将DDD包括在这个响应消息的主体中。

可以通过DDD将Websocket端点的地址提供给CD app。根据实施例，可以通过DDD将HTTP架构的服务URL的地址提供给CD app。当使用形式为两个或更多个协议的组合的架构时，可以通过DDD将Websocket端点的地址和/或HTTP的服务URL的地址提供给CD app。

图98图示根据本发明的实施例的使用DDD的Websocket端点或HTTP服务URL的发现过程中的DDD请求消息和DDD格式。

如上所述，CD app可以使用HTTP GET来请求DDD。在这种情况下，可以像在所图示的示例t418010中一样配置GET消息。可以将使用GET的DDD请求消息发送到从PD获取的DDD的URL。此外，可以使用描述的IP地址/端口的主机信息。此外，可以使用由控制点优选的语言。

如上所述，可以返回用于DDD请求消息的资源消息。可以将DDD包括在响应消息的主体中。可以像在所图示的示例t418020中一样配置DDD的典型格式。

DDD可以包括规范版本信息、基础URL信息、装置相关信息等。规范版本信息(specVersion)可以以主/次版本的形式表示所对应的DDD规范的版本。基础URL信息可以包括可用于由DDD递送的所有相关URL的基础URL信息。

装置相关信息可以包括关于由DDD描述的装置的时间信息、可由用户读取的短装置名称信息(friendlyName)、关于装置的制造商信息(manufacturer)以及服务列表信息。

服务列表信息可以包括指示由装置提供的服务的类型的服务时间信息、指示服务的ID的服务ID信息、指示与服务描述有关的新URL的服务描述URL信息、用来控制服务的控制URL信息和/或可用于服务的事件的URL信息。

所图示的格式仅是本发明的实施例，并且其结构、包括在其中的元素以及这些元素的值可以根据实施例而变化。

图99图示根据本发明的实施例的使用DDD的Websocket端点或HTTP服务URL的发现过程中的DDD的格式。

如上所述，可以通过DDD将Websocket端点的地址或HTTP服务URL的地址递送给CDapp。CD app可以使用这些地址连接到Websocket端点或者向服务URL发送请求。

在前述基于Websocket的架构示例#1中，可以使用根据所图示的示例t419010的DDD格式或根据示例t419020的DDD格式。

在所图示的示例t419010中，DDD的装置信息除了包括装置类型信息之外还可以包括关于各种Websocket端点的地址信息。如该图中所示，关于诸如服务/内容标识端点和ESG信息端点的端点的地址信息被包括在DDD的装置信息中。因为DDD格式被用于基于Websocket的架构示例#1，所以可以列举相应的端点的地址。根据所图示的示例t419020的DDD格式还可以包括关于各种Websocket端点的地址信息。在这种情况下，可以将关于端点的地址信息包括在DDD的服务信息中。

虽然地址信息被图示为被包括在装置信息或服务信息中，但是可以将地址信息包括在DDD中的其它位置中。在DDD的所图示的示例中，前述DDD的其它元素被省略。其它元素的配置可以根据实施例而变化。

根据所图示的示例t419010和t419020的DDD格式还可以被用于前述基于HTTP的架构示例#1。在这种情况下，关于Websocket端点的地址信息可以用关于对应的服务URL的URL地址信息代替。因此，可以改变元素名称。类似地，当DDD格式被用于基于HTTP的架构示例#1时，可以列举相应的服务URL的地址。

可以以例如ws://localhost:8030/ESGInformation、ws://localhost:8030/Data以及ws://localhost:8030/MediaTimeline的形式配置Websocket端点的地址。可以以例如http://192.168.1.4:8080/serviceidentification和http://localhost:8030/ESGInformation的形式配置HTTP服务URL的地址。

图100图示根据本发明的另一实施例的使用DDD的Websocket端点或HTTP服务URL的发现过程中的DDD的格式。

在前述基于Websocket的架构示例#2中，可以使用根据所图示的示例t420010的DDD格式或根据示例t420020的DDD格式。

在所图示的示例t420010中，关于DDD的装置信息除了包括设备类型信息之外还可以包括Websocket端点的地址。因为这个示例的DDD格式被用于基于Websocket的架构示例#2，所以可以包括关于仅一个配套端点的地址信息。根据所图示的示例t420020的DDD格式还可以包括关于一个配套端点的地址信息。在这种情况下，可以将关于端点的地址信息包括在DDD的服务信息中。

根据所图示的示例t420010和t420020的DDD格式还可以被用于前述基于HTTP的架构示例#2。在这种情况下，关于Websocket配套端点的地址信息可以用关于配套服务URL的地址信息代替。因此，可以改变元素名称。类似地，当DDD格式被用于基于HTTP的架构示例#2时，可以包括关于一个服务URL的地址信息。

在前述基于Websocket的架构示例#3中，可以使用根据所图示的示例t420030的DDD格式或根据示例t420040的DDD格式。

在所图示的示例t420030中，DDD的装置信息除了包括设备类型信息之外还可以包括关于n个提供的Websocket端点的地址信息。例如，关于执行诸如服务/内容标识和ESG信息递送的功能的端点的地址信息以及关于ApptoApp通信端点的地址信息可以被包括在装置信息中。根据所图示的示例t420040的DDD格式还可以包括关于n个Websocket端点的地址信息。在这种情况下，可以将关于端点的地址信息包括在DDD的服务信息中。

虽然在这个实施例中地址信息被图示为被包括在装置信息或服务信息中，但是可以将地址信息包括在DDD中的其它位置中。在DDD的所图示的示例中，前述DDD的其它元素被省略。其它元素的配置可以根据实施例而变化。

图101图示根据本发明的实施例的对于DDD请求使用响应报头的Websocket端点或HTTP服务URL的发现过程。

如上所述，PD可以组播用于通告它本身的发现消息，或者响应于所接收到的M-SEARCH消息而向CD发送响应消息。CD app可以从所组播的发现消息的LOCATION报头或针对M-SEARCH消息的响应消息中获得URL。这个过程t421010可以与前一个实施例的过程相同。

这个URL能够获取DDD。CD app可以使用HTTP GET来向URL发送用于请求DDD的消息。可以通过与请求消息相对应的响应消息的主体来递送DDD，并且因此CD app可以获得装置描述信息(t421020)。

在前一个实施例中，Websocket端点的地址或关于HTTP服务URL的地址信息通过这个响应消息的DDD来递送。在这个实施例中，可以通过响应消息的报头来递送对应的地址信息。在这种情况下，响应消息的主体可以保持为空并且因此不承载信息，或者可以包括DDD。

图102图示根据本发明的另一实施例的对于DDD请求使用响应报头的Websocket端点或HTTP服务URL的发现过程中的响应报头的格式。

如上所述，CD app可以使用HTTP GET来请求DDD。在这种情况下，可以像在所图示的示例t422010中一样配置GET消息。可以将使用GET的DDD请求消息发送到从PD获取的DDD的URL。此外，可以使用关于描述的IP地址/端口的主机信息。此外，可以使用由控制点优选的语言。这个GET消息可以与根据前一个实施例的消息相同。

如上所述，可以返回针对DDD请求消息的响应消息。可以通过响应消息的报头来递送地址信息。

在前述基于Websocket的架构示例#1中，可以使用根据所图示的示例t422020的响应报头格式。这个示例的响应报头除了包括基本200OK消息的信息之外还可以包括关于各种Websocket端点的地址信息。如该图中所示，关于诸如服务/内容标识端点和ESG信息端点的端点的地址信息可以被包括在响应报头中。当响应报头格式被用于基于Websocket的架构示例#1时，可以列举相应的端点的地址。在本文中，包括地址信息的响应报头的结构和形式可以根据实施例而变化。

根据所图示的示例t422020的响应报头格式还可以被用于上面所描述的基于HTTP的架构示例#1。在这种情况下，关于相应的Websocket端点的地址信息可以用关于对应的服务URL的URL地址信息代替。因此，可以改变元素名称。类似地，当响应报头格式被用于基于HTTP的架构示例#1时，可以列举相应的服务URL的地址。

在前述基于Websocket的架构示例#2中，可以使用根据所图示的示例t422030的响应报头格式。这个示例的响应报头除了包括基本200OK消息的信息之外还可以包括关于Websocket端点的地址信息。因为响应报头格式被用于基于Websocket的架构示例#2，所以可以包括关于仅一个配套端点的地址信息。在本文中，包括地址信息的响应报头的结构和形式可以根据实施例而变化。

根据所图示的示例t422030的响应报头格式还可以被用于上面所描述的基于HTTP的架构示例#2。在这种情况下，关于Websocket配套端点的地址信息可以用关于配套服务URL的地址信息代替。因此，可以改变元素名称。类似地，当响应报头格式被用于基于HTTP的架构示例#2时，可以包括仅关于配套服务URL的地址信息。

在前述基于Websocket的架构示例#3中，可以使用根据所图示的示例t422040的响应报头格式。这个示例的响应报头除了包括基本200OK消息的信息之外还可以包括关于n个Websocket端点的地址信息。例如，关于执行诸如服务/内容标识和ESG信息递送的功能的配套端点的地址信息以及关于ApptoApp通信端点的地址信息可以被包括在响应报头中。在本文中，包括地址信息的响应报头的结构和形式可以根据实施例而变化。

图103图示根据本发明的实施例的对于DDD请求使用响应报头的URL的Websocket端点或HTTP服务URL的发现过程。

如上所述，PD可以组播用于通告它本身的发现消息，或者向CD发送与所接收到的M-SEARCH消息相对应的响应消息。CD app可以从组播的发现消息的LOCATION报头或针对M-SEARCH消息的响应消息中获得URL。这个URL旨在获取DDD。CD app可以向URL发送HTTP GET请求。这些过程t423010和t423020可以与前一个实施例的那些过程相同。

这里，可以响应于HTTP GET请求而接收响应消息。在前一个实施例中，地址信息通过DDD在响应消息的主体或响应消息报头中递送。在这个实施例中，可以通过响应消息报头来递送用于获取地址信息的URL。在这种情况下，响应消息的主体可以保持为空并且因此不承载信息，或者可以包括DDD。

CD app可以向所接收到的地址信息的URL发送HTTP GET请求以请求地址信息。PD可以向CD app发送响应消息。可以通过响应消息将地址信息递送给CD(t423030)。可以通过响应消息的主体来递送地址信息。根据实施例，可以通过响应消息的报头来递送地址信息。

图104是图示根据本发明的实施例的在对于DDD请求使用响应报头的URL的Websocket端点或HTTP服务URL的发现过程中的GET请求以及根据该请求的响应消息的格式的图。

如上所述，CD app可以使用HTTP GET来请求DDD。在这种情况下，可以像在所图示的示例t424010中一样配置GET消息。可以将使用GET的DDD请求消息发送到从PD获取的DDD的URL。GET消息可以与根据前一个实施例的消息相同。

可以根据HTTP GET消息来接收响应消息。响应消息可以具有如所图示的示例t424020中所示出的格式。响应消息除了包括基本200OK消息的信息之外还可以包括能够获取地址信息的URL信息。这个URL信息可以旨在获取Websocket端点的地址或用于获取HTTP服务URL的地址的信息。可替选地，URL可以旨在获取两个地址。在所图示的格式中，包括了用于获取Websocket端点的地址的URL信息。

CD app可以使用HTTP GET来向意图用于地址信息的URL发送对地址信息的请求。可以像在所图示的示例t424030中一样配置这时使用的GET消息。在这种情况下，可以向从PD获取的地址信息的URI发送使用GET的请求消息。此外，可以使用关于描述的IP地址/端口的主机信息。此外，可以使用由控制点优选的语言。

例如，当用于获取地址信息的URL被配置为http://192.168.1.10:8080/WSEndpoints(假定Websocket)时，可以像在示例t424040中一样配置使用URL的GET消息。

此后，可以如上所述返回根据针对地址信息的请求消息的响应消息。该响应消息可以包括地址信息。该地址信息可以指示Websocket端点或HTTP服务URL的地址。

图105是图示根据本发明的另一实施例的用于在对于DDD请求使用响应报头的URL的Websocket端点或HTTP服务URL的发现过程中递送地址信息的响应消息的格式的图。

在上面所描述的基于Websocket的架构示例#1中，可以使用根据所图示的示例t425010的响应消息格式。

如该图中所示，关于诸如服务/内容标识端点和ESG信息端点的端点的地址信息可以被包括在消息中。当消息格式被用于基于Websocket的架构示例#1时，可以列举相应的端点的地址。

根据所图示的示例t425010的消息格式还可以被用于上面所描述的基于HTTP的架构示例#1。在这种情况下，关于相应的Websocket端点的地址信息可以用关于对应的服务URL的URL地址信息代替。因此，可以改变元素名称。类似地，当消息格式被用于基于HTTP的架构示例#1时，可以列举相应的服务URL的地址。

在上面所描述的基于Websocket的架构示例#2中，可以使用根据所图示的示例t425020的消息格式。

根据所图示的示例t425020的消息格式还可以被用于上面所描述的基于HTTP的架构示例#2。在这种情况下，关于Websocket配套端点的地址信息可以用关于配套服务URL的地址信息代替。因此，可以改变元素名称。类似地，当消息格式被用于基于HTTP的架构示例#2时，可以包括仅关于配套服务URL的地址信息。

在前述基于Websocket的架构示例#3中，可以使用根据所图示的示例t425030的消息格式。

根据所图示的示例t425030的消息格式可以包括关于n个Websocket端点的地址信息。例如，关于执行诸如服务/内容标识和ESG信息递送的功能的配套端点的地址信息以及关于ApptoApp通信端点的地址信息可以被包括在该消息格式中。

虽然这些格式被图示为将地址信息包括在additionalData元素中，但是根据实施例消息还可以包括其它信息。在本文中，包括地址信息的消息的结构和形式可以根据实施例而变化。

图106是图示根据本发明的实施例的基于Websocket的握手与连接过程的图(在发现之后)。

如上所述，PD可以用作Websocket服务器，并且CD可以对应于Websocket客户端。PD可以包括Websocket服务器和/或配套服务模块。配套服务模块可以提供TV接收机等中的配套装置所必需的信息，或者执行与配套服务有关的总体管理。配套服务模块可以是硬件模块。

PD的Websocket服务器可以提供Websocket端点。可由CD的web浏览器使用的app可能在执行中。web浏览器还可以提供Websocket客户端。

首先，PD的配套服务模块可以请求Websocket服务器生成Websocket端点t426010。例如，可以递送诸如@ServerEndpoint(“/WS_AA”)的Java格式的请求。在本文中，“/WS_AA”可以是指相关的URL。可以在这个过程中在Websocket服务器中生成Websocket端点。

CD app可以调用用于创建Websocket对象的API(t426020)。被称作newWebsocket的API可以具有Websocket端点的地址作为变量。例如，可以以ex_websocket＝newWebSocket(ws://192.168.1.11:8080/WS_AA)的形式定义ex_websocket。可以通过这个过程在CD中创建Websocket对象。在本文中，可以在PD的Websocket服务器的端点与CD的Websocket对象之间执行握手(t426030)。

CD app可以调用用于添加OpenEventHandler的API(t426040)。这个API可以是WebSocketObject.onopen()。例如，可以以ex_websocket.onopen(…)的形式添加句柄。在这个过程中，Websocket服务器可以连接到客户端(t426050)。Websocket客户端可以向CDapp通知连接的建立(t426060)。

图107是图示根据本发明的实施例的用于基于Websocket的app到app通信的握手与连接过程的图(在发现之后)。

在基于Websocket的架构中，可以在正在PD中执行的app与正在CD中执行的app之间执行app到app通信。如上所述，一旦PD app连接到Websocket服务器，并且CD app也连接到Websocket服务器，Websocket服务器就可以在apps之间中继消息和数据。

首先，PD app可以从PD中的Websocket客户端调用用于创建Websocket对象的API。可以使用前述newWebsocket API。例如，可以以local_websocket＝new WebSocket(ws://localhost:8080/ApptoApp)的形式使用该API。在这个过程中，可以创建用于PD app的Websocket对象。

PD中的配套服务模块可以从Websocket服务器调用API以便创建Websocket端点(t427020、t427030)。可以如上所述执行这个过程。在这种情况下，需要创建用于app到app通信的端点，并且因此可以使用与app到app通信有关的URL(例如，/ApptoApp)。此后，PD的本地Websocket客户端和Websocket服务器可以执行握手过程(t427040)。

CD app还可以创建Websocket对象(t427050)。可以如上所述执行这个过程。在这种情况下，因为Websocket对象意图用于app到app通信，所以可以以例如remote_websocket＝newWebSocket(ws://192.168.1.11:8080/ApptoApp)的形式定义Websocket对象。此后，PD的Websocket服务器以及CD的Websocket对象可以执行握手过程(t427060)。

PD的Websocket客户端以及CD的Websocket客户端可以调用API来添加OpenEventHandler(t427091、t427090)。可以如上所述执行这些过程。因此，每个Websocket客户端可以连接到Websocket服务器(t427070、t427100)。一旦建立了连接，每个Websocket客户端就可以通过事件向相应的apps预告连接的建立(t427080、t427110)。

一旦前述过程完成，CD app和PD app就可以与彼此进行通信(t427120)。可以经由Websocket服务器将消息从一个app递送给另一个app。也就是说，Websocket服务器可以将消息从一个客户端中继到另一个客户端。将稍后详细地描述这个双向通信过程。

图108是图示根据本发明的实施例的基于Websocket的双向通信过程的图(在连接之后)。

假定CD app以及PD中的Websocket服务器通过前述过程连接(t428010)。如上所述，Websocket客户端可以向CD app通知连接的建立(t428020)。

配套服务模块可以调用API以便接收消息(t428030)。例如，可以使用诸如Java格式的@OnMessage的API。因此，Websocket服务器可能准备好接收消息(准备好接收)。

CD app可以调用用于添加MessageEventHandler的API(t428040)。例如，可以调用诸如WebSocketObject.onmessage()的API。对于诸如前一个示例的ex_websocket的对象，可以以ex_websocket.onmessage(…)的形式调用API。通过这个过程，CD的Websocket客户端可以准备好发送/接收消息。

CD app可以调用用于发送消息的API(t428050)。例如，可以调用诸如WebSocketObject.send(message1)的API。对于诸如前一个示例的ex_websocket的对象，可以以ex_websocket.send(message1)的形式调用API。因此，可以将消息(消息1)递送给Websocket服务器(t428060)。

Websocket服务器可以将所接收到的消息(消息1)中继到配套服务模块(t428070)。作为响应配套服务模块可以递送消息(消息2)(t428080、t428090、t428100)。配套服务模块可以调用用于发送消息的API(t428080)。为了以JSON格式发送文本或对象，可以调用诸如session.getBasicRemote().sendText(message2)或session.getBasicRemote().sendObject(message2)的Java API。

图109是图示根据本发明的实施例的基于Websocket的app到app双向通信过程的图(在连接/CD到PD之后)。

假定CD app、PD的Websocket服务器以及正在PD中执行的app被连接。可能已由Websocket客户端通过事件向相应的apps通知了连接的建立。

如上所述，配套服务模块可以调用用于接收消息的API。因此，Websocket服务器可以准备好接收消息(t429030)。PD app可以调用API以便添加MessageEventHandler，并且PD的Websocket客户端也可以准备好接收消息(t429040)。CD app还可以调用API以便使Websocket客户端准备好接收消息(t429020)。已经在上面描述了该过程的细节。

CD app可以调用API以便发送消息(t429050)。这个API是前述API并且可以以例如remote_websocket.send(message1)的形式被使用。因此，可以将消息递送给Websocket服务器(t429060)。Websocket服务器可以将消息(消息1)中继到配套服务模块(t429070)。

为了将消息递送给PD的本地Websocket客户端，配套服务模块可以搜索本地Websocket会话。当配套服务模块发现本地Websocket会话时，该模块可以调用API以便递送消息(消息1)(t429080)。在这种情况下，可以调用诸如session.getBasicRemote().sendText(message1)或session.getBasicRemote().sendObject(message1)的JavaAPI，以便以JSON格式发送文本或对象。

Websocket服务器可以将消息(消息1)中继到Websocket客户端(t429090)，并且Websocket客户端可以进而将该消息中继到PD app(t429100)。

图110是图示根据本发明的实施例的基于Websocket的app到app双向通信过程的图(在连接/PD到CD之后)。

假定CD app、PD的Websocket服务器以及正在PD中执行的app被连接。可能已由Websocket客户端通过事件向相应的apps通知了连接的建立。

Websocket服务器以及相应的Websocket客户端可以准备好在与如上所述的相同的过程中发送/接收消息。

PD app可以调用API以便发送消息(t430010)。这个API是前述API并且可以被以例如local_websocket.send(message2)的形式使用。因此，可以将消息递送给Websocket服务器(t430020)。Websocket服务器可以将消息(消息2)中继到配套服务模块(t430030)。

配套服务模块可以搜索远程Websocket会话以将消息递送给CD的远程Websocket客户端。当配套服务模块发现远程Websocket会话时，该模块可以调用API以便递送消息(消息2)(t430040)。在这种情况下，可以调用诸如session.getBasicRemote().sendText(message2)或session.getBasicRemote().sendObject(message2)的Java API，以便以JSON格式发送文本或对象。

Websocket服务器可以将消息(消息2)中继到Websocket客户端(t430050)，并且Websocket客户端可以进而将该消息中继到CD app(t430060)。

图111是图示根据本发明的实施例的基于HTTP的请求-响应过程的图(在发现之后)。

假定已经通过基于HTTP的架构的前述发现过程发现了所有HTTP服务URL(t431010)。

CD app可以从HTTP客户端调用API以便发送消息请求(t431020)。HTTP客户端可以在发现过程中识别的HTTP服务URL当中根据请求向适当的URL发送消息请求(t431030)。可替选地，根据前一个实施例可以将消息请求发送到一个配套服务URL。在这种情况下，请求的内容可以由例如请求的查询项来标识。

HTTP服务器可以向PD中的配套服务模块中继请求消息(t431040)。配套服务模块可以调用API以便将请求消息(消息1)中继到CD(t431050)。

因此，HTTP服务器可以将消息(消息1)中继到HTTP客户端(t431060)，并且HTTP客户端可以将消息中继到CD app(t431070)。

图112图示根据本发明的另一实施例的XML格式的ESGData状态变量变成JSON格式的ESGData状态变量的转换。

根据本发明的实施例的广播接收装置可以采用包括HTTP(超文本传送协议)、RTP(实时传输协议)、XMPP(可扩展消息传递和存在协议)、FTP(文件传送协议)以及WebSocket的各种协议，以通过装置到装置通信中使用的消息来递送各种类型的信息以为各种目的服务。

在通过前述各种协议来递送装置到装置通信中使用的消息时，根据本发明的实施例的广播接收装置可以递送相应的协议中定义的各种类型(字符串、整数、浮点、布尔、字符、数组、列表等)的数据。广播接收装置可以采用诸如XML(可扩展标记语言)、HTML(超文本标记语言)、XHTML(可扩展超文本标记语言)以及JSON(JavaScript对象表示法)、文本或图像格式的标记方案来更多在结构上表达、递送和存储包含复杂内容的数据，并且不限于特定方案。

在下文中，将给出广播接收装置使用Websocket协议来将包含ESG数据的消息(例如，状态变量)递送给配套装置的方法的描述。在这种情况下，广播接收装置可以将包含ESG数据的ESGData状态变量转换成JSON格式的ESGData状态变量并且使用WebSocket协议来将JSON格式的ESGData状态变量递送给配套屏幕设备。

图112(a)图示在XML格式(或XML数据结构)的ESGData状态变量中设置前述ESG数据的实施例。ESGData状态变量的细节与上面所描述的相同。

参考图112(b)，可以将图112(a)的XML格式的ESGData状态变量转换成JSON格式的ESGData状态变量(或JSON格式)。JSON格式的ESGData状态变量的细节与XML格式的ESGData状态变量的那些细节相同。

因此，可以将XML格式(XML数据结构)的所有数据转换成JSON格式的数据。JSON格式的数据可以被称为JSON对象。可以通过Websocket协议将JSON对象递送给广播接收装置(例如，主装置)中的配套装置。

图113是图示根据本发明的另一实施例的使用Websocket协议来将JSON格式的ESGData状态变量递送给配套装置的过程的图。

所图示的CD(配套装置)可以是指配套装置，并且PD(主装置)可以是指接收机或广播接收装置。

配套装置可以使用以下语法通过调用Websocket API来创建Websocket对象(C58003)

[构建WebSocket对象]

Websocketobjectname＝new WebSocket(Websocket address)

Ex)WS_ESG＝new WebSocket(“ws://Tvhost:8080/ESGServer”)

在本文中，所创建的Websocket对象的名称可以是“WS_ESG”，所调用的WebsocketAPI可以是用于创建新Websocket的“new WebSocket”，并且WebSocket服务器的地址可以是“ws://Tvhost:8080/ESGServer”。

然后，配套装置可以使用以下语法通过调用Websocket API来打开Websocket连接(C58005)。

[打开Websocket连接]

Ex)WS_ESG.onopen＝function{～～～}

在本文中，“WS_ESG.onopen”可以是用于打开Websocket的打开事件句柄。项“function{～～～}”可以是用于打开Websocket连接的Websocket API。

在这种状态(C58010)下，广播接收装置的ESGData状态变量可以没有值。

服务/内容提供方可以通过广播网络或宽带信道来发送ESG数据(C58020)。可以通过接收单元或网络接口来接收ESG数据。在本文中，接收单元可以是前述广播接口或调谐器。

广播接收装置可以发信号通知所接收到的ESG数据(C58030)。

然后，广播接收装置和配套装置可以打开到彼此的Websocket连接(C58035)。

可以以与上面所描述的相同方式打开Websocket连接。例如，包括在广播接收装置中的应用处理器(未示出)可以向网络处理器(未示出)发送对连接到配套装置的请求。此后，网络处理器可以从配套装置接收连接请求。网络处理器可以基于从配套装置接收到的信息来搜索匹配应用处理器的连接请求。一旦网络处理器检索到匹配连接请求，该网络处理器就可以将配套装置与广播接收装置的应用处理器连接。在本文中，应用处理器可以是应用模块或应用浏览器。网络处理器可以是Websocket服务器。

一旦广播接收装置与配套装置之间的Websocket连接打开，广播接收装置就被允许向配套装置发送消息并且/或者从配套装置接收消息。

然后，配套装置可以使用以下事件句柄来向广播接收装置发送各种消息并且/或者从广播接收装置接收各种消息(C58037)。

例如，事件句柄可以包括消息事件句柄、错误事件句柄和/或关闭事件句柄。

在本文中，消息事件句柄是用于在广播接收装置与配套屏幕之间发送和/或接收消息的事件句柄，并且具有以下语法。

[消息事件句柄]

EX)WS_ESG.onmessage＝function{～～～}

错误事件句柄可以是用于发送和/或接收与Websocket连接、广播接收装置和/或配套装置中的错误有关的消息的事件句柄，并且具有以下语法。

[错误事件句柄]

EX)WS_ESG.onerror＝function{～～～}

关闭事件句柄是用于关闭Websocket连接的事件句柄并且具有以下语法。

[关闭事件句柄]

EX)WS_ESG.onclose＝function{～～～}

然后，广播接收装置可以将ESG数据存储(或者设置)在ESGData状态变量中(C58040)。

例如，ESGData状态变量可以具有XML格式或JSON格式。如果广播接收装置将ESG数据设置在XML格式的ESGData状态变量中，则广播接收装置可以将XML格式的状态变量转换成JSON格式的状态变量。

然后，广播接收装置可以通过Websocket协议将ESGData状态变量的JSON对象递送给配套装置(C58050)。

在接收到ESGData状态变量时，配套装置可以解析该状态变量(C58060)，并且然后根据经解析的值来通过UI使ESG数据展示(C56070)。

这时，为了将ESG数据示出给用户，配套装置可以在本地级别(native level)或在应用中表达UI。

可能存在在配套装置中表达ESG数据的各种实施例。根据实施例，在接收到ESG数据时，配套装置可以立即以任何形式使ESG数据展示给用户。根据实施例，在接收到ESG数据时，配套装置可以向用户发送通知消息，并且可以在用户执行ESG数据时使ESG数据展示。根据实施例，在接收到ESG数据时，配套装置可以使ESG信息保持在后台中，并且只有当用户执行用于显示ESG数据的应用时才可以使ESG数据展示给用户。

图114是图示根据本发明的实施例的服务/内容识别消息的图。

本发明提出其中基于陆地广播网络和IP网络之间的链接在下一代混合广播环境下广播接收机(TV接收机或者PD)将各种数据提供给CD的方案。在此，在CD侧上执行的CD或者CD侧应用可以与PD侧通信。

在此数据供应架构中，PD和CD可以交换各种类型的数据。在这样的数据供应中，能够利用上述WebSocket端点的服务、通过HTTP服务URL提供的服务等等。在此提及的服务指的是在PD和CD之间的配套服务，并且对应于不同于广播服务的概念。

例如，PD可以将关于当前提供的并且在PD中在未来能够提供的广播服务(频道)或者内容(或者频道的节目)的信息递送给CD。另外，PD可以将ESG或者紧急报警消息(EAM)递送给CD。根据给定的实施例，PD可以将在回放期间服务的回放状态信息或者PD的时间线信息递送给CD。

在此，EAM是用于报告紧急情形或者灾难性的紧急情形的报警消息。EAM可以通过PD接收并且被递送给CD侧。在此，回放状态信息可以指的是关于用于由PD提供的诸如广播服务等等的服务的关于回放速度、快进、快退等等的信息。时间线信息可以包括用于由PD提供的诸如广播服务等等的服务的媒体时间信息和/或UTC绝对时间对。

如在前述中所描述的，本发明提出用于基于HTTP请求/响应支持在PD和CD之间的通信同时基于WebSocket支持在PD和CD之间的通信的架构。在此，取决于各自的配套装置的属性可以选择根据WebSocket或者HTTP的通信方案。在这一点上，本发明可以允许灵活的架构配置并且确保在PD和CD之间的通信的效率。

在本发明的实施例中，基于WebSocket的通信可以负责与服务/内容识别相关联的通信和与回放状态的递送相关联的通信。同时，基于HTTP的通过web服务器的通信可以负责与ESG的递送的通信和与服务/演出/片段有关的数据的递送相关联的通信。与媒体时间线信息相关联的通信可以由WebSocket和HTTP两者执行。另外，在与服务/内容识别相关联的通信中，可以通过基于HTTP的通信识别当前广播服务的服务/内容。

将会给出与服务/内容识别相关联的通信的描述。广播接收机已经直接地提供用于广播服务等等附加服务。在这样的情况下，当用户尝试执行与包括识别内容或者检查附加的信息同时观看节目的广播服务有关的增强服务时，可能存在有关的信息覆盖广播节目的问题。本发明可以在没有妨碍观看的情况下提供附加的信息，并且通过允许附加的服务被显示在用户的CD上使用CD的更加方便的UI。

此外，本发明提出用于解决在上面提及的问题的协议和PD-CD架构、被递送给CD的服务/内容识别消息等等。另外，本发明提出其中使用服务/内容识别消息CD或者CD侧应用访问在PD中提供或者能够提供的服务/内容。以这样的方式，CD可以事先获取关于广播服务/内容的信息，并且因此附加的服务可以被有效地提供。另外，本发明提出通过在服务/内容识别消息中配置分级位置URL使CD侧有效地获取关于服务/内容的信息的方案。此外，本发明提出能够使用WebSocket和HTTP两者有效地执行上述过程的方案。以这样的方式，在没有妨碍PD的服务/内容的观看的情况下，并且以更加方便的方式，可以提供附加的服务。另外，以这样的方式，能够执行预处理使得CD侧可以获取和再现服务/内容，获取和提供与服务/内容有关的附加的信息/服务，或者有效地执行与服务/内容有关的附加服务。

在本发明的实施例中，PD可以将服务/内容识别消息递送给CD或者CD侧应用。首先，WebSocket连接可以在发现过程中被建立。在上面已经描述了此过程。PD的WebSocket服务器可以从CD侧应用接收用于接收服务/内容识别消息的配套服务的订阅消息。CD侧应用可以已经订阅配套服务。此配套服务可以被更新或者配套服务的订阅可以被取消。此配套服务可以被称为ESG服务。

当与服务/内容有关的信息被改变时，WebSocket服务器可以将服务/内容识别消息递送给CD侧应用。此服务/内容识别消息可以对应于通知消息的类型。此通知消息可以具有消息主体和指示关联于通知消息的配套服务的信息。在这样的情况下，消息主体可以包括与服务/内容识别消息相对应的信息。CD侧应用可以获取此信息以执行必要的附加操作。

CD侧应用可以通过WebSocket连接接收服务/内容识别消息，并且使用HTTP接收关于在PD中当前提供的服务/内容的信息。可以根据消息通过HTTP GET消息和HTTP响应执行此过程。CD侧应用可以发送用于对于PD的web服务器或者web服务器的服务/内容识别的HTTP服务URL的HTTP GET消息。PD的web服务器可以将响应消息发送到CD侧应用。在此，响应消息可以包括与服务/内容有关的信息。

通过在上面描述的WebSocket与服务/内容有关的信息的递送指的是与被提供或者在PD中能够提供的整个服务/内容有关的信息的递送，并且可以对应于以通知的形式的综合信息的递送。另一方面，在上面描述的通过HTTP与服务/内容有关的信息的递送指的是与在PD中提供的服务/内容有关的信息的递送，并且可以响应于来自于CD侧应用的请求执行。

通过WebSocket的递送是综合和整体信息的递送。当存在大的变化时，例如，当ESG被更新时，在没有CD的请求的情况下，关于此变化的信息可以通过此递送提供给CD侧，使得能够有效地检查服务/内容。在这样的情况下，诸如WebSocket的方案可以是更加合适的，并且因此支持WebSocket和HTTP的本发明的PD可以使用WebSocket利用此信息递送。另外，当CD侧需要获取关于在PD测量上当前再现的服务/内容的信息时，通过HTTP的递送允许通过请求/响应容易地获取信息。在这样的情况下，通过HTTP GET等等的请求/响应方案是更加合适的，并且因此本发明的PD可以使用HTTP。CD侧可以通过WebSocket接收服务/内容识别消息，并且然后必要时另外接收用于当前服务/内容的HTTP响应消息。

将会给出通过WebSocket在递送中的服务/内容识别消息的描述。服务/内容识别消息可以包括ESG信息或者从ESG获取并且处理的信息。另外，根据给定的实施例，服务/内容识别消息可以使用ESG的信息结构。

被图示的服务/内容识别消息的实施例可以包括服务元素和/或内容元素。至少一(1至N)个服务元素可以被包括，并且至少零(零至N)个内容元素可以被包括。

服务元素可以描述关于PD的广播服务的信息。在此，可以从ESG数据模型中带来关于服务的信息。服务元素可以包括id元素、SerivceType元素、Name元素、Description元素以及/或者TargetUserProfile元素。

id元素可以指示服务的ID。SerivceType元素可以指示服务的服务类型。Name元素可以指示服务的名称。Description元素可以包括服务的描述。TargetUserProfile元素可以指示通过服务定向的用户简档。

Content元素可以描述关于PD的内容的信息。在此，当广播服务对应于频道时，内容可以指的是节目。Content元素可以包括Programid元素、Name元素、Description元素、TargetUserProfile元素、CARatings元素、Capabilities元素、Component元素、FileContentItem元素、TimelineInfo元素以及/或者Location元素。

Programid元素、Name元素、Description元素、TargetUserProfile元素可以分别包括内容的ID、名称、描述、以及目标用户简档。CARatings元素可以包括内容的内容咨询信息。Capabilities元素可以指示与内容有关的性能信息。在此，性能信息对于有意义地再现内容来说可能是必需的。

Component元素可以包括与被包括在内容中的组件有关的信息。在此，Component元素可以包括与内容的连续的组件有关的信息。在此，连续的组件可以指的是可呈现的组件。根据给定的实施例，音频/视频/字幕组件等等可以对应于连续的组件。根据给定的实施例，基于应用的增强组件、应用组件等等对应于连续的组件。多个Component元素可以存在，并且各个Component元素可以进一步包括@componentType、@componentRole、@componentName以及/或者@componentLocation属性。

@componentType属性可以指示组件的类型。例如，当属性具有0、1、2以及3的值时，组件可以分别具有音频组件、视频组件、隐藏字幕组件以及应用组件类型。剩余的值可以被保留以供将来使用。

@componentRole属性可以指示组件的作用或者类型。@componentName属性可以指示组件的名称。在此，名称可以是人类可读的名称。@componentName属性可以包括用于访问组件的URL信息。CD侧应用可以通过此URL获取组件。

FileContentItem元素可以包括与被包括在内容中的文件内容项目有关的信息。在此，FileContentItem元素可以包括内容的附加信息(附属数据)。在此，附加信息可以包括各种类型的信息。根据给定的实施例，基于应用的增强组件、应用组件等等可以对应于各种类型的信息。多个FileContentItem元素可以存在，并且FileContentItem元素可以被省略。FileContentItem元素可以包括@FileContentItemLocation、@FileContentItemName、@FileContentItemID、@FileContentItemType以及/或者@FileContentItemEncoding属性。

@FileContentItemLocation属性可以包括用于访问相对应的文件组件项目的URL信息。CD侧应用可以通过此URL获取文件组件。

@FileContentItemName属性可以指示文件组件项目的人类可读的名称。@FileContentItemID属性可以指示文件组件项目的ID。@FileContentItemType属性可以指示文件组件项目的类型。@FileContentItemEncoding属性可以指示文件组件项目的编码方案。

TimelineInfo元素可以包括内容的时间线有关的信息。可以通过HTTP GET递送时间线信息或者通过单独的WebSocket服务递送。可替选地，时间线信息可以被包括在服务/内容识别消息中并且被递送。TimelineInfo元素可以进一步包括currentTime元素。currentTime元素可以指示内容的当前时间信息。

Location元素可以指示用于访问相对应的内容的URL信息。CD侧应用可以通过此URL获取内容。此元素可以对应于不同于上述的URL信息的用于访问整个内容的URL信息。根据给定的实施例，当使用此元素的URL信息发送用于获取的请求时，可以通过添加查询项仅获取必要的组件或者文件内容项目。

服务/内容识别消息可以进一步包括演出元素和片段元素。对于演出元素和片段元素中的每一个，被包括在服务元素和内容元素中的上述元素/属性可以被定义。另外，服务/内容识别消息可以进一步包括用于基于服务、演出、片段、或者内容报告关于通过PD当前再现的服务、演出、片段或者内容的一部分的信息的信息。

根据给定的实施例，服务/内容识别消息可以进一步包括标志、其它的ESG信息、以及服务、内容等等的每一个的特性(大小、编码解码器、比率速率、长宽比、以及所要求/期待的性能)。另外，服务/内容识别消息可以进一步包括过滤用于确定是否各个服务、内容等等满足特定的个性化准则的准则信息。

根据给定的实施例，上述位置信息的URL可以是用于从PD获取相对应的信息的PD的URL(PD的服务器)、用于来自于互联网的直接获取的互联网的URL、或者任意的远程服务器的URL。根据给定的实施例，服务/内容识别消息可以进一步包括指示是否能够订阅各个服务、内容等等以接收服务、内容等等中的每一个或者是否服务、内容等等中的每一个对应于一次性的信息。

将会给出用于通过HTTP在递送中递送与当前服务/内容有关的信息的HTTP响应消息的描述。

如在前述中所描述的，CD侧应用可以将HTTP GET消息发送给PD的基于HTTP的web服务器。可以通过配套服务的服务URL信息请求HTTP GET消息。HTTP GET消息可以包括服务URL信息和用于识别配套服务(用于获取与当前服务/内容有关的信息的配套服务)的信息。HTTP GET消息可以进一步包括询问项，并且可以通过此询问项识别被请求的信息。

CD侧应用可以通过HTTP响应消息请求关于通过PD当前提供的服务/内容的信息。关于服务/内容的被请求的信息的示例可以包括当前演出的ESG信息、当前可用的组件信息、当前可用的文件或者NRT数据、以及/或者当前时间线位置信息等等。

PD或者PD的web服务器可以通过HTTP响应消息将被请求的信息递送给CD侧。HTTP响应消息可以包括被请求的信息，或者当不存在被请求的信息时不可以包括被请求的信息。另外，HTTP响应消息可以进一步包括指示是否被请求的信息被包括的信息。在此，被请求的和被递送的信息可以对应于服务/内容识别消息的上述信息。例如，ESG信息可以对应于在服务元素、服务元素的子元素、内容元素、以及上述的内容元素当中的id、名称、描述以及CAratings元素。另外，组件信息可以对应于组件元素和上述组件元素的子元素。关于文件或者NRT数据的信息可以对应于FileContentItem元素和上述的FileContentItem的子元素。此外，时间线位置信息可以对应于上述的FileContentItem元素的子元素。

图115是图示根据本发明的实施例的在PD中提供广播服务的方法的图。

根据本发明的实施例的在PD中提供广播服务的方法可以包括接收广播信号、处理广播信号以输出SLT和ROUTE分组；解析SLT；获取SLS；以及/或者获取流组件和应用组件。

首先，广播接收机(PD)的接收模块可以接收广播信号。在此，接收模块可以指的是接收广播信号的调谐器或者整个接收单元。

PD的第一处理模块处理广播信号以输出SLT和ROUTE分组。第一处理模块可以是硬件模块，其管理物理层、链路层、IP层、以及UDP层。在此，第一处理模块可以被细分成管理各自的层的硬件模块。根据给定的实施例，整个硬件模块可以被视为被称为第一处理模块的一个硬件模块。

PD的第二处理模块可以解析包括引导信息的SLT。引导信息可以指示递送SLS的ROUTE会话。在上面已经描述了引导信息。SLS可以用信号发送特定广播服务的服务数据。特定广播服务的服务数据可以包括流组件和应用组件。流组件可以指的是音频/视频/隐藏字幕组件等等，并且应用组件可以指的是基于应用的增强组件等等。在此，基于应用的增强组件可以作为NRT服务组件被递送。在此，第二处理模块可以是用于解析SLT并且获取信息的硬件模块。

PD的第三处理模块可以访问ROUTE会话，其递送SLS以获取SLS。在此，上述引导信息可以被使用。另外，第三处理模块可以使用SLS获取流组件和应用组件。通过诸如S-TSID等等的会话描述信息可以获取组件，或者可以使用USBD的基本模式等等从宽带网络获取。应用组件可以包括与广播服务的基于应用的增强有关的数据。基于应用的增强可以指的是上述基于应用的增强服务。

在根据本发明的另一实施例的在PD中提供广播服务的方法中，SLS可以包括USBD、S-TSID、以及/或者MPD，并且USBD可以提供S-TSID的参考信息和MPD的参考信息。如在前述中所描述的，USBD可以包括参考S-TSID和MPD的URI信息。S-TSID可以提供用于流组件和应用组件的组件获取信息。接收机可以使用此组件获取信息获取用于广播服务的组件。在此，应用组件可以对应于NRT组件。MPD可以提供用于流组件的再现描述。

在根据本发明的另一实施例的在PD中提供广播服务的方法中，SLS可以进一步包括用于用信号发送基于应用的增强的应用的AST。如在前述中所描述的，可以通过其中递送SLS的传输会话AST可以与其它的SLS片段一起被递送。AST可以包括描述应用组件的信息。描述应用组件的信息可以对应于上述的AST的内容项目信息/元素。在上面已经描述了AST。

MPD可以包括时段元素中的事件流元素。事件流元素可以对应于EventStream元素。事件流元素可以包括静态事件信息。静态事件信息可以对应于在EventStream元素中的事件子元素。术语“静态事件”可以被使用，因为使用EventStream的事件递送通常被用于静态(预产生或者非直播)情形。静态事件信息可以包括事件ID和时序信息。在此，事件ID可以识别静态事件，并且时序信息可以参考时段的开始时间(基于时段的开始时间)指示静态事件的开始时间。

在根据本发明的另一实施例的在PD中提供广播服务的方法中，流组件的片段可以包括动态事件信息。如在前述中所描述的，表示，即，流组件可以具有媒体片段(DASH片段)。在动态情形(直播情形)中，可以在带内递送事件。各自的媒体片段可以在其中包括事件信息。

动态事件信息可以包括事件ID和时间信息。在此，事件ID可以识别动态事件，并且时序信息可以参考表示的开始时间(基于流组件)指示动态事件的开始时间。MPD可以进一步包括用于在流组件中用信号发送动态事件信息的存在的信息。

根据本发明的另一实施例的在PD中提供广播服务的方法可以进一步包括通过PD的配套模块将WebSocket端点位置递送给在CD中正在执行的CD应用以执行发现过程。另外，方法可以通过PD的WebSocket服务器使用WebSocket端点位置建立WebSocket连接。

在发现过程中，被用作PD的HTTP服务器端点的第一URL和被用作PD的WebSocket服务器端点的第二URL可以被递送给CD应用。此发现过程可以如上面所描述的。在此，假定通过PD还没有执行CD应用。CD可以多播M-SEARCH消息。接收此消息的PD可以响应200 OK消息。200 0K消息的报头可以包括PD的LOCATION URL信息。

CD侧应用可以从此位置URL请求装置描述。使用HTTP GET方法可以执行此请求。接收此请求的PD或者PD的配套模块可以将第一响应消息发送到CD侧应用。在此，第一响应消息可以在其报头中包括第一URL。第一URL可以被用作通过PD提供的web服务器的端点。在此，web服务器的端点可以指的是通过上述web服务器提供的服务URL。第一URL可以对应于在上述基于HTTP的架构中使用的配套服务URL。根据给定的实施例，根据各个功能各个服务URL可以存在。在这样的情况下，第一URL可以对应于数个HTTP服务URL中的一个。

PD的配套模块可以从CD应用接收用于应用信息的请求。CD侧应用可以从第一URL请求应用信息。配套模块可以响应于请求发送第二响应消息。第二响应消息可以在响应消息主体中包括第二URL信息。第二URL可以被用作通过PD提供的WebSocket服务器的端点。在此，与WebSocket端点的地址信息相对应的第二URL可以是配套WebSocket端点或者应用对应用WebSocket端点。

在上述实施例当中，本实施例可以对应于其中基于HTTP的web服务器和基于WebSocket的WebSocket服务器两者被设置在PD中的实施例。此外，本实施例可以对应于其中仅一个配套服务URL作为HTTP服务URL被提供，并且一个配套端点和一个应用对应用端点作为WebSocket服务器端点被提供的实施例。在此，WebSocket配套端点可以是提供除了应用对应用通信之外的功能的端点。可以通过任务的划分通过web服务器(HTTP)或者WebSocket服务器(WebSocket)执行在PD和CD之间的通信。例如，可以通过web服务器执行ESG的递送。另外，通过WebSocket服务器可以执行服务&内容识别、EAM的递送以及媒体回放信息的递送。媒体时间线信息可以通过web服务器或者WebSocket服务器被递送。

其后，PD的配套模块可以在WebSocket服务器和CD应用之间建立WebSocket连接。在此过程中，第二URL信息可以被使用。在上面已经详细地描述了建立WebSocket连接(会话)的方法。在此，WebSocket连接可以是用于互连用于应用对应用通信的PD侧应用和CD侧应用的WebSocket连接，或者可以是用于在PD和CD侧应用之间交换信息的WebSocket连接。

根据本发明的另一实施例的在PD中提供广播服务的方法可以进一步包括通过WebSocket服务器使用WebSocket连接将服务识别消息递送给CD应用。在此，WebSocket服务器可以指的是执行与上述WebSocket服务器相对应的操作的硬件模块或者处理器。在此，服务识别消息可以指的是上述服务/内容识别消息。服务识别消息可以包括用于访问广播服务的足迹的组件URL。URL可以对应于上述的位置元素、@componentLocation属性、以及@FileContentItemLocation属性。

PD的接收模块可以通过广播网络或者宽带网络接收ESG信息。在此，接收模块可以对应于包括用于通过广播网络接收数据的调谐器和用于通过宽带网络接收数据的网络接口中的一个或者两者的概念。PD可以进一步包括内部控制模块。当ESG被接收时内部控制模块可以处理ESG，并且生成服务/内容识别消息。

PD的WebSocket服务器可以从CD应用接收订阅消息。订阅消息可以对应于通过上述第二URL识别的WebSocket服务器端点(配套端点)。订阅消息可以订阅用于接收包括从ESG导出的信息的服务识别消息的配套服务。配套服务可以被称为服务/内容识别服务或者ESG服务。

PD的WebSocket服务器可以通过WebSocket连接将服务识别消息递送给CD应用。可以以WebSocket的配套服务的上述通知消息的形式执行此递送。当与服务/内容识别消息相对应的信息被改变时，例如，当ESG被改变时，可以执行此通知。可替选地，此通知可以被周期性地执行。

在根据本发明的另一实施例的在PD中提供广播服务的方法中，PD应用可以使用组件URL获取应用组件。根据给定的实施例，URL可以对应于在PD中提供的服务的URL或者任意的远程服务器的URL。可以在前述情况下从PD并且在后述情况下从服务器可以获取应用组件。

将会给出根据本发明的实施例的在CD中提供广播服务的方法的描述。在附图中未图示此方法。

根据本发明的实施例的在CD中提供广播服务的方法可以包括：通过CD的启动器执行CD的应用；通过CD的应用使用CD的网络接口通过PD执行发现过程；使用CD的WebSocket客户端通过CD的应用建立与WebSocket服务器的WebSocket连接；使用CD的WebSocket客户端发送用于接收服务/内容识别消息的订阅消息以通过CD应用订阅相对应的服务；以及/或者通过CD应用使用CD的WebSocket客户端接收服务识别消息。可以通过CD的配套模块执行在CD应用和PD之间的发现过程。CD应用可以使用配套模块请求装置描述，从上述第一URL请求应用信息，并且获取对请求的响应。另外，在CD中提供广播服务的方法可以进一步包括提供用于使用从通过CD应用从PD或者宽带获取的AST、EventStream、emsg盒以及/或者应用组件在PD中提供的广播服务的基于应用的增强。

根据本发明的实施例的在CD中提供广播服务的方法可以对应于根据本发明的实施例的在PD中提供广播服务的上述方法。可以通过与在PD中提供广播服务的方法中使用的模块(例如，配套模块、接收模块、内部控制模块、web服务器、WebSocket服务器、第一、第二以及第三处理模块等等)相对应的硬件模块执行在CD中提供广播服务的方法。在CD中提供广播服务的方法可以具有与在上述PD中提供广播服务的方法的实施例相对应的实施例。

上述步骤可以被省略或者被替换成用于根据实施例执行相同/相似操作的其它步骤。

图116是图示根据本发明的实施例的用于提供作为PD操作的广播服务的设备的图。

根据本发明的实施例的作为PD操作的用于提供广播服务的设备可以包括配套模块、第一、第二、以及第三处理模块、接收模块、内部控制模块、web服务器、以及/或者上述WebSocket服务器。在上面已经描述了各自的块/模块。

根据本发明的实施例的用于提供作为PD操作的广播服务的设备及其内部块/模块可以执行在本发明的PD中提供广播服务的方法的上述实施例。

将会给出根据本发明的实施例的作为CD操作的用于提供广播服务的设备的描述。在附图中未图示此设备。

根据本发明的实施例的作为CD操作的用于提供广播服务的设备可以包括上述启动器、配套模块、以及/或者网络接口。在上面已经描述了各自的块/模块。

根据本发明的实施例的作为CD操作的用于提供广播服务的及其内部块/模块可以执行在本发明的CD中提供广播服务的方法的上述实施例。

设备内部的上述块/模块等等可以对应于执行在存储器中存储的连续的处理的处理器或者被定位在根据实施例的设备的内部/外部的硬件元件。

上述模块可以被省略或者被替换成用于根据实施例执行相同/相似的操作的其它模块。

模块或单元可以是执行存储在存储器(或存储单元)中的连续处理的处理器。上述实施方式中所描述的步骤可由硬件/处理器来执行。上述实施方式中所描述的模块/块/单元可作为硬件/处理器来操作。本发明所提出的方法可作为代码来执行。这种代码可被写在处理器可读存储介质上，因此可由设备所提供的处理器读取。

尽管为了方便已参照各个附图描述了实施方式，实施方式可被组合以实现新的实施方式。另外，设计存储有用于实现上述实施方式的程序的计算机可读记录介质在本发明的范围内。

根据本发明的设备和方法不限于上述实施方式的配置和方法，所有或一些实施方式可被选择性地组合以获得各种修改。

本发明所提出的方法可被实现为存储在网络装置中所包括的处理器可读记录介质中的处理器可读代码。处理器可读记录介质包括存储有可由处理器读取的数据的所有类型的记录介质。处理器可读记录介质的示例包括ROM、RAM、CD-ROM、磁带、软盘、光学数据存储装置等以及作为载波的实现方式(例如，经由互联网的传输)。另外，处理器可读记录介质可被分布于通过网络连接的计算机系统上并且作为可按照分布式方式读取的代码来存储和执行。

尽管出于例示性目的公开了本发明的优选实施方式，本领域技术人员将理解，在不脱离所附权利要求书中所公开的本发明的范围和精神的情况下，各种修改、添加和置换是可能的。这些修改不应从本发明的技术精神或前景单独地理解。

本说明书中提及了设备发明和方法发明二者，设备发明和方法发明二者的描述可互补地应用于彼此。

本领域技术人员将理解，在不脱离本发明的精神和基本特性的情况下，本发明可按照本文所阐述的方式以外的特定方式来实现。因此，本发明的范围应该由所附权利要求书及其法律上的等同物来确定，而非由以上描述确定，落入所附权利要求书的含义和等同范围内的所有改变旨在被涵盖于其内。

在本说明书中，提及了设备发明和方法发明二者，设备发明和方法发明二者的描述可互补地应用。

本发明的模式

已在具体实施方式中描述了各种实施方式。

工业实用性

本发明适用于广播信号提供领域。

本领域技术人员将认识并理解，在本发明的精神和范围内，可进行各种等同修改。因此，本发明旨在涵盖对本发明的修改和变化，只要它们落入所附权利要求书及其等同物的范围内即可。