KR101846382B1 - 전송 계층에서 요청 가속을 시그널링하기 위한 시스템들 및 방법들 - Google Patents

전송 계층에서 요청 가속을 시그널링하기 위한 시스템들 및 방법들 Download PDF

Info

Publication number
KR101846382B1
KR101846382B1 KR1020177008369A KR20177008369A KR101846382B1 KR 101846382 B1 KR101846382 B1 KR 101846382B1 KR 1020177008369 A KR1020177008369 A KR 1020177008369A KR 20177008369 A KR20177008369 A KR 20177008369A KR 101846382 B1 KR101846382 B1 KR 101846382B1
Authority
KR
South Korea
Prior art keywords
content
request
acceleration
transport
requests
Prior art date
Application number
KR1020177008369A
Other languages
English (en)
Other versions
KR20170063635A (ko
Inventor
파티흐 울루피나르
푼야슬로크 푸카야스타
이니안 마오
데비프라사드 풋차라
로렌즈 크리스토프 민더
마이클 조지 루비
Original Assignee
퀄컴 인코포레이티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 퀄컴 인코포레이티드 filed Critical 퀄컴 인코포레이티드
Publication of KR20170063635A publication Critical patent/KR20170063635A/ko
Application granted granted Critical
Publication of KR101846382B1 publication Critical patent/KR101846382B1/ko

Links

Images

Classifications

    • H04L65/4084—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H04L67/322—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)

Abstract

사용자 에이전트(UA) 시그널링의 사용을 통해 전송 가속기 동작을 제공하도록 적응된 시스템들 및 방법들이 개시된다. 실시예들에 따른 동작에서, 전송 가속기(TA)는, 전송 가속 기능이 제공된다는 표시를 콘텐츠 요청이 포함하는지를 결정하기 위해 콘텐츠 요청을 분석한다. 그러한 표시가 존재하면, TA는 또한 전송 가속 기능이 제공될 것인지를 결정하기 위해 콘텐츠 요청을 분석한다.

Description

