KR20190031578A

KR20190031578A - 긴급 경보 메시지들의 시그널링을 위한 시스템들 및 방법들

Info

Publication number: KR20190031578A
Application number: KR1020197006624A
Authority: KR
Inventors: 셰우 엔쥐; 사친 쥐. 데쉬판데; 크리스토퍼 앤드류 세갈
Original assignee: 샤프 가부시키가이샤
Priority date: 2016-09-09
Filing date: 2017-09-04
Publication date: 2019-03-26
Also published as: US20210289268A1; CN109661821A; KR102151595B1; CA3035658A1; CN109661821B; TWI640962B; MX2019002512A; WO2018047779A1; CA3035658C; TW201812714A

Abstract

디바이스는 방송 스트림으로부터 저레벨 시그널링 긴급 경보 메시지 프래그먼트를 수신하도록 구성될 수 있다. 디바이스는 긴급 경보 메시지 프래그먼트에 포함된 신택스 엘리먼트들을 파싱할 수 있다. 디바이스는 파싱된 신택스 엘리먼트들에 기초하여 긴급 경보 메시지와 연관된 미디어 리소스를 검색할지를 결정할 수 있다.

Description

긴급 경보 메시지들의 시그널링을 위한 시스템들 및 방법들

본 개시내용은 대화형 텔레비전의 분야에 관한 것이다.

디지털 미디어 재생 능력은 소위 "스마트" 텔레비전들을 포함한, 디지털 텔레비전들, 셋톱 박스들, 랩톱 또는 데스크톱 컴퓨터들, 태블릿 컴퓨터들, 디지털 레코딩 디바이스들, 디지털 미디어 플레이어들, 비디오 게이밍 디바이스들, 소위 "스마트" 폰들을 포함한, 셀룰러 전화들, 전용 비디오 스트리밍 디바이스들, 및 이와 유사한 것을 포함하는, 광범위한 디바이스들에 통합될(incorporated) 수 있다. 디지털 미디어 콘텐츠(예컨대, 비디오 및 오디오 프로그래밍)는, 예를 들어, 오버-디-에어(over-the-air) 텔레비전 제공자들, 위성 텔레비전 제공자들, 케이블 텔레비전 제공자들, 소위 스트리밍 서비스 제공자들을 포함한, 온라인 미디어 서비스 제공자들, 및 이와 유사한 것을 포함한, 복수의 소스들로부터 유래할 수 있다. 디지털 미디어 콘텐츠는 인터넷 프로토콜(IP) 네트워크들과 같은 양방향 네트워크들 및 디지털 방송 네트워크들과 같은 단방향 네트워크들을 포함한, 패킷 교환 네트워크들을 통해 전달될 수 있다.

디지털 미디어 콘텐츠는 전송 표준에 따라 소스로부터 수신자 디바이스(예컨대, 디지털 텔레비전 또는 스마트 폰)로 전송될 수 있다. 전송 표준들의 예들은 DVB(Digital Video Broadcasting) 표준들, ISDB(Integrated Services Digital Broadcasting Standards) 표준들, 및, 예를 들어, ATSC 2.0 표준을 포함한, ATSC(Advanced Television Systems Committee)에 의해 개발된 표준들을 포함한다. ATSC는 소위 ATSC 3.0 표준 스위트(suite of standards)를 현재 개발 중이다. ATSC 3.0 표준 스위트는 다양한 전달 메커니즘들을 통해 광범위한 다양한 서비스들을 지원하려고 모색한다. 예를 들어, ATSC 3.0 표준 스위트는 방송 멀티미디어 전달, 소위 방송 스트리밍 및/또는 파일 다운로드 멀티미디어 전달, 소위 광대역 스트리밍 및/또는 파일 다운로드 멀티미디어 전달, 및 이들의 조합(즉, "하이브리드 서비스들")을 지원하려고 모색한다. ATSC 3.0 표준 스위트에 대해 고려된 하이브리드 서비스의 일 예는 (예컨대, 단방향 전송을 통해) 오버-디-에어 비디오 방송을 수신하고 패킷 교환 네트워크를 통해(즉, 양방향 전송을 통해) 온라인 미디어 서비스 제공자로부터 동기화된 세컨더리 오디오 프레젠테이션(synchronized secondary audio presentation)(예컨대, 세컨더리 언어(secondary language))을 수신하는 수신자 디바이스를 포함한다. 디지털 미디어 콘텐츠가 소스로부터 수신자 디바이스로 어떻게 전송될 수 있는지를 정의하는 것에 부가하여, 전송 표준들은 긴급 경보 메시지들이 소스로부터 수신자 디바이스로 어떻게 통신될 수 있는지를 명시할 수 있다. 긴급 경보 메시지들을 통신하기 위한 현재의 기법들은 이상적이지 않을 수 있다.

본 발명의 일 양태는 긴급 경보 메시지와 연관된 정보를 시그널링하기 위한 방법이며, 이 방법은:

긴급 경보 메시지에 포함된 긴급 이벤트 디스크립터들(emergency event descriptors)의 수를 표시하는 신택스 엘리먼트(syntax element)를 시그널링하는 단계; 및

표시된 수의 긴급 경보 디스크립터들 각각에 대한 긴급 이벤트 디스크립터의 길이를 표시하는 신택스 엘리먼트를 시그널링하는 단계를 포함한다.

본 발명의 일 양태는 워터마크 페이로드(watermark payload)에서 긴급 경보 메시지와 연관된 정보를 시그널링하기 위한 디바이스이며, 이 디바이스는 하나 이상의 프로세서를 포함하며, 하나 이상의 프로세서는:

긴급 경보 메시지에 포함된 긴급 이벤트 디스크립터들의 수를 표시하는 신택스 엘리먼트를 시그널링하고;

표시된 수의 긴급 이벤트 디스크립터들 각각에 대한 긴급 이벤트 디스크립터의 길이를 표시하는 신택스 엘리먼트를 시그널링하도록 구성되고, 여기서 긴급 이벤트 디스크립터의 길이를 표시하는 신택스 엘리먼트는 6-비트 정수 값 - 이 6-비트 정수 값에 1을 더한 것이 긴급 이벤트 디스크립터의 길이를 표시함 - 을 포함한다.

본 발명의 일 양태는 긴급 경보 메시지에 대한 디스크립터를 생성하기 위한 방법이며, 이 방법은:

긴급 경보 메시지를 수신하는 단계;

긴급 경보 메시지에 포함된 긴급 이벤트 디스크립터의 바이트 수를 표시하는 신택스 엘리먼트를 파싱하는 단계 - 긴급 이벤트 디스크립터의 바이트 수를 표시하는 신택스 엘리먼트는 6-비트 정수 값 - 이 6-비트 정수 값에 1을 더한 것이 바이트 수를 표시함 - 을 포함함 -;

표시된 바이트 수에 대해, 문자를 표시하는 값을 갖는 바이트를 파싱하는 단계; 및

표시된 문자들을 사용하여 긴급 이벤트 디스크립터를 생성하는 단계를 포함한다.

본 발명의 일 양태는 긴급 경보 메시지에 대한 디스크립터를 생성하기 위한 디바이스이고, 이 디바이스는 하나 이상의 프로세서를 포함하며, 하나 이상의 프로세서는:

긴급 경보 메시지를 수신하고;

긴급 경보 메시지에 포함된 긴급 이벤트 디스크립터의 바이트 수를 표시하는 신택스 엘리먼트를 파싱하며 - 긴급 이벤트 디스크립터의 바이트 수를 표시하는 신택스 엘리먼트는 6-비트 정수 값 - 이 6-비트 정수 값에 1을 더한 것이 바이트 수를 표시함 - 을 포함함 -;

표시된 바이트 수에 대해 바이트를 파싱하고 - 각각의 바이트는 문자를 표시하는 값을 가짐 -;

표시된 문자들을 사용하여 긴급 이벤트 디스크립터를 생성하도록 구성된다.

도 1은 본 개시내용의 하나 이상의 기법에 따른 콘텐츠 전달 프로토콜 모델의 일 예를 예시하는 개념 다이어그램이다.
도 2는 본 개시내용의 하나 이상의 기법을 구현할 수 있는 시스템의 일 예를 예시하는 블록 다이어그램이다.
도 3은 본 개시내용의 하나 이상의 기법을 구현할 수 있는 서비스 배포 엔진(service distribution engine)의 일 예를 예시하는 블록 다이어그램이다.
도 4는 본 개시내용의 하나 이상의 기법을 구현할 수 있는 수신자 디바이스의 일 예를 예시하는 블록 다이어그램이다.
도 5는 본 개시내용의 하나 이상의 기법을 구현할 수 있는 디바이스의 일 예를 예시하는 블록 다이어그램이다.
도 6a는 예시적인 긴급 경보 메시지의 예시적인 스키마(schema)를 예시하는 컴퓨터 프로그램 리스팅이다.
도 6b는 도 6a의 다음 부분이다.
도 7a는 예시적인 긴급 경보 메시지의 예시적인 스키마를 예시하는 컴퓨터 프로그램 리스팅이다.
도 7b는 도 7a의 다음 부분이다.

일반적으로, 본 개시내용은 긴급 경보 메시지들을 시그널링(signaling)(또는 시그널링(signalling))하기 위한 기법들을 설명한다. 상세하게는, 본 명세서에 설명된 기법들은 긴급 경보 메시지에 포함된 콘텐츠와 연관된 정보, 및/또는 긴급 경보 메시지와 연관된 다른 정보를 시그널링하는 데 사용될 수 있다. 일부 경우들에서, 수신자 디바이스는 긴급 경보 메시지들과 연관된 정보를 파싱하고, 대응하는 긴급 메시지 경보가 사용자에게 보다 명백하도록, 디지털 미디어 콘텐츠의 제시 및/또는 렌더링이 수정되게 할 수 있다. 예를 들어, 시그널링 정보가 긴급 경보 메시지 내의 특정 타입의 콘텐츠의 존재를 표시하는 경우, 수신자 디바이스는 애플리케이션을 닫거나 일시적으로 중지(suspend)시키도록 구성될 수 있다. 비록 본 명세서에 설명된 기법들이, 일부 예들에서, 긴급 경보 메시지들과 관련하여 설명되었지만, 본 명세서에 설명된 기법들은 다른 타입의 경보들 및 메시지들에 일반적으로 적용가능할 수 있다는 점에 유의해야 한다. 비록 일부 예들에서, 본 개시내용의 기법들이 ATSC 표준들과 관련하여 설명되었지만, 본 명세서에 설명된 기법들이 임의의 전송 표준에 일반적으로 적용가능하다는 점에 유의해야 한다. 예를 들어, 본 명세서에 설명된 기법들은 DVB 표준들, ISDB 표준들, ATSC 표준들, DTMB(Digital Terrestrial Multimedia Broadcast) 표준들, DMB(Digital Multimedia Broadcast) 표준들, HbbTV(Hybrid Broadcast and Broadband Television) 표준들, W3C(World Wide Web Consortium) 표준들, UPnP(Universal Plug and Play) 표준들, 및 다른 비디오 인코딩 표준들 중 임의의 것에 일반적으로 적용가능하다. 게다가, 본 명세서에서의 문서들의 참조에 의한 포함이 설명 목적들을 위한 것이며 본 명세서에서 사용된 용어들과 관련하여 모호성을 제한하고 그리고/또는 야기하도록 구성되어서는 안된다는 점에 유의해야 한다. 예를 들어, 하나의 포함된 참조가 다른 포함된 참조와 상이한 용어의 정의를 제공하는 경우에 그리고/또는 이 용어가 본 명세서에서 사용될 때, 이 용어는 각자의 정의 각각을 광의적으로(broadly) 포함하는 방식으로 그리고/또는 대안에서 특정 정의들 각각을 포함하는 방식으로 해석되어야 한다.

전송 표준들은 긴급 경보들이 서비스 제공자로부터 수신자 디바이스들로 어떻게 통신될 수 있는지를 정의할 수 있다. 긴급 경보들은 전형적으로 긴급 기관(emergency authority)에 의해 생성되어 서비스 제공자에게 전송된다. 긴급 기관은 정부 기관(government agency)의 일원으로서 포함될 수 있다. 예를 들어, 긴급 기관들은 미국 국립 기상청(United States National Weather Service), 미국 국토 안보부(United States Department of Homeland Security), 지역 및 지방 기관들(예컨대, 경찰 및 소방서) 및 이와 유사한 것을 포함할 수 있다. 긴급 경보들은 현재의 또는 예기된 긴급에 관한 정보를 포함할 수 있다. 정보는 생명, 건강, 안전, 및 재산의 보호를 추진하도록 의도된 정보를 포함할 수 있고, 긴급에 관한 중요한 상세들 및 긴급에 어떻게 대처할지를 포함할 수 있다. 긴급 경보와 연관될 수 있는 긴급들의 타입들의 예들은 토네이도, 허리케인, 홍수, 해일, 지진, 착빙 조건(icing conditions), 폭설, 광범위한 화재, 유독 가스 방출, 광범위한 정전, 산업 폭발(industrial explosions), 시민 소요, 임박한 날씨 변화에 대한 경계경보 및 주의보(warnings and watches), 및 이와 유사한 것을 포함한다.

예를 들어, 텔레비전 방송국(예컨대, 지역 네트워크 계열사), MVPD(multi-channel video program distributor)(예컨대, 케이블 텔레비전 서비스 운영자, 위성 텔레비전 서비스 운영자, IPTV(Internet Protocol Television) 서비스 운영자), 및 이와 유사한 것과 같은 서비스 제공자는 수신자 디바이스들에 배포하기 위한 하나 이상의 긴급 경보 메시지를 생성할 수 있다. 긴급 경보들 및/또는 긴급 경보 메시지들은 텍스트(예컨대 "기상 특보(Severe Weather Alert)"), 이미지들(예컨대, 기상도(weather map)), 오디오 콘텐츠(예컨대, 경고 톤들(warning tones), 오디오 메시지들 등), 비디오 콘텐츠, 및/또는 전자 문서들 중 하나 이상을 포함할 수 있다. 긴급 경보 메시지들은 다양한 기법들을 사용하여 멀티미디어 콘텐츠의 프레젠테이션에 통합될 수 있다. 예를 들어, 긴급 경보 메시지는 스크롤링 배너(scrolling banner)로서 비디오에 "번인"되거나(burned-in) 오디오 트랙과 믹싱되거나, 또는 긴급 경보 메시지가 오버레이된 사용자 제어가능 윈도(예컨대, 팝업 윈도)에 제시될 수 있다. 게다가, 일부 예들에서, 긴급 경보들 및/또는 긴급 경보 메시지들은 URI들(Uniform Resource Identifiers)을 포함할 수 있다. 예를 들어, 긴급 경보 메시지는 긴급에 관련된 부가 정보(예컨대, 비디오, 오디오, 텍스트, 이미지들 등)가 어디에서 획득될 수 있는지를 식별해주는 URL들(Universal Resource Locators)(예컨대, 긴급을 설명하는 문서를 포함하는 서버의 IP 어드레스)을 포함할 수 있다. (단방향 브로드캐스트를 통해 또는 양방향 광대역 접속을 통해) URL을 포함하는 긴급 경보 메시지를 수신하는 수신자 디바이스는 긴급 경보를 설명하는 문서를 획득하고, 문서를 파싱하며, 문서에 포함된 정보를 디스플레이 상에 디스플레이할(예컨대, 스크롤링 배너를 생성하여 비디오 프레젠테이션 상에 오버레이하고, 이미지들을 렌더링하며, 오디오 메시지들을 플레이할) 수 있다. 프로토콜들은, 예를 들어, HTML(Hypertext Markup Language), 동적 HTML, XML(Extensible Markup Language), JSON(JavaScript Object Notation), 및 CSS(Cascading Style Sheets)에 기초한 스키마들과 같은, 긴급 경보 메시지를 포맷팅하기 위한 하나 이상의 스키마를 명시할 수 있다. 문헌 [OASIS: "Common Alerting Protocol" Version 1.2, 1 July 2010, (이하, "CAP Version 1.2")]에 설명되어 있는 공통 경보 프로토콜(Common Alerting Protocol), 버전 1.2는 긴급 경보 메시지가 XML 스키마에 따라 어떻게 포맷팅될 수 있는지의 일 예를 제공한다. 게다가, 문헌 [ANSI: "Emergency Alert Messaging for Cable," J-STD-42-B, American National Standards Association, October 2013]은 긴급 경보 메시지가 스키마에 따라 어떻게 포맷팅될 수 있는지의 일 예를 제공한다.

컴퓨팅 디바이스들 및/또는 전송 시스템들은 하나 이상의 추상화 계층을 포함하는 모델들에 기초할 수 있으며, 여기서 각각의 추상화 계층에서의 데이터는 특정 구조들, 예컨대, 패킷 구조들, 변조 스킴들 등에 따라 표현된다. 정의된 추상화 계층들을 포함하는 모델의 일 예는 도 1에 예시된 소위 OSI(Open Systems Interconnection) 모델이다. OSI 모델은 애플리케이션 계층, 프레젠테이션 계층, 세션 계층, 전송 계층, 네트워크 계층, 데이터 링크 계층 및 물리 계층을 포함한, 7-계층 스택 모델을 정의한다. 스택 모델에서의 계층들을 설명하는 것과 관련하여 용어들 상위(upper) 및 하위(lower)의 사용은 애플리케이션 계층이 최상위 계층이고 물리 계층이 최하위 계층인 것에 기초할 수 있다는 점에 유의해야 한다. 게다가, 일부 경우들에서, 용어 "계층 1" 또는 "L1"은 물리 계층을 지칭하는 데 사용되고, 용어 "계층 2" 또는 "L2"는 링크 계층을 지칭하는 데 사용될 수 있으며, 용어 "계층 3" 또는 "L3" 또는 "IP 계층"은 네트워크 계층을 지칭하는 데 사용될 수 있다.

물리 계층은 일반적으로 전기 신호들이 디지털 데이터를 형성하는 계층을 지칭할 수 있다. 예를 들어, 물리 계층은 변조된 라디오 주파수(RF) 심벌들이 어떻게 디지털 데이터의 프레임을 형성하는지를 정의하는 계층을 지칭할 수 있다. 링크 계층이라고도 지칭될 수 있는, 데이터 링크 계층은 송신 측에서의 물리 계층 프로세싱 이전에 그리고 수신 측에서의 물리 계층 수신 이후에 사용되는 추상화를 지칭할 수 있다. 본 명세서에서 사용되는 바와 같이, 링크 계층은 송신 측에서 데이터를 네트워크 계층으로부터 물리 계층으로 전송하는 데 사용되고 수신 측에서 데이터를 물리 계층으로부터 네트워크 계층으로 전송하는 데 사용되는 추상화를 지칭할 수 있다. 송신 측 및 수신 측이 논리적 역할들이고 단일 디바이스가 한 경우에서는 송신 측으로서 동작하기도 하고 다른 경우에서는 수신 측으로서 동작하기도 할 수 있다는 점에 유의해야 한다. 링크 계층은 특정 패킷 타입들(예컨대, MPEG-TS(Motion Picture Expert Group - Transport Stream) 패킷들, IPv4(Internet Protocol Version 4) 패킷들 등)로 캡슐화된 다양한 타입의 데이터(예컨대, 비디오, 오디오, 또는 애플리케이션 파일들)을 물리 계층에 의한 프로세싱을 위한 단일 일반 포맷(generic format)으로 추상화할 수 있다. 네트워크 계층은 일반적으로 논리적 어드레싱(logical addressing)이 일어나는 계층을 지칭할 수 있다. 즉, 네트워크 계층은 데이터 패킷들이 네트워크 내의 특정 노드(예컨대, 컴퓨팅 디바이스)에 전달될 수 있도록 일반적으로 어드레싱 정보(예컨대, 인터넷 프로토콜(IP) 어드레스들, URL들, URI들 등)를 제공할 수 있다. 본 명세서에서 사용되는 바와 같이, 용어 네트워크 계층은 링크 계층 위의 계층 및/또는 데이터가 링크 계층 프로세싱을 위해 수신될 수 있도록 하는 구조로 된 데이터를 갖는 계층을 지칭할 수 있다. 전송 계층, 세션 계층, 프레젠테이션 계층, 및 애플리케이션 계층 각각은 데이터가 사용자 애플리케이션에 의한 사용을 위해 어떻게 전달되는지를 정의할 수 있다.

