Data Management for the Internet of Things: Design Primitives and Solution

2.1. IoT Data Lifecycle

The lifecycle of data within an IoT system—illustrated in Figure 1—proceeds from data production to aggregation, transfer, optional filtering and preprocessing, and finally to storage and archiving. Querying and analysis are the end points that initiate (request) and consume data production, but data production can be set to be “pushed” to the IoT consuming services [5]. Production, collection, aggregation, filtering, and some basic querying and preliminary processing functionalities are considered online, communication-intensive operations. Intensive preprocessing, long-term storage and archival and in-depth processing/analysis are considered offline storage-intensive operations.

Storage operations aim at making data available on the long term for constant access/updates, while archival is concerned with read-only data. Since some IoT systems may generate, process, and store data in-network for real-time and localized services, with no need to propagate this data further up to concentration points in the system, “edges” that combine both processing and storage elements may exist as autonomous units in the cycle. In the following paragraphs, each of the elements in the IoT data lifecycle is explained.

Querying: Data-intensive systems rely on querying as the core process to access and retrieve data. In the context of IoT, a query can be issued either to request real-time data to be collected for temporal monitoring purposes or to retrieve a certain view of the data stored within the system. The first case is typical when a (mostly localized) real-time request for data is needed. The second case represents more globalized views of data and in-depth analysis of trends and patterns.

Production: Data production involves sensing and transfer of data by the “Things” within the IoT framework and reporting this data to interested parties periodically (as in a subscribe/notify model), pushing it up the network to aggregation points and subsequently to database servers, or sending it as a response triggered by queries that request the data from sensors and smart objects. Data is usually time-stamped and possibly geo-stamped, and can be in the form of simple key-value pairs, or it may contain rich audio/image/video content, with varying degrees of complexity in-between.

Collection: The sensors and smart objects within the IoT may store the data for a certain time interval or report it to governing components. Data may be collected at concentration points or gateways within the network where it is further filtered and processed, and possibly fused into compact forms for efficient transmission. Wireless communication technologies such as Zigbee, Wi-Fi and cellular are used by objects to send data to collection points.

Aggregation/Fusion: Transmitting all the raw data out of the network in real-time is often prohibitively expensive given the increasing data streaming rates and the limited bandwidth. Aggregation and fusion techniques deploy summarization and merging operations in real-time to compress the volume of data to be stored and transmitted [6].

Delivery: As data is filtered, aggregated, and possibly processed either at the concentration points or at the autonomous virtual units within the IoT, the results of these processes may need to be sent further up the system, either as final responses, or for storage and in-depth analysis. Wired or wireless broadband communications may be used there to transfer data to permanent data stores.

Preprocessing: IoT data will come from different sources with varying formats and structures. Data may need to be preprocessed to handle missing data, remove redundancies and integrate data from different sources into a unified schema before being committed to storage. This preprocessing is a known procedure in data mining called data cleaning. Schema integration does not imply brute-force fitting of all the data into a fixed relational (tables) schema, but rather a more abstract definition of a consistent way to access the data without having to customize access for each source's data format(s). Probabilities at different levels in the schema may be added at this phase to IoT data items in order to handle uncertainty that may be present in data or to deal with the lack of trust that may exist in data sources [7].

Storage/Update—Archiving: This phase handles the efficient storage and organization of data as well as the continuous update of data with new information as it becomes available. Archiving refers to the offline long-term storage of data that is not immediately needed for the system's ongoing operations. The core of centralized storage is the deployment of storage structures that adapt to the various data types and the frequency of data capture. Relational database management systems are a popular choice that involves the organization of data into a table schema with predefined interrelationships and metadata for efficient retrieval at later stages [8]. NoSQL key-value stores are gaining popularity as storage technologies for their support of big data storage with no reliance on relational schema or strong consistency requirements typical of relational database systems [9]. Storage can also be decentralized for autonomous IoT systems, where data is kept at the objects that generate it and is not sent up the system. However, due to the limited capabilities of such objects, storage capacity remains limited in comparison to the centralized storage model.

