Distributed coordination protocol for event data exchange in IoT monitoring applications
•Download as PPTX, PDF•
0 likes•66 views
The document proposes a distributed coordination protocol for event data exchange in IoT monitoring applications. It aims to address challenges from low-powered IoT devices by minimizing communication overhead. The protocol builds on a previous broker-less solution by utilizing packet headers and a decision algorithm to selectively disseminate messages. Simulation results show the proposed protocol reduces energy consumption by up to 33%, network traffic by 28%, registration delay by 19%, and packet delivery delay by 10% compared to the previous approach.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Distributed coordination protocol for event data exchange in IoT monitoring applications
Similar to Distributed coordination protocol for event data exchange in IoT monitoring applications (20)
More from Maynooth University
More from Maynooth University (8)
Recently uploaded
Recently uploaded (20)
Distributed coordination protocol for event data exchange in IoT monitoring applications
- 1. Distributed coordination protocol for event data exchange in IoT monitoring applications Presented by: Behnam Khazael Author with Affiliation: Dr. Hadi Tabatabaee Malazi
- 2. Overview Introduction Problem statement Related work Proposed distributed coordination protocol Evaluation Conclusion 2020 11th International (Virtual) Conference on Information and Knowledge Technology (IKT) 2/14
- 3. Introduction • Internet of Things (IoT) in monitoring applications • IoT applications such as waste management, fire monitoring, and traffic monitoring. • In-place monitoring devices need to capture events as soon as they happen. • Broker-less publish/subscribe architecture in designing the Internet of things (IoT) monitoring applications. 2020 11th International (Virtual) Conference on Information and Knowledge Technology (IKT) 3/14
- 4. Problem Statement • Designing a distributed coordination protocol for event data exchange in IoT monitoring applications is a challenging task: • Low computation capacity IoT devices. • IoT devices mostly operating with batteries. • Most of the energy of IoT devices is consumed on packet transmission. • Keeping each node in the network updated needs to exchange a high number of control messages. 2020 11th International (Virtual) Conference on Information and Knowledge Technology (IKT) 4/14
- 5. Previous Work: • Esposito et al.* proposed solution. • The researchers considered a broker-less publish/subscribe architecture. • To minimize the communication overhead, message beaconing was utilized to disseminate messages in the network. • Issue is the blind re-beaconing 2020 11th International (Virtual) Conference on Information and Knowledge Technology (IKT) * “Event-based sensor data exchange and fusion in the Internet of Things environments”, Journal of Parallel and Distributed Computing, vol. 118, pp. 328–343, 2018. 5/14
- 6. Proposed Distributed coordination protocol • Routing Table structure in each node: • The topic of the interest • Publishers' list • Subscribers’ list • Received list • Packet structure: • Header • Source Address • Destination Address (Broadcast) Beaconing • Message-ID • Receivers list • Message Type (advertisement, subscribe, publish, update, leave) • Body • Topic • Data 2020 11th International (Virtual) Conference on Information and Knowledge Technology (IKT) Our proposed coordination protocol built on top of Esposito et al. proposed solution. 6/14
- 7. Proposed Distributed coordination protocol (Cont.) Decision support algorithm 2020 11th International (Virtual) Conference on Information and Knowledge Technology (IKT) 1 2 <header> … <receivers><item>1</item> <item>2</item></receivers> … </header> 1 3 4 5 6 7 8 9 Topic Subscribers Publishers temp 2, 3, 4 0 Is it necessary to send the packet? Algorithm to support. -> list of subscribers -> receiver list 3, 4 Yes set the packet. (beaconing) 7/14
- 8. Proposed Distributed coordination protocol (Cont.) How the algorithm help to reduce unwanted publish messages? 2020 11th International (Virtual) Conference on Information and Knowledge Technology (IKT) 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 8/14 2 3 4 1
- 9. Evaluation • Cooja simulator utilized to evaluates the proposed solution vs. Esposito et al. approach. • Cooja Simulator is a network simulator specifically designed for Wireless Sensor Networks. • Motes simulated by extending java classes of Cooja motes. 2020 11th International (Virtual) Conference on Information and Knowledge Technology (IKT) 9/14
- 10. Evaluation (Cont.) • Configuration Parameters considered as follow: • Working space with 100 units height and 100 unites widths considered for the evaluation. • Transition range of each mote set to 30 unites. • Number of nodes for each evaluations ranges from 25 to 125 (publishers and subscribers). • 1000 events generated during 10 minutes of simulation. 2020 11th International (Virtual) Conference on Information and Knowledge Technology (IKT) 10/14
- 11. Evaluation (Cont.) Energy consumption comparison (up to 33% ) Network traffic comparison(on average 28% ) 2020 11th International (Virtual) Conference on Information and Knowledge Technology (IKT) 11/14
- 12. Evaluation (Cont.) Registration delay comparison (on average 19% ) Packet delivery delay comparison(on average 10% ) 2020 11th International (Virtual) Conference on Information and Knowledge Technology (IKT) 12/14
- 13. Conclusion • We utilized headers of the packets in the dissemination of the events to improve packet dissemination in a distributed event data exchange protocol. • As evaluation showed that our method increased the longevity of the network. • As evaluation showed that our method reduces the time that packets wait in the sending queue. • Our method Imposed additional computation in the process of packets. • In future works, we focus on extending this approach to bring in-network processing to determine complex events in a distributed manner. 2020 11th International (Virtual) Conference on Information and Knowledge Technology (IKT) 13/14
- 14. Questions? Thank you for your attention! 14/14
Editor's Notes
- In the name of God. Hello everyone. My name is Behnam Khazael, I’m a Ph.D. student at Shahid Beheshti University, under the supervision of Dr. Tabatabaee, my research interest includes complex event processing and middleware architectures for monitoring applications in smart cities. This research, with the title of “Distributed coordination protocol for event data exchange in IoT monitoring applications” is about an extended distributed coordination protocol that improved a number of metrics in event data dissemination for monitoring applications in smart cities.
- Here is an overview of topics that we are going to address in this presentation. At first, in the Introduction section, we will introduce the environment of our research and explain solutions and applications. We will introduce the problem with the challenges that we are going to address, in the problem statement section. In the related work section, we elaborate in more detail on the current solution and its main drawback. We introduce our method and algorithm in the proposed distributed coordination protocol section. In the evaluations section, we will show the results of our experiments. And finally, in the conclusion section, we spot the goals that we achieved.
- 1- One of the major category of the Internet of Things (IoT) are monitoring applications. 2-1- For instance, in a smart city, a huge number of IoT devices are employed for various applications such as waste management, fire monitoring, and traffic monitoring. 2-2- Fire monitoring applications are a common applications that needs to continuously receive new data from sensors that deployed in the environment. 3- To establish the connection between consumers of sensors data and sensor nodes the publish-subscribe architectural styles utilized in designing the Internet of things (IoT) monitoring applications.
- 0- The IoT systems innately need to exchange data among connected devices to reach their objectives such as detecting a complex event, like fire. 0- Broker-less publish/subscribe architecture is one the most solutions utilized to exchange data among connected devices. 0- Designing a distributed coordination protocol for broker-less publish/subscribe systems is a challenging task as: 1- The IoT devices in these systems have low computation capacity and they are mostly operating with batteries which replacing them is not easy. 2- Most of the energy of IoT devices is consumed on packet transmission. 3- Keeping each node in the network updated regard to publishers and subscribers needs to exchange a high number of control messages. 3- thus, Designing an efficient communication protocol is challenging, message dissemination has to be done efficiently, which means that with minimum message passing the maximum information should exchange.
- Esposito et al. proposed a broker-less communication protocol for monitoring applications. In their solution, they considered that each node maintains a routing topic table to distribute the management of subscriptions. in order to reduce the communication overhead, they consider beaconing for message dissemination. as the middle figure shows, if we consider that node number 1 is the publisher the dissemination of packets based on beaconing would happen as follow: In iteration A which is presented in black color, by beaconing the message nodes 2 and 3 would receive the packet. At the nest iteration, the iteration “B”, which is presented in red, as only node number 3 has two other neighbors to send the packet two them, it would re-beaconing the packet. At the final iteration which is iteration C, node number 5 re-beaconing the packet to deliver it to its neighbor the node number 6. In this way, the packets disseminate in the network. Although the protocol is fully distributed but, re-beaconing the packet can drain the node energy and make the sending/receiving queue of nodes crowded. As the figure on the right side of the slide shows, consider a node with number 7 that exist as a neighbor of nodes 2, 3, and 4. now again consider the iteration B in Red. Node 3 send the packet to node 4 and 7. At this moment nodes number 2, 3, 4, 5, and 7 already received the packet, but in iteration C, as node number 4 and node number 7 does not know that the packet reaches their neighbor, they blindly re-beaconing the packet.
- In order to rectify blind exchange, we extended the Esposito et al. algorithm. The routing table that each node maintain includes following items: 1- topic of interest, 2- list of publishers 3- list of subscribers 4- received list which is the list of message ids that received for this topic. In the packet structure we allocate a header part to let sender of a packet introduce the nodes that it already sent this packet to them, we called this part of header as a receivers list.
- To utilize the receiver list of the packets, each node must run an algorithm which we are going to introduce in this slide. Consider an environment with 10 nodes as presented in this slide, to deliver the publish message to the subscriber the publisher send it to its neighbors by beaconing the packet. Node number 1 receives the packet and starts to process it. It first checks if it is interested in this topic or not, if yes it would consume the data Meanwhile, it checks its routing table and finds interested neighbors in the received topic, besides it extracts the receivers list, and along with subscribers of this topic, it evaluates to see if it is necessary to beaconing the packet or not. As neighbors number 3 and 4 did not exist in the receivers list the node re-beaconing the packet to deliver it to nodes number 3 and 4.
- But how the algorithm help to eliminate unwanted beaconing? Let's continue the previous example, Nodes in black are sender nodes at each iteration. Nodes in yellow are receivers nodes at each iteration. Nodes in white are not active to receive or send a message. new packets presented in green arrows, duplicate packets presented in blue and blind messages presented in red. In iteration 1 publisher send the packet to nodes number 1 and 2 in iteration 2 nodes number 1 and 2 re-beaconing the packet and in this iteration, nodes number 3, 4, 5, and 6 receive the packet, in this iteration node number 4 receives the same packet twice as it is in the transmission range of both node number 1 and node number 2. In iteration 3, node number 3 and node number 6 won't re-beaconing the packet, although they have a neighbor in their transmission rage. As they run the algorithm and node number 4 was in the receives list thus, node number 3 stop resending the packet, same happens for node number 6 as node number 5 is already received the packet. Finally, in iteration 4, the packet is delivered to the subscriber.
- Cooja simulator utilized to evaluates the proposed solution vs. Esposito et al. approach. Cooja Simulator is a network simulator specifically designed for Wireless Sensor Networks. Motes simulated by extending java classes of Cooja motes.
- Here are configuration parameters used for evaluations. A sample simulation space is presented in this slide.
- energy consumption figure on the left side of the slide Shows the average energy consumption of nodes for transmitting and receiving packets. As the figure demonstrates our proposed solution shows 19.03 % improvements to decreasing energy consumption in the network size 25 and 33.78 % better performance in the network size 125. The reason for this improvement is that in the proposed approach each node makes a decision based on the received packet signatures in the header and decides to not beacon the message again the packet already sent to its neighbors. The next metric that we measured is the network traffic which fig. Network Traffic shows on the right side of the slide the evaluation result where the Y-axis presents the number of disseminated packets in the network and the X-axis presents the network size. As the figure demonstrates our proposed solution which on average reduces up to 28.12 % the number of disseminated packets in the network under the same network sizes in comparison to the Esposito et al approach. The reason is that by applying the algorithm to identify the eligible neighbors to receive the packet we prevent re-sending duplicates packets which as a result it reduces the communication overhead to prepare a new beacon packet and in addition, reduces the network traffic.
- The next measurement metric that we consider in our work to compare our proposed solution with the Esposito et al. approach is the registration delay which is the time that nodes in the network announced event topic(s) that they can publish event messages regard to them or express their interests in a certain topic(s). As the fig registration delay shows on the left side of the slide our proposed solution perform 19.94 % on average better in this criteria over the Esposito et al. approach, since by processing the received packets each node tries to not occupy the radio for transmitting redundant data thus relevant and necessary packets get the chance to transmit and in this way time to deliver the registration messages reduced. The final evaluation metric that we consider in this work is the time pass from the actual event to happen until the event reaches the desired subscribers. Fig event propagation delay demonstrates the evaluation result for these criteria. As the figure shows our proposed solution performs 10.33 % better in comparison to the Esposito et al. approach and delivered the event notifications to the subscribers faster since in our approach we reduced the network traffic and because of those events in our approach will not remain in the sending queue as much as the Esposito et al. approach.
- By adding metadata to the header of disseminated packets we empowered nodes in this protocol to wisely decide when re-beaconing the received packet. As evaluation showed, our method saved energy in comparison to the previous method. In addition, our method reduced the delivery time, which is important for monitoring applications.
- In the end, thank you for your attention.