KR102078869B1 - 데이터 전송률 향상을 위한 다중 연결 제어 방법 및 장치 - Google Patents

데이터 전송률 향상을 위한 다중 연결 제어 방법 및 장치 Download PDF

Info

Publication number
KR102078869B1
KR102078869B1 KR1020150036758A KR20150036758A KR102078869B1 KR 102078869 B1 KR102078869 B1 KR 102078869B1 KR 1020150036758 A KR1020150036758 A KR 1020150036758A KR 20150036758 A KR20150036758 A KR 20150036758A KR 102078869 B1 KR102078869 B1 KR 102078869B1
Authority
KR
South Korea
Prior art keywords
multiple connections
connections
client
determined
service
Prior art date
Application number
KR1020150036758A
Other languages
English (en)
Other versions
KR20160111723A (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 삼성전자주식회사
Priority to KR1020150036758A priority Critical patent/KR102078869B1/ko
Priority to CN202010994345.9A priority patent/CN112118177B/zh
Priority to EP15885671.6A priority patent/EP3261319B1/en
Priority to US15/558,869 priority patent/US10554727B2/en
Priority to CN201580080076.2A priority patent/CN107637046B/zh
Priority to PCT/KR2015/011853 priority patent/WO2016148370A1/ko
Priority to EP18205590.5A priority patent/EP3461107B1/en
Publication of KR20160111723A publication Critical patent/KR20160111723A/ko
Priority to US16/720,983 priority patent/US10999348B2/en
Application granted granted Critical
Publication of KR102078869B1 publication Critical patent/KR102078869B1/ko

Links

Images

Classifications

    • H04L67/32
    • 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/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H04L67/025Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
    • 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/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • 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/0876Network utilisation, e.g. volume of load or congestion level
    • H04L43/0888Throughput
    • 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/193Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • 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/2408Traffic characterised by specific attributes, e.g. priority or QoS for supporting different services, e.g. a differentiated services [DiffServ] type of service
    • 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/40Support for services or applications
    • 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/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • 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
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • 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/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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
    • 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/104Peer-to-peer [P2P] networks
    • H04L67/1074Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H04L67/1078Resource delivery mechanisms
    • H04L67/108Resource delivery mechanisms characterised by resources being split in blocks or fragments
    • 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]
    • 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/24Negotiation of communication capabilities
    • 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
    • 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/51Discovery or management thereof, e.g. service location protocol [SLP] or web services

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)
  • Information Transfer Between Computers (AREA)

Abstract

클라이언트에서 서비스를 제공하기 위한 다중 연결 방법은, 서비스를 제공하기 위한 적어도 하나의 애플리케이션을 실행하는 단계, 다중 연결 개수 및 서브세그먼트 크기에 대한 정보를 포함하는 다중 연결 이력을 참조하는 단계, 참조된 다중 연결 이력에 기초하여 다중 연결 개수 및 서브세그먼트 크기를 결정하는 단계 및 결정된 다중 연결 개수 및 결정된 서브세그먼트 크기에 따라 다중 연결을 요청하는 단계를 포함한다.

Description

데이터 전송률 향상을 위한 다중 연결 제어 방법 및 장치 {METHOD AND APPARATUS FOR CONTROLLING MULTI CONNECTION IMPROVING DATA TRANSFER RATE}
본 발명은 다중 연결을 이용하여 데이터 전송율을 향상시키는 방법 및 그 장치에 대한 것으로, 보다 상세하게는, 클라이언트 기반의 다중 연결 제어 테이블을 이용하여 최대 전송율을 얻기 위한 최적의 다중 연결 개수 및 각각의 다중 연결을 통해 전송할 서브세그먼트의 크기를 결정하는 방법 및 장치에 관한 것이다.
서버와 클라이언트 사이의 통신 연결 시 데이터 전송율 향상을 위해 다중 연결 기술이 사용된다. 다중 연결 기술은 네트워크 상황에 적합한 다중 연결 개수 및 각각의 다중 연결을 통해 전송할 서브세그먼트의 크기를 결정하는 것이 중요하다.
서버 기반의 다중 연결 제어 방법은 서버에서 네트워크 상황을 판단하여 다중 연결 개수 및 서브세그먼트 크기를 결정하는 방법으로, 가용 대역폭 예측을 위해 서버에서 클라이언트로 프로브(probe) 신호를 전송하고 이를 이용해 네트워크 상태 지표를 도출한다. 그러나, 이와 같은 방법은 반드시 서버가 연동된 상태에서만 클라이언트에서 다중 연결 개수의 판단이 가능하며 부가적인 트래픽을 유발한다.
최대 전송율을 얻기 위한 최적 다중 연결 개수를 결정하는 방법은 순차적으로 연결 개수를 증가시키면서 전송율을 모니터링하여 최적 다중 연결 개수를 결정하나, 최적 다중 연결 개수를 결정하기 위한 초기 시간이 많이 필요하다.
본 발명은 전술한 종래 기술의 문제점을 해결하며, 클라이언트 기반으로 서버연동 없이도 다중 연결을 제어하고 최적의 다중 연결 개수를 찾아, 사용자에게 보다 빠른 속도로 서비스를 제공하는 것을 그 목적으로 한다. 또는, 클라이언트로부터 전송된 다중 연결 이력 정보를 서버에서 관리함으로써 네트워크 환경이 변경된 상황에서 클라이언트가 보다 빨리 다중 연결 설정을 결정할 수 있도록 하는 것을 목적으로 한다.
상기 목적을 달성하기 위한 본 발명의 대표적인 구성은 다음과 같다.
상기 기술적 과제를 해결하기 위한 본 발명의 일 실시예에 따른 클라이언트에서 서비스를 제공하기 위한 다중 연결 방법은, 서비스를 제공하기 위한 적어도 하나의 애플리케이션을 실행하는 단계, 다중 연결 개수 및 서브세그먼트 크기에 대한 정보를 포함하는 다중 연결 이력을 참조하는 단계, 참조된 다중 연결 이력에 기초하여 다중 연결 개수 및 서브세그먼트 크기를 결정하는 단계 및 결정된 다중 연결 개수 및 결정된 서브세그먼트 크기에 따라 다중 연결을 요청하는 단계를 포함한다.
본 발명의 또 다른 실시예에 따르면, 적어도 하나의 애플리케이션에서 제공하는 서비스의 서비스 타입을 판단하는 단계를 더 포함하고, 다중 연결 개수 및 서브세그먼트 크기는 판단된 서비스 타입에 기초하여 결정된다.
본 발명의 또 다른 실시예에 따르면, 결정된 다중 연결 개수 및 결정된 서브세그먼트 크기는 세그먼트 크기에 기초하여 재결정된다.
본 발명의 또 다른 실시예에 따르면, 적어도 하나의 애플리케이션에 표시되는 웹 페이지에 포함된 적어도 하나의 링크의 개수를 판단하는 단계를 더 포함하고, 다중 연결 개수를 결정하는 단계는, 적어도 하나의 링크 각각에서 제공하는 서비스의 타입 및 적어도 하나의 링크 각각에서 제공하는 서비스를 위한 데이터 사이즈 중 적어도 하나에 기초하여, 적어도 하나의 링크 각각에 대응하는 다중 연결 개수를 결정한다.
본 발명의 또 다른 실시예에 따르면, 제공할 서비스가 복수 개인 경우, 다중 연결 개수를 결정하는 단계는, 복수 개의 제공할 서비스 각각에 대해 판단된 서비스 타입에 따라 복수 개의 서비스 각각에 요청될 다중 연결 개수를 결정한다.
본 발명의 또 다른 실시예에 따르면, 다중 연결 개수를 결정하는 단계는, 다중 연결 개수 Ni 로 연결된 데이터 전송율 T(Ni)를 계산하는 단계, 다중 연결 개수를 Ni+α 로 증가시키고, 증가된 다중 연결 개수 Ni+α로 연결된 데이터 전송율 T(Ni+α)를 계산하는 단계, T(Ni)와 T(Ni+α)를 비교하는 단계를 더 포함하고, 비교 결과, T(Ni+α)≤T(Ni)이면 다중 연결 개수 No=Ni로 결정하고, 비교 결과 T(Ni+α)>T(Ni)이면 다중 연결 개수 No=Ni+N으로 결정하는 단계를 더 포함하고, N은 다중 연결 개수가 Ni+α일 때의 평균 단일 수신율 Tas(Ni+α)과 다중 연결 개수가 Ni일 때의 평균 단일 수신율 Tas(Ni)의 증가 비율,
Figure 112015025991769-pat00001
에 기초하여 결정된다.
본 발명의 또 다른 실시예에 따르면, 다중 연결 개수는 다중 전송 모드에 기초하여 결정된다.
본 발명의 또 다른 실시예에 따르면, 다중 전송 모드는 초기 모드(Initial Mode), 최적 모드(Optimal Mode), 정체 모드(Congestion Mode) 또는 갱신 모드(Update Mode) 중 적어도 하나를 포함한다.
본 발명의 또 다른 실시예에 따르면, 다중 연결 개수는 클라이언트에 수신되는 i번째 패킷의 도달 시간차 dPATi 에 기초하여 결정되며,
Figure 112015025991769-pat00002
이고 dPATi는 i번째 패킷이 수신된 시간이다.
본 발명의 또 다른 실시예에 따르면, 다중 연결 개수를 결정하는 단계는, dPATi를 수집하는 단계 및 수집된 dPATi를 이용하여 제 1 임계값 T1 및 제 2 임계값 T2을 생성하는 단계, T1 및 T2을 갱신하는 단계를 더 포함하고, 현재 패킷의 도달 시간차가 T1 보다 작으면 다중 연결 개수를 증가시키고, 현재 패킷의 도달 시간차가 T2 보다 크면 다중 연결 개수를 감소시킨다.
본 발명의 또 다른 실시예에 따르면, T1은 다중 연결 개수가 증가되는 상태에서 수집한 dPATi 샘플 ω1 중 T1보다 큰 dPATi를 갖는 샘플의 비율과, 다중 연결 개수가 유지되는 상태에서 수집한 dPATi 샘플 ω2 중 T1보다 작은 dPATi을 갖는 샘플의 비율의 베이즈 에러율(Bayes error rate)이 최소가 되도록 하는 패킷 도달 시간차이고, T2는 ω2중 T2보다 큰 dPATi을 갖는 샘플의 비율과, 다중 연결 개수가 감소되는 상태에서 수집한 dPATi 샘플 ω3중 T2보다 작은 dPATi을 갖는 샘플의 비율의 베이즈 에러율이 최소가 되도록 하는 패킷 도달 시간차이다.
본 발명의 또 다른 실시예에 따르면,
Figure 112015025991769-pat00003
이고, 이 때
Figure 112015025991769-pat00004
,
Figure 112015025991769-pat00005
,
Figure 112015025991769-pat00006
,
Figure 112015025991769-pat00007
이고,
Figure 112015025991769-pat00008
이고, 이 때
Figure 112015025991769-pat00009
,
Figure 112015025991769-pat00010
,
Figure 112015025991769-pat00011
,
Figure 112015025991769-pat00012
이고,
Figure 112015025991769-pat00013
,
Figure 112015025991769-pat00014
,
Figure 112015025991769-pat00015
이다.
상기 기술적 과제를 해결하기 위한 본 발명의 일 실시예에 따른 클라이언트에서 서비스를 제공하기 위한 다중 연결 방법은, 적어도 하나의 클라이언트로부터 다중 연결 이력을 수신하는 단계, 수신된 다중 연결 이력을 분류하는 단계, 분류된 다중 연결 이력에 기초하여 대표 다중 연결 설정을 결정하는 단계, 결정된 대표 다중 연결 설정을 저장하는 단계, 대표 다중 연결 설정의 전송 요청을 수신하는 단계 및 전송 요청이 수신된 대표 다중 연결 설정을 전송하는 단계를 포함한다.
상기 기술적 과제를 해결하기 위한 본 발명의 일 실시예에 따른 서비스를 제공하기 위해 다중 연결하는 클라이언트 장치는 서비스를 제공하기 위한 적어도 하나의 애플리케이션을 실행하는 애플리케이션 실행부, 다중 연결 개수 및 서브세그먼트 크기에 대한 정보를 포함하는 다중 연결 이력이 저장된 저장부, 상기 저장된 다중 연결 이력을 참조하고, 참조된 다중 연결 이력에 기초하여 다중 연결 개수 및 서브세그먼트 크기를 결정하는 결정부 및 결정된 다중 연결 개수 및 결정된 서브세그먼트 크기에 따라 다중 연결 요청을 전송하는 전송부를 포함한다.
본 발명의 또 다른 실시예에 따르면, 결정부는 적어도 하나의 애플리케이션에서 제공하는 서비스의 서비스 타입을 판단하고, 판단된 서비스 타입에 기초하여 다중 연결 개수 및 서브세그먼트 크기를 결정한다.
본 발명의 또 다른 실시예에 따르면, 결정부는 세그먼트 크기에 기초하여 다중 연결 개수 및 서브세그먼트 크기를 재결정한다.
본 발명의 또 다른 실시예에 따르면, 결정부는 적어도 하나의 애플리케이션에 표시되는 웹 페이지에 포함된 적어도 하나의 링크의 개수를 판단하고, 적어도 하나의 링크 각각에서 제공하는 서비스의 타입 및 적어도 하나의 링크 각각에서 제공하는 서비스를 위한 데이터 사이즈 중 적어도 하나에 기초하여, 적어도 하나의 링크 각각에 대응하는 다중 연결 개수를 결정한다.
본 발명의 또 다른 실시예에 따르면, 제공할 서비스가 복수 개인 경우 결정부는, 복수 개의 제공할 서비스 각각에 대해 판단된 서비스 타입에 따라 복수 개의 서비스 각각에 요청될 다중 연결 개수를 결정한다.
본 발명의 또 다른 실시예에 따르면, 결정부는 다중 연결 개수 Ni 로 연결된 데이터 전송율 T(Ni) 및 증가된 다중 연결 개수 Ni+α로 연결된 데이터 전송율 T(Ni+α)를 계산하고 T(Ni)와 T(Ni+α)를 비교하여, 비교 결과 T(Ni+α)≤T(Ni)이면 다중 연결 개수 No=Ni로 결정하고, 비교 결과 T(Ni+α)>T(Ni)이면 다중 연결 개수 No=Ni+N으로 결정하며, N은 다중 연결 개수가 Ni+α일 때의 평균 단일 수신율 Tas(Ni+α)과 다중 연결 개수가 Ni일 때의 평균 단일 수신율 Tas(Ni)의 증가 비율,
Figure 112015025991769-pat00016
에 기초하여 결정한다.
본 발명의 또 다른 실시예에 따르면, 다중 연결 개수는 다중 전송 모드에 기초하여 결정된다.
본 발명의 또 다른 실시예에 따르면, 다중 전송 모드는 초기 모드(Initial Mode), 최적 모드(Optimal Mode), 정체 모드(Congestion Mode) 또는 갱신 모드(Update Mode) 중 적어도 하나를 포함한다.
본 발명의 또 다른 실시예에 따르면, 다중 연결 개수는 클라이언트에 수신되는 i번째 패킷의 도달 시간차 dPATi 에 기초하여 결정되며,
Figure 112015025991769-pat00017
이고 dPATi는 i번째 패킷이 클라이언트에 수신된 시간이다.
본 발명의 또 다른 실시예에 따르면, 결정부는 dPATi를 수집하고, 수집된 dPATi를 이용하여 제 1 임계값 T1 및 제 2 임계값 T2을 생성하고, T1 및 T2을 갱신하고, 현재 패킷의 도달 시간차가 T1 보다 작으면 다중 연결 개수를 증가시키고, 현재 패킷의 도달 시간차가 T2 보다 크면 다중 연결 개수를 감소시킨다.
본 발명의 또 다른 실시예에 따르면, T1은 다중 연결 개수가 증가되는 상태에서 수집한 dPATi 샘플 ω1 중 T1보다 큰 dPATi를 갖는 샘플의 비율과, 다중 연결 개수가 유지되는 상태에서 수집한 dPATi 샘플 ω2 중 T1보다 작은 dPATi을 갖는 샘플의 비율의 베이즈 에러율(Bayes error rate)이 최소가 되도록 하는 패킷 도달 시간차이고, T2는 ω2중 T2보다 큰 dPATi을 갖는 샘플의 비율과, 다중 연결 개수가 감소되는 상태에서 수집한 dPATi 샘플 ω3중 T2보다 작은 dPATi을 갖는 샘플의 비율의 베이즈 에러율이 최소가 되도록 하는 패킷 도달 시간차이다.
본 발명의 또 다른 실시예에 따르면,
Figure 112015025991769-pat00018
이고, 이 때
Figure 112015025991769-pat00019
,
Figure 112015025991769-pat00020
,
Figure 112015025991769-pat00021
,
Figure 112015025991769-pat00022
이고,
Figure 112015025991769-pat00023
이고, 이 때
Figure 112015025991769-pat00024
,
Figure 112015025991769-pat00025
,
Figure 112015025991769-pat00026
,
Figure 112015025991769-pat00027
이고,
Figure 112015025991769-pat00028
,
Figure 112015025991769-pat00029
,
Figure 112015025991769-pat00030
이다.
상기 기술적 과제를 해결하기 위한 본 발명의 일 실시예에 따른 클라이언트에 서비스를 제공하기 위해 다중 연결하는 서버는, 적어도 하나의 클라이언트로부터 다중 연결 이력을수신하는 수신부, 수신된 다중 연결 이력을 분류하고 분류된 다중 연결 이력에 기초하여 대표 다중 연결 설정을결정하는 제어부, 결정된 대표 다중 연결 설정을 저장하는 저장부 및 수신부에 대표 다중 연결 설정의 전송 요청이 수신되면, 대표 다중 연결 설정을 전송하는 전송부를 포함한다.
한편, 본 발명의 일 실시예에 따르면, 전술한 방법을 실행하기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체를 제공한다.
이 외에도, 본 발명을 구현하기 위한 다른 방법, 다른 시스템 및 상기 방법을 실행하기 위한 컴퓨터 프로그램을 기록하는 컴퓨터 판독 가능한 기록 매체가 더 제공된다.
본 발명에 의하면, 클라이언트기반으로 서버연동 없이도 다중 연결을 제어하고 최적의 다중 연결 개수를 찾아, 사용자에게 보다 빠른 속도로 서비스를 제공할 수 있다.
도 1 은 서버-클라이언트 간 데이터 전송을 위한 단일 연결과 다중 연결을 나타내는 도면이다.
도 2 는 다중 연결 개수와 데이터 전송율의 관계에 대한 그래프를 나타낸 도면이다.
도 3 은 서브세그먼트의 크기와 데이터 전송율의 관계에 대한 그래프를 나타낸 도면이다.
도 4 는 클라이언트에서 서비스를 제공하기 위해 서버에 HTTP 요청과 응답을 송수신하는 과정을 나타낸 도면이다.
도 5 은 본 발명의 일 실시예에 따라 최적의 다중 연결 개수를 결정한 경우, 다중 연결 제어 횟수와 전송율의 관계에 대한 그래프를 나타낸 도면이다.
도 6 은 본 발명의 일 실시예에 따른 클라이언트-서버 시스템의 전체 개요도이다.
도 7 은 본 발명의 일 실시예에 따른 서비스 타입에 기초하여 다중 연결 개수를 결정하는 방법의 순서도이다.
도 8 은 본 발명의 일 실시예에 따른 서비스의 타입에 따라 최적 다중 연결 개수 및 최적 세그먼트크기를 결정하는 다중 연결 이력이 저장된, 다중 연결 테이블에 대한 예시이다.
도 9 는 본 발명의 또 다른 실시예에 따른 웹 페이지에 포함된 복수 개의 구성 요소에 따라 다중 연결 개수를 결정하는 방법을 설명하기 위한 도면이다.
도 10 은 본 발명의 또 다른 실시예에 따른 클라이언트가 다중 서버에 접속하는 경우 다중 연결 이력을 이용하여 다중 연결 개수를 결정하는 방법을 설명하기 위한 도면이다.
도 11 은 본 발명의 또 다른 실시예에 따른 평균 단일 수신율을 이용하여 다중 연결 개수를 결정한 경우, 다중 연결 개수와 전송율의 관계를 나타낸 도면이다.
도 12 는 본 발명의 또 다른 실시예에 따른 다중 연결 개수 결정을 위한 다중 연결 모드 상태도 및 각 모드에 대한 정의 등을 나타낸 것이다.
도 13 은 본 발명의 또 다른 실시예에 따른 다중 연결 모드에 따라 다중 연결 개수를 결정하는 경우, 다중 연결 제어 횟수에 따른 전송율의 관계 및 다중 연결 개수의 관계를 나타낸 도면이다.
도 14 는 본 발명의 또 다른 실시예에 따른 다중 연결 모드에 따라 다중 연결 개수를 결정하는 경우, 다중 연결 제어 횟수와 전송율의 관계를 나타낸 도면이다.
도 15 는 본 발명의 또 다른 실시예에 따른 패킷 도달 시간 차에 기초하여 다중 연결 개수를 결정하는 방법의 순서도이다.
도 16 은 본 발명의 일 실시예에 따른 패킷 도달 시간 차에 기초하여 다중 연결 개수를 결정하는 방법에서 최적의 임계값을 결정하기 위한 확률 분포 모델링 결과를 나타낸 도면이다.
도 17 은 본 발명의 일 실시예에 따른 패킷 도달 시간 차에 기초하여 다중 연결 개수를 결정하는 방법에서 dTime과 베이즈 에러의 관계를 나타낸 도면이다.
도 18 은 본 발명의 실시예에 따른 클라이언트가 이동성을 가지는 경우의 동작을 설명하기 위한 도면이다.
도 19 는 본 발명의 또 다른 일 실시예에 따른 클라이언트가 이동성을 가지는 경우 다중 연결을 제어하는 시스템을 나타낸 도면이다.
도 20 은 본 발명의 또 다른 일 실시에에 따른 클라이언트가 이동성을 가지는 경우 다중 연결을 제어하는 시스템의 동작을 나타낸 도면이다.
도 21 은 도 19 의 시스템에서, 클라이언트가 다른 지역으로 이동한 경우의 동작을 설명하기 위한 도면이다.
도 22 는 본 발명의 일 실시예에 따라 다중 연결을 제어하는 클라이언트 (100)의 세부 구성도이다.
후술하는 본 발명에 대한 상세한 설명은, 본 발명이 실시될 수 있는 특정 실시예를 예시로서 도시하는 첨부 도면을 참조한다. 이러한 실시예는 당업자가 본 발명을 실시할 수 있기에 충분하도록 상세히 설명된다. 본 발명의 다양한 실시예는 서로 다르지만 상호 배타적일 필요는 없음이 이해되어야 한다.
예를 들어, 본 명세서에 기재되어 있는 특정 형상, 구조 및 특성은 본 발명의 정신과 범위를 벗어나지 않으면서 일 실시예로부터 다른 실시예로 변경되어 구현될 수 있다. 또한, 각각의 실시예 내의 개별 구성요소의 위치 또는 배치도 본 발명의 정신과 범위를 벗어나지 않으면서 변경될 수 있음이 이해되어야 한다. 따라서, 후술하는 상세한 설명은 한정적인 의미로서 행하여지는 것이 아니며, 본 발명의 범위는 특허청구범위의 청구항들이 청구하는 범위 및 그와 균등한 모든 범위를 포괄하는 것으로 받아들여져야 한다.
도면에서 유사한 참조부호는 여러 측면에 걸쳐서 동일하거나 유사한 구성요소를 나타낸다. 그리고 도면에서 본 발명을 명확하게 설명하기 위해서 설명과 관계없는 부분은 생략하였으며, 명세서 전체를 통하여 유사한 부분에 대해서는 유사한 도면 부호를 붙였다.
이하에서는, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자가 본 발명을 용이하게 실시할 수 있도록 하기 위하여, 본 발명의 여러 실시예에 관하여 첨부된 도면을 참조하여 상세히 설명하기로 한다. 그러나 본 발명은 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시예에 한정되지 않는다.
명세서 전체에서, 어떤 부분이 다른 부분과 "연결"되어 있다고 할 때, 이는 "직접적으로 연결"되어 있는 경우뿐 아니라, 그 중간에 다른 소자를 사이에 두고 "전기적으로 연결"되어 있는 경우도 포함한다. 또한 어떤 부분이 어떤 구성요소를 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있는 것을 의미한다.
이하 첨부된 도면을 참고하여 본 발명을 상세히 설명하기로 한다.
도 1 은 서버-클라이언트 간 데이터 전송을 위한 단일 연결과 다중 연결을 나타내는 도면이다.
도 1(a) 는 서버-클라이언트 간 단일 연결을 통해 콘텐츠를 요청하는 동작에 대한 블록도이다.
사용자의 서비스 제공 요청이 입력되면, 클라이언트(100)는 서버(500)로 서비스 제공을 위한 콘텐츠를 단인 연결을 통해 전송할 것을 요청하고 서버는 단일 연결을 통해 콘텐츠 세그먼트(segment)를 클라이언트로 전송한다. 콘텐츠 세그먼트는 전송할 콘텐츠의 데이터를 분할한 것으로 데이터의 전송 및 저장을 위한 단위이다.
도 1(b) 는 서버-클라이언트 간 다중 연결을 통해 콘텐츠를 요청하는 동작에 대한 블록도이다.
도 1(b) 에서, 클라이언트(100)가 2 개의 다중 연결을 통해 콘텐츠를 전송할 것을 서버에(500) 요청하면, 서버(500)는 클라이언트(100)와 2 개의 다중 연결을 설정하고, 두개의 서브세그먼트 S1 과 S2 를 각각의 연결을 통해 독립적으로 전송한다. 서브세그먼트 S1 과 S2 가 수신되면, 클라이언트는 수신된 서브세그먼트 S1 과 S2 를 병합하여 세그먼트를 복원한다.
큰 지연이나 높은 패킷 손실이 발생하는 네트워크 상황에서는 단일 연결의 효용(utilization)이 감소하므로, 세그먼트를 분할한 서브세그먼트를 다중 연결을 통해 전송하면 단일 연결에 비해 전송율이 향상될 수 있다.
도 2 는 다중 연결 개수와 데이터 전송율의 관계에 대한 그래프를 나타낸 도면이다.
앞서 언급한 바와 같이, 단일 연결의 효용(utilization) 낮은 경우, 다중 연결을 통해 데이터를 전송하는 경우 전송율이 향상될 수 있다. 그러나, 전송 장치와 수신 장치를 연결하는 네트워크에서 이용할 수 있는 자원은 유한하며 서로 트레이드 오프(trade-off)관계를 가지므로, 많은 개수의 다중 연결이 반드시 높은 전송율을 보장하는 것은 아니다.
도 2 를 살펴보면, 다중 연결 개수가 6 이하인 경우는 단일 연결로부터 다중 연결 개수가 증가함에 따라 전송율이 증가하는 관계에 있다. 그러나 다중 연결 개수가 작을수록 전송율 증가폭이 크지만 다중 연결 개수가 증가함에 따라 전송율 증가폭이 줄어드는 양상을 보인다. 또한, 다중 연결 개수가 7 이상인 경우는 오히려 전송율이 감소하는 것을 확인할 수 있다.
전송 장치와 수신 장치 사이의 다중 연결을 위해서는, 세그먼트를 서브세그먼트로 분할하여 전송해야 하는데, 각 서브세그먼트를 구성하는 데이터 패킷들을 위한 헤더, 테일 등의 데이터가 부가되어야 하며 이와 같은 데이터는 다중 연결 개수인 N 이 증가할수록 그 양이 늘어나기 때문이다.
그리고, 다중 연결을 하게 되면 각각의 다중 연결에 대해 링크 프로토콜을 설정해야 하며 데이터 분할 및 재조합을 위한 별도의 처리 과정을 거쳐야 하는 등, 시스템 복잡도가 증가하여 전체적인 시스템 성능에 영향을 미칠 수 있다.
또한, 앞서 언급한 바와 같이 제한된 네트워크 자원을 다중 연결을 위해 배분하여 사용하기 때문에 많은 개수의 다중 연결이 반드시 높은 전송율을 보장하는 것은 아니다.
예를 들어, 다중 연결을 위해 주파수 대역을 분할하여 사용하는 경우, 전송하고자 하는 데이터 주파수 대역폭의 두배의 주파수 대역을 필요로 하는데 다중 연결 개수가 많은 경우라면 서브세그먼트의 전송을 위한 충분한 주파수 대역을 확보하지 못할 수 있다. 또는, 다중 연결을 위해 시간을 분할하여 사용하는 경우 역시 마찬가지로, 다중 연결 개수가 많은 경우 서브세그먼트의 전송을 위한 충분한 시간을 보장받지 못하는 경우가 발생할 수 있다.
도 2 와 같은 경우, 최대 전송율을 얻기위한 최적의 다중 연결 개수는 6 개가 되며 이와 같은 최적의 다중 연결 개수를 최대한 빨리 알 수 있다면 보다 높은 전송율을 얻을 수 있다.
도 3 은 서브세그먼트의 크기와 데이터 전송율의 관계에 대한 그래프를 나타낸 도면이다.
전송 장치와 수신 장치가 같은 개수로 다중 연결 된 경우, 네트워크 환경이 이상적이라면 서브세그먼트의 크기가 클수록 데이터 전송율은 높아질 것이다. 그러나, 실제 네트워크 환경에서는 외부 요인에 의한 잡음, 간섭 등의 요인에 의해 에러가 발생할 뿐 아니라 통신 채널 상태에 따라 페이딩(fading)이 발생할 수 있고 클라이언트 단말이 새도우존(shadow zone)에 진입하는 경우 등에는 통신환경이 급격히 나빠지게 된다.
이러한 상황에서는 데이터 전송 단위인 서브세그먼트의 크기가 큰 경우 오히려 하나의 패킷 또는 서브세그먼트 내에서 에러가 발생할 확률이 높아지게 되어, 에러정정부호화(error correcting code)등을 이용한 데이터 복원 효율이 낮아지게 된다.
또한, 서브세그먼트의 크기가 작아지면 동일한 크기의 세그먼트를 전송하기 위해 더 많은 개수의 서브세그먼트로 분할하고, 전송해야 하므로 서브세그먼트 구성을 위한 부가데이터가 더 많이 필요하고 서브세그먼트 전송을 하기 위한 시간지연도 발생할 수 있다.
도 3 에서는, 서브세그먼트의 크기가 0.2kbyte부터 0.2kbyte씩 증가될 때, 각 서브세그먼트의 크기에 따른 전송율이 나타나 있다. 앞서 설명한 바와 같이, 서브세그먼트의 크기가 0.6이 될 때 까지는 서브세그먼트의 크기가 증가함에 따라 데이터 전송율이 증가하지만, 그 증가율은 점점 작아지며 서브세그먼트의 크기가 0.8 이상인 경우는 오히려 데이터 전송율이 감소하는 양상을 보이는 것을 확인할 수 있다.
도 4 는 클라이언트에서 서비스를 제공하기 위해 서버에 HTTP 요청과 응답을 송수신하는 과정을 나타낸 도면이다.
도 2 에 나타난 다중 연결 개수와 전송율의 관계 및 도 3 에 나타난 서브세그먼트의 크기와 전송율의 관계를 고려할 때, 보다 높은 데이터 전송율을 얻기 위해 최적의 다중 연결 개수 및 최적의 서브세그먼트 크기를 결정하는 것이 필요하다.
도 4 는 클라이언트와 서버가 인터넷 망을 통해 연결된 경우, 클라이언트가 서버에 HTTP(Hyper-Text Transfer Protocol)을 이용하여 연결 및 데이터 전송을 요청하고 서버로부터 그에 대한 응답을 수신하는 과정을 나타낸 것이다.
서버와 클라이언트가 단일 연결된 경우 클라이언트는 서버로 하나의 HTTP Get Request를 전송하고 서버로부터 하나의 HTTP Get Response를 수신한다. 반면, 서버와 클라이언트가 다중 연결된 경우, 클라이언트는 서버로 다중 연결 개수 N 에 해당하는 HTTP Get Request를 전송하고 서버로부터 다중 연결 개수 N 에 해당하는 HTTP Get Response를 수신한다.
도 5 은 본 발명의 일 실시예에 따라 최적의 다중 연결 개수를 결정한 경우, 다중 연결 제어 횟수와 전송율의 관계에 대한 그래프를 나타낸 도면이다.
도 2 에서 확인한 바와 같이 연결 개수가 적은 측정 초기에는 연결 개수가 증가함에 따라 전송율이 증가하나 전송율 증가폭은 점점 감소하여, 연결 개수가 특정 수준 이상이 되면 전송율 증가는 포화(saturation)되어 더 이상 증가하지 않거나 오히려 감소하는 양상을 띄게 된다.
종래 기술에서는 서버와 클라이언트간 다중 연결이 필요한 경우 가장 높은 전송율을 얻을 수 있는 최적 다중 연결 개수를 결정하기 위해, 단일 연결부터 시작하여 연결 개수를 하나씩 증가시키면서 전송율을 측정한다. 예를 들어, 연결 개수가 N 일 때의 전송율 T(N)과 연결 개수를 1 만큼 증가시켜 연결 개수가 N+1일 때의 전송율 T(N+1)을 비교하여 T(N+1)이 T(N)보다 급격히 작아진다면 그때의 N을 최적 다중 연결 개수 No로 결정하는 것이다.
이 때, 종래 기술과 같이 단인 연결 개수를 하나씩 증가시키며 최적의 전송율로부터 최적 다중 연결 개수 No를 찾는 경우라면 No-1번의 다중 연결 제어 과정을 거쳐야 하므로 도 5(a)와 같이 최적 다중 연결 개수 9를 찾기 위해 8회의 다중 연결 제어 과정을 거쳐야 한다. 만일 최적 다중 연결 개수 No가 크다면 최적 다중 연결 제어 개수 No를 결정하기 위한 다중 연결 제어 횟수 역시 커지므로 No를 결정하기 위한 초기 시간은 더 길어지게 된다.
도 5(b)는 본 발명의 실시예에 따라 최적의 다중 연결 개수를 찾는 경우 다중 연결 제어 횟수와 전송율의 관계를 실험적으로 나타낸 것으로, 도5(a)보다 훨씬 적은 3회의 다중 연결 제어 만에 최적의 다중 연결 개수를 찾고 최대 전송율을 가진다.
이하에서는 본 발명의 실시예에 따른 최적 다중 연결 개수 및 서브세그먼트 크기를 결정하는 발명에 대해 구체적으로 설명하기로 한다.
도 6 은 본 발명의 일 실시예에 따른 클라이언트-서버 시스템의 전체 개요도이다.
도 6 에 도시된 바와 같이, 본 발명의 일 실시예에 따른 클라이언트-서버 시스템은 클라이언트(100), 서버(500) 및 네트워크(600)를 포함한다.
클라이언트(100)는, 휴대폰, 스마트폰, PDA(Personal Digital Assistant), PDA폰, 노트북, 스마트 TV 등과 같이 애플리케이션을 실행할 수 있는 장치를 의미하며, 네트워크를 통하여 서버(500)에 연결되는 모든 종류의 장치를 포함할 수 있다. 대표적인 클라이언트(100)로 스마트폰을 들 수 있으며, 스마트폰은 이동 전화 기능 외에도 여러 가지 기능이 집적되어 있어 PDA 기능 또는 소형 PC의 기능을 수행하기 적합하다.
서버(500)는 서버에서 제공하는 서비스의 타입에 따라 파일 서버(501), 스트리밍 서버(502), 웹서버(503) 등을 포함할 수 있으나 이에 한정되는 것은 아니다.
네트워크는 클라이언트(100)와 서버(500)를 연결하는 역할을 한다. 네트워크(600)는 전용선, LAN, VAN, 인트라넷, 사설 전화망, 공중 전화망, PSTN 망 및 이들의 상호 조합을 포함하며, 도 6 에 도시된 각 네트워크 구성 주체가 서로 원활하게 통신을 할 수 있도록 하는 포괄적인 의미의 데이터 통신망으로, 유선 인터넷, 무선 인터넷 및 모바일 무선 통신망을 포함한다.
사용자는 제공받고자 하는 서비스의 타입에 따라 서로 다른 종류의 애플리케이션을 이용하는데, 파일 서버(501)에 있는 파일을 클라이언트로 다운로드하고자 할 때는 다운로드 애플리케이션(301)을, 스트리밍 서버(502)에 있는 미디어 파일을 스트리밍으로 이용하고자 할 때는 스트리밍 애플리케이션(302)를 이용할 수 있다. 또는 인터넷 검색 등을 하고자 할 때에는 웹브라우저 애플리케이션(303)을 이용하여 웹서버(503)에 있는 컨텐츠를 웹브라우저 화면을 통해 확인할 수 있다.
이 때, 도 6 에서는 각 서비스의 종류에 따라 애플리케이션이 각각 다른 것으로 도시되어 있으나, 구현 방법에 따라 사용자는 하나의 애플리케이션에서 여러 종류의 서비스를 선택할 할 수 있으며 서버 역시 하나의 서버에서 여러 종류의 서비스를 제공할 수 있다.
이와 같이 사용자는 클라이언트에 설치된 애플리케이션을 통해 제공받고자 하는 서비스를 선택할 수 있으며, 사용자의 서비스 요청이 있는 경우 애플리케이션은 가속모듈(200)로 서비스 요청을 전달한다. 애플리케이션으로부터 서비스 요청이 전달되면, 가속 모듈(200)은 요청된 서비스의 타입을 분석하여 분석된 서비스타입에 적합한 다중 연결 개수를 결정하고 서버에 다중 연결을 요청한다.
도 7 은 본 발명의 일 실시예에 따른 서비스 타입에 기초하여 다중 연결 개수를 결정하는 방법의 순서도이다.
애플리케이션(300)을 통해 사용자의 서비스 제공 요청이 입력되면, 가속 모듈(200)는 서비스 제공 요청에 포함된 서비스 URL로 HTTP Get Request를 전송(S710)한다. 가속 모듈(200)는 HTTP Get Request가 요청된 URL의 서비스 타입을 판별(S720)하고, 판별된 서비스 타입에 기초한 최적의 다중 연결 개수 No 및 최적 서브세그먼트 크기 So를 결정(S730)한다.
클라이언트에서 제공해야 하는 서비스 종류와 타입에 따라 전송해야 하는 데이터의 크기가 달라지므로 서비스 타입에 따라 다중 연결 개수 및 서브세그먼트 크기를 결정할 필요가 있기 때문이다.
예를 들어, 웹브라우저를 통한 인터넷 검색 등의 서비스를 위해서는 대용량의 데이터를 전송할 필요가 없는 경우가 많으므로 다중 연결 개수를 적게 결정하고, 파일을 다운로드 하는 경우에는 다중 연결 개수를 많이 결정할 수 있다. 또한, 스트리밍 서비스의 경우 대용량의 데이터를 지속적으로 전송할 필요가 있고 세그먼트 조합이 실시간으로 이루어져야 하므로 스트리밍 서비스에 적합한 최적의 다중 연결 개수를 결정하는 경우 데이터 전송율을 높이면서 원활한 스트리밍 서비스를 제공하는 최적의 다중 연결 개수를 결정할 수 있는 것이다.
최적 다중 연결 개수 No가 결정되면, 가속 엔진은 서버로 결정된 최적 다중 연결 개수 No로 다중 연결하고, So의 크기를 갖는 No개의 서브세그먼트를 전송할 것을 요청(S740)한다. 이후 다중 연결 개수 No로 서버와 연결되면, 요청에 대한 응답으로 서버에서 전송하는 No의 크기를 갖는 No개의 서브세그먼트를 수신(S750)하고, 수신된 No개의 서브세그먼트를 조합하여 세그먼트를 구성하여 애플리케이션으로 구성된 세그먼트를 전달(S760)한다.
애플리케이션은 수신된 세그먼트를 이용하여 사용자에게 서비스를 제공한다.
이 때, 가속 모듈은 클라이언트(100) 내에 저장된 다중 연결 이력을 참조하여 다중 연결 개수 및 서브세그먼트 크기를 결정할 수 있는데, 도 8 은 본 발명의 일 실시예에 따른, 서비스 타입에 따라 최적 다중 연결 개수 및 최적 서브세그먼트 크기를 결정하는 다중 연결 이력이 저장된, 다중 연결 테이블의 예시이다.
클라이언트에서 다중 연결 이력을 저장하고 관리함으로써, 최적 다중 연결 개수 결정을 위해 정보를 수집하거나 서버로부터 별도의 제어 데이터를 수신할 필요 없이, 클라이언트 기반으로 다중 연결 개수를 결정할 수 있다.
도 8 은 본 발명의 일 실시예에 따른 서비스의 타입에 따라 최적 다중 연결 개수 및 최적 세그먼트크기를 결정하는 다중 연결 이력이 저장된, 다중 연결 테이블을 나타낸다.
다중 연결 테이블은 도 8 에 도시된 바와 같이 각 애플리케이션에서 서비스를 요청할 도메인 또는 IP 등 서비스 주소와, 서비스의 타입, 최적 연결 개수 No, 최적 연결 개수의 전송율(최대 전송율) To 및 최적 서브세그먼트의 크기 So 등을 포함할 수 있다.
도 8 의 실시예에서는, 파일 다운로드 서비스(FD)를 제공하는 OTN 애플리케이션, 스무디 스트리밍 서비스(SS)를 제공하는 MLB 애플리케이션, HTTP 라이브 스트리밍 서비스(HLS)를 제공하는 Fitness 애플리케이션 및 웹브라우징 서비스(Web)를 제공하는 Web 애플리케이션이 있다고 가정한다.
OTN 애플리케이션의 경우 파일 다운로드 서비스를 제공하며, 해당 서비스 주소에서 파일 다운로드 서비스를 전송받기 위한 최적의 다중 연결 개수 No는 3개, 3개의 다중 연결시의 전송율 To은 8.0Mbps 이고, 최적 서브세그먼트 크기 So는 1.8kbyte이다. MLB 애플리케이션의 경우 스무드 스트리밍 서비스를 제공하며, 해당 서비스 주소에서 스무드 스트리밍 서비스를 전송받기 위한 최적의 다중 연결 개수 No는 6개, 6개의 다중 연결시의 전송율 To는 10.4Mbps이고, 최적 서브세그먼트 크기 So는 0.8kbyte이다.
Fitness 애플리케이션의 경우 HTTP 라이브 스트리밍 서비스를 제공하며, 해당 서비스 주소에서 HTTP 라이브 스트리밍 서비스를 전송받기 위한 최적의 다중 연결 개수 No는 1개, 1개의 단일 연결시의 전송율 To는 1Mbps이고, 최적 서브세그먼트 크기 So는 1kbyte이다.
마지막으로, Web 애플리케이션의 경우 웹브라우징 서비스를 제공하며, 해당 서비스 주소에서 웹브라우징 서비스를 전송받기 위한 최적의 다중 연결 개수 No는 4개, 4개의 다중 연결시의 전송율 To는 16Mbps이고, 최적 서브세그먼트 크기 So는 4kbyte이다.
예를 들어, 사용자가 MLB 애플리케이션을 통해 야구 경기를 보고자 할 경우를 가정하자. 사용자의 vod 재생 요청이 있는 경우, 종래 기술에 따르면 서비스 타입에 무관하게 하나 또는 적은 개수의 연결을 서버에 요청하고, 연결 개수를 하나씩 증가시키면서 가장 높은 전송율을 갖는 최적 다중 연결 개수 및 최적 서브세그먼트 크기를 결정한다.
그러나, 본 발명의 일 실시예에 따르면, MLB 애플리케이션을 통해 전달된 서비스 요청으로부터 서비스 주소 및 서비스 타입을 먼저 판단한다. 판단 결과, 서비스 타입이 스무드 스트리밍이므로 다중 연결 테이블을 참조하여 최적 연결 개수 No를 6으로, 최적 서브세그먼트 크기 So를 0.8kbyte로 결정한다.
또는 다중 연결 테이블에 서비스주소가 등록되지 않은 서비스 요청인 경우라면 판단된 서비스 타입에 기초하여, 다중 연결 테이블에 등록된 서비스 중 동일한 서비스 타입을 가지는 서비스의 최적 다중 연결 개수를 참조할 수 있다.
또는, 다중 연결 테이블 항목 구성에 서비스 주소가 포함되지 않은 경우라면, 서비스 타입에만 기초하여 최적 다중 연결 개수 및 최적 서브세그먼트 크기가 결정될 수 있다.
한편, 서비스 타입이나 서비스 데이터의크기 또는 네트워크설정에 따라 세그먼트의 크기는 다양하게 결정될 수 있는데, 세그먼트 크기가 일전 범위보다 크거나 작은 경우라면 다중 연결 개수 및 서브세그먼트의 크기를 적당히 조절하면 더 높은 전송율을 얻을 수 있다.
최적 다중 연결 개수가 No, 최적 서브세그먼트의 크기가 So이고, 전송해야 하는 세그먼트의 크기가 SS라 하자. 세그먼트의 크기 SS가 No×So로부터 일정 범위 이내에 있을 때에는 최적 다중 연결 개수가 No와 최적 서브세그먼트의 크기 So를 그대로 이용하여도 큰 문제가 없다.
그러나, 전송해야 하는 세그먼트의 크기가 상대적으로 큰 경우라면 최적 다중 연결 개수의 크기 No와 최적 서브세그먼트의 크기 So를 이용하는 경우 세그먼트를 전부 전송하지 못하게 된다. 또한, 전송해야 하는 세그먼트의 크기가 상대적으로 작은 경우라면 최적 다중 연결 개수의 크기 No와 최적 서브세그먼트의 크기 So를 이용하는 경우 네트워크 자원의 낭비가 될 수 있다.
따라서, 각 경우에 따라 조정된 다중 연결 개수 Nn 및 서브세그먼트의 크기 Sn을 식 1과 같이 재결정할 수 있다.
Figure 112015025991769-pat00031
(식 1)
여기서, α 및 β는 SS를 기준으로 일정 크기의 데이터 범위를 나타내기 위해 사용된 파라미터로, 고정된 값은 아니며 실시예에 따라 다양하게 결정될 수 있다.
도 9 는 본 발명의 또 다른 실시예에 따른 웹 페이지에 포함된 복수 개의 구성 요소에 따라 다중 연결 개수를 결정하는 방법을 설명하기 위한 도면이다.
도 9 의 실시예에서는 웹 페이지 구성에 여러 개의 링크가 포함되어 있는 경우, 복수의 서버에서 제공하는 서비스의 타입에 따라 다중 연결 개수를 결정한다.
웹브라우저 애플리케이션(303)의 웹 페이지구성이 도 9 (a)와 같다고 가정하자. 해당 웹 페이지는 모두 다섯 개의 링크를 포함하며, 구체적으로 두 개의 텍스트링크(Text 1 및 Text 4), 두 개의 이미지 링크(Image 2 및 Image 3) 및 한 개의 비디오 링크(Video 5)를 포함하고 있다.
도 9 (b)와 같이 각 서비스에 대해 단일 연결을 통해 웹페이지를 로딩하고 모든 컨텐츠를 서비스 한다면, 클라이언트는 웹페이지 내의 링크 개수에 해당하는 5개의 연결을 요청하고 세그먼트를 전송받게 된다. 그러나, 각 서비스에 대해서는 단일 연결에 해당하며 각각의 서비스가 서로 다른 서버에서 제공된다면, 클라이언트와 하나의 서버는 단일 연결된 상태이다.
이와 같이 복수 개의 링크에 해당하는 다중 서버에 대해 각각 단일 연결 하는 경우, 서비스를 위한 데이터 용량이 큰 비디오 링크의 컨텐츠를 수신하기 위해서는 많은 시간이 소요며 비디오 링크의 컨텐츠가 처리될 때까지 웹페이지 전체의 로딩이 지연되게 된다.
따라서, 도 9(c)와 같이 각 링크에 따라 다중 연결 개수를 결정하는 방법이 제안된다.
웹페이지에 포함된 링크 중 서버로부터 전송되는 데이터 용량이 큰 경우 더 많은 개수의 다중 연결이 필요하므로, 비디오 링크에 대해서 다른 링크보다 더 많은 개수의 다중 연결을 할당하면 비디오 링크에 해당하는 컨텐츠의 수신 속도를 빠르게 할 수 있으며 결국 웹페이지 전체의 처리 속도를 향상시키는 결과를 얻게 된다.
따라서, 웹페이지 내의 각각의 링크에 해당하는 다중 서버로부터 서비스 콘텐츠를 전송받는 경우 클라이언트가 각 다중 서버와 연결할 최적의 다중 연결 개수를 결정하는 것이 필요하다.
도 10 은 본 발명의 또 다른 실시예에 따른 클라이언트가 다중 서버에 접속하는 경우 다중 연결 이력을 이용하여 다중 연결 개수를 결정하는 방법을 설명하기 위한 도면이다.
도 9 의 실시예에서는 비디오 링크 이외의 나머지 링크들은 모두 최적 연결 개수가 1 인 경우를 가정하였으나, 클라이언트가 실제로 다중 서버에 접속하는 경우 각 링크에서 제공하는 서비스의 타입에 따라 각각의 다중 연결 개수가 결정될 수 있다.
도 10 의 실시예에서 도 10(a) 는 하나의 클라이언트(100)가 서비스의 제공을 위해 두개의 다중 서버, 서버 1(501, otn.com/sec)과 서버 2(502, MLB.com/abc)와 다중 연결되는 경우를 가정한다.
도 10(b) 의 다중 연결 테이블에는 각각의 서버에 대한 최적 다중 연결 정보가 포함되어 있다. 도 10(b) 는 도 8 의 다중 연결 테이블과 유사하게 서비스를 요청할 도메인 또는 IP 등 서비스 주소와, 서비스의 타입, 최적 연결 개수 No, 최적 연결 개수의 전송율(최대 전송율) To 및 최적 서브세그먼트의 크기 So 등을 포함하며 인코딩율이 추가로 포함되어 있다.
서버 1 과 다중 연결하기 위한 최적 다중 연결 정보는 도 10(b)의 다중 연결 테이블의 첫번째 행에 기록되어 있다. 서버 1 에서 제공하는 서비스의 타입은 파일 다운로드(FD)이고, 최적 다중 연결 개수 No는 10 개이다.
서버 2와 다중 연결하기 위한 최적 다중 연결 정보는 도 10(b)의 다중 연결 테이블의 세번째 행에 기록되어 있다. 서버 2 에서 제공하는 서비스의 타입은 스무딩 스트리밍(SS)이고, 최적 다중 연결 개수 No는 15 개 이다.
클라이언트에서 서버 1 과 서버 2 로부터 서비스를 제공받기 위해, 두 개의 서버에 다중 연결 하는 경우에, 도 10(b)와 같이 다중 연결 테이블에 최적 다중 연결 정보가 각각 존재하는 경우라면 최적 다중 연결 개수의 구성을 참조하여 다중 연결 개수를 재구성한다.
예를 들어, 클라이언트에서 사용할 수 있는 최대 다중 연결 개수가 25개라면 서버 1에 10개를 할당하고 서버 2에 15개를 할당하고, 클라이언트에서 사용할 수 있는 최대 다중 연결 개수가 15개라면, 서버 1에 6개를 할당하고 서버 2에 9개를 할당하는 등 2:3의 비율을 유지하여 할당할 수 있다.
또는, 서비스 타입에 기초하여 우선 순위를 부여할 수 있다. 파일 다운로드(FD) 서비스보다는 스트리밍(SS 또는 HLS) 서비스가 더 높은 전송율을 요구하므로 파일 다운로드 서비스를 제공하는 서버 1 보다 스무딩 스트리밍 서비스를 제공하는 서버 2에 우선 순위를 부여하여 더 많은 다중 연결 개수를 할당하는 것이다.
예를 들어, 클라이언트에서 사용할 수 있는 최대 다중 연결 개수가 15개인 경우라면, 서버 2에 12개를 할당하고 서버 1에 3개를 할당하여 서비스 콘텐츠를 전송받고, 서버 2의 서비스 콘텐츠를 모두 전송받은 이후 서버 1에 나머지 다중 연결 개수를 재할당하는 것이다. 이 때, 할당 비율은 실험적으로 또는 통계적으로 결정될 수 있으며, 수집된 데이터에 따라 주기적으로 갱신될 수 있다.
도 11 은 본 발명의 또 다른 실시예에 따른 평균 단일 수신율을 이용하여 다중 연결 개수를 결정한 경우, 다중 연결 개수와 전송율의 관계를 나타낸 도면이다.
본 발명의 또 다른 실시예에 따르면, 다중 연결의 평균 단일 수신율에 기초하여 다중 연결 개수를 증감함으로써 최적 다중 연결 개수를 결정할 수 있다. 본 명세서에서, 수신율은 클라이언트가 서버로부터 전송된 데이터를 수신하는 시간당 수신된 데이터양을 의미하는 것으로 전송율과 유사한 개념으로 사용된다.
평균 단일 수신율 Tas(Ni) 은 다중 연결 개수가 Ni일 때의 수신율 T(Ni)을 다중 연결 개수인 Ni로 나눈 것으로, Ni개의 다중 연결시 하나의 연결을 통해 수신되는 데이터의 수신율을 의미한다.
즉 평균 단일 수신율 Tas(N)은 식 2 와 같이 정의된다.
Figure 112015025991769-pat00032
(식 2)
평균 단일 수신율에 기초하여 최적 다중 연결 개수 No를 결정하기 위해, 초기 다중 연결 개수 Ni개 만큼의 다중 연결을 하고 그때의 수신율 T(Ni)을 구한다. 이후, 다중 연결 개수를 α만큼 증가시킨, 다중 연결 개수가 Ni+ α일 때의 전송율 T(Ni+ α) 를 구하고, T(Ni)와 T(Ni+ α)를 비교한다.
최적 다중 연결 개수는 높은 수신율을 확보할 수 있도록 결정되므로, T(Ni)와 T(Ni+ α)를 비교하여 T(Ni)가 T(Ni+ α)보다 크거나 같다면, 최적 다중 연결 개수 No는 Ni로 결정된다. 그러나, T(Ni)와 T(Ni+ α)의 비교 결과 T(Ni)가 T(Ni+ α)보다 작다면, 다중 연결 개수를 Ni보다 증가시키면 더 높은 수신율을 얻을 수 있는 상태이다. 이 때, 증가되는 다중 연결 개수 N은 각 다중 연결 개수의 평균 단일 수신율 증가 비율에 대한 파라미터 β 에 의해 결정된다.
즉, 최적 다중 연결 개수 No는 식 3 과 같이 결정되며,
Figure 112015025991769-pat00033
(식 3)
수신율 증가 비율 β 는 식 4 와 같이 정의된다.
Figure 112015025991769-pat00034
(식 4)
다중 연결 개수를 증가시켰을 때 평균 단일 전송율의 증가가 상대적으로 크다면 수신율 증가 비율 β 역시 큰 값을 가지게 되며, 평균 단일 전송율의 증가가 상대적으로 작다면 수신율 증가 비율 β 는 작은 값을 가지게 된다. 따라서, 이와 같은 특징을 이용하여 수신율 증가 비율 β 가 크다면 다중 연결 개수를 많이 증가시키고, 수신율 증가 비율 β 가 크지 않다면 다중 연결 개수를 적게 증가시키는 것이다.
예를 들어, 단일 연결의 효용(utilization)이 낮아 다중 연결 개수 증가에 따른 수신율의 증가가 크다면 수신율 증가 비율 β 는 1에 근접한 값을 가지고, 다중 연결 개수의 증가에 따른 수신율의 증가가 작다면 수신율 증가 비율 β 는 1 보다 작은 값을 가지게 된다. 따라서, β 가 0.9<β≤1 의 범위에 있을 때는 증가되는 다중 연결 개수 N 을 적극적으로 3 만큼 증가시키고, 0.7<β≤0.9 의 범위에 있을 때는 증가되는 다중 연결 개수 N 을 2 만큼 증가시키고, β≤0.7 의 범위에 있을 때는 증가되는 다중 연결 개수 N 을 소극적으로 1 만큼 증가시킬 수 있다.
또는 다중 연결 개수 Ni+α 일 때를 기준으로, β가 0.9<β≤1 의 범위에 있을 때는 증가되는 다중 연결 개수 N 을 α+3 만큼 증가시키고, 0.7<β≤0.9 의 범위에 있을 때는 증가되는 다중 연결 개수 N 을 α+2 만큼 증가시키고, β≤0.7 의 범위에 있을 때는 증가되는 다중 연결 개수 N 을 α+1 만큼 증가시키도록 구현할 수 있다.
이 때, 각 임계값은 0.7 또는 0.9 이외에도 다양하게 설정될 수 있으며 실험적으로 또는 경험적으로 결정될 수 있다.
도 11(a) 는 결정된 다중 연결 제어 횟수에 따른 클라이언트의 데이터 수신율을 나타낸 그래프로 x축은 다중 연결 제어 횟수를 의미하며 초기 접속 후 6회의 다중 연결 제어가 수행되는 동안의 클라이언트의 데이터 수신율을 측정한 것이다.
초기 접속 시 Ni=1, α=1 로 설정되어 있다. 초기 접속 시 Ni=1이므로 서버와 클라이언트가 단일 연결 되었을 때 클라이언트에서 데이터를 수신하는 단일 연결 수신율 T(1)을 계산하고, 연결 개수를 α개 만큼 증가시킨 두 개의 다중 연결시의 수신율 T(2)를 계산하여, 두 값을 비교한다.
도 11(a)에서 알 수 있는 바와 같이, 비교 결과 T(1)는 약 1.5Mbps이고, T(2)는 약 3Mbps로 더 큰 값을 가지므로 식 3 에 따라 다중 연결 개수가 증가된다. 이 때, 단일 수신율 증가 비율 β= Tas(2)/(Tas(1)) 이고 Tas(1)=T(1), Tas(2)=(T(2))/2 이므로 수신율 증가 비율 β 는 1에 근접한 값을 가지게 되고, 증가되는 다중 연결 개수 N 은 α+3이 되어, 다중 연결 개수 No는 5로 결정될 수 있다.
이후 같은 과정을 반복하며 다중 연결 개수를 결정하여 갱신하며, 최대 전송율을 가지는 최적 다중 연결 개수 No는 6으로 수렴하게 된다.
도 11(b) 는 도 11(a)와 같은 환경에서 현재 다중 연결 개수(Nr)에 따른 수신율을 나타낸 것으로, 다중 연결 개수가 6개가 될 때 까지는 다중 연결 개수가 증가할수록 수신율이 점점 증가하다가 다중 연결 개수가 7 이상이 되면 오히려 줄어들게 된다. 따라서, 최대 수신율을 확보하기 위한 최적의 다중 연결 개수는 6개가 되며 도 11(a)의 결과와 동일한 것을 확인할 수 있다.
도 12 는 본 발명의 또 다른 실시예에 따른 다중 연결 개수 결정을 위한 다중 연결 모드 상태도 및 각 모드에 대한 정의 등을 나타낸 것이다.
본 발명의 또 다른 실시예에 따르면, 최적의 다중 연결 개수 제어를 위한 상태도를 정의함으로써 실시간으로 최적 연결 개수를 결정하고 관리할 수 있으며, 최적 값 결정 속도를 제어하는 파라미터를 이용하여 결정 속도를 관리할 수 있다.
도 12(a) 는 본 발명의 또 다른 실시예에 따른 다중 연결 개수 결정을 위한 다중 연결 모드 상태도이다.
도 12 의 실시예 에서는, 초기 모드(IM, Initial Mode), 최적 모드(OM, Optimal Mode), 정체 모드(CM, Congestion Mode) 및 갱신 모드(UM, Update Mode)의 네 가지 모드가 정의된다. 이 때, Ni는 초기 연결 개수, No는 최적 연결 개수, Nn은 결정된 다중 연결 개수, Nr은 현재의 다중 연결 개수이고, To는 최대 전송율, Tr은 현재 전송율, Tc는 최대 단일 연결 전송율로 Tc=To/No 와 같이 정의된다.
도 12(b) 는 본 발명의 또 다른 실시예에 따른 다중 연결 개수 결정을 위한 다중 연결 모드에 대한 구체적 내용을 나타낸 것으로, 각 모드에 대한 설명, 진입/탈출 조건 및 각 모드에서의 동작을 설명한다.
첫번째, 초기 모드는 초기값(Ni)을 이용하여 다중 연결하고 전송을 개시하는 모드로, 설정된 초기값에 따라 다중 연결 한 경우 전송율 Tr이 적절한 값을 갖는지 여부를 확인한다. 확인된 Tr에 따라 바로 최적 모드로 진입하거나, 갱신 모드로 진입하여 최대 전송율 To을 갱신한 후 최적 모드로 진입한다.
두번째, 최적 모드는 현재 상태가 최적 연결 상태인지 여부를확인한다. 즉, Tr(No)가 되면 최적 모드로 진입하며, 지속적으로 Tr(No)를 관찰하며 모드 변경 여부를 결정한다. Tr(No)가 안정적인 값을 가지며 유지된다면 계속 최적 모드를 유지하나 전송율이 급격히 떨어지면 정체 모드로, 더 높은 전송율을 얻을 수 있다면 갱신 모드로 진입하여 최대 전송율 To을 갱신한 후 다시 최적 모드로 진입한다.
최적 모드 진입시 Pio를 이용하여 연결 수 증가 여부를 결정할 수 있는데, Pio는 초기 모드에서 최적 모드로 진입할 수 있는 최적 값을 찾는 속도를 결정하는 파라미터로 식 5 와 같이 정의된다.
Figure 112015025991769-pat00035
(식 5)
따라서, 초기 모드에서 최적 모드로 진입하기 위한 다중 연결 개수 Nn은 식 6 과 같이 결정된다.
Figure 112015025991769-pat00036
(식 6)
세번째, 정체 모드는 전송율이 급격히 낮아지는 경우 진입하게 된다. 구체적으로, Tr<To-α×Tc의 조건이 되면 정체 모드로 진입하며, 이 때 α는 정체 모드 제어 파라미터로 α≥1의 값을 가지며 정체 모드로의 진입 및 정체 모드로부터의 탈출 조건을 결정한다.
정체 모드에서는 Pco를 이용해 다중 연결 개수 Nn를 결정하며 Tr>To-α×Tc의 조건을 만족하게 되면 정체 모드를 탈출하여 최적 모드로 돌아간다. 이 때 Pco는 정체 모드에서 최적 모드로 진입할 수 있는 최적 값을 찾는 속도를 결정하는 파라미터로 식 7 과 같이 정의된다.
Figure 112015025991769-pat00037
(식 7)
따라서, 정체 모드에서 최적 모드로 진입하기 위한 다중 연결 개수 Nn은 식 8 과 같이 결정된다.
Figure 112015025991769-pat00038
(식 8)
네번째, 갱신 모드는 네트워크 상황이 좋아 높은 전송율을 얻을 수 있는 경우, 최대 전송율을 변경하기 위해 진입하는 모드이다. 구체적으로, Tr>To+β×Tc의 조건을 만족하면 갱신 모드로 진입하며, Tr을 새로운 최대 전송율 To로 설정하고 이로부터 새로운 No 을 결정한다. Tr를 갱신하면 바로 갱신 모드를 탈출하여 최적 모드로 돌아간다.
이 때, β는 갱신 모드 제어 파라미터로 β≥1의 값을 가지며 갱신 모드로 진입 및 갱신 모드로부터 탈출 조건을 결정한다.
도 13 은 본 발명의 또 다른 실시예에 따른 다중 연결 모드에 따라 다중 연결 개수를 결정하는 경우, 다중 연결 제어 횟수에 따른 전송율의 관계 및 다중 연결 개수의 관계를 나타낸 도면이다.
도 13 은, 다중 연결 제어 회수에 따른 현재 다중 연결 개수 Nn 및 최적 다중 연결 개수 No의 관계로 y축은 다중 연결 개수를 의미하고, Tr의 경우 전송율을 나타내는 것으로 전체적인 변화 양상을 나타내기 위해 하나의 도면에 표시하였으나 그 단위는 일치하지 않음을 유념해야 한다.
도 13 의 구현예의 경우, 초기 연결 개수 Ni=2, Pio=1인 경우를 가정하며 초기 모드에서는 최초 접속시 두개의 다중 연결을 설정한 후 전송율 Tr (2)에 기초하여 모드 변경 여부를 판단한다. Pio=1이므로 식 6 에 의해 Nn=No가 되어 바로 다음 제어 회차에서 Nn=10으로 결정되고 초기 모드를 벗어나 최적 모드로 진입한다.
도 13 과 같은 경우, 주기적으로 Nn을 변화시켜 Tr이 변화하는지 여부를 파악하여 최적 다중 연결 개수 No를 증가시킬 필요가 있는지 판단한다.
최적 다중 연결 개수 No는 10개로 계속 유지되며 네트워크 환경이 안정적인 상황이라고 유추할 수 있다. 또한, 전송을 시작하고 초기 모드에서 최적 모드로 진입한 초기에는 Tr이 다소간의 변동를 보이나, 약 10회의 다중 연결 제어 횟수 이후에는 Tr이 안정적인 형태로 나타남을 확인할 수 있다.
도 14 는 본 발명의 또 다른 실시예에 따른 다중 연결 모드에 따라 다중 연결 개수를 결정하는 경우, 다중 연결 제어 횟수와 전송율의 관계를 나타낸 도면이다.
도 14 의 구현예의 경우, 도 13 과 마찬가지로 초기 연결 개수 Ni=2, Pio=1인 경우를 가정하며 정체 모드 제어 파라미터 α 및 갱신 모드 제어 파라미터 β 역시 모두 1인 경우를 가정한다.
정체 모드 제어 파라미터 α 및 갱신 모드 제어 파라미터 β 역시 모두 1인 경우이므로 현재 전송율 Tr이 To-Tc≤Tr≤To+Tc 범위에 있다면 최적 모드가 유지된다. 그러나 Tr<To-Tc인 경우라면, 전송율이 급격히 낮아진 상태이므로 정체 모드로 진입하여 다중 연결 개수를 줄인다. 또한 Tr>To+Tc 인 경우라면, 전송율이 높은 상태이므로 갱신 모드로 진입하여 최적 다중 연결 개수 No 및 최대 전송율 To를 새로 결정하고 갱신한다.
도 14 를 살펴보면, 초기 연결 개수 Ni=2이므로 초기 모드에서는 최초 접속시 두개의 다중 연결을 설정한 후 전송율 Tr (2)에 기초하여 모드 변경 여부를 판단한다. Pio=1이므로 식 6 에 의해 Nn=No가 되어 바로 다음 제어 회차에서 Nn=10으로 결정되고 초기 모드를 벗어나 최적 모드로 진입한다.
다중 연결 제어 횟수가 7회에 이르기까지는 Tr이 일정 수준 이상으로 유지되므로 정체 모드나 갱신 모드로 진입하지 않고 최적 모드가 유지된다. 그러나, 다중 연결 제어 횟수가 8회일 때 Tr이 To+Tc보다 커지게 되므로 갱신 모드로 진입하게 되며 최적 다중 연결 개수 No 및 최대 전송율 To를 갱신한다.
갱신 모드에 진입하여 최적 다중 연결 개수 No 및 최대 전송율 To를 갱신한 후에는 바로 갱신 모드를 탈출하여 최적 모드로 진입하게 되며, 이 때 최적 모드를 결정하는 최대 전송율 To는 갱신된 결과인 Tr이 된다. 도 14 에서도 다중 연결 제어 회수 9회차 이후부터는 갱신된 최대 전송율 To가 적용되어 다중 연결 제어 회수 8회차까지의 최적 모드 범위보다 높은 전송율 범위를 갖는 것을 확인할 수 있다.
도 15 는 본 발명의 또 다른 실시예에 따른 패킷 도달 시간 차에 기초하여 다중 연결 개수를 결정하는 방법의 순서도이다.
패킷 도달 시간 차에 기초하여 다중 연결 개수를 결정하는 방법은 클라이언트에서 수신하는 패킷의 타임 스탬프를 이용하여, 각 패킷의 도달 시간차를 이용하는 것이다. 네트워크 환경이 좋을 경우는 전송 신호에 페이딩(fading)이나 간섭의 영향이 적으므로, 서버에서 전송하고 클라이언트에서 수신하는 데이터 간에는 시간 지연이 적게 발생하게 된다.
따라서, 데이터의 송수신 시간차를 이용하면 네트워크 상태를 판단할 수 있는 지표를 도출할 수 있는 것이다. 또한, 수신 패킷의 도달 시간차이를 이용함으로써 보다 작은 해상도(resolution)로 네트워크 상태의 분석이 가능할 뿐 아니라, 실시간으로 네트워크 상태 지표를 도출하고 적응적으로 다중 연결 개수를 제어할 수 있다.
패킷 도달 시간차 기반 네트워크 상태 지표를 계산하기 위해 새로운 변수들을 정의한다. dPATi는 클라이언트에서 i+1번째로 수신한 패킷과 클라이언트에서 i번째로 수신한 패킷의 도달 시간차(delta packet arrival time)로, 이를 수식으로 나타내면 식 9 와 같다.
Figure 112015025991769-pat00039
(식 9)
dTime(low passed delta packet arrival time)은 특수한 상황에 의해 패킷 도달 지연이 발생하는 등 신뢰도가 낮은 데이터 샘플을 제거하기 위해 dPATi 샘플들을 스무딩 필터링(smoothing filtering)한 결과로 식 10 과 같이 정의된다.
Figure 112015025991769-pat00040
(식 10)
dTime의 통계적 특징에 기초하여 다중 연결 개수를 증가 또는 감소시키는 판단 기준이 되는 dTime의 임계값을 결정하고, 결정된 dTime의 임계값을 이용하여 다중 연결 개수를 제어하는 것이다.
패킷 도달 시간 차에 기초하여 다중 연결 개수를 결정하는 구체적인 방법은 도 15에 개시된 순서도와 같이 진행되며 모두 3 단계로 구성된다.
제 1 단계(S1510)는 데이터 수집 단계로 적응적 임계값 생성을 위한 dTime 데이터를 수집하는 단계이다. 제 1 단계에서는, 확률 분포 모델링을 통한 최적의 고정 임계값을 이용하여 다중 연결 개수를 결정하거나, 미리 결정된 다중 연결 개수의 증가, 유지, 감소 및 종료 조건을 이용하여 다중 연결 개수를 결정할 수 있다.
제 2 단계(S1520)는 적응적 임계값을 결정하고 적용하는 단계로, 제 1 단계(S1510)에서 얻은 dTime로부터 산출한 샘플 평균, 샘플 표준편차, 다중 연결 개수의 증가/유지/감소 상태 비율을 이용하여 적응 임계값, 즉 다중 연결 개수를 변화시키는 임계 dTime인 THR_I_R 및 THR_R_D를 생성한다.
측정된 dTime이 THR_I_R 과 THR_R_D사이에 있다면 현재의 다중 연결 개수를 유지시키고, 측정된 패킷 도달 시간차가 THR_I_R 보다 작다면 네트워크 상태가 좋은 것으로 추정할 수 있으므로 다중 연결 개수를 증가킨다. 반대로 측정된 패킷 도달 시간차가 THR_R_D보다 크다면, 네트워크 상태가 좋지 않은 것으로 추정할 수 있으므로 다중 연결 개수를 감소시킨다.
제 3 단계(S1530)는 적응 임계값을 갱신하는 단계로, 제 2 단계(S1520)에서 얻은 dTime으로부터 일정 주기로 또는 네트워크 조건이 변동될 때 적응 임계값을 갱신한다. 적응 임계값이 갱신되면, 갱신된 적응 임계값을 이용하여 다중 연결 개수를 결정한다.
도 16 은 본 발명의 일 실시예에 따른 패킷 도달 시간 차에 기초하여 다중 연결 개수를 결정하는 방법에서 최적의 임계값을 결정하기 위한 확률 분포 모델링 결과를 나타낸 도면이다.
구체적인 동작을 설명하기 위해 (x|ω1), (x|ω2) 및 (x|ω3)을 정의한다. (x|ω1)은 최적 전송율을 얻기 위해 현재의 다중 연결 개수보다 다중 연결 개수를 증가시켜야 하는 상태에서 수집한 dTime 샘플들을 의미하고, (x|ω2)는 최적 전송율을 얻기 위해 현재의 다중 연결 개수를 유지시켜야 하는 상태에서 수집한 dTime 샘플들을 의미하고, (x|ω3)는 최적 전송율을 얻기 위해 현재의 다중 연결 개수를 감소시켜야 하는 상태에서 수집한 dTime 샘플들을 의미한다.
즉, 수집된 dTime 샘플의 값이 THR_I_R보다 작다면 다중 연결 개수를 증가시켜야 하는 상태에서 수집한 dTime 샘플이므로 (x|ω1)이고, 수집된 dTime 샘플의 값이 THR_R_D보다 크다면 다중 연결 개수를 감소시켜야 하는 상태에서 수집한 dTime 샘플이므로 (x|ω3)이고, 수집된 dTime 샘플의 값이 THR_I_R 과 THR_R_D사이에 있다면 현재의 다중 연결 개수를 유지시켜야 하는 상태에서 수집한 dTime 샘플이므로 (x|ω2)가 된다.
측정된 dTime의 값을 확률변수 x라 하고, x가 로그-노멀 분포(log-normal distribution)를 따른다고 가정하면, ln(x)는 노멀 분포(normal distribution), 즉 정규분포(Gaussian distribution)를 따른다.
ln(x|ω1 )와 ln(x|ω2)의 확률 밀도 함수를 각각 p(l|ω1) 및 p(l|ω2)이라 하면, 다중 연결 개수를 증가시켜야 하는 상황의 경우, 다중 연결 개수를 유지시켜야 하는 상황에 비해 패킷 도달 시간차가 더 작기 때문에 p(l|ω1)가 p(l|ω2)에 비해 더 작은 dTime에서 최고점을 갖는다.
ln(x|ω3 )의 확률 밀도 함수 p(l|ω3)가 함께 도시된다면 p(l|ω2)에 비해 더 큰 dTime에서 최고점을 가지게 되어 p(l|ω2)보다 우측에서 정규분포 형태로 나타날 것이다.
도 16 에서 dTime이 THR_I_R일 때를 기준으로, (x|ω1 )>THR_I_R인 확률 p(l>THR_I_R|ω1)는 p(l|ω1)를 x>THR_I_R 범위에 대해 적분한 값으로, 도 16에서 격자로 표시된 넓이(S1)와 같다. S1 영역은 측정된 dTime이 THR_I_R보다 크기 때문에 다중 연결 개수가 유지되야 하지만, 다중 연결 개수가 증가되는 상태의 비율을 의미한다.
또한, 도 16 에서 dTime이 THR_I_R일 때를 기준으로 (x|ω2 )≤THR_I_R인 확률 p(l≤THR_I_R|ω2)는 p(l|ω2)를 x≤THR_I_R 범위에 대해 적분한 값으로, 도 16 에서 가로로 표시된 넓이(S2)와 같다. S2 영역은 측정된 dTime이 THR_I_R보다 작은 값을 가지기 때문에 다중 연결 개수가 증가해야 하지만, 다중연결 개수가 유지되는 상태의 비율을 의미한다.
결국, S1과 S2는 오동작 하는 상태의 비율을 의미하므로 S1과 S2를 최소화하는 dTime을 임계값 THR_I_R로 결정한다면 오동작율, 또는 에러율을 최소화할 수 있는 것이다.
마찬가지 방법으로 THR_R_D를 결정함으로써, 에러율을 최소화할 수 있다.
도 17 은 본 발명의 일 실시예에 따른 패킷 도달 시간 차에 기초하여 다중 연결 개수를 결정하는 방법에서 dTime과 베이즈 에러의 관계를 나타낸 도면이다.
각각 정규 분포를 가지는 p(l|ω1)와 p(l|ω2)의 베이즈 에러는 도 17과 같은 형태를 가진다. p(l|ω1)와 p(l|ω2)의 베이즈 에러(Bayes Error)가 최소가 되는 t값이 다중 연결 개수를 증가시킬지 여부를 결정하는 dTime의 임계값인 THR_I_R으로 결정되며, 이는 베이즈 에러 공식으로부터 연역적으로 유도된다.
정규 분포를 가지는 p(l|ω2)와 p(l|ω3)의 베이즈 에러 역시 마찬가지 형태를 가지며 p(l|ω2)와 p(l|ω3)의 베이즈 에러가 최소가 되는 t값이 다중 연결 개수를 감소시킬지 여부를 결정하는 dTime의 임계값인 THR_R_D로 결정된다.
THR_I_R와 THR_R_D가 모두 결정되면, 현재 dTime을 측정하여 dTime<THR_I_R이면 다중 연결 개수를 증가시키고, dTime>THR_R_D이면 다중 연결 개수를 감소시키고, THR_R_D≤dTime≤THR_I_R이면 다중 연결 개수를 유지시키도록 하여 다중 연결 개수를 제어할 수 있다.
도 17 에서 dTime이 4ms일 때 p(l|ω1)와 p(l|ω2)의 베이즈 에러가 최소값을 가지므로 THR_I_R는 4ms로 결정된다. 또한, dTime이 6.5ms일 때 p(l|ω2)와 p(l|ω3)의 베이즈 에러가 최소값을 가지므로 THR_R_D는 6.5ms로 결정된다.
따라서, 현재의 dTime을 측정하여, dTime<4ms이면 다중 연결 개수를 증가시키고, dTime>6.5ms이면 다중 연결 개수를 감소시키고, 4ms≤dTime≤6.5ms이면 다중 연결 개수를 유지시키도록 결정한다.
이하에서는 베이즈 에러를 이용하여 적응 임계값을 결정하기 위한 구체적인 방법을 설명한다.
dTime에 대한 확률변수 x가 로그-노멀 분포라고 가정하였으므로 이를 정규 분포로 변환하기 위해 새로운 확률 변수 Zi를 식 11 과 같이 정의한다.
Figure 112015025991769-pat00041
(식 11)
여기서, αi는 각 상태에서 수집한 dTime 샘플 (x|ωi)의 자연로그값 ln(x|ωi)의 평균을 의미하고 βi는 ln(x|ωi)의 표준편차를 의미하며, 식 12 내지 식 13 과 같이 정의된다.
Figure 112015025991769-pat00042
(식 12)
Figure 112015025991769-pat00043
,
Figure 112015025991769-pat00044
(식 13)
적응적 임계값 THR_I_R 는 베이즈 에러 공식으로부터 연역적으로 유도하여, 식 14 와 같이 결정된다.
Figure 112015025991769-pat00045
(식 14)
여기서,
Figure 112015025991769-pat00046
,
Figure 112015025991769-pat00047
,
Figure 112015025991769-pat00048
,
Figure 112015025991769-pat00049
이다.
마찬가지 방법으로, 적응적 임계값 THR_R_D는 베이즈 에러 공식으로부터 연역적으로 유도하여, 식 15 와 같이 결정된다.
Figure 112015025991769-pat00050
(식 15)
여기서,
Figure 112015025991769-pat00051
,
Figure 112015025991769-pat00052
,
Figure 112015025991769-pat00053
,
Figure 112015025991769-pat00054
이다.
앞서 언급된 바와 같이, 본 발명의 일 실시예에 따른 패킷 도달 시간 차에 기초하여 다중 연결 개수를 결정하는 방법에서, 제 1 단계는 적응적 임계값 생성을 위한 dTime 데이터를 수집하는 단계로 적응적 임계값이 결정되지 않은 상태이다. 따라서, 제 1 단계에서는 확률 분포 모델링을 이용한 최적의 고정 임계값에 기초하여 다중 연결 개수를 결정하거나 미리 결정된 다중 연결 개수의 증가, 유지, 감소 및 종료 조건을 이용하여 다중 연결 개수를 결정할 수 있다.
확률 분포 모델링을 이용한 최적의 고정 임계값에 기초하여 다중 연결 개수를 결정하는 방법은, 각 상태에서 수집한 dTime 샘플의 확률 밀도 함수를 이용한다.
제 1 단계에서, 서버와 클라이언트가 연결되면, 초기값 Ni 개의 연결부터 시작하여 최종값 Nf 까지 다중 연결 개수를 증가시키며 각 다중 연결 개수에 대한 전송율을 측정하고 dTime 샘플들을 수집한다.
다중 연결 개수에 따라 전송율 측정 결과, 최대 전송율을 얻기 위한 다중 연결 개수가 No개라면, 다중 연결 개수 No보다 작은 다중 연결 개수인 1,…,No-1개의 연결인 상태에서 수집한 dTime 샘플들이 (x|ω1)가 되고, 최적 다중 연결 개수 No개의 연결인 상태에서 수집한 dTime 샘플들이 (x|ω2)가 된다. 또한, 최적 다중 연결 개수 No보다 큰 다중 연결 개수인 No+1,…, Nf 개의 연결인 상태에서 수집한 dTime 샘플들은 (x|ω3)가 된다.
이 때, ω1, ω2 및 ω3을 결정하는 조건은 최적 다중 연결 개수 No으로부터 일정 범위 내의 다중 연결 개수로 정의할 수 있다. 예를들어, 최대 전송율을 얻기 위한 다중 연결 개수가 4인 경우, 4를 기준으로 ±1개의 다중 연결 개수의 범위를 다중 연결 개수를 다중 연결 개수를 유지시켜야 하는 상태로 정의할 수 있다.
이와 같은 경우 다중 연결 개수가 1, 2 개인 상태에서 수집한 dTime 샘플들이 (x|ω1)가 되고, 다중 연결 개수가 3, 4, 5 개인 상태에서 수집한 dTime 샘플들이 (x|ω2)가 되며, 다중 연결 개수가 6 개 이상인 상태에서 수집한 dTime 샘플들이 (x|ω3)가 되는 것이다.
수집한 dTime 샘플들로부터 유도한 값들을 식 11 내지 식 15에 적용함으로써, 제 1 단계에 적용할 고정 임계값을 결정할 수 있다.
또는, 제 1 단계에서 미리 결정된 다중 연결 개수의 증가, 유지, 감소 및 종료 조건을 이용하여 다중 연결 개수를 결정 할 수 있다.
충분한 양의 dTime 샘플을 수집할 때 까지는 다중 연결 개수에 따라 고정된 증가/유지/감소/종료 조건을 적용하는 것이다.
예를 들어, 제 1 단계에서 서버와 클라이언트가 연결되면 다중 연결을 증가시키며 적응적 임계값 생성을 위한 dTime 샘플을 수집하지만, 다중 연결 개수가 1 개부터 4 개 까지는 다중 연결 개수를 증가시키고, 다중 연결 개수가 5 개부터 7 개 까지는 다중 연결 개수를 유지시키고, 다중 연결 개수가 8개 이상이 되면 다중 연결 개수를 감소시킨다.
또는, 다중 연결 개수가 12 개 이상이 되거나 초기 연결 후 2 초가 경과하면 제 1 단계를 종료하고 제 2 단계로 진입하여 수집된 dTime 샘플을 이용하여 적응 임계값을 결정한다. 제 1 단계에 이와 같은 방식을 적용하면, 수집된 샘플을 분석하고 임계값을 계산하는 과정이 필요하지 않은 장점이 있다.
도 18 은 본 발명의 실시예에 따른 클라이언트가 이동성을 가지는 경우의 동작을 설명하기 위한 도면이다.
이상에서는, 클라이언트 기반으로 다중 연결 개수를 결정하는 방법에 대해 설명하였다. 클라이언트 기반의 다중 연결 개수 결정 방법은 네트워크 상황 또는 서비스 타입등에 따라 다중 연결 개수 및 서브세그먼트 크기 등을 클라이언트가 결정하고, 이와 같은 다중 연결 이력 정보가 저장된 다중 연결 테이블을 클라이언트가 저장 및 관리한다.
앞서 언급한 바와 같이 클라이언트(100)는, 휴대폰, 스마트폰, PDA(Personal Digital Assistant), PDA폰, 노트북, 스마트 TV 등과 같이 애플리케이션을 실행할 수 있는 장치를 의미하며, 네트워크를 통하여 서버에 연결되는 모든 종류의 장치를 포함할 수 있다. 대표적인 클라이언트로 스마트폰을 들 수 있으며, 스마트폰은 사용자가 항상 휴대하는 경우가 대부분으로 사용자의 이동에 따라 위치가 지속적으로 변화하는 높은 이동성을 가지며 항상 기지국과 연결되어 있는 특징을 갖는다.
클라이언트가 이동성을 가지는 경우, 이동 지역에 따라 네트워크 환경이 지속적으로 변화하게 되며, 클라이언트가 이동전화라면 기지국으로부터 수신한 정보에 기초하여 현재 위치하는 지역을 알 수 있다. 따라서 각 지역에 따라 적절한 다중 연결 제어를 위해서 클라이언트는 현재 위치하는 지역의 다중 연결 제어 테이블을 작성하여 저장하고, 다중 연결 제어 테이블을 이용하여 다중 연결을 제어하게 된다.
도 18 과 같은 경우, 클라이언트(100)가 수원 지역에 진입하면 수원 지역의 기지국(504)으로부터 수신한 정보에 기초하여, 클라이언트(100)는 수원 지역의 다중 연결 제어 테이블 SUWON_LTE.tbl을 작성한다. SUWON_LTE.tbl을 작성하고 나면 클라이언트(100)는 SUWON_LTE.tbl를 이용하여 다중 연결 개수 및 서브세그먼트의 크기 등을 결정할 수 있다.
이후 클라이언트(100)가 인접한 용인 지역에 진입하면, 클라이언트는 용인 지역의 기지국(505)으로부터 수신한 정보에 기초하여 용인 지역의 다중 연결 제어 테이블 YONGIN_LTE.tbl을 새로 작성하고 이용하는 동일한 과정을 반복해야 한다.
결국, 새로운 지역으로 이동하여 새로운 네트워크 환경이 되면 클라이언트는 매번 변화된 네트워크 환경에 적합한 새로운 다중 제어 테이블을작성해야 하며, 변화된 네트워크 환경에 적응하기 위한 초기 시간이 필요하게 된다.
도 19 는 본 발명의 또 다른 일 실시예에 따른 클라이언트가 이동성을 가지는 경우 다중 연결을 제어하는 시스템을 나타낸 도면이다.
본 발명의 또 다른 일 실시예에 따르면, 클라이언트가 이동성을 가지는 경우, 다중 연결 이력을 이용하기 위한 시스템은 각 기지국을 총괄하는 서버(500), 각 지역의 기지국들(기지국 1 및 기지국 2), 이동성을 가지는 클라이언트들(클라이언트 1 및 클라이언트 2)로 구성된다. 이동성을 가지는 클라이언트들은 각각 서로 다른 지역에 존재할 수 있는데, 클라이언트1(100)은 지역 1 에 존재하고 클라이언트 2(101)는 지역 2에 존재하는 경우를 가정한다.
기지국을 총괄하는 서버(500)는, 다중 연결 제어 이력을 이용하는 클라이언트 그룹에 속한 클라이언트들(100, 101, 102, 103)을 분류한다. 이 때, 분류 기준은 서비스 특성에 따라 결정되는데, 예를 들어 서비스 내용, 서비스 경로 또는 서비스 방식 등에 따라 분류될 수 있다.
각 클라이언트(클라이언트 1 및 클라이언트 2)는 자신이 속한 지역의 기지국들 (기지국 1 및 기지국 2)로 다중 연결 이력을 전송하고, 각 기지국들(기지국 1 및 기지국 2)은 수신한 다중 연결 이력을 서버(500)로 전송한다. 이 때, 클라이언트가 기지국으로 전송하는 다중 연결 이력 또는 기지국이 서버로 전송하는 다중 연결 이력은, 클라이언트의 다중 연결 이력이 저장된 다중 연결 테이블일 수 있다.
서버(500)는 기지국들 (기지국 1 및 기지국 2)부터 클라이언트들 각각의 다중 연결 이력을 수신하고, 각 분류된 클라이언트 그룹별로 대표 다중 연결 설정을 산출하여 저장한다.
이후, 클라이언트의 이동성에 의해 클라이언트 1 이 지역 2 로 이동할 수 있다. 클라이언트 1(100) 은 기지국 2(505)로부터 수신한 신호에 의해 자신이 지역 2에 있음을 알 수 있다. 따라서, 클라이언트 1(100)은 기지국 2(505)로 지역 2의 대표 다중 연결 설정의 전송을 요청한다.
클라이언트 1(100)로부터 지역 2의 대표 다중 연결 설정의 전송을 요청받은 기지국 2(505)는 다시 서버(500)로 지역 2의 대표 다중 연결 설정의 전송을 요청한다. 서버(500)는 전송 요청에 대한 응답으로 지역 2의 대표 다중 연결 설정을 기지국 2(505)로 전송하며, 기지국 2(505)는 수신한 지역 2의 대표 다중 연결 설정을 다시 클라이언트 1(100)로 전송한다.
이와 같이 서버로부터 전송받은 다중 연결 제어 설정을 이용하는 경우, 서비스 특성 변경에 따른 다중 연결 제어 이력을 직접 작성할 필요가 없기 때문에 서비스 특성 변경 초기의 시스템 성능 저하를 감소시킬 수 있다.
이 때, 다중 연결 이력 및 대표 다중 연결 설정 역시 테이블 형태로 작성되어 공유될 수 있으며, 클라이언트와 서버가 서비스 특성에 기반한 공통된 작명 규칙을 공유한다면 보다 더 효율적인 다중 제어 테이블의 공유가 가능하다.
도 19 에서는 별도의 서버(500)가 존재하며 서버를 통해 다중 연결 제어 이력 및 대표 다중 연결 설정이 관리된다. 그러나, 기지국 역시 서버의 기능을 수행할 수 있으므로 별도의 서버가 존재하지 않는 경우에도 기지국에서 해당 기지국 반경 내에 존재하는 클라이언트들을 이용한 다중 연결 제어 이력 및 대표 다중 연결 설정의 관리가 가능하다.
도 20 은 본 발명의 또 다른 일 실시에에 따른 클라이언트가 이동성을 가지는 경우 다중 연결을 제어하는 시스템의 동작을 나타낸 도면이다.
도 20 의 시스템에서는 도 19 의 시스템과 달리, 기지국을 총괄하는 서버가 존재하지 않는다. 그러나, 기지국 각각은 서버의 역할을 수행할 수 있으므로 각각의 기지국 내에 존재하는 클라이언트들을 그룹화하여 해당 클라이언트 그룹으로부터 수신한 다중 연결 제어 이력을 관리할 수 있다.
기지국 1(504)은 기지국 1 내에 존재하는, 클라이언트 1을 포함하는 클라이언트들로부터 다중 연결 제어 이력을 수신하고 수신한 다중 연결 제어 테이블을 종합하여, 지역 1의 대표 다중 연결 설정을 결정한다.
기지국 2(505)는 기지국 2 내에 존재하는 클라이언트들로부터 다중 연결 이력을수신하고 수신한 다중 연결 이력을 종합하여, 지역 2의 대표 다중 연결 설정을 결정한다.
이후, 클라이언트의 이동성에 의해 클라이언트 1 이 지역 2 로 이동할 수 있다. 클라이언트 1(100) 은 기지국 2(505)로부터 수신한 신호에 의해 자신이 지역 2에 있음을 알 수 있다. 따라서, 클라이언트 1(100)은 기지국 2(505)로 지역 2의 대표 다중 연결 설정의 전송을 요청한다.
클라이언트 1(100)로부터 지역 2의 대표 다중 연결 설정의 전송을 요청받은 기지국 2(505)은, 전송 요청에 대한 응답으로 기지국 2(505)에 저장되어 있는 지역 2의 대표 다중 연결 설정을 다시 클라이언트 1(100)로 전송한다.
이와 같이 기지국이 서버로 동작하는 경우, 모든 지역의 다중 연결 제어 이력을 총괄하여 관리할 수는 없지만 해당 지역의 다중 연결 제어 이력을 관리할 수 있으며 별도의 서버를 거치지 않기 때문에 보다 효율적인 운영이 가능하다.
도 21 은 도 19 의 시스템에서, 클라이언트가 다른 지역으로 이동한 경우의 동작을 설명하기 위한 도면이다.
도 21 의 실시예에서는, 서비스 경로에 의해 수원 지역의 클라이언트 그룹 1(100) 과 용인 지역의 클라이언트 그룹 2(101, 102, 103,…)으로 분류될 수 있다. 또한, 도 21 의 실시예에서는 클라이언트 각각의 다중 연결 제어 이력 및 기지국 각각의 대표 다중 연결 설정이 다중 연결 제어 테이블의 형태로 관리된다.
서버(500)는 클라이언트 그룹들부터 다중 연결 제어 테이블을 수신하고, 클라이언트 그룹 1의 대표 다중 연결 제어 테이블과 클라이언트 그룹 2의 대표 다중 연결 제어 테이블을 산출하여 저장한다.
수원 지역에서 서비스를 이용하던 클라이언트 100이 용인 지역으로 이동하면, 클라이언트 100 은 서비스 특성(서비스 경로)가 변경되었으므로 용인 지역의 클라이언트 그룹 2의 다중 연결 제어 테이블의 전송을 요청한다.
도 21 에서는, 클라이언트의 다중 연결 제어 테이블 전송 요청이 기지국을 통해 서버로 전송되고 다중 연결 제어 테이블은 서버로부터 기지국을 통해 클라이언트로 전송되지만, 도 20 에 개시된 시스템이라면 별도의 서버 없이 클라이언트의 요청을 수신한 기지국이 바로 클라이언트로 다중 연결 제어 테이블을 전송할 수 있다.
이 때, 앞서 언급한 바와 같이 클라이언트와 서버가 서비스 특성에 기반한 공통된 작명 규칙을 공유한다면 보다 더 효율적인 다중 제어 테이블의 공유가 가능하다.
예를 들어 서비스내용_지역_서비스방식.tbl과 같은 작명 규칙을 공유한다면, 도 21 과 같이 서버(500)에서는 MBL_YONGIN_LTE.tbl과 같은 이름으로 다중 연결 제어 테이블을 작성하여 저장하고, 클라이언트(501)에서는 동일한 작명 규칙에 의해 작성한 MBL_YONGIN_LTE.tbl을 요청하는 HTTP 메시지를 전송한다.
이와 같은 방법을 이용하면 별도의 전송 방식에 대한 새로운 정의 없이 표준 HTTP 전송을 통해 다중 제어 연결 테이블의 공유 및 이용이 가능하다.
도 22 는 본 발명의 일 실시예에 따라 다중 연결을 제어하는 클라이언트 (100)의 세부 구성도이다.
도 22 에 도시된 바와 같이, 본 발명의 일 실시예에 따라 다중 연결을 제어하는 클라이언트(100)는 다중 연결 결정부(110), 애플리케이션 실행부(120), 제어부(130), 수신부(140), 송신부(150) 및 저장부(160)를 포함한다.
다중 연결 결정부(110)는, 다중 연결 제어 테이블을 하고, 작성된 다중 연결 테이블을 저장부(160)에 저장하며, 다중 연결 테이블을 이용하여 다중 연결 개수를 결정한다. 다중 연결 개수 및 서브세그먼트 크기가 결정되면, 다중 연결 결정부(110)는 결정된 다중 연결 개수 및 서브세그먼트 크기를 제어부(130) 또는 송신부(150)로 전달한다.
애플리케이션 실행부(120)는 클라이언트에서 사용자에게 서비스를 제공하기 위한 애플리케이션을 실행한다. 애플리케이션 실행부(120)는 애플리케이션에서 제공하는 서비스의 서비스 타입 또는 서비스를 제공하기 위한 데이터 사이즈를 다중 연결 결정부(110)에 전달할 수 있다. 애플리케이션 실행부(120)는 애플리케이션에서 제공하는 서비스에 포함된 링크의개수를 다중 연결 결정부(110)에 전달할 수 있다.
수신부(140)는 서버로부터 전송되는 데이터의 세그먼트 또는 서브세그먼트를 수신한다. 또는, 실시예에 따라 서버로부터 전송되는 대표 다중 연결 제어 테이블을 수신할 수 있다.
송신부(150)는 결정된 다중 연결 개수 및 서브세그먼트 크기와, 그에 따른 다중 연결 요청을 서버로 전송한다. 또는, 실시예에 따라 서버 또는 기지국으로 대표 다중 연결 제어 테이블 전송 요청을 전송한다.
저장부(160)는 다중 연결 결정부(110)에서 결정한 다중 연결 제어 테이블을 저장한다. 또는, 실시예에 따라 서버 또는 기지국으로부터 수신된 대표 다중 연결 테이블을 저장한다.
제어부(130)는 클라이언트(100) 전체의 동작을 제어하며, 다중 연결 개수 및 서브세그먼트 크기를 결정할 수 있도록 다중 연결 결정부(110), 애플리케이션 실행부(120), 수신부(140), 송신부(150) 및 저장부(160)를 제어한다.
이상 설명된 본 발명에 따른 실시예는 다양한 컴퓨터 구성요소를 통하여 실행될 수 있는 프로그램 명령어의 형태로 구현되어 컴퓨터 판독 가능한 기록 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능한 기록 매체는 프로그램 명령어, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 컴퓨터 판독 가능한 기록 매체에 기록되는 프로그램 명령어는 본 발명을 위하여 특별히 설계되고 구성된 것이거나 컴퓨터 소프트웨어 분야의 당업자에게 공지되어 사용 가능한 것일 수 있다. 컴퓨터 판독 가능한 기록 매체의 예에는, 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체, CD-ROM 및 DVD와 같은 광기록 매체, 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical medium), 및 ROM, RAM, 플래시 메모리 등과 같은, 프로그램 명령어를 저장하고 실행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령어의 예에는, 컴파일러에 의하여 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용하여 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드도 포함된다. 하드웨어 장치는 본 발명에 따른 처리를 수행하기 위하여 하나 이상의 소프트웨어 모듈로 변경될 수 있으며, 그 역도 마찬가지이다.
이상에서 본 발명이 구체적인 구성요소 등과 같은 특정 사항과 한정된 실시예 및 도면에 의하여 설명되었으나, 이는 본 발명의 보다 전반적인 이해를 돕기 위하여 제공된 것일 뿐, 본 발명이 상기 실시예에 한정되는 것은 아니며, 본 발명이 속하는 기술분야에서 통상적인 지식을 가진 자라면 이러한 기재로부터 다양한 수정과 변경을 꾀할 수 있다.
따라서, 본 발명의 사상은 상기 설명된 실시예에 국한되어 정해져서는 아니 되며, 후술하는 특허청구범위뿐만 아니라 이 특허청구범위와 균등한 또는 이로부터 등가적으로 변경된 모든 범위는 본 발명의 사상의 범주에 속한다고 할 것이다.

Claims (27)

  1. 클라이언트에서 서비스를 제공하기 위한 다중 연결 방법에 있어서,
    서비스를 제공하기 위한 적어도 하나의 애플리케이션을 실행하는 단계;
    상기 실행된 애플리케이션에 의해 제공되는 서비스의 서비스 타입을 결정하는 단계;
    다중 연결 개수 및 서브세그먼트 크기에 대한 정보를 포함하는 다중 연결 이력을 참조하는 단계;
    상기 참조된 다중 연결 이력에서, 상기 결정된 서비스 타입과 동일한 서비스 타입을 가지는 서비스의 다중 연결 개수 및 서브 세그먼트 크기에 기초하여 다중 연결 개수 및 서브세그먼트 크기를 결정하는 단계; 및
    상기 결정된 다중 연결 개수 및 상기 결정된 서브세그먼트 크기에 따라 다중 연결을 요청하는 단계;
    를 포함하는, 다중 연결 방법.
  2. 삭제
  3. 제1항에 있어서,
    상기 결정된 다중 연결 개수 및 상기 결정된 서브세그먼트 크기는 세그먼트 크기에 기초하여 재결정되는, 다중 연결 방법.
  4. 제 1 항에 있어서,
    상기 적어도 하나의 애플리케이션에 표시되는 웹 페이지에 포함된 적어도 하나의 링크의 개수를 판단하는 단계;를 더 포함하고,
    상기 다중 연결 개수를 결정하는 단계는,
    상기 적어도 하나의 링크 각각에서 제공하는 서비스의 타입 및 상기 적어도 하나의 링크 각각에서 제공하는 서비스를 위한 데이터 사이즈 중 적어도 하나에 기초하여, 상기 적어도 하나의 링크 각각에 대응하는 다중 연결 개수를 결정하는, 다중 연결 방법.
  5. 제 1 항에 있어서, 상기 제공할 서비스가 복수 개인 경우,
    상기 다중 연결 개수를 결정하는 단계는,
    상기 복수 개의 제공할 서비스 각각에 대해 판단된 서비스 타입에 따라 상기 복수 개의 서비스 각각에 요청될 다중 연결 개수를 결정하는, 다중 연결 방법.
  6. 제 1 항에 있어서,
    상기 다중 연결 개수를 결정하는 단계는,
    상기 다중 연결 개수 Ni로 연결된 데이터 전송율 T(Ni)를 계산하는 단계;
    상기 다중 연결 개수를 Ni+α로 증가시키고, 상기 증가된 다중 연결 개수 Ni+α로 연결된 데이터 전송율 T(Ni+α)를 계산하는 단계; 및
    T(Ni)와 T(Ni+α)를 비교하는 단계를 더 포함하고,
    비교 결과, T(Ni+α)≤T(Ni)이면 다중 연결 개수 No=Ni로 결정하고,
    비교 결과 T(Ni+α)>T(Ni)이면 다중 연결 개수 No=Ni+N으로 결정하는 단계;를 더 포함하고,
    상기 N은 다중 연결 개수가 Ni+α일 때의 평균 단일 수신율(Tas(Ni+α))과 다중 연결 개수가 Ni일 때의 평균 단일 수신율(Tas(Ni))의 증가 비율, β= Tas(Ni+α)/(Tas(Ni))에 기초하여 결정되는, 다중 연결 방법.
  7. 제 1 항에 있어서,
    상기 다중 연결 개수는 다중 전송 모드에 기초하여 결정되는, 다중 연결 방법.
  8. 제 7 항에 있어서,
    상기 다중 전송 모드는 초기 모드(Initial Mode), 최적 모드(Optimal Mode), 정체 모드(Congestion Mode) 또는 갱신 모드(Update Mode) 중 적어도 하나를 포함하는, 다중 연결 방법.
  9. 제 1 항에 있어서,
    상기 다중 연결 개수는 클라이언트에 수신되는 i번째 패킷의 도달 시간차 dPATi 에 기초하여 결정되며,
    상기
    Figure 112015025991769-pat00055
    이고 상기 PATi는 상기 i번째 패킷이 수신된 시간인, 다중 연결 방법.
  10. 제 9 항에 있어서, 상기 다중 연결 개수를 결정하는 단계는,
    상기 dPATi를 수집하는 단계;
    상기 수집된 dPATi를 이용하여 제 1 임계값 T1 및 제 2 임계값 T2을 생성하는 단계; 및
    상기 T1 및 상기 T2을 갱신하는 단계;를 더 포함하고,
    현재 패킷의 도달 시간차가 상기 T1 보다 작으면 상기 다중 연결 개수를 증가시키고, 상기 현재 패킷의 도달 시간차가 상기 T2 보다 크면 상기 다중 연결 개수를 감소시키는, 다중 연결 방법.
  11. 제 10 항에 있어서,
    상기 T1은 다중 연결 개수가 증가되는 상태에서 수집한 dPATi 샘플 ω1 중 T1 보다 큰 dPATi를 갖는 샘플의 비율과, 다중 연결 개수가 유지되는 상태에서 수집한 dPATi 샘플 ω2 중 T1보다 작은 dPATi을 갖는 샘플의 비율의 베이즈 에러율(Bayes error rate)이 최소가 되도록 하는 패킷 도달 시간차이고,
    상기 T2는 상기 ω2중 T2보다 큰 dPATi을 갖는 샘플의 비율과, 다중 연결 개수가 감소되는 상태에서 수집한 dPATi 샘플 ω3중 T2보다 작은 dPATi을 갖는 샘플의 비율의 베이즈 에러율이 최소가 되도록 하는 패킷 도달 시간차인, 다중 연결 방법.
  12. 제 11 항에 있어서,
    상기
    Figure 112015025991769-pat00056
    이고,
    이 때, 상기
    Figure 112015025991769-pat00057
    , 상기
    Figure 112015025991769-pat00058
    , 상기
    Figure 112015025991769-pat00059
    , 상기
    Figure 112015025991769-pat00060
    이고,
    상기
    Figure 112015025991769-pat00061
    이고,
    이 때, 상기
    Figure 112015025991769-pat00062
    , 상기
    Figure 112015025991769-pat00063
    , 상기
    Figure 112015025991769-pat00064
    , 상기
    Figure 112015025991769-pat00065
    이고,
    상기
    Figure 112015025991769-pat00066
    , 상기
    Figure 112015025991769-pat00067
    이고 상기
    Figure 112015025991769-pat00068
    인, 다중 연결 방법.
  13. 클라이언트에 서비스를 제공하기 위한 다중 연결 방법에 있어서,
    적어도 하나의 클라이언트로부터, 상기 적어도 하나의 클라이언트에서 실행된 애플리케이션이 제공하는 서비스 타입에 기초하여 미리 결정된 다중 연결 개수 및 서브 세그먼트 크기에 대한 정보를 포함하는 다중 연결 이력을 수신하는 단계;
    상기 수신된 다중 연결 이력에 기초하여 상기 적어도 하나의 클라이언트를 분류하는 단계;
    상기 다중 연력 이력에 기초하여 상기 클라이언트 별 대표 다중 연결 설정을 결정하는 단계;
    상기 결정된 대표 다중 연결 설정을 저장하는 단계;
    상기 적어도 하나의 클라이언트로부터 대표 다중 연결 설정의 전송 요청이 수신되면, 상기 수신된 대표 다중 연결 설정의 전송 요청에 응답하여, 상기 전송 요청이 수신된 대표 다중 연결 설정을 전송하는 단계;를 포함하는,
    다중 연결 방법.
  14. 서비스를 제공하기 위해 다중 연결하는 클라이언트 장치에 있어서,
    서비스를 제공하기 위한 적어도 하나의 애플리케이션을 실행하는 애플리케이션 실행부;
    다중 연결 개수 및 서브세그먼트 크기에 대한 정보를 포함하는 다중 연결 이력이 저장된 저장부;
    상기 실행된 애플리케이션에 의해 제공되는 서비스의 서비스 타입을 결정하고, 상기 저장된 다중 연결 이력에서, 상기 결정된 서비스 타입과 동일한 서비스 타입을 가지는 서비스의 다중 연결 개수 및 서브 세그먼트 크기에 기초하여 다중 연결 개수 및 서브세그먼트 크기를 결정하는 결정부; 및
    상기 결정된 다중 연결 개수 및 상기 결정된 서브세그먼트 크기에 따라 다중 연결 요청을 전송하는 전송부;
    를 포함하는, 클라이언트 장치.
  15. 삭제
  16. 제 14 항에 있어서,
    상기 결정부는,
    세그먼트 크기에 기초하여 상기 다중 연결 개수 및 상기 서브세그먼트 크기를 재결정하는, 클라이언트 장치.
  17. 제 14 항에 있어서,
    상기 결정부는,
    상기 적어도 하나의 애플리케이션에 표시되는 웹 페이지에 포함된 적어도 하나의 링크의 개수를 판단하고,
    상기 적어도 하나의 링크 각각에서 제공하는 서비스의 타입 및 상기 적어도 하나의 링크 각각에서 제공하는 서비스를 위한 데이터 사이즈 중 적어도 하나에 기초하여, 상기 적어도 하나의 링크 각각에 대응하는 다중 연결 개수를 결정하는, 클라이언트 장치.
  18. 제 14 항에 있어서, 상기 제공할 서비스가 복수 개인 경우,
    상기 결정부는,
    상기 복수 개의 제공할 서비스 각각에 대해 판단된 서비스 타입에 따라 상기 복수 개의 서비스 각각에 요청될 다중 연결 개수를 결정하는, 클라이언트 장치.

  19. 제 14 항에 있어서, 상기 결정부는,
    상기 다중 연결 개수 Ni로 연결된 데이터 전송율 T(Ni) 및 증가된 다중 연결 개수 Ni+α로 연결된 데이터 전송율 T(Ni+α)를 계산하고,
    T(Ni)와 T(Ni+α)를 비교하여,
    비교 결과, T(Ni+α)≤T(Ni)이면 다중 연결 개수 N0=Ni로 결정하고,
    비교 결과 T(Ni+α)>T(Ni)이면 다중 연결 개수 No=Ni+N으로 결정하며,
    상기 N은 다중 연결 개수가 Ni+α일 때의 평균 단일 수신율(Tas(Ni+α))과 다중 연결 개수가 Ni일 때의 평균 단일 수신율(Tas(Ni))의 증가 비율, β= Tas(Ni+α)/(Tas(Ni))에 기초하여 결정하는, 클라이언트 장치.
  20. 제 14 항에 있어서,
    상기 다중 연결 개수는 다중 전송 모드에 기초하여 결정되는, 클라이언트 장치.
  21. 제 20 항에 있어서,
    상기 다중 전송 모드는 초기 모드(Initial Mode), 최적 모드(Optimal Mode), 정체 모드(Congestion Mode) 또는 갱신 모드(Update Mode) 중 적어도 하나를 포함하는, 클라이언트 장치.
  22. 제 14 항에 있어서,
    상기 다중 연결 개수는 클라이언트에 수신되는 i번째 패킷의 도달 시간차 dPATi 에 기초하여 결정되며,
    상기
    Figure 112015025991769-pat00069
    이고 상기 PATi는 상기 i번째 패킷이 클라이언트에 수신된 시간인, 클라이언트 장치.
  23. 제 22 항에 있어서, 상기 결정부는,
    상기 dPATi를 수집하고;
    상기 수집된 dPATi를 이용하여 제 1 임계값 T1 및 제 2 임계값 T2을 생성하고;
    상기 제 1 임계값 및 상기 제 2 임계값을 갱신하고,
    현재 패킷의 도달 시간차가 상기 T1 보다 작으면 상기 다중 연결 개수를 증가시키고, 상기 현재 패킷의 도달 시간차가 상기 T2 보다 크면 상기 다중 연결 개수를 감소시키는, 클라이언트 장치.

  24. 제 23 항에 있어서,
    상기 T1은 다중 연결 개수가 증가되는 상태에서 수집한 dPATi 샘플 ω1 중 T1 보다 큰 dPATi를 갖는 샘플의 비율과, 다중 연결 개수가 유지되는 상태에서 수집한 dPATi 샘플 ω2 중 T1보다 작은 dPATi을 갖는 샘플의 비율의 베이즈 에러율(Bayes error rate)이 최소가 되도록 하는 패킷 도달 시간차이고,
    상기 T2는 상기 ω2 중 T2보다 큰 dPATi을 갖는 샘플의 비율과, 다중 연결 개수가 감소되는 상태에서 수집한 dPATi 샘플 ω3 중 T2보다 작은 dPATi을 갖는 샘플의 비율의 베이즈 에러율이 최소가 되도록 하는 패킷 도달 시간차인, 클라이언트 장치.
  25. 제 24 항에 있어서,
    상기
    Figure 112015025991769-pat00070
    이고,
    이 때, 상기
    Figure 112015025991769-pat00071
    , 상기
    Figure 112015025991769-pat00072
    , 상기
    Figure 112015025991769-pat00073
    , 상기
    Figure 112015025991769-pat00074
    이고,
    상기
    Figure 112015025991769-pat00075
    이고,
    이 때, 상기
    Figure 112015025991769-pat00076
    , 상기
    Figure 112015025991769-pat00077
    , 상기
    Figure 112015025991769-pat00078
    , 상기
    Figure 112015025991769-pat00079
    이고,
    상기
    Figure 112015025991769-pat00080
    , 상기
    Figure 112015025991769-pat00081
    이고 상기
    Figure 112015025991769-pat00082
    인, 클라이언트 장치.
  26. 클라이언트에 서비스를 제공하기 위해 다중 연결하는 서버에 있어서,
    적어도 하나의 클라이언트로부터, 상기 적어도 하나의 클라이언트에서 실행된 애플리케이션이 제공하는 서비스 타입에 기초하여 미리 결정된 다중 연결 개수 및 서브 세그먼트 크기에 대한 정보를 포함하는 다중 연결 이력을 수신하는 수신부;
    상기 수신된 다중 연결에 기초하여 상기 적어도 하나의 클라이언트를 분류하고, 상기 다중 연결 이력에 기초하여 상기 클라이언트 별 대표 다중 연결 설정을 결정하는 제어부;
    상기 결정된 대표 다중 연결 설정을 저장하는 저장부; 및
    상기 적어도 하나의 클라이언트로부터, 대표 다중 연결 설정의 전송 요청이 수신되면, 상기 수신된 대표 다중 연결 설정의 전송 요청에 응답하여, 상기 전송 요청이 수신된 대표 다중 연결 설정을 전송하는 전송부;를 포함하는, 서버.
  27. 제 1 항 및 제 3 항 내지 제 13 항 중 어느 한 항에 따른 방법을 실행하기 위한 컴퓨터 프로그램을 기록하는 컴퓨터 판독 가능한 기록 매체.
