KR20190017351A

KR20190017351A - TRAFFIC CONTROL METHOD AND TRAFFIC CONTROL SERVER FOR IoT SERVICE

Info

Publication number: KR20190017351A
Application number: KR1020170102072A
Authority: KR
Inventors: 심재희; 김지현; 오인규
Original assignee: (주)엔텔스
Priority date: 2017-08-11
Filing date: 2017-08-11
Publication date: 2019-02-20
Also published as: KR101960254B1

Abstract

A traffic control method for an IoT service comprises the following steps. A control server receives a request message for an IoT service, and the control server identifies a LoRa device generated the request message based on an identifier included in the request message. The control server blocks a message delivered by the LoRa device when the number of request messages transmitted by the LoRa device during a reference time exceeds a threshold value, and the control server releases the message blocking for the LoRa device after a predetermined time elapsed from the blocking time.

Description

Technical Field [0001] The present invention relates to a traffic control method and a traffic control server for an IoT service,

이하 설명하는 기술은 IoT 서비스를 위한 트래픽 제어 기법에 관한 것이다.The techniques described below are related to traffic control techniques for IoT services.

IoT 플랫폼에서 처리하는 데이터는 특정 객체로부터 수신하는 데이터 및 특정 객체로 송신하는 데이터로 구분할 수 있다. 예컨대, IoT 플랫폼은 IoT 디바이스로부터 데이터를 수신(Inbound)할 수 있고, 특정 서비스를 제공하는 서버에 데이터를 송신(Outbound)할 수 있다.The data processed by the IOT platform can be divided into data received from a specific object and data transmitted to a specific object. For example, the IoT platform can receive data from the IoT device (Inbound), and can transmit data to a server providing a specific service (Outbound).

IoT 플랫폼은 수신하는 데이터에 대해서 DDos 공격에 대응해야 한다. 한편 IoT 플랫폼은 애플리케이션에 대한 접속이 끊어지거나 네트워크가 단절되는 경우에 데이터 송신을 재시도하면서 과도한 트래픽이 발생할 수 있다. The IoT platform must respond to DDos attacks against incoming data. The IoT platform, on the other hand, can cause excessive traffic while retrying data transmission if the application is disconnected or the network is disconnected.

한국공개특허 제10-2015-0123747호Korean Patent Publication No. 10-2015-0123747

IoT 플랫폼은 일정한 경우 수신 데이터 및 송신 데이터에 대한 트래픽 제어를 수행할 필요가 있다. 이하 설명하는 기술은 IoT 플랫폼에서 트래픽을 제어하는 기법을 제공하고자 한다. 이하 설명하는 기술은 LoRa 통신을 수행하는 시스템에서 트래픽을 제어하는 기법을 제공하고자 한다. IoT platform needs to perform traffic control on received data and transmitted data in certain cases. The technique described below is intended to provide a technique for controlling traffic in the IOT platform. The technique described below is intended to provide a technique for controlling traffic in a system that performs LoRa communication.

IoT 서비스를 위한 트래픽 제어 방법은 제어서버가 IoT 서비스를 위한 요청 메시지를 수신하는 단계, 상기 제어서버가 상기 요청 메시지에 포함된 식별자를 기준으로 상기 요청 메시지를 생성한 LoRa 디바이스를 식별하는 단계, 상기 제어서버가 상기 LoRa 디바이스에서 기준 시간 동안 전송한 요청 메시지의 횟수가 임계값을 초과하는 경우 상기 LoRa 디바이스가 전달하는 메시지를 차단하는 단계 및 상기 제어서버가 상기 차단 시점부터 설정된 시간이 경과한 후 상기 LoRa 디바이스에 대한 메시지 차단을 해제하는 단계를 포함한다.A traffic control method for an IoT service includes receiving a request message for an IoT service from a control server, identifying a LoRa device from which the control server has generated the request message based on an identifier included in the request message, Blocking the message delivered by the LoRa device when the number of request messages transmitted by the control server during the reference time in the LoRa device exceeds a threshold value; And releasing the message blocking for the LoRa device.

다른 측면에서 IoT 서비스를 위한 트래픽 제어 방법은 제어서버가 IoT 서비스를 위한 요청 메시지를 수신하는 단계, 상기 제어서버가 상기 요청 메시지를 전송하는 프로토콜이 HTTP(Hyper Text Transfer Protocol)인 경우 상기 요청 메시지에 포함된 IP를 기준으로 상기 요청 메시지를 생성한 객체를 식별하는 단계, 상기 제어서버가 상기 요청 메시지를 전송하는 프로토콜이 MQTT(MQ Telemetry Transport) 프로토콜인 경우 상기 요청 메시지에 포함된 식별자를 기준으로 상기 요청 메시지를 생성한 객체를 식별하는 단계, 상기 제어서버가 상기 IP 또는 상기 식별자로 식별한 객체에서 기준 시간 동안 전송한 요청 메시지의 횟수가 임계값을 초과하는 경우 상기 객체가 전달하는 메시지를 차단하는 단계 및 상기 제어서버가 상기 차단 시점부터 설정된 시간이 경과한 후 상기 L객체에 대한 메시지 차단을 해제하는 단계를 포함한다.In another aspect of the present invention, there is provided a traffic control method for an IoT service, the method comprising: receiving a request message for an IoT service from a control server; receiving, by the control server, the request message, if the protocol for transmitting the request message is HTTP (Hyper Text Transfer Protocol) Identifying the object that generated the request message based on the included IP; if the control server transmits the request message in the MQTT (MQ Telemetry Transport) protocol, Identifying the object that generated the request message; blocking the message delivered by the object if the number of request messages transmitted during the reference time in the object identified by the IP or the identifier exceeds the threshold value; And after the control server has elapsed a predetermined time from the disconnection point, the L And a step of releasing the blocking message for the object.

IoT 서비스를 위한 트래픽 제어 서버는 LoRa 디바이스 및 애플리케이션 서버와 메시지를 교환하는 통신 인터페이스 장치, 상기 LoRa 디바이스의 식별자, 상기 애플리케이션 서버의 IP, 및 상기 LoRa 디바이스 또는 상기 애플리케이션 서버에 대한 로그 정보를 저장하는 데이터베이스 및 상기 통신 인터페이스가 수신한 요청 메시지에서 상기 LoRa 디바이스 또는 상기 애플리케이션 서버를 식별하고, 식별한 LoRa 디바이스 또는 애플리케이션 서버에서 기준 시간 동안 전송한 요청 메시지의 횟수가 임계값을 초과하는 경우 상기 식별한 LoRa 디바이스 또는 애플리케이션 서버에 대한 로그 정보를 생성하고, 상기 로그 정보에 설정된 시간 동안 상기 식별한 LoRa 디바이스 또는 애플리케이션 서버에 대한 메시지를 차단하는 제어 장치를 포함한다.The traffic control server for the IoT service includes a communication interface device for exchanging messages with the LoRa device and the application server, a database for storing the identifier of the LoRa device, the IP of the application server, and the log information for the LoRa device or the application server The LoRa device or the application server identifies the LoRa device or the application server in the request message received by the communication interface, and when the number of request messages transmitted during the reference time in the identified LoRa device or the application server exceeds the threshold value, Or the application server, and blocks the message for the identified LoRa device or the application server for the time set in the log information.

이하 설명하는 기술은 IoT 시스템에서 데이터가 들어오는 상황(Inbound) 및/또는 나가는 상황(Outbound)에서의 트래픽을 효과적으로 제어한다. 이하 설명하는 기술은 LoRa 망을 이용하는 IoT 서비스에서 트래픽을 효과적으로 제어한다. 이하 설명하는 기술은 MongoDB의 TTL(Time-to-Live) 기능으로 트래픽을 제어하여 플랫폼에 부하를 주지 않는다.The techniques described below effectively control traffic in the Inbound and / or Outbound conditions in the IoT system. The technique described below effectively controls the traffic in the IoT service using the LoRa network. The technology described below is a time-to-live (TTL) function of MongoDB that does not load the platform by controlling traffic.

도 1은 IoT 서비스를 제공하는 시스템에 대한 예이다.
도 2는 제어서버의 구성을 도시한 블록도의 예이다.
도 3은 수신 메시지에 대한 트래픽 제어 과정의 순서도의 예이다.
도 4는 송신 메시지에 대한 트래픽 제어 과정의 순서도의 예이다.
도 5는 IoT 플랫폼에서 수신 메시지를 처리하는 과정에 대한 예이다.
도 6은 IoT 플랫폼에서 수신 메시지를 처리하는 절차에 대한 흐름도의 예이다.
도 7은 IoT 플랫폼에서 송신 메시지를 처리하는 과정에 대한 예이다.
도 8은 IoT 플랫폼에서 송신 메시지를 처리하는 절차에 대한 흐름도의 예이다.Figure 1 is an example of a system for providing IoT service.
2 is an example of a block diagram showing the configuration of the control server.
3 is an example of a flowchart of a traffic control process for a received message.
4 is an example of a flowchart of a traffic control process for a transmission message.
5 is an example of a process of processing a received message on the IOT platform.
Figure 6 is an example of a flow chart for a procedure for processing a received message on the IoT platform.
7 is an example of a process of processing a transmission message in the IoT platform.
Figure 8 is an example of a flow chart for a procedure for processing a send message on the IoT platform.

