CS 294-1 Project Ideas


Project Requirements

Projects will be one person or two person teams. If the class remains large, two person teams will be required. Projects should include a detailed technical investigation of a topic (including background literature searches), an in-depth analysis of the existing situation, either the simulation of or the construction/modification of a demonstration system, and a detailed analysis of the simulation on system results.

Basically you can pick any project topic you want, subject to three constraints: related to the course topics, addresses significant issues, and is substantial in size.


Mobile Telephony Projects

Measurement and analysis of the interactions between TCP/IP and reliable link protocols in mobile telephony

Digital cellular telephony (PCS) offers data transport capabilities that make it an attractive candidate for mobile Internet access. A typical scenario is a business person who uses a laptop connected to a PCS cell phone to dial into the Internet and use TCP/IP-based applications. However, performance problems can occur because of detrimental interactions between TCP and the PCS reliable link protocol, Radio Link Protocol (RLP).

The project's goal is to study and analyze these problems. The project will consist of enhancing the existing measurement platform, running several series of performance measurements of TCP via PCS to build up a database of traces, and post-processing the traces using statistical analysis for further analysis and use in a simulation environment like the ns network simulator.

  1. Optional: Enhance the existing measurement platform by porting the current implementation of the RLP driver from user space to kernel space. This is a real kernel hacking job which requires significant kernel and system programming knowledge and experience.
  2. Measurement collection and statistical trace analysis will involve using the existing (or enhanced) measurement platform to collect a number of measurement traces from different locations in the Berkeley area. In parallel, the collected traces will have to be post-processed by statistical analysis to convert them into adequate representation forms for both presentation in reports, and also for use in a simulation environment like ns (network simulator). Basic knowledge of statistical analysis would help but is not absolutely required as it can be learned during the project.


Evaluation Tools and Methodologies for Wireless Networks

Simulation and analysis of the tradeoffs between using Forward Error Correction (FEC) and/or retransmission for wireless data transmission

The GSM mobile telephony system relies on FEC to provide reliable delivery of digitized voice data across an error-prone wireless digital link. FEC is used because voice data is time sensitive and must be delivered in real-time. The overhead of using FEC is approximately a factor of two in space (and a lower actual data rate).

Digital data sent using GSM is protected by both FEC and a retransmission scheme. However, data is usually not time sensitive, but is bandwidth sensitive. This raises the question for the design of future wireless networks of whether a retransmission scheme alone would be sufficient to provide reliable data delivery (at a higher bandwidth). We have wireless networking software that has the ability to collect packet traces and measure physical network performance parameters like received signal strength and bit error rates. The project will consist of:

  1. Designing benchmarks (for example, a rate controlled UDP traffic generator), collecting, and analyzing signal strength and bit error rate traces from several different in-building and wide-area networks (WaveLAN, Metricom packet radio network, GSM PCS data network, Hughes DBS satellite network, etc.). It would be great to collect as large a library of (reproducible) benchmark traces as possible.
  2. Using the collected information and existing wireless channel error models to develop a wireless channel model for burst errors rates and probabilities.
  3. Constructing modules for the ns network simulator to model wireless channels and simulate the effects of FEC and retransmission on data transfer rates and latencies.


Mobile IP

The Mobile IP specification can be extended in a variety of directions, any of which would make an interesting project:

Overlay IP

Mobile IP was never designed to support routing in overlay networks. The needed capability is for the HA to choose among alternative wireless networks for providing connectivity to the Mobile Host. How should the Home Agent be modified to allow it to select a given network interface (and IP address) for a particular kind of network traffic? What kind of session or stream abstraction is required? How is information exchanged between the Home Agent and the Mobile Host to establish the policies by which a route is chosen?

Hierarchical Routing

A potential limitation in the current Mobile IP specification is that the Home Agent needs to be informed about every change in location of the Mobile Host. These could be high latency operations if the mobile is far from home. One possible improvement is to introduce hierarchical routing authorities (Foreign Agents) to which the HA forwards packets, which are then reforwarded locally to FAs associated with individual microcells. Most location updates are thus handled locally. The details of this scheme need to be worked out and evaluated in depth (note that mobility traces would be of great value in this evaluation).

Mobile Security and Privacy

Our current implementation of Mobile IP does nothing to protect user identity or provide end-to-end encryption. It would be worthwhile to design and implement either a public key or a shared secret/challenge-response prototype system. Note that we might be able to obtain some Tessera cards for use in this project.

Cell Admission Control and Airlink Load Balancing

Our current implementation of Mobile IP does no admission control and makes no attempt to do load balancing between cells or alternative networks. How should the registration process be generalized to provide these capabilities? How does it interface with the HA to assist in making routing decisions?

IP Spoofing and Mobility

Routers with IP Spoofing detection enabled cause many problems for the existing Mobile IP specification. The source address of the packet is the MH's address in its home network, but the router interprets this as an attempt to spoof the Internet by providing an incorrect IP address on purpose (the router will refuse to pass the packet!). Propose and evaluate methods for circumventing this problem.

