KR20230101898A - 오디오 및/또는 비디오 콘텐츠 전달을 위한 방법 및 컨트롤러 - Google Patents

오디오 및/또는 비디오 콘텐츠 전달을 위한 방법 및 컨트롤러 Download PDF

Info

Publication number
KR20230101898A
KR20230101898A KR1020237019439A KR20237019439A KR20230101898A KR 20230101898 A KR20230101898 A KR 20230101898A KR 1020237019439 A KR1020237019439 A KR 1020237019439A KR 20237019439 A KR20237019439 A KR 20237019439A KR 20230101898 A KR20230101898 A KR 20230101898A
Authority
KR
South Korea
Prior art keywords
audio
video content
caching
platform
terminal
Prior art date
Application number
KR1020237019439A
Other languages
English (en)
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 KR20230101898A publication Critical patent/KR20230101898A/ko

Links

Images

Classifications

    • 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
    • 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
    • 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/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/765—Media network packet handling intermediate
    • 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/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams
    • 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/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Traffic Control Systems (AREA)
  • Reverberation, Karaoke And Other Acoustics (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

적응적 스트리밍을 사용하여 오디오 및/또는 비디오 콘텐츠를 단말기에 전달하기 위해 - 오디오 및/또는 비디오 콘텐츠는 각자의 오디오 및/또는 비디오 품질들을 갖는 다양한 표현들로 이용 가능한 데이터 세그먼트들로 세그먼트화되고, 표현들은 세그먼트마다 시간-정렬되고, 세그먼트들은 청크들로 추가로 분할됨 -, 컨트롤러는, 후보 캐싱 플랫폼들의 세트로부터, 오디오 및/또는 비디오 콘텐츠를 제공하는 원천 서버에 의해 정의된 바와 같은 청크 지속기간과 비교한 최소 버스트 전송 지속기간의 함수로서, 오디오 및/또는 비디오 콘텐츠를 단말기에 전달하는 데 사용될 캐싱 플랫폼을 선택한다. 컨트롤러는 세그먼트들에 대한 요청들에 응답한 청크들의 버스트들의 형태의 오디오 및/또는 비디오 콘텐츠의 추가 전달을 위해 단말기를 선택된 플랫폼으로 재지향시킨다.

Description

오디오 및/또는 비디오 콘텐츠 전달을 위한 방법 및 컨트롤러
본 발명은 일반적으로 네트워크 기반구조를 통해 클라이언트 디바이스 또는 단말기에 오디오 및/또는 비디오 콘텐츠를 전달하는 것에 관한 것이다.
HTTP("Hypertext Transfer Protocol") 적응적 스트리밍에서, 클라이언트 디바이스(또는 단말기)는 재생될 오디오 및/또는 비디오 스트림(라이브 콘텐츠) 또는 파일(주문형 비디오 콘텐츠)의, 세그먼트들로 지칭되는, 부분들을 요청하기 위해 서버 장비와 상호작용한다. 오디오 및/또는 비디오 스트림 또는 파일은, 표현(representation)들로 지칭되는, 여러 품질들로 인코딩된다. 표현들 각각은 오디오 및/또는 비디오 콘텐츠에 대해 동일한 지속기간(duration)의 일련의 세그먼트들로 구성된다. 그에 따라 표현들은 세그먼트마다 시간-정렬되고, 동일한 오디오 및/또는 비디오 기준 프레임으로 시작하며, 따라서 클라이언트 디바이스(또는 단말기), 더 구체적으로는 그 안에 포함된 오디오 및/또는 비디오 플레이어가 세그먼트 경계들 상에서 하나의 표현으로부터 다른 표현으로 스위칭하는 것을 가능하게 한다.
HLS(HTTP에 기초하고 애플 인크.(Apple Inc.)에 의해 개발된 라이브 스트리밍 통신 프로토콜인 "HTTP Live Streaming"을 의미함) 또는 DASH(MPEG(Moving Picture Experts Group)에 의해 개발된 멀티미디어 스트리밍 기술인 "Dynamic Adaptive Streaming over HTTP"를 의미함)와 같은 적응적 스트리밍 기술에서, 하나의 표현으로부터 다른 표현으로의 스위칭은 클라이언트 디바이스(또는 단말기)에 의해 구동되며, 이는 클라이언트 디바이스(또는 단말기)가 상기 다른 표현으로 스위칭하도록 서버 장비에 요청한다는 것을 의미한다. 전형적으로, 클라이언트 디바이스(또는 단말기)는 서버 장비로부터 클라이언트 디바이스(또는 단말기)로의 가용 대역폭의 추정, 및 잠재적으로 버퍼 점유, 스크린 해상도, 디코더 능력 등과 같은 다른 기준들에 기초하여 적절한 표현을 선택한다.
MPEG CMAF(Common Media Application Format) 또는 LL HLS(Low Latency HLS)를 갖는 CTE(Chunked Transfer Encoding)와 같은 라이브 스트리밍을 위한 떠오르는 낮은 레이턴시 기술들은 재생을 시작하기 전에 전체 세그먼트의 가용성을 필요로 하지 않는 특정 청크 관리에 의한 오디오 및/또는 비디오 콘텐츠의 조기 재생을 가능하게 한다.
이에 따라, 적응적 스트리밍을 위한 콘텐츠 전달 네트워크(CDN) 배치에서, 패키저 장비로서 작용하는 발신 서버(originating server)(원천 서버로도 지칭됨)는 관련 세그먼트가 캐시 서버 또는 캐싱 플랫폼에 의해 요청될 때마다 전송될 준비가 된 청크들로 분할된 세그먼트들의 형태로 표현들을 제공한다. 청크들은 오디오 및/또는 비디오 콘텐츠의, 청크 지속기간(chunk duration)으로 지칭되는, 미리 정의된 지속기간에 대응하고, 이에 따라 세그먼트들보다 더 작은 인코딩된 유닛들이다. 캐시 서버 또는 캐싱 플랫폼은, 버스트 전송들에서 청크들을 전달함으로써, 그로부터의 세그먼트 요청들의 수신 시에 클라이언트 디바이스(또는 단말기)를 서빙한다.
이러한 낮은 레이턴시 기술들은 데이터 전달을 가속화하지만, 그들은 가용 대역폭을 추정할 때 교란들을 생성한다. 그 결과 부적절한 오디오 및/또는 비디오 콘텐츠 표현(품질)이 선택될 수 있고, 이에 따라 QoE가 낮아질 수 있다.
캐시 서버로부터 클라이언트 디바이스(또는 단말기)로의 처리량은 캐시 서버로부터 클라이언트 디바이스(또는 단말기)로의 링크 용량에 의해, 또는 캐시 서버 또는 캐싱 플랫폼과 클라이언트 디바이스(또는 단말기) 사이의 왕복 시간(RTT)에 의해 제약될 수 있다.
다음과 같은 예시적인 예를 고려하자. 비디오 콘텐츠가 4 Mbps, 2 Mbps 및 1 Mbps의 대응하는 비트레이트들을 갖는 3개의 표현으로 이용 가능하게 된다. 비디오 콘텐츠는 비디오 콘텐츠에 대해 2초의 지속기간을 갖는 세그먼트들로 분할되고, 비디오 콘텐츠에 대해 200 밀리초의 지속기간의 청크들(세그먼트당 10개의 청크)로 추가로 분할된다. 150 밀리초의 RTT 및 8 Mbps의 최대 병목 대역폭을 고려하자. 클라이언트 디바이스(플레이어)가 예를 들어 MPEG DASH 기술에 따라 1 Mbps 비디오 세그먼트를 요청한 경우, 비디오 콘텐츠는 청크 후 청크로 전달되며, 이는, 유효 용량이 8 Mbps와 동일하지만, 대략 1.5 내지 2,5 Mbps의 대역폭 추정으로 이어진다. 여기서, LL HLS 기술의 하나의 동작 모드에서와 같은, 몇몇 낮은 레이턴시 기술들에 따르면, 클라이언트 디바이스(플레이어)는 세그먼트별로 대신에 청크별로 요청들을 송신할 수 있지만, 대역폭 추정 및 유효 용량 수치들은 동일하게 유지된다는 점에 유의할 수 있다.
그것은 청크의 송신에 대응하는 버스트 기간 동안 송신되는 비트들의 양을 분석하는 것을 통해 최대 가용 대역폭을 평가하려고 시도하고 있는 클라이언트 디바이스(또는 단말기) 또는 캐시 서버(또는 캐싱 플랫폼)가 실제 가용 대역폭보다 훨씬 아래의 1.5 내지 2.5 Mbps의 가용 대역폭을 잘못 추정하여, (더 높은 비트레이트를 갖는) 더 높은 품질 표현들의 사용을 배제한다는 것을 의미한다. 상황은 확실히 전술한 예에서 나타내어진 것보다 훨씬 더 나쁜데, 왜냐하면 오디오 및/또는 비디오 콘텐츠에 대해 동일한 지속기간의 청크들로 세그먼트를 분할하는 것이 동일한 크기(즉, 비트들의 수량)를 갖는 청크들로 이어지지 않기 때문이다. 실제로, 비디오 콘텐츠를 고려하면, (종래의 IPB 압축 스킴에 따른) I 픽처 데이터를 포함하는 청크는 확실히 가용 대역폭을 추정하기 위해 전술한 예에서 사용되는 200 kbit의 평균 크기보다 더 큰 크기를 갖는 반면, 동일한 비디오 프레임의 다른 데이터를 포함하는 다른 청크들은 더 낮은 크기를 갖는다. 가용 대역폭을 추정하기 위해 혼잡 시간 윈도우에서 어느 청크들이 고려되는지에 따라, 그것은 훨씬 더 감소된 가용 대역폭 추정으로 이어질 수 있으며, 이는 또한 캐시 서버(또는 캐싱 플랫폼)와 클라이언트 디바이스(또는 단말기) 사이에 네트워크 버퍼링이 있을 때 증폭될 수 있다.
RTT가 상이할 때, 결과적인 가용 대역폭 추정이 상이하다는 점에 추가로 유의할 수 있는데, 예를 들어 RTT가 10 밀리초와 동일한 경우, 그것은 20 Mbps의 이론적 대역폭 추정을 야기했을 것이며, 이는 실제로 8 Mbps(링크 용량)의 최대 병목 대역폭에 의해 제한된다.
이에 따라 QoE를 개선하기 위해 상기 단말기에 대해 수행되는 RTT 추정에 의존할 수 있는, 오디오 및/또는 비디오 콘텐츠를 단말기에 전달하기 위한 캐시 서버를 적절하게 선택/배치하는 것이 바람직하다.
이에 따라 종래 기술의 전술한 결점들을 극복하는 것이 바람직하며, 보다 구체적으로 적응적 비트 레이트를 사용하여 서버 장비로부터 클라이언트 디바이스(또는 단말기)로 오디오 및/또는 비디오 콘텐츠를 전달할 때 QoE를 개선하는 것이 바람직하다. 구현이 간단하고 비용-효과적인 해결책을 제공하는 것이 또한 특히 바람직하다.
그 목적으로, 네트워크 기반구조의 최상부에 배치된 오디오 및/또는 비디오 콘텐츠 전달 시스템에 의해 적응적 스트리밍을 사용하여 오디오 및/또는 비디오 콘텐츠를 단말기에 전달하기 위한 방법으로서, 오디오 및/또는 비디오 콘텐츠 전달 시스템은 컨트롤러 및 복수의 캐싱 플랫폼들을 포함하고, 오디오 및/또는 비디오 콘텐츠는 각자의 오디오 및/또는 비디오 품질들을 갖는 다양한 표현들로 이용 가능한 데이터 세그먼트들로 세그먼트화되고, 표현들은 오디오 및/또는 비디오 콘텐츠에 대해 동일한 청크 지속기간을 갖는 청크들로 추가로 분할되는 세그먼트들마다 시간-정렬되는, 방법이 본 명세서에 개시된다. 방법은, 각각의 캐싱 플랫폼에 대해, 컨트롤러에 의해 수행되는 다음의 단계들을 포함한다: 네트워크 기반구조를 통해 해당 캐싱 플랫폼에 의해 오디오 및/또는 비디오 콘텐츠들을 단말기들에 전달하는 것에 대해 해당 캐싱 플랫폼에 관한 물리적 왕복 시간 정보를 획득하는 단계; 오디오 및/또는 비디오 콘텐츠의 다양한 표현들의 최대 평균 비트레이트로부터, 그리고 획득된 물리적 왕복 시간 정보로부터 최소 버스트 전송 크기(mTBS)를 계산하는 단계; 최소 버스트 전송 크기(mTBS)로부터, 오디오 및/또는 비디오 콘텐츠의 하나 이상의 표현들(i)에 대한, 최소 버스트 전송 지속기간(mTBDi)을 계산하는 단계. 오디오 및/또는 비디오 콘텐츠가 단말기에 전달되어야 할 때, 방법은 컨트롤러에 의해 수행되는 다음 단계들을 포함한다: 후보 캐싱 플랫폼들의 세트(L0)로부터, 오디오 및/또는 비디오 콘텐츠의 하나 이상의 표현들(i)에 대해 계산된 최소 버스트 전송 지속기간(mTBDi)의 함수로서, 오디오 및/또는 비디오 콘텐츠를 단말기에 전달하는 데 사용될 캐싱 플랫폼을 선택하는 단계; 및 청크들의 버스트들의 형태의 오디오 및/또는 비디오 콘텐츠의 추가 전달을 위해 단말기를 선택된 플랫폼으로 재지향시키는 단계. 더욱이, 사용될 캐싱 플랫폼을 선택하기 위해, 컨트롤러는, 후보 캐싱 플랫폼들의 세트(L0)로부터, 해당 오디오 및/또는 비디오 콘텐츠의 전달에 적용 가능한 청크 지속기간 이하인, 오디오 및/또는 비디오 콘텐츠의 i의 하나 이상의 표현들에 대한 최소 버스트 전송 지속기간(mTBDi)을 나타내는 캐싱 플랫폼들을 포함하는 리스트(L1)를 형성하고, 리스트(L1)의 카디널리티(cardinality)가 미리 정의된 임계치 초과일 때, 리스트(L1)로부터 사용될 캐싱 플랫폼을 선택하는 단계; 및 그렇지 않으면, 후보 캐싱 플랫폼들의 세트(L0)로부터, 해당 오디오 및/또는 비디오 콘텐츠의 전달에 적용 가능한 청크 지속기간의 배수인 미리 정의된 임계치(TH) 이하인 최소 버스트 전송 지속기간(mTBDi)을 나타내는 캐싱 플랫폼들을 포함하는 리스트(L2)를 형성하고, 리스트(L2)로부터 사용될 캐싱 플랫폼을 선택하는 단계를 수행한다. 사용될 캐싱 플랫폼을 이와 같이 선택함으로써, 적응적 비트 레이트를 사용하여 오디오 및/또는 비디오 콘텐츠를 단말기에 전달할 때 대역폭 추정이 더 신뢰성 있기 때문에 QoE가 개선된다.
특정 실시예에 따르면, 물리적 왕복 시간 정보는 오디오 및/또는 비디오 콘텐츠를 단말기들에 전달할 때 과거 이력에서 초래된 최소 왕복 시간의 최대, 및/또는 오디오 및/또는 비디오 콘텐츠를 단말기들에 전달할 때 과거 이력에서 초래된 최소 왕복 시간의 평균을 나타낸다.
특정 실시예에 따르면, 컨트롤러는, 각각의 캐싱 플랫폼에 대해, 하나 이상의 오디오 및/또는 비디오 콘텐츠들에 대해 이용 가능한 최저 비트레이트 표현에 대해서만, 즉 i = 1에 대해 최소 버스트 전송 지속기간(mTBDi)을 계산한다.
특정 실시예에 따르면, 컨트롤러는 해당 단말기 및 해당 오디오 및/또는 비디오 콘텐츠에 관한 세션 요청을 처리할 때 오디오 및/또는 비디오 콘텐츠를 단말기에 전달하는 데 사용될 캐싱 플랫폼을 선택한다.
특정 실시예에 따르면, 청크 지속기간뿐만 아니라, 오디오 및/또는 비디오 콘텐츠의 이용 가능한 표현들은 세션 요청에 의해 관련된 오디오 및/또는 비디오 콘텐츠를 제공하는 원천 서버에 의존하고, 컨트롤러는 세션 요청에 표시된, 또는 세션 요청으로부터 복사되거나 인용된 URI(Uniform Resource Identifier) 경로를 분석함으로써 해당 원천 서버를 나타내는 식별자를 검색한다.
특정 실시예에 따르면, 컨트롤러는 상기 후보 캐싱 플랫폼들의 세트(L0)를, 미리 결정된 지리적 영역에 배치된 또는 미리 결정된 지리적 영역에서 활성화될 수 있는 오디오 및/또는 비디오 콘텐츠 전달 시스템의 캐싱 플랫폼들인 것으로서 정의한다.
특정 실시예에 따르면, 네트워크 기반구조는 모바일 네트워크 기반구조이고, 지리적 영역은 단말기를 둘러싸는 모바일 네트워크 셀들의 미리 결정된 세트의 상류측에 있는 네트워크 기반구조의 일부인 것으로서 결정된다.
특정 실시예에 따르면, 리스트(L2)의 카디널리티가 미리 정의된 임계치 이하일 때, 컨트롤러는 리스트(L0)로부터 사용될 캐싱 플랫폼을 선택한다.
특정 실시예에 따르면, 컨트롤러는, 적어도 하나의 미리 정의된 기준을 충족시키지 않는 캐싱 플랫폼들을 리스트(L0)로부터 철회하는 단계; 파라미터 y = 1로 여기서 지정된, 최저 표현을 선택하는 단계; 리스트(L1) 및 잠재적으로 리스트(L2)를 형성함으로써 i = y에 대한 최소 버스트 전송 지속기간(mTBDi)을 고려함으로써 캐싱 플랫폼 선택 라운드를 수행하는 단계를 수행하고, 리스트들(L1 및 L2)로부터 어떠한 선택도 발생하지 않을 때, 파라미터 y는 하나의 단위만큼 증분되고, 컨트롤러는 파라미터 y에 의해 지정된 표현에 대한 최소 버스트 전송 지속기간(mTBDi)으로 다른 캐싱 플랫폼 선택 라운드를 수행한다.
특정 실시예에 따르면, 컨트롤러는 단말기가 세션 요청을 다시 제출하지만 컨트롤러에 질의하는 대신에 선택된 캐싱 플랫폼에 질의하도록 강제함으로써 단말기를 선택된 캐싱 플랫폼을 향해 재지향시킨다.
특정 실시예에 따르면, 네트워크 기반구조는 모바일 네트워크 기반구조이고, 캐싱 플랫폼들은 모바일 네트워크 기반구조의 클라우들릿(cloudlet)들에 배치된다.
프로그램 코드 명령어들을 포함하는 컴퓨터 프로그램 제품으로서, 프로그램 코드 명령어들은, 프로그램 코드 명령어들이 프로그래밍 가능 디바이스에 의해 실행될 때, 그의 실시예들 중 임의의 하나의 실시예에서의 전술한 방법을 구현하기 위해 프로그래밍 가능 디바이스에 로딩될 수 있는, 컴퓨터 프로그램 제품이 본 명세서에 추가로 개시된다. 그러한 컴퓨터 프로그램을 저장하는 정보 저장 매체가 본 명세서에 추가로 개시된다.
네트워크 기반구조의 최상부에 배치된 오디오 및/또는 비디오 콘텐츠 전달 시스템에서 사용되도록 의도된 컨트롤러로서, 오디오 및/또는 비디오 콘텐츠 전달 시스템은 네트워크 기반구조를 통해 오디오 및/또는 비디오 콘텐츠를 전달하기 위한 복수의 캐싱 플랫폼들을 추가로 포함하고, 오디오 및/또는 비디오 콘텐츠는 각자의 오디오 및/또는 비디오 품질들을 갖는 다양한 표현들로 이용 가능한 데이터 세그먼트들로 세그먼트화되고, 표현들은 오디오 및/또는 비디오 콘텐츠에 대해 동일한 청크 지속기간을 갖는 청크들로 추가로 분할되는 세그먼트들마다 시간-정렬되는, 컨트롤러가 본 명세서에 추가로 개시된다. 컨트롤러는, 각각의 캐싱 플랫폼에 대해, 네트워크 기반구조를 통해 해당 캐싱 플랫폼에 의해 오디오 및/또는 비디오 콘텐츠들을 단말기들에 전달하는 것에 대해 해당 캐싱 플랫폼에 관한 물리적 왕복 시간 정보를 획득하고; 오디오 및/또는 비디오 콘텐츠의 다양한 표현들의 최대 평균 비트레이트로부터, 그리고 획득된 물리적 왕복 시간 정보로부터 최소 버스트 전송 크기(mTBS)를 계산하고; 최소 버스트 전송 크기(mTBS)로부터, 오디오 및/또는 비디오 콘텐츠의 하나 이상의 표현들(i)에 대한, 최소 버스트 전송 지속기간(mTBDi)을 계산하도록 구성된 전자 회로를 포함한다. 그리고 전자 회로는, 오디오 및/또는 비디오 콘텐츠가 단말기에 전달되어야 할 때, 후보 캐싱 플랫폼들의 세트(L0)로부터, 오디오 및/또는 비디오 콘텐츠의 하나 이상의 표현들(i)에 대해 계산된 최소 버스트 전송 지속기간(mTBDi)의 함수로서, 오디오 및/또는 비디오 콘텐츠를 단말기에 전달하는 데 사용될 캐싱 플랫폼을 선택하고; 청크들의 버스트들의 형태의 오디오 및/또는 비디오 콘텐츠의 추가 전달을 위해 단말기를 선택된 플랫폼으로 재지향시키도록 추가로 구성된다. 더욱이, 전자 회로는, 사용될 캐싱 플랫폼을 선택하기 위해, 후보 캐싱 플랫폼들의 세트(L0)로부터, 해당 오디오 및/또는 비디오 콘텐츠의 전달에 적용 가능한 청크 지속기간 이하인, 오디오 및/또는 비디오 콘텐츠의 하나 이상의 표현들(i)에 대한 최소 버스트 전송 지속기간(mTBDi)을 나타내는 캐싱 플랫폼들을 포함하는 리스트(L1)를 형성하고, 리스트(L1)의 카디널리티가 미리 정의된 임계치 초과일 때, 리스트(L1)로부터 사용될 캐싱 플랫폼을 선택하고; 그렇지 않으면, 후보 캐싱 플랫폼들의 세트(L0)로부터, 해당 오디오 및/또는 비디오 콘텐츠의 전달에 적용 가능한 청크 지속기간의 배수인 미리 정의된 임계치(TH) 이하인 최소 버스트 전송 지속기간(mTBDi)을 나타내는 캐싱 플랫폼들을 포함하는 리스트(L2)를 형성하고, 리스트(L2)로부터 사용될 캐싱 플랫폼을 선택하도록 구성된다.
전술한 컨트롤러를 포함하는 콘텐츠 전달 네트워크가 본 명세서에 추가로 개시된다.
본 발명의 특징들이 적어도 하나의 실시예에 대한 다음의 설명을 읽음으로써 더 명확하게 드러날 것이며, 상기 설명은 첨부 도면들을 참조하여 이루어진다.
도 1은 본 발명이 구현될 수 있는 오디오 및/또는 비디오 콘텐츠 전달 시스템을 개략적으로 나타낸다.
도 2는 다양한 표현들의 시간-정렬된 세그먼트들을 개략적으로 나타낸다.
도 3은 오디오 및/또는 비디오 콘텐츠 전달 시스템의 범위에서 사용 가능한 디바이스의 하드웨어 아키텍처의 예를 개략적으로 나타낸다.
도 4는 나중에 오디오 및/또는 비디오 콘텐츠를 전달하기 위해 적절한 캐싱 플랫폼을 선택하는 데 사용 가능한 정보를 획득하고 저장하기 위한 알고리즘을 개략적으로 나타낸다.
도 5는 일 실시예에서 세션 요청들을 관리하기 위한 알고리즘을 개략적으로 나타낸다.
도 6은 다른 실시예에서 세션 요청들을 관리하기 위한 알고리즘을 개략적으로 나타낸다.
도 1은 네트워크 기반구조의 최상부에 배치된 오디오 및/또는 비디오 콘텐츠 전달 시스템(100)을 개략적으로 나타낸다.
오디오 및/또는 비디오 콘텐츠 전달 시스템(100)은 바람직하게는 콘텐츠 전달 네트워크(CDN)이다.
네트워크 기반구조는 예를 들어, 도 1에 예시적으로 도시된 바와 같이, 예를 들어 LTE(Long-Term Evolution) 4G 또는 5G를 준수하는 모바일 네트워크 기반구조이다.
오디오 및/또는 비디오 콘텐츠 전달 시스템(100)은 네트워크 기반구조에 걸쳐, 즉 네트워크 기반구조 내의 다양한 위치들에 확산된 캐싱 플랫폼들을 포함한다. 캐싱 플랫폼들은 컨트롤러, 예시적으로 도 1에서의 중앙 컨트롤러(CC)(111)에 의해 제어된다. 캐싱 플랫폼들은, 중앙 캐싱 플랫폼을 루트(root)로서 사용하여, 계층적으로 배열된다.
도 1에서의 예시적인 모바일 네트워크 기반구조의 범위에서, 캐싱 플랫폼들은 에지 캐시 서버들(ECS)(132)로 명명된다.
에지 캐시 서버들(ECS)(132)은 오디오 및/또는 비디오 콘텐츠의 세그먼트들을 네트워크 기반구조에 접속된 단말기들(T)(150)(클라이언트 디바이스들로도 지칭됨), 즉 도 1에서 예시적으로 모바일 단말기들(T)(150)로 송신하는 것을 목표로 한다. 이에 따라 단말기들(T)(150)은 기지국들(eNodeB들)을 통해 모바일 네트워크 기반구조에 액세스할 수 있지만, 또한 예를 들어 무선 근거리 네트워크(WLAN) 게이트웨이들(140)에 의해 제공되는, Wi-Fi 핫스팟들과 같은, 그에 접속된 WLAN을 통해 모바일 네트워크 기반구조에 액세스할 수 있다.
네트워크 기반구조는 집성 노드들(각각의 집성 노드는 도 1에서 A-NODE(130)로 라벨링됨)을 포함한다. 그러한 집성 노드들은, 사용되고 있는 네트워크 기반구조 기술에 따라, 기지국들, 중앙국들, eNodeB들, P-GW(Packet data network GateWay)들 또는 S-GW(Serving GateWay)들, TUPF(Terminating User Plane Function)들이다. 모바일 네트워크 기반구조의 집성 노드들(130) 중 적어도 일부는, 예를 들어 MEC-기반 플랫폼들을 사용하여, 브레이크아웃 기능을 구현한다.
각각의 에지 캐시 서버(ECS)(132)는 모바일 네트워크 기반구조의 집성 노드(130)의 브레이크아웃 기능에 접속된다. 에지 캐시 서버(ECS)(132)가 접속되는 임의의 집성 노드(130)는, 구성 가능한 라우팅 규칙들에 따라 브레이킹 기능을 통해, 패킷들, 전형적으로 IP(인터넷 프로토콜) 패킷들을 라우팅하는 것을 허용하는 구성 가능한 브레이크아웃 기능을 구현한다. 그러한 라우팅 규칙들은 그러한 목적지 어드레스 및/또는 그러한 소스 어드레스를 갖는 패킷들이 해당 에지 캐시 서버(ECS)(132)로 라우팅되어야 한다는 것을 정의할 수 있다. 브레이크아웃 기능은 또한 그에 접속된 에지 캐시 서버(ECS)(132)가 네트워크 기반구조를 통해 패킷들을 송신할 수 있게 한다.
논리적으로 에지 캐시 서버(ECS)(132)는 트리 토폴로지(tree topology) 또는 스타 토폴로지(star topology)를 사용하여 상호 접속되고, 이에 따라 계층적으로 배열되며, 여기서 중앙 장비(CE)(110) 내의 중앙 콘텐츠 서버(CCS)(112)는 토폴로지의 루트이다. 그것은, 주어진 단말기(T)(150)에 대한 오디오 및/또는 콘텐츠 전달 세션이 해당 단말기(T)(150)에 대해 네트워크 기반구조 내의 가장 가까운 에지 캐시 서버(ECS)(132)에 의해 처리될 수 없을 때, 오디오 및/또는 콘텐츠 전달 세션이 오디오 및/또는 비디오 콘텐츠 전달 시스템(100)의 토폴로지에서(그리고 네트워크 기반구조에서) 상류측에 있는 더 먼 하나의 (루트에 더 가까운) 캐시 서버에 의해 처리된다는 것을 의미한다.
중앙 콘텐츠 서버(CCS)(112)는 단일 서버 또는 서버들의 클러스터(cluster)일 수 있다. 중앙 콘텐츠 서버(CCS)(112)는 적어도 하나의 원천 서버로부터 오디오 및/또는 비디오 콘텐츠를 획득한다. 도 1에, 2개의 원천 서버(OS1(161) 및 OS2(162))가 도시되어 있다. 예시적으로 원천 서버(OS1)(161) 및 원천 서버(OS2)(162)는 별개의 콘텐츠 제공자들에 속한다. 오디오 및/또는 비디오 콘텐츠에 대해 사용되고 있는 청크 크기는 콘텐츠 제공자들에 의해 부과되며, 이는, 원천 서버(OS1)(161), 원천 서버(OS2)(162) 및 중앙 콘텐츠 서버(CCS)(112)가 전형적으로 상이한 조직들에 의해 지배되기 때문에, 중앙 콘텐츠 서버(CCS)(112)가 청크 크기를 수정하기 위한 어떠한 수단도 갖지 않는다는 것을 의미한다. 더욱이, 원천 서버(OS1)(161)에 의해 제공되는 청크들의 크기는 원천 서버(OS2)(162)에 의해 제공되는 청크들의 크기와는 상이할 수 있다. 도 1에서, 중앙 캐시 서버(CCS)(112)는 차폐 캐시의 역할을 한다는 점에 유의한다. 대안적으로, 원천 서버들(OS1(161) 및 OS2(162))은 에지 콘텐츠 서버들(ECS)(132)에 직접 공급할 수 있다.
에지 캐시 서버들(ECS)(132)은, 중앙 콘텐츠 서버(CCS)(112)를 통해 또는 이를 통하지 않고, 원천 서버(OS1)(161) 및/또는 원천 서버(OS2)(162)에 의해 오디오 및/또는 비디오 콘텐츠를 공급받는다. 원천 서버들(OS1(161) 및 OS2(162)), 중앙 콘텐츠 서버(CCS)(112) 및 에지 캐시 서버들(ECS)(132)은 적응적 스트리밍을 적용한다. 중앙 콘텐츠 서버(CCS)(112)는 브로드캐스트, 멀티캐스트 또는 유니캐스트 송신들을 사용하여 해당 오디오 및/또는 비디오 콘텐츠의 적응적 스트리밍 세그먼트들을 에지 캐시 서버들(ECS)(132)에 송신할 수 있다.
원천 서버들(OS1(161) 및 OS2(162))은, 적응적 스트리밍을 구현하기 위해, 각자의 비트레이트들을 갖는 복수의 표현들(품질들)로 각각의 오디오 및/또는 비디오 콘텐츠를 제공하는 청크들로 분할되는 세그먼트들의 형태로 단말기들(T)(150)에 전달될 적어도 하나의 오디오 및/또는 비디오 콘텐츠를 패키징하는 것을 담당한다.
도 2에 관하여 이후에 개시되는 바와 같이, 표현의 품질이 높을수록, 대응하는 비트레이트는 더 높다. 세그먼트들은 임의의 하나의 상기 오디오 및/또는 비디오 콘텐츠의 모든 표현들 사이에서 시간-정렬되며, 이에 따라 가능한 한 최상의 QoE를 달성하기 위해 가용 대역폭 추정에 어느 표현 비트레이트가 더 잘 어울리는지에 따라 하나의 표현으로부터 다른 표현으로의 스위칭을 가능하게 한다.
청크들은 오디오 및/또는 비디오 콘텐츠에 대해 동일한 지속기간을 갖는다. 청크 지속기간은 원천 서버들(OS1(161), OS2(162))의 구성 파라미터이며, 그에 따라, 이미 설명된 바와 같이, 전형적으로 오디오 및/또는 비디오 콘텐츠 전달 시스템(100)의 제어 밖이다. 청크 지속기간은 세그먼트 지속기간이 예를 들어 1초인 경우(세그먼트 지속기간은 청크 지속기간의 정수에 대응해야 함) 오디오 및/또는 비디오 콘텐츠의 예를 들어 40 밀리초(25 프레임/초 비디오 스트림을 다룰 때의 최소 청크 지속기간) 내지 500 밀리초의 범위인 고정된 값이다.
에지 캐시 서버들(ECS)(132)은, 버스트 전송들에서 청크들을 전달함으로써, 그로부터의 요청들(세그먼트별 요청 또는 청크별 요청들)의 수신 시에 단말기들(T)(150)을 서빙한다.
각각의 단말기(T)(150)는 플레이어 및 디코더를 포함한다. 디코더는 효과적으로 사용되고 있는 인코딩 포맷 및 품질(즉, 표현)에 따라 플레이어에 의해 구성(초기화 또는 재초기화)되고, 플레이어에 의해 수신된 오디오 및/또는 비디오 데이터에 따른 디코딩을 담당한다. 플레이어는 캐싱 플랫폼으로부터 인코딩된 오디오 및/또는 비디오 데이터를 수신하기 위해 상기 캐싱 플랫폼과의 교환을 수행하는 것을 담당한다. 플레이어는 적어도 하나의 오디오 및/또는 비디오 콘텐츠의 세그먼트들 또는 그의 청크들을 요청하고, 캐싱 플랫폼은 요청된 세그먼트들의 청크들 또는 요청된 청크들을 회답으로 송신한다.
하나의 상기 단말기(T)(150)에 오디오 및/또는 비디오 콘텐츠를 전달하기 위한 세션을 고려하면, 가용 대역폭 추정이 상기 단말기(T)(150)에 오디오 및/또는 비디오 콘텐츠를 전달하는 캐싱 플랫폼에 의해, 그리고/또는 상기 단말기(T)(150)에 의해 수행된다. 가용 대역폭 추정은 가능한 한 최상의 QoE를 달성하기 위해 어느 표현 비트레이트가 가용 대역폭 추정에 더 잘 어울리는지에 따라 오디오 및/또는 비디오 콘텐츠의 하나의 표현을 선택하는 것을 가능하게 한다. 예를 들어, BBR(Bottleneck Bandwidth and Round-trip propagation time) 정보를 사용함으로써 가용 대역폭 추정이 수행된다. BBR 접근법은, 무선 통신에 특히 잘 어울리고 TCP 프로토콜 또는 다른 전송 프로토콜(예를 들어, UDP(User Datagram Protocol)를 통한 QUIC)과 관련하여 사용될 수 있는 최근의 혼잡 제어 알고리즘이다. 가용 대역폭 추정이 TCP CUBIC, VEGAS, RENO, 또는 QUIC, SCTP(Stream Control Transmission Protocol)...와 같은 다른 전송 프로토콜들에서와 같이 다른 혼잡 제어 알고리즘들을 사용하여 이루어지는 대안적인 실시예들이 가능하다. 대안적으로, 가용 대역폭 추정은 해당 단말기(T)(150)에 청크를 전달하는 데 사용되는 적어도 하나의 전송 접속(예를 들어, TCP 접속)의 전송 프로토콜 트래픽 형상(데이터 패킷 및 확인응답 패킷)을 분석함으로써 직접 수행된다.
도 2에 도시된 바와 같이, 각각의 오디오 및/또는 비디오 콘텐츠는 각자의 오디오 및/또는 비디오 품질들을 갖는 다양한 표현들(R1, R2, R3)로 이용 가능하게 된다. 오디오 및/또는 비디오 콘텐츠의 임의의 그리고 모든 표현들(예를 들어, R1)의 하나의 세그먼트는 오디오 및/또는 비디오 콘텐츠의 임의의 그리고 모든 다른 표현들(예를 들어, 각각 R2, R3)의 동일한 세그먼트와 동일한 콘텐츠 부분을 포함한다. 다시 말해서, 다양한 표현들(R1, R2, R3)의 세그먼트들은 시간-정렬된다. 각각의 세그먼트는 기준 프레임(RF)으로 시작한다. 도 2에서, 오디오 및/또는 비디오 콘텐츠의 동일한 세그먼트를 고려하면, 기준 프레임(RF)은 표현(R1)에 대해 RF1로 라벨링되고, 기준 프레임(RF)은 표현(R2)에 대해 RF2로 라벨링되고, 기준 프레임(RF)은 표현(R3)에 대해 RF3으로 라벨링된다. 더욱이, 기준 프레임(RF)에 이어서 세그먼트 내의 적어도 하나의 후속 프레임(SF)이 뒤따른다. 도 2에서, 적어도 하나의 후속 프레임(SF)은 표현(R1)에 대해 SF1로 라벨링되고, 적어도 하나의 후속 프레임(SF)은 표현(R2)에 대해 SF2로 라벨링되고, 적어도 하나의 후속 프레임(SF)은 표현(R3)에 대해 SF3으로 라벨링된다.
표현들(R1, R2, R3)이 상이한 품질들에 대응하기 때문에, 임의의 그리고 모든 표현들(예를 들어, R1)의 하나의 세그먼트의 크기는 전형적으로 임의의 그리고 모든 다른 표현들(예를 들어, 각각 R2, R3)의 동일 세그먼트의 크기와는 상이하다. 실제로, 세그먼트 크기는 도 2에 도시된 바와 같이 품질에 따라 증가하며, 도 2에서 표현들(R1, R2, R3)의 동일한 세그먼트가 개략적으로 나타내어져 있고, 표현(R3)이 표현(R2)보다 더 양호한 품질에 대응하고, 표현(R2)이 표현(R1)보다 더 양호한 품질에 대응하는 것으로 간주된다. 그 결과 표현(R3)에서의 기준 프레임(RF3)의 크기는 표현(R2)에서의 기준 프레임(RF2)의 크기보다 크고, 표현(R2)에서의 기준 프레임(RF2)의 크기는 표현(R1)에서의 기준 프레임(RF1)의 크기보다 크다. 또한, 표현(R3)에서의 후속 프레임들(SF3)의 크기는 표현(R2)에서의 후속 프레임들(SF2)의 크기보다 크고, 표현(R2)에서의 후속 프레임들(SF2)의 크기는 표현(R1)에서의 후속 프레임들(SF1)의 크기보다 크다. 결과적으로, 대역폭 요건들이 또한 오디오 및/또는 비디오 품질에 따라 증가한다.
도 3은 오디오 및/또는 비디오 콘텐츠 전달 시스템(100)의 범위에서 사용 가능한 하드웨어 아키텍처(300)의 예를 개략적으로 나타낸다. 하드웨어 아키텍처(300)는 에지 캐시 서버(ECS)(132)와 같은 캐싱 플랫폼의 일부일 수 있다. 하드웨어 아키텍처(300)는 중앙 컨트롤러(CC)(111)와 같은 중앙 장비(CE)(110)의 일부일 수 있다. 하드웨어 아키텍처(300)는 단말기(T)(150)의 일부일 수 있다.
하드웨어 아키텍처(300)는 통신 버스(310)에 의해 상호접속된 다음의 컴포넌트들을 포함한다: 프로세서, 마이크로프로세서, 마이크로컨트롤러 또는 CPU(Central Processing Unit)(301); RAM(Random-Access Memory)(302); ROM(Read-Only Memory)(303), 예컨대 EEPROM(Electrically Erasable Programmable ROM), 예를 들어 플래시 메모리; HDD(Hard-Disk Drive), 또는 SD(Secure Digital) 카드 판독기(304)와 같은 저장 매체에 저장된 정보를 판독하도록 적응된 임의의 다른 디바이스; 적어도 하나의 통신 인터페이스(COM)(305).
CPU(301)는 ROM(303)으로부터, 또는 HDD(304) 또는 SD 카드와 같은 외부 메모리로부터 RAM(302)에 로딩된 명령어들을 실행할 수 있다. 하드웨어 아키텍처(300)가 파워 온된 후에, CPU(301)는 RAM(302)으로부터 명령어들을 판독하고 이 명령어들을 실행할 수 있다. 명령어들은 CPU(301)로 하여금 캐싱 플랫폼들에 대해, 또는 중앙 장비(CE)(110)에 대해 또는 단말기들(T)(150)에 대해 본 명세서에 개시된 수행되는 단계들을 실행하게 하는 하나의 컴퓨터 프로그램을 형성한다.
이에 따라, 본 명세서에서 설명되는 단계들 및 알고리즘들은 PC, DSP(Digital Signal Processor) 또는 프로세서와 같은 프로그래밍 가능 컴퓨팅 기계에 의한 명령어들의 세트 또는 프로그램의 실행에 의해 소프트웨어 형태로 구현될 수 있거나; 그렇지 않으면 FPGA(Field-Programmable Gate Array) 또는 ASIC(Application-Specific Integrated Circuit)와 같은 기계 또는 전용 컴포넌트, 칩 또는 칩셋에 의해 하드웨어 형태로 구현될 수 있다. 보다 일반적으로, 캐싱 플랫폼들, 중앙 장비(CE)(110), 및 모바일 단말기들(T)(150)은 해당 디바이스 또는 장비와 관련하여 본 명세서에 설명된 단계들 및 알고리즘들을 수행하도록 구성된 전자 회로를 포함한다.
도 4는 적응적 스트리밍을 사용하여 나중에 하나 이상의 오디오 및/또는 비디오 콘텐츠를 전달하기 위해 적절한 캐싱 플랫폼을 선택하는 데 사용 가능한 정보를 획득하고 저장하기 위한 알고리즘을 개략적으로 나타낸다. 하나 이상의 오디오 및/또는 비디오 콘텐츠는 낮은 레이턴시로 전달되어야 하며, 그렇기 때문에 바람직하게는 라이브 콘텐츠이다.
단계(400)에서, 중앙 컨트롤러(CC)(111)는 각각의 캐싱 플랫폼으로부터 물리적 RTT(왕복 시간) 정보를 획득한다. 물리적 RTT는, 트래픽 과부하에 의해 초래되는 것이 아니라, 전형적으로 거리(예를 들어, 와이어 길이) 및 스위치/라우터 처리 시간에 관련되는, 물리적 경로에 의해 초래되는 RTT를 의미한다. 각각의 캐싱 플랫폼으로부터의 물리적 RTT 정보는 상기 캐싱 플랫폼과 상기 캐싱 플랫폼이 오디오 및/또는 비디오 콘텐츠를 전달할 수 있는 단말기(T)(150) 사이의 예상 RTT(즉, 단말기(T)(150)가 상기 캐싱 플랫폼으로부터 오디오 및/또는 비디오 콘텐츠의 전달을 획득할 때 초래될 것으로 예상되는 RTT)에 대응한다. 물리적 RTT 정보는 오디오 및/또는 비디오 콘텐츠를 단말기(T)(150)에 전달할 때 과거 이력에서 초래된 최소 RTT의 최대(가장 큰 값), 및/또는 오디오 및/또는 비디오 콘텐츠를 단말기(T)(150)에 전달할 때 과거 이력에서 초래된 최소 RTT의 평균이다.
선택적인 단계(401)에서, 중앙 컨트롤러(CC)(111)는 각각의 캐싱 플랫폼으로부터 부하 정보를 획득한다. 부하 정보는 상대적으로 캐싱 플랫폼에 대한 자원 점유율을 나타낸다. 부하 정보는 예를 들어 캐싱 플랫폼에서 사용되고 있는 처리 및/또는 메모리 자원의 백분율이다. 부하 정보는 예를 들어 캐싱 플랫폼에서의 이용 가능한 처리 및/또는 메모리 자원의 양이다. 부하 정보는 예를 들어 캐싱 플랫폼에 의해 여전히 수용될 수 있는 나머지 세션들의 양이다.
단계들 400 및 401은 캐싱 플랫폼들(즉, 도 1에서의 에지 캐시 서버들(ECS)(132))과 중앙 컨트롤러(CC)(111) 사이의 메시지들의 송신들에 의해 수행된다. 물리적 RTT 정보 및/또는 부하 정보의 송신은, 전형적으로 정기적으로 또는 특정 이벤트가 발생할 때, 캐싱 플랫폼들에 의해 개시될 수 있다. 물리적 RTT 정보 및/또는 부하 정보의 송신은 중앙 컨트롤러(CC)(111)로부터의 요청들에 응답하여 수행될 수 있다. 물리적 RTT 정보 및/또는 부하 정보의 송신은 공동으로 수행될 수 있다. 캐싱 플랫폼들과 중앙 컨트롤러(CC)(111) 간의 통신들을 보장하기 위해 중간 컨트롤러들이 사용될 수 있다.
단계(402)에서, 중앙 컨트롤러(CC)(111)는 고려될 하나 이상의 오디오 및/또는 비디오 콘텐츠에 대해 지원될 각각의 표현 비트레이트에 대한 정보를 획득한다.
이용 가능한 표현 비트레이트들은 오디오 및/또는 비디오 콘텐츠마다 상이할 수 있다. 이 경우에, 중앙 컨트롤러(CC)(111)는 각각의 오디오 및/또는 비디오 콘텐츠에 대해 독립적으로 도 4의 알고리즘을 실행할 수 있다.
이용 가능한 표현 비트레이트들은 원천 서버마다 상이할 수 있다. 예를 들어, 오디오 및/또는 비디오 콘텐츠 전달 시스템(100)은 복수의 테넌트(tenant)들 또는 콘텐츠 제공자들에 대해 동작한다. 각각의 테넌트 또는 콘텐츠 제공자(및 그들의 대응하는 원천 서버들)는 복수의 비트레이트들을 의미하는, 복수의 표현들로 오디오 및/또는 비디오 콘텐츠를 제공한다. 표현 비트레이트들은 테넌트 또는 콘텐츠 제공자마다(예를 들어, 프리미엄 콘텐츠 제공자 대 저비용 콘텐츠 제공자) 상이할 수 있다. 이 경우에, 중앙 컨트롤러(CC)(111)는 각각의 테넌트 또는 콘텐츠 제공자에 대해 독립적으로 도 4의 알고리즘을 실행할 수 있으며, 따라서 나중에 오디오 및/또는 비디오 콘텐츠를 전달하기 위한 적절한 캐싱 플랫폼의 선택이 각각의 테넌트 또는 콘텐츠 제공자에 대해 맞춤화된 방식으로 수행된다.
N개의 표현이 지원되는 것으로 가정하면, 각각의 표현은 평균 비트레이트들(Bi)(i = 1,..,N)을 가지며, 여기서 i = 1은 최저 비트레이트 표현(최저 품질)을 나타내고, i = N은 최고 비트레이트 표현(최고 품질)을 나타낸다.
단계(403)에서, 중앙 컨트롤러(CC)(111)는, 각각의 캐싱 플랫폼에 대해, 다음과 같이, 상기 캐싱 플랫폼에 대해 단계(400)에서 획득된 물리적 RTT 정보의 함수로서, 최소 버스트 전송 크기 mTBS를 계산하며:
mTBS = C0*BN*RTT
여기서 C0은 RTT 정보의 잠재적 근사화를 보상하는 사전 정의된 마진을 더하는 (양의) 상수이다. C0의 정의는 캐싱 플랫폼이 (LL HLS 기술의 하나의 동작 모드에서와 같이) 청크별 요청들에 응답하는지 또는 캐싱 플랫폼이 (MPEG DASH 기술에서와 같이) 세그먼트별 요청들에 응답하는지에 의존한다. C0은 또한 BN을 포함한 Bi가 평균 비트레이트 표시임을 보상한다(이는 유효 비트레이트가 이러한 평균 비트레이트 표시 부근에서 달라질 수 있다는 것을 의미함).C0은 또한, 사용되고 있는 적응적 스트리밍 기술을 고려하여, 사용되고 있는 대역폭 추정이 유효 RTT에 또는 이 값의 절반에 의존할 수 있다는 것을 보상할 수 있다. 실제로, (MPEG DASH 기술에서와 같이) 세그먼트별 요청들에 대해, 대역폭 추정은 절반 RTT에 의존할 수 있는 반면, (LL HLS 기술의 하나의 동작 모드에서와 같이) 청크별 요청들에 대해, 대역폭 추정은 RTT에 의존할 수 있다.
단계(404)에서, 중앙 컨트롤러(CC)(111)는, 각각의 캐싱 플랫폼에 대해, 다음과 같이, 지원되는 각각의 표현 i (i = 1,..,N)에 대해, 최소 버스트 전송 지속기간(mTBDi)을 계산한다:
mTBDi = mTBS / Bi
최소 버스트 전송 지속기간(mTBDi)(i = 1,..,N)은 상기 캐싱 플랫폼에 대한 물리적 RTT 정보를 고려하여 오디오 및/또는 비디오 콘텐츠를 캐싱 플랫폼으로부터 단말기(T)(150)로 전달할 때 효과적인 대역폭 추정에 적합할 버스트 전송 지속기간에 대응한다.
특정 실시예에서, 중앙 컨트롤러(CC)(111)는, 각각의 캐싱 플랫폼에 대해, 하나 이상의 오디오 및/또는 비디오 콘텐츠에 대해 이용 가능한 최저 비트레이트 표현(i = 1)에 대해서만 최소 버스트 전송 지속기간(mTBDi)을 계산한다.
단계(405)에서, 중앙 컨트롤러(CC)(111)는, 각각의 캐싱 플랫폼에 대해, 단계(404)에서 계산된 최소 버스트 전송 지속기간(mTBDi)을 메모리에 저장하고, 이는 이어서, 도 5에 관하여 이후에 개시되는 바와 같이, 오디오 및/또는 비디오 콘텐츠를 전달하기 위한 가능한 캐싱 플랫폼들 중에서 하나의 캐싱 플랫폼을 적절히 선택하기 위해 중앙 컨트롤러(CC)(111)에 의해 나중에 사용된다.
도 4에서의 알고리즘은 정기적으로 실행될 수 있다. 도 4에서의 알고리즘은 캐싱 플랫폼으로부터의 물리적 RTT 정보가 사전 정의된 임계치 위로 어느 정도 변경되었음을 나타내는 이벤트의 수신 시에 실행될 수 있다. 도 4에서의 알고리즘은 새로운 캐싱 플랫폼이 오디오 및/또는 비디오 콘텐츠 전달 시스템(100)에 추가됨을 나타내는 이벤트의 수신 시에 실행될 수 있다. 도 4에서의 알고리즘은 새로운 테넌트 또는 콘텐츠 제공자(및 하나 이상의 대응하는 새로운 원천 서버)에 대해 오디오 및/또는 비디오 전달 서비스들이 제공되어야 한다는 것을 나타내는 이벤트의 수신 시에 실행될 수 있다.
부하 정보가 또한 별개의 프로세스에서 제공될 수 있다. 부하 정보 업데이트는 미리 정의된 임계치 위로 어느 정도의 변화가 발생할 때(예를 들어, 마지막 업데이트 이후로 총 자원들의 10%가 해제되거나 할당되었을 때) 캐싱 플랫폼들에 의해 중앙 컨트롤러(CC)(111)에 제공될 수 있다.
중앙 컨트롤러(CC)(111)는 단말기(T)(150)에 대한 세션 요청을 처리할 때 상기 단말기(T)(150)에 오디오 및/또는 비디오 콘텐츠를 전달하는 데 사용될 캐싱 플랫폼을 선택하기로 결정한다. 상기 세션 요청은, 해당 오디오 및/또는 비디오 콘텐츠 전달 세션을 핸들링하기 위해, 오디오 및/또는 비디오 콘텐츠 전달 세션이 새롭게 관리되어야 하고(전형적으로, 새로운 오디오 및/또는 비디오 콘텐츠 전달 세션이 마련되어야 함) 적절한 캐싱 플랫폼이 선택되어야 하며, 심지어 잠재적으로 배치(활성화)되어야 함을 나타낸다. 예를 들어, 세션 요청은 오디오 및/또는 비디오 콘텐츠와 연관된 매니페스트 파일 또는 플레이리스트를 획득하기 위한 요청의 형태를 취한다. "매니페스트 파일"은 MPEG DASH 기술에서 사용되는 용어이고, "플레이리스트"는 HLS 기술에서 사용되는 용어이다. 매니페스트 파일 또는 플레이리스트는, 청크 지속기간 정보(HLS 용어에 따라 부분 세그먼트들로 불리는 청크들)를 포함하여, 세션 요청이 참조하는 오디오 및/또는 비디오 콘텐츠에 대해 이용 가능한 표현들에 관한 정보를 수집한다. 상기 세션 요청은 관련된 단말기(T)(150)로부터 중앙 컨트롤러(CC)(111)에 의해 직접 수신될 수 있다. 상기 세션 요청은 하나의 상기 캐싱 플랫폼에 의해 중앙 컨트롤러(CC)(111)에 통지될 수 있다. 상기 세션 요청은, 중간 컨트롤러로서 동작하고 하나 이상의 캐싱 플랫폼들을 국소적으로 관리하는 오디오 및/또는 비디오 콘텐츠 전달 시스템(100)의 에지 컨트롤러에 의해 중앙 컨트롤러(CC)(111)에 통지될 수 있다.
도 5는 일 실시예에서, 중앙 컨트롤러(CC)(111)에 의해 세션 요청들을 관리하기 위한 알고리즘을 개략적으로 나타낸다.
단계(501)에서, 중앙 컨트롤러(CC)(111)는 단말기(T)(150)에 대한 세션 요청을 처리한다. 위에서 설명된 바와 같이, 세션 요청은 오디오 및/또는 비디오 콘텐츠를 상기 단말기(T)(150)에 전달하기 위해 상기 단말기(T)(150)에 대하여 셋업될 세션을 나타낸다.
단계(502)에서, 중앙 컨트롤러(CC)(111)는 오디오 및/또는 비디오 콘텐츠를 단말기(T)(150)에 전달할 수 있는 이용 가능한 캐싱 플랫폼들을 열거한다. 이에 따라 중앙 컨트롤러(CC)(111)는 해당 단말기(T)(150)에 오디오 및/또는 비디오 콘텐츠를 전달하기 위한, 오디오 및/또는 비디오 콘텐츠 전달 시스템(100)의 후보 캐싱 플랫폼들의 세트로서 리스트(L0)를 형성한다. 중앙 컨트롤러(CC)(111)는 미리 결정된 지리적 영역에 배치되거나 미리 결정된 지리적 영역에서 활성화(예를 들어, 에지 클라우들릿에서의 캐싱 플랫폼 인스턴스의 동적 활성화)될 수 있는 오디오 및/또는 비디오 콘텐츠 전달 시스템(100)의 캐싱 플랫폼들인 것으로서 상기 후보 캐싱 플랫폼들의 세트를 정의할 수 있다. 예를 들어, 네트워크 기반구조가 모바일 네트워크 기반구조일 때, 단말기(T)(150)가 위치되는 셀은 해당 단말기(T)(150)로부터 발신되는 메시지들에 표시되며, 따라서 중앙 컨트롤러(CC)(111)는 단말기(T)(150)가 어느 지리적 영역에 위치되는지를, 그리고 그에 따라 어느 캐싱 플랫폼들이 오디오 및/또는 비디오 콘텐츠를 단말기(T)(150)에 전달할 수 있는지를 결정할 수 있다. 예를 들어, 지리적 영역은 단말기(T)(150)를 둘러싸는 모바일 네트워크 셀들의 미리 결정된 세트의 상류측에 있는 네트워크 기반구조의 일부인 것으로서 결정된다.
단계(503)에서, 중앙 컨트롤러(CC)(111)는, 리스트(L0)로부터, 해당 오디오 및/또는 비디오 콘텐츠의 전달에 적용 가능한 청크 지속기간 이하인, 도 4의 알고리즘에 따라 저장된 바와 같은, 최소 버스트 전송 지속기간(mTBDi)을 나타내는 캐싱 플랫폼들을 열거한다. 이에 따라 중앙 컨트롤러(CC)(111)는 해당 단말기(T)(150)에 오디오 및/또는 비디오 콘텐츠를 전달하기 위한, 오디오 및/또는 비디오 콘텐츠 전달 시스템(100)의 후보 캐싱 플랫폼들의 정제된 세트로서 리스트(L1)를 형성한다. 이미 언급된 바와 같이, 청크 지속기간뿐만 아니라, 적응적 스트리밍을 위한 이용 가능한 표현들은 세션 요청에 의해 관련된 테넌트 또는 콘텐츠 제공자(및 대응하는 원천 서버)에 의존한다. 예를 들어, 중앙 컨트롤러(CC)(111)는 세션 요청에 표시된 또는 그로부터 복사되거나 인용되었을 수 있는 URI(Uniform Resource Identifier) 경로를 분석함으로써 관련된 원천 서버를 나타내는 식별자(예를 들어, 해당 테넌트 또는 콘텐츠 제공자의 식별자)를 검색할 수 있다.
단계(504)에서, 중앙 컨트롤러(CC)(111)는 리스트(L1)가 충분한 후보 캐싱 플랫폼들을 포함하는지를 체크한다. 예를 들어, 중앙 컨트롤러(CC)(111)는 리스트(L1)가 비어 있지 않은지를 체크한다. 다른 예에 따르면, 중앙 컨트롤러(CC)(111)는 후보 캐싱 플랫폼들 중에서 충분한 선택 가능성을 갖기 위해 리스트(L1)의 카디널리티가 미리 정의된 임계치(TH_L1)보다 큰지를 체크한다. 리스트(L1)가 충분한 후보 캐싱 플랫폼들을 포함할 때, 단계(505)가 수행되고; 그렇지 않으면, 단계(506)가 수행된다.
단계(505)에서, 중앙 컨트롤러(CC)(111)는 리스트(L1)로부터 캐싱 플랫폼을 선택한다. 복수의 캐싱 플랫폼이 리스트(L1) 내에 존재할 때, 중앙 컨트롤러(CC)(111)는 미리 정의된 선택 규칙들을 적용한다. 섹션 규칙들은 부하 균형화 규칙들 및/또는 부하 공유 규칙들 및/또는 에너지 소비 최적화 규칙들 및/또는 대역폭 소비 최적화 규칙들(예를 들어, 그에 부착된 단말기들(T)(150)을 향한 이용 가능한 다운링크 대역폭을 고려하여 캐싱 플랫폼에 의해 동시에 핸들링되는 동시 세션들의 양)을 포함할 수 있다. 예를 들어, 중앙 컨트롤러(CC)(111)는 도 4의 알고리즘의 실행 중에 획득된 부하 정보를 고려하여 부하가 더 적은 캐싱 플랫폼을 선택한다. 적절한 캐싱 플랫폼의 선택은 여기서 서술되지 않은 하나 이상의 다른 기준의 함수로서 수행될 수 있다. 이어서 단계(510)가 수행된다.
단계(506)에서, 중앙 컨트롤러(CC)(111)는, 리스트(L0)로부터, 해당 오디오 및/또는 비디오 콘텐츠의 전달에 적용 가능한 청크 지속기간의 (정수) 배인 미리 정의된 임계치(TH) 이하인, 도 4의 알고리즘에 따라 저장된 바와 같은, 최소 버스트 전송 지속기간(mTBDi)을 나타내는 캐싱 플랫폼들을 열거한다. 예를 들어, 임계치(TH)는 청크 지속기간(예를 들어, 250 밀리초)의 2배이다. 이에 따라 중앙 컨트롤러(CC)(111)는 해당 단말기(T)(150)에 오디오 및/또는 비디오 콘텐츠를 전달하기 위한, 오디오 및/또는 비디오 콘텐츠 전달 시스템(100)의 후보 캐싱 플랫폼들의 정제된 세트로서 리스트(L2)를 형성한다.
단계(507)에서, 중앙 컨트롤러(CC)(111)는 리스트(L2)가 충분한 후보 캐싱 플랫폼들을 포함하는지를 체크한다. 예를 들어, 중앙 컨트롤러(CC)(111)는 리스트(L2)가 비어 있지 않은지를 체크한다. 다른 예에 따르면, 중앙 컨트롤러(CC)(111)는 후보 캐싱 플랫폼들 중에서 충분한 선택 가능성을 갖기 위해 리스트(L2)의 카디널리티가 (TH_L1과 동일할 수 있는) 미리 정의된 임계치(TH_L2)보다 큰지를 체크한다. 리스트(L2)가 충분한 후보 캐싱 플랫폼들을 포함할 때, 단계(508)가 수행되고; 그렇지 않으면, 단계(509)가 수행된다.
단계(508)에서, 중앙 컨트롤러(CC)(111)는 리스트(L2)로부터 캐싱 플랫폼을 선택한다. 복수의 캐싱 플랫폼이 리스트(L2) 내에 존재할 때, 중앙 컨트롤러(CC)(111)는 미리 정의된 선택 규칙들을 적용한다. 섹션 규칙들은 부하 균형화 규칙들 및/또는 부하 공유 규칙들 및/또는 에너지 소비 최적화 규칙들 및/또는 대역폭 소비 최적화 규칙들(예를 들어, 그에 부착된 단말기들(T)(150)을 향한 이용 가능한 다운링크 대역폭을 고려하여 캐싱 플랫폼에 의해 동시에 핸들링되는 동시 세션들의 양)을 포함할 수 있다. 예를 들어, 중앙 컨트롤러(CC)(111)는 도 4의 알고리즘의 실행 중에 획득된 부하 정보를 고려하여 부하가 더 적은 캐싱 플랫폼을 선택한다. 적절한 캐싱 플랫폼의 선택은 여기서 서술되지 않은 하나 이상의 다른 기준의 함수로서 수행될 수 있다. 단계(508)에서 적용된 선택 규칙들은 단계(505)에서 적용된 선택 규칙들과는 상이할 수 있다. 이어서 단계(510)가 수행된다.
단계(509)에서, 중앙 컨트롤러(CC)(111)는 리스트(L0)로부터 캐싱 플랫폼을 선택한다. 복수의 캐싱 플랫폼이 리스트(L0) 내에 존재할 때, 중앙 컨트롤러(CC)(111)는 미리 정의된 선택 규칙들을 적용한다. 섹션 규칙들은 부하 균형화 규칙들 및/또는 부하 공유 규칙들 및/또는 에너지 소비 최적화 규칙들 및/또는 대역폭 소비 최적화 규칙들(예를 들어, 그에 부착된 단말기들(T)(150)을 향한 이용 가능한 다운링크 대역폭을 고려하여 캐싱 플랫폼에 의해 동시에 핸들링되는 동시 세션들의 양)을 포함할 수 있다. 예를 들어, 중앙 컨트롤러(CC)(111)는 도 4의 알고리즘의 실행 중에 획득된 부하 정보를 고려하여 부하가 더 적은 캐싱 플랫폼을 선택한다. 적절한 캐싱 플랫폼의 선택은 여기서 서술되지 않은 하나 이상의 다른 기준의 함수로서 수행될 수 있다. 단계(510)에서 적용된 선택 규칙들은 단계(505)에서 그리고/또는 단계(508)에서 적용된 선택 규칙들과는 상이할 수 있다. 이어서 단계(510)가 수행된다.
오디오 및/또는 비디오 콘텐츠를 전달하기 위한 서버들은 비교적 작은 클라우드 기반구조(클라우들릿으로도 지칭됨)에 배치되는 가상 인스턴스들로서 캐싱 플랫폼들에서 구현될 수 있다. 이 경우에, 캐싱 플랫폼이 선택될 때, 중앙 컨트롤러(CC)(111)는 선택된 캐싱 플랫폼 내의 새로운 서버를 활성화하거나, 전개/인스턴스화해야 할 수 있다. 전형적으로, 중앙 컨트롤러(CC)(111)는 그렇게 하도록 클라우들릿 서버 인스턴스화를 관리하는 컨트롤러에게 강요한다. 그러한 서버가 활성화되었을 때, 중앙 컨트롤러(CC)(111)는 미리 정의된 규칙들에 관하여 부하 균형화 또는 적절한 부하 공유를 수행하기 위해 해당 오디오 및/또는 비디오 콘텐츠에 대한 하나 이상의 세션들을 상기 오디오 및/또는 비디오 콘텐츠를 전달하는 다른 캐싱 플랫폼으로(전형적으로, 새롭게 활성화된 클라우들릿 서버로) 재지향시키도록 오디오 및/또는 비디오 콘텐츠 전달 시스템(100)에게 강요할 수 있다.
단계(510)에서, 중앙 컨트롤러(CC)(111)는 단말기(T)(150)가 세션 요청을 다시 제출하지만 이제 선택된 캐싱 플랫폼에 질의하도록 강제하기 위해 해당 단말기(T)(150)를 선택된 캐싱 플랫폼을 향해 재지향시킨다. 그렇게 하기 위해, 중앙 컨트롤러(CC)(111)는 해당 단말기(T)(150)에 재지향 메시지(예를 들어, HTTP 재지향)를 송신한다. 재지향 메시지는 해당 단말기(T)(150)가 어느 선택된 캐싱 플랫폼에 세션 요청을 다시 제출할지를 결정할 수 있게 하는 정보를 포함하거나, 중앙 컨트롤러(CC)(111)는 해당 단말기T(150)에 의한 세션 요청의 새로운 제출이 선택된 캐싱 플랫폼에 도달하는 것을 보장하도록 네트워크 기반구조(전형적으로 그 안에 구현된 브레이크아웃 기능들)에게 강요한다.
도 6은 다른 실시예에서 중앙 컨트롤러(CC)(111)에 의해 세션 요청들을 관리하기 위한 알고리즘을 개략적으로 나타낸다.
단계(600)에서, 중앙 컨트롤러(CC)(111)는 단말기(T)(150)에 대한 세션 요청을 처리한다. 위에서 설명된 바와 같이, 세션 요청은 오디오 및/또는 비디오 콘텐츠를 전달하기 위해 상기 단말기(T)(150)에 대하여 셋업될 세션을 나타낸다. 단계(600)는 단계(501)와 동일하다.
단계(601)에서, 중앙 컨트롤러(CC)(111)는 오디오 및/또는 비디오 콘텐츠를 단말기(T)(150)에 전달할 수 있는 이용 가능한 캐싱 플랫폼들을 열거한다. 이에 따라 중앙 컨트롤러(CC)(111)는 해당 단말기(T)(150)에 오디오 및/또는 비디오 콘텐츠를 전달하기 위한, 오디오 및/또는 비디오 콘텐츠 전달 시스템(100)의 후보 캐싱 플랫폼들의 세트로서 리스트(L0)를 형성한다. 단계(601)는 단계(502)와 동일하다.
단계(602)에서, 중앙 컨트롤러(CC)(111)는 부하 제약과 같은 적어도 하나의 미리 정의된 기준을 충족시키지 않는 캐싱 플랫폼들을 리스트(L0)로부터 철회한다. 미리 정의된 임계치(예를 들어, 처리 및/또는 메모리 자원들의 80%) 미만의, 도 4의 알고리즘을 실행할 때 획득된 바와 같은, 부하 정보를 나타내는 캐싱 플랫폼은 부하 제약을 충족시키는 것으로 간주된다. 다른 기준들은 에너지 소비 및/또는 대역폭 소비, 또는 다른 것, 또는 이들의 조합들에 관련될 수 있다.
단계(603)에서, 중앙 컨트롤러(CC)(111)는 파라미터 y를 1로 설정한다. 파라미터 y는 고려 중인 표현(즉, 품질)을 나타낸다.
단계(604)에서, 중앙 컨트롤러(CC)(111)는 i = y에 대한 최소 버스트 전송 지속기간(mTBDi)을 고려함으로써 캐싱 플랫폼 선택 라운드를 수행한다. 캐싱 플랫폼 선택 라운드는 이미 설명된 단계들(503 내지 508)에 대응한다. 단계(605)에서, 중앙 컨트롤러(CC)(111)는 (단계들(505 및 508)에서와 같이) 캐싱 플랫폼 선택이 가능한지를 체크한다. 캐싱 플랫폼 선택이 가능한 경우, 단계(608)가 수행되고; 그렇지 않으면 (단계(509)를 수행하는 대신에), 단계(606)가 수행된다.
단계(606)에서, 중앙 컨트롤러(CC)(111)는 하나 이상의 표현이 조사되어야 하는지(즉, y ≠ N일 때)를 체크한다. 하나 이상의 표현이 조사되어야 할 때, 단계(607)가 수행되고; 그렇지 않으면, 단계(610)가 수행된다.
단계(607)에서, 중앙 컨트롤러(CC)(111)는 파라미터 y를 하나의 단위만큼 증분시키고, 단계(604)가 이러한 새롭게 선택된 표현에 대해 최소 버스트 전송 지속기간(mTBDi)으로 반복된다.
단계(608)에서, 중앙 컨트롤러(CC)(111)는 어느 것이든 적용 가능한 것에 따라 단계들(505 및 508)에서와 같이 캐싱 플랫폼을 선택하고, 단계(609)에서, 중앙 컨트롤러(CC)(111)는 단말기(T)(150)가 세션 요청을 다시 제출하지만 이제 선택된 캐싱 플랫폼에 질의하도록 강제하기 위해 해당 단말기(T)(150)를 선택된 캐싱 플랫폼을 향해 재지향시킨다. 단계(609)는 단계(510)와 동일하다.
단계(610)에서, 중앙 컨트롤러(CC)(111)는 단계(602)에서 철회된 캐싱 플랫폼들을 리스트(L0)에 재도입하여, 캐싱 플랫폼들의 세트를 확대한다(하지만, 예를 들어 재도입된 캐싱 플랫폼들은 고도로 로딩될 수 있음).

Claims (15)

  1. 네트워크 기반구조의 최상부에 배치된 오디오 및/또는 비디오 콘텐츠 전달 시스템에 의해 적응적 스트리밍을 사용하여 오디오 및/또는 비디오 콘텐츠를 단말기에 전달하기 위한 방법으로서, 상기 오디오 및/또는 비디오 콘텐츠 전달 시스템은 컨트롤러 및 복수의 캐싱 플랫폼들을 포함하고, 상기 오디오 및/또는 비디오 콘텐츠는 각자의 오디오 및/또는 비디오 품질들을 갖는 다양한 표현(representation)들로 이용 가능한 데이터 세그먼트들로 세그먼트화되고, 상기 표현들은 상기 오디오 및/또는 비디오 콘텐츠에 대해 동일한 청크 지속기간(chunk duration)을 갖는 청크들로 추가로 분할되는 세그먼트들마다 시간-정렬되고, 상기 방법은, 각각의 캐싱 플랫폼에 대해, 상기 컨트롤러에 의해 수행되는,
    - 상기 네트워크 기반구조를 통해 해당 상기 캐싱 플랫폼에 의해 오디오 및/또는 비디오 콘텐츠들을 단말기들에 전달하는 것에 대해 해당 상기 캐싱 플랫폼에 관한 물리적 왕복 시간 정보를 획득하는 단계;
    - 상기 오디오 및/또는 비디오 콘텐츠의 상기 다양한 표현들의 최대 평균 비트레이트로부터, 그리고 상기 획득된 물리적 왕복 시간 정보로부터 최소 버스트 전송 크기(mTBS)를 계산하는 단계;
    - 상기 최소 버스트 전송 크기(mTBS)로부터, 상기 오디오 및/또는 비디오 콘텐츠의 하나 이상의 표현들(i)에 대한, 최소 버스트 전송 지속기간(mTBDi)을 계산하는 단계를 포함하고,
    상기 오디오 및/또는 비디오 콘텐츠가 상기 단말기에 전달되어야 할 때, 상기 방법은 상기 컨트롤러에 의해 수행되는,
    - 후보 캐싱 플랫폼들의 세트(L0)로부터, 상기 오디오 및/또는 비디오 콘텐츠의 하나 이상의 표현들(i)에 대해 계산된 상기 최소 버스트 전송 지속기간(mTBDi)의 함수로서, 상기 오디오 및/또는 비디오 콘텐츠를 상기 단말기에 전달하는 데 사용될 상기 캐싱 플랫폼을 선택하는 단계; 및
    - 청크들의 버스트들의 형태의 상기 오디오 및/또는 비디오 콘텐츠의 추가 전달을 위해 상기 단말기를 상기 선택된 플랫폼으로 재지향시키는 단계를 포함하고,
    사용될 상기 캐싱 플랫폼을 선택하기 위해, 상기 컨트롤러는,
    - 상기 후보 캐싱 플랫폼들의 세트(L0)로부터, 해당 상기 오디오 및/또는 비디오 콘텐츠의 상기 전달에 적용 가능한 상기 청크 지속기간 이하인, 상기 오디오 및/또는 비디오 콘텐츠의 상기 i의 하나 이상의 표현들에 대한 최소 버스트 전송 지속기간(mTBDi)을 나타내는 상기 캐싱 플랫폼들을 포함하는 리스트(L1)를 형성하고, 상기 리스트(L1)의 카디널리티(cardinality)가 미리 정의된 임계치 초과일 때, 상기 리스트(L1)로부터 사용될 상기 캐싱 플랫폼을 선택하는 단계; 및
    - 그렇지 않으면, 상기 후보 캐싱 플랫폼들의 세트(L0)로부터, 해당 상기 오디오 및/또는 비디오 콘텐츠의 상기 전달에 적용 가능한 상기 청크 지속기간의 배수인 미리 정의된 임계치(TH) 이하인 최소 버스트 전송 지속기간(mTBDi)을 나타내는 상기 캐싱 플랫폼들을 포함하는 리스트(L2)를 형성하고, 상기 리스트(L2)로부터 사용될 상기 캐싱 플랫폼을 선택하는 단계를 수행하는, 방법.
  2. 제1항에 있어서, 상기 물리적 왕복 시간 정보는 오디오 및/또는 비디오 콘텐츠를 단말기들에 전달할 때 과거 이력에서 초래된 최소 왕복 시간의 최대, 및/또는 오디오 및/또는 비디오 콘텐츠를 단말기들에 전달할 때 과거 이력에서 초래된 최소 왕복 시간의 평균을 나타내는, 방법.
  3. 제1항 또는 제2항에 있어서, 상기 컨트롤러는, 각각의 캐싱 플랫폼에 대해, 하나 이상의 상기 오디오 및/또는 비디오 콘텐츠들에 대해 이용 가능한 최저 비트레이트 표현에 대해서만, 즉 i = 1에 대해 상기 최소 버스트 전송 지속기간(mTBDi)을 계산하는, 방법.
  4. 제1항 내지 제3항 중 어느 한 항에 있어서, 상기 컨트롤러는 해당 상기 단말기 및 해당 상기 오디오 및/또는 비디오 콘텐츠에 관한 세션 요청을 처리할 때 상기 오디오 및/또는 비디오 콘텐츠를 상기 단말기에 전달하는 데 사용될 상기 캐싱 플랫폼을 선택하는, 방법.
  5. 제4항에 있어서, 상기 청크 지속기간뿐만 아니라, 상기 오디오 및/또는 비디오 콘텐츠의 이용 가능한 표현들은 상기 세션 요청에 의해 관련된 상기 오디오 및/또는 비디오 콘텐츠를 제공하는 원천 서버에 의존하고, 상기 컨트롤러는 상기 세션 요청에 표시된, 또는 상기 세션 요청으로부터 복사되거나 인용된 URI(Uniform Resource Identifier) 경로를 분석함으로써 해당 상기 원천 서버를 나타내는 식별자를 검색하는, 방법.
  6. 제1항 내지 제5항 중 어느 한 항에 있어서, 상기 컨트롤러는 상기 후보 캐싱 플랫폼들의 세트(L0)를, 미리 결정된 지리적 영역에 배치된 또는 상기 미리 결정된 지리적 영역에서 활성화될 수 있는 상기 오디오 및/또는 비디오 콘텐츠 전달 시스템의 상기 캐싱 플랫폼들인 것으로서 정의하는, 방법.
  7. 제6항에 있어서, 상기 네트워크 기반구조는 모바일 네트워크 기반구조이고, 상기 지리적 영역은 상기 단말기를 둘러싸는 모바일 네트워크 셀들의 미리 결정된 세트의 상류측에 있는 상기 네트워크 기반구조의 일부인 것으로서 결정되는, 방법.
  8. 제1항 내지 제7항 중 어느 한 항에 있어서, 상기 리스트(L2)의 카디널리티가 미리 정의된 임계치 이하일 때, 상기 컨트롤러는 상기 리스트(L0)로부터 사용될 상기 캐싱 플랫폼을 선택하는, 방법.
  9. 제1항 내지 제7항 중 어느 한 항에 있어서, 상기 컨트롤러는,
    - 적어도 하나의 미리 정의된 기준을 충족시키지 않는 캐싱 플랫폼들을 상기 리스트(L0)로부터 철회하는 단계;
    - 파라미터 y = 1로 여기서 지정된, 최저 표현을 선택하는 단계;
    - 상기 리스트(L1) 및 잠재적으로 상기 리스트(L2)를 형성함으로써 i = y에 대한 상기 최소 버스트 전송 지속기간(mTBDi)을 고려함으로써 캐싱 플랫폼 선택 라운드를 수행하는 단계를 수행하고,
    상기 리스트들(L1 및 L2)로부터 어떠한 선택도 발생하지 않을 때, 상기 파라미터 y는 하나의 단위만큼 증분되고, 상기 컨트롤러는 상기 파라미터 y에 의해 지정된 상기 표현에 대한 상기 최소 버스트 전송 지속기간(mTBDi)으로 다른 캐싱 플랫폼 선택 라운드를 수행하는, 방법.
  10. 제1항 내지 제9항 중 어느 한 항에 있어서, 상기 컨트롤러는 상기 단말기가 세션 요청을 다시 제출하지만 상기 컨트롤러에 질의하는 대신에 상기 선택된 캐싱 플랫폼에 질의하도록 강제함으로써 상기 단말기를 상기 선택된 캐싱 플랫폼을 향해 재지향시키는, 방법.
  11. 제1항 내지 제10항 중 어느 한 항에 있어서, 상기 네트워크 기반구조는 모바일 네트워크 기반구조이고, 상기 캐싱 플랫폼들은 상기 모바일 네트워크 기반구조의 클라우들릿(cloudlet)들에 배치되는, 방법.
  12. 네트워크 기반구조의 최상부에 배치된 오디오 및/또는 비디오 콘텐츠 전달 시스템에서 사용되도록 의도된 컨트롤러로서, 상기 오디오 및/또는 비디오 콘텐츠 전달 시스템은 상기 네트워크 기반구조를 통해 오디오 및/또는 비디오 콘텐츠를 전달하기 위한 복수의 캐싱 플랫폼들을 추가로 포함하고, 상기 오디오 및/또는 비디오 콘텐츠는 각자의 오디오 및/또는 비디오 품질들을 갖는 다양한 표현들로 이용 가능한 데이터 세그먼트들로 세그먼트화되고, 상기 표현들은 상기 오디오 및/또는 비디오 콘텐츠에 대해 동일한 청크 지속기간을 갖는 청크들로 추가로 분할되는 세그먼트들마다 시간-정렬되고, 상기 컨트롤러는, 각각의 캐싱 플랫폼에 대해,
    - 상기 네트워크 기반구조를 통해 해당 상기 캐싱 플랫폼에 의해 오디오 및/또는 비디오 콘텐츠들을 단말기들에 전달하는 것에 대해 해당 상기 캐싱 플랫폼에 관한 물리적 왕복 시간 정보를 획득하고;
    - 상기 오디오 및/또는 비디오 콘텐츠의 상기 다양한 표현들의 최대 평균 비트레이트로부터, 그리고 상기 획득된 물리적 왕복 시간 정보로부터 최소 버스트 전송 크기(mTBS)를 계산하고;
    - 상기 최소 버스트 전송 크기(mTBS)로부터, 상기 오디오 및/또는 비디오 콘텐츠의 하나 이상의 표현들(i)에 대한, 최소 버스트 전송 지속기간(mTBDi)을 계산하도록 구성된 전자 회로를 포함하고,
    상기 전자 회로는, 상기 오디오 및/또는 비디오 콘텐츠가 상기 단말기에 전달되어야 할 때,
    - 후보 캐싱 플랫폼들의 세트(L0)로부터, 상기 오디오 및/또는 비디오 콘텐츠의 하나 이상의 표현들(i)에 대해 계산된 상기 최소 버스트 전송 지속기간(mTBDi)의 함수로서, 상기 오디오 및/또는 비디오 콘텐츠를 상기 단말기에 전달하는 데 사용될 상기 캐싱 플랫폼을 선택하고;
    - 청크들의 버스트들의 형태의 상기 오디오 및/또는 비디오 콘텐츠의 추가 전달을 위해 상기 단말기를 상기 선택된 플랫폼으로 재지향시키도록 추가로 구성되고,
    상기 전자 회로는, 사용될 상기 캐싱 플랫폼을 선택하기 위해,
    - 상기 후보 캐싱 플랫폼들의 세트(L0)로부터, 해당 상기 오디오 및/또는 비디오 콘텐츠의 상기 전달에 적용 가능한 상기 청크 지속기간 이하인, 상기 오디오 및/또는 비디오 콘텐츠의 하나 이상의 표현들(i)에 대한 최소 버스트 전송 지속기간(mTBDi)을 나타내는 상기 캐싱 플랫폼들을 포함하는 리스트(L1)를 형성하고, 상기 리스트(L1)의 카디널리티가 미리 정의된 임계치 초과일 때, 상기 리스트(L1)로부터 사용될 상기 캐싱 플랫폼을 선택하고;
    - 그렇지 않으면, 상기 후보 캐싱 플랫폼들의 세트(L0)로부터, 해당 상기 오디오 및/또는 비디오 콘텐츠의 상기 전달에 적용 가능한 상기 청크 지속기간의 배수인 미리 정의된 임계치(TH) 이하인 최소 버스트 전송 지속기간(mTBDi)을 나타내는 상기 캐싱 플랫폼들을 포함하는 리스트(L2)를 형성하고, 상기 리스트(L2)로부터 사용될 상기 캐싱 플랫폼을 선택하도록 추가로 구성되는, 컨트롤러.
  13. 제12항에 따른 컨트롤러를 포함하는, 콘텐츠 전달 네트워크(CDN).
  14. 명령어들을 포함하는 컴퓨터 프로그램 제품으로서, 상기 명령어들은, 상기 명령어들이 프로세서에 의해 실행될 때, 제1항 내지 제11항 중 어느 한 항에 따른 방법의 구현을 야기하는, 컴퓨터 프로그램 제품.
  15. 제11항에 따른 컴퓨터 프로그램 제품을 저장하는, 정보 저장 매체.
KR1020237019439A 2020-11-13 2021-11-09 오디오 및/또는 비디오 콘텐츠 전달을 위한 방법 및 컨트롤러 KR20230101898A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP20306377.1A EP4002793B1 (en) 2020-11-13 2020-11-13 Method and controller for audio and/or video content delivery
EP20306377.1 2020-11-13
PCT/EP2021/081053 WO2022101176A1 (en) 2020-11-13 2021-11-09 Method and controller for audio and/or video content delivery

Publications (1)

Publication Number Publication Date
KR20230101898A true KR20230101898A (ko) 2023-07-06

Family

ID=73598024

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020237019439A KR20230101898A (ko) 2020-11-13 2021-11-09 오디오 및/또는 비디오 콘텐츠 전달을 위한 방법 및 컨트롤러

Country Status (9)

Country Link
US (1) US11973814B2 (ko)
EP (1) EP4002793B1 (ko)
JP (1) JP2023549778A (ko)
KR (1) KR20230101898A (ko)
CA (1) CA3197979A1 (ko)
ES (1) ES2968442T3 (ko)
IL (1) IL302710A (ko)
MX (1) MX2023005426A (ko)
WO (1) WO2022101176A1 (ko)

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7565450B2 (en) * 2000-03-16 2009-07-21 Adara Networks Inc. System and method for using a mapping between client addresses and addresses of caches to support content delivery
WO2002044915A1 (en) * 2000-11-30 2002-06-06 Appfluent Technology, Inc. System and method for delivering dynamic content
GB2456026A (en) * 2007-12-26 2009-07-01 Contendo Inc CDN balancing and sharing platform
WO2011073707A1 (en) * 2009-12-14 2011-06-23 Telefonaktiebolaget L M Ericsson (Publ) Dynamic cache selection method and system
PT2704391T (pt) * 2012-08-27 2019-08-07 Broadpeak Sistema e método para distribuição de conteúdo audio-visual para um dispositivo de cliente
US20150100667A1 (en) * 2013-10-08 2015-04-09 WePow, Inc. Optimizing content delivery
US10567461B2 (en) * 2016-08-04 2020-02-18 Twitter, Inc. Low-latency HTTP live streaming
US11363345B2 (en) * 2019-03-26 2022-06-14 Ssimwave Inc. Unified end-to-end quality and latency measurement, optimization and management in multimedia communications
US11997324B2 (en) * 2019-10-04 2024-05-28 Novi Digital Entertainment Private Limited Systems and methods for dynamic optimization of content delivery in a wireless communication network
EP3905708B1 (en) * 2020-04-27 2022-12-21 Broadpeak Method and server for audio and/or video content delivery

Also Published As

Publication number Publication date
JP2023549778A (ja) 2023-11-29
US11973814B2 (en) 2024-04-30
ES2968442T3 (es) 2024-05-09
EP4002793C0 (en) 2024-01-03
EP4002793B1 (en) 2024-01-03
US20230403313A1 (en) 2023-12-14
CA3197979A1 (en) 2022-05-19
EP4002793A1 (en) 2022-05-25
WO2022101176A1 (en) 2022-05-19
IL302710A (en) 2023-07-01
MX2023005426A (es) 2023-07-25

Similar Documents

Publication Publication Date Title
US9826016B2 (en) Fair adaptive streaming
KR102050816B1 (ko) 통신 네트워크에서 강화된 체감 품질을 위해 클라이언트 측 비디오 버퍼 점유율을 사용하기 위한 방법 및 시스템
US9438494B2 (en) Apparatus and methods for optimizing network data transmission
US20170041238A1 (en) Data flow control method
US8621061B2 (en) Adaptive bitrate management for streaming media over packet networks
Thomas et al. Enhancing MPEG DASH performance via server and network assistance
US9369391B2 (en) Flow management for data streams over cellular networks
KR102486847B1 (ko) 링크 인식 스트리밍 적응
US11812114B2 (en) Method and server for audio and/or video content delivery
Abuteir et al. SDN based architecture to improve video streaming in home networks
CN111031340B (zh) 自适应地传输数据流的方法和通信网络中的节点
CN111669665B (zh) 媒体流的实时推送方法及服务器
Clayman et al. The future of media streaming systems: transferring video over new IP
US11973814B2 (en) Method and controller for audio and/or video content delivery
WO2019120532A1 (en) Method and apparatus for adaptive bit rate control in a communication network
Livi et al. HTTP adaptive streaming and access router management: The users' and network's perspectives
Martin et al. On the Efficacy of the Dynamic Adaptive Streaming Over HTTP (DASH) Protocol
Martin et al. On the efficacy of the dynamic adaptive streaming over HTTP (DASH) protocol–extended version