KR20090002821A

KR20090002821A - 서비스 가이드 정보 수신 방법 및 서비스 가이드 정보 수신장치

Info

Publication number: KR20090002821A
Application number: KR1020070067099A
Authority: KR
Inventors: 문경수; 최진영; 최선영
Original assignee: 엘지전자 주식회사
Priority date: 2007-07-04
Filing date: 2007-07-04
Publication date: 2009-01-09

Abstract

본 발명은 서비스 가이드 정보 수신 방법 및 서비스 가이드 정보 수신 장치에 관한 것이다. 본 발명은 인터액티브 채널을 통해 서비스 가이드 정보를 전송할 수 있는 다수의 서버 중 마스터(master) 서버의 위치 정보를 얻는 획득단계 및 상기 마스터 서버로부터 서비스 가이드 정보를 수신할 수 있는지 여부를 판단하고, 상기 판단결과에 따라 마스터 서버가 서비스 가이드 정보를 전송할 수 없는 경우, 슬레이브(slave) 서버에 대한 위치 정보를 얻어 상기 슬레이브 서버로부터 서비스 가이드 정보를 수신하고, 상기 판단결과 마스터 서버로부터 서비스 가이드 정보를 수신한 경우 상기 마스터 서버로부터 서비스 가이드 정보를 수신하는 수신단계를 포함하는 서비스 가이드 정보 수신 방법을 제공한다.

인터액티브, ESG, 서버, URL, 마스터, 슬레이브

Description

서비스 가이드 정보 수신 방법 및 서비스 가이드 정보 수신 장치{method of receiving service guide information and apparatus for receiving service guide information}

본 발명은 서비스 가이드 정보 수신 방법 및 서비스 가이드 정보 수신 장치에 관한 것이다.

콘텐츠는 유무선 통신을 통해 사용자에게 이미지, 소리 및 문자를 포함하는 내용물 또는 정보을 지칭한다. 최근의 콘텐츠는 디지털 방식으로 제작되어 다양한 방송 채널과 인터액티브(interactive) 채널을 통해 제공되고 있다. 예를 들어 사용자는 방송을 통해 시청한 콘텐츠를 인터넷 등의 통해 다운로드 받고 시청할 수 있다. 방송 시스템과 통신 시스템이 융합되면서 방송 시스템과 통신 시스템으로부터 동일한 콘텐츠를 제공받는 방안이 고려되고 있다.

본 발명의 목적은 효율적으로 서비스 가이드 정보를 얻을 수 있는 서비스 가이드 정보 수신 방법 및 서비스 가이드 정보 수신 장치를 제공하는 것이다.

상기 목적을 달성하기 위하여 본 발명은 인터액티브 채널을 통해 서비스 가이드 정보를 전송할 수 있는 다수의 서버 중 마스터(master) 서버의 위치 정보를 얻는 획득단계 및 상기 마스터 서버로부터 서비스 가이드 정보를 수신할 수 있는지 여부를 판단하고, 상기 판단결과에 따라 마스터 서버가 서비스 가이드 정보를 전송할 수 없는 경우, 슬레이브(slave) 서버에 대한 위치 정보를 얻어 상기 슬레이브 서버로부터 서비스 가이드 정보를 수신하고, 상기 판단결과 마스터 서버로부터 서비스 가이드 정보를 수신한 경우 상기 마스터 서버로부터 서비스 가이드 정보를 수신하는 수신단계를 포함하는 서비스 가이드 정보 수신 방법을 제공한다.

또한, 서비스 가이드 정보를 전송하는 다수의 서버 중 마스터(master) 서버의 위치 정보를 포함하는 부트스트랩 정보를 수신하는 수신부 및 상기 수신부가 수신한 부트스트랩 정보로부터 상기 마스터 서버의 위치 정보를 얻고 이를 이용해 상기 마스터 서버에 서비스 가이드 정보를 요청하도록 하는 메세지를 생성하여 출력하고, 상기 마스터 서버로부터 서비스 가이드 정보를 전송받지 못할 경우, 슬레이브 서버의 위치 정보를 얻고 상기 슬레이브 서버로부터 서비스 가이드 정보를 수신하는 제어부를 포함하는 서비스 가이드 정보 수신 장치를 제공한다.

본 발명에 따르면 단말기가 마스터 서버 이외의 슬레이브 서버를 식별할 수 있고, 슬레이브 서버로부터 서비스 가이드 정보를 수신할 수 있어 효율적으로 서비스 가이드 정보를 수신할 수 있다.

이하에서는 서비스되는 콘텐츠에 관련되고, 콘텐츠에 접근할 수 있는 정보를 서비스 가이드 정보라고 호칭한다.

서비스 가이드 정보는 사용자가 서비스를 선택할 수 있도록 하는 각 서비스에 대한 스케줄 정보 및 사용자가 단말기로 아이템들을 구입하고 접근하여 저장할 수 있도록 하는 정보 중 적어도 하나의 정보를 포함한다. 사용자는 단말기를 통해 서비스 가이드 정보를 제공받을 수 있고, 원하는 서비스를 선택하거나 구매할 수 있다. 여기서, 인터액티브 채널(interactive channel)은 양방향 통신이 가능한 채널을 의미하고, 브로드캐스트 채널(broadcast channel) 또는 방송 채널은 멀티 캐스트 중 사용자를 지정하지 않은 단방향 통신 채널을 의미한다.

서비스 가이드 정보는 단말기가 서비스 가이드 정보를 이용할 수 있는지 또는 그 서비스 가이드를 어떻게 얻는지 인식하는 제 1 과정(이하 부트스트랩(bootstrap) 과정), 단말기가 서비스 가이드 정보를 얻고 처리하는 제 2 과정(이하 획득(acquisition) 과정), 단말기가 얻은 서비스 가이드 정보를 갱신하는 제 3 과정(이하 갱신(update) 과정)에 의해 단말기에서 처리될 수 있다.

단말기는 수신 신호로부터 제 1 과정을 위한 정보를 얻은 후에 그 정보를 트리거(trigger) 정보로 사용하여 서비스 가이드 정보를 얻을 수 있는데, 이하에서 제 1 과정에서 얻는 정보를 부트스트랩 정보라고 호칭한다. 단말기는 부트스트랩 정보를 통해 각각의 서비스 가이드 정보를 얻고, 서비스 가이드 정보로부터 각각 서비스에 대한 정보를 얻거나 콘텐츠에 접근할 수 있다.

도 1은 서비스 가이드 정보에 대한 예를 나타낸 도면이다. 도 1을 참조하여 서비스 가이드 정보의 구조를 설명하면 다음과 같다.

서비스 가이드 정보는 세분화된 하위 단위로 사용자에게 제공될 수 있다. 여기서 서비스 가이드 정보의 세분화된 하위 단위를 프래그먼트(fragment)라고 호칭한다. 도 1의 예는 서비스(service) 프래그먼트, 스케줄이벤트(ScheduleEvent) 프래그먼트, 콘텐츠(contents) 프래그먼트, 서비스번들(serviceBundle) 프래그먼트, 퍼처스(purchase) 프래그먼트, 퍼처스채널(purchaseChannel) 프래그먼트 및 어큐지션(acquistion) 프래그먼트를 포함한다. 도 1의 화살표는 참조 관계를 나타낸다. 도 1에 나타낸 예를 따르면 서비스번들 프래그먼트는 서비스 프래그먼트를 참조할 수 있다. 각 화살표 위에 예시된 수는 각 프레그멘트 별 참조 가능한 개수를 나타낸다. 예를 들어 0...n은 0부터 n개(n은 임의의 자연수)까지 다른 프래그먼트를 참조할 수 있음을 의미한다.

서비스 프래그먼트는 사용자에게 제공되는 서비스, 예를 들면 종래의 하나의 텔레비전 채널과 같은 서비스에 대한 정보를 포함한다. 서비스 번들 프래그먼트는 서비스 그룹에 대한 정보를 포함한다. 서비스 그룹은 예를 들어 스포츠 서비스 번들, 시네마 서비스 번들 등이 있을 수 있다. 콘텐츠 프래그먼트는 콘텐츠에 대한 메타데이터(metadata)를 포함한다. 예를 들어 콘텐츠 프래그먼트에는 콘텐츠에 대한 A/V, 텍스트, 이미지 등의 타입이 콘텐츠 프래그먼트에 포함될 수 있다.

스케줄이벤트 프래그먼트는 서비스의 하나의 콘텐츠에 대한 스케줄 정보를 포함한다. 예를 들면 그 콘텐츠의 방송 시간이 이에 해당할 수 있다. 퍼처스 프래 그먼트는 사용자가 구매할 수 있는 서비스에 대한 구매에 관련된 정보를 포함한다. 퍼처스채널 프래그먼트는 단말기나 사용자가 구매시스템과 소통하는 인터페이스를 의미한다. 퍼처스채널 프래그먼트는 구매 시스템에 관련된 파라미터나 구매 채널의 관리에 대한 정보를 포함한다.

어큐지션 프래그먼트(acquisition fragment)는 서비스나 콘텐트의 접근에 관련된 정보를 포함한다. 사용자는 단말기로부터 서비스 가이드 정보를 통해 어큐지션 프래그먼트에 관련된 정보를 통해 서비스나 콘텐트에 접근하고, 이를 구매할 수 있다.

