CN114128301A - 广播信号发送设备、广播信号发送方法、广播信号接收方法和广播信号接收设备 - Google Patents

广播信号发送设备、广播信号发送方法、广播信号接收方法和广播信号接收设备 Download PDF

Info

Publication number
CN114128301A
CN114128301A CN202080052294.6A CN202080052294A CN114128301A CN 114128301 A CN114128301 A CN 114128301A CN 202080052294 A CN202080052294 A CN 202080052294A CN 114128301 A CN114128301 A CN 114128301A
Authority
CN
China
Prior art keywords
service
information
signaling
dvb
broadcast signal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202080052294.6A
Other languages
English (en)
Other versions
CN114128301B (zh
Inventor
朴钟桓
尹准熙
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LG Electronics Inc
Original Assignee
LG Electronics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by LG Electronics Inc filed Critical LG Electronics Inc
Publication of CN114128301A publication Critical patent/CN114128301A/zh
Application granted granted Critical
Publication of CN114128301B publication Critical patent/CN114128301B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2362—Generation or processing of Service Information [SI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/426—Internal components of the client ; Characteristics thereof
    • H04N21/42607—Internal components of the client ; Characteristics thereof for processing the incoming bitstream
    • H04N21/4263—Internal components of the client ; Characteristics thereof for processing the incoming bitstream involving specific tuning arrangements, e.g. two tuners
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/4722—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting additional data associated with the content
    • H04N21/4725—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting additional data associated with the content using interactive regions of the image, e.g. hot spots
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

根据实施例的广播信号接收方法可以包括以下步骤：接收广播信号，所述广播信号包括用于广播网络的服务数据和用于互联网网络的服务数据，并且还包括用于用信号通知所述服务数据的信令信息；解析所述信令信息；以及基于所述信令信息来解码服务数据。根据实施例的广播信号发送方法可以包括以下步骤：编码用于广播网络的服务数据；编码用于互联网网络的服务数据；生成用于用信号通知所述服务数据的信令信息；以及发送所述服务数据和所述信令信息。

Description

广播信号发送设备、广播信号发送方法、广播信号接收方法和 广播信号接收设备
技术领域
本公开涉及广播信号发送设备、广播信号发送方法、广播信号接收方法和广播信号接收设备。
背景技术
随着模拟广播信号传输告终，已经开发了用于发送/接收数字广播信号的各种技术。数字广播信号可以包含比模拟广播信号更大量的视频/音频数据。它还可以包含除了视频/音频数据之外的各种类型的附加数据。
发明内容
[技术问题]
根据本公开的实施例的广播信号发送设备和广播信号接收设备实现基于互联网协议(IP)的TV服务，该TV服务能够提供与地面、卫星和/或有线线性信道相同的用户体验(UX)。
根据本公开的实施例的广播信号发送设备和广播信号接收设备通过接收基于开放互联网的本地码而不是基于应用的线性信道服务，来提供与地面、卫星和/或有线信道聚合的信道指南。
考虑到高单播业务和通过诸如作为基于IP的设备的过顶(OTT)设备、个人计算机(PC)和互联网协议电视(IP TV)的媒体而不是通过固定地面服务的直接接收来消费广播服务的情况，根据本公开的实施例的广播信号发送设备和广播信号接收设备提供实时/非实时媒体流的无缝服务。
[技术方案]
根据本公开的目的，一种广播信号接收方法可以包括：接收广播信号，该广播信号包括用于广播网络的服务数据和用于互联网网络的服务数据，其中该广播信号还包括用于用信号通知该服务数据的信令信息；解析所述信令信息；以及基于所述信令信息来解码所述服务数据。
在本公开的另一方面，一种广播信号发送方法可以包括：编码用于广播网络的服务数据；编码用于互联网网络的服务数据；生成用于用信号通知所述服务数据的信令信息；以及发送所述服务数据和所述信令信息。
[有益效果]
基于互联网的广播服务发现和获取可以由未配备现有传统调谐器的接收器在宽带网络上实现。
在接收聚合服务列表中，由于用于每个服务的版本化/期满管理方法以及用于每个服务的选择性解析和存储，所以不需要接收整个聚合服务列表。
在互联网线性信道的隐藏/可选/非激活操作中，通过阻止不能提供广播信号并因此给用户带来不便的逻辑信道服务以及提供互联网返回信道替换服务，可以提供更好的媒体服务。
支持基于RF的DVB调谐器的设备能够实现通过在其中聚合现有线性服务和OTT服务的UI来访问的服务。
在没有机顶盒(STB)的情况下，可以通过开放式互联网来提供媒体服务，该媒体服务提供与现有线性信道相同的UX。
由于现有DVB网络和互联网信道被聚合，因此可以扩展可以在同一信道内提供的分辨率。
根据实施例，可以通过uri_linkage_descriptor来实现DVB-I服务列表位置的信令。根据实施例的接收设备可以有效地获取DVB-I服务列表。另外，根据实施例的端点可以允许接收设备有效地获取服务列表。
附图说明
附图被包括以提供对本公开的进一步理解，并且被并入和构成本申请的一部分，附图图示了本公开的实施例，并且与说明书一起用于解释本公开的原理。在附图中：
图1示出了根据实施例的服务场景；
图2是从根据实施例的网络运营商/ISP的角度的根据实施例的操作的流程图；
图3示出了根据实施例的用于DVB信道服务的协议栈；
图4示出了根据实施例的DVB-I客户端的各种示例；
图5示出了根据实施例的查询项；
图6示出了根据实施例的DVB-I服务发现查询请求的示例；
图7示出了根据实施例的实现基于SDLT的服务列表UI的实施例的示例设备；
图8是根据实施例的服务发现操作的示例性流程图；
图9示出了根据实施例的服务发现列表表(service discovery list table，SDLT)的语法；
图10示出了根据实施例的服务类别；
图11示出了根据实施例的内容格式；
图12示出了根据实施例的URL的类型；
图13示出了根据实施例的添加了SdltInetUrl的SDLT语法；
图14示出了根据实施例的可用于查询项的项；
图15示出了根据实施例的信令对象类型的列表；
图16示出了根据实施例的使用SdltInetUrl的查询项的使用的示例；
图17示出了由根据实施例的方法/设备提供的UI/UX的示例；
图18示出了根据实施例的元数据封装类型；
图19示出了根据实施例的基于元数据封装的HTTP响应的示例；
图20示出了根据实施例的DVB-I服务信令机制；
图21示出了根据实施例的USBD的示例；
图22示出了根据实施例的RunningStatus；
图23是图示了根据实施例的基于互联网的服务的USBD和MPD获取的流程图；
图24示出了根据实施例的基于RunningStatus的UI/UX的示例；
图25是根据实施例的USBD信令处理的流程图；
图26示出了根据实施例的服务发现列表表的扩展语法；
图27示出了根据实施例的简化USBD的语法；
图28示出了根据实施例的用于使用扩展SDLT提供服务列表和服务的UI/UX；
图29是图示了根据实施例的扩展SDLT和简化USBD的使用的流程图；
图30示出了根据实施例的指示位置信息的LocationInfo元素的语法；
图31示出了根据实施例的包括位置信息的SDLT；
图32图示了根据实施例的提供区域信息的SDLT和接收器的操作的示例；
图33是根据实施例的通过提供区域信息的接收器的流程图；
图34示出了根据实施例的与设备相关的DVB组件和接口的示例配置；
图35示出了根据实施例的用于接收服务列表的元数据封装；
图36具体示出了根据实施例的元数据封装；
图37示出了根据实施例的DITS服务发现元数据封装；
图38示出了根据实施例的SDLT的扩展；
图39示出了根据实施例的信道管理的示例；
图40示出了根据实施例的隐藏(可见)呈现的值；
图41是根据实施例的隐藏信道管理的流程图；
图42示出了根据实施例的包括相关材料(Related Material)的SDLT的示例；
图43示出了根据实施例的相关材料的使用的示例；
图44示出了根据实施例的非活动横幅(banner)的使用的示例；
图45示出了根据实施例的服务列表的分级结构；
图46示出了根据实施例的DVB-I服务列表类型；
图47是根据实施例的DVB-I服务列表类型的表格表示；
图48示出了根据实施例的DVB-I服务类型；
图49示出了根据实施例的DVB-I服务类型；
图50示出了根据实施例的DVB-I服务类型；
图51示出了根据实施例的服务实例类型的表格表示；
图52示出了根据实施例的用于联播的DASH传送参数的扩展；
图53示出了根据实施例的用于联播的DASH传送参数的表格表示；
图54示出了根据实施例的DASH传送参数类型；
图55示出了根据实施例的DASH传送参数类型；
图56图示了根据实施例的DVB-I服务实例的信令；
图57示出了根据实施例的联播UI/UX；
图58示出了根据实施例的接收设备的结构；
图59示出了根据实施例的网络信息表(NIT)的配置；
图60示出了根据实施例的业务群关联表(BAT)的配置；
图61示出了根据实施例的服务描述表(SDT)的配置；
图62图示了根据实施例的由广播信号接收设备解析信令信息的处理；
图63示出了根据实施例的网络的类型；
图64示出了根据实施例的URI描述符(URI_linkage_descriptor)的配置；
图65示出了根据实施例的URI链接类型信息(URI_linkage_type)的配置；
图66示出了根据实施例的专用数据的配置；
图67示出了根据实施例的专用数据的配置；
图68示出了根据实施例的IP信道ID描述符(IP_channel_ID_descriptor)的配置；
图69图示了根据实施例的基于业务群(bouquet)的服务发现的处理；
图70图示了根据实施例的在DVB网络上的DVB-I引导方法(bootstrappingmethod)；
图71示出了根据实施例的URI链接描述符；
图72示出了根据实施例的端点类型(end_point_type)；
图73示出了根据实施例的链接型专用数据字节的配置；
图74示出了根据实施例的BAT的URI链接描述符；
图75示出了根据实施例的接收设备的参考关系；
图76示出了根据实施例的在一个信道上提供混合服务的元素；
图77示出了根据实施例的信号接收设备的配置；
图78示出了根据实施例的链接描述符；
图79示出了根据实施例的扩展事件链接；
图80示出了根据实施例的private_data_byte；
图81示出根据实施例的扩展事件链接描述符的用例；
图82示出了根据实施例的补充视频描述符；
图83示出了根据实施例的替换服务；
图84示出了根据实施例的SDLT；
图85示出了根据实施方式的用于信道列表的UI/UX；
图86示出了根据实施例的用于动态解析支持的ABR流和链接服务；
图87示出了根据实施例的EPG视图；
图88示出了根据实施例的发送设备的配置；
图89示出了根据实施例的接收设备的配置；
图90图示了根据实施例的广播信号发送方法；以及
图91图示了根据实施例的广播信号接收方法。
具体实施方式
在以下，将参照附图详细描述本说明书中公开的实施例。相同或相似的部件被赋予相同的附图标记，并且省略其冗余描述。本文的元件的后缀“模块”和“单元”是为了便于描述而使用，且因此可互换使用且不具有任何可区分的含义或功能。此外，在描述本说明书中公开的实施例时，如果相关已知技术的详细描述将不必要地模糊本说明书中公开的实施例的要点，则将省略其详细描述。另外，提供附图是为了容易理解本说明书中公开的实施例，并且附图不限制本说明书中公开的技术思想，并且实施例应当被解释为包括落入本公开的精神和范围内的所有修改、等同物和替代物。
显然，以下实施例旨在体现本公开，而不旨在限制或约束本公开的范围。本领域技术人员从本公开的详细描述和实施例容易想到的所有技术被解释为属于本公开的范围。
以下详细描述在所有方面都应被解释为说明性的而非限制性的。本公开的范围应当由所附权利要求的合理解释来确定，并且落入本公开的等同范围内的所有改变都落入本公开的范围内。
现在将详细参考本公开的示例性实施例，其示例在附图中图示。下面将参照附图给出的详细描述旨在解释本公开的示例性实施例，而不是示出根据本公开可以实现的仅有实施例。以下详细描述包括具体细节以便提供对本公开的透彻理解。然而，对于本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下实践本公开。尽管在本公开中使用的大多数术语是从本领域中广泛使用的一般术语中选择的，但是一些术语是由申请人任意选择的，并且它们的含义根据需要在以下描述中详细解释。因此，本公开应当基于术语的预期含义而不是它们的简单名称或含义来理解。另外，附图和详细描述不应被解释为限制本文阐述的实施例，并且应被解释为覆盖附图和详细描述中公开的实施例的所有等同物或其他替代物。
将描述根据实施例的用于发送和接收广播信号的方法/设备的操作。用于发送和接收广播信号的方法/设备可以被称为根据实施例的方法/设备。
图1示出了根据实施例的服务场景。
本说明书中描述的实施例涉及一种用于信令方法基于图1的场景提供基于互联网的广播服务的发现和获取的方法/设备，并且将描述提供用于这种操作的信令方案的实施例。
具体地，实施例提供了一种实现基于IP的TV服务的方法，该TV服务能够提供与地面、卫星和有线线性信道相同的用户UX。
实施例提供了一种通过接收基于开放互联网的本地码而不是基于应用的线性信道服务来提供与地面、卫星和有线信道聚合的信道指南的方法。
实施例提供了基于所有地面波、卫星、线缆(cable)和互联网的聚合广播系统协议。
实施例提供了一种在没有地面、卫星或有线调谐器的情况下由接收器获取互联网广播服务信令的方法。
实施例提供了一种用于获取基于互联网传输的广播服务的服务发现系统。
实施例提供了基于互联网的广播服务信令机制。
实施例提供了一种用于提供基于互联网的广播服务的服务发现方案。
实施例提出了应当针对基于互联网的广播服务标识而定义的附加信息。
实施例提供了一种用于获取基于互联网的广播服务信令的系统机制。
实施例提出了用于每个服务的版本控制/期满管理方法以及用于每个服务的在接收聚合服务列表时的选择性解析和存储方法。
实施例提出了一种在互联网线性信道的隐藏/可选/非活动状态中的信道管理方法。
实施例提出了用于提供基于互联网的广播服务的服务发现信令方案。
实施例提出了当在多部分/相关容器中发送针对每个唯一服务分段的服务列表时配置的服务列表元数据封装的结构。
实施例提出了一种当用户直接访问当前信道时在互联网线性逻辑信道的隐藏/可选/非活动情况下向用户显示当前信道状态或提供备可替换信道的方法。
实施例可以使未配备传统调谐器的接收器能够在宽带网络上执行基于互联网的广播服务发现和获取。
根据实施例，由于提供了用于每个服务的版本控制/期满管理方法以及用于每个服务的选择性解析和存储，因此在接收聚合服务列表时不需要接收整个聚合服务列表。
根据实施例，当互联网线性信道处于隐藏/可选/非活动状态时，可以通过阻止不能提供广播信号并因此对用户造成不便的逻辑信道服务以及提供互联网返回信道替换服务，来提供更好媒体服务。
传统的基于IP的线性信道服务以通过特定提供商(例如，ISP、网络运营商)的订阅来授权认证并且通过由提供商提供的机顶盒(STB)来接收IP线性服务的方式来操作。另外，最近，已经引入了连接性TV，从而使得无机顶盒(无STB)的IP线性服务可用。代表性的标准技术是ATSC3.0、IBB和HbbTV。可以通过在TV内部的OS平台上运行应用来向客户端提供各种线性富媒体服务。各种运营商提供他们自己开发的服务应用以安装在TV平台上，并且该应用定义了可以接收用于服务的数据的服务器和启用请求/接收的API。基于生命周期，客户端可以通过TV UI访问应用并且通过应用接收各种服务。
在北美和欧洲，OTT信道的普及程度高达观看全世界的线性电视，并且随着OTT市场的扩展，OTT已经成为基于IP的设备的基本媒体应用。然而，OTT的影响形式已经通过其自己的平台和专用于OTT的服务生态系统而变成专有服务。换句话说，OTT在编解码器、协议栈、应用、浏览器等方面形成其自身的应用生态系统消费模式，编解码器、协议栈、应用、浏览器等仅由每个OTT提供。
就这一点而言，实施例提出了可以解决诸如OTT的专有平台和对应用的操作的依赖性之类的问题的方法和设备。
实施例提出了一种服务，通过该服务在接收器本级发现服务，并且客户端访问可访问的服务服务器并且接收线性服务，与需要执行应用以提供类似于地面(T)、卫星(S)或有线(C)线性信道服务的信道UX的传统技术形成对比。
此外，实施例提出了一种其中OTT自己的平台被集成到单个统一的TV本地平台中以允许用户在信道上接收和观看OTT内容而不执行OTT应用的服务场景。
参照图1，广播装置10000可以在地面(T)、卫星(S)或有线(C)信道10010和互联网信道10020上同时发送服务。能够接收DVB-I服务的服务提供商和设备制造商10050可以通过调整获得服务信道的认证，并且通过现有线性服务和信道聚合器提供互联网信道。
为了以聚合形式呈现现有线性广播信道(例如，地面、卫星和有线信道)的列表和互联网信道列表，引导(bootstrap)10030可以基于通过现有线性网络提供的服务发现信息来操作。
在广播装置侧，可以扩展现有传统服务提供类型，并且能够以点播/组播服务(multicast service)的形式与现有的线性信道网络一起提供附加服务。另外，可以通过互联网信道的基于连接的使用报告来提供个性化服务。
从TV/STB制造商的角度来看，通过提供将OTT服务与传统T/S/C信道聚合的信道列表10040，可以获得提供各种服务和扩展终端的功能的机会。
在网络/ISP的情况下，OTT内容可以通过它们的网络基础设施来聚合，以扩展服务提供。另外，通过单播/组播的动态分配，可以提供与提供基于非管理网络的服务的终端的性能相比增强的传送性能。
换句话说，广播装置10000可以通过传统的广播网络10010和互联网网络10020发送广播数据。根据实施例的接收设备，例如，TV 10060或者第二设备10070可以向DVB-I提供商或者服务器10050请求广播数据的服务发现10030，并且接收聚合的DVB-I服务列表10040。因此，可以在传统线性信道和互联网信道这两者上执行服务信令，而无需在本地级别安装和执行单独应用的处理。
图2是从根据实施例的网络运营商/ISP的角度的根据实施例的操作的流程图。
根据实施例的设备20000可以是TV接收器。也就是说，它可以是根据支持DVB-I服务的混合IPTV/DTT网络的设备。接收设备20000可以连接到STB。例如，可以通过HDMI建立连接。IPTV STB可以通过地面网络从地面头端接收地面广播信号，并且可以通过家庭网关和宽带网络从提供组播服务的组播头端、提供DVB-I服务的DVB-I源和/或提供互联网内容的内容递送网络(CDN)等接收各种服务和/或数据。
特别地，在OTT的情况下，为每个现有终端单独提供适合于不同OS环境的OTT应用。然而，根据实施例的方法/设备可以通过基于行业标准的生态系统来使用服务，而不需要这样的单独的应用。这提供了公共服务接口，从而提供了方便和有效的服务访问。
图3示出了根据实施例的用于DVB信道服务的协议栈。
图2的TV设备20000可以基于图3的协议结构来执行图1的场景。
根据实施例的服务包括DVB C/S/T/I服务。基于构成图3的DVB-C(30000)/S(30010)/T(30020)/I(30030)服务的协议栈结构，实施例提出了用于发现通过互联网发送的DVB-I服务的机制及其信令方案。根据实施例的方法/设备可以通过服务发现来驱动应用，并且根据实施例的应用30040可以包括本地应用、预先安装的应用和用户选择的应用。
图4示出了根据实施例的DVB-I客户端的各种示例。
图4的移动设备40020、计算机40030、TV 40040、以及机顶盒或第二设备40050可以对应于/兼容图2的TV 20000。
提出了一种即使当根据实施例的接收方法/设备未连接到用于DVB-C/S/T的调谐器时也由接收设备执行DVB-I服务发现的方法。
换句话说，即使当没有安装(连接)DVB-C/S/T调谐器时，接收设备也可以连接到宽带网络，并且包括(连接到)A/V播放器模块的接收器可以执行DVB-I服务发现。配备有(连接到)DVB-C/S/T调谐器的接收器可以使用传统方法(例如，具有宽带互联网连接而没有DVB-C/S/T调谐器的设备、具有宽带互联网连接和DVB-C/S/T调谐器的设备)来执行信道扫描。
图4示出包括预先提供的URL的DVB-I客户端的各种位置。
宽带服务器40000可以将用于各种应用的URL 40010存储在数据库中。
根据实施例的连接到宽带服务器40000的接收设备可以包括移动设备40020、计算机40030、TV 40040、机顶盒或第二设备40050。
每个接收设备可以通过云40060连接到应用商店40070。
根据实施例的服务发现流程可以被配置如下。
1.基于预先提供的URL，通过宽带网络检索/获取服务发现列表表。
2.预先提供的URL可以用于如下各种模块中：A.由接收器制造商提供的DVB-I客户端模块；B.安装在由网络运营商提供的机顶盒上的DVB-I客户端模块(该模块可以是在设备内部单独实现的应用或者可以是HbbTV应用)；C.移动接收器或DVB-I客户端模块，该DVB-I客户端模块安装在从应用商店下载的应用中并且由可安装应用的接收器安装。
3.预先提供的URL可以是查询模板的形式。查询模板作为安装在接收器上的应用(包括DVB-I客户端)中的模板而完成，并且接收器可以向宽带服务器发送HTTP请求。查询模板形式可以定义如下：
http[s]：/{Recovery Base URL}/[？query]/sdlt，
其中：
方括号[..]中的[string]项指示可任选字符串，以及
花括号{..}中的{element}项指示命名的元素。
{Recovery Base URL}被预先安装在每个应用或本地应用中并且被发布，并且对于其上安装了每个应用的每个接收器或由制造商提供的每个接收器可以具有不同的URL值。
对{Recovery Base URL}的值没有限制。它们应当允许使用URL作为基础来访问宽带服务器。
[？query]字符串可以根据配置请求字符串的设备能力以应用中的模板的形式产生。
对于根据各实施例的查询项，参考图5。
4.服务发现列表表包括DVB服务列表，并且包括URL，通过该URL可以接收每个服务的信令。它还包括每个服务的有效信息。
图5示出了根据各实施例的查询项。
图5示出了根据图4的服务发现处理中的实施例的接收设备所使用的查询项的示例。
查询项C表示包括经由线缆递送的服务的ServiceDiscoveryListTable。
查询项S表示包括经由卫星递送的服务的ServiceDiscoveryListTable。
查询项T表示包括经由地面递送的服务的ServiceDiscoveryListTable。
查询项I表示包括经由互联网递送的服务的ServiceDiscoveryListTable。
查询项IPTV表示包括经由IPTV递送的服务的ServiceDiscoveryListTable。
查询项ALL表示包括经由C|S|T|I递送的所有服务的ServiceDiscoveryListTable。
图6示出了根据实施例的DVB-I服务发现查询请求的示例。
图6示出了根据基于图5的查询的实施例由接收设备60000执行查询请求的处理，图6的接收设备60000包括图2的设备20000和图4的终端40020、40030、40040和40050。
根据实施例的接收设备可以基于预先提供的URL和查询模板来执行以下操作，并且根据实施例的发送设备支持用于接收设备的操作的处理。
1.仅支持宽带网络的移动接收器(或根据实施例的接收设备60000)可以从应用商店60010下载能够实现DVB-I服务的发现的应用60020，并且安装该应用。
2.所下载的应用包括DVB-I客户端模块。该模块具有预先提供的URL。
3.为了执行DVB-I服务发现，移动接收器60000使用嵌入的预先提供的URL来配置查询形式60050。
4.由于接收器不包含DVB-S/C/T调谐器，所以它希望发现在宽带网络60030上可获得的DVB-I服务。这里，宽带网络或服务器60030被认为包括例如https://bb1.com的地址。
5.查询模板60060能够以查询形式60050配置，该查询形式请求包括其中仅DVB-I服务可以被发现的列表的服务发现列表表(SDLT或SLDT，服务列表发现表)60040。这里，SDLT可以包括其中可以发现诸如DVB-I/T/S的服务(信道)的列表表。例如，查询可以基于宽带网络的地址60030而被表达为https://bb1.com/[？query]/sldt，并且可以具有向特定服务器请求sldt的形式。
6.在接收到查询60060时，宽带服务器60030解析查询60060，并且然后通过在服务器60030中实现的响应场景向已经做出请求60060的接收器60000提供响应60070。这里，基于服务器的地址，查询60060可以表示为例如http://bb1.com/i/sldt，并且可以具有向特定服务器请求I内容(服务)的SDLT的形式。
7.响应(或对应)于请求60060的sdlt文件60070能够以XML或JSON格式web环境中可支持的任何文件格式来配置。
图7示出了根据实施例的实现基于SDLT的服务列表UI的实施例的示例设备。
图7从UI的角度图示了图6的基于SDLT的服务发现处理的详细实现操作。
实施例的接收设备可以提供服务UI/UX以便用户方便。当提供了实施例中所提出的SDLT 70000时，接收器可以在可以由用户选择的服务列表中列出基于互联网的服务以及传统地面、卫星和有线服务。图7示出了通过特定应用在TV上的UI，并且可以根据每个服务的特性为每个接收器生成并显示图标，以示出是否在互联网上发送了每个服务。另外，接收器可以另外提供信息。例如，当接收器没有连接到宽带时，它可以指示不能选择基于互联网的服务。
换句话说，实施例的接收设备70010可以通过语音/电信号/各种输入从用户接收选择信号(No.1)。这里，用户可以选择本地应用和/或下载的应用70020。为了方便用户选择，接收设备70010可以在显示器(70020)上以各种配置/类型表达UI/UX相关信息。
接收设备70010可以向嵌入在应用中的宽带服务器地址(例如，https://bb1.com,70030)请求(请求)SDLT(No.2)。
作为响应，服务器70030可以将包括所有地面、线缆、卫星和互联网服务的服务发现列表发送到接收设备70010(No.3)。
接收设备70010可以基于在SDLT中写入的服务信息以UI/UX列表的形式在显示器上呈现互联网服务以及地面、线缆和卫星服务。逻辑信道号70040、地面/有线/卫星/互联网信道指示符70050、节目/服务相关信息(标题、内容、剧集号等)70060、能力/分辨率信息等70070可以通过UI/UX显示在显示器上。
图8是根据实施例的服务发现操作的示例性流程图。
图8是参照图6和图7描述的服务发现的流程图。
1.激活根据实施例的接收设备。
2-1.当接收设备连接到宽带网络时
2-1-1.当具有DVB-I客户端的应用存在于接收设备中时
2-1-1-1.接收设备向宽带网络发送SDLT请求。
2-1-1-2.接收设备解析从宽带网络接收到的SDLT响应信息。
2-1-1-3.接收设备检查是否存在DVB-T/S/C调谐器。当存在调谐器时，基于SDLT向用户提供DVB-T/S/C/I服务。当没有调谐器时，基于SDLT仅向用户提供DVB-T服务。
2-1-2.当在接收设备中不存在其上安装有DVB-I客户端的应用时，接收设备可以从应用商店下载应用。
2-2当接收设备没有连接到宽带网络而具有DVB-T/S/C调谐器时，它接收DVB T/S/C服务并且将其提供给用户。当不存在DVB-T/S/C调谐器时，它通过UI/UX通知用户不存在可用的服务。
图9示出了根据实施例的服务发现列表表(SDLT)的语法。
图9示出了根据图8等中描述的实施例的SDLT的语法。
图9的ServiceDiscoveryListTable(服务发现列表表)可以由根据实施例的发送设备中的服务提供商、编码器(BICM)、信令生成器等生成/编码，并且可以由接收设备中的信令解析器、信令解析器等解析/获取。
根据实施例的ServiceDiscoveryListTable(SDLT)可以采取由宽带服务器通过HTTP请求提供的HTTP响应的形式，该HTTP请求根据嵌入在DVB-I客户端模块中的预先提供的URL和接收器能力以查询形式配置。
图9示出了根据实施例的XML格式的SDLT的元素和属性值的定义。
ServiceDiscoveryListTable表示该表格的根元素，并且包括服务发现所必需的服务列表。
服务表示包括在列表中的服务。
serviceId是服务的标识符。对于DVB-C/S/T，serviceId具有在serviceId+transportStreamId+initialNetworkId的范围内的唯一值。对于DVB-I，ServiceId具有在原始网络范围内的唯一值。
对于DVB-I，GlobalServiceId具有以全局唯一URI形式的值，该URI被映射到电子服务指南(ESG)中的一个服务。
OriginlNetworkId指示原始网络的标识符。
transportStreamId指示传输流的标识符。
ServiceCategory指示服务的类别，并且可以如图10所示定义。
图10示出了根据实施例的服务类别。
图10示出了图9的SDLT的服务类别元素的详细配置。
例如，服务类别的值可以被表达如下：1：线性TV服务；2：线性无线电服务；3：VoD服务；4：应用服务；5：ESG服务；6：数据服务。
SvcSeqNum是指示服务元素内的值是否已改变的序列号。当该值没有改变时，这意指服务元素内的值没有改变。当已经接收到具有相同ServiceId的服务时，接收器不需要执行重新分析。
ContentFormat指示构成服务的内容的格式。将参考图11来描述内容格式。
图11示出了根据实施例的内容格式。
图11示出了参考图10描述的各个类别的服务具有的内容格式。
例如，内容格式的值可以被表达如下：1：TS(根据MPEG-2TS格式的内容)；2：ISOBMFF(根据ISO BMFF文件结构的内容)；3：CMAF(根据通用媒体应用格式的内容)。
SvcInetUrl指示可接收服务信令或ESG的宽带服务器的URL值。
urlType指示宽带服务器URL的类型并且可以指示信令数据或ESG数据，如图12所示。
图12示出了根据各实施例的URL的类型。
图12示出了图9的SDLT的URL类型元素。
例如，URL的类型值可以被表达如下：1：服务信令服务器的URL；2：ESG服务器的URL(提供对ESG数据的访问)。
图13示出了根据实施例的添加了SdltInetUrl的SDLT语法。
图13是对应于图9的SDLT或从其附加扩展的示例。
根据实施例的方法/设备可以使用SdltInetUrl和SvcInetUrl来配置查询形式。
实施例可以使用SDLT中提供的每个服务的SdltInetUrl或SvcInetUrl来生成服务信令和ESG可访问的查询项。
实施例提出了一种发信号通知SDLT级别的宽带URL的方法。SdltInetUrl表示由接收器可访问以获取可对应于SDLT中包括的特定服务的信息的宽带服务器地址，并且可以被包括在SDLT中，如图13所示。
SdltInetUrl指示宽带服务器的URL值，从该URL值可以获取与SDLT中列出的任何服务相关的信令或ESG。
urlType可以指示宽带服务器URL的类型，并且可以根据每个定义的类型来指示信令数据或ESG数据。
在本公开中，根据实施例的URL可以被称为地址信息等。
图14示出了根据各实施例的可用于查询项的项。
图14示出了在基于图13和/或图9的SDLT来配置查询项时使用的项。
实施例提出了一种配置HTTP查询项的方法，该HTTP查询项可以使用SdltInetUrl请求服务相关信息，如下所述。图14定义了在配置HTTP请求查询中适用的项。
service_id识别期望服务。
normal|diff|template识别期望文件模式。
current|next识别期望当前/下一个版本。
list_of_signaling_object_type指示信令对象的类型，并且可以基于空间来表达。
当在SDLT中发信号通知具有urlType等于“1”的SdltInetUrl时，可以使用项<service_id>。这意指URL在SDLT级别被发信号通知的查询，但是接收器期望仅获取用于特定所需服务的信令信息。当查询项中不包括<service_id>值时，这意指请求在SDLT中发信号通知的所有服务的信令。根据实施例的接收设备可以通过基于服务ID配置查询来请求和获取用于特定服务的信令信息。
关于项normal/diff/template，当进行对DVB-I服务的请求时，相应项可以在信令对象是XML格式时被应用。
项current/next指示所请求的信令对象是当前服务的信令还是下一个版本的信令。根据实施例，当请求当前版本的信令对象时，可以省略相应项。
项list_of_signaling_object_type指示所请求的信令对象的类型(见图15)，其可以被分成空间。当请求所有信令对象时，ALL可以应用于查询项。
图15示出了根据实施例的信令对象类型的列表。
图15示出了由根据图1、4、6、7等中的实施例的方法/设备发信号通知的对象的示例。
例如，信令对象的值和由这些值指示的信息可以被配置如下：ALL：用于所请求的服务的所有元数据对象；USBD：用于所请求的服务的USBD；MPD：用于所请求的服务的DASHMPD；NIT：网络信息表；BAT：业务群关联表；SDT：服务描述表；AIT：应用信息表；DWD：分发窗口描述。
图16示出了根据实施例的使用SdltInetUrl的查询项的使用的示例。
图16是与图4、6和7的服务发现处理相关的附加示例。
根据实施例的方法/设备可以使用sdltInetUrl生成查询项，如下。
1.当接收器通过<sdltInetUrl urlType＝"1">http://aaa.bbb.com/</sdltInetUrl>获取SDLT时，接收器利用http://aaa.bbb.com/0x2107/ALL的值来配置查询项。当进行这样的HTTP请求时，宽带服务器返回当前正常版本中的用于(具有等于0x2107的@serviceId的)服务的所有信令对象。
2.当接收器通过<sdltInetUrl urlType＝“1”>http://xxx.yyy.com/</sdltInetUrl>获取SDLT时，接收器利用http://xxx.yyy.com/0x2103/next/MPD的值来配置查询项。当进行这样的HTTP请求时，宽带服务器返回下一个正常版本中的用于具有等于0x2103的@serviceId的服务的MPD信令对象。
根据实施例的接收设备16000对应于上述实施例的接收设备。接收设备16000生成查询项16010。查询项16010可以基于应用向服务器发送请求宽带服务器地址的SDLT的查询(？query)。
根据实施例的服务器16030对应于根据上述实施例的宽带服务器。服务器16030包含服务器的地址，例如https://bb1.com，并且服务器的数据库包含用于诸如I/T/S的服务的SDLT。
响应于查询16020，接收设备16000从服务器16030接收SDLT 16040。
SDLT 16040可以包括URL类型为1的用于信令的服务器的地址，可以识别用于例如http://aaa.bbb.com或每个服务ID的服务信令的信息，诸如例如2107，2107。
接收设备16000可以基于SDLT 16040生成要发送到信令服务器16050的查询项16060，并且将查询项16060发送到信令服务器16050。查询项16060可以包括信令服务器16050，包括请求信令信息的服务的标识符，并且包括请求关于特定服务的标识符的所有信令信息的信息。信令服务器16050可以在数据库中存储关于每个服务标识符的服务的信令信息。接收设备16000可以从信令服务器16050接收信令对象16070作为与请求相对应的响应信息。信令对象16070包括关于特定服务的标识符的信令信息。根据实施例，服务器可以包括包含SDLT的服务器16030和/或包含用于每个服务的信令对象的服务器16020。服务器可以被称为各种项，诸如宽带服务器、互联网服务器、通信网络服务器和信令服务器。另外，服务器可以被分类为上述两个服务器，或者可以被集成到一个服务器中。
图17示出了由根据实施例的方法/设备提供的UI/UX的示例。
图17示出了图4、6、7、16等的UI/UX示例的附加相关示例。
根据实施例的UI/UX操作的流程图可以被配置如下。
1.接收设备(包括根据上述实施例的接收设备)可以从广播信号或从网络获取SDLT，或者可以具有所存储的SDLT。SDLT包含基于URL类型值的SDLT互联网URL，并且包含一个或多个服务ID。
2.接收设备可以从用户接收输入信号。接收设备可以基于UI/UX向用户显示服务列表。输入信号可以是关于用户期望查看的对象的信息。接收设备可以向用户提供通知信息(可听或可视菜单/图标等)以指示接收设备是否支持地面、线缆或卫星服务。此外，通过通知信息，接收设备可以询问用户是否检查互联网服务列表(DVB-I内容)。
3.当接收设备从用户接收到信道列表图标选择信号时，接收设备基于SDLT向用户提供互联网服务列表。如在上述实施例中，接收设备可以在显示器上显示服务的信道号、信道类型(地面、线缆、卫星、互联网等)、属于服务的节目的名称、节目的概要、服务的分辨率、能力信息等。
4.接收设备可以从用户接收用于选择特定服务的信道号33-7的信号。
5.响应于用户的选择，接收设备向信令服务器请求与URL类型等于1和服务ID等于0X2107相对应的信令。
6.响应于从接收设备到信令服务器的请求，接收设备可以从信令服务器接收关于与33-7相对应的服务的服务信令信息。
图18示出了根据实施例的元数据封装类型。
图18的元数据封装可以是信令对象中的作为关于服务的信令信息的信令对象(见图19)。
根据实施例的方法/设备可以执行用于DVB-I服务的HTTP响应信令方案。
在下文中，将描述在接收用于在宽带网络上进行的DVB-I服务信令HTTP请求的HTTP响应时所使用的DVB-I HTTP响应信令方案。
在接收到接收器已经使用SdltInetUrl或SvcInetUrl向宽带服务器作出的HTTP请求的HTTP响应时，应当允许接收器检查该响应是否满足接收器作出的请求。另外，实施例可以执行以下操作，使得可以在最快时间获取最新信息。
包含DVB-I服务信令对象的HTTP响应在metadataEnvelope(元数据封装)结构中携带。根据实施例的DVB-I服务信令的metadataEnvelope被配置为如图18所示的metadataEnvelopeType。
metadataEnvelope由项元素序列组成，并且每个项表示相应信令对象。如图18所示，项元素由metadateEnvelopItemType定义。
nextUrlAvailableTime指示用于向宽带服务器做出HTTP请求的可能开始时间，其中nextUrl指示下一个版本的信令。提出该属性值以减少在宽带网络上通过请求/响应处理获取信令对象的接收器的请求错误。接收器可以根据实现算法计算该属性值与validUntil的属性值之间的最佳时间，以降低接收器请求集中以及接收器未能接收到响应的概率。
nextUrl指定指示下一个版本的信令对象的宽带URL地址值。
metadateEnvelopeType被包括在由接收器接收到的响应信息中。
元素名称被指示为项，而类型指示metadateEnvelopeItempeType。
metadateEnvelopeItempeType表示元数据封装项的类型。
元素名称可以是元数据段，并且类型可以是字符串。
属性名称可以是metadataURI，并且类型可以是anyURI。
属性名称可以是版本，并且类型可以是positiveInteger。
属性名称可以是validFrom，并且类型可以是dateTime(日期/时间)。
属性名称可以是validUntil，并且类型可以是dateTime(日期/时间)。基于validFrom和validUntil，元数据可以指示响应信息的有效时间。
属性名称可以是contentType，并且类型可以是字符串。
属性名称可以是nextUrlAvailableTime，并且类型可以是dateTime(日期/时间)。该属性指示下一个可用时间。
属性名称可以是nextUrl，并且类型可以是anyURI。
如图18所示，上述属性可以基本上或可选地存在，或者可以省略。
图19示出了根据实施例的基于元数据封装的HTTP响应的示例。
图19示出了基于图18的元数据封装和图9、13的SDLT等的服务信令。
根据实施例，接收器使用metadataEnvelope根据由接收器做出的HTTP请求从宽带服务器接收DVB-I服务的信令作为响应。
在实施例中，发信号通知USBD的nextUrl和nextUrlAvailableTime。因此，当前USBD直到例如8月10日的12点是有效的，并且下一个版本的USBD从例如8月10日的0点在在下一个URL地址上可下载。因此，允许接收器下载USBD的下一个版本达在存在大量业务的时间之外可用的12小时。
接收设备19000(对应于根据上述实施例的接收设备)检查SDLT19010。SDLT 19010包括URL TYPE和SERVICE ID。
接收设备19000可以向信令服务器19030请求与特定服务(例如，具有等于0X2107的服务ID的服务)相对应的信令的所有信息(ALL)。
接收设备19000可以从信令服务器19030接收与对请求的响应相对应的信令对象19040。信令对象19040包括关于与所请求的服务标识符相对应的服务的信令信息。如上所述，信令对象1940能够以元数据封装的形式来表达。信令对象1940可以包括USDB的项和MPD的项。对于每个项，信令对象1940可以基于元数据分段而包括版本信息、validUntil、用于下一个信息的地址(nextUrl)、以及用于下一信息的可用时间(NextUrlAvailableTime)。
图20示出了根据实施例的DVB-I服务信令机制。
图20示出了可以另外应用于图1、4、6、7、8、16、17、19等的DVB-I服务信令的类型及其机制。
根据实施例的方法/设备在特定类型的元数据中生成/配置基于互联网的服务的服务信令，并且提出包括在每个元数据中的服务信息的定义。根据实施例的发送方法/设备可以生成和发送这样的信令信息，并且根据实施例的接收方法/设备可以接收信令信息并且执行服务发现。
在DVB-I服务的情况下，连接到宽带服务器的接收器应该能够播放音频(A)/视频(V)/字幕内容，而不管是否安装了DVB-C/S/T调谐器。提出了一种响应于由接收器做出的对服务的信令的请求而由宽带服务器提供的DVB-I服务的服务信令配置。
如图20所示，包括在DVB-I服务的服务信令中的信息取决于每个元数据信令对象的角色和配置。实施例提出了一种由四种类型的信令元数据组成的DVB-I服务信令方案。
以下信令信息可以被称为各种项，诸如第一信息、第二信息、第一信令信息和第二信令信息。
UserServiceBundleDescription(用户服务捆绑描述)(USBD)：发信号通知关于DVB-I服务的信息，并且在DVB-I线性服务的情况下包括关于MPD的URL信息。
MediaPresentationDescription(媒体呈现描述)(MPD)：在DVB-DASH中使用的信令元数据。相应元数据的使用和信令信息如MPEG-DASH中所定义。
应用信息表(AIT)：当DVB-I服务是由应用驱动的服务时，USBD可以通告用于AIT信令的URL以用于连接该应用。
分发窗口描述(DWD)：DVB-I服务可以在其开始显示静止图像或正常文件时向用户提供关于该服务的信息。在这种情况下，USBD可以通告链接DWD的URL，该DWD用信号通知关于何时分配静止图像的调度信息。
另外，上述元数据可以具有以下引用关系。USBD可以引用USD。USBD可以引用DWD和/或AIT。此外，USBD可以根据服务/信令递送方法来引用MPD。
图21示出了根据实施例的USBD的示例。
图21对应于图20的USBD。
根据实施例的发送方法/设备可以发送USBD，或者根据实施例的接收方法/设备可以基于来自发送设备和/或服务器的服务发现信令来获取USBD。
将描述根据实施例的DVB-I服务的UserServiceBundleDescription的配置。
根据实施例的USBD可以描述DVB-I服务的综合信息，并且提供服务信令系统，该服务信令系统用作用于连接USBD/USD向用户提供每种服务所需的其他信令元数据的起始点。
根据实施例的USBD可以被配置为仅包括一个用户服务描述(USD)。USD包含关于用户服务的综合信息以及关于如何以及何时可以向用户提供服务的信息。图21描述了USBD/USD的语法。
UserServiceBundleDescription：是DVB-I的USBD的根元素。
UserServiceDescription(用户服务描述)：指示DVB-I服务的单个实例。
@serviceId：是unsignedShort类型的服务标识符，并且具有与在用于发现基于互联网的服务的SDLT信令表中描述的值相同的值。该值可以引用SDLT中的相应服务条目。
@globalServiceId：具有anyURI类型的全局唯一服务标识符值。该值与ESG中使用的全局服务ID的值相匹配，并且可以用作用于映射到特定类型的服务的信息。在一些服务类别中，可以不使用该值。该值可以引用ESG(电子服务指南)信息中的相应服务条目。
@serviceCategory(服务类别)：由unsignedByte类型的整数值来区分，并且表示服务类别。即，@ServiceCategory可以表示服务的类别，并且类别可以包括线性TV、线性无线电、点播或应用服务。针对特定类别，参照附图。
@hidden(隐藏)：指示该服务是隐藏在服务列表中还是向用户示出。该字段具有布尔类型的属性值，并且指示是否应当在服务列表中向用户示出服务。当没有指示该值时，默认值是FALSE(假)，这意指向用户示出服务。
@appRendering：指示是否有任何应用将首先被执行并且渲染该服务。它具有布尔类型的属性值，并且指示在向用户示出服务时是通过嵌入在接收器中的模块还是通过特定应用提供服务。当该值为TRUE(真)时，接收器可以起到等待应用被驱动的作用，并且该信息可以被提供给用户。当没有呈现该值时，这意指假，并且应用不执行渲染。因此，接收器执行立即渲染服务的功能。
@MediaPresentationDescription(媒体呈现描述)：指示指向MPD信令描述的URL。它具有可被指示为可选的anyURI类型的属性值，并且指定MPD文件通过宽带可下载的URL。
@ApplicationInformationTable(应用信息表)：指示指向AIT信令描述的URL。它具有可以被指示为可选的anyURI类型的属性值，并且指定描述应用信息的AIT表可以通过宽带下载到的URL。
@DistributionWindowDescription(分发窗口描述)：指示指向DWD信令描述的URL。它具有可以被指示为可选的anyURI类型的属性值，并且指定了其中DWD即描述可以接收与服务相关的文件的时间的信令表在宽带网络上可下载的URL。
RunningStatus(运行状态)：指示该服务的状态。例如，状态可以包括运行、没有运行或在几秒内开始。该值表示unsignedByte类型的元素值，并且可以指定当前服务的运行状态。
@duration(持续时间)：可以在RunningStatus没有运行或正在暂停时以秒指示暂停持续时间。它具有一个属性值，该属性值具有unsignedInt类型的整数值。当RunningStatus具有不同于1的值时，即，当RunningStatus没有运行时，它可以指定以秒为单位的持续时间。
@resumeTime(恢复时间)可以指示当RunningStatus没有运行或暂停时的恢复日期/时间。它具有dateTime类型的属性值。当RunningStatus具有不同于1的值时，@resumeTime可以指定当服务被恢复时的日期/时间。
Name(名称)：指示DVB-I服务的名称。它具有字符串类型的元素值。
@lang：指示DVB-I服务名称的语言。它具有lang类型的属性值。
ServiceLanguge(服务语言)：指示DVB-I服务的可用语言。
Icon(图标)：指示指向图标(或图像)的URL。多个URL可以用于指向图标或图像。在这种情况下，可以发信号通知不同宽度、高度或分辨率格式的图标/图像。Icon具有可被指示为可选的元素值，并且可具有一个或多个值。它可以是anyURI类型的URL，并且可以是指示每个文件的宽带URL。每个文件可以指向在提供服务之前应当在屏幕上显示的静止图像或图标。Icon元素具有以下属性值以提供关于接收器是否能够渲染文件的信息。
@mimeType：可以指示图标的可选MIME类型，其允许接收器忽略不适合使用的图像类型。它具有字符串类型的属性值，并且以MIME类型形式配置。
@width(宽度)：能够以像素为单位指示参考图像的宽度。它具有unsignedInt类型的属性值，并且以像素为单位指定宽度。
@height(高度)：能够以像素为单位指示参考图像的高度。它具有unsignedInt类型的属性值，并且以像素为单位指定高度。
@dataSize(数据大小)：能够以字节为单位指示图像数据的大小。它具有unsignedInt类型的属性值，并且以字节为单位指定大小。
@displayDuration(显示持续时间)：能够以秒为单位指示图标(图像)显示持续时间。它具有unsignedInt类型的属性值，并且指定图标或图像在屏幕上显示的以秒为单位的持续时间。
DeliveryMethod(递送方法)：可以指示在宽带中是否广播或可选地发送/接入包括服务内容的传输相关信息的容器。该字段是与构成相应服务的数据的传输信息有关的信令信息，并且可以根据@serviceCategory不被指示，或者可以被指示为多个元素值。通过子元素值来指示关于容器是通过广播网络还是通过宽带网络来发送的信息。
BroadcastAppservice(广播应用服务)：指示通过包含属于DVB-I服务的相应媒体组件的广播递送的DASH表示。在线性A/V服务或线性音频服务的情况下，DASH表示可以通过广播网络发送以配置服务。在这种情况下，可以指示多个元素值。
BasePattern(基本模式)：指示由DVB-I接收器用于与由DASH客户端用来请求父DASH表示的DASH媒体片段的片段URL的任何部分进行匹配的字符模式。该值用于指示通过广播网络发送的DASH表示的基本URL，可以由一个或多个值组成。它应当匹配MPD中描述的基本URL值。
UnicastAppService(单播应用服务)：指示在包含属于DVB-I服务的媒体内容分量的宽带上递送的DASH表示。在线性A/V服务或线性音频服务的情况下，可以通过在宽带网络上发送DASH表示来配置服务。在这种情况下，可以指示多个元素值。
BasePattern(基本模式)：用于指示通过宽带网络发送的DASH表示的基本URL，可以由一个或多个值组成。它应当匹配MPD中描述的基本URL值。
此外，USBD的配置可以取决于如图10中定义的@serviceCategory的值。
在线性TV服务和线性无线电服务的情况下，USBD/USD实质上包含MPD URL(@MediaPresentationDescription)。MPD URL值意指接收器可以直接访问宽带服务器并且获取文件的URL。由于可以包括应用，所以可以可选地包括AIT URL(ApplicationInformationTable)。
在VOD服务的情况下，可以不包括MPD URL(@MediaPresentationDescription)。在首先渲染应用以显示VoD列表的情况下，@appRendering的属性值被设置为TRUE，并且必须包括AIT URL。
在应用服务的情况下，AIT URL基本上存在，而不管@apprendering具有什么值，并且MPD URL可以可选地出现。
ESG服务指示发送ESG数据的特定服务。在这种情况下，AIT URL(@ApplicationInformationTable)和MPD URL(@MediaPresentationDescription)在USBD/USD中不发信号通知。
数据服务指示发送数据的服务。在这种情况下，AIT URL和MPD URL在USBD/USD中不发信号通知。
图22示出了根据实施例的RunningStatus。
图22示出了图21的运行状态的特定值。
当上述RunningStatus没有运行时，即，当它具有2、3、4或5的值时，它根据情况而具有@duration或@resumedTime的子属性值。当没有给出值时，可以将默认值指示为无穷值。
RunningStatus可以包括运行、没有运行、暂停、在几秒内的开始以及服务停播。
图23是示出了根据实施例的基于互联网的服务的USBD和MPD获取的流程图。
图23是示出根据实施例的接收设备基于与图20等相关的信令信息获取服务信令的流程图。图23可以是与上述图4、6、7、16、17和19的服务获取/发现处理相结合的示例。
将描述根据实施例的根据用于基于互联网的服务的服务信令机制方法从由接收器通过服务发现获取的信令数据获取服务的信令来向用户提供服务的流程图。
关于根据实施例的方法/设备，该示例示出了当线性A/V服务是基于互联网的服务时指示MPD的URL被插入到USBD中，并且USBD/USD/DeliveryMethod/BasePattern的URL值必须与在MPD中发信号通知的BaseURL的值相匹配。
在图23的描述中将省略或简要描述上述附图和上述段落中描述的细节，并且可以参考上述实施例。
1.接收设备可以使用SDLT来示出互联网服务的列表。SDLT可以包括如图24所示的信息。
2.接收设备从用户接收用于选择与33-7相对应的服务(DVB-I)的信号。
3.接收设备使用URL TYPE和服务ID的值向宽带服务器请求与特定服务ID相对应的信令信息，例如USBD。
4.接收设备从服务器接收与服务33-7相对应的USBD作为响应。
5.接收设备可以确定存在来自USBD的与服务33-7相对应的MPD，向服务器请求MPD，并且从其接收响应。
接收设备通过USBD的全局服务ID确定ID为0X2107的服务为KBS体育，并且通过USBD的媒体呈现描述确定该服务的MPD。接收设备可以通过所获取的MPD检查与服务器地址的33-7相对应的用于服务的体育的基本URL。接收设备可以基于上述服务发现信令来显示用户所期望的服务。
图24示出了根据实施例的基于RunningStatus的UI/UX的示例。
图24示出了基于图22的RunningStatus的与图23等相关的操作。
图24示出了根据实施例的接收器可以实现以向用户提供与RunningStatus元素值有关的信息的UX/UI，其中RunningStatus元素值用于指示USBD/USD的信令方案中的服务的状态。
实施例的示例示出了当RunningStatus暂停时，接收器在检查@appRendering的属性值之后确定应用不执行渲染，使用接收器UI向用户提供暂停持续时间，并且使用接收器应用在屏幕上显示体育事件的分值直到当前时间。
在图24中，操作1和2与上述实施例相同/相似。参考操作3和后续处理，接收USBD的接收设备可以基于USBD的信息识别出运行状态在30秒的持续时间暂停，并且以UI/UX的形式在显示器上显示相关信息。例如，基于图像/图标/声音信息，它可以向用户递送“广播在30秒内开始”的信息。关于操作4，接收设备向服务器请求用于服务33-7的MPD，并且接收所请求的信息作为响应。关于MPD，周期元素包含自适应集合，并且自适应集合元素包含表示。表示元素包含基础URL。基础URL可以由诸如服务器地址、服务ID、服务类别(体育)等信息组成。接收设备可以基于USBD和/或MPD在30秒之后播放体育服务。
图25是根据实施例的USBD信令处理的流程图。
图25图示了根据实施例的接收设备基于参照图20至图25描述的服务信令信息获取并且播放各种类型的服务的流程。图25可以与图8的流程图等组合。
根据实施例的方法/设备的信令流程图被配置如下。
在操作2500中，根据实施例的设备接通电源。接收设备检查该设备是否连接到宽带或通信网络。
在操作25010，当接收设备未连接到诸如互联网的通信网络时，检查接收设备中的DVB-T/S/C调谐器，或者检查是否能够接收DVB-T/S/C服务。当接收设备不能接收DVB-T/S/C服务等时，接收设备可以向用户显示或通知没有可用服务。当可以接收DVB-T/S/C服务等时，接收设备向用户提供DVB-T/S/C服务等。
在操作25020，当接收设备连接到互联网网络等时，检查在接收设备中是否存在存储的服务发现列表(或信息)。当在接收设备中不存在服务发现信息时，接收设备执行获取服务发现列表的操作。当在接收设备中存在服务发现信息时，接收设备从用户接收用于选择服务的信号(信息)。
在操作25030中，接收设备可以向信令服务器发送由SDLT发信号通知(指示)的USBD请求。USBD请求可以包括服务类别是线性的情况。当服务类别是线性时，接收设备可以向信令服务器请求MPD并且获取MPD。接收设备可以基于该信令处理来播放线性A/V服务。当服务类别不是线性时，服务信令处理可以取决于appRendering的值是TRUE还是FALSE而变化。当appRendering为TRUE时，接收设备可以向信令服务器请求AIT，并且获取AIT以播放应用。当appRendering为FALSE时，接收设备可以播放本地应用。
图26示出了根据实施例的服务发现列表表的扩展语法。
图26的SDLT可以对应于图5、6、7、8、9、13、16、17、19、23、25等的SDLT。
根据实施例的方法/设备可以配置SDLT以用于DVB-I服务的更快服务发现和服务获取。
实施例提出了如图26所示的服务发现列表表(SDLT)和USBD配置方案，以便更快速地提供由用户从可以通过服务发现处理提供给用户的服务中所选择的服务。
SDLT可以是接收器必须首先用于服务发现的基本信息。通过该信令数据，接收器可以提供允许用户选择服务的服务列表信息。在这种情况下，SDLT可以被配置为包括更多信息。该配置信息可以使得能够提供丰富服务量，并且使得能够在用户选择服务时更快地播放该服务。
当SDLT以这种方式被配置时，基于互联网的服务的信令元数据中的USBD可以包括提供映射到MPD的信息的DeliveryMethod元素值，并且@serviceId和@globalServiceId信息可以用作用于映射到SDLT的信息和用于映射到ESG的信息。
将参考附图描述SDLT的每个元素。
ServiceDiscoveryListTable表示根元素。
SdltInetUrl指示用于访问信令/ESG对象的URL。
@urlType指示利用该URL可用的文件的类型。
Service表示服务信息。
@serviceId指示在originalNetworkId(原始网络Id)的范围内唯一地识别该服务的数字。
@globalServiceId指示全局唯一服务标识符。它被映射到ESG中的全局服务ID。对于传统的DVB/T/S/C服务，该属性可能不存在。
@originalNetworkId指示唯一地识别最初从其生成该服务的原始网络的数字。
@transportStreamId指示唯一识别传输流的数字。这种属性存在于传统的DVB-T/S/C服务中。然而，该属性可能对于ISO BMFF格式的DVB-T服务而不存在。
@frequfferyNum指示唯一地识别物理层的频率编号的编号。当服务是传统的地面服务时，可以存在该属性。
@serviceCategory指示该服务的类别。类别可以是线性的、点播的或应用服务。
@svcSeqNum指示服务信息的版本。对于RFG中的每个新版本的服务数据，可以将其递增1。
@contentFormat指示该服务的内容的格式。
@hidden指示该服务是隐藏在服务列表中还是显示给用户。@hidden的默认值是FALSE。
@appRendering指示是否首先执行任何应用或渲染该服务。默认值是FALSE。
@MediaPresentationDescription是指向MPD信令描述的URL。
@ApplicationInformationTable是指向AIT信令描述的URL。
@DistributionWindowDescription是指向DWD信令描述的URL。
RunningStatus指示该服务的状态。
将省略对先前描述的属性的描述。
下面将描述当使用扩展SDLT时应用的USBD的语法。
图27示出了根据实施例的简化USBD的语法。
图27的USDB可以对应于图20、21、23、24、25等的USBD。
UserServiceBundleDescription是DVB-I的用户服务捆绑描述的根元素。
UserServiceDescription是DVB-I服务的单个实例。
USBD的配置可以如图27所示简化。对于每个元素的细节，参考上面的描述。
图28示出了根据实施例的用于使用扩展SDLT提供服务列表和服务的UI/UX。
图28的SDLT、USBD和MPD可以分别对应于图5、6、7、8、9、13、16、17、19、20、21、23、24、25、26、27等的SDLT、USBD和MPD。另外，图28可以与图7、17、23、24等的UI/UX实现方式相结合。
下面将描述根据实施例的方法/设备使用扩展SDLT的服务发现的流程图。
1.接收设备(对应于根据上述实施例的接收设备)使用SDLT向用户提供服务列表。如上所述，SDLT包括URL类型、每个服务ID的服务类别、媒体呈现描述和运行状态。
2.接收设备可以在显示器上显示服务运行状态和开始时间相关信息。接收设备的显示器可以通过UI/UX显示ESG和服务相关信息。例如，对于信道号33-7，可以显示诸如DVB-I内容显示、HD、BB、KBS SPORTS(LG对比Doosa)、“该广播在30秒内开始”等的信息。
3.接收设备可以向服务器请求服务33-7的MPD和USBD，并且从服务器接收响应。
4.接收设备可以在30秒之后从用户接收用于由用户选择服务33-7的信号。
5.接收设备可以显示用户所期望的服务。
图29是图示了根据实施例的扩展SDLT和简化USBD的使用的流程图。
图29是图示使用根据上述实施例的SDLT和USBD由根据实施例的接收设备获取和播放服务数据的方法的流程图。图29可以与图25的流程图等组合。
在操作29000，根据实施例的方法/设备在接收器的电源被打开之后检查在接收设备中是否存在存储的服务发现列表。当不存在所存储的列表时，执行用于接收服务发现列表的操作。接收设备可以获取包含在广播信号中的服务发现列表，或者可以从服务器获取服务发现列表。当存在存储的列表(包括根据上述实施例的服务发现信息)时，接收设备接收关于由用户所选择的服务的信号/信息。
在操作29010中，接收设备检查用户选择的服务是否是基于互联网的服务。当所选择的服务不是基于互联网的服务时，该设备检查在接收设备中是否存在DVB-T/S/C调谐器。当没有调谐器时，该设备向用户通知没有可用服务。当存在调谐器时，接收设备提供DVB-T/S/C服务。
在操作29020中，当服务是基于互联网的服务时，接收设备检查服务类别是否是线性的。当服务类别是线性时，接收设备向服务器发送MPD请求并且接收MPD响应。接收设备基于MPD播放线性A/V服务。
在操作29030中，当服务类别不是线性时，设备检查appRendering是否为真。当appRendering不为真时，接收设备播放本地应用。当appRendering为真时，接收设备向服务器发送AIT请求并且接收AIT响应。接收设备基于AIT播放应用。
图30示出了根据实施例的指示位置信息的LocationInfo元素的语法。
图30示出了根据上述实施例可以在SDLT中另外递送的位置信息。图30可以是与图26等相关的SDLT的示例。
根据实施例的方法/设备可以附加地发信号通知可以为其提供服务的位置信息。
实施例提出了一种在服务发现信令中包括位置信息以便根据接收器的位置过滤服务或服务列表的方法。
实施例提出了一种显示如图30所示的位置信息的方法，该位置信息可以由各种方法来指示。
1.根据实施例的LocationInfo可以使用注册的国家代码和城市名称来提供区域信息。由于以文本形式提供了人类可识别的区域信息，所以即使当接收器没有识别出位置信息时也可以在接收器解析之后将其提供给用户。
2.根据实施例的LocationInfo允许以圆形形状绘制关于提供服务的区域的信息。这允许通过提供三种简单信息来包括综合区域信息。
3.根据实施例的LocationInfo通过提供西南端点和东北端点的纬度和经度使得可以绘制矩形来提供4种位置信息。
4.根据实施例的LocationInfo可以通过提供允许构造多边形的多边形位置信息来提供更精确位置信息。
5.根据实施例的LocationInfo可以允许连接到互联网的接收器的IP是已知的，并且允许在IP地址所属的类别的区域中提供相应服务。
根据实施例，可以通过SDLT发信号通知如上所述的LocationInfo信息，并且可以将其定位在两个级别。当其被定位在SDLT之下时，可以提供关于属于SDLT的所有服务的位置信息。当LocationInfo被定位在服务之下时，它可以提供关于可以提供相应服务的位置的信息。当在SDLT和服务中呈现的区域信息中提供不同信息时，在服务中提供的位置信息优先。
图31示出了根据实施例的包括位置信息的SDLT。
图31示出了图30的SDLT等的具体示例。
LocationInfo：可以指示各种类型的位置信息的元素。它指示与包括在SDLT中的所有服务相对应的位置信息。
可以将LocationInfo 31000发信号通知作为对于由SDLT发信号通知的整个服务列表公共的信息。
可以为由SDLT发信号通知的每个服务提供LocationInfo 31000。
图32示出了根据实施例的提供区域信息的SDLT和接收器的操作的示例。
图32示出了基于与图31相关的SDLT等实现的UI/UX操作。
图32示出了接收设备使用包括LocationInfo(其可以被称为位置信息、区域信息等)的SDLT提供基于区域的服务的流程。
下面描述根据实施例的配置UX/UI和SDLT的方法。
图32示出了包括区域信息的SDLT的配置示例。例如，当通过广播在法国提供的两个服务是仅在不同城市提供的服务时，在SDLT和服务下发信号通知相应的区域信息。已经获取SDLT的接收器可以根据所提供的信息向用户显示服务列表。在这种情况下，能够提取关于接收器所处位置的信息的接收器可以根据SDLT所提供的位置信息向用户显示过滤的服务列表。
根据实施例的方法/设备的操作在如下流程图中执行。
1.接收设备(包括上述实施例的接收设备)使用SDLT向用户提供服务列表。根据实施例的SDLT还可以提供LocationInfo。
2.接收设备可以基于LocationInfo元素检查关于接收器所处位置的信息，通过比较来配置服务列表，并且在显示器上显示所配置的服务列表。例如，服务33-7是巴黎新闻，而服务33-8是凡尔赛新闻。这里，凡尔赛新闻可以是仅在凡尔赛地区查看的新闻。基于SDLT，接收设备可以向用户提供“该广播仅在凡尔赛区域可用”作为33-8服务指南信息。
接收设备包括TV或移动设备。在这种情况下，接收设备可以基于由LocationInfo元素指示的信息，将移动设备(或TV)的位置与LocationInfo的位置信息进行比较，并且可以显示反映比较结果的服务列表。
3.接收设备可以从用户接收用于由用户在过滤的服务列表中选择的服务的信号。用户可以在过滤的服务列表中选择可选择的服务。
图33是根据实施例的接收器通过提供区域信息的流程图。
图33是接收器基于与图31相关的SDLT等提供服务信息的流程图。图33可以与关于图29等的流程图结合。
在该流程图中的与上述操作相同/类似的操作可以被省略或简要描述，并且可以参考对上述操作的描述。
在操作33000，当接收器(接收设备)的电源被接通时，接收器检查是否存在存储的服务发现列表。当存在存储的服务发现列表时，接收器获取每个SDLT服务的区域信息。
在操作330010，接收器检查是否可以提取接收器区域信息。当不能提取区域信息时，接收器可以选择任何服务。当用户选择与SDLT所提供的本地信息不匹配的服务时，接收器向用户通知该服务不可用。
在操作330020，接收器提取接收器区域信息，并且检查接收器区域是否包括在SDLT区域信息中。当不包括位置时，接收器通知用户，使得用户不能选择服务列表中的服务。当包括位置时，接收器向用户通知用户可以选择服务列表中的服务并且播放与用户选择相对应的服务。
图34示出了根据实施例的与设备相关的DVB组件和接口的示例配置。
图34的DVB-I播放器34000可以对应于根据实施例的接收设备。图34示出了接收设备从服务器获取服务信令信息等的流程图。DVB-I播放器34000可以对应于接收设备，该接收设备对应于图1的DVB-I传输、图2的TV 20000、图4的移动设备40020、图4的计算机40030、图4的TV40040、图4的机顶盒或第二设备40050、图6的移动设备60000、图7、17、23、24、28、32、57、86和87的TV、图16和19的移动设备、图58的接收设备、图75中的DVB-I客户端75000的设备、图77和89的接收设备等。
根据实施例的方法/设备可以实现接收DVB-I聚合服务列表信令的方法。
在上面，已经定义了用于在宽带网络上请求DVB-I服务描述的查询形式。DVB-I终端通过预先提供的URL发送查询并且接收包括所有DVB-I服务列表的聚合服务列表。
图34是图示了执行DVB-I服务发现和接收内容的处理的图。在接口B上，以规则间隔发送服务列表查询并且接收服务列表。例如，对应于根据实施例的接收设备34000的广播装置3410或发送设备34010可以将内容指南服务器的内容指南数据B1和/或URL B2发送到内容指南服务器。发送设备34010可以将服务列表分段D发送到服务列表服务器。接收设备34000(DVB-I播放器)可以将内容指南查询C1发送到内容指南服务器，并且从内容指南服务器接收内容指南数据C2。接收设备34000可以向服务列表服务器发送服务列表查询A1，并且从服务列表服务器接收聚合服务列表A2。
接口C是接收设备34000通过在聚合服务列表表中定义的SdltInetUrl或SvcInetUrl或通过预先提供的URL接收内容指南的处理。将所接收的内容指南与现有广播信道一起聚合到特定逻辑信道中以示出服务。内容/服务提供商提供内容指南数据，以允许DVB-I终端34000访问内容指南服务器。此外，以规则间隔通过接口D周期性地提供服务列表分段，以允许DVB-I终端接收聚合服务列表。接收设备35000通过在所接收的聚合服务列表表中定义的MPD URL请求MPD，并且接收期望线性服务。
广播/发送设备34010从MPD服务器34020接收MPD的URL(E1)。MPD服务器34020从流服务器34030接收(G)用于媒体的URL。接收设备34000向MPD服务器34020发送对DASH MPD的请求F1并且从MPD服务器34020接收DASH MPD F2。
流服务器34030从接收设备34000接收对媒体的请求H1，并且向接收设备34000发送单播DASH H2。流服务器34030可以连接到组播服务器。接收设备34000可以连接到组播网关。组播网关和组播服务器用于发送组播Y1和交换单播修复Y2。接收设备34000从组播网关接收单播DASH Z1。
图35示出了根据实施例的用于接收服务列表的元数据封装。
图35示出了图18和图19的元数据封装的配置。
在图35中，DVB-I终端应该周期性地通过接口A发送用于请求聚合服务列表的HTTP请求查询，并且应该检查所接收的响应信息是否是最新信息。然而，不存在用于确定根据查询的响应是否是最新版本信息的信息。因此，实施例另外提出了一种快速检查响应信息是否是最新信息并且确定是否接收和解析信息的方法。
元数据封装：当根据实施例的方法/设备发送HTTP请求并且接收到对其的HTTP响应时，必须允许检查返回的响应是否满足发送的请求。第二，实施例旨在确保可以在最快时间获取最新信息。第三，聚合服务列表应当具有多个服务列表，使得仅识别最新信息。
在metadataEnvelope结构中携带包括DVB-I服务聚合服务列表信令对象的HTTP响应，并且例如，针对RFC 2387的每个多部分/相关容器发送每个服务列表。metadataEnvelope不附加到每个服务列表，而是被定位在顶部并且引用每个分段的服务列表。根据实施例的DVB-I服务信令的metadataEnvelope由图36所示的metadataEnvelopeType组成，并且该类型由以下模式定义。
例如，metadataEnvelope可以具有XML格式，并且可以为每个多部分容器发送服务列表。
图36具体示出了根据实施例的元数据封装。
图36对应于图18、19、35等中描述的元数据封装。
通过图34的接口A1，HTTP请求形式的查询被发送到服务列表服务器，并且以如图35所示的元数据封装形式聚合的服务列表被接收作为接收数据。
metadataEnvelope由一系列项目元素组成。每个项目表示相应信令对象。项目元素由metadataEnvelopeType定义。
元数据URI指示聚合服务列表的地址，并且“version(版本)”和“validfrom”/“validUntil”指示文档/信息的有效时间。ContentType(内容类型)指定当前包括的聚合服务列表中的特定服务的标识符。
ContentType的字符串具有如下所示的模板形式，并且该信息对于每个服务具有唯一值：
ContentType＝“Application/DITS-(OriginalNetworkID)-(TransportStreamID)-(serviceID)+xml”
通过该信息，可以检查在聚合服务列表中改变的服务的版本信息，然后可以获取更新信息。因此，根据实施例的接收方法/设备可以仅搜索和更新特定服务的改变值，而不接收整个服务列表。
nextUrlAvailableTime：指示用于通过指向下一版本的信令的nextUrl向宽带服务器做出HTTP请求的可能开始时间。提出这个属性以减少在宽带网络上通过请求/响应处理获取信令对象的接收器的请求错误。在该属性值和validUntil的属性值之间的持续时间内根据接收器的实现算法计算最佳时间，以减少由于接收器请求的集中而导致未能接收到响应的概率。
nextUrl：指示指向下一个版本的信令对象的宽带URL地址值。
图37示出了根据实施例的DITS服务发现元数据封装。
图37示出了一种与图18、19、35、36等相关的元数据封装的容器具有标识符、类型、内容类型和元数据URI的配置。
图37的元数据封装是当在多部分/相关容器中携带针对每个唯一服务分段的服务列表时配置的服务列表元数据封装。每个服务的contentType被编码并且发送作为(OriginalNetworkID)-(TransportStreamID)-(serviceID)，其是DITS中的唯一信息。可执行包括该信息和版本信息的版本化和期满管理。在必要时，可以检查多部分/相关容器内容ID/内容类型值，并且可以仅接收相应信息。
图38示出了根据实施例的SDLT的扩展。
图38示出了根据上述实施例(图26等)的SDLT的示例扩展语法。对于上述元素的细节，参考上述说明。
在根据实施例的方法/设备中，提出了服务发现列表表(SDLT)和USBD配置方案，以便更快速地提供用户从可以通过服务发现处理提供给用户的服务中所选择的服务。
SDLT可以是接收器必须首先针对服务发现而具有的基本信息。通过该信令数据，接收器可以提供允许用户选择服务的服务列表信息。在这种情况下，SDLT可以被配置为包括更多信息。该配置信息可以使得能够提供丰富服务量，并且使得能够在用户选择服务时更快地播放该服务。
在提供DVB-I服务时有两种选择线性信道的方式。用户可以直接选择信道号或者通过信道搜台(surfing)来选择信道。考虑到DVB互联网信道的特性，可以基于HTTP网络接收单播，或者能够以组播的形式提供线性信道服务。DVB-I是互联网上的预订/流式传输类型，与通过专用频率和逻辑信道为未指定数量的用户接收作为DVB广播的信道不同，因此它需要通过信道的隐藏/非活动模式进行信道管理。
根据实施例的SDLT的扩展语法还包括以下值：@hidden(指示服务是隐藏还是向用户示出，并且具有作为默认值的假)、@selectable(可选择的)(指示选择可能性)、@hidden(visible)_guide(隐藏(可见)_指南)、@hidden(visible)_presentation(隐藏(可见)_呈现)(可以通过组合来用信号通知隐藏信道)。
图39示出了根据实施例的信道管理的示例。
图39示出了图38的隐藏元素。
例如，广播网络ATSC 1.0可以如下定义信道管理。
@hidden：布尔值，指示逻辑信道是可见还是隐藏。当用户搜索逻辑信道或直接选择信道条目时，它指示可见或隐藏属性。
@hide_guide：布尔值，指示逻辑信道在EPG中是可见的还是隐藏。它为用户指示信道指南的可见或隐藏属性。
该方法是基于RF广播环境的信道管理方法，并且信道管理应该仅基于服务列表中的信息来手动地执行。然而，在DVB-I环境中，存在返回信道，因此可以存在各种信道管理方法。
在实施例中，当信道在DVB-I环境中是隐藏/非活动的时，用户可以使用返回信道来确定相应信道的存在/状态，并且现有广播的隐藏/非活动信道可以通过替代服务来容易地管理。
在hide_guide(＝1)和Hidden(＝1)的情况下，可以另外用信号通知应用服务可访问的指示。
图40示出了根据实施例的hidden(visible)_presentation的值。
关于图39中描述的技术问题，可以使用以下添加的元素。
Hidden(可见)：布尔值(boolean value)指示逻辑信道是可见还是隐藏。当用户搜索逻辑信道或直接选择信道条目时，它指示可见或隐藏属性。
@selectable：当设置了这个时，可以通过直接输入到逻辑信道号来选择隐藏服务。当该值为假时，即使用户直接输入隐藏服务，也不能选择隐藏服务。
@hidden_guide：当在隐藏信道状态下直接访问信道时，@hidden_guid可以引导信道中的状态或者通过链接显示可替换屏幕。可以存在指示各种类型的信道指南方法的类型值。
@hidden(visible)_presentation：根据通过hidden_guide定义的类型值定义相应anyURI信息。
图40示出了与隐藏呈现相关的隐藏引导的类型。
当类型是0x0001时，它指示服务提供商的可替换链接，并且隐藏呈现可以提供连接地址，例如www.bbc.co.kr/alternative/music。
当类型是0x0002时，它指示可替换信道的链接服务，并且隐藏呈现可以用信号通知DVB三元组，例如DITS-(OriginalNetworkID)-(TransportStreamID)-(serviceID)。
当类型是0x0003时，它指示立体信道指南，并且隐藏呈现可以用信号通知DVB三元组，例如DITS-(OriginalNetworkID)-(TransportStreamID)-(ServiceID)。
当类型是0x0004时，它指示ESG或宽带内容指南(BCG)链接，并且隐藏呈现可以用信号通知loginformDB.html。
当类型是0x0005时，指示可替换应用服务，并且隐藏呈现可以用信号通知应用专用信道。因此，接收设备可以使用AIT来访问应用。
图41是根据实施例的隐藏信道管理的流程图。
图41是示出了基于与图38到40相关的隐藏信道来处理信道的流程图。
下面将参考流程图描述上述实施例的操作。
在操作41000，当接收设备的电源被接通时，接收设备检查信道/服务是否被隐藏。当信道/服务未被隐藏时，接收设备在显示器上指示可见信道和可见信道指南。
在操作41010，当存在隐藏信道/服务并且信道搜台不可能时，接收设备检查信道是否是可选择的。当信道不可选择时，接收设备向用户通知信道是非活动的并且信道指南不可见。在选择可能性为是的情况下，接收设备通常可以基于隐藏引导和隐藏呈现来处理/显示隐藏信道。
图42示出了根据实施例的包括RelatedMaterial(相关材料)的SDLT的示例。
图42示出了与图38等相关的SDLT的语法。
将参照图42描述当DVB-I兼职服务被提供并且服务是非活动的时提供服务相关材料的方法。
如上所述，DVB-I服务可以提供互联网线性信道，并且在服务发现处理中，可以在特定LCN中以兼职形式提供服务。当用户在服务状态之外通过信道号直接选择服务时，为了不引起混乱，可以通过非活动服务横幅图像或附加应用来执行信道改变API，或者可以提供附加VoD服务。在这点上，通过应用工业中实际使用的数据类型值来提出符合实际实践的层级。
图42的SDLT可以对应于根据上述实施例的SDLT，并且添加的元素/字段将如下描述。
@LCN指示逻辑信道号。
RelatedMaterial还可以包括以下元素。
@HowRelated:href可以与携带值的@href元素一起递送。
媒体定位器可以携带关于媒体位置的信息。具体地，MediaURI可以是包含XML AIT文件或图像的URI的值，并且@contentType可以携带该值。
可用性指示该服务的状态(运行、没有运行或在几秒内开始等)。
@ValidFrom指示该服务变为有效的时间/日期。当没有指定该值时，可以假设服务已经可用。
@ValidTo指示该服务将期满的时间/日期。当没有描述该值时，可以假设该服务是无限可用的。
@Days指示服务可用的一周中的多天。当没有指定时，服务在所有天都可用。例如，ServiceDays＝“1 4 7”指示该服务仅在星期一、星期四和星期六可用。
@Recurrence指示服务的调度可用性的每周节奏。当没有指定时，每周都会发生复发。
图43示出了根据实施例的相关材料的使用的示例。
图43示出了图42的相关材料的详细语法。
根据实施例的接收器通过<Availability(可用性)>元素中的属性来用信号通知兼职服务的实际有效时间，并且检查非活动时段。在该时段期间在LCN上显示的屏幕可以将非活动状态示出为在<RelatedMaterial>元素中定义的属性。@MediaURI是与上述hidden(visible)_presentation URI相同的属性并且符合HbbTV(AIT)应用信令和应用生命周期。当它被省略时，可以通过在@ApplicationInformationTable中定义的URI来提供非活动可替换服务。当@MediaURI的content_type是“image/png”时，可以指示非活动服务横幅。可以根据@MediaURI属性中的content_type通过图像和应用信令来提供非活动服务。
例如，根据@MediaURI，接收设备可以基于http://img-ctv.digitaluk.co.uk/channel7/service_a_linear.png的图像(image/png)(横幅)来提供非活动状态。
根据@MediaURI，接收设备可以基于application/vnd.dvb.ait+xml(application)of http://www.channel9.co.uk/player/ait.aitx？channel＝channela来提供非活动状态。
图44示出了根据实施例的非活动横幅的使用的示例。
图44可以包括在图41等中的信道管理的示例中。
图44示出了可以应用于非活动服务中的特定逻辑信道号(LCN)的UI/UX。接收设备可以在显示器上显示ESG 44000。在ESG 44000的UI/UX上的LCN 6的情况下，接收设备可以提供诸如指示“无服务”作为当前状态的“无服务”横幅的可替换应用(44010)。可替换应用可以在空白屏幕上执行，或者接收设备可以接收用于由用户通过远程控制器选择可替换应用的信号，并且执行与其相关的操作。
图45示出了根据实施例的服务列表的分级结构。
图45的服务列表分层结构是用于图1的服务情形。
DVB-I服务列表可以包含相应服务，并且每个服务可以包含服务实例。可以根据每个递送网络来定义多个服务实例，并且可以根据source_type的URN来区分唯一性。
DVB服务列表类型45000可以针对每个服务引用DVB-I服务类型45010。DVB-I服务类型45010用信号通知相关材料和指南源。DVB-I服务类型45010可以针对每个服务实例引用服务实例类型45020。服务实例类型45020用信号通知相关材料的订阅包和URN的源类型。服务实例类型可以引用以下中的至少一个：DVB T/S/C的递送参数类型、RTSP递送参数类型、组播递送参数类型或DASH递送参数类型。
所提出的源类型URN 45030提供用于DVB T/S/C/IPTV/DASH等的URN)。
DVB服务列表类型45000引用LCN表格列表类型，并且LCN表格列表类型引用LCN表格类型。LCN表格类型、DVB服务列表类型46000和DVB-I服务类型45010可以引用区域。相关区域信息可以在服务之间变化。
将参考随后的每个附图来描述图45的元素的细节。
图46示出了根据实施例的DVB-I服务列表类型。
将详细描述在图45中分层表达的DVB-I服务列表类型45010。
DVB-I服务列表具有类型“dvbisd:DVBiServiceListType”，并且具有每个序列的属性。
可以针对每个序列来用信号通知TextualType、附加用信号通知的RelatedMaterialType、区域信息的RegionListType、逻辑信道号的LCNTableListType等。
图47是根据实施例的DVB-I服务列表类型的表格表示。
在图47中，与图45和图46中所示的ServiceList相对应的ServiceList是由服务提供商提供的IP服务的细节和位置的列表。服务提供商可以将其服务分成多个服务列表。这个属性是强制性的。
名称是可读形式的服务列表的名称。多个服务列表名称可以用不同的语言来表达。这个属性是强制性的。
ProviderName(提供商名称)是可读服务列表的提供商的名称。可以用不同的语言描述提供商名称的多个值。这个属性是强制性的。
RelatedMaterial指示与服务相关的附加材料。这个属性是可选的。
RegionList(区域列表)是具有逻辑标识符的地理区域的列表，该逻辑标识符用于提供服务列表或服务列表中的服务的区域信息。这个属性是可选的。
TargetRegion(目标区域)表示在RegionList中指定的区域的标识符，该服务列表以该区域为目标。这个属性是可选的。
LCNTableList(LCN表格列表)是定义用于相应服务的区域化和分组化的逻辑信道号的表格的列表。这个属性是可选的。
Serivce表示作为服务列表的一部分的服务。这个属性是可选的。
@version是服务列表的版本号。该值对于每个发布的改变而递增。这个属性是强制性的。
图48示出了根据实施例的DVB-I服务类型。
上述DVB-I服务类型可以如图48所示来表示。
对于每个序列，DVB-I服务类型可以具有UniqueIdentifier(唯一标识符)和ServiceInstance(服务实例)，以及提供TargetRegion(目标区域)、用于用信号通知的服务的名称(ServiceName)、服务提供商(ServiceName)、作为附加信息的RelatedMaterial、关于该服务的流派(ServiceGenere)、该服务的特定类型(ServiceType)、关于该服务的记录相关信息(RecordingInfo)以及该服务的指南源(GuideSource)。
图49示出了根据实施例的DVB-I服务类型。
图49的DVB-I服务类型以表格的形式描述了图48的服务类型。
UniqueIdentifier是服务的唯一ID。对于服务，该ID可以从不改变。可以改变该服务的其他参数。这个属性是强制性的。
ServiceInstance(服务实例)是具有用于该服务的A/V内容的实例。当该属性的类型的多个元素存在并且可用时，具有@priority属性的较低值的元素可以具有较高优先级(或者反之亦然)。给定服务的所有服务实例可以具有相同内容。这个属性是可选的。
TargetRegion是接收服务的区域。当没有指定时，不存在区域约束。这个属性是可选的。
ServiceName是服务的名称。服务名称可以用各种语言来指定。这个属性是强制性的。
ProviderName是该服务的可读提供者名称。该元素可以用各种语言指定并且是强制性的。
RelatedMaterial是与服务相关的附加材料。该材料可以包括例如停止服务横幅、服务相关应用和服务标志。这个属性是可选的。
ServiceGenere是服务的类型。ServiceGenere是任选的。
ServiceType是服务类型(参考ETSI EN 300 468中的描述)。ServiceType是可选的。
RecordingInfo是允许DVB-I客户端确定来自该服务的内容是否被记录、时移或重新分发的信息。RecordingInfo是可选的。
GuideSource是承载用于该服务的元数据的宽带内容指南的细节。GuideSource是可选的。
@version是该服务的版本号。它对于每个发布的改变递增。@version是强制性的。
图50示出了根据实施例的DVB-I服务类型。
图50示出了图45的服务实例类型45020的详细形式。
例如，对于每个服务实例类型，可以携带DisplayName、RelatedMaterial、DRMSsystemid、ContentAttribute、Availability、SubscriptionPackage、FTAConentManagement以及各种参数，如图45所示。
图51示出了根据实施例的服务实例类型的表格表示。
将参考图50和图51来描述服务实例类型的元素。
DisplayName是与特定服务位置相关联的服务的可读名称。能够以各种语言指定多个服务名称。当不存在时，可以使用ServiceName字段。这个属性是可选的。在本公开中，属性可以根据级别而对应于元素、字段、信息或值，并且可以用各种术语来指代。
RelatedMaterial是与服务相关的附加材料。具体地，它可以包括无服务横幅、服务相关应用、服务标志等。在ServiceInstance元素内提供的具有属性HowRelated的特定值的相关材料取代了在服务元素内提供的具有HowRelated值的任何相应相关材料。该元素是可选的。
DRMSsystemId指示用于该服务的任何内容投影方案。该值可以与在文档DVB A168中定义的@schemeIdURI相同。该值是可选的。
ContentAttributes(内容属性)可以参考ETSI TS 103 205的附录D.1.3.2。该值是可选的。
Availability表示预期该服务位置是活动的时间段。该值是可选的。
SubscriptionPackage指定了其中包括该服务的订阅包。该值是可选的。
FTAContentManagement：不使用DRM的DVB-I服务实例可以携带FTAContentManagement元素，以定义用于ServiceInstance的内容管理策略。每个属性的语义可以在FTA_content_management_descriptor的相应字段中规定，其是文档ETSI EN 300468中的描述符。该值是可选的。
SourceType识别该服务实例的主要递送源。SourceType确定所需的递送参数。该值是可选的。
DVBTDeliveryParameters提供用于DVB-T服务的递送参数。
DVBSDeliveryParameters提供用于DVB-S服务的递送参数。
DVBCDeliveryParameters提供用于DVB-C服务的递送参数。
RTSPDeliveryParameters提供用于基于RTSP的服务的递送参数。
MulticastTSDeliveryParameters提供了用于使用组播UDP递送的服务的递送参数。
DASHDeliveryParameters()提供用于使用DVB DASH递送的服务的递送参数。
SATIPDeliveryParameters提供支持SATIP的DVB-I客户端可以用于从SATIP服务器接收服务实例的参数。
上述参数可以根据SourceType来描述。
@priority指示该服务实例相对于该服务的其他服务实例的优先级。该值是可选的。
图52示出了根据实施例的用于联播的DASH递送参数的扩展。
图53示出了根据实施例的用于联播的DASH递送参数的表格表示。
图52和图53示出了图51的DASH递送参数的详细语法。
根据实施例的DASHDeliveryParameter可以另外扩展用于联播。
UriBasedLocation可以参考文献ETSI TS103205的附录D.1.3.2。这是强制性的。当DASH服务被联播时，该值可以基于URI提供位置信息。
MinimmAitRate指示阈值比特率，在该阈值比特率下，用于相同服务的可替换服务应当是优选的。该值是可选的。
作为DVB-I服务类型的子元素，可以根据递送网络提供服务接口。接收设备可以考虑每个@priority和设备能力将服务实例确定为客户端。
这里，@MinimumBitrate指示在服务实例内用于接收流的网络堆栈方面的吞吐量。
例如，根据实施例的@MinimumBitrate可以指示在服务实例内用于接收流的网络堆栈方面的吞吐量。也就是说，根据实施例的设备可以检查最小比特率信息，以用于网络当前可以接收DASH服务的最小比特率。
通过该信息，可以确定服务实例是否是可播放的。然而，在当前定义的信息的情况下，当DVBiserviceType中包含多个服务实例时，客户端难以仅基于@minimumBitrate的信息来选择服务实例。
例如，假设存在如下两个服务实例。
(服务实例1)DVB-T递送方法，HD，H.264/AVC
(服务实例2)DVB-I DASH递送方法，最小比特速率1.5Mbps
例如，在存在两个服务实例(例如，服务实例1和服务实例2)的情况下，与根据实施例的发送/接收设备相关的客户端是HEVC UHD使能终端，并且可以确保高于另一比较目标的比特率的网络状况，接收器(终端)应当请求服务实例2(例如，HEVC UHD)。然而，除非通过请求接收到MPD，否则接收器不能从当前信息知道指示包括比实例1质量更好的流的属性。接收和比较所有服务实例的所有MPD可能不仅是从接收器角度的负担，而且可能是合理网络选择中的问题。下面提出了用于在DVB服务方案信息内的实例之间提供更好服务的方案。也就是说，可以实现这样的实施例，消除了接收器解析/分析所有MPD或类似信令信息的负担，并且允许接收器响应于特定比特率或更高比特率的网络情况而快速识别和请求更好的服务实例。
因此，如下所述，可以通过信息的扩展来区分服务实例。这个挑战可以通过参考图55和图26描述的实施例来解决。
图54示出了根据各实施例的DASH递送参数类型。
图54示出了图45的DASH DeliveryParameterType的详细语法。
如图54所示，DASH DeliveryParameterType可以是ComparisonBitRate和ComparisonContentAttributeType。ComparisonContentAttribute类型可以包括AudioAttribute元素、VideoAttribute元素、CaptionLangage元素和SignLangage元素。
ComparisonContentAttributeType可以对应于图45的ServiceInstanceType45020中所包括的ContentAttributes元素。
图55示出了根据各实施例的DASH递送参数类型。
如图55所示，DASHDeliveryParameterType可以包括ComparisonContentAttributeType。此外，ComparisonContentAttributeType可以包括ComparisonBitRate以及AudioAttributes元素、VideoAttributes元素、CaptionLangage元素和SignLangage元素。
尽管图54和图55的配置不同，但是作为公共元素的ComparisonBitRate和ComparisonContentAttributeType可以定义如下。
ComparisonBitRate意指它将能够处理什么比特率以便特定IP递送的服务实例可能提供比可用于该服务的任何非IP递送的服务实例更好的用户体验。
@ComparisonContentAttributeType指示哪个视频特性将可用于DVB-I客户端，以提供比可用于该服务的任何非IP递送的服务实例更好的用户体验。
图56示出了根据实施例的DVB-I服务实例的信令。
图56示出了图45的DVB-I服务实例的示例。
图56示出了两个服务实例。部分56000表示DVB-S服务实例，并且部分56010表示DVB-I服务实例。
服务实例56000具有优先级0，并且显示名称为ABC戏剧。如图56所示，AudioAttributes、VideoAttributes等被作为属性用信号通知，并且服务实例包括DVBSDeliveryParameters。这里，优先级“0”可以是示例值。另外，根据实施例的接收设备可以检查除了服务实例之外的附加服务实例，以通过根据实施例的信令信息提供能够不仅考虑优先级值而且考虑网络状态或可用带宽和客户端的能力来向用户提供更好服务的服务实例。
服务实例56010具有优先级1，并且显示名称为ABC戏剧。DASHDeleveryParameters可以通过基于URI的位置用信号通知https://live.daserste.de/0001Das％20Erste.mpd</dvbisd-base:用于应用/dash+xml类型的内容的URI。MinimumBitRate是1M，而ComparisonBitRate是7M。ComparionContentAttribute“urn:mpeg:mpeg7:cs:VideoCodingFormatCS:2001:2.2.2”和HEVC Video Main10 Profile@Main Level</tva:Name>(UHD enable)用信号通知VideoAttribute。具体地，ComparisonBitRate的值可以是示例值。根据实施例的接收设备(终端、客户端等)检查ComparisonBitRate的值，并且从该值识别出提供了更好服务。例如，当提供对应于值7M的更好服务时，根据实施例的方法/设备可以附加地定义类似于图56的ComparisonContentAttribute的对应视频属性信息，因此，根据实施例的接收设备可以检查UHD流的存在，并且根据网络情况将流切换到ComparisonContentAttribute的服务。
当接收器在DVB-I服务方案中接收相同服务(例如，ABC戏剧)内的两个实例时，DVB-I客户端应当选择可以被提供用于更好用户体验的实例。当@ComparisonBitrate值的值被识别为7Mbps，与HD相比超过了当前网络的可用带宽，并且@ComparisonContentAttribute的属性可由终端(接收器)支持时，可以请求MPD，并且可以接收更好服务并将其提供给用户。该属性基于@ComparisonBitrate(7Mbps-HD)指示“beyondHD”，并且意指可以提供与广播服务实例相比被丰富的服务。
这里，1M BPS和7M BPS的比特率可以是示例值。这些值可以是在具有不同分辨率的服务(例如UD和UHD)之间应用的比特率。
根据实施例，如下扩展使用情况。
实例1.HD广播
实例2.具有从SD到UHD的表示的UHD DASH，1.5Mbps到33Mbps(具有7Mbps的HD表示)。最小比特率1.5Mbps；ComparisonBitRate7Mbps。
即，实例1指示HD广播，并且实例2指示UHD DASH。实例2可表示为从SD到UHD，并且可具有从1.5Mbps到33Mbps的带宽。在这种情况下，HD表示是7Mbps，最小比特率是1.5Mbps，并且比较比特率是7Mbps。
根据实施例的能够支持UHD的播放器可以在比特率为7Mbps时选择实例2。
根据实施例的能够支持HD而不具有HEVC支持的播放器选择实例1。
能够支持UHD并且具有根据实施例的5.5mpbs速度的Wi-Fi链路的播放器选择实例1。
根据实施例的能够支持UHD并且具有不能接收到广播报告的1Mbps的3G移动连接的播放器可能不具有足够快以播放服务的连接但是可能尝试播放服务。
根据实施例的能够支持UHD并且具有不能接收广播的2Mbps的4G移动连接的播放器可以选择实例2。
图57示出了根据实施例的联播UI/UX。
在该图中，部分57000图示根据实施例的接收设备显示DVB-T广播服务的状态，而部分57010图示根据实施例的接收设备显示DVB-I服务的状态。图57图示了根据用户的选择和/或接收设备的特性、基于根据实施例的信令方案和UI/UX方案向用户提供对于相同服务的更好的用户体验。
部分57020是用于上述状态的上述信令信息的示例。该示例对应于以上参考图45描述的服务列表。
根据实施例的服务列表可以为每个服务提供服务实例。用于部分57000和57010的服务具有逻辑信道号6，并且包括服务实例1和服务实例2。服务实例1用信号通知DVB-T(HD)服务，如部分57000所示，以及服务实例2用信号通知DVB-I(UHD)服务，如部分57010所示。
根据实施例，当能够接收DVB-I服务的设备接收一个或多个服务实例时，可以基于所包括的比较比特率值和比较内容属性值来确定可以提供更高质量的媒体服务。当如在该实施例中那样接收两个服务实例时，可能通过IP/DASH来快速识别可能接收更好服务的服务实例。如在该实施例中，当同时接收到HD和UHD时，可以通过该信息来选择递送类型。
换句话说，接收服务实例1和服务实例2的接收设备可以基于包括在DVB-I的服务实例中的比较比特率值和比较内容属性值，立即检查更好的DVB-I UHD服务，而不必解析所有服务的所有其他信令信息。基于实例2，接收设备可以通过比较内容属性识别出比较比特率是7Mbps并且更好服务的分辨率是UHD(HEVC)。接收设备可以基于UI/UX询问用户是否查看更好服务。根据实例2的服务可以根据用户的选择或接收设备的设置而被提供给用户。
根据实施例的接收设备可以向用户提供DVB-I联播服务UI/UX。图57中所示的UI/UX表示根据上述实施例的当DVB-I客户端通过扩展信息接收多个服务实例时向用户提供更好体验的UI/UX。对于能够支持UHD/HEVC的终端，可以选择能够接收UHD的DVB-I服务实例来代替能够接收HD的DVB-T服务实例。终端可以仅通过服务列表方案选择高质量的服务实例，而不必接收所有DASH MPD。
根据上述实施例的信令信息可以被称为各种术语，诸如字段、属性、元素、第一信息、第二信息、第一值和第二值。
上述实施例和下面将要描述的实施例可以提供以下效果。
根据实施例，可以初始化用于互联网信道扫描的基于MPEG-2系统/DVB SI的服务，以便提供与现有线性服务信道相同的用户UX。
根据实施例，可以执行用于互联网流标识的网络/流/服务唯一信令以与现有线性信道聚合。
根据实施例，可以扩展用于替换现有系统信息中的TSID的方法。
根据实施例，可以允许切换在相同专用信道上提供的DVB网络和在DVB-I信道上提供的每个比特流。
根据实施例，SUHD(8k)链接可以通过在现有信道上提供的SD、HD和UHD链接服务中的DVB-I信道来提供。
根据实施例，可以在现有DVB网络上获取DVB-I服务列表。
根据实施例，为了提供基于线性IP的TV服务，提供了现有线性信道网络的服务引导技术。
根据实施例，可以添加必须针对基于线性IP的TV服务识别而定义的唯一信息。
根据实施例，基于IP的TV信道可以被添加到现有线性信道EPG。
根据实施例，可以在同一专用信道上同时提供现有DVB流和DVB-I流，并且可以在预定时间段内动态地改变这些流。
根据实施例，可以通过在现有信道上提供的SD、HD和UHD链接服务中的DVB-I信道来提供SUHD(8k)链接。
根据实施例，可以扩展用于在现有DVB网络上获取DVB-I服务列表或查询端点的链接信息。
根据实施例，用于现有线性信道网络的服务引导方案可以被扩展以提供基于线性IP的TV服务。
根据实施例，可以基于DVB-SI信息在业务群级、服务级和事件级提供现有DVB网络和DVB-I网络之间的链接。
根据实施例，通过关于现有的DVB网络和DVB-I网络的链接信息，可以在相同逻辑信道上提供各种分辨率的内容。
根据实施例，可以通过链接描述符(uri_linkage_descriptor)来定义DVB-I服务列表位置和查询，以获取现有DVB网络上的DVB-I服务列表。
根据实施例，可以通过端点访问开放DVB-I服务注册表，并且可以获取适合于客户端的服务列表条目列表。
根据实施例，可以能够实现由支持基于RF的DVB调谐器的设备通过UI访问的服务，其中，现有线性服务和OTT服务被聚合在该UI中。
根据实施例，提供与现有线性信道相同的UX的媒体服务可以通过开放式互联网而不是机顶盒(STB)来提供。
根据实施例，当现有DVB网络和互联网信道被聚合时，可以扩展可以在相同信道上提供的分辨率。
根据实施例，由于链接描述符(uri_linkage_descriptor)，可以用信号通知DVB-I服务列表位置。根据实施例的接收设备可以有效地获取DVB-I服务列表。另外，由于根据实施例的终点，根据实施例的接收设备可以有效地获取服务列表。
由于上述实施例，根据实施例的终端(设备)可以获取其中所有信道被聚合的服务列表，如图34所示，聚合的服务列表可以包括整个列表、接收设备期望的列表等。
可以存在可以获取所有服务的URI。通过该URI，可以另外获取用于各个服务的列表的URI。该各个列表可以是每个广播装置的服务列表。
随着服务平台的扩展，运营商可以通过更多样环境提供服务。从用户的角度来看，在各种应用环境中接收的媒体服务可以在被称为DVB-I的聚合接收环境中提供，因此，可以接收更方便并且具有良好可访问性的服务。
随着业务平台的扩展和集成，服务可以在包括地面、线缆、卫星和5G网络的通信网络上同时广播，并且接收器可以根据接收器能力接收期望业务。
该处理可以通过图54至图57中的ComparisonBitrate和/或ComparisonContentAttribute等来实现。
MPD可以包含多个表示，且还包含UD相关信息和UHD相关信息这两者。
接收设备具有解析MPD的所有信息的很大负担，这花费大量时间。
另一方面，当使用服务实例级的DVB-I服务列表时，可以允许接收设备根据接收设备的能力选择性地和快速地解码优化的服务和富媒体。
接收设备可以通过ComparisonBitrate识别具有不同能力的服务的存在。ComparisonBitrate可以是最小吞吐量的概念。此外，接收设备可以通过ComparisonContentAttribute识别交换服务的特定属性。
图58示出了根据实施例的接收设备的结构。
图58示出了应用图1至图57的实施例的用于接收广播信号的设备的结构。
根据实施例的广播信号接收设备接收广播信号。
TS分组过滤器580001处理包括在广播信号中的TS分组。TS分组可以是MPEG-2传输流分组。
PES解析器580002处理包括在TS分组中的流。该流可以是分组化的基本流。该流可包括视频流。
PES解析器580003处理包括在TS分组中的流。该流可以是分组化的基本流。所述流可以包括音频流。
数据解析器580004处理包括在TS分组中的数据。该数据可以包括与广播节目相关的内容或与应用相关的事件。
信令解析器580005处理包括在TS分组中的信令数据。信令数据可以包括业务群关联表(BAT)、网络信息表(NIT)、事件信息表(EIT)、服务描述表(SDT)和标识信道表(ICT)。信令解析器590005可以包括BAT解析器、EIT解析器、NIT解析器、SDT解析器和ICT解析器。信令解析器580005可根据图9、13、20、21、26、27、30、34、35、38、42、45等的实施例从接收信号解析信令信息。
视频解码器580006对包括在TS分组中的视频数据进行解码。
音频解码器580007对包括在TS分组中的音频数据进行解码。
控制单元580008控制解码的视频数据和解码的音频数据的同步。
控制器580009控制除了视频数据和音频数据之外的数据的事件。控制器580009可以从信令解析器580005接收信令数据，并基于该信令数据控制事件。
服务初始化服务器580010可以从信令解析器580005的信令数据获取用于服务发现的统一资源标识符(URI)信息。具体地，信令数据包括用于服务扫描的服务引导信息。信令解析器580005可以基于服务引导信息中的特定表格信息将服务发现信息URI提供给服务器580010。图58中的方法A表示由广播信号接收设备基于信令数据中的NIT的服务发现URI获取ICT的处理。
具体地，根据实施例的广播信号接收设备可以基于NIT的服务发现URI信息从服务器获取ICT信息。信令解析器580005的ICT解析器处理从服务器获取的ICT信息。信令解析器的ICT解析器可以对应于DVB-I服务方案解析器。
根据实施例的广播信号接收设备可以获取线性信道上的ICT信息。图58的方法B表示从由广播信号接收设备在线性信道上接收到的信令数据中获取和处理ICT信息的处理。
EPG服务器580011可以向EPG生成器580012提供基于ICT解析器的ICT信息的服务指南信息。
DASH服务器580012可以基于ICT信息向组播内部服务器580013提供用于通过HTTP的动态自适应流(DASH)数据的引导信息。
DASH客户端590014从组播内部服务器590013接收DASH数据。DASH客户端580014解析包括在DASH数据中的MPD(媒体呈现描述)信息，解析包括在DASH数据中的文件，解码包括在DASH数据中的视频数据，以及解码包括在DASH数据中的音频数据。
EPG生成器580012可以从信令解析器580005接收EPG相关信令数据，并且从EPG服务器580011接收EPG数据，并且生成要显示的EPG数据。
渲染器580015可以从控制器580008接收同步的视频/音频数据，从DASH客户端580014接收DASH视频/音频数据，并且渲染它们。
显示器580016可以显示所呈现的数据和EPG数据。
根据实施例的广播信号接收设备提供了一种用于提供IP服务的服务发现方法，在该IP服务中集成现有T/S/C信道和IP信道。
独立线性IP服务是指可以提供现有T/S/C信道和IP信道的聚合服务指南的服务。广播信号接收设备可以接收用于IP信道的服务扫描的服务引导信息。
具体地，广播信号接收设备可以从T/S/C信道的服务引导信息中的特定表格或特定描述中获取服务运营商URI。例如，服务运营商可以提供服务发现信息。
广播信号接收设备可以从T/S/C信道的服务引导信息中的特定表格或特定描述中获取服务发现信息URI(参见图59中的方法A)。
广播信号接收设备能够以与T/S/C信道的服务引导信息相同的方式获取在非实时转盘上发送的服务发现信息文件URI。
广播信号接收设备可以基于CICAM中的服务引导信息中的特定表格或特定描述来获取服务发现信息URI。
根据实施例的广播信号接收设备可以基于硬连线的链接URI信息来执行服务发现。硬连线的链接URI可以通过运营商与CE之间的协议来提供硬连线的URI。广播信号接收设备可以通过URI获取服务发现信息。
由于根据实施例的广播信号发送设备和广播信号接收设备以聚合方式提供现有信道的服务指南，所以可以使用与现有信道的服务指南信息相对应的信息。广播信号接收设备可获取关于图58所示的结构中的服务指南的唯一标识信息，TS分组过滤器580001过滤TS分组以区分服务发现信息和音频/视频数据。信令解析器580005通过解析包括在所接收的广播信号中的服务发现信息在DB中构建服务指南数据。
广播信号发送设备和广播信号接收设备可以符合基于MPEG-2系统的DVB标准。例如，根据DVB标准的DVB系统信息可以包括诸如上述NIT、BAT、SDT和EIT的表格或描述信息。广播信号发送设备和广播信号接收设备可以基于这样的表格来执行服务发现和生成EPG信息。
获取服务发现信息的处理可以基于NIT来执行，NIT是用信号通知可接收网络的表格。NIT包括关于网络的服务发现信息。广播信号接收设备可以通过解析NIT来获取ICT(图58中的A)或者通过线性信道来获取ICT信道(图58中的B)。
图59示出了根据实施例的网络信息表(NIT)的配置。
图59的NIT是包括在广播信号中的信令信息，并且可以由图58的信令解析器580005解析。
图59中的网络信息区段指代NIT。NIT中包含的信息可以符合DVB标准的定义。
table_id可以识别NIT。
section_syntax_indicator是1比特字段并且可以被设置为值1。section_syntax_indicator包括指示由NIT识别的语法的信息。
reserved_future_use和“reserved”是为将来使用而保留的字段。
section_length指示区段的字节数。
network_id可以用于识别递送系统并且指示通过网络所接收的比特流的标识信息(唯一标识)。递送系统指的是递送传输流的物理单元的概念。
version_number指示子表的版本号。
current_next_indicator指示子表当前是否可应用。
section_number指示区段的编号。
last_section_number指示最后区段的编号。
network_descriptors_length指示网络描述符的长度中的字节数。
transport_stream_loop_length指示TS循环的字节总数。
transport_strem_id是用于识别TS的信息。
original_network_id是识别关于原始递送系统的网络标识信息的信息。
根据实施例的广播信号接收设备基于NIT区分当前用于接收的网络，例如地面、线缆和卫星信道的网络。广播信号接收设备利用原始网络ID和传输ID来定义关于在网络中接收的比特流的标识信息(唯一标识)。TSID是用于识别在当前传递系统中复用的TS的唯一ID。
此外，广播信号发送设备可单独使用当前正接收的S信道、T信道和C信道的主流的实际NIT和另一网络的NIT。因此，除了用于主流的现有NIT之外，互联网线性信道的服务发现在用于其他网络的表格中也是可能的。在除主流之外的递送系统中，可以使用网络ID来区分网络。因此，广播信号发送设备可以扩展并且使用网络ID以便检查作为另一网络的互联网线性信道。
根据实施例的广播信号接收设备可以通过扩展包括在图60的NIT中的网络ID并且使用与服务发现URI信息相同的URI信息来执行针对互联网线性信道的服务发现，如图59的方法A中那样。
此外，根据实施例的广播信号发送设备可以在广播网络上以轮播方式发送XML文件或二进制代码。在这种情况下，广播信号接收设备可以如图59的方法B中那样在广播网络上获取ICT。
NIT还可以包括通过子环的描述符。NIT中包括的描述符可以包括关于服务或服务列表的信息。描述符的详细配置将在下面描述。
在本发明中，NIT可以被称为第一信令信息、第二信令信息等。
图60示出了根据实施例的业务群关联表(BAT)的配置。
图60的BAT是包括在广播信号中的信令信息，并且可以由图58的信令解析器580005来解析。
根据实施例的广播信号发送设备可以通过捆绑服务来生成被称为业务群的服务捆绑。BAT包括用于服务捆绑的信令信息。
可以通过这样的服务捆绑或服务编组对从其他网络发送的多个流/服务进行编组来配置各种服务场景。也就是说，如图7所示，广播信号发送设备可以将服务捆绑在业务群中，而不管接收网络如何，并且捆绑所接收的TS和服务。
根据实施例的广播信号接收设备通过业务群关联区段表(BAT)接收信令信息，以便用信号通知编组的服务。
table_id指定用于识别BAT的信息。
section_syntax_indicator指定了指示由BAT用信号通知的语法的信息。
bouquet_ID指定用于识别服务捆绑的信息。
version_number指示子表的版本号。
current_next_indicator指示子表当前是否可应用。
section_number指示区段的编号。
last_section_number指示最后区段的编号。
bouquet_description_length指示BAT中描述的业务群的长度的字节总数。
transport_stream_loop_length指示TS循环的长度中的字节总数。
transport_stream_id指定用于在递送系统中从其他复用流识别TS的信息。
original_network_id指定用于识别原始递送系统的网络ID的信息。
基于BAT中包含的业务群ID、传输流ID和/或原始网络ID，根据实施例的广播信号发送设备可以描述和发现通过捆绑互联网线性信道服务以及现有主流或线性信道的服务而形成的业务群。
具体地，业务群ID可以识别包括互联网信道的服务的业务群。传输流ID可识别包括互联网信道的服务的传输流。原始网络ID可以是原始递送系统的网络ID，并且可以表示用于互联网信道的服务的网络。根据实施例的广播信号接收设备可以通过解析BAT来发现互联网信道的服务。
BAT还可包括通过子环的描述符。BAT中所包括的描述符可包括关于服务或服务列表的信息。描述符的详细配置将在下面描述。
在本公开中，BAT可以被称为第一信令信息、第二信令信息等。
图61示出了根据实施例的服务描述表格(SDT)的配置。
图61的SDT是包括在广播信号中的信令信息，并且可以由图58的信令解析器580005解析。
根据实施例的广播信号发送设备可以发送包括SDT的广播信号，并且根据实施例的广播信号接收设备可以接收包括SDT的广播信号。
table_id表示用于识别SDT的信息。
section_syntax_indicator指定了指示通过SDT用信号通知的语法的信息。
transport_stream_id指定用于识别由SDT在递送系统中描述的传输流的信息。
version_number指示子表的版本号。
current_next_indicator指示子表当前是否可应用。
section_number指示区段的编号。
last_section_number指示最后区段的数目。
original_network_id指定用于识别原始递送系统的网络ID的信息。
service_id指定用于识别传输流中的服务的信息。
EIT_schedule_flag指示用于服务的EIT调度信息是否存在于当前TS中。
EIT_present_found_flag指示在当前TS中是否存在用于服务的EIT存在跟随信息。
running_status指示服务的状态。服务的状态可以包括“运行”、“在几秒内启动”、“暂停”和“服务停播”。
free_CA_mode指示是否对服务的所有分量流进行加扰。free_CA_mode指示控制由条件接入(CA)系统控制的一个或多个流的模式，该条件接入(CA)系统是被配置为控制接入服务的订户的系统。
SDT是定义当前正在进行传输的网络并且定义TS中的传输数据的服务描述的表格。类似于上述NIT，SDT可以基于TSID和原始网络ID来描述多个服务。广播信号发送设备可以基于原始网络ID、传输流ID和/或服务ID来区分一个服务。在由原始网络ID识别的网络上不存在重叠的服务ID，并且服务ID具有唯一值。此外，通常，原始网络ID具有与网络ID相同的值。
图60至图62示出了由根据实施例的广播信号发送设备和广播信号接收设备发送和接收的信令信息。在每个表格中定义的字段可以符合DVB-SI标准中的定义。此外，根据实施例的广播信号发送设备和广播信号接收设备还扩展和定义了包括在用于互联网信道的服务描述和服务发现的现有线性信道上的服务描述和服务发现的表中的信息。因此，广播信号接收设备可向用户提供互联网信道服务，同时提供与现有线性信道的向后兼容性。广播信号接收设备可以向用户提供聚合现有线性信道和互联网信道的EPG。
根据实施例的广播信号发送设备可以发送包括新表格的广播信号。图59所示的ICT表格可以包括在实际网络上接收的服务指南信息。在接收到ICT信息时，广播信号接收设备的EPG生成器580012以聚合的EPG的形式向用户提供单个信道服务指南。
广播信号发送设备可通过网络发送包括信令信息的信令数据和除信令数据之外的包括AV数据的广播数据。广播信号发送设备可以基于组件类型来区分和处理信令数据和广播数据。
广播信号接收设备的数据解析器58004除了AV数据之外还解析互联网数据和为了同步而发送的同步数据(例如，MPEG TEMI)。因此，广播信号接收设备可以恒定速率根据传输定时提供用于实际信道的事件链接服务。
根据实施例，ICT可以包括关于要在实际互联网信道上接收的媒体数据的信息。广播信号接收设备可以基于ICT的MPD URI获取能够接收内容的MPD。DASH服务器具有接收内容的角色(内容源)。因此，可以通过MPD URI在DASH服务器580012上执行根据网络状态的组播和/或单播服务器的动态分配。在组播的情况下，MPD可以包括靠近客户端的具有CDN角色的组播服务地址，并且广播信号接收设备可以接收单播/组播自适应类型服务。
DASH客户端580014通过MPD接收A/V DASH片段并且对其进行解码。此外，来自DASH客户端590014的诸如线性信道的媒体数据通过渲染器580015渲染，并且显示在显示器580016上。
在本公开中，SDT可以被称为第一信令信息、第二信令信息等。
图62图示了由根据实施例的广播信号接收设备解析信令信息的处理。
图62中的解析信令信息的处理可以由图58的信令解析器580005执行。
根据实施例的广播信号接收设备可以使用如上所述的集成用于现有信道的服务指南所必需的唯一标识信息。广播信号接收设备可以如下解析用于服务指南的标识信息。因此，根据实施的方法/设备可以扩展基于DVB网络的互联网信道扫描(指的是从T/S/C服务自主信息中的特定表格获取服务发现信息URI的方法，以及获取如在T/S/C服务自主信息的情况下以非实时轮播方式发送的服务发现信息文件URI的方法)。
TS解复用器62001可从包括在广播信号中的TS解析信令信息。TS解复用器可以对应于TS分组过滤器63001。TS解复用器62001可以基于分组标识符(PID)来识别分组。
当TS分组包括关于PAT的信息62002时，根据实施例的广播信号接收设备解析PAT。PAT包括与网络有关的标识信息(Network_PID)。
当TS分组包括关于NIT的信息62003时，广播信号接收设备解析NIT。NIT包括关于NIT表格的标识信息、关于网络的标识信息、关于传输流的标识信息和关于原始网络的标识信息。
此外，当TS分组包括关于NIT的信息62004时，广播信号接收设备解析NIT。与NIT表相关的标识信息(table_id)可以包括关于主网络或实际网络的信息，并且可以包括关于其他网络的信息。
例如，当服务指南信息符合MPEG-2节目特定信息(PSI)的格式时，广播信号接收设备响应于TS分组报头中的PID的值为0x00的情况而接收PAT。广播信号接收设备响应于PID的值是0x01的情况而接收network_PID。当NIT的table_id是0x40时，NIT包括关于主网络的信息。当NIT的table_id是0x41时，NIT包括关于其他网络的信息。NIT的table_id的值，0x40，是一个实施例，并且table_id可以根据实施例具有各个值。也就是说，可以根据服务提供商的意图来分配用于DVB-I服务发现的NIT table_id。
用于主网络的NIT 62003可以包括network_id(NID)、transport_stream_id(TSID)和original_network_id(ONID)，并且广播信号接收设备可以基于包括network_id(NID)、transport_stream_id(TSID)和original_network_id(ONID)来识别当前接收的流。
根据实施例的广播信号发送设备可发送包括关于NIT的信息62004的TS分组以便引导互联网信道服务。
用于其他网络的NIT 63004可以包括network_id。network_id可指示互联网线性信道。NIT 62004可以包括original_network_id(ONID)和transport_stream_id(TSID)，并且广播信号接收设备可以基于ONID和TSID来唯一地识别服务。
根据实施例，服务列表可以是聚合列表。服务列表可以包括服务唯一信息。由于DVB-I可以支持用于各种网络的服务，所以根据实施例的服务列表可以包括用于单独服务的服务列表和/或用于聚合服务的聚合列表。互联网信道的数据不包括TSID。因此，对于互联网信道的数据需要可以替换TSID的信息(unique_id)。TSID的唯一标识信息可以由URI_linkage_descriptor 62005，62008来代替。URI_linkage_descriptor包括URI地址信息。由于每个运营商具有不同的URI字符串，因此TSID可以用URI字符串来替换。另外，基于URI地址信息，广播信号接收设备可以接收发现信息，该发现信息包括ICT信道信息和MPD URI信息，通过该发现信息可以接收实际DASH片段。URI_linkage_descriptor的特定配置将参考图65详细描述。
根据实施例的广播信号接收设备可以接收用于基于宽带和/或广播获取线性互联网信道的服务发现信息。当获取路径是宽带时，描述符是URI_linkage_descriptor 62005。当获取路径是广播时，描述符是URI_linkage_descriptor 62005。
当获取路径是宽带时，URI_linkage_descriptor 62005包括专用数据63006。将参考图67描述基于宽带的专用数据62006的详细配置。
当获取路径是广播时，URI_linkage_descriptor 62008包括专用数据63009。将参考图66描述基于广播的专用数据63009的详细配置。
另外，根据实施例的广播信号发送设备可以基于宽带或广播发送与服务或服务列表有关的信息(service_list_descriptor)作为NIT 62004的子配置信息。基于宽带的服务列表信息是service_list_descriptor 62007，并且基于广播的服务列表信息是service_list_descriptor 62010。服务列表信息63007和63010提供关于服务的唯一标识信息，诸如服务ID和服务类型。
当TS分组包括关于BAT 62011的信息时，根据实施例的广播信号接收设备解析BAT62011。BAT 62011包括用于标识作为服务捆绑的业务群的信息(bouquet_id)，并且包括作为广播信道的服务描述信息的transport_stream_id(TSID)和original_network_id(ONID)。为了提供用于互联网线性信道的服务描述，广播信号发送设备可以附加地提供可以替换用于线性信道的TSID的信息。BAT 62011可以另外包括用于服务发现URI的描述符62012和服务列表描述符62013作为子配置信息。将参考图67描述符62012和服务列表描述符62013的详细配置。
当TS分组包括关于SDT 62014的信息时，根据实施例的广播信号接收设备解析SDT62014。已经参照图61描述了SDT 62014的详细配置。
图63示出了根据实施例的网络的类型。
图63示出了图62中的网络ID分配的模板。
根据实施例的广播信号发送设备和广播信号接收设备可以使用各种网络来发送和接收广播信号。网络可以包括S信道、T信道和C信道，并且还可以包括互联网信道。作为关于网络的信令信息的NIT可以包括network_id，并且广播信号发送设备可以将互联网信道与S信道、T信道和C信道一起分配给network_id。
图64示出了根据实施例的URI描述符(URI_linkage_descriptor)的配置。
图64中的URI描述符是图62所包括的URI描述符的具体语法。
URI描述符(也可以称为URI链接描述符、链接描述符等)包括类型信息(URI_linkage_type)。广播信号发送设备可将用于互联网信道的服务发现信息的值重新分配给类型信息。将参考图66描述类型信息的详细配置。
当URI描述符的URI链接类型的值是0x00和/或0x01时，可以提供最小轮询间隔的值。根据最小轮询间隔的值，可以用信号通知用于发现链接(连接)信息的轮询的最小间隔的值。
URI描述符包含专用数据。将参照图67和图68描述根据服务发现获取路径是宽带或广播的情况的专用数据的详细配置。
图65示出了根据实施例的URI链接类型信息(URI_linkage_type)的配置。
图65示出图64的URI链接类型的特定值。
图65的URI链接类型信息包括用于获取线性互联网信道的服务发现信息。广播信号接收设备获取线性互联网信道所通过的路径包括宽带和/或广播。
例如，当URI_linkage_type的值是0x00时，URI链接类型信息指示CI Plus的在线SDT(OSDT)。当URI_linkage_type的值是0x01时，URI链接类型信息指示DVB-IPTV SD&S。当URI_linkage_type的值是0x02时，URI链接类型信息指示用于伴随屏幕应用的材料分辨率服务器(MRS)。当URI_linkage_type的值为0x60时，URI链接类型信息指示HbbTV操作应用。
此外，根据实施例的广播信号发送设备可以附加地扩展和定义URI_linkage_type。例如，当URI_linkage_type的值是0x61时，URI链接类型信息指示用于宽带网络上的线性互联网信道的服务发现。当URI_linkage_type的值是0x62时，URI链接类型信息指示用于广播网络上的线性互联网信道的服务发现信息。因此，当URI_linkage_type的值是0x61时，广播信号接收设备可以通过互联网获取服务发现信息。当URI_linkage_type的值是0x62时，广播信号接收设备可以在与关于当前接收的T信道、S信道和/或C信道的DVB SI信息兼容的同时获取服务发现信息。
当URI_linkage_type的值是0x03(或者可以使用根据实施例的各个值)时，可以执行根据如图72所示的实施例的附加服务列表的信令。
图66示出了根据实施例的专用数据的配置。
图66示出了图64中包括的专用数据的详细信息。
下面描述在宽带上发送的专用数据63006中包括的信息。
包括Destination_IP_address。Destination_IP_address指示服务发现IP地址。Destination_Port指示端口号。Service_provider_id指示服务提供商。Network_operator_id指示提供服务的网络运营商。Instance_TSID指示替换TSID的临时TSID值。
根据实施例的广播信号发送设备可将用于服务发现的URL信息而不是Destination_IP_address添加到专用数据62006。由于URL是通过将IP信息转换为字符串而获得的，因此URL信息可以对应于IP信息。
类似地，根据实施例的广播信号发送设备可以将用于服务发现的URL信息而不是Destination_Port添加到专用数据62006。
根据实施例的广播信号发送设备可基于宽带发送URI_linkage_descriptor63005中的专用数据62006。广播信号发送设备可以利用用于互联网线性信道的服务发现的URI信息来替换专用数据63006中包括的Destination_IP_address、Destination_Port、Service_provider_id、Network_operator_id和Instance_TSID。广播信号接收设备可以提供包括互联网信道的广播信道的聚合的EPG，并且可以使用URI_linkage_descriptor62006的URI信息执行互联网信道的服务发现。
图67示出了根据实施例的专用数据的配置。
图67示出了包括在图64中的专用数据的详细信息。
下面描述通过广播发送的专用数据62009中所包括的信息。
Info_type指示广播信号接收设备接收到的服务发现信息是XML格式还是二进制格式。
ICT_PID指示包括服务发现表格信息的TS分组的PID。
ICT_table_id指示用于识别服务发现表格的ID。
Service_discovery_URI指示当Info_Type是XML文件时的文件URI。
instance_TSID指示代替TSID的临时TSID。
已经参照图63至图68描述了用于通过广播信号接收设备获取互联网信道的服务发现信息的方法。广播信号接收设备基于宽带或广播而接收用于其他网络的NIT并且解析NIT中所包括的URI_linkage_descriptor。另外，广播信号接收设备通过包括在每个URI_linkage_descriptor中的专用数据而获取另外扩展和定义的服务发现URI而不是TSID。
此外，在根据实施例的广播信号接收设备中，NIT 63004和/或BAT62011的子环路可以包括service_list_descriptor或service_descriptor 62007、62010、62013。service_list_descriptor或service_descriptor 62007、62010、62013包括stream_unique_id和service_id。
如上面参考图61所述，BAT 90011在当前接收器中收集流和服务，而不管网络如何，并且发送称为业务群的服务捆绑。BAT 62011可基于bouquet_id、original_network_id(ONID)和transport_stream_id(TSID)来提供用于网络和传输级别的逻辑捆绑的信令。由于互联网线性信道不能包括TSID，因此需要互联网线性信道级别的信令。
根据实施例的广播信号发送设备可以基于广播来发送URI_linkage_descriptor62008中的专用数据。广播信号发送设备可以用用于互联网线性信道的服务发现的URI信息来替换Info_type、ICT_PID、ICT_table_id、Service_discovery_URI和/或instance_TSID。广播信号接收设备可以提供包括互联网信道的广播信道的聚合的EPG，并且可以使用URI_linkage_descriptor 62008的URI信息来执行互联网信道的服务发现。
因此，根据实施例的广播信号发送设备可以如上所述将替换TSID的唯一信息添加到URI_linkage_descriptor，或者可以另外定义BAT中的描述符。具体地，BAT可以包括IP_channel_ID_descriptor。将参考图69详细描述IP_channel_ID_descriptor的配置。
图68示出了根据实施例的IP信道ID描述符(IP_channel_ID_descriptor)的配置。
图68示出了图62的IP_channel_ID_descriptor。
IP_channel_ID_descriptor 62012包括关于网络和流的唯一信息。类似地，URI_linkage_descriptor 62005、62008还包括关于网络和流的唯一信息。
descriptor_tag和descriptor_length识别描述符并且指示描述符的长度。
service_provider_ID指定用于识别IP信道的服务供应商的信息。
network_operator_ID指定用于识别网络运营商的信息。
IP_number指示IP信道的编号。具体地，IP_number可以用作标识符和访问地址，并且可以执行与用于服务发现的URL相同的功能。由于IP_number是IP地址并且被转换为URL，因此它被用作服务引导的访问地址。
Port_number指示用于IP信道的端口号。
IP_channel_ID_descriptor 62012包括用于互联网线性信道的服务发现的service_discovery_URI。此外，IP_channel_ID_descriptor 62012包括代替TSID的instance_TSID。instance_TSID可以具有代替TSID的临时TSID的值。
作为用于识别互联网线性信道的服务的信息的service_list_descriptor62013包括互联网线性信道的服务的service_id和service_type。
因此，广播信号接收设备可以通过解析BAT 62011的original_network_id(ONID)来识别网络，并且通过解析IP_channel_ID_descriptor 62012来基于服务发现URI信息获取互联网线性信道的服务。此外，广播信号接收设备可以基于service_list_descriptor62013获取服务ID和服务类型。
根据实施例的广播信号发送设备可以扩展和定义包括在IP_channel_ID_descriptor 62012中的IP_number、Port_number、network_operator_ID和service_provider_ID，以包括用于互联网线性信道的服务发现的URI信息。广播信号接收设备可以基于IP_channel_ID_descriptor 62012接收聚合的EPG并且获取URI信息。
此外，广播信号发送设备可以通过为每个逻辑业务群ID配置服务捆绑来用信号通知服务发现。
图69图示了根据实施例的基于业务群的服务发现的处理。
图69图示了基于图62的信令信息的服务发现的示例。
根据实施例的广播信号接收设备可以基于业务群标识信息来用信号通知服务捆绑。
业务群169001和业务群269005可以基于bouquet_ID来识别。
业务群169001可以包括多个服务捆绑69002、69003和69003。业务群269005可以包括多个服务捆绑69006、69007和69008。如上面参考图60所述，业务群包括通过各种网络发送的一组流或服务。服务捆绑可以由original_network_id(ONID)表示。用于各种网络之间的T信道、S信道和C信道的服务可以通过transport_stream_id(TSID)(69003,69007)来表示。可以基于URI(69002、69004、69006、69008)来表示用于各种网络之间的互联网线性信道的服务。此外，如上参考图62至68所述，图69的URI信息可以由IP_number、Port_number、Service_provider_ID、Network_operator_ID和/或instance_TSID来替换。
根据上述实施例，广播信号接收设备可以实现基于IP的TV服务，其可以提供与地面、卫星和有线线性信道相同的用户UX。此外，广播信号接收设备可以通过接收基于开放式互联网的本地码而不是基于应用的线性信道服务来提供与地面、卫星和有线信道聚合的信道指南。另外，广播信号接收设备可以执行能够提供与现有线性服务信道相同的用户UX的互联网信道扫描，并且还执行基于MPEG-2系统/DVB SI的服务初始化。为了提供与现有线性信道聚合的服务指南，广播信号接收设备可以通过上述信令信息、描述或表格来提供用于互联网流标识的网络/流/服务唯一信令。广播信号发送设备提供了一种可以在维持与当前系统信息中的TSID信息的兼容性的同时替换TSID而无需额外定义新信息的信令方法。
根据实施例的广播信号发送设备扩展了现有线性信道网络的服务引导方案，以便提供基于线性IP的TV服务。已经参考图8描述了针对基于线性IP的TV服务标识所定义的唯一附加信息。因此，可以向用户提供添加到现有线性信道EPG的基于IP的TV信道信息。
根据实施例的广播信号接收设备可以通过其中现有线性服务和OTT服务由支持基于RF的DVB调谐器的设备来聚合的UI来访问服务。另外，广播信号接收设备可以支持通过开放式互联网提供与现有线性信道相同的UX的媒体服务而不使用STB。
对于根据实施例的广播信号发送设备，传统的基于IP的线性信道服务通过订购特定运营商而被授权认证，所述特定运营商例如ISP或网络运营商。广播信号接收设备通过由运营商提供的STB接收IP线性服务。而且，最近，随着连接TV的出现，无STB的IP线性服务是可用的。例如，代表性的标准技术可以包括ATSC 3.0、IBB和HbbTV。客户端可以通过在TV内部的OS平台上操作应用来接收各种线性富媒体服务。各种运营商提供由他们自己开发的服务应用，使得应用可以安装在TV平台上。在应用中定义了能够与可以从其接收服务的数据的服务器实现请求/接收的API。基于该生命周期，客户端可以通过TV UI访问应用，并且通过该应用接收各种服务。根据实施例的广播信号接收设备可以向用户提供上述各种服务。
另外，根据实施例的广播信号接收设备不仅可以提供线性TV，而且可以提供OTT信道。OTT市场增加了对基于IP的设备的基本媒体应用的需求。在OTT市场中，专用服务正根据独立平台和仅由OTT形成的服务生态系统而增加。换句话说，诸如仅由每个OTT提供的编解码器、协议栈、应用和浏览器之类的独立应用生态系统的消耗模式正在增加。根据实施例的广播信号接收设备可以解决诸如对OTT的专用平台和应用的操作的依赖性的问题。此外，代替提供类似于诸如T信道、S信道或C信道的线性信道服务的UX的需要执行应用的UX，广播信号接收设备提供了一种在接收器本地层级发现服务并且通过访问客户端可访问的服务服务器来接收线性服务的方法。
此外，根据实施例的广播信号接收设备提供了一种将OTT的独立平台集成到一个统一的TV本地平台中并且在消除用户运行OTT应用的需要的同时在信道内接收和提供OTT内容的方法。
图70图示了根据实施例的在DVB网络上的DVB-I引导方法。
图70的信令信息(SI)可以对应于图62的SI，并且图62的SI可以如图70所示地被附加地扩展。
DVB SI可以用信号通知通过基于MPEG-2系统的初始化处理所接收的流的网络信息和节目以及事件信息。NIT 70000可以用信号通知和发现所接收的流的网络。在本公开中，使用现有DVB网络来扩展DVB-I服务引导方法。
DVB-I是互联网线性信道并且可以通过NIT 70000来用信号通知。通过EN300 468标准中的URI链接描述符，必须定义对于发现点可访问的查询，在该发现点可获得用于获取DVB-I服务列表或列表中的服务列表的位置。发现点可以是TV制造商的服务注册表，或者是诸如EBU或DVB之类的团体可访问的中央服务注册表。两种方法可以用于定义引导。
关于NIT 70000中的引导顺序，URI链接描述符被包括在NIT(0x40/41)中的/*描述符循环*/或/*ts循环*/中，并且用于引导DVB-I的信息被包括在上述信息中。
图71示出了根据实施例的URI链接描述符。
图71的描述符可以对应于图64的URI描述符。图64的描述符可以如图71所示地扩展。
对于图71中与图64的元素相同的元素，可以参考图64的描述。
Linkage_type是链接服务的类型。例如，Linkage_type的值是0x03，其指示链路服务是DVB-I服务，并且接收设备必须解析end_point_type的字段。
根据实施例的URI链接(连接)描述符可以根据URI链接类型来用信号通知连接服务的类型，并且可以递送用于要用信号通知的服务的连接信息(URI或查询串)。例如，根据URL_linkage_type＝3的条件，end_point_type以语法出现在以下字段中。这里，end_point_type指示结束点的类型。然后，根据通过for循环编码的比特长度N来用信号通知URI或查询。
图72示出了根据实施例的端点类型(end_point_type)。
图72示出了图71的end_point_type。
end_point_type的值可以指示以下信息。根据实施例，能够以各种方式设置end_point_type的值。
例如，当end_point_type的值是0x00时，其指示该端点是DVB-I服务列表位置。当end_point_type的值是0x01时，其指示该端点是对DVB-I服务列表注册表的查询。
根据实施例，能够以各种方式修改end_point_type的整数值。
例如，根据实施例的接收设备可以通过NIT检查网络信息，并且获取URI链接描述符。URI链接描述符提供端点类型。这种类型根据URI的值指示URI的存在，该URI是DVB-I服务列表的位置。接收设备可以通过URI快速获取服务列表和聚合的服务列表(列表的列表)，该URI是包括在URI链接描述符中的DVB-I服务列表的位置。此外，端点类型根据其值用信号通知存在可以获得DVB-I服务列表注册表的查询。当接收设备发送查询时，它可以接收用于列表的URI。
图73示出了根据实施例的链接型专用数据字节的配置。
图73示出了关于专用数据字节的详细信息，其可以由图71的URI链接描述符根据图72的end_point_type来用信号通知。
在专用数据字节中，DVB-I服务列表位置可以根据end_point_type定义，或者可以提供服务列表。根据end_point_type，可以提供对DVB-I服务列表注册表的查询。
图74示出了根据实施例的BAT的URI链接描述符。
图62的BAT可以如图74所示地用信号通知。
关于BAT 74000中的引导顺序，URI链接描述符可包括在NIT(0x40/41)中的/*描述符循环*/中。
BAT 74000可以包括URI链接描述符，以引导DVB-I。URI链接描述符可以根据URI链接类型的值(例如，0x3)用信号通知端点类型和专用数据字节。
根据端点类型，可以提供专用数据字节可以从中获取DVB-I服务列表的地址信息(URI)，或者可以提供对DVB-I服务列表注册表的查询。
例如，当End_point_type是0x01时，接收设备可以通过解析DVB-I服务列表注册表来获得对服务发现的查询或端点字符串，如图74所示。
结果，DVB-I客户端(或接收设备)可以获取服务列表的入口点，并且可以获取列表位置，在该列表位置处可以根据客户端的区域和语言标准来请求合理服务列表。
通过获取DVB-I服务列表或查询信息，能够进行DVB-I服务发现和本地码解析的终端(接收设备)解析包含服务的服务列表方案并且将与每个服务对应的LCN信息存储在信道DB中，如图74所示。在这种情况下，接收设备可以管理聚合现有DVB信道(C、S、T信道)和DVB-I服务实例的DB信道，并且向客户端提供其中DVB-I IP线性信道和现有DVB信道与单个列表相同的UX。
另一方面，不支持互联网或不支持DVB-I的终端可以忽略NIT和BAT的信息。然而，能够使用互联网并且支持DVB-I web应用的终端可以将关于引导的信息递送给DVB-I web应用以获取IP线性信道。
图75示出了根据实施例的接收设备的参考关系。
图75的结构与图34的接口相同/相似。对于图75的结构中与图34的元素相同的元素，参考图34的描述，通过图75的参考关系，如图58所示的接收设备可以基于图62、70和74所示的信令信息发现接收设备75000所期望的服务，并且将该服务提供给用户。
DVB-I客户端34000对应于根据实施例的接收设备/终端。DVB-I客户端75000向内容服务器75010发送内容指南查询，并且响应于该内容指南查询而接收内容指南数据。DDVB-IVB客户端75000将服务列表查询发送到服务列表服务器75020，并且响应于该查询而接收聚合的服务列表。DVB-I客户端75000向服务列表发现75030请求服务列表发现查询，并且响应于此获取服务列表入口点。DVB-I客户端75000向播放列表服务器75040做出对播放列表的查询的请求，并且响应于此获取播放列表。DVB-I客户端75000向MPD服务器75050发送DASH MPD请求，并响应于此接收DASH MPD。DVB-I客户端75000向流服务器75060请求媒体，并且响应于此接收单播DASH。这里，可以在组播中接收单播DASH。
流服务器75060可以将媒体的URL信息提供给MPD服务器75050。MPD服务器75050可以将MPD的URL提供给内容/服务提供商75070并且获取MPD。
内容/服务提供商76070可以从播放列表服务器75040接收用于播放列表的URL，并且将播放列表发送到其地址。内容/服务提供商75070向服务列表服务器75020提供服务记录。服务列表服务器75020提供到服务列表发现75030的入口点。内容/服务提供商75070从内容服务器75010接收用于内容指南数据的URL，并且提供内容指南数据。
图76示出了根据实施例的在一个信道上提供混合服务的元素。
图76示出了为参考图1、2、3、4等描述的相应信道提供混合服务的元素。
根据实施例的广播信号发送设备和广播信号接收设备可以提供DVB网络和DVB-I信道之间的服务链接。
具体地，同一专用信道可以同时提供DVB流和DVB-I流，使得该流可以在特定时间段内动态地改变。通过在不同网络上递送的流在相同信道上提供以不同分辨率产生的内容，并且根据网络条件提供自适应服务。例如，假设HD内容通过DVB网络被接收，并且I信道以不同分辨率承载相同内容。在这种情况下，如果现有信道的带宽好于I信道的可用带宽，则可以向用户显示HD的内容。如果I信道的带宽好于现有信道的带宽，则可以提供UHD或8k分辨率的内容。因此，根据实施例的广播信号接收设备或广播信号接收设备的显示设备可以考虑特定时段的网络带宽来向用户提供具有各种质量的视频。
换言之，广播信号接收设备的调谐器接收包括DVB T/S/C网络的DVB T/S/C流和DVB-I的DVB-I流的广播信号，广播接收设备的控制器(或事件控制器)可以根据接收设备和网络的状况动态地改变T/S/C流和DVB-I流，并且将其提供给用户。这里，可将/S/C流和DVB-I流分配给一个信道，即，同一专用信道，使得控制器可动态地改变这两个流。
DVB SI包括服务和事件相关信息。例如，BAT包括使得能够对一个或多个信道或服务进行编组的信息，并且SDT包括所接收的服务或信道级别的流信息。EIT包括关于与特定服务相对应的时间的事件的信息。流特定信息可通过MPEG-2PSI识别所接收的流。
服务提供商76001可以提供DVB T、S、C流76002和DVB-I流76003。DVB T、S、C流76002表示对应于HD的地面、卫星和有线信道的流，并且DVB-I流76003表示对应于UHD或8K的互联网信道的流。
DVB T、S、C流76002和DVB-I流76003可以通过相同信道号76004来提供。可以为信道号x提供HD服务数据，并且可以为信道号x提供UHD服务数据。从而，广播信号接收设备可以考虑到特定时段的网络带宽而向用户显示各种质量的数据。上面已经描述了DVB T、S、C流76002和DVB-I流76003的信令信息。在下文中，将描述用于同时发送DVB T、S、C流76002和DVB-I流76003并且动态地改变它们的信令信息。
图77示出了根据实施例的信号接收设备的配置。
图77的接收设备对应于图58的广播接收设备，并且还包括一些组件。
TS分组过滤器接收包括在广播信号中的TS分组。TS分组过滤器将包括在TS分组中的分组化的基本流(PES)、数据和信令信息分别递送到PES解析器、数据解析器和信令解析器。
信令解析器解析包括在信令信息中的节目特定信息(PSI)和服务信息(SI)。此外，信令解析器解析来自服务初始化服务器(SDN)的标识信道表(ICT)。
广播信号发送设备可以向两个网络中的同一信道提供各种质量的相同内容。DVBSI和PSI包括初始化信息，并且广播信号接收设备执行服务发现。具体地，可以识别用于相应网络的服务，并且事件控制器18005可以基于服务链接信息以自适应比特率流(ABR)的形式处理接收器解析处理。基于包括多个DASH表示和TS的流，可以根据网络条件或终端的容量来支持选择性内容再现。ABR同步控制器可以请求/处理可支持流以支持更自适应回放。
事件控制器77005基于从PSI、SI和ICT获取的链接信息来处理事件控制器处理。
事件控制器链接来自不同网络的流。链接描述符和extended_event_linkage_info()可以被扩展为不仅支持UHD视频，而且支持8k分辨率的视频。另外，可重新定义与定义PMT基本流信息的ES_info循环中的特定PID对应的链接信息。也就是说，可使用与定义PMT基本流信息的ES_info循环中的特定PID对应的链接信息。
图78示出了根据实施例的链接描述符。
当与根据上述图64的URI链接类型用信号通知URI连接的URI链接描述符相比较时，图78的链接描述符用信号通知链接的属性的信息。
DVB SI包括将附加信息链接到正被接收的服务的信息。链接描述符提供与链接信息相关的位置和附加信息。
transport_stream_id指示包括指示服务的信息的TS。
original_network_id表示指示服务的信息的原始递送系统的网络ID。
service_id指示TS中的服务。service_id可以具有与相应program_map_section中的program_number相同的值。当linkage_type字段的值是0x04时，service_id是不相关的并且被设置为0x0000。
linkage_type指示链接的类型。linkage_type可以包括具有信息服务、EPG服务或完整网络/业务群SI的TS、具有服务替换服务、数据广播服务、RCS映射、移动切换、系统软件更新服务或SSU BAT或NIT的TS、事件链接以及扩展事件链接。
链接描述符可以包括在SDT或EIT中的循环中。链接描述符包括链接相关信息。链接描述符基于target_transport_stream_id、original_network_id、和service_id信息来用信号通知当前服务或事件，并且将特定链接信息定义为linkage_type的值。
由移动接收器切换的服务也可以使用mobile_handover_infor()来指示。
可以使用event_linkage_info()来用信号通知两个事件。链接事件可以是联播或时间偏移。可以使用event_linkage_info()来用信号通知具有高质量的目标事件。event_linkage_info()可以包括target_event_id、target_listed和event_simultast。
target_event_id指示目标事件的ID。目标事件是指通过基于original_network_id、transport_stream_id和service_id表示的服务递送的事件。
target_listed指示基于original_network_id、transport_stream_id和service_id表示的服务是否包括在TS的SDT中。
event_simulcast指示目标事件和源事件是否被联播。
图79示出了根据实施例的扩展的事件链接。
图79表示由图58和图77的信令分析器从广播信号获取的信令信息。
当链接描述符中的linkage_type被设置为特定值时，可以定义extended_event_linkage_info()。
loop_length指示循环的长度或大小。
target_event_id指示目标事件的event_id。目标事件是指通过基于original_network_id、transport_stream_id和service_id表示的服务递送的事件。
target_listed指示基于original_network_id、transport_stream_id和service_id表示的服务是否包括在SDT中。当target_listed被设置为特定值时，该服务被包括在SDT中。
event_simulcast指示目标事件和源事件是否被联播。当event_simulcast被设置为另一个值时，事件具有时间顺序上的偏移。
link_type指示目标服务的类型。根据link_type和linkage_type的组合，目标服务的类型包括SD、HD、H.264、UHD、服务兼容平面-立体MVC和服务帧兼容平面立体。
target_id_type指示目标服务。target_id_type的值可以指示transport_stream_id或target_transport_stream_id用于指示单个目标服务，指示目标服务是否在一个或多个传输流中，或者指示目标服务是否使用用户定义的标识符来匹配。
original_netword_id_flag指示target_original_netword_id是否用于确定目标服务。
service_id_flag指示target_service_id是否用于确定目标服务。
user_defined_id指示链接描述符是否在专用数据说明描述符的范围内。由此，接收器可以确定user_defined_id的含义。
target_transport_stream_id指示包括由target_id_type、original_network_id_flag和service_id_flag表示的信息服务的可替换TS。
target_original_network_id意指由target_id_type、original_network_id_flag和service_id_flag表示的信息服务的递送系统的network_id的标签。
target_service_id指示由target_id_type、original_network_id_flag和service_id_flag表示的信息服务。
extended_event_linkage_info()循环可以定义作为目标的特定event_id，并且可以用信号通知事件是否被联播。目标服务类型可以通过Link_type字段和Linking_type的值的组合来用信号通知，如下面的图22到图23所示。根据实施例的广播信号接收设备可扩展关于8k的链接信息(SUHD)，以实现DVB-I和现有DVB网络之间的自适应服务。
因此，广播信号接收设备的控制器可以基于图19和图20的信令信息获取不同网络的内容或流之间的连接关系。广播信号接收设备的解码器(或渲染器)可以通过动态地改变分配给一个信道的不同网络的内容和流来向用户提供高质量的内容。
DVB-I表示基于MPEG-DASH/DVB-DASH的传输，并且不对应于在传统DVB的MPEG-2系统中定义的信息。因此，包括在图19的链接描述符中的private_data_byte(或专用数据说明描述符)将被如下扩展。
图80示出了根据实施例的private_data_byte。
图80对应于图78的链接描述符中包括的专用数据字节。
图78中的链接描述符包括private_data_byte。private_data_byte包含以下信息。
MPD_id是用信号通知的MPD的标识符。
Adaptationset_id指示MPEG-DASH内容的自适应集合的ID。
representation_id指示MPEG-DASH内容的表示ID。
Base_url指示DVB-I内容的分量和/或片段的URL。
媒体指示DVB-I内容的分量和/或片段的URL。
Adaptationset_id和representation_id是在MPEG-DASH的MPD中定义的内容的分层id信息，并且关于分量和表示的信息可以基于这种id信息来表示。为了检查表示的特定片段的信息，使用片段模板中的baseurl(基本URL)和媒体。即，baseurl和媒体可以指示与当前执行接收的DVB网络相对应的DVB-I的分量和片段url。由目标transport_stream_id、original_network_id_flag和service_id_flag表示的特定表示的目标片段可以通过private_data_byte来用信号通知。
因此，根据实施例的广播信号接收设备或信令解析器解析private_data_byte中所包括的信息。控制器或解码器可以基于Adaptationset_id和representation_id来识别包括在媒体流中的适应或表示，并且可以基于Base_url和媒体来获取包括在媒体流中的分量或片段。换句话说，可以分层地识别和获取包括在DVB-I网络的流中的内容。
图81示出根据各实施例的扩展事件链接描述符的用例。
包括在图78的链接描述符中的linkage_type通过扩展链接描述符提供图79的extended_event_linkage_info()。extended_event_linkage_info()使用link_type在DVB-I和现有DVB网络之间提供自适应服务。
此外，图79的extended_event_linkage_info()可以在将来用于广播网络和DVB-I之间的混合服务。图81示出了对应于8k场景的实施例，其可以用于未来服务。在该方法中，当在现有广播网络中提供8k时，它通过链接信息来提供。
根据linkage_type和link_type的组合，扩展事件链接描述符可以用信号通知源事件的类型是SD而目的地事件的类型是SUHD(8k)，源事件的类型是HD而目的地事件的类型是SUHD(8k)，或者源事件的类型是UHD并且目的地事件的类型是SUHD(8k)。
因此，根据实施例的广播信号发送设备和广播信号接收设备可以提供DVB-I和现有DVB网络之间的自适应服务。
根据图81中的linkage_type和link_type的组合，可以用信号通知源事件和目的地事件之间的链接。
根据实施例的广播信号发送设备和广播信号接收设备在由信道提供的SD、UD或UHD链接服务上基于DVB-I信道提供SUHD(8k)链接。
图82示出了根据实施例的补充视频描述符。
图62、70和74的DVB-SI(信令信息)可以包括节目映射表(PMT)。另外，重新定义了与ES_Info循环或ES_Info描述符循环中的特定PID相对应的链接信息。图82示出了以这种方式定义的链接信息的配置。
扩展事件链接描述符可以用在EIT中，但是TSID和访问MPEG DASH中的特定片段的分层结构不匹配。TSID是其中音频、视频和字幕分量被复用并且可能不适合于链接信息的传输流的标识符。
图82的描述符可以包括以下元素。
multi_stream_info_present指示当前接收的补充视频流是否存在。
original_network_id指示发送补充视频的网络类型的标识符。例如，它可以指示DVB线缆、地面或卫星，或者指示传输网络运营商的标识符。
transport_stream_id是通过其发送补充视频的TSID的标识符
video_linkage_type定义了与补充视频的可能链接类型。如图83的表格所示，可以实现可替换服务或ABR服务。private_data_byte如上所述地配置。
图83示出了根据实施例的可替换服务。
图83示出了与图81的链接类型相关的信令的附加扩展实施例。
如上所述，可以基于视频链接类型来用信号通知源事件和目的地事件之间的链接。基于这样的信令信息，接收设备可以链接到UHD或SUHD中的可替换信道。
作为根据实施例可以实现互联网线性信道和传统DVB信道之间的ABR服务的方法，已经提出了在现有MPEG-2系统和DVB SI服务信道列表配置方法中扩展链接服务信息。DVB-I功能可以通过对IP线性信道执行服务发现并将信道包括在现有TV信道列表中来提供与现有DVB信道服务类似的UX，并且可以具有独立的服务信道。互联网信道和现有DVB网络之间的链接服务也可以通过服务相关初始化信息来获得。
接下来，将描述用于在支持DVB-I的参考架构中的上述ICT(或SDLT)表中提供链接服务的信息的扩展。
图84示出了根据实施例的SDLT。
图84的SDLT可以对应于根据上述实施例的SDLT，并且SDLT可以针对链接服务而被扩展，如图84所示。
@Linkage_type指示与通过DVB-I接收的更高级服务的链接的类型的值。该值可以具有与DVB-SI的URI_linkage_descriptor中的linkage_type相等的属性，并且实现与信道列表链接服务相等的场景。该值指示链接信息的类型。
@link_type是与URI_linkage_descriptor中的extended_event_linkage_info()之下的link_type的值相同。该值使得能够通过链接服务识别可能的ABR比特流。该值指示目标服务(或链路服务)的类型。
基于两个字段的值，图58的ABR同步控制器580008识别可能的比特流的视频属性并且提供服务。
@originalNetworkId、transportStreamId、serviceId和Eventid是用于通过根据网络条件在特定时间内在SD、HD、UHD和SUHD(8k)之间动态切换与相同信道或节目相对应的视频分辨率来提供服务的链接信息。
@list_hidden指示列表对用户是隐藏的还是可见的。
@originalNetworkId识别该服务已经最初从其发起的原始网络。
transportStreamId识别传输流。这种属性存在于传统的DVB T/S/C服务中。对于具有ISO BMFF文件格式的DVB-I服务，该属性可能不存在。
serviceId识别在originalNetworkId的范围内的服务。
Eventid识别serviceId范围内的服务。
图85示出了根据实施例的用于信道列表的UI/UX。
图85示出了根据上述实施例和/或图77的ABR同步控制器的基于信令信息的信道列表的配置。
信道列表示出信道号(例如，40、41、50、51)和每个信道号上的服务(例如，Rocks&Co ABR、变色蓝宝石、BBC体育ABR、BBC HD预览、信道4ABR、信道4UHD、M.net：世界音乐颁奖礼-1ABR)。基于上述信令方案，信道/服务还可以指示ABR。
图86示出了根据实施例的用于动态分辨率支持的ABR流和链接服务。
图86示出了与图85相关的接收设备上的显示实现。
根据实施例的接收设备基于原始网络ID(ONID)、传输流ID(TSID)、服务ID(SVID)和事件ID(EVID)接收传统DVB-T/S/C服务，并且基于ONID、TSID、SVID和EVID接收DVB-I服务。接收设备可以通过UI/UX向用户提供信道号是否支持ABR服务的指示。用户可以通过控制器等控制ABR信道来观看所接收的DVB-T/S/C/I服务。接收设备可以在DVB-T/S/C/I服务之间动态地切换(改变)期望分辨率的服务。当接收设备接收上述链接服务和ABR流时，其可以向用户提供动态服务。
图87示出了根据实施例的EPG视图。
图87示出了在图86的显示器上实现EPG视图的示例。
例如，信道号41和50可以支持ABR。BBC运动能够以HD提供服务，或者能够以UHD提供服务。接收设备可以在显示器上显示EPG指南信息和附加预览图像。
接收设备可以指示信道50具有信道4ABR和信道3UHD的服务。EPG可以基于信道/服务内容/时间/日期来显示。
图88示出了根据实施例的发送设备的配置。
通过如图88所示的处理来发送根据上述实施例的包括数据和信令信息的广播信号。图88的发送设备是与图58、77和78的接收设备相对应的发送侧上的设备。
根据实施例的用于未来广播服务的广播信号发送设备可以包括输入格式块1000、比特交织编码和调制(BICM)块1010、帧构建块1020、正交频分复用(OFDM)生成块1030和信令生成块1040。将描述广播信号发送设备的每个块的操作。
IP流/分组和MPEG2-TS是主要输入格式，而其他流类型被作为通用流对待。除了这些数据输入之外，还输入管理信息。因此，控制了每个输入流的带宽的调度和分配。允许同时输入一个或多个TS流、IP流和/或通用流。
输入格式块1000可以将输入流解复用为应用独立编码和调制的一个或多个数据管道。数据管道是鲁棒性控制的基本单元，其影响服务质量(QoS)。一个或多个服务或服务组件可以由数据管道承载。
数据管道是承载服务数据的物理层的逻辑信道或可以承载一个或多个服务或服务组件的相关元数据。数据管道可以对应于物理层管道(PLP)。
此外，数据管道单元是用于将数据信元分配给一帧中的数据管道的基本单元。
在输入格式块1000中，添加奇偶校验数据用于纠错，并且将编码的比特流映射到复数值星座符号。在用于数据管道的特定交织深度上对符号进行交织。对于高级配置，在BICM块1010中执行MIMO编码，并且将附加数据路径添加到输出以用于MIMO传输。
帧构建块1020可以将输入数据管道的数据信元映射到一个帧内的OFDM符号。在映射之后，频率交织用于频域分集，特别是避免频率选择性衰落信道。
在每个帧的开始处插入前同步码之后，OFDM生成块1030可以应用传统OFDM调制，其具有作为保护间隔的循环前缀。对于天线空间分集，在发送器之间应用分布式MISO方案。此外，在时域中执行峰均功率比降低(PAPR)方案。对于灵活网络配置，该提议提供了一组各种FFT大小、保护间隔长度和相应导频模式。
信令生成块1040可以生成用于每个功能块的操作的物理层信令信息。还发送信令信息，使得在接收器侧正确地恢复感兴趣服务。
图89示出了根据实施例的接收设备的配置。
根据上述实施例的包括数据和信令信息的广播信号通过图89所示的处理被接收。图89的接收设备可以对应于图58、77和78的接收设备。
根据实施例的用于未来广播服务的广播信号接收设备可以对应于参照图1描述的用于未来广播服务的广播信号发送设备。
根据实施例的用于未来广播服务的广播信号接收设备可以包括同步与解调模块9000、帧解析模块9010、解映射与解码模块9020、输出处理器9030和信令解码模块9040。将给出广播信号接收设备的每个模块的操作的描述。
同步与解调模块9000可以通过m个接收天线接收输入信号，执行与广播信号接收设备相对应的系统的信号检测和同步，并且执行与由广播信号发送设备执行的过程的相反过程相对应的解调。
帧解析模块9010可以解析输入信号帧，并且提取发送用户选择的服务的数据。当广播信号发送设备执行交织时，帧解析模块9010可以执行解交织，这对应于交织的逆过程。在这种情况下，可以通过对从信令解码模块9040输出的数据进行解码来获取需要提取的信号和数据的位置，以恢复由广播信号发送设备生成的调度信息。
解映射与解码模块9020可以将输入信号转换为比特域数据，然后根据需要对其进行解交织。解映射与解码模块9020可以执行针对传输效率而应用的映射的解映射，并且通过解码来校正在传输信道上生成的错误。在这种情况下，解映射与解码模块9020可以通过对从信令解码模块9040输出的数据进行解码来获取解映射和解码所需的传输参数。
输出处理器9030可以执行由广播信号发送设备应用的各种压缩/信号处理过程的逆过程，以提高传输效率。在这种情况下，输出处理器9030可以从信令解码模块9040输出的数据中获取必要的控制信息。输出处理器8300的输出可以对应于输入到广播信号发送设备的信号，并且可以是MPEG-TS、IP流(v4或v6)和GS。
信令解码模块9040可以从由同步与解调模块9000解调的信号中获取PLS信息。如上所述，帧解析模块9010、解映射与解码模块9020和输出处理器9030可以使用从信令解码模块9040输出的数据来执行其功能。
图90图示了根据实施例的广播信号发送方法。
S90000：根据实施例的广播信号发送方法包括对用于广播网络的服务数据进行编码。
S90010：广播信号发送方法还包括对用于互联网网络的服务数据进行编码。
用于广播网络的服务数据和/或用于互联网网络的服务数据可以是相同服务数据和/或不同服务数据。另外，可以单独地或一起执行相应服务数据的编码。
例如，根据实施例的编码可以包括图1中的DVB-I传输、图2中的地面、组播和DVB-I数据的编码、根据图3中的协议的卫星、线缆、地面或基于互联网的数据的编码、根据图10中的服务类别的服务数据的编码、包括根据图11中的格式的内容的服务的编码、和/或图88中的输入格式化、BICM编码、帧构建和OFDM调制。
S90020：广播信号发送方法还包括生成用于用信号通知服务数据的信令信息。生成信令信息可以包括编码信令信息(图88)。生成信令信息的操作可以包括在图5、6、9、10、9至15、18、20至22、26、27、30、31、35至40、42、47至56、60至74、78至85等中生成信令信息的操作。
S90030：广播信号发送方法还包括发送服务数据和信令信息。发送包括服务数据和信令信息的广播信号可以包括图2、3和88中的发送等。
图91示出根据实施例的广播信号接收方法。
S91000：根据实施例的广播信号接收方法包括接收广播信号。接收包括服务数据和信令信息的广播信号可以包括图1到4、6到8、16、17、19、23到25、28、29、32到34、41、44、57、58、62、70、74到77、86、87和89中的接收操作。
S91010：根据实施例的广播信号接收方法还包括解析信令信息。解析信令信息可以包括在图5、6、9到15、18、20到22、26、27、30、31、35到40、42、47到56、60到74、78到85等中解析和获取信令信息的操作。
S91020：广播信号接收方法还包括基于信令信息来解码服务数据。解码操作可以包括：解码服务数据和/或信令信息，并且基于图1、2、4、6、7、16、17、19、23、24、25、28、32、33、41、44、57、58、76、77、86、87和89中所示的信令信息向用户提供服务数据。
图91的广播信号接收方法可以遵循图90的广播信号发送方法的操作的逆过程。
上述每个部分、模块或单元可以是执行存储在存储器(或存储单元)中的连续过程的软件、处理器或硬件部分。上述实施例中描述的各个操作可以由软件、处理器或硬件部分来执行。以上示例中描述的每个模块/块/单元可以作为处理器、软件或硬件来操作。另外，在实施例中提出的方法可以通过代码来实现。代码可以被写入处理器可读的记录介质中，以便代码可以由通过该装置提供的处理器读取。
尽管为了清楚起见参考每个附图进行了本公开的描述，但是可以通过将附图中示出的示例彼此合并来设计新示例。如果计算机可读的其中记录了用于执行在前述描述中提及的示例的程序的记录介质由本领域技术人员设计，则其可以落入所附权利要求及其等同物的范围内。
根据实施例的设备和方法可以不受在前述描述中提及的示例的配置和方法的限制。在上述说明中提及的示例能够以选择性地彼此完全或部分组合的方式配置，以使得能够进行各种修改。
另外，根据实施例的所提出的方法可以利用提供给网络设备的处理器可读记录介质中的处理器可读代码来实现。处理器可读介质可以包括能够存储处理器可读的数据的所有种类的记录设备。处理器可读介质可以包括ROM、RAM、CD-ROM、磁带、软盘、光学数据存储设备等中的一个，并且还包括载波类型的实现，诸如经由互联网的传输。此外，当处理器可读记录介质被分发到经由网络连接的计算机系统时，能够以分布式方式保存和执行处理器可读代码。
尽管已经参考示例性实例描述了本公开，但是本领域技术人员将理解，在不脱离所附权利要求中描述的本公开的精神或范围的情况下，可以对实施例进行各种修改和变化。不能从本公开的技术思想或观点单独地理解这样的修改。
本领域技术人员将理解，在不脱离本公开的精神或范围的情况下，可以对实施例进行各种修改和变化。因此，本公开旨在覆盖本公开的修改和变化，只要它们落在所附权利要求及其等同物的范围内。
在本公开中，提及了装置公开和方法公开两者，并且对装置公开和方法公开两者的描述可以应用于彼此补充。
在本文档中，术语“/”和“,”应当被解释为指示“和/或”。例如，表述“A/B”可以意指“A和/或B”。进一步，“A,B”可以意指“A和/或B”。进一步，“A/B/C”可以表示“A、B和/或C中的至少一个”。同样，“A/B/C”可以意指“A、B和/或C中的至少一个”。
此外，在该文档中，术语“或”应当被解释为指示“和/或”。例如，表述“A或B”可以包括1)仅A，2)仅B，和/或3)A和B两者，换言之，本文档中的术语“或”应当被解释为指示“附加地或替代地”。
实施例的各种元素可以通过硬件、软件、固件或其组合来实现。实施例中的各种元素可以由诸如单个硬件电路的单个芯片执行。根据实施例，该元素可以分别由单独芯片选择性地执行。根据实施例，实施例的至少一个元素可以在包括用于执行根据实施例的操作的指令的一个或多个处理器中执行。
诸如第一和第二的术语可用于描述实施例的各种元素。然而，根据实施例的各种元素不应被上述术语限制。这些术语仅用于将一个元素与另一个元素区分。
用于描述实施例的术语仅用于描述特定实施例的目的，而不是要限制实施例。如在实施例的描述和权利要求中所使用的，单数形式“一”、“一个”和“该”包括复数指示物，除非上下文另外清楚地规定。表述“和/或”用于包括术语的所有可能组合。诸如“包括”或“具有”的术语旨在指示图、数字、步骤、元素和/或组件的存在，并且应当被理解为不排除图、数字、步骤、元素和/或组件的附加存在的可能性。
如本文所使用的，诸如“如果”和“当......时”的条件表达不限于可选情况，并且旨在当满足特定条件时被解释为根据特定条件执行相关操作或解释相关定义。
[用于公开的模式]
以最佳模式进行了详细描述。
[工业实用性]
对于本领域技术人员显而易见的是，在不脱离本公开的精神或范围的情况下，可以对本公开进行各种改变和修改。因此，本公开旨在覆盖在所附权利要求及其等同物内提供的本公开的修改和改变。

