KR101837637B1 - 클라이언트 측 ack 조정 기반 적응 스트리밍 방법 및 장치 - Google Patents

클라이언트 측 ack 조정 기반 적응 스트리밍 방법 및 장치 Download PDF

Info

Publication number
KR101837637B1
KR101837637B1 KR1020160167001A KR20160167001A KR101837637B1 KR 101837637 B1 KR101837637 B1 KR 101837637B1 KR 1020160167001 A KR1020160167001 A KR 1020160167001A KR 20160167001 A KR20160167001 A KR 20160167001A KR 101837637 B1 KR101837637 B1 KR 101837637B1
Authority
KR
South Korea
Prior art keywords
video
size
token
available bandwidth
video segment
Prior art date
Application number
KR1020160167001A
Other languages
English (en)
Inventor
김서향
김종권
조기환
Original Assignee
서울대학교산학협력단
전북대학교산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 서울대학교산학협력단, 전북대학교산학협력단 filed Critical 서울대학교산학협력단
Priority to KR1020160167001A priority Critical patent/KR101837637B1/ko
Priority to US15/385,015 priority patent/US20180167431A1/en
Application granted granted Critical
Publication of KR101837637B1 publication Critical patent/KR101837637B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H04L43/0864—Round trip delays
    • 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/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • 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/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/23805—Controlling the feeding rate to the network, e.g. by controlling the video pump
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0888—Throughput
    • 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/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • 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/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2401—Monitoring of the client buffer
    • 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/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available
    • 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26208—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
    • H04N21/26216—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints involving the channel capacity, e.g. network bandwidth
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/21—Flow control; Congestion control using leaky-bucket
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]

Landscapes

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

Abstract

본 발명에 따른 클라이언트 측 ACK 조정 기반 적응 스트리밍 방법은 비디오 세그먼트의 목표 다운로드 시간(Goal Download Time, GDT)를 변경하여 애플리케이션의 앱 버퍼 레벨을 조정하는 단계; 상기 조정된 GDT를 이용하여 토큰 크기를 결정함으로써 리키 버킷을 토대로 리시브 소켓 읽기를 조절하는 단계; 및 상기 결정된 토큰 크기를 토대로 리시브 소켓 버퍼 사이즈를 제어하는 단계;를 포함한다.

Description

클라이언트 측 ACK 조정 기반 적응 스트리밍 방법 및 장치{Streaming method based on Client-side ACK-regulation and apparatus thereof}
본 발명은 데이터 스트리밍 방법 및 시스템에 관한 것으로서 구체적으로 다수의 스트리밍 유저가 하나의 병목 링크를 공유할 때 발생하는 스트리밍 품질 저하를 방지하기 위하여 TCP 소켓 버퍼의 사이즈와 TCP 소켓 버퍼의 데이터에 대한 읽기를 제어하여 스트리밍 품질을 증가시키는 클라이언트 측 ACK 조정 기반 적응 스트리밍 방법 및 시스템에 관한 것이다.
본 발명은 미래창조과학부 및 정보통신기술진흥센터의 대학ICT연구센터육성 지원사업(IITP-2016-R0992-16-1023, 사물인터넷/빅데이터 기반 차세대 공공안전 서비스 기술개발) 및 2016년도 정부(미래창조과학부)의 재원으로 정보통신기술진흥센터의 정보통신/방송 연구 개발 사업(No.B0190-16-2017, IoT 기기의 물리적 속성, 관계, 역할 기반 Resilient/Fault-Tolerant 자율 네트워킹 기술 연구)의 지원을 받아 수행된 연구로부터 도출된 것이다.
최근, 세계 모바일 트래픽 중 70% 이상이 비디오 트래픽이며, 비디오 어플리케이션 사용자의 수는 더욱 증가할 것이다. 비디오 트래픽의 증가에 따라 비디오 사업자 및 클라이언트는 질 높은 스트리밍 기술을 요구하고 있고, 더 높은 비디오 품질과 끊김 없는 재생을 위한 연구가 활발히 진행되고 있다.
기존의 데이터 스트리밍 방법 및 시스템은 병목 링크를 공유할 경우, 하나의 클라이언트가 해당 링크의 대부분의 트래픽을 사용하여, 다른 사용자의 경우, 적절한 수준의 트래픽을 보장받지 못하는 문제가 있다.
본 발명은 전술한 문제를 해결하기 위하여, 병목 구간에서 다수의 클라이언트가 평균적으로 높은 트래픽을 보장할 수 있는 클라이언트 측 ACK 조정 기반 적응 스트리밍 방법 및 시스템을 제공하는 것을 그 목적으로 한다.
본 발명의 목적은 이상에서 언급한 목적으로 제한되지 않으며, 언급되지 않은 또 다른 목적들은 아래의 기재로부터 당업자에게 명확하게 이해될 수 있을 것이다.
전술한 목적을 달성하기 위한 본 발명에 따른 클라이언트 측 ACK 조정 기반 적응 스트리밍 방법은 비디오 세그먼트의 목표 다운로드 시간(Goal Download Time, GDT)를 변경하여 앱 버퍼 레벨을 조정하는 단계; 상기 조정된 GDT를 이용하여 토큰 크기를 결정함으로써 리키 버킷을 토대로 리시브 소켓 읽기를 조절하는 단계; 및 상기 결정된 토큰 크기를 토대로 리시브 소켓 버퍼 사이즈를 제어하는 단계;를 포함한다.
본 발명에 따른 클라이언트 측 ACK 조정 기반 적응 스트리밍 장치는 스트리밍 처리 모듈을 제공하기 위한 프로그램이 저장된 메모리; 및 상기 프로그램을 실행시키는 프로세서를 포함하되, 상기 프로세서는 상기 프로그램을 실행시킴에 따라, 비디오 세그먼트의 목표 다운로드 시간(Goal Download Time, GDT)를 변경하여 앱 버퍼 레벨을 조정하고; 상기 조정된 GDT를 이용하여 토큰의 크기를 결정함으로써 리키 버킷을 토대로 리시브 소켓 읽기를 조절하고; 상기 결정된 토큰 크기를 토대로 리시브 소켓 버퍼의 크기를 제어하고; 이용 가능한 대역폭을 프로빙하고; 프로빙한 이용 가능한 대역폭과 상기 앱 버퍼 레벨을 토대로 목표 쓰루풋을 결정하고; 및 상기 목표 쓰루풋을 이용하여 다음 주기에서의 비디오 레이트를 결정하는; 것을 특징으로 한다.
본 발명에 따르면, 평균 비디오 품질, 안정성, 공정성, 리버퍼 비율, 트래픽 분포 완화 측면에서 우수한 성능을 보이고, 버퍼 넘침(bloat) 문제도 완화시키는 효과가 있다. 또한, 본 발명은 클라이언트 측 어플리케이션 수준에서 제공되므로 쉽게 채용할 수 있고, 데이터 센터 또는 CDN 등 데이터 트래픽을 다량으로 발생시키는 경우, 버퍼 넘침(buffer bloat) 및 과도하고 첨밀한 대역폭(greedy and bursty bandwidth) 사용 문제 해결에 도움을 줄 수 있을 것이다.
도 1은 본 발명에 따른 클라이언트 측 ACK 조정 기반 적응 스트리밍 방법이 구현되는 컴퓨터 시스템의 구성을 설명하기 위한 예시도.
도 2는 본 발명에 따른 네트워크 구성을 설명하기 위한 예시도.
도 3는 본 발명에 따른 CLAS와 종래 기술의 따라 ON-OFF 방법을 비교 설명하기 위한 예시 그래프.
도 4은 본 발명의 부분 실시예에 따른 리시브 소켓 버퍼의 사이즈에 따른 다운로드 시간 및 쓰루풋을 설명하기 위한 그래프.
도 5는 본 발명에 따른 리시브 소켓 버퍼 사이즈 조절 및 리키 버킷(Leaky Bucket)을 이용한 스트리밍 방법을 설명하기 위한 블록도.
도 6는 본 발명에 따른 이용 가능한 대역폭(Available BandWidth)을 프로빙하는 방법을 설명하기 위한 그래프.
도 7는 본 발명의 부분 실시예에 따른 하이브리드 비율 적응 알고리즘을 설명하기 위한 그래프.
도 8는 목표 쓰루풋 값을 이용하여 다음 기의 목표 비디오 레이트를 결정하는 방법을 설명하기 위한 하이브리드 비율 적응 알고리즘을 나타내는 예시도.
도 9는 본 발명에 따른 CLAS 방법, BBA 방법, FESTIVE 방법에 따른 비디오 레이트 및 시간 별 청크 다운로드 양을 나타내는 그래프.
도 10는 CLAS 방법, BBA 방법, FESTIVE 방법에 따른 ACK interval에 따른 다운로드 정도를 측정한 그래프.
도 11는 CLAS 방법, BBA 방법, FESTIVE 방법에 따른 스트리밍 서비스의 품질 테스트 결과를 나타내는 그래프.
도 12는 클라이언트와 서버 사이의 RTT 누적 분포를 나타내는 그래프.
도 13은 본 발명에 따른 클라이언트 측 ACK 조정 기반 적응 스트리밍 방법을 설명하기 위한 절차 흐름도.
본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 개시되는 실시예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 것이며, 단지 본 실시예들은 본 발명의 개시가 완전하도록 하며, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 한편, 본 명세서에서 사용된 용어는 실시예들을 설명하기 위한 것이며 본 발명을 제한하고자 하는 것은 아니다. 본 명세서에서, 단수형은 문구에서 특별히 언급하지 않는 한 복수형도 포함한다. 명세서에서 사용되는 "포함한다(comprises)" 및/또는 "포함하는(comprising)"은 언급된 구성소자, 단계, 동작 및/또는 소자는 하나 이상의 다른 구성소자, 단계, 동작 및/또는 소자의 존재 또는 추가를 배제하지 않는다.
이하, 본 발명의 바람직한 실시예에 대하여 첨부한 도면을 참조하여 상세히 설명하기로 한다.
도 1은 본 발명에 따른 클라이언트 측 ACK 조정 기반 적응 스트리밍 방법이 구현되는 컴퓨터 시스템의 구성을 설명하기 위한 예시도이다.
한편, 본 발명의 실시예에 따른 클라이언트 측 ACK 조정 기반 적응 스트리밍 방법은 컴퓨터 시스템에서 구현되거나, 또는 기록매체에 기록될 수 있다. 도 1에 도시된 바와 같이, 컴퓨터 시스템은 적어도 하나 이상의 프로세서(110)와, 메모리(120)와, 사용자 입력 장치(150)와, 데이터 통신 버스(130)와, 사용자 출력 장치(160)와, 저장소(140)를 포함할 수 있다. 전술한 각각의 구성 요소는 데이터 통신 버스(130)를 통해 데이터 통신을 한다.
컴퓨터 시스템은 네트워크(180)에 연결된 네트워크 인터페이스(170)를 더 포함할 수 있다. 상기 프로세서(110)는 중앙처리 장치(central processing unit (CPU))이거나, 혹은 메모리(130) 및/또는 저장소(140)에 저장된 명령어를 처리하는 반도체 장치일 수 있다.
상기 메모리(120) 및 상기 저장소(140)는 다양한 형태의 휘발성 혹은 비휘발성 저장매체를 포함할 수 있다. 예컨대, 상기 메모리(120)는 ROM(123) 및 RAM(126)을 포함할 수 있다.
따라서, 본 발명의 실시예에 따른 클라이언트 측 ACK 조정 기반 적응 스트리밍 방법은 컴퓨터에서 실행 가능한 방법으로 구현될 수 있다. 본 발명의 실시예에 따른 클라이언트 측 ACK 조정 기반 적응 스트리밍 방법이 컴퓨터 장치에서 수행될 때, 컴퓨터로 판독 가능한 명령어들이 본 발명에 따른 운영 방법을 수행할 수 있다.
한편, 상술한 본 발명에 따른 클라이언트 측 ACK 조정 기반 적응 스트리밍 방법은 컴퓨터로 읽을 수 있는 기록매체에 컴퓨터가 읽을 수 있는 코드로서 구현되는 것이 가능하다. 컴퓨터가 읽을 수 있는 기록 매체로는 컴퓨터 시스템에 의하여 해독될 수 있는 데이터가 저장된 모든 종류의 기록 매체를 포함한다. 예를 들어, ROM(Read Only Memory), RAM(Random Access Memory), 자기 테이프, 자기 디스크, 플래시 메모리, 광 데이터 저장장치 등이 있을 수 있다. 또한, 컴퓨터로 판독 가능한 기록매체는 컴퓨터 통신망으로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 읽을 수 있는 코드로서 저장되고 실행될 수 있다.
본 발명에 따른 클라이언트 측 ACK 조정 기반 적응 스트리밍 장치는 스트리밍 처리 모듈을 제공하기 위한 프로그램이 저장된 메모리; 및 상기 프로그램을 실행시키는 프로세서를 포함하되, 상기 프로세서는 상기 프로그램을 실행시킴에 따라, 비디오 세그먼트의 목표 다운로드 시간(Goal Download Time, GDT)를 변경하여 앱 버퍼 레벨을 조정하고; 상기 조정된 GDT를 이용하여 토큰의 크기를 결정함으로써 리키 버킷을 토대로 리시브 소켓 읽기를 조절하고; 상기 결정된 토큰 크기를 토대로 리시브 소켓 버퍼의 크기를 제어하고; 이용 가능한 대역폭을 프로빙하고; 프로빙한 이용 가능한 대역폭과 상기 앱 버퍼 레벨을 토대로 목표 쓰루풋을 결정하고; 및 상기 목표 쓰루풋을 이용하여 다음 주기에서의 비디오 레이트를 결정하는; 것을 특징으로 한다.
도 2는 본 발명에 따른 네트워크 구성을 설명하기 위한 예시도이다.
HTTP 스트리밍 서버는 CDN(content delivery network)에 있고, 다수의 스트리밍 클라이언트가 하나의 AP에 연결되어 무선 병목 링크를 공유하고 있다. 각 클라이언트는 소켓 버퍼 및 애플리케이션 버퍼를 가지고 있고, 상기 버퍼 및 네트워크 상황에 따라 비디오 레이트를 결정하여 HTTP 스트리밍 서버에 요청을 보내고, HTTP 스트리밍 서버는 해당 비디오 세그먼트를 보내어 응답한다.
최근 서비스되는 적응형 비디오 스트리밍 방법은 네트워크 상황과 네트워크 수요에 따라서 비디오 품질을 동적으로 조정하여 적절한 서비스 품질을 제공한다. 그러나, 몇몇 연구는 몇몇 구독자가 병목 연결을 공유할 때 무선 인터넷 환경에서 적응형 비디오 스트리밍 서비스가 형편없는 성능을 보여줄 수 있음을 지적하였다.
본 발명에서는 CLAS(CLient-side Adaptive Streaing)라는 기발한 비디오 레이트 선택 스키마를 제공할 것이다. 통상 비디오 레이트는 스트리밍 서비스하고자하는 비디오의 품질을 의미한다. 그러나, 스트리밍 서비스하는 비디오의 생성 및 압축 방법에 따라 비디오 품질과 달리 용량이 상이할 수 있으므로, 비디오 레이트는 1초 당 플레이 되는 평균적인 비디오의 용량을 기준으로 분류한다. 일반적으로 같은 코덱의 비디오 영상을 기준으로 비디오 레이트의 클수록 품질이 상승하게 된다. 네트워크 상황이 좋을 경우에는 높은 수준의 비디오 레이트를 가지는 비디오로 서비스하며, 네트워크 상황이 나쁠 경우에는 낮은 수준의 비디오 레이트를 가지는 비디오로 서비스하게 된다. HTTP 스트리밍 서버는 비디오 파일 데이터를 일정 시간 간격(청크 타임 T, 예컨대, T=4초) 별로 조각낸 비디오 세그먼트(video segment 혹은 청크, chunk)를 비디오 레이트 별로 다수 보유하고, 네트워크 상황에 따라 적절한 비디오 레이트의 비디오 세그먼트를 스트리밍 클라이언트에 서비스하게 된다.
스트리밍의 품질(QoE, Quality of Experience)는 몇 가지 기준에 따라, 평가될 수 있다. 예컨대, 서비스 되는 비디오 레이트(Video Rate), 비디오 레이트의 변화 정도(Instability), 다수의 클라이언트 사이의 공정성(Unfairness), 클라이언트에서 발생하는 리버퍼링 횟수(Rebuffering number), 비디오 세그먼트 당 평균 다운로드 시간인 청크 다운로드 시간(Chunk Download Time)를 이용하여 스트리밍 품질을 평가할 수 있다.
상기 CLAS 방법은 이용 가능한 대역폭(available bandwidth, ABW) 예측과 비디오 레이트 선택의 방법을 이용하여 스트리밍 품질(QoE)을 향상 시키고자 한다. 통상 스트리밍 서비스는 하나의 클라이언트가 AP의 자원을 너무 많이 사용하는 것을 방지하기 위하여 ON-OFF 전송 패턴을 사용하기 때문에, 이용 가능한 대역폭(ABW)을 측정하기 어려운 문제가 있다. OFF 구간에서는 ABW를 측정하는 것이 불가능하고, ON 구간에서만 측정 결과를 이용하여 ABW를 추정하는 것은 부정확하기 때문이다. 본 발명에서는 OFF 구간을 제거하고, 클라이언트 측에서 전송율을 조정함으로써 일정한 수준의 전송율을 유지하고자 한다.
도 3는 본 발명의 CLAS 방법과 종래 기술의 ON-OFF 방법에 따른 전송 패턴을 비교 설명하기 위한 예시 그래프이다.
상단 그래프는 본 발명인 CLAS 방법에 따른 전송 패턴이고, 하단 그래프는 종래 기술에 따른 ON-OFF 방법에 따른 전송 패턴을 나타낸다. CLAS 방법에 따르면, 전체 시간에 걸쳐서 비디오 스트리밍을 다운로드하고 있는 것을 확인할 수 있고, ON-OFF 방법에 따르면, 일정 시간 집중적으로 다운로드 받은 후(ON 기간), 일정 시간 동안은 전혀 다운로드 하지 아니한다(OFF 기간).
최근 발전된 국가(developed countries)에서 피크 시간에 실시간 엔터테인먼트 트래픽은 전체 트래픽의 70% 이상을 차지하고 있고, 무선 인터넷 및 스마트 모바일 장치의 채용에 따라 비디오 스트리밍은 차지하는 비중은 점점 증가할 것으로 예상된다. 동일한 무선 인터넷 환경 내에서 동시에 스트리밍 서비스를 하는 것은 흔한 일이다. 비디오 서비스를 위하여 전체 데이터를 다운 받는 대신, 작은 사이즈로 나뉘어진 비디오 세그먼트 또는 청크(chunk) 단위로 다운로드하여 플레이하게 된다. 또한, 적응형 스트리밍 서비스는, 예컨대 매우 주목할만한 DASH(Dynamic Adaptive Streaming over HTTP) 서비스는 사용자의 네트워크 상황에 따라 적절한 품질의 비디오 세그먼트를 선택할 수 있도록 한다.
좋은 네트워크 환경에서는 높은 비디오 레이트로 서비스하고, 반면의 경우, 낮은 비디오 레이트로 서비스하게 된다.
스트리밍 서비스 유저의 QoE(Quality of Experience)는 비디오 레이트에 비례하여 증가하므로, 스트리밍 서비스 시스템은 네트워크의 이용 가능한 대역폭(ABW)를 예측하여 네트워크가 유지될 수 있는 최대의 비디오 레이트로 서비스하게 된다. 이러한 기술을 ABR(adaptive bit rate selection)이라 부른다. 최근 몇 년 동안 많은 연구자들이 ABR 문제를 공격하면서, 다수의 재치 있는 장치를 고안하였다.
몇 가지 방법은 버퍼의 역할을 강조하고, 버퍼 레벨을 토대로 전송 속도를 결정한다. 네트워크 대역을 연속적으로 사용하는 FTP와 같은 서비스와 달리, 적응형 스트리밍 서비스는 네트워크 대역을 간헐적으로 사용(ON-OFF 방법)하게 된다. 다만, 연구자에 따르면, ON-OFF 방법을 사용할 경우, 적응형 스트리밍 서비스의 형편없는 성능, 불공정성, 불안정성이 발견되었다.
본 발명에서는 데이터 전송 비율을 조정하여, ON-OFF 패턴을 제거하거나, 아주 짧은 시간 내에서 ON-OFF 패턴을 구현함으로써 부정확한 ABW 예측을 개선하였다. TCP 연결은 혼잡 윈도우(congestion window)와 알려진 윈도우(advertised window, 리시버로부터 전송받은 리시브 윈도우 크기)를 이용하여 전송 비율을 결정한다. 이를 혼잡 제어(congestion control) 이라 부른다.
혼잡 제어의 경우, 느린 시작(slow start), 혼잡 회피(congestion avoidance), 빠른 전송(fast transmission), 빠른 복구(fast recovery)의 메커니즘에 따라 이루어진다. 서버의 전송율이 꽉 차도록 적절한 소켓 버퍼 사이즈를 고정하고, 버퍼 읽기 비율을 제어한다. 데이터 세그먼트의 전송을 제한함으로써 ON-OFF 패턴을 제거하고 ABW를 정확하게 예측하여 다음 세그먼트에 가장 적합한 비디오 레이트(bit rate) 결정한다.
본 발명의 효과는 다른 알려진 클라이언트 측 스트리밍 방법인 FESTIVE와 BBA(Buffer-Based Adaptation)와 비교할 것이다. 예측된 ABW과 앱 버퍼 레벨을 토대로 CLAS 방법은 가장 적합한 비디오 레이트를 선택한다. 본 발명에 따르면 평균 비디오 레이트는 20% 증가하였고, 리버퍼링 레이트는 FESTIVE, BBA 대비 현저하게 감소하였다.
도 4은 본 발명의 부분 실시예에 따른 리시브 소켓 버퍼의 사이즈에 따른 다운로드 시간 및 쓰루풋을 설명하기 위한 그래프이다.
본 발명에 따르면 리시브 소켓 버퍼는 RTT(Round Trip Time)에 따라 정하여 진다. 예컨대, 서울에 있는 AP에 연결된 클라이언트가 부산에 있는 서버에 연결하는 경우 측정된 RTT는 13ms이었고, 미국 오레건주에 위치한 서버에 연결하는 경우 측정된 RTT는 130ms 이었다.
도 4의 상단 그래프는 리시브 소켓 버퍼 사이즈가 클수록 다운로드 시간이 감소하나 일정 수준(40KB)을 초과하면 감소하는 수준이 저하되는 것을 나타낸다. 도 4의 하단 그래프는 리시브 소켓 버퍼 사이즈가 클수록 쓰루풋이 상승하는 것을 알 수 있다. TCP 프로토콜 상 리시브 소켓 버퍼의 사이즈는 무한정 크게 할 수는 없는 것이고, 리시브 소켓 버퍼의 사이즈를 적절하게 조정함으로써, 다운로드 시간을 감소시키고, 쓰루풋을 증가시킬 수 있다.
도 5는 본 발명에 따른 리시브 소켓 버퍼의 사이즈 조절 및 리키 버킷(Leaky Bucket)을 이용한 스트리밍 방법을 설명하기 위한 블록도를 나타낸다.
기존의 적응형 스트리밍 방법은 ON-OFF 제약 조건 하에서 ABW를 정확히 측정하는 것이 방해받기 때문에, 대부분의 ABR 기술들은 ON-OFF 제약 조건 하에서 ABW를 정확하게 예측하는 것에 초점이 맞추어져 있다. 본 발명은 데이터 전송율을 조정하여 ON-OFF 패턴을 제거한다. 트래픽을 조정하기 위하여 기존 기술들은 서버 측에 리키 버킷(Leaky Bucket)을 구축하는 방법을 주로 사용하나, 본 발명의 경우 클라이언트 측에 리키 버킷을 구축하는 것에 차이가 있다.
본 발명에 따라 클라이언트 측에 도착하는 패킷을 일정하게 유지하도록 데이터 전송을 조정하는 것은 최초의 시도이다. 기존 기술들은 서버 측에 리키 버킷을 구축하기 때문에 클라이언트로부터 네트워크 상황 등을 전송받아야 하므로, 제어 지연이 발생하고 확장성이 제한되는 문제가 있다.
DASH와 같은 적응형 스트리밍 서비스는 TCP ACK 전송 방법을 이용하여 전송 비율(sending rate)을 조정하므로, 본 발명에 따르면, 혼잡 윈도우 사이즈(cwnd)가 클 때, 서버가 ACK 신호를 받지 않고, 다수의 세그먼트 전송하기 때문에, 서버를 조정할 수 없는 문제가 있다.
본 발명에서 리시브 소켓 윈도우 사이즈(rwnd)를 제어함으로써 서버 측의 TCP 흐름 제어는 MIN(cwnd, rwnd) 값을 한계값으로 갖게 된다. rwnd은 다음 식을 따르게 된다.
Figure 112016120610359-pat00001
센드 소켓 버퍼의 이용 가능한 버퍼(number of inflight segments)는 다음 수식에 의하여 정하여진다.
Figure 112016120610359-pat00002
cwnd는 서버측에서 결정되는 값이지만, rwnd는 클라이언트 측에서 결정되는 값이므로, 클라이언트 측의 리시브 소켓 버퍼의 rwnd 값을 조정함으로써, 서버 측센드 소켓의 이용 가능한 버퍼를 조정할 수 있다.
상기 rwnd의 값은 서버와 클라이언트 사이의 RTT(Round Trip Time) 값을 토대로 결정하게 된다. RTT는 클라이언트에서 서버로 요청한 후, 그 응답을 받을 때까지의 시간을 의미한다. 통상 RTT는 서버와 클라이언트 사이에 연결된 라우터의 수에 의하여 결정되는 경향이 있다.
상술한 리시브 소켓 버퍼의 사이즈와 관련하여 rwnd 값을 조정하더라도, ON-OFF 패턴이 제거되지 않을 수 있다. 도 4의 상단 그래프를 보면, 리시브 버퍼 사이즈가 작더라도, 다운로드 타임이 충분히 짧을 수 있기 때문에, 리시브 버퍼 사이즈 조정만으로는 ON-OFF 패턴을 완전히 제거할 수는 없게 된다.
ON-OFF 패턴을 제거하여 부드럽고, 연속적인 패킷 전송을 위하여, 더 정밀한 제어를 요한다. 본 발명에서는 클라이언트 측에 리키 버킷을 구현하여 이를 해결하고자 한다.
리키 버킷(Leaky Bucket)은 클라이언트 측의 리시브 소켓의 읽기 함수를 제어하기 위한 구조이다. TCP 소켓의 읽기 함수는 서버로부터 전달받은 데이터를 미리 설정된 앱 버퍼에 채우는데, 리키 버킷에 채워진 토큰 수만큼 앱 버퍼를 채움으로써, ON-OFF 패턴을 제거하고자 한다. 상기 앱 버퍼는 통상 비디오 플레이어의 버퍼를 의미할 수 있으며, 리시브 소켓 버퍼와 대비하여, 훨씬 크다. 스트리밍 서비스를 통하여 비디오 플레이어를 작동시키는 경우 앱 버퍼에는 수십 초 이상의 비디오 클립이 저장될 수 있다. 저장된 비디오 클립의 용량을 초 단위로 환산한 값을 본 발명에서는 앱 버퍼 레벨 B(t)로 나타낸다.
토큰은 현재 비디오 레이트에 따라 생성되고, 클라이언트는 리시브 소켓 버퍼로부터 토큰 수에 해당하는 만큼을 애플리케이션 버퍼로 읽어온다. 통상 x bit 토큰에 대하여 x bit 의 비디오 데이터를 읽어온다. 이를 버퍼 레벨 제어 매커니즘이라 한다. 도 3의 상단 그래프는 리시브 소켓의 버퍼 사이즈 조절하고, 리시브 소켓과 애플리케이션 버퍼 사이에 토큰을 이용한 리키 버키 구조를 구현한 CLAS 방법을 이용하여 얻은 것이다. 반면, 도 3의 하단 그래프는 ON-OFF 패턴을 이용하는 적응형 스트리밍 방법에 따라 얻은 데이터이다.
본 발명에 따른 클라이언트 측 ACK 조정 기반 적응 스트리밍 방법은 비디오 세그먼트의 목표 다운로드 시간(Goal Download Time, GDT)를 변경하여 앱 버퍼 레벨을 조정하는 단계; 상기 조정된 GDT를 이용하여 토큰 크기를 결정함으로써 리키 버킷을 토대로 리시브 소켓 읽기를 조절하는 단계; 및 상기 결정된 토큰 크기를 토대로 리시브 소켓 버퍼의 사이즈를 제어하는 단계;를 포함한다.
상기 목표 다운로드 시간은 다음 수식에 의하여 변경된다.
Figure 112016120610359-pat00003
T는 비디오 세그먼트의 플레이 시간이고, g는 0<g<1을 만족하나, 앱 버퍼 레벨(B(t))이 클수록 0에 가까운 값을 가지고, 앱 버퍼 레벨이 작을수록 1에 가까운 값을 가진다. 예컨대, g는 B(t)에 따라 g∈[0, 0.75]를 만족하도록 계단 함수로 표시할 수 있다.
통상 비디오 세그먼트의 플레이 시간을 의미하는 청크 시간 T는 4초일 수 있다. 이때, 목표 다운로드 시간(GDT)는 4초 이내이어야 한다. GDT가 4초를 초과하면, 비디오를 다운로드 받는 시간이 플레이하는 시간을 초과하기 때문에 원활하게 비디오를 플레이할 수 없게 된다. 비디오 세그먼트 당 RTT 1회를 소모할 수 있으므로, (T-minRTT)는 GDT의 상한으로 한다. RTT는 비디오 스트리밍 서비스를 제공하는 CDN(Content Delivary Network)에 HTTP get 요청을 하여, 그 응답이 온 시간을 기준으로 산출할 수 있다. 이는 실제 RTT와 거의 같은 값을 가진다. 앱 버퍼 레벨이 충분하고, minRTT가 작으면 GDT는 T와 거의 같게 된다. 즉, 비디오 세그먼트가 플레이되는 시간(T)과 해당 비디오 세그먼트가 다운로드되는 시간(Chunk Download Time)이 거의 같게 된다.
앱 버퍼 레벨이 낮다면, 미리 다운로드된 영상이 적다는 것이므로, GDT를 줄여서(g값을 크게 해서), 앱 버퍼 레벨을 높일 수 있을 것이다.
본 발명에서 리시브 소켓 버퍼에 저장된 비디오 데이터를 읽어와서 앱 버퍼에 저장하는 것은 생성된 토큰에 의하여 결정된다. 토큰의 생성 주기는 RTT를 기준으로 한다. 1회에 생성하는 토큰의 크기(
Figure 112016120610359-pat00004
)는 다음 수식에 의하여 결정된다.
Figure 112016120610359-pat00005
Figure 112016120610359-pat00006
는 i번째 비디오 세그먼트를 의미한다.
Figure 112016120610359-pat00007
는
Figure 112016120610359-pat00008
의 파일 사이즈를 의미한다. RTT는 round trip time으로 클라이언트의 요청이 발신되어 서버의 응답이 수신될 때까지의 시간을 의미한다. GDT는 상술한 목표 다운로드 시간을 의미한다.
예컨대,
Figure 112016120610359-pat00009
가 2,000,000 Bytes이고, RTT가 13ms이고, GDT가 3.2초이면, 토큰의 크기(
Figure 112016120610359-pat00010
)는 8,125 bytes가 된다. GDT(=3.2초) 동안, RTT(=13ms)주기로 약 246회의 전송이 이루어지므로, GDT(=3.2초) 동안, 약 2,000,000 Bytes을 수신하게 된다. 다만, GDT는 목표 다운로드 시간이고, 실제로 RTT 동안 8,125 bytes를 모두 수신하지 못할 수 있고, GDT 동안, 246회 미만의 전송횟수가 발생할 수 있으므로, 실제 다운로드 시간(
Figure 112016120610359-pat00011
)는 GDT를 초과할 것이다. 그러나, 데이터를 1회 다운로드하는 시간은 RTT 보다 작아지기 힘들기 때문에 실제 다운로드 시간(
Figure 112016120610359-pat00012
)는 GDT보다 작은 경우는 드물다.
리시브 소켓 버퍼의 사이즈(
Figure 112016120610359-pat00013
)는 상기 토큰의 크기(
Figure 112016120610359-pat00014
)를 토대로 다음식에 의하여 결정된다.
Figure 112016120610359-pat00015
이상적인 네트워크를 가정할 때, 데이터 패킷이 연속적으로 입력되면, 리시브 소켓 버퍼의 사이즈(
Figure 112016120610359-pat00016
)는 상기 토큰의 크기(
Figure 112016120610359-pat00017
)와 같아도 된다. 그러나, 실제 네트워크 상에서 TCP 특성상 패킷이 버스티(bursty)하게 입력되므로, 소켓 버퍼 사이즈를 토큰의 크기보다 다소 크게 설정한다. 도 9 내지 12의 경우, d=1로 설정하여 얻은 결과이나, 이는 발명의 권리범위를 제한하지는 않는다. 예컨대, d=2 또는 d=3이어도 버스티(bursty)한 결과가 나오지 않는 것을 확인하였다.
도 6는 본 발명에 따른 이용 가능한 대역폭(Available BandWidth)을 프로빙하는 방법을 설명하기 위한 그래프이다.
통상 ABW(Available BandWidth, 이용 가능한 대역폭)은 쓰루풋(Throughput)을 추정하여 사용한다. 스트리밍 애플리케이션의 경우, 쓰루풋은
Figure 112016120610359-pat00018
을 이용한다. 그러나, 본 발명에서는
Figure 112016120610359-pat00019
> GDT 이므로, 쓰루풋은 네트워크 환경이 양호한 경우에도
Figure 112016120610359-pat00020
이하이므로, 실제 네트워크 환경상에 ABW가
Figure 112016120610359-pat00021
이상인 경우에도 그 사실을 알 수 없는 문제가 있다. 다시 말하면, 쓰루풋을 ABW로 그대로 사용할 수 없는 문제가 있다. 본 발명에서는 ABW를 정확하게 예측하기 위하여, ABW를 프로빙하는 방법을 고안하였다.
ABW 프로빙 방법은 일반구간(N)과 프로빙 구간(P)으로 나누어 실행된다. 상기 일반 구간(N)은 상술한 데이터 스트리밍 방법을 이용하고, 상기 프로빙 구간(P)은 소수의 RTT 단위의 주기를 포함하고, 상기 프로빙 구간(P)에서는 더 높은 비디오 레이트를 기준으로 생성되는 토큰의 크기를 결정한다.
상기 수학식 4에 따르면, 더 높은 비디오 레이트의
Figure 112016120610359-pat00022
값이 더 크므로, 토크의 크기도 증가하여 더 많은 데이터를 수신하게 된다. 더 높은 비디오 레이트를
Figure 112016120610359-pat00023
라고 하면,
Figure 112016120610359-pat00024
)=
Figure 112016120610359-pat00025
* (청크 사이즈)가 되므로, 생성되는 토큰의 크기(t
Figure 112016120610359-pat00026
), 리시브 소켓 버퍼의 크기(
Figure 112016120610359-pat00027
)는 각각 다음 수학식을 따른다.
Figure 112016120610359-pat00028
Figure 112016120610359-pat00029
상기 일반 구간과 프로빙 구간에서 측정되는 쓰루풋은 각 구간에서의 평균값을 사용할 수도 있으나, EWMA(Exponentially weighted moving average)한 값으로 산출할 수 있다. 상기 일반 구간과 프로빙 구간에서의 쓰루풋을 측정하고, 이 중에 작지 아니한 값을 목표 쓰루풋(target throughput)으로 결정한다. 목표 쓰루풋은 예측된 이용 가능한 대역폭(estimated available bandwidth, 예측된 ABW)으로 볼 수 있다. 다만, 예측된 ABW 뿐만 아니라, 앱 버퍼 레벨을 함께 고려하여 목표 쓰루풋을 결정할 수 있다. 이러한 방법을 예측된 ABW와 앱 버퍼 레벨을 동시에 고려하는 점에서 하이브리드 비율 선택(hybrid rate selection) 방법이라 한다.
도 6의 그래프는 다수의 클라이언트가 사용 중일 경우, 클라이언트의 프로빙 구간이 겹치지 않도록, 프로빙 구간은 2*RTT 동안, 일반 구간은 Rand(3,5,7)*RTT 동안 유지하는 것을 전제로 작성되었으나, 동시에 다수의 클라이언트가 프로빙 구간에 있는 것을 방지하기 위하여 프로빙 구간과 일반 구간의 크기는 적절하게 조정될 수 있는 것이고, 발명의 권리범위를 제한하는 것이 아니다. 예컨대, 프로빙 구간은 3*RTT로 설정하고, 일반 구간을 Rand(5,7,11)*RTT로 설정해도 무관하다.
도 7는 본 발명의 부분 실시예에 따른 하이브리드 비율 적응 알고리즘을 설명하기 위한 그래프이다.
도 7의 상단 그래프는 시간의 흐름에 따른 리시브 소켓의 버퍼 사이즈와 전송받은 데이터 양을 표시하고 있다. 도 7의 중단 그래프는 시간의 흐름에 따른 리키 버킷에 포함된 토큰의 갯수를 표시하고 있고, 도 7의 하단 그래프는 시간의 흐름에 따른 ABW 측정치를 표시하고 있다. 도 7의 그래프는 모두, 11.2초 지점에서 목표 비디오 레이트(target video rate)을 4Mbps에서 5Mbps로 증가시킨 결과를 나타내고 있다. 11.2초 근방의 프로빙 구간에서 네트워크 상황이 좋아진 것을 프로빙하여 목표 비디오 레이트를 상향시킴으로써 더 좋은 품질의 비디오 스트리밍 서비스를 받을 수 있게 되었다.
도 6의 설명에서와 같이 결정된 쓰루풋 값을 이용하여 다음 단계의 목표 비디오 레이트를 변경한다. 비디오 레이트가 변경되면, 비디오 세그먼트의 파일 사이즈도 변경되고, 앱 버퍼 레벨에 영향을 미치므로, GDT(Goal Download Time, 목표 다운로드 시간), 토큰의 크기, 리시브 소켓 버퍼의 크기에도 영향을 미치므로, 도 7의 그래프와 같이 전후로 스트리밍 서비스의 품질(QoE)이 변경된다.
도 8는 목표 쓰루풋 값을 이용하여 다음 기의 목표 비디오 레이트를 결정하는 방법을 설명하기 위한 하이브리드 비율 적응 알고리즘을 나타낸다.
i번째 세그먼트(청크)와 i번째 세그먼트의 비디오 레이트를 각각 Si, Vi라 하고, 한 단계 높은 비디오 레이트를 Vi+1, 한 단계 낮은 비디오 레이트를 Vi-1로 두자.
도 8의 수도 코드(pseudo code)에서 ABi는 도 6에서 산출한 목표 쓰루풋을 나타낸다. fT(B(t), ABi)는 하이브리드 목표 쓰루풋을 나타낸다. i번째 세그먼트의 EWMA(exponentially weighted moving average)한 목표 쓰루풋 값 이용할 수 있다. 프로빙 구간의 쓰루풋과 일반 구간의 쓰루풋 중 작지 아니한 값을 예측된 이용 가능한 대역폭 ABi로 산출하되, 앱 버퍼 레벨을 고려하여 하이브리드 목표 쓰루풋 값을 산출한다. fT(B(t), ABi)는 간단히 다음 수식을 이용할 수 있다.
Figure 112016120610359-pat00030
r은 B(t)가 클수록 작고, B(t)가 작을수록 크며, 0≤r<1을 만족한다.
실험적으로 0≤r<0.4 를 사용하였으나, 이는 본 발명의 권리범위를 제한하지 아니한다.
앱 버퍼 레벨(B(t))이 높을수록, 비디오 레이트를 높게 결정할 수 있으므로, B(t)가 높을수록 r를 작게 설정하고, B(t)가 작으면 r을 높게 설정하여, 목표 쓰루풋값이 작아지므로, 목표 비디오 레이트도 작아지므로, 앱 버퍼를 빠르게 채워서 앱 버퍼 레벨을 높일 수 있을 것이다.
앱 버퍼 레벨(B(t))이 증가할수록, a는 감소하고, b는 증가한다.
첫번째 if문은 비디오 레이트를 감소 시키는 것으로, 앱 버퍼 레벨(B(t))이 크면, 목표 쓰루풋(Vi+1)도 크고, b도 크므로, 첫번째 if문에 포함되지 않을 확률이 커진다. 앱 버퍼 레벨(B(t))이 작으면 목표 쓰루풋(Vi+1)도 작고, b도 작으므로, 첫번째 if문에 포함되어 (i+1)번째 비디오 세그먼트에서 목표 비디오 레이트 낮추게 될 가능성이 클 것이다. 다만, 제시된 Vmin을 하한으로 한다.
두번째 else if문은 비디오 레이트를 증가 시키는 것으로, 앱 버퍼 레벨(B(t))가 크면 목표 쓰루풋(Vi+1)도 크고, b는 작으므로, (i+1)번째 비디오 세그먼트에서 목표 비디오 레이트 높일 수 있을 것이다. 다만 앱 버퍼 레벨(B(t))이 작다면, 두번째 else if문이 적용되지 않을 것이다.
비디오 레이트를 증가시키거나 감소시키지 않는 경우는 비디오 레이트가 유지될 것이며, 마지막 else에 의하여 처리되는 것이다.
도 9는 본 발명에 따른 CLAS 방법, BBA 방법, FESTIVE 방법에 따른 비디오 레이트 및 실제 청크 다운로드 시간의 누적 분포를 그래프로 나타낸다.
도 9의 오른쪽 그래프에서 본 발명에 따른 CLAS 방법에 의하는 경우, t=4초 근방에서 실제 청크 다운로드 시간의 분포가 가장 높은 것을 알 수 있다. 본 발명에 CLAS 방법은 앱 버퍼 레벨이 충분한 경우 GDT를 비디오 청크의 플레이 타임(청크 타임 T, 예컨대, T=4초)에 가깝게 조정하기 때문에 CLAS 방법을 사용하는 경우, 실제 청크의 다운로드 시간은 T 근방에서 밀도가 가장 높을 것이다. 반면, BBA 방법 및 FESTIVE 방법은 ON-OFF 패턴을 유지하며 다운로드하기 때문에 실제 청크 다운로드 시간은 T 보다 작게 된다. BBA 방법 및 FESTIVE 방법은 OFF 기간으로 인하여, 대역폭 이용률이 낮아진다. CLAS 방법의 경우에는 OFF 기간이 존재하지 않고, 시간적으로 분산되어 대역폭을 이용하기 때문에 다수의 클라이언트가 비디오 스트리밍 서비스를 받는 경우, 높은 평균 비디오 레이트를 유지할 수 있다.
도 10는 CLAS 방법, BBA 방법, FESTIVE 방법에 따른 ACK interval 누적 분포를 나타낸다. 상단 그래프는 하나의 AP에 연결된 하나의 클라이언트가 스트리밍 서비스를 받는 경우에 하나의 클라이언트에서 측정한 것이고, 하단 그래프는 하나의 AP에 연결된 4개의 클라이언트가 스트리밍 서비스를 받는 경우에 하나의 클라이언트에서 측정한 것이다. BBA 방법과 FESTIVE 방법은 TCP 특성에 의존하기 때문에 초반에 버스티(bursty)한 경향이 있음을 확인할 수 있다. 반면, CLAS 방법은 읽기 조정 방법을 사용하므로, 보다 분산적인 ACK interval 분포를 확인할 수 있다.
도 11는 CLAS 방법, BBA 방법, FESTIVE 방법에 따른 스트리밍 서비스의 품질 테스트 결과를 나타내는 그래프이다.
스트리밍 서비스의 품질은 비디오 레이트(video rate), 안정성(instability), 공정성(unfairness), 리버퍼링 횟수(Rebuffering Number), 비디오 세그먼트 당 평균 다운로드 시간인 청크 다운로드 시간(Chunk Download Time)을 이용하여 평가한다.
비디오 레이트는 CLAS 방법이 가장 우수하고, FESTIVE 방법이 가장 열악한 것을 확인할 수 있다.
안정성이란, 일정 시간 동안(예컨대, 20초) 비디오 레이트가 바뀌는 횟수를 측정하여 바뀌는 횟수가 많은 것을 불안정한 것(instability)으로 보았다. 실제 동영상 시청시 비디오 레이트가 자주 변하는 경우, 시청자가 불편함을 느끼게 된다. 안정성 측면에서는 FESTIVE 방법이 가장 우수하고, BBA 방법이 가장 열악한 것을 확인할 수 있다. 안정성을 측정하는 것은 다양한 방법을 사용할 수 있다. 예컨대, 20초 단위 동안 비디오 레이트가 바뀐 횟수를 카운팅하고, 이를 1초 단위로 반복하여 전체 비디오 스트리밍 서비스에 대하여 산출할 수 있다.
공정성은 다수의 클라이언트의 평균 비디오 레이트의 표준편차를 이용하여 표준편차가 클수록 불공정한 것(unfairness)으로 판단하였다. CLAS 방법이 가장 공정하고, FESTIVE 방법이 가장 불공정한 것으로 확인되었다.
앱 버퍼에 저장된 동영상 데이터가 소진되면, 원활한 동영상 플레이를 위하여 비디오 재생이 잠시 중단된 상태로 앱 버퍼에 가까운 미래에 플레이할 동영상 데이터를 저장하는 것을 리버퍼링이라 하는데, 리버퍼링 횟수가 많을수록 QoE(Quality of Experience)가 안 좋다. 리버퍼링 횟수 측면에 CLAS 방법이 가장 우수하고, FESTIVE 방법이 가장 열악하였다.
가장 오른쪽 그래프는 비디오 세그먼트 당 평균 다운로드 시간인 청크 다운로드 시간(Chunk Download Time)의 누적 분포를 나타낸다. BBA 방법과 FESTIVE 방법은 버스티(bursty)한 경향과 함께 OFF 기간을 제거하지 못해 청크 시간 T에 비해 짧은 쪽에 청크 다운로드 시간의 밀도가 높은 것을 알 수 있다. 반면, CLAS 방법은 읽기 조정 방법을 이용하여 OFF 기간을 제거하고 전체 스트리밍 구간 걸쳐서 분산적으로 다운로드되는 것을 확인할 수 있다.
도 12는 클라이언트와 서버 사이의 RTT 누적 분포를 나타낸다.
상단의 그래프는 클라이언트와 부산에 있는 서버 사이의 RTT 누적 분포를 나타내며, 하단의 그래프는 클라이언트와 미국 오레곤 주에 있는 서버 사이의 RTT 누적 분포를 나타낸다.
BBA 방법과 FESTIVE 방법은 버스티(bursty)한 방법으로 다운로드가 진행되므로, 다수의 클라이언트가 병목 연결에 의하여 비디오 스트리밍 서비스를 받게 되면, RTT 시간이 더 커지게 되는데, BBA 방법과 FESTIVE 방법의 경우, 평균 RTT값이 CLAS 방법보다 더 크게 될 것을 도 12로부터 알 수 있다. 하단의 그래프는 미국 오레곤 주의 서버와 연결되어 RTT 값이 10배정도 크게 나오는 것을 제외하고는 상단의 그래프와 유사한 패턴을 확인할 수 있다.
도 13은 본 발명에 따른 클라이언트 측 ACK 조정 기반 적응 스트리밍 방법을 설명하기 위한 절차 흐름도를 나타낸다.
본 발명에 따른 클라이언트 측 ACK 조정 기반 적응 스트리밍 방법은 비디오 세그먼트의 목표 다운로드 시간(Goal Download Time, GDT)를 변경하여 앱 버퍼 레벨을 조정하는 단계; 상기 조정된 GDT를 이용하여 토큰의 크기를 결정함으로써 리키 버킷을 토대로 리시브 소켓 읽기를 조절하는 단계; 상기 결정된 토큰 크기를 토대로 리시브 소켓 버퍼의 크기를 제어하는 단계; 이용 가능한 대역폭을 프로빙하는 단계; 프로빙한 이용 가능한 대역폭과 상기 앱 버퍼 레벨을 토대로 목표 쓰루풋을 결정하는 단계; 및 상기 목표 쓰루풋을 이용하여 다음 주기에서의 비디오 레이트를 결정하는 단계;를 포함한다.
이상, 본 발명의 구성에 대하여 첨부 도면을 참조하여 상세히 설명하였으나, 이는 예시에 불과한 것으로서, 본 발명이 속하는 기술 분야에 통상의 지식을 가진 자라면 본 발명의 기술적 사상의 범위 내에서 다양한 변형과 변경이 가능함은 물론이다. 따라서 본 발명의 보호 범위는 전술한 실시예에 국한되어서는 아니 되며 이하의 특허청구범위의 기재에 의하여 정해져야 할 것이다.
100: 컴퓨터 시스템
110: 프로세서
120: 메모리
123: ROM
126: RAM
130: 데이터 통신 버스
140: 저장소
150: 사용자 입력 장치
160: 사용자 출력 장치
170: 네트워크 인터페이스
180: 네트워크
500: 클라이언트
510: 커널
520: 리시브 소켓 버퍼
530: 스트리밍 애플리케이션
532: 리키 버킷(leaky bucket)
534: 토큰(token)
536: 앱 버퍼

