PaperlayerView exact revision on arXiv

Source-linked AI summary

Sensor Search Techniques for Sensing as a Service Architecture for The Internet of Things

Charith Perera, Arkady Zaslavsky, Chi Harold Liu, Michael Compton, Peter Christen, Dimitrios Georgakopoulos

arXiv:1309.3618v1cs.NI

TL;DR

The paper addresses efficient sensor search and selection when IoT systems expose many sensors with heterogeneous context and user requirements. CASSARAM combines ontology-based context modelling, semantic querying, priority-weighted indexing and ranking, and filtering techniques. Evaluations report efficiency benefits from CPHF and REF, while relational expressions increase processing time and memory requirements.

  • Problem

    IoT scale and resource constraints make it difficult to efficiently select sensors that satisfy users’ mandatory requirements and preferences from many available sensors.

  • Method

    CASSARAM combines ontology-based context modelling with semantic querying, user-priority capture, CPWI indexing and ranking, CPHF heuristic filtering, REF filtering, and distributed search mechanisms.

  • Results

    CPHF improves efficiency by reducing information transferred to indexing, while using at least one relational operator increases processing time and memory requirements by 100%.

  • Takeaways & Limitations

    CASSARAM selects sensors according to user expectations and priorities and supports optimized sensor-data collection in sensing-as-a-service scenarios.

Abstract

from arXiv · show

The Internet of Things (IoT) is part of the Internet of the future and will comprise billions of intelligent communicating "things" or Internet Connected Objects (ICO) which will have sensing, actuating, and data processing capabilities. Each ICO will have one or more embedded sensors that will capture potentially enormous amounts of data. The sensors and related data streams can be clustered physically or virtually, which raises the challenge of searching and selecting the right sensors for a query in an efficient and effective way. This paper proposes a context-aware sensor search, selection and ranking model, called CASSARAM, to address the challenge of efficiently selecting a subset of relevant sensors out of a large set of sensors with similar functionality and capabilities. CASSARAM takes into account user preferences and considers a broad range of sensor characteristics, such as reliability, accuracy, location, battery life, and many more. The paper highlights the importance of sensor search, selection and ranking for the IoT, identifies important characteristics of both sensors and data capture processes, and discusses how semantic and quantitative reasoning can be combined together. This work also addresses challenges such as efficient distributed sensor search and relational-expression based filtering. CASSARAM testing and performance evaluation results are presented and discussed.

I. INTRODUCTION

IoT scale makes efficient sensor search and selection essential, yet existing approaches do not comprehensively support context-aware selection. CASSARAM combines ontology-based descriptions, semantic querying, quantitative reasoning, filtering, indexing, ranking, and distributed search.

  • IoT deployments generate enormous sensor data, making it infeasible to collect from all available sensors because of scale, resource, and cost constraints.
  • Existing IoT middleware solutions focus on connecting sensor devices to software systems, while sensor search and selection remain insufficiently addressed.
  • Text-based search cannot accurately capture critical sensor characteristics, while metadata approaches face significant interoperability issues.
  • CASSARAM uses ontology-based sensor descriptions so users can search and select sensors through semantic queries and quantitative reasoning based on priorities.
  • The model contributes CPWI indexing and ranking, CPHF heuristic filtering, REF relational-expression filtering, and several distributed sensor search mechanisms.
  • Prior work includes location-, type-, keyword-, content-, similarity-, tree-, and prediction-based search, but related systems often provide limited context or user-unfriendly interfaces.

III. PROBLEM DEFINITION AND MOTIVATION

