KR20140103338A

KR20140103338A - 네트워크-시작 콘텐츠 스트리밍 컨트롤

Info

Publication number: KR20140103338A
Application number: KR1020147019733A
Authority: KR
Inventors: 브란덴부르크 레이 반; 오마르 아지즈 니아무트; 멧치스 오스카 반 데벤터
Original assignee: 코닌클리즈케 케이피엔 엔.브이.; 네덜란제 오르가니자티에 포오르 토에게파스트-나투우르베텐샤펠리즈크 온데르조에크 테엔오
Priority date: 2011-12-29
Filing date: 2012-12-27
Publication date: 2014-08-26
Also published as: KR101691709B1; EP3068102A1; CN104137505B; ES2586818T3; EP2798816A1; JP6310513B2; JP5977838B2; WO2013098317A1; CN104137505A; JP2015510161A; HK1200995A1; US20140379871A1; EP2798816B1; PL2798816T3; US10516717B2; US20170353522A1; HUE036024T2; US9723047B2; EP3068102B1; JP2016219032A

Abstract

콘텐츠 전달 노드로부터 적어도 하나의 클라이언트에게 세그먼트 콘텐츠 스트리밍의 네트워크-시작 제어를 가능하게 하는 방법 및 시스템을 설명하였으며, 상기 클라이언트는 매니페스트 파일을 토대로 상기 세그먼트 콘텐츠의 적어도 일부에 액세스하도록 구성하되, 여기서 방법은 다음 단계를 포함할 수 있다: 하나 또는 그 이상의 세그먼트 및 상기 적어도 하나의 클라이언트에게 상기 하나 또는 그 이상의 세그먼트를 전송하도록 구성된 하나 또는 그이상의 콘텐츠 전달 노드 위치를 찾기 위한 위치 정보를 식별하는 제 1 매니페스트 파일을 수신하는 단계; 상기 제 1 매니페스트 파일의 상기 수신에 응하여, 채널 셋-업 정보를 제공하는 단계; 및, 상기 채널 셋-업 정보를 토대로 상기 적어도 하나의 클라이언트와 상기 콘텐츠 전달 노드와 연관된 제어 채널 서버 기능 사이에 적어도 하나의 스트리밍 제어 채널을 설정하는 단계를 포함하며, 상기 적어도 하나의 클라이언트는 상기 스트리밍 제어 채널을 통해 적어도 하나의 매니페스트 업데이트 메시지를 수신하도록 구성된다.

Description

네트워크-시작 콘텐츠 스트리밍 컨트롤{Network-initiated content streaming control}

본 발명은 콘텐츠 스트리밍 제어, 그에 한정되지는 않지만, 특히, 세그먼트 콘텐츠 스트리밍의 네트워크-시작 제어를 가능하게 하는 방법, 세그먼트 콘텐츠의 수신을 제어하기 위한 콘텐츠 프로세싱 장치에 사용하기 위한 클라이언트, 세그먼트 콘텐츠 스트리밍의 네트워크-시작 제어를 가능하게 하는 제어 채널 서버 기능과 데이터 구조 및 그러한 방법을 사용하는 컴퓨터 프로그램 제품에 관한 것이다.

현재 점점 더 많은 비디오 스트리밍 기술들이 소위 콘텐츠 세그먼테이션을 이용하며, 여기서 콘텐츠 데이터, 예를 들어, 비디오 데이터는 논리적으로 또는 가상적으로 다수의 세그먼트 파일 또는 스트림으로 분할되고, 그리하여 세그먼트 콘텐츠를 발생한다. 세그먼트 파일은 파일 검색 프로토콜(retrieval protocol),예를 들면, HTTP 또는 FTP에 의하여 검색될 수 있는 콘텐츠 데이터를 포함하는 스트림과 관련될 수 있다. 유사하게, 세그먼트 스트림은 스트리밍 프로토콜, 즉 RTSP/RTP 또는 HAS에 의하여 검색될 수 있는 콘텐츠 데이터를 포함하는 스트림과 관련될 수 있다. 세그먼트 파일들 또는 스트림은(이후 간단히 세그먼트로 언급한다) 따로따로 클라이언트에게 전달될 수 있으나, 그러나 클라이언트에서 재결합되면 그들은 원활한 비디오 스트림을 제공한다.

콘텐츠 세그멘테이션 프로세스 동안에 소위 매니페스트 파일은 세그먼트들을 식별하고 다른 세그먼트들 사이의 관계 및 세그먼트들이 검색될 수 있는 위치를 설명한다.

세그먼트 콘텐츠는 몇 가지 표현(representations), 예를 들어, 동일한 콘텐츠에 대해 해상도, 오디오 채널의 수 및/또는 다른 비트 전송속도(bitrate)에서 차이가 있는, 선택적 버전으로 제공될 수 있다. 모든 표현들은 시간적으로(temporally) 조정(align)되고 그래서 다른 표현의 세그먼트들이 원활하게 상호교환될 수 있다. 다른 표현으로 세그먼트 콘텐츠를 스트리밍 하는 것은 적응성 스트리밍(adaptive streming)으로 언급되며, 여기서 HTTP 적응성 스트리밍(HAS)과 같은 적응성 스트리밍 프로토콜 및 연관된 프로토콜이 사용될 수 있다.

클라이언트가 웹 서버로부터 독립적으로 요청하는 세그먼트들로 비디오를 전송함으로써, HAS는 HTTP 프로토콜에 의하여 (라이브) 비디오의 전달을 가능하게 한다. 다양한 상용 및 표준화된 HAS 프로토콜, 예를 들어, 애플 HTTP 라이브(Live) 스트리밍(http://tools.ietf.org/html/draft-pantos-http-live-streaming-07), 마이크로소프트 스무드 스트리밍(http://www.iis.net/download/SmoothStreaming), 아도베(Adobe) HTTP 다이나믹 스트리밍(http://www.adobe.com/products/httpdynamicstreaming), 3GPP-DASH TS 26.247 투명한 종단간 패킷-교환 스트리밍 서비스(PSS); HTTP 수단을 통해서 점진적(Progressive) 다운로드와 동적 적응 스트리밍] 및 HTTP MPEG DASH ISO/IEC 23001-6을 통한 엠팩(MPEG) 동적 적응성 스트림들이 존재한다.

세그먼트 콘텐츠는 높은 품질에서 낮은 품질의 비디오 스트림으로 전환함으로서 변환 대역폭 요구에 다이내믹하게 적응하기 위해 사용될 수 있다. 또한, 세그먼트 콘텐츠는 인기 있는 (비디오) 세그먼트와 인기가 낮은 (비디오) 세그먼트 사이의 차별을 허용할 수 있다. 예를 들어, 일반적으로 비디오의 시작 부분과 연관된 콘텐츠는(예고편 같은) 종료에서의 콘텐츠보다 더 자주 시청할 것이다. 유사하게 일부 사용 사례로, 낮은 비트레이트 낮은 품질의 비디오 콘텐츠(예를 들어, 최저 해상도 HAS 세그먼트)는 수신 장치로부터 더 많은 비용 또는 요구가 있을 수 있고 또는 더 많은 대역폭을 요구할 수 있는 높은 품질의 콘텐츠(예를 들어, 높은 해상도 HAS 세그먼트)보다 더 자주 다운로드될 것 같다. 세그먼트 콘텐츠의 상기 언급된 특성은 소비자(consumer)에게 콘텐츠를 전달하도록 구성된 콘텐츠 전달 네트워크(CDN)에 의하여 편리하게 사용될 수 있다. CDN은 인기 있고 더 자주 요구되는 콘텐츠 세그먼트를 CDN의 다중 전달 노드에서 저장할 수 있고, 그래서 대역폭(bandwidth) 문제는 감소되고 효율적인 전달이 보장된다. CDN 제어 기능(CDNCF)은, 이 후 전달 노드로 언급될, CND 내에서 위치를 집중적으로 관리하며, 여기서 콘텐츠 아이템(예를 들어, 비디오 또는 영화)과 연관되어 있는 콘텐츠 세그먼트는 검색(retrieved, get)될 수 있다.

RTP/RTSP 또는 RTMP 와 같은 많은 다른 스트리밍 프로토콜이 클라이언트에게 (세그먼트) 콘텐츠의 스트리밍을 구현하기 위하여 사용될 수 있지만, HTTP 또는 HTTP-기반의 스트리밍 프로토콜이 CDN 내에 가장 넓게 사용된다. 이러한 스트리밍 프로토콜은 서버로부터 새로운 기능성을 요청하지 않고 세그먼트들이 투과성 있게 캐시(cache)될 수 있도록 허용하는 표준 HTTP 지배권이 없는, 고객 서버 프로토콜- 를 사용한다. 게다가, 다른 스트리밍 솔루션과는 달리, HTTP 트래픽은 일반적으로 방화벽이나 네트워크 주소 변환기(NATs)에 의해 자동으로 차단되지 않는다.

또한, HTTP-기반의 스트리밍은 세션-기반(session-based)이 아니다. 이것은 HTTP 서버가 서비스하는 다양한 클라이언트에 대하여 세션을 유지할 필요가 없음을 의미한다. 이런 방식으로 HTTP 서버 구조는 단순하게 유지될 수 있다. 그러나, HTTP가 클라이언트-시작 프로토콜이라는 사실과 결합된 이러한 세션-없는 특성(nature)의 HTTP 서버는, 예를 들어, CDN의 전달 노드는 클라이언트와 통신을 시작할 수 없음을 의미한다.

클라이언트가 CDN 내에 저장된 세그먼트에 액세스(즉, 다운로드/검색)하는 것을 가능하도록 하기 위하여, 클라이언트에게 각각 세그먼트 식별자(예를 들면, 세그먼트 파일 명) 및 세그먼트 위치(예를 들면, 세그먼트 위치자), 예를 들어, 세그먼트를 액세스(검색)할 수 있는 네트워크 노드를 가리키는 URLs 에 의해 식별되는 세그먼트의 리스트를 포함하고 있는 소위 매니페스트 파일을 제공한다. 특정 CDN 및/또는 구현에 따라, 미리 정의된 매니페스트 파일은, 연관된 세그먼트와 함께, CDN의 하나 또는 그 이상의 (전달) 노드에 저장될 수 있거나, 또는 매니페스트 파일은 사용자 요청에 따라 CDN에 의해 다이나믹하게 생성될 수 있다.

이러한 방식으로, 소비자(클라이언트 장치)가 특정 세그먼트 콘텐츠 아이템(비디오 같은)을 요청할 때, CDN은, 요청 즉시, 요청받은 콘텐츠 아이템을 소비자(장치)에게 전달 가능하도록 하기에 적절한 (전달)노드에 저장된 매니페스트 파일을 식별할 수 있다.

선택적으로, CDN은, 함께 채택하면, 요청받은 콘텐츠 세그먼트들을 고객에게 전달하기에 적절한 하나 또는 그 이상의 전달 노드들을 식별하는 새로운 매니페스트 파일을 생성할 수 있다. 결과적으로, CDN 은 소비자의 요청하는 클라이언트(장치)에게 응하여 생성된 매니페스트 파일을 전송할 수 있다.

콘텐츠 세그먼트의 스트리밍 동안에, CDN에서의 네트워크 구성 또는 로드(load) 분배는 변할 수 있다. 예를 들어, CDN의 하나의 노드에서의 실패 또는 오버로드(overload)는 CDN의 하나 또는 그 이상의 전달 노드들이 매니페스트 파일에 식별된 콘텐츠 세그먼트를 더 이상 전달할 수 없는 상황을 초래할 수 있다. 또한 다른 상황, 즉 임박한 오버로드 상황에서는, 스트리밍 프로세서 동안 특정 콘텐츠 세그먼트를 특정 소비자(콘텐츠 수신 장치)에게로 전달하는 태스크(task)를 한 전달 노드로부터 다른 전달노드로 또는 심지어 다른 CDN의 전달 노드로 이전함으로써 오버로드 상황을 예방할 필요가 있다. 특정 소비자의 클라이언트 장치가 포지션(position)을 변경하면, 오리지널 노드로부터 스트리밍을 인계받는, 이제는 더 가까운 전달 노드인, 다른 전달 노드를 가지는 것이 더 유리할 수 있다고 심지어 상상할 수 있다.

전달 네트워크에서클라이언트에게 세그먼트를 전달함에 있어서 변화를 요구하거나 보증할 수 있는 네트워크에서의 다른 이벤트(즉, 네트워크에서 로드 밸런싱 메커니즘을 촉발하는)는 계획된 사용불능(outages), 서버 마이그레이션, CDN 마이그레이션, 등등이다.

알려진 방법에서, 클라이언트에게 세그먼트를 전달함에 있어서 그러한 변화는 다수의 방법에 의하여 구현될 수 있다. 일부 경우에, CDN은, 예를 들어, 희망하는 전달 노드에 대한 세그먼트 요청을 리디렉션하기 위하여 HTTP 리디렉트 방식(scheme)을 사용할 수 있다. 그러나 그러한 방식은 클라이언트가 미래에 요구하게 될 모든 세그먼트에 대하여 개별 리디랙션 응답 메시지(간단히 리디랙션으로 언급함) 또는 심지어 요청된 세그먼트 당 다중 리디렉트 응답 메시지를 요구 및 촉발할 수 있고, 그 때문에 네트워크에 시그널링 로드의 실질적인 증가를 야기한다. 이것은 많은 양의 소비자가 동일한 전달 노드에 의존하며 동시에 동일한 콘텐츠를 요청하고 검색할 경우에 특별히 관계된다. 추가적인 시그널링 로드는 CDN의 부분 또는 전체에 넘칠 뿐만 아니라, 리디랙트는 개별 세그먼트의 전달이 리디렉션의 결과로서 갑자기 지연되기 때문에, 클라이언트 측에 용인할 수 없는 서비스 중단이 발생할 수 있다. 그러한 이유로, 리디렉터 방식은 네트워크의 구성(예를 들어, 전달 노드 실패의 결과로서)의 변화로 인해 서비스 중단(interruptions)을 효과적으로 방지할 수 없다. 서비스 중단은, 예를 들어, 콘텐츠가 클라이언트 장치에서 거의 버퍼링되지 않은 상황에서, 다중 리디렉션이 발생하거나, 또는 새로운 타켓 전달 노드가 이전의 노드에 비해 클라이언트 장치에서 상당히 먼 거리에 위치한 상황에서 더 확연할 수 있다.

선택적으로, CDN은 새로운 네트워크 구성을 바탕으로 클라이언트를 위해 새롭게 업데이트된 매니페스트 파일을 발생할 수 있다. 그러나 그것의 특성으로 인해, HTTP 프로토콜은 서버 측(예를 들어, CDN)이 클라이언트에게 그러한 새롭게 업데이트된 매니페스트 파일의 전송을 직접 및/또는 프로액티브하게(pro-actively) 시작을 허용하지 않거나 또는, 선택적으로, 그러한 새롭게 업데이트된 매니페스트 파일에 대한 클라이언트 요청을 시작하도록 허용하지 않는다.

클라이언트가 업데이트된 매니페스트 파일을 수신하느냐 또는 수신하지 않느냐는 그러한 업데이트를 요청하는 클라이언트(그러나 네트워크 구성에서(임박한)변경을 인식하지 못하는)의 이니셔티브에 완전히 달려있다. 마찬가지로, 예를 들어, 세그먼트 콘텐츠 스트림이 클라이언트에게 이전에 제공된 매니페스트 파일에 존재하는 것보다 보다 높은 표현으로 CDN에 의해 이용할 수 있게 될 경우에, 클라이언트는 이를 알 수 있는 방법이 없으며, 그러한 높은 품질의 스트림으로부터 이익을 얻을 수 없다. 클라이언트가 주기적으로 매니페스트 파일 업데이트를 요구하도록 구성된다 할지라도, 이러한 업데이트 방식은 네트워크 구성의 변화에 대해 효과적으로(빨리) 애드-혹(ad-hoc, 임기 응변식))으로 반응할 수 없으며, 그러한 변화로 인한 서비스 중지를 피할 수 없다. 이러한 업데이트 빈도가 갑자기 필요한 구성 변경과 정확하게 일치한다면, 그것은 단지 우연의 일치일 뿐이다. 또한, 매우 높은 업데이트 빈도를 구현함은, (HTTP 기반의 요청 - 응답 시그널링 메카니즘을 사용하는), 심지어 어떠한 구성 변화도 (예를 들어, 클라이언트에게 세그먼트 콘텐츠를 전달함에 있어서의 변화) 필요하지 않거나 추천할 만하지 않는 동안에도, 네트워크에 상당한 오버헤드(overhead) 시그널링 로드 및 클라이언트와 네트워크 측에 프로세서 로드를 야기하는 불리한 점을 가진다.

따라서, 클라이언트에 대한 콘텐츠 스트리밍의 개선된 제어를 가능하게 하는 방법 및 시스템을 위한 기술이 필요하다.

본 발명이 해결하려는 과제는 클라이언트에 수행되는 스트리밍 프로세스가 네트워크 구성에서의 변화 및/또는 명백한 오버로드 상황 또는 네트워크 실패와 같은 네트워크 문제에 신속히 반응할 수 있으며, 그리하여 네트워크는 클라이언트에게 선제적으로 신호할 수 있도록 제어 채널을 구현함으로써 종래 기술 형태의 세그먼트 스트리밍 솔루션이 기반이 되는 알려진 (HTTP)요청-응답 메커니즘의 한계점 및 단점들은 완화 및/또는 극복될 수 있도록 하는데 있다.

본 발명 과제의 해결 수단은 적어도 하나의 클라이언트에게 하나 또는 그 이상의 식별자 및 상기 하나 또는 그 이상의 식별자와 연관된 하나 또는 그 이상의 세그먼트를 전송하도록 구성된 하나 또는 그 이상의 콘텐츠 전달 노드 위치를 찾기 위한 위치정보를 포함하는 제 1 매니페스트 파일을 수신하는 단계; 클라이언트에게 채널 셋-업 정보를 제공하는 단계; 및 바람직하게는 클라이언트에서 상기 제 1 매니페스트 파일의 수신에 의하여, 상기 적어도 하나의 클라이언트와 상기 공급된 채널 셋-업 정보를 토대로 상기 전달 노드와 연관된 제어 채널 서버 기능 사이에 적어도 하나의 스트리밍 제어 채널을 설정하는 단계를 포함하며, 상기 적어도 하나의 클라이언트는 스트리밍 제어 채널을 통하여 적어도 하나의 매니페스트 파일 업데이트 메시지를 수신하도록 구성된 전달 노드로부터 적어도 하나의 클라이언트에게 세그먼트 콘텐츠 스트림의 네트워크-시작 제어를 가능하게 하는 방법을 제공하는데 있다.

본 발명의 또 다른 과제의 해결 수단은 하나 또는 그 이상의 세그먼트 식별자 및 상기 하나 또는 그 이상의 식별자와 연관된 하나 또는 그 이상의 정보를 상기 적어도 하나의 클라이언트에게 전송하도록 구성된 하나 또는 그 이상의 콘텐츠 전달 노드를 찾기 위한 위치 정보를 포함하는 매니페스트 파일을 적어도 하나의 클라이언트에게 전달하는 단계; 상기 하나 또는 그 이상의 콘텐츠 전달 노드와 연관된 제어 채널 서버 기능과 상기 적어도 하나의 클라이언트 사이에 제어 채널을 셋-업하기 위한 요청을 수신하는 단계; 및 상기 적어도 하나의 스트리밍 제어 채널을 설정하는 단계를 포함하되, 여기서 상기 제어 채널 서버 기능은 상기 클라이언트에게 적어도 하나의 매니페스트 파일 업데이트 메시지를 전송하도록 구성된 전달 노드로부터 적어도 하나의 클라이언트에게 세그먼트 콘텐츠 스트림의 네트워크- 시작 제어를 가능하게 하는 방법을 제공하는데 있다.

