DTIC ADA440112: Solar: Towards a Flexible and Scalable Data-Fusion Infrastructure for Ubiquitous Computing

0.09 MB·English

by  Defense Technical Information Center

Solar
: Towards a Flexible and Scalable Data-Fusion
Infrastructure for Ubiquitous Computing
Guanling Chen and David Kotz
Dartmouth College
Hanover, NH, USA 03755
{glchen, dfk}@cs.dartmouth.edu
Abstract
situation in which they are running. They must ob-
tain and analyze the data about their context, and
Asweembedmorecomputersintoourdailyenviron- adjust their behavior without unnecessarily distract-
ment, ubiquitous computing promises to make them ingtheuser. Thistaskischallengingbecauseapplica-
less noticeable and to avoid information overload. tions face heterogenous data types, different commu-
We see, however, few ubiquitous applications that nication protocols, unreliable wireless links with lim-
are able to adapt to the dynamics of user, physical, ited bandwidth, low data quality due to error-prone
andcomputationalcontext. Thechallengeistoallow sensors affected by environmental noises, and many
applications flexible access to these sources, and yet other issues.
scale to thousands of devices and sensors. In this pa- Asking each application to work directly from in-
perweintroduceourproposedinfrastructure,Solar. formation sources overwhelms programmers with de-
In Solar, information sources produce events. Ap- tailsandcomplexity. Itleadstoad-hocsolutionsthat
plications may subscribe to interesting sources di- will not scale with N2 pipes between the sourcesand
rectly,ortheymayinstantiateandsubscribetoatree applications. Theprogrammersneedatoolkittosim-
of operators that filter, transform, merge and aggre- plify their task and the toolkit needs an infrastruc-
gateevents. Applicationsuseasubscriptionlanguage ture to deliver context data, an infrastructure that
todescribethetree,basedoneventstreamsregistered can scale by sharing data streams.
in a context-sensitive naming hierarchy. Solar is Both Gryphon [1] and Siena [2] are content-based
flexible: modular operators can be composed to pro- publish/subscribe systems and provide large-scale
duce new event streams. Solar is scalable: it dis- event-routing services. While they can provide some
tributes operators across hosts called Planets, and it event-fusion functions, it is unclear how these func-
re-uses common subgraphs in the operator network. tionsaredeployedandwhetheritispossibletoshare
themacrossapplications. Sincetheubiquitous adap-
tiveapplicationstypicallygainthehigh-level“aware-
1 Introduction
ness” by filtering, transforming, merging, and ag-
gregating low-level sensor data, what we really need
As wireless computing devices become more com- is a fusion-centric (instead of routing-centric) data
mon,theirusersareexposedtoatremendousamount dissemination infrastructure that provides sharing of
of information that comes from an array of diverse both data streams and fusion functionalities. Build-
sources, such as location sensors, weather or traffic ingsuchadata-fusioninfrastructureforaubiquitous
sensors, network monitors, information appliances, mobile environment has to face many technical chal-
the status of computational or human services, and lenges, which are summarized by Cohen et al. [4].
so forth. One important goal of ubiquitous comput- We propose a system infrastructure, Solar, to
ing,however,istohelptheuserovercomeinformation meet the challenges. Our goal is to allow appli-
overload and concentrate on the current task [7]. To cations to define their own operations, to describe
do so, ubiquitous applications must be aware of the flexible compositions of operations, and to support
many such applications with scalable performance.
This research has been supported by DARPA contract Solar provides flexibility by allowing applications
F30602-98-2-0107,byDoDMURIcontractF49620-97-1-03821,
to define and interconnect operator objects. Solar
by Microsoft Research, and by the Cisco Systems University
ResearchProgram. provides scalability by distributing these operators
Report Documentation Page Form Approved
OMB No. 0704-0188
Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and
maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,
including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington
VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it

does not display a currently valid OMB control number.
1. REPORT DATE 3. DATES COVERED
2005 2. REPORT TYPE -
4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER
Solar: Towards a Flexible and Scalable Data-Fusion Infrastructure for
5b. GRANT NUMBER
Ubiquitous Computing
5c. PROGRAM ELEMENT NUMBER
6. AUTHOR(S) 5d. PROJECT NUMBER
5e. TASK NUMBER
5f. WORK UNIT NUMBER
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION
Defense Advanced Research projects Agency,3701 North Fairfax REPORT NUMBER
Drive,Arlington,VA,22203-1714
9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)
11. SPONSOR/MONITOR’S REPORT
NUMBER(S)
12. DISTRIBUTION/AVAILABILITY STATEMENT
Approved for public release; distribution unlimited
13. SUPPLEMENTARY NOTES
14. ABSTRACT
see report
15. SUBJECT TERMS
16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 18. NUMBER 19a. NAME OF
ABSTRACT OF PAGES RESPONSIBLE PERSON

