CN109964486B

CN109964486B - 广播标识符信令

Info

Publication number: CN109964486B
Application number: CN201780066130.7A
Authority: CN
Inventors: 萨钦·G·德施潘德
Original assignee: Sharp Corp
Current assignee: Sharp Corp
Priority date: 2016-11-03
Filing date: 2017-10-31
Publication date: 2021-07-20
Anticipated expiration: 2037-10-31
Also published as: TW201841515A; WO2018084150A1; KR20190068604A; US20190261253A1; CN109964486A; CA3041982C; CA3041982A1; KR102166984B1; TWI639349B; TW201820902A; MX2019004781A

Abstract

一种用于使用OtherBsid(图26B)、@type(图26B)、@essential(图26B)、“type”(图30)、SLT(图26A)、和@serviceID(图26A)来生成、发送、提供和/或接收服务信息的系统。

Description

广播标识符信令

技术领域

本公开总体上涉及服务信令。

背景技术

广播服务能够被具有广播接收器的所有用户接收。广播服务可以大致分为两类，即，仅承载音频的无线电广播服务和承载音频、视频和数据的多媒体广播服务。这种广播服务已从模拟服务发展到数字服务。最近，各种类型的广播系统(诸如有线广播系统、卫星广播系统、基于因特网的广播系统、以及使用有线网络、因特网和/或卫星的混合广播系统)提供高质量的音频和视频广播服务以及高速数据服务。而且，广播服务包括发送和/或接收指向个人计算机和/或计算机组和/或一个或多个移动通信设备的音频、视频和/或数据。

除了更传统的固定接收设备之外，移动通信设备同样被配置为支持这样的服务。这样配置的移动设备便于用户在移动中使用这样的服务，诸如移动电话。对多媒体服务的日益增长的需求已经导致用于移动通信和通用有线通信的各种无线和/或广播服务。此外，这种融合已经融合了不同有线和无线广播服务的环境。

开放移动联盟(OMA)是在各个移动解决方案之间互通的标准，用于定义移动软件和互联网服务的各种应用标准。OMA移动广播服务启动器套件(BCAST)是一种被设计来支持移动广播技术的规范。OMA BCAST定义了提供基于IP的移动内容传递的技术，其包括各种功能，例如下载和流传输服务指南、服务和内容保护、服务订阅、和漫游。

通过结合附图考虑本发明的以下详细描述，将更容易理解本发明的前述和其他目的、特征和优点。

发明内容

本发明的一个实施例公开了一种用于用信号发送与第一射频信道中的服务相关联的服务信息的方法，该方法包括：用信号发送与第一射频信道相关联的服务列表；用信号发送与第一射频信道相关联的服务列表中的服务信息；并且，用信号发送与第一射频信道相关联的服务列表中的服务信息相关的必要信息，其中，必要信息是指示第一射频信道中的服务具有由第二射频信道传送的一个或多个部分的属性；在必要信息属性为真的情况下，用信号发送与指示部分类型的第一射频信道相关联的服务列表中的服务信息中的至少一个其他广播服务标识(OtherBSID)元素；在必要信息属性为假的情况下，不用信号发送与第一射频信道相关联的服务列表中的服务信息中的任何其他广播服务标识(OtherBSID)元素；以及，发送服务列表。

本发明的一个实施例公开了一种用于呈现视频服务的设备，所述设备包括一个或多个处理器，其被配置为：接收第一射频信道；以及，接收所述第一射频信道中的第一服务列表；以及，解析所述第一服务列表以接收服务元素；以及，确定所述服务元素是否包括必要信息属性；以及，在存在所述必要信息属性的情况下，解析所述服务元素以确定所述必要信息属性的值；以及，当所述必要元素的值为真时：解析所述服务元素以接收一个或多个其他广播服务标识(OtherBSID)元素；以及，确定所述一个或多个其他广播服务标识(OtherBSID)元素中的每一个的类型；以及，当所述必要元素的值为假时，不解析所述服务元素以接收一个或多个其他广播服务标识(OtherBSID)元素；以及，使用所述服务信息呈现所述视频服务。

附图说明

[图1]

图1是示出由应用层和传输层中的OMA BCAST工作组指定的BCAST系统的逻辑架构的框图。

[图2]

图2是示出用于OMA BCAST系统中的服务指南的结构的图。

[图2A]

图2A是示出在服务指南片段之间的基数和参考方向的图。

[图3]

图3是示出传统服务指南传送方法的原理的框图。

[图4]

图4示出了描述方案。

[图5]

图5示出了具有MajorChannelNum和MinorChannelNum的ServiceMediaExtension。

[图6]

图6示出了具有Icon的ServiceMediaExtension。

[图7]

图7示出了具有url的ServiceMediaExtension。

[图8]

图8示出了具有MajorChannelNum、MinorChannelNum、Icon、和 url的ServiceMediaExtension。

[图9A]

图9A示出了AudioLanguage元素和TextLanguage元素。

[图9B]

图9B示出了AudioLanguage元素和TextLanguage元素。

[图9C]

图9C示出了AudioLanguage元素和TextLanguage元素。

[图10A]

图10A示出了AudioLanguage元素和TextLanguage元素。

[图10B]

图10B示出了AudioLanguage元素和TextLanguage元素。

[图10C]

图10C示出了AudioLanguage元素和TextLanguage元素。

[图11]

图11示出了组件信息描述信号信令。

[图12]

图12示出了信道信息描述信号信令。

[图13A]

图13A示出了组件信息描述符的二进制语法。

[图13B]

图13B示出了组件信息描述符的二进制语法。

[图14A]

图14A示出了信道信息描述符的二进制语法。

[图14B]

图14B示出了信道信息描述符的二进制语法。

[图15]

图15示出了组件信息描述符的XML语法和语义。

[图16]

图16示出了用于信道信息描述符的XML语法和语义。

[图17]

图17示出了组件信息描述符的XML模式。

[图18]

图18示出了信道信息描述符的XML模式。

[图19]

图19示出了服务列表(SLT)。

[图20A]

图20A示出了SLT的XML模式。

[图20B]

图20B示出了SLT的XML模式。

[图20C]

图20C示出了SLT的结构。

[图21]

图21示出了URLType的代码值。

[图22]

图22示出了SLT.Service@serviceCategory的代码值。

[图23]

图23示出了SLT.Service@slsProtocol的代码值。

[图24]

图24以路径中的出现顺序示出了路径项。

[图25]

图25示出元数据对象类型。

[图26A]

图26A 示出了示例服务列表。

[图26B]

图26B 示出了示例服务列表。

[图27]

图27示出了urlType的示例代码值。

[图28]

图28示出了SLT.Service@serviceCategory的示例代码值。

[图29]

图29示出了SLT.Service.BroadcastSvcSignaling@slsProtocol的示例代码值。

[图30]

图30示出了SLT.Service.OtherBsid@type的示例代码值。

具体实施方式

参考图1，由OMA(开放移动联盟)BCAST指定的广播系统的逻辑架构可以包括应用层和传输层。BCAST系统的逻辑架构可以包括内容创建(CC)101、BCAST服务应用102、BCAST服务分发自适应 (BSDA)103、BCAST订阅管理(BSM)104、终端105、广播分发系统(BDS)服务分发111、BDS 112、和交互网络113。应该理解，可以根据需要重新配置广播系统和/或接收器系统。应该理解，广播系统和/或接收器系统可以根据需要包括附加元件和/或更少元件。

通常，内容创建101可以提供作为BCAST服务的基础的内容。该内容可以包括用于公共广播服务的文件，例如包括音频和视频的电影的数据。内容创建101向BCAST服务应用102提供内容的属性，其用于创建服务指南并确定将通过其传递服务的传输承载。

通常，BCAST服务应用102可以接收从内容创建101提供的 BCAST服务的数据，并且将接收的数据转换成适合于提供媒体编码、内容保护、交互服务等的形式。BCAST服务应用102向BSDA 103和 BSM 104提供从内容创建101接收到的内容的属性。

通常，BSDA 103可以使用从BCAST服务应用102提供的BCAST 服务数据来执行操作，诸如文件和/或流传输、服务收集、服务保护、服务指南创建/传递和服务通知。BSDA 103使服务适应BDS 112。

通常，BSM 104可以经由硬件或软件管理服务供应，诸如用于 BCAST服务用户的订阅和计费相关功能、用于BCAST服务的信息供应以及接收BCAST服务的移动终端。

通常，终端105可以接收内容和/或服务指南和节目支持信息——诸如内容保护，并向用户提供广播服务。BDS服务分发111通过与BDS 112和交互网络113的相互通信向多个终端传送移动广播服务。

通常，BDS 112可以通过广播信道传送移动广播服务，并且可以包括例如第三代项目合作伙伴(3GPP)的多媒体广播多播服务 (MBMS)、第三代项目合作伙伴2(3GPP2)的广播多播服务(BCMCS)、通过数字视频广播(DVB)的DVB-手持设备(DVB-H)、或基于互联网协议(IP)的广播通信网络。交互网络113提供交互信道，并且可以包括例如蜂窝网络。

参考点或图1的逻辑实体之间的连接路径可以根据需要具有多个接口。接口用于在两个或多个逻辑实体之间的通信以用于其特定目的。对接口应用消息格式和协议等。在一些实施例中，在一个或多个不同功能之间不存在逻辑接口。

BCAST-1 121是用于内容和内容属性的传输路径，BCAST-2 122 是用于内容受保护或内容不受保护的BCAST服务、BCAST服务的属性、和内容属性的传输路径。

BCAST-3 123是BCAST服务的属性、内容的属性、用户偏好和/ 或订阅信息、用户请求、以及对请求的响应的传输路径。BCAST-4 124 是用于通知消息、用于服务指南的属性、以及用于内容保护和服务保护的密钥的传输路径。

BCAST-5 125是受保护的BCAST服务、不受保护的BCAST服务、内容受保护的BCAST服务、内容不受保护的BCAST服务、BCAST服务属性、内容属性、通知、服务指南、诸如数字版权管理(DRM)权利对象(RO)和用于BCAST服务保护的密钥值的安全材料、以及通过广播信道传输的所有数据和信令的传输路径。

BCAST-6 126是受保护的BCAST服务、不受保护的BCAST服务、内容受保护的BCAST服务、内容不受保护的BCAST服务、BCAST服务属性、内容属性、通知、服务指南、诸如DRM RO和用于BCAST 服务保护的密钥值的安全材料、以及通过交互信道传输的所有数据和信令的传输路径。

BCAST-7 127是用于服务提供、订阅信息、设备管理、和通过用于与诸如DRM RO和用于BCAST服务保护的密钥值的安全材料的接收相关的控制信息的交互信道传输的用户偏好信息的传输路径。

BCAST-8 128是传输路径，通过该路径提供用于BCAST服务的用户数据。BDS-1 129是受保护的BCAST服务、不受保护的BCAST服务、BCAST服务属性、内容属性、通知、服务指南、和诸如DRM RO 和用于BCAST服务保护的密钥值的安全材料的传输路径。

BDS-2 130是用于服务供应、订阅信息、设备管理、和诸如DRM RO和用于BCAST服务保护的密钥值的安全材料的传输路径。

