KR20210119957A - 오디오-비주얼 라이브 콘텐츠 전달을 위한 방법 및 시스템 - Google Patents

오디오-비주얼 라이브 콘텐츠 전달을 위한 방법 및 시스템 Download PDF

Info

Publication number
KR20210119957A
KR20210119957A KR1020217019969A KR20217019969A KR20210119957A KR 20210119957 A KR20210119957 A KR 20210119957A KR 1020217019969 A KR1020217019969 A KR 1020217019969A KR 20217019969 A KR20217019969 A KR 20217019969A KR 20210119957 A KR20210119957 A KR 20210119957A
Authority
KR
South Korea
Prior art keywords
multicaster
live content
client
controller
visual live
Prior art date
Application number
KR1020217019969A
Other languages
English (en)
Other versions
KR102506107B1 (ko
Inventor
소피 베일
레미 브리비온
니콜라스 르나르
장-프랑수아 마르틴
피에르-올리비에 부토
Original Assignee
브로드피크
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 브로드피크 filed Critical 브로드피크
Publication of KR20210119957A publication Critical patent/KR20210119957A/ko
Application granted granted Critical
Publication of KR102506107B1 publication Critical patent/KR102506107B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2187—Live feed
    • H04L65/4084—
    • 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/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • 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
    • H04L65/4076—
    • H04L65/605—
    • 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/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • 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/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/239—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
    • H04N21/2393—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/43615—Interfacing a Home Network, e.g. for connecting the client to a plurality of peripherals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6405—Multicasting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6408—Unicasting

Abstract

오디오-비주얼 라이브 콘텐츠 전달 시스템은, 게이트웨이(140)를 통해 제공자 네트워크(102)로의 액세스를 갖는 클라이언트(110); 제공자 네트워크(102)를 통해 멀티캐스트 형식으로 오디오-비주얼 라이브 콘텐츠를 송신하기 위한 멀티캐스터를 포함하는 오디오-비주얼 라이브 콘텐츠 전달 장비(120); 멀티캐스터로부터 멀티캐스트 형식으로 수신된 오디오-비주얼 라이브 콘텐츠의 유니캐스트 형식으로의 변환을 수행할 수 있는 디-멀티캐스터(150); 및 오디오-비주얼 라이브 콘텐츠를 얻기 위한 요청들의 라우팅을 관리하는 컨트롤러(130)를 포함한다. 클라이언트(110)는 디-멀티캐스터(150)의 잠재적 존재 및 이용 가능성에 관한 정보의 수신을 목적으로 하는 발견 절차를 수행한다. 클라이언트(110)가 타깃 오디오-비주얼 라이브 콘텐츠를 수신하고자 할 때, 클라이언트(110)는 디-멀티캐스터(150)의 존재 및 이용 가능성의 표시, 또는 그 역의 표시를 제공하는 요청을 컨트롤러(130)에 전송한다. 그후, 컨트롤러(130)는, 적어도 디-멀티캐스터(150)의 존재 및 이용 가능성의 표시, 또는 그 역의 표시에 따라, 요청을 충족시키기 위해 클라이언트(110)를 리디렉팅하는 방법을 결정한다.

Description

오디오-비주얼 라이브 콘텐츠 전달을 위한 방법 및 시스템
본 발명은 일반적으로 클라이언트 디바이스에 오디오-비주얼 라이브 콘텐츠(audio-visual live content)를 전달하는 방법에 관한 것으로, 게이트웨이 디바이스는 제공자 네트워크에 로컬 영역 네트워크를 상호접속하고, 클라이언트 디바이스는 로컬 영역 네트워크에 연결되며, 오디오-비주얼 라이브 콘텐츠를 제공하도록 적응된 장비는 제공자 네트워크에 연결되어 있다.
과거에, 대부분의 비디오 라이브 스트리밍 기술은 RTP(표준 문헌 RFC 3550에 정의된 것과 같은 "실시간 전송 프로토콜") 또는 RTSP(표준 문헌 RFC 2326에 정의된 것과 같은 "실시간 스트리밍 프로토콜")와 같은 스트리밍 프로토콜에 의존했다. 오늘날의 라이브 스트리밍 기술은 거의 독점적으로 HTTP(표준 문헌 RFC 2616에 정의된 것과 같은 "하이퍼텍스트 전송 프로토콜") 프로토콜에 기반하고, 인터넷과 같은 대규모 분산 HTTP 네트워크를 통해 효율적으로 작동하도록 설계된다.
적응형 비트레이트 스트리밍(Adaptive Bitrate Streaming: ABS)은, 컴퓨터 네트워크를 통해 콘텐츠를 스트리밍하는 데 사용되는 대중적인 HTTP 스트리밍 기술 중 하나이며, HTTP에 기반하고 애플사(Apple Inc.)에 의해 개발된 라이브 스트리밍 통신 프로토콜인 HLS("HTTP 라이브 스트리밍")이 특정 일 구현예이다. HLS는 전체 AV("오디오-비주얼") 스트림을 일련의 작은 HTTP-기반 파일 다운로드들로 분할함으로써 이루어지며, 이 일련의 작은 HTTP-기반 파일 다운로드들 각각은 잠재적으로 제한되지 않은 전체 전송 스트림의 하나의 청크(chunk)를 포함한다. AV 콘텐츠는 다양한 분해능으로 이용 가능하고 청크들로 분할되며, 여기서 청크는, 실제 분해능이 어떤 것이든, AV 콘텐츠의 일부이며 이는 AV 콘텐츠의 시간 세그먼트에 대응한다. AV 스트림이 재생됨에 따라, AV 콘텐츠를 디코딩하는 클라이언트 디바이스는 다양한 개별 분해능(다양한 개별 비트 레이트)으로 인코딩된 동일한 자료를 포함하는 상이한 대안적인 버전(또한, 레이어 또는 표현으로 지칭됨) 중에서 선택할 수 있으며, 이는 스트리밍 세션이 네트워크의 이용 가능한 송신 리소스 및/또는 클라이언트 디바이스의 이용 가능한 프로세싱 리소스에 적응할 수 있게 한다. 스트리밍 세션의 시작 시에, 클라이언트 디바이스는 통상적으로 파일 확장자가 "M3U" 또는 "m3u8"인 텍스트 파일 형식의 재생목록을 다운로드한다. 이러한 텍스트 파일은 관련 AV 콘텐츠에 이용 가능한 다양한 대안적인 버전에 대한 메타데이터를 포함한다.
유사한 ABS 접근방식이 마이크로소프트 사(Microsoft Corp)가 제공하는 통합 HTTP-기반 매체 전달 플랫폼인 인터넷 정보 서비스(Internet Information Services: IIS) 미디어 서비스의 특징인 스무스 스트리밍(Smooth Streaming)으로 구현된다. AV 스트림이 재생목록 파일로 보완된 청크들을 포함하는 복수 파일들로 잘리는 HLS와는 대조적으로, 스무스 스트리밍은 조각들로 잘린 단일 AV 파일에 의존하며, 여기서 파일의 각각의 조각은 AV 콘텐츠의 관련 레이어 및 참조 시간을 나타내는 디스크립터(descriptor)를 포함하고 있다. 그러나, 프로토콜 기반 및 이점은 동일하다.
HDS, HLS 및 스무스 스트리밍과 관련된 MPEG DASH로 지칭되고 동영상 전문가 그룹(Moving Picture Experts Group)이 개발한 멀티미디어 스트리밍 기술인, 어도비 시스템(Adobe Systems)의 HTTP 동적 스트리밍(HTTP Dynamic Streaming: HDS) 및 HTTP를 통한 동적 적응 스트리밍을 유사하게 고려할 수 있다. 그후, "mpd" 파일 확장자를 가진 파일이 사용된다.
HTTP가 방화벽을 통과할 수 있게 하고 TCP(표준 문헌 793에 의해 정의된 것과 같은 "송신 제어 프로토콜")에 의존함으로써 데이터 무결성을 보장하기 때문에, HTTP-기반 스트리밍 기술은 매우 편리하다. 그러나, ABS의 맥락에서 HTTP의 유니캐스트 특성은 CDN("Content Delivery Network") 운영자들에게 막대한 확장성 문제를 야기하여 라이브 스트리밍을 위해 ABS-기반 메커니즘을 채택하지 못하게 한다. 사실상, HTTP-기반 스트리밍 기술은 유니캐스트 송신에 의존하며, 이에 따라 백-엔드 인프라스트럭처의 관점에서 지속불가능할 수 있는데, 이는 수많은 사용자들이 AV 라이브 콘텐츠 시청을 동시에 요청할 수 있기 때문이다.
라이브 AV 콘텐츠 전달을 위한 HTTP-기반 스트리밍 기술의 이러한 단점들을 고려하여, 많은 운영자들은 멀티캐스트-기반 라이브 스트리밍 기술들에 의존한다. 이는, 보다 비용-효율적인 방식으로 백-엔드 인프라스트럭처의 크기를 조정할 수 있게 한다. 결과적으로, 특허 문헌 EP 2 704 391 A1에 개시된 바와 같은, M-ABR로 지칭되는 멀티캐스트-ABR이 개선책으로 등장했다. 이는, 멀티캐스트 또는 브로드캐스트 매체를 통해 멀티캐스트 IP(표준 문헌 RFC 791에 정의된 것과 같은 "인터넷 프로토콜") 패킷으로서 AV 라이브 콘텐츠의 다양한 표현뿐만 아니라 매니페스트 파일을 전송하는 것으로 구성되어 있어, 이에 따라 네트워크 리소스들의 상당한 소비 절감을 제공한다. 네트워크 측에는, 기본적으로 매니페스트를 획득한 다음 원본 서버로부터 대응 세그먼트들을 획득하는 소위 멀티캐스트 서버(멀티캐스터로 지칭됨)가 존재한다. 멀티캐스터는 중간 전송 프로토콜의 일부 캡슐화 방식을 사용하여 멀티캐스트 IP 패킷 내에 그 세그먼트들을 캡슐화한다. 게이트웨이 측에는, 상기 중간 전송 프로토콜을 구현함으로써 멀티캐스트 IP 패킷을 수신하고, 유니캐스트 송신을 사용함으로써 클라이언트 디바이스의 플레이어에게 공급할 준비가 된 미디어 세그먼트로서 페이로드를 추출하는 소위 디-멀티캐스터(de-multicaster)가 존재한다. 플레이어는 세그먼트 지속 기간 및 추정 품질/비트 레이트에 기초하여 기존 유니캐스트 방식(예를 들어, MPEG DASH)으로, 클라이언트 디바이스의 관점에서 HTTP 서버로서의 역할을 하는 디-멀티캐스터에 해당 세그먼트를 요청한다.
클라이언트 디바이스가 프록시로서 디-멀티캐스터를 사용하는 것을 보장하기 위해, 특허 문헌 EP 2 704 391 A1은, 클라이언트 디바이스가 AV 라이브 콘텐츠의 전달을 요청하는 CDN 컨트롤러가, 클라이언트 디바이스가 위치된 로컬 영역 네트워크(LAN) 및 CDN 컨트롤러와 멀티캐스터가 위치된 제공자 네트워크를 상호연결하는 게이트웨이 내의 디-멀티캐스터로 클라이언트 디바이스를 리디렉팅하는 리디렉션 메커니즘(redirection mechanism)을 개시한다.
그러나, 유연성을 고려할 때, 클라이언트 디바이스가 위치된 LAN과 제공자 네트워크를 상호연결하는 게이트웨이가 이러한 디-멀티캐스터를 구현하는지 여부, 그리고 만약 구현한다면 이 디-멀티캐스터가 해당 클라이언트 디바이스를 담당할 수 있는지 여부를 CDN 컨트롤러가 동적으로 결정하는 것이 바람직할 것이다. 또한, 클라이언트 디바이스의 관점에서 CDN 컨트롤러로서 간주되는 디바이스의 유효 위치 측면에서, 특히 CDN 컨트롤러로서 간주되는 디바이스의 유효 위치가 클라이언트 디바이스 구현에 전혀 영향을 미치지 않는다는 점에서, 유연한 솔루션을 제공하는 것이 바람직할 것이다. 클라이언트 디바이스(예를 들어, 브로드캐스트 네트워크)로부터의 상향링크 통신 능력이 없는 제공자 네트워크뿐만 아니라 이러한 상향링크 통신 능력을 갖춘 제공자 네트워크를 지원하기에 충분히 유연한 솔루션을 제공하는 것이 더욱 바람직하다.
적응형 스트리밍의 맥락에서 작동하는 솔루션을 제공하는 것이 더욱 바람직하며, 이에 따라 사용자가 다양한 개별 비트 레이트(또는 분해능)로 인코딩된 AV 라이브 콘텐츠의 다른 대안 버전(또는 표현)의 이용 가능성을 활용할 수 있게 한다.
또한, 간단하고 비용-효율적인 솔루션을 제공하는 것이 특히 바람직하다.
이를 위해, 본 발명은 타깃 오디오-비주얼 라이브 콘텐츠를 클라이언트에게 전달하기 위한 방법에 관한 것으로, 이 방법은 다음을 포함하는 오디오-비주얼 라이브 콘텐츠 전달 시스템에 의해 수행된다.
- 제공자 네트워크에 대한 액세스를 제공하는 게이트웨이에 의해 제공자 네트워크에 상호연결된 로컬 영역 네트워크 내에 위치되거나 또는 제공자 네트워크에 대한 액세스를 제공하는 게이트웨이 내에 위치된 클라이언트;
- 제공자 네트워크를 통해 멀티캐스트 형식으로 오디오-비주얼 라이브 콘텐츠를 송신하기 위한 멀티캐스터가 포함된 하나 이상의 서버들을 포함하는 오디오-비주얼 라이브 콘텐츠 전달 장비;
- 제공자 네트워크에 대한 액세스를 제공하는 게이트웨이 내의 또는 로컬 영역 네트워크에 위치된 임의의 디바이스 내의 디-멀티캐스터 - 상기 디-멀티캐스터는 멀티캐스터로부터 멀티캐스트 형식으로 수신되는 오디오-비주얼 라이브 콘텐츠를 유니캐스트 형식으로 변환할 수 있음 -;
- 오디오-비주얼 라이브 콘텐츠를 얻기 위한 요청들의 라우팅을 관리하는 컨트롤러.
방법은 다음을 포함한다:
- 클라이언트는 디-멀티캐스터의 잠재적 존재 및 이용 가능성에 관한 정보를 제공자 네트워크에 대한 액세스를 제공하는 게이트웨이로부터 그리고 로컬 영역 네트워크에 위치된 임의의 디바이스로부터 수신하는 것을 목표로 하는 발견 절차를 수행한다;
클라이언트가 타깃 오디오-비주얼 라이브 콘텐츠를 수신하려고 하는 경우:
- 클라이언트는 디-멀티캐스터의 존재 및 이용 가능성의 표시, 또는 그 역의 표시를 제공하는 타깃 오디오-비주얼 라이브 콘텐츠를 얻기 위한 요청을 컨트롤러에게 전송한다;
- 컨트롤러는, 적어도 디-멀티캐스터의 존재 및 이용 가능성의 표시, 또는 그 역의 표시에 따라, 타깃 오디오-비주얼 라이브 콘텐츠를 얻기 위한 요청을 충족시키기 위해 클라이언트를 리디렉팅하는 방법을 결정한다.
이에 따라, 디-멀티캐스터의 존재 및 이용 가능성의 표시, 또는 그 역의 표시에 대한 요청을 수신함으로써, 컨트롤러는 클라이언트가 멀티캐스트-유니캐스트 변환에 대해 이득을 얻을 수 있는지 여부를 결정할 수 있다. 이는, 컨트롤러가 존재하지 않거나 또는 존재하지만 이용 가능하지 않은(예를 들어, 활성) 디-멀티캐스터로 클라이언트를 리디렉팅하도록 시도하는 것을 방지한다. 이는, 컨트롤러가 로컬 영역 네트워크 내의 게이트웨이 또는 다른 디바이스에 디-멀티캐스터가 내장되어 있는지 여부 및 만약 내장되어 있는 경우 컨트롤러가 수많은 게이트웨이들과 상호작용할 때 디-멀티캐스터가 효과적으로 활성화되어 있는지 여부를 자체적으로 체크하는 것(이는 시간 및 리소스 소모적임)을 방지한다.
본 발명의 특징은 적어도 하나의 실시형태의 다음의 설명을 읽음으로써 보다 명확하게 나타날 것이며, 이 설명은 첨부 도면을 참조하여 제공된다.
도 1은 본 발명에 따른 AV 라이브 콘텐츠 전달 시스템을 개략적으로 나타낸다.
도 2a 및 도 2b는 본 발명에 따른 AV 라이브 콘텐츠 전달 시스템에서 발생하는 교환을 개략적으로 나타낸다.
도 3은 AV 라이브 콘텐츠 전달 시스템에서의 디바이스들의 예시적인 하드웨어 아키텍쳐를 개략적으로 나타낸다.
도 4는 AV 라이브 콘텐츠 전달 시스템의 제1 실시형태를 개략적으로 나타낸다.
도 5a 및 도 5b는 AV 라이브 콘텐츠 전달 시스템의 제1 실시형태에서 발생하는 교환을 개략적으로 나타낸다.
도 6은 AV 라이브 콘텐츠 전달 시스템의 제2 실시형태를 개략적으로 나타낸다.
도 7은 AV 라이브 콘텐츠 전달 시스템의 제2 실시형태에서 발생하는 교환을 개략적으로 나타낸다.
도 8은 AV 라이브 콘텐츠 전달 시스템의 제3 실시형태를 개략적으로 나타낸다.
도 9a 및 도 9b는 AV 라이브 콘텐츠 전달 시스템의 제3 실시형태에서 발생하는 교환을 개략적으로 나타낸다.
도 10은 AV 라이브 콘텐츠 전달 시스템의 제4 실시형태를 개략적으로 나타낸다.
도 11은 AV 라이브 콘텐츠 전달 시스템의 제4 실시형태에서 발생하는 교환을 개략적으로 나타낸다.
도 1은 본 발명에 따른 AV 라이브 콘텐츠 전달 시스템을 개략적으로 나타낸다.
AV 라이브 콘텐츠 전달 시스템은 LAN(101) 및 제공자 네트워크 PN(102)을 상호연결하는 게이트웨이 GW(140)를 포함한다. 제공자 네트워크 PN(102)은 예를 들어 ISP("인터넷 서비스 제공자") 네트워크이다. 제공자 네트워크 PN(102)은 예를 들어 케이블 또는 위성 브로드캐스트 네트워크이다. 따라서, 제공자 네트워크 PN(102)은 하향링크 및 상향링크 송신을 허용할 수 있거나, 이하에 설명된 바와 같이 오직 하향링크 송신만을 허용할 수 있다. 바람직한 실시형태에서, LAN(101) 및 제공자 네트워크 PN(102)은 IP 프로토콜을 지원한다. 게이트웨이 GW(140)는 바람직하게는 가정용(residential) 게이트웨이이다.
AV 라이브 콘텐츠 전달 시스템은 통상적으로 각각의 게이트웨이들에 의해 제공자 네트워크 PN(102)에 상호연결된 복수의 LAN을 포함하여, 상이한 지리적 위치들에 있는 클라이언트 디바이스들이 AV 라이브 콘텐츠 전달로부터 이점을 누릴 수 있게 한다.
AV 라이브 콘텐츠 전달 시스템에서, 적어도 하나의 클라이언트는 플레이어 PL(110)을 포함하거나 이에 연결된다. 클라이언트는 통상적으로 LAN(101)에 연결된다. 플레이어 PL(110)은 유니캐스트 형식으로 클라이언트에 의해 수신된 AV 라이브 콘텐츠를 소비(예를 들어, 재생, 녹화)하도록 적응되고 구성된다. 바람직하게, 클라이언트는 HTTP를 사용하여 통신하고 AV 라이브 콘텐츠를 수신하도록 적응 및 구성되며, 예를 들어, HAS("HTTP 적응형 스트리밍") 체계를 준수하는 AV 라이브 콘텐츠를 소비하도록 적응 및 구성된다. 이에 따라, 클라이언트는 멀티캐스트 형식 또는 브로드캐스트 형식의 AV 라이브 콘텐츠는 수신할 수 없다. 이하에 상세하게 설명되는 바와 같이, 플레이어 PL(110)은 AV 라이브 콘텐츠 전달 시스템의 인프라스트럭처에 대한 지식이 없어도 작동 가능하다(agnostic to). 클라이언트는, 플레이어 PL(110)에 의해 소비되도록 의도되는 수신된 AV 라이브 콘텐츠 데이터를 형상화하여 AV 라이브 콘텐츠 데이터가 플레이어 PL(110)에 적합한 형식이 되도록 한다. 클라이언트는 플레이어 PL(110)이 상기 AV 라이브 콘텐츠 데이터를 수신할 수 있도록 프로토콜 교환을 수행한다. 이하에서는, 간략화를 위해 클라이언트와 플레이어 PL(110)이 단일 엔티티인 것으로 간주된다.
AV 라이브 콘텐츠 전달 시스템에서, 콘텐츠 전달 장비 CDE(120)는 제공자 네트워크 PN(102)에 직접적으로 또는 간접적으로 연결된다. 콘텐츠 전달 장비 CDE(120)는 하나 이상의 서버들을 포함한다. 콘텐츠 전달 장비 CDE(120)는 적어도 멀티캐스터를 포함한다. 멀티캐스터는, 제공자 네트워크 PN(102)을 통해 AV 라이브 콘텐츠를 멀티캐스트 형식으로 제공하는 것을 담당한다. 예를 들어, 멀티캐스터는 UDP(표준 문헌 RFC 768에 의해 정의된 것과 같은 "사용자 데이터그램 프로토콜")를 사용하여 AV 라이브 콘텐츠의 다양한 표현들을 멀티캐스트 스트림의 형식으로 제공한다. 제공자 네트워크 PN(102)을 통한 멀티캐스트 송신에 의존하는 것은, AV 라이브 콘텐츠를 유니캐스트 방식으로 전달하는 것과 비교하여 백-엔드 인프라스트럭처를 다운사이징하는 것(즉, AV 라이브 콘텐츠 전달을 수행하기 위해 콘텐츠 전달 장비 CDE(120)에 의해 필요로 하는 리소스 및 대역폭을 프로세싱하는 것)을 허용한다.
업스트림에서 멀티캐스터는 AV 라이브 콘텐츠의 다양한 표현을 세그먼트들로 패키징하는 것을 담당하는 원본 패키저(origin packager)로 지칭되는 원본 서버에 존재할 수 있으며, 여기서 모든 세그먼트들은 HAS 체계를 준수하는 미디어 파일 세트로서 정렬된다(동일한 지속기간, 동일한 이미지). 업스트림에서 원본 패키저에는 AV 라이브 콘텐츠(예를 들어, TV 채널)의 다양한 표현들을 원본 패키저로 전달하는 OTT("오버-더-탑") 인코더가 존재할 수 있으며, 여기서 각각의 표현은 OTT 인코더에 의해 특정 비트-레이트/품질로 인코딩된다.
(클라이언트를 포함하는) LAN(101) 내의 게이트웨이 GW(140) 또는 다른 디바이스는 디-멀티캐스터 DM(150)을 포함한다. 디-멀티캐스터 DM(150)은, 멀티캐스터에 의해, 가능하게는 디-멀티캐스터 DM(150)이 LAN(101) 내의 다른 디바이스에 위치되는 경우 게이트웨이 GW(140)를 통해, 송신된 멀티캐스트 IP 패킷들을 수신하도록 적응되고 구성된다.
디-멀티캐스터 DM(150)은 유니캐스트 송신을 사용함으로써 플레이어 PL(110)에 공급할 준비가 된 AV 라이브 콘텐츠 세그먼트들을 추출하도록 적응되고 구성된다. 플레이어 PL(110)이 AV 라이브 콘텐츠를 수신할 때, 플레이어 PL(110)은 AV 라이브 콘텐츠를 수신하는 데 이용 가능한 대역폭을 모니터링하고, 또한 이용 가능한 대역폭 그리고 바람직하게는 이용 가능한 내부 프로세싱 리소스들과 일치하는 AV 라이브 콘텐츠의 표현을 선택하도록 적응되고 구성된다. 따라서, 디-멀티캐스터 DM(150)은 멀티캐스트에서 유니캐스트로의 변환을 수행하도록 적응되고 구성된다. 이를 위해, 디-멀티캐스터 DM(150)은, 예를 들어, IGMP(표준 문헌 RFC 3376에 의해 정의된 것과 같은 "인터넷 그룹 관리 프로토콜") 프로토콜을 구현함으로써 멀티캐스트 스트림 등록을 관리하도록 적응되고 구성된다. 또한, 디-멀티캐스터 DM(150)은, 예를 들어, 콘텐츠 전달 장비 CDE(120)에 의해 제공되는 사전정의된 전용 멀티캐스트 스트림 또는 채널을 사용함으로써 또는 콘텐츠 전달 장비 CDE(120)의 사전정의된 전용 구성 서버와 교환함으로써, 멀티캐스트 송신을 통해 AV 라이브 콘텐츠가 수신될 수 있는 종래의 구성으로 알려져 있다.
디-멀티캐스터 DM(150)은 또한, 디-멀티캐스터 DM(150)이 멀티캐스트 송신 동안 누락된 AV 라이브 콘텐츠 세그먼트들을 리트리브(retrieve)할 수 있게 하기 위해, 콘텐츠 전달 장비 CDE(120)의 복원 유니캐스트 서버(repair unicast server: RUS)에 응답하여 AV 라이브 콘텐츠 세그먼트들을 유니캐스트 형식으로 요청 및 수신하도록 적응되고 구성될 수 있다. 이 양태는 이하에 다뤄진다.
게이트웨이 GW(140) 및 LAN(101)과 같은 제공자 네트워크 PN(102)에 연결된 게이트웨이 및 LAN은 이러한 디-멀티캐스터를 포함할 수 있는 한편, 제공자 네트워크 PN(102)에 연결된 다른 게이트웨이들 또는 다른 LAN들은 이러한 디-멀티캐스터를 포함하지 않을 수도 있다. 또한, 이러한 디-멀티캐스터를 포함하는 게이트웨이들 또는 LAN들 중에서, 일부 디-멀티캐스터들은 존재하지만 활성이 아닐 수도 있고, 일부 디-멀티캐스터들은 메모리 및/또는 프로세싱 리소스가 이미 부족할 수도 있다. 이 양태는 이하에 상세하게 다뤄진다.
AV 라이브 콘텐츠 전달 시스템에서, 컨트롤러 CTRL(130)은 AV 라이브 콘텐츠 전달을 조정하는데, 즉, 오디오-비주얼 라이브 콘텐츠를 얻기 위한 요청을 라우팅하는 것을 관리한다. AV 라이브 콘텐츠 전달 시스템의 인프라스트럭처에 따라, 컨트롤러 CTRL(130)은 제공자 네트워크 PN(102)에 위치될 수 있거나 이에 연결될 수 있고, 또는 게이트웨이 GW(140) 내에 또는 LAN(101) 내에 위치될 수 있다. 플레이어 PL(110)이 (예를 들어, 사용자 커맨드에 따라) AV 라이브 콘텐츠를 소비할 것으로 예상되는 경우, 플레이어 PL(110)은 해당 AV 라이브 콘텐츠의 전달을 요청하기 위해 컨트롤러 CTRL(130)에 컨택한다. 플레이어 PL(110)은, 컨트롤러 CTRL(130)이 AV 라이브 콘텐츠가 그로부터 전달될 수 있는 서버인 것처럼 컨트롤러 CTRL(130)에 컨택한다. 컨트롤러 CTRL(130)이 자체적으로 AV 라이브 콘텐츠를 전달할 수 없다는 사실은 플레이어 PL(110)에게 명백하다. 플레이어 PL(110)은, DNS("도메인 이름 시스템") 확인(resolution)을 사용하거나, 또는 게이트웨이 GW(140) 또는 LAN(101)의 다른 디바이스 내의 디-멀티캐스터 DM(150)의 이용 가능성을 검출하는 것을 목표로 하는 발견 절차로부터의 주소 추론을 사용하여 컨트롤러 CTRL(130)에 컨택하는 방법을 결정한다. 이 양태는 이하에 상세하게 다뤄진다. AV 라이브 콘텐츠를 전달하기 위한 요청을 충족시키기 위해, 컨트롤러 CTRL(130)은, 제공자 네트워크 PN(102)에서 리소스 소비를 최적화하기 위한 목적으로 AV 라이브 콘텐츠 전달 시스템의 인프라스트럭처 및 실제 운영 상태의 관점에서 실현가능한 모든 것에 따라, (예를 들어, 콘텐츠 전달 장비 CDE(120)의) 적절한 유니캐스트 서버에 또는 디-멀티캐스터 DM(150)에 플레이어 PL(110)을 리디렉팅한다. 다른 관점들에서, 컨트롤러는 적어도 멀티캐스트에서 유니캐스트로의 변환을 제공할 수 있는 이러한 디-멀티캐스터의 존재 또는 이용 가능성의 표시, 또는 그 역의 표시에 따라, 타깃 AV 라이브 콘텐츠를 얻기 위한 요청들을 충족시키기 위해 클라이언트를 리디렉팅하는 방법을 결정한다. 또한, 이 양태는 이하에 상세하게 다뤄진다.
특정 실시형태에서, 디-멀티캐스터 DM(150)은 게이트웨이 GW(140)에 설치된다. 다른 특정 실시형태에서, 디-멀티캐스터 DM(150)은 게이트웨이 GW(140)에 연결된 셋탑 박스에 설치된다. 이러한 셋탑 박스는 LAN(101) 내에 있으며, 또한 LAN(101)을 통해 또는 전용 링크에 의해 게이트웨이 GW(140)에 연결될 수 있다.
특정 실시형태에서, 클라이언트 및 플레이어 PL(110)은 게이트웨이 GW(140) 또는 여기에 연결된 셋탑 박스에 설치된다. 디-멀티캐스터 DM(150)이 또한 게이트웨이 GW(140) 또는 이에 연결된 셋탑 박스에 존재하는 경우, 클라이언트 및 플레이어 PL(110)은 디-멀티캐스터 DM(150)에 대해, 그리고 존재하는 경우 컨트롤러 CTRL(130)로부터 밀폐되어(hermetically) 설치된다. 이는, 발견 절차를 수행하기 전에, 클라이언트 및 플레이어 PL(110)이 이들이 디-멀티캐스터 DM(150)과 동일한 디바이스에 공동-위치되었는지 여부를 인지하지 못하고 있음을 의미한다.
도 2a 및 도 2b는 본 발명에 따른 AV 라이브 콘텐츠 전달 시스템에서 발생하는 교환을 개략적으로 나타낸다.
도 2a의 단계 200 및 도 2b의 단계 210에서, 플레이어 PL(110)은 발견 절차를 개시하는데, 이 발견 절차 동안 게이트웨이 GW(140) 및 LAN(101) 상의 임의의 다른 디바이스가 플레이어 PL(110)에게 상기 게이트웨이 GW(140) 또는 LAN(101) 상의 상기 다른 디바이스가 이용 가능한 디-멀티캐스터를 내장하고 있는지 여부를 통지해야만 한다. 플레이어 PL(110)이 게이트웨이 GW(140)와는 별개의 디바이스에 내장되는 경우, 발견 절차는 LAN(101)에서 수행된다. 플레이어 PL(110)이 이러한 디-멀티캐스터(예컨대, 게이트웨이 GW(140))를 내장할 수 있는 디바이스에 의해 호스팅되는 경우, 발견 절차는 플레이어 PL(110)을 호스팅하는 디바이스의 API("애플리케이션 프로그래밍 인터페이스")를 통해 추가로 수행된다.
이용 가능한 디-멀티캐스터는, 첫째로 존재하고 둘째로 활성(즉, 실행중)인 디-멀티캐스터를 지칭한다. 이용 가능한 디-멀티캐스터는 멀티캐스트-유니캐스트 변환을 위한 보완 AV 라이브 콘텐츠를 담당하기에 충분한 메모리 및/또는 프로세싱 리소스를 갖는 디-멀티캐스터로서 지칭될 수 있다.
플레이어 PL(110)이 게이트웨이 GW(140)와는 별개의 디바이스에 내장되고 발견 절차가 LAN(101)에서 단독으로 수행된다고 예시적으로 고려하자. LAN(101)의 맥락에서 본원에 설명된 발견 절차 원리들은 앞서 언급한 API의 맥락에서 필요한 부분만 약간 수정하여(mutatis mutandis) 적용할 수 있다.
발견 절차는 예를 들어, UPnP(표준 문헌 ISO/IEC 29341에 의해 정의된 것과 같은 "유니버셜 플러그 앤 플레이") 프로토콜에서 또한 사용되는 것과 같은 SSDP("간단한 서비스 발견 프로토콜") 프로토콜과 같은 SDP("서비스 발견 프로토콜") 프로토콜, 또는 애플(Apple)의 Bonjour 또는 DNS-기반 서비스 발견 접근방식과 같은 기술 Zeroconf을 사용한다. 예를 들어, 게이트웨이 GW(140)에 위치되고 존재하는 경우 가능하다면 디-멀티캐스터 DM(150)에 의해 미리 구성된 로컬 DNS 서버는, 상기 디-멀티캐스터 DM(150)과 연관된 사전정의된 도메인 이름의 확인을 허용한다.
발견 절차 동안, 플레이어 PL(110)은 디-멀티캐스터가 게이트웨이 GW(140)에 또는 더욱 일반적으로 LAN(101) 상에 존재하는지 여부 및 바람직하게는 디-멀티캐스터가 존재한다면 활성인지 여부를 결정하기 위해 LAN(101)을 프로빙한다(probe). 디바이스가 이러한 디-멀티캐스터를 호스팅하면, 상기 디바이스는 해당 디-멀티캐스터 DM(150)을 식별하는 디스크립터를 응답으로 송신한다. 게이트웨이 GW(140)가 디-멀티캐스터 DM(150)을 내장하는 것으로 간주한다면, 게이트웨이 GW(140)는 이에 따라 디-멀티캐스터 DM(150)을 식별하는 디스크립터를 응답으로 송신한다. 이에 따라, 디스크립터는 본질적으로 디-멀티캐스터 DM(150)의 존재를 나타낸다. 디스크립터는 또한 디-멀티캐스터 DM(150)에 컨택하기 위한 주소, 및, 가능다면, 디-멀티캐스터 DM(150)을 설치한 경우의 구성에 의해 정의되는 디-멀티캐스터 DM(150)의 로컬 이름을 나타낸다.
본원에 사용된 용어 "주소"는 특히 IP 주소 및 포트 번호의 연결(concatenation)을 포함하는 광범위한 의미로 이해되어야 한다는 점에 주의해야 한다.
디스크립터는 또한 디-멀티캐스터 DM(150)이 활성인지 여부를 나타낼 수 있다. 디스크립터는 또한 디-멀티캐스터 DM(150)이 다른 AV 라이브 콘텐츠 전달을 수락하기에 충분한 메모리 및/또는 프로세싱 리소스를 갖는지 여부를 나타낼 수 있다. 이 디스크립터에 이러한 정보를 채우기 위해, 디-멀티캐스터 DM(150)을 호스팅하는 디바이스는 내부적으로 디-멀티캐스터 DM(150)에게 활성 상태인지 확인하도록 요청할 수 있으며, 가능하다면 디-멀티캐스터 DM(150)이 다른 AV 라이브 콘텐츠 전달을 수락하기에 충분한 메모리 및/또는 프로세싱 리소스를 갖는지 여부를 확인하도록 요청할 수 있다.
바람직한 대안적인 실시형태에서, 디스크립터는 오직 디-멀티캐스터 DM(150)의 존재 및 디-멀티캐스터 DM(150)에 컨택하기 위한 IP 주소 및 포트 번호와 같은 주소만을 나타낸다. 그후, 플레이어 PL(110)은 디스크립터에 제공된 주소를 사용함으로써 디-멀티캐스터 DM(150)이 활성인지 여부를 결정하기 위한 전용 요청을 디-멀티캐스터 DM(150)에 송신한다. 디-멀티캐스터 DM(150)이 상기 전용 요청에 응답할 때, 플레이어 PL(110)은 디-멀티캐스터 DM(150)이 활성 상태라는 결론을 내린다. 응답 시에, 디-멀티캐스터 DM(150)은, 디-멀티캐스터 DM(150)이 다른 AV 라이브 콘텐츠 전달을 수락하기에 충분한 메모리 및/또는 프로세싱 리소스들을 갖는지 여부를 나타낼 수 있다. 사전정의된 타임아웃 지연시간 내에 어떠한 전용 요청에 대한 응답도 수신되지 않으면, 플레이어 PL(110)은 디-멀티캐스터 DM(150)이 활성 상태가 아니라는 결론을 내린다.
도 2a의 단계 201 및 도 2b의 단계 211에서, 플레이어 PL(110)은 컨트롤러 CTRL(130)에 컨택하기 위한 주소를 획득하고 하나의 특정 AV 라이브 콘텐츠의 전달을 요청하는 요청 REQ1을 컨트롤러 CTRL(130)에 송신한다. 이에 따라, 요청 REQ1은 해당 AV 라이브 콘텐츠를 식별하는 유니캐스트 메시지이다. 예를 들어, 요청 REQ1은 FQDN("전체 주소 도메인 이름")으로 구성된 URL("유니폼 리소스 로케이터")과 그 뒤에 (AV 라이브 콘텐츠가 패키징된 포맷의 관점에서) 적절한 파일 확장자를 가진 텍스트 파일에 대한 경로를 포함하는 HTTP GET 메시지이며, 예를 들어 아래와 같다:
HTTP GET tv.myISP.com/SportsChannel1.mpd
요청 REQ1은, 발견 이후에, 플레이어 PL(110)이 제공자 네트워크 PN(102)에 액세스하는 게이트웨이가 플레이어 PL(110)에 대한 AV 라이브 콘텐츠 전달을 담당할 수 있는 디-멀티캐스터를 내장하고 있는지 여부를 나타내는 정보를 추가로 포함한다. 예를 들어, 위의 예를 재사용하면, 요청 REQ1은 정보를 명확하게 제공하는 인라인 파라미터(inline parameter)를 포함하며, 디-멀티캐스터 이용 가능성을 나타낼 경우 아래와 같다:
HTTP GET tv.myISP.com/SportsChannel1.mpd?de-multicaster=ON
디-멀티캐스터의 이용 불가능(unavailability)을 나타낼 경우 아래와 같다:
HTTP GET tv.myISP.com/SportsChannel1.mpd?de-multicaster=OFF
다른 바람직한 접근방식은 요청 REQ1이 이러한 정보를 함축적으로 포함한다는 것이다. 요청 REQ1은, 만약 존재한다면, 해당 디-멀티캐스터의 주소 또는 그 로컬 이름을 제공하는 인라인 파라미터를 대신 포함한다. 어떠한 주소도 지정되지 않은 경우, 어떠한 디-멀티캐스터도 이용 가능하지 않으며, 요청 REQ1은 예를 들어 아래와 같이 어떠한 인라인 파라미터도 포함하지 않는다:
HTTP GET tv.myISP.com/SportsChannel1.mpd
주소가 지정된 경우, 요청 REQ1은 예를 들어 아래와 같이 인라인 파라미터로서 상기 디-멀티캐스터의 주소 또는 로컬 이름을 포함한다:
HTTP GET tv.myISP.com/SportsChannel1.mpd?
de-multicaster=192.168.1.100:8000
이 예에서, 192.168.1.100:8000는 디-멀티캐스터 DM(150)의 IP 주소와 포트 번호의 조합이다.
이러한 바람직한 접근방식은 유리하게 AV 라이브 콘텐츠 전달 시스템에 배치된 모든 디-멀티캐스터에 대해 오직 하나의 잘-확립된 로컬 이름 및/또는 주소를 갖는 것을 방지할 수 있다.
요청 REQ1은, 디-멀티캐스터가 존재하는 경우, 여분의 인라인 파라미터로서 아래와 같이 FQDN 정보(이 예에서는, tv.myISP.com)를 추가로 포함할 수 있다.
HTTP GET tv.myISP.com/SportsChannel1.mpd?
de-multicaster=192.168.1.100:8000&FQDN_orig= tv.myISP.com
이는 나중에 예를 들어, 액세스 제어를 이유로, 그리고 상세하게 설명된 실시형태에서 이후에 설명되는 추가적인 양태에 대해 디-멀티캐스터 DM(150)에 유용하다. 이러한 인라인 파라미터는 필수적인 것은 아님에 주의한다. 존재하지 않는 경우, 디-멀티캐스터 DM(150)에 플레이어 PL(110)을 리디렉팅할 때 컨트롤러 CTRL(130)에 의해 추가될 수 있다. 존재하는 경우, 디-멀티캐스터 DM(150)으로 플레이어 PL(110)을 리디렉팅할 필요가 있을 때 요청 REQ1의 인라인 파라미터를 카피해야만 하는 컨트롤러 CTRL(130)에게 명백하다.
도 2a의 단계 201에서, 요청 REQ1는, 플레이어 PL(110)에 대한 AV 라이브 콘텐츠 전달을 담당할 수 있는 디-멀티캐스터가 로컬로 존재한다는 것을 나타내는 정보를 포함한다고 간주된다. 상보적으로, 도 2b의 단계 211에서, 요청 REQ1는, 플레이어 PL(110)에 대한 AV 라이브 콘텐츠 전달을 담당할 수 있는 어떠한 디-멀티캐스터도 로컬로 존재하지 않는다는 것을 나타내는 정보를 포함한다고 간주된다.
도 2a의 단계 202 및 도 2b의 단계 212에서, 컨트롤러 CTRL(130)은 해당 AV 라이브 콘텐츠가 임의의 형식으로 이용 가능한지 여부를 체크한다. 해당 AV 라이브 콘텐츠가 어떠한 형식으로도 이용 가능하지 않은 것으로 컨트롤러 CTRL(130)가 결정하는 경우, 컨트롤러 CTRL(130)은 예를 들어 HTTP ERROR(404) 메시지를 반환함으로써 요청 REQ1을 거절한다.
도 2a의 단계 202에서, 컨트롤러 CTRL(130)은 해당 AV 라이브 콘텐츠가 멀티캐스트 형식으로 이용 가능한지 여부를 체크한다. 컨트롤러 CTRL(130)은, 예를 들어, 멀티캐스트 형식으로 이용 가능한 AV 라이브 콘텐츠의 목록을 제공하는 파일에 액세스한다. 컨트롤러 CTRL(130)이 해당 AV 라이브 콘텐츠가 멀티캐스트 형식으로 이용 가능하다고 결정하는 경우, 컨트롤러 CTRL(130)은 도 2a에 도시된 바와 같이 디-멀티캐스터 DM(150)으로 플레이어 PL(110)을 리디렉팅한다. 그렇게 하기 위해, 컨트롤러 CTRL(130)은 바람직하게는 요청 REQ1의 인라인 파라미터로서 제공된 것과 같은 디-멀티캐스터 DM(150)의 주소 또는 로컬 이름을 요청 REQ1에 응답하여 송신된 리디렉트 메시지 REDIR1에 포함시킨다.
이에 더해, 제공자 네트워크 PN(102)이 상향링크 통신을 허용하는 경우, 컨트롤러 CTRL(130)은 (예를 들어, 콘텐츠 전달 장비 CDE(120)의) 제공자 네트워크 PN(102) 상에 유니캐스트 AV 라이브 콘텐츠 전달 서버의 주소(또는 URL)을 인라인 파라미터로서 리디렉트 메시지 REDIR1에 포함시킬 수 있다. 이러한 유니캐스트 AV 라이브 콘텐츠 전달 서버는, 특히 디-멀티캐스터 DM(150)이 멀티캐스트 형식으로 수신된 세그먼트들 중에서 적어도 하나의 누락된 AV 라이브 콘텐츠가 존재한다고 검출하는 경우, 유니캐스트 형식의 세그먼트들에 의해 멀티캐스트 형식으로 수신된 AV 라이브 콘텐츠 세그먼트들을 완성하기 위해 디-멀티캐스트 DM(150)에 의해 나중에 사용될 수 있다.
전술한 예를 계속하면, 리디렉트 메시지 REDIR1는 예를 들어 아래와 같다:
HTTP REDIRECT 192.168.1.100:8000/SportsChannel1.mpd? FQDN_orig= tv.myISP.com &CDN_unicastServer=<address of the server>
컨트롤러 CTRL(130)이 해당 AV 라이브 콘텐츠가 멀티캐스트 형식으로 이용 가능하지 않은 것으로 결정하는 경우, AV 라이브 콘텐츠 전달 시스템의 인프라스트럭처가 게이트웨이 GW(140) 및 LAN(101)로부터 콘텐츠 전달 장비 CDE(120)로의 상향링크 통신을 허용한다면 그리고 이러한 유니캐스트 AV 라이브 콘텐츠 전달 서버가 제공자 네트워크 PN(102) 내에(예를 들어, 콘텐츠 전달 장비 CDE(120) 내에) 존재한다면, 컨트롤러 CTRL(130)은 (예를 들어, 콘텐츠 전달 장비 CDE(120)의) 제공자 네트워크 PN(102) 상에 유니캐스트 AV 라이브 콘텐츠 전달 서버로 플레이어 PL(110)을 리디렉팅한다. 플레이어 PL(110)은 이에 따라, 도 2b에 도시된 바와 같이, 게이트웨이 GW(140) 내에 또는 LAN(101)의 어떠한 다른 디바이스 내에 어떠한 디-멀티캐스터도 존재하지 않는 것과 동일한 방식으로 리디렉팅된다.
컨트롤러 CTRL(130)이 해당 AV 라이브 콘텐츠가 멀티캐스트 형식으로 이용 가능한지 여부를 결정할 수 없는 경우, 컨트롤러 CTRL(130)은 디-멀티캐스터 DM(150)이 마지막에 이러한 체크를 수행할 수 있게 한다. 이 경우, 컨트롤러 CTRL(130)은 바람직하게 해당 유니캐스트 AV 라이브 콘텐츠 전달 서버의 주소(또는 URL)를 리디렉트 메시지 REDIR1에 인라인 파라미터로서 나타낸다.
그후, 리디렉트 메시지 REDIR1의 각각의 인라인 파라미터는 플레이어 PL(110)에 의해 리디렉션동안 디-멀티캐스터 DM(150)에 제공되며, 이에 따라 필요할 때 디-멀티캐스터 DM(150)이 유니캐스트 AV 라이브 콘텐츠 전달 서버의 주소를 식별할 수 있게 한다. 이 양태는 도 8에 도시된 특정 인프라스트럭처 실시형태의 맥락으로 도 9a 및 도 9b에서 다뤄지지만, 도 4에 도시된 특정 인프라스트럭처 실시형태의 맥락에서도(즉, 제공자 네트워크 PN(102)이 상향링크 통신을 허용하는 한) 동일한 원리가 또한 적용된다.
특정 실시형태에서, 디-멀티캐스터 DM(150)으로 플레이어 PL(110)을 리디렉팅하는 리디렉트 메시지 REDIR1은, 예를 들어, 복원 유니캐스트 서버의 주소(존재하는 경우), 및/또는 컨트롤러 CTRL(130)에 의해 알려져 있다면 해당 AV 라이브 콘텐츠의 다양한 표현들의 멀티캐스트 주소들과 같은 다른 인라인 파라미터들을 더 포함한다. 전술한 예를 계속하면, 리디렉트 메시지 REDIR1는 예를 들어 아래와 같다:
HTTP REDIRECT 192.168.1.100:8000/SportsChannel1.mpd? FQDN_orig=tv.myISP.com&CDN_unicastServer=<address of the server>
&repair=172.16.254.1:80
이 예에서, 172.16.254.1:80는 해당 복원 유니캐스트 서버에 할당된 IP 주소와 포트 번호의 조합이다.
이제 도 2b의 단계 212로 돌아오면, 컨트롤러 CTRL(130)은 해당 AV 라이브 콘텐츠가 유니캐스트 형식으로 이용 가능한지 여부를 체크한다. 컨트롤러 CTRL(130)은, 예를 들어, 유니캐스트 형식으로 이용 가능한 AV 라이브 콘텐츠의 목록을 제공하는 파일에 액세스한다. 컨트롤러 CTRL(130)가 해당 AV 라이브 콘텐츠가 유니캐스트 형식으로 이용 가능한 것으로 결정하는 경우, AV 라이브 콘텐츠 전달 시스템의 인프라스트럭처가 LAN(101)으로부터 콘텐츠 전달 장비 CDE(120)로의 상향링크 통신을 허용한다면 그리고 이러한 유니캐스트 AV 라이브 콘텐츠 전달 서버가 제공자 네트워크 PN(102) 상에(예를 들어, 콘텐츠 전달 장비 CDE(120) 내에) 존재한다면, 컨트롤러 CTRL(130)은 (예를 들어, 콘텐츠 전달 장비 CDE(120)의) 제공자 네트워크 PN(102) 상의 유니캐스트 AV 라이브 콘텐츠 전달 서버로 플레이어 PL(110)을 리디렉팅한다. 그렇게 하기 위해, 컨트롤러 CTRL(130)은 바람직하게는 요청 REQ1에 응답하여 송신된 리디렉트 메시지 REDIR1 내에 해당 유니캐스트 AV 라이브 콘텐츠 전달 서버의 주소를 포함시킨다. 전술한 예를 계속하면, 리디렉트 메시지 REDIR1는 예를 들어 아래와 같다:
HTTP REDIRECT 172.16.248.3:80/SportsChannel1.mpd
여기서, 172.16.248.3:80는 해당 유니캐스트 AV 라이브 콘텐츠 전달 서버의 IP 주소와 포트 번호의 조합이다.
그렇지 않으면, 컨트롤러 CTRL(130)은, 예를 들어, HTTP ERROR(404) 메시지를 반환함으로써 요청 REQ1을 거절한다.
도 2a의 단계 203 및 도 2b의 단계 213에서, 플레이어 PL(110)은 리디렉트 메시지 REDIR1에 포함된 명령들에 따라 다른 요청 REQ2를 송신한다. 따라서, 요청 REQ2는 컨트롤러 CTRL(130)이 처음에 요청했던 것과는 다른 서버로부터 해당 AV 라이브 콘텐츠의 전달을 요청한다. 도 2a의 단계 203에서, 플레이어 PL(110)은 디-멀티캐스터 DM(150)에 요청 REQ2를 송신한다.
도 2b의 단계 213에서, 플레이어 PL(110)은 유니캐스트 AV 라이브 콘텐츠 전달 서버에 요청 REQ2를 송신한다.
결과적으로, 플레이어 PL(110)은 해당 AV 라이브 콘텐츠를 수신한다. AV 라이브 콘텐츠는 도 2a의 단계 205에서 단계 204의 콘텐츠 전달 장비 CDE(120)로부터 수신된 송신들의 릴레이로서 작용하는 디-멀티캐스터 DM(150)으로부터 유니캐스트 형식으로 수신되거나; 또는 AV 라이브 콘텐츠는 도 2b의 단계 214에서, 유니캐스트 AV 라이브 콘텐츠 전달 서버(예를 들어, 콘텐츠 전달 장비 CDE(120))로부터 유니캐스트 형식으로, 즉, 디-멀티캐스터 DM(150)을 통과하지 않고 수신된다.
단계 204 및 단계 205에서, 제공자 네트워크(102)가 상향링크 통신을 허용하는 경우, 요청된 AV 라이브 콘텐츠 세그먼트는 콘텐츠 전달 장비 CDE(120)의 멀티캐스터로부터 멀티캐스트 형식으로 이전에 수신된 것으로서 디-멀티캐스터 DM(150)에 존재하고 디-멀티캐스터 DM(150)이 요청된 AV 라이브 콘텐츠 세그먼트를 플레이어 PL(110)에 반환할 수 있거나, 또는 세그먼트가 누락된 경우, 디-멀티캐스터 DM(150)은 유니캐스트 AV 라이브 콘텐츠 전달 서버로부터 콘텐츠를 요청할 수 있다.
앞서 설명된 접근방식 덕분에, 컨트롤러 CTRL(130)은 게이트웨이 GW(140) 또는 LAN(101)의 임의의 다른 디바이스가 이러한 디-멀티캐스터를 구현하는지 여부, 그리고 존재한다면 이 디-멀티캐스터가 AV 라이브 콘텐츠 전달 요청을 충족시키기 위해 플레이어 PL(110)을 담당할 수 있는지 여부를 동적으로 결정한다. 실제로, 디-멀티캐스터는 존재하지만 비활성일 수 있는데, 이는 디-멀티캐스터로 플레이어 PL(110)을 리디렉팅하는 것이 이 경우에 적어도 플레이어 PL(110)의 QoE("경험 품질")의 관점에서 상당히 쓸모없는 지연시간을 함축하기 때문에 부적절할 수 있다는 것을 의미한다.
이러한 접근방식은 도 4, 도 6, 도 8 및 도 10의 특정 인프라스트럭처 실시형태들에서 이하에 상세하게 설명되는 바와 같이 컨트롤러 CTRL(130)의 유효 위치의 측면에서 유연하며, 이러한 유효 위치는 플레이어 PL(110)(즉, 클라이언트) 구현에 어떠한 영향도 미치지 않는다. 게다가, 이 접근방식은 상기 제공자 네트워크(예를 들어, 브로드캐스트 네트워크)를 통한 게이트웨이 GW(140) 및 LAN(101)으로부터의 어떠한 상향링크 통신 성능도 갖지 않는 제공자 네트워크들뿐만 아니라, 이러한 상향링크 통신 성능을 갖는 제공자 네트워크들을 지원하기에 충분히 유연하다. 또한, 이 접근방식은 적응형 스트리밍에 적합하며, 이에 따라 사용자가 다양한 개별 비트 레이트(또는 분해능)로 인코딩된 AV 라이브 콘텐츠의 다른 대안 버전(또는 표현)의 이용 가능성을 활용할 수 있게 한다는 점을 알 수 있다.
도 3은 AV 라이브 콘텐츠 전달 시스템의 디바이스들의 예시적인 하드웨어 아키텍쳐를 개략적으로 나타낸다. 디-멀티캐스터 DM(150) 및/또는 컨트롤러 CTRL(130) 및/또는 게이트웨이 GW(140) 및/또는 플레이어 PL(110) 및/또는 콘텐츠 전달 장비 CDE(120)의 임의의 서버는 이러한 예시적인 하드웨어 아키텍쳐를 중심으로 구축될 수 있다. 도 3이 컨트롤러 CTRL(130)의 하드웨어 아키텍쳐를 나타내는 것임을 예시적으로 고려하자.
도시된 예시적인 하드웨어 아키텍쳐에 따르면, 컨트롤러 CTRL(130)은 통신 버스(310)에 의해 상호연결된 이하의 컴포넌트들: 프로세서, 마이크로프로세서, 마이크로컨트롤러 또는 CPU("중앙 처리 장치")(301); RAM("랜덤-액세스 메모리")(302); ROM("판독-전용 메모리")(303) 또는 EEPROM("전기적으로 삭제가능한 ROM") 또는 플래시 메모리; 하드-디스크 드라이브, 또는 비-일시적 저장 매체 상에 저장된 정보를 판독하도록 적응된 임의의 다른 디바이스, 예컨대, SD("보안 디지털") 카드 판독기(304); LAN(101) 및/또는 제공자 네트워크 PN(102)을 통해 통신하도록 허용하는 적어도 하나의 통신 인터페이스 COM(305)을 포함한다.
CPU(301)는 ROM(303)로부터 또는 SD 카드와 같은 외부 메모리로부터 RAM(302)으로 로딩된 명령들을 실행할 수 있다. 컨트롤러 CTRL(130)이 파워 온된 후, CPU(301)는 RAM(302)로부터의 명령들을 판독하고 이러한 명령들을 실행할 수 있다. 이 명령들은 CPU(301)로 하여금 컨트롤러 CTRL(130)와 관련하여 본원에 설명된 단계들을 수행하게 하는 하나의 컴퓨터 프로그램을 형성한다.
본원에 설명된 단계들이 PC("퍼스널 컴퓨터"), DSP("디지털 신호 프로세서") 또는 마이크로컨트롤러와 같은 프로그래머블 컴퓨팅 머신에 의한 명령들의 세트 또는 프로그램의 실행에 의해 소프트웨어 형태로 구현될 수 있거나; 또는 FPGA("필드-프로그래머블 게이트 어레이") 또는 ASIC("애플리케이션-특정 집적 회로")와 같은 전용 컴포넌트 또는 머신에 의해 하드웨어 형태로 구현될 수 있다는 점에 유의해야 한다. 보다 일반적으로, AV 라이브 콘텐츠 전달 시스템의 임의의 디바이스는 해당 디바이스와 관련하여 본원에 설명된 바와 같이 관련 단계들을 구현하도록 적응되고 구성된 프로세싱 전자 회로를 포함한다.
도 4는 AV 라이브 콘텐츠 전달 시스템의 제1 실시형태를 개략적으로 나타내며, 여기서 컨트롤러 CTRL(130)는 제공자 네트워크 PN(102)에 위치되거나 또는 이에 연결되며, 즉, 플레이어 PL(110)의 관점으로부터 게이트웨이 GW(140)를 넘어서 있다. 도 4에서는 도메인 이름들을 확인하기 위한 제공자 네트워크 PN(102)의 DNS 서버(161)가 더 나타난다. 또한, 도 4의 콘텐츠 전달 장비 CDE(120)는 멀티캐스터, 또는 멀티캐스트 서버 MS(121)뿐만 아니라 앞서 언급된 복원 유니캐스트 서버 RUS(122)를 나타낸다. 복원 유니캐스트 서버 RUS(122)는 멀티캐스트 서버 MS(121)와 공동-위치, 즉, 물리적으로 동일한 머신 상에 위치될 수 있다. 복원 유니캐스트 서버 RUS(122)는, 통상적으로 멀티캐스트 동작(예를 들어, RTP 또는 FLUTE/ALC)을 위해 사용된 전송 프로토콜에 따라 선택된 표준화된 통신 프로토콜을 통해 누락된 AV 라이브 콘텐츠 세그먼트들을 복구하기 위한 메커니즘을 구현한다. 콘텐츠 전달 장비 CDE(120)는 이미 유발된(evoked) 다른 서버들을 포함할 수 있다.
특정 특징에 따라, 복원 유니캐스트 서버 RUS(122)는 해당 AV 라이브 콘텐츠의 각각의 다양한 표현들에 대한 멀티캐스트 서버 MS(121)에 의해 공급된 다양한 멀티캐스트 스트림들을 결합시킴으로써 AV 라이브 콘텐츠의 세그먼트들을 획득한다. 복원 유니캐스트 서버 RUS(122)는 상기 멀티캐스트 스트림의 패킷들을 미리 정의된 수명동안 기억하고 잠재적인 세그먼트 누락들을 보상하기 위해 디-멀티캐스터 DM(150)으로부터 복원 요청들을 서빙한다. 예를 들어, 복원 유니캐스트 서버 RUS(122)는 용이한 데이터 누락 검출을 허용하는 멀티캐스트 서버 MS(121)에 의해 송신된 RTP 패킷들에서의 연속성 카운터(continuity counter)에 기초하여 (표준 문헌 RFC 4588에 정의된 것과 같은) RTP 재시도에 의존함으로써 복원 서비스를 제공한다.
도 4에서, 디-멀티캐스터 DM(150)은 게이트웨이 GW(140)에 내장된다. 이미 언급된 바와 같이, 변형에서 디-멀티캐스터 DM(150)은 LAN(101)의 다른 디바이스에 무작위로 내장될 수 있다.
도 5a 및 도 5b는 도 4에 도시된 AV 라이브 콘텐츠 전달 시스템의 제1 실시형태에서 발생하는 교환을 개략적으로 나타낸다.
도 5a의 단계 500 및 도 5b의 단계 510에서, 플레이어 PL(110)은 도 2a의 단계 200 및 도 2b의 단계 210과 관련하여 이미 설명된 바와 같이 LAN(101)에서 (및/또는 API를 통해) 발견 절차를 수행한다.
컨트롤러 CTRL(130)에 컨택하기 위한 주소를 획득하기 위해, 플레이어 PL(110)은 DNS 서버(161)에 도메인 이름 확인을 요청한다. DNS 서버(161)에 컨택하기 위한 주소는, 플레이어 PL(110)이 게이트웨이 GW(140)에 의해 관리되는 LAN(101)에 성공적으로 등록되었을 때, 플레이어 PL(110)의 게이트웨이 GW(140)에 의해 구성된다. DNS 서버(161)에 컨택하기 위한 주소는 대안적으로 플레이어 PL(110)을 설치할 때 사용자에 의해 수동으로 구성된다. 따라서, 도 5a의 단계 501 및 도 5b의 단계 511에서, 플레이어 PL(110)은 요청 REQ0를 DNS 서버(161)에 송신한다. 요청 REQ0는 플레이어 PL(110)이 타깃으로 하는 AV 라이브 콘텐츠를 식별하는 URL의 FQDN, 즉, 전술한 예의tv.myISP.com의 확인을 요청한다. DNS 서버(161)는 도메인 이름 확인을 수행하고, 이에 따라 제공자 네트워크 PN(102)에서 컨트롤러 CTRL(130)의 주소를 리트리브한다. 예를 들어, 도메인 이름 확인은 아래의 IP 주소: 72.68.18.14로 유도한다.
도 5a의 단계 502 및 도 5b의 단계 512에서, DNS 서버(161)는 응답 메시지 RESP0에 컨트롤러 CTRL(130)의 리트리브된 주소를 플레이어 PL(110)에 반환한다. 플레이어 PL(110)은 이에 따라 컨트롤러 CTRL(130)에 컨택할 수 있다.
도 5a에서, 이후에 수행되는 단계 503 내지 단계 507은 각각 이미 설명된 도 2a의 단계 201 내지 단계 205와 동일하다. 그리고 도 5b에서, 이후에 수행되는 단계 513 내지 단계 516은 각각 이미 설명된 도 2b의 단계 211 내지 단계 214와 동일하다.
디-멀티캐스터 DM(150)이 콘텐츠 전달 장비 CDE(120)로부터 AV 라이브 콘텐츠의 세그먼트들을 획득하는 도 5a의 단계 506을 고려할 때, 디-멀티캐스터 DM(150)은 멀티캐스트 서버 MS(121)에 의해 공급되고 그리고 플레이어 PL(110)에 의해 요청된 AV 라이브 콘텐츠의 표현에 대응하는 멀티캐스트 스트림을 활용한다. 디-멀티캐스터 DM(150)이 세그먼트 누락에 직면하는 경우, 디-멀티캐스터 DM(150)은 AV 라이브 콘텐츠 세그먼트를 플레이어 PL(110)에게 계속적으로 공급하고 이에 따라 수신된 멀티캐스트 스트림에서의 잠재적인 세그먼트 누락에도 불구하고 QoE를 개선시키기 위해 복원 유니캐스트 서버 RUS(122)로부터 해당 누락된 세그먼트를 유니캐스트 형식으로 요청한다. 제공자 네트워크 PN(102)이 게이트웨이 GW(140) 및 LAN(101)으로부터 콘텐츠 전달 장비 CDE(120)로의 상향링크 통신을 구조적으로 허용하기 때문에, 이러한 복원으로부터의 이점은 도 4에 도시된 AV 라이브 콘텐츠 전달 시스템의 제1 실시형태에서 가능하다. 복원 서버 RUS(122)에 의존하는 것은, 전형적으로는 어떠한 재송신 메커니즘도 갖지 않는 전송 프로토콜(예컨대, UDP)을 사용하여 송신된 멀티캐스트 패킷들이 누락되었을 때 특히 유용하다. 세그먼트 누락이 연속적으로 정확하게 수신된 멀티캐스트 패킷들 사이에서의 누락 세그먼트들로 인한 것인 경우, 디-멀티캐스터 DM(150)은 유니캐스트 AV 라이브 콘텐츠 전달 서버로부터 누락 세그먼트들을 요청할 수 있다.
도 6은 AV 라이브 콘텐츠 전달 시스템의 제2 실시형태를 개략적으로 나타내며, 여기서 컨트롤러 CTRL(130)은 또한 게이트웨이 GW(140)에 또는 LAN(101)의 다른 디바이스에 위치된다. 도 6에서, 디-멀티캐스터 DM(150)은 게이트웨이 GW(140)에 내장된다. 이미 언급된 바와 같이, 변형에서 디-멀티캐스터 DM(150)은 LAN(101)의 다른 디바이스에 무작위로 내장될 수 있다. 또한, 도 6에서, 컨트롤러 CTRL(130)은 디-멀티캐스터 DM(150)과 공동-위치, 즉, 게이트웨이 GW(140) 내에 위치된다. 변형에서, 컨트롤러 CTRL(130)은 LAN(101)의 다른 디바이스에 무작위로 내장될 수 있다.
도 6에서는 도메인 이름들을 확인하기 위한 로컬 DNS(LDNS) 서버(162)가 더 나타난다. LDNS 서버(162)는 도 6의 게이트웨이 GW(140) 내에 위치되지만, LAN(101)의 다른 디바이스에 위치될 수 있다. 제공자 네트워크 PN(102)는 브로드캐스트 유형의 네트워크이므로, LAN(101)로부터 또는 게이트웨이 GW(140)로부터의 어떠한 상향링크 통신도 콘텐츠 전달 장비 CDE를 향해 이루어질 수 없다. 따라서, 게이트웨이 GW(140) 및 LAN(101)내의 임의의 다른 디바이스에 의해 액세스가능한 콘텐츠 전달 장비 CDE의 서버들은 오직 멀티캐스트 서버 MS(121)와 같은 멀티캐스트 서버일 수 있으며, 오직 하향링크 통신 전용일 수 있다. 이러한 맥락에서, 브로드캐스트 제공자 네트워크 서버는, 각각의 디-멀티캐스터가 효과적으로 수신하고 프로세스할 AV 콘텐츠 라이브 스트림(예를 들어, TV 채널)을 선택하고, 이에 따라 (브로드캐스트 송신이 모든 디-멀티캐스터들을 동일한 데이터를 수신하도록 유도하기 때문에) 멀티캐스트 송신으로 지칭되는 멀티캐스트 서버로서 간주된다는 점에 유의해야 한다.
도 7은 도 6에 도시된 AV 라이브 콘텐츠 전달 시스템의 제2 실시형태에서 발생하는 교환을 개략적으로 나타낸다.
단계 701에서, 플레이어 PL(110)은 도 2a의 단계 200과 관련하여 이미 설명된 바와 같이 LAN(101)에서(및/또는 API를 통해) 발견 절차를 수행한다.
컨트롤러 CTRL(130)에 컨택하기 위한 주소를 획득하기 위해, 플레이어 PL(110)은 LDNS 서버(162)에 도메인 이름 확인을 요청한다. LDNS 서버(162)에 컨택하기 위한 주소는, 플레이어 PL(110)이 게이트웨이 GW(140)에 의해 관리되는 LAN(101)에 성공적으로 등록되었을 때, 플레이어 PL(110)의 게이트웨이 GW(140)에 의해 구성된다. LDNS 서버(162)에 컨택하기 위한 주소는 대안적으로, 플레이어 PL(110)을 설치할 때, 특히 LDNS 서버(162)가 LAN(101)의 다른 디바이스 내에 위치될 때 사용자에 의해 수동으로 구성된다. 따라서, 단계 702에서, 플레이어 PL(110)은 LDNS 서버(162)에 요청 REQ0를 송신한다. 요청 REQ0는 플레이어 PL(110)이 타깃으로 하는 AV 라이브 콘텐츠를 식별하는 URL의 FQDN, 즉, 전술한 예의 tv.myISP.com의 확인을 요청한다. LDNS 서버(162)는 도메인 이름 확인을 수행하고, 이에 따라 컨트롤러 CTRL(130)의 주소를 리트리브한다. 예를 들어, 도메인 이름 확인은 아래의 IP 주소 및 포트 번호: 192.168.1.100:8001로 유도한다.
LDNS 서버(162)가 도메인 이름 확인을 수행할 수 있고 컨트롤러 CTRL(130)의 주소를 리트리브할 수 있도록 LDNS 서버(162)를 구성하는 것은, 바람직하게는, 디-멀티캐스터 DM(150)이 게이트웨이 GW(140)에 성공적으로 설치될 때, 해당 AV 라이브 콘텐츠의 URL의 FQDN과 컨트롤러 CTRL(130)에 컨택하기 위한 주소 사이의 연관성을 제공하는 구성 메시지 CONF1를 단계 700에서 LDNS 서버(162)에 송신함으로써 디-멀티캐스터 DM(150)에 의해 수행된다. 따라서, 이러한 메시지는, 디-멀티캐스터 DM(150)이 게이트웨이 GW(140)에 의해 호스팅될 때 게이트웨이 GW(140) 내부에 있다. 대안적으로, LDNS 서버(162)는, 디-멀티캐스터 DM(150) 및 컨트롤러 CTRL(130)를 설치할 때 사용자에 의해 수동으로 구성하는 것을 포함하는 임의의 다른 수단에 의해 구성될 수 있다.
디-멀티캐스터 DM(150) 및 컨트롤러 CTRL(130)이 동일한 머신(예를 들어, 게이트웨이 GW(140)) 내에 공동-위치되는 특정 실시형태에서, LDNS 서버(162)에 의해 수행된 도메인 이름 확인은 디-멀티캐스터 DM(150)에 컨택하기 위해 사용된 주소와는 상이한 IP 주소로 유도할 수 있으며, 이는 IP 에일리어싱(IP aliasing)으로 지칭된다. 이는 게이트웨이 GW(140)의 다른 컴포넌트들과의 포트 번호 할당 시에 충돌 해결을 용이하게 하는 데 특히 유용하다.
단계 703에서, LDNS 서버(162)는 응답 메시지 RESP0에 컨트롤러 CTRL(130)의 리트리브된 주소를 플레이어 PL(110)에 반환한다. 플레이어 PL(110)은 이에 따라 컨트롤러 CTRL(130)에 컨택할 수 있다.
디-멀티캐스터 DM(150) 및 컨트롤러 CTRL(130)가 동일한 머신(예를 들어, 게이트웨이 GW(140)) 내에 공동-위치되는 특정 변형 특징에 따르면, 플레이어 PL(110)은 도메인 이름 확인에 의존하지 않고 컨트롤러 CTRL(130)에 컨택하기 위한 주소를 결정한다. 이 상황은, LAN(101)에 어떠한 로컬 DNS 서버도 존재하지 않을 때, 또는 컨트롤러 CTRL(130)이 이러한 로컬 DNS 서버를 구성할 수 없을 때 발생할 수 있다. 이 특정 변형 특징에 따라 플레이어 PL(110)은 컨트롤러 CTRL(130)가 동일한 머신 내에(예를 들어, 게이트웨이 GW(140) 내에) 디-멀티캐스터 DM(150)과 공동-위치되는 구성을 인지한다. 따라서, 발견 절차에서 디-멀티캐스터 DM(150)의 주소를 획득한 후, 컨트롤러 CTRL(130)은 디-멀티캐스터 DM(150)에 할당된 포트 번호에 사전정의된 대체 규칙을 적용함으로써 디-멀티캐스터 DM(150)의 주소로부터 컨트롤러 CTRL(130)의 주소를 도출한다. 예를 들어, 컨트롤러 CTRL(130)은 컨트롤러 CTRL(130)의 주소의 포트 번호를 획득하기 위해 디-멀티캐스터 DM(150)의 주소의 포트 번호를 1 단위로 증분한다.
도 7에서, 이후에 수행되는 단계 704 내지 단계 708은 각각 이미 설명된 도 2a의 단계 201 내지 단계 205와 동일하다. 도 5a와는 반대로, 디-멀티캐스터 DM(150)은, 도 6의 AV 라이브 콘텐츠 전달 시스템의 제2 실시형태의 맥락에서 상향링크 통신을 수행하는 것이 불가능하기 때문에, 단계 707에서의 어떤 유니캐스트 서버로부터도 이점을 얻을 수 없다는 점에 유의해야 한다.
도 8은 AV 라이브 콘텐츠 전달 시스템의 제3 실시형태를 개략적으로 나타내며, 이는 도 4 및 도 6과 관련하여 앞서 설명된 제1 실시형태와 제2 실시형태의 하이브리드 조합이다. 도 8에서, 컨트롤러 CTRL(130)은 또한 게이트웨이 GW(140)에 또는 LAN(101) 내의 다른 디바이스에 위치된다. 도 8에서, 디-멀티캐스터 DM(150)은 게이트웨이 GW(140)에 내장된다. 이미 언급된 바와 같이, 변형에서 디-멀티캐스터 DM(150)은 LAN(101)의 다른 디바이스에 무작위로 내장될 수 있다. 또한, 도 8에서, 컨트롤러 CTRL(130)은 디-멀티캐스터 DM(150)과 공동-위치, 즉, 게이트웨이 GW(140) 내에 위치된다. 변형에서, 컨트롤러 CTRL(130)은 LAN(101)의 다른 디바이스에 무작위로 내장될 수 있다. 그러나, 도 8에서, 제공자 네트워크 PN(102)은 도 4의 제1 실시형태에서와 같이 상향링크 통신을 허용한다. 따라서, 도 6의 콘텐츠 전달 장비 CDE(120)는 멀티캐스터, 또는 멀티캐스트 서버 MS(121)뿐만 아니라 복원 유니캐스트 서버 RUS(122)를 나타낸다.
도 6의 콘텐츠 전달 장비 CDE(120)는 콘텐츠 전달 네트워크 서버 CDNS(123)를 더 포함한다. 서버 CDNS(123)는 콘텐츠 전달 장비 CDE(120)의 멀티캐스트 능력을 인지하지 않고 있고, 예를 들어 AV 라이브 콘텐츠가 유니캐스트 형식으로 요청될 수 있는 제3자 서버이다. 서버 CDNS(123)는 콘텐츠 전달 장비 CDE(120)와는 상이한 권한 도메인에 있을 수 있으며, 이에 따라 콘텐츠 전달 장비 CDE(120)로부터 분리될 수 있다. AV 라이브 콘텐츠 전달을 위해 컨택될 때, 서버 CDNS(123)는 효과적인 AV 라이브 콘텐츠 전달을 위해 제공자 네트워크 PN(102)의 다른 서버로의 리디렉션을 수행할 수 있다는 점에 유의해야 한다. 도 8에는, 각각 도 4 및 도 6에 이미 도시된 DNS 서버(161) 및 LDNS 서버(162)가 더 나타난다. LDNS 서버(162)는 도 8의 게이트웨이 GW(140) 내에 위치되지만, LAN(101)의 다른 디바이스에 위치될 수 있다.
도 9a 및 도 9b는 도 8에 도시된 AV 라이브 콘텐츠 전달 시스템의 제3 실시형태에서 발생하는 교환을 개략적으로 나타낸다.
LDNS 서버(162)는 도 7에 관련되어 이미 설명된 바와 같이 구성된다. 따라서, 디-멀티캐스터 DM(150)은, 플레이어 PL(110)가 도메인 이름 확인에 의해 컨트롤러 CTRL(130)에 컨택하기 위한 주소를 획득할 수 있게 하기 위해, 구성 메시지 CONF1를 통해 단계 900에서 LDNS 서버(162)를 바람직하게 구성할 수 있다. 도 7과 관련하여 설명된 바와 같이, 컨트롤러 CTRL(130) 및 디-멀티캐스터 DM(150)이 동일한 머신에 공동-위치되는 경우, 발견 절차 동안 획득된 디-멀티캐스터 DM(150)의 주소(포트 번호)로부터 컨트롤러 CTRL(130)의 주소(포트 번호)를 도출하는 플레이어 PL(110)에 대한 변형이 구성된다.
도 9a의 단계 901 및 도 9b의 단계 911에서, 플레이어 PL(110)은 도 2a의 단계 200 및 도 2b의 단계 210과 관련하여 이미 설명된 바와 같이 LAN(101)에서 (및/또는 API를 통해) 발견 절차를 수행한다.
도 9a의 단계 902 및 도 9b의 단계 912에서, 플레이어 PL(110)은 요청 REQ0를 LDNS 서버(162)에 송신한다. 요청 REQ0는 플레이어 PL(110)이 타깃으로 하는 AV 라이브 콘텐츠를 식별하는 URL의 FQDN, 즉, 전술한 예의 tv.myISP.com의 확인을 요청한다. LDNS 서버(162)는 도메인 이름 확인을 수행하고, 이에 따라 컨트롤러 CTRL(130)의 주소를 리트리브한다. 예를 들어, 도메인 이름 확인은 아래의 IP 주소 및 포트 번호: 192.168.1.100:8001로 유도한다.
도 9a의 단계 903 및 도 9b의 단계 913에서, LDNS 서버(162)는 응답 메시지 RESP0에서 컨트롤러 CTRL(130)의 리트리브된 주소를 플레이어 PL(110)에 반환한다. 플레이어 PL(110)은 이에 따라 컨트롤러 CTRL(130)에 컨택할 수 있다.
도 9a에서, 이후에 수행되는 단계 904 내지 단계 906은 각각 이미 설명된 도 2a의 단계 201 내지 단계 203과 동일하다.
도 9a에서, 이후에 수행되는 단계 909a 내지 단계 909b는 각각 이미 설명된 도 2a의 단계 204 및 단계 205와 동일하다. 도 7과는 반대로, 디-멀티캐스터 DM(150)은, 도 8의 AV 라이브 콘텐츠 전달 시스템의 제3 실시형태의 맥락에서 상향링크 통신을 수행하는 것이 가능하기 때문에, 단계 909b에서 복원 유니캐스트 서버 RUS(122) 및/또는 서버 CDNS(123)로부터 이점을 얻을 수 있다는 점에 유의해야 한다. 디-멀티캐스터 DM(150)이 서버 CDNS(123)로부터 이점을 얻을 수 있게 하기 위해, 컨트롤러 CTRL(130)는 요청 REQ1에 표시된 것과 같이 플레이어 PL(110)이 타깃으로 하는 AV 라이브 콘텐츠를 식별하는 URL의 FQDN, 즉, 전술한 예의 tv.myISP.com을 제공하는 인라인 파라미터를 리디렉트 메시지 REDIR1에 포함시킨다. 전술한 예에 이어, 리디렉트 메시지 REDIR1는 예를 들어 아래와 같다:
HTTP REDIRECT 192.168.1.100:8000/SportsChannel1.mpd?FQDN_orig= tv.myISP.com&CDN_unicastServer=tv.myISP.com
이는, 서버 CDNS(123)가 컨트롤러 CTRL(130) 및 디-멀티캐스터 DM(150)과 비교하여 제3자에 의해 관리되는 경우에 특히 유용하다. 단계 906에서 요청 REQ2를 수신하는 디-멀티캐스터 DM(150)은 DNS 서버(161)에 의해 도메인 이름 확인을 강제하고 LDNS 서버(162)(만약 존재하는 경우)가 도메인 이름 확인의 타깃이 되는 것을 방지하기 위해 디-멀티캐스터 DM(150)과 동일한 머신에 그와 함께 설치된 DNS 클라이언트 에이전트의 서비스를 사용할 수 있다.
요청 REQ1에 나타난 것과 같이 상기 FQDN을 제공하는 인라인 파라미터로부터, 디-멀티캐스터 DM(150)은 도메인 이름 확인을 요청하고, 이에 따라 메시지 REQ3이 단계(907)에서 송신된다. DNS 서버(161)는 요청 REQ3를 프로세싱하고, 도메인 이름 확인을 수행하여, 이에 따라 서버 CDNS(123)의 주소를 리트리브한다. 예를 들어, 도메인 이름 확인은 아래의 IP 주소: 72.36.53.18로 유도한다. 그후, 단계 908에서, DNS 서버(161)는 응답 메시지 RESP3에 서버 CDNS(123)의 리트리브된 주소를 디-멀티캐스터 DM(150)에 반환한다. 이에 따라, 디-멀티캐스터 DM(150)은 필요할 때(예를 들어, 누락 AV 라이브 콘텐츠 세그먼트를 획득하기 위해) 서버 CDNS(123)에 컨택하기 위한 주소를 동작시킬 수 있다.
도 9b에서, 이후에 수행되는 단계 914는 이미 설명된 도 2b의 단계 211과 동일하다. 여기서, 컨트롤러 CTRL(130)은 플레이어 PL(110)에 의해 요청된 AV 라이브 콘텐츠가 멀티캐스트 형식으로 이용 가능한지 여부를 나타내는 어떠한 정보도 갖지 않는다는 점을 고려한다. 동일한 머신 내에(예를 들어, 게이트웨이 GW(140) 내에) 공동-위치될 때에도, 컨트롤러 CTRL(130) 및 디-멀티캐스터 DM(150)은 서로의 존재에 대해 인지하지 못한다. 이들이 상호작용하는 것이 가능할 수 있지만, 상기 컨트롤러 CTRL(130)는 게이트웨이 GW(140) 내에 또는 제공자 네트워크 PN(102) 내에 위치될 때 다르게 작동하지 않기 때문에, 이들 사이에 밀폐성을 유지하는 것은 컨트롤러 CTRL(130)의 개발을 단순화한다. 그후, 컨트롤러 CTRL(130)은, 플레이어 PL(110)에 의해 요청된 AV 라이브 콘텐츠가 멀티캐스트 형식으로 이용 가능한지 여부를 디-멀티캐스터 DM(150)이 체크하게 한다. 플레이어 PL(110)에 의해 요청된 AV 라이브 콘텐츠가 멀티캐스트 형식으로 이용 가능하면, 도 9a에 도시된 바와 같이 교환이 계속된다. 이용 가능하지 않으면, 디-멀티캐스터 DM(150)은 서버 CDNS(123)으로 플레이어 PL(110)을 리디렉팅할 필요가 있다.
서버 CDNS(123)으로 플레이어 PL(110)을 리디렉팅하기 위해, 디-멀티캐스터 DM(150)은 플레이어 PL(110)이 타깃으로 하는 AV 라이브 콘텐츠를 식별하는 URL의 FQDN의 확인을 요청할 필요가 있다. 사실상, 이전 도메인 이름 확인은 컨트롤러 CTRL(130)로 플레이어 PL(110)을 지향했으며, 이는 무한 루프로 유도될 수 있기 때문에 현재의 상황에서 불편할 수 있다. 따라서, 단계 917에서, 디-멀티캐스터 DM(150)은 요청 REQ3을 DNS 서버(161)에 송신한다. 요청 REQ3은플레이어 PL(110)이 타깃으로 하는 AV 라이브 콘텐츠를 식별하는 URL의 FQDN, 즉, 전술한 예의 tv.myISP.com의 확인을 요청하는데, 이는 단계 915에서 리디렉트 메시지 REDIR1의 인라인 파라미터로서 컨트롤러 CTRL(130)에 의해 제공되었을 필요가 있다. 디-멀티캐스터 DM(150)은 DNS 서버(161)에 의한 확인을 강제하고 LDNS 서버(162)(만약 존재하는 경우)가 도메인 이름 확인의 타깃이 되는 것을 방지하기 위해 디-멀티캐스터 DM(150)과 동일한 머신에 그와 함께 설치된 DNS 클라이언트 에이전트의 서비스를 사용할 수 있다.
DNS 서버(161)는 도메인 이름 확인을 수행하여, 이에 따라 서버 CDNS(123)의 주소를 리트리브한다. 예를 들어, 도메인 이름 확인은 아래의 IP 주소: 72.36.53.18로 유도한다. 그후, 단계 918에서, DNS 서버(161)는 응답 메시지 RESP3에 서버 CDNS(123)의 리트리브된 주소를 디-멀티캐스터 DM(150)에 반환한다. 이에 따라, 디-멀티캐스터 DM(150)은 플레이어 PL(110)에게 서버 CDNS(123)의 주소를 제공할 수 있다.
단계 919에서, 디-멀티캐스터 DM(150)은 요청 REQ2에 응답하여 플레이어 PL(110)에게 리디렉트 메시지 REDIR2를 송신한다. 리디렉트 메시지 REDIR2는 대응 FQDN 대신에 서버 CDNS(123)의 주소를 포함한다. 전술한 예를 계속하면, 리디렉트 메시지 REDIR2는 예를 들어 아래와 같다:
HTTP REDIRECT 72.36.53.18:80/SportsChannel1.mpd
여기서, 서버 CDNS(123)의 IP 주소 뒤에는 디폴트 포트 번호('80')가 이어진다.
단계 920에서, 플레이어 PL(110)은 리디렉트 메시지 REDIR2에 포함된 명령들에 따라 다른 요청 REQ4를 송신한다. 이에 따라, 요청 REQ4는 서버 CDNS(123)로부터 해당 AV 라이브 콘텐츠의 전달을 요청한다. 단계 921에서, 플레이어 PL(110)은 서버 CDNS(123)로부터 유니캐스트 형식으로(즉, 디-멀티캐스터 DM(150)을 통과하지 않고) AV 라이브 콘텐츠를 수신한다.
도 10은 AV 라이브 콘텐츠 전달 시스템의 제4 실시형태를 개략적으로 나타내며, 이는 도 8과 관련하여 앞서 설명된 제3 실시형태로부터 도출된다. 도 10에서, 디-멀티캐스터 DM(150)은 게이트웨이 GW(140)에 내장된다. 이미 언급된 바와 같이, 변형에서 디-멀티캐스터 DM(150)은 LAN(101)의 다른 디바이스에 무작위로 내장될 수 있다. 도 10에서, 컨트롤러 CTRL(130)는 제공자 네트워크 PN(102)에 위치되거나 또는 이에 연결되며, 즉, 플레이어 PL(110)의 관점으로부터 게이트웨이 GW(140)를 넘어서 있다. 도 10에서, LDNS 서버(162)는 게이트웨이 GW(140) 내에 존재하지만, LAN(101)의 다른 디바이스에 위치될 수 있다.
이러한 구성으로 인해 발생되는 문제는, 특히 AV 라이브 콘텐츠가 멀티캐스트 형식으로 이용 가능하지 않은 경우 도메인 이름 확인 시에 발견된다. 플레이어 PL(110)이 타깃으로 하는 AV 라이브 콘텐츠가 멀티캐스트 형식으로 이용 가능한 경우, 컨트롤러 CTRL(130)가 플레이어 PL(110)의 관점으로부터 게이트웨이 GW(140)를 넘어 위치되는 것을 제외하고는, 도 9a와 관련하여 이미 설명된 것과 같이 교환이 실행된다. 따라서, 단순화를 고려하여, 이하에 설명되는 도 11은 오직, 플레이어 PL(110)이 타깃으로 하는 AV 라이브 콘텐츠가 멀티캐스트 형식으로 이용 가능하지 않고, 어쨌든 제공자 네트워크 PN(102)을 통한 어떠한 멀티캐스트 성능에 대해 인지하지 못하는 서버 CDNS(123)로부터 유니캐스트 형식으로 제공되어야만 하는 상황에만 초점이 맞춰져 있다.
도 11은 도 10에 도시된 AV 라이브 콘텐츠 전달 시스템의 제4 실시형태에서 발생하는 교환을 개략적으로 나타낸다.
LDNS 서버(162)는 디-멀티캐스터 DM(150)에 의해 송신된 구성 메시지 CONF1를 통해 구성된다. 이에 따라, LDNS 서버(162)가 도메인 이름 확인을 수행할 수 있고 컨트롤러 CTRL(130)의 주소를 리트리브할 수 있도록 LDNS 서버(162)를 구성하는 것은, 디-멀티캐스터 DM(150)이 게이트웨이 GW(140)에 성공적으로 설치될 때, 플레이어 PL(110)이 타깃으로 하는 AV 라이브 콘텐츠의 URL의 FQDN과 컨트롤러 CTRL(130)에 컨택하기 위한 주소 사이의 연관성을 제공하는 구성 메시지 CONF1를 단계 1110에서 LDNS 서버(162)에 송신함으로써 디-멀티캐스터 DM(150)에 의해 수행된다. 도 7과 관련하여 언급된 바와 같이, 이는 변형에서 수동으로 수행될 수 있다.
단계 1111에서, 플레이어 PL(110)은 도 2a의 단계 200과 관련하여 이미 설명된 바와 같이 LAN(101) 에서 (및/또는 API를 통해) 발견 절차를 수행한다.
단계 1112에서, 플레이어 PL(110)은 LDNS 서버(162)에 요청 REQ0를 송신한다. 요청 REQ0는 플레이어 PL(110)이 타깃으로 하는 AV 라이브 콘텐츠를 식별하는 URL의 FQDN, 즉, 전술한 예의 tv.myISP.com의 확인을 요청한다. LDNS 서버(162)는 도메인 이름 확인을 수행하고, 이에 따라 컨트롤러 CTRL(130)의 주소를 리트리브한다. 예를 들어, 도메인 이름 확인은 아래의 IP 주소: 72.68.18.14로 유도한다.
단계 1113에서, LDNS 서버(162)는 응답 메시지 RESP0에서 컨트롤러 CTRL(130)의 리트리브된 주소를 플레이어 PL(110)에 반환한다. 플레이어 PL(110)은 이에 따라 컨트롤러 CTRL(130)에 컨택할 수 있다.
단계 1114에서, 플레이어 PL(110)은 LDNS 서버(162)로부터 획득된 주소를 사용하여 컨트롤러 CTRL(130)에 요청 REQ1을 송신한다. 요청 REQ1은 이미 설명된 바와 같이 형성된다.
단계 1115에서, 컨트롤러 CTRL(130)는, 플레이어 PL(110)이 타깃으로 하는 AV 라이브 콘텐츠가 멀티캐스트 형식으로 이용 가능한지 여부를 알지 못하고, 요청 REQ1에 응답하여 리디렉트 메시지 REDIR1을 송신한다. 전술한 예를 계속하면, 리디렉트 메시지 REDIR1은 예를 들어 아래와 같다:
HTTP REDIRECT 192.168.1.100:8000/SportsChannel1.mpd?FQDN_orig= tv.myISP.com&CDN_unicastServer=tv.myISP.com
리디렉트 메시지 REDIR1를 수신할 때, 플레이어 PL(110)은 리디렉트 메시지 REDIR1에 따라 단계 1116에서 요청 REQ2를 통해 디-멀티캐스터 DM(150)에 자체 요청을 리디렉팅한다. 플레이어 PL(110)이 타깃으로 하는 AV 라이브 콘텐츠가 멀티캐스트 형식으로 이용 가능하지 않다고 디-멀티캐스터 DM(150)이 인지하고 있음을 고려하면, 디-멀티캐스터 DM(150)은 요청 REQ2에 응답하여 단계 1119에서 리디렉트 메시지 REDIR2를 송신한다.
리디렉트 메시지 REDIR2에서, 디-멀티캐스터 DM(150)은 요청 REQ2의 인라인 파라미터(즉, 전술한 예의 인라인 파라미터 "CDN_unicastServer")로서 제공된 유니캐스트 서버의 주소로 요청 REQ2에 나타난 것과 같은 주소(예를 들어, IP 주소 및 포트 번호)를 대체한다.
플레이어 PL(110)이 타깃으로 하는 AV 라이브 콘텐츠를 식별하는 URL의 FQDN, 즉, tv.myISP.com를 갖는 유니캐스트 서버를 참조하는 것은, 서버 CDNS(123)가 컨트롤러 CTRL(130) 및 디-멀티캐스터 DM(150)과는 상이한 기관에 의해 관리되는 경우에 특히 유용하다는 점에 유의한다. 단계 1116에서 요청 REQ2를 수신하는 디-멀티캐스터 DM(150)은 DNS 서버(161)에 의해 도메인 이름 확인을 강제하고 LDNS 서버(162)(만약 존재하는 경우)가 도메인 이름 확인의 타깃이 되는 것을 방지하기 위해 디-멀티캐스터 DM(150)과 동일한 머신에 그와 함께 설치된 DNS 클라이언트 에이전트의 서비스를 사용할 수 있다.
디-멀티캐스터 DM(150)은 도메인 이름 확인을 요청하고, 이에 따라 메시지 REQ3이 단계 1117에서 송신된다. DNS 서버(161)는 요청 REQ3를 프로세싱하고, 도메인 이름 확인을 수행하여, 이에 따라 서버 CDNS(123)의 주소를 리트리브한다. 예를 들어, 도메인 이름 확인은 아래의 IP 주소: 72.36.53.18로 유도한다. 그후, 단계 1118에서, DNS 서버(161)는 응답 메시지 RESP3에서 서버 CDNS(123)의 리트리브된 주소를 디-멀티캐스터 DM(150)에 반환한다.
다음으로, 디-멀티캐스터 DM(150)은 리디렉트 메시지 REDIR2를 전송한다. 전술한 예를 계속하면, 리디렉트 메시지 REDIR2는 예를 들어 아래와 같다:
HTTP REDIRECT 72.36.53.18:80/SportsChannel1.mpd
리디렉트 메시지 REDIR2를 수신하면, 단계 1120에서, 플레이어 PL(110)은 서버 CDNS(123)에 요청 REQ4을 송신하고, 이에 의해 서버 CDNS(123)로부터 해당 AV 라이브 콘텐츠의 전달을 요청한다. 그후, 단계 1121에서, 플레이어 PL(110)은 서버 CDNS(123)로부터 유니캐스트 형식으로(즉, 디-멀티캐스터 DM(150)을 통과하지 않고) AV 라이브 콘텐츠를 수신한다.

Claims (17)

  1. 타깃 오디오-비주얼 라이브 콘텐츠(targeted audio-visual live content)를 클라이언트(110)에게 전달하기 위한 방법으로서, 상기 방법은,
    - 제공자 네트워크(102)에 대한 액세스를 제공하는 게이트웨이(140)에 의해 상기 제공자 네트워크(102)에 상호연결된 로컬 영역 네트워크(101) 내에 위치되거나 또는 상기 제공자 네트워크(102)에 대한 액세스를 제공하는 상기 게이트웨이(140) 내에 위치된 클라이언트(110);
    - 상기 제공자 네트워크(102)를 통해 멀티캐스트 형식으로 오디오-비주얼 라이브 콘텐츠를 송신하기 위한 멀티캐스터가 포함된 하나 이상의 서버들을 포함하는 오디오-비주얼 라이브 콘텐츠 전달 장비(120);
    - 상기 제공자 네트워크(102)에 대한 액세스를 제공하는 상기 게이트웨이(140) 내의 또는 상기 로컬 영역 네트워크(101)에 위치된 임의의 디바이스 내의 디-멀티캐스터(de-multicaster)(150)로서, 상기 멀티캐스터로부터 멀티캐스트 형식으로 수신되는 오디오-비주얼 라이브 콘텐츠를 유니캐스트 형식으로 변환할 수 있는, 상기 디-멀티캐스터(150);
    - 오디오-비주얼 라이브 콘텐츠를 얻기 위한 요청들의 라우팅을 관리하는 컨트롤러(130)를 포함하는 오디오-비주얼 라이브 콘텐츠 전달 시스템에 의해 수행되며,
    상기 방법은,
    - 상기 클라이언트(110)는 상기 디-멀티캐스터(150)의 잠재적 존재 및 이용 가능성에 관한 정보를, 상기 제공자 네트워크(102)에 대한 액세스를 제공하는 상기 게이트웨이(140) 및 상기 로컬 영역 네트워크(101)에 연결된 임의의 디바이스로부터 수신하는 것을 목표로 하는 발견 절차(200; 210; 500; 510; 701; 901; 911; 1111)를 수행하고;
    상기 클라이언트(110)가 상기 타깃 오디오-비주얼 라이브 콘텐츠를 수신하려고 하는 경우:
    - 상기 클라이언트(110)가 상기 디-멀티캐스터(150)의 존재 및 이용 가능성의 표시, 또는 그 역의 표시를 제공하는 상기 타깃 오디오-비주얼 라이브 콘텐츠를 얻기 위한 요청(201; 211; 503; 513; 704; 904; 914; 1114)을 상기 컨트롤러(130)에게 전송하고;
    - 상기 컨트롤러(130)가, 적어도 상기 디-멀티캐스터(150)의 존재 및 이용 가능성의 표시, 또는 그 역의 표시에 따라, 상기 타깃 오디오-비주얼 라이브 콘텐츠를 얻기 위한 요청을 충족시키기 위해 상기 클라이언트(110)를 리디렉팅하는 방법을 결정하는, 타깃 오디오-비주얼 라이브 콘텐츠를 클라이언트에게 전달하기 위한 방법.
  2. 제1항에 있어서, 상기 디-멀티캐스터(150)의 존재 및 이용 가능성의 표시 또는 그 역의 표시는, 상기 디-멀티캐스터(150)가 존재하고 이용 가능할 때, 상기 타깃 오디오-비주얼 라이브 콘텐츠를 얻기 위한 요청이 상기 발견 절차로부터 초래되는 상기 디-멀티캐스터(150)의 주소를 제공하는 인라인 파라미터를 포함하도록, 상기 타깃 오디오-비주얼 라이브 콘텐츠를 얻기 위한 상기 요청에 함축적으로 제공되는, 타깃 오디오-비주얼 라이브 콘텐츠를 클라이언트에게 전달하기 위한 방법.
  3. 제1항 또는 제2항에 있어서, 상기 제공자 네트워크(102)는 상기 제공자 네트워크(102)를 통한 상기 게이트웨이(140) 및 상기 로컬 영역 네트워크(101)로부터의 상향링크 통신을 가능하게 하고, 상기 컨트롤러(130)는 상기 제공자 네트워크(102) 상에 위치되며, 상기 컨트롤러(130)가 상기 클라이언트(110)가 변환으로부터 이점을 누릴 수 없음을 결정하고 그렇지 않으면 상기 디-멀티캐스터(150)로 상기 클라이언트(110)를 리디렉팅할 때 상기 컨트롤러(130)는 상기 오디오-비주얼 라이브 콘텐츠 전달 장비의 유니캐스트 서버(123)로 상기 클라이언트(110)를 리디렉팅하는, 타깃 오디오-비주얼 라이브 콘텐츠를 클라이언트에게 전달하기 위한 방법.
  4. 제3항에 있어서, 상기 클라이언트는 상기 제공자 네트워크(102) 내에 위치된 도메인 이름 서버(161)에 도메인 이름 확인을 요청함으로써 상기 컨트롤러(130)에 컨택하기 위한 주소를 결정하고, 상기 도메인 이름 확인은 상기 타깃 오디오-비주얼 라이브 콘텐츠를 식별하는 단일 리소스 로케이터(uniform resource locator)에 포함된 전체 주소 도메인 이름(fully qualified domain name)에 관한 것인, 타깃 오디오-비주얼 라이브 콘텐츠를 클라이언트에게 전달하기 위한 방법.
  5. 제3항 또는 제4항에 있어서, 상기 디-멀티캐스터(150)는 상기 멀티캐스터(121)로부터 상기 타깃 오디오-비주얼 라이브 콘텐츠를 수신하는 상기 오디오-비주얼 라이브 콘텐츠 전달 장비(120)의 복원 유니캐스트 서버(repair unicast server)(122)로부터, 멀티캐스트 형식으로 누락된 상기 타깃 오디오-비주얼 라이브 콘텐츠의 세그먼트들을 리트리브(retrieve)하는, 타깃 오디오-비주얼 라이브 콘텐츠를 클라이언트에게 전달하기 위한 방법.
  6. 제3항 내지 제5항 중 어느 한 항에 있어서, 상기 디-멀티캐스터(150)로 상기 클라이언트(110)를 리디렉팅할 때, 상기 컨트롤러(130)는 상기 타깃 오디오-비주얼 라이브 콘텐츠를 얻기 위한 요청에 표시되었고 상기 타깃 오디오-비주얼 라이브 콘텐츠를 식별하는 단일 리소스 로케이터에 포함된 상기 전체 주소 도메인 이름을 제공하는 인라인 파라미터를 포함하는 리디렉트 메시지를 송신하고, 상기 디-멀티캐스터(150)가 상기 클라이언트(110)가 상기 변환으로부터 이점을 누릴 수 없음을 결정할 때 상기 디-멀티캐스터(150)는 상기 제공자 네트워크(102) 상에서 유니캐스트 서버로 상기 클라이언트(110)를 리디렉팅하며, 상기 디-멀티캐스터(150)는 상기 전체 주소 도메인 이름을 제공하는 상기 인라인 파라미터를 사용하여 상기 제공자 네트워크(102)에 위치된 도메인 이름 서버(161)에 도메인 이름 확인을 요청함으로써 상기 유니캐스트 서버의 주소를 결정하는, 타깃 오디오-비주얼 라이브 콘텐츠를 클라이언트에게 전달하기 위한 방법.
  7. 제1항 또는 제2항에 있어서, 상기 제공자 네트워크(102)는 상기 제공자 네트워크(102)를 통한 상기 게이트웨이(140) 및 상기 로컬 영역 네트워크(101)로부터의 상향링크 통신을 가능하게 하고, 상기 컨트롤러(130)는 상기 게이트웨이(140) 내에 또는 상기 로컬 영역 네트워크(101) 내에 위치되고, 상기 컨트롤러(130)가 상기 클라이언트(110)가 상기 변환으로부터 이점을 누릴 수 없음을 결정하고 달리 상기 디-멀티캐스터(150)로 상기 클라이언트를 리디렉팅할 때 상기 컨트롤러(140)는 상기 제공자 네트워크(102) 상의 멀티캐스트 비-인지 유니캐스트 서버로 상기 클라이언트(110)를 리디렉팅하는, 타깃 오디오-비주얼 라이브 콘텐츠를 클라이언트에게 전달하기 위한 방법.
  8. 제7항에 있어서, 상기 클라이언트(110)는 상기 게이트웨이(140) 내에 또는 상기 로컬 영역 네트워크(101) 내에 위치된 로컬 도메인 이름 서버(162)에 도메인 이름 확인을 요청함으로써 상기 컨트롤러(130)에 컨택하기 위한 주소를 결정하고, 상기 도메인 이름 확인은 상기 타깃 오디오-비주얼 라이브 콘텐츠를 식별하는 단일 리소스 로케이터에 포함된 전체 주소 도메인 이름에 관한 것인, 타깃 오디오-비주얼 라이브 콘텐츠를 클라이언트에게 전달하기 위한 방법.
  9. 제8항에 있어서, 상기 컨트롤러(130)는 상기 컨트롤러(130)의 주소와 상기 전체 주소 도메인 이름을 연관시키기 위해 상기 로컬 도메인 이름 서버(162)를 이전에 구성한, 타깃 오디오-비주얼 라이브 콘텐츠를 클라이언트에게 전달하기 위한 방법.
  10. 제7항에 있어서, 상기 컨트롤러(130) 및 상기 디-멀티캐스터(150)는 동일한 머신 내에 공동-위치되고, 상기 클라이언트(110)는 상기 발견 절차로부터 초래되는 상기 디-멀티캐스터(150)에 컨택하기 위한 주소로부터 상기 컨트롤러(130)에 컨택하기 위한 주소를 도출시킴으로써 상기 컨트롤러(130)에 컨택하기 위한 상기 주소를 결정하는, 타깃 오디오-비주얼 라이브 콘텐츠를 클라이언트에게 전달하기 위한 방법.
  11. 제8항 내지 제10항 중 어느 한 항에 있어서, 상기 디-멀티캐스터(150)는 상기 멀티캐스터(121)로부터 상기 타깃 오디오-비주얼 라이브 콘텐츠를 수신하는 상기 오디오-비주얼 라이브 콘텐츠 전달 장비(120)의 복원 유니캐스트 서버(122)로부터, 멀티캐스트 형식으로 누락된 상기 타깃 오디오-비주얼 라이브 콘텐츠의 세그먼트들을 리트리브하는, 타깃 오디오-비주얼 라이브 콘텐츠를 클라이언트에게 전달하기 위한 방법.
  12. 제8항 내지 제11항 중 어느 한 항에 있어서, 상기 디-멀티캐스터(150)로 상기 클라이언트(110)를 리디렉팅할 때, 상기 컨트롤러(130)는 상기 타깃 오디오-비주얼 라이브 콘텐츠를 얻기 위한 요청에 표시되었고 상기 타깃 오디오-비주얼 라이브 콘텐츠를 식별하는 단일 리소스 로케이터에 포함된 상기 전체 주소 도메인 이름을 제공하는 인라인 파라미터를 포함하는 리디렉트 메시지를 송신하고, 상기 디-멀티캐스터(150)가 상기 클라이언트(110)가 상기 변환으로부터 이점을 누릴 수 없음을 결정할 때 상기 디-멀티캐스터(150)는 상기 제공자 네트워크(102) 상에서 멀티캐스트 비-인지 유니캐스트 서버로 상기 클라이언트(110)를 리디렉팅하며, 상기 디-멀티캐스터(150)는 상기 전체 주소 도메인 이름을 제공하는 상기 인라인 파라미터를 사용하여 상기 제공자 네트워크(102)에 위치된 도메인 이름 서버(161)에 도메인 이름 확인을 요청함으로써 상기 멀티캐스트 비-인지 유니캐스트 서버의 주소를 결정하는, 타깃 오디오-비주얼 라이브 콘텐츠를 클라이언트에게 전달하기 위한 방법.
  13. 제1항 또는 제2항에 있어서, 상기 제공자 네트워크(102)는 상기 제공자 네트워크(102)를 통한 상기 게이트웨이(140) 및 상기 로컬 영역 네트워크(101)로부터의 상향링크 통신을 가능하게 하지 않고, 상기 컨트롤러(130)는 상기 게이트웨이(140) 내에 또는 상기 로컬 영역 네트워크(101) 내에 위치되고, 상기 컨트롤러(130)가 상기 클라이언트(110)가 상기 변환으로부터 이점을 누릴 수 없음을 결정하고 달리 상기 디-멀티캐스터(150)로 상기 클라이언트를 리디렉팅할 때 상기 컨트롤러(130)는 상기 타깃 오디오-비주얼 라이브 콘텐츠를 얻기 위한 요청을 거절하는, 타깃 오디오-비주얼 라이브 콘텐츠를 클라이언트에게 전달하기 위한 방법.
  14. 제13항에 있어서, 상기 클라이언트는 상기 게이트웨이(140) 내에 또는 상기 로컬 영역 네트워크(101) 내에 위치된 로컬 도메인 이름 서버(162)에 도메인 이름 확인을 요청함으로써 상기 컨트롤러(130)에 컨택하기 위한 주소를 결정하고, 상기 도메인 이름 확인은 상기 타깃 오디오-비주얼 라이브 콘텐츠를 식별하는 단일 리소스 로케이터에 포함된 전체 주소 도메인 이름에 관한 것인, 타깃 오디오-비주얼 라이브 콘텐츠를 클라이언트에게 전달하기 위한 방법.
  15. 제14항에 있어서, 상기 디-멀티캐스터(150)는 상기 컨트롤러(130)의 주소와 상기 전체 주소 도메인 이름을 연관시키기 위해 상기 로컬 도메인 이름 서버(162)를 이전에 구성한, 타깃 오디오-비주얼 라이브 콘텐츠를 클라이언트에게 전달하기 위한 방법.
  16. 제13항에 있어서, 상기 컨트롤러(130) 및 상기 디-멀티캐스터(150)는 동일한 머신 내에 공동-위치되고, 상기 클라이언트(110)는 상기 발견 절차로부터 초래되는 상기 디-멀티캐스터(150)에 컨택하기 위한 주소로부터 상기 컨트롤러(130)에 컨택하기 위한 주소를 도출시킴으로써 상기 컨트롤러(130)에 컨택하기 위한 상기 주소를 결정하는, 타깃 오디오-비주얼 라이브 콘텐츠를 클라이언트에게 전달하기 위한 방법.
  17. 오디오-비주얼 라이브 콘텐츠 전달 시스템으로서,
    - 제공자 네트워크(102)에 대한 액세스를 제공하는 게이트웨이(140)에 의해 상기 제공자 네트워크(102)에 상호연결된 로컬 영역 네트워크(101) 내에 위치되거나 또는 상기 제공자 네트워크(102)에 대한 액세스를 제공하는 상기 게이트웨이(140) 내에 위치된 클라이언트(110);
    - 상기 제공자 네트워크(102)를 통해 멀티캐스트 형식으로 오디오-비주얼 라이브 콘텐츠를 송신하기 위한 멀티캐스터가 포함된 하나 이상의 서버들을 포함하는 오디오-비주얼 라이브 콘텐츠 전달 장비(120);
    - 상기 제공자 네트워크(102)에 대한 액세스를 제공하는 상기 게이트웨이(140) 내의 또는 상기 로컬 영역 네트워크(101)에 위치된 임의의 디바이스 내의 디-멀티캐스터(150) - 상기 디-멀티캐스터(150)는 상기 멀티캐스터로부터 멀티캐스트 형식으로 수신되는 오디오-비주얼 라이브 콘텐츠를 유니캐스트 형식으로 변환할 수 있음 -;
    - 오디오-비주얼 라이브 콘텐츠를 얻기 위한 요청들의 라우팅을 관리하는 컨트롤러(130)를 포함하고,
    상기 시스템은,
    - 상기 클라이언트(110)가 상기 디-멀티캐스터(150)의 잠재적 존재 및 이용 가능성에 관한 정보를, 상기 제공자 네트워크(102)에 대한 액세스를 제공하는 상기 게이트웨이(140) 및 상기 로컬 영역 네트워크(101)에 연결된 임의의 디바이스로부터 수신하는 것을 목표로 하는 발견 절차(200; 210; 500; 510; 701; 901; 911; 1111)를 수행하기 위한 수단을 포함하고;
    - 상기 클라이언트(110)가 상기 타깃 오디오-비주얼 라이브 콘텐츠를 수신하려고 할 때, 상기 클라이언트(110)는 상기 디-멀티캐스터(150)의 존재 및 이용 가능성의 표시, 또는 그 역의 표시를 제공하는 상기 타깃 오디오-비주얼 라이브 콘텐츠를 얻기 위한 요청을 상기 컨트롤러(130)에게 전송하기 위한 수단(201; 211; 503; 513; 704; 904; 914; 1114)을 포함하고;
    - 상기 컨트롤러(130)가, 적어도 상기 디-멀티캐스터(150)의 존재 및 이용 가능성의 표시, 또는 그 역의 표시에 따라, 상기 타깃 오디오-비주얼 라이브 콘텐츠를 얻기 위한 요청을 충족시키기 위해 상기 클라이언트(110)를 리디렉팅하는 방법을 결정하는, 오디오-비주얼 라이브 콘텐츠 전달 시스템.
KR1020217019969A 2018-11-28 2018-11-28 오디오-비주얼 라이브 콘텐츠 전달을 위한 방법 및 시스템 KR102506107B1 (ko)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IB2018/001488 WO2020109834A1 (en) 2018-11-28 2018-11-28 Method and system for audio-visual live content delivery

Publications (2)

Publication Number Publication Date
KR20210119957A true KR20210119957A (ko) 2021-10-06
KR102506107B1 KR102506107B1 (ko) 2023-03-03

Family

ID=65033620

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020217019969A KR102506107B1 (ko) 2018-11-28 2018-11-28 오디오-비주얼 라이브 콘텐츠 전달을 위한 방법 및 시스템

Country Status (15)

Country Link
US (1) US20210314631A1 (ko)
EP (1) EP3888316B1 (ko)
JP (1) JP7312828B2 (ko)
KR (1) KR102506107B1 (ko)
CN (1) CN113287283B (ko)
BR (1) BR112021010392A2 (ko)
CA (1) CA3121298A1 (ko)
DK (1) DK3888316T3 (ko)
ES (1) ES2965183T3 (ko)
HR (1) HRP20231623T1 (ko)
MX (1) MX2021006191A (ko)
PL (1) PL3888316T3 (ko)
PT (1) PT3888316T (ko)
SG (1) SG11202105599PA (ko)
WO (1) WO2020109834A1 (ko)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11445000B2 (en) * 2018-11-30 2022-09-13 British Telecommunications Public Limited Company Multicast to unicast conversion
CN110730053A (zh) * 2019-09-09 2020-01-24 晶晨半导体（深圳）有限公司 一种基于ts格式和udp传输方式的网络丢包重传方法
CN113840151A (zh) * 2020-06-24 2021-12-24 中国电信股份有限公司 Ott组播网关调度方法、装置和系统、存储介质
EP4175259A1 (en) * 2020-06-30 2023-05-03 LG Electronics, Inc. Method and apparatus for processing multicast signal
EP4002857A1 (en) * 2020-11-13 2022-05-25 Broadpeak Method and system for customized audio and/or video content delivery
CN114286125B (zh) * 2021-12-30 2023-12-19 北京爱学习博乐教育科技有限公司 企业直播实现方法及系统
FR3140233A1 (fr) * 2022-09-28 2024-03-29 Orange Procédés et dispositifs de configuration d’un module DNS et de résolution d’adresse pour gérer la diffusion de flux de contenus multimédias dans un réseau de télécommunications

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020143951A1 (en) * 2001-03-30 2002-10-03 Eyeball.Com Network Inc. Method and system for multicast to unicast bridging
KR20090035492A (ko) * 2006-06-27 2009-04-09 톰슨 라이센싱 신뢰적 멀티캐스트 데이터 전송을 위한 방법 및 장치
KR20150079557A (ko) * 2012-08-27 2015-07-08 브로드피크 클라이언트 장치에 시청각 컨텐츠를 전달하는 시스템 및 방법
KR20160026712A (ko) * 2014-09-01 2016-03-09 캐논 가부시끼가이샤 통신장치와 통신장치의 제어방법

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8528015B2 (en) * 2003-11-06 2013-09-03 Aptiv Digital, Inc. Resource sharing system of set-top boxes
US8145711B2 (en) * 2008-11-05 2012-03-27 At&T Intellectual Property I, L.P. Multi-player game data via multicast transmission
US9185004B2 (en) * 2010-12-29 2015-11-10 Comcast Cable Communications, Llc Quality of service for distribution of content to network devices
FR2981530B1 (fr) 2011-10-12 2013-12-06 Broadpeak Passerelle, et procede, programme d'ordinateur et moyens de stockage correspondants
US9402107B2 (en) * 2013-03-15 2016-07-26 Time Warner Cable Enterprises Llc Apparatus and methods for delivery of multicast and unicast content in a content delivery network
US9716763B2 (en) * 2015-05-13 2017-07-25 Arris Enterprises Llc Content streaming apparatus for transferring a streaming session to another apparatus
US10193994B2 (en) * 2015-06-18 2019-01-29 Qualcomm Incorporated Signaling cached segments for broadcast

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020143951A1 (en) * 2001-03-30 2002-10-03 Eyeball.Com Network Inc. Method and system for multicast to unicast bridging
KR20090035492A (ko) * 2006-06-27 2009-04-09 톰슨 라이센싱 신뢰적 멀티캐스트 데이터 전송을 위한 방법 및 장치
KR20150079557A (ko) * 2012-08-27 2015-07-08 브로드피크 클라이언트 장치에 시청각 컨텐츠를 전달하는 시스템 및 방법
KR20160026712A (ko) * 2014-09-01 2016-03-09 캐논 가부시끼가이샤 통신장치와 통신장치의 제어방법

Also Published As

Publication number Publication date
MX2021006191A (es) 2021-09-08
DK3888316T3 (da) 2023-11-27
ES2965183T3 (es) 2024-04-11
US20210314631A1 (en) 2021-10-07
CN113287283B (zh) 2024-03-08
SG11202105599PA (en) 2021-06-29
PT3888316T (pt) 2023-11-16
EP3888316B1 (en) 2023-09-13
JP7312828B2 (ja) 2023-07-21
JP2022518107A (ja) 2022-03-14
WO2020109834A1 (en) 2020-06-04
BR112021010392A2 (pt) 2021-08-24
HRP20231623T1 (hr) 2024-03-15
EP3888316A1 (en) 2021-10-06
CA3121298A1 (en) 2020-06-04
PL3888316T3 (pl) 2024-03-18
CN113287283A (zh) 2021-08-20
KR102506107B1 (ko) 2023-03-03

Similar Documents

Publication Publication Date Title
KR102506107B1 (ko) 오디오-비주얼 라이브 콘텐츠 전달을 위한 방법 및 시스템
KR102110421B1 (ko) 클라이언트 장치에 시청각 컨텐츠를 전달하는 시스템 및 방법
EP2897340B1 (en) Routing proxy for adaptive streaming
JP6278531B2 (ja) ハイブリッドｈｔｔｐ及びｕｄｐコンテンツ配信
US20130114597A1 (en) Proxy server, relay method, communication system, relay control program, and recording medium
US20230275949A1 (en) Method and apparatus for processing multicast signal
US20170222973A1 (en) Improved QOS in Data Stream Delivery
US20130290517A1 (en) Nat traversal under tcp for real time streaming protocol
US20170180439A1 (en) Methods and devices for responding to a streaming request, access node and method for operating the same
US20240121123A1 (en) Multicast signal processing method and device
RU2621961C2 (ru) Шлюз и соответствующие ему способ, компьютерная программа и носитель информации
US20150074234A1 (en) Content system and method for chunk-based content delivery
EP3370394A1 (fr) Dispositif d&#39;accès à adressage multiple
RU2791242C2 (ru) Способ и система доставки аудиовизуального контента в режиме реального времени
Hammershøj et al. The Next-Generation Television Broadcasting Test Platform in Copenhagen
KR20220116201A (ko) 재생기에 오디오 및/또는 비디오 콘텐츠를 전달하기 위한 방법
CN117459747A (zh) 一种数据传输方法以及装置

Legal Events

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