The paper defines sensor selection as finding data-providing sensors that efficiently and effectively support a user’s problem. Requirements are separated into non-negotiable point-based constraints and negotiable proximity-based preferences.

  • The objective is to search and select sensors whose data helps address the user’s problem efficiently and effectively, without solving the problem itself.
  • Point-based requirements are non-negotiable constraints that must be fulfilled, such as selecting temperature sensors in Canberra for a temperature-measurement request.
  • Proximity-based requirements are negotiable preferences used to distinguish among sensors that satisfy the point-based requirements.
  • The motivation includes rapid sensor deployment, heterogeneous sensor context values, and sensing-as-a-service models in which users select and pay for sensor data.
  • The proposed approach captures user requirements, represents sensor context, and applies semantic querying and quantitative reasoning to sensor selection.

A. High-level Model Overview

CASSARAM first identifies mandatory requirements, preferences, and user priorities, then queries sensor descriptions, computes priority-weighted indices, ranks sensors, and selects the requested number. Users express priorities through context-property sliders.

  • High-level Model Overview: CASSARAM begins by identifying point-based requirements, proximity-based requirements, and user priorities.
  • High-level Model Overview: Users specify sensor type, location, and required quantity as point-based requirements before the system searches the ontology.
  • High-level Model Overview: Users assign relative importance to context properties with sliders; unselected properties are excluded from CPWI, and higher priorities produce higher weights.
  • High-level Model Overview: If the filtered sensor set contains at least N sensors, CASSARAM calculates CPWI, ranks the sensors, and selects N results.
  • High-level Model Overview: CASSARAM models sensor descriptions and context properties with the SSN ontology, which covers capabilities, performance, operating conditions, and common measurement properties.

D. Filtering Using Querying Reasoning

CASSARAM combines semantic querying for mandatory requirements with quantitative reasoning for preference-based ranking. Its design also includes normalization and filtering mechanisms intended to reduce the sensor set processed by later stages.

  • Filtering Using Querying Reasoning: Semantic querying expresses point-based requirements, but complex queries reduce performance and relational expressions increase computational requirements.
  • Filtering Using Querying Reasoning: CPWI ranks sensors according to proximity-based requirements using a weighted Euclidean-distance indexing technique.
  • Filtering Using Querying Reasoning: CASSARAM represents each sensor as a point in multidimensional context space and compares it with a user-defined or automatically generated ideal sensor.
  • Filtering Using Querying Reasoning: Flexi-Dynamic Normalization normalizes context-property values before quantitative indexing across registered sensors.

F. Context Framework

CASSARAM models sensor context using a broad, extensible set of properties and combines semantic querying with quantitative, priority-based ranking. Its Comparative-Priority Based Weighted Index ranks sensors by weighted distance from user requirements.

  • Context properties: Users express sensor preferences through context properties, while ontology-based descriptions support semantic querying and data modelling.The approach combines semantic querying with quantitative reasoning to search and select suitable sensors.
  • Weighted indexing: CPWI calculates weighted distance between each real sensor and the user-preferred sensor in multidimensional space.The user-preferred sensor and default preferred sensor provide reference points for the comparison.
  • Weighted indexing: The indexing procedure calculates CPWI for each sensor and applies reverse-normalized ranking, so the lowest weighted distance ranks highest.CASSARAM returns the top N sensors from the ranked results.
  • Context properties: CASSARAM stores context properties including availability, accuracy, reliability, response time, frequency, sensitivity, measurement range, precision, latency, and resolution.The framework can be extended with additional properties, including battery life, security, interoperability, cost, bandwidth, and trust.
  • Heuristic filtering: Comparative-Priority Based Heuristic Filtering orders sensors by weighted context-property priorities and removes low-ranked subsets before final indexing and ranking.The filtering algorithm converts priorities to percentages, removes sensors iteratively, and returns the filtered set.

V. IMPROVING SCALABILITY AND EFFICIENCY

