KR20190064066A - IoT 로컬 네트워크에서 CoAP 기반의 트래픽 부하 관리 장치 및 방법 - Google Patents

IoT 로컬 네트워크에서 CoAP 기반의 트래픽 부하 관리 장치 및 방법 Download PDF

Info

Publication number
KR20190064066A
KR20190064066A KR1020170163340A KR20170163340A KR20190064066A KR 20190064066 A KR20190064066 A KR 20190064066A KR 1020170163340 A KR1020170163340 A KR 1020170163340A KR 20170163340 A KR20170163340 A KR 20170163340A KR 20190064066 A KR20190064066 A KR 20190064066A
Authority
KR
South Korea
Prior art keywords
message
traffic load
load management
resource
server
Prior art date
Application number
KR1020170163340A
Other languages
English (en)
Other versions
KR102042027B1 (ko
Inventor
김의직
이솔비
권정혁
Original Assignee
한림대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 한림대학교 산학협력단 filed Critical 한림대학교 산학협력단
Priority to KR1020170163340A priority Critical patent/KR102042027B1/ko
Publication of KR20190064066A publication Critical patent/KR20190064066A/ko
Application granted granted Critical
Publication of KR102042027B1 publication Critical patent/KR102042027B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1029—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers using data related to the state of servers by a load balancer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

IoT (Internet of Things) 로컬 네트워크에서 CoAP(Constrained Application Protocol) 기반의 트래픽 부하 관리 방법에 관한 것이며, 트래픽 부하 관리 방법은, 트래픽 부하 관리 장치에서, 서버 그룹에 포함된 복수의 서버로부터 수신한 등록 메시지 및/또는 업데이트 메시지를 통합하여 통합 메시지를 생성하는 단계; 및 상기 트래픽 부하 관리 장치에서, 생성된 상기 통합 메시지를 리소스 디렉토리(Resource Directory)로 전송하는 단계를 포함하고, 상기 리소스 디렉토리로 전송된 통합 메시지에 의하여, 상기 통합 메시지와 관련된 복수의 메시지들을 전송한 서버의 리소스 엔트리가 상기 리소스 디렉토리에 등록 및/또는 업데이트될 수 있다.

Description

IoT 로컬 네트워크에서 CoAP 기반의 트래픽 부하 관리 장치 및 방법 {TRAFFIC LOAD MANAGEMENT APPARATUS AND METHOD BASED ON COORDINATED APPLICATION PROTOCOL FOR INTERNET OF THINGS LOCAL NETWORKS}
본원은 대규모 IoT(Internet of Things) 로컬 네트워크에서 중앙집중식 리소스 검색 접근법을 사용하여 확장성 문제를 해결하기 위한 CoAP(Constrained Application Protocol) 기반의 트래픽 부하 관리 장치 및 방법에 관한 것이다.
최근 IoT(Internet of Things)에 대한 관심이 급속히 증가하고 있으며, IoT 기술이 더욱 보편화되고 있다. IoT는 일반적으로 스마트 도시, 스마트 팩토리 및 스마트 팜과 같은 대규모 모니터링 응용 프로그램의 주요 기술로 간주된다. 이러한 대규모 어플리케이션에서 IoT 로컬 네트워크는 제한된 배터리, 메모리 및 CPU와 같은 제한된 물리적 자원을 갖춘 다수의 장치로 구성되며 무선 센서 네트워크 (WSN)와 유사하다.
IETF(Internet Engineering Task Force)의 CoRE 워킹 그룹은 배터리, 메모리 및 CPU와 같은 제약된 어플리케이션 프로토콜(Constrained Application Protocol, CoAP)을 개발하여 표준화했다. CoAP은 IoT 로컬 네트워크의 리소스 제한적인 디바이스를 위한 경량 웹 전송 프로토콜을 의미하며, 작은 헤더 크기를 유지하고, user datagram protocol(UDP)에서 동작한다.
CoAP에서 리소스 검색은 클라이언트가 서버에서 필요한 리소스를 얻는데 필요한 필수적인 절차이다. CoAP 리소스 검색에는 분산 및 중앙집중식 리소스 검색의 두 가지 유형이 있다. 분산 리소스 검색은 클라이언트가 특정 서버에 직접 질의하는 방법으로서, 이 방법은 클라이언트가 인터넷 프로토콜(IP) 주소와 복수의 호스트 이름을 알아야하기 때문에 대규모 IoT 로컬 네트워크에는 적합하지 않은 단점이 있다.
반면에, 중앙집중식 리소스 검색은 에너지 효율성을 위해 서버에 RD 엔트리로 알려진 일련의 웹 링크를 유지 관리하는 리소스 디렉토리(resource directory, RD)를 사용한다. RD를 사용하는 이러한 중앙집중식 방법은 분산 리소스 검색과 마찬가지로 대규모 IoT 로컬 네트워크에서 사용될 때 낮은 확장성으로 어려움을 겪는 문제가 있다. 대규모 IoT 로컬 네트워크에서는 많은 수의 서버가 주기적으로 RD에 업데이트 메시지를 보내 리소스 엔트리를 최신 상태로 유지한다. 그러나 RD는 무선 링크의 제한된 대역폭 때문에 모든 업데이트 메시지를 받을 여력이 없는 문제가 있다. 또한, RD에서는 트래픽 부하가 많이 증가함에 따라 메시지 손실, 네트워크 정체 및 병목 현상과 같은 문제가 나타나게 된다. 따라서, IoT 로컬 네트워크 환경에서의 확장성 문제를 극복하기 위해서는 RD를 위한 부하 밸런싱(Load Balancing) 메커니즘이 필요한 실정이다.
위와 같은 문제점들을 해결하기 위해, 종래에 리소스 검색 및 RD에 대한 많은 연구가 수행된 바 있다.
일예로, 논문["A Proactive Trickle-based Mechanism for Discovering CoRE Resource Directories", Badis Djamaa and Ali Yachir, Procedia Computer Science 83 (2016) 115-122]에서는 적응적 트리클(trickle) 타이머를 기반으로 하는 선행적 RD 탐색(proactive RD discovery, PRD) 메커니즘을 제안했다. 이 메커니즘은 효과적인 RD 검색을 위해 트리클 타이머를 사용하고, directory advertisement(DA)라고 불리는 CoAP 메시지가 모든 노드에 파도 모양으로 전파되어 RD 탐색(discovery)을 수행한다. 그러나 선행 논문의 기술은 RD 에만 초점을 맞추고 리소스 업데이트로 인한 RD의 트래픽 오버헤드와 집중에 대하여 전혀 고려하고 있지 않음에 따라, 여전히 메시지 손실, 네트워크 정체 및 병목 현상 등의 문제가 나타나는 문제가 있다.
또한, 논문["A hybrid service discovery approach to mitigate overhead concentration on resource directory", Yoona Kim, Ki-Hyung Kim, Taeshik Shon, Jai-Hoon Kim, Information Networking (ICOIN), 2015 International Conference on, 12-14 Jan. 2015]에서는 RD에 대한 과부하를 극복하기 위한 하이브리드 메커니즘을 제안했다. 이 메커니즘은 기본적으로 RD를 사용하는 중앙집중식 리소스 검색 방법을 사용하며, RD에서 과부하가 발생하면 클라이언트는 분산된 방법을 사용하여 메시지를 직접 브로드캐스트 한다. 그런데, 선행 논문의 기술은 사전에 미리 RD의 트래픽 로드 문제를 방지할 수 없는 문제가 있다.
본원은 전술한 종래 기술의 문제점을 해결하기 위한 것으로서, 대규모 IoT(Internet of Things) 로컬 네트워크에서 중앙집중식 리소스 검색 접근법을 사용하여 확장성 문제를 해결하기 위한 CoAP(Constrained Application Protocol) 기반의 트래픽 부하 관리 장치 및 방법을 제공하려는 것을 목적으로 한다.
본원은 전술한 종래 기술의 문제점을 해결하기 위한 것으로서, RD에 집중되는 많은 수의 메시지로 인한 트래픽 부하의 균형을 맞출 수 있는 CoAP(Constrained Application Protocol) 기반의 트래픽 부하 관리 장치 및 방법을 제공하려는 것을 목적으로 한다.
본원은 전술한 종래 기술의 문제점을 해결하기 위한 것으로서, 종래에 RD가 무선 링크의 제한된 대역폭 때문에 모든 업데이트 메시지를 받을 여력이 없었던 문제를 해소할 수 있는 CoAP(Constrained Application Protocol) 기반의 트래픽 부하 관리 장치 및 방법을 제공하려는 것을 목적으로 한다.
본원은 전술한 종래 기술의 문제점을 해결하기 위한 것으로서, 종래에 RD의 경우 트래픽 부하가 증가함에 따라 메시지가 손실되고, 네트워크 정체 및 병목 현상이 나타나던 문제를 해소할 수 있는 CoAP(Constrained Application Protocol) 기반의 트래픽 부하 관리 장치 및 방법을 제공하려는 것을 목적으로 한다.
다만, 본원의 실시예가 이루고자 하는 기술적 과제는 상기된 바와 같은 기술적 과제들로 한정되지 않으며, 또 다른 기술적 과제들이 존재할 수 있다.
상기한 기술적 과제를 달성하기 위한 기술적 수단으로서, 본원의 일 실시예에 따른 IoT (Internet of Things) 로컬 네트워크에서 CoAP(Constrained Application Protocol) 기반의 트래픽 부하 관리 방법은, 트래픽 부하 관리 장치에서, 서버 그룹에 포함된 복수의 서버로부터 수신한 등록 메시지 및/또는 업데이트 메시지를 통합하여 통합 메시지를 생성하는 단계; 및 상기 트래픽 부하 관리 장치에서, 생성된 상기 통합 메시지를 리소스 디렉토리(Resource Directory)로 전송하는 단계를 포함하고, 상기 리소스 디렉토리로 전송된 통합 메시지에 의하여, 상기 통합 메시지와 관련된 복수의 메시지들을 전송한 서버의 리소스 엔트리가 상기 리소스 디렉토리에 등록 및/또는 업데이트될 수 있다.
또한, 상기 생성하는 단계는, 상기 복수의 서버로부터 수신한 등록 메시지 및/또는 업데이트 메시지를 순차적으로 카운트하여 통합함으로써 상기 통합 메시지를 생성할 수 있다.
또한, 상기 전송하는 단계는, 상기 통합 메시지가 상기 리소스 디렉토리로 전송되는 전송 시간을 결정하는 단계를 포함할 수 있다.
또한, 상기 전송 시간을 결정하는 단계는, 상기 CoAP의 메시지 포맷의 최대 페이로드 크기를 고려하여 상기 전송 시간을 결정할 수 있다.
또한, 상기 전송 시간을 결정하는 단계는, 상기 통합 메시지에 포함된 복수의 메시지들의 페이로드의 크기가 상기 CoAP의 메시지 포맷의 최대 페이로드 크기를 초과하지 않는 시점으로 상기 전송 시간을 결정하고, 상기 전송 시간의 결정에 의하여 상기 통합 메시지로서 통합되는 최대 등록 메시지 및/또는 업데이트 메시지의 수가 결정될 수 있다.
또한, 본원의 일 실시예에 따른 IoT (Internet of Things) 로컬 네트워크에서 CoAP(Constrained Application Protocol) 기반의 트래픽 부하 관리 방법은, 상기 트래픽 부하 관리 장치에서, 상기 리소스 디렉토리로 전송된 통합 메시지에 응답하여 상기 리소스 디렉토리로부터 정상 등록 및/또는 정상 업데이트에 관한 응답 메시지를 수신한 경우, 상기 응답 메시지를 상기 통합 메시지와 관련된 상기 복수의 메시지들을 전송한 서버로 전송하는 단계를 더 포함할 수 있다.
또한, 상기 응답 메시지를 전송하는 단계는, 등록 메시지의 수신에 의하여 생성된 상기 서버 그룹에 대한 URI(Uniform Resource Identifier) 목록에 기초하여 상기 응답 메시지를 전송할 수 있다.
또한, 본원의 일 실시예에 따른 IoT (Internet of Things) 로컬 네트워크에서 CoAP(Constrained Application Protocol) 기반의 트래픽 부하 관리 방법은, 상기 생성하는 단계 이전에, 상기 트래픽 부하 관리 장치에서, 상기 CoAP의 리소스 검색을 위해 상기 리소스 디렉토리로부터 수신한 GET 요청 메시지에 응답하여 상기 트래픽 부하 관리 장치에 관한 정보를 상기 리소스 디렉토리로 전송하는 단계; 및 상기 트래픽 부하 관리 장치에서, 상기 트래픽 부하 관리 장치에 관한 정보를 기초로 상기 리소스 디렉토리에 의해 상기 트래픽 부하 관리 장치에 할당된 서버 그룹 정보를 기반으로 하여, 상기 서버 그룹 정보에 대응하는 서버 그룹에 포함된 복수의 서버로부터 등록 메시지 및/또는 업데이트 메시지를 수신하는 단계를 더 포함할 수 있다.
또한, 상기 트래픽 부하 관리 장치는, 복수의 서버 그룹이 존재하는 경우 상기 복수의 서버 그룹 각각에 대응하여 복수 개 구비될 수 있다.
한편, 본원의 일 실시예에 따른 IoT (Internet of Things) 로컬 네트워크에서 CoAP(Constrained Application Protocol) 기반의 트래픽 부하 관리 장치는, 서버 그룹에 포함된 복수의 서버로부터 수신한 등록 메시지 및/또는 업데이트 메시지를 통합하여 통합 메시지를 생성하는 메시지 집계부; 및 상기 통합 메시지를 리소스 디렉토리(Resource Directory)로 전송하는 전송부를 포함하고, 상기 리소스 디렉토리로 전송된 통합 메시지에 의하여, 상기 통합 메시지와 관련된 복수의 메시지들을 전송한 서버의 리소스 엔트리가 상기 리소스 디렉토리에 등록 및/또는 업데이트될 수 있다.
한편, 본원의 일 실시예에 따른 IoT (Internet of Things) 로컬 네트워크에서 CoAP(Constrained Application Protocol) 기반의 트래픽 부하 관리 시스템은, 리소스 엔트리를 등록 메시지 및/또는 업데이트 메시지를 통해 트래픽 부하 관리 장치로 전송하는 복수의 서버를 포함하는 서버 그룹, 상기 서버 그룹에 포함된 복수의 서버로부터 수신한 등록 메시지 및/또는 업데이트 메시지를 통합하여 통합 메시지를 생성하고, 생성된 상기 통합 메시지를 리소스 디렉토리(Resource Directory)로 전송하는 상기 트래픽 부하 관리 장치; 및 상기 트래픽 부하 관리 장치로부터 수신한 상기 통합 메시지에 기초하여, 상기 통합 메시지와 관련된 복수의 메시지들을 전송한 서버의 리소스 엔트리를 등록 및/또는 업데이트하는 상기 리소스 디렉토리를 포함할 수 있다.
또한, 상기 트래픽 부하 관리 장치는, 상기 서버 그룹이 복수 개 존재하는 경우 복수의 서버 그룹 각각에 대응하여 복수 개 구비될 수 있다.
상술한 과제 해결 수단은 단지 예시적인 것으로서, 본원을 제한하려는 의도로 해석되지 않아야 한다. 상술한 예시적인 실시예 외에도, 도면 및 발명의 상세한 설명에 추가적인 실시예가 존재할 수 있다.
전술한 본원의 과제 해결 수단에 의하면, 트래픽 부하 관리 장치에서 복수 개의 등록 메시지 및 업데이트 메시지를 하나의 메시지로 통합한 통합 메시지를 리소스 디렉토리(RD)로 전송함으로써, RD에 집중되는 많은 수의 메시지로 인한 트래픽 부하의 불균형 문제를 해소할 수 있다.
전술한 본원의 과제 해결 수단에 의하면, 통합 메시지로 하여금 종래의 RD 기술 대비 손실되는 메시지의 수 및 메시지 손실률을 효과적으로 개선시킬 수 있다.
전술한 본원의 과제 해결 수단에 의하면, 대규모 IoT 로컬 네트워크에서 중앙집중식 리소스 검색 접근법의 확장성 문제를 해소할 수 있다.
다만, 본원에서 얻을 수 있는 효과는 상기된 바와 같은 효과들로 한정되지 않으며, 또 다른 효과들이 존재할 수 있다.
도 1은 본원의 일 실시예에 따른 IoT 로컬 네트워크에서 CoAP 기반의 트래픽 부하 관리 시스템에 대한 개략적인 구성을 나타낸 도면이다.
도 2는 본원의 일 실시예에 따른 트래픽 부하 관리 시스템에서 CoAP의 리소스 검색 동작에 관한 흐름을 개략적으로 나타낸 도면이다.
도 3은 본원의 일 실시예에 따른 트래픽 부하 관리 시스템에서 리소스 엔트리 등록 동작에 관한 흐름을 개략적으로 나타낸 도면이다.
도 4는 본원의 일 실시예에 따른 트래픽 부하 관리 시스템에서 리소스 엔트리 업데이트 동작에 관한 흐름을 개략적으로 나타낸 도면이다.
도 5는 본원의 일 실시예에 따른 시뮬레이션에 적용되는 파라미터의 예를 나타낸 도면이다.
도 6은 본원의 일 실시예에 따른 실험에서 서버의 수의 변화에 따른 손실된 메시지의 수의 변화를 나타낸 도면이다.
도 7은 본원의 일 실시예에 따른 실험에서 서버의 수의 변화에 따른 메시지 손실률을 나타낸 도면이다.
도 8은 본원의 일 실시예에 따른 실험에서 대역폭이 1Mbps에서 1.45Mbps로 변경될 때 손실되는 메시지의 수를 나타낸 도면이다.
도 9는 본원의 일 실시예에 따른 실험에서 대역폭이 1Mbps에서 1.45Mbps로 변경될 때의 메시지 손실률을 나타낸 도면이다.
도 10은 본원의 일 실시예에 따른 IoT 로컬 네트워크에서 CoAP기반의 트래픽 부하 관리 방법에 대한 동작 흐름도이다.
아래에서는 첨부한 도면을 참조하여 본원이 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 본원의 실시예를 상세히 설명한다. 그러나 본원은 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시예에 한정되지 않는다. 그리고 도면에서 본원을 명확하게 설명하기 위해서 설명과 관계없는 부분은 생략하였으며, 명세서 전체를 통하여 유사한 부분에 대해서는 유사한 도면 부호를 붙였다.
본원 명세서 전체에서, 어떤 부분이 다른 부분과 "연결"되어 있다고 할 때, 이는 "직접적으로 연결"되어 있는 경우뿐 아니라, 그 중간에 다른 소자를 사이에 두고 "전기적으로 연결" 또는 "간접적으로 연결"되어 있는 경우도 포함한다.
본원 명세서 전체에서, 어떤 부재가 다른 부재 "상에", "상부에", "상단에", "하에", "하부에", "하단에" 위치하고 있다고 할 때, 이는 어떤 부재가 다른 부재에 접해 있는 경우뿐 아니라 두 부재 사이에 또 다른 부재가 존재하는 경우도 포함한다.
본원 명세서 전체에서, 어떤 부분이 어떤 구성 요소를 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성 요소를 제외하는 것이 아니라 다른 구성 요소를 더 포함할 수 있는 것을 의미한다.
본원은 대규모 IoT(Internet of Things) 로컬 네트워크에서 중앙집중식 리소스 검색 접근법의 확장성 문제를 해결하기 위한 CoAP(Constrained Application Protocol) 기반의 트래픽 부하 관리 시스템, 장치 및 방법에 관한 것이다.
도 1은 본원의 일 실시예에 따른 IoT(Internet of Things) 로컬 네트워크에서 CoAP(Constrained Application Protocol) 기반의 트래픽 부하 관리 시스템(이하 '본 시스템'이라 함)에 대한 개략적인 구성을 나타낸 도면이다.
도 1을 참조하면, 본 시스템(1)은 서버 그룹(100), 트래픽 부하 관리 장치(200) 및 리소스 디렉토리(300, Resource Directory)를 포함할 수 있다.
서버 그룹(100, Server group)은 복수의 서버를 포함할 수 있으며, 복수의 서버 각각은 자신의 리소스 엔트리를 등록 메시지 및/또는 업데이트 메시지를 통해 트래픽 부하 관리 장치(200)로 전송할 수 있다. 본 시스템(1)에서 복수의 서버를 포함하는 서버 그룹(100)은 복수 개 구비될 수 있다. 일예로, 서버 그룹(100)은 복수 개의 서버 그룹으로서, 제1 서버 그룹(110, Server group #1), 제2 서버 그룹(120, Server group #2), …, 제n 서버 그룹(1n0, Server group #n)을 포함할 수 있다. 일예로, 제1 서버 그룹(110)은 제1 서버(111, Server #1), 제2 서버(112, Server #2), …, 제n 서버(11n, Server #n)를 포함할 수 있다.
트래픽 부하 관리 장치(200)는 서버와 리소스 디렉토리(300) 사이에서 중간 에이전트 역할을 수행할 수 있다.
트래픽 부하 관리 장치(200)는 서버 그룹(100)이 복수 개 존재하는 경우, 복수의 서버 그룹 각각에 대응하여 복수 개 구비될 수 있다. 일예로, 트래픽 부하 관리 장치(200)는 제1 트래픽 부하 관리 장치(210, LB-RD #1), 제2 트래픽 부하 관리 장치(220, LB-RD #2), …, 제n 트래픽 부하 관리 장치(2n0, LB-RD #n)를 포함할 수 있다.
여기서, 일예로 제1 트래픽 부하 관리 장치(210)는 제1 서버 그룹(110)과 연관된 트래픽 부하 관리 장치를 의미하고, 제2 트래픽 부하 관리 장치(220)는 제2 서버 그룹(120)과 연관된 트래픽 부하 관리 장치를 의미하고, 제n 트래픽 부하 관리 장치(2n0)는 제n 서버 그룹(1n0)과 연관된 트래픽 부하 관리 장치를 의미할 수 있다. 이때, 서버 그룹과 연관된 트래픽 부하 관리 장치라 함은, 해당 서버 그룹을 관리(즉, 해당 서버 그룹에 포함된 복수의 서버와 관련된 정보를 관리)하고, 해당 서버 그룹에 포함된 복수의 서버와 메시지를 송수신하는 트래픽 부하 관리 장치를 의미할 수 있다.
이하에서는 설명의 편의상 서버 그룹(100)이 제1 서버 그룹(110)이고, 트래픽 부하 관리 장치(200)가 제1 트래픽 부하 관리 장치(210)인 것으로 가정하여 설명하기로 한다. 또한, 이하 생략된 내용이라 하더라도 제1 서버 그룹(110)에 대하여 설명된 내용은 다른 서버 그룹에 대한 설명에도 동일 내지 유사하게 이해될 수 있고, 제1 트래픽 부하 관리 장치(210)에 대하여 설명된 내용은 다른 트래픽 부하 관리 장치에 대한 설명에도 동일 내지 유사하게 이해될 수 있다.
트래픽 부하 관리 장치(200)는 서버 그룹(100)에 포함된 복수의 서버로부터 수신한 등록 메시지 및/또는 업데이트 메시지를 통합하여 통합 메시지(집계 메시지)를 생성하고, 생성된 통합 메시지를 리소스 디렉토리(300)로 전송할 수 있다.
본원은 트래픽 부하 관리 장치(200)를 통한 복수의 메시지들의 통합을 통해, 대규모 IoT 로컬 네트워크에서 중앙집중식 리소스 검색 접근법의 확장성 문제를 해결하고, 리소스 디렉토리(300)에 집중되는 많은 수의 메시지로 인한 트래픽 부하의 균형을 맞출 수 있다. 한편, 본원에서 제안하는 트래픽 부하 관리 장치(200)는 LB-RD(Load-Balanced Resource Directory) 아키텍처로서, 간단히 LB-RD로 지칭될 수 있다. 트래픽 부하 관리 장치(200)에 대한 구체적인 설명은 후술하여 보다 자세히 설명하기로 한다.
리소스 디렉토리(300)는 CoAP(Constrained Application Protocol)에서 중앙집중식 리소스 검색을 수행함에 있어서 에너지 효율성을 위해 서버에 RD 엔트리로 알려진 일련의 웹 링크를 유지 관리하기 위한 디렉토리를 의미할 수 있다.
리소스 디렉토리(300)는 트래픽 부하 관리 장치(200)로부터 수신한 통합 메시지에 기초하여, 통합 메시지와 관련된 복수의 메시지들을 전송한 서버의 리소스 엔트리를 등록 및/또는 업데이트할 수 있다.
본 시스템(1)에서는 서버 그룹(100)에 포함된 복수의 서버 각각과 트래픽 부하 관리 장치(200)와 리소스 디렉토리(300) 간의 메시지 송수신이 CoAP (Coordinated Application Protocol)에 기반하여 이루어질 수 있다. 이하에서는 트래픽 부하 관리 장치(200)에 대하여 보다 자세히 설명하기로 한다.
트래픽 부하 관리 장치(200)는 서버 그룹 관리부(211, Server Group Management, SGM), 메시지 집계부(212, Message Aggregation, MS) 및 전송부(213)를 포함할 수 있다.
서버 그룹 관리부(211)는 트래픽 부하 관리 장치(200)와 연관된 서버 그룹(100)에 대한 URI(Uniform Resource Identifier) 목록(리스트)을 관리할 수 있다. 구체적인 일예로, 제1 트래픽 부하 관리 장치(210)의 서버 그룹 관리부(211)는, 제1 트래픽 부하 관리 장치(210)와 연관된 제1 서버 그룹(110)에 대한 URI(Uniform Resource Identifier) 목록(리스트)을 관리하고, 제2 트래픽 부하 관리 장치(220)의 서버 그룹 관리부는, 제2 트래픽 부하 관리 장치(220)와 연관된 제2 서버 그룹(120)에 대한 URI(Uniform Resource Identifier) 목록(리스트)을 관리할 수 있다.
여기서, URI 목록(리스트)은 서버 그룹(100)에 포함된 서버가 등록 메시지를 통해 자신의 리소스 엔트리를 리소스 디렉토리(300)에 등록하고자 할 때 생성될 수 있다. 또한, URI 목록(리스트)은 트래픽 부하 관리 장치(200)가 메시지 집계부(212)의 기능을 통해 서버 그룹(100)에 포함된 복수의 서버로부터 수신된 메시지를 집계하여 통합 메시지를 생성한 이후에 통합 메시지에 대한 응답 메시지를 서버에 멀티캐스트하고자 할 때 이용될 수 있다.
메시지 집계부(212)는 서버 그룹(100)에 포함된 복수의 서버로부터 수신한 등록 메시지 및/또는 업데이트 메시지를 통합하여 통합 메시지(달리 표현하여 집계 메시지)를 생성할 수 있다. 메시지 집계부(212)는 통합 메시지의 생성시, 복수의 등록 메시지를 포함하는 통합 메시지를 생성하거나 복수의 업데이트 메시지를 포함하는 통합 메시지를 생성하거나 등록 메시지와 업데이트 메시지를 함께 포함하는 통합 메시지를 생성할 수 있다.
메시지 집계부(212)는 서버 그룹(110)에 포함된 복수의 서버로부터 수신한 등록 메시지 및/또는 업데이트 메시지를 집계(Aggregation)할 수 있다. 구체적으로, 메시지 집계부(212)는 복수의 서버로부터 수신한 등록 메시지 및/또는 업데이트 메시지를 순차적으로 카운트(또는 집계)하여 통합함으로써 통합 메시지를 생성할 수 있다.
메시지 집계부(212)는 복수의 서버로부터 수신한 복수의 등록 메시지 및/또는 업데이트 메시지를 단일 집계 메시지로서 통합함으로써 통합 메시지를 생성할 수 있다.
메시지 집계부(212)에 의하여 생성된 통합 메시지는 다수의 독립적인 메시지의 페이로드와 단일 헤더로 이루어질 수 있다.
전송부(213)는 메시지 집계부(212)에서 생성된 통합 메시지를 리소스 디렉토리(300, Resource Directory, RD)로 전송할 수 있다.
이때 전송부(213)는, 통합 메시지가 리소스 디렉토리(300)로 전송되는 전송 시간을 결정할 수 있다. 달리 표현하여, 전송부(213)는 리소스 디렉토리(300)에 대하여 통합 메시지의 전송이 이루어지는 시간을 결정할 수 있다. 즉, 전송부(213)는 메시지 집계부(212)에 의하여 집계되어 통합되는 통합 메시지를 언제(어느 시점에) 리소스 디렉토리(300)로 전송할지에 대한 시간(전송 시간)을 결정할 수 있다. 달리 표현하여, 전송부(213)를 통한 전송 시간의 결정에 의하여 통합 메시지가 리소스 디렉토리(300)로 언제 전송될지 결정될 수 있다. 전송부(213)는 결정된 전송 시간에 통합 메시지를 리소스 디렉토리(300)로 전송할 수 있다. 전송 시간의 결정에 대한 구체적인 설명은 다음과 같다.
전송부(213)는 CoAP의 메시지 포맷의 최대 페이로드 크기를 고려하여 전송 시간을 결정할 수 있다. 전송부(213)는 통합 메시지에 포함된 복수의 메시지들의 페이로드의 크기가 CoAP의 메시지 포맷의 최대 페이로드 크기를 초과하지 않는 시점으로 전송 시간을 결정할 수 있다. 달리 표현하여, 전송부(213)는 메시지 집계부(212)에 의하여 통합되는 복수의 메시지들(즉, 복수의 등록 메시지 및/또는 업데이트 메시지)의 페이로드의 크기가 CoAP의 메시지 포맷의 최대 페이로드 크기를 초과하지 않는 시점으로 전송 시간을 결정할 수 있다. 이때, 전송 시간의 결정에 의하여 통합 메시지로서 통합되는 최대 등록 메시지 및/또는 업데이트 메시지의 수(k)가 결정될 수 있다. 다시 말해, 전송 시간은 통합 메시지에 포함된 복수의 메시지들의 페이로드의 크기가 CoAP 메시지의 최대 페이로드 크기보다 작거나 같아지는 시점으로 결정될 수 있다.
일예로, 트래픽 부하 관리 장치(200)가 복수의 서버로부터 등록 메시지만 수신하고 있는 상태인 것으로 가정하자. 이때, 메시지 집계부(212)는 복수의 서버로부터 수신된 복수의 등록 메시지의 수를 카운트하여 순차적으로 수신된 등록 메시지를 통합할 수 있다. 이때, 리소스 디렉토리(300)로의 전송을 위해 통합될 수 있는 최대 등록 메시지의 수 k는 하기 수학식 1을 만족할 수 있다. 달리 표현하여, 리소스 디렉토리(300)로의 전송을 위해 한번에 통합될 수 있는 등록 메시지의 수 k는 하기 수학식 1을 만족할 수 있다.
[수학식 1]
Figure pat00001
여기서, k는 하나의 통합 메시지로서 통합 가능한 등록 메시지의 수, L Reg 는 서버로부터 전송된 등록 메시지의 페이로드 크기, L CoAP 는 CoAP의 메시지 포맷의 최대 페이로드 크기를 나타낸다.
일예로, CoAP의 메시지 포맷의 최대 페이로드 크기(L Reg)가 1000이고, 등록 메시지의 페이로드 크기가 CoAP의 메시지 포맷의 최대 페이로드 크기(L CoAP)의 1/10 크기인 100인 경우, k는 10으로 결정될 수 있다. 이에 따르면, 메시지 집계부(212)는 10개의 등록 메시지를 통합한 통합 메시지를 생성할 수 있고, 전송부(213)는 10개의 등록 메시지가 통합된 시점, 즉 10개의 등록 메시지가 통합되어 통합 메시지가 생성된 시점에 통합 메시지를 리소스 디렉토리(300)로 전송할 수 있다.
이때, 상기 수학식 1에는 k의 값 결정 시 CoAP의 메시지 포맷의 최대 페이로드 크기 외에 서버로부터 전송된 등록 메시지의 페이로드 크기(L Reg)만 고려되는 것으로 기재되어 있으나, 이에만 한정되는 것은 아니고, 일예로, 트래픽 부하 관리 장치(200)가 복수의 서버로부터 업데이트 메시지만 수신하고 있는 상태일 경우에는 업데이트 메시지의 페이로드 크기가 고려될 수 있다. 다른 일예로, 트래픽 부하 관리 장치(200)가 복수의 서버로부터 등록 메시지와 업데이트 메시지를 수신하고 있는 상태일 경우에는 CoAP의 메시지 포맷의 최대 페이로드 크기 외에 등록 메시지의 페이로드 크기와 업데이트 메시지의 페이로드 크기가 함께 고려될 수 있다.
이러한 전송부(213)는 메시지 전달 예약부(Message Forwarding Scheduling, MFS)로 달리 지칭될 수 있다.
전송부(213)는 추가적인 지연을 방지하기 위하여, 메시지 집계부(212)에 의하여 생성된 통합 메시지를 통합 메시지의 생성 즉시 리소스 디렉토리(300)로 전송(전달)할 수 있다. 여기서, 리소스 디렉토리(300)로 전송된 통합 메시지에 의하여, 통합 메시지와 관련된 복수의 메시지들을 전송한 서버의 리소스 엔트리가 리소스 디렉토리(300)에 등록 및/또는 업데이트될 수 있다.
또한, 전송부(213)는 리소스 디렉토리(300)로 전송된 통합 메시지에 응답하여 리소스 디렉토리(300)로부터 통합 메시지와 관련된 서버의 리소스 엔트리에 대한 정상 등록 및/또는 정상 업데이트에 관한 응답 메시지를 수신한 경우, 수신한 응답 메시지를 통합 메시지와 관련된 복수의 메시지들을 전송한 서버로 전송(전달)할 수 있다. 이때, 전송부(213)는 서버 그룹 관리부(211)로 하여금 등록 메시지의 수신에 의하여 생성된 서버 그룹에 대한 URI(Uniform Resource Identifier) 목록에 기초하여 응답 메시지를 전송할 수 있다.
즉, 전송부(213)가 리소스 디렉토리(300)로 통합 메시지를 전송한 이후, 리소스 디렉토리(300)는 수신된 통합 메시지에 등록 메시지가 포함되어 있는 경우 등록 메시지를 송신한 서버의 리소스 엔트리를 등록할 수 있으며, 수신된 통합 메시지에 업데이트 메시지가 포함되어 있는 경우 업데이트 메시지를 송신한 서버의 리소스 엔트리를 업데이트할 수 있다. 이후 리소스 디렉토리(300)는 등록 내지 업데이트가 정상적으로 이루어진 경우, 트래픽 부하 관리 장치(200)로 정상 등록 내지 정상 업데이트에 대한 응답 메시지를 전송할 수 있다. 트래픽 부하 관리 장치(200)는 리소스 디렉토리(300)로부터 수신한 응답 메시지를 응답 메시지와 연관된 서버(즉, 리소스 엔트리에 대한 정상 등록 내지 정상 업데이트가 이루어진 서버)로 전송(전달, 멀티캐스트)할 수 있다. 이때, 전송부(213)는 응답 메시지의 전송 시 서버 그룹 관리부(211)에서 관리하는 URI 목록을 이용(참고)하여 전송할 수 있다.
이러한 본 시스템(1)은 트래픽 부하 관리 장치(200)로 하여금 서버의 등록 메시지 내지 업데이트 메시지를 통합 메시지로 통합하여 리소스 디렉토리(300)로 전송함으로써, 리소스 디렉토리(300)에 집중되는 트래픽 부하를 효과적으로 줄일 수 있다. 다시 말해, 서버의 등록 메시지 내지 업데이트 메시지의 집중으로 인한 리소스 디렉토리(300)의 트래픽 부하 문제를 완화하기 위해, 본원에서 제안하는 트래픽 부하 관리 장치(200)는 서버로부터 전송되는 메시지를 집계하여 하나의 통합 메시지로서 통합한 이후 통합된 통합 메시지를 리소스 디렉토리(300)로 전송할 수 있다.
즉, 본원은 대규모 IoT 로컬 네트워크에서 중앙집중식 자원 검색 접근법의 확장성 문제를 해결하기 위해 CoAP에 기반한 트래픽 부하 관리 장치(즉, LB-RD 아키텍처)를 제안한다. 구체적으로, 리소스 디렉토리(300)에 집중되는 많은 수의 메시지로 인한 트래픽 부하의 균형을 맞추기 위해, 트래픽 부하 관리 장치(200)는 서버와 리소스 디렉토리(300) 사이의 중간 에이전트 역할을 수행할 수 있다. 특히, 트래픽 부하 관리 장치(200)는 트래픽 부하 관리 장치(200)와 연관된 서버 그룹(100)의 URI (Uniform Resource Identifier) 목록을 관리하고, 서버로부터 수신한 등록 메시지 및 업데이트 메시지를 단일 집계 메시지, 즉 통합 메시지로 통합하고, 통합 메시지가 리소스 디렉토리(300)로 전송되는 전송 시간을 결정한 후 결정된 전송 시간에 통합 메시지를 전송할 수 있다.
한편, 트래픽 부하 관리 장치(200)는 CoAP의 리소스 검색 동작, 리소스 엔트리 등록 동작 및 리소스 엔트리 업데이트 동작을 수행할 수 있다. 이하에서는 앞서 언급한 검색 동작, 등록 동작 및 업데이트 동작에 대하여 보다 구체적으로 설명하기로 한다. 다만, 이하 설명에서는 설명의 편의상 검색 동작, 등록 동작 및 업데이트 동작 각각을 구분된 별개의 동작으로 설명하기로 하며, 이에만 한정되는 것은 아니고, 적어도 일부의 동작은 함께 이루어질 수 있다.
먼저 간단히 살펴보면, 트래픽 부하 관리 장치(200)는 메시지 집계부(212)를 통해 통합 메시지를 생성하기 이전에, CoAP의 리소스 검색을 위해 리소스 디렉토리(300)로부터 수신한 GET 요청 메시지에 응답하여 트래픽 부하 관리 장치(200)에 관한 정보(예를 들어, 주소, 포트 등)를 리소스 디렉토리(300)로 전송할 수 있다. 이후, 트래픽 부하 관리 장치(200)는, 트래픽 부하 관리 장치(200)에 관한 정보를 기초로 리소스 디렉토리(300)에 의해 트래픽 부하 관리 장치(200)에 할당된 서버 그룹 정보를 기반으로 하여, 서버 그룹 정보에 대응하는 서버 그룹에 포함된 복수의 서버로부터 등록 메시지 및/또는 업데이트 메시지를 수신할 수 있다. 이후, 트래픽 부하 관리 장치(200)는 수신된 등록 메시지 및/또는 업데이트 메시지에 기초하여 통합 메시지를 생성할 수 있다. 보다 구체적인 설명은 도 2 내지 도 4를 참조하여 보다 쉽게 이해될 수 있다.
도 2는 본원의 일 실시예에 따른 트래픽 부하 관리 시스템에서 CoAP의 리소스 검색(Discovery) 동작에 관한 흐름을 개략적으로 나타낸 도면이다. 도 3은 본원의 일 실시예에 따른 트래픽 부하 관리 시스템에서 리소스 엔트리 등록 동작에 관한 흐름을 개략적으로 나타낸 도면이다. 도 4는 본원의 일 실시예에 따른 트래픽 부하 관리 시스템에서 리소스 엔트리 업데이트 동작에 관한 흐름을 개략적으로 나타낸 도면이다.
이하 도 2를 참조한 설명에 있어서, 일예로 LB-RD는 트래픽 부하 관리 장치(200) 중 제1 트래픽 부하 관리 장치(210)인 경우로 가정하여 설명하기로 하며, 이에만 한정되는 것은 아니고, 제1 트래픽 부하 관리 장치(210)에 대하여 설명된 내용은 다른 트래픽 부하 관리 장치에 대해서도 동일 내지 유사하게 적용될 수 있다.
도 2를 참조하면, CoAP의 리소스 검색 동작의 경우, 트래픽 부하 관리 장치(210)는 리소스 디렉토리(300)로부터 트래픽 부하 관리 장치(210)의 검색(발견)을 위한 GET 요청 메시지를 수신(S201)할 수 있다. 트래픽 부하 관리 장치(210)는 리소스 디렉토리(300)로부터 전송된 GET 요청 메시지에 대한 응답으로 트래픽 부하 관리 장치(210)에 관한 정보(예를 들어, 주소, 포트 등)를 리소스 디렉토리(300)로 전송(S202)할 수 있다.
이후, 리소스 디렉토리(300)는 제1 트래픽 부하 관리 장치(210)를 포함한 복수의 트래픽 부하 관리 장치로부터 획득한 복수의 트래픽 부하 관리 장치에 관한 정보에 기반하여, 복수의 트래픽 부하 관리 장치 각각에 각기 다른 서버 그룹을 할당하고, 복수의 트래픽 부하 관리 장치에 대하여 할당된 서버 그룹 정보를 유지 및 관리할 수 있다. 이후, 서버 각각은 GET 요청 메시지를 리소스 디렉토리(300)로 전송(S203)하여 자신에게 할당된 트래픽 부하 관리 장치에 관한 정보를 요청할 수 있다. 리소스 디렉토리(300)는 각 서버로부터 획득된 GET 요청 메시지 각각에 응답(S204)하여, 해당 서버에 할당된 트래픽 부하 관리 장치에 관한 정보를 각 서버로 제공할 수 있다.
리소스 엔트리 등록 동작에 관한 설명은 다음과 같다. 이하 도 3을 참조한 설명에 있어서, 일예로 LB-RD는 제1 트래픽 부하 관리 장치(210)인 경우로 가정하고, 제1 서버(111, Server #1), 제2 서버(112, Server #2), …, 제n 서버(11n, Server #n)는 제1 서버 그룹(110)에 포함된 복수의 서버인 것으로 가정하여 설명하기로 한다.
도 3을 참조하면, 리소스 엔트리 등록 동작의 경우, 각 서버(111, 112, …, 11n)는 CoAP의 리소스 검색 동작이 이루어진 이후에 리소스에 대한 리소스 엔트리를 포함하는 기 지정(할당)된 트래픽 부하 관리 장치(210)로 POST 메소드를 사용하여 등록 메시지를 전송(S301)할 수 있다. 트래픽 부하 관리 장치(200)는 통합 메시지를 생성하는 메시지 집계 과정을 수행(S302)할 수 있다. 즉, 트래픽 부하 관리 장치(200)는 통합 메시지의 생성을 위해, 복수의 서버로부터 수신된 등록 메시지의 수를 카운트하여 k 개의 등록 메시지를 순차적으로 통합할 수 있다. 여기서, k의 값은 상기 수학식 1을 만족할 수 있으며, 이에 대한 설명은 앞서 자세히 설명했으므로, 이하 중복되는 설명은 생략하기로 한다. 이때, 제1 트래픽 부하 관리 장치(210)를 포함한 복수의 트래픽 부하 관리 장치 각각은 추가적인 지연을 방지하기 위해, 각자 생성한 통합 데이터를 통합 데이터의 생성 즉시 리소스 디렉토리(300)로 전송할 수 있다.
이후, 리소스 디렉토리(300)는 통합 메시지를 수신하면, 통합 메시지와 관련된 등록 메시지를 전송한 서버의 리소스 엔트리를 등록(S303)할 수 있다. 리소스 디렉토리(300)는 리소스 엔트리의 등록이 정상(성공)적으로 이루어진 경우 통합 메시지를 송신한 트래픽 부하 관리 장치(210)로 리소스 엔트리의 정상 등록에 대한 응답 메시지를 전송(S304)할 수 있다. 이후, 트래픽 부하 관리 장치(200)는 리소스 디렉토리(300)로부터 수신한 정상 등록에 대한 응답 메시지를 정상 등록과 관련하여 등록 메시지를 전송한 각 서버(111, 112, …, 11n)로 전송(S305, 전달, 멀티캐스트)할 수 있다.
도 3과 같은 등록 동작에 따르면, 종래에 CoAP 리소스 검색에서는 서버가 리소스 엔트리를 리소스 디렉토리에 직접 등록하는 반면, 본원에서는 트래픽 부하 관리 장치(200)를 통해 서버의 리소스 엔트리를 리소스 디렉토리(300)에 등록할 수 있다.
등록 동작이 이루어진 이후, 각 서버(111, 112, …, 11n)는 리소스 디렉토리(300)에 등록된 리소스 엔트리를 기 설정된 주기로 업데이트할 수 있다. 이는 도 4를 참조하여 보다 쉽게 이해될 수 있다.
도 4를 참조하면, 도 4는 리소스 디렉토리(300)가 각 서버에 대하여 가장 최근의 리소스 엔트리를 유지하도록 하는 트래픽 부하 관리 장치(210)의 업데이트 동작에 관한 개략적인 흐름을 나타낸다.
도 4에 도시된 업데이트 동작의 경우, 앞서 설명한 등록 동작 흐름에서 등록 메시지가 업데이트 메시지로 적용되고, 이에 따라 리소스 디렉토리(300)에 기 등록된 리소스 엔트리가 업데이트 된다는 것 이외의 모든 과정은 등록 동작 흐름에서의 과정과 동일하므로, 업데이트 동작은 등록 동작과 동일 내지 유사하게 이해될 수 있는 것인바, 이하 구체적인 설명은 생략하기로 한다.
트래픽 부하 관리 장치를 포함하는 본 시스템(1)은 복수의 등록 메시지와 업데이트 메시지를 하나의 통합 메시지로서 통합함으로써 리소스 디렉토리로 하여금 수신하는 등록 메시지 내지 업데이트 메시지의 수가 줄어들도록 하여, 리소스 디렉토리(300)에 집중되는 많은 수의 메시지로 인한 트래픽 부하의 불균형 문제를 해소할 수 있다. 이러한 본 시스템(1)에서 트래픽 부하 관리 장치(즉, LB-RD 아키텍처)의 부하 밸런싱 효과는 많은 수의 서버를 포함하는 대규모 IoT 로컬 네트워크에서 더욱 효과적일 수 있다.
이하에서는 본원에서 제안하는 트래픽 부하 관리 장치(이하, LB-RD 아키텍처라 함)의 유효성(효율성)을 확인하기 위해 수행된 시뮬레이션 결과에 대하여 기술하기로 한다. 일예로, 본원의 일 실시예에 따른 실험에서는 MATLAB을 사용하여 실험 시뮬레이션을 수행하였으며, 이하에서 LB-RD 아키텍처의 시뮬레이션 결과를 기존(종래)의 리소스 디렉토리(RD) 방식의 시뮬레이션 결과와 비교하기로 한다.
보다 구체적으로, 본원의 일 실시예에 따른 실험에서는 손실된 메시지의 수와 시뮬레이션을 통한 메시지 손실률 측면에서 LB-RD 아키텍처의 성능을 확인하기로 한다. 손실된 메시지 수와 메시지 손실률은 서버의 수 및 대역폭을 늘리기 위해 평가되며, 그 결과는 손실된 메시지 수와 LB-RD 아키텍처의 메시지 손실률이 각각 기존 RD 접근법의 값보다 12%, 11% 더 낮게 나타남을 확인할 수 있다. 이에 대한 설명은 도 5 내지 도 9를 참조하여 보다 쉽게 이해될 수 있다.
도 5는 본원의 일 실시예에 따른 시뮬레이션에 적용되는 파라미터의 예를 나타낸 도면이다.
도 5를 참조하면, 본원의 일 실험예에 따른 시뮬레이션에서는 서버의 수(Number of servers)가 100개 내지 1,000개로 설정되고, 트래픽 부하 관리 장치의 수(Number of LB-RDs)가 10개로 설정될 수 있다. 또한, 메시지 통합(집계)를 위한 업데이트 메시지의 수(Number of update messages for aggregation)는 5로 설정될 수 있으며, 이에 따라 5 개의 업데이트 메시지가 트래픽 부하 관리 장치에 의해 통합 메시지(단일 집계 메시지)로 통합(결합)될 수 있다. 또한, 헤더 크기(Header size)는 10 바이트로 설정되고, 페이로드의 크기(Payload size)는 200 바이트로 설정될 수 있다. 또한, 서버와 리소스 디렉토리(300)사이의 대역폭(Bandwidth)은 1에서 1.45 Mbps까지 변화되도록 설정될 수 있다.
도 6은 본원의 일 실시예에 따른 실험에서 서버의 수의 변화에 따른 손실된 메시지의 수의 변화를 나타낸 도면이다.
도 6을 참조하면, 서버와 RD 사이의 대역폭이 1 Mbps로 설정되어 있을 때, 본원에서 제안하는 LB-RD 아키텍처는 서버의 수가 500 개를 초과할 때 기존(종래, Existing RD)의 RD 접근 방식보다 손실되는 메시지의 수가 적음을 확인할 수 있다. 특히, 서버 수가 600개일 경우에는 기존 RD 방식만 업데이트 메시지의 손실이 발생하는 것을 확인할 수 있다. 이는 본원에서 제안하는 LB-RD가 메시지의 집계를 통해, 업데이트 메시지 헤더로 인해 발생하는 오버헤드를 줄이기 때문이라 할 수 있다. 즉, 본원에서 제안하는 LB-RD는 기존의 RD 접근 방식보다 1 Mbps 대역폭을 통해 더 많은 업데이트 메시지를 전송할 수 있다. 한편, 본원에서 제안하는 LB-RD 방식과 기존의 RD 접근 방식은 모두 서버의 수가 500개 미만이 될 때까지 업데이트 메시지의 손실이 발생하지 않음을 확인할 수 있으며, 이는 대역폭이 서버의 모든 업데이트 메시지를 수용하기에 충분하기 때문이라 할 수 있다.
도 7은 본원의 일 실시예에 따른 실험에서 서버의 수의 변화에 따른 메시지 손실률을 나타낸 도면이다.
도 7을 참조하면, 서버와 RD 사이의 대역폭이 1 Mbps로 설정되어 있을 때, 본원에서 제안하는 LB-RD는 복수 개의 업데이트 메시지를 하나의 통합 메시지(즉, 단일 집계 메시지)로 결합함에 따라, LB-RD의 메시지 손실률이 기존의 RD 접근법보다 낮음을 확인할 수 있다. 구체적으로, 본원의 일 실험에 따르면, 기존의 RD 접근 방식과 본원에서 제안하는 LB-RD 아키텍처의 평균 메시지 손실률이 각각 12 %와 10 %로 나타난 바, 본원에서 제안하는 LB-RD 아키텍처는 종래 기술 대비 메시지 손실률을 낮출 수 있다.
도 8은 본원의 일 실시예에 따른 실험에서 대역폭이 1Mbps에서 1.45Mbps로 변경될 때 손실되는 메시지의 수를 나타낸 도면이고, 도 9는 본원의 일 실시예에 따른 실험에서 대역폭이 1Mbps에서 1.45Mbps로 변경될 때의 메시지 손실률을 나타낸 도면이다. 도 8 및 도 9에 따른 일 실험에서는 서버의 수가 1,000개로 설정된 경우를 나타낸다.
도 8을 참조하면, 본원에서 제안하는 LB-RD 방식과 기존의 RD 접근 방식은 모두 대역폭이 증가함에 따라 손실되는 메시지의 수가 감소함을 확인할 수 있다. 이는 LB-RD 방식과 기존의 RD 접근 모두 대역폭이 증가함에 따라 더 많은 수의 업데이트 메시지를 전송할 수 있기 때문이라 할 수 있다. 한편, 전반적으로 본원에서 제안하는 LB-RD 아키텍처는 메시지 집계를 통한 통합 메시지의 생성에 의하여 기존의 RD 방식보다 손실되는 메시지의 수가 적음을 확인할 수 있다. 특히, 본원에서 제안하는 LB-RD 아키텍처는 평균적으로 기존의 RD 방식에 비해 손실되는 메시지의 수가 11 % 적은 것으로 나타났다.
도 9를 참조하면, 본원에서 제안하는 LB-RD 아키텍처의 메시지 손실률은 대역폭에 관계없이 기존의 RD 방식의 메시지 손실률 보다 낮게 나타남을 확인할 수 있으며, 이는 앞서 도 8을 참조하여 설명한 이유와 같은 이유에서라 할 수 있다. 이러한 본원에서 제안하는 LB-RD 아키텍처의 메시지 손실률은 기존 RD 방식보다 11 % 낮은 24 %인 것으로 나타났다.
본원의 일 실험에 따르면, 본원에서 제안하는 LB-RD 아키텍처의 경우, 손실된 메시지의 수와 메시지 손실률의 측면에서 기존의 RD 방식보다 우수한 성능을 나타냄을 확인할 수 있다.
본원은 대규모 IoT 로컬 네트워크에서 중앙집중식 리소스 검색 접근법의 확장성 문제를 해결하는 CoAP 기반 LB-RD 아키텍처(트래픽 부하 관리 장치)를 제안함에 따라, RD에 집중되는 많은 수의 메시지로 인한 트래픽 부하의 균형을 맞출 수 있다.
이하에서는 상기에 자세히 설명된 내용을 기반으로, 본원의 동작 흐름을 간단히 살펴보기로 한다.
도 10은 본원의 일 실시예에 따른 IoT 로컬 네트워크에서 CoAP기반의 트래픽 부하 관리 방법에 대한 동작 흐름도이다.
도 10에 도시된 트래픽 부하 관리 방법은 앞서 설명된 트래픽 부하 관리 장치(200)에 의하여 수행될 수 있다. 따라서, 이하 생략된 내용이라고 하더라도 트래픽 부하 관리 장치(200)에 대하여 설명된 내용은 트래픽 부하 관리 방법에 대한 설명에도 동일하게 적용될 수 있다.
도 10을 참조하면, 본원의 일 실시예에 따른 트래픽 부하 관리 방법은 트래픽 부하 관리 장치에서 서버 그룹에 포함된 복수의 서버로부터 수신한 등록 메시지 및/또는 업데이트 메시지를 통합하여 통합 메시지(집계 메시지)를 생성할 수 있다(S10).
여기서, 트래픽 부하 관리 장치는 복수의 서버 그룹이 존재하는 경우 복수의 서버 그룹 각각에 대응하여 복수 개 구비될 수 있다.
이때, 단계S10에서는, 복수의 서버로부터 수신한 등록 메시지 및/또는 업데이트 메시지를 순차적으로 카운트하여 통합함으로써 통합 메시지가 생성될 수 있다.
다음으로, 본원의 일 실시예에 따른 트래픽 부하 관리 방법은 트래픽 부하 관리 장치에서 통합 메시지를 리소스 디렉토리(Resource Directory)로 전송할 수 있다(S20).
이때, 리소스 디렉토리로 전송된 통합 메시지에 의하여, 통합 메시지와 관련된 복수의 메시지들을 전송한 서버의 리소스 엔트리가 리소스 디렉토리에 등록 및/또는 업데이트될 수 있다.
또한, 단계S20에서는 통합 메시지가 리소스 디렉토리로 전송되는 전송 시간을 결정할 수 있다. 이때, 단계S20에서는 CoAP의 메시지 포맷의 최대 페이로드 크기를 고려하여 전송 시간을 결정할 수 있다.
또한, 단계S20에서는 통합 메시지에 포함된 복수의 메시지들의 페이로드의 크기가 CoAP의 메시지 포맷의 최대 페이로드 크기를 초과하지 않는 시점으로 전송 시간이 결정될 수 있으며, 전송 시간의 결정에 의하여 통합 메시지로서 통합되는 최대 등록 메시지 및/또는 업데이트 메시지의 수가 결정될 수 있다.
또한, 도면에 개시하지는 않았으나, 본원의 일 실시예에 따른 트래픽 부하 관리 방법은 트래픽 부하 관리 장치에서, 리소스 디렉토리로 전송된 통합 메시지에 응답하여 리소스 디렉토리로부터 정상 등록 및/또는 정상 업데이트에 관한 응답 메시지를 수신한 경우, 응답 메시지를 통합 메시지와 관련된 복수의 메시지들을 전송한 서버로 전송하는 단계를 포함할 수 있다.
여기서, 응답 메시지를 전송하는 단계에서는, 등록 메시지의 수신에 의하여 생성된 서버 그룹에 대한 URI(Uniform Resource Identifier) 목록에 기초하여 응답 메시지를 전송할 수 있다.
또한, 도면에 개시하지는 않았으나, 본원의 일 실시예에 따른 트래픽 부하 관리 방법은 단계S10 이전에, 트래픽 부하 관리 장치에서, CoAP의 리소스 검색을 위해 리소스 디렉토리로부터 수신한 GET 요청 메시지에 응답하여 트래픽 부하 관리 장치에 관한 정보(즉, 주소, 포트)를 리소스 디렉토리로 전송하는 단계를 포함할 수 있다. 또한, 트래픽 부하 관리 장치에서, 트래픽 부하 관리 장치에 관한 정보를 기초로 리소스 디렉토리에 의해 트래픽 부하 관리 장치에 할당된 서버 그룹 정보를 기반으로 하여, 서버 그룹 정보에 대응하는 서버 그룹에 포함된 복수의 서버로부터 등록 메시지 및/또는 업데이트 메시지를 수신하는 단계를 포함할 수 있다.
상술한 설명에서, 단계 S10 내지 S20은 본원의 구현예에 따라서, 추가적인 단계들로 더 분할되거나, 더 적은 단계들로 조합될 수 있다. 또한, 일부 단계는 필요에 따라 생략될 수도 있고, 단계 간의 순서가 변경될 수도 있다.
본원의 일 실시 예에 따른 IoT 로컬 네트워크에서 CoAP기반의 트래픽 부하 관리 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 및/또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 본 발명을 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다. 상기된 하드웨어 장치는 본 발명의 동작을 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.
전술한 본원의 설명은 예시를 위한 것이며, 본원이 속하는 기술분야의 통상의 지식을 가진 자는 본원의 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 쉽게 변형이 가능하다는 것을 이해할 수 있을 것이다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적이 아닌 것으로 이해해야만 한다. 예를 들어, 단일형으로 설명되어 있는 각 구성 요소는 분산되어 실시될 수도 있으며, 마찬가지로 분산된 것으로 설명되어 있는 구성 요소들도 결합된 형태로 실시될 수 있다.
본원의 범위는 상기 상세한 설명보다는 후술하는 특허청구범위에 의하여 나타내어지며, 특허청구범위의 의미 및 범위 그리고 그 균등 개념으로부터 도출되는 모든 변경 및/또는 변형된 형태가 본원의 범위에 포함되는 것으로 해석되어야 한다.
1: 트래픽 부하 관리 시스템
100: 서버 그룹
200: 트래픽 부하 관리 장치
211: 서버 그룹 관리부
212: 메시지 집계부
213: 전송부
300: 리소스 디렉토리

Claims (9)

  1. IoT (Internet of Things) 로컬 네트워크에서 CoAP(Constrained Application Protocol) 기반의 트래픽 부하 관리 방법에 있어서,
    트래픽 부하 관리 장치에서, 서버 그룹에 포함된 복수의 서버로부터 수신한 등록 메시지 및/또는 업데이트 메시지를 통합하여 통합 메시지를 생성하는 단계; 및
    상기 트래픽 부하 관리 장치에서, 생성된 상기 통합 메시지를 리소스 디렉토리(Resource Directory)로 전송하는 단계,
    를 포함하고,
    상기 리소스 디렉토리로 전송된 통합 메시지에 의하여, 상기 통합 메시지와 관련된 복수의 메시지들을 전송한 서버의 리소스 엔트리가 상기 리소스 디렉토리에 등록 및/또는 업데이트되는 것인, 트래픽 부하 관리 방법.
  2. 제1항에 있어서,
    상기 전송하는 단계는,
    상기 통합 메시지가 상기 리소스 디렉토리로 전송되는 전송 시간을 결정하는 단계,
    를 포함하는 것인, 트래픽 부하 관리 방법.
  3. 제2항에 있어서,
    상기 전송 시간을 결정하는 단계는,
    상기 CoAP의 메시지 포맷의 최대 페이로드 크기를 고려하여 상기 전송 시간을 결정하는 것인, 트래픽 부하 관리 방법.
  4. 제3항에 있어서,
    상기 전송 시간을 결정하는 단계는,
    상기 통합 메시지에 포함된 복수의 메시지들의 페이로드의 크기가 상기 CoAP의 메시지 포맷의 최대 페이로드 크기를 초과하지 않는 시점으로 상기 전송 시간을 결정하고,
    상기 전송 시간의 결정에 의하여 상기 통합 메시지로서 통합되는 최대 등록 메시지 및/또는 업데이트 메시지의 수가 결정되는 것인, 트래픽 부하 관리 방법.
  5. 제1항에 있어서,
    상기 생성하는 단계 이전에,
    상기 트래픽 부하 관리 장치에서, 상기 CoAP의 리소스 검색을 위해 상기 리소스 디렉토리로부터 수신한 GET 요청 메시지에 응답하여 상기 트래픽 부하 관리 장치에 관한 정보를 상기 리소스 디렉토리로 전송하는 단계; 및
    상기 트래픽 부하 관리 장치에서, 상기 트래픽 부하 관리 장치에 관한 정보를 기초로 상기 리소스 디렉토리에 의해 상기 트래픽 부하 관리 장치에 할당된 서버 그룹 정보를 기반으로 하여, 상기 서버 그룹 정보에 대응하는 서버 그룹에 포함된 복수의 서버로부터 등록 메시지 및/또는 업데이트 메시지를 수신하는 단계,
    를 더 포함하는 트래픽 부하 관리 방법.
  6. IoT (Internet of Things) 로컬 네트워크에서 CoAP(Constrained Application Protocol) 기반의 트래픽 부하 관리 장치에 있어서,
    서버 그룹에 포함된 복수의 서버로부터 수신한 등록 메시지 및/또는 업데이트 메시지를 통합하여 통합 메시지를 생성하는 메시지 집계부; 및
    상기 통합 메시지를 리소스 디렉토리(Resource Directory)로 전송하는 전송부,
    를 포함하고,
    상기 리소스 디렉토리로 전송된 통합 메시지에 의하여, 상기 통합 메시지와 관련된 복수의 메시지들을 전송한 서버의 리소스 엔트리가 상기 리소스 디렉토리에 등록 및/또는 업데이트되는 것인, 트래픽 부하 관리 장치.
  7. IoT (Internet of Things) 로컬 네트워크에서 CoAP(Constrained Application Protocol) 기반의 트래픽 부하 관리 시스템에 있어서,
    리소스 엔트리를 등록 메시지 및/또는 업데이트 메시지를 통해 트래픽 부하 관리 장치로 전송하는 복수의 서버를 포함하는 서버 그룹;
    상기 서버 그룹에 포함된 복수의 서버로부터 수신한 등록 메시지 및/또는 업데이트 메시지를 통합하여 통합 메시지를 생성하고, 생성된 상기 통합 메시지를 리소스 디렉토리(Resource Directory)로 전송하는 상기 트래픽 부하 관리 장치; 및
    상기 트래픽 부하 관리 장치로부터 수신한 상기 통합 메시지에 기초하여, 상기 통합 메시지와 관련된 복수의 메시지들을 전송한 서버의 리소스 엔트리를 등록 및/또는 업데이트하는 상기 리소스 디렉토리,
    를 포함하는 트래픽 부하 관리 시스템.
  8. 제7항에 있어서,
    상기 트래픽 부하 관리 장치는,
    상기 서버 그룹이 복수 개 존재하는 경우 복수의 서버 그룹 각각에 대응하여 복수 개 구비되는 것인, 트래픽 부하 관리 시스템.
  9. 제1항 내지 제5항 중 어느 한 항의 방법을 컴퓨터에서 실행하기 위한 프로그램을 기록한 컴퓨터에서 판독 가능한 기록 매체.
KR1020170163340A 2017-11-30 2017-11-30 IoT 로컬 네트워크에서 CoAP 기반의 트래픽 부하 관리 장치 및 방법 KR102042027B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020170163340A KR102042027B1 (ko) 2017-11-30 2017-11-30 IoT 로컬 네트워크에서 CoAP 기반의 트래픽 부하 관리 장치 및 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020170163340A KR102042027B1 (ko) 2017-11-30 2017-11-30 IoT 로컬 네트워크에서 CoAP 기반의 트래픽 부하 관리 장치 및 방법

Publications (2)

Publication Number Publication Date
KR20190064066A true KR20190064066A (ko) 2019-06-10
KR102042027B1 KR102042027B1 (ko) 2019-11-07

Family

ID=66848455

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020170163340A KR102042027B1 (ko) 2017-11-30 2017-11-30 IoT 로컬 네트워크에서 CoAP 기반의 트래픽 부하 관리 장치 및 방법

Country Status (1)

Country Link
KR (1) KR102042027B1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021115622A1 (en) * 2019-12-13 2021-06-17 Telefonaktiebolaget Lm Ericsson (Publ) Managing resource state notifications
WO2021162321A1 (ko) * 2020-02-11 2021-08-19 삼성전자주식회사 서버 장치 및 그의 제어 방법

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160092275A (ko) * 2015-01-27 2016-08-04 한국전자통신연구원 CoAP 통신 방법 및 이를 수행하는 시스템

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160092275A (ko) * 2015-01-27 2016-08-04 한국전자통신연구원 CoAP 통신 방법 및 이를 수행하는 시스템

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021115622A1 (en) * 2019-12-13 2021-06-17 Telefonaktiebolaget Lm Ericsson (Publ) Managing resource state notifications
US11924309B2 (en) 2019-12-13 2024-03-05 Telefonaktiebolaget Lm Ericsson (Publ) Managing resource state notifications
WO2021162321A1 (ko) * 2020-02-11 2021-08-19 삼성전자주식회사 서버 장치 및 그의 제어 방법
US11418607B2 (en) 2020-02-11 2022-08-16 Samsung Electronics Co., Ltd. Server apparatus and controlling method thereof

Also Published As

Publication number Publication date
KR102042027B1 (ko) 2019-11-07

Similar Documents

Publication Publication Date Title
US8677011B2 (en) Load distribution system, load distribution method, apparatuses constituting load distribution system, and program
US8694675B2 (en) Generalized dual-mode data forwarding plane for information-centric network
US7978631B1 (en) Method and apparatus for encoding and mapping of virtual addresses for clusters
WO2016015582A1 (zh) 传输报文的方法、装置和系统
Pitkänen et al. Opportunistic web access via wlan hotspots
US10171610B2 (en) Web caching method and system for content distribution network
Francis Antony Selvi et al. Ant based multipath backbone routing for load balancing in MANET
Rajesh et al. Constructing Well-Organized Wireless Sensor Networks with Low-Level Identification
WO2013029569A1 (en) A Generalized Dual-Mode Data Forwarding Plane for Information-Centric Network
JP2014241135A (ja) コンテンツ中心ネットワークにおけるノードの通信方法及びそのノード
Auzias et al. Coap over bp for a delay-tolerant internet of things
WO2016029345A1 (zh) 网络流的信息统计方法和装置
Xing et al. MPTCP meets big data: Customizing transmission strategy for various data flows
WO2023221452A1 (zh) 报文处理系统、方法、设备和存储介质
Misic et al. Reliable and scalable data acquisition from IoT domains
KR102042027B1 (ko) IoT 로컬 네트워크에서 CoAP 기반의 트래픽 부하 관리 장치 및 방법
Skjegstad et al. Mist: A reliable and delay-tolerant publish/subscribe solution for dynamic networks
Jin et al. MANET for Disaster Relief based on NDN
Narayana Rao et al. Way-point multicast routing framework for improving QoS in hybrid wireless mesh networks
Tagami et al. GreenICN Project: Architecture and applications of green information centric networking
CN111464448B (zh) 一种数据传输方法及装置
US11006310B2 (en) Node-density aware interest packet forwarding in ad hoc network
CN114244850A (zh) 数据包处理方法、装置、计算机设备和存储介质
Amadeo et al. Client Discovery and Data Exchange in Edge-based Federated Learning via Named Data Networking
JP5784234B2 (ja) 情報中心ネットワークのための一般化デュアルモードデータ転送プレーン

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
AMND Amendment
E601 Decision to refuse application
AMND Amendment
X701 Decision to grant (after re-examination)