KR20140032542A

KR20140032542A - 무선 네트워크에서 푸시 서비스의 ｈｅａｒｔｈｂｅａｔ 주기 결정 방법 및 장치

Info

Publication number: KR20140032542A
Application number: KR1020120095859A
Authority: KR
Inventors: 박혜영
Original assignee: 삼성전자주식회사
Priority date: 2012-08-30
Filing date: 2012-08-30
Publication date: 2014-03-17
Also published as: US20140066063A1

Abstract

본 발명은 무선 네트워크에서 푸시 서비스의 HEARTBEAT 주기 결정 방법 및 장치에 관한 것으로, 본 발명의 실시예에 무선 네트워크의 단말에서 푸시 서비스의 HEARTBEAT 주기 결정 방법은, 등록서버로 단말 정보 및 네트워크 정보를 포함하는 등록 요청 메시지를 전송하는 단계, 등록 서버로부터 핑 주기 정보를 포함하는 등록 응답 메시지를 수신하는 단계, 푸시서버와 푸시채널을 생성하는 단계 및 수신한 핑 주기 정보를 이용하여 heartbeat 주기를 결정하는 단계를 포함하는 것을 특징으로 한다.
본 발명에 따르면, 푸시 서비스 사용 시, 단말과의 long-lived Connection을 유지하는 방법인 핑 메시지에서 핑 주기 결정 시, 단말의 의존성을 줄일 수 있고, 단말의 불필요한 연산을 줄일 수 있다. 즉, 단말이 자체적인 알고리즘을 연산하거나 미리 결정된 핑 주기를 사용하고 서버에서 핑 주기를 결정하여 단말로 전송하므로, 단말의 전력 소모 또는 동작 프로세스를 감소시킬 수 있고, 네트워크 상황에 맞는 최적의 핑 주기를 결정할 수 있다.
나아가, 각 네트워크 망의 상황에 따라 핑 주기를 동적으로(dynamically) 적용하여, 빈번하게 일어나는 단말의 핑 메세지 전송을 줄이고 네트워크의 과부화를 피할 수 있다.

Description

무선 네트워크에서 푸시 서비스의 ＨＥＡＲＴＨＢＥＡＴ 주기 결정 방법 및 장치{A METHOD AND APPARATUS FOR DETERMINING HEARTBEAT PERIOD OF PUSH SERVICE IN WIRELESS NETWORK}

본 발명은 무선 네트워크에서 푸시 서비스의 HEARTBEAT 주기 결정 방법 및 장치에 관한 것이다.

본 발명은 유/무선 인터넷 및 이동통신망 인프라 위에서 제공되는 IP 네트워크를 기반으로 하는 푸시(Push) 기술에 적용된다. 푸시 기술은 모바일 단말에 특정 메시지나 알림 등을 전달하는데 그 목적이 있다. 푸시 기술은 모바일 단말의 자원 제약에서 시작되었다. 푸시 기술을 활용하면, 단말에서 실행 되는 다수의 응용들이 각자 네트워크 연결(Network connectivity)를 점유하는 대신, 공용의 네트워크 연결 하나만 유지하고, 모바일 플랫폼 차원에서 각 애플리케이션(application)에게 메시지나 알림 등을 전달하도록 지원함으로써 자원 제약에 따른 한계를 어느 정도 극복하고 다양한 서비스의 활용이 가능하다. 애플의 APNS, 구글의 C2DM, 블랙베리의 BPNS, mFluent의 MPNS, Seven의 PingTM 등이 푸시 기술을 사용하는 서비스이다.

일반적으로 푸시 서비스를 위해서는 단말과 푸시 서버가 논리적으로 연결이 되어 있어야 한다. 단말과 푸시 서버 간의 연결을 위해서는 UDP/TCP 가 사용 가능하며, 푸시 서버와 각 단말은 연결 지속을 위해서 keep-alive 메시지를 주고 받게 된다. 이 때, keep-alive 메시지의 전달 주기는 통신사의 방화벽 타임아웃(firewall timeout) 정책에 종속적이며, 보편적인 관례나 표준은 정해져 있지 않다.

푸시 채널을 지속적으로 유지하기 위해서는 단말의 long lived connection이 보장되어야 하는데 long lived connection을 유지하는 방법은 단말에서 방화벽 타임아웃 이전에 heartbeat을 서버로 전송하여 채널의 타임아웃 시간을 연장하는 것이다. 하지만 이 방화벽 타임아웃 주기는 사업자 망 별로 각각 다르고 공개되어 있지 않고, 너무 잦은 heartbeat 전송은 단말의 배터리 소모에 영향을 주기 때문에 최대 방화벽 타임아웃(max fire wall timeout)을 찾아내는 것은 매우 중요하다.