Processing/Analysis: This phase involves the ongoing retrieval and analysis operations performed and stored and archived data in order to gain insights into historical data and predict future trends, or to detect abnormalities in the data that may trigger further investigation or action. Task-specific preprocessing may be needed to filter and clean data before meaningful operations take place. When an IoT subsystem is autonomous and does not require permanent storage of its data, but rather keeps the processing and storage in the network, then in-network processing may be performed in response to real-time or localized queries.

Looking back at Figure 1, the flow of data may take one of three paths: a path for autonomous systems within the IoT that proceeds from query to production to in-network processing and then delivery, a path that starts from production and proceeds to collection and filtering/aggregation/fusion and ends with data delivery to initiating (possibly global or near real-time) queries, and finally a path that extends the production to aggregation further and includes preprocessing, permanent data storage and archival, and in-depth processing and analysis. In the next section, the need for data management solutions that surpass the current capabilities of traditional data management is highlighted in light of the previously outlined life cycle.

2.2. IoT Data Management versus Traditional Database Management Systems

Based on the IoT data lifecycle discussed earlier, we divide an IoT data management system into an online, real-time frontend that interacts directly with the interconnected IoT objects and sensors, and an offline backend that handles the mass storage and in-depth analysis of IoT data. The data management frontend is communication-intensive; involving the propagation of query requests and result to and from sensors and smart objects. The backend is storage-intensive; involving the mass storage of produced data for later processing and analysis and more in-depth queries. Although the storage elements reside on the back end, they interact with the frontend on a frequent basis via continuous updates and are thus referred to as online. The autonomous edges in the life cycle can be considered more communication-intensive than storage-intensive, as they provide real-time data to certain queries.

This envisioned data management architecture parts considerably from the existing database management systems, which are mainly storage-centric. In traditional database systems, the bulk of data is collected from predefined and finite sources, and stored in scalar form according to strict normalization rules in relations. Queries are used to retrieve specific “summary” views of the system or update specific items in the database. New data is inserted into the database when needed, also via insertion queries. Query operations are usually local, with execution costs bound to processing and intermediate storage. Transaction management mechanisms guarantee the ACID properties in order to enforce overall data integrity [8]. Even if the database is distributed over multiple sites, query processing and distributed transaction management are enforced [10]. The execution of distributed queries is based on the transparency principle, which dictates that the database is still viewed logically as one centralized unit, and the ACID properties are guaranteed via the two-phase commit protocol.

In IoT systems, the picture is dramatically different, with a massive—and growing—number of data sources; sensors, RFIDs, embedded systems, and mobile devices. Contrary to the occasional updates and queries submitted to traditional DBMSs, data is streaming constantly from a multitude of “Things” to IoT data stores, and queries are more frequent and with more versatile needs. Hierarchical data reporting and aggregation may be needed for scalability guarantees as well as to enable more prompt processing functionality. The strict relational database schema and the relational normalization practice may be relaxed in favour of more unstructured and flexible forms that adapt to the diverse data types and sophisticated queries. Although distributed DataBase Management Systems (DBMSs) optimize queries based on communication considerations, optimizers base their decisions on fixed and well-defined schemas. This may not be the case in IoT, where new data sources and streaming, localized data create a highly dynamic environment for query optimizers. Striving to guarantee the transparency requirements imposed in distributed DBMSs on IoT data management systems is challenging, if not impossible. Furthermore, transparency may not even be required in IoT, because innovative applications and services may require location and context awareness. Maintaining ACID properties in bounded IoT spaces (subsystems) while executing transactions can be managed, but is challenging for the more globalized space [4]. However, the element of mobile data sources and how their generated data can be incorporated into the already established data space is a novel challenge that is yet to be addressed by IoT data management systems.

The following section provides details of some data management solutions for IoT that integrate all or part of the above mechanisms. These proposals are then analyzed in light of a set of design primitives that we deem necessary for a comprehensive data management solution for IoT.

3.1. Data Collection Elements

Sources discovery support: One of the value-added services that IoT is projected to provide is the ability to tap into diverse sources of data that may not necessarily belong to the same IoT subsystem. Therefore, a sources discovery mechanism is needed for IoT applications so that they can announce their service needs and get responses from sources whose data can satisfy these needs. Alternatively, sources can periodically announce their services; the data they can report and produce. An example framework that addresses the discovery of data sources as an integral part of data management is proposed in [11]. The system may discover data sources either via crawling, or via starting with a predefined set of data sources that may later grow as new ones are discovered. Energy-efficient solutions for managing data from mobile data sources were outlined in [12]. Position prediction was used to lower the energy consumption of position tracking technologies, and context monitoring was proposed to reduce unnecessary computations and communication.

