KR102166984B1 - 방송 식별자 시그널링 - Google Patents

Abstract

OtherBsid(도 26b), @type(도 26b), @essential(도 26b), "type"(도 30), SLT(도 26a), Service(도 26a) 및 @serviceId(도 26a)를 사용하여 서비스 정보를 생성, 전송, 제공 및/또는 수신하기 위한 시스템.

Description

방송 식별자 시그널링

본 개시내용은 대체로 서비스 시그널링(service signaling)에 관한 것이다.

방송 서비스는 방송 수신기들을 갖는 모든 사용자들에 의해 수신될 수 있다. 방송 서비스들은 2가지 범주, 즉, 오디오만 운반하는 라디오 방송 서비스와, 오디오, 비디오 및 데이터를 운반하는 멀티미디어 방송 서비스로 대략 나눌 수 있다. 이러한 방송 서비스들은 아날로그 서비스들로부터 디지털 서비스들로 발전했다. 더 최근에는, (케이블 방송 시스템, 위성 방송 시스템, 인터넷 기반 방송 시스템, 및 케이블 네트워크, 인터넷 및/또는 위성 모두를 이용한 하이브리드 방송 시스템 등의) 다양한 타입들의 방송 시스템들이 고속 데이터 서비스와 함께 고품질의 오디오 및 비디오 방송 서비스들을 제공한다. 또한, 방송 서비스들은, 개개의 컴퓨터 및/또는 컴퓨터 그룹 및/또는 하나 이상의 모바일 통신 디바이스로 향하는 오디오, 비디오 및/또는 데이터를 전송 및/또는 수신하는 것을 포함한다.

보다 전통적인 고정 수신 디바이스들에 추가하여, 모바일 통신 디바이스들은 이러한 서비스들을 지원하도록 마찬가지로 구성된다. 이렇게 구성된 모바일 디바이스들은, 모바일 전화들과 같이, 이동 중에 사용자가 이러한 서비스들을 용이하게 이용할 수 있게 해왔다. 멀티미디어 서비스들에 대한 요구가 증가함에 따라, 모바일 통신들 및 일반 유선 통신들 양쪽 모두를 위한 다양한 무선 및/또는 방송 서비스들이 생겨났다. 또한, 이러한 컨버전스는 상이한 유선 및 무선 방송 서비스들을 위한 환경을 통합했다.

OMA(Open Mobile Alliance)는 개개의 모바일 솔루션들간의 연동을 위한 표준이며, 모바일 소프트웨어 및 인터넷 서비스들에 대한 다양한 애플리케이션 표준들을 정의하는 역할을 한다. OMA BCAST(Mobile Broadcast Services Enabler Suite)는 모바일 방송 기술들을 지원하도록 설계된 명세이다. OMA BCAST는, 서비스 가이드 다운로딩 및 스트리밍, 서비스 및 콘텐츠 보호, 서비스 가입, 및 로밍 등의 다양한 기능들을 포함하는 IP 기반 모바일 콘텐츠 배달을 제공하는 기술들을 정의한다.

본 발명의 전술된 것 및 기타의 목적들, 특징들, 및 이점들은, 첨부된 도면들과 연계하여 본 발명의 이하의 상세한 설명을 고려하면 더욱 용이하게 이해될 것이다.

본 발명의 일 실시예는 제1 라디오 주파수 채널 내의 서비스와 연관된 서비스 정보를 시그널링하기 위한 방법을 개시하고, 이 방법은: 제1 라디오 주파수 채널과 연관된 서비스 리스트 테이블을 시그널링하는 단계; 제1 라디오 주파수 채널과 연관된 서비스 리스트 테이블 내의 서비스 정보를 시그널링하는 단계; 제1 라디오 주파수 채널과 연관된 서비스 리스트 테이블 내의 서비스 정보와 연관된 필수 정보를 시그널링하는 단계 - 필수 정보는 제1 라디오 주파수 채널 내의 서비스가 제2 라디오 주파수 채널에 의해 배달된 하나 이상의 부분을 갖는다는 것을 표시하는 속성임 - ; 필수 정보 속성이 참인 경우에, 부분 타입을 표시하는 제1 라디오 주파수 채널과 연관된 서비스 리스트 테이블 내의 서비스 정보에서의 적어도 하나의 다른 방송 서비스 식별 (OtherBSID) 엘리먼트를 시그널링하는 단계; 필수 정보 속성이 거짓인 경우에, 제1 라디오 주파수 채널과 연관된 서비스 리스트 테이블 내의 서비스 정보에서의 어떤 다른 방송 서비스 식별(OtherBSID) 엘리먼트도 시그널링하지 않는 단계; 및 서비스 리스트 테이블을 전송하는 단계를 포함한다.

본 발명의 일 실시예는 비디오 서비스를 렌더링하기 위한 디바이스를 개시하고, 이 디바이스는 하나 이상의 프로세서를 포함하고, 하나 이상의 프로세서는: 제1 라디오 주파수 채널을 수신하고; 제1 라디오 주파수 채널 내의 제1 서비스 리스트 테이블을 수신하고; 서비스 엘리먼트를 수신하기 위해 제1 서비스 리스트 테이블을 파싱하고; 서비스 엘리먼트가 필수 정보 속성을 포함하는지를 결정하고; 필수 정보 속성이 존재하는 경우에, 필수 정보 속성의 값을 결정하기 위해 서비스 엘리먼트를 파싱하고; 필수 엘리먼트의 값이 참일 때: 하나 이상의 다른 방송 서비스 식별(OtherBSID) 엘리먼트를 수신하기 위해 서비스 엘리먼트를 파싱하고; 하나 이상의 다른 방송 서비스 식별(OtherBSID) 엘리먼트 각각의 타입을 결정하고; 필수 엘리먼트의 값이 거짓일 때, 하나 이상의 다른 방송 서비스 식별(OtherBSID) 엘리먼트를 수신하기 위해 서비스 엘리먼트를 파싱하지 않고; 서비스 정보를 이용하여 비디오 서비스를 렌더링하도록 구성된다.

도 1은 애플리케이션 계층과 트랜스포트 계층에서 OMA BCAST 연구 그룹에 의해 명시된 BCAST 시스템의 논리적 아키텍쳐를 나타내는 블록도이다.
도 2는 OMA BCAST 시스템에서 이용하기 위한 서비스 가이드의 구조를 나타내는 도면이다.
도 2a는 서비스 가이드 프래그먼트들 사이의 카디널리티들 및 참조 방향을 도시하는 도면이다.
도 3은 종래의 서비스 가이드 배달 방법의 원리를 나타내는 블록도이다.
도 4는 디스크립션 스킴을 나타낸다.
도 5는 MajorChannelNum 및 MinorChannelNum을 갖는 ServiceMediaExtension을 나타낸다.
도 6은 Icon을 갖는 ServiceMediaExtension을 나타낸다.
도 7은 url을 갖는 ServiceMediaExtension을 나타낸다.
도 8은 MajorChannelNum, MinorChannelNum, Icon 및 url을 갖는 ServiceMediaExtension을 나타낸다.
도 9a는 AudioLanguage 엘리먼트들 및 TextLanguage 엘리먼트들을 나타낸다.
도 9b는 AudioLanguage 엘리먼트들 및 TextLanguage 엘리먼트들을 나타낸다.
도 9c는 AudioLanguage 엘리먼트들 및 TextLanguage 엘리먼트들을 나타낸다.
도 10a는 AudioLanguage 엘리먼트들 및 TextLanguage 엘리먼트들을 나타낸다.
도 10b는 AudioLanguage 엘리먼트들 및 TextLanguage 엘리먼트들을 나타낸다.
도 10c는 AudioLanguage 엘리먼트들 및 TextLanguage 엘리먼트들을 나타낸다.
도 11은 컴포넌트 정보 디스크립션 시그널링을 나타낸다.
도 12는 채널 정보 디스크립션 시그널링을 나타낸다.
도 13a는 컴포넌트 정보 디스크립터에 대한 바이너리 신택스를 나타낸다.
도 13b는 컴포넌트 정보 디스크립터에 대한 바이너리 신택스를 나타낸다.
도 14a는 채널 정보 디스크립터에 대한 바이너리 신택스를 나타낸다.
도 14b는 채널 정보 디스크립터에 대한 바이너리 신택스를 나타낸다.
도 15는 컴포넌트 정보 디스크립터에 대한 XML 신택스 및 시맨틱스를 나타낸다.
도 16은 채널 정보 디스크립터에 대한 XML 신택스 및 시맨틱스를 나타낸다.
도 17은 컴포넌트 정보 디스크립터에 대한 XML 스키마를 나타낸다.
도 18은 채널 정보 디스크립터에 대한 XML 스키마를 나타낸다.
도 19는 서비스 리스트 테이블(SLT)을 나타낸다.
도 20a는 SLT에 대한 XML 스키마를 나타낸다.
도 20b는 SLT에 대한 XML 스키마를 나타낸다.
도 20c는 SLT의 구조를 나타낸다.
도 21은 URLType에 대한 코드 값들을 나타낸다.
도 22는 SLT.Service@serviceCategory에 대한 코드 값들을 나타낸다.
도 23은 SLT.Service@slsProtocol에 대한 코드 값들을 나타낸다.
도 24는 경로 내의 겉보기의 순서로 경로 용어들을 나타낸다.
도 25는 메타데이터 오브젝트 타입들을 나타낸다.
도 261은 예시적인 서비스 리스트 테이블을 나타낸다.
도 262는 예시적인 서비스 리스트 테이블을 나타낸다.
도 27은 urlType에 대한 예시적인 코드 값들을 나타낸다.
도 28은 SLT.Service@serviceCategory에 대한 예시적인 코드 값들을 나타낸다.
도 29는 SLT.Service.BroadcastSvcSignaling@slsProtocol에 대한 예시적인 코드 값들을 나타낸다.
도 30은 SLT.Service.OtherBsid@type에 대한 예시적인 코드 값들을 나타낸다.

도 1을 참조하면, OMA(Open Mobile Alliance) BCAST에 의해 명시된 방송 시스템의 논리적 아키텍쳐는 애플리케이션 계층과 트랜스포트 계층을 포함할 수 있다. BCAST 시스템의 논리적 아키텍쳐는, 콘텐츠 생성(CC)(101), BCAST 서비스 애플리케이션(102), BCAST 서비스 배포 적응화(BSDA)(103), BCAST 가입 관리(BSM)(104), 단말기(105), 방송 배포 시스템(BDS) 서비스 배포(111), BDS(112), 및 상호작용 네트워크(113)를 포함한다. 방송 시스템 및/또는 수신기 시스템은 원한다면 재구성될 수 있다는 것을 이해해야 한다. 방송 시스템 및/또는 수신기 시스템은 원한다면 추가적인 엘리먼트들 및/또는 더 적은 수의 엘리먼트들을 포함할 수 있다는 것을 이해해야 한다.

일반적으로, 콘텐츠 생성(101)은 BCAST 서비스들의 기초가 되는 콘텐츠를 제공할 수 있다. 콘텐츠는, 공통 방송 서비스들을 위한 파일들, 예를 들어, 오디오 및 비디오를 포함하는 영화에 대한 데이터를 포함할 수 있다. 콘텐츠 생성(101)은, 서비스 가이드를 생성하고 서비스들이 배달될 전송 베어러(transmission bearer)를 결정하는 데 이용되는, 콘텐츠에 대한 속성들을 BCAST 서비스 애플리케이션(102)에 제공한다.

일반적으로, BCAST 서비스 애플리케이션(102)은 콘텐츠 생성(101)으로부터 제공된 BCAST 서비스들에 대한 데이터를 수신할 수 있고, 수신된 데이터를, 미디어 인코딩, 콘텐츠 보호, 대화형 서비스들 등을 제공하기에 적합한 형태로 변환한다. BCAST 서비스 애플리케이션(102)은, 콘텐츠 생성(101)으로부터 수신된 콘텐츠에 대한 속성들을 BSDA(103) 및 BSM(104)에 제공한다.

일반적으로, BSDA(103)는 BCAST 서비스 애플리케이션(102)으로부터 제공되는 BCAST 서비스 데이터를 이용하여, 파일 및/또는 스트리밍 배달, 서비스 수집, 서비스 보호, 서비스 가이드 생성/배달 및 서비스 통지 등의 동작들을 수행할 수 있다. BSDA(103)는 BDS(112)에 맞게 서비스를 적응화한다.

일반적으로, BSM(104)은, 하드웨어 또는 소프트웨어를 통해, BCAST 서비스 사용자들에 대한 가입 및 과금 관련 기능들, BCAST 서비스들에 이용되는 정보 프로비져닝 등의 서비스 프로비져닝, 및 BCAST 서비스들을 수신하는 모바일 단말기들을 관리할 수 있다.

일반적으로, 단말기(105)는 콘텐츠 보호 등의 콘텐츠 및/또는 서비스 가이드 및 프로그램 지원 정보를 수신할 수 있고, 사용자에게 방송 서비스를 제공한다. BDS 서비스 배포(111)는, BDS(112) 및 상호작용 네트워크(113)와의 상호 통신을 통해 복수의 단말기들에 모바일 방송 서비스들을 배달한다.

일반적으로, BDS(112)는 방송 채널을 통해 모바일 방송 서비스들을 배달할 수 있고, 예를 들어, 제3 세대 프로젝트 파트너십(3GPP)에 의한 멀티미디어 방송 멀티캐스트 서비스(MBMS), 제3 세대 프로젝트 파트너십 2(3GPP2)에 의한 방송 멀티캐스트 서비스(BCMCS), DVB(Digital Video Broadcasting)에 의한 DVB-H(DVB-Handheld), 또는 IP(Internet Protocol) 기반 방송 통신 네트워크를 포함할 수 있다. 상호작용 네트워크(113)는 상호작용 채널을 제공하고, 예를 들어, 셀룰러 네트워크를 포함할 수 있다.

참조 포인트들, 또는 도 1의 논리적 엔티티들 사이의 접속 경로들은, 원한다면, 복수의 인터페이스들을 가질 수 있다. 인터페이스들은 그들 특유의 목적들을 위해 2개 이상의 논리적 엔티티들 사이의 통신에 이용된다. 메시지 포맷, 프로토콜 등이 인터페이스들에 적용된다. 일부 실시예들에서, 하나 이상의 상이한 기능들 사이에는 논리적 인터페이스들이 없다.

BCAST-1(121)은 콘텐츠 및 콘텐츠 속성들에 대한 전송 경로이고, BCAST-2(122)는 콘텐츠-보호된 또는 콘텐츠-비보호된 BCAST 서비스, BCAST 서비스의 속성들, 및 콘텐츠 속성들에 대한 전송 경로이다.

BCAST-3(123)은, BCAST 서비스의 속성들, 콘텐츠의 속성들, 사용자 선호사항 및/또는 가입 정보, 사용자 요청, 및 요청에 대한 응답에 대한 전송 경로이다. BCAST-4(124)는, 통지 메시지, 서비스 가이드에 이용되는 속성들, 및 콘텐츠 보호 및 서비스 보호에 이용되는 키에 대한 전송 경로이다.

BCAST-5(125)는, 방송 채널을 통해 전송되는 모든 데이터 및 시그널링, 보호된 BCAST 서비스, 비보호된 BCAST 서비스, 콘텐츠-보호된 BCAST 서비스, 콘텐츠-비보호된 BCAST 서비스, BCAST 서비스 속성들, 콘텐츠 속성들, 통지, 서비스 가이드, 및 BCAST 서비스 보호에 이용되는 키 값들 및 DRM RO(Digital Right Management Right Object) 등의 보안 자료들에 대한 전송 경로이다.

BCAST-6(126)은, 상호작용 채널을 통해 전송되는 모든 데이터와 시그널링, 보호된 BCAST 서비스, 비보호된 BCAST 서비스, 콘텐츠-보호된 BCAST 서비스, 콘텐츠-비보호된 BCAST 서비스, BCAST 서비스 속성들, 콘텐츠 속성들, 통지, 서비스 가이드, 및 BCAST 서비스 보호에 이용되는 키 값들 및 DRM RO 등의 보안 자료들에 대한 전송 경로이다.

BCAST-7(127)은, BCAST 서비스 보호를 위해 이용되는 키 값들 및 DRM RO 등의, 보안 자료들의 수신에 관련된 제어 정보를 위한 상호작용 채널을 통해 전송되는 사용자 선호사항 정보, 서비스 프로비져닝, 가입 정보, 및 디바이스 관리에 대한 전송 경로이다.

BCAST-8(128)은 BCAST 서비스를 위한 사용자 데이터가 제공되는 전송 경로이다. BDS-1(129)은, BCAST 서비스 보호에 이용되는 키 값들 및 DRM RO 등의 보안 자료들, 보호된 BCAST 서비스, 비보호된 BCAST 서비스, BCAST 서비스 속성들, 콘텐츠 속성들, 통지, 및 서비스 가이드에 대한 전송 경로이다.

BDS-2(130)는, BCAST 서비스 보호를 위해 이용되는 키 값들 및 DRM RO 등의 보안 자료들, 서비스 프로비져닝, 가입 정보, 및 디바이스 관리에 대한 전송 경로이다.

X-1(131)은 BDS 서비스 배포(111)와 BDS(112) 사이의 참조 포인트이다. X-2(132)는 BDS 서비스 배포(111)와 상호작용 네트워크(113) 사이의 참조 포인트이다. X-3(133)은 BDS(112)와 단말기(105) 사이의 참조 포인트이다. X-4(134)는 방송 채널을 통한 BDS 서비스 배포(111)와 단말기(105) 사이의 참조 포인트이다. X-5(135)는 상호작용 채널을 통한 BDS 서비스 배포(111)와 단말기(105) 사이의 참조 포인트이다. X-6(136)은 상호작용 네트워크(113)와 단말기(105) 사이의 참조 포인트이다.

도 2를 참조하면, OMA BCAST 시스템에 대한 예시적인 서비스 가이드가 예시된다. 예시의 목적들을 위해, 프래그먼트들 사이의 실선 화살표들은 프래그먼트들 사이의 참조 방향을 나타낸다. 서비스 가이드 시스템은, 원한다면, 재구성될 수 있다는 것을 이해해야 한다. 서비스 가이드 시스템은, 원한다면, 추가적인 엘리먼트들 및/또는 더 적은 수의 엘리먼트들을 포함할 수 있다는 것을 이해해야 한다. 엘리먼트들의 기능성은, 원한다면, 수정 및/또는 결합될 수 있다는 것을 이해해야 한다.

