KR20150107842A - 다중 경로 스트리밍을 위한 fec-기반 신뢰 가능 전송 제어 프로토콜들 - Google Patents

Abstract

클라이언트 디바이스는, 순방향-에러 정정된 데이터를 서버 디바이스로부터 복수의 병렬 네트워크 경로들을 통해 수신하고, 네트워크 경로들 각각을 통한 데이터의 손실들을 결정하고, 네트워크 경로들 각각을 통한 데이터의 손실들을 표현하는 데이터를 서버 디바이스에 전송하도록 구성되는 하나 이상의 프로세서들을 포함한다. 추가적으로 또는 대안적으로, 클라이언트 디바이스는, 제 1 블록에 대한 인코딩 유닛들의 제 1 세트를 수신하고 ―인코딩 유닛들의 제 1 세트는 제 1 블록을 복원하기 위해 요구되는 인코딩 유닛들의 최소수보다 적은 인코딩 유닛들을 포함함―, 인코딩 유닛들의 제 1 세트를 수신한 후, 제 2 블록에 대한 인코딩 유닛들의 제 2 세트를 수신하고, 인코딩 유닛들의 제 2 세트를 수신한 후, 제 1 블록에 대한 하나 이상의 인코딩 유닛들을 포함하는 인코딩 유닛들의 제 3 세트를 수신하도록 구성되는 하나 이상의 프로세서들을 포함한다.

Description

다중 경로 스트리밍을 위한 FEC-기반 신뢰 가능 전송 제어 프로토콜들{FEC-BASED RELIABLE TRANSPORT CONTROL PROTOCOLS FOR MULTIPATH STREAMING}

[0001] 본 출원은 2013년 1월 17일 출원된 미국 예비 출원 일련 번호 61/753,884, 및 2013년 5월 1일 출원된 미국 예비 출원 일련 번호 61/818,106의 우선권을 주장하고, 각각의 예비 출원의 전체 내용들은 이로써 인용에 의해 포함된다.

[0002] 본 개시는 미디어 데이터의 전송에 관한 것이다.

[0003] 디바이스들은 다중 경로들 및 낮은-레이턴시(latency) 핸들링을 사용하는 데이터 통신 네트워크를 통해 종단 시스템들 사이에서 데이터의 빠른 송신을 수행할 수 있다. 많은 데이터 통신 시스템들 및 높은 레벨 데이터 통신 프로토콜들은 신뢰 가능 데이터 전송의 편리한 통신 개념들을 제공하고, 레이트 제어를 제공하는데, 즉 네트워크 조건들에 기초하여 자신의 패킷 송신 레이트를 자동으로 조절한다. 보편적인 전송 제어 프로토콜(TCP: Transport Control Protocol) 같은 보다 낮은 레벨 패킷화된 데이터 전송들의 측면에서 그들의 종래 근본적인 구현들은, 다음 조건들 중 적어도 하나, 즉 (a) 전송기(들)와 수신기(들) 사이의 연결이 큰 왕복 시간(RTT: round-trip time)을 가지며; (b) 데이터의 양이 크고 네트워크가 버스티(bursty) 손실 및 일시적 손실로 고통을 받는 것이 발생할 때, 고통을 받는다.

[0004] 하나의 널리 사용된 신뢰 가능 전송 프로토콜은 전송 제어 프로토콜(TCP)이다. TCP는 확인응답 메커니즘을 가진 상용의 포인트 투 포인트 패킷 제어 방식이다. TCP는, 전송기와 수신부 사이에서 손실이 작고 전송기와 수신부 사이의 RTT가 작을 때 일 대 일 신뢰 가능 통신들에 대해 잘 작동한다. 그러나, TCP의 처리량은 심지어 매우 작은 손실이 있을 때, 또는 전송기와 수신부 사이에 임의의 상당한 레이턴시가 있을 때 크게 떨어진다.

[0005] TCP를 사용하여, 전송기는 순서화된 패킷들을 전송하고 수신부는 각각의 패킷의 수신을 확인응답한다. 만약 패킷이 손실되면, 어떠한 확인응답도 전송기에 전송되지 않을 것이고 추후 수신된 패킷들 또는 타임아웃 중 어느 하나의 수신에 기초하여 전송기는 패킷을 재전송할 것이다. TCP 같은 프로토콜들에 의해, 확인응답 패러다임은 패킷들이 완전한 실패 없이 손실되게 하는데, 그 이유는 손실 패킷들이 확인응답의 결여에 응답하여 또는 수신부로부터의 명시적 요청에 응답하여, 단지 재송신될 수 있기 때문이다.

[0006] TCP는 신뢰도 제어 및 레이트 제어 둘 다를 제공한다. 즉, TCP를 구현하는 디바이스들은, 본래 데이터 모두가 수신기들에 전달되고 혼잡 및 패킷 손실 같은 네트워크 조건들에 기초하여 패킷 송신 레이트를 자동으로 조절하는 것을 보장한다. TCP에 의해, 신뢰도 제어 프로토콜 및 레이트 제어 프로토콜은 얽혀지고 분리 가능하지 않다. 게다가, 증가하는 RTT 및 패킷 손실의 함수로서 TCP의 처리량 성능은 최적과는 거리가 멀다.

[0007] 일반적으로, 본 개시는 복수의 병렬 네트워크 경로들을 통해 전송된 데이터에 적용된 순방향 오류 정정(FEC: forward-error correction)에 관련된 기술들을 설명한다. 일 실시예에서, 데이터는 전송될 데이터를 데이터 블록들로 구성함으로써 전송기로부터 수신기로 신뢰 가능하게 전송될 수 있고, 각각의 데이터 블록은 복수의 인코딩 유닛들을 포함한다. 제 1 데이터 블록의 인코딩 유닛들은 다중 경로들을 통해 전송기로부터 수신기로 송신될 수 있고, 즉 제 1 데이터 블록의 몇몇 인코딩 유닛들은 하나의 경로를 통해 전송되는 반면 제 1 데이터 블록의 다른 인코딩 유닛들은 제 2 경로를 통해 전송되고, 등등이다. 전송기는 수신기에 의해 인코딩 유닛들의 수신의 확인응답들을 검출할 수 있다. 전송기에서, 수신기가 수신기에서 제 1 데이터 블록을 복원하기 위하여 제 1 데이터 블록에 대한 이미 전송된 인코딩 유닛들로부터 제 1 데이터 블록의 충분한 인코딩 유닛들을 수신할 확률은 검출될 수 있고 확률은 미리 결정된 테스트가 충족되는지를 결정하기 위하여 임계 확률에 대해 테스트될 수 있다. 테스팅 단계 다음 및 수신기에서 제 1 데이터 블록의 복원의 확인을 전송기가 수신하기 이전, 미리 결정된 테스트가 충족될 때, 전송기는 다중 경로들을 통해 전송기로부터 제 2 데이터 블록의 인코딩 유닛들을 전송할 수 있다. 몇몇 예들에서, 전송기는 수신기가 제 1 블록을 복원하기 위하여 제 1 블록에 대해 충분한 수의 인코딩 유닛들이 전송되기 전에 제 2 블록의 인코딩 유닛들을 전송할 수 있고, 따라서 전송기는 제 2 블록에 대한 적어도 몇몇의 인코딩 유닛들을 전송한 다음 제 1 블록에 대한 부가적인 인코딩 유닛들을 전송할 수 있다. 게다가, 전송기는 블록이 완전히 형성되기 전에 블록의 인코딩 유닛들을 수신기에 전송할 수 있다. 몇몇 예들에서, 미리 결정된 테스트는 임계 확률에 대한 상기 확률의 비교이고 미리 결정된 테스트는, 확률이 임계 확률보다 높을 때 충족되는 것으로 결정될 수 있다.

[0008] 몇몇 예들에서, 전송기는 또한 생성될 때 각각의 블록의 크기 또는 지속 기간을 동적으로 결정하고, 블록들의 데이터가 생성되는 레이트를 결정하고, 그리고 인코딩 유닛들이 다중 경로들의 각각을 통해 수신기로 전송되는 레이트를 결정할 수 있다.

[0009] 일 예에서, 컴퓨터-판독가능 저장 매체는, 실행될 때, 클라이언트 디바이스의 프로세서가, 서버 디바이스로부터 복수의 병렬 네트워크 경로들을 통해 순방향 오류 정정된 데이터를 수신하고, 네트워크 경로들의 각각을 통해 데이터의 손실들을 결정하고, 그리고 네트워크 경로들의 각각을 통해 서버 디바이스로 데이터의 손실들을 표현하는 데이터를 전송하게 하는 명령들이 저장되어 있다.

[0010] 다른 예에서, 컴퓨터-판독가능 저장 매체는, 실행될 때, 서버 디바이스의 프로세서가, 복수의 병렬 네트워크 경로들을 통해 순방향 오류 정정된 데이터를 클라이언트 디바이스에 전송하고, 클라이언트 디바이스로부터 네트워크 경로들의 각각을 통해 전송된 데이터의 손실들을 표현하는 데이터를 수신하고, 그리고 손실들을 표현하는 데이터에 기초하여, 병렬 네트워크 경로들을 통해 추후 데이터 송신들을 위해 전송된 순방향 오류 정정 데이터의 양을 수정하게 하는 명령들이 저장되어 있다.

[0011] 하나 이상의 예들의 상세들은 첨부 도면들 및 하기 설명에 설명된다. 다른 특징들, 목적들, 및 장점들은 설명 및 도면들, 및 청구항들로부터 명백할 것이다.

[0012] 도 1은, 본 개시물의 교시들을 이용할 수 있는 예시적 네트워크, 전송단 시스템들 및 수신단 시스템들의 블록도이다.
[0013] 도 2는, 모듈형 신뢰 가능 전송 프로토콜 아키텍처 및 이러한 프로토콜을 이용하여 동작하는 관련 시스템의 예시이다.
[0014] 도 3은, 전송기 FEC-기반 신뢰도 제어 프로토콜 아키텍처 및 이러한 프로토콜을 이용하여 동작하는 관련 시스템의 예이다.
[0015] 도 4는, 수신기 FEC-기반 신뢰도 제어 프로토콜 아키텍처 및 이러한 프로토콜을 이용하여 동작하는 관련 시스템의 예이다.
[0016] 도 5는, TF 신뢰도 제어 프로토콜을 구현하는 시스템에 의해 사용될 수 있는 하나의 가능한 세트의 포맷들을 도시한다.
[0017] 도 6은, 전송기 TF 신뢰도 제어 프로토콜을 구현하는 시스템의 로직을 예시하는 흐름도이다.
[0018] 도 7은, 수신기 TF 신뢰도 제어 프로토콜을 구현하는 시스템의 로직을 예시하는 흐름도이다.
[0019] 도 8은, 액티브 블록들의 예시이다.
[0020] 도 9는, 인터리빙된(interleaved) 신뢰도 제어 프로토콜에 의해 사용될 수 있는 하나의 가능한 세트의 포맷들의 예시이다.
[0021] 도 10은, 기본 전송기의 인터리빙된 신뢰도 제어 프로토콜을 구현하는 시스템의 로직의 예시적 예이다.
[0022] 도 11은, 기본 수신기의 인터리빙된 신뢰도 제어 프로토콜을 구현하는 시스템의 로직의 예시적 예이다.
[0023] 도 12는, 다중경로 스트리밍 시스템의 블록도이다.
[0024] 도 13은, 다중경로 신뢰도 제어 프로토콜을 구현하는 다중경로 스트리밍 시스템에 의해 사용될 수 있는 하나의 가능한 세트의 데이터 포맷들을 도시한다.
[0025] 도 14는, 다중경로 스트리밍 전송기의 블록도이다.
[0026] 도 15는, 다중경로 스트리밍 수신기의 블록도이다.
[0027] 도 16은, 다중경로 FEC-기반 신뢰도 전송 제어 방법의 동작 동안 상이한 분류들의 소스 블록들의 스냅샷을 도시한다.

[0028] TCP를 사용할 때, 데이터 전송의 쓰루풋(초당 패킷들의 단위)은 RTT(초 단위)의 곱(product), 그리고 단-대-단 접속(end-to-end connection)에 대한 손실 레이트의 제곱근에 반비례한다는 것이 많은 연구원들에 의한 연구들에서 밝혀졌다. 예를 들어, 미국과 유럽 간의 통상적인 단-대-단 지상파(terrestrial) 접속은 200 밀리초의 RTT 및 2%의 평균 패킷 손실을 가지며, IP 패킷들은 통상적으로 크기가 대략 10 Kilobits이다. 이들 조건들 하에서, TCP 접속의 쓰루풋은 최대(at most) 대략 300-400 kbps(Kilobits per second)이며, 얼마나 많은 대역폭이 단-대-단에 이용가능한지는 중요치 않다. 이 상황은 위성 링크에 대해 더욱 심각하며, 여기서는 높은 RTT들 외에도, 다양한 대기 효과들로 인해 정보가 손실된다.

[0029] 또 다른 예로서, 모바일 네트워크들, 3G 또는 LTE 네트워크들에서의 모바일 디바이스들은 큰 RTT들, RTT들에서의 동적 변동(dynamic fluctuation)들, 및 이용가능한 대역폭에서의 동적 변동들을 경험하는 것으로 알려졌다. 모바일 디바이스는, 셀 내 모바일 디바이스의 포지션 변화 또는 커버리지에서의 변동들을 야기할 수 있는 셀 경계들에 걸친 이동, 다른 모바일 디바이스들이 모바일 디바이스에 커버리지를 제공하고 있는 셀로부터 멀리 이동하거나 또는 근접해짐으로 인한 네트워크의 가변 로딩을 비롯한 다양한 원인들 또는 다양한 다른 원인들에 대해 이들을 경험할 수 있다. 이러한 타입들의 조건들에서 TCP의 열악한 성능에 대한 주요 원인은, 예를 들어 이용가능한 대역폭이 짧은 시간 기간들 동안 높다 하더라도, TCP에 의해 사용되는 레이트 제어 프로토콜이 이를 조건들에서 잘 작동하지 않는다는 점이며, TCP 프로토콜은 이용가능한 대역폭이 다시 감소하기 전에 더 높은 이용가능한 대역폭을 이용하도록 자신의 송신 레이트를 증가시키기에 충분히 신속하게 반응(react)할 수 없다.

[0030] TCP에 의해 이용되는 레이트 제어 프로토콜 및 신뢰도 제어 프로토콜은 불가분(inseparable)하기 때문에, 이는 전체 TCP 프로토콜이 이러한 조건들에서 잘 작동하지 않는다는 것을 의미한다. 이러한 TCP의 제한들을 해결하기 위해 시도하는 한가지 방식은, 어그리게이트(aggregate) 단-대-단 쓰루풋을 추가 증가시키기 위해 개별 경로들에 걸쳐 다수의 TCP 접속들을 이용하는 것이다. 추가로, 전송을 위한 상이한 애플리케이션들의 요건들(requirements)은 다양하지만, TCP는 모든 네트워크 조건들에서 다양한 애플리케이션들에 대해 상당히 보편적으로(fairly universally) 이용되어, 많은 상황들에서 성능 악화를 유도한다.

[0031] 예를 들어, 실시간 비디오 스트리밍 애플리케이션의 경우, 비디오는, 모바일 디바이스 상의 필드에 생성될 수 있고, 다수의 TCP 접속들을 통해, 가능하면 상이한 3G 또는 4G/LTE 접속들을 통해, 가능하면 WiFi에 의해 생성 모바일 디바이스에 접속되거나 또는 테더링되는 다수의 모바일 디바이스들을 사용하여, 오리지널 비디오 스트림을 재구성하기 위한 수신 디바이스에 스트리밍될 수 있다. 그러나 이용가능한 대역폭에서의 변동들 및 RTT들에서의 변화들(variations)로 인해, 이 다수의 TCP 접속들은 여전히 이용가능한 대역폭을 충분히 이용하는 것을 실패할 수 있다. 이러한 스트리밍 애플리케이션의 경우, 단-대-단 딜레이 요건들은 실시간 스트리밍 애플리케이션에 대해 상당히 엄중(stringent)해야 하며, 이에 따라, 스트림이 데이터의 블록들의 시퀀스로 구성되는 요건 및 추가의 컴플리케이션(complication)이 있고, 데이터의 각각의 블록에 대한 상이한 TCP 접속들을 통해 전송되는 충분한 인코딩 유닛들이 수신되어 수신 디바이스에서 스트림의 해당 데이터 블록의 재구성을 허용하는 것이 필요하며, 일반적으로 데이터의 블록들은 데이터의 각각의 블록이 전송기에서 (부분적으로 또는 전체적으로) 이용가능해지는 시기와 데이터의 블록이 재구성되고 수신 디바이스에서의 소모(consumption) 또는 플레이백을 위해 이용가능해지는 시기 사이에 가능한 가장 작은 딜레이를 갖는 시퀀스로 수신 디바이스에서 플레이백되거나 소모될 것이다. 이러한 요건들은 가장 느린 TCP 접속에 의해 제약되는 TCP-기반 솔루션의 능력들을 구성할 수 있고, 전체 TCP-기반 솔루션은 상당히 하급(quite inferior)일 수 있다.

[0032] 본 개시물은 독립적으로 사용될 수 있는 개선된 신뢰도 제어 및 레이트 제어 프로토콜들의 설명들을 포함하며, 선택된 실제 레이트 제어 프로토콜이 애플리케이션이 실행되는 네트워크 조건들 및 애플리케이션 요건들에 기초할 수 있게, 동일 신뢰도 제어 프로토콜이 다양한 여러(variety of different) 레이트 제어 프로토콜들에 사용될 수 있다. 논문 "A Modular Analysis of Network Transmission Protocols"(Micah Adler, Yair Bartal, John Byers, Michael Luby, Danny Raz, Proceedings of the Fifth Israeli Symposium on Theory of Computing and Systems, June 1997)(이후 "Adler"로 언급되며 인용에 의해 본원에 포함됨)은, 신뢰 가능 전송 프로토콜을 독립적 신뢰도 제어 및 레이트 제어 프로토콜들로 파티셔닝하는 것을 지지하는 전송 프로토콜들을 구축하는데 모듈형 접근방식을 소개한다.

[0033] 임의의 신뢰도 제어 프로토콜의 경우, 그 성능에 대한 2가지 주요 척도들(measures)은 얼마나 많은 버퍼링이 요구되는지와 그의 "굿풋(goodput)"이다. 버퍼링은 전송기 및 수신기 둘 다에서 신뢰도 제어 프로토콜에 도입된다. 전송기에서의 버퍼링은, 예를 들어, 데이터가 초기에 전송된 이후 데이터가 수신기에서 수신되었다는 확인응답을 전송기가 갖을 때까지, 데이터가 버퍼링될 때 발생한다. 수신기에서의 버퍼링은 유사한 원인들로 발생한다. 버퍼링은 2가지 이유로 중요하다: (1) 버퍼링은 전송기 및 수신기 신뢰도 제어 프로토콜이 얼마나 많은 메모리를 사용하는지에 직접적인 영향을 미친다: (2) 버퍼링은 전송기 및 수신기 신뢰도 제어 프로토콜이 얼마나 많은 레이턴시를 도입하는지에 직접적인 영향을 미친다. 굿풋은, 전송될 데이터의 크기를, 전송 동안 수신단 시스템에서 수신되는, 전송된 데이터의 양으로 나눈 것으로 정의된다. 예를 들면, 오리지널 데이터를 전송하는 패킷들에서 전송된 데이터의 양이 오리지널 데이터의 크기인 경우, 굿풋=1.0이며, 어떠한 잔여 데이터도 전혀 송신되지 않은 경우 굿풋=1.0이 달성될 수 있다.

[0034] Adler는 사용되는 레이트 제어 프로토콜과는 대부분 관련이 없는 신뢰도 제어 프로토콜을 개설하였고, 이는 이하에서 “노-코드 신뢰도 제어 프로토콜”로 지칭된다. 오리지널 데이터가 블록들로 분할되고 각 블록이 패킷의 페이로드에서 전송되며, 따라서 각 블록의 정확한 사본이 신뢰 가능한 전달을 보장하기 위해 수신될 필요가 있다는 점에서, 노-코드 신뢰도 제어 프로토콜은 어떤 면에서는 TCP에 임베딩된 신뢰도 제어 프로토콜과 유사하다. 노-코드 신뢰도 제어 프로토콜에 있어서의 이슈는, 굿풋이 최적(필수적으로 1과 같음)이더라고, 노-코드 신뢰도 제어 프로토콜이 유발하는 버퍼링이, 패킷 손실이 존재할 때 상당할 수 있다는 것이다. 아들러는, 프로토콜이 최적의 굿풋을 가지며, 증명가능하게, 전송기 및 수신기에서 요구되는 버퍼링의 양을 최소화하는 점에서 최적의 일정한 팩터 내에 있다는 점에서, 노-코드 신뢰도 제어 프로토콜이 데이터를 전달하기 위해 코딩을 사용하지 않는 신뢰도 제어 프로토콜들 중에서 최적의 일정한 팩터 내에 있다는 것을 증명하였다.

[0035] 신뢰도 제어 프로토콜들에서 사용되었던 일 기술은 순방향 에러 정정(FEC) 코드들, 이를테면, 리드-솔로몬 코드들 또는 토네이도 코드들, 또는 연쇄 반응 코드들(이들은 정보 부가 코드들임)이다. FEC 코드들을 사용하여, 오리지널 데이터는 패킷의 페이로드보다 큰 블록들로 분할되고, 그 후 인코딩 유닛들이 이 블록들로부터 생성되고 패킷들로 인코딩 유닛들을 전송한다. 코딩을 사용하지 않는 신뢰도 제어 프로토콜에 비해 이러한 방식의 기본적인 일 장점은, 피드백이 훨씬 더 간편하고 덜 빈번할 수 있다는 것인데, 즉 각 블록에 대해 수신기는 정확하게 어느 인코딩 유닛들이 수신되는지의 리스트 대신에 수신된 인코딩 유닛들의 양을 전송기에 표시하기만 하면 된다. 더욱이, 오리지널 데이터 블록의 길이보다 더 많은 인코딩 유닛들을 전체적으로 생성하여 전송하는 능력은 신뢰도 제어 프로토콜들의 설계에서 강력한 수단이다.

[0036] 소거 정정 코드들, 이를테면, 리드-솔로몬 또는 토네이도 코드들은 고정된 길이 블록에 대해 고정된 수의 인코딩 유닛들을 생성한다. 예를 들어, B개의 입력 유닛들을 포함하는 블록의 경우, N개의 인코딩 유닛들이 생성될 수 있다. 이러한 N개의 인코딩 유닛들은 B개의 오리지널 입력 유닛들 및 N-B개의 리던던트 유닛들을 포함할 수 있다. 저장소가 허용된다면, 전송기는 각 블록에 대해 오직 한번만 인코딩 유닛들의 세트를 컴퓨팅하고 캐루젤(carousel) 프로토콜을 이용하여 인코딩 유닛들을 전송할 수 있다.

[0037] 일부 FEC 코드들에 있어서 하나의 문제는 이들이 연산을 위해 과도한 컴퓨팅 파워 또는 메모리를 필요로 한다는 것이다. 다른 문제는 필요한 인코딩 유닛들의 수가 코딩 프로세스에 앞서 결정되어야 한다는 것이다. 이는 패킷들의 손실 레이트가 과대평가되면 비효율성을 초래할 수 있고, 패킷들의 손실 레이트가 과소평가되면 실패를 초래할 수 있다.

[0038] 전통적인 FEC 코드들의 경우, 생성될 수 있는 가능한 인코딩 유닛들의 수는, 블록이 분할되는 입력 유닛들의 수와 동일한 규모이다. 전형적으로, 그러나 배타적이지 않게, 이러한 인코딩 유닛들의 대부분 또는 전부는 전송 단계 이전의 사전 프로세싱 단계에서 생성된다. 이러한 인코딩 유닛들은, 모든 입력 유닛들이 오리지널 블록과 길이가 동일한 또는 오리지널 블록보다 길이가 조금 더 긴 인코딩 유닛들의 임의의 서브세트로부터 재생성될 수 있다는 특성을 갖는다.

