KR20130066588A

KR20130066588A - 비실시간 서비스 처리 방법 및 방송 수신기

Info

Publication number: KR20130066588A
Application number: KR1020127027863A
Authority: KR
Inventors: 서종열
Original assignee: 엘지전자 주식회사
Priority date: 2010-03-29
Filing date: 2011-03-29
Publication date: 2013-06-20
Also published as: CA2794399A1; CA2851888C; WO2011122838A2; US20130014202A1; CA2989204A1; CA2851888A1; WO2011122838A3; US9154818B2; CA2794399C; CA2989204C; KR101809957B1

Abstract

방송 수신기에서 NRT(non-real time) 서비스를 처리하는 방법이 개시되며, 이 방법은, 인터넷을 통해 액세스될 수 있는 콘텐츠 아이템의 파일을 나타내는 액세스 정보와 NRT 서비스 정보를 포함하는 시그널링 정보를 수신하는 단계, FLUTE(File Delivery over Unidirectional Transport) 세션을 통해 FLUTE 파일을 수신하는 단계로서, 콘텐츠 아이템에 속하는 각각의 파일에 대한 FLUTE 세션의 FDT(File Delivery Table) 인스턴스는 파일의 콘텐츠 위치 정보를 포함하고, 콘텐츠 위치 정보는 URL(Uniform Resource Locator)을 포함하는, 단계, 및 콘텐츠 아이템에 속하는 파일을 사용하여 NRT 서비스를 제공하는 단계로서, 파일은 상기 파일의 콘텐츠 위치 정보에 표시된 URL을 사용하여 인터넷을 통해 액세스되거나 방송 수신기의 스토리지를 통해 액세스되는, 단계를 포함한다.

Description

비실시간 서비스 처리 방법 및 방송 수신기{METHOD OF PROCESSING NON-REAL TIME SERVICE AND BORADCAST RECEIVER}

본 발명은 비실시간 서비스 처리 방법 및 방송 수신기에 관한 것이다.

본 발명은 비실시간(non-real time)(이후 NRT로 축약)으로 송신되는 서비스의 서비스 유형, 방송 네트워크를 통한 서비스에 관한 상세 정보, 및 대응 정보를 수신하여 처리하는 NRT 수신기의 동작에 대한 시그널링 방법에 관한 것이며, 특히, NRT 콘텐츠와 관련된 파일을 액세스함으로써 NRT 서비스를 제공하는 방송 수신기 및 그 방법에 관한 것이다. 본 발명은 광범위한 어플리케이션에 적합하지만, 특히 서비스관련 시그널링 정보를 사용하여 대응 NRT 서비스에 관한 부가 정보를 얻고, 대응하는 서비스를 어떻게 처리하여 사용자에게 출력할 것인지를 결정하고, 관련 어플리케이션 모듈의 동작을 결정하는 수신기에 특히 적합하다.

본 발명의 일 과제는, 비실시간(non-real time)으로 송신되는 서비스의 서비스 유형, 방송 네트워크를 통한 서비스에 관한 상세 정보 및 대응 정보를 수신하여 처리하는 NRT 수신기의 동작하도록 하는 시그널링 방법을 제공하고자 한다.

본 발명의 다른 과제는, NRT 콘텐츠와 관련된 파일을 액세스함으로써 NRT 서비스를 제공하는 방송 수신기 및 그 방법을 제공하고자 한다.

본 명세서에서는 본 발명에 따른 비실시간 서비스 처리 방법 및 방송 수신기가 개시된다.

본 발명에 따른 방송 수신기의 비실시간 서비스 처리 방법의 일 예는, 인터넷을 통해 액세스될 수 있는 콘텐츠 아이템의 파일을 나타내는 액세스 정보와 NRT(non-real time) 서비스 정보를 포함하는 시그널링 정보를 수신하는 단계; FLUTE(File Delivery over Unidirectional Transport) 세션을 통해 FLUTE 파일을 수신하되, 상기 콘텐츠 아이템에 속하는 각각의 파일에 대한 FLUTE 세션의 FDT(File Delivery Table) 인스턴스는 파일의 콘텐츠 위치 정보를 포함하고, 상기 콘텐츠 위치 정보는 URL(Uniform Resource Locator)을 포함하는 단계; 및 상기 콘텐츠 아이템에 속하는 파일을 사용하여 NRT 서비스를 제공하는 단계;를 포함하여 이루어지되, 상기에서, 파일은 상기 파일의 콘텐츠 위치 정보에 표시된 URL을 사용하여 인터넷을 통해 액세스되거나 방송 수신기의 스토리지를 통해 액세스할 수 있다.

상기에서, NRT 서비스 정보는, 다른 파일을 액세스하기 전에 우선 액세스되어야 하는 파일을 나타내는 엔트리 파일을 포함할 수 있다.

상기에서, NRT 서비스 정보는, 상기 엔트리 파일에 대한 정보를 갖는 디스크립터를 포함하고, 상기 엔트리 파일에 대한 정보는 상기 엔트리 파일의 파일명을 포함할 수 있다.

상기에서, NRT 서비스 정보는, NRT 서비스 시그널링 테이블, NRT 서비스 맵 테이블(NRT service map table) 및 NRT 정보 테이블(NRT information table)을 포함할 수 있다.

그리고 상기에서, 파일이 FLUTE 세션을 통해서만 액세스될 때, 상기 파일은 절대 태그 URL 또는 상대 URL을 사용하여 액세스될 수 있다.

상기에서, 파일이 절대 태그 URL을 사용하여 액세스될 때, 상기 URL은 상기 파일에 대한 절대 URL일 수 있다.

상기에서, 파일이 상대 URL을 사용하여 액세스될 때, 상기 파일은 file://X/<content-location> 형태의 URL을 갖고, 상기 X는 방송 수신기가 알고 있는 임의의 가상 폴더일 수 있다.

상기에서, 태그 URL은, FLUTE 세션에서 결정되며 유니크할 수 있다.

상기에서, 인터넷을 통해 이용가능하지 않은 FLUTE 파일은, 상대 URL 또는 절대 태그 URI(Uniform Resource Identifier)를 콘텐츠 위치값으로 가질 수 있다.

본 발명에 따른 비실시간 서비스를 처리하는 방송 수신기의 일 예는, 인터넷을 통해 액세스될 수 있는 콘텐츠 아이템의 파일을 나타내는 액세스 정보와 NRT 서비스 정보를 포함하는 시그널링 정보를 수신하는 시그널링 정보 처리부; FLUTE(File Delivery over Unidirectional Transport) 세션을 통해 FLUTE 파일을 수신하되, 상기 콘텐츠 아이템에 속하는 각각의 파일에 대한 FLUTE 세션의 FDT(File Delivery Table) 인스턴스는 상기 파일의 콘텐츠 위치 정보를 포함하고, 상기 콘텐츠 위치 정보는 URL(Uniform Resource Locator)을 포함하는 파일 처리부; 및 상기 콘텐츠 아이템에 속하는 파일을 사용하여 상기 NRT 서비스를 제공하는 서비스 처리부;를 포함하되, 상기에서, 파일은 상기 파일의 콘텐츠 위치 정보에 표시된 URL을 사용하여 인터넷을 통해 액세스되거나 방송 수신기의 스토리지를 통해 액세스될 수 있다.

상기에서, NRT 서비스 정보는, 상기 엔트리 파일에 대한 정보를 포함하는 디스크립터를 포함하고, 상기 엔트리 파일에 대한 정보는 상기 엔트리 파일의 파일명을 포함할 수 있다.

상기에서, NRT 서비스 정보는, NRT 서비스 시그널링 테이블, NRT 서비스 맵 테이블, 및 NRT 정보 테이블을 포함할 수 있다.

상기에서, 파일이 FLUTE 세션을 통해서만 액세스될 때, 상기 파일은 절대 태그 URL 또는 상대 URL을 사용하여 액세스될 수 있다.

상기에서, 파일이 상대 URL을 사용하여 액세스될 때, 상기 파일은 형태 file://X/<content-location>의 URL을 갖고, 여기서 X는 방송 수신기가 알고 있는 임의의 가상 폴더일 수 있다.

상기에서, 인터넷을 통해 이용가능하지 않은 FLUTE 파일은 콘텐츠 위치값으로 상대 URL 또는 절대 태그 URI(Uniform Resource Identifier)를 가질 수 있다.

본 발명에 따르면,

첫째, 비실시간(non-real time)으로 송신되는 서비스의 서비스 유형, 방송 네트워크를 통한 서비스에 관한 상세 정보 및 대응 정보를 수신하여 처리하는 NRT 수신기의 동작하도록 하는 시그널링할 수 있는 효과가 있다.

둘째, NRT 콘텐츠와 관련된 파일을 액세스함으로써 NRT 서비스를 제공하는 방송 수신기 및 그 방법을 제공할 수 있는 효과가 있다.

본 발명의 보다 나은 이해를 제공하도록 포함되고, 본 출원서에 통합되어 출원서의 일부를 구성하는 첨부 도면은, 본 발명의 실시예(들)를 도시하며, 상세한 설명과 함께 본 발명의 원리를 설명하는 기능을 행한다. 도면에서,
도 1은 RT(real-time) 서비스와 NRT(non-real time) 서비스를 제공하는 개념도를 도시한다.
도 2는 NRT 서비스, 콘텐츠 아이템 및 파일 사이의 관계를 나타낸 도면이다.
도 3은 본 발명에 따른 fixed NRT 서비스를 위한 프로토콜 스택의 일 실시예를 나타낸 도면이다.
도 4는 본 발명에 따른 VCT(virtual channel table)의 비트스트림 신택스 구조를 나타낸 도면이다.
도 5는 본 발명에 따른 도 4의 VCT(virtual channel table) 내 서비스 유형의 의미 및 필드 값을 나타낸 도면이다.
도 6는 VCT 내 ATSC(Advanced Television Systems Committee) 서비스 유형의 개정된 의미 및 필드 값을 나타낸 도면이다.
도 7은 본 발명에 따른 DST(data service table)의 비트스트림 신택스 구조의 일 실시예를 나타낸 도면이다.
도 8은 PSI(Program Specific Information)/PSIP(Program and System Information Protocol) 테이블을 이용하여 NRT 서비스 시그널링 채널을 전송하는 IP 스트림의 접속 정보를 획득하는 다이어그램을 나타낸 도면이다.
도 9는 도 8의 PSI/PSIP 테이블을 이용하여 NRT 서비스 시그널링 채널을 전송하는 IP 스트림의 접속 정보를 획득하는 과정을 나타낸 흐름도이다.
도 10은 어플리케이션 식별 디스크립션 필드의 의미를 나타낸 도면이다.
도 11은 본 발명에 따른 어플리케이션 식별 디스크립션 필드의 제안된 의미를 나타낸 도면이다.
도 12는 본 발명에 따른 NRT 서비스 시그널링 테이블에서 사용되는 비트스트림 신택스 구조와 일반적인 테이블 포맷을 나타낸 도면이다.
도 13과 도 14는 본 발명에 따른 NRT 서비스 맵 테이블(NST)의 비트스트림 신택스 구조를 나타낸 도면이다.
도 15는 본 발명에 따른 MH 서비스 카테고리의 의미를 나타낸 도면이다.
도 16은 NRT 컴포넌트 디스크립터의 비트스트림 신택스 구조를 나타낸 도면이다.
도 17은 본 발명에 따라 구성된 ATSC-M/H(Mobile/Handheld)의 컴포넌트 유형의 의미를 나타낸 도면이다.
도 18은 본 발명에 따라 구성된 NRT_component_descriptor()의 비트스트림 신택스 구조를 나타낸 도면이다.
도 19는 본 발명에 따라 구성된 도 18의 component_descriptor()를 이용한 FLUTE(File Delivery over Unidirectional Transport) 파일 배송 NRT_component_data()의 비트스트림 신택스 구조를 나타낸 도면이다.
도 20은 본 발명에 따른 BCAST DCD 채널 디스커버리 정보의 다이렉트 배송을 통한 부트스트랩 시퀀스를 나타낸 도면이다.
도 21은 본 발명에 따른 BCAST ESG를 이용한 부트스트랩 시퀀스를 나타낸 도면이다.
도 22는 본 발명에 따른 OMA DCD DCD-2-broadcast-profile-type의 XML 스키마를 나타낸 도면이다.
도 23은 본 발명에 따른 OMA DCD DCD-2-broadcast-profile-type의 XML 스키마를 나타낸 도면이다.
도 24는 본 발명에 따라 구성된 NRT DCD 부트스트랩 디스크립터의 비트스트림 신택스 구조를 나타낸 도면이다.
도 25는 본 발명에 따라 구성된 NRT DCD 채널 디스크립터의 비트스트림 신택스 구조를 나타낸 도면이다.
도 26은 본 발명에 따른 OMA BCAST SG 방송 서비스 배송의 XML 스키마를 나타낸 도면이다.
도 27은 본 발명에 따라 제안된 NRT 서비스를 통한 접속 정보를 제공하도록 구성된 OMA BCAST SG 방송 서비스 배송의 XML 스키마를 나타낸 도면이다.
도 28 및 29는 본 발명에 따라 구성된 NRT-IT 섹션(NRT_information_table_section)의 비트스트림 신택스 구조를 나타낸 도면이다.
도 30 및 31은 본 발명에 따라 구성된 FDT XML 스키마를 나타낸 도면이다.
도 32는 본 발명에 따라 구성된 ATSC M/H 수신기의 블록도이다.
도 33은 본 발명에 따른 Fixed NRT를 수신하도록 구성된 방송 수신기의 블록도이다.

본 발명의 실시예가 도시된 도면을 참조하여 본 발명의 바람직한 실시예를 상세히 설명한다. 도면에서 동일하거나 유사한 부분에는 동일한 참조 번호를 사용한다.

본 발명에서 사용되는 용어는 본 발명에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어를 선택하였으나, 이는 당 분야에 종사하는 기술자의 의도 또는 관례 또는 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 그 상세한 의미는 본 발명의 상세한 설명 또는 바람직한 실시예에서 설명될 것이다. 따라서 본 발명에서 사용되는 용어는 단순한 명칭이 아니라 본 발명에 걸친 용어의 의미와 내용에 기초하여 정의될 필요가 있다.

본 발명에서 사용하는 용어 중 RT(real time) service는, 말 그대로 실시간 서비스를 의미한다. 즉, 시간에 구속받는 서비스이다. 이에 반해, NRT(non-real time) service는 상기 RT 서비스 이외의, 시간에 구속받지 않는 비실시간 서비스를 의미한다.

본 발명의 설명에서 사용되는 용어중, 메인 서비스 데이터는 고정된 수신 시스템에 의해 수신될 수 있는 데이터에 해당하며, A/V(audio/video) 데이터를 포함할 수 있다. 더 상세하게, 메인 서비스 데이터는 HD(high definition) 또는 SD(standard definition) 레벨의 A/V 데이터를 포함할 수 있으며, 데이터 방송에 필요한 다양한 데이터 유형을 포함할 수 있다. 또한, 알려진 데이터(known data)는 수신 시스템과 송신 시스템 사이에 미리 체결된 약속에 따라서 미리 알려진 데이터에 해당된다.

또한, 본 발명에서 사용하는 용어 중, "M/H" (또는 MH)는 "mobile"과 "handheld"의 이니셜에 대응되며, 고정된 유형의 시스템의 반대 개념을 나타낸다. 또한, M/H 서비스 데이터는 모바일 서비스 데이터와 핸드헬드 서비스 데이터 중 적어도 하나를 포함할 수 있으며, 간단하게 "모바일 서비스 데이터"로 칭해지기도 한다. 이후, M/H, MH, 모바일은 동일한 의미로 사용된다. 여기서, 모바일 서비스 데이터는 M/H 서비스 데이터에 해당할 뿐 아니라 모바일 또는 포터블 특징을 갖는 임의의 유형의 서비스 데이터를 또한 포함할 수 있다. 그러므로, 본 발명에 따른 모바일 서비스 데이터는 M/H 서비스 데이터에만 한정되는 것은 아니다.

상기 설명된 모바일 서비스 데이터는 프로그램 실행 파일, 주식 정보 등과 같은 정보를 갖는 데이터에 해당할 수 있으며, A/V 데이터에 또한 해당할 수 있다. 가장 특이하게, 모바일 서비스 데이터는 메인 서비스 데이터와 비교하여 더 낮은 해상도와 더 낮은 데이터 전송률을 갖는 A/V 데이터에 해당할 수 있다. 예를 들면, 종래의 메인 서비스에서 사용되는 A/V 코덱이 MPEG-2 코덱에 대응하면, 더 좋은 이미지 압축률을 갖는 MPEG-4 AVC(advanced video coding) 또는 SVC(scalable video coding)가 모바일 서비스용 A/V 코덱으로 사용될 수 있다. 또한, 임의의 유형의 데이터가 모바일 서비스 데이터로서 송신될 수 있다. 예를 들면, 실시간 전송 정보 또는 비실시간(NRT) 서비스 데이터용 TPEG(transport protocol expert group) 데이터가 메인 서비스 데이터로서 송신될 수 있다.

또한, 모바일 서비스 데이터를 이용하는 데이터 서비스는 일기 예보 서비스, 교통 정보, 시청자 참여 퀴즈 프로그램, 실시간 투표 및 의견조사, 상호 교육 방송 프로그램, 게임 서비스, 드라마 또는 시리즈물의 줄거리, 등장 인물, 배경 음악 및 촬영지에 대한 정보를 제공하는 서비스, 과거 전적 및 플레이어 프로필 및 수상실적에 대한 정보를 제공하는 서비스, 구매 주문을 처리하도록 서비스, 미디어, 시간, 및 테마에 의해 분류된 상품 정보 및 프로그램에 대한 정보를 제공하는 서비스를 포함할 수 있다.

본 발명의 전송 시스템은 NRT 서비스를 포함하는 모바일 서비스 데이터, 메인 서비스 데이터를 다중화하여 동일 또는 상이한 물리적 채널로, 현재 수신 시스템의 메인 서비스 데이터의 수신에 영향을 미치지 않고 전송할 수 있다(하위 호환성 : backward compatibility).

또한, 본 발명에 따른 전송 시스템은 모바일 서비스 데이터에 추가 인코딩을 행하여 수신 시스템과 송신 시스템이 이미 알고 있는 데이터(예를 들면, 알려진 데이터)를 삽입함으로써, 처리된 데이터를 송신할 수 있다.

