KR20080009992A

KR20080009992A - 방송 수신기 및 인터페이스 방법

Info

Publication number: KR20080009992A
Application number: KR1020060069898A
Authority: KR
Inventors: 차상훈
Original assignee: 엘지전자 주식회사
Priority date: 2006-07-25
Filing date: 2006-07-25
Publication date: 2008-01-30

Abstract

본 발명은 방송 수신기, 방송 수신기 내 호스트와 케이블카드간 인터페이스 방법에 관한 것이다. 특히 본 발명은 확장 채널의 플로우 설정을 요청하는 측에서는 요청을 원하는 서비스 타입과 서비스 타입 전송 순서를 저장하도록 함으로써, 이후 플로우 설정 요청에 따른 응답이 수신되었을 때 저장된 정보를 참조하여 어떤 서비스 타입의 요청에 대한 응답인지를 알 수 있게 된다. 특히 복수개 이상의 서비스 타입에 대한 플로우 설정 요청을 연속으로 전송한 후 응답이 수신되었을 때에도 어떤 서비스 타입의 요청에 대한 응답인지를 알 수 있게 된다.

서비스 타입, 확장 채널, 서비스 타입 전송 순서

Description

방송 수신기 및 인터페이스 방법{Broadcasting receiver and interfacing method}

도 1은 본 발명에 따른 확장 채널 플로우 설정을 요청하기 위한 요청 신택스 구조의 일 실시예를 보인 도면

도 2는 본 발명의 플로우 설정 요청에 응답하기 위한 응답 신택스 구조의 일 실시예를 보인 도면

도 3은 응답 신택스에 포함되는 상태 필드 값과 그 정의의 예를 보인 일반적인 도면

도 4는 서비스 타입의 플로우 설정 요청 및 응답이 정상적으로 이루어지는 예를 보인 도면

도 5는 서비스 타입의 플로우 설정 요청 및 응답이 비정상적으로 이루어지는 예를 보인 도면

도 6은 본 발명에 따른 플로우 설정을 요청하는 측의 동작을 보인 흐름도

도 7은 본 발명에 따른 플로우 설정 요청을 수신하는 측의 동작을 보인 흐름도

도 8은 플로우 설정을 요청하는 측과 요청에 따른 응답을 생성하여 전송하는 측의 실제 동작 예를 보인 도면

도 9는 본 발명에 따른 방송 수신기의 일 실시예를 보인 구성 블록도

도면의 주요부분에 대한 부호의 설명

900 : 제어부 911~913 : 튜너

920,950,960 : 복조부 930 : 역다중화부

940 : 디코더 970 : 스위칭부

980 : 변조부 800 : 케이블카드

본 발명은 방송 수신기에 관한 것으로, 보다 상세하게는 케이블 방송 수신기 내 호스트와 케이블카드간 인터페이스 방법에 관한 것이다.

통상, 케이블 방송 시스템은 크게 케이블 방송을 전송하는 송신측인 케이블 방송국과, 전송된 케이블 방송을 수신할 수 있는 케이블 방송 수신기로 구성된다.

상기 케이블 방송국은 SO(System Operator) 헤드엔드, 또는 MSO(Multiple System Operator) 헤드엔드라 하기도 한다.

상기 케이블 방송 수신기는 제한 수신(Conditional Access ; CA) 시스템을 포함하는 케이블카드(CableCARD)가 본체로부터 분리된 오픈 케이블 방식이다. 상기 케이블카드는 POD(Point Of Deployment) 모듈이라고도 하며, 상기 케이블 방송 수신기의 본체 슬롯에 장.탈착이 가능하도록 되어 있다.

그리고 상기 케이블카드가 삽입되는 본체를 호스트라 하기도 한다. 즉 상기 케이블카드와 호스트를 합쳐서 케이블 방송 수신기라 한다.

상기 케이블카드와 호스트간에는 데이터 채널(Data Channel)과 확장 채널(Extended Channel)이 존재한다. 상기 데이터 채널은 호스트와 케이블카드간에 제어 신호를 주고받도록 설정되고, 확장 채널은 실제 데이터를 주고받도록 설정된 채널이다.

즉, 상기 케이블카드는 헤드엔드와 통신을 해서 헤드엔드로부터 받은 명령을 해석한 후 상기 데이터 채널 및 확장 채널을 통해 호스트와 서로 통신을 하면서 헤드엔드가 지시한 사항을 수행하게 하거나, 사용자가 입력한 내용들을 헤드엔드로 전달하는 역할을 한다.

이때, 상기 확장 채널을 통해서 데이터를 전송하기 위해서는 먼저, 케이블카드와 호스트간에 정의된 데이터 타입(또는 서비스 타입이라고도 함)에 해당되는 전송 선로를 설정해야 한다. 이를 플로우(Flow)라 한다. 예를 들어, MPEG 섹션 데이터를 전송하기 위해서는 먼저 케이블카드와 호스트간에 MPEG 섹션 플로우를 설정한 뒤에 MPEG 섹션 플로우 상에서 실제 MPEG 섹션 데이터를 전송할 수 있다.

따라서 본 발명의 목적은 확장 채널을 통해 호스트와 케이블카드 간에 효율적인 데이터 전송이 이루어지도록 하는 인터페이스 방법 및 이를 적용한 방송 수신기를 제공함에 있다.

상기 목적을 달성하기 위하여, 본 발명의 일 실시예에 따른 방송 수신기의 호스트와 케이블 카드간의 인터페이스 방법은, 확장채널 플로우를 설정하기 위해 적어도 해당 서비스 타입과 상기 서비스 타입에 따른 고유 정보를 전송함과 동시에 서비스 타입 정보를 저장하는 요청 단계; 및 확장채널 플로우 설정 요청에 따른 응답이 수신되면, 상기 응답에 포함된 상태 정보와 상기 요청 단계에서 저장된 서비스 타입 정보 중 적어도 하나를 참조하여 어떤 서비스 타입의 플로우 설정 요청에 따른 응답인지를 확인하는 단계를 포함하여 이루어지는 것을 특징으로 한다.

상기 서비스 타입 정보는 확장채널 플로우의 설정을 요청하는 서비스 타입과 서비스 타입 전송 순서를 포함하는 것을 특징으로 한다.

상기 확인 단계는 상기 응답에 포함된 상태 정보가 플로우 설정 거절을 표시하면 상기 서비스 타입과 서비스 타입 전송 순서를 참조하여 수신된 응답이 어떤 서비스 타입의 플로우 설정 요청에 따른 응답인지를 확인하는 것을 특징으로 한다.