현재 개발 중인 전송 표준들을 포함한, 전송 표준들은 각각의 계층에 대해 지원되는 프로토콜들을 명시하는 콘텐츠 전달 프로토콜 모델을 포함할 수 있으며, 하나 이상의 특정 계층 구현을 추가로 정의할 수 있다. 도 1을 또다시 참조하면, 예시적인 콘텐츠 전달 프로토콜 모델이 예시되어 있다. 도 1에 예시된 예에서, 콘텐츠 전달 프로토콜 모델(100)은 예시 목적들을 위해 7-계층 OSI 모델과 일반적으로 정렬된다. 그러한 예시가 콘텐츠 전달 프로토콜 모델(100) 및/또는 본 명세서에 설명된 기법들의 구현들을 제한하는 것으로 해석되어서는 안된다는 점에 유의해야 한다. 콘텐츠 전달 프로토콜 모델(100)은 ATSC 3.0 표준 스위트에 대한 현재 제안된 콘텐츠 전달 프로토콜 모델에 일반적으로 대응할 수 있다. 게다가, 본 명세서에 설명된 기법들은 콘텐츠 전달 프로토콜 모델(100)에 기초하여 동작하도록 구성된 시스템에서 구현될 수 있다.

ATSC 3.0 표준 스위트는, 그 전체가 참고로 본 명세서에 포함되는, [ATSC Standard A/321, System Discovery and Signaling Doc. A/321:2016, 23 March 2016 (이하, "A/321")]을 포함한다. A/321은 ATSC 3.0 단방향 물리 계층 구현의 물리 계층 파형의 초기 엔트리 포인트(initial entry point)를 설명한다. 게다가, 현재 개발 중인 ATSC 3.0 표준 스위트의 양태들은 [Candidate Standards, revisions thereto, and Working Drafts (WD)]에 설명되어 있으며, 이들 각각은 ATSC 3.0 표준의 발표된(즉 "최종" 또는 "채택된") 버전에 포함시키기 위한 제안된 양태들을 포함할 수 있다. 예를 들어, 그 전체가 참고로 본 명세서에 포함되는, [ATSC Standard: Physical Layer Protocol, Doc. S32-230r56, 29 June 2016]은 ATSC 3.0에 대한 제안된 단방향 물리 계층을 설명한다. 제안된 ATSC 3.0 단방향 물리 계층은 정의된 부트스트랩, 프리앰블, 및 하나 이상의 물리 계층 파이프(PLP)를 포함하는 데이터 페이로드 구조를 포함하는 물리 계층 프레임 구조를 포함한다. PLP는 RF 채널 또는 RF 채널의 일 부분 내의 논리적 구조를 일반적으로 지칭할 수 있다. 제안된 ATSC 3.0 표준 스위트는 RF 채널에 대한 추상화를 방송 스트림이라고 지칭한다. 제안된 ATSC 3.0 표준 스위트는 PLP가, 자신이 속한 방송 스트림 내에서 고유한, PLP 식별자(PLPID)에 의해 식별된다는 것을 추가로 규정한다. 즉, PLP는 특정 변조 및 코딩 파라미터들을 갖는 RF 채널(예컨대, 지리적 지역 및 주파수에 의해 식별되는 RF 채널)의 일 부분을 포함할 수 있다.

제안된 ATSC 3.0 단방향 물리 계층은 단일 RF 채널이 하나 이상의 PLP를 포함할 수 있고 각각의 PLP가 하나 이상의 서비스를 운반할 수 있다는 것을 규정한다. 일 예에서, 다수의 PLP들이 단일 서비스를 운반할 수 있다. 제안된 ATSC 3.0 표준 스위트에서, 용어 서비스는 사용자에게 일괄하여(in aggregate) 제공되는 미디어 컴포넌트들의 집합체(예컨대, 비디오 컴포넌트, 오디오 컴포넌트, 및 자막(sub-title) 컴포넌트)을 지칭하는 데 사용될 수 있으며, 여기서 컴포넌트들은 다수의 미디어 타입들을 가질 수 있으며, 여기서 서비스는 연속적(continuous)이거나 단속적(intermittent)일 수 있고, 여기서 서비스는 실시간 서비스(예컨대, 라이브 이벤트에 대응하는 멀티미디어 프레젠테이션) 또는 비-실시간 서비스(예컨대, 비디오 온 디맨드(video on demand) 서비스, 전자 서비스 가이드(electronic service guide) 서비스)일 수 있으며, 여기서 실시간 서비스는 텔레비전 프로그램들의 시퀀스를 포함할 수 있다. 서비스들은 애플리케이션 기반 특징들(application based features)을 포함할 수 있다. 애플리케이션 기반 특징들은 애플리케이션, 애플리케이션에 의해 사용될 임의적 파일들, 및 특정 시간들에서 특정 액션들을 취하도록 애플리케이션에 지시하는 임의적 통지들을 포함한 서비스 컴포넌트들을 포함할 수 있다. 일 예에서, 애플리케이션은 향상된 또는 대화형 서비스를 구성하는 문서들의 집합체일 수 있다. 애플리케이션의 문서들은 HTML, JavaScript, CSS, XML, 및/또는 멀티미디어 파일들을 포함할 수 있다. 제안된 ATSC 3.0 표준 스위트가 새로운 타입의 서비스들이 장래의 버전들에서 정의될 수 있음을 명시한다는 점에 유의해야 한다. 따라서, 본 명세서에서 사용되는 바와 같이, 용어 서비스는 제안된 ATSC 3.0 표준 스위트 및/또는 다른 타입의 디지털 미디어 서비스들과 관련하여 설명된 서비스를 지칭할 수 있다. 앞서 기술된 바와 같이, 서비스 제공자는 긴급 기관으로부터 긴급 경보를 수신하고 서비스와 관련하여 수신자 디바이스에 배포될 수 있는 긴급 경보 메시지들을 생성할 수 있다. 서비스 제공자는 멀티미디어 프레젠테이션에 통합되는 긴급 경보 메시지를 생성할 수 있고 그리고/또는 애플리케이션 기반 향상의 일부로서 긴급 경보 메시지를 생성할 수 있다. 예를 들어, 긴급 정보는 비디오에 (긴급 온-스크린 텍스트 정보(emergency on-screen text information)라고 지칭될 수 있는) 텍스트로서 디스플레이될 수 있으며, 예를 들어, (크롤(crawl)이라고 지칭될 수 있는) 스크롤링 배너를 포함할 수 있다. 스크롤링 배너는 비디오 프레젠테이션에 번인된 텍스트 메시지로서(예컨대, 온스크린 긴급 경보 메시지로서) 그리고/또는 문서에 포함된 텍스트(예컨대, XML 프래그먼트(XML fragment))로서 수신자 디바이스에 의해 수신될 수 있다.

도 1을 참조하면, 콘텐츠 전달 프로토콜 모델(100)은 UDP(User Datagram Protocol) 및 IP(Internet Protocol)을 통한 MMTP(MPEG Media Transport Protocol) 그리고 UDP 및 IP를 통한 ROUTE(Real-time Object delivery over Unidirectional Transport)를 사용하여 ATSC 방송 물리 계층을 통해 스트리밍 및/또는 파일 다운로드를 지원한다. MMTP는 [ISO/IEC: ISO/IEC 23008-1, "Information technology-High efficiency coding and media delivery in heterogeneous environments-Part 1: MPEG media transport (MMT)"]에 설명되어 있다. ROUTE의 개요는, 그 전체가 참고로 포함되는, [ATSC Candidate Standard: Signaling, Delivery, Synchronization, and Error Protection (A/331) Doc. S33-601r4, 21 June 2016, Rev. 3 20 July 2016 (이하, "A/331")]에서 제공된다.

비록 ATSC 3.0이 단방향 오버-디-에어 전송 물리 계층을 지칭하기 위해 일부 맥락들에서 용어 방송을 사용하지만, 소위 ATSC 3.0 방송 물리 계층이 스트리밍 또는 파일 다운로드를 통해 비디오 전달을 지원한다는 점에 유의해야 한다. 그와 같이, 본 명세서에서 사용되는 바와 같은 용어 방송은 비디오 및 관련 데이터가 본 개시내용의 하나 이상의 기법에 따라 전송될 수 있는 방식을 제한하는 데 사용되어서는 안된다. 게다가, 콘텐츠 전달 프로토콜 모델(100)은 ATSC 방송 물리 계층에서의 시그널링(예컨대, 물리 프레임 프리앰블을 사용하는 시그널링), ATSC 링크 계층에서의 시그널링(LMT(Link Mapping Table)를 사용하는 시그널링), IP 계층에서의 시그널링(예컨대, 소위 LLS(Low Level Signaling)), 서비스 계층 시그널링(SLS)(예컨대, MMTP 또는 ROUTE에서의 메시지들을 사용하는 시그널링), 및 애플리케이션 또는 프레젠테이션 계층 시그널링(예컨대, 비디오 또는 오디오 워터마크를 사용하는 시그널링)을 지원한다.

앞서 설명된 바와 같이, 제안된 ATSC 3.0 표준 스위트는, LLS(Low Level Signaling)라고 지칭되는, IP 계층에서의 시그널링을 지원한다. 제안된 ATSC 3.0 표준 스위트에서, LLS는 이 시그널링 기능에 전용된 어드레스 및/또는 포트를 갖는 IP 패킷들의 페이로드에서 운반되는 시그널링 정보를 포함한다. 제안된 ATSC 3.0 표준 스위트는 LLS 테이블(LLS Table): 서비스 리스트 테이블(Service List Table)(SLT), 등급 지역 테이블(Rating Region Table)(RRT), 시스템 시간 프래그먼트(System Time fragment), 진보된 긴급 경보 테이블 프래그먼트(Advanced Emergency Alerting Table fragment)(AEAT) 메시지, 및 온스크린 메시지 통지(Onscreen Message Notification)의 형태로 시그널링될 수 있는 5가지 타입의 LLS 정보를 정의한다. 장래의 버전들에서 부가의 LLS 테이블들이 시그널링될 수 있다. 표 1은 제안된 ATSC 3.0 표준 스위트에 따라 정의되고 A/331에 설명된 바와 같은, LLS 테이블에 대해 제공된 신택스를 제공한다. 표 1, 및 본 명세서에 설명된 다른 표들에서, uimsbf는 부호없는(unsigned) 정수 최상위 비트 제1 데이터 포맷(unsigned integer most significant bit first data format)을 지칭하고 var은 가변 비트 수(variable number of bits)를 지칭한다.

[표 1]

A/331은 표 1에 포함된 신택스 엘리먼트들에 대해 이하의 정의들을 제공한다:

LLS_table_id - 보디(body)에서 전달되는 테이블의 타입을 식별해주어야 하는 8-비트 부호없는 정수. 0 내지 0x7F의 범위에 있는 LLS_table_id의 값들은 ATSC에 의해 정의되거나 ATSC에 의한 장래의 사용을 위해 예약되어야 한다. 0x80 내지 0xFF의 범위에 있는 LLS_table_id의 값들은 사용자 사적 사용을 위해 이용가능해야 한다.

provider_id - LLS_table()의 이 인스턴스에서 시그널링된 서비스들과 연관된 제공자를 식별해주어야 하는 8-비트 부호없는 정수, 여기서 "provider"는 서비스들을 방송하기 위해 이 방송 스트림의 일부 또는 전부를 사용하고 있는 방송국이다. provider_id는 이 방송 스트림 내에서 고유해야 한다.

LLS_table_version - LLS_table_id와 provider_id의 조합에 의해 식별된 테이블 내의 임의의 데이터가 변할 때마다 1씩 증가되어야 하는 8-비트 부호없는 정수. 값이 0xFF에 도달할 때, 값은 증가 시에 0x00으로 래핑(wrapping)해야 한다. 방송 스트림을 공유하는 하나 초과의 제공자가 있을 때마다, 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(Advanced Emergency Alerting Message Format) 구조([A/331]의 섹션 6.5)에 부합하는 XML 포맷 진보된 긴급 경보 테이블 프래그먼트.