Wide Area Roaming Architecture

Mobility software has not as yet been widely available. Most research groups working on Mobile IP have implementations that are only operational within their own local administrative domains. What will it take to implement a true wide area roaming architecture around the Mobile IP specification? Most of the issues are related to resource allocation (local users should be given priority access to network bandwidth, compute and printer resources, etc.) and accounting (e.g., keeping track of resource usage in the visited environment; this can form the basis of a credit system when mobiles from the visited environment become visitors in turn).

Internet Firewalls and Mobility vs. Mobile Telephony

Extend Mobile IP to use a mobile telephony style authentication protocol. Many organizations deploy Internet firewalls to restrict access to external users of resources inside their corporate networks. Develop and evaluate some schemes that could allow local users who are roaming in foreign networks to access resources inside the firewall. In principle, the problem is the same as that of users who need to dial-in to a corporate network from outside. Such systems typically make use of secure terminal servers inside the firewall. How might a local authentication agent be constructed to provide adequate security for external access?

Simulation and analysis of the scalability of Mobile IP

Mobile telephony systems support millions of roaming users. Will Mobile IP support millions of roaming users? Investigate the bottlenecks and simulate a system with millions of users. Propose extensions (new or from mobile telephony) to improve Mobile IP scalability.

Mobile IP Security

Compare the security mechanisms used in wireless networks with those used in mobile telephony networks. Develop a model that explores the following issues: Which mechanism are necessary to have complete protection from eavesdropping and to provide robust authentication of users? Scalability and deployability? Is anonymity a desirable feature? How can the needs of law enforcement be met without opening the system to potential abuse? How is the security mechanism's secret information propagated to mobile users in a secure fashion?


Mobile Applications

Queued RPC for the USR Palm Pilot

A Palm Pilot automatically shuts down the network connection and power downs after a user-specified period of inactivity. This behavior is very disruptive for many networking applications. Several of the UCB-developed TopGun tools for the Palm Pilot (WingMan and PostMan) use a simple session model to handle disconnections and reconnections of the pilot's network connection. The session model hides disconnections from the upper layers of the application at each end point. This project will entail generalizing the session model (e.g., adding compression and security) and adding queued communication. The new model will be simulated on the copilot simulator and deployed on pilots.

ns Simulation of Service Location Protocol

The Service Location Protocol (SLP) makes several decisions about the propagation of advertisements for services (printing, file system, etc). An open question is how SLP will scale to cover building or campus wide resources. The project will involve developing ns modules to simulate a large SLP domain, analyzing bottlenecks (e.g., what is the latency of advertisements, how much bandwidth is required for announcement traffic, etc), and proposing (and simulating) various alternative mechanisms.

Personal information management

These are projects that involve collaborative groupware applications (e-mail, calendar tools, WWW, and USENET).

Java-based implementation of Queued Remote Procedure Call

The QRPC implementation in the Rover toolkit is based upon C and Tcl/Tk code. This project will consist of extending the original QRPC design, implementing a portable, Java-based QRPC operator, and measuring the benefits of using batching and compression.

Policies for adaptive mechanisms

Two open research questions are when to decide to initiate/shutdown a network transport connection in a virtual circuit-based network (e.g., when to place a GSM data call and when to end the call) and which network transport to use when multiple ones are available (e.g., use CDPD or GSM). These decisions may be based upon the bandwidth, latency, network coverage, pricing model, and future expected network availability (i.e., if I'm on a plane, do I use the $5/min AirPhone or wait to place a $0.10/min long-distance call from the hotel?). This project will involve researching the issues, developing a decision-making algorithm, simulating the algorithm, and evaluating the results.

Security for mobile code

In several mobile computing systems (e.g., Rover, Bayou) code generated at clients and server runs everywhere. This raises serious issues about how to protect private client and server data and resources. This project will entail identifying the potential problems and developing solutions.

Smart Spaces

Several Soda hall rooms have been outfitted with interfaces to make them computer controllable (see Todd's paper for more information). Currently the interfaces are based upon Tcl scripts. To handle smaller devices and customized user interfaces, we'd like to move to a Java-based environment. This project entails developing Java objects for controlling the devices and building a user interface compiler. The UI compiler would take a set of objects, user preferences, and screen size as input and generate a user interface that is optimized for screen space and functionality. The goal here is to be able to compose operations across devices and to adapt interfaces for for users. For example, most users only want an interface that displays "lecture", "computer", "play" mode buttons for lecturing in a room, displaying a computer screen, and playing tape. Providing the appearance of a single common interface to all rooms makes using the room much easier. Likewise, more sophisticated users may want access to additional functionality and power users may want all the buttons, knobs, and sliders exposed.


Anthony D. Joseph, adj@cs.berkeley.edu, Last Updated: 19 February 1998