상기 확인 단계는 수신된 응답이 어떤 서비스 타입의 플로우 설정 요청에 따른 응답인지가 확인된 후, 새로이 수신할 응답이 남아있으면 새로운 응답이 수신될 때까지 새로운 확장채널 플로우의 설정을 요청하지 않고 대기하는 단계를 더 포함하는 것을 특징으로 한다.

상기 확인 단계는 상기 응답에 포함된 상태 정보가 플로우 설정 허가를 표시하면 상기 응답에 포함된 서비스 타입에 해당하는 확장채널 플로우를 설정하는 단계를 더 포함하는 것을 특징으로 한다.

본 발명의 다른 실시예에 따른 방송 수신기의 호스트와 케이블카드간의 인터페이스 방법은, 확장채널의 플로우 설정 요청이 수신되면 시간을 카운트하는 단계; 및 상기 카운트 값이 기 설정된 값이 될 때까지 상기 확장채널 플로우의 설정 요청에 따른 응답이 전송되지 않으면, 플로우 설정 거절을 표시하는 상태 정보를 포함하는 응답을 무조건 전송하는 단계를 포함하여 이루어지는 것을 특징으로 한다.

상기 카운트 단계는 확장채널의 플로우 설정 요청에 포함된 정보를 얻기 위해 시도한 횟수를 카운트하는 단계를 더 포함하는 것을 특징으로 한다.

상기 응답 단계는 플로우 설정 요청을 허가할 경우, 플로우 설정을 허가함을 표시하는 상태 필드, 플로우 ID, 해당 서비스 타입을 포함하는 응답을 전송하는 것을 특징으로 한다.

상기 응답 단계는 플로우 설정 요청이 허가된 서비스 타입이 IP 유니캐스트인 경우, 상기 응답에 적어도 IP 어드레스, 플로우 타입 정보를 더 포함하여 전송하는 것을 특징으로 한다.

본 발명의 일 실시예에 따른 방송 수신기는, 서비스 타입에 따른 확장채널 플로우를 통해 해당 데이터를 주고받는 호스트와 케이블카드를 포함하여 구성되며, 상기 호스트와 케이블카드 중 어느 하나는, 확장채널의 플로우 설정을 요청하기 위해 적어도 해당 서비스 타입과 상기 서비스 타입에 따른 고유 정보를 전송함과 동시에 서비스 타입 정보를 저장하며, 이후 플로우 설정 요청에 따른 응답이 수신되면 상기 응답에 포함된 상태 정보와 기 저장된 서비스 타입 정보 중 적어도 하나를 참조하여 어떤 서비스 타입의 플로우 설정 요청에 따른 응답인지를 확인하고; 상기 호스트와 케이블카드 중 다른 하나는, 확장채널의 플로우 설정 요청이 수신되면 상기 요청에 포함된 서비스 타입의 플로우 설정 가능 여부를 확인한 후 그 결과를 표 시한 상태 정보를 포함하는 응답을 전송하는 것을 특징으로 한다.

본 발명의 다른 실시예에 따른 방송 수신기는, 서비스 타입에 따른 확장채널 플로우를 통해 해당 데이터를 주고받는 호스트와 케이블카드를 포함하여 구성되며, 상기 호스트와 케이블카드 중 어느 하나는, 확장채널의 플로우 설정을 요청하기 위해 적어도 해당 서비스 타입과 상기 서비스 타입에 따른 고유 정보를 전송하고; 상기 호스트와 케이블카드 중 다른 하나는, 확장채널의 플로우 설정 요청이 수신되면 시간을 카운트하여 카운트 값이 기 설정된 값이 될 때까지 상기 확장채널의 플로우 설정 요청에 따른 응답을 전송하지 못하면, 플로우 설정 거절을 표시하는 상태 정보를 포함하는 응답을 무조건 전송하는 것을 특징으로 한다.

본 발명의 다른 목적, 특징 및 잇점들은 첨부한 도면을 참조한 실시예들의 상세한 설명을 통해 명백해질 것이다.

이하 상기의 목적을 구체적으로 실현할 수 있는 본 발명의 바람직한 실시예를 첨부한 도면을 참조하여 설명한다. 이때 도면에 도시되고 또 이것에 의해서 설명되는 본 발명의 구성과 작용은 적어도 하나의 실시예로서 설명되는 것이며, 이것에 의해서 상기한 본 발명의 기술적 사상과 그 핵심 구성 및 작용이 제한되지는 않는다.

그리고 본 발명에서 사용되는 용어는 가능한 한 현재 널리 사용되는 일반적인 용어를 선택하였으나, 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 발명의 설명 부분에서 상세히 그 의미를 기재하였으므로, 단순한 용어의 명칭이 아닌 그 용어가 가지는 의미로서 본 발명을 파악하여야 됨을 밝혀두 고자 한다.

본 발명은 OOB QPSK 모뎀과 DOCSIS(Data Over Cable Service Interface Specifications) 모뎀을 동시에 포함하고 DSG(DOCSIS Settop Gateway)를 지원하는 케이블 방송 수신기를 일 실시예로 설명한다.

본 발명은 확장 채널 플로우 설정시 호스트와 케이블카드간 통신의 효율성을 높이고, 실제 구현시 구현의 복잡성을 줄이며, 프로토콜의 강건성(Robustness) 및 확장성(Extensibility)을 제공하기 위한 것이다.

상기 확장 채널은 전술한 바와 같이 호스트와 케이블카드간에 데이터를 주고받도록 정의된 CPU 인터페이스이다. 그리고 상기 확장 채널을 통해서 전송되는 데이터 타입(또는 서비스 타입이라고도 함)은 현재까지 MPEG 섹션(MPEG Section), IP 유니캐스트(IP Unicast ; IP_U), IP 멀티캐스트(IP Multicast ; IP_M) 및 DSG가 있다.

이때 상기 확장 채널 플로우를 설정하고자 하는 측(케이블카드 또는 호스트)에서는 new_flow_req() APDU에 설정하고자 하는 서비스 타입 및 관련 정보를 포함시켜 전송한다. 상기 new_flow_req() APDU를 전송 받은 측(호스트 또는 케이블카드)은 해당 서비스 타입의 플로우 설정이 가능한지 여부를 판단하고 그 결과를 new_flow_cnf() APDU에 포함시켜 상대측(케이블카드 또는 호스트)에 전송한다. 즉, 상기 확장 채널 플로우를 설정하기 위해 new_flow_req() APDU를 전송하는 측이 케이블카드라면, 해당 서비스 타입의 확장 채널 플로우의 설정이 가능한지 여부를 판단하고 그 결과인 new_flow_cnf() APDU를 전송하는 측은 호스트가 된다. 이는 하나 의 실시예이며 그 반대가 될 수도 있다.

