KR101698038B1

KR101698038B1 - 중복 인코딩 컨텐츠 데이터 기능의 선택적 활용을 구현하는 전달 가속기

Info

Publication number: KR101698038B1
Application number: KR1020167025195A
Authority: KR
Inventors: 마이클 조지 루비; 쉬라뱌 쿠나말라; 로렌츠 크리스토프 민더
Original assignee: 퀄컴 인코포레이티드
Priority date: 2014-03-18
Filing date: 2015-03-17
Publication date: 2017-01-19
Also published as: KR20160112009A; EP3120475A1; CN106134150A; US9350484B2; JP6147939B1; CN106134150B; JP2017518654A; US20150270930A1; WO2015142888A1

Abstract

클라이언트 디바이스의 사용자 에이전트(UA)로 컨텐츠를 전달하기 위한 전달 가속기(TA) 시스템들 및 방법들이 본 개시의 실시예들에 따라 제공된다. 실시예들은, TA의 요청 관리자(RM)에 의해서, 컨텐츠 서버에 컨텐츠를 요청하기 위해 상기 UA에 의해 제공되는 프래그먼트 요청들을 수신하고; 그리고 프래그먼트를 복원하는데 있어 RM에 의해 사용하기 위한 상기 프래그먼트 요청들 중 한 프래그먼트 요청을 요청하기 위해서 중복 인코딩 컨텐츠 데이터의 양을 결정한다.

Description

중복 인코딩 컨텐츠 데이터 기능의 선택적 활용을 구현하는 전달 가속기{TRANSPORT ACCELERATOR IMPLEMENTING SELECTIVE UTILIZATION OF REDUNDANT ENCODED CONTENT DATA FUNCTIONALITY}

[0001] 본 출원은, 공동-계류 중인, 2014년 3월 18일에 "TRANSPORT ACCELEATOR IMPLEMENTING SELECTIVE UTILIZATION OF REDUNDANT ENCODED CONTENT DATA FUNCTIONALITY"란 명칭으로 출원된 미국 가특허 출원 번호 제 61/954,987호; 및 2014년 5월 28일에 "TRANSPORT ACCELEATOR IMPLEMENTING SELECTIVE UTILIZATION OF REDUNDANT ENCODED CONTENT DATA FUNCTIONALITY"란 명칭으로 출원된 미국 특허 출원 번호 제 14/289,458호를 우선권으로 청구하고, 이로 인해 이들 출원들의 개시내용들은 인용에 의해 본원에 통합된다. 본 출원은, 공동 양도되어진, 2014년 5월 28일에 "TRANSPORT ACCELERATOR IMPLEMENTING EXTENDED TRANSMISSION CONTROL FUNCTIONALITY"라는 명칭으로 미국 특허 출원 번호 제 14/289,016호; 2014년 5월 28일에 "TRANSPORT ACCELERATOR IMPLEMENTING EXTENDED TRANSMISSION CONTROL FUNCTIONALITY"라는 명칭으로 출원된 출원 번호 제 14/289,181호; 2014년 5월 28일에 "TRANSPORT ACCELERATOR IMPLEMENTING ENHANCED SIGNALING"라는 명칭으로 출원된 출원 번호 제 14/289,348호; 2014년 5월 28일에 "TRANSPORT ACCELERATOR IMPLEMENTING REQUEST MANAGER AND CONNECTION MANAGER FUNCTIONALITY"라는 명칭으로 출원된 출원번호 제 14/289,403호; 2014년 5월 28일에 "TRANSPORT ACCELERATOR IMPLEMENTING A MULTIPLE INTERFACE ARCHITECTURE"라는 명칭으로 출원된 출원 번호 제 14/289,476호; 및 2014년 5월 28일에 "TRANSPORT ACCELERATOR IMPLEMENTING CLIENT SIDE TRANSMISSION FUNCTIONALITY"라는 명칭으로 출원된 출원 번호 제 14/289,499호에 관련되고, 이들 출원들 각각은 본 출원과 동시에 출원되었고, 이들 출원들의 개시내용들은 그 전체가 본원에 인용에 의해 명백히 통합된다.

[0002] 이용가능한 통신 네트워크들을 통해 더욱더 많은 컨텐츠가 전달되고 있다. 종종, 이러한 컨텐츠는 예컨대 오디오 데이터, 비디오 데이터, 이미지 데이터 등을 포함하는 많은 타입들의 데이터를 포함한다. 비디오 컨텐츠, 특히 고 분해능 비디오 컨텐츠는, 종종 비교적 큰 데이터 파일 또는 데이터의 다른 컬렉션을 포함한다. 그에 따라서, 최종 사용자 디바이스나 혹은 그러한 컨텐츠를 소비하고 있는 다른 클라이언트 디바이스 상의 사용자 에이전트(UA)는 종종 원하는 비디오 컨텐츠를 포함하는 컨텐츠의 프래그먼트들의 시퀀스를 요청하여 수신한다. 예컨대, UA는, 데이터, 종종 멀티미디어 데이터를 요청하고 요청된 데이터를 수신하여 추가로 프로세싱하고 어쩌면 사용자 디바이스 상에 디스플레이하는 사용자 디바이스 상에서 실행하는 클라이언트 애플리케이션 또는 프로세스를 포함할 수 있다.

[0003] 많은 타입들의 애플리케이션들은 오늘날 전술한 컨텐츠 전달을 위해 HTTP(Hypertext Transfer Protocol)에 의존한다. 많은 그러한 애플리케이션들에서는, HTTP 전달들의 성능이 애플리케이션을 통한 사용자의 경험에 중요하다. 예컨대, 라이브 스트리밍은 비디오 스트리밍 클라이언트의 성능을 방해할 수 있는 몇몇 제약들을 갖는다. 두 가지의 제약들이 특히 두드러진다. 첫째, 미디어 세그먼트들이 시간에 걸쳐 잇따라서 이용가능하게 된다. 이러한 제약은 클라이언트가 데이터의 대부분을 계속해서 다운로딩하는 것을 막고, 이는 결국 다운로드 레이트 추정의 정확성에 영향을 준다. 대부분의 스트리밍 클라이언트들은 "요청-다운로드-추정" 루프 상에서 동작하기 때문에, 그것은 다운로드 추정이 부정확할 경우에는 일반적으로 제대로 이루어지지 않는다. 둘째, 라이브 이벤트 스트리밍을 시청할 때, 사용자들은 실제 라이브 이벤트 타임라인으로부터의 긴 지연이 발생하는 것을 일반적으로 원하지 않는다. 그러한 작동은 스트리밍 클라이언트가 대형 버퍼를 구축하는 것을 막고, 이는 결국 더 많은 재버퍼링을 야기할 수 있다.

[0004] 스트리밍 클라이언트가 TCP(Transport Control Protocol)을 통해 동작할 경우(대부분의 DASH(Dynamic Adaptive Streaming over HTTP) 클라이언트들이 동작하는 것처럼), 클라이언트는 추정된 이용가능성 스케줄에 기초하여 프래그먼트들을 통상 요청한다. 프래그먼트들의 패킷이 수신되지 않는 경우, 기존 TCP 프로토콜들은 데이터의 송신을 늦추고 그 패킷을 통해 운반된 손실 데이터를 재요청하기 위해 활용된다. 예컨대, 수신기는 단지 NextByteExperted까지만 확인응답(ACK)을 할 것인데, 여기서 NextByteExpected는 손실 패킷을 통해 운반되는 프래그먼트의 데이터의 제 1 바이트를 지칭한다. 그 이후에, 만약 NextByteExperted 이외의 데이터를 운반하지만 프래그먼트의 byte NextByteExperted는 포함하지 않는 비순서적인 패킷들이 수신된다면, 수신기는 NextByteExperted에 대응하는 복제 ACK들을 전송할 것이고, 전송기는 그러한 복제 ACK들을 네트워크에서의 혼잡에 대한 사인(sign)들로 해석할 것이며, 따라서 혼잡 윈도우를 감소시킴으로써 전송 레이트를 늦춘다. 그에 따라서, 컨텐츠 데이터의 손실 또는 지연된 부분들의 복원이 그러한 데이터의 재송신에 관련된 지연으로 인해서 뿐만 아니라 연관된 네트워크 혼잡 검출에 대한 응답으로 종종 늦춰지는 전송 레이트로 인해서 문제가 될 수 있다.

[0005] 비록 중복 인코딩 데이터 기술들(예컨대, 순방향 에러 정정(FEC) 코딩)을 사용하여 클라이언트에 의해 수신되지 못한 적어도 일부 레벨의 컨텐츠 데이터를 순향적으로(proactively) 처리하는 것이 가능할 수 있지만, 스트리밍 컨텐츠에 적용될 때 그러한 기술들을 사용할 경우에는 주의가 이루어져야 한다. 프로토콜들의 설계에 의존하여, 중복 인코딩 데이터의 순향 전송은 잠재적 손실 데이터의 복원을 지원하기 위해 데이터 인코딩의 중복성으로 인한 추가적인 대역폭을 소비할 수 있다. 그러나, 그러한 중복성들이 없는 스트리밍 컨텐츠는, 특히 라이브 스트리밍에 적용될 때 그리고 TCP를 근본적인 전달 프로토콜로서 사용할 때, 바람직하지 않은 엔드-투-엔드 레이턴시들이 발생할 수 있다. 위의 설명은 특히, 스트리밍 클라이언트가 데이터의 전달은 보장하지만 아마도 지연되거나 감소된 레이트 전달을 갖는 프로토콜들의 동작으로 인해 (예컨대, DASH 클라이언트로서) TCP를 통해 동작하는 경우이다.

[0006] 클라이언트 디바이스의 전달 가속기(TA)에 의해서 클라이언트 디바이스의 사용자 에이전트(UA)로 컨텐츠의 전달을 가속시키기 위한 방법이 본 개시의 실시예들에 따라 제공된다. 실시예들의 그 방법은, TA의 요청 관리자(RM)에 의해서, 컨텐츠 서버에 컨텐츠를 요청하기 위해 UA에 의해 제공되는 프래그먼트 요청들을 수신하는 단계; 및 프래그먼트를 복원하는데 있어 RM에 의해 사용하기 위한 프래그먼트 요청들 중 한 프래그먼트 요청을 요청하기 위해서 중복 인코딩 컨텐츠 데이터의 양을 결정하는 단계를 포함한다.

[0007] 클라이언트 디바이스의 전달 가속기(TA)에 의해서 클라이언트 디바이스의 사용자 에이전트(UA)로 컨텐츠의 전달을 가속시키도록 구성된 장치가 본 개시의 실시예들에 따라 제공된다. 실시예들의 그 장치는, TA의 요청 관리자(RM)에 의해서, 컨텐츠 서버에 컨텐츠를 요청하기 위해 UA에 의해 제공되는 프래그먼트 요청들을 수신하기 위한 수단; 및 프래그먼트를 복원하는데 있어 RM에 의해 사용하기 위한 프래그먼트 요청들 중 한 프래그먼트 요청을 요청하기 위해서 중복 인코딩 컨텐츠 데이터의 양을 결정하기 위한 수단을 포함한다.

[0008] 클라이언트 디바이스의 전달 가속기(TA)에 의해서 클라이언트 디바이스의 사용자 에이전트(UA)로 컨텐츠의 전달을 가속시키기 위한 컴퓨터 프로그램 물건이 본 개시의 실시예들에 따라 제공된다. 컴퓨터 프로그램 물건은 레코딩되는 프로그램 코드를 갖는 비-일시적 컴퓨터-판독가능 매체를 포함한다. 실시예들의 프로그램 코드는, TA의 요청 관리자(RM)에 의해서, 컨텐츠 서버에 컨텐츠를 요청하기 위해 UA에 의해 제공되는 프래그먼트 요청들을 수신하기 위한 프로그램 코드; 및 프래그먼트를 복원하는데 있어 RM에 의해 사용하기 위한 프래그먼트 요청들 중 한 프래그먼트 요청을 요청하기 위해서 중복 인코딩 컨텐츠 데이터의 양을 결정하기 위한 프로그램 코드를 포함한다.

[0009] 클라이언트 디바이스의 전달 가속기(TA)에 의해서 클라이언트 디바이스의 사용자 에이전트(UA)로 컨텐츠의 전달을 가속시키도록 구성된 장치가 본 개시의 실시예들에 따라 제공된다. 그 장치는 적어도 하나의 프로세서, 및 적어도 하나의 프로세서에 결합된 메모리를 포함한다. 실시예들의 적어도 하나의 프로세서는, TA의 요청 관리자(RM)에 의해서, 컨텐츠 서버에 컨텐츠를 요청하기 위해 UA에 의해 제공되는 프래그먼트 요청들을 수신하고; 그리고 프래그먼트를 복원하는데 있어 RM에 의해 사용하기 위한 프래그먼트 요청들 중 한 프래그먼트 요청을 요청하기 위해서 중복 인코딩 컨텐츠 데이터의 양을 결정하도록 구성된다.

[0010] 도 1은 본 개시의 실시예들에 따라, 중복 인코딩 컨텐츠 데이터의 선택적 활용을 구현하는 전달 가속기에 의한 컨텐츠의 전달을 제공하도록 적응되는 시스템을 도시한다.
[0011] 도 2는 본 개시의 실시예들의 전달 가속기의 고정 중복 인코딩 컨텐츠 데이터 구성 요청 관리자의 동작을 예시하는 흐름도를 도시한다.
[0012] 도 3은 본 개시의 실시예들의 전달 가속기의 자동 중복 인코딩 컨텐츠 데이터 구성 요청 관리자의 동작을 예시하는 흐름도를 도시한다.
[0013] 도 4는 본 개시의 실시예들에 따라, 수신되는, 계류 중인 그리고 늦는 데이터를 예시하는 타임라인을 도시한다.
[0014] 도 5는 본 개시의 실시예들의 요청 관리자와 사용자 에이전트 간에 구현될 수 있는 애플리케이션 프로그래밍 인터페이스를 도시한다.
[0015] 도 6은 중복 인코딩 컨텐츠 데이터의 선택적 활용을 구현하는 전달 가속기에 의한 컨텐츠의 전달을 제공하도록 적응되는 시스템을 도시하는데, 여기서 중복 인코딩 컨텐츠 데이터는 본 개시의 실시예들에 따라 개별 소스 또는 제공자에 의해 제공된다.

[0016] 용어 "예시적인"은 "예, 경우, 또는 예시로서 제공하는 것"을 의미하도록 본원에서 사용된다. "예시적인"으로서 본원에 설명된 임의의 양상이 다른 양상들에 비해 바람직하거나 유리한 것으로서 해석될 필요는 없다.

[0017] 본 설명에서, 용어 "애플리케이션"은 또한 오브젝트 코드, 스크립트들, 바이트 코드, 마크업 언어 파일들 및 패치들과 같은 실행가능 컨텐츠를 갖는 파일들을 포함할 수 있다. 게다가, 본원에서 지칭되는 "애플리케이션"은 또한 본질적으로 실행가능하지 않은 파일들, 이를테면 오픈될 필요가 있을 수 있는 문헌들 또는 액세스될 필요가 있는 다른 데이터 파일들과 같은 파일들을 포함할 수 있다.

[0018] 본 설명에서 사용되는 바와 같이, 용어 "컨텐츠"는 비디오, 오디오, 비디오와 오디오의 조합들, 또는 하나 또는 그 초과의 품질 레벨들의 다른 데이터를 갖는 데이터를 포함할 수 있는데, 그 품질 레벨은 비트 레이트, 분해능 또는 다른 팩터들에 의해 결정된다. 컨텐츠는 또한 오브젝트 코드, 스크립트들, 바이트 코드, 마크업 언어 파일들 및 패치들과 같은 실행가능 컨텐츠를 갖는 파일들을 포함할 수 있다. 게다가, "컨텐츠"는 또한 본질적으로 실행가능하지 않은 파일들, 이를테면 오픈될 필요가 있을 수 있는 문헌들 또는 액세스될 필요가 있는 다른 데이터 파일들과 같은 파일들을 포함할 수 있다.

[0019] 본 설명에서 사용되는 바와 같이, 용어 "프래그먼트"는 사용자 디바이스에 의해 요청되고 그리고/또는 사용자 디바이스에서 수신될 수 있는 컨텐츠의 하나 또는 그 초과의 부분들을 지칭한다.

[0020] 본 설명에서 사용되는 바와 같이, 용어 "스트리밍 컨텐츠"는 컨텐츠의 실시간 전달 또는 시간 기간에 걸친 컨텐츠의 전달을 가능하게 하는 하나 또는 그 초과의 표준들에 따라 서버 디바이스로부터 전송되어 사용자 디바이스에서 수신될 수 있는 컨텐츠를 지칭한다. 스트리밍 컨텐츠 표준들의 예들은 디-인터리빙된(또는 다중) 채널들을 지원하는 표준들 및 디-인터리빙된(또는 다중) 채널들을 지원하지 않는 표준들을 포함한다.

[0021] 본 설명에서 사용되는 바와 같이, 용어들 "컴포넌트", "데이터베이스", "모듈", "시스템" 등은 컴퓨터-관련 엔티티, 즉, 하드웨어, 펌웨어, 하드웨어와 소프트웨어의 결합, 소프트웨어, 또는 실행 중인 소프트웨어 중 어느 하나를 지칭하도록 의도된다. 예컨대, 컴포넌트는 프로세서 상에서 실행 중인 프로세스, 프로세서, 오브젝트, 실행가능물, 실행 스레드, 프로그램 및/또는 컴퓨터일 수 있지만, 이들로 제한되지는 않는다. 예시로서, 컴퓨팅 디바이스 상에서 실행 중인 애플리케이션 및 컴퓨팅 디바이스 둘 모두는 컴포넌트일 수 있다. 하나 또는 그 초과의 컴포넌트들은 프로세스 및/또는 실행 스레드 내에 상주할 수 있고, 컴포넌트는 하나의 컴퓨터 상에 국부화되고 그리고/또는 둘 또는 그 초과의 컴퓨터들 간에 분포될 수 있다. 게다가, 이러한 컴포넌트들은 저장된 다양한 데이터 구조들을 갖는 다양한 컴퓨터 판독가능 매체들로부터 실행될 수 있다. 컴포넌트들은 이를테면 하나 또는 그 초과의 데이터 패킷들(예컨대, 로컬 시스템에서, 분산형 시스템에서 및/또는 신호에 의한 다른 시스템들과의 네트워크(이를테면, 인터넷)를 통해 다른 컴포넌트와 상호 작용하는 하나의 컴포넌트로부터의 데이터)을 갖는 신호에 따라 로컬 및/또는 원격 프로세스들을 통해 통신할 수 있다.

[0022] 본원에서 사용되는 바와 같이, 용어들 "사용자 장비", "사용자 디바이스" 및 "클라이언트 디바이스"는 웹 서버에 컨텐츠를 요청하고 그 컨텐츠를 그로부터 수신할 수 있고 정보를 웹 서버에 송신할 수 있는 디바이스들을 포함한다. 그러한 디바이스들은 정지형 디바이스들 또는 이동형 디바이스들일 수 있다. 용어들 "사용자 장치", "사용자 디바이스" 및 "클라이언트 디바이스"는 서로 바뀌어 사용될 수 있다.

[0023] 본원에서 사용되는 바와 같이, 용어 "사용자"는 사용자 디바이스 또는 클라이언트 디바이스를 통해 컨텐츠를 수신하고 정보를 웹사이트에 송신하는 개인을 지칭한다.