a. REPORT b. ABSTRACT c. THIS PAGE 4
unclassified unclassified unclassified
Standard Form 298 (Rev. 8-98)
Prescribed by ANSI Std Z39-18
across hosts in the network and by sharing identical 007 Loc Active Map
Sensor Building
data streams across users and applications. Locator
S T A
This paper provides a brief overview of the Solar .. Bob’s
Locator
infrastructure. We necessarily skip many of the de- . M F
tails here because of the space limitation. For more
information see our Technical Report [3]. 215 Loc T 215
Sensor Monitor Bob’s
S A Guide
2 Operator graph
Figure 1: An example operator graph.
Solar treats sensors of ubiquitous data as informa-
tion sources, whether they sense physical properties
room. These events are transformed to appropriate
such as location, or computational properties such
namesoftheobjectsassociatedwiththebadgebefore
as network bandwidth. Information sources produce
merged into a single event stream. The aggregator
their data as events, implemented in Solar as ob-
labeled as “Building Locator” takes this stream and
jects. The sequence of events produced is an event
produces only location-change events about the ob-
stream, which is inherently unidirectional. An event
jects. Similarly, the “215 Monitor” reports whenever
publisher producesaneventstream,andaneventsub-
anobjectleavesorentersroom215. TheActiveMap
scriber consumes an event stream.
running on a public wall-mounted screen can then
An operator is an object that subscribes to and
displaythecurrentlocationoftrackedobjectbysub-
processes one or more input event streams, and pub-
scribing to the “Building Locator” aggregator. The
lishes another event stream. Since the inputs and
aggregator’soutputcanalsobefilteredtoreportonly
outputofanoperatorarealleventstreams,theoper-
Bob’s movement. The personal Guide application on
atorscanbeconnectedrecursivelytoformadirected
Bob’s PDA displays the descriptions about the room
acyclic graph, an event-flow graph that we call the
andthelistofcurrentresidentobjectsandassociated
operator graph.
links, followingwhichBobcanfindmoreinformation
Ouroperatorgraphconsistsofthreekindsofnodes:
such as the calendar of a colleague and the manual
sources, operators, and applications. The sources
ofascanner. Thedashedarrowrepresentsacontext-
have no subscriptions. They are wrappers for in-
sensitive subscription (assuming Bob is currently in
formation sensors. Operators are deterministic func-
room 215), which will be discussed in Section 4.
tions of their input events. They only publish an
In this example we show how the operator graph
event when they receive an input event. Applica-
achieves flexibility by allowing dynamic composition
tions are sinks of the graph. They subscribe to one
ofoperatorsandachievesscalabilitybyre-usingevent
or more event streams and react to incoming events
streams. These applications adapt to high-level con-
(andpossiblyotherstimuli, suchasinteractionswith
text that is derived from the same sources, simply
the user).
reusing the operators without having to process raw
There are four common categories of operators. A
data from sensors on their own. The redundant and
filter outputs a subset of its input events. A trans-
irrelevant events have been filtered out before reach-
former inputs events of one type and outputs events
ing these applications, making it possible to support
of the same or another type. (The types may be the
a larger number of applications without saturating
same if the transformer only changes some attribute
network edge links.
values.) The merger simply outputs every event it
In summary, once the data-fusion functionalities
receives. While mergers are not strictly necessary,
(represented by operators) are isolated from the ap-
since any of the merger’s subscribers could directly plications, Solar can deploy them across the net-
subscribe to the same inputs, a merger aids re-use of
work and promote re-use of these operators by var-
event streams. An aggregator outputs an arbitrary
ious applications. This approach achieves several
typeeventstreambasedontheeventsinoneormore
advantages: 1) It provides a fine-grain application-
input event streams.
partitioning method for flexible adaptation to vari-
ous capabilities of the mobile devices and available
Example. We show a simple example operator network connectivity; 2) Solar encourages the use
graph in Figure 1. Suppose in a typical office envi- and sharing of filter operators, and the deployment
ronmentwithlocationsystem(suchasActiveBadge) ofthosefiltersclosetotheinformationsources,which
installed, each room has a location sensor that peri- candramaticallyreducebandwidthusedonslownet-
odically reports the badge number it detects in that work links; 3) Re-use of an operator instance in
2
Solar is to re-use all the event streams and oper- ate the appropriate list of children when asked. For
atorsinthesubgraphrootedbythatoperator,allow- example, the node [/places/2F/215/people] lists Bob
ing much easier composition than manually specify- as child and [/people/profs/Bob/location] refers to
ing a list of components the data should go through room 215. These links are automatically updated as
from source to application (such as the “after list” theusermovesacrossgeographicalspaces. Sinceboth
in Active Names [6]); and 4) the operator graph can operators derive the location information from the
dynamicallygrowasanapplicationcustomizesthein- same source [/places/2F/215/location-sensor], these
formationflowbyaddingitsownfusionoperatorsand two views will remain consistent.
re-using many others, avoiding the limitation (the Nodes in the name space are also publishers of
needofalargepredefinedservicerepository)imposed changes to name bindings. More precisely, direc-
by automatic path construction [5]. tory nodes are publishers that announce additions
or deletions of their children by publishing events.
(Static directory nodes are sources and dynamic di-
3 Context-sensitive naming rectory nodes are operators.) Alias nodes are pub-
lishers that announce changes in their bindings. In-
Althoughwecanbuildoperatorgraphsfromthecon- terestedapplicationscansubscribetothesesourcesto
nections described by a subscribing application, and detect changes in the name space. So if Alice wants
Solar has a small language for that purpose, it is to track the location of her advisor Bob, her appli-
frequently useful to name event publishers so that cation subscribes to the operator named as [/peo-
their streams are easily usable by many subscribers. ple/profs/Bob/location].
By naming a publisher, applications can subscribe Although Solar’s concept of “operator graph” is
to its event stream without needing to describe that independentofitsnamingscheme,webelievethecon-
stream from first principles (sources). It is common text sensitive namespace is ideal for adaptive ubiq-
to construct named mergers, for example, to make uitous applications. The namespace re-uses the op-
pre-defined combinations of event streams available erator abstraction and connects the physical loca-
to many applications. tion with entities inside, allowing applications to use
A flat name space does not scale. Furthermore, one persistent name to access location-dependent in-
given the dynamic nature of an application’s con- formation sources while Solar automatically selects
textinubiquitouscomputingenvironments,Solar’s anddeliversappropriateeventstreamsasusermoves
name bindings change with the changing context. So around. This approach removes much of the com-
Solar’snamespaceisorganizedasatreeoflabelled plexity of location tracking from applications.
nodes, withtheadditionofcrossedges(seeanexam-
ple in [3]). The name for a node is the sequence of
labels encountered on any path from the root to the 4 System architecture
node, separated by slashes. There are several types
of nodes. Some of the leaves are alias nodes that We discuss Solar’s architecture in this section. At
are representatives of another node. By analogy to the center of any Solar system is a Star, which
Unix, we call these cross edges “soft links”. Some keeps a reference to the root of naming tree, main-
leaves may be service nodes, which represent avail- tains the operator graph, and services requests for
able services. Other leaves are the event publishers new subscriptions. When the Star receives a new
we discussed in the operator graph. subscription-tree description, it parses the descrip-
Internal nodes are directories that refer to sev- tion, checks the name space, and matches the sub-
eral child nodes. Static directory nodes contain a scription tree against its internal data structure rep-
list of children, a list updated only by explicit re- resenting the operator graph. When it decides to de-
quests. Dynamic directory nodes generate a list of ployanoperator,itinstantiatestheoperator’sobject
children dynamically, from internal state that de- on one of many Planets. Each Planet is an execu-
pends on contextual information obtained from sub- tion platform for Solar sources and operators. (In
scriptions. Typicallythechildrenofdynamicdirecto- our implementation, operators are Java objects and
ries are nodes already located elsewhere in the name PlanetsareJavavirtualmachines.) Applicationsrun
space. outside the Solar system, on any platform. They
Softlinksaredynamicallygeneratedbyadirectory use a small Solar library that allows them to send
oraliasnodewhenneeded. Thesedirectoryandalias requests to the Star, and to manage their subscrip-
nodesmust, therefore, beoperators with appropriate tions, over standard network protocols.
subscriptions and sufficient state to be able to gener- Planets play a key role in the subscriptions of res-
3
ident operators. When deploying new subscriptions, (cid:127) consider security and privacy (Planets need to
the Star tells the Planets to record a subscription execute untrusted operator code securely, Plan-
from one of its operators to an operator in another ets must limit the resource usage, and Solar
Planet. In our implementation there is at most one mustlimitsubscriptiontoeventstreamsaccord-
network(TCP/IP)connectionbetweenanytwoPlan- ing to an access policy), and
ets, regardless of the number of operators on or sub-
(cid:127) experiment with the use of Solar in several
scriptions between the two Planets.
context-sensitive mobile applications to deter-
Another critical advantage of our approach is
mine the value of the abstraction and the per-
that the Planet supports subscription requests that
formance of the system.
involve context-sensitive names (CSNs). These
subscription requests are mapped to subscriptions,
which need to be changed when the CSN bind- References
ing changes. Consider an operator X that records
the name of every person Bob meets. The op- [1] G. Banavar, M. Kaplan, K. Shaw, R. E. Strom,
erator requests subscription to the CSN [/peo- D. C. Sturman, and W. Tao. Information flow
ple/profs/Bob/location/people], currently bound to based event distribution middleware. In Pro-
an operator P. X’s Planet subscribes to the name ceedings of the Middleware Workshop at the 19th
[/people/profs/Bob/location]. The Planet receives IEEE International Conference on Distributed
the current binding and subscribes X to P. When Computing Systems, Austin, Texas, May 1999.
Bob moves, suppose the binding changes to opera- IEEE Computer Society Press.
tor Q. X’s Planet contacts P’s Planet to remove X
[2] A. Carzaniga, D. S. Rosenblum, and A. L. Wolf.
from P’s data structure, and contacts Q’s Planet to
Achieving scalability and expressiveness in an
addXtotheQ’sdatastructure. Alltheworkisdone
Internet-scale event notification service. In Pro-
by planets and the namespace operators; P, Q, and
ceedings of the Nineteenth Annual ACM Sym-
X are never involved.
posium on Principles of Distributed Computing,
TheseandotheraspectsoftheSolararchitecture
pages 219–227, Portland OR, USA, July 2000.
arekeytoitsscalabilityandflexibility. Furthermore,
although the operators must execute inside a Solar [3] G. Chen and D. Kotz. Supporting adaptive
Planet,applicationsmayrunonanyplatform. Thus, ubiquitous applications with the SOLAR system.
legacyorCOTSapplicationsmayeasilybeintegrated Technical Report TR2001-397, Dept. of Com-
with a ubiquitous-computing environment built on puter Science, Dartmouth College, May 2001.
Solar technology.
[4] N. H. Cohen, A. Purakayastha, J. Turek,
L. Wong, and D. Yeh. Challenges in flexible ag-
5 Future work gregation of pervasive data. Technical Report
RC21942, IBM Research Division, Thomas J.
Our focus on Solar so far has been to develop a WatsonResearchCenter,P.O.Box704,Yorktown
useful model for flexible, scalable access of contex- Heights, NY 10598, January 2001.
tual information. There are three critical directions
[5] E. Kiciman and A. Fox. Using dynamic medi-
in which we must refine our design: scalability, relia-
ation to integrate COTS entities in a ubiquitous
bility, and security. We plan to
computingenvironment. InProceedingsofSecond
International Symposium on Handheld and Ubiq-
(cid:127) distribute the responsibility of the Star to avoid
uitous Computing, pages 211–226, Bristol, UK,
a central point of failure and to avoid any pos-
September 2000. Springer Verlag.
sible performance bottleneck in systems where
new subscriptions occur frequently, [6] A. Vahdat, M. Dahlin, T. Anderson, and A. Ag-
garwal. Active Names: Flexible location and
(cid:127) extend the name space to allow federation of transport of wide-area resources. In Proceedings
many name spaces, ofthe2ndUSENIXSymposiumonInternetTech-
nologies and Systems, Boulder, Colorado, Octo-
(cid:127) address reliability in the face of failure of a
ber 1999. USENIX.
Planet or a network connection,
[7] M. Weiser. The computer for the 21st century.
(cid:127) develop a mechanism for flow control between Scientific American, pages 94–104, September
publishers and subscribers, 1991.
4