Communication Efficient Spatial Search in a Sensor Data Web Portal

[0001] Over the past several years, there has been a proliferation of sensor network deployments into our environments. Sensors in such networks capture data pertaining to weather, traffic, parking, security, real-time views, and many other data items and conditions.

[0002] The sensor data portal model has been designed to expose the data for search and querying by a general audience. Sensor data web portals enable browsing of disparate collections of sensor networks. Such portals function as a rendezvous point for sensor network administrators to publish their data, and through which a large base of users may pose individual queries to the sensor network. Thus, the sensor data web portal provides a platform with which users can interact and visualize content being generated by autonomous sensor networks.

[0003] However, sensor data web portals commonly experience time delays due to the continuously changing nature of sensor readings and unavailability of data. Therefore, there remains a need to improve the way sensor data is collected and presented to users via a web portal.

[0004] This summary is provided to introduce simplified concepts relating to spatial searches, and these concepts are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

[0005] Techniques for collecting and displaying sensor data captured by a spatially representative sample of sensors requested in a search query are described. The sensors are represented in an index structure (e.g., a data tree). In response to the search query, the index structure is leveraged to identify a subset of sensors that exhibits a similar spatial distribution to the original full set of sensors. Sensor data is then collected from the subset of sensors by probing the sensors, or retrieving recently cached data located by the index, and finally returned to satisfy the query. In this manner, the number of sensors to be probed is reduced, thereby reducing latency involved with polling a large number of sensors and making the search process more efficient.

[0014] This disclosure is directed to techniques for conducting a spatial search for sensor data using a sensor data web portal. The portal provides users with continuous access to sensor readings obtained from various sensors spread throughout disparate sensor networks. Users specify certain spatial regions from which they wish to receive readings, and a summarization of the sensor readings satisfying these conditions is produced and returned, rather than values from individual sensors. The summarization may be performed in many ways, including by simple aggregates such as an average value over groups of sensors in the query region, a maximum value, a minimum value, or sum of the values.

[0015] Generally, query processing in the sensor portal involves two high-level components: (1) a portal web service to facilitate query processing and (2) a backend database to maintain sensor metadata and provide core search functionality. In this architecture, data is not maintained in any persistent archive, but is instead collected in an on-demand fashion during query processing. First, a portal service translates any queries issued by clients into a sequence of declarative queries. The first query asks the backend database to determine a set of relevant sensors. The database processes the queries by inspecting the sensor locations it maintains. Upon receipt of a list of sensors, the web service first checks a cache to ascertain whether there is any recent and current sensor data that can be returned to satisfy the query. If fresh data in the cache is not sufficient to answer the query, the web service polls the sensors for updated readings and issues a second query to the database to insert the new readings into the cache maintained in the backend. The web service then queries the database for all relevant readings from its cache, presenting the results to the user. Moreover, the backend database may routinely poll sensors as data in the caches become stale. This polling may occur responsive to a search query or as part of a separate process. The polling is thus conducted in a manner transparent to the user, as the user merely submits a query and receives results from the web portal.

[0016] One challenge for the data portal is to provide timely processing of user queries using a data collection mechanism that efficiently retrieves readings from the sensor networks, with large numbers of sensors and large volumes of queries present in the system. The techniques described herein address this challenge by providing a layered sampling algorithm that facilitates probing of random subsets from the complete list of sensors relevant to a query. Layered sampling leverages the index structure to produce a random subset of sensors that exhibits a similar spatial distribution to the original full set of sensors. By reducing the number of sensors to probe, the latency involved with polling a large number of sensors is reduced, thereby making the process more efficient.

[0017] The techniques described herein may be used in many different operating environments and systems. Multiple and varied implementations are described below. An exemplary environment that is suitable for practicing various implementations is discussed in the following section.

[0018] Exemplary systems and methodologies for obtaining the sensor data from various sensors through the sensor data web portal are described in the general context of computer-executable instructions (program modules) being executed by a computing device such as a personal computer. Program modules generally include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. While the systems and methods are described in the foregoing contexts, acts and operations described hereinafter is implemented in hardware or other forms of computing platforms.

