KR20210015955A

KR20210015955A - 동적 채널 본딩을 위한 시스템 및 방법

Info

Publication number: KR20210015955A
Application number: KR1020207037944A
Authority: KR
Inventors: 윌리엄 웨이예 초우; 마크 리 쯔이예; 브라이언 알렉스 트룽
Original assignee: 모보파일스 인코포레이티드 디비에이 모보라이즈
Priority date: 2018-05-31
Filing date: 2019-05-31
Publication date: 2021-02-10
Also published as: CN112205036A; AU2019279102A1; US11012908B2; US20210235349A1; EP3815432A1; US11937141B2; CA3101843A1; JP7209745B2; EP3815432C0; EP3815432B1; WO2019232497A1; US20190373526A1; EP3815432A4; CN112205036B; KR102457792B1; JP2021525985A; WO2019232497A8

Abstract

프로세서, 메모리, 및 복수의 네트워크에 연결하도록 구성된 복수의 네트워크 인터페이스를 포함하는 휴대용 통신 장치에서 네트워크 트래픽을 관리하는 방법은, 프로세서에서 실행중인 애플리케이션의 네트워크 트래픽을, 복수의 네트워크 중에서, 프로세서 상에서 실행되는 운영 체제에 의해 기본 네트워크로 지정된 1차 네트워크를 통해 처리하는 단계; 1차 네트워크와 연관된 복수의 네트워크 상태 정보를 모니터링하는 단계; 수신된 네트워크 상태 정보의 하나 이상의 파라미터가 하나 이상의 임계값 밖에 있을 때 1차 네트워크의 문제를 감지하는 단계; 1차 네트워크의 문제를 감지하는 것에 응답하여, 복수의 네트워크 중 2차 네트워크를 기본 네트워크로서 선택하는 단계; 및 네트워크 트래픽을, 기본 네트워크로서 업데이트된 2차 네트워크를 통해 처리하는 단계를 포함한다.

Description

동적 채널 본딩을 위한 시스템 및 방법

CROSS-REFERENCE TO RELATED APPLICATIONS

본 출원은 2018년 5월 31일자로 미국 특허청에 제출된 미국 특허 가출원 제62/678,810호의 이익을 주장하며, 그 전체 개시 내용은 본 출원에 참조로 포함된다.

본 발명의 실시예의 여러 측면은 컴퓨터 네트워킹 분야에 관한 것이다.

연결 본딩(connection bonding) 또는 링크 통합(link aggregation)은 여러 네트워크 연결을 결합 또는 통합하는 방법과 관련된다.

어떤 네트워크 상태에서 컴퓨팅 장치가 네트워크 도달의 가용 범위에 가깝거나 벗어나거나 네트워크 용량의 가용 한계에 가깝거나 벗어나는 경우와 같이 컴퓨팅 장치의 네트워크 연결이 좋지 않을 수 있다. 예를 들어, 무선 근거리 통신망 또는 WLAN(예를 들어, Wi-Fi 네트워크)에 연결된 스마트 폰이 무선 네트워크의 유효 범위 가장자리로 이동한 경우(예를 들어 집의 진입로에 있는 자동차에 앉아 있는 경우), 스마트 폰은 일반적으로 무선 네트워크 연결이 좋지 않은 경우에도 셀룰러 연결로 전환하는 대신 무선 네트워크를 통해 데이터를 계속 전송하고 요청하려고 한다. 이로 인해 셀룰러 네트워크 신호가 강한 경우에도 사용자가 로컬 무선 네트워크의 가장자리에 있을 때 일시적으로 네트워크 연결이 끊어지는 등 사용자 경험이 좋지 않을 수 있다. 또 다른 예로는 바쁜 커피숍의 혼잡한 Wi-Fi 네트워크나 스포츠 경기 중 경기장에서 처리할 수 있는 것보다 많은 트래픽이 있는 무선 네트워크에 스마트 폰이 연결된 경우이다. 이로 인해 인터넷 콘텐츠에 액세스하려고 할 때 행 또는 타임아웃과 같은 열악한 사용자 경험이 발생할 수 있다.

WLAN 연결의 예들은 Wi-Fi로도 알려진 IEEE 802.11 표준에 기반한 것들과 같은 네트워크를 포함한다. 셀룰러 네트워크 연결의 예들은 3G 무선 셀룰러 네트워크(때때로 Universal Mobile Telecommunications Service 또는 UMTS, Global Systems for Mobile 또는 GSM 및 Code Division Multiple Access 2000 또는 CDMA2000으로 불림) 또는 4G 무선 셀룰러 네트워크(예를 들어, 때때로, Long Term Evolution Advanced 또는 LTE Advanced로 불림) 등을 포함한다.

Wi-Fi와 같은 다른 유형의 네트워크에 연결하는 데 있어서, 성능(예를 들어, 셀룰러 연결보다 느릴 수 있음), 접근성(예를 들어, 인터넷 액세스를 허용하기 전에 로그인해야 할 수 있음) 또는 품질(예를 들어, 더 나은 신호 또는 성능을 가진 다른 액세스 포인트가 있을 수 있음)과 같은 추가적인 문제가 있다. 일반적으로 이러한 문제는 장치(장치에서 실행되는 소프트웨어 포함)에 의해 잘 처리되지 않거나 전혀 처리되지 않으므로 사용자는 장치에서 Wi-Fi를 비활성화하거나 연결 해제하여 수동으로 장치가 셀룰러 연결을 사용하도록 하는 등, 이러한 연결을 자주 수동으로 관리해야 한다. 이로 인해 사용자 환경이 매우 열악해지고(예를 들어, 사용자가 Wi-Fi를 다시 켜야 하는 시기를 기억해야 함) 사용자 모두(예를 들어, 사용자가 데이터 요금제를 사용하는 경우) 또는 모바일 네트워크 사업자에게(예를 들어, 사용자가 무제한 데이터 요금제를 사용하는 경우) 더 높은 셀룰러 비용과 같은 추가 결과가 발생한다.

또한, 장치들은 블루투스와 같은 다른 네트워크 유형 또는 미래에 가능한 네트워크 유형에 연결할 수 있으며, 이들 중에서 임의의 것이 에지(edges)에서 유사한 문제를 일으킬 수 있다. 일반적으로 장치가 연결할 수 있는 서로 다른 이기종 네트워크가 여러 개 있는 경우 장치가 사용 가능한 각 네트워크를 사용하는 방법과 시기에 도전(Challenges)이 있다.

장치에 이용 가능한 복수의 가능한 이기종 네트워크 사용을 관리하는 이슈와 관련하여 이들을 해결하는 데 다른 관련 접근법이 소개되었다. 사용자가 수동으로 제어할 수 있도록 사용자 인터페이스(UI) 설정을 제공하는 것부터 네트워크 연결을 자동화하기 위한 소프트웨어 기반 접근 방식(예를 들어, Passpoint® for Wi-Fi), 사용 가능한 여러 네트워크를 제어하는 방법과 시기에 이르기까지(예를 들어, 다중 경로 TCP) 다양하다.

예를 들어, 일부 비교 네트워크 프로토콜은, 여러 가용 네트워크에서 교차된 네트워크 트래픽을 분할한 다음, 연관된 중개자를 사용하여 분할된 트래픽 다운스트림을 재결합하여 아마도 더 높은 성능(예를 들어, 셀룰러 및 Wi-Fi 네트워크를 통해 동시에 데이터의 부하를 분산시킴으로써) 및 더 높은 복원력을 가능하게 함으로써(예를 들어, 손실된 Wi-Fi 패킷을 셀룰러 네트워크로 재시도/재전송함으로써) 다중 경로 TCP(MPTCP, Multipath TCP)와 같은 다중 네트워크를 동시에 활용하도록 설계되었다. 클라이언트에서 트래픽을 분할한 다음 트래픽을 재결합하기 위해 서버(또는 이와 동등한 중개자) 다운스트림을 갖는 통합 클라이언트-서버 모델을 따르는 독점 프로토콜을 포함하여 수년에 걸쳐 개발된 이러한 네트워크 프로토콜이 많이 있다. 그러나 이러한 접근 방식은 모든 장치 트래픽이 중개자를 통해 전달되는 것을 요구하는데, 이는 상당한 영향(예를 들어, 높은 운영 비용)을 미칠 수 있다. 이 비용은 일반적으로 모바일 네트워크 사업자(MNO, mobile network operator)와 같이 장치가 사용하는 네트워크 중 하나의 네트워크 사업자가 부담하며, 여기서 추가 비용은, 사용자의 기기가 Wi-Fi 네트워크에 연결되어 있는 동안 MNO가 이전에 처리할 필요가 없었던, 새 서버 및 추가 대역폭(예를 들어, Wi-Fi 트래픽)을 포함한다.

애플리케이션이 다중 네트워크를 인식하여 애플리케이션이 동시에 (부하 분산을 통한 성능을 위해) 또는 선택적으로 (작동하지 않는 하나의 네트워크에 대한 복원력을 위해) Wi-Fi 및/또는 셀룰러를 통해 트래픽을 전달하도록 하는 또 다른 비교 접근법이 취해졌다. 예를 들어 Samsung® Download Booster는 셀룰러 및 Wi-Fi에서 부하 분산을 통해 대용량 파일(> 30MB) 다운로드 속도를 높일 수 있다. 그러나 이 접근 방식은 웹 브라우저와 같은 특정 앱에서 수행하는 파일 다운로드에만 특별히 사용되기 때문에 다양한 애플리케이션에서 네트워크 성능을 전반적으로 향상시키기 위해 확장되지 않는다(예를 들어, 이 접근 방식은 웹 브라우징 또는 비디오 시청을 개선하지 않음). 이러한 접근 방식은 또한 각 네트워크의 동적으로 변화하는 성능 특성을 기반으로 사용 가능한 네트워크 간의 부하를 동적으로 조정하는 인식이 부족하다. 또 다른 비교 예는 Apple® iOS의 Wi-Fi 지원 기능으로, Wi-Fi가 응답하지 않음을 감지하면 앱이 셀룰러를 사용하도록 전환할 수 있다. 그러나 이 구현에는 어떤 네트워크가 실제로 응답하는지 빠르고 원활하게(예를 들어, 거의 실시간으로) 감지할 수 있는 기능이 없기 때문에 Wi-Fi에서 셀룰러로 전환하기 전에 행 또는 타임아웃과 같은 네트워크 요청이 필요하다. 또한 Apple® Wi-Fi Assist 기능은 사용자 또는 MNO가 얼마나 많은 셀룰러 데이터가 사용되는지를 제어할 수 있는 정책 제어가 없기 때문에 "포어그라운드(foreground)" 앱(즉, 사용자가 현재 상호 작용하고 있는 포어그라운드에서 실행중인 애플리케이션)으로 제한된다.

본 발명에 따른 실시예의 측면은 네트워크 연결을 개선하기 위해 컴퓨팅 장치에서 다중 네트워크 연결을 자동으로 관리하기 위한 시스템 및 방법에 관한 것이다.

본 발명의 일 실시예에 따르면, 프로세서, 메모리 및 복수의 네트워크에 연결되도록 구성된 복수의 네트워크 인터페이스를 포함하는 휴대용 통신 장치에서 네트워크 트래픽 관리 방법은, 상기 프로세서에서 실행되는 트래픽 관리자에 의해, 상기 프로세서에서 실행되는 애플리케이션에 송신 및 수신의 네트워크 데이터를 인터셉트하는 단계; 상기 트래픽 관리자에 의해, 상기 네트워크 데이터의 멱등성(冪等性, idempotent) 요청을 상기 복수의 네트워크를 통해 서버로 전송하는 단계; 상기 트래픽 관리자에 의해, 상기 복수의 네트워크 상의 1차 네트워크(first network)를 통해 상기 서버로부터 상기 멱등성 요청에 대한 응답을 수신하는 단계; 및 상기 트래픽 관리자에 의해, 상기 복수의 네트워크 중에서, 상기 응답의 수신 및 상기 애플리케이션에 송신에 사용할 상기 1차 네트워크를 선택하는 단계를 포함한다.

상기 멱등성 요청을 상기 복수의 네트워크를 통해 서버로 전송하는 단계는, 상기 복수의 네트워크 중에서 2차 네트워크(second network)에서 멱등성 요청을 전송하는 것을 포함할 수 있으며, 상기 방법은 2차 네트워크에서 멱등성 요청을 종료하는 단계를 더 포함할 수 있다.

상기 멱등성 요청을 상기 복수의 네트워크를 통해 서버로 전송하는 단계는, 상기 복수의 네트워크 중에서 하나의 네트워크를 통해 상기 멱등성 요청을 상기 서버로 전송하는 단계; 및 지연에 따라 상기 복수의 네트워크 중에서 하나 이상의 다른 네트워크를 통해 상기 멱등성 요청을 상기 서버로 전송하는 단계를 포함할 수 있다.

상기 지연은 상기 휴대용 통신 장치에서 실행되는 상기 애플리케이션의 애플리케이션 레벨의 타임아웃보다 짧을 수 있다.

상기 지연은 상기 멱등성 요청에 대한 일반적인 응답 시간을 기반으로 설정될 수 있다.

상기 멱등성 요청은 네트워크 프로토콜과 연관될 수 있고, 상기 지연은 상기 멱등성 요청과 연관된 상기 네트워크 프로토콜에 기반하여 설정될 수 있다.

상기 지연은 상기 멱등성 요청에 대한 응답의 크기에 기반하여 설정될 수 있다.

상기 지연은 네트워크 품질 메트릭에 기반하여 설정될 수 있다.

상기 복수의 네트워크는 선호도 순위로 배열될 수 있고, 상기 하나 이상의 다른 네트워크는 선호도 순위에 따라 선택될 수 있다.

각각의 네트워크는 선호도 순위에 따라 상이한 지연과 연관될 수 있다.

상기 방법은 하나 이상의 동적 인자에 따라 상기 선호도 순위에서 상기 복수의 네트워크를 재배열하는 단계를 더 포함할 수 있다.

상기 하나 이상의 동적 인자는 네트워크 성능을 포함할 수 있다.

상기 하나 이상의 동적 인자는 네트워크 트래픽 비용을 포함할 수 있다.

상기 복수의 네트워크는 복수의 상이한 유형의 네트워크를 포함할 수 있다.

상기 네트워크의 유형은, 셀룰러, 블루투스 및 Wi-Fi 네트워크 중에서 하나 이상을 포함할 수 있다.

본 발명의 일 실시예에 따른, 프로세서, 메모리 및 복수의 네트워크에 연결되도록 구성된 복수의 네트워크 인터페이스를 포함하는 휴대용 통신 장치에서 네트워크 트래픽 관리 방법은, 상기 복수의 네트워크 중에서, 상기 프로세서에서 실행되는 운영 체제에 의해 기본 네트워크(primary network)로 지정된, 1차 네트워크(first network)를 통해 상기 프로세서 상에서 실행중인 애플리케이션의 네트워크 트래픽을 처리하는 단계; 상기 1차 네트워크와 연관된 복수의 네트워크 상태 정보를 모니터링하는 단계; 수신된 네트워크 상태 정보의 하나 이상의 파라미터가 하나 이상의 임계값 밖에 있을 때 1차 네트워크의 문제를 감지하는 단계; 1차 네트워크(first network)에서 문제를 감지하는 것에 응답하여, 복수의 네트워크 중에서 2차 네트워크(second network)를 상기 기본 네트워크로서 선택하는 단계; 및 업데이트된 기본 네트워크로서 2차 네트워크를 통해 상기 네트워크 트래픽을 처리하는 단계를 포함한다.

상기 네트워크 트래픽은 요청 및 상기 요청에 대한 응답을 포함할 수 있으며, 상기 1차 네트워크에서 상기 문제는 요청의 타임 스탬프와 최대 임계값을 초과하는 응답의 타임 스탬프 사이의 응답 시간에 기반하여 감지된다.

상기 1차 네트워크에서 상기 문제를 감지하는 단계는, 상기 1차 네트워크 상에서 적어도 하나의 네트워크 통계를 모니터링하는 단계; 및 네트워크 통계의 변화가 임계값을 초과할 때 문제를 감지하는 단계를 포함할 수 있다.

상기 네트워크 통계는 패킷 손실률 또는 불량 패킷율을 포함할 수 있다.

상기 1차 네트워크는 무선 네트워크일 수 있고, 상기 1차 네트워크에서 문제를 감지하는 단계는, 무선 네트워크의 신호 강도를 모니터링하는 단계; 및 상기 신호 강도가 임계 신호 강도 아래로 떨어질 때 상기 문제를 감지하는 단계를 포함할 수 한다.

상기 복수의 네트워크 중에서 상기 2차 네트워크는 상기 복수의 네트워크의 선호도 순위에 따라 선택될 수 있다.

상기 1차 네트워크에서 상기 문제는 상기 1차 네트워크에서 응답이 수신되기 전에 다른 네트워크에서 수신된 응답에 기반하여 감지될 수 있다.

본 발명의 일 실시예에 따른 휴대용 통신 장치는, 프로세서, 메모리 및 복수의 네트워크에 연결하도록 구성된 복수의 네트워크 인터페이스를 포함하며, 상기 메모리는, 상기 프로세서에 의해 실행될 때, 상기 프로세서가 상기 휴대용 통신 장치의 네트워크 트래픽을 관리하게 하는 명령어로서, 상기 프로세서에서 실행되는 트래픽 관리자에 의해, 상기 프로세서에서 실행되는 애플리케이션에 송신 및 수신의 네트워크 데이터를 인터셉트 하는 단계; 상기 트래픽 관리자에 의해, 상기 네트워크 데이터의 멱등성 요청을 상기 복수의 네트워크를 통해 서버로 전송하는 단계; 상기 트래픽 관리자에 의해, 상기 복수의 네트워크상의 1차 네트워크를 통해 상기 서버로부터 상기 멱등성 요청에 대한 응답을 수신하는 단계; 및 상기 트래픽 관리자에 의해, 상기 복수의 네트워크 중에서, 상기 애플리케이션에 대한 응답의 수신 및 상기 애플리케이션에 송신에 사용할 상기 1차 네트워크를 선택하는 단계에 의한 명령어를 저장한다.

상기 멱등성 요청을 상기 복수의 네트워크를 통해 상기 서버로 전송하는 단계는, 상기 복수의 네트워크 중에서 2차 네트워크를 통해 상기 멱등성 요청을 전송하는 단계를 포함할 수 있으며, 상기 명령어는 상기 프로세서가, 상기 2차 네트워크에서 상기 멱등성 요청을 종료하게 하는 명령어를 더 포함할 수 있다.

상기 멱등성 요청을 상기 복수의 네트워크를 통해 상기 서버로 전송하는 단계는, 상기 복수의 네트워크 중에서 하나의 네트워크를 통해 상기 멱등성 요청을 상기 서버로 전송하는 단계; 및 지연에 따라 상기 복수의 네트워크 중에서 하나 이상의 다른 네트워크를 통해 상기 멱등성 요청을 상기 서버로 전송하는 단계를 포함할 수 있다.

상기 지연은 상기 휴대용 통신 장치에서 실행되는 상기 애플리케이션의 애플리케이션 레벨 타임아웃보다 짧을 수 있다.

상기 지연은 상기 멱등성 요청에 대한 일반적인 응답 시간에 기반하여 설정될 수 있다.

상기 멱등성 요청은 네트워크 프로토콜과 연관될 수 있고, 그리고 상기 지연은 상기 멱등성 요청과 연관된 상기 네트워크 프로토콜에 기반하여 설정될 수 있다.

상기 복수의 네트워크는 선호도 순위로 배열될 수 있고, 그리고 상기 하나 이상의 다른 네트워크는 선호도 순위에 따라 선택될 수 있다.

상기 메모리는 상기 프로세서에 의해 실행될 때 상기 프로세서가, 하나 이상의 동적 인자에 따라 상기 선호도 순위에서 상기 복수의 네트워크를 재배열하게 하는 명령어를 더 저장할 수 있다.

상기 네트워크의 유형은 셀룰러, 블루투스 및 Wi-Fi 네트워크 중에서 하나 이상을 포함할 수 있다.

본 발명의 일 실시예에 따르면, 휴대용 통신 장치는 프로세서, 메모리 및 복수의 네트워크에 연결되도록 구성된 복수의 네트워크 인터페이스를 포함하며, 상기 메모리는, 상기 프로세서에 의해 실행될 때, 상기 프로세서가 상기 휴대용 통신 장치의 네트워크 트래픽을 관리하게 하는 명령어로서, 상기 복수의 네트워크 중에서, 상기 프로세서에서 실행되는 운영 체재에 의해 기본 네트워크로 지정된, 1차 네트워크를 통해 상기 프로세서에서 실행중인 애플리케이션의 네트워크 트래픽을 처리하는 단계; 상기 1차 네트워크와 연관된 복수의 네트워크 상태 정보를 모니터링하는 단계; 수신된 네트워크 상태 정보의 하나 이상의 파라미터가 하나 이상의 임계값 밖에 있을 때 상기 1차 네트워크의 문제를 감지하는 단계; 상기 1차 네트워크에서 상기 문제를 감지하는 것에 응답하여, 복수의 네트워크 중에서 2차 네트워크를 상기 기본 네트워크로서 선택하는 단계; 및 업데이트된 기본 네트워크로서, 상기 2차 네트워크를 통해 상기 네트워크 트래픽을 처리하는 단계에 의한 명령어를 저장한다.

상기 네트워크 트래픽은 요청 및 상기 요청에 대한 응답을 포함할 수 있으며, 상기 1차 네트워크에서 상기 문제는 요청의 타임 스탬프와 최대 임계값을 초과하는 응답의 타임 스탬프 사이의 응답 시간에 기반하여 감지될 수 있다.

상기 1차 네트워크에서 문제를 감지하기 위한 명령어는 상기 프로세서에 의해 실행될 때 상기 프로세서가, 상기 1차 네트워크에서 적어도 하나의 네트워크 통계를 모니터링하게 하고; 그리고 네트워크 통계의 변경이 임계값을 초과할 때 문제를 감지하게 하는 명령어를 포함할 수 있다.

상기 1차 네트워크는 무선 네트워크일 수 있고, 상기 1차 네트워크에서 상기 문제를 감지하는 단계는 무선 네트워크의 신호 강도를 모니터링하는 단계; 및 신호 강도가 임계 신호 강도 아래로 떨어질 때 상기 문제를 감지하는 단계를 포함할 수 있다.

본 발명의 실시예 측면은 활성 요청 카운트에 기초하여 다른 네트워크에 요청을 전송함으로써 개선된 성능을 제공하는 것에 관한 것으로, 다른 네트워크 사이의 활성 요청의 비율에 기초하여 부하를 분배하는 단계; 대기 시간 및 대역폭을 포함하는 요인에 기초한 활성 요청 비율을 동적으로 조정하는 단계; 아웃 바운드/요청 데이터의 존재를 통해 새로운 활성 요청을 감지하고 마지막 인바운드/응답 데이터 이후 충분히 긴 지연이 있는 경우라면 요청 완료를 포함하여, 암호화된 트래픽의 활성 요청을 감지하고 추적하는 단계를 포함한다.

본 발명의 일 실시예에 따르면, 컴퓨터 프로세서 및 컴퓨터 서버로 데이터를 송수 또는 수신하기 위한 복수의 네트워크 인터페이스를 갖는 휴대용 통신 장치에서 네트워크 트래픽 관리 방법은, 트래픽 관리자 애플리케이션에 의해, 1차 애플리케이션에 송신 또는 수신의 상기 1차 데이터의 전자 트래픽을 인터셉트하는 단계; 상기 트래픽 관리자 애플리케이션에 의해, 각 네트워크 인터페이스에 대한 활성 데이터 요청 또는 응답의 수를 추적하는 단계; 및 트래픽 관리자 애플리케이션에 의해, 활성 데이터 교환의 수에 기반하여 1차 애플리케이션에 송신 또는 수신 또는 서버에 송신 또는 수신의 1차 데이터의 전달에 사용할 네트워크 인터페이스를 선택하는 단계를 포함한다.

본 발명의 일 실시예에 따르면, 프로세서, 메모리 및 복수의 네트워크에 연결하도록 구성된 복수의 네트워크 인터페이스를 포함하는 휴대용 통신 장치에서 트래픽을 관리하는 방법은, 프로세서 상에서 실행되는 트래픽 관리자에 의해, 프로세서에서 실행되는 응용 프로그램에 송신 그리고 수신의 네트워크 데이터를 인터셉트하는 단계; 트래픽 관리자에 의해, 복수의 네트워크를 통해 전송되는 복수의 요청을 서버로 전송하는 단계; 트래픽 관리자에 의해, 각 네트워크 인터페이스와 연관된 다수의 활성 데이터 요청을 추적하는 단계; 및 트래픽 관리자에 의해, 네트워크 데이터를 서버로 전송하고 네트워크 인터페이스와 연관된 복수의 활성 데이터 요청에 따라 서버로부터 네트워크 데이터를 수신하기 위한 복수의 네트워크 인터페이스의 네트워크 인터페이스를 선택하는 단계를 포함한다.

복수의 네트워크 중 하나는 기본 네트워크로 지정될 수 있고, 네트워크 인터페이스를 선택하는 단계는, 기본 네트워크와 연관된 임계값을 초과하는 활성 데이터 요청의 수를 결정하는 단계 및 활성 데이터 요청의 수가 임계값을 초과하지 않는 복수의 네트워크 중에서 다른 네트워크에 대응하는 네트워크 인터페이스를 선택하는 단계를 포함할 수 있다.

복수의 네트워크 인터페이스 중에서 네트워크 인터페이스를 선택하는 단계는, 복수의 네트워크 인터페이스 중에서 2차 네트워크 인터페이스를 선택하는 단계; 네트워크 인터페이스와 연관된 활성 데이터 요청의 수에 따라 활성 요청의 비율을 계산하는 단계; 및 2차 네트워크 인터페이스와 연관된 다수의 활성 데이터 요청; 및 활성 요청의 비율에 따라 네트워크 인터페이스와 2차 네트워크 인터페이스 사이에 네트워크 데이터의 네트워크 트래픽을 분배하는 단계를 포함할 수 있다.

상기 방법은 복수의 네트워크의 복수의 네트워크 조건에 따라 활성 요청의 비율을 동적으로 조정하는 단계를 더 포함할 수 있다.

네트워크 조건은 복수의 네트워크에 대응하는 지연 측정을 포함할 수 있다.

네트워크 조건은 복수의 네트워크에 대응하는 최대 대역폭 측정을 포함할 수 있다.

상기 방법은, 네트워크 인터페이스와 연관된 1차 네트워크 또는 2차 네트워크 인터페이스와 연관된 2차 네트워크가 응답하지 않는 네트워크인 경우를 감지하는 단계 및 응답하지 않는 네트워크를 삭제하는 단계를 더 포함할 수 있다.

본 발명의 실시예의 측면은, 본딩(예를 들어, 더블탭(doubletap) 또는 부하 분산)이 기본/디폴트 네트워크의 성능 저하를 감지할 때 다른 네트워크로의 전환; 더블탭에 기초한 다른 네트워크로의 전환(예를 들어, 기본 네트워크가 꺼지는 경우); 부하 분산에 기초한 다른 네트워크로의 전환(예를 들어, 활성 요청이 현재 기본 네트워크에서 충분히 빠르게 완료되지 않을 때)을 포함하는 연결 관리에 관한 것이다.

첨부된 도면은 발명의 설명과 함께 본 발명의 예시적인 실시예를 도시하고, 설명과 함께 본 발명의 원리를 설명하는 역할을 한다.
도 1은 본 발명의 일 실시예에 따른 온-디바이스 채널 본딩 구현과 함께 사용하기에 적합한 스마트 폰과 같은 예시적인 휴대용 통신 장치 아키텍처의 개략도이다.
도 2는 본 발명의 일 실시예에 따른 앱과 서버 간의 네트워크 트래픽을 모니터링하고 제어할 수 있게 하는 프록시 내의 소프트웨어 구성 요소의 블록도이다.
도 3은 본 발명의 일 실시예에 따른 기본 네트워크의 설정 방법을 설명하는 상위 레벨 흐름도이다.
도 4는 본 발명의 일 실시예에 따른 네트워크 액세스를 제어하기 위해 사전 신호를 활용하기 위한 방법을 묘사하는 상위 레벨 흐름도이다.
도 5는 본 발명의 일 실시예에 따른 부하 분산 접근법의 예시적인 방법을 묘사하는 상위 레벨 흐름도이다.
도 6은 각각이 양호한 신호 품질 영역을 나타내는 내부 녹색 원형 영역과 불량한 신호 품질 영역(즉, Wi-Fi 데드 존)을 나타내는 외부 빨간색 원형 영역이 있는 여러 Wi-Fi 네트워크를 갖는 지역의 예를 보여주는 도면이다.
도 7은 도 6과 동일하나, 본 발명의 실시예에 따른 기술을 활용하는 예를 보여주는 도면이다.

다음의 상세한 설명에서, 본 발명의 특정 예시적인 실시예만이 예시로서 도시되고 설명된다. 당업자가 인식하는 바와 같이, 본 발명은 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시예에 한정되는 것으로 해석되어서는 안된다.

모바일 네트워킹의 한 가지 과제는 이종 네트워크의 경우와 같이 서로 다른 네트워크 간의 핸드 오프(handoff)가 종종 원활하지 않다는 것이다. 이기종 네트워크의 사용은 일반적으로 Wi-Fi와 셀룰러 간 전환과 같이 모바일 장치에서 지원하는 다른 유형의 네트워크 간에 전환할 때 발생한다. 예를 들어, 모바일 기기가 Wi-Fi 네트워크에 참여되고/연결되면 Wi-Fi 신호가 안정적인 통신에 사용되기에 너무 약하거나(불량한 경우에도), Wi-Fi를 사용하려는 모든 시도가 실패할 때까지(예를 들어, 오랜 시간 초과 후) Wi-Fi를 사용할 수 없음을 감지하기 어렵기 때문에, 기기는 Wi-Fi 네트워크에 유지되고 네트워크 통신에 이를 사용한다. 이 상태는, 장치가 여전히 사용될 수 없는 네트워크에 연결되고, 사용(또는 사용을 시도)하기 때문에 인터넷 연결이 없는 상태인, "데드 존(dead zone)"으로 알려져 있다. 이 문제는 동일한 유형의 네트워크 간에 전환할 때도 발생하는, 이는 이러한 네트워크 간에 종종 조정이 없는 경우가 있기 때문이다. 예를 들어, 장치가 한 Wi-Fi 네트워크의 데드 존에 있지만 범위 내에 더 좋고 사용 가능한 다른 Wi-Fi 네트워크가 있는 경우 이들 Wi-Fi 네트워크 간의 일종의 명시적인 조정 없이는 장치가 다른 Wi-Fi 네트워크로 전환되지 않는다. 이러한 Wi-Fi 네트워크 간에 명시적 조정의 예로는 일반적으로 회사에서 운영하고 IEEE 802.11r 또는 802.11v와 같은 핸드 오프 기술을 활용하는 여러 Wi-Fi 액세스 포인트가 있는 "엔터프라이즈" 메시 네트워크가 있다. 그러나, 사용자는 서로를 인식하지 못하는(예를 들어, 협력하지 않는) 하나 이상의 겹치거나 인접하는 Wi-Fi 네트워크가 있을 수 있는 공용 공간과 같이 관련 없는 Wi-Fi 네트워크를 사용하는 경우가 많으므로, 그들 사이에 장치를 사전에 전달할 수 없다. 즉, 이는 원활한 핸드 오프를 방해하는 이기종 네트워크의 또 다른 사례이다.

다수의 네트워크에 걸쳐 부하를 분산시키는 한 가지 과제는 각 네트워크가 상이한 성능 특성을 가질 때 최적의 부하 분포를 결정하는 것이다. 예를 들어, 단순한 부하 분산 정책은 전체 성능이 가장 느린 경로에 의해 결정되기 때문에 성능이 향상되지 않는 경우가 많다. 아래의 표 1에서 Wi-Fi 네트워크의 속도가 40 mbps이고 셀룰러 네트워크의 속도가 20 mbps라고 가정한다. 이 표는 더 빠른 Wi-Fi 연결과 느린 셀룰러 연결 사이의 다양한 부하 분산을 이용하여 40 MB 파일과 100 MB를 다운로드하는 데 소요된 시간에 대한 다양한 계산을 보여준다:

