Architecture Overview

Figure 2: A Typical Usage Scenario. Dan Sender uses his cell phone to place a call to Jane Mobile. The call is redirected to Jane Mobile's laptop through her Personal Proxy. The gray figure and arrow indicate Jane was recently accessible through her cell phone, but is now accessible through her laptop only.

The main goal of MPA is to route communication to a mobile person, independently of his location or the communication applications he is currently using. This people-level routing uses an addressing scheme that uniquely identifies people. In MPA, these addresses are called Personal Online IDs (POIDs). The architecture does not depend on how POIDs are maintained or how people retrieve the POIDs of other people.

Figure 2 shows a typical usage scenario in which Dan Sender wants to initiate communication with Jane Mobile. If Dan's communication application (which could be anything ranging from email to a fax machine) supports MPA, then it uses Jane's POID to direct communication to her Personal Proxy. If Dan's application is not MPA-aware or if a POID naming scheme is not widely deployed, then an alternate scheme is used (see Section IV).

The Personal Proxy is the heart of MPA and consists of three components: the Tracking Agent, the Dispatcher, and a set of Application Drivers. We briefly describe their functions here, and give more detailed descriptions in Section V.

The Tracking Agent in Jane's Personal Proxy is responsible for keeping track of her as she moves from an application on one device to another application (possibly on another device). For example, in Figure 2, Jane has switched her cell phone off and is now accessible only via email on her laptop. The Tracking Agent makes this information available to the Dispatcher in her Personal Proxy.

The Dispatcher processes any communication that arrives at the Personal Proxy. Using Jane's accessibility information and her preferences, the Dispatcher directs the communication to the appropriate application. In some cases, the Dispatcher may call upon an Application Driver to convert the communication into a form understandable by the receiving application. In Figure 2, Dan Sender calls Jane on her cell phone. Since she is accessible only via email, an Application Driver converts the voice message into an email message with an embedded sound file. This sound file is then forwarded to Jane's laptop. An Application Driver could also enforce user-specified restrictions (e.g., to block spam), or convert intrusive forms of communication into less intrusive ones (e.g., a phone call into voicemail).