KR20160106144A

KR20160106144A - 혼잡 제어 비트레이트 알고리즘

Info

Publication number: KR20160106144A
Application number: KR1020167021510A
Authority: KR
Inventors: 크리스티앙 리케비; 켈빈 영
Original assignee: 소니 인터랙티브 엔터테인먼트 아메리카 엘엘씨
Priority date: 2014-02-06
Filing date: 2015-01-28
Publication date: 2016-09-09
Also published as: JP2017508372A; JP6476197B2; EP3103210B1; CN104836748A; CN104836748B; WO2015119817A1; EP3103210A4; EP3103210A1; KR101862175B1; US9998388B2; US20150222555A1

Abstract

방법은, 신뢰할 수 없는 프로토콜을 통해, 데이터 패킷들의 스트림을 네트워크를 통해 적어도 하나의 수신기 디바이스로 전송하는 단계를 포함할 수 있다. 데이터 패킷들의 스트림은 소스 패킷들 및 순방향 오류 정정(FEC) 패킷들을 포함할 수 있다. 방법은, 상기 전송하는 단계 동안, 적어도 하나의 수신기 디바이스로부터 하나 이상의 피드백 리포트들을 수신하는 단계로서, 각각의 상기 주기적인 피드백 리포트는 대응하는 시간의 기간 동안의 패킷 손실을 특징짓는, 단계를 포함할 수 있다. 5 방법은 또한, 상기 전송하는 단계 동안, 상기 피드백 리포트들 중 적어도 하나에 응답하여 상기 데이터 패킷들이 스트림 내에서 전송되는 레이트를 조정하는 단계를 포함할 수 있다. 레이트를 조정하는 단계는, 패킷 손실을 용인가능 레벨 내에 있는 것으로서 10 특징짓는 피드백 리포트들 중 하나에 응답하여, 소스 패킷들이 전송되는 소스 레이트를 유지하면서, FEC 패킷들이 전송되는 FEC 레이트를 증가시키는 단계를 포함할 수 있다.

Description

혼잡 제어 비트레이트 알고리즘{CONGESTION CONTROL BITRATE ALGORITHM}

본 개시는 네트워크를 통한 데이터 전송에 관한 것이다. 구체적으로, 본 개시의 측면들은 패킷 교환 네트워크 내의 신뢰할 수 없는 전송 프로토콜들을 사용하는 혼잡 제어를 위한 시스템들 및 방법들에 관한 것이다.

디지털 스트리밍 서비스들 및 다양한 클라우드-기반 컴퓨팅 해법들의 보급이 증가함에 따라, 원격 디바이스들 사이에서 큰 양의 데이터를 빠르고 정확하게 전송하기 위한 능력이 중요한 태스크이다. 인터넷, 광역 네트워크(WAN), 또는 근거리 네트워크(LAN)와 같은 네트워크의 공유된 자원들을 통해 목적지 시스템으로 디지털 데이터를 전송하는 것은 전형적으로, 고정된 또는 가변 길이를 가질 수 있는 패킷들로서 알려진 포맷된 블록들로의 데이터의 배열을 수반한다. 각각의 데이터 패킷은 전형적으로, 페이로드(payload) 또는 바디(body)를 포함하며, 이는 목적지로 전달되는 기초 사용자 데이터뿐만 아니라, 일반적으로 데이터 패킷의 헤더 내에 적어도 부분적으로 포함되는 라우팅 및 제어 목적들을 위해 사용되는 특정 추가 정보를 갖는다. 대체로 말하면, 네트워크, 전송 시스템들, 및 수신 시스템들은 의도된 목적지로의 페이로드의 적절한 라우팅 및 전달을 보장하기 위하여 이러한 추가 정보를 사용할 수 있다.

이러한 방식의 패킷 교환 네트워크를 통해 데이터를 전송하는 것의 일반적인 회피할 수 없는 결과는 패킷 손실이며, 이는 하나 이상의 데이터 패킷들이 그들의 목적지에 적절하게 도달하는 것을 실패할 때 발생한다. 패킷 손실은, 채널 혼잡, 신호 품질저하, 및 다른 이유들을 포함하는 다양한 인자들에 기인하여 일어날 수 있다. 패킷 손실이 발생하도록 초래하는 특정 네트워크 조건들을 방지하기 위하여, 동시에 또한 네트워크 채널 내의 이용가능 대역폭을 효율적으로 사용하기 위하여, 다양한 혼잡 제어 기술들이 개발되어왔다. 또한, 데이터 전송 동안 사용되는 특정 전송 프로토콜의 의존하여 패킷 손실이 발생할 때, 패킷 손실을 처리하기 위한 툴(tool)들, 및 패킷 손실을 처리하기 위해 사용되는 특정 방법을 통합할 수 있는 전송 프로토콜들의 범위가 존재한다. 일반적으로 말하면, 이러한 전송 프로토콜들은 신뢰할 수 있는 프로토콜들 및 신뢰할 수 없는 프로토콜들의 2개의 유형들로 분류될 수 있고, 이들은 각각이 특정 트레이드오프(tradeoff)들을 제공하며, 임의의 경우에 사용되는 프로토콜의 특정한 선택이 데이터 전송의 성질에 의존할 수 있다.

신뢰할 수 있는 프로토콜들은, 각각의 데이터 패킷이 차례로 그것의 목적지로 전달되며, 패킷 손실의 경우에 드롭(drop)된 패킷들을 재송신한다는 보장들을 통합한다. 신뢰할 수 있는 프로토콜들은, 항상은 아니지만 흔히, 연결-지향형(connection-oriented) 프로토콜들이며, 전달 보증들은 전형적으로, 특정 통신 세션에 대하여, 수신기가 패킷들이 적절하게 전달되었다는 것을 확인하기 위하여 어떤 유형의 수신확인 영수증(acknowledgement receipt)들을 전송하기 위해 사용할 수 있는, 수신기로부터 다시 송신기로의 백채널(backchannel)을 수립함으로써 달성된다. 송신기는, 데이터 패킷들이 그들의 목적지에 적절하게 도달하는데 실패하였다는 것이 표시될 때, 재송신 프로세스를 가이드하기 위하여 이러한 수신확인을 사용할 수 있다. 신뢰할 수 있는 프로토콜의 보급되고 잘-알려진 예는, 또한 연결-지향형인 송신 제어 프로토콜(Transmission Control Protocol; TCP)이다. TCP와 같은 신뢰할 수 있는 프로토콜들은, 데이터의 정확한 전송이 주요 고려사항이며, 관심이 있는 데이터 패킷들이 적절하게 전달되었는지를 검증함에 있어서 어떤 양의 지연이 허용될 수 있는 태스크들, 예컨대 텍스트 기반 이메일들의 전송, 디지털 콘텐트 다운로드들, 및 오디오/비디오가 목적지 시스템에서 버퍼링될 수 있는 미디어 스트리밍 서비스들에 적합하다. 불행히도, 데이터 검증 속성들 및 데이터의 재송신이 비교적 큰 오버헤드를 도입하며, 이는 다수의 신뢰할 수 있는 프로토콜들을, 라이브 오디오 및/또는 비디오 스트리밍, 온라인 비디오 게이밍, 및 인터넷 전화와 같은 실시간 데이터 전송을 포함하는 시간-임계적 애플리케이션들에 대해 바람직하지 않게 만든다.

대조적으로, 신뢰할 수 없는 프로토콜들은 일반적으로 이상에서 설명된 바와 같은 유형의 특정 패킷들에 대한 데이터 전달 검증을 하지 않으며, 일반적으로 이들은, 이들이 각각의 패킷이 그것의 목적지에 도달한다는 것을 보장하지 않고, 이들이 패킷들이 적절한 시퀀스로 전달되었다는 것을 보장하지도 않는다는 사실에 의해 특징지어진다. 신뢰할 수 없는 프로토콜들은, 항상은 아니지만 흔히, 비연결형(connectionless)이며, 전형적으로 임의의 특정 통신 세션 동안 고정된 채널을 수립하지 않는다. 그 대신, 각각의 데이터 패킷은 각각의 데이터 패킷 내에 포함된 추가 정보에 기초하여 독립적으로 라우팅될 수 있다. 신뢰할 수 없는 프로토콜의 보급되고 잘-알려진 예는, 또한 비연결형인 사용자 데이터그램 프로토콜(User Datagram Protocol; UDP)이다. UDP와 같은 신뢰할 수 없는 프로토콜들이 이상에서 언급된 신뢰성 속성들 없이 지냄으로써 오버헤드를 상당히 감소시키기 때문에, 이들은, 레이턴시(latency)를 최소화하는 것이 주요 고려사항인 시간 민감성 애플리케이션들, 예컨대 이상에서 언급된 실-시간 애플리케이션들에 더 적절하다.

신뢰할 수 없는 프로토콜들이 일반적으로 데이터 패킷들의 재송신을 하지 않기 때문에, 신뢰할 수 없는 서비스를 사용하여 데이터를 전송할 때 순방향 오류 정정(forward error correction; FEC)으로서 알려진 기술이 패킷 손실을 처리하기 위하여 일반적으로 사용된다. FEC는 수신기 디바이스에, 송신기가 적절하게 전달되는데 실패한 소스 패킷들을 재송신해야 할 필요성 없이, 손실된 패킷을 독립적으로 재구성할 수 있는 능력을 제공한다. 순방향 오류 정정이 사용될 때, 원본 소스 데이터는 전형적으로, 소스 패킷들과 동시에 수신기로 송신되는 FEC 패킷들의 형태로 송신기 측에서 중복 코딩된다. 소스 패킷 손실의 경우, 수신기 디바이스는 재송신을 기다릴 필요없이 손실 패킷을 재구성하기 위해 FEC 패킷들 내에 포함된 중복 코딩된 데이터를 사용할 수 있다.

중요하게, 네트워크 상태들이 흔히 시간의 경과에 따라 변화화며, 이는 채널 상의 현재 부하에 기초하여 네트워크 채널을 통해 송신기가 이용할 수 있는 최대 비트레이트가 변화하게끔 한다. 송신기 시스템이 채널의 현재 이용가능 대역폭을 초과하는 비트레이트로 데이터 패킷들을 송신하려고 시도할 때, 이는, 이에 응답하여 서비스 패킷 손실을 트리거(trigger)하는 혼잡 상태들을 초래할 수 있다. 손실 패킷의 재송신이 보증되기 때문에, 이는 TCP와 같은 신뢰할 수 있는 데이터 전송을 수반하는 시간에 덜 민감한 애플리케이션들에서는 허용될 수 있지만; 그러나, 패킷 손실이 수신기가 손실 데이터를 재구성할 수 없는 정도일 수 있고, 이것이 신호의 드롭아웃(dropout)과 같은 바람직하지 않은 결과들을 초래할 수 있음에 따라, 이는 다수의 실-시간 애플리케이션들 및 신뢰할 수 없는 전송을 수반하는 다른 애플리케이션들에서 용인될 수 없을 수 있다. 반면, 그 대신 최대 이용가능 비트레이트가 송신기에 의해 제시되는 비트레이트를 훨씬 초과할 때, 네트워크 채널의 전체 송신 용량이 불충분하게 사용되며, 결과적으로 수신기 측에서의 신호의 품질이 불필요하게 열악할 수 있음에 따라, 이 또한 바람직하지 않다.

