KR101997986B1 - 상호 작용하는 IoT 어플리케이션을 위한 클라우드-포그-클라이언트 삼각 컴퓨팅 방법 및 장치 - Google Patents

Abstract

상호 작용하는 IoT 어플리케이션을 위한 클라우드-포그-클라이언트 삼각 접근 방법 및 장치가 제시된다. 일 측면에 있어서, 본 발명에서 제안하는 상호 작용하는 IoT 어플리케이션을 위한 클라우드-포그-클라이언트 삼각 접근 방법은 포그 서비스 요청 기능을 이용하여 클라이언트를 할당된 포그 웹 서비스에 접근시키는 단계, 상기 클라이언트를 서비스 핸드오프 결정 상태로 변환하고, 포그 응답에서 포그 상태 및 반응 시간을 모니터링 하는 단계, 상기 모니터링 결과에 따라 클라이언트에 서비스를 제공할 경우, 현재 포그 상태를 확인하기 위해 클라우드를 통해 클라이언트에 대한 응답에 명령을 입력하는 단계, 클라이언트가 포그 상태를 확인하기 위한 상기 명령을 수신한 경우, 클라이언트를 포그 상태 확인 상태로 변환시키고, 포그에 감지 패킷을 전송하는 단계 및 상기 전송된 감지 패킷에 대한 반응 및 반응 시간을 분석하는 단계를 포함한다.

Description

상호 작용하는 IoT 어플리케이션을 위한 클라우드-포그-클라이언트 삼각 컴퓨팅 방법 및 장치{Method and Apparatus for Cloud-Fog-Client Triangular Computing for Interactive IoT Applications}

본 발명은 상호 작용하는 IoT 어플리케이션을 위한 클라우드-포그-클라이언트 삼각 접근 방법 및 장치에 관한 것이다.

스마트 공동체를 위한 대표적인 IoT 장치는 센서, 액츄에이터 및 클라이언트가 있다. 클라우드를 통해 IoT 데이터를 전달하고 처리하기 위해서 일반적으로 클라우드 내에 물리적인 IoT 장치에 대응하는 가상 IoT 장치를 설정하는 방법이 사용된다. 구체적인 과정은 다음과 같다. 센서를 갖는 IoT 클라이언트는 센서 판독 처리를 위한 요청을 클라우드 내 가상 액츄에이터로 보낸다. 클라우드는 요청을 관련된 물리 액츄에이터로 보낸다. 물리 액츄에이터는 응답 메시지를 클라우드 내 가상 액츄에이터로 보낸다. 클라우드는 가상 액츄에이터로부터 응답 메시지를 읽고 그것을 클라이언트로 다시 보낸다. 이러한 예에서, 클라이언트와 액츄에이터 간의 응답 시간은 두 가지 시간, 즉, 클라이언트와 클라우드 간의 응답 시간 및 클라우드와 액츄에이터 간의 응답 시간으로 나눠질 수 있다. 그러므로, 클라우드를 통한 통신 효율성은 IoT 어플리케이션의 성능에서 중요한 주제이다. 게다가, IoT 데이터 생성기와 클라이언트가 동일한 엣지 네트워크 내에 있다면, 원시 데이터를 클라우드로 전달하는 것과 응답을 다시 엣지 네트워크로 전달하는 것은 비효율적일 수 있다. 이러한 비효율은 적어도 두 가지 문제, 즉, 응답 시간의 지연 및 코어 네트워크의 오버헤드를 유발한다.

최근에, 포그 컴퓨팅은 비효율성 문제를 해결하기 위해 각광받고 있다. 포그 컴퓨팅은 기존 클라우드 기능들을 엣지 네트워크 근처에 두는 컴퓨팅 패러다임이다. 포그 컴퓨팅의 주요 이점은 네트워크 지연 감소 및 코어 네트워크 로드 감소를 포함한다. IoT 서비스를 지원하기 위하여, 클라이언트와 서버가 같은 엣지 네트워크에 존재한다면, 가공처리되기 전의 대용량의 원시 데이터는 원격의 클라우드로 전송될 필요가 없다. 그 대신에, 원시 데이터는 포그 노드로 전달되고 오직 매우 적은 요약 데이터만이 서비스를 관리하기 위하여 클라우드로 전달되는 방식으로 IoT 서비스를 제공하는 것이 가능하다. IoT 어플리케이션을 위해 요구되는 데이터 처리는 포그 내에서 수행될 수 있다. 이는 데이터 수집 및 서비스 전달이 지연되는 것을 감소시킨다.

포그 컴퓨팅의 문제점은 가상화에 기반한 자원 확장성이 필연적으로 부족하기 때문에, 포그 노드 용량이 클라우드만큼 탄력적이지 않다는 점이다. 클라우드 컴퓨팅이 인터넷에 분포된 풍부한 컴퓨팅 자원에 의해 지원받아 컴퓨팅 용량이 쉽게 증가될 수 있는 반면, 포그 컴퓨팅에서는 컴퓨팅 자원이 엣지 네트워크 또는 그 부근에 배치되어야 있어야 하기 때문에 포그 컴퓨팅에 풍부한 컴퓨팅 자원을 지원하기가 어렵다. 그러므로, 포그 컴퓨팅을 제공하기 위해서, 서비스 제공자는 서버를 배치하기 전에 예상되는 서비스 수요와 함께 필요한 컴퓨팅 용량을 예측할 필요가 있다. 일반적으로, 엣지 네트워크를 커버하는 포그 노드의 사용자 수가 넓은 영역을 커버하는 기존 서버의 사용자 수보다 적을 것이기 때문에, 포그 노드에 대한 컴퓨팅 용량 추정은 기존 서버에 대한 컴퓨팅 용량 추정에 비해 매우 어려울 것이다. 따라서, 서비스 수요의 상대적인 변동은 서비스 커버리지가 작을 때 더 커진다. 부정확한 추정에 의해, 포그 노드는 쉽게 과부하되거나 활용도가 낮아질 것이다. 이것을 포그노드의 성능확장성 부재 문제라 하자.

기존의 클라우드 컴퓨팅 및 모바일 셀룰러 네트워크에서 네트워크 지연을 감소시키기 위한 대표적인 방법으로 클라우드렛(cloudlet)과 모바일 엣지 컴퓨팅이 있다. 클라우드렛은 클라이언트와 가까운 네트워크상에 분산 클라우드를 설치하여 기존의 클라우드 서버에서 제공하던 서비스를 대신 제공해 주도록 하는 기술이다. 엣지 컴퓨팅은 기존의 모바일 셀룰러 네트워크의 기지국의 기능을 확장해 다양한 부가 서비스를 제공해 주도록 하는 기술이다. 두 기술 모두 기존의 클라우드에서 제공하던 서비스를 클라이언트와 가까운 컴퓨팅 노드에서 제공하도록 한다는 점에서 포그컴퓨팅과 그 목적이 같다. 하지만 상기의 방식들은 클라우드 서버를 포그서버로 대체하는 방식으로 포그서버에 부하가 증가하게 되면 성능확장성을 갖지 못하는 포그서버의 특성으로 인해 서비스 응답속도가 저하된다는 문제가 있다.

본 발명이 이루고자 하는 기술적 과제는 클라우드, 포그, 클라이언트가 저-지연 IoT 서비스를 위해 협업하는, 클라우드-포그-클라이언트 삼각 컴퓨팅 방법 및 장치를 제공하는데 있다. 더욱 상세하게는 클라우드를 포그의 백업 컴퓨팅 자원으로 만들고 포그 노드의 부하를 현재 포그 상태에 따라 동적으로 클라우드에 이동시킬 수 있도록 한다. 또한, 포그 컴퓨팅에 의한 반응 시간을 감소시키고, 과부화된 포그 노드에 의한 서비스 다운을 방지하고자 한다.

일 측면에 있어서, 본 발명에서 제안하는 상호 작용하는 IoT 어플리케이션을 위한 클라우드-포그-클라이언트 삼각 접근 방법은 포그 서비스 요청 기능을 이용하여 클라이언트를 할당된 포그 웹 서비스에 접근시키는 단계, 상기 클라이언트를 서비스 핸드오프 결정 상태로 변환하고, 포그 응답에서 포그 상태 및 반응 시간을 모니터링 하는 단계, 상기 모니터링 결과에 따라 클라이언트에 서비스를 제공할 경우, 현재 포그 상태를 확인하기 위해 클라우드를 통해 클라이언트에 대한 응답에 명령을 입력하는 단계, 클라이언트가 포그 상태를 확인하기 위한 상기 명령을 수신한 경우, 클라이언트를 포그 상태 확인 상태로 변환시키고, 포그에 감지 패킷을 전송하는 단계 및 상기 전송된 감지 패킷에 대한 반응 및 반응 시간을 분석하는 단계를 포함한다.

상기 클라이언트를 서비스 핸드오프 결정 상태로 변환하고, 포그 응답에서 포그 상태 및 반응 시간을 모니터링 하는 단계는 네트워크 또는 포그 상태가 미리 정해진 기준 이하인 경우, 클라이언트를 클라우드 서비스 요청 상태로 변환 시키고, 후속 요청들을 전송하는 단계를 포함한다.

상기 클라이언트를 서비스 핸드오프 결정 상태로 변환하고, 포그 응답에서 포그 상태 및 반응 시간을 모니터링 하는 단계는 현재 로드 포화 레벨이 포그 노드가 감당 가능한지 여부를 결정하기 위해 현재 로드 포화 레벨을 모니터링하는 단계 및 후속 기간 동안의 로드 포화 레벨을 추정하기 위해 포그 노드를 통해 초당 처리될 수 있는 요청의 수에 대한 서비스 당 요청의 수를 추정하는 단계를 포함한다.

상기 현재 로드 포화 레벨을 계산하기 위해, 포그 노드는 초 당 처리되어야 하는 요청의 수(H)를 초 당 처리될 수 있는 요청의 수(h)로 나누고, 상기 노드는 초 당 처리되어야 하는 요청의 수(H)는 서비스 당 요청의 수(P)와 초 당 사용자의 평균적인 수(λ)의 곱으로 정의된다.

상기 후속 기간 동안의 로드 포화 레벨을 추정하기 위해, 포그를 통해 사용자 수를 모니터링함으로써 초당 처리될 수 있는 요청의 수에 대한 서비스 당 요청의 수를 추정하고, 활성 사용자를 카운트하기 위하여, 포그를 통해 어느 사용자의 서비스가 종료되었는지 또는 서비스 핸드오프 방식에 의해 클라우드로 다시 전달되었는지 추적한다.

또 다른 일 측면에 있어서, 본 발명에서 제안하는 상호 작용하는 IoT 어플리케이션을 위한 클라우드-포그-클라이언트 삼각 접근 장치는 포그 서비스 요청 기능을 이용하여 클라이언트를 할당된 포그 웹 서비스에 접근시키는 통신부, 상기 클라이언트를 서비스 핸드오프 결정 상태로 변환하고, 포그 응답에서 포그 상태 및 반응 시간을 모니터링 하는 모니터링부, 상기 모니터링 결과에 따라 클라이언트에 서비스를 제공할 경우, 현재 포그 상태를 확인하기 위해 클라우드를 통해 클라이언트에 대한 응답에 명령을 입력하는 명령부, 클라이언트가 포그 상태를 확인하기 위한 상기 명령을 수신한 경우, 클라이언트를 포그 상태 확인 상태로 변환시키고, 포그에 감지 패킷을 전송하는 패킷 전송부 및 상기 전송된 감지 패킷에 대한 반응 및 반응 시간을 분석하는 분석부를 포함한다.

모니터링부는 네트워크 또는 포그 상태가 미리 정해진 기준 이하인 경우, 클라이언트를 클라우드 서비스 요청 상태로 변환 시키고, 후속 요청들을 전송한다.

현재 로드 포화 레벨이 포그 노드가 감당 가능한지 여부를 결정하기 위해 현재 로드 포화 레벨을 모니터링하고, 후속 기간 동안의 로드 포화 레벨을 추정하기 위해 포그 노드를 통해 초당 처리될 수 있는 요청의 수에 대한 서비스 당 요청의 수를 추정한다.

상기 현재 로드 포화 레벨을 계산하기 위해, 포그 노드는 초 당 처리되어야 하는 요청의 수(H)를 초 당 처리될 수 있는 요청의 수(h)로 나누고, 상기 노드에서 초 당 처리되어야 하는 요청의 수(H)는 서비스 당 요청의 수(P)와 초 당 사용자의 평균적인 수(λ)의 곱으로 정의된다.

상기 후속 기간 동안의 로드 포화 레벨을 추정하기 위해, 포그를 통해 사용자 수를 모니터링함으로써 초당 처리될 수 있는 요청의 수를 추정하고, 활성 사용자를 카운트하기 위하여, 포그를 통해 어느 사용자의 서비스가 종료되었는지 또는 서비스 핸드오프 방식에 의해 클라우드로 다시 전달되었는지 추적한다.

본 발명의 실시예들에 따르면 클라우드-포그-클라이언트 삼각 컴퓨팅 방식을 통해 클라우드가 서비스 요청을 포그에 동적으로 전달하고, 포그가 작업 과부하에 걸린 경우에는 태스크를 다시 가져올 수 있다. 또한 제안된 삼각 컴퓨팅 방식을 통해 전체적인 응답 시간 및 코어 네트워크 트래픽을 감소시킬 수 있다.