도 1은 new_flow_req() APDU 신택스 구조를, 도 2는 new_flow_cnf() APDU 신택스 구조의 일 실시예를 보이고 있다.

도 1을 보면, new_flow_req() APDU는 new_flow_req()임을 식별할 수 있는 태그 값이 표시되는 new_flow_reg_tag 필드, 서비스 타입(service_type)이 표시되는 필드, 및 상기 서비스 타입 필드 값에 따른 고유 정보를 표시하는 필드를 적어도 포함하여 구성된다.

즉, 서비스 타입 필드 값이 00 즉, MPEG 섹션이면 PID 값을 전송하고, 01 즉, IP 유니캐스트이면 MAC 어드레스(MAC_address)를 전송한다. 또한 서비스 타입 필드 값이 02 즉, IP 멀티캐스트이면 멀티캐스트 그룹 ID(multicast_group_ID)를 전송한다.

도 1과 같은 new_flow_req() APDU를 전송받은 측에서는 그에 대한 응답으로 해당 플로우의 설정이 가능한지 여부 및 그에 관련된 정보를 도 2와 같은 new_flow_cnf() APDU에 담아 전송한다.

도 2는 new_flow_cnf()임을 식별할 수 있는 태그 값이 표시되는 new_flow_cnf_tag 필드, new_flow_req()에서 요청한 해당 플로우의 연결 설정이 가능한지 여부에 대한 정보를 표시하는 상태 필드(status_field), 및 상기 상태 필드 값에 따라 수행되는 조건문을 포함하여 구성된다.

도 3은 상기 상태 필드 값에 표시될 수 있는 값과 그 의미의 일 실시예를 보이고 있다. 예를 들어, 상태 필드 값이 0x00이면 새로운 확장 채널 플로우의 설정 요청이 허가되었음을 표시한다(Request granted, new flow created). 그리고 상태 필드 값이 0x01이면 플로우의 수가 초과되어 요청이 거절되었음을 표시한다(Request denied, number of flows exceeded). 또한 상태 필드 값이 0x03이면 네트워크가 이용 가능하지 않거나, 또는 응답이 없어서 요청이 거절되었음을 표시한다(Request denied, network unavailable or not responding). 그리고 상기 상태 필드 값이 0x04이면 네트워크가 busy 상태이어서 요청이 거절되었음을 표시한다(Request denied, network busy).

그리고 상기 상태 필드 값에 따라 수행되는 조건문은 상기 상태 필드 값이 0x00 즉, 새로운 플로우의 설정 요청이 허가되었음을 표시할 때에만 수행된다.

상기 상태 필드 값이 0x00인 경우에 수행되는 조건문 내에는 플로우 ID를 표시하는 플로우 ID 필드와 서비스 타입을 표시하는 서비스 타입 필드가 포함되어 있다. 또한 상기 조건문 내 서비스 타입 필드 다음에는 서비스 타입이 01 즉, IP 유니캐스트(IP_U)이면 수행되는 IP_U 조건문이 포함되며, 상기 IP_U 조건문 내에는 IP 어드레스(IP_address) 필드, 플로우 타입(flow_type) 필드, 플래그 필드, 최대 PDU 사이즈(max_pdu_size) 필드 등이 포함되어 있다.

이때 정상적인 트랜잭션(transaction) 상태라면 케이블카드와 호스트는 한번에 하나의 new_flow_req()/new_flow_cnf() 트랜잭션만 수행한다(The card and host are required to support only one outstanding new_flow_req() transaction at a time). 즉, 한번에 하나의 new_flow_req()를 전송하고, 전송된 new_flow_req()에 대한 응답 new_flow_cnf()을 받은 경우에만 새로운 new_flow_req()을 전송할 수 있 다

도 4는 그러한 예를 보인 것으로서, 케이블카드는 도 4의 (1)과 같이 IP_U 플로우 설정을 요청하기 위해서 서비스 타입 필드 값이 0x01인 new_flow_req()를 호스트로 전송하고, 이를 수신한 호스트는 상기 IP_U 플로우 설정을 허가하는 상태 필드 값(=0x00)을 갖는 new_flow_cnf()를 케이블카드로 전송한다. 상기 IP_U 트랜잭션이 완료되면 상기 케이블카드는 도 4의 (2)와 같이 IP_M 플로우 설정을 요청하기 위해서 서비스 타입 필드 값이 0x02인 new_flow_req()를 호스트로 전송하고, 이를 수신한 호스트는 상기 IP_M 플로우 설정을 허가하는 상태 필드 값(=0x00)을 갖는 new_flow_cnf()를 케이블카드로 전송한다.

한편 비정상적인 트랜잭션(transaction) 상태라면 케이블카드와 호스트는 한번에 하나의 new_flow_req()/new_flow_cnf() 트랜잭션만 수행하지 않을 수도 있다.

예를 들어, IP_U와 IP_M 트랜잭션은 그 특성상 new_flow_req() APDU를 받는 주체(호스트 또는 케이블카드)가 그 즉시 new_flow_cnf() APDU로 응답할 수 없다. 왜냐하면, 전송받은 new_flow_req()안의 정보들을 가지고 원격지의 서버(Server)에 IP 패킷(packet)을 보내야 하고 그 응답을 기다려야 하기 때문이다. 그러므로 네트워크 환경이나 원격지 서버 환경이 정상적인 경우에는 바로 응답을 받아, 전송 받은 정보들로 new_flow_cnf() APDU를 만든 후 상대측에 전송할 수 있지만, 네트워크 환경이나 원격지 서버 환경이 비정상적인 경우에는 상당한 시간이 걸릴 수도 있다.

도 5는 이러한 비정상적인 네트워크 환경의 경우에, 호스트가 바로 IP_U 트랜잭션을 끝내지 못하고 계속 계류(pending) 상태로 유지되는 경우를 보여주고 있 다. 이때, 케이블카드는 IP_U 트랜잭션이 끝나기 이전에 IP_M 트랜잭션을 새롭게 시작할 수 있다. 즉, IP_U 플로우 설정을 요청하는 new_flow_req()에 대한 응답 new_flow_cnf()을 호스트로부터 받지 않았는데도 불구하고, IP_M 플로우 설정을 요청하는 new_flow_req()을 전송하게 된다.