[0019] Exemplary Environment

[0020] FIG. 1 illustrates an exemplary architecture 100 in which a communication efficient spatial search sensor data web portal may be implemented. Architecture 100 is shown in a client-server environment where a server 102 receives queries from any number of client devices 104-1, 104-2, and 104-3 (collectively referred to as devices 104) over a network 106. The queries contain requests for sensor data from sensors in distributed sensor networks. Server 102 processes the queries by employing a sensor index maintained locally or on a remote storage 108 that is accessible over network 106. After processing, server 102 returns results to the client devices 104.

[0021] Server 102 may be implemented in many ways including, for example, as a standalone general purpose computing device or mainframe, or as a cluster of servers (e.g., arranged in a server farm). Client devices 104 may be implemented in any number of ways including, for example, as general purpose computing devices, laptops, mobile computing devices, PDAs, communication devices, GPS-equipped devices, and/or so on. Network 106 may include, but is not limited to, a Local Area Network (LAN), a Wide Area Network (WAN), and a Metropolitan Area Network (MAN). Further, network 106 is representative of a wireless network, a wired network, or a combination thereof. Storage 108 may be implemented in any number of ways, including as a remote database server or as an accessible networked storage device, such as a RAID system or the like.

[0022] Server 102 includes one or more processor(s) 110 coupled to a system memory 112. Processor(s) 110 may include, for example, microprocessors, microcomputers, microcontrollers, multi-core processors, and so forth. The processor(s) 110 are configured to fetch and execute computer-program instructions stored in system memory 112. System memory 112 includes computer-readable media in the form of volatile memory, such as Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash RAM.

[0023] Server 102 hosts a web portal 114 that facilitates user access to sensor data obtained from the various sensors. The web portal 114 provides a user interface (UI) that may be rendered on client devices 104 to support submission of user queries for sensor data and presentation of results. One example UI 116 is illustrated as a browser-rendered graphical UI titled “SensorMap” on client device 104-1. UI 116 allows users to specify spatial regions to identify a collection of sensors from which they wish to receive readings. The sensors may be of any type including, for example, temperature sensors, video cameras, humidity sensors, wind sensors, traffic sensors, parking sensors, security sensors, and so on. In FIG. 1, representative sensors include a temperature sensor 118-1, a camera 118-2, a video camera 118-3, and any other sensors 118-4 (collectively referred to as sensors 118).

[0024] Upon receiving a query submitted by a client device 104, server 102 analyzes and translates the query into a sequence of declarative queries that may be used to identify a set of sensors that can contribute to the sensor data requested by the user. Server 102 implements a query processing module 120, which is stored in system memory 112 and executed by processor(s) 110. To aid in identifying the appropriate set of sensors to respond to the user's query, query processing module 120 discovers attributes of the set of sensors. The attributes may include, for example, sensor location in terms of latitude and longitude, type of sensor, schemas for sensor readings, and so on.

[0025] In one implementation, query processing module 120 ascertains sensor attributes from a database 122, which is illustrated as being stored in remote storage device 108 (although it may be stored in other locations, such as within system memory 112). Database 122 stores an index of the sensors, and the index maintains metadata describing the attributes of the sensors. Server 102 has an indexing module 124 stored in system memory 112 and executable on processor(s) 110 to create such index structures. In one implementation, the index is structured as a data tree having plural nodes arranged in layers. More particularly, the tree may be configured as a Collection R-Tree (or “COLR-Tree”), which is a spatial index built according to the techniques described herein, but loosely based on a classic R-Tree structure. One example technique of creating a COLR-Tree structure is described below in more detail with reference to FIGS. 3 and 4.

[0026] Once the set of sensors are identified, the appropriate sensors are polled and updated readings are inserted into the database. Caches may be maintained within the indexing tree to hold the data. The collected updated readings may then be retrieved from the database and presented to client devices 104 using the UI 116.