[0039] (이하에서 “Luby I”로 지칭되고 본 명세서에 참조로 통합되는) 미국 특허 제 6,307,487호에 설명된 연쇄 반응 디코딩은 전술한 이슈들을 해결하는 순방향 에러 정정의 형태를 제공할 수 있다. 연쇄 반응 코드들의 경우, 생성될 수 있는 가능한 인코딩 유닛들의 풀은 입력 유닛들의 수보다 큰 규모이며, 가능성들의 풀로부터 랜덤하게 또는 의사 랜덤하게 선택된 인코딩 유닛이 매우 신속하게 생성될 수 있다. 연쇄 반응 코드들의 경우, 인코딩 유닛들은 전송 단계와 동시에, 필요에 따라 그때 그때 생성될 수 있다. 연쇄 반응 코드들은 컨텐츠의 모든 입력 유닛들이 오리지널 컨텐츠보다 길이가 약간 더 긴, 랜덤하게 또는 의사 랜덤하개 생성된 인코딩 유닛들의 세트의 서브세트로부터 재생성될 수 있는 것을 허용한다.

[0040] 다른 문서들, 이를테면 미국 특허 번호 제 6,320,520호 제 6,373,406호, 제 6,614,366호, 제 6,411,223호, 제 6,486,803호 및 미국 특허 공개 번호 제 2003/0058958호 (이하에서 “Shokrollahi I”로 지칭됨)은 다양한 연쇄 반응 코딩 방식들을 설명하며 본 명세서에 참조로 통합된다.

[0041] 연쇄 반응 코드들을 사용하는 전송기는 각 블록이 송신되는 동안 인코딩 유닛들을 연속적으로 생성할 수 있다. 인코딩 유닛들은 UDP(User Datagram Protocol) 유니캐스트를 통해 또는 적용가능한 경우 UDP 멀티캐스트를 통해 수취인들에게 전송될 수 있다. 각 수취인은 디코딩 유닛을 갖춘 것으로 가정되며, 이 디코딩 유닛은 원래의 블록들을 획득하기 위해 패킷들로 수신된 적절한 수의 인코딩 유닛들을 디코딩한다.

[0042] 이하에서 "TF 신뢰도 제어 프로토콜"로 지칭되는, 현재의 단순 FEC 기반 신뢰도 제어 프로토콜은, 블록을 복원할 정도로 충분한 인코딩 유닛들이 수신되었다는 수신기로부터의 확인 응답을 수신할 때까지 주어진 데이터의 블록에 대한 인코딩 유닛들을 전송하며, 그 후, 전송기는 다음 블록으로 이동한다.

[0043] 전송기가 패킷을 전송했을 때부터 전송기가 수신기로부터 패킷이 도달했다는 확인응답을 수신할 때까지 소요되는 초의 수를 RTT라고 하고, R을 패킷/초 단위인 전송기의 현재 송신 레이트라고 하며, B를 패킷 단위인 블록의 크기라고 하자. TF 신뢰도 제어 프로토콜을 이용하여, 블록을 복원하는데 필요한 최종 패킷에 후속하여 전송된 블록에 대한 인코딩 유닛들을 포함하는 불필요한 패킷들의 수는 N = R*RTT이다. 따라서, 전송된 패킷들의 부분 f = N/(B+N)는 낭비되며, 결국 굿풋은 기껏해야 1-f 이다. 예를 들어, R=1,000 패킷/초이고, RTT=1 이고, B=3,000 패킷들인 경우, f=0.25인바, 즉 수신된 패킷들의 25%가 낭비된다. 따라서, 이 예에서 굿풋은 (1.0이라는 가능한 최대 굿풋에 비해) 불충분한 0.75이다.

[0044] 이 예에서, 레이트 R과 함께 블록 B의 크기는, 단순 FEC 기반 신뢰도 제어 프로토콜에 의해 도입된 지연이 적어도 4초(각 블록이 총 4초 동안 전송됨)임을 암시하며, 적어도 하나의 블록, 즉 데이터의 3,000개의 패킷들에서 버퍼링을 필요로 한다는 것을 또한 주목해야 한다. 더욱이, 굿풋을 증가시키는 것은 버퍼링을 증가시키는 것을 필요로 하거나, 반대로 버퍼링을 감소시키는 것은 굿풋을 감소시키는 것을 필요로 한다.

[0045] Luby 등으로 명명되는 미국 특허 번호 제 7,447,235호 (이하에서 "Luby II"로 지칭됨)는 향상된 FEC 기반 신뢰도 프로토콜을 기술한다. 그러나, 복수의 경로들을 통한 스트리밍에 대한 향상된 신뢰도 제어 프로토콜들이 바람직하다. 더욱이, 신뢰도 및 굿풋을 최대화하고 단-대-단 지연을 최소화하는, 복수의 경로들을 통한 스트리밍에 적합한 전송 프로토콜을 초래하기 위해 향상된 신뢰도 제어 프로토콜들과 결합될 수 있는 대응하는 레이트 제어 프로토콜을 제공하는 것이 바람직하다.

[0046] 본 개시에 따른 예들에서, 다중 경로 전송을 위한 인터리빙된 신뢰도 제어 프로토콜들이 TCP, TF 신뢰도 제어 프로토콜 및 노-코드 신뢰도 제어 프로토콜 및 Luby II에 기술된 FEC 기반 신뢰도 프로토콜에 대한 개선들을 제공하기 위해 사용될 수 있다. 더욱이, 신뢰도 및 굿풋을 최대화하고 단-대-단 지연을 최소화하는 복수 경로들을 통한 스트리밍에 적합한 전송 프로토콜을 제공하기 위해 향상된 신뢰도 제어 프로토콜들과 결합될 수 있는 향상된 레이트 제어 프로토콜들 및 생성 레이트 프로토콜들이 도입된다.

[0047] 신뢰도 제어 프로토콜에 있어서, 데이터의 블록들은 전송기로부터 수신기로의 일련의 인코딩 유닛들로서 전송되며, 수신기는 인코딩 유닛들 또는 블록들의 복원을 확인 응답하고, 그로 인해 전송기가, 수신기가 데이터를 수신했는지 그렇지 않으면 수신하지 않았는지를 결정하고, 데이터를 전송하거나 수신된 데이터를 복원하기 위해 사용가능한 다른 데이터를 전송하게 한다. 일부 인터리빙된 신뢰도 제어 프로토콜들의 일 특성은, 상이한 블록들에 대한 인코딩 유닛들이 인터리빙된 방식으로 전송된다는 것이다. 인터리빙된 신뢰도 제어 프로토콜들은, 사실상 임의의 레이트 제어 프로토콜과 결합할 때, 이들이 종단 시스템에서 버퍼링(및 결과적인 지연)을 최소화하고 전송의 굿풋을 최대화하는 효율적인 신뢰 가능한 데이터 전송을 제공하는 특성을 갖는다.

[0048] 본 개시의 기법들에 따르면, 큰(high) 손실이 있는 경우에 조차도 그리고/또는 큰 RTT가 존재하는 경우에 조차도, 높은 쓰루풋을 유지하면서 신뢰 가능한 데이터 전송을 보장하기 위해, 인터리빙된 신뢰도 제어 프로토콜들이 적절한 레이트 제어 프로토콜과 함께 이용될 수 있다. 예를 들어, 레이트 제어 프로토콜은 고정된 레이트로 전송하는 것 만큼 간단할 수 있으며, 그리고 인터리빙된 신뢰도 제어 프로토콜은, 전송 동안 버퍼링 및 레이턴시를 최소화하면서, 성공적으로 도달하는 패킷들의 비율(fraction) 곱하기 고정된 레이트와 같은 레이트로 데이터가 전송되도록 보장할 것이다.

[0049] 여기에서 도입되는 인터리빙된 신뢰도 제어 프로토콜들에 의해 제공되는 정량적(quantitative) 개선들의 예로서, 레이트 제어 프로토콜이 초당 R개의 패킷들의 고정된 레이트로 패킷들을 전송할 것이고, 전송기와 수신기 간의 라운드-트립 시간이 RTT 초 이며, 그에 따라, N=R*RTT 는 확인응답이 되지 않은 인플라이트(in flight) 패킷들의 수인 것으로 가정한다. 노-코드 신뢰도 제어 프로토콜에 대해, 전송기에서의 총 버퍼 크기 B는 적어도 N*In(N)이고, 굿풋은 대략 1.0 이고, 요구되는 양의 버퍼링과 굿풋 간에 어떠한 가능한 다른 트레이드-오프 포인트(trade-off point)들도 존재하지 않는다. 여기서, In(x)는 x의 자연 로그로서 정의된다. TF 신뢰도 제어 프로토콜을 이용하게 되면, 전송기에서의 총 버퍼 크기는 적어도 B 이고, 굿풋은 대략 B/(B+N) 이며, 여기서 B는 패킷들 단위(units)의 선택된 블록 크기이며 그리고 요구되는 버퍼링을 굿풋에 대하여 트레이드-오프시키도록 선택될 수 있다. 대조적으로, Luby Ⅱ에서 설명되는 것들과 같은, 인터리빙된 신뢰도 제어 프로토콜들에 대해, 전송기에서의 총 버퍼 크기는 기껏해야 B 이고, 굿풋은 대략 N/(N+X) 이며, 여기서 X는 요구되는 버퍼링을 굿풋에 대하여 트레이드-오프시키도록 선택되는 양의 정수 파라미터이고, B=N*(1+In((N/X)+1))이 패킷들 단위의 버퍼 크기이다.

[0050] 예로서, 레이트 R이 1,000 패킷들/초 이고, RTT가 1초이면, N=1,000 패킷들이다. 노-코드 신뢰도 제어 프로토콜에 대해, 전송기에서의 버퍼 크기는 적어도 7,000 패킷들이다. TF 신뢰도 제어 프로토콜에 대해, B가 4,000 패킷들이도록 선택된다면, 굿풋은 대략 0.80 이다. Luby Ⅱ에서 설명되는 인터리빙된 신뢰도 제어 프로토콜들에 대해, X가 50 이도록 선택되는 경우, B=4,000 패킷들(TF 신뢰도 제어 프로토콜들에 대해서와 동일한 값)이고, 굿풋은 0.95를 초과하는 바, 즉 수신되는 패킷들 중에서 기껏해야 5%가 낭비된다. 따라서, 이러한 예에서, 인터리빙된 신뢰도 제어 프로토콜들은, 거의 동일한 최적의 굿풋을 가지면서, 노-코드 신뢰도 제어 프로토콜 보다 훨씬 더 적은 버퍼링을 요구하며, 그리고 동일한 양의 버퍼링에 대해 TF 신뢰도 제어 프로토콜의 굿풋을 훨씬 초과하는 바, 즉, TF 신뢰도 제어 프로토콜에 대한 25%에 비해, 인터리빙된 신뢰도 제어 프로토콜들에 대해서는 기껏해야 5%의 송신이 낭비된다.

[0051] 실질적으로, 임의의 레이트 제어 프로토콜이, 인터리빙된 신뢰도 제어 프로토콜과 함께 이용되어, 신뢰 가능한 전송 프로토콜을 제공할 수 있는데, 예를 들어, 고정된 레이트로 전송하고, TCP와 유사한 윈도우-기반 혼잡(congestion) 제어를 이용하고, TRFC(TCP Friendly Rate Control)와 같은 방정식 기반 혼잡 제어 프로토콜(equation based congestion control protocol)을 이용하거나, 또는 실질적으로, 본원에서 도입되는 레이트 제어 프로토콜들을 포함하는, 임의의 다른 레이트 제어 프로토콜들을 이용할 수 있다.

[0052] 하기에서의 이후의 설명은, 전송기로부터 수신기로 다수의 독립적인 경로들을 통해 데이터를 전송하는 데에 적합할 수 있는 레이트 제어 프로토콜들을 설명할 뿐만 아니라, 이러한 레이트 제어 프로토콜들과 결합될 수 있는 향상된(enhanced) 인터리빙된 신뢰도 제어 프로토콜들을 설명한다. 또한, 데이터가 송신을 위해 얼마나 빠르게 생성되어야 하는 지를 결정하기 위해 이용될 수 있는 생성 레이트 프로토콜들(generation rate protocols)이 설명된다. 마지막으로, 설명은, 신뢰도 및 굿풋을 최대화하고 그리고 단부간(end-to-end) 레이턴시를 최소화하는, 전송기로부터 수신기로 다수의 독립적인 경로들을 통해 데이터를 스트리밍하는 데에 적합한 전반적(overall) 전송 프로토콜을 제공하기 위해 이들 프로토콜들을 결합하기 위한 방식들의 예들을 설명한다.

[0053] 이러한 설명에서, 신뢰 가능한 전송 프로토콜은, 전송되는 패킷들 중 일부가 수신되지 않을 가능성이 있는 경우에 조차도 모든 데이터가 전송되는 방식으로 전송단 시스템으로부터 패킷 기반 네트워크를 통해 수신단 시스템에 데이터를 신뢰 가능하게 전송하는 프로토콜이다.

[0054] 도 1은, 신뢰 가능한 전송 프로토콜이 동작(operate)할 수 있는, 네트워크(130), 전송단 시스템들의 세트(100(1)-100(J)) 및 수신단 시스템들의 세트(160(1)-160(K))의 예를 도시하는 개념도이다. 전송단 시스템들(100)은 또한 서버 디바이스들로서 설명될 수 있고, 수신단 시스템들(160)은 클라이언트 디바이스들로서 설명될 수 있다. 전형적으로, 그러한 프로토콜은 또한, 패킷 전송 레이트를 조정하기 위한 몇몇 메커니즘들을 포함하며, 여기서, 이러한 전송 레이트는, 프로토콜이 구축되는(built) 애플리케이션, 사용자 입력 파라미터들, 및 전송단 시스템과 수신단 시스템 간의 네트워크 조건들(network conditions)을 포함하는 다양한 팩터들에 의존할 수 있다.

[0055] 신뢰 가능한 전송 프로토콜, 이를 테면 TCP는 전형적으로 몇 개의 단계들을 수반한다. 이러한 단계들은, 단 시스템들(end systems)이 데이터의 유효성을 광고하고(advertise), 다른 단 시스템들로의 데이터의 전송을 개시하고, 어떤 데이터가 전송될 것인지를 전달하고(communicate), 그리고 신뢰 가능한 데이터 전송을 수행하는 방식들을 포함한다. 단 시스템들이 유효성을 광고하고, 전송을 개시하고, 무엇이 전송될 지를 전달하는 다양한 표준 방식들, 예를 들어, 세션 공표 프로토콜들(session announcement protocols), 세션 개시 프로토콜들(session initiation protocols) 등이 있다. 이들 단계들은 잘 알려져 있기 때문에, 이들은 여기에서 더 상세히 설명될 필요가 없다.

[0056] 패킷 데이터의 신뢰 가능한 전송은, 전송시의 각각의 포인트에서, 패킷들에서 어떤 데이터를 전송할지와 그리고 패킷들을 어떤 레이트로 전송할지를 결정하는 것을 포함한다. 각각의 시점(point in time)에서 행해지는 결정들은, 수신단 시스템으로부터 전송되는 피드백, 및 다른 팩터들에 의존할 수 있다. 전형적으로, 데이터는 전송단 시스템에서 데이터의 스트림으로서 제시되며, 그리고 신뢰 가능한 전송 프로토콜은, 이러한 스트림을 이것이 전송되었던 것과 동일한 순서(order)로 수신단 시스템에 신뢰 가능하게 전달하도록 의도된다. 전송이 개시되기 전에 스트림의 총 길이가 알려지지 않는 경우가 종종 있다.

[0057] 본 개시는 신뢰 가능한 전송 프로토콜들을 위한 모듈식 아키텍쳐(modular architecture)의 예들을 설명한다. Adler는 임의의 신뢰 가능한 전송 프로토콜이 어떻게 신뢰도 제어 프로토콜과 레이트 제어 프로토콜의 결합으로서 고려될 수 있는 지를 설명한다. 신뢰도 제어 프로토콜은, 전송 동안 각각의 패킷에 어떤 데이터를 배치할(place) 지를 결정하는 전반적 전송 프로토콜의 일부이다. 레이트 제어 프로토콜은, 각각의 데이터 패킷을 언제 전송할지를 결정한다. 많은 전송 프로토콜들에 있어서, 신뢰도 제어 및 레이트 제어 프로토콜들은 동작시 불가분하게(inseparably) 인터와인드되는데(interwined), 즉 이것은 TCP에 대한 경우이다. 하지만, 여전히, 그러한 인터와인드된 프로토콜 조차도 신뢰도 제어 프로토콜과 레이트 제어 프로토콜로 개념적으로 분할될 수 있는 경우가 있다.

[0058] Adler는, 신뢰도 제어 프로토콜 및 레이트 제어 프로토콜을 독립적으로 설계함으로써, 신뢰 가능한 전송 프로토콜들의 설계를 지지한다(advocate). 그러한 접근법의 장점은, 동일한 신뢰도 제어 프로토콜이 다양한 레이트 제어 프로토콜들과 함께 이용될 수 있으며, 그에 따라, 동일한 신뢰도 제어 프로토콜이, 전반적 신뢰 가능한 전송 프로토콜이 이용되는 네트워크 조건들 및 애플리케이션에 대해 적절한 레이트 제어 프로토콜과 함께 이용될 수 있다는 것이다. 설계에 대한 이러한 모듈식 접근법은 상당히 유익할 수 있는데, 왜냐하면 동일한 신뢰도 제어 프로토콜이, 상이한 애플리케이션들 및 네트워크 환경들에서 다양한 세트의 레이트 제어 프로토콜들과 함께 이용될 수 있고, 그에 따라 각각의 애플리케이션 및 네트워크 환경에 대해 신뢰 가능한 전송 프로토콜 전체의 완전한 재설계를 피할 수 있기 때문이다. 예를 들어, TCP는, 상이한 네트워크 환경들에서의 다양한 애플리케이션들에 대해 이용되며, 이는 그 레이트 제어 프로토콜에 의해 결정되는, 자신이 달성하는 불충분한(poor) 쓰루풋으로 인해, 이들 애플리케이션들 및 네트워크 환경들 중 일부에 대해 불충분하게(poorly) 수행한다. 불행하게도, 신뢰도 제어 프로토콜 및 레이트 제어 프로토콜은 TCP 아키텍쳐에서 매우 인터와인드되기 때문에, TCP가 불충분하게 작동(work)하는 그러한 상황들에서 그 쓰루풋 성능을 개선하기 위해서 TCP 내에서 상이한 레이트 제어 프로토콜을 간단히 사용하는 것이 가능하지 않다.

[0059] 도 1의 예에서, 전송단 시스템들(100) 중 하나는 본 개시의 기술들을 사용하여 네트워크(130)를 통해 수신단 시스템들(160) 중 하나로 데이터를 전송할 수 있다. 예컨대, 전송단 시스템(100(1))은 본 개시의 기술들 중 하나 이상을 사용하여 미디어 데이터를 수신단 시스템(160(1))에 전송할 수 있다. 일례로, 전송단 시스템(100(1))은 네트워크(130)를 통해 복수의 병렬 경로들을 거쳐 수신단 시스템(160(1))으로 순방향-에러 정정된 미디어 데이터를 전송할 수 있다. 이러한 순방향-에러 정정된 데이터는 복수의 블록들을 포함할 수 있으며, 이들 각각은 복수의 인코딩 유닛들을 사용하여 FEC-인코딩될 수 있다. 따라서 각각의 블록에 대해, 전송단 시스템(100(1))은 복수의 인코딩 유닛들을 수신단 시스템(160(1))으로 전송할 수 있다.

[0060] 수신단 시스템(160(1))은 병렬 네트워크 경로들 각각에 대한 손실들을 나타내는 데이터 전송할 수 있다. 이러한 데이터의 일례는 도 9와 도 13에 관해 아래 더 상세히 설명된다. 일반적으로, 데이터는 각각의 블록에 대해, 수신된 인코딩 유닛들의 수 및 수신된 가장 높은 시퀀스 번호를 표시할 수 있다. 추가로 또는 대안으로, 데이터는 다양한 병렬 네트워크 경로들을 통한 각각의 패킷 플로우에 대해, 수신된 가장 높은 시퀀스 번호를 표시할 수 있다. 마찬가지로, 전송단 시스템(100(1))은 손실들에 관해 수신단 시스템(160(1))에 의해 전송된 데이터를 수신할 수 있다. 전송단 시스템(100(1))은 손실들에 관한 이러한 데이터를 사용하여 다음 인코딩 유닛들이 어떻게 형성되는지를 변경할 수 있는데, 예를 들어 손실들이 예상보다 높다면 추가 FEC 데이터를 포함시키고, 또는 손실들이 예상보다 낮다면 FEC 데이터의 양을 감소시킬 수 있다. 인코딩 유닛들에 포함되는 FEC 데이터의 이러한 변경은 병렬 네트워크 경로들에 대한 손실들의 어그리게이션을 기초로 할 수 있다.

[0061] 추가로 또는 대안으로, 전송단 시스템(100(1))은 블록이 완전히 형성되기 전에 블록의 인코딩 유닛들을 전송할 수 있다. 예컨대, 현재 블록이 크기가 K개의 인코딩 유닛들이라고 가정하면, 전송단 시스템(100(1))은 현재 블록에 대한 K개의 모든 인코딩 유닛들이 전송기(100(1))에 이용 가능해지기 전에 현재 블록에 대한 하나 이상의 인코딩 유닛들을 전송할 수 있다. 또한, 수신단 시스템(160(1))은 현재 블록에 대한 K개의 인코딩 유닛들을 수신하기 전에 다음 블록의 하나 이상의 인코딩 유닛들을 수신할 수 있다.

[0062] 도 2는 Adler에서 지지되는 예시적인 모듈식의 신뢰 가능 전송 프로토콜 아키텍처를 나타내는 블록도이다. 전송기 전송 프로토콜(210)은 전송기 신뢰도 제어 프로토콜(220) 및 전송기 레이트 제어 프로토콜(230)로 분할된다. 전송기 신뢰도 제어 프로토콜(220)은 각각의 데이터 패킷에서 무엇이 전송되는지를 결정하고, 전송기 레이트 제어 프로토콜(230)은 각각의 데이터 패킷이 언제 전송되는지를 결정한다. 전송기 신뢰도 제어 프로토콜(220)은 수신기 전송 프로토콜(290) 내의 수신기 신뢰도 제어 프로토콜(280)에 의해 사용될 수 있는 각각의 데이터 패킷에 추가 신뢰도 제어 정보를 배치할 수 있다.

[0063] 전송기 신뢰도 제어 프로토콜(220)은 또한 각각의 데이터 패킷에서 무엇이 전송되는지의 결정을 돕는데 사용되는 수신기 전송 프로토콜(290) 내의 대응하는 수신기 신뢰도 제어 프로토콜(280)로부터의 신뢰도 제어 정보(250)를 수신할 수 있다. 마찬가지로, 전송기 레이트 제어 프로토콜(230)은 수신기 전송 프로토콜(290) 내의 수신기 레이트 제어 프로토콜(270)에 의해 사용될 수 있는 각각의 데이터 패킷에 추가 레이트 제어 정보를 배치할 수 있다. 전송기 레이트 제어 프로토콜(230)은 또한 각각의 데이터 패킷이 언제 전송되는지의 결정을 돕는데 사용되는 수신기 전송 프로토콜(290) 내의 대응하는 수신기 레이트 프로토콜(270)로부터의 레이트 제어 정보(250)를 수신할 수도 있다.

[0064] 전송기 신뢰도 프로토콜(220)과 수신기 신뢰도 프로토콜(280) 사이에 전달되는 신뢰도 제어 정보는 패킷 손실과 같은 다양한 팩터들에 의존할 수 있으며, 뒤에 어느 정도 상세히 설명되는 바와 같이 다양한 정보를 포함할 수 있다. 마찬가지로, 전송기 레이트 제어 프로토콜(230)과 수신기 레이트 제어 프로토콜(270) 사이에 전달되는 레이트 제어 정보는 패킷 손실 및 측정된 왕복 시간(RTT)과 같은 다양한 팩터들에 의존할 수 있다. 더욱이, 데이터 패킷들(240)에서 또는 피드백 패킷들(250)에서 전송된 정보가 신뢰도 제어와 레이트 제어 모두에 사용될 수도 있다는 점에서, 신뢰도 제어 정보와 레이트 제어 정보가 중첩될 수도 있다. 일반적으로, 전송기 전송 프로토콜(210)로부터 수신기 전송 프로토콜(290)로 전송되는 신뢰도 제어 및 레이트 제어 정보는 데이터 패킷들(240) 내의 데이터로 전송되거나 개별 제어 패킷들(240)에서 전송될 수 있고, 또는 둘 다 가능하다. 이러한 프로토콜들은 전송기에서 수신기로 그리고 수신기에서 전송기로 전송될 필요가 있는 제어 정보의 양을 최소화하도록 설계되어야 한다.