불행히도, 용인할 수 없는 패킷 손실을 야기하는 혼잡 상태들을 초래하지 않고 네트워크 채널의 이용가능 대역폭을 효율적으로 사용하는 방식으로 신뢰할 수 없는 프로토콜을 사용하는 데이터의 전송이 상당한 도전이다. 전통적인 혼잡 제어 기술들은 흔히, 송신기 내장(built in) 전송 계층으로의 피드백을 갖는 TCP와 같은 신뢰할 수 있는 프로토콜들에 대해서만 적합하지만, 이들은, 전형적으로 사용자에 의해 전송 계층을 통해 독립적으로 부가되지 않는 한 요구되는 피드백을 갖지 않는 UDP와 같은 다수의 신뢰할 수 없는 프로토콜들에 대해서는 비효율적이다. 또한, TCP 또는 다른 신뢰할 수 있는 프로토콜들에 대해 설계된 혼잡 제어 또는 혼잡 회피 알고리즘들은 일반적으로 고속 실-시간 스트리밍 애플리케이션들이 아니거나, 또는, 혼잡에 응답하는 비트레이트의 지수적 감소가 결과적으로 실-시간 신호의 품질의 너무 많은 손해를 야기할 수 있기 때문에, 신뢰할 수 없는 프로토콜들을 수반하는 다수의 데이터 전송 애플리케이션들에 대해 부적절할 수 있다. 또한, 혼잡의 지점으로의 증가하는 비트레이트에 기인하는 패킷 손실이 TCP 또는 데이터의 재송신을 위한 다른 신뢰할 수 있는 프로토콜들을 사용하는 시간에 덜 민감한 애플리케이션들에서 허용될 수 있지만, 반면 이는 데이터를 재구성하기 위한 수신기의 결과적인 불능에 기인하여 다수의 실-시간 애플리케이션들에서 용인될 수 없을 수 있다.

따라서, UDP 및 다른 신뢰할 수 없는 프로토콜들과 함께 사용하기에 적절한 효율적인 혼잡 제어 및 혼잡 회피 기술들에 대한 요구가 당업계에 존재한다. 이는, 본 개시의 측면들이 발생하는 이러한 문맥 내에 존재한다.

본 개시의 특정 구현예들에 따르면, 송신기 컴퓨팅 시스템에 의해 수행되는 방법은, 신뢰할 수 없는 프로토콜을 통해, 데이터 패킷들의 스트림을 네트워크를 통해 적어도 하나의 수신기 디바이스로 전송하는 단계를 포함할 수 있다. 데이터 패킷들의 스트림은 소스 패킷들 및 순방향 오류 정정(FEC) 패킷들을 포함할 수 있다. 방법은, 상기 전송하는 단계 동안, 적어도 하나의 수신기 디바이스로부터 하나 이상의 피드백 리포트들을 수신하는 단계로서, 각각의 상기 주기적인 피드백 리포트는 대응하는 시간의 기간 동안의 패킷 손실을 특징짓는, 단계를 포함할 수 있다. 방법은 또한, 상기 전송하는 단계 동안, 상기 피드백 리포트들 중 적어도 하나에 응답하여 상기 데이터 패킷들이 스트림 내에서 전송되는 레이트를 조정하는 단계를 포함할 수 있다. 레이트를 조정하는 단계는, 패킷 손실을 용인가능 레벨 내에 있는 것으로서 특징짓는 피드백 리포트들 중 하나에 응답하여, 소스 패킷들이 전송되는 소스 레이트를 유지하면서, FEC 패킷들이 전송되는 FEC 레이트를 증가시키는 단계를 포함할 수 있다.

본 개시의 특정 구현예들에 따르면, 송신기 컴퓨팅 디바이스는 적어도 하나의 프로세서 유닛, 및 적어도 하나의 프로세서 유닛에 결합된 적어도 하나의 메모리 유닛을 포함할 수 있다. 적어도 하나의 프로세서 유닛 및 적어도 하나의 메모리 유닛은 방법을 수행하도록 구성될 수 있다. 방법은, 신뢰할 수 없는 프로토콜을 통해, 데이터 패킷들의 스트림을 네트워크를 통해 적어도 하나의 수신기 디바이스로 전송하는 단계를 포함할 수 있다. 데이터 패킷들의 스트림은 소스 패킷들 및 순방향 오류 정정(FEC) 패킷들을 포함할 수 있다. 방법은, 상기 전송하는 단계 동안, 적어도 하나의 수신기 디바이스로부터 하나 이상의 피드백 리포트들을 수신하는 단계로서, 각각의 상기 주기적인 피드백 리포트는 대응하는 시간의 기간 동안의 패킷 손실을 특징짓는, 단계를 포함할 수 있다. 방법은 또한, 상기 전송하는 단계 동안, 상기 피드백 리포트들 중 적어도 하나에 응답하여 상기 데이터 패킷들이 스트림 내에서 전송되는 레이트를 조정하는 단계를 포함할 수 있다. 레이트를 조정하는 단계는, 패킷 손실을 용인가능 레벨 내에 있는 것으로서 특징짓는 피드백 리포트들 중 하나에 응답하여, 소스 패킷들이 전송되는 소스 레이트를 유지하면서, FEC 패킷들이 전송되는 FEC 레이트를 증가시키는 단계를 포함할 수 있다.

본 개시의 특정 구현예들에 따르면, 비-일시적인 컴퓨터 판독가능 매체는, 그 내부에 구현된 컴퓨터 판독가능 명령어들을 포함할 수 있다. 컴퓨터 판독가능 명령어들은 실행될 때 방법을 구현하도록 구성될 수 있다. 방법은, 신뢰할 수 없는 프로토콜을 통해, 데이터 패킷들의 스트림을 네트워크를 통해 적어도 하나의 수신기 디바이스로 전송하는 단계를 포함할 수 있다. 데이터 패킷들의 스트림은 소스 패킷들 및 순방향 오류 정정(FEC) 패킷들을 포함할 수 있다. 방법은, 상기 전송하는 단계 동안, 적어도 하나의 수신기 디바이스로부터 하나 이상의 피드백 리포트들을 수신하는 단계로서, 각각의 상기 주기적인 피드백 리포트는 대응하는 시간의 기간 동안의 패킷 손실을 특징짓는, 단계를 포함할 수 있다. 방법은 또한, 상기 전송하는 단계 동안, 상기 피드백 리포트들 중 적어도 하나에 응답하여 상기 데이터 패킷들이 스트림 내에서 전송되는 레이트를 조정하는 단계를 포함할 수 있다. 레이트를 조정하는 단계는, 패킷 손실을 용인가능 레벨 내에 있는 것으로서 특징짓는 피드백 리포트들 중 하나에 응답하여, 소스 패킷들이 전송되는 소스 레이트를 유지하면서, FEC 패킷들이 전송되는 FEC 레이트를 증가시키는 단계를 포함할 수 있다.

본 개시의 교시들은 첨부된 도면들과 함께 다음의 상세한 설명을 고려함으로써 용이하게 이해될 수 있다.
도 1은 본 개시의 특정 측면들에 따른 예시적인 데이터 전송 및 순방향 오류 정정 기술의 개략도이다.
도 2는 본 개시의 특정 측면들에 따른 예시적인 혼잡 제어 기술의 흐름도이다.
도 3은, 본 개시의 특정 측면들에 따른 적어도 하나의 수신기 디바이스로부터의 피드백에 응답하여 송신기 디바이스가 비트레이트 레이트를 조정하는 상세화된 예의 흐름도이다.
도 4는 본 개시의 특정 측면들에 따른 예시적인 시스템의 블록도이다.

다음의 상세한 설명이 예시의 목적들을 위한 다수의 특정한 세부사항들을 포함하지만, 당업자는 다음의 세부사항들에 대한 다수의 변형들 및 변경들이 본 발명의 범위 내에 속한다는 것을 이해할 것이다. 따라서, 이하에서 설명되는 본 개시의 예시적인 구현예들은 청구된 발명에 대해 제한들을 부여하지 않고 이에 대한 일반성의 어떠한 상실도 없이 기술된다.

소개

본 개시의 측면들은 UDP와 같은 신뢰할 수 없는 전송 프로토콜과 함께 사용될 수 있는 혼잡 제어 및/또는 혼잡 회피 기술들에 관한 것이다.

특정 측면들에 따르면, 하나 이상의 송신기 디바이스들은 UDP와 같은 신뢰할 수 없는 전송 프로토콜을 사용하여 하나 이상의 수신기 디바이스들로 데이터 패킷들을 전송할 수 있다. 데이터 패킷들은, 희망되는 소스 데이터를 포함하는 소스 패킷들뿐만 아니라, 소스 패킷들 중 하나 이상이 하나 이상의 수신기 디바이스들에 도달하는데 실패하는 경우의 오류 정정을 위한 소스 데이터의 중복들을 포함하는 FEC 패킷들 둘 모두를 포함할 수 있다. 주기적인 피드백 리포트들이 하나 이상의 수신기 디바이스들로부터 하나 이상의 송신기 디바이스들로 전송될 수 있다. 피드백 리포트들은 대응하는 시간의 기간 동안의 패킷 손실을 식별할 수 있으며, 송신기는 시간의 기간 동안 패킷 손실이 발생하였는지 여부를 식별하기 위하여 및/또는 대응하는 시간의 기간 동안의 패킷 손실의 정도를 식별하기 위하여 피드백 리포트들을 사용할 수 있다. 패킷 손실은, 예를 들어, 송신기가 데이터 스트림 내로 너무 높은 비트레이트를 제공한 결과로서 발생할 수 있다.

특정 측면들에 따르면, 하나 이상의 송신기 디바이스들은 하나 이상의 수신기 디바이스들로 전송되는 스트림 내의 데이터 패킷들의 비트레이트의 측면들을 조정하기 위하여 주기적인 피드백 리포트들을 사용할 수 있다. 비트레이트의 측면들은, 소스 데이터를 획득하기 위한 수신기 디바이스의 능력을 최적화하는 방식으로 조정될 수 있다. 특정 측면들에 있어, 패킷 손실이 용인가능한 레벨 내에 있다는 것을 나타내는 피드백 리포트에 응답하여, FEC 패킷들의 비트레이트가 증가될 수 있으며, 동시에 스트림 내의 소스 패킷들의 동시 비트레이트는 초기 피드백 리포트에 응답하여 유지될 수 있다. 특정 측면들에 따르면, 비트레이트가 오류 정정을 위해 사용되는 FEC 패킷들의 수만을 증가시킴으로써 조정될 수 있기 때문에, 하나 이상의 수신기 디바이스들은, 비트레이트의 증가가 혼잡 및 증가된 패킷 손실을 야기하는 경우에도 소스 데이터를 재구성하는 것이 가능할 수 있다. 예를 들어, FEC 패킷들 대 소스 패킷들의 비율이 증가될 수 있기 때문에, FEC 패킷들이 전달 동안의 소스 패킷들의 손실에 기인하는 데이터를 재구성하기에 충분한 숫자로 성공적으로 전달될 가능성이 높다.

추가적인 세부사항들

이제 도 1로 돌아오면, 본 개시의 특정 측면들에 따른 예시적인 데이터 전송 및 순방향 오류 정정(FEC) 기술의 예시적인 예가 도시된다. 도 1의 예에 있어서, 하나 이상의 송신기 디바이스들(102)은 네트워크(106)를 통해 하나 이상의 수신기 디바이스들(104)로 데이터를 전송할 수 있으며, 데이터는 복수의 데이터 패킷들(108)의 형태로 송신될 수 있다. 데이터 패킷들(108)은, 각각의 패킷(108)의 전달 또는 패킷들(108)의 순서대로의 전달이 프로토콜에 의해 보증되지 않는 UDP와 같은 신뢰할 수 없는 프로토콜을 사용하여 전송되는 데이터그램들일 수 있다. 따라서, 패킷 손실의 경우에, 송신기 디바이스(102)가 손실된 패킷들을 재송신하지 않으며; 오히려, 수신기 디바이스(104)가 사용되는 특정 FEC 기술에 의해 데이터 스트림 내로 인코딩된 중복들을 사용하여 손실된 소스 데이터 패킷을 재구성하려고 시도할 수 있다.

