CS 219 :: Wireless Urban Sensing Systems

1
CS 219 Wireless Urban Sensing Systems FIND
Proposal Presentation Andrew ParkerSasank
Reddy
2
Overview

• Introduction
• Sensing Contexts
• System Architecture
• Technical Approach
• Applications

3
FIND Challenge

• FIND (Future Internet Network Design) asks two
  broad questions
• What are the requirements for the global network
  of 15 years from now - what should that network
  look like and do?
• How would we re-conceive tomorrow's global
  network today, if we could design it from scratch?

4
Urban Sensing Systems FIND Proposal

• How can clean-slate design of the internet better
  support Urban Sensing Applications?

CENS Deborah Estrin Andrew Parker Sasank
Reddy Ganeriwal Saurabh Mani Srivastava
ICIR Mark Allman Vern Paxon
Embedded Systems Sensor Networks Internet
Architecture Data Statistics Social
Sharing Interactive Media
Hypermedia Jeff Burke
UCLA Stats Mark Hansen
5
Urban Sensing Systems FIND Proposal

• New sensing contexts raise many challenging
  questions that require a new network
  architecture.
• Dissemination
• How can we make it easy for people to share data?
• Selective Sharing
• While still respecting privacy concerns?
• Verification
• Can the network assure basic quality checks on
  data and context?
• Ideas that will influence this new architecture
  include
• Space-Time coordinates as network primitives.
• Policy-mediated rendezvous based on data
  properties and meta-data.
• Aggregation-based reliability -- good enough
  equivalence.

6
Sensing Contexts (Urban)

• Urban applications are based on sensors that
  are already out there.
• Mobile phones and PDAs can provide audio,
  images, coarse-grained localization.
• Hardware is not controlled by central agency.
• Citizens carry sensors, contribute data about
  their surroundings.
• Fusion of several entities (citizens) gives
  interesting data points.
• Two specific scenarios considered
• Private citizen installs a sensor in their
  private space.
• Private citizen carries or deploys a sensor in a
  public space.

7
Sensing Contexts (Urban)

• Private Citizens, Private Spaces
• Personal applications - data is generally
  strictly personal and the citizen will expect
  privacy (health monitoring).
• Social applications - share data with a small
  circle of friends (Flickr).
• Urban applications - citizens share data as part
  of city or state-wide project (blogs).
• Private Citizens, Public Spaces
• Monitoring the public domain space by private
  citizens.

8
Sensing Contexts (Urban)

• Guidelines for Privacy and Selective Sharing
• It is important that context of data be
  verifiable to the to a resolution with which the
  provider is comfortable.
• Policies for selective sharing must be
  implemented as an automated component of a
  sensing system.
• Decisions about data sharing depend often on
  location and time.

9
System Architecture
10
System Architecture

• Sensors
• Sources of data at the edges of the network
  (acoustic, image, vital sign, etc)

11
System Architecture

• Subscribers
• Sinks of sensor data.
• Individual users interested in data streams and
  event notifications.
• Network applications for archiving, aggregation,
  distillation, and signal search.

12
System Architecture

• Mediators
• Provides selected in-network functions on
  sensor data streams.
• Selective Sharing
• Policy enforcement and negotiation on behalf of
  a publisher or subscriber
• performing anonymization by removing
  identification information.
• Verification
• enhancing streams with attested contextual
  information.
• performing simple range/proximity checks.
• Dissemination
• replicating streams for delivery to different
  nodes.
• providing reliability in the presence of
  disconnections.

13
System Architecture

• Client (of subscriber)
• Clients are end-users that go to sites that have
  already crawled or aggregated data.

14
System Architecture

• Registries
• Network entities that help subscribers discover
  and bind with sensor data streams.
• Provide a service analogous to that of the Domain
  Name Service (DNS), with a model of
  administration and deployment-ubiquity similar to
  DNS servers.
• The registry maps the query via a tuple space
  search process to return a handle to the sensor
  data stream (or, in general, a set of handles).

15
Certificate Authority
Sensor
Mediator1
Registry
Mediator2
Subscriber
Client
CA signs ID for Sensor
The sensor registers a data stream.
Sensor starts sending data
A subscriber makes a query via its mediator.
The registry forwards to mediator1, which then
negotiates with mediator2.
Possibly some limited tasking occurs as a result
of the new subscriber.
Mediator1 sends data to Mediator2, which in turn
forwards to the subscriber.
Subscriber accumulates, aggregates, and may
respond to clients of its own.
16
Technical Approach Context Verification and
Resolution Control

• Properly interpreting sensor information
  requires both the data values and description of
  physical context
• Data streams are augmented by contextual
  information by the sensors and mediators
• Verification of other contextual features
  (orientation, configuration, etc.) and the data
  themselves must rely upon comparisons to other
  sensors.

17
Technical Approach Context Verification and
Resolution Control

• Spatiotemporal Context
• Time and Location of when the data was injected
  are contexts to which the redesigned internet may
  directly attest.
• How might this be done?
• NTP based time stamp protocols.
• Signal strength ranging or radio time of flight
  can be used by a base station to measure
  distance to a sensor node for location
  information.
• GPS is a simpler method to perform these
  actions.

18
Technical Approach Context Verification and
Resolution Control

• Spatiotemporal Context
• What about cheating?
• Cryptographic distance bounding to verify.
• Hidden/trusted nodes can be used to advert
  cheating.
