KR20070004517A

KR20070004517A - Ｆｅｃ-기반 신뢰도 제어 프로토콜

Info

Publication number: KR20070004517A
Application number: KR1020067004808A
Authority: KR
Inventors: 마이클 루비; 매트 더클레프; 아비 비그더손; 소렌 라센
Original assignee: 디지털 파운튼, 인크.
Priority date: 2003-10-08
Filing date: 2004-10-08
Publication date: 2007-01-09
Also published as: CN101656731B; JP2007508750A; US20090144601A1; CN100550652C; EP1671424B1; WO2005036361A2; EP1671424A2; CN1864335A; US20050226272A1; WO2005036361A3; KR101035219B1; CN101656731A; EP1671424A4; JP4685787B2; US7447235B2; US8458567B2

Abstract

전송 시스템에서, 데이터 블록에 전송될 데이터를 복수의 인코딩 유닛을 각각 포함하는 데이터 블록으로 조직화하고, 송신기로부터의 제1 데이터 블록의 인코딩 유닛을 수신기에 전송하며, 수신기에 의한 인코딩 유닛의 수신 통지를 송신기에서 검출하여 데이터를 송신기로부터 수신기에 신뢰적으로 전송한다. 수신기에서 제1 데이터 블록을 복구하기 위해서 제1 데이터 블록의 충분한 인코딩 유닛을 수신기가 수신하는 확률을 송신기에서 결정하고, 소정의 테스트가 충족되는지를 판정하기 위해서 임계 확률에 대하여 확률을 테스트한다. 테스트 단계 이후 및 송신기가 수신기에서의 제1 데이터 블록의 복구 확인을 수신하기 이전에 소정의 테스트가 충족되는 경우 송신기로부터 제1 데이터 블록의 인코딩 유닛을 전송한다. 제1 데이터 블록의 복구 실패 암시가 송신기에 수신되는 경우 송신기로부터 수신기에 제1 데이터 블록용 인코딩 유닛을 더 송신한다. 일부 실시예에서, 소정의 테스트는 임계 확률에 대한 확률의 비교이며, 확률이 임계 확률보다 높은 경우에 소정의 테스트는 충족된다.

송신기 종단 시스템, 수신기 종단 시스템, 데이터 전송, 데이터 블록, 인코딩 유닛, 데이터 복구

Description

ＦＥＣ-기반 신뢰도 제어 프로토콜{FEC-BASED RELIABILITY CONTROL PROTOCOLS}

관련 출원

본 출원은 "FEC-BASED RELIABILITY CONTROL PROTOCOLS"라는 발명의 명칭으로 2003년 10월 8일에 출원되어 동시 계류중인 미국 가특허 출원 제60/509,976호로부터 우선권을 주장하며, 이는 참조로서 본 명세서에 통합되어 있다.

본 발명은 데이터 통신 네트워크를 통한 종단 시스템들(end systems) 사이에서의 신속한 데이터 통신의 문제에 관한 것이다.

여러 데이터 통신 시스템 및 고수준 데이터 통신 프로토콜은 신뢰적인 데이터 전송의 편리한 통신 추상화(abstraction)를 제공하며, 속도 제어, 즉 네트워크 상태에 따라서 그것들의 패킷 전송 속도를 자동적으로 조절한다. 유니쿼터스 TCP(transport control protocol)와 같은 저수준 패킷화된 데이터 전송의 관점에서 통상적인 기본적 실행은, 다음 상태의 적어도 하나에 처해진다: (a) 송신기(들)와 수신기(들) 사이의 접속에서 왕복 시간(RTT; round-trip time)이 길다; (b) 데이터량이 크고 네트워크는 버스트 및 전송 손실을 겪는다.

현재 사용되고 있는 가장 널리 사용되는 신뢰적인 전송 프로토콜 중 하나는 TCP이다. TCP는 통지(acknowledgment) 메커니즘을 갖는 통상적으로 사용되는 포인트-투-포인트(point-to-point) 패킷 제어 기술이다. TCP는 송신기와 수신기 사이에 손실이 적고 송신기와 수신기 사이의 RTT가 작은 경우 일대일 신뢰적인 통신으로 잘 작동한다. 하지만, TCP의 처리량은 매우 작은 손실이라도 존재하는 경우, 또는 송신기와 수신기가 멀리 떨어져 있는 경우에는 급격히 떨어진다.

TCP를 사용하여, 송신기는 주문된 패킷을 전송하고 수신기는 각 패킷의 수신을 통지한다. 패킷이 손실된 경우, 송신기에 통지가 송신되지 않을 것이며, 송신기는 패킷을 재전송할 것이다. TCP와 같은 프로토콜에서, 손실된 패킷은 수신기로부터의 통지의 결여 또는 명시적 요구에 응답하여 바로 재전송될 수 있기 때문에, 통지 프로그램은 전체 실패 없이 패킷이 손실되는 것을 허용한다.

TCP는 신뢰도 제어 및 속도 제어의 양자를 제공하며, 즉 모든 오리지널 데이터가 수신기에 전달되는 것을 보장하며, 혼잡 및 패킷 손실과 같은 네트워크 상태에 기초하여 패킷 전송 속도를 자동적으로 조정한다. TCP에서, 신뢰도 제어 프로토콜 및 속도 제어 프로토콜은 얽히고 분리되지 않는다. 또한, 증가하는 RTT 및 패킷 손실의 함수로서의 TCP의 처리량 성능은 최적과는 멀다.

여러 연구자에 의한 연구는, TCP를 사용하는 경우, 데이터 전송의 처리량은 RTT와, 종단간 접속에서의 손실률의 역(inverse)의 제곱근의 곱에 반비례하는 것을 보여준다. 예컨대, 미국과 유럽 사이의 통상적인 종단간 지상 접속은 200 밀리초(millissecond)의 RTT와 2%의 평균 패킷 손실을 갖는다. 이러한 상태에서는, 아무리 많은 밴드폭이 종단간에 사용가능할지라도, TCP 접속의 처리량은 기껏해야 초당 300-400킬로비트(kbps)이다. 위성 연결의 경우 상황은 더욱 심각해지며, 높은 RTT에 부가하여, 각종 대기 영향으로 인하여 정보가 손실된다. 이러한 종류의 상태에서 TCP의 열악한 성능의 주요 이유는 TCP에 의해서 사용되는 속도 제어 프로토콜이 이들 상태에서는 잘 작동하지 않는다는 것이며, TCP에 의해 사용되는 신뢰도 제어 프로토콜과 속도 제어 프로토콜이 분리되지 않기 때문에, 이는 전체 TCP 프로토콜이 이러한 상태에서는 작 작동하지 않는다는 것을 암시한다. 또한, 전송을 위한 상이한 애플리케이션의 요건이 변하지만, 아직 TCP가 모든 네트워크 상태에서 각종 애플리케이션에 상당히 보편적으로 사용되고 있어서, 여러 상황에서 열악한 성능을 이끌고 있다.

전체 전송 프로토콜에 의해서 사용되는 신뢰도 제어 프로토콜 및 속도 제어 프로토콜이 독립적인 경우, 동일한 신뢰도 제어 프로토콜이 각종 상이한 속도 제어 프로토콜과 함께 사용될 수 있어서, 선택된 실제 속도 제어 프로토콜은 애플리케이션 요건과, 애플리케이션이 가동되는 네트워크 상태에 기초할 수 있는 것이 소망 된다. 1997년 6월, Proceedings of the Fifth Israeli Symposium on Theory of Computing and System에서, Micah Adler, Yair Bartal , John Bayers , Michael Luby , Danny Raz에 의한 "A Modular Analysis of Network Transmission Protocols"란 제하의 논문(이하, "애들러(Adler)"라 칭하고, 여기에 참고자료로서 합체된다)은, 신뢰적인 전송 프로토콜을 독립적인 신뢰도 제어 프로토콜 및 속도 제어 프로토콜로 구분하는 것을 지지하는 전송 프로토콜의 구축에 대한 모듈식 접근을 소개한다.

임의의 신뢰적인 제어 프로토콜에서, 그것의 성능에 대한 두 가지의 주요 척도는 얼마나 많은 버퍼링이 요구되는가와 그것의 "굿풋(goodput)"이 얼마인가 이다. 버퍼링은 송신기 및 수신기 양쪽에서 신뢰도 제어 프로토콜에 도입된다. 송신기에서의 버퍼링은 예컨대, 데이터가 초기에 송신된 이후 수신기에서 수신되었다는 통지를 송신기가 가질 때까지 데이터가 버퍼링 되는 경우 발생한다. 버퍼링이 중요한 것은 다음의 두 가지 이유 때문이다: (1) 버퍼링은 송신기 및 수신기 신뢰도 제어 프로토콜이 얼마나 많은 메모리를 사용하는지에 직접적인 영향을 끼친다; (2) 버퍼링은 송신기 및 수신기 신뢰도 제어 프로토콜이 얼마나 많은 지연을 도입하는지에 직접적인 영향을 끼친다. 굿풋은 전송 동안에 수신기 종단 시스템에서 수신된 송신 데이터량으로 전송된 데이터의 사이즈를 나눈 것으로 정의된다. 예컨대, 오리지널 데이터를 전송하기 위해 패킷으로 송신된 데이터량이 오리지널 데이터의 사이즈이면 굿풋은 1.0이고, 굿풋 = 1.0은 중복 데이터가 전혀 전송되지 않은 경우에 달성될 수 있다.

애들러는 속도 제어 프로토콜에 매우 독립적인 신뢰도 제어 프로토콜의 개요를 언급하며, 이하 "비코드(No-code) 신뢰도 제어 프로토콜"이라 한다. 비코드 신뢰도 제어 프로토콜은, 오리지널 데이터가 블록으로 구분되고 각 블록이 패킷의 페이로드로 송신되며, 각 블록의 정확한 카피(copy)가 신뢰적인 전송을 보장하기 위해서 수신될 필요가 있다는 관점에서, TCP에서 실행되는 신뢰도 제어 프로토콜과 여러가지 점에서 유사하다. 비코드 신뢰도 제어 프로토콜에서의 문제점은, 굿풋이 최적(실질적으로 1과 동일)일지라도, 패킷 손실이 있는 경우에는, 비코드 신뢰도 제어 프로토콜이 도입하는 버퍼링이 상당해질 수 있다는 것이다. 애들러는, 프로토콜이 최적의 굿풋을 가지며, 송신기 및 수신기에서 필요한 버퍼링의 양을 최소화하는 관점에서 대개는 최적의 일정한 인자 내에 있다는 견지에서, 비코드 신뢰도 제어 프로토콜이 데이터를 전송하는데 코딩을 사용하지 않는 신뢰도 제어 프로토콜 중에서 최적의 일정한 인자 내에 있음을 입증한다.

신뢰도 제어 프로토콜에서 사용되고 있는 하나의 솔루션은 리드-솔로몬(Reed-Solomon) 코드 또는 토네이도(Tornado) 코드 등의 순방향 오류 정정(FEC) 코드, 또는 체인 리액션(chain reaction) 코드(정보 부가 코드임)이다. FEC 코드를 사용하여, 오리지널 데이터는 패킷의 페이로드(payload)보다 큰 블록으로 분할되고, 이러한 블록으로부터 인코딩 유닛이 생성되며, 그 인코딩 유닛을 패킷으로 송신한다. 코딩을 사용하지 않는 신뢰도 제어 프로토콜에 대한 이러한 접근의 하나의 기본적인 장점은, 피드백이 매우 단순해지며 덜 빈번하다는 것이며, 즉 각각의 블록에 대하여, 수신기는 어느 인코딩 유닛이 수신되는지의 정확한 리스트 대신에 수신된 인코딩 유닛의 양을 송신기에 지시하는 것만이 필요하다. 또한, 오리지널 데이터 블록의 길이보다도 집합적으로 더 많은 인코딩 유닛을 생성하고 송신하는 능력은 신뢰도 제어 프로토콜 설계시의 강력한 툴(tool)이다.

