RFID Ecosystem

1
RFID Ecosystem

• Robert Spies
• In collaboration with
• Magda Balazinska, Gaetano Borriello,
• Travis Kriplean, Evan Welbourne
• Garret Cole, Patricia Lee, Caitlin Lustig, Jordan
  Walke

2
Overview

• Description of RFID
• Research Project Overview
• System Design
• System Deployment
• Conclusion/Questions

3
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

4
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
5
Why does RFID Matter?

• "The value of RFID is not within the
  physicsthe real value depends on how you create
  intelligence from all the data you capture.
• - Richard Wirt, Intel Senior Fellow

6
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

7
Application Area the Supply Chain

• RFID is expected to replace the UPC bar-code in
  the supply chain at the case level
• Focus on distribution channels
• Goal is item-level tagging
• 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

8
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
/
9
Areas of Exploration

• Question What are the implications for
  technology, business and societyof 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

10
What we are Building

• We are building a privacy-centric distributed
  system for RFID-based applications

11
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
• Floor 1, elevators, etc.
• Focused on occupants of upper floors

Key Antenna Reader
12
System Design Goals

• User Privacy Paramount
• Ease of Use
• API presented to user facilitates application
  development
• Customization
• Event updates and definitions
• Robustness
• Scalability

13
Privacy Model

• Basic working model known as Physical Access
  Control (PAC)
• A user is only allowed access to Tag Read Events
  (TREs) that they could have observed
• System determines line of sight interactions
• Special person tag determines users location
• Restricts user from even seeing TREs 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 TREs from that table and
  that table alone
• Replace with animation, explore trade offs, then
  intro pac

14
Privacy Model Cont.

• Tag Ids 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 TREs 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.

15
PAC example
Line-of-Sight Start End
A,C 2 5
D,C 7 9
F,E 12 15
16
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

17
Robustness and Scalability

• All servers in the system actively work to
  re-establish 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.

18

• 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 TREs in database
• Stores system metadata in database
• Node Servers
• Control reader hardware
• Collects TREs and forwards to cluster servers
• Data cleansing
• Slide of whatg this came from

19
Reason for 3-tiered Architecture

• Node server layer
• Used to control reader hardware
• Enables low level data cleansing
• Cluster server layer
• Need to combine streams of TREs to determine
  collocation essential to PAC
• Interface server layer
• Isolates computational resources
• Isolates API queries and allows resource
  replication if necessary
• scalability

20
Node Server

• Control reader hardware
• Collects TREs 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

21
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.

22
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

Interface Server
Cluster Server
wilford, -43254323532, 77, 11745617000
evan, -43254323532, 77, 11745617000
-43254323532, 77, 11745617000
gbc3, -43254323532, 77, 11745617000

23
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

24
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 summary slide

Start Event ltevent_updategt lttag_at_locationgt
ltevent_typegtstartlt/event_typegt
lttag_idgt5436234543lt/tag_idgt
ltlocationgt88lt/locationgt
lttimestampgt117123879229lt/timestampgt
lt/tag_at_locationgt lt/event_updategt
End Event ltevent_updategt lttag_at_locationgt
ltevent_typegtendlt/event_typegt
lttag_idgt5436234543lt/tag_idgt
ltlocationgt88lt/locationgt
lttimestampgt1171239700000lt/timestampgt
lt/tag_at_locationgt lt/event_updategt
25
Interface Server Event Hierarchy
PersonAssociation

• From low level events, we can infer more complex
  interactions
• Provides a hierarchical event structure
• Processes (what we anticipate will be) common use
  cases

PersonContact
PersonAtLocation
TagAtLocation
26
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 Servers API
• Allows users to customize events
• Borealis Event Definitions are xml formatted
  files, specified by Borealis own public API

27
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

28
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 Yellow User
• Tag Location Tag Location
• blue_tag 88 blue_tag 88
• Yellow_tag 88 yellow_tag 88

29
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 Users 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 Yellow User
• Tag Location Tag Location
• blue_tag 88 yellow_tag 87

30
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

31
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. queryGET_OBJECT_METADATA
• Get Raw TREs
• Take parameters that can specify start time, end
  time, antenna id, and tag id
• Ex. queryGET_RAW_TAG_DATAant_id88start1708767
  6
• Ex. queryGET_RAW_TAG_DATAdistincttag_id1123321
  2332 ant_idstart17087676
• Get Reader and Antenna Metadata
• Ex. queryGET_OBJEC
  T_METADATA

32
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)

33
Interface Server DB Schema
Actual Schema
API Schema
object_metadata( object_id int, type_id int,
owner varchar(20), personal boolean,
description varchar(160), )
objects ( object_id int, type_id int,
user varchar(20), personal boolean,
description varchar(160), )
pac_wilford( tag_id bigint, ant_id int,
timestamp bigint, rssi I nt )
tag_reads( tag_id bigint, ant_id int,
timestamp bigint, rssi I nt )
34
Interface Server Custom Queries

• When a custom query is received
• Checks if the query contains any actual names of
  meaning in the database if it does, throws out
  query
• Then maps symbolic API names to actual database
  table names
• Can be simple mapping objects -gt object_metadata
• Special cases tag_reads -gt pac_wilford
  (requires determining who the identity of the
  user)
• Parse the query and add necessary constraints
• 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

Exput on other slide 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.ownerwilford) and x.ownerwilford
35
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

36
User Case Visual Object Tracking
lt LIVE DEMO! gt
37
User Case Visual Object Tracking
Introduce map and what everything means before
running demo
38
User Case Visual Object Tracking
lt/ Live Demo!gt (Sorry, had to do it)
39
Application Tag Info Editor
40
Use Case Social History

• Query Personal History
• Paths Walked, Objects Seen, People Seen With
• Where was my bag last seen at?

41
User Case Support Application

• Support interested in an application that helps
  with inventory management
• Includes tagging every object of value owned by
  the CS department
• Inventory tracking extremely easy
• 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.

42
The Future

• Explore low level data aggregation
• A tag sitting under a reading will generate 50
  TREs a second, 300 TREs 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!

43
The Near Future

• Continue Populate Allen Center with readers
• Achieve better coverage
• Full scale test of system over the summer
• Include participants not in the Research group
• Explore the benefits and limitations of PAC
• Open the RFID Ecosystem for applications

44
Questions?
45

• 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