도 2a는 서비스 가이드 프래그먼트들 사이의 카디널리티들 및 참조 방향을 도시하는 도면이다. 도 2에 도시된 카디널리티들의 의미는 다음과 같다: 도 2a에서와 같이 프래그먼트 A의 한 인스턴스화는 프래그먼트 B의 c 내지 d개의 인스턴스화를 참조한다. c가 d이면, d가 생략된다. 따라서, c > 0이고 프래그먼트 A가 존재한다면, 프래그먼트 B의 적어도 c개의 인스턴스화가 또한 존재해야 하지만, 프래그먼트 B의 최대 d개의 인스턴스화가 존재할 수 있다. 그 역도 마찬가지로, 프래그먼트 B의 한 인스턴스화는 프래그먼트 A의 a 내지 b개의 인스턴스화에 의해 참조된다. a가 b이면, b가 생략된다. 프래그먼트 B를 가리키는 프래그먼트 A로부터의 화살표 연결은 프래그먼트 A가 프래그먼트 B에 대한 참조를 포함한다는 것을 나타낸다.

도 2와 관련하여, 일반적으로, 서비스 가이드는, 전체 서비스 가이드에 대한 기본 정보를 제공하기 위한 관리 그룹(200), 가입 및 구매 정보를 제공하기 위한 프로비저닝 그룹(210), 서비스 가이드의 코어 부분으로서 역할하는 코어 그룹(220), 및 서비스들과 콘텐츠에 대한 액세스를 제어하는 액세스 정보를 제공하기 위한 액세스 그룹(230)을 포함한다.

관리 그룹(200)은 서비스 가이드 배달 디스크립터(Service Guide Delivery Descriptor: SGDD)(201)을 포함할 수 있다. 프로비저닝 그룹(210)은 구매 항목 블록(211), 구매 데이터 블록(212), 및 구매 채널 블록(213)을 포함할 수 있다. 코어 그룹(220)은, 서비스 블록(221), 스케쥴 블록(222), 및 콘텐츠 블록(223)을 포함할 수 있다. 액세스 그룹(230)은 액세스 블록(231) 및 세션 디스크립션 블록(232)을 포함할 수 있다.

서비스 가이드는, 관리 그룹(200), 프로비저닝 그룹(210), 코어 그룹(220), 및 액세스 그룹(230)에 추가하여, 미리보기 데이터(241) 및 대화형 데이터(251)를 더 포함할 수 있다.

전술된 컴포넌트들은 식별 목적들을 위해, 서비스 가이드의 양태들을 구성하는 기본 유닛들 또는 프래그먼트들이라고 지칭될 수 있다.

SGDD 프래그먼트(201)는, SGDU(Service Guide Delivery Unit)가 위치해 있는 배달 세션에 관한 정보를 제공할 수 있다. SGDU는, 서비스 가이드를 구성하는 서비스 가이드 프래그먼트들(211, 212, 213, 221, 222, 223, 231, 232, 241, 251)을 포함하는 컨테이너이다. SGDD는 또한, 그룹화 정보 및 통지 메시지들을 수신하기 위한 엔트리 포인트들에 관한 정보를 제공할 수 있다.

방송 서비스에 포함된 콘텐츠의 상위 집성인 서비스 프래그먼트(221)는, 서비스 콘텐츠, 장르, 서비스 위치 등에 관한 정보를 포함할 수 있다. 일반적으로, 'Service' 프래그먼트는 방송 서비스를 포함하는 콘텐츠 항목들을 집성 레벨(aggregate level)에서 디스크립션한다. 서비스는 다수의 액세스 수단, 예를 들어, 방송 채널 및 대화형 채널을 이용하여 사용자에게 배달될 수 있다. 서비스는 소정 사용자 그룹 또는 지리적 영역을 대상으로 할 수 있다. 서비스의 타입에 따라, 서비스는 대화형 부분(들), 방송-전용 부분(들), 또는 양쪽 모두를 가질 수 있다. 또한, 서비스는, 콘텐츠에 직접 관련되지 않지만 구매 또는 가입 정보 등의 서비스의 기능에 관련된 컴포넌트들을 포함할 수 있다. 서비스 가이드(SG)의 일부로서, '서비스' 프래그먼트는 '액세스(Access)', '스케쥴(Schedule)', '콘텐츠(Content)' 및 '구매항목(PurchaseItem)' 프래그먼트들을 포함한 다른 프래그먼트들에 의해 참조되는 중앙 허브를 형성한다. 그 외에도, '서비스' 프래그먼트는 '프리뷰데이터(PreviewData)' 프래그먼트를 참조할 수 있다. 이것은 이들 프래그먼트들 각각 중 몇몇에 의해 참조될 수 있거나 어느 것에 의해서도 참조되지 않을 수 있다. 연관된 프래그먼트들과 함께, 단말기는 임의의 시점에서 서비스와 연관된 상세사항들을 결정할 수 있다. 예를 들어, 연관된 무슨 콘텐츠가 언제, 어떻게, 어떤 비용으로 소비될 수 있는지의, 이러한 상세사항들이 사용자-친화적인 디스플레이 내에 요약될 수 있다.

Access 프래그먼트(231)는, 사용자가, 서비스 및 배달 방법, 및 대응하는 액세스 세션과 연관된 세션 정보를 보는 것을 허용하기 위한 액세스-관련 정보를 제공할 수 있다. 따라서, '액세스' 프래그먼트는 서비스의 수명 기간 동안 서비스가 어떻게 액세스될 수 있는지를 디스크립션한다. 이 프래그먼트는 세션 디스크립션 정보를 포함하거나 참조하며, 배달 방법을 나타낸다. 하나 이상의 '액세스' 프래그먼트는 '서비스' 프래그먼트를 참조할 수 있고, 연관된 서비스에 액세스하거나 상호작용하기 위한 대안적 방식들을 제공한다. 단말기의 경우, '액세스' 프래그먼트는 서비스를 수신하고 렌더링하는 단말기로부터 요구되는 능력들이 무엇인지에 관한 정보를 제공한다. '액세스' 프래그먼트는 세션 디스크립션 파라미터들을, 인라인 텍스트의 형태로, 또는 별개의 세션 디스크립션에 대한 URI(Uniform Resource Identifier) 형태의 포인터를 통해 제공한다. 세션 디스크립션 정보는 방송 채널 또는 상호작용 채널을 통해 배달될 수 있다.

세션 디스크립션 프래그먼트(232)는 액세스 프래그먼트(231)에 포함될 수 있고, 단말기가 세션 디스크립션 프래그먼트(232)에 관한 정보를 검출할 수 있도록 균일한 리소스 식별자 형태로 위치 정보를 제공할 수 있다. 세션 디스크립션 프래그먼트(232)는, 세션에 존재하는 멀티미디어 콘텐츠에 관한 어드레스 정보, 코덱 정보 등을 제공할 수 있다. 따라서 'SessionDescription'은 서비스 또는 콘텐츠 항목에의 액세스를 위한 세션 정보를 제공하는 서비스 가이드 프래그먼트이다. 또한, 세션 디스크립션은, 연관된 배달 프로시져들에 이용되는 보조 디스크립션 정보를 제공할 수 있다. 세션 디스크립션 정보는, 텍스트 포맷의 세션 디스크립션 프로토콜(session description protocol: SDP)의 신택스를 이용하여, 또는 3GPP MBMS 사용자 서비스 번들 디스크립션[3GPP TS 26.346](USBD)을 통해 제공된다. 보조 디스크립션 정보는 XML(eXtensible Markup Language) 포맷으로 제공되며 [BCAST10-Distribution(배포)]에 명시된 연관된 배달 디스크립션(Associated Delivery Description)을 포함한다. SDP 신택스가 이용되는 경우, 세션 디스크립션을 배달하는 대안적인 방식은 SDP를 '액세스' 프래그먼트에서 텍스트 포맷으로 캡슐화에 의한 것이라는 점에 유의한다. 세션 디스크립션은 서비스 가이드(Service Guide) 배달 그 자체 뿐만 아니라 콘텐츠 세션들 양쪽 모두에 이용될 수 있다는 점에 유의한다.

구매 항목(Purchase Item) 프래그먼트(211)는, 사용자가 구매 항목 프래그먼트(211)에 가입하거나 이를 구매하는 것을 돕는 서비스의 번들, 콘텐츠, 시간 등을 제공할 수 있다. 따라서, 'PurchaseItem' 프래그먼트는, 가입 및/또는 구매를 위해 최종 사용자에게 무료로 제공되는 하나 이상의 서비스(즉, 서비스 번들) 또는 하나 이상의 콘텐츠 항목의 그룹을 나타낸다. 이 프래그먼트는, 상이한 서비스 번들들에 관한 더 많은 정보를 제공하는 '구매데이터(PurchaseData)' 프래그먼트에 의해 참조될 수 있다. 'PurchaseItem' 프래그먼트는 다음과도 연관될 수 있다: (1) 번들화된 서비스들 가입을 가능하게 하는 '서비스' 프래그먼트, 및/또는 (2) 소정 시간프레임에서 소정 서비스 또는 콘텐츠를 소비할 수 있게 하는(페이-퍼-뷰 기능) '스케쥴' 프래그먼트, 및/또는 (3) 서비스에 관련된 단일 콘텐츠 파일을 구매할 수 있게 하는 '콘텐츠' 프래그먼트, (4) 구매 항목들의 번들링을 가능하게 하는 기타의 '구매항목(PurchaseItem)' 프래그먼트.

구매 데이터 프래그먼트(212)는 서비스 또는 콘텐츠 번들에 대한 가격 정보 및 홍보 정보 등의, 상세한 구매 및 가입 정보를 포함할 수 있다. 구매 채널(Purchase Channel) 프래그먼트(213)는 가입 또는 구매에 대한 액세스 정보를 제공할 수 있다. 따라서, '구매데이터(PurchaseData)' 프래그먼트의 주요 기능은 연관된 구매 항목에 대한 이용가능한 가격 정보를 표현하는 것이다. 'PurchaseData' 프래그먼트는 하나 또는 수 개의 구매 채널에 대한 정보를 수집하고 소정 서비스 또는 서비스 번들 특유의 프리뷰데이터(PreviewData)와 연관될 수 있다. 이것은 서비스, 서비스 번들 또는 콘텐츠 항목의 가격책정에 대한 정보를 운반한다. 또한, 홍보 활동에 대한 정보가 이 프래그먼트에 포함될 수 있다. SGDD는 또한, 서비스 가이드를 수신하고 컨테이너로서 SGDU에 대한 정보를 그룹화하는 엔트리 포인트들에 관한 정보를 제공할 수 있다.

프리뷰 데이터 프래그먼트(241)는 서비스, 스케쥴, 및 콘텐츠에 대한 프리뷰 정보를 제공하는 데 이용될 수 있다. 따라서, 'PreviewData' 프래그먼트는 서비스 또는 콘텐츠 개요를 사용자들에게 제시하기 위해 단말기에 의해 이용되는 정보를 포함하여, 사용자들이 서비스 또는 콘텐츠가 무엇에 관한 것인지에 대한 일반적인 생각을 가질 수 있게 한다. PreviewData' 프래그먼트는 간단한 텍스트들, 정적 이미지들(예를 들어, 로고), 짧은 비디오 클립들, 또는 메인 서비스에 대한 낮은 비트 레이트 버전일 수 있을 다른 서비스에 대한 심지어 참조를 포함할 수 있다. 'Service', 'Content', 'PurchaseData', 'Access' 및 'Schedule' 프래그먼트들은 'PreviewData' 프래그먼트를 참조할 수 있다.

대화형 데이터(Interactivity Data) 프래그먼트(251)는 브로드캐스팅 동안 서비스, 스케쥴, 및 콘텐츠에 따라 대화형 서비스를 제공하는 데 이용될 수 있다. 서비스 가이드에 대한 더 상세한 정보는 시스템의 하나 이상의 엘리먼트 및 속성에 의해 정의될 수 있다. 따라서, InteractivityData 데이터는 방송 콘텐츠와 연관된 대화형 서비스들을 사용자에게 제공하기 위해 단말기에 의해 이용되는 정보를 포함한다. 이들 대화형 서비스들은 사용자가, 예를 들어, 텔레비전(TV) 쇼 동안에 투표할 수 있게 하거나 방송 콘텐츠에 관련된 콘텐츠를 획득할 수 있게 한다. 'InteractivityData' 프래그먼트는 xhtml 파일들, 정적 이미지들, 이메일 템플릿, 단문 메시지 서비스(Short Message Service: SMS) 템플릿, 멀티미디어 메시징 서비스(Multimedia Messaging Service: MMS) 템플릿 문서들 등을 포함하는 하나 또는 여러 개의 'InteractivityMedia' 문서를 가리킨다. 'InteractivityData' 프래그먼트는 'Service', 'Content' 및 'Schedule' 프래그먼트들을 참조할 수 있고, 'Schedule' 프래그먼트에 의해 참조될 수 있다.

'Schedule' 프래그먼트는 스트리밍, 다운로딩 및/또는 렌더링에 대해 연관된 콘텐츠 항목들이 이용가능한 시간프레임들을 정의한다. 이 프래그먼트는 'Service' 프래그먼트를 참조한다. 이것이 또한 하나 이상의 'Content' 프래그먼트 또는 '대화형데이터(InteractivityData)' 프래그먼트를 참조한다면, 이것은 서비스에 속하는 그 콘텐츠 항목들의 유효한 배포 및/또는 제시 시간프레임을, 또는 서비스와 연관된 대화형미디어문서들(InteractivityMediaDocuments)의 유효한 배포 시간프레임 및 자동 활성화 시간을 정의한다. 반면에, 'Schedule' 프래그먼트가 어떠한 'Content' 프래그먼트(들) 또는 'InteractivityData' 프래그먼트(들)도 참조하지 않는다면, 이것은 한정되지 않은 서비스 이용가능성의 시간프레임을 정의한다.

'Content' 프래그먼트는 특정한 콘텐츠 항목의 상세한 디스크립션을 제공한다. 콘텐츠의 타입, 디스크립션 및 언어를 정의하는 것 외에도, 이것은 장르 및 부모 등급 뿐만 아니라 타겟화된 사용자 그룹 또는 지리적 영역에 대한 정보를 제공할 수 있다. 'Content' 프래그먼트는 Schedule, PurchaseItem, 또는 'InteractivityData' 프래그먼트에 의해 참조될 수 있다. 이것은 'PreviewData' 프래그먼트 또는 'Service' 프래그먼트를 참조할 수 있다.

'PurchaseChannel' 프래그먼트는 'PurchaseData' 프래그먼트에서 정의된 바와 같이, 엔티티 - 이 엔티티로부터 소정 서비스, 서비스 번들 또는 콘텐츠 항목에 대한 액세스 및/또는 콘텐츠 권한들의 구매가 획득될 수 있음 - 에 대한 정보를 운반한다. 구매 채널은 하나 이상의 방송 가입 관리(Broadcast Subscription Managements: BSMs)와 연관된다. 단말기는 특정한 구매 채널이 그 구매 채널과 역시 연관되어 있는 BSM과 연계되어 있는 경우에만 그 특정한 구매 채널에 액세스하도록 허가될 수 있다. 다수의 구매 채널들이 하나의 'PurchaseData' 프래그먼트에 연관될 수 있다. 특정 최종 사용자는 구매 요청들이 지시되어야 하는 "선호되는" 구매 채널 (예를 들어, 그의 모바일 오퍼레이터)을 가질 수 있다. 선호되는 구매 채널은 최종 사용자가 이용하는 것이 허용된 유일한 채널일 수도 있다.

서비스가이드배달디스크립터(ServiceGuideDeliveryDescriptor)는 서비스 가이드 고지 채널에서 전송되며, 서비스 가이드(Service Guide) 발견 프로세스에서 Service Guide의 프래그먼트들의 이용가능성, 메타데이터 및 그룹화를 단말기에게 알려준다. SGDD는 단말기에 캐싱된 또는 전송중인 서비스 가이드(Service Guide) 프래그먼트들의 신속한 식별을 허용한다. 이러한 이유 때문에, SGDD는 방송 채널을 통해 배포되는 경우 바람직하게 반복된다. SGDD는 또한, 관련된 서비스 가이드 프래그먼트들의 그룹화를 제공하므로 이러한 그룹의 완성을 결정하는 수단을 제공한다. ServiceGuideDeliveryDescriptor는 단말기가 하나의 서비스 커버리지 영역으로부터 또 다른 영역으로 이동하는 경우 특히 유용하다. 이 경우, ServiceGuideDeliveryDescriptor은 이전 서비스 커버리지 영역에서 수신된 서비스 가이드 프래그먼트들 중 어느 것이 현재의 서비스 커버리지 영역에서 여전히 유효한지를 신속하게 체크하기 위해 이용될 수 있으므로, 재파싱 및 재처리될 필요가 없다.

명시적으로 도시되지는 않았지만, 서비스 가이드를 구성하는 프래그먼트들은 그들의 목적들을 이행하기 위한 엘리먼트 및 속성 값들을 포함할 수 있다. 또한, 서비스 가이드의 프래그먼트들 중 하나 이상은 원한다면 생략될 수 있다. 또한, 서비스 가이드의 하나 이상의 프래그먼트는 원한다면 결합될 수 있다. 또한, 서비스 가이드의 하나 이상의 프래그먼트의 상이한 양태들이, 원한다면, 함께 결합되거나, 재구성되거나, 달리 수정되거나 제한될 수 있다.

도 3을 참조하면, 예시적인 블록도는 서비스 가이드 배달 기술의 양태들을 나타낸다. 서비스 가이드 배달 디스크립터(Service Guide Deliver Descriptor: SGDD)(301)는 서비스 정보를 포함하는 모든 프래그먼트들에 관련된 세션 정보, 그룹화 정보, 및 통지 메시지 액세스 정보를 포함할 수 있다. 모바일 방송 서비스-가능형 단말기(105)는 켜지거나 서비스 가이드를 수신하기 시작할 때, 서비스 가이드 고지 채널(Service Guide Announcement Channel: SG Announcement Channel)(300)에 액세스할 수 있다.

