KR102042027B1 - Traffic load management apparatus and method based on coordinated application protocol for internet of things local networks - Google Patents

Abstract

The present invention relates to a traffic load management method based on Constrained Application Protocol (CoAP) in an Internet of Things (IoT) local network, and the traffic load management method includes a registration message received from a plurality of servers included in a server group in a traffic load management device. And / or integrating the update message to generate an integration message; And transmitting, by the traffic load management apparatus, the generated integrated message to a resource directory, wherein the integrated message transmitted to the resource directory transmits a plurality of messages related to the integrated message. Resource entries of the server may be registered and / or updated in the resource directory.

Description

TRAFFIC LOAD MANAGEMENT APPARATUS AND METHOD BASED ON COORDINATED APPLICATION PROTOCOL FOR INTERNET OF THINGS LOCAL NETWORKS}

The present invention relates to an apparatus and method for traffic load management based on Constrained Application Protocol (CoAP) for solving a scalability problem by using a centralized resource retrieval approach in a large scale Internet of Things (IoT) local network.

Recently, interest in the Internet of Things (IoT) is rapidly increasing, and IoT technology is becoming more common. IoT is generally regarded as the primary technology for large-scale monitoring applications such as smart cities, smart factories, and smart farms. In these large-scale applications, the IoT local network consists of a number of devices with limited physical resources such as limited battery, memory, and CPU and is similar to a wireless sensor network (WSN).

The Core Working Group of the Internet Engineering Task Force (IETF) developed and standardized the Constrained Application Protocol (CoAP) such as battery, memory and CPU. CoAP stands for lightweight web transport protocol for resource-constrained devices in IoT local networks, maintains a small header size, and operates on user datagram protocol (UDP).

Resource discovery in CoAP is an essential step for clients to obtain the necessary resources from the server. There are two types of CoAP resource discovery: distributed and centralized resource discovery. Distributed resource retrieval is a method in which a client directly queries a specific server, which is disadvantageous for large IoT local networks because the client must know an Internet Protocol (IP) address and multiple host names.

Centralized resource discovery, on the other hand, uses a resource directory (RD) to maintain a set of web links known as RD entries on the server for energy efficiency. This centralized method using RD suffers from low scalability when used in large IoT local networks, just like distributed resource discovery. In large IoT local networks, a large number of servers periodically send update messages to RD to keep resource entries up to date. However, RD has a problem in that it cannot afford to receive all update messages because of the limited bandwidth of the radio link. In addition, in RD, as traffic load increases, problems such as message loss, network congestion, and bottlenecks appear. Therefore, in order to overcome the scalability problem in the IoT local network environment, a load balancing mechanism for RD is required.

In order to solve the above problems, a lot of researches on resource search and RD have been performed in the past.

As an example, the paper ["A Proactive Trickle-based Mechanism for Discovering CoRE Resource Directories", Badis Djamaa and Ali Yachir, Procedia Computer Science 83 (2016) 115-122] prior art based on adaptive trickle timers. Proactive RD discovery (PRD) mechanism has been proposed. This mechanism uses a trickle timer for effective RD retrieval, and CoAP messages called directory advertisements (DAs) are propagated in waves to all nodes to perform RD discovery. However, since the prior art focuses only on RD and does not consider the traffic overhead and concentration of RD due to resource update at all, there are still problems such as message loss, network congestion, and bottlenecks.

In addition, "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] proposed a hybrid mechanism to overcome the overload on RD. This mechanism uses a centralized resource retrieval method using RD by default, and when an overload occurs in RD, the client broadcasts the message directly using a distributed method. However, the technique of the prior art has a problem that can not prevent the traffic load problem of RD in advance.

The present invention is to solve the above-described problems of the prior art, traffic load management based on Constrained Application Protocol (CoAP) to solve the scalability problem by using a centralized resource discovery approach in a large Internet of Things (IoT) local network It is an object to provide an apparatus and method.

The present invention is to solve the above-mentioned problems of the prior art, to provide a traffic load management apparatus and method based on CoAP (Constrained Application Protocol) that can balance the traffic load due to a large number of messages focused on RD The purpose.

The present invention is to solve the above-mentioned problems of the prior art, the conventional traffic load management apparatus based on CoAP (Constrained Application Protocol) that can solve the problem that RD was not able to receive all the update message because of the limited bandwidth of the radio link And to provide a method.

The present invention is to solve the above-described problems of the prior art, in the case of the conventional RD Constrained Application Protocol (CoAP) that can solve the problem of lost messages, network congestion and bottlenecks as traffic load increases An object of the present invention is to provide a traffic load management apparatus and method.

However, the technical problem to be achieved by the embodiments of the present application is not limited to the technical problems as described above, and other technical problems may exist.

As a technical means for achieving the above technical problem, a traffic load management method based on Constrained Application Protocol (CoAP) in the Internet of Things (IoT) local network according to an embodiment of the present application, in the traffic load management apparatus, server group Generating an integration message by integrating a registration message and / or an update message received from a plurality of servers included in the; And transmitting, by the traffic load management apparatus, the generated integrated message to a resource directory, wherein the integrated message transmitted to the resource directory transmits a plurality of messages related to the integrated message. Resource entries of the server may be registered and / or updated in the resource directory.

The generating may include generating the integration message by sequentially counting and integrating registration messages and / or update messages received from the plurality of servers.

