WISE: A Web-based Intelligent Sensor Explorer
Framework for Publishing, Browsing, and Analyzing
Sensor Data over the Internet
Kien A. Hua, Rui Peng, and Georgiana Hamza-Lup
School of Computer Science, University of Central Florida
Orlando, FL 32816, U.S.A
{Kienhua, Rpeng, Ghamza}@cs.ucf.edu
Abstract. In this paper, we present an Internet-scale framework for publishing,
browsing, and analyzing real-time sensor data. Existing work assumes a known
set of sensors, deployed for a specific application, intended for a group of users
who are aware of the application. In contrast, WISE provides a new
environment for publishing real-time sensor data, and sharing sensor-based
applications with unsolicited users over the Internet. It enables providers to
advertise their sensors using a Sensor Data Description Advertisement. Any
user can search relevant sensors over the Internet using a scalable peer-to-peer
search mechanism. Once the desired sensors are located, the user can employ
two new communication protocols, namely SSCP and SSTP, to remotely
control the incoming sensor streams. As the data arrive at the user browser
software, a corresponding plug-in such as a data animation module is activated
to allow the user to “see” the data stream presented in an intelligible way.
1 Introduction
Nowadays pervasive sensing systems ranging from short-range wireless ad hoc sensor
networks to more powerful capture devices such as video cameras are becoming a
reality. However, the captured data from these systems are often hidden from the
Internet, partially due to the dynamic nature of the data and the lack of a common
framework for sharing such information in the public. As more and more sensorbased services become part of our daily life, they call for new technologies to allow
publishing, searching, browsing, and analyzing sensor data on the Internet. Consider,
for example, a stream monitoring sensor network deployed in a brook by a group of
geographers. The sensors measure the water temperature, turbidity and precipitation,
and periodically send back the data to an Internet-connected computer. These data
arrive as a stream and are published on the Internet by the geographers.
Independently, a biologist wants to study the life zone in the same brook and
searches for the information on the Internet. In a few seconds, she locates the sensors
published by the geographers, and starts to browse and analyze the data stream on her
own screen. As another example, think about video cameras deployed along the
major highways to monitor traffic condition. A navigation system can use such real-
time information to determine the fastest route to a given destination. In fact, such a
route can be updated continuously to ensure the fastest trip for the motorist.
We envision in this paper an all-new environment where innumerable sensing
systems, deployed by numerous publishers, expose different data over the Internet to
share them freely with a wide variety of unsolicited users much like web pages that
are publicly shared on the Internet today. To explore our vision, we have identified
the following key challenges:
Support the dynamic nature of sensor data. Sensors are generally limited in
power and memory 12, and must deliver data continuously at well-defined intervals in
the form of streams 5. While current web servers show good efficiency when
publishing static objects such as HTML web pages, they are not capable of publishing
dynamic sensor streams. As HTML provides a standard for displaying web pages,
sensor data need new standards to represent a wide variety of data stream formats.
Provide effective browsing methods for sensor data. While HTML web pages
contain all the information for a web browser to display, streaming sensor data do not.
If original sensor data are shown on the screen without interpretation, the user will
only see a screen of meaningless numbers. It is a major challenge to assist users to
browse sensor streams arriving at a high rate with potentially unlimited information.
Efficiently deliver real-time sensor data streams.
Current real-time
communication protocols focus at multimedia delivery and are not designed
specifically for sensor data. Hence they incur unnecessary overhead for sensor
streams due to the complexity of encoding/decoding, synchronization, etc. New
light-weighted protocols that target at sensor streams are highly desirable.
Build an efficient search engine for sensor meta-data. Given a large number of
sensors on the web as we envision, search engines need to be enhanced with the
capability to efficiently search semi-structured sensor meta-data.
Keeping the aforementioned challenges in mind, we have developed a framework
for a Web-based Intelligent Sensor Explorer (WISE) system, and build a prototype as
part of this effort. This system enables users to publish, browse, and analyze sensor
data over the Internet. This common platform also allows more sophisticated users to
develop and share their more specialized WISE-based analysis tools. Hereafter, we
refer to a sensing system and device simply as a sensor unless otherwise noted.
The WISE framework requires the following core technologies:
• Sensor data publishing is via Sensor Data Description Advertisement (SDDA).
An SDDA is an XML file that contains all the information a client needs to know
to access and interpret the published sensor data. In other words, it allows
providers tailor their own data service advertisements using SDDA as a canonical
format.
• Sensor proxies 5 are used to communicate with sensors. These proxies gather
nearby sensor data, remove noise, and process it to extract the desired
information (e.g., compute average vehicle speed from captured video). As in 5,
we assume that sensor proxies run on Internet connected computers.
• Sensor data from sensor proxies are published through a Sensor Data Server
(SDS), which accepts data requests and delivers data to the user. An SDS and
sensor proxies may or may not run on the same computer. A number of sensor
streams can be logically grouped together to collectively provide service to users.
As an example, the driver’s navigation system may need to get the information
from several sensors in order to determine the fastest route.
• The Sensor Data Browser (SDB) is an intelligent user interface with embedded
search functionality for sensor data. It also accepts specialized data processing
plug-ins for different purposes. Data can be visualized using the techniques
discussed in this paper, analyzed using data mining techniques 113, or queried
using Continuous Query (CQ) techniques 36.
• SDS’s and SDBs exchange control information and transmit sensor streams over
two different channels according to two light-weighted protocols, namely the
Sensor Stream Control Protocol (SSCP) and the Sensor Stream Transport
Protocol (SSTP)
Since many techniques have already been developed for sensor proxies (e.g., 25
15), we consider them as data sources in this paper, and focus our discussion on the
SDDA, SDS, SDB, SSCP, and SSTP. Our contribution is the development of WISE
as an underlying framework for a wide variety of Internet-scale sensor-based services
and applications. In addition to sensor data dissemination, WISE also supports
applications such as industrial control and monitoring, security and military sensing,
home automation and consumer electronics, asset tracking and supply chain
management, intelligent agriculture and environmental sensing, health monitoring,
just to name a few.
The remainder of this paper is organized as follows. In Section 2, we describe the
architecture of WISE along with the details of the core techniques. We present the
prototype and experimental study in Section 3. Related works are discussed in
Section 4. Finally, we offer our concluding remarks in Section 5.
2 WISE Framework
Fig. 1. High-level network architecture
The WISE environment is shown in Fig. 1. We revisit the sensor example of the
geographers to illustrate how this framework facilitates this application. To publish
the data, a Sensor Data Description Advertisement (SDDA) is created on a Sensor
Data Server (SDS) to hold the meta-data, and publish them into the Internet. At the
same time, the sensor proxy is collecting intermittent data from sensors in the brook.
When a biologist looking for related sensors enters search criteria into a local Sensor
Data Browser (SDB), this software uses a distributed search facility to look for
relevant SDDAs. As the browser displays a list of relevant SDDAs on the screen, the
biologist identifies the desired sensor and clicks on it. In response, the browser
establishes a session with the SDS using a Sensor Stream Control Protocol (SSCP),
gets the real-time stream using a Sensor Stream Transport Protocol (SSTP), and
directs the data to the default plug-in, the Visualizer, for display. The various
components are described in the following subsections.
2.1 Canonical SDDA format
Each SDDA advertises a sensor service consisting of a collection of related sensors.
For example, we can publish many traffic monitoring sensors deployed at different
busy locations throughout the city to support various navigation applications. An
SDDA is defined based on the XML schema shown in Fig. 2 and a sample SDDA is
given in Fig. 3. As shown in this example, a sensor service has a ServiceName, and a
ServiceDescription, providing a general description about the service. Furthermore,
an SDDA includes information for each sensor employed in this service. This sensor
information includes the following standard data fields:
Fig. 2. Canonical SDDA format
•
•
•
SensorName, SensorDescription, and SensorLocation: These data fields provide
the general description of each sensor.
ServerIP, ServerPort, SensorID and Protocol: These are the parameters for an
SDB to connect to the SDS. By default, we assume Protocol to be SSCP. We
need information on ServerIP and ServerPort because SSCP is built atop TCP.
StreamFormat: This user-defined field allows the sensor provider to customize
the format of the data stream. For instance, the SDDA example in Fig. 3 indicates
four distinct data fields in the sensor data: Temperature, Turbidity, Precipitation,
and Time. We define Data frame as the unit for sensor data transmission. Thus,
a data stream in WISE is a sequence of data frames, each consisting of a datum
for each of the data fields declared in FrameFormat.
Fig. 3. Sample SDDA
As in 5, the sensor proxy is responsible for packaging incoming sensor data into
data frames, and forwarding them to the server. Therefore, the SDS always delivers
sensor streams in well-defined data frames as declared in the SDDA and any SDB
will interpret the data streams according to the SDDA.
2.2 Sensor Data Server (SDS)
The SDS is responsible for managing incoming data from sensor proxies and
delivering the data to SDBs. As shown in Fig. 4, it has three major components,
namely the Publish Manager, the Stream Manager, and the Session Manager.
The Publish Manager accepts registrations from sensor proxies and publishes the
corresponding SDDAs into the Internet. An SDDA may advertise streams from
multiple SDS’s. For the local SDS, only standard parameters like Name, Description,
Location, and FrameFormat need to be provided. Additional parameters, such as
ServerIP, ServerPort, StreamID, and Protocol are automatically supplied by the
Publish Manager. For remote SDS’s, all parameters must be entered provided. We
note that a StreamID is unique only within a given SDS. The combination of
ServerIP, ServerPort, StreamID, however, uniquely identifies a stream on the Internet.
Fig. 4. Architecture of an SDS
Upon receiving a registration request from a sensor proxy, PM allocates a Stream
Processor which manages a small buffer for incoming data, and directs them to either
local applications (e.g., local display, database), or remote SDBs, or both. In Fig. 4,
the second stream is only for local display but the third one is delivered to a remote
SDB as well as stored into a local database. Although the stream processor consumes
data as fast as it can, the buffer may overflow if data arrive too fast. In WISE, we
discard the oldest frame in the buffer when buffer overflow occurs due to real-time
delivery consideration.
The Server Session Manager interacts with remote clients and provides two
important functionalities. First, it accepts client requests and control messages using
SSCP. For the first request for each stream, the server session manager spoons a new
session; whereas each subsequent request for the same stream joins the existing
session. Each session accepts client control commands and performs actions on the
streams. For example, the client can pause the stream transmission, and resume at a
later time without reconnecting to the SDS. Second, it delivers the stream to all
clients in the same session using SSTP. Essentially, a client uses two separate
channels to interact with the server, one for control messages, and one for data
delivery. The control channel is bi-directional, but the data channel only goes in one
direction. The details of SSCP and SSTP are discussed in Section 2.4.
2.3 Sensor Data Browser (SDB)
Fig. 5(a) illustrates the basic architecture of an SDB. An SDB consists of two
components, the Plug-in Manager (PIM) and the Client Session Manager (CSM).
The Plug-in Manager accepts registration of plug-in modules, and instantiates
plug-in instances for the Client Session Manager to use. Common plug-in modules
currently included in WISE are Visualizer, Analyzer, and Query Processor. Each
module can instantiate in a variety of ways. For example, the Visualizer module can
be used to create Line Charts, Time Series Charts, Bar charts and more Error!
Reference source not found.. We discuss our data visualization technique in section
2.6. More complicated plug-in modules such as the aforementioned navigation
service can also be installed. Through this facility, WISE enables sharing of various
sensor data analysis tools and applications. We note that a software developer can
create an SDDA to publish a sensor application (e.g., a sensor query processing
application) using only sensors published by third parties. Thus, WISE facilitates
sharing of not only sensor data, but also sensor-related tools and applications. This
flexibility and extensibility is another unique feature of WISE compared to previous
work.
Fig. 5. Sensor Data Browser architecture (a) & plug-in architecture (b)
In WISE environment, a plug-in typically has the MAP (Merge-Analyze-Present)
architecture as illustrated in Fig. 5(b). The Merger component combines related data
sources to prepare them for analysis.
The Analyzer component performs
computations on the combined stream and forwards the result stream to the Presenter
which visualizes the information onto the screen. As a simple example, a Merger can
combine streams of temperatures arriving from a number of nearby towns; the
Analyzer then computes the average temperature of the region for every time interval;
and finally, the Presenter plots a curve to visualize the variation in the temperature of
the region over time.
The Client Session Manager (CSM) of an SDB has three major functionalities.
First, it accepts user search criteria and looks for matching SDDAs on the Internet.
As a result, the user can browse through a list of relevant SDDAs and select desired
streams to view. Second, CSM connects to SDSs and establishes a client session for
each incoming stream. Similar to a server session, a client session also has two
channels, control channel and data channel. The control channel is used to
communicate user commands to the corresponding SDS; and sensor data are received
from this SDS over the data channel. Third, CSM requests the Plug-in Manager to
instantiate new plug-ins according to user selections and directs data to the
appropriate plug-ins. It can also deposit data into a local operating system file or
database upon user request for future analyses.
2.4 Communication protocols
Two communication protocols are used in WISE framework, namely SSCP and
SSTP. Both are application-layer protocols. The SSCP is used for control message
exchange on the control channel between an SDS and an SDB. As a simple analogy,
the SSCP acts as the network remote control for sensor stream playback by providing
a set of useful methods for a client. SSCP does not deliver the stream itself, but rather
uses SSTP for real-time data transmission. The semantics of the control methods are
listed below with an example illustrated in Fig. 6(a).
Fig. 6. SSCP operations (a) & SSTP packet format (b)
•
PREPARE. Request the SDS to allocate resources for a sensor stream and
prepare for the data delivery. If this is the first request for a particular stream, the
SDS creates a new server session and adds the requesting SDB to the session’s
SDB list. If a subsequent request arrives for a stream in an existing session, the
SDB will simply be added to this session.
• START. Request the SDS to start the data transmission through the data
channel. If this is the first request for a stream, the SDS starts an SSTP
transmission on the SSTP port to the SDB. If this is a subsequent request for an
existing stream, the SDS lets the SDB join the existing SSTP transmission. This
operation can also be used to start receiving the data again after a pause
operation.
• PAUSE. Temporarily stop the stream transmission without releasing server
resources. Any data transmitted during the pause period are lost. If the PAUSE
request is from the last active SDB on this stream, the SDS stops the data
transmission.
• STOP. Notify the SDS to stop the data transmission, free server resources, and
close the corresponding server session if this is the last active SDB receiving this
stream; otherwise, the SDS continues the data transmission for other SDBs while
purging the resources for the stopping SDB.
SSCP is based upon TCP to ensure reliable communication of control messages,
whereas SSTP is built atop UDP. Since UDP is connection-less without
acknowledgements or retransmissions, it incurs less overhead compared to TCP and
is better suited in a real-time environment.
SSTP also leverages its
broadcast/multicast capability so that the system scales to a large number of clients.
Before sending a data frame, the SDS wraps it into an SSTP packet with a header
as shown in Fig. 6(b). The sequence number increments by one for each SSTP packet
and is used by the SDB to detect packet loss and ensure in-order delivery. Due to
page limit, we only provide a high level view of SSCP and SSTP and omit the
detailed lower level specifications.
2.5 Search Mechanism
The WISE framework can be configured to work with any search engine as long as it
recognizes the sensor metadata. However, we use a peer-to-peer search facility in
WISE rather than a centralized one due to the following reasons:
• Building a conventional web-based search engine is much more expensive than a
peer-to-peer approach. In a P2P search engine the cost of search responsibility
and index storage are distributed among a large number of peers, reducing the
cost for each peer to virtually zero.
• A centralized server can become a bottleneck when too many clients request the
service. In contrast, a P2P system scales well because the workload is shared
among many peers.
• Search engine websites can no longer provide service to an isolated local area
network or a wireless ad hoc network where Internet access is not available.
However, those hosts in such environment (e.g., cars in a highway) can easily
self-organize into a peer-to-peer network (e.g. a JXTA virtual network), where
peer-to-peer search service can be carried out immediately.
Peers in the network use a distributed hash table (DHT) function to facilitate index
storage and access. Many DHT techniques have been proposed in CAN 8, CHORD
12 and Brocade 16, and Project JXTA 714Error! Reference source not found.. The
Project JXTA is an open-source effort to specify the standard protocols for peer-topeer (P2P) communication and collaboration. JXTA protocols establish a virtual
network overlay on top of the existing physical network infrastructure and provide
simple primitives to hide the complexity of the underlying physical network. The
JXTA network provides a Shared Resource Distributed Index (SRDI) service based
on Rendezvous peers, which maintain index of advertisements published by edge
peers. When an SDS publishes an SDDA, it is cached by a nearby rendezvous, and
its index is pushed to another rendezvous determined by the DHT.
When an SDB searches for an SDDA, the SDB issues a query to the SRDI service,
which calculates the DHT function and finds the peer that contains the index for the
SDDA. The SDB then gets the index from that peer and finds the target SDDA. We
refer to 14 for a detailed discussion on relevant techniques. It is noted that DHT
approaches have several well-known drawbacks such as fuzzy search incapability.
We leave the improvement for this search component as future work, while focus
primarily on the overall architecture of the framework in this paper.
2.6 Data Visualization
While different plug-ins can be created for specific applications and incorporated
seamlessly in WISE, we present in this section a Visualizer module that is currently
provided in SDB.
For a data stream with potentially unlimited information arriving at a very high
rate, summarization is a great way for the user to “see” the stream. Different types of
summarization methods can be used under different circumstances, including
visualization, analysis, and querying, where visualization is probably the most
intuitive way. In WISE, we provide Visualizer as the first default plug-in for the
standard browser. We define a concept of Presentation Frame, analogous to a video
frame, as the minimum unit of data for display. That is, a presentation frame is a
collection of data frames that are visualized together on the screen. For example, the
Visualizer may display the presentation frame by drawing a time series chart where
every point corresponds to a data frame. We can view a continuous stream arriving at
the Visualizer as a sliding window over the data stream. A sliding window of size six
is illustrated in Fig. 7. It shows two consecutive presentation frames, one includes
data frames 69 to 74, and the next one has frames 70 to 75. By visualizing these
consecutive presentation frames at a high display rate, we create the experience of
motion similar to video. In other words, the standard WISE browser summarizes and
presents sensor data to the end user in the form of data animation. This is another
unique feature of WISE compared to previous work. We note that the Visualizer is
only one of many possible plug-ins for the WISE environment. Other ways to
summarize data streams including data mining and various statistical analysis
techniques can also be easily incorporated as plug-ins.
Fig. 7. Presentation frame
3 Prototype
We have developed a WISE prototype in JAVA using the design and techniques
presented in the last section. In this section we describe the usage of this system and
discuss its implementation details. As a proof of concept, the first version of WISE
has a simple user interface with a basic set of functionalities. A screen shot of the
Sensor Data Browser (SDB) is shown in Fig. 8. It provides three ways to access and
explore a sensor service:
• Use the search mechanism to find the SDDA, and click on it.
• Select one of the bookmarks, and click on it to select the corresponding SDDA.
• Enter the URL to access the SDDA directly if the information is available.
All three access methods will activate the corresponding plug-in. To use the first
option to search for an SDDA or a sensor service, the user enters a set of keywords as
the search criteria. These keywords are matched against the metadata in order to
determine the relevant SDDA’s, and rank them accordingly. To make the search
more specific, the user can also enter additional keywords for the three provided
metadata fields. The keywords entered for Datafields are compared with the names
of the sensor data fields declared by the sensor providers.
Fig. 8. Browser Interface – Search
Fig. 9. Browser Interface - Search Results
After the “Search” button is clicked, the SDB searches on the Internet and brings
back a screen of relevant SDDAs, as shown in Fig. 9. Our sensor explorer displays
only the standard descriptive information such as the name of the service, its
description, and the locations of the sensors to help the user identify the desired
sensor service. The user can now select a service by clicking on its name. This will
activates the default plug-in, the Visualizer, which prompts the user to choose from a
number of different visualization methods. Fig. 10 shows a screen shot when the user
views the variation of the water temperature on a time series chart.
To validate the key concepts discussed in this paper, we tested our prototype over
the Internet. The experiment environment consists of three SDS’s and two SDBs, as
shown in Fig. 11(a). We tested the publish and search mechanism by letting each of
the SDS’s advertise a data stream from a simulated sensor proxy running on a
separate computer in the same local area network. We conducted the following
experiments, as illustrated in Fig. 11 (b) and (c).
Fig. 10. Visualizer
Fig. 11. Experimental environment and test scenarios
•
•
One SDS serving multiple SDBs. We initiated the same search on the two
SDB’s using the same keyword. When the results returned as shown in Fig. 9,
we selected the same sensor service on both SDB’s. In response, the two sensor
explorers brought up the same Visualizer window as shown in Fig. 10. This
experiment illustrates the capability of an SDB to find sensors, and an SDS to
handle multiple SDBs, as well as other basic functionalities of the WISE
framework.
One SDB receiving streams from multiple SDS’s. In this experiment, we
opened one sensor explorer window and clicked on two streams with different
formats. In response, the sensor explorer created two independent Visualizers
and displayed the two streams without interference. This test shows that an SDB
is capable of receiving multiple streams and accommodating different stream
formats.
4 Related Work
Recently there has been a growing interest on sensor data management with the main
focus on building sensor databases on top of wireless ad hoc sensor networks.
Madden et al propose the technique Fjords 5 for query processing on the continuous,
never-ending sensor data streams. The sensor network is modeled as a streaming data
source by providing a sensor proxy as the sensor’s interface into the query processor.
Yang et al also discuss query processing over sensor networks in 15 focusing on
modeling sensor streams as virtual relations. These techniques provide useful design
guidelines and insights for sensor databases and query systems, but their target
environment is limited to within a sensor network. Our WISE framework, in contrast,
aims at a higher level, Internet-scale sensor-based services and applications while
utilizing these existing techniques to hide the lower-level sensor management details.
In 4 Deshpande et al present the project IrisNet to deal with widely deployed PCscale sensors and organizes them into a distributed database. The authors proposed
effective techniques for fragmenting a database, query routing, and data caching.
WISE differs from this work in the following aspects. First, IrisNet treats sensor data
as discrete updates to the database and does not incorporate any specific methods to
work with streaming data. Second, IrisNet predefines the scale of the database, i.e. all
the sensors are assumed to be owned by the same organization. In contrast, WISE
provides a flexible environment for providers to publish their sensors, and unsolicited
users to find and use the sensors freely over the Internet. In fact, the IrisNet could be
designed as one powerful plug-in for WISE. Finally, WISE accepts both large,
powerful sensors like webcams and resource-stringent wireless sensor networks by
providing the sensor proxies as another layer of abstraction.
RTSP 9 is an application-level protocol that provides an extensible framework to
enable controlled, on-demand delivery of real-time multimedia. RTP 10 is a real-time
transport protocol that provides end-to-end transport functions. Since RTSP, RTP
and other popular protocols employ considerable complexity to address various issues
on streaming multimedia transmission, they cause unnecessary overhead for sensor
data delivery that has more relaxed real-time requirement. Stream Control
Transmission Protocol (SCTP) 11 is a reliable, connection-oriented protocol at
transport layer and also provides a number of functions for real-time services. SCTP
can be used as an alternative in WISE to provide enhanced transport layer services to
SSCP and SSTP.
5 Concluding Remarks
The major contribution of this paper is the development of WISE, the first Internetscale framework for publishing, searching, and browsing sensor data. We envision a
future Internet where innumerable sensing systems are deployed by numerous
publishers exposing different real-time data over the Internet to share them freely
with a wide variety of unsolicited users. We identified the key challenges in
supporting such an environment, and proposed solutions that are effective, flexible
and scalable. Our techniques include the canonical metadata representation for
publishing sensor data over the Internet, the peer-to-peer search mechanism for
finding relevant sensors, the data animation concept for presenting stream data in an
intelligible way, and the communication protocols SSCP and SSTP for remote control
of sensor streams. We have built a prototype as a test bed to evaluate these
techniques. Our experiments over the Internet indicate that WISE indeed provides an
effective framework for publishing, finding, and using sensors.
References
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
C. C. Aggarwal, J. Han, J. Wang, P. S. Yu: A Framework for Clustering Evolving Data
Streams. In VLDB, 2003.
E. H. Callaway. Wireless Sensor Networks: Architecture and Protocols. From Auerbach
Publications, 2003.
S. Chandrasekaram, O. Cooper, A. Deshpande, M. J. Franklin, J. M. Hellerstein, W.
Hong, S. Krishnamurthy, S. Madden, V. Raman, F. Reiss, and M. Shah. TelegraphCQ:
Continuous Dataflow Processing for an Uncertain World. In CIDR, 2003.
Deshpande, S. Nath, P. B. Gibbons and S. Seshan. Cache-and-Query for Wide Area
Sensor Databases. In SIGMOD, 2003.
S. Madden and M. J. Franklin. Fjording the Stream: An Architecture for Queries over
Streaming Sensor Data. In ICDE, 2002.
R. Motwani, J. Widom, A. Arasu, B. Babcock, S. Babu, M. Datar, G. Manku, C. Olston,
J. Rosenstein, and R. Varma. Query Processing, Approximation, and Resource
Management in a Data Stream Management System. In CIDR, 2003.
Project JXTA, http://www.jxta.org.
S. Ratnasamy, P. Francis, M. Handley, R. Karp and S. Shenker. A Scalable ContentAddressable Network. In ACM SIGCOMM, 2001.
H. Schulzrinne, A. Rao and R. Lanphier. Real Time Streaming Protocol (RTSP). RFC
2326, 1998.
H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson. RTP: A Transport Protocol for
Real-Time Applications. RFC 1889, 1996.
R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M.
Kalla, L. Zhang, and V. Paxson. Stream Control Transmission Protocol. RFC 2960,
2000.
I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan. Chord: A Scalable
Peer-to-peer Lookup Service for Internet Applications. In ACM SIGCOMM, 2001.
W. G. Teng, M. S. Chen, P. S. Yu: A Regression-Based Temporal Pattern Mining
Scheme for Data Streams. In VLDB, 2003.
Traversat, A. Arora, M. Abdelaziz, M. Duigou, C. Haywood, J. C. Hugly, E. Pouyoul,
and B. Yeager. Project JXTA 2.0 Super-Peer Virtual Network. http://www.jxta.org.
Y. Yang and J. Gehrke. Query Processing for Sensor Networks. In CIDR, 2003.
Zhao, Y. Duan, L. Huang, A. D. Joseph, and J. D. Kubiatowicz. Brocade: Landmark
Routing on Overlay Networks. In Proceedings of the First International Workshop on
Peer-to-Peer Systems (IPTPS), 2002.