• Secure time synchronization does exist as well.
• Expanded applications possible.
• Use spatial/time data for routing instead of IP,
  supporting anonymity and mobility

19
Technical Approach Context Verification and
Resolution Control

• Physical Context and Sensor Data Validation
• Physical context information useful for
  validating integrity of information provided by
  sensor.
• Aggregation can aid in verifying sensor data.
• Mediators might have rules that provide a suite
  of aggregation capabilities on values for
  validation purposes.
• Reputations or trust level can be tagged to the
  data based on feedback from different network
  layers.

20
Technical Approach Context Verification and
Resolution Control

• Resolution Control
• Though high resolution data and contextual
  information may be available, the publisher may
  want to reduce this resolution when its released
  to the subscriber
• Mediators act to protect both data and
  contextual information, physically, through
  indirection, and statistically, through its
  access to similar data sources, while
  simultaneously providing some degree of
  verification
• Mediators protect at a network level through
  interposition
• Mediators protect statistically through
  aggregation, down-sampling, blurring, and other
  anonymization techniques

21
Technical Approach -- Application Services

• Naming Registry
• Names touch on how we do dissemination,
  selective sharing, and verification.
• Sensor submits to its mediator a set of
  attributes and disclosure rules.
• Mediator augments with verified attributes
  before forwarding to the registry.
• Subscriber resolves attributes to data streams
  using request to its mediator.
• That mediator augments the request with
  verified attributes describing the
  requesters and forwards to a registry.
• Registry returns handles to data streams if
  attributes and disclosure rules match.

22
Technical Approach -- Application Services

• Aggregation
• The goals of the architecture are to ease and
  encourage publication of sensor data by
  independent data providers, as
• well as application development by 3rd
  parties that pull on the published data
  streams.
• The primitive functionality provided by the web
  services will include aggregation,
  processing, and querying.
• The elements providing these services are
  called Application Servers, and act as
  subscribers to data streams.

23
Experimental Validation

• Personal Health Monitor
• Remote medical diagnostic and treatment system
  that connects health metrics of a mobile
  patient to a care provider.
• Urban Scale Sound Level Mapping
• The creation of a framework for opt-in
  participation in mapping city sound levels
  through cell phones.
• Presence-authenticated Social Data Sharing System
• Develop an image, sound and text sharing
  application, roughly a location-tagged Flickr.

24
Experimental Validation Personal Health Monitor

• Personal Health Monitor

25
Experimental Validation Personal Health Monitor

• Personal Health Monitor
• Health data would be regularly sampled as
  required by a physician and published to the
  network.
• The user receives the BAN/PMH from their health
  care provider and, with their physicians staff,
  selects sharing options in additional an
  invariant personal data privacy policy.
• The provider embeds the names and identity
  verification method for its application servers
  in the devices firmware.
• The application servers are informed of the
  patients data names when the BAN/PMH is provided
  to the patient.

26
Experimental Validation Personal Health Monitor

• Personal Health Monitor
• When the BAN/PMH comes in contact with a
  mediator, it advertises its data and sharing
  policy, providing metadata such as its own
  location/time information (UCLA Medical Plaza,
  2006, 05, 08, 1321), data type tag (ECG), data
  format tag (beats/sec), and unique id (Patient
  X).
• The mediator verifies the data sources identity
  through a certificate authority, logs the
  space-time context, then registers the data name
  and its sharing policy.
• The PMB source sends data to its mediator,
  expires if there are no sinks.

27
Experimental Validation Personal Health Monitor

• Personal Health Monitor
• Asynchronously, the providers application
  servers query the registry via their local
  mediator and, after authentication of identity,
  receive the patients data.
• Via the network, this data is forwarded from a
  secure application server to a physician or
  caregiver, or logged for future diagnostic use.
• With multi-tiered disclosure rules, a variety
  of clients can be served.
• Privacy protection and uninterrupted data
  delivery for a mobile patient is a key advantage
  using multiple mediators that can hand off the
  source as it moves, the network can seamlessly
  route named data from the patient to the data
  sinks.

28
Experimental ValidationPresence Authenticated
Social Data Sharing
29
Experimental Validation- Soundscape Mapping
30
Experimental ValidationPresence Authenticated
Social Data Sharing
31
Experimental ValidationPresence Authenticated
Social Data Sharing
32
Application Authoring

• Development at three stages
• End-user data source applications
• Web Services on subscribers
• End-user data sink applications (running on
  public or personal servers and consumed on mobile
  devices)
• Development at three layers
• Graphical configuration
• Scripting/Gluing
• Lower-level service and library implementation

33
Application Authoring

• Forgrounded Concepts
• Resolution control
• Location and context tagging and verification
  (time/space/direction/WAPs/cell-towers/etc.)
• Closeness of mapping to devices parameters
• Rapid online modifications during development and
  testing
• Tools for managing time and distributed state

34
Deployment Platforms

• Intel X-Scale based platforms
• iPAQ Pocket PCs, Crossbow Stargates, CENS Low
  Power Energy Aware Processing notes
• Programmable cell phones
• Symbian OS, Linux
• Connectivity through GPRS, 3G networks, 802.11
• Directly attached to sensors, or anchor a cloud
  of wireless sensors

35
Experimental Validation Personal Health Monitor
Questions, Comments, Suggestions.