이와 같이 서비스 가이드 정보는 프래그먼트로 호칭되는 하위 단위를 가질 수 있다. 각각의 프래그먼트는 인코딩되어 하나 이상의 프래그먼트 단위들이 인캡슐레이션되거나 하나의 더 큰 단위로 형성되어 전송될 수 있는데, 이 인캡슐레이션된 단위를 컨테이너(container)라고 호칭한다. 서비스 가이드 정보의 컨테이너는 서비스 가이드 정보를 전송하는 프로토콜에 따라 송수신될 수 있는데, 이러한 정보를 송수신하는 시스템 및 송수신 프로토콜은 아래에서 예시한다.

한편 위에서 기술한 바와 같이 서비스 가이드 정보는 부트스트랩 정보로부터 얻을 수 있는데, 서비스 가이드 정보의 부트스트랩 정보를 수신하는 과정을 설명하면 다음과 같다.

방송 채널을 통해 전송되는 방송 신호에서 하나 이상이 섹션으로 전송되는 테이블 정보 중 INT(IP/MAC Notification table)는, 그 방송 신호의 트랜스포트 스트림 내에 IP(internet protocol) 스트림의 IP 어드레스와 트랜스포트 스트림의 PID(packet identifier)간의 매핑 정보를 포함한다. 단말기가 매핑 정보인 INT로부터 서비스 가이드 정보의 부트스트랩 정보를 수신하기 위한 IP 어드레스를 얻은 경우, 단말기는 얻은 IP 어드레스가 정의된 PMT 상의 프로그램 넘버(program_number)로부터 부트스트랩 정보를 수신할 수 있는 패킷 아이디를 알 수 있다. 그리고 단말기는 그 패킷 아이디에 해당하는 패킷이 전송 신호에 인캡슐레이션된 경우, 이를 디캡슐레이트하여 부트스트랩 정보를 얻을 수 있다.

이와 같이 서비스 가이드 정보는 방송 채널이나 인터액티브 채널을 통해 송수신될 수 있다. 어느 채널(예를 들면 방송 채널)로 전송된 서비스 가이드의 속성과 인터액티브 채널을 통해 서비스 가이드 정보를 제공하는 서버의 능력에 대해 설명하면 다음과 같다.

도 2a 내지 도 2b는 서비스 가이드 정보의 속성을 설명하기 위한 예시도이다.

어느 채널, 예를 들면 방송 채널을 통해 제공되는 서비스 가이드 정보의 속성에 따라 서비스 가이드 정보를 제공하는 서버의 능력(capability)이 결정될 수 있다. 그리고, 단말기는 방송 채널을 통해 수신되는 서비스 가이드 정보의 속성을 알 필요가 있다.

도 2a는 서비스 가이드 정보가 컴플리트(complete) 속성을 가지는 경우를 나타낸다. 서비스 가이드 정보가 컴플리트(complete) 속성을 가진다는 것은 단말기가 서버로부터 방송 채널을 통해 수신한 서비스 가이드 정보(A.B)가 서버에 저장된 서비스 가이드 정보(A.B)와 동일함을 의미한다. 따라서, 단말기가 컴플리트 속성에 따른 서비스 가이드 정보를 수신한 경우에는 단말기가 수신한 서비스 가이드 정보는 서버의 서비스 가이드 정보와 동일한 서비스 가이드 정보를 포함한다. 따라서, 단말기는 다른 채널(여기서는 인터액티브 채널)을 통해서 서비스 가이드 정보를 별도로 수신받을 필요가 없다.

반대로 서비스 가이드 정보가 인컴플리트(incomplete)한 속성을 가진다는 의미는 단말기가 어느 채널, 예를 들면 방송 채널로 수신한 서비스 가이드 정보가 서버의 서비스 가이드 정보보다 적은 정보(A 또는 B 중 어느 하나)를 포함하고 있음을 의미한다. 따라서, 단말기는 별도의 채널(여기서는 인터액티브 채널)을 통해 서비스 가이드 정보를 수신한다.

도 2b는 서비스 가이드 정보의 속성 중 컨시스턴트(consistent) 속성을 기술하기 위한 예시도이다.

서버로부터 어느 채널을 통해 단말기로 제공되는 서비스 가이드 정보는 도 1에 예시한 바와 같이 서로 연결된 구조를 가질 수 있다. 따라서, 서비스 가이드 정보의 제 1프래그먼트가 제 2 프래그먼트와 관련된다면, 서비스 가이드 정보는 제 1 프래그먼트와 제 2 프래그먼트 정보를 포함하고, 두 프래그먼트가 링크되어 있음을 나타내는 정보를 포함한다. 즉, 서비스 가이드 정보는 실제 정보를 포함하는 데이터와 데이터가 연결된 구조를 기술하는 정보를 포함할 수 있다.

단말기가 어느 채널을 통해 컨시스턴트(consistent) 속성을 가진 서비스 가이드 정보를 수신한다면, 단말기는 그 채널을 통해 서비스 가이드 정보에 대한 모든 연결 정보 또는 링크 정보를 제공받을 수 있다. 그러나, 단말기가 서비스 가이 드 정보의 모든 링크 정보를 수신한다고 하여도 실제 제공받는 서비스 가이드 정보 데이터도 수신하였는지 여부는 별개의 문제가 된다. 따라서, 어느 채널을 통해 단말기가 수신받은 서비스 가이드 정보의 속성이 컨시스턴트하다는 것은 단말기가 그 채널로부터 수신한 서비스 가이드 정보에 대한 링크 정보에 해당하는 데이터까지 모두 수신한 경우, 그 채널의 서비스 가이드 정보는 컨시스턴트(consistent)하다고 정의한다.

반대로 인컨시스턴트(inconsistent) 속성은 어느 채널을 통해 단말기로 수신된 서비스 가이드 정보의 연결 정보에 따른 데이터 중 일부가 없는 경우를 의미한다. 따라서, 단말기는 그 서비스 가이드 정보 데이터를 다른 채널(인터액티브 채널)을 통해 수신한다.

위에서 예시한 바와 같이 컴플리트 속성은 어느 채널을 통해 서버의 모든 서비스 정보가 제공되는지 여부를 나타내는 속성이고, 컨시스턴트 속성은 어느 채널을 통해 제공되는 서비스 가이드 정보에 포함되어야 할 모든 데이터가 구비되어 제공되는지 여부를 나타내는 속성이다. 따라서, 서비스 가이드 정보의 속성이 컴플리트(complete)하면 당연히 컨시스턴트(consistent)하지만, 서비스 가이드 정보의 속성이 컨시스턴트하다고 모두 컴플리트하지는 않다.

이하에서는 서비스 가이드 정보를 제공하는 서버의 능력에 대해 개시한다.

인터액티브 채널을 통해 서비스 가이드 정보를 제공하는 서버의 능력(capability)은 방송 채널을 통해 제공되는 서비스 가이드의 속성에 따라 결정될 수 있다. 예를 들어, 단말기가 방송 채널로부터 제공받는 서비스 가이드 정보의 속 성이 그 서비스 가이드 정보의 엔트리 정보에 포함될 경우, 단말기는 그 속성에 따라 인터액티브 채널을 통해 서비스 가이드 정보를 제공하는 서버에 접근해야 하는지 여부를 결정할 수 있다.

인터액티브 채널을 통해 서비스 가이드 정보를 제공하는 서버의 능력은 컴플리트(complete), 컴플리멘팅(complementing), 리페어(repair)가 있다. 도 3a 내지 도 3c는 서비스 가이드 정보를 제공하는 서버의 능력을 설명하기 위한 예시도이다.

도 3a는 서버의 능력이 컴플리트(complete)한 경우를 예시한다.

컴플리트는 서비스 가이드 정보를 제공하는 서버가 모든 서비스 가이드 정보를 어느 채널, 예를 들면 인터액티브 채널을 통해 제공할 수 있을 경우 서버의 능력을 의미한다. 따라서 단말기는 인터액티브 채널을 통해 컴플리트한 능력을 가지는 서버로부터 방송 채널로부터 수신할 수 있는 서비스 가이드 정보(A. B)를 모두 수신할 수 있다.

도 3b는 서버의 능력이 컴플리멘팅(complementing)한 경우를 예시한다.

컴플리멘팅(complementing)은 방송 채널을 통해 서비스 가이드 정보를 제수신한 단말기의 서비스 가이드 정보가 서버의 서비스 가이드 정보를 완전히 구비하지 못한 경우(A만 수신), 그 서비스 가이드 정보를 보완할 수 있는 능력을 가진 서버의 능력(B 제공 가능)을 의미한다. 따라서, 단말기가 A, B로 구성된 서비스 가이드 정보 중 A만을 방송 채널로부터 수신한 경우, 컴플리멘팅한 능력을 가진 서버로부터 인터액티브 채널을 통해 서비스 가이드 정보 B를 수신할 수 있다.

도 3c는 서버의 능력이 리페어(repair)인 경우를 예시한다.