Wi-Fi 속도	셀 속도	파일 크기	부하 분산(LB) %	경과 시간
40 mbps (5 MB/s)	20 mbps (2.5 MB/s)	40 MB	100% Wi-Fi	8 s
			50/50: 20 MB on Wi-Fi = 4 s 20 MB on cell = 8 s	8 s
			비율:27 MB on Wi-Fi = 5.4 s 13 MB on cell = 5.2 s	5.2 s
		100 MB	100% Wi-Fi	20 s
			50/50: 50 MB on Wi-Fi = 10 sec 50 MB on cell = 20 sec	20 s
			속도비율:67 MB on Wi-Fi =13.4 s 33 MB on cell = 13.2 s	일 크기13.4 s

표 1은 실제 성능 이득을 달성할 수 있도록 가용 네트워크의 상대적 성능에 비례하여 부하를 분산하는 것이 바람직함을 보여주며, 예를 들어, 셀룰러 네트워크보다 두 배 빠른 Wi-Fi 네트워크는 총 대기 시간을 크게 줄이기 위해 두 배의 트래픽을 가져가야 한다.

그러나, 클라이언트 장치가, 네트워크가 처리할 수 있는 것보다 더 많은 네트워크 부하를 생성하려는 시도는 웹 페이지 검색과 같은 정상적인 사용 중에는 거의 발생하지 않는데, 이러한 시도 없이는, 클라이언트가, 네트워크가 용량에 도달했는지를 판단하기가 어렵기 때문에, 여러 네트워크에 걸쳐 부하를 적절하게 분배하는 데 있어 한 가지 문제는 이것이 실제로 필요한 시점을 결정하는 것이다. 네트워크의 용량 한도에 도달했는지 확인하는 몇 가지 방법은 총 대역폭 속도가 더 이상 증가하지 않을 때까지 대규모 테스트 파일의 여러 동시 다운로드를 지속적으로 추가하는 "속도 테스트"를 통해 테스트 트래픽을 생성하는 것이다. 그러나 이 접근 방식은 불필요한 추가 부하(배터리 수명 또는 네트워크 사용에 영향을 줄 수 있음)를 생성하고 사용자의 활동을 방해/경쟁할 수 있으며 추가 네트워크 사용 비용을 추가할 수 있으므로 (예를 들어, 종량제 네트워크) 일반적인 사용자 활동 중에 적용될 수 없다. 또한 이 기술은 사용 가능한 네트워크 용량의 동적 변화(예를 들어, 동일한 네트워크의 다른 사용자에 따라 달라지는 정체)를 고려하지 않으며, 현재 네트워크 용량을 지속적으로 재계산하기 위해 지속적으로 테스트 트래픽을 생성하는 것은 일반적으로 바람직하지 않다.

따라서, 본 발명의 실시예의 측면은 중개자/서버에 의해 트래픽을 분할 및 재결합하지 않고 또한 네트워크의 현재 용량에 도달했는지 테스트하기 위해 네트워크 트래픽을 생성하지 않고도 최종 사용자(클라이언트) 장치에서 이용 가능한 네트워크의 품질 및 성능을 실시간으로(예를 들어, 필요에 따라, 네트워크 사용시에) 감지할 수 있는 능력을 갖는 접근 방식에 관한 것이다. 본 발명의 일 실시예의 일부 측면은 사용 가능한 네트워크의 세밀한 인식과 관련되어 있으므로 부하 분산이 동적으로 조정되어 다양한 유형의 네트워크 트래픽(예를 들어, 대용량 파일 다운로드뿐만 아니라 웹 브라우징 등)을 가속화할 수 있을 뿐만 아니라 Wi-Fi에서 셀룰러로 빠르게 장애를 우회하여 클라이언트에서의 행(hangs) 및 타임아웃을 방지할 수 있다.

본 발명의 실시예의 측면은 네트워크 연결을 개선하기 위해 컴퓨팅 장치에서 다중 네트워크 연결을 자동으로 관리하는 시스템 및 방법에 관한 것이다. 편의상, 본 발명의 실시예는 무선 근거리 통신망(예를 들어, 3G GSM, 4G LTE) 연결 및 셀룰러 네트워크(예를 들어, WLAN 또는 Wi-Fi) 연결을 모두 갖는 모바일 장치에서 네트워크 연결을 개선하는 것과 관련하여 여기서 설명될 것이다. 그러나, 본 발명의 실시예는 이에 제한되지 않고 두 개의 서로 다른 네트워크 연결(예를 들어, 무선 근거리 통신망 연결 및 유선 근거리 통신망 연결)을 갖는 장치 및 두 개 이상의 서로 다른 네트워크 연결을 갖는 장치(예를 들어, 유선 LAN 연결 또는 위성 데이터 연결과 같은 제3 네트워크 연결)에도 적용될 수 있다.

이제 본 발명의 예시적인 실시예가, 첨부된 도면을 참조하여 설명될 것이다. 도면에서 동일하거나 유사한 참조 번호는 전체적으로 동일하거나 유사한 요소를 지칭한다. 여기서, 본 발명의 실시예를 설명 할 때 "일수 있다(may)"라는 용어는 "본 발명의 하나 이상의 실시예"를 의미한다. 또한, 본 발명의 실시예를 설명할 때 "또는"과 같은 대체 언어의 사용은 나열된 각 해당 항목에 대해 "본 발명의 하나 이상의 실시예"를 의미한다.

도 1은 본 발명의 일 실시예에 따른 온-디바이스 채널 본딩 구현과 함께 사용하기에 적합한 예시적인 휴대용 통신 디바이스(스마트 폰과 같은) 아키텍처(100)의 개략도이다. 예시를 위해, 휴대용 통신 장치 또는 모바일 장치(100)는 Android® 스마트 폰으로 가정될 것이다. 그러나, 본 발명의 실시예는 이에 한정되지 않으며, Android® 이외의 운영 체제를 실행하는 스마트 폰 및 태블릿 컴퓨터, 랩톱 컴퓨터 등과 같은 다른 컴퓨팅 장치에도 적용될 수 있다. 또한, 이러한 모바일 장치는 많은 사용자를 지원할 수 있지만 설명의 편의를 위해 모바일 장치는 특정 사용자 전용으로 가정하며, 따라서 용어 "사용자" 및 "모바일 장치"(또는 개인적 또는 휴대용 방식으로 사용되는 임의의 컴퓨팅 장치)는 명세서 전체에 걸쳐서 동의어로 사용될 수 있다.

본 발명의 하나 이상의 실시예에 따르면, 휴대용 통신 장치 또는 모바일 장치(예를 들어, 아키텍처(100))의 일반 아키텍처는 데이터 트래픽을 모니터링하거나 제어하도록 구성된 중앙 집중식 프록시(130)(또는 트래픽 관리자)를 제공하는데, 상기 데이터 트래픽은, 애플리케이션(예를 들어, 모바일 앱 또는 "앱")부터 모바일 장치가 예를 들어, Wi-Fi 또는 셀룰러 네트워크를 통해 접속하는 애플리케이션 서버(또는 앱 서버)(250)까지 발생한다. 이 접근법은 채널 본딩이 여러 네트워크(예를 들어, Wi-Fi 및 셀룰러) 및 여러 앱에 걸쳐 수행될 수 있게 하고, 채널 본딩이 중앙에서 관리될 수 있도록 허용하지만, 본 발명의 일 실시예가 이에 제한되지는 않는다. 다른 실시예에서, 채널 결합은 각 앱 내에서 또는 앱의 특정 하위 집합에 대해 비공개적으로 수행 될 수 있다.

휴대용 통신 장치(100)의 앱 및 기타 프로그램 가능 구성 요소는 예를 들어 휴대용 통신 장치(100)의 비 일시적 저장 장치(예를 들어, 플래시 메모리(170))에 저장된 컴퓨터 명령 세트로서 구현될 수 있으며, 또한 휴대용 통신 장치(100)의 하나 이상의 프로세서 상에서 실행되도록 구성될 수 있다. 프록시(130)는 또한 특정 웹 사이트에 대한 트래픽, 예컨대 웹 브라우저로부터의 트래픽을 관리할 수 있다. 따라서, 설명의 편의를 위해, 프록시(130)가 관리하는 콘텐츠의 카테고리를 지칭할 때, 본 명세서 전반에 걸쳐 "애플리케이션", "앱", "웹 사이트" 또는 "사이트"와 같은 용어는 다소 혼용될 수 있다.

프록시(130)는, 소켓 계층(120), 네트워크 터널(TUN, network tunnel) 장치(230)를 이용하는 가상 사설망(VPN) 서비스(140)(예를 들어, OS 네트워크 설정을 통해)를 다시 이용하는 프록시 서버(예를 들어, 운영 체제(OS)의 네트워크 설정을 통해)와 같은 다수의 상이한 메커니즘으로부터 결합되거나, 인터셉션 레이어(150)를 이용하는 앱 내에 내장될 수 있다. 프록시(130)는 JVM(Java Virtual Machine), ART(Android® Runtime), 또는 다른 관리되는 런타임 환경(160) 또는 관리되는 런타임 환경없이 운영 체제에서 직접 실행될 수 있다. 프록시(130)는 플래시 메모리(170) 또는 다른 비 휘발성 저장 장치와 같은 물리적 저장 장치상의 캐시된 콘텐츠를 관리하기 위한 캐시 엔진(110)을 포함할 수 있다. 일반성을 잃지 않으면서 이러한 장치는 솔리드 스테이트 드라이브(예를 들어, NAND 플래시 메모리)와 같은 비 일시적 저장 장치 유형일 수 있지만 "디스크"라고도 한다. 또한, 캐시된 콘텐츠 또는 기타 저장된 콘텐츠는 DRAM (Dynamic Random Access Memory)과 같은 휘발성 저장소에 전체 또는 부분적으로 저장될 수 있으며, 이 휘발성 저장소는, 가장 최근에 액세스한 콘텐츠가 더 느린 비 휘발성 스토리지로 전환되기 전에 더 빠른 휘발성 스토리지에 저장되는 계층화된 방식을 통해, 비 휘발성 저장소와 함께 사용될 수 있다.

프록시(130)는 애플리케이션, 커널 드라이버 또는 모바일 장치의 OS와 같은 다양한 형태 인자(form factors)에서 실행될 수 있으며, 내부 앱(180) 및 외부 애플리케이션 서버(250)에서 네트워크 연결을 수신하도록 구성(예를 들어, OS 네트워크 설정을 통해)될 수 있다. 하나 이상의 실시예에서, 프록시 서버는 JVM(160)과 같은 관리되는 런타임 환경에서 실행될 수 있다. 프록시(130)는 클라이언트 애플리케이션(180)을 대신하여 중개자 역할을 할 수 있다. 예를 들어, 프록시(130)는 JVM(165)과 같은 다른 관리되는 런타임 환경에서 실행되는 앱(180)의 요청을 서비스할 수 있다.

동작의 일 예로서, 앱(180)은 예를 들어 HttpURLConnection(190)과 같은 안드로이드 서비스를 이용하여 인터넷 접속을 요청할 수 있다(여기서, HTTP는 하이퍼 텍스트 전송 프로토콜을 의미하고 URL은 균일한 리소스 로케이터, 예를 들어, 웹 주소를 의미한다). HttpURLConnection(190)은 인터넷에 액세스하기 위해 OS에 의해 제공되는 네트워크 서비스(200)를 호출 할 수 있다. 네트워크 서비스(200)는 예를 들어 액세스 포인트 이름(APN, access point name)(210)(예를 들어, 3G 또는 4G 셀룰러 네트워크와 같은 모바일 네트워크) 또는 Wi-Fi 연결(220)을 사용하여 인터넷에 액세스할 수 있다. 네트워크 서비스(200)는, 도 1에서 점선으로 도시된 바와 같이, 시스템에 전역적으로 적용되거나 또는 APN(210) 또는 Wi-Fi 연결(220)에 적용되는 프록시 구성을 사용하여 앱(180)으로부터의 요청을 프록시(130)로 라우팅하도록 구성될 수 있다. 네트워크 서비스(200)는 또한 예를 들어 도 1에 점선으로 나타낸 바와 같이 네트워크 터널(TUN) 장치(230) 또는 IP 라우팅 테이블("아이피테이블(iptables)"로도 알려짐)을 통해 다양한 다른 방식을 사용하여 앱(180)으로부터 프록시(130)로 요청을 라우팅할 수 있다.

네트워크 서비스(200)는 인터넷에 액세스하기 위해서 프록시를 (예를 들어, 장치에서 실행되는 앱에 의해 직접 감지되어 사용되는 글로벌 시스템 프록시, 또는 APN(210) 또는 Wi-Fi 연결(220) 상의 설정을 통한 간접적인 글로벌 시스템 프록시로서) 직접 또는 간접적으로 지정하도록 구성될 수 있으며, 따라서 프록시(130)에 의해 수신되는 소켓(120)(예를 들어, 인터넷에 연결하기 위한 네트워크 소켓)과 같은 표준 통신 계층을 통해 요청이 전송될 수 있도록 한다. 프록시(130)는 차례로 네트워크 서비스(200)를 통해(자체로의 루프백(looping back)을 피하기 위해 APN 또는 Wi-Fi 프록시 구성을 우회하면서) 외부 네트워크(240)를 통해 앱 서버(250)에 요청을 할 수 있으며, 여기서 앱 서버(250)는 요청을 서비스하고 외부 네트워크(240) 및 네트워크 서비스(200)를 통해 임의의 응답 통신을 프록시(130)에 반환한다. 따라서 프록시(130)는 앱(180)과 서버(250) 사이의 통신을 모니터링하거나 제어할 수 있다. 프록시(130)는 캐싱 엔진(110)을 통해 서버(250)로부터 수신된 응답의 일부, 전혀 않거나, 또는 전부를 캐시할 수 있고, 이후에 앱(180)에 네트워크 소켓(120)을 통한 응답을 역순이지만 동일하게 표현되는 단계를 통해 반환한다(예를 들어, APN(210) 연결/Wi-Fi(220) 연결, 네트워크 서비스(200) 및 HttpURLConnection 라이브러리(190)).

APN 또는 Wi-Fi 연결에서 프록시 구성을 사용하는 대신, 네트워크 서비스(200)는 또한 다양한 다른 수단을 통해 요청을 프록시 서버(130)로 라우팅 하도록 구성될 수 있다. 예를 들어, 다른 접근법은 네트워크 전송을 처리하기 위해 VPN 서비스(140)로 네트워크 활동을 라우팅할 수 있는 VPN 연결을 설정하기 위해 네트워크 터널(TUN)(230)을 사용하는 것이다. VPN 서비스(140)는 요청을 서비스하고 네트워크 터널(230)을 통해 응답을 반환하기 위해 소켓(120)을 사용하여 앱(180)과 앱 서버(250) 사이의 트래픽을 관리하기 위해 프록시(130)로 요청을 라우팅할 수 있다.

프록시(130)를 참여시키기 위한 또 다른 메커니즘은 트래픽을 프록시 프로세스로 리다이렉트하기(redirect) 위해 앱 내에서 인터셉션 레이어(interception layer)(예를 들어, 인터셉션 레이어(150 및 155))를 사용하는 것이다. 예를 들어, 위의 예에서, HttpURLConnection(190)이 인터넷에 액세스하기 위해 네트워크 서비스(200)를 호출하도록 하기 전이나 그 대신에, HttpURLConnection(190)은 인터셉션 레이어(150)가 앱(180)으로부터의 요청을 인터셉트 하여 그 트래픽을 프록시(130)로 직접 전달할 수 있다. 인터셉션 레이어(150)로부터 프록시(130)로의 전송은 네트워크 서비스(200)를 통해 또는 메시지 큐(message queues), 명명된 파이프(named pipes) 또는 공유 메모리와 같은 당업자에게 명백한 표준 프로세스 간 통신(IPC) 메커니즘을 사용하여 수행될 수 있다.

JVM(160) 내에서와 같은 별도의 프로세스에서 작동하는 프록시(130)에 추가하여, 다른 실시예에서, 프록시(130)는 JVM(165) 또는 브라우저(185)(웹 브라우저와 같은)와 같은 요청 프로세스 내에 내장될 수 있다. 그러면 프록시(130)는 프로세스 간 통신없이 앱의 네트워크 트래픽을 관리할 수 있다.