Data collection strategy: The collection of data from the “Things” layer may be temporal or modal. Temporal data collection involves collecting data from all “Things” at specified intervals, while modal collection involves collecting data pertaining to specific elements. The variation in data needs that is to be expected in IoT systems may dictate having more than one database schema to accommodate the two data collection methodologies [13].

Mobility support: Mobile devices and entities are a prominent subset of the “Things” in IoT. As they move, they need to still be able to report (and access) data to data stores in a transparent way. Solutions have been proposed for database managements systems that run on mobile devices, which use a session-based synchronization system for data exchange, and store-and-forward mechanisms to facilitate data synchronization [14–16]. Publisher/subscriber-based systems have been proposed for notification-based data delivery from and to mobile devices [17] with considerations for intermittent connectivity [18] and transactions processing [19]. Implementations for such systems are in place for the vehicular [20] and WSN [21] IoT subspaces. However, no clear proposals have been found in the literature that support mobile devices acting as data sources to continuously report/update data to centralized databases, a scenario that would be prominent in IoT. Connectivity abstraction and maintaining the semantic context on the move are the main factors that need to be addressed in order to support mobility in IoT data management.

3.2. Database System Design Elements

Federated architecture: Concepts from distributed and federated database systems can be adapted to the needs of IoT data management. Distributed database systems manage a single database distributed over multiple sites. Federated database systems, on the other hand, manage independent and possibly heterogeneous data stores at multiple sites. In a federated architecture, a site's full autonomy over its data is maintained when it chooses to participate in a database federation, based on that site's operational requirements [10]. If the different subsystems forming IoT are to be viewed as independent “data factories” with autonomous database systems, then it would be interesting to explore the adaptation of query optimization targeted at distributed heterogeneous database systems [22] to the inherently distributed and heterogeneous IoT subsystems.

In addition to federated architectures, there is an increasing trend to build IoT systems around service-oriented architectures [23,24]. Deploying architectures that merge physical “Things” with virtual services requires rethinking communication- and storage-intensive database operations, such as joins and aggregation, to provide interoperability features. Furthermore, novel techniques are needed to join real-time spatio-temporal data residing in lower layers of the IoT network with historical data stored at database servers in higher layers. This may prove especially beneficial in e-Health applications for example; where a patient's historical data can be integrated with their real-time status reports to construct a patient's history.

Data- and sources-centric IoT middleware: There is a need for data-centric middleware between the communication-centric “things” network and the storage-centric data stores. This middleware layer will serve to provide more versatile capabilities for discovering data sources and accessing and analyzing heterogeneous and geographically distributed data [25]. The middleware layer will also target the scalable transfer of large data volume sent from the network to the data stores. There is a need to leverage the full potential of knowledge that can be harnessed from different data sources within IoT by providing the means to discover such sources based on location, modality (i.e., source type) or global query needs that are agnostic to the underlying network.

An architecture that incorporates middleware for data processing in large-scale WSNs to mask network heterogeneity and facilitate data aggregation is proposed in [26]. The core element in this architecture is a virtual sensor that integrates multiple data streams from real sensors in lower layers into a single data stream. Input stream queries are evaluated and the results are stored in temporary relations, and the result of combining these streams is stored permanently only if required, otherwise it is consumed by the application.

Flexible database model: In relational database systems, the principles of atomicity, functional dependency, and normalization are used to define the structure of the relations in a relational database. Database models that depart from the relational model in favor of a more flexible database structure are gaining considerable popularity, although it has been shown that parallel relational DBMSs outperform unstructured DBMS paradigms [27].

