Design Project #2: Applications of Radio Frequency Tagging

In this project, you'll design an application that makes use of a new technology called 'radio frequency tagging'. We describe below a particular application (tracking students within MIT), but you are free to choose your own application instead. If you do so, you will be expected to hand in an additional one-pager describing its goals and key design issues.

A radio frequency identity (RFID) tag is a device that can be used to identify an object to which it is attached. The tag consists of an integrated circuit and an antenna, and is small enough to be sewn into a clothing label. When interrogated by a reading device, the tag discloses an identifier stored internally. No battery is necessary; the tag can be energized by waves received by the antenna. A tag stores 64 or 96 bits of data. A variant allows the tag to be written as well as read, but this adds enough to the cost to rule out use for the most compelling applications, in which tags are attached to inexpensive objects. A read-only tag currently costs about 5-10 cents, but the price is expected to drop sufficiently that, for most applications, the tags themselves will be considered free.

RFID readers, in contrast, are heavy and moderately expensive; they currently cost about $100, although the price will no doubt drop over time. The reading range depends on the frequency used, and whether the tag is equipped with its own battery. For your project, you should assume simple passive tags, which have a range of less than 10m.

Here are some ideas for applications, should you decide to pick one of your own:

If you choose to do the StudentTracker:

• In phase one, you'll write a one-pager outlining your design.
• In phase two, you'll develop a design, and prepare a report as described below.

If you choose an application of your own:

• In phase one, you'll write the one-pager outlining your design, and, in addition, a one-pager outlining the goals and design issues of the application you have chosen. These should take the same form as those sections we wrote for the StudentTracker application in this document.
• In phase two, you'll develop a design, and prepare a report as described below.

• Don't pick an application that is too complicated, or make it more complicated than necessary by adding gratuitous functionality. The usual mistake of first-time designers is to define and tackle a problem that is too big. It's better to think small, and do a modest problem in depth rather than a bigger one superficially.
• Make sure your description is crystal clear. If your recitation instructor doesn't understand exactly what you have in mind, he or she will be uncomfortable letting you proceed.
• Make sure that the design issues that you list in your one-pager are compelling, and that they establish a strong connection to the ideas you have studied in 6.033.

Student Tracker: Goals

StudentTracker is a system that provides students with information on the whereabouts of other students. It provides an interface that allows students to ask for the location of another student, and to specify which students may track them.

Two kinds of location are reported. Sometimes, the system will simply report that a student was last detected near a particular landmark: "1.10pm: waldo at food trucks". Often, though, it will be possible to report that a student is currently within a room or building: "11.35am: waldo in 34-101 since 11.05am". In this case, the location report will give the relevant room, and the time at which the student entered, in addition to the timestamp.

Location reports are delivered in two ways. In query mode, which is synchronous, a student asks for the location of another student, and awaits a response, which should be received in a few seconds. In callback mode, which is asynchronous, a student registers a request to be informed when another student arrives in a particular location; if and when that student appears in the specified location, the requester is notified. The system also offers historical reporting, which provides the locations of a particular student in the past, and the students at particular locations at given times.

The interface provides, in addition to the location function, some administrative functions. Each student may specify particular students or groups of students who may access his or her location. Tracking may be turned on and off in the short term for privacy, or when a student leaves town. A student may also revoke a particular tag issued to him or her, in case of loss or theft.

Tracking information must be timely. Timestamps must be accurate to within 10 seconds. Location records must be accessible (whether by query or callback) within a minute following the detection event. The system should be continuously available, with downtime never to exceed ten minutes in a single incident, and not to exceed 3 hours aggregated over an entire year.

It is up to you to determine what client devices are used for the interface. Different functions might be accessed with different devices: historical records, for example, might be available only on a desktop machine, whereas students might use handheld devices for queries and callbacks.

The system is intended for use at MIT. Your design may therefore take advantage of existing MIT infrastructure, such as Athena and zephyr.

Student Tracker: Design Issues