다른 예에서, 웹 브라우저(185)는 인터넷(예를 들어, 외부 네트워크(240))에 액세스하려고 한다. 위의 앱(180)과 유사하게, 웹 브라우저(185)는 다수의 상이한 접근법에 의해 프록시(130)를 이용할 수 있다. 예를 들어, 웹 브라우저(185)는 네트워크 소켓(125)을 사용하여 인터넷에 액세스하도록 구성될 수 있으며, 이후에, 상술한 바와 같이, 네트워크 서비스(200)를 사용하여, 예를 들어, 소켓(120) 또는 VPN 서비스(140)를 사용하여 앱 서버(250) 및/또는 프록시(130)에 액세스할 수 있다. 유사한 방식으로, 인터셉션 레이어(155)가 웹 브라우저(185)에 추가될 수 있으며, 인터셉션 레이어(155)는 웹 브라우저(185)로부터의 요청을 인터셉트하고 그 트래픽을 프록시(130)로 전달할 수 있다.

더욱 상세하게는, 상기 기술은 기존 인터페이스에 통합될 수 있으며, 일부 실시예에서 기술은 안전 소켓 레이어(secure sockets layer)(SSL, 예를 들어, 암호화된 통신)와 non-SSL(예를 들어, 암호화되지 않은) 통신 사이에서 구별된다. 애플리케이션과의 통합은 예를 들어 네트워크 스택의 중앙 위치에서 non-SSL통신을 위해 활성화될 수 있다. 예를 들어, 프록시(130)는, 네트워크 프로토콜의 전부 또는 HTTP, HTTPS 또는 둘 모두에 대한 것과 같이 서브 세트에 대한 프록시로서 구성 될 수 있다. 유사하게, 프록시(130)는 셀룰러, Wi-Fi 또는 둘 모두에 대한 것과 같은 네트워크 인터페이스의 전부 또는 서브 세트에 대한 프록시로서 구성될 수 있다. 예를 들어, APN(210) 액세스를 위해, 셀룰러 액세스 포인트가 프록시(130)로 설정될 수 있다. 아이피테이블(iptables) 액세스를 위해, 대응하는 인터넷 프로토콜(IP) 라우팅 테이블 엔트리가 설정될 수 있다. VPN 서비스의 경우, VPN 클라이언트(VPN 서비스(140)와 같은)는 트래픽을 프록시(130)로 라우팅할 수 있다. Wi-Fi의 경우, 프록시(130)는 각 Wi-Fi 액세스 포인트(AP)에 대해 설정될 수 있다. 글로벌 시스템 프록시의 경우, 시스템은 모든 애플리케이션 트래픽에 대한 트래픽을 프록시(130)로 보낼 수 있다.

또한, SSL 또는 TLS와 같은 암호화된 통신을 사용하는 애플리케이션과의 통합은 암호화되지 않은 네트워크 데이터(예를 들어, 암호화되기 전의 네트워크 데이터)에 대한 액세스를 요구할 수 있다. 여기에 사용될 수 있는 여러 가지 접근 방식이 존재한다. man-in-the-middle 접근 방식의 경우 신뢰할 수 있는 인증 기관(CA)을 통해 서버를 가장하여 암호화된 데이터에 액세스 할 수 있다. 소프트웨어 개발 키트(SDK) 접근법(예를 들어, 도 1의 인터셉션 레이어(155)와 함께)의 경우, 암호화 계층 위(예를 들어, 이전)의 네트워킹 API에 대한 후크(hooks)와 함께 빌드 타임 링크가 사용될 수 있다. 재연결 방식의 경우 기존 앱을 디컴파일하고 다시 연결하여 HttpURLConnection(190)과 같은 사용자 지정 대체 API(Application Programming Interface)를 사용할 수 있다. 웹 브라우저(185)와 같은 브라우저를 사용하는 것과 같은 대체 방식의 경우 인터셉션이 이미 연결된 곳에 대체 버전의 앱이 제공될 수 있다. 이는 널리 사용되는 오픈 소스 앱에 특히 적합할 수 있다.

도 1은 주로 휴대용 통신 장치 또는 모바일 장치(100)의 아키텍처에 관한 것이며, 온-디바이스 채널 본딩은 또한 모바일 장치(100)의 하나 이상의 프로세서에서 실행되도록 구성된 소프트웨어 구성 요소와 같은 다른 구성 요소를 수반할 수 있다. 도 2는 본 발명의 일부 예시적인 실시예에 따라 앱(280)과 서버(250) 사이의 네트워크 트래픽의 모니터링 및 제어를 가능하게 하는 프록시(130) 내의 소프트웨어 구성 요소의 블록도이다.

도 2에 있어서, 모바일 장치(100) 내에서 실행되는 앱(280)은 앱 서버(250)와 통신하고, 프록시(130)는 시스템 프록시 설정 또는 VPN을 통하는 것과 같이 이전에 논의된 임의의 방법을 사용하여 앱의 네트워크 트래픽을 인터셉트할 것이다. 프록시(130) 내에, 본 발명의 하나 이상의 실시예에서, 네트워크 트래픽 모니터링 및 제어를 수행하는 논리적 소프트웨어 구성 요소가 있으며, 이러한 소프트웨어 구성 요소는, 앱(280)과 함께, 외부 네트워크 데이터 경로(135)(모바일 장치(100)의 외부의, 예를 들어 인터넷과 같은 외부 네트워크를 넘어서)를 처리할 수 있는 RequestHandler(134) 및 앱 서버(250)와 함께, 내부 데이터 경로(133)(모바일 장치(100) 내부의)를 처리할 수 있는 ClientHandler(132)를 포함할 수 있다. 도 2는 휴대용 통신 장치의 다른 네트워크 인터페이스를 통해 휴대용 통신 장치(100)에 액세스 할 수 있는 다른 네트워크(예를 들어, 다른 Wi-Fi 네트워크, 다른 셀룰러 네트워크 등)를 나타내는 프록시(130)와 앱 서버(250) 사이의 여러 화살표를 도시한다.

앱(280)과 ClientHandler(132) 사이의 데이터 경로(133)는 당업자에 명백하듯이 네트워크 소켓 또는 임의의 다른 표준 프로세스 간 통신 메커니즘과 같은 앱의 네트워크 트래픽을 인터셉트 하는 데 사용되는 방법에 따라 다른 메커니즘을 통해 발생할 수 있다. RequestHandler(133)와 앱 서버(250) 사이의 데이터 경로(135)는 앱(280)이 일반적으로 TCP/IP를 사용하는 네트워크 소켓과 같은 앱 서버(250)와 통신하는 방법에 따라 다른 메커니즘을 통해 발생할 수도 있다. 앱(280)과 내부 데이터 경로(133) 및 앱 서버(250)와 외부 데이터 경로(135)를 분리함으로써, 프록시(130)로 하여금, (외부 네트워크 데이터 경로(135)를 통해) 앱 서버(250)로 및/또는 앱 서버로부터 하나 이상의 사용 가능한 네트워크 연결을 사용하면서 앱(280)으로 및/또는 앱으로부터 데이터를 전송하는 것과 같이, 예컨대, 앱 서버(250)와 통신하는데 사용되는 네트워크 경로(들)로부터 앱(280)이 사용하는 네트워크 경로를 분리할 수 있도록 한다.

본 발명의 다른 실시예에 따르면, PathManager(136)는 RequestHandler(133)에 의해 사용되는 외부 네트워크 데이터 경로(135)를 관리하는 데 사용될 수 있다. 사용할 수 있는 가용 네트워크가 복수인 경우, PathManager(136)는 하나 이상의 정책(policy)을 구현하여 앱 서버(250)와 통신하는데 사용되는 네트워크를 RequestHandler에 지시할 수 있다. 예를 들어, RequestHandler(133)가 복수의 네트워크(예컨대, 복수의 외부 네트워크 데이터 경로(135))를 통과한 복수의 요청을 분산(즉, 부하를 분산)시키도록 지시하여 느린 네트워크(예를 들어, 바쁜 커피 숍의 혼잡한 Wi-Fi 네트워크)를 어떻게 처리하는 지에 대한 방법을 결정하는 정책이 있을 수 있다. 다수의 네트워크에 걸쳐(예를 들어, 다수의 외부 네트워크 데이터 경로(135)에 걸쳐) 다수의 요청을 분배(일명 부하 분산)하기 위해 또 다른 예로, 네트워크 중 하나가 응답하지 않을 수 있는 경우에도 원활하고 응답성이 뛰어난 데이터 연결을 제공하기 위해 여러 네트워크에서 데이터 요청을 중복 발행할 시기를 결정하는 정책이 있을 수 있다.

전술된 정책 중 임의의 것은 예를 들어 사용자에 의해 제공되거나, 앱에 의해 미리 구성되거나, 관리 서버와 같은 외부 시스템으로부터 수신될 수 있다. 앞서 언급된 모든 정책은 성능 메트릭, 비용 요인, 각 매개 변수의 상대적 가중치 등과 같은 여러 매개 변수 또는 가변 매개 변수를 갖도록 확장될 수 있다. 예를 들어 부하 분산 조정 정책은, 기본 네트워크(예를 들어, Wi-Fi)를 확장하기 위해 다른 네트워크(예를 들어, 셀룰러)를 사용하는 방법/시기에 대한 정책을 세우기 위해, 네트워크 속도/대역폭, 대기 시간 및 바이트 대비 비용을 고려할 수 있다.

- 더블탭

본 발명의 실시예의 측면은 컴퓨팅 장치에 이용 가능한 네트워크 연결 또는 네트워크 인터페이스 중 하나 이상을 통해 데이터에 대해 동일한 요청을 전송함으로써 이용 가능한 네트워크 또는 외부 네트워크 데이터 경로(135) 중에서 선택하는 것과 연관된다. 위에 설명된 예에 따라 스마트 폰은 무선 근거리 통신망(또는 Wi-Fi) 연결과 셀룰러 네트워크 연결 모두에서 중복 또는 "더블탭" 요청(예를 들어, DNS 쿼리 또는 웹 페이지 요청)을 보낼 수 있다. 여기서 "요청"이라는 용어는 해당 응답이 있는 네트워크 요청을 지칭하기 위해 일반적으로 사용된다. 요청을 더블탭 하려면 요청이 멱등적이어야 한다(예를 들어, 다른 연결에서 안전하게 재전송되거나 앱 서버(250)에서 여러 번 안전하게 수신 될 수 있음). 예를 들어, 계정 상태에 대한 요청은, 상기 요청의 결과로 앱 서버(250)에서 사용자 데이터가 변경되지 않기 때문에 일반적으로 멱등이지만, 신용 카드 청구 요청은, 그 요청을 받을 때마다 앱 서버(250)가 신용 카드 대금을 청구할 수 있기 때문에 일반적으로 멱등적이지 않다. 이 접근 방식은 많은 네트워크 프로토콜의 초기 요청이 일반적으로 멱등성을 갖기 때문에 거의 모든 유형의 네트워크 트래픽에 취해질 수 있다. 이러한 멱등성 요청의 예로는 DNS(Domain Name System) 쿼리, TCP(Transmission Control Protocol) 연결 용 SYN 패킷, TLS(Transport Layer Security) 핸드 셰이크용 ClientHello 또는 HTTP GET 요청이 있다. 일반적으로 멱등적이지 않은(또는 비멱등성) 요청의 예로는 HTTP POST가 있다.

본 발명의 실시예는, 중복 요청/응답의 비용이 무시할 수 있는/작은 경우(예를 들어, DNS 요청, 이 경우 프로토콜에 의해 응답 크기가 작다)와 같이 하나 이상의 다른 이용 가능한 네트워크에서 즉시 더블탭 할 수 있거나(예를 들어, 동일 데이터 요청을 중복으로 송신), 비용이 큰 경우(예를 들어, 파일 다운로드와 같이 큰 크기의 응답을 생성할 것으로 예상되는 요청 또는 TCP 연결 설정과 같이 상당한 서버 리소스를 소비하는 요청)와 같이 초기 지연이 있고 나서, 선호하는 네트워크(예를 들어, Wi-Fi)에 먼저 요청을 보낸 후 동일한 요청을 사용 가능한 다른 네트워크(예를 들어, 셀룰러)에 더블탭할 수 있다. 따라서 지연의 길이는 멱등성 요청에 대한 응답의 알려진 또는 예상 크기(예를 들어 작은 크기의 응답에 대한 짧은 지연 및 큰 크기의 응답에 대한 더 긴 지연)에 기반하거나, 다른 비용 고려 사항(예를 들어, 적은 비용의 경우 더 짧은 지연, 더 높은 비용의 경우 더 긴 지연)에 기반한다. 컴퓨팅 장치(100)는 어느 연결이 더 나은 성능을 갖는지를 감지하고(예를 들어, 어떤 연결이 먼저 응답을 전달하는지) 다른 연결을 끊는 동안(예를 들어, 응답 수신 및/또는 추가 요청을 전송하지 않음) 더 나은 연결을 계속 사용할 수 있다. 위의 예에서, Wi-Fi 연결이 약한 지역에서 본 발명의 일 실시예에 따른 더블탭 기술을 사용하는 경우, 컴퓨팅 장치(100)는 Wi-Fi 연결을 통하는 것보다 더 빠르게 셀룰러 연결을 통해 응답을 수신할 수 있고, 결과를 즉시 제공할 수 있다. 대조적으로, 컴퓨팅 장치(100)는 Wi-Fi 연결을 먼저 시도하고 Wi-Fi 연결이, 더블탭 지연이라고도 지칭되는 짧은 지연(예를 들어, 애플리케이션 레벨의 타임아웃보다 훨씬 짧은 기간) 내에 응답하지 않은 뒤에만 셀룰러 연결을 따라 요청을 전송할 수 있다.

중복 요청이 더 빨리 전송될수록 하나의 네트워크가 다른 네트워크보다 더 응답성이 있는지 여부를 더 빨리 감지할 수 있다. 일반적으로 네트워크가 여러 개인 경우 어느 것이 사용되는지 결정하는 데 우선 순위가 있다. 예를 들어, Wi-Fi는 일반적으로 무제한 또는 무제한 네트워크인 반면, 셀룰러는 종종 측정 또는 조절된 네트워크일 수 있으므로 Wi-Fi는 디폴트로 사용하는 "기본(primary)" 네트워크로 선호될 수 있지만 셀룰러 및 기타 네트워크는 Wi-Fi가 느리거나 응답이 없을 때 이차적으로 사용된다. 네트워크마다 비용 및 성능 특성이 다를 수 있으므로 블루투스보다 셀룰러를 선호하거나 무제한 데이터 요금제가 있는 경우 셀룰러를 보조(secondary) 네트워크로만 허용하는 등 각 네트워크와 연관된 우선 순위가 다를 수 있다. 즉, 사용 가능한 네트워크에 대한 우선 순위는 성능 또는 비용과 같은 네트워크의 하나 이상의 특성을 기반으로 결정될 수 있다. 본 발명의 일부 실시예에서, 이용 가능한 네트워크에 대한 선호도는 사용자가 제공하는 구성 데이터(configuration data)를 통해 설정된다. 본 발명의 실시예는 중복 요청에 사용하기 위해 서로 다른 우선 순위의 보조(secondary) 네트워크의 조합을 활용할 수 있다.

예를 들어, 애플리케이션이 서버로부터 데이터를 요청하는 경우, 애플리케이션 서버의 도메인 이름과 연관된 IP 주소에 대한 DNS 요청을 전송한 다음 애플리케이션 서버와의 연결을 설정하기 위해 TCP SYN 패킷을 전송할 수 있다. TLS ClientHello에 의해(예를 들어, HTTPS 요청의 경우) 마지막으로 HTTP GET을 전송하여 데이터를 요청한다. 이러한 각 요청은 멱등적이며 보조(secondary) 네트워크에서 중복으로 발행되어 기본 네트워크의 문제에 대한 복원력을 제공할 수 있다. 그러나 이러한 각 요청은 네트워크 및/또는 서버에 서로 다른 비용과 영향을 미친다. 예를 들어 DNS 요청/응답은 작고 상태 비저장이므로 네트워크 또는 DNS 서버에 상당한 비용이나 오버 헤드를 발생시키지 않고 여러 네트워크에서 중복 전송될 수 있다. 그러나, TCP 연결은 더 제한된 리소스(예를 들어, 서버는 동시 연결에 제한이 있음)이므로 일부 실시예에서 프록시(130)는, 기본 네트워크를 통해 보통의 시간 내에(예를 들어, 보통의 시간은 종종 1 ~ 2 초 이내 일 수 있음) 앱 서버(250)로부터 응답을 수신하지 않았음을 감지할 때까지(예를 들어, SYN-ACK 수신) 보조(secondary) 네트워크에서 서버에 대한 TCP 연결(예를 들어, SYN 패킷 전송)에 대한 중복 요청을 지연한다. 위에서 언급 한 바와 같이, 이 대기 기간은 여기에서 더블탭 지연(예를 들어, 응답을 위한 일반적인 시간보다 약간 더 긴 기간, 예를 들어, 2 초)이라고 할 수 있다.