그러므로, 본 발명에 따른 송신 시스템을 사용할 때, 수신 시스템은 이동 상태인 동안 모바일 서비스 데이터를 수신할 수 있고, 채널 내에서 생기는 여러가지 왜곡 및 노이즈에도 불구하고 안정되게 NRT 서비스를 포함한 모바일 서비스 데이터를 수신할 수 있다.

도 1은 NRT 서비스의 일 예의 개념도이다.

우선, 방송국은 기존 방식에 따라 RT(real time) 서비스를 송신한다. 이때, 방송국은 RT 서비스를 송신하고 그 과정에서 남는 대역폭을 이용하거나 또는 전용 대역폭을 이용하여 NRT 서비스를 제공할 수 있다. 이 경우, NRT 서비스는 뉴스 클립, 날씨 정보, 광고, Push VOD(video on demand) 용 콘텐츠 등을 포함할 수 있다.

그러나, 종래 기술의 DTV 수신기(즉, legacy device)는 채널에 포함된 NRT 스트림에 의해 그 동작이 영향을 받지 않는 것이 원칙이다. 그렇지만, 종래 기술의 DTV 수신기는 NRT 서비스를 적절하게 처리할 수 있는 수단이 구비되지 않아 방송국에 의해 제공된 NRT 서비스를 적절히 수신하여 처리할 수 없다는 문제점이 있다.

반면, 본 발명에 따른 방송 수신기(즉, NRT device)는 RT 서비스와 결합된 NRT 서비스를 수신하여 적절하게 처리할 수 있으므로, 시청자에게 종래의 DTV 수신기에 비해 다양한 기능을 제공할 수 있다.

이 경우, RT 서비스와 NRT 서비스는 동일 DTV 채널 또는 상이한 DTV 채널로 송신되고, MPEG-2 트랜스포트 패킷(TS) 또는 인터넷 프로토콜(IP) 데이터그램을 통해 송신될 수 있다. 그러므로, 수신기는 동일하거나 상이한 채널을 통해 송신되는 2종류의 서비스를 식별하는 것이 필요하다. 이를 위해, 본 명세서는 수신기가 NRT 서비스를 적절히 수신 및 처리할 수 있도록 시그널링 정보를 정의 및 제공하는 방법을 제공한다. 이때, 방송국이 시그널링 정보를 제공한다. 특히, NRT 서비스를 식별하기 위한 적어도 하나의 특정 PID(packet identifier)가 할당될 수 있다.

도 2는 NRT 서비스, 콘텐츠 아이템 및 파일 사이의 관계를 설명하기 위한 일 예의 도면이다.

도 2를 참조하면, NRT 서비스는 하나 이상의 콘텐츠 아이템을 포함할 수 있다. 또한, 각각의 콘텐츠 아이템은 하나 이상의 파일을 포함할 수 있다. 그리고, 각각의 콘텐츠 아이템은 독립적으로 재생가능한 엔티티이며, 실시간 방송의 프로그램 또는 이벤트에 대응할 수 있다. 그러므로, NRT 서비스는 상기 콘텐츠 아이템의 조합으로 서비스가능한 그룹을 의미한다. NRT 서비스는 실시간의 채널 개념에 대응한다.

수신기가 상기 NRT 서비스를 적절히 처리하기 위해서, 대응하는 NRT 서비스를 시그널링하는 것이 필요하다. 본 발명은, 시그널링 정보를 정의 및 제공함으로써, 수신기가 수신한 NRT 서비스를 적절히 처리하고자 하는 것이다. 더욱이, 시그널링 정보는 대응 부분의 설명에서 설명된다.

우선, NRT 서비스는 IP 데이터그램을 획득하는 유형에 따라서 fixed NRT 서비스 및 모바일 NRT 서비스로 크게 카테고리화될 수 있다. 다음의 설명에서, fixed NRT 서비스 및 모바일 NRT 서비스를, 설명을 편리하고 명확하게 하기 위해, 순차적으로 구체화한다.

도 3은 본 발명의 일 실시예에 따라서 구성된 fixed NRT 서비스의 프로토콜 스택을 나타내는 도면이다.

도 3을 참조하면, fixed NRT 서비스를 제공하는 프로토콜 스택은 MPEG-2-TS 포맷을 사용하여, NRT 콘텐츠 아이템/파일, NST 및 NCT를 제공하는 시그널링 채널을 포함하는 IP 데이터그램, 및 PSI(Program Specific Information)/PSIP(Program and System Information Protocol) 데이터를 송신한다.

도 3에서, fixed NRT 서비스는 IP 계층에서 UDP에 따라서 패킷화된다. UDP 패킷은 IP 방식에 따라서 다시 패킷화되어 UDP/IP 패킷 데이터가 된다. 본 명세서에서 패킷화된 UDP/IP 패킷 데이터를 설명의 편의를 위해 IP 데이터그램으로 명한다.

NRT 콘텐츠 아이템/파일은 FLUTE(File Delivery over Unidirectional Transport) 방식 또는 ALC/LCT(Asynchronous Layered Coding/Layered Coding Transport) 방식에 따라 패킷화된다. 상기 패킷화된 ALC/LCT 데이터는 다시 UDP 데이터그램으로 캡슐화되어 전송된다. 상기 ALC/LCT/UDP 패킷은 IP 데이터그램 방식에 따라 ALC/LCT/UDP/IP 패킷으로 패킷화되어 IP 데이터그램이 된다. 이 IP 데이터그램은 트랜스포트를 위해 DSM-CC 어드레서블 섹션을 통해 MPEG-2 TS에 포함된다. 이 경우, ALC/LCT/UDP/IP 패킷은 FLUTE 세션에 대한 정보이며, FDT를 또한 포함한다.

NST 및 NCT를 포함하는 시그널링 정보 채널은 UDP 방식에 따라 패킷화된다. 이 UDP 패킷은 다시 IP 방식에 따라 패킷화되어 UDP/IP 패킷 데이터, 즉, IP 데이터그램이 된다. 이 IP 데이터그램은 트랜스포트를 위해 DSM-CC 어드레서블 섹션을 통해 MPEG-2 TS에 또한 포함된다.

또한, PSI/PSIP 테이블은 별도로 정의되어, MPEG-2 TS에 포함된다.

NRT 콘텐츠 아이템/파일, 시그널링 정보 채널 및 PSI/PSIP 데이터를 그 안에 포함하는 MPEG-2 TS는 VSB 전송 방식과 같은 소정의 전송 방식에 의해 변조되어 전송된다.

도 4는 본 발명의 일 실시예에 따라서 구성된 VCT(Virtual Channel Table) 비트 스트림 섹션을 위한 도면이다.

도 4를 참조하면, VCT 섹션은 MPEG-2 프라이빗 섹션과 유사한 테이블 포맷을 갖는 것으로 서술된다. 그러나, 이것은 단지 일 예이며, 본 발명은 여기 주어진 예에 한정되는 것은 아니다.

VCT는 헤더, 바디, 및 트레일러로 나뉠 수 있다. 헤더 부분은 table_id 필드에서 protocol_version 필드까지의 범위이다. transport_stream_id 필드는 16비트 필드이며 다중화를 위해 '0'의 PID 값에 의해 정의된 PAT(program association table) 내의 MPEG-2 TSID를 나타낸다. 바디 부분에서, num_channels_in_section 필드는 8비트 필드이며, VCT 섹션 내의 가상 채널 번호를 나타낸다. 최종적으로, 테일 부분은 CRC_32 필드를 포함한다.

우선, 헤더 부분을 설명하면 다음과 같다.

table_id 필드는, 여기에 정의된 테이블 섹션의 유형을 나타내는 8비트 언사인드(unsigned) 정수이다. virtual_channel_table_section()에 대해서, table_id는 '0xC8'이다.

section_syntax_indicator 필드는 virtual_channel_table_section()에 대해서 '1'로 설정되는 1비트 필드이다.

private_ indicator 필드 (1 비트)는 '1'로 설정된다.

section_length 필드는 12 비트 필드이며, 처음 2비트는 '00'이다. 이 필드는 section_length 필드 바로 다음에 시작하며 CRC를 포함하는 섹션의 바이트의 수를 명시한다. 이 필드의 값은 1021을 넘지 않는다.

table_id_extention 필드는 '0x000'으로 설정된다.

version_number 필드 (5비트)는 VCT의 버전 번호를 표시한다. 현재의 VCT (current_next_indicator = '1')에 대해서, 현재의 VCT의 정의가 변화할 때 마다, 버전 번호는 1만큼 증가된다. 값 '31'에 도달하면, '0'으로 랩어라운드된다. 다음의 VCT (current_next_indicator = '0')에 대해서(또한 modulo 32 연산에서), 버전 번호는 현재의 VCT 보다 1 단위 많다. 임의의 경우에, version_number의 값은 MGT의 대응하는 엔트리와 일치한다.

current_next_indicator 필드는 1비트 지시자이며, '1'로 설정되면 송신된 VCT가 현재 어플리케이션 가능한 것을 나타낸다. 이 비트가 '0'으로 설정되면 송신된 테이블이 아직 어플리케이션 가능하지 않은 것을 나타내며, 다음의 테이블(current_next_indicator가 '0'으로 설정)은 유효하게 된다. 이 표준은 "다음의" 테이블이 반드시 송신되어야 하는 것을 요구하지 않는다. 현재 어플리케이션가능한 테이블의 업데이트는 version_number 필드를 증가시킴으로써 시그널링된다.

section_number 필드 (8비트)는 이 섹션에 번호를 제공한다. TVCT의 제1 섹션의 section_number는 '0x00'이다. TVCT에서 각각의 추가 섹션에서 1만큼 증가한다.

last_section_number 필드 (8비트)는 컴플릿 TVCT의 최종 섹션(즉, 가장 높은 section_number를 갖는 섹션)의 번호를 명시한다.

protocol_version 필드는 8비트 언사인드 정수 필드이며, 미래에, 해당 테이블 유형이 현재 프로토콜에서 정의된 것과 다르게 구성될 수 있는 파라미터를 갖는 것을 허용하는 기능을 한다. 현재, protocol_version에 대해서 유효한 값은 오직 제로뿐이다. 비제로값의 protocol_version은 구조적으로 다른 테이블을 나타내는 이 표준의 미래 버전에서 사용될 수 있다.

바디 부분의 설명은 다음과 같다.

num_channels_in_section 필드 (8 비트)는 이 VCT 섹션에서 가상 채널의 수를 명시한다. 이 수는 섹션 길이에 의해 제한된다.

short_name 필드는 0 ~ 16 비트 코드 값의 시퀀스로 표현되는, 가상 채널명을 명시한다.

major_channel_number 필드는 'for' 루프의 반복으로 정의된 가상 채널과 관련된 '메이저(major)' 채널 개수를 표현하는 10비트 번호이다. 각각의 가상 채널은 메이저 및 마이너 채널 번호와 관련된다. 메이저 채널 번호는 마이너 채널 번호와 함께 가상 채널용 사용자의 참조 번호로서 기능한다. major_channel_number는 '1'과 '99' 사이에 있다. major_channel_number/minor_channel_number 쌍이 TVCT 내에서 중복되지 않도록 major_channel_number의 값이 설정된다.

minor_channel_number 필드는 "minor" 또는 "sub"-채널 번호를 표현하는 '0' ~ '99' 범위에 있는 10비트 번호이다. 이 필드는 major_channel_number와 함께, two-part의 채널 번호로서 기능하며, minor_channel_number는 두번째 또는 오른쪽 부분의 번호를 나타낸다. service_type이 아날로그 텔레비젼이면, minor_channel_number는 '0'으로 설정된다. service_type이 ATSC_digital_television 또는 ATSC_audio_only인 서비스는 '1'과 '99' 사이의 마이너 번호를 사용한다. major_channel_number/minor_channel_number 쌍이 TVCT 내에서 중복되지 않도록 minor_channel_number의 값이 설정된다. 데이터 방송과 같은, 다른 유형의 서비스에 대해서, 유효 마이너 가상 채널 번호는 '1'과 '999' 사이에 있다.

modulation_mode 필드는 이 가상 채널과 관련된 송신된 캐리어에 대한 변조 모드를 나타내는 8비트 언사인드 정수이다.

carrier_frequency 필드는 이들 32 비트에 대해 추천된 값이 제로인 것을 포함한다. 이 필드는 캐리어 주파수를 식별하기 위해 사용될 수는 있지만, 권하지는 않는다.

channel_TSID 필드는 이 가상 채널에 의해 참조된 MPEG-2 프로그램을 전송하는 TS와 관련된 MPEG-2 TSID를 표현하는 '0x0000' ~ '0xFFFF' 범위의 16비트 언사인드 정수 필드이다.

program_number 필드는 MPEG-2 PROGRAM ASSOCIATION 및 TS PROGRAM MAP 테이블로 정의되는 가상 채널과 관련된 16비트 언사인드 정수이다. 아날로그 서비스를 표현하는 가상 채널에 대해서, '0xFFFF' 값이 program_number로 지정된다.

ETM_location은 ETM(Extended Text Message)의 존재와 위치를 지정하는 2비트 필드이다.

access_controlled 필드는 1비트 불리안(Boolean) 플래그이며, 설정되면, 이 가상 채널과 관련된 이벤트가 액세스 제어될 수 있는 것을 나타낸다. 이 플래그가 '0'으로 설정되면, 이벤트 액세스는 제한되지 않는다.

hidden 필드는 1비트 불리안 플래그이며, 설정되면, 가상 채널 번호의 직접 입력에 의해 가상 채널이 사용자에 의해 액세스되지 않은 것을 나타낸다. 사용자가 채널 탐색(channel surfing)을 할 때 히든 가상 채널은 스킵되며, 직접 채널 입력에 의해 액세스되면 지정되지 않은 것처럼 표시된다. 히든 채널과 그 이벤트가 EPG 디스플레이에 나타날 수 있는지 아닌지는 hide_guide 비트의 상태에 따른다.

hide_guide 필드는, 히든 채널에 대해서 '0'으로 설정될 때, 가상 채널과 그 이벤트가 EPG 디스플레이에 나타날 수 있는 것을 표시한다. 이 비트는 히든 비트 세트를 가지지 않는 채널에 대해서는 무시되므로, hide_guide 비트의 상태에 상관없이 넌-히든(non-hidden) 채널과 그 이벤트는 EPG 디스플레이에 항상 포함될 수 있다. '1'로 설정된 hide_guide 비트를 갖는 히든 채널에 대한 전형적인 어플리케이션은 어플리케이션-레벨 포인터를 통해 액세스 가능한 테스트 신호와 서비스이다.

service_type 필드는 해당 가상 채널로 전송되는 서비스 유형을 식별하는 6비트 이뉴머레이티드 유형(enumerated type) 필드이다. 여기서, 도 6은 본 발명에 따른 ATSC 서비스 유형의 일 예의 도면이며, 도 7은 본 발명에 따른 ATSC 서비스 유형의 또 다른 예의 도면이다.

본 발명에 따르면, fixed NRT 서비스는 종래의 ATSC 지상파 방송 환경을 사용한다. 특히, fixed NRT 서비스는 DSM-CC 어드레서블 섹션을 통해서 IP 데이터그램을 전송하는 방식에 기초하며, 예를 들면 다음 방식에 의해 제공될 수 있다.

1. 오디오 및/또는 비디오를 포함하는 가상 채널을 통한 전송의 경우: 이 경우, 대응하는 가상 채널의 서비스 유형은, 종래의 ATSC 사양에 명시된 것같이, 도 5를 따를 수 있다. 특히, 서비스 유형은, 본 발명에서 제안된 것같이, 도 6에 나타낸 ATSC data only service를 나타내는 '0x04'를 따른다. 또는, 종래 기술의 또 다른 서비스 유형에 포함됨으로써 서비스 유형은 NRT 서비스를 식별할 수 있다.

NRT 서비스만을 포함하는 가상 채널을 통한 전송의 경우: 도 6을 참조하면, 새로운 서비스 유형 값을 할당함으로써 NRT 어플리케이션('0x05')을 나타내도록 시그널링이 행해질 수 있다.

source_id 필드 (16 비트)는 가상 채널에 관련된 프로그래밍 소스를 나타낸다.

descriptor_length 필드는 다음에 오는 가상 채널에 대한 디스크립터의 전체 길이(바이트)이다.

descriptor() 필드는, 적절히 포함될 수 있는 제로 이상의 디스크립터를 포함한다.

additional_descriptors_length 필드는 다음에 오는 VCT 디스크립터 리스트의 전체 길이(바이트 단위)이다.

트레일 부분은 다음과 같이 설명된다.

CRC_32 필드는 디코더의 레지스터로부터 제로 출력을 확실하게 하는 CRC(Cyclic Redundancy Check)를 포함하는 32비트 필드이다.

NRT 콘텐츠는 IP 메카니즘을 통해 전송된다. 디지털 방송 스트림을 통해 IP 데이터그램을 전송하기 위해 ATSC는 ATSC A/90 및 A/92 사양을 조절한다.

상기 설명에서, DST(Data Service Table)은 service_location_descriptor에 포함된 PID를 통해 수신될 수 있다. 그리고, DST를 통해서 해당 채널로 전송되는 데이터 방송 스트림의 어플리케이션 유형 및 상세 정보를 알 수 있다.

도 7은 본 발명의 일 실시예에 따라 구성된 NRT 어플리케이션을 식별하기 위한 DST 섹션의 비트스트림 신택스를 나타낸 도면이다.

data_service_table_byte 구조를 포함하는 필드의 시맨틱스가 아래에 정의되어 있다.

sdf_protocol_version 필드 (8비트)는, Service Description Framework(SDF) 프로토콜의 버전을 명시하기 위해 사용된다. 이 필드의 값은 '0x01'로 설정되어 있다. 값 '0x00'과 '0x02' ~ '0xFF' 범위의 값은 ATSC 예비되어 있다(reserved).

application_count_in_section 필드 (8비트)는, DST 섹션 내 리스트 된 어플리케이션들의 수를 명시한다.

compatibility_descriptor() 필드는, DSM-CC 호환성 디스크립터를 포함한다. 그 목적은 수신 플랫폼이 해당 데이터 서비스를 사용하기 위해 그 능력을 판단하도록 어플리케이션의 호환성 요구사항들을 시그널링하는 것이다.