이하 설명하는 기술은 다양한 변경을 가할 수 있고 여러 가지 실시례를 가질 수 있는 바, 특정 실시례들을 도면에 예시하고 상세하게 설명하고자 한다. 그러나, 이는 이하 설명하는 기술을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 이하 설명하는 기술의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.The following description is intended to illustrate and describe specific embodiments in the drawings, since various changes may be made and the embodiments may have various embodiments. However, it should be understood that the following description does not limit the specific embodiments, but includes all changes, equivalents, and alternatives falling within the spirit and scope of the following description.

제1, 제2, A, B 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 해당 구성요소들은 상기 용어들에 의해 한정되지는 않으며, 단지 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 이하 설명하는 기술의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.The terms first, second, A, B, etc., may be used to describe various components, but the components are not limited by the terms, but may be used to distinguish one component from another . For example, without departing from the scope of the following description, the first component may be referred to as a second component, and similarly, the second component may also be referred to as a first component. And / or < / RTI > includes any combination of a plurality of related listed items or any of a plurality of related listed items.

본 명세서에서 사용되는 용어에서 단수의 표현은 문맥상 명백하게 다르게 해석되지 않는 한 복수의 표현을 포함하는 것으로 이해되어야 하고, "포함한다" 등의 용어는 설시된 특징, 개수, 단계, 동작, 구성요소, 부분품 또는 이들을 조합한 것이 존재함을 의미하는 것이지, 하나 또는 그 이상의 다른 특징들이나 개수, 단계 동작 구성요소, 부분품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 배제하지 않는 것으로 이해되어야 한다.As used herein, the singular " include " should be understood to include a plurality of representations unless the context clearly dictates otherwise, and the terms " comprises & , Parts or combinations thereof, and does not preclude the presence or addition of one or more other features, integers, steps, components, components, or combinations thereof.

도면에 대한 상세한 설명을 하기에 앞서, 본 명세서에서의 구성부들에 대한 구분은 각 구성부가 담당하는 주기능 별로 구분한 것에 불과함을 명확히 하고자 한다. 즉, 이하에서 설명할 2개 이상의 구성부가 하나의 구성부로 합쳐지거나 또는 하나의 구성부가 보다 세분화된 기능별로 2개 이상으로 분화되어 구비될 수도 있다. 그리고 이하에서 설명할 구성부 각각은 자신이 담당하는 주기능 이외에도 다른 구성부가 담당하는 기능 중 일부 또는 전부의 기능을 추가적으로 수행할 수도 있으며, 구성부 각각이 담당하는 주기능 중 일부 기능이 다른 구성부에 의해 전담되어 수행될 수도 있음은 물론이다.Before describing the drawings in detail, it is to be clarified that the division of constituent parts in this specification is merely a division by main functions of each constituent part. That is, two or more constituent parts to be described below may be combined into one constituent part, or one constituent part may be divided into two or more functions according to functions that are more subdivided. In addition, each of the constituent units described below may additionally perform some or all of the functions of other constituent units in addition to the main functions of the constituent units themselves, and that some of the main functions, And may be carried out in a dedicated manner.

또, 방법 또는 동작 방법을 수행함에 있어서, 상기 방법을 이루는 각 과정들은 문맥상 명백하게 특정 순서를 기재하지 않은 이상 명기된 순서와 다르게 일어날 수 있다. 즉, 각 과정들은 명기된 순서와 동일하게 일어날 수도 있고 실질적으로 동시에 수행될 수도 있으며 반대의 순서대로 수행될 수도 있다.Also, in performing a method or an operation method, each of the processes constituting the method may take place differently from the stated order unless clearly specified in the context. That is, each process may occur in the same order as described, may be performed substantially concurrently, or may be performed in the opposite order.

이하 설명하는 기술은 IoT 서비스를 제공하는 시스템에서 트래픽을 제어하는 기법에 관한 것이다. 먼저 전체 시스템에 대해 설명한다. 도 1은 IoT 서비스를 제공하는 시스템(100)에 대한 예이다. 도 1의 시스템(100)은 IoT 디바이스(110), AP(120), 제어서버(130), 애플리케이션 서버(140), 서비스 제공자 단말(150) 및 사용자 단말(160)을 포함한다.The techniques described below relate to techniques for controlling traffic in a system that provides IoT services. First, the entire system will be described. Figure 1 is an example of a system 100 providing IoT service. The system 100 of Figure 1 includes an IoT device 110, an AP 120, a control server 130, an application server 140, a service provider terminal 150 and a user terminal 160.

IoT 디바이스(110)는 IoT 서비스를 위한 정보 수집 장치이다. IoT 디바이스(110)는 특정 장치를 제어하기 위한 장치일 수도 있다. 도 1은 3개의 IoT 디바이스(110A, 110B 및 110C)를 예로 도시하였다. IoT 디바이스(110)는 LoRa 디바이스일 수 있다. LoRa 디바이스는 LoRa 통신을 사용하여 데이터를 교환하는 장치를 의미한다. 도 1에서 IoT 디바이스(110)는 LoRa 통신을 사용하여 데이터(패킷)를 전송하는 예를 도시하였다. 이하 IoT 디바이스(110)는 LoRa 디바이스라고 가정하고 설명한다. 이하 전달되는 데이터는 패킷 형태라고 가정한다.The IoT device 110 is an information collecting device for the IoT service. The IoT device 110 may be a device for controlling a specific device. FIG. 1 illustrates three IoT devices 110A, 110B, and 110C as an example. IoT device 110 may be a LoRa device. The LoRa device refers to a device that exchanges data using LoRa communication. 1, the IoT device 110 transmits data (packets) using LoRa communication. Hereinafter, it is assumed that the IoT device 110 is a LoRa device. Hereinafter, it is assumed that data to be transmitted is a packet.

AP(120)는 IoT 디바이스(110)로부터 패킷을 수신하다. 또한 AP(120)는 IoT 디바이스(110)에 대한 명령을 IoT 디바이스(110)에 전달할 수 있다. AP(120)는 IoT 디바이스(110)와 LoRa 통신으로 정보를 교환한다. AP(120)는 일반적으로 복수의 IoT 디바이스(110)와 통신을 수행한다. 도 1에서 AP(120A)는 IoT 디바이스(110A 및 110B)와 통신한다. AP(120B)는 IoT 디바이스(110C)와 통신한다.The AP 120 receives the packet from the IoT device 110. The AP 120 may also communicate an instruction to the IoT device 110 to the IoT device 110. The AP 120 exchanges information with the IoT device 110 through LoRa communication. The AP 120 typically communicates with a plurality of IoT devices 110. In FIG. 1, AP 120A communicates with IoT devices 110A and 110B. AP 120B communicates with IoT device 110C.

AP(120)는 IoT 디바이스(110)가 수집한 데이터를 이종 네트워크로 전달한다. 이종 네트워크는 이동통신(LTE, 3G 등), 근거리 무선 통신(Zigbee 등), 무선랜 등일 수 있다. 이하 이종 네트워크는 이동통신 네트워크라고 가정한다. 도 1에서 AP(120)는 LTE 또는 3G 망을 통해 패킷을 전달한다고 도시하였다. 따라서 AP(120)는 LoRa 통신과 이동통신이 모두 가능한 장치이다. AP(120)는 이동통신 기지국으로 LoRA 통신 기능을 부가한 장치일 수도 있다. AP(120)가 전달하는 데이터는 제어서버(130)에 전달된다. AP(120)와 제어서버(130) 사이에 위치하는 네트워크에 대해서는 자세한 설명을 생략한다. 제어서버(130)의 위치에 따라 AP(120)와 제어서버(130)를 연결하는 네트워크 구성은 다양할 수 있다.The AP 120 transfers the data collected by the IoT device 110 to the heterogeneous network. The heterogeneous network may be mobile communication (LTE, 3G, etc.), short-range wireless communication (Zigbee, etc.), wireless LAN, and the like. Hereinafter, it is assumed that the heterogeneous network is a mobile communication network. In FIG. 1, the AP 120 is shown to deliver packets over an LTE or 3G network. Therefore, the AP 120 is a device capable of both LoRa communication and mobile communication. The AP 120 may be a device that adds a LoRA communication function to a mobile communication base station. The data transmitted by the AP 120 is transmitted to the control server 130. A detailed description of the network located between the AP 120 and the control server 130 will be omitted. The network configuration for connecting the AP 120 and the control server 130 according to the location of the control server 130 may vary.

제어서버(130)는 시스템(100)에서 트래픽을 제어하는 구성이다. 제어서버(130)는 이동통신코어망에 위치할 수 있다. 또는 제어서버(130)는 이동통신의 코어망이 아닌 PDN(Packet Data Network)에 위치할 수도 있다. The control server 130 is a configuration for controlling traffic in the system 100. The control server 130 may be located in the mobile communication core network. Alternatively, the control server 130 may be located in a PDN (Packet Data Network) rather than a core network of mobile communication.