[0027] To illustrate this architecture 100, consider the following example. Suppose a user at client device 104-1 wants to know the temperature at a specific geographic location. The user submits a query for the temperature at the target location using UI 116 rendered on client device 104-1. Server 102 receives the query and query processing module 120 examines the query to determine the latitude and longitude of the target location. Subsequent to examination, query processing module 120 reviews the data tree stored in database 122 to identify a set of sensors having latitudes and longitudes within the target location. Upon identifying the set of sensors from various sensor networks, query processing module 120 probes the set of sensors to obtain updated sensor readings, including temperature data. The updated sensor data is then formatted and presented to the user through UI 116.

[0028] Although the sensors 118 are shown accessible by server 102, the sensors 118 may be accessible directly by remote storage device 108. This allows the sensor metadata to be stored directly in database 122 in response to probing the sensors by indexing module 124. The sensor metadata stored in remote storage device 108 is then indexed to form the data tree.

[0029] FIG. 2 illustrates the sensor search user interface (UI) 116 in more detail. In this example, search UI 116 is configured in the environment of depicting geographic locations of sensors within a certain region. Although not illustrated in this rendering, the UI 116 allows the user to draw arbitrary polygons to specify a search region. Thus, the user can form a box or rectangle, for example, around a portion of the map displayed in UI 116 to designate an area of interest. Alternatively, the user may specify a search region by entering search keywords (e.g., “Seattle”, “King County”) or by entering phrases or sentences (e.g., “weather in Seattle”, or “What is the traffic on I-90 and I5 interchange?”). Once the user submits the query, server 102 collects the appropriate data and returns it to UI 116 for depiction in a results pane 202. In this illustration, a regional map of the cities of Seattle and Bellevue in Washington State is shown in results pane 202, as well as various freeways and highways within this region. It should be noted that the sensor search UI 116 may be implemented in other environments, and display results of searches in other formats, including non-graphical and non-geographical presentations.

[0030] Next to the results pane 202 in search UI 116 is a control panel 204 that enables a user to refine the search or navigate throughout the results. In the illustrated implementation, control panel 204 has a sensor selection area 210, a view name entry area 212, and location viewing controls 214. Sensor selection area 210 provides various options that allow a user to define which sensor types to display in results pane 202, since there may be many types of sensors located throughout a region. Representative sensors shown in sensor selection area 210 include options for temperature sensors 220, video or web cameras 222, weather sensors 224, traffic sensors 226, parking sensors 228, and other generic sensors 230. Here, the user may check a corresponding box to have the sensor type displayed. The sensor types selected by the user are then represented by graphical icons on the map in results pane 202.

[0031] View name entry area 212 enables the user to name the search results view. Upon entry of the name, the user may actuate a control (e.g., “Save View” button or return key) to save that name. Once a particular search is named, the user may quickly rerun future searches for the same sensor data by simply selecting the view name. This is useful, for example, for the user who might like to know traffic conditions on a daily basis for the morning or evening commutes.

[0032] Location viewing controls 214 facilitates user navigation through various locations within the region in results pane 202. Viewing controls 214 also provide additional control features (i.e. panning and zooming) to view sensors in each of the locations. Thus, the user may be provided with a facility to identify sensor densities (i.e. number of sensors) and types of sensors at different locations, thereby enabling the user to make a decision for selecting sensors prior to posting a request for sensor data.

[0033] Control panel 204 further allows users to refine the search. Notice, for example, that there may be a high density of sensors in certain key areas of the region, such as at freeway interchanges. A user may want to know the traffic status at a particular stretch of freeway within the region depicted in results pane 202. Control panel 204 can be used to navigate through the location to find the stretch of road, limit display of only traffic sensors 226, and then ascertain the traffic sensor density (i.e. number of traffic sensors present in the particular location). A facility may be provided to identify locations of the traffic sensors 226 (i.e. latitude and longitude of locations of traffic sensors) within the target freeway or a list may be provided to allow the user to choose specific sensors along this stretch of road. Upon identifying target sensors, a new query may be submitted and processed to collect data only from the specified traffic sensors 226.

[0034] In one implementation, UI 116 enables the user to specify freshness constraints of the sensor data in terms of how stale (or how recent) the sensor data is to be acceptable. For example, the user may specify that that sensor data older than a particular time period (e.g., 10 minutes, 1 hour, 1 day, etc.) may not be acceptable. Thus, the user can obtain the latest sensor readings from all the locations.