이러한 경우 호스트는 IP_U 트랜잭션이 계류 중이므로, 네트워크 busy여서 요청을 거절함을 표시하는 상태 필드 값(=0x04)를 갖는 new_flow_cnf()를 케이블카드로 전송한다. 즉, new_flow_req()를 수신한 측(케이블카드 또는 호스트)은 추가의 new_flow_req()가 수신되고, 하나가 계류 중이면 0x04로 표시된 상태 필드를 갖는 new_flow_cnf()를 보내야 한다(The Card or Host SHALL send a new_flow_cnf() with a Status_field of 0x04(Network Busy) when additional new_flow_req() messages are received and one is pending).

그런데 상태 필드 값이 0x04인 new_flow_cnf()를 수신한 케이블카드는 해당 new_flow_cnf()가 new_flow_req(IP_U)에 대한 응답인지, new_flow_req(IP_M)에 대한 응답인지를 구분하지 못한다. 이는 도 2의 new_flow_cnf() APDU의 신택스에 의해서 상태 필드 값이 0x00인 경우를 제외하면 new_flow_cnf() APDU에 서비스 타입 필드를 포함하지 않기 때문이다. 마찬가지로, 이후 케이블카드가 상태 필드 값이 0x03(Request denied, network unavailable or not responding)인 new_flow_cnf()를 수신하더라도, 수신된 new_flow_cnf()가 IP_U에 대한 응답인지 IP_M에 대한 응답인지 구분하지 못하게 된다.

이것은 동일한 new_flow_req() 및 new_flow_cnf() APDU를 DSG, IP_U, IP_M, MPEG_SECTION 서비스 타입이라는 서로 다른 용도로 사용하면서 new_flow_cnf() 안에 해당 서비스 타입 필드를 어떤 경우는 포함하고(상태 필드가 0x00인 경우), 어떤 다른 경우(상태 필드가 0x00 이외의 값을 가지는 경우)에는 포함하지 않기 때문이다.

본 발명은 이를 해결하기 위한 것으로서, new_flow_req()를 전송하는 측에서는 상기 new_flow_req()를 전송할 때 해당 new_flow_req()에 포함된 서비스 타입과 서비스 타입 전송 순서를 저장하였다가, 이후 new_flow_cnf()가 수신되면 저장된 서비스 타입과 서비스 타입 전송 순서를 참조하여 수신된 new_flow_cnf()가 어느 서비스 타입의 요청 new_flow_req()에 대한 응답인지를 구분할 수 있도록 한다.

본 발명에서는 설명의 편의를 위해 케이블카드에서 new_flow_req()를 호스트로 전송하고, 호스트는 이에 대한 응답으로 new_flow_cnf()를 케이블카드로 전송한다고 가정하고 설명한다. 이는 하나의 실시예이며, 반대로 호스트에서 new_flow_req()를 전송하고, 케이블카드에서 new_flow_cnf()를 전송할 수도 있다.

도 6은 본 발명에 따른 확장 채널 플로우 연결 설정을 요청하고, 그 요청에 따른 응답을 받아 처리하는 측 예를 들면, 케이블카드의 동작 흐름도를 보이고 있다.

즉, 케이블카드는 확장 채널 플로우 연결 설정을 요청하기 위해, 플로우 설정을 원하는 서비스 타입이 표시된 new_flow_req()를 호스트로 전송하고(단계 601), 상기 서비스 타입을 저장한다(단계 602).

이때 상기 케이블카드는 한번에 하나의 new_flow_req()만을 전송할 수도 있 고, 요청에 따른 응답을 받기 전에 연속적으로 복수개 이상의 new_flow_req()를 전송할 수도 있다. 만일 연속적으로 복수개 이상의 new_flow_req()를 전송하는 경우에는 서비스 타입뿐만 아니라 서비스 타입의 전송 순서도 저장한다.

예를 들어, 상기 케이블카드에서 도 8과 같이 서비스 타입이 IP_U로 설정된 new_flow_req()와 IP_M으로 설정된 new_flow_req()를 호스트로 전송하였다고 가정하자. 그러면 상기 케이블카드는 IP_U와 IP_M라는 서비스 타입을 저장하면서, IP_U를 갖는 new_flow_req()가 IP_M을 갖는 new_flow_req()보다 먼저 전송하였다는 정보도 함께 저장한다.

이 후 호스트로부터 new_flow_cnf()가 전송되면(단계 603), 상기 케이블카드는 저장된 서비스 타입 정보와 서비스 타입 전송 순서를 참조하여 상기 단계 603에서 수신된 new_flow_cnf()가 어떤 서비스 타입의 플로우 설정 요청에 대한 응답인지를 결정한다.

이때 어떤 서비스 타입의 플로우 설정 요청에 대한 응답인지를 결정하는 방법은 저장된 서비스 타입과 서비스 타입 전송 순서만을 참조하여 결정할 수도 있고, 수신된 new_flow_cnf()에 포함된 상태 필드 값을 함께 참조하여 결정할 수도 있다.

본 발명에서는 일 실시예로, 수신된 new_flow_cnf()에 포함된 상태 필드 값과 저장된 서비스 타입 정보 및 서비스 타입 전송 순서를 참조하여 어느 서비스 타입의 플로우 설정 요청에 대한 응답인지를 판별한다.

즉, 수신된 new_flow_cnf()에 포함된 상태 필드 값이 0x00 즉, 플로우 설정 요청을 허가한 경우에는 수신된 new_flow_cnf()에 서비스 타입 정보가 포함되므로, 저장된 서비스 타입과 서비스 타입 전송 순서를 참조하지 않는다.

그리고 수신된 new_flow_cnf()에 포함된 상태 필드 값이 0x00가 아니면 수신된 new_flow_cnf()에 서비스 타입 정보가 포함되지 않으므로, 이때는 저장된 서비스 타입과 서비스 타입 전송 순서를 참조한다. 특히 상태 필드 값이 0x04 즉, 네트워크 busy 임을 표시하면, 저장된 서비스 타입과 서비스 타입 전송 순서를 참조한다.

이를 위해 호스트로부터 new_flow_cnf()가 전송되면, 상기 케이블카드는 수신된 new_flow_cnf()에 포함된 상태 필드(status_field) 값을 추출한다(단계 604).