앞서 설명된 바와 같이, 서비스 제공자는 긴급 기관으로부터 긴급 경보를 수신하고 서비스와 함께 수신자 디바이스에 배포될 수 있는 긴급 경보 메시지들을 생성할 수 있다. 긴급 경보 메시지를 포함할 수 있는 문서의 일 예에서의 AEAT 프래그먼트. A/331에서, AEAT 프래그먼트는 하나 이상의 AEA(Advanced Emergency Alerting) 메시지로 구성될 수 있으며, 여기서 AEA 메시지는 AEA-MF(Advanced Emergency Alerting-Message Format) 구조에 따라 포맷팅된다. A/331에서, AEA-MF는 경보 발신자(alert originator)(예컨대, 긴급 기관) 또는 서비스 제공자로부터 수신자 디바이스로 포워딩될 수 있는 멀티미디어 콘텐츠에 대한 설비들(facilities)을 포함한다. 표 2는 A/331에서 제공되는 바와 같은 AEAT 엘리먼트의 구조를 설명한다. 표 2 및 본 명세서에 포함된 다른 표들에서, 데이터 타입들 string, unsignedByte, dateTime, language, 및 anyURI가 W3C(World Wide Web Consortium)에 의해 유지되는 XSD(XML Schema Definition) 권고들에서 제공된 정의들에 대응할 수 있다는 점에 유의해야 한다. 일 예에서, 이것들은 ["XML Schema Part 2: Datatypes Second Edition]에 설명된 정의들에 대응할 수 있다. 게다가, 사용(use)은 엘리먼트 또는 속성(attribute)의 카디널리티(cardinality)(즉, 엘리먼트 또는 속성의 출현 횟수)에 대응할 수 있다.

[표 2]

일 예에서, 표 2에 포함된 엘리먼트들 및 속성들은 A/331에 포함된 이하의 시맨틱스(semantics)에 기초할 수 있다:

AEAT - AEAT의 루트 엘리먼트.

AEA - 진보된 긴급 경보 메시지(Advanced Emergency Alerting Message). 이 엘리먼트는 @AEAid, @issuer, @audience, @AEAtype, @refAEAid, 및 @priority 속성들에 덧붙여 다음과 같은 자식 엘리먼트들(child-elements): Header, AEAtext, Media, 그리고 임의로 Signature를 갖는 부모 엘리먼트(parent element)이다.

AEA@AEAid - 이 엘리먼트는 스테이션(송신기)에 의해 배정된(assigned), AEA 메시지를 고유하게 식별해주는 스트링 값(string value)이어야 한다. @AEAid는 공백들(spaces), 쉼표들(commas) 또는 제한된 문자들(< 및 &)을 포함하지 않아야 한다.

AEA@issuer - 메시지를 발신하거나 포워딩하는 방송국을 식별해주어야 하는 스트링. @issuer는 호출 부호(call letters), 스테이션 식별자(ID), 그룹 이름, 또는 다른 식별 값과 같은, 영숫자 값을 포함해야 한다.

AEA@audience - 메시지의 의도된 오디언스(audience)를 식별해주어야 하는 스트링. 값은 표 3에 따라 코딩되어야 한다.

[표 3]

AEA@refAEAid - 참조된 AEA 메시지의 AEAid를 식별해주어야 하는 스트링. 이는 @AEAtype이 "update" 또는 "cancel"일 때 나타나야 한다.

AEA@AEAtype - AEA 메시지의 카테고리를 식별해주어야 하는 스트링. 값은 표 4에 따라 코딩되어야 한다. @refAEAid

[표 4]

AEA@priority - AEA 메시지는 경보의 우선순위를 표시하는 정수 값을 포함해야 한다. 값은 표 5에 따라 코딩되어야 한다.

[표 5]

Header -이 엘리먼트는 경보의 타입(EventCode), 경보가 유효한 시간(@effective), 경보가 만료하는 시간(@expires), 및 목표한 경보 지역(targeted alert area)의 위치(Location)를 포함한, 경보에 대한 관련 엔벨로프 정보(envelope information)를 포함해야 한다.

Header@effective -이 dateTime은 경보 메시지의 유효 시간을 포함해야 한다. 날짜와 시간은 XML dateTime 데이터 타입 포맷(예컨대, 2016년 6월 23일 오전 11:15 EDT에 대해 "2016-06-23T22:11:16-05:00")으로 표현되어야 한다. "Z"와 같은 알파벳 시간대 지정자들(time zone designators)이 사용되지 않아야 한다. UTC에 대한 시간대는 "-00:00"으로 표현되어야 한다.

Header@expires - 이 dateTime은 경보 메시지의 만료 시간을 포함해야 한다. 날짜와 시간은 XML dateTime 데이터 타입 포맷(예컨대, 2016년 6월 23일 오전 11:15 EDT에 대해 "2016-06-23T22:11:16-05:00")으로 표현되어야 한다. "Z"와 같은 알파벳 시간대 지정자들이 사용되지 않아야 한다. UTC에 대한 시간대는 "-00:00"으로 표현되어야 한다.

EventCode - 값 자체를 표기하는 (숫자를 표현할 수 있는) 스트링으로 포맷팅된 경보 메시지의 이벤트 타입을 식별해주어야 하는 스트링(예컨대, 미국에서, "EVI"의 값은 대피 경고를 표기하는 데 사용될 것이다). 값들은 국가마다 상이할 수 있으며, 영숫자 코드일 수 있거나, 평문(plain text)일 수 있다. AEA 메시지당 하나의 EventCode만 존재해야 한다.

EventCode@type - 이 속성은 EventCode의 도메인을 지정해야 하는 국가 지정 스트링 값(national-assigned string value)이어야 한다(예컨대, 미국에서, "SAME"은 표준 연방 통신 위원회(Federal Communications Commission)(FCC) Part 11 긴급 경보 시스템(Emergency Alert System)(EAS) 코딩을 표기한다). 두문자어들인 @type의 값들은 마침표들(periods) 없이 모두 대문자들로 표현되어야 한다.

Location - 지리적 기반 코드로 메시지 타깃(message target)을 설명해야 하는 스트링.

Location@type - 이 속성은 Location 코드의 도메인을 식별해주는 스트링이어야 한다.

@type="FIPS"인 경우, Location은 미국 연방 통신위원회(Federal Communications Commission)에 의해 긴급 경보 시스템에 대한 47 CFR(Code of Federal Regulations) 11(개정됨)에 명시된 바와 같은 FIPS(Federal Information Processing Standard) 지역 코드들(geographic codes)로서 정의되어야 한다.

@type="SGC"인 경우, Location은 2010년 5월에 업데이트된, 버전 2006인, 캐나다 통계청(Statistics Canada)에 의해 정의된 바와 같은 표준 지역 분류(Standard Geographic Classification) 코드들로서 정의되어야 한다.

@type="polygon"인 경우, Location은 닫힌, 비-자기 교차 루프(closed, non-self-intersecting loop)를 형성하는 4개 이상의 좌표 쌍의 연결 시퀀스(connected sequence)로 이루어진 지리공간 공간 지역(geospatial space area)을 정의해야 한다.

@type="circle"인 경우, Location은 좌표 쌍으로서 주어지는 중심 지점 및 그에 뒤이은 공백 문자(space character) 및 킬로미터 단위의 반경 값에 의해 표현되는 원형 지역을 정의해야 한다.

@type의 텍스트 값들은 대소문자 구분(case sensitive)이며, "polygon" 및 "circle"을 제외하고는, 모두 대문자들로 표현되어야 한다.

AEAtext - 긴급 메시지의 평문의 스트링. 각각의 AEAtext 엘리먼트는 정확히 하나의 @lang 속성을 포함해야 한다. 다수의 언어들로 된 동일한 경보의 AEAtext의 경우, 이 엘리먼트는 다수의 AEAtext 엘리먼트들의 존재를 요구해야 한다.

AEAtext@lang - 이 속성은 경보 메시지의 각자의 AEAtext 엘리먼트의 언어를 식별해주어야 한다. 이 속성은 이 ATSC 3.0 서비스의 이름에 대한 언어를 표현해야 하며, BCP 47에 정의된 바와 같은 공식적인 자연 언어 식별자들(formal natural language identifier)에 의해 표현되어야 한다 [IETF(Internet Engineering Task Force) BCP(Best Current Practice) 47. BCP가 일련의 IETF RFC들(Request for Comments)에 대한 영속적 이름 - 그의 숫자들은 그것들이 업데이트될 때 변경됨 - 이라는 점에 유의해야 한다. 언어 태그 신택스를 설명하는 최신의 RFC는, 본 명세서에 참고로 포함된, [RFC 5646, Tags for the Identification of Languages]이고, 이는 이전의 RFC 4646, RFC 3066 및 RFC 1766을 폐기시킨다]. 암시적 디폴트 값이 없어야 한다.

Media - 리소스의 언어(@lang), 디스크립션(description)(@mediaDesc) 및 위치(@url)를 포함한, 멀티미디어 리소스의 컴포넌트 부분들을 포함해야 한다. AEAtext에 관련된 보충 정보를 갖는 부가 파일; 예컨대, 이미지 또는 오디오 파일을 참조한다. AEA 메시지 블록 내에 다수의 인스턴스들이 출현할 수 있다.

Media@lang - 이 속성은, 동일한 멀티미디어의 상이한 언어 인스턴스들이 송신되고 있는 경우 수신자에게 알려주는 데 도움을 주기 위해, 각각의 미디어 리소스에 대한 각자의 언어를 식별해주어야 한다. 이 속성은 이 ATSC 3.0 서비스의 이름에 대한 언어를 표현해야 하며, BCP 47에 정의된 바와 같은 공식적인 자연 언어 식별자들에 의해 표현되어야 한다.

Media@mediaDesc - 미디어 리소스의 타입 및 콘텐츠를, 평문으로, 설명해야 하는 스트링. 디스크립션은, 비디오, 사진, PDF 등과 같은, 미디어 타입을 표시해야 한다.

Media@uri - 메시지로부터 외부 목적지로부터의 리소스를 검색하는 데 사용될 수 있는 전체 URL(full URL)을 포함해야 하는 임의적 엘리먼트. 리치 미디어 리소스(rich media resource)가 광대역을 통해 전달될 때, Media 엘리먼트의 URL은 원격 서버 상의 파일을 참조해야 한다. 리치 미디어 리소스가 브로드캐스트 ROUTE를 통해 전달될 때, 리소스에 대한 URL은 http://localhost/로 시작해야 한다. URL은 파일, 또는 파일의 Entity 헤더를 전달하는 LCT [IETF: RFC 5651, "Layered Coding Transport (LCT) Building Block," Internet Engineering Task Force, Reston, VA, October, 2009] 채널에서의 EFDT(Extended File Delivery Table) 내의 대응하는 File 엘리먼트의 Content-Location 속성과 매칭해야 한다.

Signature - 스테이션과 수신기 사이에서 디지털적으로 서명된 메시지들을 가능하게 해주어야 하는 임의적 엘리먼트.

표 2에 예시된 바와 같이, AEA 메시지는 긴급에 관련된 부가의 미디어 리소스들(예컨대, 비디오, 오디오, 텍스트, 이미지들 등)이 어디에서 획득될 수 있는지를 식별해주는 URI(Media@URI)를 포함할 수 있다. AEA 메시지는 부가의 미디어 리소스들과 연관된 정보를 포함할 수 있다. 표 2에 제공된 바와 같은, 부가의 미디어 리소스와 연관된 정보의 시그널링이 이상적이지 않을 수 있다.

앞서 설명된 바와 같이, 제안된 ATSC 3.0 표준 스위트는 비디오 또는 오디오 워터마크를 사용하는 시그널링을 지원한다. 워터마크는 멀티미디어 콘텐츠가 어떻게 배포되는지에 관계없이 수신자 디바이스가 보충 콘텐츠(예컨대, 긴급 메시지들, 대안의 오디오 트랙들, 애플리케이션 데이터, 클로즈드 캡셔닝 데이터(closed captioning data) 등)를 검색할 수 있도록 보장하는 데 유용할 수 있다. 예를 들어, 로컬 네트워크 계열사는, 수신자 디바이스가 로컬 텔레비전 프레젠테이션과 연관된 보충 정보를 검색할 수 있고, 따라서 보충 콘텐츠를 시청자에게 제시할 수 있도록 보장하기 위해, 워터마크를 비디오 신호에 임베딩할 수 있다. 예를 들어, 콘텐츠 제공자는 재배포 시나리오 동안 메시지가 미디어 서비스의 프레젠테이션과 함께 나타나도록 보장하기를 원할 수 있다. 재배포 시나리오의 일 예는 ATSC 3.0 수신자 디바이스가 멀티미디어 신호(예컨대, 비디오 및/또는 오디오 신호)를 수신하고 멀티미디어 신호로부터 임베딩된 정보를 복구하는 상황을 포함할 수 있다. 예를 들어, 수신자 디바이스(예컨대, 디지털 텔레비전)는 멀티미디어 인터페이스(예컨대, HDMI(High Definition Multimedia Interface), 또는 이와 유사한 것)로부터 비압축된(uncompressed) 비디오 신호를 수신할 수 있고, 수신자 디바이스는 비압축된 비디오 신호로부터 임베딩된 정보를 복구할 수 있다. 일부 경우들에서, MVPD가 수신자 디바이스와 콘텐츠 제공자(예컨대, 지역 네트워크 계열사) 사이의 중재자(intermediary)로서 기능할 때 재배포 시나리오가 일어날 수 있다. 이 경우들에서, 셋톱 박스는 특정 물리 계층, 링크 계층, 및/또는 네트워크 계층 포맷들을 통해 멀티미디어 서비스 데이터 스트림을 수신하고, 비압축된 멀티미디어 신호를 수신자 디바이스에 출력할 수 있다. 일부 예들에서, 재배포 시나리오가 셋톱 박스 또는 홈 미디어 서버가 가정 내 비디오 분배기(in-home video distributor)로서 기능하고 접속된 디바이스(예컨대, 스마트폰들, 태블릿들 등)에 (예컨대, 로컬 유선 또는 무선 네트워크를 통해) 서빙하는 상황을 포함할 수 있다는 점에 유의해야 한다. 게다가, 일부 경우들에서, MVPD가 콘텐츠 제공자로부터 유래하는 콘텐츠를 향상시키기 위해(예컨대, 타깃 보충 광고(targeted supplemental advertisement)를 제공하기 위해) 비디오 신호에 워터마크를 임베딩할 수 있다는 점에 유의해야 한다.

그 전체가 참고로 포함되는, 문헌 [ATSC Candidate Standard: Content Recovery (A/336), Doc. S33-178r2, 15 January 2016 (이하, "A/336")]는 특정 시그널링 정보가 오디오 워터마크 페이로드들, 비디오 워터마크 페이로드들, 및 오디오 트랙들의 사용자 영역들(user areas)에서 어떻게 운반될 수 있는지, 및 이 정보가 재배포 시나리오에서 보충 콘텐츠에 액세스하는 데 어떻게 사용될 수 있는지를 명시한다. A/336은 비디오 워터마크 페이로드가 emergency_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()를 부가(add)하기 위한 제안들이 이루어졌다. 일부 예들에서, advanced_emergency_alert_message()가 AEA_message()라고 지칭될 수 있다는 점에 유의해야 한다. 표 6, 및 본 명세서에 설명된 다른 표들에서, char은 문자를 지칭한다.

[표 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()에 포함된 location에 대해 이하의 정의들이 제공되었다:

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 - 이 파라미터는 국제 원자시(International Atomic Time)(TAI) 1970년 1월 1일 00:00:00 이후의 초 수(number of seconds)의 32-비트 카운트로서 인코딩된, AEA 메시지의 유효 날짜 및 시간을 표시해야 한다. 이 파라미터는 [A/331]에 정의된 현재의 진보된 긴급 경보 메시지의 AEAT.AEA.Header@effective 속성의 값이어야 한다.

expires - 이 파라미터는 국제 원자시(TAI) 1970년 1월 1일 00:00:00 이후의 초 수의 32-비트 카운트로서 인코딩된, AEA 메시지의 최종 만료 날짜 및 시간(latest expiration date and time)을 표시해야 한다. 이 파라미터는 [A/331]에 정의된 현재의 진보된 긴급 경보 메시지의 AEAT.AEA.Header@expires 속성의 값이어야 한다.

audience - 이 3-비트 부호없는 정수 필드는 메시지의 오디언스 타입을 제공한다. 이 부호없는 정수는 [A/331]에 정의된 현재의 진보된 긴급 경보 메시지의 AEAT.AEA@audience 속성의 값이어야 한다. 값은 표 7에 따라 코딩되어야 한다.

[표 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에 따라 코딩되어야 한다.

[표 8]

priority - 이 4-비트 부호없는 정수는 [A/331]에 정의된 현재의 진보된 긴급 경보 메시지의 AEAT.AEA@priority 속성의 값이어야 한다.

ref_AEA_ID_flag - 이 1-비트 불 플래그(Boolean flag) 필드는 AEA 메시지 내의 ref_AEA_ID 필드의 존재를 표시한다.

num_AEA_text - 이 2-비트 부호없는 정수 필드는 AEA 메시지 내의 AEA_text 필드의 수를 제공한다.

num_location - 이 2-비트 부호없는 정수 필드는 AEA 메시지 내의 location 필드의 수를 제공한다.

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 속성의 처음 2개의 문자이어야 한다.

AEA_text_length - 이 8-비트 부호없는 정수 필드는 바이트 단위로 AEA_text 필드의 길이를 제공한다.

AEA_text - 이 스트링은 [A/331]에 정의된 현재의 진보된 긴급 경보 메시지의 AEAT.AEA.AEAtext 엘리먼트의 값이어야 한다.

location_type - 이 3-비트 부호없는 정수 필드는 location 필드의 타입을 제공한다. 이 부호없는 정수는, "polygon" 위치 타입이 비디오 워터마크 메시지에서 사용되지 않아야 한다는 제약을 갖는, [A/331]에 정의된 현재의 진보된 긴급 경보 메시지의 AEAT.AEA.Header.Location@type 속성의 값이어야 한다. 값은 표 9에 따라 코딩되어야 한다.

[표 9]

location_length - 이 8-비트 부호없는 정수 필드는 바이트 단위로 location 필드의 길이를 제공한다.

location - 이 스트링은 [A/331]에 정의된 현재의 진보된 긴급 경보 메시지의 AEAT.AEA.Header.Location 엘리먼트의 값이어야 한다.

표 6에 예시된 바와 같이, advanced_emergency_alert_message()는 num_AEA_text 및 num_location의 각자의 2-비트 값들이 0 내지 3의 범위에 있는 것에 기초하여 최대 3개의 AEA 텍스트 스트링 및 최대 3개의 AEA 위치 스트링을 시그널링할 수 있다. 게다가, 표 6에 예시된 바와 같이, AEA 텍스트 스트링들의 언어는 AEA_text_lang_code 엘리먼트를 사용하여 시그널링될 수 있다. 표 6에 제공된 시그널링은 이상적이지 않을 수 있다. 이러한 방식으로, ATSC 3.0 표준 스위트에서 긴급 경보 메시지들을 시그널링하기 위해 제안된 메커니즘들은 이상적이지 않을 수 있다.

도 2는 본 개시내용에 설명된 하나 이상의 기법을 구현할 수 있는 시스템의 일 예를 예시하는 블록 다이어그램이다. 시스템(200)은 본 명세서에 설명된 기법들에 따라 데이터를 통신하도록 구성될 수 있다. 도 2에 예시된 예에서, 시스템(200)은 하나 이상의 수신자 디바이스(202A 내지 202N), 하나 이상의 컴패니언 디바이스(companion device)(들)(203), 텔레비전 서비스 네트워크(204), 텔레비전 서비스 제공자 사이트(206), 광역 네트워크(212), 하나 이상의 콘텐츠 제공자 사이트(들)(214), 하나 이상의 긴급 기관 사이트(들)(216), 및 하나 이상의 긴급 경보 데이터 제공자 사이트(들)(218)를 포함한다. 시스템(200)은 소프트웨어 모듈들을 포함할 수 있다. 소프트웨어 모듈들은 메모리에 저장되고 프로세서에 의해 실행될 수 있다. 시스템(200)은 하나 이상의 프로세서 및 복수의 내부 및/또는 외부 메모리 디바이스들을 포함할 수 있다. 메모리 디바이스들의 예들은 파일 서버들, FTP(file transfer protocol) 서버들, NAS(network attached storage) 디바이스들, 로컬 디스크 드라이브들, 또는 데이터를 저장할 수 있는 임의의 다른 타입의 디바이스 또는 스토리지 매체를 포함한다. 스토리지 매체들은 블루 레이 디스크들, DVD들, CD-ROM들, 자기 디스크들, 플래시 메모리, 또는 임의의 다른 적당한 디지털 스토리지 매체들을 포함할 수 있다. 본 명세서에 설명된 기법들이 부분적으로 소프트웨어로 구현될 때, 디바이스는 소프트웨어에 대한 명령어들을 적당한 비일시적 컴퓨터 판독가능 매체에 저장하고 하나 이상의 프로세서를 사용하여 하드웨어로 명령어들을 실행할 수 있다.

시스템(200)은, 예를 들어, 영화, 라이브 스포츠 이벤트 등과 같은, 디지털 미디어 콘텐츠, 및 이와 연관된 데이터, 애플리케이션들 및 미디어 프레젠테이션들(예컨대, 긴급 경보 메시지들)이, 수신자 디바이스들(202A 내지 202N)과 같은, 복수의 컴퓨팅 디바이스들에 배포되고 이들에 의해 액세스될 수 해주도록 구성될 수 있는 시스템의 일 예를 나타낸다. 도 2에 예시된 예에서, 수신자 디바이스들(202A 내지 202N)은 텔레비전 서비스 제공자 사이트(206)로부터 데이터를 수신하도록 구성된 임의의 디바이스를 포함할 수 있다. 예를 들어, 수신자 디바이스들(202A 내지 202N)은 유선 및/또는 무선 통신을 위한 장비를 갖출(equipped) 수 있고, 하나 이상의 데이터 채널을 통해 서비스들을 수신하도록 구성될 수 있으며, 소위 스마트 텔레비전들을 포함한, 텔레비전들, 셋톱 박스들, 및 디지털 비디오 레코더들을 포함할 수 있다. 게다가, 수신자 디바이스들(202A 내지 202N)은 텔레비전 서비스 제공자 사이트(206)로부터 데이터를 수신하도록 구성된 데스크톱, 랩톱, 또는 태블릿 컴퓨터들, 게이밍 콘솔들, 예를 들어, "스마트" 폰들, 셀룰러 전화들을 포함한, 모바일 디바이스들, 및 개인 게이밍 디바이스들을 포함할 수 있다. 비록 시스템(200)이 구별되는 사이트들을 갖는 것으로 예시되어 있지만, 그러한 예시가 설명 목적들을 위한 것이고 시스템(200)을 특정의 물리적 아키텍처로 제한하지 않는다는 점에 유의해야 한다. 시스템(200)의 기능들 및 시스템(200)에 포함된 사이트들은 하드웨어, 펌웨어 및/또는 소프트웨어 구현들의 임의의 조합을 사용하여 실현될 수 있다.

텔레비전 서비스 네트워크(204)는 텔레비전 서비스들을 포함할 수 있는 디지털 미디어 콘텐츠가 배포될 수 있게 해주도록 구성된 네트워크의 일 예이다. 예를 들어, 텔레비전 서비스 네트워크(204)는 공중 오버-디-에어 텔레비전 네트워크들, 공중 또는 가입 기반 위성 텔레비전 서비스 제공자 네트워크들, 및 공중 또는 가입 기반 케이블 텔레비전 제공자 네트워크들 및/또는 오버 더 톱(over the top) 또는 인터넷 서비스 제공자들을 포함할 수 있다. 비록, 일부 예들에서, 텔레비전 서비스 네트워크(204)가 텔레비전 서비스들이 제공될 수 있게 해주는 데 주로 사용될 수 있지만, 텔레비전 서비스 네트워크(204)가 또한 다른 타입의 데이터 및 서비스들이 본 명세서에 설명된 원격통신 프로토콜들(telecommunication protocols)의 임의의 조합에 따라 제공될 수 있게 해줄 수 있다는 점에 유의해야 한다. 게다가, 일부 예들에서, 텔레비전 서비스 네트워크(204)가 텔레비전 서비스 제공자 사이트(206)와 수신자 디바이스들(202A 내지 202N) 중 하나 이상 사이의 양방향 통신을 가능하게 해줄 수 있다는 점에 유의해야 한다. 텔레비전 서비스 네트워크(204)는 무선 및/또는 유선 통신 매체들의 임의의 조합을 포함할 수 있다. 텔레비전 서비스 네트워크(204)는 동축 케이블들, 광섬유 케이블들, 연선 케이블들, 무선 송신기들 및 수신기들, 라우터들, 스위치들, 리피터들(repeaters), 기지국들, 또는 다양한 디바이스들과 사이트들 간의 통신을 용이하게 하는 데 유용할 수 있는 임의의 다른 장비를 포함할 수 있다. 텔레비전 서비스 네트워크(204)는 하나 이상의 원격통신 프로토콜의 조합에 따라 동작할 수 있다. 원격통신 프로토콜들은 독점적 양태들을 포함할 수 있고 그리고/또는 표준화된 원격통신 프로토콜들을 포함할 수 있다. 표준화된 원격통신 프로토콜들의 예들은 DVB 표준들, ATSC 표준들, ISDB 표준들, DTMB 표준들, DMB 표준들, DOCSIS(Data Over Cable Service Interface Specification) 표준들, HbbTV 표준들, W3C 표준들, 및 UPnP 표준들을 포함한다.

도 2를 또다시 참조하면, 텔레비전 서비스 제공자 사이트(206)는 텔레비전 서비스 네트워크(204)를 통해 텔레비전 서비스를 배포하도록 구성될 수 있다. 예를 들어, 텔레비전 서비스 제공자 사이트(206)는 하나 이상의 방송국, 예를 들어, 케이블 텔레비전 제공자, 또는 위성 텔레비전 제공자, 또는 인터넷 기반 텔레비전 제공자와 같은, MVPD를 포함할 수 있다. 도 2에 예시된 예에서, 텔레비전 서비스 제공자 사이트(206)는 서비스 배포 엔진(208), 콘텐츠 데이터베이스(210A), 및 긴급 경보 데이터베이스(210B)를 포함한다. 서비스 배포 엔진(208)은, 예를 들어, 멀티미디어 콘텐츠, 대화형 애플리케이션들을 포함한, 데이터, 및, 긴급 경보들 및/또는 긴급 경보 메시지들을 포함한, 메시지들을 수신하고, 데이터를 텔레비전 서비스 네트워크(204)를 통해 수신자 디바이스들(202A 내지 202N)에 배포하도록 구성될 수 있다. 예를 들어, 서비스 배포 엔진(208)은 앞서 설명된 전송 표준들 중 하나 이상(예컨대, ATSC 표준)의 양태들에 따라 텔레비전 서비스들을 전송하도록 구성될 수 있다. 일 예에서, 서비스 배포 엔진(208)은 하나 이상의 소스를 통해 데이터를 수신하도록 구성될 수 있다. 예를 들어, 텔레비전 서비스 제공자 사이트(206)는 위성 업링크 및/또는 다운링크를 통해 또는 직접 전송(direct transmission)을 통해 지방 또는 전국 방송 네트워크(예컨대, NBC, ABC 등)로부터 텔레비전 프로그래밍을 포함한 전송을 수신하도록 구성될 수 있다. 게다가, 도 2에 예시된 바와 같이, 텔레비전 서비스 제공자 사이트(206)는 광역 네트워크(212)와 통신할 수 있고, 콘텐츠 제공자 사이트(들)(214)로부터 멀티미디어 콘텐츠 및 데이터를 수신하도록 구성될 수 있다. 일부 예들에서, 텔레비전 서비스 제공자 사이트(206)가 텔레비전 스튜디오를 포함할 수 있고, 콘텐츠가 그것으로부터 유래할 수 있다는 점에 유의해야 한다.

콘텐츠 데이터베이스(210A) 및 긴급 경보 데이터베이스(210B)는 데이터를 저장하도록 구성된 스토리지 디바이스들을 포함할 수 있다. 예를 들어, 콘텐츠 데이터베이스(210A)는 멀티미디어 콘텐츠 및 이와 연관된 데이터 - 예를 들어, 설명 데이터(descriptive data) 및 실행가능한 대화형 애플리케이션들을 포함함 - 를 저장할 수 있다. 예를 들어, 스포츠 이벤트는 통계 업데이트들을 제공하는 대화형 애플리케이션과 연관될 수 있다. 긴급 경보 데이터베이스(210B)는, 예를 들어, 긴급 경보 메시지들을 포함한, 긴급 경보들과 관련된 데이터를 저장할 수 있다. 데이터는, 예를 들어, HTML, 동적 HTML, XML, 및 JSON(JavaScript Object Notation)과 같은, 정의된 데이터 포맷에 따라 포맷팅될 수 있고, 수신자 디바이스들(202A 내지 202N)이, 예컨대, 긴급 경보 데이터 제공자 사이트(들)(218) 중 하나로부터의 데이터에 액세스할 수 있게 해주는 URL들 및 URI들을 포함할 수 있다. 일부 예들에서, 텔레비전 서비스 제공자 사이트(206)는 저장된 멀티미디어 콘텐츠에 대한 액세스를 제공하고 텔레비전 서비스 네트워크(204)를 통해 수신자 디바이스들(202A 내지 202N) 중 하나 이상에 멀티미디어 콘텐츠를 배포하도록 구성될 수 있다. 예를 들어, 콘텐츠 데이터베이스(210A)에 저장된 멀티미디어 콘텐츠(예컨대, 음악, 영화들, 및 텔레비전(TV) 쇼들)는 소위 온 디맨드(on demand) 방식으로 텔레비전 서비스 네트워크(204)를 통해 사용자에게 제공될 수 있다.

도 2에 예시된 바와 같이, 텔레비전 서비스 제공자 사이트(206)로부터 데이터를 수신하도록 구성되는 것에 부가하여, 수신자 디바이스(202N)는 컴패니언 디바이스(들)(203)와 통신하도록 구성될 수 있다. 도 2에 예시된 예에서, 컴패니언 디바이스(들)(203)는 (예컨대, 단거리 통신 프로토콜, 예컨대, 블루투스를 사용하여) 수신자 디바이스와 직접 통신하고, 로컬 영역 네트워크를 통해(예컨대, Wi-Fi 라우터를 통해) 수신자 디바이스와 통신하며, 그리고/또는 광역 네트워크(예컨대, 셀룰러 네트워크)와 통신하도록 구성될 수 있다. 이하에서 상세히 설명되는 바와 같이, 컴패니언 디바이스는, 그 상에서 실행 중인 애플리케이션에 의한 사용을 위해, 긴급 경보 정보를 포함한, 데이터를 수신하도록 구성될 수 있다. 컴패니언 디바이스(들)(203)는 수신자 디바이스와 함께 애플리케이션들을 실행하도록 구성된 컴퓨팅 디바이스를 포함할 수 있다. 도 2에 예시된 예에서, 비록 단일 컴패니언 디바이스가 예시되어 있지만, 각각의 수신자 디바이스(202A 내지 202N)가 복수의 컴패니언 디바이스(들)와 연관될 수 있다는 점에 유의해야 한다. 컴패니언 디바이스(들)(203)는 유선 및/또는 무선 통신을 위한 장비를 갖출 수 있으며, 예를 들어, 데스크톱, 랩톱, 또는 태블릿 컴퓨터들, 모바일 디바이스들, 스마트폰들, 셀룰러 전화들, 및 개인 게이밍 디바이스들과 같은, 디바이스들을 포함할 수 있다. 비록 도 2에 예시되어 있지 않지만, 일부 예들에서, 컴패니언 디바이스(들)가 텔레비전 서비스 네트워크(204)로부터 데이터를 수신하도록 구성될 수 있다는 점에 유의해야 한다.

광역 네트워크(212)는 패킷 기반 네트워크를 포함하고, 하나 이상의 원격통신 프로토콜의 조합에 따라 동작할 수 있다. 원격통신 프로토콜들은 독점적 양태들을 포함할 수 있고 그리고/또는 표준화된 원격통신 프로토콜들을 포함할 수 있다. 표준화된 원격통신 프로토콜들의 예들은 GSM(Global System Mobile Communications) 표준들, CDMA(code division multiple access) 표준들, 3GPP(3rd Generation Partnership Project) 표준들, ETSI(European Telecommunications Standards Institute) 표준들, 유럽 표준들(EN), IP 표준들, WAP(Wireless Application Protocol) 표준들, 및, 예를 들어, IEEE 802 표준들 중 하나 이상(예컨대, Wi-Fi)와 같은, IEEE(Institute of Electrical and Electronics Engineers) 표준들을 포함한다. 광역 네트워크(212)는 무선 및/또는 유선 통신 매체들의 임의의 조합을 포함할 수 있다. 광역 네트워크(212)는 동축 케이블들, 광섬유 케이블들, 연선 케이블들, 이더넷 케이블들, 무선 송신기들 및 수신기들, 라우터들, 스위치들, 리피터들, 기지국들, 또는 다양한 디바이스들과 사이트들 간의 통신을 용이하게 하는 데 유용할 수 있는 임의의 다른 장비를 포함할 수 있다. 일 예에서, 광역 네트워크(212)는 인터넷을 포함할 수 있다.

도 2를 또다시 참조하면, 콘텐츠 제공자 사이트(들)(214)는 멀티미디어 콘텐츠를 텔레비전 서비스 제공자 사이트(206)에 그리고/또는 일부 경우들에서 수신자 디바이스들(202A 내지 202N)에 제공할 수 있는 사이트들의 예들을 나타낸다. 예를 들어, 콘텐츠 제공자 사이트는 멀티미디어 파일들 및/또는 콘텐츠 피드들(content feeds)을 텔레비전 서비스 제공자 사이트(206)에 제공하도록 구성된 하나 이상의 스튜디오 콘텐츠 서버를 갖는 스튜디오를 포함할 수 있다. 일 예에서, 콘텐츠 제공자 사이트(들)(214)는 IP 스위트(IP suite)를 사용하여 멀티미디어 콘텐츠를 제공하도록 구성될 수 있다. 예를 들어, 콘텐츠 제공자 사이트는 RTSP(Real Time Streaming Protocol), HTTP(HyperText Transfer Protocol), 또는 이와 유사한 것에 따라 멀티미디어 콘텐츠를 수신자 디바이스에 제공하도록 구성될 수 있다.

긴급 기관 사이트(들)(216)는 긴급 경보들을 텔레비전 서비스 제공자 사이트(206)에 제공할 수 있는 사이트들의 예들을 나타낸다. 예를 들어, 앞서 설명된 바와 같이, 긴급 기관들은 미국 국립 기상청, 미국 국토 안보부, 지역 및 지방 기관들, 및 이와 유사한 것을 포함할 수 있다. 긴급 기관 사이트는 (직접 또는 광역 네트워크(212)를 통해) 텔레비전 서비스 제공자 사이트(206)와 통신하는 긴급 기관의 물리적 위치일 수 있다. 긴급 기관 사이트는 긴급 경보들을 텔레비전 서비스 제공자 사이트(206)에 제공하도록 구성된 하나 이상의 서버를 포함할 수 있다. 앞서 기술된 바와 같이, 서비스 제공자, 예컨대, 텔레비전 서비스 제공자 사이트(206)는 긴급 경보를 수신하고 수신자 디바이스, 예컨대, 수신자 디바이스들(202A 내지 202N)로의 배포를 위한 긴급 경보 메시지를 생성할 수 있다. 일부 경우들에서 긴급 경보와 긴급 경보 메시지가 유사할 수 있다는 점에 유의해야 한다. 예를 들어, 텔레비전 서비스 제공자 사이트(206)는 긴급 기관 사이트(들)(216)로부터 수신된 XML 프래그먼트를 긴급 경보 메시지의 일부로서 수신자 디바이스들(202A 내지 202N)로 전달할 수 있다. 텔레비전 서비스 제공자 사이트(206)는, 예를 들어, HTML, 동적 HTML, XML, 및 JSON과 같은, 정의된 데이터 포맷에 따라 긴급 경보 메시지를 생성할 수 있다.

앞서 설명된 바와 같이, 긴급 경보 메시지는 긴급에 관련된 부가 콘텐츠가 어디서 획득될 수 있는지를 식별해주는 URI들을 포함할 수 있다. 긴급 경보 데이터 제공자 사이트(들)(218)는 미디어 콘텐츠, 하이퍼텍스트 기반 콘텐츠, XML 프래그먼트들, 및 이와 유사한 것을 포함한, 긴급 경보 데이터를 광역 네트워크(212)를 통해 수신자 디바이스들(202A 내지 202N) 중 하나 이상 및/또는, 일부 예들에서, 텔레비전 서비스 제공자 사이트(206)에 제공하도록 구성된 사이트들의 예들을 나타낸다. 긴급 경보 데이터 제공자 사이트(들)(218)는 하나 이상의 웹 서버를 포함할 수 있다.

앞서 설명된 바와 같이, 서비스 배포 엔진(208)은, 예를 들어, 멀티미디어 콘텐츠, 대화형 애플리케이션들, 및 메시지들을 포함한, 데이터를 수신하고, 데이터를 텔레비전 서비스 네트워크(204)를 통해 수신자 디바이스들(202A 내지 202N)에 배포하도록 구성될 수 있다. 따라서, 하나의 예시적인 시나리오에서, 텔레비전 서비스 제공자 사이트(206)는 긴급 기관 사이트(들)(216)로부터의 긴급 경보(예컨대, 테러리스트 경고)를 수신할 수 있다. 서비스 배포 엔진(208)은 긴급 경보에 기초하여 긴급 경보 메시지(예컨대, "테러리스트 경고" 텍스트를 포함하는 메시지)를 생성할 수 있고, 긴급 메시지가 수신자 디바이스들(202A 내지 202N)에 배포되도록 할 수 있다. 예를 들어, 서비스 배포 엔진(208)은 긴급 경보 메시지들을 통신하기 위해, 앞서 설명된 바와 같이, LLS 및/또는 워터마크들을 사용할 수 있다.

도 3은 본 개시내용의 하나 이상의 기법을 구현할 수 있는 서비스 배포 엔진의 일 예를 예시하는 블록 다이어그램이다. 서비스 배포 엔진(300)은 데이터를 수신하고 통신 네트워크, 예컨대, 텔레비전 서비스 네트워크(204)를 통해 배포하기 위해 그 데이터를 나타내는 신호를 출력하도록 구성될 수 있다. 예를 들어, 서비스 배포 엔진(300)은 하나 이상의 데이터 세트(sets of data)를 수신하고 단일 라디오 주파수 대역(예컨대, 6 MHz 채널, 8 MHz 채널 등) 또는 본딩된 채널(bonded channel)(예컨대, 2개의 개별 6 MHz 채널)을 사용하여 전송될 수 있는 신호를 출력하도록 구성될 수 있다.

도 3에 예시된 바와 같이, 서비스 배포 엔진(300)은 컴포넌트 캡슐화기(302), 전송 및 네트워크 패킷 생성기(304), 링크 계층 패킷 생성기(306), 프레임 빌더 및 파형 생성기(frame builder and waveform generator)(308), 및 시스템 메모리(310)를 포함한다. 컴포넌트 캡슐화기(302), 전송 및 네트워크 패킷 생성기(304), 링크 계층 패킷 생성기(306), 프레임 빌더 및 파형 생성기(308), 및 시스템 메모리(310) 각각은 컴포넌트간 통신(inter-component communications)을 위해 (물리적으로(physically), 통신가능하게(communicatively), 및/또는 동작가능하게(operatively)) 상호접속될 수 있고, 하나 이상의 마이크로프로세서, 디지털 신호 프로세서(DSP), ASIC(application specific integrated circuit), FPGA(field programmable gate array), 이산 로직(discrete logic), 소프트웨어, 하드웨어, 펌웨어 또는 이들의 임의의 조합들과 같은, 다양한 적당한 회로부 중 임의의 것으로 구현될 수 있다. 비록 서비스 배포 엔진(300)이 구별되는 기능 블록들을 갖는 것으로 예시되어 있지만, 그러한 예시가 설명 목적들을 위한 것이고 서비스 배포 엔진(300)을 특정의 하드웨어 아키텍처로 제한하지 않는다는 점에 유의해야 한다. 서비스 배포 엔진(300)의 기능들은 하드웨어, 펌웨어 및/또는 소프트웨어 구현들의 임의의 조합을 사용하여 실현될 수 있다.

시스템 메모리(310)는 비일시적 또는 유형적 컴퓨터 판독가능 스토리지 매체로서 설명될 수 있다. 일부 예들에서, 시스템 메모리(310)는 일시적 및/또는 장기 스토리지(temporary and/or long-term storage)를 제공할 수 있다. 일부 예들에서, 시스템 메모리(310) 또는 그 부분들은 비휘발성 메모리로서 설명될 수 있고, 다른 예들에서 시스템 메모리(310)의 부분들은 휘발성 메모리로서 설명될 수 있다. 휘발성 메모리들의 예들은 랜덤 액세스 메모리들(RAM), 동적 랜덤 액세스 메모리들(DRAM), 및 정적 랜덤 액세스 메모리들(SRAM)을 포함한다. 비휘발성 메모리들의 예들은 자기 하드 디스크들, 광학 디스크들, 플로피 디스크들, 플래시 메모리들, 또는 전기적 프로그래밍가능 메모리들(EPROM) 또는 전기적 소거가능 프로그래밍가능 메모리들(EEPROM)의 형태들을 포함한다. 시스템 메모리(310)는 동작 동안 서비스 배포 엔진(300)에 의해 사용될 수 있는 정보를 저장하도록 구성될 수 있다. 시스템 메모리(310)가 컴포넌트 캡슐화기(302), 전송 및 네트워크 패킷 생성기(304), 링크 계층 패킷 생성기(306), 및 프레임 빌더 및 파형 생성기(308) 각각 내에 포함된 개개의 메모리 요소들을 포함할 수 있다는 점에 유의해야 한다. 예를 들어, 시스템 메모리(310)는 데이터를 서비스 배포 엔진(300)의 컴포넌트에 의한 프로세싱을 위해 저장하도록 구성된 하나 이상의 버퍼(예컨대, FIFO(First-in First-out) 버퍼)를 포함할 수 있다.

컴포넌트 캡슐화기(302)는 서비스의 하나 이상의 컴포넌트를 수신하고 정의된 데이터 구조에 따라 하나 이상의 컴포넌트를 캡슐화하도록 구성될 수 있다. 예를 들어, 컴포넌트 캡슐화기(302)는 하나 이상의 미디어 컴포넌트를 수신하고 MMTP에 기초한 패키지를 생성하도록 구성될 수 있다. 게다가, 컴포넌트 캡슐화기(302)는 하나 이상의 미디어 컴포넌트를 수신하고 DASH(Dynamic Adaptive Streaming Over HTTP)에 기초한 미디어 프레젠테이션을 생성하도록 구성될 수 있다. 일부 예들에서, 컴포넌트 캡슐화기(302)가 서비스 계층 시그널링 데이터를 생성하도록 구성될 수 있다는 점에 유의해야 한다.

전송 및 네트워크 패킷 생성기(304)는 전송 패키지를 수신하고 전송 패키지를 대응하는 전송 계층 패킷들(예컨대, UDP, TCP(Transport Control Protocol) 등) 및 네트워크 계층 패킷들(예컨대, IPv4 , IPv6, 압축된 IP 패킷들 등)로 캡슐화하도록 구성될 수 있다. 일 예에서, 전송 및 네트워크 패킷 생성기(304)는 시그널링 기능에 전용된 어드레스 및/또는 포트를 갖는 IP 패킷들의 페이로드에서 운반되는 시그널링 정보를 생성하도록 구성될 수 있다. 즉, 예를 들어, 전송 및 네트워크 패킷 생성기(304)는 본 개시내용의 하나 이상의 기법에 따라 LLS 테이블들을 생성하도록 구성될 수 있다.

링크 계층 패킷 생성기(306)는 네트워크 패킷들을 수신하고 정의된 링크 계층 패킷 구조(예컨대, ATSC 3.0 링크 계층 패킷 구조)에 따라 패킷들을 생성하도록 구성될 수 있다. 프레임 빌더 및 파형 발생기(308)는 프레임 구조에 배열된 하나 이상의 링크 계층 패킷 및 출력 심벌(예컨대, OFDM 심벌)을 수신하도록 구성될 수 있다. 앞서 기술된 바와 같이, 프레임은 물리 계층 프레임(PHY-계층 프레임)이라고 지칭될 수 있는, 하나 이상의 PLP를 포함할 수 있다. 앞서 기술된 바와 같이, 프레임 구조는 부트스트랩, 프리앰블, 및 하나 이상의 PLP를 포함하는 데이터 페이로드를 포함할 수 있다. 부트스트랩은 파형에 대한 범용 엔트리 포인트(universal entry point)로서 기능할 수 있다. 프리앰블은 소위 계층-1 시그널링(L1-시그널링)을 포함할 수 있다. L1-시그널링은 물리 계층 파라미터들을 구성하는 데 필요한 정보를 제공할 수 있다. 프레임 빌더 및 파형 발생기(308)는 하나 이상의 타입의 RF 채널들: 단일 6 MHz 채널, 단일 7 MHz 채널, 단일 8 MHz 채널, 단일 11 MHz 채널, 및 임의의 2개 이상의 개별 단일 채널을 포함하는 본딩된 채널들(예컨대, 6 MHz 채널과 8 MHz 채널을 포함하는 14 MHz 채널) 내에서 전송하기 위한 신호를 생성하도록 구성될 수 있다. 프레임 빌더 및 파형 발생기(308)는 채널 추정 및/또는 동기화를 위해 파일럿들 및 예약된 톤들을 삽입하도록 구성될 수 있다. 일 예에서, 파일럿들 및 예약된 톤들은 OFDM(Orthogonal Frequency Division Multiplexing) 심벌 및 서브캐리어 주파수 맵(sub-carrier frequency map)에 따라 정의될 수 있다. 프레임 빌더 및 파형 발생기(308)는 OFDM 심벌들을 서브캐리어들에 매핑함으로써 OFDM 파형을 생성하도록 구성될 수 있다. 일부 예들에서, 프레임 빌더 및 파형 발생기(308)가 계층 분할 다중화(layer division multiplexing)를 지원하도록 구성될 수 있다는 점에 유의해야 한다. 계층 분할 다중화는 동일한 RF 채널(예컨대, 6 MHz 채널) 상에 다수의 데이터 계층들(layers of data)을 중첩(super-imposing)시키는 것을 지칭할 수 있다. 전형적으로, 상위 계층은 프라이머리 서비스(primary service)를 지원하는 코어(예컨대, 보다 강건한) 계층을 지칭하고, 하위 계층은 향상된 서비스들을 지원하는 고 데이터 레이트 계층을 지칭한다. 예를 들어, 상위 계층은 기본 고화질(basic High Definition) 비디오 콘텐츠를 지원할 수 있고 하위 계층은 향상된 초고화질(enhanced Ultra-High Definition) 비디오 콘텐츠를 지원할 수 있다.

앞서 기술된 바와 같이, 전송 및 네트워크 패킷 생성기(304)는 본 개시내용의 하나 이상의 기법에 따라 LLS 테이블들을 생성하도록 구성될 수 있다. 일부 예들에서, 서비스 배포 엔진(예컨대, 서비스 배포 엔진(208) 또는 서비스 배포 엔진(300)) 또는 그의 특정 컴포넌트들이 본 명세서에 설명된 기법들에 따라 시그널링 메시지들을 생성하도록 구성될 수 있다는 점에 유의해야 한다. 그와 같이, 전송 및 네트워크 패킷 생성기(304)와 관련하여, 데이터 프래그먼트들을 포함한, 시그널링 메시지들의 디스크립션은 본 명세서에 설명된 기법들을 제한하는 것으로 해석되어서는 안된다. 일부 경우들에서, 사용자가 긴급 경보 메시지를 인식할 가능성을 증가시키기 위해 수신자 디바이스가 애플리케이션들을 일시적으로 중지시키고 그리고/또는 멀티미디어 프레젠테이션이 어떻게 렌더링되는지를 변경하는 것이 유용하고 그리고/또는 필요할 수 있다. 앞서 기술된 바와 같이, 긴급 경보 메시지들과 연관된 정보를 시그널링하기 위한 현재 제안된 기법들은 이상적이지 않을 수 있다.

전송 및 네트워크 패킷 생성기(304)는 긴급 경보 메시지를 시그널링 및/또는 생성하도록 구성될 수 있다. 일 예에서, 전송 및 네트워크 패킷 생성기(304)는 표 2와 관련하여 제공된 예시적인 구조에 기초하여 AEA 메시지를 생성하도록 구성될 수 있다. 일 예에서, 전송 및 네트워크 패킷 생성기(304)는 표 10A에 제공된 예시적인 신택스에 기초하여 LLS 테이블을 생성하도록 구성될 수 있다. 표 10A에서 표 2가 참조된다는 점에 유의해야 한다. 이러한 방식으로, 표 10A는 표 2에 포함된 엘리먼트들 및 속성들을 포함할 수 있다. 그렇지만, 표 10A에 예시된 바와 같이, Media 엘리먼트와 그 속성들은 표 2와 관련하여 제공된 Media 엘리먼트와 구별된다.

[표 10A]

표 10A에 예시된 예에서, Media@lang, Media@mediaDesc, Media@contentType, 및 Media@contentLength 각각은 이하의 예시적인 시맨틱스에 기초할 수 있다:

Media@lang - 이 속성은, 동일한 멀티미디어의 상이한 언어 인스턴스들이 송신되고 있는 경우 수신자에게 알려주는 데 도움을 주기 위해, 각각의 미디어 리소스에 대한 각자의 언어를 식별해주어야 한다. 이 속성은 Media 엘리먼트에 의해 명시된 미디어 리소스에 대한 언어를 표현해야 하며, BCP 47에 정의된 바와 같은 공식적인 자연 언어 식별자들에 의해 표현되어야 한다. 존재하지 않을 때, 이 속성의 값은 "en"(영어)인 것으로 추론되어야 한다. 다른 예에서, 존재하지 않을 때, 이 속성의 값은 "EN"(영어)인 것으로 추론되어야 한다.

다른 예에서, 존재하지 않을 때, 표준에 명시된 디폴트 값(default value)이 추론을 위해 사용되어야 한다. 예를 들어, "en"(영어) 대신에, 이 언어가 "es"(스페인어), "kr"(한국어) 또는 어떤 다른 언어일 수 있다.

Media@mediaDesc - 미디어 리소스의 콘텐츠를, 평문으로, 설명해야 하는 스트링. 디스크립션은 미디어 정보를 표시해야 한다. 예를 들어, "대피 지도" 또는 "도플러 레이더 이미지" 등. Media@mediaDesc의 언어는 Media@lang에 표시된 언어와 동일한 것으로 추론되어야 한다.

Media@contentType - Media@uri에 의해 참조되는 미디어 콘텐츠의 MIME 타입을 표현해야 하는 스트링. 일 예에서, Media@contentType은 IETF RFC 7231에서 제공된 HTTP/1.1 프로토콜의 Content-ype 헤더의 시맨틱스를 준수해야 한다. 다른 예에서, Media@contentType은 IETF RFC 2616에서 제공된 HTTP/1.1 프로토콜의 Content-ype 헤더의 시맨틱스를 준수해야 한다.

Media@contentLength - Media@uri에 의해 참조되는 미디어 콘텐츠의 바이트 단위의 크기를 표현해야 하는 스트링.

앞서 제공된 시맨틱스와 관련하여, 임의로 시그널링된 Media@lang에 대한 디폴트 값을 제공하는 것은 시그널링 효율을 개선시킬 수 있다. 게다가, 표 10A에 예시된 예에서, 미디어 콘텐츠 타입 및 미디어 디스크립션은 개별적으로(즉, 구별되는 속성들을 사용하여) 시그널링된다. 표 10A와 관련하여, 본 명세서에서 사용된 바와 같이, MIME 타입이 일반적으로 일부 경우들에서 미디어 또는 콘텐츠 타입을 지칭할 수 있고 다른 경우들에서 다목적 인터넷 메일 확장(Multipurpose Internet Mail Extensions)에 기초하여 정의된 미디어 또는 콘텐츠 타입들과 연관될 수 있다는 점에 유의해야 한다. 미디어 콘텐츠 타입 및 미디어 디스크립션을 개별적으로 시그널링하는 것은 미디어가 효율적인 방식으로 검색될 수 있게 해줄 수 있다. 즉, 미디어 콘텐츠 타입 및 미디어 디스크립션을 개별적으로 시그널링하는 것은 미디어 콘텐츠가 수신자 디바이스에 의해 검색되어야 하는지와 관련하여 부가의 결정들이 행해질 수 있게 해줄 수 있다. 예를 들어, 수신자 디바이스가 특정 미디어 타입들만을 디코딩할 수 있는 경우, 수신자 디바이스는 시그널링된 미디어 콘텐츠 타입에 대한 능력을 체크하고 콘텐츠를 디코딩할 능력을 갖는지를 결정할 수 있다. 이 경우에, 수신자 디바이스는 자신이 디코딩할 수 있는 콘텐츠만을 다운로드할 수 있다.

표 10A에 예시된 예에서, Media@contentType 속성은 머신 판독가능이고 자유 양식 스트링(free form string)이 아니다. 머신 판독가능 속성을 시그널링하는 것은 수신자 디바이스가 미디어 콘텐츠를 검색할지를 결정할 수 있게 해줄 수 있다. 예를 들어, MIME-type은 수신자 디바이스에 의해 지원되지 않는 파일 타입(예컨대, shockwave 플래시 포맷 파일(.swf) 파일)을 표시할 수 있으며, 이 경우에, 수신자 디바이스는 파일을 검색하지 못할 수 있다. 유사한 방식으로, 미디어 리소스의 파일 크기에 관한 정보는 미디어 리소스가 검색되어야 하는지를 결정하는 데 사용될 수 있다. 예를 들어, 수신자 디바이스는 임계치보다 낮은 크기를 갖는 파일들만을 검색하도록 구성될 수 있다. 예를 들어, 수신자 디바이스의 설정은 사용자가 비교적 큰 비디오 파일들이 검색되는 것을 방지할 수 있게 해줄 수 있다. 일 예에서, 이 설정은 디바이스의 가용 메모리 용량 및/또는 수신자 디바이스에 대한 가용 네트워크 대역폭에 기초할 수 있다.

일부 예들에서, 수신자 디바이스의 사용자는 사용자에게 제시된 미디어 속성들에 기초하여 콘텐츠를 검색할지를 결정할 수 있다. 예를 들어, 일 예에서, 수신자 디바이스는 미디어 디스크립션이 수신자 디바이스의 사용자에게 제시되게 할 수 있고, 디스크립션에 기초하여, 사용자는 콘텐츠를 검색할지를 결정할 수 있다. 이러한 방식으로, 미디어 디스크립션 언어의 언어가 시그널링되는 것이 유용하고 잠재적으로 필요하다. 상기 예에서, 언어는 Media@lang과 동일한 것으로 추론된다. 일 예에서, 필수적(mandatory) 또는 임의적(optional) 속성이 미디어 디스크립터의 언어를 시그널링하기 위해 표 10A에 포함될 수 있다. 일 예에서, 이 속성은 Media 엘리먼트의 속성일 수 있다. 일 예에서, 이 속성은 이하의 시맨틱스에 기초할 수 있다:

Media@mediaDescLang - 이 속성은 Media@mediaDesc에 명시된 텍스트의 언어를 명시해야 한다. 이 값은 BCP 47에 정의된 바와 같아야 한다. 존재하지 않을 때, 이 속성의 값은 "en"(영어)인 것으로 추론되어야 한다. Media@mediaDesc가 존재하지 않을 때 Media@mediaDescLang은 존재하지 않아야 한다.

비록 상기 예에서 필드들 contentType, contentLength 및 mediaDescLang이 Media XML 엘리먼트의 XML 속성들로서 시그널링되는 것으로 표시되어 있지만, 다른 예에서 그것들은 Media XML 엘리먼트 내의 (XML 속성들 대신에) XML 엘리먼트들로서 시그널링될 수 있다. 이러한 방식으로, 전송 및 네트워크 패킷 생성기(304)는 긴급 경보 메시지와 연관된 부가의 미디어 리소스와 연관된 정보를 시그널링하도록 구성될 수 있다.

일 예에서, 표 10A와 관련하여 설명된 미디어 속성들은 표 10B와 관련하여 이하에서 제공되는 예시적인 구조에 기초한 AEA 메시지에 포함될 수 있다.

[표 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 엘리먼트에 표시된 이벤트 코드에 대응해야 한다(예컨대, "토네이도 경고(Tornado Warning)"의 EventDesc는 "TOR"의 EAS EventCode에 대응한다). EventCode 엘리먼트가 존재하지 않을 때, EventDesc는 이벤트의 타입(예컨대, "휴교(School Closing)")의 간략하고 사용자에게 친숙한(user-friendly) 표시를 제공해야 한다. 일 예에서, AEA 내의 AEA.Header.EventDesc 엘리먼트의 출현 횟수는 8을 초과하지 않아야 한다.

EventDesc@lang - 이 속성은 경보 메시지의 각자의 EventDesc 엘리먼트의 언어를 식별해주어야 한다. 이 속성은 공식적인 자연 언어 식별자들에 의해 표현되어야 하며, 일 예에서, BCP 47에 의해 정의된 바와 같이, 길이가 35개의 문자를 초과하지 않아야 한다. 일 예에서, 암시적 디폴트 값이 없어야 한다.

LiveMedia - 긴급 관련 정보, 예컨대, 진행 중인 뉴스 보도(ongoing news coverage)를 위해 튜닝할 선택사항으로서 사용자에게 제시될 수 있는 A/V 서비스의 ID(Identification).

LiveMedia@bsid - 긴급 관련 라이브 A/V 서비스를 포함하는 방송 스트림의 식별자.

LiveMedia@serviceId - 긴급 관련 라이브 A/V 서비스를 고유하게 식별해 주어야 하는 16-비트 정수.

ServiceName - LiveMedia, 예컨대, "WXYZ Channel 5"에 튜닝하는 옵션을 제시할 때 수신기가 시청자에게 제시할 수 있는 LiveMedia가 이용가능한 서비스에 대한 사용자에게 친숙한 이름.

ServiceName@lang - 라이브 미디어 스트림의 각자의 ServiceName 엘리먼트의 언어를 식별해 주어야 한다. 이 속성은 공식적인 자연 언어 식별자들에 의해 표현되어야 하며, 일 예에서, BCP 47에 의해 정의된 바와 같이, 35개의 문자를 초과하지 않아야 한다. 일 예에서, 암시적 디폴트 값이 없어야 한다.

일부 예들에서, 엘리먼트들 및 속성들 AEA@AEAid, AEA@refAEAid, Location, Location@type, AEAtext, Media, Media@mediDesc, 및 Media@contentType은 이하의 시맨틱스에 기초할 수 있다:

AEA@AEAid - 이 엘리먼트는 스테이션(송신기)에 의해 배정된, AEA 메시지를 고유하게 식별해주는 스트링 값이어야 한다. @AEAid는 공백들, 쉼표들 또는 제한된 문자들(< 및 &)을 포함하지 않아야 한다. 이 엘리먼트는 업데이트들을 이 경보에 연관시키는 데 사용된다. 일 예에서, 이 스트링은 32개의 문자를 초과하지 않아야 한다.

AEA@refAEAid - 참조된 AEA 메시지의 AEAid를 식별해주어야 하는 스트링. 이는 @AEAtype이 "update" 또는 "cancel"일 때 나타나야 한다. 일 예에서, 이 스트링은 256개의 문자를 초과하지 않아야 한다.

Location - 지리적 기반 코드로 메시지 타깃을 설명해야 하는 스트링. 일 예에서, AEA 내의 AEA.Header.Location 엘리먼트의 출현 횟수는 8을 초과하지 않아야 한다.

@type="FIPS"인 경우, Location은 쉼표들에 의해 분리된 하나 이상의 숫자 스트링의 그룹으로 정의되어야 하며, 일 예에서, 246개의 문자를 초과하지 않아야 한다. 각각의 6-자리 숫자 스트링은 47CFR11.31에서 PSSCCC로서 정의된 방식으로 FIPS [NIST: "Federal Information Processing Standard Geographic Codes," 47 C.F.R. 11.31(f), National Institute of Standards and Technology, Gaithersburg, MD, 22 October 2015.]에 정의된 바와 같이 카운티 하위구분(county subdivision), 주(state) 및 카운티(county) 코드들의 연결(concatenation)이어야 한다. 부가적으로, 코드 "000000"은 미국 및 그 영토 내의 모든 위치들로서 해석되어야 한다.

@type="SGC"인 경우, Location은 쉼표들에 의해 분리된 하나 이상의 숫자 스트링의 그룹으로 정의되어야 하며, 일 예에서, 252개의 문자를 초과하지 않아야 한다. 각각의 숫자 스트링은 SGC에 정의된 바와 같은 2-자리 PR(province), 2-자리 CD(census division) 및 3-자리 CSD(census subdivision)의 연결이어야 한다.

@type="polygon"인 경우, Location은 닫힌, 비-자기 교차 루프를 형성하는 3개 이상의 GPS 좌표 쌍의 연결 시퀀스로 이루어진 지리공간 공간 지역을 정의해야 한다. 각각의 좌표 쌍은 십진수도(decimal degrees)로 표현되어야 한다.

@type="circle"인 경우, Location은 좌표 쌍으로서 주어지는 중심 지점 및 그에 뒤이은 공백 문자 및 킬로미터 단위의 반경 값에 의해 표현되는 원형 지역을 정의해야 한다.

@type의 텍스트 값들은 대소문자 구분이며, "polygon" 및 "circle"을 제외하고는, 모두 대문자들로 표현되어야 한다.

AEAtext - 긴급 메시지의 평문의 스트링. 각각의 AEAtext 엘리먼트는 정확히 하나의 @lang 속성을 포함해야 한다. 다수의 언어들로 된 동일한 경보의 AEAtext의 경우, 이 엘리먼트는 다수의 AEAtext 엘리먼트들의 존재를 요구해야 한다. 일 예에서, 이 스트링은 256개의 문자를 초과하지 않아야 하며, 그리고/또는 AEA 내의 AEA.AEAtext 엘리먼트의 출현 횟수는 8을 초과하지 않아야 한다.

Media - 리소스의 언어(@lang), 디스크립션(@mediaDesc) 및 위치(@url)를 포함한, 멀티미디어 리소스의 컴포넌트 부분들을 포함해야 한다. AEAtext에 관련된 보충 정보를 갖는 부가 파일; 예컨대, 이미지 또는 오디오 파일을 참조한다. AEA 메시지 블록 내에 다수의 인스턴스들이 출현할 수 있다. 일 예에서, AEA 내의 AEA.Media 엘리먼트의 출현 횟수는 8을 초과하지 않아야 한다.

Media@mediaDesc - 미디어 리소스의 콘텐츠를, 평문으로, 설명해야 하는 스트링. 일 예에서, 이 스트링은 64개의 문자를 초과하지 않아야 한다. 디스크립션은 미디어 정보를 표시해야 한다. 예를 들어, "대피 지도" 또는 "도플러 레이더 이미지" 등. Media@mediaDesc의 언어는 Media@lang에 표시된 언어와 동일한 것으로 추론되어야 한다.

Media@contentType - Media@url에 의해 참조되는 미디어 콘텐츠의 MIME 타입을 표현해야 하는 스트링. Media@contentType은 HTTP/1.1 프로토콜 RFC 7231의 Content-Type 헤더의 시맨틱스를 준수해야 한다. 일 예에서, 이 스트링은 15개의 문자를 초과하지 않아야 한다.

이러한 방식으로, 일부 예들에서, AEA 메시지의 크기는 보다 효율적인 수신자 디바이스로의 시그널링 및 수신 디바이스에 의한 파싱을 제공하도록 제약될 수 있다.

일 예에서, 표 2, 표 10A, 및 표 10B에서의 Header의 시맨틱스는 표 10C에 제공된 시맨틱스에 기초할 수 있다.

[표 10C]

표 10C에서, Header, Header@effective, 및 Header@expires는 표 2와 관련하여 앞서 제공된 정의들에 기초할 수 있다. Header@allLocation은 이하의 정의에 기초할 수 있다:

Header@allLocation - 이 불 속성(boolean attribute)이 TRUE일 때, 이는 이 AEA 메시지가 이 ATSC 방출 신호(emission signal)의 방송 지역(broadcast area) 내의 모든 위치들을 목표로 하고 있다는 것을 표시한다. 이 불 속성이 FALSE일 때, 이는 이 AEA 메시지가 목표로 하는 위치들이 Header.Location 엘리먼트(들)에 의해 표시된 것과 같아야 한다는 것을 표시한다. 존재하지 않을 때, Header@allLocation은 FALSE인 것으로 추론되어야 한다. Header@allLocation 속성이 FALSE일 때, 적어도 하나의 Header.Location 엘리먼트가 AEA 메시지 Header에 존재해야 한다.

Header의 시맨틱스가 Header@allLocation을 포함할 때, Header.Location의 카디널리티가 0..N인 점에 유의해야 한다. 이것은 Location 엘리먼트가 임의로 AEA 메시지의 인스턴스들에 존재할 수 있다는 것을 의미한다. Header@allLocation이 TRUE로 설정될 때는, 수신자 디바이스가 메시지가 방송 영역 내의 모든 수신자들에 대해 의도되어 있다고 결정할 수 있고, Header@allLocation이 FALSE로 설정될 때는, 수신자 디바이스가 메시지가, 예를 들어, Header.Location 엘리먼트가 AEA 메시지에 존재하지 않는 것으로 인해, 부가의 위치 정보가 수신되지 않으면 메시지가 불완전하다고(또는 에러가 있다고) 결정할 수 있다는 점에 유의해야 한다.

다른 예에서, Header@allLocation의 정의는 Header@allLocation이 존재하지 않을 때 Header@allLocation이 TRUE인 것으로 추론되어야 한다고 규정할 수 있다. 일 예에서, Header@allLocation이 TRUE일 때, 전송 및 네트워크 패킷 생성기(304)는 AEA 메시지의 인스턴스에 Header.Location을 포함시키지 않도록 구성될 수 있다. 일 예에서, Header@allLocation이 TRUE일 때, 전송 및 네트워크 패킷 생성기(304)는 AEA 메시지의 인스턴스에 Header.Location을 임의로 포함시키도록 구성될 수 있다. 일 예에서, Header@allLocation이 TRUE이고 Header.Location이 AEA 메시지의 인스턴스에 포함될 때, 수신자 디바이스는 Header.Location을 무시하도록 구성될 수 있다. 다른 예들에서, allLocation에 대한 XML 속성을 사용하는 대신에, allLocation 내의 정보가 XML 엘리먼트로서, 예컨대, Header.AllLocation 엘리먼트로서 전달될 수 있다는 점에 유의해야 한다.

게다가, 일 예에서, 표 2, 표 10A, 및 표 10B에서의 Media의 시맨틱스는 표 10D에 제공된 시맨틱스에 기초할 수 있다.

[표 10D]

표 10D에서, 일 예에서, Media, Media@lang, Media@mediaDesc, Media@url Media@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에서 아이템에 대한 일반 텍스트(generic text)를 제시할 수 있다(예컨대, @contentType이 아이템이 비디오라고 표시하는 경우, 수신기는 UI 리스트에서 아이템을 "비디오"라고 설명할 수 있다).

Media@mediaType - 이 스트링은 관련 미디어의 의도된 용도를 식별해 주어야 한다. 이 속성으로 식별된 미디어 아이템들이 전형적으로, 선택을 위해 리스트에서 사용자에게 제시되는 미디어가 아니라, 수신기의 경보 사용자 인터페이스에 의해 자동으로 핸들링되는 아이템들과 연관된다는 점에 유의한다. 일 예에서, 값은 표 10E에 따라 코딩되어야 한다.

[표 10E]

Media@url - 멀티미디어 리소스 파일들 또는 패키지들의 소스를 결정해야 하는 요구된 속성. 리치 미디어 리소스가 광대역을 통해 전달될 때, 이 속성은 절대 URL(absolute URL)로서 형성되고 원격 서버 상의 파일을 참조해야 한다. 리치 미디어 리소스가 방송 ROUTE를 통해 전달될 때, 이 속성은 상대 URL(relative URL)로서 형성되어야 한다. 상대 URL은 파일, 또는 파일의 Entity 헤더를 전달하는 LCT [IETF: RFC 5651, "Layered Coding Transport (LCT) Building Block," Internet Engineering Task Force, Reston, VA, October, 2009] 채널에서의 EFDT 내의 대응하는 File 엘리먼트의 Content-Location 속성과 매칭해야 한다.

Media@mediaAssoc - 이 미디어 리소스와 연관된 다른 리치 미디어 리소스의 Media@url을 포함하는 임의적 속성. 예는 비디오와 연관된 클로즈드 캡션 트랙(closed caption track)을 포함한다. Media@mediaAssoc의 구성은 앞서 Media@url에 설명된 바와 같아야 한다.

Media@order - 미디어 리소스 파일들의 선호된 제시 순서를 표시해야 하는 임의적 속성. 동일한 순서 번호를 가지며 Media@mediaAssoc 속성에 의해 표시된 바와 같이 서로 연관된 미디어 리소스 파일들은, 존재하는 경우, 순서 번호에서 1을 뺀 것을 갖는 모든 미디어 리소스 파일들이 제시된 후에 함께 제시되어야 한다.

Media@duration - 미디어 리소스 파일의 지속기간을 표현해야 하는 임의적 속성.

앞서 제공된 시맨틱스과 관련하여, 임의로 시그널링된 Media@order 및 Media@duration에 대한 값들을 제공하는 것은 미디어가 효율적인 방식으로 검색 및/또는 제시될 수 있게 해줄 수 있다. 예를 들어, 수신자 디바이스는 순서 및 지속기간 값들에 기초하여 미디어 리소스들을 다운로드할 수 있다. 예를 들어, 수신자 디바이스는 비교적 긴 지속기간을 갖는 미디어 리소스를 다운로드하지 않기로 결정할 수 있다.

다른 예에서, @mediaAssoc 속성은 대안적으로 MediaAssoc 엘리먼트로서 시그널링될 수 있다. 이러한 이유는 @mediaAssoc 속성이 다른 미디어가 존재하거나 부재하는 것으로 인해 현재의 미디어와 최대 하나의 다른 미디어와의 연관만을 표시할 수 있기 때문이다. 특정 상황들에서, 하나의 미디어 엘리먼트가 하나 초과의 다른 미디어 엘리먼트와 연관될 필요가 있을 수 있다. 이것은 표 10F에 보여진 바와 같이 0..N의 카디널리티를 갖는 MediaAssoc 엘리먼트를 사용하여 달성될 수 있다.

[표 10F]

이 경우에, MediaAssoc 엘리먼트의 시맨틱스는 다음과 같을 수 있다:

Media.MediaAssoc - 이 미디어 리소스와 연관된 다른 리치 미디어 리소스의 Media@url을 포함하는 임의적 엘리먼트. 예는 비디오와 연관된 클로즈드 캡션 트랙을 포함한다. Media@mediaAssoc의 구성은 앞서 Media@url에 설명된 바와 같아야 한다. 다수의 MediaAssoc 엘리먼트의 존재가 지원되며 다수의 미디어 리소스들과의 연관을 표시한다.

ATSC 3.0 서비스는 하나 초과의 RF 채널에서 전달되는 컴포넌트들을 가질 수 있다. 그러한 서비스의 컴포넌트 세트는, 그 세트가 서비스의 모든 컴포넌트들로 이루어지지 않고 하나 초과의 그러한 컴포넌트 세트가 서비스를 구성할 때, 서비스의 일 부분(portion)이라고 불린다. 다른 한편으로, 서비스의 컴포넌트 세트는, 그 세트가 서비스의 모든 컴포넌트들로 이루어지고 하나 초과의 그러한 컴포넌트 세트가 전달될 때, 서비스의 중복(duplicate)이라고 불린다. 부분들에 의해 표현된 각각의 서비스는 (비록 다른 부분들을 사용하는 것이 또한 보다 매력적인 프레젠테이션을 제공할 수 있지만) 다른 부분들, 즉 비-필수(non-essential) 부분들을 사용하지 않고 서비스의 의미있는 프레젠테이션을 위해 충분한 하나의 필수(essential) 부분만을 가져야 한다.

일 예에서, AEA의 시맨틱스는 표 10G에 제공된 시맨틱스에 기초할 수 있다.

[표 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), 도트(dot)(0x002E), 및 밑줄(0x005F) 문자들의 UTF-8/유니코드 문자 세트를 사용하는 62개의 영숫자 문자(기본 라틴 문자 및 아라비아 숫자)로 제한되어야 한다. 이 엘리먼트는 업데이트들을 이 경보에 연관시키는 데 사용된다.

AEA@issuer - 메시지를 발신하거나 포워딩하는 방송국을 식별해주어야 하는 스트링. @issuer는 호출 부호(call letters), 스테이션 ID, 그룹 이름, 또는 다른 식별 값과 같은, 영숫자 값을 포함해야 한다. 이 스트링은 32개의 문자를 초과하지 않아야 한다.

표 10G에 예시된 예에서, 엘리먼트 AEA는 속성 AEA@wakeup을 포함한다. 일 예에서, AEA@wakeup은 이하의 정의에 기초할 수 있다:

AEA@wakeup - 이 임의적 불 속성은, 존재하고 "true"로 설정될 때, AEA가 비-제로(non-zero) ea_wake_up 비트들과 연관된다는 것을 표시해야 한다. 디폴트 값은, 존재하지 않을 때, "false"이어야 한다.

ea_wake_up 비트들이 A/331의 부록 G에 설명되어 있다는 점에 유의해야 한다. A/331의 부록 G에 제공된 바와 같이, 수신자 디바이스가 대기 모드(standby mode)에 있는 동안 수신자 디바이스가 웨이크 업 비트들(wake-up bits)을 검출하는 것이 가능한 방식으로 2개의 웨이크 업 비트가 물리 계층에서 전달된다. 2개의 웨이크 업 비트는 수신자 디바이스가 긴급 정보가 이용가능하다는 것을 검출하고 웨이크 업 버전(wake-up version)을 검출할 수 있게 해준다. 표 10H는 2개의 웨이크 업 비트의 연결의 의미를 요약한다.

[표 10H]

웨이크 업 비트 값들이 0으로부터 1로 변할 때, 이것은 긴급에 대한 웨이크 업 호출(wake-up call)을 표시한다는 점에 유의해야 한다. 수치 설정 숫자(numerical setting number)가 1로부터 2로, 2로부터 3으로, 3으로부터 1로, 기타 등등으로 증가할 때, 이것은 새로운 웨이크 업 호출을 표시한다. 비트들의 값이 0으로 되돌아올 때, 이는 긴급 웨이크 업이 더 이상 시그널링되지 않는다는 것을 의미한다.

앞서 설명된 바와 같이, 서비스 배포 엔진은 본딩된 채널(예컨대, 2개의 개별 6 MHz 채널)을 사용하여 전송될 수 있는 신호를 출력하도록 구성될 수 있다. 본딩된 채널을 형성하는 채널들 각각은 구별되는 방송 스트림과 연관될 수 있고 구별되는 bsid를 가질 수 있다. 일 예에서, LiveMedia의 시맨틱스는 표 10I에 제공된 시맨틱스에 기초할 수 있다.

[표 10I]

표 10I에 예시된 예에서, LiveMedia@serviceId, ServiceName, 및 ServiceName@lang 각각은 앞서 제공된 정의들에 기초할 수 있다. 일부 예들에서, LiveMedia 및 LiveMedia@bsid는 이하의 예시적인 정의들에 기초할 수 있다:

LiveMedia - 긴급 관련 정보, 예컨대, 진행 중인 뉴스 보도를 위해 튜닝할 선택사항으로서 사용자에게 제시될 수 있는 A/V 서비스의 ID(Identification). AEA@wakeup이 "true"인 경우 LiveMedia 엘리먼트가 존재해야 한다. LiveMedia가 존재하지 않을 때, 디폴트 값이 없다.

LiveMedia@bsid - unsigned short 16-비트 정수 값들의 이 리스트는 긴급 관련 라이브 A/V 서비스의 필수 부분을 포함하는 방송 스트림(들)의 식별자(들)를 표시해야 한다. LiveMedia@bsid의 값이 하나 초과의 unsigned short 값의 리스트일 때, 이는 채널 본딩(channel bonding)이 적용된 다수의 방송 스트림들을 표시해야 한다.

일 예에서, LiveMedia@bsid는 이하의 예시적인 정의에 기초할 수 있다:

LiveMedia@bsid - 이 unsigned short 16-비트 정수 값들은 긴급 관련 라이브 A/V 서비스의 필수 부분을 포함하는 방송 스트림(들)의 식별자(들)를 표시해야 한다.

이 경우에, LiveMedia@bsid의 데이터 타입은 이하에서 표 10Ia에 보여지는 바와 같이 unsignedShort이어야 한다.

[표 10Ia]

표 10I에서, 데이터 타입 string listOfunsignedShort가 W3C(World Wide Web Consortium)에 의해 유지되는 XSD(XML Schema Definition) 권고들에서 제공된 정의들에 대응할 수 있다는 점에 유의해야 한다. 일 예에서, 이들은 ["XML Schema Part 2: Datatypes Second Edition]에 설명된 정의들에 대응할 수 있다. 게다가, 표 10I에 제공된 예에 기초한 컴퓨터 프로그램 리스팅이 표 10J에 예시된 예시적인 XML 스키마에 기초하여 LiveMedia@bsid를 표현할 수 있다는 점에 유의해야 한다. 표 10J에 예시된 예시적인 XML 스키마가 앞서 설명된 AEAT의 엘리먼트들 및 속성들을 포함한 XML 스키마에 포함될 수 있고 간략함을 위해, AEAT에 대한 완전한 XML 스키마는 표 10J에서 제공되지 않는다는 점에 유의해야 한다.

[표 10J]

이러한 방식으로, 표 10I 또는 표 10Ia와 관련하여 제공된 예시적인 구조에 기초한 AEA 메시지는 서비스가 본딩된 채널들을 사용하여 전송될 때 수신자 디바이스가 긴급 관련 정보에 대한 A/V 서비스에 튜닝할 수 있게 해줄 수 있다.

앞서 설명된 바와 같이, 워터마크는 긴급 경보 메시지, 예컨대, 표 6에서 제공된 바와 같은 advanced_emergency_alert_message()를 시그널링하는 데 사용될 수 있다. 서비스 배포 엔진(300)은 표 11에 제공된 바와 같은 예시적인 advanced_emergency_alert_message()에 기초하여 긴급 경보 메시지에 대한 신호를 생성하도록 구성될 수 있다.

[표 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 메시지 내의 location 필드의 수를 제공한다.

표 11에 예시된 바와 같이, advanced_emergency_alert_message()는 num_AEA_text_minus1 및 num_location_minus1의 각자의 2-비트 값들이 0 내지 3의 범위에 있는 것에 기초하여 최대 4개의 AEA 텍스트 스트링 및 최대 4개의 AEA 위치 스트링을 시그널링할 수 있다. 일 예에서, 표 11이 24-비트 AEA_text_lang_code를 포함할 수 있다는 점에 유의해야 한다. 24-비트 AEA_text_lang_code는 이하의 정의에 기초할 수 있다:

AEA_text_lang_code - AEA_text 필드의 언어를 표현해야 하고 ISO 639.2/B에 따라 3-문자 언어 코드로서 인코딩되어야 하는 24-비트 부호없는 정수 필드. 각각의 문자는 ISO 8859-1(ISO Latin-1)에 따라 8 비트로 인코딩되고 이 필드에 순서대로 삽입되어야 한다.

상기 AEA_text_lang_code의 정의에서, ISO 639.2/B는 [ISO 639-2:1998, Codes for the representation of names of languages - Part 2: Alpha-3 code]에 설명되어 있고 ISO 8859-1(ISO Latin-1)은 [ISO/IEC 8859-1:1998, Information technology - 8-bit single-byte coded graphic character sets - Part 1: Latin alphabet No. 1]에 설명되어 있으며, 이들 각각은 그 전체가 참고로 포함된다.

일 예에서, 서비스 배포 엔진(300)은 표 12에 제공된 바와 같은 예시적인 advanced_emergency_alert_message()에 기초하여 긴급 경보 메시지를 시그널링하도록 구성될 수 있다.

[표 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_minus1; media_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에 의해 지정된 등록 기관(registration authority)에 의해 배정되어야 한다.

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이 프래그먼트 단위로(in fragments) 송신된 경우 재조립(reassembly) 후에, RFC 3986에 따른 path, query, 및 fragment의 URI 신택스 컴포넌트들만을 포함해야 한다. media_url_string은 다음과 같이 HTTPS 요청을 구성하는 데 사용되어야 한다:

https://{BSID_code}.{url_construction}.vp1.tv/AEA/media_url_string() 여기서

{BSID_code}는 16-비트 bsid의 4-문자 16 진수 표현이다.

{url_construction}은 16-비트 url_construction_code의 4-문자 16 진수 표현이다.

상기 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 값에 적용되는 지수 인자(exponent factor)를 표시한다. 값은 표 13에 따라 코딩되어야 한다.

[표 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은 이하의 정의들에 기초할 수 있다.

이 경우에, media_present_flag 이후의 예약된 값은 3-비트일 수 있고 일 예에서 '111'일 수 있다.

게다가, 일 예에서, 표 12에서 AEA 메시지 내의 media 필드는 표 14A에 제공된 바와 같이 포맷팅될 수 있다.

[표 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 - 이 스트링은 적어도 최상위 레벨 도메인(top-level domain)과 두 번째 레벨 도메인으로 이루어진, IANA에 등록된 도메인 이름(IANA-registered domain name)이어야 한다. 상위 레벨 도메인들이 존재할 수 있다. 마침표 문자들(".")이 최상위 레벨, 두 번째 레벨, 및 임의의 상위 도메인들 사이에 포함되어야 한다. 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을 추가(appending)하는 것에 의해 형성되어야 한다. media_url_string()은, 프래그먼트 단위로 송신된 경우 재조립 후에, RFC 3986에 따른 유효한 URL이어야 하고 RFC 3986에 따른 path, query, 및 fragment의 URI 신택스 컴포넌트들만을 포함해야 한다. media_url_string()은 다음과 같이 HTTPS 요청을 구성하는 데 사용되어야 한다:

https://entity_string.2.vp1.tv/media_url_string

이러한 방식으로, 서비스 배포 엔진(300)은 긴급 경보 메시지와 연관된 미디어 리소스의 크기에 적용되는 지수 인자를 표시하는 신택스 엘리먼트를 시그널링하고 미디어 리소스의 크기를 표시하는 신택스 엘리먼트를 시그널링하도록 구성될 수 있다.

일 예에서, 서비스 배포 엔진(300)은 표 14B에 제공된 바와 같은 예시적인 advanced_emergency_alert_message()에 기초하여 긴급 경보 메시지를 시그널링하도록 구성될 수 있다.

[표 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[유니 코드 변환 포맷 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 - 이 8-비트 부호없는 정수는 표 15에 따라 URL 구성에 사용될 도메인을 식별해주어야 하는 식별자 코드를 표시해야 한다.

[표 15]

entity_string() - 이 스트링은 RFC 3986 URL의 일 부분이어야 하며, 이 advanced_emergency_alert_message_message()에 의해 전달되는 URL이 RFC 3986과 부합하도록, (RFC 3986 Sec 2.3에 정의된 바와 같은) 예약되지 않은 문자들만으로 이루어져야 한다. entity_string()의 길이는 entity_strlen_minus1의 값에 1을 더한 것에 의해 주어져야 한다.

media_url_string - 이 스트링은, 전달된 URL이 RFC 3986과 부합하도록, RFC 3986 URL의 일 부분이어야 한다. 스트링의 길이는 media_uri_string_length_minus1의 값에 1을 더한 것에 의해 주어져야 한다. URL은 "https://", 그에 뒤이은 entity_string(), 그에 뒤이은 "."(마침표), 그에 뒤이은 domain_string(), 그에 뒤이은 "/"(포워드 슬래시(forward slash)), 그리고 그에 뒤이은 media_url_string()의 연결이어야 한다. 이 URL은, 프래그먼트 단위로 송신되는 경우 재조립 후에, RFC 3986에 따른 유효한 URL이어야 한다. 그에 따라, URL은 다음과 같이 조립된다:

https://entity_string().domain_string()/media_url_string()

mediaType_code - 이 3-비트 부호없는 정수는 표 16에 따라, [A/331]에 정의된 현재의 진보된 긴급 경보 메시지의 AEAT.AEA.Header.Media@mediaType 문자 스트링을 표시해야 한다.

[표 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()에 기초하여 긴급 경보 메시지를 시그널링하도록 구성될 수 있다.

[표 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 - 이 스트링은, 전달된 URL이 RFC 3986과 부합하도록, RFC 3986 [REF] URL의 일 부분이어야 한다. 스트링의 길이는 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()

수신기는 [A/331]에 정의된 바와 같이 XML-포맷의(XML-formatted) AEAT를 다운로드하기 위해 상기 https 호출(https call)을 서버에 대해 사용할 수 있다.

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)은 유니버설 리소스 로케이터(universal resource locator) 구성을 위해 사용될 도메인을 식별해주는 식별자 코드를 표시하는 신택스 엘리먼트를 시그널링하고, 유니버설 리소스 로케이터 프래그먼트의 스트링을 제공하는 신택스 엘리먼트를 시그널링하도록 구성될 수 있다. 이러한 방식으로, 서비스 배포 엔진(300)은 긴급 경보 메시지의 언어가 2-문자 스트링 또는 5-문자 스트링에 의해 표현되는지를 표시하는 신택스 엘리먼트를 시그널링하고, 긴급 경보 메시지의 언어를 표시하는 스트링을 제공하는 신택스 엘리먼트를 시그널링하도록 구성될 수 있다.

도 4는 본 개시내용의 하나 이상의 기법을 구현할 수 있는 수신자 디바이스의 일 예를 예시하는 블록 다이어그램이다. 즉, 수신자 디바이스(400)는 앞서 설명된 표들 중 하나 이상과 관련하여 앞서 설명된 시맨틱스에 기초하여 신호를 파싱하도록 구성될 수 있다. 일 예에서, 수신자 디바이스(400)는 앞서 설명된 예시적인 시맨틱스의 임의의 조합에 기초한 긴급 경보 메시지를 수신하고, 그것을 파싱하며, 이어서 액션을 취하도록 구성될 수 있다. 게다가, 수신자 디바이스(400)는 긴급 경보 메시지와 연관된 미디어 콘텐츠가 검색될 수 있게 해주도록 구성될 수 있다. 예를 들어, 수신자 디바이스는 긴급 경보 메시지와 연관된 미디어 콘텐츠가 이용가능하다는 것을 사용자가 인식할 가능성을 증가시키기 위해 (예컨대, 하나 이상의 서비스에 대한 특정된 지속기간 동안) 애플리케이션들을 일시적으로 중지시키고 그리고/또는 멀티미디어 프레젠테이션이 어떻게 렌더링되는지를 변경하도록 구성될 수 있다. 게다가, 일 예에서, 수신자 디바이스(400)는 사용자가 긴급 경보 메시지와 연관된 미디어 콘텐츠가 수신자 디바이스(400)에 의해 어떻게 핸들링되는지를 설정할 수 있게 해도록 구성될 수 있다. 예를 들어, 사용자는 설정 메뉴에서 이하의 기본설정들(preferences) 중 하나를 설정할 수 있다: 검색될 미디어의 타입들에 대한 기본설정, 선택적으로 검색될 특정 타입의 미디어에 대한 기본설정, 및 결코 검색되지 않을 특정 타입의 미디어에 대한 기본설정.

수신자 디바이스(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(application specific integrated circuit), FPGA(field programmable gate array), 이산 로직, 소프트웨어, 하드웨어, 펌웨어 또는 이들의 임의의 조합들과 같은, 다양한 적당한 회로부 중 임의의 것으로 구현될 수 있다. 비록 수신자 디바이스(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)의 컴포넌트들 내에 구현되거나 포함될 수 있고, 이들에 의해 동작가능할 수 있으며, 이들에 의해 실행될 수 있고, 그리고/또는 이들에 동작가능하게 그리고/또는 통신가능하게 커플링될 수 있다. 애플리케이션들(408)은 수신자 디바이스(400)의 CPU(들)(402)로 하여금 특정 기능들을 수행하게 할 수 있는 명령어들을 포함할 수 있다. 애플리케이션들(408)은, for-루프들, while-루프들, if-명령문들(statements), do-루프들 등과 같은, 컴퓨터 프로그래밍 명령문들로 표현되는 알고리즘들을 포함할 수 있다. 애플리케이션들(408)은 특정된 프로그래밍 언어를 사용하여 개발될 수 있다. 프로그래밍 언어들의 예들은 Java^TM, Jini^TM, 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)는 데이터가 하나의 피어 디바이스(peer device)로부터 다른 피어 디바이스로 또는 스토리지 매체로 전송될 수 있게 해주는 구조들을 포함한다. 예를 들어, 시스템 인터페이스(410)는 AGP(Accelerated Graphics Port) 기반 프로토콜들, PCI SIG(Peripheral Component Interconnect Special Interest Group)에 의해 유지되는, 예를 들어, PCI Express^TM (PCIe) 버스 규격과 같은, PCI(Peripheral Component Interconnect) 버스 기반 프로토콜들, 또는 피어 디바이스들을 상호접속시키는 데 사용될 수 있는 임의의 다른 형태의 구조(예컨대, 독점적 버스 프로토콜들)를 지원하는 칩셋을 포함할 수 있다.

앞서 설명된 바와 같이, 수신자 디바이스(400)는 텔레비전 서비스 네트워크를 통해 데이터를 수신하고, 임의로, 데이터를 송신하도록 구성된다. 앞서 기술된 바와 같이, 텔레비전 서비스 네트워크는 원격통신 표준에 따라 동작할 수 있다. 원격통신 표준은, 예를 들어, 물리적 시그널링, 어드레싱, 채널 액세스 제어, 패킷 특성들, 및 데이터 프로세싱과 같은, 통신 특성들(예컨대, 프로토콜 계층들)을 정의할 수 있다. 도 4에 예시된 예에서, 데이터 추출기(412)는 신호로부터 비디오, 오디오, 및 데이터를 추출하도록 구성될 수 있다. 신호는, 예를 들어, DVB 표준들, ATSC 표준들, ISDB 표준들, DTMB 표준들, DMB 표준들, 및 DOCSIS 표준들의 양태들에 따라 정의될 수 있다. 데이터 추출기(412)는 앞서 설명된 서비스 배포 엔진(300)에 의해 생성된 신호로부터 비디오, 오디오, 및 데이터를 추출하도록 구성될 수 있다. 즉, 데이터 추출기(412)는 서비스 배포 엔진(300)에 서비스하기 위해 상호 방식으로(in a reciprocal manner) 동작할 수 있다.

데이터 패킷들은 CPU(들)(402), 오디오 디코더(414), 및 비디오 디코더(418)에 의해 프로세싱될 수 있다. 오디오 디코더(414)는 오디오 패킷들을 수신하고 프로세싱하도록 구성될 수 있다. 예를 들어, 오디오 디코더(414)는 오디오 코덱의 양태들을 구현하도록 구성된 하드웨어 및 소프트웨어의 조합을 포함할 수 있다. 즉, 오디오 디코더(414)는 오디오 패킷들을 수신하고 오디오 데이터를 렌더링을 위해 오디오 출력 시스템(416)에 제공하도록 구성될 수 있다. 오디오 데이터는 Dolby 및 Digital Theater Systems에 의해 개발된 것들과 같은 다중 채널 포맷들을 사용하여 코딩될 수 있다. 오디오 데이터는 오디오 압축 포맷을 사용하여 코딩될 수 있다. 오디오 압축 포맷들의 예들은 MPEG(Motion Picture Experts Group) 포맷들, AAC(Advanced Audio Coding) 포맷들, DTS-HD 포맷들, 및 Dolby Digital(AC-3, AC-4 등) 포맷들을 포함한다. 오디오 출력 시스템(416)은 오디오 데이터를 렌더링하도록 구성될 수 있다. 예를 들어, 오디오 출력 시스템(416)은 오디오 프로세서, 디지털-아날로그 변환기, 증폭기, 및 스피커 시스템을 포함할 수 있다. 스피커 시스템은, 헤드폰, 통합 스테레오 스피커 시스템(integrated stereo speaker system), 멀티 스피커 시스템, 또는 서라운드 사운드 시스템과 같은, 다양한 스피커 시스템들 중 임의의 것을 포함할 수 있다.

비디오 디코더(418)는 비디오 패킷들을 수신하고 프로세싱하도록 구성될 수 있다. 예를 들어, 비디오 디코더(418)는 비디오 코덱의 양태들을 구현하는 데 사용되는 하드웨어 및 소프트웨어의 조합을 포함할 수 있다. 일 예에서, 비디오 디코더(418)는 ITU-T H.262 또는 ISO/IEC MPEG-2 Visual, ISO/IEC MPEG-4 Visual, ITU-T H.264 (ISO/IEC MPEG-4 AVC(Advanced video Coding)라고도 알려져 있음), 및 HEVC(High-Efficiency Video Coding)와 같은 임의의 수의 비디오 압축 표준들에 따라 인코딩된 비디오 데이터를 디코딩하도록 구성될 수 있다. 디스플레이 시스템(420)은 비디오 데이터를 검색하고 이를 디스플레이하기 위해 프로세싱하도록 구성될 수 있다. 예를 들어, 디스플레이 시스템(420)은 비디오 디코더(418)로부터 픽셀 데이터를 수신하고 시각적 프레젠테이션을 위해 데이터를 출력할 수 있다. 게다가, 디스플레이 시스템(420)은 그래픽스를 비디오 데이터와 함께, 예컨대, 그래픽 사용자 인터페이스들을 출력하도록 구성될 수 있다. 디스플레이 시스템(420)은 LCD(liquid crystal display), 플라스마 디스플레이, OLED(organic light emitting diode) 디스플레이, 또는 비디오 데이터를 사용자에게 제시할 수 있는 다른 타입의 디스플레이 디바이스와 같은 다양한 디스플레이 디바이스들 중 하나를 포함할 수 있다. 디스플레이 디바이스는 표준 화질(standard definition) 콘텐츠, 고화질 콘텐츠, 또는 초고화질 콘텐츠를 디스플레이하도록 구성될 수 있다.

I/O 디바이스(들)(422)는 수신자 디바이스(400)의 동작 동안 입력을 수신하고 출력을 제공하도록 구성될 수 있다. 즉, I/O 디바이스(들)(422)는 사용자로 하여금 렌더링될 멀티미디어 콘텐츠를 선택할 수 있게 해줄 수 있다. 입력은, 예를 들어, 푸시 버튼 리모콘, 터치 감응 스크린을 포함하는 디바이스, 모션 기반 입력 디바이스, 오디오 기반 입력 디바이스, 또는 사용자 입력을 수신하도록 구성된 임의의 다른 타입의 디바이스와 같은, 입력 디바이스로부터 생성될 수 있다. I/O 디바이스(들)(422)는, 예를 들어, USB(Universal Serial Bus protocol), 블루투스, ZigBee 또는, 예를 들어, 독점적 적외선 통신 프로토콜과 같은, 독점적 통신 프로토콜과 같은, 표준화된 통신 프로토콜을 사용하여 수신자 디바이스(400)에 동작가능하게 커플링될 수 있다.

네트워크 인터페이스(424)는 수신자 디바이스(400)가 로컬 영역 네트워크 및/또는 광역 네트워크를 통해 데이터를 송신 및 수신할 수 있게 해주도록 구성될 수 있다. 네트워크 인터페이스(424)는, 이더넷 카드, 광학 트랜시버, 라디오 주파수 트랜시버, 또는 정보를 송신 및 수신하도록 구성된 임의의 다른 타입의 디바이스와 같은, 네트워크 인터페이스 카드를 포함할 수 있다. 네트워크 인터페이스(424)는 네트워크에서 이용되는 물리 및 MAC(Media Access Control) 계층들에 따른 물리적 시그널링, 어드레싱, 및 채널 액세스 제어를 수행하도록 구성될 수 있다. 수신자 디바이스(400)는 도 3과 관련하여 앞서 설명된 기법들 중 임의의 것에 따라 생성된 신호를 파싱하도록 구성될 수 있다. 게다가, 수신자 디바이스(400)는 하나 이상의 통신 기법에 따라 데이터를 컴패니언 디바이스에게 송신하고 컴패니언 디바이스로부터 데이터를 수신하도록 구성될 수 있다.

도 5는 본 개시내용의 하나 이상의 기법을 구현할 수 있는 컴패니언 디바이스의 일 예를 예시하는 블록 다이어그램이다. 컴패니언 디바이스(500)는 하나 이상의 프로세서 및 복수의 내부 및/또는 외부 스토리지 디바이스들을 포함할 수 있다. 컴패니언 디바이스(500)는 콘텐츠 정보 통신 메시지를 수신하도록 구성된 디바이스의 일 예이다. 컴패니언 디바이스(500)는 콘텐츠 정보 통신 메시지에 포함된 정보를 이용할 수 있는 그 상에서 실행되는 하나 이상의 애플리케이션을 포함할 수 있다. 컴패니언 디바이스(500)는 유선 및/또는 무선 통신을 위한 장비를 갖출 수 있으며, 예를 들어, 데스크톱 또는 랩톱 컴퓨터들, 모바일 디바이스들, 스마트폰들, 셀룰러 전화들, PDA(personal data assistants), 태블릿 디바이스들, 및 개인 게이밍 디바이스들과 같은, 디바이스들을 포함할 수 있다.

도 5에 예시된 바와 같이, 컴패니언 디바이스(500)는 중앙 프로세싱 유닛(들)(502), 시스템 메모리(504), 시스템 인터페이스(510), 스토리지 디바이스(들)(512), I/O 디바이스(들)(514), 및 네트워크 인터페이스(516)를 포함한다. 도 5에 예시된 바와 같이, 시스템 메모리(504)는 운영 체제(506) 및 애플리케이션들(508)을 포함한다. 비록 예시적인 컴패니언 디바이스(500)가 구별되는 기능 블록들을 갖는 것으로 예시되어 있지만, 그러한 예시가 설명 목적들을 위한 것이고 컴패니언 디바이스(500)를 특정의 하드웨어 또는 소프트웨어 아키텍처로 제한하지 않는다는 점에 유의해야 한다. 컴패니언 디바이스(500)의 기능들은 하드웨어, 펌웨어 및/또는 소프트웨어 구현들의 임의의 조합을 이용하여 실현될 수 있다.

중앙 프로세싱 유닛(들)(502), 시스템 메모리(504), 및 시스템 인터페이스(510) 각각은 앞서 설명된 중앙 프로세싱 유닛(들)(502), 시스템 메모리(504), 및 시스템 인터페이스(510)와 유사할 수 있다. 스토리지 디바이스(들)(512)는 시스템 메모리(504)보다 많은 양의 데이터를 저장하도록 구성될 수 있는 컴패니언 디바이스(500)의 메모리를 나타낸다. 예를 들어, 스토리지 디바이스(들)(512)는 사용자의 멀티미디어 컬렉션(multimedia collection)을 저장하도록 구성될 수 있다. 시스템 메모리(504)와 유사하게, 스토리지 디바이스(들)(512)는 하나 이상의 비일시적 또는 유형적 컴퓨터 판독가능 스토리지 매체를 또한 포함할 수 있다. 스토리지 디바이스(들)(512)는 내부 또는 외부 메모리일 수 있고, 일부 예들에서 비휘발성 스토리지 요소들을 포함할 수 있다. 스토리지 디바이스(들)(512)는 메모리 카드들(예컨대, SDSC(Standard-Capacity), SDHC(High-Capacity) 및 SDXC(eXtended-Capacity) 포맷들을 포함한, SD(Secure Digital) 메모리 카드), 외부 하드 디스크 드라이브들, 및/또는 외부 솔리드 스테이트 드라이브를 포함할 수 있다.

I/O 디바이스(들)(514)는 컴퓨팅 디바이스(514)에 대한 입력을 수신하고 출력을 제공하도록 구성될 수 있다. 입력은, 예를 들어, 터치 감응 스크린, 트랙 패드, 트랙 포인트, 마우스, 키보드, 마이크로폰, 비디오 카메라, 또는 입력을 수신하도록 구성된 임의의 다른 타입의 디바이스와 같은, 입력 디바이스로부터 생성될 수 있다. 출력은, 예를 들어, 스피커들 또는 디스플레이 디바이스와 같은, 출력 디바이스들에 제공될 수 있다. 일부 예들에서, I/O 디바이스(들)(514)는 컴패니언 디바이스(500)의 외부에 있을 수 있고, 예를 들어, USB(Universal Serial Bus) 프로토콜과 같은, 표준화된 통신 프로토콜을 사용하여 컴패니언 디바이스(500)에 동작가능하게 커플링될 수 있다.

네트워크 인터페이스(516)는 컴패니언 디바이스(500)가, 수신자 디바이스(400) 및 다른 디바이스들 또는 서버들과 같은, 외부 컴퓨팅 디바이스들과 통신할 수 있게 해주도록 구성될 수 있다. 게다가, 컴패니언 디바이스(500)가 스마트폰을 포함하는 예에서, 네트워크 인터페이스(516)는 컴패니언 디바이스(500)가 셀룰러 네트워크와 통신할 수 있게 해주도록 구성될 수 있다. 네트워크 인터페이스(516)는, 이더넷 카드, 광학 트랜시버, 라디오 주파수 트랜시버, 또는 정보를 송신 및 수신할 수 있는 임의의 다른 타입의 디바이스와 같은, 네트워크 인터페이스 카드를 포함할 수 있다. 네트워크 인터페이스(516)는 예를 들어, GSM(Global System Mobile Communications) 표준, CDMA(code division multiple access) 표준, 3GPP(3rd Generation Partnership Project) 표준, IP(Internet Protocol) 표준, WAP(Wireless Application Protocol) 표준, 블루투스, 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)의 컴포넌트들 내에 구현되거나 포함될 수 있고, 이들에 의해 동작가능할 수 있으며, 이들에 의해 실행될 수 있고, 그리고/또는 이들에 동작가능하게 그리고/또는 통신가능하게 커플링될 수 있다. 애플리케이션들(508)은 컴패니언 디바이스(500)의 중앙 프로세싱 유닛(들)(502)으로 하여금 특정 기능들을 수행하게 할 수 있는 명령어들을 포함할 수 있다. 애플리케이션들(508)은, for-루프들, while-루프들, if-명령문들, do-루프들 등과 같은, 컴퓨터 프로그래밍 명령문들로 표현되는 알고리즘들을 포함할 수 있다. 게다가, 애플리케이션들(508)은 제2 스크린 애플리케이션들을 포함할 수 있다.

앞서 설명된 바와 같이, 수신자 디바이스(400)는 앞서 설명된 예시적인 시맨틱스의 임의의 조합에 기초한 긴급 경보 메시지를 수신하고, 그것을 파싱하며, 이어서 액션을 취하도록 구성될 수 있다. 일 예에서, 수신자 디바이스(400)는 긴급 경보 메시지에 포함된 정보를 컴패니언 디바이스, 예컨대, 컴패니언 디바이스(500)에 통신하도록 구성될 수 있다. 이 예에서, 수신자 디바이스(400)는 "프라이머리 디바이스(primary device)"라고 지칭될 수 있다. 컴패니언 디바이스(500) 및/또는 애플리케이션들(508)은 정보를 수신하며 제2 스크린 애플리케이션에서의 사용을 위해 콘텐츠 정보를 파싱하도록 구성될 수 있다. 일 예에서, 수신자 디바이스(400)는 JSON 기반 스키마에 따라 긴급 경보 메시지에 포함된 정보를 컴패니언 디바이스에 통신하도록 구성될 수 있다. 그 전체가 참고로 포함되는, 문헌 [ATSC Candidate Standard: Companion Device (A/338) Doc. S33-161r1-Companion-Device, approved 2 December 2015, (이하, "A/338")]은 ATSC 3.0 프라이머리 디바이스와 ATSC 3.0 컴패니언 디바이스 사이의 통신을 위해 사용하기 위한 제안된 통신 프로토콜을 설명한다. 표 17A는 JSON 기반 스키마에 따른 AEAT 엘리먼트의 구조를 설명한다. 도 6a 및 도 6b는 표 17A에 제공된 예에 기초한 컴퓨터 프로그램 리스팅이다. 표 17A와 관련하여, 미디어 콘텐츠 타입(즉, MIME-type) 및 미디어 디스크립션이 개별적으로 시그널링된다는 점에 유의해야 한다. 이러한 방식으로, 수신자 디바이스(400)는 컴패니언 디바이스(500)가 미디어 콘텐츠를 검색하도록 표 17A에 제공된 예시적인 스키마에 기초하여 메시지를 컴패니언 디바이스(500)에게 송신하도록 구성될 수 있다. 예를 들어, 사용자는 컴패니언 디바이스를 사용하여 특정 타입의 미디어(예컨대, .pdf 파일)를 검색하기 위한 기본설정을 가질 수 있다.

[표 17A]

표 17A에 포함된 엘리먼트들 및 속성들의 시맨틱스가 일반적으로 표 2, 표 6, 및 표 10A 내지 표 10F와 관련하여 앞서 제공된 것들 그리고 간결함을 위해 이하의 엘리먼트들 및 속성들의 시맨틱스를 제외한 예시적인 공식적 정의들에 대응한다는 점에 유의해야 한다:

Header - 이 오브젝트는 경보의 타입(EventCode), 경보가 유효한 시간(effective), 경보가 만료하는 시간(expires), 및 목표한 경보 지역(targeted alert area)의 위치(Location)를 포함한, 경보에 대한 관련 엔벨로프 정보를 포함해야 한다.

Header.effective -이 date-time은 경보 메시지의 유효 시간을 포함해야 한다. date-time은 JSON "type": "string", 및 "format": "date-time"에 따라 표현되어야 한다.

Header.expires - 이 date-time은 경보 메시지의 만료 시간을 포함해야 한다. date-time은 JSON "type": "string", 및 "format": "date-time"에 따라 표현되어야 한다.

EventCode - 이벤트 코드 값 및 이벤트 타입에 대한 정보를 제공하는 오브젝트.

EventCode.value - 값 자체를 표기하는 (숫자를 표현할 수 있는) 스트링으로 포맷팅된 경보 메시지의 이벤트 타입을 식별해주어야 하는 스트링(예컨대, 미국에서, "EVI"의 값은 대피 경고를 표기하는 데 사용될 것이다). 값들은 국가마다 상이할 수 있으며, 영숫자 코드일 수 있거나, 평문일 수 있다. AEA 메시지당 하나의 EventCode만 존재해야 한다.

EventCode.type - 이 특성(property)은 EventCode의 도메인을 지정해야 하는 국가 지정 스트링 값이어야 한다(예컨대, 미국에서, "SAME"은 FCC Part 11 EAS 코딩을 표기한다). 두문자어들인 type의 값들은 마침표들 없이 모두 대문자들로 표현되어야 한다.

Location - 지리적 위치 값 및 위치의 타입에 관한 정보를 제공하는 오브젝트.

Location.value - 지리적 기반 코드로 메시지 타깃을 설명해야 하는 스트링.

Location.type -이 특성은 Location 코드의 도메인을 식별해주는 스트링이어야 한다.

AEAtext - 진보된 긴급 경보 메시지 텍스트 값 및 텍스트의 언어에 관한 정보를 제공하는 오브젝트.

AEAtext.value - 긴급 메시지의 평문의 스트링. 각각의 AEAtext 엘리먼트는 정확히 하나의 lang 속성을 포함해야 한다. 다수의 언어들로 된 동일한 경보의 AEAtext의 경우, 이 엘리먼트는 다수의 AEAtext 엘리먼트들의 존재를 요구해야 한다.

일 예에서, 수신자 디바이스(400)는 표 17B에 예시된 구조에 기초한 JSON 기반 스키마에 따라 긴급 경보 메시지에 포함된 정보를 컴패니언 디바이스에 통신하도록 구성될 수 있다. 도 7a 및 도 7b는 표 17B에 제공된 예에 기초한 컴퓨터 프로그램 리스팅이다.

[표 17B]

표 17B에 포함된 엘리먼트들 및 속성들의 시맨틱스가 일반적으로 표 2, 표 6, 표 10A 내지 표 10I 및 표 17A와 관련하여 앞서 제공된 것들 그리고 간결함을 위해 이하의 엘리먼트들 및 속성들의 시맨틱스를 제외한 예시적인 공식적 정의들에 대응한다는 점에 유의해야 한다:

AEA.wakeup - 이 임의적 불 속성은, 존재하고 "true"로 설정될 때, AEA가 비-제로 ea_wake_up 비트들과 연관된다는 것을 표시해야 한다([ATSC 3.0 Candidate Standard A/331]의 부록 G.2를 참조). 디폴트 값은, 존재하지 않을 때, "false"이어야 한다. 이 값은 [A/331]에 정의된 현재의 진보된 긴급 경보 메시지의 AEAT.AEA@wakeup 속성의 값이어야 한다.

Location.type -이 특성은 Location 코드의 도메인을 식별해주는 스트링이어야 한다. 일부 프라이머리 디바이스들 및 컴패니언 디바이스들이 자신들이 경보의 시그널링된 위치 지역 내에 위치되는지를 결정할 수 없을지도 모른다는 점에 유의한다. 그러한 프라이머리 디바이스들 및 컴패니언 디바이스들이 자신들이 경보의 지역 내에 위치된 것처럼 경보를 프로세싱하는 것이 제안된다.

타입이 "FIPS"와 동일한 경우, Location은 쉼표들로 분리된 하나 이상의 숫자 스트링의 그룹으로서 정의되어야 한다. 각각의 6-자리 숫자 스트링은 47 CFR 11.31에서 PSSCCC로서 정의된 방식으로 FIPS[FIPS]에 정의된 바와 같이 카운티 하위구분, 주 및 카운티 코드들의 연결이어야 한다. 부가적으로, 코드 "000000"은 미국 및 그 영토 내의 모든 위치들을 의미해야 하고, 코드 "999999"는 이 AEAT가 유래한 스테이션의 커버리지 영역 내의 모든 위치들을 의미해야 한다.

타입이 "SGC"와 동일한 경우, Location은 쉼표들로 분리된 하나 이상의 숫자 스트링의 그룹으로서 정의되어야 한다. 각각의 숫자 스트링은 SGC에 정의된 바와 같은 2-자리 PR(province), 2-자리 CD(census division) 및 3-자리 CSD(census subdivision)의 연결이어야 한다. 부가적으로, 코드 "00"은 캐나다 내의 모든 위치들을 의미해야 하고, 코드 "9999"는 이 AEAT가 유래한 스테이션의 커버리지 영역 내의 모든 위치들을 의미해야 한다.

type이 "polygon"과 동일한 경우, Location은 닫힌, 비-자기 교차 루프를 형성하는 4개 이상의 좌표 쌍의 연결 시퀀스로 이루어진 지리공간 공간 지역을 정의해야 한다.

type이 "circle"과 동일한 경우, Location은 좌표 쌍으로서 주어지는 중심 지점 및 그에 뒤이은 공백 문자 및 킬로미터 단위의 반경 값에 의해 표현되는 원형 지역을 정의해야 한다.

type의 텍스트 값들은 대소문자 구분이며, "polygon" 및 "circle"을 제외하고는, 모두 대문자들로 표현되어야 한다.

이 스트링은 [ATSC 3.0 Candidate Standard A/331]에 정의된 현재의 진보된 긴급 경보 메시지의 AEAT.AEA.Header.Location@type 속성의 값과 동일한 값을 가져야 한다.

LiveMedia - 긴급 관련 정보, 예컨대, 진행 중인 뉴스 보도를 위해 튜닝할 선택사항으로서 사용자에게 제시될 수 있는 A/V 서비스의 ID(Identification)를 제공하는 오브젝트. AEA.wakeup이 "true"인 경우 LiveMedia 엘리먼트가 존재해야 한다.

Media.mediaDesc - 미디어 리소스의 콘텐츠를, 평문으로, 설명해야 하는 스트링. 디스크립션은 미디어 정보를 표시해야 한다. 예를 들어, "대피 지도" 또는 "도플러 레이더 이미지" 등. Media.mediaDesc의 언어는 Media.lang에 표시된 언어와 동일한 것으로 추론되어야 한다. 이 정보는 시청자가 렌더링을 위해 선택할 수 있는 미디어 아이템들의 리스트를 시청자에게 제시하기 위해 수신기에 의해 사용될 수 있다. 이 필드가 제공되지 않은 경우, 수신기는 시청자 UI에서 아이템에 대한 일반 텍스트를 제시할 수 있다(예컨대, @contentType이 아이템이 비디오라고 표시하는 경우, 수신기는 UI 리스트에서 아이템을 "비디오"라고 설명할 수 있다).

Media.mediaType - 이 스트링은 관련 미디어의 의도된 용도를 식별해 주어야 한다. 이 속성으로 식별된 미디어 아이템들이 전형적으로, 선택을 위해 리스트에서 사용자에게 제시되는 미디어가 아니라, 수신기의 경보 사용자 인터페이스에 의해 자동으로 핸들링되는 아이템들과 연관된다는 점에 유의한다. 이 스트링은 [ATSC 3.0 Candidate Standard A/331]에 정의된 현재의 진보된 긴급 경보 메시지의 AEAT.AEA.Media@mediaType 엘리먼트의 값과 동일한 값을 가져야 한다.

Media.url - 멀티미디어 리소스 파일들 또는 패키지들의 소스를 결정해야 하는 요구된 특성. 리치 미디어 리소스가 광대역을 통해 전달될 때, 이 필드는 절대 URL로서 형성되고 원격 서버 상의 파일을 참조해야 한다. 리치 미디어 리소스가 방송 ROUTE를 통해 전달될 때, 이 필드는 상대 URL로서 형성되어야 한다. 상대 URL은 파일, 또는 파일의 Entity 헤더를 전달하는 LCT 채널에서의 EFDT 내의 대응하는 File 엘리먼트의 Content-Location 속성과 매칭해야 한다. EFDT 및 LCT 채널은 [ATSC 3.0 Candidate Standard A/331]에 정의되어 있다.

Media.mediaAssoc - 이 미디어 리소스와 연관된 다른 리치 미디어 리소스의 Media@uri를 포함하는 임의적 특성. 예들은 비디오와 연관된 클로즈드 캡션 트랙을 포함한다. Media.mediaAssoc의 구성은 앞서 Media.uri에 설명된 바와 같아야 한다. 이 값은 [ATSC 3.0 Candidate Standard A/331]에 정의된 현재의 진보된 긴급 경보 메시지의 AEAT.AEA.Media@mediaAssoc 속성의 값이어야 한다.

게다가, 일부 예들에서, 수신자 디바이스(400)가 표 10A 내지 표 10I와 관련하여 앞서 제공된 것들에 일반적으로 대응하는 엘리먼트들 및 속성들을 포함하는 예시적인 스키마에 기초하여 메시지를 컴패니언 디바이스(500)에게 송신하도록 구성될 수 있다는 점에 유의해야 한다.

이러한 방식으로, 수신자 디바이스(400)는 서비스 제공자로부터 긴급 경보 메시지를 수신하고, 웨이크 업 속성의 값을 표시하는 신택스 엘리먼트를 파싱하며, 신택스 엘리먼트에 적어도 부분적으로 기초하여 액션을 수행하도록 구성될 수 있다.

하나 이상의 예에서, 설명된 기능들은 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 임의의 조합으로 구현될 수 있다. 소프트웨어로 구현되는 경우, 기능들은 하나 이상의 명령어 또는 코드로서 컴퓨터 판독가능 매체 상에 저장되거나 그를 통해 전송될 수 있고 하드웨어 기반 프로세싱 유닛에 의해 실행될 수 있다. 컴퓨터 판독가능 매체들은 데이터 스토리지 매체들과 같은 유형적 매체에 대응하는 컴퓨터 판독가능 스토리지 매체들, 또는, 예컨대, 통신 프로토콜에 따라, 한 장소로부터 다른 장소로의 컴퓨터 프로그램의 전송을 용이하게 하는 임의의 매체를 포함한 통신 매체들을 포함할 수 있다. 이러한 방식으로, 컴퓨터 판독가능 매체들은 (1) 비일시적인 유형적 컴퓨터 판독가능 스토리지 매체들 또는 (2) 신호 또는 반송파(carrier wave)와 같은 통신 매체에 일반적으로 대응할 수 있다. 데이터 스토리지 매체들은 본 개시내용에서 설명된 기법들의 구현을 위해 명령어들, 코드 및/또는 데이터 구조들을 검색하기 위해 하나 이상의 컴퓨터 또는 하나 이상의 프로세서에 의해 액세스될 수 있는 임의의 이용가능한 매체들일 수 있다. 컴퓨터 프로그램 제품은 컴퓨터 판독가능 매체를 포함할 수 있다.

제한이 아닌 예로서, 그러한 컴퓨터 판독가능 스토리지 매체들은 RAM, ROM, EEPROM, CD-ROM 또는 다른 광학 디스크 스토리지, 자기 디스크 스토리지, 또는 다른 자기 스토리지 디바이스들, 플래시 메모리, 또는 원하는 프로그램 코드를 명령어들 또는 데이터 구조들의 형태로 저장하는 데 사용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함할 수 있다. 또한, 임의의 접속부(connection)가 적절하게도 컴퓨터 판독가능 매체라고 지칭된다. 예를 들어, 명령어들이 동축 케이블, 광섬유 케이블, 연선(twisted pair), DSL(digital subscriber line), 또는 적외선, 라디오, 및 마이크로파와 같은 무선 기술들을 사용하여 웹사이트, 서버, 또는 다른 원격 소스로부터 전송되는 경우, 동축 케이블, 광섬유 케이블, 연선, DSL, 또는 적외선, 라디오, 및 마이크로파와 같은 무선 기술들은 매체의 정의에 포함된다. 그렇지만, 컴퓨터 판독가능 스토리지 매체들 및 데이터 스토리지 매체들이 접속부들, 반송파들, 신호들, 또는 다른 일시적 매체들을 포함하지 않고, 그 대신에 비일시적, 유형적 스토리지 매체들에 관한 것임이 이해되어야 한다. 본 명세서에서 사용되는 바와 같은, 디스크(disk) 및 디스크(disc)는 CD(compact disc), 레이저 디스크, 광학 디스크, DVD(digital versatile disc), 플로피 디스크, 및 블루레이 디스크를 포함하고, 여기서 디스크들(disks)은 보통 데이터를 자기적으로 재생하는 반면, 디스크들(discs)은 데이터를 레이저를 사용하여 광학적으로 재생한다. 상기한 것들의 조합들이 컴퓨터 판독가능 매체들의 범주 내에 또한 포함되어야 한다.

명령어들은, 하나 이상의 디지털 신호 프로세서(DSP), 범용 마이크로프로세서, ASIC(application specific integrated circuit), FPGA(field programmable logic array), 또는 다른 동등한 집적 또는 이산 로직 회로부와 같은, 하나 이상의 프로세서에 의해 실행될 수 있다. 그에 따라, 본 명세서에서 사용되는 바와 같은 용어 "프로세서"는 전술한 구조체 또는 본 명세서에 설명된 기법들의 구현에 적당한 임의의 다른 구조체를 지칭할 수 있다. 그에 부가하여, 일부 양태들에서, 본 명세서에 설명된 기능은 인코딩 및 디코딩을 위해 구성된 전용 하드웨어 및/또는 소프트웨어 모듈들 내에 제공되거나, 결합된 코덱(combined codec)에 통합될 수 있다. 또한, 기법들은 하나 이상의 회로 또는 로직 요소에서 완전히 구현될 수 있다.

본 개시내용의 기법들은 무선 핸드셋, 집적 회로(IC) 또는 IC들의 세트(예컨대, 칩 세트)를 포함한, 다양한 디바이스들 또는 장치들에서 구현될 수 있다. 개시된 기법들을 수행하도록 구성된 디바이스들의 기능적 양태들을 강조하기 위해 다양한 컴포넌트들, 모듈들, 또는 유닛들이 본 개시내용에 설명되어 있지만, 상이한 하드웨어 유닛들에 의한 실현을 반드시 요구하지는 않는다. 오히려, 앞서 설명된 바와 같이, 다양한 유닛들은 코덱 하드웨어 유닛에 결합되거나, 적당한 소프트웨어 및/또는 펌웨어와 함께, 앞서 설명된 바와 같은 하나 이상의 프로세서를 포함한, 상호연동 하드웨어 유닛들의 집합체(collection of interoperative hardware units)에 의해 제공될 수 있다.

더욱이, 앞서 언급된 실시예들 각각에서 사용된 기지국 디바이스 및 단말 디바이스(비디오 디코더 및 비디오 인코더)의 각각의 기능 블록 또는 다양한 특징들은, 전형적으로 하나의 집적 회로 또는 복수의 집적 회로들인, 회로부에 의해 구현되거나 실행될 수 있다. 본 명세서에 설명된 기능들을 실행하도록 설계된 회로부는 범용 프로세서, 디지털 신호 프로세서(DSP), ASIC(application specific or general application integrated circuit), FPGA(field programmable gate array), 또는 다른 프로그래밍가능 로직 디바이스들, 이산 게이트들 또는 트랜지스터 로직, 또는 이산 하드웨어 컴포넌트, 또는 이들의 조합을 포함할 수 있다. 범용 프로세서는 마이크로프로세서일 수 있거나, 대안적으로, 프로세서는 종래의 프로세서, 제어기, 마이크로컨트롤러 또는 상태 머신일 수 있다. 앞서 설명된 범용 프로세서 또는 각각의 회로는 디지털 회로에 의해 구성될 수 있거나, 아날로그 회로에 의해 구성될 수 있다. 게다가, 반도체 기술의 진보로 인해 현재의 집적 회로들을 대체하는 집적 회로로 제조하는 기술이 출현할 때, 이 기술에 의한 집적 회로가 또한 사용될 수 있다.

다양한 예들이 설명되었다. 이들 및 다른 예들은 이하의 청구항들의 범주 내에 속한다.

<개요>

본 개시내용의 일 예에 따르면, 긴급 경보 메시지와 연관된 정보를 시그널링하기 위한 방법은 긴급 경보 메시지와 연관된 미디어 리소스의 콘텐츠 타입을 표시하는 신택스 엘리먼트를 시그널링하는 단계, 및 미디어 리소스의 디스크립션을 제공하는 신택스 엘리먼트를 시그널링하는 단계를 포함한다.

본 개시내용의 다른 예에 따르면, 긴급 경보 메시지와 연관된 정보를 시그널링하기 위한 디바이스는 긴급 경보 메시지와 연관된 미디어 리소스의 콘텐츠 타입을 표시하는 신택스 엘리먼트를 시그널링하고, 미디어 리소스의 디스크립션을 제공하는 신택스 엘리먼트를 시그널링하도록 구성된 하나 이상의 프로세서를 포함한다.

본 개시내용의 다른 예에 따르면, 장치는 긴급 경보 메시지와 연관된 미디어 리소스의 콘텐츠 타입을 표시하는 신택스 엘리먼트를 시그널링하기 위한 수단, 및 미디어 리소스의 디스크립션을 제공하는 신택스 엘리먼트를 시그널링하기 위한 수단을 포함한다.

본 개시내용의 다른 예에 따르면, 비일시적 컴퓨터 판독가능 저장 매체는 실행 시에 디바이스의 하나 이상의 프로세서로 하여금 긴급 경보 메시지와 연관된 미디어 리소스의 콘텐츠 타입을 표시하는 신택스 엘리먼트를 시그널링하게 하고, 미디어 리소스의 디스크립션을 제공하는 신택스 엘리먼트를 시그널링하게 하는 그 상에 저장된 명령어들을 포함한다.

본 개시내용의 일 예에 따르면, 긴급 경보와 연관된 미디어 리소스를 검색하기 위한 방법은 서비스 제공자로부터 긴급 경보 메시지를 수신하는 단계, 긴급 경보 메시지와 연관된 미디어 리소스의 콘텐츠 타입을 표시하는 신택스 엘리먼트를 파싱하는 단계, 및 콘텐츠 타입을 표시하는 신택스 엘리먼트에 적어도 부분적으로 기초하여, 미디어 리소스를 검색할지를 결정하는 단계를 포함한다.

본 개시내용의 다른 예에 따르면, 긴급 경보와 연관된 미디어 리소스를 검색하기 위한 디바이스는 서비스 제공자로부터 긴급 경보 메시지를 수신하고, 긴급 경보 메시지와 연관된 미디어 리소스의 콘텐츠 타입을 표시하는 신택스 엘리먼트를 파싱하며, 콘텐츠 타입을 표시하는 신택스 엘리먼트에 적어도 부분적으로 기초하여, 미디어 리소스를 검색할지를 결정하도록 구성된 하나 이상의 프로세서를 포함한다.

본 개시내용의 다른 예에 따르면, 장치는 서비스 제공자로부터 긴급 경보 메시지를 수신하고, 긴급 경보 메시지와 연관된 미디어 리소스의 콘텐츠 타입을 표시하는 신택스 엘리먼트를 파싱하며, 콘텐츠 타입을 표시하는 신택스 엘리먼트에 적어도 부분적으로 기초하여, 미디어 리소스를 검색할지를 결정하기 위한 수단을 포함한다.

본 개시내용의 다른 예에 따르면, 비일시적 컴퓨터 판독가능 저장 매체는 실행 시에 디바이스의 하나 이상의 프로세서로 하여금 서비스 제공자로부터 긴급 경보 메시지를 수신하게 하고, 긴급 경보 메시지와 연관된 미디어 리소스의 콘텐츠 타입을 표시하는 신택스 엘리먼트를 파싱하게 하며, 콘텐츠 타입을 표시하는 신택스 엘리먼트에 적어도 부분적으로 기초하여, 미디어 리소스를 검색할지를 결정하게 하는 그 상에 저장된 명령어들을 포함한다.

하나 이상의 예의 상세들이 첨부 도면들 및 이하의 설명에 기재되어 있다. 다른 특징들, 목적들, 및 장점들은 설명 및 도면들로부터 그리고 청구항들로부터 명백할 것이다.

Claims

긴급 경보 메시지와 연관된 정보를 시그널링하기 위한 방법으로서,
긴급 경보 메시지에 포함된 긴급 이벤트 디스크립터들(emergency event descriptors)의 수를 표시하는 신택스 엘리먼트(syntax element)를 시그널링하는 단계; 및
상기 표시된 수의 긴급 경보 디스크립터들 각각에 대한 긴급 이벤트 디스크립터의 길이를 표시하는 신택스 엘리먼트를 시그널링하는 단계
를 포함하는, 방법.
제1항에 있어서, 긴급 이벤트 디스크립터의 길이를 표시하는 상기 신택스 엘리먼트는 6-비트 정수 값 - 이 6-비트 정수 값에 1을 더한 것이 상기 긴급 이벤트 디스크립터의 상기 길이를 표시함 - 을 포함하는, 방법.
제1항에 있어서, 값 - 이 값에 1을 더한 것이 상기 표시된 수의 긴급 이벤트 디스크립터들 각각에 대한 긴급 이벤트 디스크립터의 언어(language) 속성의 길이를 표시함 - 을 갖는 신택스 엘리먼트를 시그널링하는 단계를 추가로 포함하는, 방법.
제1항에 있어서, 웨이크 업(wake up) 속성의 값을 표시하는 신택스 엘리먼트를 시그널링하는 단계를 추가로 포함하는, 방법.
제1항에 있어서, 상기 긴급 경보 메시지는 워터마크 페이로드(watermark payload)에 포함되는, 방법.
워터마크 페이로드에서 긴급 경보 메시지와 연관된 정보를 시그널링하기 위한 디바이스로서,
상기 디바이스는 하나 이상의 프로세서
를 포함하며, 상기 하나 이상의 프로세서는:
긴급 경보 메시지에 포함된 긴급 이벤트 디스크립터들의 수를 표시하는 신택스 엘리먼트를 시그널링하고;
상기 표시된 수의 긴급 이벤트 디스크립터들 각각에 대한 긴급 이벤트 디스크립터의 길이를 표시하는 신택스 엘리먼트를 시그널링하도록 구성되고, 긴급 이벤트 디스크립터의 길이를 표시하는 상기 신택스 엘리먼트는 6-비트 정수 값 - 이 6-비트 정수 값에 1을 더한 것이 상기 긴급 이벤트 디스크립터의 상기 길이를 표시함 - 을 포함하는, 디바이스.
제6항에 있어서, 상기 하나 이상의 프로세서는 상기 표시된 수의 긴급 이벤트 디스크립터들 각각에 대한 긴급 이벤트 디스크립터의 언어 속성의 길이를 표시하는 신택스 엘리먼트를 시그널링하도록 추가로 구성되고, 언어 속성의 길이를 표시하는 신택스 엘리먼트는 값 - 이 값에 1을 더한 것이 언어 속성의 상기 길이를 표시함 - 을 표시하는, 디바이스.
제6항에 있어서, 상기 하나 이상의 프로세서는 웨이크 업 속성의 값을 표시하는 신택스 엘리먼트를 시그널링하도록 추가로 구성되는, 디바이스.
제6항에 있어서, 상기 디바이스는 서비스 배포 엔진을 포함하는, 디바이스.
긴급 경보 메시지에 대한 디스크립터를 생성하기 위한 방법으로서,
긴급 경보 메시지를 수신하는 단계;
상기 긴급 경보 메시지에 포함된 긴급 이벤트 디스크립터의 바이트 수를 표시하는 신택스 엘리먼트를 파싱하는 단계 - 긴급 이벤트 디스크립터의 바이트 수를 표시하는 상기 신택스 엘리먼트는 6-비트 정수 값 - 이 6-비트 정수 값에 1을 더한 것이 상기 바이트 수를 표시함 - 을 포함함 -;
상기 표시된 바이트 수에 대해, 문자를 표시하는 값을 갖는 바이트를 파싱하는 단계; 및
상기 표시된 문자들을 사용하여 상기 긴급 이벤트 디스크립터를 생성하는 단계
를 포함하는, 방법.
제10항에 있어서, 값 - 이 값에 1을 더한 것이 상기 긴급 이벤트 디스크립터의 언어 속성의 길이를 표시함 - 을 갖는 신택스 엘리먼트를 파싱하는 단계를 추가로 포함하는, 방법.
제10항에 있어서, 웨이크 업 속성의 값을 표시하는 신택스 엘리먼트를 파싱하는 단계를 추가로 포함하는, 방법.
제10항에 있어서, 상기 긴급 경보 메시지는 워터마크 페이로드에 포함되는, 방법.
제10항에 있어서, 웨이크 업 속성의 상기 값을 표시하는 상기 신택스 엘리먼트에 적어도 부분적으로 기초하여 액션을 취하는 단계
를 추가로 포함하는, 방법.
긴급 경보 메시지에 대한 디스크립터를 생성하기 위한 디바이스로서,
상기 디바이스는 하나 이상의 프로세서
를 포함하고, 상기 하나 이상의 프로세서는:
긴급 경보 메시지를 수신하고;
상기 긴급 경보 메시지에 포함된 긴급 이벤트 디스크립터의 바이트 수를 표시하는 신택스 엘리먼트를 파싱하며 - 긴급 이벤트 디스크립터의 바이트 수를 표시하는 상기 신택스 엘리먼트는 6-비트 정수 값 - 이 6-비트 정수 값에 1을 더한 것이 상기 바이트 수를 표시함 - 을 포함함 -;
상기 표시된 바이트 수에 대해 바이트를 파싱하고 - 각각의 바이트는 문자를 표시하는 값을 가짐 -;
상기 표시된 문자들을 사용하여 상기 긴급 이벤트 디스크립터를 생성하도록 구성되는, 디바이스.
제15항에 있어서, 상기 하나 이상의 프로세서는 값 - 이 값에 1을 더한 것이 상기 긴급 이벤트 디스크립터의 언어 속성의 길이를 표시함 - 을 갖는 신택스 엘리먼트를 파싱하도록 추가로 구성되는, 디바이스.
제15항에 있어서, 상기 하나 이상의 프로세서는 웨이크 업 속성의 값을 표시하는 신택스 엘리먼트를 파싱하도록 추가로 구성되는, 디바이스.
제17항에 있어서, 상기 하나 이상의 프로세서는 웨이크 업 속성의 상기 값을 표시하는 상기 신택스 엘리먼트에 적어도 부분적으로 기초하여 액션을 취하도록 추가로 구성되는, 디바이스.
제15항에 있어서, 상기 긴급 경보 메시지는 워터마크 페이로드에 포함되는, 디바이스.
제15항에 있어서, 상기 디바이스는 데스크톱 또는 랩톱 컴퓨터, 모바일 디바이스, 스마트폰, 셀룰러 전화, PDA(personal data assistant), 텔레비전, 태블릿 디바이스, 또는 개인 게이밍 디바이스로 이루어진 그룹 중에서 선택되는, 디바이스.