KR1020150036758A 2015-03-17 2015-03-17 데이터 전송률 향상을 위한 다중 연결 제어 방법 및 장치 KR102078869B1 (ko)

Priority Applications (8)

Application Number Priority Date Filing Date Title
KR1020150036758A KR102078869B1 (ko) 2015-03-17 2015-03-17 데이터 전송률 향상을 위한 다중 연결 제어 방법 및 장치
CN202010994345.9A CN112118177B (zh) 2015-03-17 2015-11-05 用于控制多连接以提高数据传输率的方法和设备
EP15885671.6A EP3261319B1 (en) 2015-03-17 2015-11-05 Method and apparatus for controlling multi-connection for data transmission rate improvement
US15/558,869 US10554727B2 (en) 2015-03-17 2015-11-05 Method and apparatus for controlling multi-connection for data transmission rate improvement
CN201580080076.2A CN107637046B (zh) 2015-03-17 2015-11-05 用于控制多连接以提高数据传输率的方法和设备
PCT/KR2015/011853 WO2016148370A1 (ko) 2015-03-17 2015-11-05 데이터 전송률 향상을 위한 다중 연결 제어 방법 및 장치
EP18205590.5A EP3461107B1 (en) 2015-03-17 2015-11-05 Method and apparatus for controlling multi-connection for data transmission rate improvement
US16/720,983 US10999348B2 (en) 2015-03-17 2019-12-19 Method and apparatus for controlling multi-connection for data transmission rate improvement

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020150036758A KR102078869B1 (ko) 2015-03-17 2015-03-17 데이터 전송률 향상을 위한 다중 연결 제어 방법 및 장치