일반적으로, 보조(secondary) 네트워크(들)에 대한 중복 더블탭 요청을 지연시킬 때, 기본 네트워크에 대한 요청은 효과적으로 유리하게 시작되며 대부분의 시간에 성공적으로 완료된다(예를 들어, 일반적으로 보조(secondary) 네트워크의 서버에 SYN 요청을 보내지 않고도 더블탭 지연 내에 기본 네트워크를 통해 응답이 수신됨). 그러나 더블탭 지연 후 중복 요청이 보조(secondary) 네트워크(들) 상에서 전송되므로 기본 네트워크 상에서 전송된 요청과 경쟁하게 된다. 응답이 보이는 모든 네트워크를 사용하여 응답을 받을 수 있으며 응답이 둘 이상의 네트워크를 통해 수신될 수 있다. 중복되는 네트워크 트래픽을 줄이거나 최소화하기 위해, 일부 실시예에서 프록시(130)는 응답을 수신할 네트워크를 하나만(예를 들어, 정확히 하나) 선택한다. 본 발명의 일 실시예에 있어서, 프록시(130)가 응답을 먼저 수신한 네트워크를 더블탭 "승자(winner)"로 선택하고, 프록시(130)는 (예를 들어, 다른 연결 또는 연결들을 닫아서) 다른 네트워크에 대한 데이터 요청을 종료한다. 이중탭 "패자(loser)" 또는 "패자들(losers)"을 종료하면 중복 응답을 처리하기 위한 추가 처리 및 네트워크 사용(예를 들어, 대역폭 소비)을 방지하고, 그리고 중복 요청이 종료되는 방법은 요청 유형에 따라 다르다. 예를 들어 DNS는 상태를 저장하지 않으므로 중복된 "패자" 응답을 무시하는 것으로 충분하지만 HTTP 요청은 더블탭 레이스에서 패배한 네트워크에서 중복 연결을 종료하여 종료할 수 있다.

DNS 및 TCP 프로토콜에 대해 여기에 설명된 바와 같이, 특히 이전에 설명된 것과 같이 "이중탭" 될 수 있는 프로토콜의 많은 예가 있으며, 다른 프로토콜이 중복성을 제공하기 위해 이 더블탭 접근 방식을 유사하게 활용할 수 있다는 것은 당업자에게 자명해야 한다. 예를 들어, TLS 세션은 일반적으로 TCP 연결을 통해 설정되고 TLS ClientHello 요청은 보조(secondary) 네트워크에서 더블탭될 수 있다. 특히 프록시(130)가, 일반적인 응답 시간 이내(예를 들어, 일반적으로 1-2 초 이내), 기본 네트워크의 앱 서버(250)로부터 TLS ServerHello 응답을 수신하지 않는 지연 시간이 지난 후에도 마찬가지이다. 또 다른 예는 TCP 대신 UDP를 사용하여 논리적 보안 연결을 설정하고 동일한 TLS 핸드 셰이크를 활용하는 QUIC(Quick UDP Internet Connection)이고, 따라서 멱등성 요청은 더블탭 기술을 사용하여 중복 전송될 수 있다(예를 들어, 아마도 지연 후에, 동일한 ClientHello를 보조(secondary) 네트워크 상에 중복 전송한다). 또 다른 예로, HTTP 요청은 일반적으로 TCP 또는 QUIC 연결을 설정한 후 수행되며 모든 멱등성 HTTP 요청(예를 들어, 메서드가 GET, HEAD, PUT 또는 DELETE인 HTTP 요청)은 보조(secondary) 네트워크에서 중복 전송될 수 있으며, 또한 기본 네트워크에서 처음 전송한 후 지연되는 것이 바람직하다. 이 예에서 설명한 대로 더블탭은 OSI 네트워크 프로토콜 모델에 의해 정의된 것과 같은 다른 프로토콜 레이어에 적용될 수 있으며, 더블탭은 동일한 애플리케이션 수준 데이터 요청에 대해 둘 이상의 프로토콜 레이어에서 수행될 수도 있다. 다중 프로토콜 계층에서 더블탭을 수행하면 여러 중복 지점이 제공되며, 여기에서 클라이언트-서버 상호 작용의 여러 지점에서 오류(예를 들어, 불량한 네트워크 신호로 인해)가 발생하고 보조(secondary) 네트워크에서 복구될 수 있다.

본 발명의 일부 실시예에서, 보조(secondary) 네트워크상의 중복 요청은 대부분의 응답들(예를 들어, 더블탭 지연시간)에 대해 보이는 전형적인 응답 시간(예를 들어, 더블탭 지연 시간)에 의해서만 지연되기 때문에, 이러한 더블탭 지연은 일반적으로 애플리케이션 타임아웃에 대해 설정되는 것보다 훨씬 더 짧은 임계값이다(예를 들어, 최대 또는 최악의 경우 응답 시간을 기준으로 설정되는 타임 아웃). 중복 요청을 발행하기 위해 짧은 지연(예를 들어, 몇 초)을 사용하면 이러한 중복 요청이 네트워크 문제를 감지하는데 사용되는 애플리케이션의 타임 아웃을 초과하지 않고 기본 네트워크가 불량/응답이 없을 때 보조(secondary) 네트워크에서 응답을 제공할 수 있다. 경우에 따라 이로 인해 애플리케이션 시간 초과 메시지가 사용자에게 표시되지 않을 수 있다(보조(secondary) 네트워크에서 응답이 수신되기 때문). 대조적으로, 비교 시스템에서 사용자는 응용 프로그램 수준(예를 들어, 수십 초)에서 시간 초과 오류가 발생할 때까지 오랜 시간을 기다려야 할 수 있으며 종종 문제의 원인이 무엇인지 사용자가 알 수 없다(예를 들어, 응답하지 않는 Wi-Fi 네트워크는 다른 네트워크에서도 해당 서버와의 통신을 시도하지 않는 한 응답하지 않는 서버와 구별할 수 없는 경우가 많다). 본 발명의 일 실시예는 보조(secondary) 네트워크에 중복 전송될 수 있는 각각의 가능한 요청에 대해 적절한 더블탭 지연을 구성하여, 각 지연이 기본 네트워크가 양호하거나 응답성이 있거나 정상일 때마다 그 기간 내에서 소정 유형의 요청 대부분의 응답이 수신되도록 허용하도록 하는 것이다.

도 3은 본 발명의 일 실시예에 따른 더블탭 접근법의 예시적인 방법을 묘사하는 상위 레벨 흐름도이다. 이 흐름도는, 도 1에 기술된 것과 같이 앱(280)과 앱 서버(250) 사이의 프록시(130)에 의해 네트워크 데이터 경로에서 중개자에 의해 수행될 수 있다. 프록시(130)는 데이터 요청이 앱에서 서버로 전송될 때까지 310 단계에서 대기할 수 있다. 315 단계에서 앱으로부터 데이터 요청이 수신되면, 프록시는 320 단계에서 요청이 멱등적인지를 판단하여 더블탭 방식을 적용할 수 있는지 판단한다. 만약 아니라면, 프록시에 의한 정상적인 네트워크 처리는 더블탭을 수행하지 않고 325 단계에서 적용된다. 만약 그렇다면, 프록시(130)는 적용 가능한 경우(예를 들어, 요청의 유형 및 아마도 이전에 논의된 다른 인자에 기초하여) 더블탭 지연의 시작으로서 330 단계에서 현재 타임 스탬프를 저장함으로써 먼저 더블탭을 적용할 것이다. 데이터 요청은 335 단계에서 현재의 기본 네트워크의 서버로 전송된다. 프록시(130)는 서버로부터 응답이 수신될 때까지(예를 들어, 네트워크가 양호/응답하는 경우) 340 단계에서 더블탭 지연까지 대기한다. 프록시가 345 단계에서 더블탭 지연이 초과되었다고 결정하면, 프록시(130)는 350 단계로 진행하여 하나 이상의 이용 가능한 보조(secondary) 네트워크에서 중복 요청을 전송한다. 345 단계에서 프록시(130)가 응답이 더블탭 지연 내에서 성공적으로 수신되었다고 결정하면, 프록시(130)는 375 단계로 진행하여 응답을 앱(280)에 전송하여 응답을 완료한다.

350 단계에서 중복 요청이 전송된 경우, 프록시(130)는 요청이 중복 전송된 네트워크 중 임의의 네트워크에서 수신될 응답을 기다린다. 360 단계에서, 프록시(130)가 어떤 네트워크를 통해서도 응답이 수신되지 않았다고 판단하는 경우(예를 들어, 타임아웃 기간 내에), 프록시(130)는 365 단계에서 다시 앱으로 요청을 보내지 못한다(예를 들어, 오류 응답이나 연결 재설정 등의 오류를 앱(280)으로 전송한다). 그러나, 1차 응답이 (예를 들어, 타임아웃 기간 내에) 수신되는 경우, 이 1차 응답은 더블탭 레이스의 "승자"이고 프록시(130)는 370 단계에서 (예를 들어, 소켓을 닫음으로써 명시적으로 또는 단순히 이후 응답을 무시하여 암시적으로) 다른 "패자" 네트워크에 대한 요청을 포기할 수 있다. 이제 프록시(130)가 성공적인 응답을 얻었으므로, 375 단계에서 더블탭 승자로부터 앱(280)으로 그 응답을 보낼 수 있다. 프로토콜과 앱과의 연결 상태에 따라 논리적 요청을 완료하기 위해 380 단계에서 추가 처리가 있을 수 있다. 예를 들어, TLS 핸드셰이크는 ClientHello로 시작하지만 프로세스를 완료하기 위해 서버와 추가 요청/응답 라운드 트립을 할 수 있다. 반대로, DNS 쿼리 또는 TCP 연결은 서버로부터의 단일 응답에 의해 완료되며 380 단계에서 추가 처리를 할 필요가 없다.

주요 네트워크가 문제가 있다고 결정되었을 때(예를 들어, 속도가 느리거나 완전히 응답하지 않는 경우), 사용자가 Wi-Fi 네트워크(일명 "데드 존")의 최적 범위의 가장자리에 있을 때와 같이, 현재 주요 네트워크의 지연이 현재의 요청/연결을 넘어 계속될 수 있기 때문에, 현재의 주요 네트워크가 명백하게 실패하기 전에(예를 들어, 타임아웃, 연결 끊김) 주요 네트워크로서 다른 네트워크로 선제적으로 전환하는 것이 바람직할 수 있다. 문제가 있는 주요 네트워크로 네트워크 데이터를 계속 처리하는 것은 여전히 작동할 수 있지만, 보조(secondary) 네트워크(들)에서 전송된 중복 데이터 요청이, 최소화된 중복 네트워크 트래픽을 최소화하기 위해 지연될 수 있기 때문에, 사용자가 체감하는 전반적인 네트워크 성능을 정상보다 저하시킬 수 있다. 네트워크 트래픽을 처리하는 기본 네트워크로서 다른, 아마도 더 반응성이 높은 네트워크로 전환하는 것은, 요청이 지연 없이 기본적으로 해당 네트워크에 전송되므로, 사용자가 더 반응적인 네트워크의 전체 성능을 경험할 수 있게 하는 것을 의미한다. 연속적인 더블탭 승자의 임계값을 초과하거나 하나 이상의 응답 시간에 대한 최대 임계값을 초과하는 것과 같이 기본 네트워크를 변경하는 방법과 시기를 결정할 때 다른 정책이 가능하다. 이러한 정책에 사용되는 임계값은 특정 네트워크(예를 들어, 일부 Wi-Fi 네트워크가 다른 네트워크보다 DNS에 더 느리게 응답하는 것이 정상일 수 있음) 또는 특정 서버(예를 들어, 일부 서버가 TCP SYN 또는 TLS ClientHello 요청에 다른 서버보다 느리게 응답하는 것이 정상일 수 있음)에 대해 확인된 이전 결과에 기반하는 휴리스틱/머신 러닝에 의해 수동 또는 동적으로 구성될 수 있다.

기본(primary) 네트워크에 문제가 있을 때(또는 감소 또는 저하될 때) 성능을 개선하는 또 다른 방법은, 보조(secondary) 네트워크(들)에 대한 중복 요청을 얼마나 지연시킬 지 결정하거나 기본 네트워크로서 다른 네트워크로 선제적으로 전환하기 위해 다른 신호를 활용하는 것이다. 예를 들어, 장치(100)(예를 들어, 운영 체제)가 네트워크 품질에 대한 정보(예를 들어, 신호 강도, 패킷 장애 비율, 손실/불량 패킷 등)에 대한 액세스를 제공하는 경우, 이러한 정보는 보조(secondary) 네트워크를 사용하는 방법과 시기를 결정하는데 사용될 수 있다. 예를 들어, 기본 네트워크가 Wi-Fi이고 신호 품질(예를 들어, RSSI로 알려진 수신 신호 강도 표시기)이 특정 임계값 아래로 떨어지면, 보조(secondary) 네트워크가 요청을 더 빨리 처리하고 네트워크 연결 성능 저하 시 시간 초과 대기 때문에 사용자가 볼 수 있는 지연을 줄이거나 최소화하기 위해 중복 요청에 대한 더블탭 지연이 감소 내지 가능하면 사라질 수 있다. 서로 다른 신호 품질 수준에 대해 서로 다른 지연이 구성될 수 있어서(예를 들어, 신호 품질이 악화되면 더블탭 지연이 감소됨), 이 접근 방식은 점진적이거나 계층적일 수 있다. 신호 품질이 계속 떨어지거나 저하됨에 따라, 이전 기본 네트워크의 신호 품질 수준이 최악의 수준 아래로 떨어질 경우 새 기본 네트워크로의 전환이 이용될 수 있다. 앞서 언급한 접근 방식을 적용하여 더블탭 지연을 줄이거나 새로운 기본 네트워크로 전환하는데, 네트워크에 사용될 수 있는 모든 품질 수준 또는 표시기의 조합이 이용될 수 있다. 일부 실시예에서, 현재 기본(primary) 네트워크의 신호 강도(즉, 새로운 기본 네트워크로서 다른 네트워크로 스위칭하기 전)는, 성능이 저하될 수 있지만, 여전히 동작 가능한 범위 내에 있을 수 있다. 예시적으로, 신호 강도는 현재의 기본 네트워크의 최대 대역폭이 감소되는 지점까지 저하될 수 있지만, 연결은 여전히 이용 가능하다(예를 들어, 부분적인 패킷 손실).

도 4는 본 발명의 일 실시예에 따라 네트워크 액세스를 제어하기 위해 사전 신호를 활용하는 방법을 나타내는 상위 레벨 흐름도이다. 용어 "사전 신호(advance signals)"는 네트워크 동작을 모니터링하는 것(예를 들어, 현재 기본 네트워크가 명시적으로 실패하거나 타임아웃 되기 전)으로부터 감지된 조기 경고 신호를 지칭하기 위해 여기에서 사용될 수 있다. 일부 실시예에서, 사전 신호의 감지는 더블탭 지연을 조정하고/또는 기본/디폴트 네트워크를 선제적으로 전환하기 위해 사용된다. 도 4를 참조하면, 본 발명의 일 실시예에 따르면, 410 단계에서 프록시(130)는 운영체제로부터 신호 강도 업데이터(예를 들어, RSSI) 또는 유사한 네트워크 품질 데이터를 등록한다(이 단계는 네트워크 품질 데이터를 사용할 수 없는 실시예에서 생략될 수 있는데, 예컨대 운영체제가 지원하지 않거나 현재 기본 네트워크에서 사용할 수 없는 경우). 415 단계에서, 프록시(130)는 또한 패킷 통계(예컨대, 네트워크 상에서 검출된 누락 패킷 또는 재전송 패킷의 숫자 및/또는 비율)와 같은 네트워크 메트릭 모니터링을 시작할 수 있다. 420 단계에서, 프록시(130)는 가입된 네트워크 신호 품질 데이터 및/또는 네트워크 통계 데이터에 대한 변경 또는 업데이트를 기다린다. 변경이 감지되면(예를 들어, 운영 체제가 콜백 또는 등가물(지원되는 경우)을 통해 알림을 전송하고/또는 스레드 또는 등가물이 네트워크 데이터의 변경 사항을 주기적으로 샘플링 및 모니터링하면), 425 단계에서 프록시(130)는 업데이트된 네트워크 데이터(예를 들어, RSSI 데이터 및/또는 네트워크 통계 데이터)를 수신한다.