The paper improves CASSARAM’s scalability by introducing heuristic filtering for large sensor populations. The approach trades some accuracy for efficiency by reducing the sensors requiring indexing and ranking.

  • Motivation: CASSARAM becomes inefficient when searching a massive sensor population, such as selecting 1,000 sensors from one million.The baseline indexes and ranks all available sensors before selecting the top requested subset.
  • Comparative-Priority Based Heuristic Filtering: The proposed heuristic removes sensors far from user-defined requirements before indexing and ranking the remaining candidates.This reduces the number of sensors processed by the computationally expensive ranking stages.
  • Comparative-Priority Based Heuristic Filtering: CPHF repeatedly ranks candidates by the highest-priority context properties, removes bottom-ranked subsets, and continues with the remaining properties.The example removes 40% of removable sensors using accuracy, then 30% using reliability, before final ranking.

B. Relational-Expression Based Filtering (REF)

REF uses relational operators to exclude sensors that fall outside user-defined bounds before CPWI generation. Distributed strategies then coordinate search across multiple middleware instances while limiting communication overhead.

  • Relational-Expression Based Filtering: REF lets users specify exact or semi-non-negotiable context requirements with operators such as <, >, ≤, and ≥.For example, an accuracy requirement may accept sensors between 70% and 90% instead of requiring exactly 85%.
  • Relational-Expression Based Filtering: Applying relational ranges during semantic querying excludes irrelevant sensors before CPWI generation and saves computational resources.Sensors that satisfy the range are still ranked according to user priorities.
  • Distributed Sensor Searching: Distributed search is needed because sensors may be connected to different middleware instances rather than one server.Complex requirements can require querying multiple instances, such as geographically distributed agricultural sensor deployments.
  • Distributed Sensor Searching: In sequential processing, an initiator sends selected sensor identifiers and CPWIs between nodes, where each node merges incoming information with its own results.The sequential chain limits each node’s transmitted selection to the most appropriate sensors.
  • Distributed Sensor Searching: Parallel processing sends each request to all nodes, but returning many candidates can overwhelm the initiator and waste bandwidth.With 2,500 nodes returning 100 sensors each, the initiator receives 2500 × 100 records.
  • Distributed Sensor Searching: The paper concludes that distributed processing should combine chain and parallel techniques dynamically according to device capabilities and available bandwidth.No single strategy is efficient for every situation.
  • Distributed Sensor Searching: The optimized parallel approach has each node send only every kth ranked sensor instead of its entire candidate list.This reduces transmitted records while preserving ranked information for aggregation at the initiator.

VI. IMPLEMENTATION AND EXPERIMENTATION

The authors evaluate CASSARAM with a Java prototype that captures user preferences and context-property priorities. Experiments vary relational filtering conditions and compare CPHF with baseline processing as sensor counts increase.

  • Implementation: The CASSARA Tool prototype was implemented in Java with sensor data stored in MySQL and evaluated on a computer with an Intel Core i5-2557M CPU and 4GB RAM.The implementation uses Apache Commons Mathematics for Euclidean-distance operations and Apache Jena for SSN ontology processing.
  • Implementation: The tool captures user preferences and priorities for sensor context properties through a user interface.Users can enter values in native units, which CASSARAM normalizes for processing.
  • Assumptions: The evaluation assumes sensor descriptions and context data are available in the SSN ontology and are continually monitored, measured, managed, and stored.The distributed-processing evaluation uses an experimental test involving multiple computers.
  • Experimental design: The experiments evaluate combinations of relational operators across five retrieved context properties.Scenarios include unrestricted properties and restrictions applied to one or more properties using operators such as ≥.

VII. EVALUATION AND DISCUSSION