Claims (20)

1.一种广播信号接收设备，包括：
接收器，所述接收器被配置为接收广播信号，所述广播信号包括用于广播网络的服务数据和用于互联网网络的服务数据，其中所述广播信号还包括用于用信号通知所述服务数据的信令信息；
信令解析器，所述信令解析器被配置为解析所述信令信息；以及
解码器，所述解码器被配置为基于所述信令信息来解码所述服务数据。
2.根据权利要求1所述的设备，其中，所述信令信息包括URI链接描述符，所述URI链接描述符用于用信号通知对用于所述互联网网络的服务列表或服务列表注册的查询的地址。
3.根据权利要求2所述的设备，其中，所述URI链接描述符包括端点类型。
4.根据权利要求3所述的设备，其中，基于所述端点类型具有第一值，所述端点类型指示所述信令信息用信号通知指示用于所述互联网网络的服务列表的位置的URI。
5.根据权利要求3所述的设备，其中，基于所述端点类型具有第二值，所述端点类型指示所述信令信息用信号通知包括对所述服务列表注册表的所述查询的URI。
6.根据权利要求3所述的设备，其中，响应于所述端点类型的第一值，所述URI链接描述符包括指示用于所述互联网网络的服务列表的位置的服务列表位置。
7.根据权利要求3所述的设备，其中，响应于所述端点类型的第二值，所述URI链接描述符包括查询串，所述查询串包括对用于所述互联网网络的所述服务列表注册表的所述查询。
8.一种广播信号接收方法，包括：
接收广播信号，所述广播信号包括用于广播网络的服务数据和用于互联网网络的服务数据，其中所述广播信号还包括用于用信号通知所述服务数据的信令信息；
解析所述信令信息；以及
基于所述信令信息来解码所述服务数据。
9.根据权利要求8所述的方法，其中，所述信令信息包括URI链接描述符，所述URI链接描述符用于用信号通知对用于所述互联网网络的服务列表或服务列表注册的查询的地址。
10.根据权利要求9所述的方法，其中，所述URI链接描述符包括端点类型。
11.根据权利要求10所述的方法，其中，基于所述端点类型具有第一值，所述端点类型指示所述信令信息用信号通知指示用于所述互联网网络的服务列表的位置的URI。
12.根据权利要求10所述的方法，其中，基于所述端点类型具有第二值，所述端点类型指示所述信令信息用信号通知包括对所述服务列表注册表的所述查询的URI。
13.根据权利要求10所述的方法，其中，响应于所述端点类型的第一值，所述URI链接描述符包括指示用于所述互联网网络的服务列表的位置的服务列表位置。
14.根据权利要求10所述的方法，其中，响应于所述端点类型的第二值，所述URI链接描述符包括查询串，所述查询串包括对用于所述互联网网络的所述服务列表注册表的所述查询。
15.一种广播信号传输方法，包括：
编码用于广播网络的服务数据；
编码用于互联网网络的服务数据；
生成用于用信号通知所述服务数据的信令信息；以及
发送所述业务数据和所述信令信息。
16.根据权利要求15所述的方法，其中，所述信令信息包括URI链接描述符，所述URI链接描述符用于用信号通知对用于所述互联网网络的服务列表或服务列表注册的查询的地址。
17.根据权利要求16所述的方法，其中，所述URI链接描述符包括端点类型。
18.一种广播信号发送设备，包括：
编码器，所述编码器被配置为编码用于广播网络的服务数据以及编码用于互联网网络的服务数据；
信令生成器，所述信令生成器被配置为生成用于用信号通知所述服务数据的信令信息；以及
发送器，所述发送器被配置为发送所述服务数据和所述信令信息。
19.根据权利要求18所述的设备，其中，所述信令信息包括URI链接描述符，所述URI链接描述符用于用信号通知对用于所述互联网网络的服务列表或服务列表注册的查询的地址。
20.根据权利要求19的所述设备，其中，所述URI链接描述符包括端点类型。
CN202080052294.6A 2019-07-19 2020-07-07 广播信号发送设备、广播信号发送方法、广播信号接收方法和广播信号接收设备 Active CN114128301B (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
KR20190087743 2019-07-19
KR10-2019-0087743 2019-07-19
KR20190122581 2019-10-02
KR10-2019-0122581 2019-10-02
PCT/KR2020/008840 WO2021015450A1 (ko) 2019-07-19 2020-07-07 방송 신호 송신 장치, 방송 신호 송신 방법, 방송 신호 수신 방법 및 방송 신호 수신 장치

Publications (2)

Publication Number Publication Date
CN114128301A true CN114128301A (zh) 2022-03-01
CN114128301B CN114128301B (zh) 2024-04-16

Family

ID=74194288

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202080052294.6A Active CN114128301B (zh) 2019-07-19 2020-07-07 广播信号发送设备、广播信号发送方法、广播信号接收方法和广播信号接收设备

Country Status (4)

Country Link
US (1) US20220264159A1 (zh)
EP (1) EP4002856A4 (zh)
CN (1) CN114128301B (zh)
WO (1) WO2021015450A1 (zh)

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1906947A (zh) * 2004-01-06 2007-01-31 汤姆森许可贸易公司 在网络上传输数字服务的方法和实现该方法的设备
US20110016171A1 (en) * 2009-07-14 2011-01-20 Samsung Electronics Co., Ltd. Method and apparatus for client capable of accessing broadcasting network and internet network to receive application
US20110182562A1 (en) * 2010-01-25 2011-07-28 Canon Kabushiki Kaisha Digital broadcast receiving apparatus and method for controlling the same
US8503447B2 (en) * 2007-09-20 2013-08-06 Lg Electronics Inc. Broadcast receiver and channel information processing method
CN105165018A (zh) * 2013-06-27 2015-12-16 Lg电子株式会社 基于地面广播网络和网际协议网络的连接在混合广播系统中发送和接收广播服务的方法和装置
US20160255394A1 (en) * 2015-03-01 2016-09-01 Lg Electronics Inc. Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method of transmitting broadcast signals and method of receiving broadcast signals
JP2017510091A (ja) * 2014-11-20 2017-04-06 エルジー エレクトロニクス インコーポレイティド 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法
CN107852516A (zh) * 2015-07-06 2018-03-27 Lg电子株式会社 广播信号发送装置、广播信号接收装置、广播信号发送方法和广播信号接收方法
US20180262814A1 (en) * 2015-02-10 2018-09-13 Lg Electronics Inc. Apparatus for transmitting broadcast signal, apparatus for receiving broadcast signal, method for transmitting broadcast signal and method for receiving broadcast signal

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101265635B1 (ko) * 2007-01-10 2013-05-23 엘지전자 주식회사 방송 신호 수신 방법 및 방송 수신 장치
JP6151152B2 (ja) * 2013-10-11 2017-06-21 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
GB2529838B (en) * 2014-09-03 2021-06-30 Advanced Risc Mach Ltd Bootstrap Mechanism For Endpoint Devices
KR102464061B1 (ko) * 2015-02-13 2022-11-08 삼성전자주식회사 미디어 데이터를 송수신하는 방법 및 장치
WO2017014586A1 (ko) * 2015-07-21 2017-01-26 엘지전자(주) 방송 신호 송수신 장치 및 방법
WO2021177630A1 (ko) * 2020-03-05 2021-09-10 엘지전자 주식회사 미디어 처리 장치 및 미디어 처리 방법

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1906947A (zh) * 2004-01-06 2007-01-31 汤姆森许可贸易公司 在网络上传输数字服务的方法和实现该方法的设备
US8503447B2 (en) * 2007-09-20 2013-08-06 Lg Electronics Inc. Broadcast receiver and channel information processing method
US20110016171A1 (en) * 2009-07-14 2011-01-20 Samsung Electronics Co., Ltd. Method and apparatus for client capable of accessing broadcasting network and internet network to receive application
US20110182562A1 (en) * 2010-01-25 2011-07-28 Canon Kabushiki Kaisha Digital broadcast receiving apparatus and method for controlling the same
CN105165018A (zh) * 2013-06-27 2015-12-16 Lg电子株式会社 基于地面广播网络和网际协议网络的连接在混合广播系统中发送和接收广播服务的方法和装置
JP2017510091A (ja) * 2014-11-20 2017-04-06 エルジー エレクトロニクス インコーポレイティド 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法
US20180262814A1 (en) * 2015-02-10 2018-09-13 Lg Electronics Inc. Apparatus for transmitting broadcast signal, apparatus for receiving broadcast signal, method for transmitting broadcast signal and method for receiving broadcast signal
US20160255394A1 (en) * 2015-03-01 2016-09-01 Lg Electronics Inc. Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method of transmitting broadcast signals and method of receiving broadcast signals
KR101814404B1 (ko) * 2015-03-01 2018-01-04 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
CN107852516A (zh) * 2015-07-06 2018-03-27 Lg电子株式会社 广播信号发送装置、广播信号接收装置、广播信号发送方法和广播信号接收方法

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ETSI: "digital video broadcasting(DVB);guidelines on implementation and usage of service information(SI)", ETSI *
ETSI: "digital video broadcasting(DVB);specification for service information(SI) in DVB systems", ETSI, pages 110 *
ETSI: "digital video broadcasting(DVB);transport of MPEG-2 TS based DVB services over IP based networks", ETSI, pages 16 - 40 *

Also Published As

Publication number Publication date
EP4002856A1 (en) 2022-05-25
WO2021015450A1 (ko) 2021-01-28
CN114128301B (zh) 2024-04-16
US20220264159A1 (en) 2022-08-18
EP4002856A4 (en) 2023-05-03

Similar Documents

Publication Publication Date Title
US11082729B2 (en) Method and apparatus for transmitting and receiving signaling information associated with multimedia content
KR102325529B1 (ko) 신호 송신 장치, 신호 송신 방법, 신호 수신 방법 및 신호 수신 장치
US8893200B2 (en) IPTV receiver and method of acquiring a resource for an IPTV service
US8893205B2 (en) IPTV receiver and method of providing channel map management information
US20160352793A1 (en) Apparatus for processing a hybrid broadcast service, and method for processing a hybrid broadcast service
US10999612B2 (en) Broadcast signal reception device and broadcast signal reception method
US20090158327A1 (en) IPTV receiver and method of providing channel map information
US20170164071A1 (en) Broadcast signal transmission apparatus, broadcast signal reception apparatus, broadcast signal transmission method, and broadcast signal reception method
US11758205B2 (en) Broadcasting signal transmitting device, broadcasting signal receiving device, broadcasting signal transmitting method, and broadcasting signal receiving method
EP3790286A1 (en) Broadcast signal transmission device, broadcast signal transmission method, broadcast signal reception method, and broadcast signal reception device
CN101232613B (zh) 发送/接收数字内容的方法和接收数字内容的装置
US11895347B2 (en) Media processing device and media processing method
EP3836553B1 (en) Broadcast signal transmission method, broadcast signal transmission apparatus, broadcast signal reception method, and broadcast signal reception apparatus
KR100914709B1 (ko) Ｉｐｔｖ 수신기 및 채널 맵 관리 정보 제공 방법
US11742971B2 (en) Broadcast receiving apparatus and method of processing transmission waves
EP4207776A1 (en) Media data processing method and media data processing device
CN114128301B (zh) 广播信号发送设备、广播信号发送方法、广播信号接收方法和广播信号接收设备
EP4167578A1 (en) Media data processing method and media data processing apparatus
EP4376421A1 (en) Media data processing method and media data processing device
US20240137590A1 (en) Media data processing method and media data processing apparatus
EP4307688A1 (en) Media data processing method and media data processing device
KR100914710B1 (ko) Ｉｐｔｖ 수신기 및 ｉｐｔｖ 서비스를 위한 리소스 획득 방법
KR20090002820A (ko) 서비스 가이드 정보 수신 방법 및 서비스 가이드 정보 수신장치

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant