KR101922281B1

KR101922281B1 - 대역폭을 제어하는 방법 및 이에 대응하는 디바이스

Info

Publication number: KR101922281B1
Application number: KR1020147010972A
Authority: KR
Inventors: 스테판느 구아쉬; 레미 우다이유
Original assignee: 톰슨 라이센싱
Priority date: 2011-09-26
Filing date: 2012-08-30
Publication date: 2018-11-26
Also published as: TWI559754B; CA2849952A1; TW201325207A; CA2849952C; US10333858B2; JP2014534489A; PL2761842T3; HK1200994A1; AU2012314756A1; CN103828327B; RU2604416C2; KR20140069256A; JP6268090B2; RU2014117037A; EP2761842B1; ZA201401777B; US20140250231A1; EP2761842A1; ES2690021T3; CN103828327A

Abstract

본 발명은 디바이스 또는 디바이스에서의 방법에 관한 것으로, 디바이스는 적응형 스트리밍 서버를 포함하는 제1 네트워크에 대한 제1 인터페이스, 적어도 하나의 적응형 클라이언트 디바이스를 포함하는 제2 네트워크에 대한 제2 인터페이스, 상기 적어도 하나의 적응형 스트리밍 클라이언트 디바이스에 의해 요청되고 하나보다 많은 데이터 레이트로 이용가능한 적어도 하나의 스트리밍 콘텐츠를 감지하기 위한 스트림 식별자, 상기 하나보다 많은 데이터 레이트 중에서 데이터 레이트를 선택하기 위한 대역폭 관리자, 상기 스트리밍 콘텐츠에 대해 이용가능한 상기 선택된 데이터 레이트보다 크고 어떤 높은 데이터 레이트보다 작은 데이터 레이트로 상기 제2 인터페이스에서 상기 적어도 하나의 클라이언트 디바이스로 상기 적어도 하나의 스트리밍 콘텐츠를 전송하기 위한 스케줄러를 포함한다.

Description

대역폭을 제어하는 방법 및 이에 대응하는 디바이스{METHOD FOR CONTROLLING BANDWIDTH AND CORRESPONDING DEVICE}

본 발명은 일반적으로 비디오 스트리밍 콘텐츠 분배에 관한 것으로서, 특히 비디오 스트리밍 콘텐츠에 의해 사용되는 대역폭 제어에 관한 것이다.

본 절은 이하에서 설명 및/또는 청구하는 본 발명의 다양한 특징과 관계될 수 있는 기술의 다양한 특징을 독자에게 소개하기 위한 것이다. 이 논의는 독자에게 배경 정보를 제공함으로써 본 발명의 다양한 특징을 더 잘 이해할 수 있도록 하는데 도움이 될 것이라고 믿는다. 따라서, 본 서술은 이러한 관점에서 읽어야하며, 종래기술의 인정으로 여겨서는 안 된다는 사실을 이해할 필요가 있다.

미디어 전달(delivery) 스트리밍 솔루션(solution)은 IETF RFC 2326에서 정의된 리얼 타임 스트리밍 프로토콜(Real time streaming Protocol: RTSP), 마이크로소프트(Microsoft)의 마이크로소프트 미디어 서버(Microsoft Media Server: MMS) 전용(proprietary) 프로토콜 또는 어도비 시스템즈(Adobe Systems)의 리얼 타임 메시징 프로토콜(Real Time Messaging Protocol: RTMP) 전용 프로토콜과 같은 프로토콜들에 주로 기초를 두고 있다.

인터넷을 통한 콘텐츠의 전달을 가능하게 하기 위해, HTTP 프로토콜에 기초한 스트리밍 기술들이 알려져 왔다. 이러한 기술들은 클라이언트 디바이스를 청크(chunk)라고 불리는, 작고 연속적인 작은 세그먼트들의 형태로, 수 초의 길이의 영상을 수신하도록 허용한다. 각 세그먼트는 HTTP 프로토콜을 통해 요청받고 다양한 변형들이 존재할 수 있으며, 이는 클라이언트 디바이스가 네트워크 및 그 고유의 제한과 매칭되는 적절한 비트 레이트(bit rate)를 언제나 선택할 수 있도록 허용한다. 상이한 비트 레이트는 전달된 콘텐츠의 상이한 품질 수준들(quality levels)에 대응한다. 클라이언트 디바이스에 의해 측정된 네트워크 대역폭이 감소하자마자, 그것은 네트워크 대역폭 요건에 관해 덜 제한적인 청크를 요청한다. 클라이언트 디바이스에 의해 측정된 네트워크 대역폭이 증가하면, 그것은 네트워크 대역폭 요건에 관해 더 제한적인 청크를 요청한다.

이용가능한 청크들은 일반적으로 스트리밍 서버에 의해 생성되고 제공되는 재생목록에 열거된다. 재생목록은 포맷의 타입당 하나와 같이 다른 재생목록들을 가리킬 수 있다. 재생목록들은 코덱 또는 그것을 다운로드 하기 위해 필요한 대역폭과 같은 청크 콘텐츠, 및 이들을 요청하기 위한 방법을 나타낸다. 재생목록 포맷은 다양한 SVC 레이어를 나타내는 코덱 정보로 확장되는 "HTTP Live Streaming draft, pantos, http-live-streaming, 06"의 문서에 기재된 하나일 수 있다.

