CN106105249B - 用于解码服务指南的方法 - Google Patents

用于解码服务指南的方法 Download PDF

Info

Publication number
CN106105249B
CN106105249B CN201580014531.9A CN201580014531A CN106105249B CN 106105249 B CN106105249 B CN 106105249B CN 201580014531 A CN201580014531 A CN 201580014531A CN 106105249 B CN106105249 B CN 106105249B
Authority
CN
China
Prior art keywords
service
information
attribute
component
guide
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201580014531.9A
Other languages
English (en)
Other versions
CN106105249A (zh
Inventor
萨琴·G·德希潘德
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sharp Corp
Original Assignee
Sharp Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sharp Corp filed Critical Sharp Corp
Publication of CN106105249A publication Critical patent/CN106105249A/zh
Application granted granted Critical
Publication of CN106105249B publication Critical patent/CN106105249B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/68—Systems specially adapted for using specific information, e.g. geographical or meteorological information
    • H04H60/72—Systems specially adapted for using specific information, e.g. geographical or meteorological information using electronic programme guides [EPG]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/35—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users
    • H04H60/38—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users for identifying broadcast time or space
    • H04H60/41—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users for identifying broadcast time or space for identifying broadcast space, i.e. broadcast channels, broadcast stations or broadcast areas
    • H04H60/43—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users for identifying broadcast time or space for identifying broadcast space, i.e. broadcast channels, broadcast stations or broadcast areas for identifying broadcast channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2362—Generation or processing of Service Information [SI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/41407—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance embedded in a portable device, e.g. video client on a mobile phone, PDA, laptop
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4383—Accessing a communication channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • General Engineering & Computer Science (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

一种由解码器执行的解码服务指南的方法包括：接收所述服务指南中的服务描述；接收所述服务描述中的服务媒体扩展；接收服务媒体扩展中的主频道号、副频道号和图标；对包括所述服务媒体扩展、所述主频道号、所述副频道号和所述图标在内的所述服务指南进行解码。服务指南与包括媒体比特流在内的服务相关联，并且被OMA移动广播服务使能器套件(OMA BCAST)支持。

Description

用于解码服务指南的方法
技术领域
本公开总体上涉及服务指南。
背景技术
广播服务能够被具有广播接收机的所有用户接收。广播服务可以被粗略地划分为两种，即，仅携带音频的无线电广播服务以及携带音频、视频和数据的多媒体广播服务。这种广播服务从模拟服务发展为数字服务。最近，多种类型的广播系统(例如电缆广播系统、卫星广播系统、基于互联网的广播系统、以及使用电缆网络、互联网和/或卫星的混合广播系统)将高质量的音频和视频广播服务随高速数据服务一起提供。此外，广播服务包括发送和/或接收朝向单独计算机和/或计算机组和/或一个或多个移动通信设备的音频、视频和/或数据。
除了更传统的固定接收设备之外，移动通信设备也被类似地配置为支持这些服务。如此配置的移动设备(例如移动电话)使得用户在移动时方便地使用这些服务。对多媒体服务的增长的需要导致了针对移动通信和通用有线通信两者的多种无线/广播服务。此外，这种会聚融合了针对不同的有线和无线广播服务的环境。
发明内容
技术问题
开放移动联盟(OMA)是用于在个人移动方案之间交互的标准，其用于定义针对移动软件和互联网服务的各种应用标准。OMA移动广播服务使能器套件(OMA BCAST)是设计为支持移动广播技术的规范。OMA BCAST定义了提供基于IP的移动内容传递的技术，其包括诸如服务指南、下载和流传输、服务和内容保护、服务订阅和漫游之类的各种功能。
问题的解决方案
根据本发明，提供了一种由与包括媒体比特流的服务相关联的解码器对服务指南进行解码的方法，所述方法包括：
(a)由所述解码器接收所述服务指南中的服务描述；
(b)由所述解码器接收所述服务描述中的服务媒体扩展；
(c)由所述解码器接收所述服务媒体扩展中的主频道号；
(d)由所述解码器接收所述服务媒体扩展中的副频道号；
(e)由所述解码器接收所述服务媒体扩展中的图标；
(f)由所述解码器对包括所述服务媒体扩展、所述主频道号、所述副频道号和所述图标在内的所述服务指南进行解码。
发明的有益效果
在结合附图考虑本发明的以下详细描述时，本发明的以上和其它目的、特征和优点将更易于理解。
附图说明
图1是示出了由OMA BCAST工作组在应用层和传输层中指定的BCAST系统的逻辑架构的框图。
图2是示出了用于OMA BCAST系统中的服务指南的结构的示图。
图2A是示出了服务指南分段之间的基数和参考方向的示图。
图3是示出了传统服务指南传递方法的原理的框图。
图4示出了描述方案。
图5示出了具有MajorChannelNum(主频道号)和MinorChannelNum(副频道号)的ServiceMediaExtension(服务媒体扩展)。
图6示出了具有Icon(图标)的服务媒体扩展。
图7示出了具有url的服务媒体扩展。
图8示出了具有MajorChannelNum、MinorChannelNum、Icon和url的ServiceMediaExtension。
图9A示出了AudioLanguage(音频语言)元素和TextLanguage(文本语言)元素。
图9B示出了AudioLanguage元素和TextLanguage元素。
图9C示出了AudioLanguage元素和TextLanguage元素。
图10A示出了AudioLanguage元素和TextLanguage元素。
图10B示出了AudioLanguage元素和TextLanguage元素。
图10C示出了AudioLanguage元素和TextLanguage元素。
图11示出了分量信息描述信令。
图12示出了频道信息描述信令。
图13A示出了用于分量信息描述符的二进制语法。
图13B示出了用于分量信息描述符的二进制语法。
图14A示出了用于频道信息描述符的二进制语法。
图14B示出了用于频道信息描述符的二进制语法。
图15示出了用于分量信息描述符的XML语法和语义。
图16示出了用于频道信息描述符的XML语法和语义。
图17示出了用于分量信息描述符的XML架构。
图18示出了用于频道信息描述符的XML架构。
具体实施方式
参照图1，由OMA(开放移动联盟)BCAST指定的广播系统的逻辑架构可以包括应用层和传输层。BCAST系统的逻辑架构可以包括内容创建(CC)101、BCAST服务应用102、BCAST服务分布/适配(BSDA)103、BCAST订阅管理(BSM)104、终端105、广播分布系统(BDS)服务分布111、BDS 112和交互网络113。将理解，可以根据需要对广播系统和/或接收机系统进行重配置。将理解，根据需要，广播系统和/或接收机系统可以包括附加的元件和/或更少的元件。
总体上，内容创建(CC)101可以提供作为BCAST服务的基础的内容。内容可以包括用于公共广播服务的文件，例如用于包括音频和视频在内的电影的数据。内容创建101向BCAST服务应用102提供内容的属性，所述属性用于创建服务指南并确定将传递服务的传输承载。
总体上，BCAST服务应用102可以接收从内容创建101提供的BCAST服务的数据，并且将接收到的数据转换为适合于提供媒体编码、内容保护、交互服务等的形式。BCAST服务应用102将从内容创建101接收到的内容的属性提供给BSDA 103和BSM 104。
总体上，BSDA 103可以使用从BCAST服务应用102提供的BCAST服务数据，执行诸如文件/流传递、服务聚集、服务保护、服务指南创建/传递和服务通知之类的操作。BSDA 103将服务适配于BDS 112。
总体上，BSM 104可以经由硬件或软件管理服务预配置(例如用于BCAST服务用户的订阅和收费相关功能)、用于BCAST服务的信息预配置以及接收BCAST服务的移动终端。
总体上，终端105可以接收内容/服务指南和节目支持信息(例如内容保护)，并将广播服务提供给用户。BDS服务分布111通过与BDS 112和交互网络113的双向通信向多个终端传递移动广播服务。
总体上，BDS112可以通过广播频道传递移动广播服务，并且可以包括例如第三代合作伙伴计划(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服务属性、内容属性、通知、服务指南、安全材料(例如用于BCAST服务保护的密钥值和数字版权管理(DRM)版权对象(RO))、以及通过广播频道传输的所有数据和信令。
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是用于以下项的传输路径：服务预配置、订阅信息、设备管理以及安全材料(例如，用于BCAST服务保护的密钥值和DRM RO)。
X-1 131是BDS服务分布111和BDS 112之间的参考点。X-2 132是BDS服务分布111和交互网络113之间的参考点。X-3133是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可以包括服务指南传递描述符(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可以包括关于服务内容、种类、服务位置等的信息。总体上，“Service(服务)”分段以聚集水平描述包括广播服务在内的内容项。可以使用多种访问方式(例如广播频道和交互频道)来向用户传递服务。服务可以针对特定用户组或地理区域。根据服务的类型，服务可以具有交互部分、仅广播部分或这两者。此外，服务可以包括不与内容直接相关但是与服务(例如购买或订阅信息)的功能相关的分量。作为服务指南(Service Guide)的一部分，“Service”分段形成了由包括“Access(访问)”、“Schedule(时间表)”、“Content(内容)”和“PurchaseItem(购买项)”分段在内的其它分段所参考的中央集线器。除此之外，“Service”分段还可以参考“PreviewData(预览数据)”分段。“Service”分段可以不被这些分段参考，或者被这些分段中的若干个参考。与相关联的分段一起，终端可以在任意时间点确定与服务相关联的细节。这些细节可以综合为用户友好的显示，例如，关于消费了什么样的关联内容、怎样和何时消费关联内容以及花费是多少的显示。
访问分段231可以提供用于允许用户查看服务和传递方法的与访问相关的信息、以及与相应访问会话相关联的会话信息。如此，“Access”分段描述了在服务的生命周期期间如何访问服务。该分段包含或参考会话描述信息，并指示传递方法。一个或多个“Access”分段可以参考“Service”分段，并提供用于访问关联服务或与关联服务交互的备选方式。对于终端，“Access”分段提供关于需要终端具备何种能力来接收和渲染服务的信息。“Access”分段以嵌入式文本或通过URI形式的打印机将会话描述参数提供给单独的会话描述。可以通过广播频道或交互频道来传递会话描述信息。
会话描述分段232可以包括在访问分段231中，并且可以以统一资源标识符(URI)形式提供位置信息，从而终端可以检测会话描述分段232上的信息。会话描述分段232可以提供关于存在于会话中的多媒体内容的地址信息、编解码器信息等。如此，“SessionDescription(会话描述)”是提供用于访问服务或内容项的会话信息的服务指南分段。此外，会话描述可以提供用于关联传递过程的辅助描述信息。使用文本格式的SDP的语法或通过3GPP MBMS用户服务包描述[3GPP TS 26.346](USBD)来提供会话描述信息。以XML格式提供辅助描述信息，并且该信息包含在[BCAST10-分布]中规定的关联传递描述。应注意，在使用SDP语法的情况下，传递会话描述的备选方式是将文本格式的SDP封装在“访问”分段中。应注意，会话描述可以用于服务指南传递本身以及用于内容会话两者。
购买项分段211可以提供服务、内容、时间等的包，以帮助用户对购买项分段211进行订阅或购买。如此，“PurchaseItem”分段表示免费提供给终端用户以用于订阅和/或购买的一个或多个服务的组(即，服务包)或者一个或多个内容项。该分段可以被提供关于不同服务包的更多信息的“PurchaseData(购买数据)”分段参考。“PurchaseItem”分段还可以与以下项相关联：(1)用于实现打包的服务订阅的“Service”分段和/或，(2)用于实现消费特定时间帧中的特定服务或内容(付费观看功能)的“Schedule”分段，和/或(3)用于实现购买与服务相关的单个内容文件的“Content”分段，(4)用于实现购买项的打包的其它“PurchaseItem”分段。
购买数据分段212可以包括用于服务或内容包的详细的购买和订阅信息，例如价格信息和促销信息。购买频道分段213可以提供用于订阅或购买的访问信息。如此，“PurchaseData”分段的主要功能在于展示关于关联购买项的所有可用价格信息。“PurchaseData”分段收集关于一个或多个购买频道的信息，并且可以与针对特定服务或服务包的预览数据相关联。“PurchaseData”分段携带关于服务、服务包或内容项的价格的信息。此外，关于促销活动的信息可以包括在该分段中。SGDD还可以提供关于作为容器的SGDU的与用于接收服务指南和分组信息的进入点相关的信息。
预览数据分段241可以用于提供服务、时间表和内容的预览信息。如此，“PreviewData”分段包含由终端用于向用户呈现服务或内容概要的信息，从而用户可以大致了解服务或内容关于什么。“PreviewData”分段可以包括简单文本、静止图像(例如，标志)、短视频剪辑、或者甚至参考可能是针对主服务的低比特率版本的另一服务。“Service”、“Content”、“PurchaseData”、“Access”和“Schedule”分段可以参考“PreviewData”分段。
交互性数据分段251可以用于在广播期间根据服务、时间表和内容提供交互服务。可以由系统的一个或多个元素和属性来定义关于服务指南的更详细的信息。如此，交互性数据包含由终端用于向用户提供交互服务的与广播内容相关联的信息。这些交互服务使得用户能够例如在TV节目期间进行投票或者获得与广播内容相关的内容。“InteractivityData(交互性数据)”分段指向一个或多个“交互性媒体”文档，该文档包括xhtml文件、静止图像、电子邮件模板、SMS模板、MMS模板文档等。“InteractivityData”分段可以参考“Service”、“Content”和“Schedule”分段，并且可以被“时间表”分段参考。
“Schedule”分段定义关联内容项可用于流传输、下载和/或渲染的时间帧。该分段参考“Service”分段。如果其还参考一个或多个“Content”分段或“InterativityData”分段，则其定义属于服务的这些内容项的有效分布和/或呈现时间帧、或者与服务相关联的交互性媒体文档的自动激活时间和有效分布时间帧。另一方面，如果“Schedule”分段不参考任何“Content”分段或“InteractivityData”分段，则其定义无界的服务可用性的时间帧。
“Content”分段给出对特定内容项的详细描述。除了定义内容的类型、描述和语言之外，“Content”分段还可以提供关于目标用户组或地理区域的信息以及种类和家长评级。“Content”分段可以被“Schedule”、“PurchaseItem”或“InteractivityData”分段参考。其可以参考“PreviewData”分段或“Service”分段。
“PurchaseChannel(购买频道)”分段携带与可以获得针对在“PurchaseData”分段中定义的特定服务、服务包或内容项的购买权和/或内容权的实体相关的信息。购买频道与一个或多个广播订阅管理(BSM)相关联。终端仅在附属于与特定购买频道相关联的BSM的情况下才被允许访问该购买频道。多个购买频道还可以关联于一个“PurchaseData”分段。特定终端用户可以具有所有购买请求均被指向到的“优选”购买频道(例如，他/她的移动运营商)。优选购买频道甚至可以是终端被允许使用的唯一频道。
在服务指南公告频道上传输ServiceGuideDeliveryDescriptor(服务指南传递描述符)，其向终端通知服务指南发现处理中的服务指南的分段的可用性、元数据和分组。SGDD允许对在终端中缓存或者发送的服务指南分段的快速识别。为此，如果被分布在广播频道上，则优选重复SGDD。SGDD还提供对相关服务指南分段的分组，从而提供确定这种组的完整性的方式。在终端从一个服务覆盖区域移动到另一个服务覆盖区域的情况下，服务指南传递描述符尤其有用。在此情况下，服务指南传递描述符可以用于快速检查在先前服务覆盖区域中接收到的服务指南分段在当前服务覆盖区域中是否仍然有效，从而不需要被重新解析或重新处理。
虽然没有明确地绘出，但是构成服务指南的分段可以包括用于实现其目的的元素和属性值。此外，根据需要，可以省去服务指南的一个或多个分段。此外，根据需要，可以组合服务指南的一个或多个分段。此外，根据需要，可以将服务指南的一个或多个分段的不同方面组合在一起、重组或修改或者约束。
参照图3，示例性框图示出了服务指南传递技术的多个方面。服务指南传递描述符分段201可以包括与包含服务信息的所有分段相关的通知消息访问信息、会话信息和分组信息。当实现移动广播服务的终端105开启或者开始接收服务指南时，其可以访问服务指南公告频道(SG公告频道)300。
SG公告频道300可以包括至少一个SGDD 200(例如，SGDD#1、...、SGDD#2、SGDD#3)，其可以被格式化为任意合适的格式，例如在用于移动广播服务、开放移动联盟的服务指南(版本1.0.1、2013年1月9日)和/或在用于移动广播服务、开放移动联盟的服务指南(版本1.1、2013年10月29日)中说明的格式；这两者均以引用的方式完全并入本文。构成服务指南传递描述符分段201的元素和属性的描述可以反映为任意合适的格式，例如表格格式和/或可扩展标记语言(XML)架构。
根据SGDD分段201优选地以XML格式来提供实际数据。与服务指南相关的信息可以按照多种数据格式被提供，例如二进制，其中元素和属性根据广播系统被设置为相应的值。
终端105可以从在SG公告频道300上接收到的SGDD分段的描述条目获取与包含分段信息的服务指南传递单元(SGDU)312相关的传输信息。
可以提供服务指南的分组信息的描述条目302包括“GroupingCriteria(分组标准)”、“ServiceGuideDeliveryUnit(服务指南传递单元)”、“Transport(传输)”和“AlternativeAccessURI(备选访问URI)”。可以由“Transport”或“AlternativeAccessURI”提供与传输相关的频道信息，由“ServiceGuideDeliveryUnit”提供相应频道的实际值。此外，可以由“GroupingCriteria”提供关于SGDU 312的上层组信息，例如“Service”和“Genre”。终端105可以根据相应组信息接收所有SGDU 312并向用户呈现。
一旦获取了传输信息，终端105就可以访问从SG传递频道310上的SGDD 301中的描述条目302获取的所有传递频道，以接收实际SGDU312。可以使用“GroupingCriteria”来识别SG传递频道。在时间分组的情况下，可以利用基于时间的传输频道(例如以小时为单位的SG频道311和以天为单元的SG频道)来传输SGDU。因此，终端105可以选择性地访问频道并接收相应频道上存在的所有SGDU。一旦在SG传递频道310上完整地接收到整个SGDU，则终端105检查在SG传递频道310上接收到的SGDU中包含的所有分段，并且聚集分段以在屏幕上显示实际的完全服务指南320，该服务指南可以以小时为单位321被再划分。
在传统的移动广播系统中，服务指南以仅配置的终端接收相应广播系统的广播信号的方式被格式化并被发送。例如，由DVB-H系统发送的服务指南信息可以仅由被配置为接收DVB-H广播的终端接收。
服务提供方根据服务汇聚(可以被称为多播服务)使用多种发送系统以及多种广播系统提供打包和集成的服务。广播服务提供方还可以在IP网络上提供广播服务。可以使用在3GPP标准和OMA BCAST标准(例如，方案)中定义的实体来描述集成的服务指南发送/接收系统。然而，服务指南发送/接收系统可以与任意合适的通信和/或广播系统一起使用。
参照图4，方案可以包括：例如(1)名称(Name)；(2)类型(Type)；(3)类别(Category)；(4)基数(Cardinality)；(5)描述(Description)；以及(6)数据类型(Datatype)。该方案可以布置为任意方式，例如表格格式或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个值。“描述”栏描述了相应元素或属性的含义，“数据类型”栏指示相应元素或属性的数据类型。
服务可以表示内容项的包，其形成针对终端用户的逻辑组。一个示例是由若干TV节目构成的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”来用信号通知用于表示该元素的值的语言，并且该语言可以包括多语言支持。针对元素“AudioLanguage”所指定的指派和解释属性“languageSDPTag”和“xml：lang”的相同规则和约束可以应用于该元素。
“languageSDPTag”属性是由在会话描述中的描述文本轨迹的媒体部分中所使用的父“TextLanguage”元素描述的文本语言的标识符。
“ParentalRating”元素可以声明标准家长，并可以用于根据服务区域的规定要求的限定来确定关联项目是否适合于被儿童访问。终端可以支持“ParentalRating”作为自由字符串，并且终端可以通过使用“ratingSystem(评级系统)”和“ratingValueName(评级值名称)”属性来支持用于表达家长评级水平的结构化方式。
“ratingSystem”属性可以指定所使用的家长评级系统，在其上下文中在语义上定义了“ParentalRating”元素的值。这允许终端以毫无疑义的方式来识别所使用的评级系统并正确地操作。当使用评级系统时，可以将该属性实例化。缺少该属性意味着没有使用评级系统(即，“ParentalRating”元素的值将被解释为自由字符串)。
“ratingValueName”属性可以指定由该ParentalRating元素给出的评级值的人类可读名称。
“TargetUserProfile”可以指定服务所针对的用户的元素。详细个人属性名称和相应值由“attributeName(属性名称)”和“attributeValue(属性值)”的属性来指定。可用的简档属性名称包括年龄、性别、职业等(受限于国家/地区规则和规章(如果有的话)，并且适用于有关个人简档信息和个人数据隐私的使用)。针对特定服务的“attributeName”和“属性值”配对的可扩展列表实现对广播服务的终端用户简档过滤和终端用户偏好过滤。终端可以支持“TargetUserProfile”元素。使用“TargetUserProfile”元素可以是针对用户的“可选”能力。终端设置可以允许用户配置是否输入它们的个人简档或偏好以及是否允许广播服务在没有用户请求的情况下基于用户个人属性被自动过滤。该元素可以包含以下属性：attributeName和属性值attributeValue。
“attributeName”属性可以是简档属性名称。
“attributeValue”属性可以是简档属性值。
“Genre”元素可以指定与特征形式(例如，喜剧、电视剧)相关联的服务的分类。OMABCAST服务指南可以允许以两种方式描述服务指南中的种类元素的格式。第一种方式是使用自由字符串。第二种方式是使用种类元素的“href”属性，以按照受控制词汇(在[TVA-元数据]中定义的分类方案或在[MIGFG]中定义的分类列表)的形式来传达信息。可以利用该元素使用嵌入式XML属性xml：lang来表达语言。网络可以将“Genre”元素的若干不同集合实例化，将其用作自由字符串或用于“href”属性。网络可以确保不同集合具有等同和非冲突的意义，并且该终端可以选择集合之一来向终端用户进行解释。“Genre”元素可以包含以下属性：类型和href。
“type”属性可以例如利用“主要”、“次要”和“其它”之类的值来用信号通知“Genre”元素的级别。
“href”属性可以用信号通知在“种类”元素中使用的受控制词汇。
在检查了节目指南元素和属性的集合：(1)Name；(2)Description；(3)AudioLanguage；(4)TextLanguage；(5)ParentalRating；(6)TargetUserProfile；以及(7)Genre之后，确定接收设备仍然不具有在节目指南中定义的足够信息来按照适合于观看者的方式正确地渲染信息。具体地，传统的NTSC电视台一般具有例如2、4、6、8、12和49之类的号码。对于数字服务，节目和系统信息协议包括虚拟频道表，该虚拟频道表针对地面广播利用由主频道及随后的副频道构成的两部分号码来定义每个数字电视服务。主频道号通常与电视台的NTSC频道相同，副频道号取决于在数字电视中存在了多少个数字电视服务，通常开始于1。例如，华盛顿特区中的WUSA-TV的模拟电视频道9可以将其两个空中数字服务识别为以下：频道9-1 WUSA-DT和频道9-2 9-Radar。电视频道的该标注可以易于观看者的理解，并且节目指南元素可以包括该能力作为节目指南的扩展，从而该信息可以在计算上高效地被接收设备处理并且向观看者渲染。
参照图5，为了实现这种灵活性，可以在可指定更多服务的节目指南元素中包括诸如服务媒体扩展的扩展。具体地，服务媒体扩展可以具有类型元素E1、类别NM/TM以及基数1。主频道可以指MajorChannelNum，其类型元素为E2、类别为NM/TM、基数为0..1以及数据类型为字符串。通过包括字符串而非unsignedByte(无符号字节)的数据类型，能够支持不必须是数字的其它语言。包括服务媒体扩展的节目指南信息可以包括在任意合适的广播系统(例如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的扩展。
在其它实施例中，除了使用数据类型“string(字符串)”用于主频道号(MajorChannelNum)和副频道号(MinorChannelNum)元素之外，还可以使用其它数据类型。例如，可以使用数据类型unsignedInt。在另一示例中，可以使用有限长度的字符串，例如，10位的字符串。用于以上扩展的示例性XML架构语法在下文示出。
在一些实施例中，服务媒体扩展可以包括在OMA“extension(扩展)”元素内，或者可以总体使用OMA扩展机制来定义服务媒体扩展。
在一些实施例中，MajorChannelNum和MinorChannelNum可以被组合为一个公共的频道号并被表示。例如，可以通过级联MajorChannelNum、随后是句点(“.”)、随后是MinorChannelNum，来创建ChannelNum字符串。用其它字符代替时间段的其它这种组合也是可行的。在将MajorChannelNum和MinorChannelNum组合为一个号码表示这方面，当使用unsignedInt或其它数据类型来表示频道号时，可以应用类似的构思。
在另一实施例中，MajorChannelNum.MinorChannelNum可以被表示为针对服务的“ServiceId”元素(服务Id)。
在另一实施例中，服务媒体扩展应仅用于服务分段内的PrivateExt元素内。用于这种扩展的示例性XML架构语法在下文中示出。
＜element name＝″ServiceMediaExtension″type＝″SerExtensionType″＞
＜annotation＞
＜documentation＞
该元素是用于对OMA BCAST SG服务分段的扩展的封套。其应仅用在服务分段内的PrivateExt元素内。
在其它实施例中，以上元素中的一些可以从E2改变为E1。在其它实施例中，可以改变一些元素的基数。此外，如果需要，则可以省去类别，因为其总体上与包括在基数中的信息重复。
期望将ATSC服务元素和属性的选定分量映射到OMA服务指南服务分段节目指南。例如，OMA服务指南分段节目指南的“Description”属性可以被映射到ATSC服务元素和属性(例如ATSC-移动DTV标准，部分4-公告、用于类似元素和属性的其它类似的广播或移动标准)的“Description”。例如，OMA服务指南分段节目指南的“Genre”属性可以被映射到ATSC服务元素和属性(例如ATSC-移动DTV标准，部分4-公告、用于类似元素和属性的其它类似标准)的“种类”。在一个实施例中，可以利用在ATSC A153/部分4的章节6.10.2中定义的种类方案。例如，OMA服务指南分段节目指南的“种类”属性可以被映射到ATSC服务元素和属性(例如ATSC-移动DTV标准，部分4-公告、用于类似元素和属性的其它类似标准)的“Genre”。优选地，将名称的基数选为0..N，这样能够省去名称，从而减少系统的整体比特率并增加灵活性。例如，OMA服务指南分段节目指南的“ParentalRating”属性可以被映射到ATSC服务元素和属性(例如ATSC-移动DTV标准，部分4-公告或用于类似元素和属性的类似标准)的新“ContentAdvisory(内容建议)”。例如，OMA服务指南分段节目指南的“TargetUserProfile”属性可以被映射到ATSC服务元素和属性(例如ATSC-移动DTV标准，部分4-公告、或用于类似元素和属性的类似标准)的新“个性化”。
参照图9A、图9B和图9C，如果会话描述分段包括在服务公告(例如ATSC-移动DTV标准，部分4-公告或用于类似元素和属性的类似标准)中，则可以包括元素“AudioLanguage(属性为languageSDPTag)”和“
TextLanguage(属性为languageSDPTag)”。这是因为元素AudioLanguage和TextLanguage的属性“languageSDPTag”优选为强制的。该属性为在会话描述中的描述音频/文本轨迹的媒体部分中所使用的父元素所描述的音频/文本语言提供标识符。在另一实施例中，属性“languageSDPTag”可以是可选的，并且元素AudioLanguage和TextLanguage可以包括在属性“language”中，其中数据类型“string”可以提供语言名称。
用于此的示例XML架构语法在下文示出。
在另一实施例中，可以移除元素“AudioLanguage”和“TextLanguage”的属性“languageSDPTag”。用于此的示例XML架构语法在下文示出。
参照图10A、图10B和图10C，如果会话描述分段包括在服务公告(例如ATSC-移动DTV标准，部分4-公告或用于类似元素和属性的类似标准)中，则可以包括元素“AudioLanguage(属性为languageSDPTag)”和“TextLanguage(属性为languageSDPTag)”。这是因为元素AudioLanguage和TextLanguage的属性“languageSDPTag”优选为强制的。该属性为在会话描述中的描述音频/文本轨迹的媒体部分中所使用的父元素所描述的音频/文本语言提供标识符。在另一实施例中，属性“languageSDPTag”可以是可选的。
用于此的示例XML架构语法在下文示出。
在另一实施例中，可以移除用于元素“AudioLanguage”和“TextLanguage”的属性“languageSDPTag”。用于此的示例XML架构语法在下文示出。
在另一实施例中，属性“language”可以映射到ATSC服务“language”元素，并且可以表示服务的主语言。
在另一实施例中，元素“AudioLanguage”的值可以映射到ATSC服务“语言”元素，并且可以表示ATSC中的音频服务的主语言。
在另一实施例中，元素“TextLanguage”的值可以映射到ATSC服务“语言”元素，并且可以表示ATSC中的文本服务的主语言。在一些情况下，文本服务可以是诸如隐藏字幕服务之类的服务。在另一实施例中，可以移除元素“AudioLanguage”和“TextLanguage”以及它们的属性。
针对服务指南，传统上考虑参考音频-视频内容的线性流，一般被称为“线性服务”。随着应用(还称为“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没有指示它们的存在时易于被省去，进而减小比特流的复杂度。
在另一实施例中，可以定义附加的ServiceType值，而不是将通知映射到用于OMAServiceType的值7。OMA服务指南分段节目指南的通知ServiceType元素227可以用于标识包括要使用的包含通知流分量的应用分量在内的“基于APP的服务”。
应理解，可以类似地使用其它值用于所描述的服务。例如，除了上文的服务类型值224、225、226和227，可以使用服务类型值240、241、242和243。在另一情况下，可以使用服务类型值129、130、131、132作为替代。
在作为替代的另一实施例中，如果使用来自保留为专用的范围(128-255)中的ServiceType值，则可以使用来自保留为将来使用的范围(11-127)中的值。
在作为替代的使用OMA BCAST指南1.1的另一实施例中，如果使用来自保留为专用的范围(128-255)中的ServiceType值，则可以使用来自保留为将来使用的范围(14-127)中的值。
在作为替代的使用OMA BCAST指南1.1的另一实施例中，如果使用来自保留为专用的范围(128-255)中的ServiceType值，则可以使用来自保留用于其它OMA使能器的范围(128-223)中的值。
在作为替代的使用OMA BCAST指南1.1的另一实施例中，如果使用来自保留为专用的范围(128-255)中的ServiceType值，则可以将值限制在保留用于其它OMA使能器的范围(224-255)中。
在另一实施例中，例如，可以使用附加ServiceType元素值228来标识“线性服务”。例如，附加ServiceType元素值229可以用于标识包括基于一般化应用的增强在内的“基于APP的服务”。以这种方式，通过不显式地包括用于应用分量、非实时内容、非按需分量的服务，来简化服务标记。
在另一实施例中，例如，附加或备选ServiceType元素值230可以用于标识包括基于应用的增强在内的“基于APP的服务”。以这种方式，通过不显式地包括用于线性服务、应用分量、非实时内容、非按需分量的服务，来进一步简化通知。
在另一实施例中，例如，还可以使用ServiceType元素值1来标识“线性服务”。以这种方式，线性元素合并在现有语法结构中。在此情况下，“线性服务”映射到基础TV服务。
在另一实施例中，例如，ServiceType元素值11可以用于标识流传输按需分量，该分量可以是具有包括按需分量在内的基于app的增强的基于app的服务。例如，ServiceType元素值12可以用于标识文件下载按需分量，该分量可以是包括非实时内容项分量在内的基于app的增强。
在另一实施例中，以上服务类型值中的任意一个可以由另一元素内的值来表示。例如，可用内容元素或属性及其值可以采用应用分量、非实时内容、按需分量和/或通知的值之一。
在另一实施例中，可以分层地进行ServiceType值分配。例如，主服务类型可以是线性服务和基于app的服务，并且这两种类型的服务中的每种可以包括零个或更多个基于app的增强分量，该分量可以包括应用分量、非实时内容、按需分量和/或通知，并且可以执行对ServiceType值的分层分配。在此情况下，针对“ServiceType”，“unsigned Byte”(ServiceType的数据类型)的比特之一可以用于用信号通知线性服务(比特值被设置为1)或基于app的服务(比特值被设置为0)。然后剩余比特可以用信号通知服务类型。
一个示例如下所示：
224(11100000二进制)具有包括应用分量在内的基于App的增强的线性服务
240(11110000二进制)具有包括应用分量在内的基于App的增强的基于App的服务
225(11100001二进制)具有包括非实时内容在内的基于App的增强的线性服务
241(111100001二进制)具有包括非实时内容在内的基于App的增强的基于App的服务
226(11100010二进制)具有包括按需分量在内的基于App的增强的线性服务
242(11110010二进制)具有包括按需分量在内的基于App的增强的基于App的服务
227(11100011二进制)具有包括通知流分量在内的基于App的增强的线性服务
243(11110011二进制)具有包括通知流分量在内的基于App的增强的基于App的服务
228(11100100二进制)具有广义服务类型的线性服务
243(11110100二进制)具有广义服务类型的基于App的服务
广义服务类型可以表示与具有应用分量或非实时内容或按需分量的服务不同的服务。在一些情况下，广义服务类型可以是“未知”服务类型。
在另一实施例中，值可以使用连续的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(Primary App)可以是一旦选择了底层服务时就被激活的app。此外，可以在服务中稍后启动非主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可以向发送服务提供方1200发送针对服务的频道传递请求1220。在一个示例中，接收机1240可以从发送服务提供方1200接收对频道的传递。
图13A-图13B示出了用于分量信息描述符的二进制语法。
图13B与图13A相比包括更少的语法元素，因此可以被发送服务提供方1100更容易地发送并且可以被接收机1140更容易地解析和解码。
图13A和图13B的分量信息描述符提供与在服务中可用的分量相关的信息。其包括与在服务中可用的分量数目相关的信息。对于每个可用分量，用信号通知以下信息：分量类型、分量角色、分量名称、分量标识符、分量保护标记。可以用信号通知音频、视频、隐藏字幕和应用分量。针对音频、视频和隐藏字幕分量来定义分量角色值。
分量信息描述符的语法应该符合图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＝保留，
15＝未知
当上述component_type字段在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()-以“英语”为语言的分量的短可读名称。它们的每个字符可以按照UTF-8被编码。
参照图13A、图13B、图14A、图14B，描述符的格式栏可以如下解释：
TBD：意味着按照以上描述待定。
uimsbf：意味着无符号整数，最高有效位在先，
bslbf标识比特串，左位在先。
图14A至图14B示出了用于频道信息描述符的二进制语法。图14A和图14B的频道描述符提供与服务中的频道相关的信息。其包括主频道号、副频道号、主频道语言、频道种类、频道描述(以多种语言)和频道图标。
频道描述符的语法应该符合图14A或图14B中示出的语法。在另一实施例中，可以仅在频道描述符或一些其它描述符或一些其它数据结构中用信号通知其中的一些元素，而不是频道描述符中的全部。
图14A和图14B的频道描述符中的语法元素的语义如下所示。
descriptor_tag-这是用于标识该描述符的8位无符号整数。可以用信号通知唯一地标识该描述符的在0-255之间的任意合适值。在一个实施例中，该字段的格式可以是uimsbf。在另一实施例中，可以使用基于该descriptor_tag值而与其它描述符相比唯一地标识描述符的一些其它格式。
descriptor_lenth-该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获得的名为“Codes for the representation of names of languages—Part 3：Alpha-3 code for comprehensive coverage of languages”的ISO 639-3中的3字母代码之一，其整体通过引用合并于此。在其它实施例中，可以定义语言的预定义列表，并且该字段可以是插入这些字段的列表中的索引。在备选实施例中，针对该字段可以使用16比特，因为可以表示的语言数目的上限为26×26×26(即，17576)或者17576-547＝17030。
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-移动DTV标准，部分4-公告)”的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()-服务的短描述。用“英语”或者用由该描述符中的service_lang_code字段的值所识别的语言。它们的每个字符可以按照UTF-8被编码。
icon_url_length和service_descriptor_length的值被约束为由提供与该整个描述符的长度相关的信息的descriptor_length字段的值所指定。
参照图14B，附加语法元素如下：
ext_channel_info_present_flag-该1位布林(boolean)标记可以指示：当被设置为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架构。
虽然图13至图18示出了语法、语义和架构的具体实施例，但是其他的变量也是可行的。这些变量包括以下变化：
与以上示出的相比，可以针对元素使用不同的数据类型。例如，可以使用unsignedShort数据类型来替代unsignedByte数据类型。在另一示例中，可以使用String(字符串)数据类型来替代unsignedByte数据类型。
作为用信号通知语法作为属性的替代，其可以被信号通知为元素。作为用信号通知语法作为元素的替代，其可以被信号通知为属性。
可以改变各种字段的比特宽度，例如针对比特流语法中的元素，可以使用5位、8位或2位来替代4位。这里列出的实际值仅仅是示例。
可以使用JavaScript对象符号(JSON)格式和JSON架构来替代XML格式和XML架构。备选地，可以使用逗号分隔值(CSV)、巴科斯范式(BNF)、增强巴科斯范式(ABNF)或扩展巴科斯范式(EBNF)来用信号通知提出的语法元素。
可以改变元素和/或属性的基数。例如基数可以从“1”至“1..N”改变，或者基数可以从“1”至“0..N”改变，或者基数可以从“1”至“0..1”改变，或者基数可以从“0..1”至“0..N”改变，或者基数可以从“0..N”至“0..1”改变。
当在上文被示出为可选时，可以使元素和/或属性变为必要。当在上文被示出为必要时，可以使元素和/或属性变为可选。
一些子元素可以替代地被信号通知为父元素，或者它们可以被信号通知为其它子元素的子元素。
以上所有变量预期包括在本发明的范围内。
应理解，权利要求不限于以上示出的确切配置和组件。在不脱离权利要求的范围的情况下，可以对这里描述的系统、方法和装置的布置、操作和细节进行修改、改变和变化。

Claims (1)

1.一种由解码器对与包括媒体比特流的广播服务相关联的服务指南进行解码的方法，所述方法包括：
(a)由所述解码器接收所述服务指南中的服务分段，其中所述服务分段是包括在广播服务中的内容的上聚集并且包括关于服务内容、种类、服务位置的信息；
(b)由所述解码器接收所述服务分段中的服务媒体扩展；
(c)由所述解码器接收所述服务媒体扩展中的主频道号，其中所述主频道号的数据类型是字符串；
(d)由所述解码器接收所述服务媒体扩展中的副频道号，其中所述副频道号的数据类型是字符串；
(e)由所述解码器接收所述服务媒体扩展中的图标元素，其中所述图标元素是指向不同宽度和高度的图标的多个URL；以及
(f)由所述解码器对包括所述服务媒体扩展、所述主频道号、所述副频道号和所述图标元素在内的所述服务指南进行解码。
CN201580014531.9A 2014-04-21 2015-04-20 用于解码服务指南的方法 Active CN106105249B (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201461982158P 2014-04-21 2014-04-21
US61/982,158 2014-04-21
US201562137797P 2015-03-24 2015-03-24
US62/137,797 2015-03-24
PCT/JP2015/002150 WO2015162903A1 (en) 2014-04-21 2015-04-20 A method for decoding a service guide

Publications (2)

Publication Number Publication Date
CN106105249A CN106105249A (zh) 2016-11-09
CN106105249B true CN106105249B (zh) 2019-07-26

Family

ID=54332081

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201580014531.9A Active CN106105249B (zh) 2014-04-21 2015-04-20 用于解码服务指南的方法

Country Status (4)

Country Link
US (2) US9882665B2 (zh)
CN (1) CN106105249B (zh)
CA (1) CA2939894C (zh)
WO (1) WO2015162903A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3139623A4 (en) * 2014-04-27 2017-10-11 LG Electronics Inc. Broadcast signal transmitting apparatus, broadcast signal receiving apparatus, method for transmitting broadcast signal, and method for receiving broadcast signal
WO2017154633A1 (en) * 2016-03-09 2017-09-14 Sharp Kabushiki Kaisha Methods and systems for usage reporting

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101243701A (zh) * 2005-08-17 2008-08-13 三星电子株式会社 用于在广播系统中提供通知消息的方法和装置
CN101411103A (zh) * 2006-02-03 2009-04-15 三星电子株式会社 用于在移动广播系统中共享服务指南或服务指南片段的方法和系统
CN102090040A (zh) * 2008-06-07 2011-06-08 相干逻辑公司 传输和接收供多媒体流使用的控制信息

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7051357B2 (en) * 1999-05-28 2006-05-23 Intel Corporation Communicating ancillary information associated with a plurality of audio/video programs
KR100978277B1 (ko) * 2005-11-07 2010-08-26 삼성전자주식회사 휴대 방송 시스템에서 서비스 가이드 생성을 위한 공급 정보 전달 방법과 통지 이벤트/통지 메시지 전달 방법 및 시스템
US20090253416A1 (en) * 2008-04-04 2009-10-08 Samsung Electronics Co. Ltd. Method and system for providing user defined bundle in a mobile broadcast system
US20100037258A1 (en) * 2008-08-07 2010-02-11 Research In Motion Limited Mobile broadcasting system and method for enhancing mobile broadcasting services with rich media including an enhanced service guide
KR101593569B1 (ko) * 2009-02-02 2016-02-15 삼성전자주식회사 콘텐츠 오브젝트 구성 방법 및 시스템

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101243701A (zh) * 2005-08-17 2008-08-13 三星电子株式会社 用于在广播系统中提供通知消息的方法和装置
CN101411103A (zh) * 2006-02-03 2009-04-15 三星电子株式会社 用于在移动广播系统中共享服务指南或服务指南片段的方法和系统
CN102090040A (zh) * 2008-06-07 2011-06-08 相干逻辑公司 传输和接收供多媒体流使用的控制信息

Also Published As

Publication number Publication date
WO2015162903A1 (en) 2015-10-29
US9882665B2 (en) 2018-01-30
US20170070306A1 (en) 2017-03-09
CA2939894A1 (en) 2015-10-29
US10389461B2 (en) 2019-08-20
CA2939894C (en) 2019-05-21
US20180109342A1 (en) 2018-04-19
CN106105249A (zh) 2016-11-09

Similar Documents

Publication Publication Date Title
US11218235B2 (en) Method for decoding a service list table
US20100180310A1 (en) Rich media-enabled service guide provision method and system for broadcast service
TWI639349B (zh) 廣播識別符傳訊
CA2977718C (en) Service signaling extensions
CA2748940A1 (en) Rich media-enabled service guide provision method and system for broadcast service
CN106105249B (zh) 用于解码服务指南的方法
CA3081282C (en) Service list
US10645446B2 (en) Service guide encapsulation
US10939144B2 (en) Signaling ratings information
CA2948786C (en) A method for decoding a service guide
US11722734B2 (en) Ratings information
US20200045381A1 (en) Signaling ratings information

Legal Events

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