Database Reference
In-Depth Information
messages, where N , splitting threshold and merging threshold are parameters of
the engine. The coordinator initiates the splitting and merging actions based on
the observed idle time of a single process. The splitting of a matcher is initiated
when idle time of the matcher process in the window of N last received mes-
sages is smaller than a given threshold, i.e., when the matching process is active
throughout the time span of the window, expressed as the percentage of the
total window time. If the idle time is smaller than the given splitting threshold,
a splitting trigger is fired. Since the observed matcher is under high load, i.e.,
it takes too much time to process incoming messages, the subscription structure
needs to be reduced. To reduce the load on the matcher, half of the subscription
structure is forwarded to a newly created matcher. The merging of a matcher is
initiated when the maximal processing time in the window of N last publication
matching is smaller than a given threshold, i.e. when all publications in the win-
dow were processed in lower processing time than the defined threshold. This
criterion is, like the splitting criterion, chosen for its robustness with regard to
sudden spikes in processing times.
2.2 QoS Manager
While CUPUS architecture supports controlled data acquisition based on global
data requirements, the CPSP engine does not provide further intelligent decision-
making mechanisms aimed at optimizing sensing data quality and energy con-
sumption while retaining a required sensing coverage. We envision cases when
redundant sensed data is available in certain geographical locations (e.g., due to a
large number of sensors generating data in a certain geographic area), whereby a
subset of sensors may be requested to transmit data, while others may be deacti-
vated. Decisions on determining an optimal subset of sensors which to keep active
in order to meet subscription requirements can be made based on parameters such
as sensor accuracy, level of trustworthiness, and available battery level.
The QoS Manager component adds support for intelligent QoS-based mon-
itoring and management mechanisms in mobile IoT usage scenarios involving
mobile devices with either built-in or wearable sensors as data sources. It is
implemented as a stand-alone component which interfaces the CPSP engine and
is further integrated with the OpenIoT platform in order to achieve the follow-
ing goals: (1) context-aware sensing coverage and data quality management and
(2) energy eciency management.
1. Context-aware sensing coverage and data quality management:
Ensure that the sensed data received by an end user meets his/her sensor
data demands with established quality thresholds (in terms of accuracy, fre-
quency of sensor readings) through support of context-aware data acquisi-
tion mechanisms, while maintaining energy eciency. In other words, for a
given geographic area and time interval, the goal is to acquire a sucient
number of sensor readings from activated sensors to satisfy the data qual-
ity requirements for all active end-user subscriptions in that area (i.e., global
data requirements integrating individual data demands), thus effectively min-
imizing energy consumption.
Search WWH ::




Custom Search