다양한 HTTP 스트리밍 기술들이 이용가능하다. 애플(Apple) HTTP 라이브 스트리밍(HTTP Live Streaming: HLS)는 초안 RFC로 공개되었고, 그리고 주로 애플의 기기들에 사용된다. 마이크로소프트 스무드 스트리밍(Microsoft Smooth Streaming)은 마이크로소프트 실버라이트(Silverlight) 플랫폼의 일부이며, 사양은 공개적으로 이용가능하다. 어도비의 오픈 소스 미디어 프레임워크(Open Source Media Framework: OSMF)는 마이크로소프트의 솔루션과 가깝다. 3GPP는 패킷 교환 스트리밍(Packet Switched Streaming: PSS) 시스템을 위한 사양을 발표하였고; MPEG 워킹 그룹은 HTTP를 통한 동적 적응형 스트리밍(Dynamic Adaptive Streaming over HTTP: DASH)의 정의를 둘러싸고 또한 생성되었다. 이러한 스트리밍 솔루션들에서 HTTP 프로토콜을 사용하는 장점은 NAT 및 방화벽을 끊김없이(seamlessly) 지나갈 수 있다는 점이다. 이러한 HTTP 스트리밍 기술들은 대역폭 제한에 맞도록 비디오 품질을 연속적이고 적절하게 업그레이드 또는 다운그레이드함으로써 이용가능한 대역폭에 대한 불규칙한 네트워크 동작을 보상하는 방법을 제공한다.

일반적으로 HTTP 스트리밍 기술들은 동일한 개념에 기초한다. 이들은 재생목록의 파일 포맷들과, 콘텐츠 옵션들(비트 레이트, 이미지 크기들(image dimensions), 프레임 레이트)을 나타내도록 제공되는 메타 데이터(meta-data), 세그먼트들 내의 콘텐츠의 이용가능한 표현들(representations)의 구성, 지원되는 코덱들 및 콘텐츠 보호 기술들에 따라 다르다.

클라이언트 디바이스가 어떤 오디오/비디오 콘텐츠를 재생하고자 할 때, 먼저 이 특정 콘텐츠가 어떻게 획득될 수 있는지를 나타내는 파일을 얻어야한다.

이는 URL로부터 어떤 '파일'을 얻음으로써 HTTP를 통해 수행된다. 이 파일은 기본적으로 (비트 레이트 및 다른 특성들에 관한) 콘텐츠의 이용가능한 표현들과, 그 각각에 대해 각각의 타임 슬라이스에 콘텐츠 세그먼트들을 로딩하는(loading) 것을 가능하게 하는 URL들을 열거한다. 예를 들어, 주문형 비디오(Video on Demand) 콘텐츠에 대해서 영화의 전체 설명이 제공되지만, 반면 라이브 방송 콘텐츠에 대해서는 설명이 짧은 시간간격만을 차지하고 시간이 지나면 새로운 아이템들을 탐색하기 위해 주기적으로 재로딩될(reloaded) 필요가 있다.

일반적으로 네트워크 환경으로부터 얻은 능력 및 지식에 따라, 클라이언트 디바이스는 (일반적으로 그것의 비트 레이트에 기초한) 어떤 표현을 선택하고 콘텐츠의 첫 세그먼트(들)를 로드한다. 이것은 네트워크 장애에 대처할 수 있도록 몇 개의 세그먼트들을 버퍼에 저장한다. 그 다음에 각각의 수신된 세그먼트들로부터 콘텐츠가 교대로 재생된다. 동시에, 클라이언트 디바이스는 수신 레이트를 측정하고 더 높거나 더 낮은 비트 레이트로 진행하도록 결정할 수 있다. 이와 같은 경우에, 이것은 또 다른 표현으로부터 다음 세그먼트(들)을 바로 요청한다. 모든 HTTP 스트리밍 시스템은 어떤 비트 레이트에서의 세그먼트로부터 다른 비트 레이트의 '다음' 세그먼트로 진행하는 동안 클라이언트가 연속적인 재생을 유지할 수 있도록 한다.

이 방법은 네트워크상의 트래픽이 콘텐츠가 수신되는 레이트의 변화를 도입할 때, 클라이언트는 클라이언트 버퍼 필링(client buffer filling)을 안전한 수준으로 유지할 수 있는 비트 레이트로 세그먼트들을 선택함으로써 대응할 수 있다. 실제로 클라이언트는 일반적으로 더 나은 뷰잉(viewing) 품질을 제공하기 위해 가장 높은 가능한 비트 레이트에 도달하려고 시도하고, 렌더링(rendering)이 매크로-블록(macro-block) 또는 화면 정지(picture freezes)를 야기하는 늦은 데이터 수신으로 어려움을 겪지 않는 수준을 유지하도록 시도한다.

레지덴셜 네트워크(residential network)에서 복수의 클라이언트 디바이스는 HTTP 스트리밍을 동시에 수행할 수 있다. 로컬 네트워크 또는 광대역 네트워크에서 이용가능한 대역폭이 전체 트래픽을 지원하기에 충분하지 않다면, 클라이언트 디바이스들은 이용가능한 대역폭에서의 그들의 할당(share)을 확보하기 위해 경쟁한다. HTTP 스트리밍 알고리즘들은 각각의 디바이스에 독립적으로 동작하고 대역폭에서의 최적의 할당을 제공하지 못한다. 다음과 같은 상황이 발생할 수 있다. 비디오 스트림들 중 하나는 일정한 높은 비트 레이트를 사용하는 반면, 다른 하나는 낮은 비트 레이트로 머무름에 따라, 대역폭 할당이 불공평할 수 있다. 또는, 각 디바이스가 교대로 높고 낮은 비트 레이트를 사용하는 경우 오실레이션(oscillation)이 발생할 수 있다. 때때로 디바이스들은 그들이 비우호적(unfriendly)이라고 판단하는 네트워크 조건들에 동시에 과잉반응할 수 있고, 그 결과 큰 대역폭 손실과 각 디바이스들에서 매우 낮은 비트 레이트를 선택하게 된다. 이는 충분한 대역폭이 이용가능한 때에도 발생할 수 있다; 즉, HTTP 프로토콜에 기저가 되는 TCP 메커니즘들은 각각의 스트림에 대한 패킷 수신의 내포된 경쟁의 어려움을 겪을 수 있으며, 이는 안정된 불공평한 상황 또는 영구적 오실레이션과 동일한 결과를 생성한다. 디스플레이된 비디오 품질이 사용된 비트 레이트와 관련되어 있기 때문에, 이러한 성향(behaviour)은 최종 사용자의 경험의 품질에 직접적인 영향을 미친다.