Claims (7)

  1. 비디오 세그먼트의 목표 다운로드 시간(Goal Download Time, GDT)를 변경하여 앱 버퍼 레벨을 조정하는 단계;
    상기 조정된 GDT를 이용하여 토큰의 크기를 결정함으로써 리키 버킷을 토대로 리시브 소켓 읽기를 조절하는 단계; 및
    상기 결정된 토큰 크기를 토대로 리시브 소켓 버퍼의 크기를 제어하는 단계를 포함하고,
    상기 리시브 소켓 읽기를 조절하는 단계는,
    상기 토큰은 RTT(Round Trip Time)을 주기로 생성되고, 생성되는 토큰의 크기는 상기 비디오 세그먼트의 크기와 상기 RTT에 비례하고, 상기 GDT에 반비례하는 것이고,
    상기 생성된 토큰은 리키 버킷(leaky bucket)에 저장되며, 토큰의 크기 만큼 리시브 소켓 버퍼에 있는 데이터를 읽어 앱 버퍼에 저장하면서 상기 생성된 토큰을 제거하는 것
    인 클라이언트 측 ACK 조정 기반 적응 스트리밍 방법.
  2. 제1항에 있어서,
    이용 가능한 대역폭을 프로빙하는 단계;
    프로빙한 이용 가능한 대역폭과 상기 앱 버퍼 레벨을 토대로 목표 쓰루풋을 결정하는 단계; 및
    상기 목표 쓰루풋을 이용하여 다음 비디오 세그먼트에 대한 비디오 레이트를 결정하는 단계;
    를 더 포함하는 클라이언트 측 ACK 조정 기반 적응 스트리밍 방법.
  3. 제1항에 있어서,
    상기 목표 다운로드 시간은 비디오 세그먼트의 플레이 시간을 상한으로 하고, 상기 앱 버퍼 레벨이 충분할 경우 증가하고, 상기 앱 버퍼 레벨이 부족할 경우 감소하는 것
    인 클라이언트 측 ACK 조정 기반 적응 스트리밍 방법.
  4. 삭제
  5. 비디오 세그먼트의 목표 다운로드 시간(Goal Download Time, GDT)를 변경하여 앱 버퍼 레벨을 조정하는 단계;
    상기 조정된 GDT를 이용하여 토큰의 크기를 결정함으로써 리키 버킷을 토대로 리시브 소켓 읽기를 조절하는 단계; 및
    상기 결정된 토큰 크기를 토대로 리시브 소켓 버퍼의 크기를 제어하는 단계를 포함하고,
    이용 가능한 대역폭을 프로빙하는 단계;
    프로빙한 이용 가능한 대역폭과 상기 앱 버퍼 레벨을 토대로 목표 쓰루풋을 결정하는 단계; 및
    상기 목표 쓰루풋을 이용하여 다음 비디오 세그먼트에 대한 비디오 레이트를 결정하는 단계를 더 포함하고,
    상기 이용 가능한 대역폭을 프로빙하는 단계는,
    하나 이상의 RTT(Round Trip Time) 단위 시간을 포함하는 일반 구간과 하나 이상의 RTT 단위 시간을 포함하는 프로빙 구간에서 프로빙하는 것이고,
    일반 구간과 프로빙 구간에서 각각 이용 가능한 대역폭을 산출하되,
    프로빙 구간에서는 일반 구간에서 스트리밍 되는 비디오 레이트보다 한 단계 높은 비디오 레이트의 세그먼트를 요청하는 것
    인 클라이언트 측 ACK 조정 기반 적응 스트리밍 방법.
  6. 제5항에 있어서,
    상기 목표 쓰루풋을 결정하는 단계는,
    상기 일반 구간에서 산출한 이용 가능한 대역폭과 프로빙 구간에서 산출한 이용 가능한 대역폭을 비교하여 둘 중 작지 아니한 값을 다음 비디오 세그먼트에 대하여 예측된 이용 가능한 대역폭으로 사용하고,
    상기 예측된 이용 가능한 대역폭과 상기 앱 버퍼 레벨을 이용하여 목표 쓰루풋을 산출하는 것
    인 클라이언트 측 ACK 조정 기반 적응 스트리밍 방법.
  7. 제6항에 있어서,
    상기 다음 비디오 세그먼트에 대한 비디오 레이트를 결정하는 단계는,
    상기 앱 버퍼 레벨이 작을수록 상기 다음 비디오 세그먼트의 비디오 레이트를 감소시키고, 상기 앱 버퍼 레벨이 클수록 상기 다음 비디오 세그먼트의 비디오 레이트를 증가시키고,
    상기 예측된 이용 가능한 대역폭이 클수록 상기 다음 비디오 세그먼트의 비디오 레이트를 증가시키고, 상기 예측된 이용 가능한 대역폭이 작을수록 상기 다음 비디오 세그먼트의 비디오 레이트를 감소시키는 것
    인 클라이언트 측 ACK 조정 기반 적응 스트리밍 방법.