종래 기술에 따르면, 통신사마다 다른 방화벽 타임아웃 정책에 따른 연결 종료 문제를 극복하기 위해서 다음과 같은 다양한 방법들을 고안해서 사용하고 있다. 예를 들어, 통계 또는 규칙(rule)을 기반으로 하거나, 또는 휴리스틱(heuristic)한 방법으로 방화벽 타임아웃(firewall timeout) 값을 감지하여 heartbeat 주기를 결정하게 된다. 이러한 동적(Dynamic)인 방법들을 사용하는 경우, 기존에 결정된 핑(PING) 주기가 유효하지 않은 상황이 되면 다시 방화벽 타임아웃 값을 추적한다. 또한 정적(static)인 방법으로 핑 주기를 미리 고정하여 사용하는 경우도 있다. 즉, 종래의 기술들은 최적의(혹은 항상 보장되는) heartbeat 주기를 계산 (혹은 미리 결정)하여 방화벽 타임아웃 발생 이전에 반복적으로 heartbeat 메시지를 전송함으로써 방화벽의 포트 막힘을 방지하여 long lived connection (또는 세션(session))을 유지하도록 한다.

이러한 종래의 푸시 서비스 관련 keep-alive 기술들은 대부분 핑 요청(Ping Request)을 보내는 주체에 의해 최적의 핑 주기를 찾는데 초점이 맞춰져 있다. 따라서 최적의 핑 주기를 찾기 위해 단말에서 방화벽 타임아웃을 추정할 수 있도록 단말 내의 통계 또는 규칙(rule)을 기반의 방법 또는 또는 휴리스틱(heuristic)한 방법들을 활용한다. 하지만, 이러한 방법들은 단말 플랫폼 내의 알고리즘(algorithm)에 의해 수행되므로, 단말에 종속(dependency)된다. 따라서, 네트워크 상황이나 네트워크의 지역마다 다른 방화벽에 의한 브레이크업 시간(breakup time)에 대한 변화뿐 아니라 단말의 환경 변화에 의해서도 heartbeat 주기가 변화하게 된다.

나아가 네트워크 망의 환경이 변화하는 상황에서 이러한 알고리즘의 적용은 단말에서 방화벽 타임아웃을 추정하기 위해 수행해야 하는 타이머의 수와 프로세스(process)의 수의 증가되어 단말에 부하가 걸릴 것을 예상할 수 있다. 이러한 단말의 부하를 피하기 위해, 단말에서 정적(static)인 방법으로 핑 주기를 미리 고정해서 사용하는 경우, 네트워크 상황에 따라 동적(Dynamically)으로 대처 할 수 없고, 모든 네트워크 환경에서 브레이크업(breakup)을 방지할 수 있는 최소값의 heartbeat 주기를 사용하게 되는데 이러한 경우, 전력 소모량이 증가하게 된다.

즉, 종래 기술에 다르면, 서버는 단말에게 특정한 초기값을 전송하여 또는 단말이 자체의 동적(Dynamic) 알고리즘으로 최적의 heartbeat 주기를 결정하였다. 그러나 특정한 초기값을 전송하는 방식은 단말의 특수한 환경이나 주변환경을 고려 하지 않은 채 일괄적으로 heartbeat 주기를 결정한다는 문제점이 있고, 단말이 알고리즘으로 최적값을 찾아 가는 방식은 공통의 특징이나 패턴이 있음에도 불구하고 모든 단말이 접속된 네트워크 상태나 정보를 찾기 위해 불필요한 알고리즘을 반복해서 수행한다는 문제점이 있다.

본 발명은 상기와 같은 문제점을 해결하기 위하여, 단말의 상태 정보와 단말과서버 간의 연결 상태를 반영하여, 단말 의존성과 단말의 불필요한 연산을 줄일 수 있는 heartbeat 주기를 결정 방법 및 장치를 제공하는데 그 목적이 있다.

상기와 같은 문제점을 해결하기 위한 본 발명의 실시예에 무선 네트워크의 단말에서 푸시 서비스의 HEARTBEAT 주기 결정 방법은, 등록서버로 단말 정보 및 네트워크 정보를 포함하는 등록 요청 메시지를 전송하는 단계, 등록 서버로부터 핑 주기 정보를 포함하는 등록 응답 메시지를 수신하는 단계, 푸시서버와 푸시채널을 생성하는 단계 및 수신한 핑 주기 정보를 이용하여 heartbeat 주기를 결정하는 단계를 포함하는 것을 특징으로 한다.