In addition, the transmitting may include determining a transmission time at which the integration message is transmitted to the resource directory.

In the determining of the transmission time, the transmission time may be determined in consideration of the maximum payload size of the message format of the CoAP.

The determining of the transmission time may include determining the transmission time at a time when the payload size of the plurality of messages included in the integrated message does not exceed the maximum payload size of the message format of the CoAP, The determination of the transmission time may determine the maximum number of registration messages and / or update messages incorporated as the merge message.

In addition, the traffic load management method based on the Constrained Application Protocol (CoAP) in the Internet of Things (IoT) local network, in response to the integrated message transmitted to the resource directory in the traffic load management device When receiving a response message regarding normal registration and / or normal update from the resource directory, the method may further include transmitting the response message to a server that has transmitted the plurality of messages related to the integrated message.

The transmitting of the response message may include transmitting the response message based on a Uniform Resource Identifier (URI) list for the server group generated by receiving a registration message.

In addition, the traffic load management method based on the Constrained Application Protocol (CoAP) in the Internet of Things (IoT) local network according to an embodiment of the present invention, before the generating step, in the traffic load management device, the resource of the CoAP Transmitting information about the traffic load management device to the resource directory in response to a GET request message received from the resource directory for searching; And in the traffic load management apparatus, based on the server group information assigned to the traffic load management apparatus by the resource directory based on the information about the traffic load management apparatus, to the server group corresponding to the server group information. The method may further include receiving a registration message and / or an update message from a plurality of servers included.

In addition, the traffic load management apparatus may be provided in plurality in correspondence with each of the plurality of server groups when a plurality of server groups exist.

Meanwhile, a traffic load management apparatus based on Constrained Application Protocol (CoAP) in an Internet of Things (IoT) local network according to an embodiment of the present application may include a registration message and / or an update message received from a plurality of servers included in a server group. Message aggregation unit for generating a unified message by integrating; And a transmitter configured to transmit the integrated message to a resource directory, wherein a resource entry of a server that transmits a plurality of messages related to the integrated message is stored in the resource directory by the integrated message transmitted to the resource directory. It can be registered and / or updated.

Meanwhile, a traffic load management system based on a Constrained Application Protocol (CoAP) in an Internet of Things (IoT) local network according to an embodiment of the present application transmits a resource entry to a traffic load management apparatus through a registration message and / or an update message. A server group including a plurality of servers configured to integrate a registration message and / or an update message received from a plurality of servers included in the server group, thereby generating an integrated message, and generating the integrated message; The traffic load management device for transmitting to; And the resource directory for registering and / or updating a resource entry of a server that has transmitted a plurality of messages related to the integrated message, based on the integrated message received from the traffic load management apparatus.

The traffic load management apparatus may include a plurality of server load groups corresponding to each of the plurality of server groups.

The above-mentioned means for solving the problems are merely exemplary and should not be construed as limiting the present application. In addition to the above-described exemplary embodiments, additional embodiments may exist in the drawings and detailed description of the invention.

According to the above-described problem solving means of the present application, the traffic load management apparatus transmits an integrated message in which a plurality of registration messages and update messages are combined into one message to the resource directory RD, so that a large number of messages focused on RD. This can solve the imbalance problem caused by the traffic load.

According to the aforementioned problem solving means of the present application, it is possible for the integrated message to effectively improve the number of messages lost and the message loss rate compared to the conventional RD technology.

According to the aforementioned problem solving means of the present application, it is possible to solve the scalability problem of the centralized resource search approach in a large-scale IoT local network.

However, the effects obtainable herein are not limited to the effects as described above, and other effects may exist.

1 is a diagram illustrating a schematic configuration of a CoAP-based traffic load management system in an IoT local network according to an embodiment of the present application.
2 is a diagram schematically illustrating a flow of a resource search operation of a CoAP in a traffic load management system according to an embodiment of the present application.
3 is a diagram schematically illustrating a flow of a resource entry registration operation in a traffic load management system according to an embodiment of the present application.
4 is a diagram schematically illustrating a flow of a resource entry update operation in a traffic load management system according to an embodiment of the present application.
5 is a diagram illustrating an example of a parameter applied to a simulation according to an exemplary embodiment of the present application.
6 is a view showing a change in the number of lost messages according to the change in the number of servers in the experiment according to an embodiment of the present application.
7 is a diagram illustrating a message loss rate according to the change of the number of servers in an experiment according to an embodiment of the present application.
8 is a view showing the number of messages lost when the bandwidth is changed from 1Mbps to 1.45Mbps in an experiment according to an embodiment of the present application.
9 is a diagram illustrating a message loss rate when the bandwidth is changed from 1 Mbps to 1.45 Mbps in an experiment according to an embodiment of the present application.
FIG. 10 is a flowchart illustrating a CoAP-based traffic load management method in an IoT local network according to an embodiment of the present application.

DETAILED DESCRIPTION Hereinafter, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings so that those skilled in the art may easily implement the present disclosure. As those skilled in the art would realize, the described embodiments may be modified in various different ways, all without departing from the spirit or scope of the present invention. In the drawings, parts irrelevant to the description are omitted for simplicity of explanation, and like reference numerals designate like parts throughout the specification.

Throughout this specification, when a part is "connected" to another part, it is not only "directly connected" but also "electrically connected" or "indirectly connected" with another element in between. "Includes the case.

Throughout this specification, when a member is said to be located on another member "on", "upper", "top", "bottom", "bottom", "bottom", this means that any member This includes not only the contact but also the presence of another member between the two members.

Throughout this specification, when a part is said to "include" a certain component, it means that it can further include other components, without excluding the other components unless specifically stated otherwise.

The present invention relates to a traffic load management system, apparatus and method based on Constrained Application Protocol (CoAP) for solving the scalability problem of a centralized resource retrieval approach in a large scale Internet of Things (IoT) local network.

FIG. 1 is a diagram illustrating a schematic configuration of a traffic load management system based on a Constrained Application Protocol (CoAP) in the Internet of Things (IoT) local network according to an embodiment of the present application (hereinafter, referred to as 'the present system').

Referring to FIG. 1, the system 1 may include a server group 100, a traffic load management apparatus 200, and a resource directory 300.

The server group 100 may include a plurality of servers, and each of the plurality of servers may transmit its resource entry to the traffic load management apparatus 200 through a registration message and / or an update message. In the system 1, a plurality of server groups 100 including a plurality of servers may be provided. For example, the server group 100 may be a plurality of server groups, the first server group 110 (Server group # 1), the second server group 120 (Server group # 2),. It may include an n-th server group (1n0, Server group #n). For example, the first server group 110 may include a first server 111 (Server # 1), a second server 112 (Server # 2),. It may include the n-th server (11n, Server #n).

The traffic load management apparatus 200 may serve as an intermediate agent between the server and the resource directory 300.

The traffic load management apparatus 200 may include a plurality of server groups 100 corresponding to each of the plurality of server groups. For example, the traffic load management apparatus 200 may include the first traffic load management apparatus 210 (LB-RD # 1), the second traffic load management apparatus 220 (LB-RD # 2),. , The n th traffic load management apparatus 2n0 and LB-RD #n.

Here, for example, the first traffic load management device 210 refers to a traffic load management device associated with the first server group 110, and the second traffic load management device 220 is associated with the second server group 120. The traffic load management device, and the n-th traffic load management device (2n0) may mean a traffic load management device associated with the n-th server group (1n0). In this case, the traffic load management apparatus associated with the server group refers to managing the server group (that is, managing information related to the plurality of servers included in the server group), and the plurality of servers and messages included in the server group. It may mean a traffic load management device for transmitting and receiving.

In the following description, it is assumed that the server group 100 is the first server group 110 and the traffic load management apparatus 200 is the first traffic load management apparatus 210. In addition, even if omitted below, the content described with respect to the first server group 110 may be understood in the same or similar manner to the description of other server groups, and the description of the first traffic load management apparatus 210 may be described. The content may be understood in the same or similar manner to the description of other traffic load management apparatus.

The traffic load management apparatus 200 integrates registration messages and / or update messages received from a plurality of servers included in the server group 100 to generate an integrated message (aggregate message), and generates the integrated message as a resource directory ( 300).

The present application solves the scalability problem of the centralized resource retrieval approach in a large IoT local network through the integration of a plurality of messages through the traffic load management apparatus 200, and with a large number of messages concentrated in the resource directory 300. It can balance the traffic load caused. Meanwhile, the traffic load management apparatus 200 proposed herein may be referred to simply as an LB-RD as a load-balanced resource directory (LB-RD) architecture. A detailed description of the traffic load management apparatus 200 will be described later in more detail.

The resource directory 300 may refer to a directory for maintaining a series of web links known as RD entries in a server for energy efficiency in performing a centralized resource search in a Constrained Application Protocol (CoAP).

The resource directory 300 may register and / or update a resource entry of a server that has transmitted a plurality of messages related to the integrated message, based on the integrated message received from the traffic load management apparatus 200.

In the system 1, message transmission and reception between each of the plurality of servers included in the server group 100, the traffic load management apparatus 200, and the resource directory 300 may be performed based on CoAP (Coordinated Application Protocol). Hereinafter, the traffic load management apparatus 200 will be described in more detail.

The traffic load management apparatus 200 may include a server group management unit 211, a message aggregation unit 212, a message aggregation unit (MS), and a transmission unit 213.

The server group manager 211 may manage a Uniform Resource Identifier (URI) list (list) for the server group 100 associated with the traffic load management apparatus 200. As a specific example, the server group management unit 211 of the first traffic load management apparatus 210 may include a Uniform Resource Identifier (URI) list for the first server group 110 associated with the first traffic load management apparatus 210. List), and the server group manager of the second traffic load management apparatus 220 includes a uniform resource identifier (URI) list (list) for the second server group 120 associated with the second traffic load management apparatus 220. ) Can be managed.

Here, the URI list (list) may be generated when a server included in the server group 100 tries to register its resource entry in the resource directory 300 through a registration message. In addition, the URI list (list) after the traffic load management device 200 generates a unified message by aggregating messages received from a plurality of servers included in the server group 100 through the function of the message aggregation unit 212 It can be used when you want to multicast the response message to the server.

The message aggregation unit 212 may generate registration messages (or, alternatively, aggregation messages) by integrating registration messages and / or update messages received from a plurality of servers included in the server group 100. When generating the integrated message, the message aggregation unit 212 may generate an integrated message including a plurality of registration messages, generate an integrated message including a plurality of update messages, or generate an integrated message including both a registration message and an update message. can do.