리페어(repair)는 단말기가 방송 채널로부터 수신한 서비스 가이드 정보에 손실이 있는 경우, 인터액티브 채널로 그 손실 부분의 서비스 가이드 정보를 재전송할 수 있는 서버의 능력을 의미한다. 단말기가 A, B로 구성된 서비스 가이드 정보 중 A를 방송 채널로부터 정상적으로 수신하지 못하였을 경우, 리페어 능력을 가진 서버로부터 서비스 가이드 정보 A를 인터액티브 채널을 통해 재수신받을 수 있다.

단말기가 서비스 가이드 정보를 수신한 경우 수신한 서비스 가이드 정보를 컴플리트하게 하기 위해 단말기는 컴플리트 또는 컴플리멘팅한 능력을 가진 서버에 서비스 가이드 정보를 요청할 수 있다. 인터액티브 채널로 서비스 가이드 정보를 제공할 수 있는 서버가 다수 존재할 수 있다. 그리고 단말기가 서비스 가이드 정보를 수신하고자 하는 서버에 문제가 발생하여 그 서버로부터 서비스 가이드 정보가 정상적으로 제공받지 못할 경우 단말기는 다른 서버를 인터액티브 채널을 통해 접근하여 서비스 가이드 정보를 제공받을 수 있다. 이하의 실시예에서는 서비스 가이드 정보를 제공받을 수 있는 서버에 문제가 발생하여 전원이 다운되거나, 그 서버에 저장된 서비스 가이드 정보가 정상적이지 않은 손실이 있는 경우에도 단말기가다른 서버로부터 서비스 가이드 정보를 제공받을 수 있는 방안을 개시한다.

도 4는 단말기가 다수의 서버로부터 인터액티브 채널을 통해 서비스 가이드 정보를 수신할 수 있는 경우를 개념적으로 예시한다.

단말기가 부트스트랩 정보를 얻은 후 인터액티브 채널을 통해 서비스 가이드 정보를 수신할 경우 단말기는 먼저 부트스트랩 정보에 설정된 마스터 서버(master server)에 서비스 가이드 정보를 요청할 수 있다. 마스터 서버에 문제가 있어 단말기가 서버로부터 응답을 얻지 못하거나 서비스 가이드 정보를 얻지 못할 경우 단말기는 인터액티브 채널을 통해 다른 서버에 접근하여 서비스 가이드 정보를 얻는다. 이 경우 다른 서버는 슬레이브 서버로 호칭할 수 있다. 단말기는 다수의 서버 중 어느 하나의 마스터 서버로부터 우선적으로 서비스 가이드 정보를 수신받고, 그렇지 못할 경우 다른 서버에 서비스 가이드 정보를 수신할 수 있을지 여부를 문의한다. 이와 같은 마스터/슬레이브 서버로 서비스 가이드 정보를 수신하는 과정을 이하에서 마스터/슬레이브 메카니즘으로 호칭한다. 그리고, 다수의 서버가 있을 경우 단말기는 우선적으로 어느 서버가 마스터 서버인지, 즉 가장 먼저 접근해야 하는 서버인지 판단한다. 그리고, 단말기는 식별한 서버를 마스터 서버로 하여 서비스 가이드 정보를 수신한다.

인터액티브 채널을 통해 다수의 서버로부터 서비스 가이드 정보를 수신할 수 있는 경우, 위의 마스터/슬레이브 메카니즘을 이용하여 특정 서버로부터 서비스 가이드 정보를 수신하는 방안을 개시한다.

도 5는 서비스 가이드 정보에 대한 부트스트랩 정보로부터 인터액티브 채널을 통해 서비스 가이드 정보를 수신할 수 있는 마스터/슬레이브 서버에 대한 정보를 얻는 예를 개시한다.

도 5는 엔트리 정보 중 인터액티브 채널로부터 서비스 가이드 정보를 수신할 경우(AccessType = 0x02)를 나타낸다. 도 4에서 HaveBackupServer 필드는 서버로부터 인터액티브 채널을 통해 서비스 가이드 정보를 수신할 경우, 백업서버(backup server)가 존재하는지 여부를 나타내는 필드이다. 예를 들어 HaveBackupServer 필드가 0인 경우 백업 서버가 없음을, 1인 경우 백업서버가 존재함을 나타낸다. 도 5에서 예시한 부트스트랩 정보는 7비트의 미지정영역(reserved)을 가질 수 있다. HaveBackupServer 필드가 1인 경우 부트스트랩 정보는 마스터 서버(master server)와 슬레이브 서버(slave server) 메카니즘을 이용해 단말기가 인터액티브 채널을 통해 서비스 가이드 정보를 수신할 수 있는 서버에 대한 정보를 얻을 수 있다. 단말기가 인터액티브 채널을 통해 서비스 가이드 정보를 제공하는 다수의 서버가 있을 경우 단말기가 마스터 서버를 식별하는 예를 개시한다.

도 6은 단말기가 인터액티브 채널을 통해 서비스 가이드 정보를 수신할 경우 도 5와 같은 부트스트랩 정보로부터 서버에 대한 정보를 얻을 경우, 마스터 서버를 식별하는 예를 개시한다.

도 5에서 예시한 바와 같이, HaveBackupServer 필드가 1인 경우 부트스트랩 정보는 인터액티브 채널로부터 서비스 가이드 정보를 제공할 수 있는 서버의 개수를 나타내는 n_o_groupAccessPoints 필드를 포함할 수 있다. 서버의 개수(n_o_groupAccessPoints)에 따라 어느 하나의 서버가 마스터 서버임을 나타낼 수 있는데, 예를 들어 masterFlag가 1인 경우 마스터 서버이고, 0일 경우 슬레이브 서버로 설정할 수 있다. 단말기는 masterFlag 정보를 이용하여 다수의 서버 중 어느 하나를 마스터 서버로 식별할 수 있다.

그리고 도 6에 예시한 부트스트랩 정보는 7비트의 미지정영역(reserved) 영역 필드와 서버의 위치 정보의 길이인 URL_length 필드를 더 포함할 수 있다. 단말 기는 마스터 서버에 서비스 가이드 정보를 요청(request)하고, 그 응답에 따라 서비스 가이드 정보를 수신할 수 있다.

도 7 및 도 8은 클라이언트인 단말기와 서버가 서로 통신할 수 있는 메시지 형식으로서, HyperText Transfer Protocol(HTTP)형식을 예시한다. 단말기가 HTTP 형식에 따라 서버에 요청하는 형식인 request 메세지는 도 7에, 서버가 단말기의 요청에 대해 응답하는 형식인 response는 도 8에 각각 예시하였다.

HTTP는 어플리케이션 레이어(application layer) 상에서 구동되는 프로토콜 중 하나로서, 트랜스포트 레이어(transport layer)에서 구동되는 프로토콜인 TCP 를 기반으로 구동될 수 있는 신호 송수신 규약이다. HTTP는 클라이언트(예를 들어, 단말기에서 구동될 수 있는 브라우저)가 서버로부터 웹 페이지 등의 정보를 어떻게 요청하고, 서버가 그 요청에 어떻게 이에 응답하는지 여부를 기술할 수 있다.

도 7에서 request 메세지 형식의 request line는 서버에 요구하는 method, 요구하는 URI(Uniform Resource Identifier), HTTP 버전이 설정된다. request 메세지에는 각 오브젝트(object)가 위치한 호스트 서버의 어드레스, 서버와 연결시 속성, 유저 에이전트(user-agent) 등이 설정될 수 있는 헤더 라인을 포함한다. 헤더 라인은 general header, request header, entity header를 포함할 수 있다. 그리고, message-body는 단말기가 서버에 제공하는 search word 등의 단말기가 서버로 전송하는 내용에 따른 데이터인 메세지 바디가 설정될 수 있다.

도 8에서 response 메세지 형식의 status-line에는 HTTP 버전, 스테이터스 코드(status code) 리전 퍼레이즈(reason phrase)가 설정된다. response 메세지의 헤더 라인에는 general header, response header, entity header가 포함되고, message-body에 response 메세지의 내용에 포함된다.

서버는 도 7의 request 메세지를 단말기로부터 수신한 후 도 8에 예시한 형식에 따라 HTTP response 메세지를 전송하여 응답한다. status-line은

HTTP-version SP(space) status-code SP(space) reason-phrase

의 형식을 가지는데, status code는 request 메세지에 수신에 대한 상태 정보 코드를 포함한다. 상태 정보 코드의 예로서 1xx(여기서 xx는 IETF RFC 2616에서 규정하는 수를 따른다)는 request 수신 등에 대한 알림 정보를 나타내고, 2xx는 액션이 성공적으로 수신되었음을 나타낸다. 그리고, 3xx는 request를 완전하게 하기 위해 추가적인 액션이 수행되어야 함을 나타내고, 5xx는 서버가 외형적으로 유효한 request를 수신하여 이행하는데 실패했음을 나타낸다. 상세한 내용은 IETF RFC 2616을 참조한다.