X-1 131是BDS服务分发111和BDS 112之间的参考点。X-2 132 是BDS服务分发111和交互网络113之间的参考点。X-3 133是BDS 112 和终端105之间的参考点。X-4 134是广播信道上BDS服务分发111 和终端105之间的参考点。X-5 135是通过交互信道的在BDS服务分发111和终端105之间的参考点。X-6 136是交互网络113和终端105 之间的参考点。

参考图2，示出了OMA BCAST系统的示例性服务指南。出于说明的目的，片段之间的实线箭头指示片段之间的参考方向。应该理解，可以根据需要重新配置服务指南系统。应该理解，服务指南系统可以根据需要包括附加元件和/或更少元件。应该理解，可以根据需要修改和/或组合元件的功能。

图2A是示出服务指南片段之间的基数和参考方向的图。图2中所示的基数的含义如下：如图2中的片段A的一个实例化引用片段B的 c到d实例化。如果c等于d，则省略d。因此，如果c>0并且存在片段A，则至少还必须存在片段B的c实例化，但是最多可能存在片段B的d实例化。反之亦然，片段B的一个实例化由片段A的a到b实例引用。如果a等于b，则省略b。从片段A指向片段B的箭头连接表示片段A包含对片段B的引用。

参考图2，通常，服务指南可以包括用于提供关于整个服务指南的必要信息的管理组200、用于提供订阅和购买信息的供应组210、用作服务指南的核心部分的核心组220、和用于提供控制对服务和内容的接入的接入信息的接入组230。

管理组200可以包括服务指南传递描述符(SGDD)201。供应组 210可以包括购买项块211、购买数据块212、和购买渠道块213。核心组220可以包括服务块221、调度块222、和内容块223。接入组230 可以包括接入块231和会话描述块232。

除了管理组200、供应组210、核心组220、和/或接入组230之外，服务指南还可以包括预览数据241和交互数据251。

出于识别的目的，上述组件可以被称为构成服务指南的各方面的基本单元或片段。

SGDD片段201可以提供关于服务指南传递单元(SGDU)所在的传递会话的信息。SGDU是包含构成服务指南的服务指南片段211、212、 213、221、222、223、231、232、241、和251的容器。SGDD还可以提供关于用于接收分组信息和通知消息的入口点的信息。

作为包括在广播服务中的内容的上部聚合的服务片段221可以包括关于服务内容、类型(genre)、服务位置等的信息。通常，“Service (服务)”片段在聚合级别描述内容项目，其包括广播服务。可以使用多种接入手段——例如，广播信道和交互信道——将服务传递给用户。该服务可以针对特定用户组或地理区域。根据服务类型，它可能具有(一个或多个)交互部分、(一个或多个)仅广播部分或两者。此外，服务可以包括与内容不直接相关但是与诸如购买或订阅信息的服务的功能相关的组件。作为服务指南(SG)的一部分、“Service”片段形成了由包括“Access(访问)”、“Schedule(调度)”、“Content (内容)”和“PurchaseItem(购买项目)”片段的其他片段引用的中心枢纽。除此之外，“Service”片段可以引用“PreviewData(预览数据)”片段。它可以由这些片段中的几个引用，或者不由这些片段中的任一个引用。终端可以与相关联的片段一起在任何时间点确定与服务相关联的细节。这些细节可以概括为用户友好的显示，例如，可以消费的相关联的内容的内容、方式和时间以及成本为何。

接入片段231可以提供用于允许用户查看服务和传递方法的接入相关信息，以及与对应的接入会话相关联的会话信息。因此，“Access”片段描述了在服务的生命周期内如何接入服务。此片段包含或引用会话描述信息并指示传递方法。一个或多个“Access”片段可以引用“服务”片段，提供接入相关服务或与相关服务交互的替代方式。对于终端，“Access”片段提供有关终端接收和呈现服务所需的功能的信息。“Access”片段以内联文本的形式或者通过指向单独的会话描述的、以统一资源标识符(URI)形式的指针提供会话描述参数。会话描述信息可以通过广播信道或交互信道传送。

会话描述片段232可以包括在接入片段231中，并且可以以统一资源标识符形式提供位置信息，使得终端可以检测关于会话描述片段 232的信息。会话描述片段232可以提供关于会话中存在的多媒体内容的地址信息、编解码器的信息等。因此，“SessionDescription(会话描述)”是服务指南片段，其提供用于接入服务或内容项的会话信息。此外，会话描述可以提供用于相关联的传递过程的辅助描述信息。使用文本格式的会话描述协议(SDP)的语法或通过3GPP MBMS用户服务捆绑描述[3GPP TS 26.346](USBD)来提供会话描述信息。辅助描述信息以可扩展标记语言(XML)格式提供，并包含 [BCAST10-Distribution]中指定的关联传送描述。请注意，在使用SDP 语法的情况下，提供会话描述的替代方法是将SDP以文本格式封装在“Access”片段中。请注意，会话描述既可以用于服务指南传递本身，也可以用于内容会话。

购买项目片段211可以提供服务、内容、时间等的包，以帮助用户订阅或购买购买项目片段211。因此，“PurchaseItem”片段表示一组一个或多个服务(即，服务捆绑)或一个或多个内容项，其被免费提供给最终用户，用于订阅和/或购买。这个片段可以由“PurchaseData (购买数据)”片段引用，提供有关不同服务捆绑的更多信息。“PurchaseItem”片段还可以与以下相关联：(1)用于启用捆绑服务订阅的“Service”片段，和/或(2)用于使得能够在特定时间范围内消费特定服务或内容(按次计费功能)的“Schedule”片段，和/或(3) 用于使得能够购买与服务相关的单个内容文件的“Content”片段，(4) 实现购买项目的捆绑的其他“PurchaseItem”片段。

购买数据片段212可以包括针对服务或内容包的详细购买和订阅信息，诸如价格信息和促销信息。购买渠道片段213可以提供用于订阅或购买的接入信息。因此，“PurchaseData”片段的主要功能是表达关于相关购买项目的所有可用定价信息。“PurchaseData”片段收集有关一个或多个购买渠道的信息，并且可以与特定于某个服务或服务捆绑的PreviewData相关联。它承载有关服务定价、服务捆绑或内容项的信息。此外，有关促销活动的信息可能包含在此片段中。SGDD还可以提供关于用于接收服务指南的入口点的信息以及关于作为容器的 SGDU的分组信息。

预览数据片段241可用于提供服务、调度和内容的预览信息。因此，“PreviewData”片段包含终端用于向用户呈现服务或内容概要的信息，以便用户可以大致了解服务或内容所关于的内容。”PreviewData”片段可以包括简单文本、静态图像(例如，徽标)、短视频剪辑甚至可以是主服务的低比特率版本的另一服务的引用。“Service”、“Content”、“PurchaseData”、“Access”和“Schedule”片段可能会引用“PreviewData”片段。

交互数据片段251可用于在广播期间根据服务、调度和内容提供交互服务。可以通过系统的一个或多个元素和属性来定义关于服务指南的更详细信息。这样，InteractivityData(交互性数据)包含终端用于向用户提供与广播内容相关联的交互服务的信息。这些交互服务使用户能够例如在电视(TV)节目期间投票或获得与广播内容相关的内容。“InteractivityData”片段指向一个或多个“InteractivityMedia(交互性媒体)”文档，其包括xhtml文件、静态图像、电子邮件模板、短消息服务(SMS)模板、多媒体消息服务(MMS)模板文档等。“InteractivityData”片段可能引用“Service”、“Content”和“Schedule”片段，并且可以被“Schedule”片段引用。

“Schedule”片段定义了相关内容项可用于流式传输、下载和/或呈现的时间范围。该片段引用了“Service”片段。如果它还引用了一个或多个“Content”片段或“InteractivityData”片段，则它定义属于该服务的那些内容项的有效分发和/或呈现时间范围，或者与服务相关联的InteractivityMediaDocuments(交互性媒体文档)的有效分发时间范围和自动激活时间。另一方面，如果”Schedule”片段没有引用任何 (一个或多个)“Content”片段或(一个或多个)“InteractivityData”片段，那么它定义了无限制的服务可用性的时间帧。

“Content”片段给出特定内容项的详细说明。除了定义内容的类型、描述和语言之外，它还可以提供关于目标用户组或地理区域以及类型和父母评级的信息。“Content”片段可以由Schedule、PurchaseItem 或“InteractivityData”片段引用。它可能引用“PreviewData”片段或“Service”片段。

“PurchaseChannel(购买渠道)”片段携带关于实体的信息，如“PurchaseData”片段中所定义的，可以从该实体获得对特定服务、服务捆绑或内容项的接入和/或内容权限的购买。购买渠道与一个或多个广播订阅管理(BSM)相关联。如果终端附属于也与该购买渠道相关联的BSM，则仅允许终端接入特定购买渠道。多个购买渠道可以与一个”PurchaseData”片段相关联。某个最终用户可以拥有所有购买请求应该指向的“优选”购买渠道(例如，他或她的移动运营商)。首选购买渠道甚至可以是允许最终用户使用的唯一渠道。

ServiceGuideDeliveryDescriptor(服务指南传递描述符)在服务指南公告信道上传输，并在服务指南发现过程中向终端通知服务指南的片段的可用性、元数据和分组。SGDD允许快速识别在终端中缓存或正在传输的服务指南片段。因此，如果通过广播信道分布，则优选地重复SGDD。SGDD还提供相关服务指南片段的分组，因此提供用于确定该组的完整性的手段。如果终端从一个服务覆盖区域移动到另一个服务覆盖区域，ServiceGuideDeliveryDescriptor特别有用。在这种情况下，ServiceGuideDeliveryDescriptor可用于快速检查在先前服务覆盖区域中已经接收到的哪些服务指南片段在当前服务覆盖区域中仍然有效，因此不必重新被解析和重新处理。

尽管未明确描述，但构成服务指南的片段可包括用于实现其目的的元素和属性值。另外，根据需要，可以省略服务指南的一个或多个片段。此外，可以根据需要组合服务指南的一个或多个片段。而且，根据需要，服务指南的一个或多个片段的不同方面可以根据需要组合在一起、重新组织以及否则修改或进行约束。

参考图3，示例性框图示出了服务指南传递技术的各方面。服务指南传递描述符(SGDD)301可以包括与包含服务信息的所有片段相关的会话信息、分组信息、和通知消息接入信息。当启用移动广播服务的终端105开启或开始接收服务指南时，它可以接入服务指南公告信道(SG公告信道)300。