[0065] 많은 애플리케이션들의 경우에, 데이터는 스트림으로서 전송되어야 하는데, 즉, 데이터가 전송단 시스템에 도착하면, 데이터가 전송단 시스템에 도착한 것과 동일한 순서로 가능한 한 신속하게 수신단 시스템으로 신뢰 가능하게 전송되어야 한다. 일부 애플리케이션들의 경우, 예를 들어 스트리밍 애플리케이션의 경우, 또는 데이터의 작은 버스트들이 2개의 단 시스템들 사이에서 가능한 한 신속하게 왔다갔다 송신되는 대화식 애플리케이션의 경우에, 전체 전송 프로토콜에 의해 유도되는 레이턴시는 최소화되어야 한다. 따라서 전송 프로토콜에 의해 유도되는 전체 레이턴시는 최소화되어야 한다.

[0066] 전송기 신뢰도 제어 프로토콜(220)과 수신기 신뢰도 제어 프로토콜(280)은 일반적으로 둘 다 데이터를 임시로 저장하기 위한 버퍼들을 필요로 한다. 일반적으로, 전송기 신뢰도 제어 프로토콜(220)에서 버퍼링되는 데이터는 적어도, 전송기 신뢰도 제어 프로토콜(220)이 수신기 신뢰도 제어 프로토콜(280)로부터 복원에 관한 확인응답을 아직 수신하지 않은 스트림에서의 가장 빠른 데이터에서, 전송기 신뢰도 제어 프로토콜(220)이 데이터 패킷들에서 전송하기 시작한 스트림에서의 가장 늦은 데이터까지를 포함한다. 수신기 신뢰도 제어 프로토콜(280)에서의 버퍼 크기는 일반적으로 아직 복원되지 않은 가장 빠른 데이터에서부터 데이터 패킷들이 수신된 가장 늦은 데이터까지, 적어도 스트림에서의 데이터의 양이다.

[0067] 전송기 신뢰도 제어 프로토콜(220)의 버퍼링 요건들은 전송기 신뢰도 제어 프로토콜(220)에 의해 얼마나 많은 임시 저장 공간이 요구되는지, 그리고 전송기 신뢰도 제어 프로토콜(220)이 전체적인 신뢰 가능 데이터 전송에 얼마나 많은 레이턴시를 유도하는지에 직접적인 영향을 갖는다. 수신기 신뢰도 제어 프로토콜(280)의 버퍼링 요건들은 비슷한 영향을 갖는다. 따라서 전송기 신뢰도 제어 프로토콜(220)과 수신기 신뢰도 제어 프로토콜(280) 둘 다의 버퍼링 요건들을 최소화하는 것이 중요하다.

[0068] 신뢰도 제어 프로토콜은 각각의 데이터 패킷에서 무엇이 전송되는지를 결정한다. 단 시스템들 간의 접속을 효율적으로 이용하기 위해서는, 수신기 신뢰도 제어 프로토콜(280)에 어떤 데이터 패킷들이 수신되든 오리지널 데이터 스트림의 부분들을 복원하는데 유용함을 보장하도록, 전송기 신뢰도 제어 프로토콜(220)이 패킷들에서 가능한 한 적은 리던던트 데이터를 전송하는 것이 중요하다. 데이터의 오리지널 스트림의 길이를 데이터의 오리지널 스트림의 복원 도중 수신기 신뢰도 제어 프로토콜(280)에 의해 수신되는 데이터 패킷들의 총 길이로 나눈 것이 되도록 신뢰도 제어 프로토콜의 굿풋이 정의된다. 굿풋 목표는 신뢰도 제어 프로토콜이 1.0 또는 거의 그 정도의 굿풋을 야기하는 것이며, 이 경우 데이터의 오리지널 스트림을 복원하기 위해 최소량의 데이터가 수신된다. 일부 신뢰도 제어 프로토콜들에서, 굿풋은 1.0 미만일 수 있으며, 이 경우 송신된 데이터 패킷들 중 일부는 낭비된다. 따라서 전송단 시스템에서 수신단 시스템으로 이동하는 데이터 패킷들에 의해 소비되는 대역폭을 효율적으로 사용하기 위해 굿풋이 가능한 한 1.0에 가깝도록 신뢰도 제어 프로토콜들을 설계하는 것이 중요하다.

[0069] 신뢰도 제어 프로토콜들에서 사용된 한가지 해법은, FEC(Forward Error-Correction) 코드들, 이를테면 리드-솔로몬(Reed-Solomon) 코드들 또는 토네이도(Tornado) 코드들, 또는 Luby I 또는 Shokrollahi I에서 설명된 것들과 같은 (정보 부가 코드들인) 연쇄 반응 코드들의 해법이다. 본래 데이터는 패킷의 페이로드(payload)보다 더 큰 블록들로 분할되며(partitioned), 그 후 인코딩 유닛들이 이러한 블록들로부터 생성되며 패킷들의 인코딩 유닛들을 전송한다. 리드-솔로몬 또는 토네이도 코드들과 같은 소거 정정 코드들은 고정 길이 블록을 위한 일정 수의 인코딩 유닛들을 생성한다. 예를 들면, 입력 유닛들을 포함하는 블록에 대해, N개의 인코딩 유닛들이 생성될 수 있다. 이러한 N개의 인코딩 유닛들은 B개의 본래 입력 유닛들 및 N-B개의 여분의 유닛들을 포함할 수 있다.

[0070] FEC-기반 신뢰도 제어 프로토콜이 FEC 코드들을 사용하는 신뢰도 제어 프로토콜이다. 도 3은 전송기 FEC-기반 신뢰도 제어 프로토콜(220)의 예를 도시하는 블록도이며, 도 4는 수신기 FEC-기반 신뢰도 제어 프로토콜(280)의 예를 도시하는 블록도이다. 전송기 신뢰도 제어 로직(310)은 본래 데이터의 스트림을 데이터 블록들(330)로 분할하며, 그 후 각각의 블록에 대한 인코딩 유닛들을 생성하도록 FEC 인코더(320)에 명령한다. 전송기 신뢰도 제어 로직(310)은, 인코딩 유닛들 및 신뢰도 제어 정보(340)가 전송기 레이트 제어 프로토콜(230)을 핸들링하는 디바이스로 전달되는 방법을 결정하며, 또한 도 4에 도시된 수신기 FEC-기반 신뢰도 제어 로직(410)에 의해 전송된 신뢰도 제어 정보(350)를 핸들링한다.

[0071] 전송기 신뢰도 제어 로직(310)은, 각각의 블록이 복원되는 것을 보장하도록, 충분한 인코딩 유닛들이 도 4에 도시된 수신기 FEC-기반 신뢰도 제어 프로토콜(280)에 의해 수신되는 것을 보장해야 한다. 모든 블록들은 본질적으로 동일한 길이일 수 있거나, 블록 길이는 전송기에 대해 데이터의 스트림이 이용가능하게 되는 레이트, 데이터 패킷들의 전송 레이트, 네트워크 조건들, 애플리케이션 요건들 및 사용자 요건들을 포함하는 다양한 파라미터들에 따라, 이송 중에 동적으로 변화할 수 있다.

[0072] 주어진 데이터 블록은 길이에 있어서 B개의 인코딩 유닛들을 가정한다. 일부 FEC 코드들에 대해, 본래의 데이터 블록을 복원하는데 요구되는 인코딩 유닛들의 수는 정확하게는 B개 이지만, 다른 FEC 코드들에 대해, 본래의 데이터 블록을 복원하는데 요구되는 인코딩 유닛들의 수는 B개보다 약간 더 많다. FEC-기반 신뢰도 제어 프로토콜들의 설명을 단순화하기 위해, B개의 인코딩 유닛들은 데이터 블록의 복원에 대해 충분한 것으로 가정되며, 이때 블록을 디코딩하기 위해 B개 초과의 인코딩 유닛들을 필요로 하는 FEC 코드는 약간 감소된 굿풋(goodput) 및 약간 증가된 버퍼링 요건으로 사용될 수 있는 것으로 이해될 것이다.

[0073] 도 4의 수신기 신뢰도 제어 로직(410)은, 데이터 블록을 디코딩하기 위해 B개의 인코딩 유닛들이 수신되고 그 후 FEC 디코더(420)가 데이터 블록(430)을 복원하는데 사용되는 것을 보장하는 것을 담당한다. 수신기 신뢰도 제어 로직(410)은, 전송기 FEC-기반 신뢰도 제어 프로토콜(220)로부터 전송된 인코딩 유닛들 및 신뢰도 제어 정보(340)를 수신하고, 그리고 전송기 신뢰도 제어 로직(310)에 최종적으로 전송되고 전송기 신뢰도 제어 로직(310)에 의해 프로세싱되는 신뢰도 제어 정보(350)를 생성하고 전송하는 것을 담당한다.

[0074] TF 신뢰도 제어 프로토콜은 데이터의 스트림을 대체로 동일한 크기의 블록들로 분할한다. 전체 아키텍쳐는 임의의 시점에서 하나의 액티브 데이터 블록이 존재하는 것이며, 전송기는 그러한 데이터 블록에 대해 인코딩 유닛들을 생성하고, 블록을 재구성하기 위해 충분한 인코딩 유닛들이 도달됐다는 것을 나타내는 메시지를 전송기가 수신기로부터 수신할 때까지 인코딩 유닛들을 전송하며, 그러한 시점에서 전송기는 다음 블록으로 이동한다. 따라서, 주어진 블록에 대한 모든 인코딩 유닛들이 생성되고 전송되며, 블록은 후속하는 블록에 대한 임의의 인코딩 유닛들이 생성되고 전송되기 전에 복원된다.

[0075] 도 5는 TF 신뢰도 제어 프로토콜에 의해 사용될 수 있는 포맷들의 하나의 가능한 세트를 도시하는 블록도이다. 이러한 예의 전송기 데이터 포맷은, 전송기 TF 신뢰도 제어 프로토콜이 인코딩 유닛들 및 대응하는 신뢰도 제어 정보를 수신기 TF 신뢰도 제어 프로토콜에 전송하는 포맷을 설명한다. 이는, 인코딩 유닛이 어느 블록으로부터 생성되는지를 나타내는 블록 번호(510), 인코딩 유닛이 블록으로부터 생성되는 방법을 나타내는 인코딩 유닛 ID(520), 및 블록을 복원하기 위해 수신기 TF 신뢰도 제어 프로토콜 내의 FEC 디코더에 의해 사용될 수 있는 인코딩 유닛(530)을 포함한다. 수신기 피드백 포맷은, 수신기 TF 신뢰도 제어 프로토콜이 신뢰도 제어 정보를 전송기 TF 신뢰도 제어 프로토콜에 전송하는 포맷을 설명한다. 이는, 블록을 복원하기 위해 수신기 TF 신뢰도 제어 프로토콜이 인코딩 유닛들을 수신하고 있는 현재 블록의 블록 번호인 블록 번호(540), 및 수신기 TF 신뢰도 제어 프로토콜이 블록을 복원하는데 필요한 부가적인 인코딩 유닛들의 수인 요구되는 인코딩 유닛들(550)을 포함한다.

[0076] 도 6은 전송기 TF 신뢰도 제어 프로토콜을 구현하기 위한 프로세스의 예를 도시하는 흐름도이다. 이러한 예시적인 프로세스에 따르면, (도 1의 전송단 시스템들(100) 중 하나와 같은) 전송기 디바이스는, 대응하는 전송기 레이트 제어 프로토콜에 의해 결정되는, 전송기 데이터(단계(610))에 전송할 시간인가를 알기 위해 연속적으로 체크한다. 전송기 데이터에 전송할 시간이라면, 인코딩 유닛은 액티브 블록으로부터 생성되며, 전송기 데이터는 전송된다(620). 전송기 데이터에 대한 형태의 예는 도 5에 도시된 포맷이다. 프로세스는 또한, 수신기 피드백이 수신되었는가(630)를 알기 위해 연속적으로 체크한다. 수신기 피드백 데이터에 대한 형태의 예는 도 5에 도시된 포맷이다. 수신기 피드백이 존재한다면, 얼마나 많은 부가적인 인코딩 유닛들이 수신기가 활성 블록을 복원하는데 필요한지에 대한 정보를 업데이트하도록 프로세싱된다. 그 후 요구되는 인코딩 유닛들의 수가 0인지를(640) 알기 위해 체크하며, 만약 그렇다면, 데이터 스트림의 다음 블록이 이용가능한지(650)를 알게 된다. 만약 이용가능하지 않다면, 블록이 준비될 때까지 다음 블록(660)을 준비하며, 그 후 현재의 액티브 블록을 비활성화하고 다음 블록을 활성화하도록 계속된다(670). 일반적으로, 다음 블록은 현재의 액티브 블록이 송신되는 동안 준비중일 수 있다.

[0077] 본원에서 설명되는 프로토콜들의 각각은 적합한 프로세서에 의해 실행되는 펌웨어 또는 소프트웨어 또는 디바이스에 의해 구현될 수 있는 것으로 이해되어야 한다. 예를 들면, 라우터들 및 호스트 컴퓨터들과 같은 네트워크 디바이스들을 사용하여 구현들이 이루어질 수 있을뿐 아니라, 무선 송신기들, 재송신기들, 및 다른 무선 디바이스들 상에서 구현될 수 있다. 본원에서 설명되는 프로토콜들은 소프트웨어에서 구현될 수 있으며, 방법들을 가지며, 그리고/또는 그러한 프로토콜들을 구현하도록 구성되는 장치를 갖는다.

[0078] 도 7은 수신기 TF 신뢰도 제어 프로토콜을 구현하기 위한 예시적인 프로세스를 도시하는 흐름도이다. 수신기 TF 신뢰도 제어 프로토콜에 따르면, 수신단 시스템들(160)(도 1) 중 하나와 같은 수신기 디바이스는, 도 5에 도시된 전송기 데이터 포맷 내에 있는, 전송기 데이터가 수신되었는가를 알기 위해 연속적으로 체크할 수 있다(710). 만약 그렇다면, 전송기 데이터 내의 인코딩 유닛이 액티브 블록으로부터인가가 체크된다(720). 인코딩 유닛이 액티브 블록으로부터가 아니라면, 인코딩 유닛이 폐기되고(760), 그에 따라 인코딩 유닛이 임의의 블록을 복원하는데 유용하지 않기 때문에, 인코딩 유닛은 불필요한 전송기 데이터이다.

[0079] 인코딩 유닛이 액티브 블록으로부터라면, 인코딩 유닛은 액티브 블록에 대해 이미 수신된 인코딩 유닛들의 세트에 부가되며, 블록에 대해 요구되는 인코딩 유닛들의 수는 1만큼 감소된다(730). 그 후 인코딩 유닛들의 요구되는 수가 0인지를 알기 위해 체크하며(740), 만약 그렇다면, FEC 디코더를 사용하여 액티브 블록을 복원하고 다음 액티브 블록에 대한 인코딩 유닛들의 수신을 준비한다(750). 수신기 TF 신뢰도 제어 프로토콜은 또한, 수신기 피드백을 전송할 시간인가를 알기 위해 연속적으로 체크하며(770), 이는 대응하는 수신기 레이트 제어 프로토콜에 의해 결정된다. 만약, 그러한 시간이라면, 수신기 피드백이 준비되고 전송되며(780), 이는 도 5에 도시된 수신기 피드백 포맷의 형태 이내이다.

[0080] 이것이 전체 TF 신뢰도 제어 프로토콜의 부분적인 설명이라는 것을 주목하라. 예를 들면, 이것은, 수신기 피드백이 수신기 TF 신뢰도 제어 프로토콜에 의해 전송되는 조건들을 지정하지 않는다. 이것은 수신된 전송기 데이터의 수신에 의해, 가끔 탈선(go off)하는 타이머에 의해, 또는 수신기 레이트 제어 프로토콜에 의해 결정된 이러한 이벤트들 또는 임의의 다른 이벤트들의 임의의 조합하에 의해 트리거링될 수 있다. 일반적으로, 수신기 피드백은 수신기 TF 신뢰도 제어 프로토콜에서 인코딩 유닛들의 수신의 진행에 관하여 규칙적으로 알려진 전송기 TF 신뢰도 제어 프로토콜을 유지하기에 충분히 자주 전송되고, 전송기 TF 신뢰도 제어 프로토콜로부터 수신기 TF 신뢰도 제어 프로토콜로 전송되는 인코딩 유닛들을 포함하는 전송기 데이터와 거의 같은 많은 대역폭을 소비하기에 충분히 자주는 아니다.

[0081] TF 신뢰도 제어 프로토콜이 다음에 오는 의미에서 "낭비적인" 것으로 고려될 수 있다는 것을 주목하라. B를 인코딩 유닛들의 유닛들의 각각의 데이터 블록의 크기라고 놓고, R은 패킷들이 레이트 제어 프로토콜에 의해 전송되는 레이트라고 놓고, RTT는 전송기와 수신단 시스템들 사이의 라운드-트립 시간으로 놓고, N = R*RTT라 놓는다. 전송기와 수신기 사이에서 어떠한 패킷 손실도 존재하지 않는다고 예상하라. 그후, 전송기 TF 신뢰도 제어 프로토콜이 액티브 블록(블록을 복원하기에 충분함)에 대한 B 인코딩 유닛들을 전송한 후에, 이것이 블록을 복원하기에 충분한 인코딩 유닛들이 도달하였다는 것을 나타내는 수신기 피드백을 수신기 TF 신뢰도 제어 프로토콜로부터 수신할 때까지, 이것은 N 개의 부가적인 인코딩 유닛들을 계속해서 전송하고, 이러한 N 개의 인코딩 유닛들 모두가 낭비된다. 길이 B의 블록을 복원하는 것은 B+N 개의 인코딩 유닛들을 전송하는 것을 요구하고, 따라서, 굿풋은 B/(B+N)이다.

[0082] B가 N과 비교하여 상대적으로 작다면, 굿풋은 최적으로부터 멀고, 전송기와 수신기 사이의 많은 사용된 대역폭이 낭비된다. 반면에, B가 N과 비교하여 크다면, 전송기 및 수신기 TF 신뢰도 제어 프로토콜에서 버퍼들의 크기는 클 수 있고, 이것은 또한 수신기에서 데이터 스트림의 전달에서 지연이 크다는 것을 암시한다. 예로서, 인코딩 유닛의 크기가 1 킬로바이트라고 예상하면, 레이트(R)는 초 당 1,000 개의 인코딩 유닛들 = 초 당 1 메가바이트 = 초 당 8 메가비트들이고, RTT는 1 초이다. 그러면, N =R*RTT = 1 메가바이트이다. 블록의 크기가 B = 3 메가바이트들로 설정되면, 굿풋은 단지 대략 (B/(B+N)) = 0.75이고, 즉, 전송된 인코딩 유닛들 중 약 25 %가 낭비된다. 전송된 인코딩 유닛들 중 약 2%만이 낭비되도록 굿풋을, 예를 들면, 0.98로 증가시키는 것은 B = 49 메가바이트들의 매우 큰 버퍼 크기를 요구한다. 그러면, 이러한 크기 버퍼는 적어도 50 초의 신뢰도 제어 프로토콜만큼 부가된 지연을 초래한다.

[0083] 앞서 설명된 TF 신뢰도 제어 프로토콜에 대한 많은 가능한 변형들이 존재한다. 예를 들면, 전송기 TF 신뢰도 제어 프로토콜은, B 개의 인코딩 유닛들이 블록으로부터 전송된 후에 인코딩 유닛들을 전송하는 것을 중지하고, 블록을 복원하기에 충분한 인코딩 유닛들이 수신되었는지 여부를 나타내기 위한 수신기 피드백을 수신하도록 대기할 수 있다. 어떠한 손실도 없다면, 이러한 변형예는 낭비될 어떠한 인코딩 유닛들도 전송하지 않지만, 심지어 이러한 경우에, 각각의 블록 사이에 RTT 시간의 갭이 존재하고, 대역폭이 임의의 다른 목적으로 사용되지 않는다면, 이러한 프로토콜은 여전히 R*RTT의 대역폭의 낭비되는 양을 초래한다. 게다가, 총 전달 시간은 이상적인 것보다 B/(B+N) 배만큼 더 느려질 것이다. 손실이 존재하면, 이러한 변형예는 전달에서 심지어 추가의 지연들 및 둔화들을 부가할 것인데, 왜냐하면 결국 블록을 복원하기 위해, 손실된 인코딩 유닛들 대신에, 부가적인 인코딩 유닛들이 전송되어야 할 것이기 때문이다.

[0084] 임의의 손실된 인코딩 유닛이, 수신기 피드백에 대한 필요성 없이, 동일한 블록으로부터 생성된 임의의 후속으로 수신된 인코딩 유닛에 의해 보상될 수 있기 때문에, TF 신뢰도 제어 프로토콜은 비-코드 신뢰도 제어 프로토콜에 비해 이점을 갖는다. TF 신뢰도 제어 프로토콜이 낭비적이라는 것의 주요 이유는, 각각의 블록의 전송이 다음 블록에 대한 전송이 시작하기 전에 완료된다는 점에서, 프로토콜의 순차적인 성질로 인한 것이다. 본 명세서에 설명된 개선된 신뢰도 제어 프로토콜들은 지능적인 방식으로 블록들의 프로세싱을 인터리빙하는데 사용될 수 있다.

[0085] 인터리빙의 예시적인 예가 도 8에 도시된다. 이러한 예에서, 2 개의 액티브 블록들, 즉, 제 1 액티브 블록 AB 1(810) 및 제 2 액티브 블록 AB 2(820)가 존재한다. 도 8의 하단 부분은 시간에 걸친 데이터 패킷 전송의 패턴의 예를 도시하고, 여기서 각각의 패킷은 대응하는 패킷이 AB 1에 대한 인코딩 유닛을 포함하는지 또는 AB 2에 대한 인코딩 유닛을 포함하는지에 의존하여 AB 1 또는 AB 2 중 어느 하나로 라벨링된다. 이러한 예에서, AB 1에 대한 인코딩 유닛들을 포함하는 4 개의 패킷들(830(1), 830(2), 830(3) 및 830(4))이 먼저 전송되고, 그후 AB 2에 대한 인코딩 유닛들을 포함하는 2 개의 패킷들(830(5) 및 830(6)), 다음에 AB 1에 대한 인코딩 유닛을 포함하는 하나의 패킷(830(7)), AB 2에 대한 인코딩 유닛을 포함하는 하나의 패킷(830(8)) 및 AB 1에 대한 인코딩 유닛을 포함하는 하나의 패킷(830(9))이 전송된다. 일반적으로, 상이한 블록들에 대한 인코딩 유닛들 사이의 인터리빙은 굿풋을 최대화하고 총 버퍼링 요건들(및 결과적인 도입된 지연)을 최소화하도록 설계되어야 한다.