전송 계층에서 요청 가속을 시그널링하기 위한 시스템들 및 방법들{SYSTEMS AND METHODS FOR SIGNALING REQUEST ACCELERATION IN THE TRANSPORT LAYER}
관련 출원들에 대한 교차-참조
[0001] 본 출원은 2014년 9월 30일에 출원된 "SYSTEMS AND METHODS FOR USER AGENT SIGNALING REQUEST ACCELERATION BY TRANSPORT ACCELERATOR"란 명칭의 공동-계류중인 미국 가특허 출원 번호 제 62/057,412 호, 및 2015년 2월 6일에 출원된 "SYSTEMS AND METHODS FOR USER AGENT SIGNALING REQUEST ACCELERATION BY TRANSPORT ACCELERATOR"란 명칭의 미국 실용 특허 출원 제 14/616,233 호에 대한 우선권을 주장하고, 상기 출원들은 전체 내용이 인용에 의해 본원에 명백히 통합된다.
[0002] 점점 더 많은 콘텐츠가 이용가능한 통신 네트워크들을 통해 전달되고 있다. 흔히, 이러한 콘텐츠는, 예를 들어, 오디오 데이터, 비디오 데이터, 이미지 데이터 등을 포함하는, 다양한 타입들의 데이터를 포함한다. 비디오 콘텐츠, 특히 고해상도 비디오 콘텐츠는 흔히 상대적으로 큰 데이터 파일 또는 데이터의 다른 콜렉션을 포함한다. 따라서, 이러한 콘텐츠를 소비하고 있는 최종 사용자 디바이스 상의 사용자 에이전트(UA) 또는 다른 클라이언트 디바이스는 흔히 원하는 비디오 콘텐츠를 포함하는 콘텐츠의 프래그먼트들의 시퀀스를 요청 및 수신한다. 예를 들어, UA는, 데이터, 흔히 멀티미디어 데이터를 요청하고, 추가의 프로세싱 및 가능하게는 사용자 디바이스 상의 디스플레이를 위해 요청된 데이터를 수신하는 사용자 디바이스 상에서 실행하는 프로세스 또는 클라이언트 애플리케이션을 포함할 수 있다.
[0003] 많은 타입들의 애플리케이션들이 오늘날 전술한 콘텐츠 전달을 위해 HTTP에 의존한다. 많은 이러한 애플리케이션들에서, HTTP 전송의 성능은 애플리케이션에 대한 사용자의 경험에 중요하다. 예를 들어, 라이브 스트리밍은 비디오 스트리밍 클라이언트의 성능을 저해할 수 있는 몇몇 제한들을 갖는다. 두 제한들이 특히 두드러진다. 첫 번째, 미디어 세그먼트들은 시간이 지남에 따라 차례로 이용가능하게 된다. 이러한 제한은 클라이언트가 데이터의 큰 부분을 연속적으로 다운로딩하는 것을 못하게 하며, 이는 차례로 다운로드 레이트 추정의 정확성에 영향을 미친다. 대부분의 스트리밍 클라이언트들이 "요청-다운로드-추정" 루프로 동작하기 때문에, 다운로드 추정이 부정확한 경우 콘텐츠 다운로드는 일반적으로 잘 잘 동작하지 않는다. 두 번째, 라이브 이벤트 스트리밍을 뷰잉 시, 사용자는 일반적으로 실제 라이브 이벤트 타임라인으로부터 긴 지연을 겪기를 원치 않는다. 이러한 거동은 스트리밍 클라이언트가 큰 버퍼를 구축하는 것을 못하게 하며, 이는 차례로 더 많은 재버퍼링을 유발할 수 있다.
[0004] 스트리밍 클라이언트가 (예를 들면, 대부분의 DASH(Dynamic Adaptive Streaming over HTTP) 클라이언트들이 하는 바와 같이) TCP(Transmission Control Protocol)를 통해 동작하면, 앞서 말한 엄격한 라이브 이벤트 타임라인은, 누락 또는 재정렬된 패킷이 존재할 때 둔화되는 전형적인 TCP 거동과 모순된다. 빌트-인 TCP 혼잡 제어 메커니즘은 라이브 스트리밍 동안에 재버퍼링 효과를 악화시키고, 반면에 라이브 이벤트에 대한 시청자들은 기꺼이 재버퍼링을 스킵하고 최종 이벤트 타임라인으로 점프할 가능성이 더 많다.
[0005] 동일한 이슈들이 또한 HTTP-기반 파일 다운로드에서 존재하고, 여기서 다운로드의 완료에 대한 데드라인이 존재하고, 그렇지 않다면 페널티가 발생된다. 예를 들면, 사용자가 웹 페이지, 사진을 액세스하거나 웹-기반 애플리케이션을 사용하려고 시도하면, 큰 다운로드 레이턴시는 사용자가 웹 페이지 또는 웹-기반 애플리케이션을 외면하게 할 수 있다.
[0006] 온-디맨드 스트리밍은 또한 유사한 제약들로 고통받는다. 예를 들면, 온-디맨드 스트리밍에서, 클라이언트 디바이스들은 재생을 사용자에게 제공하기 위한 올바른 순서로 가능한 한 빠르게 온-디맨드 스트림을 수신하고자 한다. 온-디맨드 콘텐츠를 스트리밍하는 것의 성능은 누락 및 재정렬된 패킷들, 재버퍼링 등에 의해 영향을 받는다.
[0007] 전송 가속기의 구현을 사용하여 콘텐츠의 전달에 관련하여 가속을 제공하기 위한 다양한 기술들이 개발되고 있다. 그러한 전송 가속기 구현들은, 예를 들면, 클라이언트 디바이스로의 데이터의 촉진된 전달을 가능하게 하기 위한 노력으로 데이터의 캐싱, 데이터 요청들의 프로세싱 및/또는 데이터 요청들에 대한 응답들 등을 제공하도록 동작할 수 있다. 일부 또는 심지어 많은 상황들에서 클라이언트 디바이스들로의 데이터의 촉진된 전달을 제공하지만, 그럼에도 불구하고 많은 전송 가속기 구현들은 일부 상황들에서 바람직하지 않은 동작을 발생시킨다. 예를 들면, 전송 가속기의 동작은 증가된 네트워크 혼잡, 통신 프로토콜들 또는 그의 부분들과의 호환 불가성들 등을 발생시킬 수 있다.
[0008] 전송 가속기는, 예를 들면, 다수의 애플리케이션들에 관련하여 전송 가속 동작을 가능하게 하기 위해 시스템 프레임워크(예를 들면, ANDROID 모바일 디바이스 운영 시스템에 의해 제공된 STAGEFRIGHT 미디어 플레이어 아키텍처)에서 구현될 수 있다. 예를 들면, 운영 시스템(OS)은 시스템 프레임워크를 제공할 수 있고, 이로써 가령, API(application programming interface)의 사용을 통해 애플리케이션들에 의한 사용을 위해 HTTP 계층 트랜잭션들, 네트워크 계층 트랜잭션들, 미디어 재생 엔진 등과 같은 특정 하위 레벨 기능들이 제공된다. OS 상에서 동작하는 잠재적으로 많은 수의 애플리케이션들에 대해 공통으로 이용 가능한 그러한 프레임워크는 마찬가지로 전송 가속기의 요청 및 데이터 전달 가속과 같은 기능을 프레임워크 서비스들 자체에 도움이 되는 애플리케이션들에 대해 마찬가지로 이용 가능하게 만들도록 레버리지될 수 있다.
[0009] 그러나, 일부 애플리케이션들은 그러한 시스템 프레임워크의 기능을 사용할 수 없다. 예를 들면, 특정 애플리케이션들은 애플리케이션들의 동작에 대한 그러한 기능들을 최적화하기 위해 HTTP 계층 트랜잭션들, 네트워크 트랜잭션들, 미디어 재생 등과 같은 그들 자신의 하위 레벨 기능들을 구현할 수 있다. 예를 들면, 상대적으로 높은 네트워크 영향 애플리케이션들(예를 들면, NETFLIX 및 YOUTUBE 클라이언트들)은 시스템 제공 프레임워크(예를 들면, STAGEFRIGHT)의 사용에 선행하고, 대신에 그들 자신의 하위 레벨 기능을 구현할 수 있다. 따라서, 더 복잡한 애플리케이션 소프트웨어 구성을 요구하지만, 그럼에도 불구하고 그러한 애플리케이션들은 특정 애플리케이션에 의한 사용을 위해 특별히 적응된 하위 레벨 기능의 사용을 통해 개선된 또는 훨씬 더 예측가능한 성능으로부터 이득을 얻을 수 있다.
[0010] 본원의 실시예들에 따라, 전송 가속 요청 통신(transport acceleration request communication)을 위한 방법이 제공된다. 상기 방법은, 전송 가속기(TA)에 의해, 제 1 사용자 에이전트(UA)로부터 TA의 제 1 요청 가속 포트를 통해 콘텐츠 요청을 수신하는 단계를 포함하고, 콘텐츠 요청은 콘텐츠 데이터가 콘텐츠 서버에 의해 UA에 전달되기 위한 요청을 포함한다. 상기 방법은 전송 가속 기능이 콘텐츠 요청에 관련하여 제공된다는 것을 표시하는 시그널링을 콘텐츠 요청이 포함하는지를 결정하기 위해 콘텐츠 요청을 분석하는 단계 및 전송 가속 기능이 제공된다는 것을 표시하는 시그널링을 콘텐츠 요청이 포함한다는 결정에 적어도 부분적으로 기초하여, 콘텐츠 요청에 관련하여 콘텐츠 데이터를 요청하기 위한 전송 가속 동작을 수행하는 단계를 더 포함하고, 전송 가속 동작은 콘텐츠 요청을 콘텐츠에 대한 복수의 요청들로 세분화하는 것, 및 요청된 콘텐츠 데이터의 TA로의 가속화된 전달을 제공하기 위해 TA에 의해 콘텐츠 서버로부터 콘텐츠를 요청하는 것을 제어하는 것을 포함한다.
[0011] 본원의 추가의 실시예들에 따라, 전송 가속 요청 통신을 위한 장치가 제공된다. 상기 장치는, 전송 가속기(TA)가 제 1 사용자 에이전트(UA)로부터 TA의 제 1 요청 가속 포트를 통해 콘텐츠 요청을 수신하기 위한 수단을 포함하고, 콘텐츠 요청은 콘텐츠 데이터가 콘텐츠 서버에 의해 UA에 전달되기 위한 요청을 포함한다. 상기 장치는 전송 가속 기능이 콘텐츠 요청에 관련하여 제공된다는 것을 표시하는 시그널링을 콘텐츠 요청이 포함하는지를 결정하기 위해 콘텐츠 요청을 분석하기 위한 수단 및 전송 가속 기능이 제공된다는 것을 표시하는 시그널링을 콘텐츠 요청이 포함한다는 결정에 적어도 부분적으로 기초하여, 콘텐츠 요청에 관련하여 콘텐츠 데이터를 요청하기 위한 전송 가속 동작을 수행하기 위한 수단을 더 포함하고, 전송 가속 동작은 콘텐츠 요청을 콘텐츠에 대한 복수의 요청들로 세분화하는 것, 및 요청된 콘텐츠 데이터의 TA로의 가속화된 전달을 제공하기 위해 TA에 의해 콘텐츠 서버로부터 콘텐츠를 요청하는 것을 제어하는 것을 포함한다.
[0012] 또 다른 본원의 실시예들에 따라, 전송 가속 요청 통신을 위한 컴퓨터 실행 가능 코드를 저장하는 컴퓨터 판독 가능 매체가 제공되고, 컴퓨터 판독 가능 매체는 프로그램 코드가 기록된 유형의 컴퓨터-판독 가능 매체를 포함한다. 프로그램 코드는, 전송 가속기(TA)에 의해, 제 1 사용자 에이전트(UA)로부터 TA의 제 1 요청 가속 포트를 통해 콘텐츠 요청을 수신하기 위한 프로그램 코드를 포함하고, 콘텐츠 요청은 콘텐츠 데이터가 콘텐츠 서버에 의해 UA에 전달되기 위한 요청을 포함한다. 프로그램 코드는 전송 가속 기능이 콘텐츠 요청에 관련하여 제공된다는 것을 표시하는 시그널링을 콘텐츠 요청이 포함하는지를 결정하기 위해 콘텐츠 요청을 분석하기 위한 프로그램 코드 및 전송 가속 기능이 제공된다는 것을 표시하는 시그널링을 콘텐츠 요청이 포함한다는 결정에 적어도 부분적으로 기초하여, 콘텐츠 요청에 관련하여 콘텐츠 데이터를 요청하기 위한 전송 가속 동작을 수행하기 위한 프로그램 코드를 더 포함하고, 전송 가속 동작은 콘텐츠 요청을 콘텐츠에 대한 복수의 요청들로 세분화하는 것, 및 요청된 콘텐츠 데이터의 TA로의 가속화된 전달을 제공하기 위해 TA에 의해 콘텐츠 서버로부터 콘텐츠를 요청하는 것을 제어하는 것을 포함한다.
[0013] 본원의 추가의 실시예들에 따라, 전송 가속 요청 통신을 위한 장치가 제공된다. 상기 장치는 적어도 하나의 프로세서, 및 상기 적어도 하나의 프로세서에 커플링된 메모리를 포함한다. 적어도 하나의 프로세서는, 전송 가속기(TA)에 의해, 제 1 사용자 에이전트(UA)로부터 TA의 제 1 요청 가속 포트를 통해 콘텐츠 요청을 수신하도록 구성되고, 콘텐츠 요청은 콘텐츠 데이터가 콘텐츠 서버에 의해 UA에 전달되기 위한 요청을 포함한다. 적어도 하나의 프로세서는 전송 가속 기능이 콘텐츠 요청에 관련하여 제공된다는 것을 표시하는 시그널링을 콘텐츠 요청이 포함하는지를 결정하기 위해 콘텐츠 요청을 분석하고, 전송 가속 기능이 제공된다는 것을 표시하는 시그널링을 콘텐츠 요청이 포함한다는 결정에 적어도 부분적으로 기초하여, 콘텐츠 요청에 관련하여 콘텐츠 데이터를 요청하기 위한 전송 가속 동작을 수행하도록 추가로 구성되고, 전송 가속 동작은 콘텐츠 요청을 콘텐츠에 대한 복수의 요청들로 세분화하는 것, 및 요청된 콘텐츠 데이터의 TA로의 가속화된 전달을 제공하기 위해 TA에 의해 콘텐츠 서버로부터 콘텐츠를 요청하는 것을 제어하는 것을 포함한다.
[0014] 도 1은 본 개시의 실시예들에 따른 전송 가속기 동작을 위해 적응된 시스템을 도시한다.
[0015] 도 2a는 본 개시의 실시예에 따른 전송 가속기 동작을 제공하기 위한 전송 가속기 제어 로직의 동작을 예시한 고레벨 흐름도를 도시한다.
[0016] 도 2b는 본 개시의 실시예에 따른 전송 가속기 로직의 기능을 선택적으로 인보크하기 위한 동작을 예시한 고레벨 흐름도를 도시한다.
[0017] 용어 “예시적인”은, 오직 “예, 예증 또는 예시로서 기능하는” 것을 의미하도록 본 명세서에서 사용된다. 본 명세서에서 “예시적인” 것으로 설명되는 임의의 양상은 반드시 다른 양상들에 비해 선호되거나 유리한 것으로 해석될 필요는 없다.
[0018] 이 설명에서, 용어 "애플리케이션"은 또한, 실행가능한 콘텐츠, 예컨대: 객체 코드, 스크립트, 바이트 코드, 마크업 언어 파일들, 및 패치들을 갖는 파일들을 포함할 수 있다. 게다가, 본 명세서에 언급되는 "애플리케이션"은 또한, 특성상 실행가능하지 않은 파일들, 예컨대, 오픈될 필요가 있는 문서들 또는 액세스될 필요가 있는 다른 데이터 파일들을 포함할 수 있다.
[0019] 본 명세서에 사용되듯이, 용어 "콘텐츠"는 비디오, 오디오, 비디오와 오디오의 결합들, 또는 하나 이상의 품질 레벨들에 있는 다른 데이터, 비트 레이트, 해상도 또는 다른 팩터에 의해 결정되는 품질 레벨을 갖는 데이터를 포함할 수 있다. 콘텐츠는 또한 실행기능한 콘텐츠, 예컨대: 객체 코드, 스크립트들, 바이트 코드, 마크업 언어 파일들, 및 패치들을 포함할 수 있다. 게다가, "콘텐츠"는 또한, 특성상 실행가능하지 않은 파일들, 예컨대, 오픈될 필요가 있는 문서들 또는 액세스될 필요가 있는 다른 데이터 파일들을 포함할 수 있다.
[0020] 본 설명에서 사용되는 바와 같이, 용어 "프래그먼트"는 사용자 디바이스에 의해 요청되고 그리고/또는 수신될 수 있는 콘텐츠의 하나 이상의 부분들을 지칭한다.
[0021] 본 설명에서 사용되는 바와 같이, 용어 "스트리밍 콘텐츠"는 시간 기간 동안 콘텐츠의 전달 또는 콘텐츠의 실시간 전달을 가능하게 하는 하나 이상의 표준들에 따라 서버 디바이스로부터 전송되고 사용자 디바이스에서 수신될 수 있는 콘텐츠를 지칭한다. 스트리밍 콘텐츠 표준들의 예들은, 디인터리빙된(또는 다수의) 채널들을 지원하는 표준들 및 디인터리빙된 (또는 다수의) 채널들을 지원하지 않는 표준들을 포함한다.
[0022] 본 명세서에 사용되는 바와 같이, 용어 "컴포넌트", "데이터베이스", "모듈", "시스템" 등은 컴퓨터 관련 엔티티, 하드웨어, 펌웨어, 하드웨어 및 소프트웨어의 결합이나 실행중인 소프트웨어 중 어느 하나를 지칭하도록 의도된다. 예를 들어, 컴포넌트는, 프로세서 상에서 구동하는 프로세스, 프로세서, 객체, 실행가능한 것, 실행의 스레드, 프로그램 및/또는 컴퓨터일 수 있지만, 이에 한정되지는 않는다. 예시로서, 컴퓨팅 디바이스 상에서 구동하는 애플리케이션 및 컴퓨팅 디바이스 둘 모두는 컴포넌트일 수 있다. 하나 이상의 컴포넌트들이 프로세스 및/또는 실행의 스레드 내에 상주할 수 있고, 컴포넌트는 하나의 컴퓨터 상에 로컬화될 수 있고 그리고/또는 둘 이상의 컴퓨터들 사이에서 분포될 수 있다. 게다가, 이러한 컴포넌트들은 다양한 데이터 구조들이 저장되어 있는 다양한 컴퓨터 판독 가능 매체로부터 실행될 수 있다. 컴포넌트들은 예컨대 하나 이상의 데이터 패킷들(예를 들면, 로컬 시스템에서, 분산 시스템에서 및/또는 신호에 의한 다른 시스템들과의 네트워크(예를 들어, 인터넷)를 통해 다른 컴포넌트와 상호 작용하는 하나의 컴포넌트로부터의 데이터)을 갖는 신호에 따라 로컬 및/또는 원격 프로세스들을 통해 통신할 수 있다.
[0023] 본 명세서에 사용되듯이, 용어 "사용자 설비", "사용자 디바이스" 및 "클라이언트 디바이스"는 웹 서버로부터의 콘텐츠를 요청하여 이를 수신하고 정보를 웹 서버에 송신할 수 있는 디바이스들을 포함한다. 이러한 디바이스들은 정적 디바이스들 또는 모바일 디바이스들일 수 있다. 용어 "사용자 장비", "사용자 디바이스" 및 "클라이언트 디바이스"는 상호 교환가능하게 사용될 수 있다.
[0024] 본 명세서에 사용되듯이, 용어 "사용자"는 사용자 디바이스 상에서 또는 클라이언트 디바이스 상에서 콘텐츠를 수신하고 정보를 웹사이트에 송신하는 개인을 지칭한다.
[0025] 도 1은 통신 네트워크를 통해, 예컨대, 오디오 데이터, 비디오 데이터, 이미지 데이터, 파일 데이터 등을 포함할 수 있는 콘텐츠의 전달을 제공하기 위해 본 명세서의 개념들에 따라 적응되는 시스템(100)의 실시예를 도시한다. 따라서, 클라이언트 디바이스(110)는 네트워크(150)를 통해 서버(130)와 통신 상태에 있는 것으로 도시되며, 그로 인해, 서버(130)는 본 개시의 개념들에 따라, 데이터베이스(140)에 저장된 다양한 콘텐츠를 클라이언트 디바이스(110)로 전달할 수 있다. 단일의 클라이언트 디바이스 및 단일의 서버 및 데이터베이스만이 도 1에 제시되었지만, 시스템(100)은 복수의, 임의의 또는 모든 이러한 디바이스들을 포함할 수 있다는 것이 인지되어야 한다. 예를 들어, 서버(130)는, 콘텐츠 전달을 위한 고레벨의 요구를 서빙하기 위해, 서버 팜의 서버를 포함할 수 있고, 여기서, 복수의 서버들이 중앙에 그리고/또는 분포된 구성으로 배치될 수 있다. 대안적으로, 서버(130)는 예컨대, 콘텐츠의 일부 또는 전부가 디바이스 상에 또한 콜로케이트되고 서버(130)를 통해 (예를 들어, 네트워크(150)를 통하는 대신 I/O 엘리먼트(113)를 통해 직접 전송 가속기(TA)(120)에 연결되는) TA(120)로 제공되는 데이터베이스(140)(캐시)에 상주할 경우, TA(120)와 동일한 디바이스 상에 콜로케이트될 수 있다. 마찬가지로, 사용자들은 복수의 클라이언트 디바이스들을 소유할 수 있고 그리고/또는 복수의 사용자들 각각은, 하나 이상의 클라이언트 디바이스들을 소유할 수 있고, 이들 중 임의의 것 또는 전부는 본 명세서의 개념들에 따른 콘텐츠 전달을 위해 적응된다.
[0026] 클라이언트 디바이스(110)는 네트워크(150)를 통해 콘텐츠의 전달을 수신하도록 동작가능한 디바이스들의 다양한 구성들을 포함할 수 있다. 예를 들어, 클라이언트 디바이스(110)는 유선 디바이스, 무선 디바이스, 개인 컴퓨팅 디바이스, 태블릿 또는 패드 컴퓨팅 디바이스, 포터블 셀룰러 전화, WiFi 가능 디바이스, 블루투스 가능 디바이스, 텔레비전, 디스플레이를 가진 한 쌍의 안경, 한 쌍의 증강 현실 안경 또는 임의의 이용가능한 방법 또는 인프라구조를 사용하여 서버(130)와 통신할 수 있는 네트워크(150)에 연결되는 임의의 다른 통신, 컴퓨팅 또는 인터페이스 디바이스를 포함할 수 있다. 클라이언트 디바이스(110)는 "클라이언트 디바이스"로 지칭되는데, 그 이유는 클라이언트 디바이스가 서버(130)의 클라이언트로 기능하는 디바이스로서 기능하거나 이에 연결될 수 있기 때문이다.
[0027] 예시된 실시예의 클라이언트 디바이스(110)는, 프로세서(111), 메모리(112) 및 입력/출력(I/O) 엘리먼트(113)를 포함하는 것으로 본 명세서에 도시된, 복수의 기능 블록들을 포함한다. 간략화를 위해 도 1의 묘사에 도시되지는 않았지만, 클라이언트 디바이스(110)는 추가의 기능 블록들, 예컨대, 사용자 인터페이스, 라디오 주파수(RF) 모듈, 카메라, 센서 어레이, 디스플레이, 비디오 플레이어, 브라우저 등을 포함할 수 있으며, 이들 중 일부 또는 전부는 본 명세서의 개념들에 따른 동작을 위해 사용될 수 있다. 전술한 기능 블록들은 하나 이상의 버스들(예컨대, 버스(114))을 통해 동작가능하게 연결될 수 있다. 버스(114)는 연결된 엘리먼트들, 모듈들 및 컴포넌트들이 통신하고 상호동작하도록 허용하기 위한 논리적 그리고 물리적 연결들을 포함할 수 있다.
[0028] 실시예들의 메모리(112)는 임의의 타입의 휘발성 또는 비휘발성 메모리이며, 일 실시예에서 플래시 메모리를 포함할 수 있다. 메모리(112)는 클라이언트 디바이스(110)에 영구적으로 설치될 수 있거나 탈착식 메모리 엘리먼트, 예컨대 탈착식 메모리 카드일 수 있다. 단일 엘리먼트로 도시되었지만, 메모리(112)는 다수의 개별 메모리들 및/또는 메모리 타입들을 포함할 수 있다.
[0029] 메모리(112)는, 예컨대 애플리케이션들, 운영체제, 파일들, 전자 문서들, 콘텐츠 등을 형성할 수 있는 다양한 컴퓨터 판독가능 코드 세그먼트들을 저장 또는 다른 방식으로 포함할 수 있다. 예를 들어, 예시된 실시예들의 메모리(112)는, 프로세서(예를 들면, 프로세서(111))에 의해 실행될 때 본 명세서에 설명된 대로 동작가능한 논리 회로들을 제공하는, TA(120), 전송 가속기(TA) 제어(125), 및 UA들(129a 및 129b)을 한정하는 컴퓨터 판독가능 코드 세그먼트들을 포함한다. 메모리(112)에 의해 저장되는 코드 세그먼트는 전술한 TA(120), TA 제어(125) 및 UA들(129a 및 129b) 외에도 애플리케이션들을 제공할 수 있다. 예를 들어, 메모리(112)는 본 명세서의 실시예들에 따라 서버(130)로부터의 콘텐츠를 액세싱하는데 유용한 브라우저와 같은 애플리케이션들을 저장할 수 있다. 이러한 브라우저는 웹 브라우저, 예컨대, 웹 콘텐츠를 액세스하고 뷰잉하기 위해 그리고 서버(130)가 웹 서버라면, 연결들(151 및 152)을 통해 네트워크(150)를 거쳐 서버(130)와 HTTP(hypertext transfer protocol)를 통해 통신하기 위한 HTTP 웹 브라우저일 수 있다. 예로서, HTTP 요청은 클라이언트 디바이스(110)의 브라우저로부터, 연결들(151 및 152)을 통해 네트워크(150)를 거쳐 서버(130)로 전송될 수 있다. HTTP 응답은 서버(130)로부터, 연결들(151 및 152)을 통해 네트워크(150)를 거쳐 클라이언트 디바이스(110)의 브라우저로 전송될 수 있다.
[0030] UA들(129a 및 129b)은 서버, 예컨대 서버(130)로부터 콘텐츠를 요청 및/또는 수신하도록 동작가능하다. UA들(129a 및 129b) 중 어느 하나 또는 둘 모두는, 데이터, 예컨대, 멀티미디어 데이터를 요청하고 추가의 프로세싱을 위해 그리고 가능하게는 클라이언트 디바이스(110)의 디스플레이 상에 디스플레이하기 위해 요청된 데이터를 수신하는, 예를 들어, 클라이언트 애플리케이션 또는 프로세스, 예컨대, 브라우저, DASH 클라이언트, HTTP 라이브 스트리밍(HLS) 클라이언트 등을 포함할 수 있다. 예를 들어, 클라이언트 디바이스(110)는, 인터넷 브라우저에서 구동하도록 구성되는 독립형 미디어 재생 애플리케이션 또는 브라우저 기반 미디어 플레이어와 같이, 미디어를 재생하기 위한 UA들(129a 또는 129b) 중 어느 하나를 포함하는 코드를 실행할 수 있다. 실시예들에 따른 동작에서, UA들(129a 및 129b)은 어느 콘텐츠 파일의 프래그먼트들의 시퀀스들 또는 프래그먼트들을 스트리밍 콘텐츠 세션 동안 다양한 시점에서 전달을 위해 요청할지를 결정한다. 예를 들어, UA의 DASH 클라이언트 구성은, 각 시점에서, 예컨대, 최근 다운로드된 조건들에 기초하여, 콘텐츠의 어느 표현(예를 들어, 고해상도 표현, 중간 해상도 표현, 저해상도 표현 등)으로부터 어느 프래그먼트를 요청할지를 결정하도록 동작할 수 있다. 마찬가지로, UA의 웹 브라우저 구성은 웹 페이지들 또는 이들의 일부 등에 대해 요청하도록 동작할 수 있다. 전형적으로, UA는 HTTP 요청들을 사용하여 이러한 프래그먼트들을 요청한다.
[0031] UA들의 2 개의 인스턴스들이 도 1에 예시된 클라이언트 디바이스(110)의 실시예에 관련하여 도시되지만, 시스템(100)의 클라이언트 디바이스들은 임의의 수의 UA들을 포함할 수 있다는 것이 인지되어야 한다. 예를 들면, 특정 클라이언트 디바이스 구성은 단일 UA를 포함할 수 있고, 반면에 다른 클라이언트 디바이스 구성은 복수의 UA들(즉, 2 개 이상)을 포함할 수 있다.
[0032] TA(120)는 본원의 개념들에 따라, (예를 들어, 비디오 스트리밍, 파일 다운로드, 웹 기반 애플리케이션들, 일반 웹 페이지 등을 제공하는데 사용될 수 있는 전술한 콘텐츠 프래그먼트들인) 원하는 콘텐츠의 프래그먼트들의 시퀀스들 또는 프래그먼트들의 향상된 전달을 제공하도록 적응된다. 예를 들면, TA(120)는 클라이언트 디바이스(110)로의 콘텐츠의 가속화된 전달을 제공하기 위해 UA들(129a 및 129b)에 의해 이루어진 콘텐츠에 대한 요청들을 서버(130)로부터 콘텐츠의 청크들을 제어가능하게 요청하기 위한 복수의 청크 요청들로 세분화하도록 동작할 수 있다. 실시예들의 TA(120)는, 표준 인터페이스, 예컨대, HTTP 1.1 인터페이스 구현 표준화된 TCP 전송 프로토콜들을 오직 지원하는 범용 또는 레거시 UA(즉 TA와 상호작용하도록 사전 설계되지 않은 UA)가 프래그먼트 요청들을 수행하는 것을 허용하도록 적응되어 이러한 요청들을 실행하는 TA를 사용하는 것으로부터 역시 유익하게 한다. 부가적으로 또는 대안적으로, 실시예들의 TA(120)는 향상된 인터페이스의 기능을 이용하도록 설계된 UA들에 추가의 이익들을 제공하는 것을 용이하게 하기 위해 향상된 인터페이스를 제공한다. 실시예들의 TA(120)는 기존 콘텐츠 전달 프로토콜들에 따라, 예컨대, 표준화된 TCP 전송 프로토콜들을 구현하는 HTTP 인터페이스를 통해 TCP를 사용하여 프래그먼트 요청을 실행하도록 적응되며, 그로 인해, 일반 또는 레거시 콘텐츠 서버(즉, TA와 상호작용하도록 사전 설계되지 않은 콘텐츠 서버)가, UA 및 클라이언트 디바이스로 프래그먼트들의 향상된 전달을 제공하면서, 요청들을 서빙하게 한다.
[0033] 전술한 강화된 프래그먼트 전달 기능을 제공하는데 있어서, 본원의 실시예들의 TA(120)는 본 명세서에 설명되듯이 아키텍처 컴포넌트들 및 프로토콜들을 포함한다. 예를 들면, 도 1에 예시된 실시예의 TA(120)는, 다양한 향상된 프래그먼트 전달 기능을 제공하도록 협력하는 요청 관리기(RM)(121) 및 하나 이상의 연결 관리기들(CM)(122)을 포함한다. RM(121)은 UA들(129a 및 129b)로부터 프래그먼트 요청들을 수신하고 이에 응답하고, 복수의 대응하는 더 작은 데이터 요청들(본원에서 "청크 요청들"로 지칭됨, 여기서 요청된 데이터는 "청크"를 포함함)을 제공하기 위해 요청된 프래그먼트들을 세분화하고, 청크 요청들을 CM(122)으로 지향시키도록 동작할 수 있다. 따라서, CM(122)은 청크 요청들을 수신하고, 그러한 청크 요청들에 대응하는 요청들(예를 들면, HTTP 요청들)을 네트워크(150)를 통해 전송하고, 그들의 청크 요청들에 대한 응답들을 수신하고, 응답들을 다시 RM(121)으로 전달하기 위해 RM(121)과 인터페이스할 수 있고, 여기서 UA들에 의해 요청된 프래그먼트들은 RM(121)에 의해 수신된 청크들로부터 분석되고, 요청하는 UA에 제공된다. 실시예들의 CM(122)의 기능은 RM(121)에 의해 이루어진 청크 요청들의 데이터를 요청할 때를 결정하도록 동작한다.
[0034] 예시된 실시예의 클라이언트 디바이스(110)가, 가령, 하나 이상의 통신 세션들, 통신 세션들에 관련하여 통신 포트 회복 등에 대한 동시의 다중-포트 통신 지원을 제공하는데 활용될 수 있는 다중 인터페이스 아키텍처를 구현하는 것으로 도시되는 것이 인지되어야 한다. 특히, TA(120)는 CM들(122a-122d)을 포함하는 것으로 도시된다. 대응하여, I/O 엘리먼트(113)는 데이터 통신을 가능하게 하도록 동작 가능한 복수의 인터페이스들(인터페이스들(161a-161d)로 도시됨)을 포함하는 것으로 도시된다. RM(121)은 마찬가지로 복수의 상이한 CM구성들과의 동작을 위해 또는 하나보다 더 많은 CM과 동시에 인터페이스하기 위해, 가령, CM들(122a-122d) 중 2 개 이상의 CM들로부터 동일한 프래그먼트 또는 프래그먼트들의 시퀀스의 데이터 청크들을 요청하기 위해 적응될 수 있다. 각각의 그러한 CM은, 예를 들면, 상이한 네트워크 인터페이스를 지원할 수 있다(예를 들면, 제 1 CM은 온-디바이스 캐시에 대한 로컬 인터페이스를 가질 수 있고, 제 2 CM은 3G 네트워크 인터페이스에 대한 HTTP/TCP 연결들을 사용할 수 있고, 제 3 CM은 4G/LTE 네트워크 인터페이스에 대한 HTTP/TCP 연결들을 사용할 수 있고, 제 4 CM은 WiFi 네트워크 인터페이스에 대한 HTTP/TCP 연결들을 사용할 수 있고, 기타 등등임). 대응하여, I/O 엘리먼트(113)의 인터페이스들은 다수의 통신 프로토콜들에 따라 동작 가능한 다양한 구성들을 포함할 수 있다. 예를 들면, 인터페이스들(161a-161d)은 3G 네트워크, 4G/LTE 네트워크, 상이한 4G/LTE 네트워크 및 WiFi 통신들 각각에 대한 인터페이스를 제공할 수 있고, 여기서 TA(120)는, 예를 들면, 이들 인터페이스들을 통해 데이터를 송신하기 위해 HTTP/TCP, HTTP/xTCP와 같은 전송 프로토콜, 또는 UDP(User Datagram Protocol)을 사용하여 구축된 프로토콜을 사용한다. 가령, 각각의 그러한 인터페이스는 I/O 엘리먼트(113)의 인터페이스들과 네트워크(150)의 컴포넌트들을 링킹하는 것으로 도시된 연결들(151a-151d)과 같은 연관된 통신 링크를 통해 통신 세션들을 구현하기 위한 하나 이상의 통신 포트들을 제공하도록 동작 가능할 수 있다.
[0035] 본원의 실시예들에 따라 활용되는 인터페이스들의 수 및 구성이 도시된 것으로 제한되지 않는다는 것이 인지되어야 한다. 더 적거나 더 많은 인터페이스들은, 예를 들면, 전송 가속기의 실시예들에 따라 활용될 수 있다. 또한, 하나 이상의 그러한 인터페이스들은 도시된 네트워크 링크들(예를 들면, 연결들(151a-151d)) 이외의 것을 통해 그리고/또는 네트워크 컴포넌트들(예를 들면, 서버(130)) 이외의 디바이스들과의 데이터 통신을 제공할 수 있다.
[0036] 애플리케이션들, 운영 체제, 파일들, 전자 문서들, 콘텐츠 등을 형성하는 전술한 코드 세그먼트들에 부가하여, 메모리(112)는 클라이언트 디바이스(110)의 기능 블록에 의해 사용되는 다양한 레지스터들, 버퍼들, 및 저장소 셀들을 포함하거나 그렇지 않으면 제공할 수 있다. 예를 들어, 메모리(112)는 예컨대, 클라이언트 디바이스(110)에 의한 재생 및 서버(130)로부터의 스트리밍을 위한 프래그먼트들의 데이터를 스풀링하기 위해 선입선출(FIFO) 메모리를 제공할 수 있는 플레이-아웃 버퍼를 포함할 수 있다.
[0037] 실시예들의 프로세서(111)는 클라이언트 디바이스(110)의 기능 및 동작을 제어하기 위해 명령들을 실행할 수 있는 임의의 범용 또는 특수 목적 프로세서일 수 있다. 단일 엘리먼트로 도시되었지만, 프로세서(111)는 다수의 프로세서들, 또는 분포된 프로세싱 아키텍처를 포함할 수 있다.
[0038] I/O 엘리먼트(113)는 다양한 입력/출력 컴포넌트들을 포함하고 그리고/또는 이에 커플링될 수 있다. 예를 들어, I/O 엘리먼트(113)는, 디스플레이, 스피커, 마이크로폰, 키패드, 포인팅 디바이스, 터치 감응식 스크린, 사용자 인터페이스 제어 엘리먼트들 및 사용자가 클라이언트 디바이스(110)로부터의 출력들을 수신하고 입력 명령들을 제공하게 하는 임의의 다른 디바이스들 또는 시스템들을 포함하고 그리고/또는 이에 커플링될 수 있다. 임의의 또는 모든 이러한 컴포넌트들은 클라이언트 디바이스(110)의 사용자 인터페이스를 제공하도록 사용될 수 있다. 부가적으로 또는 대안적으로, I/O 엘리먼트(113)는 디스크 제어기, 네트워크 인터페이스 카드(NIC), 라디오 주파수(RF) 트랜시버, 및 클라이언트 디바이스(110)의 입력 및/또는 출력 기능을 용이하게 하는 임의의 다른 디바이스들 또는 시스템들을 포함하고 그리고/또는 이에 커플링될 수 있다.
[0039] 스트리밍 콘텐츠에 액세스하고 플레이하기 위한 동작에서, 클라이언트 디바이스(110)는 연결들(151 및 152)을 이용하여 네트워크(150)를 통해 서버(130)와 통신하여, 렌더링될 때 콘텐츠의 재생을 제공하는 (예를 들어, 전술한 프래그먼트들로서) 콘텐츠 데이터를 획득할 수 있다. 따라서, UA들(129a 및 129b) 중 어느 하나 또는 둘 모두는 클라이언트 디바이스(110)에 콘텐츠 재생 환경을 구축하기 위해 프로세서(111)에 의해 실행된 콘텐츠 플레이어 애플리케이션을 포함할 수 있다. 특정 콘텐츠 파일의 재생을 개시할 때, UA는 서버(130)의 콘텐츠 전달 플랫폼과 통신하여 콘텐츠 식별자(예를 들어, 하나 이상의 리스트들, 매니페스트들, 구성 파일들, 또는 원하는 콘텐츠의 미디어 세그먼트들 또는 프래그먼트들, 그리고 이들의 타이밍 경계들을 식별하는 다른 식별자들)를 획득할 수 있다. 미디어 세그먼트들 및 이들의 타이밍에 관한 정보는 실시예들의 UA의 스트리밍 콘텐츠 로직에 의해 사용되어 콘텐츠의 재생에 대한 요청 프래그먼트들을 제어한다.
[0040] 본원의 실시예들에 따라 활용되는 인터페이스들의 수 및 구성이 도 1에 도시된 것으로 제한되지 않는다는 것이 인지되어야 한다. 예를 들면, 전송 가속기의 실시예들에 따라 더 적거나 더 많은 인터페이스들이 활용될 수 있다. 또한, 하나 이상의 그러한 인터페이스들은 도시된 네트워크 링크들(예를 들면, 연결들(151 및 152)) 이외의 것을 통해 그리고/또는 네트워크 컴포넌트들(예를 들면, 서버(130)) 이외의 디바이스들과의 데이터 통신을 제공할 수 있다.
[0041] 서버(130)는 원하는 콘텐츠를 클라이언트 디바이스들에 서빙하도록 동작가능한 하나 이상의 시스템들을 포함한다. 예를 들어, 서버(130)는 네트워크(150)를 통해 다양한 클라이언트 디바이스들에 콘텐츠를 스트리밍하도록 동작 가능한 표준 HTTP 웹 서버를 포함할 수 있다. 서버(130)는 콘텐츠를 클라이언트 디바이스(110)에 전달할 수 있는 임의의 시스템 또는 방법을 포함하는 콘텐츠 전달 플랫폼을 포함할 수 있다. 콘텐츠는 서버(130)와 통신하고 있는 하나 이상의 데이터베이스들, 예컨대, 예시된 실시예의 데이터베이스(140)에 저장될 수 있다. 데이터베이스(140)는 서버(130)에 저장될 수 있거나, 서버(130)에 통신가능하게 커플링되는 하나 이상의 서버들에 저장될 수 있다. 데이터베이스(140)의 콘텐츠는 다양한 형태들의 데이터, 예컨대, 비디오, 오디오, 스트리밍 텍스트, 및 서버(130)에 의해 시간 기간 동안 클라이언트 디바이스(110)에 전달될 수 있는 임의의 다른 콘텐츠, 예컨대 라이브 웹캐스트 콘텐츠 및 저장된 미디어 콘텐츠를 포함할 수 있다.
[0042] 데이터베이스(140)는 복수의 상이한 소스 또는 콘텐츠 파일들 및/또는 임의의 특정 콘텐츠의 복수의 상이한 표현들(예를 들어, 고해상도 표현, 중간 해상도 표현, 저해상도 표현 등)을 포함할 수 있다. 예를 들어, 콘텐츠 파일(141)은 고해상도 표현, 그리고 따라서 전달시, 특정 멀티미디어 컴필레이션의 높은 비트 레이트 표현을 포함할 수 있는 반면, 콘텐츠 파일(142)은 저해상도 표현, 그리고 따라서 전달시 동일한 특정 멀티미디어 컴필레이션의 낮은 비트 레이트 표현을 포함할 수 있다. 부가적으로 또는 대안적으로, 임의의 특정 콘텐츠의 상이한 표현들은, 예컨대, 콘텐츠 파일(143)에 의해 제공될 수 있는 순방향 에러 정정(FEC) 표현(예를 들어, 콘텐츠 데이터의 중복(redundant) 인코딩을 포함하는 표현)을 포함할 수 있다. URL(Uniform Resource Locator), URI(Uniform Resource Identifier) 및/또는 URN(Uniform Resource Name)은 본 명세서의 실시예들에 따른 이러한 콘텐츠 파일들 모두와 관련되며, 따라서, 이러한 URL들, URI들 및/또는 URN들이 요청된 데이터를 식별 및 액세스하기 위해, 아마도 다른 정보, 예컨대 바이트 범위들과 함께 사용될 수 있다.
[0043] 네트워크(150)는, 무선 네트워크, 유선 네트워크, 광역 네트워크(WAN), 로컬 영역 네트워크(LAN), 또는 본원에 설명된 콘텐츠의 전달에 적절한 임의의 다른 네트워크일 수 있다. 네트워크(150)는, 예를 들면, 3G 네트워크, 4G/LTE 네트워크, WiFi 네트워크 등뿐만 아니라 이들의 조합들을 포함할 수 있다. 또한, 단일 네트워크 클라우드로서 예시되지만, 실시예들에 따라 활용되는 네트워크(150)가 상이한 또는 별개의 네트워크들을 포함할 수 있고, 이들 중 임의의 것 또는 모두가 클라이언트 디바이스(110)와 서버(130) 사이의 통신을 제공하는 동일하거나 상이한 네트워크 기술들을 포함할 수 있다는 것이 인지되어야 한다. 일 실시예에서, 네트워크(150)는 인터넷의 적어도 일부들을 포함할 수 있다. 클라이언트 디바이스(110)는, 예컨대, 네트워크 연결(들)(151)로 표현된 양방향 연결을 통해 네트워크(150)에 연결될 수 있다. 대안적으로, 클라이언트 디바이스(110)는, 예컨대 MBMS(Multimedia Broadcast Multimedia System) 가능 네트워크(예를 들어, 연결들(151, 152) 및 네트워크(150)는 MBMS 네트워크를 포함하고, 서버(130)는 BM-SC(Broadcast Multicast Service Center) 서버를 포함할 수 있음)에 의해 제공되는 양방향 연결을 통해 연결될 수 있다. 연결은 유선 연결일 수 있거나 무선 연결일 수 있다. 일 실시예에서, 연결(들)(151)은 무선 연결, 예컨대, 셀룰러 3G 연결(예를 들면, 인터페이스(161a)에 의해 제공되는 연결(151a)), 셀룰러 4G 연결(예를 들면, 인터페이스들(161b 및 161c)에 의해 각각 제공되는 연결들(151b 및 151c)), WiFi(wireless fidelity) 연결(가령, 인터페이스(161d)에 의해 제공된 연결(151d)), 블루투스 연결, 또는 다른 무선 연결을 포함할 수 있다. 서버(130)는, 예컨대, 연결(152)로 표현된 양방향 연결을 통해 네트워크(150)에 연결될 수 있다. 서버(130)는 단방향 연결(예를 들어, 3GPP TS.26.346 또는 ATSC 3.0 네트워크에 설명된 프로토콜들 및 서비스들을 이용하는 MBMS 네트워크)을 통해 네트워크(150)에 연결될 수 있다. 연결은 유선 연결일 수 있거나 무선 연결일 수 있다.
[0044] 도 1에 예시된 실시예의 클라이언트 디바이스(110)는 UA들(129a 및 129b) 중 어느 하나 또는 둘 모두와 같은 UA들에 의해 요청된 원하는 콘텐츠의 프래그먼트들 또는 프래그먼트들의 시퀀스들의 향상된 전달을 제공하도록 동작 가능한 TA(120)를 포함한다. 예를 들면, 앞서 논의된 바와 같이, 예시된 실시예의 TA(120)는, 클라이언트 디바이스(110)의 UA들로의 데이터의 촉진된 전달을 가능하게 하도록 동작 가능한 다양한 향상된 프래그먼트 전달 기능을 제공하기 위해 협조하는 RM 및 CM 기능을 포함한다. 그러나, 전통적으로 제공되는 전송 가속 기능은 UA들의 모든 구성들 또는 모든 상황들에서 이용 가능하지는 않을 수 있다. 따라서, 본원의 실시예들은 다양한 UA들에 의해 전송 가속기 동작의 요청을 가능하게 하도록 적응된다. 예를 들면, 특정 콘텐츠 또는 특정 콘텐츠 요청에 관련하여 전송 가속이 요구된다는 시그널링을 UA가 TA에 제공하는 경우에, TA는 시그널링을 검출하고, 그에 응답하여 전송 가속 기능을 제공할 수 있다. 그러나, 모든 콘텐츠 요청들이 전송 가속기 동작으로부터 이득을 얻을 수 있지는 않기 때문에, 그럼에도 불구하고 실시예들은 다양한 UA들에 의한 그러한 요청들에 응답하여 전송 가속기 동작을 선택적으로 구현한다(예를 들면, 이로써 전송 가속기 동작의 하나 이상의 기능들이 선택적으로 우회되거나 특정 기준들에 기초하지 않음). 예를 들면, 전송 가속이 특정 콘텐츠 또는 특정 콘텐츠 요청에 관련하여 요구된다고 요청하는 시그널링을 UA로부터 검출하지만, TA는 전송 가속 기능의 구현이 실제로 시그널링된 요청에 응답하여 구현되는지를 결정하도록 동작할 수 있다.
[0045] 본원의 개념들의 이해를 돕기 위해, UA들(129a 및 129b)은 실시예들에 따라 적응된 TA(120)에 의해 서빙되거나 서빙되지 않을 수 있는 상이한 구성들을 갖는 UA들을 포함한다. 후속하는 논의로부터 인지될 바와 같이, UA(129)는, 시스템 프레임워크(127)의 기능 또는 자원들을 활용하지 않지만, 그럼에도 불구하고 TA(120)의 기능을 활용하도록 적응된 애플리케이션 또는 다른 사용자 에이전트를 포함한다. 이와 대조적으로, UA(129b)는 시스템 프레임워크(127)의 기능을 활용하는 애플리케이션 또는 다른 사용자 에이전트를 포함하고, 그러한 상호작용을 통해, 또한 TA(120)의 기능이 제공될 수 있다.
[0046] 특히, UA(129b)는 시스템 프레임워크(127)를 통해 콘텐츠에 대한 요청들을 통신하도록 적응되고, 여기서 시스템 프레임워크(127)는 링크(128c)를 통해 UA(129b)와 같은 다양한 UA들에 의해 사용하기 위한 특정 저레벨 기능을 제공한다. 예를 들면, 시스템 프레임워크(127)는 다큐멘트화된 기능(예를 들면, HTTP 계층 트랜잭션들, 네트워크 계층 트랜잭션들, 미디어 재생 엔진 등)을 공개된 API를 통해 UA들에 제공하는 ANDROID 모바일 디바이스 운영 시스템에 의해 제공된 STAGEFRIGHT 미디어 플레이어 아키텍처를 포함할 수 있다. 따라서, 실시예들의 TA(120)는 시스템 프레임워크(127)와 상호동작하고, 시스템 프레임워크(127) API를 구현하는 애플리케이션들에 의해 사용하기 위한 전송 가속 기능을 제공하도록 적응될 수 있다. 예를 들면, 시스템 프레임워크(127)는 전송 가속 동작을 위해 UA(129b)에 의해 이루어진 콘텐츠 요청들을 TA(120)에 제공하기 위해 링크(128d)를 통해 TA(120)와 상호작용할 수 있다. TA(120)는, 예를 들면, 링크(128d)와 연관된 "항상 가속" 포트를 제공할 수 있고, 이로써 링크(128d)를 통해 수신된 콘텐츠 요청들은 시스템 프레임워크(127)를 통해 제공되는 것으로 알려져 있고, 따라서 본원에 설명된 개념들에 따라 전송 가속 동작이 실시될 수 있다.
[0047] 그러나, UA(129a)는, 가령, UA(129a)의 동작에 대해 그러한 기능들을 최적화하기 위해, 그렇지 않은 경우 시스템 프레임워크(127)를 통해 이용 가능한 그 자신의 저레벨 기능 또는 서비스들(예를 들면, HTTP 계층 트랜잭션들, 네트워크 트랜잭션들, 미디어 재생 등)을 구현하도록 적응될 수 있다. 예를 들면, UA(129a)는, 시스템 프레임워크(127)를 활용하기보다는, 그 자신의 HTTP 계층, 네트워크 계층, 미디어 재생 엔진 등을 구현하는 상대적으로 높은 네트워크 영향 애플리케이션(예를 들면, NETFLIX 또는 YOUTUBE 클라이언트)을 포함할 수 있다. 따라서, UA(129a)는 서버(130)와 통신하기 위해 링크(128a)를 통해 I/O 엘리먼트(113)에 의해 제공되는 하나 이상의 포트들과 직접적으로 상호작용하도록 동작할 수 있고, 이로써 TA(120)에 의해 제안된 전송 가속기 기능을 우회한다.
[0048] UA(129a)가 또한 시스템 프레임워크(127)를 통해 이용 가능한 특정 기능을 자체 제공하도록 적응될 수 있지만, UA(129a)는 그럼에도 불구하고 TA(120)의 전송 가속 기능과 같은 다른 기능의 가용성 및 구현으로부터 이득을 얻을 수 있다. 예를 들면, 전송 가속 기능의 구현은 UA의 개발자들의 전문지식 분야 밖에서 복잡하거나, 그렇지 않다면 UA(129a) 내에 직접적으로 포함하기 위한 이상적인 기회를 제공하지 않을 수 있다. 따라서, UA(129a)가 시스템 프레임워크(127)의 기능을 활용할 수 없다는 사실에도 불구하고, UA(129a)에 본원의 실시예들의 TA(120)의 전송 가속 기능에 대한 액세스가 제공되는 것이 바람직할 수 있다.
[0049] 도 1에 예시된 실시예의 UA(129a)는, TA(120)에 예시된 전송 가속기 기능이 UA에 의해 이루어진 콘텐츠 요청들에 관련하여 구현되는 동작을 가능하게 하도록 적응된다. 예를 들면, UA(129a)는 전송 가속 동작을 위해 UA(129a)에 의해 이루어진 콘텐츠 요청들이 TA(120)에 제공하기 위해 링크(128b)를 통해 TA(120)와 상호작동하도록 적응될 수 있다. 실시예들의 UA(129a)는, 가령, 콘텐츠 요청들을 I/O 엘리먼트(113)의 포트로 직접적으로 지향시키고 이로써 TA(120)의 전송 가속 기능을 우회함으로써, 또는 TA(120)의 전송 가속 기능을 인보크하기 위한 콘텐츠 요청들을 TA(120)의 포트로 지향시킴으로써 전송 가속을 선택적으로 구현하도록 적응된다. TA(120)는, 예를 들면, 링크(128b)와 연관된 "선택적으로 가속" 포트를 제공할 수 있고, 이로써 UA(129a)는 링크(128b)를 통해 TA(120)의 선택적으로 가속 포트에 전송 가속 기능이 제공되기를 원하는 요청들을 지향시킬 수 있다. 이로써 링크(128b)를 통해 수신된 콘텐츠 요청들은 본원에 설명된 개념들에 따른 전송 가속 동작에 영향을 받는다. 본원의 개념들에 따른 전송 가속 기능의 자신의 사용을 가능하게 하기 위한 UA의 수정(modification)이 상대적으로 작을 수 있다는 것이 인지되어야 한다. 예를 들면, 특정 동작들, 콘텐츠 등에 관련하여 전송 가속이 요구되는지 여부를 결정하기 위한 로직 및/또는 UA에 의해 이루어진 요청들에 관련하여 전송 가속 서비스들을 제공하기 위한 적절한 요청들을 전송 가속기 포트(예를 들면, TA(120)의 실시예들의 선택적으로 가속 포트)로 지향시키기 위한 로직이 UA에 제공될 수 있다.
[0050] 앞서 말한 것으로부터, 실시예들에 따른 동작에서, UA(129a)는 전송 가속 기능이 요구되는 콘텐츠 요청들을 (예를 들면, 링크(128b)를 통해) TA(120)와 연관된 포트로 지향시키도록 적응된다. 예를 들면, UA(129a)의 로직은, 전송 가속 동작이 요구되는(예를 들면, 다운로드 성능 개선을 제공하는 것으로 알려진 또는 예상되는) 큰 파일, 특정 타입의 미디어, 스트리밍 미디어 콘텐츠 등을 요청된 콘텐츠가 포함한다고 결정할 수 있다. 따라서, UA(129a)는 그와 연관된 콘텐츠 요청들을 링크(128b)를 통해 TA(120)로 선택적으로 지향시키도록 동작할 수 있다. 상대적으로 작은 파일들, 전송 가속이 비현실적이거나 일반적으로 개선된 성능을 발생시키지 않는 특정 타입들의 미디어 등에 대한 콘텐츠 요청들과 같은 다른 콘텐츠 요청들은 실시예들에 따라 링크(128a)를 통해 I/O 엘리먼트(113)의 포트로 지향될 수 있고, 이로써 TA(120)를 우회한다.
[0051] 본원의 실시예들에 따른 전송 가속 동작을 가능하게 하기 위해, TA(120)의 선택적으로 가속 포트에 대해 이루어진 콘텐츠 요청들은, 요청이 전송 가속 동작을 수신하는 것이 요구된다는 것을 표시하거나, 전송 가속 동작을 가능하게 하는데 유용한 정보를 제공하는 것 등을 위한 시그널링을 포함한다. 예를 들면, 실시예들의 UA(129a)는, 전송 가속기 기능이 제공되는 것이 콘텐츠 요청이라는 요청을 표시하는 콘텐츠 요청을 갖는 헤더 정보(예를 들면, 본원의 전송 가속기 동작에 대해 고유한 HTTP 헤더)를 포함하도록 동작할 수 있다. 그러한 헤더 정보는 UA로의 콘텐츠의 전달을 요구되거나 최적의 방식으로 제공하는데 있어서 유용한 우선순위 정보, 타이밍 정보, 스케줄링 정보, 비트레이트 정보, 파일 크기 정보 등과 같은 데이터를 부가적으로 포함할 수 있다.
[0052] 실시예들에 따른 동작에서, TA(120)의 선택적으로 가속 포트에서 수신된 콘텐츠 요청에 관련한 디폴트 거동은, 전송 가속 기능을 제공하는 것이 아니라, 대신에 가속 프로세싱 없이 그러한 요청들을 전달하는 것이다(예를 들면, 콘텐츠 요청들을 I/O 엘리먼트(113)의 포트에 제공함). 그러한 디폴트 거동은 시스템 프레임워크(127)를 활용하기를 원하지 않고 또한 가속화된 특정 요청을 원하지 않는 UA가 특수 헤더 없이 요청을 TA(120)의 선택적으로 가속 포트로 전송하고 따라서 그 요청에 대한 전송 가속 동작을 우회하는 것을 가능하게 한다. 예를 들면, 콘텐츠 요청이 가속화된다는 것을 표시하는 특수 헤더가 UA(129a)에 의해 TA(120)로 전송되는 콘텐츠 요청에 존재하지 않는다면, 콘텐츠 요청은 실시예들의 TA(120)에 의해 가속화되지 않을 것이다. 따라서, UA는, 전송 가속기 기능이 제공되는 것이 콘텐츠 요청이라는 것을 표시할 뿐만 아니라, 요청을 분할하고 이를 스케줄링하는데 전송 가속기가 활용할 수 있는 부가적인 메타-정보를 제공하기 위해, 상술된 특수 헤더를 사용하여 제공될 수 있는 시그널링을 사용할 수 있다. 이러한 시그널링(예를 들면, 특수 헤더)은, 콘텐츠 요청들을 콘텐츠 서버로 포워딩하기 전에, 실시예들의 전송 가속기에 의해 콘텐츠 요청들로부터 제거될 수 있다. 이러한 시그널링은 다양한 적절한 방식들 중 임의의 것으로 콘텐츠 요청에 포함될 수 있고, 예를 들면, 시그널링은 HTTP 요청의 특수 헤더일 수 있고, HTTP 요청의 헤더의 필드 값으로서 포함될 수 있고, HTTP 요청의 URI 또는 URL의 질의 스트링 내의 하나 이상의 파라미터들에 포함될 수 있고 그리고/또는 임의의 다른 적절한 특징의 콘텐츠 요청으로서 포함될 수 있다.
[0053] 상술된 시그널링은, 가령, 요청된 전송 가속기 기능의 구현에 관한 TA(120)로부터 UA(129a)로의 시그널링을 포함하기 위해 양방향일 수 있다. 예를 들면, 실시예들의 TA(120)는, 콘텐츠 요청이 가속화되었는지 여부를 UA(129a)가 표시하여, (예를 들면, UA에 의해 호환 가능하거나 최적화된 동작을 가능하게 하기 위해) 제공되는 가속의 상세들(particulars)에 관한 정보 등을 제공하는 것에 대한 하나 이상의 응답들에 헤더(예를 들면, 본원의 전송 가속기 동작에 대해 고유한 HTTP 헤더)를 포함하도록 동작할 수 있다.
[0054] 상술된 전송 가속기 시그널링을 구현하는데 있어서, 본원의 실시예들은 본원에 설명된 바와 같이 정보를 전달하기 위해 UA/TA 특수 요청 헤더(본원에서 "QC-STA 헤더"로 지칭됨)를 제공하도록 적응될 수 있다. 실시예들의 QC-STA 헤더가 UA-TA 연결에만 관련되기 때문에, QC-STA 헤더는 본원의 실시예들에 따른 전송 가속기에 의한 콘텐츠 요청의 포워딩 전에 제거될 수 있다. 물론, QC-STA 헤더 또는 다른 시그널링은, 자신이 무시될 수 있고 따라서 그의 제거가 선택적일 수 있도록 구성될 수 있다. 본원에 포함된 본원의 실시예들의 QC-STA 헤더를 갖는 HTTP 요청 헤더의 예는 "연결: 클로즈, QC-STA"이다. 본원의 개념들에 따른 QC-STA 헤더는 구분자들(separators)(예를 들면, HTTP 헤더들에서 공통적으로 사용되는 구분자 ";")를 갖는 키-값 쌍들의 리스트를 포함한다. 각각의 키-값 쌍은, 예를 들면, "키=값" 포맷으로 제공될 수 있다. 실시예들의 일반적인 형태의 QC-STA 헤더는 "QC-STA: 키1=값1; 키2=값2;...; 키N=키N;"을 포함할 수 있고, 여기서 헤더 토큰 스트링 자체는 구분자 ";"로 종료된다. 실시예들에 따른 동작에서, QC-STA 헤더가 콘텐츠 요청에 존재하지 않는다면, 콘텐츠 요청은 전송 가속기에 의해 가속화되지 않을 것이다.
[0055] QC-STA 헤더에 포함된 키들은 다양한 상이한 타입들의 정보를 제공할 수 있다. 예를 들면, QC-STA 헤더에 관련하여 활용되는 키들은, 제한없이, fileType, priority, streamingBitRate, streamingPlaybackBuffer 및 requestExpirationTime을 포함할 수 있다. 키들 중 특정 키들은 부가적인 데이터를 포함하거나 그와 연관된 부가적인 데이터를 가질 수 있다. 예를 들면, 실시예들에 따라, 모든 파일 타입들에 대해 approxFileSize 정보가 제공될 수 있다. 그러나, 키들 중 어떠한 것도 실시예들의 QC-STA 헤더에 존재하도록 요구되지 않는다는 것이 인지되어야 한다. 즉, UA는, 가령, 디폴트 파라미터들/설정들을 사용하여 전송 가속 기능을 개시하기 위해 그 안에 어떠한 토큰들도 갖지 않는 QC-STA 헤더를 갖는 콘텐츠 요청을 전송할 수 있다. 그러나, 본원의 실시예들의 TA(120)의 선택적으로 가속 포트에 대한 콘텐츠 요청들에 대해, 앞서 말한 키들 모두는 요구될 때 또는 적절할 때 사용될 수 있다.
[0056] 아래의 표 1은 본원의 실시예들의 QC-STA 헤더에 관련하여 활용될 수 있는 키들의 예들, 값들의 타입들 및 키들의 가능한 값들을 제공한다.
표 1
키 의미 키의 값들 및 타입들
fileType 파일의 타입 "스트리밍", "벌크파일"(스트링)
requestPriority 요청의 우선순위 무부호 정수, 최대값은 구현 의존적일 수 있음. 더 높은 값은 더 높은 우선순위들을 의미함. 예들은: 0-백그라운드 트래픽(예컨대, 다운로드 관리기), 1-정규적인 포그라운드 트래픽(예컨대, 스트리밍 비디오), 2-가장 높은 우선순위 포그라운드 트래픽(예컨대, MPD 페치)을 사용함.
streamingBitRate 스트림의 비트 레이트(예컨대, kbps 단위) 무부호 정수
streamingPlaybackBuffer UA는 현재 재생 버퍼가 얼마나 긴지를 지정할 수 있음(예컨대, 밀리초 단위). 무부호 정수
requestExpirationTime 이러한 시간은 응답이 UA에 의해 수신되어야 하는 절대적인 시간을 지정할 수 있음 (부동 소수점)
이것은 Unix 에포크 이래로 시스템 시간(예컨대, 초 단위)일 수 있음. 이것은 실시예들에 따라 적어도 64 비트 정밀도를 갖는 수로서 파싱되어야 함.
approxFileSize 대략적인 파일 크기(예를 들면, 킬로바이트(KB) 단위). 스트리밍 fileType에 대해, UA는 세그먼트의 듀레이션 및 공칭 비트레이트로부터 이를 계산함. 무부호 정수
preferredNetworkInterface UA는 자신이 선호하는 네트워크 인터페이스를 표시할 수 있고, 그 네트워크 인터페이스 상에서 TA가 요청을 전송함. 스트링
예시적인 값들: "WiFi", "셀룰러 4G".
fastStartSize UA가 고속 시동을 요구하면, UA는 이러한 파라미터를 제공할 수 있음(예를 들면, KB 단위). 무부호 정수
useHTTPS 요청/서브-요청들이 SSL/TLS 연결을 사용하여 서버로 전송되는지를 표시함 "y", "n"(스트링)
[0057] 본원의 QC-STA 헤더의 실시예에 따라 활용될 수 있는 상술된 키들의 추가적인 설명에 의해, "fileType" 키는 콘텐츠 요청이 속하는 파일의 특정 타입에 관한 정보를 포함할 수 있다. 이러한 정보는, 전송 가속기 기능의 구현이 현실적이거나, 예를 들면, 콘텐츠 요청과 연관하여 사용하기에 유리한지를 결정하기 위해 전송 가속기에 의해 사용될 수 있다. 부가적으로 또는 대안적으로, 그러한 정보는 가속의 하나 이상의 양상들이 구현되는 방법을 결정(예를 들면, 청크 크기, 비트 레이트, 에러 정정 등을 결정)하기 위해 전송 가속기에 의해 활용될 수 있다.
[0058] "requestPriority" 키는 UA 내의 주어진 콘텐츠 요청의 우선순위에 관한 정보를 제공할 수 있다. 실시예들에 따른 동작에서, 근본적인 또는 하위 레벨 통신 계층으로의 우선순위의 일치하는 맵핑이 존재한다. 예를 들면, 실시예들은, 가령, UA에 의해 이루어진 콘텐츠 요청과 일치하는 청크 요청 우선순위들을 설정하기 위해, 이러한 우선순위 정보를 저레벨 네트워크 라이브러리(예를 들면, CHROMIUM)에 전달하도록 동작할 수 있다. 부가적으로 또는 대안적으로, 실시예들은, 콘텐츠 요청과 함께 제공되는 우선순위 정보에 따라 콘텐츠 요청의 청크 요청들을 스케줄링하는 전송 가속기 내에서 스케줄링 알고리즘을 구현할 수 있다.
[0059] "streamingBitRate" 키는 클라이언트가 요청된 데이터를 재생 또는 프로세싱하기로 예상된 레이트를 표시하는 정보를 제공할 수 있다. 따라서, 실시예들에 따라 스트리밍 레이트를 지정하는 것은 전송 가속기가 적절한 공유의 대역폭을 경쟁하는 요청 스트림들에 할당하도록 동작하는 것을 가능하게 할 수 있고, 이것은 표시된 재생 또는 데이터 프로세싱 레이트를 만족시키는 UE로의 데이터의 전달을 발생시킨다.
[0060] "streamingPlaybackBuffer" 키는 UA의 현재 재생 버퍼의 길이를 표시할 수 있다. 실시예들의 streamingPlaybackBuffer 키는 가속의 하나 이상의 양상들이 구현되는 방법을 결정(예를 들면, 청크 크기, 비트 레이트, 에러 정정 등을 결정)하기 위해 전송 가속기에 의해 활용될 수 있다. 예를 들면, 재생 버퍼의 크기는 가까운 미래에 다운로딩될 데이터의 양(예를 들면, 발행하기 위한 청크 요청들의 크기 및 수)을 결정하기 위해 TA(120)에 의해 사용될 수 있다.
[0061] "requestExpirationTime" 키는 콘텐츠 요청이 완료되는 시간을 표시할 수 있다. 타겟 시간은, 예를 들면, Unix 에포크가 단편적인 초들로(with fractional seconds) 허용될 수 있기 때문에 초 단위로 제공될 수 있다. 실시예들에 따른 동작에서, 타임스탬프는 논의되는 디바이스의 시스템 시간에 대해 상대적일 수 있고, 여기서 시스템 시간은 이러한 구현이 정확한 만료 시간들을 허용하기에 정확할 필요는 없다(예를 들면, TA(120) 및 UA(129a)가 동일한 클록을 사용하는 경우에, 실제 만료는 요구된 시점에서 발생할 것임). 만료 시간에 도달할 때, 실시예들의 전송 가속기는 콘텐츠 요청을 취소하도록 동작할 수 있다(예를 들면, 이후에 수신된 임의의 콘텐츠 데이터는 시기적으로 부적절(untimely)할 때 사용 불가하거나 바람직하지 않을 수 있음).
[0062] "approxFileSize" 키는 요청된 자원의 대략적인 파일 크기를 표시할 수 있다. 그러한 정보는, 예를 들면, (예를 들면, 정확한 파일 크기가 알려지기 전에) 발행하기 위한 적절한 수의 청크 요청들을 선택하기 위해 전송 가속기에 의해 사용될 수 있다. 실시예들에 따른 대략적인 파일 크기 정보의 활용의 예로서, 청크 크기가 C이면, TA(120)의 RM(121)은 파일 크기를 실제로 결정하고 추가의 요청들을 발행하기 위해 제 1 응답을 수신하기 전에 max(floor(approxFileSize/C), 1) 청크 요청들을 발행할 수 있다.
[0063] "preferredNetworkInterface" 키는 요청이 특정 네트워크 인터페이스(예를 들면, WiFi) 상에서 송신되는 것의 선호도를 표시할 수 있다. 예를 들면, WiFi 네트워크 인터페이스의 사용은, 이용 가능할 때, 셀룰러 데이터 플랜 제약들로 인해 셀룰러 인터페이스에 비해 선호될 수 있다. 선호되는 네트워크 인터페이스의 그러한 선택은, 예를 들면, 동작 가능한 인터페이스들을 인지하는 연결 관리기에 대한 UA에 의한 액세스를 통해 가능하게 될 수 있다.
[0064] "fastStartSize" 키는 요청된 콘텐츠의 전달에 대한 고속 시작이 제공되기를 원하는 요구를 표시하기 위해 UA에 의해 사용될 수 있다. 이에 응답하여, 전송 가속기는, 가령, 이러한 초기 양의 콘텐츠를 다운로딩하기 위해 다수의 인터페이스들을 사용하고, 가령, 다수의 인터페이스들의 사용으로부터 하나의 인터페이스의 사용으로 스위칭하고, 요청된 콘텐츠의 나머지를 페칭하기 위해 나중에 정상 페칭 동작으로 스위칭하여 요청을 만족시키려고 최상으로 자신의 노력들을 사용할 수 있다.
[0065] "useHTTPS" 키는, 전송 가속기가 보안 통신 경로(예를 들면, HTTPS 프로토콜에 의해 제공됨)를 사용하여 콘텐츠 요청을 전송한다는 것을 표시하기 위해 UA에 의해 사용될 수 있다.
[0066] 키들의 앞서 말한 예들, 값들의 타입들 및 키들의 가능한 값들을 사용하면, 키들 및 그들의 값들을 갖는 예시적인 QC-STA 헤더가 다음과 같이 보일 수 있다.
Figure 112017029999460-pct00001
[0067] 앞서 말한 것이 본원의 실시예들에 따라 구현될 수 있는 시그널링의 예들을 제공하고, 따라서 특정 구현들이 본원의 개념들에 따라 다양한 상이한 정보를 제공하는 시그널링을 구현할 수 있다는 것이 인지되어야 한다.
[0068] 실시예들에 따라 활용될 수 있는 시그널링의 추가의 예로서, 아래의 표 2에 제시된 키들, 값들의 타입들 및 키들의 가능한 값들은 본원의 개념들에 따라 QC-STA 헤더에 관련하여 활용될 수 있다.
표 2
키 의미 키의 값들 및 타입들
fileType 파일의 타입 "스트리밍", "벌크파일"(스트링)
uniqueUAinstanceID 요청을 발행하는 UA 인스턴스의 고유한 ID (스트링) 이것은 요청을 발행하는 UA에 대한 고유한 식별자일 수 있음(예컨대, 캐릭터들 [a-zA-Z0-9＼-+_]를 갖는 스트링)
UAPriority UA의 우선순위 무부호 정수(예컨대, 값들은 0 내지 7 범위 내에 있을 수 있고, 여기서 0-백그라운드 우선순위, 3-표준, 및 7-디폴트가 3인 경우 높은 우선순위).
uniqueStreamID 요청이 속하는 스트림의 고유한 식별자 (스트링) 이것은 스트림에 대한 고유한 식별자 스트링일 수 있음.
streamPriority 스트림의 우선순위 무부호 정수(예컨대, 값들은 0 내지 2^32-1 범위 내에 있을 수 있고, 여기서 더 높은 값들은 더 높은 우선순위들을 의미함).
예들은: 0-백그라운드 트래픽(예컨대, 다운로드 관리기), 2^31-정규적인 포그라운드 트래픽(예컨대, 스트리밍 비디오), 2^32-1-가장 높은 우선순위 포그라운드 트래픽(예컨대, MPD 페치)
streamBitRate 스트림의 비트 레이트(예컨대, kpbs 단위) 무부호 정수
streamPlaybackBuffer UA는 현재 재생 버퍼가 얼마나 긴지를 지정할 수 있음(예컨대, 밀리초 단위). 무부호 정수
requestExpirationTime 이러한 시간은 응답이 UA에 의해 수신되어야 하는 절대적인 시간을 지정함. (부동 소수점)
이것은 Unix 에포크 이래로 초 단위의 시스템 시간임. 이것은 적어도 64 비트 정밀도(53 비트 가수(mantissa))를 갖는 부동수로서 파싱되어야 함.
requestSoftExpirationTime 요청이 "소프트하게" 만료하는 시간. 아래의 설명들을 참조. requestExpirationTime와 동일함.
requestUniqueID 요청에 대한 고유한 식별자 핸들 (스트링) 이것은 요청에 대한 고유한 식별자 스트링일 수 있음(예컨대, 캐릭터들 [a-zA-Z0-9＼-+_]를 갖는 자유-형태 스트링을 포함함).
requestPrerequisites 요청된 자원에 대한 전제조건들인 고유한 요청 식별자들의 콤마-분리된 리스트 (스트링)(예컨대, requestUniqueID 키에 정의된 바와 같이, 고유한 요청 ID들의 콤마-분리된 리스트).
[0069] 본원의 QC-STA 헤더의 실시예에 따라 활용될 수 있는 상술된 키들의 추가의 설명에 의해, "uniqueUAinstanceID" 키는 UA가 몇몇의 연결들 상에서 전송 가속기에 요청하는 동작을 가능하게 할 수 있다. 예를 들면, uniqueUAinstanceID 키는, 전송 가속기가 어떠한 연결들이 어떠한 UA에 속하는지를 알 수 있게 하는 선험 정보를 제공할 수 있다. 그러한 정보는 공정하게 말하면 UA들 중에서 그 능력을 전송 가속기에 제공하기 위해 실시예들의 TA(120)에 의해 활용될 수 있다.
[0070] 실시예들의 "uniqueUAinstanceID" 키는, 이것이 고유한 방식으로 선택된다. 예를 들면, UA는 128 비트 랜덤 넘버를 생성하고, 자신의 고유한 ID로서 그 랜덤 넘버의 육진 표기(hex notation)를 사용할 수 있다. 대안적으로, 실시예들은 자신의 고유성(uniqueness)을 보장하는 고유한 ID를 생성하기 위한 관습(convention)을 정의할 수 있다. 예를 들면, 고유한 ID는 프로세스 PID 및 그의 시작 시간의 조합일 수 있고, 이로써 그러한 조합은 전형적으로 임의의 주어진 호스트 상의 모든 프로세스들 중에서 고유하다.
[0071] 실시예들의 "UAPriority" 키는 UA에 대한 우선순위를 설정한다. 실시예들에 따라 구현된 가능한 우선순위 값들의 세트는, 가령, 상이한 UA들에 걸쳐 우선순위 값들의 일관된 사용을 가능하게 하기 위해 의도적으로(deliberately) 낮은 넘버(예를 들면, 0으로부터 7까지의 값들의 범위의 8 개의 별개의 설정들)로 유지된다. 우선순위 키에 대한 더 높은 값들은 일부 실시예들에 따라 더 높은 우선순위를 표시한다. 동작 시에, 더 높은 우선순위 UA들의 요청들은, 개별적인 스트림들에 주어진 우선순위 값들과 상관없이 특혜 대우(preferential treatment)를 가질 수 있다. 개별적인 스트림들의 우선순위 값들은 본원의 실시예들에 따라 UA들에 걸치지 않고 동일한 UA들의 스트림들에 대해 비교된다. 예를 들면, 하나의 UA는 모든 자신의 콘텐츠 요청들을 2^31의 디폴트 값으로 유지하도록 동작할 수 있고, 반면에 다른 것(예를 들면, 라이브 스트리밍 클라이언트)은 시간에 걸쳐 잠재적으로 모든 2^32 개의 가능한 값들을 사용하는 정교한 방식을 가질 수 있고, 이것은 실시예들에 따라 동작 시에 우선순위들을 할당하는 상이한 방식으로 인해 하나의 UA가 다른 것을 지배하지 않게 해야 한다. 그러나, 일부 실시예들에서, 개별적인 스트림들의 우선순위 값들은, 예를 들면, UA들이 우선순위 값들을 할당하기 위한 유사한 알고리즘들을 갖고 그리고/또는 UA들이 함께 작업하도록 설계되었다면, 다수의 UA들에 걸쳐 그들의 스트림들에 대해 비교될 수 있다.
[0072] 많은 UA들이 그들의 디폴트 우선순위(예를 들면, UAPriority = 3)를 변경할 수 없다고 예상되지만, 그럼에도 불구하고 다양한 스트림들은 상이한 우선순위를 활용할 수 있다. 예를 들면, 비-상호작용 소프트웨어 업데이트 프로세스는 자신에 더 낮은 우선순위(예를 들면, UAPriority = 0)를 할당함으로써 스트리밍 클라이언트들을 잠재적으로 실행하는 방식에서 이동할 수 있다.
[0073] 실시예들에 따른 동작에서, UA는 새로운 콘텐츠 요청에서 새로운 값을 제공함으로써 그와 연관된 우선순위를 업데이트할 수 있다. UA가 자신의 우선순위를 업데이트하도록 동작할 수 있는 애플리케이션의 일 예는 매우 큰 버퍼를 갖는 비디오 스트리밍 클라이언트(예를 들면, 전체 영화를 사전에(ahead of time) 다운로드하도록 동작하는 GOOGLE PLAY)이다. 버퍼가 낮을 때, UA는, 일단 버퍼 레벨이 일부 임계치(예를 들면, 몇 분의 버퍼링된 데이터)에 도달하면, 이용 가능한 버퍼링된 데이터를 증가시키지만 자신의 우선순위를 낮추기 위해 높은 우선순위를 표시할 수 있다. 버퍼가 낮아지게 되면, UA는 다시 자신의 우선순위를 증가시킬 수 있다. 그러나, 그러한 우선순위 업데이트들이 경쟁 조건(race condition)의 위험을 도입한다는 것이 인지되어야 한다. 경쟁 조건을 회피하기 위해, 실시예들의 UA는, 자신이 자신의 요청 우선순위를 업데이트한 경우 자신이 이전의 콘텐츠 요청에 대한 적어도 일부 응답을 수신한 후에 자신의 우선순위를 업데이트할 수 있다.
[0074] "uniqueStreamID" 키는 콘텐츠 요청이 속하는 스트림의 식별을 제공할 수 있다. 동일한 uniqueStreamID를 갖는 콘텐츠 요청들은 동일한 스트림에 속하는 것으로 고려될 수 있고, 따라서 실시예들에 따라 키들 사이에서 하나 이상의 속성들을 공유할 수 있다. 실시예들에 따른 동작에서, 스트림 ID들은 콘텐츠를 요청하는 UA 내에서만 고유할 필요가 있다(예를 들면, 전송 가속기는 스트림들의 ID 및 그와 연관된 UA ID 둘 모두에 의해 스트림들을 식별할 수 있음).
[0075] 실시예들에 따라 명시적인 스트림 식별자들을 갖는 것은 UA에 의한 단일 스트림에 대한 전송 가속기에 대한 몇몇의 연결들의 사용을 가능하게 하고, 전송 가속기는 여전히 어떠한 세트의 연결들이 그 스트림을 형성하는지를 알 수 있다. 그러한 구성은 다양한 상황들에서 유용할 수 있다. 예를 들면, UA가 DASH 클라이언트를 포함하는 경우에, 오디오 및 비디오에 대한 별개의 스트림들이 구현될 수 있다. UA가 네트워킹 라이브러리(예를 들면, CHROMIUM 스택)를 사용하면, UA로부터 전송 가속기로의 연결들은 스트림들을 충실히 나타낼 수 없다(예를 들면, 임의의 연결 상의 임의의 콘텐츠 요청은 2 개의 스트림들 중 어느 하나에 속할 수 있음). 따라서, 본원의 개념들에 따라 동작하는 DASH 클라이언트는 스트림 식별자들을 사용하여 자신의 콘텐츠 요청들을 태깅하여, 이로써 전송 가속기가 상이한 스트림들에 대해 청크 요청들을 정확히 우선순위화하는 것을 가능하게 할 수 있다.
[0076] "streamPriority" 키는 스트림에 대한 (예를 들면, 0 내지 2^32-1 범위 내의) 우선순위 값을 제공할 수 있다. UA 및 전송 가속기는 더 큰 범위의 스트림 우선순위들의 경우에 더 작은 세트들의 우선순위 값들에 관련하여, 앞서 설명된 것들과 유사한 알고리즘들을 사용할 수 있다. 실시예들에 따른 동작에서, 동일한 UA의 스트림들에 관련하여, 전송 가속기는 더 낮은 우선순위를 갖는 스트림들 전에 더 높은 우선순위를 갖는 스트림들로부터의 콘텐츠 요청들을 프로세싱한다. streamPriority 값은, 그 값이 후속 콘텐츠 요청에서 업데이트될 때까지 콘텐츠 요청이 이루어진 스트림에 대한 장소에 남아있을 수 있다. streamPriority 값이 업데이트될 때, 심지어 우선순위의 변화 전에 발행된 그 스트림의 콘텐츠 요청들에 대해, 그것은 전체 스트림에 대해 변경된 것으로 고려될 수 있다.
[0077] "streamBitRate" 키는 콘텐츠 요청들이 이루어지는 스트림에 대해 추정되어야 하는 비트레이트(예를 들면, Kbps 단위)를 표시할 수 있다. 그러한 비트레이트 정보는 만족스러운 대역폭 공유 정책을 구현하고, 가령, 다른 UA에서 결핍된 데이터 전달 없이 UA에서 원하는 성능을 가능하게 하기 위해 전송 가속기에 의해 사용될 수 있다. 실시예들에 따른 동작에서, streamBitRate는, 자신이 동일한 스트림에 대한 후속 콘텐츠 요청에서 새로운 값으로 대체될 때까지 주어진 스트림에 계속 설정되어 있을 수 있다. 미리 결정된 비트레이트 값(예를 들면, -1)은 실시예들의 streamBitRate 키에 의해 제공된 비트레이트 "힌트"를 클리어링하는데 사용될 수 있다.
[0078] "streamPlaybackBuffer" 키는 스트림에서 현재 재생 버퍼의 양(예를 들면, 밀리초 단위)을 표시할 수 있다. 실시예들의 streamPlaybackBuffer 키는 가속의 하나 이상의 양상들이 구현되는 방법을 결정(예를 들면, 청크 크기, 비트 레이트, 에러 정정 등을 결정)하는데 있어서 전송 가속기에 의해 활용될 수 있다. 예를 들면, streamPlaybackBuffer가 클 때, 전송 가속기는 업링크 트래픽 및 서버 로드를 감소시키기 위해 더 큰 크기의 청크들로 데이터를 요청할 수 있다. 작은 streamPlaybackBuffer의 경우에, 전송 가속기는 더 큰 크기의 청크들로 데이터를 요청하지 않기로 선택할 수 있는데, 왜냐하면 이것은 이러한 경우에 헤드-오브-라인 블로킹(head-of-line blocking )의 위험성을 증가시키기 때문이다(예를 들면, 지연된 청크는 스트림으로 하여금 인터럽트되게 할 수 있음). 일부 전송 가속기 구현들은 X의 streamPlaybackBuffer 값을 X+T로 설정된 requestSoftExpirationTime을 갖는 요청과 대략 동일한 것으로 취급할 수 있고, 여기서 T는 요청이 UA에 의해 수신된 시간이다.
[0079] "requestExpirationTime" 키는 콘텐츠 요청이 만료될 시간, 및 따라서 UA가 더 이상 콘텐츠 요청에 대한 임의의 응답을 수신하는 것에 관심이 없는 시간을 제공할 수 있다. 실시예들의 전송 가속기는, 예를 들면, 콘텐츠 요청이 만료되고 적시에 끝낼 수 없을 때, UA에 대한 연결을 폐쇄할 수 있다.
[0080] "requestSoftExpirationTime" 키는, 전송 가속기가 콘텐츠 요청에 대한 응답을 수신하려고 시도하는 소프트 만료 시간을 제공할 수 있다. 실시예들에 따른 동작에서, requestSoftExpirationTime 데드라인이 지나치면, 전송 가속기는, 예를 들면, 콘텐츠 요청이 드롭되지 않게 할 수 있다. 예를 들면, 콘텐츠는 전송 가속기에 의해 계속해서 페칭될 수 있고, 이로써 전송 가속기가 requestSoftExpirationTime의 만료 전에 요청된 콘텐츠를 획득하려는 자신의 최상의 노력들을 구현할 수 있다는 것을 제외하고, 마치 모든 것이 콘텐츠 요청과 연관된 어떠한 만료 시간도 없는 것과 같다. 실시예들에 따른 동작에서, 전송 가속기는 적절한 요청 전략을 결정하기 위해 그러한 소프트 만료 시간을 활용할 수 있다. 예를 들면, 전송 가속기가 FEC 수리(repair) 데이터를 요청하면, 전송 가속기는 곧 소프트 만료되는 콘텐츠 요청들에 대한 크기 설정 가능한 양의 FEC 데이터를 요청하도록 동작할 수 있는데, 왜냐하면 그렇지 않다면, 그러한 콘텐츠 요청들이 개별적인 청크 요청들을 지연시키는 패킷 손실들이 발생하는 경우에 데드라인을 지나치기 쉬울 것이기 때문이다. 그러나, 미래에 멀리 소프트 만료되는 다른 콘텐츠 요청들에 대해, 전송 가속기는 그러한 콘텐츠 요청들에 대해 더 적은 FEC 데이터를 요청하거나 아예 어떠한 FEC 데이터도 요청하지 않도록 동작할 수 있는데, 왜냐하면 그러한 경우들에서 데이터 재송신이 충분히 빠르게 작동할 수 있고, 이로써 불필요한 FEC 오버헤드를 위한 대역폭을 사용하는 것을 회피하기 때문이다. 실시예들에 따라 사용되는 특정 소프트 만료 시간은, 아래에 추가로 논의되는 바와 같이, 요청 전제 조건들에 따라 변할 수 있다.
[0081] 실시예들의 requestSoftExpirationTime 키의 소프트 만료 시간은 부가적으로 또는 대안적으로 다양한 다른 알고리즘들에 관련하여 사용될 수 있다. 예를 들면, 전송 가속기는 받아들여진 것처럼 보이는 청크 요청들을 취소 및 재발행할 수 있다. 따라서, 전송 가속기는, 관련된 콘텐츠 요청의 소프트 만료 시간이 곧 있을 때 공격적으로 청크 요청들의 그러한 취소 및 재발행을 채용할 수 있고, 만료 시간이 미래에 멀리 있다면, 이것은 더 관대할 수 있다.
[0082] "requestUniqueID" 키는 콘텐츠 요청의 고유한 식별을 제공할 수 있다. 그러한 요청 ID들은, 예를 들면, (예를 들면, UA들에 걸치지 않고) 논의중인 UA 내에서 그리고 단지 하나가 아닌 UA 스트림 내에서 고유한 것으로 선택될 수 있다. 고유한 ID는, 가령, 아래에 논의되는 requestPrerequisites 키에 관련하여 사용하기 위해 UA가 나중에 발행한 특정 콘텐츠 요청을 지칭할 수 있도록 UA에 대한 실시예들에 따라 제공될 수 있다.
[0083] "requestPrerequisites" 키는 특정 콘텐츠 요청에 대한 전제 조건인 요청 ID들의 범위가 정해진 리스트를 제공할 수 있다. 예를 들면, requestPrerequisites 키는 콘텐츠 요청이 발행되는 전제 조건인 요청 ID들의 콤마-분리된 리스트를 포함할 수 있다. 비디오 스트리밍 애플리케이션에서, 예를 들면, I-프레임으로 시작하지 않고, 독립적으로 디코딩 가능하지 않지만 단지 선행하는 프래그먼트 A로 디코딩 가능한 프래그먼트 B에 대한 요청은 프래그먼트 B에 대한 요청에 대한 프래그먼트 A 전제 조건에 대한 요청을 할 수 있고, 이로써 프래그먼트 B 전에 프래그먼트 A가 필요로 된다는 것을 전송 가속기에 표시한다. 그러한 요청 전송 가속기들의 활용에 대한 다른 예는 SHEVC(scalable high efficiency video coding) 비디오 스트리밍 애플리케이션이고, 여기서 기본층에 대한 요청은 제 1 개선층 등에 대한 요청에 대한 전제 조건일 수 있다.
[0084] 전제 조건 정보가 다수의 목적들로 본원의 실시예들에 따라 활용될 수 있다는 것이 인지되어야 한다. 예를 들면, 위의 예들에 도시된 바와 같이, 전제 조건 정보는 스트림 내의 개별적인 콘텐츠 요청들의 바람직한 정렬(ordering)을 통신하는데 활용될 수 있다. 예를 들면, 클라이언트는 요청들의 HTTP 형 순차적인 핸들링을 구현할 수 있고, 이것은 요청의 전임자(predecessor)에 의존하여 각각의 요청을 함으로써 달성될 수 있다. 동일한 것이 스트림 우선순위들과 같이 다른 정보를 사용하여 달성 가능하지 않을 수 있고, 왜냐하면 그러한 다른 정보가 개별적인 콘텐츠 요청들에 속하지 않을 수 있기 때문이다(예를 들면, 스트림 우선순위들이 개별적인 요청들이 아닌 전체 스트림들에 작용함). DASH 클라이언트는, 예를 들면, 비디오 요청들의 스트림을 갖기를 원할 수 있다. 클라이언트가 HTTP 파이프라이닝을 지원하지 않는 HTTP 라이브러리를 사용하지만 클라이언트 자신이 시간 상에서 중첩하는 요청들을 발행하면, 전송 가속기는 상이한 TCP 연결들 상에서 상이한 스트림들에 대한 요청들을 수신할 수 있다. 본원의 실시예들에 따라 제공된 요청 전제 조건들은 서로에 대해 그러한 요청들을 정렬하는 방법을 전송 가속기에 통지하는데 활용될 수 있고, 이로써 클라이언트에서 잠재적으로 무한한 양의 데이터를 버퍼링 및 재정렬할 필요성을 회피한다. 스트림 우선순위 및 UA 우선순위 이외에 요청 우선순위에 대한 이러한 문제를 해결하기 위한 대안적인 기술이 제공될 수 있고, 이로써 이러한 애플리케이션에 대해 요청 종속성들이 필요하지 않을 것이다.
[0085] 실시예들의 전제 조건 정보가 활용될 수 있는 다른 목적은, 하나 이상의 하드 또는 소프트 만료 시간들이 충족될 수 없는 경우에, 작동하는 방법에 대한 정보를 전송 가속기에 제공하는 것이다. 실시예들에 따른 동작에서, 하드 만료들에 대한 거동은 소프트 만료들에 대한 것과 상이할 수 있다.
[0086] 요청 A가 (직접적으로 또는 간접적으로 중 어느 하나로) 요청 B의 전제 조건이고, 요청 A가 하드 만료에 영향을 받는다면, 요청 B가 나중의 만료 시간을 갖더라도(또는 어떠한 만료 시간도 전혀 없음), 요청 A의 하드 만료 시간의 만료는 물론 실시예들에 따라 요청 B에 대한 만료 시간에 만료된다. 요청 A의 하드 만료 시간이 도달되고, 요청 A가 이용 가능하지 않는다면, 앞서 말한 관계가 구현될 수 있고, 이어서 요청 A는 결코 이용 가능하지 않을 것이다. 요청 A가 이러한 예에서 결코 이용 가능하지 않을 요청 B의 전제 조건이기 때문에, 요청 B가 일부 미래 포인트에서 이용 가능할지라도, 이것은 유용하지 않을 것이다.
[0087] 앞서 말한 상황이 발생할 수 있는 예는 SHEVC 라이브 비디오 플레이어에 관련된다. SHEVC 디코더는 그 후에 200 ms 재생될 규정된 시간에(예를 들면, 디코더가 다음 초의 비디오 데이터를 수신하는 초마다) 다음의 비디오 섹션, 가령, 다수의 개선층들을 갖는 기본층을 수신할 수 있다. 따라서, 플레이어에 제공된 데이터는 기본층 및 다수의 개선층들이다. 그러나, 비디오 데이터가 디코더로 전송된 이전 시간에서 사용된 바와 같이 사용될 수 있는 많은 개선층들로서 매초마다 최대한으로 갖는 제한이 존재한다. 이것은 다음의 풀 리프레시 세그먼트가 돌아올 때까지 반복되고, 이러한 포인트에서 다시 임의의 계층들이 디코더에 제공될 수 있다(예를 들면, 매 5 번째 세그먼트가 그러한 리프레시일 수 있음). 스트리밍 모듈은 1.2 초에 재생될 기본층 B1 및 개선층 E1을 요청하고, 따라서 하드 만료 시간을 1로 설정할 수 있다. 이어서, 나중에, 스트리밍 모듈은 2.2 초에 재생될 기본층 B2 및 개선층 E2를 요청하고, 따라서 그들의 하드 만료 시간을 2.0으로 설정할 수 있다. 요청 종속성들은, E2가 E1 없이 유용하지 않고, E1이 적시에 수신되지 않는다면 전송 가속기가 E2를 페칭하지 않아야 한다는 것을 전송 가속기에 전달하는데 사용될 수 있다. 이것은 E1에 의존하여 E2를 태깅함으로써 본원의 실시예들에 따라 달성될 수 있다(E2에 대한 요청이 발행되는 시간에서, E1이 성공적인지 여부를 전송 가속기가 알 수 없다는 것이 인지됨).
[0088] 그러한 요청 종속성들은 앞서 말한 예들에 도시된 바와 같이 하드 만료들에 관련하여 유용할 뿐만 아니라, 소프트 만료들에 관련하여 유용하다. 소프트 만료들에 관련하여 요청 종속성들의 활용의 예로서, UA는 2 개의 요청들 A 및 B를 발행할 수 있고, 요청 A는 요청 B의 소프트 만료 시간 전에 소프트 만료 시간을 갖는다. 요청 B가 요청 A에 의존하는 경우에, 전송 가속기가 자신의 소프트 만료 시간까지 요청 A를 다운로드하는데 실패하면, 그럼에도 불구하고 전송 가속기는 (예를 들면, 요청 B의 소프트 만료 시간까지, 왜냐하면 그제서야 전송 가속기가 요청 B의 소프트 만료 데드라인을 만족시킬 것이기 때문에) 요청 B와 함께 요청 A를 여전히 완료하려고 시도할 수 있다. 더 일반적으로 말하자면, 실시예들의 전송 가속기 내에서 요청 A에 대해 사용된 실제 유효 소프트 만료 시간은 요청 A 및 그의 직접적인 그리고 간접적인 종속 요청들(예를 들면, 앞서 말한 예에서 요청 B)의 태깅된 소프트 만료 시간들 중 최소치일 수 있다.
[0089] 소프트 만료들에 관련하여 요청 종속성들의 사용을 추가로 예시하자면, SHEVC 비디오 클라이언트가 다시 고려된다. 시간 1에서, UA는 세그먼트 1, 단지 기본층 B1, 또는 기본 및 개선층들의 조합 B1+E1 중 어느 하나를 재생할 수 있다. 따라서, B1에 대한 요청은 소프트 만료 시간 1을 통해 발행될 수 있고, E1에 대한 다른 요청은 또한 시간 1에서 소프트 만료되고, B1은 E1의 전제 조건으로서 선언된다. 시간 2에서, UA는 세그먼트 2, 단지 기본층 B2, 또는 기본 및 개선층들의 조합 B2+E2 중 어느 하나를 재생할 수 있다. 따라서, B2에 대한 요청은 소프트 만료 시간 2를 통해 발행될 수 있고, E2에 대한 다른 요청은 또한 시간 2에서 소프트 만료되고, B2는 전제 조건으로서 B1을 갖는 것으로 선언되고, E2는 전제 조건으로서 B2 및 E1 둘 모두를 갖는 것으로 선언된다(예를 들면, 이러한 예에서 E2는 재생 가능하기 위해 B2 및 E1 둘 모두를 필요로 함). B1이 시간 1에서 수신되지만 E1이 수신되지 않는 경우에, 플레이어는 개선층 E1 없이 시간 1에서 기본층 B1을 재생할 수 있다. 따라서, 실시예들의 전송 가속기는 시간 2까지 E1, B2 및 E2 모두를 다운로드하려고 시도할 수 있는데, 왜냐하면 모든 유효 소프트 만료 시간들이 이제 2이기 때문이다. 전송 가속기가 E1, B2 및 E2 모두를 다운로딩하는데 성공하면, 플레이어는 시간 2에서 B2+E2의 조합을 재생할 수 있는데, 왜냐하면 이러한 계층들을 디코딩하기 위한 모든 전제 조건들이 정확히 이용 가능할 것이기 때문이다.
[0090] 소프트 만료 시간들의 예와 하드 만료 시간들의 이전의 예 사이의 차이는, 하드 만료 예에서, 디코더가 재생 시간을 "따라잡을 수 없다(catch up)"고 추정된다는 것이다(예를 들면, 플레이어는 자신이 적시에 수신하는 임의의 계층들만을 사용할 수 있음). 소프트 만료 예에서, 반면에, 그럼에도 불구하고, 자신의 소프트 만료 시간 후에 수신된 요청들이 종속 요청을 디코딩하는데 사용될 수 있다고 추정된다(예를 들면, E1이 자체 재생을 위한 시간에 수신되지 않을지라도, E1 및 E2가 E2의 재생 시간 바로 전에 수신되는 한, E1이 E2를 디코딩하는데 사용될 수 있음).
[0091] 위의 표 2에 제시된 예시적인 시그널링이 몇몇의 방식들에서 표 1의 것과 상이하다는 것이 인지되어야 한다. 하나의 주목할 만한 차이는, 스트림들의 개념이 표 2의 시그널링에서 명백히 제공된다는 것이다. 많은 특성들은 개별적인 요청들보다는 스트림들에 관련되고, 따라서 스트림마다 기반하여 설정될 수 있다. 예를 들면, 비트레이트는 단일 짧은 요청에 관련하여 정확히 설정하기에 어려울 수 있지만, 이것은 요청들의 스트림에 관련하여 시행하기에 더 쉽고 더 중요할 수 있다.
[0092] 표 2의 시그널링에 제공된 다른 차이에서, 콘텐츠 요청들은 "소프트하게" 만료할 수 있고, 이로써 만료 시간은 콘텐츠 요청을 무효화하지 않는다. 선택적인 요청 종속 정보는 표 2의 시그널링에서 다른 차이로서 부가되었다. 그러한 종속 정보는, 예를 들면, 비디오 스트리밍 애플리케이션들에서 유용할 수 있다.
[0093] 표 1의 예시적인 시그널링과 비교될 때, 다음의 키들: streamingBitrate (streamBitrate로 대신됨) 및 streamingPlaybackBuffer(streamPlaybackBuffer로 대신됨)는 실시예들에 따라 표 2의 예에 제공된 시그널링에서 상이한 키들로 대체 또는 대신될 수 있다. 표 1의 예시적인 시그널링의 requestPriority 키는 실시예들의 표 2의 예시적인 시그널링의 streamPriority 키로 대체되거나 이것 이외에 사용될 수 있다.
[0094] 앞서 말한 시그널링 예들이 UA에 의해 전송 가속기에 제공되는 시그널링을 참조하여 설명되었지만, 본원의 실시예들의 전송 가속기 기능에 관련하여 구현된 시그널링은 전송 가속기로부터 UA로의 시그널링을 포함한다. 예를 들면, 실시예들의 TA(120)는 UA(129a)가 본원의 개념들에 따른 다양한 시그널링을 표시하는 것에 대한 하나 이상의 응답들에 특수 응답 헤더(본원에서 "QC-STA-응답 헤더"로 지칭됨)를 포함할 수 있다. QC-STA-응답 헤더의 형태는, 앞서 설명된 바와 같이, 콘텐츠 요청의 QC-STA 헤더의 것과 동일할 수 있다.
[0095] 아래의 표 3은, 본원의 실시예들의 QC-STA-응답 헤더에 관련하여 활용될 수 있는 키들, 값들의 타입들, 및 키들의 가능한 값들의 예들을 제공한다.
표 3
키 의미 키의 값들 및 타입들
requestAccelerated 요청이 TA에 의해 가속화되었는지를 표시함. "y", "n"(스트링)
requestEstimatedReceiveRate 요청이 이루어진 서버에 대한 요청들에 대한 예상된 레이트를 표시함(예컨대, Kbps 단위). (무부호 정수)
numberOfSupportedPriorities 지원되는 별개의 requestPriority 값들의 수. (무부호 정수)
usedHTTPS 서버에 대한 SSL/TLS 연결을 사용하여 서브-요청들을 전송하는데 있어서 TA가 성공하였는지를 표시함. "y", "n"(스트링)
[0096] 본원의 QC-STA-응답 헤더의 실시예들에 따라 활용될 수 있는 상술된 키들의 추가의 설명에 의해, "requestAccelerated" 키는 콘텐츠 요청이 가속화되는지 여부를 표시할 수 있다. 그러한 정보는 어떠한 요청들이 가속을 발생시킬 수 있는지 또는 발생시킬 수 없는지를 "학습"하고, 요청된 데이터의 가속화된/비-가속화된 전달에 관련하여 적절하거나 최적화된 동작에 대한 하나 이상의 속성들을 조절하고 기타 등등을 위해 UA에 의해 활용될 수 있다.
[0097] "requestEstimatedReceiveRate" 키는 (예를 들면, 충분히 큰 양의 데이터가 요청될 때) 콘텐츠 요청이 이루어지는 서버에 대해 달성될 수 있는 레이트의 추정을 표시할 수 있다. 예를 들면, 적응형 스트리밍 클라이언트는 재생을 위해 선택하기 위한 양호한 표현을 결정하기 위한 이러한 정보를 사용할 수 있다. 실시예들에 따른 동작에서, 전송 가속기는, 자신이 이러한 서버에 대해 과거에 달성할 수 있었던 레이트들의 이력에 기초하여 그러한 수신 레이트의 추정을 계산할 수 있다. 부가적으로 또는 대안적으로, 전송 가속기는 사용된 네트워크 인터페이스를 통해 달성 가능한 레이트의 추정을 사용할 수 있다. 따라서, 그러한 추정은 달성 가능한 레이트에 관한 이력 정보를 통해 실시예들에 따라 획득될 수 있다.
[0098] "numberOfSupportedPriorities" 키는 전송 가속기가 지원하는 별개의 우선순위 값들의 수를 표시하는데 사용될 수 있다. 그러한 정보는 전송 가속기에 의해 지원되는 범위 내에 속하도록 자신의 콘텐츠 요청들에 할당되는 우선순위들을 조절하는데 있어서 UA에 의해 활용될 수 있고, 이로써 각각의 그러한 콘텐츠 요청에 관련하여 적절한 상대적인 우선순위 처리를 보장한다.
[0099] "usedHTTPS" 키는, 전송 가속기가 콘텐츠 요청에 관련하여 콘텐츠 서버에 대한 보안 링크를 설정하는데 성공하였는지를 표시하는데 사용될 수 있다. UA는, 예를 들면, 전송 가속기가 보안 통신들을 설정하는데 성공하지 않았다는 것을 전송 가속기가 보고하는 경우에, 가령, I/O 엘리먼트(113)를 통해 직접적으로 보안 통신들을 설정하려고 시도하기 위해, TA(120)의 선택적으로 가속 포트보다는 I/O 엘리먼트(113)의 포트로 콘텐츠 요청들을 송신하도록 선출할 수 있다.
[00100] 본원의 개념들에 따라 UA들에 의해 요청된 원하는 콘텐츠의 프래그먼트들 또는 프래그먼트들의 시퀀스들의 개선된 전달을 제공하기 위해 UA와 전송 가속기 사이에 제공될 수 있는 다양한 시그널링의 예들이 제공되면, 본원에 실시예들에 따른 그러한 시그널링의 예시적인 사용들에 관련하여 추가의 세부사항이 아래에 설명된다. 그러나, 제공되는 예들이 본원의 개념들에 따른 그러한 시그널링의 활용을 총망라한 것이 아니라는 것이 인지되어야 한다.
[00101] 가령, 앞서 말한 streamingBitRate 및/또는 streamBitRate 키들에 의해 제공되는 비트레이트 정보를 활용하는데 있어서, TA(120)의 스케줄링 알고리즘은 공정하게 상이한 비트레이트 스트림들을 공유하는 것을 허용하기 위해 청크 요청들을 스케줄링하도록 적응될 수 있다(예를 들면, 400 Kbps 스트림은 100 Kbps 스트림보다 대략 4 배 많은 청크 요청들을 수신할 수 있음). 따라서, 그러한 스케줄링 알고리즘은 주어진 스트림의 비트레이트를 제한할 수 있고, 이로써 대역폭 중 일부를 획득하기 위한 기회를 더 낮은 우선순위 스트림들에 제공한다.
[00102] 가령, requestExpirationTime 및 requestSoftExpirationTime 키들에 의해 제공되는 상술된 만료 시간 정보는 다음의 알고리즘들 중 하나 이상에 따라 청크 요청들을 스케줄링하는데 실시예들의 TA(120)에 의해 사용될 수 있다. 전송 가속기 청크 요청 제한 알고리즘은, 예를 들면, 낮은 레이턴시 라이브 스트리밍 상황에서 사용될 수 있다. 실시예들에 따른 그러한 알고리즘의 활용을 넘어서 기본적인 아이디어는, 콘텐츠 요청이 일정 시간 Te에서 만료되는 것으로 알려지면, Te에 너무 가까운 청크 요청들에 대한 응답들이 시간 Te까지 반환될 가능성이 없을 것이기 때문에, Te 전에 짧은 시간에 그 콘텐츠 요청에 대한 새로운 청크 요청들을 발행하는 것을 중단하는 것이 이로울 수 있다. 그러한 알고리즘의 구현의 효과는, 만료 시간 바로 전에, 전송 가속기가 다른 콘텐츠 요청들을 프로세싱으로 이동할 수 있고 이로써 만료할 콘텐츠 요청들에 대한 덜 낭비되는 청크 요청들로 이어진다는 것이다.
[00103] 그러한 전송 가속기 청크 요청 제한 알고리즘은 다음에 따라 표현될 수 있다.
T를 현재 시간으로 놓고,
Te를 고려중인 UA 요청의 만료 시간으로 놓고,
Tstart를, 응답의 시작이 수신될 때까지 청크 요청이 발행되는 때로부터의 평균 시간으로 놓고(이것은 큐잉 지연을 포함하는 RTT(round trip time)의 추정치임),
Tend를, 청크 응답이 완료될 때까지 청크 요청 발행 시간으로부터의 평균 시간으로 놓고(Tstart 및 Tend는, 가령, RM(121) 내의 EWMA(exponentially-weighted moving average) 추정기들을 통해 측정될 수 있음),
cs 및 ce를 구성 상수들로 놓고,
T + cs*Tstart + ce*Tend >= Te이면, 주어진 UA 콘텐츠 요청에 대한 임의의 추가의 청크 요청들을 발행하지 않는다.
앞서 말한 예에서, cs 및 ce는 전형적으로 cs, ce>=0 및 cs+ce=1이도록 선택될 수 있다. cs 및 ce에 대한 일부 가능한 선택들이 아래의 표 4에 제시된다.
표 4
cs ce 대응하는 정책
1 0 부분적인 청크 응답이 Te까지 돌아올 가능성이 있는 한 청크 요청들을 발행
0 1 완전한 청크 응답이 Te까지 돌아올 가능성이 있는 한 청크 요청들을 발행까지 돌아올 가능성이 있는 한 청크 요청들을 발행
0.5 0.5 약 절반의 청크 응답이 Te까지 돌아올 가능성이 있는 한 청크 요청들을 발행
[00104] 앞서 말한 전송 가속기 청크 요청 제한 알고리즘의 변형예에서, F(t)는 청크 요청에서 완료하는데 t 또는 미만의 시간이 걸릴 수 있는 확률이다. 따라서, F(0)=F(네거티브 값)=0, F(무한대)=1 그리고 F는 단조적으로 증가한다. F가 전형적으로 알려지지 않지만, F의 파라미터 또는 비파라미터 추정이 이루어질 수 있다. 전송 가속기 청크 요청 제한 알고리즘에 대한 이러한 변형예는 다음에 따라 표현될 수 있다.
T를 현재 시간으로 놓고,
Te를 고려중인 UA 요청의 만료 시간으로 놓고,
pthresh를 구성 상수로 놓고,
F(Te - T) < pthresh이면, 주어진 UA 요청에 대한 어떠한 추가의 청크 요청들도 발행하지 않는다.
앞서 말한 pthresh 구성 상수는 0과 1 사이의 일정 적절한 값으로 선택될 수 있고, F가 추정되는 방법에 따라, 제한 값들 0 또는 1이 또한 분별 가능할 수 있다.
[00105] 동작 시에, 위의 예들에 제공된 전송 가속기 청크 요청 제한 알고리즘들은, 콘텐츠 요청이 막 하드 만료하려고 할 때까지 콘텐츠 요청에 대한 청크 요청들을 계속해서 전송할 것이다. 채널 레이트가 대략 알려질 때, 본원의 실시예들에 따라 동작 가능한 전송 가속기는, 콘텐츠 요청이 자신의 하드 만료 시간 전에 성공하지 않을 것이라고 훨씬 앞서 결론을 내릴 수 있고, 따라서 그에 대한 임의의(또는 추가의) 청크 요청들을 요청함으로써 대역폭을 낭비하지 않는다. 따라서, 그러한 전송 가속기 실시예들은 하드 만료 데드라인이 충족될 수 없는 요청을 포기하기 위한 알고리즘을 구현할 수 있다. 요청 하드 만료에 기초한 그러한 알고리즘은 다음을 통해 표현된다.
Te를 고려중인 요청에 대한 만료 시간으로 놓고,
S를 고려중인 요청의 크기로 놓고(크기가 알려지지 않은 경우에, 추정이 사용될 수 있음),
V를 고려중인 요청에 대해 이미 요청된 바이트들의 수로 놓고,
ca를 구성 가능한 상수로 놓고(예를 들면, ca=1),
R을 (고려중인 콘텐츠 요청에 대한) 다운로드 레이트의 추정으로 놓고,
Tstart를, 응답이 들어오기 시작할 때까지 청크 요청 이슈 시간으로부터의 시간의 추정으로 놓고(이것은 위의 예시적인 알고리즘으로부터의 Tstart와 동일할 수 있음),
d := Te - (T + Tstart)로 놓고,
ca*d*R < S-V이면, 고려중인 콘텐츠 요청에 대한 청크 요청들을 발행하지 않는다.
ca에 대한 일부 가능한 선택들이 아래의 표 5에 제시된다. 요청에 대해 포기하는 것이 일반적으로 바람직하지 않기 때문에, ca>=1의 선택들은 전형적으로 유리할 것이다.
표 5
ca 대응하는 정책
1 요청이 현재 다운로드 레이트로 완료될 수 없다면, 더 많은 청크 요청들을 발행하지 않음.
2 현재 레이트 두 배의 경우에, 요청이 완료될 수 없다면, 더 많은 청크 요청들을 발행하지 않음.
3 현재 레이트 절반의 경우에, 요청이 완료될 수 없다면, 더 많은 청크 요청들을 발행하지 않음.
[00106] 레이트 R이 시간에 걸쳐 변할 수 있다. 그럼에도 불구하고, 위의 알고리즘이 청크 요청들이 주어진 시점에서 발행되는 것을 방지하면, 이것은 나중 시간에 이것을 방지할 수 없다.
[00107] 실시예들은 requestSoftExpirationTime 키에 의해 제공되는 것들과 같이, 소프트 만료 시간들과 연관하여 FEC 알고리즘들을 구현할 수 있다. 예를 들면, 콘텐츠 요청들에 대한 FEC 데이터가 이용 가능하면, 실시예들은 소프트 만료 시간이 곧 있을 때 더 공격적으로 FEC 데이터를 요청하도록 동작할 수 있다. 그러한 알고리즘은 근본적인 채널 조건들로 조절할 수 있다(예를 들면, 에러 확률이 낮을 때, 만료가 곧 있을지라도, 적은 오버헤드가 요청될 수 있음).
[00108] 가령, streamPriority 키를 통해, 실시예들에 따라 제공될 수 있는 별개의 스트림 우선순위들의 수는 꽤 클 수 있다(예를 들면, 2^32). 그러한 많은 수의 우선순위들은, 가령, 각각의 콘텐츠 요청이 상이한 우선순위로 송신되도록 허용하기 위해, 일부 애플리케이션들에 관련하여 유용할 수 있다. 그러한 경우에 이용 가능한 우선순위 값들의 세트를 총망라하지 않기 위해, 많은 수의 상이한 우선순위 값들이 전송 가속기로 통신될 수 있다. 또한, 전송 가속기가 백엔드로서 HTTP/2.0을 사용하면, 클라이언트는 HTTP/2.0에 의해 지원되는 완전한 세트의 우선순위들을 사용하도록 인에이블될 수 있다. 따라서, 본원의 실시예들은 더 작은 세트들로의 우선순위 맵핑을 제공하기 위한 알고리즘들을 구현하고, 이로써 그러한 큰 별개의 우선순위들의 사용을 수용할 뿐만 아니라 상호 운용 가능성을 가능하게 한다. 다양한 기술적인 이유들로, 전송 가속기의 일부 구현들은 모든 가능한 우선순위 값들(예를 들면, 2^32)을 내부적으로 지원하지 않을 수 있다. 그러한 경우에, 값들을 내부적으로 지원되는 우선순위들의 더 작은 세트로 맵핑하기 위한 우선순위 맵핑 알고리즘이 제공될 수 있다. 그러한 우선순위 맵핑이 이루어질 수 있는 많은 방식들이 존재하지만, 예시적인 실시예가 아래에 제공된다. 다음의 예가 외관상 복잡할 수 있지만, 다음의 논의로부터 더 양호하게 이해될 바와 같이, 이것은 구현될 수 있는 다른 맵핑 기술들에 비해 이점들을 갖는다는 것이 인지되어야 한다.
[00109] 전송 가속기가 0,..., N-1로부터의 N 개의 별개의 내부 우선순위들을 지원하는 경우에, 다음의 알고리즘은 주어진 32 비트 우선순위 P에 대한 내부 우선순위로의 맵핑을 제공한다.
Figure 112017029999460-pct00002
[00110] 대부분의 클라이언트들은 2^32 개의 별개의 우선순위들을 필요로 하지 않고, 따라서 가능하게는 단지 M 개의 별개의 우선순위들의 훨씬 더 작은 세트를 활용할 수 있다. 그러한 경우에, 클라이언트는 가능한 요청 우선순위들 0,..., M-1을 가질 수 있다. 0,..., M-1 범위의 주어진 우선순위 clientInternalPriority에 대한 2^32 비트 정밀도 우선순위 P'를 계산하기 위해, 다음의 알고리즘이 사용될 수 있다.
Figure 112017029999460-pct00003
[00111] 앞서 말한 우선순위 맵핑 기술들은 상호 운용 가능성을 제공할 뿐만 아니라, 다른 가능한 우선순위 맵핑 기술들에 비해 장점들을 제공한다. 예를 들면, 위의 예시적인 실시예들의 우선순위 맵핑은, 전송 가속기가 적어도 애플리케이션이 요구하는 만큼 많은 별개의 우선순위들을 지원하는 한(즉, N>=M인 한), 우선순위 정렬이 정확히 보존되는 경우에, 별개의 클라이언트 우선순위들이 별개의 전송 가속기 우선순위들로 맵핑되는 것을 보장할 수 있다. 클라이언트가 전송 가속기의 N의 내부 값을 알지 못하거나, 전송 가속기가 클라이언트의 M의 값을 알지 못하는 경우에, 이러한 우선순위 맵핑이 작동한다는 것이 주목된다. 또한, 클라이언트가 (예를 들면, 할당
Figure 112017029999460-pct00004
을 사용함으로써) 우선순위들을 할당하는 다른 방식을 사용하면, 그럼에도 불구하고 선택된 할당이 값들을 2^32 범위로 확산시키는 한, 예시적인 실시예들에 따른 우선순위 맵핑은 비교적 잘 작동할 것이다.
[00112] 앞서 말한 것으로부터 인지될 수 있는 바와 같이, 특정 콘텐츠, 특정 콘텐츠 요청들 등에 관련하여 전송 가속기 동작을 요청하기 위한 UA와 TA 사이의 시그널링이 구현될 수 있다. 일부 실시예들에 따른 동작에서, TA는 전송 가속 기능에 대한 요구를 표시하는 그러한 시그널링의 존재를 검출하고, 따라서 전송 가속 기능을 제공할 수 있다. 그러나, 콘텐츠 요청들에 관련하여 전송 가속 동작을 가능하게 하는데 사용될 수 있는 시그널링이 본원의 실시예들에 따라 TA에 대해 이루어지지만, 그럼에도 불구하고 본원의 실시예들이 그러한 콘텐츠 요청들에 관련하여 전송 가속 동작을 선택적으로 제공하도록 동작한다는 것이 인지되어야 한다. 즉, 그 전송 가속을 요청하는 시그널링을 UA로부터 검출하는 것이 특정 콘텐츠 또는 특정 콘텐츠 요청에 관련하여 요구되지만, 실시예들의 TA는, 전송 가속 기능의 구현이 시그널링된 요청에 응답하여 실제로 구현되는지를 결정하도록 동작할 수 있다. 예를 들면, 선택적으로 가속 포트로 전송되는 콘텐츠 요청은, 콘텐츠 요청이 가속화될지 여부를 결정하기 위해 전송 가속기에 의해 추가 세트의 규칙들에 영향을 받을 수 있다.
[00113] TA 제어(125)의 로직에 의해 구현될 수 있는 요청 디스패처는, 콘텐츠 요청의 가속을 가속 또는 우회할 때를 결정하는데 사용되는 하나 이상의 규칙들을 생성하기 위해 콘텐츠 요청 또는 그의 양상들을 분석(예를 들면, 요청-URI, 헤더 필드들, 및 콘텐츠 요청 및/또는 응답 메시지들의 다른 엘리먼트들을 파싱)하도록 동작할 수 있다. 그러한 규칙들은, 예를 들면, 특정 키 워드/구 패턴들의 존재에 대한 체크들을 제공할 수 있다. 실시예들에 따른 동작에서, 그러한 규칙들은 배제 리스트를 제공하는데 활용되고, 이로써 배제 리스트는, 만족될 때, 콘텐츠 요청이 가속화되지 않을 것이라는 결정을 발생시키는 블랙리스트 규칙들의 세트를 포함한다(예를 들면, HTTP 버전, 메시지 방법, 요청된 파일 접미사들, 헤더들, 및 (서버, 자원) 튜플 등에 대한 체크들의 세트를 수반함).
[00114] 앞서 말한 것에 따라, 도 1에 예시된 실시예는 통신 세션들에 관련하여 선택적인 전송 가속기 동작을 제공하도록 본원의 개념들에 따라 적응된 TA 제어(125)를 포함한다. 위에 설명된 바와 같이, TA 제어(125)는, 프로세서(예를 들면, 프로세서(111))에 의해 실행될 때, 본원에 설명된 바와 같이 동작 가능한 로직 회로들을 제공하는, 메모리(112)에 저장될 수 있는 컴퓨터 판독 가능 코드 세그먼트들로서 구현될 수 있다. TA 제어(125)는 본원에 설명된 동작을 위한 필요한 기능을 제공하도록 동작 가능한 예시된 실시예의 분석/제어 로직(126)과 같은 하나 이상의 기능 블록들을 포함할 수 있다. 클라이언트 디바이스(110) 내에 배치되는 것을 도시되지만, 실시예들이 TA 제어 기능의 상이한 구성들을 채용할 수 있다는 것이 인지되어야 한다. 예를 들면, TA 제어(125)의 일부 부분은 서버(130)에 배치된 분석/제어 로직(126) 및/또는 클라이언트 디바이스(110)와 통신하는 다른 프로세서-기반 시스템과 같이, 클라이언트 디바이스(110) 외부에 배치될 수 있고, 한편 다른 부분은 클라이언트 디바이스(110)에 배치된다. 마찬가지로, TA 제어(125) 또는 그의 부분들은 예시된 실시예에 도시된 바와 달리 클라이언트 디바이스(110) 내에 배치될 수 있다. 예를 들면, TA 제어(125) 또는 그의 일부 부분(예를 들면, 분석/제어 로직(126))은 실시예들의 TA(120) 내에 배치될 수 있다.
[00115] 실시예들의 TA 제어(125)는 전송 가속이 제공되는 메시지들 및 전송 가속이 제공되지 않는 메시지들 사이를 구별하도록 동작하고, 이로써 선택적인 전송 가속기 동작을 제공한다. 예를 들면, 위에 논의된 바와 같이, TA(120)는 전송 가속을 가능하게 하기 위해 프래그먼트 요청들을 청크 요청들로 세분화(예를 들면, 시간 상에서 적절한 시간들에서 서버로 전송되도록 HTTP 요청들을 더 작은 요청들로 부수도록)하도록 동작할 수 있다. 그러나, 그러한 더 작은 청크 요청들의 사용은 모든 상황들에서 원하는 동작을 제공하지는 않을 수 있다. 요청들을 더 작은 요청들로 부수고, 그러한 더 작은 요청들을 서빙하는 동작은 그와 연관된 오버헤드를 갖는다. 일부 경우들에서, 가령, 요청된 콘텐츠를 저장하는 파일들이 자체로 작은 경우에, 증가된 오버헤드는 가속화되지 않는 데이터의 송신을 발생시킬 수 있다. 마찬가지로, 요청들 사이에 특정 종속성들이 존재하는 경우에, 가령, 나중에 다운로딩되는 것으로 예상되는 콘텐츠에 대한 전제 조건들인 작은 파일들이 존재하는 경우에, 세분화된 요청을 하기 위한 동작은, 임계 시간이 종속성 그래프에서 상실되고 콘텐츠가 시도된 가속으로 인해 더 느리게 재조립되도록(예를 들면, 결과적인 웹 페이지가 렌더링됨), 이러한 상호 의존적인 콘텐츠에 관련하여 요청들을 분할할 수 있다. 다른 예로서, 청크 요청들이 바이트 범위 요청들을 사용하여 이루어질 수 있고, 반면에 서버는 바이트 범위 요청들을 지원하지 않을 수 있다(예를 들면, 요청에서 지원되지 않는 바이트 범위 정보를 무시하고, 각각의 청크 요청에 응답하여 완전한 파일을 반환함). 그러한 상황들은, 전송 가속을 제공하는데 실패하지만, 증가된 네트워크 혼잡을 발생시킬 수 있다.
[00116] 따라서, TA 제어(125)의 로직은 TA(120)의 선택적으로 가속 포트에 대해 이루어진 콘텐츠 요청들(예를 들면, QC-STA 헤더가 포함되는 그러한 콘텐츠 요청들, 이로써 UA가 가속화되는 콘텐츠 요청을 갖기를 원한다는 것을 표시함)을 분석하도록 동작할 수 있다. 예를 들면, 분석/제어 로직(126)은 콘텐츠 요청으로부터 또는 그와 연관하여 하나 이상의 가속 선택 속성들을 획득하고, 전송 가속이 특정 메시지 또는 통신 세션에 관련하여 TA(120)에 의해 제공되는지를 결정할 수 있다. 이후에, 분석/제어 로직(126)은, 앞서 말한 결정에 기초하여, 그 메시지 또는 통신 세션에 TA(120)에 의해 전송 가속 동작이 제공되거나 전송 가속 동작이 제공되지 않기 위한 요청들을 발생시키게 하는 시그널링을, 가령, TA 제어(125)를 통해 TA(120)(및/또는 그와 연관된 라우팅 블록)에 제공할 수 있다. 어느 상황에서, TA(120)는, 요청 또는 그의 부분들(예를 들면, 청크들)을 서버(130)로 전달하기 전에, 전송 가속 시그널링(예를 들면, 상술된 QC-STA 헤더)의 콘텐츠 요청을 스트리핑하도록 동작할 수 있다. 또한, TA(120)는 가속 결정의 상태를 표시하고 그리고/또는 그의 동작에 관련하여 정보를 제공하기 위한 시그널링을 UA(129a)에 제공하도록 동작할 수 있다.
[00117] 도 2a의 흐름도는 본원의 실시예들에 따른 선택적인 전송 가속기 동작을 제공하기 위한 TA 제어(125)의 동작을 예시한 흐름(200)을 도시한다. 예시된 실시예의 블록(201)에서, TA(120)의 선택적으로 가속 포트에 대해 이루어지는 콘텐츠 요청은, 요청이 전송 가속 동작을 수신하는 것이라는 것을 표시하는 시그널링이 존재하는지를 결정하도록 분석된다. 예를 들면, 분석/제어 로직(126)은, 전송 가속기 기능이 제공되는 것이 콘텐츠 요청인 것을 표시하는, 콘텐츠 요청과 포함되는 헤더 정보(예를 들면, 본원의 전송 가속기 동작에 대해 고유한 HTTP 헤더)를 분석하도록 동작할 수 있다. 요청이 전송 가속 동작을 수신하는 것이라는 것을 표시하는 시그널링은 임의의 다양한 적절한 방식들로 콘텐츠 요청에 포함될 수 있고, 예를 들면, 시그널링은 HTTP 요청의 특수 헤더일 수 있고, HTTP 요청의 헤더의 필드 값으로서 포함될 수 있고, HTTP 요청의 URI 또는 URL의 질의 스트링의 하나 이상의 파라미터들에 포함될 수 있고 그리고/또는 본원의 실시예들에 따라 콘텐츠 요청의 임의의 다른 적절한 특징으로서 포함될 수 있다. 콘텐츠 요청에 관련하여 전송 가속이 요구된다는 것을 표시하는 시그널링이 존재하지 않는다면, 예시된 실시예에 따른 프로세싱은 블록(202)으로 진행되고, 여기서 (TA(120)의 선택적으로 가속 포트에 제공되었지만) 요청은 가속 동작이 TA(120)에 의해 제공되지 않고서 서버(130)로 전달된다.
[00118] 그러나, 콘텐츠 요청에 관련하여 전송 가속이 요구된다는 것을 표시하는 시그널링이 존재하면, 그러한 전송 가속 프로세싱은 실시예들에 따라 제공될 수 있거나 제공될 수 없다. 따라서, 이러한 경우에, 예시된 실시예에 따른 프로세싱은 블록(203)으로 진행되고, 여기서 하나 이상의 가속 선택 속성들은 TA(120)의 하나 이상의 기능들을 선택적으로 구현하는데 사용하기 위해 TA 제어(125)의 로직에 의해 획득된다. 예를 들면, TA 제어(125)의 로직은 요청(예를 들면, 프래그먼트 및/또는 청크 요청) 자체로부터 하나 이상의 가속 선택 속성들을 획득할 수 있다. 가속 선택 속성들은 콘텐츠 서버로부터 콘텐츠에 대한 사용자 에이전트의 요청의 속성, 콘텐츠 서버의 속성 등을 포함할 수 있다.
[00119] 요청으로부터 하나 이상의 가속 선택 속성들을 획득하는데 있어서, TA 제어(125)의 로직은 가속 선택 속성들에 관련하여 정보를 식별하기 위해 다양한 양상들의 요청들, 요청들에 관련하여 활용되는 통신 프로토콜들, 요청들 내의 데이터 등을 분석하도록 동작할 수 있다. 예를 들면, TA 제어 로직은 가속 선택 속성들을 식별하는데 유용한 정보를 식별하기 위해 URI와 같은 그러한 정보, 사용자 에이전트 필드들, 바이트 범위 또는 콘텐츠 길이 필드들 등을 분석하도록 동작할 수 있다. 실시예들에 따른 동작에서, TA 제어 로직은 요청의 프로토콜 타입(예를 들면, HTTPS, HTTP1.0, HTTP2.0 등), 요청과 연관된 통신 세션의 특성들(예를 들면, spdy_enabled, qulc_enabled, upstream_proxy_configured 등), 이루어진 요청의 타입(예를 들면, HTTP GET, PUT, POST, TRACE, OPTIONS 등), 요청 내의 헤더 정보(예를 들면, 다수의 범위들을 갖는 바이트 범위 헤더 존재, 인가 헤더 존재 등) 등을 결정하기 위해 요청을 분석할 수 있다. 실시예들에 따른 동작에서, 사용자 에이전트 필드는 가속 가능한 트래픽을 식별하기 위해 특수 값으로 파퓰레이팅될 수 있다. 부가적으로 또는 대안적으로, TA 제어(125)의 로직은 상술된 시그널링에 제공된 또는 그와 연관된 정보를 분석하도록 동작할 수 있다. 예를 들면, fileType, priority, streamingBitRate, streamingPlaybackBuffer, 및 requestExpirationTime과 같이, QC-STA 헤더에 제공된 상술된 키들 중 하나 이상에 의해 제공된 정보는 본원의 실시예들에 따라 가속 선택을 위해 분석될 수 있다.
[00120] 하나 이상의 가속 선택 속성들을 획득하면, 예시된 실시예의 흐름(200)에 따른 동작은 블록(204)으로 진행되고, 여기서 TA 제어(125)의 로직은 TA 제어 로직에 의해 획득된 하나 이상의 가속 선택 속성들에 기초하여 TA(120)의 기능의 선택적인 호출(invocation)(예를 들면, 전송 가속 동작을 선택적으로 인보크하는 것)을 제어한다. TA 제어(125)의 로직의 제어 하에서 TA(120)의 기능의 선택적인 호출은 전송 가속기의 로직으로 하여금 상술된 기능을 사용하여 콘텐츠 서버로부터 콘텐츠를 획득하게 하거나, 전송 가속기의 로직으로 하여금 상술된 기능을 우회하여 콘텐츠 서버로부터 콘텐츠를 획득하게 하도록 동작할 수 있다. 예를 들면, TA(120)(특히 그의 RM(121))는 클라이언트 디바이스로의 콘텐츠의 가속화된 전달을 제공하기 위해 콘텐츠 서버로부터 콘텐츠의 청크들을 요청하도록 콘텐츠에 대한 사용자 에이전트의 요청을 복수의 청크 요청들로 세분화하는 것을 제공하도록 동작할 수 있다. 전송 가속을 위한 이러한 요청 "청킹" 기능은 가속 선택 속성들에 기초하여 TA 제어(125)의 로직의 제어 하에서 선택적으로 인보크될 수 있다(예를 들면, 가령, RM(121) 및/또는 TA(120)의 다른 로직을 제어 가능하게 우회함으로써 우회 또는 우회되지 않음).
[00121] 실시예들에 따라 전송 가속기의 기능이 인보크되는지를 결정하기 위한 TA 제어 로직에 의한 가속 선택 속성들의 분석은 일부 일반적인 규칙들 및/또는 추정들을 채용할 수 있다. 예를 들면, 본원의 실시예들에 따른 동작에서, 콘텐츠 요청이 가속화되어야 하는지 여부를 결정하기 위해 하나 이상의 세트들의 배제 리스트 규칙들이 TA(120)의 선택적으로 가속 포트에서 수신되는 콘텐츠 요청들에 적용된다. 실시예들은, 예를 들면, 가령, 블랙리스트 서버 리스트(예를 들면, 배제 리스트(126a)) 및 요청 속성 배제 리스트(예를 들면, 배제 리스트(126b))를 포함할 수 있는 복수의 세트들의 배제 리스트 규칙들을 구현할 수 있다.
[00122] 본원의 실시예들에 따라 활용되는 블랙리스트 서버 리스트는, 이런저런 이유로(for one reason or another), 요청 가속이 현실적이거나 가능하지 않다고 결정된 서버들의 리스트를 포함할 수 있다. 예를 들면, UA(129a)는, TA(120)에 의해 전송 가속 동작과 호환 가능하지 않은 것으로 이미 결정되고, 따라서 배제 리스트(126a)의 블랙리스트 서버 리스트 상에 포함된 특정 서버에 콘텐츠 요청을 제공할 수 있다. 따라서, 흐름(200)의 블록(204)에서 분석/제어 로직(126)의 동작은 전송 가속 기능이 제공되지 않는 것이 요청이라고 결정할 수 있다. 블랙리스트 서버 리스트의 예가 아래의 표 6에 제공된다.
표 6
서버 자원 타이머 값
호스트네임 File_Extension 1440 분(1 일)
[00123] 그러한 블랙리스트 서버 리스트가 (예를 들면, 표 6의 "자원" 열에 지정된) 특정 자원들에 관련하여 블랙리스팅을 제공할 수 있다는 것이 인지되어야 한다. 따라서, 달리 블랙리스트 서버에 대한 것이지만, 그럼에도 불구하고 서버가 상이한 자원들에 관련하여 블랙리스트 서버 리스트에 리스팅된 것으로 인해, 다른 자원들에 대한 전송 가속 기능의 요청들이 거부되지 않을 수 있다. 표 6의 "타이머 값"(아래에 설명됨)과 같은 다른 정보는, 적절하거나 요구될 때, 실시예들에 따라 블랙리스트 서버 리스트에 포함될 수 있다.
[00124] 본원의 실시예들에 따라 활용되는 요청 속성 배제 리스트는, 콘텐츠 요청에 대한 전송 가속의 구현에 관한 결정이 이루어질 수 있는 콘텐츠 요청의 다양한 속성들, 또는 콘텐츠 요청과 연관된 다양한 속성들을 포함할 수 있다. 아래의 표 7은 본원의 실시예들에 따라 활용될 수 있는 요청 속성 배제 리스트(예를 들면, 배제 리스트(126b))의 예를 제공한다. 이러한 예시적인 표는 요청의 특정 프로토콜 타입, 요청과 연관된 통신 세션의 특성들, 이루어진 요청의 타입, 및 요청 내의 헤더 정보 ― 요청과 연관하여 존재하면, 요청은 전송 가속 동작으로부터 배제됨(예를 들면, 전송 가속 기능이 우회됨) ― 를 식별한다.
표 7
프로토콜 타입 세션 특성들 메시지의 타입 GET 메시지
헤더 필드들