The message aggregation unit 212 may aggregate registration messages and / or update messages received from a plurality of servers included in the server group 110. In detail, the message aggregation unit 212 may generate an integration message by sequentially counting (or aggregation) registration messages and / or update messages received from a plurality of servers.

The message aggregation unit 212 may generate an integration message by integrating a plurality of registration messages and / or update messages received from a plurality of servers as a single aggregation message.

The unified message generated by the message aggregater 212 may consist of a payload and a single header of a plurality of independent messages.

The transmitter 213 may transmit the integrated message generated by the message aggregater 212 to the resource directory 300 (Resource Directory, RD).

In this case, the transmitter 213 may determine a transmission time for transmitting the integrated message to the resource directory 300. In other words, the transmitter 213 may determine a time at which the integrated message is transmitted to the resource directory 300. That is, the transmitter 213 may determine a time (transmission time) for when (at what time) the integrated message aggregated by the message aggregater 212 is transmitted to the resource directory 300. In other words, when the integrated message is transmitted to the resource directory 300 may be determined by determining the transmission time through the transmitter 213. The transmitter 213 may transmit the integrated message to the resource directory 300 at the determined transmission time. A detailed description of the determination of the transmission time is as follows.

The transmitter 213 may determine the transmission time in consideration of the maximum payload size of the message format of the CoAP. The transmitter 213 may determine the transmission time to a point in time where the payload size of the plurality of messages included in the unified message does not exceed the maximum payload size of the message format of the CoAP. In other words, the transmitting unit 213 indicates that the payload size of the plurality of messages (ie, the plurality of registration messages and / or update messages) integrated by the message aggregation unit 212 is the maximum payout of the message format of the CoAP. The transmission time can be determined to a point in time not exceeding the load size. In this case, the number k of maximum registration messages and / or update messages to be integrated as an integrated message may be determined by determining the transmission time. In other words, the transmission time may be determined at a time point when the payload size of the plurality of messages included in the unified message is smaller than or equal to the maximum payload size of the CoAP message.

As an example, it is assumed that the traffic load management apparatus 200 receives only a registration message from a plurality of servers. In this case, the message aggregation unit 212 may count the number of the plurality of registration messages received from the plurality of servers and integrate the received registration messages sequentially. In this case, the maximum number k of registration messages that can be integrated for transmission to the resource directory 300 may satisfy Equation 1 below. In other words, the number k of registration messages that can be integrated at one time for transmission to the resource directory 300 may satisfy Equation 1 below.

[Equation 1]

Where k is the number of registration messages that can be merged as one unified message, L _Reg is the payload size of the registration message sent from the server, and L _CoAP is the maximum payload size of the message format of CoAP.

For example, if the maximum payload size ( L _Reg ) of the message format of CoAP is 1000, and the payload size of the registration message is 100, which is 1/10 the size of the maximum payload size ( L _CoAP ) of the message format of _CoAP , k may be determined to be 10. According to this, the message aggregator 212 may generate an integrated message incorporating 10 registration messages, and the transmission unit 213 may be a time when 10 registration messages are integrated, that is, 10 registration messages are integrated to integrate the message. The integration message may be transmitted to the resource directory 300 at the time point is generated.

In this case, Equation 1 describes that only the payload size ( L _Reg ) of the registration message transmitted from the server is considered in addition to the maximum payload size of the message format of CoAP when determining the value of k , but is not limited thereto. For example, when the traffic load management apparatus 200 receives only update messages from a plurality of servers, the payload size of the update message may be considered. As another example, when the traffic load management apparatus 200 is receiving a registration message and an update message from a plurality of servers, the payload size of the registration message and the payout of the update message, in addition to the maximum payload size of the message format of the CoAP. Load size can be considered together.

Such a transmitter 213 may be referred to as a message forwarding scheduling (MFS).

The transmission unit 213 may transmit (deliver) the integrated message generated by the message aggregation unit 212 to the resource directory 300 immediately after generation of the integrated message, in order to prevent additional delay. Here, the resource entry of the server that transmits the plurality of messages related to the integrated message may be registered and / or updated in the resource directory 300 by the integrated message transmitted to the resource directory 300.

In addition, the transmission unit 213 receives a response message regarding normal registration and / or normal update of a resource entry of a server related to the integration message from the resource directory 300 in response to the integration message transmitted to the resource directory 300. In one case, the received response message may be transmitted (delivered) to a server that has transmitted a plurality of messages related to the integrated message. In this case, the transmitter 213 may transmit the response message to the server group manager 211 based on a Uniform Resource Identifier (URI) list for the server group generated by receiving the registration message.

That is, after the transmission unit 213 transmits the integration message to the resource directory 300, the resource directory 300 registers the resource entry of the server that sent the registration message when the registration message is included in the received integration message. If the received integrated message includes an update message, the resource entry of the server that sent the update message may be updated. Thereafter, when the registration or update is normally performed, the resource directory 300 may transmit a response message for the normal registration or normal update to the traffic load management apparatus 200. The traffic load management apparatus 200 may transmit (deliver, multicast) a response message received from the resource directory 300 to a server associated with the response message (that is, a server that has normally registered or successfully updated a resource entry). have. In this case, the transmission unit 213 may transmit the response message using a URI list managed by the server group manager 211 (see reference).