Schema support: Database schema formally defines the structure of a database system. In the relational model, schema is defined beforehand as tables and relationships linking those tables, and all data insertions/updates must adhere to that schema. In recent data management solutions that support large and diverse data volumes, it has been customary to go for non-schema solutions to allow for a more flexible structure of the database [28]. There are a number of trade-offs between enforcing a schema and having a non-schema solution. The lack of schema leads to records being parsed at run time, as opposed to load-time parsing that is typical in relational database systems. This causes degradation in performance for non-schema systems, as compression becomes less effective. The lack of schema will also lead to users writing their own parsers, which compromises the interoperability that is desirable for IoT applications. Query optimization is challenging in non-schema systems, because of the lack of knowledge about indices, table partitions and cardinalities, and statistics about data values [27].

Efficient indexing: Indexing is heavily affected by insertion operations and is a primary design element for storage systems. Having multiple indices that are used for different retrieval requirements is essential for the dynamic IoT applications. However, building and storing indexes to facilitate data access and retrieval for the massive volume of streaming sensors data can be prohibitively costly both in terms of the extra storage required and the processing overhead (e.g., slower insertions). Therefore, trade-offs between efficient retrieval and scalable index storage need to be made when developing indexing techniques. Furthermore, dynamic spatio-temporal indexing needs to be adapted for streaming data. Models to achieve this dynamic indexing include sliding windows indexing, multi-granule indexing, wave indices, and the time index model [29].

In [30], dynamic indexing is proposed only for frequently queried data. Intelligent aging mechanisms are used to handle the limited storage space at the sensors, with emphasis on the least valuable or least accessed data. In addition, aggregation and summaries of data can be used to further optimize storage capacity. Proxies that perform intelligent spatio-temporal caching and indexing of results summaries are used to logically unify query views from heterogeneous sensor platforms.

Layered storage platform: Contrary to traditional database systems, where “persistent” data is collected a priori and stored once in centralized or distributed database servers, IoT data is continuously updated as the statuses of things and monitored phenomena change. Even if it was possible for all of the data generated by things at a certain point in time to be stored in permanent storage, it will quickly become obsolete and new data will become available. Stream and real-time databases are not new paradigms [31,32], and their principles were used for environmental sensor networks [33]. However, the design of such systems addresses centralized storage locations, and is not suitable for the scale and distribution of data volumes generated by IoT sources, which requires more than efficient update and access mechanisms [34,35].

Two approaches can be adopted to address the issue of storage locations for IoT data: having each of the systems that make up the IoT use its own dedicated database system, and storing data at the memory units in the objects that generate the data and treat them as a decentralized database. In the first approach, raw or partially aggregated data is moved to aggregation points and mass storage facilities within an IoT subsystem. Having dedicated storage facilities for the different systems forming the IoT poses a number of challenges. Database access issues such as query/transaction processing and concurrency control will need to adopt mechanisms to discover IoT systems with storage facilities, since it is not feasible to provide a finite list of all the systems linked to the IoT infrastructure. The existence of privately-owned IoT systems will dictate a need for credentials management and seamless access permissions. The heavy dependence on the transmission of streaming data from sources to storage facilities will result in high communication costs. This is made more complicated by the need for different communication technologies for different object classes and transmission scenarios.

As opposed to the traditional centralized storage (centralized is meant here as a figure of speech, indicating server-based storage systems; server clusters and distributed storage systems are assumed for large data volumes), emerging trends opt for storing the data as near as possible to its production points—at the objects' memory units [30,36]. This eliminates the need for communications infrastructure to transmit raw data to centralized storage facilities and opts for transmitting only the results if needed. This also leads to enhancements in the timeliness of query processing and response. However, this direction has a number of performance issues that make its full adoption a challenge. The most important of these challenges is the unavailability of scalable storage units in all of the objects involved. Devices have varying capabilities in terms of processing, energy profiles, and storage, with the majority having resource constraints that have led to design optimizations such as the migration of sophisticated processing tasks to upper layers where more powerful devices reside and the miniaturization which allows for very limited storage space. Each device category will have to add metadata describing its data formats for later query optimization and response, which means that query processing and optimization techniques have to adapt to a wide range of data formats that may not be known fully beforehand. Furthermore, the data stored at the things layer will have to be transient; newly generated data will have to replace older data items to accommodate the limited storage capacities. This will limit logging and archiving functions that may be needed later for trend analysis. Trade-offs between centralized and local storage will be subject to the specific application's needs. To address the scalable storage limitations that may result from the increasingly large data volume generated by the “Things”, cloud migration is an emerging trend that is being proposed as a solution [37,38]. Cloud platforms provide an excellent opportunity for data migration from privately-owned servers. This will result in fewer server facilities and a more optimized utilization of energy resources. On the other hand, it should be noted that moving to the cloud will result in increased communication and processing overhead as the cloud becomes smarter.