도 1은 본 발명의 일 실시예에 따른 삼각 컴퓨팅 개념을 나타내는 도면이다.
도 2는 본 발명의 일 실시예에 따른 서비스 서비스 핸드오프에 대한 클라이언트의 동작의 상태를 나타내는 도면이다.
도 3은 본 발명의 일 실시예에 따른 상호 작용하는 IoT 어플리케이션을 위한 클라우드-포그-클라이언트 삼각 접근 방법을 설명하기 위한 흐름도이다.
도 4는 본 발명의 일 실시예에 따른 REST 프레임워크 및 Ajax를 사용하여 구현된 제안된 삼각 컴퓨팅 방식을 설명하기 위한 도면이다.
도 5는 본 발명의 일 실시예에 따른 상호 작용하는 IoT 어플리케이션을 위한 클라우드-포그-클라이언트 삼각 접근 장치를 나타내는 도면이다.
도 6은 본 발명의 일 실시예에 따른 동적 핸드오프 알고리즘을 나타내는 도면이다.
도 7은 본 발명의 일 실시예에 따른 다양한 요청 수의 평균 반응 시간을 나타내는 그래프이다.
도 8은 본 발명의 일 실시예에 따른 다양한 요청 수의 케이스의 반응 시간을 나타내는 그래프이다.
도 9는 본 발명의 일 실시예에 따른 클라우드에 대한 다양한 네트워크 지연이 반응 시간에 미치는 영향을 나타내는 그래프이다.

본 발명은 클라이언트의 센서데이터를 주기적으로 클라우드 서버로 전송하면 클라우드 서버에서 이를 처리하고 그 결과를 실시간으로 클라이언트에 제공하는 HTTP 프로토콜을 따르는 웹 서비스에 있어서 클라우드까지 전송시 소요되는 네트워크 지연시간을 줄이기 위해 클라이언트와 같은 말단네트워크에 존재하는 포그서버를 활용하여 네트워크 지연시간을 감소시키는 방법에 관한 것이다.

포그서버를 활용하는 기존의 방식이 클라우드서버를 포그서버로 대체하는 방식으로 포그서버에 부하가 증가하게 되면 성능확장성을 갖지 못하는 포그서버의 특성으로 인해 서비스 응답속도가 저하된다는 문제가 있다.본 발명에서는 클라우드서버가 클라이언트에 서비스를 제공시 포그 서버를 활용하도록 할 뿐만 아니라 포그서버의 성능상황을 실시간으로 모니터링하도록 함으로써 클라이언트가 동적으로 서비스를 제공하는 서버를 바꿀 수 있도록 하는 클라우드-포그-클라이언트 동적 서비스 핸드오프 방법을 포함하는 것을 특징으로 한다.

도 1은 본 발명의 일 실시예에 따른 삼각 컴퓨팅 개념을 나타내는 도면이다.

복수의 클라이언트(131, 132, 133)가 클라우드 서버(110)와 포그 서버(120)에 접근할 수 있다고 가정한다. 서비스 요청은 앞서 설명된 바와 같이, 다수의 후속 요청들로 구성된다고 가정한다. 모든 클라이언트들(131, 132, 133)은 초기 웹 서비스 요청을 위해 클라우드 서버(110)에 연결한다. 그러면, 클라우드 서버(110)는 클라이언트들(131, 132, 133)을 위해 요청된 웹 서비스를 지원하는 사용 가능한 포그 노드를 감지할 수 있다. 이후, 클라우드 서버(110)는 후속 요청들이 전달되는 서버를 제어하는 초기 응답을 생성할 수 있다. 삼각 컴퓨팅의 기본 개념은 예를 들어, 웹 서버 선택이 동적 네트워크 및 서버의 부하 상태에 기반하여 수행될 수 있는 동적인 서비스 핸드오프(handoff)이다.

유비쿼터스 정보 접근 및 통신은 IoT 기반 스마트 공동체를 위한 필수적인 특징이기 때문에, IoT 어플리케이션을 위하여 클라우드 컴퓨팅에 의지하는 것은 일반적이다. 일반적인 IoT 어플리케이션에서, 클라이언트는 실시간 센서 판독 값에 대응하는 응답을 얻기 위하여 프로세스 요청을 주기적으로 보낼 수 있다. 이러한 종류의 어플리케이션을 양방향 IoT 어플리케이션이라고 부른다. 화재 경보 시스템(예를 들어, 연기감지를 위한 센서 장치와 소방서 신고를 위한 액츄에이터 장치로 이루어진 화재 경보 시스템), 증강 현실(예를 들어, 광학 정보를 습득하는 카메라 장치와 물체 인식 및 관련 정보를 표시하는 기능을 가진 엑츄에이터 장치로 이루어진 증강현실 시스템) 및 네비게이션 어플리케이션(예를 들어, GPS 센서와 해당 위치의 지도 데이터를 표시하는 액츄에이터 장치로 이루어진 네비게이션 시스템)와 같은 경우에 대한 일부 예시들이 있다.

본 발명은 양방향 IoT 어플리케이션에 있어서 그 성능을 향상시키기 위한 삼각 컴퓨팅에 관한 것으로, 포그 노드의 성능확장성 부재 한계를 극복하기 위하여, 클라우드 및 포그 간의 향상된 협업 모델을 제안한다. 본 발명에서, 클라우드는 높은 네트워크 지연 및 높은 처리 용량을 갖는 반면, 포그 노드는 낮은 네트워크 지연 및 낮은 처리 용량을 갖는다고 가정한다.

도 2는 본 발명의 일 실시예에 따른 REST 프레임워크 및 Ajax를 사용하여 구현된 제안된 삼각 컴퓨팅 방식을 설명하기 위한 도면이다.

본 발명의 클라우드 서버는 통상적인 REST 프레임워크와 웹서비스 및 view 이외에 Delegation 관리자와 포그 관리자를 포함한다. 포그관리자는 포그서버의 정보를 관리하고 포그서버와 직접 통신을 통해 현재 포그의 성능 상태 등에 관한 정보를 수집한다. Delegation 관리자는 포그 관리자로부터 얻은 포그 정보를 기반으로 웹서비스가 생성해낸 html 코드에 동적 서비스 핸드오프를 관리할 Java Script 코드를 삽입한다.

포그서버는 역시 통상적인 REST 프레임워크와 웹서비스 및 View 이외에 포그 모니터와 상태 리포터를 포함한다. 포그모니터는 포그서버의 실시간 성능상황을 측정한다. 상태리포터는 클라이언트의 요청에 의해 포그서버내 웹서비스가 생성해낸 XML 이나 JSON 등의 response 코드에 포그의 상태정보를 삽입한다.

도 3은 본 발명의 일 실시예에 따른 서비스 핸드오프에 대한 클라이언트의 동작의 상태를 나타내는 도면이다.