본 발명에 따르면, 푸시 서비스 사용 시, 단말과의 long-lived Connection을 유지하는 방법인 핑 메시지에서 핑 주기 결정 시, 단말의 의존성을 줄일 수 있고, 단말의 불필요한 연산을 줄일 수 있다. 즉, 단말이 자체적인 알고리즘을 연산하거나 미리 결정된 핑 주기를 사용하고 서버에서 핑 주기를 결정하여 단말로 전송하므로, 단말의 전력 소모 또는 동작 프로세스를 감소시킬 수 있고, 네트워크 상황에 맞는 최적의 핑 주기를 결정할 수 있다.

나아가, 각 네트워크 망의 상황에 따라 핑 주기를 동적으로(dynamically) 적용하여, 빈번하게 일어나는 단말의 핑 메세지 전송을 줄이고 네트워크의 과부화를 피할 수 있다.

도 1은 본 발명이 적용되는 무선 네트워크에서 푸시 서비스를 도시한 도면이다.
도 2는 푸시 서비스를 사용하지 않고 다수의 애플리케이션을 사용하는 경우를 나타내는 도면이다.
도 3는 푸시 서비스를 사용하여 다수의 애플리케이션을 사용하는 경우를 나타내는 도면이다.
도 4는 본 발명의 일 실시예에 따라 푸시채널을 통해 부가적인 단말 정보를 전송하는 과정을 나타내는 도면이다.
도 5는 본 발명의 일 실시예에 따른 단말 로그 수집용 프로토콜의 예시를 나타내는 도면이다.
도 6은 본 발명의 일 실시예에 따른 푸시서버가 단말들로부터 수신한 로그 통계를 나타내는 도면이다.
도 7은 본 발명의 실시예에 따른 단말 로그 중 네트워크 관련 부가정보를 나타내는 도면이다.
도 8은 본 발명의 일 실시예에 따라, 단말이 heartbeat을 전송하는 과정을 도시하는 도면이다.
도 9는 본 발명의 실시예에 따라 단말이 디바이스 등록 요청을 위하여 데이터를 수집하고 이를 등록서버로 전송하는 과정을 나타내는 도면이다.
도 10은 본 발명의 실시예에 따라 디바이스를 등록서버에 등록하는 과정을 나타내는 도면이다.
도 11은 본 발명의 실시예에 단말과 푸시서버 사이에 푸시채널을 연결하고, 이를 유지하는 과정을 나타내는 도면이다.
도 12는 본 발명의 실시예에 따라 단말이 모바일 네트워크에 연결된 경우, 서버 측의 동작을 나타낸 도면이다.
도 13는 본 발명의 실시예에 따라 단말이 모바일 네트워크에 연결되지 않은 경우, 서버 측의 동작을 나타낸 도면이다.

본 발명에 있어서, heartbeat이란, 단말이 서버와 연결을 유지하기 위하여 주기적 또는 비주기적으로 전송하는 메시지를 의미한다.

이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시 예들을 상세히 설명한다. 이 때, 첨부된 도면에서 동일한 구성 요소는 가능한 동일한 부호로 나타내고 있음에 유의해야 한다. 또한 본 발명의 요지를 흐리게 할 수 있는 공지 기능 및 구성에 대한 상세한 설명은 생략할 것이다.

도 1은 본 발명이 적용되는 무선 네트워크에서 푸시 서비스를 도시한 도면이다. 도 1에서 도시되는 무선 네트워크는 단말(101), 등록서버(102) 및 푸시서버(103)를 포함하낟.

먼저, 단말(101)은, 110 단계에서, 등록서버(102)로 디바이스 등록 요청(Device Registration Request) 메시지를 전송한다. 디바이스 등록 요청 메시지란, 단말(101)이 푸시서버(103)를 사용하기 전, 단말(101)의 정보를 등록하도록 요청하는 메시지이다. 디바이스 등록 요청 메시지에는 특정 단말임을 알 수 있는 단말(101)의 단말정보와 네트워크 상황을 알 수 있는 네트워크 정보가 포함될 수 있다. 단말정보는 디바이스 식별자(Device Identifier)로 형태로 포함될 수 있으나, 단말 ID 등 그 형태에 제한없이 다양한 종류가 될 수 있다. 네트워크 정보 역시, 네트워크 식별자(Network Identifier) 형태로 포함될 수 있으나, 네트워크 상황을 알 수 있는 어떠한 정보의 형태가 될 수도 있다.