제어서버(130)가 처리하는 트래픽은 두 가지로 구분할 수 있다. 제어서버(130)는 제어서버(130)로 들어오는(Inbound) 패킷 및/또는 제어서버(130)로부터 다른 객체 방향으로 나가는(Outbound) 패킷에 대한 트래픽을 제어할 수 있다. 제어서버(130)는 IoT 디바이스(110) 및/또는 애플리케이션 서버(140)로부터 패킷을 수신할 수 있다. 따라서 제어서버(130)는 IoT 디바이스(110) 및 애플리케이션 서버(140)에서 수신하는 패킷에 대한 트래픽을 제어할 수 있다. 제어서버(130)는 IoT 디바이스(110)와 애플리케이션 서버(140)를 구분하여 서로 다른 방식으로 트래픽을 제어할 수 있다. 한편 제어서버(130)는 애플리케이션 서버(140) 방향으로 패킷을 전송할 수 있다. 제어서버(130)는 애플리케이션 서버(140)로 전송하는 트래픽을 제어할 수 있다. 도 1에 도시하지 않았지만, 제어서버(130)는 IoT 디바이스(110)으로도 패킷을 전송할 수 있다. 경우에 따라서 제어서버(130)는 IoT 디바이스(110)에 대한 트래픽도 제어할 수 있다.The traffic handled by the control server 130 can be divided into two types. The control server 130 may control traffic for incoming packets to the control server 130 and / or outbound packets from the control server 130 to other objects. The control server 130 may receive packets from the IoT device 110 and / or the application server 140. Therefore, the control server 130 can control the traffic for the packets received by the IOT device 110 and the application server 140. The control server 130 can control the traffic by differentiating the IoT device 110 and the application server 140 from each other. Meanwhile, the control server 130 may transmit the packet toward the application server 140. The control server 130 can control traffic to be transmitted to the application server 140. [ Although not shown in FIG. 1, the control server 130 can also transmit packets to the IoT device 110. In some cases, the control server 130 may also control traffic to the IoT device 110.

애플리케이션 서버(140)는 특정한 애플리케이션 서비스를 제공하는 서버이다. 도 1은 2개의 애플리케이션 서버(140A 및 140B)를 도시하였다. 도 1에서 애플리케이션 서버(140A)는 서비스 제공자 단말(150)이 연결된 예를 도시하였다. 서비스 제공자 단말(150)는 특정 애플리케이션 서비스를 제공하는 사업자가 애플리케이션 서버(140A)를 관리하는 장치이다. 서비스 제공자 단말(150)은 애플리케이션 서버(140A)에 필요한 데이터 및 정보를 저장하거나 업데이트한다. 도 1에서 애플리케이션 서버(140B)는 사용자 단말(160)이 연결된 예를 도시하였다. 사용자 단말(160)은 애플리케이션 서버(140B)가 제공하는 특정 서비스를 받은 장치이다. 제어버서(130)가 애플리케이션 서버(140)로부터 수신하는 패킷은 서비스 제공자 단말(150) 또는 사용자 단말(160)로부터 전달되는 특정한 요청일 수도 있다.The application server 140 is a server that provides a specific application service. Figure 1 shows two application servers 140A and 140B. In FIG. 1, the application server 140A shows an example in which the service provider terminal 150 is connected. The service provider terminal 150 is a device that manages the application server 140A by a provider providing a specific application service. The service provider terminal 150 stores or updates data and information necessary for the application server 140A. In FIG. 1, application server 140B shows an example in which user terminal 160 is connected. The user terminal 160 is a device that receives a specific service provided by the application server 140B. The packet received by the control server 130 from the application server 140 may be a specific request conveyed from the service provider terminal 150 or the user terminal 160.

한편 IoT 디바이스(110)는 다른 통신 방식으로 데이터를 전달할 수도 있다. 예컨대, IoT 디바이스(110)는 LTE 통신 기반인 NB-IoT 통신을 사용할 수도 있다. 이 경우 AP(120)는 NB-IoT 방식을 지원하는 기지국일 수 있다. 즉, 제어서버(130)를 통한 트래픽 제어는 특정한 통신 방식에 제한되는 것은 아니다.Meanwhile, the IoT device 110 may transmit data using another communication method. For example, the IoT device 110 may use NB-IoT communication, which is an LTE communication base. In this case, the AP 120 may be a base station supporting the NB-IoT scheme. That is, traffic control through the control server 130 is not limited to a specific communication method.

전술한 바와 같이 제어서버(130)가 트래픽을 제어한다. 제어서버(130)에 대한 구성을 구체적으로 설명한다. 도 2는 제어서버(200)의 구성을 도시한 블록도의 예이다. 도 2에서 도시한 제어서버(200)는 도 1의 제어서버(130)와 동일한 객체이다. 제어서버(200)는 통신 인터페이스 장치(210), 저장장치(220), 제어장치(230) 및 DB(240)를 포함한다. The control server 130 controls the traffic as described above. The configuration of the control server 130 will be described in detail. 2 is an example of a block diagram showing the configuration of the control server 200. As shown in FIG. The control server 200 shown in FIG. 2 is the same object as the control server 130 in FIG. The control server 200 includes a communication interface device 210, a storage device 220, a control device 230, and a DB 240.

제어서버(200)는 전술한 바와 같이 이동통신코어망에 위치할 수 있다. 예컨대, 제어서버(200)는 이동통신망에 있는 전용 서버일 수 있다. 또한 제어서버(200)는 LTE 코어망에 있는 PGW(Packet data network GateWay)일 수 있다. 이 경우 PGW는 제어서버 기능을 수행하는 플랫폼을 포함할 수 있다. 한편 제어서버(200)는 PGW와 인터넷으로 연결된 서버일 수도 있다.The control server 200 may be located in the mobile communication core network as described above. For example, the control server 200 may be a dedicated server in the mobile communication network. Also, the control server 200 may be a packet data network GateWay (PGW) in the LTE core network. In this case, the PGW may include a platform that performs control server functions. Meanwhile, the control server 200 may be a server connected to the PGW and the Internet.

통신 인터페이스 장치(210)는 네트워크에 있는 다른 객체와 정보(패킷)를 주고 받기 위한 장치이다. 통신 인터페이스 장치(210)는 사용하는 통신 프로토콜에 따라 다양한 방식을 지원할 수 있다. 제어서버(200)는 인터넷을 통해 애플리케이션 서버(140)와 통신을 수행한다. 따라서 통신 인터페이스 장치(210)는 인터넷 프로토콜(IPv4/IPv6)을 지원한다. 한편 제어서버(200)는 이동통신코어망에 위치할 수 있다. 이 경우 통신 인터페이스 장치(210)는 이동통신코어망의 객체 사이에서 사용하는 통신 방식을 지원한다. The communication interface device 210 is a device for exchanging information (packets) with other objects in the network. The communication interface device 210 may support various methods depending on the communication protocol to be used. The control server 200 communicates with the application server 140 via the Internet. Therefore, the communication interface device 210 supports the Internet Protocol (IPv4 / IPv6). Meanwhile, the control server 200 may be located in the mobile communication core network. In this case, the communication interface device 210 supports a communication method used between objects of the mobile communication core network.

저장장치(220)는 일정한 데이터를 저장하는 장치이다. 저장장치(200)는 플래시 메모리, 하드 디스크 등과 같은 저장 매체를 의미한다. 저장장치(220)는 IoT 디바이스(110) 또는 애플리케이션 서버(140)로부터 수신한 데이터를 임시로 저장할 수 있다. 저장장치(200)는 트래픽을 제어하기 위한 일정한 정보를 저장할 수도 있다. 저장장치(200)는 트래픽 제어를 위한 프로그램(코드)이나 데이터를 저장할 수도 있다. The storage device 220 is a device that stores certain data. The storage device 200 refers to a storage medium such as a flash memory, a hard disk, or the like. The storage device 220 may temporarily store data received from the IOT device 110 or the application server 140. The storage device 200 may store certain information for controlling traffic. The storage device 200 may store a program (code) or data for traffic control.

제어장치(230)는 트래픽 제어를 수행하는 구성이다. 제어장치(230)는 컴퓨터 장치에서 특정한 프로그램 내지 명령을 수행하는 장치에 해당한다. 제어장치(230)는 컴퓨터 장치에서의 CPU 내지 AP에 해당하는 연산 장치이다. 제어장치(230)는 트래픽 제어를 위한 프로그램을 포함한 메모리를 포함할 수도 있다. 제어장치(230)는 수신한 패킷 또는 송신한 패킷이 트래픽 제어 대상인지 판단한다. 제어장치(230)는 트래픽 제어를 위하여 일정한 정보(후술할 로그 정보)를 생성한다.The control device 230 is a configuration for performing traffic control. The control device 230 corresponds to a device that executes a specific program or command in the computer device. The control device 230 is a computing device corresponding to a CPU to an AP in the computer device. The control device 230 may include a memory including a program for traffic control. The control device 230 determines whether the received packet or the transmitted packet is a traffic control target. The control device 230 generates certain information (log information to be described later) for traffic control.

DB(240)는 트래픽 제어를 위한 정보를 저장하고 관리한다. 도 2에서는 DB(240)를 별도의 구성으로 도시하였으나, 저장장치(220)가 DB의 기능을 수행할 수도 있다. 나아가 도 2와는 달리 DB(240)는 제어서버(200)와 네트워크로 연결된 별도의 장치일 수도 있다. The DB 240 stores and manages information for traffic control. 2, the DB 240 is shown as a separate component, but the storage device 220 may also function as a DB. 2, the DB 240 may be a separate device connected to the control server 200 via a network.

후술하겠지만, 제어서버(220)는 트래픽 제어를 위해 여러 가지 기준을 사용할 수 있다. 예컨대, 제어서버(220)는 일정한 시간에 특정한 객체로부터 몇 번 메시지를 수신하였는가를 기준으로 트래픽을 제어할 수 있다. 이 경우 일정한 시간에 수신한 메시지 개수는 트래픽 제어를 수행할지 여부를 판단하는 기준이 된다. 트래픽 제어를 위한 기준은 시스템 환경에 따라 변경될 수도 있다. 관리자는 별도의 컴퓨터 장치(50)를 사용하여 트래픽 제어를 위한 기준으로 제어서버(20)에 입력하거나, 업데이트할 수 있다. 컴퓨터 장치(50)는 인터넷과 같은 네트워크를 통해 제어서버(200)에 정보를 전달할 수 있다. 나아가 컴퓨터 장치(50)는 트래픽 제어를 위한 프로그램을 제어서버(200)에 입력하거나, 실시간으로 편집할 수도 있다. 저장장치(220) 내지 제어장치(230)의 메모리는 트래픽 제어를 위한 기준, 프로그램 등을 저장할 수 있다.As will be described later, the control server 220 can use various criteria for traffic control. For example, the control server 220 can control traffic based on how many times messages are received from a specific object at a predetermined time. In this case, the number of messages received at a predetermined time is a criterion for judging whether to perform traffic control. The criteria for traffic control may be changed depending on the system environment. The administrator can input or update the control server 20 as a criterion for traffic control using a separate computer device 50. The computer device 50 may communicate information to the control server 200 via a network such as the Internet. Furthermore, the computer device 50 may input a program for traffic control to the control server 200 or edit it in real time. The memories of the storage devices 220 to 230 may store standards, programs, and the like for traffic control.

먼저 제어서버(200)가 유입(Inbound)되는 메시지에 대한 트래픽을 제어하는 과정에 대하여 설명한다. 도 3은 수신 메시지에 대한 트래픽 제어 과정(300)의 순서도의 예이다. 제어서버(200)는 요청 메시지를 수신한다(310). 요청 메시지는 특정 객체가 다른 객체로 일정한 정보를 전달하거나, 일정한 명령을 전달하는 메시지이다. 예컨대, 제어서버(200)는 특정 IoT 디바이스로부터 수집한 데이터를 특정 서버에 전달하려는 요청 메시지를 수신할 수 있다. 또는 제어서버(200)는 애플리케이션 서버로부터 일정한 제어 명령을 수신할 수 있다. 제어 명령은 제어서버(200)를 제어하는 명령, 특정 IoT 디바이스에 대한 동작을 지시하는 명령 등일 수 있다.First, a process of controlling traffic for a message to be inbound to the control server 200 will be described. 3 is an example of a flowchart of a traffic control procedure 300 for a received message. The control server 200 receives the request message (310). A request message is a message in which a specific object conveys certain information to another object or transmits a certain command. For example, the control server 200 may receive a request message to transfer data collected from a specific IoT device to a specific server. Or the control server 200 may receive a certain control command from the application server. The control command may be an instruction to control the control server 200, an instruction to direct an operation to the specific IoT device, and the like.

제어서버(200)는 요청 메시지로부터 해당 메시지를 생성한 객체를 식별한다(320). 즉, 제어서버(200)는 트래픽 제어 대상이 될 객체를 식별한다. 제어서버(200)는 요청 메시지의 종류, 요청 메시지를 생성한 객체의 종류 또는 요청 메시지 전달에 사용된 프로토콜의 종류에 따라 객체 식별을 위한 기준을 적응적으로 사용할 수 있다. The control server 200 identifies the object that generated the message from the request message (320). That is, the control server 200 identifies an object to be a traffic control target. The control server 200 may adaptively use a criterion for object identification according to the type of the request message, the type of the object that generated the request message, or the type of the protocol used to transmit the request message.

(1) 제어서버(200)는 요청 메시지를 전송한 객체가 LoRa 디바이스인 경우 해당 LoRa 디바이스의 식별자(ID)를 기준으로 객체를 식별할 수 있다. LoRa 디바이스를 이용한 IoT 서비스인 경우, 사전에 LoRA 디바이스를 등록해야 한다. 따라서 제어서버(200)가 사전에 정보를 수집하는 모든 LoRa 디바이스에 대한 식별자를 보유하고, 관리한다고 전제한다. LoRa 디바이스는 MQTT(MQ Telemetry Transport) 프로토콜을 사용하여 패킷을 제어서버(200)에 전달할 수 있다. LoRa 디바이스는 MQTT 브로커를 통해 생성한 패킷을 제어서버(200)에 선별적으로 전달할 수 있다. 제어서버(200)는 MQTT 프로토콜을 통해 요청 메시지가 전송되면, 해당 메시지에 포함된 LoRa 디바이스의 식별자를 추출한다. 제어 서버(200)는 추출한 식별자와 등록 과정에서 보유한 정보를 비교하여 현재 요청 메시지를 전송한 LoRA 디바이스를 식별한다.(1) The control server 200 can identify the object based on the identifier (ID) of the LoRa device when the object transmitting the request message is a LoRa device. In case of IoT service using LoRa device, LoRA device should be registered in advance. Therefore, it is assumed that the control server 200 holds and manages identifiers for all LoRa devices that collect information in advance. The LoRa device can forward the packet to the control server 200 using the MQTT (MQ Telemetry Transport) protocol. The LoRa device can selectively deliver the packet generated through the MQTT broker to the control server 200. When the request message is transmitted through the MQTT protocol, the control server 200 extracts the identifier of the LoRa device included in the corresponding message. The control server 200 compares the extracted identifier with the information held in the registration process and identifies the LoRA device that transmitted the current request message.

(2) 제어서버(200)는 요청 메시지를 전송한 객체가 애플리케이션 서버인 경우 요청 메시지에 포함된 IP를 기준으로 객체를 식별할 수 있다. 애플리케이션 서버는 인터넷에 위치하여 특정한 IP를 갖는다. 물론 제어서버(200)는 사전에 모든 애플리케이션 서버에 대한 IP 정보를 보유한다고 전제한다. 제어서버(200)는 HTTP를 통해 요청 메시지가 전송되면, 해당 메시지에 포함된 IP를 추출한다. 제어서버(200)는 추출한 IP와 사전에 보유한 IP 정보들을 비교하여 현재 요청 메시지를 전송한 애플리케이션 서버를 식별한다. 한편 IoT 디바이스가 IP를 가질 수 있다. 예컨대, IPv6 방식을 이용하면 다수의 IoT 디바이스에 대해서도 IP를 부여할 수 있다. 이 경우 제어서버(200)는 요청 메시지에 포함된 IP를 기준으로 IoT 디바이스를 식별할 수 있다.(2) The control server 200 can identify the object based on the IP included in the request message when the object transmitted the request message is an application server. The application server is located on the Internet and has a specific IP. Of course, it is assumed that the control server 200 holds IP information for all the application servers in advance. When a request message is transmitted through HTTP, the control server 200 extracts the IP included in the message. The control server 200 compares the extracted IP with previously held IP information and identifies the application server that transmitted the current request message. On the other hand, IoT devices can have IP. For example, by using the IPv6 scheme, IP can be assigned to a plurality of IoT devices. In this case, the control server 200 can identify the IoT device based on the IP included in the request message.

제어서버(200)는 식별한 객체가 화이트리스트(white list)에 있는지 확인한다(330). 화이트리스트는 트래픽을 제어하지 않고 메시지를 처리할 대상을 포함한다. 식별한 객체가 화이트리스트에 있다면(330의 YES), 제어서버(200)는 트래픽을 제한하지 않고 통상적인 메시지 처리를 수행한다(380). The control server 200 determines whether the identified object is in a white list (330). A whitelist contains objects to handle messages without controlling traffic. If the identified object is in the whitelist (YES in 330), the control server 200 performs normal message processing (380) without limiting traffic.

식별한 객체가 화이트리스트에 없다면(330의 NO), 제어서버(200)는 기준 시간 동안 식별한 객체가 전달한 요청 메시지의 개수를 확인한다(340). 제어서버(200)는 기준 시간 동안 식별한 객체가 전달한 요청 메시지의 개수가 임계값을 초과하는지 여부를 판단한다(340). 예컨대, 제어서버(200)는 현재 요청 메시지를 포함하여 특정 IoT 디바이스가 1분(기준 시간)동안 10건(임계값) 보다 많은 요청 메시지를 전달했는지를 판단할 수 있다. 제어서버(200)는 현재 요청 메시지를 수신한 시점을 기준으로 1분을 설정할 수 있다. 기준 시간, 기준 시간의 기준시점 또는 임계값은 시스템 성능, 네트워크 상황 등을 고려하여 다양한 값이 사용될 수 있다. 기준 시간 동안 수신한 요청 메시지의 개수를 누적 요청 개수라고 명명한다. 제어서버(200)는 누적 요청 개수가 임계값 이하라면, 트래픽을 제한하지 않고 통상적인 메시지 처리를 수행한다(380). If the identified object is not in the whitelist (NO at 330), the control server 200 determines 340 the number of request messages delivered by the identified object during the reference time. The control server 200 determines whether the number of request messages delivered by the identified object during the reference time exceeds a threshold value (340). For example, the control server 200 may determine whether a particular IoT device, including the current request message, has delivered more than ten requests (thresholds) for one minute (reference time). The control server 200 can set one minute based on the time point at which the current request message is received. The reference time and the reference time or threshold value of the reference time may be various values in consideration of system performance, network conditions, and the like. The number of request messages received during the reference time is called the cumulative request count. If the number of accumulated requests is less than the threshold value, the control server 200 performs normal message processing without limiting traffic (380).

제어서버(200)는 누적 요청 개수가 임계값을 초과했다면, 식별한 객체에 대한 메시지를 차단한다(350). 제어서버(200)는 식별한 객체가 전달하는 메시지를 일정한 시간 동안 무시한다. 다만 제어서버(200)는 메시지를 차단한 객체가 요청 메시지를 전달하면, 해당 요청 메시지를 DB에 저장할 수 있다. 메시지 차단 과정에 대한 상세한 설명은 후술한다.If the number of accumulated requests exceeds the threshold, the control server 200 blocks the message for the identified object (350). The control server 200 ignores the message transmitted by the identified object for a predetermined period of time. However, when the object blocking the message transmits the request message, the control server 200 can store the request message in the DB. A detailed description of the message blocking process will be given later.

제어서버(200)는 식별한 객체에 대한 메시지 차단 후에 일정한 시간이 경과했는지 확인한다(360). 식별한 객체에 대한 메시지를 차단하는 시간을 차단 시간이라고 명명한다. 제어서버(200)는 차단시간이 경과하면 식별한 객체에 대한 메시지 차단을 해제한다(370). The control server 200 determines whether a predetermined time has elapsed after blocking the message for the identified object (360). The time to block the message for the identified object is called the blocking time. The control server 200 releases the message blocking for the identified object when the blocking time elapses (370).

제어서버(200)가 나가는(Outbound) 메시지에 대한 트래픽을 제어하는 과정에 대하여 설명한다. 도 4는 송신 메시지에 대한 트래픽 제어 과정(400)의 순서도의 예이다. 제어서버(200)는 특정 객체에 메시지를 송신한다(310). 예컨대, 제어서버(200)는 특정 IoT 디바이스로부터 수집한 데이터를 특정 서버에 전달할 수 있다. 또는 제어서버(200)는 IoT 디바이스 또는 애플리케이션 서버에 일정한 제어 명령을 전달할 수 있다. 제어서버(200)는 애플리케이션 서버에 대해 특정한 URI 내지 IP 주소로 메시지를 송신한다. 제어서버(200)는 IoT 디바이스에 대해 특정한 IP 또는 특정한 ID로 메시지를 송신한다. 제어서버(200)는 LoRa 디바이스에 대해서는 MQTT 프로토콜을 이용하여 ID를 기준으로 메시지를 전달할 수 있다. 이하 설명의 편의를 위해 메시지 전송 대상을 URI로 식별한다고 가정한다. 현재 메시지를 전송한 URI를 타깃 URI라고 명명한다. A process of controlling traffic for an outbound message of the control server 200 will be described. 4 is an example of a flowchart of a traffic control procedure 400 for a transmission message. The control server 200 transmits a message to a specific object (310). For example, the control server 200 can deliver data collected from a specific IoT device to a specific server. Or the control server 200 may transmit a certain control command to the IoT device or the application server. The control server 200 sends a message to the application server with a specific URI or IP address. The control server 200 transmits the message to the IP or specific ID for the IoT device. The control server 200 can forward the message based on the ID using the MQTT protocol for the LoRa device. For convenience of explanation, it is assumed that a message transmission destination is identified by a URI. The URI that sent the current message is called the target URI.

제어서버(200)는 메시지 전송이 실패(Notification fail)했는지 확인한다(420). 메시지 전송이 실패했다면(420의 YES), 제어서버(200)는 타깃 URI가 화이트리스트(white list)에 있는지 확인한다(430). 화이트리스트는 트래픽을 제어하지 않고 메시지를 처리할 대상을 포함한다. 타깃 URI가 화이트리스트에 있다면(430의 YES), 제어서버(200)는 트래픽을 제한하지 않고 통상적인 메시지 처리를 수행한다(480). The control server 200 determines whether message transmission has failed (420). If the message transmission fails (YES at 420), the control server 200 checks 430 whether the target URI is in the white list. A whitelist contains objects to handle messages without controlling traffic. If the target URI is in the whitelist (YES of 430), the control server 200 performs normal message processing without limiting traffic (480).

타깃 URI가 화이트리스트에 없다면(430의 NO), 제어서버(200)는 기준 시간 동안 타깃 URI에 대한 메시지 전송이 실패한 횟수를 확인한다(440). 제어서버(200)는 기준 시간 동안 타깃 URI에 대한 메시지 전송의 실패 횟수가 임계값을 초과하는지 여부를 판단한다(440). 예컨대, 제어서버(200)는 현재 실패한 메시지를 포함하여 특정 타깃 URI에 1분(기준 시간)동안 3건(임계값) 보다 많은 전송이 있었는지를 판단할 수 있다. 제어서버(200)는 메시지를 전송한 시점 또는 실패 확인 시점을 기준으로 기준 시간 1분을 설정할 수 있다. 기준 시간, 기준 시간의 기준시점 또는 임계값은 시스템 성능, 네트워크 상황 등을 고려하여 다양한 값이 사용될 수 있다. 기준 시간 동안 타깃 URI에 대한 전송 실패 횟수를 누적 실패 횟수라고 명명한다. 제어서버(200)는 누적 실패 횟수가 임계값 이하라면, 트래픽을 제한하지 않고 통상적인 메시지 처리를 수행한다(480). If the target URI is not in the whitelist (NO at 430), the control server 200 checks 440 the number of times the message transmission for the target URI failed during the reference time. The control server 200 determines 440 whether the number of failure of message transmission to the target URI exceeds the threshold value during the reference time. For example, the control server 200 may determine whether there has been a transmission of more than three (thresholds) for one minute (reference time) to a particular target URI including the currently failed message. The control server 200 can set a reference time of 1 minute based on the time point at which the message is transmitted or the failure check point. The reference time and the reference time or threshold value of the reference time may be various values in consideration of system performance, network conditions, and the like. The number of transmission failures for the target URI during the reference time is called the cumulative failure count. If the number of accumulated failures is less than the threshold value, the control server 200 performs normal message processing without limiting the traffic (480).

제어서버(200)는 누적 실패 횟수가 임계값을 초과했다면, 타깃 URI에 대한 메시지를 차단한다(450). 제어서버(200)는 일정한 시간 동안 타깃 URI로 메시지를 전송하지 않는다. 다만 제어서버(200)는 타깃 URI에 대한 메시지 또는 타깃 URI에 대한 메시지 전송 요청을 DB에 저장할 수 있다. 메시지 차단 과정에 대한 상세한 설명은 후술한다.The control server 200 blocks 450 the message for the target URI if the number of accumulated failures exceeds the threshold. The control server 200 does not transmit the message to the target URI for a predetermined time. However, the control server 200 may store a message for the target URI or a message transmission request for the target URI in the DB. A detailed description of the message blocking process will be given later.

제어서버(200)는 식별한 객체에 대한 메시지 차단 후에 일정한 시간이 경과했는지 확인한다(460). 식별한 객체에 대한 메시지를 차단하는 시간을 차단 시간이라고 명명한다. 제어서버(200)는 차단시간이 경과하면 식별한 객체에 대한 메시지 차단을 해제한다(470). The control server 200 determines whether a predetermined time has elapsed after blocking the message for the identified object (460). The time to block the message for the identified object is called the blocking time. The control server 200 releases the message blocking for the identified object when the blocking time elapses (470).

제어서버(130, 200)가 트래픽을 제어한다고 전술하였다. 제어서버(130, 200)는 일정한 서비스를 수행하는 플랫폼으로 구현될 수 있다. 플랫폼은 하드웨어 구조와 관계 없이 기능적 구성으로 설명할 수 있다. 플랫폼은 특정 서비스를 수행하는 계층(layer)으로 설명할 수 있다. 제어서버(130, 200)는 아래 설명할 플랫폼이 구현된 물리적 장치이다. 이하 플랫폼의 동작에 대해 설명한다. 이하 트래픽을 제어하는 플랫폼을 IoT 플랫폼이라고 명명한다. It has been described above that the control servers 130 and 200 control traffic. The control servers 130 and 200 may be implemented as platforms for performing certain services. The platform can be described as a functional configuration regardless of the hardware structure. A platform can be described as a layer that performs a specific service. The control servers 130 and 200 are physical devices in which the platforms described below are implemented. The operation of the platform will be described below. The platform that controls the traffic is referred to as the IoT platform.

도 5는 IoT 플랫폼(500)에서 수신 메시지를 처리하는 과정에 대한 예이다. 먼저 IoT 플랫폼(500)에 대해 설명한다. IoT 플랫폼(500)은 크게 두 가지 기능적 구성을 갖는다. 서비스 제공부(510)는 IoT 서비스를 위한 메시지 처리 및 명령을 제어하는 구성이다. 서비스 제공부(510)는 제공하는 IoT 서비스의 종류에 따라 특정한 기능을 수행한다. 트래픽 제어부(520)는 제어 서버가 수신(Inbound)하는 메시지에 대한 트래픽을 제어한다.5 is an example of a process of processing a received message in the IOT platform 500. [ First, the IoT platform 500 will be described. The IOT platform 500 mainly has two functional configurations. The service provider 510 is a configuration for controlling message processing and commands for the IoT service. The service provider 510 performs a specific function according to the type of the provided IoT service. The traffic control unit 520 controls traffic for a message received by the control server.

트래픽 제어부(520)는 특정 객체(10)로부터 요청 메시지를 수신하면 먼저 객체를 식별한다(①과정). 트래픽 제어부(520)는 HTTP로 요청 메시지를 수신하면 메시지에 포함된 IP를 기준으로 객체를 식별한다. 트래픽 제어부(520)는 MQTT 프로토콜로 요청 메시지를 수신하면 메시지에 포함된 기기 ID로 LoRa 디바이스를 식별한다. 트래픽 제어부(520)는 식별한 기기에 대한 요청 메시지를 DB(530)에 전달하여 저장한다(②과정). 트래픽 제어부(520)는 식별기기에 대한 메시지 카운트를 수행한다(③과정). 트래픽 제어부(520)는 식별한 기기가 기준 시간 동안 전송했던 메시지의 개수(누적 개수)를 확인한다. 예컨대, 트래픽 제어부(520)는 LoRa 디바이스에 대해 최근 1분 동안 전송한 데이터가 10건을 초과하는지 확인할 수 있다. 트래픽 제어부(520)는 POST 명령으로 DB(530)에 저장된 정보를 조회하여 누적 개수를 확인할 수 있다. 또는 트래픽 제어부(520)는 애플리케이션 (서버)에 대해 최근 1분 동안 전송한 데이터가 100건을 초과하는지 확인할 수 있다. 트래픽 제어부(520)는 GET/OUT 또는 DELETE 명령으로 DB(530)에 저장된 정보를 조회하여 누적 개수를 확인할 수 있다. 누적 개수가 임계값을 초과했다면 트래픽 제어부(520)는 일정한 로그 정보를 생성한다(④과정). 트래픽 제어부(520)는 로그 정보를 DB(530)에 전달하여 저장한다.Upon receiving the request message from the specific object 10, the traffic control unit 520 first identifies the object (step (1)). When the traffic control unit 520 receives the request message via HTTP, the traffic control unit 520 identifies the object based on the IP included in the message. Upon receiving the request message in the MQTT protocol, the traffic control unit 520 identifies the LoRa device by the device ID included in the message. The traffic control unit 520 transmits a request message for the identified device to the DB 530 and stores it (step 2). The traffic control unit 520 performs a message count for the identification device (step 3). The traffic control unit 520 checks the number (cumulative number) of messages that the identified device transmitted during the reference time. For example, the traffic control unit 520 can check whether the data transmitted to the LoRa device in the last one minute exceeds ten. The traffic control unit 520 can check the accumulated number by inquiring the information stored in the DB 530 by the POST command. Alternatively, the traffic control unit 520 can check whether the data transmitted to the application (server) in the last one minute exceeds 100 cases. The traffic control unit 520 can check the accumulated number by inquiring information stored in the DB 530 by a GET / OUT or DELETE command. If the cumulative number exceeds the threshold value, the traffic control unit 520 generates certain log information (step 4). The traffic control unit 520 transmits the log information to the DB 530 and stores the log information.

DB(530)는 저장한 로그 정보를 일정한 시간이 경과하면 삭제한다. DB(530)는 MongoDB일 수 있다. MongoDB는 TTL(Time-to-Live) 기능을 이용하여 사전에 설정한 시간이 경과하면 해당 로그 정보를 자동으로 삭제할 수 있다. TTL 기능을 이용하는 경우 로그 정보를 삭제하는 주체는 DB(530)이다. The DB 530 deletes the stored log information after a predetermined time elapses. DB 530 may be MongoDB. MongoDB can automatically delete the log information when the preset time elapses by using TTL (Time-to-Live) function. When the TTL function is used, the DB 530 deletes log information.

한편 트래픽 제어부(520)는 현재 요청 메시지를 전달한 객체에 대해 DB(530)에 로그 정보가 있는지 확인할 수 있다. 현재 요청 메시지를 전달한 객체에 대해 DB(530)에 로그 정보가 있다면, 트래픽 제어부(520)는 해당 객체가 전달한 요청 메시지를 무시한다. 나아가 트래픽 제어부(520)는 현재 요청 메시지를 전송한 객체에 대해 DB(530)에 로그 정보가 있다면, 해당 로그 정보를 업데이트할 수 있다. 즉, 트래픽 제어부(520)는 현재 있는 로그 정보가 유지될 시간을 늘릴 수 있다.Meanwhile, the traffic control unit 520 can check whether the DB 530 has log information for the object that has transmitted the current request message. If there is log information in the DB 530 for the object that transmitted the current request message, the traffic control unit 520 ignores the request message transmitted by the object. The traffic control unit 520 may update the log information if the DB 530 has log information for the object that transmitted the current request message. That is, the traffic control unit 520 can increase the time at which the current log information is maintained.

플랫폼(500)이 트래픽을 제어하는 몇 가지 예를 설명한다. 도 5는 3개의 객체(10A, 10B 및 10C)를 도시한다. 객체(10A, 10B 또는 10C)는 IoT 디바이스라고 가정한다. 트래픽 제어부(520)는 IoT 디바이스(10A, 10B 및 10C)로부터 각각 요청 메시지를 수신한다. IoT 디바이스(10A)는 화이트리스트에 등록된 디바이스라고 가정한다. IoT 디바이스(10B 및 10C)는 화이트리스트에 없는 디바이스라고 가정한다. Some examples of how platform 500 controls traffic are described. Figure 5 shows three objects 10A, 10B and 10C. It is assumed that the object 10A, 10B or 10C is an IoT device. The traffic control unit 520 receives the request message from the IoT devices 10A, 10B, and 10C, respectively. It is assumed that the IoT device 10A is a device registered in the whitelist. It is assumed that IoT devices 10B and 10C are devices that are not in the whitelist.

(1) 트래픽 제어부(520)는 IoT 디바이스(10A)의 누적 개수가 임계값을 넘는지에 관계 없이 IoT 디바이스(10A)로부터 수신한 요청 메시지를 서비스 제공부(510)에 전달한다. (2) 트래픽 제어부(520)는 IoT 디바이스(10B)로부터 요청 메시지를 수신하고, IoT 디바이스(10B)에 대한 누적 개수를 확인한다. IoT 디바이스(10B)의 누적 개수가 임계값 이하라면, 트래픽 제어부(520)는 IoT 디바이스(10B)로부터 수신한 요청 메시지를 서비스 제공부(510)에 전달한다. (3) 트래픽 제어부(520)는 IoT 디바이스(10C)로부터 요청 메시지를 수신하고, IoT 디바이스(10C)에 대한 누적 개수를 확인한다. IoT 디바이스(10C)의 누적 개수가 임계값을 초과하면, 트래픽 제어부(520)는 IoT 디바이스(10C)에 대한 로그 정보를 생성한다. 이를 통해 트래픽 제어부(520)는 일정한 차단 시간 동안 IoT 디바이스(10C)에 대한 메시지를 차단한다.(1) The traffic control unit 520 delivers the request message received from the IoT device 10A to the service providing unit 510 irrespective of whether the cumulative number of the IoT devices 10A exceeds the threshold value. (2) The traffic control unit 520 receives the request message from the IoT device 10B and checks the cumulative number of the IoT devices 10B. If the cumulative number of IoT devices 10B is less than or equal to the threshold value, the traffic control unit 520 delivers the request message received from the IoT device 10B to the service provider 510. [ (3) The traffic control unit 520 receives the request message from the IoT device 10C and confirms the cumulative number of the IoT device 10C. When the cumulative number of IoT devices 10C exceeds the threshold value, the traffic control section 520 generates log information for the IoT device 10C. Through this, the traffic control unit 520 blocks the message for the IOT device 10C for a certain blocking time.

도 6은 IoT 플랫폼에서 수신 메시지를 처리하는 절차(600)에 대한 흐름도의 예이다. 트래픽 제어부(510)는 요청 메시지를 특정 디바이스(10)로부터 수신한다(601). 트래픽 제어부(510)는 수신한 요청 메시지를 DB(530)에 전달한다(602). DB(530)는 수신한 요청 메시지를 저장한다(603). 이때 DB(530)는 요청 메시지에 포함된 객체를 식별하는 정보(ID 또는 IP)에 따라 구분하여 요청 메시지를 저장할 수 있다. DB(530)는 요청 메시지를 전송한 객체에 대한 정보 및 해당 객체가 요청 메시지를 전송한 시간 등을 저장할 수 있다. 즉 DB(530)는 특정 객체가 일정한 시간을 기준으로 몇 건의 요청 메시지를 전송했는지 판단할 수 있는 정보만 보유할 수 있다.6 is an example of a flow diagram for a procedure 600 for processing a received message on the IoT platform. The traffic control unit 510 receives the request message from the specific device 10 (601). The traffic control unit 510 transmits the received request message to the DB 530 (602). The DB 530 stores the received request message (603). At this time, the DB 530 can store the request message in accordance with the information (ID or IP) identifying the object included in the request message. The DB 530 may store information about the object that sent the request message and the time when the object sent the request message. In other words, the DB 530 can hold only information that can determine how many request messages a particular object has transmitted based on a certain time.

트래픽 제어부(510)는 요청 메시지를 전달한 객체를 식별한다(610). 트래픽 제어부(510)는 요청 메시지가 HTTP로 전달되면 IP를 기준으로 객체를 식별한다. 트래픽 제어부(510)는 요청 메시지가 MQTT 프로토콜로 전달되면 ID를 기준으로 객체를 식별한다. The traffic control unit 510 identifies the object that transmitted the request message (610). The traffic control unit 510 identifies the object based on the IP when the request message is transmitted through HTTP. The traffic control unit 510 identifies the object based on the ID when the request message is transmitted in the MQTT protocol.

트래픽 제어부(510)는 식별한 객체가 화이트리스트에 있다면 해당 요청 메시지를 서비스 제공부(520)에 전달한다. 즉 정상적인 메시지 처리 서비스를 제공한다(620).If the identified object is in the whitelist, the traffic control unit 510 delivers the corresponding request message to the service provider 520. That is, a normal message processing service is provided 620.

트래픽 제어부(510)는 식별한 객체가 화이트리스트에 없다면, 식별한 객체가 기준 시간 동안 요청한 메시지 개수(누적 요청 개수)를 파악한다(630). 트래픽 제어부(510)는 DB(530)에 식별한 객체에 대한 누적 요청 개수를 질의하고, 이에 대한 응답을 수신할 수 있다(531).If the identified object is not in the whitelist, the traffic controller 510 determines 630 the number of messages (the number of accumulated requests) requested by the identified object during the reference time. The traffic control unit 510 queries the DB 530 for a cumulative number of requests for the identified object and receives a response to the cumulative number of requested objects (531).

트래픽 제어부(510)는 식별한 객체의 누적 요청 개수가 임계값을 초과하면, 해당 객체에 대한 메시지를 차단한다(640). 트래픽 제어부(510)는 해당 객체에 대한 로그 정보를 생성하여 DB(530)에 전달한다(640). DB(530)는 수신한 로그 정보를 저장한다(642). 로그 정보는 메시지가 자동으로 삭제될 시간(차단 시간)을 포함할 수 있다.If the number of accumulated requests of the identified objects exceeds the threshold value, the traffic control unit 510 blocks the message for the object (640). The traffic control unit 510 generates log information about the object and transmits it to the DB 530 (640). The DB 530 stores the received log information (642). The log information may include a time at which the message is automatically deleted (blocking time).

DB(530)에 해당 객체에 대한 로그 정보가 존재하는 동안(즉 차단 시간 내에) 동일 객체가 요청 메시지를 전송(651)하면 트래픽 제어부(510)는 수신한 요청 메시지를 처리하지 않고 계속 차단한다(660). 트래픽 제어부(510)는 현재 요청 메시지를 전송한 객체에 대한 로그 정보가 존재하는지 확인(661)하여 현재 차단 대상인자 여부를 확인할 수 있다. When the same object transmits a request message (651) while log information about the object exists in the DB 530 (i.e., within the blocking time), the traffic control unit 510 continues to block the received request message without processing 660). The traffic control unit 510 checks whether log information about the object that transmitted the current request message exists (661) to check whether the current blocking object is present.

DB(530)는 TTL에 기반하여 생성한 로그 정보를 삭제한다(671). 이후 객체(10)가 요청 메시지를 전송(681)하면, 트래픽 제어부(510)는 전술한 601 과정 후의 동작을 반복한다.The DB 530 deletes the log information generated based on the TTL (671). After that, when the object 10 transmits a request message (681), the traffic control unit 510 repeats the operation after step 601 described above.

도 7은 IoT 플랫폼(500)에서 송신 메시지를 처리하는 과정에 대한 예이다. 서비스 제공부(510)는 IoT 서비스를 위한 메시지 처리 및 명령을 제어하는 구성이다. 서비스 제공부(510)는 제공하는 IoT 서비스의 종류에 따라 특정한 기능을 수행한다. 트래픽 제어부(520)는 제어 서버가 송신(Outbound)하는 메시지에 대한 트래픽을 제어한다.7 is an example of a process of processing a transmission message in the IOT platform 500. [ The service provider 510 is a configuration for controlling message processing and commands for the IoT service. The service provider 510 performs a specific function according to the type of the provided IoT service. The traffic control unit 520 controls traffic for a message transmitted from the control server.

서비스 제공부(510)는 특정 객체(20)에 대한 URI로 메시지를 전송한다. 트래픽 제어부(520)는 특정 객체(20)에 대한 메시지 전송이 실패하면, 해당 URI에 대한 실패 정보를 DB(530)에 전달한다(①과정). DB(530)는 특정 URI에 대한 실패 정보를 저장한다. DB(530)는 특정 URI 및 전송 실패가 발생한 시간 등을 저장한다. 즉 DB(530)는 특정 URI에 대한 특정 시점을 기준으로 전술한 누적 실패 횟수를 결정할 수 있는 정보를 보유한다. 트래픽 제어부(520)는 현재 전송 실패가 발생한 URI에 대해 기준 시간 동안의 실패 횟수(누적 실패 횟수)를 조회한다(②과정). 트래픽 제어부(520)는 누적 실패 횟수가 임계값을 초고하면 해당 URI에 대한 로그 정보를 생성한다(③과정). The service provider 510 transmits the message to the URI of the specific object 20. If the message transmission to the specific object 20 fails, the traffic control unit 520 delivers failure information for the corresponding URI to the DB 530 (step (1)). DB 530 stores failure information for a specific URI. The DB 530 stores a specific URI and a time at which the transmission failure occurred. That is, the DB 530 holds information that can determine the above-described cumulative failure count based on a specific time point for a specific URI. The traffic control unit 520 inquires about the number of failures (the number of cumulative failures) during the reference time with respect to the URI where the current transmission failure occurred (step (2)). The traffic control unit 520 generates log information for the corresponding URI when the accumulated failure count exceeds the threshold value (step 3).

DB(530)는 수신한 로그 정보를 저장한다. DB(530)는 저장한 로그 정보를 일정한 시간이 경과하면 삭제한다. DB(530)는 MongoDB일 수 있다. MongoDB는 TTL(Time-to-Live) 기능을 이용하여 사전에 설정한 시간이 경과하면 해당 로그 정보를 자동으로 삭제할 수 있다. TTL 기능을 이용하는 경우 로그 정보를 삭제하는 주체는 DB(530)이다. The DB 530 stores the received log information. The DB 530 deletes the stored log information after a predetermined time elapses. DB 530 may be MongoDB. MongoDB can automatically delete the log information when the preset time elapses by using TTL (Time-to-Live) function. When the TTL function is used, the DB 530 deletes log information.

한편 트래픽 제어부(520)는 현재 전송 실패가 발생한 URI에 대해 DB(530)에 로그 정보가 있는지 확인할 수 있다. 현재 전송 실패가 발생한 URI에 대해 DB(530)에 로그 정보가 있다면, 트래픽 제어부(520)는 로그 정보에 있는 차단 시간 동안 메시지를 재전송하지 않는다. 나아가 트래픽 제어부(520)는 현재 전송 실패가 발생한 URI에 대해 DB(530)에 로그 정보가 있다면, 해당 로그 정보를 업데이트할 수 있다. 즉, 트래픽 제어부(520)는 현재 있는 로그 정보가 유지될 시간을 늘릴 수 있다.Meanwhile, the traffic control unit 520 can check whether the DB 530 has log information with respect to the URI where the transmission failure occurs at present. If there is log information in the DB 530 for the URI where the current transmission failure occurs, the traffic control unit 520 does not retransmit the message for the blocking time in the log information. Further, the traffic control unit 520 can update the log information if the DB 530 has the log information for the URI where the transmission failure has occurred at present. That is, the traffic control unit 520 can increase the time at which the current log information is maintained.

플랫폼(500)이 트래픽을 제어하는 몇 가지 예를 설명한다. 도 5는 3개의 객체(20A, 20B 및 20C)를 도시한다. 객체(20A, 20B 또는 20C)는 애플리케이션 서버라고 가정한다. 트래픽 제어부(520)는 애플리케이션 서버(20A, 20B 및 20C)로 각각 메시지를 전송하고, 모든 메시지가 실패한 상태라고 가정한다. 애플리케이션 서버(20A)는 화이트리스트에 등록된 디바이스라고 가정한다. 애플리케이션 서버(20B 및 20C)는 화이트리스트에 없는 디바이스라고 가정한다. Some examples of how platform 500 controls traffic are described. Figure 5 shows three objects 20A, 20B and 20C. It is assumed that the object 20A, 20B or 20C is an application server. The traffic control unit 520 transmits a message to each of the application servers 20A, 20B, and 20C, and assumes that all messages have failed. It is assumed that the application server 20A is a device registered in the whitelist. It is assumed that the application servers 20B and 20C are devices that are not whitelisted.

(1) 트래픽 제어부(520)는 애플리케이션 서버(20A)의 누적 실패 횟수가 임계값을 넘는지에 관계 없이 서비스 제공부(510)가 애플리케이션 서버(20A)로 메시지를 재전송하도록 한다. (2) 트래픽 제어부(520)는 애플리케이션 서버(20B)의 메시지 전송이 실패하면, 애플리케이션 서버(20B)에 대한 누적 실패 횟수를 확인한다. 애플리케이션 서버(20B)의 누적 실패 횟수가 임계값 이하라면, 트래픽 제어부(520)는 서비스 제공부(510)가 애플리케이션 서버(20B)로 메시지를 재전송하도록 한다. (3) 트래픽 제어부(520)는 애플리케이션 서버(20C)의 메시지 전송이 실패하면, 애플리케이션 서버(20C)에 대한 누적 실패 횟수를 확인한다. 애플리케이션 서버(20C)의 누적 실패 횟수가 임계값을 초과하면, 트래픽 제어부(520)는 애플리케이션 서버(20C)에 대한 로그 정보를 생성한다. 이를 통해 트래픽 제어부(520)는 일정한 차단 시간 동안 애플리케이션 서버(20C)에 대한 메시지 재전송을 차단한다.(1) The traffic control unit 520 causes the service provider 510 to resend the message to the application server 20A regardless of whether the cumulative failure count of the application server 20A exceeds the threshold value. (2) If the message transmission of the application server 20B fails, the traffic control unit 520 checks the cumulative failure count for the application server 20B. If the number of accumulation failures of the application server 20B is equal to or less than the threshold value, the traffic control unit 520 causes the service provider 510 to resend the message to the application server 20B. (3) If the message transmission of the application server 20C fails, the traffic control unit 520 checks the cumulative failure count for the application server 20C. If the number of cumulative failures of the application server 20C exceeds the threshold, the traffic control unit 520 generates log information for the application server 20C. Through this, the traffic control unit 520 blocks the message retransmission to the application server 20C for a predetermined blocking time.

도 8은 IoT 플랫폼에서 송신 메시지를 처리하는 절차(700)에 대한 흐름도의 예이다. Figure 8 is an example of a flow chart for a procedure 700 for processing a send message on the IoT platform.

트래픽 제어부(510)는 특정 객체(20)로 메시지를 전송한다. 트래픽 제어부(510)는 해당 객체(20)로부터 메시지 전송 실패에 대한 정보를 수신한다(701). 예컨대, 트래픽 제어부(510)는 해당 객체(20)로부터 NACK와 같은 메시지를 수신할 수 있다. 트래픽 제어부(510)는 전송 실패에 대한 정보(예컨대, URI 및 시간)를 DB(530)에 전달한다(702). DB(530)는 수신한 실패 정보를 저장한다(703). 이때 DB(530)는 URI에 따라 구분하여 실패 정보를 저장할 수 있다. DB(530)는 특정 객체에 대해 일정한 시간을 기준으로 몇 건의 전송 실패가 있었는지 판단할 수 있는 정보만 보유할 수 있다.The traffic control unit 510 transmits the message to the specific object 20. The traffic control unit 510 receives the message transmission failure information from the object 20 (701). For example, the traffic control unit 510 may receive a message such as NACK from the object 20. The traffic control unit 510 transmits information (e.g., URI and time) about the transmission failure to the DB 530 (702). The DB 530 stores the received failure information (703). At this time, the DB 530 can store the failure information according to the URI. The DB 530 can hold only information that can determine how many transmission failures have occurred with respect to a specific object based on a predetermined time.

트래픽 제어부(510)는 전송 실패한 URI가 화이트리스트에 있다면 해당 메시지를 다시 재전송한다(712). 트래픽 제어부(510)가 메시지 재전송을 수행할 수도 있고, 트래픽 제어부(510)가 서비스 제공부(520)에 메시지 재전송 명령을 전달할 수도 있다.If the failed URI is in the whitelist, the traffic control unit 510 retransmits the message again (712). The traffic control unit 510 may perform message retransmission or the traffic control unit 510 may transmit a message retransmission command to the service providing unit 520. [

트래픽 제어부(510)는 전송 실패한 URI가 화이트리스트에 없다면, 해당 URI에 대한 누적 실패 횟수를 파악한다(720). 트래픽 제어부(510)는 DB(530)에 해당 URI에 대한 누적 실패 개수를 질의하고, 이에 대한 응답을 수신할 수 있다(721).If the failed URI is not in the whitelist, the traffic controller 510 determines the cumulative failure count for the corresponding URI (720). The traffic control unit 510 queries the DB 530 for the cumulative failure count of the URI and receives a response to the cumulative failure count (721).

트래픽 제어부(510)는 해당 URI의 누적 실패 개수가 임계값을 초과하면, 일정한 시간 동안 동일 객체에 대한 메시지 재전송을 차단한다(730). 트래픽 제어부(510)는 해당 URI에 대한 로그 정보를 생성하여 DB(530)에 전달한다(731). DB(530)는 수신한 로그 정보를 저장한다(732). 로그 정보는 메시지가 자동으로 삭제될 시간(차단 시간)을 포함할 수 있다.If the cumulative failure number of the corresponding URI exceeds the threshold value, the traffic control unit 510 blocks the message retransmission for the same object for a predetermined time (730). The traffic control unit 510 generates log information about the URI and transmits the log information to the DB 530 (731). The DB 530 stores the received log information (732). The log information may include a time at which the message is automatically deleted (blocking time).

트래픽 제어부(510)는 차단 시간 동안 해당 URI에 대한 메시지 재전송을 차단하면서, 로그 정보가 삭제(차단 해제)되는지를 모니터링한다(740). 트래픽 제어부(510)는 DB(530)에 차단된 URI에 대한 로그 정보가 존재하는지 확인할 수 있다(741). The traffic control unit 510 monitors whether the log information is deleted (unblocked) while blocking the message retransmission for the corresponding URI during the blocking period (740). The traffic control unit 510 can check whether the log information about the URI blocked in the DB 530 exists (741).

DB(530)는 TTL에 기반하여 생성한 로그 정보를 삭제한다(751). 이후 트래픽 제어부(510)는 차단했던 객체(URI)에 대하여 메시지 재전송을 수행할 수 있다(761).The DB 530 deletes the log information generated based on the TTL (751). Thereafter, the traffic control unit 510 may perform message retransmission for an object (URI) that has been blocked (761).

본 실시례 및 본 명세서에 첨부된 도면은 전술한 기술에 포함되는 기술적 사상의 일부를 명확하게 나타내고 있는 것에 불과하며, 전술한 기술의 명세서 및 도면에 포함된 기술적 사상의 범위 내에서 당업자가 용이하게 유추할 수 있는 변형 예와 구체적인 실시례는 모두 전술한 기술의 권리범위에 포함되는 것이 자명하다고 할 것이다.The present embodiment and drawings attached hereto are only a part of the technical idea included in the above-described technology, and it is easy for a person skilled in the art to easily understand the technical idea included in the description of the above- It will be appreciated that variations that may be deduced and specific embodiments are included within the scope of the foregoing description.

10 : 객체
10A, 10B, 10C: 객체
20 : 객체
20A, 20B, 20C : 객체
50 : 컴퓨터 장치
100 : 시스템
110 : IoT 디바이스
110A, 110B, 110C: IoT 디바이스
120 : AP
120A, 120B : AP
130 : 제어서버
140 : 애플리케이션 서버
140A, 140B : 애플리케이션 서버
150 : 서비스 제공자 단말
160 : 사용자 단말
200 : 제어서버
210 : 통신 인터페이스 장치
220 : 저장 장치
230 : 제어장치
240 : DB
500 : IoT 플랫폼
510 : 트래픽 제어부
520 : 서비스 제공부
530 : DB10: Objects
10A, 10B, 10C: Objects
20: Object
20A, 20B, 20C: object
50: Computer device
100: System
110: IoT device
110A, 110B, 110C: IoT devices
120: AP
120A, 120B: AP
130: control server
140: Application server
140A, 140B: application server
150: service provider terminal
160: User terminal
200: control server
210: Communication interface device
220: Storage device
230: Control device
240: DB
500: IoT platform
510: Traffic control unit
520: Service Offering
530: DB

Claims

The control server receiving a request message for the IoT service;
Identifying the LoRa device from which the control server has generated the request message based on the identifier included in the request message;
Blocking the message delivered by the LoRa device when the number of request messages transmitted by the control server during the reference time in the LoRa device exceeds a threshold value; And
And releasing message blocking for the LoRa device after the control server has elapsed a predetermined time since the blocking time.

The method according to claim 1,
Wherein the control server does not block the message delivered by the LoRa device even if the number of times exceeds the threshold value when the identifier is in the whitelist.

The method according to claim 1,
Wherein the control server generates log information for the LoRa device and blocks the message based on the log information.

The method according to claim 1,
Wherein the control server releases the message blocking by using a TTL (Time-to-Live) function of MongoDB.

The method according to claim 1,
Wherein the control server receives the request message from the LoRa device via an MQTT (MQ Telemetry Transport) protocol.

The method according to claim 1,
The control server further receives a new request message transmitted through HTTP (Hyper Text Transfer Protocol), identifies an application that generated the new request message based on the IP included in the new request message, And blocking the message delivered by the application for a certain period of time if the number of request messages transmitted during the time exceeds a threshold value.

The method according to claim 1,
Wherein the control server transmits a message to a specific URI and further comprises blocking a message for the URI for a predetermined time when a message transmission to the URI fails for a reference time during a reference time.

The control server receiving a request message for the IoT service;
Identifying the object that generated the request message based on the IP included in the request message when the control server transmits the request message in HTTP (Hyper Text Transfer Protocol);
Identifying the object that generated the request message based on the identifier included in the request message when the control server transmits the request message in the MQTT (MQ Telemetry Transport) protocol;
Blocking a message delivered by the object when the number of request messages transmitted by the control server during the reference time in the object identified by the IP or the identifier exceeds a threshold value; And
And releasing message blocking for the object after a predetermined time has elapsed since the blocking time of the control server.

9. The method of claim 8,
Wherein the control server does not block the message delivered by the object even if the number of times exceeds the threshold when the identified object is in the whitelist.

9. The method of claim 8,
Wherein the control server generates log information for the object and blocks the message based on the log information.

9. The method of claim 8,
Wherein the control server releases the message blocking by using a TTL (Time-to-Live) function of MongoDB.

9. The method of claim 8,
DB stores information on a request message received from the control server, and the control server determines that the number of times exceeds the threshold based on the information.

9. The method of claim 8,
The control server generates log information for the object and stores the log information in the DB when the number of times exceeds the threshold value; And
Wherein the DB further comprises deleting the log information stored using a TTL (Time-to-Live) function.

9. The method of claim 8,
Wherein the control server transmits a message to a specific URI and further comprises blocking a message for the URI for a predetermined time when a message transmission to the URI fails for a reference time during a reference time.

A communication interface device for exchanging messages with the LoRa device and the application server;
A database for storing an identifier of the LoRa device, an IP of the application server, and log information about the LoRa device or the application server; And
The LoRa device or the application server identifies the LoRa device or the application server in the request message received by the communication interface, and when the number of request messages transmitted during the reference time at the identified LoRa device or the application server exceeds the threshold value, And a control device for generating log information for the application server and blocking messages for the identified LoRa device or application server for a time set in the log information.

16. The method of claim 15,
The control device receives a request message from the LoRa device through an MQTT (MQ Telemetry Transport) protocol and receives a request message from the application server via HTTP (Hyper Text Transfer Protocol).

16. The method of claim 15,
Wherein the database deletes log information indicating a blocking time for the message using a TTL (Time-to-Live) function of MongoDB.