HTTPS


HTTP1.0

HTTP2.0


spdy_enabled

quic_enabled
upstream_proxy_configured
GET 이외의 무엇이든		 다수의 범위들을 갖는 바이트 범위 헤더 존재
인가
헤더 존재
[00125] 본원의 배제 리스트 내의 특정 입력들은 다수의 기술들을 통해 결정될 수 있다. 예를 들면, 전송 가속 동작을 위해 호환 불가하거나 그렇지 않다면 부적절한 것으로 선험적으로 인지된 특정 자원들(예를 들면, 콘텐츠 파일 × 접미사, 경로 또는 영역, 사용자 에이전트 × 식별 정보, 콘텐츠 서버 × 식별 정보 또는 경로 등)에 대한 입력들이 이루어질 수 있다. 부가적으로 또는 대안적으로, 전송 가속 동작에 대한 호환성 또는 적합성을 경험적으로 결정하기 위해 콘텐츠 전송이 모니터링될 수 있다(예를 들면, 전송 가속기 동작, 네트워크 혼잡, 사용자 에이전트 동작, 사용자 경험 메트릭들 등을 모니터링). 또한, 배제 리스트에 입력을 위한 자원들은, 가령, 요청들에 대한 응답들에 기초하여 시간에 걸쳐 학습될 수 있다. 예를 들면, TA 제어(125)의 학습 로직은, 가령, 바이트 범위 요청들에 대한 지원/비지원, 금지 또는 범위 불만족 응답들을 발생시키는 요청들 등에 기초하여 특정 콘텐츠 서버들 및/또는 다른 자원들에 관한 정보로 배제 리스트 및/또는 포함 리스트 중 어느 하나 또는 둘 모두를 파퓰레이팅하도록 동작할 수 있다. TA 제어(125)의 학습 로직의 실시예들은, 어떠한 응답 코드들이 전송 가속 동작에 대한 콘텐츠 서버 호환성 또는 적합성을 표시하는지를 학습하기 위해, 아마도 요청들을 서빙하는 동작을 모니터링하는 것과 결합하여, 콘텐츠 서버에 의해 제공되는 응답 코드들을 분석하도록 동작할 수 있다.
[00126] 도 2b의 흐름도는 하나 이상의 배제 리스트들(예를 들면, 블랙리스트 서버 리스트 및 요청 속성 배제 리스트)에 기초하여 전송 가속기 로직의 기능의 선택적인 호출을 제공하기 위한 블록(204)의 실시예에 따른 TA 제어(125)의 동작을 예시한다. 예시된 실시예의 블록(221)에서, 배제 리스트(들)(예를 들면, 배제 리스트(126a) 및/또는 배제 리스트(126b))는 콘텐츠 요청에 관련하여 적용된다. 실시예들에 따른 동작에서, 복수의 배제 리스트들은 계층적으로 적용될 수 있다. 예를 들면, 서버 배제 리스트는 상대적으로 용이하게 구현되고, 콘텐츠 요청이 블랙리스트 콘텐츠 서버를 향해 지향되는지를 결정하기 위해 적은 프로세싱 전력을 요구할 수 있다. 따라서, 그러한 배제 리스트는 (예를 들면, 구현하기 위해 더 많은 프로세싱 전력을 요구할 수 있는 요청 속성 배제 리스트 전에) 계층에서 더 높게 적용될 수 있다. 본원의 배제 리스트들의 계층적 구현의 다른 예로서, 배제 리스트(예를 들면, 위에 도시된 표 7의 배제 리스트를 포함할 수 있음)는, 가령, 동작의 용이성을 위해 배제 규칙들을 계층적으로 구현하기 위해 열 단위(column by column) 기반으로(예를 들면, 좌에서 우로) 적용될 수 있다. 예를 들면, 스트링 탐색들은 일반적으로 속성 매치들보다 더 느리고 그리고/또는 더 많은 컴퓨팅 자원들을 활용하고, 따라서, "spdy_enabled"와 같은 속성 탐색들은, 매치가 실시예들에 따라 배제 규칙들의 적용에서 일찍 발견되는 경우에, 개선된 성능을 제공하고 그리고/또는 자원 활용을 감소시키기 위한 임의의 스트링 매칭 전에 수행될 수 있다. 블록(222)에서, 배제 규칙들 중 어느 것이 충족되는지(예를 들면, 요청이 지향되거나 가속 선택 속성이 배제 리스트 내의 엔트리와 매칭하는 콘텐츠 서버)에 관한 결정이 이루어진다.
[00127] 배제 조건들 중 어느 하나가 만족되면, 예시된 실시예에 따른 프로세싱은 블록(224)으로 진행되고, 여기서 전송 가속 기능이 우회된다. 예를 들면, TA 제어(125)의 로직은, 바람직하게는, 그로부터의 전송 가속 동작에 관련하여 임의의 시그널링(예를 들면, 상술된 QC-STA 헤더)을 스트리핑하여, 요청이 전송 가속 기능을 우회하게 하기 위해 TA(120)의 라우팅 블록을 제어하도록 동작할 수 있다. TA(120)는, 전송 가속 기능이 구현되지 않는다고 결정할 때 또는 이후에, (예를 들면, 상술된 QC-STA-응답 헤더를 사용하여) 전송 가속을 구현하지 않는 것에 관한 시그널링을 UA에 제공할 수 있다.
[00128] 그러나, 배제 조건들 중 어느 것도 만족되지 않는다면, 예시된 실시예에 따른 프로세싱은 블록(223)으로 진행된다. 예시된 실시예의 블록(223)에서, 전송 가속 기능은 요청에 관련하여 구현된다. 예를 들면, TA 제어(125)의 로직은, 바람직하게는 그로부터의 전송 가속 동작에 관련하여 임의의 시그널링(예를 들면, 상술된 QC-STA 헤더)을 스트리핑하여, 전송 가속 기능의 요청이 제공되게 하기 위해 TA(120)의 라우팅 블록을 제어하도록 동작할 수 있다. UA로부터 시그널링으로 제공되는 정보, 가령, 상술된 시그널링 키들 중 하나 이상에 의해 제공된 정보(예를 들면, 상술된 QC-STA 헤더에 포함됨)는 UA 동작에 적절한 전송 가속 기능을 구현하기 위해 전송 가속기에 의해 활용될 수 있다. TA(120)는, 전송 가속 기능을 구현할 때 및/또는 그와 연관하여, (예를 들면, 상술된 QC-STA-응답 헤더를 사용하여) 전송 가속의 개시 및/또는 동작에 관한 시그널링을 UA에 제공할 수 있다.
[00129] 콘텐츠 서버가 전송 가속 동작을 지원하지 않는다고 결정되는 경우에(예를 들면, 앞서 말한 예시적인 조건들 중 임의의 것이 실패하였을 때), 실시예들에 따른 동작은 배제 리스트(예를 들면, (hostname, file_extension) 튜플과 같은 {서버, 자원} 튜플을 배제 리스트에 부가), 가령, 배제 리스트(126a)에 콘텐츠 서버를 동적으로 부가하도록 동작한다. 이후에, 전송 가속 기능의 선택적인 구현은, 위에 설명된 바와 같이, 배제 리스트 내의 그들의 포함에 기초하여 그러한 콘텐츠 서버들에 관련하여 이루어질 수 있다.
[00130] 전송 가속에 대한 지원을 표시하는 조건들이 자원 단위에 기초하여 변할 수 있기 때문에, 실시예들은 전송 가속 동작을 지원하지 않는다고 결정된 특정 콘텐츠 서버를 배제 리스트에 일시적으로 포함하도록 동작할 수 있다. 예를 들면, 위의 것에 따라 콘텐츠 서버를 배제 리스트에 부가할 때, 실시예들은 배제 리스트 내의 이러한 엔트리에 대한 타임스탬프 또는 타이머 값(예를 들면, 위의 표 6에서 "타이머 값")을 또한 언급할 수 있다. 실시예들에 따른 동작에서, 특정 튜플이 배제 리스트 상에 있는 시간 동안에, 그 콘텐츠 서버로의 요청들은 가속화되지 않을 것이다(즉, 전송 가속 기능이 우회될 것임). 그러나, 일단 배제 리스트 타이머가 만료되면, 콘텐츠 서버로의 요청들은 (예를 들면, 그에 관련하여 적용된 전송 가속 제어 분석에 의존하여) 가속화될 수 있다.
[00131] 선택된 양상들이 상세하게 예시 및 설명되었지만, 다양한 치환 및 변경들이 이하의 청구항들에 의해 정의된 대로 본 발명의 사상 및 범위로부터 벗어나지 않고 이 양상들에서 행해질 수 있음이 이해될 것이다.