[0024] 도 1은 통신 네트워크들을 통해서 이를테면 오디오 데이터, 비디오 데이터, 이미지 데이터, 파일 데이터 등을 포함할 수 있는 컨텐츠의 전달을 제공하도록 본원의 개념들에 따라 적응되는 시스템(100)을 도시한다. 그에 따라서, 네트워크(150)를 통해 서버(130)와 통신하는 클라이언트 디바이스(110)가 도시되어 있고, 이로 인해 서버(130)는 본 개시의 개념들에 따라 데이터베이스(140)에 저장된 다양한 컨텐츠를 클라이언트 디바이스(110)에 전달할 수 있다. 비록 단지 단일 클라이언트 디바이스와 단일 서버 및 데이터베이스가 도 1에 표시되어 있지만, 시스템(100)이 복수의 임의의 또는 모든 그러한 디바이스들을 포함할 수 있다는 점이 인지되어야 한다. 예컨대, 서버(130)는 컨텐츠 전달의 고레벨 수요를 서빙하기 위해서 서버 팜(farm)의 서버를 포함할 수 있는데, 복수의 서버들은 중앙집중적으로 그리고/또는 분산형 구성으로 배치될 수 있다. 대안적으로는, 이를테면 컨텐츠 중 일부 또는 모두가 디바이스에 또한 공존하고 서버(130)를 통해 전달 가속기(120)에 제공되는 데이터베이스(140)(캐시)에 상주할 때, 서버(130)는 전달 가속기(120)와 동일한 디바이스에 공존할 수 있다(예컨대, 네트워크(150)를 통해서가 아니라 I/O 엘리먼트(113)를 통해서 직접 전달 가속기(120)에 연결됨). 마찬가지로, 사용자들은 복수의 클라이언트 디바이스들을 소유할 수 있고 그리고/또는 복수의 사용자들 각각은 하나 또는 그 초과의 클라이언트 디바이스들을 소유할 수 있는데, 이들 중 임의의 것 또는 모두는 본원에서의 개념들에 따른 컨텐츠 전달을 위해 적응된다.

[0025] 클라이언트 디바이스(110)는 네트워크(150)를 통한 컨텐츠의 전달을 수신하도록 동작가능한 디바이스들의 다양한 구성들을 포함할 수 있다. 예컨대, 클라이언트 디바이스(110)는 유선 디바이스, 무선 디바이스, 개인용 컴퓨팅 디바이스, 테블릿 또는 패드 컴퓨팅 디바이스, 휴대용 셀룰러 텔레폰, WiFi 가능 디바이스, Bluetooth 가능 디바이스, 텔레비전, 디스플레이를 갖는 한 쌍의 안경, 한 쌍의 증강 현실 안경, 또는 임의의 이용가능한 방법들 또는 인프라구조를 사용하여 서버(130)와 통신할 수 있는 네트워크(150)에 연결되는 임의의 다른 통신, 컴퓨팅 또는 인터페이스 디바이스를 포함할 수 있다. 클라이언트 디바이스(110)는 서버(130)의 클라이언트로서 기능하는 디바이스로서 기능하거나 또는 그에 연결될 수 있기 때문에 "클라이언트 디바이스"로 지칭된다.

[0026] 예시된 실시예의 클라이언트 디바이스(110)는 프로세서(111), 메모리(112) 및 입력/출력(I/O) 엘리먼트(113)를 포함하는 것으로 여기서 도시되는 복수의 기능 블록들을 포함한다. 비록 간략성을 위해 도 1의 도면에는 도시되지 않았지만, 클라이언트 디바이스(110)는 추가적인 기능 블록들, 이를테면 사용자 인터페이스, 라디오 주파수(RF) 모듈, 카메라, 센서 어레이, 디스플레이, 비디오 플레이어, 브라우저 등을 포함할 수 있고, 이들 중 일부 또는 모두는 본원의 개념들에 따른 동작에 의해 활용될 수 있다. 전술한 기능 블록들은 하나 또는 그 초과의 버스들, 이를테면 버스(114)를 통해서 동작가능하게 연결될 수 있다. 버스(114)는 연결된 엘리먼트들, 모듈들 및 컴포넌트들로 하여금 통신하고 상호동작하도록 허용하기 위해서 논리적 및 물리적 연결들을 포함할 수 있다.

[0027] 메모리(112)는 임의의 타입의 휘발성 또는 비-휘발성 메모리일 수 있고, 일 실시예에서는 플래시 메모리를 포함할 수 있다. 메모리(112)는 클라이언트 디바이스(110)에 영구적으로 설치될 수 있거나, 제거가능 메모리 엘리먼트, 이를테면 제거가능 메모리 카드일 수 있다. 비록 단일 엘리먼트로 도시되어 있지만, 메모리(112)는 다수의 이산적 메모리들 및/또는 메모리 타입들을 포함할 수 있다.

[0028] 메모리(112)는 이를테면 애플리케이션들, 동작 시스템들, 파일들, 전자 문헌들, 컨텐츠 등을 형성할 수 있는 다양한 컴퓨터 판독가능 코드 세그먼트들을 저장하거나 또는 다른 방식으로 포함할 수 있다. 예컨대, 예시된 실시예의 메모리(112)는 TA(Transport Accelerator)(120) 및 UA(129)를 정의하는 컴퓨터 판독가능 코드 세그먼트들을 포함하는데, 그 컴퓨터 판독가능 코드 세그먼트들은 프로세서(예컨대, 프로세서(111))에 의해 실행될 때, 본원에서 설명된 바와 같이 동작가능한 논리 회로들을 제공한다. 메모리(112)에 의해 저장된 코드 세그먼트들은 앞서 설명된 TA(120) 및 UA(129) 외에도 애플리케이션들을 제공할 수 있다. 예컨대, 메모리(112)는 본원의 실시예들에 따라 서버(130)로부터의 컨텐츠에 액세스하는데 있어 유용한 브라우저와 같은 애플리케이션들을 저장할 수 있다. 그러한 브라우저는, 만약 서버(130)가 웹 서버라면, 네트워크(150)를 경유하여 연결들(151 및 152)을 통해서 웹 컨텐츠를 액세스하고 시청하며 서버(130)와 HTTP(hypertext transfer protocol)를 통해 통신하기 위한 HTTP 웹 브라우저와 같은 웹 브라우저일 수 있다. 예로서, HTTP 요청은 클라이언트 디바이스(110)의 브라우저로부터 연결들(151 및 152)을 통해서 네트워크(150)를 경유하여 서버(130)에 전송될 수 있다. HTTP 응답이 서버로부터(130)로부터 연결들(152 및 151)을 통해서 네트워크(150)를 경유하여 클라이언트 디바이스(110)의 브라우저에 전송될 수 있다.

[0029] UA(129)는 서버, 이를테면 서버(130)에 컨텐츠를 요청하고 그리고/또는 그로부터 컨텐츠를 수신하도록 동작가능하다. UA(129)는, 예컨대, 멀티미디어 데이터와 같은 데이터를 요청하고 요청된 데이터를 수신하여 추가로 프로세싱하고 어쩌면 클라이언트 디바이스(110)의 디스플레이 상에 디스플레이하는 클라이언트 애플리케이션 또는 프로세스, 이를테면 브라우저, DASH 클라이언트, HTTP 라이브 스트리밍(HLS) 클라이언트 등을 포함할 수 있다. 예컨대, 클라이언트 디바이스(110)는 인터넷 브라우저에서 실행되도록 구성되는 브라우저-기반 미디어 플레이어 또는 독립형 미디어 재생 애플리케이션과 같은 재생 미디어를 위한 UA(129)를 포함하는 코드를 실행할 수 있다. 실시예들에 따른 동작에 있어서, UA(129)는 컨텐츠 파일의 어떤 프래그먼트들 또는 프래그먼트들의 시퀀스들이 스트리밍 컨텐츠 세션 동안 다양한 시점들에서 전달하도록 요청할지를 판단한다. 예컨대, UA(129)의 DASH 클라이언트 구성은 이를테면 최근 다운로드 조건들에 기초하여 각각의 시점에 컨텐츠의 어떤 표현(예컨대, 고 분해능 표현, 중간 분해능 표현, 저 분해능 표현 등)으로부터의 어떤 프래그먼트를 요청할지를 판단하도록 동작할 수 있다. 마찬가지로, US(129)의 웹 브라우저 구성은 웹 페이지들 또는 그들의 부분들 등을 요청하도록 동작할 수 있다. 통상, UA는 HTTP 요청들을 사용하여 그러한 프래그먼트들을 요청한다.

[0030] TA(120)는 원하는 컨텐츠의 프래그먼트들 또는 프래그먼트들의 시퀀스들(비디오 스트리밍, 파일 다운로드, 웹-기반 애플리케이션들, 범용 웹 페이지들 등을 제공하는데 있어 사용될 수 있는 바와 같은 앞서 설명된 컨텐츠 프래그먼트들)의 개선된 전달을 제공하도록 본원의 개념들에 따라 적응된다. 실시예들의 TA(120)는 프래그먼트 요청들을 실행하는 TA를 사용하는 것이 유리하지만 그 프래그먼트 요청들을 수행하기 위해서 단지 표준 인터페이스, 이를테면 표준 TCP 송신 프로토콜들을 구현하는 HTTP 1.1 인터페이스를 지원하는 일반적인 또는 레거시 UA(즉, TA와 상호작용하도록 미리 설계되어지지 않은 UA)를 허용하도록 적응된다. 추가로 또는 대안적으로, 실시예들의 TA(120)는 개선된 인터페이스를 제공하여, 그 개선된 인터페이스의 기능을 이용하도록 설계되는 UA들에 추가적인 이점들을 제공하는 것을 용이하게 한다. 실시예들의 TA(120)가 이를테면 표준 TCP 송신 프로토콜들을 구현하는 HTTP 인터페이스를 통해 TCP를 사용하여 기존 컨텐츠 전달 프로토콜들에 따라 프래그먼트 요청들을 실행하도록 적응됨으로써, 일반적인 또는 레거시 미디어 서버(즉, TA와 상호작용하도록 미리 설계되지 않은 미디어 서버)로 하여금 그 요청들을 서빙하는 동시에 UA 및 클라이언트 디바이스로의 프래그먼트들의 개선된 전달을 제공하도록 허용한다.

[0031] 전술한 개선된 프래그먼트 전달 기능을 제공하는데 있어서, 본원에서 실시예들의 TA(120)는 본원에 설명된 바와 같은 아키텍츄얼 컴포넌트들 및 프로토콜들을 포함한다. 예컨대, 도 1에 예시된 실시예의 TA(120)는 요청 관리자(RM)(121) 및 연결 관리자(CM)(122)를 포함하는데, 이들은 아래에서 추가로 설명되는 바와 같이 다양한 개선된 프래그먼트 전달 기능을 제공하기 위해 협력한다.

[0032] 애플리케이션들, 동작 시스템들, 파일들, 전자 문헌들, 컨텐츠 등을 형성하는 위에서 언급된 코드 세그먼트들 외에도, 메모리(112)는 클라이언트 디바이스(110)의 기능 블록들에 의해 사용되는 다양한 레지스터들, 버퍼들 및 저장 셀들을 포함하거나 그렇지 않으면 제공할 수 있다. 예컨대, 메모리(112)는 서버(130)로부터 스트리밍을 위한 프래그먼트들의 데이터를 스풀링(spooling)하고 클라이언트 디바이스(110)에 의해 재생하기 위한 선입/선출(FIFO) 메모리를 제공할 수 있는 플레이-아웃 버퍼를 포함할 수 있다.

[0033] 실시예들의 프로세서(111)는 클라이언트 디바이스(110)의 동작 및 기능을 제어하기 위한 명령들을 실행할 수 있는 임의의 범용 또는 특수 목적 프로세서일 수 있다. 비록 단일 엘리먼트로 도시되어 있지만, 프로세서(111)는 다수의 프로세서들 또는 분산형 프로세싱 아키텍쳐를 포함할 수 있다.

[0034] I/O 엘리먼트(113)는 다양한 입력/출력 컴포넌트들을 포함하고 그리고/또는 이들에 결합될 수 있다. 예컨대, I/O 엘리먼트(113)는 디스플레이, 스피커, 마이크로폰, 키패드, 포인팅 디바이스, 터치-감응 스크린, 사용자 인터페이스 제어 엘리먼트들, 및 사용자로 하여금 입력 커맨드들을 제공하여 클라이언트 디바이스(110)로부터의 출력들을 수신하도록 허용하는 임의의 다른 디바이스들 또는 시스템들을 포함하고 그리고/또는 이들에 결합될 수 있다. 임의의 또는 모든 이러한 컴포넌트들은 클라이언트 디바이스(110)의 사용자 인터페이스를 제공하기 위해 활용될 수 있다. 추가적으로 또는 대안적으로, I/O 엘리먼트(113)는 디스플레이 제어기, 네트워크 인터페이스 카드(NIC), 라디오 주파수(RF) 트랜시버, 및 클라이언트 디바이스(110)의 입력 및/또는 출력 기능을 용이하게 하는 임의의 다른 디바이스들 또는 시스템들을 포함할 수 있고 그리고/또는 이들에 결합될 수 있다.

[0035] 스트리밍 컨텐츠를 액세스하고 플레이하기 위한 동작에 있어서, 클라이언트 디바이스(110)는, 렌더링될 때 컨텐츠의 재생을 제공하는 컨텐츠 데이터를 (예컨대, 위에서 언급된 프래그먼트들로서) 획득하기 위해 링크들(151 및 152)을 사용하여 네트워크(150)를 경유해서 서버(130)와 통신한다. 그에 따라서, UA(129)는 클라이언트 디바이스(110)에서 컨텐츠 재생 환경을 설정하기 위해 프로세서(111)에 의해 실행되는 컨텐츠 플레이어 애플리케이션을 포함할 수 있다. 특정 컨텐츠 파일의 재생을 개시할 때, UA(129)는 컨텐츠 식별자(예컨대, 하나 또는 그 초과의 리스트들, 목록들, 구성 파일들, 또는 원하는 컨텐츠의 미디어 세그먼트들 또는 프래그먼트들 및 그들의 타이밍 경계들을 식별하는 다른 식별자들)를 획득하기 위해 서버(130)의 컨텐츠 전달 플랫폼과 통신할 수 있다. 미디어 세그먼트들 및 그들의 타이밍에 관한 정보가 컨텐츠의 재생을 위한 요청 프래그먼트들을 제어하기 위해 UA(129)의 스트리밍 컨텐츠 로직에 의해서 사용된다.

[0036] 서버(130)는 원하는 컨텐츠를 클라이언트 디바이스들에 서빙하도록 동작가능한 하나 또는 그 초과의 시스템들을 포함한다. 예컨대, 서버(130)는 네트워크(150)를 경유하여 다양한 클라이언트 디바이스들에 컨텐츠를 스트리밍하도록 동작가능한 표준 HTTP 웹 서버를 포함할 수 있다. 서버(130)는 사용자 디바이스(110)에 컨텐츠를 전달할 수 있는 임의의 시스템 또는 방법을 포함하는 컨텐츠 전달 플랫폼을 포함할 수 있다. 컨텐츠는 서버(130)와 통신하는 하나 또는 그 초과의 데이터베이스들, 이를테면 예시된 실시예의 데이터베이스(140)에 저장될 수 있다. 데이터베이스(140)는 서버(130)에 저장될 수 있거나, 또는 서버(130)에 통신적으로 결합되는 하나 또는 그 초과의 서버들에 저장될 수 있다. 데이터베이스(140)의 컨텐츠는 다양한 형태들의 데이터, 이를테면 비디오, 오디오, 스트리밍 텍스트, 및 라이브 웹캐스트 컨텐츠 및 저장된 미디어 컨텐츠와 같은 서버(130)에 의해 임의의 시간 기간에 걸쳐 클라이언트 디바이스(110)에 전달될 수 있는 임의의 다른 컨텐츠를 포함할 수 있다.

[0037] 데이터베이스(140)는 복수의 상이한 소스 또는 컨텐츠 파일들 및/또는 임의의 특정 컨텐츠의 복수의 상이한 표현들(예컨대, 고 분해능 표현, 중간 분해능 표현, 저 분해능 표현 등)을 포함할 수 있다. 예컨대, 컨텐츠 파일(141)은 고 분해능 표현 및 그에 따라 전달될 경우 특정 멀티미디어 편집물의 고 비트 레이트 표현을 포함할 수 있는데 반해, 컨텐츠 파일(142)은 저 분해능 표현 및 그에 따라 전달될 경우 그 동일한 특정 멀티미디어 편집물의 저 비트 레이트 표현을 포함할 수 있다. 추가적으로 또는 대안적으로, 임의의 특정 컨텐츠의 상이한 표현들은 이를테면 컨텐츠 파일(143)에 의해 제공될 수 있는 순방향 에러 정정(FEC) 표현(예컨대, 컨텐츠 데이터의 중복 인코딩을 포함하는 표현)을 포함할 수 있다. URL(Uniform Resource Locator), URI(Uniform Resource Identifier) 및/또는 URN(Uniform Resource Name)이 본원의 실시예들에 따라 이러한 컨텐츠 파일들 모두와 연관되고, 따라서 그러한 URL들, URI들 및/또는 URN들은 요청된 데이터를 식별하고 액세스하기 위해 바이트 범위들과 같은 다른 정보와 아마도 활용될 수 있다.

[0038] 네트워크(150)는 무선 네트워크, 유선 네트워크, WAN(wide area network), LAN(local area network), 또는 본원에 설명된 바와 같은 컨텐츠의 전달에 적절한 임의의 다른 네트워크일 수 있다. 실시예에서, 네트워크(150)는 인터넷의 적어도 일부들을 포함할 수 있다. 클라이언트 디바이스(110)는 이를테면 네트워크 연결(151)에 의해 표현되는 양방향 연결을 통해 네트워크(150)에 연결될 수 있다. 대안적으로, 클라이언트 디바이스(110)는 이를테면 MBMS(Multimedia Broadcast Multimedia System) 가능 네트워크에 의해 제공되는 단방향 연결을 통해 연결될 수 있다(예컨대, 연결들(151, 152) 및 네트워크(150)는 MBMS 네트워크를 포함할 수 있고, 서버(130)는 BM-SC(Broadcast Multicast Service Center) 서버를 포함할 수 있다). 그 연결은 유선 연결일 수 있거나 무선 연결일 수 있다. 실시예에서, 연결(151)은 유선 연결, 이를테면 셀룰러 4G 연결, WiFi(wireless fidelity) 연결, Bluetooth 연결, 또는 다른 무선 연결일 수 있다. 서버(130)는 이를테면 네트워크 연결(152)에 의해 표현되는 양방향 연결을 통해 네트워크(150)에 연결될 수 있다. 서버(130)는 단방향 연결을 통해 네트워크(150)(예컨대, 3GPP TS.26.346에 설명된 바와 같은 프로토콜들 및 서비스들을 사용하는 MBMS 네트워크 또는 ATSC 3.0 네트워크)에 연결될 수 있다. 그 연결은 유선 연결일 수 있거나 무선 연결일 수 있다.

[0039] 도 1에 예시된 실시예의 클라이언트 디바이스(110)는 본원의 개념들에 따라 원하는 컨텐츠의 프래그먼트들 또는 프래그먼트들의 시퀀스의 개선된 전달을 제공하도록 동작가능한 TA(120)를 포함한다. 위에서 논의된 바와 같이, 예시된 실시예의 TA(120)는 다양한 개선된 프래그먼트 전달 기능을 제공하기 위해 협력하는 RM(121) 및 CM(122)을 포함한다. 실시예들의 UA(129)와 RM(121) 간의 인터페이스(124) 및 RM(121)과 CM(122) 간의 인터페이스(123)는 HTTP-유사 연결을 제공한다. 예컨대, 전술한 인터페이스들은 본원의 실시예들에 따라 개선된 프래그먼트 전달의 특정 기능 양상들을 지원하기 위해서 표준 HTTP 프로토콜들을 이용할 뿐만 아니라 추가적인 시그널링(예컨대, HTTP의 시그널링 기술들과 유사한 시그널링 기술들을 사용하여 제공됨)을 포함할 수 있다.

[0040] 실시예들에 따른 동작에 있어, RM(121)은 UA(129)로부터 프래그먼트들에 대한 요청들을 수신하고, 요청된 프래그먼트들을 신뢰적으로 수신하여 복원하기 위해 CM(122)에 어떤 데이터를 요청할지를 판단한다. 본원의 실시예들에 따르면, RM(121)은 일반적인 또는 레거시 UA(즉, RM과 상호작용하도록 미리 설계되지 않은 UA)로부터 프래그먼트 요청들을 수신하고 그에 응답하도록 적응되고, 그로 인해 그러한 레거시 UA들과의 호환성이 제공된다. 그에 따라서, RM(121)은 TA(120)의 확장된 송신 프로토콜 동작으로부터 UA(129)를 분리하도록 동작할 수 있다. 그러나, 후속하는 논의로부터 더 충분하게 이해될 바와 같이, UA(129)는 확장된 송신 프로토콜 동작을 위해 적응될 수 있고, 그로 인해서 RM(121) 및 UA(129)는 이를테면 확장된 송신 프로토콜 동작의 하나 또는 그 초과의 특징들을 구현하기 위해 RM(121)과 UA(129) 간의 시그널링의 사용을 통해서 그 하나 또는 초과의 특징들을 구현하도록 협력한다.