The work in [30] proposes to move from classical view of sensor data as streams that are continuously filtered and aggregated to a storage-centric view in which sensors are equipped with flash memories and embedded platforms to store data locally at the nodes, thus contributing to reduced communication overhead as query processing migrates to the nodes. A database management system, StoneDB, considers the locally stored sensors data to form a database that can support archival queries as well as mining tasks. Transmission takes place only to communicate queries to the sensory database and results back to the query initiator.

The work in [39] proposes the usage of a customizable data management infrastructure that can be tailored according to the varying requirements of WSNs. Special focus is given to supporting robustness and reliability to handle node failure and unreliable communication, via the use of RAID-inspired distributed data storage in the form of a data storage layer that resides between a WSN and the customizable DBMS. Different roles are used for different data management needs; endpoint sensor storage for storage of simple key-value pairs representing sensor measurements, cluster gateway with SQL support and buffer management for querying WSN data, and data aggregator with advanced data management features such as indexing, buffer management, and possibly security for storage and query processing.

Scalable archiving: Scalable, adaptive, heterogeneous archiving mechanisms are needed for the vast data volumes of IoT, with efficient discovery facilities for retrieval and analysis purposes varying degrees of retrieval frequency. Data expiry schemes need to adapt “usefulness” metrics instead of simple time-centric metrics.

3.3. Processing Elements

Access model: In order to access data, querying languages have been used for relational systems, and later adapted to sensor networks. Structured Query Language (SQL) has been the de facto standard for data access, with standard selection/projection/join/aggregation operations that can be nested for complex queries. Additional constructs have been added to the language in order to accommodate new forms of data, such as TinySQL for sensor networks [40] and StreamSQL for stream processing [41]. As SQL has become too complex due to the continuous extensions as new capabilities are added, developers for the various applications envisioned for IoT will find it hard to learn all of SQL's dialects and tricks while they may need only a subset of them. Therefore, it has been suggested that a more flexible form be used, in which an SQL dialect or predefined configuration is chosen according to the specific requirements of the scenario at hand [42]. Moreover, a shift from modular programming to feature-oriented programming is proposed to customize software that is used to access databases. This enables the development of customizable data management depending on the underlying system's desired features [43,44].

Efficient processing strategy: The two main purposes of collecting data from the “Things” layer in IoT systems are reporting and analysis. Both involve the processing of data at some point in the system in order to aggregate/infer useful information. Determining the location at which data is to be processed in IoT systems is a primary design concern that should take into consideration the decentralized nature of the system and the volume of data produced. Two processing approaches can be deployed for IoT systems: in-network processing and centralized processing. In-network processing involves moving the “program” down to the data and sending only the results back to the user(s), thereby reducing the volume of data that needs to be transported to centralized storage at upper architectural layers in the system. Centralized processing, on the other hand, requires that data—either in its raw form or in an aggregated, more compact form—be transported to persistent storage to enable sophisticated analysis tasks. A hybrid of both techniques can be used for a more flexible processing mode, with varying degrees of customization to accommodate the diverse IoT application needs.

Adaptive query processing and optimization: Query processing is traditionally performed near data stores in order to provide query execution plans, which are basically data-fetching plans. Traditional query optimization involves assigning a cost to each of the different plans for obtaining data in order to choose the plan that is least costly. In the context of IoT, query processing additionally involves finding plans to fetch data from sensors and devices that are geographically distributed and returning aggregate readings as results. Therefore, it requires a large volume of message exchanges that translate into communication overhead. Lowering this overhead involves migrating query processing closer to the lower layer of things, and adopting spatio-temporal optimization to account for localized queries. Query optimization for WSNs has been extensively researched in literature since WSNs are the most prominent subsystem of IoT; an in-depth review can be found in [36].