제안된 방식의 두 가지 주된 기능은 포그 모니터링 및 포그-클라우드 핸드오프 메커니즘이다. 상기 두 기능들을 구현하기 위하여, 클라우드는 클라이언트 IP의 네트워크 주소에 기반하여 포그 노드에 접근하고 현재 상태 습득 및 포그 또는 클라이언트 내의 원격 절차 실행을 위하여 클라이언트 및 포그와 통신한다. 통신하기 위하여 클라우드 및 포그에 대한 두 가지 통신 방법, 다시 말해 (1) 클라이언트를 메신저로 활용하는 방법 (2) 포그노드와의 직접통신방법이 있다. 후자는 클라우드노드와 포그노드간의 다양한 정보를 수시로 교환할 수 있는 일반적인 방법이다. 그러므로, 후자는 클라우드가 클라이언트에 응답하기 전에 수행되어야 하는 포그 서비스 발견 및 절충(negotiation) 과정을 위해 필요하다. 그러나, 후자의 경우, 정보는 클라이언트를 거치지 않고 서버간 직접 통신에 의해 이루어 지므로 각 클라이언트의 상태를 반영하지 않는다. 전자의 방법에서, 클라우드는 클라이언트의 상태뿐만 아니라 포그 상태를 얻기 위하여 클라이언트를 메신저로서 사용할 수 있다. 전자는 클라이언트가 포그와 연결될 때만 사용될 수 있다. 전자에 대하여, 초기 서비스 요청에 대한 응답으로서 클라우드에 의해 생성된 Java 스크립트에서 하나의 연결에서 복수의 서버에 접속하는 기술인 크로스-도메인 통신 기술을 사용한다.

Java 스크립트의 역할은 클라이언트와 포그를 모니터링하는 것 및 포그-클라우드 간의 핸드오프(handoff)을 결정하는 것을 포함한다. 이를 위해, AJAX가 웹 페이지들로 하여금 전체 페이지를 재저장하지 않고 요청 및 데이터를 웹 서버들과 교환함으로써 비동기식으로 업데이트되도록 하기 위해, AJAX를 사용한다. 전체 웹 페이지가 클라우드에 의해 제공되게 하고, 웹 페이지의 일부가 클라우드 또는 포그에 의한 새로운 센서 판독에 대해 업데이트될 수 있도록 한다. 클라이언트는 AJAX 명령을 통하여 센서 판독을 클라우드 또는 포그에 전달할 수 있고, 클라우드 및 포그는 Java script로 정의된 콜백 함수들을 통하여 서버 정보를 전달할 수 있다. 이 방식의 장점은 클라이언트에 임의의 추가적인 변형을 요구하지 않는다는 것이다.

위임 관리자에 의해 생성된 클라이언트 코드 내 기능들은 포그 서비스 요청(310) 기능, 포그 성능에 기반한 서비스 핸드오프 결정 상태로 변환(320), 클라우드 서비스 요청(330) 및 포그 상태 체크(340) 기능을 포함한다. 도 3를 참조하면, 서비스 핸드오프에 대한 클라이언트의 동작의 상태 다이어그램을 도시한다. 포그 서비스 요청(310) 기능에 대해, 클라이언트는 포그 서비스 요청 기능을 이용하여 할당된 포그 웹 서비스에 접근한다. 그리고 나서, 클라이언트는 서비스 핸드오프 결정 상태로 변환(320)하고, 포그 응답에(311)서 포그 상태 및 반응 시간을 모니터링한다. 이후, 네트워크 또는 포그 상태가 good(312)이면, 포그 서비스 요청(310) 상태로 다시 변화하고, 네트워크 또는 포그 상태가 bad(321)이면, 클라이언트는 클라우드 서비스 요청(330) 상태로 변화하고, 후속 요청들을 보낸다. 클라우드가 클라이언트에 서비스를 제공할 때, 현재 포그 상태를 간헐적으로 확인하기 위하여, 클라우드는 클라이언트에 대한 응답(331)에 명령을 입력할 수 있다. 클라이언트가 포그 상태를 확인하기 위한 명령을 받았을 때, 클라이언트는 포그 상태 체크(340) 상태로 변화하고, 포그에 감지 패킷(probing packet), 다시 말해 good(341)을 보내고, 포그로부터의 반응 및 반응 시간을 분석한다. 포그 상태가 bad(332)인 경우 다시 클라우드 서비스 요청(330) 상태로 변화할 수 있다.

도 4는 본 발명의 일 실시예에 따른 상호 작용하는 IoT 어플리케이션을 위한 클라우드-포그-클라이언트 삼각 접근 방법을 설명하기 위한 흐름도이다.

제안하는 상호 작용하는 IoT 어플리케이션을 위한 클라우드-포그-클라이언트 삼각 접근 방법은 포그 서비스 요청 기능을 이용하여 클라이언트를 할당된 포그 웹 서비스에 접근시키는 단계(410), 상기 클라이언트를 서비스 핸드오프 결정 상태로 변환하고, 포그 응답에서 포그 상태 및 반응 시간을 모니터링 하는 단계(420), 상기 모니터링 결과에 따라 클라이언트에 서비스를 제공할 경우, 현재 포그 상태를 확인하기 위해 클라우드를 통해 클라이언트에 대한 응답에 명령을 입력하는 단계(430), 클라이언트가 포그 상태를 확인하기 위한 상기 명령을 수신한 경우, 클라이언트를 포그 상태 확인 상태로 변환시키고, 포그에 감지 패킷을 전송하는 단계(440) 및 상기 전송된 감지 패킷에 대한 반응 및 반응 시간을 분석하는 단계(450)를 포함한다.

클라이언트를 서비스 핸드오프 결정 상태로 변환하고, 포그 응답에서 포그 상태 및 반응 시간을 모니터링 하는 단계는(420)는 네트워크 또는 포그 상태가 미리 정해진 기준 이하인 경우, 클라이언트를 클라우드 서비스 요청 상태로 변환 시키고, 후속 요청들을 전송하는 단계를 포함한다.

클라이언트를 서비스 핸드오프 결정 상태로 변환하고, 포그 응답에서 포그 상태 및 반응 시간을 모니터링 하는 단계는 현재 로드 포화 레벨이 포그 노드가 감당 가능한지 여부를 결정하기 위해 현재 로드 포화 레벨을 모니터링하는 단계 및 후속 기간 동안의 로드 포화 레벨을 추정하기 위해 포그 노드를 통해 초당 처리될 수 있는 요청의 수에 대한 서비스 당 요청의 수를 추정하는 단계를 포함한다.

이때, 상기 현재 로드 포화 레벨을 계산하기 위해, 포그 노드는 초 당 처리되어야 하는 요청의 수(H)를 초 당 처리될 수 있는 요청의 수(h)로 나누고, 상기 노드는 초 당 처리되어야 하는 요청의 수(H)는 서비스 당 요청의 수(P)와 초 당 사용자의 평균적인 수(λ)의 곱으로 정의된다.