본 발명은 각각의 적응형 스트리밍 콘텐츠에 의해 사용되는 대역폭의 제어를 제공함으로써, 종래기술의 적응형 스트리밍 불안정과 관련된 적어도 몇몇의 걱정을 개선하고자 한다.

본 발명은 적응형 스트리밍 서버를 포함하는 제1 네트워크에 대한 제1 인터페이스, 적어도 하나의 적응형 클라이언트 디바이스를 포함하는 제2 네트워크에 대한 제2 인터페이스, 상기 적어도 하나의 적응형 스트리밍 클라이언트 디바이스에 의해 요청되고 하나보다 많은 데이터 레이트(more than one data rate)로 이용가능한 적어도 하나의 스트리밍 콘텐츠를 감지하기 위한 스트림 식별자, 상기 하나보다 많은 데이터 레이트 중에서 데이터 레이트를 선택하기 위한 대역폭 관리자, 상기 스트리밍 콘텐츠에 대해 이용가능한 상기 선택된 데이터 레이트보다 크고 어떤 높은 데이터 레이트보다 작은 데이터 레이트로 상기 제2 인터페이스에서 상기 적어도 하나의 클라이언트 디바이스로 상기 적어도 하나의 스트리밍 콘텐츠를 전송하기 위한 스케줄러를 포함하는 디바이스에 관한 것이다.

일 실시예에 따르면, 제1 인터페이스는 최대 수신 대역폭(maximum bandwidth reception)을 갖고, 그리고 데이터 레이트는 적어도 하나의 스트리밍 콘텐츠가 요청된 대역폭이 최대 수신 대역폭 미만이도록 선택된다.

일 실시예에 따르면, 대역폭 관리자는 적어도 하나의 클라이언트 디바이스에 적어도 하나의 스트리밍 콘텐츠를 전송하는 우선순위를 결정하도록 구성된다.

일 실시예에 따르면, 디바이스는 레지덴셜 게이트웨이(residential gateway)이다.

발명의 다른 목적은 적응형 스트리밍 서버를 포함하는 제1 네트워크에 대한 제1 인터페이스와, 적어도 하나의 적응형 스트리밍 클라이언트 디바이스를 포함하는 제2 네트워크에 대한 제2 인터페이스를 포함하는 디바이스에서의 방법이다. 상기 방법은, 상기 적어도 하나의 적응형 스트리밍 클라이언트 디바이스에 의해 요청되고 하나보다 많은 데이터 레이트로 이용가능한 적어도 하나의 스트리밍 콘텐츠를 감지하는 단계, 상기 하나보다 많은 데이터 레이트 중에서 데이터 레이트를 선택하는 단계, 상기 스트리밍 콘텐츠에 대해 이용가능한 상기 선택된 데이터 레이트보다 크고 어떤 높은 데이터 레이트보다 작은 데이터 레이트로 상기 제2 인터페이스에서 상기 적어도 하나의 클라이언트 디바이스로 상기 적어도 하나의 스트리밍 콘텐츠를 전송하는 단계를 포함하는 방법이다.

발명의 또 다른 목적은 프로그램이 컴퓨터에서 실행될 때, 발명에 따른 상기 방법의 단계를 실행하기 위한 프로그램 코드 명령어들을 포함하는 컴퓨터 프로그램 제품이다. "컴퓨터 프로그램 제품"으로서, 컴퓨터 메모리와 같은 상기 프로그램을 포함하는 저장 공간뿐만 아니라 전기적 또는 광학적 신호와 같은 신호로 구성될 수 있는 컴퓨터 프로그램 지원을 의미한다.

본 발명은 적응형 스트리밍 서버와 적응형 스트리밍 클라이언트 디바이스들 사이에 위치한 디바이스의 수준에서 트래픽 쉐이핑(traffic shaping)을 수행한다. 대역폭 관리는 동시에 가능한 서비스들의 수와 각각의 서비스의 실효 QoE 사이의 최적의 트레이드오프(tradeoff)를 가능하게 한다. 본 발명의 트래픽 쉐이핑의 효과는 각각의 HTTP 적응형 스트리밍 클라이언트들의 성향에 유익하다. 이것은 여러 스트림들 사이의 경쟁을 억제 또는 제한한다. 트래픽 쉐이핑이 없다면, 대역폭의 할당은 TCP 프로토콜의 특성들과 클라이언트 알고리즘들이 그들이 '측정'한 대역폭에 어떻게 반응하는지에 따라 결정된다; 실제로, 이는 불안정 및/또는 불공평한 상황들을 야기한다. 트래픽 쉐이핑이 있다면, 각각의 스트림은 변화들의 그것의 가능한 범위로 제한된다. 만약 예를 들어 또 다른 스트림이 일시적으로 낮은 트래픽이기 때문에 한 스트림이 높은 비트 레이트로 갈 수 있다면, 높은 비트 레이트가 요구되는(requested) 세그먼트는 도착하는데 더 많은 시간이 걸리기 때문에, 이후의 대역폭 저하의 어려움을 겪을 것이다. 그러면 이를 보상하기 위해서, 적응형 클라이언트는 보상하기 위한 매우 낮은 비트 레이트로 동작해야 한다. 그래서 비트 레이트의 변화들은 큰 진폭을 가지고, 나쁜 품질의 경험(poor quality of experience)을 야기한다. 평균 목표에 근접한 값으로 실효 대역폭을 제한함으로써, 클라이언트는 너무 높게 가지 않을 것이고 목표 값 근처로 더욱 안정될 것이다.