[0086] 전송단 시스템들(100)(도 1) 중 하나와 같은 전송기 디바이스는 도 8에 도시된 수신단 시스템들(160)(도 1) 중 하나와 같은 수신기 디바이스로 인터리빙된 데이터를 전송할 수 있다. 이러한 방식으로, 도 8은, 제 1 블록에 대한 제 1 세트의 인코딩 유닛들을 전송하는 단계 ― 제 1 세트의 인코딩 유닛들은 제 1 블록을 복원하기 위해 필요한 최소수보다 더 적은 수의 인코딩 유닛들을 포함함 ― , 제 1 세트의 인코딩 유닛들을 전송한 후에, 제 2 블록에 대한 제 2 세트의 인코딩 유닛들을 전송하는 단계 ― 제 2 블록은 데이터의 스트림에서 제 1 블록에 후속함 ― , 및 제 2 세트의 인코딩 유닛들을 전송한 후에, 제 1 블록에 대한 하나 이상의 인코딩 유닛들을 포함하는 제 3 세트의 인코딩 유닛들을 전송하는 단계를 포함하는 방법의 예를 도시한다. 마찬가지로, 도 8은 또한, 제 1 블록에 대한 제 1 세트의 인코딩 유닛들을 수신하는 단계 ― 제 1 세트의 인코딩 유닛들은 제 1 블록을 복원하기 위해 필요한 최소수보다 더 적은 수의 인코딩 유닛들을 포함함 ― , 제 1 세트의 인코딩 유닛들을 수신한 후에, 제 2 블록에 대한 제 2 세트의 인코딩 유닛들을 수신하는 단계, 및 제 2 세트의 인코딩 유닛들을 수신한 후에, 제 1 블록에 대한 하나 이상의 인코딩 유닛들을 포함하는 제 3 세트의 인코딩 유닛들을 수신하는 단계를 포함하는 방법의 예를 도시한다.

[0087] 도 8은, 블록이 완전히 형성되기 전에 블록에 대한 인코딩 유닛들이 전송되는 예를 나타낸다. 예를 들면, 액티브 블록 AB 1에 대한 인코딩 유닛들은, AB 1이 완전히 형성되기 전에 전송될 수 있고, 즉, AB 1에 대한 제 1 인코딩 유닛들(830(1), 830(2))이 전송기에 의해 전송될 때, AB 1의 전부가 전송기에서 이용 가능하지는 않고, 그럼에도 불구하고, AB 1의 인코딩 유닛들은 AB 1이 완전히 형성되기 전에 전송될 수 있다. 부가적으로 또는 대안적으로, AB 2는 완전히 형성되지 않는 것으로 고려될 수 있고, 그럼에도 불구하고, AB 2의 인코딩 유닛들은 AB 2가 완전히 형성되기 전에 전송될 수 있다. 예를 들면, AB 2에 대한 인코딩 유닛들(830(4), 830(5))은 AB 2의 전부가 전송기에서 완전히 이용 가능하기 전에 전송될 수 있다. 마찬가지로, 도 8은 AB 1 및 AB 2에 대한 인코딩 유닛들의 인터리빙 방식으로의 전송의 예를 나타낸다.

[0088] 도 9는 인터리빙된 신뢰도 제어프로토콜에 의해 사용될 수 있는 예시적인 포맷들의 세트를 예시하는 블록도이다. 전송기 데이터 포맷은, 전송기 인터리빙된 신뢰도 제어 프로토콜이 인코딩 유닛들 및 대응하는 신뢰도 제어 정보를 수신기 인터리빙된 신뢰도 제어 프로토콜로 전송할 수 있는 포맷을 묘사한다. 이러한 예는, 인코딩 유닛이 어떠한 블록으로부터 생성되는지를 나타내는 블록 번호(910), 이러한 블록으로부터 얼마나 많은 인코딩 유닛들이 전송되는지를 나타내는 시퀀스 번호(920), 블록으로부터 인코딩 유닛이 어떻게 생성되는지를 나타내는 인코딩 유닛 ID(930), 및 블록을 복원하기 위해 수신기 인터리빙된 신뢰도 제어 프로토콜 내에서 FEC 디코더에 의해 사용될 수 있는 인코딩 유닛(940)을 포함한다. 수신기 피드백 포맷은, 수신기 인터리빙된 신뢰도 제어 프로토콜이 신뢰도 제어 정보를 전송기 인터리빙된 신뢰도 제어 프로토콜로 전송할 수 있는 포맷을 묘사한다. 액티브 블록들 각각에 대해, 이것은 블록 번호(950(1), 950(2)), 블록을 복원하기 위해 얼마나 많은 부가적인 인코딩 유닛들이 필요로 되는지(960(1), 960(2)) 및 그 블록으로부터 멀리 떨어져 수신되는 가장 높은 시퀀스 번호(970(1), 970(2))를 포함한다.

[0089] 이러한 방식으로, 도 9는 수신단 시스템들(160)의 하나와 같은 수신 디바이스 및 전송단 시스템(100) 중 하나와 같은 전송 디바이스가 복수의 병렬 네트워크 경로들 각각 상에서 데이터의 손실들을 나타내는 데이터를 전송하고 수신하는 예를 나타내며, 이 데이터는 인코딩 유닛들이 수신된 복수의 블록들 각각을 식별하는 데이터, 블록들 각각에 대해 필요한 인코딩 유닛들의 수, 및 블록들 각각에 관련되는 네트워크 패킷들에 대해 수신되는 최고 시퀀스 번호들을 정의하는 데이터를 포함해서 손실들을 나타낸다.

[0090] 도 10은 기본 전송기 인터리빙된 신뢰도 제어 프로토콜의 로직의 예를 예시하는 흐름도이다. 도 10의 예시적인 프로토콜은 도 1의 전송단 시스템들(100) 중 하나와 같은 전송 디바이스에 의해 수행될 수 있다. 프로토콜의 이 예에서, 기본 전송기 인터리빙된 신뢰도 제어 프로토콜은 대응하는 전송기 레이트 제어 프로토콜에 의해 결정되는 전송기 데이터를 전송할 시간인지를 확인하기 위해 계속적으로 체크한다(1005). 전송기 데이터를 전송할 시간인 경우, 기본 전송기 인터리빙 신뢰도 제어 프로토콜은 인코딩 유닛을 생성하고 전송할 액티브 블록을 결정하기 위해 다음의 규칙들의 세트를 이용한다.

[0091] 기본 전송기 인터리빙된 신뢰도 제어 프로토콜은 각각의 액티브 블록 i에 대해 다음의 변수들을 계속 추적하는데(1010): B_i는 그 블록을 복원하는데 필요한 인코딩 유닛들의 수이고; R_i는 기본 수신기 인터리빙된 신뢰도 제어 프로토콜이 수신된 수신기 피드백에 기초하여 그 블록으로부터 수신되었음을 기본 전송기 인터리빙된 신뢰도 제어 프로토콜이 인지하는 인코딩 유닛들의 수이고; L_i = B_i - R_i는 기본 수신기 인터리빙된 신뢰도 제어 프로토콜이 블록을 복원하기 위해 수신할 필요가 있음을 기본 전송기 인터리빙된 신뢰도 제어 프로토콜이 인지하는 확인되지 않은 인코딩 유닛들의 나머지 수이고; U_i는 그 블록에 대해 전송되었지만 확인응답이 기본 전송기 인터리빙된 신뢰도 제어 프로토콜에 의해 아직 수신되지 않은 인코딩 유닛들의 수이고; X_i는 기본 전송기 인터리빙된 신뢰도 제어 프로토콜이 블록에 대한 인코딩 유닛들을 얼마나 공격적으로 전송할지를 결정하는 파라미터이다.

[0092] 이들 변수들은 다음과 같이 결정될 수 있다: B_i의 값은 각각의 인코딩 유닛의 크기 및 블록의 크기에 의해 결정된다. 프로세싱은 전송기에 대해 아직 완전히 이용 가능하지 않은 블록들 상에서 시작할 수 있는데, 즉, 아직 완전히 형성되지 않은 블록들이 액티브가 될 수 있고, 인코딩 유닛들은 이들에 대해 전송될 수 있다는 것에 주의한다. 이 경우에, B_i는 블록 i가 전송기에 대해 현재 이용 가능하지 않은 크기로 이루어진 경우 그 블록을 복원하는데 필요한 인코딩 유닛들의 수인 것으로 결정될 수 있으며, 이 경우에, B_i는 전송 프로세스 동안 동적으로 성장할 수 있는데, 그 이유는 B_i의 값이 변경되지 않은 채로 유지되는 지점에서 블록 i가 완전히 형성될 때까지 블록 i 초과가 전송기에 대해 이용 가능하게 되기 때문이다. 따라서, B_i는 블록 i의 초기 부분이 처음 이용 가능할 때 1에서 시작할 수 있고, B_i가 그 최종 값에 도달할 때까지, 즉 B_i가 완전한 블록 i의 크기에 도달할 때까지 블록 i 초과가 전송기에 대해 이용 가능하게 되기 때문에 늘어난다.

[0093] 일반적으로, 각각의 인코딩 유닛은 주어진 블록에 대해 그리고 때때로, 모든 블록에 대해 동일한 크기를 갖고, 크기는 데이터 패킷의 페이로드에 적합하게 되도록 선택되며, 예를 들어, 인코딩 유닛의 길이는 1024 바이트일 수 있다. 각각의 블록의 크기는 일반적으로 동일할 수 있거나, 또는 인코딩 유닛의 길이는 변동될 수 있거나, 또는 인코딩 유닛의 길이는 전송기에서 데이터 스트림의 도달 레이트에 의존할 수 있거나, 또는 인코딩 유닛의 길이는 데이터 패킷들의 전송 레이트에 의존할 수 있거나, 또는 인코딩 유닛의 길이는 이들 및 다른 팩터들의 결합에 의존할 수 있다. R_i의 값은 단계(1030)에서 수신된 수신기 피드백에 기초하여 결정된다. U_i의 값은 블록에 대한 인코딩 유닛을 포함하는 전송된 마지막 전송기 데이터의 시퀀스 번호와 블록에 대한 수신기 피드백에서 수신된 최고 시퀀스 번호 간의 차이이다.

[0094] 이러한 방식으로, 블록을 복원하는데 필요한 인코딩 유닛들의 수(예를 들어, B_i)는 블록의 크기 및 블록에 대한 인코딩 유닛들의 크기들에 기초하여 계산될 수 있다. 마찬가지고, 블록을 복원하는데 필요한 부가적인 인코딩 유닛들의 수(예를 들어, L_i)는 블록을 복원하는데 필요한 인코딩 유닛들의 수(예를 들어, B_i)와 수신된 인코딩 유닛들의 수(예를 들어, R_i) 간의 차이로서 계산될 수 있다.

[0095] X_i의 값은 전체 신뢰도 제어 프로토콜의 함수이고, 추후에 설명되는 바와 같이, X_i의 선택에 있어 트레이드오프들이 있다. X_i의 값은 블록에 대한 모든 인코딩 유닛들의 전송 동안 일정하게 남아있을 수 있거나, 또는 그것은 다양한 상이한 방식으로 값을 변경할 수 있으며, 이 방식들 중 일부는 추후에 설명된다. 본질적으로, 각각의 시점에서 X_i는 기본 수신기 인터리빙된 신뢰도 프로토콜로부터의 어떠한 부가적인 수신기 피드백도 없이, 블록을 복원하는데 필요한 최소치를 초과하여 기본 전송기 인터리빙 신뢰도 제어 프로토콜이 얼마나 많은 부가적인 인코딩 유닛들을 기꺼이 전송할지에 관한 측정이다. L_i는 이미 확인응답된 수신된 인코딩 유닛들을 초과하여 블록 i를 복원하는데 필요한 인코딩 유닛들의 수이기 때문에, 그리고 U_i는 플라이트 중에 있고, 아직 확인응답되지 않은 블록 i에 대한 인코딩 유닛들의 수이기 때문에, L_i + X_i - U_i는 기본 전송기 인터리빙된 신뢰도 제어 프로토콜이 그 시점에서 기꺼이 전송하는 블록 i에 대한 부가적인 인코딩 유닛들의 수이다.

[0096] X_i의 값에 관한 트레이드오프가 이어진다. X_i가 증가할 때, 가능하게는, 액티브 블록 i를 복원하는데 필요한 최소치를 초과하여 X_i까지의 인코딩 유닛들이 기본 수신기 인터리빙된 신뢰도 제어 프로토콜에 의해 수신될 수 있기 때문에, 굿풋(goodput)은 감소한다. 한 편, 액티브 블록들의 총 크기는, X_i이 증가할 때, 액티브 블록 i의 신뢰 가능한 수신을 완성하는데 할당되는 패킷 시간 슬롯들의 수가 증가하기 때문에 X_i가 증가할 때 감소한다. 블록 i에 대한 X_i 인코딩 유닛들은 손실되고, 여전히, 기본 수신기는 부가적인 인코딩 유닛들의 전송을 트리거하기 위한 수신기 피드백을 대기함 없이 블록을 복원할 수 있기 때문에, 이는 그것이 액티브가 될 때 블록 i의 더 빠른 복원을 허용한다. X_i의 함수로서 굿풋과 총 버퍼 크기 간의 트레이드오프들은 TF 신뢰도 제어 프로토콜 또는 노-코드 신뢰도 제어 프로토콜과 같은 다른 신뢰도 제어 프로토콜들에 대한 대응하는 트레이드오프들보다 훨신 더 양호하다는 것이 판명되었다.

[0097] 단계(1015)에서, 불균형 L_i + X_i - U_i > 0을 만족하는 액티브 블록 i가 존재하는지를 결정하기 위한 테스트가 이루어진다. L_i의 값은 수신기 피드백에 의해 이미 확인응답된 인코딩 유닛들에 기초하여 수신기가 블록을 복원하는데 필요할 인코딩 유닛들의 수이다. U_i는 이 블록에 대한 플라이트 중인 확인응답되지 않은 인코딩 유닛들의 수이고, 이에 따라 L_i-U_i는 플라이트 중인 인코딩 유닛들 중 어느 것도 손실되지 않는 경우 전송해야 할 부가적인 인코딩 유닛들의 수이고, 이에 따라 L_i-U_i가 0 또는 그 미만인 경우, 수신기는 블록에 대한 플라이트중인 모든 인코딩 유닛들이 도달하는 경우 블록을 복원할 수 있을 것이다. 한 편, 인코딩 유닛들 중 일부가 손실될 수 있고, X_i는 후속 수신기 피드백에 의해 트리거되는 블록에 대한 부가적인 인코딩 유닛들을 송신해야 할 필요성을 방지하도록 전송기가 사전적으로 손실들로부터 기꺼이 보호하는 부가적인 인코딩 유닛들의 수이다.

[0098] 따라서, L_i + X_i - U_i > 0 인 경우, 전송기는 블록 i에 대한 보다 많은 인코딩 유닛들을 기꺼이 전송할 것이고, 그것이 0이거나 음인 경우, 전송기는 블록 i에 대한 보다 많은 인코딩 유닛들을 기꺼이 전송하지 않을 것이다. 따라서 단계(1015)에서, L_i + X_i - U_i > 0을 만족하는 액티브 블록 i가 존재하는 경우, 인코딩 유닛이 생성되고, 대응하는 전송기 데이터는 단계(1020)에서 가장 빠른 이러한 액티브 블록에 대해 전송된다. 이러한 액티브 블록이 존재하지 않는 경우, 인코딩 유닛이 생성되고, 대응하는 전송기 데이터는 단계(1025)에서 모든 액티브 블록 중에서 가장 빠른 액티브 블록으로부터 전송된다. 바람직하게는, 파라미터들은, 어떠한 블록도 단계(1025)의 실행을 강제하는 단계(1015)의 조건을 만족시키지 않게 되는 것을 가능한 많이 방지하도록 하는 방식으로 세팅되는데, 그 이유는, 본질적으로, 단계(1025)는 기본 전송기 인터리빙된 신뢰도 제어 프로토콜 내의 버퍼들을 클리어하기 위한 마지막 리조트로서 행해져야 하기 때문이다. 단계들(1020 및 1025)에서의 전송된 데이터는 동일한 수신기로 다수의 경로들을 통해 전송될 수 있다.

[0099] 아직 완전하게 형성되지 않은 액티브 블록들이 존재하는 경우, 단계(1015)는, 이들이 아직 완전하게 형성되지 않은 블록들인 것으로 또한 간주하도록 변경되어야 한다. 일 변형예에서, 액티브이지만 아직 완전하게 형성되지 않은 블록들에 대한 단계(1015)에 도시된 대응하는 조건이 아직 완전하게 형성되지 않은 액티브 블록에 대한 소스 인코딩 유닛들 모두가 전송될지 또는 전송되지 않을 지 여부 대신에 존재해야 하며, 이들이 모두가 전송되지 않았다면 나머지 전송되지 않은 소스 인코딩 유닛들이 전송될 수 있다. 이와 같이, 이 변형예에서, 블록 i에 대해 전송될 수 있는 인코딩 유닛들의 수는 최대 B_i이고, 여기서, B_i는 부분적으로 형성된 블록 i 내의 소스 인코딩 유닛들의 현재 수이다. 제 2 변형예에서, 액티브이지만 아직 완전하게 형성되지 않은 블록들에 대한 단계(1015)에 도시된 대응하는 조건들은 대신에, X_i=0을 설정하고, 인코딩 유닛들이 손실되거나(lost) 또는 수신된 것으로 확인응답되었던 인코딩 유닛들 중에서 손실되었다는 것을 또한 나타내는 향상된 수신기 피드백에 기초하여 수신되지 않은 것으로 확인응답되었던 인코딩 유닛들을 재전송하도록 되어야 한다. 이와 같이, 이 변형예에서, 단계(1015)에서의 조건 L_i+X_i-U_i>0은, 블록 i가 액티브이지만 아직 완전히 형성되지 않은 경우 조건 L_i-U_i>0으로 대체된다. 이 경우, 모든 소스 인코딩 유닛들이 이미 전송되었지만 일부가 손실 상태인 것으로 확인응답되었다면, 이러한 인코딩 유닛들은, 조건 L_i-U_i>0가 만족되는 경우 재전송될 수 있다.

[0100] 프로토콜의 일 변형예는 다음과 같다. 다수의 액티브 블록들이 1에서 시작하는데, 즉, 데이터 스트림의 제 1 블록이 활성화된다. 단계(1015)의 조건을 만족하는 액티브 블록이 존재하지 않을 때에만, 데이터의 스트림 내 새로운 블록이 활성화된다. 이러한 단순한 전략을 이용하여, 블록들은 단지 필요할 때에 액티브 블록들이 되고, 따라서 액티브 블록들의 수, 및 결과적으로 버퍼 크기가 블록 i에 대한 굿풋(goodput) B_i(B_i+X_i)를 보장하기 위해 필요한 수로 셀프-조정한다.

[0101] 프로토콜의 다른 변형예는 다음과 같다. 이 변형예에서, 총 버퍼 크기는 항상 동일한 크기로 남아있는 반면(모든 블록들이 동일한 크기인 경우 이는 고정된 수의 액티브 블록들이 항상 존재한다는 것을 의미한다), 굿풋은 변할 수 있다. 단계(1015)에서 조건을 만족하는 액티브 블록이 존재하지 않을 때마다 액티브 블록들에 대한 X_i의 값들은, 단계(1015)의 조건을 만족하는 액티브 블록들이 존재할 때까지 증가된다. 적절할 때마다 액티브 블록 i에 대한 X_i의 값들이 감소되며 단계(1015)의 조건을 만족하는 액티브 블록이 항상 존재한다는 제약이 있다. X_i의 값들을 증가시키고 감소시키는 많은 가능한 방법들이 존재하는데, 예를 들어, 모든 값들을 동등하게 증가시키는 것, 모든 값들을 비례적으로 동등하게 증가시키는 것, 제 1 액티브 블록들에 대한 값들을 최종 액티브 블록들에 대한 값들을 초과하여 증가시키는 것, 최종 액티브 블록들에 대한 값들을 제 1 액티브 블록들에 대한 값들을 초과하여 증가시키는 것이다. X_i의 값들을 감소시키기 위한 비슷한 전략들이 사용될 수 있다. 당업자는 또한 많은 다른 변형예들을 생각할 수 있다.

[0102] 프로토콜의 이러한 변형예들의 많은 다른 조합들 및 확장들이 매우 많아서 설명하기 어렵지만, 당업자에게는 명백해야 한다.

[0103] 단계(1030)에서, 임의의 수신기 피드백이 수신되었는지 여부를 알기 위해 체크되고, 수신되었다면, 파라미터들 모두가 단계(1035)에서 이것에 기초하여 업데이트되는데, 즉, 모든 액티브 블록들 i에 대해 파라미터들 R_i, U_i 및 X_i이다. 단계(1040)에서, 완전히 복원됨에 따라 가장 빠른 액티브 블록이 확인응답되었는지를 알기 위해 체크되고, 확인응답되었다면 가장 빠른 블록이 단계(1045)에서 비활성화되고 프로세싱은 단계(1040)로 복귀하고, 확인응답되지 않은 경우, 프로세싱은 단계(1050)으로 진행한다. 단계(1050)에서, 다른 블록이 액티브 상태가 될 준비가 되었는지 여부를 알기위해 체크되고, 액티브 상태가 될 준비가 된 경우, 단계(1060)에서, 이 다음 블록이 액티브 상태가 되고 프로세싱은 단계(1050)로 복귀하고, 액티브 상태가 될 준비가 되지 않은 경우, 프로세싱은 단계(1005)로 진행한다. 일반적으로, 현재 액티브 블록이 전송되고 있는 동안 다음 블록 또는 여러 개의 다음 블록들이 준비 상태에 있을 수 있고, 가장 빠른 액티브 블록이 비활성화되는 시기에 또는 그 이전에 활성화될 준비가 된다.

[0104] 이러한 방식으로, 도 10은, 클라이언트 디바이스로, 복수의 병렬 네트워크 경로들을 통해 순방향-에러 정정된 데이터를 전송하는 단계, 클라이언트 디바이스로부터, 네트워크 경로들 각각을 통해 전송된 데이터의 손실들을 나타내는 데이터를 수신하는 단계, 및 이 손실들을 나타내는 데이터에 기초하여, 병렬 네트워크 경로들을 통해 후속 데이터 송신들을 위해 전송된 순방향 에러 정정 데이터의 양을 변경하는 단계를 포함하는 방법의 예를 도시한다. 손실들을 나타내는 수신된 데이터는, 병렬 네트워크 경로들 각각에 대해, (예를 들어, 도 13에 대하여 아래에 논의된 바와 같이) 각각의 병렬 네트워크 경로를 통해 전송된 패킷 플로우를 위해 수신된 최고 시퀀스 번호를 식별하는 데이터, 및/또는 인코딩 유닛들이 클라이언트 디바이스에 의해 수신되었던 복수의 블록들 각각, 블록들 각각에 대해 필요로 되는 인코딩 유닛들의 수를 식별하는 데이터, 및 (예를 들어, 도 9에 대하여 상기 설명된 바와 같이) 블록들 각각과 관련된 네트워크 패킷들에 대한 클라이언트 디바이스에 의해 수신된 최고 시퀀스 번호들을 정의하는 데이터를 포함할 수 있다.

[0105] 도 11은 기본 수신기 인터리빙된 신뢰도 제어 프로토콜의 로직의 예를 도시하는 흐름도이다. 이 버전의 프로토콜에서, 기본 수신기 인터리빙된 신뢰도 제어 프로토콜은 송신기 데이터가 수신되었는지 여부를 알기 위해 계속 체크하며(1105), 이는, 예를 들어, 도 9에 도시된 송신기 데이터 포맷으로 존재할 수 있다. 데이터가 수신되었다면, 이는 단계(1110)에서 모든 액티브 블록들 상에서 그의 정보를 업데이트하고 송신기 데이터 내부의 수신된 인코딩 유닛이 액티브 블록(1115)로부터 비롯된 것인지 여부를 알기 위해 체크한다. 인코딩 유닛이 이미 복원되었던 블록으로부터 비롯된 것이거나 또는 현재 액티브 블록에 있게 될 데이터 스트림에서 매우 멀리 전방에 있는 블록으로부터 비롯된 것이면, 이는 단계(1135)에서 폐기되고, 따라서, 어떠한 블록도 복원하는 데에 유용하지 않기 때문에 이는 송신기 데이터를 낭비한다. 그렇지 않은 경우, 인코딩 유닛이 이것이 생성되었던 액티브 블록에 대한 인코딩 유닛들의 풀(pool)에 추가되며, 복원하기 위해 많은 인코딩 유닛들이 필요로 되며 액티브 블록이 단계(1120)에서 업데이트된다.

[0106] 블록 i에 대한 필요한 인코딩 유닛들의 수가 B_i 마이너스 수신된 인코딩 유닛들의 수로서 계산된다. B_i의 값을 기본 수신기 인터리빙된 신뢰도 제어 프로토콜로 통신하는 다양한 방법들이 존재하며, 예를 들어, B_i의 값이 각각의 송신기 데이터 내부에 포함될 수 있고, B_i의 값이 별개의 제어 메시지들ㅇ서 전송될 수 있고, B_i의 값이 모든 블록들에 대하여 동일할 수 있고 세션 개시 동안 통신될 수 있는 식이다.