SG 고지 채널(300)은 SGDD(301) (예를 들어, SGDD #1,..., SGDD #2, SGDD #3) 중 적어도 하나를 포함할 수 있는데, 이것은 Service Guide for Mobile Broadcast Services, Open Mobile Alliance, Version 1.0.1, January 09, 2013 및/또는 Service Guide for Mobile Broadcast Services, open Mobile Alliance, Version 1.1, October 29, 2013에 예시된 것과 같은 임의의 적절한 포맷으로 포맷될 수 있고, 이들 모두는 그 전체가 참조로 포함된다. 서비스 가이드 배달 디스크립터(301)를 구성하는 엘리먼트들 및 속성들의 디스크립션들은, 예를 들어, 테이블 포맷 및/또는 XML 스키마 등의, 임의의 적합한 포맷으로 반영될 수 있다.

실제 데이터는 바람직하게는 SGDD 프래그먼트(301)에 따라 XML 포맷으로 제공된다. 서비스 가이드에 관련된 정보는 2진 등의 다양한 데이터 포맷들로 제공될 수 있고, 여기서, 엘리먼트들 및 속성들은 방송 시스템에 따라 대응하는 값들로 설정된다.

단말기(105)는 SG 고지 채널(Announcement Channel)(300) 상에서 수신된 SGDD 프래그먼트의 DescriptorEntry로부터 프래그먼트 정보를 포함하는 서비스 가이드 배달 유닛(Service Guide Delivery Unit: SGDU)(312)에 대한 트랜스포트 정보를 취득할 수 있다.

서비스 가이드의 그룹화 정보를 제공할 수 있는 DescriptorEntry(302)는 "GroupingCriteria", "ServiceGuideDeliveryUnit", "Transport" 및 "AlternativeAccessURI"를 포함한다. 트랜스포트-관련 채널 정보는 "Transport" 또는 "AlternativeAccessURI"에 의해 제공될 수 있으며, 대응하는 채널의 실제 값은 "ServiceGuideDeliveryUnit"에 의해 제공된다. 또한, "서비스(Service)" 및 "장르(Genre)" 등의 SGDU(312)에 관한 상위 계층 그룹 정보는 "GroupingCriteria"에 의해 제공될 수 있다. 단말기(105)는 대응하는 그룹 정보에 따라 SGDU들(312)의 모두를 수신하여 사용자에게 제시할 수 있다.

일단 트랜스포트 정보가 취득되고 나면, 단말기(105)는 실제의 SGDU(312)를 수신하기 위해 SG 배달 채널(Service Guide (SG) Delivery Channel)(310) 상의 SGDD(301) 내의 DescriptorEntry(302)로부터 취득된 배달 채널들(Delivery Channels) 모두에 액세스할 수 있다. SG 배달 채널은 "GroupingCriteria"를 이용하여 식별될 수 있다. 시간 그룹화의 경우, SGDU는 시간별 SG 채널(311) 및 일별 SG 채널 등의 시간-기반의 트랜스포트 채널을 이용하여 전송될 수 있다. 따라서, 단말기(105)는 채널들에 선택적으로 액세스할 수 있고 대응하는 채널들에 존재하는 모든 SGDU들을 수신할 수 있다. 일단 전체 SGDU가 SG 배달 채널들(Delivery Channels)(310) 상에서 완전히 수신되고 나면, 단말기(105)는 SG 배달 채널들(Delivery Channels)(310) 상에서 수신된 SGDU들에 포함된 프래그먼트들을 모두 체크하고 그 프래그먼트들을 조립하여 시간별 기반(321)으로 세분될 수 있는 실제의 전체 서비스 가이드(SG)(320)를 스크린 상에 디스플레이한다.

종래의 모바일 방송 시스템에서, 서비스 가이드는 포맷팅되고 전송되어, 구성된 단말기들만이 대응하는 방송 시스템의 방송 신호들을 수신하게 한다. 예를 들어, DVB-H 시스템에 의해 전송된 서비스 가이드 정보는 DVB-H 방송을 수신하도록 구성된 단말기들에 의해서만 수신될 수 있다.

서비스 제공자들은 멀티플레이 서비스들이라 불릴 수 있는 서비스 융합에 따라 다양한 방송 시스템들 뿐만 아니라 다양한 전송 시스템들을 이용하는 번들링되고 통합된 서비스들을 제공한다. 방송 서비스 제공자들은 또한 IP 네트워크들 상에서 방송 서비스들을 제공할 수 있다. 통합된 서비스 가이드 전송 및/또는 수신 시스템들은 3GPP 표준들 및 OMA BCAST 표준들(예를 들어, 스킴)에서 정의된 엔티티들의 용어들을 이용하여 기술될 수 있다. 그러나, 서비스 가이드 송신 및/또는 수신 시스템들은 임의의 적절한 통신 및/또는 방송 시스템과 함께 이용될 수 있다.

도 4를 참조하면, 이 스킴은, 예를 들어, (1) 명칭; (2) 타입; (3) 카테고리; (4) 카디널리티; (5) 디스크립션; 및 (6) 데이터 타입을 포함할 수 있다. 스킴은, XML 포맷의 테이블 포맷 등의 임의의 방식으로 구성될 수 있다.

"명칭" 열은 엘리먼트 또는 속성의 명칭을 나타낸다. "타입" 열은 엘리먼트 또는 속성을 나타내는 인덱스를 나타낸다. 엘리먼트는 E1, E2, E3, E4, ..., E[n] 중 하나일 수 있다. E1은 전체 메시지 중 상위 엘리먼트를 나타내고, E2는 E1 아래의 엘리먼트를 나타내며, E3은 E2 아래의 엘리먼트를 나타내고, E4는 E3 아래의 엘리먼트를 나타내고, 등등이다. 속성은 A로 표시된다. 예를 들어, E1 아래의 "A"는 엘리먼트 E1의 속성을 의미한다. 일부 경우들에서, 표기법은 다음을 의미할 수 있다: E = 엘리먼트, A = 속성, E1 = 서브엘리먼트, E2 = 서브엘리먼트의 서브엘리먼트, E[n] = 엘리먼트[n-1]의 서브엘리먼트. "카테고리" 열은 엘리먼트 또는 속성이 필수인지를 나타내는 데 이용된다. 엘리먼트가 필수이면, 엘리먼트의 카테고리는 "M"으로 플래깅된다. 엘리먼트가 임의적이면, 엘리먼트의 카테고리는 "O"로 플래깅된다. 엘리먼트가 그것을 지원하는 네트워크에 대해 임의적이면, 그 엘리먼트는 "NO"로 플래깅된다. 엘리먼트가 그것을 지원하는 단말기에 대해 필수적이면, 그 엘리먼트는 "TM"으로 플래깅된다. 엘리먼트가 그것을 지원하는 네트워크에 대해 필수적이면, 그 엘리먼트는 "NM"으로 플래깅된다. 엘리먼트가 그것을 지원하는 단말기에 대해 임의적이면, 그 엘리먼트는 "TO"로 플래깅된다. 엘리먼트 또는 속성이 0보다 큰 카디널리티를 갖는다면, 이것은 일관성을 유지하기 위해 M 또는 NM으로 분류된다. "카디널리티" 열은 엘리먼트들 간의 관계를 나타내고, 0, 0 . . . 1, 1, 0 . . . n, 및 1 . . . n의 값으로 설정된다. 0은 옵션을 나타내고, 1은 필수적인 관계를 나타내며, n은 복수의 값들을 나타낸다. 예를 들면, 0 . . . n은 대응하는 엘리먼트가 전무의 또는 n개의 값들을 가질 수 있음을 의미한다. "디스크립션" 열은 대응하는 엘리먼트 또는 속성의 의미를 기술하고, "데이터 타입" 열은 대응하는 엘리먼트 또는 속성의 데이터 타입을 나타낸다.

서비스는 최종 사용자에게의 논리적 그룹을 형성하는 콘텐츠 항목들의 번들을 나타낼 수 있다. 한 예는, 수 개의 TV 쇼들로 구성된 TV 채널일 것이다. '서비스' 프래그먼트는 모바일 방송 서비스를 기술하는 메타데이터를 포함한다. '서비스' 프래그먼트와 연관된 '콘텐츠' 프래그먼트(들)에 동일한 메타데이터(즉, 속성들 및 엘리먼트들)가 존재하는 것이 가능하다. 이 상황에서, 다음과 같은 엘리먼트들: 'ParentalRating', 'TargetUserProfile', 'Genre' 및 'BroadcastArea'에 대해, '콘텐츠' 프래그먼트에 정의된 값들은 '서비스' 프래그먼트에 정의된 값들보다 우선한다.

이 프래그먼트의 프로그램 가이드 엘리먼트들은 프래그먼트 내의 프로그램 가이드의 시작(Start)과 프로그램 가이드 셀들의 끝 사이에서 그룹화될 수 있다. 프로그램 가이드의 엘리먼트들의 이러한 로컬화는 프로그래밍 가이드를 구성하는 데 있어서 수신 디바이스의 계산 복잡성을 감소시킨다. 프로그램 가이드 엘리먼트들은 일반적으로 사용자 해석에 이용된다. 이것은 콘텐츠 생성자가 서비스에 대한 사용자 판독가능한 정보를 제공할 수 있게 한다. 단말기는 최종 사용자에게 제시하기 위해 이 프래그먼트 내의 모든 선언된 프로그램 가이드 엘리먼트들을 이용해야 한다. 단말기는 검색, 소트 등의 기능들을 제공할 수 있다. 프로그램 가이드는 다음과 같은 서비스 엘리먼트들로 구성될 수 있다: (1) 명칭(Name); (2) 디스크립션(Description); (3) 오디오언어(AudioLanguage); (4) 텍스트언어(TextLanguage); (5) 부모등급(ParentalRating); (6) 타겟사용자프로파일(TargetUserProfile); 및 (7) 장르(Genre).

"명칭" 엘리먼트는 아마도 다수의 언어들로 서비스의 명칭을 지칭할 수 있다. 언어는 내장된 XML 속성 'xml:lang'을 이용하여 표현될 수 있다.

"디스크립션" 엘리먼트는 다수의 언어들로 되어 있을 수 있으며 내장된 XML 속성 'xml:lang'을 이용하여 표현될 수 있다.

"오디오언어(AudioLanguage)" 엘리먼트는 이 엘리먼트의 값에 의해 표현된 언어에 대응하는 오디오 트랙과 함께 이 서비스가 이용가능하다는 것을 최종 사용자들에게 선언할 수 있다. 이 엘리먼트의 텍스트 값은 상이한 언어들로 최종 사용자들에게 이용가능하게 될 수 있다. 이러한 경우, 이 엘리먼트의 값을 나타내는 데 이용된 언어는 내장된 XML 속성 'xml:lang'을 이용하여 시그널링될 수 있고, 복수 언어 지원을 포함할 수 있다. AudioLanguage는 languageSDPTag 속성을 포함할 수 있다.

"languageSDPTag" 속성은 세션 디스크립션 내의 오디오 트랙을 기술하는 미디어 섹션들에서 이용되는 부모 'AudioLanguage' 엘리먼트에 의해 기술된 오디오 언어의 식별자이다. 동일한 오디오 스트림을 선언하는 각각의 'AudioLanguage' 엘리먼트는 'languageSDPTag'와 동일한 값을 가질 수 있다.

"텍스트언어(TextLanguage)" 엘리먼트는 이 엘리먼트의 값에 의해 표현되는 언어로 이 서비스의 텍스트 컴포넌트들이 이용가능하다는 것을 최종 사용자에게 선언할 수 있다. 텍스트 컴포넌트들은 예를 들어, 자막 또는 부제목 트랙일 수 있다. 이 엘리먼트의 텍스트 값은 상이한 언어들로 최종 사용자들에게 이용가능하게 될 수 있다. 이러한 경우, 이 엘리먼트의 값을 나타내는 데 이용된 언어는 내장된 XML 속성 'xml:lang'을 이용하여 시그널링될 수 있고, 복수 언어 지원을 포함할 수 있다. 속성들 'languageSDPTag' 및 'xml:lang'을 할당하고 해석하는 엘리먼트 'AudioLanguage'에 대해 명시된 것들과 동일한 규칙들 및 제약들이 이 엘리먼트에 적용될 수 있다.

"languageSDPTag" 속성은 세션 디스크립션 내의 텍스트 트랙을 기술하는 미디어 섹션들에서 이용되는 부모 'TextLanguage' 엘리먼트에 의해 기술되는 텍스트 언어의 식별자이다.

"부모등급(ParentalRating)" 엘리먼트는 기준 부모들을 선언할 수 있고, 연관된 항목이 서비스 영역의 규제 요건들에 따라 정의된 자식들에 의한 액세스에 적합한지를 결정하는 데 이용될 수 있을 것이다. 단말기는 자유 스트링인 'ParentalRating'을 지원할 수 있고, 단말기는 '등급시스템(ratingSystem)' 및 '등급값명칭(ratingValueName)' 속성들을 이용하여 부모 등급 레벨을 표현하는 구조화된 방식을 지원할 수 있다.

"ratingSystem" 속성은 'ParentalRating' 엘리먼트의 값이 시맨틱적으로 정의된 어느 컨텍스트에서 이용 중인 부모 등급 시스템을 명시할 수 있다. 이것은 단말기들이 이용 중인 등급 시스템을 모호하지 않게 식별하고 적절하게 작동하는 것을 허용한다. 등급 시스템이 이용될 때 이 속성은 인스턴스화될 수 있다. 이 속성의 부재는 어떠한 등급 시스템도 이용되지 않는다는 것을 의미한다(즉, 'ParentalRating' 엘리먼트의 값은 자유 스트링으로서 해석될 것임).

"ratingValueName" 속성은 이 ParentalRating 엘리먼트에 의해 주어진 등급 값의 인간-판독가능한 명칭을 명시할 수 있다.

"타겟사용자프로파일(TargetUserProfile)"은 서비스의 타겟이 되는 사용자들의 엘리먼트들을 명시할 수 있다. 상세한 개인 속성 명칭들 및 대응하는 값들은 'attributeName' 및 'attributeValue'의 속성들에 의해 명시된다. 가능한 프로파일 속성 명칭들 중에는 연령, 장르, 직업 등이 있다 (존재하면 그리고 개인 프로파일링 정보 및 개인 데이터 프라이버시의 사용에 관하여 적용가능한 경우, 국가 및/또는 로컬 규칙들 및/또는 규정들에 구속받음). 특정한 서비스에 대한 'attributeName' 및 'attributeValue' 쌍들의 확장가능한 리스트는 최종 사용자 프로파일 필터링 및 방송 서비스들의 최종 사용자 선호사항 필터링을 가능하게 한다. 단말기는 'TargetUserProfile' 엘리먼트를 지원할 수 있을 수 있다. TargetUserProfile' 엘리먼트의 이용은 사용자들에 대한 "옵트-인(opt-in)" 능력일 수 있다. 단말기 설정들은 사용자들이, 자신들의 개인 프로파일 또는 선호사항을 입력할지 및 방송 서비스가 사용자들의 요청없이 사용자들의 개인 속성들에 기초하여 자동으로 필터링되게 허용할지를 구성하는 것을 허용할 수 있다. 이 엘리먼트는 다음과 같은 속성들을 포함할 수 있다: 속성명칭(attributeName) 및 속성값(attributeValue).

"attributeName" 속성은 프로파일 속성 명칭일 수 있다.

"attributeValue" 속성은 프로파일 속성 값일 수 있다.

"장르(Genre)" 엘리먼트는 특징적 형태와 연관된 서비스의 분류를 명시할 수 있다(예를 들어, 코미디, 드라마). OMA BCAST 서비스 가이드는 서비스 가이드에서 장르 엘리먼트의 포맷을 두가지 방식들로 기술하는 것을 허용할 수 있다. 제1 방식은 자유 스트링을 이용하는 것이다. 제2 방식은 장르 엘리먼트의 "href" 속성들을 이용하여 통제된 어휘의 형태로([TVA-Metadata(메타데이터)]에 정의된 분류 스킴 또는 동영상 장르-형태 가이드[Moving Image Genre-Form Guide (MIGFG)]에 정의된 분류 리스트) 정보를 전달하는 것이다. 내장된 XML 속성 xml:lang은 언어를 표현하기 위해 이 엘리먼트와 함께 이용될 수 있다. 네트워크는 '장르(Genre)' 엘리먼트의 수 개의 상이한 세트들을 인스턴스화할 수 있으며, 이를 자유 스트링으로서 이용하거나 또는 'href' 속성과 함께 이용한다. 네트워크는 상이한 세트들이 균등하고 상충되지 않는 의미를 가지도록 보장할 수 있으며, 단말기는 최종 사용자를 위해 해석하기 위해 세트들 중 하나를 선택할 수 있다. '장르(Genre)' 엘리먼트는 다음과 같은 속성들을 포함할 수 있다: 타입(type) 및 href.

"type" 속성은 예컨대 "메인(main)", "제2(second)" 및 "기타(other)"의 값들에 의해 'Genre' 엘리먼트의 레벨을 시그널링할 수 있다.

"href" 속성은 'Genre' 엘리먼트에서 이용된 통제된 어휘를 시그널링할 수 있다.

프로그래밍 가이드 엘리먼트들 및 속성들의 세트: (1) Name(명칭); (2) Description(디스크립션); (3) AudioLanguage; (4) TextLanguage; (5) ParentalRating; (6) TargetUserProfile; 및 (7) Genre(장르)를 검토한 후에, 수신 디바이스가 시청자에게 적절한 방식으로 정보를 적절히 렌더링하기에는 여전히 프로그래밍 가이드 내에 정의된 불충분한 정보를 가질 수 있다고 결정되었다. 특히, 전통적인 NTSC(National Television System Committee) 텔레비전 방송국들은 전형적으로 예컨대 2, 4, 6, 8, 12, 및 49의 숫자들을 가지고 있다. 디지털 서비스들의 경우, 프로그램 및 시스템 정보 프로토콜은 지상 브로드캐스팅의 경우, 주 채널 및 후속되는 부 채널로 구성된 2-부분 번호로 각각의 디지털 텔레비전 서비스를 정의하는 가상 채널 테이블을 포함한다. 주 채널 번호는 대개 방송국에 대한 NTSC 채널과 동일하고, 부 채널들은 얼마나 많은 디지털 텔레비전 서비스들이 디지털 텔레비전에 존재하는지에 따른 다수의 숫자들 - 전형적으로 1부터 시작함 - 을 갖는다. 예를 들어, Washington, D.C.의 아날로그 텔레비전 채널 9인 WUSA-TV는 다음과 같은 그것의 2개의 공중파 디지털 서비스들을 식별할 수 있다: 채널 9-1 WUSA-DT 및 채널 9-2 9-Radar. 텔레비전 채널들에 대한 이러한 표기는 시청자가 쉽게 이해할 수 있고, 프로그래밍 가이드 엘리먼트들은 프로그래밍 가이드에 대한 확장으로서 이 능력을 포함할 수 있어서, 정보가 계산상 효율적으로 수신 디바이스에 의해 처리되어 시청자에게 렌더링될 수 있게 한다.

도 5를 참조하면, 이러한 유연성을 용이화하기 위해, 서비스미디어확장(ServiceMediaExtension)과 같은 확장이 프로그래밍 가이드 엘리먼트들과 함께 포함될 수 있으며, 이는 추가 서비스들을 명시할 수 있다. 특히, ServiceMediaExtension은 타입 엘리먼트 E1, 카테고리 NM/TM을 가질 수 있으며, 카디널리티가 1이다. 주 채널은 MajorChannelNum이라고 지칭될 수 있고, 타입 엘리먼트 E2, 카테고리 NM/TM, 카디널리티 0..1, 및 스트링의 데이터 타입을 갖는다. unsignedByte가 아닌 스트링의 데이터 타입을 포함함으로써, 반드시 숫자가 아닐 수도 있는 다른 언어들의 지원을 허용한다. ServiceMediaExtension을 포함하는 프로그램 가이드 정보는 예를 들어, ATSC(Advanced Televsion Systems Committee)와 같은 임의의 적절한 방송 시스템에 포함될 수 있다.

프로그래밍 가이드 엘리먼트들 및 속성들의 세트: (1) Name; (2) Description; (3) AudioLanguage; (4) TextLanguage; (5) ParentalRating; (6) TargetUserProfile; and (7) Genre를 추가로 검토한 후에; 수신기 디바이스가 시청자에 적합한 방식으로 정보를 적절하게 렌더링하기에 적합한 정보를 여전히 불충분하게 가질 수 있다고 결정되었다. 많은 경우들에서, 시청자는 그래픽 아이콘을 특정한 프로그램 및/또는 채널 및/또는 서비스와 연관시킨다. 이러한 방식으로, 그래픽 아이콘은 선택불가능이 아니라 시스템에 의해 선택가능해야 한다.

도 6을 참조하면, 이러한 유연성을 용이화하기 위해, 아이콘을 명시할 수 있는 프로그래밍 가이드 엘리먼트를 갖는 확장이 포함될 수 있다.

프로그래밍 가이드 엘리먼트들 및 속성들의 세트: (1) Name; (2) Description; (3) AudioLanguage; (4) TextLanguage; (5) ParentalRating; (6) TargetUserProfile; 및 (7) Genre를 더 추가로 검토한 후에; 수신기 디바이스가 시청자에 적합한 방식으로 정보를 적절하게 렌더링하기에 적합한 정보를 여전히 불충분하게 가질 수 있다고 결정되었다. 많은 경우들에서, 시청자는 동일한 확장 엘리먼트들을 이용하여 식별되는 특정한 확장을 식별하려고 할 수 있다. 이러한 방식으로, 확장의 엘리먼트들의 특정한 디스크립션을 구체적으로 식별하기 위해 url이 이용될 수 있다. 이러한 방식으로, 확장의 엘리먼트들은 다수의 상이한 확장들을 명시적으로 기술할 필요없이 적절한 방식으로 수정될 수 있다.

도 7을 참조하면, 이러한 유연성을 용이화하기 위해, url을 명시할 수 있는, 프로그래밍 가이드 엘리먼트들을 갖는 확장이 포함될 수 있다.

도 8을 참조하면, 이 전반적인 확장 유연성을 용이화하기 위해, 확장은 아이콘, 주 채널 번호, 부 채널 번호, 및/또는 url을 명시할 수 있는, 프로그래밍 가이드 엘리먼트들을 가지고 포함될 수 있다.

다른 실시예들에서, MajorChannelNum 및 MinorChannelNum 엘리먼트들에 대해 "스트링" 데이터 타입을 이용하는 것 대신에, 다른 데이터 타입이 이용될 수도 있다. 예를 들어, unsignedInt 데이터 타입이 이용될 수도 있다. 다른 예에서, 제한된 길이의 스트링, 예를 들어, 10자리의 스트링이 이용될 수도 있다. 상기의 확장을 위한 XML 스키마 신택스의 예가 아래에 예시된다.

일부 실시예들에서, ServiceMediaExtension은 OMA "확장" 엘리먼트 내에 포함될 수 있거나, 일반적으로 ServiceMediaExtension을 정의하기 위한 OMA 확장 메커니즘을 이용할 수 있다.

일부 실시예들에서, MajorChannelNum 및 MinorChannelNum은 하나의 공통 채널 번호로 결합되어 표현될 수 있다. 예를 들어, ChannelNum 스트링은 MajorChannelNum, 후속의 마침표('.'), 및 후속의 MinorChannelNum을 연결함(concatenating)으로써 생성될 수 있다. 기타의 그러한 조합들이 마침표를 다른 문자들로 대체함으로써 또한 가능하다. MajorChannelNum 및 MinorChannelNum을 하나의 숫자 표현으로 결합하는 것으로 채널 번호들을 표현하기 위해 unsignedInt 또는 다른 데이터 타입들을 이용할 때 유사한 개념이 적용될 수 있다.

또 다른 실시예에서, MajorChannelNum.MinorChannelNum은 서비스에 대한 "ServiceId" 엘리먼트(Service Id)로서 표현될 수 있을 것이다.

다른 실시예에서, ServiceMediaExtension은 서비스 프래그먼트 내의 PrivateExt 엘리먼트 내부에서만 이용될 수 있다. 이러한 확장을 위한 예시적인 XML 스키마 신택스가 아래에 예시된다.

다른 실시예들에서, 상기 엘리먼트들 중 일부는 E2로부터 E1로 변경될 수 있다. 다른 실시예들에서 일부 엘리먼트의 카디널리티가 변경될 수 있다. 또한, 원한다면, 카테고리는, 카디널리티를 가지고 포함된 정보와 일반적으로 중복되므로 생략될 수 있다.

ATSC 서비스 엘리먼트들 및 속성들의 선택된 컴포넌트들을 OMA 서비스 가이드 서비스 프래그먼트 프로그램 가이드에 맵핑하는 것이 바람직하다. 예를 들어, OMA 서비스 가이드 프래그먼트 프로그램 가이드의 "디스크립션(Description)" 속성은, 예를 들어, ATSC-모바일 디지털 TV(Mobile Digital Television)(DTV) 표준, 파트 4 - 고지(Announcement), 유사한 엘리먼트들 및 속성들에 대한 기타의 유사한 방송 또는 모바일 표준들과 같은, ATSC 서비스 엘리먼트들 및 속성들의 "디스크립션(Description)"에 매핑될 수 있다. 예를 들어, OMA 서비스 가이드 프래그먼트 프로그램 가이드의 "장르(Genre)" 속성은, 예를 들어 ATSC-모바일 DTV 표준, 파트 4 - 고지, 유사한 엘리먼트들 및 속성들에 대한 기타의 유사한 표준들과 같은, ATSC 서비스 엘리먼트들 및 속성들의 "장르(Genre)"에 매핑될 수 있다. 일 실시예에서 ATSC A153 파트 4의 섹션 6.10.2에 정의된 바와 같은 장르 스킴이 이용될 수 있다. 예를 들어, OMA 서비스 가이드 프래그먼트 프로그램 가이드의 "명칭(Name)" 속성은 예를 들어, ATSC-모바일 DTV 표준, 파트 4-고지, 유사한 엘리먼트들 및 속성들에 대한 다른 유사한 표준들과 같은, ATSC 서비스 엘리먼트들 및 속성들의 "명칭(Name)"에 맵핑될 수 있다. 바람직하게는, 명칭의 카디널리티는 0..N으로 선택되고, 이것은 명칭의 생략을 허용하여 시스템의 전체 비트 레이트를 줄이고 유연성을 증가시킨다. 예를 들어, OMA 서비스 가이드 프래그먼트 프로그램 가이드의 "ParentalRating" 속성은 예를 들어, ATSC-모바일 DTV 표준, 파트 4-고지, 또는 유사한 엘리먼트들 및 속성들에 대한 유사한 표준들과 같은, ATSC 서비스 엘리먼트 및 속성들의 새로운 "ContentAdvisory"에 매핑될 수 있다. 예를 들어, OMA 서비스 가이드 프래그먼트 프로그램 가이드의 "TargetUserProfile" 속성은 예를 들어, ATSC-모바일 DTV 표준, 파트 4-고지, 또는 유사한 엘리먼트들 및 속성들에 대한 유사한 표준들과 같은, ATSC 서비스 엘리먼트 및 속성들의 새로운 "Personalization"에 매핑될 수 있다.

도 9a, 도 9b, 및 도 9c를 참조하면, 세션 디스크립션 프래그먼트(Session Description Fragment)가 예를 들어, ATSC-모바일 DTV 표준, 파트 4 - 고지, 또는 유사한 엘리먼트들 및 속성들에 대한 유사한 표준들과 같은 서비스 고지에 포함된다면, 엘리먼트들 AudioLanguage(languageSDPTag 속성을 가짐) 및 TextLanguage(languageSDPTag 속성을 가짐)가 포함될 수 있을 것이다. 이는 왜냐하면 엘리먼트들 AudioLanguage 및 TextLanguage에 대한 속성 languageSDPTag가 바람직하게는 필수이기 때문이다. 속성은 세션 디스크립션에서 오디오 및/또는 텍스트 트랙을 기술하는 미디어 섹션들에서 이용되는 부모 엘리먼트에 의해 기술된 오디오 및/또는 텍스트 언어에 대한 식별자를 제공한다. 다른 실시예에서, languageSDPTag 속성은 임의적이 될 수 있을 것이고, 엘리먼트들 AudioLanguage 및 TextLanguage는 언어 명칭을 제공할 수 있는 데이터 타입 "스트링"을 갖는 속성 "Language"를 가지고 포함될 수 있다.

이에 대한 예시적인 XML 스키마 신택스는 아래에 나타내어진다.

다른 실시예에서, 엘리먼트들 AudioLanguage 및 TextLanguage에 대한 속성들 languageSDPTag는 제거될 수 있을 것이다. 이에 대한 예시적인 XML 스키마 신택스는 아래에 나타내어진다.

도 10a, 도 10b, 및 도 10c를 참조하면, 세션 디스크립션 프래그먼트(Session Description Fragment)가 예를 들어, ATSC-모바일 DTV 표준, 파트 4 -고지, 또는 유사한 엘리먼트들 및 속성들에 대한 유사한 표준들과 같은, 서비스 고지에 포함된다면, 엘리먼트들 AudioLanguage(languageSDPTag 속성을 가짐) 및 TextLanguage(languageSDPTag 속성을 가짐)가 포함될 수 있을 것이다. 이는 왜냐하면 엘리먼트들 AudioLanguage 및 TextLanguage에 대한 속성 languageSDPTag가 바람직하게는 필수이기 때문이다. 속성은 세션 디스크립션에서 오디오 및/또는 텍스트 트랙을 기술하는 미디어 섹션들에서 이용되는 부모 엘리먼트에 의해 기술된 오디오 및/또는 텍스트 언어에 대한 식별자를 제공한다. 다른 실시예에서, 속성 languageSDPTag는 옵션이 될 수 있다.

이에 대한 예시적인 XML 스키마 신택스는 아래에 나타내어진다.

다른 실시예에서, 엘리먼트들 AudioLanguage 및 TextLanguage에 대한 속성들 languageSDPTag는 제거될 수 있을 것이다. 이에 대한 예시적인 XML 스키마 신택스는 아래에 나타내어진다.

다른 실시예에서, 속성 "language"는 ATSC 서비스 "언어(language)" 엘리먼트에 매핑될 수 있을 것이고 서비스의 프라이머리 언어를 지칭할 수 있을 것이다.

다른 실시예에서, 엘리먼트 "AudioLanguage"의 값은 ATSC 서비스 "language" 엘리먼트에 매핑될 수 있을 것이고 ATSC에서 오디오 서비스의 프라이머리 언어를 지칭할 수 있을 것이다.

다른 실시예에서, 엘리먼트 "TextLanguage"의 값은 ATSC 서비스 "language" 엘리먼트에 매핑될 수 있을 것이고 ATSC에서 텍스트 서비스의 프라이머리 언어를 지칭할 수 있을 것이다. 일부 경우들에서, 텍스트 서비스는 폐쇄 자막 서비스 등의 서비스일 수 있다. 다른 실시예에서, 엘리먼트들 AudioLanguage 및 TextLanguage 및 그들의 속성들은 제거될 수 있을 것이다.

서비스 가이드의 경우, 전통적으로 일반적으로 "선형 서비스" 라고 지칭되는 오디오-비주얼 콘텐츠의 선형 스트림을 참조하는 고려가 있었다. 일반적으로 "앱들(apps)"이라고 지칭되는 애플리케이션들의 급증으로, 실행되는 다른 프로그램들인 앱 기반 (예를 들어, 애플리케이션 기반) 서비스들을 참조하고, 일반적으로 "앱-기반 서비스"라고 지칭되는 서비스를 사용자에게 제공하는 것이 바람직하다. OMA 서비스 가이드 프래그먼트 프로그램 가이드의 통지 ServiceType 엘리먼트(7)를 이용하여 "선형 서비스" 또는 "앱-기반 서비스"의 통지 스트림을 매핑하는 것이 바람직하다.

OMA 서비스 가이드 프래그먼트 프로그램 가이드의 ServiceType 엘리먼트를 이용하여 다른 서비스의 통지를 가능하게 하는 것이 또한 바람직하다. ServiceType은 추가적인 서비스 타입들을 포함하기 위해 "독점적 이용을 위해 예약된" 범위를 이용할 수 있다. 예를 들어, ServiceType 엘리먼트 값(224)은 이용될 애플리케이션 컴포넌트를 포함하는 앱-기반 서비스(App-Based Service)를 식별하는 데 이용될 수 있다. 예를 들어, ServiceType 엘리먼트 값(225)은 이용될 비-실시간 콘텐츠를 포함하는 "앱-기반 서비스(App-Based Service)" 를 식별하는 데 이용될 수 있다. 예를 들어, ServiceType 엘리먼트 값(226)은 이용될 주문형 컴포넌트를 포함하는 "앱-기반 서비스(App-Based Service)"를 식별하는 데 이용될 수 있다. 이러한 방식으로, 이들 앱-기반 서비스들은 Notification(통지) ServiceType 엘리먼트(7)에 맵핑되고, 따라서 Notification ServiceType 엘리먼트(7)가 그들의 존재를 나타내지 않을 때 용이하게 생략됨으로써, 비트스트림의 복잡성을 감소시킨다.

다른 실시예에서, OMA ServiceType에 대해 통지를 값(7)에 맵핑하는 것이 아니라, 추가적인 ServiceType 값이 정의될 수 있다. OMA 서비스 가이드 프래그먼트 프로그램 가이드의 Notification ServiceType 엘리먼트(227)는 통지 스트림 컴포넌트를 포함하는 이용될 애플리케이션 컴포넌트를 포함하는 "앱-기반 서비스" 를 식별하는 데 이용될 수 있다.

설명된 서비스들에 대해 다른 값들이 마찬가지로 이용될 수 있다는 것을 이해해야 한다. 예를 들어, 상기 서비스 타입 값들(224, 225, 226, 및 227) 대신에, 서비스 타입 엘리먼트 값(240, 241, 242, 243)이 이용될 수 있다. 다른 경우에, 서비스 타입 값들(129, 130, 131, 132)이 대신 이용될 수 있다.

또 다른 실시예에서, 독점적 이용을 위해 예약된 범위(128-255)로부터의 ServiceType 값들을 이용하는 것 대신에, 미래의 이용을 위해 예약된 범위(11-127)로부터의 값들이 이용될 수 있다.

또 다른 실시예에서, OMA BCAST 가이드(Guide) 1.1을 이용할 때 독점적 이용을 위해 예약된 범위(128-255)로부터의 ServiceType 값들을 이용하는 것 대신에, 미래의 이용을 위해 예약된 범위(14-127)로부터의 값들이 이용될 수 있다.

또 다른 실시예에서, OMA BCAST 가이드 1.1을 이용할 때 독점적 이용을 위해 예약된 범위(128-255)의 ServiceType 값들을 이용하는 것 대신에, 다른 OMA 인에이블러들을 위해 예약된 범위(128-223)의 값들이 이용될 수 있다.

다른 실시예에서, OMA BCAST 가이드 1.1을 이용할 때 독점적 이용을 위해 예약된 범위(128-255)의 ServiceType 값들을 이용하는 것 대신에, 값들은 다른 OMA 인에이블러들을 위해 예약된 범위(224-255) 내로 제한되어 이용될 수 있다.

다른 실시예에서, 예를 들어, 추가적인 ServiceType 엘리먼트 값(228)이 "선형 서비스"를 식별하기 위해 이용될 수 있다. 예를 들어, 일반화된 애플리케이션 기반 향상을 포함하는 "앱-기반 서비스"를 식별하기 위해 추가적인 ServiceType 엘리먼트 값(229)이 이용될 수 있다. 이러한 방식으로, 서비스 라벨링은 애플리케이션 컴포넌트, 비-실시간 콘텐츠, 또는 주문형 컴포넌트에 대한 서비스 타입을 명시적으로 포함하지 않음으로써 단순화된다.

다른 실시예에서, 예를 들어, 애플리케이션 기반 향상을 포함하는 "앱-기반 서비스"를 식별하기 위해 추가적인 또는 대안적인 ServiceType 엘리먼트 값(230)이 이용될 수 있다. 이러한 방식으로, 통지는 선형 서비스, 애플리케이션 컴포넌트, 비-실시간 콘텐츠, 또는 주문형 컴포넌트에 대한 서비스 타입을 명시적으로 포함하지 않음으로써 더 단순화된다.

다른 실시예에서, 예를 들어, ServiceType 엘리먼트 값(1)은 또한 "선형 서비스"를 식별하기 위해 이용될 수 있다. 이러한 방식으로, 선형 엘리먼트(Linear Element)는 기존 신택스 구조 내에 통합된다. 이 경우에, "선형 서비스"는 기본 TV 서비스(Basic TV service)에 매핑된다.

다른 실시예에서, 예를 들어, ServiceType 엘리먼트 값(11)은 주문형 컴포넌트를 포함한 앱-기반 향상을 수반한 앱-기반 서비스일 수 있는, 스트리밍 주문형 컴포넌트(streaming on demand component)를 식별하는 데 이용될 수 있다. 예를 들어, ServiceType 엘리먼트 값(12)은 비-실시간 콘텐츠 항목 컴포넌트를 포함한 앱-기반 향상일 수 있는, 파일 다운로드 주문형 컴포넌트(file download on demand component)를 식별하는 데 이용될 수 있다.

다른 실시예에서, 상기 서비스 타입 값들 중 임의의 하나는 다른 엘리먼트 내의 값에 의해 표시될 수 있다. 예를 들어, AvailableContent 엘리먼트 또는 속성 및 그것의 값은, 애플리케이션 컴포넌트, 비-실시간 콘텐츠, 주문형 컴포넌트, 및/또는 통지로부터의 값들 중 하나를 취할 수 있을 것이다.

다른 실시예에서, ServiceType 값 할당은 계층적으로 이루어질 수 있다. 예를 들어, 메인 서비스 타입들은 선형 서비스 및 앱-기반 서비스일 수 있고, 이들 2가지 서비스 타입들 각각은, 애플리케이션 컴포넌트, 비-실시간 콘텐츠, 주문형 컴포넌트, 및/또는 통지를 포함할 수 있는 0개 이상의 앱-기반 향상 컴포넌트를 포함할 수 있고, ServiceType 값들의 계층적 할당이 이루어질 수 있다. 이 경우에, "ServiceType"에 대해 "unsigned Byte" (ServiceType의 날짜 타입)의 비트들 중 하나는 선형 서비스 (1로 설정된 값을 갖는 비트) 또는 앱-기반 서비스 (0으로 설정된 값을 갖는 비트)를 시그널링하도록 사용될 수 있을 것이다. 그 다음, 나머지 비트들이 서비스 타입들을 시그널링할 수 있다.

예가 다음과 같이 예시된다 :

일반 서비스 타입이란, 애플리케이션 컴포넌트 또는 비-실시간 콘텐츠, 또는 주문형 컴포넌트를 갖는 서비스와는 상이한 서비스를 지칭할 수 있다. 일부 경우에, 일반 서비스 타입은 "미지" 서비스 타입일 수 있다.

또 다른 실시예에서, 값들은 연속적인 ServiceType 값들을 이용할 수 있다. 예를 들어, 서비스 타입 값들은 다음과 같이 할당될 수 있을 것이다 :

또 다른 실시예에서, 선형 및/또는 앱-기반 서비스: 앱(App)은 다음과 같이 2가지 서비스 타입들(따라서 총 4가지 서비스 타입들)로 더 분할될 수 있다 :

프라이머리 앱은 기초 서비스가 선택되자마자 활성화되는 앱일 수 있다. 또한, 비-프라이머리 앱들은 서비스에서 나중에 시작될 수 있다.

일부 실시예들에서, 타입 선형 서비스(Linear Service)의 서비스: 주문형 컴포넌트가 금지될 수 있다. 그 경우에, 그 타입의 서비스에 대해 어떠한 ServiceType 값도 할당되지 않을 수 있다.

서비스 시그널링과 관련된 추가적인 실시예들이 다음과 같이 설명된다. 일반적으로, 서비스 고지 및 서비스 시그널링은 다음과 같을 수 있다. 서비스 고지는 시청자 또는 사용자가 서비스 또는 콘텐츠에 대한 통보된 선택을 행하게 허용하도록 설계된 프로그래밍 및 서비스들에 관한 정보를 포함할 수 있다. 서비스 시그널링은 수신기가 서비스들을 찾고 획득할 수 있게 하고 서비스의 기본적인 내비게이션을 수행할 수 있게 하는 정보를 포함할 수 있다.

도 11을 참조하면, 컴포넌트 정보 디스크립션 시그널링이 설명된다. 전송 서비스 제공자(1100)는 텔레비전 서비스들이 제공될 수 있도록 구성된 서비스의 제공자의 예이다. 예를 들어, 전송 서비스 제공자(1100)는 오버-디-에어 텔레비전 네트워크들, 공중 또는 가입-기반 위성 텔레비전 서비스 제공자 네트워크들, 공중 오버-더-톱 서비스 네트워크들, 방송 서비스 네트워크들, 및 공중 또는 가입-기반 케이블 텔레비전 제공자 네트워크들을 포함할 수 있다. 일부 예들에서, 전송 서비스 제공자(1100)는 주로 텔레비전 서비스들이 제공될 수 있게 하는데 이용될 수 있지만, 전송 서비스 제공자(1100)는 또한, 본 명세서에서 디스크립션된 전자통신 프로토콜들 및 메시지들의 임의의 조합에 따라 다른 타입들의 데이터 및 서비스들이 제공될 수 있게 할 수 있다는 점에 유의해야 한다. 전송 서비스 제공자(1100)는 무선 및/또는 유선 통신 매체의 임의의 조합을 포함할 수 있다. 전송 서비스 제공자(1100)는 동축 케이블들, 광섬유 케이블들, 트위스티드 페어 케이블들(twisted pair cables), 무선 전송기들 및 수신기들, 라우터들, 스위치들, 리피터들, 기지국들, 또는 다양한 디바이스들과 사이트들 사이의 통신들을 가능하게 하는 데 유용할 수 있는 임의의 다른 장비를 포함할 수 있다.

도 11을 참조하면, 수신기(1140)는 전송 서비스 제공자(1100)로부터 서비스를 수신하도록 구성된 임의의 디바이스를 포함할 수 있다. 예를 들어, 수신기(1140)는 유선 및/또는 무선 통신들을 위해 구비될 수 있고, 소위 스마트 텔레비전들, 셋탑 박스들, 및 디지털 비디오 레코더들을 포함한 텔레비전들을 포함할 수 있다. 또한, 수신기(1140)는 데스크탑, 랩탑 또는 태블릿 컴퓨터들, 게임 콘솔들, 예를 들어, 스마트폰들, 셀룰러 전화기들, 및 전송 서비스 제공자(1100)로부터 서비스를 수신하도록 구성된 개인용 게임 디바이스를 포함하는 모바일 디바이스들을 포함할 수 있다.

전송 서비스 제공자(1100)로부터 서비스의 수신의 일부로서, 수신기 (1140)는 배달 메커니즘을 통해 수신될 수 있는 다양한 미디어 스트림들 및 데이터에 관한 정보를 제공할 수 있는 시그널링 정보를 수신할 수 있다. 일 실시예에서, 전송 서비스 제공자(1100)로부터의 시그널링 정보는 컴포넌트 정보 디스크립션(1110)을 포함할 수 있다. 컴포넌트 정보 디스크립션의 예는 도 13a, 도 13b, 도 15, 및 도 17과 관련하여 나중에 제공된다. 이 컴포넌트 정보 디스크립션(1110)을 수신한 후, 수신기 (1140)는 그것을 파싱 또는 디코딩할 수 있다. 일 예에서, 수신기(1140) 는 컴포넌트 정보 디스크립션 (1110)을 파싱할 때까지 추가 시그널링 정보를 파싱할 수 없을 수 있다. 일 예에서, 수신기(1140)는 컴포넌트 정보 디스크립션(1110)의 일부 또는 전부를 디코딩(decoding), 파싱 및 렌더링한(rendering) 후에 시청자에게 디스플레이할 수 있다. 일부 경우들에서, 그것은 이 정보를 시청자에 의해 시청될 수 있는 수신기 디바이스의 스크린 상에 디스플레이할 수 있다. 예시적인 경우에, 시청자는 수신, 파싱 및 디스플레이되는 이 정보에 기초하여 결정을 할 수 있다. 일 예에서, 결정은 서비스의 하나 이상의 컴포넌트를 수신하는 것일 수 있다. 이 경우에, 수신기(1140) 는 서비스의 하나 이상의 컴포넌트에 대한 컴포넌트 배달 요청(1120)을 전송 서비스 제공자(1100)에게 송신할 수 있다. 일 예에서, 수신기(1140)는 전송 서비스(1110)로부터 요청된 컴포넌트들의 배달을 수신할 수 있다.

도 12를 참조하면, 채널 정보 디스크립션 시그널링이 기술된다. 전송 서비스 제공자(1200) 는 텔레비전 서비스가 제공될 수 있도록 구성된 서비스의 제공자의 일 예이다. 예를 들어, 전송 서비스 제공자(1200)는 오버-디-에어 텔레비전 네트워크들, 공중 또는 가입 기반 위성 텔레비전 서비스 제공자 네트워크들, 오버-더-톱 서비스 네트워크들, 방송 서비스 네트워크들, 및 공중 또는 가입-기반 케이블 텔레비전 제공자 네트워크들을 포함할 수 있다. 일부 예들에서, 전송 서비스 제공자(1200)는 주로 텔레비전 서비스들이 제공될 수 있게 하는 데 이용될 수 있지만, 전송 서비스 제공자(1200)는 또한, 본 명세서에서 디스크립션된 전자통신 프로토콜들 및 메시지들의 임의의 조합에 따라 다른 타입들의 데이터 및 서비스들이 제공될 수 있게 할 수 있다는 점에 유의해야 한다. 전송 서비스 제공자(1200)는 무선 및/또는 유선 통신 매체의 임의의 조합을 포함할 수 있다. 전송 서비스 제공자(1200)는 동축 케이블들, 광섬유 케이블들, 트위스티드 페어 케이블들, 무선 전송기들 및 수신기들, 라우터들, 스위치들, 리피터들, 기지국들, 또는 다양한 디바이스들과 사이트들 사이의 통신들을 가능하게 하는 데 유용할 수 있는 임의의 다른 장비를 포함할 수 있다.

도 12를 참조하면, 수신기(1240) 는 전송 서비스 제공자(1200)로부터 서비스를 수신하도록 구성된 임의의 디바이스를 포함할 수 있다. 예를 들어, 수신기(1240) 는 유선 및/또는 무선 통신들을 위해 구비될 수 있고, 소위 스마트 텔레비전들, 셋탑 박스들, 및 디지털 비디오 레코더들을 포함한 텔레비전들을 포함할 수 있다. 또한, 수신기(1240)는 데스크탑, 랩탑 또는 태블릿 컴퓨터들, 게임 콘솔들, 예를 들어, 스마트폰들, 셀룰러 전화기들, 및 전송 서비스 제공자 (1200)로부터 서비스를 수신하도록 구성된 개인용 게임 디바이스를 포함하는 모바일 디바이스들을 포함할 수 있다.

전송 서비스 제공자(1200)로부터 서비스의 수신의 일부로서, 수신기(1240)는 배달 메커니즘을 통해 수신될 수 있는 다양한 미디어 스트림들 및 데이터에 관한 정보를 제공할 수 있는 시그널링 정보를 수신할 수 있다. 일 실시예에서, 전송 서비스 제공자(1200)로부터의 시그널링 정보는 채널 정보 디스크립션(1210)을 포함할 수 있다. 채널 정보 디스크립션의 예는 도 14a, 도 14b, 도 16, 및 도 18과 관련하여 나중에 제공된다. 이 채널 정보 디스크립션(1210) 을 수신한 후, 수신기(1240)는 그것을 파싱 또는 디코딩할 수 있다. 일 예에서, 수신기(1240)는 채널 정보 디스크립션 (1210)을 파싱할 때까지 추가 시그널링 정보를 파싱할 수 없을 수 있다. 일 예에서, 수신기(1240)는 채널 정보 디스크립션(1210)의 일부 또는 전부를 디코딩, 파싱 및 렌더링한 후에 시청자에게 디스플레이할 수 있다. 일부 경우들에서, 그것은 이 정보를 시청자에 의해 시청될 수 있는 수신기 디바이스(1240)의 스크린 상에 디스플레이할 수 있다. 예시적인 경우에, 시청자는 수신, 파싱 및 디스플레이되는 이 정보에 기초하여 결정을 할 수 있다. 일 예에서, 결정은 서비스의 채널을 수신하는 것일 수 있다. 이 경우에, 수신기(1240)는 서비스에 대한 채널 배달 요청(1220)을 전송 서비스 제공자(1200)에게 송신할 수 있다. 일 예에서, 수신기(1240)는 전송 서비스 제공자(1200)로부터 채널의 배달을 수신할 수 있다.

도 13a 내지 도 13b는 컴포넌트 정보 디스크립터에 대한 바이너리 신택스를 나타낸다.

도 13b는 도 13a와 비교하여 더 적은 신택스 엘리먼트들을 포함하고, 따라서 전송 서비스 제공자(1100)에 의해 송신하기가 더 쉬울 수 있으며, 수신기 (1140)에 의해 파싱 및 디코딩하기 더 쉬울 수 있다.

도 13a 및 도 13b의 컴포넌트 정보 디스크립터는 서비스에서 이용가능한 컴포넌트들에 대한 정보를 제공한다. 이것은 서비스에서 이용가능한 컴포넌트들의 수에 관한 정보를 포함한다. 각각의 이용가능한 컴포넌트에 대해, 다음의 정보가 시그널링된다: 컴포넌트 타입, 컴포넌트 역할, 컴포넌트 명칭, 컴포넌트 식별자, 컴포넌트 보호 플래그. 오디오, 비디오, 폐쇄 자막 및 애플리케이션 컴포넌트들이 시그널링될 수 있다. 컴포넌트 역할 값들은 오디오, 비디오 및 폐쇄 자막 컴포넌트들에 대해 정의된다.

컴포넌트 정보 디스크립터에 대한 신택스는 도 13a 또는 도 13b에 도시된 신택스에 부합할 수 있다. 다른 실시예에서, 컴포넌트 정보 디스크립터의 전부 대신, 컴포넌트 정보 디스크립터에서의 엘리먼트들 중 일부만이 컴포넌트 정보 디스크립터에서 또는 일부 다른 디스크립터 또는 일부 다른 데이터 구조 내에서 시그널링될 수 있다.

도 13a 및 도 13b의 컴포넌트 정보 디스크립터에서의 신택스 엘리먼트들의 시맨틱 의미는 다음과 같을 수 있다.

descriptor_tag - 이것은 이 디스크립터를 식별하기 위한 8-비트 부호없는 정수이다. 이 디스크립터를 고유하게 식별하는 0-255 사이의 임의의 적절한 값이 시그널링될 수 있다. 일 실시예에서, 이 필드의 포맷은 uimsbf일 수 있다. 다른 실시예에서, 이 descriptor_tag 값에 기초하여 다른 디스크립터들에 비해 디스크립터를 고유하게 식별하는 것을 허용하는 어떤 다른 포맷이 이용될 수 있다.

descriptor_length - 이 8-비트 부호없는 정수는 필드 num_components에 바로 후속해서 이 디스크립터의 끝까지의 길이를(바이트 단위로) 특정할 수 있다. 일부 실시예들에서, 8-비트 대신, 이 필드는 16-비트일 수 있다.

num_components - 이 8-비트 부호없는 정수 필드는 이 서비스에 이용가능한 컴포넌트들의 수를 특정할 수 있다. 이 필드의 값은 1 내지 127의 범위에 있을 수 있고 양 끝점 값을 포함한다. 값들 128-255는 예약된다. 대안적인 실시예에서, 이 필드는 2개의 개별 필드로 분할될 수 있다: 7-비트 부호없는 정수 필드 num_components 및 1 비트 예약 필드.

component_type - 이 3-비트 부호없는 정수는 서비스에서 이용가능한 이 컴포넌트의 컴포넌트 타입을 특정할 수 있다. 0의 값은 오디오 컴포넌트를 나타낸다. 1의 값은 비디오 컴포넌트를 나타낸다. 2의 값은 폐쇄 자막 컴포넌트를 나타낸다. 3의 값은 애플리케이션 컴포넌트를 나타낸다. 값들 4 내지 7은 예약된다.

component_role - 이 4-비트 부호없는 정수는 이 컴포넌트의 역할 또는 종류를 특정할 수 있다. 정의된 값들은 하나 이상을 포함한다:

다른 실시예에서, 추가적으로 오디오에 대한 component_role 값은 다음과 같이 정의될 수 있다: 7 = 위급, 8= 카라오케. 이 경우에, 값들 9-14는 예약될 것이고, 15는 알려지지 않은 오디오 역할을 시그널링하는 데 사용될 것이다.

component_protected_flag - 이 1 비트 플래그는 이 컴포넌트가 보호(예를 들어, 암호화)되는지를 나타낸다. 이 플래그가 1의 값으로 설정될 때, 이 컴포넌트는 보호(예를 들어, 암호화)된다. 이 플래그가 0의 값으로 설정될 때, 이 컴포넌트는 보호(예를 들어, 암호화)되지 않는다.

component_id - 이 8-비트 부호없는 정수는 이 서비스에서 이용가능한 이 컴포넌트의 컴포넌트 식별자를 특정할 수 있다. component_id는 서비스 내에서 고유할 수 있다.

component_name_length - 이 8-비트 부호없는 정수는 이 필드에 바로 후속되는 component_name_bytes() 필드의 길이를 (바이트 단위로) 특정할 수 있다.

component_name_bytes() -"영어" 언어의 컴포넌트의 짧은 인간 판독가능 명칭. 그 각각의 문자는 UTF-8마다 인코딩될 수 있다.

도 13a, 도 13b, 도 14a, 도 14b와 관련하여, 디스크립터의 포맷 열은 다음과 같이 해석될 수 있다.

도 14a 내지 14b는 채널 정보 디스크립터에 대한 바이너리 신택스를 나타낸다. 도 14a 및 도 14b의 채널 디스크립터는 서비스 내의 채널(들)에 대한 정보를 제공한다. 이것은 주 채널 번호, 부 채널 번호, 프라이머리 채널 언어, 채널 장르, 채널 디스크립션(다수의 언어로 됨) 및 채널 아이콘을 포함한다.

채널 디스크립터에 대한 신택스는 도 14a 또는 도 14b에 도시된 신택스에 부합할 수 있다. 다른 실시예에서, 채널 디스크립터의 전부 대신, 채널 디스크립터에서의 엘리먼트들 중 일부만이 채널 디스크립터에서 또는 일부 다른 디스크립터 또는 일부 다른 데이터 구조 내에서 시그널링될 수 있다.

도 14a 및 도 14b의 채널 디스크립터에서의 신택스 엘리먼트들의 시맨틱 의미는 다음과 같다.

descriptor_tag - 이것은 이 디스크립터를 식별하기 위한 8-비트 부호없는 정수이다. 이 디스크립터를 고유하게 식별하는 0-255 사이의 임의의 적절한 값이 시그널링될 수 있다. 일 실시예에서, 이 필드의 포맷은 uimsbf일 수 있다. 다른 실시예에서, 이 descriptor_tag 값에 기초하여 다른 디스크립터들에 비해 디스크립터를 고유하게 식별하는 것을 허용하는 어떤 다른 포맷이 이용될 수 있다.

descriptor_length - 이 8-비트 부호없는 정수는 이 필드에 바로 후속해서 이 디스크립터의 끝까지의 길이를(바이트 단위로) 특정할 수 있다.

major_channel_num - 이 16-비트 부호없는 정수는 서비스의 주 채널 번호를 특정할 수 있다. 다른 실시예에서, 16 비트 대신에 이 필드에 대해 8 비트 또는 12 비트의 비트 폭이 이용될 수 있다.

minor_channel_num - 이 16-비트 부호없는 정수는 도 14a에 도시된 채널 디스크립터의 경우에 서비스의 부 채널 번호를 특정할 수 있다. 다른 실시예에서, 16 비트 대신에 이 필드에 대해 8 비트 또는 12 비트의 비트 폭이 이용될 수 있다.

도 14b에 도시된 채널 디스크립터의 경우에, 비트 폭은 15-비트로 변경된다. 따라서, 도 14b에 대해, 이 15-비트 부호없는 정수는 서비스의 부 채널 번호를 특정할 수 있다. 다른 실시예에서, 15-비트 대신에 이 필드에 대해 7-비트 또는 11-비트의 비트 폭이 이용될 수 있다.

service_lang_code - 서비스에서 이용되는 프라이머리 언어이다. 이 필드는 "언어들의 명칭들의 표현에 대한 코드들(Codes for the representation of languages) - 파트 3" 이라는 제목의 국제 표준 기구 (International Standards Organization: ISO) ISO 639-3에서 3 레터 코드 중 하나로 구성될 수 있다: 여기서 참조에 의해 그 전체가 본 명세서에 포함되는, http://www.iso.org에서 이용가능한 언어들의 포괄적인 커버리지에 대한 알파(Alpha)-3 코드. 다른 실시예들에서, 언어들의 미리 정의된 리스트가 정의될 수 있고, 이 필드는 이들 필드들의 리스트로의 인덱스일 수 있다. 대안적인 실시예에서, 이 필드에 대해 16비트가 이용될 수 있는데, 그 이유는 표현될 수 있는 언어들의 수에 대한 상한이 26 Х 26 Х 26 즉, 17576 또는 17576 - 547 = 17029이기 때문이다.

service_lang_genre - 서비스의 프라이머리 장르. service_lang_genre 엘리먼트는 서비스에 대한 장르 카테고리를 기술하기 위해 인스턴스화될 수 있다. <classificationSchemeURI>는 http://www.atsc.org/XMLSchemas/mh/2009/1.0/genre-cs/이고, service_lang_genre의 값은, 그 전체 내용이 참조로 본 명세서에 포함되는 http://www.atsc.org에서 이용가능한 "ATSC-모바일 DTV 표준, 파트 4-고지"라는 제목의 A/153 파트 4 문서의 부록 B의 분류 스키마로부터의 termID 값과 매칭할 수 있다.

icon_url_length - 이 8-비트 부호없는 정수는 이 필드에 바로 후속되는 icon_url_bytes() 필드의 길이를 (바이트 단위로) 특정할 수 있다.

icon_url_bytes() - 이 서비스를 나타내기 위해 이용되는 아이콘에 대한 URL(Uniform Resource Locator). 각각의 문자는 UTF-8마다 인코딩될 수 있다.

service_descriptor_length - 이 8-비트 부호없는 정수는 이 필드에 바로 후속되는 service_descr_bytes() 필드의 길이를 (바이트 단위로) 특정할 수 있다.

service_descr_bytes() - 서비스의 짧은 디스크립션. "영어" 언어로 또는 이 디스크립터에서의 service_lang_code 필드의 값에 의해 식별되는 언어로 된다. 그 각각의 문자는 UTF-8마다 인코딩될 수 있다.

icon_url_length 및 service_descriptor_length의 값들은 이 전체 디스크립터의 길이에 대한 정보를 제공하는 descriptor_length 필드의 값에 의해 지정된 바와 같이 제한된다.

도 14b와 관련하여, 추가의 신택스 엘리먼트는 다음과 같다:

ext_channel_info_present_flag - 1비트 불리언 플래그로서, '1'로 설정될 때, 필드들 service_lang_code, service_genre_code, service_descr_length, service_descr_bytes(), icon_url_length, icon_url_bytes()를 포함하는 이 서비스에 대한 확장된 채널 정보 필드들이 이 디스크립터에 존재한다는 것을 나타낼 수 있다. '0' 의 값은, 필드들 service_lang_code, service_genre_code, service_descr_length, service_descr_bytes(), icon_url_length, icon_url_bytes()을 포함하는 이 서비스에 대한 확장된 채널 정보 필드들이 이 디스크립터에 존재하지 않는다는 것을 나타낼 수 있다.

따라서, 도 14b에 도시된 채널 디스크립터를 이용할 때, 도 14a에 비교하여 ext_channel_info_present_flag 값을 1 더 적은 엘리먼트들로 설정함으로써 디스크립터에서 시그널링될 수 있고, 따라서 전송 서비스 제공자(1200)에 의해 전송하는 것이 더 쉬워질 수 있고, 수신기(1240) 에 의해 더 쉽게 파싱 및 디코딩될 수 있다.

일부 실시예들에서, 채널 정보 디스크립터 (예를 들어, 도 14b)가 고속 정보 채널에 포함될 때, ext_channel_info_present_flag가 0과 동일할 수 있다는 것이 비트스트림 준수의 요건일 수 있다. 다른 실시예에서, 채널 정보 디스크립터 (예를 들어, 도 14b)가 비트 효율이 요구되는 위치에서 시그널링을 위해 포함될 때, ext_channel_info_present_flag가 0과 동일할 수 있다.

또 다른 실시예에서, ext_channel_info_present_flag가 1과 동일할 수 있다는 것이 비트스트림 준수의 요건일 수 있다.

컴포넌트 정보 디스크립터에 대한 도 13a 또는 도 13b의 바이너리 신택스에 더하여, 상이한 표현이 이용될 수 있다. 도 15는 컴포넌트 정보 디스크립터에 대한 XML 신택스 및 시맨틱스를 나타낸다. 도 17은 컴포넌트 정보 디스크립터에 대한 XML 스키마를 나타낸다.

채널 정보 디스크립터에 대한 도 14a 또는 도 14b의 바이너리 신택스에 더하여, 상이한 표현이 이용될 수 있다. 도 16은 채널 정보 디스크립터에 대한 XML 신택스 및 시맨틱스를 나타낸다.

도 18은 채널 정보 디스크립터에 대한 XML 스키마를 나타낸다.

일부 예들에서 빠른 정보 채널은 대신에 서비스 리스트 테이블이라고 부를 수 있다. 추가의 예들이 서비스 리스트 테이블에 대해 아래에 설명된다. 다양한 XML 스키마들 및 명칭공간들에 관한 디스크립션이 서비스 리스트 테이블을 위해 제공된다.

서비스 리스트 테이블은 방송 내의 서비스 및/또는 광대역을 통해 이용가능한 서비스들에 관한 정보를 제공한다. 서비스 리스트 테이블은 방송 스트림 내에 각각의 서비스에 관한 다음의 정보를 포함시킴으로써 신속한 채널 스캔들 및 서비스 취득을 지원한다:

- 시청자들에게 의미있고 채널 번호 또는 업 및/또는 다운 선택을 통해 초기의 서비스 선택을 지원할 수 있는 서비스 리스트의 제시를 가능하게 하는 데 필요한 정보.

- 리스트된 각각의 서비스에 대한 서비스 계층 시그널링을 배치하기 위해 필요한 정보

서비스 리스트 테이블은 하나 이상의 섹션으로 구성될 수 있다. 서비스 리스트 테이블 섹션의 비트 스트림 신택스는 도 19에 도시된다.

도 19 내의 필드들의 시맨틱 정의들이 아래에 주어진다.

SLT - 서비스 리스트 테이블의 루트 엘리먼트.

@bsid - 전체 방송 스트림의 식별자. bsid의 값은 바람직하게는 지역 레벨(예를 들어, 북아메리카) 상에서 유일하다. 관리 또는 규정 당국은 bsid를 정의하는 데 역할을 할 수 있다.

@sltCapabilities - 이 SLT 인스턴스 내의 모든 서비스들에 대한 콘텐츠를 디코드하고 의미있게 제시하기 위한 요구된 능력들.

sltInetUrl - 이 엘리먼트는 이용가능하다면, 광대역을 통해 이 SLT 내의 모든 서비스들에 대한 전자 서비스 가이드(ESG) 또는 서비스 레벨 시그널링 파일들을 취득하기 위해 베이스 URL을 디스크라이브한다.

@URLtype - sltInetUrl(ESG 또는 시그널링 또는 서비스 이용 데이터 수집 보고 서버)로 이용가능한 파일들의 타입. 도 21은 URLType에 대해 정의된 값들을 도시한다.

서비스 - 서비스 정보.

@serviceId - 이 방송 지역의 범위 내의 이 서비스를 유일하게 식별할 수 있는 16-비트 정수.

@sltSvcSeqNum - 이 정수 번호는 바람직하게는 상기 serviceId 속성과 동일한 서비스 식별자(ID)를 갖는 SLT 서비스 정보의 시퀀스 번호를 표시한다. sltSvcSeqNum 값은 바람직하게는 각각의 서비스에 대해 0에서 시작하고 바람직하게는 이 서비스 엘리먼트의 어떤 속성 또는 자식이 변경될 때마다 1씩 증가된다. 속성 또는 자식 엘리먼트 값들이 serviceID의 특정한 값을 갖는 이전의 서비스 엘리먼트와 비교하여 변경되지 않으면 sltSvcSeqNum은 바람직하게는 증가되지 않는다. sltSvcSeqNum 필드는 최대 값에 도달한 후에 0으로 도로 랩한다.

@protected - "참"으로 설정될 때는 의미있는 제시를 위해 필요한 하나 이상의 컴포넌트가 보호되는 것을 표시한다. "거짓"으로 설정될 때, 서비스의 의미있는 제시를 위해 필요한 컴포넌트들이 보호되지 않는 것을 표시한다. 디폴트 값은 거짓이다.

@majorChannelNo - 서비스의 "주" 채널 번호를 바람직하게 나타내는 범위 1 내지 999의 정수 번호. 이 번호는 ESG 데이터 배달 서비스 또는 비상 경보 서비스(EAS) 리치 미디어 배달 서비스와 같은, 시청자들에 의해 직접 선택되도록 의도되지 않는 서비스들을 위해 요구되지 않는다.

@minorChannelNo - 서비스의 "부" 채널 번호를 바람직하게 나타내는 범위 1 내지 999의 정수 번호. 이 번호는 ESG 데이터 배달 서비스 또는 EAS 리치 미디어 배달 서비스와 같은, 시청자들에 의해 직접 선택되도록 의도되지 않는 서비스들을 위해 요구되지 않는다.

@serviceCategory - 이 서비스의 카테고리를 표시하는 8-비트 정수. 이 값은 도 22에 도시한 것과 같이 코드될 수 있다.

@shortServiceName - 서비스의 짧은 명칭(7개의 문자까지). 이 명칭은 ESG 데이터 배달 서비스 또는 EAS 리치 미디어 배달 서비스와 같은, 시청자들에 의해 직접 선택되도록 의도되지 않는 서비스들을 위해 요구되지 않는다.

@hidden - 존재할 때 그리고 "참"으로 설정될 때 서비스가 테스팅 또는 독점적 이용을 위해 의도되고, 일반 TV 수신기들에 의해 선택되는 것으로 의도되지 않은 것을 바람직하게 표시하는 불리언 값. 디폴트 값은 존재하지 않을 때 "거짓"이다.

@broadbandAccessRequired - 광대역 액세스가 서비스의 의미있는 제시를 하기 위해 수신기에 요구되는 것을 표시하는 불리언 값. 디폴트 값은 거짓이다.

@svcCapabilities - 상기 serviceId 속성과 동일한 서비스 ID를 갖는 서비스에 대한 콘텐츠를 디코드하고 의미있게 제시하기 위한 요구된 능력들.

많은 상황들에서 서비스가 BroadcastSvcSignaling 엘리먼트를 이용함으로써와 같이, 서비스에 관한 정보를 시그널링함으로써 디바이스에 대해 일부 방식으로 이용가능한 것을 보장하는 것이 바람직하다. 이 방식으로, BroadcastSvcSignaling 엘리먼트가 시그널링될 때 서비스는 위성 방송 또는 공중파 방송과 같은 방송 수신에 의해 디바이스에 이용가능하다. 이 방식으로, BroadcastSvcSignaling 엘리먼트가 존재하지 않을 때 서비스 정보 및/또는 실제 서비스가 인터넷 접속과 같은, 광대역 시그널링을 사용하여 이용가능하도록 요구된다. 이것은 적합한 서비스 이용가능성을 보장하기 위한 효율적인 메커니즘을 제공한다.

BroadcastSvcSignaling - 이 엘리먼트 및 그것의 속성들은 방송 시그널링 관련 정보를 제공한다. BroadcastSignaling 엘리먼트가 존재하지 않을 때, 부모 서비스 엘리먼트(즉, Service.svcInetUrl 엘리먼트)의 엘리먼트 scvInetUrl은 바람직하게는 존재하고 scvInetUrl(즉, Service.svcIneUrl@urlType 속성)의 속성 urlType는 값 1을 포함하고(시그널링 서버로의 URL), 또는 엘리먼트 sltInetUrl은 SLT 루트 엘리먼트(즉, SLT.sltInetUrl 엘리먼트)의 자식 엘리먼트로서 존재하고 그것의 속성 utlType(즉, SLT.sltInetUrl@urlType 속성)은 값 1을 포함하고(시그널링 서버로의 URL) service_id가 BroadcastSvcSignaling 엘리먼트의 부모 서비스 엘리먼트에 대한 serviceId 속성(즉, Seivice@serviceId 속성)에 대응하는 <service_id> 경로 용어를 지원한다.

충분한 속성 정보가 충분하고 모든 요구된 서비스 정보가 서비스에 액세스하기 위해 이용가능한 것을 보장하기 위해 BroadcastSvcSignaling 엘리먼트에 이용가능한 것을 보장하는 것이 바람직하다. 충분한 서비스 정보가 이용가능한 것을 보장하기 위해 (1) 프로토콜의 타입; (2) 주 버전 번호; (3) 부 버전 번호; (4) 물리적 계층 파이프(PLP) 식별자(ID)를 표시하는 정수 번호; (5) 인터넷 프로토콜(IP) 버전 4(IPv4) 목적지 어드레스를 포함하는 스트링; (6) 패킷들의 목적지 포트 번호; 및 (7) IPv4 소스 어드레스를 포함하는 스트링을 포함하는 방송 시그널링 정보를 제공하는, BroadcastSvcSignaling 엘리먼트에 대한 많은 상이한 속성들을 요구하는 것이 바람직하다. 이 방식으로, 정보의 이들 모든 상호-관련된 타입들이 방송 서비스에 액세스하기에 충분한 방식으로 제공된다.

@slsProtocol - 바람직하게 도 23에 도시한 것과 같이 코드된, 이 서비스에 의해 사용된 서비스 계층 시그널링의 프로토콜의 타입을 표시하는 속성.

@slsMajorProtocolVersion - 이 서비스에 대한 서비스 계층 시그널링을 배달하기 위해 사용되는 프로토콜의 주 버전 번호. 디폴트 값은 1이다.

@SlsMinorProtocolVersion - 이 서비스에 대한 서비스 계층 시그널링을 배달하기 위해 사용되는 프로토콜의 부 버전 번호. 디폴트 값은 0이다.

@slsPlpId - 이 서비스에 대한 서비스 계층 시그널링을 운반하는 물리적 계층 파이프의 PLP 식별자(ID)를 표시하는 정수 번호.

@slsDestinationIpAddress - 이 서비스에 대한 서비스 계층 시그널링(SLS) 데이터를 운반하는 패킷들의 인터넷 프로토콜(IP) 버전 4(IPv4) 목적지 어드레스를 포함하는 스트링.

@slsDestinationUdpPort - 이 서비스에 대한 서비스 계층 시그널링 데이터를 운반하는 패킷들의 포트 번호.

@slsSourceIpAddress - 이 서비스에 대한 서비스 계층 시그널링 데이터를 운반하는 패킷들의 IPv4 소스 어드레스를 포함하는 스트링.

많은 상황들에서, 상이한 타입들의 광대역 서버 정보를 시그널링하기 위해 상이한 URL들을 사용하는 능력을 포함시키는 것이 바람직하다. 한 예로서 동일한 서버 시그널링 서버 정보 및 서비스 이용 데이터 수집 보고 서버 정보는 동일한 시간에 시그널링될 필요가 있을 수 있다. 이 부가된 유연성은 SvcInetUrl에 대해 0..N의 카디널리티를 사용함으로써 달성될 수 있다. 이 방식으로, 시스템은 URL의 하나보다 많은 타입을 사용하는 유연성을 포함한다.

svcInetUrl - 이용가능하다면, 광대역을 통해 이 서비스에 대한 ESG 또는 서비스 계층 시그널링 파일들에 액세스하기 위한 베이스 URL.

@URLtype - SvcInetUrl로 이용가능한 파일들의 타입. 도 21은 이것에 대한 예시적인 값들을 도시한다.

시그널링 메타데이터의 광대역 배달에 관한 추가 디스크립션이 아래에 제공된다.

sltInetSigUrl 속성이 존재할 때, 그것은 시그널링 메타데이터를 획득하기 위해 하이퍼텍스트 트랜스퍼 프로토콜(HTTP) 요청들을 하기 위해 베이스 URL로서 사용될 수 있다. 복귀될 원하는 시그널링 오브젝트들은 베이스 URL에 경로 용어들을 부가함으로써 표시된다. 예시적인 경로 용어들이 도 24에서 정의된다. 이것은 서버 관점으로부터 시그널링 오브젝트들의 검색을 보다 효율적이게 할 수 있는데, 왜냐하면 서버 측 애플리케이션은 원하는 오브젝트들을 검색하는 것이 요구되지 않기 때문이다. 각각의 검색은 파일을 간단히 페치한다. 이러한 요청을 하기 위해, HTTP GET 방법이 사용될 수 있고, 베이스 URL의 끝에 부가된 경로는 도 24에 표시된 것과 같이, 원하는 시그널링 오브젝트 또는 오브젝트들을 표시하는 용어들을 포함한다.

sltInetSigUrl 베이스 URL이 서비스 리스트 테이블에 나타날 때, service_id 용어는 요청된 시그널링 메타데이터 오브젝트들이 적용하는 서비스를 표시하기 위해 사용된다. service_id 용어가 존재하지 않으면, 섹션 내의 모든 서비스들에 대한 시그널링 메타데이터 오브젝트들이 요청된다.

도 24에서, "normal | diff | template" 용어는 메타데이터 오브젝트(들)의 정상 형태, 메타데이터 오브젝트(들)의 상이한 형태, 또는 메타데이터 오브젝트(들)의 템플릿 형태가 요청되는지를 표시한다. 정상 형태가 요망된다면, 정상 용어는 생략될 수 있다.

도 24에서, "current | next" 용어는 메타데이터 오브젝트(들)의 현재의 버전 또는 현재의 버전 이후의 메타데이터 오브젝트(들)의 다음의 버전이 요청되는지를 표시한다. 현재의 버전이 요망된다면, 현재의 용어는 생략될 수 있다.

도 24에서, 마지막 열에 도시한 용어는 어떤 타입의 메타데이터 오브젝트(들)가 요망되는지를 표시하기 위해 사용된다. 지원된 타입들이 그들의 디스크립션들과 함께 도 25에 리스트된다.

메타데이터 오브젝트들을 시그널링하기 위한 HTTP 요청을 위한 URL의 일부 예들이 아래에 나타내진다:

<sltInetSigUrl>/0x2107/RD - service_id 0x2107을 갖는 서비스에 대한 모든 ROUTE/DASH 시그널링 오브젝트들의 현재, 정상 버전을 리턴한다

<sltInetSigUrl>/0x2103/next/MPD - service_id 0x2103을 갖는 서비스에 대한 메디안 제시 디스크립션(MPD)의 현재, 다음 버전을 리턴한다

<sltInetSigUrl>/0x2104template/AST - service_id 0x2104를 갖는 서비스에 대한 애플리케이션 시그널링 테이블(AST)의 현재, 템플릿 버전을 리턴한다

svcInetSigUrl이 (모든 서비스 레벨에서) 나타날 때, 동일한 경로들이 서비스 용어가 나타나지 않는 것을 제외하고, 동일한 시맨틱스로, 그것의 끝에 부가될 수 있는데, 왜냐하면 원하는 서비스를 지정할 필요가 없기 때문이다.

그들 HTTP 요청들에 대한 응답 바디는 그 응답 내에 포함된 각각의 시그널링 오브젝트에 대한 아이템 엘리먼트를 포함하는 메타데이터 엔벨로프를 포함할 수 있다. 시그널링 오브젝트들의 0 또는 1은 아이템 엘리먼트 내에 매립될 수 있다. 매립되지 않은 어느 시그널링 오브젝트들은 그들의 아이템 엘리먼트들에서 참조될 수 있고, 그들은 그들이 참조되는 순서로, 다수-부분 메시지 내의 메타데이터 엔벨로프와 함께 패키지될 수 있다. 아이템 엘리먼트들의 validFrom 및 validUntil 속성들은 각각의 시그널링 오브젝트의 유효성의 간격을 표시하기 위해 존재하여야 한다.

메타데이터 엔벨로프의 아이템 엘리먼트는 ATSC 명칭공간에서 정의된, 다음의 속성의 추가에 의해 확장될 수 있다:

<xs:attribute name="nextUrl" type="xs:anyURl" use="optional"/>.

존재할 때, 이 속성("nextUrl")에 의해 주어진 URL은 아이템 엘리먼트에서 디스크라이브된 시그널링 오브젝트에의 다음에 스케줄된 업데이트의 URL일 수 있다.

그러므로, 광대역을 통해 취득된 시그널링 오브젝트에 대한 validUntil 시간이 접근할 때, 디바이스는 메타데이터 엔벨로프에서 시그널링 오브젝트를 나타내기 위해 사용된 아이템 엘리먼트 내의 nextURL 속성에 의해 주어진 URL로 HTTP GET 요청을 함으로써 시그널링 오브젝트에의 다음의 스케줄된 업데이트를 취득할 수 있다.

스케줄되지 않은 업데이트가 시그널링 오브젝트에 대해 이루어지면, 동적 이벤트가 업데이트를 고지하는 것으로 발생될 것이다. 디바이스는 다음에 동적 이벤트의 데이터 속성 내의 URL을 사용하여, 업데이트된 시그널링 오브젝트를 취득할 수 있다.

sltInetUrl 엘리먼트가 SLT 엘리먼트의 자식 엘리먼트로서 존재하고, 그것의 속성 urlType이 값 2를 포함할 때(ESG 서버로의 URL), 이 sltInetUrl 엘리먼트에 의해 특정된 URL은 SLT 내의 모든 서비스들에 대해 광대역을 통해 ESG 데이터를 검색하기 위해 사용될 수 있다.

svcInetEsgUrl 속성 svcInetUrl 엘리먼트가 서비스에 대해 존재하고 그것의 속성 urlType이 값 2를 포함할 때(ESG 서버로의 URL), 이 svcInetUrl 엘리먼트에 의해 특정된 URL은 이 svcInetUrl 엘리먼트가 나타나는 서비스 엘리먼트와 동일한 service_id를 갖는 서비스에 대해 광대역을 통해 ESG 데이터를 검색하기 위해 사용될 수 있다. 이 경우에 svcInetUrl 엘리먼트에 의해 특정된 URL은 ATSC 3.0 서비스 고지에서 특정된 것과 같이 조회들을 위해 사용된다.

도 19에 도시한 서비스 리스트 테이블에서, 엘리먼트 sltInetUrl에 대해 속성 urlType이 요구되는 대로(대신에 옵션으로서) 리스트된다. 각각의 서비스를 위해, svcInetUrl 엘리먼트에 대해 속성 urlType이 요구되는 대로(대신에 옵션으로서) 리스트된다. urlType 속성이 이들 2개의 엘리먼트에 대해 옵션이었다면 그것이 어떤 타입의 URL인지를 표시하지 않고 서비스 리스트 테이블에서 또는 서비스들의 하나 이상에 대해 URL을 시그널하는 것이 가능했었을 것이다. 이것은 URL이 참조하는 서비스가 어떤 종류인지를 불분명하게 할 것이다(즉, 시그널링 서버 URL 또는 ESG 서버 URL 또는 서비스 이용 데이터 수집 보고 서버 URL 등). 결과적으로 sltInetUrl에 대한 urlType 속성 및 각각의 svcInetUrl에 대한 urlType 속성이 요구된다. 그러므로 그들의 사용은 도 19에 "1"로서 도시된다.

SLT는 다음의 명칭공간을 갖는 XML 스키마에서의 정의들에 따르는 SLT 루트 엘리먼트를 포함하는 XML 문서로서 나타내질 수 있다:

http://www.atsc.org/XMLSchemas/ATSC3/Delivery/SLT/1.0/ 및 도 20a에 도시한 것과 같은 스키마들.

약자 "slt"는 그들이 XML 문서에서 나타난다면, 일방향 트랜스포트를 통한 실시간 오브젝트 배달(ROUTE) 사용자 서비스 디스크립션 스키마의 엘리먼트의 어떤 것에 대한 명칭공간 접두사로서 사용되어야 한다. 이 표준의 초기 릴리스를 위해 명칭공간과의 이 접두사의 바인딩은 XML 문서의 스키마 엘리먼트 내에 다음의 속성을 포함시킴으로써 선언될 수 있다.

xmlns:slt="http://www.atsc.org/XMLSchemas/ATSC3/Delivery/SLT/1.0"

위에 언급된 것과 같이, 도 20a, 20b는 SLT에 대한 규범적인 스키마를 도시한다. 이 규범적인 스키마의 구조가 도 20c에 도시된다.

서비스 리스트 테이블의 다른 예가 아래에 설명된다.

ATSC 3.0 서비스는 하나보다 많은 라디오 주파수(RF) 채널 내에 컴포넌트들을 가질 수 있다. 단일 RF 채널 내의 이러한 서비스의 컴포넌트들의 세트는 서비스의 "부분"이라고 부를 수 있다. ATSC 3.0은 http://atsc.org/wp-content/uploads/2016/10/A322-2016-Physical-Layer-Protocol.pdf에서 이용가능하고 그 전체가 본원에 참조로 포함된, ATSC 표준 물리적 계층 프로토콜(A/322)에 설명된 것과 같은 채널 본딩을 지원한다. 채널 본딩에서, 단일 PLP 접속의 데이터는 2개 이상의 상이한 RF 채널에 걸쳐 분산된다. 채널 본딩이 사용되지 않을 때 이러한 서비스는 (다른 부분들을 사용하는 것이 또한 더 많이 호소하는 제시를 제공할 수 있더라도) 다른 부분들의 사용 없이 서비스의 의미있는 제시를 위해 충분할 수 있는 단일 RF 채널 내에 단지 하나의 부분을 가질 수 있다. 채널 본딩이 사용될 때 이러한 서비스는 (다른 부분들을 사용하는 것이 또한 더 많이 호소하는 제시를 제공할 수 있더라도) 다른 부분들의 사용 없이 서비스의 의미있는 제시를 위해 충분한, (채널 본딩을 위해 사용된 주파수들에 대응하는) 기껏해야 2개의 RF 채널 내에 부분들을 가질 것이다. 이러한 부분을 "필수" 부분이라고 부른다. 각각의 서비스 부분은 부분이 나타나는 RF 채널의 서비스 리스트 테이블 내에 포함될 수 있다. 서비스의 부분들의 이들 다수의 리스팅은 모두 서비스 ID의 동일한 값 및 주/부 채널 번호의 동일한 값을 가질 수 있다. 이것은 다수의 RF 채널 내의 서비스의 다수의 부분이 그들이 채널 스캔들을 수행할 때 수신기들의 채널 맵 내의 단일 서비스내로 통합되게 한다. 이러한 서비스의 각각의 부분에 대한 SLT 엔트리는 또한 다른 부분들이 발견될 수 있는 방송 스트림(들)의 방송 스트림 식별자들을 리스트한다. 서비스가 하나(채널 본딩이 아닌 경우) 또는 2개(채널 본딩인 경우)의 필수 부분을 포함하면, 이들은 SLT 내에 표시된다. 필수 부분이 SLT 내에 표시되지 않으면, 서비스는 필수 부분을 갖지 않는데, 즉, 수신기는 어떤 컴포넌트가 존재하는지를 서비스의 MPD 또는 USBD로부터 간단히 결정할 수 있다.

예시적인 서비스 리스트 테이블이 도 26에 도시된다. 서비스 리스트 테이블 내의 엘리먼트들 및 속성들의 디스크립션이 아래에 설명되는 것과 같을 수 있다.

다음의 텍스트는 SLT 내에 엘리먼트들 및 속성들의 시맨틱스들을 특정한다.

SLT - 서비스 리스트 테이블의 루트 엘리먼트.

@bsid - 전체 방송 스트림의 식별자. bsid의 값은 바람직하게는 지역 레벨(예를 들어, 북아메리카) 상에서 유일하다. 관리 또는 규정 당국은 역할을 할 수 있다.

@sltCapabilities - 이 SLT 인스턴스 내의 모든 서비스들에 대한 콘텐츠를 디코드하고 의미있게 제시하기 위한 요구된 능력들. sltCapabilities 속성의 신택스 및 시맨틱스는 http://atsc.org/wp-content/uploads/2015/12/A332S33-159r6-Service-Announcement.pdf에서 이용가능하고 그 전체가 본원에 참조로 포함된 ATSC 3.0 서비스 고지 명세 A/332의 콘텐츠 프래그먼트 하에서 특정된 sa:capabilities 엘리먼트의 신택스 및 시맨틱스를 따를 수 있다.

sltInetUrl - 이용가능하다면, 광대역을 통해 이 SLT 내의 모든 서비스들에 대한 ESG 또는 서비스 계층 시그널링 파일들을 취득하기 위한 베이스 URL.

@urlType - sltInetUrl(ESG 또는 서비스 계층 시그널링)로 이용가능한 파일들의 타입. 도 27은 urlType에 대한 가능한 코드 값들을 도시한다.

서비스 - 서비스 정보.

@serviceId - 이 방송 지역의 범위 내의 이 서비스를 유일하게 식별할 수 있는 16-비트 정수.

@sltSvcSeqNum - 이 정수 번호는 바람직하게는 상기 serviceId 속성과 동일한 서비스 식별자(ID)를 갖는 SLT 서비스 정보의 시퀀스 번호를 표시한다. sltSvcSeqNum 값은 각각의 서비스에 대해 0에서 시작할 수 있고 이 서비스 엘리먼트의 어떤 속성 또는 자식이 변경될 때마다 1씩 증가될 수 있다. 속성 또는 자식 엘리먼트 값들이 serviceID의 특정한 값을 갖는 이전의 서비스 엘리먼트와 비교하여 변경되지 않으면 sltSvcSeqNum은 증가되지 않을 수 있다. sltSvcSeqNum 필드는 최대 값에 도달한 후에 0으로 도로 랩한다.

@protected - "참"으로 설정될 때는 의미있는 제시를 위해 필요한 하나 이상의 컴포넌트가 보호되는 것을 표시한다. "거짓"으로 설정될 때, 서비스의 의미있는 제시를 위해 필요한 컴포넌트들이 보호되지 않는 것을 표시한다. 디폴트 값은 거짓이다.

@majorChannelNo - 서비스의 "주" 채널 번호를 나타낼 수 있는 범위 1 내지 999의 정수 번호. 주 채널 번호들의 할당은 ATSC 3.0 방송의 라이센스에 의해 사용된 2-부분 채널 번호 조합들이 중첩하는 DTV 서비스 지역을 갖는 기타 라이센스에 의해 사용된 것들과 상이한 것을 보장하기 위해 A/65 부록 B에 주어진 가이드라인들을 따를 수 있다. ATSC 3.0 방송 서비스는 둘 간에 동일한 프로그래밍이 주어지는 경우에, DTV 서비스 지역 내의 ATSC A/53 방송에서 사용하는 데 동일한 2-부분 채널 번호 조합을 사용할 수 있다는 점에 유의한다. @majorChannelNo의 명세는 ESG 데이터 배달 서비스 또는 EAS 리치 미디어 배달 서비스와 같은, 시청자들에 의해 직접 선택되도록 의도되지 않는 서비스들을 위해 요구되지 않는다.

@minorChannelNo - 서비스의 "부" 채널 번호를 나타낼 수 있는 범위 1 내지 999의 정수 번호. 이 번호는 ESG 데이터 배달 서비스 또는 EAS 리치 미디어 배달 서비스와 같은, 시청자들에 의해 직접 선택되도록 의도되지 않는 서비스들을 위해 요구되지 않는다.

@serviceCategory - 이 서비스의 카테고리를 표시하는 8-비트 정수. 이 값은 도 28에 따라 코드될 수 있다.

@shortServiceName - 서비스의 짧은 명칭(7개의 문자까지). 이 명칭은 ESG 데이터 배달 서비스 또는 EAS 리치 미디어 배달 서비스와 같은, 시청자들에 의해 직접 선택되도록 의도되지 않는 서비스들을 위해 요구되지 않는다.

@hidden - 존재할 때 그리고 "참"으로 설정될 때 서비스가 테스팅 또는 독점적 이용을 위해 의도되고, 일반 TV 수신기들에 의해 선택되는 것으로 의도되지 않은 것을 표시할 수 있는 불리언 값. 디폴트 값은 존재하지 않을 때 "거짓"일 수 있다.

@broadbandAccessRequired - 광대역 액세스가 서비스의 의미있는 제시를 하기 위해 수신기에 요구되는 것을 표시하는 불리언 값. 디폴트 값은 거짓이다.

@svcCapabilities - 상기 serviceId 속성과 동일한 서비스 ID를 갖는 서비스에 대한 콘텐츠를 디코드하고 의미있게 제시하기 위한 요구된 능력들. svcCapabilities 속성의 신택스 및 시맨틱스는 http://atsc.org/wp-content/uploads/2015/12/A332S33-159r6-Service-Announcement.pdf에서 이용가능하고 그 전체가 본원에 참조로 포함된 ATSC 3.0 서비스 고지 명세 A/332의 콘텐츠 프래그먼트 하에서 특정된 sa:capabilities 엘리먼트의 신택스 및 시맨틱스를 따를 수 있다.

@essential - 이 불리언 속성은 2와 동일한 @type을 갖는 OtherBsid 엘리먼트의 인스턴스들이 이 서비스에 대해 존재하지 않을 때 존재하지 않을 수 있다.

이 불리안 속성은 2와 동일한 @type을 갖는 적어도 하나의 OtherBsid 엘리먼트가 이 서비스에 대해 존재할 때 존재할 수 있다.

이 제한은 0..1의 카디널리티를 갖는 @essential이 타입 2를 갖는 적어도 하나의 OtherBsid 엘리먼트가 시그널링될 때 존재할 수 있는 것을 확실하게 한다는 점에 유의한다.

이 속성이 존재하고 "참"으로 설정될 때, 이것은 @serviceId 속성에 의해 식별된 서비스가 다수의 RF 채널 내에 컴포넌트들을 갖고, 이 방송 스트림 내의 부분이 서비스의 의미있는 제시를 위해 필수적이라는 것을 표시한다. 이 속성이 존재하고 "거짓"으로 설정될 때, 이것은 @serviceId 속성에 의해 식별된 서비스가 다수의 RF 채널 내에 컴포넌트들을 갖고, 이 방송 스트림 내의 부분이 서비스의 의미있는 제시를 위해 필수적이 아니라는 것을 표시한다. 이 속성에 대해 디폴트 값은 없다.

한 예에서 다음이 요구될 수 있다:

http://atsc.org/wp-content/uploads/2016/10/A322-2016-Physical-Layer-Protocol.pdf에서 이용가능하고 그 전체가 본원에 참조로 포함된 ATSC 3.0 표준 A/322에서 설명된 것과 같은 SNR 채널 본딩이 사용되고, Service@essebtial이 거짓일 때, SLT@bsid의 값은 이 SLT에서 OtherBsid 엘리먼트의 값과 동일할 수 있고 그에 대해 OtherBsid@essential은 참이고 OtherBsid@type은 2이다.

또한 다른 예에서 http://atsc.org/wp-content/uploads/2016/10/A322-2016-Physical-Layer-Protocol.pdf에서 이용가능하고 그 전체가 본원에 참조로 포함된 ATSC 3.0 표준 A/322에서 설명된 것과 같은 플레인 채널 본딩이 사용되고, Service@essebtial이 거짓일 때, SLT@bsid의 값은 이 SLT에서 OtherBsid 엘리먼트의 값과 동일할 수 있고 그에 대해 OtherBsid@essential은 참이고 OtherBsid@type은 2이다.

또한 다른 예에서 http://atsc.org/wp-content/uploads/2016/10/A322-2016-Physical-Layer-Protocol.pdf에서 이용가능하고 그 전체가 본원에 참조로 포함된 ATSC 3.0 표준 A/322에서 설명된 것과 같은 채널 본딩이 사용되고, Service@essebtial이 거짓일 때, SLT@bsid의 값은 이 SLT에서 OtherBsid 엘리먼트의 값과 동일할 수 있고 그에 대해 OtherBsid@essential은 참이고 OtherBsid@type은 2이다.

BroadcastSvcSignaling - 이 엘리먼트 및 그것의 속성들은 방송 시그널링 관련 정보를 제공한다. BroadcastSvcSignaling 서브-엘리먼트가 존재하지 않을 때, (a) 서비스 엘리먼트(즉, Service.svcInetUrl 엘리먼트)의 엘리먼트 svcInetUrl이 1인 그것의 urlType 속성(즉, Service.svcInetUrl@urlType) 값으로 존재할 수 있고(SLS 서버로의 URL), 또는 (b) 엘리먼트 sltInetUrl이 1인 그것의 urlType 속성(즉, SLT.sltInetUrl@urlType) 값을 갖는 SLT 루트 엘리먼트(즉, SLT.sltInetUrl)의 자식 엘리먼트로서 존재할 수 있다(URL 투 Signaling Server). 후자의 경우에, sltInetUrl은 service_id가 서비스 엘리먼트에 대한 serviceId 속성(즉, Service@serviceId 속성)에 대응하는 <service_id> 경로 용어를 지원할 수 있다.

@slsProtocol - 도 29에 따라 코드된, 이 서비스에 의해 사용된 서비스 계층 시그널링의 배달 프로토콜의 타입을 표시하는 속성.

@slsMajorProtocolVersion - 이 서비스에 대한 서비스 계층 시그널링을 배달하기 위해 사용되는 프로토콜의 주 버전 번호. 디폴트 값은 1이다.

@slsMinorProtocolVersion - 이 서비스에 대한 서비스 계층 시그널링을 배달하기 위해 사용되는 프로토콜의 부 버전 번호. 디폴트 값은 0이다.

@slsPlpId - 이 서비스에 대한 SLS를 운반하는 물리적 계층 파이프의 PLP ID를 표시하는 정수 번호. PLP ID는 http://atsc.org/wp-content/uploads/2016/10/A322-2016-Physical-Layer-Protocol.pdf에서 이용가능하고 그 전체가 본원에 참조로 포함된 ATSC 표준 A/322에서 특정될 수 있다.

@slsDestinationIpAddress - 이 서비스에 대한 SLS 데이터를 운반하는 패킷들의 점구분-IPv4 목적지 어드레스를 포함하는 스트링.

@slsDestinationUdpPort - 이 서비스에 대한 SLS 데이터를 운반하는 패킷들의 포트 번호.

@slsSourceIpAddress - 이 서비스에 대한 SLS 데이터를 운반하는 패킷들의 점구분-IPv4 소스 어드레스를 포함하는 스트링.

svcInetUrl - 이용가능하다면, 광대역을 통해 이 서비스에 대한 ESG 또는 서비스 계층 시그널링 파일들에 액세스하기 위한 베이스 URL.

@urlType - svcInetUrl로 이용가능한 파일들의 타입. 예시적인 값들이 도 27에 도시된다.

OtherBsid - 이 서비스의 복제 또는 이 서비스를 위한 추가의 컴포넌트들을 포함하는 방송 스트림의 식별자.

한 예에서 다음이 요구될 수 있다:

OtherBsid 값은 부모 SLT 엘리먼트의 @bsid 속성의 값과 동일하지 않을 수 있다.

이 제한은 OtherBsid 엘리먼트가 다른(그리고 현재의 스트림과 동일한 방송 스트림이 아닌) 방송 스트림에서 서비스들을 표시하기 위해서만 사용되는 것을 확실히 한다.

@type - 값이 "1"로 설정될 때, 이것은 OtherBsid에 의해 식별된 방송 스트림이 이 서비스의 복제라는 것을 표시한다. 값이 "2"로 설정될 때, 이것은 이 서비스 엘리먼트가 방송 스트림 식별자 OtherBsid 및 부모 서비스 엘리먼트의 @serviceId 속성인 서비스 식별자 값에 의해 식별된 방송 스트림 내에 컴포넌트들을 갖는 서비스의 부분을 나타낸다.

이 디스크립션은 OtherBsid 값에 의해 식별된 다른 방송 스트림 내에 어떤 서비스가 서비스에 대한 추가의 컴포넌트들을 포함하는지를 수신기에 분명한 표시를 가능하게 한다.

이 속성의 다른 값들이 도 30에 도시한 것에 따라 코드된, 미래 사용을 위해 미정의되거나 예약된다.

한 예에서, 그것은

하나보다 많은 OtherBsid 엘리먼트들이 서비스 엘리먼트 내부에 존재할 때 모든 이들 엘리먼트의 OtherBsid@type이 동일할 수 있는 요건일 수 있다.

이 제한은 복제와 부분 타입 서비스들의 혼합을 허용하지 않는다. 복제와 부분 타입 서비스들의 혼합은 실제 이득이 없이 상당한 수신기 파싱 및 디코딩 복잡성을 야기할 수 있다. 이와 같이 이 조합을 허용하지 않는 것은 보다 간단한 수신기 처리를 가져다 줄 수 있다.

@essential - @type이 2일 때, 이 불리언 값은 OtherBsid에 의해 식별된 방송 스트림 내에 포함된 부분이 부모 서비스 엘리먼트의 서비스 식별자 @serviceId 속성 및 이 엘리먼트의 부모 서비스 엘리먼트의 부모의 방송 스트림 식별자 @bsid에 대응하는 이 서비스의 의미있는 제시를 위해 필수적인지를 표시한다. 값 "참"은 그것이 필수적인 것을 표시하고; 값 "거짓"은 이것이 필수적이 아니라는 것을 표시한다. 디폴트 값은 거짓이다.

한 예에서 그것은

부모 서비스 엘리먼트의 Service@essential 속성이 "거짓"일 때, 2인 @type 값을 갖는 OtherBsid 엘리먼트들의 기껏해야 하나가 "참"인 OtherBsid@essential 속성을 가질 수 있는 요건일 수 있다.

부모 서비스 엘리먼트의 @essential 속성이 "참"일 때, OtherBsid@essential 속성 값은 "거짓"일 수 있다.

이들 제한은 기껏해야 하나의 RF 튜너가 서비스의 의미있는 제시를 위해 필요하게 되는 것을 확실히 하고 강요한다. 이것은 이러한 의미있는 제시를 위해 하나보다 많은 튜너를 요구하지 않고 보다 간단하고 보다 낮은 복잡성 수신기들이 서비스를 의미있게 제시할 수 있게 한다.

@type이 1일 때 이 속성은 의미를 갖지 않을 수 있고 그러므로 존재하지 않을 수 있거나 존재한다면 거짓일 수 있다.

한 예에서 OtherBsid 엘리먼트의 시맨틱스는 다음과 같을 수 있다:

OtherBsid - 부호없는 짧은 정수 값들의 이 리스트의 각각의 인스턴스는 이 서비스에 대한 복제 또는 부분을 배달하는 다른 방송 스트림의 식별자를 표시할 수 있다. OtherBsid의 각각의 인스턴스의 포맷은 @bsid의 포맷과 동일할 수 있다. 이 엘리먼트는 @essential 속성이 존재할 때 존재하고 "참"으로 설정될 수 있고 그것은 @essential 속성이 존재하지 않거나 @essential 속성이 존재하고 "거짓"으로 설정될 때 존재하고 "참"으로 설정될 수 있다. 바람직하게는 디폴트 값은 없다.

그러나, 제한들이 위에 정의된 것과 같은 시맨틱스에서 존재한다. 예를 들어 이들 시맨틱스는 Service@essential 속성이 시그널링되지 않을 때 복제 서비스들의 표시의 시그널링을 배제한다. 다른 예에서 이 제한들을 극복하기 위해 OtherBsid 엘리먼트의 시맨틱스는 다음과 같을 수 있다:

OtherBsid - 부호없는 짧은 정수 값들의 이 리스트의 각각의 인스턴스는 이 서비스에 대한 복제 또는 부분을 배달하는 다른 방송 스트림의 식별자를 표시할 수 있다. OtherBsid의 각각의 인스턴스의 포맷은 @bsid의 포맷과 동일할 수 있다. 적어도 하나의 OtherBsid 엘리먼트는 @essential 속성이 부모 서비스 엘리먼트에 대해 존재하고 "참"으로 설정될 때 존재할 수 있다. OtherBsid 엘리먼트는 @essential 속성이 부모 서비스 엘리먼트에 대해 존재하고 "거짓"으로 설정될 때 존재하지 않을 수 있다. 하나 이상의 OtherBsid 엘리먼트는 @essential 속성이 부모 서비스 엘리먼트에 대해 존재하지 않을 때 존재할 수 있다. 바람직하게는 디폴트 값은 OtherBsid 엘리먼트가 존재하지 않을 때 없다.

또 다른 예에서 OtherBsid 엘리먼트의 시맨틱스는 다음과 같을 수 있다:

OtherBsid - 부호없는 짧은 정수 값들의 이 리스트의 각각의 인스턴스는 이 서비스에 대한 복제 또는 부분을 배달하는 다른 방송 스트림의 식별자를 표시할 수 있다. OtherBsid의 각각의 인스턴스의 포맷은 @bsid의 포맷과 동일할 수 있다. 적어도 하나의 OtherBsid 엘리먼트는 @essential 속성이 부모 서비스 엘리먼트에 대해 존재하고 "참"으로 설정될 때 존재할 수 있다. OtherBsid 엘리먼트는 @essential 속성이 부모 서비스 엘리먼트에 대해 존재하고 "거짓"으로 설정될 때 존재하지 않을 수 있다. 1인 @type을 갖는 하나 이상의 OtherBsid 엘리먼트는 @essential 속성이 부모 서비스 엘리먼트에 대해 존재하지 않을 때 존재할 수 있다. 바람직하게는 디폴트 값은 OtherBsid 엘리먼트가 존재하지 않을 때 없다.

OtherBsid 엘리먼트에 대한 상기 수정된 시맨틱스는 OtherBsid 엘리먼트에 의해 표시된 다른 RF 채널 내의 서비스가 이 RF 채널 내의 서비스의 복제라는 표시를 시그널링하는 것을 가능하게 한다. 그러므로, 현재의 서비스에 대한 복제 서비스들의 리스트를 획득하는 데 관심있는 수신기는 그것이 Service@essential 속성을 포함하지 않아도 서비스 리스트 테이블을 파싱하고 하나 이상의 포함된 OtherBsid 엘리먼트들을 디코드하고 다음에 현재의 서비스의 복제를 제공하는 RF 채널들에 관한 정보를 획득하기 위해 "1"인 값을 갖는 OtherBsid@type 속성을 디코드하고 찾을 수 있다.

도 13 내지 도 30은 신택스, 시맨틱스, 및 스키마의 특정 실시예들을 도시하지만, 추가적인 변형들이 가능하다. 이들은 다음의 변형들을 포함한다:

상기에서 도시된 것들과 비교하여 상이한 데이터 타입들이 엘리먼트에 이용될 수 있다. 예를 들어, unsignedByte 데이터 타입 대신 unsignedShort 데이터 타입이 이용될 수 있다. 다른 예에서 부호없는 Byte(바이트) 데이터 타입 대신 String(스트링) 데이터 타입이 이용될 수 있다.

신택스를 속성으로서 시그널링하는 것 대신에 신택스는 엘리먼트로서 시그널링될 수 있다. 신택스를 엘리먼트로서 시그널링하는 것 대신에 신택스는 속성으로서 시그널링될 수 있다.

다양한 필드들의 비트 폭은 변경될 수 있으며, 예를 들어, 비트스트림의 엘리먼트에 대해 4 비트 대신에 신택스 5 비트 또는 8 비트 또는 2 비트가 이용될 수 있다. 여기서 열거된 실제 값들은 단지 예들일 뿐이다.

XML 포맷 및 XML 스키마 대신에 JSON(Javascript Object Notation) 포맷 및 JSON 스키마가 이용될 수 있다. 대안으로 제안된 신택스 엘리먼트들이, CSV(Comma Separated Values), BNF(Backus-Naur Form), ABNF(Augmented Backus-Naur Form), 또는 EBNF(Extended Backus-Naur Form)를 이용하여 시그널링될 수 있다.

엘리먼트 및/또는 속성의 카디널리티(Cardinality)가 변경될 수 있다. 예를 들어 카디널리티가 "1"로부터 "1..N"으로 변경될 수 있거나 카디널리티가 "1"로부터 "0..N"으로 변경될 수 있거나 카디널리티가 "1"로부터 "0..1"로 변경될 수 있거나 카디널리티가 "0..1"로부터 "0..N"으로 변경될 수 있거나 카디널리티가 "0..N"으로부터 "0..1"로 변경될 수 있다.

엘리먼트 및/또는 속성은 앞서 옵션적인 것으로 나타내어진 경우 요구되게 만들어질 수 있다. 엘리먼트 및/또는 속성은 앞서 요구되는 것으로 나타내어진 경우 옵션적으로 만들어질 수 있다.

일부 자식 엘리먼트들은 대신 부모 엘리먼트들로서 시그널링될 수 있거나 다른 자식 엘리먼트들의 자식 엘리먼트들로서 시그널링될 수 있다.

상기의 모든 변형들은 본 발명의 범위 내에 있는 것으로 의도한다.

또한, 전술된 실시예들 각각에서 이용된 기지국 디바이스 및 단말 디바이스(비디오 디코더 및 비디오 인코더)의 각각의 기능 블록 또는 다양한 피처들은, 전형적으로 집적 회로 또는 복수의 집적 회로인, 회로에 의해 구현되거나 실행될 수 있다. 본 명세서에서 설명된 기능들을 실행하도록 설계된 회로부는 범용 프로세서, 디지털 신호 프로세서(digital signal processor: DSP), 주문형 또는 일반적인 애플리케이션 집적 회로(ASIC), 필드 프로그래밍가능한 게이트 어레이(field programmable gate array: FPGA), 또는 다른 프로그래밍가능한 로직 디바이스들, 개별 게이트들 또는 트랜지스터 로직, 또는 개별 하드웨어 컴포넌트, 또는 그 조합을 포함할 수 있다. 범용 프로세서는, 마이크로프로세서이거나, 대안적으로, 프로세서는, 종래의 프로세서, 제어기, 마이크로제어기 또는 상태 머신일 수 있다. 전술된 범용 프로세서 또는 각각의 회로는 디지털 회로에 의해 구성될 수도 있거나, 아날로그 회로에 의해 구성될 수도 있다. 또한, 반도체 기술의 진보로 인해 현재의 집적 회로를 대체하는 집적 회로 제작 기술이 출현하면, 이 기술에 의한 집적 회로도 역시 이용될 수 있다.

청구항들은 위에 예시된 정확한 구성 및 컴포넌트들로 제한되지 않는다는 것을 이해해야 한다. 청구항들의 범위에서 벗어나지 않고 본 명세서에서 설명된 시스템들, 방법들, 및 장치들의 배열, 동작 및 세부 사항들에 있어서 다양한 수정들, 변경들 및 변형들이 이루어질 수 있다.

Claims (3)

1. 제1 라디오 주파수 채널 내의 서비스와 연관된 서비스 정보를 시그널링하기 위한 방법으로서,
   상기 제1 라디오 주파수 채널과 연관된 서비스 리스트 테이블을 시그널링하는 단계;
   상기 서비스 리스트 테이블 내의 서비스 정보를 시그널링하는 단계;
   상기 서비스 정보와 연관된 필수 정보를 시그널링하는 단계 - 상기 필수 정보는 상기 제1 라디오 주파수 채널 내의 상기 서비스가 제2 라디오 주파수 채널에 의해 배달된 하나 이상의 부분을 갖는다는 것을 표시하는 속성임 - ;
   상기 속성이 참인 경우에, 상기 서비스 정보에서 적어도 하나의 다른 방송 서비스 식별(OtherBSID) 엘리먼트를 시그널링하는 단계 - 상기 적어도 하나의 OtherBSID 엘리먼트는 부분 타입을 표시하고, 상기 부분 타입의 데이터 타입은 부호 없는 바이트(unsignedByte)임 - ;
   상기 속성이 거짓인 경우에, 상기 서비스 정보에서 어떤 OtherBSID 엘리먼트도 시그널링하지 않는 단계; 및
   상기 서비스 리스트 테이블을 전송하는 단계를 포함하는, 방법.
2. 제1항에 있어서, 상기 부분 타입을 표시하는 상기 적어도 하나의 OtherBSID 엘리먼트는 2인 값을 갖는 타입 속성인, 방법.
3. 비디오 서비스를 렌더링하기 위한 디바이스로서, 상기 디바이스는 하나 이상의 프로세서를 포함하고, 상기 하나 이상의 프로세서는
   제1 라디오 주파수 채널을 수신하고;
   상기 제1 라디오 주파수 채널 내의 제1 서비스 리스트 테이블을 수신하고;
   서비스 엘리먼트를 수신하기 위해 상기 제1 서비스 리스트 테이블을 파싱하고;
   상기 서비스 엘리먼트가 필수 정보 속성을 포함하는지를 결정하고;
   상기 필수 정보 속성이 존재하는 경우에, 상기 필수 정보 속성의 값을 결정하기 위해 상기 서비스 엘리먼트를 파싱하고;
   상기 필수 정보 속성의 값이 참인 경우에:
   하나 이상의 다른 방송 서비스 식별(OtherBSID) 엘리먼트를 수신하기 위해 상기 서비스 엘리먼트를 파싱하고;
   상기 하나 이상의 OtherBSID 엘리먼트 각각의 타입을 결정하고 - 상기 타입의 데이터 타입은 부호 없는 바이트임 - ;
   상기 필수 정보 속성의 값이 거짓인 경우에, 상기 서비스 엘리먼트를 파싱하지 않고 하나 이상의 OtherBSID 엘리먼트를 수신하지 않으며;
   상기 제1 서비스 리스트 테이블을 이용하여 상기 비디오 서비스를 렌더링하도록 구성된, 디바이스.

Images