본 발명은 또한 서로 다른 비디오 포맷들에 서로 다른 비트 레이트들을 사용하는 예와 같이, 제어된 비율로 대역폭을 할당하는 것을 가능하게 한다. 우리의 게이트웨이에 의해 제공되는 중앙 중재(central arbitration)가 없다면, 클라이언트는 유사한 비트 레이트들로 대역폭을 공유할 것이다.

트래픽의 분류는 시청각(audiovisual)의 스트림들과 다른 종류의 데이터 흐름들(data flows)의 사이에서 우선순위 규칙들을 포함할 수 있다. 이는 예를 들어 OTT 비디오 뷰잉이 데이터 파일들의 다운로드들에 의해 방해받는 것으로부터 보호할 수 있게 한다.

홈 게이트웨이는 대역폭 관리를 하기에 좋은 위치인데, 그 이유는 홈 게이트웨이는 네트워크 및 디바이스 제한들 대한 적절한 정보를 얻는 능력이 있기 때문이고, 그것은 모든 트래픽을 보고, 따라서 AV 서비스들에 속하는 스트림을 식별할 수 있어야 하고 그들에게 조치를 취할 수 있어야 하기 때문이다.

개시된 실시예들의 관점에서 상응하는 일정한 특징들은 이하에 기재되어 있다. 이는 이러한 특징들은 단지 본 발명이 취할 수 있는 특정한 형태의 간략한 요약을 독자에게 제공하기 위해 제시된다는 것, 그리고 이러한 특징들은 발명의 범위를 제한하도록 의도되지 않았다는 것이 이해되어야 한다. 실제로, 발명은 아래에 기재되어 있지 않을 수 있는 다양한 특징들을 포함할 수 있다.

본 발명은 결코 한정적이 아닌, 첨부된 도면을 참조하여, 이하의 실시예 몇 실행 예들에 의해 더욱 잘 이해 및 도시된다.
도 1은 실시예에 따른 시스템의 블록도.
도 2는 실시예에 따른 클라이언트 디바이스의 블록도.
도 3은 실시예에 따른 게이트웨이 디바이스의 블록도.
도 4는 실시예에 따른 게이트웨이 디바이스의 또 다른 블록도.
도 1에서, 표시된 블록들은 순수하게 기능적인 엔티티들(entities)이고, 이는 물리적으로 분리된 엔티티들에 해당할 필요는 없다. 즉, 블록들은 하드웨어 또는 소프트웨어의 형태로 개발될 수 있고, 또는 하나 또는 여러 개의 집적 회로들(integrated circuits)로 구현될 수 있다.

명확성의 목적으로, 전형적인 디지털 멀티미디어 콘텐츠 전달의 방법들 및 시스템들에서 찾을 수 있는 다른 많은 요소들을 제외하고, 본 발명의 명확한 이해에 관계된 요소들을 설명하기 위해 본 발명의 도면들 및 설명들을 단순화하였음이 이해될 것이다. 그러나, 그러한 요소들이 해당 기술분야에서 잘 알려져 있기 때문에, 이와 같은 요소들의 상세한 논의는 본 명세서에서 제공되지 않는다. 본 명세서에서의 개시 내용은 통상의 기술자에게 알려져 있는 그런 모든 변화들과 변경들과 연관된다.

도 1에 실시예에 따른 시스템이 도시된다. 이 시스템은 클라이언트 디바이스(4), 클라이언트 디바이스(5), 및 인터넷(2)을 통해 접속된 스트리밍 서버(3)를 포함한다. 클라이언트 디바이스들은 게이트웨이(1)를 통해 인터넷에 접속된 로컬 네트워크(6)에 위치한다. 바람직하게는, 로컬 네트워크는 레지덴셜 네트워크(residential network)이다. 클라이언트 요청(request)에 따라, 서버는 TCP/IP 접속을 통한 HTTP 프로토콜을 이용하여, 청크들을 클라이언트에게 스트리밍한다.

도 2에 실시예에 따른 클라이언트 디바이스(4)가 도시된다. 이하 적응형 스트리밍 클라이언트 디바이스라고도 불리는, 클라이언트 디바이스는, 로컬 네트워크(6)에 대한 제1 인터페이스(44)를 포함한다. 클라이언트는 서버(3)와 통신하는 프로토콜 스택들(stacks)을 포함하는, 통신 모듈(43)을 포함한다. 특히 통신 수단은 당해 기술분야에서 잘 알려진 TCP/IP 스택을 포함한다. 물론 이것은 클라이언트가 서버와 통신할 수 있도록 하는 어떤 다른 타입의 네트워크 및/또는 통신 수단이 될 수 있다. 이는 적응형 스트리밍 모듈(45)를 포함한다. 이는 서버로부터 HTTP 스트리밍 콘텐츠를 수신하는 HTTP 스트리밍 클라이언트이다. 이는 네트워크 제한들 및 그것의 고유의 제한들에 더 정합되는 비트 레이트로 계속적으로 청크를 선택한다.