다시 말해, 포그 노드는 현재 로드 포화 레벨이 감당 가능한 것인지 결정하기 위하여 현재 로드 포화 레벨을 모니터링해야 한다. 포화 레벨 정보는, 클라우드가 직접적으로 포그가 감당 가능한지 확인할 때는 클라우드에, 포그가 요청된 데이터를 가지고 클라이언트에 응답하거나 할당된 포그 확인 명령이 수신될 때는 클라이언트에 제공된다. 부하 포화 레벨을 계산하기 위하여, 포그는 초 당 처리될 수 있는 요청의 수(h)로 나눠진 초 당 처리되어야 하는 요청의 수(H)를 알아야 한다. 초 당 처리되어야 하는 요청의 수(H)는 서비스 당 요청의 수(P)와 초 당 사용자의 평균적인 수(λ)의 곱으로 정의된다.

또한, 후속 기간 동안의 로드 포화 레벨을 추정하기 위해, 포그를 통해 사용자 수를 모니터링함으로써 초당 처리될 수 있는 요청의 수에 대한 서비스 당 요청의 수를 추정하고, 활성 사용자를 카운트하기 위하여, 포그를 통해 어느 사용자의 서비스가 종료되었는지 또는 서비스 핸드오프 방식에 의해 클라우드로 다시 전달되었는지 추적한다.

다시 말해, 후속 기간 동안의 부하 포화 레벨을 추정하기 위하여, 포그는 주어진 W 및 h에 대한 P 및 Y를 획득해야 한다. 여기서 W는 모니티링하고자 하는 일정한 기간(상술한, 후속 기간)을 의미할 수 있으며, Y는 초당 평균 사용자수(λ)를 의미할 수 있다. 클라우드는 P를 추정할 수 있다고 가정될 수 있고, P는 요청된 서비스의 특징에 포함되기 때문에 P를 포그에 알릴 수 있다. 포그는 사용자 수를 모니터링함으로써 W에 대한 Y를 추정한다. 활성 사용자를 카운트하기 위하여, 포그는 어느 사용자의 서비스가 마쳐졌는지 또는 서비스 핸드오프 방식에 의해 클라우드로 다시 전달되었는지 추적해야 한다. 포그 사용자의 추적 대신 보다 간단한 방식으로 포그 노드의 부하를 측정하기 위해 클라이언트가 후속 서비스를 요청할 때 이전 서비스의 반응시간을 피드백으로 포그에 알려 줄 수 있다. 간단하게, 반응 시간 피드백이 임계값 이상이면, 포그는 포화된 것으로 가정될 수 있다. 제안하는 상호 작용하는 IoT 어플리케이션을 위한 클라우드-포그-클라이언트 삼각 접근 방법에 대하여 도 4를 참조하여 더욱 상세히 설명한다.

다시 도 2를 참조하여, 본 발명의 일 실시예에 따른 REST 프레임워크 및 Ajax를 사용하여 구현된 제안된 삼각 컴퓨팅 방식을 설명한다. REST(Representational State Transfer)는 웹 서비스 구현에 대해 대중적으로 선택되는 소프트웨어 아키텍처 양식이다. REST는 Http 동사(예를 들어, GET, POST, PUT, DELETE)와 같은 비상태의(stateless) 표준적인 작업을 사용하여 단일 웹 서비스에 주소를 지정하는 단일성 및 많은 수의 컴포넌트들과, 컴포넌트들 사이의 인터페이스 변화없이 컴포넌트 간 상호 작용을 지원하는 확장성을 가지는 장점이 있다. 클라우드 및 포그 웹 서비스 구현을 위하여, Django rest framework를 사용할 수 있다.

도 2는 REST 프레임워크 및 Ajax를 사용하여 구현된 제안된 삼각 컴퓨팅 방식을 도시한다. 웹 서비스는 클라이언트 브라우저(210)가 사용자 인터페이스를 통해 http 요청을 클라우드(220)에 보내는 경우에 시작한다(1). 포그 관리자는 요청이 포그(230)에 의해 지원될 수 있는지 확인하기 위하여 REST 아키텍처를 통해 포그 모니터에 접근한다(2). 포그는 현재 자원을 확인하고 포그 관리자에 응답한다(3). 포그 관리자가 포그로부터 긍정적인 응답을 얻으면, 위임 관리자는 크로스-도메인 Ajax 요청을 포함하는 java 스크립트 코드를 웹 서비스에 의해 생성된 응답에 삽입한다(4). 클라이언트 브라우저(210) 내의 사용자 인터페이스는 Java 스크립트 호출을AJAX 엔진에 보낸다(5). AJAX 엔진은 데이터 요청을 포그에 보내고 보통 JSON 또는 XML 포맷인 데이터 응답을 얻는다((6) (7)). 포그(230)로부터의 응답은 포그 상태 기록자에 의해 삽입된 포그 상태 정보를 포함한다. 그러면, AJAX 엔진은 응답 데이터를 포함하는 전체적인 html 페이지를 생성한다(8). 포그가 포그 서비스는 더 이상 이용 가능하지 않은 상태라고 응답한다면, AJAX 엔진은 포그 대신에 업데이트된 데이터에 대하여 클라우드에 접근한다(9). 위임 관리자는 클라이언트로 하여금 초기 html 반응 내에서, Java 스크립트를 사용하여 포그 상태를 확인하기 위해 명령을 내리거나 반응 시간을 모니터링하게 할 수 있다. 포그 상태 및 반응 시간이 good 상태이면, 서비스 태스크는 다시 포그로 핸드오프될 수 있다. 그러므로, 단계 (4) 및 (9)는 포그 상태에 따라 동적으로 수행될 수 있다. 이것을 동적 핸드오프(dynamic handoff)이라고 부른다.

도 5는 본 발명의 일 실시예에 따른 상호 작용하는 IoT 어플리케이션을 위한 클라우드-포그-클라이언트 삼각 접근 장치를 나타내는 도면이다.

제안하는 상호 작용하는 IoT 어플리케이션을 위한 클라우드-포그-클라이언트 삼각 접근 장치는 포그 서비스 요청 기능을 이용하여 클라이언트를 할당된 포그 웹 서비스에 접근시키는 통신부(510), 상기 클라이언트를 서비스 핸드오프 결정 상태로 변환하고, 포그 응답에서 포그 상태 및 반응 시간을 모니터링 하는 모니터링부(520), 상기 모니터링 결과에 따라 클라이언트에 서비스를 제공할 경우, 현재 포그 상태를 확인하기 위해 클라우드를 통해 클라이언트에 대한 응답에 명령을 입력하는 명령부(530), 클라이언트가 포그 상태를 확인하기 위한 상기 명령을 수신한 경우, 클라이언트를 포그 상태 확인 상태로 변환시키고, 포그에 감지 패킷을 전송하는 패킷 전송부(540) 및 상기 전송된 감지 패킷에 대한 반응 및 반응 시간을 분석하는 분석부(550)를 포함한다.

모니터링부(520)는 네트워크 또는 포그 상태가 미리 정해진 기준 이하인 경우, 클라이언트를 클라우드 서비스 요청 상태로 변환 시키고, 후속 요청들을 전송하는 단계를 포함한다.