도 7에 예시한 HTTP 메세지를 통해 단말기가 서버에 서비스 가이드 정보를 요청할 경우에는 HTTP 메세지는 HTTP 1.1의 POST method에 따를 수 있다. POST method에 따른 request 메세지는 message body에 일정한 형식의 데이터를 전송할 수 있는 점에서 message body에 어떤 데이터를 포함하지 않는 엠프티 바디(empty body)를 가지는 get method와 차별된다. request 메세지에 단말기는 다수 개의 key-value 쌍(pairs)들을 포함할 수 있는데, "type"으로 정의되는 key-value는 단말기가 서버에 서비스 가이드 정보를 요청할 경우에 사용된다. 예를 들어 단말기는 위에서 예시한 HTTP의 POST method 에 따라 request 메세지를 서버에 전송할 경우, 메세지에 "type" key-value를 message body에 설정하여 전송함으로써 그 서버가 제공할 수 있는 서비스 가이드 정보의 리스트 정보(delivery list 라고도 한다)나 서비스 가이드 정보의 컨테이터 등을 요청할 수 있다.

상세하게 예를 들면 단말기가 인터액티브 채널을 통해 서버에 서비스 가이드 정보의 컨테이너 리스트를 요청할 경우 위에서 개시한 request 메세지의 message body에, "type = Containerlist"를 설정할 수 있다. 단말기가 서비스 가이드 정보의 컨테이너를 요청할 경우에 request 메세지의 message body에, "type = ESGContainer"라고 설정하여 메세지를 전송할 수 있다. 단말기가 서비스 가이드 정보의 리스트 정보를 서버에 요청할 경우, request 메세지의 message body에, "type = ipdcindex"라고 설정하여 메세지를 전송할 수 있다.

만약 단말기가 메세지를 전송하는 서버에게 마스터 서버인지 여부를 request 메세지의 message body에, "type = MasterServer"라고 설정하여 송신하면, 그 메세지를 수신한 서버는 response message의 헤더 라인 중 response-header에 마스터 서버의 location을 설정하여 단말기에 응답할 수 있다. 따라서, 단말기는 그 response message로부터 마스터 서버의 위치 정보를 알 수 있다.

단말기가 마스터 서버를 식별하는 또 다른 예로서, 단말기가 인터액티브 채널을 통해 어떤 서버로부터 서비스 가이드 정보의 리스트 정보(delivery list)를 수신할 경우, 그 서버가 위의 리스트 정보에 마스터 서버의 위치 정보를 포함시키도록 할 수 있다.

예를 들어 서버가 단말기에 서비스 가이드 정보의 리스트 정보를 전송할 경 우 그 리스트 정보를 포함하는 파일(예를 들면 XML 파일 등)의 내용에 마스터 서버의 위치 정보가 포함되도록 할 수 있다.

예를 들어 서버가 단말기에 서비스 가이드 정보의 리스트 정보(delivery list)를 전송할 경우, 그 리스트 정보에 마스터 서버의 정보가 포함되도록 할 수 있다. 즉, 서버가 단말기에 리스트 정보를 전송할 경우, 그 리스트 정보에

와 같이 마스터 서버의 위치 정보를 설정할 수 있다. 여기서 AccessPoint는 단말기가 접속하는 서버의 위치 정보를 의미하고, 그 서버가 마스터인지 여부를 나타내는 플래그(masterFlag)의 논리 값이 참일 경우에 단말기는 그 위치 정보에 따른 서버를 마스터 서버로 식별한다. 따라서, 단말기는 위의 같이 설정된 리스트 정보로부터 마스터 서버의 위치를 인식할 수 있다. 이 예에서 마스터 서버의 위치 정보는 "http://bbc.co.kr/"이 된다.

도 9는 단말기가 마스터 서버를 식별하는 다른 예를 개시한다.

단말기가 부트 스트랩 정보로부터 인터액티브 채널을 통해 서비스 가이드 정보를 얻을 수 있다고 판단한 경우, 부트 스트랩 정보에 처음 설정된 서버의 어드레스 정보를 마스터 서버로 식별할 수 있다.

도 9는 부트 스트랩 정보 중 AccessType이 0x02 경우로서 인터액티브 채널을 통해 서비스 가이드 정보를 얻을 수 있는 AccessDescriptor를 예시한다. AccessType이 0x02 경우 위에서 예시한 바와 같이 서비스 가이드 정보를 수신할 수 있는 백업 서버가 있음을 나타내는 필드(HaveBackupServer)가 설정될 수 있다. 그 리고 만약 백업 서버가 있을 경우(HaveBackupServer = 1), 부트 스트랩 정보에는 서비스 가이드 정보를 수신할 수 있는 서버의 개수를 나타내는 필드(n_o_groupAccessPoints)가 설정되고, 그 서버의 개수(n_o_groupAccessPoints)에 따른 각 서버의 위치 정보(URLByte)를 포함한다. 도 9에서 URL_Length는 UTF-8 인코딩 등의 방식에 따른 캐랙터(character)의 개수, URLByte는 그 캐랙터(character) 개수에 따른 위치 정보로서 URL 정보가 설정될 수 있다. 단말기는 도 9와 같은 부트 스트랩 정보를 파싱할 경우 서버의 위치 정보 중 최초로 파싱되는 서버를 마스터 서버로 식별할 수 있다.

단말기는 위와 같은 방법으로 마스터 서버를 식별하고, 그 마스터 서버에 접근하여 서비스 가이드 정보를 수신한다. 만약 단말기가 마스터 서버로 접근할 경우타임아웃 메카니즘(timeout mechanism) 등을 이용하여 마스터 서버가 일정시간 응답하지 않을 경우 마스터 서버가 다운되었다고 판단할 수 있다. 또한 마스터 서버가 저장하는 서비스 가이드 정보가 손실된 경우 등도 단말기는 서비스 가이드 정보로부터 정상적인 서비스 가이드 정보를 수신하지 못한다. 이러한 경우 단말기에는 예를 들면 HTTP에 따른 메세지 형식에 따라 "500 Ineternal Server Error" 등의 상태 코드에 따른 값이 표출될 수 있다. 그리고, 단말기는 접속하고자 하는 마스터 서버 다음에 어떠한 서버를 접속해야 하는지 판단할 수 없는데, 이하에서는 단말기가 본래의 마스터 서버가 서비스 가이드 정보를 제공하지 못할 경우 슬레이브 서버 가 선택하는 방안을 기술한다.

단말기는 마스터 서버를 식별한 후 마스터 서버로부터 서비스 가이드 정보를 제공받지 못한 경우에는 슬레이브 서버를 식별할 수 있다. 예를 들어 도 9와 같이 단말기는 부트스트랩 정보를 파싱하여 인터액티브 채널로부터 서비스 가이드 정보를 수신할 수 있는 서버의 위치 정보를 얻을 경우, 파싱되는 서버의 위치 정보 중 두 번째 이후에 얻어지는 서버를 슬레이브 서버로 간주할 수 있다. 단말기는 마스터 서버로부터 정상적으로 서비스 가이드 정보를 수신하지 못하는 경우 얻은 슬레이브 서버에 접근하여 서비스 가이드 정보를 얻을 수 있다. 이 실시예에 따르면, 단말기는 서비스 가이드 정보를 정상적으로 얻을 때까지 순차적으로 얻어지는 슬레이브 서버들을 그 얻어진 순서에 따라 접근할 수 있다.

다음 예로서 서버가 단말기에 서비스 가이드 정보에 대한 리스트 정보를 송신할 경우, 그 리스트 정보에 인터액티브 채널로 통신 가능한 서버의 위치 정보와 우선 순위 정보가 포함되도록 할 수 있다.

예를 들어, 서버가 단말기에 리스트 정보를 전송할 경우 리스트 정보(여기서는 리스트 정보가 XML 파일 형태로 전송된다고 가정한다)에 다음과 같은 XML의 엘리먼트가 포함될 수 있다고 가정할 수 있다.

따라서, 서버는 단말기가 접속 가능한 서버의 위치 정보 및 우선 순위 정보를 리스트 정보에 설정하여 전송할 수 있다. 여기서 AccessPoint ref는 단말기가 접속할 수 있는 서버의 위치 정보를 나타내는 엘리먼트이고, priority는 그 서버들 의 우선순위를 나타낸다. 단말기는 리스트 정보로 전송되는 접속 가능한 서버 정보를 이용하여 그 우선 순위에 따라 슬레이브 서버에 접속할 수 있다. 따라서, 단말기는 위의 같이 설정된 리스트 정보로 마스터 서버의 위치를 인식할 수 있다.

만약 마스터 서버가 다운된 경우가 아니지만, 저장한 서비스 가이드 정보가 손실되는 등 서비스 가이드 정보를 단말기에 정상적으로 제공하지 못할 경우, 단말기의 슬레이브 서버에 이를 알려줄 수 있다. 이 경우 단말기가 마스터 서버에 서비스 가이드 정보를 요청하면, 마스터 서버는 그 요청에 대한 응답으로서 슬레이브 서버의 위치를 단말기에 전송한다. 본 실시예를 구체적으로 실행할 수 있는 하나의 예로서 HyperText Transfer Protocol(HTTP)를 사용할 수 있다. 마스터 서버와 단말기는 HTTP 형식의 메세지를 주고 받을 수 있다. 단말기가 마스터 서버에 HTTP 에 따른 메세지를 이용해 서비스 가이드 정보를 요청(request)하면, 마스터 서버는 HTTP 메세지를 이용해 슬레이브 서버의 위치 정보를 단말기의 요청에 대한 응답(response)을 전송할 수 있다. 이 경우 마스터 서버는 HTTP response 메세지의 header line에 content location 필드를 사용하여 슬레이브 서버의 위치 정보를 전송할 수 있다. HTTP response 메세지의 status-code 중 3xx(xx는 HTTP에 따른 status code에 따른 값)는 다른 서버의 URI로 단말기를 리다이렉트(redirect)시킨다. 따라서, 단말기는 HTTP 에 따른 response 메세지로부터 슬레이브 서버의 위치 정보를 얻어 슬레이브 서버에 접근하고 서비스 가이드 정보를 얻을 수 있다. 반면에 슬레이브 서버가 없거나 마스터 서버가 알지 못한다면, 본래의 마스터 서버는 단말기에 status-code 503에 따라 "service unavialable"메세지를 전송할 수 있다.