도 1에 도시된 바와 같이, 데이터 패킷들(108)은, 수신기 디바이스(104)로 전달되는 원래의 소스 데이터(110)를 포함하는 소스 패킷들(도 1의 음영진 박스들) 및, 충분한 다른 소스 또는 패러티(parity) 패킷들이 이용가능하기만 하면, 그것이 임의의 손실된 소스 패킷들을 대신하는 것을 가능하게 하는 정보를 포함하는 패러티 패킷들인 FEC 패킷들(도1의 백색/공백 박스들) 둘 모두를 포함할 수 있다. FEC 패킷들은 원래의 소스 데이터(110)의 중복들을 포함할 수 있으며, 이들은, 소스 패킷들 중 하나 이상이, 이들이 네트워크(106)에 의해 드롭되었기 때문에 수신기(104)에 적절하게 도달하는데 실패하는 경우, 소스 데이터(110)를 재구성하기 위해 수신기 디바이스(104)에 의해 사용될 수 있다. 송신된 데이터가 오디오 및 비디오 스트림을 포함하는 특정 구현예들에 있어서, 데이터 패킷들(108)은, 전술된 유형들의 둘 모두의 오디오 패킷들 및 비디오 패킷들 둘 모두를 더 포함할 수 있으며, 예를 들어, 데이터 패킷들(108)이 오디오 소스 패킷들, 오디오 FEC 패킷들, 비디오 소스 패킷들, 및 비디오 FEC 패킷들을 포함할 수 있고, 오디오 패킷들이 일반적으로 비디오 패킷들보다 더 작을 수 있다(즉, 더 적은 양의 데이터를 포함할 수 있다).

특정 구현예들에 있어서, 소스 데이터(110)는 실-시간으로 수신기 디바이스(104)로 송신되는 데이터 스트림일 수 있으며, 소스 데이터(110)는 송신기 디바이스(102) 상에서 구동되고 있는 애플리케이션에 의해 생성될 수 있다. 이러한 구현예들에 있어, 실-시간 소스 데이터(110)는, 차례로 출력되는 데이터의 복수의 프레임들로 이루어질 수 있으며, 프레임들은 소스 데이터를 생성하는 애플리케이션에 의해 정의될 수 있다. 예를 들어, 소스 데이터(110)는, 비디오 게임, 비디오 전화 프로그램, 또는 다른 A/V 소스 프로그램과 같은 송신기 디바이스(102) 상에서 구동되고 있는 애플리케이션으로부터 출력되는 실-시간 오디오/비디오(A/V) 스트림일 수 있으며, 애플리케이션이 각각의 프레임을 정의할 수 있다.

도 1의 예에 있어, 소스 데이터(110)의 예시된 블록은, 이에 대해 복수의 소스 패킷들 및 FEC 패킷들이 생성되고 네트워크(106)를 통해 수신기 디바이스(104)로 송신되는, 단일 프레임, 예를 들어, 단일 A/V 프레임에 대응할 수 있다. 데이터의 스트림은 복수의 프레임들(110)로 이루어질 수 있으며, 이들은 송신기 디바이스(102)에서 순차적으로 생성될 수 있고, 복수의 데이터 패킷들(108)은 수신기 디바이스(104)로의 송신을 위한 각각의 프레임에 대해 형성될 수 있다.

데이터가 UDP 또는 다른 신뢰할 수 없는 프로토콜을 사용하여 송신될 때, 데이터 패킷들(108), 예를 들어, 데이터그램들이 상이한 개별적인 경로들을 통해 네트워크(106)에 의해 라우팅될 수 있고, 비순서적으로 수신기 디바이스에 도착할 수 있다는 것을 주의해야 한다. 수신기 디바이스(104)에서의 데이터의 재구성을 가능하게 하기 위하여, 데이터 패킷들(108)의 각각이 특정 식별 정보와 함께 송신기 디바이스에 의해 스탬핑(stamp)될 수 있다. 예를 들어, 각각의 데이터 패킷(108)은, 데이터 패킷이 속해야 하는 프레임의 순서를 나타내는 프레임 식별자, 예를 들어, 프레임 번호(number)뿐만 아니라, 데이터 패킷이 속해야 하는 각각의 프레임 내의 (및/또는 프레임에 걸친) 순서를 나타내는 시퀀스 식별자, 예를 들어, 시퀀스 번호를 가지고 스탬핑될 수 있다. 따라서, 송신기 디바이스(102)는 생성되는 각각의 새로운 데이터 패킷에 대한 시퀀스 번호를 증분(increment)할 수 있으며, 생성되는 각각의 새로운 프레임에 대한 데이터 패킷들의 프레임 번호를 증분할 수 있다. 선택적으로, 데이터 패킷들(108)이 또한, 추가적인 식별 정보, 예컨대, 데이터 스트림이 오디오 및 비디오 컴포넌트 둘 모두를 갖는 실-시간 데이터 스트림인 구현예들에 있어, 예를 들어, 패킷이 오디오 또는 비디오 패킷인지 여부를 식별하는 유형 식별자를 가지고 추가적으로 스탬핑될 수 있다. 수신기 디바이스(104)는 각각의 패킷에 대해 스탬핑된 이러한 추가 정보에 따라 데이터를 어셈블(assemble)할 수 있으며, 그에 따라서, 예를 들어, 수신기 측에서의 최종-사용자에게 표시하기 위해 데이터를 디코딩할 수 있다.

소스 패킷들 중 하나 이상의 네트워크(106)에 의해 드롭되거나 또는 달리 그들의 목적지에 도달하는데 실패하는 패킷 손실의 경우에 있어, 수신기 디바이스(104)는, 도 1에 도시된 바와 같이, 송신기 디바이스(102)에 의해 재송신 없이 소스 데이터(110)를 재구성하기 위해 중복적으로 코딩된 FEC 패러티 패킷들을 사용할 수 있다. 임의의 수의 FEC 패러티 패킷들이 상이한 알고리즘들을 사용하여 하나 이상의 소스 패킷들로부터 생성될 수 있다는 것을 주의해야 한다. 특정 구현예들에 있어, FEC는 삭제 코드(erasure code)를 사용하여 생성될 수 있다. 특정 구현예들에 있어, 삭제 코드는 리드-솔로몬 코드(Reed-Solomon code)일 수 있다. 다른 것들 중에서도, 삭제 코딩을 지원하며 본 개시의 구현예들에서 사용될 수 있는 개방 소스 라이브러리 비-제한적인 일 예는 제이이레이저(Jerasure)로서 알려져 있다. 특정 구현예들에 있어, 오류 정정 기법은, 수신기에 도달하는데 실패한 각각의 소스 패킷에 대하여, 데이터의 특정 세트를 재구성하기 위해 하나의 FEC 패킷이 요구될 수 있는 그런 것일 수 있다. 예를 들어, 수신기 디바이스로 전달되는 데이터의 특정 프레임에 대하여, FEC 기술은, 패킷 손실의 경우에 프레임을 완전히 재구성하기 위하여, 적절하게 수신기 디바이스에 도달한 FEC 패킷들의 수가 손실된 소스 패킷들의 수와 적어도 동일할 것이 요구되는, 기술일 수 있다. 그렇지 않으며, 프레임이 붕괴될 것이다. 다시 말해서, N개의 소스 패킷들이 존재하고 M개의 패러티 패킷들이 생성되었던 경우, 소스 데이터는, 적어도 총 N개의 패킷들(소스 및 패러티)이 수신될 때 복원될 수 있다. 도 1의 예시에 있어, 송신기에 의해 전송되는 소스 패킷들의 수는 전송되는 FEC 패킷들의 수와 동일하며, 즉, 송신기(102)에 의해 송신되는 소스 패킷들 대 FEC 패킷들의 비율이 예시를 단순화하기 위하여 단순히 1:1이다. 그러나, 다수의 다른 비율들이 사용될 수 있으며, 소스 패킷들 대 FEC 패킷들의 비율이, 이하에서 설명되는 바와 같이, 본 개시의 특정 측면들에 따라 스트리밍 동안 시간의 경과에 따라 동적이며 변화될 수 있다는 것을 주의해야 한다.

데이터 전송 동안 사용되는 이용가능 대역폭을 효율적으로 사용하는 방법뿐만 아니라 용인가능하지 않은 패킷 손실을 트리거하는 방식으로 네트워크 채널을 과부화시키는 것을 회피하는 방법을 최적화하기 위하여, 송신기 디바이스(102) 및/또는 수신기 디바이스(104)는 본 개시의 측면들에 따른 혼잡 제어 알고리즘을 구현하도록 구성될 수 있다.

이제 도 2를 참조하면, 하나 이상의 송신기 디바이스(202)과 하나 이상의 수신기 디바이스(204) 사이의 혼잡 제어 기술의 예시적인 일 예의 흐름도가 도시된다. 특정 구현예들에 있어, 혼잡 제어 기술은 도 1에 도시된 데이터 전송 및 오류 정정 기술의 적어도 일부 측면들과의 유사성을 가질 수 있다.

본 개시의 다양한 측면들에 따르면, 송신기 디바이스(202)는 네트워크(206)를 통해 적어도 하나의 수신기 디바이스(204)로 원래의 소스 데이터(212)를 전송하도록 구성될 수 있다. 예로서, 그리고 비제한적으로, 네트워크(206)는 인터넷, WAN, LAN, 또는 그들의 목적지로 데이터 패킷들을 라우팅하기 위하여 패킷 스위칭을 사용하는 다른 네트워크일 수 있다. 특정 구현예들에 있어서, 송신기 디바이스(202)는 송신기 디바이스 상에서 구동되고 있을 수 있는 애플리케이션으로부터 소스 데이터(212)를 수신할 수 있으며, 송신기 디바이스는 UDP와 같은 신뢰할 수 없는 전송 프로토콜을 사용하여 소스 데이터(212)를 실-시간으로 수신기 디바이스(204)로 송신하도록 구성될 수 있다.

특정 구현예들에 있어서, 소스 데이터(212)는 네트워크를 통한 송신 전에 압출될 필요가 있는 유형일 수 있으며, 송신기 디바이스는 214에 표시된 바와 같이 소스 데이터를 압축하도록 구성될 수 있다. 예로서, 그리고 비제한적으로, 소스 데이터는 실-시간 오디오 스트림, 실-시간 비디오 스트림, 또는 둘 모두(즉, 실-시간 오디/비디오 스트림)을 포함할 수 있으며, 송신기 디바이스는 오디오 및/또는 비디오 인코더를 사용하여 데이터를 다양한 압축 포맷들 중 임의의 압축 포맷으로 압축할 수 있다. 특정 구현예들에 있어, 소스 데이터는 저 레이턴시 코덱을 사용하여 인코딩될 수 있다. 예를 들어, 소스 데이터는, 저 레이턴시 비디오 코덱의 일 예인 h.264 포맷에 따라 인코딩된 실-시간 비디오 스트림을 포함할 수 있다. 추가적인 예로서, 소스 데이터는, 저 레이턴시 오디오 코덱의 예 및 CELT 포맷에 따라 인코딩된 실-시간 오디오 스트림을 포함할 수 있다.

그런 다음, 송신기 디바이스(202)는, 애플리케이션으로부터 압축된 또는 압축되지 않은 형태로 수신된 바와 같은 소스 데이터를, 216 및 218에 표시된 바와 같이, 복수의 데이터 패킷들을 형성함으로써 송신을 위해 준비할 수 있다. 데이터 패킷들을 형성하는 것은, 데이터 패킷을 형성하기 위하여 소스 데이터의 세트를 복수의 이산 페이로드들로 분할하고 각각의 페이로드에 추가 데이터를 부가하는 것을 수반할 수 있다. 송신기 디바이스(202)에 의해 형성된 데이터 패킷들은, 216에서 표시된 바와 같이 (도 2의 예시된 예에 대해 압축된 포맷의) 소스 데이터(212)를 포함하는 소스 패킷들, 및 218에서 표시된 바와 같이, 어떤 오류 정정 코드에 따라 형성될 수 있으며 소스 데이터(212)의 중복들을 포함하는 FEC 패킷들을 포함할 수 있다.