모니터링부(520)는 현재 로드 포화 레벨이 포그 노드가 감당 가능한지 여부를 결정하기 위해 현재 로드 포화 레벨을 모니터링하고, 후속 기간 동안의 로드 포화 레벨을 추정하기 위해 포그 노드를 통해 초당 처리될 수 있는 요청의 수에 대한 서비스 당 요청의 수를 추정한다.

이때, 상기 현재 로드 포화 레벨을 계산하기 위해, 포그 노드는 초 당 처리되어야 하는 요청의 수(H)를 초 당 처리될 수 있는 요청의 수(h)를 나누고, 상기 노드는 초 당 처리되어야 하는 요청의 수(H)는 서비스 당 요청의 수(P)와 초 당 사용자의 평균적인 수(λ)의 곱으로 정의된다.

다시 말해, 포그 노드는 현재 로드 포화 레벨이 감당 가능한 것인지 결정하기 위하여 현재 로드 포화 레벨을 모니터링해야 한다. 포화 레벨 정보는, 클라우드가 직접적으로 포그가 감당 가능한지 확인할 때는 클라우드에, 포그가 요청된 데이터를 가지고 클라이언트에 응답하거나 할당된 포그 확인 명령이 수신될 때는 클라이언트에 제공된다. 부하 포화 레벨을 계산하기 위하여, 포그는 초 당 처리될 수 있는 요청의 수(h)로 나눠진 초 당 처리되어야 하는 요청의 수(H)를 알아야 한다. 초 당 처리되어야 하는 요청의 수(H)는 서비스 당 요청의 수(P)와 초 당 사용자의 평균적인 수(λ)의 곱으로 정의된다.

또한, 후속 기간 동안의 로드 포화 레벨을 추정하기 위해, 포그를 통해 사용자 수를 모니터링함으로써 초당 처리될 수 있는 요청의 수에 대한 서비스 당 요청의 수를 추정하고, 활성 사용자를 카운트하기 위하여, 포그를 통해 어느 사용자의 서비스가 종료되었는지 또는 서비스 핸드오프 방식에 의해 클라우드로 다시 전달되었는지 추적한다.

다시 말해, 후속 기간 동안의 부하 포화 레벨을 추정하기 위하여, 포그는 주어진 W 및 h에 대한 P 및 Y를 획득해야 한다. 클라우드는 P를 추정할 수 있다고 가정될 수 있고, P는 요청된 서비스의 특징에 포함되기 때문에 P를 포그에 알릴 수 있다. 포그는 사용자 수를 모니터링함으로써 W에 대한 Y를 추정한다. 활성 사용자를 카운트하기 위하여, 포그는 어느 사용자의 서비스가 마쳐졌는지 또는 서비스 핸드오프 방식에 의해 클라우드로 다시 전달되었는지 추적해야 한다. 포그 사용자의 추적 대신 보다 간단한 방식으로 포그 노드의 부하를 측정하기 위해 클라이언트가 후속 서비스를 요청할 때 이전 서비스의 반응시간을 피드백으로 포그에 알려 줄 수 있다. 간단하게, 반응 시간 피드백이 임계값 이상이면, 포그는 포화된 것으로 가정될 수 있다.

도 6은 본 발명의 일 실시예에 따른 동적 서비스 핸드오프 알고리즘을 나타내는 도면이다.

REST 프레임워크 및 Ajax를 사용하여 구현된 제안된 삼각 컴퓨팅 방식을 도시한다. 웹 서비스는 클라이언트 브라우저가 사용자 인터페이스를 통해 http 요청을 클라우드에 보내는 경우에 시작한다. 포그 관리자는 요청이 포그에 의해 지원될 수 있는지 확인하기 위하여 REST 아키텍처를 통해 포그 모니터에 접근한다. 포그는 현재 자원을 확인하고 포그 관리자에 응답한다. 포그 관리자가 포그로부터 긍정적인 응답을 얻으면, 위임 관리자는 크로스-도메인 Ajax 요청을 포함하는 java 스크립트 코드를 웹 서비스에 의해 생성된 응답에 삽입한다. 클라이언트 브라우저 내의 사용자 인터페이스는 Java 스크립트 호출을AJAX 엔진에 보낸다 AJAX 엔진은 데이터 요청을 포그에 보내고 보통 JSON 또는 XML 포맷인 데이터 응답을 얻는다. 포그로부터의 응답은 포그 상태 기록자에 의해 삽입된 포그 상태 정보를 포함한다. 그러면, AJAX 엔진은 응답 데이터를 포함하는 전체적인 html 페이지를 생성한다. 포그가 포그 서비스는 더 이상 이용 가능하지 않은 상태라고 응답한다면, AJAX 엔진은 포그 대신에 업데이트된 데이터에 대하여 클라우드에 접근한다(9). 위임 관리자는 클라이언트로 하여금 초기 html 반응 내에서, Java 스크립트를 사용하여 포그 상태를 확인하기 위해 명령을 내리거나 반응 시간을 모니터링하게 할 수 있다. 포그 상태 및 반응 시간이 good 상태이면, 서비스 태스크는 다시 포그로 핸드오프될 수 있다. 그러므로, 단계 (4) 및 (9)는 포그 상태에 따라 동적으로 수행될 수 있다. 이것을 동적 핸드오프(dynamic handoff)라고 부른다.

도 7은 본 발명의 일 실시예에 따른 다양한 요청 수의 평균 반응 시간을 나타내는 그래프이다.

두 가지 종래 접근 방법, (1) 포그에서만 수행되는 서비스(fog only) (2) 클라우드에서만 수행되는 서비스(cloud only) 간의 비교를 통해 제안된 방식의 효과를 보인다.

