CN109923869B - 发送用户服务捆绑描述的方法，及渲染视频服务的设备 - Google Patents

Abstract

一种用于生成、传输、提供和/或接收“用户服务捆绑描述”(图36A)、“内容咨询评级”(图36A)、“其他评级”(图36A)和“serviceDescrLang”(图36A)的系统。

Description

发送用户服务捆绑描述的方法，及渲染视频服务的设备

技术领域

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

背景技术

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

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

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

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

发明内容

本发明的一个实施例公开了一种用于用信号发送用户服务捆绑描述的方法，该方法包括：用信号发送与服务实例相关联的用户服务描述元素；以及，用信号发送内容咨询评级列表，其中，根据第一方法格式化内容咨询评级列表的每个元素；以及，用信号发送其他评级列表，其中，根据第二方法格式化其他评级列表的每个元素；以及传输用户服务捆绑描述。

本发明的一个实施例公开了一种用于渲染视频服务的设备，该设备包括一个或多个处理器，该一个或多个处理器被配置为：接收用户服务捆绑描述；并解析用户服务捆绑描述，以确定与视频服务相关联的用户服务描述元素；以及解析与视频服务相关联的用户服务描述元素，以接收内容咨询评级列表，其中，内容咨询评级列表的每个元素根据第一方法被格式化；以及，解析与视频服务相关联的用户服务描述元素，以接收其他评级列表，其中，根据第二方法格式化其他评级列表的每个元素；并且当内容咨询评级列表的元素和其他评级列表的元素满足条件时，渲染视频服务；并且，当内容咨询评级列表的元素和其他评级列表的元素不满足条件时，不渲染视频服务。

本发明的一个实施例公开了一种用于渲染视频服务的设备，该设备包括一个或多个处理器，该一个或多个处理器被配置为：接收用户服务捆绑描述；并解析用户服务捆绑描述，以确定与视频服务相关联的用户服务描述元素；以及解析与视频服务相关联的用户服务描述元素，以接收一个或多个服务描述元素，其中每个服务描述元素与以一种语言的服务描述相关联；并解析服务描述元素以确定是否存在服务描述语言(serviceDescrLang)属性；和

当确定服务描述语言(serviceDescrLang)属性是否存在为真时，接收服务描述语言(ServiceDescriptlang)属性，并将服务描述语言值设置为所接收的服务描述语言(ServiceDescriptlang)属性值；并且当确定服务描述语言(serviceDescrLang)属性是否存在为假时，将服务描述语言值设置为第一值；并且根据服务描述语言值来渲染视频服务。

附图说明