디바이스 등록 요청 메시지를 수신한 등록서버(102)는, 111단계에서 단말(101)에 대한 인증(Authoentication)절차를 수행한다. 단말(101)이 인증된 경우, 등록서버(102)는 113단계에서 각 단말(101)의 고유성 및 네트워크 상황에 따라 최적의 푸시서버(103)를 단말(101)에 할당한다. 이때, 등록서버(102)는 디바이스 등록 요청 메시지에 포함된 단말정보와 네트워크 정보를 이용하여 최적의 푸시서버(103)를 할당하게 된다. 나아가 등록서버(102)는 115단계에서 단말(101)의 핑 주기(Ping Period)를 결정하게 된다. 여기서 결정된 핑 주기를 이용하여 단말(101)은 해당 푸시서버(103)로 정적(static)으로 PING 메시지를 전송하게 된다.

115단계에서 등록서버(102)는, 단말(101)에서 보내 온 단말정보와 네트워크 정보를 기초로 하여 단말에 최적화된 핑 주기를 결정한다. 핑 주기를 결정하기 위하여, 등록서버(102)는 네트워크 상황에 대한 '핑 주기 테이블(Ping Period Table)' 과 '핑 주기 규칙(Ping Period Rule)'을 구성하고 이를 이용하여 핑 주기를 결정할 수 있다.

등록서버(102)는 상기 과정을 거친 후, 120 단계에서, 단말(101)로 디바이스 등록 응답(Device Registration Reply) 메시지를 전송한다. 디바이스 등록 응답 메시지에는 디바이스 UUID(Device Universally Unique Identifier), 푸시서버 주소(Push Server Address), 핑 주기(Ping Period)등이 포함될 수 있다.

단말(101)은 120 단계에서 수신한 디바이스 등록 응답 메시지에 포함된 정보를 이용하여 130 단계에서 푸시서버(103)와 연결을 초기화 하고 핑 요청 메시지를 전송할 수 있다. 즉, 단말(101)은 디바이스 등록 응답 메시지에 포함된 푸시서버 주소를 이용해 푸시서버(103)에 접속하고 디바이스 등록 응답 메시지에 포함된 핑 주기에 따라 핑을 요청할 수 있다. 여기서 푸시서버(103)과의 연결을 초기화 하는 과정은 단말(101)과 푸시서버(103) 간에 단일한 푸시채널(Push Channel)을 생성하는 과정으로, 단말은 연결 초기화 후, 이 푸시채널의 keep-alive connection을 유지하기 위하여 핑 주기마다 heartbeat을 지속적으로 전송한다. 즉, 단말(101)은 푸시채널을 통해 푸시서버(103)로 heatbeat을 지속적으로 전송하여 채널을 유지 시킨다.

여기서, 푸시채널의 필요성을 간단히 설명하도록 한다. 도 2 및 도 3은, 푸시채널의 필요성을 나타내기 위하여 푸시 서비스를 사용하는 경우와 사용하지 않는 경우의 차이를 나타내기 위한 도면이다.

도 2는 푸시 서비스를 사용하지 않고 다수의 애플리케이션을 사용하는 경우를 나타내는 도면이다.

도 2에 따르면, 푸시 서비스를 사용하지 않는 경우, 단말 측(201)에서 실행되고 있는 다수의 애플리케이션들(210, 211 … 215)이 자체적으로 각각의 서버들(220, 221, 222 … 225 … 227)과 폴링(Polling)을 수행함을 알 수 있다. 이렇게 각 애플리케이션들(210, 211 … 215)이 자체적으로 각각 폴링(Polling)을 수행하는 경우, 단말(201)의 배터리 소모가 매우 크고, 단말 측(201)과 서버 측(202) 간 네트워크의 통신량이 급증하게 된다.

도 3는 푸시 서비스를 사용하여 다수의 애플리케이션을 사용하는 경우를 나타내는 도면이다.

도 3에 따르면, 푸시 서비스를 사용하는 경우, 단말 측(201)에서 실행되고 있는 다수의 애플리케이션들(310, 311 … 315)이 푸시 클리이언트(Push Client, 330)를 통해 푸시서버(350)로부터 푸시를 받게된다. 이 때, 푸시서버(350)는 각각의 서버들(320, 321, 322 … 325 … 327)과 연결되어 있다. 이렇게 단말(301)이 푸시 클라이언트(330)와를 푸시서버(350)를 통해 서버측(302)과 하나의 채널로 연결되어 있고, 해당 채널을 계속 유지하기 위하여 heartBeat을 전송하게 되는 경우, 단말 측(301)과 서버 측(302) 간 통신량을 최소화하고 단말의 배터리 소모를 최소화 할 수 있다.

