Processing continuous join queries in sensor networks

Stern, Mirco; Böhm, Klemens; Buchmann, Erik

doi:10.1145/1807167.1807198

Cited by 19 publications

(36 citation statements)

References 17 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Many proposed frameworks for in-network data processing either rely on a base-station [7,15,17,19] or are applicable only for specific types of processing or network topology [2,3].…”

Section: Background and Processing Platformmentioning

confidence: 99%

See 1 more Smart Citation

Efficient In-Network Processing for a Hardware-Heterogeneous IoT

Kolcun

Boyle

McCann

2016

Proceedings of the 6th International Conference on the Internet of Things

View full text Add to dashboard Cite

As the number of small, battery-operated, wireless-enabled devices deployed in various applications of Internet of Things (IoT), Wireless Sensor Networks (WSN), and Cyber-physical Systems (CPS) is rapidly increasing, so is the number of data streams that must be processed. In cases where data do not need to be archived, centrally processed, or federated, innetwork data processing is becoming more common. For this purpose, various platforms like DRAGON, Innet, and CJF were proposed. However, these platforms assume that all nodes in the network are the same, i.e. the network is homogeneous. As Moore's law still applies, nodes are becoming smaller, more powerful, and more energy efficient each year; which will continue for the foreseeable future. Therefore, we can expect that as sensor networks are extended and updated, hardware heterogeneity will soon be common in networks -the same trend as can be seen in cloud computing infrastructures. This heterogeneity introduces new challenges in terms of choosing an in-network data processing node, as not only its location, but also its capabilities, must be considered. This paper introduces a new methodology to tackle this challenge, comprising three new algorithms -Request, Traverse, and Mixed -for efficiently locating an in-network data processing node, while taking into account not only position within the network but also hardware capabilities. The proposed algorithms are evaluated against a naïve approach and achieve up to 90% reduction in network traffic during long-term data processing, while spending a similar amount time in the discovery phase.

show abstract

“…Many proposed frameworks for in-network data processing either rely on a base-station [7,15,17,19] or are applicable only for specific types of processing or network topology [2,3].…”

Section: Background and Processing Platformmentioning

confidence: 99%

“…Stern et al (2010) proposed a two-phased Continuous Join Filtering (CJF) algorithm [19] where initial data are first collected at the base-station which computes and pushes filters back into the network. Nodes then send non-filtered sensed values to the base-station.…”

Section: Related Workmentioning

confidence: 99%

Efficient In-Network Processing for a Hardware-Heterogeneous IoT

Kolcun

Boyle

McCann

2016

Proceedings of the 6th International Conference on the Internet of Things

View full text Add to dashboard Cite

show abstract

“…Similarly, if the data sources are scattered throughout the network, Pandit and Gupta propose to choose a random node using the hash of the join key, as the processing node [9]. Stern et al propose Continuous Join Filtering (CJF) -a twophase approach where first summaries of static and dynamic attributes of all nodes in the network are collected, then the base-station uses these summaries to choose candidates for the join [10]. In the second phase, filters generated by the base-stations are pushed back into the network, and only nodes whose sensed data passes this filter send data back to the base-station [10].…”

Section: A Related Workmentioning

confidence: 99%

“…Stern et al propose Continuous Join Filtering (CJF) -a twophase approach where first summaries of static and dynamic attributes of all nodes in the network are collected, then the base-station uses these summaries to choose candidates for the join [10]. In the second phase, filters generated by the base-stations are pushed back into the network, and only nodes whose sensed data passes this filter send data back to the base-station [10]. The final join of data streams is performed at the base-station.…”

Section: A Related Workmentioning

confidence: 99%

Optimal processing node discovery algorithm for distributed computing in IoT

Kolcun

Boyle

McCann

2015

2015 5th International Conference on the Internet of Things (IOT)

View full text Add to dashboard Cite

Abstract-The number of Internet-connected sensing and control devices is growing. Some anticipate them to number in excess of 212 billion by 2020. Inherently, these devices generate continuous data streams, many of which need to be stored and processed. Traditional approaches, whereby all data are shipped to the cloud, may not continue to be effective as cloud infrastructure may not be able to handle myriads of data streams and their associated storage and processing needs. Using cloud infrastructure alone for data processing significantly increases latency, and contributes to unnecessary energy inefficiencies, including potentially unnecessary data transmission in constrained wireless networks, and on cloud computing facilities increasingly known to be significant consumers of energy. In this paper we present a distributed platform for wireless sensor networks which allows computation to be shifted from the cloud into the network. This reduces the traffic in the sensor network, intermediate networks, and cloud infrastructure. The platform is fully distributed, allowing every node in a homogeneous network to accept continuous queries from a user, find all nodes satisfying the user's query, find an optimal node (Fermat-Weber point) in the network upon which to process the query, and provide the result to the user. Our results show that the number of required messages can be decreased up to 49% and processing latency by 42% in comparison with state-of-the-art approaches, including Innet.

show abstract

“…Note that, although WBF j is not received at the current timestamp, a node can perform the second phase since WBF j was received previously. Each node sends its join participants and the join participants coming from its child nodes to the base station along the routing path (lines [22][23][24][25]. Finally, TWINS-BS starts its execution to generate a join result.…”

Section: The Second Phasementioning

confidence: 99%