클라이언트는 콘텐츠를 디코딩(decode) 및 렌더링(render)하도록 구성된 비디오 플레이어(46)로 포함한다. 클라이언트는 또한 클라이언트에 저장되어 있는 애플리케이션들 및 프로그램들을 실행하는 프로세서(41)를 포함한다. 그것은 비디오 플레이어(46)로 전송되기 전에 서버로부터 수신한 청크들을 버퍼링하기 위한, 메모리와 같은, 저장수단(42)을 포함한다. 특히 메모리는 휘발성 메모리(volatile memory)이다. 물론 클라이언트는 클라이언트에서 실행되는 애플리케이션들 및 프로그램들 저장을 위한, 도시되지 않은, 비 휘발성 메모리(non-volatile memory)를 포함한다. 클라이언트 디바이스는 휴대형 미디어 디바이스 또는 랩톱일 수 있다.

이와 달리 클라이언트 디바이스는 비디오 플레이어를 포함하지 않고, 비디오 플레이어에 접속하기 위한 인터페이스를 포함한다. 그리고, 클라이언트 디바이스는 셋톱박스(set-top box)와 같은 비디오 디코더(video decoder)이다.

실시예에 따른 게이트웨이가 도 3에 도시된다. 디지털 가입자 회선(Digital Subscriber Line: DSL) 게이트웨이는 DSL 기술을 통해 레지덴셜 네트워크에 광대역 인터넷 액세스를 공급한다. 물론 게이트웨이는 케이블, 광섬유 또는 무선 등의 어떤 타입의 광대역 게이트웨이일 수 있다. 그것은 LAN 인터페이스(14), 광대역 인터페이스(13) 및 인터페이스들을 통해 통신하는 프로토콜 스택들을 포함하는 통신 모듈(17)을 포함한다. 통신 모듈은 인터넷 프로토콜 스택을 포함하고, 이는 IP 스택으로 표기된다.

게이트웨이는 제1 메모리(16.1) 및 제2 메모리(16.2)를 포함한다. 제1 메모리(16.1)는 재생목록 파일들로부터 추출된 정보를 저장하도록 구성되어 있다. 제2 메모리(16.2)는 인터페이스들로부터 수신되는 그리고 인터페이스들로 송신하는 패킷들을 버퍼링하도록 구성되어있다.

게이트웨이는 또한 이하에서 더 상세히 설명될 대역폭 관리자(11), 스트림 식별자 모듈(15), 스케줄러(12), 분류자(18)를 포함하는 트래픽 쉐이핑 모듈(19)을 포함한다.

게이트웨이는 다양한 모듈들에 접속되는 내부 버스(10) 포함한다. 그것은 또한 프로세싱 수단, 도시되지 않은 라우팅(routing) 및 브리징(bridging) 수단, 및 포괄적인 레지덴셜 게이트웨이 기능들을 수행하는 통상의 기술자에게 잘 알려진 모든 수단을 포함한다.

게이트웨이는 도 4에 더욱 도시된다. 스트림 식별자 모듈(15)은 게이트웨이에서 수신한 스트림을 분석하도록 구성되어 있다. 클라이언트 디바이스가 서비스 요청을 발행할 때마다, 이것은 이 요청을 식별하고 서버에서 클라이언트로 되돌아오는 재생목록을 인터셉팅함으로써(intercepting) 서비스 정보를 수집한다. 그것은 각각의 로컬 디바이스로 향하는 재생목록 파일을 인터셉트하고 분석한다. 재생목록 파일을 분석함으로써 서버에 의해 선언된(announced) 비트 레이트와 이와 연관된 세그먼트들의 URL들과 같은 정보를 추출할 수 있게 된다. 재생목록을 인터셉트하기 위해 스트림 식별자는 이용가능한 스트리밍 기술 및 관련 프로토콜을 인식한다. 각각의 프로토콜에 대해, 이는 재생목록을 운반하는 패킷의 타입을 알고 있다. 특히, 그것은 애플 HTTP 라이브 스트리밍, 마이크로소프트 스무드 스트리밍 및 어도비의 오픈 소스 미디어 프레임워크 기술에 대해 인식한다. 물론 그것은 다른 스트리밍 기술을 인식할 수 있도록 될 수 있다.

스트림 식별자는 또한 게이트웨이에서 스트림이 더 이상 수신되지 않을 때를 식별한다. 예를 들어, 일정한 시간 동안 스트림을 수신되지 않으면, 스트림 식별자는 세션이 종료되었다고 간주하고 클라이언트 디바이스로의 분배를 취소한다.

스트림 식별자(15)로부터 얻어지는 정보는 대역폭 관리자(11)에게 전송된다.

대역폭 관리자는 서비스가 승인되는지를 결정하고, 그 서비스에 목표 비트 레이트를 할당하고, 동시에 이미 실행되고 있을 다른 서비스에 대한 목표들을 변경한다. 대역폭 관리자는 광대역 인터페이스상의 이용가능한 최대 대역폭 값을 알도록 구성된다. 이 값에 따라, 대역폭 관리자는 스트림들 중에서 대역폭 분배를 결정한다. 이는 검출되는 각 스트림에 대해 특정 큐(queue)가 제2 메모리에서 생성되고, 그리고 목표 전송 비트 레이트가 각각의 큐에 설정되도록 제2 메모리를 구성한다. 즉, 재생목록은 각각의 스트림에 대한 HTTP 스트리밍에 의해 이용가능한 비트 레이트를 제공한다. 이는 대역폭 관리자가 각각의 스트림에 대해 정확한 목표 비트 레이트를 결정할 수 있게 한다. 각각의 스트림에 대한 목표 비트 레이트를 결정한 후, 대역폭 관리자는 스케줄러(12)를 설정한다.