430 단계에서, 프록시(130)는 수신된 새로운 값(예를 들어, RSSI 데이터 또는 네트워크 통계 데이터의)이 "양호한" 네트워크를 나타내는 주어진 임계값 "아래"(또는 그렇지 않으면 더 나은)인지를 결정한다. 만약 그렇다면, 프록시는 더 많은 데이터를 기다리기 위해 420 단계로 돌아간다. 예를 들어, 패킷 손실률이 "양호" 임계값 미만이면 변경이 필요하지 않고 프록시(130)는 420 단계로 돌아간다. "미만"(below)(또는 도 4에서 "<")이라는 용어는 반드시 숫자 값이 아니라 값이 "양호한"(good) 성능 범위 내에 있는지 여부를 나타낸다. 예를 들어, RSSI 값은 신호 강도가 높을 때 더 좋기 때문에 높은 신호 강도는 도 4에 도시된 바와 같이 "양호한 임계값"의 조건 내에 있는 것을 만족할 것이다. 반대로 패킷 손실은 낮을수록 더 좋으므로 낮은 값(또는 이 값의 변화율)은 "양호한 임계값"의 조건을 충족한다.

새로운 값이 "좋은" 임계값 또는 범위 내에 있지 않으면, 프록시(130)는 새로운 값이 "사용 가능한" 범위 내에 있는지를 435 단계에서 결정하기 위해 진행한다. 프록시(130)가 435 단계에 도달했기 때문에, 새로운 값이 "양호" 범위를 벗어남). 그렇다면, 440 단계에서 프록시(130)는 위에서 논의된 더블탭 지연을 감소시킨다. 이는 현재 네트워크가 신뢰할 수 없는 것처럼 보이므로 요청을 더 빨리 대체 네트워크로 보내야 하기 때문이다. 440 단계에서 더블탭 지연을 줄인 후, 프록시는 420 단계에서 다음 네트워크 상태 업데이트를 기다리기 위해 복귀한다.

프록시(130)가 435 단계에서 새로운 값이 "사용 가능"범위 내에 있지 않다고 결정하면, 445 단계에서 프록시(130)는 휴대용 통신 장치(100)에 이용 가능한 네트워크의 다른 네트워크를 기본 네트워크로 설정한다. 다른 네트워크의 선택은 전술 한 바와 같이 다른 네트워크(예를 들어, 가장 높은 순위의 네트워크) 사이의 선호도 순위에 기초하여 행해질 수 있다.

본 발명의 실시예들의 일부 양상들은 도 3과 관련하여 위에서 논의된 바와 같이 더블탭 요청의 응답 시간에 기초하여 1차 네트워크가 될 다른 네트워크를 선택하는 것과 연관된다. 도 4를 여전히 참조하면, 본 발명의 일부 실시예에서, 프록시(130)가 450 단계에서 현재 기본 네트워크를 통해 더블탭을 수행한 후, 프록시(130)는 455 단계에서 더블탭 승자의 응답 시간(예를 들어, 요청의 타임 스탬프 및 네트워크의 대응 응답 타임 스탬프 간의 차이)을 계산한다. 460 단계에서, 프록시(130)는 응답 시간이 앱(280)에 의해 감지된 실패/타임아웃을 피할만큼 충분히 낮지만 네트워크가 충분히 응답하지 않는다는 것을 나타낼 만큼 충분히 높은 시간 임계값과 같은 "사용 가능한" 임계값을 초과했는지 여부를 결정한다. 향후 요청을 위한 기본 네트워크로 선호된다(예를 들어, 2-4 초). 그렇다면, 프록시(130)는 전술 한 바와 같이 445 단계에서 새로운 기본 네트워크를 선택한다.

더블탭 승자의 응답 시간이 기본 네트워크에 대해 허용된 최대 "사용 가능" 시간 임계값 내에 있으면, 프록시(130)는 465 단계에서 기본 네트워크가 더블탭 승자인지 여부를 확인한다. 만약 그렇다면, 기본 네트워크는 충분히 응답하는 것으로 확인되고 프록시(130)는 450 단계에서 요청에 대해 기본적으로 이를 계속 사용한다. 그러나, 더블탭 승자가 2 차 네트워크인 경우, 우리는 470 단계에서 기본 네트워크에서 관찰된 연속적인 더블탭 손실의 수를 증가시킨다. 다음으로, 475 단계에서, 프록시(130)는 기본 네트워크에 의한 연속적인 더블탭 손실의 수가 기본 네트워크가 충분히 저하되거나 응답하지 않음을 나타내는 "사용 가능한" 임계값을 초과하는지 여부를 확인한다(예를 들어, 2-4 연속 손실). 만약 그렇지 않다면, 기본 네트워크는 여전히 충분히 응답할 수 있고 프록시(130)는 450 단계에서 요청에 대해 기본적으로 그것을 계속 사용한다. 만약 그렇지 않다면, 프록시(130)는 위에서 논의 된 바와 같이 445 단계에서 새로운 기본 네트워크를 선택한다.

디폴트로 기본 네트워크로 사용하기 위해 다른 네트워크로 전환할 때, 이는 일반적으로 선호하는 네트워크(예를 들어, Wi-Fi)가 문제가 있고(예를 들어, 응답하지 않거나 너무 느림) 선호되지 않는 다른 네트워크(예를 들어, 셀룰러)를 사용하는 것이 더 낫다는 것을 의미한다. 사용자가 다시 Wi-Fi 신호 품질이 좋은 곳으로 되돌아오는 경우와 같이 나중에 더 선호하는 네트워크가 다시 충분히 응답할 수 있다. 더블탭 접근 방식은 사용 가능한 네트워크에서 계속해서 더블탭 요청을 허용하거나 네트워크 품질 표시기를 활용하거나 이들의 조합을 활용하여 현재 네트워크보다 더 나은 네트워크를 기본 네트워크로 사용할 수 있는지 확인하는 데 사용할 수 있다. 새로운 기본 네트워크로 전환한 후에도 더블탭을 수행하면 이전 기본 네트워크의 응답성을 확인하고 처음에 전환을 트리거한 조건의 변화를 모니터링 할 수 있다. 예를 들어, 연속적인 더블탭 손실을 초과하여 기본 네트워크가 셀룰러로 전환된 경우 프록시(130)는 단순히 Wi-Fi에 중복 요청을 계속해서 전송할 수 있고, 프록시(130)가 Wi-Fi에서 연속적인 더블탭 승자를 감지하면, 프록시(130)는 기본 네트워크인 Wi-Fi로 다시 전환할 수 있다.

일부 실시예에서, 이용 가능한 네트워크들 사이의 선호도 순위는 비용, 성능, 비즈니스 관계 등과 같은 요소들의 조합에 기초하여 결정된다. 이러한 요소들은 네트워크 성능(예를 들어, 일시적인 혼잡) 또는 네트워크 트래픽 비용(예를 들어, 피크 시간 동안 더 높음)과 같이 변동 가능해서, 선호 순위가 동적으로 변경될 수 있다. 본 발명의 실시예는 어느 네트워크를 언제라도 선호할지 고려하기 위해 정적 또는 동적 인자의 임의의 조합을 활용할 수 있다. 예를 들어 성능을 요인으로 고려하기 위해 사용 가능한 네트워크의 처리량이 모니터링 될 수 있다. 시스템(예를 들어, 프록시(130))이 네트워크 트래픽을 처리하기 때문에, 본 발명의 실시예는 시스템을 통해 흐르는 트래픽의 현재 네트워크 대역폭 또는 대기 시간(예를 들어, 현재 속도, 최근 기간 내 최고 속도)을 능동적으로 측정 할 수 있다. 그 다음 그에 따라 선호도 순위를 조정한다(예를 들어, 셀룰러 네트워크보다 상당히 느린 Wi-Fi 네트워크는 상대적인 순위를 감소시킬 수 있으며, 가능하면 셀룰러가 더 선호되는 것으로 간주 될 수 있음). 또 다른 예로 비용을 요인으로 고려하기 위해 시스템은 특정 네트워크를 사용하기 위한 현재 비용을 쿼리(query) 할 수 있다. 본 발명의 실시예는 사용 가능한 네트워크(예를 들어, 현재 Wi-Fi 또는 셀룰러 네트워크)를 사용하는 현재의 비용에 대해 쿼리하기 위해, 네트워크 또는 일부 백엔드 관리 및/또는 가격 시스템에 API(application programming interface) 호출을 행하고, 그에 따라 선호도 순위를 조정할 수 있다. 예를 들어 이러한 비용은 사용자가 타사 셀룰러 네트워크로 로밍하거나 액세스 요금이 부과되는 Wi-Fi 네트워크에 액세스하려고 시도하거나 혼잡에 따라 증가하는 현재 주문형/스팟 가격에 따라 달라질 수 있는 경우와 같이 동적 일 수 있다. 본 발명의 실시예의 일부 측면에서, 사용자, 모바일 네트워크 운영자 또는 장치 제조업체와 같은 엔티티는 특정 순위를 제공할 수 있거나(예를 들어, 선호 순위에서 특정 네트워크를 더 높게 고정), 네트워크의 선호도 순위를 결합하는데 사용되는 특정 요인의 가중치를 구성 할 수 있다.

전술한 본 발명의 실시예는 네트워크 트래픽에 의존하여 다른 기본 네트워크로 전환하거나 이용 가능한 네트워크의 선호도를 재순위화(또는 재 배열)하는 것과 같이, 각각의 동작을 트리거 할 수 있다. 일부 경우에, 예를 들어 더블탭될 수 있는 새로운 데이터 요청없이 서버로부터 데이터를 수신하는 오래 지속되는 암호화된 연결이 하나뿐인 경우와 같이 원하는 작업을 트리거하기 위한 네트워크 트래픽이 충분하지 않을 수 있다. 본 발명의 일 실시예에서, 프록시(130)는 응답하지 않는 기본 네트워크의 탐지를 트리거하는 것을 돕기 위해 최소 수준의 활동을 생성하기 위해 자신의 더블탭 요청을 생성한다. 예를 들어, 한 가지 접근 방식은 내부로부터 수신된 마지막 DNS 요청이 더블탭된 이후 최소 시간 임계값(예를 들어, 몇 초)을 모니터링하는 것이며, 이를 초과한 경우 프록시(130)는 해당 최소 시간 임계값 내에서 응답하지 않는 기본 네트워크를 감지하는데 도움이 되는 테스트 DNS요청(예를 들어, 잘 알려진 호스트 이름)의 더블탭을 수행한다. TCP 연결 요청(예를 들어, SYN)과 같이 더블탭될 수 있는 모든 데이터 요청이 사용될 수 있다는 것은 당업자에게 명백해야 한다. 마찬가지로 이러한 단순하고 가벼운 더블탭 테스트는 사용 가능한 네트워크의 선호 순서를 다시 지정하는 등 다른 필요한 작업을 트리거하는 데 사용될 수 있다.

- 부하 분산(Load Balancing)

본 발명의 실시예의 일부 측면은 다른 네트워크(예를 들어, 셀룰러 연결)상의 다른 연결을 사용하여 네트워크(예를 들어, 느린 Wi-Fi 연결)에서 느린 연결의 성능을 향상시키는 것에 관한 것이다. 본 발명의 다양한 실시예에서, 부하 균형 기술은 전체 네트워크 성능을 증가시키기 위해(예를 들어, 대역폭 증가, 대기 시간 감소) 하나 이상의 가용 네트워크에 걸쳐 부하를 분산시킨다. 본 발명의 일부 실시예는 상이한 네트워크 연결의 성능을 측정하고(위에서 설명된 더블탭 기술과 유사) 네트워크 연결 또는 더 높은 처리량 또는 더 적은 혼잡을 갖는 네트워크 연결의 조합을 선택할 수 있다. 이 접근 방식을 사용하면 각 네트워크의 최대 달성 가능한 처리량, 각 네트워크의 미해결 요청/연결 수 또는 이들의 조합을 기반으로 배포하는 것과 같이 성능을 기반으로 여러 요청 또는 연결을 사용 가능한 네트워크에 분산시킬 수 있다. 본 발명의 다른 실시예에서, 모든 네트워크 연결(예를 들어, Wi-Fi 및 셀룰러 연결 모두)은 데이터의 서로 구별되는 부분들을 다운로드하기 위해 동시에 사용될 수 있으며, 여기서 서로 구별되는 연결들을 따라 수신된 데이터는 장치에서 재결합된다.

본 발명의 실시예는, 기본이 되는, 보다 선호되는 네트워크가 사용 중이거나 느릴 때 보조(secondary)의 덜 선호되는 네트워크로 네트워크 트래픽을 분배할 시기를 감지하는 것에 관한 것이다. 일반적으로 속도가 빠르고 용량이 충분한 경우 선호되는 네트워크를 사용하고 선호되는 네트워크의 용량이 한계에 도달한 경우 선호되지 않는 다른 네트워크만 사용되는 것이 바람직하다. 그러나 네트워크 연결을 완전히 포화시키기 위해 전송되는 데이터가 충분하지 않으면 이를 정확하게 결정하는 것은 어려울 수 있다. 또한, Wi-Fi와 셀룰러 네트워크 모두에 공통적으로 존재하는 다른 유저와 네트워크를 공유할 때, 다른 유저들이 사용하는 용량이 측정 가능한 피크 용량을 줄이게 된다. 이와 같이, 일부 실시예들은, 선호되는 네트워크의 용량이, 테스트 트래픽의 발생 없이도 한계에 도달되었고, 그 네트워크 상의 다른 사용자들에 의해 생성된 네트워크 부하에 대해 독립적으로 작용하는 지를 결정하는 것에 관한 것이다. 본 발명의 일 실시예는 선호되는 네트워크 상의 현재 활성 요청을 추적하고 그것이 임계값에 도달했을 때 선호도가 낮은 다른 네트워크에 요청을 분배하는 것이다. 여기서 활성 요청의 개념은 논리적 요청/응답 쌍이며, 이는 일반 텍스트 트래픽(예를 들어, HTTP GET)과 암호화된 트래픽(예를 들어, 아웃 바운드 암호화된 데이터 전송에 대한 응답으로 암호화된 데이터 수신) 모두에 적용될 수 있다. 일반 텍스트 트래픽의 경우 요청이 더 이상 활성 상태가 아님을 결정하는 것은 전체 응답 데이터를 수신하는 데 기반 할 수 있다(예를 들어, HTTP 응답은 청크 전송에 대해 콘텐츠 길이 헤더 또는 데이터 끝 마커를 지정할 수 있음). 암호화된 트래픽의 경우, 응답의 명시적인 끝을 식별할 수 없을 수 있으므로, 일부 실시예에서는, 초기 데이터 응답을 수신하는 즉시 요청이 완료되는 것으로 취급된다(예를 들어, 서버로부터의 대부분의 응답은 몇 초 이내에 완료된다). 또는, 마지막으로 암호화된 데이터 청크를 수신한 이후 시간이 서버로부터 데이터 청크(chunk) 사이의 일반적인 최소 시간(예를 들어, 2-3초)을 초과하는 경우와 같이, 암호화된 데이터 요청의 끝을 식별하는데 활용될 수 있는 다른 신호가 있다. 활성 요청을 추적하는 이러한 접근 방식은 실제 요청이 활발하게 처리되는 연결만 고려한다는 장점이 있으며, 유지되어 있지만 비활성 상태인 연결(예를 들어, 미사용 연결의 풀링)은 고려하지 않는다는 장점이 있다. 이 접근 방식은 또한 단일 연결을 통해 파이프라인된(pipelined) 요청을 처리할 수 있는데, 각각의 새로운 파이프라인된 요청은 서버로의 아웃 바운드 데이터의 연속적인 시퀀스로서 전송되고, 이들 각각은 서버로부터의 인바운드 데이터의 대응하는 시퀀스가 수신되어 활성 요청 카운트를 감소시키기 전까지 활성 요청 카운트를 증가시킬 수 있기 때문이다.