The present system 1 causes the traffic load management apparatus 200 to integrate the registration message or the update message of the server into an integrated message and transmit the integrated message to the resource directory 300, thereby effectively managing the traffic load concentrated in the resource directory 300. Can be reduced. In other words, in order to alleviate the traffic load problem of the resource directory 300 due to the concentration of the registration message or the update message of the server, the traffic load management apparatus 200 proposed by the present application aggregates the messages transmitted from the server. After merging as a merge message, the merged merge message may be sent to the resource directory 300.

That is, the present application proposes a traffic load management device based on CoAP (that is, LB-RD architecture) to solve the scalability problem of the centralized resource discovery approach in a large IoT local network. Specifically, in order to balance the traffic load due to the large number of messages concentrated in the resource directory 300, the traffic load management apparatus 200 may serve as an intermediate agent between the server and the resource directory 300. . In particular, the traffic load management apparatus 200 manages a Uniform Resource Identifier (URI) list of the server group 100 associated with the traffic load management apparatus 200, and registers a registration message and an update message received from the server into a single aggregate message, That is, the integration message may be integrated, and after determining the transmission time for transmitting the integration message to the resource directory 300, the integration message may be transmitted at the determined transmission time.

Meanwhile, the traffic load management apparatus 200 may perform a resource search operation, a resource entry registration operation, and a resource entry update operation of the CoAP. Hereinafter, the above-described search operation, registration operation and update operation will be described in more detail. However, in the following description, for convenience of explanation, each of the search operation, the registration operation, and the update operation will be described as separate operations, and the present invention is not limited thereto, and at least some of the operations may be performed together.

First, the traffic load management apparatus 200 loads the traffic in response to the GET request message received from the resource directory 300 for resource search of the CoAP before generating the integrated message through the message aggregation unit 212. Information (eg, address, port, etc.) regarding the management device 200 may be transmitted to the resource directory 300. Thereafter, the traffic load management apparatus 200 based on the server group information assigned to the traffic load management apparatus 200 by the resource directory 300 based on the information about the traffic load management apparatus 200, The registration message and / or the update message may be received from a plurality of servers included in the server group corresponding to the group information. Thereafter, the traffic load management apparatus 200 may generate an integrated message based on the received registration message and / or update message. A more detailed description may be more readily understood with reference to FIGS. 2 to 4.

2 is a diagram schematically illustrating a flow of a resource discovery operation of a CoAP in a traffic load management system according to an embodiment of the present application. 3 is a diagram schematically illustrating a flow of a resource entry registration operation in a traffic load management system according to an embodiment of the present application. 4 is a diagram schematically illustrating a flow of a resource entry update operation in a traffic load management system according to an embodiment of the present application.

In the following description with reference to FIG. 2, as an example, the LB-RD is assumed to be the first traffic load management device 210 of the traffic load management device 200, and is not limited thereto. 1 may be similarly or similarly applied to other traffic load management devices.

Referring to FIG. 2, in the case of a resource search operation of a CoAP, the traffic load management apparatus 210 receives a GET request message for searching (discovering) the traffic load management apparatus 210 from the resource directory 300 (S201). can do. The traffic load management apparatus 210 sends information (eg, address, port, etc.) about the traffic load management apparatus 210 to the resource directory 300 in response to the GET request message transmitted from the resource directory 300. The transmission may be performed at step S202.

Subsequently, the resource directory 300 is based on the information on the plurality of traffic load management devices obtained from the plurality of traffic load management devices including the first traffic load management device 210, respectively. It is possible to assign different server groups, and to maintain and manage server group information allocated for a plurality of traffic load management devices. Thereafter, each server may transmit a GET request message to the resource directory 300 (S203) and request information on the traffic load management apparatus allocated to the server. The resource directory 300 may respond to each GET request message obtained from each server (S204), and provide each server with information about a traffic load management apparatus allocated to the corresponding server.

A description of the resource entry registration operation is as follows. In the following description with reference to FIG. 3, as an example, it is assumed that the LB-RD is the first traffic load management apparatus 210, and the first server 111 (Server # 1) and the second server 112 (Server # 2). ),… In this case, the n-th server 11n and Server #n are assumed to be a plurality of servers included in the first server group 110.

Referring to FIG. 3, in the case of a resource entry registration operation, each server 111, 112,..., 11n includes a predetermined (allocated) traffic load including a resource entry for a resource after a resource search operation of a CoAP is performed. The registration message may be transmitted to the management device 210 using the POST method (S301). The traffic load management apparatus 200 may perform a message aggregation process of generating an integrated message (S302). That is, the traffic load management apparatus 200 may sequentially integrate the k registration messages by counting the number of registration messages received from the plurality of servers to generate the integrated message. Here, the value of k may satisfy the above Equation 1, and the description thereof has been described in detail above, and thus redundant description will be omitted. In this case, each of the plurality of traffic load management apparatuses including the first traffic load management apparatus 210 may transmit the generated integrated data to the resource directory 300 immediately after generation of the integrated data in order to prevent additional delay.

Subsequently, when the resource directory 300 receives the integration message, the resource directory 300 may register a resource entry of the server that transmitted the registration message related to the integration message (S303). The resource directory 300 may transmit a response message for the normal registration of the resource entry to the traffic load management apparatus 210 that transmits the integrated message when the registration of the resource entry is successful (success) (S304). Thereafter, the traffic load management apparatus 200 transmits the response message for the normal registration received from the resource directory 300 to each server 111, 112,..., 11n that has transmitted the registration message in association with the normal registration (S305). , Forwarding, multicast).