Query optimization that involves choosing the best query plans based on their respective power costs are explored for WSNs in [45] and database servers in [46]. In [45], sensing and routing data and metadata collection are incorporated into a query optimizer in order to find the best query execution plan with the least energy costs. However, optimization is done for a single query at a time and does not take into account the dynamicity of the network. In [46], basic database operations such as read/write and join operations are assigned power profiles, and a query plan is assigned a power cost as a function of the operations used to execute that query plan. Adapting a similar approach for IoT queries will involve knowledge of the power profiles of intermediate nodes and lower level sensors in order to achieve the full potential of power-optimized query plans for queries that are not limited to data residing offline of servers.

Energy-efficient optimization of multiple queries is explored in ecoDB [47] for distributed large scale database systems. Batch query processing leverages the presence of common components in multiple queries within a processing workload. This is achieved by queuing queries and not executing them immediately. Common sub-expressions that may be present in the queued queries are then merged and executed together. This multi-query optimization achieves savings in energy consumption at the expense of an increased average response time resulting from the explicit delays.

Multi-query optimization was also used for energy-efficient query processing in WSNs in [48]. Two tiers are used to optimize the execution of queries: A base-station tier rewrites a set of queries to produce a synthetic set of queries with redundancies removed and common sub-queries merged. A number of in-network optimizations are then used to optimize the transmission of the query-set results. Three techniques are used to achieve in-network optimization: time sharing between temporal range queries, sharing common readings among similar queries via readings broadcast, and aggregation of results from the sensors responding to the queries to the base-station which has sent the synthetic queries.

Aggregation support: The continuously changing nature of data produced by smart objects makes it unattainable to invest in bulk data collection and storage at one repository as is the case in traditional DBMSs. By the time this is done, data of time-sensitive nature will have expired. Therefore, it is desirable to allow for data storage to take place progressively in real time as data is generated. However, this creates the challenge of transmitting large and streaming volume of data to storage facilities. Aggregation and fusion of sensor data is essential for lowering the communication overhead expected from transmitting raw streaming data. In addition, aggregation and fusion may be requirements for certain applications where raw data storage has no added value. One factor that needs to be taken into consideration is the potential loss of accuracy resulting from dropping underlying detailed data. Therefore, intelligent aggregation should be a design factor for IoT data management.

Energy-efficient aggregation mechanisms that focus on approximate aggregates for Wireless Sensor Networks (WSNs) data are proposed in [49]. Uniform sampling with sample averages is assumed to represent real data averages. Flow-based partial aggregates are distributed among peer nodes that report to the same parent, and the partial aggregate thus moves up the flow until it reaches the query originator. Such technique may be sensitive to packet loss, therefore trade-offs between the rate of aggregation and the communication overhead is needed. Extending the aggregation process into a full implementation of application functionalities on the sensor nodes themselves has been proposed in [50], where an application's operations are decomposed into all exhaustive plans and the plan with the best performance estimates in terms of energy consumption in terms of sensing and computations is considered for execution. There were a number of proposals that addressed the design of comprehensive data management solutions for the WSN subspaces of IoT. Cougar [51] adopts a cross-layer approach to WSNs energy-efficient data management, in which the communication layer adapts to the needs of the data management layer. Cougar treats the sensor network as a distributed database where data collection is performed using declarative queries. A central query optimizer generates efficient query plans aimed at minimizing resource usage within the network for a given query. The sensors sense data and then transmit data matching some criteria to the base-station. The amount of data transferred is further minimized by in-network processing, in which the WSN is logically organized as an aggregation tree, with each node maintaining aggregated results of nodes in the sub-tree of which it is root. Optimal organization of such a tree is query-dependent, and therefore may not be practical for the large-scale IoT network.