도 10은 서비스 가이드 정보를 전송하는 송신 장치의 일 실시예를 도시한 도면이다. 도 10를 참조하여 서비스 가이드 정보 송신 장치의 일 실시예를 설명하면 다음과 같다. 도 10 예에서 서비스 가이드 정보는 방송 서비스를 통해 전송된다고 가정한다.

도 10에 개시한 방송 송신 시스템은 인코딩부(310, 320, 330), 다중화부(340) 및 변조부(350)를 포함한다. 인코딩부는 제 1 인코딩부(310), 제 2 인코딩부(320) 및 제 3 인코딩부(330)를 포함한다.

제 1 인코딩부(310)는 오디오, 비디오 및 데이터에 따른 콘텐츠를, 예를 들어 엠펙-2의 트랜스포트 스트림 등의 송수신 프로토콜에 따라 인코딩할 수 있다.

제 2 인코딩부(320)는 IP 데이터그램(datagram) 형식으로 서비스 가이드 정보를 포함하는 데이터를 인코딩할 수 있다. IP 데이터 그램은 인터넷 프로토콜(internet protocol)에 의한 패킷으로 신호를 보내는 신호처리형식을 일컫는데, IP 주소를 포함하는 헤더와 정보를 전송하는 데이터 컨테이너(data container)를 포함한다. 패킷 단위의 IP 데이터 그램 중 데이터 컨테이너(data container)에는 비디오, 오디오 및 서비스 가이드 정보의 데이터가 포함될 수도 있다. 즉, 도 10의 예는 비디오 신호, 오디오 신호 및 데이터 신호를 패킷 단위로 나누어 압축한 뒤 전송하는 IP 데이터캐스팅(internet protocol datacasting) 방식을 수행하여 정보를 송신할 수 있다. IP 데이터는 MPE(multi-protocol encapsulation)로 인캡슐레이션 된 후 MPEG-2 TS(trasnport stream)에 임베드(embed)될 수 있다. MPE는 순방향 에러 정정 코드(FEC)가 추가된 MPE-FEC (multi protocol encapsulation - forward error correction) 섹션 데이터가 될 수 있다. MPE-FEC 방식에 의해 송신 신호를 배치하면 송신 신호의 캐리어 대 노이즈(carrier-to-noise; CN) 비를 향상시킬 수 있다. FEC가 포함된 MPE-FEC 데이터나, 또는 FEC가 포함되지 않은 MPE 데이터는 IP 데이터 형식의 송신 데이터를 포함될 수 있다.

제 2 인코딩부(320)는 서비스 가이드 정보를 IP 데이터 그램 형식으로 인코딩할 수 있다. 제 2 인코딩부(320)는 서비스 가이드 정보가 포함된 IP 데이터 그램을 MPE로 인캡슐레이션한 후 이를 소비 전력 절감을 위해 타임 슬라이싱(time slicing) 기법으로 멀티플레싱(multiplexing)할 수 있다. 멀티플렉싱된 신호는 트랜스포트 스트림(transport stream)으로 변환되어 비디오 또는 오디오 신호가 실린 엠펙-2 트랜스포트 스트림 패킷과 다중화될 수 있다.

제 3 인코딩부(330)는 제 1 인코딩부(310) 또는 제 2 인코딩부가 인코딩한 패킷들, 예를 들어 프로그램이나 서비스에 관련된 스트림 패킷들의 다중화 정보를 인코딩할 수 있다. 다중화 정보는 PSI/SI(Program Specific Information/Service Information)에 대한 테이블 정보를 포함한다. 제 3 인코딩부(330)가 인코딩하는 테이블 정보는 제 2 인코딩부(320)가 인코딩하는 IP 어드레스와 IP 데이터그램을 포함하는 패킷 아이디(PID)의 매핑 정보를 포함하는 INT(IP/MAC Notification table)를 포함할 수 있다. 따라서, 제 3 인코딩부(330)는 부트스트랩 정보에 대한 IP 어드레스 정보를 포함하는 INT 정보를 인코딩하여 전송할 수 있다. 제 3 인코딩부(330)가 인코딩하는 부트스트랩 정보는 서비스 가이드 정보를 제공하는 서버가 중 마스터 서버인지 여부에 대한 정보(위의 예에 따르면 masterFlag)를 포함할 수 있다. 그리고, 마스터 서버에 대한 위치 정보(URLByte)를 포함할 수 있다.

다중화부(340)는 제 1 인코딩부(310), 제 2 인코딩부(320), 제 3 인코딩부(330)가 출력하는 트랜스포트 패킷을 각각 다중화하여 출력하고, 변조및부호화부(350)는 다중화된 신호를 변조하고 부호화하여 전송할 수 있다.

다중화부(340)가 제 1 인코딩부(310), 제 2 인코딩부(320), 제 3 인코딩부(330)이 인코딩한 패킷 데이터를 다중화하여 출력하면 변조및부호화부(350)는 다중화된 신호를 전송 시스템에 따른 변조및부호화부(350)에 따라 변조하고 부호화시킨 후 RF(radio frequency) 신호로 전송할 수 있다. 변조및부호화부(350)는 다양한 방송 시스템의 변조 방식 및 부호화 방식을 따를 수 있는데, 예를 들면 DMB 방식, DVB-H 방식, VSB 변조 방식에 따른 ATSC 방식 및 ISDB-T 방식 등의 전송 방식이 사용될 수 있다.

도 11은 도 10에서 개시한 변조및부호화부를 예시한 도면이다. 도 10에서 변조 및 부호화 방식은 예를 들면 DVB-T/H(digital video broadcasting - terrestial/handheld) 방식을 따를 수 있다.

제 1 부호화부(410)는 아웃터 코더(outer coder)(411)와 아웃터 인터리버(outer interleaver)(412)를 포함한다. 제 1 부호화부(410)는 다중화된 신호에 대한 송신 성능을 향상시키기 위해 각각 다중화된 데이터를 부호화하고 인터리빙할 수 있다. 예를 들어 아웃터 코딩 방식으로 리드-솔로몬 부호(Reed-Solomon code)화 방법을 사용할 수 있고, 인터리빙 방식으로는 컨볼루션 인터리빙(convolution interleaving) 방식이 수행될 수 있다.

제 2 부호화부(420)는 인너 코더(inner coder)(421)와 인너 인터리버(inner interleaver)(422)를 포함한다. 인너 코더(inner coder)(421)와 인너 인터리버(inner interleaver)(422)는 송신 신호에 에러 발생을 대비하여 송신할 신호를 다시 부호화하여 인터리빙을 수행한다. 인너 코더(inner coder)는 펑처드 컨볼루션 코드(punctured convolution code)에 따라 송신 신호를 부호화할 수 있고, 인너 인터리빙(inner-interleaving) 방식은 2k, 4k 및 8k의 전송 모드에 따른 메모리 사용에 따라 네이트브(native) 또는 인-뎁스(in-depth) 인터리빙 방식이 사용될 수 있다.

매퍼(mapper)(430)는 시스템신호생성부(425)가 생성하는 전송 모드에 따른 파일럿 신호와 TPS(transmission parameter signalling; 전송 매개 변수 신호)를 고려하여, 송신 신호를 16QAM, 64QAM, QPSK 등의 방식에 따라 심볼로 매핑할 수 있다.

프레임형성부(440)는 매핑된 신호를 OFDM(orthogonal frequency division multiplex) 방식으로 변조하고, 변조된 신호를 포함한 데이터 구간에 보호구간이 삽입된 프레임을 형성한다. 각 프레임은 68개의 OFDM 심볼을 포함하고, 4개의 프레임은 수퍼 프레임을 형성한다. 예를 들어 전송 모드인 8k 모드에서는 하나의 심볼이 6817 캐리어를, 2k 모드에서는 1705 캐리어를 포함한다. 보호구간은 데이터구간의 데이터를 복사한 사이클릭 컨티뉴에이션(cyclic continuation)으로서, 전송 모드에 따라 길이가 달라진다. OFDM 프레임은 각각 분산 파일럿 신호, 연속 파일럿 신호 및 TPS 캐리어를 포함한다. 도 11의 프레임형성부에 의한 신호 프레임의 예는 도 12에서 개시한다.

디지털아날로그변환부(450)는 보호 구간과 데이터 구간을 가진 디지털 형식의 방송 신호를 아날로그 신호로 변환하고, 전송부(460)는 디지털아날로그변환부(450)에서 변환된 아날로그 신호를 RF(radio frequency) 신호로 송신할 수 있다. 따라서, 인코딩된 서비스 가이드 정보는 도 10의 송신 장치의 예에 따라 방송 채널을 통해 전송될 수 있다.

도 12는 도 11의 예 중 프레임형성부가 프레임을 형성한 결과에 따른 신호 배치를 예시한 도면이다. 도 12에서 Tu는 사용가능한 부반송파의 수를 나타내고, Dt는 시간축상에서 분산 파일럿간의 거리를, Df는 주파수 축상에서 분산 파일럿간의 거리를 각각 나타낸다. 주파수 영역에서 분산 파일럿간의 거리(Df)는 채널에서 추정 가능한 고스트의 지연범위를 결정한다. 도 12는 프레임형성부에서 형성한 신호를 수신시에 보간할 파일럿의 위치까지 표시한다.

따라서 이렇게 배치된 신호를 수신할 경우에 파일럿 위치에서 시간 보간을 수행하여 입력되는 심볼 4개마다 같은 파일럿 패턴이 나타나도록 심볼을 배치한다. 즉, 처음 입력되는 심볼(t=1)은 t=5에 입력된 심볼과 동일한 분산 파일럿 신호를 배치하면 신호를 수신하는 단말기는 분산 파일럿 신호의 위치에서 t=2, 3, 4에 수신된 심볼에 대한 시간 보간을 수행할 수 있다.

또한, t=6에서 입력된 심볼은 t=2에서 입력된 심볼과 동일한 분산 파일럿 패턴을 가지므로, 신호를 수신하는 단말기는 t=6에서 입력된 심볼과 t=2에서 입력된 심볼의 분산 파일럿 위치상에서 t=3, 4, 5의 신호들에 대해 시간 보간을 수행할 수 있다.

그리고, 신호 수신시 t= 7에서 심볼이 입력된 후 위와 같이 방식으로 시간 보간되면, t=4에 입력된 심볼은 4개 부반송파 위치마다 분산 파일럿들이 위치하므로, t=4의 입력된 심볼의 주파수 영역에서 분산 파일럿 신호들 사이의 간격은 본래 분산 파일럿 신호들 사이의 간격의 1/4로 줄어들고, t=4 에서 입력된 심볼은 4개의 부반송파 위치마다 분산 파일럿 신호가 위치하는 패턴을 갖도록 한다. 따라서, 신호를 수신하는 단말기는 더 많은 파일럿 신호가 심볼에 위치한 것처럼 신호를 처리할 수 있는 효과를 얻을 수 있다. 따라서, 이와 같이 연속 파일럿 신호와 분산 파일럿 신호를 이용하여 신호를 전송하면, 그 신호 수신시에 수신 채널의 상태에 따라 적응적으로 채널 보상을 할 수 있다.

도 13은 방송 프로그램, 콘텐츠 및 데이터 등이 채널로 전송되는 예를 나타낸 도면이다. 도 10 및 도 11에 개시한 송신 장치에 따라 DVB-H로 타입 슬라이싱 기법이 적용된 서비스와, DVB-T와 DVB-H의 공동 채널로 전송되는 서비스가 전송될 수 있다. 각각의 DVB-H와 DVB-T의 채널에 따라 프로그램이 전송될 수 있고, DVB-H에 의할 경우 각 서비스가 타임 슬라이싱에 의해 시간 분할 다중화되어 전송될 수 있다. 비디오/오디오를 포함하는 콘텐츠 및 서비스 가이드 정보는 DVB-H 시스템에 의한 IP 데이터 그램에 포함되어 MPE 또는 MPE-FEC로 변형되고 변형된 MPE 또는 MPE-FEC가 임베드된 MPEG-2 TS로 전송될 수 있다.

도 14 및 도 15는 서비스 가이드 정보를 수신하는 수신 장치를 예시한 도면이다. 도 14 및 도 15를 참조하여 서비스 가이드 정보 수신 장치를 예시하면 다음 과 같다. 서비스 가이드 정보를 수신하는 장치는 수신부, 입력부(530), 저장부(550), 표출부(560) 및 제어부(600)를 포함한다. 수신부는 방송 채널로부터 신호를 수신하는 방송수신부(510) 및 인터액티브 채널로부터 신호를 수신하고 인터액티브 채널로 신호를 송수신하는 통신부(520)를 포함할 수 있다. 예를 들어 통신부(520)가 인터액션(interaction)하는 채널은 양방향으로 데이터 통신이 가능한 유무선 채널일 수 있다.

방송수신부(510)는 방송 신호를 수신하고 복조하여 출력한다. 예를 들면, 방송수신부(510)는 DVB-H 방식으로 수신한 방송 신호를 선택하는 튜너 및 DVB-H형식의 방송 신호를 OFDM 방식에 따라 복조하는 복조부를 포함할 수 있다. 방송수신부(510)는 수신한 방송 신호를 복조하여 제어부(600)로 출력한다. 방송수신부(510)가 수신한 방송 신호는 서비스 가이드 정보 또는 서비스 가이드 정보의 부트스트랩 정보를 포함한다.

통신부(520)는 양방향 통신이 가능한 인터액티브 채널을 통해 신호를 송수신할 수 있다. 통신부(520)는 인터액티브 채널을 통해 신호를 수신할 경우 수신한 신호를 통신 시스템의 변조 방식을 고려하여 복조하고, 통신시스템복부호부(670)가 부호화된 신호를 출력하면 전송하고자 하는 통신 시스템의 변조 방식에 따라 출력된 신호를 변조하여 전송할 수 있다. 예를 들어 통신부(520)는 인터액티브 채널을 통해 서비스 가이드 정보를 서버로부터 수신하고자 할 경우, 그 서버에 접근하도록 신호를 출력하고, 서버가 전송하는 서비스 가이드 정보를 수신할 수 있다.

제어부(600)는 시스템복호부(610), 디코더(620), 서비스가이드정보제어 부(630), 통신시스템복부호부(670)를 포함할 수 있다. 제어부(600)는 도 14에 예시한 주위의 기능블록, 예를 들면 수신부, 입력부(530), 저장부(550), 표출부(560) 등을 제어하고 사용자로부터 수신된 제어 명령을 처리할 수 있다.

시스템복호부(610)는 방송 수신부가 방송 채널을 통해 수신한 신호의 송수신 시스템의 부호화 방식을 고려하여 수신한 신호를 복호할 수 있다. 방송수신부(510)가 방송 신호를 복조하여 출력하면, 시스템복호부(610)는 출력된 신호를 복호하여 서비스 가이드 정보가 포함된 파일을 얻을 수 있다. 시스템복호부(610)의 상세한 예는 도 15에서 상술한다.

제어부(600)는 인터액티브(interactive) 채널과 송수신할 수 있도록 통신시스템복부호부(670)를 포함할 수 있다. 통신시스템복부호부(670)는 인터액티브 채널로 전송하고자 하는 신호를 부호화하거나 통신부(520)로부터 인터액티브 채널로부터 수신한 신호를 복호할 수 있다. 예를 들어 통신부(520)가 인터액티브 채널로부터 서비스 가이드 정보를 포함한 신호를 수신하고 이를 복조하여 출력한 경우, 통신시스템복부호부(670)는 그 신호를 복호하여 서비스 가이드 정보 및 그에 관련된 신호를 서비스가이드정보제어부(630) 또는 디코더(620)로 출력할 수 있다. 통신시스템복부호부(670)는 IP 데이터 그램 형식의 신호를 부호화하거나 복호할 수 있다. 예를 들어 통신시스템복부호부(670)는 통신부(520)가 복조한 신호를 수신하고, IP 데이터그램 형식의 복호하여 출력하거나, IP 데이터 그램의 형식의 신호를 부호화하여 통신부(620)로 출력할 수 있다. 예를 들어 서비스 가이드정보 수신 장치가 인터액티브 채널로부터 HTTP 프로토콜에 따른 메세지를 포함하는 신호를 수신하면. 통신시스템복부호후(670)는 그 메세지를 복호하고, HTTP 프로토콜에 따른 메세지를 IP 데이터 그램으로 부호화하여 통신부(520)로 출력할 수 있다. 통신시스템복부호부(670)는 어떤 서버가 마스터 서버인지 여부를 HTTP의 request 메세지에 출력할 수 있다. 그리고, 통신부(520)가 마스터 서버로부터 HTTP에 따른 response 메세지를 수신할 경우, 통신시스템복부호후(670)는 그 HTTP 메세지의 location 필드에 포함된 마스터 서버의 위치 정보를 복호할 수 있다. 통신부(520)가 서버로부터 서비스 가이드 정보의 리스트 정보를 수신하고 그 리스트 정보가 HTTP response 메세지에 따라 수신될 경우, 통신시스템복부호후(670)는 그 HTTP response 메세지를 복호하여 마스터 서버의 위치 정보(AccessPoint ref), 그 메세지를 포함하는 서버가 마스터 서버인지 여부를 나타내는 정보(masterFlag)를 출력할 수 있다. 그리고, 통신시스템복부호후(670)는 위의 리스트 정보에 포함된 슬레이브 서버의 위치를 나타내는 정보(AccessPoint ref) 및 우선 순위 정보(priority)를 출력할 수 있다.