도 7에서, 다양한 요청 수에 따른 제안된 방식의 평균 반응 시간이 도시된다. 클라우드에서만 수행되는 서비스와 비교할 때, 제안된 방식은 현존하는 클라우드에서만 수행되는 서비스 및 포그에서만 수행되는 서비스보다 성능이 뛰어나다. 요청의 수가 적은 경우, 포그 노드 처리 용량이 모든 요청들을 감당할 정도로 충분히 크기 때문에, 포그에서만 수행되는 서비스와 제안된 방식은 가장 낮은 반응 시간(500ms)을 보인다. 그러나, 요청의 수가 증가하는 경우, 포그 노드는 처리 용량 부족을 겪는다. 결과적으로, 반응 시간은 급격하게 증가한다. 클라우드에서만 수행되는 서비스의 경우, 요청의 수가 적더라도, 요청들이 클라우드로 전달되기 때문에 높은 네트워크 지연에 의해 반응 시간이 높다. 그러나, 클라우드의 처리 용량은 충분히 크다고 가정되므로, 반응 시간은 요청의 수가 증가하는 경우라도 눈에 띄게 변화하지 않는다. 제안된 방식에서, 요청의 수가 적은 경우, 대부분의 요청들은 포그로 전달될 것이다. 본 방식은 반응 시간을 감소시키기 위하여 포그 컴퓨팅의 짧은 네트워크 전달 시간을 이용한다. 요청의 수가 증가함에 따라, 포그 노드는 용량 부족을 겪게 되기 때문에, 제안된 방식은 반응 시간을 모니터링하고 일부 요청들을 클라우드에 전달한다. 일부 요청들이 클라우드에 전달될 때, 포그 상의 부하는 급격히 증가하지 않고, 포그 처리 용량은 남은 부하를 감당할 수 있다. 처리 시간의 이득은 클라우드에 전달되는 일부 요청들이 높은 네트워크 지연을 겪는다고 하더라도, 전체적인 반응 시간을 감소시키는 결과를 낳는다. 클라우드는 클라이언트에 포그 확인 명령을 보낼지 결정하는 클라우드 임계값을 최적화해야 한다. 포그 확인이 매우 드물게 수행된다면, 용량이 충분함에도 불구하고, 포그는 적게 사용될 것이다. 임계값이 너무 높다면, 불필요한 감지 패킷이 엣지 네트워크 내에 발생한다. 최적화된 임계값에 의해 포그 상태 확인을 할 수 있고 클라우드는 포그 상태가 충분히 good인 경우 후속 요청들을 다시 전달할 수 있다. 유사한 결과들은 사용자 도착율의 경우에도 관찰된다.

도 8은 본 발명의 일 실시예에 따른 다양한 사용자 도착율 (λ)의 케이스의 반응 시간을 나타내는 그래프이다.

도 8에서, 3가지 케이스의 반응 시간은 λ가 변할 때의 네트워크 지연 및 CPU 처리 시간으로 분석된다. 클라우드에서만 수행되는 서비스의 경우, 클라우드가 충분한 처리 용량을 갖고 있기 때문에 대부분의 반응 시간 지연은 요청의 수와는 관련없이 네트워크 지연에 의해 발생된다. 그러나, 포그에서만 수행되는 서비스의 경우, λ가 작을 때, 네트워크 지연이 반응 시간에 영향을 미치지 않으므로 포그노드가 클라이언트와 같은 엣지 네트워크에 존재하는 이점을 보인다. 그러나, 더 많은 요청들이 포그로 들어올수록, CPU 처리 시간뿐만 아니라 네트워크 시간도 증가한다. 이는 요청 패킷 트래픽이 포그 노드의 네트워크 인터페이스 용량을 초과했기 때문이다. 제안된 방식에서, λ가 작은 경우, 반응 시간은 대부분 CPU 시간으로 구성된다. 클라이언트의 수가 증가함에 따라, 요청들의 일부가 클라우드로 전달되기 때문에, 네트워크 시간 또한 증가한다. 요청들의 일부가 클라우드 내에서 처리되기 때문에, CPU 시간은 포그에서만 수행되는 서비스의 경우보다 낮게 유지된다.

도 9은 본 발명의 일 실시예에 따른 클라우드에 대한 다양한 네트워크 지연이 반응 시간에 미치는 영향을 나타내는 그래프이다.

네트워크 지연이 증가됨에 따라, 포그에서만 수행되는 서비스 경우는 영향이 없는 반면, 클라우드에서만 수행되는 서비스 경우의 반응 시간은 증가한다. 제안된 방식에서, 네트워크 지연은 심각하지 않고, 많은 요청들은 포그 오버헤드를 피하기 위하여 클라우드로 전달된다. 결과적으로, 제안된 방식은 포그에서만 수행되는 서비스 경우보다 우수한 성능을 보인다. 네트워크가 지연됨에 따라, 클라우드에서 처리되는 요청들의 반응 시간이 증가하기 때문에 전체적인 반응 시간은 증가한다. 그러나, 높은 네트워크 지연의 영향을 분산시키기 위하여, 제안된 방식은 더 많은 요청들을 포그로 보낸다.

이와 같이 제안된 삼각 컴퓨팅 방식은 포그 노드의 제한된 처리 용량 및 낮은 네트워크 지연 이점을 모두 고려한다. 제안된 방식은 기존의 접근 방법에 비해 우수한 성능을 보인다.

이상에서 설명된 장치는 하드웨어 구성요소, 소프트웨어 구성요소, 및/또는 하드웨어 구성요소 및 소프트웨어 구성요소의 조합으로 구현될 수 있다. 예를 들어, 실시예들에서 설명된 장치 및 구성요소는, 예를 들어, 프로세서, 콘트롤러, ALU(arithmetic logic unit), 디지털 신호 프로세서(digital signal processor), 마이크로컴퓨터, FPA(field programmable array), PLU(programmable logic unit), 마이크로프로세서, 또는 명령(instruction)을 실행하고 응답할 수 있는 다른 어떠한 장치와 같이, 하나 이상의 범용 컴퓨터 또는 특수 목적 컴퓨터를 이용하여 구현될 수 있다. 처리 장치는 운영 체제(OS) 및 상기 운영 체제 상에서 수행되는 하나 이상의 소프트웨어 애플리케이션을 수행할 수 있다.　 또한, 처리 장치는 소프트웨어의 실행에 응답하여, 데이터를 접근, 저장, 조작, 처리 및 생성할 수도 있다.　 이해의 편의를 위하여, 처리 장치는 하나가 사용되는 것으로 설명된 경우도 있지만, 해당 기술분야에서 통상의 지식을 가진 자는, 처리 장치가 복수 개의 처리 요소(processing element) 및/또는 복수 유형의 처리 요소를 포함할 수 있음을 알 수 있다.　 예를 들어, 처리 장치는 복수 개의 프로세서 또는 하나의 프로세서 및 하나의 콘트롤러를 포함할 수 있다.　 또한, 병렬 프로세서(parallel processor)와 같은, 다른 처리 구성(processing configuration)도 가능하다.

소프트웨어는 컴퓨터 프로그램(computer program), 코드(code), 명령(instruction), 또는 이들 중 하나 이상의 조합을 포함할 수 있으며, 원하는 대로 동작하도록 처리 장치를 구성하거나 독립적으로 또는 결합적으로(collectively) 처리 장치를 명령할 수 있다.　 소프트웨어 및/또는 데이터는, 처리 장치에 의하여 해석되거나 처리 장치에 명령 또는 데이터를 제공하기 위하여, 어떤 유형의 기계, 구성요소(component), 물리적 장치, 가상 장치(virtual equipment), 컴퓨터 저장 매체 또는 장치에 구체화(embody)될 수 있다.　 소프트웨어는 네트워크로 연결된 컴퓨터 시스템 상에 분산되어서, 분산된 방법으로 저장되거나 실행될 수도 있다. 소프트웨어 및 데이터는 하나 이상의 컴퓨터 판독 가능 기록 매체에 저장될 수 있다.

실시예에 따른 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다.　 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다.　 상기 매체에 기록되는 프로그램 명령은 실시예를 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다.　 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다.　 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다.　

