KR102119287B1 - 이용가능한 대역폭에 따라 전송 프로토콜을 선택함으로써 콘텐츠를 획득하는 장치 - Google Patents

이용가능한 대역폭에 따라 전송 프로토콜을 선택함으로써 콘텐츠를 획득하는 장치 Download PDF

Info

Publication number
KR102119287B1
KR102119287B1 KR1020147017712A KR20147017712A KR102119287B1 KR 102119287 B1 KR102119287 B1 KR 102119287B1 KR 1020147017712 A KR1020147017712 A KR 1020147017712A KR 20147017712 A KR20147017712 A KR 20147017712A KR 102119287 B1 KR102119287 B1 KR 102119287B1
Authority
KR
South Korea
Prior art keywords
content
transmission
transport protocol
version
protocol
Prior art date
Application number
KR1020147017712A
Other languages
English (en)
Other versions
KR20140099924A (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 KR20140099924A publication Critical patent/KR20140099924A/ko
Application granted granted Critical
Publication of KR102119287B1 publication Critical patent/KR102119287B1/ko

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/101Server selection for load balancing based on network conditions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/19Flow control; Congestion control at layers above the network layer
    • H04L47/196Integration of transport layer protocols, e.g. TCP and UDP
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823Errors, e.g. transmission errors
    • H04L43/0829Packet loss
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/38Flow control; Congestion control by adapting coding or compression rate
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/165Combined use of TCP and UDP protocols; selection criteria therefor
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Communication Control (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

이용가능한 네트워크 대역폭에 있어서 상이한 요구사항을 갖는 적어도 2개의 송신 프로토콜에 의해 콘텐츠를 획득하는 장치(D)가 의도된다. 이러한 콘텐츠는 적어도 하나의 콘텐츠 서버(SC) 상에서 상이한 버전에서 이용가능하고, 버전은 상이한 송신 바이너리 비트 레이트에 대응하고 통신 네트워크(N)를 통해 송신되도록 구성된 청크(chunk)로 세분된다. 이 장치(D)는 콘텐츠의 버전의 적어도 하나의 요구되는 다음 청크를 송신하기 위해 서버에 의해 주어진 시간에 사용되어야 하는 전송 프로토콜을 선택하도록 구성되고, 선택된 전송 프로토콜은 통신 네트워크(N)의 이용가능한 대역폭의 현재 값이 제1 임계값보다 엄격히 크면 제1 전송 프로토콜을 포함하거나 대역폭의 현재 값이 상기 제1 임계값보다 작거나 같으면 제2 전송 프로토콜을 포함한다. 장치(D)는 상기 선택된 전송 프로토콜에 의해 콘텐츠의 버전의 적어도 하나의 요구되는 다음 청크를 송신하라는 요청을 콘텐츠 서버(SC)로 전송하도록 더 구성된다.

Description

이용가능한 대역폭에 따라 전송 프로토콜을 선택함으로써 콘텐츠를 획득하는 장치{DEVICE FOR OBTAINING CONTENT BY CHOOSING THE TRANSPORT PROTOCOL ACCORDING TO THE AVAILABLE BANDWIDTH}
본 발명은 콘텐츠가 스트리밍 모드 또는 풀 파일 다운로드 모드(full file download mode)인지에 따른 콘텐츠 송신에 관한 것이다.
스트리밍은, 스트리밍으로 실시간으로 콘텐츠의 청크(chunk)(또는 일부 - 마이크로 파일)를 사용하기 위하여 콘텐츠의 청크를 통신 네트워크(유선 또는 무선)를 통해 적어도 하나의 콘텐츠 수신기로 연속적으로 송신하는 것을 포함한다. 첫번째 타입의 송신은 상이한 스트리밍 프로토콜, 예를 들어, UDP에 대한 RTP 또는 MPEG-TS, HTTP 스트리밍 또는 더 최근의 HTTP 적응 스트리밍에 의해 수행된다. 풀 파일 다운로드는 플레이할 수 있게 하기 위하여 파일의 전부 또는 일부를 수신할 것을 요구한다. 이 제2 송신 타입은 일반적으로 TCP 프로토콜에 대한 http에 의한다.
"콘텐츠"는 파일(멀티미디어, 게임, 문서)의 형태로 요청에 의해 전달가능한 텔레비전 프로그램(비디오 및 오디오), 게임 또는 문서를 정의하는 데이터의 세트이다.
당업자는, 데이터 송신 비트 레이트가 때때로 의미있고 및/또는 지속적인 방식으로 통신 네트워크 내에서 요동할 수 있으며, 콘텐츠 수신기의 레벨에서 수신된 콘텐츠의 영상 및/또는 음향의 회복 품질의 변화를 유도할 수 있는 파라미터라는 것을 알고 있다. 실로, 통신 네트워크에 의해 주어진 시간에 제공된 대역폭이 데이터 송신 비트 레이트와 일시적으로 양립할 수 없으면, 이 콘텐츠의 데이터의 일부가 요구측 콘텐츠 수신기에 의해 수신될 수 없을 것이고, 따라서, 콘텐츠 수신기는 기껏해야 일시적으로 저하된 품질의 영상 및/또는 음향을 회복할 수 있고 최악의 경우 어떤 것도 회복하지 못할 수 있다.
상술한 요동의 결과를 제한하기 위하여, 동일한 콘텐츠로부터 상이한 송신 비트 레이트에 대응하는 몇 개의 상이한 버전을 생성하는 것이 제안되었다. 그러므로, 통신 네트워크에 접속된 콘텐츠 수신기가 통신 네트워크를 통해 콘텐츠를 회복하기를 원할 때, 그것은, 선택된 시간에 이 통신 네트워크에 의해 제공된 조건에 가장 잘 적응된 콘텐츠 버전을 각 선택된 시간에서 필요로 하여 정지 영상(frozen image)을 방지한다. 불행하게도, 상당한 요동 환경에서, 이 솔루션은 낮은 송신 비트 레이트에 가장 빈번히 대응하는 버전에서 청크(chunk)의 송신을 증가시켜 사용자가 경험하는 일반적인 품질을 저하시킨다. 이러한 상황을 개선하기 위하여, 송신 비트 레이트를 선택하는 알고리즘의 더 엄격한 제어를 도입할 수 있다. 그러나, 이것은 콘텐츠 수신기가 그 전송 프로토콜의 원리에 의해 제한되어 하나 이상의 동시 애플리케이션(예를 들어, 다운로딩 또는 브라우징)과 통신 네트워크의 대역폭을 공유할 때 상황을 개선할 수 없다.
발명의 개요
따라서, 본 발명은 상황, 특히 통신 네트워크 내에서 송신 조건이 요동할 때의 사용자의 경험을 개선하기 위한 것이다.
이 목적으로, 본 발명은 적어도 서버(SC) 상에서 상이한 버전들로 이용가능한 콘텐츠를 얻도록 의도된 장치를 제안하고, 상이한 버전들은 상이한 송신 바이너리 비트 레이트에 대응하고 이용가능한 네트워크 대역폭에 있어서 상이한 요구사항들을 갖는 적어도 2개의 전송 프로토콜에 의해 통신 네트워크를 통해 송신되도록 적응된 청크들로 세분된다.
이 장치는 획득측 장치에 콘텐츠의 버전의 적어도 하나의 요구되는 다음 청크를 송신하기 위해 적어도 하나의 서버에 의해 주어진 시간에 사용되어야 하는 전송 프로토콜을 선택하도록 구성된다는 점에서 특징이 있다. 전송 프로토콜의 선택은 통신 네트워크의 이용가능한 대역폭의 현재 값이 제1 임계값보다 엄격히 크면 제1 전송 프로토콜을, 상기 대역폭의 현재 값이 상기 제1 임계값보다 작거나 같으면 (이용가능한 네트워크 대역폭에 있어서 제1 전송 프로토콜보다 더 적은 요구사항을 갖는) 제2 전송 프로토콜을 포함한다. 이 장치는 또한 선택된 전송 프로토콜에 의해 콘텐츠의 버전의 적어도 하나의 요구되는 다음 청크를 송신하라는 요청을 상기 적어도 하나의 서버에 전송하도록 구성된다.
본 발명에 따른 장치는 개별적으로 또는 조합하여 취할 수 있는 다음의 다른 특징을 포함할 수 있다:
- 콘텐츠의 선명도의 요구 레벨에 맞는 콘텐츠의 요구되는 버전에 따라 상기 제1 임계값을 선택하도록 구성될 수 있다.
- 패킷 손실 레이트의 현재 값을 분석하도록 구성될 수 있다. 이 경우, 제1 송신 비트 레이트에 대응하는 버전의 청크의 송신을 위해 제2 전송 프로토콜을 선택한 경우, 상기 패킷 손실 레이트의 현재 값이 엄격히 제2 임계값보다 크면, 제1 송신 비트 레이트보다 낮은 제2 송신 비트 레이트에 대응하는 다른 버전의 동일한 청크의 송신을 요청할 수 있다.
- 전송 프로토콜을 선택하고, 획득할 콘텐츠의 송신 동안 복수의 주어진 시간에 요청을 상기 적어도 하나의 서버로 전송하도록 구성되며, 따라서 전체 콘텐츠의 송신 동안 적응될 수 있다.
- 타임 슬롯 상에서 상기 제1 및 제2 전송 프로토콜의 사용의 미리 정의된 분포에 따라 더 사용되어야 하는 전송 프로토콜을 각각의 주어진 시간에 선택하도록 구성될 수 있다.
> 타임 슬롯은 슬라이딩일 수 있다.
> 타임 슬롯 상에서 상기 제1 및 제2 전송 프로토콜의 75%/25%의 미리 정의된 분포를 이용하도록 구성될 수 있다.
- 버전의 청크의 송신을 위해 제2 전송 프로토콜이 선택된 경우, 제1 전송 프로토콜에 의해 이 버전으로부터 수신되지 않은 데이터 패킷들의 재송신 메카니즘을 트리거하도록 구성될 수 있다.
> 재송신에 전용인 콘텐츠 서버로부터의 데이터 패킷들의 각 재송신을 요청하도록 구성될 수 있다.
- 제1 전송 프로토콜은 TCP이고 제2 전송 프로토콜은 UDP일 수 있다.
- 주어진 시간에 상기 제2 전송 프로토콜을 선택하는 경우, 이 주어진 시간에 대역폭의 현재 값에 가장 가까운 값을 갖는 송신 비트 레이트에 대응하는 콘텐츠 버전을 선택하도록 구성될 수 있다.
- 획득하고 싶어하는 콘텐츠의 버전들에 대응하여 저장되고 그들 각자의 송신 비트 레이트들을 기술하는 기술 파일(description file)을 복구하여, 전송 프로토콜의 제1 선택을 수행하여 이 콘텐츠를 획득하도록 구성될 수 있다.
- 스트리밍 모드 또는 풀 파일 다운로드 모드로 콘텐츠의 송신을 획득하도록 구성될 수 있다.
본 발명은 또한 상술한 타입의 콘텐츠를 획득하는 장치를 포함하는 콘텐츠 수신기를 제안한다.
이러한 콘텐츠 수신기는 예를 들어, 셋탑 박스 타입의 박스, 디코더, 가정용 또는 홈 게이트웨이, 고정 컴퓨터 또는 랩탑, 모바일 폰, 개인 휴대 단말기, 또는 전자 태블릿의 형태로 제시될 수 있다.
본 발명은 또한 콘텐츠를 획득하는 장치에 의해 수행되는 단계를 구현하는 콘텐츠를 획득하는 방법을 제안한다. 콘텐츠를 획득하는 장치에 대하여 상술한 특징은 콘텐츠를 획득하는 방법에서 임의의 조합으로 사용될 수 있다.
본 발명의 다른 특징 및 이점은 이하의 상세한 설명 및 첨부된 도면을 검토할 때 명백해질 것이다.
도 1은 본 발명의 실시예에 따라 콘텐츠를 획득하는 장치가 구비된 콘텐츠 수신기 및 3개의 콘텐츠 서버가 접속된 통신 네트워크를 기능적으로 및 도표로 나타내는 도면.
도 2는 4개의 상이한 송신 비트 레이트에 각각 대응하는 동일 콘텐츠의 4개의 상이한 버전을 도표로 나타내는 도면.
도 3은 통신 네트워크의 대역폭(BW)의 시간 변화(t)의 제1 예, 및 이 시간 변화의 제1 예의 존재시에, 제1 방식으로 구성된 본 발명의 실시예에 따라 콘텐츠를 획득하는 장치로 송신된 콘텐츠의 청크들의 제1 예를 도표로 나타내는 도면.
도 4는 통신 네트워크의 대역폭(BW)의 시간 변화(t)의 제2 예, 및 이 시간 변화의 제2 예의 존재시에, 제2 방식으로 구성된 본 발명의 실시예에 따라 콘텐츠를 획득하는 장치로 송신된 콘텐츠의 청크들의 제2 예를 도표로 나타내는 도면.
첨부된 도면은 본 발명을 완벽하게 하는 것 뿐만 아니라 필요하다면 그 정의에 기여하는 것이다.
본 발명의 목적은 통신 네트워크(N)에 결합된 적어도 하나의 콘텐츠 수신기(CR)와 연관되도록 의도된 콘텐츠를 획득하는 장치(D)를 제안하기 위한 것이다.
이하, 비제한적인 예로서, 콘텐츠 수신기(CR)는 셋탑 박스(또는 STB)인 것으로 간주한다. 그러나, 본 발명은 이러한 타입의 콘텐츠 수신기로 제한되지 않는다. 실로, 본 발명은 적어도 하나의 통신 네트워크에 접속되어 콘텐츠를 수신할 수 있고 콘텐츠를 복구할 수 있는 임의의 타입의 콘텐츠 수신기에 관한 것이다. 결과적으로, 예를 들어, 콘텐츠 수신기는 또한 디코더, 가정용 게이트웨이, 홈 게이트웨이, 고정 컴퓨터 또는 랩탑, 모바일 폰(가능하다면, 스마트폰 타입), 개인 휴대 단말기(PDA), 전자 태블릿 또는 게임 콘솔을 포함할 수 있다.
또한, 비제한적인 예로서, 콘텐츠는 멀티미디어 콘텐츠인 것으로 간주한다. 그러나, 본 발명은 이러한 타입의 콘텐츠로 제한되지 않는다. 실로, 데이터 파일들 또는 파일 청크들 형태로 이용가능한 임의의 타입의 콘텐츠 및 텔레비전 프로그램, 게임, 영화 프로그램, 음악, CGI(computer generated imagery)에 관한 것이다.
도 1은 콘텐츠를 저장하기에 적합한 3개의 콘텐츠 서버(SC1 내지 SC3)가 접속되는 통신 네트워크(N) 및 (본 발명에 따라 콘텐츠를 획득하는 장치(D)의 요청으로) 서버(CS1 내지 CS3) 중의 하나에 의해 송신되는 콘텐츠를 디코딩하도록 의도된 콘텐츠 수신기(CR)를 도표로 나타내는 도면이다.
예를 들어, 비제한적인 방식으로 설명하는 바와 같이, 셋탑 박스(CR)는 통신 네트워크(N)를 통해 서버(CS1, CS2 또는 CS3)로부터오며 디코딩되었을 컨텐츠를 복구하는 것을 담당하는 적어도 하나의 텔레비전 세트에 결합된다.
비제한적인 예로서, 통신 네트워크(N)는 xDSL 액세스 네트워크에 의해 사용되도록 접속된 인터넷 네트워크에 의해 구성된 네트워크인 것으로 간주한다. 그러나, 본 발명은 이러한 종류의 통신 네트워크로 제한되지 않는다. 실로, 통신 네트워크(N)는 유선 또는 무선일 수 있다. 그러므로, 통신 네트워크는 또한, 케이블 또는 파이버 타입의 유선 네트워크 또는 모바일 또는 셀룰러 또는 WLAN(wireless local area network - 가능하게는 802.11 (또는 WiFi) 또는 WiMAX) 타입) 네트워크, 또는 심지어 블루투스 타입의 근거리 무선 로컬 네트워크일 수 있다.
통신(R)은 이용가능한 네트워크 대역폭에 있어서 상이한 요구사항들을 갖는 적어도 2개의 전송 프로토콜을 지원할 수 있어야 함을 명심한다. 비제한적 예로서, 통신 네트워크(N)는 타입 TCP(transmission control protocol)의 제1 전송 프로토콜 및 타입 UDP(user datagram protocol)의 제2 전송 프로토콜을 지원한다. 그러나, 전송 프로토콜의 다른 조합이 예상될 수 있다.
제1 (콘텐츠) 서버(CS1)는 예를 들어 제1 저장 수단(SM1)에 상이한 콘텐츠 버전들(Vj)을 저장하는 것을 담당한다. 이들 제1 저장 수단(SM1)은 소프트웨어를 포함하여 당업자에게 공지된 임의의 형태로 존재할 수 있다. 결과적으로, 제1 저장 수단은 메모리일 수 있다.
"콘텐츠의 상이한 버전들"은 상이한 송신 비트 레이트들에 대응하는 버전들로 해석된다. 도 2는 예를 들어 제1 버전(V1)에 대한 1 Mbps(megabits per second), 제2 버전(V2)에 대한 2 Mbps, 제3 버전(V3)에 대한 4 Mbps, 및 제4 버전(V4)에 대한 6 Mbps로서 4개의 상이한 송신 비트 레이트에 각각 대응하는 동일 콘텐츠의 상이한 버전들(V1 내지 V4)(j=1 내지 4)을 도표로 나타낸다.
콘텐츠의 각각의 버전(Vj)는 결정된 기간(duration)들의 다수의 청크(또는 부분 - 마이크로파일)로 구성된다. 도 2의 예에서, 버전(Vj)의 각각의 청크는 사각형으로 구체화되고, 그 높이는 대응하는 송신 비트 레이트를 나타낸다.
동일한 콘텐츠의 버전의 수는 적어도 2와 동일한 임의의 값과 동일할 수 있다.
동일한 콘텐츠의 버전들(Vj)은 비디오 압축 기술, 예를 들어, MVC(multiview video coding), AVC(advanced video coding), SVC(scalable video coding), MPEG2, H264 및 더 일반적으로 예를 들어 오디오 데이터를 포함하여 전송(스트리밍) 또는 저장(다운로딩)에 전용인 포맷의 캡슐화가 가능한 임의의 타입의 비디오 압축에 의한 코딩에 의해 생성되었을 수 있음을 유념한다.
상이한 송신 비트 레이트들에 대응하는 각각의 콘텐츠의 상이한 버전들(Vj)은 통신 네트워크(N) 내의 요동하는 송신 상태에 정확하게 매칭되는 것으로 이해될 것이다.
도 2에 도시된 바와 같이, 동일한 콘텐츠의 버전들(Vj)은 우선적으로 시간 위치가 버전마다 동일한 기준 프레임(RF)들을 포함한다는 것을 유념한다. 기준 프레임(RF)들은 스트리밍으로 송신되는 콘텐츠의 청크를 랜덤하게 액세스할 수 있는 것임을 상기한다. 도시된 예에서, 각각의 기준 프레임(RF)은 콘텐츠의 버전(Vj)의 청크의 시작부에 배치된다. 이것은 요청시 (기준 프레임(RF)들의 송신 시간들인) 특정한 시간들에 임의의 시각적 아티팩트(artefact)를 생성하지 않고(일반적으로 각각의 비디오 청크는 하나의 청크로부터 사용자에게 보이지 않는 다른 청크로 천이하기 위해 키 이미지를 이용하여 시작하고 종료한다) 콘텐츠 수신기(CR) 내에 설치된 디코더가 하나의 버전(Vj)으로부터 다른 버전(Vj')으로 이동하도록 허용한다.
각각의 콘텐츠의 버전들(Vj)은 우선적으로 그들 각자의 비트 레이트를 기술하는 기술 파일(description file)에 대응하여 저장된다는 것을 유념한다. 각각의 기술 파일은 예를 들어 SDP(session description protocol) 타입이다. 이 기술 파일은 더 다루어질 것이다.
제2 콘텐츠 서버(CS2) 및 제3 콘텐츠 서버(CS3)는 여기서 콘텐츠 수신기(CR)에 의해 수신되지 않은 콘텐츠의 데이터 패킷의 가능한 재송신을 위해 의도된다. 이 이점은 더 이해될 것이다.
제1 서버(CS1)에 저장된 버전들(Vj)은 요청 시 적어도 하나의 콘텐츠 수신기(CR)로 송신되도록 의도된다. 이 목적으로, 각각의 콘텐츠 수신기(CR)는 본 발명에 따라 콘텐츠를 획득하는 장치(D)와 연관될 수 있다.
"연관된다"라 함은 콘텐츠 수신기(CR)에 직접 결합된다는 사실 뿐만 아니라 비제한적인 방식으로 도시된 바와 같이 콘텐츠 서버(CR)의 일체 부분(integral part)라는 사실 둘 다로 해석된다. 결과적으로, 콘텐츠를 획득하는 장치(D)는 소프트웨어(또는 컴퓨터) 모듈 또는 전자 회로 및 소프트웨어 모듈의 조합의 형태로 실현될 수 있다.
콘텐츠를 획득하는 장치(D)는, 주어진 시간에 콘텐츠의 버전(Vj)의 적어도 하나의 요구되는 다음 청크를 송신하는데 사용되어야 하는 전송 프로토콜로서, 통신 네트워크(N)의 이용가능한 대역폭(BW)의 현재 값이 제1 임계값(S1)보다 엄격히 크면 제1 전송 프로토콜을, 대역폭(BW)의 현재 값이 제1 임계값(S1)보다 작거나 같으면 제2 전송 프로토콜을 선택하도록 구성된다.
통신 네트워크(N)가 기술적 문제 또는 액세스 네트워크의 혼잡을 경험하면 통신 네트워크(N)에서 이용가능한 대역폭(BW)은 제1 임계값(S1)보다 작거나 동일해질 수 있음을 유념한다.
제1 전송 프로토콜은 제2 전송 프로토콜보다 많은 이용가능한 네트워크 대역폭(BW)을 필요로 한다. 이것은 특히 UDP 프로토콜보다 더 많은 이용가능한 네트워크 대역폭을 요구하는 TCP 프로토콜의 경우이다. 이것은, TCP가 양방향 타입이고 확인응답의 송신을 필요로 하고 윈도우 사이즈 조정(또는 윈도잉(windowing))에 대한 제한을 부여하고 수신되지 않은 데이터 패킷의 재송신 메카니즘을 제공하는 반면, UDP는 단방향 타입이고(따라서, 어떤 확인 응답도 없고) 윈도잉에 대한 제한이 없고 수신되지 않은 데이터 패킷의 재송신 메카니즘이 없다는 사실로부터 유발된다.
윈도잉은 TCP 세션 동안 동적으로 협상되고 스트림 제어 메카니즘의 타입을 구성하는 윈도우 사이즈를 지정한다는 것을 상기한다. 특히, 데이터가 송신되면, 소스는 수신지로부터 확인응답을 수신해야 하고, 수신지는 자신이 원하고 수신지가 수신할 준비가 된 패킷의 수를 나타내는 윈도우의 사이즈를 소스에게 시그널링해야 한다.
설명의 목적으로, 1 Mbps에서의 콘텐츠의 전송을 위해, 30 ms와 동일한 왕복 시간 및 0.02 (또는 2%)와 동일한 패킷 손실 레이트의 존재시에, TCP는 동일한 양의 데이터를 전송하는데 UDP보다 30% 많은 대역폭을 필요로 한다. 이전의 예는 (수신되지 않은 데이터 패킷의 재전송 메카니즘을 포함하는) UDP 상의 RTP 트래픽과 비교하여 TCP 상의 http 트래픽에 관한 것임을 유념한다.
본 발명 덕분에, 제1 프로토콜(여기서는, TCP) 대신에 제2 프로토콜(여기서는, UDP)이 콘텐츠의 청크를 회복하는데 일시적으로 사용될 때마다, 이 콘텐츠를 필요로 하는 사용자는 (이용가능한 대역폭(BW)의 현재 값에 가장 가까운 값을 갖는) 높은 송신 비트 레이트에 대응하는 버전(Vj)을 획득할 확률이 더 높다. 결과적으로, 예를 들어, 통신 네트워크(N)에서의 혼잡에 후속하여, UDP가 선택될 때마다, 사용자의 콘텐츠 수신기(CR)에 의해 복구되는 품질은 TCP를 이용하는 경우보다 더 좋을 확률이 높다. 예를 들어, 혼잡의 경우 항상, 본 발명은 http/TCP 프로토콜이 그러하였을 것이므로 더 낮은 비트 레이트 청크를 요청할 수 있을 것이지만 RTP/UDP에서는 더 높거나 동일한 비트 레이트의 청크를 요청할 수 있다.
콘텐츠를 획득하는 장치(D)는, 또한 주어진 시간에 제2 전송 프로토콜을 선택하면 이 주어진 시간에 이용가능한 대역폭(BW)의 현재 값에 가장 가까운 값을 갖는 송신 비트 레이트에 대응하는 콘텐츠의 버전(Vj)을 선택하도록 구성될 수 있다.
요구되는 콘텐츠의 상이한 버전들(Vj)을 알기 위하여, 콘텐츠를 획득하는 장치(D)는, 바람직하게, 그 콘텐츠 수신기(CR)가 관련된 제1 서버(CS1)로부터 이들 버전(Vj)과 대응하여 저장된 (및 그 각자의 송신 비트 레이트를 기술하는) 기술 파일을 회복하도록 명령하도록 구성된다. 이 경우, 콘텐츠 수신기(CR)가 관련된 제1 서버(SC1)로부터 요구된 기술 파일을 회복하면, 콘텐츠(D)를 획득하는 장치는 통신 네트워크(N)에서 이용가능한 대역폭(BW)에 따라 요구되는 콘텐츠의 선택(또는 선정)된 버전(Vj)을 뚜렷하게 연속하는 방식으로 제어함으로써 (스트리밍 모드 또는 풀 파일 다운로드 모드로) 콘텐츠를 획득하는 세션을 시작할 수 있다. 그 후, 콘텐츠를 획득하는 장치(D)는 관련된 제1 서버(CS1)에게 요청하기 위하여 그 콘텐츠 수신기(CR)에 선택된(기술 파일에 언급된) 각 버전(Vj)의 지정을 공급할 것이다.
비제한적 예에서, 콘텐츠는 스트리밍 모드로 송신되는 것으로 간주한다.
이 경우, 콘텐츠를 획득하는 장치(D)는, 제2 프로토콜(여기서는, UDP)을 선택했을 때, 그 콘텐츠 수신기(CR)가 제1 서버(SC1)와 RTSP(real-time streaming protocol) 세션을 개시하도록 명령할 수 있다. RTSP는, RTP 프로토콜(real-time protocol)을 보완하고 스트리밍 모드에서 멀티미디어 콘텐츠 전송 세션을 설정하고 제어하는 데에 전용인, RFC 2326 룰에 의해 정의된 프로토콜임을 상기한다. 이 경우, 콘텐츠 수신기(CR)는 요구되는 콘텐츠의 기술 파일을 얻기 위하여 제1 서버(CS1)로 "RTSP 기술 URI" 메시지를 전송할 수 있다. 그 후, 제1 서버(CS1)는 "RTSP 기술 응답" 메시지로 응답하여 요구되는 기술 파일을 송신한다. 그 후 콘텐츠 수신기(CR)는 "RTSP 셋업" 메시지를 제1 서버(SC1)로 전송하여 RTP/UDP 스트리밍 세션을 준비한다. 그 후, 제1 서버(CS1)는 "RTSP 셋업 응답"으로 응답하여 이 세션이 준비되었다고 시그널링한다. 그 후, 콘텐츠 수신기(CR)는 "RTSP 플레이" 메시지를 제1 서버(SC1)로 전송하여 이전에 준비된 세션을 시작할 것을 물을 수 있다. 그 후, 제1 서버(CS1)는 "RTSP 플레이 응답" 메시지로 응답하여 RTP/UDP 스트리밍 세션을 시작할 것이라는 것을 시그널링한다. 그 후, 예를 들어 포맷 MP4 또는 MPEG-TS로 요구되는 콘텐츠의 콘테이너를 UDP 상에서 스트리밍 모드로 전송되는 패킷에 캡슐화할 것이다.
콘텐츠가 풀 파일 다운로드 모드로 송신되면, RTP 프로토콜 대신에 (RFC 3926 룰에 의해 정의된) FLUTE 프로토콜이 사용될 수 있다.
콘텐츠를 획득하는 장치(D)가 콘텐츠의 청크를 회복하기로 결정할 때마다, 선택된 버전(Vj)에 이 청크를 나타내는 식별자, 및 이 청크의 시간과 동일하고 이 청크의 시작 시간을 지정하는 타임 슬롯을 특정해야 한다. 이것은 RTSP 타입의 메시지를 교환함으로써 수행될 수 있다.
콘텐츠를 획득하는 장치(D)는 필요로 하는 콘텐츠의 선명도 레벨에 따라 제1 임계값(S1)을 선택하도록 구성될 수 있음을 유념한다. 콘텐츠의 선명도가 낮을 수록 제1 임계값(S1)이 낮을 수 있음을 이해한다. 그러므로, 제1 임계값(S1)은 표준 선명도로부터 고선명을 포함하는 매우 높은 선명도로 증가하도록 선택될 수 있다.
콘텐츠를 획득하는 장치(D)는 적어도 2개의 상이한 방식으로 동작할 수 있다.
제1 방식은 위에서 설명하였다. 이것은 제한적이지 않지만, 로컬 애플리케이션, 예를 들어, 대역폭의 공유 공정성(sharing fairness)이 우선순위가 아닌 집에 잘 적용된다. 예를 들어, 이것은 (자신의 CR STB 또는 그 홈 게이트웨이에 접속된) 텔레비전 세트(TS)의 스크린 상에서, (데스크탑 컴퓨터 등) 고정된 항목의 메모리에 또는 예를 들어 WiFi/PLC 스트리밍 모드로 CR STB 또는 그 홈 게이트웨이와 통신할 수 있는 이동하는 (예를 들어 모바일 폰 또는 비디오 플레이어 또는 랩탑 컴퓨터) 통신 장비에 저장된 비디오를 보기를 원하는 사용자에게 적합하다.
도 3은 시간(t)에 따라 통신 네트워크(N)의 이용가능한 대역폭(BW)의 변화를 나타내는 곡선의 제1 예를 도표로 나타내는 도면이다. 이 동일한 도면은 또한 제1 시간 변화 곡선의 존재시에 콘텐츠를 획득하는 장치(D)로 송신되는 콘텐츠의 청크들을 나타낸다. 상이한 사이즈의 백색 사각형들은, 3개의 상이한 송신 비트 레이트에 각각 대응하는 3개의 버전(Vj)에 속하고 제1 전송 프로토콜(여기서, TCP (예를 들어 http와 결합(즉, http/TCP)))에 의해 제1 서버(SC1)에 의해 송신되는 콘텐츠 청크들을 구체화한다. 단일 사이즈 회색 사각형들은, 송신 비트 레이트에 대응하는 단일 버전(Vj)에 속하고 제2 전송 프로토콜(여기서, UDP(예를 들어 RTP와 결합(즉, RTP/UDP)))에 의해 제1 서버(SC1)에 의해 송신되는 콘텐츠 청크들을 구체화한다.
제1 예에서 볼 수 있는 바와 같이, 이용가능한 대역폭의 값이 제1 임계값(S1)보다 작거나 같아질 때마다, 콘텐츠를 획득하는 장치(D)는 제1 서버(SC1)가 제2 전송 프로토콜(여기서는, UDP)를 이용하도록 명령한다.
이 제1 방식은 UDP 상의 RTP를 이용하는 경우 패킷 손실 레이트(또는 plr)의 현재 값을 고려하도록 의도된 옵션을 포함할 수 있다. 이 경우, 콘텐츠를 획득하는 장치(D)는 패킷 손실 레이트(여기서, plr)의 현재 값을 분석하도록 구성될 수 있다. 그러므로, 제1 송신 비트 레이트에 대응하는 버전(Vj)의 청크의 송신을 위해 제2 전송 프로토콜(여기서는, UDP)을 선택하면, 패킷 손실 레이트의 현재 값이 제2 임계값(S2)보다 엄격히 큰 것으로 검출될 때 제1 송신 비트 레이트보다 낮은 제2 송신 비트 레이트에 대응하는 다른 버전(Vj)(j'≠j)으로 이 동일한 청크의 송신을 요구할 수 있다.
예를 들어 슬라이딩 윈도우 내의 수신된 RTP 패킷(예를 들어, 수신된 모든 100개의 리프레쉬 RTP 패킷)의 수를 (시퀀스 번호라 불리우는 룰 RFC 3550에 순응하는) 각각의 RTP 패킷 해더 내에 언급된 초기에 송신된 RTP 패킷의 수와 비교함으로써, plr 파라미터가 산출된다는 것을 상기한다. 그러므로, 이는 시퀀스 번호 홉(hop)들을 검출하여 그로부터 패킷 손실 및 손실된 패킷의 수를 추론하기에 충분하다.
plr 파라미터의 경우, 제2 임계값(S2)은 예를 들어 4% 또는 5%로 선택될 수 있다.
제2 방식은, 제한적이지 않지만, 대역폭의 공유 공정(sharing equity)이 우선순위인 애플리케이션에 잘 적용된다. 예를 들어, 텔레비전 세트(TS) 등의 전자(가능하면, 통신) 장비의 항목의 화면 상에서 예를 들어 ST 또는 홈 게이트웨이 등의 이러한 전자 장비에 결합된 콘텐츠 수신기(CR)에 의해 회복된 비디오를 보기를 원하는 사용자에게 적합하다. 이러한 타입의 상황에서, 비디오는 다수의 사용자에 의해 공유되는 통신 네트워크(N)에 의해 전송되고, 그러므로, 공정성의 이유로, 대역폭은 통신 네트워크(N)의 이용가능한 대역폭(BW)이 제1 임계값(S1)보다 작아질 때마다 제2 전송 프로토콜(여기서는, UDP)을 사용하기 때문에 동일한 사용자에 의해 조직적으로 사용되지 않아야 한다.
이 목적으로, 콘텐츠를 획득하는 장치(D)는 이용가능한 대역폭(BW)의 현재 값 뿐만 아니라 타임 슬롯, 바람직하게 슬라이딩 상에서 제1 및 제2 전송 프로토콜의 사용의 미리 정의된 분포에 따라 사용되어야 하는 전송 프로토콜을 각 주어진 시간에 선택하도록 구성될 수 있다.
비제한적인 예로서, 콘텐츠를 획득하는 장치(D)는 타임 슬롯 상에서 제1 및 제2 전송 프로토콜의 75%/25% 타입(제1 전송 프로토콜에 대하여 75% 및 제2 전송 프로토콜에 대하여 25%)의 미리 정의된 선명도를 이용할 수 있다.
도 4는 시간(t)에 따라 통신 네트워크(N)의 이용가능한 대역폭(BW)의 변화를 나타내는 곡선의 제2 예를 도표로 나타낸다. 이 동일한 도면은 또한 제2 시간 변화 곡선의 존재시에 콘텐츠를 획득하는 장치(D)로 송신되는 콘텐츠의 청크들을 나타낸다. 상이한 사이즈의 백색 사각형들은, 4개의 상이한 송신 비트 레이트에 각각 대응하는 4개의 버전(Vj)에 속하고 제1 전송 프로토콜(여기서, TCP (예를 들어 http와 결합(즉, http/TCP)))에 의해 제1 서버(SC1)에 의해 송신되는 콘텐츠 청크들을 구체화한다. 단일 사이즈 회색 사각형들은, 송신 비트 레이트에 대응하는 단일 버전(Vj)에 속하고 제2 전송 프로토콜(여기서, UDP(예를 들어 RTP와 결합(즉, RTP/UDP)))에 의해 제1 서버(SC1)에 의해 송신되는 콘텐츠 청크들을 구체화한다.
제2 예에서 관찰되는 바와 같이, 제2 전송 프로토콜(여기서는, UDP)은 이용가능한 대역폭(BW)의 값이 제1 임계값(S1)보다 작거나 같아질 때마다 조직적으로 이용되지 않는다. 제2 전송 프로토콜은, 사실, 현재 타임 슬롯에서의 그 사용이 선택된 분포에 의해 그에 할당된 퍼센티지를 초과하지 않으면, 이용가능한 대역폭(BW)의 값이 제1 임계값(S1)보다 작거나 동일해질 때 콘텐츠를 획득하는 장치(D)의 요청에 의해 사용된다. 어떤 경우, 제2 전송 프로토콜은 이용가능한 대역폭(BW)이 제1 임계값(S1)보다 작거나 같더라도 사용되지 않는다.
제2 전송 프로토콜이 UDP의 경우에서처럼 수신되지 않은 데이터 패킷에 대한 임의의 재전송 메카니즘을 포함하지 않는 경우, 버전(Vj)의 청크의 송신을 위해 이러한 제2 전송 프로토콜을 선택하면, 콘텐츠를 획득하는 장치(D)가 제1 전송 프로토콜에 의해 버전(Vj)의 이 청크로부터 수신되지 않은 데이터 패킷에 대한 재송신 메카니즘을 트리거하도록 구성된다는 것이 유리하다. 이렇게 하기 위하여, 콘텐츠를 획득하는 장치(D)는 예를 들어 그 콘텐츠 수신기가 RTSP 타입의 재송신 요청을 서버에 송신하도록 명령할 수 있으며, 서버가 http/TCP 세션을 개시함으로써 응답한다.
데이터 패킷의 각각의 재송신은 재송신에 전용인 콘텐츠 서버(CS2 또는 CS3)로부터 요구될 수 있음을 유념한다. 실로, 이것은, 제1 서버(SC1)가 추가의 태스크를 수행하는 것을 방지할 뿐만 아니라 제1 서버(CS1)에 의해 사용되는 것(또는 것들)과 다르고 데이터 패킷들이 손실된(따라서, 이것은 경로 다이버시티를 제공) 경로의 통신 네트워크(N) 내에서의 사용을 가능하게 한다. 또한, 하나 이상의 콘텐츠 서버를 수신되지 않은 데이터 패킷의 재송신에 전념하도록 하는 것은 재송신 시간을 줄일 수 있다.
본 발명은 비제한적인 예로서 제공되는 상술한 콘텐츠를 획득하고 콘텐츠를 수신하는 장치의 실시예로 제한되지 않고 다음의 청구범위의 프레임워크 내에서 당업자에 의해 예상될 수 있는 모든 변형을 포함한다.

Claims (16)

  1. 이용가능한 네트워크 대역폭에 있어서 상이한 요구사항들을 갖는 적어도 2개의 전송 프로토콜에 의해 콘텐츠를 획득하는 장치(D)로서 - 상기 콘텐츠는 적어도 하나의 서버 상에서 상이한 버전들로 이용가능하고, 상기 콘텐츠의 상이한 버전들은 상이한 송신 비트 레이트들에 대응하고 통신 네트워크(N)를 통해 송신되도록 구성된 청크(chunk)들로 세분됨 -,
    상기 장치는 콘텐츠의 버전 및 전송 프로토콜에 따라 적어도 하나의 청크의 송신을 상기 적어도 하나의 서버에 요청하도록 구성되고, 상기 전송 프로토콜 및 상기 버전은 상기 통신 네트워크(N)의 현재 이용 가능한 대역폭에 응답하여 선택가능하며,
    상기 현재 이용 가능한 대역폭이 제1 값보다 큰 경우에 제1 전송 프로토콜이 요청되고, 상기 현재 이용 가능한 대역폭이 상기 제1 값보다 작은 경우에 제2 전송 프로토콜이 요청되며,
    상기 제1 전송 프로토콜은 상기 제2 전송 프로토콜보다 더 많은 이용 가능한 네트워크 대역폭을 요구하는, 장치.
  2. 삭제
  3. 제1항에 있어서,
    상기 제1 값은 상기 콘텐츠의 버전의 함수인, 장치.
  4. 제1항에 있어서,
    현재 패킷 손실 레이트를 분석하고, 상기 제2 전송 프로토콜이 제1 송신 비트 레이트에 대응하는 버전의 청크의 송신을 위해 요구되는 경우 및 상기 현재 패킷 손실 레이트가 제2 값보다 높은 경우, 상기 제1 송신 비트 레이트보다 낮은 제2 송신 비트 레이트에 대응하는 다른 버전의 동일한 청크의 송신을 요청하도록 구성되는 장치.
  5. 제1항에 있어서,
    상기 콘텐츠를 획득하기 위해 복수의 연속적인 청크들에 대한 전송 프로토콜에 따라 요구되는 버전의 적어도 하나의 청크의 송신을 연속적으로 요청하도록 구성되는 장치.
  6. 제1항에 있어서,
    타임 슬롯 상에서 제1 전송 프로토콜 및 제2 전송 프로토콜의 사용의 분포에 따라 추가로 사용되어야 하는 전송 프로토콜을 각각의 청크에 대해 요청하도록 구성되는 장치.
  7. 제6항에 있어서,
    상기 타임 슬롯은 슬라이딩(sliding)인, 장치.
  8. 제6항에 있어서,
    상기 타임 슬롯 상에서 상기 제1 전송 프로토콜 및 상기 제2 전송 프로토콜의 75%/25%의 미리 정의된 분포를 이용하도록 구성되는 장치.
  9. 제1항에 있어서,
    버전의 청크의 송신을 위해 상기 제2 전송 프로토콜이 요청된 경우, 상기 제1 전송 프로토콜에 의해 상기 버전의 청크로부터 수신되지 않은 데이터 패킷들의 재송신 메카니즘을 트리거(trigger)하도록 구성되는 장치.
  10. 제9항에 있어서,
    상기 재송신들에 전용인 콘텐츠 서버(CS2)로부터의 데이터 패킷들의 각각의 재송신을 요청하도록 구성되는 장치.
  11. 제1항에 있어서,
    상기 제1 전송 프로토콜은 TCP이고 상기 제2 전송 프로토콜은 UDP인, 장치.
  12. 제1항에 있어서,
    상기 제2 전송 프로토콜이 요청되는 경우, 상기 청크에 대해 현재 대역폭에 가장 가까운 송신 비트 레이트에 대응하는 콘텐츠 버전을 요구하도록 구성되는 장치.
  13. 제1항에 있어서,
    획득하고 싶어하는 콘텐츠의 버전들에 대응하여 저장되고 각자의 송신 비트 레이트들을 기술하는 기술 파일(description file)을 복구하여, 전송 프로토콜을 선택하여 상기 콘텐츠를 획득하도록 구성되는 장치.
  14. 제1항에 있어서,
    스트리밍 모드 또는 다운로드 모드로 콘텐츠의 송신을 획득하도록 구성되는 장치.
  15. 제1항에 있어서,
    상기 제1 전송 프로토콜을 이용하여 적어도 콘텐츠의 버전의 다음 청크를 송신하는 것을 제1 콘텐츠 서버(SC1)에 요청하고 상기 제2 전송 프로토콜을 이용하여 적어도 콘텐츠의 다음 버전의 청크를 송신하는 것을 제2 콘텐츠 서버에 요청하도록 구성되는 장치.
  16. 이용가능한 네트워크 대역폭에 있어서 상이한 요구사항들을 갖는 적어도 2개의 전송 프로토콜에 의해 콘텐츠를 획득하는 방법으로서 - 상기 콘텐츠는 적어도 하나의 서버(SC) 상에서 상이한 버전들로 이용가능하고, 상기 콘텐츠의 상이한 버전들은 상이한 송신 비트 레이트들에 대응하고 통신 네트워크(N)를 통해 송신되도록 구성된 청크(chunk)들로 세분되며, 상기 방법은 콘텐츠 획득 장치(D)에 의해 수행됨- ,
    콘텐츠의 버전 및 전송 프로토콜에 따라 적어도 하나의 청크의 송신을 상기 적어도 하나의 서버에 요청하는 단계 - 상기 전송 프로토콜 및 상기 버전은 상기 통신 네트워크(N)의 현재 이용 가능한 대역폭에 응답하여 선택가능함 -
    를 포함하고,
    상기 현재 이용 가능한 대역폭이 제1 값보다 큰 경우에 제1 전송 프로토콜이 요청되고, 상기 현재 이용 가능한 대역폭이 상기 제1 값보다 작은 경우에 제2 전송 프로토콜이 요청되며,
    상기 제1 전송 프로토콜은 상기 제2 전송 프로토콜보다 더 많은 이용 가능한 네트워크 대역폭을 요구하는 방법.
KR1020147017712A 2011-12-01 2012-11-29 이용가능한 대역폭에 따라 전송 프로토콜을 선택함으로써 콘텐츠를 획득하는 장치 KR102119287B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR1161045 2011-12-01
FR1161045 2011-12-01
PCT/EP2012/073972 WO2013079598A1 (en) 2011-12-01 2012-11-29 Device for obtaining content by choosing the transport protocol according to the available bandwidth

Publications (2)

Publication Number Publication Date
KR20140099924A KR20140099924A (ko) 2014-08-13
KR102119287B1 true KR102119287B1 (ko) 2020-06-04

Family

ID=47263370

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020147017712A KR102119287B1 (ko) 2011-12-01 2012-11-29 이용가능한 대역폭에 따라 전송 프로토콜을 선택함으로써 콘텐츠를 획득하는 장치

Country Status (7)

Country Link
US (1) US9584596B2 (ko)
EP (1) EP2786537B1 (ko)
JP (1) JP6513402B2 (ko)
KR (1) KR102119287B1 (ko)
CN (1) CN104094561B (ko)
BR (1) BR112014013006B1 (ko)
WO (1) WO2013079598A1 (ko)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8086734B2 (en) * 2009-08-26 2011-12-27 International Business Machines Corporation Method of autonomic representative selection in local area networks
CN103780741B (zh) * 2012-10-18 2018-03-13 腾讯科技(深圳)有限公司 提示网速的方法和移动设备
CN103618704A (zh) * 2013-11-15 2014-03-05 四川长虹电器股份有限公司 界面客户端与服务器的通信方法
US9596323B2 (en) * 2014-03-18 2017-03-14 Qualcomm Incorporated Transport accelerator implementing client side transmission functionality
US9596281B2 (en) * 2014-03-18 2017-03-14 Qualcomm Incorporated Transport accelerator implementing request manager and connection manager functionality
US10567457B1 (en) * 2014-09-29 2020-02-18 Amazon Technologies, Inc. Dynamic rotation of streaming protocols
KR102111572B1 (ko) * 2015-02-13 2020-05-15 에스케이텔레콤 주식회사 저지연 생방송 컨텐츠 제공을 위한 프로그램을 기록한 기록매체 및 장치
JPWO2016132899A1 (ja) 2015-02-17 2017-11-24 ソニー株式会社 送信装置、送信方法、受信装置、及び、受信方法
US10491525B2 (en) * 2015-03-10 2019-11-26 Huawei Technologies Co., Ltd. Traffic engineering feeder for packet switched networks
JP2018082241A (ja) * 2016-11-14 2018-05-24 日本電信電話株式会社 動画再生装置、動画再生方法及びプログラム
US10433201B2 (en) * 2017-03-17 2019-10-01 Electronics And Telecommunications Research Institute Method for transmitting and receiving packet in transport network
KR102238310B1 (ko) * 2017-03-17 2021-04-09 한국전자통신연구원 트랜스포트 네트워크에서 패킷의 송수신 방법
CN108667775A (zh) * 2017-03-31 2018-10-16 宇龙计算机通信科技(深圳)有限公司 通信方法和通信系统
CN107861908A (zh) * 2017-11-22 2018-03-30 江苏微锐超算科技有限公司 适用于处理芯片的通信协议选择方法及装置
US11349904B2 (en) * 2019-04-03 2022-05-31 Citrix Systems, Inc. Selecting a mode of delivery to provide access to a file systems and methods
US11212349B1 (en) * 2020-08-31 2021-12-28 Frontiir Pte Ltd. Switching between network protocols for a data storage system
US11902599B2 (en) 2020-12-09 2024-02-13 Hulu, LLC Multiple protocol prediction and in-session adaptation in video streaming
CN113259365B (zh) * 2021-05-27 2021-10-01 中国电子科技集团公司第二十八研究所 一种窄带弱连接自适应服务框架装置及服务调用方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002281103A (ja) * 2001-03-19 2002-09-27 Nippon Hoso Kyokai <Nhk> 蓄積連続メディア転送方法及びシステム及び蓄積連続メディア転送プログラム
JP2011087103A (ja) * 2009-10-15 2011-04-28 Sony Corp コンテンツ再生システム、コンテンツ再生装置、プログラム、コンテンツ再生方法、およびコンテンツサーバを提供
US20110249667A1 (en) * 2010-04-13 2011-10-13 Rebelvox, Llc Apparatus and method for transmitting media using either network efficient protocol or a loss tolerant transmission protocol

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4176865B2 (ja) * 1998-04-30 2008-11-05 シャープ株式会社 画像伝送装置
JP3426144B2 (ja) * 1998-11-16 2003-07-14 シャープ株式会社 マルチメディア通信装置
US7010492B1 (en) * 1999-09-30 2006-03-07 International Business Machines Corporation Method and apparatus for dynamic distribution of controlled and additional selective overlays in a streaming media
NO315887B1 (no) * 2001-01-04 2003-11-03 Fast Search & Transfer As Fremgangsmater ved overforing og soking av videoinformasjon
JP2003069472A (ja) * 2001-08-24 2003-03-07 Matsushita Electric Ind Co Ltd 受信端末装置及び通信システム
JP3846853B2 (ja) * 2001-10-12 2006-11-15 株式会社メガチップス 情報配信システム及び情報配信方法
AU2003215853A1 (en) * 2002-04-09 2003-10-20 Koninklijke Philips Electronics N.V. Transmission method combining downloading and streaming
JP3935419B2 (ja) * 2002-11-19 2007-06-20 Kddi株式会社 動画像符号化ビットレート選択方式
JP2005167780A (ja) * 2003-12-04 2005-06-23 Toshiba Corp ストリーミングデータ伝送装置及び伝送方法
US7720983B2 (en) 2004-05-03 2010-05-18 Microsoft Corporation Fast startup for streaming media
JP2006191186A (ja) * 2004-12-28 2006-07-20 Toshiba Corp コンテンツの再生システム、再生装置、再生方法、及び配信サーバ
CN101039414A (zh) * 2006-03-17 2007-09-19 中兴通讯股份有限公司 高质量流媒体传送方法
CN100456678C (zh) * 2006-11-28 2009-01-28 华为技术有限公司 为不同类型的终端提供iptv业务的方法和iptv业务系统
US7617337B1 (en) * 2007-02-06 2009-11-10 Avaya Inc. VoIP quality tradeoff system
FR2919778A1 (fr) * 2007-07-30 2009-02-06 Canon Kk Procede de transmission de paquets de donnees dans un tunnel, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants
US20110066703A1 (en) 2009-05-20 2011-03-17 Creative Ad Technology Proprietary Limited Methods and systems for delivering media to client device
CN102045768A (zh) * 2009-10-26 2011-05-04 宏碁股份有限公司 数据传输方法及其用户装置与数据传输系统
EP2375680A1 (en) * 2010-04-01 2011-10-12 Thomson Licensing A method for recovering content streamed into chunk
WO2011153475A1 (en) * 2010-06-04 2011-12-08 Skype Ireland Technologies Holdings Limited Server-assisted video conversation

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002281103A (ja) * 2001-03-19 2002-09-27 Nippon Hoso Kyokai <Nhk> 蓄積連続メディア転送方法及びシステム及び蓄積連続メディア転送プログラム
JP2011087103A (ja) * 2009-10-15 2011-04-28 Sony Corp コンテンツ再生システム、コンテンツ再生装置、プログラム、コンテンツ再生方法、およびコンテンツサーバを提供
US20110249667A1 (en) * 2010-04-13 2011-10-13 Rebelvox, Llc Apparatus and method for transmitting media using either network efficient protocol or a loss tolerant transmission protocol

Also Published As

Publication number Publication date
JP2015507857A (ja) 2015-03-12
US20140330887A1 (en) 2014-11-06
EP2786537A1 (en) 2014-10-08
CN104094561A (zh) 2014-10-08
BR112014013006B1 (pt) 2022-05-24
KR20140099924A (ko) 2014-08-13
WO2013079598A1 (en) 2013-06-06
JP6513402B2 (ja) 2019-05-15
BR112014013006A2 (pt) 2017-06-13
EP2786537B1 (en) 2019-11-20
US9584596B2 (en) 2017-02-28
CN104094561B (zh) 2017-12-12

Similar Documents

Publication Publication Date Title
KR102119287B1 (ko) 이용가능한 대역폭에 따라 전송 프로토콜을 선택함으로써 콘텐츠를 획득하는 장치
US10455404B2 (en) Quality of experience aware multimedia adaptive streaming
KR101843328B1 (ko) 비디오 방향 조정(cvo)를 갖는 스트리밍
US9253236B2 (en) Apparatus and method for providing streaming service in a data communication network
WO2014134309A1 (en) Link-aware streaming adaptation
US10499094B2 (en) Transmission apparatus, transmitting method, reception apparatus, and receiving method
KR20120010089A (ko) Http 기반의 멀티미디어 스트리밍 서비스의 품질 향상을 위한 방법 및 장치
US10834161B2 (en) Dash representations adaptations in network
EP2710778B1 (en) Method for dynamic adaptation of the reception bitrate and associated receiver
US20140189064A1 (en) Method and system for adaptive video transmission
US8930755B2 (en) Distribution apparatus and distribution method
US9131251B2 (en) Use of a receive-window size advertised by a client to a content server to change a video stream bitrate streamed by the content server
US9332421B2 (en) Method and apparatus for random access to multimedia content in wireless communication system
CN117014608A (zh) 视频流码率调整方法、装置、计算机设备和存储介质

Legal Events

Date Code Title Description
AMND Amendment
A201 Request for examination
AMND Amendment
E902 Notification of reason for refusal
AMND Amendment
E601 Decision to refuse application
AMND Amendment
X701 Decision to grant (after re-examination)