소거 정정 코드(erasure correcting code)는 고정된 길이 블록에 고정된 수의 인코딩 유닛을 생성한다. 예컨대, 입력 유닛 N을 포함하는 블록에서는, N 인코딩 유닛이 생성될 것이다. 이러한 N 인코딩 유닛은 B 오리지널 입력 유닛과, N-B 중복 유닛(redundant unit)을 포함할 수 있다. 스토리지(storage)가 허용되면, 송 신기는 각 블록을 위한 인코딩 유닛의 세트를 일 회만 산출하고, 캐러설 프로토콜(carousel protocol)을 사용하여 인코딩 유닛을 전송한다.

일부 FEC 코드에서의 하나의 문제점은, 과도한 연산 능력과 가동 메모리를 필요로 한다는 것이다. 다른 문제점은 필요한 인코딩 유닛의 수가 코딩 프로세스 이전에 결정되어야 한다는 것이다. 이것은 패킷의 손실률이 과대 평가되면 불충분성이 초래되고, 패킷의 손실률이 과소 평가되면 실패가 초래될 것이다.

통상적인 FEC 코드의 경우, 생성될 수 있는 가능한 인코딩 유닛의 수는 블록이 구분되는 입력 유닛의 수와 동일한 크기의 차수이다. 배타적이진 않지만, 통상적으로, 대부분 또는 전체의 인코딩 유닛은 송신 단계 이전의 사전처리 단계에서 생성된다. 이러한 인코딩 유닛은 모든 입력 유닛이 오리지널 블록의 길이와 동일하거나 오리지널 블록의 길이보다 미소하게 큰 인코딩 유닛의 임의의 서브세트로부터 재생성될 수 있는 특성이 있다.

미국 특허 제 6,307,487호(이하 "루비(Luby) I"이라 하며, 여기에 참고 자료로 합체된다)에 개시되는 체인 리액션 디코딩은 전술한 문제점들을 언급한 순방향 오류 정정의 폼을 제공한다. 체인 리액션 코드에서, 생성될 수 있는 가능한 인코딩 유닛의 풀(pool)은 입력 유닛의 수보다 큰 크기의 차수이며, 가능한 풀로부터 랜덤하거나 유사 랜덤하게 선택되는 유닛이 매우 빠르게 선택될 수 있다. 체인 리액션 코드에서, 인코딩 유닛은 송신 단계와 동시적인 "필요한 때" 기초로 전송중에 생성될 수 있다. 체인 리액션 코드는 콘텐츠의 모든 입력 유닛이 오리지널 콘텐츠보다 길이가 미소하게 긴 랜덤 또는 유사 랜덤하게 생성되는 인코딩 유닛의 세트의 서브 세트로부터 재생성될 수 있게 한다.

미국 특허 제 6,320,520호, 6,373,406호, 6,614,366호, 6,411,223호, 6,486,803호 및 미국 공개 특허 제2003-0058958호(이하, "쇼크롤라히(Shokrollahi) I"라 한다)와 같은 다른 문서들은, 각종 체인 리액션 코딩 기술을 개시하며 여기에 참고 자료로 합체된다.

체인 리액션 코드를 사용하는 송신기는 송신되는 각 블록용 인코딩 유닛을 연속적으로 생성할 수 있다. 인코딩 유닛은 UDP(user datagram protocol) 유니케스트를 통하여 또는 적용 가능한 경우 UDP 멀티케스트(multicast)를 통하여 수신기에게 전송될 수 있다. 각각의 수신기는 오리지널 블록을 얻기 위하여 패킷으로 수신되는 적절한 수의 인코딩 유닛을 디코딩하는 디코딩 유닛을 구비하는 것이라고 추정한다.

디지털 파운튼사(Digital Fountain, Inc.)로부터 입수 가능한 트랜스포터 파운튼(Transporter Fountain^TM) 네트워크 장치에서 이용가능한 몇몇 전송 중의 하나는 각종 속도 제어 프로토콜과 조합될 수 있는 단순한 FEC-기반 신뢰도 제어 프로토콜이다. 이러한 단순한 FEC-기반 신뢰도 제어 프로토콜은 이하 "TF 신뢰도 제어 프로토콜"이라 한다. TF 신뢰도 제어 프로토콜은 블록을 복구하는데 충분한 인코딩 유닛이 수신되었다는 수신기로부터의 통지를 수신할 때까지 해당 데이터 블록용 인코딩 유닛을 전송하고, 송신기는 다음 블록으로 이동한다.

송신기가 패킷을 송신한 때로부터, 패킷이 도달하였다는 수신기로부터의 통 지를 송신기가 수신할 때까지 걸린 시간을 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%가 낭비된다. 따라서, 이러한 예에서의 굿풋은 빈약한 0.75(최대 가능한 굿풋 1.0에 비하여)이다.

이러한 예에서, 속도 R과 함께 블록 B의 사이즈는 단순한 FEC-기반 신뢰도 제어 프로토콜에 의해서 도입되는 지연이 적어도 4초(각 블록은 전체 4초 동안 전송된다)이며, 적어도 1 블록, 즉 3,000 데이터 패킷의 버퍼링을 필요로 한다. 또한, 굿풋을 증가시키기 위해서는 버퍼링의 증가를 필요로 하며, 반대로 버퍼링을 감소시키기 위해서는 굿풋의 감소를 필요로 한다.

전술한 바와 같이, 신뢰도 제어에 대한 개선점이 소망 된다.

발명의 개요

본 발명에 실시예에 따른 전송 시스템에서, 데이터 블록에 전송될 데이터를, 복수의 인코딩 유닛을 각각 포함하는 데이터 블록으로 조직화하고, 송신기로부터의 제1 데이터 블록의 인코딩 유닛을 수신기에 전송하며, 수신기에 의한 인코딩 유닛의 수신 통지를 송신기에서 검출하여 데이터를 송신기로부터 수신기에 신뢰적으로 전송한다. 수신기에서 제1 데이터 블록을 복구하기 위해서 제1 데이터 블록의 충분 한 인코딩 유닛을 수신기가 수신하는 확률을 송신기에서 결정하고, 소정의 테스트가 충족되는지를 판정하기 위해서, 임계 확률에 대하여 확률을 테스트한다. 테스트 단계 이후 및 송신기가 수신기에서의 제1 데이터 블록의 복구 확인을 수신하기 이전에, 소정의 테스트가 충족되는 경우, 송신기로부터 제2 데이터 블록의 인코딩 유닛을 전송한다. 제1 데이터 블록의 복구 실패 암시가 송신기에 수신되는 경우, 송신기로부터 수신기에 제1 데이터 블록용 인코딩 유닛을 더 송신한다. 일부 실시예에서, 소정의 테스트는 임계 확률에 대한 확률의 비교이며, 확률이 임계 확률보다 높은 경우에 소정의 테스트는 충족된다.

도 1은 본 발명의 교시를 사용할 수 있는 네트워크, 송신기 종단 시스템 및 수신기 종단 시스템의 일 실시예의 블록도.

도 2는 모듈식의 신뢰적인 전송 프로토콜 아키텍처 및 그러한 프로토콜을 사용하는 관련 오퍼레이팅 시스템의 설명도.

도 3은 송신기 FEC-기반 신뢰도 제어 프로토콜 아키텍처 및 그러한 프로토콜을 사용하는 관련 오퍼레이팅 시스템의 설명도.

도 4는 수신기 FEC-기반 신뢰도 제어 프로토콜 아키텍처 및 그러한 프로토콜을 사용하는 관련 오퍼레이팅 시스템의 설명도.

도 5는 TF 신뢰도 제어 프로토콜을 실행하는 시스템에 의해서 사용될 수 있는 가능한 포맷 세트를 나타내는 도면.

도 6은 송신기 TF 신뢰도 제어 프로토콜을 실행하는 시스템의 논리 블록도.

도 7은 수신기 TF 신뢰도 제어 프로토콜을 실행하는 시스템의 논리 블록도.

도 8은 액티브 블록의 설명도.

도 9는 인터리브드(interleaved) 신뢰도 제어 프로토콜에 의해서 사용될 수 있는 가능한 포맷 세트의 설명도.

도 10은 기본 송신기 인터리브드 신뢰도 제어 프로토콜을 실행하는 시스템의 논리의 예시적 실시예.

도 11은 기본 수신기 인터리브드 신뢰도 제어 프로토콜을 실행하는 시스템의 논리의 예시적인 실시예.

본 발명의 실시예에서, 인터리브드 신뢰도 제어 프로토콜은 TCP, TF 신뢰도 제어 프로토콜 및 비코드 신뢰도 제어 프로토콜에 대한 개선점을 제공한다. 신뢰도 제어 프로토콜에서, 데이터 블록은 송신기로부터 일련의 인코딩 유닛으로 수신기에 송신되며, 수신기는 인코딩 유닛 또는 블록의 복구를 알린다. 그리하여, 수신기가 데이터를 수신하였는지 수신하지 않았는지를 송신기가 판단하게 하거나, 데이터를 재전송하거나, 수신된 데이터를 복구하는데 사용할 수 있는 다른 데이터를 전송할 수 있게 한다. 일부 인터리브드 신뢰도 제어 프로토콜의 일 특성은, 상이한 블록용의 인코딩 유닛이 인터리브드 식(interleaved fashion)으로 송신된다는 것이다. 인터리브드 신뢰도 제어 프로토콜은, 실질적인 임의의 속도 제어 프로토콜과 조합되는 경우에, 종단(end) 시스템에서 버퍼링(및 결과적인 지연)을 최소화하고, 전송의 굿풋(goodput)을 최대화하는 효율적이고 신뢰적인 데이터 전송을 제 공한다.

인터리브드 신뢰도 제어 프로토콜은, 큰 손실 및/또는 큰 RTT가 있는 경우에도, 고처리량을 유지하면서 데이터의 신뢰적인 전송을 보장하기 위하여 적절한 속도 제어 프로토콜과 함께 사용될 수 있다. 예컨대, 속도 제어 프로토콜은 고정 속도로 송신하는 경우에는 단순해질 수 있고, 인터리브드 신뢰도 제어 프로토콜은 전송 동안에 버퍼링 및 지연을 최소화하면서, 데이터가 그 고정 속도 × 성공적으로 도달하는 패킷의 비율과 동일한 속도로 전송되는 것을 보장할 것이다.

여기에 도입된 인터리브드 신뢰도 제어 프로토콜에 의해서 제공되는 양적 개선의 일례로서, 속도 제어 프로토콜이 초당 R 패킷의 고정 속도로 송신되며, 송신기와 수신기 사이의 왕복 시간이 RTT라 하면, N=R*RTT 는 전송중인 미확인 패킷의 수이다. 비코드 신뢰도 제어 프로토콜에서는, 송신기에서의 전체 버퍼 사이즈는 적어도 N*ln(N)이며, 굿풋은 약 1.0이고, 필요량의 버퍼링과 굿풋 사이의 가능한 다른 트레이드-오프(trade-off)는 없다. 여기서, ln(x)는 x의 자연 로그로서 정의된다. TF 신뢰도 제어 프로토콜에서는, 송신기에서의 전체 버퍼 사이즈는 적어도 B이며, 굿풋은 약 B/(B+N)이고, 여기서 B는 패킷 유닛의 선택된 블록 사이즈이고 굿풋에 대하여 필요한 버퍼링을 트레이드-오프 하기 위하여 선택될 수 있다. 대조적으로, 인터리브드 신뢰도 제어 프로토콜의 경우에는, 송신기에서의 전체 버퍼 사이즈는 B 이하이며, 굿풋은 약 N/(N+X)이고, 여기서 X는 굿풋에 대하여 필요한 버퍼링을 트레이드-오프하기 위해 선택되는 양의 정수 파라미터이고, B=N*(1+ln((N/X)+1))은 패킷 유닛의 버퍼 사이즈이다.