According to the registration operation of FIG. 3, in the conventional CoAP resource search, the server directly registers the resource entry in the resource directory, whereas in the present application, the resource entry of the server is registered in the resource directory 300 through the traffic load management apparatus 200. You can register.

After the registration operation is performed, each server 111, 112,..., 11n may update the resource entry registered in the resource directory 300 at a predetermined cycle. This can be more readily understood with reference to FIG. 4.

Referring to FIG. 4, FIG. 4 shows a schematic flow of an update operation of the traffic load management apparatus 210 such that the resource directory 300 maintains the most recent resource entry for each server.

In the update operation illustrated in FIG. 4, in the above-described registration operation flow, a registration message is applied as an update message, and accordingly, all processes except for updating a resource entry previously registered in the resource directory 300 are performed. Since the process is the same as in the, the update operation can be understood as the same or similar to the registration operation, a detailed description thereof will be omitted below.

The system 1 including a traffic load management apparatus integrates a plurality of registration messages and update messages as one unified message, thereby causing the resource directory to reduce the number of registration messages or update messages received, thereby reducing the resource directory 300. This can solve the imbalance of traffic load caused by the large number of messages that are concentrated in the network. The load balancing effect of the traffic load management device (ie, LB-RD architecture) in the present system 1 may be more effective in a large IoT local network including a large number of servers.

Hereinafter, a simulation result performed to confirm the effectiveness (efficiency) of the traffic load management apparatus (hereinafter referred to as LB-RD architecture) proposed herein will be described. For example, in an experiment according to an exemplary embodiment of the present application, an experimental simulation was performed using MATLAB. Hereinafter, the simulation results of the LB-RD architecture will be compared with the simulation results of the conventional (prior) resource directory (RD) method. do.

More specifically, the experiment according to an embodiment of the present application will determine the performance of the LB-RD architecture in terms of the number of messages lost and message loss rate through simulation. The number of lost messages and the message loss rate are evaluated to increase the number of servers and bandwidth, and the result is that the number of lost messages and the message loss rate of the LB-RD architecture are 12% and 11% lower than those of the existing RD approach, respectively. can confirm. The description thereof may be more easily understood with reference to FIGS. 5 to 9.

5 is a diagram illustrating an example of a parameter applied to a simulation according to an exemplary embodiment of the present application.

Referring to FIG. 5, in the simulation according to an exemplary embodiment of the present application, the number of servers is set to 100 to 1,000, and the number of LB-RDs of traffic load management apparatus is set to 10. Can be. In addition, the number of update messages for aggregation for message aggregation may be set to 5, so that five update messages are converted into aggregation messages (single aggregation messages) by the traffic load management device. Can be integrated. In addition, the header size may be set to 10 bytes, and the payload size may be set to 200 bytes. In addition, the bandwidth between the server and the resource directory 300 may be set to vary from 1 to 1.45 Mbps.

6 is a view showing a change in the number of lost messages according to the change in the number of servers in the experiment according to an embodiment of the present application.

Referring to FIG. 6, when the bandwidth between the server and the RD is set to 1 Mbps, the LB-RD architecture proposed in the present application is a conventional RD approach when the number of servers exceeds 500 (conventionally, Existing RD). You can see that fewer messages are lost. In particular, when the number of servers is 600, it can be seen that only the existing RD method loses the update message. This is because the LB-RD proposed herein reduces the overhead caused by the update message header through the aggregation of messages. That is, the LB-RD proposed herein can transmit more update messages through 1 Mbps bandwidth than the conventional RD approach. On the other hand, both the LB-RD scheme and the existing RD approach proposed herein can confirm that no loss of update messages occurs until the number of servers is less than 500. This is because it is enough to accommodate.

7 is a diagram illustrating a message loss rate according to the change of the number of servers in an experiment according to an embodiment of the present application.

Referring to FIG. 7, when the bandwidth between the server and the RD is set to 1 Mbps, the LB-RD proposed herein combines a plurality of update messages into one integrated message (ie, a single aggregate message). It can be seen that the message loss rate of the LB-RD is lower than that of the conventional RD approach. Specifically, according to an experiment of the present application, the average message loss rate of the conventional RD approach and the LB-RD architecture proposed by the present invention is 12% and 10%, respectively. The message loss rate can be lowered.

8 is a diagram showing the number of messages lost when the bandwidth is changed from 1 Mbps to 1.45 Mbps in the experiment according to an embodiment of the present application, Figure 9 is a bandwidth from 1 Mbps to 1.45 Mbps in an experiment according to an embodiment of the present application Is a diagram illustrating a message loss rate when changed to. 8 and 9 illustrate a case where the number of servers is set to 1,000.

Referring to FIG. 8, it can be seen that both the LB-RD scheme and the existing RD approach proposed in the present application decrease the number of lost messages as the bandwidth increases. This is because both LB-RD and conventional RD approaches can transmit a larger number of update messages as the bandwidth increases. On the other hand, the overall LB-RD architecture proposed in the present application can confirm that the number of messages lost less than the existing RD scheme by the generation of the integrated message through the message aggregation. In particular, the proposed LB-RD architecture shows that the number of lost messages is 11% less than the conventional RD scheme.