Publications (2)

Publication Number Publication Date
KR20160111723A KR20160111723A (ko) 2016-09-27
KR102078869B1 true KR102078869B1 (ko) 2020-02-18

Family

ID=56919199

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020150036758A KR102078869B1 (ko) 2015-03-17 2015-03-17 데이터 전송률 향상을 위한 다중 연결 제어 방법 및 장치

Country Status (5)

Country Link
US (2) US10554727B2 (ko)
EP (2) EP3461107B1 (ko)
KR (1) KR102078869B1 (ko)
CN (2) CN107637046B (ko)
WO (1) WO2016148370A1 (ko)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102078869B1 (ko) * 2015-03-17 2020-02-18 삼성전자주식회사 데이터 전송률 향상을 위한 다중 연결 제어 방법 및 장치
GB2537459B (en) * 2015-06-03 2017-06-21 Bridgeworks Ltd Transmitting data
WO2018236261A1 (en) 2017-06-22 2018-12-27 Telefonaktiebolaget Lm Ericsson (Publ) METHOD AND NETWORK NODE FOR ESTABLISHING A WIRELESS CONNECTION
CN110545481B (zh) * 2018-05-29 2021-12-14 北京字节跳动网络技术有限公司 一种媒体播放过程中连接分配方法、装置及存储介质
CN113242436B (zh) * 2020-12-28 2023-01-03 淘宝(中国)软件有限公司 直播数据的处理方法、装置及电子设备
CN115134277B (zh) * 2022-06-24 2023-10-20 山东信通电子股份有限公司 一种动态调整网络连接数的宽带网络速率测试方法及设备

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040133691A1 (en) * 2002-12-10 2004-07-08 Fujitsu Limited Server-load-balancing program, server-load-balancing method, and server-load-balancing apparatus
US20140258365A1 (en) * 2010-10-29 2014-09-11 Israel L'Heureux Enhanced computer networking via multi-connection object retrieval

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6339785B1 (en) 1999-11-24 2002-01-15 Idan Feigenbaum Multi-server file download
US7088720B1 (en) * 2000-08-07 2006-08-08 Sbc Technology Resources, Inc. Multiservice use of network connection capability under user-to-network interface signaling
US20030223450A1 (en) * 2002-05-29 2003-12-04 Bender Paul E. Aggregating multiple air interfaces with a multi-link protocol
CN1324490C (zh) * 2003-07-01 2007-07-04 联想(新加坡)私人有限公司 面向应用的自动连接***和方法
US7486697B2 (en) 2004-05-27 2009-02-03 International Business Machines Corporation Method for negotiating link protocols for link aggregations
US7783194B2 (en) * 2004-12-13 2010-08-24 Ciena Corporation Method and apparatus for provisioning optical services on an optical network
US9065595B2 (en) * 2005-04-07 2015-06-23 Opanga Networks, Inc. System and method for peak flow detection in a communication network
KR100728037B1 (ko) * 2006-03-03 2007-06-14 삼성전자주식회사 무선 데이터 스트리밍 시스템의 파라미터 제어 방법 및장치
US8571473B2 (en) * 2006-06-02 2013-10-29 Qualcomm Incorporated Wireless subscriber station for short range ad-hoc data communication
US7827237B2 (en) * 2007-03-12 2010-11-02 Citrix Systems, Inc. Systems and methods for identifying long matches of data in a compression history
US20120327779A1 (en) * 2009-06-12 2012-12-27 Cygnus Broadband, Inc. Systems and methods for congestion detection for use in prioritizing and scheduling packets in a communication network
JP5504952B2 (ja) * 2010-02-17 2014-05-28 ソニー株式会社 通信装置及び通信方法、並びにコンピューター・プログラム
US8516147B2 (en) * 2010-02-26 2013-08-20 Simula Innovation Sa Data segmentation, request and transfer method
US8386621B2 (en) 2010-03-12 2013-02-26 Netflix, Inc. Parallel streaming
US8719447B2 (en) * 2010-05-04 2014-05-06 Aryaka Networks, Inc. Heterogeneous service provider model through pay-for-performance based transit settlements
US9641447B2 (en) * 2011-01-12 2017-05-02 Telefonaktiebolaget Lm Ericsson (Publ) Adaptive relative bitrate manager for TCP depending flow control
US8862693B2 (en) * 2011-03-11 2014-10-14 Qualcomm Incorporated Remote access and administration of device content and configuration using HTTP protocol
US9052898B2 (en) 2011-03-11 2015-06-09 Qualcomm Incorporated Remote access and administration of device content, with device power optimization, using HTTP protocol
US20130079149A1 (en) * 2011-09-28 2013-03-28 Mediascale Llc Contest application facilitating social connections
US20140136653A1 (en) 2012-02-27 2014-05-15 Qualcomm Incorporated Dash client and receiver with download rate acceleration
US9560011B2 (en) * 2012-02-28 2017-01-31 Raytheon Company System and method for protecting service-level entities
WO2014113919A1 (en) * 2013-01-22 2014-07-31 Broadcom Corporation Addressing communication failure in multiple connection systems
US9241044B2 (en) * 2013-08-28 2016-01-19 Hola Networks, Ltd. System and method for improving internet communication by using intermediate nodes
US8699328B1 (en) * 2013-09-24 2014-04-15 tw telecom holdings, inc. Determining feasibility of a network service using a ring analysis
US20150188949A1 (en) * 2013-12-31 2015-07-02 Lookout, Inc. Cloud-based network security
CN104168123A (zh) * 2014-07-26 2014-11-26 珠海市君天电子科技有限公司 一种数据推送方法、数据服务器、客户端以及***
KR102078869B1 (ko) * 2015-03-17 2020-02-18 삼성전자주식회사 데이터 전송률 향상을 위한 다중 연결 제어 방법 및 장치

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040133691A1 (en) * 2002-12-10 2004-07-08 Fujitsu Limited Server-load-balancing program, server-load-balancing method, and server-load-balancing apparatus
US20140258365A1 (en) * 2010-10-29 2014-09-11 Israel L'Heureux Enhanced computer networking via multi-connection object retrieval