프록시(130)는, "활성 요청(active requests)"의 카운트를 통해 기본이 되는, 선호되는 네트워크(예를 들어, Wi-Fi)의 임계값이 초과할 때마다 새로운 요청을 덜 선호되는 다른 네트워크(예를 들어, 셀룰러)로 이동할 수 있다. 이 임계값(예를 들어, 최소 임계값)은 기본 네트워크가 새로운 요청에 대해 먼저 시도되도록 네트워크의 선택을 제어하고, 이러한 활성 요청이 이 임계값을 초과하지 않고 신속하게 완료(예를 들어, 응답)되면 프록시(130)는 기본 네트워크를 사용하여 네트워크 트래픽의 대부분을 서비스한다. 이 임계값에 도달될 때마다, 프록시(130)는, 본 발명의 실시예에 따라, 새로운 요청을 다른 네트워크로 보내고, 그에 상응하게 이 다른 네트워크에 대한 활성 요청의 수를 추적하여 가용 네트워크 사이에서의 균형 잡힌 부하 분산을 설정한다.

본 발명의 다른 실시예는 각 네트워크에 분배할 요청의 비율을 설정하기 위해 활성 요청의 수를 사용하는 것이다. 사용 가능한 네트워크 간의 활성 요청의 상대적 비율을 사용하여, 시스템은 (예를 들어, 최적의 성능을 위해) 여러 네트워크 간의 활성 요청의 분산을 유지하여 이들 네트워크에서의 네트워크 부하의 균형을 맞출 수 있다. 예를 들어, 더 느린 네트워크에는 더 빠른 네트워크로 전송된 요청보다 더 긴 시간 프레임 동안 활성 상태로 남아있는 요청이 있을 수 있으므로, 이 접근 방식은 각 네트워크의 용량을 확인하기 위해 테스트 트래픽을 사용하지 않고 여러 네트워크간에 트래픽을 분산하는 방법을 제공한다. 본 발명의 다양한 실시예에서, 각각의 가용 네트워크 사이에서 유지하기 위한 활성 요청의 비율은 정적으로 구성되거나, 동적으로 계산되거나, 이들의 조합으로 구성된다. 일부 실시예에서, 활성 요청 비율은 기본 네트워크에 대한 최소 임계값과 결합되어, 최소 임계값이 현재 초과될 때 네트워크간에 새로운 요청을 분배하는 데 비율이 사용된다.

도 5는 부하 균형 접근법의 예시적인 방법을 묘사하는 상위 레벨 흐름도이다. 이 흐름도는 도 1에 설명된 앱(280)과 앱 서버(250) 사이의 프록시(130)와 같은 네트워크 데이터 경로의 중개자에 의해 수행될 수 있다. 본 발명의 일 실시예에 따르면, 프록시(130)는 410 단계에서 앱(280)에서 앱 서버(250)로 데이터 요청이 전송될 때까지 대기한다. 55 단계에서 앱으로부터 데이터 요청이 수신되면 프록시(130)는 520 단계에서 기본 네트워크가 최소 활성 요청 임계값을 초과했는지 여부를 결정한다. 만약 아니면, 기본 네트워크는 새로운 요청에 대해 525 단계에서 기본 네트워크로 선택되고, 555 단계로 계속 진행된다. 만약 그렇다면, 프록시(130)는 기본 네트워크에 대한 활성 요청의 비율을 확인함으로써 사용할 네트워크를 식별하거나 선택하기 위해 선호도 순서대로 각각의 2 차 네트워크를 반복한다. 535 단계에서 현재 보조(secondary) 네트워크에 대한 기본 네트워크의 활성 요청 비율이 목표 비율보다 크면, 프록시(130)는 기본 네트워크인 것처럼 이 요청에 사용할 현재의 보조(secondary) 네트워크를 선택하며, 이후에 프록시(130)는 555 단계로 진행한다. 그렇지 않고, 기본 및 현재의 보조(secondary) 네트워크 사이의 활성 요청 비율이 목표 비율보다 작다면, 프록시(130)는 530 단계에서 다음 보조(secondary) 네트워크로 계속 진행한다. 540 단계에서 다른 보조(secondary) 네트워크가 없다면, 550 단계에서 기본 네트워크가 선택되고 555 단계로 진행한다. 555 단계에서, 네트워크가 요청에 대해 선택되었으므로 네트워크에 대한 활성 요청 수가 증가된다. 본 발명의 일 실시예에서, 부하 균형 접근법은 560 단계에서 더블탭 접근법과 결합되며, 여기에서 요청은 무응답의 선택된 네트워크에 대해 중복성을 제공하기 위해 도 3의 흐름도에 따라 처리된다. 요청이 완료되면(예를 들어, 선택된 네트워크에서 응답을 수신할 때) 선택된 네트워크에 대한 활성 요청 수가 감소한다.

본 발명의 실시예의 일부 측면은 현재 시스템을 통해 흐르는 네트워크 활동에 의해 사용되는 대역폭(예를 들어, 평균 및 최고 속도)을 모니터링함으로써 테스트 트래픽을 사용하지 않고 각 네트워크의 속도/대역폭을 측정하는 것과 연관된다. 이 접근법은 시스템(예를 들어, 프록시(130))이 또한 각 네트워크의 이러한 대역폭 측정을 사용하여 이들 이용 가능한 네트워크들 사이에서 적절한 활성 요청 비율을 계산 한 다음, 이 비율을 유지하기 위해 각 네트워크에 새로운 요청을 분배할 수 있게 한다. 예를 들어, 위의 표1은 각 네트워크의 상대 속도를 기반으로 여러 네트워크에 부하를 분산하여 전체 성능을 향상시킬 수 있는 방법을 보여준다. 네트워크는 일반적으로 여러 사용자(예를 들어, 셀룰러 및 Wi-Fi)간에 여러 모바일 장치에서 공유되기 때문에 이러한 공유 네트워크의 성능은 시간이 지남에 따라 달라질 수 있다(예를 들어, 사용자 간의 경합으로 인해). 따라서 이러한 대역폭 측정을 사용하여 사용 가능한 네트워크 간의 활성 요청 비율을 동적으로 모니터링하고 업데이트 할 수 있다.

본 발명의 실시예의 일부 측면은 각 네트워크에 대해 가능한 대역폭 상한으로서 각 네트워크(예를 들어, 특정 Wi-Fi SSID 및 BSSID 또는 특정 셀 타워(cell tower))에 대해 보이는 최대 대역폭을 추적하는 것과 연관되며, 이는 활성 요청 비율을 계산하는 데 사용된다. 예를 들어, 네트워크에 대한 활성 요청 수가 증가하지만 측정된 대역폭이 증가하지 않는 경우, 현재 측정된 대역폭이 네트워크의 가능한 현재 한도일 수 있다. 또한, 본 발명의 실시예의 일부 측면은 측정된 대역폭이 가능한 한도라는 신뢰를 높이고 오탐을 피하기 위해 대역폭 측정 기간 동안 전송되는 데이터의 최소 또는 임계량을 사용하는 방법과 연관된다. 본 발명의 일부 실시예에서, 프록시(130)는 이전 측정에 대한 현재 측정의 근접성에 기초하고 및/또는 현재 측정 기간 동안 전송된 데이터의 양에 기초하여 현재 대역폭에서의 신뢰 수준(또는 신뢰 점수)을 계산한다. 예를 들어, 비율을 업데이트하는데 필요한 최소 신뢰 수준을 설정하는 것과 같이, 시스템으로 하여금 현재 측정된 대역폭을 사용하여 활성 요청 비율을 업데이트하는데 사용하여야 하는지의 여부를 신뢰 수준이 결정하도록 할 수 있다. 그 후, 데이터 요청을 위한 네트워크를 선택할 때, 프록시(130)는 또한 현재 선택된 네트워크가 대역폭 상한(bandwidth ceiling)에 있는지 여부를 결정하고, 대역폭 상한 아래에 있는 다른 네트워크를 선택한다, 아마도 그렇게 한다 활성 요청 비율(예를 들어, 재정의(overruling))에도 불구하고 말이다.

각 네트워크에 대한 활성 요청을 추적하는 것도 네트워크 용량의 변화를 동적으로 감지하는 데 사용될 수 있다. 본 발명의 실시예의 일부 측면은 요청이 각 네트워크에 대해 활성 상태로 유지되는 시간을 모니터링하고 각 네트워크가 비슷한 시간 내에 활성 요청을 완료할 수 있도록 각 네트워크의 활성 요청 임계값을 조정하는 것과 연관된다(예를 들어, 활성 요청의 수 감소). 예를 들어 한 네트워크가 다른 네트워크보다 두 배 빠른(예를 들어, 2배 빠른) 활성 요청을 완료하는 것으로 확인되면, 활성 요청의 비율을 조정하여 느린 네트워크보다 빠른 네트워크에 두 배(예를 들어, 2 배 더) 많은 새 요청을 보낼 수 있다. 각 네트워크의 요청 완료 시간은 시간이 지남에 따라 변경될 수 있으므로(예를 들어, 공유 네트워크에서 다른 사용자의 활동이 시간이 지남에 따라 증가 또는 감소), 이것은 사용 가능한 네트워크 간의 활성 요청 비율을 동적으로 조정하는 데 사용될 수 있다. 일부 실시예에서, 이 접근법은 이용 가능한 네트워크의 피크 용량 또는 속도를 결정하기에 네트워크 활동이 불충분한 상황에서 적용된다(예를 들어, 피크 용량을 결정하기 위해 테스트 트래픽을 사용할 필요없이). 이 접근 방식은 각 접근 방식에 가중치를 할당하고 결합 된 가중치를 기반으로 활성 요청 비율을 계산하는 것과 같이 적절한 비율을 계산하기 위해 각 네트워크의 속도 측정을 사용하는 이전에 논의된 접근 방식과 결합 될 수도 있다. 일부 실시예에서, 각 접근법의 상대적 가중치는 각각의 신뢰도에 기초하여 조정된다. 예를 들어, 현재 측정된 네트워크의 속도는 전송되는 데이터 양이 많을 때 더 정확하며, 요청 활성 시간을 측정하는 것은 전송되는 데이터 양이 적을 때 더 정확하므로, 각 데이터의 가중치는 이러한 요인에 기반하여 동적으로 조정될 수 있다(예를 들어, 요청 당 전송된 바이트).

상기 접근법의 일부 실시예는 요청을 전송한 후 응답의 첫 번째 바이트를 수신하는 시간(예를 들어, 활성 요청이 완전히 완료될 때까지 기다리지 않고 첫 번째 바이트에 대한 시간)을 측정하는 것과 같이, 각 네트워크로 전송할 요청의 비율을 계산하기 위해 응답 시간 또는 지연을 사용한다. 이 접근 방식은 앞서 언급된 속도 측정 및 요청 당 활성 시간을 고려하는 접근 방식과 유사한 방식(예를 들어, 결합된 가중치 계산)으로 결합될 수도 있다. 다양하고 상이한 성능 메트릭이 각각의 이용 가능한 네트워크에 분배할 최적의 활성 요청 비율을 결정하기 위해 활용될 수 있다는 것은 당업자에게 명백해야 한다.

앞서 언급된 각 임계값 또는 비율은, 시스템이 각 네트워크에 사용할 임계값(예를 들어, 최상의 임계값)을 학습하도록 네트워크 별로(예를 들어, 각각의 별개의 Wi-Fi SSID에 대해 확인된 이력 결과를 기반으로 별도의 값을 추적) 조정할 수도 있다. 이를 통해 시스템은 네트워크가 연결될 때마다 처음부터 시작할 필요없이 네트워크에 대한 운영 설정(예를 들어, 최적의 운영 설정)을 구성할 수 있다. 이전에 논의된 다양한 측정 값 및 계산된 비율은 각 네트워크에 저장되고(예를 들어, 네트워크의 Wi-Fi SSID에 따라) 특정 네트워크에 다시 가입할 때마다 복원된 다음 시간이 지남에 따라 지속적으로 업데이트된다.

- Wi-Fi 연결 관리(connection management)

본 발명의 실시예의 일부 측면은, 보다 나은 신호 품질을 갖는 다른 Wi-Fi 네트워크를 확인하고, 장치가 "양호한" Wi-Fi 연결의 범위 내에 있을 때 알림을 생성하거나, 장치가 더 나은 Wi-Fi 네트워크에 연결되록 하기 위해 현재 연결된 Wi-Fi 네트워크로부터 선제적으로 분리하는 것과 같은, Wi-Fi 연결 프로세서를 자동화하는 것과 관련된다. 본 발명의 실시예의 일부 측면은, 종속 포털(captive portal)에(예를 들어, 네트워크 제공 업체가 제공하지만 로그인이나 패스워드, 또는 비용 지불이 필요한 Wi-Fi 연결과 같은) 로그인하는 프로세스를 자동화하는 것과 관련된다.

본 발명의 실시예의 한 측면은, 성능을 개선하고, 서로 다른 네트워크에 연결하기 위해 가용 네트워크(예를 들어, Wi-Fi 재스캔)에 대한 휴대용 통신 장치(100)의 스캔을 활용하는 것에 관한 것이다. 이러한 재스캔은 사용자가 이동할 때, 현재 네트워크의 RSSI가 변경될 때, 또는 사용자가 사용 가능한 네트워크 목록을 볼 때와 같이 대부분의 운영 체제에서 정기적으로 발생한다. 예를 들어, 위에서 도 3에 묘사된 바와 같이, 더블탭이 기본 네트워크 스위치(예를 들어, Wi-Fi 네트워크의 데드 존에서)를 트리거할 때 현재 네트워크가 느리거나 응답이 없는 것으로 간주되었기 때문에, 선호하는 유형의 다른 네트워크(예를 들어, 더 나은 RSSI를 갖는 다른 Wi-Fi 네트워크)를 확인하는 것이 유익할 수 있다. 또 다른 예는 부하 분산이, 활성 요청이 너무 느리게 완료되고 있다고 판단하는 경우(예를 들어, 평균 또는 더 불량한 케이스 시간이 일부 최소 임계값 보다 낮은 경우)일 것이다.

트리거에 관계없이, 현재 연결된 네트워크의 감지된 성능 저하는 동일한 유형의 다른 네트워크로의 전환을 트리거하는 데 사용될 수 있다. 즉, 더블탭 접근 방식에 대한 이전의 논의는 하나의 네트워크 유형(예를 들어, Wi-Fi)에서 다른 네트워크 유형(예를 들어, 단일 요청의 경우 또는 모든 요청의 디폴트/기본으로 사용)으로 전환하는 것이었지만, 이것은 동일한 유형의 서로 다른 네트워크 간에 전환하기 위해 더욱 일반화될 수 있다. 예를 들어, 장치는 일반적으로 문제가 확실할 정도로 충분히 높게 설정된 시간 제한을 사용하여 문제를 감지하므로, 장치는 일반적으로 현재 네트워크를 사용할 수 없을 때까지 다른 Wi-Fi 네트워크로 전환하지 않기 때문에, 이것은 다른 Wi-Fi 네트워크(예를 들어, SSID가 다르거나 SSID가 같지만 BSSID가 다른 경우)로 전환하는데 유용하다. 그러나 위에서 논의한 바와 같이 이러한 시간 제한은 일반적으로 너무 높기 때문에 사용자를 더 나은 네트워크로 원활하게 이동하기에는 너무 느리다(예를 들어, 앱이 오랫동안 행(hang)될 수 있고/또는 장치가 더 나은 네트워크로 전환되기 전에 사용자에게 오류 메시지가 표시될 수 있음). 예를 들어, 더블탭 방식을 사용하면, 시스템은 사용자가 시간 초과 오류를 확인하기 훨씬 전에 선호하는 유형의 다른 네트워크로 변경하기 위한(예를 들어, 현재 Wi-Fi 네트워크 연결 해제 및 다른 Wi-Fi 네트워크 연결) 더 빠른 결정을 내릴 수 있으므로 선호하는 네트워크 유형의 품질/가용성을 최대화하는 동시에 더 빠르고 원활한 전환이 가능하다. 또한, 휴대용 통신 장치(100)가 Wi-Fi 네트워크에 가입하고 인증하기 위해 긴 다단계 프로세스를 수행해야 할 수 있기 때문에, 서로 다른 관련 없는 Wi-Fi 네트워크 간의 핸드오프가 느릴 수 있으므로, 이전에 논의되었듯이 더블탭 전근 방식은, 이러한 전환 중에 셀룰러를 사용하여 Wi-Fi 네트워크에서 Wi-Fi 네트워크로의 더 원활한 전환을 보장할 수 있다.

