Active Messenger: filtering and delivery in a heterogeneous network
Stefan Marti and Chris Schmandt
MIT Media Laboratory
20 Ames Street,
Cambridge, MA 02139, U.S.A.
{stefanm, geek}@media.mit.edu
Abstract. Active Messenger (AM) is a software agent that dynamically filters and routes email to a variety of wired and wireless delivery channels. More than just a router, AM is a dynamic process that monitors a message's progress through various channels over time. It observes which devices have been used to originate or respond to messages, recent log ins, and caller-ID when checking voice or email over the phone. Its goal is to ensure that desired messages always reach the subscriber, while decreasing message volume when the user is less reachable. AM also acts as a proxy, hiding the identity of the multiple device addresses at which the subscriber may be found. It also caches channels to guarantee seamless information delivery for the user in a heterogeneous network.
1 Overview
Active Messenger [8][12] is a system that delivers messages, based on priority, to a variety of devices in a heterogeneous network. Its goal is to ensure delivery of urgent messages across multiple user access methods, while throttling back delivery of less important messages. To support these goals, AM may attempt to reach a series of devices over time, or to resend messages when a device comes back into range, but without sending redundant messages. AM uses sets of explicit and context sensitive filtering rules, based on a user's recent correspondence, calendar, and location. AM also transcodes messages to fit different display characteristics of mobile text-based devices, as well as for faxing or speech synthesis for voice delivery. AM infers device availability from a combination of network supplied information (device in range, device re-entered range, delivery successful) and observation of user originated traffic.
As just implied, AM is a two-way system. It acts as a proxy for messages or replies originated from the mobile devices, rewriting them to appear to originate from the user's canonical, published email address, rather than the address of the particular device. Because the user can originate a message on any device, and expects a reply to appear promptly on that device, AM tracks “threads” of such messages for special delivery. It also provides, through short structured messages, access to and modification of a number of personal information management tools, such as address book and calendar, and access to limited web-based sources. Additionally, Active Messenger can explain its behavior in handling a particular message, and the user can override that specific contextual rule.
Why a heterogeneous network?
Currently, we employ devices with different network coverage and usage fees. For example, courtesy of sponsor Motorola™ we have campus wide two-way paging from an in house system. In the US, SMS is available on GSM phones, but GSM is not available in every metropolitan area and GSM service providers do not always allow interchange of SMS messages. Other wireless devices exhibit spotty coverage, where a user may switch to a voice channel such as listening to messages over the phone or a portable terminal such as Pocketmail™[1]. Just traveling to a summer home a few hours from Boston crosses three zones of different device access. There are also international issues of which devices work in which countries and at which frequencies.
Additionally, we argue that even if a single mobile device could be employed, a system such as Active Messenger still needs to be aware of multiple access methods. First, many messages will be read on a normal computer or laptop screen and need not be sent to any other device. Second, most users will not want to receive all their messages on the mobile device, but only the most important ones. Third, there are situations in which it is very desirable to access messages via fax (perhaps to share with others or deliver to third party) or listen to via synthetic speech over any telephone (perhaps a coin-operated roadside phone in a remote area with no wireless service of any form).
Filtering and delivery
AM relies on several sources to classify messages. Users can specify rules linking particular kinds of messages to user-defined categories, using a modified version of the public domain procmail syntax (e.g., [14]). For example, messages from a daughter or boss may be “very important,” messages to a mailing list may be “ignore,” and messages from students may be “important.”
Additionally, AM employs the CLUES filtering system [9] written by Matt Marx. On an hourly basis, CLUES examines a number of personal information databases to come up with an additional set of regular expressions defining “timely” messages, after consulting the user's log of sent email, dialed phone calls (if using computer telephony tools), calendar, and address book. For example, messages containing the word “Ubicomp” within a few days of a calendar entry such as “Ubicomp paper due” will be tagged as timely, as would a reply message from the conference chair if the user had sent him a message yesterday. If the user provides a contact phone number, or even just an area code, in his calendar, CLUES attempts to associate emails with location via the address book, and marks as “timely” messages from senders in that area.
Users indicate the ordering of message priorities, including ordering of the “timely” category. A message is evaluated for timeliness when it arrives, and is assigned to the highest priority for which it matches. If a static rule has been created to identify messages from a boss as “very important” and this category is ranked higher than timeliness, a message from a boss about something in my calendar tomorrow would be “very important” and not “timely.”
AM uses the user-defined ordering to determine how hard to attempt to deliver a message. In to specifying filter categories and ordering them, the user must indicate which of these categories should be sent to which devices; currently this is done by editing a text file. Combined with geographic or situational (when a device is carried) locality, this mapping allows AM to throttle message delivery when a user is in a less accessible mode.
When a user is known to be online, there is no reason to hold off any messages so AM simply observes the progress of the message through whatever mail reader the user employs. Since one of our devices—the in house Motorola pager system named Canard [2][3]—works only within a few kilometers of campus, and one of the authors lives out of that range, it is safe to assume that she is “at work” when in range, and a large number of messages are sent to that device. When further away and using a more limited or expensive service (such as Skytel™ or Iridium™) he limits his messages to only the highest priorities. But when he can connect in a more direct and non-interrupting manner, e.g. by a wireless Palm VII™[2] PDA, he again prefers to receive a fairly large fraction of his rated messages (which is still only about a third of all his messages). In this way, AM strives to guarantee prompt delivery of very important messages but pace delivery of other messages to limit their degree of annoyance.
In order to deliver a message, AM takes a number of timed steps after a message arrives and is sorted. The following example (Fig. 1) shows what happens when a new email message arrives. Let’s assume that the user has the following line in her preference file:
Mapping
important = canard(20), vpager(13), phone(14), fax(35)
This describes the channel sequence for important messages. It means that if a message is important, it will be sent to the Canard pager (in house paging system), after that to a Voice Pager[3], then to a phone, and then to a fax. The numbers in brackets mean the delay until a device or channel is used.
Let’s assume furthermore that the user is currently at home and has the following entries in her preference file:
Home
canard = , anytime
vpager = 654-4567, not 0-7
phone = 423-7755, not M-F 22-8, not SU
fax = 423-7755, not 2-7:30
This means that at home, she has the channels canard, vpager, phone, and fax available. For each channel, a number or address is specified, and the time when it is OK to use the device.
Fig. 1: Channel sequence exampleThe message arrives at 6:57am. According to the above channel sequence, the first channel would be canard in 20 minutes. However, this initial delay is scaled down indirect proportionally to the user's idle time: if the user is idle for more than an hour, the message gets sent immediately. Because our user has checked email half an hour ago, the delay is scaled down to 10 minutes. Before the agent can schedule this event, it checks if canard is allowed at that time at that location. The preference file says anytime is ok for canard at home, so Active Messenger schedules this event, and waits.
After 10 minutes, if the user hasn’t read the message otherwise, e.g., by reading it from the mail spool file, Active Messenger sends it to the Canard pager. Right after the sending, Active Messenger looks up the next channel, which is vpager in 13 minutes from then. It’s now 7:07am; the time of the sending would be 7:20am, which is a valid time, because the Voice Pager only wants to get messages after 7:00am. Then the agent waits again and checks all available back channels if the message gets read somehow.
After 13 minutes, if the message’s is still not read, Active Messenger calls up the Voice Pager number and synthesizes the message with the text-to-speech module. Right after that, the agent tries to schedule the next event, which would be phone. The phone call would be in 14 minutes at 7:34am. Unfortunately, the user does not allow Active Messenger to call her up on the phone at home from Monday until Friday after 10pm and before 8am. Therefore, this channel is currently not available, and the agent skips it. The next entry would be fax. It is now 7:20am, the delay for sending faxes is specified by the users as 35 minutes, and so Active Messenger schedules a fax sending for 7:55am. Then the agent waits again.
The user, however, happens to log in to her computer and read this email message at 7:48am. The “message read” level rises over the threshold, and the message is regarded as read. Therefore, Active Messenger cancels the fax.
Device handoff and intermittent connectivity
In a heterogeneous environment, AM supports graceful device handoff. AM detects “device” presence in a variety of ways. The Unix “finger” command indicates computer activity and can give some hints as to whether a login session is local or remote; if the user is logged in, she is likely to be reading email so AM delays longer before deciding that a message is not going to be read and sending it to the first in a series of possible devices. Similarly, if the user phones in to access voice mail or hear email, caller ID on the call may indicate whether she is at home, or a geographic location (area code).
For mobile devices, different networks provide different indicators of connectivity. Some indicate when a device is within range, some indicate when a device newly arrives in range, some explicitly indicate receipt of a message on the device, and others provide no indication at all. In all cases, messages originated from a device and received through AM (as a proxy) indicate that a user is active on that device. If AM does not know whether a device is in range, it sends a limited number of messages to it before waiting for some indication of successful delivery; this is important because some networks buffer messages internally, and when the user comes back in range, perhaps days later, many stale messages could be waiting, wasting money, bandwidth, and the time spent deleting them on the device.
When AM detects that the user has switched devices or a device is newly within range, it rescans all the messages which might have been sent to the device, to determine whether they are still unread. If so, it then sends them automatically. This handoff could be triggered by a signal from the network, change in status of a previously sent message to “received,” or an incoming message suddenly appearing from the device. This caching and resending when appropriate has resulted in very effective “seamless roaming” across devices and networks.
Another aspect of modifying device priority is “threaded” messages. A user can send a message to any Internet address from any device. This could be someone who appears in some predefined filter rule. If not, on the next hour when CLUES runs, that person will become “timely”; until then a reply from that person would most likely be unrated.
In any case, the device from which the message was sent my not be configured to receive a message of whatever category, if any, the reply would have, so it would be missed. In order to avoid this unwanted behavior, AM tracks message “threads,” i.e. new messages originated from each device. An incoming message is matched against these threads, and if a match is found, the message is immediately sent to the original originating device. It is then sent through the normal chain of devices, in case that device is no longer in range.
Similar behavior is required to notify the user of rejected messages, perhaps because of ill-formed or mis-typed destination fields. It is very frustrating to send a message and be wondering why the recipient has not replied when, in fact, the message was never delivered and the rejection notification was missed!
Role as proxy mailer
Although most AM devices are email-addressable, an AM user may not wish to reveal their addresses, for a variety of reasons. Different devices may be in use at different times, so a message sent to any one may not be delivered for some time. We may change devices from time to time and don't wish to bother having to so inform all our correspondents. Most important, we may wish to keep the addresses of these devices secret and rely on filtering agents to make sure that only the desired messages are delivered to them. Similarly, if our correspondents use filters, these filters may not recognize the addresses of our devices as “ours.”