예컨대, 속도 R이 초당 1,000 패킷이고, RTT가 1초이면, N=1,000 패킷이다. 비코드 신뢰도 제어 프로토콜의 경우에는, 송신기에서의 버퍼 사이즈는 적어도 7,000 패킷이다. TF 신뢰도 제어 프로토콜의 경우에, B가 4,000 패킷이 되도록 선택되는 경우, 굿풋은 약 0.80이다. X가 50이 되도록 선택되는 인터리브드 신뢰도 제어 프로토콜의 경우, B=4,000 패킷(TF 신뢰도 제어 프로토콜의 경우와 동일한 값)이고, 굿풋이 0.95를 초과하며, 즉 수신된 패킷의 많아야 5%가 낭비된다. 따라서, 이 예에서, 인터리브드 신뢰도 제어 프로토콜은 거의 동일한 최적 굿풋에서, 비코드 신뢰도 제어 프로토콜에 비하여 훨씬 적은 양의 버퍼링을 필요로 하며, 동일한 양의 버퍼링에서의 TF 신뢰도 제어 프로토콜의 굿풋을 훨씬 초과한다. 즉, TF 신뢰도 제어 프로토콜에서는 낭비된 전송이 25%인 것에 비하여, 인터리브드 신뢰도 제어 프로토콜에서는 많아야 5%이다.

실질적으로 임의의 속도 제어 프로토콜은 신뢰적인 전송 프로토콜을 제공하기 위하여, 예컨대, 고정 속도로 전송하기 위하여, 인터리브드 신뢰도 제어 프로토콜과 함께 사용될 수 있고, TCP와 유사한 윈도우 기반 정체 제어 프로토콜을 사용하거나, TFRC(TCP Friendly Rate Control)와 같은 등식 기반 정체 제어 프로토콜을 사용하거나, 실질적인 임의의 다른 속도 제어 프로토콜을 사용할 수 있다.

3. 신뢰적인 전송 프로토콜

본 설명에서, 신뢰적인 전송 프로토콜은, 송신된 패킷의 일부가 수신되지 않을 가능성이 있을지라도 모든 데이터가 전송되는 방식으로 패킷 기반 네트워크를 통하여 송신기 종단 시스템으로부터 수신기 종단 시스템으로 데이터를 신뢰적으로 전송하는 프로토콜이다. 도 1은 신뢰적인 전송 프로트콜이 작동할 수 있는 네트워크(130)와, 송신기 종단 시스템[100(1), …, 100(J)]와, 수신기 종단 시스템[160(1), …,160(K)] 세트의 예시적인 실시예이다. 통상적으로, 그러한 프로토콜은 패킷 송신 속도를 조정하기 위한 일부 메커니즘을 포함할 수 있으며, 이러한 송신 속도는, 프로토콜이 구축되는 애플리케이션(application), 유저 입력 파라미터, 및 송신기 종단 시스템과 수신기 종단 시스템 사이의 네트워크 상태를 포함하는 각종 인자에 달려 있다.

TCP와 같은 신뢰적인 전송 프로토콜은 통상적으로 몇몇 단계를 포함한다. 이러한 단계는 종단 시스템이 데이터의 입수 가능성을 광고하고, 다른 종단 시스템으로의 데이터 전송을 개시하고, 어느 데이터가 전송될지를 알리고, 데이터의 신뢰적인 전송을 수행하는 방식을 포함한다. 종단 시스템이 입수 가능성을 광고하고, 전송을 개시하고, 어느 것이 전송될지를 알리는 각종 표준 방식, 예컨대, 세션 안내 프로토콜, 세션 개시 프로토콜 등의 각종 표준 방식이 있지만, 이들 단계가 잘 공지되어 있으므로, 여기에서는 상세히 설명하지 않는다.

패킷 데이터의 신뢰적인 전송은 전송의 각 포인트에서 어느 데이터를 패킷으로 송신할지 그리고 그 패킷을 어느 속도로 송신할지를 결정하는 것을 포함한다. 각 시점에서 이루어지는 결정은 수신기 종단 시스템으로부터 송신된 피드백 및 다른 인자들에 의존할 수 있다. 통상적으로, 데이터는 송신기 종단 시스템에 데이터 스트림(data stream)으로서 존재하며, 신뢰적인 전송 프로토콜이라는 것은 이러한 스트림을 그것이 송신된 것과 같은 순서로 수신기 종단 시스템에 신뢰적으로 전달 하는 것을 의미한다. 전송이 개시되기 전에 스트림의 전체 길이가 알려지지 않는 경우가 종종 있다.

4. 신뢰적인 전송 프로토콜의 모듈식 아키텍처

애들러(Adler)는 임의의 신뢰적인 전송 프로토콜이 신뢰도 제어 프로토콜과 속도 제어 프로토콜의 조합으로서 어떻게 고려될 수 있는지를 기술한다. 신뢰도 제어 프로토콜은 전송 동안에 어느 데이터를 각 패킷에 위치시킬지를 결정하는 전체 전송 프로토콜의 일부이다. 속도 제어 프로토콜은 각각의 데이터 패킷을 언제 송신할지를 결정한다. 여러 전송 프로토콜에서, 신뢰도 제어 프로토콜 및 속도 제어 프로토콜은 오퍼레이션 동안 밀접하게 얽히며, 이는 TCP의 경우이다. 하지만, 그러한 얽힌 프로토콜이라도 신뢰도 제어 프로토콜과 속도 제어 프로토콜로 개념적으로 구분될 수 있는 경우가 있다.

애들러는 신뢰도 제어 프로토콜과 속도 제어 프로토콜을 독립적으로 설계하는 신뢰적인 전송 프로토콜의 설계를 지지한다. 그와 같은 접근의 이점은, 동일한 신뢰도 제어 프로토콜이 각종 속도 제어 프로토콜과 함께 사용될 수 있고, 그리하여 동일한 신뢰도 제어 프로토콜이, 전체적으로 신뢰적인 전송 프로토콜이 사용되는 네트워크 상태 및 애플리케이션에 적절한 속도 제어 프로토콜과 함께 사용될 수 있다는 것이다. 설계에 대한 이러한 모듈식 접근은, 동일한 신뢰도 제어 프로토콜이 상이한 애플리케이션 및 네트워크 환경에서 각종 세트의 속도 제어 프로토콜과 함께 사용될 수 있기 때문에 매우 이점이 있고, 그리하여 각각의 애플리케이션 및 네트워크 환경에 대하여 전체적인 신뢰적인 전송 프로토콜의 전적인 재설계를 피할 수 있다. 예컨대, 상이한 네트워크 환경의 각종 애플리케이션에 TCP가 사용되고, 그것은 속도 제어 프로토콜에 의해서 결정될 때 달성하는 빈약한 처리량으로 인하여, 일부의 애플리케이션 및 네트워크 환경에는 불충분하게 수행한다. 불행히도, 신뢰도 제어 프로토콜 및 속도 제어 프로토콜이 TCP 아키텍처 내에서 얽히기 때문에, TCP 내에서 상이한 속도 제어 프로토콜을 단순히 사용하여, 불충분하게 작동하는 상황에서 처리량 성능을 개선하는 것은 불가능하다.

도 2는 애들러에서 지지되는 모듈식의 신뢰적인 전송 프로토콜 아키텍처의 설명도이다. 송신기 전송 프로토콜(210)은 송신기 신뢰도 제어 프로토콜(220)과 송신 속도 제어 프로토콜(230)로 구분된다. 송신기 신뢰도 제어 프로토콜(220)은 각각의 데이터 패킷으로 무엇을 보낼지를 결정하며, 송신 속도 제어 프로토콜(230)은 언제 각각의 데이터 패킷이 송신될지를 결정한다. 송신기 신뢰도 제어 프로토콜(230)은 각각의 데이터 패킷 내에 부가적인 신뢰도 제어 정보를 배치할 수 있으며, 그 정보는 수신기 전송 프로토콜(290) 내의 수신기 신뢰도 제어 프로토콜(280)에 의해서 사용될 수 있다. 송신기 신뢰도 제어 프로토콜(220)은 수신기 전송 프로토콜(290) 내의 대응하는 수신기 신뢰도 제어 프로토콜(280)로부터 신뢰도 제어 프로토콜 정보(250)를 또한 수신할 수 있으며, 그 정보는 각각의 데이터 패킷으로 무엇이 송신될지를 결정하는데 돕기 위해 사용된다. 유사하게, 송신기 속도 제어 프로토콜(230)은 각각의 패킷 내에 부가적인 속도 제어 정보를 배치할 수 있으며, 그 정보는 수신기 전송 프로토콜(290) 내의 수신기 속도 제어 프로토콜(270)에 의해서 사용될 수 있다. 또한, 송신기 속도 제어 프로토콜(230)은 수신기 전송 프로 토콜(290) 내의 대응하는 수신기 속도 프로토콜(270)로부터 속도 제어 정보(250)를 수신할 수 있으며, 그 정보는 각각의 데이터 패킷이 송신될 때를 결정하는데 돕도록 사용될 수 있다.

송신기 신뢰도 프로토콜(220)과 수신기 신뢰도 프로토콜(280) 사이에서 전송되는 신뢰도 제어 정보는 패킷 손실 등의 각종 인자들에 의존할 수 있고, 나중에 상세하게 설명할 각종 정보를 포함할 수 있다. 유사하게, 송신기 속도 제어 프로토콜(230)과 수신기 속도 제어 프로토콜(270) 사이에서 전송되는 속도 제어 정보는 패킷 손실, 측정된 왕복 시간(RTT) 등의 각종 인자들에 의존할 수 있다. 또한, 데이터 패킷(240) 또는 피드백 패킷(250)으로 송신된 정보가 신뢰도 제어 및 속도 제어의 양쪽에 사용될 수 있다는 견지에서 신뢰도 제어 정보 및 속도 제어 정보는 서로 중첩할 수 있다. 일반적으로, 송신기 전송 프로토콜(210)로부터 수신기 전송 프로토콜(290)로 송신된 신뢰도 제어 및 속도 제어 정보는 데이터와 함께 데이터 패킷(240)으로 송신되거나, 별도의 제어 패킷(240)으로 송신되거나, 상기 양쪽 방식으로 송신될 수 있다. 이러한 프로토콜은 송신기로부터 수신기로, 그리고 수신기로부터 송신기로 전송되는데 필요한 정보량을 최소화시키도록 설계되어야 한다.

여러 애플리케이션에서, 데이터는 스트림으로서 전송된다. 즉, 데이터가 송신기 종단 시스템에 도달할 때, 송신기 종단 시스템에 도달할 때와 같은 순서로 가능한 한 빨리 수신기 종단 시스템에 신뢰적으로 전송된다. 일부 애플리케이션, 예컨대, 스트리밍 애플리케이션(streaming application), 또는 데이터의 작은 버스트(burst)가 두 종단 시스템 사이에서 가능한 한 빠르게 앞뒤로 전송되는 쌍방 애플 리케이션(interactive application)에서, 전체 전송 프로토콜에 의해 도입되는 지연이 최소화되어야 한다. 그리하여, 전송 프로토콜에 의해서 도입되는 전체 지연이 최소화되어야 한다.

송신기 신뢰도 제어 프로토콜(220)과 수신기 신뢰도 제어 프로토콜(280) 모두는 통상적으로 데이터를 임시 저장하기 위해 버퍼를 필요로 한다. 일반적으로, 송신기 신뢰도 제어 프로토콜(220)에서 버퍼링된 데이터는 적어도, 송신기 신뢰도 제어 프로토콜(220)이 수신기 신뢰도 제어 프로토콜(280)로부터 복구 통지를 아직 수신하지 않은 스트림 내의 초기 데이터로부터, 송신기 신뢰도 제어 프로토콜(220)이 데이터 패킷으로 송신하기 시작한 스트림 내의 최근 데이터까지를 포함한다. 수신기 신뢰도 제어 프로토콜(280)에서의 버퍼 사이즈는 일반적으로는 적어도 아직 복구되지 않은 초기 데이터로부터 데이터 패킷이 수신된 최근 데이터까지의 스트림 내의 데이터량이다.