[0041] 실시예들의 CM(122)에 대해 RM(121)에 의해서 이루어지는 데이터 요청들의 사이즈("청크(chunk) 요청들"로 본원에서 지칭되고, 요청된 데이터는 "청크"를 포함함)는 UA(129)에 의해 요청된 그리고 RM(121)이 복원하고 있는 프래그먼트인 프래그먼트의 사이즈보다 훨씬 작을 수 있다. 따라서, UA(129)로부터의 각각의 프래그먼트 요청은 그 프래그먼트를 복원하기 위해 CM(122)에 대한 다수의 청크 요청들을 생성하여 수행하도록 RM(121)을 트리거시킬 수 있다.

[0042] CM(122)에 대해 RM(121)에 의해서 수행된 청크 요청들 중 일부는 아직 도달하지 않은 그리고 그 RM(121)이 결코 도달할 수 없거나 또는 너무 늦게 도달할 수 있는 것으로 간주한, 이미 요청된 데이터에 대한 것일 수 있다. 추가적으로 또는 대안적으로, CM(122)에 대해 RM(121)에 의해서 수행된 청크 요청들 중 일부는 오리지널 프래그먼트로부터 생성되는 FEC 인코딩 데이터에 대한 것일 수 있고, 그로 인해서 RM(121)은 프래그먼트 또는 그 프래그먼트의 일부 부분을 복원하기 위해 CM(122)으로부터 수신되는 데이터를 FEC 디코딩할 수 있다. RM(121)은 복원된 프래그먼트들을 UA(129)에 전달한다. 그에 따라서, 이를테면 FEC 데이터를 사용하지 않고 따라서 단지 오리지널 소스 프래그먼트들로부터의 데이터의 일부들만을 요청하는 기본 RM 구성(RM-basic) 및 오리지널 소스 프래그먼트들로부터의 데이터의 부분들뿐만 아니라 소스 프래그먼트들로부터 생성되는 매칭 FEC 프래그먼트들을 요청할 수 있는 FEC RM 구성(RM-FEC)을 포함할 수 있는, 실시예들에 따른 RM들의 다양한 구성들이 존재할 수 있다.

[0043] 실시예들의 RM(121)은 타이밍 및/또는 대역폭 이용가능성 제약들을 인지할 수 없고 그로 인해 RM(121)과 CM(122) 간의 비교적 간단한 인터페이스를 용이하게 하며, 따라서 RM(121)은 RM(121)에 의한 그러한 제약들을 고려하지 않고 청크 요청들을 수행하도록 동작할 수 있다. 대안적으로, RM(121)은 이를테면 클라이언트 디바이스(110) 내의 CM(122) 또는 다른 모듈들에 의해서 RM(121)에 대해 지원될 수 있는 타이밍 및/또는 대역폭 이용가능성 제약들을 인지하도록 적응될 수 있고, 따라서 RM(121)은 그러한 제약들에 기초하여 청크 요청들을 수행하도록 동작할 수 있다.

[0044] 실시예들의 RM(121)은 복수의 상이한 CM 구성들과의 동작을 위해 적응된다. 더욱이, 일부 실시예들의 RM(121)은 이를테면 복수의 CM들로부터의 동일 프래그먼트 또는 프래그먼트들의 시퀀스의 데이터 청크들을 요청하기 위해서 하나 초과의 CM과 동시에 인터페이싱할 수 있다. 각각의 그러한 CM은, 예컨대, 상이한 네트워크 인터페이스를 지원할 수 있다(예컨대, 제 1 CM은 온-디바이스 캐시로의 로컬 인터페이스를 가질 수 있고, 제 2 CM은 3G 네트워크 인터페이스로의 HTTP/TCP 연결들을 사용할 수 있고, 제 3 CM은 4G/LTE 네트워크 인터페이스로의 HTTP/TCP 연결들을 사용할 수 있고, 제 4 CM은 WiFi 네트워크 인터페이스로의 HTTP/TCP 연결들을 사용할 수 있으며, 기타 등등이다).

[0045] 실시예들에 따른 동작에 있어서, CM(122)은 청크 요청들을 수신하기 위해 RM(121)과 인터페이싱하고, 그러한 요청들을 네트워크(150)를 통해 전송한다. CM(122)은 청크 요청들에 대한 응답들을 수신하고 그 응답들을 RM(121)에 다시 전달하는데, UA(129)에 의해 요청된 프래그먼트들은 수신된 청크로부터 구해진다. CM(122)의 기능은 RM(121)에 의해 수행된 청크 요청들의 데이터를 언제 요청할지를 판단하도록 동작한다. 본원의 실시예들에 따르면, CM(122)은 일반적인 또는 레거시 서버들(즉, TA와 상호작용하도록 미리 설계되지 않은 서버)에 청크들을 요청하고 그로부터 청크들을 수신하도록 적응된다. 예컨대, CM(122)이 데이터를 요청한 서버(들)는 표준 HTTP 웹 서버들을 포함할 수 있다. 대안적으로, CM(122)이 데이터를 수신하는 서버(들)는 MBMS 서비스들 전개에서 사용되는 BM-SC 서버들을 포함할 수 있다.

[0046] 위에서 논의된 RM(121)을 통해서와 같이, 실시예들에 따른 CM들의 다양한 구성들이 존재할 수 있다. 예컨대, 다중 연결 CM 구성(예컨대, CM-mHTTP)이 제공됨으로써, CM은 다수의 TCP 연결들을 통해 HTTP를 사용하도록 적응된다. 다중 연결 CM 구성은 이를테면 네트워크 조건들, 데이터에 대한 수요, 혼잡 윈도우 등에 의존하여 다수의 연결들(예컨대, TCP 연결들)을 동적으로 변경하도록 동작할 수 있다. 다른 예로서, CM이 TCP 연결(xTCP로서 본원에서 지칭됨)의 확장된 형태의 상부에서 HTTP를 사용하는 확장된 송신 프로토콜 CM 구성(예컨대, CM-xTCP)이 제공된다. 그러한 확장된 송신 프로토콜은 본원의 개념들에 따라 TA(120)에 의한 프래그먼트들의 개선된 전달을 용이하게 하도록 적응되는 동작을 제공할 수 있다. 예컨대, xTCP의 실시예는 전송된 패킷들이 손실될 때 조차도 확인응답을 서버에 다시 제공한다(패킷들이 손실될 때 TCP의 복제 확인응답 방식과는 대조적으로). 그러한 xTCP 패킷 확인응답 방식은 데이터 패킷들이 분실되었다는 결정에 대한 응답으로 데이터 패킷들이 송신되는 레이트를 서버가 감소시키는 것을 회피하기 위해 TA(120)에 의해서 활용될 수 있다. 또 다른 예로서, CM이 독점 UDP(User Datagram Protocol) 프로토콜을 사용하는 독점 프로토콜 CM 구성(예컨대, CM-rUDP)이 제공될 수 있고, 서버로부터 응답 데이터를 전송하는 레이트가 미리 구성된 일정한 레이트로 이루어질 수 있거나, 네트워크를 바람직하지 않게 혼합하게 하지 않고도 전송 레이트가 가능한 높게 되도록 보장하기 위해 프로토콜 내에 레이트 관리가 존재할 수 있다. 그러한 독점 프로토콜 CM은 독점 프로토콜을 지원하는 독점 서버들과 협력하도록 동작할 수 있다.

[0047] 비록 예시된 실시예는 CM(122)이 서버(130)로부터의 소스 파일로부터의 데이터를 에 요청하는 것에 관해 논의되었지만, CM이 데이터를 액세스해야 하는 인터페이스의 타입에 의존하여, 소스 파일들은 서버들 상에서 이용가능할 수 있거나 클라이언트 소스 상에 국부적으로 저장될 수 있다는 것이 인지되어야 한다.

[0048] 추가로, 실시예들에 따르면, 클라이언트 디바이스(110)는 도움기 디바이스로 본원에서 지칭되는 하나 또는 그 초과의 다른 디바이스들(예컨대, 인접하여 배치되는 디바이스들의 다양한 구성들)에 연결할 수도 있고(예컨대, WiFi 또는 Bluetooth 인터페이스를 통해서), 여기서 그러한 도움기 디바이스들은 3G 또는 LTE 연결을 통해서, 잠재적으로는 상이한 도움기 디바이스들에 대한 상이한 캐리어들을 통해서 하나 또는 그 초과의 서버들, 이를테면 서버(130)로의 연결을 가질 수 있다. 따라서, 클라이언트 디바이스(110)는 청크 요청들을 하나 또는 그 초과의 서버들, 이를테면 서버(130)에 전송하기 위해 도움기 디바이스들의 연결을 사용할 수도 있다. 이 경우에는, 도움기 디바이스들 각각에 연결하고 청크 요청들을 그들에 전송하여 응답들을 수신하기 위한 TA(120) 내의 CM이 존재할 수 있다. 그러한 실시예에서, 도움기 디바이스들은 동일한 프래그먼트에 대한 상이한 청크 요청을 동일하거나 상이한 서버들에 전송할 수 있다(예컨대, 동일한 프래그먼트는 예컨대 상이한 서버들이 동일하거나 상이한 컨텐츠 전달 네트워크 제공자들에 의해 제공되는 경우 다수의 서버들 상의 도움기 디바이스들에 이용가능할 수 있다).

[0049] 일부 실시예들에서, 매칭 소스 파일들로부터 중복 인코딩 기술들을 사용하여 생성된 보수(repair) 심볼들을 포함하는 중복 인코딩 컨텐츠 데이터 파일들(예컨대, FEC 인코딩 데이터 파일들)이 또한 (예컨대, 하나 또는 그 초과의 컨텐츠 서버들 상에서) 이용가능하게 될 수 있다. 예컨대, 각각의 소스 파일에 대한 하나의 그러한 파일이 존재할 수 있는데, 각각의 중복 인코딩 컨텐츠 데이터 파일이 기술 분야에 공지되어 있는 FEC 인코딩 기술들과 같은 중복 인코딩 기술들을 사용하여 소스 파일로부터 생성된다. 그러한 실시예에서는, 예컨대, 컨텐츠 파일(141)은 컨텐츠의 저 비트레이트(저 분해능) 버전을 포함할 수 있고, 컨텐츠 파일(142)은 컨텐츠의 고 비트레이트(고 분해능) 버전을 포함할 수 있으며, 컨텐츠 파일(143)은 컨텐츠 파일(142)의 FEC 인코딩 버전을 포함할 수 있다. 비록 중복 인코딩 데이터 송신의 구현들은 송신되는 모든 데이터가 에러 정정을 위해 인코딩되는 경우 일부 스트리밍 사용 경우들에 대해 상당한 이점들을 제공할 수는 없지만, 본원의 개념들에 따른 그러한 중복 인코딩 컨텐츠 데이터의 사용(예컨대, 이전 송신에서 손실된 컨텐츠 데이터의 전달을 신속히 처리하기 위해)은 많은 스트리밍 사용 경우들에 대해 유리할 수 있다. 예컨대, 라이브 스트리밍을 경우에는, 컨텐츠가 생성되거나, 이용가능하게 되거나, 발생될 때와 그 동일한 컨텐츠가 클라이언트 디바이스(110) 상에서 재생되어 시청하기에 이용가능하게 될 때 사이에는 작은 시간 간격이 존재하는 요건들이 종종 존재한다. 예컨대, 그 시간 간격은 1초 또는 그 미만일 수 있다. 그에 따라서, 아래에서 더 상세히 설명되는 바와 같이, CM(122)에 대해 RM(121)에 의해서 이루어지는 청크 요청들 중 일부는 중복 인코딩 컨텐츠 데이터에 대한 것일 수 있다.

[0050] 전술한 것에 부합하여, 이를테면 중복 인코딩 컨텐츠 데이터를 사용하지 않고 따라서 단지 오리지널 소스 프래그먼트들로부터의 데이터의 일부들만을 요청하는 기본 RM 구성(RM-basic) 및 오리지널 소스 프래그먼트들로부터의 데이터의 부분들뿐만 아니라 소스 프래그먼트들로부터 생성되는 매칭 중복 인코딩 컨텐츠 데이터 프래그먼트들을 요청할 수 있는 중복 인코딩 컨텐츠 데이터 RM 구성(RM-FEC)을 포함할 수 있는, 실시예들에 따른 RM들의 다양한 구성들이 존재할 수 있다. 중복 인코딩 컨텐츠 데이터를 위해 적응되는 RM(121)의 실시예들은 따라서 프래그먼트 또는 프래그먼트의 일부 부분을 복원하기 위해 적절한 중복 인코딩 컨텐츠 데이터 디코딩(예컨대, FEC 디코딩) 기술을 사용하여 CM(122)으로부터 수신된 그러한 데이터를 디코딩할 수 있다. 그런 이후에, RM(121)은 복원된 프래그먼트들을 UA(129)에 전달할 수 있다.

[0051] 후속하는 논의로부터 더 충분하게 이해될 바와 같이, 실시예들의 TA(120)는 프래그먼트들을 복원하는데 도움이 되게 중복 인코딩 컨텐츠 데이터 요청들을 활용하는데, 임의의 프래그먼트를 요청하기 위한 데이터의 총 양 및 임의의 프래그먼트에 대한 중복 인코딩 컨텐츠 데이터를 요청할 시기는 그 프래그먼트에 대한 얼마나 많은 그리고 어떤 데이터가 이미 수신되었는지와 같은 팩터들에 의존하여 바뀔 수 있다. 즉, 통상적인 것처럼, 데이터 송신들로부터 초래되는 손상 데이터를 정정하기 위해 중복 인코딩 데이터를 활용하는 것보다는 오히려, 실시예들은 이를테면 요청된 데이터 유닛들(예컨대, 프래그먼트들, 청크들, 패킷들 등)이 손실되거나 지연되는 경우에 요청된 프래그먼트들의 복원을 신속히 처리하기 위해 중복 인코딩 데이터를 추가 데이터로서 활용한다. 실시예들에 따른 동작에 있어서, 임의의 특정 프래그먼트에 대해 요청되는 중복 인코딩 데이터의 양(또는 임의의 중복 인코딩 데이터가 요청되는지 여부)은 프래그먼트의 전달 및 복원의 속도를 높이기 위해 그러한 중복 인코딩 데이터에 대한 필요성에 기초하여 제어된다. 예컨대, 만약 프래그먼트 요청들에 대한 응답으로 수신되는 고 레벨의 늦는 데이터가 존재하지 않는다면, 프래그먼트 요청들의 비-중복 인코딩 데이터에 대한 요청들 외에도 작은 양의 중복 인코딩 데이터가 요청될 수 있다.

[0052] TA(120)의 로직은 (어떤 중복 인코딩 컨텐츠 데이터도 포함하지 않는) 임의의 프래그먼트에 비해 얼마나 많은 중복 인코딩 컨텐츠 데이터를 사용할 지를 자동으로 결정할 수 있다. 예컨대, RM(121)은 요청되는 중복 인코딩 컨텐츠 데이터의 양을 각각의 프래그먼트를 복원하는데 필요한 중복 인코딩 컨텐츠 데이터의 양에 시기적절한 형태로 자동으로 튜닝(tune)할 수 있다. 실시예들에 따른 동작에 있어서, 임의의 특정 청크에 대해 RM(121)에 의해서 요청되는 중복 인코딩 데이터의 양은 프래그먼트를 다운로딩하는 과정 동안 경험되는 늦는 데이터의 총 양에 의존할 수 있다. 중복 인코딩 컨텐츠 데이터를 요청하고 디코딩하기 위한 로직이 실시예들의 전달 가속기(예컨대, RM(121))에 의해 구현될 때, UA(129)(즉, 심지어 중복 인코딩 컨텐츠 데이터의 사용을 위해 적응되지 않은 UA들)의 임의의 구성은 어떤 중복 인코딩 컨텐츠 데이터 시멘틱스(sementics)나 로직이 없이도 자동화된 RF FEC 방법들을 사용할 수 있다(예컨대, UA는 자동화된 RM FEC 방법들이 FEC 데이터가 이용가능할 때 그러한 FEC 데이터를 활용하게 동작하도록 하기 위해서 그러한 FEC 데이터가 이용가능한지 여부에 대해 인지할 필요가 없다). (예컨대, RM 및 그것의 CM의 협력을 통해서) 실시예들의 전달 가속기는 이를테면 각각의 프래그먼트 또는 프래그먼트들의 시퀀스에 대해 중복 인코딩 컨텐츠 데이터를 사용할지 여부, 언제 사용할지 및 얼마나 많이 사용할지를 자동으로 판독하도록 동작할 수 있다.

[0053] 중복 인코딩 컨텐츠 데이터를 사용하여 컨텐츠의 가속된 전달을 제공하도록 본원의 개념들에 따라 적응되는 시스템의 실시예들에 대한 상세사항이 아래에서 제공된다. 비록 판독자가 더 쉽게 이해하게 하는 특정 예들을 제공하기 위해 예시적인 중복 인코딩 컨텐츠 데이터로서 FEC 인코딩 데이터가 참조되지만, 본원의 개념들은 임의의 수의 적절한 중복 인코딩 컨텐츠 데이터 타입들에 대해 적용가능하다는 것이 인지되어야 한다. 예컨대, 패킷 손실로부터 보호하기 위해 애플리케이션 레벨에서 사용되는 순방향 에러 정정을 대신하여 또는 그에 추가하여 에러-정정이 사용될 수 있다. 다른 예로서, 각각의 프래그먼트는 단순히 일반적인 순방향 순서 대신에 역방향 순서로 이용가능하게 될 수 있는데, 그 경우들에서는 청크 요청들이 처음부터 끝으로의 일반적인 요청 시퀀스 외에도 프래그먼트의 끝부터 처음 쪽으로 이루어질 수 있고, 이어서 프래그먼트는 역방향 순서의 프래그먼트 복원이 순방향 순서의 프래그먼트 복원과 일치하자마자(어쩌면 두 요청 순서들로 요청되는 데이터의 일부 겹침을 통해) 복원가능하다.

[0054] TA(120)의 실시예들은 요청되는 컨텐츠의 임의의 또는 모든 프래그먼트들에 대해 FEC 데이터를 활용하도록 동작할 수 있다. 그러나, 프래그먼트(F)의 사이즈 이외의 얼마나 많은 가외적인 데이터가 실시예들에 따른 프래그먼트에 대해 요청될 수 있는지가 미리 결정된 양(예컨대, 가외적인 데이터의 양이 그렇지 않으면 명시되지 않는 그러한 프래그먼트들에 대해 또는 모든 프래그먼트들에 대해 사용되는 디폴트 양)으로서 제공될 수 있고, (예컨대, 현재 네트워크 조건들에 의존하여) 동적으로 결정될 수 있고, 기타 등등이다. 실시예들에 따른 동작에 있어서, 각각의 프래그먼트에 대해 사용할 FEC 데이터의 양 및 FEC 데이터를 포함하는 대응하는 FEC 프래그먼트에 관한 정보가 UA에 의해서 RM에 제공될 수 있다. 그에 따라서, UA(129) 및/또는 TA(120)(예컨대, RM(121))는 본 개시의 실시예들에 따라 FEC 데이터를 활용하기 위해 적응될 수 있다.

[0055] 전술한 것으로부터 인지될 수 있는 바와 같이, 기본 RM 구성에 대한 대안으로, 실시예들의 RM(121)이 프래그먼트들을 복원하는데 도움이 되게 FEC 데이터를 사용하도록 적응될 수 있다. 예컨대, RM(121)의 구성은 RM-fixed-FEC로서 본원에서 지칭되는 FEC 데이터 기술을 구현할 수 있고, 이로 인해서 각각의 프래그먼트에 대해 사용할 FEC 데이터의 양 및 FEC 데이터를 포함하는 대응하는 FEC 프래그먼트가 UA에 의해서 RM에 제공된다.