스케줄러(12)는 로컬 네트워크에서 패킷의 전송을 관리하도록 구성되어 있다. 즉, 각각의 스트림은 하나의 정확한 대역폭에 정확히 할당되는 독립적인 큐에 지정된다. 패킷은 이 목표 비트 레이트보다 빠르지 않게 전송된다. 동시에 대역폭은 '보장'된다; 큐가 전송할 패킷들을 가지고 그리고 목표 비트 레이트에 도달하지 않는 한, 패킷들이 다른 트래픽에 대해 우선순위를 가진다.

스트리밍 세션들 중에서 대역폭 할당에 대한 대역폭 관리자의 결정들은 많은 파라미터들과 사용자 또는 서비스 공급자의 선호들에 의존한다. 그들은 대역폭 관리자에 의해 강제되고 콘텐츠, 네트워크, 클라이언트 디바이스들 등의 특성에 의해 공급되는 (예를 들어, 모든 세션들이 그들의 포맷들에 비례하여 대역폭을 얻는 공평한 할당과 같은) 중재 방안들의 세트를 가져온다. 대역폭 관리자는 이용가능한 그 가능한 비트 레이트 단계들을 알 수 있는 능력과 함께 HTTP 적응형 스트림들의 고유한 탄성(intrinsic elasticity)에 먼저 의존한다.

대역폭 분배는 다음과 같이 수행된다. 이는 클라이언트 디바이스 타입에 기초한다. 예를 들어, 텔레비전 세트를 위한 스트림은 휴대용 미디어 플레이어를 위한 스트림보다 높은 우선순위를 가진다. 이와 달리, 레지덴셜 네트워크에서는 대역폭 분배가 클라이언트 디바이스의 위치에 기초할 수 있다. 거실에 위치한 클라이언트 디바이스는 침실에 위치한 클라이언트 디바이스보다 더 높은 우선순위를 가질 수 있다. 이 분배는 텔레비전 세트, 셋톱 박스와 같은 고정된 디바이스들(fixed devices)에 선호된다. 대역폭 분배는 레지덴셜 네트워크에서 또한 디바이스 타입 및 그 위치의 조합에 기초할 수도 있다. 이와 달리 디바이스들 중에서의 분배는 공평하게 설정되었다.

바람직하게는, 게이트웨이는 스트림들 사이에서 우선순위의 조절을 가능하게 하는 사용자 인터페이스를 포함한다. 사용자 인터페이스 내의 입력은 예를 들어 디바이스 타입, 그 위치 그리고 그 우선순위일 수 있다.

클라이언트들에게 할당할 대역폭을 계산하는 예시적인 실시예로서, 이하에서 가능한 알고리즘을 제공한다:

BW를 전체 이용가능한 대역폭이라고 가정한다.

각각의 클라이언트 c에 대해:

● share[c]를 클라이언트 c에 대해 부여하길 원하는 대역폭의 백분율이라고 한다. 이상에서 설명한 바와 같이 share[c]는 관리 정책들, 사용자 선호도들 등에 따라 결정된다.

● target[c]는 클라이언트 c가 선택하기를 원하는 콘텐츠 비트 레이트를 나타낸다.

● target[c]는 c를 위한 스트리밍 콘텐츠의 가장 높은 값으로 초기화되고, 그 다음 아래에 계산될 것이다.

● percent[c]는 얼마나 많은 대역폭을 클라이언트가 사용하는지에 대한 임시 계산된 값을 표시한다고 하자.

다음과 같은 알고리즘에 따라 target[] 테이블의 최종 계산이 수행된다.

SUM(target[]) > BW 인 동안에

● 이미 가장 낮은 비율의 클라이언트들은 무시하면서, 가장 큰 비율( percent[c] / share[c] )의 클라이언트 c를 선택한다.

● target[c] := next lower bitrate for c

● percent[c] := target[c] / BW

이제 "unused"(사용되지 않은) 대역폭을 클라이언트들에게 할당한다:

unused := BW - SUM(target[])

각각의 클라이언트 c에 대해:

● target[c] := target[c] + (unused * share[c])

그래서, 각각의 클라이언트는 우리가 사용되기를 원하는 콘텐츠 비트 레이트보다 더 큰 값으로 쉐이핑된(shaped) 트래픽을 가지게 될 것이다. 이는 HTTP 적응형 클라이언트들이 일반적으로 그들이 가지고 있는 대역폭의 100%를 사용하는 것에 성공하지 않았기 때문에, 이는 클라이언트가 원하는 콘텐츠 비트 레이트를 요청하는 것을 성공적으로 유지하기 위한 조건이다.

분류자(18)는 게이트웨이에서 수신한 스트림을 식별하고, 제2 메모리 내의 적합한 큐에 스트림을 보내도록 구성된다. 디바이스들 중 하나에 대해 수신된 모든 패킷은 오디오-비디오 스트림들 또는 몇몇의 다른 트래픽 중 하나에 속하는 것으로 분류자 모듈에 의해 확인되고 분류된다. 이 분류를 기초로, LAN으로 전송하기 위해 패킷이 서로 다른 큐에 위치된다. 각각의 큐의 패킷들은 선택된 쉐이핑 프로파일(profile)에 따라 스케줄러에 의해 전달된다. 그들은 목표 비트 레이트로 부합하도록 포워딩된다.