송신기 신뢰도 제어 프로토콜(220)의 버퍼링 요건은, 얼마나 많은 임시 저장 스페이스가 송신기 제어 프로토콜(220)에 의해서 요구되는지에, 그리고 송신기 신뢰도 제어 프로토콜(220)이 얼마나 많은 지연이 전체의 신뢰적인 데이터 전송에 도입하는지에 직접적인 영향을 준다. 수신기 신뢰도 제어 프로토콜(280)의 버퍼링 요건도 유사한 영향을 준다. 그리하여, 송신기 신뢰도 제어 프로토콜(220) 및 수신기 신뢰도 제어 프로토콜(280)의 버퍼링 요건을 최소화하는 것이 중요하다.

신뢰도 제어 프로토콜은 각각의 데이터 패킷으로 무엇이 송신될지를 결정한다. 종단 시스템간의 접속을 효율적으로 활용하기 위해서, 송신기 신뢰도 제어 프 로토콜(220)은, 수신기 신뢰도 제어 프로토콜(280)에서 수신되는 어떠한 데이터라도 오리지널 데이터 스트림의 복구부(recovering portion)에 유용하게 되는 것을 보장하도록 가능한 한 적은 중복 데이터를 패킷으로 송신하는 것이 중요하다. 신뢰도 제어 프로토콜의 굿풋은, 데이터의 오리지널 스트림을 복구하는 동안에 수신기 신뢰도 제어 프로토콜(280)에 의해서 수신되는 데이터 패킷의 전체 길이로 데이터의 오리지널 스트림의 길이를 나눈 것으로 정의된다. 굿풋 목표는 신뢰도 제어 프로토콜의 경우 1.0 또는 그것에 근접하는 굿풋이 되게 하는 것이며, 이 경우 데이터의 오리지널 스트림을 복구하기 위해서 최소량의 데이터가 수신된다. 일부 신뢰도 제어 프로토콜에서, 굿풋은 1.0 이하일 수 있고, 이 경우 전송된 데이터 패킷의 일부가 낭비된다. 따라서, 송신기 종단 시스템으로부터 수신기 종단 시스템으로 이동하는 데이터 패킷에 의해서 소모되는 밴드폭(bandwidth)을 효율적으로 사용하도록 하기 위하여, 굿풋이 가능한 한 1.0에 근접하도록 신뢰성 제어 프로토콜을 설계하는 것이 중요하다.

5. FEC -기반 신뢰도 제어 프로토콜

신뢰도 제어 프로토콜에서 사용되는 하나의 솔루션은, 리드-솔로몬(Reed-Solomon) 코드 또는 토네이도(Tornado) 코드 등의 순방향 오류 정정(FEC) 코드, 또는 체인 리액션(chain reaction) 코드(정보 부가 코드임)의 솔루션이 있다. 오리지널 데이터는 패킷의 페이로드(payload)보다 큰 블록으로 분할되고, 이러한 블록으로부터 인코딩 유닛이 생성되며, 그 인코딩 유닛을 패킷으로 송신한다. 리드-솔로몬이나 토네이드 코드와 같은 소거 정정 코드는 고정된 길이의 블록에 고정된 수 의 인코딩 유닛을 생성한다. 예컨대, 입력 유닛을 포함하는 블록에서는, N 인코딩 유닛이 생성될 것이다. 이러한 N 인코딩 유닛은 B 오리지널 입력 유닛과, N-B 중복 유닛을 포함할 수 있다.

FEC-기반 신뢰도 제어 프로토콜은 FEC 코드를 사용하는 신뢰도 제어 프로토콜이다. 도 3은 송신기 FEC-기반 신뢰도 제어 프로토콜(220)의 예시적인 실시예이며, 도 4는 수신기 FEC-기반 신뢰도 제어 프로토콜(280)의 예시적인 실시예이다. 송신기 신뢰도 제어 논리(310)는 데이터의 오리지널 스트림을 데이터 블록(330)으로 분할하고, FEC 인코더(320)에 각 블록용 인코딩 유닛을 생성할 것을 지시한다. 송신기 신뢰도 제어 프로토콜 논리(310)는 인코딩 유닛과 신뢰도 제어 정보(340)가 송신기 속도 제어 프로토콜(230)을 처리하는 장치로 어떻게 진행할지를 결정하고, 도 4에 도시된 FEC-기반 신뢰도 제어 논리(410)에 의해서 송신된 신뢰도 제어 정보(350)를 또한 처리한다.

송신기 신뢰도 제어 논리(310)는, 각 블록이 복구되는 것을 보장하기 위해서, 도 4에 도시된 수신기 FEC-기반 신뢰도 제어 프로토콜(280)에 의해서 충분한 인코딩 유닛이 수신되는 것을 보장해야 한다. 모든 블록은 실질적으로 동일한 길이로 이루어질 수 있거나, 블록 길이가 데이터 스트림이 송신기에 입수가능하게 되는 속도, 데이터 패킷의 송신 속도, 네트워크 상태, 애플리케이션 요건, 및 유저 요건을 포함하는 각종 파라미터의 함수로서 전송중에 동적으로 변할 수 있다.

해당 데이터 블록은 길이가 B 인코딩 유닛이라 상정한다. 일부 FEC 코드에서, 데이터의 오리지널 블록을 복구하는데 요구되는 인코딩 유닛의 수는 정확히 B 인 반면, 다른 FEC 코드의 경우, 데이터의 오리지널 블록을 복구하는데 요구되는 인코딩 유닛의 수는 B보다 다소 크다. FEC-기반 신뢰도 제어 프로토콜의 기술(description)을 단순화시키기 위해서, B 인코딩 유닛은 데이터 블록의 복구에 충분하다고 추정하며, 블록을 디코딩하기 위해 B 인코딩 유닛 이상을 필요로 하는 FEC 코드가 다소 감소된 굿풋 및 다소 증가된 버퍼링 요건에서 사용될 수 있다고 이해되어야 한다.

도 4의 수신기 신뢰도 제어 논리(410)는 데이터 블록을 디코딩하기 위해 B 인코딩 유닛이 수신되는 것을 보장할 책임이 있고, FEC 디코더(420)는 데이터 블록(430)을 복구하는데 사용된다. 수신기 신뢰도 제어 논리(410)는 송신기 FEC-기반 신뢰도 제어 프로토콜(220)로부터 송신된 신뢰도 제어 정보(340) 및 인코딩 유닛을 수신하고, 궁극적으로 송신기 신뢰도 제어 논리(310)에 송신되고 그것에 의해 처리되는 신뢰도 제어 정보(350)를 생성하고 송신하는 책임이 있다.

6. 신뢰도 제어 프로토콜

TF 신뢰도 제어 프로토콜은 데이터 스트림을 일반적으로 동일한 사이즈의 블록으로 분할한다. 전체적인 아키텍처(architecture)는, 임의의 시점에서 하나의 액티브 데이터 블록이 존재하고, 송신기가 블록을 재구성하기 위하여 충분한 인코딩 유닛이 도달했다는 것을 지시하는 수신기로부터의 메시지를 수신할 때까지 그 데이터 블록용의 충분한 인코딩 유닛을 생성하고 송신하는 아키텍처이며, 그 시점에서 송신기는 다음 블록으로 이동한다. 따라서, 해당 블록용의 모든 인코딩 유닛이 생성되어 송신되고, 그 블록은 후속 블록의 임의의 인코딩 유닛이 생성되어 송 신되기 이전에 복구된다.

도 5는 TF 신뢰도 제어 프로토콜에 의해서 사용될 수 있는 가능한 포맷 세트를 도시한다. 송신기 데이터 포맷은 송신기 RF 신뢰도 제어 프로토콜이 인코딩 유닛 및 대응하는 신뢰도 제어 정보를 수신기 TF 신뢰도 제어 프로토콜에 송신하는 포맷을 기술한다. 이 포맷은 인코딩 유닛이 생성되는 블록을 지시하는 블록 번호(510)와, 그 인코딩 유닛이 블록으로부터 어떻게 생성되는지를 지시하는 인코딩 유닛 ID(520)와, 블록을 복구하기 위하여 수신기 TF 신뢰도 제어 프로토콜 내의 FEC 디코더에 의해서 사용될 수 있는 인코딩 유닛(530)을 포함한다. 수신기 피드백 포맷은 수신기 TF 신뢰도 제어 프로토콜이 신뢰도 제어 정보를 송신기 TF 신뢰도 제어 프로토콜에 송신하는 포맷을 기술한다. 이 포맷은 블록을 복구하기 위해서 그 블록을 위해 수신기 TF 신뢰도 제어 프로토콜이 인코딩 유닛을 수신하고 있는 현재 블록의 블록 번호와, 수신기 TF 신뢰도 제어 프로토콜이 블록을 복구하는데 필요로 하는 부가적인 인코딩 유닛의 수인 필요 인코딩 유닛(550)을 포함한다.

도 6은 송신기 TF 신뢰도 제어 프로토콜을 실행하기 위한 프로세스의 예시적인 실시예이다. 프로세스는 송신기 데이터를 송신할 시간인지를 알기 위해 계속 체크하며(단계 610), 그 시간은 대응하는 송신기 속도 제어 프로토콜에 의해서 결정된다. 송신기 데이터를 송신할 시간인 경우에는, 액티브 블록으로부터 인코딩 유닛이 생성되고 송신기 데이터가 송신된다(단계 620). 송신기 데이터용 폼의 예는 도 5에 도시된 포맷이다. 프로세스는 또한 수신기 피드백이 수신되었는지를 알아보기 위해 계속 체크한다(단계 630). 수신기 피드백 데이터용 폼의 일 예는 도 5에 도시된 포맷이다. 수신기 피드백이 존재하는 경우에, 그것을 액티브 블록을 복구하기 위해 수신기가 얼마나 많은 부가적인 인코딩 유닛을 필요로 하는지에 관한 정보를 갱신하기 위해 처리된다. 그 후, 필요한 인코딩 유닛의 수가 0인지를 알아보기 위해 체크하며(단계 640), 0인 경우에는, 데이터 스트림 내의 다음 블록이 이용가능한지를 조사한다(단계 650). 이용이 불가능한 경우에는, 준비될 때까지 다음 블록을 준비하고(단계 660), 현재의 액티브 블록을 비활성화하고 다음 블록을 활성화한다(670). 일반적으로, 다음 블록은 현재의 액티브 블록이 전송되고 있는 동안에 준비될 수 있다.

여기에 기술한 각각의 프로토콜은 적절한 프로세스에 의해서 실행되는 디바이스, 소프트웨어, 또는 펌웨어에 의해서 실행될 수 있다는 것을 이해해야 한다. 예컨대, 실행은 라우터와 호스트 컴퓨터와 같은 네트워크 디바이스를 이용하여 이루어질 수 있고, 무선 전송기, 재 전송기, 및 다른 무선 디바이스에서 실행될 수 있다. 여기에 기술된 프로토콜은 소프트웨어로 실행될 수 있고, 그러한 프로토콜을 실행하도록 구성되는 방법 및/또는 장치를 갖는다.

도 7은 수신기 TF 신뢰도 제어 프로토콜을 실행하기 위한 프로세스의 예시적인 실시예이다. 수신기 TF 신뢰도 제어 프로토콜은 송신기 데이터가 도 5에 도시된 송신기 데이터 포맷으로 수신되었는지를 알아보기 위해 계속 체크한다(단계 710). 수신된 경우에는, 송신기 데이터 내의 인코딩 유닛이 액티브 블록으로부터의 것인지를 체크한다(단계 720). 인코딩 유닛이 액티브 블록으로부터의 것이 아닌 경우에는 폐기되고(단계 760), 그리하여 그것은 어떠한 블록을 복구하는데에도 유용하지 않기 때문에 낭비되는 송신기 데이터가 된다. 인코딩 유닛이 액티브 블록으로부터의 것인 경우에는, 액티브 블록용으로 이미 수신된 인코딩 유닛 세트에 부가되고 블록용 인코딩 유닛의 필요한 수는 하나씩 감소한다(단계 730). 인코딩 유닛의 필요한 수가 0인지를 알아보기 위해 체크하고(단계 740), 0인 경우에는 FEC 디코더를 사용하여 액티브 블록을 복구하고, 다음 액티브 블록용 인코딩 유닛의 수신을 준비한다(단계 750). 또한, 수신기 TF 신뢰도 제어 프로토콜은, 대응 수신기 속도 제어 프로토콜에 의해서 결정되는, 수신기 피드백을 송신할 시간인지를 알아보기 위해 계속 체크한다(단계 770). 그 시간인 경우에, 도 5에 도시된 수신기 피드백 포맷의 포맷인 수신기 피드백이 준비되고 송신된다(단계 780).

