15-829A/18-849B/95-811A/19-729A Internet-Scale Sensor Systems: Design and Policy

15-829A/18-849B/95-811A/19-729AInternet-Scale Sensor Systems: Design and Policy Lecture 2 – IrisNet System Overview Phil Gibbons, Intel Research Pittsburgh Adjunct Associate Professor CMU

Outline • IrisNet big picture • IrisNet demo • IrisNet further details • IrisNet mini-projects

IrisNet Team • Srini Seshan, CMU • Brad Karp, Intel Research Pittsburgh • Suman Nath, CMU • Yan Ke, CMU • Amol Deshpande, U.C. Berkeley • Phil Gibbons, Intel Research Pittsburgh • Also many valuable suggestions from Satya, CMU

A World of Smart Sensors • Webcams & other smart sensors are everywhere, collecting vast amounts of data • But, no effective tools for querying this data and extracting useful information • Opportunities for new sensor-based services • Rich, high bit-rate data sources • Rich expressive queries: range queries, aggregate queries, historical queries • Internet-scale: view vast collection of widely distributed sensors as a single queriable unit

Example: Parking Space Finder • A distributed database maintains • Spot availability data • Address of parking spot • Meter description • Historical availability data • Query: Where is the cheapest empty parking spot near Intel Research? • Returns driving directions to the best spot One of many possible sensor services

IrisNet: Internet-scale Resource-intensive Sensor Network services IrisNet Other Sensor Projects Webcams are typically attached to computers with significant processing power & memory

“Smart Dust” mote hardware TinyOS, TinyDB, etc. campus-scale minimal sensor processing energy is a key concern scalar sensors narrowly focused services ad hoc wireless connectivity “Brilliant Rocks” PCs/PDAs Linux, Java, XML, C++ Internet-scale intensive sensor processing powered nodes multimedia sensors wide variety of services direct Internet connectivity Brilliant Rocks vs. Smart Dust Complementary agendas

IrisNet Goal: Build a scalable infrastructure for deploying sensor-based Internet services (using brilliant rocks) with • Efficient query processing • Filtering rich data feeds • Shared sensors • Internet-scale • Ease of service creation

IrisNet Some Challenges: • richness of query language vs. system complexity • query routing at Internet-scale • service-specific code at sensors requires domain knowledge • trust / isolation in sensor sharing • scalability and peak load performance • ease of service creation vs. heterogeneous services

IrisNet Architecture Internet Sensing Agent Organizing Agents User Sensing Agent Sensing Agent • Organizing Agents (OA): • PC-class or server-class processor, GBs of storage, Linux • Sensing Agents (SA): • PDA/PC-class processor, MBs–GBs storage, Linux

Sensing & Organizing Agents SA OAs SA • Sensing agents (SA) • Collect & process data from sensors • Shared across services • Execute “senselet” code uploaded by OAs • Send extracted information back to the OAs • Organizing agents(OA) • Provide database & query facilities • Group of OAs dedicated to one service • Index, archive, aggregate, mine & cache data from SAs • Provide mechanisms for discovering relevant sensors, dealing with transient agents and balancing load across agents

OA Groups Parking Space Finder Organizing Agents Sensing Agent Sensing Agent University Downtown Museum Internet Sensing Agent Sensing Agent Amy-John Kim-Steve Tom-Zoe Person Finder Organizing Agents Sensing Agent Sensing Agent

IrisNet Key Features • Rich query language with low-latency queries • Flexible data partitioning • Efficient & protected sharing of sensor nodes • Partial match caching • Query-specified freshness tolerances • Monitoring & logging support • Ease of sensor service deployment

Deploying a Webcam Sensor Service • IrisNet provides: • Query Processing • Networking • Caching & Load balancing Send to OA Updates DB FFFFEFF Image processing steps • Locate desired webcams (add more if needed) • Create XML Schema • Defines distributed database & logical OA hierarchy 3. Create senselet code & download to SAs • Create web-based front end that fires off XPATH queries

Outline • IrisNet big picture • IrisNet demo (20 min video) • IrisNet further details • IrisNet mini-projects

Outline • IrisNet big picture • IrisNet demo • IrisNet further details • SAs & senselets • OAs & query processing • Example services • IrisNet mini-projects

Senselets • Binary code fragments uploaded by OAs to SAs • Perform intensive data filtering • E.g., image processing • Leverage available processing power and memory • SAs reduce high sensor data rates (e.g. webcams) into low rates • data reduction is through service-specific code

Bandwidth Reduction Parking Space Finder: Video feed distilled to full/empty spots