도 4는 본 발명의 일 실시예에 따라 푸시채널을 통해 부가적인 단말정보를 전송하는 과정을 나타내는 도면이다.

도 4에 도시한 바와 같이, 단말(401)은 서버측(402)의 푸시서버(450)와의 푸시 채널을 유지하기 위하여 지속적으로 heartbeat을 전송한다. 이 때, 단말(401)은 푸시 클라이언트(330)을 이용하여 푸시채널을 통해 단말(401)의 부가적인 정보를 푸시서버(450)로 전송할 수도 있다. 여기서, 부가적인 단말정보는 heartbeat을 제외하고, 단말(401)에서 보낼 수 있는 모든 의미있는 데이터를 의미한다. 즉, 단말(401)은 푸시채널을 통해 heartbeat과 함께, 또는 별도로 데이터를 전송할 수 있다. 전송할 수 있는 부가적인 단말정보로는, 단말(401)의 OS, 제조사, 모델명, 시간 정보등과 같은 디바이스 프로필(Device Profile) 정보, MNC, MCC, GeoIP, GPS 좌표 등과 같은 디바이스 위치 정보, 망상태 정보, Wifi/2G/3G/LTE 사용여부, Roaming 유무 등과 같은 디바이스 네트워크(Device Network) 정보, 사용 패턴 정보 등과 같은 디바이스 사용(Device Usage) 정보 등이 있다.

이렇게 푸시채널을 통해 전송된 단말(401)의 부가정보는, 푸시서버(350)가 단말의 상태 및 네트워크 상태를 판단하는 근거가 될 수 있다.

도 5는 본 발명의 일 실시예에 따른 단말 로그 수집용 프로토콜의 예시를 나타내는 도면이다.

도 1에서 설명한 바와 같이, 디바이스 등록 요청 메시지에는 특정 단말임을 알 수 있는 단말(101)의 단말정보와 네트워크 상황을 알 수 있는 네트워크 정보가 포함될 수 있다. 이 때, 단말정보와 네트워크 정보는 로그 형태로 전송될 수 있는데, 도 5에서 단말의 로그 수집용 프로토콜의 예시를 나타내고 있다. 나아가 단말은 이러한 단말 로그를 푸시채널 생성 후에도, 서버로 푸시채널 또는 그 외 경로를 통해 전송할 수 있다.

도 5에 도시된 프로토콜에 따르면 단말은 다음과 같은 정보들을 기록할 수 있다. 먼저, “date”는 기록이 수집된 시간을 나타낸다. “deviceToken”은 단말 식별 키정보, 예를 들어, IMEI, Device_Serial_Number 등을 나타낸다. “appID”는 단말 상의 Application 식별 키정보, 예를 들어, 주소록, 갤러리, 캘린더, 카카오톡 등을 나타낸다. “data”는 단말에서 수집할 수 있는 부가정보, 예를 들어, 단말 프로파일, 위치정보, 네트워크정보, 사용정보 등을 나타낸다.

도 5에 도시된 프로토콜은 본 발명의 일 실시예에 불과하며, 보다 다양한 정보를 수집할 수 있도록 프로토콜을 다양하게 정의할 수 있다.

도 6은 본 발명의 일 실시예에 따른 푸시서버가 단말들로부터 수신한 로그 통계를 나타내는 도면이다.

상기 도 5에 도시된 프로토콜 등을 통해 기록된 로그는 푸시서버로 전송된다. 푸시서버가 단말들로부터 수집한 데이터는 푸시서버에 저장되고, 저장된 데이터는 도 6과 같이 기록되어 분석 및 통계 추출 과정에 사용된다. 푸시서버는 수신한 데이터의 분석 및 통계 추출을 통해, 단말이 현재 접속한 망의 Breakup 상태 및 APN의 타임아웃 상황을 분석하고, 분석 결과를 이용하여 사업자 망별, 평균 heartbeat 주기(ping_avg), heartbeat 주기의 변경 값(ping_inc) 및 해당 망의 방화벽 타임아웃 최대값 (ping_max) 등을 추출해 낼수 있다.

보다 구체적으로 설명하면, 먼저, 푸시서버는, 단말에서 전송되는 로그를 단말 별, 네트워크 별, 시간 별로 분류(sorting)한다. 도 7에 이렇게 분류한 네트워크 관련 부가정보의 예시가 도시되어 있다.

도 7은 본 발명의 실시예에 따른 단말 로그 중 네트워크 관련 부가정보를 나타내는 도면이다.