본 발명의 또 다른 과제의 해결 수단은 상기 하나 또는 그 이상의 클라이언트에게 세그먼트 콘텐츠를 전달하기 위한 적어도 하나의 요청을 수신하는 단계; 하나 또는 그 이상의 세그먼트 식별자와 상기 세그먼트 식별자에게 상기 세그먼트 식별자와 연관된 하나 또는 그 이상의 세그먼트를 전송하도록 구성된 하나 또는 그 이상의 콘텐츠 전달 노드 위치를 찾기 위한 위치 정보 및 채널 셋-업 정보를 포함하는 적어도 하나의 매니페스트 파일을 생성하는 단계; 상기 하나 또는 그 이상의 클라이언트 중 적어도 하나에 상기 제 1 매니페스트 파일을 전송하는 단계; 및 상기 적어도 하나의 클라이언트와 상기 제어 채널 서버 기능 사이에 적어도 제 1 스트리밍 제어 채널의 셋-업에 참여하는 단계를 위하여 구성되며, 상기 셋-업은 상기 채널 셋업 정보를 토대로 하며; 및, 선택적으로, 상기 제어 채널 서버 기능은 매니페스트 파일 업데이트 메시지 생성 및/또는 상기 클라이언트에게 상기 제 1 스트리밍 제어 채널을 통해 상기 메시지를 전송하도록 추가로 구성된 상기 전달 노드로부터 하나 또는 그 이상의 클라이언트에게 세그먼트 콘텐츠 스트리밍의 네트워크-시작 제어를 가능하게 하는 적어도 하나의 전달 노드와 연관된 제어 채널 서버 기능을 제공하는데 있다.

본 발명의 또 다른 과제의 해결 수단은 하나 또는 그 이상의 세그먼트 식별자 및 상기 클라이언트에게 상기 하나 또는 그 이상의 세그먼트 식별자와 연관된 하나 또는 그 이상의 세그먼트들을 전송하도록 구성된 하나 또는 그 이상의 콘텐츠 전달 노드 위치를 찾기 위한 위치 정보를 포함하고; 상기 데이터 구조는 상기 채널 셋업 정보의 적어도 일부를 더 포함하고, 바람직하게는 상기 채널 셋-업 정보는 상기 클라이언트와 함께 스트리밍 제어 채널 셋업 프로세서를 시작하도록 구성된 제어 채널 서버 기능을 포함하는 네트워크 노드와 연관된 위치 정보, 바람직하게는 하나 또는 그 이상의 URLs를 포함하는 매니페스트 파일의 적어도 일부이며, 세그먼트 콘텐츠 스트림의 네트워크-시작 제어를 가능하게 하는 데이터 구조를 제공하는데 있다.

본 발명은 클라이언트에 수행되는 스트리밍 프로세스가 네트워크 구성에서의 변화 및/또는 명백한 오버로드 상황 또는 네트워크 실패와 같은 네트워크 문제에 신속히 반응할 수 있으며, 그리하여 네트워크는 클라이언트에게 선제적으로 신호할 수 있도록 제어 채널을 구현함으로써 종래 기술 형태의 세그먼트 스트리밍 솔루션이 기반이 되는 알려진(HTTP)요청-응답 메커니즘의 한계점 및 단점들은 완화 및/또는 극복될 수 있는 유리한 효과가 있다.

본 발명은 발명에 따른 실시 예를 개략적으로 보여줄 첨부된 도면을 참고로 추가로 설명될 것이다.
도면의 간단한 설명
도 1은 클라이언트와 서버 사이의 종래 HAS 세션의 개요(overview)를 도시한 것이다.
도 2는 본 발명의 하나의 실시 예에 따른 클라이언트와 서버 사이의 프로토콜 흐름을 도시한 것이다.
도 3은 본 발명의 실시 예에 따른 클라이언트-측 프로세스 흐름을 도시한 것이다.
도 4는 본 발명의 실시 예에 따른 서버-측 프로세스 흐름을 도시한 것이다.
도 5A-5C는 본 발명의 다양한 실시 예에 따른 클라이언트와 서버 사이의 프로세스 흐름을 도시한 것이다.
도 6은 본 발명 실시 예에 따른 콘텐츠 스트리밍 시스템을 도시한 것이다.
도 7은 본 발명 실시 예에 따른 콘텐츠 스트리밍 시스템에서 사용을 위한 메시지 흐름을 도시한 것이다.
도 8은 본 발명 실시 예에 따른 전달 연속성 노드(DCN)와 연관된 프로세스 흐름을 도시한 것이다.
도 9는 본 발명의 다른 실시 예에 따른 콘텐츠 스트리밍 시스템에 사용할 메시지 흐름을 도시한 것이다.
도 10은 본 발명의 또 다른 실시 예에 따른 콘텐츠 스트리밍 시스템에 사용할 메시지 흐름을 도시한 것이다.
도 11은 본 발명의 추가적인 다른 실시 예에 따른 콘텐츠 스트리밍 시스템에 사용할 메시지 흐름을 도시한 것이다.
도 12는 본 발명의 실시 예에 따른 콘텐츠 스트리밍 시스템을 도시한 것이다.
도 13은 본 발명의 또 다른 추가적인 실시 예에 따른 콘텐츠 스트리밍 시스템에 사용할 메시지 흐름을 도시한 것이다.
도 14는 본 발명의 하나의 실시 예에 따른 매니페스트 파일을 도시한 것이다.

종래 기술에 알려진 결점 중 적어도 하나를 감소시키거나 또는 제거하는 것이 본 발명의 목적이다. 본 발명의 제 1 측면은 전달 노드(node)로부터 적어도 하나의 클라이언트에게, 바람직하게는, MPEG의 DASH 호환 적응된 스트리밍 클라이언트와 같은 HTTP 적응 스트리밍(HAS) 클라이언트에게 세그먼트 콘텐츠 스트리밍의 네트워크-시작 제어를 가능하게 하는 방법에 관한 것일 수 있다. 방법은 적어도 다음 단계 중 하나를 포함할 수 있다; 제 1 매니페스트 파일을 수신하는 단계, 바람직하게는 상기 매니페스트 파일은 하나 또는 그 이상의 세그먼트를 식별하기 위하여 하나 또는 그 이상의 세그먼트 식별자 및 상기 적어도 하나의 클라이언트에게 상기 세그먼트 식별자와 연관된 하나 또는 그 이상의 세그먼트들을 전송하도록 구성된 하나 또는 그 이상의 콘텐츠 전달 노드 위치를 알아내기 위한 위치 정보를 포함하며; 클라이언트에게 채널 셋업 정보를 제공하는 단계; 및/또는, 상기 적어도 하나의 클라이언트와 네트워크 사이에 바람직하게는, 상기 제공된 채널 셋업 정보를 토대로 상기 하나 또는 그 이상의 전달 노드들 중 적어도 하나와 연관된 제어 채널 서버 기능인, 적어도 하나의 스트리밍 제어 채널을 설정하는 단계. 하나의 실시 예에서, 상기 단계들은 클라이언트에 의하여 실행될 수 있다. 다른 실시 예에서, 상기 적어도 하나의 클라이언트는 상기 스트리밍 제어 채널을 통해서 적어도 하나의 매니페스트 파일 업데이트 메시지를 수신하도록 구성될 수 있다. 선택적으로 제어 채널은 매니페스트 파일 업데이트의 가용성을 나타내는 업데이트 메시지 외의, 세그먼트 콘텐츠의 스트리밍과 관련된 서버 또는 네트워크 측 이벤트의 메시지를 통신하도록 네트워크(즉 제어 채널 서버 기능)에 의해 사용될 수 있다. 이러한 이벤트는 매니페스트 파일 업데이트를 통해 통신할 수 없는 정보(예를 들어, 파라메터)와 관련될 수 있으며, 또는 그런 이벤트에는 매니페스트 파일 업데이트에서 분리된 클라이언트에게 이를 통신하는 것이 더 적합(예를 들면 더 빠를)할 수 있다. 그러한 실시 예에서 클라이언트는 이러한 다른 이벤트 메시지를 수신 및/또는 처리하도록 선택적으로 구성될 수 있다. 다른 실시 예에서, 상기 적어도 하나의 클라이언트는 매니페스트 파일을 토대로 상기 세그먼트 콘텐츠의 적어도 일부에 액세스하도록 구성할 수 있다.

다른 실시 예에서, 클라이언트에 의한 매니페스트 파일의 수신은, 바람직하게는, 제공된 채널 셋-업 정보를 바탕으로 네트워크로 스트리밍 제어 채널을 셋-업하기 위해 클라이언트를 트리거(trigger)할 수 있으며, 여기서 스트리밍 제어 채널은 네트워크, 예를 들어, CDN이 클라이언트에게 매니페스트 파일 업데이트의 가용성을 나타내는, 매니페스트 파일 업데이트 메시지를 프로-액티브하게(=사전대책을 강구해, pro-actively) 제공하는 것을 가능하게 한다. 매니페스트 파일 업데이트 메시지는 클라이언트가 먼저 네트워크에 (HTTP) 요청을 전송할 필요없이 제어 채널을 통해 클라이언트에게 프로-액티브하게 전송할 수 있다. 이 방법으로, 클라이언트에 수행되는 스트리밍 프로세스는 네트워크 구성에서의 변화 및/또는 명백한 오버로드 상황 또는 네트워크 실패와 같은 네트워크 문제에 신속히 반응할 수 있으며, 그리하여 네트워크는 클라이언트에게 선제적으로 신호할 수 있다. 제어 채널을 구현함으로써 종래 기술 형태의 세그먼트 스트리밍 솔루션이 기반이 되는 알려진 (HTTP)요청-응답 메커니즘의 한계점 및 단점들은, 그들 중 일부는 배경 섹션에서 충분히 논의를 마쳤으므로, 완화 및/또는 극복될 수 있다.

실시 예에서, 본 방법은 적어도 하나의 매니페스트 파일 업데이트 메시지에 대한 상기 스트리밍 제어 채널 모니터링을 포함할 수 있다. 이러한 실시 예에서, 클라이언트는 네트워크로부터의 업데이트 메시지를 위한 채널을 연속적으로 모니터링 할 수 있고, 그래서 이러한 업데이트 메시지에 대한 클라이언트에 의한 신속한 대응이 보장된다. 이 모니터링 프로세스는, 예를 들면 스트리밍 프로세스 동안 백그라운드 프로세스로서 실행될 수 있다.

하나의 실시 예에서, 방법은 다음 단계중 적어도 하나를 포함할 수 있다 : 매니페스트 파일 업데이트 메시지를 검출하는 단계; 및 선택적으로 상기 매니페스트 파일 업데이트 메시지에 응하여 제 2 매니페스트 파일의 적어도 일부를 검색하는 단계를 포함할 수 있다. 다른 실시 예에서, 방법은: 상기 제 2 매니페스트 파일에 기초하여 세그먼트 스트림 또는 파일을 요청하는 단계를 더 포함할 수 있다. 따라서, 네트워크로부터 클라이언트에 의해 수신된 매니페스트 파일 업데이트 메시지는 업데이트된 매니페스트 파일을 요청 및/또는 사용할 수 있고, 및 스트리밍 프로세스는 이러한 업데이트된 매니페스트 파일에 기초하여 계속되어야하거나 또는 계속될 수 있음을 클라이언트에게 신호할 수 있다. 여기서 매니페스트 파일의 업데이트는 네트워크 구성에서의 변화 및/또는 네트워크 실패 또는 네트워크 과부하와 같은 네트워크 문제 때문에 요구될 수 있다. 이러한 방식으로, 네트워크는 네트워크에서의 특정 이벤트에 응하여 스트리밍 프로세스의 제어를 효율적으로 프로-액티브하게 개시할 수 있다. 세그먼트 스트리밍 솔루션 기반의 종래의 기술 HTTP 에서는, 당연히 클라이언트로부터 제 1 이니셔티브를 요청하는 HTTP 요청 및 응답 메커니즘에 기초하므로, 이러한 스트리밍 프로세스의 프로액티브 네트워크-시작 제어는 간단하게 되지는 않는다.

하나의 실시 예에서, 상기 채널 셋-업 정보의 적어도 일부는 상기 제 1 매니페스트 파일로 상기 클라이언트에게 제공될 수 있으며, 선택적으로 클라이언트에게 별도(separate)의 메시지로 제공될 수 있다. 또 다른 실시 예에서, 상기 채널 셋-업 정보의 제공은 상기 채널 셋-업 정보를 가진 클라이언트를 미리-구성함을 포함한다. 하나의 실시 예에서, 상기 채널 셋-업 정보는 네트워크에서 제어 채널 서버 기능을 찾기 위한 서버 위치 정보, 바람직하게는 적어도 하나의 URL을 포함할 수 있다. 따라서, 매니페스트 파일은 제어 채널의 셋-업을 위해 요구되는 정보의 적어도 일부를 포함할 수 있다.

하나의 실시 예에서, 상기 매니페스트 파일 업데이트 메시지의 적어도 일부는 제 2 매니페스트 파일의 적어도 일부를 포함할 수 있다. 이러한 실시 예에서, 스트리밍 제어 채널은 매니페스트 파일에서 업데이트 부분을 전송하는데 사용할 수 있다. 다른 실시 예에서 상기 매니페스트 파일 업데이트 메시지는 매니페스트 파일 위치 정보인, 상기 제 2 매니페스트 파일의 적어도 일부를 요청하고 및 위치를 찾기 위한, 적어도 하나의 URL을 포함할 수 있다. 이러한 방법으로, 네트워크는 어디서 업데이트된 매니페스트 파일(또는 그 부분)을 검색할 수 있는지 간단하고 효율적인 방법으로 클라이언트에게 알려줄 수 있다.

하나의 실시 예에서, 상기 스트리밍 제어 채널은 WebSocket 프로토콜을 바탕으로 설정할 수 있다. 하나의 실시 예에서, 콘텐츠 전달 네트워크(CDN) 실체(entity), 바람직하게는 제어 채널 서버 기능, 및 클라이언트는 클라이언트와 상기 CDN 실체 사이에 스트리밍 제어 채널을 셋업하기 위하여 WebSocket 프로토콜 및 채널 셋업 정보를 사용하도록 구성된 HTTP WebSocket API를 포함할 수 있다. WebSocket 연결은 일반적으로 표준 HTTP 포트 80 및 443을 사용하며 그래서 데이터는 방화벽과 NATs를 쉽게 통과할 수 있으며, 뿐만 아니라 다른 포트도 사용할 수 있다. 또한, 프로토콜은 그것이 낮은 메시지 오버헤드(overhead)를 가지고 있으므로 확장 가능한(scalable) 솔루션을 제공한다. 또한, WebSocket은 HTTP를 토대로 하며, 그래서 방화벽의 통과와 관련한 문제는 제거될 수 있거나 또는 실질적으로 감소된다. 또한, 그것은 다른 프로토콜의 터널링(tunnelling)을 위한 가능성을 제공한다.

하나의 실시 예에서 상기 세그먼트 콘텐츠의 적어도 일부가 스트리밍 프로토콜 기반의, 바람직하게는 HTTP-기반 스트리밍 프로토콜 또는 이의 유도체(derivative)를 토대로 한 상기 적어도 하나의 클라이언트에게 전달된다. 다른 실시 예에서, 스트리밍 제어 채널은 SIP 프로토콜, XMPP 프로토콜 및/또는 이들의 조합을 사용하여 설정될 수 있다.

다른 측면에서, 본 발명은 전달 노드로부터 적어도 하나의 클라이언트에게 세그먼트 콘텐츠 스트리밍의 네트워크-시작 제어(network-initiated control)를 가능하게 하는 방법에 관한 것이며, 상기 방법은 다음 단계중의 적어도 하나를 포함한다: 하나 또는 그 이상의 세그먼트를 식별하기 위한 하나 또는 그 이상의 세그먼트 식별자 및 적어도 하나의 클라이언트에게 상기 세그먼트 식별자들과 연관된 하나 또는 그 이상의 세그먼트들을 전송하도록 구성된 하나 또는 그 이상의 콘텐츠 전달 노드의 위치를 찾기 위한 위치 정보를 포함하는 매니페스트 파일을 전달하는 단계; 하나 또는 그 이상의 콘텐츠 전달 노드와 연관된 제어 채널 서버와 상기 적어도 하나의 클라이언트 사이에 스트리밍 제어 채널을 셋업하기 위한 요청을 수신하는 단계; 및/또는 상기 적어도 하나의 스트리밍 제어 채널을 설정하는 단계. 하나의 실시 예에서 상기 제어 채널 서버 기능은 상기 클라이언트에게 적어도 하나의 매니페스트 파일 업데이트 메시지를 전송하도록 구성할 수 있다. 다른 실시 예에서, 상기 클라이언트는 매니페스트 파일을 바탕으로 상기 세그먼트 콘텐츠의 적어도 일부에 액세스 하도록 구성될 수 있다. 다른 실시 예에서, 매니페스트 파일은 하나 또는 그 이상의 식별자 및 상기 적어도 하나의 클라이언트에게 상기 하나 또는 그 이상의 세그먼트 식별자와 연관된 하나 또는 그 이상의 세그먼트를 전송하도록 구성된 하나 또는 그 이상의 콘텐츠 전달 노드의 위치를 찾기 위한 위치 정보를 포함할 수 있다.

하나의 실시 예에서, 상기 하나 또는 그 이상의 전달 노드들의 상기 적어도 제1 부분의 상기 적어도 일부는 상기 클라이언트에게 상기 세그먼트의 적어도 제 1 부분을 전달하도록 구성된 제 1 콘텐츠 전달 네트워크(CDN1)에 속하는 제 1 전달 노드로서 구성될 수 있으며; 및/또는 상기 전달 노드의 적어도 제 2 부분은 상기 클라이언트에게 상기 세그먼트의 적어도 제 2 부분을 전달하도록 구성된 제 2 콘텐츠 전달 네트워크(CDN2)에 속하는 제 2 전달 노드로서 구성될 수 있다. 따라서 이러한 실시 예에서, 세그먼트의 적어도 한 부분이 제 2 CDN , 더 나아가 그 이상의 CDN에 의하여 클라이언트에게 전달된다.

하나의 실시 예에서 상기 방법은: 하나 또는 그 이상의 네트워크 파라메터, 바람직하게는 오버로드, 임박한 오버로드, 실패와 연관된 상기 하나 또는 그 이상의 네트워크 파라메터 또는 상기 하나 또는 그 이상의 전달 노드들과 관련된 네트워크 구성 변화를 모니터링하는 단계; 상기 네트워크 파라메터와 연관된 하나 또는 그 이상의 미리 결정된 조건을 충족할 경우에 매니페스트 파일 업데이트 메시지를 발생하는 단계; 및, 선택적으로, 상기 적어도 하나의 클라이언트에게 상기 매니페스트 파일 업데이트 메시지를 전송하는 단계를 포함한다.

하나의 실시 예에서 상기 방법은 : 오버로드, 임박한 오버로드, 실패 또는 상기 하나 또는 그 이상의 제 1 및/또는 제 2 전달 노드들과 관련된 네트워크 구성에서의 변화를 결정하는 단계; 결정된 오버로드, 임박한 오버로드, 실패 또는 네트워크 구성 변화와 연관된 하나 또는 그 이상의 제 1 및/또는 제 2 전달 노드로부터 세그먼트를 검색하거나 또는 검색을 기대하는 하나 또는 그 이상의 클라이언트를 식별하는 단계; 상기 식별된 클라이언트의 적어도 일부와 연관된 하나 또는 그 이상의 스트리밍 제어 채널들을 결정하는 단계; 및, 선택적으로, 상기 하나 또는 그 이상의 스트리밍 제어 채널을 통해서 상기 식별된 클라이언트의 적어도 일부에게 매니페스트 파일 업데이트 메시지를 전송하는 단계를 포함한다.

하나의 실시 예에서, 상기 오버로드, 실패 또는 네트워크 구성 변화의 적어도 일부는 적어도 CDN2에 속하는 상기 제 2 전달 노드들 중 적어도 하나와 관련될 수 있다. 다른 실시 예에서 상기 방법은: 상기 제 1 CDN1에 오버로드 통지, 실패 통지 또는 네트워크 구성 변화 통지를 전송하는 상기 제 2 CDN2를 포함할 수 있으며, 상기 오버로드 또는 실패 통지는 상기 오버로드 또는 실패와 연관된 하나 또는 그 이상의 제 2 전달 노드 식별자를 포함한다.

하나의 실시 예에서 상기 방법은: 제 1 CDN 데이터베이스에서 클라이언트 전달 정보를 저장하는 단계를 포함할 수 있으며, 상기 클라이언트 전달 정보는 다음 중 적어도 하나를 포함한다: 스트리밍 제어 채널 식별자; 클라이언트 식별자, 바람직하게는 상기 클라이언트와 연관된 IP 어드레스; 상기 매니페스트 파일에서 참조되는 하나 또는 그 이상의 세그먼트들을 호스팅(hosting)하는 전달 노드와 연관된 전달 노드 식별자; 콘텐츠 전달 네트워크 식별자; 및/또는, 매니페스트 파일 식별자.

또 다른 측면에서, 본 발명은 하나 또는 그 이상의 클라이언트에게 적어도 제 1 및 제 2 콘텐츠 전달 네트워크(CDN1, CDN2)와 연관된 세그먼트 콘텐츠의 스트리밍의 네트워크-시작 제어를 가능하게 하는 방법에 관한 것이며, 상기 제 1 CDN1은 제 1 제어 채널 서버 기능과 연관되고 및 상기 제 2 CDN2는 제 2 제어 채널 서버 기능과 연관되며, 여기서 상기 방법은 다음 단계중 적어도 하나를 포함할 수 있다: 세그먼트 콘텐츠와 관련된, 하나 또는 그 이상의 세그먼트 및 제 1 CDN1 과 연관된 하나 이상 콘텐츠 전달 노드의 위치를 찾는 위치 정보를 포함하는 제 1 매니페스트 파일을 생성하는 단계; 및/또는, 상기 제 2 제어 채널 서버 기능에 세그먼트 콘텐츠와 연관된 제 2 매니페스트 파일을 요청하는 단계, 여기서 상기 제 2 매니페스트 파일은 하나 또는 그 이상의 세그먼트 및/또는 상기 제 2 CDN2와 연관된 하나 또는 그 이상의 콘텐츠 전달 노드들의 위치를 찾기 위한 위치 정보를 포함할 수 있다; 상기 제 1 및 제 2 매니페스트 파일을 바탕으로 추가적인 매니페스트 파일 및 선택적으로, 채널 셋-업 정보를 생성하는 단계; 상기 채널 셋-업 정보를 바탕으로 상기 적어도 하나의 클라이언트와 상기 제 1 제어 채널 서버 기능 사이에 적어도 제 1 스트리밍 제어 채널을 설정하는 단계, 여기서 제 1 제어 채널 서버 기능은 매니페스트 파일 업데이트 메시지를 생성하고 상기 스트리밍 제어 채널을 통해서 상기 클라이언트에게 상기 메시지를 전송하도록 구성될 수 있다.

추가적인 측면에서, 본 발명은 콘텐츠 프로세싱 장치에 사용할 클라이언트에 관한 것일 수 있으며, 상기 클라이언트는: 상기 서버에 세그먼트 콘텐츠를 전달하기 위한 요청을 전송하는 단계; 상기 적어도 하나의 클라이언트에게 하나 또는 그 이상의 세그먼트 식별자 및 상기 하나 또는 그 이상의 세그먼트 식별자와 연관된 하나 또는 그 이상의 세그먼트를 전송하도록 구성된 하나 또는 그 이상의 콘텐츠 전달 노드들의 위치를 찾기 위한 위치 정보를 포함하는 매니페스트 파일을 수신하는 단계; 제 1 채널 셋-업 정보를 제공하는 단계; 및/또는, 상기 적어도 하나의 클라이언트와 제공된 제 1 채널 셋-업 정보를 바탕으로 상기 제 1 CDN1과 연관된 상기 제어 채널 서버 기능 사이에 제 1 스트리밍 제어 채널을 설정하는 단계로 구성될 수 있다. 하나의 실시 예에서, 적어도 하나의 클라이언트는 상기 제 1 제어 채널 서버 기능으로부터 적어도 하나의 매니페스트 파일 업데이트 메시지를 수신하도록 구성되어 있다.

한 측면에서, 본 발명은 상기 전달 노드로부터 하나 또는 그 이상의 클라이언트에게 세그먼트 콘텐츠의 네트워크-시작 제어 전송을 가능하도록 하기 위한 전달 노드와 연관된 제어 채널 서버 기능에 관한 것일 수 있으며, 여기서 제어 채널 서버 기능은 다음 단계 중 적어도 하나로 구성될 수 있다: 하나 또는 그 이상의 클라이언트에게 세그먼트 콘텐츠를 전달하기 위하여 적어도 하나의 요청을 수신하는 단계; 상기 클라이언트에게 하나 또는 그 이상의 식별자 및 상기 하나 또는 그 이상의 세그먼트 식별자와 연관된 하나 또는 그 이상의 세그먼트를 전송하도록 구성된 하나 또는 그 이상의 콘텐츠 전달 노드들의 위치를 찾기 위한 위치 정보 및, 선택적으로, 채널 셋-업 정보를 포함하는 적어도 하나의 매니페스트 파일을 생성하는 단계; 및, 상기 클라이언트에게 적어도 하나의 매니페스트 파일을 전송하는 단계, 및 상기 채널 셋-업 정보를 바탕으로 상기 적어도 하나의 클라이언트와 상기 제어 채널 서버 기능 사이에 적어도 제 1 스트리밍 제어 채널의 셋-업에 참여하는 단계. 하나의 실시 예에서, 상기 제어 채널 서버 기능은 매니페스트 파일 업데이트 메시지를 발생하고, 상기 클라이언트에게 상기 제 1 스트리밍 제어 채널을 통해서 상기 메시지를 전송하도록 추가로 구성할 수 있다.

하나의 실시 예에서 적어도 하나의 매니페스트 파일을 생성하는 것은 다음 단계를 포함할 수 있다: 하나 또는 그 이상의 제 1 세그먼트 식별자 및 제 1 콘텐츠 전달 네트워크(CDN1)에서 하나 또는 그 이상의 콘텐츠 전달 노드를 찾기 위한 제 1 위치 정보를 제공하는 단계; 제 2 콘텐츠 네트워크에 하나 또는 그 이상의 제 2 세그먼트 식별자 및 상기 제 2 콘텐츠 전달 네트워크(CDN2)에서 하나 또는 그 이상의 콘텐츠 전달 노드를 찾기 위한 제 2 위치 정보를 요청하는 단계; 하나 또는 그 이상의 제 1 및 제 2 세그먼트 식별자 및 제 1 및 제 2 위치 정보 각각의 적어도 일부를 바탕으로 상기 매니페스트 파일을 생성하는 단계.

다른 하나의 실시 예에서 상기 제어 채널 서버 기능은; 제 2 콘텐츠 전달 네트워크로부터 오버로드 통지를 수신하고; 및, 상기 오버로드 통지에 응하여 상기 클라이언트에 상기 제 1 스트리밍 제어 채널을 통해서 매니페스트 파일 업데이트 메시지를 보내도록 추가로 구성할 수 있다.

추가적인 측면에서, 본 발명은 데이터 구조, 바람직하게는 앞서 설명한 바와 같이 클라이언트에 사용할 매니페스트 파일에 관한 것일 수 있으며, 여기서 상기 데이터 구조는 하나 또는 그 이상의 세그먼트 식별자 및 상기 클라이언트에게 상기 하나 또는 그 이상의 세그먼트와 연관된 하나 또는 그 이상의 세그먼트를 전송하도록 구성된 하나 또는 그 이상의 콘텐츠 전달 노드를 찾기 위한 위치 정보를 포함 할 수 있으며; 상기 데이터 구조는 추가로 상기 채널 셋-업 정보의 적어도 일부를 포함할 수 있다. 하나의 실시 예에서, 상기 채널 셋-업 정보는 상기 클라이언트에게 스트리밍 제어 채널을 셋-업하도록 구성된 제어 채널 서버 기능을 포함하는 네트워크 노드와 연관된 위치 정보, 바람직하게는 하나 또는 그 이상의 URLs를 포함할 수 있다.

본 발명은 또한 컴퓨터 메모리에서 수행될 때, 위에 기술된 방법 단계 중 어느 하나에 따라 방법 단계를 실행하도록 구성된 소프트웨어 코드를 포함하는 컴퓨터 프로그램 상품에 관한 것이다.

본 발명은 발명에 따른 실시 예를 개략적으로 보여줄 첨부된 도면을 참고로 추가로 설명될 것이다.

도 1은 터미널에서의 클라이언트(130)와 응답 및 요청 프로토콜 메시지(134,136)를 포함하는 HAS 스트리밍 프로토콜과 같은 스트리밍 프로토콜을 통해서 통신하도록 구성된 미디어 서버(132)사이의 재래식 HAS 프로토콜 흐름의 개요(overview)를 도시한 것이다. 여기서, 터미널은 일반적으로 콘텐츠 프로세싱 장치, 예를 들어, 전자 테블릿, 스마트-폰, 노트북, 미디어 플레이어, 등과 같은 콘텐츠 재생(play-out) 장치에 관한 것일 수 있다. 일부 실시 예에서, 터미널은 콘텐츠 재생(play-out) 장치로 미래에 소비할 콘텐츠를 프로세싱하고 일시적으로 저장하도록 구성된 셋-탑 박스 또는 콘텐츠 저장 장치일 수 있다. 유사하게, 미디어 서버는 콘텐츠 제공자 또는 콘텐츠 전달 네트워크(CDN)의 일부이거나 또는 그에 연관될 수 있다.

프로토콜 흐름은 사용자가 웹사이트(단계102) 상에 비디오에 대한 링크(연결)를 선택하는 것으로 시작할 수 있으며, 여기서 URL은 매니페스트 파일을 가리킬(예를 들어, 리디랙션을 통해서) 수 있다. 매니페스트 파일은 세그먼트 식별자, 예를 들어, 세그멘트 파일 이름을 포함하고, 세그먼트 비디오 파일을 구축하고 및 클라이언트(전달 노드)에게 세그먼트를 전달하도록 구성된 하나 또는 그 이상의 네트워크 노드를 찾기 위한 위치 정보, 예를 들어, URLs와 연관된 특별한 데이터 구조에 관한 것일 수 있으며 ; 또는, 선택적으로, 식별된 세그먼트를 전달할 수 있는 하나 또는 그 이상의 네트워크 노드를 결정할 수 있는 네트워크 노드에 관한 것일 수 있다. 그러나 다른 실시 예에서, 위치 정보는 또한 네트워크 노드 상의 위치를 가리킬 수 있다. 예를 들어, 세그먼트와 연관된 URLs는 하나의 전달 노드에서 정의된 다른 폴더들을 가리킬 수 있다.

바람직하게는 매니페스트 파일에 포함된, 세그먼트에 대한 레프런스(reference)는 세그먼트 식별자 및/또는 세그먼트를 찾기 위한 세그먼트 식별자와 연괸된 위치 정보를 포함할 수 있다.

매니페스트 파일은 세그먼트들 사이의 시간적인 및/또는 공간적인 관계를 설명하는 정보를 더 포함할 수 있다. 이러한 파일은 특수한 파일명 확장자, 예를 들어, mf, .mf, .xml 및 .m3u8을 사용하여 저장하고 식별할 수 있다. 그리고나서 클라이언트는 서버로부터 매니페스트 파일을 획득하기 위하여 HTTP GET 요청을 보낼 수 있다(단계(104)). 응답으로, 서버는 클라이언트에게 매니페스트 파일을 보냄으로써 응답할 수 있다 (단계(106). 그 후 클라이언트는 요청받은 비디오와 연관된 세그먼트의 위치를 획득하기 위하여 매니페스트 파일을 분석한다(단계(108)).

클라이언트는 매니페스트 파일에 기술된 위치로부터 비디오의 제 1 세그먼트를 요청하고, 서버는 클라이언트에게 요청받은 세그먼트를 보냄으로써 요청에 응답한다(단계(110, 112)). 매니페스트 파일을 토대로, 다수의 세그멘트들은 검색된다(단계(114,116)).

그리고 나서, 일정 시간 후에, 클라이언트는(예를 들어, 미리-설정된 타이머가 다 돌아가거나 또는 클라이언트가 라이브 스트리밍으로 거의 매니페스트 파일의 끝에 도달하는 것을 토대로) 매니페스트 파일을 업데이트할 때라고 결정하고, 최초의 매니페스트를 획득했던 동일한 위치에 요청을 보낼 수 있다(단계(118)). 업데이트된 매니페스트 파일은 그 후 클라이언트에게 보내지고(단계(120)), 다시 업데이트된 매니페스트 파일의 분석을 시작함으로써 클라이언트에 의해 처리될 수 있다(단계(122)).

앞서 검토한 바와 같이, 이러한 재래의 HAS 콘텐츠 스트리밍 시스템은 클라이언트와 서버사이의 스트리밍 프로세서의 서버-기반의 제어를 허용하지 않는다. 그것은 예측하기 어려운 애드-혹(ad-hoc) 상황에서의 제어를 허용하지 않으며, 여기서 스트리밍 구성의 직접적인 조정(adaptation)이 요구된다.

도 2는 본 발명의 하나의 실시 예에 따른 고객과 서버 사이의 프로토콜 흐름을 도시한다. 특히. 도 2는 미디어 서버(232)로부터 클라이언트(230)에게 콘텐츠를 스트리밍하기 위한 HTTP 적응 스트리밍(HAS) 프로토콜 같은 스트리밍 프로토콜과 연관된 프로토콜 흐름을 도시한다.

클라이언트는 비디오 재생(play-out, 246) 기능으로 재생하기 위해 스트림을 처리하는 스트리밍 클라이언트 기능(248) 및 제어 채널 클라이언트 기능(244)(CCCF)을 포함할 수 있다.

유사하게, 미디어 서버는 미디어를 스트리밍 클라이언트 기능(248)에 스트리밍하기 위한 스트리밍 서버 기능(242)을 포함한다.

미디어 서버는 또한 제어 채널 서버 기능(CCSF), 예를 들어, CCSF와 CCCF(244) 사이에 스트리밍 제어 채널(236)의 설정을 시작하도록 구성된 서버(232) 내에 또는 서버(232)와 연관된 HAS 제어 채널 서버 기능(234)을 포함하며, 여기서 스트리밍 제어 채널은 클라이언트와 서버 사이에 스트리밍 제어 정보를 교환하는데 사용할 수 있으며 , 세그먼트 콘텐츠(238)를 클라이언트에게 스트리밍하는 동안, 특히 서버로부터 발생한 스트리밍 제어 정보를 클라이언트에게 스트리밍하는데 사용할 수 있다.

여기서, 프로세서는 도 1에서와 같은 방식으로, 즉 웹사이트 상에 비디오에 대한 링크를 사용자 클릭킹하는 것으로 시작할 수 있고, 여기서 URL은 매니페스트 파일을 가리킬(예를 들어, 리디렉션을 통해)수 있다(단계200)). 클라이언트는 서브로부터 매니페스트 파일을 획득하기 위하여 HTTP GET 요청을 보낼 수 있고, 서브는 또 매니페스트 파일(이 경우에는 XML 파일)을 클라이언트에게 보냄으로써 응답할 수 있으며(단계202, 204)), 클라이언트는 결과적으로 요청된 콘텐츠 스트림을 구성하는 세그먼트의 위치를 획득하기 위하여 매니페스트 파일을 분석한다(단계206)). 이러한 특별한 경우에, 그러나, 서버에서 CCSF는 매니페스트 파일에 채널 셋-업 정보를 삽입하도록 구성되어, 클라이언트에서는 CCCF가 및 서버에서는 CCSF가 스트리밍 제어 체널을 셋-업하도록 허용한다.

매니페스트 파일에 삽입된 채널 셋업 정보를 토대로, 클라이언트에서 CCCF는 서버-투-클라이언트 스트리밍 제어 채널을 셋업하기 위해 예를 들어 서버의 CCSF에게 채널 셋업 요청을 보낼 수 있다(단계(208)). 하나의 실시 예에서. CCCF 및 CCSF는 WebSocket 프로토콜 및 클라이언트와 서버 사이에 스트리밍 제어 채널을 설정하기 위한 채널 셋-업 정보를 사용하도록 구성된 HTTP WebSocket API를 포함할 수 있다. WebSocket 연결(connections)은 일반적으로 표준 HTTP 포트(80) 및 (443)을 사용하며 그래서 데이터는 쉽게 방화벽 및 NATs를 트랜스퍼(transfer)할 수 있지만, 또한 다른 포트도 사용될 수 있다.

CDN 및 HAS의 환경(context) 내에서 WebSocket 프로토콜의 사용은 확장성(scalability)에 대한 낮은 메시지 오버헤드(overhead), 프로토콜 컨버전스 및 방화벽 괸통에 대한 HTTP의 사용 및 다른 프로토콜의 터널링에 대한 가능성 같은 다수의 이점을 갖는다. 다른 실시 예에서는, 세션 이니시에이션 프로토콜(SIP)(http://tools.ietf.org/html/rfc3261)이 사용되는데, 클라이언트는 SIP 유저 에이전트를 포함할 수 있고 서버는 SIP 애플리케이션 서버이다.

또 다른 실시 예에서, 익스텐시블 메시징 및 프레전스 프로토콜(XMPP) (http://www.ietf.org/rfc/ rfc3920.txt)이 사용되는데, 클라이언트는 XMPP 클라이언트를 포함할 수 있고 서버는 XMPP 서버를 포함한다. SIP 및 XMPP 프로토콜 메시지 둘 다 draft-ibc-rtcweb-sip-websocket-00 및 draft-moffitt-xmpp-over-websocket-00에 따라 WebSocket을 통해 터널링될 수 있다. 다른 프로토콜을 위한 실시 예에 대한 더 자세한 설명은 도 5A 내지 5C에 제공된다.

스트리밍 제어 채널의 셋-업 동안, 채널 파라메터는 CCCF 및 CCSF 사이에 교환될 수 있다(단계(210)). 또한, 클라이언트에서 비롯된 메시지를 다루기 위해, CCSF는 전용 채널 핸들링 프로세스(thread)를 만들 수 있다(단계(212)). 일단 스트리밍 제어 채널이 설정되면(214), 클라이언트는 매니페스트 파일에서 식별된 세그먼트 스트리밍 프로세스를 시작할 수 있다. 스트리밍 프로세스는 HAS-타입 스크리밍 프로토콜에 기반을 두고, 제 1 세그먼트 segment_low-1.avi 와 연관된 URL을 포함하고 있는 HTTP GET 요청으로 시작한다(단계216)). 일단 제 1 세그먼트의 전달이 HTTP 200 OK 응답에 의해 확인되면(단계(218)), 클라이언트는 다음의 세그먼트 segment_high-2.avi를 요청한다 (단계( 220,222)).

그리고나서, 미디어 서버에서 CCSF는 클라이언트가 자신의 매니페스트 파일을 업데이트할 필요가 있음을 결정할 수 있다. 예를 들어, CCSF는 일어날 수 있는 서버 오버로드 또는 실패를 검출할 수 있다. 그러므로 그것은 스트리밍 제어 채널을 통하여 선택적으로 새로운 매니페스트 파일을 가리키는 URL을 포함하는 매니페스트 업데이트 신호를 보낼 수 있다(단계(224)). 매니페스트 파일 업데이터 신호를 수신하자마자, CCCF는 새로운 매니페스트 파일을 요청할 수 있다. 새로운 매니페스트 파일을 수신하는 즉시. 클라이언트는 새로운 매니페스트를 토대로 스트리밍을 계속할 수 있다(미도시).

하나의 실시 예에서, 메니페스트 파일에 채널 셋-업 정보를 전달하는 대신에, 채널 셋-업 정보는 터미널 안에 미리-설정될 수 있거나 또는 다른(네트워크) 소스와는 별도의 커뮤나케이션 채널을 통해 검색할 수 있다. 이러한 경우에는, 클라이언트가 매니페스트 파일을 수신하면, 클라이언트는 도 2의 단계(208 내지 214)를 참조하여 설명한대로 스트리밍 제어 채널을 설정하기 위하여 채널 셋-업 정보를 검색하도록 스트리밍 제어 채널 클라이언트 기능을 촉발(trigger)할 수 있다.

다른 실시 예에서, 미디어 서버는 다중의 클라이언트에게 세그먼트를 스트리밍하도록 구성할 수 있고, 여기서 각각의 클라이언트는 도 2를 참조하여 설명한 바와 같이 네트워크-시작, 예를 들어, 서버-시작 제어를 가능하게 자체의 스트리밍 제어 채널과 연관된다. 이런 방식으로, 서버는 네트워크 파라메터, 예를 들어, 네트워크 트래픽 또는 서버의 프로세싱 로드(load)를 토대로 다중의 클라이언트에게 세그먼트 콘텐츠의 스트리밍을 통제할 수 있다. 예를 들어, 하나의 특별한 실시 예에서, 다른 클라이언트들은 다른 가입 신청(subscription)), 예를 들어, 프리미엄 신청 및 보통 신청과 연관될 수 있다. 미디어 서버와 연관된 로드-밸런싱 기능(240)이 로드(load)에서의 증가를 탐지하면, 그것은 CCSF에게 매니페스트 파일 업데이트를 시작하도록 신호함으로써 선제적으로 부하(load)를 감소시킬 수 있고, 여기서 (적어도 일부의) 보통의 클라이언트들에게는 이러한 클라이언트들로 하여금 저-비율 및/또는 저(더 낮은) 품질과 연관된 세그먼트를 요구하게 하는 새로운 매니페스트 파일을 제공한다.

매니페스트 파일 업데이트는 다양한 방법으로 실현할 수 있다. 하나의 실시 예에서, 업데이트된 매니페스트 파일의 전체 또는 적어도 일부는 스트리밍 제어 채널을 통해 클라이언트에게 보낼 수 있다. 또 다른 실시 예에서, CCSF는 매니페스트 업데이트 트리거를 클라이언트, 특히 CCCF에게 보낼 수 있고. CCCF는 (디폴트) 위치, 예를 들어, 오리지널 미디어 서버로부터, 또는 새로운 위치, 예를 들어, 매니페스트 파일 업데이트 트리거에서 식별된 (예를 들어, URL을 사용하여) 다른 미디어 서버로부터 업데이트된 또는 새로운 매니페스트 피일을 요청함으로써 응답한다.

도 3은 본 발명의 실시 예에 따른 클라이언트-측 흐름을 도시한다. 특히, 도 3은 세그먼트의 검색과 재생(play-out)을 위하여 및, 예를 들어, 도 2에 도시된 바와 같이 스트리밍 제어 채널을 통해 스트리밍의 서버-시작 제어를 제공하기 위하여 클라이언트에서 실행되는 프로세서와 연관된 프로세스 흐름을 도시한다. 프로세스는 클라이언트가 특별한 세그먼트 콘텐츠 아이템과 관련된 매니페스트 파일을 요청하는 것으로 시작할 수 있다(단계(300)).

매니페스트 파일은 세그먼트 위치를 포함할 수 있고 또한 스트리밍 제어 채널(WebSocket URL 같은) 및, 예를 들어, WebSocket 서브-프로토콜, WebSocket 버전 등등의 사용을 나타내는 일부 파라메터를 설정하기 위해 클라이언트에 의해 사용되는 채널 셋-업 정보도 포함할 수 있다. 서버로부터 매니페스트 파일을 수신하는 즉시, 클라이언트는 매니페스트 파일을 분석할 수 있고(단계(301 및302)), 클라이언트에서 적어도 두 개의 분리된 프로세스/스레드(threads)를 시작할 수 있다: 세그먼트 검색 및 세그먼트의 재생을 다루기 위해 클라이언트에서 미디어 스트리밍 클라이언트 기능에 의해 실행되는 적어도 제 1 프로세스 및 스트리밍 제어 채널을 다루기 위해 클라이언트에서 CCCF에 의해 실행되는 제 2 프로세서.

클라이언트는 주기적으로 세그먼트를 검색하여 비디오의 끝이 탐지될 때까지(단계(304)) 그것들을 재생(단계(303))하도록 매니페스트 파일에 설명된 세그먼트 위치를 사용할 수 있다. 또한, 클라이언트는 매니페스트 파일에 설명된 URL을 토대로 서버에 채널 셋업 요청을 보내고(단계(305)) 및 클라이언트, 특히 클라이언트 내의 CCCF와 서버, 특히, 서버와 연관된 CCSF 사이에 스트리밍 제어 채널을 설정하기 위해(단계(306)) 매니페스트 파일에 삽입(embeded)된 셋-업 정보를 사용할 수 있다. 그리고나서, 세그먼트를 스트리밍하고 재생하는 동안, CCCF는 서버로부터 들어오는 메시지를 위해 스트리밍 제어 채널에 따른다(listens to)(단계(307)). 스트리밍 제어 채널은 또한 클라이언트로부터 서버로 데이터를 전송하는데 사용할 수 있다.

서버로부터 들어오는 데이터의 경우에, CCCF는 매니페스트 업데이트 신호(매니페스트 업데이트 트리거)가 수신되었는지를 체크할 수 있다(단계(308)). 그러한 매니페스트 업데이트 신호가 수신되었으면, CCCF는 (그것이 오리지널 매니페스트를 받은 위치로부터 또는 매니페스트 업데이트 트리거에 명시된 URL로부터) 업데이트된 매니페스트를 요청할 수 있다(단계 309)). 업데이트된 매니페스트 파일을 수신한 후, 클라이언트는 그것을 분석하고(단계 302 참조), 세그먼트 식별자의 리스트 및 연관된 위치 정보를 업데이트한다.

도 4는 본 발명의 실시 예에 따른 서버-측 프로세서 흐름을 도시한다. 특히, 도 4는 클라이언트에게 세그먼트를 스트리밍하고 및 스트리밍 제어 채널을 사용하여 스트리밍의 네트워크-시작 제어를 제공하기 위하여 미디어 서버에 실행되는 프로세서의 프로세서 흐름을 도시한다. 상기 프로세서는 예를 들어, 도 2를 참조하여 설명한 미디어 서버에 호스트된 다양한 기능, 즉, 스트리밍 서버 기능, 제어 채널 서버 기능 및, 선택적으로, 로드-밸런싱(load-balancing) 기능에 의해 실행될 수 있다. 상기 기능들은 서버 로드를 모니터링하고 클라이언트로부터 세그먼트 요청에 응하고, 클라이언트와 함께 스트리밍 제어 채널을 셋업하고 유지하기 위하여 하나 또는 그 이상의 프로세서를 실행하도록 구성할 수 있다.

예를 들어, 제 1 프로세서는 클라이언트에 의해 서버로 보내진 채널 셋-업 요청의 수신을 모니터링하는 미디어 서버에서 실행될 수 있다(단계(402)). 그러한 요청이 수신되면, CCSF는 스트리밍 제어 채널을 셋-업할 수 있고 채널 핸들링 프로세서를 시작할 수 있으며, 여기서 클라이언트로부터 비롯되거나 또는 클라이언트에게 보내진 정보는, 예를 들어, 적절히 처리된다. 제 2 프로세서는 매니페스트 파일 및/또는 세그먼트에 대한 클라이언트로부터의 요청 수신을 다루는 미디어 스트리밍 서버 기능에 의해 실행될 수 있다(단계 400). 그러한 요청이 수신되면, 서버는 요청받은 정보(세그먼트 및/또는 매니페스트 파일)를 요청하는 클라이언트에게 보낼 수 있다(단계 401). 제 3 프로세스는 네트워크 로드 정보 및/또는 서버 로드 정보에 대한 로드 밸런싱 기능 모니터링과 관계가 있을 수 있다. 로드(load)가 특정한 임계치(threshold value)에 도달하거나 또는 접근하면, 그것은 CCSF에게 매니페스트 업데이트 파일을 위해 하나 또는 그 이상의 클라이언트를 선택하라는 신호를 보낸다(단계(405)). 응답으로, CCSF는 매니페스트 업데이터 트리거를 선택된 클라이언트에게 보낼 수 있다(단계 406).

에를 들어, 하나의 실시 예에서, 서버와 연관된 로드-밸런스 기능은 CCSF에게 서버의 프로세싱 로드를 감소시키기 위하여 매니페스트 파일 업데이트를 시작하라는 신호를 보낼 수 있다. 업데이트된 매니페스트 파일은 클라이언트에게 낮은 품질의 세그먼트를 토대로 스트리밍을 계속하라는 지시를 한다. 다른 실시 예에서. CCSF는 서버 로드 또는 서버 실패를 탐지할 수 있고 응답으로 하나 또는 그 이상의 클라이언트에게 다른 네트워크 서버로부터 온 세그먼트를 검색하라고 지시하기 위해 매니페스트 파일 업데이트를 시작한다.

매니페스트 업데이트 프로세스는 다수의 방법으로 실현할 수 있다. 하나의 실시 예에서, 업데이트된 매니페스트 파일은 스트리밍 제어 채널을 통해 CCSF에 의해 클라이언트 내의 CCCF에게 보낼 수 있다. 다른 실시 예에서, CCSF는 클라이언트 내의 CCCF에게 매니페스트 파일 업데이트 트리거를 보낼 수 있고, 그것은 응답으로 미디어 서버로부터 업데이트된 또는 새로운 매니페스트 파일을 요청한다. 또 다른 실시 예에서, 매니페스트 파일 업데이트 트리거는 위치 정보, 예를 들면, 다른 미디어 서버의 URL을 포함할 수 있고, 그래서 클라이언트는- 위치 정보를 토대로- 그런 다른 미디어 서버로부터 업데이트된 또는 새로운 매니페스트 파일을 요청할 수 있다(단계 406).

도 5A 내지 5C는 네트워크-시작 스트리밍 제어를 가능하게 하는 스트리밍 제어 채널을 설정하기 위한 다양한 비-제한 프로토콜을 도시한다. 특히, 도 5A는 도 2와 유사한 메시지 흐름을 도시하며, 여기서 HTTP WebSocket 프로토콜은 스트리밍 제어 채널을 세팅하는데 사용된다. 상기 프로세서는 사용자가 웹사이트에서 비디오에 대한 링크를 선택하는 것으로 시작할 수 있고, 여기서 URL은 매니페스트 파일을 (리디렉션을 통해)가리킬 수 있다(단계 500a). 응답으로, 클라이언트는 서버로부터 매니페스트 파일을 획득하기 위하여 HTTP GET 요청을 보낼 수 있고(단계 501a). 그것은 서버에 의해(이 경우에 XML 파일의 형태로) 클라이언트에게 보내진다(단계 502a). 클라이언트는 비디오를 구성하는 세그먼트의 적어도 일부의 위치를 획득하기 위하여 매니페스트 파일을 분석할 수 있고(단계 503a), WebSocket 셋업 요청( (HTTP GET WS ws://...)을 서버에 보내기 위하여 매니페스트 파일에 삽입된 정보를 사용할 수 있다(단계 504a). 강제적인 WebSocket handshake(신호변경)를 수행한 후((WS draft draft-ietf-hybi-thewebsocketprotocol-17)에 자세히 기술된 바와 같이), 서버는 HTTP 101 SWITCHING PROTOCOLS 메시지를 사용하여 클라이언트로부터 WebSocket 요청을 받아들일 수 있다(단계 505a). 그리고나서, 생성된 WebSocke를 통해 들어오는 메시지를 다루기 위해, 서버는 전용 프로세스/스레드를 생성할 수 있고(단계 506a), 그것에 의해 서버-시작 스트리밍 제어를 제공하는데 사용할 수 있는 WebSocket 스트리밍 제어 채널을 설정한다(단계 507a).

WebSocket 프로토콜은 베스트-에포트(best-effort)인터넷 연결을 통해 풀-듀플렉스(full-duplex), 양-방향 통신을 허용한다. 서버와 클라이언트 둘 다 스트리밍 제어 채널을 통해 언제든지, 또는 심지어 동시에 데이터를 보낼 수 있다. 오직 데이터만이 HTTP 헤더(header)의 오버헤드 없이 보내지고, 그 때문에 대역폭을 맹렬히 증가시킨다. 게다가, WebSocket은 HTTP-기반의 프로토콜이기 때문에, 보통 자동으로 방화벽 또는 네트워크 주소 번역기(NATs)에 의해 봉쇄되지 않는다.

도 5B는 SIP 프로토콜을 사용하여 도 2와 유사한 스트리밍 제어 채널을 셋업하기 위한 메시지 흐름을 도시한다. 상기 프로세서는 사용자가 웹사이트상의 비디오에 대한 링크를 선택하는 것으로 시작할 수 있고 여기서 URL은 매니페스트 파일을 (예를 들어, 리디렉션을 통해)가리킬수 있다 (단계500b)). 응답으로, 클라이언트는 서버로부터 매니페스트 파일을 획득하기 위해여 HTTP GET 요청을 보낼 수 있고(단계501b)), 그것은 서버에 의해(이 경우에 XML 파일의 형태로) 클라이언트에게 보내진다(단계 502b).

클라이언트는 비디오를 구성하는 세그먼트의 위치를 획득하기 위햐여 매니페스트 파일을 분석할 수 있고(단계 503b), SIP INVITE 메시지를 SIP 애플리케이션 서버로 보내기 위하여 매니페스트 파일에 삽입된 정보를 사용할 수 있다(단계504b). 이 정보는 세션 디스크립션(Description) 프로토콜 메시지[http://www.ietf.org/rfc/rfc4566.txt]로서 포맷될 수 있다. 서버는 INVITE 메시지를 받아들일 수 있고, SIP 200 OK 메시지로 응답할 수 있다(단계 505b). 그리고나서, 생성된 SIP 세션을 통해 들어오는 메시지를 다루기 위해, 서버는 전용 프로세스/스레드를 생성할 수 있고(단계 506b), 그것에 의하여 서버-시작 스트리밍 제어를 제공하는데 사용될 수 있는 SIP-기반의 스트리밍 제어 채널을 설정한다(단계 507b).

도 5C는 XMPP프로토콜을 사용하여 도 2와 유사한 스트리밍 제어 채널을 셋업하기 위한 메시지 흐름을 도시한다. 상기 프로세서는 사용자가 웹사이트상의 비디오에 대한 링크를 선택하는 것으로 시작할 수 있고, 여기서, URL은 매니페스트 파일을 (예를 들어 리디렉션을 통해) 가리킬 수 있다(단계 500c). 응답으로, 클라이언트는 서버로부터 매니페스트 파일을 획득하기 위하여 HTTP GET 요청을 보낼 수 있고(단계 501c), 그것은 서버에 의해 (이 경우 XML 파일의 형태로) 클라이언트에게 보내진다(단계 502c).

클라이언트는 비디오를 구성하는 세그먼트의 위치를 획득하기 위하여 매니페스트 파일을 분석할 수 있고(단계 503c), XMP 세션 요청 메시지를 XML 스트림을 통해 하나 또는 그 이상의 XML 스탠자(Stanzas)의 형태로 XMPP 서버로 보내기 위하여 XMPP 서버의 Jabber Identifier (JID와 같은 매니페스트 파일에 삽입된 정보를 사용할 수 있다(단계 505c). XMPP 서버는 세션 요청 메시지를 받아들일 수 있고, 세션 생성 결과 메시지로 응답할 수 있다(단계 506c), 그리고나서, 만들어지는 XMPP 세션을 통해 들어오는 메시지를 다루기 위하여, 서버는 전용 프로세서/스레드를 만들 수 있고(단계 507c), 그것으로 인해 서버-시작 스트리밍 제어를 제공하는데 사용될 수 있는 XMPP-기반의 스트리밍 제어 채널을 설정한다(단계 508c).

도 6은 본 발명의 하나의 실시 예에 따라 클라이언트에게 세그먼트 콘텐츠를 전달하기 위한 콘텐츠 스트리밍 시스템(600)을 도시한다. 특히, 도 6은 CDN을 포함하는 콘텐츠 전달 시스템의 구성적인 개요를 도시하며, CDN은 CDN의 하나 또는 그 이상의 전달 노드와 하나 또는 그 이상의 클라이언트 사이의 스트리밍 프로세스의 네트워크-시작 제어를 제공하도록 구성된다. 네트워크-시작 제어는 도 2 내지 도 5를 참조하여 설명한 스트리밍 제어 채널 기능성을 토대로 실현될 수 있다.

이러한 실 시 예에서, 콘텐츠 전달 시스템은 적어도 하나의 콘텐츠 전달 네트워크((CDN), 602), 트랜스포트 네트워크(600)를 통하여 하나 또는 그 이상의 클라이언트(603)에게 연결된 콘텐츠 소스를 포함할 수 있다. 콘텐츠 소스는 콘텐츠 프로바이더 시스템(CPS), 콘텐츠 준비 시스템 또는 다른 CDN과 관계가 있다. CPS는 콘텐츠, 예를 들어, 오디오 아이템 또는 비디오 타이틀을, 클라이언트를 사용하여, 콘텐츠를 구매하고 수신할 수 있는 고객에게 제공하도록 구성할 수 있다.

클라이언트에게 터미널, 즉, 예를 들어, 전자 태블렛, 스마트 폰, 노트북, 미디어 플레이어 등등과 같은(모바일) 콘텐츠 프로세싱 장치에서 실행하는 소프트웨어 프로그램을 제공할 수 있다. 일부 실시 예에서, 터미널은 콘텐츠 재생 장치에 위해 미래에 소비되도록 콘텐츠를 처리하고 일시적으로 저장하도록 구성된 셋-탑 박스 또는 콘텐츠 저장 장치일 수 있다.

CDN은 전달 노드 (DN1,DN2)( 611,612) 및 적어도 하나의 중앙 CDN 노드(CCN) (610)를 포함할 수 있다. 각각의 전달 노드는 콘텐츠 저장 및 버퍼링을 위해 제어기(630,631) 및 캐시(cache, 632,633)를 포함하거나 또는 그것에 연관될 수 있다. 각각의 CCN은 외부 소스, 예를 들어, 콘텐츠 프로바이더, 또는 다른 CDN으로부터 콘텐츠의 인제스쳔(ingestion, 입수) 제어를 위한 인제스쳔 기능(또는 콘텐츠 오리진 기능, COF)(620), 콘텐츠가 CDN 내의 어디에 저장되는지에 관한 정보를 유지하기 위한 콘텐츠 위치 데이터베이스(622), 콘텐츠 전달 노드에 하나 또는 그 이상의 콘텐츠의 카피 분배(copy distribution)를 제어하고 및 적당한 전달 노드로 클라이언트를 리디렉팅하기( 또한 요청 루팅으로서 알려진 프로세서)위한 CDN 제어 기능(CDNCF, 621)을 포함하거나 또는 그것과 연관이 있을 수 있다, 분배는 클라이언트에 대한 콘텐츠 전달에 충분한 대역폭이 CDN 전체에 보장되도록 제어할 수 있다. 하나의 실시 예에서, CDN은 ETSI TS 182 019에 기술된 바와 같이 CDN과 관련될 수 있다.

고객은 세그먼트 콘텐츠, 예를 들어, 구매 가능한 비디오 타이틀을 식별하는 타이틀 조회를 제공하도록 구성된 웹 포털(WP)(661)에 요청을 보냄으로써 CPS(600)로부터 비디오 타이틀을 구매할 수 있다. 요청에 대한 응답으로, 클라이언트는 WP로부터 타이틀 조회의 적어도 일부 및 위치 정보, 예를 들어, 선택된 콘텐츠를 전달할 수 있는 CDN의 CDNCF의 URL을 수신할 수 있다. CDNCF는 선택된 콘텐츠를 클라이언트에게 전달하도록 구성된 하나 또는 그 이상의 전달 노드와 연관된 위치 정보를 클라이언트에게 보낼 수 있다. 세그먼트는 CDN 노드 내의 하나의 전달 노드에, 또는 선택적으로, CDN 내의 다른 전달 노드에 호스트될 수 있다. 예를 들어, 더 많은 세그먼트들이 CDN 내의 다수의 전달 노드에 호스트(hosted)될 수 있어서 적시에 전달(delivery)이 보장된다. 일반적으로, CDNCF는 CDN에서 클라이언트에게 선택된 콘텐츠를 전달하기에 가장 적합한 전달 노드를 선택할 수 있다. 하나 또는 그 이상의 전달 노드를 선택하는 기준은 전달 노드의 프로세싱 로드 및/또는 클라이언트와 연관된 콘텍스츄얼(contextual, 전후관계의) 정보를 토대로 할 수 있다; 예를 들어, 클라이언트의 위치(IP주소) 및/또는 클라이언트의 가입 신청(도 2를 참조하여 위에 설명한 바와 같은 프리미엄 가입신청 또는 일반 가입신청). 따라서, 이런 방식으로, CDNCF는 세그먼트를 클라이언트에게 효과적으로 전달하기에 최적인 매니페스트 파일을 다이나믹하게 생성할 수 있다.

클라이언트는 CDN에서, 예를 들어, 종래의 DNS 시스템을 사용하는 전달 노드와 접속할 수 있다. 또한, 다양한 스트리밍 프로토콜이 비디오 재생(play-out) 기능(651)에 의한 재생(play-out)을 위해 스트림을 처리하는 미디어 스트리밍 기능(652)에 콘텐츠를 전달하는데 사용할 수 있다. 그러한 프로토콜은 HTTP 및 RTP/RTCP 타입 스트리밍 프로토콜을 포함할 수 있다. 바람직한 실시 예에서, HTTP 적응 스트리밍(HAS) 같은 적응 스트리밍 프로토콜 및 HTTP를 통한 Apple HTTP Live Streaming, Microsoft Smooth Streaming, Adobe HTTP Dynamic Streaming, 3GPP-DASH 및 MPEG Dynamic Adaptive Streaming 같은 관련된 프로토콜이 사용될 수 있다.

CDNs는 세그먼트 콘텐츠를 인제스트(ingest, 입수)하고 분배하도록 구성된다. 알려진 세그먼트 스티리밍 시스템들은 HTTP 적응 스트리밍(HAS) 같은 타임 세그먼테이션을 토대로 할 수 있고, 콘텐츠는 MPEG 또는 AVI 같은 알려진 트랜스포트 컨테이너 포맷에 따라 포맷할 수 있는.다수의 세그먼트(조각들 또는 부분들)로 조직될 수 있다.

세그먼트들 사이의 관계는 특정 파일 내임(name) 확장자, 예를 들어, .mf, .xml 및 .m3u8를 사용하여 저장되고 식별될 수 있는 매니페스트 파일에서 설명할 수 있다. 매니페스트 파일은 또한 하나 또는 그 이상의 전달 노드에 다른 세그먼트들의 위치 및 내임(세그먼트 식별자)을 설명할 수 있다. 세그먼트들, 특히 인기 있는 세그먼트들은 CDN에서 하나 또는 그 이상의 전달 노드에서 검색할 수 있다. 게다가, 특정 상황에서, 세그먼트는 다른 CDN 도메인의 전달 노드에서 검색할 수 있다. 그런 상황은 도 12 및 도 13을 참조하여 자세히 설명할 것이다. CDNCF는 세그먼트를 검색할 수 있는 위치를 관리할 수 있다. 그러한 목적에, CDNCF 는 콘텐츠 위치 데이터베이스(622)를 사용할 수 있다. 하나의 실시 예에서, 콘텐츠 위치 데이터베이스는 ETSI TS 182 019에 기술된 바와 같이 Asset Location Function (ALF)과 관계가 있을 수 있다.

또한, CDN은 클라이언트와 연관된 스트리밍 제어 채널을 셋-업하고 관리하며 및 클라이언트들과 이러한 클라이언트들이 연결된 전달 노드(들)를 포함하는 데이터베이스를 관리하도록 구성된 전달 연속성 노드(Delivery Continuity Node ((DCN), 613))를 포함할 수 있다. DCN은 전달 연속성 관리 기능((DCMF)(640)을 포함할 수 있다. 이러한 기능은 CDNCF 의 요청 루팅(RR)에서 비롯되는 모니터링 통지를 위한 프로세서를 실행할 수 있다. DCN은 또 클라이언트로부터의 채널 셋-업(CCCF) 요청을 모니터링하고, 클라이언트에서 제어 채널 서버 기능((CCCF)(650)으로 스트리밍 제어 채널을 셋-업하기 위하여 DC에 제어 채널 서버 기능((CCSF)(641)을 포함할 수 있다. 또한, DCN 내의 또는 DCN과 연관된 전달 연속성(DC) 데이터베이스(642)는 클라이언트 정보(예를 들어, 클라이언트의 IP 주소) 및 매니페스트 파일 정보(즉, 세그먼트 식별자들(예를 들어, 파일 내임들), 및 적어도 이러한 세그먼트들을 호스팅하는 전달 노드들의 일부)를 저장할 수 있다. 전달 연속성 관리 기능(DCMF)은 CDNCF 또는 CDN의 분리된 네트워크 모니터링 기능에서 비롯되는 네트워크 통지, 예를 들어, (과)부하 통지 또는 실패 통지에 대해 모니터링 할 수 있고, 그러한 네트워크 통지의 수신에 응하여 매니페스트 파일 업데이트 프로세서를 시작할 수 있다. CDN에서의 프로세서와 기능에 관한 세부 사항은 도 8을 참조하여 설명한다.

도 6에서는, DCN에서의 기능, 즉, DCMF 및 CCSF는 분리된 노드(DCN)에서 구현되지만. 다른 실시 예에서, 이러한 기능들은 CDNCF 및 인제스쳔(ingestion) 기능을 포함하는 CCN(610)에서 완전히 또는 부분적으로 구현할 수 있다.

도 7은 본 발명의 실시 예에 따라 콘텐츠 스트리밍 시스템에 사용할 메시지 흐름을 도시한다. 특히, 도 7은 CDN 의 하나 또는 그 이상의 전달 노드와 하나 또는 그 이상의 클라이언트 사이에 스트리밍 프로세서의 네트워크-시작 제어를 제공하도록 구성된 CDN-타입 콘텐츠 스트리밍 시스템에 사용할 메시지 흐름을 도시한다. 이러한 실시 예에서, CDN은 적어도 제 1 및 제 2 전달 노드 (DN1, DN2) 및 도 6을 참조하여 설명한 바와 같이 CDNCF, DCMF를 포함하는 CCSF를 포함할 수 있다.

도 7에서 프로세서는 사용자가 웹사이트 상에서 비디오에 대한 링크를 선택하는 것으로 시작할 수 있으며, 여기서 URL은 (리디렉션을 통해) 매니페스트 파일을 가리킬 수 있다(단계 700). 선택 즉시, 클라이언트는 매니페스트 파일을 획득하기 위해 HTTP GET 요청을 CDNCF에게 보낼 수 있다(단계 701). CDNCF는 매니페스트 파일을 클라이언트에게 보냄으로써 요청에 응답할 수 있다(단계 702).이러한 경우에, 로드-밸런싱 기능으로부터의 정보를 토대로, CDNCF는 제 1 전달 노드(DN1)에 저장된 세그먼트들에 대한 참조(reference)(예를 들어, 세그먼트 식별자들 및/또는 연관된 위치 정보)를 포함하고 있는 매니페스트 파일을 선택하고 및/또는 생성할 수 있다. 또한, CDNCF는 특정 고객( 예를 들면, IP 주소에 의해 정의된)에게 특정(세트의)전달 노드(이 예에서는 전달 노드 DN1)에 참조를 포함하는 매니페스트 파일을 전달했다는 사실을 기록한다, 그 목적을 위해, CDNCF는 클라이언트 정보(예를 들어, 클라이언트의 IP 주소)와 ,비디오 타이틀의 적어도 일부와 연관된, 매니페스트 파일(예를 들어, 매니페스트 식별자 Manifest ID) 및 후에 사용하기 위하여 전달 연속성(DC) 데이터베이스에서 매니페스트 파일에 의해 참조되는 세그먼트를 호스팅하는 특정(세트의) 전달 노드(들)의 위치 정보를 저장할 수 있다(단계 703).

여기서, 매니페스트 파일 식별자는 번호에 의해 식별할 수 있고 전달 노드는 CDN 내에 알려진 전달 노드 식별자에 의해 식별할 수 있다. 클라이언트는 비디오를 구성하는 세그먼트의 위치(예를 들어, URL)를 획득하기 위하여 매니페스트 파일을 분석할 수 있다(단계 704). 또한, 클라이언트에서 CCCF는 CDN에서 CCCF 와 CCSF 사이에 스트리밍 제어 채널을 셋업하기 위하여 매니페스트 파일에서 채널 셋-업 정보를 사용할 수 있다(단계 705a) (CCCF 와 CCSF 사이에 스트리밍 제어 채널을 셋업하는 프로세서는 도 2와 도 3을 참조하여 설명하고 여기서는 반복하지 않는다).

스트리밍 제어 채널의 설정 동안, CCSF는 채널 셋업 요청을 특정 클라이언트 및 DC 데이터베이스에 저장된 정보를 사용함으로써 하나 또는 그 이상의 연관된 전달 노드와 관련시킬 수 있다(단계 705b). 특히, CCSF는 스트리밍 제어 채널을 설정할 클라이언트(여기서 클라이언트는 예를 들면, 식별된 IP일 수 있다.)에 대해 DC 데이터베이스에 문의하고, 그 클라이언트에게 속하는 데이터베이스 엔트리에 고유한 스트리밍 채널 식별자, 또는 채널 ID(예를 들어 포트 번호, 또는 WebSocket를 사용하는 경우에는 WebSocket ID)를 할당할 수 있다.

일단 스트리밍 제어 채널이 설정되면, 클라이언트는 제 1전달 노드(DN1)로부터 (매니페스트 파일에서 언급한 바와 같이) 제 1 세그먼트( 이 경우에는 세그먼트-로우-1)를 요청함으로써 스트리밍 프로세서를 시작할 수 있다(단계 706). 전달 노드(DN1)는 요청받은 세그먼트를 클라이언트에게 스트리밍함으로써 응답할 수 있다(단계 707).

스트리밍 프로세서 동안, 조만간 어느 시점에서, CDNCF (CDN에서 전달 노드의 로드를 모니터링하기 위한 로드 밸런스 기능을 포함한 또는 연관된)는 제 1 전달 노드( DN1)상의 로드가 (최대의) 임계 레벨에 접근한다는 것을 통지할 수 있다(단계 708). CDNCF 는 DC 데이터베이스에 저장된 정보를 체크함으로써 어느 클라이언트가 제 1 전달 노드(DN1)를 사용하고 있는지 체크하도록 알릴 수 있다(단계 709). DCMF는 그리고나서 일부 클라이언트를 제 1 전달 노드(DN1)로부터 다른 제 2 전달 노드( DN1)로 리디렉터하도록 결정을 내릴 수 있으며, 그래서 제 1 전달 노드( DN1)의 프로세싱 로드는 감소된다. 그런 목적을 위하여, DCMF는 CCSF에게 DC 데이터 베이스의 정보를 사용하여 DCMF에 의해 선택된 클라이언트의 스트리밍 제어 채널을 통해 매니페스트 업데이트 트리거를 보내도록 지시할 수 있다(단계 710).

매니페스트 업데이트 트리거를 수신하는 즉시, 클라이언트에서 CCCF는 매니페스트 요청을 CDNCF에게 보냄으로써(단계(701)을 참조하여 설명한 바와 유사한 방식으로) 새로운 또는 업데이트된 매니페스트 파일을 요청하도록 트리거된다(단계711). CDNCF는 매니페스트 요청을 수신할 수 있고 또는 클라이언트를 위하여 새로운 또는 업데이트된 매니페스트 파일을 선택하거나 또는 생성할 수 있고 및 클라이언트에게 이 매니페스트 파일을 보낼 수 있다.

하나의 실시 예에서, 새로운 또는 업데이트된 메니페스트 파일을 생성할 때, CDNCF는 새로운 전달 노드를 선택하기 위하여 로드-밸런싱 기능으로부터 정보를 사용할 수 있다(또한 단계(702) 참조). 또한, 새로운 또는 업데이트된 메니페스트 파일은 제 2 전달 노드( DN2)에 저장된 세그먼트에 대한 링크를 포함할 수 있다.

하나의 실시 예에서, 매니페스트 업데이트 트리거는 위치 정보, 예를 들면, 새로운 또는 업데이트된 메니페스트 파일을 포함하고 있는 다른 노드를 식별하는, URL을 포함할 수 있다. 다른 실시 예에서, 클라이언트에게 새로운 또는 업데이트된 메니페스트 파일을 검색하라는 신호를 보내기위해 매니페스트 업데이트 트리거를 보내는 대신에, 새로운 또는 업데이트된 메니페스트 파일을 스트리밍 제어 채널을 통해 클라이언트에게 직접 전송할 수 있다. 업데이트된 매니페스트 파일을 클라이언트에게 보낸 후, 그것은 제 2 전달 노드( DN2)로부터 세그먼트의 스트리밍을 재개하기 위하여 새로운 또는 업데이트된 메니페스트 파일을 사용한다(미도시).

클라이언트가 새로운 또는 업데이트된 매니페스트 파일을 수신하기 때문에, CDNCF는 (703)을 참조하여 설명한 단계를 수행함으로써 DC 데이터베이스에서 해당 클라이언트와 연관된 매니페스트 파일 정보를 업데이트할 수 있다. 이러한 방법으로, 미래의 어느 시점에서 오버로드 문제가 발생할 경우에, CDNCF는 클라이언트를 다른 전달 노드로 리디렉터할 수 있다.

도 8은 본 발명의 하나의 실시 예에 따른 전달 연속성성 노드(DCN)와 연관된 프로세스 흐름을 도시한 것이다. 특히 도 8은 도 6을 참조로 기술된 전달 연속성 노드(DCN) 상에 호스트할 수 있는 하나 또는 그 이상의 기능에 대한 개요(overview)를 제공한다. CDN은 클라이언트와 연관된 스트리밍 제어 채널을 셋-업하고 관리하며 및 그들과 연결된 클라이언트와 전달 노드를 기재하는 일람표(tables)를 유지하도록 구성할 수 있다. 다른 실시 예에서, DCN과 연관된 기능들 전부 또는 적어도 일부는 CCN에서 호스트할 수 있다(도 7, 9, 11 및 13 참조).

DCN은 전달 연속성 관리 기능(DCMF)을 포함할 수 있다. 이 기능은 CDNCF의 요청 루팅 기능으로부터 비롯되는 통지를 모니터링하기 위한 프로세스를 실행할 수 있다(단계 800). CDNCF가 클라이언트에게 매니페스트 파일을 보내거나 또는 클라이언트를 특정 전달 노드로 리디렉터할 때마다, CDNCF는 DCN에게 어느 전달 노드로부터 클라이언트가 세그먼트를 검색할 것으로 예상되는지를 알릴 수 있다(즉, 클라이언트에게 보낸 매니페스트 파일에서 참조(referenced)되는 전달 노드 또는 클라이언트에게 리디렉션되는 전달 노드).

통지를 수신하는 즉시, DCN은 특정 클라이언트(예를 들어, 그것의 IP 주소에 의해 식별된)를 해당 클라이언트(단계 801)에게 보낸 매니페스트 파일에서 참조된 전달 노드의 적어도 일부에 할당하는 전달 연속성(DC) 데이터베이스에 엔트리를 추가할 수 있다. 또한, 제어 채널 서버 기능(CCSF)은 클라이언트의 CCCF에서 채널 셋-업 요청을 모니터링할 수 있다(단계 802). 그것이 요청을 수신하면, 적절한 프로토콜, 예를 들어, WebSocket, SIP 또는 XMPP와 같은 적절한 프로토콜을 바탕으로 스트리밍 제어 채널을 설정하는 프로세스를 시작할 것이다.

스트리밍 제어 채널의 설정 동안에, CCSF는 스트리밍제어 채널이 설정되는 클라이언트에 대해 문의할 수 있고(여기서 클라이언트는 예를 들어, 식별된 IP주소일 수 있음), 클라이언트(단계 803)에 속하는 데이터베이스 항목에 고유 스트리밍 채널 식별자(예를 들면, 포트 번호 또는, WebSocket를 사용하는 경우에는, WebSocket ID)를 할당할 수 있다(단계 803).

그 다음에 DCMF는 CDNCF로부터 네트워크 오버로드 통지 또는 실패 통지, CDNCF와 연관된 로드 균형 기능(단계804) 또는 분리된 네트워크 모니터링 기능과 같은 네트워크 통지를 모니터링하기 위한 모니터링 프로세스를 실행할 수 있다. 하니의 실시 예에서, 오버 로드 또는 실패 통지는 CDNCF가 리디렉션을 원하는 클라이언트의 수에 관한 정보를 포함할 수 있다.

일단 DCMF가 CDNCF로부터 그러한 통지(그 자체 CDN의 전달 노드와 관련되거나 또는 다른 CDN(미도시)의 전달노드와 관련되는)를 수신하면, 오버로드 또는 실패 통지와 연관된 전달 노드로부터 세그먼트를 검색할 것으로 예상되는 클라이언트에 대해 체크하기 위하여 DC 데이터베이스에 문의할 수 있다(단계 805). 그다음에, DCMF는 리디렉션할 하나 또는 그 이상의 클라이언트(이 선택은 단계(804)를 참조하여 상기한 바와 같이 리디렉션할 클라이언트의 수에 기초할 수 있다)를 선택할 수 있다(단계 806). 그 후, DCMF는 선택한 클라이언트와 연관된(에를 들어, 스트리밍 채널 식별자를 사용하여)스트리밍 채널을 식별하고, 이 채널들 각각을 통해 매니페스트 업데이트 트리거를 보내기 위하여 자체의 데이터베이스에 문의할 수 있다.

DMCF는 클라이언트로부터 비롯된 메시지를 모니터하도록 구성할 수 있다. 하나의 실시 예에서, DMCF는 클라이언트에게 스트리밍 제어 채널을 통해서 새로운 또는 업데이트된 매니페스트 파일을 전송할 수 있다.

도 9는 본 발명의 다른 실시 예에 따라 콘텐츠 스트리밍 시스템에 사용할 메시지 흐름을 나타낸다. 특히, 도 9는 도 7과 유사한 콘텐츠 전달 시스템과 함께 사용할 메시지 흐름을 나타낸다. 그러나 이 실시 예에서 매니페스트 파일은 클라이언트에게 CDNCF에 의해 전달되지 않고 그들 자체 전달 노드에 의해 전달된다. 이를 위해, 예를 들어 제 1 전달 노드(DN1)는 단지 해당 전달 노드 상의 세그먼트에 대한 참조를 포함할 수만 있는 매니페스트 파일을 포함할 수 있다.

도 9의 프로세스는 사용자가 웹 사이트 상에서 비디오에 대한 링크를 선택하는 것으로 시작할 수 있으며, 여기서, URL 은 (예를 들어, 콘텐츠 제공자로부터 리디렉트를 통해) CDNCF의 요청 루팅(RR) 기능을 가리킨다(단계 900). 클라이언트가 CDNCF에 HTTP GET 요청을 보낸 후(901 단계), CDNCF의 RR-기능은, 예를 들어, 로드 밸런싱 기능으로부터 획득된 정보를 토대로, 요청받은 매니페스트 파일 및 연관된 세그먼트 콘텐츠를 클라이언트에게 전달하기에 적합한 전달 노드를 선택할 수 있다. CDNCF는 그리고나서 선택한 전달 노드(이 특정 예에서는 제 1 전달 노드(DN1))상의 매니페스트 파일에 대한 URL을 포함하는 HTTP 리디렉션 메시지를 클라이언트에게 보낼 수 있다(902 단계).

HTTP의 GET 요구를 리디렉팅할 때, CDNCF는 후에 사용하기 위하여 전달 연속성(DC) 데이터베이스에 클라이언트 정보(예를 들면, 클라이언트의 IP 주소) 및 적어도 비디오 타이틀의 일부와 연관된, 매니페스트 파일 정보(예를 들면, 매니페스트 파일 식별자, 또는 적어도 비디오 타이틀의 일부와 연관된 매니페스트 ID, 및 매니페스트 파일에 의해 참조되는 세그먼트를 호스팅하는 특정(세트)의 전달 노드(들)의 위치 정보)를 저장할 수 있다(단계(903)). 여기서, 매니페스트 파일 식별자는 CDN 내에서 알려진 전달 노드 식별자에 의해 식별될 수 있는 번호와 전달 노드들에 의하여 식별될 수 있다.

CDNCF로부터 HTTP REDIRECT 메시지를 수신하는 즉시, 클라이언트는 제 1 전달 노드와 연관된 REDIRECT 메시지로 URL에 새로운 HTTP GET 메시지를 보낼 수 있다(단계904). 이어서 전달 노드(DN1)는 클라이언트에게 요청된 매니페스트 파일을 보냄으로써 응답한다(단계(905)).

매니페스트 파일을 수신한 후, 클라이언트는 비디오를 구성하는 세그먼트의 위치를 얻기 위해 매니페스트 파일을 분석할 수 있다(단계 906). 클라이언트에서 CCCF는 CCSF와 클라이언트 사이에 스트리밍 제어 채널을 설정하기 위하여 매니페스트 파일에서 채널 설정 정보를 사용할 수 있다(단계 907A)(채널을 설정하는 프로세스는 도 2와 3에 도시되어 여기서는 반복하지 않는다).

스트리밍 제어 채널의 설정 동안에, CCSF는 DC 데이터베이스에 저장된 정보를 사용함으로써 채널 설정 요청을 특정 클라이언트 및 연관된 전달 노드와 상호 관련시킬 수 있다(단계 907b). 특히, CCSF는 스트리밍 제어 채널이 설정될 클라이언트(여기서 클라이언트는 , 예를 들어, IP 주소로 식별될 수 있음)에 대해 문의할 수 있고, 고유의 스트리밍 채널 식별자(예를 들어 포트 번호, 또는 WebSocket를 사용하는 경우에는, WebSocket ID)를 클라이언트에 속하는 데이터베이스 엔트리에 할당할 수 있다. 이러한 방법으로, CDN에서의 기능은 클라이언트/채널 조합이 어느(세트의) 전달 노드를 사용하고 있는지를 체크할 수 있다(예를 들어 이런 경우에, CDNCF는 특정 클라이언트가 제 1 전달 노드(DN1)를 사용하고 있고, 특정 매니페스트 파일을 수신했음을 체크할 수 있다).

일단 스트리밍 제어 채널이 설정되면(예: 도 2 및 3에서 설명한 것처럼), 클라이언트는 제 1 전달 노드(DN1)로부터 획득한 세그먼트를 요청, 수신 및 재생을 시작할 수 있다(단계 908). 스트리밍 프로세스 동안에, 조만간 어떤 시점에서, CDNCF(CDN에서 로드 전달 노드를 모니터링하기 위한 로드-밸런싱 기능을 포함하거나 또는 그것과 연관되는)는 제 1 전달 노드(DN1)의 부하(load)가 미리 설정된 (최대)의 임계 레벨에 도달함을 통지할 수 있다(단계 909). CDNCF는 DC 베이스에 저장된 정보를 확인함으로써 어느 클라이언트가 제 1 전달 노드(DN1)와 연관되는지를 결정하도록 DCMF를 트리거할 수 있다(단계 910). 이러한 정보를 바탕으로, DCMF는 제 1 전달 노드(DN1)로부터 일부(또는 모두) 클라이언트를 멀리 떨어지게 리디렉터하도록 결정할 수 있다.

그러기 위해서는, 이러한 클라이언트들에게 제어 채널을 통해서 매니페스트 업데이트 트리거를 보내도록 CCSF를 트리거할 수 있다(단계 911). 클라이언트가 제 1 전달 노드(DN1)(기본적으로)로부터 그들의 업데이트 매니페스트를 수신하지 못함을 확인하기 위하여, 매니페스트 업데이트 트리거는 새로운 또는 업데이트 매니페스트 파일(예를 들어, 제 2 전달 노드(DN2)를 가리키는)과 연관된 URL을 포함할 수 있다. 매니페스트 업데이트 트리거 신호의 수신으로 클라이언트에게 새로운 매니페스트 파일을 요청해야 한다는 신호를 보낼 수 있다. 매니페스트 업데이트 트리거로 언급되는 제 2 전달 노드(DN2)와 연관된 URL에 매니페스트 파일을 보낼 수 있다(단계(912)). 제 2 전달 노드(DN2)는 클라이언트에게 요청받은 매니페스트 파일을 전송함으로써 응답할 수 있다.

이 매니페스트 파일을 수신하는 즉시, 클라이언트는 제 1 전달 노드(DN1)대신에 제 2 전달 노드(DN2)로부터 후속 세그먼트를 요청함으로써 스트리밍 프로세스를 계속할 수 있다(단계 913). 클라이언트가 새로운 또는 업데이트된 매니페스트 파일을 수신했기 때문에, CDNCF는 단계(903)을 참조하여 설명된 단계를 수행함으로써 DC 데이터베이스에서 해당 클라이언트와 연관된 매니페스트 파일 정보를 업데이트할 수 있다. 이 방법으로, 미래의 일부 시점에서 오버로드 문제가 발생하면, CDNCF는 클라이언트를 다른 전달 노드에 다시 리디렉션할 수 있다.

따라서, 도 9에 도시된 실시 예에서, 클라이언트와 CCSF 사이에 스트리밍 제어 채널을 설정하기 위한 채널 설정 정보를 포함하는 매니페스트 파일은 세그먼트가 저장되는 전달 노드에 저장된다. 이러한 구현은 CDNCF의 로드 및 복잡성의 일부가 전달 노드로 오프로딩(offloaded)되는 장점을 제공한다. 도 7에서 CDNCF는 매니페스트 파일을 호스트 및/또는 생성하여, 매니페스트 파일이 업데이트될 때마다 로드가 CDNCF에 추가된다. 특정 구현에서, 예를 들어, 라이브 콘텐츠의 경우, 클라이언트-시작 매니페스트 업데이트는 꽤 자주, 예를 들면, 매 30초 마다 한번 발생하여, 그것으로 인해 DNCF 상의 로드를 상당히 증가시킨다. 따라서, 클라이언트-시작 매니페스트 요청에 응답하는 작업을 전달 노드에 위임함으로써, CDNCF의 상당한 로드 감소는 실현될 수 있다.

도 10은 본 발명의 또 다른 실시 예에 따른 콘텐츠 스트리밍 시스템에서 사용하기 위한 메시지 흐름을 나타낸다. 특히, 도 10은 도 7과 유사한 메시지 흐름을 도시한 것이나, CDNCF에 첨가된 DCN 기능성을 가지는 대신에, CDN은 분리된 노드에 위치한다.

도 10에서 프로세스는 사용자가 웹사이트 상에서 비디오에 대한 링크를 선택하는 것으로 시작할 수 있으며, 여기서 URL은 CDNCF에 호스트된 매니페스트 파일을 (예를 들어, 리다이랙션을 통해) 가리킬 수 있고(단계(1000)),및 클라이언트는 CDNCF로부터 매니페스트 파일을 얻기 위하여 HTTP GET 요청을 전송할 수 있다(단계(1001)). CDNCF는 클라이언트에게 매니페스트 파일을 전송함으로써 이 요청에 응답할 수 있다. 이 예에서, 로드-밸런싱 기능으로부터 얻어지는 정보에 기초하여, CDNCF는 제 1 전달 노드(DN1)에 저장된 세그먼트에 대한 참조를 포함하는 매니페스트 파일을 선택할 수 있다(단계 1002).

CDNCF는 DCN에게, 특히 DCN에서 DCMF에 특정 클라이언트(예를 들어, 그것의 IP주소에 의해 식별된)에게 특정(세트의) 전달 노드에 대한 참조를 포함하는 새로운 또는 업데이트된 매니페스트 파일이 제공되었음을 나타내는 통지를 보낼 수 있다(단계(1003)). DCMF는 클라이언트 정보(예를 들어, 클라이언트의 IP주소)와 DC 데이터베이스에서 미래에 사용(단계 1004)할 매니페스트 파일 정보(예를 들면, 비디오 타이틀의 적어도 일부와 연관된 매니페스트 파일 식별자, 또는 매니페스트 ID, 및 매니페스트 파일에 의하여 참조된 세그먼트를 호스팅하는 특정(세트의) 전달 노드의 위치정보)를 저장할 수 있다. 여기서, 매니페스트 파일 식별자는 번호에 의하여 식별될 수 있고, 전달노드는 CDN 내에서 알려진 전달 노드 식별자에 의해 식별될 수 있다.

클라이언트는 비디오를 구성하는 세그먼트의 위치(예를 들어, URL)를 얻기 위해 매니페스트 파일을 분석할 수 있다(단계 1005). 또한, 클라이언트는 DCN에 채널을 셋-업하기 위하여 매니페스트 파일에서 채널 셋-업 정보를 사용할 수 있다(단계 1006a). (채널을 설정하는 프로세스는 도 2 및 도 3에서 설명되어서 여기에서는 반복하지 않는다).

스트리밍 제어 채널의 설정 동안에, CCSF는 DC 데이터베이스에 저장된 정보를 이용하여 채널 셋-업 요청을 특정 클라이언트 및 연관된 (세트의)전달노드(들)들)과 서로 관련시킬 수 있다(단계 1006b). 특히, CCSF는 스트리밍 제어 채널이 설정되는 클라이언트에 대해 DC 데이터베이스에 문의할 수 있고(여기서 클라이언트는, 예를 들어, 그것의 IP주소로 식별할 수 있다), 클라이언트에 속하는 데이터베이스 엔트리에 고유 스트리밍 채널 식별자(예를 들어, 포트 번호 또는, WebSocket이 사용되는 경우에, WebSocket ID)를 할당할 수 있다. 이 방법으로, CDN의 기능, 예를 들어, CDNCF, DCMF 및 CCSF는 특정 전달 노드(들)에 특정 클라이언트 채널 조합을 관련시킬 수 있다.

일단 스트리밍 제어 채널이 설정되면, 스트리밍 클라이언트 기능은 제 1 전달 노드(DN1)로부터 얻어지는 세그먼트를 요청, 수신 및 재생하기 시작할 수 있다(단계(1007)). 스트리밍 프로세서 동안에, DCMF는 네트워크 통지 모니터링을 위한, 예를 들면, CDNCF로부터 네트워크 오버로드 또는 실패 통지, CDNCF 또는 네트워크 모니터링 기능과 연관된 로드-밸런스 기능을 모니터링 하기 위한 프로세스를 실행할 수 있다. 예를 들어, 어떤 시점에서, 모든 전달 노드의 로드를 모니터링하기 위한 로드 밸런싱 기능을 포함하거나 또는 그것과 연관된 CDNCF는 DN1 상의 로드가 미리- 설정된(최대) 임계값에 도달하는 것을 통지할 수 있다(단계 1008).

CDNCF는 그리고나서 DCMF에게 제 1 전달 노드(DN1)의 로드가 미리 설정된(최대의) 임계값에 접근하고 있음을 나타내는 오버로드 통지를 보낼 수 있다. 하나의 실시 예에서, 오버로드 통지는 리디렉션할 클라이언트의 수에 관한 정보를 포함할 수 있다(단계 1009). DCMF는 DC 데이터베이스의 매니페스트 파일 정보를 체킹함으로써 제 1 전달 노드(DN1)를 사용하는 클라이언트를 결정할 수 있다(단계 1010). DCMF는 리다이랙션할 클라이언트를 선택할 수 있으며 해당 클라이언트들의 스트리밍 제어 채널을 통해 매니페스트 업데이트 트리거를 보내기 위해 CCSF를 트리거할 수 있다(단계 1011). 매니페스트 업데이트 트리거의 수신은 단계(1001)에서 설명한 바와 유사한 방식으로 CDNCF에게 매니페스트 요청 파일을 보냄으로써 클라이언트에게 새로운 매니페스트 피일을 요청하라는 신호를 보낼 수 있다(단계 1012).

CDNCF는 매니페스트 요청을 수신할 수 있으며 클라이언트에게 적합한 새로운 매니페스트 파일을 생성하거나 선택할 수 있다(예를 들어, 로드-밸런싱 기능을 참조하여)(단계 1013). 이러한 경우에, 선택한 매니페스트 파일은, 예를 들어 제 2 전달 노드(DN2)에 저장된 세그먼트에 대한 링크를 포함할 수 있다. 그 다음 선택된 매니페스트 파일은 클라이언트에게 전송할 수 있다. 새로운 매니페스트 파일을 수신하는 즉시, 클라이언트는 제 1 전달 노드(DN1) 대신에 제 2 전달 노드(DN2)로부터 후속 세그먼트를 요청함으로써 스트리밍 프로세스를 계속할 수 있다.

클라이언트가 새로운 또는 업데이트된 매니페스트 파일을 수신하였기 때문에, 다른 전달 노드 (즉, 제 1 전달 노드(DN1) 대신에 제 2 전달 노드(DN2)) 상에 호스트된 세그먼트를 참조하여, CDNCF는 클라이언트와 연관된 DC 데이터베이스에서 엔트리 또는 엔트리들을 업데이트할 수 있다. 이렇게 하기 위하여, CDNCF는 클라이언트에게 새로운 또는 업데이트된 매니페스트 파일이 제공되었음을 DCN에서 DCMF에게 통지를 보낼 수 있다(단계 1003)을 참조하여 설명한 바와 유사한 방식으로). 통지를 수신한 후, DCMF는 DC 데이터베이스에 클라이언트 정보와 매니페스트 파일 정보를 저장할 수 있다(단계(1004)를 참조하여 설명한 바와 유사한 방식으로). 이 방법으로 CDNCF는 제 2 전달 노드(DN2)와 연관된 가능한 다른 로드(load) 문제를 처리할 수 있다.

따라서, 도 10에 도시된 실시 예에서, 스트리밍 제어 기능을 설정하고 관리하기 위한 기능은 분리된 네트워크 노드인, DCN, 에서 구현될 수 있으며, 그래서 CCN에서 CDNCF에 요구되는 변환은 매우 제한적이고, 기존의 CDNCF 구현은 재사용할 수 있으며, 그 때문에 CDN에 스트리밍 제어 채널 기능을 추가할 때 관련되는 비용을 제한한다. 또한, 클라이언트의 수와 연관된 활동 중인 스트리밍 제어 채널이 증가할 경우, 단지 DCN의 ,전체 CDNCF가 아니라, 용량만을 업그레이드할 필요가 있다. 따라서 이러한 실시 예는 CDN과 연관된 많은 수의 스트리밍 제어 채널을 관리하기 위한 확장 가능한(scalable) 해결책을 제공한다.

도 11은 본 발명의 또 다른 실시 예를 따른 콘텐츠 스트리밍 시스템에 사용할 메시지 흐름을 나타낸다. 특히, 도 11은 도 7과 유사한 메시지 흐름을 나타내지만, 그러나 하나의 전달 노드에 대한 참조만을 포함하는 각각의 매니페스트 파일을 갖는 대신에, 매니페스트 파일은 다수의 전달 노드에 대한 참조를 포함할 수 있다. 이 실시 예에서, CDNCF는 매니페스트 파일을 생성 및 호스트하도록 구성될 수 있다.

프로세스는 사용자가 웹 사이트에서 비디오에 대한 링크를 선택하는 것으로 시작할 수 있고, 여기서, URL은(예를 들어, 리디렉션을 통해) 매니페스트 파일을 가리키며(단계(1100)) 및 클라이언트는 CDNCF로부터 매니페스트 파일을 얻기 위하여 HTTP GET 요청을 전송한다(단계(1101)). 클라이언트로부터 매니페스트 요청을 수신하면, CDNCF는 새로운 매니페스트 파일을 생성하거나 다른 전달 노드(1102) 상의 세그먼트에 대한 참조를 포함하는 기존의 것을 선택할 수 있다. 하나의 실시 예에서, 예를 들어, 매니페스트 파일은 제 1 전달 노드(DN1)에 호스트된 저-품질의 세그먼트 및 제 2 전달 노드(DN2)에 호스트된 고품질 세그먼트에 대한 참조를 포함할 수 있다. CDNCF는 CDN에서 전달 노드와 연관된 로드 정보(로드-밸런싱 기능에 의해 생성된)를 사용할 수 있으며, 선택적으로 클라이언트에게 요구된 (일부의)세그먼트를 전달하도록 최적화된 전달 노드를 선택하기 위하여 클라이언트의 위치 정보(예를 들어, IP 주소)를 사용할 수 있다. 이 경우에, 매니페스트 파일은 적어도 제 1 전달 노드(DN1) 및 제 2 전달 노드(DN2)에 대한 참조를 포함할 수 있다.

CDNCF는 클라이언트에게 매니페스트 파일을 보낼 수 있고(단계(1103)), 이러한 경우에 DC 데이터베이스에서 제 1 및 제 2 전달 노드(D1 및 D2)에 클라이언트 정보(예를 들어, 그것의 IP 주소) 및 매니페스트 파일 정보(얘를 들어, 클라이언트의 IP 주소) 및 매니페스트 파일 정보(예를 들어, 매니페스트 파일 식별자, 또는 적어도 비디오 타이틀의 일부와 연관된, 매니페스트 ID, 및 매니페스트 파일에 의해 참조된 세그먼트를 호스트하는 특정 (세트의) 전달 노드(들)의 위치 정보)를 저장할 수 있다(단계(1104)). 여기서, 매니페스트 파일 식별자는 번호에 의해 식별될 수 있고 전달 노드는 CDN 내에서 알려진 전달 노드 식별자에 의해 식별될 수 있다.

클라이언트는 비디오를 구성하는 세그먼트의 위치를 얻기 위하여 매니페스트 파일을 분석할 수 있으며(단계(1105)), 클라이언트와 CCSF 사이에 스트리밍 제어 채널을 설정하기 위해 매니페스트 파일에서 채널 셋-업 정보를 사용할 수 있다(단계(1106a)). (채널을 설정하는 프로세스는 도 2 및 도 3에 기술되어 있으며, 여기서는 반복하지 않는다.)

스트리밍 제어 채널의 설정 동안에, CCSF는 채널 셋업 요청을 특정 클라이언트 및 DC 데이터베이스에 저장된 정보를 이용함으로써 연관된 (세트의) 전달노드(들)을 관련시킬 수 있다(단계 1106b).특히, CCSF는 스트리밍 제어 채널이 셋업되는 클라이언트에 대하여 DC 데이터베이스에 문의할 수 있고(여기서 상기 클라이언트는, 예를 들면, IP 주소로 식별할 수 있다), 상기 클라이언트에 속하는 데이터베이스 엔트리에 고유 스트리밍 채널 식별자(예를 들면, 포트 번호, WebSocket을 사용하는 경우, WebSocket ID)를 할당할 수 있다. 이러한 방법으로, CDN에서의 기능은 특정(세트의) 전달 노드(들)에 특정 클라이언트-채널 조합을 관련시킬 수 있다.

일단 스트리밍 제어 채널이 설정되면, 클라이언트는 제 1 및 제 2 전달 노드)로부터 비롯한 세그먼트를 요청, 수신 및 재생함으로써 스트리밍 프로세스를 시작할 수 있다(단계(1107)). 스트리밍 프로세스 동안에, 어떤 시점에서, CDN 내 전달 노드의 로드를 감시하기 위한 로드-밸런싱 기능을 포함하거나 또는 그것과 연관된 CDNCF는 제 1 전달 노드(DN1) 상의 로드가 미리- 설정된 (최대의) 임계값에 도달 또는 접근함을 통지할 수 있다(단계(1108)). CDNCF는 DCMF에게 DC 데이터베이스의 매니페스트 파일 정보를 체크함으로써 어느 클라이언트가 제 1 전달 노드(DN1)와 연관되는지 체크하도록 트리거(trigger)할 수 있다(단계(1109)). 그런 다음 DCMF는 어느 클라이언트가 매니페스트 업데이트를 요청하는지 결정하고 해당 클라이언트의 제어 채널을 통해 매니페스트 업데이트 트리거를 보내도록 CCSF를 트리거한다(단계 1110).

매니페스트 업데이트 트리거는 CDNCF에게 매니페이스트 요청을 보냄으로써(단계(1101 )참조) 새로운 또는 업데이트된 매니페스트 파일을 요청할 필요가 있다는 신호를 클라이언트에게 보낼 수 있다(단계 1111). CDNCF은 매니페스트 요청을 수신하거나 클라이언트에게 적절한 새로운 매니페스트 파일을 생성 또는 선택한다(단계(1012 )참조)(단계 1012). 이 경우, 새로운 또는 업데이트된 매니페스트 파일은, 예를 들어, 제 1 전달 노드(DN1)와 연관된 URLs를 동일한 세그먼트(예를 들면, 제 3 전달 노드 DN3)를 호스팅하는 다른 전달 노드(DN)와 연관된 URLs 로 대체할 수 있다. 전달 노드(DN2)와 연관된 URLs 는 단지 제 1 전달 노드(DN1)가 오버로드될 위험에 처해있기 때문에 대체되지는 않는다. CDNCF는 클라이언트에게 새로운 또는 업데이트된 매니페스트 파일을 보낼 수 있고(단계 1113), 클라이언트는 새로운 또는 업데이트된 매니페스트에 리스트된 세그먼트를 요청함으로써 그것의 (내부의) 세그먼트 리스트를 업데이트하고 스트리밍 프로세스를 계속할 수 있다.

클라이언트가 새로운 또는 업데이트된 매니페스트 파일을 수신했기 때문에, CDNCF는 단계(1104)를 참조하여 설명한 단계를 수행함으로써 DC 데이터베이스에서 해당 클라이언트와 연관된 매니페스트 파일 정보를 업데이트할 수 있다. 이 방법으로, 미래의 어느 시점에서 오버로드가 발생할 경우, CDNCF는 다른 전달 노드로 클라이언트를 다시 리디렉션할 수 있다.

따라서, 도 11에 도시된 실시 예는 하나의 매니페스트에 의해 참조된 세그먼트가 다중 전달 노드를 통해서 분산될 수 있는 이점을 제공하며, 여기서 각 전달 노드는 모든 세그먼트의 단지 서브세트(일부 조합)만을 호스트한다. 이것의 한 가지 장점은 CDN이 다른 유형의 세그먼트 사이에 차이를 구별하도록 허용한다. 세그먼트 콘텐츠의 특정 세그먼트들은 다른 세그먼트보다 더 인기(더 자주 요청됨)가 있다. 예를 들어, 시간적(temporal) 세그먼트 비디오 타이틀에서, 이전의(earlier) 세그먼트들이 일반적으로 나중의(later) 세그먼트들보다 더 자주 요청된다. 다른 예에서, 비디오 타이틀은 다른 비디오 품질과 관련된 세그먼트를 가질 수 있으며, 일부 품질은 다른 것보다 더 인기 있을 수 있다. 이러한 경우, CDN은 더 많은 전달 노드에서 덜 인기 있는 세그먼트보다 더 인기 있는 세그먼트를 호스트할 수 있고, 추가 확장성 및 높은 효율성을 제공할 수 있다.

도 12는 본 발명의 다른 실시 예에 따른 콘텐츠 스트리밍 시스템을 도시한 것이다. 특히, 도 12는 도 6을 참조하여 기술한 것과 유사한 CDN-기반 콘텐츠 전달 시스템을 도시한 것이다. 이 실시 예에서 그러나 시스템은 적어도 두 개의 상호 연결된 CDNs를 포함한다. 특히, 콘텐츠의 스트리밍 시스템은 적어도 제 2 CDN(1204))(또한 다운스트림 CDN으로 언급되는)에 CDN 상호 연결 인터페이스(1264)를 통하여 상호 연결된 제 1 CDN(1202)(또한 업스트림 CDN으로 언급되는)을 포함하며, 여기서 각 CDN은 CDN에서 하나 또는 그 이상의 전달 노드와 하나 또는 그 이상의 클라이언트 사이에 스트리밍 프로세서의 네트워크-시작 제어를 제공하도록 구성되어 있다. 네트워크-시작 제어는 도 2 내지 도 5를 참조하여 기술된 스트리밍 제어 채널 기능성을 바탕으로 실현할 수 있다.

콘텐츠 전달 시스템은 클라이언트(1203)를 호스트하는 하나 또는 그 이상의 터미널(1204)에 전송 네트워크(600)를 통해 연결된 콘텐츠 소스(1201)에 추가로 포함할 수 있다. 콘텐츠 소스는 콘텐츠 공급자 시스템(CPS), 콘텐츠 준비 시스템 또는 다른 CDN과 관련될 수 있다. CPS는 예를 들어, 비디오 재생(play-out) 기능(1251)으로 재생할 스트림을 처리하는 미디어 스트리밍 기능(1252)을 포함하는 콘텐츠를 구매하고 수신할 수 있는 클라이언트에게 콘텐츠를 예를 들어, 비디오 타이틀을 제공하도록 구성될 수 있다.

도 6에서와 유사하게, CDN은 전달 노드(1211,1212,1215)와 적어도 하나의 CCN(1210,1223)을 포함할 수 있다. 각각의 전달 노드는 콘트롤러(1230,1231,1234)와 콘텐츠를 저장하고 버퍼링하기 위한 캐시(cache, 1232,1233,1235)를 포함하거나 또는 그것과 연관될 수 있다. 각 CCN은 외부 소스, 예를 들어, 콘텐츠 공급자 또는 다른 CDN으로부터의 콘텐츠의 인제스쳔(=입수, ingestion)을 제어하기 위한 인제스쳔 노드, 콘텐츠가 CDN 내의 어디에 저장되는지에 관한 정보를 관리하기 위한 콘텐츠 위치 데이터베이스(1222,1225) 및 전달 노드에 콘텐츠의 하나 또는 그 이상의 카피(copies)의 분배를 제어하거나 클라이언트를 적절한 전달 노드로 리디렉팅(또한 요청 루팅으로 알려진 프로세스)하기 위한 CDN 및 CDN 제어 기능(CDNCF)(1221, 1224)을 포함하거나 또는 그것과 연관될 수 있다. 소비자는 콘텐츠, 예를 들어,도 6을 참조로 기술된 것과 유사한 방법으로 구매 가능한 콘텐츠 아이템을 식별하는 타이틀 참조(reference)를 제공하도록 구성되어 있는 웹 포털(WP)(1261)에 요청을 전송함으로써 CPS(1260)로부터, 비디오 타이틀을 구매할 수 있다.

CDNCF는 위치 데이터베이스(1222,1225)를 사용하여 세그먼트가 검색될 수 있는 위치를 관리할 수 있다. 또한, CDN은 클라이언트와 연관된 스트리밍 제어 채널을 셋-업 및 관리하고 이러한 클라이언트들과 연결된 전달 노드에서의 클라이언트 정보와 매니페스트 파일 정보를 포함하는 데이터베이스를 유지하도록 구성된 전달 연속성 노드(DCN)(1213,1216)를 포함할 수 있다. DCN은 독립형(stand-alone) DCN 또는 CDNCF에 통합되도록 구성할 수 있다.

DCN은 CDNCF의 요청-루팅(RR) 기능으로부터 비롯한 통지를 모니터링하기 위한 전달 연속성 관리 기능(DCMF)(1240,1243)을 포함할 수 있으며, 클라이언트로부터의 채널 셋-업 요구에 대해 모니터링하고 클라이언트에서 제어 채널 기능(1250)으로 스트리밍 제어 채널을 셋-업하기 위한 제어 채널 서버 기능(CCSF)(1241, 1244)을 포함할 수 있고; 및, 클라이언트 정보(예를 들어, 클라이언트의 IP 주소)와 매니페스트 파일 정보(즉, 세그먼트 식별자(예를 들어, 파일 명)) 및 이러한 세그먼트들을 호스팅하는 전달 노드의 적어도 일부와 연관된 위치 정보(예를 들어, URLs))를 저장하기 위한 DCN 내의 또는 연관된 전달 연속성성(DC) 데이터베이스(1245,1245)를 포함할 수 있다.

DCMF는 네트워크 통지, 예를 들면, CDNCF의 요청-루팅(RR) 기능, CDN에서 분리된 오버로드-기능 또는 네트워크 모니터링 기능에서 비롯한 오버로드(overload) 또는 실패 통지에 대해 모니터링할 수 있고, 그러한 통지의 수신에 응하여 매니페스트 파일 업데이트 프로세스를 시작할 수 있다. 매니페스트 파일 업데이트 프로세스의 상세 사항은 도 13을 참조하여 더 상세하게 후술될 것이다.

도 12의 콘텐츠 전달 시스템에서, 업스트림 CDN는 클라이언트에게 세그먼트 전달의 일부를 다운스트림 CDN에 아웃소스(outsource)할 수 있다. 예를 들어, 하나의 실시 예에서, 저-품질 세그먼트는 제 1 CDN A(예를 들어, 모바일 디바이스에 콘텐츠의 전달을 위해 구성된)에 의하여 배치되어 전달될 수 있고, 고품질 세그먼트는 제 2 CDN B(예를 들어, HDTV 기술을 지원하는 홈 미디어 장치에 고품질 세그먼트의 전달을 위해 구성된)에 의하여 배치되어 전달될 수 있다.

다운스트림 CDN에 세그먼트의 전달의 일부를 아웃소싱할 때, 업스트림 CDN(또는 특히 업스트림 CDN의 CDNCF)은 제 1 CDN A에서 하나 또는 그 이상의 전달 노드에 대한 참조(reference) 및 제 2 CDN B에서 하나 또는 그 이상의 전달 노드에 대한 참조를 포함하는 매니페스트 파일을 생성하기 위한 프로세스를 시작할 수 있다. 이러한 매니페스트 파일은 인터-CDN 매니페스트 파일로 언급될 수 있다. 인터-CDN 매니페스트 파일은 상기 클라이언트와 업스트림 CDN A 사이에 스트리밍 제어 채널을 셋업하기 위한 채널 셋업 정보를 더 포함할 수 있다. 인터-CDN 매니페스트 파일을 생성 프로세스 동안, 정보는 상호연결 인터페이스(1264)를 통해 CDN사이에 교환될 수 있다.