SG公告信道300可以包括SGDD 301中的至少一个(例如，SGDD #1、...、SGDD#2、SGDD#3)，其可以以诸如下述部分中所示的格式的任何合适的格式格式化：用于移动广播服务、开放移动联盟、版本1.1.1、2013年1月9日的服务指南；和/或用于移动广播服务、开放移动联盟、版本1.1、2013年10月29日的服务指南；这两篇文献都通过引用整体并入本文。构成服务指南传递描述符301的元素和属性的描述可以以任何合适的格式反映，诸如例如表格格式和/或XML模式。

优选地，根据SGDD片段301以XML格式提供实际数据。可以以诸如二进制的各种数据格式提供与服务指南有关的信息，其中取决于广播系统元素和属性被设置为相应的值。

终端105可以从在SG公告信道300上接收的SGDD片段的 DescriptorEntry(描述符输入项)获取包含片段信息的服务指南传递单元(SGDU)312的用信号发送信息。

DescriptorEntry 302可以提供服务指南的分组信息，包括“GroupingCriteria(分组准则)”、“ServiceGuideDeliveryUnit(服务指南传递单元)”、“Transport(传输)”和“AlternativeAccessURI (替选访问URI)”。与传输相关的信道信息可以由“Transport”或“AlternativeAccessURI”提供，并且相应信道的实际值由“ServiceGuideDeliveryUnit”提供。此外，关于SGDU 312的上层组信息——诸如“Service”和”Genre”——可以由“GroupingCriteria(分组准则)”提供。终端105可以根据相应的组信息接收并向用户呈现所有SGDU 312。

一旦获取了传输信息，终端105就可以在SG传递信道310上接入SGDD 301中的DescriptorEntry 302获取的所有传递信道，以接收实际的SGDU 312。可以使用“GroupingCriteria”来识别SG传递信道。在时间分组的情况下，可以利用诸如按小时SG信道311和按日SG信道的基于时间的传输信道来传输SGDU。因此，终端105可以选择性地接入信道并接收存在于相应信道上的所有SGDU。一旦在SG传递信道310上完全接收到整个SGDU，终端105就检查在SG传递信道310上接收的SGDU中包含的所有片段，并组合片段以在屏幕上显示可以按小时划分321的实际的完整服务指南(SG)320。

在传统的移动广播系统中，格式化并发送服务指南，使得仅配置的终端接收相应广播系统的广播信号。例如，DVB-H系统发送的服务指南信息只能由被配置为接收DVB-H广播的终端接收。

服务提供商根据服务汇聚(service convergence)使用各种传输系统以及各种广播系统提供捆绑和集成服务，其可以被称为多重播放服务。广播服务提供商还可以在IP网络上提供广播服务。可以使用3GPP 标准和OMA BCAST标准(例如，方案)中定义的实体的项来描述综合服务指南发送和/或接收系统。然而，服务指南传输和/或接收系统可以用于任何合适的通信和/或广播系统。

参考图4，该方案可以包括例如：(1)名称；(2)类型；(3) 类别；(4)基数；(5)描述；以及(6)数据类型。该方案可以以诸如表格格式或XML格式的任何方式安排。

“名称”列表示元素或属性的名称。“类型”列指示表示元素或属性的索引。元素可以是E1、E2、E3、E4、......、E[n]中的一个。E1 表示整个消息的上部元素，E2表示E1下方的元素，E3表示E2下方的元素，E4表示E3下方的元素，依此类推。属性由A表示。例如，E1 下方的“A”表示元素E1的属性。在某些情况下，符号可以表示以下： E＝元素，A＝属性，E1＝子元素，E2＝子元素的子元素，E[n]＝元素[n-1] 的子元素。“类别”列用于指示元素或属性是否必需。如果元素是必需的，则元素的类别标记为“M”。如果元素是可选的，则元素的类别将标记为“O”。如果该元素对于支持它的网络是可选的，则该元素将标记为“NO”。如果该元素对于支持它的终端是可选的，则该元素被标记为TM。如果该元素对于支持它的网络是必需的，则该元素标记为“NM”。如果该元素对于支持它的终端是可选的，则该元素标记为“TO”。如果元素或属性具有大于零的基数，则将其分类为M或NM 以保持一致性。“基数”列表示元素之间的关系，并被设置为值0、0......1、 1、0......n和1......n。0表示选项，1表示必要关系，n表示多个值。例如，0......n表示相应的元素可以没有值或具有n个值。“描述”列描述了相应元素或属性的含义，“数据类型”列指示相应元素或属性的数据类型。

服务可以表示内容捆绑，其形成对于最终用户的逻辑组。一个例子是由几个电视节目组成的电视信道。“Service”片段包含描述移动广播服务的元数据。有可能在与“Service”片段相关联的“Content”片段中存在相同的元数据(即，属性和元素)。在这种情况下，对于以下元素：“ParentalRating(家长评级)”、“TargetUserProfile(目标用户简档)”、“Genre”和“BroadcastArea(广播区域)”，“Content”片段中定义的值优先于”Service”片段中的值。

可以在片段中的节目指南开始和节目指南单元结束之间分组该片段的节目指南元素。节目指南的元素的这种定位降低了接收设备在安排节目指南时的计算复杂度。节目指南元素通常用于用户解释。这使得内容创建者能够提供关于服务的用户可读信息。终端应使用此片段中的所有已声明的节目指南元素，以便呈现给最终用户。终端可以提供搜索、排序等功能。节目指南可包括构成于以下服务要素：(1)Name (名称)；(2)Description(描述)；(3)AudioLanguage(音频语言)；(4)TextLanguage(文本语言)；(5)ParentalRating(家长评级)；(6)TargetUserProfile(目标用户简档)；(7)Genre(类型)。

“Name”元素可以指代服务的名称，可能是多种语言的。可以使用内置XML属性“xml:lang”表达该语言。

“Description”元素可以是多种语言的，可以使用内置的XML属性“xml:lang”表示。

“AudioLanguage”元素可以为终端用户声明该服务可用于与由该元素的值表示的语言相对应的音轨。可以以不同语言为终端用户提供此元素的文本值。在这种情况下，可以使用内置XML属性“xml:lang”来用信号发送用于表示该元素的值的语言，并且该语言可以包括多语言支持。AudioLanguage可能包含属性languageSDPTag(语言SDP标签)。

“languageSDPTag”属性是由如在描述会话描述中的音轨的媒体部分中所使用的“AudioLanguage(音频语言)”父元素描述的音频语言的标识符。声明相同音频流的每个“AudioLanguage”元素可以具有相同值的“languageSDPTag”。

“TextLanguage”元素可以为终端用户声明该服务的文本组件以该元素的值表示的语言可用。文本组件可以是例如字幕或子标题轨道。可以以不同语言为终端用户提供此元素的文本值。在这种情况下，可以使用内置XML属性“xml:lang”来用信号发送用于表示该元素的值的语言，并且该语言可以包括多语言支持。针对指配并解释属性“languageSDPTag”和“xml:lang”的元素“AudioLanguage”指定的相同规则和约束可以应用于此元素。

“languageSDPTag”属性是由如在描述会话描述中的文本轨道的媒体部分中所使用的“TextLanguage”父元素描述的文本语言的标识符。

“ParentalRating”元素可以声明家长准则，并且可以用于确定相关项目是否适合根据服务区域的监管要求来定义的儿童接入。终端可以支持“ParentalRating”是自由字符串，并且终端可以支持用于通过使用“ratingSystem(评级系统)”和“ratingValueName(评级值名称)”属性来表达家长评定等级的结构化方式。

“ratingSystem”属性可以指定使用中的家长评级系统，在该上下文中，“ParentalRating”元素的值在语义上定义。这允许终端以非模糊的方式识别使用中的评级系统并且适当地采取行动。当使用评级系统时，可以实例化该属性。缺少此属性意味着不使用评级系统(即，“ParentalRating”元素的值将被解释为自由字符串)。

“ratingValueName”属性可以指定此ParentalRating元素给出的评级值的人类可读名称。

“TargetUserProfile”可以指定服务所针对的用户的元素。详细的个人属性名称和相应的值由属性“attributeName(属性名称)”和“attributeValue(属性值)”指定。可能的简档属性名称包括年龄、性别、职业等(受制于国家和/或地方规则和/或法规，如果其存在且适用于个人简档信息和个人数据隐私的使用)。特定服务的“attributeName”和“attributeValue”对的可扩展列表使能终端用户简档过滤和广播服务的终端用户首选项过滤。终端可能能够支持“TargetUserProfile”元素。“TargetUserProfile”元素的使用可以是用户的“选择加入”能力。终端设置可以允许用户配置是否输入他们的个人简档或偏好以及是否允许基于用户的个人属性自动过滤广播服务而无需用户的请求。此元素可能包含以下属性：attributeName和attributeValue。

“attributeName”属性可以是简档属性名称。

“attributeValue”属性可以是简档属性值。

“Genre”元素可以指定与特征形式(例如，喜剧、戏剧)相关联的服务的分类。OMABCAST服务指南可能允许以两种方式描述服务指南中的Genre元素的格式。第一种方式是使用自由字符串。第二种方式是使用Genre元素的“href”属性以受控词汇表的形式传达信息([TVA-Metadata]中定义的分类方案或[Moving Image Genre-Form Guide(MIGFG)]中定义的分类列表)。内置的XML属性xml:lang可以用于此元素以表达语言。网络可以将其用作自由字符串或使用“href”属性实例化几组不同的“Genre”元素。网络可以确保不同的集合具有等同和非冲突的含义，并且终端可以选择其中一个集合来为最终用户解释。“Genre”元素可能包含以下属性：type和href。

“Genre”属性可以诸如使用“主”、“次”和“其他”的值用信号发送“Genre”元素的级别。

“href”属性可以用信号发送”Genre”元素中使用的受控词汇表。

在审查节目指南元素和属性集合；(1)Name(名称)；(2) Description(描述)；(3)AudioLanguage(音频语言)；(4)TextLanguage (文本语言)；(5)ParentalRating(家长评级)；(6)TargetUserProfile (目标用户简档)；(7)Genre(类型)之后，确定接收设备仍然可能在节目指南中定义的信息不足以以适合于观众的方式适当地呈现信息。特别是，传统的国家电视系统委员会(NTSC)电视台通常具有诸如2、4、6、8、12和49的数字。对于数字服务，节目和系统信息协议包括虚拟信道表，其对于地面广播定义具有由主要信道与其后的次要信道组成的两部分号码的每个数字电视服务。主要信道号码通常与电台的NTSC信道相同，次要信道的数量取决于数字电视多路中存在多少数字电视服务，通常从1开始。例如，模拟电视信道9华盛顿特区的WUSA-TV可以识别其两个无线(over-the-air)数字业务如下：9-1WUSA-DT信道和9-2 9-Radar信道。电视信道的这种表示法很容易被观众理解，并且节目指南元素可以包括这种能力作为节目指南的扩展，使得信息可以由接收设备计算有效地处理并呈现给观众。

参考图5，为了促进这种灵活性，诸如ServiceMediaExtension(服务媒体扩展)的扩展可以包括在可以指定其他服务的节目指南元素中。特别地，ServiceMediaExtension可以具有类型元素E1、类别NM/TM，具有1的基数。主要信道可以被称为MajorChannelNum(主要信道号码)，具有类型元素E2、类别NM/TM，0……1的基数以及字符串的数据类型。通过包含字符串的数据类型而不是unsignedByte(无符号字节)，允许支持其他语言，这些语言可能不一定是数字。包括 ServiceMediaExtension的节目指南信息可以包括在任何合适的广播系统中，诸如例如高级电视系统委员会(ATSC)广播系统。

在进一步审查节目节目编排指南元素和属性集合：(1)Name(名称)；(2)Description(描述)；(3)AudioLanguage(音频语言)； (4)TextLanguage(文本语言)；(5)ParentalRating(家长评级)； (6)TargetUserProfile(目标用户简档)；(7)Genre(类型)之后，确定接收设备仍然可能具有不足于适合于以适合于观看者的方式适当地呈现信息的信息。在许多情况下，观看者将图形图标与特定节目和/ 或信道和/或服务相关联。以这种方式，图形图标应该是系统可选择的，而不是不可选择的。

参考图6，为了便于这种灵活性，可以在编程指南元素中包括扩展，其可以指定图标。

在又进一步审查节目节目编排指南元素和属性集合：(1)Name (名称)；(2)Description(描述)；(3)AudioLanguage(音频语言)；(4)TextLanguage(文本语言)；(5)ParentalRating(家长评级)；(6)TargetUserProfile(目标用户简档)；(7)Genre(类型) 之后，确定接收设备仍然可能具有不足以适合以适合于观看者的方式适当地呈现信息的信息。在许多情况下，观看者可以寻求识别使用相同的扩展元素来识别的特定扩展。以这种方式，URL可以用于具体地标识扩展的元素的特定描述。以这种方式，可以以合适的方式修改扩展的元素，而不必明确地描述多个不同的扩展。

参考图7，为了便于这种灵活性，可以在编程指南元素中包括扩展，其可以指定URL。

参考图8，为了促进这种整体扩展灵活性，可以在节目指南元素中包括扩展，其可以指定图标、主要信道号、次要信道号和/或URL。

在其他实施例中，代替对MajorChannelNum(主要信道号码)和 MinorChannelNum(次要信道号码)元素使用数据类型“String(字符串)”，可以使用其他数据类型。例如，可以使用数据类型unsignedInt (无符号整型)。在另一个例子中，可以使用有限长度的字符串，例如，10位数的字符串。以下说明用于上述扩展的示例性XML模式语法。

在一些实施例中，ServiceMediaExtension可以包括在OMA “extension(扩展)”元素内，或者通常可以使用OMA扩展机制来定义ServiceMediaExtension(服务媒体扩展)。

在一些实施例中，MajorChannelNum和MinorChannelNum可以组合成一个公共信道号并被表示。例如，可以通过连接MajorChannelNum，然后连接句点(“.”)，然后连接MinorChannelNum来创建ChannelNum (信道号码)字符串。其他这样的组合也可以用其他字符替换句号。当使用unsignedInt或其他数据类型来表示将MajorChannelNum和MinorChannelNum组合成一个数字表示的信道号时，可以应用类似的概念。

在又一个实施例中，MajorChannelNum.MinorChannelNum可以表示为服务的“ServiceId”元素(服务Id)。

在另一个实施例中，ServiceMediaExtension可以仅在服务片段内的PrivateExt(私用扩展)元素内使用。下面说明用于这种扩展的示例性XML模式语法。

在其他实施例中，上述元素中的一些可以从E2改变为E1。在其他实施例中，可以改变一些元素的基数。另外，如果需要，可以省略类别，因为它通常与基数包括的信息重复。

期望将ATSC服务元素和属性的所选组件映射到OMA服务指南服务片段节目指南。例如，OMA服务指南片段节目指南的“Description”属性可以被映射到ATSC服务元素和属性的“Description”，诸如例如 ATSC-移动数字电视(DTV)标准，第4部分-公告、类似元素和属性的其他类似广播或移动标准。例如，OMA服务指南片段节目指南的“Genre”属性可以被映射到ATSC服务元素和属性的“Genre”，例如 ATSC-移动DTV标准，第4部分-公告、类似的元素和属性的其他类似标准。在一个实施例中，可以使用ATSC A153第4部分的第6.10.2节中定义的类型方案。例如，OMA服务指南片段节目指南的“Name(名称)”属性可以映射到ATSC服务元素和属性的“名称”。例如ATSC- 移动DTV标准，第4部分-公告、类似的元素和属性的其他类似标准。优选地，名称的基数被选择为0……N，这允许省略名称，这降低了系统的总比特率并增加了灵活性。例如，OMA服务指南片段节目指南的“ParentalRating(家长评级)”属性可以映射到ATSC服务元素和属性的新“ContentAdvisory(内容咨询)”，例如ATSC-移动DTV标准，第4部分-公告、类似的元素和属性的其他类似标准。例如，OMA服务指南片段节目指南的“TargetUserProfile(目标用户简档)”属性可以映射到ATSC服务元素和属性的新“Personalization(个性化)”，例如ATSC-移动DTV标准，第4部分-公告、类似的元素和属性的其他类似标准。

参见图9A、9B、9C，如果会话描述片段包括在服务公告中，则可以包括元素AudioLanguage(音频语言)(具有属性languageSDPTag (语言SDP标签))和TextLanguage(文本语言)(具有属性 languageSDPTag)，例如ATSC-移动DTV标准，第4部分-公告、类似的元素和属性的其他类似标准。这是因为元素AudioLanguage和 TextLanguage的属性languageSDPTag最好是强制性的。该属性提供由父元素描述的音频和/或文本语言的标识符，如在描述会话描述中的音频和/或文本轨道的媒体部分中使用的。在另一个实施例中，属性 languageSDPTag可以是可选的，并且元素AudioLanguage和 TextLanguage可以与提供语言名称的数据类型“string”的属性“Language(语言)”一起被包括。

此的示例的XML模式语法如下所示。

在另一个实施例中，可以移除元素AudioLanguage和TextLanguage 的属性languageSDPTag。此的示例的XML模式语法如下所示。

参见图10A、10B、10C，如果会话描述片段包括在服务通告中，则可以包括元素AudioLanguage(具有属性languageSDPTag)和 TextLanguage(具有属性languageSDPTag)，例如ATSC-Mobile DTV Standard，Part 4-Announcement，或类似元素和属性的类似标准。这是因为元素AudioLanguage和TextLanguage的属性languageSDPTag最好是强制性的。该属性提供由父元素描述的音频和/或文本语言的标识符，如在描述会话描述中的音频和/或文本轨道的媒体部分中使用的。在另一个实施例中，属性languageSDPTag可以是可选的。

此的示例的XML模式语法如下所示。

在另一个实施例中，属性“language(语言)”可以映射到ATSC 服务“language”元素，并且可以指代服务的主要语言。

在另一个实施例中，元素“AudioLanguage”的值可以映射到ATSC 服务“language”元素，并且可以指代ATSC中的音频服务的主要语言。

在另一个实施例中，元素“TextLanguage”的值可以映射到ATSC 服务“language”元素，并且可以指代ATSC中的文本服务的主要语言。在某些情况下，文本服务可以是诸如隐藏字幕服务之类的服务。在另一个实施例中，可以移除元素AudioLanguage和TextLanguage及其属性。

对于服务指南，传统上考虑的是引用视听内容的线性流，通常称为“线性服务(linear service)”。随着也被称为“app”的应用的激增，期望引用基于作为被执行的其他程序的app(即，基于应用)的服务，并向用户提供服务，通常称为“基于app的服务”。期望使用OMA服务指南片段节目指南的Notification ServiceType元素7来映射“线性服务”或“基于app的服务”的通知流。

还希望使用OMA服务指南片段节目指南的ServiceType元素来启用其他服务的通知。ServiceType可以使用“保留以用于专有用途”范围来包括其他服务类型。例如，ServiceType元素值224可以用于标识包括要使用的应用组件的“基于App的服务”。例如，ServiceType元素值225可以用于标识包括要使用的非实时内容的“基于App的服务”。例如，ServiceType元素值226可以用于标识包括要使用的按需组件的“基于App的服务”。以这种方式，这些基于app的服务被映射到 Notification ServiceType元素7，因此当Notification ServiceType元素7 不指示它们的存在时容易被省略，从而降低了比特流的复杂性。

在另一实施例中，代替将通知映射到OMA ServiceType的值7，而是可以定义附加的ServiceType值。OMA服务指南片段节目指南的 Notification ServiceType元素227可以用于标识“基于应用的服务”，其包括要使用的应用组件，包括通知流组件。

应该理解，其他值同样可以用于所描述的服务。例如，代替服务类型值224、225、226和227，可以使用服务类型值240、241、242、 243。在又一种情况下，可以替代地使用服务类型值129、130、131、 132。

在又一个实施例中，取代使用来自为专有用途保留的范围 (128-255)的ServiceType值，可以使用来自被保留供将来使用的范围 (11-127)的值。

在另一个实施例中，当使用OMA BCAST Guide 1.1取代使用保留以用于专有用途的范围(128-255)的ServiceType值时，可以使用来自被保留供将来使用的范围(14-127)的值。

在又一个实施例中，当使用OMA BCAST Guide 1.1取代使用保留用于专有用途的范围(128-255)的ServiceType值时，可以使用来自为其他OMA使能器保留的范围(128-223)的值。

在另一个实施例中，当使用OMA BCAST Guide 1.1取代使用保留用于专有用途的范围(128-255)的ServiceType值时，则可以在可以使用为其他OMA使能器保留的范围(224-255)内限制值。

在另一个实施例中，例如，附加的ServiceType元素值228可以用于标识“线性服务”。例如，附加的ServiceType元素值229可以用于标识“基于App的服务”，其包括基于通用应用的增强。以这种方式，通过不明确地包括应用组件、非实时内容、非按需组件的服务类型，来简化服务标签。

在另一个实施例中，例如，附加的或替代的ServiceType元素值 230可以用于标识包括基于应用的增强的“基于App的服务”。以这种方式，通过不明确地包括用于线性服务、应用组件、非实时内容、非按需组件的服务类型来进一步简化通知。

在另一个实施例中，例如，ServiceType元素值1也可以用于标识“线性服务”。以这种方式，线性元素被包含在现有语法结构内。在这种情况下，“线性服务”被映射到基本电视服务。

在另一个实施例中，例如，ServiceType元素值11可以用于标识按需流传输组件，其可以是具有包括按需组件的基于app的增强的基于app的服务。例如，ServiceType元素值12可以用于标识文件下载按需组件，其可以是包括非实时内容项组件的基于app的增强。

在另一个实施例中，上述服务类型值中的任何一个可以由另一个元素内的值指示。例如，AvailableContent(可用内容)元素或属性及其值可以采用来自应用组件、非实时内容、按需组件、和/或通知的值之一。

在另一个实施例中，可以分层地完成ServiceType值分配。例如，主要服务类型可以是线性服务和基于应用的服务，并且这两种类型的服务中的每一种可以包括零个或多个基于应用的增强组件，其可以包括应用组件、非实时内容、按需组件和/或通知，可以完成ServiceType 值的分层分配。在这种情况下，对于“ServiceType”，“unsigned Byte”(ServiceType的日期类型)中的一个位可用于传输线性服务(值设置为1的位)或基于应用的服务(值设置为0的位)。然后，其余的位可以传输服务类型。

一个示例被示出如下：

224(11100000二进制)具有包括应用组件的基于app的增强的线性服务

240(11110000二进制)具有包括应用组件的基于app的增强的基于app的服务

225(11100001二进制)具有包括非实时内容的基于app的增强的线性服务

241(11110001二进制)具有包括非实时内容的基于app的增强的基于app的服务

226(11100010二进制)具有包括按需组件的基于app的增强的线性服务

242(11110010二进制)具有包括按需组件的基于app的增强的基于app的服务

227(11100011二进制)具有包括通知流组件的基于app的增强的线性服务

243(11110011二进制)具有包括通知流组件的基于app的增强的基于app的服务

228(11100100二进制)具有通用服务类型的线性服务

243(11110100二进制)具有通用服务类型的基于app的服务

通用服务类型可以指代与具有应用组件或非实时内容或按需组件的服务不同的服务。在某些情况下，通用服务类型可以是“unknown (未知)”服务类型。

在又一个实施例中，值可以使用连续的ServiceType值。例如，可以按如下方式分配服务类型值：

224具有包括应用组件的基于app的增强的线性服务

225具有包括应用组件的基于app的增强的基于app的服务

226具有包括非实时内容的基于app的增强的线性服务

227具有包括非实时内容的基于app的增强的基于app的服务

228具有包括按需组件的基于app的增强的线性服务

229具有包括按需组件的基于app的增强的基于app的服务

230具有包括通知流组件的基于app的增强的线性服务

231具有包括通知流组件的基于app的增强的基于app的服务

在又一个实施例中，线性和/或基于App的服务：App可以进一步分为两种服务类型(即，总共四种服务类型)如下：

线性服务：主要app(例如，ServiceType值224)

线性服务：非主要app(例如，ServiceType值225)

基于app的服务：主要app(例如，ServiceType值234)

基于app的服务：非主要app(例如，ServiceType值235)

主要应用可以是一旦选择了基础服务就被激活的app。此外，非主要应用可能会在服务中稍后启动。

在一些实施例中，可以禁止服务类型线性服务：按需组件。在这种情况下，不能为该类型的服务分配ServiceType值。

与服务信令有关的附加实施例描述如下。通常，通用服务公告和服务信令可以如下。服务公告可以包括关于节目和被设计为允许观众或用户做出关于服务或内容的知情选择的服务的信息。服务信令可以包括使接收器能够定位和获取服务以及执行服务的基本导航的信息。

参考图11，描述了组件信息描述传输。传输服务提供商1100是被配置为使得能够提供电视服务的服务提供商的示例。例如，传输服务提供商1100可以包括公共空中电视网络、公共或基于订阅的卫星电视服务提供商网络、过顶服务网络、广播服务网络以及公共或基于订阅的有线电视提供商网络。应当注意，尽管在一些示例中，传输服务提供商1100可以主要用于使得能够提供电视服务，但是传输服务提供商1100还可以根据电信协议和这里描述的消息的任何组合来提供其他类型的数据和服务。传输服务提供商1100可以包括无线和/或有线通信媒体的任何组合。传输服务提供商1100可以包括同轴电缆、光纤电缆、双绞线电缆、无线发射器和接收器、路由器、交换机、中继器、基站\ 或可用于促进各种设备和站点之间的通信的任何其他设备。

参考图11，接收器1140可以包括被配置为从传输服务提供商1100 接收服务的任何设备。例如，接收器1140可以配备用于有线和/或无线通信，并且可以包括电视，包括所谓的智能电视、机顶盒。和数字视频录像机。此外，接收器1140可以包括台式计算机、膝上型计算机或平板计算机、游戏控制台、移动设备——包括例如智能手机、蜂窝电话、和被配置为从传输服务提供商1100接收服务的个人游戏设备。

作为从传输服务提供商1100接收服务的一部分，接收器1140可以接收信令信息，该信令信息可以提供关于可以通过传送机制接收的各种媒体流和数据的信息。在一个实施例中，来自传输服务提供商1100 的信令信息可以包括组件信息描述1110。稍后参考图13A、13B、15 和17提供组件信息描述的示例。在接收到该组件信息描述1110之后，接收器1140可以解析它或解码它。在一个示例中，接收器1140可能无法解析其他信令信息，直到其解析组件信息描述1110。在一个示例中，接收器1140可以在解码、解析和呈现组件信息描述1110中的一些或全部之后向观看者显示它。在某些情况下，可以在接收器设备的屏幕上显示该信息，观看者可以看到该信息。在示例情况下，观看者可以基于接收、解析和显示的该信息做出决定。在一个示例中，决定可以是接收服务的一个或多个组件。在这种情况下，接收器1140可以向传输服务提供商1100发送对于服务的一个或多个组件的组件传递请求1120。在一个示例中，接收器1140可以从传输服务1110接收所请求组件的传递。

参考图12，描述了信道信息描述信令。传输服务提供商1200是被配置为使得能够提供电视服务的服务提供商的示例。例如，传输服务提供商1200可以包括公共无线电视网络、公共或基于订阅的卫星电视服务提供商网络、过顶服务网络、广播服务网络以及公共或基于订阅的有线电视提供商网络。应当注意，尽管在一些示例中，传输服务提供商1200可以主要用于使得能够提供电视服务，但是传输服务提供商1200还可以根据电信协议和这里描述的消息的任何组合来提供其他类型的数据和服务。传输服务提供商1200可以包括无线和/或有线通信媒体的任何组合。传输服务提供商1200可以包括同轴电缆、光纤电缆、双绞线电缆、无线发射器和接收器、路由器、交换机、中继器、基站或可用于促进各种设备和站点之间的通信的任何其他设备。

参考图12，接收器1240可以包括被配置为从传输服务提供商1200 接收服务的任何设备。例如，接收器1240可以被配备用于有线和/或无线通信，并且可以包括电视，其包括所谓的智能电视、机顶盒和数字视频录像机。此外，接收器1240可以包括台式计算机、膝上型计算机或平板计算机、游戏控制台、移动设备——包括例如智能手机、蜂窝电话、和被配置为从传输服务提供商1200接收服务的个人游戏设备。

作为从传输服务提供商1200接收服务的一部分，接收器1240可以接收信令信息，该信令信息可以提供关于可以通过传送机制接收的各种媒体流和数据的信息。在一个实施例中，来自传输服务提供商1200 的信令信息可以包括信道信息描述1210。稍后参考图14A、14B、16 和18提供信道信息描述的示例。在接收到该信道信息描述1210之后，接收器1240可以解析它或解码它。在一个示例中，接收器1240可能无法解析其他信令信息，直到它解析信道信息描述1210。在一个示例中，接收器1240可以在解码、解析和呈现一些或全部信道信息描述1210 之后向观看者显示它。在某些情况下，可以在接收器设备1240的屏幕上显示该信息，观看者可以看到该信息。在示例情况下，观看者可以基于接收、解析和显示的该信息做出决定。在一个示例中，决定可以是接收服务的信道。在这种情况下，接收器1240可以将用于服务的信道传递请求1220发送到传输服务提供商1200。在一个示例中，接收器 1240可以从传输服务1200接收信道的传递。

图13A-13B示出了组件信息描述符的二进制语法。

与图13A相比，图13B包括更少的语法元素，因此，可以更容易地由传输服务提供商1100进行传输，并且可以更容易地由接收器1140 进行解析和解码。

图13A和图13B的组件信息描述符提供了关于服务中可用的组件的信息。这包括有关在服务中可用的组件数量的信息。对于每个可用组件，将用信号发送以下信息：组件类型、组件角色、组件名称、组件标识符、组件保护标志。可以用信号发送音频、视频、隐藏式字幕和应用组件。为音频、视频和隐藏式字幕组件定义组件角色值。

组件信息描述符的语法可以符合图13A或图13B中所示的语法。在另一个实施例中，代替所有组件信息描述符，其中的一些元素可以仅在组件信息描述符中或在某种其他描述符或某种其他数据结构内用信号发送。

图13A和图13B的组件信息描述符中的语法元素的语义含义可以如下。

descriptor_tag——这是用于标识此描述符的8比特无符号整型。可以用信号发送唯一地标识该描述符的0-255之间的任何合适的值。在一个实施例中，该字段的格式可以是uimsbf。在另一个实施例中，可以使用某种其他格式，其允许基于该descriptor_tag值标识唯一地与其他描述符相比较的描述符。

descriptor_length——这个8比特无符号整型可以指定紧跟在字段 num_components之后直到该描述符末尾的长度(以字节为单位)。在一些实施例中，代替8比特，该字段可以是16比特。

num_component——此8比特无符号整型字段可以指定此服务可用的组件数。该字段的值可以在1到127的范围内，包括1和127。值 128-255保留。在替代实施例中，该字段可以被分成两个单独的字段：7比特无符号整型字段num_components和1比特保留字段。

component_type——此3比特无符号整型可以指定服务中可用的此组件的组件类型。值0表示音频组件。值1表示视频组件。值2表示隐藏字幕组件。值3表示应用组件。值4到7保留。

component_role——此4比特无符号整型可以指定此组件的角色或种类。定义的值包括一个或多个：

对于音频组件(当上面的component_type字段等于0时)， component_role的值如下：

0＝完整主要

1＝音乐和效果

2＝对话

3＝评论

4＝视觉受损

5＝听觉受损

6＝画外音

7-14＝保留

15＝未知

在另一个实施例中，音频的附加component_role值可以如下定义： 7＝紧急，8＝卡拉OK。在这种情况下，将保留值9-14，并且将使用15 来表示未知音频角色。

对于视频(当上面的component_type字段等于1时)， component_role的值如下：

0＝主要视频

1＝替代相机视图

2＝其他替代视频组件

3＝符号语言插页

4＝随后的主题视频

5＝3D视频左视图

6＝3D视频右视图

7＝3D视频深度信息

8＝视频阵列的部分<n,m>的<x,y>

9＝随后主题元数据

10-14＝保留

15＝未知

对于隐藏字幕组件(当上面的component_type字段等于2时)， component_role的值如下：

1＝正常

2＝容易读取

2-14＝保留

15＝未知

当上面的component_type字段在3至7(包括3和7)之间时， component_role可以等于15。

component_protected_flag——该1比特标志指示该组件是否受保护(例如，未加密)。当该标志设置为值1时，该组件受到保护(例如，加密)。当该标志设置为值0时，该组件不受保护(例如，加密)。

component_id——此8比特无符号整型可以指定此服务中可用的此组件的组件标识符。component_id在服务中可以是唯一的。

component_name_length——此8比特无符号整型可以指定紧跟在此字段后面的component_name_bytes()字段的长度(以字节为单位)。

component_name_bytes()——以“English(英语)”语言的组件的简短人类可读名称。其每个字符可以按UTF-8编码。

参考图13A、图13B、图14A、图14B，描述符的格式列可以解释如下。

TBD：表示要如上所述被确定

uimsbf：表示无符号整型，最高有效位在先

bslbf：表示比特串，左位在先

图14A-14B示出了信道信息描述符的二进制语法。图14A和图14B 的信道描述符提供关于服务中的信道的信息。这包括主要信道号码、次要信道号码、主要信道语言、信道类型、信道描述(多种语言)、和信道图标。

信道描述符的语法可以符合图14A或图14B中所示的语法。在另一个实施例中，代替所有信道描述符，其中仅一些元素可以在信道描述符中或在某种其他描述符或某种其他数据结构内用信号发送。

图14A和图14B的信道描述符中的语法元素的语义含义如下。

descriptor_length——这个8比特无符号整型可以指定紧跟在该字段之后直到该描述符末尾的长度(以字节为单位)。

major_channel_num——这个16比特无符号整型可以指定服务的主要信道号。在另一个实施例中，8比特或12比特的位宽可以用于该字段，而不是16比特。

minor_channel_num——该16比特无符号整型可以指定在图14A 中所示的信道描述符的情况下服务的次要信道号。在另一个实施例中， 8比特或12比特的位宽可以用于该字段，而不是16比特。

在图14B中所示的信道描述符的情况下，位宽变为15比特。因此，对于图14B，该15比特无符号整型可以指定服务的次要信道号。在另一个实施例中，7比特或11比特的位宽可以用于该字段，而不是15比特。

service_lang_code——服务中使用的主要语言。该字段可以包括在 http：//www.iso.org可获得的国际标准组织(ISO)639-3，标题为“语言名称表示代码-第3部分：用于全面覆盖语言的Alpha-3代码”中的3 个字母代码之一，其全部内容通过引用并入本文。在其他实施例中，可以定义预定义的语言列表，并且该字段可以是这些字段的列表的索引。在替代实施例中，16比特可以用于该字段，因为可以表示的语言数量的上限是26×26×26，即，17576或17576-547＝17029。

service_lang_genre——服务的主要类型。可以实例化 service_lang_genre元素以描述服务的类型类别。 <classificationSchemeURI>是 http://www.atsc.org/XMLSchemas/mh/2009/1.0/genre-cs/， service_lang_genre的值可以与来自可从http://www.atsc.org获得的标题为“ATSC-Mobile DTV Standard，Part 4-Announcement”的A/153第4 部分的附录B中的分类方案中的termID值匹配，该文献通过引用整体并入本文。

icon_url_length——这个8比特无符号整型可以指定紧跟在该字段之后的icon_url_bytes()字段的长度(以字节为单位)。

icon_url_bytes()——用于表示此服务的图标的统一资源定位符 (URL)。每个字符可以按UTF-8编码。

service_descriptor_length——这个8比特无符号整型可以指定紧跟在该字段之后的service_descr_bytes()字段的长度(以字节为单位)。

service_descr_bytes()——服务的简短描述。以“English”语言或由此描述符中的service_lang_code字段的值标识的语言。每个字符可以按UTF-8编码。

icon_url_length和service_descriptor_length的值如 descriptor_length字段的值指定受约束，该字段提供关于整个描述符的长度的信息。

参考图14B，附加语法元素如下：

ext_channel_info_present_flag——这个1比特布尔标志，当设置为” 1”时，可以指示在此描述符中存在该服务的扩展通道信息字段，其包括字段service_lang_code、service_genre_code、service_descr_length、service_descr_bytes()、icon_url_length、icon_url_bytes()。值“0”可以指示在该描述符中不存在该服务的扩展信道信息字段，其包括字段service_lang_code、service_genre_code、service_descr_length、service_descr_bytes()、icon_url_length、icon_url_bytes()。

因此，当通过将ext_channel_info_present_flag值设置为1而使用图14B中所示的信道描述符时，可以在描述符中用信号发送比图14A 少的元素，因此可以更容易由传输服务提供商1200进行传输，并且可以更容易由接收器1240解析和解码。

在一些实施例中，可能需要比特流一致性，当信道信息描述符(例如，图14B)被包括在快速信息信道中时，则ext_channel_info_present_flag可以等于0。在另一实施例中，当信道信息描述符(例如，图14B)被包括用于在需要比特效率的位置中的信令时，则ext_channel_info_present_flag可以等于0。

在又一个实施例中，比特流一致性可能需要， ext_channel_info_present_flag可以等于1。

除了用于组件信息描述符的图13A或图13B的二进制语法之外，可以使用不同的表示。图15示出了组件信息描述符的XML语法和语义。图17示出了组件信息描述符的XML模式。

除了用于信道信息描述符的图14A或图14B的二进制语法之外，可以使用不同的表示。图16示出了用于信道信息描述符的XML语法和语义。图18示出了用于信道信息描述符的XML模式。

在一些示例中，快速信息信道可以替代地称为服务列表。下面针对服务列表描述了附加示例。为服务列表提供了有关各种XML模式和命名空间的描述。

服务列表提供有关通过宽带可用的广播和/或服务中的服务的信息。服务列表通过在广播流中包含有关每个服务的以下信息，支持快速信道扫描和服务获取：

-用于允许服务列表所需的信息，该服务列表对于观众有意义，并且可以支持经由信道号或上和/或下选择的初始服务选择。

-用于定位所列出的每个服务的服务层信令所需的信息。

服务列表可以组成于一个或多个部分。服务列表部分的比特流语法如图19中所示。

下面给出了图19中的字段的语义定义。

SLT——服务列表的根元素。

@bsid——整个广播流的标识符。bsid的值在区域级别(例如，北美洲)优选是唯一的。行政或监管机构可能在定义bsid方面发挥作用。

@sltCapabilities——解码和有意义地呈现此SLT实例中所有服务的内容所需的功能。

sltInetUrl——此元素描述了通过宽带获取此SLT中所有服务的电子服务指南(ESG)或服务级别信令文件的基本URL(如果有)。

@URLtype——sltInetUrl(ESG或信令或服务使用数据收集报告服务器)可用的文件类型。图21示出了为URLType定义的值。

Service——服务信息。

@serviceId——16比特整型，其可以在此广播区域范围内唯一标识此服务。

@sltSvcSeqNum——该整型优选地表示SLT服务信息的序列号，其服务标识符(ID)等于上面的serviceId属性。对于每个服务， sltSvcSeqNum值优选地从0开始，并且每当该服务元素的任何属性或子元素被改变时，优选地递增1。如果与具有serviceID的特定值的先前服务元素相比没有改变属性或子元素值，则优选地不递增 sltSvcSeqNum。sltSvcSeqNum字段在达到最大值后回绕到0。

@protected——设置为“true(真)”表示有意义呈现所需的一个或多个组件受到保护。设置为“false(假)”时，表示不保护服务有意义的呈现所需的组件。默认值为false。

@majorChannelNo——1到999范围内的整型，其优选代表服务的“主要”信道号。对于不打算由观众直接选择的服务——诸如ESG数据传送服务或紧急警报服务(EAS)富媒体传送服务——不需要此数。

@minorChannelNo——1到999范围内的整型，其最好代表服务的“次要”信道号。对于不打算由观众直接选择的服务——诸如ESG数据传送服务或EAS富媒体传送服务——不需要此数。

@serviceCategory——8比特整型，其表示此服务的类别。可以如图22所示进行编码该值。

@shortServiceName——服务的简称(最多7个字符)。对于不打算由观众直接选择的服务——诸如ESG数据传送服务或EAS富媒体传送服务——不需要此名称。

@hidden——当存在并设置为“true”时的布尔值优选地表示该服务旨在用于测试或专有用途，并且不旨在由普通TV接收器选择。不存在时，默认值为“false”。

@broadbandAccessRequired——布尔值，表示接收器需要进行宽带接入才能对服务进行有意义的呈现。默认值为false。

@svcCapabilities——解码并有意义地呈现服务ID等于上述 serviceId属性的服务的内容的所需的功能。

在许多情况下，期望通过下述方式来保证以某种方式可获得服务：诸如使用BroadcastSvcSignaling元素用信号发送关于服务的信息。以这种方式，当用信号发送BroadcastSvcSignaling元素时，该服务可通过诸如卫星广播或无线广播的广播接收对设备可用。以这种方式，当不存在BroadcastSvcSignaling时，则要求使用诸如因特网连接的宽带信令来获得服务信息和/或实际服务。这提供了一种确保适当服务可用性的有效机制。

BroadcastSvcSignaling——此元素及其属性提供广播信令相关信息。当BroadcastSignaling元素不存在时，优选地存在父服务元素的元素svcInetUrl(即Service.svcInetUrl元素)，并且svcInetUrl的属性 urlType(即Service.svcInetUrl@urlType属性)包括值1(到信令服务器的URL)，或者元素sltInetUrl作为SLT根元素的子元素(即 SLT.sltInetUrl元素)存在，其属性urlType(即SLT.sltInetUrl@urlType 属性)包括值1(到信令服务器的URL)并支持<service_id>path项，其中service_id对应于此BroadcastSvcSignaling元素的父服务元素的 serviceId属性(即Service@serviceId属性)。

期望确保有足够的属性信息可用于BroadcastSvcSignaling元素，以确保足够的和所有所需的服务信息可用于接入服务。为了确保有足够的服务信息可用，期望对于BroadcastSvcSignaling元素要求许多不同的属性；其提供广播信令信息，包括(1)协议类型；(2)主要版本号；(3)次要版本号；(4)表示物理层管道(PLP)标识符(ID)的整型；(5)包含因特网协议(IP)版本4(IPv4)目的地址的字符串； (6)分组的目的端口号；以及(7)包含IPv4源地址的字符串。以这种方式，以足以接入广播服务的方式提供这些所有相互关联的信息类型。

@slsProtocol——指示优选地如图23所示编码的该服务使用的服务层信令的协议类型的属性。

@slsMajorProtocolVersion——用于为此服务提供服务层信令的协议的主要版本号。默认值为1。

@SlsMinorProtocolVersion——用于为此服务提供服务层信令的协议的次要版本号。默认值为0。

@slsPlpId——整型，表示承载该服务的服务层信令的物理层管道的PLP标识符(ID)。

@slsDestinationIpAddress——包含承载此服务的服务层信令 (SLS)数据的分组的Internet协议(IP)版本4(IPv4)目标地址的字符串。

@slsDestinationUdpPort——承载此服务的服务层信令数据的分组的端口号。

@slsSourceIpAddress——包含承载此服务的服务层信令数据的分组的IPv4源地址的字符串。

在许多实施例中，期望包括使用不同URL来用信号发送不同类型的宽带服务器信息的能力。作为示例，对于相同服务，可能需要同时用信号发送信令服务器信息和服务使用数据收集报告服务器信息。通过对SvcInetUrl使用0..N的基数可以实现这种增加的灵活性。以这种方式，系统包括使用多于一种类型的URL的灵活性。

svcInetUrl——如果可用，经由宽带接入此服务的ESG或服务级别信令文件的基本URL。

@URLtype——svcInetUrl可用的文件类型。图21示出了用于此的示例性值。

下面提供关于信令元数据的宽带传送的进一步描述。

当存在sltInetSigUrl属性时，它可以用作基本URL来发出对于获取信令元数据的超文本传输协议(HTTP)请求。通过将路径项附加到基本URL来指示要返回的所需信令对象。在图24中定义了示例性路径项。从服务器的角度来看，这可以使信令对象的检索更有效，因为不需要服务器端应用来检索所需的对象。每次检索只提取一个文件。为了做出这样的请求，可以使用HTTP GET方法，并且附加到基本URL 末尾的路径包含指示所需的一个或多个信令对象的项，如图24所示。

当sltInetSigUrl基本URL出现在服务列表中时，service_id项用于指示所请求的信令元数据对象所应用到的服务。如果service_id项不存在，则请求该部分中的所有服务的信令元数据对象。

在图24中，“正常|diff|模板”项指示是否请求(一个或多个)元数据对象的正常形式、(一个或多个)元数据对象的diff形式、或(一个或多个)元数据对象的模板形式。如果需要正常形式，则可以省略正常项。

在图24中，“当前|下一个”项指示是否请求当前版本的元数据对象或在当前版本之后的下一版本的元数据对象。如果需要当前版本，则可以省略当前项。

在图24中，最后一行中示出的项用于指示期望哪种类型的元数据对象。在图26中列出支持的类型与其描述。

用于信令元数据对象的HTTP请求的URL的一些示例如下所示：

<sltIneSigUrl>/0x2107/RD——返回具有service_id 0x2107的服务的所有ROUTE/DASH信令对象的当前正常版本

<sltInetSigUrl>/0x2103/next/MPD——返回具有 service_id 0x2103的服务的中值呈现描述(MPD)的下一个正常版本

<sltInetSigUrl>/0x2104template/AST——返回具有service_id 0x2104的服务的应用信令表(AST)的当前模板版本

当(在服务级别)出现svcInetSigUrl时，可以使用相同的语义将相同的路径附加到其末尾，除了不显示任何服务项，因为不需要指定所需的服务。

那些HTTP请求的响应主体可以包括元数据包络，该元数据包络包含响应中包括的每个信令对象的项目元素。可以将零个或一个信令对象嵌入项目元素中。可以在它们的项目元素中引用未嵌入的任何信令对象，并且可以按照它们被引用的顺序将它们与元数据包络一起打包在多部分消息中。应该存在项目元素的validFrom和validUntil属性，以指示每个信令对象的有效性间隔。

可以通过添加在ATSC名称空间中定义的以下属性来扩展元数据包络的item元素：

<xs：attribute name＝"nextUrl"type＝"xs：anyURI"use＝"optional"/>

当存在时，由该属性给出的URL(“nextUrl”)可以是对于在项目元素中描述的信令对象的下一个计划的更新的URL。

因此，当validUntil时间接近通过宽带获取的信令对象时，设备可以通过使用由用于表示元数据包络中的信令对象的项目元素中的 nextURL属性给出的URL发出HTTP GET请求来获取对信令对象的下一个计划的更新。

如果对信令对象进行未计划的更新，则将发布动态事件以声明更新。然后，设备可以使用动态事件的数据属性中的URL来获取更新的信令对象。

当sltInetUrl元素作为SLT元素的子元素存在，并且其属性urlType 包含值2(到ESG服务器的URL)时，此sltInetUrl元素指定的URL 可用于经由宽带针对SLT中的所有服务检索ESG数据。

当对于服务存在svcInetEsgUrl属性svcInetUrl元素且其属性 urlType包含值2(到ESG服务器的URL)时，svcInetUrl元素指定的 URL可用于经由宽带针对作为其中出现此svcInetUrl元素的服务元素的具有相同service_id的服务检索ESG数据。在这种情况下，svcInetUrl 元素指定的URL用于在ATSC 3.0服务公告中指定的查询。

对于图19中所示的服务列表，对于元素sltInetUrl，属性urlType 被列为必需(而不是可选的)。对于每个服务，对于svcInetUrl元素，属性urlType是根据需要列出的(而不是可选的)。如果urlType属性对于这两个元素是可选的，则可能在服务列表级别或对于一个或多个服务发出URL信号，而不指示它是什么类型的URL。这将使得不清楚 URL所引用的服务类型(例如，信令服务器URL或ESG服务器URL 或服务使用数据收集报告服务器URL等)。因此，sltInetUrl的urlType 属性和每个svcInetUrl的urlType属性都是必需的。因此，它们的使用如图19所示为“1”。

SLT可以表示为包含SLT根元素的XML文档，该SLT根元素符合具有命名空间的XML模式中的定义：

http:∥www.atsc.org/XMLSchemas/ATSC3/Delivery/SLT/1.0/

和如图20A所示的模式。

如果单向传输实时对象传递(ROUTE)用户服务描述模式的任何元素出现在XML文档中，则缩写“slt”应该用作单向传输实时对象传递(ROUTE)用户服务描述模式的任何元素的名称空间前缀。对于本标准的初始版本，可以通过在XML文档的schema(模式)元素中包含以下属性来声明此前缀与命名空间的绑定。

xmlns：slt＝″http:∥www.atsc.org/XMLSchemas/ATSC3/Delivery/SLT/1.0/″

如上所述。图20A、20B示出了SLT的规范模式。该规范模式的结构如图20C所示。

下面描述服务列表的另一个示例。

ATSC 3.0服务可能具有多个射频(RF)信道中的组件。单个RF 信道中的这种服务的一组组件可以称为服务的“部分”。ATSC 3.0支持可从 http://atsc.org/wp-content/uploads/2016/10/A322-2016-Physical-Layer-Pro tocol.pdf获取并且其全部内容通过引用并入本文的ATSC标准物理层协议(A/322)中所述的信道绑定。在信道绑定中，单个PLP连接的数据分布在两个或更多个不同的RF信道上。当不使用信道绑定时，这样的服务可以仅具有单个RF信道中的一个部分，其可以足以用于有意义地呈现服务而不使用其他部分(尽管使用其他部分也可以提供更吸引人的呈现)。当使用信道绑定时，这种服务可以具有在至多两个RF信道(对应于用于信道绑定的频率)中的部分，这足以在不使用其他部分的情况下用于有意义地呈现服务(尽管使用其他部分也可以提供更吸引人的呈现)。这样的部分称为“必要”部分。每个服务部分可以包括在该部分所出现的RF信道的服务列表中。这些服务部分的多个列表可以都具有相同的服务ID值和主要/次要信道号的相同值。这使得多个RF信道中的多个服务部分能够在接收器执行信道扫描时被合并到接收器的信道映射中的单个服务中。用于这种服务的每个部分的SLT 条目还列出了其中可以找到其他部分的广播流的广播流标识符。如果服务包含一个(在没有信道绑定的情况下)或两个(在信道绑定的情况下)必要部分，这些在SLT中指示。如果在SLT中没有指示必要部分，则服务没有必要部分——即，接收器可以简单地从服务的MPD或 USBD确定要呈现哪些组件。

图26中示出了示例服务列表。服务列表中的元素和属性的描述可以如下所述。

以下文本指定在SLT中元素和属性的语义。

SLT——SLT的根元素。

@bsid——整个广播流的标识符。bsid的值在区域级别(例如，北美)可能是唯一的。行政或监管机构可以发挥作用。

@sltCapabilities——解码和有意义地呈现此SLT实例中所有服务的内容所需的功能。sltCapabilities属性的语法和语义可以遵循在 http://atsc.org/wp-content/uploads/2015/12/A332S33-159r6-Service-Anno uncement.pdf处可获得并且在此通过引用整体并入的ATSC 3.0服务声明规范A/332的内容片段下指定的sa：capabilities元素的语法和语义。

sltInetUrl——如果可用，经由宽带获取此SLT中所有服务的ESG 或服务层信令文件的基本URL。

@urlType——sltInetUrl(ESG或服务层信令)可用的文件类型。图27示出了urlType的可能代码值。

Service——服务信息。

@serviceId——可以在此广播区域范围内唯一标识此服务的16比特整型。

@sltSvcSeqNum——此整型可以指示服务ID等于上述serviceId属性的SLT服务信息的序列号。每个服务的sltSvcSeqNum值可以从0开始，并且每次更改此服务元素的任何属性或子元素时，sltSvcSeqNum 值可以递增1。如果与具有serviceID的特定值的先前服务元素相比没有更改属性或子元素值，则sltSvcSeqNum可能不会递增。sltSvcSeqNum 字段可在达到最大值后回绕到0。

@protected——设置为“true”表示有意义呈现所需的一个或多个组件受到保护。设置为“false”时，表示不保护有意义的服务呈现所需的组件。默认值为false。

@majorChannelNo——1到999范围内的整型，可表示服务的“主要”信道号。主要信道号的分配可以遵循A/65附件B中给出的指导原则，以保证ATSC 3.0广播的被许可人使用的两部分信道号组合将与具有重叠的DTV服务区的任何其他此类被许可人使用的信道号码组合不同。注意，在两者之间的等效编程的情况下，ATSC 3.0广播服务可以在DTV服务区内的ATSC A/53广播中使用相同的两部分信道号码组合。对于不旨在由观众直接选择的服务，诸如ESG数据传送服务或EAS 富媒体传送服务，不需要指定@majorChannelNo。

@minorChannelNo——1到999范围内的整型，其可以表示服务的“次要”信道号。对于不旨在由观众直接选择的服务，诸如ESG数据传送服务或EAS富媒体传送服务，不需要此号码。

@serviceCategory——8比特整型，其表示此服务的类别。可以根据图28对该值进行编码。

@shortServiceName——服务的简称(最多7个字符)。对于不旨在由观众直接选择的服务，诸如ESG数据传送服务或EAS富媒体传送服务，不需要此名称。

@hidden——布尔值，当存在并设置为“true”时可以表示该服务旨在用于测试或专有用途，并且不旨在由普通TV接收器选择。不存在时，默认值可以是“false”。

@broadbandAccessRequired——布尔值，其表示接收器需要进行宽带接入才能对服务进行有意义的呈现。默认值为false。

@svcCapabilities——解码并有意义地呈现服务ID等于上述 serviceId属性的服务的内容所需的功能。svcCapabilities元素的语法和语义可以遵循在http://atsc.org/wp-content/uploads/2015/12/A332S33-159r6-Service-Anno uncement.pdf上可获得并且在此整体通过引用并入的ATSC 3.0服务公告规范A/332的内容片段下指定的sa：capabilities元素的语法和语义。

@essential——当此服务不存在@type等于2的OtherBsid元素的实例时，此布尔属性可以不存在。

当针对该服务至少一个@type等于2的OtherBsid元素存在时，可以存在该布尔属性。

注意，当至少一个具有类型2的OtherBsid元素被用信号发送时，该约束确保可以存在具有0..1的基数的@essential。

当此属性存在并设置为“true”时，这表示由@serviceId属性标识的服务具有多个RF信道中的组件，并且该广播流中的该部分对于有意义的服务呈现是必不可少的。当存在并设置为“false”时，这表示由 @serviceId属性标识的服务具有多个RF信道中的分量，并且该广播流中的部分对于有意义的服务呈现不是必需的。此属性没有默认值。

在一个示例中，可能需要以下内容：

当使用可从 http://atsc.org/wp-content/uploads/2016/10/A322-2016-Physical-Layer-Pro tocol.pdf获得并且在此通过引用整体并入的ATSC 3.0标准A/322中描述的SNR信道绑定，并且Service@essebtial为false时，SLT@bsid的值可以等于此SLT中OtherBsid@essential为true且OtherBsid@type等于2的OtherBsid元素的值。

同样在另一个示例中，当使用可在 http://atsc.org/wp-content/uploads/2016/10/A322-2016-Physical-Layer-Pro tocol.pdf获得并且在这里通过引用被整体并入的ATSC 3.0标准A/322 中描述的普通信道绑定，并且Service@essebtial为false时，SLT@bsid 的值可以等于在此SLT中OtherBsid@essential为true且 OtherBsid@type等于2的OtherBsid元素的值。

同样在另一个示例中，当使用可在 http://atsc.org/wp-content/uploads/2016/10/A322-2016-Physical-Layer-Pro tocol.pdf获得并且在这里通过引用整体并入的ATSC 3.0标准A/322中描述的信道绑定，并且Service@essebtial为false时，SLT@bsid的值可以等于此SLT中OtherBsid@essential为true且OtherBsid@type等于2 的SLC中的OtherBsid元素的值。

BroadcastSvcSignaling——此元素及其属性提供广播信令相关信息。当BroadcastSvcSignaling子元素不存在时，则(a)服务元素的元素svcInetUrl(即Service.svcInetUrl元素)可以存在，其urlType属性 (即Service.svcInetUrl@urlType)值等于1(到SLS服务器的URL)，或(b)元素sltInetUrl可以作为SLT根元素的子元素(即SLT.sltInetUrl) 存在，其urlType属性(即SLT.sltInetUrl@urlType)值等于1(到信令服务器的URL)。在后一种情况下，sltInetUrl可以支持<service_id>路径项，其中service_id对应于服务元素的serviceId属性(即 Service@serviceId属性)。

@slsProtocol——指示由根据图29编码的该服务使用的服务层信令的传递协议的类型的属性。

@slsPlpId——整型，表示承载此服务的SLS的物理层管道的PLP ID。PLP ID可以如在可从 http://atsc.org/wp-content/uploads/2016/10/A322-2016-Physical-Layer-Pro tocol.pdf获得并且通过引用整体并入本文的ATSC标准A/322中规定。

@slsDestinationIpAddress——包含承载此服务的SLS数据的分组的点IPv4目标地址的字符串。

@slsDestinationUdpPort——承载此服务的SLS数据的分组的端口号。

@slsSourceIpAddress——包含承载此服务的SLS数据的数据包的点分IPv4源地址的字符串。

svcInetUrl——如果可用，通过宽带接入此服务的ESG或服务层信令文件的基本URL。

@urlType——svcInetUrl可用的文件类型。示例值如图27所示。

OtherBsid——包含此服务的副本或此服务的其他组件的广播流的标识符。

在一个示例中，可能需要以下内容：

OtherBsid值可以不等于父SLT元素的@bsid属性的值。

该约束确保OtherBsid元素仅仅用于指示在另一个广播流(并且不是与当前流相同的广播流)中的服务。

@type——当值设置为“1”时，这表示由OtherBsid标识的广播流是此服务的副本。当值设置为“2”时，这表示该服务元素表示服务的一部分，该服务具有由广播流标识符OtherBsid标识的广播流中的组件，并且服务标识符值等于父服务元素的@serviceId属性。

该描述允许接收器清楚地指示由OtherBsid值标识的其他广播流中的哪个服务包括用于服务的附加组件。

根据如图30所示编码的该属性的其他值未定义或保留供将来使用。

在一个示例中，可能要求：

当服务元素中存在多个OtherBsid元素时，所有这些元素的 OtherBsid@type可能相等。

此约束不允许重复和部分类型服务的混合。重复和部分类型服务的混合可导致显著的接收器解析和解码复杂性而没有实际益处。因此，不允许这种组合可以使接收器处理更简单。

@essential——当@type等于2时，此布尔值指示由OtherBsid标识的广播流中包含的部分对于与父服务元素的服务标识符@serviceId 属性以及此元素的父服务元素的父元素的广播流标识符@bsid对应的此服务的有意义呈现是否必不可少。值“true”表示它是必不可少的；值“false”表示它不是必需的。默认值为false。

在一个示例中，可能要求：

当父服务元素的Service@essential属性等于“false”时，@type 值等于2的其中一个OtherBsid元素可能具有等于“true”的 OtherBsid@essential属性值。

当父服务元素的@essential属性等于“true”时，OtherBsid@essential 属性值可能等于“false”。

这些约束确保并强制需要至多一个RF调谐器以用于有意义的服务呈现。这可以导致更简单和低复杂度的接收器能够有意义地呈现服务，而不需要多于一个调谐器来进行这种有意义的呈现。

当@type等于1时，该属性可能没有意义，因此可能不存在或者如果存在可能是false。

在一个示例中，OtherBsid元素的语义可以如下：

OtherBsid——此无符号短整型值列表的每个实例可以指示传递此服务的副本或部分的另一个广播流的标识符。OtherBsid的每个实例的格式可能与@bsid的格式相同。当@essential属性存在时，该元素可以存在并设置为“true”，当@essential属性不存在或@essential属性存在并设置为“false”时，它可能不存在。优选没有默认值。

然而，如上所定义的语义中存在限制。例如，当没有用信号发送 Service@essential属性时，这些语义排除了重复服务指示的用信号发送。为了在另一个例子中克服这个限制，OtherBsid元素的语义可以如下：

OtherBsid——此无符号短整型值列表的每个实例可以指示传递此服务的副本或部分的另一个广播流的标识符。OtherBsid的每个实例的格式可能与@bsid的格式相同。当@essential属性对于父服务元素存在并且设置为“true”时，可以存在至少一个OtherBsid元素。当@essential 属性对于父服务元素存在并且设置为“false”时，可以不存在OtherBsid元素。当对于父服务元素不存在@essential属性时，可以存在一个或多个OtherBsid元素。当OtherBsid元素不存在时，优选没有默认值。

在又一个示例中，OtherBsid元素的语义可以如下：

OtherBsid——此无符号短整型值列表的每个实例可以指示传递此服务的副本或部分的另一个广播流的标识符。OtherBsid的每个实例的格式可能与@bsid的格式相同。当@essential属性对于父服务元素存在并且设置为“true”时，可以存在至少一个OtherBsid元素。当@essential 属性对于父服务元素存在并且设置为“false”时，可以不存在OtherBsid元素。当对于父服务元素不存在@essential属性时，可以存在@type等于“1”的一个或多个OtherBsid元素。当OtherBsid元素不存在时，优选没有默认值。

用于OtherBsid元素的上述修改语义允许用信号发送由OtherBsid 元素指示的另一RF信道中的服务是该RF信道中的服务的副本的指示。因此，有兴趣获得当前服务的重复服务列表的接收器可以解析服务列表——即使它不包含Service@essential属性，并解码一个或多个包含的 OtherBsid元素并解码并找到具有等于“1”的值的OtherBsid@type属性，以便然后获得关于提供当前服务的副本的RF信道的信息。

虽然图13至图30示出了语法、语义和模式的特定实施例，但是附加变体是可能的。这些包括以下变化：

与上面所示的那些相比，可以将不同的数据类型用于元素。例如，可以使用unsignedShort数据类型而不是unsignedByte数据类型。在另一个示例中，可以使用字符串数据类型而不是无符号字节数据类型。

代替将语法作为属性用信号发送，可以将其作为元素用信号发送。代替将语法作为元素用信号发送，可以将其作为属性用信号发送。

可以改变各种字段的比特宽度，例如，代替在比特流语法中的元素的4比特，可以使用5比特或8比特或2比特。此处列出的实际值仅是示例。

代替XML格式和XML模式，可以使用Javascript Object Notation (JSON)格式和JSON模式。或者，可以使用逗号分隔值(CSV)、巴克斯-诺尔形式(BNF)、增强巴克斯-诺尔形式(ABNF)或扩展巴克斯-诺尔形式(EBNF)来用信号发送所提出的语法元素。

可以改变元素和/或属性的基数。例如，基数可以从“1”变为“1..N”，或者基数可以从“1”变为“0..N”，或者基数可以从“1”变为“0..1”，“或者基数可以从”0..1“变为”0..N“，或者基数可以从”0..N“变为”0..1“。

当上面显示为可选时，可以使元素和/或属性成为必需。当元素和 /或属性在上面显示为必需时，可以使元素和/或属性成为可选的。

可以改为将一些子元素用信号发送为父元素，或者可以将它们用信号发送为另一子元素的子元素。

所有上述变体都在本发明的范围内。

此外，在上述每个实施例中使用的基站设备和终端设备(视频解码器和视频编码器)的每个功能块或各种特征可以由电路实现或执行，该电路通常是一个集成电路或多个集成电路。设计用于执行本说明书中描述的功能的电路可以包括通用处理器、数字信号处理器(DSP)、专用或通用应用集成电路(ASIC)、现场可编程门阵列(FPGA)、或者其他可编程逻辑器件、离散门或晶体管逻辑、或分立硬件组件、或其组合。通用处理器可以是微处理器，或者，处理器可以是传统处理器、控制器、微控制器、或状态机。上述通用处理器或每个电路可以由数字电路配置，或者可以由模拟电路配置。此外，当由于半导体技术的进步而出现使得做出替代当前集成电路的集成电路的技术时，也能够使用通过该技术的集成电路。

应该理解，权利要求不限于上面说明的精确配置和组件。在不脱离权利要求的范围的情况下，可以对这里描述的系统、方法和装置的布置、操作和细节进行各种修改、改变和变化。

Claims

1.一种用于用信号发送与第一射频信道中的服务相关联的服务信息的方法，所述方法包括：

用信号发送与所述第一射频信道相关的服务列表；以及

用信号发送所述服务列表中的服务信息；以及

用信号发送与所述服务信息相关的必要信息，其中，所述必要信息是指示所述第一射频信道中的服务具有由第二射频信道传送的一个或多个部分的属性；以及

在所述属性为真的情况下，用信号发送所述服务信息中的至少一个其他广播服务标识OtherBSID元素，所述至少一个OtherBSID元素指示部分类型；以及

在所述属性为假的情况下，不用信号发送所述服务信息中的任何OtherBSID元素；以及

发送所述服务列表。

2.根据权利要求1所述的方法，其中，指示所述部分类型的所述至少一个OtherBSID元素是值等于2的类型属性。

3.一种用于呈现视频服务的设备，所述设备包括一个或多个处理器，所述一个或多个处理器被配置为：

接收第一射频信道；以及

接收所述第一射频信道中的第一服务列表；以及

解析所述第一服务列表以接收服务元素；以及

确定所述服务元素是否包括必要信息属性；以及

在存在所述必要信息属性的情况下，解析所述服务元素以确定所述必要信息属性的值；以及

在所述必要信息属性的值为真的情况下：

解析所述服务元素以接收一个或多个其他广播服务标识OtherBSID元素；以及

确定所述一个或多个OtherBSID元素中的每一个的类型；以及

在所述必要信息属性的值为假的情况下，不解析所述服务元素以接收一个或多个OtherBSID元素；以及

使用所述第一服务列表呈现所述视频服务。