Referring to FIG. 9, it can be seen that the message loss rate of the LB-RD architecture proposed in the present application is lower than the message loss rate of the conventional RD scheme regardless of the bandwidth, and for the same reason as described above with reference to FIG. 8. It can be said. The message loss rate of the LB-RD architecture proposed here is 24%, 11% lower than the conventional RD method.

According to one experiment of the present application, it can be seen that the LB-RD architecture proposed in the present invention is superior to the conventional RD scheme in terms of the number of lost messages and the message loss rate.

We propose a CoAP-based LB-RD architecture (traffic load management device) that addresses the scalability problem of a centralized resource discovery approach in large IoT local networks, balancing traffic loads due to the large number of messages focused on RD. Can be adjusted.

Hereinafter, based on the details described above, the operation flow of the present application will be briefly described.

FIG. 10 is a flowchart illustrating a CoAP-based traffic load management method in an IoT local network according to an embodiment of the present application.

The traffic load management method illustrated in FIG. 10 may be performed by the traffic load management apparatus 200 described above. Therefore, even if omitted below, the description of the traffic load management apparatus 200 may be equally applicable to the description of the traffic load management method.

Referring to FIG. 10, the traffic load management method according to an exemplary embodiment of the present disclosure integrates registration messages and / or update messages received from a plurality of servers included in a server group in a traffic load management device to aggregate a message (aggregate message). It may be generated (S10).

Here, when there are a plurality of server groups, the traffic load management apparatus may be provided in plurality in correspondence with each of the plurality of server groups.

In this case, in step S10, an integration message may be generated by sequentially counting and integrating registration messages and / or update messages received from a plurality of servers.

Next, in the traffic load management method according to an embodiment of the present application, the traffic load management apparatus may transmit an integrated message to a resource directory (S20).

In this case, the resource entry of the server that transmits the plurality of messages related to the integrated message may be registered and / or updated in the resource directory by the integrated message transmitted to the resource directory.

In addition, in step S20 it is possible to determine the transmission time for the integration message is transmitted to the resource directory. In this case, in step S20, the transmission time may be determined in consideration of the maximum payload size of the message format of CoAP.

In addition, in step S20, the transmission time may be determined at a time point where the payload sizes of the plurality of messages included in the unified message do not exceed the maximum payload size of the message format of CoAP. The maximum number of registration messages and / or update messages to be merged can be determined.

In addition, although not shown in the drawings, the traffic load management method according to an embodiment of the present application, in the traffic load management device, in response to the integrated message transmitted to the resource directory in response to the normal registration and / or normal update from the resource directory If received, may include transmitting a response message to the server that transmitted the plurality of messages related to the integrated message.

Here, in the transmitting of the response message, the response message may be transmitted based on a Uniform Resource Identifier (URI) list for the server group generated by receiving the registration message.

In addition, although not shown in the drawings, the traffic load management method according to an embodiment of the present application, before the step S10, in the traffic load management apparatus, in response to the GET request message received from the resource directory for resource search of the CoAP, traffic load And transmitting information (ie, address, port) about the management device to the resource directory. Further, in the traffic load management apparatus, a plurality of servers included in the server group corresponding to the server group information based on the server group information assigned to the traffic load management apparatus by the resource directory based on the information about the traffic load management apparatus. Receiving a registration message and / or an update message from a server.

In the above description, steps S10 to S20 may be further divided into additional steps or combined into fewer steps, according to an embodiment of the present disclosure. In addition, some steps may be omitted as necessary, and the order between the steps may be changed.

CoAP-based traffic load management method in the IoT local network according to an embodiment of the present application may be implemented in the form of program instructions that can be executed by various computer means may be recorded in a computer readable medium. The computer readable medium may include program instructions, data files, data structures, and the like singly and / or in combination. Program instructions recorded on the media may be those specially designed and constructed for the purposes of the present invention, or they may be of the kind well-known and available to those having skill in the computer software arts. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tape, optical media such as CD-ROMs, DVDs, and magnetic disks, such as floppy disks. Magneto-optical media, and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like. The hardware device described above may be configured to operate as one or more software modules to perform the operations of the present invention, and vice versa.

The foregoing description of the application is intended for illustration, and it will be understood by those skilled in the art that the present invention may be easily modified in other specific forms without changing the technical spirit or essential features of the present application. Therefore, it should be understood that the embodiments described above are exemplary in all respects and not restrictive. For example, each component described as a single type may be implemented in a distributed manner, and similarly, components described as distributed may be implemented in a combined form.

The scope of the present application is shown by the following claims rather than the above description, and all changes and / or modifications derived from the meaning and scope of the claims and their equivalents should be construed as being included in the scope of the present application. do.

1: traffic load management system
100: server group
200: traffic load management device
211: server group management
212: message aggregation unit
213: transmission unit
300: resource directory

Claims (9)

In the traffic load management method based on Constrained Application Protocol (CoAP) in the Internet of Things (IoT) local network,
In a traffic load management device that acts as an intermediate agent between a server and a resource directory, a plurality of servers included in a server group send to the resource directory to register and / or update the server's own resource entries in the resource directory. Aggregating the registration message and / or update message sequentially to generate an integrated message integrated as a single aggregate message; And
Transmitting, at the traffic load management apparatus, the integration message generated in the generating step to a resource directory at the time when the integration message is generated;
Including,
A resource entry of a server that has transmitted a plurality of messages related to the integration message is registered and / or updated in the resource directory by the integration message sent to the resource directory,
When the integration message is transmitted to the resource directory in the transmitting step, the payload size of a plurality of messages sequentially aggregated for generation of the integration message is smaller than the maximum payload size of the message format of the CoAP. A plurality of messages up to the same point in time are generated into the unified message,
Determining the maximum number of registration messages and / or update messages to be integrated as the integration message by determining when the integration message is sent to the resource directory,
The maximum number of registration messages and / or update messages integrated as the integrated message satisfies Equation 1 below.
[Equation 1]

