Abstract
As a lot of sensors are connected to the Internet, many works have been made to support group communication for constrained application protocol. The existing multicast-based group communication may be efficient, but not reliable in wireless sensor networks. The existing unicast-based group communication is reliable, but it tends to give low performance. Recently, an observe-based group communication scheme was proposed, which uses the constrained application protocol–observe option. This is very effective, but tends to generate too many notification messages in the network. In this article, we thus propose an enhanced scheme of the observe-based group communication. In the proposed scheme, a broker is employed to monitor the status information of resources for a group of sensors. Each sensor will update its resource status to the broker using the constrained application protocol–observe option, and the broker sends the aggregate updated information to the constrained application protocol client, as done in the existing observe-based scheme. To reduce the number of notifications between the broker and the client, in the proposed scheme, the broker sends an aggregated notification to the client only when the client requests the information on resource status. In addition, the proposed scheme uses a hash function and the max-age timer of constrained application protocol in order to reduce unnecessary notification messages from the sensors to the broker. For performance analysis, we compare the existing and proposed schemes in terms of total delay and the amount of generated packets. From the results, we can see that the existing and proposed observe-based schemes improve total delay by almost 60%–80%, compared to the existing multicast-based and unicast-based schemes. In terms of the number of generated packets, the proposed scheme improves the existing observed-based scheme by almost 30%. We also performed the testbed experimentation of the proposed scheme for validation in the real-world network.
Keywords
Introduction
With the popularity of Internet-of-things (IoT) services, the constrained application protocol (CoAP) was developed to support the IoT sensor devices.1–6 The basic communication model for CoAP is based on the client–server model in which a client exchanges messages with a server. However, one-to-many group communication is required for CoAP. 7
The Internet Engineering Task Force (IETF) has so far designed the group communication for CoAP using IP multicast.8,9 However, the multicast-based group communication may not be reliable in wireless sensor networks, such as low-power and lossy networks (LLNs). Thus, it is difficult for a client to receive response messages from the sensors properly, since the connectivity between client and sensors may not be stable. To overcome this problem, the unicast-based group communication schemes were proposed.10,11 However, such unicast-based schemes also tend to give low performance. Recently, an observe-based group communication scheme 12 was proposed, in which an entity manager (EM) is employed between an observing client and many sensors so as to monitor the status information of resources for many sensors. Each sensor will update its resource status to the broker using the CoAP observe option.13–16 However, the existing observe-based scheme tends to generate a lot of unnecessary notifications even when the sensor value has not been changed.
To overcome this drawback of the existing observe-based group communication, in this article, we propose an enhanced observe-based group communication scheme. The proposed scheme uses a hash function and the max-age timer of CoAP in order to reduce unnecessary notification messages. To do this, the group of sensors is divided into K subgroups using a modulo hash function. When the max-age timer expires without change of sensor value, the sensors in the corresponding subgroup will send the notifications to the broker.
This article is organized as follows. In section “Existing group communication schemes,” we briefly review the existing CoAP group communication schemes. In section “Enhanced observe-based communication,” we propose the enhanced observe-based group communication scheme. In section “Performance analysis and experimentation,” we discuss the performance analysis of the existing and proposed schemes and describe testbed experimentation of the proposed scheme. Finally, section “Conclusion” concludes this article.
Existing group communication schemes
Multicast-based group communication
The multicast-based CoAP group communication was designed by the IETF. 17 In IoT networks, the number of sensor devices can get large, and these devices are closely related in distance or function. In this respect, the use of group communication can improve the communication delays and reduce the network bandwidth in wireless sensor networks.
In the multicast-based scheme, a source node (CoAP client or controller) sends message, and each sensor sends a response to the client by unicast.
Figure 1 shows the CoAP multicast-based group communication model. In this figure, a CoAP client in the network sends a request message to the group nodes using non-confirmable message type. The target sensor nodes will respond with a response message to the CoAP client.
Multicast-based group communication.
In the multicast-based group communication, to avoid the congestion of the response messages from many sensor nodes, an appropriate back-off mechanism is employed, 8 in which each sensor will wait for a random amount of time, called lb_leisure, before sending a response to the client.
Unicast-based group communication
The multicast-based group communication can reduce the waste of network resources. However, it may not work if any router in the network cannot support the multicast routing. In reality, it is hard to expect that all routers are multicast-enabled in the networks. Moreover, multicast communication may not be reliable in wireless networks.
To overcome the drawbacks of the multicast-based scheme, the unicast-based scheme was proposed. 10 In this scheme, a group of sensors (or resources) is defined as “entity,” and EM is employed to manage the entity group. EM can be located at the border gateway of the wireless sensor network.
Figure 2 shows the unicast-based group communication model with two sensors. In the creation phase, the CoAP client requests the creation of a new entity that contains two resources.10,18 In the figure, EM creates a new entity, which is assigned to URI “1.” In the usage phase, the CoAP client sends a GET message to EM and then EM sends GET request messages to the two sensors. After collecting the response messages from the two sensors, EM sends the aggregated response messages to the CoAP client.
Unicast-based group communication.
In the unicast-based group communication, to avoid network congestion, an appropriate back-off mechanism is employed, 11 in which EM inserts a random amount of time, called Dlowerbound, before sending a request message to the group members.
Both multicast-based and unicast-based group communication schemes have their own pros and cons. The multicast-based group communication scheme is generally fast and gives little overhead. However, it is not flexible and reliable. However, the unicast-based approach is reliable and flexible, but it is generally slower and gives bigger overhead. For further enhancement of unicast-based scheme, a hybrid scheme was proposed, 11 in which the unicast transmission is used between client and EM, and the multicast or unicast transmission is employed between EM and sensors.
Observe-based group communication
A recent work by Ishaq et al. 12 proposes an observe-based CoAP group communication, in which the CoAP observe option is used for group communication.
This scheme follows a typical pub/sub model.19,20 Therefore, the observing client can get the up-to-date sensor values, as soon as each sensor value is changed. To do this, each sensor should continue to send notifications to broker and further client. When each sensor value changes, EM sends a notification to the client. If there is no change of sensor value, each sensor generates a notification message for data consistency between sensor and client, when the max-age timer expires. Therefore, the observe-based group communication scheme tends to generate a lot of notifications excessively. Such problem becomes more severe when the number of sensors increases in the network. The authors tried to solve this problem by dividing the types of clients. However, this method is not a complete solution.
Figure 3 shows the operations of the existing observe-based scheme to observe group resources. In this figure, the two sensors are observed by the client through EM. In the creation phase, the observing client requests the creation of a new entity for group observing. EM creates a new entity, which is assigned to URI “1.” In the usage phase, the client will request the group resource to EM and then EM sends a GET message with the observe option (set obs = 0) to the two sensors. EM acts as a notification forwarder that transfers the up-to-date values of the two sensors to the client. Whenever the sensor sends an up-to-date value, EM forwards a notification to the client. EM may support different clients with different types of Internet connection. Thus, EM notifies the observed values immediately or after a certain amount of time.
Observe-based group communication.
Enhanced observe-based communication
Operations
The existing observe-based group communication for CoAP 12 has the benefit to reduce network traffic and to improve its responsiveness. However, this scheme tends to generate too many notifications. That is, the broker generates notifications each time the sensor status value is changed. In addition, each sensor will generate periodic notifications when the max-age timer expires, even though a sensor value has not been changed. It may induce too may notification messages in the sensor network. To reduce notifications from sensors to the broker, we use a novel algorithm for generation of notifications using a hash function and the max-age timer.
Figure 4 shows the operations of the proposed observe-based group communication. In the figure, the broker is used to manage the resources of the sensor group, to merge the updated resources, and to send the response messages to the client.
Operations of the proposed scheme.
At the creation phase, the client will first request the creation of group resources to the broker using the POST message. Then, the broker will respond to the client with the ACK message so as to inform that resource has been created.
In the usage phase, when the client initially requests a group of resource, the broker will request the resource information to each sensor by sending a GET message with the CoAP observe option. Note that this GET message contains the parameter information on the hash function and the max-age timer that will be used for generation of notification messages. The details of algorithm for notification generation are described in the subsequent section. During communication, the broker will receive the responses from each group member. The aggregated resource information will be delivered by the broker to the client. Each sensor will continue to send the updated resource information to the broker, if the sensor value is changed. When the client requests the resource information again, the broker sends the aggregated resource information to the client.
In the deployment perspective of the proposed scheme, the broker needs to be implemented on the border gateway of wireless sensor network.
Generation of notifications
In the existing observe-based group communication, the notifications are periodically generated if the sensor value has not been changed and the max-age timer expires. This tends to induce too many notification messages in the network. To deal with this issue, the proposed scheme uses a hash-based notification generation algorithm. Using a hash function, all sensors are divided into several subgroups, and only one subgroup will generate notifications when the max-age timer expires.
More specifically, to generate a notification message, each sensor uses the sequence number S, a hash value K, variable N, and the modulo (%) operator. It is noted that the sequence number S represents the sequence number of the CoAP message with the CoAP observe option that a sensor will send to the broker. The hash value K implies the number of subgroups, and it will be determined by the broker. The broker will announce this hash value information to the sensors using the first GET message. The variable N is an integer generated by sensor, and each sensor will initially set N to zero. N is incremented by one whenever the max-age timer expires. Once the sensor sends a notification message, the variable N will be initialized to 0.
Figure 5 depicts the algorithm of notification generation used in the proposed scheme. Given the parameters (S, K, and N), if the sensor value is changed before the max-age timer expires, the sensor will send a notification. If the max-age timer expires without the change of sensor value, the sensor will check if S%K = N or not. If yes, the sensor sends a notification to the broker. Otherwise, N = N + 1 and the sensor will wait until the following max-age timer expires or the sensor value is changed.
Generation of notifications by each sensor.
For example, let us consider the case of K = 2. Then, a sensor will generate at least one notification during two max-age intervals. Roughly, the group is divided into the two subgroups, and a half of all sensors will generate the notifications during the max-age time. This approach will be helpful to reduce the amount of notification messages, while maintaining the synchronization between sensors and the broker.
Performance analysis and experimentation
Network model
For performance analysis, we compared the total delays and the number of packets generated in the network for the candidate schemes. In the analysis, we assume that wireless links are used between broker and sensors, whereas wired links are used between broker and the CoAP client.
Table 1 presents the parameter used in the analysis. In the table, we denote Tx-y(S, Hx-y) by the transmission delay of a message with size S sent from x to y via the wired/wireless links, where Hx-y represents the number of hops between node x and node y. Tx-y(S, Hx-y) is expressed as Tx-y(S, Hx-y) = Hx-y* (S/Bw (or S/Bwl) + Lw (or Lwl)). LEISURE_TIME for congestion control was calculated based on Rahman and Dijk 8 and Ishaq et al. 11
Parameters used in analysis.
For numerical analysis, we set the parameter values, as shown in Table 2, by referring to Choi and Koh. 21 The group size is configured by considering the smart building or smart city environment.
Parameter values used in analysis.
Delay analysis
In the delay analysis, the three candidate schemes are compared: multicast-based, unicast-based, and observe-based group communications. Note that the existing observe-based scheme provides the same delay with the proposed observe-based scheme.
For each scheme, the total delay is calculated by the time that the client sends a request to a group via broker and the time that the client receives the responses from the sensors via broker. In the delay analysis, we will not consider the resource (or group) creation phase, since the multicast-based scheme does not define the creation operation explicitly. A packet loss is not considered.
In the multicast-based group communication, the client sends a request to the group members. This operation takes TClnt-AR(Sc) + TAR-AR(HAR-AR, Sc) + TAR-SENSOR(Sc). Each group member will respond to the client, which takes TMAX(LEISURE_TIME)+TSENSOR-AR(Sd)+TAR-AR (HAR-AR, Sd)+TAR-Clnt(Sd). Therefore, total delay of multicast-based scheme is calculated as follows
In the unicast-based group communication, the request operation requires TClnt-AR(Sc) + TAR-EM (HAR-EM,Sc)+P+TMAX(LEISURE_TIME) + TAR-SENSOR (Sc). The response operation takes the same time with that of the multicast-based group communication. Therefore, we can obtain the total delay of unicast-based group communication as follows
In the observe-based group communication, the request phase takes only TClnt-AR(Sc) + TAR-Broker(HAR-Broker, Sc). The response phase requires only TBrokerAR(HBroker-AR, Sd) + TAR-Clnt(Sd) + P. In the proposed scheme, it is important to consider the resource update operation between broker and the group members. The resource update phase requires TSENSOR-Broker(Sd). Therefore, we can calculate the total delay of the observe-based schemes as follows
Based on the analysis, we now compare the total delays using the MATLAB tool. 22
Figure 6 shows the total delay required for each candidate scheme by different group sizes (the number of sensors).
Impact of group size on total delay.
From the figure, we can see that the multicast-based scheme gives better performance than the unicast-based scheme. This is because the multiple unicast transmissions require more bandwidth and large delay than the multicast-based scheme. In addition, we can also see that the observe-based scheme provides the best performance, since in the observe-based scheme the broker can respond with the response message directly to the client without further requesting to the group members. Also, the observe-based scheme does not use LEISURE_TIME, which is proportional to the number of sensors.
Figure 7 shows the impact of wired bandwidth on total delay. It is shown that the observe-based scheme gives the best performance among the candidate schemes. This is because the observe-based scheme can reduce the number of messages on the wired bandwidth between client and broker, compared with the other candidate schemes.
Impact of Bw on total delay.
Figure 8 shows the impact of wireless bandwidth on total delay. From the figure, we can see that the unicast-based scheme takes large delay than multicast-based scheme. This is because the unicast-based scheme requires more bandwidth than multicast-based scheme in wireless links. We can also see that the observe-based scheme has the best performance.
Impact of Bwl on delay.
Figure 9 shows the impact of wired link delay on total delay. From the figure, total delays increase as the wireless link delay gets larger for all of the candidate schemes. We can also see that the observe-based scheme shows the best performance. This is because in the observe-based scheme the broker does not need to send further requests to the group members, since the updated resource information has already obtained using the CoAP observe option. Accordingly, total delays can be reduced in the observe-based scheme.
Impact of Lw on total delay.
Figure 10 shows the impact of wireless link delay on total delay. From the figure, we can see that the observe-based scheme provides the best performance. This is because the observe-based scheme gives little impact on the wireless link delay, since there is no request phase to the group members in wireless network.
Impact of Lwl delay on delay.
Packet overhead analysis
In the analysis of packet overhead, the following four candidate schemes are compared: multicast-based, unicast-based, existing observe-based, and proposed observe-based group communications.
For analysis, we calculate the number of packets generated between the request of the client and the response of the sensors. To calculate the number of packets generated, we use the total delay that was obtained from section “Delay analysis.” Based on the total delay and the probability of sensor value change (PS), we calculate the number of packets generated in the network using MATLAB tool. 22
Figure 11 shows the impact of group size on packet overhead. In this figure, the multicast-based and unicast-based schemes generate larger number of packets than the existing and proposed observe-based schemes, since the observe-based schemes generate the packets only when the sensor value changes. We can also see that the proposed scheme has the smallest the number of packets, since it responds with notifications only once.
Impact of group size on packet overhead.
Figures 12 and 13 show the impact of network bandwidth on packet overhead. In this figure, we can see that the two observe-based schemes generate more packets than the multicast and unicast schemes, since the observe-based schemes do not generate request messages. We can also see that the proposed observe-based scheme provides the smallest number of packets, because the proposed scheme generates a notification only once from the broker to the client. The performance of the proposed scheme is not affected in the wired network, since the proposed scheme generates the request/response messages only once.
Impact of Bw on packet overhead.
Impact of Bwl on packet overhead.
Figure 14 shows the impact of the probability (PS) on packet overhead. As shown in the figure, the multicast-based and the unicast-based schemes are not affected by probability PS. In this figure, we can see that the proposed scheme provides the best performance than the other candidate schemes. This is because that the proposed scheme does not generate additional notifications from the broker to the client. Also, we can see that the proposed scheme gives better efficiency when the sensor value has changed more frequently.
Impact of PS on packet overhead.
Figure 15 shows the impact of probability (PS) on the number of notifications when the max-age timer expires. In this analysis, the multicast-based and unicast-based schemes are not considered, since these schemes do not generate notifications. In this figure, we can see that the proposed scheme generates fewer notifications than the existing observe-based scheme.
Impact of PS on notification overhead.
Figure 16 shows the impact of hash value (K) on the number of notifications when the max-age timer expires. In this figure, we can see that the existing observe-based scheme generates more notifications than the proposed scheme in all cases. In addition, we see that the hash-based notification algorithm is not affected by the number of notifications, when K is greater than 5.
Impact of K on notification overhead.
Testbed experimentation
For validation of the proposed scheme in real-world network, we have implemented the proposed scheme and performed testbed experimentations.
Figure 17 shows a simple network topology used in experimentation in which two sensors, a broker and a CoAP client are employed. In this figure, the broker receives the up-to-date sensor values from two sensors using the CoAP observe option. The client sends a request message to the broker and receives an up-to-date value in the response message.
Topology for testbed experimentation.
For implementation, we use the CoAP californium open source over Windows 10 platform and Ubuntu 16.04 platform using VMware.
Figure 18 shows the packet capturing results using the Wireshark 23 for the CoAP observe message from broker to sensor. In this figure, we can see that the broker (192.168.10.1) sends two CoAP GET messages to sensor_1 and sensor_2 in response to the predefined URI “/simple.” Sensor_1 and Sensor_2 have the IP addresses of 192.168.10.116 and 192.168.10.2, respectively. Sensor_1 and Sensor_2 send the ACK messages to the broker after the observe registration is complete.
CoAP message from broker to sensor.
Figure 19 shows the packet capturing results for the CoAP observing message from sensor to the broker. In this figure, the broker receives a CoAP observing message from Sensor_1. The observing message can use the confirmable (CON) or non-confirmable (NON) method. In this figure, we can see that the broker responds to the sensor with an empty message because it sends an observe message using the CON method.
CoAP message from sensor to broker.
Conclusion
In this article, we proposed an enhanced observe-based group communication for CoAP. The multicast-based group communication may not be reliable in wireless sensor networks. The unicast-based group communication tends to induce large delay and bandwidth in wireless sensor networks. The existing observe-based group communication is suitable for monitoring systems, but it tends to generate a lot of notifications. The proposed scheme can be used to reduce the number of packets generated between client and broker using the request-response messages. The proposed scheme can also reduce the number of notifications between broker and sensors using a hash function and the max-age timer.
In order to verify the performance of the proposed scheme, we compare the total delays and the number of packets for the candidate schemes. From the numerical analysis, we can see that the proposed observe-based group communication scheme can give better performance than the existing schemes in terms of total delay and the number of packets.
The proposed CoAP group communication scheme can be used for IoT services with numerous sensors, such as smart cities or healthcare services. To do this, more works24–26 need to be considered to provide the interoperability between the gateway and a variety of sensor devices.
For future works, we plan to implement a broker over smartphone or IoT platform and to validate the proposed group communication scheme by experimentations. In particular, we need to consider how to use the CoAP option to support the hash function. In addition, to prevent traffic overhead in group communication, more enhanced algorithm needs to be investigated to control the number of notifications generated. 27
Footnotes
Handling Editor: Giancarlo Fortino
Declaration of conflicting interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This research was supported by the BK21 Plus project funded by the Ministry of Education, School of Computer Science and Engineering, Kyungpook National University, Korea (21A20131600005); by the Ministry of Science and ICT under the National Program for Excellence in SW (2015-0-00912) supervised by the IITP; and by the Basic Science Research Korea funded by the Ministry of Education (NRF-2017R1D1A3B03032156).