[0107] 이후, 가장 빠른 액티브 블록에 대한 인코딩 유닛들의 필요한 수가 단계(1125)에서 0인지를 알기 위해 체크되고, 0인 경우, 이것은 FEC 디코더를 이용하여 액티브 블록을 복원하고 새로운 다음 액티브 블록에 대한 인코딩 유닛들의 수신을 준비한다(단계 1130). 기본 수신기 인터리빙된 신뢰도 제어 프로토콜은 또한 수신기 피드백을 전송할 시기인지를 계속 체크하고(1140), 이는 대응하는 수신기 레이트 제어 프로토콜에 의해 결정된다. 전송할 시기라면 수신기 피드백이 준비되고 전송되며(단계 1145), 이는, 예를 들어, 도 9에 도시된 수신기 데이터 포맷으로 존재할 수 있다.

[0108] 상기는 전체 기본 인터리빙된 신뢰도 제어 프로토콜 중 부분적인 설명이라는 것을 주목한다. 예를 들어, 이거은 수신기 피드백이 기본 수신기 인터리빙된 신뢰도 제어 프로토콜에 의해 전송되는 조건들을 지정하지 않는다. 이는, 수신된 송신기 데이터의 수신에 의해, 타이머에 의해(타이머가 오프 상태가 될 때마다 매우 자주), 또는 이러한 이벤트들 또는 수신기 레이트 제어 프로토콜에 의해 결정된 바와 같은 임의의 다른 이벤트들의 임의의 조합에 의해 트리거링될 수 있다. 일반적으로, 수신기 피드백이, 기본 수신기 인터리빙된 신뢰도 제어 프로토콜에서 인코딩 유닛들의 수신의 진행에 대하여 정기적으로 통지되는 기본 송신기 인터리빙된 신뢰도 제어 프로토콜을 유지하기에 충분하게 자주 전송되지만, 송신기 데이터가 기본 송신기 인터리빙된 신뢰도 제어 프로토콜로부터 기본 수신기 인터리빙된 신뢰도 제어 프로토콜로 전송된 인코딩 유닛들을 포함하는 것만큼 많은 대역폭을 거의 소비할 만큼 자주 송신되는 것을 아니다.

[0109] 기본적인 인터리빙된 신뢰도 제어 프로토콜은, TF 신뢰도 제어 프로토콜 또는 노-코드 신뢰도 제어 프로토콜보다 굿풋과 버퍼들의 크기 사이에서 훨씬 더 양호한 트래이드오프를 가질 수 있다. 예를 들어, 기본적인 인터리빙된 신뢰도 제어 프로토콜에 대해 최대 2개의 활성 블록들이 존재한다고 추정한다. B를 인코딩 유닛들의 유닛들에서 각각의 데이터 블록의 크기라고 하고, R을 패킷들이 레이트 제어 프로토콜에 의해 전송되는 레이트라 하고, RTT를 전송기와 수신기 엔드 시스템들 사이의 라운드-트립 시간이라 하고, N-R*RTT라 하며, X가 모든 활성 블록들에 대해 고정된 상수라고 추정한다. 이러한 예에서, 일반적으로 이들 파라미터들 모두가 데이터 전송 동안 동적으로 변할 수도 있지만, 이들 파라미터들 모두가 고정된 값들을 갖는다고 가정하며, B>=N이라고 가정한다.

[0110] 전송기와 수신기 사이에 어떠한 패킷 손실도 존재하지 않는다고 추정한다. 그 후, 가장 일찍 활성인 블록이 기본적인 수신기 인터리빙된 신뢰도 제어 프로토콜에 의해 성공적으로 복원된다는 것을 표시하는 수신기 피드백을 그것이 수신할 때까지, 기본적인 전송기 인터리빙된 신뢰도 제어 프로토콜은, 가장 일찍 활성인 블록에 대해 B+X 개의 인코딩 유닛들을 전송하고, 그 후, 다음의 활성 블록으로부터의 인코딩 유닛들을 전송한다. 기본적인 전송기 인터리빙된 신뢰도 제어 프로토콜이 가장 일찍 활성인 블록을 비활성화시키는 이러한 포인트에서, 몇몇 인코딩 유닛들이 이미 전송했던 다음의 활성 블록은 가장 일찍 활성인 블록이 되며, 다음의 블록은 활성 블록이 되도록 활성화된다. 따라서, B+X 인코딩 유닛들은 길이 B의 블록을 복원하는데 사용되며, 따라서, 전송된 인코딩 유닛들의 X가 낭비된다.

[0111] 한편, B>=N이면, 도 9의 단계(1015)에서 도시된 부등식을 충족시켰던 활성 블록이 항상 존재할 것이다. 따라서, 굿풋은 B/(B+X)이지만, 2개의 활성 블록들이 존재하면 버퍼의 총 크기는 2*B이다. 일 예로서, 인코딩 유닛의 크기가 1킬로바이트이고, R이 초당 1,000개의 인코딩 유닛들 = 초당 1메가바이트 = 초당 8메가비트이며, RTT가 1초라고 추정한다. 그 후, N=R*RTT=1메가바이트이다. 블록의 크기가 1메가바이트이면(이는, B=1,000개의 인코딩 유닛들이고 X는 10개의 인코딩 유닛들로 셋팅된다는 것을 의미함), 굿풋은 대략 (B/(B+X))=0.99, 즉 전송된 인코딩 유닛들의 최대 1%가 낭비되지만, 총 버퍼 크기는 단지 2MB이다(이는, 기본적인 전송기 인터리빙된 신뢰도 제어 프로토콜이 이러한 예에서 대략 2초의 레이턴시를 부가한다는 것을 의미함). 이러한 버퍼 크기가 동일한 상황의 전송기 TF 신뢰도 제어 프로토콜의 버퍼 크기보다 25배만큼 더 작다는 것을 유의한다.

[0112] 손실된 어떠한 패킷도 존재하지 않는 상술된 예에서, X의 값은 제로로 셋팅될 수 있어서, 굿풋을 1.0까지 증가시킨다. 그러나, 손실된 임의의 패킷이 존재하는 경우, 셋팅 X>0가 상당한 이점들을 가질 수 있다고 판명된다. 예를 들어, 최대 10개의 인코딩 유닛들이 상기 예에서 전송된 각각의 1,000으로부터 손실되면, 분석은, 동일한 굿풋 및 버퍼 크기들이 X=10으로 달성된다는 것을 나타내지만, 이것이 X=0에 대해 반드시 참일 필요는 없을 것이다. 패킷 손실이 더 가변적이고 알려지지 않는 경우, 특히 B개의 패킷당 손실된 패킷들의 수가 X를 초과할 수 있는 경우, 기본적인 인터리빙된 신뢰도 제어 프로토콜에 의해 달성될 수 있는 굿풋 및 버퍼 크기들이 매우 양호하며, TF 신뢰도 제어 프로토콜 또는 노-코드 신뢰도 프로토콜을 사용하여 달성될 수 있는 것보다 정량적으로 더 양호하다고 여전히 판명된다.

[0113] 다른 예로서, 패킷들에서 초당 레이트 R 및 라운드-트립 시간 RTT가 일정하게 유지되고 N=R*RTT 라고 추정한다. 각각의 패킷이 확률 p로 손실되도록 패킷 손실이 랜덤하다고 추정한다. 추가적으로, 각각의 블록 i는 크기 B_i가 패킷들의 단위들에서 동일한 크기 C라고 하고, 각각의 X_i가 동일한 값 Y를 갖는다고 추정한다. 추가적으로, 필요한 경우 새로운 블록만을 활성화시키는 상술된 프로토콜의 변형이 사용된다고 추정한다. 블록이 복원되는 확인응답이 수신기로부터 수신되기 때문에 그 블록이 먼저 활성화되는 시간으로부터 그 블록이 비활성화되는 시간까지 그 블록을 고려한다. 블록의 C-N 패킷들이 확인응답되었던 몇몇 시간 t에서, 확인응답되지 않은 운항중의 F=N+Y개의 패킷들이 존재하며, 전송기는, 수신기가 블록을 복원하기 위해 이들 패킷들의 N=F-Y를 필요로 한다는 것을 안다. 시간 t에서 블록에 대해 운항중이었던 F개의 패킷들의 시간 t+RTT에서, 패킷들의 (1-p)*F가 수신기에 의해 수신되고, 전송기는 확인응답을 수신한다.

[0114] 따라서, 시간 t+RTT에서, 전송기는, 수신기가 필요로 하는 나머지 패킷들의 수가 이제 N-(1-p)*F=p*F-Y 이며, 따라서, 운항중의 패킷들의 수가 이제 p*F라는 것을 안다. 로직을 계속하면, 시간 t+i*RTT에서, 전송기는, 수신기가 필요로 하는 나머지 패킷들의 수가 p^i*F-Y 이며, 따라서, 운항중의 패킷들의 수가 p^i*F라는 것을 안다. 수신기가 필요로 하는 전송기가 아는 패킷들의 수가 제로 아래로 떨어지는 경우, 블록이 완료되며, i가 p^i*F-Y<=0 를 충족하는 경우, 이것은 시간 t + i*RTT에서 참이다. 이러한 부등식이 참인 경우의 i의 가장 작은 값은, i가 대략 ln((N/Y)+1)/ln(1/p) 인 경우이다.

[0115] 각각의 RTT에서, 대략 (1-p)*N개의 패킷들이 수신기에 의해 수신되므로, 이것은, 최대 (ln((N/Y)+1)/ln(1/p))*(1-p)*N개의 패킷들이 수신될 때에 블록이 확인응답되는 시간만큼 전송기 프로토콜이 고려중인 블록을 넘어서 데이터 스트림에서 가장 멀리 진행할 수 있다는 것을 의미한다. p의 모든 값들에 대해 (1-p)/ln(1/p)<=1 을 주목하는 경우, 이것은, 버퍼의 크기가 길이에서 최대 C+ln((N/Y)+1)*N 이라는 것을 의미한다. 물론, 이것 모두는, 랜덤 프로세스가 자신의 예상된 거동처럼 정확히 거동한다는 것을 가정하고 있지만, 이것은 적어도 Y가 매우 작지는 않은 경우, 프로토콜이 어떻게 거동하는지의 대략적인 아이디어를 제공한다. 이러한 경우, 굿풋은 C/(C+Y)이다. 따라서, 예를 들어, RTT=1이고, R=1,000이고, C=1,000이고, Y=50이면, N=1,000이고, ln(1,000/50)은 대략 3이고, 버퍼 크기는 대략 1,000+(3+1)*1,000=5,000이며, 굿풋은, 대략 0.95인 1,000/(1,000+50)이다.

[0116] 상술된 기본적인 인터리빙된 신뢰도 제어 프로토콜에 대한 많은 변형들이 존재하며, 이는 이러한 설명을 판독한 이후에 명백할 것이다. 예를 들어, 상술된 바와 같이, 전송기 신뢰도 제어 프로토콜은, 한번에 2개 초과의 활성 블록들을 사용할 수 있으며, 이것은, 더 많은 활성 블록들을 관리하는데 더 많은 복잡도를 희생하여 전송기 및 수신기 신뢰도 제어 프로토콜들에서 사용된 버퍼들의 전체 크기를 감소시킬 수 있는 잠재적인 이점을 갖는다.

[0117] 변형의 다른 예로서, 어떤 활성 블록으로부터 인코딩 유닛이 전송될지를 결정하기 위해 랜덤 프로세스를 사용하는 것이 유익할 수 있다. 이것은, 패킷 손실 패턴들이 시스템적일 수 있고 반드시 랜덤할 필요는 없기 때문이며, 따라서, 어떤 인코딩 유닛을 다음에 전송할지를 선택하기 위해 사용되는 임의의 결정론적인 절차에 대해, 몇몇 블록들이 결코 복원되지 않지만 여전히 패킷들이 수신기에 전달되도록 하는 패킷 손실 패턴이 존재한다. 예를 들어, 결정론적인 절차가 특정한 활성 블록으로부터 인코딩 유닛을 전송할 때마다 그 인코딩 유닛이 손실되지만, 그 절차가 임의의 다른 활성 블록에 대해 인코딩 유닛을 전송할 때마다 그 인코딩 유닛이 수신기에 도달하는 손실 패턴을 고려한다.

[0118] 그 후, 이러한 예에서, 수신기가 여전히 인코딩 유닛들을 수신하더라도, 수신기는 활성 블록을 결코 복원하지 않는다. 이러한 타입의 시스템적인 손실을 극복하기 위해, 전송기 신뢰도 제어 프로토콜이 어떤 활성 블록으로부터 다음의 인코딩 유닛을 전송할지를 랜덤화하는 것이 유리하다. 이를 달성하기 위한 하나의 간단한 방식은, 전송기 신뢰도 제어 프로토콜이 전송될 Q개의 인코딩 유닛들의 배치들을 함께 버퍼링하는 것이며, 그 후, 랜덤한 순서로 Q개의 인코딩 유닛들의 각각의 배치를 전송한다. 예를 들어, 전송될 각각의 인코딩 유닛에 대해, 인코딩 유닛이 전송될 다음 시간에 그것이 전송되는 동적으로 변하는 확률을 할당하는 더 정교한 방법들이 또한 사용될 수도 있으며, 여기서, 그것이 더 많이 선택되지 않을 수록 확률이 증가한다. 다른 변형은, 단계(1015)의 조건을 충족하는 활성 블록들 중에서, 전송된 인코딩 유닛이 랜덤하게 생성되도록, (더 이전에 활성인 블록들을 선호할 수도 있고 시간에 걸쳐 동적으로 변할 수도 있는 적절히 선택된 확률 분포를 사용하여) 기본적인 전송기 인터리빙된 신뢰도 제어 프로토콜의 도 10에 도시된 바와 같이 단계(1020)를 변경시키는 것이다.

[0119] 액티브 블록(i)에 대해 인코딩 유닛을 언제 전송할지를 결정하기 위해 파라미터(X_i)가 사용되는 경우에, 송신 동안에 X_i를 어떻게 조정할지에 대한 다수의 변형들이 존재한다. 일 예는, X_i를 값으로 고정시키고, 송신 전반에 걸쳐 그 값을 유지하는 것이다. 예컨대, X_i는 제로로 세팅될 수 있거나, 또는 10과 같은 어떤 다른 고정된 값으로 세팅될 수 있다. 다른 예는, 액티브 블록(i)으로부터의 인코딩 유닛들의 송신의 시작에서 X_i를 값으로 고정시키고, 그 후에, 액티브 블록(i)으로부터 인코딩 유닛을 전송하기 위한 조건이 충족되지 않고, 인코딩 유닛이 전송될 때마다, X_i가 증가된다. X_i가 어떻게 증가될 수 있는지에 대한 다수의 변형들이 존재한다. 예로서, X_i는 제 1 N 그러한 시간들에 제로만큼 증가될 수 있고, 각각의 후속 시간에 N/B만큼 증가될 수 있다. 또한, 몇몇 단계들에서, X_i의 증가가 네거티브일 수 있는 것이 가능하다.

[0120] 다른 변형들로서, 베이직 인터리빙된 신뢰도 제어 프로토콜에서 설명되는 바와 같이 각각의 액티브 블록(i)에 대해 파라미터(X_i)만을 사용하는 대신에, 특정한 액티브 블록으로부터 인코딩 유닛이 전송되어야 하는지 여부를 결정하는 다른 방식들을 사용할 수 있다. 예컨대, 패킷 손실 확률의 평균이 유지될 수 있고, 그 후에, 액티브 블록으로부터 전송되게 허용되는 인코딩 유닛들의 수는, 최근의 패킷 손실 확률이 현재의 패킷 손실 확률에 대한 우수한 예측자라는 가정에 기초하여 결정될 수 있다. 예컨대, 평균 손실 확률이 현재 p인 경우에, 하나의 전략은, 조건이 L_i + X_i/(1-p) - U_i*(1-p) > 0이도록, 베이직 전송기 인터리빙된 신뢰도 제어 프로토콜의 도 10에 도시된 바와 같은 단계(1015)를 변경하는 것이다.

[0121] 이러한 특정한 선택 뒤에 있는 근거는, U_i 인코딩 유닛들이 액티브 블록(i)에 대해 비행 중인 경우에, 이들의 프랙션(1-p)만이 베이직 수신기 인터리빙된 신뢰도 제어 프로토콜에 도달할 것이고, X_i/(1-p) 부가적인 패킷들이 전송되는 경우에, X_i가 베이직 수신기 인터리빙된 신뢰도 제어 프로토콜에 도달할 것이다. 따라서, 전체적으로 평균하여, 베이직 수신기 인터리빙된 신뢰도 제어 프로토콜은 액티브 블록(i)에 대해 B_i + X_i 인코딩 유닛들을 수신할 것이고, X_i 부가적인 인코딩 유닛들의 값은, 블록을 복원하기에 충분한 수의 인코딩 유닛들의 송신을 위해 수신기 피드백에 따라, 패킷 손실 레이트에서의 변동성이 회피되는 것을 고려하기에 충분하게 세팅될 수 있다.

[0122] 인터리빙된 신뢰도 제어 프로토콜의 다른 변형들은, 패킷들이 전송 순서와 동일한 순서로 수신기에 도달하지 않을 수 있는 가능성을 고려한다. 따라서, 수신기로부터의 후속 수신기 피드백은, 예컨대, 블록으로부터 수신된 최고 시퀀스 번호가 동일하다고 하더라도, 주어진 액티브 블록에 대해, 이전의 수신기 피드백보다 더 큰 수의 수신된 인코딩 유닛들을 리포트백할 수 있다. 따라서, 베이직 인터리빙된 신뢰도 제어 프로토콜에서의 로직은, 재순서화된 패킷들에 대한 고려를 수용하기 위해 수신기 및 전송기 모두에서 변경될 수 있다.

[0123] 이전에 설명된 바와 같이, 도 10에 도시된 바와 같은 베이직 전송기 인터리빙된 신뢰도 제어 프로토콜의 단계(1025)는 일반적으로, 적어도 하나의 액티브 블록이 각각의 시점에서 조건(1015)을 만족시키도록, 파라미터들을 적절하게 세팅함으로써 회피될 것이다. 단계(1025)에 대한 변형은, 인코딩 유닛을 생성하고 전송하기 위해 어떤 액티브 블록이 선택될지를 변화시키는 것이다. 예컨대, 단계(1025)에서 액티브 블록은 무작위로 선택될 수 있거나, 또는 선택은 액티브 블록들의 세트를 통해 사이클링할 수 있다.

[0124] 도 10의 단계들(1040 내지 1060)은, 복원된 블록들을 비활성화시키고, 전송하기 위한 부가적인 블록들을 활성화시키기 위한 방법들을 설명한다. 하나의 간단한 방법은, 복원으로 인해 가장 빠른 블록이 비활성화되는 경우에 항상 다음 블록을 활성화시키고, 따라서, 항상 동일한 수의 액티브 블록들을 유지하는 것이다. 총 버퍼 크기 및 결과적인 레이턴시를 절약할 수 있는 변형은, 가장 늦은 현재의 액티브 블록을 지난 블록으로부터 인코딩 유닛을 전송하기 위한 시간일 때, 다음 블록만을 활성화시키는 것이다.

[0125] 베이직 인터리빙된 신뢰도 제어 프로토콜의 몇몇 변형들에 대해, 임의의 시점에서의 액티브 블록들의 수는 고정된다. 변형은, 어떤 레이트에서 데이터가 송신에 대해 이용가능하게 되는지, 얼마나 많은 패킷 손실이 발생하는지, 패킷들의 전송 레이트에서의 변동성 등을 포함하는 다양한 인자들에 따라, 액티브 블록들의 수가 변화되게 허용하는 것이다. 예컨대, 낮은 패킷 손실 조건들 및 낮은 전송 레이트 조건들 하에서, 액티브 블록들의 수는 작게 유지될 수 있지만, 손실 조건들이 악화되거나 또는 전송 레이트가 증가됨에 따라, 액티브 블록들의 수는 일시적으로 증가되게 허용될 수 있다. 따라서, 버퍼링 및 레이턴시는, 프로토콜이 동작하고 있는 조건들에 따라, 동적으로 변화된다.

[0126] 액티브 블록들의 총 크기가 또한, 액티브 블록들의 수가 고정된 채로 유지되는 경우에도 변화되게 허용될 수 있다. 이러한 경우에서, 각각의 후속 액티브 블록의 크기는 이전의 블록과 상이할 수 있다. 예컨대, 데이터 이용가능성 레이트가 증가됨에 따라, 후속 액티브 블록들의 크기가 또한 증가될 수 있고, 전송 레이트가 증가됨에 따라, 후속 액티브 블록들의 크기가 증가될 수 있다. 각각의 액티브 블록의 길이는 시간의 함수일 수 있고, 예컨대, 최대로 많은 시간이, 새로운 블록이 형성되기 전에 지나갈 수 있고, 그것은 길이의 함수일 수 있고, 즉, 각각의 블록은 최대로 길 수 있거나 또는 그것은 이들 및 다른 인자들의 조합일 수 있다.

[0127] 하나의 블록의 끝 및 다음 블록의 시작은, 인터리빙된 신뢰도 제어 프로토콜에 의해 자동적으로 판정될 수 있고, 그것은 애플리케이션 또는 이들 및 다른 인자들의 일부 조합에 의해 결정될 수 있다. 예컨대, 데이터 스트림의 블록은, 예컨대 MPEG 스트림에 대한 I-프레임 또는 픽처들의 그룹 블록과 같이, 애플리케이션에 대해 논리적인 의미를 가질 수 있고, 따라서, 인터리빙된 신뢰도 제어 프로토콜이 데이터의 스트림을 블록들로 파티셔닝하는 방식은, 논리적인 애플리케이션 블록들의 경계들을 준수할 수 있다. 대안적으로, 애플리케이션은, 인터리빙된 신뢰도 제어 프로토콜에게, 블록들 사이의 우선적인 경계들을 표시할 수 있고, 인터리빙된 신뢰도 제어 프로토콜은 가능한 잘 이들 경계들을 준수하도록 시도하지만, 여전히, 애플리케이션에 의해 공급되는 것들 이외의 포인트들에서 블록들 사이의 경계들을 만들도록 허용될 수 있다.

[0128] 인터리빙된 신뢰도 제어 프로토콜의 다른 변형은, 프로토콜이 수신기에 시퀀스로 신뢰 가능하게 모든 블록들을 전달하지 않고, 그러나, 대신에, 다른 제약들을 조건으로 이러한 목표를 달성하도록 가능한 잘 시도하게 허용하는 것이다. 예컨대, 스트리밍 애플리케이션에서, 데이터의 스트림을 가능한 신뢰 가능하게 전달하는 것이 중요할 수 있지만, 데이터 스트림에 대한 타이밍 제약들과 같은 다른 제약들이 또한 존재한다. 예컨대, 이는, 특정 시간 후에, 데이터의 특정 부분은 더 이상 관련되지 않는 경우, 또는 예컨대 인터렉티브 비디오 회의 애플리케이션에서, 인터리빙된 신뢰도 제어 프로토콜이 얼마나 많은 레이턴시를 도입할 수 있는지에 대한 강한 제한들이 존재하는 경우일 수 있다. 이들 경우들에서, 전송기 인터리빙된 신뢰도 제어 프로토콜 및 수신기 인터리빙된 신뢰도 제어 프로토콜은, 블록들 중 일부가, 이들이 완전히 복원되기 전에 스킵되게 허용하도록 변경될 수 있다.

[0129] 예컨대, 전송기 인터리빙된 신뢰도 프로토콜은, 주어진 시간 양 동안에만 액티브 블록이 액티브이게 허용하도록 제약될 수 있거나, 또는 그것은, 이후에 그것이 더 이상 블록에 대해 인코딩 유닛들을 전송하게 허용되지 않거나 또는 그것이 각가의 블록에 대해 제공된 최대 수의 인코딩 유닛들만을 전송하게 허용될 수 있는, 애플리케이션에 의해 공급되는 각각의 블록에 대한 엄격한 시간 제약들, 또는 이들 제약들의 임의의 조합을 가질 수 있다. 수신기 인터리빙된 신뢰도 제어 프로토콜에 대해 유사한 제약들이 적용가능할 수 있다. 이들 애플리케이션들에 대해, 인터리빙된 신뢰도 제어 프로토콜은 이들 제약들을 준수하도록 변경될 수 있다.