Claims (30)

  1. 전송 가속 요청 통신(transport acceleration request communication)을 위한 방법으로서,
    전송 가속기(TA)에 의해, 제 1 사용자 에이전트(UA)로부터 상기 TA의 제 1 요청 가속 포트를 통해 콘텐츠 요청을 수신하는 단계 ― 상기 콘텐츠 요청은 콘텐츠 데이터가 콘텐츠 서버에 의해 상기 제 1 UA에 전달되기 위한 요청을 포함함 ―;
    상기 콘텐츠 요청과 관련하여 전송 가속 기능이 제공될 수 있다는 것을 표시하는 시그널링(signaling)을 상기 콘텐츠 요청이 포함하는지를 결정하기 위해 상기 콘텐츠 요청을 분석하는 단계 ― 상기 전송 가속 기능이 제공될 수 있다는 것을 표시하는 시그널링은, 전송 가속 동작을 제공하는 것과 관련하여 상기 TA에 의해 활용되는 메타데이터(metadata)를 포함함 ―; 및
    전송 가속 기능이 제공될 수 있다는 것을 표시하는 시그널링을 상기 콘텐츠 요청이 포함한다는 결정에 적어도 부분적으로 기초하여, 상기 콘텐츠 요청과 관련하여 전송 가속 동작을 수행하는 단계를 포함하고,
    상기 전송 가속 동작은 상기 콘텐츠 요청을 콘텐츠에 대한 복수의 요청들로 세분화하는 것, 및 요청된 콘텐츠 데이터의 상기 TA로의 가속화된 전달을 제공하기 위해 상기 TA에 의해 상기 콘텐츠 서버로부터 콘텐츠를 요청하는 것을 제어하는 것을 포함하는,
    전송 가속 요청 통신을 위한 방법.
  2. 제 1 항에 있어서,
    다른 콘텐츠 요청과 관련하여 전송 가속 기능이 제공될 수 있다는 것을 표시하는 시그널링을 상기 다른 콘텐츠 요청이 포함하지 않는다고 결정될 때, 전송 가속 동작을 제공하지 않고서, 상기 TA에 의해 상기 다른 콘텐츠 요청을 상기 콘텐츠 서버로 전달하는 단계를 더 포함하는,
    전송 가속 요청 통신을 위한 방법.
  3. 제 1 항에 있어서,
    상기 콘텐츠 요청과 관련하여 전송 가속 기능이 상기 TA에 의해 제공될 것인지를 결정하기 위해 상기 콘텐츠 요청을 분석하는 단계를 더 포함하고,
    상기 콘텐츠 요청과 관련하여 전송 가속 동작을 수행하는 단계는, 상기 콘텐츠 요청과 관련하여 전송 가속 기능이 상기 TA에 의해 제공될 것이라는 결정에 적어도 부분적으로 기초하는,
    전송 가속 요청 통신을 위한 방법.
  4. 제 3 항에 있어서,
    다른 콘텐츠 요청과 관련하여 전송 가속 기능이 제공될 수 있다는 것을 표시하는 시그널링을 상기 다른 콘텐츠 요청이 포함한다고 결정되지만, 상기 다른 콘텐츠 요청과 관련하여 전송 가속 기능이 상기 TA에 의해 제공되지 않을 것이라고 결정될 때, 전송 가속 동작을 제공하지 않고서, 상기 TA에 의해 상기 다른 콘텐츠 요청을 상기 콘텐츠 서버로 전달하는 단계를 더 포함하는,
    전송 가속 요청 통신을 위한 방법.
  5. 제 4 항에 있어서,
    상기 다른 콘텐츠 요청을 상기 콘텐츠 서버로 전달하는 단계는, 상기 다른 콘텐츠 요청과 관련하여 전송 가속 기능이 제공될 수 있다는 표시를 스트리핑(stripping)하는 단계를 포함하는,
    전송 가속 요청 통신을 위한 방법.
  6. 제 3 항에 있어서,
    상기 전송 가속 기능이 상기 TA에 의해 제공될 것인지를 결정하기 위해 상기 콘텐츠 요청을 분석하는 단계는, 한 세트의 규칙들을 상기 콘텐츠 요청의 하나 또는 그 초과의 속성들에 적용하는 단계를 포함하는,
    전송 가속 요청 통신을 위한 방법.
  7. 제 6 항에 있어서,
    상기 한 세트의 규칙들은 배제 리스트를 포함하고,
    상기 배제 리스트는 블랙리스트 서버 리스트(blacklisted server list) 또는 요청 속성 배제 리스트(request attribute exclude list) 중 적어도 하나를 포함하는,
    전송 가속 요청 통신을 위한 방법.
  8. 제 7 항에 있어서,
    상기 배제 리스트는 미리 결정된 계층에서 적용되는 복수의 블랙 리스트들을 포함하는,
    전송 가속 요청 통신을 위한 방법.
  9. 제 1 항에 있어서,
    상기 메타데이터는 상기 콘텐츠 요청을 상기 콘텐츠에 대한 복수의 요청들로 세분화하는데 상기 TA가 활용하는 정보, 상기 콘텐츠에 대한 복수의 요청들을 스케줄링하는데 상기 TA가 활용하는 정보, 상기 전송 가속 기능의 구현이 상기 콘텐츠 요청과 관련하여 유리한지를 결정하기 위해 상기 TA가 활용하는 정보, 상기 전송 가속 기능의 하나 또는 그 초과의 양상들이 어떻게 구현될 수 있는지를 결정하기 위해 상기 TA가 활용하는 정보, 상기 콘텐츠에 대한 복수의 요청들 중 콘텐츠에 대한 하나 또는 그 초과의 요청들을 취소하는 시간을 결정하기 위해 상기 TA가 활용하는 정보, 상기 콘텐츠에 대한 복수의 요청들 중 콘텐츠에 대한 하나 또는 그 초과의 요청들과 관련하여 사용하기 위한 선호되는 네트워크 인터페이스를 선택하기 위해 상기 TA가 활용하는 정보, 또는 상기 제 1 UA에 의한 단일 콘텐츠 스트림에 대해 상기 전송 가속기에 대한 복수의 연결들을 지원하기 위해 상기 TA가 활용하는 정보 중 적어도 하나를 포함하는,
    전송 가속 요청 통신을 위한 방법.
  10. 제 1 항에 있어서,
    상기 메타데이터는 상기 전송 가속 기능의 하나 또는 그 초과의 양상들이 어떻게 구현될 수 있는지를 결정하기 위해 상기 TA가 활용하는 정보를 포함하고, 그리고
    상기 전송 가속 기능의 하나 또는 그 초과의 양상들은 상기 복수의 요청들의 청크(chunk) 크기, 상기 요청된 콘텐츠 데이터에 대한 비트 레이트, 및 에러 정정 구현으로 구성된 그룹으로부터 선택된 양상을 포함하는,
    전송 가속 요청 통신을 위한 방법.
  11. 제 1 항에 있어서,
    상기 TA는 상기 제 1 요청 가속 포트 및 제 2 가속 포트를 포함하고,
    상기 제 2 가속 포트는 전송 가속을 포함하는 하나 또는 그 초과의 서비스들을 UA들에 제공하는 시스템 프레임워크와 통신하고, 그리고
    상기 제 1 요청 가속 포트와 통신하는 상기 제 1 UA는 상기 시스템 프레임워크를 활용하지 않고 그리고 상기 콘텐츠 요청과 관련하여 전송 가속 동작을 요청하기 위해 상기 시그널링을 구현하는,
    전송 가속 요청 통신을 위한 방법.
  12. 제 1 항에 있어서,
    상기 전송 가속 기능이 제공될 수 있다는 것을 표시하는 시그널링은 전송 가속을 요청하기 위한 미리 결정된 헤더를 포함하고,
    상기 미리 결정된 헤더는 상기 요청된 전송 가속의 하나 또는 그 초과의 속성들에 대한 정보를 제공하는 하나 또는 그 초과의 키들을 포함하는,
    전송 가속 요청 통신을 위한 방법.
  13. 제 12 항에 있어서,
    상기 하나 또는 그 초과의 키들은,
    fileType;
    requestPriority;
    streamingBitRate;
    streamingPlaybackBuffer;
    requestExpirationTime;
    approxFileSize;
    preferredNetworkInterface;
    fastStartSize;
    useHTTPS;
    uniqueUAinstanceID;
    UAPriority;
    uniqueStreamID;
    streamPriority;
    streamBitRate;
    streamPlaybackBuffer;
    requestSoftExpirationTime;
    requestUniqueID; 및
    requestPrerequisites으로 구성된 그룹으로부터 선택되는,
    전송 가속 요청 통신을 위한 방법.
  14. 제 12 항에 있어서,
    상기 전송 가속 동작을 수행하는 단계는 상기 하나 또는 그 초과의 키들에 포함된 정보의 적어도 일부에 따라 상기 전송 가속 기능을 구현하는 단계를 포함하는,
    전송 가속 요청 통신을 위한 방법.
  15. 제 1 항에 있어서,
    상기 콘텐츠 요청과 관련하여 전송 가속 기능이 제공되고 있는지 여부를 표시하는 시그널링을 상기 제 1 UA에 제공하는 단계를 더 포함하는,
    전송 가속 요청 통신을 위한 방법.
  16. 제 15 항에 있어서,
    상기 전송 가속 기능이 제공되고 있는지 여부를 표시하는 시그널링은 전송 가속을 위한 요청들에 응답하기 위한 미리 결정된 헤더를 포함하고,
    상기 미리 결정된 헤더는 상기 전송 가속 기능의 구현에 관한 정보를 제공하는 하나 또는 그 초과의 키들을 포함하는,
    전송 가속 요청 통신을 위한 방법.
  17. 제 16 항에 있어서,
    상기 하나 또는 그 초과의 키들은,
    requestAccelerated;
    requestEstimatedReceiveRate;
    numberOfSupportedPriorities; 및
    usedHTTPS로 구성된 그룹으로부터 선택되는,
    전송 가속 요청 통신을 위한 방법.
  18. 제 1 항에 있어서,
    상기 전송 가속 동작은 상기 콘텐츠 요청과 관련하여 전송 가속 기능이 제공될 수 있다는 표시를 스트리핑하는 것을 더 포함하는,
    전송 가속 요청 통신을 위한 방법.
  19. 전송 가속 요청 통신을 위한 장치로서,
    전송 가속기(TA)가 제 1 사용자 에이전트(UA)로부터 상기 TA의 제 1 요청 가속 포트를 통해 콘텐츠 요청을 수신하기 위한 수단 ― 상기 콘텐츠 요청은 콘텐츠 데이터가 콘텐츠 서버에 의해 상기 제 1 UA에 전달되기 위한 요청을 포함함 ―;
    상기 콘텐츠 요청과 관련하여 전송 가속 기능이 제공될 수 있다는 것을 표시하는 시그널링을 상기 콘텐츠 요청이 포함하는지를 결정하기 위해 상기 콘텐츠 요청을 분석하기 위한 수단 ― 상기 전송 가속 기능이 제공될 수 있다는 것을 표시하는 시그널링은, 전송 가속 동작을 제공하는 것과 관련하여 상기 TA에 의해 활용되는 메타데이터를 포함함 ―;
    전송 가속 기능이 제공될 수 있다는 것을 표시하는 시그널링을 상기 콘텐츠 요청이 포함한다는 결정에 적어도 부분적으로 기초하여, 상기 콘텐츠 요청과 관련하여 전송 가속 동작을 수행하기 위한 수단을 포함하고,
    상기 전송 가속 동작은 상기 콘텐츠 요청을 콘텐츠에 대한 복수의 요청들로 세분화하는 것, 및 요청된 콘텐츠 데이터의 상기 TA로의 가속화된 전달을 제공하기 위해 상기 TA에 의해 상기 콘텐츠 서버로부터 콘텐츠를 요청하는 것을 제어하는 것을 포함하는,
    전송 가속 요청 통신을 위한 장치.
  20. 제 19 항에 있어서,
    상기 메타데이터는 상기 콘텐츠 요청을 상기 콘텐츠에 대한 복수의 요청들로 세분화하는데 상기 TA가 활용하는 정보, 상기 콘텐츠에 대한 복수의 요청들을 스케줄링하는데 상기 TA가 활용하는 정보, 상기 전송 가속 기능의 구현이 상기 콘텐츠 요청과 관련하여 유리한지를 결정하기 위해 상기 TA가 활용하는 정보, 상기 전송 가속 기능의 하나 또는 그 초과의 양상들이 어떻게 구현될 수 있는지를 결정하기 위해 상기 TA가 활용하는 정보, 상기 콘텐츠에 대한 복수의 요청들 중 콘텐츠에 대한 하나 또는 그 초과의 요청들을 취소하는 시간을 결정하기 위해 상기 TA가 활용하는 정보, 상기 콘텐츠에 대한 복수의 요청들 중 콘텐츠에 대한 하나 또는 그 초과의 요청들과 관련하여 사용하기 위한 선호되는 네트워크 인터페이스를 선택하기 위해 상기 TA가 활용하는 정보, 또는 상기 제 1 UA에 의한 단일 콘텐츠 스트림에 대해 상기 전송 가속기에 대한 복수의 연결들을 지원하기 위해 상기 TA가 활용하는 정보 중 적어도 하나를 포함하는,
    전송 가속 요청 통신을 위한 장치.
  21. 제 19 항에 있어서,
    상기 메타데이터는 상기 전송 가속 기능의 하나 또는 그 초과의 양상들이 어떻게 구현될 수 있는지를 결정하기 위해 상기 TA가 활용하는 정보를 포함하고, 그리고
    상기 전송 가속 기능의 하나 또는 그 초과의 양상들은 상기 복수의 요청들의 청크 크기, 상기 요청된 콘텐츠 데이터에 대한 비트 레이트, 및 에러 정정 구현으로 구성된 그룹으로부터 선택된 양상을 포함하는,
    전송 가속 요청 통신을 위한 장치.
  22. 제 19 항에 있어서,
    상기 TA는 상기 제 1 요청 가속 포트 및 제 2 가속 포트를 포함하고,
    상기 제 2 가속 포트는 전송 가속을 포함하는 하나 또는 그 초과의 서비스들을 UA들에 제공하는 시스템 프레임워크와 통신하고, 그리고
    상기 제 1 요청 가속 포트와 통신하는 상기 제 1 UA는 상기 시스템 프레임워크를 활용하지 않고 그리고 상기 콘텐츠 요청과 관련하여 전송 가속 동작을 요청하기 위해 상기 시그널링을 구현하는,
    전송 가속 요청 통신을 위한 장치.
  23. 전송 가속 요청 통신을 위한 컴퓨터 실행 가능 코드를 저장하는 비-일시적 컴퓨터 판독 가능 저장 매체로서, 상기 비-일시적 컴퓨터 판독 가능 저장 매체는 프로그램 코드가 기록된 유형의 컴퓨터-판독 가능 저장 매체를 포함하고, 상기 프로그램 코드는,
    전송 가속기(TA)에 의해, 제 1 사용자 에이전트(UA)로부터 상기 TA의 제 1 요청 가속 포트를 통해 콘텐츠 요청을 수신하기 위한 프로그램 코드 ― 상기 콘텐츠 요청은 콘텐츠 데이터가 콘텐츠 서버에 의해 상기 제 1 UA에 전달되기 위한 요청을 포함함 ―;
    상기 콘텐츠 요청과 관련하여 전송 가속 기능이 제공될 수 있다는 것을 표시하는 시그널링을 상기 콘텐츠 요청이 포함하는지를 결정하기 위해 상기 콘텐츠 요청을 분석하기 위한 프로그램 코드 ― 상기 전송 가속 기능이 제공될 수 있다는 것을 표시하는 시그널링은, 전송 가속 동작을 제공하는 것과 관련하여 상기 TA에 의해 활용되는 메타데이터를 포함함 ―; 및
    전송 가속 기능이 제공될 수 있다는 것을 표시하는 시그널링을 상기 콘텐츠 요청이 포함한다는 결정에 적어도 부분적으로 기초하여, 상기 콘텐츠 요청과 관련하여 전송 가속 동작을 수행하기 위한 프로그램 코드를 포함하고,
    상기 전송 가속 동작은 상기 콘텐츠 요청을 콘텐츠에 대한 복수의 요청들로 세분화하는 것, 및 요청된 콘텐츠 데이터의 상기 TA로의 가속화된 전달을 제공하기 위해 상기 TA에 의해 상기 콘텐츠 서버로부터 콘텐츠를 요청하는 것을 제어하는 것을 포함하는,
    컴퓨터 판독 가능 저장 매체.
  24. 제 23 항에 있어서,
    상기 메타데이터는 상기 콘텐츠 요청을 상기 콘텐츠에 대한 복수의 요청들로 세분화하는데 상기 TA가 활용하는 정보, 상기 콘텐츠에 대한 복수의 요청들을 스케줄링하는데 상기 TA가 활용하는 정보, 상기 전송 가속 기능의 구현이 상기 콘텐츠 요청과 관련하여 유리한지를 결정하기 위해 상기 TA가 활용하는 정보, 상기 전송 가속 기능의 하나 또는 그 초과의 양상들이 어떻게 구현될 수 있는지를 결정하기 위해 상기 TA가 활용하는 정보, 상기 콘텐츠에 대한 복수의 요청들 중 콘텐츠에 대한 하나 또는 그 초과의 요청들을 취소하는 시간을 결정하기 위해 상기 TA가 활용하는 정보, 상기 콘텐츠에 대한 복수의 요청들 중 콘텐츠에 대한 하나 또는 그 초과의 요청들과 관련하여 사용하기 위한 선호되는 네트워크 인터페이스를 선택하기 위해 상기 TA가 활용하는 정보, 또는 상기 제 1 UA에 의한 단일 콘텐츠 스트림에 대해 상기 전송 가속기에 대한 복수의 연결들을 지원하기 위해 상기 TA가 활용하는 정보 중 적어도 하나를 포함하는,
    컴퓨터 판독 가능 저장 매체.
  25. 제 23 항에 있어서,
    상기 메타데이터는 상기 전송 가속 기능의 하나 또는 그 초과의 양상들이 어떻게 구현될 수 있는지를 결정하기 위해 상기 TA가 활용하는 정보를 포함하고, 그리고
    상기 전송 가속 기능의 하나 또는 그 초과의 양상들은 상기 복수의 요청들의 청크 크기, 상기 요청된 콘텐츠 데이터에 대한 비트 레이트, 및 에러 정정 구현으로 구성된 그룹으로부터 선택된 양상을 포함하는,
    컴퓨터 판독 가능 저장 매체.
  26. 전송 가속 요청 통신을 위한 장치로서,
    적어도 하나의 프로세서, 및
    상기 적어도 하나의 프로세서에 커플링된 메모리를 포함하고,
    상기 적어도 하나의 프로세서는,
    전송 가속기(TA)에 의해, 제 1 사용자 에이전트(UA)로부터 상기 TA의 제 1 요청 가속 포트를 통해 콘텐츠 요청을 수신하고 ― 상기 콘텐츠 요청은 콘텐츠 데이터가 콘텐츠 서버에 의해 상기 제 1 UA에 전달되기 위한 요청을 포함함 ―;
    상기 콘텐츠 요청과 관련하여 전송 가속 기능이 제공될 수 있다는 것을 표시하는 시그널링을 상기 콘텐츠 요청이 포함하는지를 결정하기 위해 상기 콘텐츠 요청을 분석하고 ― 상기 전송 가속 기능이 제공될 수 있다는 것을 표시하는 시그널링은, 전송 가속 동작을 제공하는 것과 관련하여 상기 TA에 의해 활용되는 메타데이터를 포함함 ―; 그리고
    전송 가속 기능이 제공될 수 있다는 것을 표시하는 시그널링을 상기 콘텐츠 요청이 포함한다는 결정에 적어도 부분적으로 기초하여, 상기 콘텐츠 요청과 관련하여 전송 가속 동작을 수행하도록 구성되고,
    상기 전송 가속 동작은 상기 콘텐츠 요청을 콘텐츠에 대한 복수의 요청들로 세분화하는 것, 및 요청된 콘텐츠 데이터의 상기 TA로의 가속화된 전달을 제공하기 위해 상기 TA에 의해 상기 콘텐츠 서버로부터 콘텐츠를 요청하는 것을 제어하는 것을 포함하는,
    전송 가속 요청 통신을 위한 장치.
  27. 삭제
  28. 삭제
  29. 삭제
  30. 삭제