KR1020160167001A 2016-12-08 2016-12-08 클라이언트 측 ack 조정 기반 적응 스트리밍 방법 및 장치 KR101837637B1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
KR1020160167001A KR101837637B1 (ko) 2016-12-08 2016-12-08 클라이언트 측 ack 조정 기반 적응 스트리밍 방법 및 장치
US15/385,015 US20180167431A1 (en) 2016-12-08 2016-12-20 Client-side ack regulation based adaptive streaming method and apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020160167001A KR101837637B1 (ko) 2016-12-08 2016-12-08 클라이언트 측 ack 조정 기반 적응 스트리밍 방법 및 장치

Publications (1)

Publication Number Publication Date
KR101837637B1 true KR101837637B1 (ko) 2018-03-13

Family

ID=61660777

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020160167001A KR101837637B1 (ko) 2016-12-08 2016-12-08 클라이언트 측 ack 조정 기반 적응 스트리밍 방법 및 장치

Country Status (2)

Country Link
US (1) US20180167431A1 (ko)
KR (1) KR101837637B1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11425394B2 (en) * 2019-07-24 2022-08-23 Beijing Dajia Internet Information Technology Co., Ltd. Method and apparatus for determining video bit rate, and electronic device

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10911513B2 (en) * 2018-07-16 2021-02-02 Netflix, Inc. Techniques for determining an upper bound on visual quality over a completed streaming session
CN113271612B (zh) * 2020-02-17 2024-04-09 华为技术有限公司 一种随流信息遥测iFIT检测信息的上报方法及装置

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
김서향, 오하영, 김종권, "버퍼 기반 비트율 적응 기법을 응용한 에너지 효율적 Prefetching 기반 동적 적응 비디오 스트리밍." 한국정보과학회 학술발표논문집 (2014): 823-825., 2014.12.31.*
이현노, 김동회, "무선 네트워크에서 비디오 스트리밍의 버퍼 오버플로우를 해결하기 위한 토큰버킷 기법", 디지털콘텐츠학회 논문지 제16권 제3호, 366., 2015.06.*

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11425394B2 (en) * 2019-07-24 2022-08-23 Beijing Dajia Internet Information Technology Co., Ltd. Method and apparatus for determining video bit rate, and electronic device