본 개시의 특정 측면들에 따르면, 소스 데이터(212)는, 송신기 디바이스(202) 상에서 구동되고 있는 애플리케이션에 의해 정의될 수 있는 복수의 프레임들로 구성될 수 있으며, 송신기 디바이스는 각각의 프레임에 대하여 소스 패킷들 및 FEC 패킷들을 포함하는 복수의 데이터 패킷들을 형성할 수 있다. 본 개시의 특정 구현예들에 있어서, 데이터 패킷들을 전송하기 이전에, 송신기 디바이스(202)가 송신 프로세스에서의 사용을 위해 데이터 패킷들의 각각을 특정 식별 정보로 스탬핑할 수 있다. 특정 측면들에 따르면, 216 및 218에 표시된 바와 같이 각각의 데이터 패킷들에 부가된 스탬프 정보는, 프레임 식별자, 예를 들어, 각각의 데이터 패킷이 속해야 하는 프레임을 나타내는 프레임 번호, 및 시퀀스 식별자, 예를 들어, 각각의 데이터 패킷이 프레임들 내에서 및 프레임들에 걸쳐 연장하는 어떤 시퀀스에 속해야 하는지를 나타내는 시퀀스 번호를 포함할 수 있다. 따라서, 송신기 디바이스는 각각의 별개의 데이터 패킷과 함께 시퀀스 번호를 증분하고, 데이터의 각각의 별개의 프레임과 함께 프레임 번호를 증분하도록 구성될 수 있다. 소스 데이터가 실-시간 오디오 및 비디오 스트림을 포함하는 것에서의 이러한 것들과 같은, 특정 구현예들에 있어서, 스탬프 정보는 또한 선택적으로, 특정 데이터 패킷이 오디오 데이터 또는 비디오 데이터를 포함하고 있는지 여부를 식별할 수 있는 매체 유형 식별자를 포함할 수 있다. 그런 다음, 송신기 디바이스는, 데이터 패킷들이 형성되고 스탬핑된 후, 220에 표현된 바와 같이, 네트워크(206)를 통한 하나 이상의 수신기 디바이스들(204)로의 전달을 위해 데이터 패킷들을 전송할 수 있다.

시퀀스 번호는 각각의 새로운 패킷에 대하여 미리 결정된 양(예를 들어, 1)만큼 증분될 수 있다. 수신기 디바이스(204)는 얼마나 많은 패킷들이 유실되었는지를 결정하기 위하여 수신된 패킷들의 시퀀스 번호를 사용할 수 있다. 스탬프 정보는 또한, 얼마나 많은 패킷들이 프레임 내에 존재하는지 및 주어진 패킷이 프레임 내의 어떤 패킷 인덱스인지를 결정하기 위한 엑스트라(extra) 정보를 포함할 수 있다.

수신기 디바이스(204)는, 적절하게 전달된 이러한 데이터 패킷들, 예를 들어, 네트워크(206)에 의해 드롭되지 않은 이러한 데이터 패킷들을 수신할 수 있으며, 수신기 디바이스(204)는, 222에서 표시되는 바와 같이 이들이 도착함에 따라 데이터 패킷들을 축적(accumulate)할 수 있다. 수신기 디바이스(204)는, 그에 따라 수신된 데이터를 어셈블하기 위하여, 예를 들어, 프레임 및 시퀀스 식별자 정보를 포함하는 각각의 패킷과 함께 포함된 추가 정보를 사용할 수 있다. 수신기 디바이스(204)는 또한, 사용되는 특정 오류 정정 기술에 따라 FEC 패킷들을 사용하여 임의의 손실된 소스 패킷들을 재구성할 수 있다.

특정 측면들에 따르면, 수신기 디바이스(204)는, 224에 표시된 바와 같이, 각각의 패킷과 함께 포함된 스탬프 정보로부터 주어진 시간 기간에 대한 패킷 손실을 주기적으로 결정하도록 구성될 수 있다. 특정 구현예들에 있어서, 수신기 디바이스(204)는, 특정 기간에 대한 패킷 손실의 레이트를 결정하기 위하여, 시간 기간 동안에 수신된 데이터 패킷들의 총 수와 그 시간 기간 동안의 수신된 패킷들에 스탬핑된 시퀀스 정보를 비교할 수 있다. 예를 들어, 시퀀스 식별자들이 각각의 새로운 패킷과 함께 증분되기 때문에, 이들은, 모든 패킷들이 적절하게 전달되었던 경우 특정 시간 기간 동안 수신되었어야 할 데이터 패킷들의 총 수를 나타낼 수 있다. 수신기 디바이스(204)는 그 기간에 대한 패킷 손실을 계산하기 위하여, 시퀀스 식별자들로부터 결정된 예측된 패킷들의 이러한 수와 시간 기간 동안 실제 수신된 패킷들의 수를 비교할 수 있다. 그런 다음, 수신기 디바이스(204)는, 226에 표시된 바와 같이, 패킷 손실을 특정한 시간 기간에 대한 피드백 정보로서 송신기 디바이스(202)로 전송할 수 있다.

수신기 디바이스로부터 피드백 정보를 다시 송신기 디바이스로 전송하기 위해 사용되는 전송 프로토콜이 송신기로부터 수신기로 데이터 패킷들을 전송하기 위해 사용되었던 신뢰할 수 없는 프로토콜과 동일한 프로토콜일 수 있거나, 또는 상이한 프로토콜일 수 있다는 것을 주의해야 한다. 예를 들어, 송신기로부터 수신기로 데이터 패킷들을 전송하기 위해 사용된 신뢰할 수 없는 프로토콜이 UDP와 같은 비연결형 프로토콜일 수 있다. 특정 구현예들에 있어, 수신기 디바이스로부터 송신기 디바이스로의 신뢰할 수 있는 채널이 UDP를 통해 생성될 수 있다. 본 개시의 특정 구현예들에서 사용될 수 있는 UDP를 통해 신뢰할 수 있는 채널을 생성하기 위한 개방 소스 해법의 일 예는 유에스알에스씨티피(usrsctp)이다. 다른 구현예들에 있어서, 수신기 디바이스로부터 송신기 디바이스로 피드백 리포트들을 전송하기 위한 신뢰할 수 있는 백채널은, 완전히 별개의 연결, 예컨대, 별개의 신뢰할 수 있는 프로토콜, 예를 들어, TCP를 사용하여 수립될 수 있거나 또는 어떤 다른 신뢰할 수 있는 프로토콜을 사용하여 수립된 신뢰할 수 있는 채널을 사용하여 수립될 수 있다. 특정 구현예들에 있어서, 송신기로부터 수신기로 전송되는 소스 데이터에 비하여, 이러한 데이터의 상이한 성질 및 속성에 기인하여 피드백 정보를 확실하게 전송하는 것이 바람직할 수 있다.

특정 구현예들에 있어, 송신기 디바이스(202)는, 228에 표현된 바와 같이, 수신기 디바이스로부터 수신된 피드백 정보 내의 패킷 손실을 정규화(normalize)할 수 있다. 이는, 정규(regular) 스트리밍 기간 동안 전송되는 예측된 양의 패킷들에 대응할 수 있는, 미리-결정된 패킷들의 양에 대하여 패킷 손실을 정규화함으로써 달성될 수 있다. 예를 들어, 수신기 디바이스가 수신된 패킷들 대 시퀀스 정보로부터 결정된 바와 같은 예측된 패킷들의 비율로서 패킷 손실을 결정하는 경우, 이러한 비율은, 실제 전송된 데이터 패킷들의 양이 송신기 디바이스에 의해 송신될 수 있었던 것보다 훨씬 더 작은 경우, 패킷 손실을 과대평가하는 경향이 있을 수 있다. 더 상세화된 예로서, 송신기 디바이스가 4개의 패킷들을 전송했지만, 수신기 디바이스가 특정 기간 동안 3개의 패킷들만을 수신한 경우, 수신기 디바이스는 패킷 손실이 25%라고 결정할 수 있다. 그러나, 송신기 디바이스가 이러한 기간 동안 100개의 패킷들을 전송할 수 있었지만, 전송되어야 할 모든 데이터가 4개여서 4개만을 전송한 경우, 진짜 패킷 손실은, 4개 중 하나의 패킷 손실이 아니라, 100개중 하나의 패킷 손실로서, 즉, 25% 대신 1%로서 더 정확하게 표현될 수 있다. 더 일반적인 예로서, 정규 스트리밍 동안, 시간 기간 X 동안 N개의 패킷들이 수신되어야만 한다는 것이 미리-정의될 수 있다. X 동안, 수신기 디바이스가 N/2개의 패킷들에 기초하여, 즉, 데이터 패킷들의 시퀀스 번호들에 기초하여 패킷 손실을 리포팅하는 경우, 임의의 손실은 송신기에 의해 N/2개 중에서가 아니라, N개 중에서의 손실된 패킷들의 수로 정규화되어야만 한다. 따라서, 송신기 디바이스는, 하나 이상의 수신기 디바이스들(204)로부터 수신된 패킷 손실을 시간 기간 동안에 전송될 것으로 예측된 데이터 패킷들의 미리 결정된 수에 대하여 정규화하도록 구성될 수 있다.

특정 측면들에 따르면, 수신기 디바이스(204)로부터 수신된 (송신기 측에서 선택적으로 추가로 정규화되는) 피드백 정보에 응답하여, 송신기 디바이스(202)는, 230에 표시된 바와 같이, 본원에서 설명되는 혼잡 제어의 특정 원리들에 따라 송신기 디바이스가 데이터 패킷들을 전송하는 레이트를 조정할 수 있다. 특정 예들에 있어, 대응하는 시간 기간 동안의 패킷 손실이 용인가능한 레벨 내에 있었다는 것을 나타내는 피드백 정보의 세트에 응답하여, 송신기 디바이스는 스트림의 비트레이트를 증가시키도록 구성될 수 있지만, 송신기 디바이스는, 소스 패킷들이 전송되는 비트레이트를 유지하거나 또는 달리 이를 증가시키지 않으면서, FEC 패킷들이 전송되는 비트레이트만을 처음에 증가시킴으로써 이를 수행할 수 있다. 피드백 정보에 응답하여 비트 레이트가 조정될 수 있는 방법에 관한 추가적인 측면들은 본 개시의 다른 곳에서 설명된다.

도 2에 도시된 예시적인 방법이 연속적이거나 또는 반복되는 프로세스일 수 있으며, 소스 데이터(212)가 송신되고 있는 한 계속될 수 있다는 것을 주의하는 것이 중요하다. 특정 구현예들에 있어서, 송신기 디바이스(202)가 피드백 정보에 직접적으로 응답하여 데이터 패킷들이 전송되는 비트레이트를 주기적으로 조정할 수 있도록, 피드백 정보는, 데이터 송신 동안 수신기 디바이스(204)에 의해 주기적으로 송신기 디바이스(202)로 전송될 수 있다. 더 빈번하게 피드백 정보를 전송하는 것이 스트림의 응답성을 증가시킬 수 있지만, 피드백 정보를 처리하기 위한 (즉, 수신기로부터 송신기로의) 업스트림(upstream) 대역폭의 감소의 트레이드오프가 존재한다. 특정 구현예들에 있어, 피드백 리포트들은 초당 5번, 즉, 200 밀리초(ms)마다 전송될 수 있다. 추가적인 구현예들에 있어, 피드백 리포트들은 100 ms마다 내지 1 초마다의 범위 내에서 전송될 수 있다. 피드백이 너무 빈번하게 전송되는 경우, 예를 들어, 100 ms마다 한번 전송되는 경우, 수신기는 패킷 손실을 결정하기 위해 유용한 수의 패킷들을 축적할 충분한 시간을 갖지 못할 수 있으며, 이는 너무 작은 샘플 크기일 수 있다. 대조적으로, 충분히 자주 전송되지 않는 경우, 예를 들어, 1초마다 한번 미만으로 전송되는 경우, 이는 유용하기에는 충분하지 않을 수 있다.

