Project Proposal

Abstract

Design Strategy

• The server infrastructure will be running on a PC platform. It will serve and coordinate profile information within the infrastructure. Our devices will communicate over TCP/IP on ethernet. To simplify server coding, we will likely develop the server in Java in order to utilize all the available networking packages.

• Data used in our infrastructure will be in a limited, restricted XML form. We intend on developing just a few applications for demonstration -- a calendar, notepad, and instant messanger. For prototyping, we will build simple examples of these applications in Java, just to preliminarily test their integration with each other, our XML data specification, and server.

• Programming for the embedded devices, such as the video wall and PDAs will initially focus on testing the IO and UI. Since the abstract logic will likely be easily portable from the Java prototypes, we expect most of the difficulties to mainly lie with the various device IO necessary.

• The PDA device will likely be a Compaq iPaq, because we have decided to utilize wireless ethernet as our communication medium. Of course, the programming team will have to begin familiarizing themselves with the WinCE development environment as soon as possible. The first priority with the iPaq will be to attempt to interface the serial port with the radio authentication system. We expect the PDA to be a critical piece of the project, and cannot afford to be under-developed by the time of the demo.

• The Video Wall with consist of a touchscreen monitor attached to a laptop. We will be using a Magic Touch touchscreen, which is provided in the hardware lab. We are looking at writing the applications in Java with the interface for the user consisting of a virtual keyboard. It will simply be alphabetic buttons the user can press to input text. The video wall does not seem like a difficult aspect of the project. The touchscreen package already interfaces with a simple test application. The remaining part will of video wall will be the authentication of the user and developing applications.

• The radio beacons are the cornerstone of our authentication system. We are aggressively pursuing this technology in order to achieve the invisible computing experience for our infrastructure. Other options included an "IR ring", for exmple, however this would still require active There is also the issue of whether or not we can interface received beacon data and somehow pump it into our devices (PDA and VideoWall). However, we have high confidence in this piece because we will hopefully have extensive cooperation from Jeff.

  The radio devices pass around a record of all known devices in the cluster. This record can be sent up the serial line to a controller (pc, vid-wall, iPaq) for analysis etc. This is usually passed in the op-code oriented packet protocol, but can also be done as ascii dump. Since portable code has already been writen for the protocol stack, we will attempt to incorporate this stack into our applications, either through direct C calls, java JNI or library calls in Visual Basic, depending on what final development environment is chosen. In any situation, the devices express more information than is necessary for our application and some thread of execution will need to filter out the pertinent information: tag id and distance.

  The existing PC emulator/interface application is a three threaded model. The lowest level thread grabs bytes off of the port, buffers them and parses the stream into valid packets. These packets are then sent off to a synchronized queue. The second thread merely looks at the head of the queue for packets that are "interesting" and pops the un-interesting packets. The third thread is the application layer and makes use of the info in the interesting packets.

  As much of the spot-on code will be re-used in this project as possible, so our model will look very similar to that described above. One simplification that may be made is to create a packet specific for our application, since we need only 2 pieces of information from the spot-on devices. This would simplify the role of the second thread to a point, that it may not be necessary. Furthermore, the spot-on devices might also be programmed to report only this new packet type.

Design Unknowns

• Limited WinCE development experience.
• Unknown on the extraction of UID information from the radio beacons into the scrap devices. There is some code already writen to decipher the packet protocol that the radio devices speak over all of the communication ports: serial, RF, IrDA. This code is writen in C and has been successfully ported to diferent platforms, but may have trouble on devices like the iPaq. This code requires system calls to stream data over the ports; will need to learn how to do this for WinCE on the iPaq. Further more, there seems to be some issues with serial interface in Java not being pre-packaged. This will need to be a part of our package, and should be solved before Java becomes a development platform for our system.
• Unknown is whether the various applications will run on one JVM or multiple ones. With one JVM, various threads may be dispatched for the different applications (one thread for the calendar, one for the notepad...) This will allow updates from the server to be handled by one JVM and passed onto the various threads. However, this approach may not be scalable.

  Another alternative would be to have a different JVM for each application. However, as Jing has mentioned, there may be problems passing information from the server to the various JVMs.

• Unknown is what the user interface for the various applications will be.
• Unknown for the calendar application is how much information will be transmitted at one time. Will there be enough information for just one day? Will checking the next day require information from the server? Or can we send one month's worth of data?
• Unknown is if Java's package for the built-in XML parser will fit inside the iPaq's memory.
• Unknown is how an application written in Java will be displayed in the small screen of the iPaq. We may need to write specific applications for the iPaq to resolve this problem.

Design Extras

• There has been talk of maybe integrating memory technology into the authentication pin to act as a local cache, especially when roaming outside the infrastructure for offline work.
• DigitalInk as an additional scrap device.
• Use more than one type of communication medium to get at the profile data necessary. Devices can could communicate over BodyComm, wireless ethernet, ground lines, cell, satelite link, etc. Furthermore, develop the infrastructure to allow multiple environments, each at different levels of security and encapsulation.
• Develop quantum level networking so that data can be transported faster than the speed of light.

Resource Requirements

• Authentication
  • 4 spot-on tags. Two tags will be worn by users to merely let the system know of their presence via the radio communication. Each device, the ipaq and the video wall will also need a tag to detect the user(s).
  • spot-on source code Jeff will supply us with this and any compilers needed for the spot on devices.
• Video Wall
  • Touch screen - already available and installed.
  • Laptop - Running Windows 95/98. This is just needed for demo time. For development, we can simply use Jing's laptop.

Division of Labor

• Josh - Authentication. Interfacing the Java applications with Jeff's radio toys.
• Jing - Server work. Generating XML pages, transmitting data to the scrap devices, relaying updates to various scrap devices, etc.
• Danny - With the hardware completed for the video wall, developing user applications along with assisting with the server.
• Maksim - Server work
• Steve - iPaq work.