[0035] Exemplary Server Implementation

[0036] FIG. 3 shows certain functional aspects of server system 102 in more detail. As noted earlier, server system 102 includes processor(s) 110 and system memory 112. Server system 102 further includes network interfaces 302 to provide connectivity to a wide variety of networks, such as network 106, and protocol types such as wire networks (e.g., LAN, cable, etc.) and wireless networks (e.g., WLAN, cellular, satellite, etc.). Input/output interfaces 304 provide data input and output capabilities for server system 102. Input/output interfaces 304 may include, for example, a mouse port, a keyboard port, etc.

[0037] System memory 112 stores program modules 306 and program data 308. Program modules 306 include, for example, a web portal 114 and other application program modules 310 (e.g., an Operating System (OS) to provide a runtime environment, networked communications between multiple users, and so forth).

[0038] Web portal 114 has several responsibilities including acting as a front end or proxy to the sensor networks, performing the data collection by communicating with the sensor networks, and initiating query processing by the backend database by performing query translation. Web portal 114 also presents query results back to the client interface, such as through UI 116. The presentation of results typically includes aggregating sensor readings, since the user is usually not interested in visualizing the results of every single sensor node, especially in regions with a high sensor density. In one implementation described below in more detail, the choice of sensors over which to aggregate is decided dynamically using a pixel-based clustering algorithm that groups sensors lying within a distance corresponding to an n×n block of pixels (where n is a system parameter, but is typically small such as 5×5).

[0039] As noted earlier, system 102 may be employed for identifying, capturing, and indexing the metadata associated with external sensors 118 of various sensor networks as well as for subsequently providing and presenting desired sensor data specified by a user via a UI 116. As such, web portal 114 includes a query processing module 120 to handle user queries, an indexing module 124 to index the metadata into a structure, and a data acquisition module 312 to acquire data from the sensors. In the following discussion, components of the server system 102 used to identify and index the sensor metadata are described first, followed by an explanation of components involved in presenting desired sensor data specified by a user.

[0040] Server system 102 collects and stores metadata received from external sensors 118 of various sensor networks. The metadata may be provided and registered by sensor network administrators. The metadata may include, for example, locations of external sensors 118 and schemas that define how sensor readings are formatted and how to retrieve that information. From the metadata, indexing module 124 creates an index structure, such as data tree(s) 314, and stores that data trees) 314 as program data 308 in system memory 112.

[0041] In one implementation, indexing module 124 is configured to cluster nodes in data tree(s) 314 into groups of nodes such that the tree has a hierarchical structure with one or more layers. More specifically, indexing module 124 includes a clustering module 316 configured to cluster the metadata of sensors 118 into various groups of metadata based on various factors, such as sensor location and sensor type. Subsequent to creating the groups, clustering module 316 constructs layers of the groups of nodes to form data tree(s) 314. Each layer includes multiple nodes, and individual nodes store metadata of corresponding external sensors 118. This process may be performed on a layer by layer basis, where each layer is created successively beginning with the lowest layer. Within the hierarchical arrangement, the nodes may be said to include parent nodes associated with external sensors 118 and child nodes associated with locations of external sensors 118. Further, each node of data tree(s) 314 is provided with associated caches to store sensor readings collected from the respective external sensors 118. As an alternative, indexing module 124 may allocate a single cache for a layer of nodes in data tree(s) 314.

[0042] FIG. 4 shows one example structure of data tree(s) 314 in more detail. Data tree(s) 314 has multiple layers of nodes 402-418. Each node is associated with at least one external sensor 118. As shown, data tree(s) 314 has a top layer with a parent node 402 corresponding to a main sensor in a sensor network. Parent node 402 is illustrated with two child nodes 404 and 406 that form a middle layer. These middle-layer child nodes 404 and 406 may each have one or more children, as represented by two sets of three child nodes in which nodes 408, 410, and 412 are children of node 404 and nodes 414, 416 and 418 are children of node 406. These last nodes 408-418 form leaf nodes of the data tree(s) 314 in that there are no further child nodes dependent from them. The leaf nodes 408-418 form a bottom layer of the tree.