특정 구현예들에 있어, 송신기 디바이스가 데이터 패킷들을 복수의 수신기 디바이스들로 전송할 수 있으며, 복수의 상이한 목적지 시스템들로부터의 피드백 리포트들에 응답하여 비트레이트를 조정할 수 있다는 적을 주의해야 한다. 특정 구현예들에 있어, 이는, 각각의 개별적인 수신기 디바이스에 대하여 송신기 디바이스 상에서의 개별적인 인코딩을 이용하여 달성될 수 있으며, 이러한 경우에 있어, 송신기 디바이스는 그들의 개별적인 피드백 정보에 기초하여 개별적인 수신기 디바이스들에 대한 비트레이트를 독립적으로 조정하도록 구성될 수 있다. 다른 구현예들에 있어, 송신기 디바이스는 복수의 수신기 디바이스들을 지원하는 하나의 인코더를 포함할 수 있으며, 이러한 경우에 있어, 이는 최저 품질 전송에 기초하여 모든 수신기 디바이스들에 대하여 비트레이트가 조정되게끔 할 수 있다.

수신기 디바이스로부터 수신된 피드백 정보에 응답하여 비트레이트가 송신기 디바이스에 의해 조정되는 방식은 임의의 특정 피드백 리포트에 대한 패킷 손실의 성질에 의존할 수 있다는 것을 주의해야 한다. 본 개시의 특정 측면들에 따른 피드백에 응답하여 비트레이트가 조정될 수 있는 방법의 특정한 예시적인 측면들이 도 3에 도시된다. 구체적으로, 도 3은, 본 개시의 특정 구현예들에 따른, 피드백 정보에 응답하여 신뢰할 수 없는 프로토콜을 통해 데이터가 전송되는 비트레이트를 조정하기 위한 예시적인 프로세스를 도시한다. 도 3에 도시된 비트레이트를 조정하는 예시적인 방법(330)이 도 2의 230에서 표현된 비트레이트의 조정과 공통되는 하나 이상의 측면들을 가질 수 있다는 것을 주의해야 한다. 도 3의 예가 단순히, 본 개시에 따라 레이트가 조정될 수 있는 방법의 특정 측면들만을 예시하기 위한 간략화된 예일뿐이라는 것을 주의하는 것이 또한 중요하다.

처음에, 송신기에 의해 모든 데이터 패킷들이 송신되는 레이트에 의해 정의된 스트림의 총 비트레이트가, 소스 패킷들이 전송되는 레이트에 의해 정의된 소스 비트레이트, 및 FEC 패킷들이 전송되는 레이트에 의해 정의된 FEC 비트레이트 둘 모두를 포함한다는 것을 주의하는 것이 중요하다. 도 3에 도시된 바와 같이, 하나 이상의 수신기 디바이스들로부터 송신기에 의해 수신되는 피드백 정보(332)에 응답하여 비트레이트가 조정되는 방법은, 일반적으로, 피드백 정보(332)가, 334에서 표현된 바와 같이, 개별적인 시간의 기간 동안의 패킷 손실이 용인가능한 레벨 내에 있었는지를 나타내는지 여부에 의존한다. 334에서 표시되는 용인가능한 레벨은 이전의 상태들과 관련하여 정의될 수 있다는 것을 주의해야 한다. 예를 들어, 그것이 이전의 상태들과 관련하여 안정적인 경우, 즉, 패킷 손실의 레벨이 상대적으로 일정하며, 이전의 피드백 리포트에서 표시된 패킷 손실에 대하여 변동되지 않은 경우, 표시되는 패킷 손실이 용인가능한 레벨 내에 있을 수 있다. 비트레이트가 조정되는 방법은 또한, 344에서 표시되는 바와 같이, 피드백 정보가 어떤 미리 결정된 총 패킷 손실 문턱값 이상을 나타내는지 여부에 의존할 수 있다.

특정 측면들에 따르면, 여기에서, 수신기 디바이스로부터의 특정 피드백 리포트(332)가 개별적인 기간 동안의 패킷 손실이 용인가능한 레벨 내에 있었다는 것을 나타내며, 이는, 송신기에 의해 송신되는 총 비트레이트가, 예를 들어, 네트워크 채널의 최대 이용가능 대역폭이 송신되는 스트림에 의해 가득 채워지지 않고 있기 때문에, 증가될 수 있다는 것을 나타낼 수 있다. 특정 구현예들에 있어서, 표시되는 패킷 손실은, 이것이 바로 이전의 피드백 리포트와 동일하거나 또는 이에 대하여 용인가능한 양의 변화 내에 있을 때, 용인가능한 레벨 내에 있을 수 있다. 따라서, 특정 구현예들에 있어서, 손실이 변동하지 않는 한, 패킷 손실이 증가될 수 있다. 그러나, 비트레이트를, 심지어 증분적으로, 맹목적으로 증가시키는 것이, 통상적으로 수신기 디바이스에서의 신호의 드롭 아웃(drop out) 또는 프레임들의 붕괴와 같은 용인할 수 없는 결과들을 초래할 수 있는 패킷 손실을 트리거할 수 있다.

따라서, 본 개시의 특정 구현예들은, 패킷 손실이 증가하지 않았거나 또는 달리 어떤 용인가능 레벨 내에 있다는 것, 예컨대 안정적으로 것으로서 표시될 때를 나타내는 피드백 리포트에 응답하여, 338에서 표시된 바와 같이, 소스 비트레이트를 유지하면서 처음에는 FEC 비트레이트만을 증가시킴으로써, 이러한 도전들을 처리할 수 있다. 중요하게, 그 결과가 FEC 패킷들의 더 큰 수일 것이기 때문에, 비트레이트의 증가가, 예를 들어, 채널 혼잡에 기인하는 패킷 손실을 야기하는 경우에도, 수신 디바이스는, 스트림 내의 결과적인 더 큰 양의 FEC 패킷들에 기인하여 임의의 손실된 소스 패킷들을 재구성할 수 있거나, 또는 적어도 재구성할 수 있는 아주 큰 가능성을 가질 것이다. 예를 들어, 적절하게 전달되는 FEC 패킷들의 수가 전송 동안 손실되는 소스 패킷들의 수보다 더 크거나 또는 적어도 이와 동등할 가능성이 훨씬 더 클 것이다. 또한, 데이터 전송의 레이트의 이러한 증가가 송신기 디바이스로의 요구되는 피드백을 제공할 수 있으며, 이는, 송신기 디바이스에 의해 수신되는 후속 피드백 리포트(332)가, 스트림 내에 더 큰 총 비트레이트를 반영할 것이며, 총 비트레이트의 증가가, 예를 들어, 채널 혼잡에 기인하여 패킷 손실이 변동되게끔 했는지 여부를 나타낼 것이기 때문이다.

증가된 비트레이트에 응답하여 패킷 손실이 계속해서 안정적인 경우, 예를 들어, 패킷 손실이 하나 이상의 후속 피드백 리포트들(332)에 의해 표시되는 바와 같이 제공된 데이터 패킷들에 응답하여 변동하지 않거나 또는 증가하지 않는 경우, 비트레이트에 대한 다음 조정은, 342에서 표시된 바와 같이, 이전의 FEC 증가와 동일한 양만큼, FEC 비트레이트의 이전 증가에 보조를 맞추어 소스 비트레이트를 증가시키는 것일 수 있다. 특정 구현예들에 있어서, 이는 바로 후속의 피드백 리포트에 응답하는 것일 수 있거나, 또는, 이는, 피드백(332)에 의해 표시되는 바와 같이, 패킷 손실이 간격 전체에 걸쳐 용인가능한 상태로 유지되는 한, 하나를 초과하는 피드백 리포트를 갖는 어떤 다른 시간 간격 이후일 수 있다. 다시 말해서, 340에서 표시된 바와 같이, 가장 최근의 변화가 소스 비트레이트를 유지하면서 FEC 비트레이트를 증가시키는 것이었던 경우, 패킷 손실이 계속해서 용인가능한 한, 이러한 다음 조정은, 이전의 FEC 증가와 동일한 양만큼의 소스 비트레이트의 증가일 수 있다. 그런 다음, 패킷 손실이 안정적이라는 것을 피드백(332)이 나타내는 한, 이러한 총 비트레이트가 계속해서 증분적으로 증가될 수 있다.

예로서, 그리고 비제한적으로, 340에서 표시된 바와 같은 가장 최근의 조정이 총 비트레이트의 증가가 아니었던 경우, 338에서 표시된 바와 같이, FEC 비트레이트를 100kb/s만큼 증가시킴으로써 스트림의 이용가능 대역폭이 테스트될 수 있다. 334에 표시된 바와 같이, 하나 이상의 후속 피드백 리포트들이 패킷 손실이 존재하지 않는다는 것을 나타내는 경우, 다음 조정은, 342에서 표시된 바와 같이 100kb/s만큼의 소스 비트 레이트의 증가일 수 있으며, FEC 비트레이트는 소스 비트레이트가 이러한 방식으로 증가될 때 유지될 수 있고, 이는 총 비트레이트의 다른 증가를 야기할 수 있다. 총 비트레이트는, 비트레이트 증가에 응답하여 패킷 손실이 변동될 때까지 이러한 방식으로 계속해서 증가될 수 있다. FEC 패킷들로 시작하면, 수신기 디바이스가 총 비트레이트의 초기 증가에 의해 트리거되는 패킷 손실의 경우에 손실된 소스 데이터를 재구성할 수 있다는 것이 보장된다. 또한, FEC 패킷들의 증가를 선행하는 것이, 소스 비트레이트가 증가될 수 있는지 여부를 결정하기 위한 희망되는 피드백을 생성할 수 있다.

예로서, 그리고 비제한적으로, 스트림의 총 비트레이트는 2000kb/s이며, 그 중 100kb/s는 FEC 패킷들의 비트레이트이며, 나머지 1900kb/s는 소스 패킷들의 비트레이트라고 하자. 대역폭을 테스트하기 위하여, 처음에 FEC 레이트가 200kb/s로 증가될 수 있다. 이제 총 대역폭은 2100kb/s이다. 추가적인 손실이 존재하지 않는다고 결정될 때, 소스 레이트가 이전의 FEC 레이트 증가의 양만큼 증가될 수 있다. 그러면, 소스 레이트는 1900kb/s + 100kb/s = 2000kb/s이 되며, 동시에 총 레이트는 총 (2000kb/s 소스) + (FEC의 100kb/s) = 2100kb/s이지만, 대역폭이 FEC를 다시 200kb/s로 만듦으로써 즉시 테스트될 수 있다. 따라서, 2000kb/s 소스 + 200kb/s FEC이다. 다음의 반복(iteration)은 다음의 반복 상에서의 2100kb/s 소스 + 200kb/s FEC일 수 있으며, 패킷 손실이 제공된 데이터에 응답하여 증가될 때까지, 2200kb/s 소스 + 200kb/s FEC 등이 이어진다.

특정 측면들에 따르면, 비트레이트가 증가되는 방식, 예를 들어, 338에서 FEC 비트레이트가 증가되는 방식이 다양한 고려사항들에 의존할 수 있다. 예를 들어, 비트레이트가 증가되는 양이 희망되는 바와 같이 변화할 수 있다. 또한, 별개 유형들의 소스 및 FEC 패킷들을 야기하는 별개 유형들의 소스 데이터를 갖는 구현예들에 있어, 비트레이트의 증가가 분포되는 방식이, 이러한 패킷들의 속성에 따라, 예를 들어, 패킷의 각각의 별개 유형의 상대적인 크기에 기초하여 변화할 수 있다.

