[go: up one dir, main page]

KR102491452B1 - 적응 속도 제어와 트래픽 관리의 시스템 및 방법 - Google Patents

적응 속도 제어와 트래픽 관리의 시스템 및 방법 Download PDF

Info

Publication number
KR102491452B1
KR102491452B1 KR1020177009163A KR20177009163A KR102491452B1 KR 102491452 B1 KR102491452 B1 KR 102491452B1 KR 1020177009163 A KR1020177009163 A KR 1020177009163A KR 20177009163 A KR20177009163 A KR 20177009163A KR 102491452 B1 KR102491452 B1 KR 102491452B1
Authority
KR
South Korea
Prior art keywords
data
processor
traffic
rate
application
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
KR1020177009163A
Other languages
English (en)
Other versions
KR20170063678A (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 KR20170063678A publication Critical patent/KR20170063678A/ko
Application granted granted Critical
Publication of KR102491452B1 publication Critical patent/KR102491452B1/ko
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/25Flow control; Congestion control with rate being modified by the source upon detecting a change of 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/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2475Traffic characterised by specific attributes, e.g. priority or QoS for supporting traffic characterised by the type of applications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272Virtual private networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/168Implementing security features at a particular protocol layer above the transport layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/568Storing data temporarily at an intermediate stage, e.g. caching
    • 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/27Evaluation or update of window size, e.g. using information derived from acknowledged [ACK] packets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02Terminal devices

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

네트워크를 통해 프로세서로 데이터를 전송 또는 수신하기 위해 컴퓨터 프로세서 및 컴퓨터 서버에 대한 네트워크 접속을 갖는 휴대용 통신 기기상의 통신 트래픽 관리 시스템 및 방법이 제공된다. 이 방법은, 프로세서상에서 실행되는 트래픽 관리자 애플리케이션에 의해, 네트워크를 통해 서버로 또는 서버로부터 제1 데이터를 전달하고 프로세서상에서 실행되는 제1 애플리케이션을 식별하는 단계; 트래픽 관리자 애플리케이션에 의해, 제1 애플리케이션으로 또는 제1 애플리케이션으로부터 또는 서버로 또는 서버로부터 제1 데이터의 전자 트래픽을 인터셉트하는 단계; 및 트래픽 관리자 애플리케이션에 의해, 제1 애플리케이션으로의 또는 제1 애플리케이션으로부터의 제1 데이터의 전달 속도를 제어하는 단계를 포함한다. 시스템은 휴대용 통신 기기, 및 프로세서에 연결되고 프로세서에 의해 실행될 때 프로세서로 하여금 상기 방법의 단계들을 실행하게 하는 명령을 저장하는 비-휘발성 저장 장치를 포함한다.

Description

적응 속도 제어와 트래픽 관리의 시스템 및 방법{SYSTEM AND METHOD OF ADAPTIVE RATE CONTROL AND TRAFFIC MANAGEMENT}
본 출원은 2014년 3월 4일 출원된 미국 가출원 제61/947,982호와 관련된, 2014년 9월 5일에 출원된 미국 가출원 제62/046,874호의 우선권을 주장한다.
본 발명의 실시 예는 적응형 속도 제어 및 트래픽 관리 시스템 및 방법에 관한 것이다.
전자 기기(스마트 폰 또는 태블릿과 같은 휴대용 전자 기기 포함)에 스트리밍 비디오와 같은 고-대역폭 응용 프로그램의 사용이 늘어남에 따라 셀룰러 데이터 네트워크와 같은 무선 데이터 네트워크에 상당한 요구가 발생했다. 현재, 이러한 기기에서 실행되는 수많은 휴대용 기기 및 애플리케이션("앱")이 동일한 제한된 네트워크 대역폭을 사용하려고한다. 기기상에서 서버 콘텐츠를 캐싱하는 것은 동일한 데이터에 대한 요청을 반복하는 데 도움이 되지만, 휴대용 기기상에서 실시간으로 비디오 콘텐츠를 시청하거나 오디오 콘텐츠를 듣는 경우와 같은 고-대역폭 애플리케이션의 경우에는 일반적으로 그렇지 않다.
셀룰러 네트워크와 같은 현재의 이동 통신 시스템은 가속화된 수요가 제한된 용량을 추월하면서 발생하는 문제로 어려움을 겪고 있다. 용량은 각 모바일 네트워크 운영자의 유한 무선 스펙트럼, 기존 스펙트럼의 스펙트럼 용량에서 물리적 한계에 도달하는 기술 및 새로운 스펙트럼에의 액세스를 위한 긴 규제적 리드 타임에 의해 제한된다. 동시에 더 많은 사용자가 모바일 되고, 모바일 기기가 더 빨라지고 스마트하게되면서 사용 가능한 용량을 추월하고 있다. 용량 부족으로 인한 결과는 네트워크 정체, 열악한 사용자 경험 및 모바일 서비스에 대해 놓친 수익의 기회들이 있다.
더 빨라진 기기, 점점 더 많은 데이터가 부족하거나 "잡음이 많은" 앱들 및 모바일 비디오의 성장과 같이 사용자 요구와 네트워크 모바일 네트워크 용량 간에 불일치가 발생하는 많은 원인이 있다. 모바일 비디오 소비는 다른 모든 모바일 활동보다 빠르게 데이터 사용량이 증가하고 있으며 적응형 비디오 스트리밍의 고유 동작으로 인해 사용 가능한 모든 네트워크 용량을 자동으로 사용하기 때문에 특히 문제가 된다. 적응형 비디오 스트리밍은 느린 네트워크의 경우 비디오 품질을 자동으로 낮추도록 설계되었지만 사용자가 예기치 않게 높은 데이터 사용량을 초래할 수 있는 고속 네트워크의 경우 비디오 품질을 자동으로 높이는 반대되는 동작을 가능하게 한다.
안타깝게도, 사용자 또는 모바일 네트워크 운영자는 데이터 사용량을 관리하기에 충분한 통찰력이나 제어력이 없으므로 이러한 수요/용량 불일치로 인해 일반적으로 사용자 경험이 열악하거나 및/또는 높은 최종 사용자 비용이 발생한다. 모바일 운영자는 지나치게 수다스럽거나(chatty) 초과 데이터를 사용할 수 있는 특정 앱을 보기 위한 네트워크로부터의 가시성이 거의 없거나 전혀 없으므로 모바일 네트워크에 미치는 영향을 조정/제한하는 정밀도가 부족하다. 이들은 지능형 스위치 및 프록시 서버와 같은 네트워크에 배포된 기존 도구를 사용하여 특정 사용자의 데이터 소비를 모니터링 및/또는 제어하지만 이러한 도구는 특정 트래픽에 대해 특정 애플리케이션을 안정적으로 식별할 수 없으므로 충분한 세분성이 부족하다. 최종 사용자에게는 고-대역폭 비디오 스트림이 데이터 플랜을 소모하는 것을 방지하거나 로밍할 때 특정 애플리케이션이 데이터를 사용하는 것을 허용/차단하는 것과 같이 데이터 소비를 관리할 수 있는 제어가 거의 없거나 전혀 없다. 이는 최종 사용자가 그들의 데이터 소비, 비용 및 사용자 경험을 관리할 수 있는 것을 방지한다.
본 발명의 실시 예는 스마트 폰과 같은 휴대용 기기에서 트래픽을 모니터링하고 제어하는 것에 관한 것이다. 추가적인 양상들은 적응형 속도 제어 및 트래픽 관리의 시스템 및 방법에 관한 것이다.
본 발명의 실시 예는 모바일 기기 내에서 애플리케이션 레벨 데이터 사용의 검출 및 제어를 제공함으로써 이들 및 다른 관심사를 해결한다. 더 상세하게는, 본 발명의 양태들은 적응형 비디오 스트림에서와 같이 모바일 애플리케이션에 제공되는 데이터 속도를 제한함으로써 데이터 소비를 상당히 감소시키는 것을 제공한다. 또 다른 양태는 데이터를 수신하기 위해 기기가 셀 타워에 연결될 필요가 있는 총 시간을 감소시키기 위해 버스트(bursts)로 애플리케이션/기기에 데이터를 수신함으로써 라디오 시그널링(radio signaling) 및 셀룰러 혼잡(cellular congestion)을 감소시키는 것을 제공한다. 또 다른 양태는 모바일 애플리케이션에 대해 허용/제한되는 네트워크 용량의 미세-입자 추적(fine-grain tracking) 및 제어를 제공한다.
따라서, 본 발명의 실시 예들은 모바일 기기상의 애플리케이션에 의해 수행되는 모바일 트래픽을 프로세싱하는 능력을 제공한다. 이 트래픽을 "대역 내(in band)" 프로세싱할 수 있는 능력은 모바일 앱 트래픽에 광범위한 다양한 모니터링 및 제어 기능이 적용될 수 있도록 한다. 기기 내에서 이 트래픽을 프로세싱하는 능력은 기기에 의해 액세스되는 임의의 네트워크에서 이러한 기능들이 사용될 수 있게 한다. 본 발명의 실시 예들은 프록시 구성, VPN 터널 기기 또는 모바일 앱 내의 요청 인터셉션(interception)을 사용하는 것과 같이 모바일 기기상에서 대역-내 모니터링 및 제어가 이루어질 수 있는 다수의 방법을 제공한다.
본 발명의 실시 예는 (비디오 또는 오디오와 같은) 데이터 스트리밍 애플리케이션의 대역폭을 개선 또는 최적화하는 것에 관한 것이다. 본 발명의 실시 예들은 비디오의 품질을 조정하는 ABR(adaptive bitrate, 적응형 비트율)과 같은, 스트림을 전송하기 위한 가용한 대역폭의 것과 매칭하기 위한 멀티미디어 스트림의 품질을 조절하는 비디오 또는 오디오 스트리밍 기술에 따르기 쉬운 스트리밍 파일들을 포함하여 (그 다음 몇 개의 비디오 청크(chunk)들을 프리-페칭(pre-fetching)하는 것과 같은) 일시적으로 일부 콘텐츠를 저장하는 것에 관한 것이다.
본 발명의 실시 예는 (기존 프로토콜로 대역폭 사용을 최소화하는 방식으로 데이터를 요청하도록 앱을 최적화하는 것과 같은) 적응형 비트율(ABR) 제어 및 (가능한 한 효율적으로 데이터를 얻기 위해 필요한 네트워크에 대한 접속 시간을 최소화시키는 것과 같은) 접속 제어를 제공하는 데에 목적이 있다.
본 발명의 실시 예는 데이터 속도의 비트율 제어, (앱이 요청하기 전에, 나중에 접속을 개방하는 것을 피하기 위해) 스트림 청크를 프리-페칭하는 것, (비디오 스트림 청크와 같은) 스트림 청크를 프리-페칭할 경우에 데이터 속도의 비트율 제어에 대한 바람직한 비트율 제어와 프리-페치하는 정도를 결정하기 위한 정책-기반 규칙; 뿐만 아니라 (예를 들어, 앱의 네트워크 사용을 제어 또는 제한하기 위한) 특정 요청을 허용 및 허용하지 않는 것을 제공하는 데에 목적이 있다.
데이터 속도의 비트율 제어는, 예를 들어, 대역폭 사용을 줄이기 위해 사용될 수 있고, 스트리밍 콘텐츠(예를 들어, 비디오)와 같은 것에 대해 접속 시간을 감소시키기 위해 일부 경우에는 스트림 청크를 프리-페칭하는 것과 결합 될 수 있다. 이들을 제어하기 위한 정책-기반 규칙의 다른 용어는 "종점 트래픽 관리(endpoint traffic management)"이며, 이는 앱이 수행할 수 있는 요청의 유형과 빈도를 제한하는 데 사용될 수 있다.
이러한 모든 기술의 핵심은 스마트 폰이나 태블릿과 같은 종점 기기에서 이들이 이전에 활성화되지 않았다는 것이다.
본 발명의 일 실시 예에서, 적응형 비트율은 데이터가 전달되는 방법을 결정하고, 클라이언트로부터의 요청을 최적화하여 이를 활용한다(사용자가 실제로 그것을 원할 때까지 초과 콘텐츠를 버퍼링함). 다른 실시 예에서, 비트율 제어는 데이터를 요청하는 앱으로 데이터가 얼마나 빨리 전달되는지를 결정한다. 예를 들어, 이는 "적응형 비트율 스트림"에 적용될 수 있으며, 여기서 앱은 요청할 항목(예를 들어, 여러 해상도로 동일한 비디오)의 여러 사이즈 중에서 앱이 선택할 수 있고 속도를 느리게 하면 앱에서 작은 크기의 버전(version)을 선택하도록 할 것이다(이에 따라 더 적은 대역폭을 사용하게 된다).
본 발명의 일 실시 예에서, 접속 제어는 접속 기간을 최대한 이용하려고 시도하고, 액세스가 다시 필요할 때까지 다른 애플리케이션/사용자가 네트워크에 액세스할 수 있도록 접속을 끊는다.
본 발명의 일 실시 예에서, 트래픽 관리는 현재 시스템에 이용 가능하지 않은 많은 유용성 특징(보안, 사용 모니터링 등)을 추가한다. 하나 이상의 실시 예에서, 이들 특징은(최종 사용자을 위한) 유용성 또는 네트워크 운영자(예를 들어, 셀룰러 제공자)를 위한 제어/보호 중 하나일 수 있다. 일부 실시 예에서, 이들은 정책을 적용하고 결정을 내릴 수 있도록 종점 기기의 트래픽 흐름의 중심 지점에 앉아 있는 (프록시와 같은) 트래픽 관리자를 갖거나 이를 의존할 수 있다.
본 발명의 일 실시 예에서, 컴퓨터 프로세서 및 네트워크를 통해 상기 프로세서와 데이터를 전송 또는 수신하기 위한 컴퓨터 서버에 대한 네트워크 접속을 갖는 휴대가능한 통신 기기상의 통신 트래픽 관리 방법이 제공된다. 이 방법은, 프로세서상에서 실행되는 트래픽 관리자 애플리케이션에 의해, 네트워크를 통해 서버로 또는 서버로부터 제1 데이터를 전달하고 프로세서상에서 실행되는 제1 애플리케이션을 식별하는 단계; 트래픽 관리자 애플리케이션에 의해, 제1 애플리케이션으로 또는 제1 애플리케이션으로부터 제1 데이터의 전자 트래픽을 인터셉트하는 단계; 및 트래픽 관리자 애플리케이션에 의해, 서버로 또는 서버로부터 제1 애플리케이션으로의 또는 제1 애플리케이션으로부터의 제1 데이터의 전달 속도를 제어하는 단계를 포함한다.
제1 데이터의 전달 속도의 제어 단계는 제1 애플리케이션에 의해 인지되는 네트워크의 현재 속도를 네트워크의 현재 속도보다 적은 제1 데이터 속도로 스로틀링(throttling)하는 단계를 포함할 수 있다.
제1 데이터의 전자 트래픽은 하이퍼 텍스트 전송 프로토콜(Hypertext Transfer Protocol, HTTPS)을 위한 보안 프로토콜을 사용하여 전송되는 데이터를 포함할 수 있다.
제1 데이터의 전달 속도의 제어 단계는 서버로의 또는 서버로부터의 제1 데이터의 전달 속도를 네트워크의 현재 속도보다 적은 제1 데이터 속도로 스로틀링하는 단계를 포함할 수 있다.
제1 데이터의 전자 트래픽은 적응형 비트율 스트림을 포함할 수 있다.
제1 데이터의 전자 트래픽은 프로그레시브 스트림(progressive stream)을 포함할 수 있다.
제1 애플리케이션은 매니페스트(manifest)에 의해 제어되는 바와 같이 상이한 대응 해상도를 갖는 복수의 데이터 속도를 지원가능한 것일 수 있다. 제1 데이터의 전달 속도의 제어 단계는 제1 데이터 속도를 초과하는 데이터 속도를 숨기거나 제거하도록 매니페스트를 편집하는 단계를 포함할 수 있다.
제1 애플리케이션은 상이한 대응 해상도를 갖는 복수의 데이터 속도를 지원가능한 것일 수 있다. 제1 데이터의 전달 속도의 제어 단계는 제1 데이터 속도를 초과하는 데이터 속도의 액세스에 대한 실패 또는 차단 단계를 포함할 수 있다.
이 방법은 트래픽 관리자 애플리케이션에 의해, 네트워크를 통해 서버로 또는 서버로부터 제2 데이터를 전달하고 프로세서상에서 실행되는 제2 애플리케이션을 식별하는 단계; 트래픽 관리자 애플리케이션에 의해, 제2 애플리케이션으로의 또는 제2 애플리케이션으로부터의 제2 데이터의 전자 트래픽을 인터셉트하는 단계; 및 트래픽 관리자 애플리케이션에 의해, 제2 애플리케이션으로의 또는 제2 애플리케이션으로부터의 또는 서버로의 또는 서버로부터의 제2 데이터의 전달 속도를 제어하는 단계를 더 포함할 수 있다.
제1 및 제2 데이터의 전달 속도의 제어 단계는 제1 데이터의 전달 속도가 제2 데이터의 전달 속도를 초과하도록 제1 및 제2 데이터의 전달 속도를 동시에 제한하는 단계를 포함할 수 있다.
전자 트래픽을 인터셉트하는 단계는 프로세서에서 실행중인 내부 프록시를 사용하는 단계를 포함할 수 있다.
전자 트래픽을 인터셉트하는 단계는 프로세서상의 가상 사설망(virtual private network, VPN) 인터페이스를 사용하는 단계를 포함할 수 있다.
전자 트래픽을 인터셉트하는 단계는 프로세서상에서 수정된 제1 애플리케이션을 실행하는 단계를 포함할 수 있으며, 수정된 제1 애플리케이션은 전자 트래픽의 인터셉트를 요청하도록 구성된다.
본 발명의 다른 실시 예에서, 통신 트래픽 관리를 위한 시스템이 제공된다. 이 시스템은 컴퓨터 프로세서 및 네트워크를 통해 프로세서와 함께 데이터를 송신 또는 수신하기 위한 컴퓨터 서버에 대한 네트워크 접속을 갖는 휴대용 통신 기기와, 프로세서에 연결된 비-휘발성 저장 장치를 포함한다. 비-휘발성 저장 장치는 프로세서에 의해 실행될 때 프로세서로 하여금: 네트워크를 통해 서버로 또는 서버로부터 제1 데이터를 전달하고 프로세서상에서 실행되는 제1 애플리케이션을 식별; 제1 애플리케이션으로 또는 제1 애플리케이션으로부터 제1 데이터의 전자 트래픽을 인터셉트; 및 제1 애플리케이션으로의 또는 제1 애플리케이션으로부터의 또는 서버로의 또는 서버로부터의 제1 데이터의 전달 속도를 제어하게 하는, 명령을 저장한다.
명령들은 프로세서에 의해 실행될 때, 추가로 프로세서로 하여금 제1 애플리케이션에 의해 인지된 네트워크의 현재 속도를 현재의 속도보다 적은 제1 데이터 속도로 스로틀링함으로써 프로세서가 제1 데이터의 전달 속도를 제어하게 할 수 있다.
제1 데이터의 전자 트래픽은 하이퍼 텍스트 전송 프로토콜(HTTPS)을 위한 보안 프로토콜을 사용하여 전송되는 데이터를 포함할 수 있다.
명령들은 프로세서에 의해 실행될 때, 추가로 프로세서로 하여금 네트워크의 현재 속도보다 적은 제1 데이터 속도로 서버로의 또는 서버로부터의 제1 데이터의 전달 속도를 스로틀링함으로써 제1 데이터의 전달 속도를 제어하게 할 수 있다.
제1 데이터의 전자 트래픽은 적응형 비트율 스트림을 포함할 수 있다.
제1 데이터의 전자 트래픽은 프로그레시브 스트림을 포함할 수 있다.
제1 애플리케이션은 매니페스트에 의해 제어되는 바와 같이 상이한 대응 해상도를 갖는 복수의 데이터 속도가 지원가능한 것일 수 있다. 명령들은 프로세서에 의해 실행될 때, 추가로 프로세서로 하여금 제1 데이터 속도를 초과하는 데이터 속도들을 숨기거나 제거하기 위해 매니페스트를 편집함으로써 제1 데이터의 전달 속도를 제어하게 할 수 있다.
제1 애플리케이션은 상이한 대응 해상도를 갖는 복수의 데이터 속도를 지원가능한 것일 수 있다. 명령들은 프로세서에 의해 실행될 때, 추가로 프로세서로 하여금 제1 데이터 속도를 초과하는 데이터 속도의 액세스를 실패 또는 차단함으로써 제1 데이터의 전달 속도를 제어하게 할 수 있다.
명령들은 프로세서에 의해 실행될 때, 추가로 프로세서로 하여금: 네트워크를 통해 서버로 또는 서버로부터 제2 데이터를 전달하고 프로세서상에서 실행되는 제2 애플리케이션을 식별; 제2 애플리케이션으로의 또는 제2 애플리케이션으로부터의 제2 데이터의 전자 트래픽을 인터셉트; 및 제2 애플리케이션으로의 또는 제2 애플리케이션으로부터의 또는 서버로의 또는 서버로부터의 제2 데이터의 전달 속도를 제어하게 할 수 있다.
명령들은 프로세서에 의해 실행될 때, 추가로 프로세서로 하여금 제1 및 제2 데이터의 전달 속도를 동시에 제한함으로써 제1 및 제2 데이터의 전달 속도를 제어하게 하여, 제1 데이터의 전달 속도가 제2 데이터의 전달 속도를 초과하도록 할 수 있다.
명령들은 프로세서에 의해 실행될 때, 추가로 프로세서로 하여금 프로세서상에서 실행되는 내부 프록시를 사용함으로써 전자 트래픽을 인터셉트하게 할 수 있다.
명령들은 프로세서에 의해 실행될 때, 추가로 프로세서로 하여금 프로세서상의 가상 사설망(VPN) 인터페이스를 사용함으로써 전자 트래픽을 인터셉트하게 할 수 있다.
명령들은 프로세서에 의해 실행될 때, 추가로 프로세서로 하여금 프로세서상의 수정된 제1 애플리케이션을 실행함으로써 전자 트래픽의 인터셉트를 요청하게 하고, 여기서 수정된 제1 애플리케이션은 전자 트래픽의 인터셉트를 요청하기 위해 구성된다.
첨부된 도면은 본 명세서와 함께 본 발명의 예시적인 실시 예를 도시한다. 이들 도면은 설명과 함께 본 발명의 양태 및 원리를 더욱 잘 설명하는 역할을 한다.
도 1은 본 발명의 일 실시 예에 따른 온-디바이스 트래픽 관리 구현과 함께 사용하기에 적합한 예시적인 모바일 기기 (예를 들어, 스마트 폰) 아키텍처의 개략도이다.
도 2 내지 도 5는 본 발명의 실시 예에 따라 애플리케이션과 서버 간의 네트워크 트래픽의 모니터링 및 제어를 가능하게 하는 프록시 내의 소프트웨어 구성요소의 블록도이다.
도 6은 본 발명의 일 실시 예에 따른 프록시를 통한 앱과 서버 간의 요청들의 처리를 도시한 프로세스 타이밍도이다.
도 7은 본 발명의 다른 실시 예에 따라 앱과 서버 간의 네트워크 트래픽의 모니터링 및 제어를 가능하게 하는 프록시 내의 소프트웨어 구성요소의 블록도이다.
도 8은 본 발명의 다른 실시 예에 따른 프록시를 통한 앱과 서버 간의 요청들의 처리를 도시하는 프로세스 타이밍도이다.
이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시 예를 상세히 설명한다. 도면에서, 동일 또는 유사한 참조 번호는 전체적으로 동일하거나 유사한 요소를 지칭한다. 본 명세서에서, 본 발명의 실시 예를 설명할 때, "할 수 있다"라는 용어를 사용하는 것은 "본 발명의 하나 이상의 실시 예"를 의미한다. 또한, 실시 예를 설명할 때 "또는"과 같은 대체 언어를 사용하는 것은 각각의 대응하는 항목에 대한 "본 발명의 하나 이상의 실시 예"를 의미한다.
하나 이상의 실시 예에서, 모바일 기기 내에서 네트워크 트래픽을 관리하기위한 시스템들 및 방법들이 제공된다. 예시적인 실시 예는 도 1 내지 8을 참조하여 설명된다.
도 1은 본 발명의 일 실시 예에 따른 온-디바이스 트래픽 관리 구현과 함께 사용하기에 적합한 예시적인 모바일 기기 (예를 들어, 스마트 폰) 아키텍처(100)의 개략도이다. 예를 들어 모바일 기기는 안드로이드 폰일 수 있다. 설명을 위해 모바일 기기는 안드로이드 스마트 폰으로 간주될 것이다. 또한, 이러한 모바일 기기는 많은 사용자를 지원가능한 것일 수 있지만, 설명의 용이함을 위해, 모바일 기기는 특정 사용자 전용인 것으로 가정될 것이므로, 용어 "사용자" 및 "모바일 기기"(또는 개인적 또는 휴대 방식으로 사용되는 임의의 컴퓨팅 장치)는 전체적으로 동의어로 사용될 수 있습니다.
본 발명의 하나 이상의 실시 예들에 따르면, (아키텍처(100)와 같은) 모바일 기기들상의 일반적인 아키텍처는 예를 들어, 애플리케이션(예를 들어, 모바일 앱, 또는 그냥 "앱들")로부터 발생하는 데이터 트래픽을 예를 들어 Wi-Fi 또는 셀룰러 네트워크를 통해 모바일 기기가 액세스하는 예를 들어, 애플리케이션 서버(또는 앱 서버)(250)에 모니터 또는 제어할 수 있는 중앙집중형 프록시(130)를 제공한다. 이러한 접근법은 트래픽 관리가 다수의 네트워크 (예를 들어, WiFi 및 셀룰러) 및 다수의 앱에 걸쳐 수행될 수 있게 하고, 트래픽 관리가 중앙 관리될 수 있게 하지만, 본 발명은 이에 제한되지 않는다. 다른 실시 예에서, 트래픽 관리는, 전체적인 장치 트래픽이 효과적으로 중앙 관리되도록 조정된 방식으로 동작하는 각각의 앱 내에서 실행되는 프록시와 같은 분배된 방식으로 수행될 수 있다.
스마트 폰(100)의 앱 및 기타 프로그래밍 가능한 구성요소는 예를 들어 스마트 폰(100)의 비-일시적 저장 장치에 저장된 컴퓨터 명령 세트로서 구현될 수 있고, 스마트 폰(100)의 하나 이상의 프로세서에서 실행되도록 구성될 수 있다. 프록시(130)는 또한 웹 브라우저와 같은 특정 웹 사이트에 대한 트래픽을 관리할 수 있다. 따라서, 설명의 용이함을 위해, 프록시(130)에 의해 관리되는 콘텐츠의 카테고리를 언급할 때, "애플리케이션", "앱", "웹 사이트" 또는 "사이트"와 같은 용어는 본 출원 전반에 걸쳐 어느 정도 상호 교환 가능하게 사용될 수 있다.
프록시(130)는 소켓 계층(120)을 (예를 들어, OS(operating system) 네트워크 설정을 통해) 사용하는 프록시 서버, 네트워크 터널(TUN) 장치(230)를 (예를 들어 OS 네트워크 설정을 통해) 사용하는 가상 사설망(VPN) 서비스와 같은 다양한 메커니즘에서 관여(engage)될 수 있거나, 또는 인터셉트 계층(150)을 사용하는 앱 내에 내장될 수 있다. 프록시(130)는 자바 가상 장치(Java virtual machine, JVM)(160)상에 실행될 수 있다. 프록시는 물리적인 저장 장치상에 캐싱된 콘텐츠를 관리하기 위한 플래시 메모리(170) 또는 다른 비휘발성 저장 장치와 같은 캐시 엔진(110)을 포함할 수 있다. 보편성을 잃지 않으면서 이러한 장치는 솔리드(solid)-상태 드라이브와 같은 임의의 유형의 비-일시적인 저장 장치가 될 수 있지만 때때로 "디스크"라고 지칭될 수 있다. 또한, 캐싱된 또는 임의의 다른 저장된 콘텐츠는 랜덤 액세스 메모리와 같은 휘발성 저장소에 전체로 또는 부분적으로 저장될 수 있으며, 이 휘발성 저장 장치는, 더 느린 비휘발성 저장소로 전환되기 전에 더 빠른 휘발성 저장소에 가장 최근에 액세스된 콘텐츠가 저장되는 계층적 방식과 같이, 비휘발성 저장소와 조합되어 사용될 수 있다.
프록시(130)는 애플리케이션, 커널 드라이버(kernal driver)와 같은 다양한 폼 팩터(form factor)에서 또는 모바일 장치상의 OS 내에서 실행될 수 있으며, 예를 들어 OS 네트워크 설정을 통해 네트워크 접속을 수신하도록 구성될 수 있다. 하나 이상의 실시 예에서, 프록시 서버는 JVM에서 실행될 수 있다. 프록시(130)는 클라이언트 애플리케이션을 대신하여 중개자 역할을 할 수 있다. 예를 들어, 프록시(130)는 다른 JVM(165)에서 실행중인 앱(180)의 요청을 서비스할 수 있다.
앱(180)은 예를 들어 HttpURLConnection(190)과 같은 안드로이드 서비스를 사용하여 인터넷에 액세스하기를 원할 수 있다. 여기서, HTTP는 하이퍼 텍스트 전송 프로토콜(hypertext transfer protocol)을 나타내고, URL은 인터넷 주소(uniform resource locator)(예를 들어, 웹 주소)를 나타낸다. HttpURLConnection(190)은 인터넷에 액세스하기 위해 네트워크 서비스(200)를 호출(invoke)할 수 있다. 네트워크 서비스(200)는 예를 들어, 액세스 포인트 명(access point name, APN)(210) (예를 들어, 3G와 같은 모바일 네트워크) 또는 Wi-Fi 접속(220)을 사용하여 인터넷에 액세스할 수 있다. 네트워크 서비스(200)는 앱(180)으로부터 프록시 서버(130)로 시스템, APN 또는 WiFi 접속에 전역적으로 적용되는 프록시 구성을 사용하여 요청을 라우팅하도록 구성될 수 있다. 네트워크 서비스(200)는 또한 예를 들어 네트워크 터널(TUN) 장치(230) 또는 IP 라우팅 테이블("iptables"로도 공지됨)을 통해 다양한 다른 방법을 사용하여 앱(180)으로부터 프록시(130)로 요청을 라우팅할 수도 있다.
네트워크 서비스(200)는 프록시(130)에 의해 수신되는 요청이 소켓(120)(예를 들어, 인터넷에 접속하기 위한 네트워크 소켓)과 같은 표준 통신 계층을 통해 발신될 수 있도록, 인터넷에 액세스하기 위해 프록시를 직접적으로 또는 간접적으로 (예를 들어, 기기상에서 실행되는 앱에 의해 직접 검출되고 사용되는 글로벌 시스템 프록시로서, 또는 간접적으로 APN(210) 또는 Wi-Fi 접속(220)상의 설정을 통해) 지정하게 구성될 수 있다. 프록시(130)는, 차례로, (APN 또는 Wi-Fi 프록시 구성을 바이패스하여 자신에게로의 루프백(loop back)을 피하면서) 네트워크 서비스(200)를 통해 앱 서버(250)에 요청을 할 수 있으며, 이는 요청을 서비스하고 응답하는 모든 통신을 프록시(130)에 반환한다. 프록시는 그 다음에 앱과 서버 간의 통신을 모니터링 또는 제어할 수 있다. 프록시(130)는 네트워크 소켓(120)을 통해 응답을 동일한 서술된 단계의 역(reverse)을 통해 앱(180)에 응답을 반환하기 전에 캐싱 엔진(110)을 통해 응답의 일부 또는 전부를 캐싱하거나 전부를 캐싱하지 않을 수도 있다.
APN 또는 Wi-Fi 접속상에서 프록시 구성을 사용하는 대신에, 네트워크 서비스(200)는 다양한 다른 수단을 통해 프록시 서버(130)에 요청을 라우팅하도록 구성 될 수도 있다. 예를 들어, 다른 접근법은 네트워크 접속을 VPN 접속을 설정하기 위해 네트워크 터널(TUN)(230)을 사용하는 것이며, 이는 네트워크 전송을 처리하기 위해 네트워크 활동을 VPN 서비스(140)로 라우팅할 수 있다. VPN 서비스(140)는 그다음에, 요청을 서비스하고 네트워크 터널(230)을 통해 응답을 반환하기 위해 (적절한) 소켓(120)을 사용하여 앱 및 앱 서버(250) 간의 트래픽을 관리하기 위해, 요청을 프록시(130)로 라우팅할 수 있다.
프록시(130)를 관여시키는 다른 메커니즘은 트래픽을 프록시 프로세스로 리다이렉트(redirect)하기 위해 앱 내의 (인터셉션 계층 (150) 및 (155)와 같은) 인터셉션 계층(interception layer)을 사용하는 것이다. 예를 들어, 상술된 예시에서, 인터넷에 액세스하기 위해 HttpURLConnection(190) 네트워크 서비스(200)를 호출하기 전에 또는 그 대신에, HttpURLConnection은 인터셉트 계층(150)이 앱(180)으로부터의 요청을 인터셉트하고 그의 트래픽을 프록시(130)에 직접 전달할 수 있다. 인터셉트(150)로부터의 프록시(130)를 전달하는 것은 네트워크 서비스(200)를 통해 또는 메시지 대기열(queues), 명명된 파이프 또는 공유 메모리와 같은 당업자에게 자명한 표준 상호 프로세스(inter-process) 통신 메커니즘을 사용하여 수행될 수 있다.
JVM(160) 내에서와 같은 별도의 프로세스에서 동작하는 프록시(130)에 추가로, 다른 실시 예에서, 프록시(130)는 JVM(165) 또는 브라우저(185)(예를 들어 웹 브라우저)와 같은 요청 프로세스 내에 내장될 수 있다. 그 후, 프록시(130)는 임의의 상호 프로세스 통신을 필요로 하지 않고 앱의 네트워크 트래픽을 관리 할 수 있다.
다른 예시에서, 웹 브라우저(185)는 인터넷에 액세스하려고 시도한다. 상기 앱(180)과 유사하게, 웹 브라우저(185)는 다수의 상이한 접근법에 의해 프록시(130)를 이용할 수 있다. 예를 들어, 웹 브라우저(185)는 네트워크 소켓(125)을 사용함으로써 인터넷에 액세스하도록 구성될 수 있으며, 이는 그 다음에 앱 서버(250) 및/또는 프록시(130)를 액세스하기 위해 네트워크 서비스(200)를 사용할 수 있으며, 이는 예를 들어, 상술된 바와 같은 소켓(120) 또는 VPN 서비스(140)를 사용한다. 유사한 방식으로, 인터셉트 계층(155)은 웹 브라우저(185)에 추가될 수 있으며, 이는 그 다음에 웹 브라우저(185)로부터 요청을 인터셉트하여 이의 트래픽을 프록시(130)로 전달할 수 있다.
보다 상세하게는, 상기 기술들은 SSL(Secure Sockets Layer, 예를 들어, 암호화된) 통신들 및 비-SSL (예를 들어, 암호화되지 않은) 통신들 사이의 가능한 차별화와 함께 기존 인터페이스들에 통합될 수 있다. 애플리케이션과의 통합은 예를 들어 네트워크 스택의 중앙집중식 위치와 같이 비-SSL 통신에 대해 가능하게 될 수 있다. 예를 들어, 프록시(130)는 HTTP, HTTPS 또는 둘 다와 같은 네트워크 프로토콜의 전부 또는 서브세트에 대한 프록시로서 구성될 수 있다. 마찬가지로, 프록시(130)는 셀룰러, WiFi 또는 둘 다와 같은 네트워크 인터페이스의 전부 또는 서브세트에 대한 프록시로서 구성될 수 있다. 예를 들어, APN(210) 액세스에 대해, 셀룰러 액세스 포인트는 프록시(130)로 설정될 수 있다. Iptables 액세스에 대해, 대응하는 인터넷 프로토콜(IP) 라우팅 테이블 엔트리가 설정될 수 있다. VPN 서비스의 경우, (VPN 서비스(140)와 같은) VPN 클라이언트는 트래픽을 프록시(130)로 라우팅할 수 있다. Wi-Fi의 경우, 프록시(130)는 각각의 Wi-Fi 액세스 포인트(AP)에 대해 설정될 수 있다. 글로벌 시스템 프록시의 경우, 시스템은 모든 애플리케이션 트래픽에 대한 트래픽을 프록시(130)로 향하게 할 수 있다.
또한 SSL 또는 TLS와 같이 암호화된 통신을 사용하는 애플리케이션과 통합하려면 암호화되지 않은 네트워크 데이터에 대한 액세스가 필요할 수 있다. 여기에 사용할 수 있는 여러 가지 방법이 있다. Man-in-the-middle 방식의 경우 신뢰할 수 있는 인증 기관(certificate authority, CA)을 통해 서버를 가장함으로써 암호화된 데이터에 액세스할 수 있다. (도 1의 인터셉트 계층(155)과 같은) 소프트웨어 개발 키트(software development kit, SDK) 접근법의 경우, 캐싱 엔진(110)에 대한 후크(hook)와의 빌드-타임 링크(build-time linking)는 암호화 계층 위에 사용될 수 있다. 재링크(relink) 접근법의 경우, 기존의 애플리케이션은 HttpURLConnection(190)과 같은 커스텀 대체 애플리케이션 프로그래밍 인터페이스(API)를 사용하기 위해 디컴파일되고 재링크될 수 있다. 대체 접근법의 경우, 웹 브라우저(185)와 같은 브라우저와 같이, 앱의 대안적인 버전이 인터셉션(interception)이 이미 연결(wired in)된 곳에서 제공될 수 있다. 이는 특히 널리 사용되는 오픈 소스 애플리케이션에 적합할 수 있다.
도 1은 주로 모바일 기기의 아키텍처(100)에 대한 것인 한편, 모바일 기기(100)의 하나 이상의 프로세서에 실행되도록 구성된 소프트웨어 구성요소들과 같이, 온-디바이스 트래픽 관리는 다른 구성요소를 수반할 수도 있다. 도 2 내지도 5는 본 발명의 실시 예에 따른 앱(310)과 서버(250) 간의 네트워크 트래픽의 모니터링 및 제어를 가능하게 하는 프록시(130) 내의 소프트웨어 구성요소의 블록도이다.
도 2에서, 모바일 장치(100) 내에서 실행되는 앱(310)은 앱 서버 (250)와 통신하고, 프록시(130)는 시스템 프록시 설정 또는 VPN을 통한 방법과 같이 상술한 방법 중 임의의 것을 사용하여 앱의 네트워크 트래픽을 인터셉트할 것이다. 프록시(130) 내에서, 본 발명의 하나 이상의 실시 예에서, 네트워크 트래픽 모니터링 및 제어를 수행하는 논리적인 소프트웨어 구성요소가 존재하며, 이러한 소프트웨어 구성요소는 앱(310)과 함께 데이터 경로(325)를 처리할 수 있는 클라이언트 처리자(ClientHandler)(320) 및 앱 서버(330)와 함께 데이터 경로(335)를 처리할 수 있는 요청 처리자(RequestHandler)(250)를 포함할 수 있다.
앱(310)과 클라이언트 처리자(320) 사이의 데이터 경로(325)는 네트워크 소켓 또는 통상의 기술자에게 자명한 임의의 표준 상호 프로세스 통신 메커니즘과 같은, 앱의 네트워크 트래픽을 인터셉트하기 위해 사용되는 방법에 따라, 상이한 메커니즘을 통해 발생할 수 있다. 요청 처리자(330)와 앱 서버(250) 사이의 데이터 경로(335)는 또한 TCP/IP를 사용하는 네트워크 소켓과 같이 앱(310)이 앱 서버(250)와 통상 통신하는 방법에 따라 상이한 메커니즘을 통해 발생할 수 있다. 앱 서버(250)와 외부 데이터 경로 및 앱(310)과 내부 데이터 경로를 분리함으로써, 앱 서버(250)로/로부터 (데이터 경로(335)를 통해) 실제로 전달될 수 있는 속도보다 느린 속도로 앱(310)으로/으로부터 데이터를 (데이터 경로(325)를 통해) 전송하기 위한 것과 같이, 프록시(130)는 앱(310)과 앱 서버(250) 사이의 데이터 속도를 개별적으로 제어할 수 있게 된다.
본 발명의 또 다른 실시 예에 따르면, 비트율 매니저(BitrateManager)(340)는 앱(310)으로/으로부터 또는 앱 서버(250)로/로부터의 적절한 비트율(데이터 속도로도 알려짐)을 관리하기 위해 사용될 수 있다. 이는 상이한 사용자에 대한 상이한 비트율, 상이한 앱에 대한 상이한 비트율, 이전의 데이터 소비에 기초한 상이한 비트율, 상이한 네트워크 유형에 대한 상이한 비트율 및 당업자에게 자명한 다른 변형과 같은 비트율에 대한 하나 이상의 정책을 구현하기 위한 별도의 소프트웨어 구성요소를 허용한다. 상이한 사용자에 대해 비트율을 구현하기 위한 정책은 사용자 또는 사용자 카테고리의 리스트로 이루어질 수 있는데, 여기서 사용자 카테고리는 기기 유형 (예를 들어, 스마트 폰 vs. 태블릿), 기기 모델 또는 데이터 플랜과 같은 임의의 사용자 그룹일 수 있다. 다른 앱에 대해 서로 다른 비트율을 구현하는 정책은 앱 또는 앱 카테고리당 비트율 리스트를 포함할 수 있으며, 여기서 앱 카테고리는 기능(예를 들어, 동영상, 소셜, 이메일 등), 벤더(vendor) 또는 일부 다른 카테고리 (예를 들어, 직장 vs. 개인)과 같은 것에 의해 앱이 그룹핑(grouping)된 것일 수 있다.
앱 기반 정책은 앱이 사용자에게 표시되는 경우에 더 높은 비트율을 허용하거나(예를 들면, 배경에서 실행되는 것과 대조적으로 포그라운드(foreground)에서 실행되는 것), 높은 우선수위의 앱이 실행되는 경우에 낮은 우선순위의 앱에 대해 낮은 비트율을 적용하는 것과 같이, 앱이 실행되는 방법 또는 언제 실행되는지에 기초할 수도 있다. 상이한 네트워크 유형에 대해 상이한 비트율을 구현하기 위한 정책은 네트워크 유형당 (예를 들어, WiFi, LTE, HSPA, CDMA, etc.) 비트율의 리스트, 또는 특정 셀 타워나 WiFi 핫스팟과 같은 특정 네트워크의 리스트를 포함할 수 있다. 네트워크 기반 정책은 사용자의 데이터 계획의 운영자가 소유한 홈 네트워크에 액세스할 때 높은 비트율을 사용하지만 다른 운영자가 소유한 네트워크에서 사용자가 로밍할 때 비트율이 더 낮은 것과 같이 네트워크와 관련된 소유권 또는 비용에 기초할 수도 있다.
비트율 매니저에 의해 관리되는 속도 제한은 비트 수준에만 국한되지 않고 요청, 패킷(예를 들어, TCP 세그먼트 또는 IP 패킷), 네트워크 접속, 또는 당업자의 누구에게든 자명한 다른 입도(granularities)에 의한 것과 같이, 다른 증분 또는 유닛에서 트래픽 속도에 대한 제한을 포함할 수도 있다. 예를 들어, 일부 유형의 네트워크(예를 들어, 2G 및 3G 셀룰러 네트워크)가 동시에 지원할 수 있는 제한된 수의 접속을 가질 수 있기 때문에, 발생할 수 있는 정체를 제어/최소화하기 위해 특정 네트워크 유형에서 "수다스러운" 앱에 의한 요청 빈도를 제한하는 것이 바람직할 수 있다.
전술한 정책들 중 임의의 것은 예를 들어, 사용자에 의해 제공되거나, 앱에 의해 사전에 구성되거나, 또는 관리 서버와 같은 외부 시스템으로부터 수신될 수 있다. 전술한 정책들 중 임의의 것이 또한 이전의 데이터 사용 또는 트래픽 활동에 기초하여 변화하는 속도 제한과 같이, 복수의 또는 가변적인 속도 제한을 갖도록 확장 될 수 있다. 예를 들어, 앱 기반 정책은 데이터 소비가 적은 앱이 더 높은 (또는 제한되지 않은) 비트율로 작동하면서 더 높은 대역폭의 앱이 하나 이상의 임계값을 초과하면 이를 제한하는 것을 허용하기 위한 것과 같이, 앱의 데이터 소비가 증가하면서 감소하는 다수의 비트율 수준을 허용할 수 있다.
예를 들어, 앱(310)이 앱 서버(250)로부터 데이터를 수신하기 위한 요청을 수행 할 때, 요청은 클라이언트 처리자(320)에 의해 처음 수신되고, 그 다음에 요청을 처리하는 데 필요한 적절한 유형의 요청 처리자(RequestHandler)(330)로 전달된다. 프록시(130)는 도 3의 패쓰스루 처리자(PassthroughHandler)(331)와 같이 앱 서버(250)로 요청을 전달하는 하나 이상의 유형의 요청 처리자를 지원할 수 있다. 다른 유형의 요청 처리자는 캐싱된 데이터의 신선도를 검증할 수 있기 위해 필요에 따라 캐시 엔진(110) 및 앱 서버(250)와 상호 작용함으로써 캐시로부터 콘텐츠로 요청에 응답할 수 있는 도 4의 캐시로부터 서브 처리자(ServeFromCacheHandler)(332)일 수 있다. 요청 처리자의 다른 유형은 외부 네트워크 또는 서버에 의해 지원되는 것보다 낮은 속도로 요청 데이터를 송신하거나 응답 데이터를 수신하는 것과 같이, 앱 서버(250)로 데이터 경로의 속도를 제어할 수있는 도 5의 스로틀링 처리자(ThrottlingHandler)(333)일 수 있다. 본 발명의 실시 예에서, 각 유형의 요청 처리자는 요청 처리자의 수퍼 클래스의 서브 클래스로서 구현될 수 있다. 요청 처리자는 요청에 응답하고 응답을 클라이언트 처리자(320)에 제공하는 것을 책임지며, 이는 그 다음에 응답을 앱(310)에 전송한다.
클라이언트 처리자(320)는 요청 처리자로부터 응답 데이터를 수신하면, 응답 데이터를 앱(310)에 전송할 수 있고, 비트율 매니저(340)에 의해 제공된 속도 제한에 기초하여 얼마나 빨리 데이터가 전송되는지를 제어할 수 있다. 클라이언트 처리자(320)는 전체 응답이 전송될 때까지 시간 간격마다 특정 양을 전송하는 것과 같이, 당업자에게 자명한 다양한 방법으로 속도 제한을 구현할 수 있다. 본 발명의 일 실시 예에서, 클라이언트 처리자(320)는 매초마다 데이터를 앱(310)으로 전송하도록 구성될 수 있으며, 데이터가 앱 서버(250)로부터 수신되면 클라이언트 처리자(320)는 비트율 매니저(340)에 의해 특정된 초당 속도 제한을 초과하지 않는 양으로 매초마다 데이터를 전송할 것이다. 예를 들어, 비트율 매니저(340)가 클라이언트 처리자(320)에게 앱(310)에 대한 데이터 속도를 1000kilobit/초로 제한해야 한다고 지시하면, 클라이언트 처리자(320)는 앱(310)으로 전체 응답이 전송될 때까지 매초마다 최대 1000kilobit을 전송할 것이다. 이는 요청 처리자(330)가 클라이언트 처리자(320)가 그 데이터를 앱(310)에 전송하는 속도와 다른 (예를 들어, 더 높은) 속도로 앱 서버(250)로부터 데이터를 수신하게 한다.
요청 처리자(330)는 클라이언트 처리자(320)가 휘발성 또는 비휘발성일 수 있는 장치 메모리에 데이터를 저장함으로써 그 데이터를 앱(310)에 송신하는 것보다 더 높은 속도로 앱 서버(250)로부터 데이터를 수신할 수 있다. 비휘발성 메모리는 더 풍부할 수 있으므로, 앱(310)으로 클라이언트 처리자(320)가 전송하는 속도가 앱 서버(250)로부터 수신되는 데이터보다 상당히 높은 속도인 경우와 같이, 대량의 데이터가 버퍼링(buffer) 될 필요가 있을 경우에 사용될 수 있다. 본 발명의 일 실시 예에 따르면, 스로틀링 처리자(333)는 클라이언트 처리자(320)가 아직 앱 서버(250)로부터 수신된 데이터의 일부를 앱(310)에 전송할 준비가 되어 있지 않을 경우에, 앱 서버 (250)로부터 수신된 데이터의 일부를 비휘발성 메모리에 저장하는 것과 같이, 버퍼링을 관리할 수 있다. 스로틀링 처리자(333)는 또한 장치상에서 가용한 메모리 또는 저장소를 초과하지 않기 위한 것과 같이, 앱 서버(250)로부터 데이터를 얼마나 많이 또는 얼마나 빨리 수신하는지를 제한할 수 있다.
예를 들어, 데이터 경로(335)는 TCP 기반 네트워크 소켓 일 수 있고, 스로틀링 처리자(333)는 네트워크 소켓으로부터 데이터를 수신하는 것을 중지할 수 있으며, 이는 앱 서버(250)가 그 네트워크 소켓상의 TCP 수신 윈도우가 가득 차면 데이터 전송을 중단하게 한다. 스로틀링 처리자(333)와 같은 요청 처리자는 앱 서버(250)로부터 수신된 데이터를 분석하여 앱 서버(250)로부터 데이터를 수신하는 속도를 결정할 수 있다.
어떤 경우에는, 사용자가 비디오 데이터를 시청하는 것을 멈추었을 때 (그러나 계속 수신할 때) 소비되지 않을 비디오 데이터의 수신을 피하기 위해, 비디오 앱에 의해 데이터가 실제로 소비되는 속도로 비디오 데이터를 수신하는 것이 바람직할 수 있다. 일반적으로 앱에서 데이터를 소비하는 속도와 네트워크/서버에서 데이터를 전달하는 속도가 관계가 적거나 거의 없으므로 다양한 유형의 앱에 이러한 접근 방식을 적용할 수 있다. 예를 들어, MPEG-4 비디오는 모바일 기기가 네트워크/서버로부터 비디오 데이터를 현재 수신할 수 있는 속도보다 낮은 비트율로 인코딩될 수 있으며, 예를 들면 장치가 혼잡하지 않은 셀(uncongested cell) 사이트상에서 기기가 양호한 셀룰러 신호를 갖고 있을 경우가 있다. 따라서 MPEG-4 비디오가 2mbps의 비트율로 인코딩되고 장치가 4mbps에서 해당 데이터를 수신하는 경우에, 사용자가 전체 비디오를 시청하지 않으면 수신된 비디오 데이터의 상당 부분, 예를 들어 50%가 낭비될 가능성이 있다. 본 발명의 하나 이상의 실시 예들은 비디오 인코딩 비트율을 네트워크 전달 비트율과 정렬함으로써 이를 해결할 수 있다.
본 발명의 일 실시 예에 따르면, 프록시(130)는 앱 서버(250)로부터 수신된 데이터를 해석(parsing)함으로써 비디오 및 네트워크 비트율을 조정할 수 있다. 앱(310)이 앱 서버(250)로부터 비디오를 요청할 때, 스로틀링 처리자(333)는 수신 된 데이터를 분석하여 비디오 인코딩 비트율을 결정할 수 있고, 이는 앱 서버(250)로부터 데이터를 수신할 속도를 결정하는 데에 사용될 수 있다. 예를 들어, 이전의 예시를 사용하여, 스로틀링 처리자(333)가 2mbps로 인코딩된 비디오를 검출할 때, 이는 앱 서버(250)로부터 동등한 속도로 데이터를 수신할 것을 보장할 수 있으며, 혹은 네트워크 전달 속도에 임의의 알려진/검출된 변화를 수용하기 위해 약간 더 폽게 조정된 것일 수 있다.
앱(310)으로의 데이터 전달 속도를 제한함으로써, 본 발명의 실시 예들은 적응형 비트율(ABR) 비디오 스트림과 같은 속도에 기초하여 데이터 크기를 적응시키는 콘텐츠의 데이터 소비를 감소시킬 수 있다. ABR 스트리밍 기술의 예로는 HTTP(dynamic adaptive streaming over http, DASH)를 통한 동적 적응형 스트리밍, Flash용 Adobe Adaptive Streaming, HLS(Httl Live Streaming) 및 Microsoft Smooth Streaming이 있다. 예를 들어 YouTube 비디오는 다양한 비디오 해상도로 인코딩되며 각 비디오 해상도는 특정 데이터 전송 속도에 해당하므로 YouTube 앱이 데이터 전송 속도에 따라 지원되는 최고 비디오 해상도를 요청한다. 아래 표는 각 비디오 해상도 품질에 해당하는 YouTube 앱의 예상 데이터 사용률을 보여준다. YouTube 앱은 감지된 네트워크 속도가 해당 비디오에 대응하는 데이터 사용량을 초과하는 경우에만 해상도를 선택한다. 프록시(130)는 바람직한 비디오 해상도 또는 그 바로 위의 비트율 제한을 사용하여 YouTube 앱에 의해 어떤 해상도가 선택되는 지를 효과적으로 제어한다.
비디오 서비스 초당 데이터 사용량 예상되는 해상도 품질 1080p에 비해 예상되는 절약
YouTube 4464 1080p ---
2114 720p 53%
927 480p 79%
600 360p 87%
349 240p 92%
100 144p 98%
ABR 스트림에 비트율 제한을 적용한 결과는, 비디오의 지연이나 버퍼링을 일으키지 않고 가능한 최고 해상도와 비교할 때 총 데이터 소비가 90% 이상까지 크게 감소할 수 있다는 것이다. 유일한 영향은 낮은 해상도의 비디오에 있으며, 사용자는 데이터 사용 비용을 절약하기 위해 낮은 해상도의 비디오를 기꺼이 볼 수도 있다. 표에 나타난 바와 같이, 데이터 사용량의 차이는 각 해상도 수준간에 상당히 다르며 일반적으로 대응되는 해상도가 높아지는 것보다 빠르게 증가한다. 예를 들어, 360p에서 720p로 2배 증가하면 데이터 소비는 3.4 배 증가한다. 단 하나의 해상도 수준으로 축소하면 1080p에서 720p로의 해상도 감소가 33%이지만 데이터 사용량 감소에서 53%가 발생하는 등 데이터 사용량이 크게 감소할 수 있다. 소형 모바일 기기의 경우 눈에 띄는 가시적인 차이가 거의 없으나, 사용자가 50% 이상 데이터를 절약할 수 있다.
도 6은 본 발명의 일 실시 예에 따른 프록시를 통한 앱과 서버 간의 요청 처리를 도시한 프로세스 타이밍도이다. 도 6은 셀룰러 접속에서의 데이터 소비를 감소시키는 것과 같이 비트율이 제한되는 본 발명의 실시 예를 도시한다. 앱(310)이 앱 서버(250)로부터 비디오와 같은 데이터에 대한 요청을 수행할 때, 단계(410)에서 요청은 클라이언트 처리자(320)에 의해 인터셉트된다. 클라이언트 처리자(320)는 이를 처리하는 방법을 결정할 수 있거나 요청 매니저(350)에게 결정을 하기 위해 요청을 제공할 수 있으며, 이는 요청을 처리하기 위해 스로틀링 처리자(333)를 지정할 수 있다. 스로틀링 처리자(333)는 단계(415)에서 비트율 매니저(340)와 협의하여, 앱과 관련된 정책, 네트워크 유형, 또는 요청되는 데이터의 유형에 기초하여 적용될 적절한 비트율 제한을 결정할 수 있다. 클라이언트 처리자(320)는 요청을 처리하기 위해 앱 서버(250)와의 상호 작용을 처리하는 단계(420)에서 스로틀링 처리자(333)에 요청을 제출한다.
앱 서버(250)가 단계(425)에서 요청에 대한 응답을 송신하기 시작할 때, 스로틀링 처리자(333)는 서버로부터 데이터를 수신해야하는 속도를 결정하는 것과 같은 응답을 분석할 수 있다. 응답 데이터가 앱 서버(250)로부터 수신됨에 따라, 스로틀링 처리자(333)는 단계(430)에서 휘발성 저장소, 비휘발성 메모리, 또는 이들의 조합에 응답 데이터를 저장할 수있다. 데이터가 앱 서버(250)로부터 수신되면, 단계(435)에서 앱 서버(250)로부터의 스로틀링 처리자(333)에 의해 수신된 속도와 상이한 속도로 발생할 수 있는 저장된 응답 데이터를 앱(310)에 전송할 수 있다. 이것은 추가 응답 데이터가 제1 요청에 대해 단계(440)에서 수신됨에 따라 계속된다. 응답이 완료되면, HTTP URL을 통해 개별적으로 어드레싱될 수 있는(addressable) 별개의 시간-기반 청크로 분해되는 ABR 비디오 스트림에 대한 것과 같이, 앱(310)은 단계(445)에서 후속적인 데이터에 대한 추가적인 요청을 계속할 수 있다. 도 6의 실시 예는 당업자에게 명백한 바와 같이, 앱(310)에 의해 요구된 데이터가 완료될 때까지 계속된다고 가정할 수 있다.
본 발명의 다른 실시 예에 따르면, 비트율 제한은 앱 서버(250)에 의해 보고되는 스트림들의 리스트를 수정하는 것과 같은 다른 수단을 통해 제어될 수 있다. 예를 들어, ABR 스트리밍 접근법들 중 몇몇은 매니페스트(manifest)라는 목록을 통해 가용한 스트림의 앱에게 서버가 알리는 것에 의존한다. 비디오가 처음 요청되면 앱은 서버에서 매니페스트를 가져 와서 재생할 스트림을 선택하고, 여기서 선택은 일반적으로 앱에서 감지한 네트워크 속도를 기반으로 한다. 따라서 비트율을 제어하는 또 다른 접근법은 가용한 스트림을 앱에 제한하는 것과 같이, 서버로부터 수신한 매니페스트를 수정하는 것이다. 예를 들어, 앱(310)이 앱 서버(250)로부터 매니페스트를 요청할 때, 프록시(130)는 매니페스트를 앱(310)으로 전송하기 전에 매니페스트를 수정하고 더 높은 해상도의 비디오 스트림을 제거함으로써, 앱(310)이 매니페스트에 남아 있는 스트림만을 재생할 수 있게 제한한다. 이는 효과적으로 프록시(130)가 앱(310)을 비트율 매니저(340)에 의해 지정된 정책들 내에서 허용되는 스트림들로 제한하도록 허용한다. 이 접근법은 서버가 클라이언트에 다수의 스트림을 제공하거나 광고하는 임의의 스트리밍 접근법에 적용될 수 있으며, 여기서 본 발명의 실시 예에 의해 이러한 가용한 스트림의 세트는 수정될 수 있다.
본 발명의 다른 실시 예에 따르면, 비트율 제한이 제어될 수 있는 다른 수단은 서버에 의해 제공되거나 광고되는 스트림 세트 내의 하나 이상의 스트림에 대한 액세스를 거부하거나 그렇지 않으면 차단하는 것이다. 예를 들어, 프록시(130)는 다른 스트림에 대한 액세스를 차단하면서 앱(310)에 의해 요청된 하나 이상의 가용한 스트림에 대한 액세스를 허용할 수 있으며, 이는 프록시(130)가 비트율 매니저(340)에 의해 지정된 정책 내에서 허용되는 스트림에 앱(310)을 제한하는 것을 효과적으로 허용할 것이다. 스트림에 대한 액세스가 차단될 수 있는 방법은 다양하며, 이는 연결 거부, 요청에 대한 오류 반환 또는 요청 시간 초과 허용을 포함한다. 이러한 접근법은 이를 지원하는 특정 앱에 선택적으로 적용될 수 있으며, 이는 일부 앱이 특정 차단 메커니즘을 제대로 지원하지 못할 수 있고, 특정 방식으로 차단될 필요가 있을 수 있기 때문이다.
본 발명의 다른 실시 예에 따르면, 데이터가 앱 서버(250)로부터 기기에 의해 수신되는 방식의 빈도 또는 크기가 앱(310)이 데이터를 요청하거나 수신하는 방법과 다르도록 프록시(130)는 데이터를 버스트(burst) 방식으로 수신하는 것을 지원할 수 있다. 예를 들어, 사용자가 전체 비디오를 볼 수 없기 때문에 전체 5분의 프로그레시브 비디오 대신 다음 30초와 같이 시청하면서의 비디오의 다음 부분적인 일부만 다운로드 하는 것이 바람직할 수 있다. 이러한 경우, 예를 들어 빠른 네트워크와 빠른 서버는 사용자가 10초만 시청했음에도 5분짜리 비디오 전체를 다운로드 할 수 있으며, 이 모든 정보는 여전히 사용자의 데이터 계획에 반영됩니다.
반면에 ABR 비디오에 공통적인 것처럼 한 번에 다음 7초와 같이, 한 번에 비디오를 너무 적게 다운로드 하는 것은 바람직하지 않을 수 있다. 이는 셀룰러 라디오와 연결이 아이들(idle)하게 되는 것으로부터 방지할 수 있기 때문이다. 이 경우, 셀룰러 라디오는 비디오가 매번 다운로드 되는 양(예를 들어, 5 초)보다 긴 (예를 들어, 15초) 비활성 타이머를 가질 수 있기 때문에 활성, 고전력 모드에 머무를 수 있다. 셀룰러 네트워크에서는 셀 타워 시그널링, 정체 및 장치 배터리 소비가 증가할 수 있다. 네트워크의 유형 및 실제 속도에 따라, 소비되지 않은 데이터의 낭비를 피하기 위해 너무 많이 다운로드 하지 않고 셀룰러 라디오가 아이들 상태가 되도록 충분히 다운로드 하는 것 사이의 균형을 맞추기 위해 상이한 버스트 크기로 데이터를 수신하는 것이 바람직할 수 있다.
도 7은 본 발명의 다른 실시 예에 따라 앱(310)과 서버(250) 간의 네트워크 트래픽의 모니터링 및 제어를 가능하게 하는 프록시(130) 내의 소프트웨어 구성요소의 블록도이다. 도 7은 다르게는 프록시(130) 또는 버스팅 처리자(BurstingHandler)(334)없이 앱(310)에 의해 이루어졌을 상이한 양 또는 상이한 빈도로 데이터가 요청 또는 수신되도록, 버스팅 처리자(334)가 앱 서버(250)로부터 버스트로 데이터를 요청하거나 수신하기 위해 제공된 유형의 요청 처리자인 경우의 본 발명의 실시 예를 도시한다. 버스팅 처리자(334)는 데이터 경로(325)상의 앱(310)에 데이터를 송수신하는 클라이언트 처리자(320)와 독립적으로 데이터 경로(335)상의 앱 서버(250)로부터 데이터를 요청한다. 버스팅 처리자(334)는 비트율 매니저(340)와 함께 (예를 들어, 효율 및 성능을 향상시키거나 최대화하기 위해) 다양한 요소들에 기초하여 앱 서버(250)로부터 데이터를 요청/수신하기 위한 적절한 속도를 결정할 수 있다.
예를 들어, 셀룰러 접속의 아이들 시간을 증가시키거나 최대화하는 요소는 네트워크 유형(예를 들어, LTE, EDGE 등), 유효 네트워크 속도, 네트워크 비활성 타이머(예를 들어, 15 초) 및 비디오 인코딩 비트율을 포함할 수 있다. 추가 예로서, 다음 방정식을 사용하여 원하는 네트워크 아이들 시간, 네트워크 전달 비트율 및 비디오 인코딩 비트율에 따라 필요한 버스트 크기를 계산할 수 있다.
<바람직한 아이들 시간> / <비트율 비율> * <비디오 인코딩 비트율> = <버스트 크기>
여기서 비트율의 비율은 비디오 인코딩 비트율과 네트워크 전달 비트율 간의 비율이다. 예를 들어 비디오가 초당 2MB로 인코딩되고 네트워크의 데이터 전송 속도가 초당 4MB인 경우 값은 0.5이다. 예를 들어, 이 동일한 비트율 비율로, 원하는 아이들 시간이 45초인 경우, 예를 들어 15초 비활성 시간 창 다음에 30초 휴면 시간 창이 오도록 하는 경우, 버스트 크기는 다음과 같이 계산된다.
45 초 / 0.5 * 2MB/초 = 180MB
장치의 배터리 수명을 개선하거나, 비디오 스트림의 스톨(stalling)을 피하거나, 또는 당업자에게 자명한 다른 시나리오와 같은 다른 이유로 버스트 크기를 결정하기 위해 부가적인 요소가 고려될 수 있음을 주목해야한다 .
도 8은 본 발명의 다른 실시 예에 따른 프록시(130)를 통한 앱(310)과 서버(250) 사이의 요청 처리를 나타내는 프로세스 타이밍도이다. 도 8은 셀룰러 접속에 대한 아이들 시간을 증가시키거나 최대화하는 것과 같이 버스트가 수행되는 본 발명의 실시 예를 도시한다. 앱(310)이 앱 서버(250)로부터 비디오와 같은 데이터에 대한 요청을 수행할 때, 요청은 클라이언트 처리자(320)에 의해 인터셉트된다. 클라이언트 처리자(320)는 그것을 처리하는 방법을 결정할 수 있거나 단계(510)에서 요청 매니저(350)가 결정을 하기 위해 요청을 제공할 수 있으며, 이는 요청을 처리하기 위해 버스팅 처리자(334)를 지정할 수 있다. 클라이언트 처리자(320)는 요청을 프로세싱하기 위해 앱 서버(250)와의 상호 작용을 처리하는 단계(515)에서 버스팅 처리자(334)에 요청을 제출한다.
앱 서버(250)가 단계(520)에서 요청에 대한 응답을 송신하기 시작할 때, 버스팅 처리자(334)는 서버로부터 데이터를 수신해야하는 속도를 결정하는 것과 같은 응답을 분석(parse)할 수 있고, 또한 앱(310)으로 전송돼야 하는 데이터의 속도를 설정하기 위해 클라이언트 처리자(320)와 함께 조정할 수 있다. 응답 데이터가 앱 서버(250)로부터 수신될 때, 버스팅 처리자(334)는 단계(525)에서 응답 데이터를 휘발성 메모리, 비휘발성 메모리, 또는 이들의 조합 중 어느 하나에 저장할 수 있다. 버스팅 처리자(334)는 버스트 크기를 계산하여 최소 셀룰러 아이들 시간을 달성하는 것과 같은 정책에 기초하여 단계(530)에서 결정된 버스트 크기까지 추가 데이터를 수신하기 시작한다. 데이터 스트림 각각이 HTTP URL을 통해 개별적으로 어드레스되는 것과 같이 데이터의 하나 이상의 개별적으로 어드레스 가능한 청크를 포함하면, 버스팅 처리자(334)는 목표 버스트 크기까지 데이터를 수신하기 위해 필요한 요청을 할 수 있다.
목표 버스트 크기의 데이터가 수신되면, 버스팅 처리자(334)는 목표 아이들 시간의 시작을 시작하는 TCP 접속에 대한 것과 같은 관련 네트워크 접속을 종료하는 것을 포함할 수 있는 단계(535)에서 데이터 수신을 중단할 수 있다. 데이터가 앱 서버(250)로부터 수신되면, 단계(540)에서 클라이언트 처리자(320)는 앱 서버(250)로부터 버스팅 처리자(334)에 의해 수신된 속도와 상이한 속도로 발생할 수 있는 저장된 응답 데이터를 앱(310)에 전송할 수 있다. 이는 단계(545)에서 계속되고 필요에 따라 앱(310)로 제1 버스트에서 수신된 데이터가 전송될 때까지 그 이후로도 계속된다. 다음 버스트가 시작될 준비가 되면, 단계(550)에서 버스팅 처리자(334)는 앱 서버(250)로부터 후속 데이터를 요청하기 시작할 수 있고, 다음 데이터를 단계(555)에서 클라이언트 처리자(320)를 위해 저장하기 시작할 수 있으며, 이는 그 다음에 앱 서버(250)로부터 버스팅 처리자(334)에 의해 수신된 속도와 상이할 수 있는 속도로 앱(310)으로 후속적인 응답 데이터를 전송할 수 있다. 당업자에게 자명한 바와 같이, 앱(310)에 의해 요청된 데이터가 완료될 때까지, 도 8은 계속될 것으로 가정될 수 있다.
본 발명이 특정 예시적인 실시 예들과 관련하여 기술되었지만, 본 발명은 개시된 실시 예들에 제한되지 않으며, 그와 반대로, 본 발명은 다양한 변형 예 및 균등 한 구성을 포함하는 것으로 이해되어야한다. 다음의 청구 범위에 의해 정의된 바와 같은 본 발명의 사상 및 범위를 벗어나지 않고 본 기술 분야의 통상의 기술자 및 그 등가물일 수 있다.

Claims (26)

  1. 컴퓨터 프로세서 및 네트워크를 통해 상기 프로세서와 데이터를 전송 또는 수신하기 위한 서버에 대한 네트워크 접속을 갖는 휴대가능한 통신 기기상의 통신 트래픽 관리 방법은:
    상기 프로세서상에서 실행되는 트래픽 관리자 애플리케이션에 의해, 상기 서버로부터 수신되고 또한 제 1 애플리케이션에 의해서 요청되는 비디오 데이터를 포함하는 제 1 데이터의 전자 트래픽을 인터셉트하는 단계 -- 상기 트래픽 관리자 애플리케이션은 상기 네트워크 접속을 따르는 제 1 전달 속도에서 상기 서버로부터 상기 비디오 데이터를 수신함;
    상기 트래픽 관리자 애플리케이션에 의해서, 상기 프로세서상에서 실행되고 있는 상기 제 1 애플리케이션을 식별하고 또한 상기 네트워크를 통해서 상기 서버로부터 수신되는 상기 제 1 데이터를 전달하는 단계;
    상기 트래픽 관리자 애플리케이션에 의해서, 상기 제 1 애플리케이션, 상기 네트워크 접속의 유형, 또는 상기 서버 중의 적어도 하나와 연관된 제 1 정책을 선택하는 단계;
    상기 제 1 정책에 따라서 상기 트래픽 관리자 애플리케이션에 의해서, 상기 서버로부터 수신되는 상기 비디오 데이터의 상기 제 1 애플리케이션으로의 제 2 전달 속도를 제한하는 단계 -- 내부 네트워크 데이터 경로를 따르는 상기 제 2 전달 속도는 상기 네트워크 접속을 따르는 상기 비디오 데이터의 상기 제 1 전달 속도 보다 낮으며, 상기 제 2 전달 속도는 특정 목표 비디오 해상도에 대응함;를 포함하는,
    통신 트래픽 관리 방법.
  2. 제 1 항에 있어서,
    상기 비디오 데이터의 상기 제 2 전달 속도를 제한하는 상기 단계는 상기 제1 애플리케이션에 의해 인지되는 상기 네트워크의 현재 속도를 상기 네트워크의 상기 현재 속도보다 적은 제1 데이터 속도로 스로틀링(throttling)하는 단계를 포함하는
    통신 트래픽 관리 방법.
  3. 제 2 항에 있어서,
    상기 제1 데이터의 상기 전자 트래픽은 하이퍼 텍스트 전송 프로토콜(Hypertext Transfer Protocol, HTTPS)을 위한 보안 프로토콜을 사용하여 전송되는 데이터를 포함하는,
    통신 트래픽 관리 방법.
  4. 제 1 항에 있어서,
    상기 비디오 데이터의 상기 제 2 전달 속도를 제한하는 상기 단계는 상기 서버로의 또는 상기 서버로부터의 상기 비디오 데이터의 상기 제 2 전달 속도를 상기 네트워크의 현재 속도보다 적은 제1 데이터 속도로 스로틀링하는 단계를 포함하는,
    통신 트래픽 관리 방법.
  5. 제 1 항에 있어서,
    상기 제1 데이터의 상기 전자 트래픽은 적응형 비트율 스트림을 포함하는,
    통신 트래픽 관리 방법.
  6. 제 1 항에 있어서,
    상기 제1 데이터의 상기 전자 트래픽은 프로그레시브 스트림(progressive stream)을 포함하는,
    통신 트래픽 관리 방법.
  7. 제 1 항에 있어서,
    상기 제1 애플리케이션은 매니페스트(manifest)에 의해 제어되는 바와 같이 상이한 대응 해상도를 갖는 복수의 데이터 속도를 지원가능한 것이며;
    상기 비디오 데이터의 상기 제 2 전달 속도를 제한하는 상기 단계는 상기 데이터 속도 중 제1 데이터 속도를 초과하는 것을 숨기거나 제거하도록 상기 매니페스트를 편집하는 단계를 포함하는,
    통신 트래픽 관리 방법.
  8. 제 1 항에 있어서,
    상기 제1 애플리케이션은 상이한 대응 해상도를 갖는 복수의 데이터 속도를 지원가능한 것이며;
    상기 비디오 데이터의 상기 제 2 전달 속도를 제한하는 상기 단계는 상기 데이터 속도 중 제1 데이터 속도를 초과하는 것으로의 액세스에 대한 실패 또는 차단 단계를 포함하는,
    통신 트래픽 관리 방법.
  9. 제 1 항에 있어서,
    상기 트래픽 관리자 애플리케이션에 의해, 상기 네트워크를 통해 상기 서버로 또는 상기 서버로부터 제2 데이터를 전달하고 프로세서상에서 실행되는 제2 애플리케이션을 식별하는 단계;
    상기 트래픽 관리자 애플리케이션에 의해, 상기 제2 애플리케이션으로의 또는 상기 제2 애플리케이션으로부터의 상기 제2 데이터의 전자 트래픽을 인터셉트하는 단계; 및
    상기 트래픽 관리자 애플리케이션에 의해, 상기 제2 애플리케이션으로의 또는 상기 제2 애플리케이션으로부터의 또는 상기 서버로의 또는 상기 서버로부터의 상기 제2 데이터의 전달 속도를 제한하는 단계를 더 포함하는,
    통신 트래픽 관리 방법.
  10. 제 9 항에 있어서,
    상기 비디오 데이터 및 상기 제2 데이터의 상기 전달 속도를 제한하는 상기 단계는 상기 비디오 데이터의 상기 전달 속도가 상기 제2 데이터의 상기 전달 속도를 초과하도록 상기 비디오 데이터 및 상기 제2 데이터의 상기 전달 속도를 동시에 제한하는 단계를 포함하는,
    통신 트래픽 관리 방법.
  11. 제 1 항에 있어서,
    상기 전자 트래픽을 인터셉트하는 단계는 상기 프로세서에서 실행중인 내부 프록시를 사용하는 단계를 포함하는,
    통신 트래픽 관리 방법.
  12. 제 1 항에 있어서,
    상기 전자 트래픽을 인터셉트하는 단계는 상기 프로세서상의 가상 사설망(virtual private network, VPN) 인터페이스를 사용하는 단계를 포함하는,
    통신 트래픽 관리 방법.
  13. 제 1 항에 있어서,
    상기 전자 트래픽을 인터셉트하는 단계는 상기 프로세서상에서 수정된 상기 제1 애플리케이션을 실행하는 단계를 포함하며, 상기 수정된 제1 애플리케이션은 상기 전자 트래픽의 인터셉트를 요청하도록 구성된,
    통신 트래픽 관리 방법.
  14. 통신 트래픽 관리를 위한 시스템에 있어서, 상기 시스템은:
    컴퓨터 프로세서, 및 네트워크를 통해 상기 프로세서와 함께 데이터를 전송 또는 수신하기 위한 서버에 대한 네트워크 접속을 갖는 휴대가능한 통신 기기; 및
    상기 프로세서에 연결된 비-휘발성 저장 장치를 포함하며, 상기 비-휘발성 저장 장치는 명령을 저장하며, 상기 명령은 상기 프로세서가 트래픽 관리자 애플리케이션을 실행하여,
    상기 서버로부터 수신되고 또한 제 1 애플리케이션에 의해서 요청되는 비디오 데이터를 포함하는 제 1 데이터의 전자 트래픽을 인터셉트하고 -- 상기 트래픽 관리자 애플리케이션은 상기 네트워크 접속을 따르는 제 1 전달 속도에서 상기 서버로부터 상기 비디오 데이터를 수신함;
    상기 프로세서상에서 실행되고 있는 상기 제 1 애플리케이션을 식별하고 또한 상기 네트워크를 통해서 상기 서버로부터 수신되는 상기 제 1 데이터를 전달하고;
    상기 제 1 애플리케이션, 상기 네트워크 접속의 유형, 또는 상기 서버 중의 적어도 하나와 연관된 제 1 정책을 선택하고;
    상기 제 1 정책에 따라서, 상기 서버로부터 수신되는 상기 비디오 데이터의 상기 제 1 애플리케이션으로의 제 2 전달 속도를 제한하도록 -- 내부 네트워크 데이터 경로를 따르는 상기 제 2 전달 속도는 상기 네트워크 접속을 따르는 상기 비디오 데이터의 상기 제 1 전달 속도 보다 낮으며, 상기 제 2 전달 속도는 특정 목표 비디오 해상도에 대응함 -- 구성되는,
    통신 트래픽 관리를 위한 시스템.
  15. 제 14 항에 있어서,
    상기 명령은 상기 프로세서에 의해 실행될 때, 추가로 상기 프로세서로 하여금, 상기 제1 애플리케이션에 의해 인지된 상기 네트워크의 현재 속도를 상기 현재의 속도보다 적은 제1 데이터 속도로 스로틀링함으로써 상기 프로세서가 상기 제1 데이터의 전달 속도를 제어하게 하는,
    통신 트래픽 관리를 위한 시스템.
  16. 제 15 항에 있어서,
    상기 제1 데이터의 상기 전자 트래픽은 하이퍼 텍스트 전송 프로토콜(HTTPS)을 위한 보안 프로토콜을 사용하여 전송되는 데이터를 포함하는,
    통신 트래픽 관리를 위한 시스템.
  17. 제 14 항에 있어서,
    상기 명령은 프로세서에 의해 실행될 때, 추가로 상기 프로세서로 하여금, 상기 네트워크의 현재 속도보다 적은 제1 데이터 속도로 상기 서버로의 또는 상기 서버로부터의 상기 제1 데이터의 전달 속도를 스로틀링함으로써 상기 제1 데이터의 전달 속도를 제어하게 하는,
    통신 트래픽 관리를 위한 시스템.
  18. 제 14 항에 있어서,
    상기 제1 데이터의 상기 전자 트래픽은 적응형 비트율 스트림을 포함하는,
    통신 트래픽 관리를 위한 시스템.
  19. 제 14 항에 있어서,
    상기 제1 데이터의 상기 전자 트래픽은 프로그레시브 스트림을 포함하는,
    통신 트래픽 관리를 위한 시스템.
  20. 제 14 항에 있어서,
    상기 제1 애플리케이션은 매니페스트에 의해 제어되는 바와 같이 상이한 대응 해상도를 갖는 복수의 데이터 속도가 지원가능한 것이며, 상기 명령은 상기 프로세서에 의해 실행될 때, 추가로 상기 프로세서로 하여금 상기 데이터 속도 중에 제1 데이터 속도를 초과하는 것을 숨기거나 제거하기 위해 상기 매니페스트를 편집함으로써 상기 제1 데이터의 전달 속도를 제어하게 하는,
    통신 트래픽 관리를 위한 시스템.
  21. 제 14 항에 있어서,
    상기 제1 애플리케이션은 상이한 대응 해상도를 갖는 복수의 데이터 속도를 지원가능한 것이며, 상기 명령은 상기 프로세서에 의해 실행될 때, 추가로 상기 프로세서로 하여금, 상기 데이터 속도 중에 제1 데이터 속도를 초과하는 것에 대한 액세스를 실패 또는 차단함으로써 상기 제1 데이터의 전달 속도를 제어하게 하는,
    통신 트래픽 관리를 위한 시스템.
  22. 제 14 항에 있어서,
    상기 명령은 상기 프로세서에 의해 실행될 때, 추가로 상기 프로세서로 하여금:
    상기 네트워크를 통해 상기 서버로 또는 상기 서버로부터 제2 데이터를 전달하고 상기 프로세서상에서 실행되는 제2 애플리케이션을 식별;
    상기 제2 애플리케이션으로의 또는 상기 제2 애플리케이션으로부터의 상기 제2 데이터의 전자 트래픽을 인터셉트; 및
    상기 제2 애플리케이션으로의 또는 상기 제2 애플리케이션으로부터의 또는 상기 서버로의 또는 상기 서버로부터의 상기 제2 데이터의 전달 속도를 제어하게 하는,
    통신 트래픽 관리를 위한 시스템.
  23. 제 22 항에 있어서,
    상기 명령은 상기 프로세서에 의해 실행될 때, 추가로 상기 프로세서로 하여금, 상기 제1 및 제2 데이터의 전달 속도를 동시에 제한함으로써 상기 제1 및 제2 데이터의 전달 속도를 제어하게 하여, 상기 제1 데이터의 전달 속도가 상기 제2 데이터의 전달 속도를 초과하도록 하는,
    통신 트래픽 관리를 위한 시스템.
  24. 제 14 항에 있어서,
    상기 명령은 상기 프로세서에 의해 실행될 때, 추가로 상기 프로세서로 하여금, 상기 프로세서상에서 실행되는 내부 프록시를 사용함으로써 상기 전자 트래픽을 인터셉트하게 하는,
    통신 트래픽 관리를 위한 시스템.
  25. 제 14 항에 있어서,
    상기 명령은 상기 프로세서에 의해 실행될 때, 추가로 상기 프로세서로 하여금, 상기 프로세서상의 가상 사설망(VPN) 인터페이스를 사용함으로써 상기 전자 트래픽을 인터셉트하게 하는,
    통신 트래픽 관리를 위한 시스템.
  26. 제 14 항에 있어서,
    상기 명령은 상기 프로세서에 의해 실행될 때, 추가로 상기 프로세서로 하여금, 상기 프로세서상의 수정된 상기 제1 애플리케이션을 실행함으로써 상기 전자 트래픽의 인터셉트를 요청하게 하고, 여기서 상기 수정된 제1 애플리케이션은 상기 전자 트래픽의 인터셉트를 요청하기 위해 구성된 것인,
    통신 트래픽 관리를 위한 시스템.
KR1020177009163A 2014-09-05 2015-09-04 적응 속도 제어와 트래픽 관리의 시스템 및 방법 Active KR102491452B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201462046874P 2014-09-05 2014-09-05
US62/046,874 2014-09-05
PCT/US2015/048721 WO2016037148A1 (en) 2014-09-05 2015-09-04 System and method of adaptive rate control and traffic management

Publications (2)

Publication Number Publication Date
KR20170063678A KR20170063678A (ko) 2017-06-08
KR102491452B1 true KR102491452B1 (ko) 2023-01-20

Family

ID=55440428

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020177009163A Active KR102491452B1 (ko) 2014-09-05 2015-09-04 적응 속도 제어와 트래픽 관리의 시스템 및 방법

Country Status (7)

Country Link
EP (2) EP3189486B1 (ko)
JP (2) JP6606176B2 (ko)
KR (1) KR102491452B1 (ko)
CN (1) CN107113248B (ko)
AU (1) AU2015311691B2 (ko)
CA (1) CA2997611A1 (ko)
WO (1) WO2016037148A1 (ko)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102457792B1 (ko) * 2018-05-31 2022-10-20 모보파일스 인코포레이티드 디비에이 모보라이즈 동적 채널 본딩을 위한 시스템 및 방법
CN110505660B (zh) * 2019-07-23 2023-07-14 维沃移动通信有限公司 一种网络速率调整方法及终端设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110082924A1 (en) * 2009-10-06 2011-04-07 Openwave Systems Inc. Managing network traffic by editing a manifest file
US20120023190A1 (en) * 2010-07-26 2012-01-26 Ari Backholm Mobile network traffic coordination across multiple applications
WO2013017165A1 (en) * 2011-08-02 2013-02-07 Telefonaktiebolaget L M Ericsson (Publ) Shaping media traffic based on manifest file in http adaptive streaming

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6532593B1 (en) * 1999-08-17 2003-03-11 General Instrument Corporation Transcoding for consumer set-top storage application
US7286471B2 (en) * 2002-03-23 2007-10-23 Mindspeed Technologies, Inc. Dynamic bandwidth allocation for wide area networks
US9398103B2 (en) * 2011-04-15 2016-07-19 Qualcomm Incorporated Methods and apparatus for enhancing device performance through flow control
US8683013B2 (en) * 2011-04-18 2014-03-25 Cisco Technology, Inc. System and method for data streaming in a computer network
US10292066B2 (en) * 2011-11-04 2019-05-14 Cisco Technology, Inc. System and method of modifying congestion control based on mobile system information
US20130159150A1 (en) * 2011-12-19 2013-06-20 Verizon Patent And Licensing, Inc. Mobile device data metering, bandwidth allocation, and traffic control
EP2910001A4 (en) * 2012-10-18 2016-04-20 Giraffic Technologies Ltd OVERLOAD CONTROL METHOD FOR DYNAMICALLY MAXIMIZING A COMMUNICATION CONNECTION THROUGHPUT
US8897292B2 (en) * 2012-12-31 2014-11-25 Telefonaktiebolaget L M Ericsson (Publ) Low pass filter for hierarchical pipelined distributed scheduling traffic manager
US20140226571A1 (en) * 2013-02-13 2014-08-14 Qualcomm Incorporated Apparatus and method for enhanced application coexistence on an access terminal in a wireless communication system
CN103560862B (zh) * 2013-10-18 2017-01-25 华为终端有限公司 移动终端及其编码速率控制方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110082924A1 (en) * 2009-10-06 2011-04-07 Openwave Systems Inc. Managing network traffic by editing a manifest file
US20120023190A1 (en) * 2010-07-26 2012-01-26 Ari Backholm Mobile network traffic coordination across multiple applications
WO2013017165A1 (en) * 2011-08-02 2013-02-07 Telefonaktiebolaget L M Ericsson (Publ) Shaping media traffic based on manifest file in http adaptive streaming

Also Published As

Publication number Publication date
EP3189486A1 (en) 2017-07-12
AU2015311691A1 (en) 2017-04-20
EP3609164A1 (en) 2020-02-12
CA2997611A1 (en) 2016-03-10
EP3609164B1 (en) 2021-03-31
JP6606176B2 (ja) 2019-11-13
JP2020043568A (ja) 2020-03-19
WO2016037148A1 (en) 2016-03-10
KR20170063678A (ko) 2017-06-08
AU2015311691B2 (en) 2020-11-26
EP3189486B1 (en) 2019-08-28
JP2017530624A (ja) 2017-10-12
CN107113248B (zh) 2021-03-19
CN107113248A (zh) 2017-08-29
JP6974412B2 (ja) 2021-12-01
EP3189486A4 (en) 2018-04-11

Similar Documents

Publication Publication Date Title
US11570114B2 (en) System and method of adaptive rate control and traffic management
US12231982B2 (en) Systems and methods for dynamic channel bonding
CN103875304B (zh) 无线通信设备及通过无线通信设备检索内容的方法
US8977751B2 (en) Network usage throttling systems and methods
US10305952B2 (en) Preference-aware content streaming
US11259352B2 (en) Systems, methods, and media for providing multi-homing
US10070348B2 (en) Hypertext transfer protocol support over hybrid access
US10687341B2 (en) Systems, methods, and media for scheduling traffic of a communication session between an application on a WiFi network and another device
JP2020507285A (ja) スケジューリング制限による無線技術使用の制御
JP6974412B2 (ja) 適応型レート制御及びトラフィック管理のシステム及び方法
EP4011044B1 (en) Technique for controlling and performing data traffic handling in a core network domain
US20240292265A1 (en) Automatic adjustment of throughput rate to optimize wireless device battery performance
US11297634B2 (en) Systems, methods, and media for scheduling traffic of a communication session between an application on a WiFi network and another device

Legal Events

Date Code Title Description
PA0105 International application

Patent event date: 20170404

Patent event code: PA01051R01D

Comment text: International Patent Application

PG1501 Laying open of application
A201 Request for examination
PA0201 Request for examination

Patent event code: PA02012R01D

Patent event date: 20200810

Comment text: Request for Examination of Application

E902 Notification of reason for refusal
PE0902 Notice of grounds for rejection

Comment text: Notification of reason for refusal

Patent event date: 20211110

Patent event code: PE09021S01D

E90F Notification of reason for final refusal
PE0902 Notice of grounds for rejection

Comment text: Final Notice of Reason for Refusal

Patent event date: 20220418

Patent event code: PE09021S02D

E701 Decision to grant or registration of patent right
PE0701 Decision of registration

Patent event code: PE07011S01D

Comment text: Decision to Grant Registration

Patent event date: 20221026

GRNT Written decision to grant
PR0701 Registration of establishment

Comment text: Registration of Establishment

Patent event date: 20230118

Patent event code: PR07011E01D

PR1002 Payment of registration fee

Payment date: 20230118

End annual number: 3

Start annual number: 1

PG1601 Publication of registration