인터-CDN 매니페스트 파일을 생성하는 프로세스 동안, 정보는 상호연결 인터페이스(1264)를 통해 CDN 사이에 교환될 수 있다. 특히, 인터-CDN 매니페스트 파일의 생성 동안, 업스트림 CDN은 다운스트림 CDN에 아웃소싱된 하나 또는 그 이상의 세그먼트에 관한 위치 정보를 다운스트림 CDN에 요청할 수 있다. 응답으로, 다운스트림 CDN은 클라이언트에 관한 컨텍스츄얼 정보(contextual information)를 토대로 요청된 세그먼트를 호스팅하는 전달 노드를 선택할 수 있다. 예를 들어, 다운스트림 CDN은 클라이언트의 위치에서 지리적으로 가장 가까운 전달 노드를 선택할 수 있다. 이 정보는 이어서 인터-CDN 매니페스트 파일의 생성을 위해 업스트림 CDN의 CDNCF로 보내진다. 따라서, 도 13에서 콘텐츠 전달 시스템은 “개별화(personalized)된” 인터-CDN 매니페스트 파일을 다이나믹하게 생성하도록 구성된다.

일단 인터-CDN매니페스트 파일이 생성되고 클라이언트로 전달되면, 클라이언트의 제어 채널 기능은 인터-CDN 매니페스트 파일에서 채널 셋업 정보를 사용하여 업스트림 CDN의 DCN에서 CCSF와 함께 스트리밍 제어 채널을 설정할 수 있으며, 세그먼트를 요청 및 재생하기 시작한다.

스트리밍 프로세서 동안에, DCMF은 예컨대, CDNCF로부터 (오버)로드 통지 또는 실패 통지와 같은 네트워크 통지를 수신할 수 있으며, 클라이언트를 하나 또는 그 이상의 다른 전달 노드들로 리다이렉트해야 할 것을 결정한다. 네트워크 통지는 업스트림 CDN 또는 다운스트림 CDN에서의 네트워크 문제 상황과 관련될 수 있다. 후자의 경우, 다운 스트림 CDN의 CDNCF는 업스트림 CDN의 CDNCF에게 상호 연결 인터페이스(1264)를 통해 네트워크 통지를 보낼 수 있다.

도 13은 본 발명의 또 다른 실시 예에 따른 콘텐츠 스트리밍 시스템에 사용하기 위한 메시지 흐름을 나타낸다. 특히, 도 13은 도 12에 도시 된 바와 같이 콘텐츠 전달 네트워크에 사용하기 위한 메시지 흐름을 나타내며, 여기서 매니페스트 파일은 다른 CDN과 연관된 다른 전달 노드에 호스트된 세그먼트에 대한 참조를 포함할 수 있다.

프로세스는 사용자가 웹사이트에서 비디오에 대한 링크를 선택하는 것으로 시작할 수 있으며, 여기서 URL은 제 1 CDN A와 연관된 제 1 CDNCF에 호스트된 매니페스트 파일을 가리킨다)(예를 들면, 리디렉션을 통해)(단계(1300)). 이러한 CDN은 또한 업스트림 CDN으로 언급될 수 있다. 선택 즉시, 클라이언트는 CDN A의 CDNCF로부터 매니페스트 파일을 획득하기 위해 HTTP GET 요청을 보낼 수 있다(단계(1301)).

클라이언트로부터 매니페스트 요청을 수신한 후, 제 1 CDNCF는 새로운 매니페스트 파일을 생성하거나 기존의 매니페스트 파일을 업데이트하기 위한 프로세스를 시작할 수 있으며, 여기서, 매니페스트 파일은 다른 CDNs과 관련된 다른 전달 노드 상의 세그먼트에 대한 참조를 포함할 수 있다(단계(1302)). 예를 들어, 하나의 실시 예에서, 저-품질 세그먼트는 제 1 CDN A(모바일 디바이스에 콘텐츠의 전달을 위해 구성된)에 의해 배치되어 전달될 수 있다. 이 CDN은 업스트림 CDN으로 언급될 수 있다. 또한, 고품질의 세그먼트는 제 2 CDN B(HDTV 기술을 지원하는 홈 미디어 장치에서 고-품질 세그먼트의 전달을 위해 구성된)에 의해 배치되어 전달될 수 있다. 이 CDN은 다운스트림 CDN으로 언급될 수 있다. 적어도 제 1 CDN A와 연관된 제 1 전달 노드(DN1) 및 CDN B와 연관된 제 2 전달 노드(DN2)에 대한 참조를 포함하는 매니페스트 파일은 인터-CDN 매니페스트 파일로 언급될 수 있다. 인터-CDN 매니페스트 파일은 클라이언트와 업스트림 CDN A와 연관된 제 1 CDNCF 사이에 스트리밍 제어 채널을 셋업하기 위한 채널 셋-업 정보를 더 포함할 수 있다.

하나의 실시 예에서, 인터-CDN 매니페스트 파일은 업스트림 CDN A의 제 1 CDNCF는 다운스트림 CDN B의 제 2 CDNCF에게 CDN B에 의하여 클라이언트에 전달하여야 하는 미리-설정한 수의 세그먼트의 위치에 대한 참조를 제공하도록 요청하는 프로세서를 토대로 생성될 수 있다.

제 1 CDNCF는 그리고나서 인터-매니페스트 파일을 클라이언트(단계 1303)에게 보낼 수 있으며, 여기서 제 1 CDNCF는 클라이언트 정보(예를 들면, 그것의 IP 주소) 및 매니페스트 파일 식별자, 또는 비디오 타이틀의 적어도 일부와 연관된 매니페스트 ID를 포함하는 매니페스트 파일 정보, 및, 제 1 CDNCF 데이터베이스와 연관된 DC 데이터베이스에서, 제 1 CDN A 와 연관된(매니페스트 파일에 의해 참조되는) 세그먼트를 호스팅하는 특정 (세트의) 전달 노드(들) 및 제 2 CDN B와 연관된 (특정 세트의) 전달 노드의 위치 정보를 저장할 수 있다(단계 1304). 여기서, 세그먼트는 파일 명에 의하여 식별될 수 있고, 전달 노드는 전달 노드 식별자에 의하여 식별될 수 있다. 여기서, 매니페스트 파일 식별자는 번호에 의하여 식별될 수 있고 전달 노드는 CDN 내에 알려진 전달 노드 식별자에 의하여 식별될 수 있다.

따라서, 인터-CDN 매니페스트 파일의 생성 동안에, 제 1 및 제 2 CDNCF 사이에 통신이 이루어지며 그래서 - 제 2 CDNCF가 인터-CDN 매니페스트 파일의 모든 세그먼트를 다 인식하지는 못할지라도 - 제 2 CDNCF는 클라이언트가 (가까운) 미래에 (특정 세트의) 전달 노드에 위치한 미리-정해진 수의 세그먼트를 요청할 수 있음을 인식하고 있다. 그러므로, 제 2 CDNCF는 제 2 CDN B와 연관된 DC 데이터베이스에서 업스트림 CDN (이 경우는 제 1 CDNCF)에 대한 참조와 함께 다운스트림 CDN(이 예에서는 제 2 전달노드(DN2))에서 전달 노드를 포함하는 인터-CDN 정보를 저장할 수 있고, 그래서 이러한 전달 노드중 하나로 제 1 CDNCF에 임의의 네트워크 문제, 예를 들면, 로드 또는 실패 문제를 통지할 수 있다(단계 1305).

클라이언트는 비디오(단계 1306)를 구성하는 세그먼트의 위치를 얻기 위하여 인터-CDN 매니페스트 파일을 분석(parse)할 수 있으며, 제 1 CDNCF와 클라이언트 사이에 스트리밍 제어 채널을 셋업하기 위하여 매니페스트 파일에서 채널 셋-업 정보를 사용할 수 있다(단계 1307). (채널을 셋업하는 과정은 도 2 및 도 3에서 도시되었고, 여기에서는 반복하지 않는다).

스트리밍 제어 채널의 설정 동안에, 제 CDN 1과 연관된 CCSF는 제 1 DC 데이터베이스에 저장된 정보를 이용하여, 채널 셋업 요청을 특정 클라이언트 및 연관된 (세트의) 전달 노드와 관련시킬 수 있다(단계 1309). 특히, CCSF는 스트리밍 제어 채널이 설정될 클라이언트에 대한 데이터베이스를 문의할 수 있고(여기서 클라이언트는 IP 주소로 식별할 수 있음), 클라이언트에 속하는 데이터베이스에 고유한 스트리밍 제어 식별자(예를 들어, 포트 번호, 또는, WebSocket이 사용되는 경우, WebSocket ID)를 할당할 수 있다. 이 방법으로, 제 1 CDN1에서의 기능은 특정 클라이언트-채널 조합을 특정(세트의) 전달 노드에 연관시킬 수 있다. 스트리밍 제어 채널을 설정한 후에, 클라이언트는 제 1(업스트림) CDN A와 연관된 제 1 전달 노드(DN 1) 및 제 2(다운 스트림) CDN B와 연관된 제 2 전달 노드(DN 2) 모두로부터 얻은 세그먼트를 요청, 수신 및 재생함으로써 스트리밍 프로세스를 시작할 수 있다(단계(1308)).

스트리밍 프로세스 동안, 어떤 시점에서, 자신의 전달 노드를 모니터링하는 제 2 CDNCF는 네트워크 문제, 예를 들어, 제2 전달 노드(DN2)에서의 네트워크 실패를 통지할 수 있고, 또 제 2 전달 노드(DN2) 상의 로드가 미리-설정된(최대의) 임계 값에 도달 또는 접근함을 통지할 수 있다. DC 데이터베이스에서 인터-CDN 정보를 토대로, 제 2 CDNCF는 제 1 CDNCF에 네트워크 통지, 예를 들어, (오버)로드 통지 또는 실패 통지를 전송함으로써 제 1CDNCF에 네트워크 문제를 통지할 수 있다. 오버로드 통지는 제 2CDN의 전달 노드에 대한 참조의 적어도 일부는, 특히, 인터-CDN 매니페스트 파일에 리스트된 전달 노드에 대한 참조는 업데이트 할 필요가 있다는 신호를 제 1 CDNCF에 보낼 수 있다(단계 1310).