[0043] Each node in each layer of data tree(s) structure 314 has an associated cache to store sensor readings obtained from external sensors 118. During a process of collecting sensor readings, sensor readings from a plurality of external sensors 118 are stored in the caches associated with leaf nodes 408-418. Further, nodes 404 and 406 of the middle layer may store a processed version of the sensor readings of respective child nodes. For instance, node 404 stores a processed version of the sensor readings stored in child nodes 408, 410, and 412. The processed version may be an average of the sensor readings. Further, root node 402 at the upper layer may store data obtained by processing the sensor readings stored in child nodes 404 and 406 in the middle layer, such as averaging the sensor readings in nodes 404 and 406.

[0044] In one implementation, the data tree(s) structure 314 is configured as a Collection R-Tree (or “COLR-Tree”), which provides a spatial index of sensors in the sensor networks. Each layer 0, 1, 2 in the data tree(s) 314 has an associated table, as represented by table 420 for layer 2 and table 422 for layer 1. The layer tables 420 and 422 have columns representing an identifier for a parent node, an identifier for a child node, and any metadata corresponding to that child node. Here, the metadata is spatial metadata indicating a bounding box in terms of (x, y) coordinates of the child node and the number of sensors below the child node. Notice that the bounding box of the root node 402 is roughly the combined size of the boxes for the leaf nodes 408-418 descendant from the root node 402. The bounding boxes represent geographical regions within which sensors associated with the nodes are positioned. Thus, the root node 402 contains sensor data that is an aggregate (e.g., average) of data obtained from multiple sensors in lower layers.

[0045] There is one row in the layer tables for each child node. Layer tables 420 and 422 are associated with each other in that child identifiers in an upper level layer table are present as node identifiers in a lower level layer table. The data tree(s) 314 is traversed by obtaining following successive child identifiers through the layer tables 420 and 422. Each layer table has a corresponding cache table, as represented by cache tables 424 and 426. Each cache table stores cached sensor readings of nodes within the layer. Cache tables 424 and 426 contain a node ID, a value representing the (possibly aggregated) reading, a slot ID, and the number of descendant leaves in the subtree.

[0046] The data tree(s) 316 (COLR-tree structure) may be constructed by indexing module 124 in a bottom-up fashion from the lower layer of nodes to the upper layer. In one approach, indexing module 124 clusters sensor metadata using a k-means clustering technique (i.e., an algorithm to cluster objects based on attributes into k partitions or clusters) based on the geographic proximity of the sensors. This process is repeated to construct the data tree(s) 314 one layer at a time, terminating at the construction of a single cluster which becomes the root of our index.

[0047] In another implementation, clustering module 316 constructs multiple data tree(s) 316 simultaneously. Further, one or two sets of data tree(s) 314 may be linked to each by clustering module 316, assuming a relation between the sets of data tree(s) 316 may be identified.

[0048] After data tree(s) 314 has been constructed and stored, system 102 is ready to accept queries and process those queries to return sensor data requested by the users. User input queries are received from client devices 104 over the network via network interfaces 302, or obtained from input/output interfaces 304, and are passed on to query processing module 120 for processing. Input queries 318 are shown stored as program data 308 in FIG. 3 and accessible during processing. Query processing module 120 examines input queries 318 to identify a target data tree that has a set of external sensors 118 that are likely to satisfy information specified in input queries 318 by the users. The information may include, for example, location of sensors 118, spatial properties of external sensors 118 (i.e. spatial skewed distribution of sensors in each sensor networks or angle of location of the sensors), number of sensor readings, and so forth.

[0049] Once a target data tree is identified, query processing module 120 identifies a set of external sensors 118 represented by nodes within the data tree(s) 314. In one implementation, query processing module 120 employs a sampling module 320 to conduct a layered sampling process that leverages the index structure of the target data tree to produce a random subset of sensors with a similar spatial distribution to the original set of sensors. As a result, the sampling process reduces the number of external sensors 118 to be probed for sensor readings, and yet still provide an accurate response to user queries (i.e. input queries 318). Thus, the sampling process reduces the communication cost and end-to-end latency in providing the sensor data from the time of receipt of input queries 318 by system 102.