도 7을 살펴보면, 로그가 기록된 날짜, 단말의 Activity, 단말 토큰, MNC, 위치 정보 등이 기록되어 있음을 알 수 있다.

그 후, 푸시서버는, 네트워크별로 단말들의 재접속 시간 편차를 계산한다. 이때, 특정 임계값(threshold)을 기준으로 시간 편차값을 계산한다. 여기서는 특정 임계값을 평균 heartbeat 주기(ping_avg)로 하여 계산하는 과정을 실시예로 하여 설명한다.

평균 heartbeat 주기(ping_avg) 이상에서 시간 편차값의 빈도가 가장 높은 수치는 망의 최대 타임아웃 값(Max Timeout)일 확률이 높다. 따라서 이를 최대 핑(ping_max )으로 설정할 수 있다. 또한, 평균 heartbeat 주기(ping_avg) 이하에서 시간 편차값의 빈도가 가장 높은 수치는 단말의 Breakup이 빈번한 경우로, 이를 최소 핑(ping_min)으로 설정할 수 있다. 푸시서버는 특정 임계값(여기서는 평균 heartbeat 주기(ping_avg))를 변경하면서 상기 계산 과정을 반복하여 네트워크 별 최대 핑(ping_max)과 최소 핑(ping_min) 값을 결정할 수 있다.

이렇게 계산된 평균 heartbeat 주기(ping_avg), heartbeat 주기의 변경 값(ping_inc), 최대 핑(ping_max) 및 최소 핑(ping_min) 값은 디바이스 등록 응답 메시지나 푸시전송 메시지에 포함되어 단말로 전송될 수 있다.

단말은 수신한 디바이스 등록 응답 메시지에 포함된 정보를 이용하여 heartbeat 주기를 전송할 수 있는데, 이러한 과정이 도 8을 참조하여 설명하도록 한다.

도 8은 본 발명의 일 실시예에 따라, 단말이 heartbeat을 전송하는 과정을 도시하는 도면이다.

먼저, 단말과 서버간의 프로토콜은 다음과 같이 정의될 수 있다.

ping_avg: 사업자 평균 핑 주기(분)

ping_min: 핑 주기 최소값(분)

ping_max: 핑 주기 최대값(분)

ping_inc: 변경값(분)

상기 프로토콜은 일 예에 불과하며, 상황에 따라 다양하게 정의될 수 있다.

도 9을 참조하여 상기 프로토콜을 이용해 단말이 heartbeat을 전송하는 과정을 설명한다. 먼저, 단말은 프로비저닝(provisioning) 후, ping_avg을 heartbeat 주기로 하여 핑을 시도한다. 이 때, 에러(error)로 인한 프로비저닝인 경우, ping_avg가 변경되면, 새로운 사업자 평균 핑주기(이하 new_avg)가 기존 ping_avg보다 작은 경우, ping_avg에 따라 다시 핑을 시도하고, new_avg가 ping_avg보다 큰 경우, new_avg로 핑을 시도한다.

ping_avg에 따라 시도한 핑이 성공한 경우, heartbeat 주기를 ping_avg + ping_inc 로 변경하여 핑을 시도한다. 이 때, 핑이 성공하는 경우에는 다시 현재 heartbeat 주기에 ping_inc를 더한 값을 heartbeat 주기로 하여 핑을 시도한다. 즉, ping_avg + ping_inc + ping_inc를 heartbeat 주기로 하여 핑을 시도한다. heartbeat 주기를 ping_avg + ping_inc로 변경하여 핑을 시도하였으나, 핑이 실패한 경우에는 heartbeat 주기를 ping_avg로 설정한다.

ping_avg에 따라 시도한 핑이 실패한 경우에, heartbeat 주기를 ping_avg - ping_inc 로 변경하여 핑을 시도한다. 이 때, 핑이 실패하는 경우에는 다시 현재 heartbeat 주기에 ping_inc를 뺀 값을 heartbeat 주기로 하여 핑을 시도한다. 즉, ping_avg - ping_inc - ping_inc를 heartbeat 주기로 하여 핑을 시도한다. heartbeat 주기를 ping_avg - ping_inc로 변경하여 핑을 시도하여, 핑이 성공한 경우에는 heartbeat 주기를 ping_avg ? ping_inc로 설정한다.