예를 들어, 오디오/비디오 스트림의 실-시간 송신을 수반하는 특정 구현예들에 있어서, 총 비트레이트는, 오디오 패킷들이 전송되는 레이트에 의해 정의된 오디오 비트레이트, 및 비디오 패킷들이 전송되는 레이트에 의해 정의된 비디오 비트레이트에 의해 또한 정의될 수 있다. 이러한 구현예들에 있어서, 총 비트레이트는 적어도 4개의 별개의 유형들의 비트레이트들, 즉, 오디오 소스 비트레이트, 비디오 소스 비트레이트, 오디오 FEC 비트레이트, 및 오디오 소스 비트레이트를 포함할 수 있다. 각각의 비디오 패킷이 일반적으로 각각의 오디오 패킷보다 훨씬 더 클 수 있기 때문에, 비디오 FEC 패킷들에 대한 레이트만을 증가시킴으로써 비트레이트를 증가시키는 것이, 상대적으로 적은 수의 패킷들에 대해서도 너무 큰 증가를 초래할 수 있으며, 이는 증가에 의해 트리거되는 너무 많은 혼잡을 야기할 수 있다. 따라서, 이러한 구현예들에 있어서, 예를 들어, 338에서 표시된 바와 같은 비트레이트의 각각의 증가는, 프레임 당 비디오 FEC 패킷들의 수 및 프레임 단 오디오 FEC 패킷들의 수 둘 모두에서의 증가를 포함할 수 있다. 중요하게, 이러한 2개의 별개의 유형들의 패킷들에 대한 비트레이트가 증가되는 비율은, 예를 들어, 오디오 패킷들이 더 작으며, 그에 따라 총 대역폭에 대한 더 미세한 조정들을 가능하게 한다는 사실을 고려하기 위하여, 희망되는 바와 같이 그들의 상대적인 크기들에 따라 튜닝(tune)될 수 있다. 예로서, 그리고 비제한적으로, 각각의 반복으로 증가되는 오디오 FEC 비트레이트 대 증가되는 비디오 FEC 비트레이트의 비율은 2:1 내지 10:1의 범위 내에 있을 수 있다. 다시 말해서, 338에서 FEC 비트레이트를 증가시키는 것 또는 342에서 소스 비트레이트를 증가시키는 것은, 프레임 당 하나의 추가적인 비디오 패킷마다에 대하여 2개 내지 10개의 추가적인 오디오 패킷들로부터 전송하는 것을 포함할 수 있다.

본 개시의 추가적인 측면들에 따르면, 피드백 리포트가 그 대신에, 예를 들어, 334에서 표시된 바와 같이, 이전의 상태들에 대하여 변동되거나 또는 증가되었기 때문에, 패킷 손실이 더 이상 용인가능하지 않다는 것을 나타낼 때, 스트림의 비트레이트는 패킷 손실이 용인가능했을 때와는 상이한 방식으로 조정될 수 있다. 특정 구현예들에 있어서, 패킷 손실이 존재했다는 것을 나타내는 피드백 리포트에 응답하는, 초기 조정은, 346에서 표시된 바와 같이, 총 비트레이트를 유지하면서 FEC 패킷들 대 소스 패킷들의 비율을 증가시키는 것을 수반할 수 있다. 이러한 예시적인 초기 단계가 송신기 디바이스에 의해 송신되는 총 비트레이트의 감소를 수반하지 않기 때문에, FEC 패킷들 대 소스 패킷들의 비율만의 변화는, 이러한 손실이 채널 내의 혼잡에 기인하는 경우, 패킷 손실을 감소시키지 않을 수 있다. 그러나, 스트림 내의 더 많은 수의 FEC 패킷들때문에, 수신기 디바이스가 패킷 손실을 처리하기에 더 양호하게 준비가 될 수 있다. 또한, 이는, 패킷 손실을 초래한 상태들이 일시적이었던 경우에, 송신기가 총 비트레이트를 감소시키기 전에 추가적인 피드백을 계속해서 획득하는 것을 가능하게 한다.

344에 표시된 바와 같이, 패킷 손실이 계속해서 문제가 되고, 이것이 어떤 미리 정의된 총 문턱값을 넘는 경우, 348에 표시된 바와 같이, 총 비트레이트를 떨어뜨림으로써 비트레이트가 조정될 수 있다. 총 비트레이트는 어떤 미리-정의된 양만큼 떨어질 수 있거나, 또는, 가장 최근에 유효하게 동작했던 어떤 비트레이트까지, 예를 들어, 패킷 손실이 용인가능하다는 것을 나타냈던 피드백(332)을 야기했던 비트레이트까지 떨어질 수 있다.

일부 예들에 있어서, 송신기가 네트워크를 통해 송신하기 위해 이용가능한 소스 데이터의 양이 현재 이용가능한 대역폭의 양을 채우기에 불충분할 수 있다는 것을 주의해야 한다. 예로서, 그리고 비제한적으로, 실-시간 비디오가 현재 블랙 스크린(black screen)을 생성하고 있는 경우, 애플리케이션이 단순히 이용가능한 비트레이트를 채우기에 충분한 데이터를 생성하고 있지 않기 때문에, 소스 데이터의 비트레이트가 낮을 수 있다. 그러나, 요구될 때 충분한 양의 이용가능한 대역폭이 이용가능할 수 있도록, 혼잡 제어 알고리즘이 스트림 내의 최대 이용가능 비트레이트에 관하여 피드백을 계속해서 획득하는 것이 여전히 바람직할 수 있다. 이러한 예들에 있어서, 시스템은, 이상에서 설명된 바와 같이, 대역폭 내의 다음 단계를 테스트하기 위하여 총 비트레이트에 부가할 뿐만 아니라, 소스 데이터에 대하여 사용되지 않는 나머지 이용가능 대역폭을 FEC 패킷들로 채우도록 구성될 수 있다.

이는, 다음의 예에 의해 예시될 수 있다. 프로세스가 현재 6MB/s로 데이터 패킷들을 송신하고 있으며, 수신기 디바이스들로부터의 피드백이 계속해서, 패킷 손실이 용인가능한 범위 내에 있다는 것을 나타내고 있고, 그 결과 송신되는 대역폭이 증가될 수 있다고 하자. 다음 단계는, 총 대역폭이 6.1MB/s가 되도록, 다른 100kb/s만큼 FEC 비트레이트를 증가시키는 것일 수 있다. 그러나, 예를 들어, 애플리케이션이 현재 블랙 스크린인 비디오를 생성하고 있기 때문에, 소스 데이터가 단지 1MB/s로 생성되고 있을 수 있다. 이러한 예에 있어서, 프로세스는, 5.1MB/s의 비트레이트로 FEC 패킷들을 송신함으로써, 테스트되는 대역폭의 나머지를 FEC 패킷들로 채우도록 구성될 수 있다. 따라서, 예를 들어, 비디오가 블랙 스크린으로부터 다시 라이브 픽처(live picture)들로 변화하기 때문에, 현재 생성되고 있는 소스 데이터의 비트레이트가 다시 증가할 때, 알고리즘이 계속해서 피드백을 획득하고, 송신되는 대역폭을 증분적으로 증가시켰기 때문에, 소스 비트레이트가 일시적으로 드롭 오프되더라도, 시스템이 계속해서 최대 이용가능 비트레이트를 효율적으로 사용할 수 있다.

도 3에 도시된 예시적인 기술이, 본 개시의 특정 측면들을 강조하기 위하여 오로지 예시의 목적들을 위해서만 제공되었다는 것이 강조되어야 한다. 실제로, 본 개시의 구현예들은 도 3의 예에 의해 도시되지 않은 추가적인 또는 대안적인 고려사항들을 고려할 수 있으며, 도 3에 도시된 간략화된 구성보다 더 복잡할 수 있다.

본 개시의 특정 측면들이, 적어도 하나의 수신기 디바이스로부터의 피드백 리포트에 응답하여 FEC 패킷들 대 소스 패킷들의 비율을 증가시키는 것을 포함한다는 것이, 도 3의 예로부터 이해될 것이다. 이는, 패킷 손실이 개별적인 시간의 기간 동안 용인가능했다는 것을 나타내는 피드백에 응답하여, 예를 들어, 338에 표시된 바와 같이, 총 비트레이트를 증가시키기 위하여 소스 패킷들의 양을 유지하면서 FEC 패킷들의 양을 증가시키는 것을 통해서 일 수 있다. 이는 또한, 패킷 손실이 변동되었다는 것 또는 달린 용인할 수 없다는 것을 나타내는 피드백 리포트에 응답하여, 346에서 표시된 바와 같이, 현재의 총 비트레이트를 유지하기 위하여 FEC 비트레이트를 증가시키고 소스 비트레이트를 감소시킴으로써 FEC 대 소스 비율을 증가시키는 것을 통해서 일 수 있다. 각각의 경우에 있어, 스트림 내의 FEC 패킷들의 상대적인 양의 증가는, 송신기 디바이스가 네트워크 내의 이용가능 대역폭의 사용이 더 효율적으로 사용될 수 있는지 여부를 결정하는 것을 가능하게 할 수 있는 피드백을 송신기 디바이스로 또한 제공하면서, 패킷 손실을 처리하도록 수신기 디바이스를 더 양호하게 준비시킬 수 있다.

본 개시의 특정 구현예들은, 도 4에 도시된 바와 같은, 본 개시의 특정 측면들에 따른 혼잡 제어 및/또는 데이터 전송 방법들을 구현하도록 구성된 시스템들을 포함한다. 도 4는 적어도 하나의 송신기 컴퓨팅 시스템(402) 및 적어도 하나의 수신기 컴퓨팅 시스템(404)을 포함하는 분산형 컴퓨팅 시스템을 도시하며, 컴퓨팅 시스템들(402 및 404)은 본 개시의 특정 측면들에 따라 네트워크를 통해 데이터를 전송하도록 구성된다. 특정 구현예들에 있어서, 송신기 컴퓨팅 시스템(402)은 도 1 내지 도 3의 송신기들 중 하나 이상과 공통되는 하나 이상의 측면들을 가질 수 있다. 특정 구현예들에 있어서, 수신기 컴퓨팅 시스템(404)은 도 1 내지 도 3의 수신기들 중 하나 이상과 공통되는 하나 이상의 측면들을 가질 수 있다. 송신기 시스템(402) 및 수신기 시스템(404) 중 하나 또는 둘 모두는, 본원에서 설명된 방법들의 다양한 측면들을 구현하기 위한 적절한 소프트웨어 및/또는 하드웨어를 가지고 구성될 수 있다. 송신기 시스템(402) 및 수신기 시스템(404) 중 하나 또는 둘 모두는, 서버, 내장형 시스템, 모바일 폰, 개인용 컴퓨터, 랩탑 컴퓨터, 태블릿 컴퓨터, 휴대용 게임 디바이스, 워크스테이션, 게임 콘솔, 착용형 디바이스 예컨대 스마트 워치, 및 유사한 것일 수 있다.