[0056] 그에 따라서, 이를테면 요청되는 오리지널 소스 프래그먼트에 매칭하는 FEC 프래그먼트, 긴급 팩터(X)의 시그널링 등에 대한 정보를 제공하기 위해 UA(129)와 RM(121) 간의 시그널링이 실시예들에 따라 활용될 수 있다. FEC 데이터를 사용하도록 적응되는 TA(120)의 실시예들에 따른 동작에 있어서, UA(129)는 소스 프래그먼트 요청, 매칭 FEC 프래그먼트 요청, 및 긴급 팩터(X)(예컨대, 특정된 값을 가짐)를 RM(121)에 제공하는데, 긴급 팩터(X)는 아래에서 더 상세히 설명되는 바와 같이 소스 프래그먼트를 복원하기 위해 필요한 최소치 이외의 데이터를 RM이 얼마나 적극적으로 요청하는지를 제어한다. 응답으로, 실시예들의 RM(121)은 매칭 FEC 프래그먼트 데이터가 아닌 단지 소스 프래그먼트 데이터를 UA(129)에 제공한다. 그러한 실시예들의 UA(129)는 매칭 FEC 프래그먼트 요청 및 긴급 팩터를 RM(121)에 제공하고, 그로 인해 그 RM은 소스 프래그먼트 요청의 전달을 가속시키는데 도움이 되게 이러한 정보를 사용할 수 있다. 전술한 것에 대한 변경에 있어서는, 아래에서 더 상세히 설명되는 바와 같이, FEC 데이터를 사용하도록 적응되는 TA(120)와 동작가능한 UA(129)는 소스 프래그먼트 요청들만을 RM(121)에 제공할 수 있고, RM은 대응하는 매칭 FEC 프래그먼트 요청들을 자동으로 도출할 수 있으며, RM은 각각의 프래그먼트에 대해 얼마나 많은 FEC를 요청할지를 자동으로 컴퓨팅할 수 있다. 전술한 구성들 중 어느 하나에서는 RM(121)이 FEC 디코딩을 제공하는 것을 포함해서 FEC의 시맨틱스를 이해하는데 필요한 클라이언트 디바이스(110)의 단지 컴포넌트이라는 점이 이해되어야 한다.

[0057] 실시예들의 RM-fixed-FEC 기술에 따른 동작이 도 2에서 흐름(200)으로서 도시되어 있다. 실시예들의 RM-fixed-FEC 기술의 동작을 이해하는데 있어서는, 프래그먼트(F)에 대한 요청이 UA)에 의해서 막 이루어졌고(블록(201)), 따라서 F는 초기에 활성이고 적격이라는 것을 가정하자. 예시된 실시예의 UA(129)는 프래그먼트 요청과 연관하여 FEC 데이터의 양을 요청하기 위한 정보를 RM(121)에 추가로 제공한다(블록(202)). 그러한 정보는 요청된 프래그먼트의 컨텐츠 데이터에 대응하는 FEC 데이터의 소스의 식별뿐만 아니라 RM(121)에 의한 FEC 데이터의 사용에 대한 다른 정보를 포함할 수 있다.

[0058] 어떤 프래그먼트들이 식별되고 그것들이 어떻게 식별되는지는 일반적으로 UA에 특정적이라는 점이 인지되어야 한다. 그러나, 일반적으로, 프래그먼트들은 미디어 파일들 또는 바이너리 파일들이거나 그러한 파일들의 바이트 범위들인데, 그 바이트 범위들은 이를테면 HTTP 프로토콜 또는 유사한 프로토콜을 사용하여 요청될 수 있는 자원 식별 정보(예컨대, URL, URI, 또는 URN) 및 어쩌면 바이트 범위에 의해 식별된다. 그에 따라서, 실시예들에 따른 동작에 있어서, UA(129)는 자원 식별 정보(예컨대, URL), 연관된 바이트 범위 및 프래그먼트 사이즈를 RM(121)에 공급한다. 마찬가지로, UA(129)는 대응하는 FEC 프래그먼트에 대한 심볼 사이즈, 자원 식별 정보, 연관된 바이트 범위 및 프래그먼트 사이즈를 공급할 수 있다. 예컨대, 매칭 FEC 프래그먼트(R)와 바이트들 단위의 심볼 사이즈(T)가 그 프래그먼트(F)에 대한 요청과 연관하여 UA(129)에 의해서 RM(121)에 제공되고, UA(129)는 또한 프래그먼트(F)의 바이트들 단위의 사이즈(FB) 및 FEC 프래그먼트(R)의 바이트들 단위의 사이즈(RB)를 RM(121)에 제공할 수 있다. 실시예들의 데이터 요청 사이즈들은 바람직하게는 FB가 T의 배수가 아닐 경우 F의 마지막 일부에 대한 요청을 제외하고는 T 바이트들의 배수들이지만, 이것으로 제한되는 것은 아니다. 일부 경우들에서는, 예컨대 T의 값이 공지되기 이전에 요청들이 수행될 경우 T 바이트들의 배수들인 데이터 요청들이 이루어지는 것이 가능하지 않을 수 있다. 이러한 경우들에서는, 본원에서 설명된 바와 같이, 심볼 경계들 상의 정렬되지 않은 요청들 또는 요청들에 대한 응답들로 인한 부분 심볼들의 수신이 단지 수신되는 데이터의 작은 일부이도록, T의 값이 통상 선정된다.

[0059] UA(129)가 DASH 클라이언트일 때, FEC 파일들의 생성은 "ENHANCED BLOCK-REQUEST STREAMING USING COOPERATIVE PARALLEL HTTP"란 명칭의 미국 특허 출원 번호 제 12/887,495호에 도시되고 설명된 기술들을 사용하여 제공될 수 있고, 이로 인해 그 출원의 개시내용은 인용에 의해 본원에 통합된다. 그러한 실시예들에서, 이러한 FEC 파일들이 어떻게 생성되는지에 대한 로직이 DASH 클라이언트에 특별하다. 그에 따라서, 실시예들의 UA(129)는 FEC 파일들을 생성하는데 있어 사용되는 로직에 관한 정보를 RM(121)에 공급할 수 있고, 이로 인해 그 RM은 이러한 로직에 대해 독립적으로 알아낼 필요가 없다. 예컨대, 매칭 FEC 프래그먼트에 대해 UA(129)에 의해서 RM(121)에 제공되는 자원 식별 정보는 부가된 접미사 “.raptorq.$T$”를 갖는 프래그먼트에 대한 URL을 포함할 수 있는데, 여기서 "raptorQ"는 FEC 코드가 IETF(Internet Engineering Task Force) RFC 6330에 명시된 RAPTORQ 코드라는 것을 표시하고, “$T$”의 값은 프래그먼트로부터 매칭 FEC 프래그먼트를 인코딩하기 위해 사용되는 심볼 사이즈이다. 다른 예로서, T의 값은 프래그먼트의 사이즈(FB)에 기초하여 각각의 프래그먼트에 대해 자동으로 결정될 수 있다.

[0060] 실시예들의 RX-fixed-FEC 기술에 따른 동작에 있어서, UA(129)는 추가적으로 또는 대안적으로, 요청된 프래그먼트(F)의 사이즈 이외의 얼마나 많은 가외적인 데이터가 RM(121)에 의해 프래그먼트에 대해 요청될 지(또한 블록(202))를 결정(블록(206))하는데 있어 사용되는 앞서 언급된 긴급 팩터(X)를 제공한다. 긴급 팩터에 대한 값은 다양한 방식들로 결정될 수 있으며, 프래그먼트 요청과 동시에, 프래그먼트 요청 이전에, 프래그먼트 요청이 이루어지는 스트리밍 컨텐츠 세션 이전에, 기타 등등에 결정될 수 있다. 예컨대, X에 대한 미리 결정된 디폴트 값(예컨대, X=0.1)이 일부 프래그먼트들(예컨대, 그렇지 않은 경우 어떤 X 값도 제공되지않는 프래그먼트들)에 대해 또는 모든 프래그먼트들에 대해 사용될 수 있다. 실시예들에 따른 동작에 있어서, UA(129)의 로직은 일부 또는 모든 프래그먼트 요청들에 대해 사용하기 위한 긴급 팩터(X)의 값을 결정하도록 적응된다. 예컨대, 본 개시의 실시예들에 따라 활용될 수 있는 긴급 팩터의 값들은 “FEC BASED RELIABILITY CONTROL PROTOCOLS”란 명칭의 미국 특허 번호 제 7,447,235호에 설명된 바와 같은 알고리즘들을 사용하여 결정될 수 있고, 이로 인해 그 미국 특허의 개시내용은 인용에 의해 본원에 통합된다.

[0061] 요청된 프래그먼트의 데이터 이외의 FEC 데이터의 적합한 양은 전술한 긴급 팩터(X)를 사용하여 RM(121)에 의해 요청될 수 있다(블록(203)). 예컨대, RM(121)은, RM(121)이 요청을 수행하기에 적합하다고 간주하는 시점 등에서, 이를테면 CM(122)에 의한 다른 요청에 대한 준비를 시그널링하는 것에 대한 응답으로 그와 연관하여 요청되는 추가 데이터를 갖는 하나 또는 그 초과의 청크 요청들을 수행할 수 있다. 마찬가지로, RM(121)은, RM(121)이 요청을 수행하기에 적합하다고 간주하는 시점 등에서, 이를테면 CM(122)에 의한 다른 요청에 대한 준비를 시그널링하는 것에 대한 응답으로 추가 데이터 중 일부 또는 모두에 대한 별도의 요청을 CM(122)에 대해 수행할 수 있다.

[0062] UA(129)에 의해 요청되는 프래그먼트들은 CM(122)에 대해 RM(121)에 의해 수행될 때 및/또는 서버(130)에 대해 CM(122)에 의해 수행될 때 더 작은 요청들(예컨대, 앞서 언급된 청크 요청들)로 세분될 수 있다는 것이 인지되어야 한다. 따라서, 특정 프래그먼트에 대해 요청된 추가 데이터의 양은 그 프래그먼트 요청의 청크 요청들에 대해 추가 데이터의 총체적인 양일 수 있다(즉, 추가 데이터의 일부 부분은 프래그먼트에 대한 임의의 또는 모든 청크 요청들과 연관하여 요청될 수 있음). 마찬가지로, 요청된 추가 데이터는 오리지널 컨텐츠 프래그먼트로부터의 데이터에 대한 청크 요청들에 추가하여 또는 이를 대신하여 FEC 데이터에 대한 하나 또는 그 초과의 요청들을 포함할 수 있다. 예컨대, 전체적인 데이터 요청들의 양이 프래그먼트의 사이즈이거나 프래그먼트의 사이즈보다 큰지 여부에 상관없이, 모든 데이터 요청들은 FEC 데이터만에 대한 것일 수 있다.

[0063] RM-fixed-FEC 기술을 구현하는 RM(121)의 실시예는, 예컨대, 프래그먼트(F)에 대해 총 (1+X)·FB 바이트들을 요청할 수 있다. 따라서, 데이터의 추가적인 X·FB 바이트들이 FEC 프래그먼트(R)로부터 요청될 수 있다(예컨대, 프래그먼트(F)로부터의 데이터 모두가 요청되어진 이후에). RM(121)이 FEC를 사용하지 않는 경우, 실시예들은 RM-fixed-FEC 기술 동작을 취소시키기 위해 T=1 및 X=0을 셋팅할 수 있다.

[0064] 본원의 RM-fixed-FEC 기술의 실시예들에 따른 동작에 있어서는, 프래그먼트(F)의 사이즈 이외의 얼마나 많은 가외적인 데이터가 요청되는지가 이를테면 현재 네트워크 조건들에 의존하도록 동적으로(예컨대, 블록(206)에서 결정될 때) 바뀔 수 있다. 가외적인 데이터의 양은, 예컨대, 실시예들에 따라 대역폭-지연 결과의 함수일 수 있다. 예컨대, 만약 현재 다운로드 레이트가 DR이고 현재 라운드-트립 시간이 RTT라면, 요청된 F 이외의 가외적인 데이터의 양은 X·DR·RTT일 수 있고, 여기서 X는 이 실시예에 따라 고정된 분수일 수 있다(예컨대, X=½ 또는 X=0.29). 전술한 것의 접근법으로서, CM(122)이 자신의 근본 전달 프로토콜로서 TCP를 사용할 때, 요청되도록 허용되는 가외적인 데이터의 양은 X·Recwindow로 셋팅될 수 있는데, 여기서 Recwindow는 현재 TCP-수신 윈도우 사이즈이거나, 또는 클라이언트 디바이스의 TCP 수신 버퍼에 평균적으로 얼마나 많은 옥텟들(바이트들) 또는 데이터가 상주하였는지에 대한 측정이거나, 또는 다수의 TCP 연결들을 사용하는 경우에 TCP 수신 버퍼들의 평균적인 종합적 바이트 점유 또는 모든 TCP-수신 윈도우 사이즈들의 종합이다. 그러한 실시예들에서, CM(122)은 이러한 파라미터들을 RM(121)에 시그널링할 수 있다(예컨대, CM은 DR 및 RTT의 현재 추정들 또는 Recwindow의 현재 추정을 RM에 제공할 수 있다).

[0065] 본원의 개념들로부터 벗어나지 않으면서 RM-fixed-FEC 기술들을 제공하는데 있어 다양한 대안들이 활용될 수 있다는 점이 인지되어야 한다. 예컨대, 비록 UA가 (예컨대, 앞서 언급된 긴급 팩터를 사용하여) 요청된 프래그먼트에 대해 사용될 FEC 데이터의 양을 결정(예컨대, 블록(206)에서)하기 위해 동작하는 실시예들이 위에서 설명되었지만, 중복 인코딩 컨텐츠 데이터를 사용하여 컨텐츠의 가속된 전달을 제공하도록 본원의 개념들에 따라 적응되는 시스템의 다른 컴포넌트들이 사용될 FEC 데이터의 양을 결정하도록 동작할 수 있다. UA 이외의 다른 컴포넌트가 사용될 FEC 데이터의 양을 결정하도록 동작하는 구현의 예로서, 실시예들의 CM은 슝크(schunk)를 결정하고 시그널링할 수 있는데, 여기서 슝크는 각각의 청크 요청에 대해 CM에 적절한 목표 데이터 청크 요청 사이즈이다. CM은 TCP 전송기가 청크 요청을 수신한 이후에 한번에 전송하도록 허용될 수 있는 데이터의 양에 슝크를 기초할 수 있는데, 이 경우에는 청크 요청이 TCP 전송기에 의해 수신될 시간에 그 TCP 연결에 대한 현재 TCP 혼잡 윈도우 사이즈의 추정에 슝크의 값이 기초할 수 있다. 따라서, 슝크의 값은 프래그먼트 요청과 연관하여 요청될 수 있는 각각의 데이터 청크의 사이즈를 설정하는데 있어서 RM에 의해 활용될 수 있다.

[0066] 적합한 중복 인코딩 컨텐츠 데이터에 대한 정보의 하나 또는 그 초과의 파라미터들이 요청된 프래그먼트 이외의 얼마나 많은 데이터가 요청될지를 결정하는데 있어서 추가적으로 또는 대안적으로 (예컨대, RM(121)에 의해서) 활용될 수 있다는 것이 인지되어야 한다. 그에 따라서, 도 2에 예시된 흐름(200)의 실시예는 블록들(202 및 206) 간의 선택적 데이터 경로를 포함하고, 이로 인해서 그러한 정보는 본원에 설명된 바와 같이 하나 또는 그 초과의 결정들에서 사용하기 위해 전달될 수 있다.

[0067] 실시예들에 따라 UA(129) 및 CM(122)에 의해서 RM(121)에 제공될 수 있는 파라미터들을 사용하는 FEC 프래그먼트(R)를 사용하여 프래그먼트(F)에 대한 강건한 RM-fixed-FEC 기술을 구현하기 위한 세부사항을 도시하는 의사(pseudo) 코드가 아래에 제공된다:

[0068] 프래그먼트 데이터 이외의 데이터의 양을 결정(블록(206))하였고 그리고 프래그먼트 및 가외적인 데이터 요청을 수행(블록(203))하였다면, 적절할 때, 본원의 RM-fixed-FEC 기술에 따른 RM(121) 동작은 요청된 프래그먼트의 컨텐츠 데이터뿐만 아니라 요청된 프래그먼트 이외의 FEC 데이터를 수신할 수 있다(블록(204)). 도 2에 설명된 동작들은 다른 블록들로부터의 다른 부분 단계들과 시간적으로 혼합된 블록과 연관되는 부분 단계들을 수행하는 것을 잠재적으로 수반한다는 것이 인지되어야 한다. 예컨대, 블록(206)의 부분 부단계들을 수행하는 것은 블록들(203, 204 및 205)의 부분 부단계들을 수행하는 것과 시간적으로 혼합될 수 있다.

[0069] 비록 요청된 프래그먼트의 데이터 이외의 FEC 데이터를 요청하는 것이 네트워크를 통해 전달되는 데이터의 양을 증가시킬 수 있지만, 다양한 데이터 패킷들이 상이한 시간들에 도달할 수 있다(예컨대, 일부 데이터 패킷들은 지연될 수 있는데 반해 다른 데이터 패킷들은 더욱 시기적절하게 도달된다). 요청된 프래그먼트 데이터와 FEC 데이터의 다양한 조합들이 프래그먼트를 복원하기 위해 사용될 수 있다. 그에 따라서, 본원의 RM-fixed-FEC 기술을 구현하는 RM(121)의 실시예들은 프래그먼트의 복원을 제공하기에 충분한 가장 이른 수신 데이터(프래그먼트 데이터 또는 프래그먼트 데이터와 FEC 데이터의 조합이든 간에)를 사용하여 그 프래그먼트를 복원할 수 있다. 따라서, 프래그먼트는 RM(121)에 의해서 신속히 복원되고, 컨텐츠의 소비를 위해 UA(129)에 제공될 수 있다(블록(205)).

[0070] 추가적으로 또는 대안적으로, 실시예들의 RM은 요청된 프래그먼트들에 대해 얼마나 많은 FEC 데이터를 사용할지를 자동으로 결정하도록 적응될 수 있다. 그에 따라서, RM-fixed-FEC 구성에 대한 대안으로, 실시예들의 RM(121)은 프래그먼트들을 복원하는데 도움이 되게 FEC 데이터를 사용할 뿐만 아니라 프래그먼트들에 대해 얼마나 많은 FEC를 사용할지를 자동으로 결정하도록 적응될 수 있고, 이로 인해서 RM-auto-FEC로서 본원에서 지칭되는 FEC 데이터 기술을 구현하는 RM(121)의 구성이 제공된다. RM-auto-FEC 기술의 구현은 여러 이유들로 인해 일부 상황들에서는 RM-fixed-FEC 기술에 비해 바람직할 수 있다. 특히, 실시예들의 RM-auto-FEC 기술들은 요청된 FEC 데이터의 양을 각각의 프래그먼트를 복원하는데 필요한 FEC 데이터의 양으로 자동적으로 튜닝한다. 따라서, 프래그먼트에 대한 다운로딩되는 데이터의 양은 최소화됨으로써, 사용할 FEC의 양이 UA에 의해 결정될 때 RM-fixed-FEC의 경우보다 평균적으로 더 적은 전체적인 다운로딩 데이터가 일반적으로 필요하게 된다. 요청된 프래그먼트들의 시기적절한 전달은 RM-auto-FEC를 사용하여 최대화하는 동시에 일반적으로 RM-fixed-FEC의 경우보다 양호한 또는 더 양호한 시기적절한 전달을 제공한다. 게다가, 요청할 FEC 데이터의 양은 RM에 의해서 자동으로 결정되기 때문에, UA는 임의의 FEC 로직을 사용하거나 통합하기 위해 FEC의 양을 명시할 필요가 없다. 이것은 UA 상에서 요건들을 간략화하고 감소시키며, 일반적으로 (예컨대, FEC 데이터를 요청할지 또는 디코딩할지 여부에 상관없이 어떤 FEC 로직도 포함하지 않는 UA 구성을 비롯해서) 상이한 UA 구성들에 RM0-auto-FEC 방법들이 더욱 광범위하게 적용가능게 만든다.

[0071] 실시예들의 RM-auto-FEC 기술에 따른 동작이 도 3에서 흐름(300)으로서 도시되어 있다. 본원의 실시예들의 RM-auto-FEC 기술들의 개념들을 이해하는데 도움을 주기 위해서, RM-auto-FEC 기술들은 위에서 제공된 RM-fixed-FEC 기술들의 논의의 확장으로서 설명된다. 그에 따라서, 위에서 설명된 RM-fixed-FEC 기술들에서처럼, 본원에 설명된 RM-auto-FEC 기술들의 경우, 프래그먼트(F)에 대한 요청이 UA(129)에 의해 막 수행되었고(블록(301)), 따라서 F는 초기에 활성되고 적격이라는 것이 가정된다.