이상과 같이 실시예들이 비록 한정된 실시예와 도면에 의해 설명되었으나, 해당 기술분야에서 통상의 지식을 가진 자라면 상기의 기재로부터 다양한 수정 및 변형이 가능하다.　 예를 들어, 설명된 기술들이 설명된 방법과 다른 순서로 수행되거나, 및/또는 설명된 시스템, 구조, 장치, 회로 등의 구성요소들이 설명된 방법과 다른 형태로 결합 또는 조합되거나, 다른 구성요소 또는 균등물에 의하여 대치되거나 치환되더라도 적절한 결과가 달성될 수 있다.

그러므로, 다른 구현들, 다른 실시예들 및 특허청구범위와 균등한 것들도 후술하는 특허청구범위의 범위에 속한다.

Claims (10)

1. 포그 서비스 요청 기능을 이용하여 클라이언트를 할당된 포그 웹 서비스에 접근시키는 단계;
   상기 클라이언트를 서비스 핸드오프 결정 상태로 변환하고, 포그 응답에서 포그 상태 및 반응 시간을 모니터링 하는 단계;
   상기 모니터링 결과에 따라 클라이언트에 서비스를 제공할 경우, 현재 포그 상태를 확인하기 위해 클라우드를 통해 클라이언트에 대한 응답에 명령을 입력하는 단계;
   클라이언트가 포그 상태를 확인하기 위한 상기 명령을 수신한 경우, 클라이언트를 포그 상태 확인 상태로 변환시키고, 포그에 감지 패킷을 전송하는 단계; 및
   상기 전송된 감지 패킷에 대한 반응 및 반응 시간을 분석하는 단계
   를 포함하는 클라우드-포그-클라이언트 삼각 접근 방법.
2. 제1항에 있어서,
   상기 클라이언트를 서비스 핸드오프 결정 상태로 변환하고, 포그 응답에서 포그 상태 및 반응 시간을 모니터링 하는 단계는,
   네트워크 또는 포그 상태가 미리 정해진 기준 이하인 경우, 클라이언트를 클라우드 서비스 요청 상태로 변환 시키고, 후속 요청들을 전송하는 단계
   를 포함하고,
   반응 시간이 임계값 이상인 경우, 포그는 포화된 것으로 가정하는
   클라우드-포그-클라이언트 삼각 접근 방법.
3. 제1항에 있어서,
   상기 클라이언트를 서비스 핸드오프 결정 상태로 변환하고, 포그 응답에서 포그 상태 및 반응 시간을 모니터링 하는 단계는,
   현재 로드 포화 레벨이 포그 노드가 감당 가능한지 여부를 결정하기 위해 현재 로드 포화 레벨을 모니터링하는 단계; 및
   후속 기간 동안의 로드 포화 레벨을 추정하기 위해 포그 노드를 통해 초당 처리될 수 있는 요청의 수에 대한 서비스 당 요청의 수를 추정하는 단계
   를 포함하는 클라우드-포그-클라이언트 삼각 접근 방법.
4. 제3항에 있어서,
   상기 현재 로드 포화 레벨을 계산하기 위해, 포그 노드는 초 당 처리되어야 하는 요청의 수(H)를 초 당 처리될 수 있는 요청의 수(h)로 나누고, 상기 노드에서 초 당 처리되어야 하는 요청의 수(H)는 서비스 당 요청의 수(P)와 초 당 사용자의 평균적인 수(λ)의 곱으로 정의되는
   클라우드-포그-클라이언트 삼각 접근 방법.
5. 제3항에 있어서,
   상기 후속 기간 동안의 로드 포화 레벨을 추정하기 위해, 포그를 통해 사용자 수를 모니터링함으로써 초당 처리될 수 있는 요청의 수에 대한 서비스 당 요청의 수를 추정하고, 활성 사용자를 카운트하기 위하여, 포그를 통해 어느 사용자의 서비스가 종료되었는지 또는 서비스 핸드오프 방식에 의해 클라우드로 다시 전달되었는지 추적하는
   클라우드-포그-클라이언트 삼각 접근 방법.
6. 포그 서비스 요청 기능을 이용하여 클라이언트를 할당된 포그 웹 서비스에 접근시키는 통신부;
   상기 클라이언트를 서비스 핸드오프 결정 상태로 변환하고, 포그 응답에서 포그 상태 및 반응 시간을 모니터링 하는 모니터링부;
   상기 모니터링 결과에 따라 클라이언트에 서비스를 제공할 경우, 현재 포그 상태를 확인하기 위해 클라우드를 통해 클라이언트에 대한 응답에 명령을 입력하는 명령부;
   클라이언트가 포그 상태를 확인하기 위한 상기 명령을 수신한 경우, 클라이언트를 포그 상태 확인 상태로 변환시키고, 포그에 감지 패킷을 전송하는 패킷 전송부; 및
   상기 전송된 감지 패킷에 대한 반응 및 반응 시간을 분석하는 분석부
   를 포함하는 클라우드-포그-클라이언트 삼각 접근 장치.
7. 제6항에 있어서,
   모니터링부는,
   네트워크 또는 포그 상태가 미리 정해진 기준 이하인 경우, 클라이언트를 클라우드 서비스 요청 상태로 변환 시키고, 후속 요청들을 전송하고, 반응 시간이 임계값 이상인 경우, 포그는 포화된 것으로 가정하는
   클라우드-포그-클라이언트 삼각 접근 장치.
8. 제6항에 있어서,
   분석부는,
   현재 로드 포화 레벨이 포그 노드가 감당 가능한지 여부를 결정하기 위해 현재 로드 포화 레벨을 모니터링하고, 후속 기간 동안의 로드 포화 레벨을 추정하기 위해 포그 노드를 통해 초당 처리될 수 있는 요청의 수에 대한 서비스 당 요청의 수를 추정하는
   클라우드-포그-클라이언트 삼각 접근 장치.
9. 제8항에 있어서,
   상기 현재 로드 포화 레벨을 계산하기 위해, 포그 노드는 초 당 처리되어야 하는 요청의 수(H)를 초 당 처리될 수 있는 요청의 수(h)로 나누고, 상기 노드에서 초 당 처리되어야 하는 요청의 수(H)는 서비스 당 요청의 수(P)와 초 당 사용자의 평균적인 수(λ)의 곱으로 정의되는
   클라우드-포그-클라이언트 삼각 접근 장치.
10. 제8항에 있어서,
    상기 후속 기간 동안의 로드 포화 레벨을 추정하기 위해, 포그를 통해 사용자 수를 모니터링함으로써 초당 처리될 수 있는 요청의 수에 대한 서비스 당 요청의 수를 추정하고, 활성 사용자를 카운트하기 위하여, 포그를 통해 어느 사용자의 서비스가 종료되었는지 또는 서비스 핸드오프 방식에 의해 클라우드로 다시 전달되었는지 추적하는
    클라우드-포그-클라이언트 삼각 접근 장치.

Images