이는 전체적인 TF 신뢰도 제어 프로토콜의 일부의 설명임을 유념해야 한다. 예컨대, 수신기 피드백이 수신기 RF 신뢰도 제어 프로토콜에 의해서 송신되는 조건은 특정하지 않는다. 이는 수신된 송신기 데이터의 수신시, 때때로 발사하는 타이머에 의해서 트리거될 수 있거나, 수신기 속도 제어 프로토콜에 의해서 결정되는 바와 같이 이벤트의 조합 또는 임의의 다른 이벤트의 조합에 의해서 트리거될 수 있다. 일반적으로, 수신기 피드백은 인코딩 유닛의 수신 진행에 관하여 통상적인 기초로 통지되는 송신기 TF 신뢰도 제어 프로토콜을 수신기 TF 신뢰도 제어 프로토콜에 유지하도록 매우 자주 송신되지만, 송신기 TF 신뢰도 제어 프로토콜로부터 수신기 TF 신뢰도 제어 프로토콜로 송신된 인코딩 유닛을 포함하는 송신기 데이터와 거의 같은 밴드폭을 소모하도록은 아니다.

TF 신뢰도 제어 프로토콜은 다음의 관점에서 "낭비적"이라고 고려될 수 있 다. B를 인코딩 유닛의 유닛 내의 각각의 데이터 블록의 사이즈라 하고, R을 속도 제어 프로토콜에 의해서 패킷이 송신되는 속도라 하고, RTT를 송신기 종단 시스템과 수신기 종단 시스템 간의 왕복 시간이라 하고, N=R*RTT라 한다. 송신기와 수신기 사이에서는 패킷 손실이 없다고 상정한다. 송신기 TF 신뢰도 제어 프로토콜이 액티브 블록을 위해 (블록을 복구하는데 충분한) B 인코딩 유닛을 송신한 후, 수신기 TF 신뢰도 제어 프로토콜로부터 블록을 복구하는데 충분한 인코딩 유닛이 도달하였다는 것을 지시하는 수신기 피드백을 수신할 때까지 N개의 부가적인 인코딩 유닛을 계속 송신하고, 이들 N개의 인코딩 유닛은 모두 낭비된다. 길이 B의 블록을 복구하기 위해서는 B+N의 인코딩 유닛을 송신할 필요가 있고, 그리하여 굿풋은 B/(B+N)가 된다. 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%가 낭비된다. 굿풋을 예컨대 0.98로 증가시키고 그리하여 송신된 인코딩 유닛의 단지 2%만이 낭비되게 하기 위해서는, B = 49 메가바이트인 매우 큰 버퍼 사이즈를 필요로 한다. 이러한 사이즈의 버퍼는 신뢰도 제어 프로토콜에 의해서 부가되는 적어도 50초의 지연을 초래한다.

전술한 TF 신뢰도 제어 프로토콜에 대한 다수의 변형예가 있다. 예컨대, 송신기 TF 신뢰도 제어 프로토콜은 B의 인코딩 유닛이 일 블록으로부터 송신된 후 인코딩 유닛의 송신을 중지하고, 블록을 복구하기 위하여 충분한 유닛이 수신되었는지를 지시하는 수신기 피드백을 기다린다. 손실이 없는 경우에는, 이러한 변형예는 낭비될 임의의 인코딩 유닛을 송신하지 않지만, 각 블록 사이에 RTT 시간의 갭이 있는 경우에도, 그리고 밴드폭이 임의의 다른 목적을 위해 사용되고 있지 않으면, 이러한 프로토콜은 R*RTT의 밴드폭의 낭비량을 여전히 초래한다. 또한, 전체 전달 시간은 이상적인 경우보다 B/(B+N)만큼 지연될 것이다. 손실이 있다면, 궁극적으로 부가적인 인코딩 유닛이 손실된 인코딩 유닛 대신에 블록을 복구하기 위해 송신되어야 하기 때문에, 이러한 변형예에서는 지연이 더욱더 부가될 것이고 전송이 느려질 것이다.

7. 인터리브드 신뢰도 제어 프로토콜

임의의 손실된 인코딩 유닛이 수신기 피드백에 대한 필요성이 없이 동일한 블록으로부터 생성되는 임의의 순차적으로 수신된 인코딩 유닛에 의해서 보상될 수 있기 때문에, TF 신뢰도 제어 프로토콜은 비코드 신뢰도 제어 프로토콜에 비하여 장점을 갖는다. TF 신뢰도 제어 프로토콜이 낭비적인 주요 이유는, 각 블록의 전송이 후속 블록의 전송이 시작되기 이전에 완료된다는 견지에서의 프로토콜의 순차적인 특성 때문이다. 여기에 기재된 개선된 신뢰도 제어 프로토콜은 지능적인 방식으로 블록의 처리를 인터리빙(interleaving) 하는데 사용될 수 있다.

인터리빙의 예시적인 예가 도 8에 도시된다. 이 예에서, 두 개의 액티브 블록, 즉, 제1 액티브 블록 AB 1(810)과 제2 액티브 블록 AB 2(820)가 있다. 도 8의 하부는 시간에 걸친 데이터 패킷 송신의 일례를 도시하며, 각 패킷은 대응하는 패킷이 인코딩 유닛 AB 1 또는 AB 2용 인코딩 유닛을 포함하는 지에 따라서 AB 1 또는 AB 2의 라벨로 나타내었다. 이러한 예에서, AB 1(830(1), 830(2), 830(3) 및 830(4))용 인코딩 유닛을 포함하는 네 개의 패킷이 먼저 송신되고 나서, AB 2(830(5) 및 830(6))용 인코딩 유닛을 포함하는 두 패킷이 송신되고, 그 후에 AB 1(830(7))용 인코딩 유닛을 포함하는 하나의 패킷과, AB 2(830(8))용 인코딩 유닛을 포함하는 하나의 패킷과, AB 1(830(9))용 인코딩 유닛을 포함하는 하나의 패킷이 송신된다. 일반적으로, 상이한 블록용 인코딩 유닛 사이의 인터리빙은 굿풋을 최대화하고 전체 버퍼링 요건(및 후속적으로 도입되는 지연)을 최소화하도록 설계되어야 한다.

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

도 10은 기본 송신기 인터리브드 신뢰도 제어 프로토콜의 논리의 예시적인 실시예이다. 프로토콜의 이 버전에서, 기본 송신기 인터리브드 신뢰도 제어 프로토콜은, 대응하는 송신기 속도 제어 프로토콜에 의해서 결정되는, 송신기 데이터를 송신할 시간인지를 알아보기 위해 연속적으로 체크한다(단계 1005). 송신기 데이터를 송신할 시간인 경우에는, 기본 송신기 인터리브드 신뢰도 제어 프로토콜은 하기하는 룰(rule) 세트를 이용하여 인코딩 유닛을 어느 액티브 블록으로부터 생성하고 송신할지를 결정한다.

기본 송신기 인터리브드 신뢰도 제어 프로토콜은 각각의 액티브 블록 i에 대하여 다음과 같은 변수 트랙을 유지한다(단계 1010): B_i는 블록을 복구하는데 필요한 인코딩 유닛의 수; R_i는 기본 수신기 인터리브드 신뢰도 제어 프로토콜이 수신된 수신기 피드백에 기초하여 블록으로부터 수신하였다는 것을 기본 송신기 인터리브드 신뢰도 제어 프로토콜이 알고 있는 인코딩 유닛의 수; L_i = B_i - R_i는 기본 수신기 인터리브드 신뢰도 제어 프로토콜이 블록을 복구하기 위해 수신할 필요가 있다는 것을 기본 송신기 인터리브드 신뢰도 제어 프로토콜이 알고 있는 미확 인된 인코딩 유닛의 나머지 수; U_i는 블록을 위해 송신되었지만 기본 송신기 인터리브드 신뢰도 제어 프로토콜에 의해서 아직 통지가 수신되지 않은 송신 인코딩 유닛의 수; X_i는 기본 송신기 인터리브드 신뢰도 제어 프로토콜이 블록을 위해 얼마나 적극적으로 인코딩 유닛을 송신할지를 결정하는 파라미터.

이들 변수는 다음과 같이 결정된다: B_i 값은 블록의 사이즈 및 각 인코딩 유닛의 사이즈에 의해 결정된다. 일반적으로, 각각의 인코딩 유닛은 사이즈가 동일하며, 그 사이즈는 데이터 패킷의 페이로드에 적합하게 선택되며, 예컨대, 인코딩 유닛의 길이는 1024 바이트일 수 있다. 각 블록의 사이즈는 일반적으로 동일하거나 상이하거나, 또는 송신기에서의 데이터 스트림의 도착 속도에 의해 결정되거나, 데이터 패킷의 송신 속도에 의해 결정되거나, 이들과 다른 인자들의 조합에 의 해 결정될 수 있다. R_i 값은 단계 1030에서 수신된 수신기 피드백에 기초하여 결정된다. U_i 값은 블록용 인코딩 유닛을 포함하여 송신된 최종 송신기 데이터에서의 시퀀스 번호와, 블록을 위해 수신기 피드백에서 수신된 가장 높은 시퀀스 번호 사이의 차이이다.

X_i 값은 전체 신뢰도 제어 프로토콜의 함수이며, 후술하는 바와 같이, X_i의 선택에는 트레이드오프(tradeoff)가 있다. X_i 값은 블록용 모든 인코딩 유닛을 송신하는 동안에 일정하게 유지될 수 있거나, 각종의 다양한 방식으로 변하는 값일 수 있으며, 그것의 일부는 후술한다. 본질적으로, 각 시점에서의 X_i는 기본 송신기 인터리브드 신뢰도 제어 프로토콜이 기본 수신기 인터리브드 신뢰도 프로토콜로부터의 어떠한 부가적인 수신기 피드백 없이 블록을 복구하는데 필요한 최소 이상으로 얼마나 많은 부가적인 인코딩 유닛을 송신하려는 지의 척도이다. L_i는 이미 통지된 수신 인코딩 유닛을 초과한, 블록 i를 복구하는데 필요한 인코딩 유닛의 수이고, U_i는 전송중이나 아직 통지되지 않은 블록 i용 인코딩 유닛의 수이기 때문에, L_i + X_i - U_i는 기본 송신기 인터리브드 신뢰도 제어 프로토콜이 그 시점에서 송신하려고 하는 블록 i용의 부가적인 인코딩 유닛의 수이다. X_i 값에 대한 트레이드오프는 다음과 같다. X_i가 증가할수록 굿풋은 감소하며, 가능하게는 X_i까지는 액티브 블록 i을 복구하는데 필요한 최소값 이상의 인코딩 유닛이 기본 수신기 인터리브드 신뢰도 제어 프로토콜에 의해서 수신될 수 있다. 다른 한편으로, X_i가 증가할수록, 액티브 블록 i의 신뢰적인 수신을 완료하기 위한 패킷 시간대의 수가 감소하므로, X_i가 증가할수록 액티브 블록의 전체 사이즈는 감소한다. 이는 블록 i용 X_i 인코딩 유닛이 소실될 수 있고, 또한 부가적인 인코딩 유닛의 전송을 트리거하기 위한 수신기 피드백을 기다리지 않고 기본 수신기가 블록을 복구할 수 있기 때문이다. 전체 버퍼 사이즈와 X_i 함수로서의 굿풋 사이의 트레이드오프는, TF 신뢰도 제어 프로토콜이나 비코드 신뢰도 제어 프로토콜과 같은 다른 신뢰도 제어 프로토콜에서의 대응하는 트레이드오프보다 더욱 적합하다는 것이 판명된다.

