Network System Challenges in Selective Sharing and Verification for Personal, Social, and UrbanScale

1
Network System Challenges in Selective Sharing
andVerification for Personal, Social, and
Urban-Scale SensingApplications

• Andrew Parker Sasank Reddy Thomas Schmid Kevin
  Chang Ganeriwal Saurabh
• Mani Srivastava Mark Hansen Jeff Burke Deborah
  Estrin Mark Allman Vern Paxson
• Center for Embedded Networked Sensing - UCLA
  Google Inc. ICIR/ICSI

2
INTRODUCTION

• Application drives the architecture design
  choices and the definition of services needed in
  a network.
• Embedded sensing will move beyond science,
  engineering and industrial applications to become
  an everyday tool for individuals and communities,
  to effectively observe distributed phenomena at
  personal, social and urban scales.
• The sensing modalities we are considering include
  those available on cell phones and handhelds
  (imagery, video, audio)
• (temperature, pressure, light-level, etc.)

3
INTRODUCTION

• Sensor-based applications enable new kinds of
  social exchange by collecting, processing,
  sharing, and visualizing sensed information
• To achieve their potential, these applications
  require fundamentally new algorithms and software
  mechanisms.
• The research described in this paper seeks to
  identify and develop an overall network fabric
  architecture that through various services
  coherently embodies such algorithms and
  mechanisms.

4
INTRODUCTION

• Applications here are divided into three
  categories Personal Social urban
• Medical monitoring is a good example of a
  personal application
• In social applications data is shared among a
  group of participants
• In urban-scale application data is shared with
  the public, ex Flickr.
• To achieve these needs
• What mechanisms
• basic quality checks for data
• By providing a suite of services, can we
  encourage responsible sensing practices

5
DESIGN CHALLENGES

• To what resolution, location and time is
  published
• Whats the privacy mechanism (selective sharing)
• Name touch Naming the data stream not the device
• Can we use service oriented approach and offering
  an API for application

6
DESIGN CHALLENGES

• Context Verification
• Selective Sharing
• Discovery and Publication

7
Measuring Time and Location

• Measuring by the receiver
• Measuring by the data sender using GPS
• Avoid cheating by some sensors
• Using sensor signature needs key distribution and
  validation infrastructure
• Not suitable in large scale and ad-hoc nature
• Other context measurements
• Orientation of the sensor
• Sensors in the vicinity for checking integrity
• Sensor density increased
• Some sensors are deployed to measure the data
  sensor context attributes

8
Context data

• Sensor has no reason to measure orientation or
  temperature
• Application and fabrics are different entities
• Control of the fabric to what resolution it has
  to publish context data
• Sensors may has context data in a fine grained
  for aggregation or verification purposes
• For example publisher may not publish its data
  unless N sensor in the vicinity have the same
  value

9
Discovery and publication

• Publish and subscribe mechanism like DNS
• The service get some attribute values and return
  a set of handles to data streams
• Two constraints to be satisfied
• Attributes of data streams and that of subscriber
  must match some attribute values form
  hierarchical relationships that should be known
  by the discovery service
• Disclosure rule accompanied by the data stream
  must be satisfied

10
Partisans system architecture

• Sensors
• Subscribers
• Mediators
• Registries

11
Sensors

• Data sensors that collect data of a specific
  phenomenon
• Context sensor that collect information about the
  physical environment of the data sensors

12
Subscribers

• Individual users interested in some kind of data
• Network applications that process data
• Archiving
• Searching
• Aggregating
• Physician subscribe to medical events associated
  with remotely monitored patient
• Smart home software subscribe to sensors deployed
  by the homeowner
• Network application that host data to be shared
  by the public, ex Flickr.com

13
Mediators

• Acts as an intermediary between sensors and
  subscribers
• Enhance data streams
• Achieve Verification and sensor disclosure rules
• Make use of trusted infrastructure to measure
  time and location
• Act like firewall for administration and cache
  server for HW configuration
• Its a trusted component by our model

14
Registries

• Works like DNS
• Sensors register with metadata information
• Subscribers query the registries for sensors
  using attributes like location or type of sensor
• Registries return handles to the suitable streams
• Its a trusted component by our model

15
SensorBase.org

• Its a web site that is used for publishing and
  subscribing to sensor data.
• Users can make project and register them to that
  site where data consumers can query sensor data
• 4SensorBase.org
• A CENTRALIZED REPOSITORY TO SLOG
• SENSOR NETWORK DATA
• Kevin Chang, Nathan Yau, Mark Hansen, Deborah
  Estrin
• University of California, Los Angeles
• Center for Embedded Network Sensing
• Computer Science Department
• Statistics Department
• Los Angeles, CA 90095
• kchang,destrin_at_cs.ucla.edu, nyau,cocteau_at_stat.
  ucla.edu

16
Design

• Requirements
• Users prefer to save data to repository instead
  of using file server and access control
• Users prefer to query for data instead of making
  searching and parsing manipulations