[0130] 인터리빙된 신뢰도 제어 프로토콜들의 일부 변형들에서, 하나의 전송기 및 하나의 수신기가 존재한다. 다른 변형들은: 하나의 전송기 및 다수의 수신기들; 하나의 수신기 및 다수의 전송기들; 다수의 전송기들 및 다수의 수신기들을 포함하지만 이에 한정되지 않는다. 예를 들어, 하나의 전송기/다수의 수신기 변형에서, 전송 채널이 브로드캐스트 또는 멀티캐스트 채널인 경우, 전송기 신뢰도 제어 프로토콜은, 전송기가, 도 10의 단계(1010)에서 임의의 수신기로부터 수신된 확인응답된 인코딩 유닛들의 최소수로서 R_i의 값을 각각의 액티브 블록 i에 대해 컴퓨팅하도록 수정될 수 있다.

[0131] 하나의 전송기/다수의 수신기 변형에 대한 다른 예로서, 전송기가 패킷들의 개별 스트림을 각각의 수신기에 전송하는 경우, 전송기 신뢰도 제어 프로토콜은, 전송기가 액티브 블록 i에 대해 수신기 j로부터 수신된 확인응답된 인코딩 유닛들의 수로서 R_ij의 값을 각각의 액티브 블록 i에 대해 그리고 각각의 수신기 j에 대해 컴퓨팅하고, 도 10의 단계(1010)에서 L_ij = B_i - R_ij를 컴퓨팅하도록 수정될 수 있으며, U_ij는 수신기 j에 전송된 액티브 블록 i에 대해, 전송되었지만 계속 확인응답되는 인코딩 유닛들의 수로서 컴퓨팅될 수 있고, 그 다음으로, 단계(1015)의 컨디션은, 액티브 블록 i가 존재하는 경우, 일부 수신기 j에 대해, L_ij + X_i - U_ij > 0임을 결정하도록 변화될 수 있다.

[0132] 다른 예로서, 많은 전송기/하나의 수신기 변형에 대해, 수신기 신뢰도 제어 프로토콜은, 수신기가 동일한 또는 상이한 액티브 블록들에 대해 다수의 전송기들로부터 동시에 인코딩 유닛들을 수신하고 수신기 피드백을 브로드캐스트 또는 멀티캐스트 채널에 의해 모든 전송기들에 전송하거나, 잠재적으로 개별 수신기 피드백을 갖는 개별 패킷 스트림을 이용하여 각각의 전송기에 전송하도록 수정될 수 있다. 다른 예로서, 다수의 전송기/다수의 수신기 변형에 대해, 하나의 전송기/다수의 수신기 경우 및 다수의 전송기/하나의 수신기 경우에 대해 앞서 설명된 수정된 단계들이 결합될 수 있다.

[0133] 다른 변형은, 전송기가, 전송기 인터리빙된 신뢰도 제어 프로토콜의 개별 인스턴스 또는 상이한 데이터 스트림들을 고려하는 전송기 인터리빙된 신뢰도 제어 프로토콜의 버전을 각각 이용하여 다수의 데이터 스트림들을 동시에 전송하는 것일 수 있는데, 예를 들어, 모든 스트림들에 대한 모든 패킷들에 대해 어그리게이트 전송 레이트가 제한될 수 있고, 따라서 전송기는 다른 데이터 스트림들보다 일부 데이터 스트림들에 대해 패킷들을 전송하는 것을 우선순위화하는 것을 결정할 수 있다. 유사하게, 수신기는 수신기 인터리빙된 신뢰도 제어 프로토콜의 개별 인스턴스 또는 상이한 데이터 스트림들을 고려하는 수신기 인터리빙된 신뢰도 제어 프로토콜의 버전을 각각 이용하여, 다수의 데이터 스트림들을 동시에 수신할 수 있는데, 예를 들어, 모든 스트림들에 대한 모든 패킷들에 대해 어그리게이트 수신 레이트가 제한될 수 있고, 따라서, 전송기는 다른 데이터 스트림들보다 일부 데이터 스트림들에 대해 패킷들을 수신하는 것 그리고 수신기 피드백을 프로세싱 및 전송하는 것을 우선순위화하는 것을 결정할 수 있다.

[0134] 앞서의 변형들 중 임의의 변형은 서로 결합될 수 있다. 예를 들어, 일부 블록들이, 예를 들어 타이밍 및/또는 대역폭 제한들로 인해 수신기들에 신뢰적으로 전달될 수 없는 프로토콜은 다수의 전송기/다수의 수신기 변형과 결합될 수 있다.

[0135] 이러한 방식에서, 도 11은, 복수의 병렬 네트워크 경로들을 통해 포워드-에러 정정된 데이터를 서버 디바이스로부터 수신하는 단계, 네트워크 경로들 각각을 통한 데이터의 손실들을 결정하는 단계, 및 네트워크 경로들 각각을 통한 데이터의 손실들을 나타내는 데이터를 서버 디바이스에 전송하는 단계를 포함하는 방법의 예를 도시한다.

[0136] 도 12는 본원의 기법들에 따라 다중경로 FEC-기반 신뢰도 전송 제어 방법들을 활용할 수 있는 다중경로 스트리밍 시스템의 블록도이다. 이러한 예에서, 비디오 생성기(1205)는 비디오 스트림(1210)을 생성하고, 비디오 스트림(1210)은 전송기 전송 프로토콜(1215)에 의해 수신된다. 전송기 전송 프로토콜(1215)은 어떤 데이터를 비디오 스트림(1210)을 위해 전송할지 결정하고, 전송될 데이터의 각각의 피스에 대해 이를 어느 경로 플로우를 따라 전송할지를 결정한다.

[0137] 각각의 경로 플로우에 대해, 그 경로 플로우에 대한 송신기(1220(1), 1220(2))는, 그 경로 플로우에 대한 데이터를, 수신기 전송 프로토콜(1225)에 의해 적어도 부분적으로 수신될 네트워크(1222)를 통해 전송한다. 수신기 전송 프로토콜(1225)은 가능한 한 최대의 충실도로, 원래의 비디오 스트림을 복원하고, 이 비디오 스트림(1230)을 다른 디바이스들에 생성하고, 가능하게는 다른 네트워크들을 통해 그리고 다른 세트들의 서버들을 거쳐, 최종 사용자 디바이스들에 재생한다. 비디오는 예시적 데이터 스트림이고 비-비디오 스트림(non-video stream)들(예를 들어, 오디오 스트림들 또는 다른 데이터 스트림들)은 유사하게 처리될 수 있음을 유의한다.

[0138] 본 명세서에서 설명된 바와 같이, 다수의 경로들을 이용함으로써, 그리고 어떤 경로들이 언제 이용되는지 등을 조정함으로써, 낮아진 전체적인 레이턴시 또는 더 높은 전체적인 데이터 처리량과 같은 개선들이 획득될 수 있고, 이는 일반적으로, 더 높은 품질의 스트리밍 경험을 의미한다. 이는, 심지어 다수의 경로들이 개별적 레이턴시, 대역폭 및 손실 레이트와 같은 이질적인 속성들을 갖는 경우일 수 있고, 그러한 속성들은 경로마다 변화되는 것에 부가하여, 또한 시간마다 변화될 수 있다. 이와 같이, 하나의 순서로 비디오 생성기에 의해 초기에 방출되는 패킷들은 상이한 순서로 수신될 수 있는데, 그 이유는 일부 경로들이 자신들의 패킷들을 다른 경로들보다 더 신속하게 전달할 수 있기 때문이다.

[0139] 이러한 아키텍처에서, 전송기 전송 프로토콜(1215) 및 수신기 전송 프로토콜(1225)은, 이들이 서로 통신하기 위해 이용하는 잘-확립된 세트의 데이터 포맷들을 가질 수 있고, 전송기 전송 프로토콜(1215)로부터 수신기 전송 프로토콜(1225)로 흐르는 데이터뿐만 아니라, 수신기 전송 프로토콜(1225)로부터 전송기 전송 프로토콜(1215)로 흐르는 제어 및 피드백 정보가 존재할 수 있다.

[0140] 경로 플로우들의 수 및 송신기들의 수는 임의의 수일 수 있고, 그 수들은 상이할 수 있는데, 예를 들어, 10개의 경로 플로우들 및 3개의 송신기들이 존재할 수 있고, 경로 플로우들 중 4개의 경로 플로우들은 제 1 송신기(1220(1))를 통과할 수 있고, 3개의 경로 플로우들은 제 2 송신기 및 제 3 송신기 각각을 통과할 수 있다. 송신기들(1220)은 전송기 전송 프로토콜(1215)과 동일한 하드웨어 디바이스 내에 공동으로 배치(collocate)될 수 있거나, 송신기들(1220)은 전송기 전송 프로토콜(1215)을 호스팅하는 하드웨어 디바이스와 별개인 하드웨어 디바이스들에 있을 수 있고, 이러한 디바이스들은 TCP 또는 UDP 같은 표준 전송 프로토콜에 기초하여, 예를 들어, 블루투스 또는 WiFi를 이용하여 서로 통신할 수 있다. 송신기들(1220)이 자신들의 데이터를 수신기 전송 프로토콜(1225)에 전송하는 네트워크들은 상이한 송신기들에 대해 상이할 수 있는데, 예를 들어, 송신기들 중 몇몇은 3G 네트워크를 이용하여 전송할 수 있고, 다른 송신기들은 LTE를 이용할 수 있고, 다른 송신기들은 WiFi를 이용할 수 있다. 송신기들은 동일한 또는 상이한 유형의 상이한 오퍼레이터 네트워크들을 이용할 수 있는데, 예를 들어, 제 1 송신기는 AT&T 네트워크를 이용할 수 있는 반면, 제 2 송신기는 Verizon 네트워크를 이용할 수 있다. 수신기 전송 프로토콜(1225) 이전에 중간 수신 디바이스들이 존재할 수 있는데, 예를 들어, 제 1 송신기는 제 1 CDN에 의해 동작되는 제 1 서버에 전송할 수 있는 반면, 제 2 송신기는 제 2 CDN에 의해 동작되는 제 2 서버에 전송할 수 있고, 제 1 서버 및 제 2 서버는 자신들이 수신하는 것을 수신기 전송 프로토콜(1225)에 전송할 수 있다.

[0141] 다중경로 FEC-기반 인터리빙된 신뢰도 제어 프로토콜 방법이 이제 도 13과 관련하여 설명된다. 도 13은 예시적인 다중경로 신뢰도 제어 프로토콜 데이터 패킷 포맷 및 대응하는 피드백 정보 포맷을 예시하는 개념도이다.

[0142] 도 13의 상부에 도시된 바와 같이, 각각의 데이터 패킷은 플로우 식별자(FID)(1305), FID에 대한 시퀀스 번호(FID에 대한 SEQN)(1310), 소스 블록 번호(SBN)(1315), 소스 심볼들의 유닛들의 소스 블록 길이(SBL)(1318), 인코딩 심볼 식별자(인코딩 유닛 식별자로 또한 지칭됨)(ESI)(1320), 및 하나 이상의 인코딩 심볼들(1325)(인코딩 심볼들은 때때로 인코딩 유닛들로 지칭됨)을 포함한다. FID(1305)는 이러한 패킷이 전송될 경로 플로우를 식별하고, FID에 대한 SEQN(1310)은 이러한 플로우에 전송된 각각의 패킷에 대해 1만큼 증분되는 수이고, 따라서, FID에 대한 SEQN(1310)은 FID(1305)에 의해 스코핑(scope)된다.

[0143] SBN(1315)은, 이 패킷에서 반송되는 인코딩 심볼(들)(1325)이 어떤 소스 블록으로부터 생성되었는지를 식별하며, 여기서 SBN은 송신될 데이터의 각각의 후속 소스 블록을 일반적으로 1씩 증분시키는 수이다. SBL(1318)은 소스 블록 내의 소스 심볼들의 수를 식별한다. 패킷이 소스 심볼들을 반송할 때 SBL(1318)은 생략될 수 있는데, 이는, 예를 들어, 후술하는 개방형 소스 블록의 설명을 참조하여, 소스 블록의 소스 심볼들 중 적어도 일부가 전송되는 시간에 소스 블록 내의 소스 심볼들의 수가 알려져 있지 않은, 즉, 개방형 소스 블록의 경우일 수 있기 때문에 일부 애플리케이션들에 대해서는 바람직하다.

[0144] 대안적으로, SBL(1318)은 모든 데이터 패킷들에서 반송될 수 있지만, 소스 블록의 크기가 결정되기 전에 전송되는 소스 심볼들을 반송하는 패킷들에 대한 그 값이 0으로 설정될 수 있거나, 또는 SBL(1318)은 소스 심볼들을 반송하는 모든 패킷들에 대해 0으로 설정될 수 있거나, 또는 SBL(1318)은 소스 심볼들을 반송하는 패킷이 전송될 때 소스 블록 내의 소스 심볼들의 현재의 수로 설정될 수 있다. SBL(1318)은 복구 심볼들을 반송하는 모든 패킷들에 대한 소스 블록 내의 소스 심볼들의 수로 설정되는 것이 바람직하다. SBL(1318)은 또한 2개의 서브-필드들로 분할될 수 있는데, 일-비트 플래그는 소스 블록이 개방되는지 또는 폐쇄되는지 여부(즉, 패킷이 전송될 때 소스 블록 크기가 결정되지 않았다면(개방형 소스 블록) 플래그는 0으로 설정되고, 그리고 패킷이 전송될 때 소스 블록 크기가 결정되었다면(폐쇄 소스 블록) 플래그는 1로 설정됨)를 나타내고, SBL(1318)의 나머지 부분은 소스 블록 내의 소스 블록들의 수를 제공한다.

[0145] 전송자 피드백 로직 유닛(1420)은, 소스 블록의 마지막 소스 심볼을 반송하는 패킷 내에서 소스 블록이 폐쇄되었음을 나타내도록 이러한 SBL 플래그를 설정할 뿐만 아니라, 소스 블록이 이 소스 블록에 대한 복구 심볼들을 반송하는 모든 패킷들 내에 폐쇄되었음을 이러한 SBL 플래그를 통해 나타내며, 플래그가 소스 블록이 폐쇄되었음을 나타내는 각각의 패킷에서, SBL 크기는 폐쇄된 소스 블록 내의 실제 수의 소스 심볼들로 설정된다. ESI(1320)는 어떤 인코딩 심볼(들)(1325)이 SBN(1315)에 의해 식별된 소스 블록에 대한 이러한 패킷 내에서 반송되는지 식별하고, 이에 따라 ESI(1320)는 SBN(1315)에 의해 스코핑된다(scoped). 새로운 데이터 패킷이 특정 경로 플로우를 따라 전송되는 매번, 그 경로 플로우의 FID는 패킷 내부에 위치되고, 그 FID에 대한 SEQN은 1씩 증분되고 패킷 내부에 위치되며, 인코딩 심볼들이 전송되는 액티브 소스 블록의 SBN은 패킷 내부에 위치되고, 인코딩 심볼들의 대응 ESI는 패킷 내부에 위치되며, 인코딩 심볼들은 패킷 내부에 위치되고, 이들은 모두 패킷이 전송되기 전에 행해진다.

[0146] 수신기 전송 프로토콜(1225)은 전송자 전송 프로토콜(1215)에 전송될 피드백을 생성한다. 가능한 수신기 피드백 정보 포맷이 도 13의 하단에 도시된다. 도시된 바와 같이, 수신기 전송 프로토콜(1225)은 각각의 FID(1350(1), 1350(2))에 대해 그 FID(1355(1), 1355(2))에 대해 수신된 대응하는 가장 높은 SEQN을 다시 리포트한다. 이에 더해, 수신기 전송 프로토콜(1225)은, 각각의 액티브 소스 블록에 대해, 그 소스 블록(1365(1)), 1365(2))에 대해 지금까지 수신되었던 인코딩 심볼들의 수와 함께 그 소스 블록의 SBN(1360(1), 1360(2))을 다시 리포트한다.

[0147] 또한, 수신기 전송 프로토콜(1225)은 최저 액티브 소스 블록의 소스 블록 수(1370)를 다시 리포트한다. 수신기 전송 프로토콜(1225)에 의해 다시 리포트되었던 최저 액티브 SBN(1370)은, 최저 소스 블록 수를 갖는 현재의 액티브 소스 블록이 수신기 전송 프로토콜(1225)에 의해 충분한 확실성을 가지고 복원가능한 것으로 고려될 때 그리고 어떠한 추가적인 인코딩 심볼들도 현재 소스 블록에 대해 필요하지 않을 때 수신기 전송 프로토콜(1225)에 의해 일반적으로 증가되었고, 이에 따라 이러한 소스 블록은 수신기 전송 프로토콜(1225)에 의해 불활성으로서 지정된다. 또한, 충분한 인코딩 심볼들이 적절하게 충분한 방식으로 수신되지 않았을 경우의 상황들에서, 심지어는 수신기 전송 프로토콜에 의해 아직 복원되지 않았던 더 낮은 소스 블록 수들을 갖는 소스 블록들이 존재할 때조차도, 수신기 전송 프로토콜(1225)은 최저 액티브 SBN(1370)을 증가시킬 가능성이 있다.

[0148] 본 개시물을 판독할 때 다른 변형들도 가능하다는 것이 명백해야 한다. 시스템은, 도 13의 최상단에 도시된 것과 같은 전송자 다중경로 데이터 패킷 포맷 내의 최저 액티브 SBN을 전송자 전송 프로토콜(1215)이 시그널링하도록 허용하기 위해 증강될 수 있다. 예를 들어, 추가적인 파라미터 "최저 액티브 SBN"은 전송자 전송 프로토콜(1215)로부터 수신자 전송 프로토콜(1225)로의 이러한 시그널링을 허용하기 위해 도 13의 최상단에 도시된 바와 같은 다중경로 데이터 패킷 포맷에 부가될 수 있다. 다음으로, 이러한 기능은, 소스 블록들에 걸친 스킵핑을 전송자 전송 프로토콜(1215)이 시그널링하도록 허용하며, 그 소스 블록들에서는 시스템의 엔드-투-엔드 레이턴시 요건들을 충족할 수 있는 방식으로 이러한 소스 블록들의 전송 및 복원을 완료하는 것이 불가능할 수도 있다.

[0149] 앞서 수많은 변형들이 존재한다. 예를 들어, 바이트 범위는, 그 패킷 페이로드들에서 어떤 소스 데이터가 반송되는지 나타내기 위해 ESI 대신에 이용될 수 있다. 다른 예시로서, 패킷 페이로드에서 전송되는 임의의 FEC 데이터를 생성하기 위해 어떤 소스 데이터가 이용되는지 나타내기 위한 SBN 및 SBL 대신에, 패킷 페이로드에서 어떤 특정 데이터가 전송되는지 나타내기 위한 ESI와 함께, 전체 데이터의 스트림 내에서 블록의 바이트 범위가 이용될 수 있다. 다른 변형으로서, 상이한 블록들로부터의 인코딩 심볼들은 동일한 데이터 패킷 내에 포함될 수 있고, SBN, SBL, 및 ESI(또는 그들의 등가물들)의 다수의 3배수들이 데이터 패킷에서 반송되는 인코딩 심볼들을 식별하기 위해 패킷 헤더에 포함될 수 있다. 예를 들어, 각각의 액티브 소스 블록에 대해 패킷 내에서 운반되는 심볼들의 비율은, 각각의 이러한 소스 블록에 대해 현재 전송될 수 있는 심볼들의 수에 비례하도록 선택될 수 있는데, 즉, 액티브 블록 i에 대해 전송될 패킷 내의 심볼들의 비율은 L_i + X_i - U_i의 현재 값에 비례하도록 선택된다.

[0150] 도 14는 다중경로 스트리밍 전송기의 블록도를 약간 더 상세하게 도시한다. 도 1의 전송단 시스템(100)의 일부 또는 전부는 도 14의 다중경로 스트리밍 전송기와 유사한 컴포넌트들을 포함할 수 있다. 비디오 생성기(1205)에 의해 생성되는 비디오 스트림(1210)은, 도 14에 도시된 바와 같이, 전송기 전송 프로토콜(1215) 내 소스 데이터 버퍼(1405) 내에 임시로 저장된다. FEC 인코더(1410)는, 이미 형성된 소스 블록들에 대한 FEC 복구 심볼들을 생성하고 그리고 결과 FEC 복구 심볼들을, 이들이 송신을 위해 필요로 될 때까지, 복구 심볼 버퍼(1415)에 위치시킨다. FEC 인코더(1410)는, 액티브 소스 블록들이 송신을 위해 필요로 될 때 그들에 대한 복구 심볼들을 생성하는 필요 기준에 따라 동작할 수 있다. 대안적으로, FEC 인코더(1410)는 액티브 소스 블록들에 대한 복구 심볼들의 수를 사전-생성할 수 있으며, 이에 따라 이들은 필요에 따라 바로 전송되도록 그리고 또한 FEC 인코더(1410)에 호출들의 오버헤드를 감소시키도록 준비된다.

[0151] 소스 블록에 대한 추가적인 복구 심볼들을 생성하기 위한 FEC 인코더(1410)의 트리거링은, 추가적인 인코딩 심볼을 전송하는 것이 가능한 매번 어떤 추가 인코딩 심볼들을 전송할지 결정하는 전송기 피드백 로직 유닛(1420)으로부터의 신호에 의해 트리거될 수 있다. 따라서, 이러한 단계들은, 서버 디바이스에 블록에 필요한 추가적인 인코딩 유닛들의 수를 계산하는 단계, 및 서버 디바이스와 같은 전송 디바이스에 추가 인코딩 유닛들의 수를 나타내는 데이터를 전송하는 것을 포함하는 방법의 단계들의 예시들을 나타낸다.

[0152] 소스 블록은, 그러한 소스 블록의 시작 경계와 종료 경계 양자 모두가 결정되었을 때, 폐쇄형으로 간주되는데, 즉, 소스 블록 내의 데이터의 범위는 소스 블록이 폐쇄형일 때 결정되었고, 그리고 소스 블록은 데이터의 비디오 스트림의 콘텍스트스 내에 시작 바이트 인덱스 및 종료 바이트 인덱스를 갖는다. 예를 들어, 0부터 4,431의 인덱스들에서 바이트 인덱스들을 포함하는 소스 블록 내에 4,432 바이트의 데이터가 있는 경우, 제 1 소스 블록은 비디오 데이터 스트림 내의 바이트 인덱스(0)에서 시작할 수 있고, 바이트 인덱스(4,432)에서 종료할 수 있다. 이러한 예를 계속해보자면, 제 2 소스 블록은 바이트 인덱스(4,432)에서 시작하지만, 제 2 소스 블록의 종료 바이트 인덱스는, 소스 블록 생성기 유닛(1425)에 의해, 시점의 약간 이후 때까지 결정되지 않을 수 있고, 제 2 소스 블록에 대한 종료 바이트 인덱스가 결정될 때까지, 제 2 소스 블록은 개방형으로 간주된다.

[0153] 따라서, 일반적으로, 비디오 데이터 스트림은, 결정되는 중에 있는 프로세스 내에 있는 많아야 하나의 개방 소스 블록이 후속하는 폐쇄형 소스 블록들의 시퀀스로서 여겨질 수 있다. 또한, 소스 블록들의 시퀀스는, (전체 비디오 스트림이 성공적으로 전달되었을 때의 전달의 종료에서는 제외하고) 하나 이상의 액티브 소스 블록들이 후속하는 제로(zero) 이상의 인액티브 소스 블록들을 포함하며, 인액티브 소스 블록들은 수신기 전송 프로토콜(1225)로 성공적으로 전달되고, 수신기 전송 프로토콜(1225)로부터 전송된 피드백에 기초하여 전송기 전송 프로토콜(1215)로 성공적으로 전달되었다고 확인된 소스 블록들이거나, 전달하기에 너무 늦었다고 여겨지고 따라서 수신기에서 더이상 복원될 필요가 없는 소스 블록들이다. 소스 블록 생성기 유닛(1425)은, 언제 최근 액티브 소스 블록을 폐쇄할지 그리고 이에 따라 언제 새로운 액티브 개방 소스 블록을 시작할지를 결정한다. 시스템적인 FEC 코드들이 사용되는 경우, 즉, 소스 블록의 소스 심볼들이, FEC 디코더에 의해 소스 블록을 복원하는 데에 사용될 수 있는 인코딩 심볼들 사이에 있는 경우, 그러면 액티브 개방 소스 블록에 대해서 인코딩 심볼들, 구체적으로 소스 심볼들의 전송을 허용하는 것이 가능하고 바람직하다.