KR1020177008369A 2014-09-30 2015-08-28 전송 계층에서 요청 가속을 시그널링하기 위한 시스템들 및 방법들 KR101846382B1 (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201462057412P 2014-09-30 2014-09-30
US62/057,412 2014-09-30
US14/616,233 2015-02-06
US14/616,233 US9769239B2 (en) 2014-09-30 2015-02-06 Systems and methods for user agent signaling request acceleration by transport accelerator
PCT/US2015/047417 WO2016053526A1 (en) 2014-09-30 2015-08-28 Systems and methods for signaling request acceleration in the transport layer

Publications (2)

Publication Number Publication Date
KR20170063635A KR20170063635A (ko) 2017-06-08
KR101846382B1 true KR101846382B1 (ko) 2018-04-06

Family

ID=55585765

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020177008369A KR101846382B1 (ko) 2014-09-30 2015-08-28 전송 계층에서 요청 가속을 시그널링하기 위한 시스템들 및 방법들

Country Status (6)

Country Link
US (1) US9769239B2 (ko)
EP (1) EP3202113A1 (ko)
JP (1) JP2017538987A (ko)
KR (1) KR101846382B1 (ko)
CN (1) CN107079009B (ko)
WO (1) WO2016053526A1 (ko)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10033656B2 (en) * 2015-05-21 2018-07-24 Sap Portals Israel Ltd Critical rendering path optimization
CN106330988B (zh) * 2015-06-16 2020-01-03 阿里巴巴集团控股有限公司 一种超文本传输请求的补发方法、装置及客户端
US10116719B1 (en) 2016-06-03 2018-10-30 Amazon Technologies, Inc. Customized dash manifest
US10432690B1 (en) 2016-06-03 2019-10-01 Amazon Technologies, Inc. Manifest partitioning
US10104143B1 (en) * 2016-06-03 2018-10-16 Amazon Technologies, Inc. Manifest segmentation
US10148512B2 (en) * 2016-08-12 2018-12-04 T-Mobile Usa, Inc. Mobile video optimization
KR102610480B1 (ko) * 2016-09-26 2023-12-06 삼성전자 주식회사 스트리밍 서비스를 제공하는 방법 및 장치
US10439947B2 (en) * 2016-11-17 2019-10-08 Cisco Technology, Inc. Method and apparatus for providing deadline-based segmentation for video traffic
US10666528B1 (en) 2018-11-28 2020-05-26 Sap Portals Israel Ltd. Decoupling platform as a service providers using a service management platform
US10922250B2 (en) * 2019-04-30 2021-02-16 Microsoft Technology Licensing, Llc Monitoring and steering service requests to acceleration components
JP7363167B2 (ja) * 2019-07-31 2023-10-18 日本電気株式会社 コンテナデーモン、情報処理装置、コンテナ型仮想化システム、パケット振り分け方法及びプログラム
US11140060B2 (en) * 2019-11-12 2021-10-05 Hulu, LLC Dynamic variation of media segment durations for optimization of network round trip times
KR20240062222A (ko) 2022-10-28 2024-05-09 안재남 IoT 동작 기기 제어용 디지털 통신 시스템 및 그 구동방법

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140047059A1 (en) 2012-08-07 2014-02-13 International Business Machines Corporation Method for improving mobile network performance via ad-hoc peer-to-peer request partitioning

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04260132A (ja) * 1991-02-15 1992-09-16 Hitachi Ltd 問題解決システム
US6792449B2 (en) * 2001-06-28 2004-09-14 Microsoft Corporation Startup methods and apparatuses for use in streaming content
US8739274B2 (en) * 2004-06-30 2014-05-27 Citrix Systems, Inc. Method and device for performing integrated caching in a data communication network
US8458467B2 (en) 2005-06-21 2013-06-04 Cisco Technology, Inc. Method and apparatus for adaptive application message payload content transformation in a network infrastructure element
KR20070092720A (ko) 2004-12-30 2007-09-13 사이트릭스 시스템스, 인크. 클라이언트측 가속 기술을 제공하는 시스템 및 방법
US8151323B2 (en) * 2006-04-12 2012-04-03 Citrix Systems, Inc. Systems and methods for providing levels of access and action control via an SSL VPN appliance
JP5640649B2 (ja) * 2010-10-27 2014-12-17 ソニー株式会社 データ通信方法及び情報処理装置
US8750188B2 (en) 2010-12-01 2014-06-10 Deutsche Telekom Ag System support for accessing and switching among multiple wireless interfaces on mobile devices
US8743690B1 (en) 2011-06-14 2014-06-03 Cisco Technology, Inc. Selective packet sequence acceleration in a network environment
US8635411B2 (en) * 2011-07-18 2014-01-21 Arm Limited Data processing apparatus and method for managing coherency of cached data
US9182935B2 (en) 2011-09-27 2015-11-10 Z124 Secondary single screen mode activation through menu option
US9923826B2 (en) 2011-10-14 2018-03-20 Citrix Systems, Inc. Systems and methods for dynamic adaptation of network accelerators
US9374406B2 (en) * 2012-02-27 2016-06-21 Qualcomm Incorporated Dash client and receiver with a download rate estimator
US9438701B2 (en) 2012-05-05 2016-09-06 Citrix Systems, Inc. Systems and methods for a SPDY to HTTP gateway
US9009260B2 (en) 2012-05-10 2015-04-14 Blackberry Limited Method, system and apparatus for transferring data via more than one communications interface
US9544205B2 (en) 2013-04-09 2017-01-10 Twin Prime, Inc. Cognitive data delivery optimizing system
KR102164457B1 (ko) 2013-04-25 2020-10-14 삼성전자주식회사 다중 무선 억세스를 위한 전자 장치 및 그 방법
US9648023B2 (en) * 2015-01-05 2017-05-09 Movimento Group Vehicle module update, protection and diagnostics
US11057446B2 (en) * 2015-05-14 2021-07-06 Bright Data Ltd. System and method for streaming content from multiple servers

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140047059A1 (en) 2012-08-07 2014-02-13 International Business Machines Corporation Method for improving mobile network performance via ad-hoc peer-to-peer request partitioning

Also Published As

Publication number Publication date
CN107079009A (zh) 2017-08-18
CN107079009B (zh) 2018-06-08
US20160094614A1 (en) 2016-03-31
EP3202113A1 (en) 2017-08-09
JP2017538987A (ja) 2017-12-28
US9769239B2 (en) 2017-09-19
KR20170063635A (ko) 2017-06-08
WO2016053526A1 (en) 2016-04-07

Similar Documents

Publication Publication Date Title
KR101846382B1 (ko) 전송 계층에서 요청 가속을 시그널링하기 위한 시스템들 및 방법들
JP6918910B2 (ja) メディアデータの提供方法、メディアデータの受信方法、及びプログラム
US9060207B2 (en) Adaptive video streaming over a content delivery network
US8732274B2 (en) Method and apparatus for generating and handling streaming media quality-of-experience metrics
US10015437B2 (en) Supporting transport diversity and time-shifted buffers for media streaming over a network
EP3108639B1 (en) Transport accelerator implementing extended transmission control functionality
US20150271231A1 (en) Transport accelerator implementing enhanced signaling
EP3114845A1 (en) Systems and methods for media format substitution
TW201540031A (zh) 實現客戶端側的傳送功能的傳輸加速器
WO2016018572A1 (en) Systems and methods for selective transport accelerator operation
US20150271226A1 (en) Transport accelerator implementing a multiple interface architecture
EP3391652A1 (en) Controlling retrieval in adaptive streaming
KR20160112009A (ko) 중복 인코딩 컨텐츠 데이터 기능의 선택적 활용을 구현하는 전달 가속기
CN111193684B (zh) 媒体流的实时递送方法及服务器
CN110545492A (zh) 媒体流的实时递送方法及服务器
WO2016119735A1 (en) Method and device for adaptive video content delivery using http
CN107438991A (zh) 经由多媒体广播多播服务的灵活广播服务的方法和装置

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant