KR20150140783A - 브로드캐스트/멀티캐스트 인에이블드 네트워크들을 통해 오브젝트들의 플로우들을 전달하기 위한 방법들 - Google Patents

Abstract

컨텐츠(예를 들어, 멀티미디어 스트림들, 오디오-비디오 스트림들, 비디오 파일들, 텍스트 등)가 컴포넌트들(예를 들어, 서버들, 수신기 디바이스, 소프트웨어 애플리케이션들, 모듈들, 프로세스들 등)을 통해서 브로드캐스트 채널을 통해 및/또는 브로드캐스트 네트워크를 통해 수신기 디바이스들로 전달될 수 있는데, 그 컴포넌트들은, 브로드캐스트 네트워크를 통해 통신되는 정보의 양을 감소시키고, 통신에 의해 소비되는 네트워크 대역폭의 양을 감소시키고, 통신되는 개별 오브젝트들에 대한 정밀한 타이밍 요건들을 충족시키며, 각각의 수신기 디바이스가 그 수신기 디바이스의 배터리 또는 프로세싱 자원들의 과도한 양을 소비하지 않으면서 컨텐츠를 수신, 디코딩 및 렌더링할 수 있게 하게 하는 방식으로 컨텐츠를 통신하도록 구성된다.

Description

브로드캐스트/멀티캐스트 인에이블드 네트워크들을 통해 오브젝트들의 플로우들을 전달하기 위한 방법들{METHODS FOR DELIVERY OF FLOWS OF OBJECTS OVER BROADCAST/MULTICAST ENABLED NETWORKS}

[0001] 본 출원은 "Methods for Delivery of Flows of Objects over Broadcast/Multicast Enabled Networks"란 명칭으로 2013년 4월 12일에 출원된 미국 가출원번호 제61/811,693호; "Methods for Delivery of Flows of Objects over Broadcast/Multicast Enabled Networks"란 명칭으로 2013년 5월 2일에 출원된 미국 가출원번호 제61/818,912호; "Methods for Delivery of Flows of Objects over Broadcast/Multicast Enabled Networks"이란 명칭으로 2013년 9월 16일에 출원된 미국 가출원번호 제61/878,368호; 및 "Methods for Delivery of Flows of Objects over Broadcast/Multicast Enabled Networks"이란 명칭으로 2013년 12월 5일에 출원된 미국 가출원번호 제61/912,145호 각각의 우선권을 주장하며, 이에 의해, 이 가출원들 모두의 전체 내용들은 인용에 의해 통합된다.

[0002] 무선 통신 기술들은 과거 수년 동안 폭발적인 성장을 보였다. 무선 서비스 제공자들은 현재 자신들의 고객들에게 많은 서비스들을 제공하고 있으며, 정보, 자원들 및 통신들에 대한 새로운 액세스 레벨들을 사용자들에게 제공하고 있다. 무선 통신 서비스들에 덧붙여 나온 최신의 부가 서비스는 수신기 디바이스들에 텔레비전 및 다른 컨텐츠를 브로드캐스팅하는 능력이었다. 멀티미디어 FLO(forward link only) 브로드캐스트 서비스들은 사용자들로 하여금 텔레비전 쇼들과 같은 멀티미디어 프로그래밍을 시청할 뿐만 아니라 모바일 브로드캐스트 전송들을 수신하도록 구성된 모바일 수신기 디바이스를 사용하여 뉴스, 엔터테인먼트 스포츠, 비즈니스, 인터넷 데이터, 데이터 파일들 및 다른 컨텐츠의 모바일 편집(mobile edition)들을 수신하도록 한다. 멀티미디어 브로드캐스트 서비스들은 수신기 디바이스들에 다양한 서비스들을 전달하기 위하여 사용될 수 있는 중요한 대역폭을 나타낸다.

[0003] 브로드캐스트 서비스들을 전달하기 위한 하나의 프로토콜은 IETF(Internet Engineering Task Force) RFC(Request for Comments) 3926 및 RFC 6726에서 정의된 FLUTE(File Delivery over Unidirectional Transport)이다. FLUTE는 수초 이상의 전달 세션들을 사용하여 많은 호스트들에 큰 파일 및 작은 파일을 전달하기 위하여 사용될 수 있다. 예컨대, FLUTE는 많은 호스트들에 큰 소프트웨어 업데이트들을 동시에 전달하기 위하여 사용될 수 있다. FLUTE는 또한 자막 처리를 위한 타임-라인 텍스트(time-lined text), 즉 네트워크의 혼잡 상태에 대하여 세션의 풍부성(richness)을 스케일링하기 위하여 ALC(Asynchronous Layered Coding)(이는 IETF RFC 3450 및 IETF RFC 5775에 규정되어 있음) 및 LCT(Layered Coding Transport)(이는 IETF RFC 3451 및 IETF RFC 5651에 규정되어 있음)로부터의 자신의 레이어링 계승을 잠재적으로 레버리지하기 위한 타임-라인 텍스트와 같은 연속적인 그러나 세그먼트화된 데이터를 위해 사용될 수 있다. FLUTE는 또한 메타데이터, 예컨대 사용자 애플리케이션들이 멀티미디어 세션들에 액세스하는 것을 가능하게 하는 SDP(Session Description Protocol) 파일들의 기본 전송에 적합하다. FLUTE는 멀티캐스트 및 유니캐스트 전달 모두에 사용될 수 있으나, 이의 주요 애플리케이션은 단방향 멀티캐스트 파일 전달을 위한 것이다.

[0004] 스트림들, 예컨대 비디오 및/또는 오디오 스트림들을 파일들의 시퀀스로서 단방향 멀티캐스트 시스템들을 통해 전달하는 경향이 최근에 있어 왔다. 예컨대, 3GPP MBMS 시스템에서 주요 스트리밍 전달 메커니즘은 DASH의 FLUTE(ISO/IEC 23009-1에 규정된 MPEG Dynamic Adaptive Streaming over HTTP 및 TS26.247에 규정된 DASH의 3GPP 버전)를 사용하여, 포맷팅된 스트리밍 컨텐츠를 전달하기 위하여 스트림들의 RTP 전달에서부터 과거 2-3년 동안 진화되었으며, 여기서 스트리밍 컨텐츠의 통상적으로 동일한 길이의 지속 기간들이 DASH 세그먼트 파일들로서 포맷팅되며 이후 각각의 DASH 세그먼트 파일은 FLUTE 프로토콜을 사용하여 오브젝트로서 전달된다. 그러나, FLUTE는 이러한 스트리밍 애플리케이션들에 대하여 특별하게 설계되지 않았으며 따라서 이와 관련하여 어느 정도 한계들을 가진다.

[0005] 다양한 양상들은 브로드캐스트 네트워크를 통해 정보를 전송하는 방법들을 포함하며, 이 방법들은 관련된 소스 오브젝트들의 컬렉션(collection)을 소스 플로우(source flow)와 연관시키는 단계 및 소스 오브젝트들이 서로에 대한 그들의 관계에 기초하여 수신기 디바이스에 의해 수신되어 복원될 수 있도록, 소스 플로우와 연관되는 관련된 소스 오브젝트들의 컬렉션의 소스 오브젝트들을 브로드캐스트 네트워크를 통해 전송하는 단계를 포함한다. 일 양상에서, 방법은 소스 플로우에 대한 소스 플로우 식별자를 결정하는 단계 및 소스 플로우와 연관되는 관련된 소스 오브젝트들의 컬렉션의 적어도 하나의 소스 오브젝트의 데이터를 포함할 수 있는 패킷에 소스 플로우 식별자를 포함시키는 단계를 포함할 수 있다.

[0006] 추가 양상에서, 방법은 패킷에서 데이터를 식별하기 위해 패킷에서의 바이트 범위(byte range)를 사용하는 단계를 포함할 수 있다. 추가 양상에서, 방법은 패킷에서 소스 오브젝트의 데이터를 식별하는 바이트 범위를 패킷에 포함시키는 단계를 포함할 수 있다. 추가 양상에서, 방법은 패킷의 TSI(transmission session identifier) 필드를 소스 플로우 식별자로서 사용하는 단계를 포함할 수 있다. 추가 양상에서, 패킷에 소스 플로우 식별자를 포함시키는 단계는 패킷의 TSI(transmission session identifier) 필드에 소스 플로우 식별자를 포함시키는 단계를 포함할 수 있다. 추가 양상에서, 방법은 패킷의 IP(Internet protocol) 목적지 주소 필드와 UDP(user datagram protocol) 포트 번호 필드의 결합을 소스 플로우 식별자로서 사용하는 단계를 포함할 수 있다. 추가 양상에서, 패킷에 소스 플로우 식별자를 포함시키는 단계는 IP(Internet protocol) 목적지 주소 필드와 UDP 포트 번호 필드의 결합에 소스 플로우 식별자를 포함시키는 단계를 포함할 수 있다.

[0007] 추가 양상에서, 방법은 패킷의 CP(codepoint) 필드를 소스 플로우 식별자로서 사용하는 단계를 포함할 수 있다. 추가 양상에서, 패킷에 소스 플로우 식별자를 포함시키는 단계는 데이터 패킷의 CP(codepoint) 필드에 소스 플로우 식별자를 포함시키는 단계를 포함할 수 있다. 추가 양상에서, 관련된 소스 오브젝트들의 컬렉션을 전송하는 단계는 관련된 소스 오브젝트들의 복수의 컬렉션들을 전송하는 단계를 포함할 수 있으며, 각각의 컬렉션은 복수의 상이한 소스 플로우들 중 하나와 연관되고, 복수의 상이한 소스 플로우들 각각은 고유 소스 플로우 식별자를 포함한다. 이러한 양상에서, 소스 플로우와 연관되는 관련된 소스 오브젝트들의 컬렉션의 적어도 하나의 소스 오브젝트의 데이터를 포함할 수 있는 패킷에 소스 플로우 식별자를 포함시키는 단계는 소스 오브젝트의 데이터를 포함할 수 있는 소스 플로우들의 고유 소스 플로우 식별자를 패킷에 포함시키는 단계를 포함할 수 있다.

[0008] 추가 양상에서, 관련된 소스 오브젝트들의 컬렉션을 전송하는 단계는 FEC 복구 데이터, 복구 플로우 식별자 및 복구 오브젝트 식별자를 포함할 수 있는 적어도 하나의 패킷을 전송하는 단계를 포함할 수 있으며, 방법은 복구 플로우를 복수의 상이한 소스 플로우들 중 하나 이상과 연관시키는 단계, 복구 플로우를 위한 복구 플로우 식별자를 결정하는 단계, 복구 플로우를 위한 복구 오브젝트 식별자들의 컬렉션을 결정하는 단계 및 패킷의 복구 플로우 식별자와 복구 오브젝트 식별자의 결합에 적어도 부분적으로 기초하여, 연관된 복수의 소스 플로우들로부터의 소스 오브젝트들 중 어느 것으로부터, 패킷에 포함된 FEC 복구 데이터가 생성되는지를 결정하는 단계를 더 포함한다.

[0009] 추가 양상에서, 복구 플로우 식별자는 TSI 필드에 포함된다. 추가 양상에서, 복구 플로우 식별자는 IP(Internet protocol) 목적지 주소 필드와 UDP 포트 번호 필드의 결합에 포함된다. 추가 양상에서, 복구 플로우 식별자는 CP(codepoint) 필드에 포함된다. 추가 양상에서, 복구 오브젝트 식별자는 TOI(transmission object identifier)이다.

[0010] 추가 양상에서, 복구 오브젝트 식별자는 OSN(object sequence number)이다. 추가 양상에서, FEC 복구 데이터를 포함할 수 있는 적어도 하나의 패킷을 전송하는 단계는 동일한 시간 인터벌 내에 FEC 복구 데이터를 포함할 수 있는 적어도 하나의 패킷을 상응하는 소스 오브젝트에 대한 데이터를 포함할 수 있는 패킷으로서 전송하는 단계를 포함할 수 있다. 추가 양상에서, 방법은 동일한 복구 플로우 식별자 및 동일한 복구 오브젝트 식별자를 갖는 패킷들로부터 그리고 2개의 소스 오브젝트들의 총 크기보다 크거나 그와 동일한 2개의 소스 오브젝트들 중 어느 하나에 대한 데이터를 포함하는 패킷들로부터 결합하여 수신되는 데이터의 양이 2개의 소스 오브젝트들을 디코딩하기에 충분하도록 하기 위해, 상이한 소스 플로우들에서 2개의 소스 오브젝트들로부터의 동일한 복구 플로우 식별자 및 동일한 복구 오브젝트 식별자를 갖는 패킷들에 대한 FEC 복구 데이터를 생성하는 단계를 포함할 수 있다. 추가 양상에서, 복구 플로우 식별자의 부분들은 FEC 복구 데이터를 포함할 수 있는 패킷의 상이한 데이터 필드들에 포함된다.

[0011] 추가 양상에서, 방법은 복구 플로우에 대한 복구 플로우 선언(repair flow declaration)이 FEC 복구 데이터를 포함할 수 있는 패킷의 복구 오브젝트 식별자와 패킷의 FEC 복구 데이터가 생성되는 소스 플로우들과 연관되는 관련된 소스 오브젝트들의 컬렉션으로부터의 소스 오브젝트들 간의 관계를 시그널링하기에 적절한 정보를 포함하도록, 복구 플로우 선언을 결정하는 단계를 포함할 수 있다. 추가 양상에서, 방법은 복구 플로우 선언을 통해서 관계를 시그널링하기 위해 템플릿(template)을 사용하는 단계를 포함할 수 있다. 추가 양상에서, 복구 플로우 선언의 부분은 복구 플로우와 연관되는 소스 플로우와 연관된 적어도 하나의 소스 오브젝트보다 앞서 수신기 디바이스에 전송된다.

[0012] 추가 양상에서, 방법은 관련된 소스 오브젝트들의 컬렉션의 각각의 소스 오브젝트에 대한 소스 오브젝트 식별자를 결정하는 단계 및 소스 오브젝트들에 대한 데이터를 포함하는 하나 이상의 패킷들에 소스 오브젝트 식별자를 포함시키는 단계를 포함할 수 있다. 추가 양상에서, 방법은 관련된 소스 오브젝트들의 컬렉션의 상응하는 소스 오브젝트를 식별하기 위해 소스 플로우 식별자와 소스 오브젝트 식별자의 결합을 사용하는 단계를 포함할 수 있다. 추가 양상에서, 데이터를 포함할 수 있는 패킷에 소스 오브젝트 식별자를 포함시키는 단계는 소스 플로우 식별자와 소스 오브젝트 식별자의 결합이 상응하는 소스 오브젝트를 식별하도록 하기 위해 패킷에 소스 오브젝트 식별자를 포함시키는 단계를 포함할 수 있으며, 패킷은 상응하는 소스 오브젝트에 대한 데이터를 전달한다. 추가 양상에서, 방법은 TOI를 소스 오브젝트 식별자로서 사용하는 단계를 포함할 수 있다.

[0013] 추가 양상에서, 방법은 OSN을 소스 오브젝트 식별자로서 사용하는 단계를 포함할 수 있다. 추가 양상에서, 방법은 소스 오브젝트들이 서로에 대한 그들의 관계에 기초하여 수신기 디바이스에 의해 수신되어 복원될 수 있도록, 소스 플로우와 연관되는 관련된 소스 오브젝트들의 컬렉션에 대한 FEC 복구 데이터를 브로드캐스트 네트워크를 통해 전송하는 단계를 포함할 수 있으며, 소스 플로우와 연관되는 관련된 소스 오브젝트들 중 하나 이상에 대한 FEC 복구 데이터를 포함할 수 있는 각각의 패킷은 소스 플로우를 식별하는 소스 플로우 식별자를 포함할 수 있으며, 패킷은 소스 플로우에 대한 FEC 복구 데이터를 포함할 수 있으며, 소스 플로우와 연관되는 관련된 소스 오브젝트들 중 하나 이상에 대한 FEC 복구 데이터를 포함할 수 있는 각각의 패킷은 하나 이상의 소스 오브젝트들의 하나 이상의 소스 오브젝트 식별자들을 전달하며, 패킷에서 전달되는 FEC 복구 데이터가 하나 이상의 소스 오브젝트들로부터 생성되며, 그리고 소스 플로우 식별자와 하나 이상의 소스 오브젝트 식별자들의 결합은 소스 플로우와 연관되는 관련된 소스 오브젝트들의 컬렉션으로부터 하나 이상의 소스 오브젝트들을 식별하며, 패킷에서 전달되는 FEC 복구 데이터가 소스 플로우로부터 생성된다.

[0014] 추가 양상에서, 방법은 동일한 시간 인터벌 내에 하나 이상의 소스 오브젝트들로부터 생성되는 FEC 복구 데이터를 전달하는 패킷들을 하나 이상의 소스 오브젝트들에 대한 데이터를 전달하는 패킷들로서 전송하는 단계를 포함할 수 있다. 추가 양상에서, 소스 플로우와 연관되는 관련된 소스 오브젝트들의 컬렉션의 소스 오브젝트들을 브로드캐스트 네트워크를 통해 전송하는 단계는 소스 오브젝트들을 그들의 상응하는 복구 오브젝트들과는 관계없이 전송하는 단계를 포함할 수 있다. 추가 양상에서, 방법은 소스 오브젝트를 그의 상응하는 복구 오브젝트로부터 구별하기 위해 SDP(session description protocol) 정보를 사용하는 단계를 포함할 수 있다.

[0015] 추가 양상에서, 관련된 소스 오브젝트들의 컬렉션의 적어도 하나의 소스 오브젝트는 파일의 바이트 범위를 포함할 수 있다. 추가 양상에서, URL(uniform resource locator)이 파일과 연관되고, 방법은 URL 및 바이트 범위를 통해 적어도 하나의 소스 오브젝트를 식별하는 단계를 더 포함한다. 추가 양상에서, 관련된 소스 오브젝트들의 컬렉션의 적어도 하나의 소스 오브젝트는 파일이다. 추가 양상에서, URL(uniform resource locator)이 파일과 연관되고, 방법은 URL을 통해 적어도 하나의 소스 오브젝트를 식별하는 단계를 더 포함한다. 추가 양상에서, 관련된 소스 오브젝트들의 컬렉션의 적어도 하나의 소스 오브젝트는 HTTP(hypertext transfer protocol) 헤더 및 파일의 바이트 범위를 포함할 수 있다. 추가 양상에서, 소스 오브젝트들 중 적어도 일부는 HTTP 헤더, 연관된 파일, 및 HTTP 테일러를 포함할 수 있다.

[0016] 추가 양상에서, 방법은 소스 플로우와 연관되는 소스 오브젝트들의 컬렉션에 대한 소스 플로우 선언이 위치, 이름, 이용가능 시간, 또는 소스 플로우와 연관된 소스 오브젝트들의 컬렉션의 다른 메타데이터 간의 관계들을 시그널링하기에 적절한 정보를 포함하도록, 소스 플로우 선언을 결정하는 단계를 포함할 수 있다. 추가 양상에서, 관련된 소스 오브젝트들의 컬렉션을 전송하는 단계는 관련된 소스 오브젝트들의 컬렉션을 MBMS(multimedia broadcast multicast services)를 통해 전송하는 단계를 포함할 수 있다. 추가 양상에서, 관련된 소스 오브젝트들의 컬렉션을 전송하는 단계는 관련된 소스 오브젝트들의 컬렉션을 FLUTE(file delivery over unidirectional transport)를 통해 전송하는 단계를 포함할 수 있다. 추가 양상에서, 관련된 소스 오브젝트들의 컬렉션을 전송하는 단계는 FEC(forward error correction) 시그널링 정보는 전송하지 않고 소스 오브젝트들을 전송하는 단계를 포함할 수 있다. 추가 양상에서, 소스 오브젝트들 적어도 일부는 HTTP(hypertext transfer protocol) 헤더 및 파일의 바이트 범위를 포함한다.

[0017] 다양한 양상들은 또한 브로드캐스트 네트워크를 통해 하나 이상의 소스 오브젝트들을 전송하는 방법을 포함하며, 방법은 전체 파일의 부분들을 수신하는 단계, 전체 파일을 수신하기 이전에 수신된 부분들에 기초하여 소스 오브젝트들을 생성하는 단계 및 전체 파일을 수신하기 이전에 수신기 디바이스에 생성된 소스 오브젝트들을 전송하는 단계를 포함한다. 일 양상에서, 전체 파일을 수신하기 이전에 수신기 디바이스에 생성된 소스 오브젝트들을 전송하는 단계는 전체 파일의 데이터 순서와는 상이한 순서로 생성된 소스 오브젝트들에 대한 데이터를 전송하는 단계를 포함할 수 있다. 추가 양상에서, 전체 파일의 부분들을 수신하는 단계는 파일의 처음에 파일 크기를 포함할 수 있는 파일의 부분들을 수신하는 단계를 포함할 수 있으며, 파일 크기 이후의 파일의 적어도 일부 데이터가 파일 크기보다 먼저 전송되도록 하는 순서로 소스 오브젝트의 데이터가 전송된다.

[0018] 추가 양상에서, 소스 오브젝트는 HTTP(Hypertext Transfer Protocol) 헤더 및 연관된 파일을 포함할 수 있다. 추가 양상에서, 소스 오브젝트는 HTTP(Hypertext Transfer Protocol) 헤더, 연관된 파일 및 HTTP 테일러를 포함할 수 있다. 추가 양상에서, 방법은 소스 플로우와 연관된 소스 오브젝트들의 컬렉션에 대한 소스 플로어 선언을 결정하는 단계를 포함할 수 있으며, 소스 플로우 선언은 위치, 이름, 이용가능 시간, 또는 소스 플로우와 연관되는 소스 오브젝트들의 컬렉션에 대한 다른 메타데이터 간의 관계들을 시그널링한다. 추가 양상에서, 방법은 소스 플로우 선언에서 관계 정보를 시그널링하기 위해 템플릿을 사용하는 단계를 포함할 수 있다.

[0019] 추가 양상에서, 방법은 소스 플로우와 연관되는 적어도 하나의 관련된 소스 오브젝트에 앞서 소스 플로우에 대한 소스 플로우 선언(declaration)의 부분들을 수신기 디바이스에 전송하는 단계를 포함할 수 있다. 추가 양상에서, 소스 플로우와 연관된 적어도 하나의 관련된 소스 오브젝트에 앞서 소스 플로우에 대한 소스 플로우 선언의 부분들을 수신기 디바이스에 전송하는 단계는 타이밍 정보, URI(uniform resource locator), 소스 오브젝트들에 대한 암호해독 키(decryption key)들을 식별하는 정보 중 적어도 하나를 포함할 수 있는 부분을 전송하는 단계를 포함할 수 있다. 추가 양상에서, 소스 플로우와 연관되는 적어도 하나의 관련된 소스 오브젝트에 앞서 소스 플로우에 대한 소스 흐름 선언의 부분들을 수신기 디바이스에 전송하는 단계는 소스 플로우와 연관된 적어도 하나의 소스 오브젝트를 전송하기에 앞서 소스 플로우 선언 부분을 수신기 디바이스에 대역외에서 송신하는 단계, 및 소스 오브젝트와 함께 소스 플로우 선언의 다른 부분을 대역내에서 전송하는 단계를 포함할 수 있다.

[0020] 추가 양상에서, 소스 오브젝트와 함께 소스 플로우 선언의 다른 부분을 대역내에서 송신하는 단계는 소스 오브젝트에 대한 데이터의 마지막 부분의 표시를 송신하는 단계를 포함할 수 있다. 추가 양상에서, 소스 플로우 선언의 부분들을 수신기 디바이스에 제공하는 단계는 파일 전달 테이블을 송신하지 않고 단방향 전송 프로토콜을 통해 소스 플로우 선언의 부분들을 송신하는 단계를 포함할 수 있다. 추가 양상에서, 전체 파일을 수신하기 이전에 수신기 디바이스에 생성된 소스 오브젝트들을 전송하는 단계는 MBMS(multimedia broadcast multicast services)를 통해 관련된 소스 오브젝트들의 컬렉션을 전송하는 단계를 포함할 수 있다. 추가 양상에서, 전체 파일을 수신하기 이전에 수신기 디바이스에 생성된 소스 오브젝트들을 전송하는 단계는 FLUTE(file delivery over unidirectional transport)를 통해 관련된 소스 오브젝트들의 컬렉션(collection)을 전송하는 단계를 포함할 수 있다.

[0021] 추가 양상에서, 관련된 소스 오브젝트들의 컬렉션을 전송하는 단계는 소스 오브젝트들을 그들의 상응하는 복구 오브젝트들에 관계없이 전송하는 단계를 포함할 수 있다. 추가 양상에서, 방법은 소스 오브젝트를 그의 상응하는 복구 오브젝트로부터 구별하기 위하여 SDP(session description protocol) 정보를 사용하는 단계를 포함할 수 있다. 추가 양상에서, 전체 파일을 수신하기 이전에 수신기 디바이스에 생성된 소스 오브젝트들을 전송하는 단계는 FEC 시그널링 정보를 전송하지 않고 소스 오브젝트들을 전송하는 단계를 포함할 수 있다.

[0022] 추가 양상에서, 방법은 개별 소스 오브젝트의 부분들을 보호하기 위하여 FEC 동작들을 수행하는 단계를 포함할 수 있다. 추가 양상에서, 방법은 다수의 FEC 인코딩들을 사용하여 개별 소스 오브젝트를 전송하는 단계를 포함할 수 있다. 추가 양상에서, 방법은 복구 패킷 헤더에 소스 오브젝트의 보호되는 부분에 대한 TOI 또는 OSN을 추가(adding)하는 단계, 및 자신의 전송 소스 블록의 마지막에 보호되는 부분의 바이트 범위를 추가하는 단계를 포함할 수 있다. 추가 양상에서, 방법은 보호될 소스 오브젝트의 부분의 처음에 소스 심볼들을 추가하는 단계, 및 복구 패킷 헤더에 보호되는 부분의 바이트 범위를 추가하는 단계를 포함할 수 있다.

[0023] 추가 양상에서, 방법은 소스 오브젝트의 보호되는 부분의 바이트 범위의 시작 포지션 및 상기 바이트 범위에 의해 커버되는 다수의 심볼들을 복구 패킷 헤더 내에 추가하는 단계 및 바이트들 또는 옥텟들의 보호되는 부분의 크기를 전송 소스 블록의 마지막에 추가하는 단계를 포함할 수 있다. 추가 양상에서, 전체 파일을 수신하기 이전에 수신기 디바이스에 생성된 소스 오브젝트들을 전송하는 단계는 소스 오브젝트가 규칙적으로 전달되는 HTTP 자원으로서 수신기 디바이스에서 사용하기에 적절하도록 하기 위해서 소스 오브젝트를 HTTP 엔티티 헤더와 HTTP 엔티티 보디의 결합으로서 수신기 디바이스에 단방향 프로토콜을 통해 전달하는 단계를 포함할 수 있다.

[0024] 추가 양상들은, 전송기 및 위의 논의된 방법들에 상응하는 다양한 동작들을 수행하기 위한 프로세서-실행가능 명령들을 갖도록 구성된 컴퓨팅 디바이스를 포함하는 통신 시스템을 포함할 수 있다.

[0025] 추가 양상들은 위의 논의된 방법 동작들에 상응하는 기능들을 수행하기 위한 다양한 수단을 가진 통신 시스템을 포함할 수 있다.

[0026] 추가 양상들은 통신 시스템 내의 컴퓨팅 디바이스가 위의 논의된 방법 동작들에 상응하는 다양한 동작들을 수행하게 하도록 구성된 프로세서-실행가능 명령들이 저장되어 있는 비-일시적 컴퓨터-판독가능 저장 매체를 포함할 수 있다.

[0027] 본원에 통합되어 본 명세서의 일부를 구성하는 첨부 도면들은 본 발명의 예시적인 실시예들을 예시하고, 위에서 제공된 일반적인 설명 및 아래에서 제공되는 상세한 설명과 함께, 본 발명의 특징들을 설명하기 위해 제공된다.
[0028] 도 1은 다양한 실시예들에 사용하기에 적절한 모바일 멀티미디어 통신 시스템을 예시하는 블록도이다.
[0029] 도 2는 다양한 실시예들에 의해 사용될 수 있는 다양한 하드웨어 및 소프트웨어 프로토콜 층들 및 모듈들을 통한 정보 플로우들을 예시하는 스택 도면이다.
[0030] 도 3은 각각의 오브젝트가 다양한 실시예들에 따른 플로우와 연관되도록 멀티미디어 컨텐츠를 모바일 수신기 디바이스들에 전달하기에 적절한 예시적인 브로드캐스트 통신 시스템의 다양한 논리 및 기능 컴포넌트들을 예시하는 블록도이다.
[0031] 도 4는 실시예에 따라 복수의 소스 패킷들로 패키지화된 소스 오브젝트를 예시하는 블록도이다.
[0032] 도 5는 현재 FLUTE 오브젝트와 실시예 FLUTE 오브젝트 사이의 차이들을 예시하는 블록도이다.
[0033] 도 6은 HTTP 헤더 필드 및 이용가능 시간 필드를 포함하는 실시예 FLUTE 오브젝트의 예시이다.
[0034] 도 7a는 소스 오브젝트 필드, 패딩 필드, 및 크기/길이(F) 필드를 포함하는 실시예 전송 오브젝트들의 예시이다.
[0035] 도 7b는 소스 오브젝트 필드, 패딩 필드, 및 바이트 범위 필드를 포함하는 실시예 전송 오브젝트들의 예시이다.
[0036] 도 8a 및 도 8b는 현재 FLUTE 복구 FEC(forward error correction) 페이로드 ID들과 다양한 실시예 복구 FEC 페이로드 ID들 사이의 차이들을 예시하는 블록도들이다.
[0037] 도 9a 및 도 9b는 실시예에 따른 동기화된 소스 플로우들에 대한 FEC(forward error correction)를 수행하는데 사용하기에 적절한 통신 패킷들의 데이터-필드들을 예시하는 블록도들이다.
[0038] 도 10은 실시예에 따른 2개의 동기화된 소스 플로우들에 대한 FEC(forward error correction) 동작들을 수행하는데 사용하기에 적절한 통신 패킷의 데이터-필드들을 예시하는 블록도이다.
[0039] 도 11은 실시예에 따른 2개의 동기화되지 않은 소스 플로우들에 대한 FEC(forward error correction) 동작들을 수행하는데 사용하기에 적절한 통신 패킷의 데이터-필드들을 예시하는 블록도이다.
[0040] 도 12는 실시예에 따른 3개의 동기화되지 않은 짧은 소스 플로우들에 대한 FEC(forward error correction)을 수행하는데 사용하기에 적절한 통신 패킷의 데이터-필드들을 예시하는 블록도이다.
[0041] 도 13a는 브로드캐스트 또는 멀티캐스트 네트워크를 통해 오브젝트들의 플로우의 정보를 통신하는 실시예 서버 방법을 예시하는 프로세스 흐름도이다.
[0042] 도 13b는 브로드캐스트 또는 멀티캐스트 네트워크를 통해 오브젝트들의 플로우의 정보를 수신하는 단계 및 전체 소스 오브젝트가 수신되었는지 또는 오브젝트의 부분이 수신된 소스 패킷들로부터 미싱(missing)했는지를 결정하는 단계의 실시예 수신기 디바이스 방법을 예시하는 프로세스 흐름도이다.
[0043] 도 14a 및 도 14b는 다양한 실시예들에 따른 컨텐츠를 통신하기에 적절한 브로드캐스트 통신 시스템들의 다양한 논리 및 기능적 컴포넌트들을 예시하는 블록도들이다.
[0044] 도 15는 2개의 소스 오브젝트들에 기초하여 FEC(forward error correction) 복구 패킷을 생성하도록 구성된 실시예 FEC 프레임워크의 다양한 구조들, 데이터-필드들, 통신 패킷들, 변환들 및 정보 플로우들을 예시하는 블록도이다.
[0045] 도 16은 임의의 실시예들에 사용하기에 적절한 수신기 디바이스의 시스템 블록도이다.
[0046] 도 17은 임의의 실시예들에 사용하기에 적절한 서버 컴퓨터의 시스템 블록도이다.

[0047] 다양한 실시예들이 첨부 도면들을 참조하여 상세히 설명될 것이다. 가능한 한 모든 경우에, 동일한 참조 번호들은 동일하거나 유사한 부분들을 지칭하도록 도면들에 걸쳐 사용될 것이다. 특정 예들에 대해 참조들이 이루어지고, 구현들은 예시적인 목적들을 위한 것이지 본 발명 또는 청구항들의 범위를 제한하도록 의도되지는 않는다.

[0048] 개괄하여, 다양한 실시예들은 컨텐츠(예를 들어, 멀티미디어 스트림들, 오디오-비디오 스트림들, 비디오 파일들, 텍스트 등)을 브로드캐스트 채널을 통해 및/또는 브로드캐스트 네트워크를 통해 수신기 디바이스들로 효과적으로 전달하기 위한 시스템들, 디바이스들, 방법들, 및 소프트웨어를 저장하는 비일시적 컴퓨터-판독가능 미디어를 제공할 수 있다. 다양한 실시예들은 기존 브로드캐스트 솔루션들에 비해 다수의 특징들, 향상들, 개선, 및 이익들을 제공할 수 있다.

[0049] 예를 들어, 실시예들은, 브로드캐스트를 통하여 통신되는 정보의 양을 감소시키고, 통신에 의해 소비되는 네트워크 대역폭의 양을 감소시키고, 통신되는 개별 오브젝트들에 대한 정확한 타이밍 요건들을 충족하고, 그리고 각각의 수신기 디바이스가 그 수신기 디바이스의 배터리 또는 프로세싱 자원들의 과도한 양을 소비하지 않으면서 컨텐츠를 수신, 디코딩 및 렌더링할 수 있게 하는 방식으로 컨텐츠를 수신기 디바이스들에 통신하도록 구성된 컴포넌트들(예를 들어, 서버들, 수신기 디바이스들, 소프트웨어 애플리케이션들, 모듈들, 프로세스들 등)을 포함할 수 있다.

[0050] 실시예들은 또한, 서로에 대한 관련된 오브젝트들의 관계에 기초하여 수신기 디바이스에 의해 수신, 디코딩, 및 프로세싱될 수 있도록, 단일 플로우, 스트림, 또는 통신 채널에서 FLUTE 및/또는 브로드캐스트 네트워크를 통해 관련된 오브젝트들의 플로우(또는 관련된 오브젝트들의 컬렉션 또는 그룹)를 전송하도록 구성된 컴포넌트들을 포함할 수 있다.

[0051] 실시예들은, 네트워크를 통해 통신되는 정보 양 및 컨텐츠를 렌더링할 때 수신기 디바이스에 의해 수신, 디코딩 및 에러 정정되는 정보 양을 감소시키기 위하여, 브로드캐스트 시스템을 통해 컨텐츠가 전달될 방법을 조정하기 위한 시그널링 정보(예를 들어, 채널 셋업, 보안, 컨텐츠 전달 등에 관련한 정보)를 송신하도록 구성된 컴포넌트들을 포함할 수 있다.

[0052] 실시예들은 소스 오브젝트들이 수신기 디바이스들에 송신될 때에 앞서 및/또는 소스 오브젝트들이 수신기 디바이스들에 의해 수신될 때에 앞서 오브젝트 정보를 수신기 디바이스들(예를 들어, FLUTE 수신기들)에 송신하도록 구성된 컴포넌트들을 포함할 수 있다.

[0053] 실시예들은 정보가 컴포넌트들에 이용 가능하게 될 때 샘플들 또는 오브젝트들을 브로드캐스팅하고, 그리고 기존 FLUTE-기반 솔루션들 및 시스템들과 호환 가능하게 유지되고, 이에 의해 기존 패킷-기반 스트리밍 시스템들에 의해 제공된 기능성 및 기존 브로드캐스트 오브젝트-기반 스트리밍 시스템들에 의해 제공된 기능성의 하이브리드/결합을 달성하면서, 각각의 샘플/오브젝트에 대한 매우 정밀한 타이밍을 달성하도록 구성된 컴포넌트들을 포함할 수 있다.

[0054] 실시예들은 FDT(file delivery table)을 사용하지 않고도 FLUTE-기반 통신들을 달성하도록 구성된 컴포넌트들을 포함할 수 있다. 실시예에서, 컴포넌트들은 FDT 오브젝트를 브로드캐스팅하지 않고도 또한 수신기 디바이스가 요청되거나 렌더링되는 모든 각각의 실제 오브젝트(예를 들어, 소스 오브젝트)에 대한 두 개의 오브젝트들을 수신할 필요 없이도, FLUTE 및/또는 브로드캐스트 네트워크를 통해 오브젝트들을 통신하도록 구성될 수 있다.

[0055] 실시예들은, 오브젝트 전달이 기존 DASH 시스템들의 기능들, 동작들, 또는 요건들과 잘 맞도록 하기 위해서 FLUTE 및/또는 브로드캐스트 네트워크를 통해 오브젝트들을 전달하도록 구성된 컴포넌트들을 포함할 수 있다. 실시예에서, 컴포넌트들은, 소스 오브젝트들이 호환 가능하거나 또는 DASH 묘사들의 DASH 세그먼트들로서 해석될 수 있도록 그 소스 오브젝트들을 브로드캐스팅함으로써 브로드캐스트 전달 네트워크를 통한 플로우 오브젝트 전달 메커니즘들을 통해 DASH 컨텐츠를 전달하도록 구성될 수 있다. 실시예에서, 컴포넌트들은, FLUTE-기반 오브젝트들이 DASH 세그먼트들인 것을 시그널링하고, FLUTE-기반 오브젝트들이 DASH 세그먼트들인 것처럼 수신기 디바이스가 FLUTE-기반 오브젝트들을 수신 및 프로세싱할 수 있도록 FLUTE-기반 오브젝트들을 패키지화하게 구성될 수 있다.

[0056] 실시예들은 기존 FLUTE-기반 오브젝트들 및 DASH-기반 세그먼트들에 의해 제공된 특징들/특성들의 결합을 포함하는 오브젝트 또는 포맷의 시그널링 정보를 생성, 브로드캐스팅, 또는 수신하도록 구성된 컴포넌트들을 포함할 수 있다.

[0057] 실시예들은 청크(chunk) 전달 동작들 및/또는 청크 수신 동작들을 수행하도록 구성된 컴포넌트들을 포함할 수 있다.

[0058] 실시예들은 그 크기가 송신기에 의해 임의적으로 결정되는 가변 크기 소스 패킷들을 통신하도록 구성된 컴포넌트들을 포함할 수 있다.

[0059] 실시예들은 FEC(forward error correction) 오브젝트 번들링 동작들을 수행하도록 구성된 컴포넌트들을 포함할 수 있다.

[0060] 실시예들은 소스 오브젝트들을 그들의 상응하는 복구 오브젝트들(예를 들어, FEC 오브젝트)에 관계없이 전달하도록 구성된 컴포넌트들을 포함할 수 있다. 컴포넌트들은 데이터 패킷들 내에서 대역내에서 전달되는 정보를 통해 및/또는 상기 패킷들의 SDP(session description protocol) 정보를 통해 복구 플로우들로부터 소스 플로우들을 구별할 수 있다.

[0061] 실시예들은 FEC 시맨틱스(semantic)(예를 들어, FEC 인코딩 ID, "코드 없음 FEC" 시맨틱 등)를 포함하지 않는 소스 컨텐츠를 통신하고, FEC 시맨틱스 없이 소스 컨텐츠를 전달하고, 및/또는 FEC를 시그널링(즉, FEC 시그널링 정보를 송신)함이 없이 소스 컨텐츠를 전달하도록 구성된 컴포넌트들을 포함할 수 있다. 이것은 FEC 능력들을 갖지 않은 수신기 디바이스들이 FLUTE 및/또는 브로드캐스트 네트워크를 통해 소스 오브젝트들을 수신, 디코딩 및 복원(recover)하게 한다.

[0062] 실시예들은 소스 오브젝트가 다수의 FEC 인코딩들을 사용하여 전달되게 하고, 전체 오브젝트가 수신기 디바이스에 수신되기 이전에 오브젝트가 렌더링되게 하도록 개별 소스 오브젝트 또는 DASH 세그먼트의 부분들을 보호하기 위해 FEC 동작들을 수행하게 구성된 컴포넌트들을 포함할 수 있다.

[0063] 실시예들은, 오브젝트의 부분들이 상이한 라벨들과 연관될 수 있도록 소스 오브젝트들에 대한 시그널링 및 오브젝트 정보를 패키지화 및 통신하도록 구성된 컴포넌트들을 포함할 수 있다. 컴포넌트들은 그 패킷(즉, 본래의 소스 오브젝트들을 포함하는 패킷들)에서 전달되는 컨텐츠의 "타입"을 식별하기 위하여 LCT(Layered Coding Transport) 코드 포인트 필드를 사용하도록 구성될 수 있다.

[0064] 실시예들은, 바이트 범위들(byte ranges)을 사용하여 FEC 보호되는 소스 오브젝트의 부분들을 시그널링하거나 식별하도록 구성된 컴포넌트들을 포함할 수 있다.

[0065] 실시예들은, 최대 소스 파일(full source file)/오브젝트, URL(uniform resource locator), 또는 URI(uniform resource identifier)의 서브세트(subset)에 기초하여 소스 오브젝트를 전달 및 보호하도록 구성된 컴포넌트들을 포함할 수 있다.

[0066] 실시예들은, 복구 패킷 헤더에서(예를 들어, 헤더 연장부(header extension)에서) 소스 오브젝트의 보호되는 부분에 대한 TOI(transmission object identifier)/OSN(object sequence number) 값들을 그리고 전송 소스 블록의 마지막에 소스 블록의 보호되는 부분의 바이트 범위를 추가하도록 구성된 컴포넌트들을 포함할 수 있다. 컴포넌트들은 또한 (소스 오브젝트의 맨 처음 대신에) 보호될 소스 오브젝트의 부분의 처음에 소스 심볼들을 추가 또는 시작하고, 직접 복구 패킷 헤더 내에서 파일, 전달, 또는 소스 오브젝트의 보호되는 부분의 실제 바이트 범위를 제공하도록 구성될 수 있다. 컴포넌트들은 또한, 직접 복구 패킷 헤더 내에서 바이트 범위에 의해 커버되는 다수의 심볼들 및 바이트 범위의 시작 포지션을 추가하고 전송 소스 블록의 마지막에 바이트들(또는 본 개시에서 등가적으로, 옥텟들) 단위의, 보호된 소스 오브젝트(예를 들어, FEC 인코딩 오브젝트)의 부분의 크기를 추가하도록 구성될 수 있다. 컴포넌트들은 또한, 소스 오브젝트 TOI(transmission object identifier) 또는 OSN(object sequence number), 소스 오브젝트 내 시작 바이트 포지션(start byte position), 및 소스 오브젝트 내 종료 바이트 포지션을 포함하는 소스 오브젝트의 각각의 보호되는 부분에 대한 복구 패킷 헤더를 갖는 복구 패킷들을 발생시키도록 구성될 수 있다.

[0067] 실시예들은, 소스 오브젝트가 완료(complete) HTTP 응답을 포함할 수 있게 하기 위해, 오브젝트 전달 동작들을 수행하도록 구성되는 컴포넌트들을 포함할 수 있다. 컴포넌트들은 또한, 오브젝트(또는 오브젝트의 바이트 범위)와 연관된 데이터가 동적으로 분포되는 것을 허용하기 위해, (예를 들어, 전달 오브젝트로서) HTTP 엔티티 보디 및 헤더를 송신하도록 구성될 수 있다.

[0068] 실시예들은, 전체 파일 또는 오브젝트가 서버 또는 송신 디바이스에서 수신되거나 발생되기 전에 미리 데이터 송신을 시작하도록 구성된 컴포넌트들을 포함할 수 있다.

[0069] 실시예들은, 파일/오브젝트의 부분들을 비순차적으로, 부분들 모두가 수신되거나 발생되기 전에, 및/또는 FEC 스킴과는 관계없이 송신하도록 구성된 컴포넌트들을 포함할 수 있다. 실시예에서, 이는 LCT의 연장 능력들을 이용함으로써 LCT 메커니즘들을 통해 달성될 수 있다.

[0070] 실시예들은, 위치들, 이름들, 이용가능 시간들 및 전달될 오브젝트들의 컬렉션 또는 시퀀스와 연관된 다른 메타데이터 간의 관계(relationship)들을 시그널링하기 위해 템플레이팅(templating) 기술들 및 템플릿들(templates)을 이용하도록 구성된 컴포넌트들을 포함할 수 있다. 실시예에서, 컴포넌트들은 오브젝트에 대한 URI들을 식별하고, 브로드캐스트/멀티캐스트 채널을 통해 오브젝트가 전송 및/또는 수신될 시기를 결정하기 위해 소스 플로우 선언(source flow declaration)을 이용하도록 구성될 수 있다. 실시예에서, 컴포넌트들은, 1회 정적 파일 전달 디스크립터(one-time static File Delivery Descriptor)를 수신기 디바이스들에 송신하고, 유효 URI(uniform resource identifier)를 식별하는 정보와 같은 동적 정보를 생성하기 위해 동적 전달 프로토콜에서 헤더 필드들을 이용하도록 구성될 수 있다.

[0071] 실시예들은, 현재 FLUTE 표준들의 요건들을 준수하면서 및/또는 현재 FLUTE 표준들을 구현하는 다른 컴포넌트들과의 역호환성(backwards compatibility)을 유지하면서 앞서 언급된 동작들 중 임의의 것 또는 전부를 수행하도록 구성된 컴포넌트들을 포함할 수 있다.

[0072] 본원에서 "예시적(exemplary)"이란 단어는, "예, 예증, 또는 예시로서 기능하는"을 의미하는데 이용된다. "예시적"으로 본원에 설명된 임의의 구현이 반드시 다른 구현들보다 바람직하거나 유리한 것으로 해석되는 것은 아니다.

[0073] 본원에서 "수신기 디바이스"란 용어는, 셀룰러 텔레폰들, 스마트폰들, 멀티-미디어 플레이어들, PDA(personal data assistant)들, 컴퓨팅 디바이스들, 서버 컴퓨터들, 퍼스널 컴퓨터들, 랩톱 컴퓨터들, 스마트북들, 울트라북들, 테블릿 컴퓨터들, 팜-탑(palm-top) 컴퓨터들, 무선 전자 메일 수신기들, 멀티미디어 인터넷 가능 셀룰러 텔레폰들, 무선 게이밍 제어기들, 및 정보를 송신하고 수신하기 위한 통신 회로를 포함하는 유사한 전자 디바이스들, 메모리 및 프로그램가능 프로세서 중 임의의 하나 또는 전부를 지칭하는데 이용된다.

[0074] 본원에서 "브로드캐스트"란 용어는, 다수의 수신 디바이스들에 의해 동시에 수신될 수 있는 데이터(멀티미디어 스트림들, 파일들, 정보 패킷들 등)의 전송을 의미하는데 이용되며, 유니캐스트, 멀티캐스트, 및 단일 전송시 하나 또는 다수의 수신기 디바이스들에 정보를 송신하는데 적절한 다른 전송 기술들을 포함한다. 브로드캐스트 네트워크들은 전송만을 할 수 있고 어떠한 직접적인 리턴 통신 링크도 갖지 않기 때문에, 이러한 네트워크들은 또한 본원에서, 셀룰러 텔레폰 시스템들 및 무선 광역 네트워크들(예를 들어, WiFi, WiMAX 등)과 같은 양방향(two-way) 무선 통신 네트워크들과 이러한 통신 네트워크들을 구별하기 위해, "FLO(forward link only)" 브로드캐스트 네트워크들로 지칭된다.

[0075] 본원에서 "전달 오브젝트" 및 "소스 오브젝트"란 용어는, 메타데이터 또는 데이터를 포함하거나 또는 이로 표현되며 무선 또는 브로드캐스트 통신 기술들을 이용하여 통신될 수 있는 임의의 자립식 유닛(self-contained unit)을 설명하기 위해 상호교환가능하게 이용될 수 있다. 소스 오브젝트들의 예들은, 파일, HTTP 엔티티, 바이트 범위, 엔티티 헤더 및 엔티티 헤더에 의해 표시된 최대 파일을 포함하는 엔티티 보디, 파일의 바이트 범위를 표시하는 엔티티 헤더, 및 엔티티 헤더에 의해 표시된 파일의 부분을 포함하는 엔티티 보디 등을 포함한다.

[0076] 본 출원에서 사용되는 것처럼, "컴포넌트", "모듈", "시스템", "서비스", "인코더", "송신기", "수신기" 등의 용어들은, 컴퓨터-관련 엔티티 예컨대 하드웨어, 펌웨어, 하드웨어와 소프트웨어의 결합, 소프트웨어, 또는 실행중인 소프트웨어(이들로 제한되지는 않음)를 포함하도록 의도되며, 이들은 특정 동작들 또는 기능들을 수행하도록 구성된다. 예를 들어, 컴포넌트는 프로세서상에서 실행되는 프로세스, 프로세서, 오브젝트, 실행가능물, 실행 스레드, 프로그램 및/또는 컴퓨터(이들로 제한되지는 않음)일 수 있다. 예시로서, 컴퓨팅 디바이스 상에서 실행되는 애플리케이션 및 컴퓨팅 디바이스 둘 다는 컴포넌트로서 지칭될 수 있다. 하나 이상의 컴포넌트들이 프로세스 및/또는 실행 스레드 내에 상주할 수 있고, 컴포넌트가 하나의 프로세서상에 국한되거나 2개 이상의 프로세서들 사이에 분포될 수 있다. 추가로, 이들 컴포넌트들은 다양한 명령들 및/또는 데이터 구조들이 저장되어 있는 다양한 비-일시적 컴퓨터-판독가능 매체로부터 실행될 수 있다. 컴포넌트들은 로컬 및/또는 원격 프로세스들, 기능 또는 프로시저 호출들, 전자 신호들, 통신 메시지들, 데이터 패킷들, 메모리 판독/기록들 및 다른 공지된 네트워크, 컴퓨터, 프로세서 및/또는 프로세스 관련 통신 방법들에 의해 통신할 수 있다.

[0077] 다수의 상이한 브로드캐스트 서비스들, 표준들 및 기술들이 장차 이용가능하거나 고려되며, 이들 모두는 다양한 실시예들을 구현하거나 이들로부터 유리할 수 있다. 이러한 서비스들, 표준들 및 기술들은, 예를 들어, MBMS(multimedia broadcast/multicast service), eMBMS(enhanced multimedia broadcast/multicast service), EMBS(enhanced multi-broadcast service), GBS(global broadcast service), GBS(global broadcast service), OMA BCAST(open mobile alliance mobile broadcast services enabler suite), MediaFLO®, DVB-IPDC(digital video broadcast Internet protocol datacasting), DVB-H(digital video broadcasting-handheld), DVB-SH(igital video broadcasting-satellite services to handhelds), DVB-H2(digital video broadcasting-handheld 2), ATSC-M/H(advanced television systems committee-mobile/handheld), CMMB(China multimedia mobile broadcasting), ATSC-T(advanced television systems committee terrestrial) 및 MMT(MPEG Media Transport)를 포함한다. 이들 브로드캐스트 표준들, 서비스들 및 기술들 각각은 예를 들어 데이터, 시그널링 및/또는 컨텐츠 메시지들을 통신하는데 적절한 브로드캐스트 통신 채널들을 포함한다.

[0078] 앞서 언급된 브로드캐스트 서비스들 이외에도, 멀티미디어 및 다른 서비스들이 다양한 셀룰러 및 무선 통신 서비스들 및 표준들을 통해 개별 모바일 수신기 디바이스들로 직접 전달될 수 있으며, 이들 중 임의의 것 또는 전부는 다양한 실시예들을 구현하며 이들로부터 유리할 수 있다. 이러한 서비스들 및 표준들은, 예를 들어, 3GPP(third generation partnership project), LTE(long term evolution) 시스템들, 3G(third generation wireless mobile communication technology), 4G(fourth generation wireless mobile communication technology), GSM(global system for mobile communications), UMTS(universal mobile telecommunications system), 3GSM, GPRS(general packet radio service), CDMA(code division multiple access) 시스템들(예를 들어, cdmaOne, CDMA1020TM), EDGE(enhanced data rates for GSM evolution), AMPS(advanced mobile phone system), 디지털 AMPS(IS-136/TDMA), EV-DO(evolution-data optimized), DECT(digital enhanced cordless telecommunications), WiMAX(Worldwide Interoperability for Microwave Access), WLAN(wireless local area network), WPA, WPA2(Wi-Fi Protected Access I & II), 및 iden(integrated digital enhanced network)을 포함한다. 이들 기술들 각각은, 예를 들어, 음성, 데이터, 시그널링 및/또는 컨텐츠 메시지들의 전송 및 수신을 수반한다.

[0079] 개별 표준 또는 기술과 관련된 전문용어 및/또는 기술적 상세사항들에 대한 임의의 참조는 단지 예시 목적을 위한 것이며, 청구항 문언들에 특정하게 열거되지 않는다면, 특정 통신 시스템 또는 기술로 청구항들의 범위를 제한하는 것으로 의도되지 않음이 이해되어야 한다.

[0080] 일반적으로, 수신기 디바이스 상에서의 컨텐츠 수신, 디코딩 및 디스플레이의 동작들은 수신기 디바이스의 이용가능한 자원들(CPU 동작들, 배터리 전력, 메모리 등)의 상당량을 소비한다. 이는, 부분적으로는, 수신기 디바이스에 의해 수신되고, 디코딩되고, 그리고 에러 정정되어야 하는 다량의 디지털 정보로 인한 것이다. 다양한 실시예들은, 컨텐츠를 수신 또는 렌더링할 때, 수신기 디바이스에 의해 수신되고, 디코딩되고, 그리고 에러 정정되어야 하는 정보의 양을 감소시킬 수 있다.

[0081] 멀티미디어 컨텐츠를 전달할 때 네트워크를 통해 통신되어야 하는 정보의 양을 감소시키는 다수의 쉽게 이용가능한 압축 기술들(예를 들어, "MPEG(moving picture experts group)" 압축)이 현재 존재한다. 그러나, 이러한 기술들에 의해 이용되는 압축 방법의 효율성과 관계없이, 사용자들에게 충족할 만한 사용자 경험을 제공하기 위해서는 다량의(large volume of) 정보가 네트워크를 통해 통신되어야 한다. 따라서, 기존 압축 기술만으로는 수신기 디바이스의 성능 또는 전력 소모 특징들을 상당히 개선시키거나 네트워크를 통해 통신되는 정보의 양을 적절히 감소시키지 못한다.

[0082] 흔히, 전달 네트워크의 상태가 시간에 따라 변화하게 하는 네트워크 변동(network fluctuation)들(예를 들어, 자원들의 이용가능성의 변화들)이 존재한다. 이들 변동들은, 수신기 디바이스로 하여금, 패킷들을 드롭(drop)하게 하고, 버퍼들을 언더-런(under-run)하게 하거나, 아니면 사용자 경험에 부정적인 영향을 미치게 할 수 있다. DASH와 같은 다양한 기술들은, 수신기 디바이스의 클라이언트 애플리케이션(예를 들어, 미디어 플레이어 등)이 수신기 디바이스로 전송되는 또는 수신기 디바이스에 의해 수신되는 스트림들의 품질 또는 비트레이트를 조절함으로써 네트워크 조건들에서 이러한 변화들에 응답하게 허용한다. 통상적으로 이들 기술들은, 원시(raw) 비디오 파일을 판독하며 생성적 IP(generative Internet Protocol) 네트워크를 통한 전달을 위해 다수의 버전들의 파일("표현들(representations)"로 불림)을 생성하는 컨텐츠 발생 서버를 포함한다.

[0083] DASH는, 멀티-레이트 인코딩 멀티미디어(multi-rate encoded multimedia)를 설명하기 위한 웹-호환가능 국제 표준이며, 이는 클라이언트 애플리케이션(예를 들어, 미디어 플레이어들 등)이 네트워크 역학(network dynamics), 자원 이용가능성 및/또는 다른 적절한 팩터들에 기초하여 미디어 표현 중 어느 부분들을 수신할지를 동적으로 선택하도록 허용한다. DASH는 수신기 디바이스로 전달될 데이터를 인코딩하는 세그먼트들로 각각의 표현을 파티셔닝하는 것을 지원한다. 통상적으로, DASH는 MPD(Media Presentation Description)를 이용하며, MPD는 세그먼트들, 세그먼트들이 이용가능한 시간들, 및 세그먼트들을 포함하는 미디어의 플레이백 레이트의 표시들을 공지하는(announces) 세그먼트 이용가능성 타임라인이다. 현재 시스템들에서, MPD들은 OTA(Over-the-Air) 전달 기술들을 통해 수신기 디바이스들로 제공된다.

[0084] FLUTE는 브로드캐스트/멀티캐스트 전달 네트워크들의 사용에 특히 아주 적합한 파일들의 단방향성 전달을 위한 전송 층 기술/프로토콜이다. FLUTE 솔루션 또는 시스템은 IETF(Internet Engineering Task Force) RFC(Request for Comments) 3926 및 RFC 6726에 정의된 통신 메커니즘들을 구현하는 서버들 및 수신기 디바이스들을 포함할 수 있다.

[0085] 기존 FLUTE 솔루션들은 서로 독립적인 소스 오브젝트들(예를 들어, 파일들, 세그먼트들 등)을 전달하며, 일반적으로 동일한 플로우에 포함되는 관련 소스 오브젝트들 사이의 관계를 설정하는 것을 지원하지 않는다. 결과적으로, 기존 솔루션들을 사용하면, 브로드캐스트 네트워크의 서버는 각각의 오브젝트의 파라미터들, 오브젝트가 저장되어야 하는 위치, 오브젝트가 전달되기 시작하는 시기 및 다른 유사한 정보를 소스 오브젝트의 전달에 앞서 또는 소스 오브젝트의 전달 동안 수신기 디바이스에 독립적으로 시그널링(즉, 시그널링 또는 제어 정보를 포함하는 통신 메시지를 전송)해야 한다. FLUTE 표준들(RFC 3926 및 RFC 6726)에 따르면, 서버는 해당 수신기 디바이스로 전달될 각각의 소스 오브젝트에 대한 이러한 시그널링 정보를 송신해야 한다. 또한, 각각의 오브젝트에 대한 이러한 시그널링 정보를 통신하는 것은 네트워크의 이용가능한 대역폭의 과도한 양을 소비하며 수신기 디바이스가 추가의 프로세싱, 동기화 또는 메모리 액세스 동작들을 수행하는 것(이들 중 임의의 것은 수신기 디바이스의 성능 및/또는 전력 소비 특징들을 감소시키거나 사용자 경험을 악화시킬 수 있음)을 요구한다. 또한, 시그널링 정보 중 임의의 것이 손실되는 경우, 오브젝트는 일반적으로 복원(recover)될 수 없다.

[0086] 다양한 실시예들은, 컨텐츠 또는 소스 오브젝트들의 플로우를 전달할 때 통신되는 정보의 양을 감소시키기 위해, 브로드캐스트 네트워크에서 통신들을 관리하기 위한 방법들, 및 이 방법들을 구현하도록 구성된 디바이스들 및 시스템들을 포함할 수 있다.

[0087] 다양한 실시예들은, 관련된 오브젝트들(또는 관련된 오브젝트들의 그룹들의 컬렉션)이 서로에 대한 그들의 관계들에 기초하여 수신되어 디코딩되고 프로세싱될 수 있도록, 단일 플로우, 스트림 또는 통신 채널에서 브로드캐스트 네트워크를 통해 및/또는 FLUTE을 통해 관련된 오브젝트들의 플로우(또는 관련된 오브젝트들의 그룹들의 컬렉션)를 전송하는데 적절한 전달 프레임워크를 제공할 수 있다. 이는, 플로우에서 FLUTE 오브젝트들 간의 관계들을 식별하지 않고, 관련되지 않은 오브젝트들을 동일 플로우에 패키징하고, 수신 디바이스가 독립적 시그널링 정보 및 데이터를 수신하여 각각의 FLUTE 오브젝트를 디코딩하는 것을 요구하는 기존의 FLUTE-기반 솔루션들과 대조적이다.

[0088] 다양한 실시예들은 또한, 네트워크를 통해 통신되는 정보의 양을 감소시키는 방식으로 브로드캐스팅 시스템을 통해 컨텐츠가 어떻게 전달될 것인 지를 조정하기 위해 시그널링 정보(예를 들어, 채널 셋업, 보안, 컨텐츠 전달 등에 관련한 정보)를 송신하도록 구성된 네트워크 브로드캐스팅 서버들을 포함할 수 있다.

[0089] 브로드캐스팅 시스템을 통한 오브젝트 전달을 달성하기 위한 기존 솔루션들은 일반적으로, 브로드캐스팅 네트워크의 서버가 브로드캐스팅 네트워크를 통해 통신될 각각의 오브젝트에 대해 독립적으로 시그널링 정보를 송신하는 것을 필요로 한다. 이는 플로우 또는 통신 채널 내에서 및/또는 브로드캐스팅 네트워크를 통해 통신되는 2개 또는 그 초과의 오브젝트들 사이의 관계를 충분히 설정 또는 식별하지 못하는 기존 솔루션들의 무능에 부분적으로 기인한다. 이런저런 이유들로 인해, 기존 솔루션들은 전형적으로, 컨텐츠 정보를 포함하는 파일/오브젝트보다 개별 파일/오브젝트에서 시그널링 정보를 송신한다. FLUTE 기반 시스템들에서, 이러한 시그널링 정보는 전형적으로, 파일 전달 세션 내에서 전달될 파일들과 관련된 다양한 속성들을 설명하는 FDT(file delivery table)에 포함된다.

[0090] 기존 FLUTE 솔루션들은 FDT(file delivery table)들이 설명하는 컨텐츠를 포함하는 오브젝트들과 별개인 오브젝트들의 수신기 디바이스들에 파일 전달 테이블들을 송신한다. 따라서, 기존 FLUTE 솔루션들을 사용하면, 수신기 디바이스는 요청되거나 렌더링된 모든 각각의 소스 오브젝트(예를 들어, 비디오의 세그먼트)에 대한 2개의 오브젝트들(예를 들어, 비디오의 세그먼트 및 비디오의 세그먼트를 설명하는 FDT)를 수신하도록 요청된다. 또한, FDT를 포함하는 패킷/오브젝트가 손실되거나 드롭되는 경우, 수신기 디바이스가 소스 오브젝트(예를 들어, 비디오의 세그먼트)에 포함된 정보를 복원 또는 디코딩할 수 없을 것이기 때문에, 기존 FLUTE 솔루션들은 전형적으로 각각의 FDT 오브젝트를 다수 회 브로드캐스팅하여 각각의 FDT 오브젝트의 수신 가능성을 증가시킨다. FDT 오브젝트의 이러한 중복 브로드캐스팅은 과도한 양의 네트워크의 가용 대역폭을 소비할 수 있는 브로드캐스팅 자원들의 비효율적인 사용이며, 서비스로 튜닝할 때 더 긴 스타트업 지연들과 같은 다른 단점들을 갖는다.

[0091] 다양한 실시예들은, 수신기 디바이스가 요구되거나 렌더링된 모든 각각의 실제 오브젝트(즉, 소스 오브젝트)에 대해 2개의 오브젝트들을 수신할 필요 없이 그리고 FDT 오브젝트를 브로드캐스팅하지 않고, 브로드캐스팅 네트워크를 통해 및/또는 FLUTE를 통해 오브젝트들(예를 들어, 비디오의 세그먼트들 등)을 통신하도록 구성된 컴포넌트들을 포함할 수 있다. 일 실시예에서, 시그널링 정보 및 오브젝트 정보의 적어도 부분이 대역내에서 및/또는 단일 스트림 또는 채널 내에서 함께 통신될 수 있다. 대역내에서 이러한 정보의 통신은 네트워크를 통해 통신되는 정보의 양을 감소시킬 수 있으며, 네트워크 자원들의 더욱 효율적인 사용이다.

[0092] 다양한 실시예들은 소스 오브젝트들이 수신기 디바이스들로 송신될 때 미리 및/또는 소스 오브젝트들이 수신기 디바이스들에 의해 수신될 때 미리 수신기 디바이스들(예를 들어, FLUTE 수신기들)로 오브젝트 정보를 송신하도록 구성된 네트워크 서버를 포함할 수 있다. 이러한 오브젝트 정보는 타이밍 정보, 파일들의 이름 및 위치를 명시하는 URI들(예를 들어, 파일들이 애플리케이션에 의해 참조 또는 액세싱될 것인 경우), 오브젝트들이 암호화되어 전달된 경우 오브젝트를 암호해독하기 위해 어느 키들을 사용할지, 그리고 전달될 소스 오브젝트들에 관련한 다른 식별 정보를 포함할 수 있다. 오브젝트들(또는 오브젝트들의 컬렉션)의 관련된 시퀀스에 대한 이러한 오브젝트 정보는 압축된 형태로 제공될 수 있다. 일 실시예에서, 오브젝트 정보의 부분들은 소스 오브젝트들에 앞서 수신기 디바이스로 대역외에서 송신될 수 있고, 오브젝트 정보의 부분들은 임의의 FDT들을 브로드캐스팅하지 않고 소스 오브젝트들과 대역내에서 송신될 수 있다. 이러한 방식으로, 다양한 실시예들이 FLUTE 기반 통신들에서 FDT들을 사용할 필요성을 완전히 제거할 수 있다.

[0093] 다양한 실시예들은 수신기 디바이스가 소스 오브젝트들의 수신을 위해 더 좋은 계획을 세우고 더욱 지능적으로 판단할 수 있도록 소스 오브젝트에 대한 오브젝트 정보 및 시그널링을 패키징 및 통신하도록 구성된 네트워크 서버들을 포함할 수 있다. 이는 수신기 디바이스로 송신될 오브젝트들이 송신되기 전에 및/또는 이러한 오브젝트들이 수신기 디바이스에서 수신되기 전에, 이러한 오브젝트들에 관련한 수신기 디바이스 정보를 서버가 송신함으로써 달성될 수 있다. 이러한 정보에 미리 액세스하는 것은 수신기 디바이스에 의한 더 양호한 판단 실행 및 계획을 가능하게 한다.

[0094] 다양한 실시예들은 브로드캐스팅 네트워크를 통해서 FLUTE를 통해 전달되는 오브젝트들을 수신기 디바이스의 하나 이상의 클라이언트 애플리케이션들에 링크하도록 구성되는 컴포넌트들을 포함할 수 있다.

[0095] 다양한 실시예들은 오브젝트 전달이 기존 DASH 시스템들의 기능들, 동작들 또는 요건들과 잘 맞도록 브로드캐스팅 네트워크를 통해 및/또는 FLUTE를 통해 오브젝트를 전달하도록 구성된 컴포넌트들을 포함할 수 있다.

[0096] 다양한 실시예들은 브로드캐스팅 전달 네트워크를 통해서 플로우 오브젝트 전달 메커니즘들을 통해 DASH 컨텐츠를 전달하도록 구성된 컴포넌트들(예를 들어, 브로드캐스팅 네트워크의 서버들 등)을 포함할 수 있다. 일 실시예에서, 이는 소스 오브젝트들이 DASH 표현의 DASH 세그먼트들과 필적하도록 소스 오브젝트들을 브로드캐스팅함으로써 달성될 수 있거나, 또는 DASH 표현의 DASH 세그먼트들로서 해석될 수 있다.

[0097] 다양한 실시예들은, FLUTE 기반 오브젝트들이 DASH 세그먼트들이라고 시그널링하고, 수신기 디바이스가 FLUTE 기반 오브젝트들이 DASH 세그먼트들인 것처럼 그 FLUTE 기반 오브젝트들을 수신 및 프로세싱할 수 있게 그 FLUTE 기반 오브젝트들을 패키징하도록 구성된 네트워크 서버들을 포함할 수 있다.

[0098] 다양한 실시예들은 기존 FLUTE 기반 오브젝트들 및 DASH 기반 세그먼트들에 의해 제공되는 특징들/특성들의 결합을 포함하는 포맷 또는 오브젝트의 시그널링 정보를 생성, 브로드캐스팅 또는 수신하도록 구성된 컴포넌트들을 포함할 수 있다.

[0099] 다양한 실시예들은 청크 수신 동작들 및/또는 청크 전달 동작들을 수행하도록 구성되는 컴포넌트들을 포함할 수 있다. 이러한 청크 전달 동작들은 오브젝트가 소스 인코더 및/또는 인캡슐레이션 유닛 또는 모듈에 의해 완전하게 생성되기 전에 브로드캐스팅 네트워크의 서버가 오브젝트를 송신하기 시작하게 할 수 있다. 예를 들어, 브로드캐스팅 네트워크의 서버는 컨텐츠가 이용가능하게 되도록 완전한 10초를 기다리지 않고 비디오의 10초를 포함할 오브젝트를 송신할 수 있다. 즉, 컨텐츠가 이용가능하게 되도록 완전한 10초를 기다리기보다, 서버는 비디오의 제 1 부분을, 다른 부분들이 서버에 의해 수신되기 전에 송신하기 시작하기 위해 청크 전달 동작들을 수행할 수 있다. 일 실시예에서, 서버는 송신 지연을 최소화하기 위해, 개별 소스 패킷으로서 샘플 또는 네트워크 추상 층 유닛 또는 액세스 유닛의 인캡슐레이팅된 버젼을 송신할 수 있다. 유사하게, 수신기 디바이스는, 수신기 디바이스에서 전체 소스 오브젝트가 수신되기 전에 오브젝트들을 수신, 디코딩, 및 사용하기 시작하는 청크 수신 동작들을 수행할 수 있다. 예를 들어, 수신기 디바이스는 비디오를 포함하는 전체 오브젝트가 수신기 디바이스에서 수신되기 전에, 비디오 컨텐츠의 부분들의 플레이를 시작하도록 청크 수신 동작들을 수행하도록 구성될 수 있다.

[0100] 다양한 실시예들은 가변 크기의 소스 패킷들을 지원하도록 구성된 컴포넌트들을 포함할 수 있다. 즉, 기존 FLUTE 표준들 및 솔루션들은, 각각의 소스 패키지 및 각각의 복구 패키지가 동일한 크기(또는 적어도 미리 결정된 심볼 크기의 배수)인 것을 요구한다. 기존 FLUTE 표준들 및 솔루션들에 대조적으로, 다양한 실시예들은 가변 크기 소스 패킷들을 생성, 송신, 수신, 디코딩 또는 사용하도록 구성된 컴포넌트들을 포함할 수 있다. 이러한 가변 크기 패킷들로 전달된 컨텐츠의 경계들은 완전히 임의로 설정될 수 있고 및/또는 컨텐츠의 근본적인 구조와, 예를 들어, 비디오 컨텐츠의 액세스 유닛/모듈 또는 네트워크 추상 층 유닛/모듈 구조와 맞춰질 수 있다. 이러한 가변 크기 패킷들의 사용은, 소스 패킷 경계들이 심볼 구조와 맞춰질 수 있을 때(예를 들어, FEC 등을 사용할 때) 특히 유리하다. 또한, 이러한 패킷의 손실은 다수의 유닛들/모듈들 대신 단일 액세스 유닛/모듈에만 영향을 미칠 수 있으며, 적절하게 구성된 수신기 디바이스들은 수신된 컨텐츠를 렌더링하고 적절하게 저하된 품질을 제공하기 위해 수신기 디바이스(또는 수신기 디바이스의 소프트웨어 애플리케이션들)에 의해 프로세싱될 수 있는 부분적으로 수신된 오브젝트를 생성할 수 있다.

[0101] 다양한 실시예들은 FEC 시맨틱스를 포함하지 않는 소스 컨텐츠를 통신하기에 적절한 동작들을 수행하도록 구성된 컴포넌트들을 포함할 수 있다. 즉, 기존 FLUTE 표준들 및 솔루션들은 일반적으로 소스 전달 동작들이 복원 동작들에 사용되는 FEC 스킴 및 DEC 코드에 직접적으로 연관되도록 소스 전달 동작들이 시그널링되고 수행되는 것을 필요로 한다. 이는 최종 패킷을 제외하고 모든 소스 패킷들이 소스 심볼 크기의 복수일 것을 필요로 하는 고정된 크기의 소스 심볼들의 사용, FEC를 적용하기 위한 기본 유닛으로서 소스 심볼들의 사용 등을 포함하지만, 이에 제한되지 않는다. 이런저런 이유들로 인해, 기존 솔루션들은 어떠한 FEC 코드도 지원되거나, 요구되거나 또는 사용되지 않는 환경에서도 "노-코드 FEC" 시맨틱의 사용을 요구한다. 그러나 FEC 성능들을 갖추지 않은 수신기 디바이스들은 FEC 시맨틱스를 포함하는 오브젝트들을 수신, 디코딩 또는 복원할 수 없을 수도 있다.

[0102] 다양한 실시예들은 FEC 성능들을 갖추지 않은 수신기 디바이스들이 소스 오브젝트들을 수신, 디코딩 및 복원하도록 FEC 시맨틱스가 없는(및/또는 FEC를 시그널링하지 않고) 소스 컨텐츠를 전달하도록 구성된 서버들을 포함할 수 있다. 일 실시예에서, 서버는 제 1 오브젝트의 컨텐츠 정보 및 제 2 오브젝트의 FEC 시그널링 정보를 전달하도록 구성될 수 있다. 일 실시예에서, 제 1 및 제 2 오브젝트는 대역내에서 함께 전달될 수 있다.

[0103] 다양한 실시예들은 FEC(forward error correction) 오브젝트 번들링 동작들을 수행하도록 구성된 컴포넌트들을 포함할 수 있다. 다양한 실시예들은 다수의 오브젝트들에 대한 FEC 보호를 제공하도록 구성된 컴포넌트들을 포함할 수 있다. 일 실시예에서, 이는 FEC 오브젝트 번들링 동작들 및 FEC 시맨틱스들의 전달을 소스 컨텐츠와 분리시키는 동작들의 결합을 통해 달성(또는 가능하게)될 수 있다.

[0104] 다양한 실시예들은 개별 소스 오브젝트 또는 DASH 세그먼트의 부분들을 보호하기 위한 FEC(forward error correction) 동작들을 수행하도록 구성된 컴포넌트들을 포함할 수 있어서, 소스 오브젝트가 다수의 FEC 인코딩들로 전달되게 하며, 더 많은 유연성을 제공하고, 전체 오브젝트가 수신되기 전에 오브젝트가 렌더링 또는 "플레이 아웃"되게 한다. 이러한 실시예들에서, FEC 보호가 부분 오브젝트에 대해, 독립 소스 오브젝트의 바이트 범위에 대해, 및/또는 상이한 스트림들의 상이한 소스 오브젝트로부터 바이트 범위들의 결합들에 대해 제공될 수 있다. 예를 들어, 컴포넌트는, 소스 오브젝트의 처음 3개의 프레임들에 대한 독립적인 FEC 보호, 소스 오브젝트의 다음 5개의 프레임들에 대한 독립적인 FEC 보호, 소스 오브젝트의 다음 6개의 프레임들에 대한 다른 독립적인 FEC 보호 및 소스 오브젝트의 마지막 10개의 프레임들에 대한 또 다른 독립적인 FEC 보호를 제공하도록 구성될 수 있다. FEC 보호의 이러한 방법은, 시스템이 가변 크기의 소스 패킷들 또는 오브젝트들의 전송을 더 잘 지원하게 하고, 전체 오브젝트가 수신되기 전에 수신기 디바이스가 오브젝트들을 점차적으로 디코딩하기 시작하게 하고, 더 많은 오브젝트들의 전송을 가능하게 하고, 오브젝트/스트림에 포함된 독립적인 리프레시 프레임들의 수 또는 빈도를 감소시키고, 스트리밍 컨텐츠(특히 더 많은 오브젝트들로 구성된 컨텐츠)와 관련된 지연들을 향상시키고, 스트림에 의해 소비되는 대역폭의 양을 감소시키고, 그리고 시스템이 FEC 보호를 제공하는 입상에 대한 더 많은 유연성 및 제어를 제공할 수 있다.

[0105] 다양한 실시예들은 오브젝트의 부분들이 상이한 라벨들과 관련될 수 있도록 소스 오브젝트들에 대한 객체 정보 및 시그널링을 패키징 및 통신하도록 구성된 컴포넌트들을 포함할 수 있다. 예를 들어, 오브젝트의 시작 부분은 "타입 A"로 라벨링될 수 있고, 이어 "타입 B"로 라벨링된 부분이 뒤따르고, 이어 "타입 A"로 라벨링된 다른 부분이 뒤따를 수 있다. 이는 비디오 층 컴포넌트(예를 들어, 비디오 층 디코더 등)가 동일한 타입이고, 관련되고, 독립적으로 플레이 가능한 등의 오브젝트의 다양한 파트들 또는 부분들을 식별, 카테고리화 또는 분류하게 한다. 오브젝트 라벨들은 또한 비디오 층 컴포넌트에 유용할 수 있는 정보의 다른 애플리케이션들을 가능하게 할 수 있다. 일 실시예에서, 소스 오브젝트의 다양한 파트들/부분들에 대한 라벨링 정보는 다양한 특성들을 정의, 포함 또는 명시하는 코드 포인트를 통해 수신기 디바이스에 통신 또는 시그널링할 수 있다.

[0106] 다양한 실시예들은 바이트 범위들을 이용하여 FEC 보호되는 소스 오브젝트의 부분들을 시그널링 또는 식별하도록 구성된 컴포넌트들을 포함할 수 있다. 이러한 컴포넌트들은 또한 FEC 보호된 부분들의 바이트 범위를 포함하는 패킷들을 타입 식별자 또는 데이터 필드로 라벨링하도록 구성될 수 있다. (소스 오브젝트들이 수신기에서 복구되면 소스 오브젝트들을 소비하는 높은 레벨의 애플리케이션들에 대해 전형적으로 가치가 있는) 소스 오브젝트의 부분들의 타입 식별이 상이한 타입들의 소스 오브젝트들의 부분들의 FEC 보호를 제공할 수 있도록 다양한 바이트 범위들에 대한 FEC 보호를 제공하도록 시스템과 함께 사용될 수 있다. 이는 소스 오브젝트 내의 데이터의 타입에 대응하는 소스 오브젝트의 각각의 부분이 FEC를 사용하여 독립적으로 복원되게 하며, 이는 소스 오브젝트의 다른 부분들이 수신기에 아직 도달하지 않은 것으로 인해 아직 이용가능하지 않거나, 불충분한 FEC 보호로 인해 결코 이용가능하지 않을 것일 때에도 조차 타입에 대응하는 소스 오브젝트의 상이한 부분들이 그 애플리케이션에 유용한 경우 소비하는 애플리케이션에 가치가 있을 수 있다. 그러나 소스 오브젝트들의 부분들의 FEC 보호 및 소스 오브젝트들의 상이한 부분들의 상이한 타입들로서의 식별은 서로 독립적으로 사용될 수 있다. 예를 들어, FEC 보호가 상이한 타입들의 소스 오브젝트의 두 연속한 부분들에 대해 제공될 수 있거나, FEC 보호가 상이한 타입의 상이한 부분들과 정렬되지 않는 소스 오브젝트의 부분들에 대해 제공될 수 있거나, FEC 보호가 타입들로 분류되지 않은 소스 오브젝트의 상이한 부분들에 대해 제공되지 않을 수 있다.

[0107] 다양한 실시예들에서, 소스 오브젝트의 전달 및 보호는 전체 소스 파일의 서브세트에 의존할 수 있다. 예를 들어, 일 실시예에서, 컴포넌트는 개별 전달 오브젝트(또는 소스 오브젝트)로서 특정 바이트 범위를 처리하도록 구성될 수 있다. 이러한 바이트 범위와 관련된 시그널링 정보는 동적 메타데이터(DMD)와 같은 메타데이터를 통해 통신, 전송 또는 시그널링될 수 있다. 예를 들어, 동적 메타데이터의 오브젝트에는, 시스템이 오브젝트를 메타데이터의 컨텐츠-위치 필드에서 정의되는 URL의 컨텐츠-범위와 관련시키게 하는 컨텐츠-범위 헤더가 할당될 수 있다. FLUTE에 대한 확장으로서 이러한 경우에, 전송 오브젝트 식별자(TOI) 및 URL 사이의 1 대 1 맵핑이 존재하지 않을 수 있지만, TOI는 URL 및 바이트 범위의 결합에 맵핑될 수 있다. 일 실시예에서, 소스 오브젝트는 다수의 보호 오브젝트 또는 FEC 보호되는 부분들로 분할될 수 있다.

[0108] 다양한 실시예들은, 복구 패킷 헤더에(예를 들어, 헤더 연장부에) 소스 오브젝트의 보호되는 부분에 대한 TOI(transmission object identifier)/OSN(object sequence number) 값들을 그리고 전송 소스 블록의 마지막에 소스 블록의 보호 부분의 바이트 범위를 추가하도록 구성된 컴포넌트들을 포함할 수 있다. 다른 실시예들은, (소스 오브젝트의 맨 처음 대신에), 보호될 소스 오브젝트의 부분의 처음에 소스 심볼들을 추가 또는 시작하고, 직접적으로 복구 패킷 헤더 내에 파일, 전달, 또는 소스 오브젝트의 보호 부분의 실제 바이트 범위를 제공하도록 구성된 컴포넌트들을 포함할 수 있다. 추가의 실시예에서, 컴포넌트는, 직접적으로 복구 패킷 헤더 내에서 바이트 범위에 의해 커버되는 다수의 심볼들 및 바이트 범위의 시작 포지션을 추가하고, 전송 소스 블록(예를 들어, FEC 인코딩 오브젝트)의 마지막에 바이트들(또는 옥텟들) 단위의, 보호된 소스 오브젝트의 부분의 크기를 추가하도록 구성될 수 있다. 이러한 바람직한 실시예는, 상기 논의된 실시예 보다 더 적은 복구 패킷 헤더 바이트들을 필요로 하고, 복구 심볼들을 낭비하지 않으며, 그리고 전송 소스 블록의 제 1 심볼들에 패딩 바이트들을 갖지 않는다.

[0109] 다양한 실시예들은, 다음의 것들: 소스 오브젝트 TOI(또는 OSN), 소스 오브젝트 내의 시작 바이트 포지션(start byte position), 및 소스 오브젝트 내의 종료 바이트 포지션(end byte position)을 포함하는, 소스 오브젝트의 각각의 보호되는 부분에 대한 복구 패킷 헤더를 갖는 복구 패킷들을 발생시키도록 구성된 컴포넌트들을 포함할 수 있다. 실시예에서, 복구 패킷 헤더는, 소스 오브젝트의 각각의 보호되는 부분에 대해 10 바이트들(예를 들어, TOI에 대해 2 바이트들, 시작 바이트 포지션에 대해 4 바이트들 및 종료 바이트 포지션에 대해 4 바이트들)일 수 있다. 실시예에서, 이러한 그리고 다른 맵핑은, 개별적인 파일 또는 오브젝트로 수신기 디바이스에 전달되는 메타데이터 파일에 포함될 수 있다. 바람직한 실시예에서, 컴포넌트는 심볼들 단위의 오브젝트의 크기 및 시작 바이트 포지션을 시그널링하도록 구성될 수 있다. 실시예에서, TOI는 메타데이터를 통해 맵핑될 수 있다. 실시예에서, 바이트들 단위의 보호 오브젝트의 크기는, 수신기에 의해 시그널링되거나 알려지는 포지션에서, 소스 블록(예를 들어, FEC 인코딩 오브젝트)에 포함될 수 있다. 실시예에서, 컴포넌트는, 그 시작 바이트 포지션에서 시작하는, 소스 오브젝트의 부분에 대해 FEC 보호를 적용하도록 구성될 수 있다. 다양한 실시예들은, 시스템으로 하여금, 상이한 타입들의 크기들, 이를 테면, 심볼들 단위의 크기, 전달/소스 오브젝트의 시작 어드레스(예를 들어, 16 비트들, 32 비트들) 및 심볼들 단위의 크기 등을 시그널링할 수 있게 하는 다수의 연장 헤더들을 정의할 수 있다.

[0110] 다양한 실시예들은, 해당 패킷(즉, 최초 소스 오브젝트들을 포함하는 패킷들) 내에서 전달되는 컨텐츠의 "타입"을 식별하기 위해 LCT(Layered Coding Transport) 코드 포인트 필드를 이용하도록 구성된 컴포넌트들을 포함할 수 있다. 실시예에서, 이러한 정보는 코드 포인트에 포함될 수 있다. 실시예에서, 컴포넌트는 전송 소스 오브젝트들의 부분들의 "타입들"과 FEC 보호되는 전송 소스 오브젝트들의 바이트 범위들 간의 관계를 식별하도록 구성될 수 있다. 예를 들어, 전송 소스 오브젝트의 바이트 범위들은 몇 개의 타입들(예를 들어, 일반적으로 타입 X, 타입 Y, 타입 Z) 중 하나로 라벨링될(labeled) 것이며, 그리고 각각의 소스 패킷은 하나의 타입의 데이터만을 포함하도록 생성될 수 있다. 추가의 예로서, 타입 X의 바이트 범위 12,000 내지 19,999는 일곱 개(7)의 소스 패킷들에 포함될 것이고(각각 코드 포인트 필드에서 타입 X로 라벨링됨), 처음 여섯 개(6)의 소스 패킷들은 1200 바이트들을 포함할 수 있고, 일곱번째(제 7) 소스 패킷은 800 바이트들을 포함할 수 있다. 그러한 모든 정보는 연관된 패킷들의 코드 포인트 필드들에 포함될 수 있다. 코드 포인트 필드(또는 코드 포인트)에는, 그것이 특정 타입의 처음인 경우, 특정 값이 할당될 수 있다. 또한, 동일한 타입의 소스 오브젝트 내에서 연속적인 소스 오브젝트들의 부분들에 대해 FEC 보호가 제공될 수 있다. 예를 들어, 코드 포인트에 표시된 바와 같은 소스 오브젝트 내의 타입 X의 데이터에 대응하는, 소스 오브젝트의 바이트 범위 12,000 내지 19,999를 보호하는 FEC 복구 오브젝트가 있을 수 있다.

[0111] 다양한 실시예들은, 기존 FEC 스킴의 소스 FEC 페이로드 ID를 이용하도록(즉, 소스 프로토콜에서 제안되는 바이트 범위 대신에 이용함) 구성된 컴포넌트들을 포함할 수 있다. 이러한 실시예는, 예를 들어, 소스 전달 레벨 상에서, 기존 FEC 스킴들과의 역호환성을 지원하는 것을 가능하게 할 수 있다. 이러한 실시예는 오브젝트 번들링을 또한 지원할 수 있다. FEC 프레임워크를 적용하기 전에, 소스 FEC 페이로드 ID는 바이트 범위로 변환될 수 있다. 이러한 실시예는 소스 프로토콜에서 임의의 FEC 스킴들을 개선된 FEC 프레임워크에 적용하는 것을 허용할 수 있다.

[0112] 실시예에서, 소스 오브젝트들은, 완전한 기존 파일들과 대조적으로, 기존 파일들의 바이트 범위들(예를 들어, 이들을 예를 들어 ISO/IEC 23009-1, Annex E에서 정의되는 바와 같이 식별하는 URL을 가짐)일 수 있다(또는 포함할 수 있다).

[0113] 일반적으로, 웹 캐시(web cache)는, 대역폭 이용, 서버 부하 및 네트워크 레이턴시를 감소시키기 위해 웹 도큐먼트들(예를 들어, HTML 페이지들, 이미지들 등)을 일시적으로 저장하기 위한 메커니즘이다. 전형적으로, 웹 캐시는 그것을 통해 전달하는 도큐먼트들의 카피들을 저장하며, 그에 따라, 이후의 웹-기반의 요청들은 웹 캐시로부터 직접적으로 충족될 수 있다. HTTP 캐시는, HTTP 표준들에서 특정되는 기본적인 프레시니스(freshness), 검증(validation) 및 무효(invalidation) 요건들을 구현하는 웹 캐시이다.

[0114] 다양한 실시예들은, 소스 오브젝트로 하여금 완전한 HTTP 응답을 포함할 수 있도록 하기 위해 오브젝트 전달 동작들을 수행하도록 구성된 컴포넌트들을 포함할 수 있다. 이는 수신기 디바이스가 HTTP 캐시로서 동작할 수 있게 하며, 그에 따라, 다른 컴퓨팅 디바이스가 HTTP 요청을 발행하는(issue) 경우 또는 동일한 디바이스 상에서 실행되는 애플리케이션이 HTTP 요청을 발행하는 경우, HTTP를 통해 완전히 전달된 것처럼 수신기 디바이스가 완전한 HTTP 응답을 제공할 수 있다.

[0115] 다양한 실시예들은, 현재 FLUTE 표준들의 요건들을 따르면서 및/또는 현재 FLUTE 표준들을 구현하는 다른 컴포넌트들과의 역호환성을 유지하면서, 위의 언급된 동작들 중 임의의 동작 또는 모든 동작을 수행하도록 구성된 컴포넌트들을 포함할 수 있다.

[0116] 다양한 실시예들은 여러 가지의 통신 시스템들, 네트워크들 및/또는 이동 멀티-미디어 브로드캐스트 시스템들 내에서 구현될 수 있으며, 그 일 예가 도 1에 도시된다. 구체적으로, 도 1은, 이동 수신기 디바이스들(102)이 멀티미디어 브로드캐스트 네트워크(104), 유니캐스트 네트워크(106)로부터, 또는 인터넷(108)을 통해 컨텐츠를 수신할 수 있는 통신 시스템을 도시한다. 전형적인 멀티미디어 브로드캐스트 네트워크(104)는, 이동 브로드캐스트 네트워크 제어 센터/브로드캐스트 오퍼레이션 센터(BOC)(114)에 의해 제어되는 복수의 브로드캐스트 전송기들(112)을 포함한다. 멀티미디어 브로드캐스트 네트워크(104)는, 브로드캐스트 전송기들(112)로부터의 컨텐츠를, 이동 수신기 디바이스들(102)에 의해 수신하기 위한 이동 브로드캐스트 전송들(113)로서 브로드캐스팅한다. BOC(114) 내에는, 컨텐츠 브로드캐스트들을 관리하고, 인터넷(108)에 대한 접속을 제공하는 하나 이상의 서버들(110)이 존재할 수 있다.

[0117] 멀티미디어 브로드캐스트 네트워크(104) 이외에도, 이동 수신기 디바이스들(102)은 유니캐스트 네트워크(106), 이를 테면 셀룰러 전화 네트워크, WiFi 네트워크(미도시), WiMAX 등을 통해 통신할 수 있다. 전형적인 셀룰러 전화 네트워크는, 네트워크 오퍼레이션 센터(network operations center)(118)에 결합된 복수의 셀룰러 기지국들(116)을 포함한다. 네트워크 오퍼레이션 센터(118)는, 이를 테면, 전화 랜드 라인들(telephone land lines)(예를 들어, POTS 네트워크, 미도시) 및 인터넷(108)을 통해, 이동 수신기 디바이스들(102)과 다른 네트워크 목적지들 간에 음성 및 데이터 호(call)들을 접속시키도록 동작한다.

[0118] 이동 수신기 디바이스들(102)과 유니캐스트 네트워크(106) 간의 통신들은, 양방향(two-way) 무선 통신 링크들(115)을 통해, 이를 테면 LTE, 4G, 3G, CDMA, TDMA, 및 다른 셀룰러 전화 통신 기술들을 통해 달성될 수 있다. 그러한 양방향 무선 통신 링크들(115)은 사용자들로 하여금 수신기 디바이스들(예를 들어, 이동 디바이스들)에게 멀티미디어 컨텐츠를 스트리밍하게 할 수 있다.

[0119] 인터넷 데이터 통신들(예를 들어, 스트리밍 비디오 피드들(streaming video feeds))을 가능하게 하기 위해, 유니캐스트 네트워크(106)는 전형적으로, 인터넷(108)에 대한 접속을 제공하는 네트워크 오퍼레이션 센터(118)에 결합되거나 또는 네트워크 오퍼레이션 센터(118) 내에 있는 하나 이상의 서버들(120)을 포함할 것이다. 이동 수신기 디바이스들(102)은 또한, 이용가능한 경우 유선 접속(wired connection)을 통해 인터넷(108)에 접속될 수 있으며, 이 경우, 인터넷(108)이 유니캐스트 네트워크의 역할을 할 수 있다. 이동 수신기 디바이스들(102)은 또한, 잘 알려진 통상의 웹-기반의 액세스 프로토콜들을 이용하여 인터넷(108)을 통해 넌-브로드캐스트 컨텐츠를 수신할 수 있다.

[0120] 일반적으로, 수신기 디바이스(예를 들어, 상기 논의된 이동 수신기 디바이스들(102))에 의해 컨텐츠를 수신하고 렌더링하기 위한 동작들은, 개별적이고 독립적인 그룹들 또는 카테고리들의 동작들로 분할될 수 있으며, 그리고 동작들의 각각의 그룹 또는 카테고리는 층(예를 들어, 물리 층, 데이터 링크 층 등)에 할당될 수 있다. 이러한 층들 각각에서, 다양한 하드웨어 및/또는 소프트웨어 컴포넌트들이, 그 층에 할당된 책무들(responsibilities)에 상응하는 기능을 구현할 수 있다. 예를 들어, 미디어 스트림들(예를 들어, 브로드캐스트, 포인트-투-포인트 등)은 전형적으로 물리 층에서 수신되며, 물리 층은 무선 수신기, 버퍼들, 및 무선 주파수(RF) 신호 내의 심볼들을 복조하고, 인식하고, 수신된 RF 신호로부터 원시 데이터를 추출하기 위한 다른 동작들을 수행하는 프로세싱 컴포넌트들을 포함할 수 있다.

[0121] 도 2는 실시예에 따른, 컨텐츠를 수신하고 디스플레이하는데 적절한 이동 수신기 디바이스의 예시적인 프로토콜 스택(200)을 도시한다. 도 2의 도시된 예에서, 프로토콜 스택(200)은 물리 층(202) 모듈, 데이터 링크 층(204) 모듈, 네트워크 층(206) 모듈, 전송 층(208) 모듈, 및 애플리케이션 층(210) 모듈을 포함하며, 이들 각각은 하드웨어로, 소프트웨어로, 또는 하드웨어와 소프트웨어의 결합으로 구현될 수 있다. 또한, 모듈들(202-210) 각각은 서브-층들을 포함할 수 있으며, 이러한 서브-층들 또한 하드웨어로, 소프트웨어로, 또는 하드웨어와 소프트웨어의 결합으로 구현될 수 있다.

[0122] 물리 층(202) 모듈은, 기본적인 통신 신호를 수신하고, 통신 신호로부터 데이터를 추출하고, 그 데이터를 데이터 링크 층(204) 모듈 내의 미디어 액세스 제어 모듈 또는 미디어 전송 스트림(예를 들어, MPEG-2 전송 스트림)에 제공하도록 구성된 무선 컴포넌트들을 포함할 수 있다. 데이터 링크 층(204) 모듈은, 이동 수신기 디바이스의 다양한 컴포넌트들이 데이터의 상이한 스트림들을 수신할 수 있게 하는 어드레싱 및 채널 액세스 제어 메커니즘들(addressing and channel access control mechanisms)을 제공할 수 있다. 데이터 링크 층(204) 모듈은 또한, MPEG(Moving Picture Experts Group) TS(transport stream) 위에서 패킷 프로토콜(예를 들어, 인터넷 프로토콜)을 전달하기 위한 다양한 서브-모듈들 또는 서브-층들, 이를 테면 도시된 MPE-FEC(multiprotocol encapsulation forward error correction) 모듈/층 그리고 프로그램 및 시스템 정보(SI/PSI) 모듈/층을 포함할 수 있다.

[0123] 컨텐츠 및 정보 플로우들을 전달하는 스트림/신호의 부분들은 데이터 링크 층(204) 모듈에 의해 네트워크 층(206) 모듈로 전달될 수 있으며, 네트워크 층(206) 모듈은 스트림들, 데이터그램들 및/또는 패킷들을 전송 층(208) 모듈로 통신/릴레이(relay)하기 위한 IP 모듈/인터페이스를 포함할 수 있다. 전송 층(208) 모듈에서 수신된 스트림들 및 데이터는, 전송을 위해 데이터를 프로세싱하고 패키징하는 적절한 전송 층 서브-모듈들 또는 서브-층들에 전달될 수 있다. 그러한 전송 층 서브-모듈들/서브-층들은 UDP(user datagram protocol) 모듈/층, ALC/LCT(asynchronous layered coding/layered coding transport) 모듈/층, RTP(real-time transport protocol) 모듈/층, 및 FLUTE(file delivery over unidirectional transport) 모듈/층을 포함할 수 있다. 실시예에서, RTP 모듈/층은, DASH 포맷들과 유사하게, 애플리케이션 층(210)에 포함되거나 애플리케이션 층(210)의 부분일 수 있다.

[0124] 애플리케이션 층(210) 모듈은, 호스트-투-호스트(host-to-host), 엔드-투-엔드(end-to-end) 접속들을 설정하고 프로세스-투-프로세스(process-to-process) 통신들을 수행하기 위해 요구되는 방법들 및 프로토콜들을 포함할 수 있다. 애플리케이션 층(210) 모듈은 또한, 이동 수신기 디바이스 상에 수신된 컨텐츠를 프로세싱하고, 렌더링하고 및/또는 디스플레이하기 위한 최종-사용자(end-user) 애플리케이션들(예를 들어, 미디어 플레이어 등)을 포함할 수 있다. 애플리케이션 층은 또한, 미디어 포맷들, 이를 테면 DASH 포맷들, 인코딩된 미디어 스트림들 및 다른 미디어 관련 메타데이터를 포함할 수 있다. 도 2에 도시된 예에서, 애플리케이션 층(210) 모듈은 DASH 모듈, RTP 모듈 및 미디어 플레이어 모듈을 포함한다.

[0125] 도 3a는 이동 수신기 디바이스들에게 멀티미디어 컨텐츠를 전달하는 데에 적합한 브로드캐스트 통신 시스템(300)의 실시예의 다양한 논리 및 기능 컴포넌트들을 도시한다. 도 3a에 도시된 예에서, 브로드캐스트 통신 시스템(300)은 개선된 오브젝트 순방향 에러 정정 컴포넌트(302), 개선된 오브젝트 시그널링 컴포넌트(304), 및 개선된 오브젝트 전달 컴포넌트(306)를 포함한다. 멀티미디어 컨텐츠는 가변-크기 오브젝트들(Obj)로 인코딩되며, 이러한 가변-크기 오브젝트들은 3개의 상이한 오브젝트 플로우들(오브젝트 플로우 1, 2 및 3)을 통해 브로드캐스팅된다. 각각의 오브젝트 플로우(오브젝트 플로우 1, 2 및 3)는 개선된 오브젝트 전달 컴포넌트(306)를 포함하거나 또는 개선된 오브젝트 전달 컴포넌트(306)와 관련된다. 가변-크기 오브젝트들(Obj) 각각은 최대(full) 오브젝트일 수 있거나, 또는 오브젝트의 부분(예를 들어, 바이트 범위 등)일 수 있다.

[0126] 다양한 실시예들에서, 개선된 오브젝트 순방향 에러 정정 컴포넌트(302), 개선된 오브젝트 시그널링 컴포넌트(304), 및 개선된 오브젝트 전달 컴포넌트(306) 중 임의의 것 또는 전부는 하드웨어로, 소프트웨어로, 또는 하드웨어와 소프트웨어의 결합으로 구현될 수 있다.

[0127] 개선된 오브젝트 전달 컴포넌트(306)는, 전달 레벨 상에서 오브젝트들(Obj) 간의 플로우-연관성(flow-association)을 설정하거나 식별하고, 패킷 레벨 상의 오브젝트들 또는 데이터에 타임스탬프들을 추가하고, 청크형(chunked) 전달 동작들(chunked delivery operations)을 수행하고, 오브젝트들(Obj)을 소스 패킷들로 패킷화(packetizing)하거나 프래그먼트화(fragmenting)하고, 그리고 다양한 다른 유사한 동작들을 수행하는 것을 포함하는 다양한 오브젝트 전달 동작들을 수행하도록 구성될 수 있다.

[0128] 개선된 오브젝트 시그널링 컴포넌트(304)는 다양한 시그널링 동작들, 이를 테면, 오브젝트 플로우들(오브젝트 플로우 1, 2 및 3)에 시그널링 정보를 패키징 및 송신하고, HTTP 서버/프록시/캐시 복제(replication)를 달성하고, 그리고 HTTP 오브젝트들에 대한 "이용가능성 타이밍(availability timing)" 정보를 전달하는 것을 수행하도록 구성될 수 있다. 예를 들어, 개선된 오브젝트 시그널링 컴포넌트(304)는, 해당 오브젝트가 전달될 때에 HTTP 오브젝트의 이용가능성 타이밍 정보를 시그널링하도록 구성될 수 있다. 이는, 브로드캐스트를 통해 오브젝트들을 전달할 때 브로드캐스트 통신 시스템(300)이 타임아웃(time-out) 동작들을 수행할 수 있게 허용한다. 그러한 이용가능성 타이밍 정보의 전달은 또한, 브로드캐스트 통신 시스템(300)으로 하여금, 캐시 타임아웃 정책(cache time-out policy)과 유사한 특징들을 구현할 수 있게 하는 바, 여기에서는, 캐시 내에 저장된 아이템들만이 제한된 지속기간 동안 컴퓨팅 시스템에 대해 이용가능하게 되고 및/또는 특정 지속기간 또는 시간 기간 이후 타임아웃된다. 이러한 방식으로, 브로드캐스트 통신 시스템(300)은, 데이터, 오브젝트들(Obj), 및/또는 소스 패킷들이 항상 현재 및/또는 최신의(up-to-date) 정보를 포함하도록 보장할 수 있다.

[0129] 개선된 오브젝트 시그널링 컴포넌트(304)는 또한, 수신기 디바이스에게 시그널링 정보를 제공하도록 구성될 수 있으며, 이러한 시그널링 정보는, 언제 그리고 어떻게 하나 이상의 오브젝트들(Obj)이 수신기 디바이스에 전달될지를 식별하는 다양한 정보 필드들을 포함할 수 있다. 다양한 실시예들에서, 그러한 정보는, 해당 오브젝트 또는 패킷들이 수신기 디바이스에 의해 수신되거나 서버에 의해 전송되기 전에, 브로드캐스트 세션을 통해 수신기 디바이스에 전달될 수 있다.

[0130] 개선된 오브젝트 순방향 에러 정정 컴포넌트(302)는, 오브젝트들의 소스 플로우들에 대한 FEC 보호를 제공하는 것; 오브젝트들의 번들들에 대한 FEC 보호를 제공하는 것; 개별적인 오브젝트들의 부분들에 대한 FEC 보호를 제공하는 것; 및 FEC 시맨틱스, 코드들, 로직, 지원 또는 동작들과는 독립적으로 소스 오브젝트들의 전달을 허용하는 것을 위한 동작들을 포함하는 다양한 에러 정정 동작들을 수행하도록 구성될 수 있다. 실시예에서, 개선된 오브젝트 순방향 에러 정정 컴포넌트(302)는, FEC 시맨틱스들과는 독립적으로 번들들의 개별적인 소스 오브젝트들을 전달하는 한편, 그와 동시에 소스 오브젝트들의 번들들에 대한 FEC 보호를 제공하도록 구성될 수 있다.

[0131] 실시예에서, 개선된 오브젝트 순방향 에러 정정 컴포넌트(302)는, 동일하거나 상이한 플로우들 또는 스트림들에서 오브젝트들의 부분들을 보호하기 위해 전송 소스 오브젝트들의 바이트 범위들(및 바이트 범위들의 결합들)에 대한 FEC 보호를 제공하도록 구성될 수 있다. 이것은, 수신기 디바이스가, 오브젝트가 수신됨에 따라 증분적으로 오브젝트를 렌더링하기 위한 FEC 디코딩 동작들을 수행하도록 허용한다. 이것은, 전체 오브젝트에 대해 FEC 인코딩이 수행되고, 일반적으로, 그 오브젝트를 렌더링하기 위한 FEC 디코딩 동작들을 수행하기 전에 전체 오브젝트가 수신될 때까지 수신기 디바이스가 대기하도록 요구하는 기존 솔루션들과 대조적이다.

[0132] 실시예에서, 개선된 오브젝트 순방향 에러 정정 컴포넌트(302)는 소스 오브젝트들의 플로우들에 대한 FEC 보호를 제공하도록 구성될 수 있다. 개선된 오브젝트 순방향 에러 정정 컴포넌트(302)는, FLUTE-기반 전달 시스템들을 포함하는 임의의 오브젝트 기반 전달 시스템에서 소스 오브젝트들의 플로우에 대한 FEC 보호를 제공할 수 있다. 또한, 개선된 오브젝트 순방향 에러 정정 컴포넌트(302), 개선된 오브젝트 시그널링 컴포넌트(304) 및/또는 개선된 오브젝트 전달 컴포넌트(306)는, 기존 FLUTE 표준들 및 솔루션들을 구현하거나 이들의 서브세트일 수 있다. 추가로, 이러한 컴포넌트들(302, 304, 306) 중 임의의 것 또는 전부는, 오브젝트들의 스트림들 또는 플로우들이 FLUTE 컨텍스트 내에서 더 효율적으로 전달되고 기존 FLUTE 표준들을 준수하도록 허용하기 위해 FLUTE 기능(예를 들어, 도 2를 참조하여 앞서 논의된 FLUTE 서브-층에 의해 제공되는 기능 등)을 확장할 수 있다.

[0133] 현재 FLUTE 솔루션들(세그먼트들의 DASH 시퀀스들의 전달을 위한 3GPP MBMS에서 특정됨)에 의해 제공되는 것과 같은 기존 브로드캐스트 오브젝트-기반 스트리밍 전달 솔루션들은, 패킷-기반 스트리밍 솔루션들에 의해 제공되는 많은 특징들 및 기능이 부족하다. 따라서, 많은 기존 스트리밍 솔루션들은 오브젝트-기반이 아니지만, 그 대신, RTP/IP, MPEG2 전송 스트림(TS) 또는 다른 유사한 기술들을 통해 패킷 스트림들을 전달하는 패킷-기반 솔루션들이다. 이러한 패킷-기반 스트리밍 솔루션들에서 FEC가 이용되는 경우, 패킷들은 통상적으로 소스 블록들로 파티셔닝되고, FEC 복구 보호는 이러한 소스 블록들 각각에 대해 개별적으로 제공된다. 이러한 이유 및 다른 이유로, 기존 패킷-기반 스트리밍 솔루션들은, 스트림의 부분들을 (예를 들어, 통합 자원 식별자(URI)로) 명명 및 식별하는 능력이 부족하고, 일반적으로 DASH와 같은 오브젝트-기반 스트리밍 솔루션들에 의해 제공되는 많은 유리한 특징들이 부족하다.

[0134] 실시예에서, 브로드캐스트 통신 시스템(300)은, 기존 패킷-기반 스트리밍 시스템들에 의해 제공되는 기능 및 기존 브로드캐스트 오브젝트-기반 스트리밍 시스템들에 의해 제공되는 기능들의 결합인 기능을 제공하도록 구성될 수 있다. 즉, 기존 스트리밍 솔루션들과는 반대로, 브로드캐스트 통신 시스템(300)은, 기존 FLUTE-기반 솔루션들 및 시스템들과 호환성을 유지하고 이러한 통신들을 브로드캐스팅을 통해 달성하면서, 기존 패킷-기반 스트리밍 솔루션들 및 브로드캐스트 오브젝트-기반 스트리밍 솔루션들의 특징들을 결합하는(그리고 이를 넘어서는 추가적인 특징들을 제공하는) 기능을 달성할 수 있다.

[0135] 일반적으로, 패킷-기반 스트리밍 시스템들은, 패킷들이 전달, 패키지 또는 인코딩하는 소스 컨텐츠의 특성들에 매칭하도록 개별적인 패킷들을 생성할 수 있다. 예를 들어, 소스 컨텐츠가 비디오 스트림인 경우, 패킷-기반 스트리밍 시스템은, 비디오 데이터 또는 슬라이스 또는 네트워크 추상 층 유닛의 하나의 프레임을 포함하도록 각각의 소스 패킷을 생성할 수 있다. 이것은, 각각의 비디오 프레임 또는 각각의 슬라이스 또는 액세스 유닛 또는 네트워크 추상 층 유닛이 시스템에 이용가능하게 될 때, 패킷-기반 스트리밍 시스템이 이를 즉시 송신하도록 허용하고, 이것은, 일부 환경들 또는 네트워크들에서 네트워크 레이턴시를 감소시킬 수 있다. 또한, 패킷-기반 스트리밍 시스템들은 통상적으로 각각의 샘플에 대한 매우 정밀한 타이밍을 달성하고, 이는 또한 일부 환경들 또는 네트워크들에서 유리하다.

[0136] 기존 브로드캐스트 오브젝트-기반 스트리밍 시스템들은, 큰 샘플들 또는 오브젝트들을 전달하기에는 패킷-기반 스트리밍 시스템들보다 더 적절하지만, 세그먼트/오브젝트가 송신되기 전에, 세그먼트 또는 오브젝트에 포함되는 정보 전부가 IP 네트워크를 통한 통신을 위해 이용가능하게 되는 것을 요구한다. 즉, 기존 브로드캐스트 오브젝트-기반 스트리밍 시스템들은, 소스 오브젝트가 서버에 이용가능하게 될 때, 그 서버가 소스 오브젝트에 대한 컨텐츠를 송신하기 시작하도록 허용하지 않는다. 오히려, 기존 브로드캐스트 오브젝트-기반 스트리밍 시스템들은, 서버가 DASH 세그먼트(또는 소스 오브젝트)에 대한 패킷들을 수신기 디바이스들에 송신하는 것을 시작할 수 있기 전에, 그 DASH 세그먼트, 또는 일반적으로 소스 오브젝트에 대한 정보 전부가 수신되거나 서버에 이용가능하게 될 때까지 서버가 대기하도록 요구한다. 또한, 기존 브로드캐스트 오브젝트-기반 스트리밍 시스템들은 개별적인 샘플들/세그먼트들/오브젝트들에 대한 정밀한 타이밍 요건들을 충족하기에 매우 적절하지는 않고, 따라서 일부 환경들 또는 네트워크들에서는 네트워크 레이턴시 및 지터에 취약하다.

[0137] 다양한 실시예들은, 기존 FLUTE-기반 솔루션들 및 시스템들과의 호환가능성을 유지하면서, 정보가 서버에 이용가능하게 될 때 샘플들 또는 오브젝트들을 효율적으로 브로드캐스팅하고, 각각의 샘플/오브젝트에 대한 매우 정밀한 타이밍을 달성하도록 구성되어, 기존 패킷-기반 스트리밍 시스템들에 의해 제공되는 기능 및 기존 브로드캐스트 오브젝트-기반 스트리밍 시스템들에 의해 제공되는 기능들의 하이브리드/결합을 달성하도록 구성되는 브로드캐스트 통신 서버를 포함할 수 있다. 예를 들어, 브로드캐스트 통신 서버는, 데이터가 서버에 이용가능하게 될 때 이러한 데이터를 파일에 포함하고, 파일을 즉시 브로드캐스팅하는 것을 시작하여, 데이터가 서버에 이용가능하게 될 때 (즉, 서버가 파일에 포함될 데이터 전부를 수신하기 전에) 데이터가 네트워크에 이용가능해지도록 구성될 수 있다. 또한, 브로드캐스트 통신 서버는 FLUTE 레벨에서 각각의 파일/패킷에 타이밍 정보를 추가할 수 있다. 이러한 타이밍 정보는 네트워크의 지터를 측정하고 다른 유사한 동작들을 수행하기 위해 이용될 수 있다. 지터 측정 및 지터 보상은, 버퍼들을 디멘셔닝하고 저-레이턴시 동작들을 보장하기 위해 이용될 수 있다.

[0138] 기존 FLUTE 시스템들은, 시그널링 정보를 통신하기 위해 파일 전달 테이블들(FDT들)을 이용한다. FDT는, 순방향 에러 정정 오브젝트 전송 정보(FEC OTI), 통합 자원 식별자(URI), 패킷에 포함된 오브젝트 정보를 식별하는 전송 오브젝트 식별자(TOI), 및 오브젝트에 대한 전송 세션/스트림 식별자(TSI)를 포함할 수 있다.

[0139] 순방향 에러 정정 오브젝트 전송 정보(FEC OTI)는, 특정 FEC 코딩 방법을 식별하는 "FEC 인코딩 ID"를 포함할 수 있다. 또한, FEC OTI는 다양한 파라미터들, 예를 들어, 바이트 범위 또는 오브젝트/파일 크기(F), 바이트 오프셋을 식별시키는 정렬 팩터(Al), 심볼 크기(T), 오브젝트의 소스 블록들의 수(Z), 및 그 오브젝트에 대해 각각의 소스 블록이 파티셔닝되는 서브-블록들의 수(N)를 포함할 수 있다.

[0140] 다양한 실시예들에서, 각각의 오브젝트는 순방향 에러 정정 오브젝트 전송 정보(FEC OTI) 및/또는 상이한 통합 자원 식별자들(URI들)을 포함할 수 있다. 파일 전달 테이블(FDT)은 전송 오브젝트 식별자(TOI)를, FDT에 포함된 다른 정보, 예를 들어, URI, FEC OTI, 및 다른 오브젝트 전송 파라미터들에 링크할 수 있다. 전송 세션/스트림 식별자(TSI)는 TOI를 스코핑(즉, 식별 및 그에 대한 컨텍스트를 제공)하여, 다수의 오브젝트들이 동일한 세션에서 전달되고 상이한 TOI들을 갖도록 허용할 수 있다. TSI 및 TOI의 결합은 오브젝트를 고유하게 식별할 수 있다. 오브젝트 시퀀스 번호(OSN)는 TOI에 맵핑될 수 있고, 그 반대일 수도 있다. TSI는 FLID에 맵핑될 수 있다.

[0141] 파일 전달 테이블(FDT)은 정적 및 동적 정보 둘 모두를 포함할 수 있다. 예를 들어, 전송 오브젝트 식별자들(TOI들), URI들, 컨텐츠 타입 및 바이트 범위 또는 오브젝트/파일 크기(F) 값들은, 오브젝트마다 변하는 동적 정보를 포함할 수 있다. FEC 인코딩 ID, 전송 세션/스트림 식별자(TSI), 정렬 팩터(Al), 심볼 크기(T), 소스 블록들의 수(Z), 및 서브-블록들의 수(N)에 대한 값들은 모두, 다수의 오브젝트들에 걸쳐 또는 오브젝트들의 시퀀스에 걸쳐 고정되는 정적 정보를 포함할 수 있다. 이러한 값들은, 예를 들어, 모든 오브젝트들에 대해 값들 Z=1, N=1 및 고정된 Al 및 FEC 인코딩 ID 값들을 이용함으로써, 관련된 오브젝트들(또는 오브젝트들의 컬렉션)의 전체 시퀀스에 대해 한번 제공될 수 있다. 그러나, 기존 솔루션들을 이용하면, 시그널링 정보는, 스트림의 다수의 오브젝트들에 걸쳐 공유되는 정적 필드들의 수와 무관하게, 브로드캐스팅되는 각각의 오브젝트에 대해 (FDT를 브로드캐스팅하는 것을 통해) 전송되어야 한다.

[0142] 오브젝트들의 스트림을 전달하는 경우, TOI 및 URI 값들은 관련된 오브젝트들의 스트림에 걸쳐 예측될 수 있는 한편, 오브젝트/파일 크기(F)는 통상적으로 예측가능하지 않다. URI 정보는, URI를 생성하기 위한 템플릿 및 TOI를 이용함으로써 템플레이팅을 통해 전달될 수 있다.

[0143] 앞서 논의된 값 필드들 이외에도, 기존 FLUTE-기반 솔루션들에서, 각각의 패킷은 FEC 페이로드 ID를 포함한다. FEC 페이로드 ID는 패킷 페이로드에 대한 정보를 제공하고, 소스 블록 번호(SBN) 및 인코딩 심볼 식별자(ESI)를 포함할 수 있다. FEC 페이로드 ID는, 패킷이 소스 데이터를 포함하는지 또는 복구 데이터를 포함하는지와 무관하게, 특정 FEC 방법 또는 시스템에 특정되는 정보를 포함할 수 있다. 이러한 이유들로, FEC 인코딩 ID는, FLUTE를 통해 오브젝트에 대한 소스 데이터를 전달하는 경우, 기존 시스템들에 의해 요구된다.

[0144] 다양한 시스템들은, FEC 시맨틱스들, 예를 들어, FEC 인코딩 ID 데이터-필드 또는 값을 포함함이 없이, FLUTE를 통해 오브젝트에 대한 소스 데이터를 전달하도록 구성되는 브로드캐스트 서버들을 포함할 수 있다. 다양한 실시예들은 또한, FEC 시맨틱스들을 포함하지 않는 오브젝트들을 수신, 디코딩 및 이용하도록 구성되는 수신기 디바이스들을 포함할 수 있다.

[0145] 기존 FLUTE 솔루션들은, 단일 오브젝트 플로우 또는 통신 채널에 포함되는 다수의 오브젝트들 간의 관계를 설정하는 것을 지원하지 않는다. 기존 솔루션들을 이용하면, 오브젝트에 대한 FDT에 포함될 수 있는 정적 및 동적 정보 전부는 각각의 오브젝트에 대해 개별적으로 수신기 디바이스에 전달되어야 한다. 또한, 적어도 하나의 FDT는 일반적으로, 오브젝트 자체가 전달되는 경우, 오브젝트에 대한 FDT 내에서 전달되는 정보의 일부만이 통상적으로 이용가능할 때, 스트림에서 각각의 오브젝트에 대해 전달되어야 한다. 이러한 정보는, 정보에 대한 실제 또는 잠재적인 변화들이 존재하는지와 무관하게, 그리고 다수의 오브젝트들에 대해 또는 스트림의 모든 오브젝트들에 걸쳐 동일한 정보가 이용될 수 있는지와 무관하게, 각각의 오브젝트에 대해 FDT 내에서 전달되어야 한다. 또한, FEC 시맨틱스이고, 오브젝트와 함께 전달되는 각각의 패킷의 컨텐츠에 대한 정보를 제공하는 FEC 페이로드 ID는 통상적으로 FEC 특정적이고 모든 인스턴스들에서 요구되는 것은 아니다. 동일한 정보, 수신기 디바이스에 의해 요구 또는 이용되지 않는 정보, 또는 다수의 오브젝트들에 걸쳐 공유될 수 있는 정보를 반복적으로 브로드캐스팅하는 것은, 기존 시스템들에서 수행되는 바와 같이, 네트워크 자원들의 비효율적 이용이다.

[0146] 다양한 실시예들은, 단일 플로우, 스트림 또는 통신 채널에서 관련된 오브젝트들을 브로드캐스팅하도록 구성되는 브로드캐스트 통신 서버를 포함할 수 있어서, 시그널링 정보(예를 들어, FDT 파라미터들)는 플로우의 다수의 오브젝트들에 걸쳐 공유될 수 있다. 이것은, 네트워크를 통해 통신되는 정보의 양을 감소시키고, 네트워크 자원들(예를 들어, 대역폭 등)의 더 효율적인 이용이고, 수신기 디바이스들에 정보를 전달하기 위한 기존 솔루션들보다 더 신뢰가능하다.

[0147] 다양한 실시예들은 또한, 관련된 오브젝트들의 시퀀스를 브로드캐스팅하도록 구성되는 브로드캐스트 통신 서버를 포함할 수 있다. 실시예에서, 오브젝트들 간의 관계들은 TOI 필드를 통해 식별될 수 있고, 이는, TOI 필드를 2개의 서브-필드들, 즉, 관련된 오브젝트들의 플로우를 식별하는 플로우 ID(FLID) 서브-필드; 및 관련된 소스 오브젝트들의 플로우 내에서 각각의 소스 오브젝트를 식별하는 오브젝트 시퀀스 번호(OSN) 서브-필드로 분할함으로써 달성될 수 있다. 실시예에서, OSN은 TOI 필드에 맵핑될 수 있다. TOI는 이러한 방식으로 분할될 수 있는데, 그 이유는, FLUTE 표준들이 TOI 필드에 대한 엄격한 구조를 정의하지 않고, 따라서 그에 포함된 각각의 번호가 상이한 오브젝트 또는 필드에 대해 이용될 수 있기 때문이다. 추가로, 기존 TOI 필드들이 통상적으로 사(4) 바이트의 정보를 저장하기 때문에, TOI 필드들은, 이들과 기존 시스템들과의 역호환성에 영향을 미치지 않으면서 일(1) 바이트 FLID 파라미터 서브-필드 및 삼(3) 바이트 OSN 파라미터 서브-필드로 분할될 수 있다.

[0148] 실시예에서, FLID는 일(1) 바이트 파라미터일 수 있고, 이는, 시스템이 각각의 세션에 대해 256개의 상이한 FLID들을 지원하도록 허용한다. 실시예에서, 제로(0) 값은 FLID 서브-필드에 대한 허용가능한 또는 지원되는 값으로서 제외되어, 일부 시스템들에서 FDT 오브젝트 전달에 대해 예비될 수 있는 제로(0)의 TOI 값과의 혼동을 회피하게 할 수 있다.

[0149] 실시예에서, TOI는 4-바이트 값일 수 있고, 값 범위(예를 들어, 128-255 등)는 TOI의 FLID 서브-필드에 대한 이용을 위해 예비되어, 동일한 세션 내에서 기존 FLUTE 솔루션들을 이용한 오브젝트들의 전달을 허용할 수 있다. 예를 들어, TOI를 서브-필드들로 분할하지 않고 FDT를 이용하는 솔루션들은, 이용되는 TOI 값들을 범위 0 내지 128*256*256*256 - 1 = 2147483647로 제한할 수 있다(제 1 이용의 경우). 한편, 4-바이트 TOI를 1-바이트 FLID 및 3-바이트 OSN으로 분할하는 솔루션들은, 이용되는 FLID 값들을, 3-바이트 OSN 값들의 범위에 대한 임의의 추가적인 제한없이 범위 128 내지 255로 제한할 수 있다(제 2 이용의 경우). 연접되는 경우, 1-바이트 FLID 및 3-바이트 OSN은, 128*256*256*256 내지 256*256*256*256-1의 범위의 4-바이트 TOI 정수 값(또는 동등하게, 2147483648 내지 4294967295의 TOI 정수 값 범위)을 형성한다. 이것은, 앞서 논의된 2개의 이용 경우들에 대해 이용되는 4-바이트 TOI 값들의 전체 범위가 분리되는 것을 보장한다. 이것은, FLUTE 브로드캐스트 전달 시스템이, TOI를 분할하지 않고 FDT들을 이용하는 오브젝트들(앞서 설명된 제 1 이용의 경우, 기존 FLUTE 솔루션) 및 TOI를 분할하고 FDT들을 이용하지 않는 오브젝트들(앞서 설명된 제 2 이용의 경우)을 동일한 세션에서 전달하도록 허용한다. 설명된 바와 같이, 이것은, 전체 TOI 값들의 범위를, 2개의 상이한 이용 경우들에 대해 교차하지 않는 범위들로 파티셔닝함으로써 달성될 수 있고, 이것은, 동일한 세션에서 2개의 이용 경우들에 대한 충돌하는 TOI들의 가능성을 제거한다.

[0150] 실시예에서, 전송 세션/스트림 식별자(TSI)는 플로우 ID(FLID)로 이용될 수 있다.

[0151] 다양한 실시예들의 FLID 서브-필드에 의해 식별되는 것과 같은 관련된 오브젝트들의 플로우는 DASH 표현에서 비디오 세그먼트들의 스트림에 대응할 수 있다. 예를 들어, 이러한 표현에서 전달되는 각각의 오브젝트는 동일한 FLID(예를 들어, FLID = 1)를 가질 것이고, 따라서 동일한 FLID를 갖는 패킷들은, 다양한 실시예의 서버들 및 수신기 디바이스들에 의해, 오브젝트들의 동일한 플로우에 속하는 오브젝트들로 취급될 수 있다. 다른 플로우는, 예를 들어, DASH 미디어 프리젠테이션의 오디오 데이터일 수 있다.

[0152] 동일한 플로우의 오브젝트들에 속하고 따라서 동일한 FLID 값을 갖는 오브젝트들은 OSN 서브-필드를 통해 식별될 수 있다. OSN 서브-필드는 제 1 오브젝트에 대해 제로(0)의 값에서 시작하고 플로우 내의 각각의 후속 소스 오브젝트에 대해 일(1)만큼 증분되는 간단한 정수를 저장할 수 있다. 실시예에서, OSN은 삼(3) 바이트 파라미터일 수 있고, 이것은, 초 당 하나의 오브젝트의 오브젝트 전달 레이트에서, 별개의 OSN 값들의 대략 200 일들을 허용한다.

[0153] TSI는 FLID 서브-필드를 스코핑할 수 있고, 이것은 OSN 서브-필드를 스코핑할 수 있다. 즉, TSI 값은 동일한 FLID 값을 갖는 2 개의 오브젝트들을 사이를 구별하기 위한 충분한 컨텍스트를 제공할 수 있고, FLID 값은 동일한 OSN 값을 갖는 2 개의 오브젝트들 간을 구별하기 위한 충분한 컨텍스트를 제공할 수 있다.

[0154] 실시예에서, 시스템은 FLID 값으로서 TSI를 사용하도록 구성될 수 있다. 다양한 실시예들에서, TSI 필드는 DASH 표현으로 맵핑될 수 있고, 그 반대도 가능하다.

[0155] 다양한 실시예들에 따라 TOI 필드를 2개의 서브-필드들(즉, FLID 및 OSN)로 분할함으로써, 브로드캐스트 네트워크는 소스 플로우들에 대한 FDT들을 브로드캐스팅할 필요가 없다. 대신에, 브로드캐스트 네트워크는 (즉, 플로우 내의 각각의 오브젝트가 아닌) 각각의 수신기에 대해 그리고 각각의 플로우에 대해 단일 소스 플로우 선언(FLUTE 메타데이터에 포함될 수 있음)을 브로드캐스팅할 수 있다.

[0156] 소스 플로우 선언은 오브젝트 플로우 및/또는 오브젝트 플로우에 포함된 패킷들의 오브젝트들에 관련된 다양한 정보 필드들 및 값들의 간결한 표현일 수 있다. 소스 플로우 선언은 오브젝트 시퀀스 번호들과 오브젝트들 간의 관계들을 식별할 수 있다. 소스 플로우 선언은 메타데이터 레벨에서 플로우를 선언할 수 있다. 이것은 다양한 정보 필드들 및 값을 FLUTE 메타데이터에 포함시킴으로써 달성될 수 있다. 소스 플로우 선언은, 플로우 내의 소스 패킷들 및 그 플로우에 대한 다른 정적 정보를 식별하는 고유한 플로우 식별자(FLID)를 포함할 수 있다. 소스 플로우 선언은 또한 플로우의 타입(예를 들면, 비디오 오브젝트 플로우, 오디오 오브젝트 플로우 등)에 관련된 정보를 포함할 수 있다. 소스 플로우 선언은 플로우 내의 오브젝트들의 MIME(Multipurpose Internet Mail Extensions) 타입을 식별하고, 다른 유사한 정보를 포함할 수 있다. 실시예에서, 소스 플로우 선언은 (즉, 오브젝트들이 암호화된 경우에) 플로우에서 오브젝트들을 암호해독하는데 사용하기에 적절한 암호해독 키의 표시 및/또는 암호해독 키들의 시퀀스를 포함할 수 있다.

[0157] 소스 플로우 선언은 FLUTE를 사용하는 MBMS 전달의 경우에 USD(user service description)로 전달될 수 있다. 소스 플로우 선언은 FLUTE 수신기 또는 수신기 디바이스에 가장 관련된 시그널링 정보를 통신할 수 있다. 소스 플로우 선언은 오브젝트들 전달의 플로우들에 관련된 정보를 미리 대역외에서 수신기 디바이스들에 제공할 수 있다.

[0158] 실시예에서, 소스 플로우 선언은 다음과 같이 서버 또는 수신기 디바이스들에서 선언 또는 표현될 수 있다.

[0159] 플로우 선언의 위의 예에서, 플로우의 타입은 플로우_타입 데이터 필드의 값, 이러한 경우 "소스"에 의해 표시되고, 이러한 플로우에 대한 플로우 식별자는 FLID 데이터-필드의 값, 이러한 경우 "5"에 의해 표시되고, 플로우의 오브젝트들에서 전달되는 컨텐츠 타입은 소스_타입 데이터 필드의 값, 이러한 경우 "비디오"에 의해 표시된다. 일반적으로, 플로우_타입 및 FLID는 플로우_선언 내에서 선언되도록 요구되고, 반면에 다른 정보는 플로우_선언에 포함될 수 있거나 포함되지 않을 수 있다.

[0160] 대안으로서, 기존 필드들은 플로우 식별자(FLID)를 사용하여 시그널링 및 지원하는데 사용될 수 있고, 이러한 경우에, TOI(Transport Object Identifier) 시그널링 및 사용은, 시그널링 또는 프로토콜들에 대한 다른 수정들 없이, 별개로 정의된 OSN 대신에, 전송 오브젝트를 식별하는데 사용될 수 있다. 예를 들면, LCT 헤더 내의 기존의 코드 포인트 필드는 (코드 포인트 필드의 다른 사용들 이외에도) FLID를 시그널링하는데 사용될 수 있고, 기존의 TOI 필드는, 새롭게 정의된 OSN을 사용하는 대신에, 전송 오브젝트 식별자를 시그널링하기 위해 수정되지 않고 남겨질 수 있다.

[0161] 다양한 실시예들은, FEC들 또는 FEC 시맨틱스에 대한 어떠한 의존성들도 포함하지 않는 소스 패킷들이 청크 전달을 가능하게 하고, 오브젝트들이 완전히 이용가능하기 전에 오브젝트들을 전송하는 것을 가능하게 하고, 소스 오브젝트들을 가변 크기 패킷들에 패키징하는 것(예를 들면, 근본적인 미디어의 각각의 액세스 유닛의 전달)을 지원하도록 소스 오브젝트들을 소스 패킷들로 패키징하도록 구성된 브로드캐스트 서버를 포함할 수 있다.

[0162] 실시예에서, 소스_타입 데이터 필드 또는 값은 대응하는 오브젝트 플로우의 MIME 타입에 의해 대체될 수 있다.

[0163] 실시예에서, 소스 패킷들은, 패킷에서 전달된 제 1 소스 오브젝트 바이트의 바이트 오프셋을 포함하는 소스 페이로드 ID 데이터 필드 및 값을 포함하도록 생성될 수 있다. 소스 패킷들은 또한, 소스 오브젝트의 바이트들이 패킷 내에 순차적으로 저장되고, 종료 바이트 위치가 패킷 페이로드의 크기에 의해 추론될 수 있도록 생성될 수 있다. 실시예에서, 소스 페이로드 ID는 사(4) 바이트 파라미터일 수 있다. 실시예에서, FEC 복구 효율을 개선하기 위해, 브로드캐스트 시스템은 각각의 소스 패킷 내의 바이트들의 수와 FEC 심볼들의 크기를 맞출 수 있다. 실시예에서, 소스 패킷은 또한 코드 포인트를 포함하도록 생성될 수 있고, 코드 포인트는 소스 오브젝트의 바이트 범위들 또는 부분들에 대한 라벨링 정보 및/또는 FEC 코딩 정보를 포함할 수 있다.

[0164] 이러한 방식으로 소스 오브젝트들을 소스 패킷들에 패키징함으로써, 다양한 실시예들은 FEC 동작들 또는 시맨틱스와 상관없이 소스 오브젝트들의 전달을 허용할 수 있다. 추가로, 소스 오브젝트들이 FEC 동작들과 독립적이도록 소스 오브젝트들을 패키징함으로써, 송신기는 필요한 경우에 상이한 FEC 방법들을 동일한 소스 오브젝트에 적용할 수 있다.

[0165] 게다가, 소스 오브젝트들이 FEC 동작들과 독립적이도록 소스 오브젝트들을 패키징함으로써, 다양한 실시예들은 송신기(즉, 서버)가 제 1 버전의 FEC 보호를 생성하기 위해 소스 플로우 또는 플로우들의 결합들을 보호하는 복구 플로우를 생성하기 위해 FEC 보호 방법들을 적용하도록 허용할 수 있고, 여기서 각각의 FEC 인코딩은 불량한 수신 조건들에서 수신기들로의 전달 또는 브로드캐스트 세션만을 기록하고 따라서 가능한 가장 높은 충실도 복원을 원하는 수신기들에 적절한 플로우의 다수의 오브젝트들 또는 플로우들의 결합들, 및 제 2 버전의 FEC 보호를 생성하기 위해 동일한 플로우 또는 플로우들의 결합들을 보호하는 다른 복구 플로우에 대해 적용되고, 여기서 각각의 FEC 인코딩은 제 1 버전보다 플로우 또는 플로우들의 결합들의 더 적은 오브젝트들에 대해 적용되고, 이것은 모든 다른 수신기들로의 전달에 적절한 더 짧은 엔드-투-엔드 레이턴시를 제공하고 및/또는 세션에 참여할 때 미디어 스트림에 대한 더 빠른 액세스를 허용할 수 있다. 예를 들면, 제 1 버전의 FEC 보호는, 각각의 FEC 인코딩이 소스 플로우로부터의 한 쌍의 연속적인 소스 오브젝트들에 적용되는 제 1 복구 플로우일 수 있고, 제 2 버전의 FEC 보호는 각각의 FEC 인코딩이 동일한 소스 플로우로부터의 단일 소스 오브젝트에 적용되는 제 2 복구 플로우일 수 있다.

[0166] 다양한 실시예 브로드캐스트 시스템들은 다수의 소스 오브젝트 시그널링 개선들을 제공하도록 구성될 수 있다. 기존 시스템들은, 소스 오브젝트의 모든 패킷들이 수신되는지/수신되는 때 및/또는 소스 오브젝트의 길이/크기를 결정하기 위해 FEC 시맨틱스를 사용한다. 다양한 실시예들은, FEC 시맨틱스를 포함하는 패킷들 모두를 사용 또는 요구하지 않고서, 수신기 디바이스가 소스 오브젝트의 모든 패킷들이 수신되는지 또는 수신되는 때, 소스 오브젝트의 길이/크기, 및 소스 오브젝트가 불완전한 오브젝트인지(예를 들면, 모든 패킷들이 수신되지는 않음)를 결정하도록 허용할 수 있다. 실시예에서, 이것은, 소스 오브젝트의 마지막 소스 패킷에 "클로즈 오브젝트 플래그(예를 들면, B-플래그)"를 설정함으로써 소스 오브젝트의 종료를 표시하도록 시그널링함으로써 달성될 수 있고, 여기서 B-플래그는 기존의 FLUTE 표준에서의 기존 필드이다.

[0167] 예를 들면, B-플래그 필드의 값은 마지막 소스 패킷을 제외한 모든 소스 패킷에서 제로(0)로 설정될 수 있고, 마지막 소스 패킷에서 B-플래그는 일(1)로 설정될 수 있다. 이것은, FLUTE 표준들이 B-플래그 필드의 사용을 위한 확정적인 또는 정확한 요건들을 설정하지 않고, 임의의 경우에, 소스 오브젝트의 마지막 소스 패킷에서만 B-플래그가 일(1)로 설정되는 것을 지정하지 않았기 때문에 가능하다.

[0168] 소스 오브젝트의 마지막 소스 패킷(P)은 소스 오브젝트의 마지막 부분을 포함한다. 따라서, 마지막 소스 패킷에만 B-플래그를 설정(즉, P의 B-플래그 = 1을 설정)함으로써, 다양한 실시예들은 수신기 디바이스가 소스 오브젝트의 마지막 부분이 수신되었는지를 결정하는 것을 가능하게 할 수 있다. 추가로, 수신기 디바이스는, 길이/크기 값이 마지막 소스 패킷(P)의 소스 페이로드 ID의 바이트 오프셋과 마지막 소스 패킷(P)의 페이로드 크기의 합과 동일하도록 설정함으로써 소스 오브젝트의 크기/길이를 결정할 수 있다. 추가로, 수신기 디바이스는, 오브젝트에 대해 수신된 다른 소스 패킷들의 페이로드 크기 및 바이트 오프셋을 사용하여 오브젝트의 임의의 다른 부분들이 수신되지 않았는지를 결정할 수 있고, 즉, 수신기는 소스 패킷들 내에서 수신되지 않은 오브젝트의 바이트들의 임의의 시퀀스가 존재하는지를 결정할 수 있다. 이러한 방식으로, 브로드캐스트 시스템들은, 각각의 오브젝트에 대해 FDT 또는 다른 시그널링 정보 전부가 전송되도록 요구하지 않고서 그리고 소스 패킷들 또는 오브젝트들에 FEC 시맨틱스를 포함하지 않고서, 소스 오브젝트의 모든 패킷들이 수신되는지 또는 수신되는 때를 결정하고, 소스 오브젝트의 길이/크기를 결정하고 및/또는 소스 오브젝트가 불완전한 오브젝트인지를 결정할 수 있다.

[0169] 도 4는, 브로드캐스트 시스템들이, FDT 또는 FEC 시맨틱스없이, 소스 오브젝트의 패킷들 모두가 수신되는지 또는 수신되는 때를 결정할 수 있도록, 실시예의 소스 오브젝트(402)가 복수의 소스 패킷들(404-410)로 패키징되는 것을 예시한다. 각각의 소스 패킷(404-410)은 B-플래그 필드, 소스 페이로드 ID 필드 및 소스 페이로드 필드를 포함한다. 도 4에 예시된 예에서, 소스 오브젝트(402)는 5,000 바이트의 크기/길이이고, 제 1의 3개의 소스 패킷들(404-408) 각각은 1280 바이트의 크기/길이인 소스 페이로드 데이터-필드를 포함한다. 소스 오브젝트의 크기(즉, 5,000 바이트들)가 1280의 배수가 아니기 때문에, 마지막 패킷(410)의 소스 페이로드 데이터-필드는 1160 바이트만을 포함한다. 제 1의 3개의 소스 패킷들(404-408) 각각의 B-플래그 필드는 제로(0)로 설정되고, 반면에 마지막 패킷(410) 각각의 B-플래그 필드는 1로 설정된다.

[0170] 개괄해서, 수신기 디바이스 또는 수신기는, 전체 소스 오브젝트가 수신되었는지, 또는 오브젝트 중 적어도 일부 부분이 미싱되었는지를, 수신된 소스 패킷들로부터 결정할 수 있다. 예를 들면, 수신기가 일(1)로 설정된 B-플래그 필드를 갖는 오브젝트의 마지막 패킷을 수신하지 않는다면, 수신기는 오브젝트의 적어도 일부 서픽스가 수신되지 않았다고 결정할 수 있다. 반면에, 일(1)로 설정된 B-플래그 필드를 갖는 소스 패킷이 오브젝트에 대해 수신되었다면, 수신기는 자신이 오브젝트의 서픽스를 수신하였다고 결정할 수 있고, 일(1)로 설정된 B-플래그를 갖는 패킷 내의 바이트 오프셋 및 그 패킷의 패킷 페이로드 크기의 합을 계산함으로써 오브젝트의 크기를 결정할 수 있다. 게다가, 일(1)로 설정된 B-플래그 필드를 갖는 소스 패킷이 오브젝트에 대해 수신되었을 때, 수신기는 수신된 소스 패킷들의 바이트 오프셋들 및 패킷 페이로드 크기들로부터 분실된 소스 오브젝트의 내부 부분들이 존재하는지를 결정할 수 있다.

[0171] 도 4에 예시된 예에 관련하여, 수신기 디바이스는 소스 패킷들(404, 408 및 410)(그리고 소스 패킷(406)은 아님)을 수신하고, 1로 설정된 B-플래그를 갖는 소스 패킷(410)의 수신으로부터, 오브젝트의 서픽스가 수신되었다는 것 및 그의 크기가 3840(바이트 오프셋) + 1160(페이로드 크기) = 5000 바이트 크기라는 것을 결정할 수 있다. 수신기 디바이스는 또한, 수신된 소스 패킷들 및 그러한 패킷들의 바이트 오프셋들 및 페이로드 크기들로부터, 오브젝트의 바이트들 1280-2559(수신되지 않은, 소스 패킷(406)으로 전달된 바이트들)이 미싱되었다고 결정할 수 있다. 소스 패킷(406) 대신에, 수신기가 소스 패킷(410)을 수신하지 않는다면, 수신기는, 이러한 오브젝트에 대해 일(1)로 설정된 B-플래그 필드를 갖는 소스 패킷이 아직 수신되지 않았다는 것, 및 따라서 오브젝트의 서픽스가 아직 수신되지 않았다는 것을 결정할 수 있다. 실시예에서, 수신기 디바이스는, 소스 오브젝트에 대해 아직 수신되지 않은 어떠한 추가의 패킷들도 전송 또는 수신되지 않았거나, 전송 또는 수신될지 않을 높은 확률이 존재한다고 결정하기 전에, 시간의 지속기간을 대기하고, 필요한 경우에 복원 동작들을 수행하도록 구성될 수 있다. 수신기가 이러한 결정을 내리기 위해 대기할 수 있는 시간의 양은, 만약 있다면, 소스 선언에서 전달 시간 정보에 적어도 부분적으로 기초할 수 있다.

[0172] 실시예에서, 브로드캐스트 시스템은 타이밍 정보를 포함하는 소스 패킷들(404-410)을 생성하도록 구성될 수 있다. 이러한 타이밍 정보는 소스 패킷들의 전송의 타이밍일 수 있다. 따라서, 소스 패킷들의 타이밍은 패킷들 자체에 배치될 수 있다. 소스 패킷들 내의 타이밍 정보의 포함은 시스템이 RTP 동작들을 복제하고, 네트워크 지터를 측정하고, 전달 타이밍을 연관시키고, 미디어 시간 관계들을 연관시키고, NTP 타임스탬프에 걸쳐 마스크를 지정하는 것 등을 허용한다. 예를 들면, 시스템은 64 비트 NTP 타임스탬프를 생성하고, 타이밍의 정밀도를 결정하기 위해 패킷들에 포함하기 위한 64 비트 NTP 타임스탬프의 4 바이트 마스크를 사용할 수 있다. 타임스탬프는 패킷이 전송된 시간(또는 몇몇의 다른 레퍼런스)을 제공할 수 있고, 제공 시간(RTP와 유사하지만, 미디어 동기화에 사용되지 않음)과 연관될 수 있다. 마스크는 시그널링 정보에 지정될 수 있고, 비트 1 내지 64의 임의의 임의적인 범위를 가질 수 있다. 마스크 크기들은 바이트 기반 타임 스탬프들을 가능하게 하기 위해 8 비트들의 배수일 수 있다. 마스크 크기는 또한 타이밍 정보의 비-존재를 나타내기 위해 제로(0)로서 시그널링될 수 있다.

[0173] 실시예에서, 시스템은 타이밍 정보를 전달하기 위해 FLUTE/LCT 헤더 내의 혼잡도 제어 정보를 사용하도록 구성될 수 있다. 대안적으로, FLUTE/LCT 헤더 내 혼잡도 제어 정보는 수신기 디바이스에 의해 플로우 당 패킷 손실 측정들을 가능하게 하기 위해 플로우 시퀀스 번호를 전달하는데 사용될 수 있다.

[0174] 도 5는 종래 기술의 FLUTE 오브젝트 패킷 헤더(502)와 실시예의 FLUTE 오브젝트 패킷 헤더(504) 사이의 차이들 중 일부를 예시한다. 구체적으로, 도 5는, 실시예의 FLUTE 오브젝트 패킷 헤더(504)가 타임스탬프(506) 필드, FLID(508) 필드, OSN(510) 필드 및 바이트 오프셋(512)을 포함하는 것을 예시한다.

[0175] 다양한 실시예들은, 데이터 전달의 엔드-투-엔드 레이턴시가 최소이도록 소스 플로우들의 청크 전달 및 수신을 달성하도록 구성된 컴포넌트들을 포함할 수 있다. 브로드캐스트 측 상에서, 실시예의 브로드캐스트 서버는 소스 오브젝트들이 이용 가능하게 될 때 소스 오브젝트들을 청크들로 전송할 수 있는데, 왜냐하면 브로드캐스트 서버는 단지 각각의 소스 패킷이 전송될 때 바이트 오프셋을 각각의 소스 패킷에 놓을 필요가 있기 때문이다. 브로드캐스트 서버는 또한, 소스 오브젝트 크기가 소스 패킷들을 전송하기 필요하지 않도록 소스 오브젝트의 마지막 소스 패킷에서 "클로즈 오브젝트 플래그(B-플래그)"를 설정할 수 있다. 마찬가지로, 서버는 소스 오브젝트 내의 각각의 부분 또는 상이한 타입의 부분의 마지막 패킷을 식별하기 위해 "클로즈 타입" 플래그, 필드 또는 값을 설정할 수 있다. 예를 들면, 소스 오브젝트가 4 개의 상이한 부분들로 분할되고, 제 1 및 제 3 부분들이 "타입 A"로 라벨링되고, 제 2 및 제 4 부분들이 "타입 B"로 라벨링되면, 시스템은, 그 부분의 및/또는 그 타입의 마지막 패킷인 것으로 그 패킷을 식별하기 위해 이들 4 개의 부분들 각각의 마지막 패킷 내의 "클로즈 타입" 플래그/필드를 포함 또는 설정할 수 있다.

[0176] 수신기 측 상에서, 수신기 디바이스는 소스 오브젝트가 청크들로 도달할 때 그 소스 오브젝트를 복원하도록 구성될 수 있다. 수신기 디바이스는 소스 오브젝트 내의 데이터의 포지션을 결정하기 위해 소스 패킷 바이트 오프셋을 이용하고 순차적으로 수신된 소스 패킷 데이터를 애플리케이션 또는 클라이언트(예를 들어, 미디어 플레이어)에 바로 송신한다. 수신기 디바이스는 소스 페이로드 ID 바이트 오프셋 및 "클로즈 오브젝트 플래그"(B-플래그) 필드 값들을 통해 소스 오브젝트 내에서 미싱 데이터를 검출할 수 있다. 수신기 디바이스는 수신된 소스 패킷 페이로드들의 크기와 바이트 오프셋 값을 통해 미싱 데이터 갭들이 존재하는지를 결정할 수 있다. 수신기 디바이스는 일(1)로 세팅된 B-플래그로 소스 패킷이 아직 수신되지 않았음을 결정함으로써 데이터의 미싱 서픽스를 검출할 수 있다.

[0177] 도 6은 HTTP 헤더(604) 필드 및 이용 가능성 시간들(606) 필드를 포함하는(또는 이들과 번들링되는) 실시예 FLUTE 오브젝트(602)의 예시이다. HTTP 헤더(604) 필드는 캐싱 동작을 복제하도록 HTTP 프록시에 의한 이용에 적합한 정보를 포함하는 HTTP 응답 헤더를 포함할 수 있다.

[0178] 이용 가능 시간들(606) 필드는, 수신 디바이스에서 FLUTE 오브젝트(602)의 이용 가능 시간들에 속하는 시그널링 또는 제어 정보를 포함할 수 있으며, 이는 FLUTE 오브젝트(602)가 활성화되었는지, 유효한지, 또는 만료되었는지를 시스템이 결정하도록 허용할 수 있다. 실시예에서, 이용 가능 시간들(606) 필드는 소비 애플리케이션에 의한 이용을 위해 오브젝트의 시작 및/또는 종료 이용 가능 시간들에 대한 NTP(Network Time Protocol) 타임스탬프들을 포함할 수 있다. FLUTE 오브젝트(602) 내의 이러한 타이밍 정보의 포함은, 캐시에 저장된 아이템들이 제한된 지속기간 동안만 이용 가능하게 되고 및/또는 특정한 시간 기간 이후 타임 아웃되는 캐시 타임-아웃 정책과 유사한 특징들을 브로드캐스트 시스템이 구현하도록 허용할 수 있다. 이러한 방식으로, 브로드캐스트 시스템은, FLUTE 오브젝트(602)가 현재 또는 최신 정보를 포함한다는 것을 보장할 수 있다.

[0179] 기존의 FLUTE 솔루션들에서, 소스 오브젝트들의 전달을 위한 메타데이터 정보를 전달하는 FDT 오브젝트들은 그의 대응하는 소스 오브젝트들의 타이밍 정보 또는 타임스탬프들을 포함하지 않는다. FDT 오브젝트는 HTTP 응답 헤더에 통상적으로 포함된 하나 또는 2개의 필드들을 포함할 수 있지만, 기존의 FDT 오브젝트들은 다양한 실시예들에서 달성되는 바와 같이, 완전한 헤더의 포함을 허용하지 않는다. 또한, FDT 오브젝트를 브로드캐스팅하는 것은 부가적인 대역폭을 소비하므로 그리고 각각의 FDT는 통상적으로 플로우에서 각각의 소스 오브젝트에 대해 반복적으로 브로드캐스팅되므로, 개별 FDT 오브젝트의 크기를 최소화하는 것이 유리하다. 다양한 실시예들은 FDT 오브젝트 없이 오브젝트 전달을 달성하고, 소스 오브젝트와 함께 HTTP 응답 헤더 및 타임스탬프 정보를 전달할 수 있으며, 이는 각각의 오브젝트 플로우에 의해 소비되는 대역폭의 양을 감소시키는 네트워크 자원들의 보다 효율적인 이용이다.

[0180] 다양한 실시예들은 템플릿 정보를 포함하는 소스 플로우 선언 정보를 통신하도록 구성된 컴포넌트들을 포함할 수 있다. 위에서 논의된 바와 같이, 소스 플로우 선언은 오브젝트들의 플로우에서 오브젝트들 간의 관계를 식별하는데 이용될 수 있고 오브젝트 플로우에 관련된 정보 필드들의 간결한 표현(예를 들어, FLID, 플로우 타입들, MIME 타입들, 암호해독 키 정보 등)일 수 있다. 템플릿들 및 템플레이팅 기법들을 이용함으로써, 다양한 실시예들은, 오브젝트에 대한 URI들을 식별하기 위해 그리고 오브젝트들이 브로드캐스트/멀티캐스트 채널을 통해 수신되고 및/또는 전송될 때 소스 플로우 선언을 이용할 수 있다. 예를 들어, 템플릿 정보를 포함하는 플로우 선언의 소스는 다음과 같이 서버 또는 수신기 디바이스에서 표현될 수 있다:

[0181] 위의 예에서, 소스 플로우 선언의 URI 필드는 스트링 "%OSN%"을 포함한다. 템플레이팅 기법들을 이용하여, 이 스트링은 오브젝트들의 시퀀스 번호들과 URI들 간의 암시적인 맵핑을 제공하도록 오브젝트의 플로우에서 각각의 오브젝트에 대해 상이한 값으로 변환될 수 있다. 예를 들어, 이 플로우 내에서 OSN = 25인 오브젝트는 URI http://localhost.seq1/object25와 연관된다. 유사한 기법들은 전송 정보에 대해, 예컨대 "START_TRANSMISSION" 필드 및 "END_TRANSMISSION" 필드에 대해 이용될 수 있다. 실시예에서, "START_TRANSMISSION" 및 "END_TRANSMISSION" 필드들은 전달의 타이밍을 표시하기 위해 "Timescale" 필드의 값에 기초하여 컴퓨팅될 수 있다. 예를 들어, Timescale = 10은, 시간 측정이 초 당 10 틱들(ticks)의 단위들이고, 이에 따라 이 플로우 내에서 OSN=25인 오브젝트는 50초의 시작 전송 시간 및 52초의 종료 전송 시간을 갖는다는 것을 나타낸다.

[0182] 따라서, 템플릿들 및 템플레이팅 기법들은 오브젝트에 대한 URI, 오브젝트에 대한 전달 시간, FLID, OSN 및 URI 간의 관계 등을 유도하기 위한 메커니즘을 제공하도록 이용될 수 있다. 따라서, 템플릿들은 위치들, 이름들, 이용 가능 시간들 및 유도될 오브젝트의 시퀀스와 연관되는 다른 메타데이터 간의 관계들을 시그널링하는 간단하고 간결한 수단으로서 다양한 실시예들에서 이용될 수 있다.

[0183] 다양한 실시예들은 템플릿 정보 및 애플리케이션에 대한 링크를 포함하는 소스 플로우 선언 정보를 전달하도록 구성되는 컴포넌트들을 포함할 수 있다. 이러한 소스 플로우 선언은 다음과 같이 서버 또는 수신기 디바이스에서 표현될 수 있다:

[0184] 위의 예에서, 소스 플로우 선언은 MPD_URL 필드 및 MPD_REP_ID 필드를 포함한다. 실시예에서, 이들 필드들은 MPD에서 설명된 표현의 DASH 세그먼트들과 오브젝트들 간의 대응을 위해 실시예 서버 또는 수신기 디바이스에 의해 이용될 수 있다.

[0185] 다양한 실시예들은 FDT들의 이용 없이, 그리고 패킷 헤더 오버헤드들을 최소화하고 오브젝트들의 대량 전달을 지원하고 다양한 크기의 소스 패킷들의 이용을 허용하면서 FEC 시맨틱스 또는 정보에 독립적인 소스 오브젝트들이 독립적으로 전달되도록 허용하는 개선된 FEC 능력들을 브로드캐스트 통신 시스템에 제공하도록 구성되는 컴포넌트들을 포함할 수 있다.

[0186] 다양한 실시예들은 시그널링 플로우 선언을 위해 정적인 파일 전달 정보를 이용하도록 구성된 컴포넌트들을 포함할 수 있다.

[0187] 다양한 실시예들은 오브젝트 콘택스트에서 플로우의 번들링된 FEC 보호에 대한 지원을 제공하도록 구성된 컴포넌트들을 포함할 수 있다.

[0188] 다양한 실시예들은 소스 오브젝트들을 통신하고 소스 플로우 선언들 또는 소스 오브젝트들에서가 아니라 필요한 경우에만 그리고 FEC 능력들을 갖지 않은 수신기 디바이스들이 FEC 복구 플로우를 무시하는 것을 가능케 하면서 FEC 정보를 제공할 수 있다.

[0189] FEC는 복구 플로우 당 고정된 심볼 크기를 갖는 심볼 기반일 수 있다.

[0190] FEC 복구 플로우는 (예를 들어, 번들링을 통해) 하나 이상의 소스 플로우들에서 오브젝트들의 보호를 제공한다.

[0191] 다양한 실시예들은 FEC 복구 플로우 선언, FEC 복구 패킷들 및 FEC 전송 오브젝트(소스 오브젝트들의 소스 블록 또는 번들을 포함할 수 있음)와 같은 다양한 FEC 특정 컴포넌트들, 엘리먼트들, 통신 메시지들 및 데이터 구조들을 포함할 수 있다. FEC 복구 플로우 선언은 FEC 시그널링 정보 및 다른 FEC 특정 정보를 포함할 수 있다. FEC 전송 오브젝트는 소스 오브젝트 및 관련된 정보를 포함할 수 있다. 다양한 실시예들은 다수의 FEC 전송 오브젝트들 중 하나 또는 그의 연속에 FEC 코딩을 적용하도록 구성될 수 있다.

[0192] 실시예에서, 수신기 디바이스는 이용 가능한 FEC 정보에 기초하여 복구 패킷들로부터 번들링된 오브젝트들을 복원하도록 구성될 수 있다.

[0193] 다양한 실시예들은 다른 소스 FLID들 및 복구 FLID들과 다른, 각각의 복구 플로우에 대한 별개의 그리고 고유한 FLID를 포함할 수 있다. 이 FLID는 TSI에 의해 스코핑될 수 있고 FLID에 포함되는 정보를 스코핑할 수 있다.

[0194] 다양한 실시예들은 소스 플로우들에 대한 보호를 제공할 후 있는 동기화된 소스 플로우들에 대한 FEC 복구를 제공할 수 있다. 보호된 소스 플로우들은 복구 플로우 선언에서 나열될 수 있다. 다양한 실시예들은 보호된 소스 플로우들에서 오브젝트들을 시간 정렬하고, 상이한 소스 플로우들로부터 동일한 OSN을 갖는 소스 오브젝트들을 보호할 수 있다. 다양한 실시예들은 복구를 위한 OSN이 보호된 소스 플로우들에 대한 소스 오브젝트들의 OSN에 매칭하도록 각각의 복구 플로우 패킷에서 하나의 OSN을 포함할 수 있다.

[0195] 다양한 실시예들은 또한, 완전히 시간 정렬되지 않는 오브젝트들을 포함하는 소스 플로우들에 대한 보호를 제공하기 위해 비동기화된 소스 플로우들에 대한 FEC 복구를 또한 제공할 수 있다. 다양한 실시예들은 상이한 플로우들로부터 상이한 OSN들을 갖는 소스 오브젝트들을 보호하고 단일 소스 플로우의 1개 초과의 소스 오브젝트를 보호할 수 있으며, 이는 보호될 소스 오브젝트들로서 여러번 이들 소스 플로우들을 나열함으로써 달성될 수 있다.

[0196] 다양한 실시예들은 보호되는 객체들의 수와 동일하게 복구 플로우 패킷들에서 OSN들의 수를 세팅할 수 있다. OSN들은 복구 플로우 선언에서 소스 플로우 리스트에 매칭하는 순서로 나열될 수 있다.

[0197] 다양한 실시예들은 소스 오브젝트에 대한 FEC 전송 오브젝트를 포함할 수 있으며, 이는 FEC 인코딩 동작들을 위해 이용될 수 있다. FEC 전송 오브젝트는 패딩 바이트들 및 크기/길이(F) 필드를 포함할 수 있으며, 여기서 F는 바이트의 소스 오브젝트의 크기이다. 실시예에서, 크기/길이(F) 필드는 4 바이트 필드일 수 있다.

[0198] 다양한 실시예들은 소스 오브젝트의 부분에 대한 FEC 전송 오브젝트를 포함할 수 있으며, 이는 FEC 인코딩 동작들을 위해 이용될 수 있다. FEC 전송 오브젝트는 소스 오브젝트 및 패딩 바이트들에 대한 바이트 범위를 포함할 수 있다. 실시예에서, FEC 전송 오브젝트는 또한 크기/길이(F) 필드를 포함할 수 있다. 다양한 실시예들에서, 크기/길이(F) 필드는 소스 오브젝트의 바이트 범위를 또는 소스 오브젝트의 부분의 바이트 범위의 시작과 바이트 범위의 종료 간의 바이트의 차이를 제공할 수 있다.

[0199] FEC 전송 오브젝트 크기는 심볼 크기(T)의 배수일 수 있다. 크기/길이(F) 필드 값은 FEC 전송 오브젝트의 마지막 4 바이트들에서 전달될 수 있다. 이 경우에, FEC 전송 오브젝트의 심볼들의 수는 ceil((F+4)/T)로서 계산될 수 있으며, 여기서 ceil(x)는 적어도 x만큼 큰 최소의 정수를 리턴하는 함수이다. 예를 들어, T = 1280 및 F = 5000인 경우, FEC 전송 오브젝트에서 심볼들의 수는 ceil(5004/1280) = 4 로서 계산된다. FEC 전송 오브젝트는 최소수의 패딩 바이트들을 포함하도록 생성될 수 있다. 패딩 바이트들 및 F는 소스 오브젝트의 소스 패킷들 내에서 송신되지 않을 수 있고, FEC 디코딩이 복원하는 FEC 전송 오브젝트의 부분일 수 있다.

[0200] 다양한 실시예들은 소스 플로우들에 대한 FEC 보호를 제공하기 위한 FEC 복구 플로우들을 포함할 수 있으며, 이는, 소스 플로우의 개별 오브젝트들을 보호하기 위해, 하나 이상의 소스 플로우들로부터 다수의 오브젝트들을 보호하기 위해, 또는 하나 이상의 소스 플로우들로부터 오브젝트들의 다수의 부분들을 보호하기 위해 이용될 수 있다. 소스 플로우의 개별 오브젝트들을 보호하기 위해 이용될 때, 각각의 FEC 인코딩은 소스 오브젝트에 대한 FEC 전송 오브젝트로부터 생성될 수 있다. 하나 이상의 소스 플로우로부터 다수의 오브젝트들을 보호하기 위해 이용될 때, 각각의 FEC 인코딩은 소스 오브젝트에 대한 FEC 전송 오브젝트들의 연쇄로부터 생성될 수 있다. 연속은 복구 패킷들에서 수신되는 OSN들 및 복구 플로우 선언에 의해 표시되는 소스 플로우들의 순서일 수 있다.

[0201] 다양한 실시예들에서, FEC 전송 오브젝트 길이는 복구 패킷들에서 전달되는 TOL로부터 수신기에서 결정될 수 있으며, 이는 복구 플로우 선언에서 선언된 FLID 및 복구 패킷들에서 전달되는 OSN에 대응하는 FEC 전송 오브젝트의 심볼들의 수를 나타낸다. TOL은 FEC가 보호된 소스 오브젝트의 각각의 FEC 전송 오브젝트에 대한 복구 FEC 페이로드 ID에 포함되는 2 바이트 값일 수 있다.

[0202] 일반적으로, FEC 디코더는 단지 그것이 복원할 오브젝트의 부분에 대한 심볼들을 알 필요가 있다. 따라서, 다양한 실시예들은 FEC가 보호되는 오브젝트의 부분에 의해 커버되는 심볼 범위에 기초하여 FEC 전송 오브젝트 길이를 셋팅할 수 있다. 즉, FEC 전송 오브젝트 길이는 소스 오브젝트의 부분을 커버하는 소스 심볼들의 범위에 기초하여 세팅될 수 있다. 예를 들어, 심볼 길이가 1000 바이트들이고(즉, 새로운 심볼은 매 1000 바이트들에서 시작하고, 심볼 0은 소스 오브젝트의 바이트들(0-999)을 커버함) FEC가 보호될 소스 오브젝트의 부분이 바이트(1500)에서 시작하고 바이트(4500)에서 종료하는 경우, 시스템은 바이트 범위(1500-4500)를 커버하도록 심볼 범위(1-4)를 나타내기 위해 FEC 전송 오브젝트 길이를 세팅할 수 있다. 시스템은 이어서 FEC 전송 오브젝트에서 범위들(1000-1499 및 4501-4999)을 0들로 패딩할 수 있다. 실시예에서, 수신기 디바이스는 그것이 오브젝트를 디코딩할 때 0들의 이러한 패딩을 자동으로 부가할 수 있고, 수신기는 그것이 오브젝트를 인코딩할 때 이들 심볼들을 부가할 수 있다. 이는 패딩 정보를 전송할 필요성을 제거한다. 이는 또한 FEC 보호된 부분들로부터 패딩 바이트들을 제거함으로써 FEC 인코딩 내에 포함되는 바이트들의 수를 감소시킨다.

[0203] 부분적인 심볼들의 성능 영향을 감소시키기 위해, 일 실시예에서, 시스템은, FEC 전송 오브젝트에 포함되는 패딩이 작거나 크지 않도록 충분히 작은 심볼 크기를 선택하게 구성될 수 있다. 실시예에서, 시스템은 심볼 경계들에 따르도록 패킷 구조를 생성하게 구성될 수 있다.

[0204] 도 7a는 소스 오브젝트에 대한 실시예 전송 오브젝트(700)의 예시이다 예시된 전송 오브젝트(700)는 소스 오브젝트(702) 필드, 패딩(704) 필드 및 바이트 범위 또는 크기/길이(F)(706) 필드를 포함한다. 전송 오브젝트(700)는 심볼 크기(T)에 기초하여 결정될 수 있는 복수의 심볼 경계들(708)과 연관될 수 있다. FEC 전송 오브젝트가 파티셔닝될 수 있는 심볼들의 수는 심볼 크기(T)에 의해 분할되는 바이트 범위 또는 크기/길이(F)(706) 필드의 크기와 소스 오브젝트(702)의 크기/길이의 합의 상한으로서 계산될 수 있다. 전송 오브젝트(700)는 크기/길이(F)(706) 필드 및 소스 오브젝트(702) 필드를 파퓰레이팅함으로써 생성될 수 있다. 패딩(704) 필드는 소스 오브젝트(702) 필드와 크기/길이(F)(706) 필드 간의 임의의 갭들을 채우도록 파퓰레이팅될 수 있다.

[0205] 도 7a에 도시된 예에서, FEC 전송 오브젝트(700)가 3개의 심볼들로 분할되고, 소스 오브젝트(702)는 심볼 경계(708)에서 종료되지 않는다. TOL(transmission object length)는 이 예에서 3이고, 이는 FEC 전송 오브젝트는 크기가 3개의 심볼들이라는 것을 나타낸다.

[0206] 복구 FEC 페이로드 ID는 각각의 프로젝팅된 오브젝트에 대한 ESI(encoding symbol identifier) 필드 및 TOL(transmission object length) 필드 및 심볼들을 포함할 수 있다. 일 실시예에서, ESI 및 TOL 필드들은 크기가 각각 이(2) 바이트들일 수 있다.

[0207] 도 7b는 소스 오브젝트의 일 부분에 대한 일 실시예의 전송 오브젝트(750)의 도시이다. 예시된 전송 오브젝트(750)는 소스 오브젝트(702) 필드, 패딩(704) 필드, 및 바이트 범위(752) 필드를 포함한다. 전송 오브젝트(750)는, 심볼 크기 T(예를 들어, 1000)에 기초하거나 또는 소스 오브젝트에 기초하여 결정될 수 있는 복수의 심볼 경계들(754)과 연관될 수 있다. FEC 보호 부분에 의해 커버된 바이트 범위(752)는 1500-4500과 같을 수 있고, 따라서, 심볼 크기가 상기 예에 설명된 바와 같이 1000 바이트들로 설정되는 경우, 보호 부분의 심볼 범위는 심볼들(1-4)(즉, 바이트 범위(1500-4500)을 커버하기 위한 것)과 같을 수 있다.

[0208] 복구 FEC 페이로드 ID는, ESI 필드 및 FEC가 보호되는 부분 중 시작과 종료 경계들(754)을 커버하는 심볼 범위 필드를 포함할 수 있다. 일 실시예에서, ESI 및 심볼 범위 필드들은 각각 크기가 이(2) 바이트일 수 있다.

[0209] 일 실시예에서, FEC 페이로드 ID는 소스 심볼 시작 포지션과 소스 심볼 종료 포지션을 포함할 수 있다. 추가적인 실시예에서, FEC 페이로드 ID는 오브젝트 식별자의 보호된 플로우로부터 소스의 TOI를 포함할 수 있다. TOI는 크기가 이(2) 바이트일 수 있다.

[0210] 바람직한 실시예에서, FEC 페이로드 ID는, 보호될 소스 오브젝트의 부분을 포함하는 FEC 인코딩 오브젝트의 (가장 가까운 심볼 경계로 반올림된) 심볼들의 크기와 함께, 보호될 부분의 소스 오브젝트 내에서 바이트 시작 포지션을 포함하고, 소스 오브젝트의 보호된 부분의 바이트들(또는 옥텟들)의 크기가 전송 소스 블록의 종료 시에 전달된다. 이 바람직한 실시예는 복구 헤더 오버헤드들의 측면에서 상대적으로 효율적이고, 전송 소스 오브젝트 내에서 패딩 바이트들의 낭비되는 보호를 최소화하고, 수신기로 하여금 FEC 디코딩을 하여 FEC 인코딩 오브젝트를 복원하고 복구 헤더 내의 그리고 FEC 인코딩 오브젝트 내의 정보로부터 소스 오브젝트의 부분을 추출할 수 있게 한다.

[0211] 도 8a는 현재 FLUTE 복구 FEC 페이로드 ID(802)와 다양한 실시예의 복구 FEC 페이로드 ID들(804, 806, 808) 간의 차이점을 도시한다. 현재 FLUTE 복구 FEC 페이로드 ID(802)는 SBN 필드와 ESI 필드를 포함한다. 각각의 실시예의 복구 FEC 페이로드 ID들(804, 806, 808)은 ESI 필드 그리고 FEC 인코딩에 의해 보호되는 각각의 오브젝트를 위한 하나의 송신 오브젝트 길이 필드(TOL1, TOL2, TOL3 등)를 포함한다. 따라서, 이 실시예의 복구 FEC 페이로드 ID들(804, 806, 808)의 포맷은 보호되는 오브젝트들의 수에 의존한다.

[0212] 현재 FLUTE 복구 FEC 페이로드 ID(802)는, 소스 오브젝트 또는 대응하는 FEC 전송 오브젝트(FEC 인코딩 오브젝트)의 심볼들의 수를 식별하는 정보나, 소스 오브젝트 또는 대응하는 FEC 전송 오브젝트의 길이를 식별하는 어떠한 정보도 포함하지 않는다. 대신, 현재 FLUTE 솔루션들에서, 소스 오브젝트 및/또는 대응하는 전송 오브젝트에 대한 정보가 그 소스 오브젝트와 연관된 별개의 FDT에서 전달된다. 현재 FLUTE 복구 FEC 페이로드 ID(802)의 SBN(소스 블록 번호)필드는, 복구 패킷에서 전달되는 심볼들이 발생되는 소스 블록을 식별하며, 이는 오브젝트가 다수의 소스 블록들로 분할되는 경우 유용하다.

[0213] 일 실시예에서, 실시예의 복구 FEC 페이로드 ID들(804, 806, 808)의 ESI 필드가, 복구 패킷 페이로드에서 전달되는 복구 심볼들이 얼마나 많이 오브젝트로부터 생성되는지를 고유하게 식별하는 UOSI(universal object symbol identifier) 필드로 대체될 수 있다. FEC 인코딩 오브젝트 내 소스 블록들의 수가 1일 경우, UOSI 및 ESI는 동등하다. 그러나, FEC 인코딩 오브젝트의 소스 블록들(Z)의 수가 1보다 큰 경우, 소스 심볼로부터의 ESI 값 B와 SBN 값 C에 따른 심볼에 대한 UOSI 값 A는 A= B*Z + C로 계산된다. ESI 대신 UOSI를 이용하는 것은 특히, 오브젝트들이 적어도 때때로 분할되고 다수의 소스 블록들로서 FEC 인코딩되는 경우 유용하다.

[0214] 도 8b는 현재의 FLUTE 복구 FEC 페이로드 IE(802)와 다양한 추가 실시예의 복구 FEC 페이로드 ID들(852a 및 852b) 사이의 차이점을 도시한다. 하나의 (어쩌면 부분적인) 소스 오브젝트에 대한 FEC 페이로드 ID들(852a)은 SBP(source object start byte position), 전송 오브젝트의 심볼들의 크기인 전송 오브젝트 길이(TOL), 및 ESI 필드를 포함한다. FEC 페이로드 ID들(852b)은 또한 TOI 필드를 포함한다. 유사하게, FEC 페이로드 ID들(858)은, 보호될 소스 오브젝트의 일 부분에 대응하는 각각의 TOI 필드에 대한 SBP 및 TOL을 포함할 수 있고, ESI 필드가 뒤에 이어진다.

[0215] 다른 실시예들에서, FEC 페이로드 ID는 복구 플로우에 의해 보호된 각각의 (어쩌면 부분적인) 소스 오브젝트에 대한 소스 오브젝트 SBP(start byte position) 및 EBP(end byte position), 및 ESI 필드를 포함한다. EFC 페이로드 ID는 또한, 복구 플로우에 의해 보호된 각각의 (어쩌면 부분적인) 소스 오브젝트에 대한 TOI를 전달할 수 있다.

[0216] FEC 인코딩 오브젝트의 소스 블록들 Z의 수가 하나(1) 보다 더 클 경우, 또는 소스 블록 당 서브-블록들의 수(N)가 하나(1) 보다 더 클 경우, 시스템은 다양한 특성들, 특징들 또는 목적들을 유지하거나 또는 달성하는 것이 종종 중요하다. 예를 들어, (본원에 설명된 바와 같이) FEC 보호와 무관하게 소스 오브젝트들이 송신될 수 있다는 것을 시스템이 보장하는 것이 중요할 수 있다. 상이한 소스 오브젝트들로부터 소스 패킷들의 손실의 양이 상이할 경우 보호된 오브젝트들을 복원할 때 FEC 보호 동작들이 (예를 들어, 복원 오버헤드 측면에서) 유효하고 효율적이라는 것을 시스템이 보장하는 것 또한 중요할 수 있다. 이외에도, FEC 디코딩 동작들이 수신기 디바이스에서 수행되어, 가능한 한 데이터 재정렬을 거의 하지 않고 가능한한 메모리를 거의 사용하지 않으면서 FEC 전송 오브젝트들이 효율적으로 복원될 수 있는 것을 시스템이 보장하는 것 또한 중요할 수 있다. 그러나, FEC 인코딩 오브젝트를 형성하기 위한 종래의 그리고 복잡하지 않은 방법들은 종종, 이들이 시스템으로 하여금 이러한 속성들, 특성들 또는 목적들을 유지하거나 또는 달성할 수 있게 하지 않기 때문에 비효율적이거나 또는 적절하지 않다.

[0217] 다양한 실시예들은, 소스 블록들의 수(Z)가 하나(1)보다 많을 경우 및/또는 소스 블록들 당 서브-블록들의 수(N)가 하나(1)보다 많을 경우 시스템으로 하여금 상기 논의된 특성들, 특징들 또는 목적들을 유지하게 하거나 또는 달성하게 하도록 FEC 인코딩 오브젝트를 형성하는 방법들, 및 이러한 방법들을 구현하도록 구성된 컴포넌트들을 포함할 수 있다. 예를 들어, 컴포넌트는 소스 블록들 사이에서 FEC 전송 오브젝트들의 부분들을 균등하게 (또는 가능한 한 균등하게) 맵핑하도록 구성될 수 있다. 그런 다음, 소스 블록들 내에서, 컴포넌트는 FEC 전송 오브젝트들의 부분들을 그 소스 블록의 서브-블록들로 맵핑할 수 있다. 각각의 이러한 FEC 전송 블록의 경우, 컴포넌트는 각각의 서브-블록의 동일한 수의 서브-심볼들을 채울 수 있으므로, 각각의 FEC 전송 오브젝트가 각각의 서브-블록 내에서 서브-심볼들의 연속 세트를 채운다.

[0218] 예로서, FEC 전송 오브젝트들의 수가 0이고, FEC 전송 오브젝트(i) 내 심볼들의 수가 Ki라고 가정한다. Kt가 Ki의 i=0 내지 0-1의 합이라고 하면, 즉, Kt는 FEC 전송 오브젝트들 모두에서의 심볼들의 총 수이다. 각각의 j = 0 내지 Z-1의 경우, N_j는 소스 블록(j)에 할당된 소스 심볼들의 수라고 한다. 이 예에서, 컴포넌트는 표준 방법들(IETF RFC 6330에 설명된 것)을 이용하여 서브-블록당 서브-심볼 크기와 소스 블록당 심볼들의 수를 계산할 수 있다. 그런 다음, 각각의 오브젝트 i = 0 내지 O-1의 경우, 컴포넌트는 Z개의 소스 블록들 중에서 K_i의 값을 분할할 수 있으므로, K_i,_j는 소스 블록(j)으로 할당될 FEC 전송 오브젝트(i)의 심볼들의 수이다. 이는, 라운드 로빈 방식으로 소스 블록들을 통과하여 진행하고 제 1 오브젝트의 심볼들 모두가 할당될 때까지 제 1 오브젝트의 하나의 심볼을 소스 블록들 각각으로 할당한 후, 그리고 라운드 로빈의 그 포인트부터 계속하고 제 2 오브젝트의 심볼들 모두가 할당되었을 때까지 제 2 오브젝트의 하나의 심볼을 소스 블록들 각각으로 할당하는 식에 의해 달성될 수 있다. 이러한 동작들(즉, 라운드 로빈 방식으로 소스 블록들을 통과하여 진행하는 것 등)은, 오브젝트들의 심볼들의 Kt 모두가 소스 블록들로 할당될 때까지 반복적으로 수행될 수 있다. 이후, 컴포넌트는 FEC 전송 오브젝트들의 부분들을 FEC 인코딩 오브젝트의 소스 블록들 각각으로 할당할 수 있다. 이는 각각의 FEC 전송 오브젝트의 처음부터 시작함으로써 달성될 수 있으며, T는 심볼 크기이고, i = 0 내지 O-1이고, j = 0 내지 Z-1이며, 오브젝트(i)의 다음 K_i,_j*T 바이트들이 소스 블록 j으로 할당된다. 이후, 컴포넌트는 각각의 소스 블록으로 할당된 FEC 전송 오브젝트들의 부분들을 소스 블록들의 서브-블록들로 할당할 수 있다. k = 0 내지 N-1인 경우, SS_k는 서브-블록(k)에 대한 바이트 단위의 서브-심볼 크기라고 한다. 그런 다음, FEC 전송 오브젝트(i)의 부분이 소스 블록(j)의 서브-블록(k)으로 할당될 수 있으며, SS_k* K_i,_j 바이트이다. 이러한 방식으로 FEC 인코딩 오브젝트를 형성함으로써, 컴포넌트는 시스템으로 하여금 상기 논의된 바람직한 특성들, 특징들 또는 목적들 모두를 달성하거나 또는 유지하게 할 수 있다.

[0219] 다양한 실시예들은 복구 플로우 선언(declaration)을 생성하거나 또는 이용하도록 구성된 컴포넌트들을 포함할 수 있다. 복구 플로우 선언은, 보호 타입(동기화 또는 동기화해제)을 결정하기에 적절한, 소스 플로우들에 대한 시그널링 동작들을 수행하기 위한 방법을 결정하기에 적절한, 소스 플로우들에서 보호할 소스 오브젝트들을 결정하기에 적절한, 그리고 복구 플로우에 의해 보호될 소스 플로우들을 결정하기에 적절한 정보를 포함할 수 있다. 보호 타입은 패킷들의 헤더 포맷의 결정 시에 유용할 수 있다. 복구 플로우 선언은 또한, 소스 플로우들이 그들의 FLID에 의해 식별될 수 있도록 복구 플로우에 의해 보호되는 소스 플로우들을 나열할 수 있다. 복구 플로우 선언은 또한, 그 나열 순서가 FEC 전송 오브젝트들의 연결 순서에 대응하도록 소스 플로우들을 나열할 수 있다. 일 실시예에서, 복구 플로우 선언은 FEC OTI 필드들 또는 값들을 포함할 수 있다.

[0220] 하나의 동기화된 소스 플로우를 보호하는 복구 플로우 선언은 서버 또는 수신기 디바이스에 다음과 같이 나타내어질 수 있다:

[0221] 플로우 선언의 상기 예에서, 플로우의 타입은 flow_type 값, 이 경우 "repair"로 나타내어지고, 이 플로우에 대한 플로우 식별자는 FLID 값, 이 경우 "20"으로 나타내어지고, 복구 타입은 repair_type 값, 이 경우 "synchronized"으로 나타내어지고, 이 복구 플로우에 의해 보호된 소스 플로우들이 source_FLIDs 값들, 이 경우 FLID "5"를 갖는 소스 플로우로 나타내어진다.

[0222] 일 실시예에서, FEC OTI는 FEC Encoding ID = 6(이는 IETF RFC 6330에 지정된 RaptorQ 코드에 대응함), Al = 8(이는 8-바이트 정렬이 사용되는 것을 나타냄), T=1280(이는 심볼들이 크기가 1280 바이트들인 것을 나타냄), Z=1 및 N=1(이는 FEC 전송 오브젝트가 하나의 소스 블록과 소스 블록 당 하나의 서브-블록(즉, 서브-블록킹이 사용되지 않음)을 포함한다는 것을 나타냄)을 포함한다. 복구 플로우 선언들의 경우, repair_type 및 source_FLIDs 값들뿐만 아니라 FEC OTI가 제공된다.

[0223] 도 9a 및 도 9b는 상기 논의된 예시적인 복구 플로우 선언에 대응하는 FEC 인코딩 오브젝트들 및 복구 패킷들을 도시한다.

[0224] 도 9a의 상부 부분은 상기 논의된 예시적인 복구 플로우 선언에 해당하는 FEC를 수행에 사용하기에 적절한 복구 패킷들에 포함될 수 있는 다양한 데이터-필드들을 도시한다. 구체적으로, 도 9a는, 복구 FLUTE 헤더(902)가 FLID 필드와 OSN 필드를 포함할 수 있다는 것, 복구 FEC 페이로드 ID(904)가 TOL 필드와 ESI 필드를 포함할 수 있다는 것, 그리고 FEC 인코딩 오브젝트(906)가 FEC 전송 오브젝트를 포함할 수 있다는 것을 도시한다.

[0225] 902와 904에 도시된 복구 패킷 헤더 및 위에서 나타내어진 대응하는 플로우 선언은, 복구 패킷이 FEC 인코딩 오브젝트(906)로부터 생성된 복구 심볼들을 전달한다는 것을 나타낸다. 이 예에서, 하나의 소스 오브젝트가 각각의 FEC 인코딩에 의해 보호된 FEC이기 때문에, FEC 인코딩 오브젝트(906)는, FEC 인코딩 오브젝트(906)의 소스 블록들의 수(Z)와 서브 블록들의 수(N) 둘 모두가 1인 경우 그 소스 오브젝트에 대응하는 FEC 전송 오브젝트와 일치한다. FEC 인코딩 오브젝트(906)의 길이는 삼십오(35)개의 심볼들이고, 이는 복구 FEC 페이로드 ID(904)의 TOL 필드의 값에 해당한다. 이 예에서, 이 복구 패킷에서 전달되는 복구 심볼은 ESI=37을 갖는다.

[0226] 2개의 동기화된 소스 심볼들을 보호하는 예시적인 복구 플로우 선언은 다음과 같이 서버 또는 수신기 디바이스에 나타내어질 수 있다:

[0227] 플로우 선언의 위의 예에서, 플로우의 타입은 flow_type 값, 이 경우 "repair"로 나타내어지고, 이 플로우에 대한 플로우 식별자는 FLID 값, 이 경우 "21"로 나타내어지고, 복구 타입은 repair_type 값, 이 경우 "synchronized"으로 나타내어지고, 이 복구 플로우에 의해 보호된 소스 플로우들이 source_FLIDs 값들, 이 경우 FLID "6" 및 "7"을 갖는 소스 플로우로 나타내어진다. FEC OTI는 앞의 예들에서와 동일하다.

[0228] 다양한 실시예들에서, FEC 복구를 이용하는 소스 오브젝트의 부분들을 보호하기 위해서, 템블릿된 TOI 범위가 FEC 복구 플로우 선언의 부분으로서 제공될 수 있다. 예를 들어, 이 TOI 범위는, 복구 TOI들 10 내지 19는 소스 플로우로부터의 소스 오브젝트 1을 보호하고, 복구 TOI들 20 내지 29는 소스 오브젝트 2를 보호하는 식이라는 것을 식별할 수 있다. 아래는 이러한 FEC 복구 플로우 선언의 예이다.

[0229] 위의 예에서, 소스 TOI 마다 선언된 열(10)개의 복구 TOI들이 존재한다. 복구 TOI들 1-10은, FLID=6 및 FLID=7을 갖는 소스 플로우로부터 TOI=1을 갖는 소스 오브젝트들의 부분들을 보호하기 위해 예비된다. 복구 TOI들 11-20은, FLID=6 및 FLID=7을 갖는 소스 플로우로부터 TOI=2를 갖는 소스 오브젝트들의 부분들을 보호하기 위해 예비된다. 그러므로, 이러한 예에서, 열(10)개까지의 복구 TOI들이 FLID들 6 및 7을 갖는 2개의 소스 플로우로부터 소스 오브젝트들 각각의 쌍을 보호하는데 사용될 수 있다. 2개의 소스 플로우들로부터의 소스 오브젝트들의 상이한 쌍들에 대해, 할당된 최대(이러한 예에서는 10)까지 사용된 상이한 수의 복구 TOI들이 존재할 수도 있다. 즉, 소스 TOI=3을 갖는 소스 오브젝트들의 쌍에 대해 사용된 하나(1)의 복구 TOI, 예를 들어, 복구 TOI 30만이 존재할 수도 있다. 한편, 소스 TOI=4를 갖는 소스 오브젝트들의 쌍에 대해 사용된 열(10)개의 복구 TOI들, 예를 들어, 복구 TOI들, 40, 41,..., 49가 존재할 수도 있다. 소스 TOI=5를 갖는 소스 오브젝트들의 쌍에 대해 사용된 제로(0)의 복구 TOI들이 존재할 수도 있다.

[0230] 따라서, 소스 오브젝트들의 부분들의 상이한 수들의 FEC 보호들이 소스 오브젝트들의 상이한 쌍들에 대해 제공될 수도 있다. 추가적으로, 동일한 쌍의 소스 오브젝트들에 대해 제공된 2개의 상이한 FEC 보호들은, 소스 오브젝트들의 중첩하지 않는 부분들 또는 소스 오브젝트들의 중첩 부분들을 보호할 수도 있다.

[0231] 예를 들어, 복구 TOI 40과 연관된 FEC 보호는, TOI=4 및 FLID=6을 갖는 소스 오브젝트의 첫번째 절반 및 TOI=4 및 FLID=7을 갖는 소스 오브젝트의 첫번째 절반의 번들링된 보호를 제공할 수도 있다. 복구 TOI 41과 연관된 FEC 보호는, TOI=4 및 FLID=6을 갖는 소스 오브젝트의 두번째 절반 및 TOI=4 및 FLID=7을 갖는 소스 오브젝트의 두번째 절반의 번들링된 보호를 제공할 수도 있다. 복구 TOI 42와 연관된 FEC 보호는, TOI=4 및 FLID=6을 갖는 소스 오브젝트의 중간 절반 및 TOI=4 및 FLID=7을 갖는 소스 오브젝트의 중간 절반의 번들링된 보호를 제공할 수도 있다.

[0232] 상기 예에서, 각각의 소스 오브젝트에 대한 TOI는, 복구 플로우의 각각의 복구 패킷의 복구 FEC 페이로드 ID(952)에서 전달되지 않는다(또는 전달되도록 요구되지 않는다). 이것은, 소스 오브젝트 TOI가 FEC 복구 플로우 선언에서 전달된 템플릿된 TOI 범위, 및 각각의 복구 패킷의 복구 FEC 페이로드 ID(952)에서 전달된 복구 플로우 TOI에 기초하여 결정될 수도 있기 때문이다.

[0233] 도 9b의 상단 부분은, 소스 오브젝트의 부분들에 대해 FEC를 수행할 시에 사용하기에 적절한 복구 패킷들에 포함될 수도 있는 다양한 데이터 필드들을 도시한다. 상세하게, 도 9b는, 복구 FLUTE 헤더(902)가 FLID 필드 및 OSN 필드를 포함할 수도 있다는 것을 도시한다. 복구 FEC 페이로드 ID(952)는 시작 바이트 포지션(SBP) 필드, 전송 오브젝트 길이(TOL) 필드, 및 ESI 필드를 포함할 수도 있다. TOL은 소스 심볼들의 전송 오브젝트의 크기(심볼 단위)일 수도 있다.

[0234] 도 9b는 또한, FEC 인코딩 오브젝트(954)가 보호될 소스 오브젝트의 부분, 및 (소스 오브젝트의 부분과 크기 사이에서 가급적 몇몇 패딩 바이트들을 이용하여) 보호될 소스 오브젝트의 부분의 바이트 단위의 크기를 포함할 수도 있다는 것을 도시한다. 도시된 예에서, SBP=1500 및 TOL=4는, 보호될 부분적인 소스 오브젝트가 소스 오브젝트 내의 바이트 포지션 1500에서 시작한다는 것을 표시한다. 심볼 크기가 1000바이트이면, TOL=4이므로, 소스 오브젝트의 FEC 보호된 부분은 크기가 3001바이트들과 3996바이트들 사이에 있다, 이러한 예에서, FEC 보호될 부분적인 소스 오브젝트 크기를 전달하기 위해 FEC 인코딩 오브젝트의 마지막에 4바이트 필드가 존재하기 때문에, 부분적인 소스 오브젝트 크기는 최대 3996바이트들이며, 따라서, TOL=4이고 심볼 크기가 1000바이트인 경우, 부분적인 소스 오브젝트의 크기는 크기가 최대 1000*4-4=3996바이트들일 수 있다. 그러므로, (이러한 실시예에서 명시적으로 시그널링되지 않는) 종료 바이트 포지션은 4500(1500+3001-1)과 5495(1500+3996-1) 사이에 있다. FEC 인코딩 오브젝트(954)의 보호된 부분의 크기(바이트 단위)가 FEC 인코딩 오브젝트(954)의 마지막에서 전달되므로, 실제 종료 바이트 포지션은, FEC 인코딩 오브젝트(954)의 FEC 디코딩 이후에 결정될 수도 있다. 도시된 예에서, FEC 인코딩 오브젝트(954)의 바이트 단위의 크기는 3500으로 도시되며, 종료 바이트 포지션은 소스 오브젝트 내에서 4999(1500+3500-1)이다.

[0235] 다른 실시예에서, 복구 FEC 페이로드 ID(952)는, 보호된 각각의 완전한 또는 부분적인 소스 오브젝트에 대한 시작 바이트 포지션(SBP) 필드 및 종료 바이트 포지션(EBP) 필드, 및 ESI 필드를 포함할 수도 있다. 보호될 각각의 소스 오브젝트에 대해, FEC 인코딩 오브젝트(954)는 보호될 소스 오브젝트의 부분을 포함할 수도 있다.

[0236] 도 10의 상단 부분은, 2개의 동기화된 소스 플로우들에 대해 FEC를 수행할 시에 사용하기에 적절한 복구 패킷들에 포함될 수도 있는 다양한 데이터 필드들을 도시한다. 도 10에 도시된 예는 상술된 예시적인 복구 플로우 선언에 대응한다.

[0237] 도 10에 도시된 예에서, 복구 FLUTE 헤더(902)의 OSN 필드는 2개의 보호된 소스 플로우들에 대한 것이며, FEC 인코딩 오브젝트(906)는, OSN 4를 갖는 오브젝트에 대해, FLID=6을 갖는 FEC 전송 오브젝트와 FLID=7을 갖는 FEC 전송 오브젝트의 연쇄를 포함한다. 보호되는 FEC 전송 오브젝트들의 길이들은, 오브젝트들이 선언에서 리스팅되는 순서와 같은 적절한 순서(즉, 18, 10)로 복구 FEC 페이로드 ID(904)에서 2개의 FEC 전송 오브젝트들의 TOL들을 리스팅함으로써 식별될 수도 있다.

[0238] 2개의 동기화되지 않은 소스 플로우들을 보호하는 예시적인 복구 플로우 선언은 다음과 같이 서버 또는 수신기 디바이스에서 표현될 수도 있다:

[0239] 플로우 선언의 위의 예에서, 플로우의 타입은 flow_type 값, 즉 이러한 경우에는 "복구"에 의해 표시된다. 이러한 플로우에 대한 플로우 식별자는 FLID 값, 즉 이러한 경우에는 "22"에 의해 표시된다. 복구 타입은 repair_type 값, 즉 이러한 경우에는 "동기화되지 않음"에 의해 표시된다. 이러한 복구 플로우에 의해 보호된 소스 플로우들은 source_FLID 값들, 즉 이러한 경우에는 FLID들 "8" 및 "9"를 갖는 소스 플로우에 의해 표시된다. FEC OTI는 이전의 예들에서와 동일하다.

[0240] 상이한 데이터-필드들은, 그들이 소스 오브젝트의 부분들에 대해 FEC를 수행할 시에 사용하기에 적절하도록 복구 패킷들에 포함될 수도 있다. 예를 들어, 복구 FEC 페이로드 ID(904)는, 오브젝트의 보호된 부분들에 대한 심볼 또는 바이트 범위들을 식별할 시에 사용하기에 적절한 각각의 보호된 부분에 대한 시작 포지션(Start Pos) 필드 및 종료 포지션(End Pos) 필드를 포함할 수도 있다.

[0241] 도 11의 상단 부분은, 2개의 동기화되지 않은 소스 플로우들에 대해 FEC를 수행할 시에 사용하기에 적절한 복구 패킷들에 포함될 수도 있는 다양한 데이터 필드들을 도시하며, 상술된 2개의 동기화되지 않은 소스 플로우들을 보호하는 예시적인 복구 플로우 선언에 대응한다. 도 11에 도시된 예에서, 복구 FLUTE 헤더(902)는, 오브젝트들, 즉 "source_FLIDs" 필드를 통해 복구 플로우 선언에서 식별된 오브젝트들(즉, 8 및 9의 FLID를 갖는 오브젝트들) 각각에 대한 OSN 필드(OSN1, OSN2)를 포함한다.

[0242] 다양한 실시예들은, 소스 플로우들 또는 복구 플로우들 중 어느 하나에 대해, 오브젝트 시퀀스 번호 표시자(OSNI) 필드 또는 값에서 오브젝트 시퀀스 번호(OSN)를 표현할 수도 있다. OSNI는, 동기화되거나 또는 동기화되지 않은 복구 플로우 보호를 위해 OSN을 시그널링하기 위한 짧은 형태일 수도 있다. OSNI는 또한, 오브젝트가 보호된 오브젝트들의 현재의 번들에서 FEC 보호되는지 또는 보호되지 않는지를 표시하기 위해 사용될 수도 있다. 즉, 제로의 OSNI 값은, 어떠한 소스 오브젝트도 보호되지 않는다는 것을 표시할 수도 있지만, 비-제로 OSNI 값은, 소스 오브젝트가 번들 내에서 보호될 것이라는 것을 표시할 수도 있다.

[0243] 다양한 실시예들은, 보호할 소스 오브젝트가 존재하는 경우, OSIN 값을 ((OSN 모듈로 255)+1)로 셋팅할 수도 있다. OSNI 값으로부터 OSN으로의 맵핑은, 보호된 소스 플로우에 대한 소스 플로우 선언에서의 OSIN 값과 시작 및 종료 송신 시간 정보의 결합에 기초하여 행해질 수도 있다.

[0244] 일 예로서, 소스 플로우의 각각의 소스 오브젝트에 대한 송신의 지속기간이 이(2)초이고, 소스 오브젝트들에 대한 송신들이 시간상 연속적이라고 가정한다. OSNI=191을 갖는 소스 패킷이 수신되는 경우, 송신의 총 지속기간이 1401초라고 추가적으로 가정한다. 이러한 경우, OSNI=191에 맵핑하는 가능한 OSN 값들은 OSN=190, 445, 700, 955, 1210 등을 포함한다. 그러나, OSN=190을 갖는 소스 오브젝트는 시간 380 내지 382초의 간격 동안 송신되고, OSN=445를 갖는 소스 오브젝트는 시간 890 내지 892초의 간격 동안 송신되고, OSN=700을 갖는 소스 오브젝트는 시간 1400 내지 1402초의 간격 동안 송신되고, OSN=955를 갖는 소스 오브젝트는 시간 1910 내지 1912초의 간격 동안 송신되며, OSN=1210을 갖는 소스 오브젝트는 시간 2420 내지 2422초의 간격 동안 송신된다. 그러므로, 실시예의 수신기 디바이스는, 송신으로 1401초에서 수신된 OSNI=191을 갖는 소스 패킷이 OSN=700에 대응한다고 높은 신뢰도로 결정할 수도 있다.

[0245] 상기 예에서, OSNI=191에 맵핑하는 다른 OSN 값들을 갖는 패킷들이 시간 1401초에서 수신되는 경우, 수신기 디바이스가 자신의 가정/결정에서 부정확할 수도 있음을 유의한다. 그러나, 이것은 통상적으로, 패킷들이 소스 플로우 선언 내의 송신 시간 정보에서 광고된 것보다 적어도 500초 더 일찍 또는 더 늦게 송신 또는 수신되는 경우에만 발생한다. 예를 들어, OSN=445를 갖는 소스 오브젝트로부터의 패킷들(이는, 890초와 892초 사이에서 송신되는 것으로 의미됨)이 1401초에서 수신되는 경우, 실시예의 수신기 디바이스는, 패킷들이 그들의 스케줄링된 송신 시간보다 500초 더 늦게 도달한다고 결정할 수도 있고, 그에 따라 응답할 수도 있다.

[0246] 일 실시예에서, OSNI는 길이가 일(1) 바이트일 수도 있다. 이것은, 소스 또는 복구 플로우들 중 어느 하나에 대해, OSN을 사용하는 경우 요구될 수도 있는 삼(3) 바이트들과는 대조적으로, 시스템이 플로우마다 FLUTE 헤더의 1바이트만을 사용할 수도 있다는 것을 의미할 수도 있다. 복구 플로우들에 대해, OSNI는 또한, "어떠한 오브젝트도" 보호되지 않을 것이라는 것을 시스템이 시그널링하게 할 수도 있으며, 이는, OSNI의 값을 제로(0)와 동일하게 셋팅함으로써 달성될 수도 있다. 이러한 방식으로, 그 시스템은 가변 수의 보호된 소스 오브젝트들을 지원할 수도 있다. 즉, 보호된 소스 오브젝트들의 수는 변할 수도 있다.

[0247] OSN(짧은 형식) 대신 OSNI를 사용하여 3개의 동기화되지 않은 소스 플로우들을 보호하는 예시적인 복구 플로우 선언은 다음과 같이 서버 또는 수신기 디바이스에서 표현될 수도 있다:

[0248] 플로우 선언의 위의 예에서, 플로우의 타입은 flow_type 값, 즉 이러한 경우에는 "복구"에 의해 표시된다. 이러한 플로우에 대한 플로우 식별자는 FLID 값, 즉 이러한 경우에는 "23"에 의해 표시된다. 복구 타입은 repair_type 값, 즉 이러한 경우에는, (복구 패킷 헤더들에서 더 긴 OSN 필드들 대신) 짧은 OSNI 필드들을 사용하는 동기화되지 않은 보호를 표시하는 "동기화되지 않은 짧은"에 의해 표시된다. 이러한 복구 플로우에 의해 보호된 소스 플로우들은 source_FLIDs 값들, 즉 이러한 경우에는 FLID들 "8", "8" 및 "9"를 갖는 소스 플로우에 의해 표시된다. FEC OTI는 이전의 예들에서와 동일하다.

[0249] 도 12의 상단 부분은, 3개의 동기화되지 않은 소스 플로우들에 대해 FEC를 수행할 시에 사용하기에 적절한 복구 패킷들에 포함될 수도 있는 다양한 데이터-필드들을 도시하며, 직전에 설명된 예시적인 복구 플로우 선언에 대응한다. 도 12에 도시된 예에서, 복구 FLUTE 헤더(902)는 오브젝트들 각각에 대해 OSNI 필드(OSNI 1-3)를 포함한다. OSNI 필드들(OSNI 1-3)의 값들은, 그들의 대응하는 3개의 FEC 전송 오브젝트들의 ((OSN 모듈로 255)+1)와 동일할 수도 있다. FEC 인코딩 오브젝트(906)는, FLID=8을 갖는 2개의 FEC 전송 오브젝트들 및 FLID=9를 갖는 하나의 FEC 전송 오브젝트를 보호한다.

[0250] 이러한 예에서, FLID=8을 갖는 소스 플로우에 대해, 각각의 후속 소스 오브젝트에 대한 소스 패킷들은 두(2)개의 중첩하지 않는 초 동안 송신되고, FLID=9를 갖는 소스 플로우에 대해, 각각의 후속 소스 오브젝트에 대한 소스 패킷들은 4개의 중첩하지 않는 초 동안 송신되며, FLID=23을 갖는 복구 플로우에 대한 복구 패킷들은 그들이 보호하는 소스 오브젝트들에 대한 소스 패킷들이 송신되는 유사한 시간 인터벌에 걸쳐 송신된다고 가정한다. 도 12의 상단 부분에 도시된 헤더를 갖는 복구 패킷이 시간 1401초에서 수신된다고 추가적으로 가정한다. 이러한 경우, 실시예의 컴포넌트는, OSNI=191에 대응하는 FLID=8을 갖는 소스 플로우의 소스 오브젝트가 OSN=700을 갖는 소스 오브젝트이고, OSNI=192에 대응하는 FLID=8을 갖는 소스 플로우의 소스 오브젝트가 OSN=701을 갖는 소스 오브젝트이며, OSNI=96에 대응하는 FLID=9를 갖는 소스 플로우의 소스 오브젝트가 OSN=350을 갖는 소스 오브젝트라고 높은 신뢰도로 결정할 수도 있다.

[0251] 다양한 실시예들은, 소스 오브젝트들 및/또는 소스 오브젝트들의 부분들의 FEC 복원을 수행하도록 구성된 컴포넌트들을 포함할 수도 있다. 수신기 디바이스는, 그 복구 패킷에 대한 복구 플로우 선언에서 리스팅된 소스 플로우들의 FLID들(예를 들어, TSI 필드값), 복구 패킷의 복구 패킷 헤더 내의 OSN들, 및/또는 보호된 소스 오브젝트로부터의 소스 심볼들의 범위로부터의 수신된 복구 패킷에 의해 보호된 소스 오브젝트들 또는 부분들을 결정하도록 구성될 수도 있다.

[0252] 수신기 디바이스는, 복구 패킷의 복구 FEC 페이로드 ID(904) 내의 시작 및 종료 포지션 값 필드들로부터의 보호된 오브젝트들의 부분들에 대한 심볼들의 범위를 결정하도록 구성될 수도 있다. 수신기 디바이스는, 복구 패킷의 복구 FEC 페이로드 ID(904) 내의 TOL들로부터 보호된 소스 오브젝트들 각각에 대한 FEC 전송 오브젝트 크기(심볼 단위)를 결정할 수도 있다. 일 실시예에서, 수신기 디바이스는, FEC 전송 오브젝트 크기들을 합산함으로써 FEC 인코딩 오브젝트(906)의 크기를 결정하도록 구성될 수도 있다. 수신기 디바이스는, 심볼(또는 심볼들 또는 심볼들의 부분들)이 FEC 인코딩 오브젝트(906)로부터 어떻게 생성되는지를 결정하기 위해, 복구 패킷의 복구 FEC 페이로드 ID(904)에서 전달된 ESI를 사용할 수도 있다.

[0253] 수신기 디바이스는, 보호된 소스 오브젝트들 중 하나에 대한 수신된 소스 패킷으로부터 FEC 인코딩 오브젝트(906)로의 소스 데이터의 배치 및 아이덴티티를 결정하도록 구성될 수도 있다. 예를 들어, 보호된 소스 오브젝트들 중 하나에 대한 수신된 소스 패킷으로부터 FEC 인코딩 오브젝트(906)로의 소스 데이터의 배치 및 아이덴티티는, 소스 패킷 헤더에서 수신된 FLID 및 OSN, FEC 전송 오브젝트들의 TOL들, 심볼 범위, 및 소스 패킷의 소스 페이로드 ID 내의 바이트 오프셋으로부터 결정될 수도 있다. 수신기 디바이스의 FEC 디코더는, 소스 패킷들로부터 FEC 인코딩 오브젝트(906)(또는 오브젝트의 부분들)의 충분한 소스 데이터와 결합하여, 바이트 또는 심볼 범위 정보, 복구 패킷들로부터의 FEC 인코딩 오브젝트(906)에 대한 복구 심볼들, 및 적절하게 배치된 소스 패킷 데이터를 수신하는 것에 기초하여, FEC 인코딩 오브젝트(906)의 모두 또는 부분들을 복원할 수도 있다.

[0254] 수신기 디바이스는 FEC 인코딩 오브젝트(906)로부터 FEC 전송 오브젝트들(또는 전송 오브젝트들의 부분들)을 추출하도록 구성될 수 있다. 수신기 디바이스는 각각의 FEC 전송 오브젝트의 마지막에 있는 소스 오브젝트 크기 필드에 기초하여 FEC 전송 오브젝트들로부터, 및/또는 바이트 범위 정보로부터 소스 오브젝트들(또는 소스 오브젝트들의 부분들)을 추출할 수 있다.

[0255] 대안적 실시예에서, 바이트 범위를 사용하는 것과는 대조적으로, 컴포넌트들은 기존 FEC 스킴의 소스 FEC 페이로드 ID를 사용하도록 구성될 수 있다. 이 실시예는, 적어도 소스 전달 레벨에서, 기존 FEC 스킴들과의 역호환성을 더욱 잘 지원할 수 있다. 또한, 이 실시예는 오브젝트 번들링을 지원할 수 있다. 예컨대, FEC 동작들을 수행하거나 또는 본 출원에서 논의된 개선된 FEC 프레임워크를 적용하기 이전에, 소스 FEC 페이로드 ID는 바이트 범위로 변환될 수 있다. 본 실시예는 추가로, 개선된 FEC 프레임워크에 소스 프로토콜 컴포넌트의 임의적인 FEC 스킴들을 적용하는 것을 허용할 수 있고, 이는 하기에서 추가로 상세히 논의된다.

[0256] 다른 대안으로서, 컴포넌트는 복구 패킷 헤더들 내에서 대역내 시그널링을 회피하기 위하여 복구 플로우에 의해 보호되는 전송 소스 오브젝트들을 시그널링하도록 구성될 수 있다. 특히, 복구 패킷 헤더들에서 명시적으로 OSN들(또는 OSNI들)의 목록을 전달하는 대신에, 복구 플로우에 의해 보호되어야 하는 소스 오브젝트 TOI들은, 복구 플로우 선언 내의 템플레이팅을 사용하여 시그널링될 수 있다.

[0257] 다양한 실시예들은 복구 플로우들을 이용하여 청크 전달/수신을 수행하도록 구성된 컴포넌트들을 포함할 수 있다. 브로드캐스트 측에서, 서버는 청크들에서 그들이 이용가능해질 때 소스 오브젝트들을 송신할 수 있고, 그러한 오브젝트들에 대한 소스 패킷들 이후에 송신되는, 보호되는 소스 오브젝트들을 복구할 수 있고, 그리고 엔드-투-엔드 지연에 대한 자신의 기여를 최소화할 수 있다. 수신기 측에서, 수신기 디바이스는 소스 오브젝트가 청크들에서 도달할 때 이 소스 오브젝트를 복구시킬 수 있다. 소스 오브젝트 데이터는 이 소스 오브젝트 데이터가 수신될 때 클라이언트 애플리케이션에 이용가능해질 수 있다. 심지어 FEC 디코딩이 필요하지 않더라도, 오브젝트에 대해 복구가 수신될 때에만, 수신기 디바이스는 제 1 소스 오브젝트 재생을 재생할 수 있다. 이는, 후속하는 소스 오브젝트들에 대해 FEC 디코딩이 필요할 때 미래에 스톨들을 방지한다. 대안적으로, FEC 인코딩이 소스 오브젝트들의 부분들에 적용될 수 있고, 이는 소스 오브젝트들의 부분들의 FEC 디코딩을, 이 부분들이 수신기 디바이스에 도달할 때 허용하고, 이에 따라 수신기 디바이스에서의 더욱 즉각적인 플레이백을 허용한다.

[0258] 실시예에서, 수신기 디바이스는 소스 오브젝트가 수신된 직후에 제 1 소스 오브젝트의 플레이백/렌더링을 시작하도록 구성될 수 있다. FEC 디코딩을 요구하는 후속하는 패킷 분실은, FEC 복구의 도달을 기다리면서 스톨을 트리거링할 수 있다. 개선된 미디어 플레이아웃 시스템들은, 미디어의 플레이아웃 레이트를 조절함으로써, 예컨대 공칭 비디오 프레임 레이트보다 더 낮은 비디오 프레임 레이트로 플레이함으로써, 또는 플레이아웃 시간을 확장시키기 위해 오디오 프로세싱을 사용함으로써 이러한 FEC 기술들을 결합할 수 있다.

[0259] 추가적인 실시예에서, 정보를 오브젝트들로 패키징하는 방법들은, FLUTE/3GPP MBMS를 개선시키는 위에서 설명된 것들과 유사한 능력들 및 이득들 그리고 기능성들을 제공하도록 MPEG 미디어 전송(MMT)을 개선시키기 위해 MMT 내에서 일반 파일들 및 에셋들(assets)의 전송을 제공하도록 확장될 수 있다. 이 실시예는 통상적으로 브로드캐스트 또는 멀티캐스트 모드에서 네트워크를 통해 전달되어야 하는 관련된 파일들의 시퀀스(예컨대, 파일들의 시퀀스로 파티셔닝되는 비디오 또는 오디오 스트림)를 전달하는 문제점을 해결한다. 동기를 부여하는 예는 DASH 세그먼트들을 전달하는 것인데, 여기서 각각의 세그먼트는 오디오 또는 비디오의 파일이거나, 또는 다중화된 오디오/비디오 DASH 표현이다.

[0260] MBMS를 통해 DASH 세그먼트들을 전달하기 위한 기존 솔루션들이 존재하지만, 이들 기존 솔루션들은, 파일들의 시퀀스가 논리적으로 관련됨을 표시하거나 또는 시그널링할 능력이 없고, 및/또는 세그먼트들, 파일들, 오브젝트들, 엔티티들, 스트림들 등 간의 관계들을 특정할 능력이 없다. 위에서 설명된 바와 같이, 우리는 본원에서 이들 능력들 및 시그널링을 이용하여 MBMS를 개선시키는 방법들을 설명한다. 본원에 설명되는 실시예들은 또한, FLUTE/3GPP MBMS 프로토콜 슈트에 대해 위에서 설명되는 동일한 전체 시스템 아키텍처 및 방법들에 관하여 MPEG MMT 프로토콜 슈트를 개선시키는 새로운 시그널링, 프로토콜들, 프로시저들 및 방법들을 제공할 수 있고, 그리고 또한, 위에서 설명된 전체 방법들 및 시그널링 동작들을 개선할 수 있다.

[0261] 개괄해서, 이 실시예는 MMT 프로토콜들을 통해 일반 에셋들의 전달을 위한 솔루션을 제공한다. 일반 에셋은, 논리적으로 그룹핑되고 그리고 애플리케이션에 대해 어떤 공통성을 공유하는 하나 이상의 파일들, 예컨대 DASH 표현의 세그먼트들, MPU들의 시퀀스 등일 수 있다. 컴포넌트들은 GFD(General File Delivery) 프로토콜을 통해 일반 에셋을 전달하기 위해 GFDS(General File Delivery Session)을 사용하도록 구성될 수 있다.

[0262] 전송될 일반 오브젝트를 포함하는 페이로드를 위해 일반 에셋 또는 오브젝트에 대한 새로운 데이터 타입이 정의될 수 있다. 일반 오브젝트들을 전달하는 패킷들은 일반 페이로드 헤더를 가질 수 있다. GFD 세션 내에서 전달되는 각각의 파일은 전송 전달 정보와 연관될 수 있다. 이는 전송 길이 및 전송 코딩과 같은 정보를 포함할 수 있지만, 이들로 제한되지는 않는다. 전송 코딩에 대해, 인-밴드 메타-정보가 없는 파일들, 인-밴드 메타-정보를 갖는 파일들의 전달을 가능하게 하고, 그리고 인-밴드 메타-정보를 갖는 파일들의 점진적 전달을 가능하게 하는 상이한 타입들이 정의될 수 있다.

[0263] 일반적으로, 프로토콜 패킷들을 해석하기 위하여, MMT 프로토콜은 수신기에서의 세션 정보의 존재 및 이용가능성에 의존한다. 세션 정보는 플로우를 설명할 수 있고, 플로우를 통해 전달되는 오브젝트들이 수신기 디바이스에 의해 어떻게 해석 및/또는 액세스되어야 하는지를 설명할 수 있다. 실시예에서, 이러한 세션 정보는 하나 이상의 코드 포인트들에서 정의되고, 포함되고, 및/또는 전달될 수 있다. 예컨대, 코드 포인트는, 관련된 오브젝트들의 시퀀스 또는 패킷이 이 코드 포인트에서 정의되는 제한들의 특정 세트에 부합함을 시그널링하는데 사용될 수 있다. 이러한 실시예들에서, 패킷_id 속성 및 값이, 플로우 ID(FLID)를 참조하여 위에서 논의된 동작들을 달성하는데 사용될 수 있다. 따라서, MMT 내에서 일반 파일들 및 에셋들을 전송하는 상황에서, 패킷_id는 위에서 논의된 FLID 속성과 동일하거나 또는 이에 대응할 수 있다.

[0264] 실시예들은 컨텐츠를 HTTP를 통해 전달할 때에만 통상적으로 이용가능한 정보를 오브젝트 또는 관련된 오브젝트들의 시퀀스에 할당하도록 구성된 컴포넌트들을 포함할 수 있다. 실시예들은, 정보를 오브젝트 또는 오브젝트들의 시퀀스에 할당하고, 이러한 정보를 효율적인 방식으로 전달 및 사용하도록 구성된 컴포넌트들을 포함할 수 있다. 이는, 정적이고 다수의 오브젝트들에 대해 동일한 정보를, 세션 정보를 정의하는 코드 포인트에 부가함으로써 달성될 수 있다.

[0265] 간략하게, 코드 포인트는, 이 코드 포인트 시그널링으로 전달되는 임의의 오브젝트의 최대 전송 길이 및 파일 전달 모드와 같은 다양한 특성들을 정의하거나, 포함시키거나, 또는 특정할 수 있다. 부가하여, 코드 포인트는 하기의 정보 중 임의의 정보를 포함할 수 있다: 오브젝트들의 실제 전송 길이; 엔티티-헤더에 존재할 수 있는 임의의 정보; TOI 및 패킷_id 파라미터들(존재하는 경우)을 사용하는 컨텐츠-위치-템플릿; 및 컨텐츠에 관한 특정 정보(예컨대, 컨텐츠가 패키지되는 방식 등).

[0266] 단일 세션에 특성들의 다수의 부류들이 존재할 수 있다. 실시예에서, 특성들의 부류를 정의하기 위해 각각의 코드 포인트가 생성될 수 있고, 세션에 대한 특성들의 다수의 부류들을 통신시키기 위해 다수의 코드 포인트들이 사용될 수 있다.

[0267] 실시예에서, 각각의 코드 포인트는 관련된 오브젝트들의 시퀀스의 특정 오브젝트, 또는 관련된 오브젝트들의 특정 서브시퀀스에 특정하게 되도록 생성될 수 있다. 즉, 오브젝트들의 시퀀스의 각각의 오브젝트는 하나의 코드 포인트를 참조할 수 있다. 실시예에서, 코드 포인트들은 템플릿 파일 또는 유사한 데이터 구조에서 정의될 수 있다.

[0268] 실시예들은 하나의 세션 내에서 다수의 코드 포인트들을 시그널링하도록 구성된 컴포넌트들을 포함할 수 있다. 컴포넌트들은 HTTP RFC 2616에서 이용가능한 정보 및 특성들 전부, 그리고 부가적 또는 보충적 정보를 포함하는 엔티티 헤더를 코드 포인트들을 통해 생성할 수 있다. 컴포넌트들은 (예컨대, TOI 등을 사용하여) 구해질 수 있는 파라미터들을 포함하는 템플릿들과 같이 정적이지 않은 정보를 포함하는 코드 포인트들을 생성할 수 있다.

[0269] 실시예들은, 애플리케이션에 제공되어야 할 수 있는 파일들(예컨대, 구성 정보 문서(Composition Information document), 미디어 표현 설명(Media Presentation Description) 등)을 GFD 세션에서 전달하도록 구성된 컴포넌트들을 포함할 수 있다. 파일은 컨텐츠-위치로부터 제공 또는 도출되는 URI를 통해 참조될 수 있고, 이 컨텐츠-위치는 대역내에서든 또는 세션 설명의 부분으로서든 제공될 수 있다. 즉, 파일들을 참조하는 애플리케이션이 존재할 수 있고, 이러한 정보를 세션 설명에 포함시키는 것은, MMT 내에서 일반 파일들 및 에셋들을 전송시키기에 적절한 연결의 설정을 허용할 수 있다.

[0270] 실시예에서, 코드 포인트는 파일 또는 오브젝트를 전달하기 위한 상이한 방식들을 정의할 수 있다. 예컨대, 오브젝트는 어떠한 부가적인 정보도 포함하지 않는 정규 파일일 수 있다(즉, 정규 파일 모드). 오브젝트는 엔티티 헤더 및 파일을 포함하는 엔티티일 수 있다(즉, 정규 엔티티 모드). 오브젝트는 엔티티 헤더, 파일, 및 트레일러로서 전달될 수 있다(즉, 점진적 엔티티 모드).

[0271] 도 13a는 브로드캐스트 또는 멀티캐스트 네트워크를 통해 오브젝트들의 플로우에서 정보를 통신시키는 실시예 서버 방법(1300)을 예시한다. 블록 1302에서, 브로드캐스트 네트워크에 있는 서버의 서버 프로세서가 정보를 오브젝트로 패키징할 수 있다. 실시예에서, 블록 1302에서 정보를 오브젝트들로 패키징하는 것의 부분으로서, 서버 프로세서는 선택적 블록 1304에서 정보를 가변 크기 소스 패킷들로 패키징할 수 있다. 실시예에서, 서버 프로세서는 블록 1302의 부분으로서 정보를 패키징할 수 있고, 따라서 선택적 블록 1306에서 오브젝트들은 순방향 오류 정정 시맨틱스(semantics)를 포함하지 않는다. 실시예에서, 블록 1302의 부분으로서, 서버 프로세서는 선택적 블록 1308에서 정보를 FLUTE 오브젝트들로 패키징할 수 있다.

[0272] 블록 1310에서, 서버 프로세서는 파일 전달 테이블들(FDT들)의 각각의 오브젝트에 대한 첨부 메타데이터를 송신하지 않고도 브로드캐스트 네트워크를 통해 오브젝트들의 플로우에서 오브젝트들을 송신할 수 있다. 실시예에서, 블록 1310의 부분으로서, 서버 프로세서는 선택적 블록 1312에서 관련된 오브젝트들의 시퀀스로서 오브젝트들을 송신할 수 있다. 실시예에서, 블록 1310의 부분으로서, 서버 프로세서는 선택적 블록 1314에서 정보의 전부가 이용가능하기 이전에 오브젝트 송신들을 시작할 수 있다. 실시예에서, 블록 1310의 부분으로서, 서버 프로세서는 선택적 블록 1316에서 브로드캐스트 네트워크를 통해 FLUTE를 통해서 오브젝트들을 송신할 수 있다.

[0273] 도 13b는, 브로드캐스트 또는 멀티캐스트 네트워크를 통해 오브젝트들의 플로우에서 정보를 수신하고 전체 소스 오브젝트가 수신되었는지 또는 오브젝트의 적어도 어떤 부분이 수신된 소스 패킷들로부터 분실되는지를 결정하는 실시예 수신기 디바이스 방법(1350)을 예시한다. 블록 1352에서, 수신기 디바이스의 디바이스 프로세서는 브로드캐스트 또는 멀티캐스트 네트워크로부터 송신되는 소스 패킷들을 수신할 수 있다. 결정 블록 1354에서, 디바이스 프로세서는 수신된 소스 패킷들 중 임의의 소스 패킷이 "1"의 값을 갖는 B-플래그 데이터 필드를 포함하는지를 결정할 수 있다.

[0274] 디바이스 프로세서가 수신된 소스 패킷들이 "1"의 값을 갖는 B-플래그 데이터 필드를 포함함을 결정할 때(즉, 결정 블록 1354 = "예"), 블록 1356에서, 디바이스 프로세서는 자신이 오브젝트의 서픽스를 수신하였음을 결정할 수 있다. 블록 1358에서, 디바이스 프로세서는 "1"로 설정된 B-플래그를 갖는 패킷의 바이트 오프셋과 그 패킷의 패킷 페이로드 크기를 합산함으로써 오브젝트의 크기를 계산할 수 있다. 블록들 1360 및 1362에서, 디바이스 프로세서는 수신된 소스 패킷들의 패킷 페이로드 크기들 및 바이트 오프셋들로부터 분실되는 소스 오브젝트의 내부 부분들이 존재하는지 여부를 결정할 수 있다. 수신된 소스 패킷들로부터 분실되는 내부 부분이 존재하지 않음이 결정될 때(즉, 결정 블록 1362 = "아니오"), 블록 1364에서, 디바이스 프로세서는 수신된 소스 패킷들에 포함된 컨텐츠 및/또는 정보를 렌더링할 수 있다. 수신된 소스 패킷들로부터 분실되는 내부 부분이 존재함이 결정될 때(즉, 결정 블록 1362 = "예"), 선택적 블록 1366에서, 디바이스 프로세서는 복구 동작들, 예컨대, 정보를 부가로 수신하기를 기다리는 것, 정보가 재전송되기를 요청하는 것, 소스 오브젝트의 분실된 부분들을 FEC 디코딩하기 위해서, 수신된 복구 패킷들을 사용하는 것, 또는 저하된 품질을 갖는 컨텐츠를 제시하기 위해서, 수신된 패킷들을 프로세싱하는 것을 수행할 수 있다.

[0275] 디바이스 프로세서가 수신된 소스 패킷들이 "1"의 값을 갖는 B-플래그 데이터 필드를 포함하지 않음을 결정할 때(즉, 결정 블록 1354 = "아니오"), 블록 1368에서, 디바이스 프로세서는 오브젝트의 적어도 어떤 서픽스가 아직 수신되지 않았음을 결정할 수 있다. 선택적 결정 블록 1370에서, 디바이스 프로세서는, 타이머가 만료되었는지, 또는 오브젝트의 서픽스가 수신되지 않을 높은 확률이 존재함을 표시하기 위한 다른 테스트 조건이 충족되었는지를 결정할 수 있다. 디바이스 프로세서가, 타이머가 만료되지 않았음 또는 다른 테스트 조건들이 충족되지 않았음을 결정하는 경우(선택적 결정 블록 1370 = "아니오"), 블록 1352에서, 디바이스 프로세서는 부가적 소스 패킷들을 기다렸다가 수신할 수 있다.

[0276] 디바이스 프로세서가, 타이머가 만료되었음 또는 다른 테스트 조건이 충족되었음을 결정할 때(선택적 결정 블록 1370 = "예"), 선택적 블록 1366에서, 디바이스 프로세서는 다수의 복구 동작들 중 임의의 복구 동작, 예컨대, 소스 오브젝트의 분실된 부분들을 FEC 디코딩하기 위해서, 수신된 복구 패킷들을 사용하는 것, 또는 정보가 재전송되기를 요청하는 것, 또는 저하된 품질을 갖는 컨텐츠를 제시하기 위해서, 수신된 패킷들을 프로세싱하는 것을 수행할 수 있다.

[0277] 다양한 실시예들에서, 서버 및 수신기 컴포넌트들은 위에서 언급된 동작들, 방법들, 및 솔루션들 중 임의의 것 또는 전부가 기존 기술들 및/또는 구조들의 확장들로서 수행되거나, 달성되거나, 또는 구현될 수 있도록 구성될 수 있다.

[0278] 도 14a-b는 다양한 실시예들에 따라 컨텐츠를 통신시키기에 적절한 브로드캐스트 통신 시스템들(1400, 1420)의 논리적 및 기능적 컴포넌트들을 예시한다. 이러한 브로드캐스트 통신 시스템들(1400, 1420) 각각에서, 정보를 수신하고, 패키지하고, FEC 보호하고, 시그널링하고 그리고 통신시키기 위한 동작들은 동작들의 별개의 그리고 독립적인 그룹들 또는 카테고리들로 분할되고, 동작들의 각각의 그룹 또는 카테고리는 하나 이상의 하드웨어 및/또는 소프트웨어 컴포넌트들(예컨대, 서버 컴퓨팅 디바이스들 등)에 의해 수행될 수 있다. 이러한 그룹핑/조직화는 브로드캐스트 통신 시스템들(1400, 1420) 각각이 다양한 상이한 보호 스킴들 및 전달 기술들, 프로토콜들, 및 표준들을 더욱 잘 지원하도록 더욱 잘 허용할 수 있다.

[0279] 도 14a는 브로드캐스트 통신 시스템(1400)이 두 개의 주요 그룹들: 소스 전달 프로토콜(1402) 및 순방향 에러 정정(FEC) 프레임워크(1404)로 분할 또는 조직화될 수 있음을 예시한다. 시스템(1400)을 이러한 방식으로 분할/조직화하는 것은, 두 개의 비동기 층화 코딩(ALC) 인스턴스 생성들이 다중화되거나 또는 다른 방식으로 결합되도록 허용한다. 이는, 기존 FLUTE 프레임워크들을 포함하는 다양한 기존 기술들 및/또는 구조들을 통해 컨텐츠가 전달되도록 허용한다. 또한, 이러한 조직화/그룹핑은, 브로드캐스트 통신 시스템(1400)이 본원에 논의되는 특징들을 비롯해 기존 브로드캐스트 솔루션들과는 다른 다수의 개선들 및 이득들을 제공하도록 허용한다.

[0280] 도 14a에 예시된 예에서, 소스 전달 프로토콜(1402)은 소스 ALC 컴포넌트(1406)를 포함한다. 소스 ALC 컴포넌트(1406)는 소스 LCT를 포함하고, FEC의 이용을 요구하지 않도록(FEC 없음) 구성될 수 있다. FEC(forward error correction) 프레임워크(1404)는 오브젝트 번들링 컴포넌트(1414) 및 복구 ALC 컴포넌트(1408)를 포함할 수 있다. 복구 ALC 컴포넌트(1408)는 복구 LCT 및 FEC 스킴을 포함할 수 있다.

[0281] 소스 전달 프로토콜(1402)은 파일들(1410 및 1412)의 2개의 컬렉션들 내의 멀티미디어 컨텐츠를 인코딩한다. 각각의 컬렉션(1410, 1412)은 관련된 파일들의 그룹을 포함할 수 있다. 예로서, 제 1 컬렉션(1410)은 비디오 데이터 파일들을 포함할 수 있고, 제 2 컬렉션(1412)은 오디오 데이터 파일들을 포함할 수 있다. 각각의 컬렉션(1410, 1412)은 플로우일 수 있거나 플로우가 아닐 수 있다. 각각의 컬렉션(1410, 1412)에는 정적 메타데이터(정적 메타데이터 1, 정적 메타데이터 2)가 할당될 수 있다. 도 14a에 예시된 예에서, 제 2 컬렉션 내의 각각의 파일은 DMD(dynamic metadata)와 연관된다.

[0282] 시스템(1400)은 개별 오브젝트로서 시스템에서의 각각의 파일을 처리하도록 구성될 수 있고, 각각의 파일/오브젝트는 ALC 인스턴스생성(instantiation)을 통해 전달될 수 있다.

[0283] 소스 ALC 컴포넌트(1406)는 파일들, 오브젝트들, 플로우들, 번들들 또는 컬렉션들을 전달하도록 구성될 수 있다. 복구 ALC 컴포넌트(1408)는 FEC에 대한 파일들, 오브젝트들, 플로우들, 번들들 또는 컬렉션들을 유연하게 보호하도록 구성될 수 있다.

[0284] 시스템(1400)은 프로토콜을 식별하는 LCT/UDP에 대한 새로운 프로토콜 핸들러를 정의할 수 있다. 실시예에서, 시스템(1400)은 오브젝트들의 상이한 컬렉션들을 식별하고 파라미터들을 할당하기 위해 코드 포인트를 이용할 수 있다.

[0285] 시스템(1400)은 (예를 들어, 수신기 디바이스 내의) 클라이언트 애플리케이션에 가능하게는 최대 인터리빙 깊이와 함께, 사전에 오브젝트들 및/또는 전송들이 통지될 수 있도록 세션 정의에서의 오브젝트들의 전송에 대한 시그널링 및 오브젝트들의 바이트 범위들을 비순차적으로(out of order) 송신하는 것을 지원하도록 구성될 수 있다. 이것은 시스템(1400)이 오브젝트의 크기가 파일의 처음에 부가될 필요가 있는 포맷들을 지원하게 한다. 이것은 또한, 일단 동일한 오브젝트의 더 먼저 송신된 데이터보다 작은 바이트 범위 번호를 표시함으로써 헤더 데이터가 이용가능하면, 오브젝트의 컨텐츠 데이터가 먼저 송신되게 하고, 크기 필드/헤더가 나중에 송신되게 한다. 이것은 수신기 디바이스가 오브젝트를 재구성하게 하고, 헤더는 특정된 바이트 범위에 추가된다.

[0286] 실시예에서, 시스템(1400)은 시작 TOI, 종료 TOI 또는 둘 모두를 제공하도록 구성될 수 있고, 이는 제한된 리스트를 시그널링하기 위해 이용될 수 있다. 추가 실시예들에서, 코드 포인트는 이용 시 정적 FDI를 지칭할 수 있고, LCT 시간 헤더는 엔드-투-엔드 레이턴시 또는 지터를 측정하기 위해서 뿐만아니라, 서버 시간 및 클라이언트를 동기화하기 위해 이용될 수 있다. 복구 플로우는 세션 설명(1416) 및 코드 포인트에 대한 참조를 포함할 수 있고, 이는 상세히 설명된 보호 특성들을 획득하기 위해 이용될 수 있다.

[0287] 실시예에서, FEC 프레임워크 컴포넌트(1404)는 복구 패킷들만을 송신하도록 구성될 수 있다. 실시예에서, 시스템(1400)은 개별 오브젝트들의 크기의 송신을 가능하게 하기 위해 LCT 연장 헤더를 정의하도록 구성될 수 있다. 실시예에서, 시스템(1400)은 FEC가 보호되는 수퍼 오브젝트를 정의하도록 구성될 수 있다.

[0288] 도 14b는 2개의 컬렉션들(즉, 오브젝트들의 2개의 관련 그룹들)에 기초하여 FEC 복구 패킷을 생성하고, 다양한 실시예들에 따라 FEC 복구 패킷과 독립적인 오브젝트들을 수신기 디바이스에 전달하도록 구성되는 예시적 브로드캐스트 통신 시스템(1420)에서의 다양한 컴포넌트들 및 정보 플로우들을 예시한다. 도 14b에 예시된 예에서, 브로드캐스트 통신 시스템(1420)은 소스 프로토콜 컴포넌트(1424) 및 복구 프로토콜 컴포넌트(1426)로 조직화된다. 복구 프로토콜 컴포넌트(1406)는 소스 오브젝트 생성 컴포넌트(1434), 복구 ALC 컴포넌트(1436), LCT 컴포넌트(1438) 및 FEC 스킴 컴포넌트(1440)를 포함한다. 소스 프로토콜 컴포넌트(1424)는 소스 패킷 생성 컴포넌트(1428) 및 LCT 컴포넌트(1430)를 포함하고, 이들의 결합은 오브젝트들(예를 들어, 소스/전달 오브젝트들) 또는 오브젝트들의 플로우들/컬렉션들을 전달하도록 구성될 수 있다. 실시예에서, 소스 패킷 생성 컴포넌트(1428) 및/또는 LCT 컴포넌트(1430)는 ALC(Asynchronous Layered Coding) 인스턴스생성일 수 있다.

[0289] 소스 프로토콜 컴포넌트(1424)는 소스 데이터(1442)를 수신, 이용, 패키징 및 통신하도록 구성될 수 있다. 소스 프로토콜 컴포넌트(1424)는 전달 오브젝트들 또는 오브젝트들의 플로우들/컬렉션들을 통해 소스 데이터(1442)를 통신할 수 있다. 각각의 전달 오브젝트는 가능하게는, TSI(transmission session/stream identifier) 및 TOI(transmission object identifier)의 LCT 헤더 데이터 및 정적 메타데이터로부터의 정보와 결합하여, 애플리케이션에 대한 자립식(self-contained) 오브젝트일 수 있다.

[0290] 소스 프로토콜 컴포넌트(1424)는 정보 유닛들/엔티티들의 다양한 세트를 포함하는 소스 데이터(1422)를 수신 및 이용하도록 구성될 수 있고, 이들 각각은 상이한 특성들 또는 특징들을 가질 수 있다. 예를 들어, 소스 프로토콜 컴포넌트(1424)는 비-실시간 및 실시간 데이터의 결합, 단지 전체로서 액세스가능한 단일 데이터 파일(예를 들어, gzipped 파일 등)을 포함하고, 가변 크기들(예를 들어, 수 kBytes 내지 최대 GBytes)의 서브-유닛들(예를 들어, 파일들), 및/또는 개별적으로 액세스가능하지만 함께 유용한(예를 들어, 웹 페이지의 오브젝트들 등) 데이터 파일들의 컬렉션을 포함하는 소스 데이터(1402)를 수신 및 이용할 수 있다. 추가 예들로서, 소스 데이터(1402)는, 전체로서 BMSC(Broadcast Multicast Service Center) 상에서 이용가능하고 실시간 제약들 없이 분포되는 큰 멀티미디어 파일, 임의적 URL 이름들(예를 들어, HLS 분포에서의 하나의 표현)에 의해 언급되는 타임드(timed) 미디어 세그먼트들의 컬렉션, 공통 URL 패턴(예를 들어, DASH에서의 미디어 프리젠테이션에서의 표현)에 의해 언급되는 타임드 미디어 세그먼트들의 컬렉션, 미디어 프리젠테이션의 부분인 미디어 세그먼트, 공동으로 분포되고 공동으로 유발되는 다수의 미디어 컴포넌트들, 또는 서버에서 점진적으로 생성되고 서버가 전체 파일을 생성하기 전에 전송되는 미디어 파일을 포함할 수 있다. 또 다른 예로서, 소스 데이터(1402)는 수신기 디바이스가 미디어 파일(예를 들어, 프래그먼티드(fragmented) MP4 파일, DASH 온-디맨드(On-Demand) 포맷 표현 등)의 부분만을 수신한 이후 렌더링, 플레이 또는 소비를 시작할 수 있는 미디어 파일을 포함할 수 있지만, 이는 단지 서버에만 전체로서 이용가능하게 생성된다.

[0291] 소스 프로토콜 컴포넌트(1424)는 관련 오브젝트들의 컬렉션들(즉, 컬렉션 1 및 컬렉션 2)을 생성하기 위해 소스 데이터(1422)를 이용하도록 구성될 수 있다. 도 14b에 예시된 예에서, 소스 프로토콜 컴포넌트(1424)는 3개의 전달 오브젝트들(즉, 전달 오브젝트들 1-3) 및 정적 메타데이터(즉, 정적 메타데이터 1)를 포함하는 제 1 컬렉션(컬렉션 1)을 생성한다. 제 2 컬렉션(컬렉션 2)은 정적 메타데이터(즉, 정적 메타데이터 2) 및 DMD(dynamic metadata)와 연관된 3개의 전달 오브젝트들(즉, 전달 오브젝트들 1'-3')을 포함한다.

[0292] 실시예에서, 소스 프로토콜 컴포넌트(1424)는 다운로드 전달 세션으로서 세션 정보를 전달하도록 구성될 수 있다. 다운로드 전달 세션은 SDP(session description protocol) 유닛에 포함되거나, 이에 의해 설명될 수 있다.

[0293] 실시예에서, 소스 프로토콜 컴포넌트(1424)는 세션 정보 또는 소스 프로토콜의 이용을 설명하는 FEC 스킴을 시그널링하도록 구성될 수 있다. 실시예에서, 소스 프로토콜 컴포넌트(1424)는 SDP(session description protocol) 유닛을 통해 FEC 스킴을 시그널링하도록 구성될 수 있다.

[0294] 다양한 실시예들에서, 소스 프로토콜 컴포넌트(1424)는 정적 및/또는 동적 FDD(file delivery descriptor)들을 생성, 이용 또는 통신하도록 구성될 수 있다. 소스 프로토콜 컴포넌트(1424)는 각각의 다운로드 전달 세션에 대한 하나 또는 둘 이상의 정적 FDD 프래그먼트들을 생성, 이용 또는 통신할 수 있다. 소스 프로토콜 컴포넌트(1424)는 하나 또는 둘 이상의 정적 FDD 프래그먼트들을 단일 다운로드 전달 세션과 연관시킬 수 있다. 각각의 FDD는 SDP(Session Description Protocol) 유닛의 다운로드 전달 세션에 포함되는 @tsi 데이터-필드 값을 통해 식별될 수 있다. 실시예에서, 소스 프로토콜 컴포넌트(1424)는 그것이 FDT(File Delivery Table)의 모든 기능들을 복제하도록 FDD를 생성, 이용 또는 통신할 수 있다. 실시예에서, 소스 프로토콜 컴포넌트(1424)는 그것이, 이를테면, TOI 및 템플릿들을 이용함으로써, FDT의 균등물을 생성하기 위해 이용될 수 있도록 FDD를 생성, 이용 또는 통신하도록 구성될 수 있다.

[0295] 다양한 실시예들에서, 소스 프로토콜 컴포넌트(1424)는 소스 플로우 선언을 생성, 이용 및/또는 통신하도록 구성될 수 있다. 소스 플로우 선언은 USD(user service description)에 포함되고, 이를 통해 통신될 수 있다. 실시예에서, USD는 메타데이터 프래그먼트들을 포함하도록 생성될 수 있다. 각각의 메타데이터 프래그먼트는 정적 FDD(file delivery descriptor)를 특정하는 StaticFDD 데이터-필드를 포함할 수 있다. 각각의 StaticFDD 데이터-필드는 또한, 다양한 다른 데이터-필드들, 이를테면, @tsi 데이터-필드, @objectDeliveryMode 데이터-필드, @oufOfOrderSending 데이터-필드, @expires 데이터-필드, @complete 데이터-필드, @contentType 데이터-필드, @contentEncoding 데이터-필드, CodePoint 데이터-필드, File 데이터-필드 및 FileTemplate 데이터-필드를 포함할 수 있다. 이러한 데이터-필드들 각각은 소스 데이터, 전달 오브젝트들 또는 통신들의 다양한 특성들을 식별 또는 결정하기 위해 다양한 실시예의 컴포넌트들에 의해 이용될 수 있는 정보를 포함할 수 있다.

[0296] 예를 들어, @oufOfOrderSending 데이터-필드는 소스 데이터(1422)가 비순차적으로 송신되는지 여부를 결정하기 위해 이용될 수 있는 정보를 포함할 수 있다. @objectDeliveryMode 데이터-필드는 오브젝트 전달 모드를 식별하기 위해 이용될 수 있는 정보를 포함할 수 있다. @tsi 데이터-필드는 TSI(transmission session/stream identifier), 또는 LCT 헤더에서 정적 FDD(file delivery descriptor)가 할당되는 전송 세션을 식별하기 위해 이용될 수 있는 정보를 포함할 수 있다. 예를 들어, @tsi 데이터-필드는 전달 오브젝트 또는 전달 오브젝트들의 컬렉션을 해석하기 위해 이용되는 정적 FDD 인스턴스를 식별하는 TSI를 포함할 수 있다. 또한, @tsi 데이터-필드는 전달 오브젝트 또는 전달 오브젝트들의 컬렉션에 대한 (세션의 범위 내의) 고유한 식별자를 더 포함할 수 있다.

[0297] StaticFDD 데이터-필드의 CodePoint 데이터-필드는 패킷 헤더에서 이용되는 코드 포인트들을 식별하고 및/또는 특정 값들에의 맵핑들을 식별하는 정보를 포함할 수 있다. CodePoint 데이터-필드는 다양한 다른 데이터-필드들, 이를테면, @assignment 데이터-필드, @schemeIDURI 데이터-필드 및 @value 데이터-필드를 포함할 수 있다. @assignment 데이터-필드는 코드 포인트에 할당되는 CP 필드(코드 포인트 필드)의 값을 식별하는 정보를 포함할 수 있다. @schemeIDURI 데이터-필드는 코드 포인트를 정의하는 스킴을 식별하는 정보를 포함할 수 있다. @value 데이터-필드는 코드 포인트를 정의하는 스킴의 값을 식별하는 정보를 포함할 수 있다.

[0298] StaticFDD 데이터-필드의 파일 데이터-필드는 기존 FLUTE 솔루션들을 이용할 때 "파일 엘리먼트"에 전형적으로 포함되는 동일하거나 유사한 정보를 포함할 수 있다. 그러나, 기존 솔루션들에서 이용되는 "파일 엘리먼트"와는 달리, 파일 데이터-필드는 FEC 파라미터들을 포함하도록 요구되지 않는다. 또한, 파일 데이터-필드는 다양한 다른 데이터-필드들, 이를테면, @byteRange 데이터-필드를 포함할 수 있다. @byteRange 데이터-필드는 전달 오브젝트를 구성하는 파일의 바이트 범위를 식별하는 정보를 포함할 수 있다. 이러한 바이트 범위는 바이트-범위 특정 표현 또는 연속적 바이트 범위를 식별하는 표현으로서 표현 또는 포맷팅될 수 있다. 실시예의 컴포넌트들(예를 들어, 수신기 디바이스)은 전달 오브젝트가 전체 파일 또는 파일의 부분들을 포함하는지 여부를 결정하기 위해 이러한 정보를 이용할 수 있다. 예를 들어, 컴포넌트는 @byteRange 데이터-필드가 널(null), 엠티(empty)이거나, 값을 포함하지 않음에 대한 결정에 응답하여 전체 파일이 전달 오브젝트임을 결정할 수 있다.

[0299] StaticFDD 데이터-필드의 FileTemplate 데이터-필드는 파일 템플릿을 식별하기 위해 실시예의 컴포넌트들에 의해 이용될 수 있는 정보를 포함할 수 있고, 이는 HTTP 엔티티 또는 전달 오브젝트의 보디에 포함될 수 있다. FileTemplate 데이터-필드는 다양한 다른 데이터-필드들, 이를테면, @startTOI 데이터-필드 및 @endTOI 데이터-필드를 포함할 수 있다. @startTOI 데이터-필드는 전달되는 제 1 TOI를 식별하기 위해 이용될 수 있는 정보를 포함할 수 있다. @endTOI 데이터-필드는 전달되는 마지막 TOI를 식별하는 정보를 포함할 수 있다.

[0300] 다양한 실시예들에서, 소스 프로토콜 컴포넌트(1424)는 세션에서 전달되는 모든 파일들을 설명하도록 구성될 수 있다. 소스 프로토콜 컴포넌트(1424)는 리스트를 통해 또는 개별적으로 파일들을 설명할 수 있다. 소스 프로토콜 컴포넌트(1424)는 또한, 일회용(one-time) 정적 설명(예를 들어, 파일 전달 디스크립터)에서 정적 파일 정보를 포함하고, 동적 정보, 이를테면, URL/URI 정보를 생성하기 위해 헤더 필드들을 이용할 수 있다. 소스 프로토콜 컴포넌트(1424)는 오브젝트, 오브젝트들의 세트 또는 컬렉션을 설명하기 위해 이러한 기법을 이용할 수 있다. 실시예의 컴포넌트들은 본원에 설명된 다양한 기법들 중 임의의 것을 이용하여 오브젝트들의 그룹들 또는 컬렉션들을 식별할 수 있다. 예를 들어, TSI 값은 오브젝트들의 그룹 또는 컬렉션을 스코프(scope)할 수 있고, 이 경우, TOI 및/또는 바이트 범위는 오브젝트들의 그룹을 식별하기 위해 이용될 수 있다.

[0301] 다양한 실시예들에서, 소스 프로토콜 컴포넌트(1424)는 위치들 사이의 관계들, 이름들, 이용가능 시간들 및 전달될 오브젝트 또는 컬렉션과 연관된 다른 메타데이터를 시그널링하기 위해 템플릿들 및 템플릿 기법들을 이용하도록 구성될 수 있다. 이러한 템플릿들 및 템플릿 기법들은 오브젝트에 대한 URI, 오브젝트에 대한 전달 시간, FLID, OSN 및 URI 사이의 관계 등을 유도하기 위한 메커니즘을 제공하기 위해 이용될 수 있다.

[0302] 실시예에서, 소스 프로토콜 컴포넌트(1424)는 정적 파일 전달 디스크립터에 FileTemplate 엘리먼트 또는 데이터-필드를 포함시키도록 구성될 수 있다. FileTemplate 데이터-필드는, 이를테면, 전체 전달 오브젝트 또는 파일이 수신기 디바이스에서 수신된 이후, 대체 파라미터로 교체될 수 있는 식별자들을 포함할 수 있다. 예를 들어, FileTemplate 데이터-필드는 대응하는 LCT 패킷의 TSI로 대체될 수 있는 $TSI$ 식별자 및 대응하는 LCT 패킷의 TOI로 대체될 수 있는 $TOI$ 식별자를 포함할 수 있다.

[0303] 실시예에서, 소스 프로토콜 컴포넌트(1424)는 엔티티-헤더 필드들의 형태로 메타정보를 포함하고, 엔티티-보디(예를 들어, 파일, 오브젝트 등)의 형태로 컨텐츠를 포함하는 오브젝트들 또는 엔티티들을 전달하도록 구성될 수 있다. 소스 프로토콜 컴포넌트(1424)는 이를테면, 대역내 전달 기법들을 통해 및/또는 동적 방식으로 파일 그 자체와 동일한 전달 오브젝트에 파일 속성들을 포함시킬 수 있다. 예를 들어, 소스 프로토콜 컴포넌트(1424)는 대응하는 파일을 포함하는 동일한 전달 오브젝트를 통해 속성들, 이를테면, 컨텐츠-위치, 컨텐츠-크기, 컨텐츠-범위 등을 연관시키고 전달할 수 있다.

[0304] 다양한 실시예들에서, 소스 프로토콜 컴포넌트(1424)는 연장된 FDT 모드를 포함하는 다양한 FDT(file delivery table) 통신 모드들에서 동작하도록 구성될 수 있다. 연장된 FDT 모드에서 동작할 때, 소스 프로토콜 컴포넌트(1424)는 엔티티 헤더들에 전형적으로 포함되는 정보를 제공 또는 통신하기 위해 FDT들 및 FDT 연장들을 이용할 수 있다. FDT 연장들의 이용은 소스 프로토콜 컴포넌트(1424)가 FLUTE를 통해 HTTP 연장 헤더들 및 다른 HTTP 능력들을 시그널링하게 할 수 있다.

[0305] 소스 프로토콜 컴포넌트(1424)는, 파일 모드, 정규 엔티티 모드, 프로그레시브 엔티티 모드, 중복 FDT 모드, 보완 FDT 모드, 및 동적 FDT 모드와 같은 다양한 파일 전달 모드들에서 동작하도록 구성될 수 있다. 실시예에서, 소스 프로토콜 컴포넌트(1424)는, 정적 파일 전달 디스크립터 유닛을 통해 파일 전달 모드를 식별하도록 구성될 수 있다.

[0306] 파일 모드에서 동작하는 경우에, 소스 프로토콜 컴포넌트(1424)는 파일들의 바이트 범위들 또는 정규 파일들로서 오브젝트들을 전달할 수 있다. 즉, 정규 파일 모드에서 동작하는 경우에, 각각의 전달 오브젝트는 파일, 또는 파일의 바이트 범위를 표현할 수 있다(즉, @byteRange가 존재한다). 소스 프로토콜 컴포넌트(1424)는 FDD에 전달 오브젝트와 연관된 모든 정보를 포함할 수 있고, 바이트 범위 또는 파일의 모든 속성들은 정적 FDT 또는 정적 FDD를 통해 전달될 수 있다.

[0307] 소스 프로토콜 컴포넌트(1424)는 또한, 정규 엔티티 모드에서 동작할 수 있다. 이러한 모드에서, LCT를 통한 오브젝트 전달은, HTTP 엔티티들을 통해 컨텐츠를 전달하는 기존의 HTTP 전달 기법들과 거의 또는 완전히 정렬될 수 있다. 위에서 언급된 바와 같이, HTTP 엔티티는 엔티티-헤더 및 엔티티-보디를 포함한다. 따라서, 정규 엔티티 모드에서 동작하는 경우에, 소스 프로토콜 컴포넌트(1424)는, 엔티티-헤더 및 엔티티-보디(즉, 파일)를 포함하는 엔티티들로서 오브젝트들을 전달할 수 있다. 전달 오브젝트들은, 이들이 엔티티-헤더로 시작하도록, 통신 또는 생성될 수 있다. 전달 오브젝트들은, 전달 오브젝트가, 완전한 오브젝트/파일이 아니라, 오브젝트/파일의 바이트 범위인 것을 시그널링, 통신, 또는 결정하기 위해 사용될 수 있는 컨텐츠 범위 및 URL을 메시지 보디가 포함하도록, 통신 또는 생성될 수 있다.

[0308] 정규 엔티티 모드에서 동작하는 경우에, 소스 프로토콜 컴포넌트(1424)는, 전달된 파일에 대해 적용가능한 정적 파일 전달 테이블(FDT) 또는 정적 파일 전달 디스크립터(FDD)에서의 파일의 모든 속성들을 전달한다. 부가하여, 바이트 범위(예를 들어, 대역내) 또는 파일과 함께 송신되는 엔티티-헤더는, 그 파일/바이트 범위에 대한 부가적인 정보를 포함할 수 있다. 엔티티-헤더 및 FDD 양자 모두에 특정한 속성들이 존재하는 경우에, 엔티티-헤더에서의 값들은 정적 FDD에서의 대응하는 값들을 오버라이팅할 수 있다. 헤더가 엔티티-헤더에서의 컨텐츠-범위를 포함하는 경우에, 전달 오브젝트는, 완전한 오브젝트/파일이 아니라, 오브젝트/파일의 바이트 범위를 포함하는 것으로 결정될 수 있다.

[0309] 소스 프로토콜 컴포넌트(1424)는 또한, HTTP/1.1에서의 청크된 전송 모드를 통해 달성될 수 있는 것과 유사하게, 파일들의 프로그레시브 전달을 달성하기 위해, 프로그레시브 엔티티 모드에서 동작할 수 있다. 프로그레시브 엔티티 모드에서 동작하는 경우에, 소스 프로토콜 컴포넌트(1424)는, 엔티티-헤더, 파일, 및 트레일러를 포함하는 엔티티들로서 오브젝트들을 전달할 수 있다. 트레일러는, 소스 프로토콜 컴포넌트(1424)가 프로그레시브 방식으로 오브젝트/파일을 전달할 수 있게 하는 부가적인 헤더 필드들을 포함할 수 있고, 즉, 그것은 전체 파일이 생성되기 전에 전달될 수 있다.

[0310] 다양한 실시예들에서, 소스 프로토콜 컴포넌트(1424)는 엔티티 헤더 또는 코드 포인트에 트레일러를 포함하도록 구성될 수 있다. 정적 파일 전달 테이블(FDT)에서의 모든 속성들은 전달된 오브젝트/파일에 대해 적용될 수 있다. 부가하여, 소스 프로토콜 컴포넌트(1424)는 파일에 대한 부가적인 정보를 포함하도록 엔티티-헤더를 생성할 수 있다. 위치들(즉, FDD 및 엔티티-헤더) 양자 모두에 특정한 속성들이 존재하는 경우에, 엔티티-헤더에서의 값들은 정적 FDD에서의 대응하는 값들을 오버라이팅할 수 있다.

[0311] 중복 FDT 모드에서 동작하는 경우에, 소스 프로토콜 컴포넌트(1424)는, FDT에 포함된 정보가 FDD에 포함된 정보에 대해 중복하도록, 오브젝트를 갖는 FDT를 생성 및 송신할 수 있다. 보완 FDT 모드에서 동작하는 경우에, 소스 프로토콜 컴포넌트(1424)는, FDT가, 수신기 디바이스에 대해 유용할 수 있는 부가적인 정보를 포함하도록, 오브젝트를 갖는 FDT를 생성 및 송신할 수 있다. 동적 FDT 모드에서 동작하는 경우에, 소스 프로토콜 컴포넌트(1424)는, FDT가, 수신기 디바이스에 의해 사용될 수 있는 본질적인 부가적인 정보를 포함하도록, 오브젝트를 갖는 FDT를 생성 및 송신할 수 있다.

[0312] 소스 프로토콜 컴포넌트(1424)는, 본원에서 논의되는 다양한 특징들 및 기능들을 지원하고, FLUTE를 통해 오브젝트 전달을 달성하기 위해, 특정 방식들로, LCT 통신 기술들 및 방법들을 사용하도록 구성될 수 있다. 예를 들어, 소스 프로토콜 컴포넌트(1424)는, (LCT/ALC에서 정의되는) 혼잡 제어 헤더의 값을 제로(0)로 세팅할 수 있고, (예를 들어, @tsi 데이터-필드를 통해) 패킷에 의해 적용되는 전달 오브젝트 컬렉션에 따라 LCT 헤더에서 TSI를 세팅할 수 있고, @codepoint 데이터-필드의 값에 기초하여 LCT 헤더에서 코드 포인트를 세팅할 수 있고, 소스 패킷을 표시하기 위해 PSI의 제 1 비트를 제로(0)로 세팅할 수 있는 등을 행할 수 있다. 소스 프로토콜 컴포넌트(1424)는 또한, 전달 오브젝트의 (예를 들어, 옥텟들, 바이트들 등으로) 시작 어드레스를 특정하는 소스 FEC 페이로드 ID를 사용할 수 있다. 그러한 정보는, SBN, ESI, 및 심볼 크기(T) 값들을 사용함으로써, 또는 (예를 들어, 32 또는 64 비트들을 사용하는) 다이렉트 어드레싱을 통해 통신될 수 있다.

[0313] 소스 프로토콜 컴포넌트(1424)는, 다양한 시간 값들 및 이벤트들을 시그널링 또는 통신하기 위해, LCT 헤더 EXT_TIME 익스텐션을 사용하도록 구성될 수 있다. 예를 들어, 소스 프로토콜 컴포넌트(1424)는, 송신기의 현재 시간을 시그널링하기 위해, "송신기 현재 시간" 필드로서 EXT_TIME 익스텐션을 사용할 수 있다. 이러한 정보는 송신기 및 수신기 디바이스들에서 클록들을 동기화하기 위해 사용될 수 있다. 추가적인 예로서, 소스 프로토콜 컴포넌트(1424)는, 현재 오브젝트에 대한 예상되는 나머지 시간을 시그널링하기 위해, "예상되는 잔여 시간" 필드로서 EXT_TIME 익스텐션을 사용할 수 있다. 소스 프로토콜 컴포넌트(1424)는 또한, 세그먼트들의 부가 또는 제거를 시그널링하기 위해, SLC 플래그(세션 Last Change flag)로서 EXT_TIME 익스텐션을 사용할 수 있다.

[0314] 소스 프로토콜 컴포넌트(1424)는, 송신기 디바이스에서 모든 파일/오브젝트가 수신 또는 생성되기 전에, 파일/오브젝트의 부분들 또는 바이트 범위들을 비순차적으로 송신하도록 구성될 수 있다. 따라서, 오브젝트/파일의 바이트 범위들은 순차적으로 송신되지 않을 수 있다. 그보다는, 더 늦은 바이트 범위가 더 이른 바이트 범위 전에 송신될 수 있다. 그러한 경우들에서, 소스 프로토콜 컴포넌트(1424)는, 수신기 디바이스에게, 송신기 디바이스가 그러한 기술을 적용하고 및/또는 바이트 범위들이 비순차적으로 전송될 수 있는 것을 통신하기 위해, @outOfOrderSending 데이터-필드를 사용할 수 있다.

[0315] 비순차적으로 파일/오브젝트의 부분들 또는 바이트 범위들을 송신하는 것은 특히, 미디어가 생성된 후에 헤더 데이터가 생성되는 것을 요구하는 데이터 포맷들, 예를 들어, 헤더에 파일의 크기 정보를 포함하는 포맷들에 대해 유용하다. 그러한 포맷들에 대해, 소스 프로토콜 컴포넌트(1424)는, 수신기 디바이스가 그러한 헤더 정보를 수신 및 사용하여, 데이터 유닛의 크기를 결정할 수 있도록, 데이터를 전송한 후에, 수신기 디바이스에 헤더를 송신할 수 있다. 헤더 필드의 크기가 전형적으로 사전에 알려져 있기 때문에, 이는, 오브젝트가 수신되는 경우에 수신기 디바이스가 헤더 부분을 스킵하는 것에 의해, 또는 본원에서 논의되는 다른 기법들 중 임의의 것을 사용함으로써 달성될 수 있다. 헤더 필드의 크기가 가변적인 포맷들을 지원하기 위해, 소스 프로토콜 컴포넌트(1424)는 통신 또는 데이터를 패딩할 수 있다. 소스 프로토콜 컴포넌트(1424)는 또한, 시간(예를 들어, 밀리초)에서의 인터리빙 깊이, 최대 데이터 범위들 등을 통신하기 위해, 플래그를 세팅 또는 사용할 수 있다.

[0316] 다양한 실시예들에서, 시스템(1140)은, 소스 및 복구 플로우들을, 이들의 상이한 UDO 플로우들(즉, 상이한 IP/UDP 포트 결합을 통해 전달됨)에 의해, 및/또는 이들의 세션 설명 프로토콜(SDP) 파일들을 통해 구별하도록 구성될 수 있다. LCT 패킷들이 동일한 UDP 플로우에서 송신되는 경우에, 시스템(1140)은, 패킷들의 LCT 헤더 필드들에서의 전송 세션/스트림 식별자(TSI)에 기초하여, 소스 및 복구 플로우들을 구별할 수 있다. LCT 패킷들이 동일한 UDP 플로우에서 송신되고, 동일한 TSI 값을 갖는 경우에, 시스템(1140)은, 패킷의 헤더에서의 프로그램 및 시스템 정보(PSI) 비트에 기초하여, 소스 및 복구 플로우들/패킷들을 구별할 수 있다. 이는 특히, 시스템(1420)이 역호환성 모드에서 동작하거나, 또는 역호환성 모드를 지원하도록 요구되는 경우에 유용할 수 있다.

[0317] 복구 프로토콜 컴포넌트(1426)는, FEC에 대해 전달 오브젝트들의 피스들, 전달 오브젝트들의 번들들, 및/또는 전달 오브젝트들의 피스들의 번들들을 보호하도록 구성될 수 있다. 부가하여, 복구 프로토콜 컴포넌트(1426)는, 전달 오브젝트들 또는 그 피스들의 전달(즉, 패킷들을 보호하는 것이 아님)을 달성하도록 구성될 수 있다.

[0318] 복구 프로토콜 컴포넌트(1426)는, FEC 인코딩 스킴, FEC 디코딩 스킴, 및/또는 (즉, FEC 스킴의 컨텍스트에서) 패킷 페이로드 데이터를 식별하기 위한 다양한 다른 프로토콜 필드들 및 프로시저들을 정의하도록 구성된 FEC 스킴 컴포넌트(1434)를 포함할 수 있다. 다양한 실시예들에서, 기능 층으로서 구현될 수 있거나 또는 기능 층으로서 동작하도록 구성될 수 있는 FEC 스킴 컴포넌트(1434)는 전송 층(예를 들어, UDP/IP 멀티캐스트) 컴포넌트(1428) 위에 있다.

[0319] 복구 프로토콜 컴포넌트(1426)는 또한, 전달 오브젝트들(1430) 또는 오브젝트들의 컬렉션들(예를 들어, 컬렉션 1, 컬렉션 2)을 유연하게 보호하도록 구성된 복구 ALC(Asynchronous Layered Coding) 컴포넌트(1438)를 포함할 수 있다. 추가로, 복구 프로토콜 컴포넌트(1426) 및 소스 프로토콜 컴포넌트(1424) 각각은, LCT(Layered Coding Transport) 컴포넌트(1436)를 포함할 수 있다. 패킷들은 LCT 패킷들일 수 있다.

[0320] 복구 프로토콜 컴포넌트(1426)는 하나 이상의 FEC 오브젝트들을 생성하도록 구성될 수 있다. 각각의 FEC 오브젝트는 완전한 전달 오브젝트, 또는 전달 오브젝트의 연속적인 바이트 범위일 수 있다. 다양한 실시예들에서, 복구 프로토콜 컴포넌트(1426)는, FEC 보호가 단일 FEC 오브젝트, 또는 FEC 오브젝트들의 컬렉션에 대해 적용될 수 있도록 구성될 수 있다. 복구 프로토콜 컴포넌트(1426)는, TSI가 FEC 오브젝트들의 컬렉션을 스코핑하기 위해 사용될 수 있도록 구성될 수 있다. 복구 프로토콜 컴포넌트(1426)는, 본원에서 논의되는 기법들 중 임의의 것을 사용하여 및/또는 FEC 구조와 무관하게 TOI/TSI를 예시하도록 구성될 수 있다.

[0321] 다양한 실시예들에서, 복구 프로토콜 컴포넌트(1426)는, FEC-관련된 정보가, 그것이, 그러한 정보가 필요하다고, 요구된다고, 및/또는 유용하다고 결정한 경우에만, 통신되도록 구성될 수 있다. 복구 프로토콜 컴포넌트(1426)는 또한, FEC 동작들을 수행할 수 없는 수신기 디바이스들이 FEC-관련된 정보를 무시할 수 있고 여전히 그것의 대응하는 컨텐츠를 렌더링할 수 있도록, FEC-관련된 정보를 통신하도록 구성될 수 있다. 복구 프로토콜 컴포넌트(1426)는, 각각의 보호되는 복구 플로우에 대해 심볼 크기가 고정되는 심볼-기반 FEC 동작들을 수행하도록 구성될 수 있다. 복구 프로토콜 컴포넌트(1426)는 또한, 각각의 복구 플로우가 하나 이상의 소스 플로우들로부터의 전달 오브젝트에 대한 보호를 제공하도록, FEC 동작들을 수행하도록 구성될 수 있다.

[0322] 복구 프로토콜 컴포넌트(1426)는, 모든 FEC 특정 정보를 포함하는 FEC 복구 플로우 선언, 보호되는, 소스 오브젝트의 연속적인 옥텟 범위 또는 소스 오브젝트 그 자체인 FEC 오브젝트, FEC 오브젝트의 연결인 FEC 전송 오브젝트, 하나 이상의 FEC 전송 오브젝트들의 연결인 FEC 수퍼 오브젝트, FEC 프로토콜, 및 패킷 구조를 포함하거나, 또는 통신하도록 구성된 FEC 프레임워크일 수 있다. FEC 전송 오브젝트는, 데이터의 심볼-정렬된 청크를 형성하기 위해 사용될 수 있는, 크기 정보 및 패딩 옥텟들을 포함할 수 있다. FEC 수퍼 오브젝트는 FEC 보호를 위해 FEC 전송 오브젝트들을 번들링하기 위해 사용될 수 있다.

[0323] 도 15는, FEC 프레임워크(1500)가 2개의 소스 오브젝트들(1504, 1506)에 기초하여 FEC 복구 패킷(1502)을 생성하도록 구성되는 실시예에서의 다양한 구조들, 데이터-필드들, 통신 패킷들, 변환들, 및 정보 플로우들을 예시한다. FEC 프레임워크(1500)는, 도 14b를 참조하여 위에서 논의된 복구 프로토콜 컴포넌트(1426)에 포함될 수 있거나, 또는 그것의 부분으로서 구현될 수 있다. 실시예에서, 소스 오브젝트들(1504, 1506)은 도 14b를 참조하여 위에서 논의된 전달 오브젝트들과 동일할 수 있다.

[0324] 도 15에서 예시된 예에서, FEC 프레임워크(1500)는, 제 1 소스 오브젝트(1504)에 대한 제 1 FEC 오브젝트(1508), 및 제 2 소스 오브젝트(1506)에 대한 제 2 FEC 오브젝트(1510)를 생성한다. FEC 오브젝트들(1508, 1510) 각각은 완전한 소스 오브젝트, 또는 소스 오브젝트의 연속적인 옥텟 범위일 수 있다. FEC 프레임워크(1500)는, 그것의 대응하는 소스 오브젝트(1504, 1506) 및/또는 소스 오브젝트(1504, 1506)의 옥텟 범위, 즉, 보호될 FEC 오브젝트(1508, 1510)를 구성하는, 소스 오브젝트(1504, 1506)의 옥텟들의 수 및 소스 오브젝트(1504, 1506) 내의 시작 옥텟의 TOI 및 TSI를 사용하여, FEC 오브젝트들(1508, 1510)을 생성하도록 구성될 수 있다.

[0325] 각각의 FEC 오브젝트(1508, 1510)에 대해, FEC 프레임워크(1500)는, FEC 오브젝트(1508, 1510), 패딩 옥텟들(P)(1516, 1520), 및 FEC 오브젝트 크기(F)(1518, 1522)의 연결을 포함하는 FEC 전송 오브젝트(1512, 1514)를 생성할 수 있다. 패딩 옥텟들(P)(1516, 1520)은, FEC 오브젝트 크기(F)(1518, 1522)와 소스 오브젝트(1504, 1506) 사이에서, FEC 전송 오브젝트(1512, 1514)의 단부 쪽에 포함된 패딩 데이터일 수 있다. FEC 오브젝트 크기(F)(1518, 1522) 값들은 옥텟들로 표현될 수 있고, 및/또는 네(4)개의 옥텟 필드를 통해 통신될 수 있다. 즉, FEC 오브젝트 크기(F)(1518, 1522)는 FEC 전송 오브젝트(1512, 1514)의 마지막 네(4)개의 옥텟들에서 전달될 수 있다.

[0326] 다양한 실시예들에서, FEC 프레임워크(1500)는, 복구 패킷 헤더들 및/또는 세션 정보에 기초하여, FEC 전송 오브젝트들(1512, 1514) 각각에 대해 FEC 전송 오브젝트 크기(S)를 컴퓨팅하도록 구성될 수 있다. FEC 프레임워크(1500)는, 심볼 크기(T)의 정수배로서 및/또는 심볼들의 단위들로 FEC 전송 오브젝트 크기(S)를 컴퓨팅할 수 있다. 예를 들어, FEC 오브젝트 크기(F)(1518, 1522)가 옥텟들로 표현된 FEC 오브젝트(1508, 1510)의 크기이고, F가 소스 오브젝트(1504, 1506)의 데이터의 F개의 옥텟들이고, 파라미터 "f"가 네트워크 옥텟 차수에서 F의 값을 전달하는 데이터의 네(4)개의 옥텟들을 나타내고(고차 옥텟 우선), FEC 전송 오브젝트 크기(S)가 S = ceil(F+4)/T인 FEC 전송 오브젝트의 크기이고, 패딩 옥텟들(P)(1516, 1520)이 데이터의 S*T-4-F 제로 옥텟들이고, O가 F, P, 및 f의 연쇄인 경우에, O는 크기 S*T 옥텟들의 FEC 전송 오브젝트를 구성한다.

[0327] 패딩 옥텟들(P)(1516, 1520) 및 FEC 오브젝트 크기들(F)(1518, 1522)이 소스 오브젝트들(1504, 1506)의 소스 패킷들에서 송신되도록 요구되지 않는다는 것이 이해되어야 한다. 그보다는, 이들은, FEC 오브젝트(1508, 1510), 그리고 따라서, FEC 오브젝트(1508, 1510)를 구성하는 소스 오브젝트(1504, 1506) 또는 소스 오브젝트(1504, 1506)의 부분을 추출하기 위해, FEC 디코딩이 복원하는 FEC 전송 오브젝트(1512, 1514)에 포함될 수 있다.

[0328] FEC 프레임워크(1500)는, FEC 전송 오브젝트(1512, 1514)에 관한 일반적인 정보를 수신기 디바이스에 통신하도록 구성될 수 있다. FEC 프레임워크(1500)는, FEC 인에이블드 수신기 디바이스에 전달되는 FEC 전송 오브젝트(1512, 1514)에 관한 일반적인 정보가, 소스 TSI, 소스 TOI, 및 연관된 FEC 오브젝트(1508, 1510)의 소스 오브젝트(1504, 1506) 내의 연관된 옥텟 범위이도록 구성될 수 있다. FEC 오브젝트(1508, 1510)의 옥텟들의 크기가 FEC 전송 오브젝트(1512, 1514) 내의 첨부된 필드에 제공될 수 있기 때문에, 나머지 정보는, FEC 전송 오브젝트(1512, 1514)와 연관된 FEC 오브젝트(1508, 1510)가 생성되는 소스 오브젝트(1504, 1506)의 TOI 및 TSI, 연관된 FEC 오브젝트(1508, 1510)에 대한 소스 오브젝트(1504, 1506) 내의 시작 옥텟, 및 FEC 전송 오브젝트(1512, 1514)의 심볼들의 크기로서 전달될 수 있다.

[0329] FEC 프레임워크(1500)는 FEC 전송 오브젝트들(1512, 1514) 및/또는 FEC 복구 플로우 선언에 기초하여 FEC 수퍼 오브젝트(1540)를 발생시키도록 구성될 수 있다. 예를 들어, FEC 프레임워크(1500)는 연속되는 FEC 전송 오브젝트(1512) 및 FEC 전송 오브젝트(1514)를 포함하도록 FEC 수퍼 오브젝트(1540)를 발생시킬 수 있다. FEC 프레임워크(1500)는 또한, 앞서 설명된 FEC 전송 오브젝트들(1512, 1514)에 관한 모든 일반적 정보뿐만 아니라, FEC 수퍼 오브젝트(1540) 내에서의 FEC 전송 오브젝트들(1512, 1514)의 순서를 식별하는 정보도 포함하도록 FEC 수퍼 오브젝트(1540)를 발생시킬 수 있다.

[0330] 실시예에서, FEC 프레임워크(1500)는 FEC 수퍼 오브젝트(1540)의 소스 심볼들의 수를 결정하도록 구성될 수 있다. 예를 들어, N이 FEC 수퍼 오브젝트 구조에 대한 FEC 전송 오브젝트들의 총 개수이고, S[i]가

에 대한 FEC 전송 오브젝트 i의 심볼 단위의 크기이고, 그리고 B가 연속되는 FEC 전송 오브젝트(1512, 1514) 오브젝트들을 차례대로 포함하는 FEC 수퍼 오브젝트(1540)인 경우, FEC 수퍼 오브젝트(1540)는

소스 심볼들을 포함하는 것으로 결정될 수 있다.

[0331] FEC 프레임워크(1500)는 FEC 전송 오브젝트들(1512, 1514)에서 전달되는 일반적 정보를 넘어서는 부가적인 일반적 정보를 포함하게 FEC 수퍼 오브젝트(1540)를 발생시키도록 구성될 수 있다. 이러한 정보는 FEC 전송 오브젝트들의 총 개수 N을 포함할 수 있다. 이 정보는 또한, FEC 전송 오브젝트(1512, 1514)와 연관된 FEC 오브젝트(1508, 1510)가 발생되는 소스 오브젝트(1504, 1506)의 TSI 및 TOI, 연관된 FEC 오브젝트(1508, 1510)에 대한 소스 오브젝트(1504, 1506) 내에서의 시작 옥텟, 및 FEC 전송 오브젝트(1512, 1514)의 심볼 단위의 크기와 같은, 각각의 FEC 전송 오브젝트(1512, 1514)에 대한 값들을 포함할 수 있다.

[0332] 실시예에서, FEC 프레임워크(1500)는 FEC 수퍼 오브젝트(1540)에 기초하여 FEC 복구 패킷(1502)을 발생시키도록 구성될 수 있다. FEC 복구 패킷(1502)은 ALC(Asynchronous Layered Coding), LCT 층화 코딩 전송(LCT; Layered Coding Transport) 빌딩 블록에 기초하여 및/또는 본원에서 논의된 기술들, 특징들, 및 수정들 중 임의의 것을 포함하도록 발생될 수 있다. 예를 들어, LCT 헤더의 TSI는, RepairFlow.SDPParameter@tsi 속성을 통해 정의될 수 있는 FEC 복구 패킷(1502)이 적용되는 복구 플로우에 따라 설정될 수 있다. SPI(Source Packet Indicator)의 제 1 비트는 그것이 복구 패킷임을 표시하기 위해 0으로 설정될 수 있다. FEC 구성 정보는 LCT 확장 헤더들에서 전달될 수 있다.

[0333] 추가의 예들로서, FEC 프레임워크(1500)는 복구 패킷들만을 전달하기 위해 FEC 빌딩 블록을 이용하도록 구성될 수 있다. (LCT 헤더의 TSI 필드에 의해 표시되는 바와 같이) 복구 플로우의 범위 내의 각각의 복구 패킷은, TSI의 범위 내에서 생성되는 각각의 FEC 수퍼 오브젝트에 대해 고유할 수 있는 적절한 복구 TOI를 포함/전달하도록 발생될 수 있다. 세션 설명 정보는 SDP 파라미터들을 통해, 이를테면, 앞서 논의된 SDPParameter를 통해 통신될 수 있다.

[0334] FEC 프레임워크(1500)는 서머리 FEC 정보를 수신기 디바이스에 통신하도록 구성될 수 있다. 다양한 실시예들에서, FEC 프레임워크(1500)는 서머리 FEC 정보를 RepairFlow 선언에서 정적으로, LCT 확장 헤더에서 동적으로, 또는 이 둘의 결합으로 통신하도록 구성될 수 있다. FEC 프레임워크(1500)는 이러한 정보를 (복구 플로우 내의 고유 TOI에 의해 식별되고 그리고 LCT 헤더의 TSI에 의해 복구 플로우와 연관되는) 각각의 수퍼 오브젝트에 대해 통신할 수 있다. 이러한 정보는 FEC 구성 정보, FEC 인코딩 ID, FEC OTI, 및 부가적인 FEC 정보를 포함할 수 있다. 이러한 정보는 또한, FEC 수퍼 오브젝트(1540)에 포함된 FEC 오브젝트들의 총 개수뿐만 아니라, FEC 전송 오브젝트(1512, 1514)와 연관된 FEC 오브젝트(1508, 1510)가 발생되는 소스 오브젝트(1504, 1506)의 TSI 및 TOI, 연관된 FEC 오브젝트(1508, 1510)에 대한 소스 오브젝트(1504, 1506) 내에서의 시작 옥텟, 및 FEC 전송 오브젝트(1512, 1514)의 심볼 단위의 크기도 포함할 수 있다.

[0335] FEC 프레임워크(1500)는 FEC 시그널링 정보를 포함하는 FEC 복구 플로우 선언을 발생시키고, 사용하고, 및/또는 통신하도록 구성될 수 있다. 예를 들어, MBMS 사용자 서비스들에서, 복구 플로우 선언은 번들 설명 또는 사용 서비스 설명의 프래그먼트로서 포함될 수 있다. 이러한 복구 플로우 선언의 부분으로서, FEC 프레임워크(1500)는 @tsi 속성에서 복구 플로우에 대한 복구 플로우 식별자를 제공할 수 있으며, 모든 복구 플로우들은 타입 RepairFlow를 갖는 것으로 선언된다. IP 어드레스, 포트 및 복구 플로우 식별자의 결합은, 사용자 서비스 내의 모든 플로우들 가운데서 고유 식별자를 제공할 수 있다. IP/포트 결합은 상이한 FEC 복구 데이터뿐만 아니라 소스 데이터를 전달할 수 있음을 유의한다. 이러한 경우, 데이터는 LCT 헤더의 상이한 TSI 값들에 의해 차별화될 수 있다.

[0336] 실시예에서, FEC 프레임워크(1500)는, 복구 플로우에 의해 보호될 소스 플로우들로부터 소스 오브젝트들의 패턴(또는 소스 오브젝트의 옥텟 범위들)을 식별하는 정보를 포함하게 복구 플로우 선언을 발생시키도록 구성될 수 있다. 추가의 실시예들에서, FEC 프레임워크(1500)는 세션의 복구 플로우를 정의하는 RepairFlow 데이터-필드를 포함하는 메타데이터 프래그먼트들을 포함하도록 복구 플로우 선언을 발생시킬 수 있다. 각각의 RepairFlow 데이터-필드는 또한, 다양한 다른 데이터-필드들, 이를테면, @tsi 데이터-필드, @sessionDescription 데이터-필드, 및 FECParameters 데이터-필드를 포함할 수 있다. @tsi 데이터-필드는 복구 플로우가 할당되는 TSI를 식별하기 위해 이용될 수 있는 정보를 세션의 LCT 헤더에 포함할 수 있다. @sessionDescription 데이터-필드는, 복구 플로우를 포함하는 세션 설명을 참조하기 위해 이용될 수 있는 정보를 포함할 수 있다.

[0337] FECParameters 데이터-필드는 다양한 다른 데이터-필드들, 이를테면, @fecEncodingId 데이터-필드, @maximumDelay 데이터-필드, FECOTI 데이터-필드, 및 ProtectedObject 데이터-필드를 포함할 수 있다. @fecEncodingId 데이터-필드는 적용된 FEC 스킴을 식별하기 위해 이용될 수 있는 정보를 포함할 수 있다. @maximumDelay 데이터-필드는 소스 플로우와 복구 플로우의 임의의 소스 패킷 사이의 최대 전달 지연을 식별하기 위해 이용될 수 있는 정보를 포함할 수 있다. FECOTI 데이터-필드는 FEC 오브젝트 전송 정보(FEC OTI; FEC Object Transmission Information)를 포함할 수 있고, FEC 오브젝트 전송 정보(FEC OTI)는 오브젝트와 연관된 FEC 관련 정보에 대응할 뿐만 아니라, 오브젝트의 인코딩 심볼들과 연관된 FEC 정보가 이러한 선언 내에 포함될 것이고, 복구 플로우를 이용하여 모든 복구 패킷들에 적용된다.

[0338] ProtectedObject 데이터-필드는 복구 플로우에 의해 보호되는 소스 플로우들 및 보호가 어떻게 행해지는지에 대한 상세들을 식별하기 위해 이용될 수 있는 정보를 포함할 수 있다. 실시예 컴포넌트들은, 소스 플로우가 복구 플로우와 동일한 세션에 포함되는지, 소스 플로우가 복구 플로우와 동일한 TSI를 이용하여 시그널링되는지, 소스 TOI가 복구 TOI와 동일한지 등을 결정하기 위해 이러한 정보를 이용할 수 있다. 실시예 컴포넌트들은, 소스 TOI가 복구 TOI와 동일하다는 결정에 응답하여, 패킷들이 LCT 헤더의 PSI 플래그를 통해 차별화될 수 있음을 결정할 수 있다. 실시예 컴포넌트들은 또한, 각각의 FEC 전송 오브젝트의 크기가 EXT_TOL 헤더를 이용하여 복구 패킷들로부터 획득될 수 있는지를 결정하기 위해 ProtectedObject 데이터-필드의 정보를 이용할 수 있다.

[0339] ProtectedObject 데이터-필드는, 복구 플로우에 포함되는 오브젝트들의 컬렉션에서 소스 오브젝트들을 식별하기 위해 이용될 수 있는 정보를 포함할 수 있다. ProtectedObject 데이터-필드는 또한, 다양한 다른 데이터-필드들, 이를테면, @sessionDescription 데이터-필드, @tsi 데이터-필드, @sourceTOI 데이터-필드, @fecTransportObjectSize 데이터-필드, 및 @startOctet 데이터-필드를 포함할 수 있다.

[0340] @sessionDescription 데이터-필드는 소스 플로우를 포함하는 세션 설명을 식별하기 위해 이용될 수 있는 정보를 포함할 수 있다. 실시예 컴포넌트는, @sessionDescription 데이터-필드가 비어 있다는 결정에 응답하여, 소스 플로우가 복구 플로우와 동일한 세션에 포함됨을 결정하도록 구성될 수 있다.

[0341] @tsi 데이터-필드는 보호될 소스 플로우에 대한 전송 세션 식별자를 식별하기 위해 이용될 수 있는 정보를 포함할 수 있다. 실시예 컴포넌트는, @tsi 데이터-필드가 비어 있다는 결정에 응답하여 소스 플로우가 복구 플로우와 동일한 tsi/TSI를 이용하여 시그널링됨을 결정하도록 구성될 수 있으며, 이러한 경우, 패킷들은, ALC IETF RFC 5775에서 정의된 바와 같이, LCT 헤더의 SPI 플래그(Source Packet Indicator flag)를 통해 차별화될 수 있다.

[0342] @sourceTOI 데이터-필드는 소스 오브젝트의 TOI 및 복구 플로우에 포함된 TOI의 맵핑을 식별하기 위해 이용될 수 있는 정보를 포함할 수 있다. 실시예 컴포넌트는, @sourceTOI 데이터-필드가 비어 있다는 결정에 응답하여, 소스 TOI가 복구 TOI와 동일함을 결정하도록 구성될 수 있다.

[0343] @fecTransportObjectSize 데이터-필드는, 심볼들의 유닛들과 같은, 각각의 FEC 전송 오브젝트의 디폴트 크기를 식별하기 위해 이용될 수 있는 정보를 포함할 수 있다. 실시예 컴포넌트는, @fecTransportObjectSize 데이터-필드가 비어 있다는 결정에 응답하여, 디폴트 크기 값들이 EXT_TOL 헤더를 이용하여 복구 패킷들에 제공될 수 있음을 결정하도록 구성될 수 있다.

[0344] @startOctet 데이터-필드는 연관된 소스 오브젝트의 시작 옥텟을 식별하기 위해 이용될 수 있는 정보를 포함할 수 있다. 실시예 컴포넌트는, @startOctet 데이터-필드가 비어 있다는 결정에 응답하여, 시작 옥텟 정보가 EXT_TOL 헤더를 이용하여 복구 패킷들에 포함될 수 있음을 결정하도록 구성될 수 있다. 실시예 컴포넌트는 또한, @startOctet 데이터-필드가 값을 포함하거나 비어 있지 않다는 결정에 응답하여, EXT_TOL 헤더가 존재하지 않을 것임을 결정하도록 구성될 수 있다.

[0345] 실시예에서, 컴포넌트(예를 들어, 수신기 디바이스)는, 복구 플로우 선언이 ProtectedObject 데이터-필드 값을 포함한다는 결정에 응답하여, 복구 패킷이 보호하는 소스 오브젝트의 소스 TOI에 대한 복구 패킷에 포함된 복구 TOI 값의 맵핑을 @sourceTOI 속성이 명시함을 결정하도록 구성될 수 있다. 그 맵핑은, C 포맷의 방정식을 통해 설명될 수 있으며, 여기서 복구 플로우의 TOI 필드는 가변 TOI로서 명시된다. 컴포넌트는 이 방정식을 적용한 결과를, 소스 TOI를 결정하기 위해 이용할 수 있다. 속성의 값은, 최대 하나의 가변 TOI를 갖고 ";" 부호의 부가를 갖지 않는 적절한 C 방정식일 수 있다. 컴포넌트는 추가로, 어떠한 @sourceTOI 데이터-필드 값도 ProtectedObject 데이터-필드에 포함되지 않는다는 결정에 응답하여, 디폴트 방정식(예를 들어, sourceTOI= "TOI")을 적용하도록 구성될 수 있다.

[0346] TSI 값 1을 갖는 소스 플로우로부터 TOI 값 20을 갖는 소스 오브젝트를 보호하는 TSI 값 10 및 값 TOI 20을 갖는 복구 패킷에 대한 예시적인 복구 플로우 선언은 서버 또는 수신기 디바이스에서 다음과 같이 표현될 수 있다:

[0347] @sourceTOI 값을 포함하지 않는 예시적인 복구 플로우 선언은 다음과 같다:

[0348] 앞서의 예에서, 어떠한 @sourceTOI 속성도 ProtectedObject에 제공되지 않기 때문에, TOI로부터 소스 TOI를 도출하기 위해 디폴트 방정식 sourceTOI="TOI"가 이용된다. 따라서, TSI 11 및 TOI 20을 갖는 복구 패킷에 의해 보호되는 수퍼 오브젝트는, TSI 2 및 TOI 20을 갖는 소스 오브젝트에 대한 FEC 전송 오브젝트와 TSI 3 및 TOI 20을 갖는 소스 오브젝트에 대한 FEC 전송 오브젝트의 연속이다. 양쪽 경우들 모두에서의 FEC 전송 오브젝트 크기가 정의되고, FEC 수퍼 오브젝트는 2232개의 심볼들의 총 크기를 갖는다.

[0349] TSI 12 및 TOI 20을 갖는 복구 패킷에 의해 보호되는 FEC 수퍼 오브젝트가, TSI 4 및 TOI 40을 갖는 소스 오브젝트에 대한 FEC 전송 오브젝트, TSI 5 및 TOI 20을 갖는 소스 오브젝트에 대한 FEC 전송 오브젝트, 그리고 TSI 4 및 TOI 41을 갖는 소스 오브젝트에 대한 FEC 전송 오브젝트의 연속인 것에 대한 예시적인 복구 플로우 선언은, 서버 또는 수신기 디바이스에서 다음과 같이 표현될 수 있다:

[0350] 앞서의 예에서, 소스 오브젝트들의 FEC 전송 오브젝트 크기들은 복구 플로우 선언에 포함되지 않는다. 부가하여, RepairFlow 선언 내의 ProtectedObject 선언들의 시퀀스는, 수퍼 오브젝트의 소스 오브젝트들에 대한 FEC 전송 오브젝트들의 순서를 결정하기 위해 이용될 수 있다.

[0351] TSI 13 및 TOI 20을 갖는 복구 패킷이 TSI 6 및 TOI 21을 갖는 소스 오브젝트를 보호하는 것에 대한 예시적인 복구 플로우 선언은, 서버 또는 수신기 디바이스에서 다음과 같이 표현될 수 있다:

[0352] TSI(14) 및 TOI(10)를 갖는 복구 패킷에 대한 예시적인 복구 플로우 선언은 2개의 소스 오브젝트들에 대한 FEC 전송 오브젝트들의 연쇄(concatenation)를 보호하고; TSI(7) 및 TOI(20)를 갖는 소스 오브젝트 및 TSI(7) 및 TOI(21)를 갖는 소스 오브젝트는 이하와 같이 서버 또는 수신기 디바이스에서 표현될 수 있다:

[0353] 전술한 예시에서, TSI(14)를 갖는 복구 플로우 선언은 정적(static) FDD를 제공한다. 이에 더해, FEC 수퍼 오브젝트에서의 FEC 전송 오브젝트들의 순서는, Repairflow 선언에서 ProtectedObject 선언들이 행해지는 순서와 동일하다. 따라서, TSI(14) 및 TOI(10)를 갖는 복구 패킷에 대응하는 FEC 수퍼 오브젝트는, TSI(7) 및 TOI(20)를 갖는 소스 오브젝트에 대한 FEC 전송 오브젝트와 TSI(7) 및 TOI(21)를 갖는 소스 오브젝트에 대한 FEC 전송 오브젝트의 연결이다.

[0354] 요약하면, 전술한 실시예들은, 관련 소스 오브젝트들의 컬렉션을 소스 플로우와 연관시키는 것, 및 소스 오브젝트들이 서로에 대한 그들의 관계에 기초하여 수신기 디바이스에 의해 수신되고 복원(recover)될 수 있도록 소스 플로우와 연관된 브로드캐스트 네트워크를 통해 관련 소스 오브젝트들의 컬렉션을 전송하는 것을 포함하는, 브로드캐스트 네트워크를 경유하여 정보를 통신하기 위해 브로드캐스터들 및 수신기 디바이스들에서 구현될 수 있는 방법들을 포함한다. 일 실시예에서, 소스 플로우를 식별하는 소스 플로우 식별자(예를 들어, FLID)가 결정될 수 있고, 그리고 소스 플로우와 연관된 관련 소스 오브젝트들의 소스 오브젝트들 중 하나 이상에 대한 데이터를 전달하는 각각의 패킷은 소스 플로우 식별자를 전달할 수 있다. 일 실시예에서, 패킷 내에서 전달된 소스 오브젝트의 데이터는 패킷 내에서 전달되는 바이트 범위로 식별될 수 있다. 일 실시예에서, 소스 플로우 식별자는 TSI(Transmission Session Identifier) 필드에서 전달될 수 있다. 일 실시예에서, 소스 플로우 식별자는 IP 목적지 어드레스 필드와 UDP 포트 번호 필드의 결합으로 전달될 수 있다. 일 실시예에서, 소스 플로우 식별자는 CP(codepoint) 필드에서 전달될 수 있다.

[0355] 일 실시예에서, 소스 오브젝트 식별자들의 컬렉션이 결정될 수 있고, 소스 플로우의 관련 소스 오브젝트들 중 하나에 대한 데이터를 전달하는 각각의 패킷은 소스 오브젝트 식별자를 전달할 수 있으며, 소스 플로우 식별자와 소스 오브젝트 식별자의 결합은 패킷이 데이터를 전달하기 위한 소스 플로우와 연관된 소스 오브젝트를 관련 소스 오브젝트들의 컬렉션으로부터 식별할 수 있다. 일 실시예에서, 소스 오브젝트 식별자들은 TOI(Transmission Object Identifier)들일 수 있다. 일 실시예에서, 소스 오브젝트 식별자들은 OSN(Object Sequence Number)들일 수 있다.

[0356] 일 실시예에서, 관련 소스 오브젝트들의 하나 초과의 컬렉션이 브로드캐스트 네트워크를 통해 전송될 수 있고, 관련 소스 오브젝트들의 각각의 컬렉션은 상이한 소스 플로우와 연관될 수 있으며, 소스 플로우들 각각을 식별하는 소스 플로우 식별자는 고유할 수 있으며, 데이터를 전달하는 각각의 패킷의 소스 플로우는 패킷에서 전달되는 소스 플로우 식별자와 연관될 수 있고 그리고 그에 의해 식별될 수 있다.

[0357] 일 실시예에서, 소스 플로우 식별자의 부분들은 패킷 내의 상이한 필드들 내에서 전달될 수 있다. 일 실시예에서, 소스 오브젝트들 중 적어도 일부는 바이트 범위의 파일을 포함할 수 있고, 소스 오브젝트들 중 적어도 일부는 HTTP 헤더 및 바이트 범위의 파일을 포함할 수 있다. 일 실시예에서, URL은 파일과 연관될 수 있고, 소스 오브젝트는 파일에 대한 URL 및 대응 바이트 범위로 참조될 수 있다. 일 실시예에서, 소스 오브젝트들의 적어도 일부는 파일을 포함할 수 있고, URL은 파일과 연관될 수 있어서 소스 오브젝트가 파일에 대한 URL로 참조될 수 있다.

[0358] 일 실시예에서, 소스 오브젝트의 적어도 일부는 HTTP 헤더 및 관련 파일을 포함할 수 있다. 일 실시예에서, 소스 오브젝트들의 적어도 일부는 HTTP 헤더, 연관된 파일, 및 HTTP 트레일러를 포함할 수 있다.

[0359] 추가적인 실시예들은, 전체 파일의 부분들을 수신하는 것, 전체 파일을 수신하기 이전에 수신된 부분들에 기초하여 소스 오브젝트들을 생성하는 것, 및 전체 파일을 수신하기 이전에 발생된 소스 오브젝트들을 수신기 디바이스에 전송하는 것을 포함하는, 브로드캐스트 네트워크를 경유하여 정보를 전송하기 위한 브로드캐스터들 및 수신기 디바이스들에서 구현될 수 있는 방법들을 포함한다. 일 실시예에서, 전체 파일을 수신하기 이전에 생성된 소스 오브젝트들을 수신기 디바이스에 전송하는 것은, 파일의 데이터 순서와는 상이한 순서로 소스 오브젝트에 대한 데이터를 전송하는 것을 포함할 수 있다. 일 실시예에서, 파일은 파일의 처음에 파일 크기를 포함할 수 있으며, 파일 크기 이후의 파일의 적어도 일부 데이터가 파일 크기 이전에 전송될 수 있게 하기 위해, 소스 오브젝트에 대한 데이터가 전송될 수 있다. 일 실시예에서, 소스 오브젝트는 HTTP 헤더 및 관련 파일을 포함할 수 있다. 일 실시예에서, 소스 오브젝트는 HTTP 헤더, 관련 파일 및 HTTP 트레일러를 포함할 수 있다.

[0360] 일 실시예에서, 방법들은, 소스 플로우와 연관된 소스 오브젝트들의 컬렉션에 대한 소스 플로우 메타데이터를 결정하는 것을 더 포함하고, 여기서 소스 플로우 메타데이터는 위치들 사이의 관계들, 이름들, 이용가능 시간들, 또는 소스 플로우와 연관된 소스 오브젝트들의 컬렉션에 대한 다른 메타데이터를 시그널링한다. 일 실시예에서, 템플릿들은 소스 플로우 메타데이터에서 관계 정보의 적어도 일부를 시그널링하는데 이용될 수 있다. 일 실시예에서, 소스 플로우에 대한 소스 플로우 메타데이터의 부분들은, 소스 플로우와 연관된 관련 소스 오브젝트들의 적어도 일부가 전송되는 시기 이전에, 수신기 디바이스에 제공될 수 있다. 일 실시예에서, 수신기 디바이스에 제공된 소스 플로우 메타데이터의 부분들은, 타이밍 정보, URI(uniform resource identifier), 및 소스 오브젝트들에 대한 암호해독 키들을 식별하는 정보를 포함할 수 있다. 일 실시예에서, 수신기 디바이스에 소스 플로우 메타데이터의 부분들을 제공하는 것은, 소스 플로우와 연관된 소스 오브젝트들의 적어도 일부를 전송하기 이전에 수신기 디바이스에 대역외에서 흐름 메타데이터의 부분들을 송신하는 것, 및 소스 오브젝트들과 대역내에서 소스 플로우 메타데이터의 다른 부분들을 송신하는 것을 포함할 수 있다. 일 실시예에서, 각각의 소스 오브젝트와 대역내에서 송신된 소스 플로우 메타데이터의 부분들은 소스 오브젝트의 데이터의 마지막 부분의 표시를 포함할 수 있다. 일 실시예에서, 수신기 디바이스에 소스 플로우 메타데이터의 부분들을 제공하는 것은 파일 전달 테이블을 송신하지 않고 단방향 전송 프로토콜을 경유하여 소스 플로우 메타데이터의 부분들을 송신하는 것을 포함할 수 있다. 일 실시예에서, 관련 소스 오브젝트들의 컬렉션을 전송하는 것은, MBMS(multimedia broadcast multicast services)를 통해서 관련된 소스 오브젝트들의 컬렉션을 전송하는 것을 포함할 수 있다.

[0361] 일 실시예에서, 관련된 소스 오브젝트들의 컬렉션을 전송하는 것은, FLUTE(file delivery over unidirectional transport)을 통해서 관련된 소스 오브젝트들의 컬렉션을 전송하는 것을 포함할 수 있다. 일 실시예에서, 관련된 소스 오브젝트들의 컬렉션을 전송하는 것은, 소스 오브젝트들을 그들의 상응하는 복구 오브젝트들과 상관없이 소스 오브젝트들을 전송하는 것을 포함할 수 있다. 일 실시예에서, 방법들은 소스 오브젝트를 그의 상응하는 복구 오브젝트와 구별하기 위해 SDP(session description protocol) 정보를 이용하는 것을 더 포함할 수 있다. 일 실시예에서, 관련된 소스 오브젝트들의 컬렉션을 전송하는 것은, FEC(forward error correction) 시그널링 정보를 전송하지 않고 소스 오브젝트들을 전송하는 것을 포함할 수 있다.

[0362] 일 실시예에서, 방법들은, 소스 오브젝트들이 서로에 대한 그들의 관계에 기초하여 수신기 디바이스에 의해 수신되어 디코딩될 수 있도록 브로드캐스트 네트워크를 통해 소스 플로우와 연관되는 관련된 소스 오브젝트들의 컬렉션에 대한 FEC 복구 데이터를 전송하는 것을 더 포함할 수 있으며, 여기서 소스 플로우와 연관되는 관련된 소스 오브젝트들 중 하나 이상에 대한 FEC 복구 데이터를 전달하는 각각의 패킷은 패킷이 FEC 복구 데이터를 전달하는 소스 플로우를 식별하는 소스 플로우 식별자를 전달할 수 있고, 소스 플로우와 연관되는 관련된 소스 오브젝트들 중 하나 이상에 대한 FEC 복구 데이터를 전달하는 각각의 패킷은 패킷에서 전달되는 FEC 복구 데이터가 생성될 수 있는 하나 이상의 소스 오브젝트들의 하나 이상의 소스 오브젝트 식별자들을 전달할 수 있으며, 소스 플로우 식별자와 하나 이상의 소스 오브젝트 식별자들의 결합은 패킷에서 전달되는 FEC 복구 데이터가 생성될 수 있는 소스 플로우와 연관되는 관련된 소스 오브젝트들의 컬렉션으로부터 하나 이상의 소스 오브젝트들을 식별할 수 있다.

[0363] 일 실시예에서, 방법들은, 주로 하나 이상의 소스 오브젝트들에 대한 데이터를 전달하는 패킷들이 전송되는 동일한 시간 인터벌 내에서 하나 이상의 소스 오브젝트들로부터 생성된 FEC 복구 데이터를 전달하는 패킷들을 전송하는 것을 더 포함할 수 있다.

[0364] 일 실시예에서, 방법들은, 하나 이상의 소스 플로우들과 복구 플로우를 연관시키는 것, 복구 플로우에 대한 복구 플로우 식별자를 결정하는 것, 복구 플로우와 연관된 FEC 복구 데이터를 전달하는 각각의 패킷에서 복구 플로우 식별자를 전달하는 것, 복구 플로우에 대한 복구 오브젝트 식별자들의 컬렉션을 결정하는 것, 및 복구 플로우와 연관된 FEC 복구 데이터를 전달하는 각각의 패킷에서 복구 오브젝트 식별자들의 컬렉션으로부터의 복구 오브젝트 식별자를 전달하는 것을 더 포함할 수 있으며, 여기서 패킷에서 전달되는 FEC 복구 데이터가 생성되는 복구 플로우와 연관된 하나 이상의 소스 플로우들 중 관련 소스 오브젝트들의 컬렉션들로부터의 어떤 소스 오브젝트들은 패킷에서 전달되는 복구 플로우 식별자와 복구 오브젝트 식별자의 결합에 의해 적어도 부분적으로 결정될 수 있다. 일 실시예에서, 복구 플로우 식별자는 TSI(Transmission Session Identifier) 필드에서 전달될 수 있다. 일 실시예에서, 복구 플로우 식별자는 IP 목적지 어드레스 필드와 UDP 포트 번호 필드의 결합으로 전달될 수 있다. 일 실시예에서, 복구 플로우 식별자는 CP(codepoint) 필드에서 전달될 수 있다. 일 실시예에서, 복구 오브젝트 식별자들은 TOI(Transmission Object Identifier)들이다. 일 실시예에서, 복구 오브젝트 식별자들은 OSN(Object Sequence Number)들이다.

[0365] 일 실시예에서, 방법들은 복구 플로우에 대한 복구 플로우 메타데이터를 결정하는 것을 더 포함할 수 있으며, 여기서 복구 플로우 메타데이터는, 패킷의 FEC 복구 데이터가 생성되는 소스 플로우들과 연관되는 관련된 소스 오브젝트들의 하나 이상의 컬렉션들로부터의 소스 오브젝트들과 FEC 복구 데이터를 전달하는 패킷에서 전달된 복구 오브젝트 식별자 사이의 관계들을 시그널링한다. 일 실시예에서, 템플릿들은 복구 플로우 메타데이터에서 관계 정보의 적어도 일부를 시그널링하는데 이용될 수 있다. 일 실시예에서, 복구 플로우에 대한 복구 플로우 메타데이터의 부분들은, 복구 플로우와 연관된 소스 플로우들과 연관되는 관련된 소스 오브젝트들의 적어도 일부가 전송되는 시기 이전에, 수신기 디바이스에 제공될 수 있다.

[0366] 일 실시예에서, 방법들은, 주로 하나 이상의 소스 오브젝트들에 대한 데이터를 전달하는 패킷들이 전송되는 동일한 시간 인터벌 내에서 하나 이상의 소스 오브젝트들로부터 생성된 FEC 복구 데이터를 전달하는 패킷을 전송하는 것을 포함할 수 있다. 일 실시예에서, 동일한 복구 플로우 식별자 및 동일한 복구 오브젝트 식별자를 갖는 패킷에서 전달되는 FEC 복구 데이터는 상이한 소스 플로우들에 있는 2개의 소스 오브젝트들로부터 생성될 수 있으며, 여기서 2개의 소스 오브젝트들을 디코딩하기에 충분한, 동일한 복구 플로우 식별자 및 동일한 복구 오브젝트 식별자를 갖는 패킷들과 이러한 패킷들에서 FEC 복구 데이터가 생성되는 2개의 소스 오브젝트들의 결합으로 수신된 데이터의 양은 2개의 소스 오브젝트들의 총 크기와 동일하거나 또는 그보다 약간 더 많을 수 있다. 일 실시예에서, 복구 플로우 식별자의 부분들은 패킷 내의 상이한 필드들 내에서 전달될 수 있다.

[0367] 도 16은 실시예들 중 임의의 실시예와 함께 수신기 디바이스로서 사용하기에 적절한 모바일 컴퓨팅 디바이스의 시스템 블록도이다. 통상적인 모바일 컴퓨팅 디바이스(1600)는, 내부 메모리(1602)에, 디스플레이(1603)에, 그리고 스피커(1604)에 커플링된 프로세서(1601)를 포함할 수 있다. 추가적으로, 모바일 컴퓨팅 디바이스(1600)는, 무선 데이터 링크에 접속될 수 있는 전자기 방사선(electromagnetic radiation)을 송신 및 수신하기 위한 안테나(1606) 및/또는 프로세서(1601)에 커플링된 셀룰러 전화기 트랜시버(1608) 및 프로세서(1601)에 커플링된 모바일 멀티미디어 브로드캐스트 수신기(1610)를 포함할 것이다. 모바일 컴퓨팅 디바이스(1600)는 통상적으로 또한, 메뉴 선택 버튼들(1612) 또는 사용자 입력들을 수신하기 위한 로커 스위치(rocker switch)들을 포함한다.

[0368] 모바일 컴퓨팅 디바이스(1600)는 또한, 마이크로폰으로부터 수신된 사운드를 무선 전송에 적절한 데이터 패킷들로 디지털화하고 그리고 그 수신된 사운드 데이터 패킷들을 디코딩하고 스피커(1604)에 제공되는 아날로그 신호들을 생성하여 사운드를 생성하는 사운드 인코딩/디코딩(CODEC) 회로(1614)를 포함할 수 있다. 또한, 프로세서(1601), 무선 트랜시버(1608) 및 CODEC 회로(1614) 중 하나 이상은 디지털 신호 프로세서(DSP) 회로를 포함할 수 있다(별개로 도시되지 않음).

[0369] 브로드캐스트 측의 다양한 실시예들은, 도 17에 예시된 서버(1700)와 같은 다양한 상업적으로 이용가능한 서버 디바이스들 중 임의의 디바이스 상에서 구현될 수 있다. 이러한 서버(1700)는 통상적으로, 휘발성 메모리(1702)에 커플링된 프로세서(1701) 및 디스크 드라이브(1703)와 같은 대용량 비휘발성 메모리를 포함한다. 서버(1700)는 또한, 프로세서(1701)에 커플링된 플로피 디스크 드라이브, 컴팩트 디스크(CD), 또는 DVD 디스크 드라이브(1704)를 포함할 수 있다. 서버(1700)는 또한, 다른 브로드캐스트 시스템 컴퓨터들 및 서버들에 커플링된 로컬 영역 네트워크와 같은 네트워크(1706)와의 데이터 접속들을 설정하기 위한, 프로세서(1701)에 커플링된 네트워크 액세스 포트들(1705)을 포함할 수 있다.

[0370] 프로세서들(1701)은, 앞서 설명된 다양한 실시예들의 기능들을 포함하는 다양한 기능들을 수행하기 위해 소프트웨어 명령들(애플리케이션들)에 의해 구성될 수 있는 임의의 프로그램가능 마이크로프로세서, 마이크로컴퓨터 또는 다수의 프로세서 칩 또는 칩들일 수 있다. 일부 모바일 수신기 디바이스들에서, 무선 통신 기능들에 전용되는 하나의 프로세서 및 다른 애플리케이션들을 구동시키는데 전용되는 하나의 프로세서와 같은 다수의 프로세서들이 제공될 수 있다. 통상적으로, 소프트웨어 애플리케이션들은, 이들이 프로세서(1601, 1602)에 액세스되고 로딩되기 전에, 내부 메모리(1702)에 저장될 수 있다. 프로세서(1601, 1602)는 애플리케이션 소프트웨어 명령들을 저장하기에 충분한 내부 메모리를 포함할 수 있다.

[0371] 다양한 실시예들은 브로드캐스트 네트워크를 통해 정보를 통신하는 방법을 포함할 수도 있으며, 상기 방법은, 기존 기술들, 프로토콜들 및/또는 구조들을 사용하여 파일들/오브젝트들을 전달하는 단계; 각각의 패킷이 연속적인 바이트 범위의 파일을 포함하는 패킷들로 파일들/오브젝트들을 전달하는 단계; 바이트 범위에 대해 더 큰 시작 어드레스를 갖는 적어도 하나의 패킷이 바이트 범위에 대해 더 작은 어드레스를 갖는 패킷에 앞서 송신되는 패킷들로 파일들/오브젝트들을 전달하는 단계; 파일들/오브젝트들의 전달에 대해 적절한 통신 프로토콜을 식별하는 LCT/UDP에 대한 새로운 프로토콜 핸들러를 정의하는 단계; 할당 파라미터들 및 오브젝트들의 상이한 컬렉션들을 식별하기 위해 코드 포인트를 사용하는 단계; 파일들/오브젝트들의 전달 및 전달의 시그널링을 지원하기 위해 세션 정의 또는 세션 설명 메시지 또는 컴포넌트를 사용하는 단계; 크기 필드/헤더를 송신하기에 앞서 파일/오브젝트의 데이터를 송신하는 단계; 제한된 리스트를 시그널링하기 위해 시작 전송 오브젝트 식별자(TOI) 또는 종료 TOI 또는 둘 모두를 사용하는 단계; 사용 중인 정적 파일 전달 정보(FDI)를 고유하게 식별하기 위해 코드 포인트를 사용하는 단계; 서버 및 클라이언트를 동기화하기 위해 LCT 시간 연장 헤더를 사용하는 단계; 지터 또는 레이턴시 측정들에 대해 LCT 시간 연장 헤더를 사용하는 단계; 세션 설명 및 코드 포인트에 대한 참조로서 복구 플로우를 정의하는 단계 및 세부적인 보호 특성들을 제공하는 단계; FEC 보호되도록 수퍼 오브젝트를 정의하는 단계; 오직 복구 패킷들을 송신하기 위해, ALC 인스턴스생성으로서 FEC 프레임워크를 사용하는 단계; 개별적인 FEC 전송 오브젝트들의 크기를 전송하는 것을 가능하게 하는 LCT 연장 헤더를 정의하는 단계; 플로우 식별자(FLID)를 사용하는 것을 시그널링하거나 지원하기 위해 기존 필드들을 사용하는 단계; 시그널링 또는 프로토콜들에 대한 다른 변형들 없이 전송 오브젝트를 식별하기 위해 TOI를 사용하는 단계; 플로우 선언들을 시그널링하기 위해 정적 FDI를 사용하는 단계; 복구 패킷 헤더들 내의 대역-내 시그널링을 회피하도록, 복구 플로우에 의해 보호되는 전송 소스 오브젝트들을 시그널링하는 단계; 및 복구 플로우 선언 내에 템플레이팅을 사용하여, 복구 플로우에 의해 보호될 소스 오브젝트 TOI들을 시그널링하는 단계를 포함할 수도 있다.

[0372] 다양한 실시예들은, 기존 브로드캐스트 솔루션들에 비해 다수의 향상들 및 이득들을 제공할 수도 있다. 실시예들은, 관련된 오브젝트들의 시퀀스의 개선된 FLUTE(File Delivery Over Unidirectional Transport)-기반 전달을 제공한다. 실시예들은, 플로우 오브젝트 전달을 달성하기 위한 능력; HTTP를 통한 동적 적응형 스트리밍(DASH) 및 유사한 애플리케이션들, 표준들, 또는 프로토콜들에 대한 지원; 및 컨텐츠가 오브젝트들로부터 복원될 수도 있기 이전에 수신되도록 요구되는 오브젝트들의 개수를 감소시키기 위한 능력을 제공한다. 실시예들은, 스트리밍된/전송된 각각의 오브젝트에 대한 파일 전달 테이블(FDT)을 전달할 필요성을 제거한다. 실시예들은, 사전에 FLUTE 수신기들로의 정보의 프로비저닝(provisioning)에 대한 지원을 제공하며, 이는, 오브젝트들이 FLUTE 수신기들에 송신되거나 FLUTE 수신기들에 의해 수신되기 이전에 달성될 수도 있다. 실시예들은, 타이밍 정보, 균일 자원 식별자(URI)들, 및 플로우 내의 오브젝트들에 대한 다른 식별 정보의 전달을 개선한다. 실시예들은, 수신기 디바이스들 내의 개선된 결정 실행 및 계획을 지원한다. 실시예들은, 클라이언트 애플리케이션들로 프로비저닝 링크들에 대한 지원을 제공한다. 실시예들은, MPD(Media Presentation Description)에서 설명된 표현의 DASH 세그먼트들과 오브젝트들 사이의 관계들을 설정 및 식별하는 것을 지원한다. 실시예들은, 컨텐츠의 청크 전달/수신을 지원한다. 실시예들은, 순방향 에러 정정(FEC) 동작들 또는 수신기 디바이스들의 능력들의 사용에 독립적인 송신기 엔드-투-엔드 레이턴시의 감소들을 가능하게 한다. 실시예들은, FEC가 사용되지 않거나 요구되지 않는 경우, 수신기 엔트-투-엔드 레이턴시의 감소들을 가능하게 한다. 실시예들은, FEC 사용이 수용가능한 것으로 간주될 때까지 동작들을 대기 또는 일시정지하기 위한 능력을 제공한다. 실시예들은, 가변 크기 소스 패킷들을 생성, 송신, 및 수신하는 것을 지원한다. 실시예들은, 액세스 유닛들, 네트워크 추상 층 유닛들, 샘플들, 파일 포맷 또는 유사한 구조들의 박스들과 같은 근본적인 미디어 구조 경계들로 소스 패킷 경계들을 정렬하는 것을 지원한다. 실시예들은, 어떠한 FEC 시맨틱스도 없는 소스 컨텐츠의 전달을 지원하며, FEC 능력들을 갖지 않는 수신기 디바이스들이 소스 컨텐츠를 수신하게 한다. 몇몇 실시예들은, FEC 오브젝트 번들링을 지원하고; 다수의 오브젝트들에 걸친 FEC 보호를 제공하고; 다른 실시예들은 개별적인 소스 오브젝트들의 부분들에 대한 FEC 보호를 제공하며; 또 다른 실시예들은 개별적인 소스 오브젝트들의 부분들의 번들들의 FEC 보호를 제공한다. 실시예들은, RFC 2616에서 정의된 것과 같은 완전한 HTTP GET 응답들로서 오브젝트들을 전달하는 것을 가능하게 한다. 실시예들은, 현재 브로드캐스트 및 FLUTE 표준들과의 호환성 및 그들에 재사용에 대한 지원을 제공한다. 실시예들은, FDT들을 사용하지 않으면서, 본 명세서에 설명된 관련 오브젝트들의 시퀀스들의 전달을 이용하여, 동일한 세션에서 FDT들을 사용하는 표준 FLUTE 오브젝트들의 전달을 지원한다. 다양한 실시예들은 또한, 후술되는 다수의 부가적인 이득들 및 향상들을 포함할 수도 있다.

[0373] 다양한 실시예들에 의해 제공되는 기존 브로드캐스트 솔루션들에 대한 부가적인 향상들 및 이득들은 또한, MPEG 미디어 전송(MMT) 내에서 일반 파일들 및 에셋들의 전송; 코드 포인트들의 사용; 오브젝트들의 부분으로서 하이퍼텍스트 전송 프로토콜(HTTP) 헤더들의 사용; 템플레이팅; 파일의 컨텐츠 특정 애스펙트들을 전달하기 위한 코드 포인트들에서의 시그널링 및 코드 포인트들의 사용; 코드 포인트들을 통해 시그널링하기에 적절한 특성들을 포함하는 MMT 프로토콜의 변형; 엔티티 헤더 또는 코드 포인트의 트레일러를 통한 오브젝트 전달 크기의 시그널링; 오브젝트가 규칙적으로 전달된 HTTP 자원으로서 사용하기에 적절하도록, HTTP 엔티티 헤더 및 HTTP 엔티티 보디의 결합으로서 단방향 프로토콜을 통한 오브젝트의 전달; 청크 또는 순차적 전달을 통한 오브젝트의 전달; 트레일러에 오브젝트 전달의 부분으로서 크기 값 또는 다른 정보를 부가하는 것에 의한 전달의 시작에서 알려져 있는 오브젝트에 관한 오브젝트의 크기 또는 다른 정보의 표시; 코드 포인트 전달의 부분으로서 오브젝트 크기의 시그널링; 및 MPEG 미디어 전송(MMT) 프로토콜 헤더 내의 패킷_id 속성(이는, 오브젝트가 속하는 플로우를 식별함) 및 (오브젝트들의 플로우 내의 특정한 오브젝트를 식별하는) 일반 파일 전달(GFD) 프로토콜 헤더에서 전달된 전송 오브젝트 식별자(TOI) 속성에 의해, 페이로드가 관련되는 오브젝트가 식별되기 위한 MMT 프로토콜을 통한 오브젝트의 전달을 포함할 수도 있다.

[0374] 전술한 방법 설명들 및 프로세스 흐름도들은 단지 예시적인 예들로서 제공되며, 다양한 양상들의 단계들이 제시된 순서로 수행되어야 한다는 것을 요구하거나 암시하도록 의도되지 않는다. 당업자에 의해 인식될 바와 같이, 전술한 양상들에서의 단계들의 순서는 임의의 순서로 수행될 수도 있다. "이후", "그 후", "다음으로" 등과 같은 단어들은 단계들의 순서를 제한하는 것으로 의도되지 않으며, 이들 단어들은 단순히 방법들의 설명을 통해 독자에게 안내하기 위해 사용된다. 추가로, 예를 들어, 명사의 단수 표현을 사용하는 청구항 엘리먼트들에 대한 임의의 참조는 엘리먼트를 단수로 제한하는 것으로서 해석되는 것은 아니다.

[0375] 본 명세서에 기재된 양상들과 관련하여 설명된 다양한 예시적인 로직 블록들, 모듈들, 회로들, 및 알고리즘 단계들은 전자 하드웨어, 컴퓨터 소프트웨어, 또는 이 둘의 결합들로서 구현될 수도 있다. 하드웨어와 소프트웨어의 이러한 상호교환가능성을 명확히 예시하기 위해, 다양한 예시적인 컴포넌트들, 블록들, 모듈들, 회로들, 및 단계들은 그들의 기능의 관점들에서 일반적으로 상술되었다. 그러한 기능이 하드웨어로서 구현되는지 또는 소프트웨어로서 구현되는지는 특정 애플리케이션 및 전체 시스템에 부과된 설계 제한들에 의존한다. 당업자들은 설명된 기능을 각각의 특정한 애플리케이션에 대해 다양한 방식들로 구현할 수도 있지만, 그러한 구현 결정들이 본 발명의 범위를 벗어나게 하는 것으로서 해석되지는 않아야 한다.

[0376] 본 명세서에 기재된 양상들과 관련하여 설명된 다양한 예시적인 로직들, 로직 블록들, 모듈들, 및 회로들은 범용 프로세서, 디지털 신호 프로세서(DSP), 주문형 집적회로(ASIC), 필드 프로그래밍가능 게이트 어레이(FPGA) 또는 다른 프로그래밍가능 로직 디바이스, 이산 게이트 또는 트랜지스터 로직, 이산 하드웨어 컴포넌트들, 또는 본 명세서에 설명된 기능들을 수행하도록 설계된 이들의 임의의 결합으로 구현되거나 수행될 수도 있다. 범용 프로세서는 멀티프로세서일 수도 있지만, 대안적으로, 프로세서는 임의의 종래의 프로세서, 제어기, 마이크로제어기, 또는 상태 머신일 수도 있다. 또한, 프로세서는 컴퓨팅 디바이스들의 결합, 예를 들어 DSP와 멀티프로세서의 결합, 복수의 멀티프로세서들, DSP 코어와 결합된 하나 이상의 멀티프로세서들, 또는 임의의 다른 그러한 구성으로서 구현될 수도 있다. 대안적으로, 몇몇 단계들 또는 방법들은 주어진 기능에 특정한 회로에 의해 수행될 수도 있다.

[0377] 하나 이상의 예시적인 양상들에서, 설명된 기능들은 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 임의의 결합으로 구현될 수 있다. 소프트웨어로 구현되면, 기능들은 비-일시적인 컴퓨터-판독가능 저장 매체, 비-일시적인 컴퓨터-판독가능 매체, 또는 비-일시적인 프로세서-판독가능 매체 상에 하나 이상의 명령들 또는 코드로서 저장될 수도 있다. 본 명세서에 기재된 방법 또는 알고리즘의 단계들은, 비-일시적인 컴퓨터-판독가능 또는 프로세서-판독가능 저장 매체 상에 상주할 수도 있는 프로세서-실행가능 소프트웨어 모듈로 구현될 수도 있다. 비-일시적인 컴퓨터-판독가능 또는 프로세서-판독가능 저장 매체들은, 컴퓨터 또는 프로세서에 의해 액세스될 수도 있는 임의의 저장 매체일 수도 있다. 제한이 아닌 예로서, 그러한 비-일시적인 컴퓨터-판독가능 또는 프로세서-판독가능 매체들은 RAM, ROM, EEPROM, FLASH 메모리, CD-ROM 또는 다른 광학 디스크 저장부, 자기 디스크 저장 또는 다른 자기 저장 디바이스들, 또는 명령들 또는 데이터 구조들의 형태로 원하는 프로그램 코드를 저장하는데 사용될 수도 있고, 컴퓨터에 의해 액세스될 수도 있는 임의의 다른 매체를 포함할 수도 있다. 본 명세서에 사용되는 바와 같이, 디스크(disk) 및 디스크(disc)는 컴팩트 디스크(disc)(CD), 레이저 디스크(disc), 광학 디스크(disc), 디지털 다기능 디스크(digital versatile disc)(DVD), 플로피 디스크(disk) 및 블루-레이(blu-Ray) 디스크(disc)를 포함하며, 여기서 디스크(disk)들은 일반적으로 데이터를 자기적으로 재생하지만, 디스크(disc)들은 레이저들을 이용하여 광학적으로 데이터를 재생한다.

[0378] 상기의 것들의 결합들이 또한 비-일시적인 컴퓨터-판독가능 및 프로세서-판독가능 매체들의 범위 내에 포함된다. 부가적으로, 방법 또는 알고리즘의 동작들은, 비-일시적인 프로세서-판독가능 매체 및/또는 컴퓨터-판독가능 매체 상에 코드들 및/또는 명령들 중 하나 또는 이들의 임의의 결합 또는 세트로서 상주할 수도 있으며, 이는 컴퓨터 프로그램 물건 내로 통합될 수도 있다.

[0379] 기재된 실시예들의 이전 설명은 임의의 당업자가 본 발명을 사용 또는 실시할 수 있도록 제공된다. 이들 실시예들에 대한 다양한 변형들은 당업자들에게 용이하게 명백할 것이며, 본 명세서에 정의된 일반적인 원리들은 본 발명의 사상 또는 범위를 벗어나지 않으면서 다른 실시예들에 적용될 수도 있다. 따라서, 본 발명은 본 명세서에 설명된 실시예들로 제한되도록 의도되는 것이 아니라, 다음의 청구항들 및 본 명세서에 기재된 원리들 및 신규한 특성들과 일치하는 가장 넓은 범위에 부합할 것이다.

Claims (132)

1. 브로드캐스트 네트워크를 통해 정보를 통신하는 방법으로서,
   관련된 소스 오브젝트들의 컬렉션(collection)을 소스 플로우(source flow)와 연관시키는 단계; 및
   소스 오브젝트들이 서로에 대한 그들의 관계에 기초하여 수신기 디바이스에 의해 수신되어 복원될 수 있도록, 상기 소스 플로우와 연관되는 상기 관련된 소스 오브젝트들의 컬렉션의 소스 오브젝트들을 상기 브로드캐스트 네트워크를 통해 전송하는 단계를 포함하는, 정보를 통신하는 방법.
2. 제 1항에 있어서,
   상기 소스 플로우에 대한 소스 플로우 식별자를 결정하는 단계; 및
   상기 소스 플로우와 연관되는 상기 관련된 소스 오브젝트들의 컬렉션의 적어도 하나의 소스 오브젝트의 데이터를 포함하는 패킷에 상기 소스 플로우 식별자를 포함시키는 단계를 더 포함하는, 정보를 통신하는 방법.
3. 제 2항에 있어서,
   상기 패킷에서 데이터를 식별하기 위해 상기 패킷에서의 바이트 범위(byte range)를 사용하는 단계를 더 포함하는, 정보를 통신하는 방법.
4. 제 2항에 있어서,
   상기 패킷에서 소스 오브젝트의 데이터를 식별하는 바이트 범위를 상기 패킷에 포함시키는 단계를 더 포함하는, 정보를 통신하는 방법.
5. 제 2항에 있어서,
   상기 패킷의 TSI(transmission session identifier) 필드를 상기 소스 플로우 식별자로서 사용하는 단계를 더 포함하는, 정보를 통신하는 방법.
6. 제 2항에 있어서,
   상기 패킷에 소스 플로우 식별자를 포함시키는 단계는 상기 패킷의 TSI(transmission session identifier) 필드에 상기 소스 플로우 식별자를 포함시키는 단계를 포함하는, 정보를 통신하는 방법.
7. 제 2항에 있어서,
   상기 패킷의 IP(Internet protocol) 목적지 주소 필드와 UDP(user datagram protocol) 포트 번호 필드의 결합을 상기 소스 플로우 식별자로서 사용하는 단계를 더 포함하는, 정보를 통신하는 방법.
8. 제 2항에 있어서,
   상기 패킷에 소스 플로우 식별자를 포함시키는 단계는 IP(Internet protocol) 목적지 주소 필드와 UDP(user datagram protocol) 포트 번호 필드의 결합에 상기 소스 플로우 식별자를 포함시키는 단계를 포함하는, 정보를 통신하는 방법.
9. 제 2항에 있어서,
   상기 패킷의 CP(codepoint) 필드를 상기 소스 플로우 식별자로서 사용하는 단계를 더 포함하는, 정보를 통신하는 방법.
10. 제 2항에 있어서,
    상기 패킷에 소스 플로우 식별자를 포함시키는 단계는 데이터 패킷의 CP(codepoint) 필드에 상기 소스 플로우 식별자를 포함시키는 단계를 포함하는, 정보를 통신하는 방법.
11. 제 2항에 있어서,
    상기 관련된 소스 오브젝트들의 컬렉션을 전송하는 단계는 관련된 소스 오브젝트들의 복수의 컬렉션들을 전송하는 단계를 포함하고 ― 각각의 컬렉션은 복수의 상이한 소스 플로우들 중 하나와 연관되고, 상기 복수의 상이한 소스 플로우들 각각은 고유 소스 플로우 식별자를 포함함 ―; 그리고
    상기 소스 플로우와 연관되는 상기 관련된 소스 오브젝트들의 컬렉션의 적어도 하나의 소스 오브젝트의 데이터를 포함하는 패킷에 상기 소스 플로우 식별자를 포함시키는 단계는 상기 소스 오브젝트의 데이터를 포함하는 패킷에 상기 소스 플로우들의 고유 소스 플로우 식별자를 포함시키는 단계를 포함하는, 정보를 통신하는 방법.
12. 제 11항에 있어서,
    상기 관련된 소스 오브젝트들의 컬렉션을 전송하는 단계는 FEC(forward error correction) 복구 데이터, 복구 플로우 식별자 및 복구 오브젝트 식별자를 포함하는 적어도 하나의 패킷을 전송하는 단계를 포함하고,
    상기 방법은,
    복구 플로우를 상기 복수의 상이한 소스 플로우들 중 하나 이상과 연관시키는 단계;
    상기 복구 플로우에 대한 복구 플로우 식별자를 결정하는 단계;
    상기 복구 플로우에 대한 복구 오브젝트 식별자들의 컬렉션을 결정하는 단계; 및
    패킷의 복구 플로우 식별자와 복구 오브젝트 식별자의 결합에 적어도 부분적으로 기초하여, 연관된 복수의 소스 플로우들로부터의 소스 오브젝트들 중 어느 것으로부터, 상기 패킷에 포함된 상기 FEC 복구 데이터가 생성되는지를 결정하는 단계를 더 포함하는, 정보를 통신하는 방법.
13. 제 12항에 있어서,
    상기 복구 플로우 식별자는 TSI(transmission session identifier) 필드에 포함되는, 정보를 통신하는 방법.
14. 제 12항에 있어서,
    상기 복구 플로우 식별자는 IP(Internet protocol) 목적지 주소 필드와 UDP(user datagram protocol) 포트 번호 필드의 결합에 포함되는, 정보를 통신하는 방법.
15. 제 12항에 있어서,
    상기 복구 플로우 식별자는 CP(codepoint) 필드에 포함되는, 정보를 통신하는 방법.
16. 제 12항에 있어서,
    상기 복구 오브젝트 식별자는 TOI(transmission object identifier)인, 정보를 통신하는 방법.
17. 제 12항에 있어서,
    상기 복구 오브젝트 식별자는 OSN(object sequence number)인, 정보를 통신하는 방법.
18. 제 12항에 있어서,
    상기 FEC 복구 데이터를 포함하는 적어도 하나의 패킷을 전송하는 단계는 동일한 시간 인터벌 내에 FEC 복구 데이터를 포함하는 적어도 하나의 패킷을 상응하는 소스 오브젝트에 대한 데이터를 포함하는 패킷으로서 전송하는 단계를 포함하는, 정보를 통신하는 방법.
19. 제 12항에 있어서,
    동일한 복구 플로우 식별자 및 동일한 복구 오브젝트 식별자를 갖는 패킷들로부터 그리고 2개의 소스 오브젝트들의 총 크기보다 크거나 그와 동일한 상기 2개의 소스 오브젝트들 중 어느 하나에 대한 데이터를 포함하는 패킷들로부터 결합하여 수신되는 데이터의 양이 상기 2개의 소스 오브젝트들을 디코딩하기에 충분하도록 하기 위해, 상이한 소스 플로우들에서 상기 2개의 소스 오브젝트들로부터의 상기 동일한 복구 플로우 식별자 및 상기 동일한 복구 오브젝트 식별자를 갖는 패킷들에 대한 FEC 복구 데이터를 생성하는 단계를 더 포함하는, 정보를 통신하는 방법.
20. 제 12항에 있어서,
    상기 복구 플로우 식별자의 부분들은 FEC 복구 데이터를 포함하는 패킷의 상이한 데이터 필드들에 포함되는, 정보를 통신하는 방법.
21. 제 12항에 있어서,
    복구 플로우에 대한 복구 플로우 선언(repair flow declaration)이 FEC 복구 데이터를 포함하는 패킷의 복구 오브젝트 식별자와 소스 플로우들과 연관되는 관련된 소스 오브젝트들의 컬렉션으로부터의 소스 오브젝트들 간의 관계를 시그널링하기에 적절한 정보를 포함하도록, 상기 복구 플로우 선언을 결정하는 단계를 더 포함하고,
    상기 소스 플로우들로부터 상기 패킷의 FEC 복구 데이터가 생성되는, 정보를 통신하는 방법.
22. 제 21항에 있어서,
    상기 복구 플로우 선언을 통해서 상기 관계를 시그널링하기 위해 템플릿(template)을 사용하는 단계를 더 포함하는, 정보를 통신하는 방법.
23. 제 21항에 있어서,
    상기 복구 플로우 선언의 부분은 상기 복구 플로우와 연관되는 상기 소스 플로우와 연관된 적어도 하나의 소스 오브젝트보다 앞서 수신기 디바이스에 전송되는, 정보를 통신하는 방법.
24. 제 2항에 있어서,
    상기 관련된 소스 오브젝트들의 컬렉션의 각각의 소스 오브젝트에 대한 소스 오브젝트 식별자를 결정하는 단계; 및
    소스 오브젝트들에 대한 데이터를 포함하는 하나 이상의 패킷들에 상기 소스 오브젝트 식별자를 포함시키는 단계를 더 포함하는, 정보를 통신하는 방법.
25. 제 24항에 있어서,
    상기 관련된 소스 오브젝트들의 컬렉션의 상응하는 소스 오브젝트를 식별하기 위해 상기 소스 플로우 식별자와 상기 소스 오브젝트 식별자의 결합을 사용하는 단계를 더 포함하는, 정보를 통신하는 방법.
26. 제 24항에 있어서,
    상기 데이터를 포함하는 패킷에 소스 오브젝트 식별자를 포함시키는 단계는 상기 소스 플로우 식별자와 상기 소스 오브젝트 식별자의 결합이 상응하는 소스 오브젝트를 식별하도록 하기 위해 상기 패킷에 상기 소스 오브젝트 식별자를 포함시키는 단계를 포함하고,
    상기 패킷은 상기 상응하는 소스 오브젝트에 대한 데이터를 전달하는, 정보를 통신하는 방법.
27. 제 24항에 있어서,
    TOI(transmission object identifier)를 상기 소스 오브젝트 식별자로서 사용하는 단계를 더 포함하는, 정보를 통신하는 방법.
28. 제 24항에 있어서,
    OSN(object sequence number)를 상기 소스 오브젝트 식별자로서 사용하는 단계를 더 포함하는, 정보를 통신하는 방법.
29. 제 24항에 있어서,
    소스 오브젝트들이 서로에 대한 그들의 관계에 기초하여 상기 수신기 디바이스에 의해 수신되어 복원될 수 있도록, 상기 소스 플로우와 연관되는 상기 관련된 소스 오브젝트들의 컬렉션에 대한 FEC(forward error correction) 복구 데이터를 상기 브로드캐스트 네트워크를 통해 전송하는 단계를 더 포함하고,
    상기 소스 플로우와 연관되는 상기 관련된 소스 오브젝트들 중 하나 이상에 대한 FEC 복구 데이터를 포함하는 각각의 패킷은 상기 소스 플로우를 식별하는 상기 소스 플로우 식별자를 포함하고 ― 상기 패킷이 상기 소스 플로우에 대한 FEC 복구 데이터를 포함함 ―,
    상기 소스 플로우와 연관되는 상기 관련된 소스 오브젝트들 중 하나 이상에 대한 FEC 복구 데이터를 포함하는 각각의 패킷은 하나 이상의 소스 오브젝트들의 하나 이상의 소스 오브젝트 식별자들을 전달하며 ― 상기 패킷에서 전달되는 FEC 복구 데이터가 상기 하나 이상의 소스 오브젝트들로부터 생성됨 ―, 그리고
    상기 소스 플로우 식별자와 하나 이상의 소스 오브젝트 식별자들의 결합은 상기 소스 플로우와 연관되는 관련된 소스 오브젝트들의 컬렉션으로부터 하나 이상의 소스 오브젝트들을 식별하는 ― 상기 패킷에서 전달되는 FEC 복구 데이터가 상기 소스 플로우로부터 생성됨 ―, 정보를 통신하는 방법.
30. 제 29항에 있어서,
    동일한 시간 인터벌 내에 하나 이상의 소스 오브젝트들로부터 생성되는 FEC 복구 데이터를 전달하는 패킷들을 상기 하나 이상의 소스 오브젝트들에 대한 데이터를 전달하는 패킷들로서 전송하는 단계를 더 포함하는, 정보를 통신하는 방법.
31. 제 1항에 있어서,
    상기 소스 플로우와 연관되는 상기 관련된 소스 오브젝트들의 컬렉션의 소스 오브젝트들을 상기 브로드캐스트 네트워크를 통해 전송하는 단계는 상기 소스 오브젝트들을 그들의 상응하는 복구 오브젝트들과는 관계없이 전송하는 단계를 포함하는, 정보를 통신하는 방법.
32. 제 31항에 있어서,
    소스 오브젝트를 그의 상응하는 복구 오브젝트로부터 구별하기 위해 SDP(session description protocol) 정보를 사용하는 단계를 더 포함하는, 정보를 통신하는 방법.
33. 제 1항에 있어서,
    상기 관련된 소스 오브젝트들의 컬렉션의 적어도 하나의 소스 오브젝트는 파일의 바이트 범위를 포함하는, 정보를 통신하는 방법.
34. 제 33항에 있어서,
    URL(uniform resource locator)이 상기 파일과 연관되고,
    상기 방법은 상기 URL 및 상기 바이트 범위를 통해 상기 적어도 하나의 소스 오브젝트를 식별하는 단계를 더 포함하는, 정보를 통신하는 방법.
35. 제 1항에 있어서,
    상기 관련된 소스 오브젝트들의 컬렉션의 적어도 하나의 소스 오브젝트는 파일인, 정보를 통신하는 방법.
36. 제 35항에 있어서,
    URL(uniform resource locator)가 상기 파일과 연관되고,
    상기 방법은 상기 URL을 통해 상기 적어도 하나의 소스 오브젝트를 식별하는 단계를 더 포함하는, 정보를 통신하는 방법.
37. 제 1항에 있어서,
    상기 관련된 소스 오브젝트들의 컬렉션의 적어도 하나의 소스 오브젝트는 HTTP(hypertext transfer protocol) 헤더 및 파일의 바이트 범위를 포함하는, 정보를 통신하는 방법.
38. 제 37항에 있어서,
    상기 소스 오브젝트들 중 적어도 일부는 HTTP 헤더, 연관된 파일, 및 HTTP 테일러를 포함하는, 정보를 통신하는 방법.
39. 제 1항에 있어서,
    상기 소스 플로우와 연관되는 소스 오브젝트들의 컬렉션에 대한 소스 플로우 선언이 위치, 이름, 이용가능 시간, 또는 상기 소스 플로우와 연관된 소스 오브젝트들의 컬렉션에 대한 다른 메타 데이터 간의 관계들을 시그널링하기에 적절한 정보를 포함하도록, 상기 소스 플로우 선언을 결정하는 단계를 더 포함하는, 정보를 통신하는 방법.
40. 제 1항에 있어서,
    상기 관련된 소스 오브젝트들의 컬렉션을 전송하는 단계는 상기 관련된 소스 오브젝트들의 컬렉션을 MBMS(multimedia broadcast multicast services)를 통해 전송하는 단계를 포함하는, 정보를 통신하는 방법.
41. 제 1항에 있어서,
    상기 관련된 소스 오브젝트들의 컬렉션을 전송하는 단계는 상기 관련된 소스 오브젝트들의 컬렉션을 FLUTE(file delivery over unidirectional transport)를 통해 전송하는 단계를 포함하는, 정보를 통신하는 방법.
42. 제 1항에 있어서,
    상기 관련된 소스 오브젝트들의 컬렉션을 전송하는 단계는 FEC(forward error correction) 시그널링 정보는 전송하지 않고 상기 소스 오브젝트들을 전송하는 단계를 포함하는, 정보를 통신하는 방법.
43. 제 1항에 있어서,
    상기 소스 오브젝트들 적어도 일부는 HTTP(hypertext transfer protocol) 헤더 및 파일의 바이트 범위를 포함하는, 정보를 통신하는 방법.
44. 브로드캐스트 네트워크를 통해 하나 이상의 소스 오브젝트들을 전송하는 방법으로서,
    전체 파일의 부분들을 수신하는 단계;
    상기 전체 파일을 수신하기 이전에 수신된 부분들에 기초하여 소스 오브젝트들을 생성하는 단계; 및
    상기 전체 파일을 수신하기 이전에 수신기 디바이스에 생성된 소스 오브젝트들을 전송하는 단계를 포함하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
45. 제 44항에 있어서,
    상기 전체 파일을 수신하기 이전에 수신기 디바이스에 생성된 소스 오브젝트들을 전송하는 단계는 상기 전체 파일의 데이터 순서와는 상이한 순서로 상기 생성된 소스 오브젝트들에 대한 데이터를 전송하는 단계를 포함하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
46. 제 45항에 있어서,
    상기 전체 파일의 부분들을 수신하는 단계는 파일의 처음에 파일 크기를 포함하는 상기 파일의 부분들을 수신하는 단계를 포함하고,
    상기 파일 크기 이후의 상기 파일의 적어도 일부 데이터가 상기 파일 크기보다 먼저 전송되도록 하는 순서로 소스 오브젝트의 데이터가 전송되는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
47. 제 44항에 있어서,
    소스 오브젝트는 HTTP(Hypertext Transfer Protocol) 헤더 및 연관된 파일을 포함하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
48. 제 44항에 있어서,
    소스 오브젝트는 HTTP(Hypertext Transfer Protocol) 헤더, 연관된 파일 및 HTTP 테일러를 포함하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
49. 제 44항에 있어서,
    소스 플로우와 연관된 소스 오브젝트들의 컬렉션에 대한 소스 플로어 선언을 결정하는 단계를 더 포함하고,
    상기 소스 플로우 선언은 위치, 이름, 이용가능 시간, 또는 상기 소스 플로우와 연관되는 소스 오브젝트들의 컬렉션에 대한 다른 메타데이터 간의 관계들을 시그널링하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
50. 제 49항에 있어서,
    상기 소스 플로우 선언에서 관계 정보를 시그널링하기 위해 템플릿을 사용하는 단계를 더 포함하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
51. 제 49항에 있어서,
    상기 소스 플로우와 연관되는 적어도 하나의 관련된 소스 오브젝트에 앞서 상기 소스 플로우에 대한 소스 플로우 선언의 부분들을 상기 수신기 디바이스에 전송하는 단계를 더 포함하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
52. 제 51항에 있어서,
    상기 소스 플로우와 연관되는 적어도 하나의 관련된 소스 오브젝트에 앞서 상기 소스 플로우에 대한 소스 플로우 선언의 부분들을 상기 수신기 디바이스에 전송하는 단계는,
    타이밍 정보;
    URI(uniform resource identifier); 및
    소스 오브젝트들에 대한 암호해독 키들을 식별하는 정보
    중 적어도 하나를 포함하는 부분을 전송하는 단계를 포함하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
53. 제 51항에 있어서,
    상기 소스 플로우와 연관되는 적어도 하나의 관련된 소스 오브젝트에 앞서 상기 소스 플로우에 대한 소스 플로우 선언의 부분들을 상기 수신기 디바이스에 전송하는 단계는,
    상기 소스 플로우와 연관되는 적어도 하나의 소스 오브젝트를 전송하기에 앞서 상기 소스 플로우 선언의 부분을 상기 수신기 디바이스에 대역외에서 송신하는 단계; 및
    소스 오브젝트와 함께 상기 소스 플로우 선언의 다른 부분을 대역내에서 송신하는 단계를 포함하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
54. 제 53항에 있어서,
    상기 소스 오브젝트와 함께 상기 소스 플로우 선언의 다른 부분을 대역내에서 송신하는 단계는 상기 소스 오브젝트에 대한 데이터의 마지막 부분의 표시를 송신하는 단계를 포함하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
55. 제 51항에 있어서,
    상기 소스 플로우 선언의 부분들을 상기 수신기 디바이스에 제공하는 단계는 파일 전달 테이블을 송신하지 않고 단방향 전송 프로토콜을 통해 상기 소스 플로우 선언의 부분들을 송신하는 단계를 포함하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
56. 제 44항에 있어서,
    상기 전체 파일을 수신하기 이전에 수신기 디바이스에 생성된 소스 오브젝트들을 전송하는 단계는 MBMS(multimedia broadcast multicast services)를 통해 관련된 소스 오브젝트들의 컬렉션을 전송하는 단계를 포함하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
57. 제 44항에 있어서,
    상기 전체 파일을 수신하기 이전에 수신기 디바이스에 생성된 소스 오브젝트들을 전송하는 단계는 FLUTE(file delivery over unidirectional transport)를 통해 관련된 소스 오브젝트들의 컬렉션을 전송하는 단계를 포함하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
58. 제 44항에 있어서,
    관련된 소스 오브젝트들의 컬렉션을 전송하는 단계는 소스 오브젝트들을 그들의 상응하는 복구 오브젝트들에 관계없이 전송하는 단계를 포함하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
59. 제 44항에 있어서,
    소스 오브젝트를 그의 상응하는 복구 오브젝트로부터 구별하기 위해 SDP(session description protocol) 정보를 사용하는 단계를 더 포함하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
60. 제 44항에 있어서,
    상기 전체 파일을 수신하기 이전에 수신기 디바이스에 생성된 소스 오브젝트들을 전송하는 단계는 FEC(forward error correction) 시그널링 정보를 전송하지 않고 상기 소스 오브젝트들을 전송하는 단계를 포함하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
61. 제 44항에 있어서,
    개별 소스 오브젝트의 부분들을 보호하기 위해 FEC(forward error correction) 동작들을 수행하는 단계를 더 포함하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
62. 제 61항에 있어서,
    다수의 FEC 인코딩들을 통해 상기 개별 소스 오브젝트를 전송하는 단계를 더 포함하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
63. 제 61항에 있어서,
    소스 오브젝트의 보호되는 부분에 대한 TOI(transmission object identifier) 또는 OSN(object sequence number)을 복구 패킷 헤더에 추가하는 단계; 및
    상기 보호되는 부분의 바이트 범위를 그의 전송 소스 블록의 마지막에 추가하는 단계를 더 포함하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
64. 제 61항에 있어서,
    보호될 소스 오브젝트의 부분의 처음에 소스 심볼들을 추가하는 단계; 및
    보호되는 부분의 바이트 범위를 복구 패킷 헤더에 추가하는 단계를 더 포함하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
65. 제 61항에 있어서,
    소스 오브젝트의 보호되는 부분의 바이트 범위의 시작 포지션 및 상기 바이트 범위에 의해 커버되는 다수의 심볼들을 복구 패킷 헤더 내에 추가하는 단계; 및
    바이트들 또는 옥텟들의 상기 보호되는 부분의 크기를 전송 소스 블록의 마지막에 추가하는 단계를 더 포함하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
66. 제 44항에 있어서,
    상기 전체 파일을 수신하기 이전에 수신기 디바이스에 생성된 소스 오브젝트들을 전송하는 단계는 소스 오브젝트가 규칙적으로 전달되는 HTTP(hypertext transfer protocol) 자원으로서 상기 수신기 디바이스에서 사용하기에 적절하도록 하기 위해서 상기 소스 오브젝트를 HTTP 엔티티 헤더와 HTTP 엔티티 보디의 결합으로서 상기 수신기 디바이스에 단방향 프로토콜을 통해 전달하는 단계를 포함하는, 하나 이상의 소스 오브젝트들을 전송하는 방법.
67. 통신 시스템으로서,
    관련된 소스 오브젝트들의 컬렉션을 소스 플로우와 연관시키기 위한 수단; 및
    소스 오브젝트들이 서로에 대한 그들의 관계에 기초하여 수신기 디바이스에 의해 수신되어 복원될 수 있도록, 상기 소스 플로우와 연관되는 상기 관련된 소스 오브젝트들의 컬렉션의 소스 오브젝트들을 브로드캐스트 네트워크를 통해 전송하기 위한 수단을 포함하는, 통신 시스템.
68. 제 67항에 있어서,
    상기 소스 플로우에 대한 소스 플로우 식별자를 결정하기 위한 수단; 및
    상기 소스 플로우와 연관되는 상기 관련된 소스 오브젝트들의 컬렉션의 적어도 하나의 소스 오브젝트의 데이터를 포함하는 패킷에 상기 소스 플로우 식별자를 포함시키기 위한 수단을 더 포함하는, 통신 시스템.
69. 제 68항에 있어서,
    상기 패킷에서 소스 오브젝트의 데이터를 식별하는 바이트 범위를 상기 패킷에 포함시키기 위한 수단을 더 포함하는, 통신 시스템.
70. 제 68항에 있어서,
    상기 패킷에 소스 플로우 식별자를 포함시키기 위한 수단은 상기 패킷의 TSI(transmission session identifier) 필드에 상기 소스 플로우 식별자를 포함시키기 위한 수단을 포함하는, 통신 시스템.
71. 제 68항에 있어서,
    상기 패킷에 소스 플로우 식별자를 포함시키기 위한 수단은 IP(Internet protocol) 목적지 주소 필드와 UDP(user datagram protocol) 포트 번호 필드의 결합에 상기 소스 플로우 식별자를 포함시키기 위한 수단을 포함하는, 통신 시스템.
72. 제 68항에 있어서,
    상기 패킷에 소스 플로우 식별자를 포함시키기 위한 수단은 데이터 패킷의 CP(codepoint) 필드에 상기 소스 플로우 식별자를 포함시키기 위한 수단을 포함하는, 통신 시스템.
73. 제 68항에 있어서,
    상기 관련된 소스 오브젝트들의 컬렉션을 전송하기 위한 수단은 관련된 소스 오브젝트들의 복수의 컬렉션들을 전송하기 위한 수단을 포함하고 ― 각각의 컬렉션은 복수의 상이한 소스 플로우들 중 하나와 연관되고, 상기 복수의 상이한 소스 플로우들 각각은 고유 소스 플로우 식별자를 포함함 ―; 그리고
    상기 소스 플로우와 연관되는 상기 관련된 소스 오브젝트들의 컬렉션의 적어도 하나의 소스 오브젝트의 데이터를 포함하는 패킷에 상기 소스 플로우 식별자를 포함시키기 위한 수단은 상기 소스 오브젝트의 데이터를 포함하는 패킷에 상기 소스 플로우들의 고유 소스 플로우 식별자를 포함시키기 위한 수단을 포함하는, 통신 시스템.
74. 제 73항에 있어서,
    수신기 디바이스를 더 포함하고,
    상기 관련된 소스 오브젝트들의 컬렉션을 전송하기 위한 수단은 FEC(forward error correction) 복구 데이터, 복구 플로우 식별자 및 복구 오브젝트 식별자를 포함하는 적어도 하나의 패킷을 전송하기 위한 수단을 포함하고,
    상기 통신 시스템은,
    복구 플로우를 상기 복수의 상이한 소스 플로우들 중 하나 이상과 연관시키기 위한 수단;
    상기 복구 플로우를 위한 복구 플로우 식별자를 결정하기 위한 수단; 및
    상기 복구 플로우를 위한 복구 오브젝트 식별자의 컬렉션을 결정하기 위한 수단을 더 포함하고,
    상기 수신기 디바이스는 패킷의 복구 플로우 식별자와 복구 오브젝트 식별자의 결합에 적어도 부분적으로 기초하여, 연관된 복수의 소스 플로우들로부터의 소스 오브젝트들 중 어느 것으로부터, 상기 패킷에 포함된 상기 FEC 복구 데이터가 생성되는지를 결정하기 위한 수단을 포함하는, 통신 시스템.
75. 제 74항에 있어서,
    상기 복구 플로우 식별자를 TSI(transmission session identifier) 필드에 포함시키기 위한 수단을 더 포함하는, 통신 시스템.
76. 제 74항에 있어서,
    상기 복구 플로우 식별자를 IP(Internet protocol) 목적지 주소 필드와 UDP(user datagram protocol) 포트 번호 필드의 결합에 포함시키기 위한 수단을 더 포함하는, 통신 시스템.
77. 제 74항에 있어서,
    상기 복구 플로우 식별자를 CP(codepoint) 필드에 포함시키기 위한 수단을 더 포함하는, 통신 시스템.
78. 제 74항에 있어서,
    상기 복구 오브젝트 식별자를 TOI(transmission object identifier)에 포함시키기 위한 수단을 더 포함하는, 통신 시스템.
79. 제 74항에 있어서,
    상기 복구 오브젝트 식별자를 OSN(object sequence number)에 포함시키기 위한 수단을 더 포함하는, 통신 시스템.
80. 제 74항에 있어서,
    상기 FEC 복구 데이터를 포함하는 적어도 하나의 패킷을 전송하기 위한 수단은 동일한 시간 인터벌 내에 FEC 복구 데이터를 포함하는 적어도 하나의 패킷을 상응하는 소스 오브젝트에 대한 데이터를 포함하는 패킷으로서 전송하기 위한 수단을 포함하는, 통신 시스템.
81. 제 74항에 있어서,
    동일한 복구 플로우 식별자 및 동일한 복구 오브젝트 식별자를 갖는 패킷들로부터 그리고 2개의 소스 오브젝트들의 총 크기보다 크거나 그와 동일한 상기 2개의 소스 오브젝트들 중 어느 하나에 대한 데이터를 포함하는 패킷들로부터 결합하여 수신되는 데이터의 양이 상기 2개의 소스 오브젝트들을 디코딩하기에 충분하도록 하기 위해, 상이한 소스 플로우들에서 상기 2개의 소스 오브젝트들로부터의 상기 동일한 복구 플로우 식별자 및 상기 동일한 복구 오브젝트 식별자를 갖는 패킷들에 대한 FEC 복구 데이터를 생성하기 위한 수단을 더 포함하는, 통신 시스템.
82. 제 74항에 있어서,
    상기 복구 플로우 식별자의 부분들을 FEC 복구 데이터를 포함하는 패킷의 상이한 데이터 필드들에 포함시키기 위한 수단을 더 포함하는, 통신 시스템.
83. 제 74항에 있어서,
    복구 플로우 선언(repair flow declaration)이 FEC 복구 데이터를 포함하는 패킷의 복구 오브젝트 식별자와 소스 플로우들과 연관되는 관련된 소스 오브젝트들의 컬렉션으로부터의 소스 오브젝트들 간의 관계를 시그널링하기에 적절한 정보를 포함하도록, 상기 복구 플로우 선언을 결정하기 위한 수단을 더 포함하고,
    상기 소스 플로우들로부터 상기 패킷의 FEC 복구 데이터가 생성되는, 통신 시스템.
84. 제 83항에 있어서,
    상기 복구 플로우 선언을 통해서 상기 관계를 시그널링하기 위해 템플릿(template)을 사용하기 위한 수단을 더 포함하는, 통신 시스템.
85. 제 83항에 있어서,
    상기 복구 플로우와 연관되는 상기 소스 플로우와 연관된 적어도 하나의 소스 오브젝트보다 앞서 상기 복구 플로우 선언의 부분을 상기 수신기 디바이스에 전송하기 위한 수단을 더 포함하는, 통신 시스템.
86. 제 68항에 있어서,
    상기 관련된 소스 오브젝트들의 컬렉션의 각각의 소스 오브젝트에 대한 소스 오브젝트 식별자를 결정하기 위한 수단; 및
    소스 오브젝트들에 대한 데이터를 포함하는 하나 이상의 패킷들에 상기 소스 오브젝트 식별자를 포함시키기 위한 수단을 더 포함하는, 통신 시스템.
87. 제 86항에 있어서,
    상기 관련된 소스 오브젝트들의 컬렉션의 상응하는 소스 오브젝트를 식별하기 위해 상기 소스 플로우 식별자와 상기 소스 오브젝트 식별자의 결합을 사용하기 위한 수단을 더 포함하는, 통신 시스템.
88. 제 86항에 있어서,
    상기 데이터를 포함하는 패킷에 소스 오브젝트 식별자를 포함시키기 위한 수단은 상기 소스 플로우 식별자와 상기 소스 오브젝트 식별자의 결합이 상응하는 소스 오브젝트를 식별하도록 하기 위해 상기 패킷에 상기 소스 오브젝트 식별자를 포함시키기 위한 수단을 포함하고,
    상기 패킷은 상기 상응하는 소스 오브젝트에 대한 데이터를 전달하는, 통신 시스템.
89. 제 86항에 있어서,
    TOI(transmission object identifier)를 상기 소스 오브젝트 식별자로서 설정하기 위한 수단을 더 포함하는, 통신 시스템.
90. 제 86항에 있어서,
    OSN(object sequence number)를 상기 소스 오브젝트 식별자로서 설정하기 위한 수단을 더 포함하는, 통신 시스템.
91. 제 86항에 있어서,
    소스 오브젝트들이 서로에 대한 그들의 관계에 기초하여 상기 수신기 디바이스에 의해 수신되어 복원될 수 있도록, 상기 소스 플로우와 연관되는 상기 관련된 소스 오브젝트들의 컬렉션에 대한 FEC(forward error correction) 복구 데이터를 상기 브로드캐스트 네트워크를 통해 전송하기 위한 수단을 더 포함하고,
    상기 소스 플로우와 연관되는 상기 관련된 소스 오브젝트들 중 하나 이상에 대한 FEC 복구 데이터를 포함하는 각각의 패킷은 상기 소스 플로우를 식별하는 상기 소스 플로우 식별자를 포함하고 ― 상기 패킷이 상기 소스 플로우에 대한 FEC 복구 데이터를 포함함 ―,
    상기 소스 플로우와 연관되는 상기 관련된 소스 오브젝트들 중 하나 이상에 대한 FEC 복구 데이터를 포함하는 각각의 패킷은 하나 이상의 소스 오브젝트들의 하나 이상의 소스 오브젝트 식별자들을 전달하며 ― 상기 패킷에서 전달되는 FEC 복구 데이터가 상기 하나 이상의 소스 오브젝트들로부터 생성됨 ―, 그리고
    상기 소스 플로우 식별자와 하나 이상의 소스 오브젝트 식별자들의 결합은 상기 소스 플로우와 연관되는 관련된 소스 오브젝트들의 컬렉션으로부터 하나 이상의 소스 오브젝트들을 식별하는 ― 상기 패킷에서 전달되는 FEC 복구 데이터가 상기 소스 플로우로부터 생성됨 ―, 통신 시스템.
92. 제 91항에 있어서,
    동일한 시간 인터벌 내에 하나 이상의 소스 오브젝트들로부터 생성되는 FEC 복구 데이터를 전달하는 패킷들을 상기 하나 이상의 소스 오브젝트들에 대한 데이터를 전달하는 패킷들로서 전송하기 위한 수단을 더 포함하는, 통신 시스템.
93. 제 67항에 있어서,
    상기 소스 플로우와 연관되는 상기 관련된 소스 오브젝트들의 컬렉션의 소스 오브젝트들을 상기 브로드캐스트 네트워크를 통해 전송하기 위한 수단은 상기 소스 오브젝트들을 그들의 상응하는 복구 오브젝트들과는 관계없이 전송하기 위한 수단을 포함하는, 통신 시스템.
94. 제 93항에 있어서,
    소스 오브젝트를 그의 상응하는 복구 오브젝트로부터 구별하기 위해 SDP(session description protocol) 정보를 사용하기 위한 수단을 더 포함하는, 통신 시스템.
95. 제 67항에 있어서,
    상기 관련된 소스 오브젝트들의 컬렉션의 적어도 하나의 소스 오브젝트에 파일의 바이트 범위를 포함시키기 위한 수단을 더 포함하는, 통신 시스템.
96. 제 95항에 있어서,
    URL(uniform resource locator)을 상기 파일과 연관시키기 위한 수단을 더 포함하고,
    상기 통신 시스템은 상기 URL 및 상기 바이트 범위를 통해 상기 적어도 하나의 소스 오브젝트를 식별하기 위한 수단을 더 포함하는, 통신 시스템.
97. 제 67항에 있어서,
    상기 관련된 소스 오브젝트들의 컬렉션의 적어도 하나의 소스 오브젝트에 파일을 포함시키기 위한 수단을 더 포함하는, 통신 시스템.
98. 제 97항에 있어서,
    URL(uniform resource locator)을 상기 파일과 연관시키기 위한 수단을 더 포함하고,
    상기 통신 시스템은 상기 URL을 통해 상기 적어도 하나의 소스 오브젝트를 식별하기 위한 수단을 더 포함하는, 통신 시스템.
99. 제 67항에 있어서,
    상기 관련된 소스 오브젝트들의 컬렉션의 적어도 하나의 소스 오브젝트에 HTTP(hypertext transfer protocol) 헤더 및 파일의 바이트 범위를 포함시키기 위한 수단을 더 포함하는, 통신 시스템.
100. 제 99항에 있어서,
     상기 소스 오브젝트들 중 적어도 일부에 HTTP 헤더, 연관된 파일, 및 HTTP 테일러를 포함시키기 위한 수단을 더 포함하는, 통신 시스템.
101. 제 67항에 있어서,
     상기 소스 플로우와 연관되는 소스 오브젝트들의 컬렉션에 대한 소스 플로우 선언이 위치, 이름, 이용가능 시간, 또는 상기 소스 플로우와 연관된 소스 오브젝트들의 컬렉션에 대한 다른 메타 데이터 간의 관계들을 시그널링하기에 적절한 정보를 포함하도록, 상기 소스 플로우 선언을 결정하기 위한 수단을 더 포함하는, 통신 시스템.
102. 제 67항에 있어서,
     상기 관련된 소스 오브젝트들의 컬렉션을 전송하기 위한 수단은 상기 관련된 소스 오브젝트들의 컬렉션을 MBMS(multimedia broadcast multicast services)를 통해 전송하기 위한 수단을 포함하는, 통신 시스템.
103. 제 67항에 있어서,
     상기 관련된 소스 오브젝트들의 컬렉션을 전송하기 위한 수단은 상기 관련된 소스 오브젝트들의 컬렉션을 FLUTE(file delivery over unidirectional transport)를 통해 전송하기 위한 수단을 포함하는, 통신 시스템.
104. 제 67항에 있어서,
     상기 관련된 소스 오브젝트들의 컬렉션을 전송하기 위한 수단은 FEC(forward error correction) 시그널링 정보는 전송하지 않고 상기 소스 오브젝트들을 전송하기 위한 수단을 포함하는, 통신 시스템.
105. 제 67항에 있어서,
     상기 소스 오브젝트들 적어도 일부에 HTTP(hypertext transfer protocol) 헤더 및 파일의 바이트 범위를 포함시키기 위한 수단을 더 포함하는, 통신 시스템.
106. 통신 시스템으로서,
     전체 파일의 부분들을 수신하기 위한 수단;
     상기 전체 파일을 수신하기 이전에 수신된 부분들에 기초하여 소스 오브젝트들을 생성하기 위한 수단; 및
     상기 전체 파일을 수신하기 이전에 수신기 디바이스에 생성된 소스 오브젝트들을 전송하기 위한 수단을 포함하는, 통신 시스템.
107. 제 106항에 있어서,
     상기 전체 파일을 수신하기 이전에 수신기 디바이스에 생성된 소스 오브젝트들을 전송하기 위한 수단은 상기 전체 파일의 데이터 순서와는 상이한 순서로 상기 생성된 소스 오브젝트들에 대한 데이터를 전송하기 위한 수단을 포함하는, 통신 시스템.
108. 제 107항에 있어서,
     상기 전체 파일의 부분들을 수신하기 위한 수단은 파일의 처음에 파일 크기를 포함하는 상기 파일의 부분들을 수신하기 위한 수단을 포함하고,
     상기 전체 파일을 수신하기 이전에 수신기 디바이스에 생성된 소스 오브젝트들을 전송하기 위한 수단은 상기 파일 크기 이후의 상기 파일의 적어도 일부 데이터가 상기 파일 크기보다 먼저 전송되도록 하는 순서로 소스 오브젝트의 데이터를 전송하기 위한 수단을 포함하는, 통신 시스템.
109. 제 106항에 있어서,
     소스 오브젝트에 HTTP(Hypertext Transfer Protocol) 헤더 및 연관된 파일을 포함시키기 위한 수단을 더 포함하는, 통신 시스템.
110. 제 106항에 있어서,
     소스 오브젝트에 HTTP(Hypertext Transfer Protocol) 헤더, 연관된 파일 및 HTTP 테일러를 포함시키기 위한 수단을 더 포함하는, 통신 시스템.
111. 제 106항에 있어서,
     소스 플로우와 연관된 소스 오브젝트들의 컬렉션에 대한 소스 플로우 선언이 위치, 이름, 이용가능 시간, 또는 상기 소스 플로우와 연관되는 소스 오브젝트들의 컬렉션에 대한 다른 메타데이터 간의 관계들을 시그널링하도록, 상기 소스 플로어 선언을 결정하기 위한 수단을 더 포함하는, 통신 시스템.
112. 제 111항에 있어서,
     상기 소스 플로우 선언에서 관계 정보를 시그널링하기 위해 템플릿을 사용하기 위한 수단을 더 포함하는, 통신 시스템.
113. 제 111항에 있어서,
     상기 소스 플로우와 연관되는 적어도 하나의 관련된 소스 오브젝트에 앞서 상기 소스 플로우에 대한 소스 플로우 선언의 부분들을 상기 수신기 디바이스에 전송하기 위한 수단을 더 포함하는, 통신 시스템.
114. 제 113항에 있어서,
     상기 소스 플로우와 연관되는 적어도 하나의 관련된 소스 오브젝트에 앞서 상기 소스 플로우에 대한 소스 플로우 선언의 부분들을 상기 수신기 디바이스에 전송하기 위한 수단은,
     타이밍 정보;
     URI(uniform resource identifier); 및
     소스 오브젝트들에 대한 암호해독 키들을 식별하는 정보
     중 적어도 하나를 포함하는 부분을 전송하기 위한 수단을 포함하는, 통신 시스템.
115. 제 113항에 있어서,
     상기 소스 플로우와 연관되는 적어도 하나의 관련된 소스 오브젝트에 앞서 상기 소스 플로우에 대한 소스 플로우 선언의 부분들을 상기 수신기 디바이스에 전송하기 위한 수단은,
     상기 소스 플로우와 연관되는 소스 오브젝트들 중 적어도 하나를 전송하기에 앞서 상기 소스 플로우 선언의 부분을 상기 수신기 디바이스에 대역외에서 송신하기 위한 수단; 및
     소스 오브젝트와 함께 상기 소스 플로우 선언의 다른 부분을 대역내에서 송신하기 위한 수단을 포함하는, 통신 시스템.
116. 제 115항에 있어서,
     상기 소스 오브젝트와 함께 상기 소스 플로우 선언의 다른 부분을 대역내에서 송신하기 위한 수단은 상기 소스 오브젝트에 대한 데이터의 마지막 부분의 표시를 송신하기 위한 수단을 포함하는, 통신 시스템.
117. 제 113항에 있어서,
     상기 소스 플로우 선언의 부분들을 상기 수신기 디바이스에 제공하기 위한 수단은 파일 전달 테이블을 송신하지 않고 단방향 전송 프로토콜을 통해 상기 소스 플로우 선언의 부분들을 송신하기 위한 수단을 포함하는, 통신 시스템.
118. 제 106항에 있어서,
     상기 전체 파일을 수신하기 이전에 수신기 디바이스에 생성된 소스 오브젝트들을 전송하기 위한 수단은 MBMS(multimedia broadcast multicast services)를 통해 관련된 소스 오브젝트들의 컬렉션을 전송하기 위한 수단을 포함하는, 통신 시스템.
119. 제 106항에 있어서,
     상기 전체 파일을 수신하기 이전에 수신기 디바이스에 생성된 소스 오브젝트들을 전송하기 위한 수단은 FLUTE(file delivery over unidirectional transport)를 통해 관련된 소스 오브젝트들의 컬렉션을 전송하기 위한 수단을 포함하는, 통신 시스템.
120. 제 106항에 있어서,
     관련된 소스 오브젝트들의 컬렉션을 전송하기 위한 수단은 소스 오브젝트들을 그들의 상응하는 복구 오브젝트들에 관계없이 전송하기 위한 수단을 포함하는, 통신 시스템.
121. 제 106항에 있어서,
     소스 오브젝트를 그의 상응하는 복구 오브젝트로부터 구별하기 위해 SDP(session description protocol) 정보를 사용하기 위한 수단을 더 포함하는, 통신 시스템.
122. 제 106항에 있어서,
     상기 전체 파일을 수신하기 이전에 수신기 디바이스에 생성된 소스 오브젝트들을 전송하기 위한 수단은 FEC(forward error correction) 시그널링 정보를 전송하지 않고 상기 소스 오브젝트들을 전송하기 위한 수단을 포함하는, 통신 시스템.
123. 제 106항에 있어서,
     개별 소스 오브젝트의 부분들을 보호하기 위해 FEC(forward error correction) 동작들을 수행하기 위한 수단을 더 포함하는, 통신 시스템.
124. 제 123항에 있어서,
     다수의 FEC 인코딩들을 통해 상기 개별 소스 오브젝트를 전송하기 위한 수단을 더 포함하는, 통신 시스템.
125. 제 123항에 있어서,
     소스 오브젝트의 보호되는 부분에 대한 TOI(transmission object identifier) 또는 OSN(object sequence number)을 복구 패킷 헤더에 추가하기 위한 수단; 및
     상기 보호되는 부분의 바이트 범위를 그의 전송 소스 블록의 마지막에 추가하기 위한 수단을 더 포함하는, 통신 시스템.
126. 제 123항에 있어서,
     보호될 소스 오브젝트의 부분의 처음에 소스 심볼들을 추가하기 위한 수단; 및
     보호되는 부분의 바이트 범위를 복구 패킷 헤더에 추가하기 위한 수단을 더 포함하는, 통신 시스템.
127. 제 123항에 있어서,
     소스 오브젝트의 보호되는 부분의 바이트 범위의 시작 포지션 및 상기 바이트 범위에 의해 커버되는 다수의 심볼들을 복구 패킷 헤더 내에 추가하기 위한 수단; 및
     바이트들 또는 옥텟들의 상기 보호되는 부분의 크기를 전송 소스 블록의 마지막에 추가하기 위한 수단을 더 포함하는, 통신 시스템.
128. 제 106항에 있어서,
     상기 전체 파일을 수신하기 이전에 수신기 디바이스에 생성된 소스 오브젝트들을 전송하기 위한 수단은 소스 오브젝트가 규칙적으로 전달되는 HTTP(hypertext transfer protocol) 자원으로서 상기 수신기 디바이스에서 사용하기에 적절하도록 하기 위해서 상기 소스 오브젝트를 HTTP 엔티티 헤더와 HTTP 엔티티 보디의 결합으로서 상기 수신기 디바이스에 단방향 프로토콜을 통해 전달하기 위한 수단을 포함하는, 통신 시스템.
129. 통신 시스템으로서,
     전송기; 및
     상기 전송기에 커플링되고, 동작들을 수행하기 위해 프로세서-실행가능 명령들을 갖도록 구성되는 컴퓨팅 디바이스를 포함하고,
     상기 동작들은,
     관련된 소스 오브젝트들의 컬렉션을 소스 플로우와 연관시키는 동작; 및
     소스 오브젝트들이 서로에 대한 그들의 관계에 기초하여 수신기 디바이스에 의해 수신되어 복원될 수 있도록, 상기 소스 플로우와 연관되는 상기 관련된 소스 오브젝트들의 컬렉션의 소스 오브젝트들을 브로드캐스트 네트워크를 통해 전송하는 동작을 포함하는, 통신 시스템.
130. 통신 시스템으로서,
     전송기; 및
     상기 전송기에 커플링되고, 동작들을 수행하기 위해 프로세서-실행가능 명령들을 갖도록 구성되는 컴퓨팅 디바이스를 포함하고,
     상기 동작들은,
     전체 파일의 부분들을 수신하는 동작;
     상기 전체 파일을 수신하기 이전에 수신된 부분들에 기초하여 소스 오브젝트들을 생성하는 동작; 및
     상기 전체 파일을 수신하기 이전에 수신기 디바이스에 생성된 소스 오브젝트들을 전송하는 동작을 포함하는, 통신 시스템.
131. 통신 시스템 내의 컴퓨팅 디바이스로 하여금 브로드캐스트 네트워크를 통해 정보를 통신하기 위한 동작들을 수행하게 하도록 구성된 프로세서-실행가능 소프트웨어 명령들이 저장된 비-일시적 컴퓨터-판독가능 저장 매체로서,
     상기 동작들은,
     관련된 소스 오브젝트들의 컬렉션을 소스 플로우와 연관시키는 동작; 및
     소스 오브젝트들이 서로에 대한 그들의 관계에 기초하여 수신기 디바이스에 의해 수신되어 복원될 수 있도록, 상기 소스 플로우와 연관되는 상기 관련된 소스 오브젝트들의 컬렉션의 소스 오브젝트들을 상기 브로드캐스트 네트워크를 통해 전송하는 동작을 포함하는, 비-일시적 컴퓨터-판독가능 저장 매체
132. 통신 시스템 내의 컴퓨팅 디바이스로 하여금 브로드캐스트 네트워크를 통해 하나 이상의 소스 오브젝트들을 전송하기 위한 동작들을 수행하게 하도록 구성된 프로세서-실행가능 소프트웨어 명령들이 저장된 비-일시적 컴퓨터-판독가능 저장 매체로서,
     상기 동작들은,
     전체 파일의 부분들을 수신하는 동작;
     상기 전체 파일을 수신하기 이전에 수신된 부분들에 기초하여 소스 오브젝트들을 생성하는 동작; 및
     상기 전체 파일을 수신하기 이전에 수신기 디바이스에 생성된 소스 오브젝트들을 전송하는 동작을 포함하는, 비-일시적 컴퓨터-판독가능 저장 매체.

Images