특정 구현예들에 따르면, 송신기 시스템(402)은 클라우드 컴퓨팅 서버일 수 있으며, 수신기 디바이스(404)는 서버(402)의 클라우드 컴퓨팅 클라이언트일 수 있고, 송신기(402)는 신뢰할 수 없는 프로토콜을 사용하여 네트워크(499)를 통해 클라이언트 디바이스로 데이터 스트림을 제공하도록 구성될 수 있다. 예로서, 그리고 비제한적으로, 송신기(402)는, 인터넷과 같은 네트워크(499)를 통해 적어도 하나의 클라이언트 디바이스(404)로 실-시간 오디오 스트림, 실-시간 비디오 스트림, 또는 실-시간 오디오/비디오 스트림과 같은 실-시간 데이터 스트림을 제공하도록 구성된 서버일 수 있다. 송신기 시스템(402)은, 수신기 시스템(404)으로 전달되는 기초 사용자 데이터를 포함하는 소스 패킷들(452), 및 소스 패킷들 내에 포함된 소스 데이터의 중복들을 포함하는 FEC 패킷들(454)의 형태로 수신기 시스템으로 데이터를 전송하도록 구성될 수 있다. 송신기 시스템(402)은, 본 개시의 다양한 측면들에 따라, 이러한 FEC 패킷들을 소스 패킷들과 동시에 수신기 디바이스(404)로 전송할 수 있다. 수신기 시스템(404)은, 이러한 데이터 패킷들을 축적하고, 네트워크(499)를 통해 다시 송신기 시스템(402)으로 주기적으로 피드백 리포트들(456)을 전송하도록 구성될 수 있다. 송신기 시스템(402)은, 본원에서 설명된 다양한 측면들에 따라, 이러한 피드백 리포트들(456)에 응답하여 패킷들(452, 454)이 전송되는 레이트를 조정하도록 구성될 수 있다.

시스템들(402 및 404)의 각각(즉, 송신기 시스템(402), 수신기 시스템(404), 또는 이들 둘 모두)은, 잘-알려진 아키텍처들에 따라 구성될 수 있는 하나 이상의 프로세서 유닛들(470), 예컨대, 예를 들어, 단일-코어, 듀얼-코어, 쿼드-코어, 멀티-코어, 프로세서-코프로세서, 셀 프로세서, 및 유사한 것을 포함할 수 있다. 시스템들(402 및 404)의 각각이 또한 하나 이상의 메모리 유닛들(472)(예를 들어, RAM, DRAM, ROM, 및 유사한 것)을 포함할 수 있다. 프로세서 유닛(470)은 메모리(472) 내에 저장될 수 있는 하나 이상의 프로그램들(474)을 실행할 수 있으며, 프로세서(470)는, 예를 들어, 데이터 버스(476)를 통해 메모리에 액세스함으로써, 메모리(472)에 동작가능하게 결합될 수 있다. 메모리 유닛(472)은 데이터(477)를 포함할 수 있으며, 프로세서 유닛(470)은 프로그램(474)를 구현하는데 데이터(477)를 사용할 수 있다. 시스템들(402 및 404)의 각각에 대한 데이터(477)는, 예를 들어, 본 개시의 다양한 측면들에 따른, 송신기 시스템(402)으로부터 수신기 시스템(404)으로 전송되는 소스 데이터, 및 수신기(404)로부터 송신기(402)로 송신되는 피드백 정보를 포함할 수 있다. 프로그램(474)은, 프로그램에 의해 실행될 때, 예를 들어, 도 2 및/또는 도 3의 방법들과 공통되는 적어도 하나의 특징들을 갖는 방법과 같은, 유명 비디오 게임 세션과 연관된 하나 이상의 동작들을 수행하는 명령어들을 포함할 수 있다. 예를 들어, 송신기 시스템(402)의 프로그램(474)은, 프로세서(470)에 의해 실행될 때, 도 2에 도시된 방법의 송신기 디바이스 측의 측면들 및/또는 도 3에 도시된 레이트 조정 기법에 따라, 송신기 시스템이 적어도 하나의 수신기 디바이스(404)로 데이터를 전송하게끔 하며, 및/또는 수신기 디바이스(404)로부터 수신되는 피드백에 응답하여 혼잡을 제어하게끔 하는 명령어들을 포함할 수 있다. 수신기 시스템(404)의 프로그램(474)은, 프로세서(470)에 의해 실행될 때, 도 2에 도시된 방법의 수신기 측의 측면들에 따라, 수신기 시스템이 데이터 패킷들을 축적하고, 패킷 손실을 결정하며, 및/또는 피드백 정보를 송신기(402)로 전송하게끔 하는 명령어들을 포함할 수 있다.

시스템들(402 및 404)의 각각은 또한, 예를 들어, 버스(476)를 통해 시스템의 다른 컴포넌트들과 통신할 수 있는 잘-알려진 지원 회로들(478), 예컨대, 입력/출력(I/O) 회로들(479), 전원 공급장치들(P/S)(480), 클럭(CLK)(481), 및 캐시(482)를 포함할 수 있다. 시스템들(402 및 404)의 각각은 선택적으로, 대용량 저장 디바이스(484) 예컨대, 디스크 드라이브, CD-ROM 드라이브, 테이프 드라이브, 플래시 메모리, 또는 유사한 것을 포함할 수 있으며, 대용량 저장 디바이스(484)는 프로그램들 및/또는 데이터를 저장할 수 있다. 시스템들(402 및 404)의 각각은 선택적으로 디스플레이 유닛(486)을 또한 포함할 수 있다. 디스플레이 유닛(486)은, 음극선관(CRT), 평판 스크린, 터치 스크린, 또는 텍스트, 숫자들, 그래픽 심볼들 또는 다른 시각적 객체들을 디스플레이하는 다른 디바이스의 형태일 수 있다. 시스템들(402 및 404)의 각각이 또한, 시스템(402/404)과 사용자 사이의 상호작용을 가능하게 하기 위한 사용자 인터페이스(488)를 포함할 수 있다. 사용자 인터페이스(488)는, 키보드, 마우스, 라이트 펜, 게임 제어 패드, 터치 인터페이스, 또는 다른 디바이스를 포함할 수 있다. 사용자 인터페이스는 또한 오디오 I/O 디바이스, 예컨대 스피커 및/또는 마이크로폰을 포함할 수 있다.

사용자는 사용자 인터페이스(488)를 통해 컴퓨터 시스템들의 각각과 상호작용할 수 있다. 예로서, 송신기(402)가 클라우드 게이밍 서버일 수 있으며, 수신기 시스템(404)이 클라우드 게이밍 클라이언트일 수 있고, 비디오 게임 사용자는 서버(402)에 의해 실행되며 사용자 인터페이스(488)를 통해 클라이언트(404)로 스트리밍되는 비디오 게임과 상호작용할 수 있다. 서버로부터 클라이언트로 데이터가 송신되는 레이트는, 클라이언트 측에서 수신되는 신호의 품질을 유지하면서 사용자를 위한 경험을 향상시키기 위하여 본 개시의 측면들에 따라 최적화될 수 있다. 사용자 인터페이스(488)의 부분들은, 시스템(402/404)과의 사용자 상호작용을 가능하게 하기 위하여 디스플레이 유닛(486) 상에 디스플레이될 수 있는 그래픽 사용자 인터페이스(GUI)를 포함할 수 있다. 시스템(402/404)은, 와이-파이(Wi-Fi), 이더넷 포트, 또는 다른 통신 방법들의 사용을 가능하게 하도록 구성된 네트워크 인터페이스(490)를 포함할 수 있다. 네트워크 인터페이스(490)는 전자통신 네트워크를 통한 통신을 가능하게 하기 위한 적절한 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 어떤 조합을 통합할 수 있으며, 본 개시의 특정 측면들에 따란 신뢰할 수 없는 프로토콜을 사용하는 데이터 전송을 지원할 수 있다. 네트워크 인터페이스(490)는 근거리 네트워크들 또는 광역 네트워크를 예컨대 인터넷을 통한 유선 또는 무선 통신을 구현하도록 구성될 수 있다. 시스템들(402 및 404)의 각각이 네트워크를 통한 하나 이상의 데이터 패킷들(499)을 통해 파일들에 대한 데이터 및/또는 요청들을 전송하고 수신할 수 있다.

이상의 컴포넌트들은 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 어떤 조합으로 구현될 수 있다.

전술한 것이 본 개시의 다양한 예시적인 구현예들의 완전한 설명이지만, 다양한 대안예들, 수정예들 및 등가물들이 가능하다. 따라서, 본 발명의 범위는, 이상의 설명에 의해 제한되는 것으로 해석되지 않아야 하며, 그 대신, 그들의 등가물들의 완전한 범위를 따라 첨부된 청구항들을 참조하여 결정되어야만 한다. 선호되는지 여부와 무관하게, 본원에서 설명된 임의의 특징이, 선호되는지 여부와 무관하게, 본원에서 설명된 임의의 다른 특징과 결합될 수 있다. 다음의 청구항들에 있어서, 한정 관사 "일"은, 명백히 달리 표현되는 경우를 제외하고는, 관사 다음의 아이템 중 하나 또는 그 이상의 양을 지칭한다. 첨부된 청구항들은, "하기 위한 수단" 또는 "하기 위한 단계" 문구를 사용하여 주어진 청구항 내에서 이러한 한정이 명백하게 언급되지 않는 한, 수단-또는-단계-플러스-기능 한정들로서 해석되지 않아야 한다.

Claims