도 6은 신호 품질이 좋은 영역을 나타내는 내부 원형 영역과 신호 품질이 불량한 영역(예를 들어, Wi-Fi 데드 존)을 나타내는 외부 원형 영역이 있는 여러 Wi-Fi 네트워크가 있는 이웃의 예를 보여준다. 예를 들어 한 Wi-Fi 네트워크의 외부 영역(예를 들어, Wi-Fi 네트워크 "A")이 다른 Wi-Fi 네트워크의 내부 영역(예를 들어, Wi-Fi 네트워크 "B")과 겹치는 경우 결과적으로 Wi-Fi 네트워크 A가 Wi-Fi 네트워크 B의 사용을 차단한다(예를 들어, 모바일 장치가 Wi-Fi 네트워크 A에 처음 연결되었지만 Wi-Fi 네트워크 B가 더 나은 네트워크 연결을 제공하더라도 계속 연결되어 있는 경우).

도 7은 도 6과 동일한 예를 보여주지만, 본 발명의 실시예에 따른 기술을 활용한다. 더블탭 기술을 이용하면, 모바일 장치(100)는, 각 Wi-Fi 네트워크의 외부 사용 불가능 영역에 있을 때, 연결된 Wi-Fi 네트워크의 데드 존에 있는 동안 네트워크 연결을 자동으로 채우기(fill) 위해 셀룰러 네트워크를 활용할 수 있다. 부하 분산 기술을 사용하면 각 Wi-Fi의 내부 사용 가능 영역에서 셀룰러 네트워크를 활용하여 두 대역폭을 결합하여 전반적인 성능을 높일 수 있다. 연결 관리 기술을 이용하면, 모바일 장치(100)는, 외부 데드 존의 더블탭 로직 또는 내부 굿존의 부하 분산 로직에 의해 트리거되는 등, 또 다른 Wi-Fi 네트워크에 대한 스캔을 수행함으로써 다른 Wi-Fi 네트워크로 자동 전환 될 수 있다.

본 발명이 특정 예시적인 실시예와 관련하여 설명되었지만, 본 발명은 개시된 실시예에 제한되지 않고, 반대로, 첨부된 청구 범위의 정신과 범위 및 그 등가물 내부에 포함된 다양한 수정 및 등가 배열을 포함하도록 의도된 것임이 이해되어야 한다.

Claims

프로세서, 메모리 및 복수의 네트워크에 연결하도록 구성된 복수의 네트워크 인터페이스를 포함하는 휴대용 통신 장치에서 네트워크 트래픽 관리 방법으로서,
상기 프로세서에서 실행되는 트래픽 관리자에 의해, 상기 프로세서에서 실행되는 애플리케이션에 송신 및 수신의 네트워크 데이터를 인터셉트하는 단계;
상기 트래픽 관리자에 의해, 상기 네트워크 데이터의 멱등성 요청을 상기 복수의 네트워크를 통해 서버로 전송하는 단계;
상기 트래픽 관리자에 의해, 상기 복수의 네트워크 상의 1차 네트워크(first network)를 통해 상기 서버로부터 상기 멱등성 요청에 대한 응답을 수신하는 단계; 및
상기 트래픽 관리자에 의해, 상기 복수의 네트워크 중에서, 상기 응답의 수신 및 상기 애플리케이션에 송신에 사용할 상기 1차 네트워크를 선택하는 단계를 포함하는,
방법.
제1 항에 있어서,
상기 멱등성 요청을 상기 복수의 네트워크를 통해 서버로 전송하는 단계는,
상기 복수의 네트워크 중에서 2차 네트워크(second network)에서 상기 멱등성 요청을 전송하는 단계를 포함하고,
상기 방법은,
상기 2차 네트워크에서 상기 멱등성 요청을 종료하는 단계를 더 포함하는,
방법.
제 1 항에 있어서,
상기 멱등성 요청을 상기 복수의 네트워크를 통해 서버로 전송하는 단계는,
상기 복수의 네트워크 중에서 하나의 네트워크를 통해 상기 멱등성 요청을 상기 서버로 전송하는 단계; 및
지연에 따라 상기 복수의 네트워크 중에서 하나 이상의 다른 네트워크를 통해 상기 멱등성 요청을 상기 서버로 전송하는 단계를 포함하는,
방법.
제 3 항에 있어서,
상기 지연은,
상기 휴대용 통신 장치에서 실행되는 상기 애플리케이션의 애플리케이션 레벨의 타임아웃보다 짧은 것을 특징으로 하는,
방법.
제 3 항에 있어서,
상기 지연은,
상기 멱등성 요청에 대한 일반적인 응답 시간에 기반하여 설정되는,
방법.
제 3 항에 있어서,
상기 멱등성 요청은 네트워크 프로토콜과 연관되고, 그리고
상기 지연은 상기 멱등성 요청과 연관된 상기 네트워크 프로토콜에 기반하여 설정되는,
방법.
상기 3 항에 있어서,
상기 지연은,
상기 멱등성 요청에 대한 응답의 크기에 기반하여 설정되는 것을 특징으로 하는,
방법.
제 3 항에 있어서,
상기 지연은,
네트워크 품질 메트릭(network quality metric)에 기반하여 설정되는,
방법.
제 3 항에 있어서,
상기 복수의 네트워크는 선호도 순위로 배열되고, 그리고
상기 하나 이상의 다른 네트워크는 상기 선호도 순위에 따라 선택되는,
방법.
제 9 항에 있어서,
각각의 네트워크는 선호도 순위에 따라 상이한 지연과 연관되는,
방법.
제 9 항에 있어서,
하나 이상의 동적 인자에 따라 상기 선호도 순위에서 상기 복수의 네트워크를 재배열하는 단계를 더 포함하는,
방법.
제 11항에 있어서,
상기 하나 이상의 동적 인자는,
네트워크 성능을 포함하는,
방법.
제 11항에 있어서,
상기 하나 이상의 동적 인자는,
네트워크 트래픽 비용(network traffic cost)을 포함하는,
방법.
제 1 항에 있어서,
상기 복수의 네트워크는,
복수의 상이한 유형의 네트워크를 포함하는,
방법.
제 14 항에 있어서,
상기 네트워크의 유형은,
셀룰러, 블루투스 및 Wi-Fi 네트워크 중에서 하나 이상을 포함하는,
방법.
프로세서, 메모리, 및 복수의 네트워크에 연결되도록 구성된 복수의 네트워크 인터페이스를 포함하는 휴대용 통신 장치에서 네트워크 트래픽 관리 방법으로서,
상기 복수의 네트워크 중에서, 상기 프로세서에서 실행되는 운영 체재에 의해 기본 네트워크(primary network)로 지정된, 1차 네트워크(first network)를 통해 상기 프로세서 상에서 실행중인 애플리케이션의 네트워크 트래픽을 처리하는 단계;
상기 1차 네트워크와 연관된 복수의 네트워크 상태 정보를 모니터링하는 단계;
수신된 네트워크 상태 정보의 하나 이상의 파라미터가 하나 이상의 임계값 밖에 있을 때 상기 1차 네트워크의 문제를 감지하는 단계;
상기 1차 네트워크에서 상기 문제를 감지하는 것에 응답하여, 복수의 네트워크 중에서 2차 네트워크(second network)를 상기 기본 네트워크로서 선택하는 단계; 및
업데이트된 기본 네트워크로서, 상기 2차 네트워크를 통해 상기 네트워크 트래픽을 처리하는 단계를 포함하는,
방법.
제 16 항에 있어서,
상기 네트워크 트래픽은,
요청 및 상기 요청에 대한 응답을 포함하고,
상기 1차 네트워크에서 상기 문제는 요청의 타임 스탬프(timestamp of the request)와 최대 임계값을 초과하는 응답의 타임 스탬프(timestamp of the response) 사이의 응답 시간에 기반하여 감지되는,
방법.
제 16 항에 있어서,
상기 1차 네트워크에서 상기 문제를 감지하는 단계는,
상기 1차 네트워크 상에서 적어도 하나의 네트워크 통계(network statistics)를 모니터링하는 단계; 및
네트워크 통계의 변화가 임계값을 초과할 때 문제를 감지하는 단계를 포함하는,
방법.
제 18 항에 있어서,
상기 네트워크 통계는,
패킷 손실률(packet loss rate) 또는 불량 패킷율(bad packet rate)을 포함하는,
방법.
제 16 항에 있어서,
상기 1차 네트워크는 무선 네트워크이고,
상기 1차 네트워크의 문제를 감지하는 단계는,
무선 네트워크의 신호 강도를 모니터링하는 단계; 및
상기 신호 강도가 임계 신호 강도 아래로 떨어질 때 상기 문제를 감지하는 단계를 포함하는,
방법.
제 16 항에 있어서,
상기 복수의 네트워크 중에서 상기 2차 네트워크는 상기 복수의 네트워크의 선호도 순위에 따라 선택되는,
방법.
제 16 항에 있어서,
상기 1차 네트워크에서 상기 문제는,
상기 1차 네트워크에서 응답이 수신되기 전에 다른 네트워크에서 수신된 응답에 기반하여 감지되는,
방법.
프로세서, 메모리 및 복수의 네트워크에 연결하도록 구성된 복수의 네트워크 인터페이스를 포함하는 휴대용 통신 장치로서,
상기 메모리는,
상기 프로세서에 의해 실행될 때, 상기 프로세서가 상기 휴대용 통신 장치의 네트워크 트래픽을 관리하게 하는 명령어로서,
상기 프로세서에서 실행되는 트래픽 관리자에 의해, 상기 프로세서에서 실행되는 애플리케이션에 송신 및 수신의 네트워크 데이터를 인터셉트 하는 단계;
상기 트래픽 관리자에 의해, 상기 네트워크 데이터의 멱등성 요청을 상기 복수의 네트워크를 통해 서버로 전송하는 단계;
상기 트래픽 관리자에 의해, 상기 복수의 네트워크 상의 1차 네트워크를 통해 상기 서버로부터 상기 멱등성 요청에 대한 응답을 수신하는 단계; 및
상기 트래픽 관리자에 의해, 상기 복수의 네트워크 중에서, 상기 애플리케이션에 대한 응답의 수신 및 상기 애플리케이션에 송신에 사용할 상기 1차 네트워크를 선택하는 단계에 의한 명령어를 저장하는,
휴대용 통신 장치.
제23 항에 있어서,
상기 멱등성 요청을 상기 복수의 네트워크를 통해 상기 서버로 전송하는 단계는,
상기 복수의 네트워크 중에서 2차 네트워크를 통해 상기 멱등성 요청을 전송하는 단계를 포함하고,
상기 명령어는,
상기 프로세서가, 상기 2차 네트워크에서 상기 멱등성 요청을 종료하게 하는 명령어를 더 포함하는,
휴대용 통신 장치.
제23 항에 있어서,
상기 멱등성 요청을 상기 복수의 네트워크를 통해 상기 서버로 전송하는 단계는,
상기 복수의 네트워크 중에서 하나의 네트워크를 통해 상기 멱등성 요청을 상기 서버로 전송하는 단계; 및
지연에 따라 상기 복수의 네트워크 중에서 하나 이상의 다른 네트워크를 통해 상기 멱등성 요청을 상기 서버로 전송하는 단계를 포함하는,
휴대용 통신 장치.
제25 항에 있어서,
상기 지연은,
상기 휴대용 통신 장치에서 실행되는 상기 애플리케이션의 애플리케이션 레벨의 타임아웃보다 짧은 것을 특징으로 하는,
휴대용 통신 장치.
제25 항에 있어서,
상기 지연은,
상기 멱등성 요청에 대한 일반적인 응답 시간에 기반하여 설정되는,
휴대용 통신 장치.
제25 항에 있어서,
상기 멱등성 요청은 네트워크 프로토콜과 연관되고, 그리고
상기 지연은 상기 멱등성 요청과 연관된 상기 네트워크 프로토콜에 기반하여 설정되는,
휴대용 통신 장치.
제 25 항에 있어서,
상기 지연은,
상기 멱등성 요청에 대한 응답의 크기에 기반하여 설정되는 것을 특징으로 하는,
휴대용 통신 장치.
제25 항에 있어서,
상기 지연은,
네트워크 품질 메트릭(network quality metric)에 기반하여 설정되는,
휴대용 통신 장치.
제25 항에 있어서,
상기 복수의 네트워크는 선호도 순위로 배열되고, 그리고
상기 하나 이상의 네트워크는 선호도 순위에 따라 선택되는,
휴대용 통신 장치.
제 31 항에 있어서,
각각의 네트워크는 선호도 순위에 따라 상이한 지연과 연관되는,
휴대용 통신 장치.
제 31 항에 있어서,
상기 메모리는,
상기 프로세서에 의해 실행될 때 상기 프로세서가, 하나 이상의 동적 인자에 따라 상기 선호도 순위에서 상기 복수의 네트워크를 재배열하게 하는 명령어를 더 저장하는,
휴대용 통신 장치.
제 33 항에 있어서,
상기 하나 이상의 동적 인자는,
네트워크 성능을 포함하는,
휴대용 통신 장치.
제 34 항에 있어서,
상기 하나 이상의 동적 인자는,
네트워크 트래픽 비용을 포함하는,
휴대용 통신 장치.
제 23 항에 있어서,
상기 복수의 네트워크는,
복수의 상이한 유형의 네트워크를 포함하는,
휴대용 통신 장치.
제 36 항에 있어서,
상기 네트워크의 유형은,
셀룰러, 블루투스 및 Wi-Fi 네트워크 중에서 하나 이상을 포함하는,
휴대용 통신 장치.
프로세서, 메모리, 및 복수의 네트워크에 연결되도록 구성된 복수의 네트워크 인터페이스를 포함하는 휴대용 통신 장치로서,
상기 메모리는,
상기 프로세서에 의해 실행될 때, 상기 프로세서가 상기 휴대용 통신 장치의 네트워크 트래픽을 관리하게 하는 명령어로서,
상기 복수의 네트워크 중에서, 상기 프로세서에서 실행되는 운영 체재에 의해 기본 네트워크(primary network)로 지정된, 1차 네트워크를 통해 상기 프로세서에서 실행중인 애플리케이션의 네트워크 트래픽을 처리하는 단계;
상기 1차 네트워크와 연관된 복수의 네트워크 상태 정보를 모니터링하는 단계;
수신된 네트워크 상태 정보의 하나 이상의 파라미터가 하나 이상의 임계값 밖에 있을 때 상기 1차 네트워크의 문제를 감지하는 단계;
상기 1차 네트워크에서 상기 문제를 감지하는 것에 응답하여, 복수의 네트워크 중에서 2차 네트워크를 상기 기본 네트워크로서 선택하는 단계; 및
업데이트 된 기본 네트워크로서, 상기 2차 네트워크를 통해 상기 네트워크 트래픽을 처리하는 단계에 의한 명령어를 저장하는,
휴대용 통신 장치.
제 38 항에 있어서,
상기 네트워크 트래픽은,
요청 및 상기 요청에 대한 응답을 포함하고,
상기 1차 네트워크에서 상기 문제는 요청의 타임 스탬프와 최대 임계값을 초과하는 응답의 타임 스탬프 사이의 응답 시간에 기반하여 감지되는,
휴대용 통신 장치.
제 38 항에 있어서,
상기 1차 네트워크에서 상기 문제를 감지하기 위한 명령어는,
상기 프로세서에 의해 실행될 때 상기 프로세서가, 상기 1차 네트워크에서 적어도 하나의 네트워크 통계를 모니터링하게 하고; 그리고
네트워크 통계의 변경이 임계값을 초과할 때 문제를 감지하게 하는 명령어를 포함하는,
휴대용 통신 장치.
제 40 항에 있어서,
상기 네트워크 통계는,
패킷 손실률(packet loss rate) 또는 불량 패킷율(bad packet rate)을 포함하는,
휴대용 통신 장치.
제 38 항에 있어서,
상기 1차 네트워크는 무선 네트워크이고,
상기 1차 네트워크에서 상기 문제를 감지하는 단계는,
무선 네트워크의 신호 강도를 모니터링하는 단계; 및
상기 신호 강도가 임계 신호 강도 아래로 떨어질 때 상기 문제를 감지하는 단계를 포함하는,
휴대용 통신 장치.
제 38 항에 있어서,
상기 복수의 네트워크 중에서 상기 2차 네트워크는 상기 복수의 네트워크의 선호 순위에 따라 선택되는,
휴대용 통신 장치.
제 38 항에 있어서,
상기 1차 네트워크에서 상기 문제는, 상기 1차 네트워크에서 응답이 수신되기 전에 다른 네트워크에서 수신된 응답에 기반하여 감지되는,
휴대용 통신 장치.