The evaluation examines CASSARAM’s storage, processing time, memory use, and the effects of CPHF, relational expressions, and REF as sensor scale and context-property counts vary. Results identify scalability thresholds and trade-offs among querying, indexing, ranking, and resource usage.

  • Storage requirements: 6.4 GB and 17.8 GB store one million sensor descriptions with 10 and 30 context properties, respectively.A single triple requires about 0.193 KB for 100,000+ sensors; context-property counts should therefore be chosen carefully at billion-sensor scale.
  • Querying and memory: Semantic querying takes significantly more processing time than indexing and ranking, and execution time rises as retrieved context properties increase.For 10,000 sensors, querying 5 context properties takes 8 ms versus 24 ms for 10 properties.
  • Indexing: Indexing time increases significantly after 100,000 sensors, while indexing memory remains negligible below that scale and rises substantially afterward.The number of context properties has little impact on indexing memory beyond 100,000 sensors; at one million sensors, the process requires 30 MB.
  • CPHF: CPHF saves time in indexing and ranking and reduces data transferred to later phases, but requires more memory during querying.With N=50 and five retrieved context properties, CPHF avoids holding millions of sensor records across multiple processing phases.
  • Relational expressions: Using at least one relational operator increases querying time and memory requirements by 100%, while additional operators or operator types have no further impact.Multiple relational operators can still reduce the sensor volume passed to later phases.
  • REF and deployment scope: REF adds processing overhead, and its processing-time difference is significant below 100,000 queried sensors; parallel processing can reduce distributed processing time for millions of descriptions.CASSARAM can operate with limited resources, but response time is much longer; the practical deployment assumption is distributed middleware rather than one instance holding millions of sensors.

A. Evaluating Alternative Storage Options

The evaluation compares Jena SDB/MySQL with Jena TDB as alternative storage backends for CASSARAM. TDB scales better for larger sensor-description datasets, while SDB retains advantages for query processing and database functionality in some settings.

  • Jena TDB was 10 times faster than Jena SDB for 10 context properties across half a million sensor descriptions.
  • Jena SDB used less memory below 100,000 sensor descriptions, whereas Jena TDB used 50% less memory at half a million descriptions with 10 context properties.
  • The evaluation identifies Jena TDB as more suitable when sensor descriptions exceed 100,000.
  • Jena TDB offers faster loading and better scale but the worst query performance, while Sesame and SDB provide different trade-offs.
  • SDB/MySQL may be preferable when database functionality, infrequent loading, or increased transactions are important.

B. Evaluating Distributed Sensor Searching

The distributed-search evaluation compares chain and parallel processing across four nodes, then examines k-extension as a way to reduce redundant communication. Parallel processing minimizes total processing time, but its communication trade-offs depend on the scenario and k-extension setting.

  • The experiment used four computational nodes, each containing one million distinct sensor descriptions, and evaluated five context properties.
  • Parallel processing was more efficient than chain processing in total processing time.
  • k-extension can save redundant data communication, but negative values indicate that savings are not guaranteed in some situations.
  • Chain processing suits cases prioritizing computational resources and bandwidth over response time.
  • Parallel processing without k-extension suits response-critical cases when N is fairly small.
  • k-extension requires two communication rounds, which consumes more energy for energy-constrained computational devices.

C. Application

CASSARAM operates within the CASCoM application workflow for expressing tasks and finding the sensors needed to produce their required data streams. CASCoM filters tasks and components before invoking CASSARAM for sensor selection.

  • CASCoM lets consumers express requirements through a graphical question-answer interface.
  • CASCoM filters the available tasks and lets users select a desired task such as environmental pollution detection.
  • CASCoM searches for programming components that capture the data streams required by the selected task.
  • CASSARAM finds sensors capable of producing the inputs required by those data-processing components.

VIII. CONCLUSIONS AND FUTURE RESEARCH

The paper concludes that context information can guide sensor search and selection according to user requirements and priorities. It demonstrates CASSARAM through a prototype and identifies distributed search integration and further efficiency improvements as future work.

  • CASSARAM uses context information to search and select sensors suited to user requirements.
  • The prototype demonstrates CASSARAM functionality and supports experimentation with realistic applications.
  • Selecting sensors with more energy can optimize data collection and help the sensor network run longer without reconfiguration.
  • The paper evaluates comparative-priority heuristic filtering, relational-expression filtering, and distributed sensor searching as efficiency and scalability techniques.
  • Future work includes integrating CASSARAM into IoT middleware and improving efficiency through cluster-based search and machine-learning heuristics.
Loading 1309.3618v1…