app_id_byte_length 필드 (16비트)는, 어플리케이션을 식별하는데 사용되는 바이트들의 개수를 명시한다. 이 필드의 값은 뒤에 오는 app_id_description 필드 및 app_id_byte 필드의 길이를 설명한다. 값 '0x0000'은 app_id_description 필드 또는 app_id_byte 필드가 뒤에 오지 않는 것을 나타낸다. 값 '0x0001'은 포비든(forbidden)이다.

app_id_description 필드 (16비트)는, 다음의 어플리케이션 식별 바이트의 포맷과 시맨틱스를 명시한다.

표 1은 어플리케이션 식별자의 값과 관련 포맷을 명시한다. 이 경우, app_id_description 필드의 값이 '0x0003'으로 설정되어 있으면, 수신기는 해당 어플리케이션이 NRT 어플리케이션임을 알 수 있다.

값	어플리케이션 식별자 포맷
0x0000	DASE 어플리케이션
0x0001	ATSC 예비
0x0002	ATSC A/92 어플리케이션
0x0003	NRT 어플리케이션
0x0004-0x7FFF	ATSC 예비
0x8000-0xFFFF	User 프라이빗

app_id_byte 필드 (8비트)는, 어플리케이션 식별자의 바이트를 표현한다.

tap_count 필드 (8비트)는, 해당 어플리케이션에 의해 사용되는 Tap() 구조들의 개수를 명시한다.

protocol_encapsulation 필드 (8비트)는, Tap() 필드에 의해 참조되는 특정 데이터 엘리먼트를 전송하기 위해 사용되는 프로토콜 인캡슐레이션의 유형을 명시한다. 다음의 표 2는 프로토콜 인캡슐레이션의 유형의 일 예의 다이어그램이다.

값	캡슐화된 프로토콜(Encapsulated Protocol)
0x00	MPEG-2 트랜스포트 스트림에 없음
0x01	DSM-CC 섹션에서 캡슐화된 DSM-CC 다운로드 프로토콜의 비동기 넌-플로우 제어된 시나리오
0x02	DSM-CC 섹션에서 캡슐화된 넌-스트리밍 동기화된 다운로드 프로토콜
0x03	LLC/SNAP 헤더를 이용한 어드레서블 섹션에서 비동기 멀티프로토콜 데이터그램
0x04	어드레서블 섹션에서 비동기 IP 데이터그램
0x05	PES에서 캡슐화된 동기화된 스트리밍 데이터
0x06	PES에서 캡슐화된 동기 스트리밍 데이터
0x07	LLC/SNAP 헤더를 이용한 PES에서 동기화된 스트리밍 멀티프로토콜 데이터그램
0x08	LLC/SNAP 헤더를 이용한 PES에서 동기 스트리밍 멀티프로토콜 데이터그램
0x09	PES에서 동기화된 스트리밍 IP 데이터그램
0x0A	PES에서 동기 스트리밍 IP 데이터그램
0x0B	독점 데이터 파이핑
0x0C	SCTE DVS 051 비동기 프로토콜 [19]
0x0D	DSM-CC 섹션에서 캡슐화된 DSM-CC 다운로드 프로토콜의 비동기 캐러셀 시나리오
0x0E	다른 표준 바디와의 조화를 위해 예비
0x0F-0x7F	ATSC 예비
0x80-0Xff	사용자 지정

action_type 필드 (7비트)는, Tap() 필드에 의해 참조되는 데이터의 성질을 나타낸다.

resource_location 필드 (1비트)는, 다음 Tap 구조에서 리스트된 association_tag 값과 매칭되는 Association Tag 필드의 위치를 명시한다. 일치하는 association_tag가 현재 MPEG-2 프로그램의 PMT 내 존재하면, 이 비트가 '0'으로 설정된다. 일치하는 association_tag가 이 데이터 서비스의 Network Resources Table 내 DSM-CC Resource Descriptor에 존재하면, 이 비트가 '1'로 설정된다.

tap_id 필드 (16비트)는 데이터 엘리먼트들을 식별하기 위해 어플리케이션에서 사용된다. tap_id의 값은 DST 내 Tap()와 관련된 app_id_byte 필드들의 값에 의해 범위가 정해진다. tap_id 필드는 오소링시(authoring time) 데이터 서비스 제공자에 의해 선택된다. 또한, 그것은 데이터 엘리먼트를 다루기 위해 어플리케이션에서 사용된다.

use 필드 (16비트)는, association_tag에 의해 참조되는 통신 채널을 특정하기 위해 사용된다. '0x0000' 이외의 use 값의 사용은 이 표준 범위 밖이다. use 값 '0x0000'은 이 필드가 알려지지 않은(unknown) 것을 나타낸다.

association_tag 필드 (16비트)는, PMT에 나열된 데이터 엘리먼트리 스트림 또는 Network Resource Table에 나열된 DSM-CC 리소스 디스크립터 중 어느 하나를 유일하게 식별한다. 전자의 경우, 이 필드의 값은 데이터 서비스의 PMT 내 association_tag_descriptor의 association_tag 값과 일치한다. 후자의 경우, 이 필드의 값은 데이터 서비스의 Network Resource Table에서 DSM-CC 리소스 디스크립터의 commonDescriptorHeader 구조의 association_tag 값과 일치한다.

selector() 필드는, association_tag 필드에 의해 참조되는 통신 채널 또는 데이터 엘리먼트리 스트림 내에 이용 가능한 특정 데이터 엘리먼트를 명시한다. 게다가, 상기 selector 구조는 해당 데이터 엘리먼트를 얻는데 요구되는 프로토콜을 나타낼 수 있다.

tap_info_length 필드 (16비트)는, 이 tap_info_length 필드 다음의 디스크립터들의 바이트의 수를 명시한다.

descriptor() 필드는, 디스크립터 포맷 뒤에 온다.

app_info_length 필드 (8비트)는, 이 app_info_length 필드 다음의 디스크립터들의 바이트 수를 명시한다.

또 다른 descriptor() 필드는, 디스크립터 포맷을 따른다.

app_data_length 필드 (16비트)는, 다음의 app_data_byte 필드들의 길이를 바이트 단위로 명시한다.

app_data_byte (8비트)는, 어플리케이션과 관련된 입력 파라미터들 및 다른 프라이빗 데이터 필드들의 1바이트를 나타낸다.

service_info_length 필드 (8비트)는, 이 service_info_length 필드 다음의 디스크립터들의 바이트의 수를 명시한다.

또 다른 descriptor() 필드는, 디스크립터 포맷을 따른다.

service_private_data_length 필드 (16비트)는, 뒤에 오는 프라이빗 필드들의 길이를 바이트 단위로 명시한다.

service_private_data_byte 필드 (8비트)는, 1바이트의 프라이빗 필드를 표현한다.

NRT 어플리케이션이 식별된 후, IP 계층을 통해 배송된 NRT 서비스 시그널링 데이터를 배송하는 잘 알려진(well-known) IP 어드레스로 IP 스트림이 탭 정보를 이용하여 검색된다.

protocol_encapsulation의 값이 ‘0x04’로 설정되면, 비동기 IP 데이터그램이 전송된다. selector_type이 ‘0x0102’로 설정되면, 목적지 어드레스를 나타내는 device_id의 값이 selector_bytes를 통해 배송된다. selector_bytes의 값을 정확히 해석하기 위해, multiprotocol_encapsulation_descriptor가 사용된다. 그리고, in the device_id 값에서 유효한 바이트의 개수가 시그널링된다.

그러므로, 탭 정보를 통해서 대응하는 PID 상에서 전송되는 IP 데이터그램의 멀티캐스트 어드레스(또는, 어드레스 범위)를 알 수 있다.

NRT 서비스 시그널링 데이터가 배송되는 잘 알려진 IP 어드레스가 탭에 로드되었는지가 체크된다. 이것은 첫번째 위치에 수신된다. 그 다음 IP 패킷이 수신된다.

NRT 서비스 시그널링 데이터가 IP 패킷에서 추출된다. 추출된 NRT 서비스 시그널링 데이터는 NRT 어플리케이션 관리자로 배송되어 처리된다. NRT 서비스가 시작될 수 있다.

상기 설명에서 언급한 것같이, NRT 서비스 시그널링 채널은 잘 알려진 IP 어드레스를 통해 IP 데이터그램에서 캡슐화됨으로써 멀티캐스트된다.

도 8은 본 발명의 또 다른 실시예에 따라서 ATSC 방송 시스템을 통해 NRT 서비스를 전송하는 경우에 시그널링 방법의 일 예의 다이어그램이며, 도 9는 도 8의 일 예의 플로우챠트이다.

도 8은 IP 측을 통해 별개의 NRT 서비스 시그널링 채널을 구성하는 방법을 나타낸다. 이 경우, NRT 서비스 시그널링 채널은 잘 알려진 IP 어드레스를 통해 IP 데이터그램에서 캡슐화됨으로써 멀티캐스트된다. 이 경우의 시그널링 구조가 도 8에 도시되어 있다. 특히, IP 멀티캐스트 스트림으로서 별개의 NRT 서비스 시그널링 채널이 존재하는 것이 관찰될 수 있는 반면, 모든 시그널링이 PSIP 측에서 행해진다.

VCT는 채널 개념과 유사하며, 예를 들면, VCT_PID는 ‘0x1FFB’와 같다. VCT의 service_type은, 이 서비스가 NRT 어플리케이션인 것을 식별하는 현재의 VCT의 서비스 유형을 참조하며, 예를 들면, ‘0x95’와 동일한 stream_type은 이것이 DST(Data Service Table)과 관련되어 있는 것을 의미한다. DST에서 app_id_description 필드는 이 서비스가 NRT 어플리케이션인 것을 또한 식별한다. 도 8에 나타낸 것같이, PMT의 association_tag는 DST의 Tap association_tag와 동일한 값을 갖는다. PMT와 DST 사이의 관련 태그를 일치시킨 후, PMT의 elementary_PID는 NRT 서비스 시그널링 채널 또는 NRT 서비스의 IP 데이터그램을 식별하는 것이 필요하다. 상기 설명한 것같이, protocol_encapsulation = 0x04이면, 비동기 IP 데이터그램이 전송된다. selector_type이 ‘0x0102’로 설정되면, 목적지 어드레스를 나타내는 device_id의 값이 selector_bytes를 통해 배송된다. selector_bytes의 값을 정확히 해석하기 위해, multiprotocol_encapsulation_descriptor가 사용된다. 그리고, device_id 값에서 유효한 바이트의 개수가 시그널링된다.

하위 계층의 통신 채널에 포함된 어플리케이션-레벨 데이터 엘리먼트를 구하기 위해 DST에서 Tap()이 사용된다. association_tag 필드의 사용을 통해 어플리케이션-레벨 데이터 엘리먼트와 Tap() 사이에 연합이 이루어진다. Tap 구조에서 association_tag 필드의 값은 현재의 PMT에 존재하는 Association Tag descriptor에 위치하는 association_tag 필드 또는 Network Resource Table에 존재하는 dsmccResourceDescriptor descriptors 중 하나의 commonDescriptorHeader에 위치하는 associationTag 필드의 값에 대응한다. 데이터 서비스에서, 동일한 association_tag 값이 하나 이상의 Tap 구조에서 특징지어진다. association_tag는 데이터 엘리먼트의 위치를 결정하기 위한 베이스로서 사용된다. 이 베이스에 관하여, 데이터 엘리먼트의 위치는 셀렉터 구조에 의해 더욱 특정될 수 있다. 데이터 수신기는 엘리멘터리 스트림 버퍼를 적절히 분할할 수 있도록 모든 동기화된 데이터 엘리멘터리 스트림의 참조 리스트를 데이터 서비스에 필요로 한다. 따라서, DST는 데이터 서비스에 속하는 stream_type 값 0x06 또는 0x14의 데이터 엘리멘터리 스트림의 각각에 대해서 적어도 하나의 Tap()을 포함한다.

multiprotocol_encapsulation_descriptor는, protocol_encapsulation 필드의 값이 0x03 또는 0x04와 같을 때, 데이터 서비스 테이블에서 Tap 구조의 다음에 오는 디스크립터 루프에 포함될 수 있다. 디스크립터는 특정 어드레싱 방식으로의 deviceId 필드의 매핑을 정의하는 정보를 제공한다. 디스크립터는 0x0102와 같은 selector_type 필드 값을 포함하는 Tap()의 셀렉터 바이트에 명시된 deviceId 필드에서 유효 바이트의 수에 관한 정보를 제공한다. 마지막으로, 디스크립터는 신호 정렬 및 프로토콜 프래그멘테이션 규칙에 사용될 수 있다.

deviceId_address_range=0x06 은 유효한 deviceID_address 바이트가 deviceId[47…0]와 같은 것을 의미한다. 또한 deviceId_IP_mapping_flag는 1로 설정되면 IP를 MAC 어드레스 매핑으로 시그널링하는 것을 의미한다.

alignment_indicator는 DSMCC_addressable_section과 트랜스포트 스트림 바이트 사이의 바이트 레벨 정렬을 나타낸다.

max_sections_per_datagram은 8비트 필드이며, 단일 데이터그램 유닛을 전송하기 위해 사용될 수 있는 섹션의 최대 수를 나타낸다.

또한, NRT 서비스 시그널링 채널 (NST 및 NCT)에 대한 잘 알려진 IP 어드레스는 PMT와 관련된 elementary_PID를 통해 정의된다. 더욱이, NRT 서비스 시그널링 데이터는 IP 데이터그램의 NRT 서비스 시그널링 채널의 잘 알려진 IP address를 통해 송수신될 수 있다. NRT 서비스 시그널링 데이터는 Transport Packet (TP) 또는 Internet Protocol (IP)로 전송될 수 있다.

도 9는 상기 설명에 관한 플로우챠트이다.

도 9를 참조하면, 수신기의 전원이 온으로 된 후, 디플로트 채널 ㄸ또또는 사용자에 의한 채널이 선택되면[S1001], 수신기는 VCT 또는 PMT를 수신한다[S1002].

이에 대해서, 각각의 가상 채널을 구성하는 스트림에 관한 정보가, VCT의 service_location_descriptor 또는 PMT의 ES_loop에 시그널링된다. 그러므로, 수신기는 수신된 VCT 내에서 service_type을 파싱하여, 선택된 채널에 제공되는 서비스의 유형을 결정한다[S1003]. 예를 들면, service_type의 값이 ‘0x02’로 설정되면, 선택된 채녈에 제공되는 대응 서비스의 유형이 디지털 A/V 데이터 서비스 유형인 것을 의미할 수 있다. service_type의 값이 ‘0x04’로 설정되면, 선택된 채녈에 제공되는 대응 서비스의 유형이 데이터 온리(data only) 서비스 유형인 것을 의미할 수 있다. service_type의 값이 ‘0x08’로 설정되면, 선택된 채녈에 제공되는 대응 서비스의 유형이 NRT 온리(only) 서비스 유형인 것을 의미할 수 있다.

결정 단계 [S1003]의 결과로서, 대응 서비스 유형이 일반적인 A/V 서비스가 아니면, VCT의 채널 루프의 service_location_descriptor를 파싱하여 data service table (DST)의 PID (‘0x61’) 가 추출된다 [S1004].

이어서, 추출된 PID를 사용하여 DST가 수신된다[S1005].

수신된 DST로부터, 선택된 채녈에 제공되는 대응 서비스가 NRT 서비스인지가 판정된다[S1006]. 이때, DST 내의 app_id_description을 검사함으로써, NRT 서비스의 존재 또는 부재의 판정이 행해질 수 있다. 예를 들면, app_id_description의 값이 ‘0x0003’로 설정되면, 대응 서비스가 NRT 어플리케이션인 것을 의미한다.

결정 단계 [S1006]의 결과로서, 대응 서비스가 NRT 서비스이면, NRT 서비스 시그널링 채널을 포함하는 탭이 추출된다[S1007]. 그리고, PMT의 탭의 association_tag를 포함하는 elementary_PID가 추출된다[S1008].

elementary_PID가 수신된 후, DSM-CC 어드레서블 섹션이 처리된다 [S1009].

다음에, NRT 서비스 시그널링 채널의 잘 알려진 IP 어드레스로부터 IP 패킷이 수신된 후 [S1010], 수신된 IP 패킷 내의 NRT 서비스 시그널링 데이터를 처리하여 NRT 서비스가 제공된다 [S1011].

이에 대해, 상기 방법에 의해 NRT 어플리케이션이 가상 채널에 존재하는지를 검사한 후, IP 계층을 통해 전송된 NRT 서비스 시그널링 데이터가 배송되는, 잘 알려진 IP address를 갖는 IP 스트림이 탭 정보를 이용하여 검색된다.

protocol_encapsulation의 값이 ‘0x04’로 설정되면, 비동기 IP 데이터그램이 전송된다. selector_type이 ‘0x0102’로 설정되면, 목적지 어드레스를 나타내는 device_id의 값이 selector_bytes를 통해 배송된다.

그러므로, IP 데이터그램의 멀티캐스트 어드레스(또는, 어드레스 범위)에 관한 탭 정보를 통해서, 대응 데이터가 전송되는 트랜스포트 스트림의 PID를 알 수 있다. NRT 서비스 시그널링 데이터가 배송되는 잘 알려진 IP 어드레스가 탭에 로드되는지가 검사된다. 이것은 제1 위치에서 수신된다. 그 다음에, IP 패킷이 수신된다.

다음에, IP 패킷으로부터 NRT 서비스 시그널링 데이터가 추출된다. 추출된 NRT 서비스 시그널링 데이터가 NRT 어플리케이션 관리자에게 배송된다. 그 다음, 대응 서비스가 개시된다.

도 10은 DST 테이블의 App_id_description 다음에 오는 어플리케이션 식별 바이트의 의미와 포맷을 나타낸다.

도 11은 본 발명에서 제안되는 필드의 의미를 나타낸다. 도 11은 도 10의 필드가, NRT 어플리케이션의 App_id_description의 값에 대해 새로운 값 "0x0003"을 갖도록 확장된 것을 도시한다. 이 경우, Application_id_byte의 값은 NRT 어플리케이션의 Service ID 값과 동일하다. NRT 어플리케이션에 대한 Service ID는 전반적으로 특정 식별자인 URI 값을 가질 수 있다.

도 12는 본 발명에 따라 구성된 NRT 서비스 시그널링 테이블의 비트스트림 신택스 구조이다. NRT 서비스 시그널링 채널이 잘 알려진 IP 어드레스를 통해 IP 데이터그램에 스택되어 멀티캐스트된다. 시그널링 데이터는 MPEG-2 프라이빗 섹션(Private section)과 유사한 테이블을 가지며, 해당 필드들의 정의는 다음과 같다.

table_id 필드는 이 섹션이 속하는 NRT 서비스 시그널링 테이블을 식별하는 8 비트 필드이다.

section_syntax_indicator 필드는, 이 테이블이 MPEG-2 프라이빗 섹션 테이블의 "short" form에서 도출되는 것을 항상 나타내기 위해 '0'으로 설정되는 1비트 필드이다.

private_indicator 필드는 '1'로 설정되는 1비트 필드이다.

section_length 필드는 12비트 필드이며, 해당 필드 바로 다음의 이 테이블 섹션의 나머지 바이트의 수를 명시한다. 이 필드의 값은 4093(0xFFD)를 초과하지 않는다.

table_id_extension 필드는 16비트 필드이고, 테이블에 종속되어 있다. 남은 필드들의 범위를 제공하는 table_id 필드의 논리적인 부분인 것으로 고려된다.

version_number 필드는 5비트 필드이고, NRT 서비스 시그널링 테이블 섹션의 버전 번호이다. version_number는, M/N 서비스 시그널링 테이블 섹션내 보유된 정보에 변화가 있으면 1 modulo 32에 의해 증가된다.

current_next_indicator 필드는 1비트이며, '1'로 설정되면, 송신된 MH_service_signaling_section이 현재 이용가능한 것을 나타낸다. current_next_indicator가 '0'으로 설정되면, 송신된 MH_service_signaling_section이 아직 이용가능하지 않으며, 동일한 section_number, table_id_extention, 및 table_id를 갖는 다음의 MH_service_signaling_section이 유효하게 되는 것을 의미한다.

section_number 필드는 이 NRT 서비스 시그널링 테이블 섹션의 섹션 번호를 제공하는 8비트 필드이다. M/H Service Signaling 테이블의 제1 섹션의 section_number는 0x00이다. 이 section_number는 NRT 서비스 시그널링 테이블의 각각의 추가 섹션에서 1만큼 증가된다.

last_section_number 필드는, 이 섹션이 일부인, NRT 서비스 시그널링 테이블의 가장 높은 section_number를 갖는 섹션을 의미하는 최종 섹션의 번호를 주는 8비트 필드이다.

도 13 및 도 14는 본 발명의 실시예에 따른 NRT service map table(NST) 섹션의 비트스트림 신택스 구조를 도시한다. NST 섹션의 각 필드의 상세를 다음에 설명한다.

이해를 돕기 위해 신택스가 MPEG-2 프라이빗 섹션 포맷으로 쓰여지지만, 데이터는 임의의 포맷으로도 가능하다. 예를 들면, 신택스가 Session Description Protocol(SDP) 포맷으로 표현되고, Session Announcement Protocol(SAP)를 통해 시그널링되는 또 다른 방법을 사용할 수 있다.

도 13 및 도 14에서, table_id 필드는 NRT service map table(NST)에서 정의되는 테이블 섹션의 유형을 나타내는 8비트 언사인드 정수를 포함한다.

private_indicator 필드 (1비트)는 대응하는 섹션의 유형이 프라이빗 섹션 유형을 따르는지 아닌지를 나타낸다(이 필드는 '1'로 설정된다).

table_id_extension 필드는 16비트 필드이고, 테이블에 종속되어 있다. 이 필드는 남은 필드들의 범위를 제공하는 table_id 필드의 논리적인 부분인 것으로 고려된다. table_id_extension 필드는 NST_protocol_version 필드를 포함한다.

NST_protocol_version 필드는 8비트 언사인드 정수 필드이며, 미래에, 이 NST가 현재 프로토콜에서 정의된 것과 다르게 구성될 수 있는 파라미터를 갖는 것을 허용하는 기능을 한다. 현재, NST_protocol_version에 대한 값은 제로이다. 비제로값의 NST_protocol_version은 구조적으로 다른 테이블을 나타내는 이 표준의 미래 버전에서 사용될 수 있다.

version_number 필드 (5비트)는 NST의 버전 번호를 나타낸다.

current_next_indicator 필드는 1비트 지시자이며, '1'로 설정되면, 송신된 NST가 현재 이용가능한 것을 나타낸다. '0'으로 설정되면, 송신된 NST가 아직 이용가능하지 않으며, 다음의 테이블이 유효하게 되는 것을 의미한다. 이 표준은 "다음의" 테이블('0'으로 설정된 current_next_indicator)이 송신되어야 하는 것을 요구하지 않는다. 현재 어플리케이션가능한 테이블의 업데이트는 version_number 필드를 증가시킴으로써 시그널링된다.

section_number 필드는 이 NST 섹션의 섹션 번호를 주는 8비트 필드이다. NST의 제1 섹션의 section_number 필드는 '0x00'이다. 이 section_number 필드는 NST의 각각의 추가 섹션에서 1만큼 증가된다.

last_section_number 필드는, 이 섹션이 일부인, NST의 최종 섹션(즉, 가장 높은 section_number를 갖는 섹션)의 번호를 제공하는 8비트 필드이다.

num_NRT_services 필드는 이 NST 섹션 내의 서비스의 수를 명시하는 8비트이다.

상기 num_NRT_services필드 값에 대응하는 NRT 서비스 개수 동안 'for' 루프(NRT 서비스 루프라고도 칭해짐)가 실행되어 복수의 NRT 서비스에 대한 시그널링 정보를 제공한다. 그래서, 상기 NST 섹션에 포함되는 NRT 서비스별로 대응 NRT 서비스의 시그널링 정보를 표시한다. 여기서, 각 NRT 서비스에 대해 다음과 같은 필드 정보를 제공할 수 있다.

NRT_service_status 필드는 이 NRT 서비스의 상태를 식별하는 2비트 이뉴머레이티드(enumerated) 필드이다. 여기서, MSB(most significant bit)는 이 NRT 서비스가 액티브(1로 설정될 때)인지 또는 인액티브(0으로 설정될 때)인지 나타내고, LSB(least significant value)는 이 NRT 서비스가 히든(hidden)(1로 설정될 때)인지 아닌지(0으로 설정될 때)를 나타낸다. 히든 서비스들은 독점 어플리케이션을 위해 통상적으로 사용되고, 보통의 수신 장치는 이것을 무시한다.

SP_indicator 필드는, 1비트 필드이며, 설정되면, 서비스 보호가 이 NRT 서비스의 중요한 프리젠테이션을 제공하기 위해 요구되는 콤포넌트들 중 적어도 하나에 적용된다.

CP_indicator 필드는 1비트 필드이며, 설정되면, 콘텐츠 보호가 이 NRT 서비스의 중요한 프리젠테이션을 제공하기 위해 요구되는 콤포넌트들 중 적어도 하나에 적용된다.

NRT_service_id는 16비트 언사인드 정수이며, 이 NRT 방송의 범위내에서 이 NRT 서비스를 유일하게 식별한다.

서비스의 NRT_service_id는 서비스의 수명 동안 변하지 않는다. 혼동을 피하기 위해, 서비스가 종료되면, 적절한 시간 간격이 경과한 후 까지 그 서비스의 NRT_service_id는 다른 서비스를 위해 사용하지 않도록 하는 것이 추천된다.

Short_NRT_service_name 필드는 상기 NRT 서비스의 short name이다. 상기 NRT 서비스의 short name이 없으면, 이 필드는 NULL(0x00)로 채워질 수 있다.

NRT_service_category 필드는 6비트 이뉴머레이티드 유형 필드이며, 도 15에 정의된 것같이 이 NRT 서비스 내에 전송되는 서비스의 유형을 식별한다.

num_components 필드는 5비트 필드이며, 이 NRT서비스에서 IP 스트림 콤포넌트들의 개수를 명시한다.

IP_version_flag 필드(1비트)는 '0'로 설정된 경우에는 source_IP_address 필드, NRT_service_destination_IP_address 필드 및 component_destination_IP_address 필드가 IPv4 어드레스임을 나타낸다. 이 필드에 대해서 값 '1'은, source_IP_address 필드, NRT_service_destination_IP_address 필드, component_destination_IP_address 필드가 IPv6 어드레스인, 가능한 미래 표시로서 예비된다.

source_IP_address_flag 필드는 1비트 불리안 플래그이며, 설정되면, 이 NRT 서비스를 위한 소스 IP 어드레스 값이 소스 특정 멀티캐스트를 나타내도록 존재한다.

NRT_service_destination_IP_address_flag 필드는 1비트 불리안 플래그이며, '1'로 설정되면, 이 M/H 서비스의 콤포넌트들을 위한 디폴트 IP 어드레스로서 기능하도록, NRT_service_destination_IP_address 필드가 존재한다.

source_IP_address 필드는, source_IP_address_flag가 '1'로 설정되면 해당 필드는 존재하지만, source_IP_address_flag가 '0'으로 설정되면 해당 필드는 존재하지 않는다. 만약 해당 필드가 존재하면, 해당 필드는 해당 NRT 서비스의 콤포넌트들을 전송하는 모든 IP 데이터그램들의 소스 IP 어드레스를 포함한다. 해당 필드의 128 비트 길이 어드레스 버전의 조건적인 사용은 비록 현재 IPv6의 사용이 정의되지 않았지만 향후 IPv6의 사용을 가능하도록 하기 위함이다.

NRT_service_destination_IP_address 필드는 NRT_service_destination_IP_address_flag필드가 '1'로 설정되면 해당 필드는 존재하지만, NRT_service_destination_IP_address_flag필드가 '0'으로 설정되면 해당 필드는 존재하지 않는다. 만약 이 NRT_service_destination_IP_address 필드가 존재하지 않으면, component_destination_IP_address 필드가 num_components 루프 내에 각 콤포넌트를 위해 존재할 것이다. 해당 필드의 128비트 길이의 어드레스의 조건적인 사용은 비록 현재 IPv6의 사용이 정의되지 않았지만 향후 IPv6의 사용을 가능하도록 하기 위함이다.

상기 num_components 필드 값에 대응하는 콤포넌트 개수만큼 'for' 루프(또는 콤포넌트 루프라 칭함)가 수행되어 복수의 콤포넌트에 대한 접속 정보를 제공한다. 이것은, 상기 NRT 서비스에 포함되는 각 콤포넌트의 접속 정보를 제공한다. 여기서, 각 콤포넌트에 대해 다음과 같은 필드 정보를 제공할 수 있다. 실시예에서, 하나의 콤포넌트는 하나의 FLUTE 파일 배송 세션(file delivery session)(또는 FLUTE 세션)에 해당된다. 더 구체적으로, 하나의 콘텐츠 아이템에 속하는 파일은 하나 이상의 FLUTE 배송 세션을 통해 전송된다. 하나 이상의 FLUTE 파일 배송 세션은 콘텐츠 아이템에 관련된 서비스 컴포넌트이다.

essential_component_indicator 필드는 1비트 지시자이며, 해당 필드의 값이 '1'로 설정되어 있으면 해당 콤포넌트는 NRT 서비스를 위한 필수 콤포넌트 임을 나타낸다. 그렇지 않으면, 해당 필드는 이 콤포넌트가 선택적인 콤포넌트임을 나타낸다.

port_num_count 필드는 이 UDP/IP 스트림 콤포넌트와 관련된 목적지 UDP 포트들의 번호를 지시한다. 목적지 UDP 포트 넘버들의 값은 component_destination_UDP_port_num 필드 값으로부터 시작해서 1씩 증가한다.

component_destination_IP_address_flag 필드는 1비트 불리안 플래그이며, '1'로 설정되어 있으면 해당 콤포넌트를 위해 component_destination_IP_address 필드가 존재함을 나타낸다.

component_destination_IP_address 필드는 component_destination_IP_address_flag가 '1'로 설정되면 이 필드는 존재하지만, component_destination_IP_address_flag가 '0'으로 설정되면 이 필드는 존재하지 않는다. 만약 이 필드가 존재하면, 해당 NRT 서비스의 콤포넌트들을 전송하는 IP 데이터그램들의 목적지 어드레스가 이 필드의 어드레스와 일치한다. 만약 이 필드가 존재하지 않으면, 해당 콤포넌트들을 전송하는 IP 데이터그램들의 목적지 어드레스가 NRT_service_destination_IP_address 필드의 어드레스와 일치한다. 이 필드의 128비트 길이의 어드레스 버전의 조건적인 사용은 비록 현재 IPv6의 사용이 정의되지 않았지만 향후 IPv6의 사용을 가능하게 한다.

component_destination_UDP_port_num 필드는 16비트 언사인드 정수이며, 이 UDP/IP 스트림 콤포넌트에 대한 목적지 UDP 포트 번호를 나타낸다.

component_level_descriptors()는 이 IP 스트림 콤포넌트에 대해 부가 정보를 제공하는 하나 이상의 디스크립터가 포함될 수 있는 것을 나타낸다.

NRT_service_level_descriptors()는, 포함될 수 있는, 이 M/H 서비스에 대한 부가 정보를 제공하는 제로 이상의 디스크립 나타낸다.

Virtual_channel_level_descriptors()는, 포함될 수 있는, NST가 기재하는 가상 채널에 대한 부가 정보를 제공하는 제로 이상의 디스크립터를 나타낸다.

도 15는 상기 서술된 것같이 도 14의 NRT_service_category에 표시된 NRT 서비스 카테고리를 정의하는 테이블이다.

도 16은 NRT/MH 컴포넌트 디스크립터의 비트스트림 신택스 구조이며, 각 필드에 대한 설명은 다음과 같다.

descriptor_tag 필드는 8비트 언사인드 정수이며, 이 디스크립터를 MH _component_descriptor로서 식별하는 값 0x8D를 갖는다.

descriptor_length 필드는 8비트 언사인드 정수이며, 상기 이 필드 바로 다음부터 이 디스크립터의 끝까지, 디스크립터의 길이를 byte 단위로 명시한다.

component_type 필드는 7비트 필드이며, 콤포넌트의 인코딩 포맷을 식별한다. 이 값은 RTP/AVP 스트림의 payload_type에 대해서 IANA에 의해 할당된 값들 중의 하나일 수 있거나, 또는 본 발명에 의해 할당된 도 17의 값들 중 하나일 수 있거나, 또는 96-127 범위의 "다이나믹 값"일 수도 있다. RTP를 통해 전송되는 미디어로 이루어지는 콤포넌트들에 대해서, 이 필드의 값은 이 콤포넌트를 전송하는 IP 스트림의 RTP 헤더 내 payload_type 필드의 값과 일치한다.

NRT 콘텐츠 스트림이 FLUTE에 기초해 배송되면, 도 17에 도시된 것같은 ATSC-M/H에 따른 컴포넌트 타입 정의에서 "38"이 파라미터를 추가함으로써 사용되거나, 현재 사용되고 있지 않지만 NRT 배송을 위해 새롭게 정의될 수 있는 "43"이 사용된다.

num_STKM_streams 필드는 8비트 언사인드 정수 필드이며, 이 콤포넌트와 관련된 STKM 스트림들의 개수를 식별한다.

STKM_stream_id 필드는 8비트 언사인드 정수 필드이며, STKM 스트림에 대한 컴포넌트 디스크립터의 STKM_stream_id 를 참조하여, 이 보호된 컴포넌트를 디코딩하기 위해 필요한 키를 얻을 수 있는 SKTM 스트림을 식별한다.

MH_component_data(component_type) 필드는, 이 콤포넌트를 렌더링하기 위해 필요한 인코딩 파라미터들 및/또는 다른 파라미터들을 제공하는 MH_component_data 엘리먼트이다. MH_component_data의 구조는 component_type 필드의 값에 의해 결정된다.

FLUTE 세션을 시그널링하는데 필요한 파라미터들은 소스 IP 어드레스, 세션의 채널 번호, 세션의 각 채널의 목적지 IP 어드레스 및 포트 번호, 세션의 TSI(transport session identifier), 및 세션의 시작 및 종료 시각이다. 선택적으로, 다음의 파라미터들은 세션과 관련이 있을 수 있고, 이 파라미터들은 FEC Object Transmission Information, 흥미있는 파일을 세션이 포함한다는 것을 처음에 위치하는 수신기에게 알려주는 일부 정보, 및 대역폭 상세 정보이다.

도 16의 MH_component_descriptors와 함께, NRT_component_descriptor가 또한 사용된다. 도 18은 component_level_descriptors()의 비트스트림 신택스 구조에 대한 일 실시예를 보이고 있다. 즉, component_descriptor()는 NST의 콤포넌트 레벨 디스크립터 component_level_descriptors()의 하나로서 사용되며, 대응콤포넌트의 부가적인 시그널링 정보를 서술한다.

component_descriptor()의 각 필드에 대한 설명은 다음과 같다.

도 18에서, descriptor_tag 필드(8비트)는 디스크립터 식별자로서, component_descriptor()를 식별하는 식별자로서 설정될 수 있다.

descriptor_length 필드(8비트)는 상기 descriptor_length 필드 이후부터 시작하여 이 디스크립터의 끝까지, 디스크립터의 나머지 길이를 byte로 나타낸다.

component_type 필드(7비트)는 콤포넌트의 인코딩 포맷을 식별한다. 이 값은 RTP/AVP 스트림의 payload_type에 대해서 IANA에 의해 할당된 값들 중의 하나일 수 있거나, 또는 ATSC에 의해 할당된 값들 중 하나일 수 있거나, 또는 96-127 범위의 "다이나믹 값"일 수 있다. RTP를 통해 전송되는 미디어로 이루어지는 콤포넌트들에 대해서, 이 필드의 값은 이 콤포넌트를 전송하는 IP 스트림의 RTP 헤더에서 payload_type의 값과 일치한다.

component_encryption_flag 필드(1비트)는 대응 콤포넌트의 암호화 유무를 알려준다.

Num_STKM_streams 필드(8비트)는 component_encryption_flag 필드가 암호화되면, STKM 스트림들의 개수를 나타낸다. Num_STKM_streams 필드(8비트)는 8비트 언사인드 정수이며, 이 콤포넌트와 관련된 STKM 스트림들의 개수를 식별한다.

STKM_stream_id 필드(8비트)는 Num_STKM_streams의 필드 값만큼 반복되어 디크립션에 필요한 키를 얻을 수 있는 SKTM 스트림을 식별하는 값을 표시한다.

NRT_component_data(component_type) 엘리먼트는, 이 콤포넌트를 렌더링하기 위해 필요한 인코딩 파라미터들 및/또는 다른 파라미터들을 제공한다. 여기서, component_data의 구조는 component_type 필드의 값에 의해 결정된다.

예를 들어, 상기 component_type 필드 값이 35이면(도 17), NRT_component_data(component_type) 필드는 H.264/AVC 비디오 스트림에 대한 콤포넌트 데이터를 제공한다.

다른 예로, 상기 component_type 필드 값이 38이면 NRT_component_data(component_type) 필드는 도 17에 나타낸 것같이 FLUTE 파일 배송을 위한 데이터를 제공한다.

하나의 NRT 서비스는 멀티플 FLUTE 세션들에 포함될 수 있다. 그래서, 하나의 NRT 서비스는 복수개의 FLUTE 세션으로 구성될 수 있다. 즉, 하나의 콘텐츠 아이템에 속하는 파일이 하나 이상의 FLUTE 세션을 통해서 전송된다. 각 FLUTE 세션은 도 17에 도시된 것같이 NRT_component_data()를 이용하여 시그널링 될 수 있다.

도 19는 본 발명에 따른 FLUTE 파일 배송에 대한 데이터를 제공하는 NRT_component_data()의 비트스트림 신택스 구조의 일 예를 보이고 있다. 상기 NRT_component_data()의 각 필드에 대한 설명은 다음과 같다.

TSI 필드(16비트 언사인드 정수)는 FLUTE 세션의 TSI(Transport Session Identifier)이다.

session_start_time 필드(16비트)는 FLUTE 세션의 시작 시각을 나타낸다. 만약 해당 필드의 값이 모두 '0'이면, FLUTE 세션은 이미 시작된 것으로 해석될 수 있다.

session_end_time 필드(16비트)는 FLUTE 세션의 종료 시각을 나타낸다. 만약 해당 필드의 값이 모두 '0'이면, 상기 FLUTE 세션은 무한정 계속되는 것으로 해석될 수 있다.

tias_bandwidth_indicator 필드(1비트)는 TIAS(Transport Independent Application Specific) 대역폭 정보의 포함 여부를 플래그한다. TIAS 대역폭 필드가 존재하는 것을 나타내기 위해 이 비트는 '1'로 설정되고, TIAS 대역폭 필드가 존재하지 않는 것을 나타내기 위해 이 비트는 '0'으로 설정된다.

as_bandwidth_indicator 필드(1비트)는 AS(Application Specific) 대역폭 정보의 포함 여부를 플래그한다. AS 대역폭 필드가 존재하는 것을 나타내기 위해 이 비트는 '1'로 설정되고, AS 대역폭 필드가 존재하지 않는 것을 나타내기 위해 이 비트는 '0'으로 설정된다.

FEC_OTI_indicator 필드(1비트)는 FEC Object Transmission Information(OTI)가 제공되는지 여부를 나타낸다.

tias_bandwidth 필드(16비트)는 as_bandwidth_indicator 필드 값이 '1'로 설정되었을 때 존재하며, 최대 대역폭을 표시한다. 또한, RFC 3890에 정의된 것같이 Transport Independent Application Specific 최대 대역폭의 1000분의 1이며, 필요하면 다음의 가장 높은 정수로 반올림된다. 이것은 초당 수 킬로비트의 TIAS 대역폭을 준다.

as_bandwidth 필드(16비트)는 as_bandwidth_indicator 필드 값이 '1'로 설정되었을 때 존재하며, AS 최대 대역폭을 표시한다. 또한, 이 값은 RFC 4566에 정의된 것같이 Application Specific 최대 대역폭이다. 이것은 초당 수 킬로비트의 AS 대역폭을 준다.

FEC_encoding_id 필드는 상기 FEC_OTI_indicator 필드 값이 '1'로 설정되었을 때 존재하며, 대응 FLUTE 세션에서 사용된 FEC ID(RFC 3926에서 정의된 것같이, 이 FLUTE에서 사용되는 FEC 인코딩 ID)를 나타낸다.

FEC_instance_id 필드는 상기 FEC_OTI_indicator 필드 값이 '1'로 설정되었을 때 존재하며, 대응 FLUTE 세션에서 사용된 FEC 인스턴스 ID(RFC 3926에서 정의된 것같이, 이 FLUTE에서 사용되는 FEC 인스턴스 ID)를 표시한다.

상기의 파라미터들을 콤포넌트 루프 내 component_descriptor()의 NRT_component_data()를 통해 시그널링함으로써, 상기 FULTE 세션을 수신하기 위하여 필요한 정보들은 모두 제공할 수 있다.

즉, 상기 session_start_time 필드와 session_end_time 필드에 의해 설정된 시간 정보에 따라서, 대응 FLUTE 세션을 오픈하여 NRT 서비스(또는 콘텐츠)를 구성하는 파일들, 및 상기 파일들의 시그널링 정보를 서술하는 FDT(File Description Table)를 수신할 수 있다. 상기 FDT는 모든 콘텐츠 아이템들의 리스트들을 배송하는데 사용되고, 또한 콘텐츠 아이템 및 콘텐츠 아이템에 포함된 파일들을 획득하는데 필요한 정보들을 제공한다.

일 예로, 콘텐츠 아이템을 구성하는 각 파일은 FLUTE 세션의 FDT에 표시된 Content-Location을 이용하여 식별할 수 있다. 상기 Content-Location은 대응 파일을 식별할 수 있는 식별자를 표시한다. 여기서, 상기 Content-Location은 anyURI(Uniform Resource Identifier) 형태로 구성된다. 더 구체적으로, 상기 Content-Location 값은 파일 이름을 포함하는 위치자(locator)이다.

이때 FDT의 파일 레벨 또는 인스턴스 레벨별로 대응 콘텐츠 아이템을 식별하는 콘텐츠 연결(content linkage)이 할당(또는 배정)될 수 있다. 이 경우, 각 파일은 FLUTE 세션의 FDT에 명시된 콘텐츠 연결, TOI(transfer object identifier), 및 Content-Location 값을 이용하여 식별할 수 있다. 여기서, 콘텐츠 연결은 콘텐츠 아이템을 식별할 수 있는 식별자에 대응하고, TOI는 FLUTE 세션을 통해 전송되는 트랜스포트 오브젝트 즉, 파일을 식별할 수 있는 식별자에 대응한다. 일 예로, 상기 TOI 값이 '0'이면, 그 파일은 FDT이다. 더 구체적으로, 콘텐츠 아이템을 구성하는 각 파일의 TOI 값은 0보다 크다.

도 20 및 21은 NRT 콘텐츠를 수신할 때 OMA DCD를 통해 배송된 DCD 채너널 정보를 획득하는 플로우를 도시하는 시퀀스이다.

도 20은 BCAST DCD 채널 디스커버리 정보를 직접 배송하는 플로우 시퀀스를 도시하며, DST가 수신된 후의 시퀀스를 나타낸다. 더 구체적으로, DST가 수신되어, NRT 서비스가 포함된 것으로 확인된다. 그 다음, NRT 서비스 시그널링 채널에 포함된 Tap이 추출된다. PMT의 Tap으로부터 Association_tag를 포함하는 스트림 ID가 추출된다. PID로부터 스트림을 획득함으로써 DSM-CC 어드레서블 섹션이 획득된다. 잘 알려진 IP 어드레스를 통해 NRT 서비스 시그널링 채널이 접속되고, OMA DCD 채널에 접속하는데 요구되는 IP 어드레스 및 세션 정보가 수신된다. 그 다음, DCD 채널 디스커버리가 액세스될 수 있다. DCD 채널 디스커버리에 액세스한 뒤 DCD 채널 메타데이터가 수신되고, 시청을 위해 이용가능한 DCD 채널이 선택된다. FLUTE 오브젝트를 파싱하는데 필요한 기본 정보가 DCD 채널 메타데이터에서 획득된다. 결국, NRT 서비스가 수신된다.

도 21에, BCAST ESG를 이용하여 NRT 서비스를 수신하는 시퀀스도가 도시된다. 우선, DST가 수신되어, NRT 서비스가 포함된 것으로 확인된다. NRT 서비스 시그널링 채널에 포함된 Tap이 추출된다. PMT의 Tap으로부터 Association_tag를 포함하는 스트림 ID가 추출된다. PID로부터 스트림을 수신함으로써 DSM-CC 어드레서블 섹션이 획득된다. IP 어드레스, 세션, NRT 서비스 시그널링 채널을 통해 ESG를 수신하기 위한 TOI 정보가 수신된다. ESG는 FLUTE 프로토콜을 사용하여 수신된다. ESG로부터 OMA DCD 관리 채널(administrative channel)가 파싱된다. 그 다음, DCD 채널 디스커버리가 액세스된다. DCD 채널 메타데이터가 수신되고, DCD 채널이 시청을 위해 선택된다. 그 다음, DCD 채널 메타데이터로부터의 FLUTE 오브젝트 파싱에 필요한 기본 정보가 획득된다. 결국, NRT 서비스가 수신된다.

도 22는 dcd-2-broadcast-profile의 시그널링을 통해서 도 21의 DCD 채널 메타데이터 중에서 채널 액세스 정보를 획득하는 방법을 도시한다. OMA BCAST를 이용하여 액세스 정보를 배송하는데 3가지 방법이 있다. 첫번째, BCAST 서비스 가이드에서 service-fragment-reference 등의 레퍼런스와 같은 상이한 서비스를 이용하여, 정보를 액세스할 수 있는 것이다. 두번째, access-fragment를 이용하여, OMA BCAST Service Guide “Access” Fragment의 완전한 형태의 배송이 가능한 것이다. 마지막으로, SDP의 콘텐츠를 인라이닝하여, 정보를 액세스할 수 있는 것이다.

본 발명은, 도 22에 도시된 것같이, NRT 서비스를 통해 배송되는 DCD 채널 액세스 정보를 포함하도록 도 22를 확장시키는 것을 제안한다. 우선, NRT 서비스를 배송하는 방송 스트림을 식별하기 위해서, NRT-Broadcast-Locator가 포함된다. 이 정보는 “atsc://f=<frequency>.<program_number>[.m=<modulation_format>]”의 URI 구조를 가짐으로써 NRT 서비스를 포함하는 ATSC 방송의 가상 채널을 식별한다. <frequency>는 서비스의 트랜스포트 스트림을 배송하는 물리적 대역폭을 나타내며, 가상 채널을 식별하기 위해 프로그램 번호가 사용된다. 선택적으로, TS를 전송하는 변조 포맷이 함께 시그널링될 수 있다. 가상 채널을 통해 수신된 NRT 서비스로부터 DCD 채널에 대한 액세스 정보를 포함하는 NRT 서비스를 식별하기 위해 NRT-service-reference가 추가된다. NRT-service-reference의 값은 NST 테이블의 NRT_Service_ID이며, NRT 서비스가 식별될 수 있다.

도 24는 본 발명에 따라서 구성된 NRT_DCD_bootstrap_descriptor()의 비트스트림 신택스 구조를 도시한다.

descriptor_tag는 8비트 언사인드 정수이며, 이 디스크립터를 MH_current_program_descriptor로서 식별하며, 0x8E의 값을 가진다.

descriptor_length는 8비트 언사인드 정수이며, 이 필드의 바로 다음부터 이 디스크립터의 끝까지의 길이를 (바이트로) 명시한다.

service_id_length는 service_id_text()의 길이를 (바이트로) 명시한다.

service_id_text()는 서비스 id를 제공하는 필드이며, 이 값은 전반적으로 유일하다.

service_name_text()는 서비스명을 제공하는 필드이다.

NST를 통해서 BCAST SG를 시그널링하기 위해, 다음의 방법이 사용될 수 있다. BCAST SG에 포함된 NRT 서비스는 서비스 카테고리에 대해서 “0x10”의 값을 가지므로 식별될 수 있으며, NST를 통해서, 어나운스먼트 채널의 액세스 정보가 제공되므로 BCAST 부트스트랩이 실행될 수 있다.

상기 방법에서, DCD 콘텐츠 배송 채널의 부가 정보를 포함하는 NRT DCD 채널 디스크립터가 NRT_DCD_channel_descriptor()에 포함되어 전송될 수 있다.

도 25는 NRT_DCD_channel_descriptor에 대한 비트스트림 신택스 구조를 도시한다. 디스크립터에서 필드의 의미는 다음과 같다.

descriptor_tag는 8비트 언사인드 정수이며, 0x8F의 값을 가지며, 이 디스크립터를 MH_current_ program_descriptor로서 식별한다.

channel_id_length는 the channel_id_text()의 길이를 (바이트로) 명시한다.

channel_id_text()는 채널 id를 주는 필드이다. 채널 식별자는 DCD ㅅ서비스 제공자에 의해 할당되어, DCD 서비스 제공자 도메인 내 채널을 특정하게 ㅅ식별한다. 이것은 DCD 서버에 의해 일반적인 채널 메타데이터에 포함된다.

channel_name_length는 channel_name_text()의 길이를 (바이트로) 명시한다.

channel_name_text()는 채널명을 주는 필드이다. 이것은 콘텐츠 디스커버리에서 사용자에게 제시될 수 있다.

storage_reservation은 32-비트 언사인드 정수이며, 이 채널을 시청하는데 요구되는 최소 장치의 저장용량을 (바이트)로 명시한다.

updated 는 32-비트 언사인드 정수이며, 1980년 1월 6일, 00:00:00 UTC 이후에, GPS 초의 수로서, 채널 메타데이터가 최종 갱신되었을 때의 시간을 나타낸다.

content_types_length는 content_types_text()의 길이를 (바이트로) 명시한다.

content_types_text()는, 예를 들면, “카테고리”, “태그” 또는 "관계"로 채널 콘텐츠의 유형을 기재하는 스트링의 콤마-분리된(comma-separated) 리스트를 제공하는 필드이다.

mime_types_length는 mime_types_text()의 길이를 (바이트로) 명시한다.

mime_types_text()는 제공된 채널에서 콘텐츠 아이템에 대한 MIME 유형의 콤마-분리된 리스트를 제공하는 필드이다.

charging_rules_length는 charging_rules_text()의 길이를 (바이트로) 명시한다.

charging_rules_text()는 누가 채널 요금에 대해서 책임을 지는지와 결재 방법(시청 또는 소비에 기초하여)을 적어도 정의하는 정보를 제공하는 필드이다.

num_purchase_options은 8 비트 필드이며, 이 DCD 채널 디스크립터에서 구매 옵션의 수를 명시한다.

purchase_option_id_length는 purchase_option_id_text()의 길이를 (바이트로) 명시한다.

purchase_option_id_text()는 선택된 옵션을 식별하기 위해 사용되는 구매 옵션의 식별자를 제공하는 필드이다.

cost_information_flag는 1비트 불리안 플래그이며, ‘1’로 설정되면, 이 컴포넌트에 대해서 cost_information이 존재하는 것을 나타낸다.

price_information_flag는 1비트 불리안 플래그이며, ‘1’로 설정되면, 이 컴포넌트에 대해서 amount와 currency가 존재하는 것을 나타낸다.

cost_information_length는 cost_information_text()의 길이를 (바이트로) 명시한다.

cost_information_text()는 선택된 옵션을 식별하기 위해 사용되는 구매 옵션의 식별자를 제공하는 필드이다.

amount는 32-비트 플로트이며, 이 구매 옵션에 대한 금전적 가치를 명시한다.

currency는 16-비트 언사인드 정수이며, ISO 4217 국제 통화 코드에서 정의된 금전 통화 코드를 명시한다.

방송을 통한 서비스 배송의 액세스 정보가 도 26에 도시된 것같이 방송 서비스 배송 구조를 통해서 제공된다. 본 발명은 NRT 서비스의 액세스 정보를 제공하기 위해 도 27에 의해 도시된 것같이 확장된 버전을 제안한다. 도 27에 도시된 것같이, NRT 서비스 엘리먼트가 세션 디스크립션에 추가되므로 NRT 서비스가 참조된다. 하나의 URI: atsc://f=<frequency>.<program_number>[.m=<modulation_format>][/<NRT_Service_ID>]에서 NRT 서비스를 식별하기 위해 NRT-Broadcast-Locator가 다음과 같이 확장된다.

도 28과 도 29는 본 발명의 실시예에 따라 구성된 NRT 어플리케이션을 식별하기 위한 NRT-IT(Information Table) 섹션의 비트스트림 신택스의 도면이다.

NRT-IT에서 제공되는 정보는, 콘텐츠의 명칭(예를 들면, 다운로드가능한 프로그램명), 콘텐츠가 다운로드에 이용가능하게 되는 동안의 시간, 및 콘텐츠 자문(advisory), 캡션 서비스의 이용가능성, 콘텐츠 식별, 및 다른 메타데이터 등의 정보를 포함한다. 콘텐츠의 하나의 아이템은 하나 이상의 파일로 구성된다. 예를 들면, 오디오/비디오 클립은, 온스크린 디스플레이에 나타내기 위해 사용될 수 있는 JPEG 섬네일(thumbnail) 이미지로 나올수 있다.

NRT-IT의 인스턴스는 임의의 정의된 기간에 대응하는 데이터를 포함할 수 있고, 특정 시간에서 시작하여 무한 미래까지의 NRT 콘텐츠를 기재할 수 있다. 각각의 NRT-IT 인스턴스는 이것이 포함하는 기간의 시작 시간과, 이것이 포함하는 기간의 길이를 나타낸다(무한일 수 있다). 각각의 NRT-IT 인스턴스는 256 섹션으로 분할될 수 있다. 하나의 섹션은 복수의 콘텐츠 아이템에 대한 정보를 포함할 수 있지만, 임의의 주어진 콘텐츠 아이템에 대한 정보는 분할되지 않아서, 2개 이상의 섹션으로 되지 않는다.

하나 이상의 NRT-IT 인스턴스를 포함하는 기간을 초과하는 시간 간격동안 다운로드가 이용가능하게 되는 임의의 콘텐츠 아이템이 이들 NRT-IT의 처음에만 서술된다. 콘텐츠 아이템 디스크립션은 NRT_information_table_section() 내에서 그 첫번째 이용가능한 순서로 놓여진다. 그러므로, last_section_number가 제로보다 크면(NRT-IT가 복수의 섹션에서 배송되는 것을 의미), 제1 섹션 이외의 섹션(section_number의 값이 제로보다 큰 섹션)에 대해서, 주어진 섹션 내 모든 콘텐츠 아이템 디스크립션이, 바로 앞의 섹션(section_number의 값이 주어진 섹션보다 1 적은 섹션)의 콘텐츠 아이템 디스크립션의 모든 첫번째 이용가능 시간보다 같거나 큰 첫번째 이용가능 시간을 갖는다.

각각의 NRT-IT는, 이것이 포함하는 기간 동안 때때로 특정 가상 채널에서 유용한 service_id의 주어진 값과 관련되는 NRT 서비스를 식별한다.

table_id 필드(8-비트)는 Non-Real-Time Information Table에 속한 테이블 섹션을 식별하기 위해 0xTBD로 설정된다.

service_id 필드(16-비트)는 이 섹션에서 기술하는 콘텐츠 아이템을 제공하는 NRT 서비스와 관련된 service_id 필드를 명시한다.

NRT_IT_version_number 필드 (5-비트)는 이 NRT-IT 인스턴스의 버전 번호를 표시하며, NRT-IT 인스턴스는, service_id 필드, current_next_indicator 필드, protocol_version 필드 및 time_span_start 필드에 대해서 공통 값을 갖는 하나 이상의 NRT_information_table_section()의 세트로서 정의된다. NRT-IT 인스턴스에서 임의의 필드가 변할 때 버전 번호는 1 modulo 32에 의해 증가된다.

current_next_indicator 필드(1-비트)는 NRT-IT 섹션들에 대해 항상 '1'로 설정된다. 송신된 NRT-IT는 항상 현재 이용가능하다.

protocol_version 필드(8-비트)는 제로로 설정된다. protocol_version 필드의 기능은, 현재 프로토콜 내에서 정의된 것들과 다르게 구성될 수 있는 파라미터들을 이 테이블 유형이 미래에 보유하는 것을 허용하는 것이다. 현재, protocol_version 필드에 대한 유효값만이 제로이다. protocol_version 필드의 넌제로(non-zero)값이, 구조적으로 다른 테이블을 나타내기 위해 이 표준의 미래 버전에서 사용될 수 있다.

time_span_start 필드(32-비트)는 1980년 1월 6일, 00:00:00 UTC 이후에, GPS 초의 수로 표시되는, NRT-IT의 이 인스턴스에 의해 포함되는 시간 수명의 시작을 나타낸다. time_span_start 필드의 날짜의 시간이 시간의 분 00으로 정렬된다. time_span_start 필드의 값 제로는 NRT-IT 인스턴스에 의해 포함되는 기간이 무한 과거에 시작되었음을 나타낸다. time_span_start 필드의 값이 멀티-섹션의 NRT-IT 인스턴스의 각 섹션에 대해서 동일하다. time_span_start 필드와 time_span_length 필드가, 특정 시간 수명이 이 IP 서브넷에서 임의의 다른 NRT-IT 인스턴스와 중첩되지 않도록, 설정된다.

time_span_length 필드(11-비트)는, NRT-IT의 이 인스턴스에 의해 포함되는, time_span_start 필드에 의해 표시되는 시간에서 시작하는, 분의 숫자를 나타낸다. 일단 설정되면, time_span_start 필드의 주어진 값에 대해서 time_span_length 필드의 값은 변하지 않는다. 제로의 time_span_length 필드의 값은 이 NRT-IT 인스턴스는 time_span_start 필드에서 시작하여 무한의 미래까지의 모든 시간을 포함하는 것을 의미한다. time_span_start 필드의 값이 제로이면, time_span_length 필드는 의미를 갖지 않는다. time_span_length 필드의 값은 멀티-섹션의 NRT-IT 인스턴스의 각 섹션에 대해서 동일하다. time_span_start 필드와 time_span_length 필드는, 특정 시간 수명이 이 IP 서브넷에서 임의의 다른 NRT-IT 인스턴스와 중첩되지 않도록, 설정된다.

num_items_in_section 필드(8-비트)는 이 NRT-IT 섹션에 기재되는 콘텐츠 아이템의 개수를 표시한다.

0x0001 ~ 0xFFFFFFFF 범위의 content_linkage 필드(32-비트)는, 기재된 콘텐츠(또는 콘텐츠 아이템)의 식별 번호를 명시한다. 값 0x0000은 사용되지 않는다. content_linkage 필드는 2개의 연결 기능을 행한다: NRT-IT의 메타데이터를 이 NRT 서비스와 관련된 FLUTE FDT의 하나 이상의 파일에 연결하며, 또한, TF_id 필드를 형성한다(텍스트 프래그먼트 테이블에서 텍스트 프래그먼트에 대한 식별자). content_linkage 필드의 값은 콘텐츠 아이템과 관련된 각 파일에 대한 FLUTE FDT에서 FDT_Content_Linkage 엘리먼트들 중 하나의 값 또는 File_Content_Linkage 엘리먼트들 중 하나의 값에 대응한다. 각 content_linkage 값을 FLUTE FDT에서 대응하는 콘텐츠 링크(linkage) 엘리먼트들과 정합시킬 때 선행규칙이 적용될 수 있다.

TF_available field 는 불리안 플래그이며, 이 필드는, '1'로 설정되면, 서비스 시그널링 채널의 텍스트 프래그먼트 테이블에 텍스트 프래그먼트가 존재하는 것을 나타낸다. 이 필드가 '0'으로 설정되면, 이 콘텐츠 아이템에 대해서 서비스 시그널링 채널에 텍스트 프래그먼트가 포함되지 않은 것을 나타낸다.

available_on_internet 필드는 1 비트 플래그이며, 콘텐츠 아이템의 파일들이 인터넷을 통해 액세스될 수 있는 때를 나타낸다. 이 필드가 '1'로 설정되면, 이 콘텐츠 아이템에 속하는 모든 파일들이 인터넷에서 유용한 것을 나타내며, 이 콘텐츠 아이템에 속한 각 파일에 대한 FLUTE FDT 내 Content-Location 어트리뷰트는 그 파일의 인터넷 URL(Uniform Resource Locator)을 나타낸다.

low_latency field는 불리안 플래그이며, 이 필드는, '1'로 설정되면, 사용자가 대기하는 동안 그 반복이 시도되어야 하는, 충분히 낮은 지연(latency)으로 현재의 디지털 트랜스포트 내에서 콘텐츠가 유용하다는 것을 명시한다. 이 필드는, '0'으로 설정되면, 검색 지연이 더 길어져서, 사용자 인터페이스는 사용자에게 시청을 위해서 나중에 돌아올 것을 제안해야 한다.

playback_length_in_seconds 필드(20-비트)는 콘텐츠의 재생 기간을 초 단위로 표시한다. 텍스트 및/또는 정지 화상만으로 이루어진 콘텐츠에 대해서, 값 제로가 사용된다. 오디오 또는 오디오/비디오 콘텐츠를 포함하는 콘텐츠에 대해서, playback_length_in_seconds 필드는 오디오 또는 오디오/비디오 콘텐츠의 재생 길이를 표시한다.

content_length_included 필드는 불리안 플래그이며, 이 필드는, '1'로 설정되면, "for" 루프의 반복에서 content_length 필드가 존재하는 것을 나타낸다. 이 필드를 '0'으로 설정하면, "for" 루프의 반복에서 content_length 필드가 존재하지 않는 것을 나타낸다.

playback_delay_included 필드는 불리안 플래그이며, 이 필드는, '1'로 설정되면, "for" 루프의 반복에서 playback_delay 필드가 존재하는 것을 나타낸다. 이 필드를 '0'으로 설정하면, "for" 루프의 반복에서 이 playback_delay 필드가 존재하지 않는 것을 나타낸다.

expiration_included 필드는 불리안 플래그이며, 이 필드는, '1'로 설정되면, "for" 루프의 반복에서 expiration 필드가 존재하는 것을 나타낸다. 이 필드를 '0'으로 설정하면, "for" 루프의 반복에서 이 expiration 필드가 존재하지 않는 것을 나타낸다.

1 ~ 2880 범위의 duration 필드 (12 비트)는 조회된 콘텐츠 아이템을 포함하는 캐러셀(carousel)의 예상되는 사이클 시간을 분 단위로 명시한다. 방송 수신기는 조회된 콘텐츠를 캡쳐하기 위해 필요한 시간 분량을 결정하기 위해 duration 파라미터를 사용할 것으로 기대된다.

content_length 필드 (40 비트)는, 존재하면, 콘텐츠 아이템 또는 아이템의 전체 크기를 바이트로 표현한다. 이 아이템은, 다운로드가 시도되기 전에이것을 저장하기 위해 유용한 충분한 메모리가 있는지를 결정하기 위해 방송 수신기에 의해 사용된다.

playback_delay 필드 (20 비트)는, 들어 오고 있는 스트림을 버퍼링하는 동안, 재생이 시작되기 전에 방송 수신기가 대기하고 있는 관련된 콘텐츠의 첫 바이트의 수신의 다음에 몇 초가 오는지를 계수한다. 제로 값은 재생이 즉시 행해질 수 있는 것을 나타낸다. playback_delay 필드가 제공되지 않으면, 방송 수신기가 재생하기 전에 컴플릿 파일 또는 파일 세트를 회수하는 것으로 기대된다.

expiration 필드 (32 비트)는, 1980년 1월 6일, 00:00:00 UTC 이후에, GPS 초의 수로 표현되는, 해당 콘텐츠의 만료 시간을 표시한다. 경과 후에, 콘텐츠는 메모리에서 삭제된다. 만료 시간이 명시되어 있지 않으면, 방송 수신기는 메모리 리소스를 관리하기 위해 그 자신이 선택하는 방법을 사용하는 것으로 기대된다.

content_name_length 필드(8 비트)는 content_name_text() 필드의 길이를 바이트로 명시한다.

content_name_text() 필드는 복수의 스트링 구조의 형태로 이 콘텐츠 아이템의 타이틀을 명시한다.

content_descriptors_length 필드 (12 비트)는 콘텐츠 레벨에 대한 부가 정보를 제공하는 content_descriptor ()의 총 길이를 바이트로 표시한다.

content_descriptor()는 각 콘텐츠 아이템에게 개별적으로 적용된다. 본 발명의 실시예에 따라서 구성된 Receiver Targeting Descriptor는 이 디스크립터 루프에 삽입된다. Receiver Targeting Descriptor의 디스크립션을 도 16과 함께 아래에 설명한다.

descriptors_length 필드 (10 비트)는 디스크립터()의 총 길이를 바이트로 표시한다.

descriptor()는 현재 NRT-IT 섹션에서 기술되는 모든 콘텐츠 아이템에 공통으로 적용된다.

도 30 및 도 31은 본 발명에 따라서 구성된 FDT XML(eXtensible Markup Language) 방식을 도시한다.

FDT 또는 FDT 인스턴스가, 전체 어나운스된 파일에 대한 어트리뷰트를 정의할 필요가 있을 때, FDT 인스턴스 레벨에서 정의되고, 어트리뷰트가 개별적으로 정의되는 것이 필요하면, FDT 파일 레벨에서 정의된다.

도 30에서 수치 1은 FDT 인스턴스 레벨에서 콘텐츠 링크(content linkage)를 나타내며, 대응하는 FDT 인스턴스의 모든 파일에 어나운스된 콘텐츠 링크가 주어진다. 그러나, 파일 레벨에서 새로운 콘텐츠 링크를 부여함으로써 이 정보를 오버라이드할 수 있다. 또한, 특정 파일이 FDT 인스턴스 레벨에서 정의된 콘텐츠 또는 컨텍스트(context)와 상이한 컨텍스트로 정의되면, 콘텐츠 링크가 파일 레벨에서 부여된다.

도 30에서 수치 2는 FDT 인스턴스에 포함된 파일이 언제 상이한 컨텍스트에 속하는지, 또한 상이한 컨텍스트에서 파일 별로 시그널링이 어떻게 행해지는지를 콘텐츠 링크가 어나운스한 것을 나타낸다.

도 31에서 수치 3은 각각의 파일이 엔트리 파일에 속했는지 아닌지를 나타낸다. 즉, 엔트리 파일은, 콘텐츠를 구성하는 다른 파일들 중에서 액세스되는 첫번째 파일인 것과, 실행될 필요가 있는 첫번째 루트 파일인 것을 나타낸다. 엔트리 어트리뷰트를 생략할 수 있으며, 이 값이 거짓(false)이고 어트리뷰트가 생략될 때, 대응 파일은 엔트리 파일이 아니다.

본 발명에 따르면, 파일 엘리먼트가 인터넷을 통하여 이용가능하면, 도 31의 수치 4로서 표시된다. Content-Location 어트리뷰트는 파일에 대한 인터넷 어드레스를 포함한다.

예를 들면, 콘텐츠 아이템의 각각의 파일에 대응하는 FLUTE FDT에서 Content-Location 어트리뷰트는 그 파일의 인터넷 URL에 의해 표시된다. 그러므로, 콘텐츠가 FLUTE 세션을 통해 다운로드될 수 있거나 인터넷을 통해 다운로드될 수 있다.

본 발명에서, NRT-IT의 콘텐츠 아이템 루프의 단일 예비 비트가, 콘텐츠 아이템의 파일이 인터넷 상에서 이용가능한 것을 시그널링하기 위해 사용된다. 이 비트가 설정되면, 이 콘텐츠 아이템을 구성하는 파일에 대한 FLUTE FDT Content_Location 필드가, 인터넷을 통해서 파일을 검색하기 위해 사용될 수 있는 URL인 것이 요구된다. 그래서, 이 비트가 설정되면, 인터넷 접속을 갖는 NRT 장치는, 어떤 파일이 콘텐츠 아이템을 구성하는지를 식별하고, 이러한 파일 별로 URL을 구하기 위해 FDT를 파싱하므로써, 인터넷으로부터 직접 다운로드할 수 있게 한다. 이 방법의 주요 장점은 대역폭을 절약하는 것이다. 그러나, 이 방법은 단일 콘텐츠 아이템의 일부 파일들이 인터넷상에서 이용가능하게 되는 것을 허용하지 않는 반면, 동일 콘텐츠 아이템의 다른 파일들은 방송 스트림에서만 이용가능하다. 이 방법은, 인터넷 상에서 이용가능한 파일들의 URL을 얻기 위해서 NRT 장치가 FLUTE FDT를 검사할 것을 요구한다. NRT 장치들은 콘텐츠 아이템의 파일들의 완전한 리스트를 아는 것이 필요하기 때문에, 임의의 경우에 FDT를 검사할 것이 요구되며, 콘텐츠 아이템에 대한 Content Location Descriptor의 세트가 완전한 리스트를 주는지를 확인할 수 없다.

도 32는 ATSC-M/H 모바일 수신기가 NRT 서비스를 어떻게 수신하는지를 나타내는 블록도이다. ATSC-M/H 모바일 수신기에서, 오디오, 비디오, 그래픽, 텍스트 데이터는 NRT를 통해서 수신된다. SMT, OMA BCAST SG를 사용하는 어나운스먼트 데이터 및 시그널링을 통해서 콘텐츠가 저장된다.

ATSC 모바일 DTV 표준, A/153 Part 5는 OMA(Open Mobile Alliance) RME(Rich Media Envirionment)에 기초한 어플리케이션 프레임워크를 구체화한다. 이 어플리케이션 프레임워크는 다음의 OMA RME 컴포넌트로 구성된다: 씬 디스크립션, 씬 커맨드, 인라인 스크립팅, 이벤트 핸들링, 타이밍 및 프로세싱 모델, 패키징 및 배송, 및 정적 및 동적 장치 능력. 씬 디스크립션은 W3C(World Wide Web Consortium) SVG(Scalable Vector Graphics) Tiny 1.2 표준에 기초한다. 씬 디스크립션은 SVG Tiny 1.2 표준의 일부인 그래픽스 컨스트럭트(graphics constructs)를 사용할 수 있으며, 씬에 포함되는 미디어 오브젝트를 레퍼런스할 수 있다. 이런 미디어 오브젝트에 대한 레퍼런스는 국제 캐릭터 세트가 사용될 수 있는 일반화된 URL인 "IRIS"(Internationalized Resource Identifiers)의 형태이다.

A/153 Part 5는, OMA RME 표준에 정의된 것같이 "RME 단위의 스트림 시퀀스"의 형태로 씬 디스크립션 및 씬 커맨드가 자체가 배송되는 것을 요구하며, 이것은 씬 디스크립션 및 씬 커맨드가 RTP로 배송되는 것을 의미한다. 그러나, A/153 Part 5는 이러한 씬 디스크립션에 레퍼런스된 미디어 오브젝트가 어떻게 배송되어야 하는지를 명시하지 않는다. 작은 미디어 오브젝트를 배송하는 하나의 주지의 방법은 미디어 오브젝트를 IETF RFC 2397에 정의된 "데이터" URI 방식을 사용하여 씬 디스크립션에 라인간 놓는 것이다. 또 다른 주지의 방법은 HTTP 또는 FTP 등의 몇몇 프로토콜을 사용하는 투-웨이(two-way) IP 접속을 통해, 이러한 접속을 갖는 모바일 장치에 대해서, 파일로서 미디어 오브젝트를 배송하는 것이다. 또 다른 방법은 이 NRT 표준의 섹션 5에 명시된 FLUTE 배송 메카니즘을 통해 파일로서 미디어 오브젝트를 배송하는 것이다.

RME 프로세서가 투-웨이 IP 접속을 통해 미디어 오브젝트를 받도록 원래 만들어졌을 때, 다음 요구 사항들은, FLUTE를 통해 배송된 미디어 오브젝트를 취급하기 위해 RME 프로세서에 요구되는 적응 사항을 최소화하기 위한 것이다.

미디어 오브젝트가 FLUTE을 통하여 파일로서 배송되고, 또한 투-웨이 IP 접속을 통하여 배송된 파일로서 이용가능할 때, FLUTE FTD에서 파일에 대한 Content-Location 엘리먼트의 값은, 투-웨이 IP 접속을 통하여 파일을 받기 위해 사용될 수 있는 URL과 동등하다.

그리고, 미디어 오브젝트가 FLUTE을 통하여 파일로서 배송되고, 투-웨이 IP 접속을 통하여 배송된 파일로서 이용가능하지 않을 때, FLUTE FTD에서 파일에 대한 Content-Location 엘리먼트의 값은 IETF RFC 4151에서 정의된 “tag” URI 방식에 따르는 URI일 것이다.

RME 프로세서가, 레퍼런스될 때마다 동일한 파일을 반복하여 받을 필요가 없도록, 받은 파일을 캐시해두는 브라우저형 캐시를 갖는 실행 방법을 따른다고 가정할 때, 이들 필요 사항들 때문에, 투-웨이 IP 접속으로부터 미디어 오브젝트를 얻도록 만들어지고 FLUTE를 통하여 배송된 미디어 오브젝트를 활용할 수 있도록 변형시키는 RME 프로세서를 비교적 쉽게 취할 수 있다.

RME 클라이언트는, FLUTE를 통해서 배송된 파일을 RME 프로세서의 캐시에 두고, FLUTE FDT Content-Location 값을 갖는 각각의 파일을, 이것을 수신하기 위해 사용되었던 URI로서 라벨링하는 FLUTE 클라이언트와 간단히 인터페이스될 수 있다. RME 프로세서가 씬 디스크립션에서, 미디어 오브젝트를 레퍼런스하는 URI를 발견하면, 그 캐시에서 URI로 라벨링된 곳에 파일을 갖는지 우선 알아본다. 만약 파일이 있다면, 그 파일을 사용할 수 있다. 그 URI로 라벨링된 캐시에서 파일을 갖지 않으면, 2가지를 고려할 수 있다. URI가 “tag” URI가 아니면, RME 프로세서는 투-웨이 IP 접속을 통하여 파일을 받을 수 있다. URI가 “tag” URI이면, RME 프로세서는 FLUTE를 통하여 파일이 배송되기를 기다려야 한다.

이 섹션에서 명시된 URL 컨벤션은, 사용자로 하여금 FLUTE를 통해서만 이용가능한 파일과 FLUTE와 인터넷 링크 모두를 통해서 이용가능한 파일을 구분하게 하고, 더 긴 절대 URL보다 FLUTE에 의해 배송된 파일에 대한 상대 URL을 사용하는 것을 용이하게 하고, 컴퓨터의 파일 시스템에서 파일에 대해 동작하는 것과 동일한 방식으로 FLUTE 세션 내의 파일들 사이에서 하이퍼링크 레졸루션(resolution)을 지지하는 3가지를 달성하도록 의도되었다.

제1 URL 컨벤션에서, FLUTE 및 인터넷을 모두 통해서 파일이 이용가능할 때, FLUTE FDT에서 파일의 Content-Location 엘리먼트의 값은 인터넷을 통해 파일에 액세스하기 위해 사용된 URL과 일치한다.

제2 URL 컨벤션은 FLUTE 파일에 대한 Content-Location 값이며, 절대 URL 또는 상대 URL일 수 있다. Content-Location 값이 절대 URL이면, 이 URL은 파일에 대한 절대 URL이다. Content-Location 값이 상대 URL이면, 파일은 형태: file://X/<content-location>의 절대 URL을 갖는 것으로 고려되며, 여기서, <content-location> 은 그 Content-Location 값이고, “X”는 파일을 배송하는 FLUTE 세션을 나타내고, 수신자에게 알려진 모든 다른 FLUTE 세션의 가상 폴더로부터 분리되는 임의의 가상 폴더 명칭이다. 폴더 명칭이 특정되지 않기 때문에, 동일한 FLUTE 세션 내에 오는 상대 하이퍼링크를 통해서 이러한 파일을 레퍼런스할 수 있다. 더욱이, 조건 (1)로 인해서, 이러한 파일은 인터넷 링크를 통해서 이용될 수 없다.

제3 URL 컨베년은 RFC 4151[65]에서 정의된 “tag” URI 방식이며, 그 용어는 RFC 2396[40]에서 정의되었으므로, URL의 "특정" 부분이 절대 URI의 <hier_part>의 신택스 및 의미론에 따른다는 추가된 제약을 가지고, FLUTE 파일의 Content-Location 값에 대해서 사용될 수 있다. tag” URI가 RFC 4151 [65]에 의해 전반적으로 유니크한 것으로 요구되기 때문에, 이러한 파일은 어디에서든 레퍼런스될 수 있지만, 임의의 FLUTE 파일로 레퍼런스를 주소 분해하는(resolving) 엔진은, FLUTE 세션(들)에서 파일을 찾기 위해 FLUTE 세션(들)의 세트를 알 필요가 있다. 제1 URL 컨벤션의 조건 때문에 이러한 파일은 인터넷을 통해서 이용가능하지 않다.

제4 URL 컨벤션에서, 인터넷을 통해 이용가능하지 않은 FLUTE 파일은 Content-Location 값으로서 상대 URL 또는 절대 “tag” URI을 가져야 한다. FLUTE 내에서 상대 하이퍼링크를 주소 분해하기 위한 기본 URL은, 상기 제2 URL 컨벤션에서 정의된 것같이, 최종 경로 세그먼트가 제거된, 파일의 절대 URL이다. 유형 1 또는 3의 절대 URL은, 레퍼런스된 파일들과 상이한 콘텐츠 아이템의 일부인 파일 내로부터를 포함하여, 어디에서든 파일에 대한 레퍼런스로서 사용될 수 있다. 유형 1 또는 3의 동일한 절대 URL은, 상이한 서비스에서 배송된 파일에 대한 Content-Location으로서 사용될 수 있다(즉, 별개의 FLUTE 세션. 이 경우에, 배송된 파일은 동일해야 한다).

도 32는 ATSC-M/H 모바일 수신기가 NRT 서비스를 수신하는 방법의 블록도이다. ATSC-M/H 모바일 수신기에서, 오디오, 비디오, 그래픽, 텍스트 데이터는 NRT를 통해서 수신된다. SMT, OMA BCAST SG를 사용하는 어나운스먼트 데이터 및 시그널링을 통해서 콘텐츠가 저장된다.

RTP 프로토콜을 사용하여 RME 데이터가 수신되고, 커맨드를 실행함으로써 특정 A/V 오브젝트 또는 다른 그래픽, 텍스트 데이터가 요구된다. 요구된 A/V 오브젝트는 이 경우에 NRT 서비스이다. NRT 콘텐츠를 요구하기 위해 필요한 ID 값은 저장된 NRT 파일에서 FLUTE FDT의 Content-Location 필드 값이다.

도 33은 본 발명의 실시예에 따른 fixed NRT 서비스를 위한 방송 수신기의 구조를 나타내는 블록도이다.

도 33에서 방송 수신기는 동작 컨트롤러(100), 베이스밴드 프로세서(110), 서비스 디멀티플렉서(120), 스트림 컴포넌트 핸들러(130), 미디어 핸들러(140), 파일 핸들러(150), 서비스 관리자(160), PVR 관리자(170), 제1 저장부(180), SG 핸들러(190), EPG 관리자(200), NRT 서비스 관리자(210), 어플리케이션 관리자(220), 미들웨어 엔진(230), 프레젠테이션 관리자(240), UI 관리자(250) 및 인터넷 네트워크 인터페이스(260)를 포함한다.

베이스밴드 프로세서(110)는 튜너(111) 및 복조기(112)를 포함한다. 서비스 디멀티플렉서(120)는 MPEG-2 TP 핸들러(121), PSI/PSIP 핸들러(122), 디멀티플렉서(123), 디스크램블러(124) 및 제2 저장부(125)를 포함한다.

스트림 컴포넌트 핸들러(130)는 PES(Packetized Elementary Stream) 디코더(131), ES(Elementary Stream) 디코더(132), PCR 핸들러(133), STC 핸들러(134), DSM-CC 어드레서블 섹션 핸들러(135), IP 데이터그램 핸들러(136), 디스크램블러(137), UDP 핸들러(138), 서비스 시그널링 섹션 핸들러(138-1) 및 CAS(Conditional Access System)(139)를 포함한다.

미디어 핸들러(140)는 A/V 디코더(141)를 포함한다. 파일 핸들러(150)는 ALC/LCT 스트림 핸들러(151), 파일 재구성 버퍼(152), XML 파서(153), FDT 핸들러(154), 디콤프레서(155), 제3 저장부(156) 및 파일 디코더(157)를 포함한다.

예를 들면, 도 16에서 튜너(111)는 서비스 관리자(160)로부터의 제어에 의해 지상 시스템을 통해 전송된 신호를 검출하고, 소망의 채널만을 동조하여, 중간 주파수(IF)로 다운컨버트하여 복조기(112)로 출력한다. 튜너(111)는 실시간 스트림 및 비실시간 스트림을 모두 수신할 수 있다. 본 발명에서, 비실시간 스트림을 NRT 스트림으로 칭한다.

복조기는 튜너(111)로부터 입력된 디지털 IF 신호를 수신하여 자동 이득 제어를 행하고, 캐리어 주파수 및 타이밍을 재구성하여 베이스밴드 신호로 변환하고 채널을 이퀄라이징한다. 예를 들면, 방송 신호가 VSB 변조된 신호이면, 자동 이득 제어를 위해 VSB 복조 처리가 실행되고, 캐리어 주파수 및 타이밍을 재구성한다. 복조기(112)에서, 복조 및 이퀄라이징된 채널 데이터는 MPEG-2 TP 핸들러(121)로 MPEG-2 Transport Stream (TS) 패킷 포맷으로 출력된다.

MPEG-2 TP 핸들러(121)는 MPEG-2 TP 버퍼와 MPEG-2 TP 파서로 구성되며, 변조기(112) 출력을 일시적으로 저장하고 TS 헤더를 분석하여, 변조기(112) 출력이 실시간 A/V TS 패킷 또는 NRT TS 패킷이면, 디멀티플렉서(123)로 출력하고, 출력이 PSI/PSIP 테이블용 TS 패킷이면, PSI/PSIP 핸들러(122)로 출력한다. PSI/PSIP 핸들러(122)는 PSI/PSIP 섹션 버퍼와 PSI/PSIP 파서로 구성되고, MPEG-2 TP 핸들러로부터 출력된 TS 패킷을 임시 저장하고, 테이블 식별자를 참조하여 TS 패킷의 페이로드에 포함된 PSI/PSIP 섹션 데이터로부터 대응하는 테이블을 재구성하여 파싱한다. 이때, 대응 섹션 내의 table_id 필드, section_number 필드, 및 last_section_number 필드에 의해 하나의 테이블이 하나의 섹션으로 구성되었는지 또는 복수 개의 섹션으로 구성되었는지를 알 수 있다. 또한, 동일한 테이블 식별자를 갖는 섹션들을 모아서 대응 테이블을 완성할 수 있다. 예를 들면, VCT에 할당된 테이블 식별자를 갖는 섹션들을 모아서 VCT를 완성할 수 있다. 또한, 각각의 파싱된 테이블 정보는 서비스 관리자(160)에 의해 모여져서 제1 저장부(180)에 저장된다. 처리를 거친 후, VCT, PAT, PMT, DST, EIT, ETT 등이 제1 저장부(180)에 저장된다. 서비스 관리자(160)는 제1 저장부(180)에 Service Map & Guide DB 포맷으로 테이블 정보를 저장한다.

본 발명의 실시예에 따르면, VCT 내 service_type 필드는 NRT 서비스 (또는 NRT 서비스 시그널링 채널)로서 대응 서비스를 식별하기 위해 사용되며, PAT 및 PMT가 MPEG-TS 패킷의 PID 값을 추출하기 위해 사용되며, NRT 서비스 (또는 NRT 서비스 시그널링 채널)를 전송한다. 이러한 추출 과정은 PSI/PSIP 핸들러(122)의 출력을 사용하여 서비스 관리자(160)에서 실행된다. 그리고, 여기서, 추출된 PID는 MPEG-2 TS 핸들러(121)에 제공된다.

디멀티플렉서(123)는 오디오 TS 패킷과 비디오 TS 패킷을 분할하여, TS 패킷이 A/V TS 패킷이면 PES 디코더(131)로 출력하고, NRT TS 패킷이면 DSM-CC 핸들러(135)로 출력한다. TS 패킷이 PCR(Program Clock Reference)을 포함하면, 디멀티플렉서(123)는 PCR 핸들러(133)로 출력한다. TS 패킷이 CA(Conditional Access) 정보를 포함하면, CAS(139)로 출력된다. NRT TS 패킷은 NRT 서비스 데이터를 포함하는 PS 패킷과 NRT 서비스 시그널링 채널을 포함하는 TS 패킷으로 분할된다. NRT 서비스 데이터의 TS 패킷에서 NRT 서비스를 식별하기 위해 특정 PID가 할당되며, NRT 서비스 시그널링 채널을 포함하는 TS 패킷의 PID가 VCT, PAT, 및 PMT를 사용하여 추출된다.

입력된 TS 패킷의 페이로드가 스크램블되면 디멀티플렉서(123)는 디스크램블러(124)로 출력하며, 디스크램블러(124)는 디스크램블에 필요한 디스크램블 정보(예를 들면, 스크램블에 사용되는 제어 워드)를 CAS(139)로부터 수신하여 TS 패킷의 디스크램블을 행한다.

멀티플렉서(123)는 제2 저장부(125)의 레코드, 타임-레코드 또는 타임 시프트 요구 중 임의의 하나로부터 실시간의 A/V 패킷을 저장한다. 제2 저장부(125)는 대용량 저장 장치이며, 예를 들면 HDD일 수 있다. 제2 저장부(125)에서 다운로드(저장) 및 업로드(재생)는 PVR 관리자(170) 또는 서비스 관리자(160)에 의해 제어된다.

패킷 요구에 따라서, 디멀티플렉서(123)는 제2 저장부로부터 업로드된 A/V TS 패킷으로부터 오디오 TS 패킷과 비디오 TS 패킷을 분리함으로써, 분리된 TS 패킷을 PES 디코더(131)에 출력한다.

이러한 기능들을 행하기 위해 디멀티플렉서(123)는 서비스 관리자(160) 및/또는 PVR 관리자(170)에 의해 제어된다.

더 구체적으로, VCT 내의 service_type 필드값은 NRT 서비스 (또는 NRT 서비스 시그널링 채널)가 전송되고 있는 것을 나타내며, 서비스 관리자(160)는 MPEG-TS 패킷의 PID 값을 추출하기 위해 PAT 및 PMT를 사용하며, NRT 서비스 (또는 NRT 서비스 시그널링 채널)를 전송한다. 그 다음, 서비스 관리자(160)는 추출된 PID 값을 MPEG-2 TP 핸들러(121) 및 디멀티플렉서(123)에 출력한다.

멀티플렉서(123)는, 서비스 관리자(160)로부터 출력된 PID에 대응하는 MPEG-2 TS 패킷을 어드레서블 섹션 핸들러(135)에 출력한다.

PCR은 A/V 디코더(141)에서 오디오 ES와 비디오 ES를 동기화하는데 사용된 시간 값이다. PCR 핸들러(133)는 입력된 TS 패킷의 페이로드에 포함된 재구성된 PCR을 STC 핸들러(134)에 출력한다. STC 핸들러(134)는 PCR에 의해 시스템으로부터의 표준 클락인 재구성된 STC(System Time Clock)를 A/V 디코더(141)로 출력한다.

PES 디코더(131)는 PES 버퍼와 PES 핸들러로 구성되어, 오디오 TS 패킷과 비디오 TS 패킷을 임시 저장하고, 각 TS 패킷에서 TS 헤더를 제거하고 오디오 PES 및 비디오 PES로 재구성한다. 재구성된 오디오 PES 및 비디오 PES는 ES 디코더(132)로 출력된다. ES 디코더(132)는 ES 버퍼와 ES 핸들러로 구성되어, 오디오 PES와 비디오 PES에서 각 PES 헤더를 제거하고, 순수 데이터인 오디오 ES 및 비디오 ES를 재구성한다.

A/V 디코더(141)는 오디오 ES 및 비디오 ES를 디코딩하기 위해 각 디코딩 알고리즘을 사용하여, 이전-압축된 상태로 재구성하여, 프리젠테이션 관리자(240)로 출력한다. 이 때, STC에 기초하여, 오디오 ES 및 비디오 ES를 디코딩할 때 시간 동기화를 실행한다. 일 예에서, 오디오 디코딩 알고리즘은 AC-3 디코딩 알고리즘, MPEG 2 오디오 디코딩 알고리즘, HE AAC 디코딩 알고리즘, AAC SBR 디코딩 알고리즘, AAC+ 디코딩 알고리즘, HE AAC 디코딩 알고리즘, AAC SBR 디코딩 알고리즘, MPEG 서라운드 디코딩 알고리즘 또는 BSAC 디코딩 알고리즘 중 적어도 하나를 적용할 수 있으며, 비디오 디코딩 알고리즘은 MPEG 2 비디오 디코딩 알고리즘, MPEG 4 비디오 디코딩 알고리즘, H.264 디코딩 알고리즘, SVC 디코딩 알고리즘, 및 VC-1 디코딩 알고리즘 중 적어도 하나를 적용할 수 있다.

CAS(139)는 CA 스트림 버퍼 및 CA 스트림 핸들러로 구성되며, MPEG-2 TP 핸들러(121)로부터 출력된 TS 패킷 또는 UDP 데이터그램 핸들러(138)로부터 출력되고 재구성된 서비스 보호 데이터가 임시로 저장되어 저장된 TS 패킷 및 서비스 보호 데이터를 디스크램블하는데 필요한 정보(스크램블에서 사용된 제어 워드)를 재구성한다. 그래서, CAS(139)는, TS 패킷의 페이로드에 포함된 EMM(Entitlement Management Message) 및 ECM(Entitlement Control Message)을 추출한 뒤 추출된 EMM 및 ECM을 분석하여 디스크램블에 필요한 정보를 획득한다. ECM은 스크램블에 사용되는 제어 워드(CW)를 포함할 수 있다. CW는 인증키를 사용하여 암호화될 수 있다. EMM은 대응 데이터의 인증키 및 필요 정보를 포함할 수 있다. CAS(139)로부터 디스클램에 필요한 획득된 정보는 디스크램블러(124, 137)로 출력된다.

DSM-CC 섹션 핸들러(135)는 DSM-CC 섹션 버퍼와 DSM-CC 섹션 파서로 구성되며, 디멀티플렉서(123)로부터 출력된 TS 패킷을 임시 저장하고 TS 패킷의 페이로드에 포함된 어드레서블 섹션을 재구성하여, 어드레서블 섹션에서 헤더와 CRC 체크섬을 제거하고, IP 데이터그램을 재구성한 뒤 IP 데이터그램 핸들러(136)에 출력한다. IP 데이터그램 핸들러(136)는 IP 데이터그램 버퍼와 IP 데이터그램 파서로 구성되고, DSM-CC 섹션 핸들러(135)로부터 배송된 IP 데이터그램을 버퍼링한 뒤, 버퍼링된 IP 데이터그램의 헤더를 추출하여 분석하고, IP 데이터그램의 페이로드로부터 UDP 데이터그램을 재구성한 뒤 UDP 데이터그램 섹션 핸들러(138)에 출력한다.

이때, IP 데이터그램이 스크램블되면, 스크램블된 UDP 데이터그램이 디스크램블러(137)에서 디스크램블되고, UDP 데이터그램 핸들러(138)로 출력된다. 일 실시예에서, 디스크램블러(137)는 CAS(139)로부터 디스크램블에 필요한 정보(예를 들면, 스크램블에 필요한 제어 워드)를 모아서 UDP 데이터그램을 디스크램블하여, UDP 데이터그램 핸들러(138)에 출력한다.

UDP 데이터그램 핸들러(138)는 UDP 데이터그램 버퍼와 UDP 데이터그램 파서로 구성되어, IP 데이터그램 핸들러(136) 또는 디스크램블러(137)로부터 출력된 UDP 데이터그램을 버퍼링한 뒤, 버퍼링된 UDP 데이터그램의 헤더를 추출하여 분석하고, UDP 데이터그램의 페이로드에 포함된 데이터를 재구성한다. 이때, 재구성된 데이터가 서비스 보호 데이터이면, CAS(139)로 출력되고, NRT 서비스 시그널링 데이터이면, 서비스 시그널링 섹션 핸들러(138-1)로 출력되고, NRT 서비스 데이터이면, ALC/LCT 스트림 핸들러(151)로 출력된다.

이 실시예에서, NRT 서비스 시그널링 채널을 전송하는 IP 데이터그램의 액세스 정보는 주지의 목적지 IP 어드레스 및 주지의 목적지 UDP 포트 번호이다.

그러므로, IP 데이터그램 핸들러(136) 및 UDP 데이터그램 핸들러(138)는 주지의 목적지 IP 멀티캐스트 어드레스 및 주지의 목적지 UDP 포트 번호를 가지며, NRT 서비스 시그널링 채널을 전송하는 IP 멀티캐스트 스트림은 NRT 서비스 시그널링 데이터를 추출하여, 서비스 시그널링 섹션 핸들러(138-1)에 출력한다.

또한, 서비스 시그널링 섹션 핸들러(138-1)는 서비스 시그널링 섹션 버퍼와 서비스 시그널링 섹션 파서로 구성된다. 여기서, 서비스 시그널링 섹션 핸들러(138-1)는 NRT 서비스 시그널링 데이터로부터, 도 5 및 6에 도시된 것같이 NST를, 도 9에 도시된 것같이 NRT-IT를 복구하여 파싱함으로써, 처리된 데이터를 서비스 관리자(160)에 출력한다. NST가 파싱될 때, NRT 서비스를 구성하는 콘텐츠/파일을 전송하는 FLUTE 세션의 액세스 정보가 얻어질 수 있다. NST 및 NRT-IT로부터 파싱된 정보는 서비스 관리자(160)에 의해 수집(또는 모여짐)되어, 제1 저장부(180)에 저장된다. 서비스 관리자(160)는 NST 및 NRT-IT로부터 추출된 정보를 제1 저장부(180)에 서비스 맵 및 서비스 가이드의 포맷으로 저장한다. 본 발명의 또 다른 실시예에 따르면, 서비스 관리자의 기능(또는 역할)은 NRT 서비스 관리자(210)에 의해 행해질 수 있다. 더 구체적으로, NST 및 NRT-IT로부터 파싱된 정보는 NRT 서비스 관리자(210)에 의해 수집(또는 모여짐)되어, 제1 저장부(180)에 저장되도록 한다.

ALC/LCT 스트림 핸들러(151)는 ALC/LCT 스트림 버퍼와 ALC/LCT 스트림 파서로 구성되며, UDP 데이터그램 핸들러(138)로부터 출력된 ALC/LCT 구조 데이터를 버퍼링한 뒤, 데이터로부터 버퍼링된 ALC/LCT 세션의 헤더 및 헤더 연장부를 분석한다. ALC/LCT 세션의 헤더 및 헤더 연장부를 분석한 뒤, ALC/LCT 세션을 통해 전송된 데이터가 XML 구조이면, XML 파서(153)로 출력되고, 데이터가 파일 구조이면, 파일 재구성 버퍼(152)에 임시 저장되어 파일 디코더(157)로 출력되거나 제3 저장부(156)에 저장된다. ALC/LCT 세션을 통해 전송된 데이터가 NRT 서비스용 데이터이면, ALC/LCT 스트림 핸들러(151)는 NRT 서비스 관리자(210)에 의해 제어된다. ALC/LCT 세션을 통해 전송된 데이터가 압축되면, 디콤프레서(155)는 압축하여 XML 파서(153), 파일 디코더(157) 또는 제3 저장부(156)로 출력한다.

XML 파서(153)는 ALC/LCT 세션을 통해 전송된 XML 데이터를 분석하여, 분석된 데이터가 파일-기반 서비스이면, FDT 핸들러(154)로 출력되고, 서비스 가이드용 데이터이면, SG 핸들러(190)로 출력된다.

FDT 핸들러(154)는 ALC/LCT 세션을 통해 FLUTE 프로토콜의 파일 디스크립션 테이블을 분석 및 처리한다. 수신된 파일이 NRT 서비스용이면, FDT 핸들러(154)는 NRT 서비스 관리자(210)에 의해 제어된다.

SG 핸들러(190)는 XML 구조로 송신된 서비스 가이드용 데이터를 분석하여, EPG 관리자(200)에 출력한다.

파일 디코더(157)는 디콤프레서(155)로부터 출력된 파일 재구성 버퍼(152) 파일 또는 미리 선택된 알고리즘을 사용하여 제3 저장부(156)로부터 업로드된 파일로부터 출력된 파일을 디코딩하여, 미들웨어(M/W) 엔진(230) 또는 A/V 디코더(141)로 출력한다.

M/W 엔진(230)은 파일 구조의 데이터인 어플리케이션을 해석 및 실행한다. 또한, 프리젠테이션 관리자(240)를 통해서, 어플리케이션이 스크린 또는 스피커 등의 출력 장치로 출력될 수 있다. 실시예에서, M/W 엔진(230)은 JAVA 플랫폼 기반 M/W 엔진이다.

EPG 관리자(200)는, 사용자로부터의 입력에 의존하여, SG 핸들러(190)로부터 수신된 서비스 가이드 데이터를 디스플레이 포맷으로 변환한 뒤 프리젠테이션 관리자(240)로 출력한다. 어플리케이션 관리자(220)는 파일 포맷으로 수신된 어플리케이션 데이터의 핸들링을 관리한다.

서비스 관리자(160)는 NRT 서비스 시그널링 채널을 통해 전송된 NRT 서비스 시그널링 데이터 또는 PSI/PSIP 테이블 데이터를 모으고 분석하여, 서비스 맵을 만들어 제2 저장부(125)에 저장한다. 서비스 관리자(160)는 사용자가 원하는 NRT 서비스의 액세스 정보를 제어하여 튜너(111), 복조기(112) 및 IP 데이터그램 핸들러(136)를 제어한다.

UI 관리자(250)를 통한 사용자로부터의 커맨드에 따라서 동작 컨트롤러(100)는 서비스 관리자(160), PVR 관리자(170), EPG 관리자(200), NRT 서비스 관리자(210), 어플리케이션 관리자(220), 및 프리젠테이션 관리자(240) 중 적어도 하나를 제어하여, 사용자의 커맨드를 실행한다.

NRT 서비스 관리자(210)는 IP 계층에서 FLUTE 세션을 통해서 콘텐츠/파일 포맷으로 전송된 NRT 서비스를 관리한다.

UI 관리자(250)는 UI를 통해서 사용자의 입력을 동작 컨트롤러(100)에 배송한다.

프리젠테이션 관리자(240)는 A/V 디코더(141)로부터 출력된 오디오 및 비디오 데이터, M/W 엔진(230)으로부터 출력된 파일 데이터, 또는 EPG 관리자(210)로부터 출력된 서비스 가이드 데이터 중 적어도 하나를 스피커 및/또는 스크린을 통해서 사용자에게 제공한다.

한편, 본 발명의 실시예에 따르면, 엔트리 파일이 단일 콘텐츠 아이템에 포함될 때, 도 10 또는 11에 도시된 것같이, FDT는 엔트리 파일에서 정보를 시그널링하기 위해 사용된다. 이 경우, FDT 핸들러(154)는 대응하는 FDT XML 스키마를 분석하여, 엔트리 파일에 관한 정보를 획득하도록 한다. 획득된 엔트리 파일에 관한 정보는 제1 내지 제3 저장부(125, 180, 156) 중 하나에 저장될 수 있다. 그리고, 각각의 콘텐츠 아이템이 실행되거나 각각의 콘텐츠 아이템이 저장되어 재생될 때, 엔트리 파일에 관한 저장된 정보를 참조한다.

본 발명에서, 단일 콘텐츠 아이템에 포함된 하나 이상이 파일이 ZIP 파일로 압축되어 전송된다. 이때, 본 발명의 실시예에 따르면, 엔트리 파일이 ZIP 파일에 포함되어 있으면, 엔트리 파일 정보는 엔트리 파일 디스크립터 또는 대응하는 ZIP 파일의 헤더를 사용하여 시그널링된다. 또한, 본 발명의 실시예에 따르면, 엔트리 파일 디스크립터는 각각의 NRT-IT의 콘텐츠 레벨 디스크립터로서 포함된다.

엔트리 파일 정보가 엔트리 파일 디스크립터로 시그널링되어 송신되면, NRT 서비스 관리자(210)(또는 서비스 관리자(160))는 NRT-IT에 포함된 엔트리 파일 디스크립터를 분석함으로써, 엔트리 파일 정보를 획득한다. 획득된 엔트리 파일 정보는 제1 내지 제3 저장부(125, 180, 156) 중 하나에 저장될 수 있다. 그리고, 각각의 콘텐츠 아이템이 실행되거나 각각의 콘텐츠 아이템이 저장되어 재생될 때, 저장된 엔트리 파일 정보를 참조한다.

엔트리 파일 정보가 대응 ZIP 파일의 헤더로 시그널링되어 송신되면, 파일 디코더(157)는 대응 ZIP 파일의 헤더를 분석함으로써, 엔트리 파일 정보를 획득한다. 획득된 엔트리 파일 정보는 제1 내지 제3 저장부(125, 180, 156) 중 하나에 저장될 수 있다. 그리고, 각각의 콘텐츠 아이템이 실행되거나 각각의 콘텐츠 아이템이 저장되어 재생될 때, 저장된 엔트리 파일 정보를 참조한다.

본 발명의 진의와 범위를 벗어나지 않으면, 다양한 변형과 수정이 행해질 수 있다는 것은 본 기술에서 숙련된 자에게 분명하다. 따라서, 첨부된 청구 범위 및 그 동등 범위 내에 속하면 본 발명이 본 발명의 수정과 변형을 포함하는 것으로 의도되었다.

Claims

인터넷을 통해 액세스될 수 있는 콘텐츠 아이템의 파일을 나타내는 액세스 정보와 NRT(non-real time) 서비스 정보를 포함하는 시그널링 정보를 수신하는 단계;
FLUTE(File Delivery over Unidirectional Transport) 세션을 통해 FLUTE 파일을 수신하되, 상기 콘텐츠 아이템에 속하는 각각의 파일에 대한 FLUTE 세션의 FDT(File Delivery Table) 인스턴스는 파일의 콘텐츠 위치 정보를 포함하고, 상기 콘텐츠 위치 정보는 URL(Uniform Resource Locator)을 포함하는 단계; 및
상기 콘텐츠 아이템에 속하는 파일을 사용하여 NRT 서비스를 제공하는 단계;를 포함하여 이루어지되,
상기에서, 파일은 상기 파일의 콘텐츠 위치 정보에 표시된 URL을 사용하여 인터넷을 통해 액세스되거나 방송 수신기의 스토리지를 통해 액세스하는 방송 수신기의 비실시간 서비스 처리 방법.
제1항에 있어서,
상기 NRT 서비스 정보는,
다른 파일을 액세스하기 전에 우선 액세스되어야 하는 파일을 나타내는 엔트리 파일을 포함하는 것을 특징으로 하는 방송 수신기의 비실시간 서비스 처리 방법.
제2항에 있어서,
상기 NRT 서비스 정보는,
상기 엔트리 파일에 대한 정보를 갖는 디스크립터를 포함하고,
상기 엔트리 파일에 대한 정보는 상기 엔트리 파일의 파일명을 포함하는 것을 특징으로 하는 방송 수신기의 비실시간 서비스 처리 방법.
제1항에 있어서,
상기 NRT 서비스 정보는,
NRT 서비스 시그널링 테이블, NRT 서비스 맵 테이블(NRT service map table) 및 NRT 정보 테이블(NRT information table)을 포함하는 것을 특징으로 하는 방송 수신기의 비실시간 서비스 처리 방법.
제1항에 있어서,
파일이 FLUTE 세션을 통해서만 액세스될 때,
상기 파일은 절대 태그 URL 또는 상대 URL을 사용하여 액세스되는 것을 특징으로 하는 방송 수신기의 비실시간 서비스 처리 방법.
제5항에 있어서,
상기 파일이 절대 태그 URL을 사용하여 액세스될 때,
상기 URL은 상기 파일에 대한 절대 URL인 것을 특징으로 하는 방송 수신기의 비실시간 서비스 처리 방법.
제5항에 있어서,
상기 파일이 상대 URL을 사용하여 액세스될 때,
상기 파일은 file://X/<content-location> 형태의 URL을 갖고, 상기 X는 방송 수신기가 알고 있는 임의의 가상 폴더인 것을 특징으로 하는 방송 수신기의 비실시간 서비스 처리 방법.
제6항에 있어서,
상기 태그 URL은,
FLUTE 세션에서 결정되며 유니크한 것을 특징으로 하는 방송 수신기의 비실시간 서비스 처리 방법.
제1항에 있어서,
인터넷을 통해 이용가능하지 않은 FLUTE 파일은,
상대 URL 또는 절대 태그 URI(Uniform Resource Identifier)를 콘텐츠 위치값으로 갖는 것을 특징으로 하는 방송 수신기의 비실시간 서비스 처리 방법.
비실시간 서비스를 처리하는 방송 수신기에 있어서,
인터넷을 통해 액세스될 수 있는 콘텐츠 아이템의 파일을 나타내는 액세스 정보와 NRT 서비스 정보를 포함하는 시그널링 정보를 수신하는 시그널링 정보 처리부;
FLUTE(File Delivery over Unidirectional Transport) 세션을 통해 FLUTE 파일을 수신하되, 상기 콘텐츠 아이템에 속하는 각각의 파일에 대한 FLUTE 세션의 FDT(File Delivery Table) 인스턴스는 상기 파일의 콘텐츠 위치 정보를 포함하고, 상기 콘텐츠 위치 정보는 URL(Uniform Resource Locator)을 포함하는 파일 처리부; 및
상기 콘텐츠 아이템에 속하는 파일을 사용하여 상기 NRT 서비스를 제공하는 서비스 처리부;를 포함하되,
상기에서, 파일은 상기 파일의 콘텐츠 위치 정보에 표시된 URL을 사용하여 인터넷을 통해 액세스되거나 방송 수신기의 스토리지를 통해 액세스되는 방송 수신기.
제10항에 있어서,
상기 NRT 서비스 정보는,
다른 파일을 액세스하기 전에 우선 액세스되어야 하는 파일을 나타내는 엔트리 파일을 포함하는 것을 특징으로 하는 방송 수신기.
제11항에 있어서,
상기 NRT 서비스 정보는,
상기 엔트리 파일에 대한 정보를 포함하는 디스크립터를 포함하고, 상기 엔트리 파일에 대한 정보는 상기 엔트리 파일의 파일명을 포함하는 것을 특징으로 하는 방송 수신기.
제10항에 있어서,
상기 NRT 서비스 정보는,
NRT 서비스 시그널링 테이블, NRT 서비스 맵 테이블, 및 NRT 정보 테이블을 포함하는 것을 특징으로 하는 방송 수신기.
제10항에 있어서,
파일이 FLUTE 세션을 통해서만 액세스될 때,
상기 파일은 절대 태그 URL 또는 상대 URL을 사용하여 액세스되는 것을 특징으로 하는 방송 수신기.
제10항에 있어서,
상기 파일이 절대 태그 URL을 사용하여 액세스될 때,
상기 URL은 상기 파일에 대한 절대 URL인 것을 특징으로 하는 방송 수신기.
제15항에 있어서,
상기 파일이 상대 URL을 사용하여 액세스될 때, 상기 파일은 형태 file://X/<content-location>의 URL을 갖고, 여기서 X는 방송 수신기가 알고 있는 임의의 가상 폴더인 것을 특징으로 하는 방송 수신기.
제15항에 있어서,
상기 태그 URL은,
FLUTE 세션에서 결정되며 유니크한 것을 특징으로 하는 방송 수신기.
제10항에 있어서,
인터넷을 통해 이용가능하지 않은 FLUTE 파일은 콘텐츠 위치값으로 상대 URL 또는 절대 태그 URI(Uniform Resource Identifier)를 갖는 것을 특징으로 하는 방송 수신기.