[0154] 많은 주지된 FEC 코드들, 예를 들어, IETF RFC 5510에 명시된 Reed-Solomon 코드들, 또는 IETF RFC 6330에 명시된 RaptorQ 코드들, 또는 IETF RFC 5053에 명시된 Raptor 코드들은 시스템적이다. 액티브 개방 소스 블록에 대해 소스 심볼들을 전송하는 것이 바람직한데, 이는, 그러한 전송이, 비디오 스트림의 전달의 종료-대-종료 레이턴시를 감소시킬 수 있을 뿐만 아니라, 동일한 종료-대-종료 레이턴시 예산 내에서 더 높은 품질과 신뢰성 전달을 제공할 수 있기 때문이다. 장점이 있는 하나의 이유는, 심지어 전체 소스블록이 이용 가능하거나 그 크기가 알려지기 전에도 소스 블록의 전달이 시작할 수 있기 때문이다. 전송기 피드백 로직 유닛(1420) 방법들에 따라, 일단 액티브 개방 소스 블록이 소스 블록 생성기 유닛(1425)에 의해 폐쇄되면, 이러한 소스 블록에 대한 복구 심볼들은 FEC 인코더(1410)에 의해 생성될 수 있고 복구 심볼 버퍼(1415)에 저장될 수 있으며, 이러한 소스 블록에 대한 부가적인 인코딩 심볼들이 전송되어야 할 때 송신될 수 있다.

[0155] 대안적으로, 복구 심볼 버퍼(1415)가 없을 수 있고, 전송기 피드백 로직 유닛(1420) 방법들에 따라, 이러한 소스 블록에 대한 부가적인 인코딩 심볼들이 전송되어야 할 때, FEC 인코더(1410)가, 즉각적인 송신에 대해 그때 그때(on the fly) 복구 심볼들을 생성할 수 있다. 도 16은 인액티브 및 액티브 소스 블록들뿐만 아니라 폐쇄형 소스 블록들(인액티브 및 액티브 소스 블록들의 혼합) 및 많아야 하나의 (액티브인) 개방 소스 블록을 도시한다.

[0156] 소스 블록 생성기 유닛(1425)은, 언제 현재의 액티브 개방 소스 블록을 폐쇄하고 다음의 액티브 개방 소스 블록을 시작할지를 결정하기 위해, 다양한 방법들을 사용할 수 있다. 예를 들어, 소스 블록 생성기 유닛(1425)은, 현재의 액티브 개방 소스 블록에 대한 인코딩 심볼들을 포함하는 제 1 패킷이 전송되었던 시점 또는 그러한 시점 이후에 전송된 패킷이 수신되었다고 나타내는 수신기 피드백 로직 유닛(1525)으로부터 피드백을 수신한 전송기 피드백 로직 유닛(1420)으로부터 정보를 수신할 때, 현재 액티브 개방 소스 블록을 폐쇄하는 것을 결정할 수 있다. 이러한 시점은, 인코딩 심볼들을 포함하는 제 1 패킷이 현재 액티브 개방 소스 블록으로부터 전송되는 시간에서의 플로우들의 각각에 대한 현재의 시퀀스 번호를 기록함으로써, 그리고 그 후, 기록 시간에서 적어도, 플로우에 대한 현재의 시퀀스 번호만큼 높은, 플로우에 대한 가장 높은 시퀀스 번호를 가지고 전송기 피드백 로직 유닛(1420)이 수신기 피드백 로직 유닛(1525)으로부터 피드백을 수신하자 마자 소스 블록 생성기 유닛(1425)에 대한 표시가 제공되는 것을 결정함으로써, 전송기 피드백 로직 유닛(1420)에 의해 결정될 수 있다.

[0157] 이러한 방법을 사용하여, 소스 블록이 폐쇄되고 소스 블록의 크기가 결정되는 때의 현재 액티브 개방 소스 블록의 크기는 대략 데이터의 RTT 양이다. 대안적으로, 소스 블록 생성기 유닛(1425)은 고정된 양의 시간 이후에, 예를 들어, 이전 소스 블록이 폐쇄된 이후 1초 이후에 현재 액티브 개방 소스 블록을 폐쇄하는 것을 결정할 수 있다. 이러한 경우에, 전송 레이트가 가변이라면, 각각의 소스 블록이 상이한 크기일 가능성이 있고, 반면에 전송 레이트가 고정이라면, 소스 블록들은 대략 동일한 크기일 가능성이 있다. 다른 대안으로서, 현재의 액티브 개방 소스 블록은, 개방 소스 블록의 크기가 미리 정해진 크기, 예를 들어, 100,000 바이트에 도달하자 마자, 소스 블록 생성기 유닛(1425)에 의해 폐쇄될 수 있다.

[0158] 다른 대안들로서, 소스 블록 생성기 유닛(1425)은 현재의 액티브 개방 소스 블록을 폐쇄하기 위해 상기 방법들의 조합들을 사용할 수 있는데, 예를 들어, 소스 블록의 크기가 미리 정해진 크기에 도달하자마자 또는 이전 소스 블록이 폐쇄된 후에 미리 정해진 시간의 양이 지나갈 때까지 중에서 어느 한쪽이 먼저 발생할 때, 소스 블록을 폐쇄한다. 다른 예로서, 소스 블록 생성기 유닛(1425)은, 소스 블록에 대한 피드백의 표시가, 전송기 피드백 로직 유닛(1420)으로부터 소스 블록 생성기 유닛(1425)으로 먼저 표시되거나, 또는 이전 소스 블록의 폐쇄 이후에 고정된 양의 시간이 지나간 이후 중에서 어느 한 쪽이 먼저 발생할 때, 현재의 액티브 개방 소스 블록을 폐쇄할 수 있다.

[0159] 도 14의 전송기 피드백 로직 유닛(1420)은 도 15의 수신기 피드백 로직 유닛(1525)으로부터 수신된, 도 13의 하단부에 도시된 포맷으로 제공되는 피드백을 핸들링한다. 전송기 피드백 로직 유닛(1420)은 액티브 소스 블록들의 세트를 수신된 최저 액티브 SBN(1370)에 기초하여 업데이트한다. 전송기 피드백 로직 유닛(1420)은 언제 비디오 스트림에 대한 다음 데이터 패킷을 전송할지, 어떤 경로 플로우로 다음 데이터 패킷을 전송할지, 그리고 어떤 액티브 소스 블록(또는 다수의 소스 블록들)으로부터 데이터 패킷 내의 인코딩 심볼들을 전송할지를 결정한다. 전송기 피드백 로직 유닛(1420)은 어떤 액티브 소스 블록이 후속하는 것으로부터 다음 인코딩 심볼을 전송할지를 결정할 수 있다.

[0160] 이전에 사용된 것에 유사한 표기를 사용하여, SBN=I을 갖는 각각의 액티브 소스 블록에 대해, BI는, 어떠한 원하는 레벨의 확실성으로 소스 블록(I)을 복원하기 위해 수신되어야 하는 인코딩 심볼들의 수이게 한다. 예컨대, 예를 들어, IETF RFC 5510에 설명된 바와 같은 Reed-Solomon FEC 코드를 사용하여, BI의 값은 소스 블록의 소스 심볼들의 수와 동일할 수 있고, 전체 소스 블록의 복원은 완전한 확실성을 가지며, 반면에 다른 코드들, 예를 들어, IETF RFC 6330에 설명된 RaptorQ 코드들에 대해서는, BI의 값은, 거의 확실하게 소스 블록의 소스 심볼들의 수와 동일할 수 있고 더 큰 값들의 BI는 개선된 확실성을 허용한다.

[0161] 전송기 피드백 로직 유닛(1420)은 BI에 대한 값을 소스 블록(I)의 소스 심볼들의 수와 사용하는 FEC 코드의 특성들에 기초하여 계산할 수 있다. 전송기 피드백 로직 유닛(1420)은 RI를, 전송기 피드백 로직 유닛(1420)이 소스 블록(I)에 대해 수신기 피드백 로직 유닛(1525)으로부터 수신했던, 수신된 인코딩 심볼들(1365)의 번호의 가장 높은 값으로 계산할 수 있다. 전송기 피드백 로직 유닛(1420)은 LI=BI-RI를 계산할 수 있고, 이는, 어떠한 특정된 레벨의 확신성으로 소스 블록(I)을 복원하기 위해, 전송기가 인지하는 수가 수신기에 의해 수신된 것에 부가하여 수신기가 수신해야 하는 부가적인 인코딩 심볼들의 수이다.

[0162] UI를, 소스 블록 I에 대해 전송되었지만 수신기에서 그에 대한 어떠한 확인응답도 아직 전송기로부터 수신되지 않은 인코딩 심볼들의 수라고 가정한다. 전송기 피드백 로직 유닛(1420)은, 후속하는 바로서 수신기 피드백 로직 유닛(1525)으로부터 수신된 피드백에 기초하여 UI를 계산할 수 있다. 각각의 플로우 ID 값 J에 대해, 전송기 피드백 로직 유닛(1420)은, 전송기에 의해 FID = J에 대해 전송된 현재 시퀀스 번호 C로부터 아래로, 전송기 피드백 로직 유닛(1420)이 도 13의 하단에 도시된 피드백 정보 포맷으로 수신기 피드백 로직 유닛(1525)으로부터 수신한 FID = J에 대한 최고 시퀀스 번호 S까지 사이의 FID = J에 대한 시퀀스 번호들의 범위에서, 소스 블록 I에 대해 전송된 인코딩 심볼들의 수를 결정할 수 있다. 전송기 피드백 로직 유닛(1420)은, FID = J에 대해 S로부터 C까지 범위 내의 각각의 시퀀스 번호 K에 대해, 소스 블록 I에 대한 얼마나 많은 인코딩 심볼들이 FID = J 및 시퀀스 번호 K를 갖는 패킷으로 전달되었는지를 세이브함으로써 이러한 계산을 행할 수 있다.

[0163] 이에 기초하여, 전송기 피드백 로직 유닛(1420)은, 소스 블록 I가 경로 플로우 J에 전송한 시퀀스 번호들 S+1 내지 C-1 범위 내의 그러한 인코딩 심볼들의 수를 합산할 수 있다. 그 후, 전송기 피드백 로직 유닛(1420)은, 소스 블록 I에 대해, 얼마나 많은 인코딩 심볼들 UI가 전송되었지만 아직 확인응답되지 않았는지 그 총계를 결정하기 위해, 상이한 경로 플로우들에 걸쳐 이들 양들을 합산 할 수 있다. 각각의 플로우 또는 경로에 대한 플로우 시퀀스 번호들 및 플로우 식별자들, 및 본 명세서에 설명된 방법들을 사용하여 피드백 정보에 그리고 데이터 패킷들에 제공된 정보는, 각각의 경로에 대한 전송되었지만 아직 확인응답(손실됨 또는 수신됨 중 어느 하나)되지 않은 인코딩 심볼들의 수를 전송기가 정확히 계산하게 하며, 그에 따라, 전송되었지만 아직 확인응답되지 않은 모든 경로들에 걸친 인코딩 심볼들의 어그리게이트 수를 전송기가 정확히 추정하게 함을 유의한다. 전송기 추정 정확도는, 패킷들이 경로에 전송된 순서와 (손실되지 않았다면) 패킷들이 경로로부터 수신된 순서 사이에 거의 차이가 없는 경우에 높으며, 이러한 경우가 일반적이다. 앞서 언급된 바와 같이, 어느 경로를 통해 패킷들이 전송되는지를 고려하지 않은 다수의 경로들을 통한 패킷들의 어그리게이트 전송 및 수신 순서는 매우 상이할 수 있다. 따라서, 정보 및 피드백을 경로마다 제공하고 사용하는 것의 이점들 중 하나는, 리던던트 데이터를 전송하는 것을 최소화하고, 스트림 블록들의 복원의 단대단 레이턴시를 최소화하기 위해 어그리게이트로 얼마나 많은 데이터가 전송되어야 하는지를 전송기가 더 정확히 추정하게 하는 것이다. 따라서, 전송기 피드백 로직에 의해 수신된 데이터는, 패킷 손실, 다양한 데이터 스루풋들, 및 경로 레이턴시들을 경험할 수 있는 복수의 병렬 네트워크 경로들을 통해 데이터가 신뢰가능하게 스트리밍될 경우의 경로 특정 정보를 추적 및 보고 및 사용하는 예를 표현한다.

[0164] 이전과 같이, XI를, 전송기 피드백 로직 유닛(1420)이 소스 블록 I에 대해 사전적으로 전송될 수 있다고 결정한 인코딩 심볼들의 수라고 가정한다. 전송기는, 예를 들어, XI가 BI의 몇몇 고정 분율(예를 들어, XI = 0.05*BI)이라는 특정한 규칙들 또는 전술된 바와 유사한 다른 규칙들에 기초하여 XI의 값을 계산할 수 있다. 그 후, 전송기 피드백 로직 유닛(1420)은, LI + XI - UI > 0이면, 다른 인코딩 심볼이 액티브 폐쇄 소스 블록 I에 대해 전송될 수 있다고 결정한다.

[0165] 데이터 레이트 레귤레이터 유닛(1430)은, 각각의 플로우에 대해 다음 데이터 패킷이 그 플로우에 전송될 수 있는 경우를 결정한다. 데이터 레이트 레귤레이터 유닛(1430)은 이러한 결정을 행하기 위해 각각의 송신기(1220(1), 1220(2) 등)와 통신한다. 예를 들어, UDP 데이터 패킷들이 송신되면, 송신기(1220(1))는 그것의 사이즈를 결정할 수 있으며, Linux 또는 몇몇 다른 Unix-유형 동작 시스템이 사용되면 UDP는 TIOCOUTQ ioctl()을 갖는 큐를 전송한다. 전송 큐 사이즈를 모니터링함으로써, 송신기(1220(1))는, 송신기(1220(1))에서의 버퍼링이 초과되는 것을 회피할 수 있고, 오직 송신기(1220(1)) 내부 전송기 큐가 로우인 경우에만 항상 새로운 출력 패킷들을 큐잉하며, 그에 따라, 송신기(1220(1))가 전송되지 않은 데이터를 너무 많이 축적시키는 것을 회피한다. 송신기(1220(1)) 전송 큐가 비어있지는 않게, 그렇지만 적게 유지되면, 완전한 전송 스루풋이 달성될 수 있다. 따라서, 각각의 플로우에 대한 각각의 송신기(1220(1))는, 송신기가 송신을 위해 다른 데이터 패킷을 수용할 수 있는 때를 데이터 레이트 레귤레이터 유닛(1430)에 표시하며, 그 포인트에서, 데이터 레이트 레귤레이터 유닛(1430)은, 송신기(1220(1))와 연관된 플로우에 데이터 패킷을 전송할 수 있다고 결정한다. 데이터 레이트 레귤레이터 유닛(1430)은, 가능한 송신기들(1220(1), 1220(2) 등) 각각으로부터 표시들을 수신하고, 위의 방법을 사용하여, 각각의 가능한 플로우에 대해, 그 플로우에 대한 다음 데이터 패킷이 전송될 수 있는 때를 결정한다.

[0166] 대안적으로 또는 부가적으로, 송신기(1220(1))는, SO_SNDBUF 값을 사용하여 전송기 윈도우 사이즈를 충분히 작은 값으로 설정할 수 있다. 그 후, 송신기(1220(1))와 연관된 플로우에 대해 다른 데이터 패킷을 전송하는 것이 가능한 때를 결정하기 위해, 예를 들어, select() 또는 poll() 시스템 호들을 사용함으로써 UDP 소켓이 기입가능하게 되는 것을 대기할 수 있다. 이러한 방식에서, 송신기 전송기 큐의 사이즈는 끊임없이 폴링(poll)될 필요가 없다.

[0167] 모든 송신기들(1220(1), 1220(2) 등)은, 다른 데이터 패킷을 송신기와 연관된 플로우에 전송할 용량을 갖는다고 송신기가 표시한 경우, 어느 데이터 패킷들이 각각의 송신기(1220(1), 1220(2) 등)에 전송되어야 하는지를 결정하는 데이터 레이트 레귤레이터 유닛(1430)과 통신하고 있을 수도 있다. 송신기들(1220(1), 1220(2) 등)과 데이터 레이트 레귤레이터 유닛(1430) 사이의 통신은, 높은 대역폭, 낮은 레이턴시, 및 낮은 패킷 손실을 갖는 로컬 네트워크 상에서 발생할 수도 있으며, 따라서, 통신이 TCP를 사용한다면 전체적으로 충분할 수도 있다. 그러한 설정에서, 그 후, 송신기는 다음의 루프를 무기한으로 반복하여 실행한다.

1. (상술된 바와 같이, TIOCOUTQ를 모니터링하거나 또는 로우 전송 버퍼 및 select()를 사용하는 것 중 어느 하나, 또는 둘 모두를 행함으로써) 송신기 전송 큐가 로우일 때까지 대기함.

2. 새로운 패킷에 대한 요청을 데이터 레이트 레귤레이터 유닛(1430)에 전송함(예를 들어, 데이터 레이트 레귤레이터 유닛(1430)으로의 send() 또는 write()).

3. 전송할 데이터 패킷을 포함하는 데이터 레이트 레귤레이터 유닛(1430)으로부터의 응답을 대기함(예를 들어, select()을 사용함).

4. (예를 들어, send() 또는 write() 시스템 호를 사용함으로써) 데이터 패킷을 UDP를 통해 네트워크(1222)에 전송함.

데이터 레이트 레귤레이터 유닛(1430)은 다음을 무기한으로 반복하여 행한다.

1. (예를 들어, select()을 사용하여) 임의의 송신기로부터의 요청을 대기함.

2. 전송할 새로운 데이터 패킷을 요청한 각각의 송신기에 대해, 전송할 새로운 데이터 패킷을 구성하고, 그 새로운 데이터 패킷을 송신기에 제공함.

[0168] 또한, 데이터 레이트 레귤레이터 유닛(1430)은, 생성되는 비디오 스트림 데이터 레이트를 증가시키거나, 생성되는 비디오 스트림 데이터 레이트를 감소시키거나, 또는 비디오 데이터 레이트를 동일하게 유지하기 위해, 비디오 생성기(1205)에 정보를 제공할 수 있으며, 여기서, 이러한 정보는, 예를 들어, 소스 데이터 버퍼(1405) 내의 데이터의 양, 및 데이터 레이트 레귤레이터 유닛(1430)이 상이한 플로우들을 따라 어그리게이트로 데이터 패킷들을 전송하는 레이트에 기초할 수 있다.

[0169] 전송기 피드백 로직 유닛(1420)은, 아직 전송되지 않은, 전송되기 위해 이용가능한 소스 블록 I의 적어도 하나의 소스 심볼이 존재한다면, 액티브 개방형 소스 블록 I에 대한 다른 인코딩 심볼이 전송될 수 있음을 결정한다. 전송기 피드백 로직 유닛(1420)은, 인코딩 심볼들을 반송하는 다음 데이터 패킷이 전송될 것임을 데이터 레이트 레귤레이터 유닛(1430)이 나타낼 때에 논리적으로 이용가능한 모든 피드백 및 송신 정보를 이용하여 위의 계산들 모두를 수행한다(비록 전송기 피드백 로직 유닛(1420)이 다음 데이터 패킷이 전송될 시간 이전의 임의의 순간에 계산들 중 일부 또는 모두를 수행할 수 있을 지라도). 다음 데이터 패킷이 특정 플로우로 전송될 것임을 데이터 레이트 레귤레이터 유닛(1430)이 나타낼 때, 전송기 피드백 로직 유닛(1420)은, I가 전송기 피드백 로직 유닛(1420)에 의해 위에 설명된 바와 같이 결정되는 그 때에 인코딩 심볼들이 전송될 수 있는 모든 액티브 소스 블록들 중 가장 낮은 소스 블록 번호이도록, 액티브 소스 블록 I를 결정하고, 이어서 소스 블록 I에 대한 하나 이상의 인코딩 심볼들이 상기 다음 데이터 패킷에 놓이고, 그것이 그 플로우로 전송된다.

[0170] 도 14의 다양한 논리 블록들 중 임의의 블록 또는 모든 블록들이 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합으로 구현될 수 있다. 소프트웨어 또는 펌웨어로 구현될 때는, 필요한 하드웨어가 또한 제공될 수 있는데, 이를테면 하나 이상의 컴퓨터-판독가능 매체들이 설명된 기능을 수행하기 위한 명령들 및 그 명령들을 실행하기 위한 하나 이상의 프로세싱 유닛들을 포함한다는 것이 이해될 것이다.

[0171] 이러한 방식으로, 도 14는, 병렬 네트워크 경로들 중 제 1 경로를 통해 제 1 블록에 대한 제 1 인코딩 유닛을 전송하고, 제 1 인코딩 유닛을 전송한 후에는, 제 1 경로를 통해 제 2 블록에 대한 제 2 인코딩 유닛을 전송하며, 제 2 인코딩 유닛을 전송한 후에는, 제 1 경로를 통해 제 1 블록에 대한 제 3 인코딩 유닛을 전송하도록 구성되는 하나 이상의 프로세서들을 포함하는 디바이스의 예를 나타낸다.

[0172] 도 15는 예시적인 다중경로 스트리밍 수신기를 더 상세히 예시하는 블록도이다. 도 1의 수신단 시스템들(160) 중 임의의 수신단 시스템 또는 모든 수신단 시스템들은 도 15의 다중경로 스트리밍 수신기와 유사한 컴포넌트들을 포함할 수 있다. 플로우 1(1220(1))에 대해 송신기에 의해 전송된 패킷들은 플로우 1(1505(1))에 대해 대응하는 수신기에 의해 수신되고(만약 그 패킷들이 송신과 수신 사이에 분실되지 않는다면), 다른 플로우들에 대해서도 이와 마찬가지다. 모든 수신된 패킷들은 수신기 전송 프로토콜(1225)에 의해서 수신 데이터 버퍼(1505)로 어그리게이팅된다. FEC 디코더(1510)는 충분한 인코딩 심볼들이 소스 블록을 복원하기 위해 수신되어진 액티브 소스 블록들을 복원하기 위해서 실행되고, 복원된 소스 블록들은 증가적인 소스 블록 번호의 바람직한 순서로 그 복원된 소스 데이터 버퍼(1520)에 놓여서, 복원된 비디오 스트림(1230)이 본래 비디오 스트림(1210)과 동일한 순서로 놓인다.

[0173] 수신기 피드백 로직 유닛(1525)은 수신 데이터 버퍼(1505)의 수신된 패킷들을 모니터링하고, 대응하는 전송기 피드백 로직 유닛(1420)에 전송되는 피드백 정보를 예를 들어 도 13의 하단에 도시된 포맷으로 생성한다. 수신기 피드백 로직 유닛(1525)은 또한, 소스 블록에 대해 수신되는 모든 데이터 패킷들 중 수신된 최대 SBL(1318) 값들에 기초하여 그리고 또한 어쩌면 소스 블록이 개방되거나 폐쇄되는지 여부를 나타내는 SBL 플래그에 기초하여, 그 소스 블록이 복원될 수 있는 때를 결정할 수 있고, 따라서 수신기 피드백 로직 유닛(1525)은 소스 블록이 복원될 수 있다고 결정될 때 FEC 디코더(1510)를 인보크할 수 있다. 일반적으로는, 예를 들어 소스 블록이 폐쇄되었음을 나타내는 (만약 존재한다면) SBL 플래그에 의해서나 또는 소스 블록이 폐쇄되었다는 묵시적인 표시를 제공하는 소스 블록에 대한 복구 심볼들을 반송하는 패킷들을 수신함으로써 결정될 때, 수신기 피드백 로직 유닛이 소스 블록이 폐쇄되었다는 표시를 수신하지 않은 경우에는, 수신기 피드백 로직 유닛(1525)이 소스 블록이 복원가능함을 선언하지 않는다는 것이 바람직하다.