In [52], an architecture based on distributed in-network query processing is discussed. Users input SQL-like queries at the server end describing the data needed and how it should be fused. Queries view data produced by a sensor as a virtual table with one column per sensor type. Tables are continuous streams of values, with periodic time-bounded buffering used for querying purposes. Sensors push data to designated view nodes where queries can pull the data or data is pushed further to higher levels in the network. Power consumption is controlled via defining a lifetime attribute for the query, thus giving the user control over the data sampling rate. Intermediate nodes are used to execute partial aggregation and packet merging to lower the communication overhead incurred by the relay of query results. The work is further extended in [40], which proposes TinyDB; a DBMS designed and tailored for the needs of resource-constrained WSN nodes, with a query language specifically designed for querying WSNs. Sensors can determine the time, frequency, and order in which to acquire samples needed to answer queries to achieve minimized energy costs. There are examples for DBMSs customized for subsystems of IoT other than sensor networks. For example, PicoDBMS is a DBMS platform supporting data management functionalities for smartcards [53], while DELite is a data management system that is designed for embedded devices [15]. Both propose special storage mechanisms and query processing customized for the distinct nature of smartcards and embedded systems respectively. However, these solutions rely on the availability of energy supplies from hosting devices (e.g. card readers) and do not address energy efficiency requirements. Based on discussions above, we can summarize the existing data management solutions for IoT or IoT subspaces relative to whether and how they fulfill the aforementioned design primitives, as shown in Table 1.

4.1. Framework Description

The proposed IoT data management framework consists of six stacked layers, two of which include sub-layers and complementary or twin layers. The framework layers map closely to the phases of the IoT data lifecycle described in Section 2, as shown in Figure 3, with lookup/orchestration considered to be an added process that is not strictly a part of the data lifecycle. The “Things” Layer encompasses IoT sensors and smart objects (data production objects), as well as modules for in-network processing and data collection/real-time aggregation (processing, aggregation). The Communication Layer provides support for transmission of requests, queries, data, and results (collection and delivery). The Data/Sources twin layers respectively handle the discovery and cataloguing of data sources and the storage and indexing of collected data (data storage/archival). The Data Layer also handles data and query processing for local, autonomous data repository sites (filtering, preprocessing, processing). The Federation Layer provides the abstraction and integration of data repositories that is necessary for global query/analysis requests, using metadata stored in the Data Sources layer to support real-time integration of sources as well as location-centric requests (preprocessing, integration, fusion). The Query Layer handles the details of query processing and optimization in cooperation with the Federation Layer as well as the complementary Transactions Layer (processing, delivery).

The Query Layer includes the Aggregation Sub-Layer, which handles the aggregation and fusion queries that involve an array of data sources/sites (aggregation/fusion). The Application/Analysis Layer is the requester of data/analysis needs and the consumer of data and analysis results. The layers of the proposed IoT data management framework and their respective functional modules are illustrated in Figure 4, and discussed in the following subsections.

4.2. Comparison of the Proposed Framework to IoT Architecture Reference Model

The IoT Architecture Reference Model (IoT ARM, or IoT-A for short) is a project funded by the European Commission within the Seventh Framework Programme FP7, and aims at defining a reference for building compliant IoT architecture so that new systems and services can be created that interoperate with the IoT ecosystem's existing systems [5]. The ARM defines a reference model that is composed of a number of sub-models. The domain model defines the basic attributes and responsibilities of IoT devices, resources, services, and virtual entities (abstractions of physical sensors into physical devices and units; smartphones, vehicles, patients, etc.) and the relationships between them. The information model defines—on a conceptual level—the attributes and relations of the data that is handled in an IoT system, which includes modeling the information flow and storage and how they are related. The functional model breaks up the IoT architecture into manageable parts, defines their interrelationships, and produces functionalities that can be used to build IoT systems. The communication model defines the communication paradigms that connect entities within the IoT. The trust, security, and privacy model defines concepts related to system dependability and compliance to expected behavior, security of communications, and protection of private data and control of information disclosure within the IoT context.

Of special importance to our work are the information and functional models. Our definitions of data types when discussing the IoT data lifecycle are compliant with the IoT-A definitions of data to be either real-time, summarized or aggregated, inferred by in-depth processing, or reconciled (preprocessed and enhanced) for sophisticated data analysis. The IoT-A functional model breaks IoT functionalities into functionality groups, synonymous to the layered approach we have followed in our framework. The device functionality group maps to our things layer, with possible storage capacities made possible on the devices as we have defined in the things layer. The communication functionality group maps to our communication layer. The IoT service functionality group maps to the data and sources layer in our proposed framework, although our proposed framework details many modules that are abstracted in the IoT-A functional model. The virtual entity functionality group can be mapped to the federation layer in our framework. However, since our framework is data-centric, the virtual entities in the federation can be of a scale bigger than that which is meant by the virtual entities in the IoT-A. The federation layer extends also to the service organization functionality group, which also handles service requests from applications and businesses, and therefore can be mapped to the query layer. We merge the business process management and application functionality groups into the applications/analysis layer, but we do not detail the specifics of this layer as is done in the IoT-A, leaving this as future work. Two functionality groups in the IoT-A—management and security—are only partially addressed in our framework, and further elaboration is intended as future work.