Also Published As

Publication number Publication date
US20180167431A1 (en) 2018-06-14

Similar Documents

Publication Publication Date Title
US11032343B2 (en) Methods and devices for efficient adaptive bitrate streaming
US9215182B2 (en) Enhancing performance of rapid channel changes and other playback positioning changes in adaptive streaming
US10764610B2 (en) Media user client, a media user agent and respective methods performed thereby for providing media from a media server to the media user client
JP4309185B2 (ja) ストリーミング・メディアの輻輳制御メカニズム
US8346959B2 (en) Client-controlled adaptive streaming
EP3103220B1 (en) System and method for dynamic effective rate estimation for real-time video traffic
US10382356B2 (en) Scheduling transmissions of adaptive bitrate streaming flows
KR102123439B1 (ko) 이동 망에서 비디오 트래픽의 사용자 만족도 최적화를 고려한 혼잡 완화 방법 및 그 장치
KR101837637B1 (ko) 클라이언트 측 ack 조정 기반 적응 스트리밍 방법 및 장치
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
WO2016100890A1 (en) Smooth bandwidth-delay product variation inside wireless networks
JP6276206B2 (ja) 帯域割り当て制御装置及び帯域割り当て制御方法
GB2577610A (en) Improved congestion response
Jung et al. Resource-aware and quality-fair video-streaming using multiple adaptive TCP connections
ur RAHMAN et al. Chunk size aware buffer-based algorithm to improve viewing experience in dynamic HTTP streaming
US11438275B2 (en) Congestion response
JP7456445B2 (ja) 通信制御方法、通信装置及び通信システム
EP2624520A1 (en) Method, control device and delivery infrastructure for improving efficiency in adaptive streaming
WO2019004013A1 (ja) データ送信装置、方法および記録媒体
Nam et al. Adaptive Video Streaming Using Bandwidth Estimation for 3.5 G Mobile Network
WO2018002687A1 (en) Estimating a buffer level in a playout device

Legal Events

Date Code Title Description
E701 Decision to grant or registration of patent right
GRNT Written decision to grant