[图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示出了组件信息描述符的eXtensible Markup Language(可扩展标记语言，XML)语法和语义。

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

[图17]图17示出了组件信息描述符的XML方案。

[图18]图18示出了信道信息描述符的XML方案。

[图19A]图19A示出了用于MPEG媒体输送(MMT)的User Service BundleDescription(用户服务捆绑描述，USBD)片段。

[图19B]图19B示出了用于MPEG媒体输送(MMT)的User Service BundleDescription(USBD)片段。

[图19C]图19C示出了用于MPEG媒体输送(MMT)的User Service BundleDescription(USBD)片段。

[图20A]图20A示出了用于MMT USBD的XML方案。

[图20B]图20B示出了用于MMT USBD的XML方案。

[图20C]图20C示出了用于MMT USBD的XML方案。

[图21A]图21A示出了用于MMT USBD的XML方案的结构。

[图21B]图21B示出了用于MMT USBD的XML方案的结构。

[图21C]图21C示出了用于MMT USBD的XML方案的结构。

[图22A]图22A示出了用于MMT USBD的XML方案。

[图22B]图22B示出了用于MMT USBD的XML方案。

[图22C]图22C示出了用于MMT USBD的XML方案。

[图23A]图23A示出了用于单向输送实时对象传递(ROUTE)的 USBD片段。

[图23B]图23B示出了用于单向输送实时对象传递(ROUTE)的 USBD片段。

[图24]图24示出了ROUTE USBD的XML方案。

[图25]图25示出了Service-based Transport Session Instance Description(基于服务的输送会话实例描述)片段。

[图26]图26示出了SrcFlow元素。

[图27]图27示出了扩展文件传递表。

[图28]图28示出了RepairFlow(修复流)元素。

[图29]图29示出了受保护的对象捆绑。

[图30A]图30A示出了一个XML方案。

[图30B]图30B示出了一个XML方案。

[图30C]图30C示出了一个XML方案。

[图31]图31示出了SystemTime(系统时间)元素结构。

[图32]图32示出了SystemTime的XML方案。

[图33A]图33A示出了用于MMT的User Service Bundle Description(用户服务捆绑描述)片段。

[图33B]图33B示出了用于MMT的User Service Bundle Description片段。

[图34A]图34A示出了用于MMT的User Service Bundle Description片段。

[图34B]图34B示出了用于MMT的User Service Bundle Description片段。

[图35]图35示出了Associated Procedure Description Fragment(相关联的过程描述)片段。

[图36A]图36A示出了用于MPEG媒体输送(MMT)的示例User Service BundleDescription(用户服务捆绑描述，USBD)片段。

[图36B]图36B示出了用于MPEG媒体输送(MMT)的示例User Service BundleDescription(USBD)片段。

[图37]图37示出了示例非RRT内容咨询评级信息。

[图38A]图38A示出了用于MPEG媒体输送(MMT)的示例User Service BundleDescription(用户服务捆绑描述，USBD)片段。

[图38B]图38B示出了用于MPEG媒体输送(MMT)的示例User Service BundleDescription(USBD)片段。

[图39]图39示出了应用事件信息(AEI)的示例语法。

[图40]图40示出了应用事件信息的示例XML方案。

[图41]图41示出了“evti”框的示例语法。

具体实施例

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

通常，内容创建(Content Creation，CC)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可以通过广播信道传递移动广播服务，并且可以包括例如第三代项目合作伙伴关系(3rd Generation Project Partnership，3GPP)的多媒体广播多播服务(Multimedia Broadcast Multicast Service，MBMS)、第三代项目合作伙伴关系2(3rdGeneration Project Partnership 2，3GPP2)的广播多播服务 (Broadcast MulticastService，BCMCS)、数字视频广播(Digital Video Broadcasting，DVB)的手持数字视频广播(DVB-H)或基于互联网协议(IP)的广播通信网络。交互网络113提供交互信道，并且可以包括例如蜂窝网络。3GPP MBMS描述于技术标准(TS)“3GPP:TS 26.346V12.4.0(2014-12)”,“3rd Generation Partnership Project； Technical Specification Group Servicesand System Aspects； Multimedia Broadcast Multicast Service(MBMS)；Protocolsand codecs(Release 12)”(“3GPP:TS 26.346V12.4.0(2014-12)”，“第三代合作伙伴项目”；技术规范组服务和系统方面；多媒体广播多播服务(MBMS)；协议和编解码器(版本12)")，该技术标准以全文引用的方式并入到本文中。

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

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

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

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

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

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

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

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中示出的基数的含义如下：图2A中片段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可以包括ServiceGuideDeliveryDescriptor(服务指南传递描述符，SGDD)块201。供应组210可以包括购买项目块211、购买数据块212和购买渠道块213。核心组220可以包括服务块221、调度块222、和内容块223。访问组230可以包括访问块231和会话描述块 232。

除了这四个信息组管理组200、供应组210、核心组220和访问组 230之外，服务指南还可以包括预览数据241和交互性数据251。

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

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

Service(服务)片段221是广播服务中包括的内容的上层聚类，可以包括关于服务内容、风格、服务位置等的信息。一般来说，“Service”片段在总体水平上描述内容项，内容项包括广播服务。可以使用多种访问方式，例如广播信道和交互式信道，将服务传递给用户。该服务可以针对某个用户组或地理区域。根据服务的类型，它可能有(一个或多个)交互部分、(一个或多个)仅广播部分或两者兼有。此外，服务可以包括与内容不直接相关而是与诸如购买或订阅信息的服务功能直接相关的组件。作为服务指南的一部分，“Service(服务)”片段构成了由其他片段引用的中心枢纽，包括“Access(访问)”、“Schedule(调度)”、”Content(内容)”和”PurchaseItem(购买项目)”片段。除此之外，“Service”片段可以引用“PreviewData (预览数据)”片段。它无法供这些片段中各个参考或者可以供其中几个参考。与相关联的片段一起，终端可以在任何时间点确定与服务相关联的细节。这些细节可以被总结成用户友好的显示，例如，可以消费什么、如何消费以及何时消费相关联的内容以及以什么成本消费。

Access片段231可以提供访问相关信息，用于允许用户查看服务和传递方法、以及与相应的访问会话相关联的会话信息。因此，“Access”片段描述了在服务的寿命内如何访问服务。该片段包含或引用会话描述(Session Description)信息，并指示传递方法。一个或多个“Access”片段可以引用“Service”片段，提供访问相关服务或与相关服务交互的替代方式。对于终端来说，“Access(访问)”片段提供了关于终端需要什么能力来接收和渲染服务的信息。“Access”片段以内嵌文本的形式或者通过指向单独会话描述的统一资源标识符(Uniform Resource Identifier，URI)形式的指针提供会话描述参数。会话描述信息可以通过广播信道或交互信道传递。

会话描述片段232可以包括在Access片段231中，并且可以以 URI形式提供位置信息，使得终端可以检测关于会话描述片段232的信息。会话描述片段232可以提供关于会话中存在的多媒体内容的地址信息、编解码器信息等。因此，“Session Description(会话描述)”是一个Service Guide(服务指南)片段，它提供了访问服务或内容项的会话信息。此外，会话描述可以提供辅助描述信息，用于相关联的传递过程。会话描述信息是使用文本格式的会话描述协议(SDP)的语法或者通过第三代合作伙伴项目(3GPP)多媒体广播多播服务(MBMS)用户服务捆绑描述(User Service Bundle Description)来提供的。辅助描述信息以XML格式提供，并包含[BCAST10-Distribution]中规定的相关传递描述(AssociatedDelivery Description)。请注意，在使用 SDP语法的情况下，传递会话描述的另一种替代方法是将SDP以文本格式封装在“Access”片段中。请注意，会话描述既可用于服务指南(Service Guide)传递本身，也可用于内容会话。

购买项目(Purchase Item)片段211可以提供一套服务、内容、时间等，以帮助用户订阅或购买该购买项目(Purchase Item)片段 211。这样，“PurchaseItem(购买项目)”片段代表免费提供给终端用户用于订阅和/或购买的一个或多个服务(即服务捆绑)或一个或多个内容项的组。(一个或多个)“PurchaseData(购买数据)”片段可以引用此片段，提供关于不同服务捆绑的更多信息。“PurchaseItem(购买项目)”片段还可以与以下片段相关联:(1)能够进行捆绑服务订阅的“Service”片段和/或(2)能够在特定时间框架内消费特定服务或内容的“Schedule”片段(按次付费观看功能)和/或(3)能够购买与服务相关的单个内容文件的“Content”片段，(4)能够捆绑购买项目的其他“PurchaseItem”片段。

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

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

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

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

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

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

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

虽然没有明确描述，但是构成服务指南的片段可以包括实现它们的目的的元素和属性值。此外，根据需要，可以省略服务指南的片段中的一个或多个。此外，可以根据需要组合服务指南的一个或多个片段。此外，服务指南的一个或多个片段的不同方面可以根据需要组合在一起、重新组织、以其他方式修改或约束。

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

SG通告信道300可以包括SGDD 200中的至少一个(例如，SGDD #1，……，SGDD#2，SGDD#3)，其可以以任何合适的格式格式化，例如2013年1月9日1.0.1版的移动广播服务服务指南，开放移动联盟(Service Guide for Mobile Broadcast Services,Open MobileAlliance,Version 1.0.1,January 09,2013)和/或2013年10月29 日1.1版的移动广播服务服务指南，开放移动联盟(Service Guide for Mobile Broadcast Services,openMobile Alliance,Version 1.1, October 29,2013)；这二者都以全文引用的方式并入到本文中。构成服务指南传递描述符片段201的元素和属性的描述可以以任何合适的格式反映，例如表格格式和/或可扩展标记语言(XML)方案。

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

终端105可以从在SG通告信道300上接收的SGDD片段的 DescriptorEntry(描述符条目)中获取包含片段信息的服务指南传递单元(Service Guide Delivery Unit，SGDU)312的输送信息。

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

一旦获取了输送信息，终端105可以访问从服务指南(SG)传递信道310上的SGDD301中的DescriptorEntry302获取的传递信道，以接收实际的SGDU 312。可以使用“GroupingCriteria”来识别SG传递信道。在时间分组的情况下，SGDU可以用基于时间的输送信道来输送，例如每小时SG信道(Hourly SG Channel)311和每日SG信道(Daily SGChannel)。因此，终端105可以选择性地访问信道并接收存在于相应信道上的SGDU。一旦在SG传递信道310上完全接收到整个 SGDU，终端105检查包含在SG传递信道310上接收到的SGDU中的片段，并组装片段以在屏幕上显示实际的完整服务指南320，该指南可以每小时细分321。

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

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

参考图4，该方案可以包括，例如，(1)Name(名称)；(2)类型 (Type)；(3)类别(Category)；(4)基数(Cardinality)；(5)Description (描述)；和(6)数据类型(Datatype)。该方案可以以任何方式布置，例如，一种XML格式的表格格式。

“Name(名称)”列表示元素或属性的名称。“类型(type)”列表示表示元素或属性的索引。一个元素可以是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以保持一致性。“基数(cardinality)”列表示元素之间的关系，并设置为值0，0...1，1，0...n，和1... n。0表示选项，1表示必要的关系，n表示多个值。例如，0...n意味着相应的元素可以没有值或n值。“Description(描述)”列描述相应元素或属性的含义，“数据类型(data type)”列表示相应元素或属性的数据类型。

服务可以代表内容项目捆绑，其构成了终端用户的逻辑组。一个示例是由几个电视节目组成的电视(TV)信道。“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”元素可以声明家长准则(criteria parents)，并且可以用于确定相关联的项目是否适合于根据服务区域的监管要求定义的儿童访问。终端可以支持“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。

“type”属性可以表示“Genre”元素的级别，例如具有“main(主要)”、“second(第二)”和“other(其他)”的值.

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

在审查节目指南元素和属性集合：(1)Name(名称)；(2)Description (描述)；(3)AudioLanguage(音频语言)；(4)TextLanguage(文本语言)；(5)ParentalRating(家长评级)；(6)TargetUserProfile(目标用户简档)；以及(7)Genre(风格)之后，确定接收设备可能仍然没有足够的在节目指南中定义的信息来以适合观看者的方式适当地渲染信息。特别是，传统的国家电视系统委员会(National Television System Committee，NTSC)电视台通常有数字，诸如2、4、6、8、12和49。对于数字服务，节目和系统信息协议包括虚拟频道表，对于地面广播，该虚拟频道表用由主要频道和次要频道组成的两部分号码来定义每个数字电视服务。主要频道号通常与电视台的NTSC频道相同，次要信道号取决于数字电视倍数中有多少数字电视服务，通常从1开始。例如，模拟电视频道9，华盛顿特区的WUSA-TV，可以如下识别其两个空中数字服务：频道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可以被组合成一个公共频道号并被表示。例如，ChannelNum字符串可以通过连接MajorChannelNum后跟句点(‘.’)后跟MinorChannelNum来创建。用其他字符替换句点，其他这样的组合也是可能的。按照将MajorChannelNum和MinorChannelNum组合成一个号码表示，当使用unsignedInt或其他数据类型来表示信道号，类似的概念也适用。

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

在另一个示例中，ServiceMediaExtension只能在Service(服务) 片段中的PrivateExt(专用扩展)元素内使用。下面说明了这种扩展的示例性XML方案语法。

在其他示例中，上面的元素中的某些可以从E2改变为E1。在其他示例中，这些元素中的某些的基数可以改变。此外，如果需要，可以省略该类别，因为它通常与基数中包含的信息重复。

期望将高级电视系统小组委员会(Advanced Television SystemsSubcommittee，ATSC)服务元素和属性的选定组件映射到OMA服务指南服务片段节目指南。例如，OMA服务指南片段节目指南的“Description(描述)”属性可以被映射到ATSC服务元素和属性的“Description”，例如ATSC-移动数字电视(DTV)标准、第4部分-的通告(ATSC-Mobile Digital Television(DTV)Standard,Part 4- Announcement)、用于类似元素和属性其他类似广播或移动标准。例如，OMA服务指南片段节目指南的“Genre(风格)”属性可以映射到ATSC服务元素和属性的“Genre”，例如ATSC-移动DTV标准、第4部分-通告(ATSC-Mobile DTV Standard,Part 4- Announcement)、用于类似元素和属性的其他类似标准。在一个示例中，可以利用ATSC A153第4部分第6.10.2节(Section 6.10.2 of ATSC A153Part 4)中定义的风格方案。例如，OMA服务指南片段节目指南的“Name(名称)”属性可以映射到ATSC服务元素和属性的“Name(名称)”，例如ATSC-移动DTV标准、第4部分-通告(ATSCservice elements and attributes,such as for example ATSC-Mobile DTV Standard,Part 4-Announcement)、用于类似元素和属性的其他类似标准。优选地，名称的基数被选择为0..N，这允许省略名称，从而降低系统的总比特率并增加灵活性。例如，OMA 服务指南片段节目指南的“ParentalRating”属性可以被映射到ATSC 服务元素和属性的新“ContentAdvisory(内容咨询)”，例如ATSC- 移动DTV标准、第4部分-通告(ATSC-MobileDTV Standard,Part 4-Announcement)或用于类似元素和属性的类似标准。例如，OMA 服务指南片段节目指南的“TargetUserProfile(目标用户简档)”属性可以被映射到ATSC服务元素和属性的新“Personalization(个性化)”，例如ATSC-移动DTV标准、第4部分-通告(ATSC-Mobile DTV Standard,Part 4-Announcement)或用于类似元素和属性的类似标准。

参考图9A、9B、9C，如果会话描述片段包括在服务通告中，则可以包括AudioLanguage(具有属性languageSDPTag)和 TextLanguage(具有属性languageSDPTag)元素，例如ATSC-移动DTV 标准、第4部分-通告(ATSC-Mobile DTV Standard,Part 4-Announcement)，或用于类似元素和属性的类似标准。这是因为元素 AudioLanguage和TextLanguage的属性languageSDPTag优选地是强制性的。该属性提供由如在会话描述中描述音频和/或文本轨道的媒体部分中使用的父元素描述的音频语言和/或文本语言的标识符。在另一个示例中，属性languageSDPTag可以是可选的，并且元素AudioLanguage 和TextLanguage可以包括在具有可提供语言名称的数据类型“string(字符串)”的属性“Lagnuage(语言)”中。

下面显示了一个示例性的XML方案语法。

在另一个示例中，可以移除元素AudioLanguage和TextLanguage 的属性languageSDPTag。下面显示了一个示例性的XML方案语法。

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

下面显示了用于这点的示例XML方案语法。

在另一个示例中，可以移除元素AudioLanguage和TextLanguage 的属性languageSDPTag。下面显示了这点的示例XML方案语法。

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

在另一个示例中，元素“AudioLanguage(音频语言)”的值可以被映射到ATSC服务“Langugage”元素，并且可以指ATSC中音频服务的主要语言。

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

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

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

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

应当理解，其他值同样可以用于所描述的服务。例如，可以使用 Service Type元素值240、Service Type元素值241、Service Type元素值242、或Service Type元素值243代替上述Service Type＝元素值224、Service Type元素值225和Service Type元素值226和Service Type元素值227。在另一种情况下，可以替代地使用Service Type元素值129、Service Type元素值130、Service Type元素值131或Service Type元素值132。

在另一个示例中，代替使用保留给专有使用的范围(128-255)中的 ServiceType值，可以使用保留给将来使用的范围(11-127)中的值。

在另一个示例中，当使用OMA BCAST指南1.1时，代替使用保留给专有使用的范围(128-255)中的ServiceType值，可以使用保留给将来使用的范围(14-127)中的值。

在另一个示例中，当使用OMA BCAST指南1.1时，代替使用保留给专有使用的范围(128-255)中的ServiceType值，可以使用保留给其他OMA启用(OMA enabler)的范围(128-223)中的值。

在另一个示例中，当使用OMA BCAST指南1.1时，代替使用保留给专有使用的范围(128-255)中的ServiceType(服务类型)值，这些值可以被限制在保留给其他OMA启用器的范围(224-255)中。

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

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

例如，在另一个示例中，ServiceType元素值1也可以用于标识“线性服务”。以这种方式，Linear Element(线性元素)被合并到现有的语法结构中。在这种情况下，“线性服务”被映射到基本TV服务。

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

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

在另一个示例中，ServiceType值分配可以分层进行。例如，主要服务类型可以是线性服务和基于app的服务，这两种类型的服务中的每一种都可以包括零个或多个基于app的增强组件，这些增强组件可以包括应用组件、非实时内容、点播组件和/或通知，可以进行ServiceType 值的分层分配。在这种情况下，对于“ServiceType”，可以使用“无符号字节”(服务类型的日期类型)的位中的一个来表示线性服务(值设置为1的位)或基于app的服务(值设置为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的服务

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

在另一个示例中，这些值可以使用连续的ServiceType(服务类型) 值。例如，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)

其中，Primary App(主应用)可以是在选择基础服务后立即激活的app。此外，非主要app可能会在服务后期启动。

在一些示例中，线性服务:点播(Linear Service:On-Demand) 组件类型的服务可能被禁止。在这种情况下，不能为该服务类型分配 ServiceType值。

与服务信令相关的其他示例描述如下。一般服务通告和服务信令如下。服务通告(Service Announcement)可以包括关于节目和服务的信息，这些信息被设计成允许观看者或用户做出关于服务或内容的知情选择。服务信令可以包括使接收机能够定位和获取服务并执行服务的基本导航的信息。

参考图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之后向观看者显示组件信息描述1110的一些或全部。在某些情况下，它可以在接收机设备的屏幕上显示该信息，观看者可以看到该信息。在示例情况下，观看者可以基于接收、解析和显示的该信息做出决定。在一个示例中，决定可以是接收服务的一个或多个组件。在这种情况下，接收机1140可以向传输服务提供商1100发送针对服务的一个或多个组件的组件传递请求1120。在一个示例中，接收机1140 可以从传输服务提供商1100接收所请求的组件的传递。

参考图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 之后向观看者显示信道信息描述1210的一些或全部。在某些情况下，它可以在接收机设备1240的屏幕上显示该信息，观看者可以观看该信息。在示例情况下，观看者可以基于接收、解析和显示的该信息做出决定。在一个示例中，决定可以是接收服务的信道。在这种情况下，接收机1240可以向传输服务提供商1200发送服务的信道传递请求 1220。在一个示例中，接收机1240可以从传输服务提供商1200接收信道的传递。

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

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

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

Component Information Descriptor(组件信息描述符)的语法可以符合图13A或图13B所示的语法。在另一个示例中，可以在组件信息描述符中或者在一些其他描述符或一些其他数据结构中用信号发送组件信息描述符中的仅一些元素而不是所有组件信息描述符。

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

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

descriptor_length-这个8比特无符号整数可以规定紧跟在 num_components字段之后直到描述符末尾的长度(以字节为单位)。在一些示例中，该字段可以是16比特，而不是8比特。

num_components-此8比特无符号整数字段可以规定此服务可用的组件数量。该字段的值可以在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的值如下：

0＝正常

1＝简易阅读器

2-14＝r保留

15＝未知

当上述componet_type字段在3至7(含)之间，compont_role 可以等于15。

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

component_id-这个8比特无符号整数可以规定这个服务中可用的该组件的组件标识符。组件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的信道描述符提供了关于服务中的(一个或多个)信道的信息。这包括主要信道号、次要信道号、主要信道语言、信道风格、信道描述(多种语言)和信道图标。

Channel Descriptor(信道描述符)的语法可以符合图14A或图 14B所示的语法。在另一个示例中，并非所有的信道描述符，而是只有其中的元素中的一些元素可以在信道描述符中或者在一些其他描述符或者一些其他数据结构中被用信号发送。

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

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

descriptor_length-这个8比特无符号整数可以规定紧接在这个字段之后直到这个描述符末尾的长度(以字节为单位)。

major_channel_num-这个16比特无符号整数可以规定服务的主要信道号。在另一个示例中，代替16比特，8比特或12比特的位宽可以用于该字段。

minor_channel_num-在图14A所示的信道描述符的情况下，这个 16比特无符号整数可以规定服务的次要信道号。在另一个示例中，代替16比特，8比特或12比特的位宽可以用于该字段。

在图14B所示的信道描述符的情况下，位宽被改变为15比特。因此，对于图14B，这个15比特无符号整数可以规定服务的次要信道号。在另一个示例中，代替15比特，7比特或11比特的位宽可以用于该字段。

service_lang_code-服务中使用的主要语言。这个字段可包括在标题为“Codesfor the representation of names of languages-Part 3: Alpha-3 code forcomprehensive coverage of languages(语言名称表示代码-第3部分:语言综合覆盖的α-3代码)”的国际标准组织(ISO) ISO 639-3中的3个字母代码之一组成，ISO 639-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(ATSC-移动数字电视标准，第4部分-通告)”A/153第4部分文档的附录B的分类方案中的termID值相匹配，该附录以全文引用的方式并入到本文中。

icon_url_length-这个8比特无符号整数可以规定紧跟着这个字段的icon_url_bytes()字段的长度(以字节为单位)。

icon_url_bytes()-用于表示此服务的图标的URL。每个字符可以按照UnicodeTransmission Format(Unicode传输格式，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位布尔 (Boolean)标志可以表示在该描述符中存在该服务的扩展信道信息字段，包括字段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值设置为比图 14A少1个元素来使用图14B所示的信道描述符时，可以在描述符中用信号发送，并且因此传输服务提供商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方案和命名空间的描述。MMT的用户服务捆绑描述(UserService Bundle Description)的XML方案也在下面描述。User Service BundleDescription(用户服务捆绑描述)提供用于访问服务的信令信息。

图19A-19C示出了用于运动图像专家组(Motion Picture Experts Group，MPEG)媒体输送的示例User Service Bundle Description(用户服务捆绑描述)片段。图19A-19C示出了各种元素及其语义定义。User Service Bundle Description(用户服务捆绑描述)形成ATSC信令的一部分。

参考图19A-19C，内容传递包括两个选项，用于支持通过ATSC 广播物理层的流式传输和/或文件下载:(1)通过用户数据报协议(User Datagram Protocol，UDP)和互联网协议(Internet Protocol，IP)的 MPEG媒体输送协议(MPEG Media Transport Protocol，MMTP)和 (2)通过UDP和IP的单向输送实时对象传递(Real-time Object delivery overUnidirectional Transport)。MMTP描述于ISO/IEC: ISO/IEC 23008-1，“Informationtechnology-High efficiency coding and media delivery in heterogeneousenvironments-Part 1: MPEG media transport(MMT)(信息技术-异构环境中的高效编码和媒体传递-第1部分:MPEG媒体输送(MMT))”，该文以全文引用的方式并入到本文中。在MMTP用于流式传输视频数据的情况下，视频数据可以封装在媒体处理单元(MPU)中。MMTP将MPU定义为“独立于其他MPU，可由MMT实体处理并且由演示引擎消费的媒体数据项目”。MPU的逻辑分组可以形成MMT资产，其中MMTP将资产定义为“用于构建多媒体演示的任何多媒体数据。资产是共享相同资产标识符以携带编码媒体数据的MPU的逻辑分组”。一个或多个资产可以形成MMT包，其中MMT包是多媒体内容的逻辑集合。MMT包表(MMT Package Table，MPT)，也称为MP表(MP Table)，是ISO/IEC 23008-1如下定义的消息“该消息类型包含MP(MPT消息)表，MP (MPT消息)表提供单个包消费所需的全部或部分信息”。这也称为 MP表消息。

关于图19A-19C，物理层管道(PLP)通常可以指包括数据流的全部或部分的逻辑结构。在一个示例中，物理层帧的有效载荷中包括PLP。

A/331候选标准(Candidate Standard)(A/331)可在以下网站获得: http://atsc.org/wp-content/uploads/2016/01/A331S33-174r5-Signal ing-Delivery-Sync-FEC.pdf，该标准以全文引用的方式并入到本文中，描述了ATSC 3.0信令、传递、同步和错误保护。

在MMT的A/331中，可以根据评级区域表(Rating Region Table，RRT)为评级系统发出内容咨询评级信号。评级区域表(Rating Region Table)描述于A/331附件F中。然而，并非世界上所有地区都可以使用基于RRT的内容咨询评级系统。当使用MMT时，A/331不支持基于非RRT的内容咨询评级信令。

图36描述了服务通告中针对非评级区域表(非RRT)相关评级的附加评级信息的信令。

图36中的信令允许同时包括基于RRT和基于非RRT的评级。

图36中的信令支持为服务和/或内容发送附加的基于非RRT的评级的信号。

定义约束是为了确保具有相同评级模式的多个附加评级不会发出可能导致错误的信号。

图36示出了用于MPEG媒体输送的用户服务捆绑描述片段的另一个示例，包括对基于RRT和基于非RRT的内容咨询评级信令的支持。图36中示出了各种元素和属性。用户服务捆绑描述构成ATSC信令的一部分。

图36中各种元素和属性的语义可以如下:

顶层或入口点SLS片段是USBD片段。USBD的元素中的一些元素包括以下内容:

元素userServiceDescription(用户服务描述)下的子属性serviceId 和serviceStatus；

元素userServiceDescription下的子元素contentAdvisoryRating(内容咨询评级)和OtherRatings(其他评级)；

元素userServiceDescription下的子元素Channel(信道)及其子属性serviceGenre(服务风格)、serviceIcon(服务图标)和子元素 ServiceDescription(服务描述)及其子属性serviceDescrTex、 serviceDescrLang；

元素userServiceDescription下的子元素mpuComponent及其子属性mmtPackageID和nextMMTPackageID、contendIdschemdIdUri、 contentIdvalue、nextMmtPackageId、nextContentIdSchemeIdUri和 nextContentIdValue；

元素userServiceDescription下的子元素routeComponent及其子属性sTSIDUri、apdURI sTSIDDestinationIpAddress、 sTSIDDestinationUdpPort、sTSIDSourceIPAddress、 sTSIDMajorProtocolVersion、sTSIDMinorProtocolVersion，作为服务信令数据，支持经由路由(ROUTE)协议传递本地缓存的服务内容；

元素userServiceDescription下的broadbandComponent及其子属性fullMPDUri；和

元素userServiceDescription下的子元素ComponentInfo及其子属性componentType、componentRole、componentProtectedFlag、 componentId、componentName。

建议在服务通告中携带相同的信息时，不要在MMT USBD中重复该相同的信息。在这种情况下，服务通告中的信息应该优先。

bundleDescriptionMMT可以表示为包含bundleDescription MMT根元素的XML文档，该根元素符合具有以下命名空间的XML 方案中的定义：

http://www.stsc.org/XMLSchemas/ATSC3/Delivery/MMTUSD/1.0/

这些方案的定义在方案文件中。

上面标识的XML方案规定了此ATSC 3.0标准中规定的元素的规范语法。

与包含这些文件的片段相对应的媒体类型可以按照A/331附件 H.3中的所规定。

以下文本规定了MMT用户服务描述中元素和属性的语义。

bundleDescriptionMMT-MMT的User Service Bundle Description 的根元素。

userServiceDescription(用户服务描述)-ATSC 3.0服务的单个实例。

@globalServiceID-可以标识ATSC 3.0服务的全球唯一URI。此参数用于链接到ESG数据(Service@globalServiceID)。

@serviceId-引用LLS(SLT)中相应的服务条目。此属性的值与分配给服务条目的serviceId的值相同。

@serviceStatus-布尔属性，它可以将此服务的当前状态表示为活动或非活动。值“1”或“true(真)”可以指示服务处于活动状态。值“0”或“false(假)”可以指示服务不活动。默认值可以是“1”或“true(真)”。

Name-ATSC 3.0服务的名称，使用@lang属性规定的语言。

@lang-ATSC 3.0服务名称的语言。该语言可根据在 https://tools.ietf.org/html/bcp47定义的BCP 47进行规定，该文以全文引用的方式并入到本文中。

serviceLanguage-ATSC 3.0服务的可用语言。该语言可根据在 https://tools.ietf.org/html/bcp47定义的BCP 47进行规定，该文以全文引用的方式并入到本文中。

contentAdvisoryRating-规定内容咨询评级，如ATSC3.0服务通告规范A/332(A/332)中所定义，该规范可在以下网站获得: http://atsc.org/wp-content/uploads/2015/12/A332S33-159r6-Servic e-Announcement.pdf，该文以全文引用的方式并入到本文中。该元素的格式可以与ATSC 3.0服务通告规范A/332(A/332)的服务片段中规定的ContentAdvisoryRating元素相同，该规范可在以下网站获得: http://atsc.org/wp-content/uploads/2015/12/A332S33-159r6-Servic e-Announcement.pdf，该文以全文引用的方式并入到本文中。

OtherRatings-规定非RRT内容咨询评级，如ATSC3.0服务通告规范A/332(A/332)中所定义，该规范可在以下网站获得: http://atsc.org/wp-content/uploads/2015/12/A332S33-159r6-Servic e-Announcement.pdf，该规范以全文引用的方式并入到本文中。该元素的格式可以与ATSC 3.0服务通告规范A/332(A/332)的服务片段中规定的OtherRatings元素相同，该规范可在以下网址获得: http://atsc.org/wp-content/uploads/2015/12/A332S33-159r6-Servic e-Announcement.pdf，该文以全文引用的方式并入到本文中。每个 OtherRatings元素可以有一个唯一的@ratingScheme值。

Channel-这个元素包含关于服务的信息。

@serviceGenre-该属性指示服务的主要风格。可以实例化该属性来描述服务的风格类别。<classificationSchemeURI>是http://www.atsc.org/XMLSchemas/mh/2009/1.0/ genre-cs/

@serviceIcon-该属性指示用于表示该服务的图标的统一资源定位符(UniformResource Locator，URL)。

ServiceDescription-可以包含多种语言的服务描述。

@serviceDescrText-该属性指示服务的描述。

@serviceDescrLang-该属性指示serviceDescrText的语言。可以遵循xs:lang的语义。

mpuComponent-关于作为MPU传递的ATSC 3.0服务的内容组件的描述。

@mmtPackageId-作为MPU传递的ATSC 3.0服务的内容组件的 MMT包。

@contentIdschemeIdUri-该属性可以指示用来标识与当前MMT包相关联的内容ID的方案的URI。@contentIdValue属性的语义特定于该属性规定的方案。允许的值是:

用于EIDR Content ID的urn:eidr；

用于Ad-ID Content ID的tag:atsc.org,2016:cid:adid；

用于用户私有Content ID系统的 tag:atsc.org,2016:cid:x-<abbrev>，其中<abbev>是content ID系统的合适缩写。

实验性或专有的Content ID系统可以通过用实验性或专有的 Content ID系统的形式“x-<abbrev>”的名称替换Ad-ID Content ID 的contentIdSchemeIdUri中的“adid”来支持，其中<abbev>是Content ID系统的合适缩写。执行此操作时，应注意所使用的<abbrev>不要与相同服务的任何其他实验性或专有Content ID系统重复。用户私有 Content ID系统可以是例如房屋号码或广播公司使用的一些其他标识符系统。

@contentIdvalue-该属性可以根据@contentIdSchemeIdUri属性标识的ContentID系统规定与当前MMT包相关联的Content ID的值。“EIDR Content ID”可以是在娱乐标识符注册中心注册的EIDR ID 的典型形式。(参见eidr.org网站)。“Ad-ID Content ID”可以是在由美国广告代理协会和全国广告客户协会开发的Ad-ID系统中注册的 Ad-ID代码。(参见www.ad-id.org网站。)

@nextMmtPackageId-引用MMT包，该MMT包在时间上位于在 @mmtPackageId引用的包之后，用于作为MPU传递的ATSC 3.0服务的内容组件。

@nextContentIdschemeIdUri-该属性可以指示用来标识与下一个 MMT包相关联的Content ID的方案的URI。@nextContentIdValue属性的语义特定于该属性规定的方案。允许的值是:

用于EIDR Content ID的urn:eidr；

用于Ad-ID Content ID的tag:atsc.org,2016:cid:adid；

用于用户私有Content ID系统的 tag:atsc.org,2016:cid:x-<abbrev>，其中<abbrev>是Content ID系统的合适缩写。

实验性或专有Content ID系统可以通过用实验性或专有Content ID系统的形式“x-<abbrev>”的名称替换Ad-ID Content ID的 nextContentIdSchemeIdUri中的“adid”来支持，其中<abbev>是 Content ID系统的合适缩写。执行此操作时，应注意所使用的<abbrev> 不要与相同服务的任何其他实验性或专有Content ID系统重复。用户私有Content ID系统可以是例如房屋号码或广播公司使用的一些其他标识符系统。

@nextContentIdvalue-该属性可以根据 @nextContentIdSchemeIdUri属性标识的Content ID系统规定与下一个包相关联的Content ID的值。“EIDR Content ID”可以是在娱乐标识符注册中心(Entertainment Identifier Registry)注册的EIDR ID 的典型形式。(参见eidr.org网站)。“Ad-ID Content ID”可以是在由美国广告代理协会和全国广告客户协会开发的Ad-ID系统中注册的 Ad-ID代码。(参见www.ad-id.org网站。)

routeComponent-关于ROUTE传递的ATSC 3.0服务内容组件的描述。

@sTSIDUri-引用在A/331中定义的S-TSID片段，该片段为携带本ATSC 3.0服务内容的输送会话提供服务访问相关参数。

@apdURI-该可选属性可以提供对APD片段的引用，APD片段为 ROUTE传递的ATSC3.0服务的内容组件提供文件修复相关信息。该属性指向如A/331中所描述的APD片段。

当@apdURI存在时，至少一个Alternate-Content-Location-1(替代-内容-位置1)元素可以存在于由routeComponent@sTSIDUri指向的A/331中描述的S-TSID片段的EFDT元素中。

@sTSIDDestinationIpAddress-包含为该服务携带S-TSID的分组的 dotted-IPv4目的地地址的字符串。当不存在时，此属性的值被推断为当前MMTP会话的目的地IP地址。

@sTSIDDestinationUdpPort-包含为该服务携带S-TSID的分组的 UDP端口号的字符串。

@sTSIDSourceIpAddress-包含为该服务携带S-TSID的分组的 dotted-IPv4源地址的字符串。

@sTSIDMajorProtocolVersion-用于为此服务传递S-TSID的协议的主要版本号。当不存在时，该属性值被推断为1。

@sTSIDMinorProtocolVersion-用于为此服务传递S-TSID的协议的次要版本号。当不存在时，该属性值被推断为0。

broadbandComponent-关于宽带传递的ATSC 3.0服务的内容组件的描述。

@fullMPDUri-引用MPD片段，该MPD片段包含对通过宽带传递的ATSC 3.0服务的内容组件的描述。

ComponentInfo-包含服务中可用组件的信息。对于每个组件，包括关于组件类型、组件角色、组件名称、组件标识符、组件保护标志的信息。当mpuComponent存在时，该元素可能存在。

@componentType-该属性指示该组件的类型。值0表示音频组件。值1表示视频组件。值2表示隐藏字幕组件。值3到7被保留。

@componentRole-该属性指示该组件的角色或种类。

对于音频(当上述componentType(组件类型)属性等于0时): componentRole(组件角色)属性的值如下:0＝完全主要，1＝音乐和效果，2＝对话，3＝评论，4＝视觉障碍，5＝听觉障碍，6＝画外音，7-254 ＝保留，255＝未知。

对于视频(当上述componentType属性等于1时)，componentRole 属性的值如下:0＝主视频，1-254＝保留，255＝未知。

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

当上面的@componentType属性的值在3到7之间(含3和7)时， @componentRole值可能等于255。

@componentProtectedFlag-该属性表示该组件是否受保护(例如加密)。当该标志设置为值1时，该组件受到保护(例如加密)。当该标志设置为0时，该组件不受保护(例如未加密)。当不存在时， componentProtectedFlag(组件保护标志)属性的值被推断为等于0。

@componentId-该属性表示该组件的标识符。该属性的值可以与对应于该组件的MP表中的asset_id相同。

@componentName-该属性表示该组件的人类可读名称。

对于非RRT内容咨询的MMT信令，可以如下执行：

当使用MMT时，非RRT内容咨询评级可以由图36中定义的用于MMT的USBD中的sa:otherRatings元素规定。该元素的格式可能与 ATSC 3.0服务通告规范A/332的服务片段中规定的OtherRatings元素相同。

图37描述了ATSC 3.0服务通告规范A/332(A/332)中 sa:otherRatings元素的示例语法和语义，该规范可在以下网站获得: http://atsc.org/wp-content/uploads/2015/12/A332S33-159r6-Servic e-Announcement.pdf，该规范以全文引用的方式并入到本文中。关于图37，可以遵循以下约束:

每个OtherRatings元素可能具有唯一的ratingScheme(评级方案) 值。图20A-20C提供了对应于图19A-19C中示出的用于MMT USBD 的表结构中示出的元素和属性的MMTUSBD的XML方案。

图38示出了用于MPEG媒体输送的用户服务捆绑描述片段的另一个示例。图38中各种元素和属性的语义可以如下:

顶层或入口点SLS片段是USBD片段。USBD中元素中的一些元素包括以下内容:

元素userServiceDescription下的子属性serviceId和serviceStatus；

元素userServiceDescription下的子元素contentAdvisoryRating(内容咨询评级)和OtherRatings(其他评级)；

在元素userServiceDescription下的子元素Channel(信道)及其子属性serviceGenre(服务风格)、serviceIcon(服务图标)和子元素 ServiceDescription(服务描述)及其子属性serviceDescrTex(服务描述文本)、serviceDescrLang(服务描述语言)；

在元素userServiceDescription下的子元素mpuComponent及其子属性mmtPackageID和nextMMTPackageID、contendIdschemdIdUri、 contentIdvalue、nextMmtPackageId，nextContentIdSchemeIdUri和 nextContentIdValue；

在元素userServiceDescription下的子元素routeComponent及其子属性sTSIDUri、ApDuri StsiddestinationIpaddress、 sTSIDDestinationUdpPort、sTSIDSourceIPAddress、 sTSIDMajorProtocolVersion、sTSIDMinorProtocolVersion，作为服务信令数据，支持经由ROUTE协议传递本地缓存的服务内容；

在元素userServiceDescription下的broadbandComponent及其子属性fullMPDUri；和

在元素userServiceDescription下的子元素ComponentInfo及其子属性componentType(组件类型)、componentRole(组件角色)、 componentProtectedFlag(组件保护标志)、componentId(组件ID)、 componentName(组件名称)。

建议在服务通告中携带相同的信息时，不要在MMT USBD中重复该相同的信息。在这种情况下，服务通告中的信息应该优先。

bundleDescriptionMMT(捆绑描述MMT)可以表示为包含bundleDescriptionMMT根元素的XML文档，该根元素符合具有以下命名空间的XML方案中的定义：

taq:atsc.org，2016：XMLSchemas/ATSC3/Deivery/MMTUSD/1.0/

这些方案的定义在方案文件中。

上面标识的XML方案规定了ATSC 3.0标准中规定的元素的规范语法。

与包含这些文件的片段相对应的媒体类型可以按照A/331附录 H.3中的规定。

以下文本规定了MMT的用户服务描述中元素和属性的语义。

bundleDescriptionMMT-MMT的用户服务捆绑描述的根元素。

userServiceDescription(用户服务描述)-ATSC 3.0服务的单个实例。

@globalServiceID-标识ATSC 3.0服务的全球唯一URI。此参数用于链接到ESG数据(Service@globalServiceID)。缺少此属性可以意味着此ATSC 3.0服务是ESG或EAS服务。

@serviceId-引用LLS(SLT)中相应的服务条目。此属性的值与分配给服务条目的serviceId的值相同。

Name(名称)-ATSC 3.0服务的名称，使用@lang属性规定的语言。当名称不存在时，不会为ATSC 3.0服务的名称推断默认值。

@lang-ATSC 3.0服务名称的语言。该语言可根据在https://tools.ietf.org/ html/bcp47定义的BCP 47进行规定，该文以全文引用的方式并入本文中。

serviceLanguage(服务语言)-ATSC 3.0服务的可用语言。该语言可根据在https://tools.ietf.org/html/bcp47定义的BCP 47进行规定，该文以全文引用的方式并入本文中。当serviceLanguage不存在时，它被推断为“en”。

contentAdvisoryRating(内容咨询评级)-规定内容咨询评级，如ATSC3.0服务通告规范A/332(A/332)中所定义，该规范可在以下网站获得: http://atsc.org/wp-content/uploads/2015/12/A332S33-159r6-Servic e-Announcement.pdf，该文以全文引用的方式并入到本文中。该元素的格式可能与ATSC 3.0服务通告规范A/332(A/332)的服务片段中规定的ContentAdvisoryRatings(内容咨询评级)元素相同，该规范可在以下网站获得: http://atsc.org/wp-content/uploads/2015/12/A332S33-159r6-Servic e-Announcement.pdf，该文以全文引用的方式并入到本文中。当不存在contentAdvisoryRating时，不会为服务的基于RRT的内容咨询评级推断默认值。

OtherRatings(其他评级)-规定非RRT内容咨询评级，如ATSC3.0 服务通告规范A/332(A/332)中所定义，该规范可在以下网站获得: http://atsc.org/wp-content/uploads/2015/12/A332S33-159r6-Servic e-Announcement.pdf，该文以全文引用的方式并入到本文中。该元素的格式与ATSC 3.0服务通告规范A/332(A/332)服务片段中规定的OtherRatings元素相同，该规范可在以下网站获得: http://atsc.org/wp-content/uploads/2015/12/A332S33-159r6-Service-Anno uncement.pdf，该文以全文引用的方式并入到本文中。每个OtherRatings 元素可以有一个唯一的@ratingScheme值。当不存在其他评级时，不会为服务的基于非RRT的内容咨询评级推断默认值。

Channel(信道)-这个元素包含关于服务的信息。

@serviceGenre-该属性指示服务的主要风格。可以实例化该属性来描述服务的风格类别。<classificationSchemeURI>是 http://www.atsc.org/XMLSchemas/mh/2009/1.0/genre-cs/

当@serviceGenre不存在时，不会为服务的主要风格推断默认值。

@serviceIcon(服务图标)-该属性指示用于表示这种服务的图标的统一资源定位符(URL)。

ServiceDescription(服务描述)-包含可能多种语言的服务描述。

@serviceDescrText(服务描述文本)-该属性指示服务的描述。

@serviceDescrLang(服务描述语言)-该属性指示服务描述文本(serviceDescrText)的语言。可以遵循xs:lang的语义。当 @serviceDescrLang不存在时，它被推断为“en”。

在另一个示例中，当@serviceDescrLang不存在时，可以推断出一些其他默认值。例如：

当@serviceDescrLang不存在时，它被推断为“en”

当@serviceDescrLang不存在时，它被推断为“cn”

当@serviceDescrLang不存在时，它被推断为“kr”

mpuComponent-关于作为MPU传递的ATSC 3.0服务的内容组件的描述。

@mmtPackageId-对作为MPU传递的ATSC 3.0服务内容组件的 MMT包的引用。

@contentIdschemeIdUri-该属性可以指示用来标识与当前MMT包相关联的Content ID的方案的URI。@contentIdValue属性的语义特定于该属性规定的方案。允许的值是:

用于EIDR Content ID的urn:eidr；

用于Ad-ID Content ID的tag:atsc.org,2016:cid:adid；

用于用户私有Content ID系统的 tag:atsc.org,2016:cid:x-<abbrev>，其中<abbrev>是Content ID系统的合适缩写。

实验性或专有的Content ID系统可以通过用实验性或专有的 Content ID系统的形式“x-<abbrev>”的名称替换Ad-ID Content ID 的contentIdSchemeIdUri中的“adid”来支持，其中<abbev>是Content ID系统的合适缩写。执行此操作时，应注意所使用的<abbrev>不要与相同服务的任何其他实验性或专有Content ID系统重复。用户私有 Content ID系统可以是例如房屋号码或广播公司使用的一些其他标识符系统。

当@contentIdschemeIdUri不存在时，不会推断出默认值，也不会在此用户服务描述中显示有关当前MMT包的Content ID的信息。

@contentIdvalue-该属性可以根据@contentIdSchemeIdUri属性标识的ContentID系统规定与当前MMT包相关联的Content ID的值。“EIDR Content ID”可以是在娱乐标识符注册中心注册的EIDR ID 的典型形式。(参见eidr.org网站)。“Ad-ID Content ID”可以是在由美国广告代理协会和全国广告客户协会开发的Ad-ID系统中注册的 Ad-ID代码。(参见www.ad-id.org网站。)

当@ContentIdscheidURi不存在时，@ContentIdvalue可以不存在。当@ContentIdscheidURi存在时，@ContentIdvalue可以存在。

当@contentIdschemeIdValue不存在时，不会推断出默认值，也不会在此用户服务描述中存在有关当前MMT包的Content ID的信息。

@nextMmtPackageId-引用MMT包，该MMT包将在 @mmtPackageId引用的包之后及时用于作为MPU传递的ATSC 3.0服务的内容组件。

@nextContentIdschemeIdUri-该属性可以指示用来标识与下一个 MMT包相关联的Content ID的方案的URI。@nextContentIdValue属性的语义特定于该属性规定的方案。允许的值是:

用于EIDR Content ID的urn:eidr；

用于Ad-ID Content ID的tag:atsc.org,2016:cid:adid；

用于用户私有Content ID系统的 tag:atsc.org,2016:cid:x-<abbrev>，其中<abbrev>是Content ID系统的合适缩写。

实验性或专有的Content ID系统可以通过用实验性或专有的Content ID系统的形式“x-<abbrev>”的名称替换Ad-ID Content ID 的contentIdSchemeIdUri中的“adid”来支持，其中<abbev>是Content ID系统的合适缩写。执行此操作时，应注意所使用的<abbrev>不要与相同服务的任何其他实验性或专有Content ID系统重复。用户私有 Content ID系统可以是例如房屋号码或广播公司使用的一些其他标识符系统。

当@nextcontentIdschemeIdUri不存在时，不会推断出默认值，也不会在此用户服务描述中显示有关当前MMT包的Content ID的信息。

@nextContentIdvalue-该属性可以根据 @nextContentIdSchemeIdUri属性标识的Content ID系统规定与下一个包相关联的Content ID的值。“EIDR Content ID”可以是在娱乐标识符注册中心注册的EIDR ID的典型形式。(参见eidr.org网站)。“Ad-ID ContentID”可以是在由美国广告代理协会和全国广告客户协会开发的Ad-ID系统中注册的Ad-ID代码。(参见www.ad-id.org网站。)

当@NextContentIdscheidURi不存在时，@NextContentIdvalue可以不存在。当@NextContentIdscheidURi存在时，@NextContentIdvalue可以存在。

当@nextcontentIdschemeIdValue不存在时，不会推断出默认值，也不会在此用户服务描述中存在有关当前MMT包的Content ID的信息。

routeComponent-关于ROUTE传递的ATSC 3.0服务内容组件的描述。

@sTSIDUri-引用S-TSID片段，该片段为携带此ATSC 3.0服务内容的输送会话提供服务访问相关参数。

@apdURI-该可选属性可以提供对APD片段的引用，APD片段为 ROUTE传递的ATSC3.0服务的内容组件提供文件修复相关信息。该属性指向如A/331中所描述的APD片段。

当@apdURI存在时，至少一个Alternate-Content-Location-1(替代-内容-位置1)元素可以存在于由routeComponent@sTSIDUri指向的S-TSID片段的EFDT元素中。

@sTSIDDestinationIpAddress-包含为该服务携带S-TSID的分组的 dotted-IPv4目的地地址的字符串。当不存在时，此属性的值被推断为当前MMTP会话的目的地IP地址。

@sTSIDDestinationUdpPort-包含为该服务携带S-TSID的分组的 UDP端口号的字符串。

@sTSIDSourceIpAddress-包含为该服务携带S-TSID的分组的 dotted-IPv4源地址的字符串。

@sTSIDMajorProtocolVersion-用于为此服务传递S-TSID的协议的主要版本号。当不存在时，该属性值被推断为1。

@sTSIDMinorProtocolVersion-用于为此服务传递S-TSID的协议的次要版本号。当不存在时，该属性值被推断为0。

broadbandComponent-关于宽带传递的ATSC 3.0服务的内容组件的描述。mpuComponent、routeComponent或 broadbandComponent中的至少一个可能存在。

@fullMPDUri-引用MPD片段，该MPD片段包含对通过宽带传递的ATSC 3.0服务的内容组件的描述。

ComponentInfo-包含服务中可用组件的信息。对于每个组件，包括关于组件类型、组件角色、组件名称、组件标识符、组件保护标志的信息。当mpuComponent元素存在时，该元素可能存在。

@componentType-该属性指示该组件的类型。值0表示音频组件。值1表示视频组件。值2表示隐藏字幕组件。值3到7被保留。

@componentRole-该属性指示该组件的角色或种类。

对于音频(当上述componentType属性等于0时): componentRole属性的值如下:0＝完全主要，1＝音乐和效果，2＝对话， 3＝评论，4＝视觉障碍，5＝听觉障碍，6＝画外音，7-254＝保留，255＝未知。

对于视频(当上述componentType属性等于1时)，componentRole 属性的值如下:0＝主视频，1-254＝保留，255＝未知。

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

当上面的@componentType属性的值在3到7之间(含3和7)时， @componentRole值可能等于255。

@componentProtectedFlag(组件保护标志)-该属性指示该组件是否受保护(例如加密)。当该标志设置为值1时，该组件受到保护(例如加密)。当该标志设置为0时，该组件不受保护(例如未加密)。当不存在时，componentProtectedFlag属性的值被推断为等于0。

@componentId-该属性指示该组件的标识符。该属性的值可以与对应于该组件的MP表中的asset_id相同。

@componentName-该属性指示该组件的人类可读名称。当 @componentName不存在时，不推断默认值。

图22A-22C示出了用于MMT USBD的变型XML方案。图 20A-20C和22A-22C中的XML方案包括：

各种自定义的XML数据类型定义(XML复合类型和XML简单类型)。其可以包括下列：

用于端口的数据类型基于XMLunsignedShort(XML无符号短整型，0值除外)定义。

用于IP地址的基于模式的数据类型被定义为仅允许有效IP版本4 (IPv4)地址

用于Physical Layer Pipe(物理层管道，PLP)标识符的数据类型被定义为有效PLP值

这些定义使得在定义MMS USBD的同时防止为元素或属性规定非法值非常有效。

图22A-22C所示的XML方案与图20A-22C所示的XML方案之间的区别如下：

在图22A至图22C中，所用的附加命名空间(xmlns:slt)如下引用：xmlns:slt＝http://www.atsc.org/XMLSchemas/ATSC3/Delivery/SLT/1.0/.

在图22A至图22C中，用于服务清单列表(SLT)模式的xsd如下引入：<xs:importschemaLocation＝″SLT.xsd″

Namespace(命名空间)＝″http://www.atsc.org/XMLSchemas/ATSC3/Delivery/SLT/1.0/″/>

在图22A至图22C中，来自另一方案(例如，服务清单列表属性) 的serviceld属性与XML ref属性一起使用如下：<xs:attribute ref＝″slt:serviced″use＝″required”/>

图21A-21C以图形格式示出了XML方案结构。

模式的命名空间描述和规则可以定义如下。下面还提供了对XML 方案和命名空间的一般描述。

许多XML元素可以被定义并用于服务信令和传递。这些元素可以对应于以下情况：

为了提供用于低级信令、服务层信令和ROUTE协议的各种服务信令元素和属性

为了使用和扩展ATSC 3.0 USBD片段的3 GPP MBMS定义的元素和属性

这些XML元素可以在每个个别的方案文档中用单独的命名空间来定义。当定义各种个别的模式时，可以描述各种模式使用的命名空间。最右边两个“/”分隔符之间的命名空间的子字符串部分表示模式的主要版本和次要版本。最初定义的方案可以具有版本“1.0”，这表示主要版本为1，次要版本为0。

为了给模式的未来变化提供灵活性，具有当前定义的命名空间的 XML文档解码器应该忽略它们不识别的任何元素或属性，而不是将它们视为错误。

如果出现在此文档(例如，图19A-19C)中的表格所暗示的XML方案定义与出现在XML方案定义文件(例如，图20A-20C或者图22A-22C) 中的那些XML方案定义之间存在任何差异，则在XML方案定义文件中的那些XML方案定义是权威的并且可以优先。

在ATSC网站上可以找到此文档中定义的模式的XML方案文档。

下面提供了关于MMT USBD的正式、有效的XML方案的描述。这种解释是关于图20A-20C和图22A-22C中所示的XML方案和图 21A-21C中所示的XML方案结构。

bundleDescription(捆绑描述)可以表示为包含符合XML方案的bundleDescription根元素的XML文档。这种模式文件的示例在图 20A-20C中示出，并且上面提供了关于“XML方案和命名空间”的解释。

MBMS USBD片段的ATSC扩展可以与命名空间为 http://www.atsc.org/XMLSchemas/ATSC3/Delivery/MMTUSD/1.0/的 XML方案中规定的一样

缩写“mmtusd”应该被用作这个MMT USBD模式的元素中任一个的命名空间前缀——如果它们出现在XML文档中的话。可以通过在 XML文档的模式元素中包括以下属性来声明此前缀与命名空间的绑定： xmlns:mmtusd＝"http://www.atsc.org/XMLSchemas/ATSC3/Delivery/M MTUSD/1.0"

在一个变型示例中，单个命名空间可以被定义并用于各种信令相关模式。在这种情况下，以下描述可能适用于命名空间定义。

许多XML元素可以被定义并用于服务信令和传递。这些元素对应于以下情况:

为了提供用于低级信令、服务层信令和ROUTE协议的各种服务信令元素和属性

为了使用和扩展ATSC 3.0 USBD片段的3GPP MBMS定义的元素和属性

这些XML元素可以用单一的公共命名空间来定义。最右边两个“/”分隔符之间的命名空间子字符串部分表示模式的主要版本和次要版本。最初定义的模式可能具有版本“1.0”，这表示主要版本为1，次要版本为0。

为了给方案的未来变化提供灵活性，当前定义了这个命名空间的 XML文档的解码器应该忽略它们不识别的任何元素或属性，而不是将它们视为错误。

如果出现在此文档(例如，图19A-19C)中的表所暗示的XML方案定义与出现在XML方案定义文件(例如，图20A-20C或者图22A-22C) 中的那些XML方案定义之间存在任何差异，则在XML方案定义文件中的那些XML方案定义是权威的并且可以优先。

在ATSC网站上可以找到此文档中定义的模式的XML方案文档。

在一个变型示例中，当对各种信令相关模式使用信令命名空间时，可以应用以下内容。

下面提供了关于MMT USBD的正式、有效的XML方案的描述。这种解释是关于图20A-20C和图22A-22C中所示的XML方案和图 21A-21C中所示的XML方案结构。

bundleDescription(捆绑描述)可以表示为包含符合XML方案的bundleDescription根元素的XML文档。这种模式文件的示例在图 20A-20C中示出，并且上面提供了关于“XML方案和命名空间(XML Schema and Namespace)”的解释。

MBMS USBD片段的ATSC扩展可以与命名空间为 http://www.atsc.org/XMLSchemas/ATSC3/Delivery/MMTUSD/1.0/的 XML方案中规定的一样

缩写“atscsig”应该被用作ATSC信令模式的元素中任一个的命名空间前缀——如果它们出现在XML文档中的话。可以通过在XML 文档的模式元素中包括以下属性来声明此前缀与命名空间的绑定： xmlns:atscsig＝″http://www.atsc.org/XMLSchemas/ATSC3/ Delivery/Signaling/1.0″

在另一个变型示例中，可以替代地改变上面为命名空间定义的实际统一资源指示符(Uniform Resource Indicator，URL)值。

例如，代替URL：

http://www.atsc.org/XMLSchemas/ATSC3/Delivery/MMTUSD/1.0/，

可以使用URL：http://www.atsc.org/XMLSchemas/MMTUSD/1.0/

在另一个变型示例中，可以替代地改变上面为命名空间定义的实际URL值，以便不包括版本号。

例如，代替URL：

http://www.atsc.org/XMLSchemas/ATSC3/Delivery/MMTUSD/1.0/，

可以使用URL：http://www.atsc.org/XMLSchemas/MMTUSD/

应该注意，上面的URL使用斜杠(“/”)分隔符作为其最后一个字符。在一些示例中，作为最后一个字符的斜杠(“/”)分隔符可以从URL 中省略。

例如，代替URL：

http://www.atsc.org/XMLSchemasATSC3/Delivery/MMTUSD/1.0/，

可以使用URL：http://www.atsc.org/XMLschemas/ATSC3/Delivery/MMTUSD/1.0

同样

例如，代替URL：

http://www.atsc.org/XMLSchemas/ATSC3/Delivery/MMTUSD/，

可以使用URL：

http://www.atsc.org/XMLSchemas/ATSC3/Delivery/MMTUSD

例如，代替URL：

http://www.atsc.org/XMLSchemas/MMTUSD/1.0/，

可以使用URL：

http://www.atsc.org/XMLSchemas/MMTUSD/1.0

例如，代替URL：

http://www.atsc.org/XMLSchemas/MMTUSD/，

可以使用URL：

http:/www.atsc.org/XMLSchemas/MMTUSD

关于图19A-19C至图22A-22C，代替使用数据类型xml:lang来表示语言，可以使用数据类型xs:language。

关于图19A-19C至图22A-22C，代替使用数据类型xs:string，在一些情况下，可以使用数据类型xs:token。

关于图19A-19C至图22A-22C，代替使用数据类型xs:string，在一些情况下，可以使用数据类型StringNoWhitespaceType，其中 StringNoWhitespaceTpye定义如下：

如前所述，通过ATSC广播物理层进行流式传输和/或文件下载的内容传递选项之一是通过UDP和IP单向输送实时对象传递。提供了关于ROUTE传递的附加描述。

图23示出了具有ROUTE的各种元素、属性及其语义描述的用户服务捆绑描述片段。关于图23，在“ISO/IEC 23009-1 Dynamic Adaptive Streaming over HTTP(DASH)-Part1：Media presentation description and segment formats”(“ISO/IEC 23009-1通过HTTP动态自适应流式传输-第1部分：媒体演示描述和片段格式”)中进一步描述了DASH。ROUTE用户服务捆绑描述片段的根元素是捆绑描述元素。

bundleDescription(捆绑描述)可以表示为包含bundleDescription 根元素的XML文档，该bundleDescription根元素符合具有以下命名空间的XML方案中的定义：

http://www.atsc.org/XMLSchemas/ATSC3/Delivery/ROUTEUSD/1.0/

缩写“routeusd”应该用作该ROUTE用户服务描述模式的元素中元素中的任一个的命名空间前缀——如果它们出现在一个XML文档中的话。对于此标准的初始版本，可以通过在XML文档的模式元素中包含以下属性来声明此前缀与命名空间的绑定。

xmlns:routeusd＝″http://www.atsc.org/XMLSchemas/ATSC3/Delivery/ROUTEUSD/1.0/″

用于ROUTE USBD的规范XML方案在图24中示出。

进一步描述了由图23中的ROUTE USBD经由属性@sTSIDUri 引用的服务输送会话实例描述(Service Transport Session Instance Description，S-TSID)片段。S-TSID片段如图25所示。S-TSID是服务级别信令元数据片段，其包含零个或多个ROUTE会话和构成的分层编码输送(LCT)会话的整体输送会话描述信息，ATSC 3.0服务的媒体内容组件在这些会话中被传递。S-TSID片段如图26所示。LCT会话(与其携带的(一个或多个)服务组件相关联)由输送会话标识符(TSI)标识，该标识符在父ROUTE会话的范围内是唯一的。LCT会话共有的性质和个别LCT会话独有的某些性质在ROUTE信令结构中给出，ROUTE 信令结构被称为基于服务的传输会话实例描述(Service-based Transport Session InstanceDescription，S-TSID)，它是服务层信令的一部分。每个LCT会话都通过单个物理层管道(PLP)进行。PLP 是射频(RF)信道的一部分，具有一定的调制和编码参数。在ATSC A/322物理层协议规范中进一步描述了PLP，该协议规范可以在以下网站获得：“http://atsc.org/candidate-standard/a322-atsc-candidate-standard -physical-layer-protocol/”。ROUTE会话的不同LCT会话可能包含在不同的物理层管道中，也可能不包含在其中。S-TSID中描述的性质包括每个LCT会话的TSI值和PLP标识符(ID)、传递对象和/或文件的描述符以及应用层前向纠错(Application Layer Forward Error Correction，FEC)参数。S-TSID还包括服务的LCT会话中携带的传递对象或对象流的文件元数据，以及关于那些LCT会话中携带的有效载荷格式和内容组件的附加信息。

USBD片段中，userServiceDescription元素的@sTSIDUri属性引用了S-TSID片段的每个实例。

S-TSID可以表示为包含与具有以下命名空间的XML方案中的定义相符的S-TSID根元素的XML文档：

http://www.atsc.org/XMLSchemas/ATSC3/Delivery/ROUTESLS/1.0/

缩写“routesls”应该用作该模式中元素中元素中的任一个的命名空间前缀——如果它们出现在XML文档中的话。对于此标准的初始版本，可以通过在XML文档的模式元素中包含以下属性来声明此前缀与命名空间的绑定。

xmlns:routesls＝″http://www.atsc.org/XMLSchemas/ATSC3/Delivery/ROUTESLS/1.0/″

S-TSID的规范XML方案包括在图30中。

图25中的S-TSID片段在LCT会话中包括SRCFlow(SRC流) 元素和RepairFlow(修复流)元素。这些将被进一步描述。

SrcFlow元素描述了一个源流。源流将传递对象发送给接收机。传递对象是独立的，通常与应用相关的某些性质、元数据和与时间相关的信息相关联。SRCFlow元素及其子元素和属性如图26所示。SrcFlow 可以表示为包含SrcFlow根元素的XML文档，该SrcFlow根元素符合具有以下命名空间的XML方案中的定义：

http://www.atsc.org/XMLSchemas/ATSC3/Delivery/ROUTESLS/1.0/

缩写“routesls”应该用作该模式中元素中元素中的任一个的命名空间前缀——如果它们出现在XML文档中的话。对于此标准的初始版本，可以通过在XML文档的模式元素中包含以下属性来声明此前缀与命名空间的绑定。

xmlns:routesls＝″http://www.atsc.org/XMLSchema/ATSC3/Delivery/ROUTESLS/1. 0/′

图26中的SRCFlow元素包括图27中所示的扩展文件传递表 (EFDT)元素。

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

http://www.atsc.og/XMLSchemas/ATSC3/Delivery/ROUTESLS/1.0/

缩写“routesls”应该用作该模式中元素中的元素中的任一个的命名空间前缀——如果它们出现在XML文档中的话。对于本标准的初始版本，可以通过在XML文档的模式元素中包含以下属性来声明此前缀与命名空间的绑定。

xmlns:routesls＝″http://www.atsc.org/XMLSchemas/ATSC3/Delivery/ROUTESLS/1.0/″

EFDT的规范XML方案包括在图30中。

如前所述，图25中的S-TSID片段在LCT会话中包括RepairFlow 元素。这将进一步描述。图28示出了RepairFlow元素的结构。 RepairFlow元素及其子元素和属性提供关于信令元数据引用的LCT会话中携带的修复流的信息。

RepairFlow元素由三个属性和两个元素组成。这些将被进一步描述。元素FECOTI规定FEC对象传输信息。ProtectedObiect(受保护对象)元素描述如下。@maximumDelay属性规定源流中任何源分组与修复流之间的最大延迟。该属性可选择性地用信号发送。当未用信号发送时，该属性值被推断为等于0。不用信号发送这个属性，而是推断它的值可以节省比特。在另一个示例中，当@maximumDelay属性值没有被用信号发送时，可以使用一些其他默认值。例如，可以使用值5000。或者可以使用一些其他值。@overhead属性以百分比值表示修复流的开销。@minBuffSize属性规定修复流所需的缓冲大小。

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

http://www.atsc.org/XMLSchemas/ATSC3/Delivery/ROUTESLS/1.0/

缩写“routesls”应该用作该模式中元素中元素中的任一个的命名空间前缀——如果它们出现在XML文档中的话。对于本标准的初始版本，可以通过在XML文档的模式元素中包含以下属性来声明此前缀与命名空间的绑定。

xmlns:routesls＝http://www.atsc.org/XMLSchemas/ATSC3/Delivery/ROUTESLS/1.0/

RepairFlow的规范XML方案包括在图30中。

图28所示的修复流包括ProtectedObject(受保护对象)元素。关于ProtectedObject元素的更多细节显示在图29中。ProtectedObject元素由四个属性组成。@sessionDescription属性为受此修复流保护的源流提供会话描述信息。@tsi属性为受此修复流保护的源流提供传输会话标识符。@sourceTOI为传递对象提供输送对象标识符。 @fecTransportObjectSize规定FEC输送对象的默认大小。

ProtectedObject(受保护对象)的规范XML方案包含在图30中。

在XML方案中，定义了各种自定义数据类型。还为各种元素定义了数据类型。关于图30中的XML方案的元素和数据类型中的一些元素和数据类型的信息如下:

SrcFlow中的ContentInfo(内容信息):定义了用于该元素的“string(字符串)”数据类型。

扩展文件传递表(EFDT)的@version attribute(版本属性):定义用于该属性定义的unsignedInt(无符号整型)数据类型。

(EFDT的)@maxExpiresDelta属性:定义用于此属性的 unsignedInt(无符号整型)数据类型。

EFDT的FileTemplate、FDTParameters元素:定义用于该元素的“string(字符串)”数据类型。

在另一个示例中，FDTParameters元素可以是包括一个或多个文件描述符的数据结构，如单向输送文件传递(File Delivery over Unidirectional Transport，FLUTE)文件传递表(File Delivery Table，FDT)中所规定的。FLUTE FDT的定义见IETF:RFC 6726,“FLUTE-File Delivery over Unidirectional Transport, “Internet EngineeringTask Force(互联网工程任务组),Reston, VA,2012年11月.http://tools.ietf.org/ html/rfc6726”，该文以全文引用的方式并入到本文中。

在又一个示例中，FDTParameters元素可以是包括一个或多个文件描述符的数据结构，如以下文件中定义的3GPP-定义的FDT扩展中所规定：MBMS 3GPP:TS 26.346 V12.4.0(2014-12)，“3rd Generation Partnership Project；Technical Specification GroupServices and System Aspects；Multimedia Broadcast/Multicast Service(MBMS)；Protocols and codecs(Release 12)”(第三代合作伙伴项目；技术规范组服务和系统方面；多媒体广播/多播服务 (MBMS)；协议和编解码器(第12版))”，该文以全文引用的方式并入到本文中。FDTParameters元素可以包括一个或多个元素:

Cache-Control(缓存控制)、Alternate-Content-Location-1(替代-内容-位置-1)、Alternate-Content-Location-2、Base-URL-1(基本-URL-1)和Base-URL-2以及属性@Availability-Time。这些元素和属性的语义在这些文档中定义，并在下面描述。

在一个示例中，Alternate-Content-Location-1和/或 Alternate-Content-Location-2元素为文件修复提供URI。基于字节范围的文件修复服务URI的数量可以由FDT中的“Alternate-Content-Location-1”和“Alternate-Content-Location-2”元素的数量来确定。Alternate-Content-Location-1和/或 Alternate-Content-Location-2元素经由“xs:anyURI”值提供对文件修复服务器资源的引用。

在一个示例中，Base-URL-1和/或Base-URL-2元素为文件修复提供base URL。当存在时，“Base-URL-1”和/或“Base-URL-2”元素可以提供可以用来解析分别包含在任何Alternate-Content-Location-1和/或Alternate-Content-Location-2中的相对引用的base URL。

在一个示例中，Cache-Control元素提供了关于文件缓存指令的信息。如果对应文件的FDT中不存在元素“Cache-Control”，则终端应该假设不能为该文件给出缓存指令，并且可以尽最大努力处理该文件的缓存。

修复流的@maximumDelay属性:定义用于该属性的unsignedInt 数据类型。

修复流的@overhead属性:为此属性定义的基于unsignedInt的类型。

修复流的@minBuffSize属性:定义用于该属性的unsignedInt数据类型。

修复流的FECOTI:定义用于该元素的“string”数据类型。

ProtectedObject的@sessionDescription属性:定义用于该属性的“string”数据类型。

ProtectedObject的@tsi属性:定义用于此属性的unsignedInt数据类型。

ProtectedObject的@sessionDescription属性:定义了用于该属性的“string”数据类型。

ProtectedObject的@fecTransportObjectSize属性:定义用于该属性的unsignedInt数据类型。

自定义XML数据类型是为某些元素和/或属性定义和使用的。这些只允许为各种元素和/或属性定义和使用有效值。定义了以下自定义数据类型:

用于端口的数据类型基于XMLunsignedShort(XML无符号短整型，0值除外)定义。这允许仅定义有效的UDP端口值。

用于IP地址的基于模式的数据类型被定义为仅允许有效IPv4地址。这允许仅定义有效UDP端口值而不是任何通用的字符串。

用于物理层管道标识符的数据类型被定义为有效PLP值

典型的传递和流式传送系统需要将时间信息从传输侧传达到接收机侧。例如，这允许没有任何其他时钟源的接收机知道当前日期和时间。它还允许通过参考由传输侧用信号发送的公共系统时间来同步各种流媒体组件。

对于ATSC，系统时间可以经由物理层和/或输送层和/或通过IP 层来传递。例如，系统时间可以在ATSC物理层中作为自1970年1月1日00：00：00国际原子时(InternationalAtomic Time，TAI)以来的32比特秒数计数来传递，TAI是在IEEE 1588中定义的精确时间协议(Precision Time Protocol，PTP)时期。PTP定义于“IEEE：IEEE 1588-2008 PTP，“Standard for a Precision Clock Synchronization Protocol for NetworkedMeasurement and Control Systems，”，Institute for Electrical and ElectronicsEngineers.(IEEE：IEEE 1588-2008 PTP，“网络测量和控制系统精确时钟同步协议标准)电气和电子工程师学会”。额外的系统时间相关信息可以在输送层传递的 SystemTime(系统时间)元素中用信号发送。在一个示例中，SystemTime 元素可以具有如图31所示的结构。图31显示了SystemTime XML元素及其属性和属性的语义含义。

System Time可以表示为一个包含SystemTime根元素的XML文档，SystemTime根元素符合具有以下命名空间的XML方案中的定义：

http://www.atsc.org/XMLSchemas/ATSC3/Delivery/SYSTIME/1.0/

缩写“systime”应该用作该模式中的元素中的元素中的任一个的命名空间前缀——如果它们出现在XML文档中。对于此标准的初始版本，可以通过在XML文档的模式元素中包含以下属性来声明此前缀与命名空间的绑定。

xmlns:systme＝″ http://www.atsc.org/XMLSchemas/ATSC3/Delivery/SYSTIME/1.0/″

SystemTime的规范XML方案如图32所示。

在图32的XML方案中，定义了自定义的XML数据类型——“Day type(日类型)”，其可以具有1到31(包括1和31)之间的有效值，仅用于指示一个月中的有效日。

自定义的XML数据类型-“Hour type(小时类型)”，该数据类型可以具有0到24之间(包括0和24)的有效值，仅指示一日中的有效小时。

现在为MMT的用户服务捆绑描述片段描述额外变型。

图33示出了MMT的示例用户服务捆绑描述片段。

图34示出了MMT的另一个示例用户服务捆绑描述片段。

ATSC3.0的MMT的USBD片段包括以下内容：

元素userServiceDescription(用户服务描述)下的子属性 serviceId

元素userServiceDescription下的子元素contentAdvisoryRating (内容咨询评级)；

元素userServiceDescription下的子元素Channel(信道)及其子属性serviceGenre(服务风格)、serviceIcon(服务图标)和子元素 ServiceDescription(服务描述)及其子属性serviceDescrTex(服务描述文本)、serviceDescrLang(服务描述语言本)；

元素userServiceDescription下的子元素mpuComponent及其子属性mmtPackageID和nextMMTPackageID；

元素userServiceDescription的子元素routeComponent及其子属性sTSIDUri、sTSIDDestinationIpAddress、sTSIDDestinationUdpPort、 sTSIDSourceIPAddress、sTSIDMajorProtocolVersion、 sTSIDMinorProtocolVersion；

元素userServiceDescription下的子元素 broadbandComponent(宽带组件)及其子属性fullMPDUri；和

元素userServiceDescription下的子元素ComponentInfo(组件信息)及其子属性componentType(组件类型)、componentRole(组件角色)、componentProtectedFlag(组件保护标志)、componentId、 componentName(组件名称)。

优选地，当在服务通知中携带相同的信息时，相同的信息不应在 MMT USBD中的发射侧重复。在这种情况下，服务通告中的信息应该优先。

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

http://www.atsc.org/XMLSchemas/ATSCC3/Delivery/MMTUSD/1.0/

图33和图34中各种语法元素的语义如下所示。

bundleDescription-是用户服务捆绑描述的根元素。

userServiceDescription-元素对应于ATSC 3.0服务的单个实例。

@globalServiceID-标识ATSC 3.0服务的全球唯一URI。此参数用于将USBD链接到电子服务指南数据。电子服务指南提供了关于服务和节目的描述，以及它们的调度和其他元数据信息。

@serviceId-该属性提供对服务清单表中相应服务条目的引用。该属性值与分配给服务条目的服务标识符的值相同。

Name-ATSC 3.0服务的名称，使用@lang属性规定的语言。

@lang-ATSC 3.0服务名称的语言。语言可以根据最佳当前实践 (Best CurrentPractice，BCP)47来规定。BCP 47描述了用于标识语言的标签，并可在https:// tools.ietf.org/html/bcp47获得。它以全文引用的方式并入到本文中。

serviceLanguage-ATSC 3.0服务的可用语言。语言可根据BCP 47 规定。

contentAdvisoryRating-规定contentAdvisoryRating，如ATSC 3.0服务通告中所定义。

Channel-这个元素包含关于服务的信息。

@serviceGenre-该属性指示服务的主要风格。可以实例化该属性来描述服务的风格类别。<classificationSchemeURI>是 http://www.atsc.org/XMLSchemas/mh/2009/1.0/genre-cs/，服务风格的值可以与A/153第4部分附件B中的分类方案中的术语值相匹配。A/153 第4部分描述了ATSC移动DTV标准-通告，可在以下网址获得: http://atsc.org/wp-content/uploads/2015/03/a_153-Part-4-2009.pdf 。它以全文引用的方式并入到本文中。

@serviceIcon-该属性指示用于表示该服务的图标的URL。

ServiceDescription-包含可能多种语言的服务描述。

@serviceDescrText-该属性指示服务的描述。

@serviceDescrLang-该属性指示serviceDescrText的语言。可以遵循xs:lang的语义。

mpuComponent-关于作为MPU传递的ATSC 3.0服务的内容组件的描述。

@mmtPackageId-对作为MPU传递的ATSC 3.0服务的内容组件的 MMT包的引用。

@nextMmtPackageId-引用MMT包，该MMT包将在@mmtPackageId引用的包之后及时用于作为MPU传递的ATSC 3.0服务的内容组件。

routeComponent-提供ROUTE传递的ATSC 3.0服务内容组件的描述。

@sTSIDUri-引用S-TSID片段，该片段为携带此ATSC 3.0服务内容的输送会话提供服务访问相关参数。

@sTSIDDestinationIpAddress-包含为该服务携带S-TSID的分组的 dotted-IPv4目标地址的字符串。当不存在时，此属性的值被推断为当前MMTP会话的目的地IP地址。

@sTSIDDestinationUdpPort-包含为该服务携带S-TSID的分组的 UDP端口号的字符串。

@sTSIDSourceIpAddress-包含为该服务携带S-TSID的分组的 dotted-IPv4源地址的字符串。

@sTSIDMajorProtocolVersion-用于为此服务传递S-TSID的协议的主要版本号。当不存在时，该属性值被推断为1。

@sTSIDMinorProtocolVersion-用于为此服务传递S-TSID的协议的次要版本号。当不存在时，该属性值被推断为0。

broadbandComponent-该元素提供了关于宽带传递的ATSC 3.0 服务的内容组件的描述。

@fullMPDUri-提供了一个对基于HTTP的动态自适应流 (Dynamic AdaptiveStreaming over HTTP，DASH)媒体演示描述 (Media Presentation Description，MPD)片段的引用，该片段包含了对通过宽带传递的ATSC 3.0服务的内容组件的描述。ISO/IEC国际标准最终草案(Final Draft International Standard，FDIS) 23009-1:2014(其以全文引用的方式并入到本文中)中规定了DASH。

DASH MPD是为了提供流媒体服务而对Media Presentation (媒体演示)的形式化描述。

DASH Media Presentation是建立媒体内容的有界或无界演示的数据集合。

ComponentInfo-包含服务中可用组件的信息。对于每个组件，这包括关于组件类型、组件角色、组件名称、组件标识符、组件保护标志的信息。

@componentType-该属性指示该组件的类型。值0指示音频组件。值1指示视频组件。值为2指示隐藏字幕组件。值3到7被保留。

@componentRole-该属性指示该组件的角色或种类。对于音频(当上述componentType属性等于0时):componentRole属性的值如下: 0＝完全主要，1＝音乐和效果，2＝对话，3＝评论，4＝视觉障碍，5＝听觉障碍，6＝画外音，7-254＝保留，255＝未知。对于视频(当上述 componentType属性等于1时)，componentRole属性的值如下:0＝主视频，1-254＝保留，255＝未知。

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

当上面的@componentType属性的值在3到7之间(含3和7)时， @componentRole值可能等于255。

@componentProtectedFlag-该属性指示该组件是否受保护(例如加密)。当该标志设置为值1时，该组件受到保护(例如加密)。当该标志设置为0时，该组件不受保护(例如未加密)。当不存在时， componentProtectedFlag属性的值被推断为等于0。

@componentId-该属性指示该组件的标识符。该属性的值可以与对应于该组件的MP表中的asset_id相同。

@componentName-该属性指示该组件的人类可读名称。

除了上述元素和属性之外，图33中还定义了@apdUri属性。在这种情况下，@apdUri被定义为其routeComponent元素的属性。因为 @apdUri是作为属性包括的，所以它只能指示一个URI。在这种情况下，此apd URI表示为@apdUri属性的值，@apdUri的语义定义如下:

@apdUri-该可选属性可提供对相关过程描述(Associated ProcedureDescription，APD)片段的引用，该片段为ROUTE传递的 ATSC 3.0服务的内容组件提供文件修复相关信息。@apdUri指向下面描述的APD片段。

当@apdURI存在时，由routeComponent(路由组件)元素的 @sTSIDUri属性指向的S-TSID片段的EFDT元素中可能至少存在一个 Alternate-Content-Location-1元素。

图27示出了一个示例EFDT。一个或多个文件修复服务器的(一个或多个)位置由EFDT元素的Alternate-Content-Location-1和 Alternate-Content-Location-2子元素提供，一个或多个文件修复服务器的位置呈(一个或多个)HTTP URL(超文本链接)形式，接收机可以与其联系以请求文件修复数据。

图34中定义了具有@apdUri属性的apd元素。在这种情况下，apd 元素被定义为其routeComponent元素的子元素。apd的基数为0..N，允许包含多个apd元素作为routeComponent元素的子元素。apd元素和 @apdUri属性的语义定义如下:

apd-APD片段URI的容器元素。

@apdUri-该可选属性可以提供对APD片段的引用，APD片段为 ROUTE提供的ATSC3.0服务的内容组件提供文件修复相关信息。 @apdUri指向下面描述的APD片段。

当@apdURI存在时，由routeComponent@sTSIDUri指向的S-TSID 片段的EFDT元素中可以至少存在一个Alternate-Content-Location-1元素。

相关过程描述片段描述如下:

APD是一个服务层信令元数据片段，它包含与S-TSID片段中 EFDT元素中的特定参数结合使用的信息，以管理接收机对HTTP文件修复功能的可选使用。文件修复过程对应于HTTP请求/响应事务，通过该事务，无法获取通过ROUTE传递的整个对象的接收机可以经由宽带从文件修复服务器请求并获取丢失的数据。

图35示出了一个示例APD片段。如果接收机希望执行文件修复过程以获得丢失的数据，APD片段在postFileRepair(后文件修复) 元素下为接收机提供时间信息。postFileReception的offsetTime(偏移时间)子元素表示在相关文件的传输结束后，接收机在能开始文件修复过程之前可能等待的时间间隔(秒)。这意味着接收机可以通过这种方式确定文件传输结束，以及允许其执行文件修复的相关时间窗口。 postFileRepair(后文件修复)的randomTimePeriod(随机时间周期)子元素定义了一个时间窗口，接收机可以在该时间窗口内计算随机值。该值表示接收机在提交文件修复请求之前，经过了offsetTime传达的初始固定延迟之后的额外等待时间。随机等待的目的是更好地确保从多个接收机到达文件修复服务器的文件修复请求流量的统计均匀分布。

APD可以表示为包含associatedProcedureDescription(关联过程描述)根元素的XML文档，该根元素符合具有以下命名空间的XML 方案中的定义：

http://www.atsc.org/XMLSchemas/ATSC3/Delivery/ROUTEAPD/1. 0/

以下文本规定了APD片段中元素和属性的语义。

associatedProcedureDescription-Associated Procedure Description的根元素。

postFileRepair-管理文件修复过程开始时间的时间信息容器。

@offsetTime-广播文件传输结束后，接收机在开始文件修复过程之前可以等待的时间间隔(秒)。如果此属性不存在或设置为“0”，则接收机不应在@randomTimePeriod给出的时间窗口内计算随机时间之前使用等待时间来发起文件修复请求。当不存在时，offsetTime被推断为等于0。

@randomTimePeriod-在经过了offsetTime传达的固定延迟之后，作为文件修复过程的一部分，该属性定义了一个时间窗口(以秒为单位)，接收机可以在该时间窗口内计算随机值。@randomTimePeriod的值表示接收机在被允许发起文件修复请求之前的额外等待时间。

广播服务可能有与之相关联的应用。这种应用可以通过向用户提供交互式体验来增强广播服务。作为示例，观看直播广播服务电视节目“Jeopardy”的用户可以播放与直播广播服务电视节目相关联的 Jeopardy问答节目交互式应用。应用要采取的动作可以经由广播或宽带传递的通知来发起。这种通知称为事件。服务和应用信令可按照 ATSC3.0候选标准A/337“应用信令(Application Signaling)”进行定义，该标准可在以下网址获得：http://atsc.org/wp-content/uploads/2017/01/A337S33-215r1-Applic ation-Signaling-1.pdf，该文以全文引用的方式并入到本文中。

当在基于MMT的系统中经由广播传递时，事件可以在称为应用事件信息(Application Event Information，AEI)文档的XML文档中传递。

AEI可以表示为一个包含AEI根元素的XML文档，该根元素符合具有以下命名空间的XML方案中的定义：

tag:atsc.org，2016：XMLSchemas/ATSC3/AppSignaling/AEI/1.0/

XML方案xmlns的简称应该是“aei”。

图39指示了AEI的示例结构。AEI的规范XML方案可以如图40 所示。

AEI表的元素和属性的规范语义如下：

AEI-这个根元素描述了一组静态事件流，并包含一个或多个 EventStream元素。

@assetId-此必需属性规定MMT资产的标识符，其MPU用作 EventStream元素中事件时间参考的锚。该值可能等于ISO/IEC 23008-1中的asset_id()值。

@mpuSeqNum-此必需属性规定MMT资产中锚MPU的序列号，由AEI@assetId标识，用作EventStream(事件流)元素中事件的时间参考锚。

@timestamp-该必需属性规定了锚MPU中第一访问单元的演示时间，锚MPU由AEI@assetId指示的资产内的AEI@mpuSeqNum指示。ISO/IEC 23008-1 MPU_Timestamp_descriptor()的 mpu_presentation_time字段的格式可以用于该属性。

EventStream-这个元素及其属性可以描述关于事件流的信息。

@schemeIdUri-此必需属性规定此事件流的标识符方案。该字符串可以使用URN或URL语法。URN和URL在IETF RFC 3986 “Uniform Resource Identifier(URI):GenericSyntax”(IETF RFC 3986“统一资源标识符(URI):通用语法”)中有所描述，该文可在https://tools.ietf.org/html/rfc3986获得，以全文引用的方式并入到本文中。每个AEI.EventStream元素对此属性可能有唯一的值。

@value-该可选属性规定AEI.EventStream@schemeIdUri范围内事件流的值。当不存在时，不定义默认值。

@timescale-此可选属性规定用于此事件流中事件的时标，单位为每秒。当不存在时，AEI.EventStream@timescale被推断为等于1。 AEI.EventStream@timescale可能不等于0。

Event-该元素的每个实例及其属性可以定义关于父事件流元素上下文中的事件信息。

在一个示例中，以下语义可以适用于“Event”元素:

Event-该元素的每个实例及其属性可以定义父事件流元素上下文中的事件信息。该元素包括对应于编码为XML string.@presentationTime的事件的数据。该可选属性规定事件相对于锚MPU中第一访问单元的演示时间的演示时间，锚MPU在由 AEI@assetId规定的asset ID指示的资产内由父AEI@mpuSeqNum规定的序列号指示。演示时间的相对值(秒)等于 AEI.EventStream.Event@presentationTime除以 AEI.EventStream@timeScale。当不存在时， AEI.EventStream.Event@presentationTime被推断为等于0。

@duration-此可选属性规定事件的演示持续时间。演示持续时间 (秒)等于AEI.EventStream.Event@duration除以 AEI.EventStream@timeScale。当该属性不存在时，不会推断出默认值。在另一个示例中，当不存在时，@duration被推断为等于在由 AEI@assetId规定的资产ID指示的资产内由父AEI@mpuSeqNum规定的序列号指示的MPU的持续时间。

@id-此可选属性规定父AEI.EventStream@schemeIdUri和 AEI.EventStream@value范围内此事件的标识符。当该属性不存在时，不会推断出默认值。

基于MMT的服务中的事件也可以在MPU的“evti”框中携带。这种方法特别适用于动态事件。图41指示了“evti”框的示例结构，使用了ISO BMFF文件中的框的规范格式。

evti框的定义如下。

框类型“evti”

容器：MPU

强制性：否

数量：零或更多

“evti”框中元素的规范语义如下:

scheme_id_uri-此字段规定此事件的标识符方案。该字符串可以使用URN或URL语法。可以存在多个具有相同scheme_id_uri的“evti”框。

Value-此字段规定scheme_id_uri范围内此事件的值。

timescale-此字段提供用于此事件的时标，单位为每秒。时标可以不等于0。

event_id-该字段规定scheme_id_uri和值范围内的此事件标识符。具有scheme_id_uri、value和event_id字段相同值的事件在 timescale、event_presentation_time_delta、event_duration、和event_data[] 方面可以具有相同值。

event_presentation_time_delta-该字段规定该事件相对于该 MPU中第一访问单元的演示时间的演示时间。此演示时间的相对值(秒) 等于event_presentation_time_delta除以timescale。

event_duration-此字段规定此事件的演示持续时间。此事件的演示持续时间(秒)等于event_duration除以timeScale。

event_data-此“evti”框结束前的剩余数据规定了与此事件相关联的数据。此字段可能为空。此字段的格式由scheme_id_uri规定的方案的所有者定义。

在一个示例中，如果存在具有相同scheme_id_uri的多个“evti”框，则在这些框中，value(值)、event_presentation_time_delta、 event_data[]中的至少一个可以不同。

一个或多个“evti”框可以出现在MPU的开头，“ftyp”框之后，“moov”框之前，或者可以可能出现在紧挨着任何“moof”框的前方。这些框在ISO/IEC 14496-12“ISO basemedia file format”-ISO BMFF,February 2015(2015年2月的ISO/IEC 14496-12“ISO基本媒体文件格式”-ISO BMFF)中定义，该文以全文引用的方式并入到本文中。

因此，一个MPU中可以包含多于一个“evti”框。

尽管图13至图40示出了语法、语义和模式的特定示例，但是其他变型也是可能的。这些包括以下变型：

与上面显示的数据类型相比，一个元素可以使用不同的数据类型。例如，可以使用unsignedShort(无符号短整型)数据类型来代替 unsignedByte(无符号字节)数据类型。在另一个示例中，可以使用 String(字符串)数据类型来代替无符号字节数据类型。

代替作为属性用信号发送语法，而是作为元素用信号发送语法。代替作为元素用信号发送语法，而是作为属性用信号发送语法。

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

可以使用Javascript对象符号(Javascript Object Notation，JSON) 格式和JSON模式来代替XML格式和XML方案。替代地，所提出的语法元素可以使用逗号分隔值(Comma Separated Values，CSV)、巴科斯诺尔范式(Backus-Naur Form，BNF)、扩充巴科斯诺尔范式 (Augmented Backus-Naur Form，ABNF)或扩展巴科斯诺尔范式 (ExtendedBackus-Naur Form，EBNF)来表示。

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

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

一些子元素可以替代地作为父元素被用信号发送，或者它们可以作为另一个子元素的子元素被用信号发送。

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

在一个或多个示例中，所描述的功能可以用硬件、软件、固件或其任意组合来实现。如果以软件实现，这些功能可以作为一个或多个指令或代码存储在计算机可读介质上或通过计算机可读介质传输，并由基于硬件的处理单元执行。计算机可读介质可以包括计算机可读存储介质，其对应于诸如数据存储介质之类的有形介质，或者包括例如根据通信协议便于计算机程序从一个地方传输到另一个地方的任何介质的通信介质。以这种方式，计算机可读介质通常可以对应于(1)非暂时性的有形计算机可读存储介质，或者(2)诸如信号或载波的通信介质。数据存储介质可以是可由一个或多个计算机或一个或多个处理器访问的任何可用介质，以检索指令、代码和/或数据结构来实现本公开中描述的技术。计算机程序产品可以包括计算机可读介质。

作为示例而非限制，这种计算机可读存储介质可以包括RAM、 ROM、EEPROM、CD-ROM或其他光盘存储器、磁盘存储器或其他磁存储设备、闪存或任何其他可以用于存储指令或数据结构形式的所需程序代码并且可以由计算机访问的介质。此外，任何连接都被恰当地称为计算机可读介质。例如，如果使用同轴电缆、光纤电缆、双绞线、数字用户线路(DSL)或诸如红外、无线电和微波等无线技术从网站、服务器或其他远程源传输指令，则同轴电缆、光纤电缆、双绞线、DSL 或诸如红外、无线电和微波的无线技术包括在介质的定义中。然而，应当理解，计算机可读存储介质和数据存储介质不包括连接、载波、信号或其他暂时介质，而是指向非暂时的有形存储介质。这里使用的光盘和磁盘包括致密盘(compact disc，CD)、激光盘、光盘、数字多功能盘(DVD)、软盘和蓝光光盘，其中磁盘通常磁性地再现数据，而光盘用激光光学地再现数据。上述的组合也应该包括在计算机可读介质的范围内。

指令可以由一个或多个处理器执行，例如一个或多个数字信号处理器(DSP)、通用微处理器、专用集成电路(ASIC)、现场可编程逻辑阵列(FPGA)或其他等效的集成或离散逻辑电路。因此，这里使用的术语“处理器”可以指任何前述结构或任何其他适合于实现这里描述的技术的结构。此外，在一些方面，这里描述的功能可以在配置用于编码和解码的专用硬件和/或软件模块中提供，或者并入组合编解码器中。此外，这些技术可以在一个或多个电路或逻辑元素中完全实现。

本公开的技术可以在多种设备或装置中实现，包括无线手持机、集成电路(IC)或一组IC(例如芯片组)。在本公开中描述了各种组件、模块或单元，以强调被配置为执行所公开的技术的设备的功能方面，但是不一定需要由不同的硬件单元来实现。相反，如上所述，各种单元可以结合在硬件单元中，或者由操作中硬件单元(intraoperative hardwareunit)的集合提供，包括如上所述的一个或多个处理器，以及合适的软件和/或固件。

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

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

Claims (6)

1.一种用于用信号发送用户服务捆绑描述的方法，所述方法包括：

用信号发送与服务实例相关联的用户服务描述元素；

用信号发送内容咨询评级列表，其中，根据第一方法格式化所述内容咨询评级列表的每个元素；

用信号发送其他评级列表，其中，根据第二方法格式化所述其他评级列表的每个元素；

传输所述用户服务捆绑描述；和

针对MPEG媒体输送服务中的事件，用信号发送媒体处理单元中的多个evit框，其中

所述其他评级列表的第一元素和所述其他评级列表的第二元素包含评级方案属性，其中

所述第一方法是评级区域表格式化方法，并且

所述第二方法是非评级区域表格式化方法。

2.根据权利要求1所述的方法，其中，所述内容咨询评级列表包含零元素。

3.根据权利要求1所述的方法，其中，所述其他评级列表包含零元素。

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

接收用户服务捆绑描述；

解析所述用户服务捆绑描述，以确定与所述视频服务相关联的用户服务描述元素；

解析与所述视频服务相关联的所述用户服务描述元素，以接收内容咨询评级列表，其中，根据第一方法格式化所述内容咨询评级列表的每个元素；

解析与所述视频服务相关联的所述用户服务描述元素，以接收其他评级列表，其中，根据第二方法格式化所述其他评级列表的每个元素；

当所述内容咨询评级列表的元素和所述其他评级列表的元素满足条件时，渲染所述视频服务；

当所述内容咨询评级列表的元素和所述其他评级列表的元素不满足所述条件时，不渲染所述视频服务；

解析所述其他评级列表的第一元素，以确定第一评级方案属性；以及

解析所述其他评级列表的第二元素，以确定第二评级方案属性；

根据所述第一元素和所述第二元素来渲染所述视频服务；和

针对MPEG媒体输送服务中的事件，接收媒体处理单元中的多个evit框；

解析所述多个evit框以呈现所述事件；并且

根据所述多个evit框呈现所述事件，其中

所述第一方法是评级区域表格式化方法，并且

所述第二方法是非评级区域表格式化方法。

5.根据权利要求4所述的设备，其中，所述内容咨询评级列表包含零元素。

6.根据权利要求4所述的设备，其中，所述其他评级列表包含零元素。

Images