[0072] 예시된 실시예에 따른 동작에 있어서, RM(121)은 프래그먼트 요청과 연관하여 적합한 양의 중복 인코딩 컨텐츠 데이터의 사용을 위한 정보를 획득한다(블록(302). 그러한 정보는 요청된 프래그먼트의 컨텐츠 데이터에 대응하는 FEC 데이터의 소스의 식별뿐만 아니라 RM(121)에 의한 FEC 데이터의 사용에 대한 다른 정보를 포함할 수 있다. 예컨대, 매칭 FEC 프래그먼트(R)에 관한 정보, 및 심볼 사이즈(T)가 프래그먼트(F)에 대한 요청이 RM(121)에 제공될 때 이용가능하거나 그렇지 않으면 결정가능할 수 있다. 비록 UA(129)가 FEC 데이터의 사용에 대해 유용한 일부 정보를 RM(121)에 제공할 수 있지만(예컨대, 블록(301)에서), 실시예들의 RM(121)은 FEC 데이터를 활용하기 위한 정보를 결정하거나 그렇지 않으면 획득하도록 동작할 수 있다. 예컨대, UA(129)는 프래그먼트(F)의 바이트들 단위의 사이즈인 FB를 제공할 수 있지만, 대응하는 FEC 프래그먼트(R)의 바이트들 단위의 사이즈(RB)는 RM에 의해서 FB로부터 자동으로 도출될 수 있다(예컨대, “ENHANCED BLOCK-REQUEST STREAMING USING COOPERATIVE PARALLEL HTTP”란 명칭의 미국 특허 출원 번호 제 12/887,495호에 도시되고 설명된 기술들을 사용하며, 이로 인해 그 미국 특허 출원의 개시내용은 인용에 의해 본원에 통합된다).

[0073] 대안적으로, FB의 값은 F 또는 R의 적어도 일부에 대한 요청의 응답으로 획득될 수 있다. FEC 인코딩 및 FEC 디코딩(F)을 위해 사용할 심볼들의 사이즈(T)는 F의 사이즈(FB)로부터 자동으로 결정될 수 있다. 예컨대, FEC 인코더 및 DEC 디코더 둘 모두에서 T를 T=max {4, floor(FB/2,048)}로서 도출하는 것은, 동일한 심볼 사이즈가 인코딩 및 디코딩하기 위해 사용되는 것 및 F가 분할되는 소스 심볼들의 수가 만약 FB가 적어도 8 킬로바이트들이라면 적어도 2,048이라는 것을 보장한다. 이것은, FEC 디코딩에 유용하지 않을 수 있는 부분 심볼들을 수신하는 것으로 인해 데이터를 수신하는 것에 대한 각각의 응답으로 수신된 데이터에 있어 최대 0.1%의 낭비만이 존재하는 것을 보장할 수 있다. 예컨대, F의 바이트 범위에 대한 청크 요청에 대한 응답은, 응답의 최대 두 개의 부분 심볼들 중 나머지가 다른 응답들로 수신되지 않는 경우 FEC 디코딩에 유용하지 않을 수 있는 그 최대 두 개의 부분 심볼들(응답의 처음의 하나의 부분 심볼, 끝의 하나의 부분 심볼, 여기서 중간 응답 데이터 모두는 최대 심볼들을 포함함)을 포함할 수 있고, 응답 당 2개의 낭비되는 부분 심볼들은 만약 FB가 적어도 8 킬로바이트들이라면 프래그먼트(F)의 최대 2/2,048=0.1%만을 포함한다.

[0074] FEC 프래그먼트(R)에 대한 URL, 또는 FEC 데이터를 식별하고 액세스하기 위해 적절한 다른 정보가 실시예들에 따라 UA(129)로부터의 어떠한 입력도 필요치 않고 RM(121)에 의해 자동으로 생성될 수 있다. 위에서 논의된 실시예들에서처럼, FB가 T의 배수가 아닐 때 F의 마지막 부분에 대한 요청을 제외하고, 데이터 요청 사이즈들은 T 바이트들의 배수들로 만들어질 수 있거나, 또는 심볼 사이즈(T)가 공지될 때까지는, 예컨대 일단 FB가 프래그먼트(F)에 대해 전송된 데이터 요청에 대한 응답으로 결정되면 T가 FB에 기초하여 결정된다. RM(121)이 FEC를 사용하지 않는 경우, 실시예들은 T의 값이 공지될 때까지 T=1을 셋팅할 수 있다. 대안으로서, T-바이트 정렬에 기초하지 않는 모든 요청들이 수행될 수 있는데, 즉, 효과적으로 T=1이 모든 데이터 요청들에 대해 사용되고, 이어서 응답들을 통해 수신되는 데이터는 만약 FEC 디코딩이 프래그먼트를 복원하기 위해 사용된다면 FEC 디코딩의 목적을 위해 RM(121)에 의해서 심볼들로 내부적으로 분할된다.

[0075] 본원의 RM-auto-FEC 기술에 따른 동작에 있어서, RM(121)은 요청된 프래그먼트 이외의 얼마나 많은 데이터를 요청할지를 동적으로 그리고 자동으로 결정하도록 동작한다(블록(303)). 그러한 결정들은 프래그먼트 요청 시에 또는 그 시간 근처에서 이루어짐으로써, 프래그먼트 요청과 비교적 동시적인 네트워크 조건들 및/또는 다른 환경들에 대해 시기적절한 가외적인 데이터에 대한 결정들을 동적으로 제공한다. 그러나, 실시예들은 바람직하다고 결정될 때 다른 시간들에서 그러한 결정들을 수행하도록 추가적으로 또는 대안적으로 동작할 수 있다. 적합한 중복 인코딩 컨텐츠 데이터에 대한 정보의 하나 또는 그 초과의 파라미터들이 요청된 프래그먼트 이외의 얼마나 많은 데이터가 요청될지를 동적으로 결정하는데 있어서 RM(121)에 의해서 활용될 수 있다는 것이 인지되어야 한다.

[0076] 본원의 RM-auto-FEC 기술의 실시예들은 위에서 논의된 RM-fixed-FEC 기술(예컨대, 미리 결정된 디폴트 값, 네트워크 조건들에 의존하여 변하는 팩터(X) 등을 사용함)로 구현되는 것들과 동일하거나 유사한, 요청된 프래그먼트 이외의 얼마나 많은 데이터가 요청될지를 결정하기 위한 하나 또는 그 초과의 프로세스들을 구현한다. 그러한 추가 데이터가 실시예들의 RM-auto-FEC 기술에 따라 프래그먼트에 대해 요청될 때에 대한 조건은 RM-fixed-FEC 기술의 조건과 상이할 수 있다. 특히, RM-fixed-FEC 기술들의 실시예들은 요청된 프래그먼트의 데이터 이외의 데이터를 균일하게 요청하도록 동작하고(예컨대, 각각의 프래그먼트에 대한 그러한 추가 데이터를 요청함), 반면에 RM-auto-FEC 기술의 실시예들은 요청된 프래그먼트의 데이터 이외의 데이터가 언제 그리고 얼마나 많이 요청될 것인지를 동적으로 결정하도록 동작한다(예컨대, 네트워크 조건들에 기초하여 그러한 추가 데이터를 요청함).

[0077] 실시예들의 RM(121)은 프래그먼트 데이터를 (예컨대, 하나 또는 그 초과의 청크 요청들로서) 요청할 수 있고, 적합한 것으로 결정될 때, RM(121)은 CM(122)으로부터의 프래그먼트 데이터 이외의 가외적인 데이터를 요청할 수 있다(블록(303)). 실시예들의 RM-auto-FEC 기술에 따른 동작에 있어서, 요청된 프래그먼트에 추가하여 언제 그리고 얼마나 많은 데이터가 요청될지에 관한 결정은 네트워크 조건들(예컨대, 늦는 데이터의 양의 측정 및/또는 네트워크를 통해 요청되는 데이터의 늦음)에 적어도 부분적으로 의존한다.

[0078] 실시예들의 RM(121)에 대한 예시적인 프로세스에 따라, 그것은 임의의 특정 프래그먼트에 대해 추가 데이터를 요청할 적절한 시기 및 얼마나 많은 그러한 데이터를 요청할지를 동적으로 그리고 자동으로 결정한다. RM(121)으로부터 CM(122)으로의 데이터 요청들의 순서가 지연되거나 늦는 데이터 패킷들을 식별하는데 있어 사용하기 위해 정의된다. 예컨대, RM으로부터 CM으로의 데이터 요청들의 순서는 RM이 CM으로부터의 데이터를 요청하는 순서로서 정의될 수 있고, 이로 인해 데이터의 더 이른 요청된 청크들이 데이터의 청크들의 후속 요청들보다 순서에 있어서 더 이르다. 그러한 실시예에서, 청구 요청 내의 데이터의 순서는 자연적인 순서로서 정의될 수 있다(즉, 청크 요청들의 제 1 바이트들이 청크 요청의 후속 바이트들보다 순서에 있어 더 이르다).

[0079] 전술한 데이터의 순서를 사용하여, 실시예들의 RM(121)은, 만약 그 RM이 데이터의 제 1 부분을 요청하였지만 그 데이터의 제 1 부분이 요청된 이후에 RM에 의해서 요청된 데이터의 제 2 부분이 수신될 때도 그 데이터의 제 1 부분이 아직 수신되지 않았다면, 그 데이터의 제 1 부분을 늦는 것으로(그리고 어쩌면 손실된 것으로) 간주하도록 동작할 수 있다. 예컨대, RM에 의해 요청되었지만 아직 수신되지 않은 데이터의 일부에 대해: 데이터의 일부에 후속하는 요청된 어떤 데이터도 RM에 의해 아직 수신되지 않았다면 그 데이터의 일부를 "계류 중인 것"으로 정의하고; 그리고 RM에 의해 수신되어진, 데이터의 일부에 후속하는 요청된 데이터가 존재한다면, 그 데이터의 일부를 "늦는 것"으로 확인응답되는 것으로서 정의하자.

[0080] RM-fixed-FEC 기술에 대해 위에서 정의된 변수들에 추가하여, 프래그먼트에 대한 계류 중인 데이터의 양인 변수(PK) 및 프래그먼트에 대한 늦는 데이터의 양인 변수(LK)가 본원의 실시예들의 RM-auto-FEC 기술에 대해 사용하기 위해 정의될 수 있다. 전술한 것으로부터, 프래그먼트에 대한 요청되었지만 확인응답되지 않은 데이터의 총 양인 UK는 UK=PK+LK로서 표현될 수 있다는 것이 인지될 수 있다. 프래그먼트에 대한 수신되는 데이터의 총 양인 변수(RK)가 실시예들의 RM-auto-FEC 기술에 대해 사용하기 위해 추가로 정의될 수 있다(만약 정확한 동일 데이터가 프래그먼트에 대해 두 번 수신된다면, 그것은 RK에서 단지 한번 카운팅된다). 본원에서 제공되는 예들의 경우, 전술한 양들 모두는, 비록 다른 유닛들(예컨대, 바이트들 또는 옥텟들 단위로 데이터의 양들을 측정하는 것)이 실시예들에 따라 활용될 수 있지만, 심볼들의 유닛들로 측정되는 것으로 가정된다.

[0081] 추가로, 실시예들의 RM(121)은 프래그먼트에 대해 임의의 시점에 확인되는 늦는 데이터의 최대 양을 계속 추적할 수 있다(예컨대, 변수(maxLK)는 제로로 초기화될 수 있고, 이후에 프래그먼트에 대해 LK의 값이 바뀔 때마다 maxLK=maximum{LK, maxLK}가 다시 계산될 수 있다). 그러한 프래그먼트 최대 늦는 데이터 변수는, 예컨대, 실시예들에 따라 늦음 변수(LK)의 잠재적으로 매우 가변적인 특성을 완화하도록 활용될 수 있다. 대안으로서, maxLK는 프래그먼트들의 S의 일부 이전 윈도우에 걸쳐 임의의 시점에 늦는 데이터의 최대 양으로서 정의될 수 있는데, 여기서 S는 구성가능한 파라미터이고, 예컨대 S=10이다. 다른 변경으로서, 최대치가 계산되는 윈도우는 이전 시간의 구성가능한 지소기간에 걸쳐, 또는 RTT와 같은 다른 측정들에 의존하는 이전 시간의 지속기간에 걸쳐, 또는 구성가능한 수의 이전 청크 요청들에 걸쳐 있을 수 있다. 다른 대안으로서, LK의 값은 근본 프래그먼트 구조와 상관없이 유지될 수 있는데, 예컨대 각각의 청크 요청이 어떤 프래그먼트로부터 생성되는지와 무관하게 RM에 의해 수행되는 청크 요청들의 순서에 기초할 수 있다.

[0082] 실시예들에 따른 동작에 있어서, RM(121)이 프래그먼트에 대한 데이터를 수신할 때마다, RK의 값은 수신된 데이터의 양만큼 증가되고(그것이 동일한 프래그먼트에 대해 이전에 수신된 정확한 동일 데이터가 아닌 한), UK의 값은 이러한 양만큼 감소되고, PK의 값은 이전에 계류 중이었던 이러한 데이터의 양만큼 감소되며, LK의 값은 이전에 늦었던 이러한 데이터의 양만큼 감소된다. 또한, 데이터가 RM(121)에 의해 수신될 때는, 만약 아직 계류 중인 이전에 요청된 데이터가 존재한다면, 이러한 이전에 요청된 데이터는 계류 중인 것으로부터 늦는 것으로 다시 분류되고, 이러한 이전에 요청된 데이터의 사이즈가 PK로부터 감산되고 LK에 가산된다.

[0083] 도 4는 전술한 수신되는 계류 중인 그리고 늦는 데이터와 전술한 변수들의 대응하는 값들을 예시하는 타임라인을 도시한다. 도 4의 타임라인에서, RM(121)은 CM(122)에 대해 프래그먼트의 데이터 청크들에 대한 요청을 수행하는데, 먼저 데이터 청크 1(C1)에 대한 요청을 수행하고, 이어서 데이터 청크 2(C2)에 대한 요청을 수행하며, 이어서 데이터 청크 3(C3)에 대한 요청을 수행한다. 예시된 예에서, 데이터 청크들 각각은 사이즈에 있어 8 KB이고, 각각의 데이터 청크는 4 KB의 두 이산적인 단편들로 각각 수신된다(표기 Ci.j는 데이터청크(i)의 j번째 단편을 표시하도록 사용된다). 도 4의 타임라인 아래에 도시된 정보는 RK, PK, LK 및 maxLK의 값들이 데이터 청크들에 대해 RM에 의한 새로운 요청들 또는 이전에 요청된 청크들에 대해 RM에 의한 데이터의 수신 중 어느 하나로 인해 바뀔 때를 예시한다는 것이 인지되어야 한다.

[0084] 도 4에 표시된 시나리오에 도시된 바와 같이, RM(121)이 데이터 청크 1(C1)을 요청할 때는, RK=0(어떠한 데이터도 아직 수신되지 않았기 때문임), PK=8 KB(사이즈 8 KB의 데이터 청크 1이 지금 계류 중이기 때문임), LK=0(어떠한 데이터도 아직 늦지 않기 때문임), 및 maxLK=0이다. 데이터 청크 1의 제 1 단편(C1.1)이 RM(121)에 의해 수신된 직후의 타임라인의 시점에서는, RK=4 KB(C1.1이 수신되었기 때문임), PK=4 KB(C1.2가 지금 계류 중이기 때문임), LK=0(어떠한 데이터도 아직 늦지 않기 때문임), 및 maxLK=0이다. RM(121)이 데이터 청크 2(C2)를 요청할 때는, RK=4 KB(C1.1이 수신되었기 때문임), PK=12 KB(C1.2, C2.1 및 C2.2가 계류 중이기 때문임), LK=0(어떠한 데이터도 아직 늦지 않기 때문임), 및 maxLK=0이다. 데이터 청크 2의 제 1 단편(C2.1)이 RM(121)에 의해 수신된 직후의 타임라인의 시점에서는, RK=8 KB(C1.1 및 C2.1이 수신되었기 때문임), PK=4 KB(C2.2가 여전히 계류 중이기 때문임), LK=4 KB(C2.2의 도달이 C1.2가 늦도록 트리거하기 때문임) 및 maxLK=4 KB이다. RM(121)이 데이터 청크 3(C3)을 요청할 때는, RK=8 KB(C1.1 및 C2.1이 수신되었기 때문임), PK=12 KB(C2.2가 여전히 계류 중이고 또한 지금 C3.1 및 C3.2가 계류 중이기 때문임), LK=4 KB(C1.2가 여전히 늦기 때문임), 및 maxLK=4 KB이다. 데이터 청크 3의 제 1 단편(C3.1)이 RM(121)에 의해 수신된 직후의 타임라인의 시점에서는, RK=12 KB(C1.1, C2.1 및 C3.1이 수신되었기 때문임), PK=4 KB(C3.2가 계류 중이기 때문임), LK=8 KB(지금 C1.2 및 C2.2 둘 모두가 늦기 때문임) 및 maxLK=8 KB이다. 데이터 청크 1의 제 2 단편(C1.2)이 RM(121)에 의해 수신된 직후의 타임라인의 시점에서는, RK=16 KB(C1.1, C1.2, C2.1 및 C3.1이 수신되었기 때문임), PK=4 KB(C3.2가 계류 중이기 때문임), LK=4 KB(지금 단지 C2.2만이 늦기 때문임) 및 maxLK=8 KB이다. 데이터 청크 2의 제 2 단편(C2.2)이 RM(121)에 의해 수신된 직후의 타임라인의 시점에서는, RK=20 KB(C1.1, C1.2, C2.1, C2.2 및 C3.1이 수신되었기 때문임), PK=4 KB(C3.2가 여전히 계류 중이기 때문임), LK=0 KB(지금 C2.2가 지금 도달하였고 어떤 다른 늦는 데이터도 없기 때문임) 및 maxLK=8 KB이다. 데이터 청크 3의 제 2 단편(C3.2)이 RM(121)에 의해 수신된 직후의 타임라인의 시점에서는, RK=24 KB(C1.1, C1.2, C2.1, C2.2, C3.1 및 C3.2가 수신되었기 때문임), PK=0 KB(어떤 계류 중인 데이터도 없기 때문임), LK=0 KB(어떤 늦는 데이터도 없기 때문임) 및 maxLK=0 KB이다.

[0085] 비록 위의 예에서는 모든 데이터 청크들이 단일 프래그먼트에 대한 것이었지만, 제시된 개념들은 다수의 프래그먼트들에 적용된다는 것이 인지되어야 한다. 예컨대, 다수의 프래그먼트들이 존재할 때는, RK, UK, PK, LK 및 maxLK의 값들이 프래그먼트마다 유지될 수 있거나, 대안적으로는 청크 요청들이 생성되는 프래그먼트들과 무관하게 청크 요청들에 기초하여 유지될 수 있다(예컨대, 구성가능한 수의 이전 청크들의 윈도우 또는 구성가능한 수의 이전 바이트들의 윈도우 또는 구성가능한 지속기간의 이전 시간에 걸쳐 계산될 수 있음). 그러나, 만약 RM이 제 1 프래그먼트에 대한 제 1 데이터 청크를 요청하고 이어서 RM이 제 2 프래그먼트에 대한 제 2 데이터 청크를 요청한다면, 제 2 데이터 청크의 단편들의 도달은 제 1 데이터 청크의 아직 도달되지 않은 단편들을 늦는 것으로서 RM에 의해 분류되게 만들 수 있다.

[0086] 전술한 파라미터들을 사용하여, 데이터(예컨대, 요청된 프래그먼트의 데이터뿐만 아니라 요청된 프래그먼트 이외의 데이터)에 대한 요청이 언제 수행될 수 있고 얼마나 많은 데이터를 요청할 것인지에 관한 결정이 이루어진다. 추가 데이터는 프래그먼트 데이터에 대한 요청과 함께(예컨대, 초기 청크 요청 또는 청크 데이터의 재요청인지에 상관없이 청크 요청의 부분으로서 또는 그 청크 요청과 연관하여) 요청되거나 또는 데이터에 대한 별도 요청으로서(예컨대, 추가 데이터에 대한 독립적인 요청으로서 또는 늦는 또는 분실 데이터에 대한 응답으로 독립적인 요청으로서) 요청될 수 있다는 것이 인지되어야 한다. 그러나, RM(121)이 데이터 청크에 대한 요청을 수행할 때마다, 명시되는 최소 사이즈 데이터 청크(예컨대, 4 KB, 8 KB 등)가 존재할 수 있는데, 그 최소 사이즈 데이터 청크는 예컨대 프래그먼트의 사이즈 또는 슝크의 값에 의존적일 수 있다(슝크는 CM(122)에 적절한 목표 데이터 청크 요청 사이즈임).

[0087] 기본 RM-auto-FEC 구현에 따른 동작에 있어서는, 조건 "RK+PK < K+XK"가 충족되는 한은 임의의 특정 프래그먼트에 대한 더 많은 데이터가 전술한 네트워크 조건 파라미터들에 따라 RM(121)에 의해서 요청될 수 있다(예컨대, 도 3의 블록(303)에서)(즉, 프래그먼트에 대한 수신되거나 계류 중인 데이터의 양이 최대로 프래그먼트의 사이즈와 XK의 합인 한은 다른 데이터 청크 요청이 수행될 수 있다). RM(121)은, 예컨대, CM(122)에 의한 RM(121)으로의 데이터 전달의 전체적인 패턴 및 네트워크 조건에 무관하게 XK의 값을 셋팅할 수 있다. 실시예들의 RM-auto-FEC 기술의 경우, XK의 값은 RM(121)에 의해서 작은 값으로 자동으로 셋팅될 수 있다(예컨대, XK는 {4 KB, 0.004·K}의 최소치로 셋팅될 수 있고, XK는 슝크로 셋팅될 수 있고, XK는 0으로 설정될 수 있고, 기타 등등).

[0088] 더욱 강건한 RM-auto-FEC 구현에 따른 동작에 있어서는, LK를 전술한 부등식(UK=PK+LK를 상기하자)의 각각의 사이드에 더하여, 조건이 RK+UK < K+XK+LK로서 기재될 수 있고(즉, 프래그먼트에 대한 수신되거나 요청된 데이터의 양이 최대로 프래그먼트의 사이즈(K)와 프래그먼트의 사이즈의 바이트들의 추가적인 일정 수(XK)와 프래그먼트에 대한 늦는 데이터의 양(LK)의 합이 되는 한, 다른 데이터 청크 요청이 수행될 수 있음), 이로 인해 LK의 값은 늦는 요청된 데이터의 양으로 인해 얼마나 많은 가외적인 데이터가 요청되도록 허용되는지(예컨대, 블록(303)에서)를 제공한다. 전술한 것의 변경들에서, RM-auto-FEC 구현의 실시예들은, 조건 "RK+UK < K+XK+α·LK"이 충족되는 한은 RM(121)이 프래그먼트에 대한 추가 데이터를 요청하도록 허용되는 동작을 제공할 수 있고, 여기서 α는 적절하게 선정된 상수(예컨대, α=0.5, α=1, 또는 α=3)이다. 전술한 조건에서 프래그먼트에 대해 임의의 시점에서 확인되는 최대 양의 늦는 데이터(maxLK)를 사용하는 것은 늦음 변수(LK)의 잠재적으로 매우 가변적인 특성을 완화시키기 위해 활용될 수 있다. 그러한 실시예에서, 조건 "RK+UK < K+XK+α·maxLK"이 충족되는 한은 RM(121)이 프래그먼트에 대한 추가 데이터를 요청하도록 허용될 수 있고, 여기서 α는 적절하게 선정된 상수(예컨대, α=0.5, α=1, 또는 α=1.5)이다. 대안적으로는, 조건 "RK + UK < K + XK + α·FB·maxLK/W"이 충족되는 한은 RM(121)이 프래그먼트에 대한 추가 데이터를 요청하도록 허용될 수 있는데, 여기서 FB는 프래그먼트의 사이즈이고, W은 maxLK가 측정되는 바이트들의 윈도우이다.

[0089] 전술한 것에 대해, 늦는 것으로 분류되는 데이터 및 그에 따라 LK에서 카운팅되는 데이터의 사이즈는 본질적으로 손실된 데이터로 일시적으로 카운팅되는 데이터라는 것이 인지되어야 한다. 계류 중인 데이터가 늦게 될 때, 이러한 데이터의 사이즈는 PK로부터 감산되고 LK에 가산되며, 이는 위에서 기술된 특정 조건들에 따라 이러한 프래그먼트에 대한 더 많은 데이터가 요청되도록 잠재적으로 허용할 수 있다. 그러나, 늦게 되는 임의의 요청된 데이터가 수신되자마자, 그것의 사이즈는 RK에 가산되고 LK로부터 감산되며, 따라서 짧은 시간 기간 동안 늦는 것으로 분류되는 임의의 데이터는 단지 이러한 짧은 시간 기간 동안 RK+PK로부터 분실될 것이다(단지 이러한 짧은 시간 기간 동안 LK에 기여함). LK를 사용하는 전술한 조건에 따르면, 단지 다소 늦게 수신되는 데이터는 단지 짧은 시간 기간 동안 LK에 기여할 것이다(예컨대, 만약 데이터가 어느 정도의 시간(T)으로 늦는 것으로 먼저 결정되고 데이터가 시간 t+X에 도달한다면, 이러한 데이터는 t와 t+X 사이의 시간 기간 동안에만 LK에 기여한다). 예컨대, 만약 X=RTT라면(여기서, RTT는 현재 라운드 트립 시간임), 데이터는 단지 그 RTT 동안 LK에 기여할 것이다. 따라서, 만약 DR이 수신 데이터의 현재 레이트이고 데이터가 단지 최대 하나의 RTT에서 비순서적으로 수신된다면, LK는 임의의 시점에 최대 DR·RTT이다. 그에 따라서, LK의 값은 임의의 시간에 얼마나 많은 가외적인 데이터가 실시예들에 따라 늦는 데이터로 인해 요청되도록 허용되는지를 정량화한다. 특히, LK를 사용하여 조건들을 구현하는 전술한 실시예들에서, LK의 값은 늦는 요청된 데이터에 대한 양의 자동 조정으로 인해 얼마나 많은 가외적인 데이터가 RM-fixed-FEC 기술과 비교해서 RM-auto-FEC 기술을 사용할 때 요청되도록 허용되는지의 차이이다.

[0090] 만약 요청된 데이터가 단지 짧은 시간 기간들 동안 늦는다면, 심지어 대부분의 데이터가 적어도 일부 시간 기간 동안 늦는 것으로서 분류되더라도, 그것은 수신되고(만약 그것이 계속 수신된다면) 따라서 약간 비순서적으로 수신된다. 실시예들에 따라 늦는 데이터로 인해 요청되는 데이터의 가외적인 양은 일반적으로 작다(즉, LK의 값은 일반적으로 작게될 것이다). 그러나, 요청된 데이터가 계속해서 늦게 되는 시간의 양이 증가함에 따라, 각각의 시점에 더욱 현저한 요청되었지만 늦는 데이터가 존재할 것이고, 따라서 LK의 값은 일반적으로 증가할 것이며(즉, 수신되는 데이터의 순서의 더욱 상당한 차이가 존재할 때, LK의 값은 일반적으로 더 커짐), 그에 따라서 늦는 데이터로 인한 허용되는 요청된 데이터의 양이 증가할 것이다. 실시예들에 따른 동작에 있어서, 늦는 데이터의 도달이 더욱 지연될수록, 추가적인 요청된 데이터가 요청되도록 허용하는 것에 대해 늦는 데이터는 더 큰 악영향을 준다. 만약 요청된 데이터가 영구적으로 손실된다면, 그 데이터의 사이즈는 그 데이터가 늦는 것으로 분류되는 시간부터 LK에 대한 기여로서 남을 것이고(또는 시간의 윈도우, 또는 바이트들의 윈도우, 또는 청크들의 윈도우, 또는 프래그먼트들의 윈도우에 걸쳐 남을 것이고, 그것들 동안에 LK는 계산됨), 그런 이후에 실시예들에 따라 이러한 손실 데이터에 대해 가외적인 데이터가 요청되도록 허용될 것이다.

[0091] XK의 값은 RM-fixed-FEC 기술들에 대해서보다 RM-auto-FEC 기술들에 대해 훨씬 더 작은 값으로 일반적으로 셋팅되는데, 그 이유는 그것이 상이한 목적으로 제공되기 때문이다. 실시예들의 RM-fixed-FEC 기술들의 경우, XK의 값은 수신되었거나(RK) 이미 요청되었지만 아직 수신되지 않은 것(UK) 이외의 요청될 수 있는 가외적인 데이터의 양을 결정한다. 그에 따라서, 그러한 RM-fixed-FEC 기술의 경우, XK의 값은 일반적으로, 얼마나 많은 비순서적인 데이터가 수신될 것으로 예상되는지, 데이터 중 일부가 다른 데이터에 비교해서 얼마나 느리게 도달할 것인지, 얼마나 많은 데이터가 손실되는지 등과 같은 고려사항들에 따라 셋팅된다. 따라서, XK의 값은 통상적으로 RM-fixed-FEC 기술들에 대한 일부 추가 정보를 사용하여 셋팅된다(위에서 의사 코드에서 도시된 바와 같이). 그러나, 실시예들의 RM-auto-FEC 기술들의 경우, 다른 데이터보다 더 느리게 도달하는 일부 데이터에 대해 그리고 손실된 데이터에 대해 비순서적인 데이터를 고려하는 것은 LK의 값에 의해 제공된다(PK의 값은 LK의 값만큼 UK의 값보다 작다). 따라서, 실시예들의 RM-auto-FEC 기술들에 대한 XK의 역할은, 프래그먼트에 대한 마지막 요청된 데이터 중 일부가 만약 느리게 도달한다면 늦는 것으로 분류되는 것을 보장하기 위해서 프래그먼트를 복원하기 위해 실제로 필요한 것 이외의 일부 데이터가 요청되는 것을 확실하게 하는 것이다. 즉, 데이터의 마지막 XK 바이트들을 요청함으로써, 그것이 도달할 때, 느리게 도달하거나 손실된 임의의 이전에 요청된 데이터는 이어서 늦는 것으로 분류될 것이고, 따라서 이러한 느리게 도달하거나 손실된 데이터에 대한 추가 요청을 잠재적으로 트리거링한다. 이러한 이유로, XK의 값은 실시예들의 RM-auto-FEC 기술들의 경우 자동으로 작은 고정 값으로 셋팅될 수 있다.

[0092] RM이 프래그먼트들의 시퀀스를 요청하고 있는 상황에서, 실시예들의 RM(121)은 각각의 프래그먼트에 대한 얼마나 많은 데이터를 요청할지를 결정하기 위해서 RM에 의해 사용될 수 있는 다수의 프래그먼트들에 대한 통계치를 계산할 수 있다. 예컨대, avgmaxLK를 다수의 연속 프래그먼트들의 윈도우에 걸쳐 프래그먼트 당 평균 최대 늦는 데이터라고 하자. 실시예들에 따른 동작에 있어서, 조건 "RK+UK < K+XK+α·avgmaxLK"가 충족되는 한은 RM(121)이 프래그먼트에 대한 추가 데이터를 요청하도록 허용될 수 있고, 여기서 α는 적절하게 선정된 상수(예컨대, α=0.5, α=1, 또는 α=1.5)이다. avgmaxLK의 값은, 실시예들에 따라, maxLK의 가중된 이동 평균을 사용하여 업데이팅될 수 있는데, 여기서 maxLK는 현재 프래그먼트에 대한 값이다(예컨대, avgmaxLK는 avgmaxLK = β·avgmaxLK + (1-β)· maxLK로서 업데이팅되고, 여기서 β는 적절하게 선정된 상수(예컨대, β < 1)이다). 대안적으로, 실시예들의 avgmaxLK의 값의 업데이팅은 로직을 구현할 수 있는데, 여기서 만약 maxLK > avgmaxLK라면, avgmaxLK = β1·avgmaxLK + (1-β1)·maxLK인데 반해, 만약 maxLK ≤ avgmaxLK라면, avgmaxLK = β2·avgmaxLK + (1-β2)·maxLK이고, 여기서 0 < β2 < β1 < 1이다. 본원의 실시예들에 따라 구현될 수 있는 평균화 로직의 다른 예들은 현재 프래그먼트에 대해 과거 연속 프래그먼트들의 이동 윈도우에 걸쳐 maxLK의 값의 95 퍼센트(또는 임의의 다른 적절한 퍼센트)를 사용하는 것이다.

[0093] 늦는 데이터에 대해서 데이터를 요청할 시기 및 요청될 데이터의 양을 결정하기 위한 RM(121)의 동작의 다른 예로서, RM은 그 데이터의 늦음을 계속 추적할 수 있고, 이로 인해 그 RM은 데이터의 늦음에 적어도 부분적으로 기초하여 프래그먼트에 대한 더 많은 데이터가 요청될 수 있는지 여부에 대해 결정하는 것에 기초할 수 있다. 예컨대, 데이터의 늦음은, 데이터가 늦는 것으로 분류되는 시점에 후속하여 수신되는 데이터의 바이트들의 수로서 계산될 수 있다. 다른 예로서, 데이터의 늦음은, 수신되어진 데이터에 후속하여 요청되어진 데이터의 바이트들의 수로서 계산될 수 있다. 늦는 데이터의 늦음에 기초하여 그 늦는 데이터의 각각의 단편에 대한 가중 팩터가 계산될 수 있다. 예컨대, 만약 늦는 데이터의 단편의 늦음이 LB 바이트들이라면, 데이터의 그 늦는 단편의 가중치는 1 + LB/K로서 계산될 수 있다. 다른 예로서, 데이터의 늦는 단편의 가중치는 e^LB ^/K로서 계산될 수 있다. 또 다른 예로서, 데이터의 그 늦는 단편의 가중치는 2-e^-LB/UK로서 계산될 수 있다. 가중치를 계산하기 위해 사용되는 특정 기술에 상관없이, 총 가중치(wtL)는 모든 늦는 데이터의 가중치의 합으로서 계산될 수 있다. 실시예들에 따른 동작에 있어서, 조건 "RK+UK < K+XK+wtL"이 충족되는 한은 RM(121)이 프래그먼트에 대한 추가 데이터를 요청하도록 허용될 수 있다. 지금까지의 프래그먼트에 걸친 wtL의 최대치는 대안적인 실시예에 따라 전술한 조건에서의 wtL로 대체될 수 있다.

[0094] 데이터가 요청될 시기 및 요청될 데이터의 양을 결정하는데 있어 이용되는 특정 로직에 상관없이, 도 3에 도시된 흐름(300)의 실시예에 따른 RM-auto-FEC 기술의 동작에 있어서, RM(121)은 프래그먼트 및 가외적인 데이터 요청에 대한 응답으로, 요청된 프래그먼트의 컨텐츠 데이터뿐만 아니라 요청된 프래그먼트 이외의 FEC 데이터를 수신한다(블록(304)). 위의 RM-fixed-FEC 기술들에처럼, 본원의 RM-auto-FEC 기술을 구현하는 RM(121)의 실시예들은 프래그먼트의 복원을 제공하기에 충분한 가장 이른 수신 데이터(프래그먼트 데이터 또는 프래그먼트 데이터와 FEC 데이터의 조합이든 간에)를 사용하여 그 프래그먼트를 복원할 수 있다. 게다가, 네트워크 조건(예컨대, 늦는 데이터의 양 및 요청된 데이터의 늦음)에 기초하여 임의의 특정 프래그먼트에 대해 FEC 데이터가 요청되는지 여부 및 얼마나 많은 FEC 데이터가 요청되는지를 동적으로 조정하는 것을 통해서, 네트워크를 통해 전달되는 데이터의 양에 대한 증가가 최소화되거나 최적화될 수 있다. 따라서, 프래그먼트는 네트워크 혼잡에 최소로 영향을 주면서 RM(121)에 의해서 신속히 복원되고, 컨텐츠의 소비를 위해 UA(129)에 제공될 수 있다(블록(305)).

[0095] RM-auto-FEC 구성의 변경에서, 실시예들의 RM(121)은 프래그먼트들에 대해 얼마나 많은 FEC를 사용할 지를 자동으로 결정하기 위해서뿐만 아니라 FEC 프래그먼트들에 대한 URL들을 자동으로 결정하게 동작하도록 적응될 수 있고, 이로 인해 RM-auto-FEC+URL로서 본원에서 지칭되는 FEC 데이터 기술을 구현하는 RM(121)의 구성이 제공된다. RM-auto-FEC+URL 기술의 실시예들에 따른 동작에 있어서, RM(121)은 소스 프래그먼트들의 UA 제공 URL들로부터 FEC 프래그먼트들에 대한 URL들을 자동을 결정한다. 실시예들의 RM-auto-FEC+URL 기술은, RM(121)이 FEC 인코딩 및 디코딩을 위해 사용할 심볼들의 사이즈들을 결정하는 것을 또한 포함한다(예컨대, RM은 프래그먼트의 사이즈에 기초하여 사용할 심볼 사이즈를 자동으로 결정하고, RM은 FEC 프래그먼트의 제 1 부분을 판독하고(여기서 심볼 사이즈는 FEC 프래그먼트의 프리엠블에서 이용가능함), 기타 등등이다). (예컨대, FEC 프래그먼트들이 UA에 요청되는 소스 프래그먼트들에 대해 이용가능한 한) 어떤 FEC 시멘틱스 또는 로직도 UA에 의해 사용되지 않고도 UA들을 포함하는 임의의 UA 구성에 의해 RM-auto-FEC+URL 기술들이 사용될 수 있다는 것이 인지되어야 한다. RM-auto-FEC+URL 동작을 위해 구성되는, UA(129)와 RM(121) 간에 구현될 수 있는 바와 같은 기본 API가 도 5에 예시되어 있다.

[0096] RM-auto-FEC+URL 구성의 변경은, 중복 인코딩 데이터를 사용할지 여부를 자동으로 결정함으로써 RM-fully-auto로서 본원에서 지칭되는 FEC 데이터 기술을 구현하는 RM(121)의 구성을 제공하도록 실시예들의 RM(121)이 추가로 적응되는 구성을 제공한다. RM-fully-auto 기술의 실시예들에 따른 동작에 있어서, 본원의 실시예들의 RM(121)은 FEC 데이터를 사용할지 여부를 자동으로 결정하도록 동작한다. 동작에 있어서, RM(121) 및 CM(122)은 FEC 프래그먼트들이 이용가능한지 여부를 자동을 결정하기 위해 협력할 수 있다(예컨대, 각각의 프래그먼트 또는 프래그먼트들의 시퀀스에 대해). 예컨대, CM(122)은 FEC 프래그먼트들에 대한 하나 또는 그 초과의 요청들을 전송할 수 있고, 이로 인해 RM(121)은 응답에 의존하여 그들의 이용가능성을 결정할 수 있다(예컨대, FEC 프래그먼트의 일부에 대한 HTTP 요청에 대해서 "404 not founded"의 응답은 FEC 프래그먼트가 이용가능하지 않다는 것을 표시하기 위해 활용될 수 있다. 만약 FEC 프래그먼트들이 이용가능하지 않다면, RM(121) 및 CM(122)은 FEC 데이터를 사용하지 않는 기술들에 따른 동작으로 진행할 수 있다. 그러나, 만약 FEC 프래그먼트들이 이용가능하다고 결정된다면, RM(121) 및 CM(122)은 본원의 개념들에 따라 프래그먼트 요청들과 연관하여 FEC 데이터 기술들을 활용할 수 있다(예컨대, RM-auto-FEC+URL 기술을 구현할 수 있음). 따라서, 요청된 프래그먼트에 대해 FEC 데이터가 이용가능할 때는, FEC 데이터가 RM(121) 및 CM(122)에 의해 자동으로 사용될 수 있고, FEC 데이터가 이용가능하지 않을 때는, RM(121) 및 CM(122)이 그럼에도 불구하고 FEC 데이터를 사용하지 않고도 동작할 수 있다. 따라서, UA(129)의 임의의 구성은, FEC 프래그먼트들이 이용가능한지 여부에 상관없이, 어떤 FEC 시멘틱스 또는 로직도 UA에 의해 사용되지 않고도, RM-fully-auto 방법을 사용할 수 있다.

[0097] 본원에 설명된 바와 같은 RM-auto-FEC 기술들을 구현하기 위한 하나의 잠재적인 사용 경우는 CM(122)이 DASH 또는 HLS를 사용하여 저 레이턴시 라이브 스트리밍을 위한 다중 연결 동작(예컨대, CM-mHTTP 구성)을 위해 구성되는 것과 공조하여 RM(121)이 구현될 RM-auto-FEC 동작을 위해 구성되는 경우이다.

[0098] 그러한 라이브 스트리밍 상황들에 있어서, 이벤트가 비디오 카메라에 의해 캡쳐되는 시기와 대응하는 이벤트가 최종 사용자 디바이스 상에서 디스플레이되는 시기 사이의 엔드-투-엔드 레이턴시는 최소화되어야 한다. 라이브 스트림은 비디오 프래그먼트들의 시퀀스로 인코딩되는데, 여기서 예컨대 각각의 프래그먼트는 비디오 스트림의 1초를 포함한다. 각각의 비디오 프래그먼트가 생성될 때, 그것은 DASH 클라이언트들 또는 HLS 클라이언트들이 표준 HTTP/TCP를 사용하여 프래그먼트들을 액세스하는 HTTP 웹 서버들에 이용가능하게 된다. 더욱 난해한 네트워크 조건들에 있어서는, 비디오 프래그먼트들을 다운로딩하기 위해 단일 HTTP/TCP 연결을 사용하여 가능할 수 있는 것보다 더 나은 품질의 비디오 스트림을 제공할 수 있도록 DASH 또는 HLS 클라이언트들이 다수의 HTTP/TCP 연결들을 사용하는 것이 유리할 수 있다.

[0099] 중요도의 한 기준은 수신기측 레이턴시인데, 그 수신기측 레이턴시는 비디오의 프래그먼트가 HTTP 웹 서버들에서 이용가능할 때와 비디오의 프레임이 최종 디바이스 상에서의 재생을 위해 준비되는 시간까지 사이의 시간으로서 정의된다. 통상적으로, 수신기측 레이턴시는 엔드-투-엔드 레이턴시에 대해 주요 기여자이다. 따라서, 수신기측 레이턴시를 최소화하는 것은 엔드-투-엔드 레이턴시를 최소화하는데 결정적일 수 있다. 본원의 실시예들의 구현에서, DASH 클라이언트 또는 HLS 클라이언트는 UA(129)이고, 그리고 그 UA는 재생을 위한 프래그먼트들을 제공하기 위해 TA(120)(RM(121) 및 CM(122)을 포함함)를 사용하고 있으며, 이로 인해 충분한 데이터(프래그먼트 데이터만이든 또는 프래그먼트 데이터와 추가 데이터의 조합이든 간에) 가 프래그먼트를 복원하기 위해 수신되자마자 프래그먼트들의 복원을 용이하게 하기 위해서 다수의 연결들을 사용하여 FEC 데이터가 동적으로 요청될 수 있다.

[00100] 전술한 것으로부터, 전달 가속기의 실시예들은 소스 프래그먼트 요청들의 전달을 가속시키는데 도움이 되도록 소스 컨텐츠 데이터(즉, 비-중복 인코딩 데이터) 외에도 FEC 데이터와 같은 중복 인코딩 데이터를 활용한다는 것이 인지될 수 있다. 그러한 중복 인코딩 데이터는 중복 인코딩 데이터 파일들을 생성하기 위한 다수의 공지된 기술들 중 임의의 기술을 사용하여 생성될 수 있다. 예컨대, 잘 알려진 FEC 데이터 파일 생성 기술들은 본원의 실시예들에 따라 활용될 수 있다. UA가 DASH 클라이언트를 포함하는 경우에, 예컨대, 적절한 FEC 데이터 파일은 "ENHANCED BLOCK-REQUEST STREAMING USING COOPERATIVE PARALLEL HTTP"란 명칭의 미국 특허 출원 번호 제 12/887,495호에 도시되고 설명된 기술들을 사용하여 생성될 수 있고, 이로 인해 그 출원의 개시내용은 인용에 의해 본원에 통합된다.

[00101] 비록 소스 프래그먼트 파일들 및 대응하는 중복 인코딩 데이터 파일들이 동일 서버 또는 서버 팜(farm)(예컨대, 서버(130))에 의해 소싱되는 실시예들이 본원에 설명되었지만, 본원의 개념들은 그러한 구현들로 제한되지 않는다는 것이 인지되어야 한다. 예컨대, 본원의 실시예들의 TA(120)는 본원의 개념들에 따라 데이터의 가속된 전달을 제공하기 위해서 중복 인코딩 데이터의 독립적인 소스 또는 제공자에 대해 동작하도록 적응될 수 있다. 예컨대, 컨텐츠 제공자는 자신의 컨텐츠에 대한 FEC 데이터를 제공하길 원하지 않거나 또는 이를 위한 자원들을 갖지 않을 수 있다. 그러한 상황에서, RM(121)의 실시예는 독립적인 제 3자 FEC 제공자와 동작하도록 적응될 수 있다. 도 6에 도시된 시스템(600)의 구성이 이러한 개념을 예시하였는데, 여기서 FEC 서버(630)는 서버(130)에 의해서 제공되는 컨텐츠에 대응하는 중복 인코딩 데이터를 제공한다.

[00102] 중복 인코딩 데이터의 독립적인 소스 또는 제공자를 활용하는 구성, 예컨대 시스템(600)은 본원에서 컨텐츠를 전달하기 위한 다양한 방식들로 동작할 수 있다. 예컨대, 실시예들의 RM(121)은 컨텐츠 제공자(서버(130))에게 소스 요청들을 발생하고 FEC 제공자(FEC 서버(630))에게 FEC 요청들을 발생하도록 동작한다. 그러한 실시예에서는, 따라서, FEC 제공자가 컨텐츠 제공자로부터 독립적으로 컨텐츠를 페칭(fetch)하고, 그것을 FEC 인코딩하며, FEC 인코딩 심볼들을 RM(121)에 다시 전송할 수 있다. 그에 따라서, RM(121)은 모든 소스 데이터를 먼저 페칭하기 보다는 오히려 자신이 요청한 임의의 자원에 대한 FEC 데이터를 즉시 페칭하기 시작하도록 동작할 수 있어서, FEC 제공자가 제일 먼저 소스 세그먼트들 자체를 페칭할 필요가 있고 이어서 인코딩 심볼들을 소스에 전송하기 이전에 데이터를 인코딩해야 하는 것으로부터 초해하는 레이턴시가 회피된다.

[00103] 중복 인코딩 데이터의 독립적인 소스 또는 제공자를 활용하는 구성의 다른 예에서, RM(121)은 FEC 제공자(예컨대, FEC 서버(630))를 통해 소스 데이터 및 추가 데이터 둘 모두를 페칭하도록 동작한다. 따라서, 그러한 실시예에서의 FEC 제공자는, 소스 제공자(예컨대, 서버(130))로부터 소스 데이터 자체를 페칭하고 FEC 데이터를 실시간으로(on the fly) 컴퓨팅하는 프록시처럼 동작할 수 있다. 이러한 실시예들의 장점은, 컨텐츠 제공자가 FEC 데이터의 사용으로 인한 증가된 트래픽에 대처할 필요가 없다는 것이다(예컨대, RM(121)이 컨텐츠 제공자로부터의 소스 데이터 및 FEC 제공자로부터의 추가 데이터를 요청하고 있는 위의 예에서는, 컨텐츠 제공자가 FEC 서버(630)(FEC 인코딩을 위해) 및 UA(129) 둘 모두에 각각의 데이터 세그먼트를 전송한다).

[00104] 실시예들에 따른 동작에서, FEC 제공자(예컨대, FEC 서버(630))는 간단한 일반적 중복 인코딩을 제공할 수 있다. 예컨대, 인코딩되는 데이터 유닛들(예컨대, 프래그먼트들)은 단지 컨텐츠만에 의해서 고정되고 결정될 수 있다. FEC 심볼 사이즈도 마찬가지로 컨텐츠에 의해 고정되고 결정될 수 있다. 그러한 실시예는 FEC 제공자가 상이한 클라이언트들에 대한 동일 데이터를 반복적으로 FEC 인코딩해야 할 필요성을 감소시키기 위해 활용될 수 있다(예컨대, FEC 제공자는 인기있는 컨텐츠를 캐싱(cache)할 수 있고, 따라서 메모리 저장을 위한 컴퓨테이션 비용과 네트워크 트래픽을 절충시킨다).

[00105] 본원의 실시예들에 따라, FEC 제공자는 UA에 일반적일 수 있고, 이로 인해 UA는 자신이 요청하는 컨텐츠의 자원(예컨대, URI를 이용하는), 바이트 범위, 심볼 사이즈 등을 명시할 수 있고, FEC 제공자는 그에 따라 요청된 FEC 코딩을 실시간으로 생성할 수 있다(예컨대, 전술한 정보가 FEC 컨텐츠 제공자에서 URL 질의 스트링으로 전달될 수 있다). 그러한 실시예에 따른 동작에 있어서, FEC 제공자는 요청된 FEC 데이터를 정확하게 제공할 수 있다(또는 그 데이터가 실행하기에 비실용적인 경우에는 에러 코드를 반송할 수 있다). 그러한 실시에의 장점은 UA가 자신의 사용 경우에 최상으로 적합한 파라미터들을 선택하는 것이 가능할 수 있다는 것이다(예컨대, 매우 짧은 엔드-투-엔드 레이턴시를 제공하는 UA는 짧은 엔드-투-엔드 레이턴시와 관련되지 않은 UA에 비해서 더 짧은 FEC 보호 기간들을 선택할 수 있다).

[00106] 본원에 설명된 기술들은 실시예들에 따라, 어떤 FEC 제공자도 존재하지 않고 그러므로 FEC 데이터가 사용될 수 없는 경우들에 적응될 수 있다. 예컨대, UA는 어떤 요청들이 "늦는지"를 식별하기 위해서, 이를테면 FEC 데이터를 요청하기 보다는 오히려 검출된 늦는 부분들에 대한 중복 청크 요청들을 다시 발생하기 위해 이러한 정보를 사용하기 위해서, 설명된 바와 동일하거나 유사한 알고리즘들을 사용할 수 있다. 그러므로, 실시예들에 따른 동작에 있어서, 만약 TCP 연결이 데이터를 매우 느리게 수신하거나 또는 새로운 데이터의 수신을 완전히 중단한다면, 중복 요청이 분실 단편들을 획득하는데 있어 도움을 줄 수 있다.

[00107] 그러한 중복 요청들은 일반적으로 역방향 순서로 저장되는 세그먼트를 지칭하고, 그로 인해 디폴트적으로 두 단부들로부터의 갭들이 채워질 것이다. 대안적으로, UA는 정규 세그먼트를 지칭하지만, 응답의 순서의 대략적인 역순을 획득하기 위해 다수의 바이트 범위들을 사용할 수 있다(예컨대, 만약 6 KB 내지 10 KB의 홀(hole)이 채워질 필요가 있다면, 클라이언트는 9 BK-10 KB, 8 KB-9 KB, 7 KB-8 KB, 6 KB-7 KB의 HTTP 바이트 범위를 사용할 수 있고, 따라서 클라이언트는 역순으로 블록들을 수신할 것이다). 그러한 접근법을 위한 양호한 블록 사이즈는 대략적으로 TCP MSS일 것이다.

[00108] 클라이언트가 실시예들에 따라 적용될 수 있는 유사한 사상의 추가 기술은 순향적 방식으로 완전히 분리적인 청크들은 요청하지 않지만 데이터의 오버랩핑 단편을 갖는 청크들은 요청하는 것이다. 예컨대, 만약 스트림의 200 KB의 단편이 2개의 청크들을 통해 요청될 것이라면, 제 1 청크의 0-100 KB 및 제 2 청크의 100 KB-200 KB로부터 요청하는 대신에, UA는 제 1 청크의 0-100 KB 및 예컨대 제 2 청크의 94 KB-200 KB를 요청할 수 있어서, 6 KB의 오버랩이 초래된다. 이러한 전력은, 청크의 마지막 단편들이 응답에서 조기의 것들보다 실질적인 지연에 직면하기 훨씬 더 쉽다는 사실을 고려한다. 만약 임의의 조기 TCP 세그먼트가 손실된다면, 전송기에 의해 수신되는 복제 확인응답들이 일반적으로 상당히 신속하게 재송신을 트리거시킬 것이다. 송신이 끝날 무렵에 TCP 세그먼트들에 대해서는 그렇지 않다(예컨대, 그러한 경우들에서, 전송기는 재송신을 트리거시키기 위해 충분한 복제 ACK들을 수신하지 않을 수 있고, 따라서 그것은 단지 일단 타임아웃이 발생하면 데이터를 재송신할 것인데, 이는 일반적으로 훨씬 긴 시간이 걸린다). 그 외에도, 청크의 중간에 임의의 지연이 청크의 마지막의 수신에 대한 지연을 또한 야기하기 쉽다.

[00109] UA의 로직은 필요한 오버랩의 양을 감소시키기 위한 전략을 구현할 수 있다. 예컨대, UA는 청크 응답이 끝날 무렵에는 "지연된 ACK들"을 디스에이블시킬 수 있고, 그로 인해서 마지막 몇몇 TCP 세그먼트들에 대한 복제 ACK들이 서버에 의해서 확인될 가능성이 증가된다.

[00110] 스마트 서버가 필요한 오버랩의 양을 추가로 감소시키기 위해 사용될 수 있다. 예컨대, 실시예들의 서버는 그것이 일반적으로 사용하는 것들보다 송신의 마지막 단편들에 대한 훨씬 더 작은 TCP 세그먼트들을 전송할 수 있다.

[00111] 비록 선택된 양상들이 예시되고 상세히 설명되었지만, 다양한 대체들 및 변경들이 아래의 청구항들에 의해 정의되는 본 발명의 사상 및 범위로부터 벗어나지 않고 본원에서 이루어질 수 있다는 것이 이해될 것이다.

Claims

클라이언트 디바이스의 전달 가속기(TA)에 의해서 상기 클라이언트 디바이스의 사용자 에이전트(UA)로 컨텐츠의 전달을 가속시키기 위한 방법으로서, 상기 방법은,
상기 TA의 요청 관리자(RM)에 의해서, 컨텐츠 서버에 컨텐츠를 요청하기 위해 상기 UA에 의해 제공되는 프래그먼트 요청들을 수신하는 단계;
상기 프래그먼트 요청들 중 한 프래그먼트 요청에 대응하는 프래그먼트의 컨텐츠를 복원하는데 있어 상기 RM에 의해 사용하기 위한 상기 프래그먼트 요청을 요청하기 위해서 중복 인코딩 컨텐츠 데이터의 양을 결정하는 단계; 및
상기 RM에 의해서, 상기 중복 인코딩 컨텐츠 데이터의 양이 상기 프래그먼트 요청을 위해 요청될 때를 결정하는 단계를 포함하고,
상기 중복 인코딩 컨텐츠 데이터의 양이 요청될 때를 결정하는 단계는 미리 요청된 데이터를 늦는 것으로 상기 RM에 의해서 간주하는 단계를 포함하는, 컨텐츠의 전달을 가속시키기 위한 방법.
제 1항에 있어서,
상기 중복 인코딩 컨텐츠 데이터는 순방향 에러 정정(FEC) 인코딩 데이터를 포함하는, 컨텐츠의 전달을 가속시키기 위한 방법.
제 2항에 있어서,
상기 RM은 상기 UA에 의해 수행된 상기 프래그먼트 요청의 컨텐츠를 복원하고 대응하는 복원된 프래그먼트를 상기 UA에 제공하기 위해서 상기 RM에 의해 수신된 데이터에 대해 FEC 디코딩을 이용하는, 컨텐츠의 전달을 가속시키기 위한 방법.
제 1항에 있어서,
상기 컨텐츠 및 상기 중복 인코딩 컨텐츠 데이터를 요청하는데 있어 그리고 상기 요청에 대한 응답으로 상기 컨텐츠 서버로부터 컨텐츠의 송신에 있어 HTTP/TCP(Hypertext Transfer Protocol/Transmission Control Protocol)이 활용되는, 컨텐츠의 전달을 가속시키기 위한 방법.
제 4항에 있어서,
상기 프래그먼트 요청과 연관된 자원 식별 정보가 중복 인코딩 컨텐츠 데이터의 적어도 일부를 제공하기 위해 사용되는 중복 인코딩 컨텐츠 프래그먼트의 일부에 대한 HTTP 요청을 결정하는데 사용되는, 컨텐츠의 전달을 가속시키기 위한 방법.
제 1항에 있어서,
상기 RM에 의해서, 상기 프래그먼트 요청들 중 한 프래그먼트 요청에 기초하여 복수의 청크 요청들을 결정하는 단계를 더 포함하고,
상기 복수의 청크 요청들 중 적어도 하나의 청크 요청은 상기 프래그먼트 요청에 대응하는 프래그먼트의 일부에 대한 요청을 포함하고,
상기 복수의 청크 요청들 중 적어도 다른 하나의 청크 요청은 상기 프래그먼트 요청에 대응하는 프래그먼트와 연관된 중복 인코딩 컨텐츠 프래그먼트의 일부에 대한 요청을 포함하는, 컨텐츠의 전달을 가속시키기 위한 방법.
제 6항에 있어서,
상기 RM에 의해서, 상기 TA의 연결 관리자(CM)에 의해 관리되는 복수의 연결들을 통해 상기 복수의 청크 요청들 중 둘 이상을 병렬로 상기 컨텐츠 서버에 요청하는 단계를 더 포함하는, 컨텐츠의 전달을 가속시키기 위한 방법.
제 7항에 있어서,
상기 UA에 의해 요청되는 프래그먼트의 일부에 대한 요청은 상기 복수의 연결들 중 제 1 연결을 통해서 컨텐츠 서버에 대해 수행되고,
상기 중복 인코딩 컨텐츠 프래그먼트의 일부에 대한 요청은 상기 복수의 연결들 중 제 2 연결을 통해서 중복 인코딩 컨텐츠 데이터 서버에 대해 수행되며,
상기 컨텐츠 서버 및 상기 중복 인코딩 컨텐츠 데이터 서버는 별개의 그리고 독립적인 서버들인, 컨텐츠의 전달을 가속시키기 위한 방법.
제 6항에 있어서,
프래그먼트를 요청하기 위한 상기 중복 인코딩 컨텐츠 데이터의 양은 상기 프래그먼트에 대한 청크들의 수신 동안 상기 프래그먼트에 대한 동시적으로 늦는 데이터의 최대 양에 기초하고,
청크 내의 제 1 데이터는, 만약 상기 제 1 데이터가 상기 RM에 의해서 요청되었지만 아직 수신되지 않았고 적어도 일부 제 2 데이터가 상기 제 1 데이터 이후에 요청되어 수신되었다면, 특정 시점에 늦는 것으로서 분류되는, 컨텐츠의 전달을 가속시키기 위한 방법.
제 9항에 있어서,
상기 RM은, 상기 프래그먼트에 대한 수신된 데이터의 총 양과 요청되었지만 아직 수신되지 않은 상기 프래그먼트에 대한 데이터의 양의 합이 임의의 시점까지 상기 프래그먼트의 사이즈의 바이트들의 추가적인 일정 수와 상기 프래그먼트에 대한 동시적으로 늦는 데이터의 최대 양의 합 내에 있는 한, 상기 프래그먼트에 대한 추가적인 청크 요청들을 수행하도록 적응되는, 컨텐츠의 전달을 가속시키기 위한 방법.
제 1항에 있어서,
상기 프래그먼트를 요청하기 위해서 중복 인코딩 컨텐츠 데이터의 양을 결정하는 단계는 상기 프래그먼트에 대한 미리 요청된 데이터를 충분히 빠르게 수신하지 못하는 것에 기초하여 상기 프래그먼트에 대해 요청될 추가적인 중복 인코딩 컨텐츠 데이터를 결정하는 단계를 포함하고,
비록 상기 미리 요청된 데이터가 도달할 경우 상기 미리 요청된 데이터의 양이 상기 RM이 상기 프래그먼트를 완전히 복원하기에 충분할지라도 그리고 비록 상기 미리 요청된 데이터 모두가 상기 RM에 의해 수신될지라도, 상기 추가적인 중복 인코딩 컨텐츠 데이터는 요청되도록 결정되는, 컨텐츠의 전달을 가속시키기 위한 방법.
제 1항에 있어서,
상기 프래그먼트 요청을 요청하기 위해서 중복 인코딩 컨텐츠 데이터의 양을 결정하는 단계는 현재 네트워크 조건들에 적어도 부분적으로 기초하는, 컨텐츠의 전달을 가속시키기 위한 방법.
제 12항에 있어서,
상기 현재 네트워크 조건들은 현재 다운로드 레이트(R) 및 현재 라운드-트립 시간(RTT)의 함수로써 결정되는 대역폭-지연 결과를 포함하는, 컨텐츠의 전달을 가속시키기 위한 방법.
제 1항에 있어서,
상기 프래그먼트 요청을 요청하기 위해서 중복 인코딩 컨텐츠 데이터의 양을 결정하는 단계는 상기 프래그먼트 요청을 요청하기 위해 데이터의 총 양을 결정하는 단계를 포함하고,
상기 데이터의 총 양은 상기 중복 인코딩 컨텐츠 데이터의 양 및 에러 정정 인코딩되지 않은 컨텐츠 데이터의 양을 포함하는, 컨텐츠의 전달을 가속시키기 위한 방법.
제 1항에 있어서,
상기 RM에 의해서, 복수의 프래그먼트 요청들 각각과 연관하여 요청할 중복 인코딩 컨텐츠 데이터의 양을 동적으로 조정하는 단계를 더 포함하는, 컨텐츠의 전달을 가속시키기 위한 방법.
제 1항에 있어서,
상기 RM에 의해서, 상기 UA에 의해 제공된 프래그먼트 요청들 중 임의의 특정 프래그먼트 요청과 연관하여 중복 인코딩 컨텐츠 데이터가 요청될지 여부를 결정하는 단계를 더 포함하는, 컨텐츠의 전달을 가속시키기 위한 방법.
제 16항에 있어서,
상기 중복 인코딩 컨텐츠 데이터가 요청될지 여부를 결정하는 단계는 상기 TA에 의해서, 상기 UA에 의해 제공된 프래그먼트 요청들의 하나 또는 그 초과의 프래그먼트들에 대해 중복 인코딩 컨텐츠 데이터가 이용가능하다고 결정하는 단계를 포함하는, 컨텐츠의 전달을 가속시키기 위한 방법.
제 1항에 있어서,
상기 UA는 중복 인코딩 컨텐츠 데이터를 활용하기 위한 로직을 포함하지 않는, 컨텐츠의 전달을 가속시키기 위한 방법.
제 18항에 있어서,
상기 중복 인코딩 컨텐츠 데이터는 순방향 에러 정정(FEC) 인코딩 데이터를 포함하는, 컨텐츠의 전달을 가속시키기 위한 방법.
클라이언트 디바이스의 전달 가속기(TA)에 의해서 상기 클라이언트 디바이스의 사용자 에이전트(UA)로 컨텐츠의 전달을 가속시키도록 구성되는 장치로서, 상기 장치는,
상기 TA의 요청 관리자(RM)에 의해서, 컨텐츠 서버에 컨텐츠를 요청하기 위해 상기 UA에 의해 제공되는 프래그먼트 요청들을 수신하기 위한 수단;
상기 프래그먼트 요청들 중 한 프래그먼트 요청에 대응하는 프래그먼트의 컨텐츠를 복원하는데 있어 상기 RM에 의해 사용하기 위한 상기 프래그먼트 요청을 요청하기 위해서 중복 인코딩 컨텐츠 데이터의 양을 결정하기 위한 수단; 및
상기 RM에 의해서, 상기 중복 인코딩 컨텐츠 데이터의 양이 상기 프래그먼트 요청을 위해 요청될 때를 결정하기 위한 수단을 포함하고,
상기 중복 인코딩 컨텐츠 데이터의 양이 요청될 때를 결정하기 위한 수단은 미리 요청된 데이터를 늦는 것으로 상기 RM에 의해서 간주하기 위한 수단을 포함하는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 20항에 있어서,
상기 중복 인코딩 컨텐츠 데이터는 순방향 에러 정정(FEC) 인코딩 데이터를 포함하는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 21항에 있어서,
상기 RM은 상기 UA에 의해 수행된 프래그먼트 요청의 컨텐츠를 복원하고 복원된 프래그먼트를 상기 UA에 제공하기 위해서 상기 RM에 의해 수신된 데이터에 대해 FEC 디코딩을 이용하는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 20항에 있어서,
상기 컨텐츠 및 상기 중복 인코딩 컨텐츠 데이터를 요청하는데 있어 그리고 상기 요청에 대한 응답으로 상기 컨텐츠 서버로부터 컨텐츠의 송신에 있어 HTTP/TCP(Hypertext Transfer Protocol/Transmission Control Protocol)이 활용되는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 23항에 있어서,
상기 프래그먼트 요청과 연관된 자원 식별 정보가 중복 인코딩 컨텐츠 데이터의 적어도 일부를 제공하기 위해 사용되는 중복 인코딩 컨텐츠 프래그먼트의 일부에 대한 HTTP 요청을 결정하는데 사용되는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 20항에 있어서,
상기 RM에 의해서, 상기 프래그먼트 요청들 중 한 프래그먼트 요청에 기초하여 복수의 청크 요청들을 결정하기 위한 수단을 더 포함하고,
상기 복수의 청크 요청들 중 적어도 하나의 청크 요청은 상기 프래그먼트 요청에 대응하는 프래그먼트의 일부에 대한 요청을 포함하고,
상기 복수의 청크 요청들 중 적어도 다른 하나의 청크 요청은 상기 프래그먼트 요청에 대응하는 프래그먼트와 연관된 중복 인코딩 컨텐츠 프래그먼트의 일부에 대한 요청을 포함하는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 25항에 있어서,
상기 RM에 의해서, 상기 TA의 연결 관리자(CM)에 의해 관리되는 복수의 연결들을 통해 상기 복수의 청크 요청들 중 둘 이상을 병렬로 상기 컨텐츠 서버에 요청하기 위한 수단을 더 포함하는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 26항에 있어서,
상기 UA에 의해 요청되는 프래그먼트의 일부에 대한 요청은 상기 복수의 연결들 중 제 1 연결을 통해서 컨텐츠 서버에 대해 수행되고,
상기 중복 인코딩 컨텐츠 프래그먼트의 일부에 대한 요청은 상기 복수의 연결들 중 제 2 연결을 통해서 중복 인코딩 컨텐츠 데이터 서버에 대해 수행되며,
상기 컨텐츠 서버 및 상기 중복 인코딩 컨텐츠 데이터 서버는 별개의 그리고 독립적인 서버들인, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 25항에 있어서,
프래그먼트를 요청하기 위한 상기 중복 인코딩 컨텐츠 데이터의 양은 상기 프래그먼트에 대한 청크들의 수신 동안 상기 프래그먼트에 대한 동시적으로 늦는 데이터의 최대 양에 기초하고,
청크 내의 제 1 데이터는, 만약 상기 제 1 데이터가 상기 RM에 의해서 요청되었지만 아직 수신되지 않았고 적어도 일부 제 2 데이터가 상기 제 1 데이터 이후에 요청되어 수신되었다면, 특정 시점에 늦는 것으로서 분류되는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 28항에 있어서,
상기 RM은, 상기 프래그먼트에 대한 수신된 데이터의 총 양과 요청되었지만 아직 수신되지 않은 상기 프래그먼트에 대한 데이터의 양의 합이 임의의 시점까지 상기 프래그먼트의 사이즈의 바이트들의 추가적인 일정 수와 상기 프래그먼트에 대한 동시적으로 늦는 데이터의 최대 양의 합 내에 있는 한, 상기 프래그먼트에 대한 추가적인 청크 요청들을 수행하도록 적응되는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 20항에 있어서,
상기 프래그먼트를 요청하기 위해서 중복 인코딩 컨텐츠 데이터의 양을 결정하기 위한 수단은 상기 프래그먼트에 대한 미리 요청된 데이터를 충분히 빠르게 수신하지 못하는 것에 기초하여 상기 프래그먼트에 대해 요청될 추가적인 중복 인코딩 컨텐츠 데이터를 결정하기 위한 수단을 포함하고,
비록 상기 미리 요청된 데이터가 도달할 경우 상기 미리 요청된 데이터의 양이 상기 RM이 상기 프래그먼트를 완전히 복원하기에 충분할지라도 그리고 비록 상기 미리 요청된 데이터 모두가 상기 RM에 의해 수신될지라도, 상기 추가적인 중복 인코딩 컨텐츠 데이터는 요청되도록 결정되는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 20항에 있어서,
상기 프래그먼트 요청을 요청하기 위해서 중복 인코딩 컨텐츠 데이터의 양을 결정하기 위한 수단은 현재 네트워크 조건들에 적어도 부분적으로 기초하여 중복 인코딩 컨텐츠 데이터의 양을 결정하기 위한 수단을 포함하는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 31항에 있어서,
상기 현재 네트워크 조건들은 현재 다운로드 레이트(R) 및 현재 라운드-트립 시간(RTT)의 함수로써 결정되는 대역폭-지연 결과를 포함하는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 20항에 있어서,
상기 프래그먼트 요청을 요청하기 위해서 중복 인코딩 컨텐츠 데이터의 양을 결정하기 위한 수단은 상기 프래그먼트 요청을 요청하기 위해 데이터의 총 양을 결정하기 위한 수단을 포함하고,
상기 데이터의 총 양은 상기 중복 인코딩 컨텐츠 데이터의 양 및 에러 정정 인코딩되지 않은 컨텐츠 데이터의 양을 포함하는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 20항에 있어서,
상기 RM에 의해서, 복수의 프래그먼트 요청들 각각과 연관하여 요청할 중복 인코딩 컨텐츠 데이터의 양을 동적으로 조정하기 위한 수단을 더 포함하는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 20항에 있어서,
상기 RM에 의해서, 상기 UA에 의해 제공된 프래그먼트 요청들 중 임의의 특정 프래그먼트 요청과 연관하여 중복 인코딩 컨텐츠 데이터가 요청될지 여부를 결정하기 위한 수단을 더 포함하는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 35항에 있어서,
상기 중복 인코딩 컨텐츠 데이터가 요청될지 여부를 결정하기 위한 수단은 상기 TA에 의해서, 상기 UA에 의해 제공된 프래그먼트 요청들의 하나 또는 그 초과의 프래그먼트들에 대해 중복 인코딩 컨텐츠 데이터가 이용가능하다고 결정하기 위한 수단을 포함하는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 20항에 있어서,
상기 UA는 중복 인코딩 컨텐츠 데이터를 활용하기 위한 로직을 포함하지 않는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 37항에 있어서,
상기 중복 인코딩 컨텐츠 데이터는 순방향 에러 정정(FEC) 인코딩 데이터를 포함하는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
클라이언트 디바이스의 전달 가속기(TA)에 의해서 상기 클라이언트 디바이스의 사용자 에이전트(UA)로 컨텐츠의 전달을 가속시키기 위한 컴퓨터 판독가능 저장 매체로서,
상기 컴퓨터 판독가능 저장 매체에는 프로그램 코드가 레코딩되고, 상기 프로그램 코드는:
상기 TA의 요청 관리자(RM)에 의해서, 컨텐츠 서버에 컨텐츠를 요청하기 위해 상기 UA에 의해 제공되는 프래그먼트 요청들을 수신하기 위한 프로그램 코드;
상기 프래그먼트 요청들 중 한 프래그먼트 요청에 대응하는 프래그먼트의 컨텐츠를 복원하는데 있어 상기 RM에 의해 사용하기 위한 상기 프래그먼트 요청을 요청하기 위해서 중복 인코딩 컨텐츠 데이터의 양을 결정하기 위한 프로그램 코드; 및
상기 RM에 의해서, 상기 중복 인코딩 컨텐츠 데이터의 양이 상기 프래그먼트 요청을 위해 요청될 때를 결정하기 위한 프로그램 코드를 포함하고,
상기 중복 인코딩 컨텐츠 데이터의 양이 요청될 때를 결정하기 위한 프로그램 코드는 미리 요청된 데이터를 늦는 것으로 상기 RM에 의해서 간주하기 위한 프로그램 코드를 포함하는, 컨텐츠의 전달을 가속시키기 위한 컴퓨터 판독가능 저장 매체.
제 39항에 있어서,
상기 RM에 의해서, 상기 프래그먼트 요청들 중 한 프래그먼트 요청에 기초하여 복수의 청크 요청들을 결정하기 위한 프로그램 코드를 더 포함하고,
상기 복수의 청크 요청들 중 적어도 하나의 청크 요청은 상기 프래그먼트 요청에 대응하는 프래그먼트의 일부에 대한 요청을 포함하며,
상기 복수의 청크 요청들 중 적어도 다른 하나의 청크 요청은 상기 프래그먼트 요청에 대응하는 프래그먼트와 연관된 중복 인코딩 컨텐츠 프래그먼트의 일부에 대한 요청을 포함하는, 컨텐츠의 전달을 가속시키기 위한 컴퓨터 판독가능 저장 매체.
제 40항에 있어서,
프래그먼트를 요청하기 위한 상기 중복 인코딩 컨텐츠 데이터의 양은 상기 프래그먼트에 대한 청크들의 수신 동안 상기 프래그먼트에 대한 동시적으로 늦는 데이터의 최대 양에 기초하고,
청크 내의 제 1 데이터는, 만약 상기 제 1 데이터가 상기 RM에 의해서 요청되었지만 아직 수신되지 않았고 적어도 일부 제 2 데이터가 상기 제 1 데이터 이후에 요청되어 수신되었다면, 특정 시점에 늦는 것으로서 분류되는, 컨텐츠의 전달을 가속시키기 위한 컴퓨터 판독가능 저장 매체.
제 39항에 있어서,
상기 프래그먼트를 요청하기 위해서 중복 인코딩 컨텐츠 데이터의 양을 결정하기 위한 프로그램 코드는 상기 프래그먼트에 대한 미리 요청된 데이터를 충분히 빠르게 수신하지 못하는 것에 기초하여 상기 프래그먼트에 대해 요청될 추가적인 중복 인코딩 컨텐츠 데이터를 결정하기 위한 프로그램 코드를 포함하고,
비록 상기 미리 요청된 데이터가 도달할 경우 상기 미리 요청된 데이터의 양이 상기 RM이 상기 프래그먼트를 완전히 복원하기에 충분할지라도 그리고 비록 상기 미리 요청된 데이터 모두가 상기 RM에 의해 수신될지라도, 상기 추가적인 중복 인코딩 컨텐츠 데이터는 요청되도록 결정되는, 컨텐츠의 전달을 가속시키기 위한 컴퓨터 판독가능 저장 매체.
제 39항에 있어서,
상기 중복 인코딩 컨텐츠 데이터의 양을 결정하기 위한 프로그램 코드에 의해 프래그먼트 요청을 요청하기 위해서 중복 인코딩 컨텐츠 데이터의 양의 결정하는 것은 현재 네트워크 조건들에 적어도 부분적으로 기초하는, 컨텐츠의 전달을 가속시키기 위한 컴퓨터 판독가능 저장 매체.
제 39항에 있어서,
상기 RM에 의해서, 복수의 프래그먼트 요청들 각각과 연관하여 요청할 중복 인코딩 컨텐츠 데이터의 양을 동적으로 조정하기 위한 프로그램 코드를 더 포함하는, 컨텐츠의 전달을 가속시키기 위한 컴퓨터 판독가능 저장 매체.
제 39항에 있어서,
상기 RM에 의해서, 상기 UA에 의해 제공된 프래그먼트 요청들 중 임의의 특정 프래그먼트 요청과 연관하여 중복 인코딩 컨텐츠 데이터가 요청될지 여부를 결정하기 위한 프로그램 코드를 더 포함하는, 컨텐츠의 전달을 가속시키기 위한 컴퓨터 판독가능 저장 매체.
클라이언트 디바이스의 전달 가속기(TA)에 의해서 상기 클라이언트 디바이스의 사용자 에이전트(UA)로 컨텐츠의 전달을 가속시키도록 구성되는 장치로서, 상기 장치는,
적어도 하나의 프로세서; 및
상기 적어도 하나의 프로세서에 결합된 메모리를 포함하고, 상기 적어도 하나의 프로세서는:
상기 TA의 요청 관리자(RM)에 의해서, 컨텐츠 서버에 컨텐츠를 요청하기 위해 상기 UA에 의해 제공되는 프래그먼트 요청들을 수신하고;
상기 프래그먼트 요청들 중 한 프래그먼트 요청에 대응하는 프래그먼트의 컨텐츠를 복원하는데 있어 상기 RM에 의해 사용하기 위한 상기 프래그먼트 요청을 요청하기 위해서 중복 인코딩 컨텐츠 데이터의 양을 결정하며; 그리고
상기 RM에 의해서, 상기 중복 인코딩 컨텐츠 데이터의 양이 상기 프래그먼트 요청을 위해 요청될 때를 결정하도록 구성되고,
상기 중복 인코딩 컨텐츠 데이터의 양이 요청될 때를 결정하도록 구성되는 상기 적어도 하나의 프로세서는 미리 요청된 데이터를 늦는 것으로 상기 RM에 의해서 간주하도록 추가로 구성되는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 46항에 있어서,
상기 적어도 하나의 프로세서는 상기 프래그먼트 요청들 중 한 프래그먼트 요청에 기초하여 복수의 청크 요청들을 결정하도록 추가로 구성되고,
상기 복수의 청크 요청들 중 적어도 하나의 청크 요청은 상기 프래그먼트 요청에 대응하는 프래그먼트의 일부에 대한 요청을 포함하고,
상기 복수의 청크 요청들 중 적어도 다른 하나의 청크 요청은 상기 프래그먼트 요청에 대응하는 프래그먼트와 연관된 중복 인코딩 컨텐츠 프래그먼트의 일부에 대한 요청을 포함하는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 47항에 있어서,
프래그먼트를 요청하기 위한 상기 중복 인코딩 컨텐츠 데이터의 양은 상기 프래그먼트에 대한 청크들의 수신 동안 상기 프래그먼트에 대한 동시적으로 늦는 데이터의 최대 양에 기초하고,
청크 내의 제 1 데이터는, 만약 상기 제 1 데이터가 상기 RM에 의해서 요청되었지만 아직 수신되지 않았고 적어도 일부 제 2 데이터가 상기 제 1 데이터 이후에 요청되어 수신되었다면, 특정 시점에 늦는 것으로서 분류되는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 46항에 있어서,
상기 프래그먼트를 요청하기 위해서 중복 인코딩 컨텐츠 데이터의 양을 결정하도록 구성되는 상기 적어도 하나의 프로세서는 상기 프래그먼트에 대한 미리 요청된 데이터를 충분히 빠르게 수신하지 못하는 것에 기초하여 상기 프래그먼트에 대해 요청될 추가적인 중복 인코딩 컨텐츠 데이터를 결정하도록 추가로 구성되고,
비록 상기 미리 요청된 데이터가 도달할 경우 상기 미리 요청된 데이터의 양이 상기 RM이 상기 프래그먼트를 완전히 복원하기에 충분할지라도 그리고 비록 상기 미리 요청된 데이터 모두가 상기 RM에 의해 수신될지라도, 상기 추가적인 중복 인코딩 컨텐츠 데이터는 요청되도록 결정되는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 46항에 있어서,
상기 적어도 하나의 프로세서에 의해 상기 프래그먼트 요청을 요청하기 위해서 중복 인코딩 컨텐츠 데이터의 양을 결정하는 것은 현재 네트워크 조건들에 적어도 부분적으로 기초하는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 46항에 있어서,
상기 적어도 하나의 프로세서는 상기 RM에 의해서, 복수의 프래그먼트 요청들 각각과 연관하여 요청할 중복 인코딩 컨텐츠 데이터의 양을 동적으로 조정하도록 추가로 구성되는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.
제 46항에 있어서,
상기 적어도 하나의 프로세서는 상기 RM에 의해서, 상기 UA에 의해 제공된 프래그먼트 요청들 중 임의의 특정 프래그먼트 요청과 연관하여 중복 인코딩 컨텐츠 데이터가 요청될지 여부를 결정하도록 추가로 구성되는, 컨텐츠의 전달을 가속시키도록 구성되는 장치.