각각의 클라이언트에 대해 목표 비트 레이트가 선택되자마자, 클라이언트 디바이스에 의해 인식된 네트워크 대역폭이 원하는 비트 레이트를 채택하도록 게이트웨이는 트래픽 쉐이핑을 적용한다. 이는 디바이스가 더 높은 비트 레이트 요청들을 시도할 수 있다고 믿게 하는 전체 대역폭의 가능한 사용 때문에 수신에 있어 스피드 버스트(speed burst)를 보는 것을 예방한다. 동시에, 각 클라이언트는 그들의 대역폭 할당의 사용을 위한 우선순위를 보장받는다. 이는 클라이언트가 비트 레이트 감소를 보는 것과 그것을 보상하는 것을 회피하게 한다.

몇몇의 예는 트래픽 쉐이핑이 실시예의 디바이스로 수행되는 방법을 설명한다.

제1 예에서, 스트림은 클라이언트 디바이스에 대해 1mbps, 2mbps 및 3mbps가 이용가능하다. 이용가능한 대역폭은 평균적으로 2.5mbps이다. 그 다음에 게이트웨이는 2mbps를 선택한다. 그 후에, 클라이언트 디바이스는 스트림 콘텐츠를 최대 2mbps로 수신하고 3mbps로 콘텐츠를 요청하도록 수행되지 않을 것이다. 이는 클라이언트 디바이스를 2mbps보다 많이 사용하는 것을 방지한다.

제2 예에서, 제1 스트림은 제1 클라이언트 디바이스에 대해 1mbps, 2mbps 및 3mbps로 이용가능하고, 그리고 제2 스트림은 제2 클라이언트 디바이스에 대해 2mbps, 3mbps 및 5mbps로 이용가능하다. 이용가능한 대역폭은 5.5mbps이다. 우선순위는 제1 클라이언트 디바이스에 있다. 제1 클라이언트 디바이스는 최대 3mbps로 스트림 콘텐츠를 수신하고, 그리고 제2 클라이언트 디바이스는 최대 2mbps로 스트림 콘텐츠를 수신한다. 이는 제2 클라이언트 디바이스가 2mbps보다 많이 사용하는 것을 방지한다. 그 후 제1 클라이언트는 더 이상 제1 스트림을 수신하지 않는다. 더 많은 대역폭이 이용가능함에 따라, 제2 클라이언트 디바이스는 최대 5mbps로 스트리밍 콘텐츠를 수신한다.

또 다른 예는 SD 스트림과 HD 스트림이 요청될 때이다. SD 스트림과 HD 스트림은 그들의 각각의 최대 비트 레이트의 비례하여 대역폭이 할당되고, 예를 들어 SD 스트림에 20% 그리고 HD 스트림에 80%로 할당된다.

바람직하게는, 클라이언트가 목표 된 스트림의 변화에 대해 그 선택을 안정화할 수 있는 것을 보장하기 위해 큐에 대한 목표 비트 레이트는 스트림의 목표 비트 레이트보다 몇 퍼센트 높게 놓인다.

실시예에서, 대역폭 관리자는 광대역 인터페이스상의 이용가능한 최대 대역폭의 값을 기초로, 스트림들에 대역폭 분배를 결정한다. 이와 달리, 광대역 인터페이스상의 이용가능한 최대 대역폭 대신에, 대역폭 관리자는 로컬 네트워크상의 이용가능한 최대 대역폭을 고려할 수 있다. 로컬 네트워크상의 이용가능한 최대 대역폭의 값을 기초로, 스트림들에 대역폭 분배를 결정할 수 있다. 이것은 광대역 네트워크 대신 로컬 네트워크에 병목(bottleneck)이 생길 경우 발생한다.

실시예에서, 트래픽 쉐이핑은 게이트웨이에서 수행된다. 이와 달리 로컬 네트워크에 위치하는 라우터 속에서 수행될 수 있고, 게이트웨이로 접속될 수 있다.

상세한 설명, 청구항 및 도면에 의해 개시된 참조들은 독립적으로 또는 어떤 적절한 조합에 의해 제공될 수 있다. 적절한 경우, 특징들은, 하드웨어, 소프트웨어, 또는 이 둘의 조합으로 구현될 수 있다.

본 명세서에서의 "일(one) 실시예" 또는 "일(an) 실시예"에 대한 참조는 실시예와 관련하여 설명된 특정한 특징, 구조, 또는 특성이 본 발명의 적어도 하나의 구현에 포함될 수 있음을 의미한다. 명세서의 여러 곳에서 "일 실시예"라는 문구의 등장은 반드시 모두 동일한 실시예가 아니고, 또한 다른 실시예들의 상호 배타적인 별개의 또는 대안적인 실시예가 아니다.

청구범위에 나타나는 참조 부호들은 단지 예이며 청구항의 권리범위에 아무런 제한 효과를 가지지 않는다.

Claims