상기 단계 604에서 상태 필드 값이 0x04이면 즉, 네트워크가 busy 상태여서 플로우 설정이 거절된 경우이면, 저장된 서비스 타입과 서비스 타입 전송 순서를 참조하여 가장 최근에 전송한 서비스 타입을 검출하고, 상기 단계 603에서 수신된 new_flow_cnf()가 상기 검출된 서비스 타입의 플로우 설정 요청 new_flow_req()의 응답이라고 간주한다(단계 605).

예를 들어, 도 8과 같이 서비스 타입이 IP_U,IP_M으로 설정된 new_flow_req()APDU 2개가 순차적으로 전송된 경우라면, 상기 단계 605는 단계 603에서 수신된 new_flow_cnf()가 IP_M 플로우 설정 요청에 대한 응답으로 간주한다.

이러한 경우, IP_M 플로우 설정 요청보다 먼저 전송된 IP_U 플로우 설정 요청에 대한 응답이 아직 도착하지 않았으므로, 상기 케이블카드는 IP_U 플로우 설정 요청에 대한 응답 new_flow_cnf()이 도착할 때까지 새로운 new_flow_req()을 전송 하지 않고 대기한다(단계 606). 즉, 상기 단계 605에서 간주된 서비스 타입을 갖는 요청보다 먼저 전송된 요청에 대한 응답이 도착할 때까지 새로운 확장 채널 플로우 설정 요청을 하지 않는다.

그리고 상기 단계 604에서 상태 필드 값이 0x00이면 즉, 플로우 설정을 허가한 경우이면 수신된 new_flow_cnf()에 포함된 서비스 타입에 해당하는 확장 채널 플로우의 연결을 설정한다(단계 605).

또한 상기 단계 604에서 상태 필드 값이 0x00도 아니고, 0x04도 아닌 다른 값 예를 들어, 0x01,0x02,0x03,0x05 중 어느 하나이면 상태 필드 값에 대응된 동작을 수행한다(단계 608). 이때 저장된 서비스 타입과 서비스 타입 전송 순서 정보를 참조하여 대응된 동작을 수행할 수도 있다.

한편 new_flow_req()를 수신하는 측에서는 시스템의 불안정, 원격지 서버 환경이나 네트워크 환경이 비정상적인 경우 등으로 인해 수신된 new_flow_req()에 대한 응답 new_flow_cnf()을 전송하지 못하는 경우가 발생할 수 있다.

예를 들어, 호스트에서 서비스 타입이 IP_U로 설정된 new_flow_req()를 수신하였다고 가정할 때, 상기 호스트는 IP 어드레스를 얻기 위해서 DHCP 서버와 통신(IP packet)을 수행할 것이다. 이때, 네트워크 상태나 DHCP 서버의 상태가 비정상적인 경우, 상기 호스트는 DHCP 프로토콜에 의해서 IP 어드레스를 얻을 때까지 계속 DHCP 서버와 통신을 수행한다.

결국, 상기 호스트는 DHCP 서버와의 통신의 결과로 IP 어드레스를 얻을 때까지 계속 통신을 시도하게 되고, IP 어드레스를 얻기 이전에는 케이블카드로 new_flow_cnf()를 전송하지 못하게 된다.

그러면 케이블카드도 새로운 new_flow_req()를 전송하지 못하고 계속 대기 상태로 있게 된다.

이것은 한번에 하나의 new_flow_req()/new_flow_cnf() 트랜잭션을 수행하여야 하는 경우에 적용될 수 있다. 또한 상기 도 6과 같이 복수개 이상의 new_flow_req()가 연속적으로 전송된 경우, 수신된 new_flow_cnf()를 가장 최근에 전송한 new_flow_req()에 대한 응답으로 간주하고, 새로운 new_flow_cnf()가 수신될 때까지 새로운 new_flow_req()를 전송하지 않고 대기하는 경우에도 적용될 수 있다.

도 8을 예로 들면, 케이블카드는 일단 서비스 타입이 IP_U로 설정된 new_flow_req()를 전송했기 때문에, 상기 new_flow_req()에 대한 응답 new_flow_cnf()을 받기 전에는 새로운 new_flow_req()를 전송할 수 없게 된다.

이를 해결하기 위하여, 본 발명은 시간(또는 시도 횟수)을 미리 설정하고, new_flow_req()를 수신한 시점부터 미리 설정된 시간(또는 시도 횟수)이 경과할 때까지 상기 new_flow_req()에 대한 응답 new_flow_cnf()을 전송하지 못하면, new_flow_cnf()의 상태 필드 값을 적절하게 설정하여 무조건 전송하도록 한다. 여기서 상기 시간이나 시도 횟수는 어느 하나로 고정할 수도 있고, 서비스 타입의 특성에 맞게 시간이나 시도 횟수로 설정할 수도 있다. 예를 들어, 서비스 타입이 IP_U인 경우에는 시간으로 설정할 수도 있고, DHCP 클라이언트(client)가 IP 어드레스를 얻기 위해서 시도한 횟수로 설정할 수도 있다. 여기서, 상기 시간이나 시도 횟수는 실험에 의해 가장 적절하게 결정된다.

도 7은 본 발명에 따른 확장 채널 플로우의 연결 설정 요청에 따른 응답을 처리하는 측, 예를 들면 호스트의 동작 흐름도를 보이고 있다.

즉, 상기 호스트는 new_flow_req()가 수신되면(단계 701), 상기 new_flow_req()가 수신된 시점부터 시간(또는 시도 횟수)을 카운트하기 시작한다(단계 702). 그리고 상기 기 설정된 시간(또는 시도 횟수)이 경과할 때까지 전술한 이유 등으로 인해 수신된 new_flow_req()에 대한 응답 new_flow_cnf()를 전송하지 못하는 대기 상태로 판별되면, 상태 필드 값을 기 설정된 값 예를 들면, 0x03으로 표시한 new_flow_cnf()를 무조건 케이블카드로 전송한다(단계 703). 만일 기 설정된 시간(또는 시도 횟수)이 경과하기 전에 수신된 new_flow_req()에 대한 응답 new_flow_cnf()를 케이블카드로 전송하였다면 상기 카운트되는 시간(또는 시도 횟수)은 초기화된다.