단계 1015에서, 부등식 L_i + X_i - U_i > 0을 만족시키는 액티브 블록 i가 있는지를 결정하기 위해 테스트가 이루어진다. L_i 값은 수신기 피드백에 의해서 이미 통지된 인코딩 유닛에 기초하여 블록을 복구하는데 얼마나 많은 인코딩 유닛이 필요한지의 값이다. U_i는 그 블록용으로 전송중인 통지된 인코딩 유닛의 수이 다. 그리하여, 전송중인 모든 인코딩 유닛이 소실되지 않는 경우, L_i - U_i는 송신되어야 할 부가적인 인코딩 유닛의 수이며, 그리하여 이 수가 0 이하인 경우, 수신기는 블록용으로 전송중인 모든 인코딩 유닛이 도달한다면 그 블록을 복구할 수 있을 것이다. 다른 한편으로, 인코딩 유닛의 일부가 소실될 수 있고, X_i는 후속하는 수신기 피드백에 의해서 트리거되는 블록을 위해 부가적인 인코딩 유닛을 전송해야 하는 것을 피하기 위해서 소실에 대하여 보호하기 위해 송신기가 순향적으로 송신하려고 하는 부가적인 인코딩 유닛의 수이다. 따라서, L_i + X_i - U_i >0인 경우, 송신기는 블록 i를 위해 더 많은 인코딩 유닛을 전송하려고 할 것이며, 그것이 0 이하인 경우에는, 송신기는 블록 i를 위해 더 많은 인코딩 유닛을 전송하려고하지 않을 것이다. 따라서, 단계 1015에서, L_i + X_i - U_i >0 을 만족시키는 액티브 블록이 있는 경우에는, 단계 1020에서 인코딩 유닛이 생성되고 대응하는 송신기 데이터는 최초의 그러한 액티브 블록용으로 송신될 것이다. 그러한 액티브 블록이 없는 경우에는, 단계 1025에서 인코딩 유닛이 생성되고 대응하는 송신기 데이터는 모든 액티브 블록 중에서 최초의 액티브 블록으로부터 송신될 것이다. 바람직하게는, 파라미터는 단계 1025의 실행을 강요하는 단계 1015에서 그러한 조건을 만족시키는 블록을 갖지 않는 것을 가능한 한 피하는 방식으로 설정되며, 이는 본질적으로 단계 1025는 기본 송신기 인터리브드 신뢰도 제어 프로토콜 내의 버퍼를 클리어 하기 위한 최후의 수단으로서 행해진다.

그러한 프로토콜의 일 변형예는 다음과 같다. 활성화된 블록의 수는 1에서 시작하고, 즉, 데이터 스트림의 제1 블록이 활성화된다. 단계 1015에서의 조건을 만족시키는 액티브 블록이 없는 경우에만, 데이터 스트림의 새로운 블록이 활성화된다. 이러한 단순한 전략을 사용함으로써, 블록은 필요한 경우에만 액티브 블록이 되며, 그리하여 액티브 블록의 수, 및 그것에 후속하는 버퍼 사이즈는 블록 i에 대하여 굿풋 B_i/(B_i + X_i)를 보장하는데 필요한 수로 자가-조정한다.

프로토콜의 다른 변형예는 다음과 같다. 이러한 변형예에서, 전체 버퍼 사이즈는 동일한 사이즈를 항상 유지한다(모든 블록이 동일한 사이즈인 경우, 이는 항상 고정된 수의 액티브 블록이 존재한다는 것을 의미한다). 단계 1015에서의 조건을 만족시키는 액티브 블록이 없는 경우에는, 액티브 블록용의 X_i 값은 단계 1015에서의 조건을 만족시키는 액티브 블록이 존재할 때까지 증가한다. 단계 1015에서의 조건을 만족시키는 액티브 블록이 항상 존재한다는 규제하에서, 액티브 블록용 X_i 값이 감소하는 것이 적절하다. X_i 값을 증감시키는 여러 가능한 방식이 있으며, 예컨대, 모든 값을 동일하게 증가시키거나, 최종 액티브 블록용 값보다 최초 액티브 블록용 값을 증가시키거나, 최초 액티브 블록용 값보다 최종 액티브 블록용 값을 증가시키는 것들이 있다. X_i 값을 감소시키기 위해서 유사한 전략이 사용될 수 있다. 당업자라면 여러 가지의 다른 변형예를 생각할 수 있을 것이다.

프로토콜의 이들 변형예에 대하여 기술할 수 없을 정도로 많은 여러 가지 다른 조합이나 확장이 존재하지만, 이는 당업자에게는 자명할 것이다.

단계 1030에서, 임의의 수신기 피드백이 수신되었는지를 알아보기 위해 체크하며, 그러한 경우에는, 그것에 기초하여 모든 파라미터, 즉 모든 액티브 블록 i용 파라미터 R_i, U_i 및 X_i가 단계 1035에서 갱신된다. 단계 1040에서, 최초의 액 티브 블록이 완전 복구된 것으로 통지되었는지를 알아보기 위해 체크하며, 그러한 경우에는, 단계 1045 및 1050에서 다음 블록이 준비되고, 단계 1055에서 최초의 블록은 비활성화되고 다음 블록이 활성화된다. 일반적으로, 다음 블록 또는 몇몇 다음 블록은 액티브 블록이 전송되는 동안에 준비중에 있을 수 있으며, 최초의 액티브 블록이 비활성화될 때나 그 이전에 활성화될 준비에 있다.

도 11은 기본 수신기 인터리브드 제어 프로토콜의 논리의 예시적인 실시예이다. 프로토콜의 이러한 버전에서, 기본 수신기 인터리브드 신뢰도 제어 프로토콜은 예컨대 도 9에 도시된 송신기 데이터 포맷일 수 있는 송신기 데이터가 수신되었는지를 연속적으로 체크한다(단계 1105). 수신된 경우, 모든 액티브 블록에 대한 정보를 단계 1110에서 갱신하고, 송신기 데이터 내의 수신된 인코딩 유닛이 액티브 블록으로부터의 것인지를 알아보기 위해서 체크한다(단계 1115). 인코딩 유닛이 이미 복구된 블록으로부터의 것이거나 현재의 액티브 블록이 되는 데이터 스트림 내에서 너무 멀리 앞에 있는 블록으로부터의 것인 경우에는, 단계 1135에서 폐기되고, 그리하여 임의의 블록을 복구하는데 유용하지 않기 때문에 낭비되는 송신기 데이터가 된다. 다르게는, 단계 1120에서, 인코딩 유닛은 그것이 생성된 액티브 블록용 인코딩 유닛의 풀(pool)에 부가되며, 액티브 블록을 복구하는데 얼마나 많은 인코딩 유닛이 필요한지가 갱신된다.

블록 i용 필요한 인코딩 유닛의 수는 B_i - 수신된 인코딩 유닛의 수로서 산출된다. 기본 수신기 인터리브드 신뢰도 제어 프로토콜에 B_i 값을 전송하는 각종 방식이 있으며, 예컨대, B_i 값은 각 송신기 데이터에 포함될 수 있고, B_i 값은 별도의 제어 메시지로 송신될 수 있으며, B_i 값은 모든 블록에서 동일할 수 있으며, 세션 개시 동안에 전송될 수 있다.

그 후, 단계 1125에서, 최초 블록용의 인코딩 유닛의 수가 0인지를 알아보기 위해서 체크하며, 그러한 경우에, 단계 1130에서 FEC 디코더를 사용하여 액티브 블록을 복구하고, 새로운 다음 액티브 블록용의 인코딩 유닛을 준비한다. 기본 수신기 인터리브드 신뢰도 제어 프로토콜은, 대응하는 수신기 속도 제어 프로토콜에 의해서 결정되는, 수신기 피드백을 송신할 시간인지를 알아보기 위해 계속 체크한다(단계 1140). 그러한 경우에는, 단계 1145에서, 수신기 피드백이 준비되고 송신되며, 그것은 도 9에 도시된 송신기 데이터 포맷일 수 있다.

전술한 것은 전체의 베이직(basic) 인터리브드 신뢰도 제어 프로토콜의 부분적인 기술임을 유념해야 한다. 예컨대, 베이직 수신기 인터리브드 신뢰도 제어 프로토콜에 의해서 수신기 피드백이 송신되는 조건은 특정하지 않는다. 이것은 수신된 송신기 데이터의 수신에 의해서나, 종종 발사하는 타이머에 의해서나, 또는 이들 이벤트 또는 수신기 속도 제어 프로토콜에 의해서 결정되는 것과 같은 다른 이벤트의 조합에 의해서 트리거될 수 있다. 일반적으로, 수신기 피드백은 인코딩 유닛의 수신 진행에 관하여 통상적인 기초로 통지되는 베이직 송신기 인터리브드 신뢰도 제어 프로토콜을 베이직 수신기 인터리브드 신뢰도 제어 프로토콜에 유지하도록 매우 자주 송신되지만, 베이직 송신기 인터리브드 신뢰도 제어 프로토콜로부터 베이직 수신기 인터리브드 신뢰도 제어 프로토콜로 송신된 인코딩 유닛을 포함하는 송신기 데이터와 거의 같은 밴드폭을 소모하도록은 아니다.

베이직 인터리브드 신뢰도 제어 프로토콜은 TF 신뢰도 제어 프로토콜이나 비코드 신뢰도 제어 프로토콜보다도 굿풋과 버퍼 사이즈 사이에 더 많은 트레이드 오프를 갖는다. 예컨대, 베이직 인터리브드 신뢰도 제어 프로토콜용으로 2 이하의 액티브 블록이 있다고 상정한다. B는 인코딩 유닛의 유닛 내의 각 데이터 블록의 사이즈라 하고, B는 패킷이 속도 제어 프로토콜에 의해서 송신되는 속도라 하며, RTT는 송신기 종단 시스템과 수신기 종단 시스템 사이의 왕복 시간이라 하고, N = R*RTT라 하고, X는 모든 액티브 블록에서의 고정 상수라 한다. 이러한 예에서, 모든 파라미터는 일반적으로 데이터 전송 동안에 변할 수 있을지라도 고정된 값을 갖는다고 가정하며, B >= N이라 가정한다.

송신기와 수신기 사이에 패킷 손실이 없다고 가정한다. 베이직 송신기 인터리브드 신뢰도 제어 프로토콜은 최초 액티브 블록용으로 B+X 인코딩 유닛을 송신하고, 최초의 액티브 블록이 베이직 수신기 인터리브드 신뢰도 제어 프로토콜에 의해서 성공적으로 복구되었다는 것을 지시하는 수신기 피드백을 수신할 때까지 다음 액티브 블록으로부터 인코딩 유닛을 송신한다. 이때, 베이직 송신기 인터리브드 신뢰도 제어 프로토콜은 최초 액티브 블록을 비활성화시키고, 일부 인코딩 유닛이 이미 송신된 다음 액티브 블록이 최초 액티브 블록이 되며, 다음 블록이 활성화되어 액티브 블록이 된다. 따라서, B+X 인코딩 유닛이 길이 B의 블록을 복구하는데 사용되고, 그리하여 송신된 X 인코딩 유닛이 낭비된다. 다른 한편으로, B>=N이면, 도 9의 단계 1015에서 도시된 부등식을 만족시키는 액티브 블록이 항상 존재할 것이다. 따라서, 굿풋은 B/(B+X)가 되고, 반면 두 개의 액티브 블록이 있다면, 버퍼 의 전체 사이즈는 2*B가 된다. 일 예로서, 인코딩 유닛의 사이즈가 1 킬로바이트이고, 속도 R은 초당 1,000 인코딩 유닛 = 초당 1 메가바이트 = 초당 8 메가비트이고, RTT는 1 초라 상정하면, N = R*RTT = 1 메가바이트이다. 블록의 사이즈가 B = 1 메가바이트이고 X는 10으로 설정되면, 굿풋(B/(B+N)) = 약 0.99이고, 즉, 송신된 인코딩 유닛의 약 1%가 낭비된다. 반면에, 버퍼 사이즈가 단지 2MB이고, 이는 이러한 예에서는 베이직 송신기 인터리브드 신뢰도 제어 프로토콜이 약 2초의 지연을 부가하는 것을 의미한다. 이러한 버퍼 사이즈는 동일한 상황에서의 송신기 TF 신뢰도 제어 프로토콜의 것보다 인수 25만큼 작다는 것을 유념해야 한다.

