Transcript Interface Servers - The RFID Ecosystem Project

RFID Ecosystem
Robert Spies
In collaboration with
Magda Balazinska, Gaetano Borriello,
Travis Kriplean, Evan Welbourne
Garret Cole, Patricia Lee, Caitlin Lustig, Jordan Walke
Overview
Description of RFID
 Research Project Overview
 System Design
 System Deployment
 Conclusion/Questions

What is RFID?

Radio Frequency Identification

RFID systems comprise tags and readers
Tags are placed on objects
Readers interrogate tag through RF

Does not require line-of-sight





Tags are Small and cheap (~$.25/tag)
Tag IDs able to uniquely identify every object in the world
(Current tags use 64 to 128 bits)
Can include other information besides ID



Current State
Location
History
RFID Basics

Tags can be active or passive

Active tags: battery, expanded capability, longer range
Passive tag: receives power from RF field, limited
capability

What is means to not have battery table?

Active Tag
Passive Tag
Why does RFID Matter?
"The value of RFID is not within
the physics—the real value
depends on how you create
intelligence from all the data you
capture.”
- Richard Wirt, Intel Senior Fellow
Barcode vs. RFID

RFID tags are expected to replace the UPC
barcode





Unlike barcode scanners, RFID readers do not require a
line of sight
Tags are less susceptible to damage
RFID readers can both read and write data
Leads to many advantages in supply chain automation
There are Privacy concerns…

More on those later

Scan many rfid tags at once, rfid tags id object, not
class of obj
Application Area: the Supply Chain

RFID is expected to replace
the UPC bar-code in the
supply chain at the case level


Goal is item-level tagging





Focus on distribution channels
Ability to track inventory
Automated checkouts
Recalls
Ability to write information
directly onto product
~100 Wal-Mart suppliers use
RFID tags

Best Buy, Target, and DoD are
also issuing RFID-related
mandates

Collapse into one slide, with
multiple examples
Application Area: Passports

US passports now issued with RFID
tags.

Chip contains the same information
as the printed document (name, photo,
etc…)

Goal is to allow easy scanning of the
passport and cross-referencing of
security database

Worries from privacy advocates about
amount of information available to
identity thieves, terrorist, etc.



Data is encrypted
Security firm was able to crack the
encryption on Dutch RFID passports
Case Provides an “RF Shield”
Image source: http://www.msnbc.msn.com/id/11748876/
Areas of Exploration


Question: What are the implications– for
technology, business and society—of having a
“number on everything”?
What issues do we have to address to enable
RFID-based consumer applications


Privacy is a major issue
Deployments, utility, ease-of-use, etc.

Design a system with a centralized database to
explore the tradeoffs between user privacy and
system utility

Try to scale back verbosity
What we are Building

We are building a privacy-centric distributed
system for RFID-based applications
Populating the Allen Center with Readers:
Initial Deployment

33 readers, 132 antennas

Placed on floors 2-6

Good start, but still
inadequate; key areas are
not covered


Key
Floor 1, elevators, etc.
Focused on occupants of
upper floors
Antenna
Reader
System Design Goals
User Privacy Paramount
 Ease of Use



API presented to user facilitates application
development
Customization

Event updates and definitions
Robustness
 Scalability

Privacy Model

Basic working model known as Physical Access Control
(PAC)

A user is only allowed access to Tag Read Events (TRE’s)
that they could have observed





System determines line of sight interactions
Special “person” tag determines user’s location
Restricts user from even seeing TRE’s for tags they own
if they are not near them
Gives user “Perfect Memory”
Database contains per user TRE tables

Each user has their own TRE table.
The user can view the TRE’s from that table and that table
alone

Replace with animation, explore trade offs, then intro pac

Privacy Model Cont.

Tag Id’s hashed before being stored in the system

Makes it more difficult for an adversary to infer meaning from
database tables if database is compromised

Users can label tags as public or private, PAC respects this

Users can purge tag data at any time through a provided
API

All TRE’s from unregistered tags are discarded

CSE kerberos authentication required to access data

Instead of one big table, many little tables, advantages in
implementain, own table v views.
PAC example
Line-of-Sight Start
End
A,C
2
5
D,C
7
9
F,E
12
15
Ease of Use



Beyond raw tag reads, the RFID Ecosystem will
provide higher-level inferences about tag data.
For applications, we provide an xml based API
accessible over both a socket and web connection
For users, a tag programming application is
provided that allows users add tags to the system
and alter metadata about their tags

Whether its private, the description, etc.

Two sections, ease of use for the programer, ease of use
for users gui
Robustness and Scalability

All servers in the system actively work to reestablish lost connections.

If work load is too large, each process in the
system can be replication on another machine to
reduce the work done on a single computer