도 8을 예로 들면, 케이블카드는 상태 필드 값이 0x04인 new_flow_cnf()를 수신하면, 저장된 서비스 타입과 서비스 타입 전송 순서를 참조하여 수신된 new_flow_cnf()가 IP_M 플로우 설정 요청에 대한 응답으로 간주한다. 그래서 새로운 new_flow_cnf() 즉, IP_U 플로우 설정 요청에 대한 응답이 수신될 때까지 IP_M 트랜잭션을 더 이상 시도하지 않고 대기한다.

상기 호스트에서는 IP_U 플로우 연결 설정에 대한 응답 new_flow_cnf()을 만들기 위한 동작을 수행한다. 예를 들면, IP 어드레스를 얻기 위해서 DHCP 서버와 통신을 수행할 것이다. 이때 네트워크 상태나 DHCP 서버의 상태가 비정상적이어서 상기 DHCP 서버로부터 IP 어드레스를 얻기 위한 시도를 계속하다가 기 설정된 시간(또는 시도 횟수)이 경과되면, IP 어드레스를 얻지 못하였어도 무조건 상태 필드 값을 0x03으로 설정한 new_flow_cnf()을 케이블카드로 전송한다.

그러면 상기 케이블카드는 자신이 기억하고 있는 서비스 타입과 서비스 타입의 전송 순서를 참조하여, 상태 필드 값이 0x03으로 설정되어 수신된 new_flow_cnf()가 IP_U 플로우의 설정 요청에 대한 응답이라고 결정한다.

상기와 같이 결정하고 나면, 케이블카드는 IP_M 트랜잭션을 시도할지, 아니면 IP_U 트랜잭션을 시도할지, 아니면 기타 다른 서비스 타입에 대한 트랜잭션을 시도할지를 결정한다. 도 8은 IP_M 트랜잭션을 다시 시도하는 예를 보이고 있다. 그리고 상기 도 8은 호스트와 케이블카드의 역할이 뒤바뀐 경우에도 동일하게 성립된다.

도 9는 본 발명이 적용되는 방송 수신기의 일 실시예를 보인 구성 블록도로서, 크게 호스트와 케이블카드로 구성된다.

도 9를 보면, 호스트는 제어부(CPU,900), 제1 내지 제3 튜너(911~913), 제1 내지 제3 복조부(920,950,960), 역다중화부(930), 디코더(940), 스위칭부(970), 및 변조부(980)를 포함하여 구성된다.

상기 케이블카드(800)는 하나의 스트림만을 처리할 수 있는 싱글 스트림(Single stream) 카드일 수도 있고, 다수개의 스트림을 동시에 처리할 수 있는 멀티 스트림(Multi stream) 카드일 수도 있다. 도 9에서는 멀티 스트림 카드의 예를 도시하고 있다.

상기 제1 튜너(911)는 안테나를 통해 전송되는 지상파 A/V(Audio/Video) 방송이나 케이블을 통해 인-밴드(In-band)로 전송되는 케이블 A/V 방송 중 특정 채널 주파수만을 튜닝하여 제1 복조부(920)로 출력한다.

이때 지상파 방송과 케이블 방송은 전송 방식이 다르므로 제1 복조부(920)에서의 복조 방식도 다르다. 즉 지상파 A/V 방송은 VSB(Vestigial Sideband Modulation) 방식으로 변조되어 전송되고, 케이블 A/V 방송은 QAM(Quadrature Amplitude Modulation) 방식으로 변조되어 전송된다. 그러므로 제1 튜너(911)에서 튜닝된 채널 주파수가 지상파 방송이면 제1 복조부(920)에서 VSB 방식으로 복조되고, 케이블 방송이면 QAM 방식으로 복조된다.

또한 상기 제1 복조부(920)에서 복조된 신호가 지상파 방송이면 복조된 신호는 바로 역다중화부(930)로 출력되고, 케이블 방송이면 슬롯에 장착된 케이블카드(800)를 통해 역다중화부(930)로 출력된다. 상기 케이블카드(800)는 고부가가치의 방송 콘텐츠에 대한 복사 방지 및 제한적인 접근을 위하여, 제한 수신(Conditional Access ; CA) 시스템을 포함한다.

즉, 상기 케이블 카드(800)는 케이블 A/V 방송에 스크램블이 걸려있다면 디스크램블하여 역다중화부(930)로 출력한다. 만일 케이블카드(800)가 장착되어 있지 않다면 상기 제1 복조부(920)에서 복조된 케이블 A/V 방송은 바로 역다중화부(930)로 출력된다. 이 경우 스크램블된 케이블 A/V 방송은 디스크램블을 하지 못하므로 정상적으로 시청하지 못한다.

상기 역다중화부(930)는 다중화되어 전송된 비디오 신호와 오디오 신호를 분 리하여 디코더(940)로 출력한다. 상기 디코더(940)는 각각 비디오 디코딩 알고리즘과 오디오 디코딩 알고리즘을 통해 압축된 A/V 신호를 원래 신호로 복원한 후 디스플레이를 위해 출력한다.

한편 제2 튜너(912)는 DSG 방식으로 케이블을 통해 전송되는 데이터 방송 중 특정 채널 주파수를 튜닝하여 제2 복조부(950)로 출력한다. 상기 제2 복조부(950)는 DSG 방식의 데이터 방송을 복조한 후 제어부(900)로 출력한다.

또한 제3 튜너(913)는 OOB 방식으로 케이블을 통해 전송되는 데이터 방송 중 특정 채널 주파수를 튜닝하여 제3 복조부(960)로 출력한다. 상기 제3 복조부(960)는 OOB 방식의 데이터 방송을 QPSK 복조한 후 케이블 카드(800)로 출력한다. 즉 상기 OOB의 경우 QPSK 전송 방식을 사용하기 때문에 수신측에서도 QPSK 방식으로 복조하는 것이다.

그리고 상기 케이블 방송국과 케이블 방송 수신기간의 양방향 통신이 가능할 경우, 케이블 방송 수신기에서 케이블 방송국으로 전송하는 정보들(예를 들면, 유료 프로그램 신청, 수신기의 상태 정보, 사용자 입력 등)은 OOB나 DSG 방식으로 전송된다. 이를 위해 스위칭부(970)가 구비된다. 상기 스위칭부(970)의 스위칭 제어는 제어부(900)에서 이루어진다.

