CN109661821B - 用于用信号发送紧急警报消息的系统和方法 - Google Patents

用于用信号发送紧急警报消息的系统和方法 Download PDF

Info

Publication number
CN109661821B
CN109661821B CN201780054631.3A CN201780054631A CN109661821B CN 109661821 B CN109661821 B CN 109661821B CN 201780054631 A CN201780054631 A CN 201780054631A CN 109661821 B CN109661821 B CN 109661821B
Authority
CN
China
Prior art keywords
emergency
media
aea
syntax element
emergency alert
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
CN201780054631.3A
Other languages
English (en)
Other versions
CN109661821A (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 CN109661821A publication Critical patent/CN109661821A/zh
Application granted granted Critical
Publication of CN109661821B publication Critical patent/CN109661821B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8126—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts
    • H04N21/814—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts comprising emergency warnings
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/53—Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers
    • H04H20/59—Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers for emergency or urgency
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614—Multiplexing of additional data and video streams
    • 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/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/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/4348—Demultiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/488—Data services, e.g. news ticker
    • H04N21/4882—Data services, e.g. news ticker for displaying messages, e.g. warnings, reminders
    • 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835—Generation of protective data, e.g. certificates
    • H04N21/8358—Generation of protective data, e.g. certificates involving watermark
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H2201/00—Aspects of broadcast communication
    • H04H2201/50—Aspects of broadcast communication characterised by the use of watermarks

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • Emergency Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Alarm Systems (AREA)

Abstract

一种设备，其可以被配置为接收来自广播流的低级别信令紧急警报消息片段。该设备可以对包括在紧急警报消息片段中的语法元素进行解析。该设备可以基于所解析的语法元素来确定是否检索与紧急警报消息相关联的媒体资源。

Description

用于用信号发送紧急警报消息的系统和方法
技术领域
本公开涉及交互式电视领域。
背景技术
数字媒体播放能力可以包含在广泛范围的设备之中，其包括数字电视——包括所谓的“智能”电视、机顶盒、笔记本电脑或台式电脑、平板电脑、数字记录设备、数字媒体播放器、视频游戏设备、蜂窝电话——包括所谓的“智能”电话、专用视频流设备等。数字媒体内容(例如视频和音频节目)可以源自多个源，其包括例如空中电视提供者、卫星电视提供者、有线电视提供者、在线媒体服务提供者——包括所谓的流媒体服务提供者等。数字媒体内容可以通过其包括诸如因特网协议(IP)网络的双向网络以及诸如数字广播网络的单向网络的分组交换网络传递。
可以根据传输标准将数字媒体内容从源传送到接收器设备(例如数字电视或智能电话)。传输标准的示例包括数字视频广播(DVB)标准、综合业务数字广播标准(ISDB)标准、以及由高级电视系统委员会(ATSC)所开发的标准，包括例如ATSC 2.0标准。ATSC目前正在开发所谓的ATSC 3.0标准套件。ATSC 3.0标准套件旨在通过各种递送机制支持广泛范围的各种服务。例如，ATSC 3.0标准套件旨在支持广播多媒体递送——所谓的广播流——和/或文件下载多媒体递送——所谓的宽带流——和/或文件下载多媒体递送及其组合(即“混合服务”)。预期用于ATSC 3.0标准套件的混合服务的示例包括接收空中视频广播(例如通过单向传输)并且通过分组交换网络(即通过双向传输)接收来自在线媒体服务提供者的同步辅助音频呈现(例如辅助语言)。除了定义如何将数字媒体内容从源传送到接收器设备之外，传输标准还可以指定如何将紧急警报消息从源传递到接收器设备。用于传递紧急警报消息的当前技术可能不太理想。
发明内容
本发明的一个方面是一种用于用信号发送与紧急警报消息相关联的信息的方法，该方法包括：
用信号发送指示包括在紧急警报消息中的紧急事件描述符的数量的语法元素；以及
针对所指示数量的紧急警报描述符中的每一个，用信号发送指示紧急事件描述符的长度的语法元素。
本发明的一个方面是一种用于用信号发送与水印有效载荷中的紧急警报消息相关联的信息的设备，该设备包括一个或多个处理器，这一个或多个处理器被配置为：
用信号发送指示包括在紧急警报消息中的紧急事件描述符的数量的语法元素；以及
针对所指示数量的紧急事件描述符中的每一个用信号发送指示紧急事件描述符的长度的语法元素，其中指示紧急事件描述符的长度的语法元素包括6比特整型值，该6比特整型值加1指示紧急事件描述符的长度。
本发明的一个方面是一种用于生成紧急警报消息的描述符的方法，该方法包括：
接收紧急警报信息；
对指示包括在紧急警报消息中的紧急事件描述符的字节数的语法元素进行解析，其中指示紧急事件描述符的字节数的语法元素包括6比特整型值，该6比特整型值加1指示字节数；
对于所指示的字节数，对具有指示字符的值的字节进行解析；并且
使用所指示的字符生成紧急事件描述符。
本发明的一个方面是一种用于为紧急警报消息产生描述符的设备，该设备包括一个或多个处理器，这一个或多个处理器被配置为：
接收紧急警报信息；
对指示包括在紧急警报消息中的紧急事件描述符的字节数的语法元素进行解析，其中指示紧急事件描述符的字节数的语法元素包括6比特整型值，该6比特整型值加1指示出字节数；
对所指示的字节数的字节进行分析，每个字节具有指示字符的值；并且
使用所指示的字符生成紧急事件描述符。
附图说明
[图1]图1是用于对根据本公开的一个或多个技术的内容递送协议模型的示例进行说明的概念图。
[图2]图2是用于对可以实现本公开的一个或多个技术的系统的示例进行说明的方框图。
[图3]图3是用于对可以实现本公开的一个或多个技术的服务分发引擎的示例进行说明的方框图。
[图4]图4是用于对可以实现本发明的一个或多个技术的接收器设备的示例进行说明的方框图。
[图5]图5是用于对可以实现本发明的一个或多个技术的设备的示例进行说明的方框图。
[图6A]图6A是用于对示例性紧急警报消息的示例性模式进行说明的计算机程序列表。
[图6B]图6B是图6A的下一部分。
[图7A]图7A是用于对示例性紧急警报消息的示例性模式进行说明的计算机程序列表。
[图7B]图7B是图7A的下一部分。
具体实施方式
总体上，本公开描述了用于用信号发送(或发信令通知)紧急警报消息的技术。特别地，这里所述的技术可以用于用信号发送与包含在紧急警报消息之中的内容相关联的信息和/或与紧急警报消息相关联的其他信息。在一些情况下，接收器设备可以能够对与紧急警报消息相关联的信息进行解析并且使得数字媒体内容的呈现和/或渲染被修改，以便相应紧急消息警报对于用户更为明显。例如，如果信令信息指示出特定类型的内容的存在包含在紧急警报消息之中，则接收器设备可以被配置为关闭或临时暂停应用。应当注意的是尽管在一些示例中就紧急警报消息而言描述了这里所述的技术，但是这里所述的技术通常可以应用于其他类型的警报和消息。应当注意的是尽管在一些示例中就ATSC标准而言描述了这里所述的技术，但是这里所述的技术通常适用于任何传输标准。例如，这里所述的技术通常适用于任何DV B标准、ISDB标准、ATSC标准、数字地面多媒体广播(DTMB)标准、数字多媒体广播(DMB)标准、混合广播和宽带电视(HbbTV)标准、万维网同盟(W3C)标准、通用即插即用(UPnP)标准、及其他视频编码标准。此外，应该注意的是通过引用而将文献引入到这里是出于描述的目的并且不应该被解释为限制和/或产生就这里所使用的术语而言的歧义。例如，在一个引用的参考提供了与另一个引用的参考不同的术语定义的情况下和/或在这里使用术语时，该术语应该以广泛地包括每个相应定义的方式和/或以包括替代方案中的每个特定定义的方式解释。
传输标准可以定义如何将紧急警报从服务提供者传递到接收器设备。紧急警报典型地是由紧急机构产生并被传送到服务提供者。紧急机构可以被包括以作为政府机构的一部分。例如，紧急机构可以包括美国国家气象局、美国国土安全部、地方和区域机构(例如警察和消防部门)等。紧急警报可能包括与当前或预期紧急情况有关的信息。信息可以包括旨在进一步保护生命、健康、安全、以及财产的信息，并且可以包括与紧急情况及如何应对该紧急情况有关的重要细节。可能与紧急警报相关联的紧急类型的示例包括龙卷风、飓风、洪水、潮汐、地震、结冰条件、大雪、大范围火灾、有毒气体排放、大范围电源故障、工业爆炸、内乱、对即将发生的天气变化的告警和警戒等。
诸如例如电视广播公司(例如区域网络附属公司)、多频道视频节目分发商(MVPD)(例如有线电视服务运营商、卫星电视服务运营商、互联网协议电视(IPTV)服务运营商)等的服务提供者可以产生一个或多个紧急警报消息以分发给接收器设备。紧急警报和/或紧急警报消息可以包括文本(例如“恶劣天气警报”)、图像(例如天气图)、音频内容(例如告警音、音频消息等)、视频内容、和/或电子文档中的一个或多个。可以使用各种技术将紧急警报消息集成到多媒体内容的呈现之中。例如，紧急警报消息可以作为滚动条而“烧入(burned-i n)”到视频或与音频轨道混合，或者紧急警报消息可以在重叠的用户可控制窗口(例如弹出窗口)中呈现。此外，在一些示例中，紧急警报和/或紧急警报消息可以包括统一资源标识符(URI)。例如，紧急警报消息可以包括统一资源定位符(URL)，其用于标识可以获得与紧急情况有关的附加信息(例如视频、音频、文本、图像等)的位置(例如包括用于描述紧急情况的文档的服务器的IP地址)。用于接收包括URL的紧急警报消息(通过单向广播或通过双向宽带连接)的接收器设备可以获得用于描述紧急警报的文档，对该文档进行解析，并在显示器上显示包含在该文档之中的信息(例如产生滚动条并使滚动条重叠在视频呈现上，渲染图像，播放音频消息)。协议可以指定诸如例如基于超文本标记语言(HTML)、动态HTML、可扩展标记语言(XML)、JavaScript对象符号(JSON)、以及层叠样式表的用于使紧急警报消息格式化的一个或多个模式。在OASIS：“Common Alert ing Protocol”，1.2版，2010年7月1日(以下简称“CAP版本1.2”)中所描述的通用警报协议提供了如何根据XML模式来使紧急警报消息格式化的示例。此外，ANSI：“Emergency Alert Messaging for Cable”，J-STD-42-B，美国国家标准协会，2013年10月提供了如何根据模式来使紧急警报消息格式化的示例。
计算设备和/或传输系统可以基于包括一个或多个抽象层的模型，其中根据例如分组结构，调制方案等的特定结构来表示每个抽象层处的数据。包括定义的抽象层的模型的示例是图1所示的所谓开放系统互连(OSI)模型。OSI模型定义了7层堆栈模型，该7层堆栈模型包括应用层、表示层、会话层、传输层、网络层、数据链路层、以及物理层。应当注意的是就描述堆栈模型中的层而言术语“上”和“下”的使用可能基于应用层是最上层并且物理层是最下层。此外，在一些情况下，术语“层1”或“L1”可用于指物理层，术语“层2”或“L2”可用于指链路层，并且术语“层3”或“L3”或“IP层”可用于指网络层。
物理层通常可以指电信号形成数字数据的层。例如，物理层可以指用于定义调制射频(RF)符号如何形成数字数据帧的层。数据链路层(也可以称为链路层)可以指在发送侧的物理层处理之前及在接收侧的物理层接收之后所使用的抽象。如这里所使用的，链路层可以指用于在发送侧将数据从网络层传输到物理层并用于在接收侧将数据从物理层传输到网络层的抽象。应当注意的是发送侧和接收侧是逻辑角色并且单个设备可以在一个实例中作为发送侧并且在另一实例中作为接收侧进行操作。链路层可以封装在特定分组类型(例如运动图像专家组-传输流(MPEG-TS)分组、因特网协议版本4(IPv4)分组等)中的各种类型的数据(例如视频、音频、或应用文件)抽象成由物理层进行处理的单个通用格式。网络层通常可以指发生逻辑寻址的层。也就是说，网络层通常可以提供寻址信息(例如互联网协议(IP)地址、URL、URI等)以便数据分组可被递送到网络内的特定节点(例如计算设备)。如这里所使用的，术语网络层可以指链路层上方的层和/或具有使得其可以被接收以用于链路层处理的结构中的数据的层。传输层、会话层、表示层、以及应用层中的每一个可以定义如何递送数据以供用户应用使用。
传输标准，包括当前正在开发的传输标准，可以包括用于指定每层的支持协议的内容递送协议模型并且可以进一步定义一个或多个特定层实施方式。再次参考图1，说明了示例性内容递送协议模型。在图1所示的示例中，出于说明目的，内容递送协议模型100通常与7层OSI模型保持一致。应当注意的是这样的说明不应被解释为限制内容递送协议模型100和/或这里所述的技术的实施方式。内容递送协议模型100通常可以与ATSC 3.0标准套件的当前提出的内容递送协议模型相对应。此外，这里所述的技术可以是在其被配置为根据内容递送协议模型100进行操作的系统中实现的。
ATSC 3.0标准套件包括ATSC标准A/321，系统发现和信令文档，2016年3月23日(以下简称为“A/321”)，其全部内容通过引用被并入到本文。A/321描述了ATSC 3.0单向物理层实施方式的物理层波形的初始进入点。此外，目前正在开发的ATSC 3.0系列标准的方面在候选标准、其修订版、以及工作草案(WD)中进行了描述，其每一个都可能包括所提议的方面以包含在ATSC 3.0标准的已发布的(即“最终”或“已采用”)版本之中。例如，ATSC标准：物理层协议(Doc.S32-230r56，2016年6月29日，其全部内容通过引用被并入到本文)描述了所提议的用于ATSC 3.0的单向物理层。所提议的ATSC 3.0单向物理层包括物理层帧结构，该物理层帧结构包括定义的引导程序、前导码、以及其包括一个或多个物理层管道(PLP)的数据有效载荷结构。PLP通常可以指RF信道内的逻辑结构或RF信道的一部分。所提议的ATSC 3.0标准套件是指将RF信道作为广播流的抽象。所提议的ATSC 3.0标准套件进一步提供了由在其所属的广播流中是唯一的PLP标识符(PLPID)来标识PLP。也就是说，PLP可以包括具有特定调制和编码参数的RF信道的一部分(例如由地理区域和频率所标识的RF信道)。
所提议的ATSC 3.0单向物理层提供了单个RF信道可包含一个或多个PLP并且每个PLP可以携带一个或多个服务。在一个示例中，多个PLP可以携带单个服务。在所提议的ATSC3.0标准套件中，术语服务可以用于指聚合地呈现给用户的媒体组件的集合(例如视频组件、音频组件、以及子标题组件)，其中组件可以是多种媒体类型，其中服务可以是连续的或间歇的，其中服务可以是实时服务(例如与直播事件相对应的多媒体呈现)或非实时服务(例如视频点播服务、电子服务指南服务)，并且其中实时服务可以包括一系列电视节目。服务可以包括基于应用的特征。基于应用的特征可以包括服务组件，该服务组件包括应用、将由应用使用的可选文件、以及用于指示应用在特定时间采取特定动作的可选通知。在一个示例中，应用可以是构成增强或交互式服务的文档的集合。应用的文档可以包括HTML、JavaScript、CSS、XML、和/或多媒体文件。应当注意的是所提议的ATSC 3.0标准套件规定了在未来版本中可以定义新类型的服务。因而，如在这里所使用的，术语服务可以指相对于所提议的ATSC 3.0标准套件和/或其他类型的数字媒体服务所描述的服务。如上所述，服务提供者可以接收来自紧急机构的紧急警报并产生可以与服务一起分发到接收器设备的紧急警报消息。服务提供者可以产生其被集成到多媒体呈现之中的紧急警报消息，该紧急警报消息和/或产生其作为基于应用的增强的一部分的紧急警报消息。例如，紧急信息可以在视频中显示为文本(其可以被称为紧急屏幕上文本信息)，并且可以包括例如滚动条(其可以被称为爬取)。滚动条可以由接收器设备接收以作为烧入到视频呈现的文本消息(例如作为屏幕上紧急警报消息)和/或作为包含在文档中的文本(例如XML片段)。
参考图1，内容递送协议模型100支持通过使用用户数据报协议(UDP)和因特网协议(IP)上的MPEG媒体传输协议(MMTP)而通过ATSC广播物理层进行流传送和/或文件下载以及通过UDP和IP上的单向传输的实时对象递送(ROUTE)。在ISO/IEC：ISO/IEC 23008-1，““Information technology-High efficiency coding and mediadelivery inheterogeneous environments-Part 1:MPEG media transport(MMT)”中描述了MMTP。在ATSC候选标准：Signaling,Delivery,Synchronization,and Error Protection(A/331)Doc.S33-601r4，2016年6月21日，Rev.3，2016年7月20日(以下简称为“A/331”)中提供了对ROUTE的概述，其全部内容通过引用被并入到本文。
应当注意的是尽管ATSC 3.0在某些上下文中使用术语广播来指代单向空中传输物理层，但是所谓的ATSC 3.0广播物理层支持通过流传送或文件下载进行视频递送。因而，在这里所使用的术语“广播”不应用于限制可以根据本公开的一个或多个技术来传输视频和相关数据的方式。此外，内容递送协议模型100支持在ATSC广播物理层处的信令(例如使用物理帧前导码的信令)、在ATSC链路层处的信令(使用链路映射表(LMT)的信令)、在IP层处的信令(例如所谓的低级信令(LLS))、服务层信令(SLS)(例如使用MMTP或ROUTE中的消息的信令)、以及应用或表示层信令(例如使用视频或音频水印的信令)。
如上所述，所提议的ATSC 3.0标准套件支持在IP层处的信令，其被称为低级信令(LLS)。在所提议的ATSC 3.0标准套件中，LLS包括在具有专用于该信令功能的地址和/或端口的IP分组的有效载荷中携带的信令信息。所提议的ATSC 3.0标准套件定义了可以以LLS表的形式用信号发送的五种类型的LLS信息：服务列表(SLT)、评级区域表(RRT)、系统时间片段、高级紧急警报表片段(AEAT)消息、以及屏幕上消息通知。在将来的版本中可以用信号发送附加LLS表。表格1提供了为LLS表所提供的语法，如根据所提议的ATSC 3.0标准套件所定义并在A/331中所描述的。在表格1及在这里所述的其他表格中，uimsbf是指无符号整数最高有效位第一数据格式并且var是指可变数量的比特。
Figure BDA0001986640130000101
表格1
A/331为包含在表格1中的语法元素提供了以下定义：
LLS_table_id-8位无符号整数，用于标识在主体中所递送的表的类型。范围在0到0x7F中的LLS_table_id的值应由ATSC来定义或被保留以供ATSC将来使用。范围在0x80到0xFF中的LLS_table_id的值可供用户私人使用。
provider_id-8位无符号整数，用于标识与在该LLS_table()实例中所用信号发送的服务相关联的提供者，其中“提供者(provider)”是使用此广播流的部分或全部来广播服务的广播者。provider_id在此广播流中应是唯一的。
LLS_table_version-8位无符号整数，只要LLS_table_id和provider_id的组合所标识的表中的任何数据发生变化，该8位无符号整数就会加1。当值达到0xFF时，该值在递增时将环绕为0x00。每当存在不止一个多个共享广播流的提供者时，LLS_table()应由LLS_table_id和provider_id的组合来标识。
SLT-用gzip压缩[即gzip文件格式]的XML格式服务列表表格([A/331]第6.3节)。
RRT-用gzip压缩的符合在[A/331的]附录F中所规定的RatingRegionTable结构的评级区域表格的实例。
SystemTime-用gzip压缩的XML格式系统时间片段([A/331的]第6.3节)。
AEAT-用gzip压缩的符合高级紧急警报消息格式(AEA-MF)结构([A/331的]第6.5节)的XML格式高级紧急警报表格片段。
如上所述，服务提供者可以接收来自紧急机构的紧急警报并产生紧急警报消息，该紧急警报消息可以与服务一起分发给接收器设备。文档示例中的AEAT片段可以包括紧急警报消息。在A/331中，AEAT片段可以是由一个或多个AEA(高级紧急警报)消息构成的，其中根据AEA-MF(高级紧急警报-消息格式)结构对AEA消息格式化。在A/331中，AEA-MF包括用于多媒体内容的设施，这些多媒体内容可以从警报发起者(例如紧急机构)或服务提供者转发到接收器设备。表格2描述了如在A/331中所提供的AEAT元素的结构。应当注意的是在表格2及包含在这里的其他表格中，数据类型字符串unsignedByte、dateTime、language、以及anyURI可以与在万维网联盟(W3C)所维护的XML模式定义(XSD)建议中所提供的定义相对应。在一个示例中，这些可以与在“XML Schema Part 2：Datatypes Second Edition”中所描述的定义相对应。此外，使用可以与元素或属性的基数(即元素或属性的出现次数)相对应。
Figure BDA0001986640130000121
表格2
在一个示例中，包含在表格2中的元素和属性可以基于包含在A/331中的以下语义：
AEAT-AEAT的根元素。
AEA-高级紧急警报消息。此元素是具有@AEAid、@ifuer、@aud ience、@AEAtype、@refAEAid、以及@priority属性的父元素加以下子元素：Header、AEAtext、Media、以及可选的Signature：。
AEA@AEAid-此元素应为由站(发送方)所分配的用于唯一标识AEA消息的字符串值。@AEAid不包含空格、逗号、或限制字符(<和&)。
AEA@issuer-字符串，其用于标识发起或转发消息的广播站。@issuer应包含诸如呼号、站标识符(ID)、组名、或其他标识值的字母数字值。
AEA@audience-字符串，其用于标识消息的预期受众。该值应根据表格3被编码。
Figure BDA0001986640130000131
表格3
AEA@refAEAid-字符串，其用于标识所引用的AEA消息的AEAid。当@AEAtype为“更新”或“取消”时，它将出现。
AEA@AEAtype-字符串，其用于标识AEA消息的类别。该值应根据表格4编码。@refAEAid
Figure BDA0001986640130000141
表格4
AEA@priority-AEA消息应包含用于指示出警报的优先级的整数值。该值应根据表格5编码。
Figure BDA0001986640130000151
表格5
Header-此元素应包含警报的相关包络信息，其包括警报类型(EventCode)、警报有效的时间(@effective)、到期时间(@expires)、以及目标警报区域的位置(Location)。
Header@effective-该dateTime应包含警报消息的有效时间。日期和时间应以XMLdateTime数据类型格式来表示(例如针对2016年6月23日美国东部时间上午11:15，表示为“2016-06-23T22：11：16-05：00”)。不得使用诸如“Z”的字母时区指示符。UTC的时区应表示为“-00：00”。
Header@expires-该dateTime应包含警报消息的到期时间。日期和时间应以XMLdateTime数据类型格式表示(例如针对2016年6月23日美国东部时间上午11:15，表示为“2016-06-23T22：11：16-05：00”)。不得使用诸如“Z”的字母时区指示符。UTC的时区应表示为“-00：00”。
EventCode-用于标识警报消息的事件类型的字符串，其被格式化为用于表示值本身的字符串(可以代表数字)(例如，在美国，值“EVI”将用于表示疏散告警)。值可能因国家而异，并且可能是字母数字代码，或者可能是纯文本。对于每个AEA消息只能出现一个EventCode。
EventCode@type-该属性应为国家分配的字符串值，该字符串值应指定EventCode的域(例如在美国，“SAME”表示标准联邦通信委员会(FCC)第11部分紧急警报系统(EAS)编码)。作为首字母缩写词的@type的值应以不带句号的全部大写字母表示。
Location-字符串，该字符串用于描述具有基于地理位置的代码的消息目标。
Location@type–该属性应为用于标识位置代码的域的字符串。
如果@type＝“FIPS”，则该位置应被定义为美国联邦通信委员会针对紧急警报系统在联邦法规(CFR)11的规程47中所指定的联邦信息处理标准(FIPS)地理代码。
如果@type＝“sgc”，则该位置应被定义为加拿大统计局2006年版(2010年5月更新)所定义的标准地理分类代码。
如果@type＝“polygon”，则该位置应定义下述地理空间区域，该区域由其形成了封闭的、非自相交环的四个或更多个坐标对的连接序列组成。
如果@type＝“circle”，则该位置应定义由下述中心点所表示的圆形区域，该中心点作为坐标对后跟空格字符及以千米为单位的半径值所给出。
@type的文本值区分大小写，并且应以全部大写字母表示，但“polygon”和“circle”除外。
AEAtext-紧急消息的纯文本字符串。每个AEAtext元素应包含一个@lang属性。对于多种语言的同一警报的AEAtext，该元素应要求存在多个AEAtext元素。
AEAtext@lang-该属性应标识警报消息的相应AEAtext元素的语言。该属性应表示该ATSC 3.0服务名称的语言，并应由BCP 47所定义的形式自然语言标识符来表示[互联网工程任务组(IETF)最佳现行做法(BCP)47。应该注意的是BCP是一系列IETF RFC(请求注解)的持久名称，其编号随着更新而变化。用于描述语言标签语法的最新RFC是RFC 5646，标签用于语言的标识，其通过引用被并入到这里，并且它废弃了较旧的RFC 4646、3066、以及1766]。不应有隐含的默认值。
Media-应包含多媒体资源的组成部分，其包括资源的语言(@lang)、描述(@mediaDesc)、以及位置(@url)。指带具有与AEAtext有关的补充信息的附加文件；例如，图像或音频文件。在AEA消息块中可能出现多个实例。
Media@lang–该属性应标识每个媒体资源的相应语言以帮助指示收件人是否正在发送相同多媒体的不同语言实例。该属性应表示该ATSC 3.0服务名称的语言，并且应由BCP47所定义的形式自然语言标识符来表示。
Media@mediaDesc-字符串，其以纯文本形式描述媒体资源的类型和内容。该描述应指示出诸如视频、照片、PDF等的媒体类型。
Media@uri-可选元素，其应包含可用于从消息外部的目的地中检索资源的完整URL。当经由宽带递送富媒体资源时，Media元素的URL应引用远程服务器上的文件。当经由广播ROUTE递送富媒体资源时，资源的URL应以http：//localhost/开头。URL应与用于递送文件的LCT信道中的扩展文件递送表(EFDT)中的相应File元素的Content-Location属性或者文件的实体报头相匹配[IETF：RFC 5651，“Layered Coding Transport(LCT)BuildingBlock”，因特网工程任务组，雷斯顿，VA，2009年10月]。
Signature-可选元素，其应能够使得站与接收器之间的数字签名消息。
如表格2所示，AEA消息可以包括URI(Media@uri)，该URI用于标识可以获得与紧急情况有关的附加媒体资源(例如视频、音频、文本、图像等)的位置。AEA消息可以包括与附加媒体资源相关联的信息。如表格2中所提供的，与附加媒体资源相关联的信息的信令可能不太理想。
如上所述，所提议的ATSC 3.0标准套件支持使用视频或音频水印的信令。水印可用于确保接收器设备可检索补充内容(例如紧急消息、替代音频轨道、应用数据、隐藏字幕数据等)而与多媒体内容如何被分发无关。例如，本地网络附属机构可以在视频信号中嵌入水印以确保接收器设备可检索与本地电视呈现相关联的补充信息，并且因而向观看者呈现补充内容。例如，内容提供者可能希望确保在重新分发场景期间消息与媒体服务的呈现一起出现。重新分发场景的示例可以包括ATSC 3.0接收器设备接收多媒体信号(例如视频和/或音频信号)并从多媒体信号恢复嵌入信息的情况。例如，接收器设备(例如数字电视)可以从多媒体接口(例如高清晰度多媒体接口(HDMI)等)接收未压缩的视频信号并且接收器设备可以从未压缩的视频信号中恢复嵌入信息。在一些情况下，当MVPD用作接收器设备和内容提供者(例如本地网络附属机构)之间的中介时，可能发生重新分发场景。在这些情况下，机顶盒可以通过特定的物理链路和/或网络层格式接收多媒体服务数据流，并且将未压缩的多媒体信号输出到接收器设备。应当注意的是在一些示例中，重新分发场景可以包括机顶盒或家庭媒体服务器用作家庭内视频分发器，并且(例如通过本地有线或无线网络)服务于连接设备(例如智能手机、平板电脑等)的情况。此外，应当注意的是在一些情况下，MVPD可以在视频信号中嵌入水印以增强源自内容提供者的内容(例如提供定向补充广告)。
ATSC候选标准：内容恢复(A/336)(Doc.S33-178r2，2016年1月15日(下文中称为“A/336”)，其全部内容通过引用被并入到本文)指定了如何在音频水印有效载荷、视频水印有效载荷、以及音频轨道的用户区域中携带某些信令信息以及如何使用该信息以访问重新分发场景中的补充内容。A/336描述了视频水印有效载荷可以包括eme rgency_alert_message()的位置。emergency_alert_message()支持在视频水印中递送紧急警报信息。已提议将在A/336中所提议的emergency_alert_message()替换为在表格6中所提供的advanced_emergency_alert_message()，或者在A/336中所提供的emergency_alert_message()之外还添加在表格6中所提供的advanced_emergency_alert_message()。应当注意是在一些示例中，advanced_emergency_alert_message()可以被称为AEA_message()。在表格6以及在这里所描述的其他表格中，char表示字符。
Figure BDA0001986640130000201
Figure BDA0001986640130000211
表格6
已经为相应语法元素AEA_ID_length；AEA_ID；AEA_issuer_length；AEA_issuer；effective；expires；event_code_type_length；event_code_length；event_code_type；event_code；audience；AEA_type；priority；ref_AEA_ID_flag；num_AEA_text；num_location；ref_AEA_ID_length；ref_AEA_ID；AEA_text_lang_code；AEA_text_length；AEA_text；location_type；location_length；以及包含在advanced_emergency_alert_message()中的位置提供了以下定义：
AEA_ID_length-该8位无符号整数字段以字节为单位给出了AEA_ID字段的长度。
AEA_ID-该字符串应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA@AEAid属性的值。
AEA_issuer_length-该8位无符号整数字段以字节为单位给出了AEA_issuer字段的长度。
AEA_issuer-该字符串应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA@issuer属性的值。
effective-该参数应指示出AEA消息的有效日期和时间，其被编码为自1970年1月1日00:00:00国际原子时间(TAI)以来的秒数的32位计数。该参数应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.Header@effective属性的值。
expires-该参数应指示出AEA消息的最晚到期日期和时间，其被编码为自1970年1月1日00:00:00国际原子时间(TAI)以来的秒数的32位计数。该参数应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.Header@expires属性的值。
audience-该3位无符号整数字段给出了消息的受众类型。该无符号整数应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA@audience属性的值。该值应根据表格7编码。
Figure BDA0001986640130000221
表格7
event_code_type_length-该3位无符号整数字段以字节为单位给出了event_code_type字段的长度。
event_code_length-该4位无符号整数字段以字节为单位给出了event_code字段的长度。
event_code_type-该字符串应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.Header.EventCode@type属性的值。
event_code-该字符串应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.Header.EventCode元素的值。
AEA_type-该3位无符号整数字段给出了AEA消息的类别。该无符号整数应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA@AEAtype属性的值。该值应根据表格8编码。
Figure BDA0001986640130000231
表格8
priority-该4位无符号整数应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA@priority属性的值。
ref_AEA_ID_flag-该1位布尔标志字段指示出在AEA消息中存在ref_AEA_ID字段。
num_AEA_text-该2位无符号整数字段给出AEA消息中的AEA_text字段的编号。
num_location-该2位无符号整数字段给出AEA消息中的位置字段的编号。
ref_AEA_ID_length-该8位无符号整数字段以字节为单位给出ref_AEA_ID字段的长度。
ref_AEA_ID-该字符串应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA@refAEAid属性的值。
AEA_text_lang_code-该16位字符字段给出AEA_text字段的语言代码。该字符串应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.AEAtext@lang属性的前两个字符。
AEA_text_length-该8位无符号整数字段以字节为单位给出了AEA_text字段的长度。
AEA_text-该字符串应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.AEAtext元素的值。
location_type-该3位无符号整数字段给出了位置字段的类型。该无符号整数应为在[A/331]中所定义的、约束条件为不应在视频水印消息中使用“多边形”位置类型的当前高级紧急警报消息的AEAT.AEA.Header.Location@type属性的值。该值应根据表格9编码。
Figure BDA0001986640130000251
表格9
location_length-该8位无符号整数字段以字节为单位给出了位置字段的长度。
location-该字符串应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.Header.Location元素的值。
如表格6中所示，advanced_emergency_alert_message()可以根据其范围从0到3的num_AEA_text和num_location的各自2比特值来用信号发送最多三个AEA文本字符串和最多三个AEA位置字符串。此外，如表格6所示，可以使用AEA_text_lang_code元素来用信号发送AEA文本字符串的语言。表格6中所提供的信令可能不太理想。按照这种方式，在ATSC3.0标准套件中用于用信号发送紧急警报消息的机制可能不太理想。
图2是用于说明可以实现在本公开中所描述的一种或多种技术的系统的示例的方框图。系统200可以被配置为根据这里所述的技术来传递数据。在图2所示的示例中，系统200包括一个或多个接收器设备202A-202N、一个或多个配套设备203、电视服务网络204、电视服务提供者站点206、广域网212、一个或多个内容提供者站点214、一个或多个紧急机构站点216、以及一个或多个紧急警报数据提供者站点218。系统200可以包括软件模块。可以将软件模块存储在存储器中并由处理器执行。系统200可以包括一个或多个处理器以及多个内部和/或外部存储器设备。存储器设备的示例包括文件服务器、文件传输协议(FTP)服务器、网络附加存储(NAS)设备、本地磁盘驱动器、或者能够存储数据的任何其他类型的设备或存储介质。存储介质可以包括蓝光盘、DVD、CD-ROM、磁盘、闪存、或者任何其他适当的数字存储介质。当这里所述的技术部分地以软件实现时，设备可以将软件的指令存储在适当的非暂时性计算机可读介质中，并且使用硬件中的一个或多个处理器来执行指令。
系统200表示下述系统的示例：该系统可以被配置为允许诸如例如电影、现场体育赛事等的数字媒体内容以及与其相关联的数据、应用、以及媒体呈现(例如紧急警报消息)被分发给诸如接收器设备202A-202N的多个计算设备并由多个计算设备访问。在图2所示的示例中，接收器设备202A-202N可以包括其被配置为接收来自电视服务提供者站点206的数据的任何设备。例如，接收器设备202A-202N可以被配备用于有线和/或无线通信并且可以被配置为通过一个或多个数据通道接收服务，并且可以包括其包括所谓的智能电视、机顶盒、以及数字视频录像机的电视。此外，接收器设备202A-202N可以包括台式计算机、膝上型计算机、或平板计算机、游戏控制台、包括例如“智能”电话、蜂窝电话的移动设备、以及其被配置为接收来自电视服务提供者站点206的数据的个人游戏设备。应当注意的是尽管系统200被说明为具有不同站点，但是的说明是出于描述的目的，并且不将系统200限制于特定的物理架构。可以使用硬件、固件、和/或软件实现的任何组合来实现系统200以及包含在其中的站点的功能。
电视服务网络204是下述网络的示例：该网络被配置为能够分发可以包括电视服务的数字媒体内容。例如，电视服务网络204可以包括公共空中电视网络、基于公共或订购的卫星电视服务提供者网络、以及基于公共或订购的有线电视提供者网络和/或顶级或互联网服务提供者。应当注意的是尽管在一些示例中，电视服务网络204可以主要用于使得能够提供电视服务，但是电视服务网络204还可以使得能够根据这里所述的电信协议的任何组合来提供其他类型的数据和服务。此外，应当注意的是在一些示例中，电视服务网络204可以使得能够在电视服务提供者站点206与一个或多个接收器设备202A-202N之间进行双向通信。电视服务网络204可以包括无线和/或有线通信媒体的任何组合。电视服务网络204可以包括同轴电缆、光纤电缆、双绞线电缆、无线传送器和接收器、路由器、交换机、中继器、基站、或者可以用于便于各种设备与站点之间进行通信的任何其他设备。电视服务网络204可以根据一个或多个电信协议的组合来进行操作。电信协议可以包括专有方面和/或可以包括标准化电信协议。标准化电信协议的示例包括DVB标准、ATSC标准、ISDB标准、DTMB标准、DMB标准、有线数据服务接口规范(DOCSIS)标准、HbbTV标准、W3C标准、以及UPnP标准。
再次参考图2，电视服务提供者站点206可以被配置为通过电视服务网络204分发电视服务。例如，电视服务提供者站点206可以包括一个或多个广播站、MVPD，诸如例如有线电视提供者、或卫星电视提供者、或基于互联网的电视提供者。在图2所示的示例中，电视服务提供者站点206包括服务分发引擎208、内容数据库210A、以及紧急警报数据库210B。服务分发引擎208可以被配置为接收包括例如多媒体内容、交互式应用的数据，以及包括紧急警报和/或紧急警报消息的消息，并且通过电视服务网络204将数据分发到接收器设备202A-202N。例如，服务分发引擎208可以被配置为根据上述传输标准(例如ATSC标准)中的一个或多个的方面来传送电视服务。在一个示例中，服务分发引擎208可以被配置为通过一个或多个源来接收数据。例如，电视服务提供者站点206可以被配置为通过卫星上行链路和/或下行链路或者通过直接传输接收来自地区或国家广播网络(例如NBC、ABC等)的其包括电视节目的传输。此外，如图2所示，电视服务提供者站点206可以与广域网212进行通信，并且可以被配置为接收来自(一个或多个)内容提供者站点214的多媒体内容和数据。应当注意的是在一些示例中，电视服务提供者站点206可以包括电视工作室并且内容可以源自其。
内容数据库210A和紧急警报数据库210B可以包括被配置为存储数据的存储设备。例如，内容数据库210A可以存储多媒体内容以及与其相关联的数据，其包括例如描述性数据和可执行交互式应用。例如，体育赛事可以与用于提供统计更新的交互式应用相关联。紧急警报数据库210B可以存储与紧急警报相关联的包括例如紧急警报消息的数据。可以根据诸如例如HTML、动态HTML、XML、以及JavaScript对象表示法(JSON)的已定义的数据格式来格式化数据，并且该数据可以包括使得接收器设备202A-202N能够访问例如来自(一个或多个)紧急警报数据提供者站点218之一的数据的URL和URI。在一些示例中，电视服务提供者站点206可以被配置为提供对所存储的多媒体内容的访问并且通过电视服务网络204将多媒体内容分发给一个或多个接收器设备202A-202N。例如，可以根据所谓的按需通过电视服务网络204将存储在内容数据库210A中的多媒体内容(例如音乐、电影、以及电视(TV)节目)提供给用户。
如图2所示，除了被配置为接收来自电视服务提供者站点206的数据之外，接收器设备202N还可以被配置为与(一个或多个)配套设备203进行通信。在图2所示的示例中，(一个或多个)配套设备203可以被配置为直接与接收器设备进行通信(例如使用例如蓝牙的短程通信协议)、通过局域网与接收器设备进行通信(例如通过Wi-Fi路由器)、和/或与广域网(例如蜂窝网络)进行通信。如下面所详细描述的，配套设备可以被配置为接收包括紧急警报信息的数据以供在其上运行的应用程序使用。(一个或多个)配套设备203可以包括计算设备，该计算设备被配置为执行与接收器设备结合的应用。应该注意的是在图2所示的示例中，尽管说明了单个配套设备，但是每个接收器设备202A-202N可以与多个配套设备相关联。配套设备203可以被配备用于有线和/或无线通信，并且可以包括诸如例如台式计算机、膝上型计算机、或平板计算机、移动设备、智能电话、蜂窝电话、以及个人游戏设备的设备。应该注意的是尽管在图2中未示出，但是在一些示例中，(一个或多个)配套设备可以被配置为接收来自电视服务网络204的数据。
广域网212可以包括基于分组的网络并且根据一个或多个电信协议的组合进行操作。电信协议可以包括专有方面和/或可以包括标准化电信协议。标准化电信协议的示例包括全球系统移动通信(GSM)标准、码分多址(CDMA)标准、第三代合作伙伴计划(3GPP)标准、欧洲电信标准协会(ETSI)标准、欧洲标准(EN)、IP标准、无线应用协议(WAP)标准、以及诸如例如IEEE 802标准中的一个或多个(例如Wi-Fi)的电气和电子工程师协会(IEEE)标准。广域网212可以包括无线和/或有线通信媒体的任何组合。广域网212可以包括同轴电缆、光纤电缆、双绞线电缆、以太网电缆、无线发送器和接收器、路由器、交换机、中继器、基站、或者可用于便于在各种设备与站点之间进行通信的任何其他设备。在一个示例中，广域网212可以包括因特网。
再次参考图2，(一个或多个)内容提供者站点214表示可以向电视服务提供者站点206和/或在一些情况下向接收器设备202A-202N提供多媒体内容的站点的示例。例如，内容提供者站点可以包括具有一个或多个工作室内容服务器的工作室，该工作室内容服务器被配置为向电视服务提供者站点206提供多媒体文件和/或内容馈送。在一个示例中，内容提供者站点214可以被配置为使用IP套件提供多媒体内容。例如，内容提供者站点可以被配置为根据实时流协议(RTSP)、超文本传输协议(HTTP)等向接收器设备提供多媒体内容。
(一个或多个)紧急机构站点216表示可以向电视服务提供者站点206提供紧急警报的站点的示例。例如，如上所述，紧急机构可以包括美国国家气象局、美国国土安全部、当地和区域机构等。紧急机构站点可以是紧急机构在通信(直接或通过广域网212)电视服务提供者站点206中的物理位置。紧急机构站点可以包括其被配置为向电视服务提供者站点206提供紧急警报的一个或多个服务器。如上所述，服务提供者(例如电视服务提供者站点206)可以接收紧急警报并产生紧急警报消息以分发给接收器设备(例如接收器设备202A-202N)。应注意的是在一些情况下紧急警报和紧急警报消息可以类似。例如，电视服务提供者站点206可以将从(一个或多个)紧急机构站点216所接收的XML片段作为紧急警报消息的一部分传递给接收器设备202A-202N。电视服务提供者站点206可以根据诸如例如HTML、动态HTML、XML、以及JSON的已定义的数据格式产生紧急警报消息。
如上所述，紧急警报消息可以包括URI，该URI用于标识可以获得与紧急情况有关的附加内容的位置。(一个或多个)紧急警报数据提供者站点218表示被配置为向接收器设备202A-202N中的一个或多个提供紧急警报数据——包括媒体内容、基于超文本的内容、XML片段等——和/或在一些示例中通过广域网212向电视服务提供者站点206提供所述紧急警报数据的站点的示例。(一个或多个)紧急警报数据提供者站点218可以包括一个或多个web服务器。
如上所述，服务分发引擎208可以被配置为接收包括例如多媒体内容、交互式应用、以及消息的数据，并且通过电视服务网络204将数据分发到接收器设备202A-202N。因而，在一个示例性场景中，电视服务提供者站点206可以接收来自(一个或多个)紧急机构站点216的紧急警报(例如恐怖告警)。服务分发引擎208可以根据紧急警报产生紧急警报消息(例如包括“恐怖告警”文本的消息)，并且使得将紧急消息分发到接收器设备202A-202N。例如，如上所述，服务分发引擎208可以使用LLS和/或水印来传递紧急警报消息。
图3是用于对可以实现本公开的一个或多个技术的服务分发引擎的示例进行说明的方框图。服务分发引擎300可以被配置为接收数据并输出用于表示该数据以通过例如电视服务网络204的通信网络分发的信号。例如，服务分发引擎300可以被配置为接收一个或多个数据集并且输出可以使用单个射频频带(例如6MHz信道、8MHz信道等)或绑定信道(例如两个单独的6MHz信道)所传送的信号。
如图3中所说明的，服务分发引擎300包括组件封装器302、传输和网络分组生成器304、链路层分组生成器306、帧构建器和波形发生器308、以及系统存储器310。组件封装器302、传输和网络分组生成器304、链路层分组发生器306、帧构建器和波形发生器308、以及系统存储器310中的每一个可以互连(物理地、通信地、和/或可操作地)以用于组件间通信并且可以是作为诸如一个或多个微处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、离散逻辑、软件、硬件、固件、或其任何组合的各种适当电路中的任何一个而实现的。应当注意的是尽管服务分发引擎300被示为具有不同的功能块，但是的说明是出于描述的目的，并且不将服务分发引擎300限制为特定硬件架构。服务分发引擎300的功能可以是利用硬件、固件、和/或软件实现的任何组合来实现的。
系统存储器310可以被描述为非暂时性或有形计算机可读存储介质。在一些示例中，系统存储器310可以提供临时和/或长期存储。在一些示例中，系统存储器310或其部分可以被描述为非易失性存储器并且在其他示例中系统存储器310的部分可以被描述为易失性存储器。易失性存储器的示例包括随机存取存储器(RAM)、动态随机存取存储器(DRAM)、以及静态随机存取存储器(SRAM)。非易失性存储器的示例包括磁性硬盘、光盘、软盘、闪存、或者电可编程存储器(EPROM)或电可擦除和可编程(EEPROM)存储器的形式。系统存储器310可以被配置为存储可以在操作期间由服务分发引擎300所使用的信息。应当注意的是系统存储器310可以包括包含在组件封装器302、传输和网络分组生成器304、链路层分组生成器306、以及帧构建器和波形发生器308中的每一个之内的各个存储器元件。例如，系统存储器310可以包括一个或多个缓冲器(例如先入先出(FIFO)缓冲器)，该缓冲器被配置为存储用于由服务分发引擎300的组件进行处理的数据。
组件封装器302可以被配置为接收服务的一个或多个组件并根据已定义的数据结构对一个或多个组件进行封装。例如，组件封装器302可以被配置为接收一个或多个媒体组件并基于MMTP产生分组。此外，组件封装器302可以被配置为接收一个或多个媒体组件并基于通过HTTP的动态自适应流(DASH)产生媒体呈现。应该注意的是在一些示例中组件封装器302可以被配置为产生服务层信令数据。
传输和网络分组生成器304可以被配置为接收传输包并将传输包封装到相应传输层分组(例如UDP、传输控制协议(TCP)等)和网络层分组(例如IPv4、IPv6、压缩的IP包等)。在一个示例中，传输和网络分组生成器304可以被配置为产生信令信息，该信令信息被携带在具有专用于信令功能的地址和/或端口的IP分组的有效载荷中。也就是说，例如，传输和网络分组生成器304可以被配置为根据本公开的一种或多种技术产生LLS表。
链路层分组生成器306可以被配置为接收网络分组并且根据已定义的链路层分组结构(例如ATSC 3.0链路层分组结构)产生分组。帧构建器和波形发生器308可以被配置为接收一个或多个链路层分组并输出以帧结构布置的符号(例如OFDM符号)。如上所述，帧可以包括其可以被称为物理层帧(PHY层帧)的一个或多个PLP。如上所述，帧结构可以包括引导程序、前导码、以及包括一个或多个PLP的数据有效载荷。引导程序可以用作波形的通用入口点。前导码可以包括所谓的层1信令(L1-信令)。L1信令可以提供用于配置物理层参数的必要信息。帧构建器和波形发生器308可以被配置为生成用于在一个或多个RF信道内传输的信号：单个6MHz信道、单个7MHz信道、单个8MHz信道、单个11MHz信道、包括任何两个或更多个单独单个信道的绑定信道(例如包括6MHz信道和8MHz信道的14MHz信道)。帧构建器和波形发生器308可以被配置为插入导频和保留音调以用于信道估计和/或同步。在一个示例中，可以根据正交频分复用(OFDM)符号和子载波频率映射来定义导频和保留音调。帧构建器和波形发生器308可以被配置为通过将OFDM符号映射到子载波来产生OFDM波形。应该注意的是在一些示例中，帧构建器和波形发生器308可以被配置为支持层分多路复用。层分多路复用可以指在将多个数据层叠加在同一RF信道(例如6MHz信道)上。典型地，上层是指支持主要服务的核心(例如更鲁棒的)层，而下层是指支持增强型服务的高数据速率层。例如，上层可以支持基本的高清视频内容，并且下层可以支持增强的超高清视频内容。
如上所述，传输和网络分组生成器304可以被配置为根据本公开的一个或多个技术产生LLS表。应当注意的是在一些示例中服务分发引擎(例如服务分发引擎208或服务分发引擎300)或其特定组件可以被配置为根据这里所述的技术产生信令消息。因而，就传输和网络分组生成器304而言，对包括数据片段的信令消息的描述不应被解释为限制这里所述的技术。在一些情况下，接收器设备临时暂停应用和/或改变渲染多媒体呈现的方式以便增加用户了解紧急警报消息的可能性这是有用和/或必要的。如上所述，当前提议的用于用信号发送与紧急警报消息相关联的信息的技术可能不太理想。
传输和网络分组生成器304可以被配置为用信号发送和/或产生紧急警报消息。在一个示例中，传输和网络分组生成器304可以被配置为基于关于表格2所提供的示例性结构产生AEA消息。在一个示例中，传输和网络分组生成器304可以被配置为基于在表格10A中所提供的示例性语法产生LLS表。应当注意的是在表格10A中参考表格2。按照这种方式，表格10A可以包括包含在表格2中的元素和属性。然而，如表格10A中所说明的，媒体元素及其属性不同于关于表格2所提供的媒体元素。
Figure BDA0001986640130000341
表格10A
在表格10A所说明的示例中，Media@lang、Media@mediaDesc、Media@contentType、以及Media@contentLength中的每一个可以基于以下示例性语义：
Media@lang-该属性应标识每个媒体资源的相应语言以在如果正在发送相同多媒体的不同语言实例的情况下帮助指示收件人。该属性应表示由Media元素所指定的媒体资源的语言，并且应由如BCP 47所定义的形式自然语言标识符来表示。当不存在时，推断出该属性的值为“en”(英语)。在另一示例中，当不存在时，推断出该属性的值为“EN”(英语)。
在另一示例中，当不存在时，应使用在标准中所指定的默认值以进行推断。例如，代替“en”(英语)，该语言可以是“es”(西班牙语)、“kr”(韩语)、或其他语言。
Media@mediaDesc-字符串，其应以纯文本形式描述媒体资源的内容。该描述应指示出媒体信息。例如“疏散地图”或“多普勒雷达图像”等。应推断出Media@mediaDesc的语言与在Media@lang中所指示出的语言相同。
Media@contentType-字符串，其表示Media@uri所引用的媒体内容的MIME类型。在一个示例中，Media@contentType应遵循如在IETF RFC 7231中所提供的HTTP/1.1协议的Content-Type报头的语义。在另一示例中，Media@contentType应遵循如在IETF RFC 2616中所提供的HTTP/1.1协议的Content-Type报头的语义。
Media@contentLength-字符串，其应以字节为单位来表示Media@uri所引用的媒体内容的大小。
就上面所提供的语义而言，为可选地用信号发送的Media@lang提供默认值可以提高信令效率。此外，在表格10A中所说明的示例中，分别用信号发送媒体内容类型和媒体描述(即使用不同属性)。就表格10A而言，应当注意的是如在这里所使用的，在一些情况下MIME类型通常可以指代媒体或内容类型，并且在其他情况下可以基于多用途因特网邮件扩展与已定义的媒体或内容类型相关联。单独地用信号发送媒体内容类型和媒体描述可以使得能够以有效的方式检索媒体。也就是说，单独用信号发送媒体内容类型和媒体描述可以使得能够进行媒体内容是否应由接收器设备检索的附加确定。例如，如果接收器设备仅能够对某些媒体类型进行解码，则它可对照所用信号发送的媒体内容类型来检查能力并且确定它是否具有解码内容的能力。在这种情况下，接收器设备可以仅下载它可解码的内容。
在表格10A中所说明的示例中，Media@contentType属性是机器可读的而不是自由形式的字符串。用信号发送机器可读属性可以使得接收器设备能够确定是否检索媒体内容。例如，MIME类型可以指示出接收器设备不支持的文件类型(例如冲击波程式闪格式文件(.swf)文件)并且在这种情况下，接收器设备可能不检索该文件。按照类似方式，可以使用与媒体资源的文件大小有关的信息来确定是否应该检索媒体资源。例如，接收器设备可以被配置为仅检索具有小于阈值的大小的文件。例如，接收器设备的设置可以使得用户能够防止检索相对大的视频文件。在一个示例中，该设置可以基于设备的可用存储容量和/或接收器设备的可用网络带宽。
在一些示例中，接收器设备的用户可以基于呈现给用户的媒体属性来确定是否检索内容。例如，在一个示例中，接收器设备可以使得媒体描述被呈现给接收器设备的用户，并且根据该描述，用户可以确定是否检索内容。按照这种方式，用信号发送媒体描述语言的语言是有用的并且可能是必要的。在上面的示例中，推断出语言与Media@lang相同。在一个示例中，在表格10A中可以包括强制或可选属性以用信号发送媒体描述符的语言。在一个示例中，该属性可以是Media元素的属性。在一个示例中，该属性可以基于以下语义：
Media@mediaDescLang-该属性应指定在Media@mediaDesc中所指定的文本语言。该值应如BCP 47所定义的。当不存在时，应推断出该属性的值为“en”(英语)。当Media@mediaDesc不存在时，Media@mediaDescLang应不存在。
尽管在上面的示例中指示出字段contentType、contentLength、以及mediaDescLang被用信号发送为Media XML元素的XML属性，但是在另一示例中，它们可以被用信号发送为Media XML元素内的XML元素(而不是XML属性)。按照这种方式，传输和网络分组生成器304可以被配置为用信号发送与附加媒体资源相关联的信息，该附加媒体资源与紧急警报消息相关联。
在一个示例中，基于下面关于表格10B所提供的示例性结构，关于表格10A所描述的媒体属性可以包含在AEA消息之中。
Figure BDA0001986640130000371
Figure BDA0001986640130000381
表格10B
应当注意的是表格10B包括上面关于表格2和表格10A所描述的元素和属性并且另外包括EventDesc、EventDesc@lang、LiveMedia、LiveMedia@bsid、LiveMedia@serviceId、ServiceName、以及ServiceName@lang。在一个示例中，EventDesc、EventDesc@lang、LiveMedia、LiveMedia@bsid、LiveMedia@serviceId、ServiceName、以及ServiceName@lang中的每一个可以基于以下语义：
EventDesc-字符串，该字符串应包含紧急事件的短纯文本描述。在一个示例中，该字符串不得超过64个字符。当EventCode元素存在时，EventDesc应与在EventCode元素中所指示出的事件代码相对应(例如“龙卷风告警”的EventDesc与“TOR”的EAS EventCode相对应)。当EventCode元素不存在时，EventDesc应提供对事件类型的简短用户友好的指示(例如“学校关闭”)。在一个示例中，AEA内的AEA.Header.EventDesc元素的出现次数不得超过8。
EventDesc@lang-该属性应标识警报消息的相应EventDesc元素的语言。该属性应由正式自然语言标识符来表示，并且在一个示例中，长度不得超过35个字符，如BCP 47所定义的。在一个示例中，不应有隐含的默认值。
LiveMedia-A/V服务的标识，其作为对例如正在进行的新闻报道的紧急相关信息进行调整的选择提供给用户。
LiveMedia@bsid-广播流的标识符，其包含紧急相关实时A/V服务。
LiveMedia@serviceId-16位整数，其用于唯一标识紧急相关实时A/V服务。
ServiceName-LiveMedia可用的服务的用户友好名称，当呈现对调整到例如“WXYZChannel 5”的LiveMedia的选项时接收器可向观看者呈现该用户友好名称。
ServiceName@lang-应标识实时媒体流的相应ServiceName元素的语言。该属性应由正式自然语言标识符表示并且在一个示例中，不应超过35个字符，如BCP 47所定义的。在一个示例中，不应存在隐式默认值。
在一些示例中，元素和属性AEA@AEAid、AEA@refAEAid、Location、Location@type、AEAtext、Media、Media@mediDesc、以及Media@contentType可以基于以下语义：
AEA@AEAid-该元素应为用于唯一标识由站(发送方)所分配的AEA消息的字符串值。@AEAid不应包含空格、逗号、或限制字符(<和&)。该元素用于使更新与该警报相关联。在一个示例中，字符串不得超过32个字符。
AEA@refAEAid-字符串，其用于标识所引用的AEA消息的AEAid。当@AEAtype为“更新”或“取消”时，它应出现。在一个示例中，字符串不应超过256个字符。
Location-字符串，其应用于描述具有基于地理位置的代码的消息目标。在一个示例中，AEA内的AEA.Header.Location元素的出现次数不得超过8。
Location@type-该属性应是用于标识位置代码的域的字符串。
如果@type＝“FIPS”，则Location应被定义为由逗号分隔的一个或多个数字字符串的组，并且在一个示例中，不得超过246个字符。按照在47CFR11.31中定义为PSSCCC的方式，每6位数字字符串应为如在FIPS中所定义的县级细分、州、以及县代码的串接[NIST：“联邦信息处理标准地理代码”，47CFR 11.31(f)，国家标准与技术研究院，盖瑟斯堡，MD，2015年10月22日]。此外，代码“000000”应被解释为美国及其领土内的所有位置。
如果@type＝“SGC”，则位置应被定义为由逗号分隔的一个或多个数字字符串的组，并且在一个示例中，不得超过252个字符。每个数字字符串应为如在SGC中所定义的2位数字省(PR)、2位数字人口普查区(CD)、以及3位数字人口普查子区(CSD)的串接。
如果@type＝“polygon”，则位置应定义地理空间区域，该区域是由其形成了封闭的非自相交环的三个或更多个GPS坐标对的连接序列组成的。每个坐标对应以十进制度来表示。
如果@type＝“circle”，则位置应定义由中心点所表示的圆形区域，该中心点是作为坐标对后跟空格字符及以千米为单位的半径值所给出的。
@type的文本值区分大小写，并且应以全部大写字母表示，但“polygon”和“circle”除外。
AEAtext-紧急消息的纯文本字符串。每个AEAtext元素应包含一个@lang属性。对于多种语言的同一警报的AEAtext，该元素应要求存在多个AEAtext元素。在一个示例中，该字符串不得超过256个字符，和/或AEA内的AEA.AEAtext元素的出现次数不得超过8。
Media-应包含多媒体资源的组成部分，其包括资源的语言(@lang)、描述(@mediaDesc)、以及位置(@url)。指代具有与AEAtext有关的补充信息的附加文件；例如，图像或音频文件。在AEA消息块内可能出现多个实例。在一个示例中，AEA内的AEA.Media元素的出现次数不得超过8。
edia@mediaDesc-字符串，其应以纯文本形式描述媒体资源的内容。在一个示例中，该字符串不得超过64个字符。在一个示例中，该描述应指示出媒体信息。例如“疏散地图”或“多普勒雷达图像”等。应推断出Media@mediaDesc的语言与在Media@lang中所指示出的语言相同。
Media@contentType-字符串，其应表示Media@uri所引用的媒体内容的MIME类型。Media@contentType应遵循HTTP/1.1协议RFC 7231的Content-Type报头的语义。在一个示例中，该字符串不得超过15个字符。
按照这种方式，在一些示例中，可以约束AEA消息的大小以向接收器设备提供更有效的信令并由接收器设备进行解析。
在一个示例中，表格2、表格10A、以及表格10B中的报头的语义可以基于在表格10C中所提供的语义。
Figure BDA0001986640130000421
表格10C
在表格10C中，Header、Header@effective、以及Header@expires可以基于上面关于表格2所提供的定义。Header@allLocation可以基于以下定义：
Header@allLocation-当该布尔属性为TRUE时，它指示出该AEA消息针对是该ATSC发射信号的广播区域中的所有位置。当该布尔属性为FALSE时，它指示出该AEA消息所针对的位置应如(一个或多个)Header.Location元素所指示的。如果不存在，则应推断出Header@allLocation为FALSE。当Header@allLocation属性为FALSE时，在AEA消息报头中应存在至少一个Header.Location元素。
应当注意的是当Header的语义包括Header@allLocation时，Header.Location的基数为0..N。这意味着Location元素可以可选地存在于AEA消息的实例中。应当注意的是当Header@allLocation被设置为TRUE时，接收器设备可以确定出该消息是旨在广播区域中的所有接收器，并且当Header@allLocation被设置为FALSE时，如果例如由于在AEA消息中不存在Header.Location元素而未接收到另外位置信息，则接收器设备可以确定出该消息是不完整的(或错误)。
在另一示例中，Header@allLocation的定义可以提供当Header@allLocation不存在时应推断出Header@allLocation为TRUE。在一个示例中，当Header@allLocation为TRUE时，传输和网络分组生成器304可以被配置为在AEA消息的实例中不包括Header.Location。在一个示例中，当Header@allLocation为TRUE时，传输和网络分组生成器304可以被配置为可选地在AEA消息的实例中包括Header.Location。在一个示例中，当Header@allLocation为TRUE并且在AEA消息的实例中包括Header.Location时，接收器设备可以被配置为忽略Header.Location。应当注意的是在其他示例中，代替使用allLocation的XML属性，可以将allLocation中的信息作为XML元素——例如作为Header.AllLocation元素——传送。
此外，在一个示例中，表格2、表格10A、以及表格10B中的媒体的语义可以基于在表格10D中所提供的语义。
Figure BDA0001986640130000431
表格10D
在表格10D中，在一个示例中，Media、Media@lang、Media@mediaDesc、Media@urlMedia@contentType、和/或Media@contentLength可以基于以上关于表格2、10A、10B、和/或10C所提供的定义。在一个示例中，Media@lang、Media@mediaDesc、Media@mediaType、Media@url、Media@order、Media@duration、和/或Media@mediaAssoc可以基于以下定义：
Media@lang-该属性应标识每个媒体资源的相应语言，以在如果正在发送相同多媒体的不同语言实例的情况下帮助指示收件人。该属性应由如BCP 47所定义的形式自然语言标识符来表示，并且不得超过35个字符。如果@mediaDesc元素存在，则该元素应存在。
Media@mediaDesc-字符串，其应以纯文本形式描述媒体资源的内容。该描述应指示出媒体信息。例如“疏散地图”或“多普勒雷达图像”等。应推断出Media@mediaDesc的语言与在Media@lang中所指示出的语言相同。接收器可以使用该信息以向观看者呈现观看者可以选择用于渲染的媒体项列表。如果未提供该字段，则接收器可以在观看者UI中呈现项的通用文本(例如，如果@contentType指示出项是视频，则接收器可以在UI列表中将该项描述为“视频”)。
Media@mediaType-该字符串应标识关联媒体的预期用途。应当注意的是与在列表中呈现给用户以供选择的媒体相反，利用该属性所标识的媒体项典型地与接收器的警报用户界面所自动处理的项相关联。在一个示例中，该值应根据表格10E编码。
媒体类型 含义
"EventDescAudio" 与EventDesc元素相关联的音频(语音)
"AEAtextAudio" 与AEAtext元素相关联的音频(语音)
"EventSymbol" 与EventDesc相关联的符号
其他值 保留以供将来使用
表格10E
Media@url-必需属性，其应确定多媒体资源文件或分组的源。当经由宽带递送富媒体资源时，该属性应被形成为绝对URL并引用远程服务器上的文件。当经由广播ROUTE递送富媒体资源时，该属性应被形成为相对URL。相对URL应与用于递送文件的LCT信道中的EFDT中的相应文件元素的Content-Location属性或者文件的实体报头相匹配[IETF：RFC5651，“Layered Coding Transport(LCT)Building Block“，因特网工程任务组，雷斯顿，VA，October，2009]。
Media@mediaAssoc-可选属性，其包含与该媒体资源相关联的另一富媒体资源的Media@url。示例包括与视频相关联的隐藏字幕轨道。Media@mediaAssoc的构建应如上面在Media@url中所描述的。
Media@order-可选属性，其应指示出媒体资源文件的优选呈现顺序。在顺序编号减1的所有媒体资源文件(如果存在的话)已被呈现之后，应一并呈现具有相同顺序编号并且如Media@mediaAssoc属性所指示的彼此相关联的媒体资源文件。
Media@duration-可选属性，其应表示媒体资源文件的持续时间。
就上面所提供的语义而言，为可选地用信号发送的Media@order和Media@duration提供值可以使得能够以有效方式检索和/或呈现媒体。例如，接收器设备可以基于顺序和持续时间值来下载媒体资源。例如，接收器设备可以确定不下载具有相对长持续时间的媒体资源。
在另一示例中，可替代地将@mediaAssoc属性用信号发送为MediaAssoc元素。这是因为@mediaAssoc属性仅可因为其存在或不存在而指示出当前媒体与至多一个其他媒体的关联。在某些情况下，一个媒体元素可能需要与一个以上的其他媒体元素相关联。这可通过使用如表格10F所示的基数为0..N的MediaAssoc元素来实现。
Figure BDA0001986640130000461
表格10F
在这种情况下，MediaAssoc元素的语义可以如下：
Media.MediaAssoc-可选元素，其包含与该媒体资源相关联的另一富媒体资源的Media@url。示例包括与视频相关联的隐藏字幕轨道。Media@mediaAssoc的构建应如上面在Media@url中所描述的。支持存在多个MediaAssoc元素并且指示出与多个媒体资源的关联。
ATSC 3.0可以具有在多于一个RF信道中所递送的组件。当这种服务的组件的集合不是由服务的所有组件组成并且不止一个这种组件的集合构成服务时，将这种服务的组件的集合称为服务的一部分。另一方面，当该集合是由服务的所有组件组成并且递送了不止一个的组件集合时，将服务组件的集合称为服务的副本。由部分所表示的每个服务应仅具有一个基本部分，该部分足以在不使用其他部分，即非必要部分的情况下有意义地呈现服务(尽管使用其他部分也可以提供更有吸引力的呈现)。
在一个示例中，AEA的语义可以基于表格10G中所提供的语义。
Figure BDA0001986640130000471
表格10G
在一个示例中，AEA@audience、AEA@aeatype、AEA@refAEAid、以及AEA@priority可以基于上面所提供的定义。在一个示例中，AEA、AEA@aeaId、以及AEA@issuer可以基于以下示例性定义：
AEA-高级紧急警报消息。此元素是具有@aeaId、@issuer、@audience、@aeaType、@refAEAId、@priority、以及@wakeup属性加以下子元素：Header、AEAtext、Media、以及可选的LiveMedia、Media、以及Signature的父元素。
AEA@aeaId-该元素应为由站(发送方)所分配的用于唯一标识AEA消息的字符串值。@aeaId应被限制为使用0x0030至0x0039、0x0041至0x005A、0x0061至0x007A、短划线(0x002D)、点(0x002E)、以及下划线(0x005F)字符的UTF-8/Unicode字符集的62个字母数字字符(基本拉丁字母和阿拉伯数字)。该元素用于使更新与该警报相关联。
AEA@issuer-字符串，其用于标识发起或转发消息的广播站。@issuer应包含诸如呼号、站ID、组名、或其他标识值的字母数字值。该字符串不得超过32个字符。
在表格10G所示的示例中，元素AEA包括属性AEA@wakeup。在一个示例中，AEA@wakeup可以基于以下定义：
AEA@wakeup-该可选布尔属性——如果存在且设置为“true”——应将指示出AEA与非零ea_wake_up位相关联。默认值(如果不存在)应为“false”。
应当注意的是在A/331的附录G中描述了ea_wake_up位。如A/331的附件G中所提供的，在物理层中按照下述方式来递送两个ea_wake_up比特：当接收设备处于待机模式时接收设备可以检测到唤醒比特。两个唤醒比特允许接收器设备检测到紧急信息是可用的并且检测唤醒版本。表格10H总结了两个唤醒比特的串接的含义。
值 含义
′00′ 当前没有用信号发送唤醒设备的紧急情况
′01′ 唤醒设备的紧急情况-设置1
′10′ 唤醒设备的紧急情况-设置2
′11′ 唤醒设备的紧急情况-设置3
表格10H
应当注意的是当唤醒比特值从0变为1时，这指示出对紧急情况的唤醒调用。当数字设置编号从1增加到2、从2增加到3、从3增加到1等时，这指示出新的唤醒调用。当比特值返回到0时，这意味着不再用信号发送紧急唤醒。
如上所述，服务分发引擎可以被配置为输出可以使用绑定信道(例如两个单独的6MHz信道)所传送的信号。形成绑定信道的每个信道可以与不同广播流相关联并且可以具有不同基站识别码。在一个示例中，LiveMedia的语义可以基于在表格10I中所提供的语义。
Figure BDA0001986640130000491
表格10I
在表格10I所说明的示例中，LiveMedia@serviceId、ServiceName、以及ServiceName@lang中的每一个可以基于上面所提供的定义。在一些示例中，LiveMedia和LiveMedia@bsid可以基于以下示例性定义：
LiveMedia-A/V服务的标识，其作为对例如正在进行的新闻报道的紧急相关信息进行调整的选择提供给用户。如果AEA@wakeup为“true”，则应存在LiveMedia元素。当LiveMedia不存在时，不存在默认值。
LiveMedia@bsid-该无符号短16位整数值列表应指示出(一个或多个)广播流的(一个或多个)标识符，该(一个或多个)广播流包含紧急相关实时A/V服务的基本部分。当LiveMedia@bsid的值是多于一个无符号短值的列表时，它应指示出应用有信道绑定的多个广播流。
在一个示例中，LiveMedia@bsid可以基于下述示例性定义：
LiveMedia@bsid-该无符号短16位整数值应指示出(一个或多个)广播流的(一个或多个)标识符，该(一个或多个)广播流包含紧急相关实时A/V服务的基本部分。
在这种情况下，LiveMedia@bsid的数据类型应为如下表格10Ia中所示的unsignedShort。
Figure BDA0001986640130000501
表格10Ia
应当注意的是在表格10I中数据类型字符串listOfunsignedShort可以对应于在由万维网联盟(W3C)所维护的XML模式定义(XSD)推荐中所提供的定义。在一个示例中，这些可以对应于在“XML Schema Part 2：Datatypes Second Edition”中所描述的定义。此外，应当注意的是基于在表格10I中所提供的示例的计算机程序列表可以基于在表格10J中所示的示例性XML模式来表达LiveMedia@bsid。应当注意的是在表格10J中所示的示例性XML模式可以包含在XML方案之中，该XML方案包括上面所述的AEAT的元素和属性，为了简洁起见在表格10J中未提供AEAT的完整XML模式。
Figure BDA0001986640130000511
表格10J
按照这种方式，基于关于表格10I或表格101a所提供的示例性结构的AEA消息可以使得接收器设备能够在利用绑定信道传送服务时针对紧急相关信息调整到A/V服务。
如上所述，水印可以用于用信号发送如在表格6中所提供的紧急警报消息，例如advanced_emergency_alert_message()。服务分发引擎300可以被配置为根据如在表格11中所提供的示例性advanced_emergency_alert_message()来产生紧急警报消息的信号。
Figure BDA0001986640130000512
Figure BDA0001986640130000521
表格11
在表格11中所示的示例中，语法元素AEA_ID_length、AEA_ID、AEA_issuer_length、AEA_issuer、effective、expires、event_code_type_length、event_code_length、event_code_type、event_code、audience、AEA_type、priority、ref_AEA_ID_flag、ref_AEA_ID_length、ref_AEA_ID、AEA_text_lang_code、AEA_text_length、AEA_text、location_type、location_length、以及location中的每一个可以基于上面关于表格6所提供的定义。语法元素num_AEA_text_minus1和num_location_minus1可以基于以下定义。
num_AEA_text_minus1-该2比特无符号整数字段加1给出了AEA消息中的AEA_text字段的编号。
num_location_minus1-该2比特无符号整数字段加1给出了AEA消息中的位置字段的编号。
如表格11所示，advanced_emergency_alert_message()可以基于范围从0到3的num_AEA_text_minus1和num_location_minus1的各自2比特值用信号发送最多四个AEA文本字符串和最多四个AEA位置字符串。应当注意的是在一个示例中，表格11可以包括24比特AEA_text_lang_code。24比特AEA_text_lang_code可以基于以下定义：
AEA_text_lang_code-24比特无符号整数字段，其应表示AEA_text字段的语言并应按照ISO 639.2/B被编码为3字符语言代码。每个字符应根据ISO 8859-1(ISO拉丁文-1)被编码为8位并按顺序插入到该字段之中。
在AEA_text_lang_code的定义中，在ISO 639-2：1998，语言名称的表示的代码-第2部分：阿尔法-3代码中描述了上述ISO 639.2/B，并且在ISO/IEC 8859-1：1998，信息技术-8位单字节编码的图形字符集-第1部分：拉丁字母No.1中描述了ISO 8859-1(ISO拉丁-1)，其每一个通过引用而被整体并入本文。
在一个示例中，服务分发引擎300可以被配置为基于表格12中所提供的示例性advanced_emergency_alert_message()来用信号发送紧急警报消息。
Figure BDA0001986640130000541
Figure BDA0001986640130000542
Figure BDA0001986640130000551
Figure BDA0001986640130000552
Figure BDA0001986640130000561
表格12
在表格12所示的示例中，语法元素AEA_type、priority、AEA_ID、AEA_issuer、audience、effective、expires、ref_AEA_ID、event_code_type、event_code、location_type、location、以及AEA_text的每一个可以基于关于表格6所提供的定义。语法元素AEA_ID_length_minus1、AEA_issuer_length_minus1、ref_AEA_ID_present_flag、event_code_present_flag、event_desc_present_flag、num_location_minus1、num_AEA_text_minus1media_present_flag、ref_AEA_ID_length_minus1、event_code_type_length_minus1、event_code_length_minus1、num_eventDesc_minus1、eventDesc_length_minus1、eventDesc_lang_length_minus1、eventDesc、eventDesc_lang、location_length_minus1、AEA_text_lang_length_minus1、AEA_text_lang、AEA_text_length_minus1、num_media_minus1、bsid、url_construction_code、media_url_string、content_size、content_size_exp、content_type_length、content_type、mediaDesc_length、media_lang_length、mediaDesc、以及mediaDesc_lang可以基于以下定义。
AEA_ID_length_minus1-该8比特无符号整数字段加1以字节为单位给出了AEA_ID字段的长度。
AEA_issuer_length_minus1-该5比特无符号整数字段加1以字节为单位给出了AEA_issuer字段的长度。
ref_AEA_ID_flag-该1比特布尔标志字段指示出AEA消息中的ref_AEA_ID字段的存在性。
event_code_present_flag-该1比特布尔标志字段指示出AEA消息中的event_code字段的存在性。
event_desc_present_flag-该1比特布尔标志字段指示出AEA消息中的event_desc字段的存在性。
num_AEA_text_minus1-该3比特无符号整数字段加1指示出AEA消息中的AEA_text字段的编号。
num_location_minus1-该3比特无符号整数字段加1指示出AEA消息中的location字段的编号。
media_present_flag-该1比特布尔标志字段指示出AEA消息中media字段的存在性。
ref_AEA_ID_length_minus1-该8比特无符号整数字段加1以字节为单位给出ref_AEA_ID字段的长度。
event_code_type_length_minus1-该3比特无符号整数字段加1以字节为单位给出event_code_type字段的长度。
event_code_length_minus1-该4比特无符号整数字段加1以字节为单位给出event_code字段的长度。
num_eventDesc_minus1-该3比特无符号整数字段加1给出AEA消息中的AEA.Header.eventDesc元素的编号。
eventDesc_length_minus1-该6比特无符号整数加1以字节为单位给出AEA.Header.eventDesc字段的长度。
eventDesc_lang_length_minus1-该6比特无符号整数字段加1以字节为单位给出AEA.Header.eventDesc@lang字段的长度。
eventDesc-该字符串应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.Header.eventDesc字符串的值。
eventDesc_lang-该字符串应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.Header.eventDesc@lang属性。
location_length_minus1-该8比特无符号整数字段加1以字节为单位给出location字段的长度。
AEA_text_lang_length_minus1-该6比特无符号整数字段加1以字节为单位给出AEA_text_lang字段的长度。
AEA_text_lang-该字符串应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.AEAtext@lang属性。
AEA_text_length_minus1-该8比特无符号整数字段加1以字节为单位给出AEA_text字段的长度。
num_media_minus1-该3比特无符号整数字段加1给出AEA消息中的media字段的编号。
bsid-该16比特标识符应指示出与服务相关联的广播流的BSID。
url_construction_code-将代替https请求中的{url_construction}使用的全局唯一的16比特url_construction_code。该url_construction_code应由ATSC所指定的注册机构来分配。
media_url_string_length_minus1-该8比特无符号整数字段加1以字节为单位给出media_url_string字段的长度。
media_url_string-该字符串应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.Media@url属性中的URL。如果media_url_string是以片段形式发送的，则重新组装后的media_url_string应仅包含按照RFC 3986的路径、查询、以及片段的URI语法组件。media_url_string应将用于构造如下的HTTPS请求：
https://{BSID_code}.{url_construction}.vp1.tv/AEA/media_url_string()，其中
{BSID_code}是16比特基站识别码的4字符十六进制表示。
{url_construction}是16比特url_construction_code的4字符十六进制表示，
上述HTTPS请求字符串应符合RFC 3986。
content_size-该10比特无符号整数应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.Media@contentLength属性的值除以content_size_exp值，向上舍入为最接近的整数。当content_size_exp是0x03时，将在0-999范围之外的content_size的值保留用于将来并且不应被使用。
content_size_exp-该2比特无符号整数指示出应用于content_size值的指数因子。该值应根据表格13编码。
代码值 单位 值
0x00 字节 1
0x01 千字节 2"10
0x02 兆字节 2"20
0x03 千兆字节 2"30
表格13
content_type_length-该4比特无符号整数以字节为单位指示出content_type字段的长度。
content_type-该字符串应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.Media@contentType属性的值。
mediaDesc_length-该6比特无符号整数以字节为单位给出了AEA.Header.media@mediaDesc字段的长度。
media_lang_length-该6比特无符号整数字段以字节为单位给出了AEA.Header.media@lang字段的长度。
mediaDesc-该字符串应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.Header.media@mediaDesc字符串的值。
mediaDesc_lang-该字符串应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.Header.media@lang属性。
在一个示例中，语法元素num_AEA_text_minus1和num_location_minus1可以基于以下定义。
num_AEA_text_minus1-该2比特无符号整数字段加1给出了AEA消息中的AEA_text字段的编号。
num_location_minus1-该2比特无符号整数字段加1给出了AEA消息中的比特置字段的编号。
在这种情况下，media_present_flag之后的保留值可以是3比特并且在一个示例中是'111'。
此外，在一个示例中，表格12中的AEA消息中的media字段可以如表格14A中所提供的那样被格式化。
Figure BDA0001986640130000611
Figure BDA0001986640130000621
表格14A
在表格14A所示的示例中，语法元素num_media_minus1、media_url_string_length_minus1、content_size、content_size_exp、content_type_length、content_type、mediaDesc_length、media_lang_length、mediaDesc；、以及mediaDesc_lang的每一个可以基于以上关于表格12所提供的定义。语法元素entity_length_minus1、entity_string、以及media_url_string可以基于以下定义。
entity_length_minus1-8比特无符号整数加1应用信号发送接下来的entity_string中的字符数。
entity_string-该字符串应为其至少是由顶级域名和二级域名所组成的IANA注册的域名。可能存在更高级别的域。句点字符(“.”)应包含在顶级、二级、以及任何更高级别的域之间。entity_string的长度应由entity_length_minus1的值加1给出。
media_url_string-该字符串应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.Media@url属性中的URL。
期望接收器通过以下过程形成将用于检索引用内容的URL。该URL应是通过使entity_string附加字符串“.2.vp1.tv/”并随后是media_url_string的来形成的。如果是以片段形式发送的，则重新组装后的media_url_string()应为按照RFC 3986的有效URL并且应仅包含按照RFC 3986的路径、查询、以及片段的URI语法组件。media_url_string()应将用于构造如下的HTTPS请求：
https://entity_string.2.vp1.tv/media_url_string
按照这种方式，服务分发引擎300可以被配置为用信号发送语法元素，该语法元素用于指示出其应用于与紧急警报消息相关联的媒体资源的大小的指数因子，并且用信号发送用于指示出媒体资源的大小的语法元素。
在一个示例中，服务分发引擎300可以被配置为基于表格14B中所提供的示例性advanced_emergency_alert_message()来用信号发送紧急警报消息。
Figure BDA0001986640130000631
Figure BDA0001986640130000641
Figure BDA0001986640130000642
Figure BDA0001986640130000651
Figure BDA0001986640130000652
Figure BDA0001986640130000661
表格14B
在表格14B所示的示例中，语法元素的AEA_ID_length_minus1、AEA_type、priority、AEA_issuer_length_minus1、AEA_ID、AEA_issuer、audience、event_code_present_flag、event_desc_present_flag、num_location_minus1、num_AEA_text_minus1、ref_AEA_ID_present_flag media_present_flag、effective、expires、ref_AEA_ID_length_minus1、ref_AEA_ID、event_code_type_length_minus1、event_code_length_minus1、event_code_type、event_code、num_eventDesc_minus1、eventDesc_length_minus1、eventDesc_lang_length_minus1、eventDesc、eventDesc_lang、location_type、location_length_minus1、location、AEA_text_lang_length_minus1、AEA_text_lang、AEA_text_length_minus1、AEA_text、num_media_minus1、media_url_string_length_minus1、content_size、content_size_exp、content_type_length、content_type、mediaDesc_length、mediaDesc_lang_length、mediaDesc、以及mediaDesc_lang每一个可以基于以上关于表格6、12、以及14A所提供的定义。在一个示例中，语法元素num_location_minus1和AEA_text可以基于以下定义：
num_location_minus1-该3比特无符号整数字段加1应指示出AEA消息中的location字段的编号。值0x07保留以供将来使用。
AEA_text-该字符串应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.AEAtext元素的UTF-8[Unicode转换格式8比特块，例如RFC 3629]字符编码值。
在表格14B所示的示例中，语法元素LiveMedia_present_flag、AEAwakeup_flag、LiveMedia_strlen_minus1、LiveMedia_lang_length、LiveMedia_string、LiveMedia_lang、entity_strlen_minus1、domain_code、entity_string、media_url_string、mediaType_code、mediaAssoc_present_flag、mediaAssoc_stlen_minus1、以及mediaAssoc_string的每一个可以基于以下定义：
LiveMedia_present_flag-该1比特布尔标志字段当被设置为“1”时应指示出AEA消息中的LiveMedia_string字段的存在。
AEAwakeup_flag-该1比特布尔标志字段应为在[A/331]中所定义的可选AEAT.AEA@wakeup属性的值。当AEAT.AEA@wakeup属性不存在时，该字段应被设置为“0”。应当注意的是在一些示例中AEAwakeup_flag可以不包含在表格14B中。
LiveMedia_strlen_minus1-该6比特无符号整数字段加1应以字节为单位指示出LiveMedia_string字段的长度。
LiveMedia_string-该字符串应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.LiveMedia.ServiceName元素。
LiveMedia_lang_length-该6比特无符号整数字段应以字节为单位指示出LiveMedia_lang字段的长度。
LiveMedia_lang-该字符串应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.LiveMedia.ServiceName@lang属性。
entity_strlen_minus1-该5比特无符号整数加1应用信号发送接下来的entity_string()中的字符数。
domain_code-根据表格15，该8比特无符号整数应指示出应用于标识要用于URL构造的域的标识符代码。
domain_code值 domain_string()
0x00 “vp1.tv”
0x01-0xFF 保留
表格15
entity_string()-该字符串应为RFC 3986URL的一部分，并且应仅是由未保留字符组成的(如在RFC 3986第2.3节中定义的)，以便该advanced_emergency_alert_message_message()所传送的URL符合RFC3986。entity_string()的长度应由entity_strlen_minus1的值加1给出。
media_url_string-该字符串应为RFC 3986URL的一部分，以便所传送的URL符合RFC 3986。字符串的长度应由media_uri_string_length_minus1的值加1给出。URL应为“https”后跟entity_string()、后跟”.“(句点)、后跟domain_string()、后跟”/“(正斜杠)、后跟media_url_string()的串接。如果是以片段形式发送的，则重新组装之后的该URL应为按照RFC 3986的有效URL。因此，如下组装URL：
https://entity_string().domain_string()/media_url_string()
mediaType_code-根据表格16，该3比特无符号整数应指示出在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.Header.Media@mediaType字符串。
MediaType_code值 domain_string()
0 “EventDescAudio”
1 “AEAtextAudio”
2 “EventSymbol”
3-7 保留
表格16
mediaAssoc_present_flag-该1比特布尔标志字段当被设置为“1”时应指示出AEA消息中的mediaAssoc字段的存在。
mediaAssoc_strlen_minus1-该8比特无符号整数字段加1应以字节为单位指示出mediaAssoc_string字段的长度。
mediaAssoc_string-该字符串应具有等于在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.Media@mediaAssoc属性的值。
在一个示例中，服务分发引擎300可以被配置为基于在表格14C中所提供的示例性advanced_emergency_alert_message()来用信号发送紧急警报消息。
Figure BDA0001986640130000701
Figure BDA0001986640130000702
Figure BDA0001986640130000711
表格14C
在表格14C所示的示例中，语法元素domain_code、entity_strlen_minus1、entity_string、AEA_ID_length_minus1、AEA_type；priority、AEA_issuer_length_minus1、AEA_ID、AEA_issuer、audience、ref_AEA_ID_present_flag、AEAwakeup_flag、effective、expires、ref_AEA_ID_length_minus1、ref_AEA_ID、eventDesc_length_minus1、eventDesc、AEA_text_lang_length_minus1、以及AEA_text_lang的每一个可以基于上面关于表格6、12、14A、以及14B所提供的定义。
在表格14C所示的示例中，语法元素AEATurl_present_flag、AEAT_url_strlen_minus1、AEAT_url_string,langlen_code、num_AEAtext、num_eventDesc、eventDesc_lang、以及AEA_text_lang的每一个可以基于以下定义：
AEATurl_present_flag-该1比特布尔标志字段当被设置为“1”时应指示出AEA消息中的AEAT URL字段的存在。
AEAT_url_strlen_minus1-该8比特无符号整数字段加1以字节为单位给出了AEAT_url_string字段的长度。
AEAT_url_string-该字符串应为RFC 3986[REF]URL的一部分，以便所传送的URL符合RFC 3986。字符串的长度应由AEAT_uri_strlen_minus1的值加1给出。URL应为“https：//”后跟entity_string()、后跟“.”(句点)、后跟domain_string()、后跟“/”(正斜杠)、后跟AEAT_url_string()的串接。在重新组装后，如果是以片段形式发送的，则该URL应为按照RFC 3986的有效URL。因此，如下组装URL：
https://entity_string().domain_string()/AEAT_url_string()
接收器可以使用上述https向服务器呼叫以下载在[A/331]中所定义的XML格式的AEAT。
langlen_code-该1比特字段当被设置为'1'时应指示出AEA消息中的2-字符language_code字段的使用，当被设置为'0'时应指示出AEA消息中的5-字符language_code字段的使用。
num_AEAtext-该2比特无符号整数字段应指示出AEA消息中的AEA_text字段的编号。值0x00和0x03保留以供将来使用。
num_eventDesc-该2比特无符号整数字段应指示出AEA消息中的AEA.Header.eventDesc元素的编号。0x03的值保留以供将来使用。
eventDesc_lang-该2或5-字符字符串应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.eventDesc@lang属性。英语的2-字符字符串的示例可以是“en”，并且英语的5-字符字符串可以是“en-US”。
AEA_text_lang-该2或5-字符字符串应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA.AEAtext@lang属性。英语的2-字符字符串的示例可以是“en”，并且英语的5-字符字符串可以是“en-US”。
按照这种方式，服务分发引擎300可以被配置为用信号发送语法元素，该语法元素指示出用于识别将用于通用资源定位符构造的域的标识符代码，并且用信号发送用于提供通用资源定位符片段的字符串的语法元素。按照这种方式，服务分发引擎300可以被配置为用信号发送语法元素，该语法元素用于指示出紧急警报消息的语言是由两个字符的字符串还是五个字符的字符串表示，并且用信号发送用于提供其指示出紧急警报消息的语言的字符串的语法元素。
图4是用于对可以实现本公开的一个或多个技术的接收器设备的示例的方框图。也就是说，接收器设备400可以被配置为根据上面关于上述一个或多个表格所描述的语义来解析信号。在一个示例中，接收器设备400可以被配置为根据上述示例性语义的任何组合来接收紧急警报消息、对其进行解析、并且此后采取动作。此外，接收器设备400可以被配置为使得能够检索与紧急警报消息相关联的媒体内容。例如，接收器设备可以被配置为暂时中止应用和/或改变渲染多媒体呈现的方式(例如对于一个或多个服务而言指定的持续时间)以便增加用户了解与紧急警报消息相关联的媒体内容可用的可能性。此外，在一个示例中，接收器设备400可以被配置为使得用户能够设置接收器设备400如何处理与紧急警报消息相关联的媒体内容。例如，用户可以在设置菜单中设置以下偏好之一：对要检索的媒体类型的偏好、对要选择性检索的某些类型的媒体的偏好、以及从不检索某些类型的媒体的偏好。
接收器设备400是可以被配置为通过一个或多个类型的数据信道接收来自通信网络的数据并且允许用户访问多媒体内容的计算设备的示例。在图4所示的示例中，接收器设备400被配置为经由诸如例如如上所述的电视服务网络204的电视网络接收数据。此外，在图4所示的示例中，接收器设备400被配置为经由广域网发送和接收数据。应当注意的是在其他示例中接收器设备400可以被配置为简单地经由电视服务网络204接收数据。被配置为利用通信网络的任何和所有组合进行通信的设备可用使用这里所述的技术。
如图4中所示，接收器设备400包括中央处理单元402、系统存储器404、系统接口410、数据提取器412、音频解码器414、音频输出系统416、视频解码器418、显示系统420、(一个或多个)I/O设备422、以及网络接口424。如图4所示，系统存储器404包括操作系统406、应用408、以及文档解析器409。(一个或多个)中央处理单元402、系统存储器404、系统接口410、数据提取器412、音频解码器414、音频输出系统416、视频解码器418、显示系统420、(一个或多个)I/O设备422、以及网络接口424中的每一个可以互连(物理地、通信地、和/或可操作地)以进行组件间通信，并且可以是作为诸如一个或多个微处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、离散逻辑、软件、硬件、固件、或其任何组合的各种适当电路中的任何一个而实现的。应当注意的是尽管接收器设备400被说明为具有不同功能块，但是这样的说明是出于描述的目的，并且不将接收器设备400限制为特定硬件架构。可以使用硬件、固件、和/或软件实现的任何组合来实现接收器设备400的功能。
(一个或多个)CPU 402可以被配置为实现用于在接收器设备400中执行的功能和/或处理指令。(一个或多个)CPU 402可以包括单核和/或多核中央处理单元。(一个或多个)CPU 402可以能够检索和处理用于实现这里所述的一个或多个技术的指令、代码、和/或数据结构。可以将指令存储在诸如系统存储器404的计算机可读介质上。
系统存储器404可以被描述为非暂时性或有形计算机可读存储介质。在一些示例中，系统存储器404可以提供临时和/或长期存储。在一些示例中，系统存储器404或其部分可以被描述为非易失性存储器并且在其他示例中，系统存储器404的部分可以被描述为易失性存储器。系统存储器404可以被配置为存储可以在操作期间由接收器设备400使用的信息。系统存储器404可以用于存储由CPU 402执行的程序指令并且可以由在接收器设备400上运行的程序使用以在程序执行期间临时存储信息。此外，在接收器设备400被包括以作为数字视频记录器的一部分的示例中，系统存储器404可以被配置为存储许多视频文件。
应用408可以包括在接收器设备400内实现或由接收器设备400执行的应用，并且可以被实现或包含在接收器设备400的组件内、可由接收器设备400的组件操作、执行和/或与接收器设备400的组件可操作地和/或可通信地相耦合。应用408可以包括可以使接收器设备400的CPU 402执行特定功能的指令。应用408可以包括以诸如例如for循环、while循环、if语句、do循环等的计算机编程语句所表达的算法。可以使用指定编程语言来开发应用408。编程语言的示例包括JavaTM、JiniTM、C、C++、Objective C、Swift、Perl、Python、PhP、UNIX Shell、Visual Basic、以及Visual Basic Script。在接收器设备400包括智能电视的示例中，应用可以由电视制造商或广播公司开发。如图4中所示，应用408可以结合操作系统406执行。也就是说，操作系统406可以被配置为便于应用408与(一个或多个)CPU 402以及接收器设备400的其他硬件组件的交互。操作系统406可以是其被设计为安装在机顶盒、数字视频录像机、电视机等上的操作系统。应当注意的是被配置为利用软件架构的任何和所有组合进行操作的设备可以使用这里所述的技术。
如上所述，应用可以是构成增强或交互式服务的文档的集合。此外，文档可以用于根据协议来描述紧急警报等。文档解析器409可以被配置为对文档进行解析并且使得对应功能发生在接收器设备400处。例如，文档解析器409可以被配置为从文档解析出URL并且接收器设备400可以检索与URL相对应的数据。
系统接口410可以被配置为使得能够在接收器设备400的组件之间进行通信。在一个示例中，系统接口410包括使得数据能够从一个对等设备传输到另一个对等设备或传输到存储介质的结构。例如，系统接口410可以包括芯片组，该芯片组支持基于加速图形端口(AGP)的协议、基于外围组件互连(PCI)总线的协议——诸如例如PCI ExpressTM(PCIe)总线规范的由外围组件互连特殊兴趣组维护、或者可以用于使对等设备互连的任何其他形式的结构(例如专有总线协议)。
如上所述，接收器设备400被配置为经由电视服务网络接收并且可选地发送数据。如上所述，电视服务网络可以根据电信标准进行操作。电信标准可以定义诸如例如物理信令、寻址、信道访问控制、分组属性、以及数据处理的通信属性(例如协议层)。在图4所示的示例中，数据提取器412可以被配置为从信号中提取视频、音频、以及数据。可以根据例如方面DVB标准、ATSC标准、ISDB标准、DTMB标准、DMB标准、以及DOCSIS标准来定义信号。数据提取器412可以被配置为从上述服务分发引擎300所产生的信号中提取视频、音频、以及数据。也就是说，数据提取器412可以以与服务分发引擎300相互的方式进行操作。
数据分组可以由(一个或多个)CPU 402、音频解码器414、以及视频解码器418进行处理。音频解码器414可以被配置为接收音频分组并对其进行处理。例如，音频解码器414可以包括被配置为实现音频编解码器的各方面的硬件和软件的组合。也就是说，音频解码器414可以被配置为接收音频分组并将音频数据提供给音频输出系统416以进行渲染。可以使用诸如由杜比和数字影院系统所开发的格式的多通道格式对音频数据进行编码。可以使用音频压缩格式对音频数据进行编码。音频压缩格式的示例包括运动图像专家组(MPEG)格式、高级音频编码(AAC)格式、DTS-HD格式、以及杜比数字(AC-3、AC-4等)格式。音频输出系统416可以被配置为对音频数据进行渲染。例如，音频输出系统416可以包括音频处理器、数字-模拟转换器、放大器、以及扬声器系统。扬声器系统可以包括诸如耳机、集成立体声扬声器系统、多扬声器系统、或环绕声系统的各种扬声器系统中的任何一种。
视频解码器418可被配置为接收视频分组并对其进行处理。例如，视频解码器418可以包括用于实现视频编解码器的各方面的硬件和软件的组合。在一个示例中，视频解码器418可以被配置为对根据任何数量的视频压缩标准所编码的视频数据进行解码，诸如ITU-T H.262或ISO/IEC MPEG-2Visual、ISO/IEC MPEG-4Visual、ITU-T H.264(还被称为ISO/IEC MPEG-4高级视频编码(AVC))、以及高效视频编码(HEVC)。显示系统420可以被配置为检索视频数据并对进行处理以供显示。例如，显示系统420可以接收来自视频解码器418的像素数据并输出该数据以供视觉呈现。此外，显示系统420可以被配置为结合视频数据输出图形，例如图形用户界面。显示系统420可以包括诸如液晶显示器(LCD)、等离子显示器、有机发光二极管(OLED)显示器、或者能够向用户呈现视频数据的其他类型的显示设备的各种显示设备中的一种。显示设备可以被配置为显示标准清晰度内容、高清晰度内容、或超高清内容。
(一个或多个)I/O设备422可以被配置为在接收器设备400的操作期间接收输入并提供输出。也就是说，(一个或多个)I/O设备422可以使得用户能够选择要呈现的多媒体内容。输入可以是从诸如例如按钮式遥控器、包括触敏屏幕的设备、基于运动的输入设备、基于音频的输入设备、或者被配置为接收用户输入的任何其他类型的设备的输入设备产生的。可以使用诸如例如通用串行总线协议(USB)、蓝牙、ZigBee、或诸如例如专有红外通信协议的专有通信协议的标准化通信协议使I/O设备422可操作地与接收器设备400相耦合。
网络接口424可以被配置为使得接收器设备400能够通过局域网和/或广域网发送和接收数据。网络接口424可以包括诸如以太网卡、光学收发器、射频收发器、或者被配置为发送和接收信息的任何其他类型的设备的网络接口卡。网络接口424可以被配置为根据在网络中所使用的物理和媒体访问控制(MAC)层来执行物理信令、寻址、以及信道访问控制。接收器设备400可以被配置为对根据以上关于图3所描述的任何技术所产生的信号进行解析。此外，接收器设备400可以被配置为根据一个或多个通信技术将数据发送到配套设备以及接收来自配套设备的数据。
图5是用于对可以实现本发明的一个或多个技术的配套设备的示例进行说明的方框图。配套设备500可以包括一个或多个处理器以及多个内部和/或外部存储设备。配套设备500是被配置为接收内容信息通信消息的设备的示例。配套设备500可以包括在其上运行的一个或多个应用，该应用可以利用包括在内容信息通信消息之中的信息。配套设备500可以配备用于有线和/或无线通信并且可以包括诸如台式或膝上型计算机、移动设备、智能电话、蜂窝电话、个人数据助理(PDA)、平板设备、以及个人游戏设备的设备。
如图5所示，配套设备500包括(一个或多个)中央处理单元502、系统存储器504、系统接口510、(一个或多个)存储设备512、(一个或多个)I/O设备514、以及网络接口516。如图5所示，系统存储器504包括操作系统506和应用508。应当注意的是尽管示例性配套设备500被示为具有不同的功能块，但是这样的说明是出于描述的目的，并且不是将配套设备500限制为特定硬件或软件架构。可以使用硬件、固件、和/或软件实现的任何组合来实现配套设备500的功能。
(一个或多个)中央处理单元502、系统存储器504、以及系统接口510中的每一个可以与上述(一个或多个)中央处理单元502、系统存储器504、以及系统接口510相似。(一个或多个)存储设备512表示配套设备500的存储器，该存储器可以被配置为存储比系统存储器504更大量的数据。例如，(一个或多个)存储设备512可以被配置为存储用户的多媒体集合。与系统存储器504相似，(一个或多个)存储设备512还可以包括一个或多个非暂时性或有形计算机可读存储介质。(一个或多个)存储设备512可以是内部或外部存储器，并且在一些示例中可以包括非易失性存储元件。(一个或多个)存储设备512可以包括存储卡(例如包括标准容量(SDSC)、高容量(SDHC)、以及扩展容量(SDXC)格式的安全数字(SD)存储卡)、外部硬盘驱动器、和/或外部固态驱动器。
(一个或多个)I/O设备514可以被配置成为计算设备514接收输入并提供输出。输入可以是从诸如例如触敏屏、跟踪板、跟踪点、鼠标、小键盘、麦克风、摄像机、或者被配置为接收输入的任何其他类型的设备的输入设备产生的。可以将输出提供给诸如例如扬声器或显示设备的输出设备。在一些示例中，(一个或多个)I/O设备514可以在配套设备500外部并且可以使用诸如例如通用串行总线(USB)协议的标准化通信协议可操作地与配套设备500相耦合。
网络接口516可以被配置为使得配套设备500能够与诸如接收器设备400和其他设备或服务器的外部计算设备进行通信。此外，在配套设备500包括智能电话的示例中，网络接口516可以被配置为使得配套设备500能够与蜂窝网络进行通信。网络接口516可以包括诸如以太网卡、光学收发器、射频收发器、或者可发送和接收信息的任何其他类型的设备的网络接口卡。网络接口516可以被配置为根据诸如例如全球系统移动通信(GSM)标准、码分多址(CDMA)标准、第三代合作伙伴计划(3GPP)标准、互联网协议(IP)标准、无线应用协议(WAP)标准、蓝牙、ZigBee、和/或诸如一个或多个802.11标准的IEEE标准、以及其各种组合的一个或多个通信协议进行操作。
如图5中所示，系统存储器504包括操作系统506以及存储在其上的应用508。操作系统506可以被配置为便于应用508与(一个或多个)中央处理单元502以及配套设备500的其他硬件组件的交互。操作系统506可以是被设计为安装在膝上型计算机和台式机上的操作系统。例如，操作系统506可以是Windows(注册商标)操作系统、Linux、或者Mac OS。操作系统506可以是被设计为安装在智能手机、平板电脑、和/或游戏设备上的操作系统。例如，操作系统506可以是Android、iOS、WebOS、Windows Mobile(注册商标)、或者Windows Phone(注册商标)操作系统。应当注意的是这里所述的技术不限于特定操作系统。
应用508可以是在配套设备500内实现的或由配套设备500执行的任何应用，并且可以被实现或包含在配套设备500的组件内、可由配套设备500的组件操作、由配套设备500的组件执行、和/或与配套设备500的组件可操作地和/或可通信地相耦合。应用508可以包括可以使得配套设备500的(一个或多个)中央处理单元502执行特定功能的指令。应用508可以包括以诸如例如for循环、while循环、if语句、do循环等的计算机编程语句所表达的算法。此外，应用508可以包括第二屏幕应用。
如上所述，接收器设备400可以被配置为根据上述示例性语义的任何组合来接收紧急警报消息、对其进行解析、并且此后采取动作。在一个示例中，接收器设备400可以被配置为将包括在紧急警报消息中的信息传递到配套设备，例如配套设备500。在该示例中，接收器设备400可以被称为“主设备”。配套设备500和/或应用508可以被配置为接收信息并对内容信息进行解析以供在第二屏幕应用中使用。在一个示例中，接收器设备400可以被配置为根据基于JSON的模式将包括在紧急警报消息中的信息传递到配套设备。ATSC候选标准：配套设备(A/338)2015年12月2日批准的Doc.S33-161r1-配套设备(以下称“A/338”)——其整个内容通过引用而被并入——描述了所提议的用于在ATSC 3.0主设备与ATSC 3.0配套设备之间进行通信的通信协议。表格17A描述了根据基于JSON的模式的AEAT元素的结构。图6A-6B是基于在表格17A中所提供的示例的计算机程序列表。应当注意的是关于表格17A，分别用信号发送媒体内容类型(即MIME类型)和媒体描述。按照这种方式，接收器设备400可以被配置为根据在表格17A中所提供的示例性模式向配套设备500发送消息以便配套设备500检索媒体内容。例如，用户具有使用配套设备来检索某些类型的媒体(例如.pdf文件)的偏好。
Figure BDA0001986640130000811
Figure BDA0001986640130000821
表格17A
应当注意的是包括在表格17A中的元素和属性的语义通常对应于上面关于表格2、表格6、以及表格10A-10F所提供的那些，并且为了简洁起见对应于除以下元素和属性的语义之外的示例性正式定义：
Header-该对象应包含警报的相关封装信息，其包括警报类型(EventCode)、警报有效的时间(effective)、到期时间(expires)、以及目标警报区域的位置(Location)。
Header.effective-该日期-时间应包含警报消息的有效时间。应根据JSON“type”：“string”以及“format”：“date-time”来表示该日期-时间。
Header.expires-该日期-时间应包含警报消息的到期时间。应根据JSON“type”：“string”以及“format”：“date-time”来表示该日期-时间。
EventCode-对象，其提供与事件代码值和事件类型有关的信息。
EventCode.value-字符串，其用于标识警报消息的事件类型，该事件类型被格式化为用于表示值本身(例如，在美国，值“EVI”将用于表示疏散告警)的字符串(可以表示数字)。值可能因国家之间而不同，并且可能是字母数字代码，或者可能是纯文本。对于每个AEA消息应仅存在一个EventCode。
EventCode.type-该属性应为国家指定的字符串值，该字符串值应指定EventCode的域(例如，在美国，“SAME”表示标准FCC第11部分EAS编码)。作为首字母缩略词的类型的值应以所有大写字母表示而没有句点。
Location-对象，其提供与地理位置值和位置类型有关的信息。
Location.value-字符串，其用于描述具有基于地理位置的代码的消息目标。
Location.type-该属性应为用于标识位置代码的域的字符串。
AEAtext-对象，其提供与高级紧急警报消息文本值和文本的语言有关的信息。
AEAtext.value-紧急消息的纯文本字符串。每个AEAtext元素应仅包含一个lang属性。对于多种语言的同一警报的AEAtext，该元素应要求多个AEAtext元素的存在。
在一个示例中，接收器设备400可以被配置为基于在表格17B中所示的结构、根据基于JSON的方案将包括在紧急警报消息之中的信息传递到配套设备。图7A-7B是基于在表格17B中所提供的示例的计算机程序列表。
Figure BDA0001986640130000841
Figure BDA0001986640130000851
表格17B
应当注意的是包括在表格17B中的元素和属性的语义通常对应于以上关于表格2、表格6、表格10A-10I、以及表格17A所提供的那些，并且为了简洁起见对应于除以下元素和属性的语义之外的示例性正式定义：
AEA.wakeup-该可选布尔属性当存在且被设置为“true”时应指示出AEA与non-zero ea_wake_up位相关联(参见ATSC 3.0候选标准A/331的附录G.2)。当不存在时，默认值应为“false”。该值应为在[A/331]中所定义的当前高级紧急警报消息的AEAT.AEA@wakeup属性的值。
Location.type-该属性应为用于标识位置代码的域的字符串。应当注意的是某些主设备和配套设备可能无法确定它们是否位于用信号发送的警报的位置区域之内。建议此类主设备和配套设备如其位于警报的区域之内地来对警报进行处理。
如果类型等于“FIPS”，则Location应被定义为由逗号分隔开的一个或多个数字字符串的组。按照在47CFR11.31中定义为PSSCCC的方式，每6比特数字字符串应为如在FIPS[FIPS]中所定义的县级子划分、州、以及县代码的串接。另外，代码“000000”应指美国及其领土内的所有位置，并且代码“999999”应指该AEAT所源自的站的覆盖区域内的所有位置。
如果类型等于“SGC”，则Location应被定义为由逗号分隔开的一个或多个数字字符串的组。每个数字串应为如在SGC中所定义的2位数字省(PR)、2位数字人口普查区(CD)、以及3位数字人口普查细分(CSD)的串接。另外，代码“00”应指加拿大境内的所有位置，并且代码“9999”应指该AEAT所源自的站的覆盖区域内的所有位置。
如果类型＝“polygon”，则Location应定义下述地理空间区域：该区域由其形成了封闭的非自相交环的四个或更多个坐标对的连接序列组成。
如果类型等于“circle”，则Location应定义由下述中心点所表示的圆形区域：该中心点是作为坐标对后跟空格字符和以千米为单位的半径值所给出的。
类型的文本值区分大小写，并且应以全部大写字母表示，但“polygon”和“circle”除外。
该字符串的值应等于在ATSC 3.0候选标准A/331中所定义的当前高级紧急警报消息的AEAT.AEA.Header.Location@type属性的值。
LiveMedia-用于提供对A/V服务的标识的对象，其可以作为对例如正在进行的新闻报道的紧急相关信息进行调整的选择呈现给用户。如果AEA.wakeup为“true”，则应存在LiveMedia元素。
Media.mediaDesc-字符串，其以纯文本形式描述媒体资源的内容。描述应指示出媒体信息。例如“疏散地图”或“多普勒雷达图像”等。应推断Media.mediaDesc的语言与在Media.lang中所指示出的语言相同。接收器可以使用该信息以向观看者呈现观看者可以选择以供渲染的媒体项列表。如果未提供该字段，则接收器可以在观看者UI中呈现项的通用文本(例如，如果@contentType指示出项是视频，则接收器可以在UI列表中将该项描述为“视频”)。
Media.mediaType-该字符串应标识关联媒体的预期用途。应当注意的是与在列表中呈现给用户以供选择的媒体相反，利用该属性所标识的媒体项典型地与接收器的警报用户界面所自动处理的项相关联。该字符串的值应具有等于在ATSC 3.0候选标准A/331中所定义的当前高级紧急警报消息的AEAT.AEA.Media@mediaType元素的值。
Media.uri-必需属性，其应确定多媒体资源文件或分组的源。当通过宽带递送富媒体资源时，该属性应被形成为绝对URL并引用远程服务器上的文件。当通过广播ROUTE递送富媒体资源时，该属性应被形成为相对URL。相对URL应与用于递送文件的LCT信道的EFDT中的相应文件元素的Content-Location属性或者文件的实体报头相匹配。在ATSC 3.0候选标准A/331中定义了EFDT和LCT信道。
Media@mediaAssoc-可选属性，其包含与该媒体资源相关联的另一富媒体资源的Media@url。示例包括与视频相关联的隐藏字幕轨道。Media.mediaAssoc的构建应如上面在Media.uri中所描述的。该值应为在ATSC 3.0候选标准A/331中所定义的当前高级紧急警报消息的AEAT.AEA.Media@mediaAssoc属性的值。
此外，应当注意的是在一些示例中接收器设备400可以被配置为基于示例性模式向配套设备500发送消息，该示例性模式包括通常与上面关于表格10A-10I所提供的那些相对应的元素和属性。
按照这种方式，接收器设备400可以被配置为接收来自服务提供者的紧急警报消息，对用于指示出唤醒属性的值的语法元素进行解析，并且至少部分地根据该语法元素来执行动作。
在一个或多个示例中，所描述的功能可以是以硬件、软件、固件、或其任何组合来实现的。如果是以软件实现的，那么该功能可以作为一个或多个指令或代码而存储在计算机可读介质上或通过一个或多个指令或代码而传送到计算机可读介质并由基于硬件的处理单元来执行。计算机可读介质可以包括与诸如数据存储介质的有形介质相对应的计算机可读存储介质或者下述通信介质：该通信介质包括便于例如根据通信协议将计算机程序从一个地方传输到另一个地方的任何介质。按照这种方式，计算机可读介质通常可以对应于(1)其是非暂时性的有形计算机可读存储介质或者(2)诸如信号或载波的通信介质。数据存储介质可以是可由一个或多个计算机或一个或多个处理器访问以检索用于实现在本公开中所描述的技术的指令、代码、和/或数据结构的任何可用介质。计算机程序产品可包括计算机可读介质。
作为示例而非限制，这种计算机可读存储介质可包括RAM、ROM、EEPROM、CD-ROM、或其他光盘存储器、磁盘存储器、或其他磁存储设备、闪存、或者用于以指令或数据结构的形式存储期望的程序代码并可由计算机访问的任何其他介质。此外，任何连接被适当地称为计算机可读介质。例如，如果使用同轴电缆、光纤电缆、双绞线、数字用户线(DSL)、或者诸如红外线、无线电、以及微波的无线技术从网站、服务器、或者其他远程源传送指令，则同轴电缆、光纤电缆、双绞线、DSL、或者诸如红外线、无线电、以及微波无线技术都包括在介质的定义中。然而，应该理解的是计算机可读存储介质和数据存储介质不包括连接、载波、信号、或其他暂时性介质，而是指非暂时性有形存储介质。这里所使用的盘(disk)和碟(disc)包括压缩盘(CD)、激光盘、光盘、数字通用盘(DVD)、软盘、以及蓝光盘，其中盘(disk)通常磁性地再现数据，而碟(disc)利用激光光学地再现数据。上述的组合也应包含在计算机可读介质的范围之内。
可以由诸如一个或多个数字信号处理器(DSP)、通用微处理器、专用集成电路(ASIC)、现场可编程逻辑阵列(FPGA)、或者其他等效集成或离散逻辑电路的一个或多个处理器来执行指令。因此，这里所使用的术语“处理器”可以指任何前述结构或者适合于实现这里所述技术的任何其他结构。另外，在一些方面中，这里所述的功能可以提供于被配置为用于编码和解码的专用硬件和/或软件模块之内或者并入在组合的编解码器中。此外，这些技术可以完全在一个或多个电路或逻辑元件中实现。
本公开的技术可以是在包括无线手持机、集成电路(IC)、或IC组(例如芯片组)的各种各样的设备或装置中实现的。在本公开中描述了各种组件、模块、或单元以强调被配置为执行所公开的技术的设备的功能方面，但不一定需要由不同硬件单元来实现。而是，如上所述，可以将各种单元组合在编解码器硬件单元中或者由包括如上所述的一个或多个处理器的互操作硬件单元的集合结合适当软件和/或固件来提供。
此外，在上述每个实施例中所使用的基站设备和终端设备(视频解码器和视频编码器)的每个功能块或各种特征可以由下述电路实现或执行：该电路典型地是集成电路或多个集成电路。被设计成执行在本说明书中所述的功能的电路可以包括通用处理器、数字信号处理器(DSP)、专用或通用应用集成电路(ASIC)、现场可编程门阵列(FPGA)、或者其他可编程逻辑器件、离散门或晶体管逻辑、或分立硬件组件、或其组合。通用处理器可以是微处理器，或者替代地，处理器可以是传统处理器、控制器、微控制器、或状态机。上述通用处理器或每个电路可以由数字电路来配置或者可以由模拟电路来配置。此外，当由于半导体技术的进步而出现了制成用于取代当前集成电路的集成电路的技术时，也能够使用通过该技术的集成电路。
已经描述了各种示例。这些和其他示例在以下权利要求的范围之内。
<概要>
根据本公开的一个示例，一种用于用信号发送与紧急警报消息相关联的信息的方法包括：用信号发送指示与紧急警报消息相关联的媒体资源的内容类型的语法元素；以及用信号发送用于提供对媒体资源的描述的语法元素。
根据本公开的另一示例，一种用于用信号发送与紧急警报消息相关联的信息的设备包括一个或多个处理器，该一个或多个处理器被配置为：用信号发送指示与紧急警报消息相关联的媒体资源的内容类型的语法元素；并且用信号发送用于提供对媒体资源的描述的语法元素。
根据本公开的另一示例，一种装置包括：用于用信号发送指示与紧急警报消息相关联的媒体资源的内容类型的语法元素的部件；以及用于用信号发送用于提供对媒体资源的描述的语法元素的部件。
根据本公开的另一示例，一种非暂时性计算机可读存储介质包括存储在其上的指令，所述指令在执行时使得设备的一个或多个处理器用信号发送指示与紧急警报消息相关联的媒体资源的内容类型的语法元素，并且用信号发送用于提供对媒体资源的描述的语法元素。
根据本公开的一个示例，一种用于检索与紧急警报相关联的媒体资源的方法包括：接收来自服务提供者的紧急警报消息；对指示与紧急警报消息相关联的媒体资源的内容类型的语法元素进行解析；以及至少部分地基于指示内容类型的语法元素来确定是否检索媒体资源。
根据本公开的另一示例，一种用于检索与紧急警报相关联的媒体资源的设备包括一个或多个处理器，该一个或多个处理器被配置为：接收来自服务提供者的紧急警报消息；对指示与紧急警报消息相关联的媒体资源的内容类型的语法元素进行解析；并且至少部分地基于指示内容类型的语法元素来确定是否检索媒体资源。
根据本公开的另一示例，一种装置包括用于接收来自服务提供者的紧急警报消息，对指示与紧急警报消息相关联的媒体资源的内容类型的语法元素进行解析，并且至少部分地基于指示内容类型的语法元素是否检索媒体资源部件。
根据本公开的另一示例，一种非暂时性计算机可读存储介质包括存储在其上的指令，所述指令在执行时使得设备的一个或多个处理器接收来自服务提供者的紧急警报消息，对指示与紧急警报消息相关联的媒体资源的内容类型的语法元素进行解析，并且至少部分地基于指示内容类型的语法元素来确定是否检索媒体资源。
在附图和以下描述中阐述了一个或多个示例的细节。从说明书、附图以及权利要求将显而易见地得知其他特征、目的、以及优点。

Claims (19)

1.一种用于用信号发送与紧急警报消息相关联的信息的方法，所述方法包括：
用信号发送指示包括在紧急警报消息中的紧急事件描述符的数量的第一语法元素；以及
针对所述数量的紧急事件描述符中的每一个，用信号发送指示紧急事件描述符的长度的第二语法元素，其中，所述第二语法元素包括6比特整型值，所述6比特整型值加1指示所述紧急事件描述符的长度。
2.根据权利要求1所述的方法，进一步包括：针对所述数量的紧急事件描述符中的每一个，用信号发送具有下述值的第三语法元素：所述值加1指示紧急事件描述符的语言属性的长度。
3.根据权利要求1所述的方法，进一步包括：用信号发送指示唤醒属性的值的第四语法元素。
4.根据权利要求1所述的方法，其中，所述紧急警报消息包括在水印有效载荷中。
5.一种用于在水印有效载荷中用信号发送与紧急警报消息相关联的信息的设备，所述设备包括一个或多个处理器，所述一个或多个处理器被配置为：
用信号发送指示包括在紧急警报消息中的紧急事件描述符的数量的第一语法元素；以及
针对所述数量的紧急事件描述符中的每一个，用信号发送指示紧急事件描述符的长度的第二语法元素，其中，所述第二语法元素包括6比特整型值，所述6比特整型值加1指示所述紧急事件描述符的长度。
6.根据权利要求5所述的设备，其中，所述一个或多个处理器被进一步配置为：针对所述数量的紧急事件描述符中的每一个，用信号发送指示紧急事件描述符的语言属性的长度的第三语法元素，其中指示语言属性的长度的第三语法元素指示下述值：所述值加1指示语言属性的长度。
7.根据权利要求5所述的设备，其中，所述一个或多个处理器被进一步配置为：用信号发送指示唤醒属性的值的第四语法元素。
8.根据权利要求5所述的设备，其中所述设备包括服务分发引擎。
9.一种用于生成用于紧急警报消息的描述符的方法，所述方法包括：
接收紧急警报信息；
对指示包括在所述紧急警报消息中的紧急事件描述符的字节数的第一语法元素进行解析，其中所述第一语法元素包括6比特整型值，所述6比特整型值加1指示所述字节的长度；
对于所述字节数，对具有指示字符的值的字节进行解析；并且
使用所述字符生成所述紧急事件描述符。
10.根据权利要求9所述的方法，进一步包括：对具有下述值的第二语法元素进行解析：所述值加1指示所述紧急事件描述符的语言属性的长度。
11.根据权利要求9所述的方法，进一步包括：对指示唤醒属性的值的第三语法元素进行解析。
12.根据权利要求9所述的方法，其中，所述紧急警报消息包括在水印有效载荷中。
13.根据权利要求11所述的方法，进一步包括：至少部分地基于所述第三语法元素来采取动作。
14.一种用于生成用于紧急警报消息的描述符的设备，所述设备包括一个或多个处理器，所述一个或多个处理器被配置为：
接收紧急警报信息；
对指示包括在所述紧急警报消息中的紧急事件描述符的字节数的第一语法元素进行解析，其中所述第一语法元素包括6比特整型值，所述6比特整型值加1指示所述字节的长度；
对所述字节数的字节进行解析，每个字节具有指示字符的值；并且
使用所述字符生成所述紧急事件描述符。
15.根据权利要求14所述的设备，其中，所述一个或多个处理器被进一步配置为：对具有下述值的第二语法元素进行解析：所述值加1指示所述紧急事件描述符的语言属性的长度。
16.根据权利要求14所述的设备，其中，所述一个或多个处理器被进一步配置为：对指示唤醒属性的值的第三语法元素进行解析。
17.根据权利要求16所述的设备，其中，所述一个或多个处理器被进一步配置为：至少部分地基于指示唤醒属性的值的所述第三语法元素来采取动作。
18.根据权利要求14所述的设备，其中，所述紧急警报消息包括在水印有效载荷中。
19.根据权利要求14所述的设备，其中，所述设备是从由下述所组成的组中选择出来的：台式机或膝上型计算机、移动设备、智能手机、蜂窝电话、个人数字助理(PDA)、电视、平板设备、或者个人游戏设备。
CN201780054631.3A 2016-09-09 2017-09-04 用于用信号发送紧急警报消息的系统和方法 Active CN109661821B (zh)

Applications Claiming Priority (11)

Application Number Priority Date Filing Date Title
US201662385738P 2016-09-09 2016-09-09
US62/385,738 2016-09-09
US201662405201P 2016-10-06 2016-10-06
US62/405,201 2016-10-06
US201662420468P 2016-11-10 2016-11-10
US62/420,468 2016-11-10
US201662427134P 2016-11-28 2016-11-28
US62/427,134 2016-11-28
US201762461156P 2017-02-20 2017-02-20
US62/461,156 2017-02-20
PCT/JP2017/031835 WO2018047779A1 (en) 2016-09-09 2017-09-04 Systems and methods for signaling of emergency alert messages

Publications (2)

Publication Number Publication Date
CN109661821A CN109661821A (zh) 2019-04-19
CN109661821B true CN109661821B (zh) 2021-05-18

Family

ID=61562881

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201780054631.3A Active CN109661821B (zh) 2016-09-09 2017-09-04 用于用信号发送紧急警报消息的系统和方法

Country Status (7)

Country Link
US (1) US20210289268A1 (zh)
KR (1) KR102151595B1 (zh)
CN (1) CN109661821B (zh)
CA (1) CA3035658C (zh)
MX (1) MX2019002512A (zh)
TW (1) TWI640962B (zh)
WO (1) WO2018047779A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021112037A1 (en) * 2019-12-06 2021-06-10 Sharp Kabushiki Kaisha Systems and methods for signaling temporal sublayer information in video coding
US11576126B2 (en) * 2020-03-24 2023-02-07 Qualcomm Incorporated Wakeup signaling identification
TWI799821B (zh) * 2021-03-30 2023-04-21 許維綸 危險預測預防系統

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104041031A (zh) * 2011-12-29 2014-09-10 Lg电子株式会社 视频编码和解码方法和使用该方法的装置
CN105519124A (zh) * 2013-09-18 2016-04-20 索尼公司 发送装置、发送方法、接收装置、接收方法与计算机程序

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2298302B (en) * 1995-02-25 1998-04-01 Accupage Ltd Security device
US7590589B2 (en) * 2004-09-10 2009-09-15 Hoffberg Steven M Game theoretic prioritization scheme for mobile ad hoc networks permitting hierarchal deference
US8924269B2 (en) * 2006-05-13 2014-12-30 Sap Ag Consistent set of interfaces derived from a business object model
US8483282B2 (en) * 2007-10-12 2013-07-09 Qualcomm, Incorporated Entropy coding of interleaved sub-blocks of a video block
GB2474035A (en) * 2009-10-01 2011-04-06 Sean Edward James Mccarroll Restricting use of an electrical device
US9288554B2 (en) * 2011-09-23 2016-03-15 Lg Electronics Inc. Method for receiving broadcast service and reception device thereof
US9219556B2 (en) * 2012-03-02 2015-12-22 Lg Electronics Inc. Method of providing an emergency alert service via a mobile broadcasting and apparatus therefor
EP2993898A4 (en) * 2013-05-01 2016-11-09 Lg Electronics Inc APPARATUS AND METHOD FOR TRANSMITTING AND RECEIVING A SIGNAL

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104041031A (zh) * 2011-12-29 2014-09-10 Lg电子株式会社 视频编码和解码方法和使用该方法的装置
CN105519124A (zh) * 2013-09-18 2016-04-20 索尼公司 发送装置、发送方法、接收装置、接收方法与计算机程序

Also Published As

Publication number Publication date
CA3035658A1 (en) 2018-03-15
MX2019002512A (es) 2019-06-20
KR102151595B1 (ko) 2020-09-03
KR20190031578A (ko) 2019-03-26
CN109661821A (zh) 2019-04-19
CA3035658C (en) 2023-01-24
TWI640962B (zh) 2018-11-11
US20210289268A1 (en) 2021-09-16
TW201812714A (zh) 2018-04-01
WO2018047779A1 (en) 2018-03-15

Similar Documents

Publication Publication Date Title
US11006189B2 (en) Primary device, companion device and method
TWI787218B (zh) 用於以信號發送與一緊急警報訊息相關聯之資訊之方法、裝置、設備、記錄媒體、剖析與一緊急警報訊息相關聯之資訊之裝置、用於以信號發送及剖析與一緊急警報訊息相關聯之資訊之系統、用於擷取與一緊急警報訊息相關聯之一媒體資源之方法及用於基於一緊急警報訊息而執行一動作之方法
US11336932B2 (en) Broadcast signal transmission/reception device and method
US11615778B2 (en) Method for receiving emergency information, method for signaling emergency information, and receiver for receiving emergency information
KR102134597B1 (ko) 불투명 사용자 데이터를 시그널링하기 위한 방법
KR102080726B1 (ko) 비상 경보의 시그널링을 위한 시스템 및 방법
CN109661821B (zh) 用于用信号发送紧急警报消息的系统和方法
US20190141361A1 (en) Systems and methods for signaling of an identifier of a data channel

Legal Events

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