All input servers are determined at runtime from
a database. Additional servers can be added on
the fly.
Interface Servers
• Compute higher level events
• Store higher level event history to
local DB
• Support API
• Stream higher level events to
application
• Respond to application queries
Cluster Servers
• Implementation of PAC
• Stores TRE’s in database
• Stores system metadata in database
Node Servers
• Control reader hardware
• Collects TRE’s and forwards to
cluster servers
• Data cleansing
•Slide of whatg this came from
Reason for 3-tiered Architecture

Node server layer



Cluster server layer


Used to control reader hardware
Enables low level data cleansing
Need to combine streams of TRE’s to determine
collocation essential to PAC
Interface server layer

Isolates computational resources
Isolates API queries and allows resource replication if
necessary

scalability

Node Server





Control reader hardware
Collects TRE’s and
forwards a tuple of the
form
{tagid, antenna_id,
timestamp} to Cluster
Servers
Future Goals: Include low
level stream cleaning
Unreliable, summarizartion
How much data, introduce
earlier
Cluster Server

The database
server(s)

Database contains
table of TREs for each
PAC user

Metadata tables as
well



Information about the
objects tags are on
Reader and antenna
information
etc.
Cluster Server (Cont.)

Receives each TRE from Node Server and
propagates through Access Control Switch (ACS)

ACS contains implementation of PAC

Determines which user can see which TRE, and
stores TREs in appropriate PAC user tables.

For each User-TRE pair, Cluster server forwards
{user, tre} tuple to Interface Servers
Cluster Server
{-43254323532, 77, 11745617000}
Interface Server
{wilford, {-43254323532, 77, 11745617000}}
{evan, {-43254323532, 77, 11745617000}}
{gbc3, {-43254323532, 77, 11745617000}}
…
Interface Server



Compute higher-level
events based on raw
TRE stream from
cluster servers
Maintain connections
with applications
Supports a push and
pull based API


Events are pushed to
the Applications when
computed
Applications can query
data from the
Ecosystem
Interface Server: Push API


Events Computed by Interface Server pushed to user
The lowest level event computed is TagAtLocation


Per antenna, sends the application an alert when a tag is first
seen at an antenna, and then when it has left the antenna
Essential due to the high amount of TREs generated
Most user do not care about every TRE generated, but do care
about entrance and exit events
 How to computer end event
 Talk about how this was most of my work that I did or in
Start Event
End Event
summary slide

<event_update>
<tag_at_location>
<event_type>start</event_type>
<tag_id>5436234543</tag_id>
<location>88</location>
<timestamp>117123879229</timestamp>
</tag_at_location>
</event_update>
<event_update>
<tag_at_location>
<event_type>end</event_type>
<tag_id>5436234543</tag_id>
<location>88</location>
<timestamp>1171239700000</timestamp>
</tag_at_location>
</event_update>
Interface Server: Event Hierarchy


From low level
events, we can
infer more complex
interactions
Provides a
hierarchical event
structure

Processes (what we
anticipate will be)
common use cases
PersonAssociation
PersonContact
PersonAtLocation
TagAtLocation
Interface Server: Borealis

Borealis [MIT, Brandeis, Brown] stream
processing engine


For real-time processing of sensor data.
Allows users to define their own events
over the TREs, and then deploy this to
Borealis via the Interface Server’s API


Allows users to customize events
Borealis “Event Definitions” are xml formatted
files, specified by Borealis own public API
Interface Server: Event Streams

Each event is computed per user


Interface Server receives {user, tre} tuple for
each user that is allowed to see a tre
Results in a logical event stream for each user

This is because PAC dictates when each
user can see a TRE

Duplicate events will be computed for
different user
Interface Server: Event Streams

Blue User holding blue_tag, Yellow User
holding yellow_tag

Users meet at Antenna 88 at time t1

PAC detects this, begins streaming
tuples of the form:
{blue_user ,{blue_tag, 88, t1}}
{blue_user ,{yellow_tag, 88, t1}}
{yellow_user ,{blue_tag, 88, t1}}
{yellow_user ,{yellow_tag, 88, t1}}

This starts TagAtLocation events for
each user
Blue User
Tag
Location
blue_tag
88
Yellow_tag 88
Yellow User
Tag
Location
blue_tag
88
yellow_tag 88
Interface Server: Event Streams

Sometime later at time tΔ later Yellow
user has moved to antenna 87 while
Blue User remains at 88

PAC detects that there is no longer line
of sight between Yellow User and Blue
User, stops sending tuples of the form
{blue_user ,{yellow_tag, 88, tΔ }}
{yellow_user ,{blue_tag, 88, tΔ }}

But Blue User’s TagAtLocation for
blue_tag still persists. And Yellow User
now has a TagAtLocation event for
yellow_tag at location 87.

To respect the privacy model, Blue User
and Yellow User must not know of each
others TagAtLocation events
Blue User
Tag
Location
blue_tag
88
Yellow User
Tag
Location
yellow_tag 87
Interface Server API: Pull based

API also allows pull based model. Users can
query the ecosystem for historical data.