즉 OOB 모드이면 사용자나 수신기 상태 정보가 케이블카드(800)와 스위칭부(970)를 통해 변조부(980)로 출력되고, 변조부(980)에서 QPSK 방식으로 변조된 후 케이블을 통해 케이블 방송국으로 전송된다. 또한 DSG 모드이면 사용자나 수신기 상태 정보가 제어부(900)와 스위칭부(970)를 통해 변조부(980)로 출력되고, 변 조부(980)에서 16-QAM 방식으로 변조된 후 케이블을 통해 케이블 방송국으로 전송된다.

한편 상기 호스트와 케이블카드 간에 확장 채널(extended channel)을 통해서 데이터를 전송하기 위해서는 먼저, 케이블카드와 호스트간에 정의된 서비스 타입(또는 데이터 타입)에 해당되는 전송 선로 즉, 플로우를 설정해야 한다.

이때 상기 확장 채널 플로우를 설정하고자 하는 측(케이블카드 또는 호스트)의 제어부(CPU)에서는 new_flow_req()를 전송할 때 상기 new_flow_req()에 포함된 서비스 타입과 서비스 타입 전송 순서를 저장한다. 여기서 상기 new_flow_req()를 전송하는 측이 케이블카드라면, 상기 서비스 타입과 서비스 타입 전송 순서는 케이블카드에 저장되고, 호스트라면 호스트에 저장된다.

그리고 나서, 상기 new_flow_req()를 전송한 측에서는 new_flow_cnf()이 수신되면, 수신된 new_flow_cnf()에 포함된 상태 필드 값과 저장된 서비스 타입 및 서비스 타입 전송 순서를 참조하여 수신된 new_flow_cnf()이 어떤 서비스 타입의 플로우 설정 요청에 대한 응답인지를 판별한다. 예를 들어, 수신된 new_flow_cnf()에 포함된 상태 필드 값이 0x04이면 가장 최근에 전송한 서비스 타입의 플로우 설정 요청 new_flow_req()의 응답으로 간주한다.

또한 상기 new_flow_req()를 수신한 측에서는 상기 new_flow_req()에 포함된 정보를 이용하여 응답 new_flow_cnf()을 생성하여 전송하여야 하는데, 기 설정된 시간(또는 시도 횟수)가 경과할 때까지 전술한 여러 가지 이유로 응답 new_flow_cnf()을 전송하지 못하면, 원하는 정보를 얻지 못했더라도 무조건 new_flow_cnf()을 만들어 전송한다. 이때 상태 필드 값을 기 설정된 값 예를 들면, 0x03으로 표시하여 전송한다.

본 발명은 상술한 실시예에 한정되지 않으며, 첨부된 청구범위에서 알 수 있는 바와 같이 본 발명이 속한 분야의 통상의 지식을 가진 자에 의해 변형이 가능하고 이러한 변형은 본 발명의 범위에 속한다.

상기에서 설명한 본 발명에 따른 방송 수신기 및 인터페이스 방법은 다음과 같은 잇점이 있다.

첫째, new_flow_req()를 전송하고 이에 대한 응답으로 new_flow_cnf()를 전송받은 측에서는 기 저장된 서비스 타입과 서비스 타입 전송 순서를 참조함으로써, 확장 채널의 플로우 설정에 대한 요청이 거절된 경우에도 어떤 서비스 타입의 요청이 거절되었는지를 알 수 있게 된다. 특히 복수개 이상의 new_flow_req()를 연속으로 전송한 후 응답 new_flow_cnf()이 수신되었을 때에도 어떤 서비스 타입의 플로우 설정 요청에 대한 응답인지를 알 수 있게 된다.

둘째, new_flow_req()를 수신하고 이에 대한 응답으로 new_flow_cnf()를 생성하여 전송하는 측에서는 기 설정된 시간(또는 시도 횟수)이 경과할 때까지 원하는 정보를 얻지 못하면 플로우 설정 거절을 표시한 new_flow_cnf()을 생성하여 무조건 전송하도록 함으로써, 상기 new_flow_req()를 전송하는 측에서 새로운 new_flow_req()를 전송하지 못하고 계속 대기하게 되는 문제점을 해결할 수 있게 된다.

이상 설명한 내용을 통해 당업자라면 본 발명의 기술 사상을 일탈하지 아니하는 범위에서 다양한 변경 및 수정이 가능함을 알 수 있을 것이다.

따라서, 본 발명의 기술적 범위는 실시예에 기재된 내용으로 한정되는 것이 아니라 특허 청구의 범위에 의하여 정해져야 한다.

Claims

확장채널 플로우를 설정하기 위해 적어도 해당 서비스 타입과 상기 서비스 타입에 따른 고유 정보를 전송함과 동시에 서비스 타입 정보를 저장하는 요청 단계; 및

확장채널 플로우 설정 요청에 따른 응답이 수신되면, 상기 응답에 포함된 상태 정보와 상기 요청 단계에서 저장된 서비스 타입 정보 중 적어도 하나를 참조하여 어떤 서비스 타입의 플로우 설정 요청에 따른 응답인지를 확인하는 단계를 포함하여 이루어지는 것을 특징으로 하는 인터페이스 방법.
제 1 항에 있어서, 상기 서비스 타입 정보는

확장채널 플로우의 설정을 요청하는 서비스 타입과 서비스 타입 전송 순서를 포함하는 것을 특징으로 하는 인터페이스 방법.
제 2 항에 있어서, 상기 확인 단계는

상기 응답에 포함된 상태 정보가 플로우 설정 거절을 표시하면 상기 서비스 타입과 서비스 타입 전송 순서를 참조하여 수신된 응답이 어떤 서비스 타입의 플로우 설정 요청에 따른 응답인지를 확인하는 것을 특징으로 하는 인터페이스 방법.
제 3 항에 있어서, 상기 확인 단계는

수신된 응답이 어떤 서비스 타입의 플로우 설정 요청에 따른 응답인지가 확인된 후, 새로이 수신할 응답이 남아있으면 새로운 응답이 수신될 때까지 새로운 확장채널 플로우의 설정을 요청하지 않고 대기하는 단계를 더 포함하는 것을 특징으로 하는 인터페이스 방법.
제 2 항에 있어서, 상기 확인 단계는

상기 응답에 포함된 상태 정보가 네트워크 busy로 이유로 플로우 설정 거절을 표시하면 상기 서비스 타입과 서비스 타입 전송 순서를 참조하여 가장 최근에 전송한 서비스 타입의 플로우 설정 요청에 따른 응답으로 결정하는 것을 특징으로 하는 인터페이스 방법.
제 5 항에 있어서, 상기 확인 단계는

