The WhiteBerry/ $\mathbf{\{Bluetooth\}}$ Messaging Solution

As we discuss at length in Appendix A.1, the modern professional can equip himself with a variety of mobile communications and productivity devices. But a common choice is for the user to carry two specialized devices: a cell phone for voice communications, and a wireless-enabled PDA for Mobile Messaging.

A major disadvantage of this configuration is that the user must carry and maintain battery charge for three distinct components: cell phone, PDA and add-on modem. But note that this user is in fact carrying around two airlink components: one in the cell phone, and one in the form of the modem. Both of these components perform essentially the same function. The user, or the systems integrator, may well wonder if this component duplication can be avoided.

The basic premise of the WhiteBerry/ $\mathrm{\{Bluetooth\}}$ solution, simply stated, is to use the cell phone as the airlink component for the PDA, and use Bluetooth or similar wireless technology for local communication between these two devices. Under the WhiteBerry/ $\mathrm{\{Bluetooth\}}$ scenario the add-on modem for the PDA is unnecessary, and can be dispensed with altogether.

Since the WhiteBerry solution provides generic component interoperability, it allows any appropriate component to provide airlink functionality for the Mobile Messaging device. In particular, this functionality need not be provided by the customary wireless modem; it can just as well be provided by a cell phone. All that is required is for the cell phone to be able to communicate with the PDA - and this is something that can very conveniently be accomplished by means of Bluetooth wireless technology, or its equivalent.

The general operation of this model is shown in Figure 18.1. Under the WhiteBerry/ $\mathrm{\{Bluetooth\}}$ scenario the user maintains his cell phone and PDA as two physically distinct devices, but the cell phone provides airlink functionality for both voice and data messaging. The user uses the cell phone for voice communications as usual; while Mobile Messaging capability is provided by means of integration of the cell phone with the PDA via $\mathrm{\{Bluetooth\}}$.

An immediate advantage of the WhiteBerry/ $\mathrm{\{Bluetooth\}}$ solution is that it eliminates the cost, size and inconvenience of the wireless modem for the PDA, replacing this with inexpensive miniaturized Bluetooth or equivalent hardware. The only disadvantage of this is that the Mobile Messaging functionality of the PDA requires physical proximity of the cell phone. If the two devices are separated too far, or if the cell phone battery runs out, the Mobile Messaging functionality of the PDA is lost. (But not, it is important to note, its PDA functionality.)

Basic WhiteBerry/ $\mathbf{\{Bluetooth\}}$ Implementation Architecture

Figure 18.2 shows a basic implementation architecture for the WhiteBerry/ $\mathrm{\{Bluetooth\}}$ model. This implementation is basic in the sense that it requires the least amount of device integration. In particular, the basic implementation requires only minimal cell phone integration, and no PDA integration at all.

Figure 18.2: Basic Implementation Architecture.
Device components which are not commonly bundled are shown shaded.

On the Wide-Area Network (WAN) side of the cell phone, message transfer between the message center and the cell phone takes place via EMSD [5], [7]. EMSD, or the Efficient Mail Submission & Delivery protocol, is the e-mail component of the LEAP family of protocols. EMSD is highly optimized for efficient delivery of short e-mail messages. Given the bandwidth constraints of wide-area wireless networks, EMSD is therefore ideal for this application. For complete details on EMSD see the LEAP Manifesto article EMSD: The LEAP E-Mail Component [7], or visit the EMSD website at http://www.EMSD.org.

Since EMSD supports the push mode of message delivery, the cell phone can accept incoming messages at any time, and at any point within the network coverage area. Communications at Layers 2 and 3 takes place via IP over any appropriate Wireless-IP network.

On the local side of the cell phone, message transfer between the phone and the PDA is handled by IMAP [27] or other appropriate protocol. Layer 2 communications is implemented by means of Bluetooth, or any alternative technology appropriate to this.

Under the WhiteBerry/ $\mathrm{\{Bluetooth\}}$ scenario the cell phone normally remains on at all times, so that it is always ready to receive messages. The PDA may be turned on or off as desired by the user.

When a message arrives at the message center it is delivered to the cell phone via the EMSD protocol. The cell phone stores the incoming message, then alerts the user that a new message has arrived. The cell phone may alert the user in any of the usual ways, i.e. by means of an audible (beep, buzz, ring) visual (flash) or tactile (vibration) indication. The user may then turn on the PDA and retrieve the message from the cell phone via the IMAP protocol.

The basic implementation requires that the cell phone and PDA include all the components shown in Figure 18.2. Note that the WhiteBerry/ $\mathrm{\{Bluetooth\}}$ solution is based entirely on readily available, open and free protocols, that conform fully to the Internet end-to-end principle. Specifically, it is based on TCP/IP, IMAP and EMSD.

All those components which are not commonly bundled with the cell phone and PDA are shown shaded in this figure; all unshaded components we consider to be standard or near-standard issue for most modern devices. In particular, we consider $\mathrm{\{Bluetooth\}}$ support to be the norm for both the cell phone and the PDA, and IMAP Client software to be the norm for the PDA. These components are increasingly being provided in cell phone and PDAs; a trend we expect to continue.

In terms of device integration, therefore, the basic implementation requires only that the cell phone be equipped with the EMSD User Agent protocol engine, a minimal IMAP Server protocol engine, and a Message Store. The EMSD and IMAP protocol engines must also be properly integrated with the cell phone User Message Alert and $\mathrm{\{Bluetooth\}}$ capabilities. As described below, open-source and free software for both the EMSD and IMAP protocol engines is readily available.

Note that the Message Store requirements of the cell phone are quite limited, since it need only provide short-term storage of short e-mail messages for a single user. The memory requirements for this are well within the design parameters for most modern cell phones.

Note also that the basic implementation requires no PDA integration whatsoever - the PDA can be used entirely as is, without requiring any hardware or software modifications. This means that the basic implementation can be carried out independently by any cell phone manufacturer; no joint integration with a PDA manufacturer is required. The designed-in functionality of the PDA is intended to allow general e-mail communication with a desktop system or Message Center. But the cell phone manufacturer can use this same functionality to replace the intended desktop system or Message Center with its own cell phone - and the PDA is none the wiser.

Finally, it is worth noting that the WhiteBerry/ $\mathrm{\{Bluetooth\}}$ model allows the use of any appropriate device as the airlink component - not just a cell phone. We have framed the discussion in terms of a cell phone as the airlink device since this is a particularly convenient and logical model. However, the role of the cell phone in Figure 18.2 could be played by any appropriate airlink device.

A Word About SMS

The cell phone manufacturer may note that SMS could also be used to provide push-mode message delivery to the phone. While it is true that SMS can provide the same functionality as EMSD, SMS is not an IP-based Internet protocol, and therefore has no long-term future in the Internet domain. In particular SMS, unlike EMSD, integrates extremely poorly with existing Internet e-mail protocols.