Access to data such as TREs (per user), antenna
and reader metadata, object metadata

Also allows updates on this information:



Delete all tag reads from last Tuesday to today
Change an objects description
Change the object a tag is placed on
Interface Server API: Canned Queries

Predefined queries for ease of use
 Specially formatted query string
 Interface Server responsible for parsing the parameters
 Interface Server converts query string into SQL and runs query over
database
 Returns xml formatted String

Get Object Metadata (per user)
 Ex. query=GET_OBJECT_METADATA

Get Raw TRE’s
 Take parameters that can specify start time, end time, antenna id, and
tag id
 Ex. query=GET_RAW_TAG_DATA&ant_id=88&start=17087676
 Ex. query=GET_RAW_TAG_DATA&distinct&tag_id=11233212332
&ant_id&start=17087676

Get Reader and Antenna Metadata
 Ex. query=GET_OBJEC
T_METADATA
Interface Server: Custom Queries

Canned queries inadequate to cover queries a
users interested in

API allows user to write their own SQL queries
over the database

Database schema made public, but names
changed


Allows us to alter underlying schema without breaking
users queries
Also enables us to protect tables and data that the users
should not see about the ecosystem or each other (more
on that in a bit)
Interface Server: DB Schema
Actual Schema
object_metadata(
object_id
type_id
owner
personal
description
)
pac_wilford(
tag_id
ant_id
timestamp
rssi I
)
API Schema
int,
int,
varchar(20),
boolean,
varchar(160),
bigint,
int,
bigint,
nt
objects (
)
tag_reads(
object_id
type_id
user
personal
description
int,
int,
varchar(20),
boolean,
varchar(160),
tag_id
ant_id
timestamp
rssi I
)
bigint,
int,
bigint,
nt
Interface Server: Custom Queries
When a custom query is received:
1.
Checks if the query contains any actual names of meaning in the database: if it does,
throws out query
2.
Then maps symbolic API names to actual database table names


3.
Parse the query and add necessary constraints




4.
Can be simple mapping:
objects -> object_metadata
Special cases: tag_reads -> pac_wilford (requires determining who the identity of the user)
Ex. User should only be able to see object metadata about objects they own.
object_metadata is a common table
Parse the query and add necessary constraints wherever object_metadata is accessed
Need to deal with complex cases such as subqueries, inner joins, aliases, etc.
Run the query and return the results as an xml formatted string
lide english version of query
Query Sent to Interface Server:
Select x.description from objects as x where x.id in (select obj.id from objects as obj)
After Transformation:
Select x.description from object_metadata as x where x.id in
(select obj.id from object_metadata as obj where obj.owner=‘wilford’) and x.owner=‘wilford’
Interface Server: Connections

Interface Server handles both secure socket and
http connections


Tomcat Apache used for web front
Host info and port numbers publicly available

Authenticates users with CSE Kerberos

For event streaming on the web front, utilizes a
relatively new technology to do server push


Client and browser maintain persistent http connection
Only available on select browsers:



We only support Mozilla 1.5 and greater at this time
Not Available for IE yet
ASK GARRET ABOUT THIS
User Case: Visual Object Tracking
< LIVE DEMO! >
User Case: Visual Object Tracking
d what everything means before running demo
User Case: Visual Object Tracking
</ Live Demo!>
(Sorry, had to do it)
Application: Tag Info Editor
Use Case: Social History


Query Personal History
Paths Walked, Objects Seen, People Seen With

Where was my bag last seen at?
User Case: Support Application

Support interested in an application that helps
with inventory management


Inventory tracking extremely easy


Includes tagging every object of value owned by the CS
department
Where is Laptop X, and/or where has it been?
Allows a level of security and asset protection



Detect movement events
Is an asset on the move? Ensure that with an
authorized person
Security Alerts: “Why is this computer leaving the
building?” Alert the security guard appropriately.
The Future

Explore low level data aggregation

A tag sitting under a reading will generate ~50
TRE’s a second, ~300 TRE’s a minute,
~180000 an hour…
Fix your math
 Generates a large amount of relatively
uninteresting information.



Explore expanding window solutions: A TRE
per second, then per two seconds, etc.
But essential to catch when the tag is no
longer under the reader!
The Near Future

Continue Populate Allen Center with
readers


Full scale test of system over the summer



Achieve better coverage
Include participants not in the Research group
Explore the benefits and limitations of PAC
Open the RFID Ecosystem for applications
Questions?



Talk about numbers of reads per second.
Take out implementation of pac
Change diagram for pac demo. Annimated map demo. Have people pop up on map. Change
discussion of “why pac.” talk about discussions of extremes.

Shorten custom queries section

Maintains ssl connections on node server, authentication

Bring up main point of each slide or slides, bring up outline and how this relates to the bigger
picture.

Summary slide

Look at slide crowding remove a lot of text

Show base level architecture, and then how is grows with our implementation and how what we do
expands this