[0174] 소스 블록이 복원될 수 있을 때 또는 소스 블록이 예를 들어 단대단 시간 제약으로 인해 생략될 때, 수신기 피드백 로직 유닛(1525)은 전송기 피드백 로직 유닛(1420)에 제공되는 피드백 정보의 가장 낮은 액티브 SBN(1370)을 적절히 더 높은 SBN 값으로 리셋할 수 있다. 수신기 피드백 로직 유닛(1525)은 각각의 액티브 소스 블록에 대해서 그 소스 블록에 대한 수신된 인코딩 심볼들의 수를 결정한다. 수신기 피드백 로직 유닛(1525)은, 각각의 플로우에 대해, 그 플로우에 대해 수신된 가장 높은 시퀀스 번호를 결정한다. 이런 정보 모두는 예를 들어 도 13의 하단에 제공되는 수신기 다중경로 피드백 정보 포맷을 사용하여, 수신기 피드백 로직 유닛(1525)으로부터 전송기 피드백 로직 유닛(1420)으로 연속적인 방식에 기초하여 전송된다.

[0175] 도 15의 다양한 논리 블록들 중 임의의 블록 또는 모든 블록들은 하드웨어, 소프트웨어, 펌웨어 또는 이들의 조합으로 구현될 수 있다. 소프트웨어 또는 펌웨어로 구현될 때는, 필요한 하드웨어가 또한 제공될 수 있는데, 이를테면 하나 이상의 컴퓨터-판독가능 매체들이 설명된 기능을 수행하기 위한 명령들 및 그 명령들을 실행하기 위한 하나 이상의 프로세싱 유닛들을 포함한다는 것이 이해될 것이다.

[0176] 이러한 방식으로, 도 15는, 병렬 네트워크 경로들 중 제 1 경로를 통해 제 1 블록에 대한 제 1 인코딩 유닛을 수신하고, 제 1 인코딩 유닛을 수신한 후에는, 제 1 경로를 통해 제 2 블록에 대한 제 2 인코딩 유닛을 수신하며, 제 2 인코딩 유닛을 수신한 후에는, 제 1 경로를 통해 제 1 블록에 대한 제 3 인코딩 유닛을 수신하도록 구성되는 하나 이상의 프로세서들을 포함하는 디바이스의 예를 나타낸다.

[0177] 이러한 방식으로, 도 15는, 복수의 병렬 네트워크 경로들을 통해 순방향-에러 정정 데이터를 서버 디바이스로부터 수신하고, 네트워크 경로들 각각을 통한 데이터의 손실들을 결정하며, 네트워크 경로들 각각을 통한 데이터의 손실들을 나타내는 데이터를 서버 디바이스에 전송하도록 구성되는 하나 이상의 프로세서들을 포함하는 디바이스의 예를 나타낸다.

[0178] 예에 따라, 본 명세서에서 설명되는 임의의 기술들의 특정한 동작들 또는 이벤트들은 상이한 시퀀스로 수행될 수 있고, 모두 추가, 병합 또는 제거될 수 있음을 인식해야 한다 (예를 들어, 기술들의 실시를 위해 모든 설명된 동작들 또는 이벤트들이 필수적인 것은 아니다). 아울러, 특정한 예들에서, 동작들 또는 이벤트들은 순차적이기보다는 동시에, 예를 들어, 멀티-스레딩된 프로세싱, 인터럽트 프로세싱 또는 다수의 프로세서들을 통해 수행될 수 있다.

[0179] 하나 이상의 예들에서, 설명된 기능들은, 하드웨어, 소프트웨어, 펌웨어 또는 이들의 임의의 조합으로 구현될 수 있다. 소프트웨어로 구현되면, 기능들은, 컴퓨터-판독가능 매체 상의 하나 이상의 명령들 또는 코드 상에 저장될 수 있거나 이를 통해 송신될 수 있고, 하드웨어-기반 프로세싱 유닛에 의해 실행될 수 있다. 컴퓨터-판독가능 매체는, 데이터 저장 매체와 같은 유형의 매체에 대응하는 컴퓨터-판독가능 저장 매체, 또는 예를 들어, 통신 프로토콜에 따라 일 장소로부터 다른 장소로의 컴퓨터 프로그램의 전송을 용이하게 하는 임의의 매체를 포함하는 통신 매체를 포함할 수 있다. 이러한 방식으로, 컴퓨터-판독가능 매체는 일반적으로 (1) 비일시적인 유형의 컴퓨터-판독가능 저장 매체 또는 (2) 신호 또는 반송파와 같은 통신 매체에 대응할 수 있다. 데이터 저장 매체는, 본 개시에서 설명되는 기술들의 구현을 위해 명령들, 코드 및/또는 데이터 구조들을 리트리브하기 위해 하나 이상의 컴퓨터들 또는 하나 이상의 프로세서들에 의해 액세스될 수 있는 임의의 이용가능한 매체일 수 있다. 컴퓨터 프로그램 물건은 컴퓨터-판독가능 매체를 포함할 수 있다.

[0180] 예를 들어, 이러한 컴퓨터-판독가능 저장 매체는 RAM, ROM, EEPROM, CD-ROM 또는 다른 광학 디스크 저장소, 자기 디스크 저장 또는 다른 자기 저장 디바이스들, 플래쉬 메모리 또는 명령들 또는 데이터 구조들의 형태로 요구되는 프로그램 코드를 저장하는데 사용될 수 있고, 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함하지만, 이들로 제한되는 것은 아니다. 또한, 임의의 연결 수단(connection)이 컴퓨터-판독가능 매체로 적절히 지칭된다. 예를 들어, 명령들이 웹사이트, 서버, 또는 다른 원격 소스로부터 동축 케이블, 광섬유 케이블, 연선(twisted pair), 디지털 가입자 라인(DSL), 또는 적외선, 라디오, 및 마이크로웨이브와 같은 무선 기술들을 이용하여 송신되는 경우, 동축 케이블, 광섬유 케이블, 연선, DSL, 또는 적외선, 라디오, 및 마이크로웨이브와 같은 무선 기술들이 이러한 매체의 정의에 포함된다. 그러나, 컴퓨터-판독가능 저장 매체 및 데이터 저장 매체는 접속들, 반송파들, 신호들 또는 다른 일시적 매체를 포함하지 않지만, 그 대신 비일시적 유형의 저장 매체에 관한 것임을 이해해야 한다. 여기서 사용되는 디스크(disk) 및 디스크(disc)는 컴팩트 디스크(disc(CD)), 레이저 디스크(disc), 광 디스크(disc), 디지털 다기능 디스크(disc)(DVD), 플로피 디스크(disk), 및 블루-레이 디스크(disc)를 포함하며, 여기서 디스크(disk)들은 데이터를 보통 자기적으로 재생하지만, 디스크(disc)들은 레이저들을 이용하여 광학적으로 데이터를 재생한다. 상기한 것들의 조합들 또한 컴퓨터-판독가능 매체의 범위 내에 포함되어야 한다.

[0181] 명령들은, 하나 이상의 디지털 신호 프로세서들(DSP들), 범용 마이크로프로세서들, 주문형 집적 회로들(ASIC들), 필드 프로그래머블 로직 어레이들(FPGA들), 또는 다른 균등한 집적 또는 이산 로직 회로와 같은 하나 이상의 프로세서들에 의해 실행될 수 있다. 따라서, 본 명세서에서 사용되는 바와 같은 용어 "프로세서"는, 전술한 구조 또는 본 명세서에서 설명되는 기술들의 구현에 적합한 임의의 다른 구조 중 임의의 구조를 지칭할 수 있다. 또한, 일부 양상들에서, 본 명세서에서 설명된 기능은, 인코딩 및 디코딩을 위해 구성되거나 결합된 코덱으로 통합된 전용 하드웨어 및/또는 소프트웨어 모듈들 내에서 제공될 수 있다. 또한, 기술들은 하나 이상의 회로들 또는 로직 엘리먼트들에서 완전히 구현될 수 있다.

[0182] 본 개시의 기술들은, 무선 핸드셋을 포함하는 광범위한 디바이스들 또는 장치들, 집적 회로(IC) 또는 IC들의 세트(즉, 칩 셋)에서 구현될 수 있다. 다양한 컴포넌트들, 모듈들 또는 유닛들은, 개시된 기술들을 수행하도록 구성된 디바이스들의 기능적 양상들을 강조하기 위해 본 개시에서 설명되지만, 상이한 하드웨어 유닛들에 의한 실현을 반드시 요구하는 것은 아니다. 오히려, 앞서 설명된 바와 같이, 다양한 유닛들은, 적절한 소프트웨어 및/또는 펌웨어와 함께, 앞서 설명된 하나 이상의 프로세서들을 포함하는 상호협력적 하드웨어 유닛들의 집합에 의해 제공되거나 코덱 하드웨어 유닛에서 결합될 수 있다.

[0183] 다양한 예들이 설명되었다. 이러한 예들 및 다른 예들은 하기 청구항들의 범위 내에 있다.

Claims (25)

1. 명령들이 저장된 컴퓨터-판독가능 저장 매체로서,
   상기 명령들은 실행되는 경우, 클라이언트 디바이스의 프로세서로 하여금,
   순방향-에러 정정된 데이터를 서버 디바이스로부터 복수의 병렬 네트워크 경로들을 통해 수신하게 하고;
   상기 네트워크 경로들 각각을 통한 상기 데이터의 손실들을 결정하게 하고; 그리고
   상기 데이터의 손실들을 표현하는 데이터를 상기 네트워크 경로들 각각을 통해 상기 서버 디바이스에 전송하게 하는, 컴퓨터-판독가능 저장 매체.
2. 제 1 항에 있어서,
   상기 프로세서로 하여금, 상기 손실들을 표현하는 데이터를 전송하게 하는 명령들은, 상기 프로세서로 하여금, 인코딩 유닛들이 수신된 복수의 블록들 각각을 식별하는 데이터, 상기 블록들 각각에 대해 요구되는 인코딩 유닛들의 수들, 및 상기 블록들 각각과 관련된 네트워크 패킷들에 대해 수신된 최고 시퀀스 번호들을 정의하는 데이터를 전송하게 하는 명령들을 포함하는, 컴퓨터-판독가능 저장 매체.
3. 제 1 항에 있어서,
   상기 프로세서로 하여금, 상기 손실들을 표현하는 데이터를 전송하게 하는 명령들은, 상기 프로세서로 하여금, 상기 병렬 네트워크 경로들 각각에 대해, 각각의 병렬 네트워크 경로를 통해 수신된 패킷 플로우에 대해 수신된 최고 시퀀스 번호를 식별하는 데이터를 전송하게 하는 명령들을 포함하는, 컴퓨터-판독가능 저장 매체.
4. 제 1 항에 있어서,
   수신된 데이터는, 데이터의 블록에 대한 다수의 인코딩 유닛들을 포함하고,
   상기 프로세서로 하여금, 상기 네트워크 경로들 각각을 통한 상기 데이터의 손실들을 표현하는 데이터의 어그리게이션에 기초하여, 데이터의 블록에 대한 하나 이상의 추가적인 인코딩 유닛들을 수신하게 하는 명령들을 더 포함하는, 컴퓨터-판독가능 저장 매체.
5. 제 1 항에 있어서,
   수신된 데이터는, 데이터의 블록에 대한 다수의 인코딩 유닛들을 포함하고,
   상기 프로세서로 하여금,
   상기 서버 디바이스로의 상기 블록에 대해 요구되는 추가적인 인코딩 유닛들의 수를 계산하게 하고;
   상기 추가적인 인코딩 유닛들의 수를 표현하는 데이터를 상기 서버 디바이스에 전송하게 하는 명령들을 더 포함하는, 컴퓨터-판독가능 저장 매체.
6. 제 5 항에 있어서,
   상기 추가적인 인코딩 유닛들의 수를 표현하는 데이터는, 상기 네트워크 경로들 각각을 통한 상기 데이터의 손실들을 표현하는 데이터를 포함하는, 컴퓨터-판독가능 저장 매체.
7. 제 5 항에 있어서,
   상기 프로세서로 하여금, 상기 추가적인 인코딩 유닛들의 수를 계산하게 하는 명령들은,
   상기 프로세서로 하여금,
   상기 블록의 크기 및 상기 블록에 대한 수신된 인코딩 유닛들의 크기들에 기초하여, 상기 블록을 복원하기 위해 요구되는 인코딩 유닛들의 수를 계산하게 하고; 그리고
   상기 추가적인 인코딩 유닛들의 수를, 상기 블록을 복원하기 위해 요구되는 인코딩 유닛들의 수와 수신된 인코딩 유닛들의 수 사이의 차이로서 계산하게 하는 명령들을 포함하는, 컴퓨터-판독가능 저장 매체.
8. 제 1 항에 있어서,
   수신된 데이터는, 데이터의 블록에 대한 다수의 인코딩 유닛들을 포함하고,
   상기 프로세서로 하여금,
   상기 블록에 대한 인코딩 유닛을 수신하게 하고;
   상기 블록이 액티브인지를 결정하게 하고;
   상기 블록이 액티브가 아닌 경우, 상기 인코딩 유닛을 폐기하게 하고;
   상기 블록이 액티브인 경우, 상기 블록을, 상기 블록을 복원하기 위해 이용되는 상기 블록에 대한 인코딩 유닛들의 세트에 추가하게 하는 명령들을 더 포함하는, 컴퓨터-판독가능 저장 매체.
9. 제 1 항에 있어서,
   상기 프로세서로 하여금 수신하게 하는 명령들은, 복수의 블록들에 대한 인코딩 유닛들이 서로 인터리빙되도록, 상기 프로세서로 하여금, 상기 복수의 블록들에 대한 인코딩 유닛들을 수신하게 하는 명령들을 포함하는, 컴퓨터-판독가능 저장 매체.
10. 제 9 항에 있어서,
    상기 프로세서로 하여금, 상기 인코딩 유닛들을 수신하게 하는 명령들은, 상기 프로세서로 하여금,
    상기 병렬 네트워크 경로들 중 제 1 경로를 통해 제 1 블록에 대한 제 1 인코딩 유닛을 수신하게 하고;
    상기 제 1 인코딩 유닛을 수신한 후, 상기 제 1 경로를 통해 제 2 블록에 대한 제 2 인코딩 유닛을 수신하게 하고;
    상기 제 2 인코딩 유닛을 수신한 후, 상기 제 1 경로를 통해 상기 제 1 블록에 대한 제 2 인코딩 유닛을 수신하게 하는 명령들을 포함하는, 컴퓨터-판독가능 저장 매체.
11. 명령들이 저장된 컴퓨터-판독가능 저장 매체로서,
    상기 명령들은 실행되는 경우, 서버 디바이스의 프로세서로 하여금,
    순방향-에러 정정된 데이터를 복수의 병렬 네트워크 경로들을 통해 클라이언트 디바이스에 송신하게 하고;
    상기 클라이언트 디바이스로부터, 상기 네트워크 경로들 각각을 통해 전송된 데이터의 손실들을 표현하는 데이터를 수신하게 하고; 그리고
    상기 손실들을 표현하는 데이터에 기초하여, 상기 병렬 네트워크 경로들을 통한 후속 데이터 송신들에 대해 전송되는 순방향-에러 정정 데이터의 양을 변형하게 하는, 컴퓨터-판독가능 저장 매체.
12. 제 11 항에 있어서,
    상기 프로세서로 하여금, 상기 손실들을 표현하는 데이터를 수신하게 하는 명령들은, 상기 프로세서로 하여금, 상기 병렬 네트워크 경로들 각각에 대해, 각각의 병렬 네트워크 경로를 통해 전송된 패킷 플로우에 대해 수신된 최고 시퀀스 번호를 식별하는 데이터를 수신하게 하는 명령들을 포함하는, 컴퓨터-판독가능 저장 매체.
13. 제 11 항에 있어서,
    상기 프로세서로 하여금, 상기 손실들을 표현하는 데이터를 수신하게 하는 명령들은, 상기 프로세서로 하여금, 상기 클라이언트 디바이스에 의해 인코딩 유닛들이 수신된 복수의 블록들 각각을 식별하는 데이터, 상기 블록들 각각에 대해 요구되는 인코딩 유닛들의 수들, 및 상기 블록들 각각과 관련된 네트워크 패킷들에 대해 상기 클라이언트에 의해 수신된 최고 시퀀스 번호들을 정의하는 데이터를 수신하게 하는 명령들을 포함하는, 컴퓨터-판독가능 저장 매체.
14. 제 11 항에 있어서,
    전송된 데이터는, 데이터의 블록에 대한 다수의 인코딩 유닛들을 포함하고,
    상기 프로세서로 하여금, 상기 네트워크 경로들 각각을 통해 전송된 상기 데이터의 손실들을 표현하는 데이터의 어그리게이션에 기초하여, 데이터의 블록에 대한 하나 이상의 추가적인 인코딩 유닛들을 전송하게 하는 명령들을 더 포함하는, 컴퓨터-판독가능 저장 매체.
15. 제 11 항에 있어서,
    전송된 데이터는, 데이터의 블록에 대한 다수의 인코딩 유닛들을 포함하고,
    상기 프로세서로 하여금,
    상기 블록에 대해 요구되는 추가적인 인코딩 유닛들의 수를 표현하는 데이터를 상기 클라이언트 디바이스로부터 수신하게 하고;
    상기 블록에 대한 상기 추가적인 인코딩 유닛들의 수를 상기 클라이언트 디바이스에 전송하게 하는 명령들을 더 포함하는, 컴퓨터-판독가능 저장 매체.
16. 제 15 항에 있어서,
    상기 추가적인 인코딩 유닛들의 수를 표현하는 데이터는, 상기 네트워크 경로들 각각을 통해 전송된 상기 데이터의 손실들을 표현하는 데이터를 포함하는, 컴퓨터-판독가능 저장 매체.
17. 제 11 항에 있어서,
    전송된 데이터는 데이터의 블록에 대한 다수의 인코딩 유닛들을 포함하고,
    상기 프로세서로 하여금,
    수신된 인코딩 유닛들의 수를 표현하는 데이터를 상기 클라이언트 디바이스로부터 수신하게 하고;
    상기 블록의 크기 및 상기 블록에 대한 수신된 인코딩 유닛들의 크기들에 기초하여, 상기 블록을 복원하기 위해 요구되는 인코딩 유닛들의 수를 계산하게 하고;
    추가적인 인코딩 유닛들의 수를, 상기 블록을 복원하기 위해 요구되는 인코딩 유닛들의 수와 수신된 인코딩 유닛들의 수 사이의 차이로서 계산하게 하고;
    상기 추가적인 인코딩 유닛들의 수를 상기 클라이언트 디바이스에 전송하게 하는 명령들을 더 포함하는, 컴퓨터-판독가능 저장 매체.
18. 제 11 항에 있어서,
    상기 프로세서로 하여금 전송하게 하는 명령들은, 복수의 블록들에 대한 인코딩 유닛들이 서로 인터리빙되도록, 상기 프로세서로 하여금, 상기 복수의 블록들에 대한 인코딩 유닛들을 전송하게 하는 명령들을 포함하는, 컴퓨터-판독가능 저장 매체.
19. 제 18 항에 있어서,
    상기 프로세서로 하여금, 상기 인코딩 유닛들을 전송하게 하는 명령들은, 상기 프로세서로 하여금,
    상기 병렬 네트워크 경로들 중 제 1 경로를 통해 제 1 블록에 대한 제 1 인코딩 유닛을 전송하게 하고;
    상기 제 1 인코딩 유닛을 전송한 후, 상기 제 1 경로를 통해 제 2 블록에 대한 제 2 인코딩 유닛을 전송하게 하고;
    상기 제 2 인코딩 유닛을 전송한 후, 상기 제 1 경로를 통해 상기 제 1 블록에 대한 제 3 인코딩 유닛을 전송하게 하는 명령들을 포함하는, 컴퓨터-판독가능 저장 매체.
20. 제 11 항에 있어서,
    데이터의 전체 블록이 상기 프로세서에 대해 이용가능하기 전에, 상기 프로세서로 하여금 데이터의 블록에 대한 인코딩 유닛들을 전송하게 하는 명령들을 더 포함하는, 컴퓨터-판독가능 저장 매체.
21. 제 11 항에 있어서,
    상기 프로세서로 하여금,
    제 1 블록에 대한 인코딩 유닛들의 제 1 세트를 전송하게 하고 ―상기 인코딩 유닛들의 제 1 세트는, 상기 제 1 블록을 복원하기 위해 요구되는 인코딩 유닛들의 최소수보다 더 적은 수의 인코딩 유닛들을 포함함―;
    상기 인코딩 유닛들의 제 1 세트를 전송한 후, 제 2 블록에 대한 인코딩 유닛들의 제 2 세트를 전송하게 하고;
    상기 인코딩 유닛들의 제 2 세트를 전송한 후, 상기 제 1 블록에 대한 하나 이상의 인코딩 유닛들을 포함하는 인코딩 유닛들의 제 3 세트를 전송하게 하는 명령들을 더 포함하는, 컴퓨터-판독가능 저장 매체.
22. 제 21 항에 있어서,
    상기 프로세서로 하여금, 상기 인코딩 유닛들의 제 1 세트를 전송하게 하는 명령들은, 상기 제 1 블록이 완전히 형성되기 전에 상기 프로세서로 하여금 상기 인코딩 유닛들의 제 1 세트를 전송하게 하는 명령들을 포함하는, 컴퓨터-판독가능 저장 매체.
23. 제 21 항에 있어서,
    상기 제 1 블록 및 상기 제 2 블록은 미디어 컨텐츠에 대한 데이터의 복수의 블록들 중의 블록들을 포함하고, 상기 프로세서로 하여금 상기 인코딩 유닛들의 제 1 세트, 상기 인코딩 유닛들의 제 2 세트 및 상기 인코딩 유닛들의 제 3 세트를 전송하게 하는 명령들은, 상기 프로세서로 하여금, 상기 인코딩 유닛들의 제 1 세트, 상기 인코딩 유닛들의 제 2 세트 및 상기 인코딩 유닛들의 제 3 세트를, 상기 데이터의 복수의 블록들이 전송된 복수의 병렬 네트워크 경로들 중의 경로를 통해 전송하게 하는 명령들을 포함하는, 컴퓨터-판독가능 저장 매체.
24. 제 23 항에 있어서,
    상기 프로세서로 하여금, 상기 데이터의 손실들을 표현하는 데이터를 상기 클라이언트 디바이스로부터 상기 네트워크 경로들 각각을 통해 수신하게 하는 명령들을 더 포함하는, 컴퓨터-판독가능 저장 매체.
25. 제 21 항에 있어서,
    상기 프로세서로 하여금,
    상기 인코딩 유닛들의 제 1 세트를 수신한 후 피드백 데이터의 제 1 세트를 수신하게 하고 ―상기 피드백 데이터의 제 1 세트는, 상기 제 1 블록을 식별하는 데이터, 상기 제 1 블록을 복원하기 위한 다수의 요구되는 인코딩 유닛들을 표시하는 데이터, 및 상기 제 1 블록과 관련된 네트워크 패킷들에 대해 수신된 최고 시퀀스 번호를 정의하는 데이터를 포함함―;
    상기 인코딩 유닛들의 제 2 세트를 수신한 후 피드백 데이터의 제 2 세트를 수신하게 하는 명령들을 더 포함하고,
    상기 피드백 데이터의 제 2 세트는, 상기 제 2 블록을 식별하는 데이터, 상기 제 2 블록을 복원하기 위한 다수의 요구되는 인코딩 유닛들을 표시하는 데이터, 및 상기 제 2 블록과 관련된 네트워크 패킷들에 대해 수신된 최고 시퀀스 번호를 정의하는 데이터를 포함하는, 컴퓨터-판독가능 저장 매체.

Images