디코더(620)는 시스템복호부(610), 통신시스템복호부(670)가 시스템에 따라 복호한 비디오, 오디오 및 데이터 정보를 각각 디코딩할 수 있다. 디코더(620)는 비디오 복호부, 오디오 복호부 및 데이터 복호부를 포함할 수 있다. 비디오 복호부는 예를 들어 H.264 형식의 비디오 데이터를 복호하여 출력할 수 있고, 오디오 복호부는 예를 들면 AC-3, AAC+ 형식 등의 오디오 데이터를 복호할 수 있다. 또한, 디코더(620)는 PSI/SI에 따른 테이블 형식의 프로그램 정보/서비스정보를 복호할 수 있는 데이터복호부(미도시)를 포함할 수 있다. 예를 들면 디코더(620)는 시스템복호부(610)가 복호한 신호로부터 PAT(program associate table), PMT(program map table), NIT(network information table) 등의 테이블 정보에 따른 신호를 복호하거나, 데이터 방송에 따른 방송 신호를 복호할 수 있다. 디코더(620)는 PMT로부터 테이블 정보인 INT(IP/MAC Notification table)을 파싱할 수 있다. INT는 트랜스포트 스트림내에 IP 스트림의 IP 어드레스와 트랜스포트 스트림의 PID간의 매핑 정보를 포함한다. 디코더(620)가 INT를 파싱하여 서비스 가이드 정보의 부트스트랩 정보로부터 IP 어드레스를 얻은 경우, 이를 서비스가이드정보제어부(630)로 출력되도록 할 수 있다. 따라서, 서비스 가이드 수신 장치는 그 IP 어드레스를 이용하여 서비스 가이드 정보를 방송 채널 또는 인터액티브 채널로부터 얻을 수 있다. 이 경우 디코더(620)가 파싱하는 부트스트랩 정보의 예는 도 5 및 도 6에서 예시하였다. 예를 들어 방송 채널로 수신된 부트스트랩 정보는 인터액티브 채널로 연결된 서버 중 어떤 서버가 마스터 서버인지 여부와 그 마스터 서버의 위치 정보를 포함할 수 있다.

서비스가이드정보제어부(630)는 시스템복호부(610) 또는 통신시스템복부호부(620)가 복호한 부트스트랩 정보를 수신하고, 그 부트스트랩 정보를 이용하여 서비스 가이드 정보 수신 장치가 서비스 가이드 정보가 수신되도록 할 수 있다. 예를 들어 서비스가이드정보제어부(630)는 시스템복호부(610)가 수신한 부트스트랩 정보에 따라 시스템복호부(610)가 방송 채널로부터 서비스 가이드 정보를 수신하도록 하거나 통신시스템복부호부(670)가 인터액티브 채널로부터 서비스 가이드 정보를 수신하도록 제어할 수 있다.

서비스가이드정보제어부(630)는 컨트롤러(613), 채널맵저장부(633), 브라우 저구동부(635)를 포함할 수 있다. 컨트롤러(631)는 서비스 가이드 정보로부터 채널 맵 정보를 추출하여 채널맵저장부(633)에 저장할 수 있다. 그리고, 컨트롤러(631)는 세션을 제어하고, 어플리케이션 등을 구동시키는 브라우저구동부(browser)(635)를 제어하여 수신되거나 저장된 서비스 가이드 정보가 표출되도록 할 수 있다.

서비스 가이드 정보 수신 장치는 수신한 서비스 가이드 정보를 저장부(550)에 저장할 수 있다. 저장부(550)는 서비스 가이드 정보, IP 데이터 그램으로 전송된 파일, 콘텐츠 데이터를 저장할 수 있고, 디코더(620)가 복호하기 전후의 데이터를 저장할 수도 있다. 입력부(530)는 사용자가 입력하는 제어 명령을 수신하여 이를 제어부(600)로 출력할 수 있다. 표출부(560)는 제어부(600)가 출력하는 오디오 또는 비디오 신호를 출력할 수 있다. 그리고, 서비스가이드정보제어부(630)가 구동하는 어플리케이션은 표출부(560)를 통해 서비스 가이드 정보를 영상과 소리로 출력시킬 수 있다. 따라서, 서비스 가이드 정보에 대한 어플리케이션을 통해 사용자는 파일을 다운로드 받거나 웹 서비스를 제공받거나 서비스 가이드 정보를 제공받을 수 있다.

도 15는 시스템복호부(610)를 상세하게 예시한 도면이다.

시스템복호부(610)는 방송수신부(510)가 복조한 방송 신호를 부호화한 시스템의 부호화를 고려하여 복호할 수 있다. 시스템복호부(610)는 방송수신부(510)가 복조한 서비스 가이드 정보를 아래와 같이 처리할 수 있다.

시스템복호부(610)는 IP 디캡슐레이터(decapsulator)(611), UDP(user datagram protocol) 복호부(612), RTP 복호부(613), FLUTE(File Delivery over Unidirectional Transport Protocol) 복호부(614), 컨테이너파서(container parser)(615), 빔파서(BiM parser)(616) 및 XML파서(617)을 포함할 수 있다.

시스템복호부(610)는 실시간으로 전송되는 콘텐츠 데이터를 시스템 부호화를 고려하여 복호할 수 있다. 예를 들어, 시스템복호부(610)는 IP 데이터그램 형식으로 전송되는 콘텐츠 데이터, 서비스 가이드 정보가 포함된 파일을 복호할 수 있다.

시스템복호부(610)가 IP 데이터그램 형식의 콘텐츠 데이터나 서비스 가이드 정보를 복호하는 예를 다음과 같다. 먼저 콘텐츠 데이터에 대해 IP 디캡슐레이터(decapsulator)(611)는 IP 패킷의 헤더를 참조하여 IP 패킷의 패이로드에 포함된 콘텐츠 데이터를 디캡슐레이트(decapsulate)한다. UDP(user datagram protocol) 복호부(612)는 IP 디캡슐레이트된 패이로드로부터 실시간으로 전송되는 콘텐츠 데이터를 유저 데이터 그램 프로토콜(UDP)에 따라 복호할 수 있다. RTP복호부(613)는 UDP(user datagram protocol)복호부(612)가 복호한 콘텐츠 데이터를 RTCP(RTP control protocol)에 의해 부호화 속도가 제어되도록 부호화된 콘텐츠 데이터를 출력할 수 있다. RTP복호부(613)로부터 출력된 콘텐츠의 오디오/비디오 신호는 각각 오디오 디코더와 비디오 디코더를 포함하는 디코더(620)로 출력한다.

시스템복호부(610)가 파일 형식의 서비스 가이드 정보에 대한 데이터를 복호할 경우, UDP복호부(612)가 복호한 데이터는 FLUTE복호후(614)로 출력된다.

FLUTE복호부(614)는 FLUTE(IETF RFC3926: File Delivery over Unidirectional Transport) 형식의 데이터를 복호하여, 예를 들면 바이너리 데이터, 이미지 데이터 및 텍스트 등의 파일을 출력할 수 있다. FLUTE복호부(614)가 복호하여 출력하는 데이터는 서비스 가이드 정보가 포함된 파일을 포함할 수 있다.

컨테이너파서(container parser)(615)는 서비스 가이드 정보 중 컨테이너 단위의 파일을 복호하여 프래그먼트 단위의 정보를 출력한다. 컨테이터파서(615)가 출력한 결과에 따라 서비스 가이드 정보가 빔(BiM) 형식으로 출력될 경우 빔(BiM) 파서(616)는 BiM 형식에 따른 데이터를 복호하여 XML파서(617)로 전송한다. XML파서(617)는 컨테이너파서(container parser)(615)나 BiM파서(616)가 출력하는 XML 형식의 파일을 복호할 수 있다.

만약 통신시스템복부호부(670)가 수신 신호를 복호하여 서비스 가이드 정보를 표출할 경우에, 통신시스템복부호부(670)는 IP 데이터 그램 내에 HTTP 등의 프로토콜에 따라 전송되는 서비스 가이드 정보 파일(예를 들면 XML 파일)을 복호할 수 있다.

도 16은 단말기에 서비스 가이드 정보 또는 서비스 가이드 정보의 부트스트랩 정보가 전달될 경우 따르는 프로토콜 스택(protocol stack)의 예를 개시한다. 도 16에서 왼쪽은 방송 네트워크에 따른 프로토콜 스택이고, 오른쪽은 인터액티브 네트워크에 따른 프로토콜 스택이다.

먼저 방송 네트워크에 따른 프로토콜을 설명하면 다음과 같다.

예를 들어 DVB-T/H 형식에 따라 서비스 가이드 정보가 전달되면 전달된 신호는 MPEG-2 TS(트랜스포트 스트림)에 관련된 프로토콜을 따른다.

트랜스포트 스트림은 타임 슬라이싱 규칙을 따를 수 있고, 트랜스포트 스트림을 복호하면 MPE(multiprotocol encapsulation) 또는 MPE-FEC(multiprotocol encapsulation - forward error correction) 형식에 따른 신호가 될 수 있다. 트랜스포트 스트림에는 PSI/SI에 따른 정보가 전달될 수도 있다.

