Enhanced group communication in constrained application protocol–based Internet-of-things networks

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.

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. ⁷

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 ¹² 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. ¹⁷ 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.

Figure 1.

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, ⁸ 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. ¹⁰ 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.

Figure 2.

Unicast-based group communication.

In the unicast-based group communication, to avoid network congestion, an appropriate back-off mechanism is employed, ¹¹ in which EM inserts a random amount of time, called D_lowerbound, 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, ¹¹ 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. ¹² 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.

Figure 3.

Observe-based group communication.

Enhanced observe-based communication

Operations

The existing observe-based group communication for CoAP ¹² 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.

Figure 4.

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.

Figure 5.

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 T_x-y(S, H_x-y) by the transmission delay of a message with size S sent from x to y via the wired/wireless links, where H_x-y represents the number of hops between node x and node y. T_x-y(S, H_x-y) is expressed as T_x-y(S, H_x-y) = H_x-y* (S/B_w (or S/B_wl) + L_w (or L_wl)). LEISURE_TIME for congestion control was calculated based on Rahman and Dijk ⁸ and Ishaq et al. ¹¹

Table 1.

Parameters used in analysis.

Parameter	Description
Sc	Size of control packets (bytes)
Sd	Size of data packets (bytes)
Lw	Wired link delay (s)
Lwl	Wireless link delay (s)
Bw	Wired link bandwidth
Bwl	Wireless link bandwidth
Hx-y	Hop count between node x and y
G	Number of sensors in a group
P	The delay of CPU processing
PS	Prob. of sensor value change (%)
K	The hash value employed

For numerical analysis, we set the parameter values, as shown in Table 2, by referring to Choi and Koh. ²¹ The group size is configured by considering the smart building or smart city environment.

Table 2.

Parameter values used in analysis.

Parameter	Minimum	Default	Maximum
Lw (s)	0.0001	0.002	0.0055
Lwl (s)	0.001	0.01	0.055
Bw (MBps)	1.25	12.5	15
Bwl	137.5KBps	1.375MBps	1.75MBps
G	100	300	1000
Sc		80 bytes
Sd		120 bytes
Hx-y		3
P		0.00005 s
PS (%)	10	50	90
K	2	3	6

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 T_Clnt-AR(S_c) + T_AR-AR(H_AR-AR, S_c) + T_AR-SENSOR(S_c). Each group member will respond to the client, which takes T_{MAX(LEISURE_TIME)}+T_SENSOR-AR(S_d)+T_AR-AR (H_AR-AR, S_d)+T_AR-Clnt(S_d). Therefore, total delay of multicast-based scheme is calculated as follows

$$\begin{array}{c}\multicolumn{1}{c}{{\mathrm{T}}_{\mathrm{MULTI}}={\mathrm{T}}_{\mathrm{Clnt}-\mathrm{AR}}\left({\mathrm{S}}_{\mathrm{c}}\right)+{\mathrm{T}}_{\mathrm{AR}-\mathrm{AR}}({\mathrm{H}}_{\mathrm{AR}-\mathrm{AR}},{\mathrm{S}}_{\mathrm{c}})}\\ \multicolumn{1}{c}{+{\mathrm{T}}_{\mathrm{AR}-\mathrm{SENSOR}}\left({\mathrm{S}}_{\mathrm{c}}\right)+{\mathrm{T}}_{\mathrm{MAX}(\mathrm{LEISURE}-\mathrm{TIME})}}\\ \multicolumn{1}{c}{+{\mathrm{T}}_{\mathrm{SENSOR}-\mathrm{AR}}\left({\mathrm{S}}_{\mathrm{d}}\right)+{\mathrm{T}}_{\mathrm{AR}-\mathrm{AR}}({\mathrm{H}}_{\mathrm{AR}-\mathrm{AR}},{\mathrm{S}}_{\mathrm{d}})}\\ \multicolumn{1}{c}{+{\mathrm{T}}_{\mathrm{AR}-\mathrm{Clnt}}\left({\mathrm{S}}_{\mathrm{d}}\right)}\end{array}$$

In the unicast-based group communication, the request operation requires T_Clnt-AR(S_c) + T_AR-EM (H_AR-EM,S_c)+P+T_{MAX(LEISURE_TIME)} + T_AR-SENSOR (S_c). 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