전술한 예에서, 패킷 손실이 없는 경우에는, X 값은 0으로 설정될 수 있고, 굿풋을 1.0까지 증가시킨다. 하지만, 임의의 패킷 손실이 있는 경우에, X>0 인 설정은 현저한 장점을 갖는다는 것이 판명된다. 예컨대, 상기 예에서 송신된 각각의 1,000 개당 10 이하의 인코딩 유닛이 손실되면, X=10에서, 동일한 굿풋과 버퍼 사이즈가 달성됨이 분석에 의해 알 수 있다. 반면, X=0인 경우에는 필수적으로 적용될 수 있는 것은 아니다. 패킷 손실이 더욱 가변적이고 알려지지 않는 경우, 특히 B 패킷당 패킷 손실의 수가 X 이상인 경우, 베이직 인터리브드 신뢰되 제어 프로토콜에 의해서 달성될 수 있는 굿풋 및 버퍼 사이즈는 매우 양호하고, 양적으로도 TF 신뢰도 제어 프로토콜이나 비코드 신뢰도 프로토콜을 사용하여 달성될 수 있는 것보다 우수하다.

다른 예로서, 초당 패킷의 송신 속도 및 왕복 시간 RTT가 일정하며, N = R*RTT라고 상정한다. 패킷 손실이 랜덤하여 각 패킷이 확률 p로 손실된다고 상정 한다. 또한, 각 블록 i의 사이즈 B_i가 패킷 유닛 내의 동일한 사이즈 C이고, 각 X_i는 동일한 값 Y라 상정한다. 또한, 필요한 경우에만 새로운 블록을 활성화하는 상기 프로토콜의 변수가 사용된다. 복구되었다는 통지가 수신기로부터 수신되기 때문에, 최초로 활성화되는 때부터 재활성화되는 때까지의 블록을 고려한다. 블록의 C-N 패킷이 통지되었을 때의 일부 시간 t에서, 전송중인 F=N+Y 패킷이 통지되고, 송신기는 수신기가 블록을 완성하기 위해서 N=F-Y의 패킷을 필요로 한다는 것을 안다. 시간 t+RTT에서는, 시간 t에서 블록을 위해 전송중인 F 패킷 중에서, (1-p)*F 패킷이 수신기에 의해서 수신되고, 송신기는 통지를 수신한다. 따라서, 시간 r+RTT에서, 송신기는 수신기가 필요로 하는 나머지 패킷의 수가 N-(1-p)*F = p*F-Y이며, 그리하여 전송중인 패킷의 수는 p*F임을 안다. 논리를 계속하여, 시간 t+i*RTT에서, 송신기는 수신기가 필요로 하는 나머지 패킷의 수가 P^i*F-Y이며, 그리하여 전송중인 패킷의 수가 p^i*F임을 안다. 수신기가 필요하다고 송신기가 알고 있는 패킷 수가 0 이하이며, 블록은 완성되며, 이것은 i가 p^i*F-Y<=0을 만족시키는 경우, 시간 t+i*RTT에도 적용된다. 이러한 부등식이 적용되는 경우 i의 최소값은 i가 약 ln((N/Y)+1)ln(1/p)일 때이다. 각각의 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 패킷임을 의미한다. 물론, 랜덤한 프로세스가 예측되는 거동으로 정확히 거동한다는 것을 추정한 것이지만, 어떻게 프로토콜이 거동하는지의 개략적인 아이디어는 제공한다. 이 경우, 굿풋은 C/(C+Y)이다. 따라서, 예컨대, RTT=1, R=1,000, Y=50인 경우, 버퍼 사이즈는 커야 4,000이고, 굿풋은 0.95이다.

상기한 베이직 인터리브드 신뢰도 제어 프로토콜에 대한 여러 변형예가 있다는 것은 본 명세서를 읽은 후 자명해질 것이다. 예컨대, 전술한 바와 같이, 송신기 신뢰도 제어 프로토콜은 2 이상의 액티브 블록을 한번에 사용할 수 있으며, 이는 더욱 많은 액티브 블록을 관리시 더욱 많은 복잡성을 희생하여, 송신기 및 수신기 신뢰도 제어 프로토콜에서 사용되는 전체 버퍼 사이즈를 저감시킬 수 있는 잠재적인 장점을 가진다.

변형예의 다른 예로서, 어느 액티브 블록으로부터 인코딩 유닛이 송신될지를 결정하기 위하여 랜덤 프로세스를 사용하는데 유익할 수 있다. 이는, 패킷 손실 패턴이 시스템적일 수 있고 랜덤할 필요가 없기 때문이며, 그리하여, 어느 인코딩 유닛을 다음에 송신할지를 선택하는데 사용되는 임의의 결정론적인 프로시저의 경우, 일부 블록은 전혀 복구되지 않지만, 여전히 패킷은 수신기에 전달되는 패킷 손실 패턴이 있다. 예컨대, 결정론적인 프로시저가 특정 액티브 블록으로부터 인코딩 유닛을 송신할 때마다, 그 인코딩 유닛이 손실되지만, 임의의 다른 액티브 블록에 인코딩 유닛을 송신할 때마다, 그 인코딩 유닛은 수신기에 도달하는 손실 패턴을 고려한다. 그러한 예에서는, 수신기는 그것이 인코딩 유닛을 여전히 수신할지라도 액티브 블록을 전혀 복구하지 못한다. 이러한 종류의 시스템적 손실을 극복하기 위해서, 송신기 신뢰도 제어 프로토콜은 어느 액티브 블록으로부터 다음 인코 딩 유닛을 송신할지를 랜덤화하는 것이 유리하다. 이를 달성하기 위한 하나의 단순한 방식은 송신기 신뢰도 제어 프로토콜이 송신되는 Q 인코딩 유닛의 배치(batch)와 함께 버퍼하고, Q 인코딩 유닛의 각 배치를 랜덤한 순서로 송신하는 것이다. 더욱 정교한 방법이 사용될 수도 있으며, 예컨대, 송신될 각각의 인코딩 유닛에, 하나의 인코딩 유닛이 송신되는 다음번에 송신되는 동적으로 변하는 확률을 할당하며, 그 확률은 선택되지 않은 때 더 증가한다. 다른 변형예는 단계 1015에서의 조건을 만족시키는 액티브 블록으로부터 인코딩 유닛이 랜럼하게 생성되도록 (초기의 액티브 블록을 지지할 수 있으며 시간에 걸쳐 동적으로 변할 수 있는 적절하게 선택된 확률 분포를 사용하여) 베이직 송신기 인터리브드 신뢰도 제어 프로토콜의 도 10에 도시된 단계 1020을 수정하는 것이다.

액티브 블록 i을 위해 인코딩 유닛을 송신할 때를 결정하기 위해 파라미터 X_i가 사용되는 경우, 전송 중에 X_i를 어떻게 조정할지에 대한 여러 변형예가 있다. 일 예는 하나의 값에 X_i를 고정하고 그 값을 전송 동안에 유지하는 것이다. 예컨대, X_i는 0 또는 10과 같은 일부 다른 고정 값으로 설정될 수 있다. 다른 예에서는 X_i가 액티브 블록 i로부터의 인코딩 유닛의 전송 초기에는 하나의 값에 고정한 후, 그 X_i는 인코딩 유닛이 송신될 때마다 그리고 액티브 유닛으로부터 인코딩 유닛을 송신하기 위한 조건이 충족되지 않을 때마다 증가한다. X_i가 어떻게 증가될 수 있는지에 대한 여러 변형예가 있다. 일 예로서, X_i는 처음 N회에서는 0씩 증가되고, 그 후에는 N/B씩 증가된다. 일부 단계에서 X_i의 증가는 마이너스가 될 수 있다.

다른 변형예로서, 베이직 인터리브드 신뢰도 제어 프로토콜에서 기술한 바와 같이, 각각의 액티브 블록 i에 파라미터 X_i만을 사용하는 대신에, 인코딩 유닛이 특정 액티브 블록으로부터 송신되어야 하는지 아닌지를 결정하는 다른 방식을 사용할 수 있다. 예컨대, 평균 패킷 손실 확률이 유지될 수 있고, 액티브 블록으로부터 송신되도록 허용되는 인코딩 유닛의 수는 최근의 패킷 손실 확률이 현재 패킷 손실 확률의 좋은 예언자라는 가정에 기초하여 결정될 수 있다. 예컨대, 평균 손실 확률이 현재 p이면, 하나의 전략은 L_i + X_i/(1-p) - U_i*(1-p) > 0 이 되도록 베이직 송신기 인터리브드 신뢰도 제어 프로토콜의 도 10에 도시된 바와 같은 단계 1015를 수정하는 것이다. 이러한 특정 선택 뒤의 논리적 근거는, U_i 인코딩 유닛이 액티브 블록 i를 위해 전송중이면, 그것들의 1-p 비율만 베이직 수신기 인터리브드 신뢰도 제어 프로토콜에 도달할 것이며, X_i/(1-p) 부가적인 패킷이 송신되면, X_i가 베이직 수신기 인터리브드 신뢰도 제어 프로토콜에 도달할 것이라는 것이다. 따라서, 전체 평균하여 베이직 수신기 인터리브드 신뢰도 제어 프로토콜은 액티브 블록 i용으로 B_i + X_i 인코딩 유닛을 수신하고, X_i 부가적인 인코딩 유닛은, 블록을 복구하는데 충분한 수의 인코딩 유닛의 전송을 위해 수신기 피드백에 의존하는 것을 피하기 위해서 패킷 손실률에서의 변화도를 고려하는데 충분하게 설정되어야 한다.

인터리브드 신뢰도 제어 프로토콜의 다른 변형예는 패킷이 송신 순서와 동일한 순서로 수신기에 도달하지 않을 수 있는 가능성을 고려한다. 따라서, 수신기로부터의 후속 수신기 피드백은 예컨대, 블록으로부터 수신된 가장 높은 시퀀스 번호 가 동일할지라도 이전의 수신기 피드백보다도 해당 액티브 블록용의 더 많은 수의 수신 인코딩 유닛을 보고할 것이다. 그리하여, 베이직 인터리브드 신뢰도 제어 프로토콜 내의 논리는 재주문된 패킷용 어카운팅(accounting)을 보상하기 위해서 송신기 및 수신기 양측에서 수정될 것이다.

전술한 바와 같이, 도 10에 도시된 바와 같은 베이직 송신기 인터리브드 신뢰도 제어 프로토콜의 단계 1025는 적어도 하나의 액티브 블록이 각 시점에서의 조건 1015를 만족시키도록 일반적으로 파라미터를 적절히 설정함으로써 회피된다. 단계 1025에 대한 변형예는 인코딩 유닛을 생성하고 송신하도록 어느 액티브 블록이 선택되는지를 변형하는 것이다. 예컨대, 액티브 블록은 단계 1025에서 랜덤하게 선택될 수 있거나, 그 선택은 액티브 블록 세트를 통하여 순환할 수 있다.

도 10의 단계 1045는 다음 블록이 최초 액티브 블록이 비활성화된 후 다음 블록이 즉시 활성화되는 것을 나타낸다. 전체 버퍼 사이즈를 줄이고 후속하는 지연을 줄일 수 있는 변형예는 가장 최근의 현재 액티브 블록 이후의 블록으로부터 인코딩 유닛을 송신할 때, 다음 블록만을 활성화하는 것이다.

전술한 바와 같은 베이직 인터리브드 신뢰도 제어 프로토콜은 임의의 시점에서의 액티브 블록의 수는 고정되는 것을 가정한다. 변형예는 어느 속도에서 데이터가 전송가능한지, 얼마나 패킷 손실이 일어나는지, 패킷의 송신 속도에서의 변화도 등을 포함하는 각종 인자에 따라 액티브 블록의 수가 변하게 하는 것이다. 예컨대, 낮은 패킷 손실 상태 및 낮은 전송 속도하에서는, 액티브 블록의 수는 작게 유지될 것이지만, 손실 상태가 악화되거나 전송 속도가 증가하면, 액티브 블록의 수는 일시적으로 커질 것이다. 따라서, 버퍼링 및 지연은 프로토콜이 작동하는 상태에 따라서 동적으로 변할 것이다.