디바이스로서,
적응형 스트리밍 서버를 포함하는 제1 네트워크에 대한 제1 인터페이스,
적어도 하나의 적응형 스트리밍 클라이언트 디바이스를 포함하는 제2 네트워크에 대한 제2 인터페이스,
상기 적응형 스트리밍 서버로 상기 적어도 하나의 적응형 스트리밍 클라이언트 디바이스에 의해 요청되는 적어도 하나의 스트리밍 콘텐츠를 검출하기 위한 스트림 식별자 - 상기 적어도 하나의 스트리밍 콘텐츠는 상기 적응형 스트리밍 서버에서 하나보다 많은 데이터 레이트(more than one data rate)로 이용가능함 -,
상기 하나보다 많은 데이터 레이트 중에서 데이터 레이트를 선택하기 위한 대역폭 관리자, 및
상기 선택된 데이터 레이트보다 큰 제1 데이터 레이트로 상기 적응형 스트리밍 서버로부터 상기 적어도 하나의 스트리밍 콘텐츠를 수신하면, 상기 선택된 데이터 레이트보다 크지만 상기 스트리밍 콘텐츠에 대해 이용가능한 임의의 더 높은 데이터 레이트보다 작은 제2 데이터 레이트로, 상기 제2 인터페이스에서, 상기 적어도 하나의 클라이언트 디바이스로 상기 적어도 하나의 스트리밍 콘텐츠를 전송하기 위한 스케줄러
를 포함하는 디바이스.
제1항에 있어서,
상기 제1 인터페이스는 최대 수신 대역폭(maximum bandwidth reception)을 가지고, 상기 대역폭 관리자는 상기 적어도 하나의 스트리밍 콘텐츠에 요구되는 대역폭이 상기 최대 수신 대역폭보다 작도록 상기 선택된 데이터 레이트를 선택하도록 구성된, 디바이스.
제1항에 있어서,
상기 제2 인터페이스는 최대 대역폭을 가지고, 상기 대역폭 관리자는 상기 적어도 하나의 스트리밍 콘텐츠에 요구되는 대역폭이 상기 최대 대역폭보다 작도록 상기 선택된 데이터 레이트를 선택하도록 구성된, 디바이스.
제1항에 있어서,
상기 대역폭 관리자는 상기 제2 네트워크를 통해 전송되는 다른 스트리밍 콘텐츠에 따라 상기 데이터 레이트를 선택하도록 구성된, 디바이스.
제1항에 있어서,
상기 스트림 식별자는, 상기 적응형 스트리밍 서버로부터 스트림이 더 이상 수신되지 않을 때를 검출하도록 구성된, 디바이스.
제1항에 있어서,
상기 대역폭 관리자는 상기 적어도 하나의 클라이언트 디바이스로의 상기 적어도 하나의 스트리밍 콘텐츠의 전송에 우선순위를 부여(prioritize)하도록 구성된, 디바이스.
제6항에 있어서,
상기 우선순위는 상기 클라이언트 디바이스의 타입에 기초를 둔, 디바이스.
제7항에 있어서,
상기 우선순위는 상기 제2 네트워크에서의 상기 클라이언트 디바이스의 위치에 기초를 둔, 디바이스.
제1항에 있어서,
상기 디바이스는 레지덴셜 게이트웨이(residential gateway)인, 디바이스.
적응형 스트리밍 서버를 포함하는 제1 네트워크에 대한 제1 인터페이스와, 적어도 하나의 적응형 스트리밍 클라이언트 디바이스를 포함하는 제2 네트워크에 대한 제2 인터페이스를 포함하는 디바이스에 의해 수행되는 방법으로서,
상기 적응형 스트리밍 서버로 상기 적어도 하나의 적응형 스트리밍 클라이언트 디바이스에 의해 요청되는 적어도 하나의 스트리밍 콘텐츠를 검출하는 단계 - 상기 적어도 하나의 스트리밍 콘텐츠는 상기 적응형 스트리밍 서버에서 하나보다 많은 데이터 레이트로 이용가능함 -,
상기 하나보다 많은 데이터 레이트 중에서 데이터 레이트를 선택하는 단계, 및
상기 선택된 데이터 레이트보다 큰 제1 데이터 레이트로 상기 적응형 스트리밍 서버로부터 상기 적어도 하나의 스트리밍 콘텐츠를 수신하면, 상기 선택된 데이터 레이트보다 크지만 상기 스트리밍 콘텐츠에 대해 이용가능한 임의의 더 높은 데이터 레이트보다 작은 제2 데이터 레이트로, 상기 제2 인터페이스에서, 상기 적어도 하나의 클라이언트 디바이스로 상기 적어도 하나의 스트리밍 콘텐츠를 전송하는 단계
를 포함하는 방법.
제10항에 있어서,
상기 제1 인터페이스는 최대 수신 대역폭(maximum bandwidth reception)을 가지고, 상기 적어도 하나의 스트리밍 콘텐츠에 요구되는 대역폭이 상기 최대 수신 대역폭보다 작도록 상기 데이터 레이트가 선택되는, 방법.
제10항에 있어서,
상기 제2 인터페이스는 최대 대역폭을 가지고, 상기 적어도 하나의 스트리밍 콘텐츠에 요구되는 대역폭이 상기 최대 대역폭보다 작도록 상기 데이터 레이트가 선택되는, 방법.
제10항에 있어서,
상기 적응형 스트리밍 서버로부터 스트림이 더 이상 수신되지 않을 때를 검출하는 단계를 더 포함하는, 방법.
제10항에 있어서,
상기 적어도 하나의 클라이언트 디바이스로의 상기 적어도 하나의 스트리밍 콘텐츠의 전송에 우선순위를 부여(prioritize)하는 단계를 더 포함하는, 방법.
프로그램 코드 명령어들을 포함하는 컴퓨터-판독가능한 저장 매체로서, 상기 프로그램 코드 명령어들은 컴퓨터에서 실행될 때, 청구항 10에 따른 방법의 상기 단계들을 실행하는, 컴퓨터-판독가능한 저장 매체.