$$\begin{array}{c}\multicolumn{1}{c}{{\mathrm{T}}_{\mathrm{UNI}}={\mathrm{T}}_{\mathrm{Clnt}-\mathrm{AR}}\left({\mathrm{S}}_{\mathrm{c}}\right)+{\mathrm{T}}_{\mathrm{AR}-\mathrm{AR}}({\mathrm{H}}_{\mathrm{AR}-\mathrm{AR}},{\mathrm{S}}_{\mathrm{c}})}\\ \multicolumn{1}{c}{+{\mathrm{T}}_{\mathrm{AR}-\mathrm{SENSOR}}\left({\mathrm{S}}_{\mathrm{c}}\right)+{\mathrm{T}}_{\mathrm{MAX}(\mathrm{LEISURE}\mathrm{\_}\mathrm{TIME})}}\\ \multicolumn{1}{c}{+{\mathrm{T}}_{\mathrm{SENSOR}-\mathrm{AR}}\left({\mathrm{S}}_{\mathrm{d}}\right)+{\mathrm{T}}_{\mathrm{AR}-\mathrm{AR}}({\mathrm{H}}_{\mathrm{AR}-\mathrm{AR}},{\mathrm{S}}_{\mathrm{d}})}\\ \multicolumn{1}{c}{+{\mathrm{T}}_{\mathrm{AR}-\mathrm{Clnt}}\left({\mathrm{S}}_{\mathrm{d}}\right)}\end{array}$$

In the observe-based group communication, the request phase takes only T_Clnt-AR(S_c) + T_AR-Broker(H_AR-Broker, S_c). The response phase requires only T_BrokerAR(H_Broker-AR, S_d) + T_AR-Clnt(S_d) + 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 T_{SENSOR-Broker}(S_d). Therefore, we can calculate the total delay of the observe-based schemes as follows

$$\begin{array}{c}\multicolumn{1}{c}{{\mathrm{T}}_{\mathrm{OBSERVE}}={\mathrm{T}}_{\mathrm{Clnt}-\mathrm{AR}}\left({\mathrm{S}}_{\mathrm{c}}\right)+{\mathrm{T}}_{\mathrm{AR}-\mathrm{Broker}}({\mathrm{H}}_{\mathrm{AR}-\mathrm{Broker}},{\mathrm{S}}_{\mathrm{c}})}\\ \multicolumn{1}{c}{+\mathrm{P}+{\mathrm{T}}_{\mathrm{SENSOR}-\mathrm{Broker}}\left({\mathrm{S}}_{\mathrm{d}}\right)}\\ \multicolumn{1}{c}{+{\mathrm{T}}_{\mathrm{Broker}-\mathrm{AR}}({\mathrm{H}}_{\mathrm{Broker}-\mathrm{AR}},{\mathrm{S}}_{\mathrm{d}})+{\mathrm{T}}_{\mathrm{AR}-\mathrm{Clnt}}\left({\mathrm{S}}_{\mathrm{d}}\right)}\end{array}$$

Based on the analysis, we now compare the total delays using the MATLAB tool. ²²

Figure 6 shows the total delay required for each candidate scheme by different group sizes (the number of sensors).

Figure 6.

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.

Figure 7.

Impact of B_w 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.

Figure 8.

Impact of B_wl 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.

Figure 9.

Impact of L_w 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.

Figure 10.

Impact of L_wl 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 (P_S), we calculate the number of packets generated in the network using MATLAB tool. ²²

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.

Figure 11.

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.

Figure 12.

Impact of B_w on packet overhead.

Figure 13.

Impact of B_wl on packet overhead.

Figure 14 shows the impact of the probability (P_S) on packet overhead. As shown in the figure, the multicast-based and the unicast-based schemes are not affected by probability P_S. 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.

Figure 14.

Impact of P_S on packet overhead.

Figure 15 shows the impact of probability (P_S) 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.

Figure 15.

Impact of P_S 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.

Figure 16.

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.

Figure 17.

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 ²³ 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.

Figure 18.

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.

Figure 19.

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 works^24–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. ²⁷