Optimizations
The most commonly used resource and therefore the most significant source of bandwidth consumption on the OpenIOT platform, is expected to be the data streamed from the sensors to the users. This section describes an optimization strategy that addresses this issue and has been developed in the context Resource Sharing and Management functionalities. The module responsible for streaming from sensors to the LSM-Light is X-GSN. In the current implementation of X-GSN, once a sensor is activated it streams data continuously whether the data is actually needed from a service or not. This results in a misuse of available bandwidth. In order to address this issue, a module that applies Indirect Dynamic Sensor functionality has been implemented on top of the X-GSN module. As the name of the module implies, the control (activation/deactivation) of a sensor is not to be controlled directly from the user. Rather, a user announces the creation of a service which makes use of a group of sensors, to the Request Definition module. The request is forwarded to the Scheduler which in turn creates a SPARQL triplet of a “serviceID HAS sensorID” format on the LSM-Light, which is represented by the sensorServiceRelation entity, stating which sensors a particular service is intending to use. At the same time, a periodic timed task is running on the X-GSN module, which is responsible for direct sensor management, querying the particular triple on the LSM-Light repository, in order to determine which sensors are being currently announced/ requested by users. The task compares the query results from the triplets, with the list of virtual-sensors that are currently active on the X-GSN module. Then X-GSN activates virtual sensors that have been found by the query but are not active on the module and deactivate the virtual sensors that are active on the module but have not been found in the query.
The above process is illustrated in the sequence and flow chart diagrams below:
[
](Documentation/images/resource-optimization/ro-sequence-diagram.png)
[
](Documentation/images/resource-optimization/ro-flow-chart.png)
The above process is expected to result in significant bandwidth conservation, since sensors streams data only when they are actually used, as opposed to them streaming on a constant basis.
To implement the Dynamic Sensor Control functionality, the X-GSN module needed support a basic API that activates/deactivates virtual-sensors programmatically. The original GSN framework does not support such an API, and sensor activation / deactivation is performed by copying or removing accordingly the virtual sensor .xml and metadata files, from the virtual-sensors directory within the GSN source folder.
In order not to temper with the existing code, an independent module for has been implemented that performs the Dynamic Sensor Control functionality.
The module’s functionality can be described briefly as follows:
- By querying the LSM-Light, an
ArrayList<String>of active sensor names are obtained - Then the module scans the virtual-sensors directory for all
.xmlfiles constructs aHashMap<String, File>, that maps sensor id Strings which are obtained from the name property in the<sensor>.xml.metadatafile, with File Objects that correspond the virtual-sensor names - The module scans the available virtual sensors from the LSM-Light folder in the X-GSN module, again mapping sensor id’s with corresponding files.
- The
ArrayList<String>obtained from the query on the LSM-Light is compared with the firstHashMap<String, File>. Any sensor names located in the HashMap but not in the SPARQL query ArrayList are deactivated. This is performed by deleting the corresponding.xmland.xml.metadatafiles from the directory - Finally the
ArrayList<String>obtained from the SPARQL query is compared with the available sensors and activates them by copying the corresponding files to the virtual-sensors directory - This functionality is embedded in a TimerTask class (the DynamicControlTask class) that is executed in predefined intervals