방법으로서, 송신기 컴퓨팅 시스템을 이용하여,
신뢰할 수 없는 프로토콜을 통해, 데이터 패킷들의 스트림을 네트워크를 통해 적어도 하나의 수신기 디바이스로 전송하는 단계;
상기 전송하는 단계 동안, 상기 적어도 하나의 수신기 디바이스로부터 하나 이상의 피드백 리포트들을 수신하는 단계; 및
상기 전송하는 단계 동안, 상기 피드백 리포트들 중 적어도 하나에 응답하여 상기 데이터 패킷들이 상기 스트림 내에서 전송되는 레이트를 조정하는 단계를 포함하며,
상기 데이터 패킷들의 스트림은 소스 패킷들 및 순방향 오류 정정(forward error correction; FEC) 패킷들을 포함하고,
상기 주기적인 피드백 리포트 각각은 개별적인 시간의 기간 동안의 패킷 손실을 특징지으며,
상기 레이트를 조정하는 단계는, 상기 패킷 손실을 용인가능한 레벨 내에 있는 것으로서 특징짓는 상기 피드백 리포트들 중 특정한 하나에 응답하여, 상기 소스 패킷들이 전송되는 소스 레이트를 유지하면서, 상기 FEC 패킷들이 전송되는 FEC 레이트를 증가시키는 단계를 포함하는, 방법.
청구항 1에 있어서,
상기 신뢰할 수 없는 프로토콜은 사용자 데이터그램 프로토콜(User Datagram Protocol; UDP)인, 방법.
청구항 1에 있어서, 상기 방법은,
상기 송신기 컴퓨팅 시스템을 이용하여, 각각의 상기 데이터 패킷을 시퀀스 번호로 스탬핑하는 단계를 더 포함하는, 방법.
청구항 1에 있어서, 상기 방법은,
상기 송신기 컴퓨팅 시스템을 이용하여, 각각의 상기 데이터 패킷을 시퀀스 번호로 스탬핑하는 단계를 더 포함하며,
상기 적어도 하나의 수신기 디바이스는, 상기 개별적인 시간의 기간 동안 상기 데이터 패킷들을 축적하고, 상기 개별적인 시간의 기간 동안 상기 수신기 디바이스에 의해 수신된 상기 데이터 패킷들의 상기 시퀀스 번호로부터 수신될 것으로 예측된 상기 데이터 패킷들의 수 및 실제 수신된 상기 데이터 패킷들의 수를 결정함으로써, 각각의 상기 피드백 리포트 내에서 상기 패킷 손실을 특징짓는, 방법.
청구항 1에 있어서, 상기 방법은,
상기 송신기 컴퓨팅 시스템을 이용하여, 각각의 상기 데이터 패킷을 시퀀스 번호로 스탬핑하는 단계;
상기 적어도 하나의 수신기 디바이스를 이용하여, 상기 개별적인 시간의 기간 동안 상기 데이터 패킷들을 축적하고, 상기 개별적인 시간의 기간 동안 상기 수신기 디바이스에 의해 수신된 상기 데이터 패킷들의 상기 시퀀스 번호로부터 수신될 것으로 예측된 상기 데이터 패킷들의 수 및 실제 수신된 상기 데이터 패킷들의 수를 결정함으로써, 각각의 상기 피드백 리포트 내에서 상기 패킷 손실을 특징짓는 단계를 더 포함하는, 방법.
청구항 1에 있어서, 상기 방법은, 상기 송신기 컴퓨팅 시스템을 이용하여,
상기 피드백 리포트들 중 적어도 하나 내의 상기 패킷 손실을 상기 개별적인 시간의 기간 동안 전송될 것으로 예측된 상기 데이터 패킷들의 미리 결정된 양에 대하여 정규화하는 단계를 더 포함하는, 방법.
청구항 1에 있어서, 상기 레이트를 조정하는 상기 단계는,
상기 패킷 손실이 용인가능한 레벨의 외부에 있다고 특징짓는 상기 피드백 리포트들 중 특정한 하나에 응답하여, 상기 데이터 패킷들이 전송되는 총 레이트를 유지하면서 상기 FEC 레이트 대 상기 소스 레이트의 비율을 증가시키는 단계를 더 포함하는, 방법.
청구항 1에 있어서,
상기 데이터 패킷들은 오디오 패킷들 및 비디오 패킷들을 포함하고,
상기 FEC 패킷들이 전송되는 FEC 레이트를 증가시키는 상기 단계는, 상기 FEC 오디오 패킷들이 전송되는 FEC 오디오 레이트 및 상기 FEC 비디오 패킷들이 전송되는 FEC 비디오 레이트 둘 모두를 증가시키는 단계를 포함하며,
상기 FEC 오디오 레이트 및 상기 FEC 비디오 레이트 둘 모두를 증가시키는 상기 단계는, 상기 FEC 비디오 레이트보다 더 큰 정도만큼 상기 FEC 오디오 레이트를 증가시키는 단계를 포함하는, 방법.
청구항 1에 있어서,
상기 데이터 패킷들은 오디오 패킷들 및 비디오 패킷들을 포함하고,
상기 FEC 패킷들이 전송되는 FEC 레이트를 증가시키는 상기 단계는, 상기 FEC 오디오 패킷들이 전송되는 FEC 오디오 레이트 및 상기 FEC 비디오 패킷들이 전송되는 FEC 비디오 레이트 둘 모두를 증가시키는 단계를 포함하며,
상기 FEC 오디오 레이트 및 상기 FEC 비디오 레이트 둘 모두를 증가시키는 상기 단계는, 상기 FEC 비디오 레이트보다 2배 내지 10배만큼 더 상기 FEC 오디오 레이트를 증가시키는 단계를 포함하는, 방법.
청구항 1에 있어서,
상기 하나 이상의 피드백 리포트들은, 상기 피드백 리포트들의 각각의 생성 사이에 미리-정의된 시간 간격을 갖는 복수의 주기적인 피드백 리포트들인, 방법.
청구항 1에 있어서,
상기 하나 이상의 피드백 리포트들은, 상기 피드백 리포트들의 각각의 생성 사이에 미리-정의된 시간 간격을 갖는 복수의 주기적인 피드백 리포트들이며,
상기 시간 간격은 100 밀리초 내지 1 초 사이인, 방법.
청구항 1에 있어서,
상기 적어도 하나의 수신기 디바이스는 복수의 수신기 디바이스들인, 방법.
청구항 1에 있어서,
상기 신뢰할 수 없는 프로토콜은 비연결형(connectionless)인, 방법.
청구항 1에 있어서,
상기 패킷 손실이 상기 용인가능한 레벨 내에 있다는 것을 나타내는 상기 피드백 리포트들 중 상기 특정한 하나는, 상기 패킷 손실이 이전의 상기 피드백 리포트들 중 하나에 대하여 안정적인 것을 나타내는, 방법.
송신기 컴퓨팅 시스템으로서,
적어도 하나의 프로세서 유닛;
상기 적어도 하나의 프로세서 유닛에 결합된 적어도 하나의 메모리 유닛을 포함하며,
상기 적어도 하나의 프로세서 유닛 및 상기 적어도 하나의 메모리 유닛은 방법을 수행하도록 구성되며, 상기 방법은,
신뢰할 수 없는 프로토콜을 통해, 데이터 패킷들의 스트림을 네트워크를 통해 적어도 하나의 수신기 디바이스로 전송하는 단계;
상기 전송하는 단계 동안, 상기 적어도 하나의 수신기 디바이스로부터 하나 이상의 피드백 리포트들을 수신하는 단계; 및
상기 전송하는 단계 동안, 상기 피드백 리포트들 중 적어도 하나에 응답하여 상기 데이터 패킷들이 상기 스트림 내에서 전송되는 레이트를 조정하는 단계를 포함하며,
상기 데이터 패킷들의 스트림은 소스 패킷들 및 순방향 오류 정정(forward error correction; FEC) 패킷들을 포함하고,
상기 주기적인 피드백 리포트 각각은 개별적인 시간의 기간 동안의 패킷 손실을 특징지으며,
상기 레이트를 조정하는 단계는, 상기 패킷 손실을 용인가능한 레벨 내에 있는 것으로서 특징짓는 상기 피드백 리포트들 중 특정한 하나에 응답하여, 상기 소스 패킷들이 전송되는 소스 레이트를 유지하면서, 상기 FEC 패킷들이 전송되는 FEC 레이트를 증가시키는 단계를 포함하는, 컴퓨팅 시스템.
청구항 15에 있어서, 상기 컴퓨팅 시스템은,
상기 적어도 하나의 메모리 유닛 내에 구현된 컴퓨터 판독가능 명령어들로서, 상기 명령어들은 상기 적어도 하나의 프로세서 유닛에 의해 실행될 때, 상기 컴퓨팅 시스템이 상기 방법을 수행하게끔 하는, 상기 컴퓨터 판독가능 명령어들을 더 포함하는, 컴퓨팅 시스템.
청구항 15에 있어서,
상기 신뢰할 수 없는 프로토콜은 UDP인, 컴퓨팅 시스템.
청구항 15에 있어서, 상기 방법은,
각각의 상기 데이터 패킷을 시퀀스 번호로 스탬핑하는 단계를 더 포함하는, 컴퓨팅 시스템.
청구항 15에 있어서, 상기 방법은,
각각의 상기 데이터 패킷을 시퀀스 번호로 스탬핑하는 단계를 더 포함하며,
상기 적어도 하나의 수신기 디바이스는, 상기 개별적인 시간의 기간 동안 상기 데이터 패킷들을 축적하고, 상기 개별적인 시간의 기간 동안 상기 수신기 디바이스에 의해 수신된 상기 데이터 패킷들의 상기 시퀀스 번호로부터 수신될 것으로 예측된 상기 데이터 패킷들의 수 및 실제 수신된 상기 데이터 패킷들의 수를 결정함으로써, 각각의 상기 피드백 리포트 내에서 상기 패킷 손실을 특징짓는, 컴퓨팅 시스템.
청구항 15에 있어서, 상기 방법은,
상기 피드백 리포트들 중 적어도 하나 내의 상기 패킷 손실을 상기 개별적인 시간의 기간 동안 전송될 것으로 예측된 데이터 패킷들의 미리 결정된 양에 대하여 정규화하는 단계를 더 포함하는, 컴퓨팅 시스템.
청구항 15에 있어서, 상기 레이트를 조정하는 상기 단계는,
상기 패킷 손실이 용인가능한 레벨의 외부에 있다고 특징짓는 상기 피드백 리포트들 중 특정한 하나에 응답하여, 상기 데이터 패킷들이 전송되는 총 레이트를 유지하면서 상기 FEC 레이트 대 상기 소스 레이트의 비율을 증가시키는 단계를 더 포함하는, 컴퓨팅 시스템.
청구항 15에 있어서,
상기 데이터 패킷들은 오디오 패킷들 및 비디오 패킷들을 포함하고,
상기 FEC 패킷들이 전송되는 FEC 레이트를 증가시키는 상기 단계는, 상기 FEC 오디오 패킷들이 전송되는 FEC 오디오 레이트 및 상기 FEC 비디오 패킷들이 전송되는 FEC 비디오 레이트 둘 모두를 증가시키는 단계를 포함하며,
상기 FEC 오디오 레이트 및 상기 FEC 비디오 레이트 둘 모두를 증가시키는 상기 단계는, 상기 FEC 비디오 레이트보다 더 큰 정도만큼 상기 FEC 오디오 레이트를 증가시키는 단계를 포함하는, 컴퓨팅 시스템.
청구항 15에 있어서,
상기 데이터 패킷들은 오디오 패킷들 및 비디오 패킷들을 포함하고,
상기 FEC 패킷들이 전송되는 FEC 레이트를 증가시키는 상기 단계는, 상기 FEC 오디오 패킷들이 전송되는 FEC 오디오 레이트 및 상기 FEC 비디오 패킷들이 전송되는 FEC 비디오 레이트 둘 모두를 증가시키는 단계를 포함하며,
상기 FEC 오디오 레이트 및 상기 FEC 비디오 레이트 둘 모두를 증가시키는 상기 단계는, 상기 FEC 비디오 레이트보다 2배 내지 10배만큼 더 상기 FEC 오디오 레이트를 증가시키는 단계를 포함하는, 컴퓨팅 시스템.
청구항 15에 있어서,
상기 하나 이상의 피드백 리포트들은, 상기 피드백 리포트들의 각각의 생성 사이에 미리-정의된 시간 간격을 갖는 복수의 주기적인 피드백 리포트들인, 컴퓨팅 시스템.
청구항 15에 있어서,
상기 하나 이상의 피드백 리포트들은, 상기 피드백 리포트들의 각각의 생성 사이에 미리-정의된 시간 간격을 갖는 복수의 주기적인 피드백 리포트들이며,
상기 시간 간격은 100 밀리초 내지 1 초 사이인, 컴퓨팅 시스템.
청구항 15에 있어서,
상기 적어도 하나의 수신기 디바이스는 복수의 수신기 디바이스들인, 컴퓨팅 시스템.
청구항 15에 있어서,
상기 신뢰할 수 없는 프로토콜은 비연결형(connectionless)인, 컴퓨팅 시스템.
청구항 15에 있어서,
상기 패킷 손실이 상기 용인가능한 레벨 내에 있다는 것을 나타내는 상기 피드백 리포트들 중 상기 특정한 하나는, 상기 패킷 손실이 이전의 상기 피드백 리포트들 중 하나에 대하여 안정적인 것을 나타내는, 컴퓨팅 시스템.
그 내부에 구현된 컴퓨터 판독가능 명령어들을 갖는 비-일시적인 컴퓨터 판독가능 매체로서, 상기 컴퓨터 판독가능 명령어들은 실행될 때 방법을 구현하도록 구성되며, 상기 방법은,
신뢰할 수 없는 프로토콜을 통해, 데이터 패킷들의 스트림을 네트워크를 통해 적어도 하나의 수신기 디바이스로 전송하는 단계;
상기 전송하는 단계 동안, 상기 적어도 하나의 수신기 디바이스로부터 하나 이상의 피드백 리포트들을 수신하는 단계; 및
상기 전송하는 단계 동안, 상기 피드백 리포트들 중 적어도 하나에 응답하여 상기 데이터 패킷들이 상기 스트림 내에서 전송되는 레이트를 조정하는 단계를 포함하며,
상기 데이터 패킷들의 스트림은 소스 패킷들 및 순방향 오류 정정(forward error correction; FEC) 패킷들을 포함하고,
상기 주기적인 피드백 리포트 각각은 개별적인 시간의 기간 동안의 패킷 손실을 특징지으며,
상기 레이트를 조정하는 단계는, 상기 패킷 손실을 용인가능한 레벨 내에 있는 것으로서 특징짓는 상기 피드백 리포트들 중 특정한 하나에 응답하여, 상기 소스 패킷들이 전송되는 소스 레이트를 유지하면서, 상기 FEC 패킷들이 전송되는 FEC 레이트를 증가시키는 단계를 포함하는, 비-일시적인 컴퓨터 판독가능 매체.