따라서, 제 2 CDNCF로부터 네트워크 통지를 수신하는 즉시, 제 1 CDNCF는 DCMF에게 클라이언트들에게 제 1 CDN A와 연관된 DC 데이터베이스에 저장된 매니페스트 파일 정보를 토대로 제 2 전달 노드(DN2)에 대한 참조를 포함하는 인터-CDN 매니페스트 파일이 전송되었는지 체크하도록 트리거한다(단계 1311). DCMF는 그리고나서 어느 클라이언트를 리디렉터할지 결정하고(단계 1312), 클라이언트의 제어 채널을 통해서 매니페스트 업데이트 트리거를 보내기 위하여 CCSF를 트리거하기 위한 결정을 할 수 있다. 매니페스트 업데이트 트리거를 수신하는 즉시, 클라이언트는 제 1 CDNCF에 매니페스트 파일 요청을 보냄으로써 (단계(1301)과 유사)) 새로운 매니페스트 파일을 요청할 것이다(단계 1313).

제 1 CDNCF는 단계(1302)를 참조하여 앞서 기술한 바와 같은 유사한 방식으로 제 2 CDNCF와 협력하여 클라이언트에게 적합한 새로운 또는 업데이트된 매니페스트 파일을 생성할 것이다(단계 1314). 예를 들어, 하나의 실시 예에서, 제 2 CDNCF는 제 2 CDN(이 경우 제 2 전달 노드)에서 (거의) 오버로드된 전달 노드를 참조하는 URLs를 다른 전달 노드, 예를 들면, 같은 세그먼트를 호스팅하는 제 4 전달 노드(DN4)를 참조하는 URLs로 대체할 수 있으며, 제 1 CDNCF에 이러한 참조를 보낼 수 있다. 제 1 CDN A에서 전달 노드(DN 1)를 참조하는 URLs는 그 전달 로드에 대하여 어떠한 오버로드 신호도 제 1 CDNCF에 의하여 수신되지 않았기 때문에 대체되지 않는다.

제 1 CDNCF는 클라이언트에게 업데이트된 인터-CDN 매니페스트 파일을 보낼 수 있고(단계 1315), 클라이언트는 업데이트된 매니페스트 파일에 기초하여 세그먼트의 내부 리스트를 업데이트할 수 있고, 새로운 매니페스트에 리스트된 URLs에서 후속 세그먼트를 요청하여 스트리밍을 계속할 수 있다.

클라이언트가 새로운 또는 업데이트된 매니페스트 파일을 수신하였기 때문에, 제 1 CDNCF는 단계(1304)를 참조하여 설명한 단계를 수행함으로써 DC 데이터베이스에서 해당 클라이언트와 연관된 매니페스트 파일 정보를 업데이트할 수 있다. 또한 제 2CDNCF는 단계(1305)를 참조하여 설명한 바와 유사하게 제 2CDN B와 연관된 DC 데이터베이스에서 업스트림 CDN(이 경우 제 1CDNCF)을 참고하여 다운스트림 CDN(이 예에서 제 4 전달 노드(DN4))에서 전달 노드를 포함하는 인터-CDN 정보를 업데이트할 수 있다. 이 방법으로, 미래의 어떤 시점에서 CDN B에서 오버로드 문제가 발생하는 경우, 제 2 CDNCF는 클라이언트를 다른 전달 노드에 다시 리디렉션할 수 있다.

따라서, 도 13에 도시된 실시 예는 세그먼트 콘텐츠가 다중의 CDNs를 통해 분배되도록 허용하는 이점을 제공하며, 여기서 각 CDN은 오로지 모든 세그먼트의 서브세트만을 호스트한다. 이러한 실시 예는 도 11을 참조로 논의한 바와 동일한 형태의 이점을 제공하나, 그러나, 이 경우에 다른 전달 노드는 다중의 CDNs를 통해 분배될 수 있다. 이것의 다른 이점은 업스트림 CDN이 다른 다운스트림 CDN에 일부 작업부하(workload)를 아웃소스하도록 하용하는 것이다. 또한 이러한 실시 예는 특화된 CDNs의 사용을 허용한다. 예를 들면, 하나의 실시 예에서 제 1 CDN은 주로 낮은 품질의 세그먼트를 호스팅하는 모바일 장치에 전달을 위해 구성되고 최적화될 수 있는 반면에, 제 2 CDN은 주로 높은 품질 세그먼트를 호스팅하는 HD 재생 장치에 전달을 위해 구성되고 최적화될 수 있다.

앞서 기술된 CDN의 실시 예에서, 새로운 또는 업데이트된 매니페스트 파일을 요청함에 의하여응답하는 클라이언트에게 업데이트 매니페스트 트리거를 보내는 대신에, 새로운 또는 업데이트된 매니페스트 파일(의 일부)을 스트리밍 제어 채널을 통하여 클라이언트에게 직접 보낼 수 있다는 의견을 제출한다.

도 14는 본 발명의 하나의 실시 예에 따른 매니페스트 파일을 도시한 것이다. 특히, 도 14는 특정 세트의 세그먼트를 전달하도록 구성된 전달 노드에 대한 참조, 예를 들어, URLs를 포함하는 매니페스트 파일의 실시 예를 나타낸다. 이러한 특별한 예에서, 매니페스트 파일은, 예를 들어, 전달 노드에 저장된 동일한 콘텐츠와 관련된 낮은 및 높은-비트속도의 세그먼트에 대한 두 개의 다른 세트의 참조를 포함할 수 있다. 매니페스트 파일은 추가로 채널 셋-업 정보를 포함할 수 있다. 하나의 실시 예에서, 채널 셋-업 정보는 스트리밍 제어 기능(또는 CDN 경우에 제어 채널 서버 기능)을 포함하는 네트워크 노드에 대한 참조를 제공하는 채널 타겟 파라메터(1400)를 포함할 수 있다. 또한, 다른 실시 예에서, 채널 셋-업 정보는 채널 파라메터(1402), 즉, 스트리밍 제어 기능/제어 채널 서버 기능이 사용하는 파라메터를 포함할 수 있다. 예를 들어, WebSocket의 경우에, 파라메터는 WebSocket 서브-프로토콜, WebSocket 버전 등의 사용과 관계있다.

임의의 어느 하나의 실시 예와 관련하여 기술한 임의의 특징은 단독으로 또는 기술한 다른 특징과의 조합으로 사용될 수 있고, 임의의 다른 실시 예의 하나 또는 그 이상의 특징들의 임의의 조합으로 역시 사용될 수 있는 것으로 이해되어야 한다. 본 발명의 하나의 실시 예는 컴퓨터 시스템과 함께 사용하기 위한 프로그램 상품으로 구현될 수 있다. 프로그램 상품 중의 프로그램(들)은 실시 예(여기에 기술된 방법을 포함하여)의 기능을 정의하고, 다양한 컴퓨터 판독 가능한 저장 매체에 내장할 수 있다. 도시된 컴퓨터 판독 가능한 저장 매체는 다음을 포함하나,그러나 그것에 제한되지는 않는다: (i) 정보가 영구히 저장되는 쓰기-불가능한 저장 매체(예를 들어, (즉, CD-ROM 드라이버에 의하여 읽을 수 있는 CD-ROM 디스크, 플래시 메모리, ROM 칩 또는 고체-상태 비- 휘발성 반도체 메모리 같은 컴퓨터 내의 읽기 전용(read-only )메모리 장치) ; 및 (ii)변경할 수 있는 정보가 저장되는 쓰기-가능한(writable) 매체(예를 들어, 디스켓 드라이브 내의 플러피 디스크 또는 하드-디스크 드라이브 또는 고체-상태의 랜덤-액세스 반도체 메모리). 본 발명은 앞서 설명한 실시 예에 제한되지 않으며, 첨부한 청구항의 범위 내에서 변형이 있을 수 있다.

Claims

전달 노드로부터 적어도 하나의 클라이언트에게 세그먼트 콘텐츠 스트림의 네트워크-시작 제어를 가능하게 하는 방법에 있어서, 상기 방법은
적어도 하나의 클라이언트에게 하나 또는 그 이상의 식별자 및 상기 하나 또는 그 이상의 식별자와 연관된 하나 또는 그 이상의 세그먼트를 전송하도록 구성된 하나 또는 그 이상의 콘텐츠 전달 노드 위치를 찾기 위한 위치정보를 포함하는 제 1 매니페스트 파일을 수신하는 단계;
클라이언트에게 채널 셋-업 정보를 제공하는 단계; 및
바람직하게는 클라이언트에서 상기 제 1 매니페스트 파일의 수신에 의하여, 상기 적어도 하나의 클라이언트와 상기 공급된 채널 셋-업 정보를 토대로 상기 전달 노드와 연관된 제어 채널 서버 기능 사이에 적어도 하나의 스트리밍 제어 채널을 설정하는 단계를 포함하며, 상기 적어도 하나의 클라이언트는 스트리밍 제어 채널을 통하여 적어도 하나의 매니페스트 파일 업데이트 메시지를 수신하도록 구성됨을 특징으로 하는 방법.
청구항 1에 있어서,
적어도 하나의 매니페스트 파일 업데이트 메시지에 대한 상기 스트리밍 제어 채널을 모니터링하는 단계를 포함하는 방법.
청구항 1 또는 청구항 2 에 있어서,
매니페스트 파일 업데이트 메시지를 검출하는 단계;
상기 매니페스트 파일 업데이트 메시지의 검출에 대응하여 제 2 매니페스트 파일의 적어도 일부를 수신하는 단계; 및 선택적으로,
상기 제 2 매니페스트 파일을 토대로 세그먼트 스트림 또는 파일을 요청하는 단계를 포함하는 방법.
청구항 1 내지 청구항 3 중 어느 한 항에 있어서,
상기 채널 셋-업 정보의 적어도 일부는 상기 제 1 매니페스트 파일로 상기 클라이언트에게 제공되며, 바람직하게는, 상기 채널 셋-업 정보는, 네트워크에서 상기 제어 채널 서버 기능을 찾기 위한, 서버 위치 정보, 바람직하게는 적어도 하나의 URL을 포함하는 방법.
청구항 1 내지 청구항 4 중 어느 한 항에 있어서,
상기 매니페스트 파일 업데이트 메시지는 제 2 매니페스트 파일의 적어도 일부를 포함하거나 또는 상기 매니페스트 파일 업데이트 메시지는, 상기 제 2 매니페스트 파일의 적어도 일부에서 위치를 찾거나 요청하기 위한, 매니페스트 파일 정보, 바람직하게는 적어도 하나의 URL을 포함하는 방법.
청구항 1 내지 청구항 5 중 어느 한 항에 있어서,
상기 세그먼트 콘텐츠는 스트리밍 프로토콜, 바람직하게는 HTTP-기반의 스트리밍 프로토콜 또는 그의 유도체(derivative)를 토대로 상기 적어도 하나의 클라이언트에게 전달되며; 및/또는, 여기서 스트리밍 제어 채널은 WebSocket 프로토콜, SIP 프로토콜, XMPP 프로토콜 및/또는 그들의 조합을 토대로 설정하는 방법.
전달 노드로부터 적어도 하나의 클라이언트에게 세그먼트 콘텐츠 스트림의 네트워크-시작 제어를 가능하게 하는 방법에 있어서, 상기 방법은
하나 또는 그 이상의 세그먼트 식별자 및 상기 하나 또는 그 이상의 식별자와 연관된 하나 또는 그 이상의 정보를 상기 적어도 하나의 클라이언트에게 전송하도록 구성된 하나 또는 그 이상의 콘텐츠 전달 노드를 찾기 위한 위치 정보를 포함하는 매니페스트 파일을 적어도 하나의 클라이언트에게 전달하는 단계;
상기 하나 또는 그 이상의 콘텐츠 전달 노드와 연관된 제어 채널 서버 기능과 상기 적어도 하나의 클라이언트 사이에 제어 채널을 셋-업하기 위한 요청을 수신하는 단계; 및
상기 적어도 하나의 스트리밍 제어 채널을 설정하는 단계를 포함하되, 여기서 상기 제어 채널 서버 기능은 상기 클라이언트에게 적어도 하나의 매니페스트 파일 업데이트 메시지를 전송하도록 구성된 방법.
청구항 7에 있어서,
상기 하나 또는 그 이상의 전달 노드의 적어도 제 1 부분은 상기 클라이언트에게 상기 세그먼트의 적어도 제 1 부분을 전달하도록 구성된 제 1 콘텐츠 전달 네트워크(CDN1)와 연관된 제 1 전달 노드로서 구성되며; 및/또는,
상기 전달 노드의 적어도 제 2 부분은 상기 클라이언트에게 상기 세그먼트의 적어도 제 2 부분을 전달하도록 구성된 제 2 콘텐츠 전달 네트워크(CDN2)와 연관된 제 2 전달 노드로 구성된 방법.
청구항 7 또는 청구항 8에 있어서,
하나 또는 그 이상의 네트워크 파라메터를, 바람직하게는 오버로드, 임박한 오버로드, 실패, 또는 상기 하나 또는 그 이상의 전달 노드와 연관된 네트워크 구성 변화와 연관된 상기 하나 또는 그 이상의 네트워크 파라메터 중 적어도 하나를 모니터링하는 단계;
상기 네트워크 파라메터와 연관된 하나 또는 그 이상의 미리 설정된 조건을 충족하면, 매니페스트 파일 업데이트 메시지를 발생하는 단계; 및,
상기 적어도 하나의 클라이언트에게 상기 매니페스트 파일 업데이트 메시지를 전송하는 단계를 포함하는 방법.
청구항 8 또는 청구항 9에 있어서,
오버로드, 임박한 오버로드, 실패, 또는 하나 또는 그 이상의 상기 제 1 및/또는 제 2 전달 노드와 연관된 네트워크 구성 변화를 결정하는 단계;
상기 결정된 오버로드, 임박한 오버로드, 실패, 또는 네트워크 구성 변화와 연관된 상기 하나 또는 그 이상의 제 1 및/또는 제 2 전달 노드로부터 적어도 하나의 세그먼트를 검색하거나 또는 검색할 것을 예상하는 하나 또는 그 이상의 클라이언트를 식별하는 단계;
상기 식별된 클라이언트 중 적어도 일부와 연관된 하나 또는 그 이상의 스트리밍 제어 채널을 결정하는 단계; 및
상기 식별된 클라이언트의 적어도 일부에게 상기 하나 또는 그 이상의 스트리밍 제어 채널을 통해 매니페스트 파일 업데이트 메시지를 전송하는 단계를 포함하는 방법.
청구항 10에 있어서,
상기 오버로드, 임박한 오버로드, 실패, 또는 네트워크 구성 변화 중 적어도 일부는 제 2 CDN2에 속하는 상기 제 2 전달 노드 중 적어도 하나와 연관되고, 상기 방법은;
제 2 CDN2는 오버로드, 실패 또는 네트워크 구성 변화 통지를 상기 제 1 CDN1에게 전송하고, 상기 통지는 ,상기 오버로드, 실패 또는 네트워크 구성 변화와 연관된 하나 또는 그 이상의 제 2 전달 노드 식별자를 포함하는 방법.
적어도 하나의 전달 노드로부터 전송된 세그먼트 콘텐츠의 수신을 제어하기 위한 콘텐츠 프로세싱 장치에 사용할 클라이언트에 있어서, 상기 제 1 전달 노드는 제 1 제어 채널 서버 기능과 연관되고, 상기 클라이언트는;
상기 적어도 하나의 전달 노드에 세그먼트 콘텐츠를 전달하기 위한 요청을 전송하는 단계;
하나 또는 그 이상의 세그먼트 식별자 및 상기 적어도 하나의 클라이언트에게 상기 세그먼트 식별자와 연관된 하나 또는 그 이상의 세그먼트를 전송하도록 구성된 하나 또는 그 이상의 콘텐츠 전달 노드 위치를 찾기 위한 위치 정보를 포함하는 매니페스트 파일을 수신하는 단계;
채널 셋-업 정보를 제공하는 단계; 및,
상기 적어도 하나의 클라이언트와 상기 제 1 제어 채널 서버 기능 사이에 상기 채널 셋-업 정보를 토대로 스트리밍 제어 채널을 설정하는 단계로 구성되며, 상기 적어도 하나의 클라이언트는 상기 제 1 제어 채널 서버 기능으로부터 적어도 하나의 매니페스트 파일 업데이트 메시지를 수신하도록 구성됨을 특징으로 하는 클라이언트.
상기 전달 노드로부터 하나 또는 그 이상의 클라이언트에게 세그먼트 콘텐츠 스트리밍의 네트워크-시작 제어를 가능하게 하는 적어도 하나의 전달 노드와 연관된 제어 채널 서버 기능에 있어서, 상기 제어 채널 서버 기능은:
상기 하나 또는 그 이상의 클라이언트에게 세그먼트 콘텐츠를 전달하기 위한 적어도 하나의 요청을 수신하는 단계;
하나 또는 그 이상의 세그먼트 식별자와 상기 세그먼트 식별자에게 상기 세그먼트 식별자와 연관된 하나 또는 그 이상의 세그먼트를 전송하도록 구성된 하나 또는 그 이상의 콘텐츠 전달 노드 위치를 찾기 위한 위치 정보 및 채널 셋-업 정보를 포함하는 적어도 하나의 매니페스트 파일을 생성하는 단계;
상기 하나 또는 그 이상의 클라이언트 중 적어도 하나에 상기 제 1 매니페스트 파일을 전송하는 단계; 및
상기 적어도 하나의 클라이언트와 상기 제어 채널 서버 기능 사이에 적어도 제 1 스트리밍 제어 채널의 셋-업에 참여하는 단계로 구성되며, 상기 셋-업은 상기 채널 셋업 정보를 토대로 하며; 및, 선택적으로, 상기 제어 채널 서버 기능은 매니페스트 파일 업데이트 메시지 생성 및/또는 상기 클라이언트에게 상기 제 1 스트리밍 제어 채널을 통해 상기 메시지를 전송하도록 추가로 구성된 제어 채널 서버 기능.
청구항 13에 있어서,
적어도 하나의 매니페스트 파일을 생성하는 단계는:
제 1 콘텐츠 전달 네트워크(CDN1)에서 하나 또는 그 이상의 콘텐츠 전달 노드 위치를 찾기 위한 하나 또는 그 이상의 제 1 세그먼트 식별자 및 제 1 위치 정보를 제공하는 단계;
상기 제 2 콘텐츠 전달 네트워크(CDN1)에서 하나 또는 그 이상의 콘텐츠 전달 노드 위치를 찾기 위한 하나 또는 그 이상의 제 2 세그먼트 식별자 및 제 2 위치 정보를 제 2 콘텐츠 전달 네트워크에게 요청하는 단계;
상기 하나 또는 그 이상의 제 1 및 제 2 세그먼트 식별자 중 적어도 일부와 제 1 및 제 2 위치 정보 각각을 토대로 상기 매니페스트 파일을 생성하는 단계를 포함함을 특징으로 하는 제어 채널 서버 기능.
바람직하게는 매니페스트 파일의 적어도 일부이며, 세그먼트 콘텐츠 스트림의 네트워크-시작 제어를 가능하게 하는 데이터 구조에 있어서, 상기 데이터 구조는 하나 또는 그 이상의 세그먼트 식별자 및 상기 클라이언트에게 상기 하나 또는 그 이상의 세그먼트 식별자와 연관된 하나 또는 그 이상의 세그먼트들을 전송하도록 구성된 하나 또는 그 이상의 콘텐츠 전달 노드 위치를 찾기 위한 위치 정보를 포함하고; 상기 데이터 구조는 상기 채널 셋업 정보의 적어도 일부를 더 포함하고, 바람직하게는 상기 채널 셋-업 정보는 상기 클라이언트와 함께 스트리밍 제어 채널 셋업 프로세서를 시작하도록 구성된 제어 채널 서버 기능을 포함하는 네트워크 노드와 연관된 위치 정보, 바람직하게는 하나 또는 그 이상의 URLs를 포함함을 특징으로 하는 데이터 구조.
컴퓨터 메모리에서 실행할 때, 청구항 1 내지 11 중 어느 한 항에 따른 방법 단계를 실행하도록 구성된 소프트웨어 코드 부분을 포함하는 컴퓨터 프로그램 기록매체(product).