• What is the architecture of the system? How are servers connected to RFID readers? What devices do students use to query the system and register callbacks? Are the same devices used for administrative functions?
• Does your design make any assumptions about RFID technology beyond the properties mentioned in the overview above?
• How many readers does your design require, and how critical is their placement?
• How does the design prevent unauthorized access to location records? Are communications confidential and authenticated? If so, what methods are used, and how are keys distributed? Are users authenticated, and if so, how?
• What is the naming scheme for locations, within the system and as presented to users? How are students named?
• How is the system configured? How are locations associated with readers, and student names with tags?
• How does your design handle the requirements of historical reporting?
• Is your design susceptible to denial of service attacks? Suppose a malicious student writes a program that mimics a reader. How badly, and in what ways, might such a program damage your system?
• How does the system achieve availability and reliability? How does it handle unreliable hardware (flakey readers and tags, disk head crashes, etc.)? Network partitions? Dropped tags?
• How does the design ensure that the system's performance goals met? Under what conditions may performance degrade, and how often will such conditions occur?
• How does the system ensure a consistent view of time? Do readers have clocks that are synchronized, for example?
• How are entry and exit detected? How are readers setup to provide location information? Are there topological constraints? If so, what happens if they are violated?
• What assumptions does your design make about the reliability of RFID technology? About the behaviour of students, such as the speed at which they walk, or the number passing a reader at a given time?
• How well does your design scale? Could it handle a larger university with 30,000 students? How about a small town of 100,000? A city of 3 million?
• What risks to society does the system pose? How are they mitigated in your design?

Your Report

• a diagram of the overall architecture of the system;
• a detailed description of the key data structures used within servers, readers, and client devices;
• a clear indication of which functions belong within which physical devices;
• pseudocode for the key operations of the system;
• message structures and protocols by which readers and clients talk to servers.

Your paper must not exceed ten 11-point, single-spaced pages in length. Please use 1-inch margins. Don't forget to use diagrams where appropriate.

Writing Suggestions

1. Suggestions on Writing Style

Your paper should be as long as is necessary to explain the problem, your solution, the alternatives you considered, and the reasons for your choices. It should be no longer than that. Again, please make sure your paper is no longer than ten pages.

A good paper begins with an abstract. The abstract is a very short summary of the entire paper. It is not an outline of the organization of the paper! It states the problem to be addressed (in one sentence). It states the essential points of your solution, without any detailed justification. And it announces any conclusions you have drawn. Good abstracts can fit in 100-150 words, at most.

The body of your paper should expand the points made in the abstract. Here you should:

1. Explain the problem and the externally imposed constraints. You should explain to your intended audience the background of the problem in terms that the audience can understand.
2. Explain and elaborate your solution. Be sure to explain the approach or architecture conceptually before delving into details, components, and mechanics. (Remember, you aren't writing a mystery novel!) Present any analysis clearly and concisely.
3. Show how your solution satisfies the constraints and solves the problem (or how it fails to do so); explain how the properties of your solution that result from choices you have made in your design are reasonable or desirable in the context of the problem statement.
4. Briefly describe the alternative approaches that you considered and rejected, and why you rejected them. Your paper will be more convincing if you say not just why your idea is good, but why it is better than the alternatives. (For example, if another approach would meet all of the objectives perfectly, but the cost would be 100 times higher, then you should mention that as a reason for choosing your less general but cheaper approach.)
5. Document your sources, giving a list of all references (including personal communications). The style of your citations (references) and bibliography should be similar to the styles in the technical papers you're reading in this class. In particular, a bibliography at the end and no citations in the text of your paper is insufficient; we'd like to see what specific pieces of information you learned from where as we read your paper.

Write for an audience consisting of colleagues who took 6.033 five years ago. That is, they understand the underlying system and network concepts and have a fair amount of experience applying them in various situations, but they have not thought carefully about the particular problem you are dealing with. Give enough detail that your design could be turned over to some programmers for implementation with some confidence that you won't surprised by the result.

2. How do we evaluate your report?

When evaluating your report, your instructor will look at both content and writing.

Some content considerations:

• Does your solution actually address the stated problem?
• Do you explain your decisions and the trade-offs?
• How complex is your solution? Simple is better, yet sometimes simple won't do the job. But unnecessary complexity is bad.
• Does your solution fit well with the rest of the system? If your solution requires modifying every piece of hardware, software, and data in sight, it won't be credible, unless you can come up with a very good story why everything needs to be changed.
• How extensible is your design? Are there opportunities for later addition of desirable features that you decided to omit?
• Is your analysis clear?

• Is the report easy to comprehend?
• Is it well organized and coherent?
• Does it use diagrams where appropriate? (A frequent problem when people use word processors is that they try to express everything in words, either because the word processor doesn't make it easy to include diagrams, or they haven't ever learned how to use the drawing features. Pictures can communicate some ideas far better.)
• Does it use the concepts, models, and terminology introduced in 6.033? If not, does it have a good reason for using a different universe of discourse?
• Does it address the intended audience?
• Is there a good abstract and bibliography?