다시 말해, 단말이 단말과 푸시서버 간에 정의된 프로토콜로 ping_avg, ping_min, ping_max, ping_inc 4가지 값을 얻게된다. 단말 이러한 4가지 값을 이용하여, 먼저 ping_avg 간격으로 heartbeat을 푸시서버로 전송하고, 푸시채널 연결이 유지되는 경우 ping_avg 에서 ping_inc만큼 증가된 값으로 heartbeat을 전송하며, 푸시채널 연결이 끊어진 경우 ping_avg에서 ping_inc 만큼 감소된 값으로 heartbeat을 전송한다. 이 때, heartbeat 주기는 ping_max와 ping_min 사이를 유지해야 한다. 따라서, 현재 heartbeat 주기가 ping_max이거나, 현재 heartbeat 주기 + ping_inc가 ping_max보다 큰 경우에는 heartbeat 주기가 ping_max로 설정된다. 또한, 현재 heartbeat 주기가 ping_min이거나, 현재 heartbeat 주기 + ping_inc가 ping_min보다 작은 경우에는 heartbeat 주기가 ping_min로 설정된다.

보다 구체적으로 단말의 구동 방법을 설명하도록 한다. 단말이 푸시서버로부터 user_data: "ping_avg=10&ping_min=1&ping_inc=4&ping_max=24" 라는 정보를 수신하는 경우를 가정하도록 한다.

이 때, ping_avg는 10이므로, 최초 10분 간격으로 heartbeat을 전송하게 되고, 연결이 유지되면, ping_inc=4 값에 따라 14, 18, 22로 4분씩 heartbeat 주기를 늘려간다. 다만, ping_max가 24이므로, heartbeat 주기가 22이고 핑이 성공한 경우에는 그 이후 heartbeat 주기는 24로 설정되고 더 이상 커지지 않는다. 연결이 유지되지 않는 경우에는 ping_inc=4 값에 따라 6, 2로 4분씩 heartbeat 주기를 줄여간다. 다만, ping_min가 1이므로, heartbeat 주기가 2이고 핑이 실패한 경우에는 그 이후 heartbeat 주기는 1로 설정되고 더 이상 줄어들지 않는다.

도 9 내지 11은 본 발명의 실시예에 따른 단말의 동작을 나타낸 도면이다.

도 9는 본 발명의 실시예에 따라 단말이 디바이스 등록 요청을 위하여 데이터를 수집하고 이를 등록서버로 전송하는 과정을 나타내는 도면이다.

먼저, 단말은 네트워크와 연결 후, 네트워크로부터 네트워크 식별자(Network Identifier)인 MCC 와 MNC 정보를 획득한다. 단말이 SIM 카드를 사용하는 경우에는 SIM 카드로부터 MCC 와 MNC 정보를 획득할 수도 있다. 나아가, 단말이 WiFi를 사용할 수 있는 경우에는, WiFi의 연결 여부에 대한 정보를 획득할 수도 있다.

그 후, 단말은 다음과 같은 정보를 등록서버로 전송할 수 있다.

- Device Model Name: 디바이스 모델명

- Device Id: IMEI 또는 MAC Address와 같은 디바이스 식별자

- Device Type: TV, PC, 휴대폰과 같은 디바이스 타입

- Network MCC & MNC: 모바일 네트워크를 사용하는 경우, 그 네트워크의 MCC와 MNC를 전송

- Sim MCC & MNC: SIM 카드를 사용하는 경우, SIM 카드의 MCC와 MNC를 전송

- WiFi Connected(Optional):디바이스가 WiFi에 연결되었는지 여부에 따라 true 또는 false를 전송

도 10은 본 발명의 실시예에 따라 디바이스를 등록서버에 등록하는 과정을 나타내는 도면이다.

먼저, 등록서버는 단말로부터 디바이스 등록 요청 메시지를 수신한다. 그 후, 다음과 같은 정보를 포함하는 디바이스 등록 응답 메시지를 단말로 전송한다.

- DeviceToken: 푸시 서버와 연결을 설정하기 위해 요구되는 푸시 디바이스 식별자(Push Device Identifier)

- Push Server Address: 디바이스가 푸시 서비스를 받기 위해 접속해야 하는 푸시서버의 주소

- Ping Interval: 단말이 핑 요청(Ping Request)을 보내는 주기

도 11은 본 발명의 실시예에 단말과 푸시서버 사이에 푸시채널을 연결하고, 이를 유지하는 과정을 나타내는 도면이다.

먼저 단말은 등록서버로부터 수신한 푸시서버의 주소로 접속하여 등록서버로부터 수신한 DeviceToken 정보를 포함한 초기화요청(InitRequest) 메시지를 전송한다. 그 후, 푸시서버와 성공적으로 연결이 되는 경우, 등록서버 로부터 받은 핑 주기로 푸시서버로 핑 요청(Ping Request)을 전송한다. 이 때, 단말은 상기에서 설명한 바와 같이 ping_max와 ping_min 사이에서 ping_avg와 ping_inc를 이용하여 heartbeat 주기를 결정할 수 있다.