액티브 블록의 전체 사이즈는 액티브 블록의 수가 고정적으로 유지될지라도 변하도록 허용될 것이다. 이 경우, 각각의 후속 액티브 블록의 사이즈는 이전의 블록과는 상이할 것이다. 예컨대, 데이터 입수가능 비율이 커질수록 후속 액티브 블록의 사이즈도 커질 것이고, 전송 속도가 증가할수록 그것에 수반하는 액티브 블록의 사이즈도 커질 것이다. 각 액티브 블록의 길이는 시간의 함수일 수 있거나, 예컨대, 새로운 블록이 형성되기 전에 기껏해야 얼마간의 시간이 지날 것이며, 길이의 함수일 수 있거나, 즉, 각 블록은 기껏해야 어느 정도일 것이며, 또는 이들 인자 또는 다른 인자들의 조합일 수 있다.

일 블록의 끝 및 다음 블록의 시작은 인터리브드 신뢰도 제어 프로토콜에 의해서 자동적으로 결정될 것이며, 애플리케이션, 또는 이것들과 다른 인자들의 조합에 의해서 결정될 수도 있다. 예컨대, 데이터 스트림의 블록은, MPEG 스트림용 I-프레임 또는 동영상 그룹(Group of Picture) 블록 등의 애플리케이션에 대한 논리적인 의미를 가질 수 있고, 그리하여 인터리브드 신뢰도 제어 프로토콜이 데이터 스트림을 블록들로 구분하는 방식은 논리적인 애플리케이션 블록의 경계를 고려할 것이다. 또한, 애플리케이션은 인터리브드 신뢰도 제어 프로토콜에 블록 사이의 바람직한 경계를 지시할 것이고, 인터리브드 신뢰도 제어 프로토콜은 그러한 경계를 고려할 뿐만 아니라, 애플리케이션에 의해서 공급되는 것들 이외의 포인트에서에서 블록 사이에 경계를 만들도록 허용될 수 있다.

인터리브드 신뢰도 제어 프로토콜의 다른 변형예는, 그 프로토콜이 모든 블록을 신뢰적으로 순서대로 수신기에 전달하지 않는 것을 허용하지만, 다른 제약을 받기 쉬운 그러한 목적을 시도하거나 가능하면 달성하려고 한다. 예컨대, 스트리밍 애플리케이션에서, 가능하면 신뢰적으로 데이터 스트림을 전달하는 것이 중요하지만, 데이터 스트림에 대한 타이밍 제약과 같은 다른 제약이 또한 존재한다. 예컨대, 특정 시간 이후에 데이터의 특정 부분이 더 이상 적절하지 않거나, 예컨대, 쌍방향 화상 회의 애플리케이션에서 인터리브드 신뢰도 제어 프로토콜이 얼마나 많은 지연을 도입하는지에 대한 강한 제약이 있는 경우가 있다. 이러한 경우에, 송신기 인터리브드 신뢰도 제어 프로토콜 및 수신기 인터리브드 신뢰도 제어 프로토콜은 블록이 완전히 복구되기 이전에 그것의 일부가 건너뛰게 허용하도록 변형될 수 있다. 예컨대, 송신기 인터리브드 신뢰도 프로토콜은 액티브 블록이 주어진 시간 동안만 액티브하게 허용하도록 제약될 수 있거나, 블록에 인코딩 유닛을 송신하는 것이 더 이상 허용되지 않은 이후에 애플리케이션에 의해서 공급되는 각 블록에 어려운 시간 제약을 가질 수 있거나, 각 블록에 최대 수의 인코딩 유닛만을 공급하도록 허용되거나, 이들 제약의 임의의 조합이 있을 수 있다. 유사한 제약이 수신기 인터리브드 신뢰도 제어 프로토콜에 적용될 수도 있다. 이러한 애플리케이션에서, 인터리브드 신뢰도 제어 프로토콜은 이들 제약을 고려하도록 변형될 수 있다.

인터리브드 신뢰도 제어 프로토콜의 일부 변형예에서는 하나의 송신기와 하나의 수신기가 존재한다. 다른 변형예는 다음의 것을 포함할 수 있지만 이것에 한정되는 것은 아니다: 하나의 송신기 및 복수의 수신기; 하나의 수신기 및 복수의 송신기; 복수의 송신기 및 복수의 수신기. 예컨대, 송신 채널이 브로드케스트(broadcast) 또는 멀티케스트인 때, 하나의 송신기/복수의 수신기 변형예에서는, 도 10의 단계 1010에서, 송신기가 각 액티브 블록 i를 위해서 임의의 수신기로부터의 최대수의 수신된 통지 인코딩 유닛으로서의 R_i 값을 산출하도록 송신기 신뢰도 제어 프로토콜이 변형될 수 있다. 송신기가 별도의 패킷 스트림을 각각의 수신기에 송신하는 경우 하나의 송신기/복수의 수신기의 다른 예로서, 도 10의 단계 1010에서, 각각의 액티브 블록 i 및 각각의 수신기 j에 대하여, 송신기가 수신기 j로부터 수신된 통지 인코딩 유닛의 수로서 R_ij 값을 액티브 블록 i용으로 산출하고, L_ij = B_i - R_ij를 산출하도록 송신기 신뢰도 제어 프로토콜은 변형될 수 있으며, U_ij는 수신기 j로 송신된 액티브 블록 i용으로 송신되었지만 아직 미통지된 인코딩 유닛의 수로서 산출될 수 있으며, 단계 1015에서의 조건은, 일부 수신기 j에 대하여 L_ij + X_i - U_ij > 0인 액티브 블록 i가 존재하는지를 결정하기 위해서 변경될 수 있다. 다른 예로서, 복수의 송신기/하나의 수신기 변형예에서, 동일하거나 다른 액티브 블록의 경우, 수신기가 복수의 송신기로부터 인코딩 유닛을 동시에 수신하고, 브로드케스트 또는 멀티케스트 채널을 통하여 모든 송신기에 수신기 피드백을 송신하거나, 잠재적으로 별도인 수신기 피드백에 별도의 패킷 스트림을 사용하여 각각의 송신기에 송신하도록 수신기 신뢰도 제어 프로토콜이 변형될 수 있다. 복수의 송신기/복수의 수신기 변형예에서는, 하나의 송신기/복수의 수신기 케이스 및 복수의 송신기/하나의 수신기 케이스에서 전술한 변형 단계가 조합될 수 있다.

다른 변형예는, 하나의 송신기가 복수의 데이터 스트림을 동시에 송신할 수 있고, 각각은 송신기 인터리브드 신뢰도 제어 프로토콜의 별도의 인스턴스(instance), 또는 모든 스트림의 모든 패킷의 전체 송신 속도가 제한되는 등의 상이한 데이터 스트림을 고려한 송신기 인터리브드 신뢰도 제어 프로토콜의 버전을 사용할 수 있고, 그리하여 송신기는 다른 것들에 대하여 일부 데이터 스트림에 패킷 송신의 우선 순위를 매기도록 결정할 수 있다. 유사하게, 하나의 수신기가 복수의 데이터 스트림을 동시에 수신할 수 있고, 각각은 수신기 인터리브드 신뢰도 제어 프로토콜의 별도의 인스턴스, 또는 모든 스트림의 모든 패킷의 전체 수신 속도가 제한되는 등의 상이한 데이터 스트림을 고려한 수신기 인터리브드 신뢰도 제어 프로토콜의 버전을 사용할 수 있고, 그리하여 송신기는 다른 것들에 대하여 일부 데이터 스트림에 패킷 수신, 처리, 및 수신기 피드백 송신의 우선 순위를 매기도록 결정할 수 있다.

전술한 변형예는 서로 조합될 수 있다. 예컨대, 일부 블록이 예컨대, 타이밍 및/또는 밴드폭 제한으로 인하여 수신기에 신뢰적으로 전달되지 않는 프로토콜은 복수의 송신기/복수의 수신기 변형예와 조합될 수 있다.

Claims

데이터를 송신기로부터 수신기에 신뢰적으로 전송하는 방법으로서,

데이터 블록에 전송될 데이터를, 복수의 인코딩 유닛을 각각 포함하는 데이터 블록으로 조직화하는 단계와;

상기 송신기로부터의 제1 데이터 블록의 인코딩 유닛을 상기 수신기에 전송하는 단계와;

상기 수신기에 의한 인코딩 유닛의 수신 통지를 상기 송신기에서 검출하는 단계와;

상기 수신기에서 상기 제1 데이터 블록을 복구하기 위해서 상기 제1 데이터 블록의 충분한 인코딩 유닛을 상기 수신기가 수신하는 확률을 상기 송신기에서 결정하는 단계와;

소정의 테스트가 충족되는지를 판정하기 위해서, 임계 확률에 대한 상기 확률을 테스트하는 단계와;

상기 테스트 단계 이후 및 상기 송신기가 상기 수신기에서의 상기 제1 데이터 블록의 복구 확인을 수신하기 이전에, 상기 소정의 테스트가 충족되는 경우, 상기 송신기로부터 제2 데이터 블록의 인코딩 유닛을 전송하는 단계와;

상기 제1 데이터 블록의 복구 실패 암시가 송신기에 수신되는 경우, 상기 송신기로부터 상기 수신기에 상기 제1 데이터 블록용 인코딩 유닛을 추가로 송신하는 단계

를 포함하는 것을 특징으로 하는 데이터를 송신기로부터 수신기에 신뢰적으로 전송하는 방법.
제1항에 있어서, 상기 각각의 인코딩 유닛은 IP 패킷인 것을 특징으로 하는 데이터를 송신기로부터 수신기에 신뢰적으로 전송하는 방법.
제1항에 있어서, 상기 실패 암시는 상기 수신기로부터 송신되어 상기 송신기에서 수신한 명시적인 실패 통지인 것을 특징으로 하는 데이터를 송신기로부터 수신기에 신뢰적으로 전송하는 방법.
제1항에 있어서, 상기 실패 암시는, 상기 송신기에서 결정한 기간 내에 상기 제1 데이터 블록의 성공적인 복구에 관한 상기 수신기로부터의 통지 수신 실패에 대하여 상기 송신기를 위해서 생성되는 것을 특징으로 하는 데이터를 송신기로부터 수신기에 신뢰적으로 전송하는 방법.
제1항에 있어서, 상기 제1 데이터 블록용의 추가의 인코딩 유닛은 상기 테스트 단계 이전에 송신된 상기 인코딩 유닛 이외의 부가적인 인코딩 유닛인 것을 특징으로 하는 데이터를 송신기로부터 수신기에 신뢰적으로 전송하는 방법.
제1항에 있어서, 상기 제1 데이터 블록용의 추가의 인코딩 유닛은 상기 테스 트 단계 이전에 송신된 인코딩 유닛의 재송신 카피(copy)인 것을 특징으로 하는 데이터를 송신기로부터 수신기에 신뢰적으로 전송하는 방법.
제1항에 있어서, 상기 인코딩 유닛은 체인 리액션 코딩 프로세스(chain reaction coding process)를 이용하여 인코딩되는 것을 특징으로 하는 데이터를 송신기로부터 수신기에 신뢰적으로 전송하는 방법.
제1항에 있어서, 상기 인코딩 유닛은 토네이도 코딩 프로세스(tornado coding process)를 사용하여 인코딩되는 것을 특징으로 하는 데이터를 송신기로부터 수신기에 신뢰적으로 전송하는 방법.
제1항에 있어서, 상기 인코딩 유닛은 소정의 코드 속도(code rate)를 갖는 순방향 오류 정정 코딩 프로세스(forward error correcting coding process)를 사용하는 것을 특징으로 하는 데이터를 송신기로부터 수신기에 신뢰적으로 전송하는 방법.