• Administrators prefer projects to be self-managed
  in groups and also have the ability to manage
  users and meta-data

17
alternative

• Use file server and web server such as Apache2.0
• Create Unix account for every project
• Users should use scp (secure copy command) or
  HTTP POST to upload well defines XML formats on
  their directories
• Drawbacks
• It doesnt enforce users to publish files in a
  standardized formats
• Searching and retrieving data is difficult
• Managing large number of users and data points is
  time consuming for administrators

18
Alternative

• For fast data retrieval we can make a schema for
  each project
• Drawbacks
• This is time consuming
• Schemas may diverge so we have no common
  interface for query purposes

19
Proposed SystemSensorBase.Org

• Centralized repository that perform automatic
  checking for well specified XML file
• Fine grained queries is available
• challenges
• A very big amount of resources needs to be
  invested to create backend and front-end
• Flexibility in maintaining different data types

20
Implementation

• Technologies used
• MySQL for database
• PHP as a scripting language for web design
• UNIX utilities as a platform and administrative
  operating system

21
Interface

• User can create new project and sensor types
• User can invite new users, set permission and
  other options
• Each project can contain one measurement type.
  Each measurement type is associated with a
  specific sensor type
• Using Geocodes give users the ability to search
  depending on geographic locations

22
Query results

• Search features are easy like SQL queries
• Search features are evolving to meet user needs
• Results are returned to the user in
• HTML formats for browsers
• raw comma separated text entries. This gives
  application a more easy interface with
  SensorBase.org
• XML generators are being implemented

23
Uploading data

• Uploading data using HTTP POST mechanism
• Upload meta-data file that describe the data file
  format as well as project measurement types and
  sensors locations
• Upload data files
• Uploading mechanism can be automated in a script
• Like queries uploading mechanism is evolving by
  time

24
Backend

• Database is divided into two parts
• Project and users part
• Project tables describe information about
  projects such as
• Project owner
• Allowable measurements and their description
• permissions
• User tables describe information about users such
  as
• Which group a user can manage
• InnoDB engine is used to allow consistent and
  reliable transactions
• Data part
• Contains data for the project
• This part is read only and heavily used so for
  performance issue ISAM engine is used that is
  good in fast read operations but lake for
  transaction and fault-tolerance

25
REFERENCES

• 1 Cisco application-oriented networking blog.
  http//
• blogs.cisco.com/AON/.
• 2 Ecopda. http//www.lecs.cs.ucla.edu/
• urban-sensing/index.php/EcoPDA.
• 3 Tinyos An operating system for networked
  sensors.
• http//tinyos.millennium.berkeley.edu.
• 4 CHANG, K., YAU, N., HANSEN, M., AND ESTRIN,
  D.
• Sensorbase.orga centralized repository to slog
  sensor
• network data. In DCOSS/EAWMS Proceedings (June
  17
• 2006).

26
REFERENCES

• 5 GANERIWAL, S., KUMAR, R., AND SRIVASTAVA, M.
• Timing Sync Protocol for Sensor Networks. In
  Sensys
• (Los Angeles, 2003).
• 6 HUFFMAN, S. M., AND REIFER, M. H. Method for
  geolocating
• logical network address. In United States Patent
• 6947978 (Sept. 2005).
• 7 KANSAL, A., AND SRIVASTAVA, M. Wireless
  Sensor
• Networks A Systems Perspective, Eds. N. Bulusu
  and S.
• Jha. Artech House, 2005, ch. Energy harvesting
  aware
• power management.
• 8 KOHNO, T., BROIDO, A., AND CLAFFY, K. C.
  Remote
• physical device fingerprinting. IEEE Trans.
  Dependable
• Secur. Comput. 2, 2 (2005), 93108.

27
REFERENCES

• 9 MCINTIRE, D., HO, K., YIP, B., SINGH, A., WU,
  W.,
• AND KAISER, W. J. The low power energy aware
  processing
• (leap)embedded networked sensor system. In
• IPSN 2006 (New York, NY, USA, 2006), ACM Press,
• pp. 449457.
• 10 MILLS, D. L. Internet Time Synchronization
  The Network
• Time Protocol. In Global States and Time in
  Distributed
• Systems, Z. Yang and T. A. Marsland, Eds. IEEE
• Computer Society Press, 1994.
• 11 REDDY, S., SCHMID, T., PARKER, A., PORWAY,
  J.,
• CHEN, G., JOKI, A., BURKE, J., HANSEN, M.,
  ESTRIN,
• D., AND SRIVASTAVA, M. Demo Urbancens Sensing
• with the urban context in mind. In Ubicomp, to
  appear
• (2006).
• 12 SAVVIDES, A., GIROD, L., SRIVASTAVA, M., AND
  ESTRIN,
• D. Localization in sensor networks. In Wireless
• Sensor Networks, C. S. Raghavendra, K. M.
  Sivalingam,
• and T. Znati, Eds. Kluwer, 2004.