수신된 응답이 가장 최근에 전송한 서비스 타입의 플로우 설정 요청에 따른 응답으로 확인되면 새로운 응답이 수신될 때까지 새로운 확장채널 플로우의 설정을 요청하지 않고 대기하는 단계를 더 포함하는 것을 특징으로 하는 인터페이스 방법.
제 1 항에 있어서, 상기 확인 단계는

상기 응답에 포함된 상태 정보가 플로우 설정 허가를 표시하면 상기 응답에 포함된 서비스 타입에 해당하는 확장채널 플로우를 설정하는 단계를 더 포함하는 것을 특징으로 하는 인터페이스 방법.
제 1 항에 있어서,

상기 서비스 타입에 따른 고유 정보는 MPEG 섹션인 경우 PID, IP 유니캐스트인 경우 MAC 어드레스, IP 멀티캐스트인 경우 멀티캐스트 그룹 ID를 적어도 포함하는 것을 특징으로 하는 인터페이스 방법.
확장채널의 플로우 설정 요청이 수신되면 시간을 카운트하는 단계; 및

상기 카운트 값이 기 설정된 값이 될 때까지 상기 확장채널 플로우의 설정 요청에 따른 응답이 전송되지 않으면, 플로우 설정 거절을 표시하는 상태 정보를 포함하는 응답을 무조건 전송하는 단계를 포함하여 이루어지는 것을 특징으로 하는 인터페이스 방법.
제 9 항에 있어서, 상기 카운트 단계는

확장채널의 플로우 설정 요청에 포함된 정보를 얻기 위해 시도한 횟수를 카운트하는 단계를 더 포함하는 것을 특징으로 하는 인터페이스 방법.
제 9 항에 있어서, 상기 응답 단계는

플로우 설정 요청을 허가할 경우, 플로우 설정을 허가함을 표시하는 상태 필드, 플로우 ID, 해당 서비스 타입을 포함하는 응답을 전송하는 것을 특징으로 하는 인터페이스 방법.
제 11 항에 있어서, 상기 응답 단계는

플로우 설정 요청이 허가된 서비스 타입이 IP 유니캐스트인 경우, 상기 응답에 적어도 IP 어드레스, 플로우 타입 정보를 더 포함하여 전송하는 것을 특징으로 하는 인터페이스 방법.
서비스 타입에 따른 확장채널 플로우를 통해 해당 데이터를 주고받는 호스트와 케이블카드를 포함하여 구성되며,

상기 호스트와 케이블카드 중 어느 하나는, 확장채널의 플로우 설정을 요청하기 위해 적어도 해당 서비스 타입과 상기 서비스 타입에 따른 고유 정보를 전송함과 동시에 서비스 타입 정보를 저장하며, 이후 플로우 설정 요청에 따른 응답이 수신되면 상기 응답에 포함된 상태 정보와 기 저장된 서비스 타입 정보 중 적어도 하나를 참조하여 어떤 서비스 타입의 플로우 설정 요청에 따른 응답인지를 확인하고;

상기 호스트와 케이블카드 중 다른 하나는, 확장채널의 플로우 설정 요청이 수신되면 상기 요청에 포함된 서비스 타입의 플로우 설정 가능 여부를 확인한 후 그 결과를 표시한 상태 정보를 포함하는 응답을 전송하는 것을 특징으로 하는 방송 수신기.
제 13 항에 있어서, 상기 서비스 타입 정보는

확장채널의 플로우 설정을 요청하는 서비스 타입과 서비스 타입 전송 순서를 포함하는 것을 특징으로 하는 방송 수신기.
제 13 항에 있어서,

상기 호스트와 케이블카드 중 응답을 수신하는 측에서는 수신된 응답에 포함된 상태 정보가 플로우 설정 거절을 표시하면 상기 서비스 타입과 서비스 타입 전송 순서를 참조하여 수신된 응답이 어떤 서비스 타입의 플로우 설정 요청에 따른 응답인지를 확인하는 것을 특징으로 하는 방송 수신기.
제 15 항에 있어서,

상기 호스트와 케이블카드 중 응답을 수신하는 측에서는 수신된 응답이 어떤 서비스 타입의 플로우 설정 요청에 따른 응답인지가 확인된 후 새로이 수신할 응답이 남아있으면 새로운 응답이 수신될 때까지 새로운 확장채널의 플로우 설정을 요청하지 않고 대기하는 것을 특징으로 하는 방송 수신기.
제 13 항에 있어서,

상기 호스트와 케이블카드 중 응답을 수신하는 측에서는 수신된 응답에 포함된 상태 정보가 플로우 설정 허가를 표시하면 상기 응답에 포함된 서비스 타입에 해당하는 확장채널 플로우를 설정하는 것을 특징으로 하는 방송 수신기.
서비스 타입에 따른 확장채널 플로우를 통해 해당 데이터를 주고받는 호스트와 케이블카드를 포함하여 구성되며,

상기 호스트와 케이블카드 중 어느 하나는, 확장채널의 플로우 설정을 요청하기 위해 적어도 해당 서비스 타입과 상기 서비스 타입에 따른 고유 정보를 전송하고;

상기 호스트와 케이블카드 중 다른 하나는, 확장채널의 플로우 설정 요청이 수신되면 시간을 카운트하여 카운트 값이 기 설정된 값이 될 때까지 상기 확장채널의 플로우 설정 요청에 따른 응답을 전송하지 못하면, 플로우 설정 거절을 표시하는 상태 정보를 포함하는 응답을 무조건 전송하는 것을 특징으로 하는 방송 수신기.
제 18 항에 있어서,

상기 호스트와 케이블카드 중 응답을 전송하는 측에서는 확장채널의 플로우 설정 요청에 포함된 정보를 얻기 위해 시도한 횟수를 카운트하는 것을 특징으로 하는 방송 수신기.
제 18 항에 있어서,

상기 호스트와 케이블카드 중 응답을 전송하는 측에서는 플로우 설정 요청을 허가할 경우, 플로우 설정을 허가함을 표시하는 상태 정보, 플로우 ID, 해당 서비스 타입을 포함하는 응답을 전송하는 것을 특징으로 하는 방송 수신기.
제 20 항에 있어서,

플로우 설정 요청이 허가된 서비스 타입이 IP 유니캐스트인 경우, 상기 응답에 적어도 IP 어드레스, 플로우 타입을 더 포함하여 전송하는 것을 특징으로 하는 방송 수신기.