Sensing Agents Shared by Services • Each SA can host senselets for multiple services simultaneously • Goal: Avoid redundant processing & duplicate storage • Senselets use image processing library stored on SA • Window of sensor feed stored in shared memory segment • Filters read named segments, store into named segments • Automatically avoid many redundancies • E.g., multiple services want edge detection but do only once • Issues:Scheduling, Protection, Resource allocation

Languages • Data stored in XML databases: + Supports a heterogenous mix of self-describing data + Supports on-the-fly additions of new data fields • Queries in XPATH: • Standard XML language with good DB support • OAs written in Java: + Language of choice for native XML databases + Safe mobile language • SAs written in C: + Most widely portable to low-end computers (e.g., “bricks”) + Have open-source image processing library (from Intel)

XML <parking @status=‘ownsthis’> <usRegion @id=‘NE’ @status=‘ownsthis’> <state @id=‘PA’ @status=‘ownsthis’> <county @id=‘Allegheny’ @status=‘ownsthis’> <city @id=‘Pittsburgh’ @status=‘ownsthis’> <neighborhood @id=‘Oakland’ @status=‘ownsthis’> <block @id=‘1’ @status=‘ownsthis’> <address>400 Craig</address> <parkingSpace @id=‘1’> <available>no</available> <parkingSpace @id=‘2’> <available>no</available> </block> <block @id=‘2’ @status=‘ownsthis’> <address>500 Craig</address> <parkingSpace @id=‘1’> <available>no</available> </block> </neighborhood> </county></state></usRegion></parking>

Query Processing: Context Pittsburgh Squirrel Hill Oakland Shadyside 400 Craig 500 Craig • Hierarchy defined by schema: NE – PA – Allegheny - Pittsburgh – Oakland – 400 Craig Block – parking space • Each OA in the network owns a part of the data • E.g., Pittsburgh OA owns aggregate info about Pittsburgh but not the per-neighborhood details; plus it knows the names of its children • Note: May cache other data (e.g., from its children) • Note: IP address of an OA may change

Query Processing: Context Pittsburgh Squirrel Hill Oakland Shadyside 400 Craig 500 Craig • User at browser asks about available parking near Intel Research Pittsburgh • Converted to an XPATH query (for the parking database): /usRegion[@id=‘NE’]/state[@id=‘PA’]/…/neighborhood[@id= ‘Oakland’]/[some predicate] • Web server for www.parking.intel-iris.net receives posted query, passes on to local OA

/parking/usRegion[@id=‘NE’]/state[@id=‘PA’]/county[@id=‘Allegheny’]/neighborhood[@id=‘Oakland’]/block/parkingSpace[available=‘yes’]/parking/usRegion[@id=‘NE’]/state[@id=‘PA’]/county[@id=‘Allegheny’]/neighborhood[@id=‘Oakland’]/block/parkingSpace[available=‘yes’] <parking @status=‘ownsthis’> <usRegion @id=‘NE’ @status=‘ownsthis’> <state @id=‘PA’ @status=‘ownsthis’> <county @id=‘Allegheny’ @status=‘ownsthis’> <city @id=‘Pittsburgh’ @status=‘ownsthis’> <neighborhood @id=‘Oakland’ @status=‘ownsthis’> <block @id=‘1’ @status=‘ownsthis’> <address>400 Craig</address> <parkingSpace @id=‘1’> <available>no</available> <parkingSpace @id=‘2’> <available>yes</available> </block> <block @id=‘2’ @status=‘ownsthis’> <address>500 Craig</address> <parkingSpace @id=‘1’> <available>yes</available>

Data Partitioning • IrisNet permits a very flexible partitioning scheme for distributing fragments of the (overall) service database among the OAs • “id” attribute defines split points • Minimum granularity for a partitionable unit • Id of a split node must be unique among its siblings • Parent of a non-root split node must also be a split node • An OA can own (and/or cache) any subset of the nodes in the hierarchy, as long as • Ownership transitions occur at split points • All nodes owned by exactly one OA

Data Partitioning • Data fragment at an OA stored as a single XML document in the OA’s local XML database • The ids on the path from the root to a split node form a globally unique name • Global name to OA mapping: • Store in DNS the IP address of the OA • When change ownership, just need to update DNS • Initially, overall service database on a single OA • Command line partitioning, or specify partitioning order pittsburgh.allegheny.pa.ne.parking.intel-iris.net -> 128.2.44.67

Self-Starting Distributed Queries • Each query has a hierarchical prefix /usRegion[@id=‘NE’]/state[@id=‘PA’]/county[@id=‘Allegheny’] /city[@id=‘Pittsburgh’]/ rest of query • Simple parsing of id chain to extract global name • Do DNS lookup on pittsburgh.allegheny.pa.ne.parking.intel-iris.net to locate the Pittsburgh OA • Send query to that OA • OA is the least common ancestor (LCA) of the (possible) query result • Name extracted from query without any global or per-service state at the webserver’s OA