Also Published As

Publication number Publication date
EP3261319A4 (en) 2018-03-07
CN112118177B (zh) 2022-06-07
EP3261319A1 (en) 2017-12-27
CN112118177A (zh) 2020-12-22
EP3461107A1 (en) 2019-03-27
US10554727B2 (en) 2020-02-04
US20180077217A1 (en) 2018-03-15
CN107637046A (zh) 2018-01-26
CN107637046B (zh) 2020-10-20
US20200128064A1 (en) 2020-04-23
EP3461107B1 (en) 2020-06-10
WO2016148370A1 (ko) 2016-09-22
KR20160111723A (ko) 2016-09-27
EP3261319B1 (en) 2019-03-27
US10999348B2 (en) 2021-05-04

Similar Documents

Publication Publication Date Title
KR102078869B1 (ko) 데이터 전송률 향상을 위한 다중 연결 제어 방법 및 장치
US10574586B2 (en) Method and system for self-adaptive bandwidth control of CDN platform
US8887217B2 (en) Systems and methods for quality of experience aware joint scheduling of buffered video on demand and best effort flows
EP3103220B1 (en) System and method for dynamic effective rate estimation for real-time video traffic
KR20140073546A (ko) 자원 할당을 최적화함으로써 적응 스트리밍 비디오 품질의 개선
Zhao et al. Buffer data-driven adaptation of mobile video streaming over heterogeneous wireless networks
CN110769512B (zh) 星载资源分配方法、装置、计算机设备及存储介质
Chang et al. Edge-assisted adaptive video streaming with deep learning in mobile edge networks
Taha et al. SDN-based throughput allocation in wireless networks for heterogeneous adaptive video streaming applications
Abuteir et al. SDN based architecture to improve video streaming in home networks
US10581944B2 (en) Transmission resource distribution for streaming of variable bitrate encoded media data
Kim et al. XMAS: An efficient mobile adaptive streaming scheme based on traffic shaping
Hoßfeld et al. Can context monitoring improve QoE? A case study of video flash crowds in the internet of services
Zahran et al. SAP: Stall-aware pacing for improved DASH video experience in cellular networks
Bronzino et al. Exploiting network awareness to enhance DASH over wireless
Ahmad et al. Towards information-centric collaborative QoE management using SDN
Vergados et al. Evaluation of HTTP/DASH adaptation algorithms on vehicular networks
JP2016143980A (ja) 帯域割り当て制御装置及び帯域割り当て制御方法
Hiraoka et al. A Progressive Download Method Using Multiple TCP Flows on Multiple Paths
US10292164B2 (en) Method and apparatus for optimization of video transmissions
Tosic et al. Soft sensors in wireless networking as enablers for SDN based management of content delivery
Mehrabi et al. Cache-aware QoE-traffic optimization in mobile edge assisted adaptive video streaming
Khan et al. Bandwidth Estimation Techniques for Relative'Fair'Sharing in DASH
Triki et al. Anticipating resource management and QoE for mobile video streaming under imperfect prediction
Du et al. Integrated bandwidth variation pattern differentiation for HTTP adaptive streaming over 4G cellular networks

Legal Events

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