Where k is the maximum number of registration and / or update messages that can be merged as one unified message, L _Reg is the payload size of the registration message sent from the server, L _CoAP is the maximum payload size of the message format of CoAP,
The transmitting may include: integrating the k registration messages and / or update messages so that the number of registration messages and / or update messages that the resource directory receives from the server is merged to generate the integration message. To the resource directory,
The resource entry of the server is registered in the resource directory by the traffic load management device through the traffic load management device located between the server and the resource directory, not directly in the server to the resource directory. , Traffic load management method. delete delete delete The method of claim 1,
Before the generating step,
In the traffic load management apparatus, transmitting information about the traffic load management apparatus to the resource directory in response to a GET request message received from the resource directory for resource searching of the CoAP; And
In the traffic load management apparatus, based on the server group information assigned to the traffic load management apparatus by the resource directory based on the information about the traffic load management apparatus, included in the server group corresponding to the server group information Receiving a registration message and / or an update message from a plurality of configured servers,
Traffic load management method further comprising. In the traffic load management apparatus based on Constrained Application Protocol (CoAP) in the Internet of Things (IoT) local network,
Aggregate a plurality of registration messages and / or update messages that are sent to the resource directory by a plurality of servers included in the server group to register and / or update the server's own resource entries in the resource directory and consolidate them as a single aggregate message. A message aggregation unit generating an integrated message; And
A transmission unit for transmitting the integration message generated by the message aggregation unit to a resource directory when the integration message is generated;
Including,
The traffic load management device is a device that serves as an intermediate agent between the server and the resource directory,
A resource entry of a server that has transmitted a plurality of messages related to the integration message is registered and / or updated in the resource directory by the integration message sent to the resource directory,
The point in time at which the integration message is transmitted to the resource directory by the transmitter, is that the payload size of a plurality of messages sequentially aggregated for generation of the integration message is less than or equal to the maximum payload size of the message format of the CoAP. A plurality of messages up to a time of losing are generated into the unified message,
Determining the maximum number of registration messages and / or update messages to be integrated as the integration message by determining when the integration message is sent to the resource directory,
The maximum number of registration messages and / or update messages integrated as the integrated message satisfies Equation 2 below.
[Equation 2]

Where k is the maximum number of registration and / or update messages that can be merged as one unified message, L _Reg is the payload size of the registration message sent from the server, L _CoAP is the maximum payload size of the message format of CoAP,
The transmitting unit, when the resource directory is received by the k registration messages and / or update messages are merged to reduce the number of registration messages and / or update messages from the server, the integrated message is the resource directory to the integrated message is generated; To,
The resource entry of the server is registered in the resource directory by the traffic load management device through the traffic load management device located between the server and the resource directory, not directly in the server to the resource directory. , Traffic load management device. In traffic load management system based on Constrained Application Protocol (CoAP) in the Internet of Things (IoT) local network,
A server group including a plurality of servers for transmitting the resource entry to the traffic load management apparatus through a registration message and / or an update message;
Aggregate a plurality of registration messages and / or update messages that are sent by the plurality of servers included in the server group to the resource directory to register and / or update the server's own resource entries in the resource directory and consolidate them as a single aggregate message. The traffic load management device configured to generate an integrated message, and act as an intermediate agent between a server and a resource directory for transmitting the generated integrated message to a resource directory at the time when the integrated message is generated; And
The resource directory for registering and / or updating a resource entry of a server that has transmitted a plurality of messages related to the integrated message, based on the integrated message received from the traffic load management apparatus;
Including,
When the aggregation message is transmitted to the resource directory in the traffic load management apparatus, the payload size of a plurality of messages sequentially aggregated for generation of the aggregation message is smaller than the maximum payload size of the message format of the CoAP. A plurality of messages up to or equal to the point in time are generated into the unified message,
Determining the maximum number of registration messages and / or update messages to be integrated as the integration message by determining when the integration message is sent to the resource directory,
The maximum number of registration messages and / or update messages integrated as the integrated message satisfies Equation 3 below.
[Equation 3]

Where k is the maximum number of registration and / or update messages that can be merged as one unified message, L _Reg is the payload size of the registration message sent from the server, L _CoAP is the maximum payload size of the message format of CoAP,
The traffic load management apparatus may integrate the registration message at the time when the integration message is generated by integrating k registration messages and / or update messages so that the number of registration messages and / or update messages that the resource directory receives from the server is reduced. Send to the resource directory,
The resource entry of the server is registered in the resource directory by the traffic load management device through the traffic load management device located between the server and the resource directory, not directly in the server to the resource directory. Traffic load management system. The method of claim 7, wherein
The traffic load management device,
When there are a plurality of server groups, a plurality are provided corresponding to each of the plurality of server groups, traffic load management system. A computer-readable recording medium having recorded thereon a program for executing the method of claim 1 or 5 on a computer.

Images