상기 과정에서 디바이스 등록 절차(Device Registration process)은 단말이 최초에 푸시 클라이언트를 사용하려는 경우에 진행된다. 그러나 그 후에도, 다음과 같은 경우에 디바이스 등록 절차가 추가적으로 수행될 수 있다.

- 단말과 푸시서버의 연결이 특정 횟수 이상 실패하는 경우(연속적, 비연속적 실패)

- 푸시 서버로부터 다시 등록하라는 메세지를 받은 경우

- 등록 서버로부터 받은 DeviceToken이 잘못된 경우(예를들어, DeviceToken이 삭제되는 경우)

도 12는 본 발명의 실시예에 따라 단말이 모바일 네트워크에 연결된 경우, 서버 측의 동작을 나타낸 도면이다.

먼저 등록 서버는 단말로부터 수신한 데이터에 MCC, MNC 정보가 있는지 여부를 확인한다. MCC, MNC 정보가 있는 경우, 단말로부터 수신한 MCC와 MNC 에 따라 DB에 미리 정의된 핑 주기를 전송한다. 이 핑 주기는 필드 테스트(Field Test) 또는 푸시서버에서 단말과의 연결을 모니터링한 후 결정되는데, 모바일 네트워크의 방화벽 Breakup 타임에 가장 근접하도록 설정된다.

도 13는 본 발명의 실시예에 따라 단말이 모바일 네트워크에 연결되지 않은 경우, 서버 측의 동작을 나타낸 도면이다.

단말이 모바일 네트워크를 사용하지 않는 경우에는 단말의 특성과 푸시서버의 연결 관리(Connection Management) 로직에 따라 핑 주기를 결정하게 된다. 등록서버는 단말로부터 수신한 DeviceType 정보에 따라 각각 다른 핑 할당 규칙(Ping Allocation Rule)을 가지게 된다. 도 13을 참조하면, NotePC는 30분의 핑 인터벌을 같도록 규칙이 정의될 수 있다.

단말의 핑 주기는 각각 다른 사업자의 망의 방화벽 Breakup 타임에 의해 결정된다. 방화벽 Breakup 타임은 무선 네트워크상의 자원을 확보하기 위하여 일정 시간동안 데이터의 전송이 없는 경우, 단말의 연결을 끊는 시간을 의미한다.

단말에 보내는 핑 주기는 아래와 같은 방법으로 정해진다.

먼저, 서버는 필드 테스트(Field Test)를 통해 방화벽 Breakup 타임을 측정하고 적용한다. 그 후, 사업자로부터 방화벽 Breakup 타임을 수신하고, 푸시서버에서 각 단말의 연결 breakup 타임을 모니터링 후, 핑 주기를 도출하여 적용한다.

본 명세서와 도면에 개시된 본 발명의 실시예들은 본 발명의 기술 내용을 쉽게 설명하고 본 발명의 이해를 돕기 위해 특정 예를 제시한 것일 뿐이며, 본 발명의 범위를 한정하고자 하는 것은 아니다. 여기에 개시된 실시예들 이외에도 본 발명의 기술적 사상에 바탕을 둔 다른 변형 예들이 실시 가능하다는 것은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에게 자명한 것이다.

101: 단말
102: 등록서버
103: 푸시서버

Claims

무선 네트워크의 단말에서 푸시 서비스의 HEARTBEAT 주기 결정 방법은,
등록서버로 단말 정보 및 네트워크 정보를 포함하는 등록 요청 메시지를 전송하는 단계;
상기 등록 서버로부터 핑 주기 정보를 포함하는 등록 응답 메시지를 수신하는 단계
푸시서버와 푸시채널을 생성하는 단계 및
상기 수신한 핑 주기 정보를 이용하여 상기 heartbeat 주기를 결정하는 단계를 포함하는 것을 특징으로 하는 방법.
무선 네트워크의 등록서버에서 푸시 서비스의 HEARTBEAT 주기 결정 방법은,
단말로부터 단말 정보 및 네트워크 정보를 포함하는 등록 요청 메시지를 수신하는 단계;
상기 수신한 단말 정보 및 네트워크 정보를 이용하여 핑 주기 정보를 생성하는 단계; 및
상기 단말로 상기 핑 주기 정보를 전송하는 단계를 포함하는 것을 특징으로 하는 방법.