When it comes to data handling, the IoT-A information view that stems from the information model provides a more detailed outlook as to how data is stored. IoT services provide access to data produced within the system, either real-time, raw data (on demand) or higher-level data that has been processed/aggregated. Special IoT services are defined as “history storage”, both at the sensors level and at the virtual entities level, which is analogous to the storage patterns we have included in our framework's thing layer (objects' internal storage) and data layer (repositories/archives). Unlike our use of catalogs and discovery modules to manage the discovery and indexing of data sources, the IoT-A uses service descriptions that are either provided by the IoT services themselves or by special management components in order to make the services visible and discoverable within the IoT system. A service resolution component is responsible for service discovery, which is similar to what our proposed framework provides in the sources layer. Information flow follows three exchange patterns similar to what we have defined in the IoT data lifecycle; namely, the data push, the request/response, and the subscribe/notify patterns.

4.3. Illustrative Use Case

An IoT-empowered mobile health (m-health) system would have wearable or implanted health monitoring sensors (devices, things) on the patient (an abstracted virtual entity), which report on the patient's vital signs and possibly track her/his whereabouts as her location changes, either indoors or outdoors (push exchange pattern). These sensors are connected wirelessly to concentration points for periodic data collection/reporting (aggregation). The patient's smartphone can be such concentration point, and it can also interact with and control the patient's surrounding environment (e.g., home/hospital apparatus, bus chairs, sensors on a sidewalk). Vital readings that are collected periodically by the smartphone are reported wirelessly to the respective caregiver's network (communication) and stored in the patient's respective health records in data repositories (data layer repositories). Emergency or abnormal events concerning the patient are also reported back to the caregiver's data repositories and the caregiver is alerted for proper assessment and response (notification exchange pattern). If the patient experiences a severe health condition while driving for example, smart vehicles can “sense” such a condition and report it to the nearest emergency unit (enabling federation of patient data and vehicle data). Information analysts at the hospital have access to the patients' information included in data repositories and can profile and assess a single patient's condition based on his history (query, application/analysis). They can also analyze the collective patients' health profiles in order to find or infer interesting patterns related to possibly spreading health conditions, such as post-op infection incidents related to operations performed at that given hospital. The scale of analysis can be further widened to include health records that are accessed via the Internet on a city-wide, state-wide, country-wide, or even world-wide scale (sources discovery, then data federation). This can serve to identify the existence of epidemics or seasonal symptoms, as well as visualize their spread rate, patients' severity levels, and locale. This can help in the prompt containment of life-threatening conditions. On a short-term scale, findings of such analysis could initiate a series of commands back to individual patients' smart environments in order to provide proper isolation and/or decontamination (transaction management as a series of commands executed as one unit). Longer-term uses of analysis findings can drive future health care policies and deployment strategies.

This example highlights a data-intensive environment in which the availability of data for large-scale analysis is pivotal in discovering valuable knowledge that can shape strategic action plans. The various levels of data availability (single patient, patients at a single hospital, patients at certain localities) are made possible in the framework since there are three levels of data collection and processing: single data source, single data site with multiple sources, and a federation of data sites/sources. In addition, the real-time and offline processing modes of data are supported via in-network processing as well as on-site/federated analysis. The system is flexible in the sense that as new sources of data become available (e.g., new patients, new hospitals, new localities), they can be seamlessly merged into the existing system, because it supports federation rather than rigid structure. It is not mandatory that a certain level of data availability be the exact aggregate of all sub-levels; analysis of data about a certain municipality, for example, does not require all data from hospitals within that municipality. Overall, the framework's separation of data and processing, and the framework's support for various levels of availability, allow for various processing needs to be addressed by different entities with varying degrees of flexibility.