QEG Querying Model Query Evaluate Gather (QEG) Upon receiving a (sub-)query Q, an OA: • Queries its local XML database • Evaluates what parts of the answer to Q are in its DB • Gathers the missing parts by recursively sending subqueries to its children Later, OA combines the returned answers (including its local answer) and returns an answer to Q QEG Techniques: Key contribution of our research

Query Evaluate Gather Pittsburgh OA Q 1. Queries its XML DB 2. Evaluate the result Discovers Shadyside data is cached, but not Oakland Does DNS lookup to find IP addr for Oakland Q’ Oakland OA QEG Q’: /NE/PA/Allegheny/Pittsburgh/Oakland/ rest of query /NE/PA/Allegheny/Pittsburgh/(Oakland | Shadyside) / rest of query 3. Gathers the missing data by sending Q’ to Oakland OA Combines results & returns

Cache Consistency • All data is time stamped • Include timestamp field in XML schema • When cache data, also cache its time stamp • Queries specify a freshness requirement • “I want data that is within the last minute” • “Have you seen Joe?” – today? this morning? last 10 minutes? • QEG procedure ignores too-stale data • Carefully designed set of cache invariants & tags ensure that the correct answer is returned Exploring other consistency conditions

Historical Trends:Parking Space Finder • Using historical availability information, may provide more helpful answers There are no spaces available near your destination, but if you drive around the block twice, one will likely open up… (also useful in a Mall parking lot) Working on aging techniques for historical data

Coastal Monitoring • Team of oceanographers at Oregon State • Use cameras to record continuous video feeds of a coastline area • Process the video to detect & analyze sandbar formation and riptides In progress: Coastal Monitoring using IrisNet

Waiting Time Monitors • I need to mail a package. Which post office has the shortest wait, counting my drive time? • Which lunch trailer with vegetarian food and reasonable prices has the shortest service time? • Do I have time to grab a hot dog between innings, and which nearby foodstand has the shortest wait? • I need to drive downtown, which way should I go?

Locator Services • Where are my project team members? • I lost my umbrella today on the CMU campus. Help me find it. • Show me where my children are playing in the neighborhood. • Where is language X being spoken?

Silent Witness • A webcam hidden in a “rock” monitors by lawn. • It silently maintains a circular buffer of 2 days video. • One day, I discover dog poop. Who’s dog pooped on my lawn? What animal ate my flowers? Who stole my bike? Motion-triggered surveillance is insufficient in high motion environments

Triggered Event Monitors • “Jason Query”: Send an alarm to my screen when you see the 61 bus coming down the street. • Next time that dog wanders on my lawn, alert me. • Near-Accident Witness: Monitor a street intersection as a silent witness, but when you hear the sound of a car horn, save the video from 1 minute before the horn to 3 minutes after.

IrisNet • A software infrastructure for extracting useful data from webcams & other sensor data • Providing efficient querying mechanisms • Based on XPATH & XML, plus QEGs & DNS • Ease of webcam service creation • Define Schema, Senselets, Web front-end • Dynamically adapting to changes • Abstractions hide location, Flexibility of XML • Designed for world-wide scalability

Outline • IrisNet big picture • IrisNet demo • IrisNet further details • IrisNet mini-projects

Class Mailing List • Subscribe to class email list irisnet-course@intel-iris.net • How? Send email to majordomo@intel-iris.net with the text subscribe irisnet-course in the body • Will go through a confirmation process

Next Lecture • Topic: IrisNet code overview & project suggestions • Assigned reading: • [N+03] IrisNet: An Architecture for Compute-Intensive Wide-Area Sensor Network Services (if didn’t read it yet) • [G+03] Building Internet-Scale Sensor Services using a Hierarchy of Brilliant Rocks (will post Friday) • No hand in question for Tues • Class web page: http://www.cs.cmu.edu/~srini/15-829A • IrisNet home page: http://www.intel-iris.net/ • Under construction • Browse through download (but don’t download yet) & documentation

Mini-Projects • Assigned on Tues • 14 page handout given out on Tues • Give laptops & webcams on Tues • Need 2 machines (Linux) for mini-project • Do individually • Due Feb 4

Deploying a Person Finder Service • IrisNet provides: • Query Processing • Networking • Caching & Load balancing • Set up IrisNet to process canned video feed • Create XML Schema • Defines distributed database & logical OA hierarchy • Create senselet code & download to SAs • Create web-based front end that fires off canned XPATH queries Send to OA Updates DB Phil Image processing steps

15-829A/18-849B/95-811A/19-729A Internet-Scale Sensor Systems: Design and Policy