[0050] Generally, layered sampling allows siblings in the data tree(s) 314 to independently choose samples from their descendants. A user specifies a sample target size (i.e., the number of sensors to be read). Starting at the root node, with the user-specified sample target size, the sampling module 320 first examines the cache tables at each layer to determine whether current data exists. Depending upon the data in the cache, the sampling module 320 decides how many additional samples are needed. Thereafter, the sampling module 320 traverses through the target data tree, descending along nodes relevant to the query and splitting the target size amongst the child nodes. Thus, each child node is asked to return a sample smaller than the original target size, so that consequently when the samples from each child node are combined, the original size goal is met. The sampling traversal terminates when a node is assigned a target size smaller than a value of one.

[0051] More particularly, in the present implementation, sampling module 320 may assign a target size at a node as ‘r’ and define a target size at one of its child nodes as ‘r_i’. The target size of the child nodes may be computed as:

$\begin{array}{cc}{r}_i=r\times \frac{w_i}{\sum _iw_i}& \left(1\right)\end{array}$

where ‘w_i’ is a number of sensors that are descendents of child node ‘i’ of the current node (parent node or root node of the data tree). Thus, the above equation (1) denotes that the sample target size is divided and allocated to each sensor present at the branches of the current node. Such allocation process results in the identification of a smaller sample of nodes associated with lesser number of sensors than a desired number of external sensors 118. This smaller sample of nodes is sent to data acquisition module 312 for probing the sensors to collect the sensor readings. The sensor readings collected are stored into caches of respective nodes and displayed to the user on UI 116 through display devices 324.

[0052] For example, sampling module 320 may need to identify a set of prominent temperature sensors from a location having high density temperature sensors (i.e. higher number of temperature sensors). Sampling module 320 may review the target data tree and distribute the target size specified by the user amongst the nodes on a layer by layer fashion. Implementation of such a process results in the elimination of nodes having target sizes less than one. Thus, the sensor data may be collected from a set of sensors having fewer sensors, thereby reducing a time delay in collection and presentation to the user. In such a scenario, a user may prefer to obtain the sensor data at a shorter time interval.

[0053] In one exemplary implementation, sampling module 320 may be configured to eliminate some child nodes that may not possess any sensor readings that can contribute to the sensor data. In such a case, sampling module 320 may allocate a larger fraction of the sample target size to each child node. Thus, the larger fraction of the target size assigned to the child nodes can be computed as:

$\begin{array}{cc}{r}_i=r\times \frac{w_i}{\sum _iw_i\times \left[\mathrm{overlap}\left(\mathrm{BB}\left(i\right),q\right)\right]}& \left(2\right)\end{array}$

where ‘w_i’ is a number of sensors that are descendents of child node ‘i’ of the current node, ‘overlap’ denotes an indicator function that represents a maximum number of nodes in the target data tree that may satisfy the query rather than the total number of sensors descending the current node.

[0054] For example, sampling module 320 may split the target size of temperature sensors (i.e. for a specified temperature data in a location) unequally amongst the child nodes by assigning a larger target size and a smaller target size to higher weighted nodes and lower weighted nodes, respectively. Such a process may be implemented to further reduce the number of sample sensors by eliminating the sensors that may not overlap with the user's query (i.e. may not contribute to the user's query) thereby reducing the end-to-end latency. Thus, a smaller sample of nodes determined by the above reduction process is send to data acquisition module 312 for probing the sensors to collect the sensor readings. The sensor readings collected are stored into caches of respective nodes and displayed to the user through UI 116 on client devices 104 or on other display devices 324.

[0055] In yet another implementation, child nodes possessing sensor readings in the cache, stored during any of the previous traversals through the target data tree by sampling module 320, may be eliminated to reduce the number of sample sensors. In such a scenario, sampling module 320 may deduct the child nodes having the sensor readings in the cache. Thus the target size of the child nodes ‘i’ can be computed as:

$\begin{array}{cc}{r}_i=r\times \frac{w_i-c_i}{\sum _iw_i\times \left[\mathrm{overlap}\left(\mathrm{BB}\left(i\right),q\right)\right]}& \left(3\right)\end{array}$

where ‘w_i’ is a number of sensors that are descendents of child node ‘i’ of the current node, ‘overlap’ denotes an indicator function that represents a maximum number of nodes in the target data tree that may satisfy the query rather than the total number of sensors descending the current node and ‘c_i’ denoting the sampling weight. The sampling weight corresponds to an aggregate of the values of number of sensors having the sensor readings pre-stored in the cache.

[0056] For example, upon traversing through the target data tree to identify a set of temperature sensors, sampling module 320 may determine the nodes having the latest temperature readings stored in the cache. In such a case, nodes associated with the set of temperature sensors may be deducted from the number of nodes that are descendants of a child node of the any of parent nodes associated with the set of temperature sensors. Thus, a smaller sample of nodes determined by the above reduction process is send to data acquisition module 312 for probing the sensors to collect the sensor readings. The sensor readings collected are stored into caches of respective nodes and displayed to the user on UI 116 through display devices 324.

[0057] In one exemplary implementation, sampling module 320 may determine the smaller sample of nodes by performing all the techniques simultaneously, as described above according to equation (1), (2) and (3) thereby reducing the end-to-end latency. Further, it may be noted that sampling module 320 can determine the smaller sample of nodes employing the techniques as described in equation (1), (2) and (3) in various combinations.

[0058] Operation

[0059] Exemplary processes for operating a sensor data web portal to conduct communication efficient spatial searches for sensor data are described in this section with additional reference to FIGS. 1-4. FIG. 5 provides an overview of performing communication efficient spatial searches, while FIGS. 6 and 7 offer more detailed implementations of creating an index of sensors and processing queries using the index. The exemplary processes may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, and the like that perform particular functions or implement particular abstract data types. The processes may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.

[0060] FIG. 5 illustrates a general overall process 500 for performing communication efficient spatial searches for sensor data based on a user's query. The process 500 is illustrated as a collection of blocks in a logical flow graph, which represents a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the blocks represent computer instructions that, when executed by one or more processors, perform the recited operations. The order in which the process is described is not intended to be construed as a limitation, and any number of the described blocks can be combined in any order to implement the process, or an alternate process. Additionally, individual blocks may be deleted from the process without departing from the spirit and scope of the subject matter described herein. For discussion purposes, the process 500 is described with reference to environment shown in FIG. 1 and system 102 shown in FIG. 2.

[0061] At 502, an index of geographically-distributed sensors is constructed and stored. In one context, the sensors capture data pertaining to weather, traffic, parking, security, real-time views, and so forth. In building this index, a sensor registration process may be conducted, where sensor network administrators provide metadata including sensor locations and schemas of sensor readings. The metadata may include, for example, sensor location, type of sensor, schema for sensor readings, and so forth.

[0062] In one approach, index construction is initiated with the hierarchical clustering algorithm described above, which constructs one layer of the index at a time from the metadata. According to one implementation, the index is formed as a data tree with multiple layers of nodes, where individual nodes are associated with caches to store metadata of external sensors 118. One example data tree(s) 314 is shown in FIG. 4. The administrator may modify the index by eliminating certain sensors which may not be deemed useful, or alternatively may specify a selected number of sensors for any particular location.

[0063] At 504, a query for sensor data is received. The query may be submitted by users via UI 116 on client devices 104 and routed to server 102 via network 106. Query processing module 120 may review the query to identify certain information, such as location of sensors, number of sensors (i.e. external sensors), and so forth. The query may further include the identity of certain external sensors 118 or indicate a physical boundary of a particular area in which the sensors exist. For example, if the user is interested in a location with a high density of traffic sensors, the user may input a geographical range within which traffic sensors may be sampled.

[0064] At 506, a subset of the sensors from which to obtain data that would satisfy the query is identified using the index. In one implementation, the smallest possible number of nodes is determined. The number of sensors in the subset may be specified in the user query, or chosen by the system administrator as a controllable parameter. The sensors forming the subset are then selected randomly from the index to exhibit a spatial distribution similar to the complete set of sensors.