트랜스포트 스트림에는 IP 데이터 그램의 형식에 따른 신호가 존재한다. 그리고, IP 데이터 그램에 따른 데이터는 UDP 또는 TCP의 규약에 따른다. UDP로 전달되는 콘텐츠 중 실시간 스트리밍 형태로 송수신되는 콘텐츠는 RTP 형식에 따를 수 있고, 파일 형태로 전달되는 콘텐츠는 FLUTE/ALC 형식에 따를 수 있다. RTP에 따른 스트리밍 형태의 콘텐츠는 H.264/AAC+에 따라 부호화되어 전송될 수 있다. 한편 파일 형태로 전달되는 콘텐츠는 XML(eXtensible Markup Language), 바이너리, 텍스트 등에 따른 데이터가 되거나, XML, SDP(Session Description Protocol) 등에 따른 서비스 가이드 정보가 있을 수 있다. XML(eXtensible Markup Language)은 객체 지향 언어로서, 서비스 가이드 정보는 FLUTE를 통해 객체 단위로 포함되어 전송될 수 있다.

인터액티브 채널을 통해 서비스 가이드 정보가 수신될 경우, 인터액티브 채널을 통해 수신되는 신호의 물리 계층 및 데이터 링크 계층은 통신 시스템에 따른 방식이 사용될 수 있다. 도 16의 예는 GSM(Global System for Mobile Telecommunication), GPRS(general packet radio service), UMTS(Universal Mobile Telecommunications System) 등의 통신 시스템을 예시한다.

IP 데이터 그램에 따른 프로토콜 형식 중 UDP 형식에 따라 전송된 서비스 가이드 정보는 HTTP 에 따라 파일로 수신될 수 있고. 비디오/오디오 등의 멀티미디어 서비스는 RTP 에 따라 표출될 수 있다. 참고로, 통신 시스템에 따른 음성 서비스나 문자 서비스는 각각 그에 따른 프로토콜 스택(도 16에서는 SMS, Voice로 표시)으로 데이터 링크 계층상에 위치할 수 있다.

도 17은 본 발명에 따른 서비스 가이드 정보 수신 방법의 실시예를 나타낸 도면이다. 도 17을 참조하여 본 발명에 따른 서비스 가이드 정보 수신 방법의 실시예를 설명하면 다음과 같다.

인터액티브 채널로부터 서비스 가이드 정보를 수신할 수 있는 다수의 서버 중 마스터 서버의 위치 정보를 얻는다(S110).

마스터 서버의 위치 정보는 예를 들면 방송 채널로부터 수신되는 부트스트랩 정보로부터 파싱될 수 있다. 부트스트랩 정보로부터 파싱될 경우 마스터 서버는 그 부트스트랩 정보로부터 가장 먼저 파싱되는 서버의 위치를 마스터 서버의 위치로 하거나 별도의 URL 정보 등의 위치 정보를 그 부트스트랩 정보로부터 얻을 수 있다. 또는 인터액티브 채널을 통해 위의 다수의 서버 중 어느 서버가 마스터 서버인지 HTTP 메세지 등으로 요청하고, 그 메세지의 response 메세지의 헤더 중 location 필드로부터 마스터 서버의 위치 정보를 얻거나, response 메세지의 메세지 바디로부터 마스터 서버의 위치 정보를 얻을 수 있다.

마스터 서버로부터 서비스 가이드 정보를 수신할 수 있는지 여부를 판단한다(S120). 마스터 서버가 다운되거나 그 서버에 저장된 서비스 가이드 정보가 손실되어 서비스 가이드 정보를 수신하지 못하는 경우(S120 no) 슬레이브 서버로부터 서비스 가이드 정보를 요청한다(S125). 그 예로서 S110 단계에서 위의 부트스트랩 정보로부터 마스터 서버를 얻었다면 그 부트스트랩 정보로부터 마스터 서버 다음에 얻는 서버의 위치 정보에 위치한 서버에 서비스 가이드 정보를 요청할 수 있다. 또는 만약 S110 단계에서 서버에 요청한 메세지에 대한 response 메세지의 헤더의 location 필드로부터 슬레이브 서버의 위치로 리다이렉트(redirect)하여 슬레이브 서버로부터 서비스 가이드 정보를 요청할 수 있다. 또는 S110 단계에서 서버에 요청한 메세지에 대한 response 메세지의 바디에 포함된 슬레이브 서버의 위치와 그 우선 순위에 따라 얻은 슬레이브 서버에 서비스 가이드 정보를 요청할 수 있다.

마스터 서버로부터 정상적으로 서비스 가이드 정보를 얻거나, S125에 따라 슬레이브 서버로부터 서비스 가이드 정보를 수신한다(S130)

도 1은 서비스 가이드 정보에 대한 예를 나타낸 도면

도 2a 내지 도 2b는 서비스 가이드 정보의 속성을 설명하기 위한 예시도

도 3a 내지 도 3c는 서비스 가이드 정보를 제공하는 서버의 능력을 설명하기 위한 예시도

도 4는 단말기가 다수의 서버로부터 인터액티브 채널을 통해 서비스 가이드 정보를 수신할 수 있는 개념도

도 5는 인터액티브 채널을 통해 서비스 가이드 정보를 수신할 경우 마스터/슬레이브 서버의 기능을 제공하는지 나타내는 부트스트랩 정보의 예를 개시한 도면

도 6은 도 5에서 단말기가 마스터 서버를 식별하도록 하기 위한 예를 개시한 도면

도 7 및 도 8은 HyperText Transfer Protocol(HTTP)형식을 예시한 도면

도 9는 단말기가 마스터 서버를 식별하는 다른 예를 개시한 도면

도 10은 서비스 가이드 정보를 전송하는 송신 장치의 일 실시예를 도시한 도면

도 11은 도 10에서 개시한 변조및부호화부를 예시한 도면

도 12는 도 11의 예 중 프레임형성부가 프레임을 형성한 결과에 따른 신호 배치를 예시한 도면

도 13은 방송 프로그램, 콘텐츠 및 데이터 등이 채널로 전송되는 예를 나타낸 도면

도 14는 서비스 가이드 정보를 수신하는 수신 장치를 예시한 도면

도 15는 도 14의 시스템복호부를 예시한 도면

도 16은 프로토콜 스택(protocol stack)의 예시한 도면

도 17은 본 발명에 따른 서비스 가이드 정보 수신 방법의 실시예를 나타낸 도면

Claims

인터액티브 채널을 통해 서비스 가이드 정보를 전송할 수 있는 다수의 서버 중 마스터(master) 서버의 위치 정보를 얻는 획득단계; 및

상기 마스터 서버로부터 서비스 가이드 정보를 수신할 수 있는지 여부를 판단하고, 상기 판단결과에 따라 마스터 서버가 서비스 가이드 정보를 전송할 수 없는 경우, 슬레이브(slave) 서버에 대한 위치 정보를 얻어 상기 슬레이브 서버로부터 서비스 가이드 정보를 수신하고, 상기 판단결과 마스터 서버로부터 서비스 가이드 정보를 수신한 경우 상기 마스터 서버로부터 서비스 가이드 정보를 수신하는 수신단계를 포함하는 서비스 가이드 정보 수신 방법.
제 1항에 있어서,

상기 획득단계 중 마스터 서버의 위치 정보는 부트스트랩 정보로부터 획득하거나, 상기 인터액티브 채널을 통해 상기 서버들에 마스터 서버의 위치 정보를 요청하고 그 요청에 따른 응답으로 상기 마스터 서버의 위치 정보를 획득하는 서비스 가이드 정보 수신 방법.
제 1항에 있어서,

상기 슬레이브 서버의 위치 정보는 상기 부트스트랩 정보로부터 획득하거나, 상기 인터액티브 채널을 통해 상기 서버들에 마스터 서버의 위치 정보를 요청하고 그 요청에 따라 상기 마스터 서버가 전송하는 리스트 정보로부터 상기 슬레이브 서버의 위치 정보를 획득하는 서비스 가이드 정보 수신 방법.
서비스 가이드 정보를 전송하는 다수의 서버 중 마스터(master) 서버의 위치 정보를 포함하는 부트스트랩 정보를 수신하는 수신부; 및

상기 수신부가 수신한 부트스트랩 정보로부터 상기 마스터 서버의 위치 정보를 얻고 이를 이용해 상기 마스터 서버에 서비스 가이드 정보를 요청하도록 하는 메세지를 생성하여 출력하고, 상기 마스터 서버로부터 서비스 가이드 정보를 전송받지 못할 경우, 슬레이브 서버의 위치 정보를 얻고 상기 슬레이브 서버로부터 서비스 가이드 정보를 수신하는 제어부를 포함하는 서비스 가이드 정보 수신 장치.
제 4항에 있어서,

상기 제어부는 상기 부트스트랩 정보로부터 슬레이브 서버의 위치 정보를 얻거나 상기 마스터 서버가 전송하는 리스트 정보로 상기 슬레이브 서버의 위치 정보를 획득하는 서비스 가이드 정보 수신 장치.