[0065] At 508, sensor data is obtained from the subset of sensors. The sensor data may be retrieved from caches associated with the sensors, or alternatively data acquisition module 312 may poll the subset of sensors and collect updated sensor readings on demand.

[0066] At 510, the sensor data is formatted and presented to the user in a manner responsive to the user query. The sample sensor data may be displayed through UI 116, as shown in FIG. 2.

[0067] FIG. 6 illustrates an exemplary process 600 for creating a data tree in more detail. At 602, sensors to be included in an index are identified. This may be accomplished through a registration process, for example, where sensor network administrators register sensors with the web portal. The administrators may submit metadata on the sensors including sensor type, location, schemas, and so on.

[0068] At 604, sensors to be represented in the index are clustered together to form groups. In one implementation, clustering module 316 runs a clustering algorithm to form the groups of sensors. The clustering may be based on one or more criteria, such as sensor type, location, and so forth. As shown in FIG. 4, for example, clustering module 316 creates a bottom layer (i.e., layer 0) of all possible sensors to be represented by the index. The clustering process may then be repeated to form successively higher layers up to top layer with a single root node.

[0069] At 606, various groups of sensors that may be interlinked in some manner are identified. As one example, external sensors 118 located in smaller areas within a particular location may be aggregated to form a group.

[0070] At 608, the various groups of sensors can be combined to form new larger groups of sensors. In one technique, a clustering algorithm employs a pixel-based clustering algorithm that enables grouping of sensors lying within a distance corresponding to an n×n block of pixels, where n denotes a system parameter (e.g., 5×5). Various groups of external sensors 118 are reviewed by clustering module 316 using the pixel-based clustering algorithm to determine whether distances between groups of external sensors 118 tallies with a distance of an n×n block of pixels. If found that the distances tallies, the groups of external sensors 118 can be associated with one another to form new groups of external sensors 118.

[0071] At 610, one or more data trees are formed from the groups of sensors including newly combined groups. The data trees are created by clustering module 316 and stored in database.

[0072] FIGS. 7A and 7B illustrate an exemplary process 700 for processing a query for sample sensor data. At 702, a query for sample sensor data is received from a user. The query may be received by query processing module 120, which identifies a set of constraints specified by the user. The constraints may include a number of external sensors 118 that to be probed to obtain sensor readings corresponding to the sample sensor data.

[0073] At 704, a target size of how many external sensors should be probed to retrieve the desired sensor data is determined. The target size may be specified in the input query, or it may be a parameter specified by the system administrator. It may also be inferred or calculated based on information provided in the query.

[0074] At 706, a determination is made whether the target size needs to be distributed among a group of multiple nodes of the data tree. If so (i.e., the “yes” path from block 706), the target size if divided into parts and nodes from a top to bottom layer are assigned a smaller target size at 708.

[0075] If the query does not include any information regarding dividing target size (i.e., the “no” path from block 706), a determination is made whether nodes deficient of sensor data corresponding to the requested sensor data should be eliminated. The query processing module may review the query to identify whether the user has specified to eliminate such nodes. If specified (i.e., the “yes” path from block 710), such nodes are eliminated from the group of nodes of the data tree at 712.

[0076] If the query does not specify the elimination such nodes (i.e., the “no” path from block 710), a determination is made whether any cached sensor data would satisfy the query at 714. If such cached data exists (i.e., the “yes” path from block 714), such nodes can be excluded from the group of nodes in the data tree which will be probed at 716. Conversely, if the query does not specify elimination of such nodes (i.e., the “no” path from block 714), the subset of nodes from which to provide the sensor data are identified and the corresponding sensors are probed at 718. The data may then be returned to the user, such as via UI 116.

[0077] Conclusion

[0078] Although embodiments of techniques of identifying and displaying a sample sensor data based on a user's query have been described in language specific to structural features and/or methods, it is to be understood that the subject of the appended claims is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as exemplary implementations techniques of identifying and displaying a sample sensor data based on a user's query.