WhiteBerry and {Bluetooth}

A Permanent Libre Published Content

---

WhiteBerry and {Bluetooth}

Use of EMSD and Short Range Wireless Connectivity

for Enhanced Mobile Messaging Applications

Document Number:	PLPC-100016   [ .bib ]
Version:	2.8
Dated:	July 27, 2001
Group:	LEAP
Primary URL:	http://www.freeprotocols.org/PLPC/100016
Federated Publications:	ByTopic -- ByContent
AccessPage Revision:	This AccessPage was produced on July 04, 2013 at 1:12 PDT (-0700)
Author(s):	Andrew Hammoude, Mohsen BANAN
Organization:	Free Protocols Foundation

AVAILABLE FORMATS

• PDF: -- 256K -- Provides the document in Portable Document Format.
• PS: -- 1.2M -- Provides the document in Postscript format for printing.
• HTML: -- 236K -- Displays the document as a web page.

SHORT DESCRIPTION

This article provides a description of how WhiteBerry and Bluetooth can be used in combination to bring new and enhanced messaging capabilities to the mobile professional.

---

FULL INLINE DOCUMENT

A Component of The LEAP Manifesto

This article is one of a series of articles describing various aspects of the Mobile Messaging industry and the Lightweight & Efficient Application Protocols (LEAP) protocols. For the complete collection of articles see The LEAP Manifesto [9], available at
http://www.LeapForum.org/LEAP/Manifesto/roadMap/index.html. The LEAP Manifesto is also available at the Free Protocols Foundation website at
http://www.FreeProtocols.org/LEAP/Manifesto/roadMap/index.html.

Contents

List of Figures

1 Introduction

In this article we will describe how the EMSD (Efficient Mail Submission & Delivery)[1] protocol can be used to provide powerful new messaging capabilities. The capabilities we describe are based entirely on existing technologies, and on existing open and free protocols. We will describe two major new applications:

• Use of EMSD to provide true Mobile Messaging capability to the user who habitually carries a cell phone and a PDA device, without requiring additional hardware components. In particular, the model we describe does not require the customary add-on wireless modem for the PDA, so that the cost and inconvenience of this component can be eliminated. We refer to this model as the WhiteBerry/{Bluetooth} messaging solution.
• Use of EMSD to provide a general Mail Notification functionality, which can provide the user with immediate notification of the arrival of certain types of messages in the user’s back-end Message Center.

This article is a follow-on to a previous Manifesto article entitled Use of EMSD for Mail Notification [4]. In that article we describe the Mail Notification model in technical terms; in this article we describe its implementation in a specific messaging context.

The models we describe in this paper are part of a more general industry movement which we call Operation WhiteBerry [3]. As described in Section 6, the Operation WhiteBerry movement is supported by a comprehensive set of development tools and resources. In particular, free open-source software implementations of the EMSD protocol are immediately available for a wide variety of end-user devices and Message Center platforms. All this software is readily available at the MailMeAnywhere open-source software distribution center at http://www.MailMeAnywhere.org.

The models we describe are thus not merely theoretical, but can be implemented immediately and without difficulty using existing software components.

1.1 Bluetooth vs. {Bluetooth}

In Section 3 we describe how true Mobile Messaging can be implemented based on a cell phone and a PDA. A key component of this model consists of a technology for short range, low power wireless communications between the cell phone and the PDA. At present there are two candidate technologies which address this requirement: 802.11, and Bluetooth.

The 802.11 [5] standard for wireless LANs (WLANs) is an IEEE Media Access Control (MAC) specification which was completed in 1997. The latest step in the evolution of the specification has been the ratification of the 802.11b or High Rate, providing data rates of up to 11 Mbps which can reach distances of hundreds of feet. Products based on 802.11 are now available in a variety of forms, and are experiencing widespread usage. Interoperability amongst the 802.11 products is common place and certification processes such as Wi-Fi™(wireless fidelity) which assurance of interoperability are in place. This widespread availability and usage has brought significant economies of scale benefits at both component and device level, greatly reducing the cost of 802.11 solutions. 802.11 does not specifically address the low power end of short range wireless communications, e.g. for communications with small battery operated devices. However it is to be expected that low power flavors of 802.11 will be developed in the future.

Bluetooth [7] is generally intended as replacement for wires and links between devices like laptops, cell phones, headsets and handheld computers. Bluetooth was intended to be a low-cost, low-power wireless technology for short-range radio communication. It has been under development for more than three years. Bluetooth provides fast and reliable digital transmission of both voice and data. Unlike infrared technology, Bluetooth is not limited to line-of-sight communication. Some Bluetooth products are available, but the price remains high. For more information visit the Bluetooth website at http://www.bluetooth.com/.

There are many in the wireless industry who argue that Bluetooth is no longer a viable option for short range wireless communications, since 802.11 is already in widespread usage and has lower cost; see for example the article Bye, Bye Bluetooth [8]. This may very well be the case for wireless communications in general, but it is not yet clear what will be the winning technology in the extremely low power short range environment. Bluetooth may yet play a role in addressing the requirements of extremely low power devices such as battery-operated cell phones and miniaturized PDAs. Furthermore, it is reasonable to expect pieces of Bluetooth technology (e.g. physical layer, usage profiles) to be merged in with 802.11 solutions.

However, this debate, and the eventual technological outcome, are irrelevant to our current purposes. What is clear is that there is a need for short range, low power wireless connectivity, and that some technology will eventually occupy this space, whether it be Bluetooth, 802.11 or something else altogether.

The model we describe in Section 3 requires cell phone/PDA connectivity, but it is independent of the particular technology used to accomplish this. We refer to Bluetooth in the title of this article for the sake of catchy wordplay; however the model we present is in no way locked in to Bluetooth.

Since repeated use of the wording “Bluetooth, or similar technology for short range wireless communications” will quickly become wearisome to the reader, we will use the notation {Bluetooth} throughout this article as shorthand for this. Specifically, we define {Bluetooth} to mean:

On those occasions when we really do mean Bluetooth specifically, we will say Bluetooth.

1.2 Industry Characteristics and Trends

There are various industry characteristics and trends that act to enable or facilitate the models we describe in this paper. The following characteristics or trends are of particular relevance:

• {Bluetooth} support increasing on cell phones. Support for Bluetooth itself is becoming increasingly common on cell phones, for example to enable the use of cordless hands-free headsets and other close-proximity components. We expect that this trend will continue, and that support for Bluetooth or similar technology will eventually become the norm for cell phones.
• {Bluetooth} support increasing on PDAs. Bluetooth hardware is also becoming increasingly common on PDAs, for example to enable cordless synchronization with a desktop PC. We expect this trend to continue, and that Bluetooth or similar technology will eventually become the norm for PDAs.
• IMAP (Internet Message Access Protocol) support increasing on PDAs. IMAP Client software is becoming increasingly widespread on PDAs, for example to support e-mail synchronization of the PDA with a desktop mailbox application. We expect that IMAP support will eventually become the norm for PDAs.
• EMSD (Efficient Mail Submission & Delivery) support to increase in Message Centers. As the open WhiteBerry solution becomes widespread throughout the Mobile Messaging industry, we expect that EMSD support will increasingly be provided in Message Centers.
• Essential Mobile Messaging requirements: Unconscious carry and push-mode delivery. Market experience has now demonstrated beyond any doubt that the correct Mobile Messaging model includes two essential characteristics: unconscious carry, meaning that messaging is provided on a device that can be carried without moment-to-moment awareness of its presence; and push mode delivery, meaning that messages are delivered directly to the recipient without requiring an explicit poll or retrieval action. Any viable messaging solution must have these two characteristics.
• Cell phone and PDA a viable device configuration. The mobile professional of today can choose to carry any of a wide variety of communications and productivity devices. A common choice among users is to carry separate cell phone and PDA devices. This user may also equip himself with Mobile Messaging capability, implemented either via the cell phone, via the PDA, or by means of a specialized messaging device.

  Though other options are commonly exercised, we will assume throughout this article that the separate cell phone and PDA option is and will remain a viable and important option in the mobile marketplace.

  There already exists a large body of speculative literature describing the pros and cons of various device types and configurations, and predicting their future success or failure. The purpose of this article is not to add to this. For those who are interested, however, we provide a justification for this assumption in the appendix to this article.

2 What is WhiteBerry?

WhiteBerry is an open Mobile Messaging solution, based on a set of open, patent-free protocols called the Lightweight & Efficient Application Protocols, or LEAP. LEAP is a family of high-performance, efficient protocols that are ideal for mobile and wireless applications. For more information about the LEAP protocols see the LEAP Forum website at http://www.LeapForum.org.

The Mobile Messaging landscape of today consists of a number of closed, competing solutions, such as the popular BlackBerry system from Research in Motion (RIM). These existing solutions are based on closed and/or proprietary protocols, and are limited to a specific set of components which do not interoperate with those of any other solution.

The WhiteBerry solution, by contrast, is an open industry model, based on generic industry-wide component interoperability. Under the WhiteBerry scenario, Mobile Messaging functionality is provided by a multi-vendor set of products and services, and the necessary cross-vendor interoperability is guaranteed by the openness and integrity of the underlying LEAP protocols. WhiteBerry thus provides an open alternative to existing successful solutions such as BlackBerry.

Since the underlying protocols are completely open, WhiteBerry allows market entry, cooperation and competion at every point within the Mobile Messaging technology chain. The result is greatly increased business opportunities throughout the Mobile Messaging industry, increased competition, and better solutions for the end user. In particular, the two EMSD applications we describe in this paper represent major business opportunities.

A detailed description of the WhiteBerry solution is provided in the Manifesto article Operation WhiteBerry [3]. This article is available on the LEAP Forum website at
http://www.LeapForum.org/operationWhiteberry/index.html, and also on the Free Protocols Website at
http://www.freeprotocols.org/operationWhiteberry/index.html.

In the context of the present article, the key characteristic of the WhiteBerry solution is that it allows independent selection of each component of the Mobile Messaging solution. In particular, the end user or systems integrator may specify any appropriate component to provide airlink functionality for the mobile device.

3 The WhiteBerry/{Bluetooth} Messaging Solution

As we discuss at length in Appendix A, 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/{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/{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 1. Under the WhiteBerry/{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 {Bluetooth}.

---

---

An immediate advantage of the WhiteBerry/{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.)

3.1 Basic WhiteBerry/{Bluetooth} Implementation Architecture

Figure 2 shows a basic implementation architecture for the WhiteBerry/{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.

---

---

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 [1], [2]. 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 [2], 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 [6] or other appropriate protocol. Layer 2 communications is implemented by means of Bluetooth, or any alternative technology appropriate to this.

Under the WhiteBerry/{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 2. Note that the WhiteBerry/{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 {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 {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/{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 2 could be played by any appropriate airlink device.

3.2 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.

4 Mail Notification

A basic shortcoming of conventional e-mail protocols such as IMAP is that they do not support the push mode of message delivery, in which the message is delivered directly to the end-user device. Instead, the user must initiate an explicit pull action to retrieve new messages from the Message Center.

This is one of the shortcomings of existing protocols that EMSD addresses: EMSD fully supports the push mode of delivery. In addition, EMSD has been designed with a major emphasis on efficiency; it is highly optimized for the efficient delivery of “short” Internet e-mail messages – meaning text messages up to approximately 4 kbytes in length.

Although the great majority of daily e-mail messages fall within this category, there is no inherent upper limit to the size of e-mail messages. Any given e-mail can be extremely large, particulary if large attachment files are included with the message. However, the efficiency characteristics of EMSD do not extend to long messages; and in terms of efficiency, IMAP (because of TCP, sliding windows etc.) is more suitable for long messages than EMSD.

Thus we see that in the case of long messages, there is a functional lacuna in the existing e-mail protocol framework. EMSD can push the message to the recipient but cannot deliver it efficiently; while IMAP can deliver the message efficiently, but cannot push it to the recipient.

The ideal solution to this would be a well-integrated family of protocols, designed ab initio to provide full support for these, and other, messaging requirements. However, no such integrated protocol family exists at present. Nevertheless, the delivery of long messages can be properly managed by the integration of existing, though independently designed, protocols such as EMSD and IMAP.

In particular, long message delivery can be greatly enhanced by by means of a Mail Notification service, which would alert the user to the arrival of the message at the Message Center. Such a service can readily be provided by EMSD, and used in conjunction with a suitable message delivery protocol such as IMAP, this can greatly improve the timeliness of delivery of long messages.

The general operation of the Mail Notification service is shown in Figure 3. If a short message arrives at the Message Center, it is delivered directly to the mobile device via the EMSD protocol, and the device then alerts the user to its arrival. In this case no explicit notification is required, since notification is implicit in the arrival of the message itself.

---

---

If a long message arrives at the Message Center, then the EMSD protocol is used to send a Mail Notification to the device. This could take the form of a generic notification, simply flagging the arrival of a long message at the Message Center; alternatively the notification could take the form of a message digest for perusal by the user. In the former case the Message Center would require an appropriate Mail Notification Send function, and the mobile device would require a complementary Mail Notification Receive function.

Regardless of the nature of the Mail Notification, the mobile device would then alert the user to the availability of the long message at the Message Center. The user can then retrieve the message at his discretion, either sight unseen (in the case of a generic notification), or on the basis of the message digest. Retrieval of the long message, of course, takes place via the IMAP protocol.

The above operational model could be described as a “push-assisted” mode of operation – i.e. the notification is pushed to the user, but the user must then pull the message itself. Alternatively, receipt of the notification could trigger automatic retrieval of the message by the device. In this case, the combination of Mail Notification via EMSD and message retrieval via IMAP is functionally equivalent to true push mode delivery of long messages.

5 Mail Notification in the WhiteBerry/{Bluetooth} Model

Figure 4 shows how the above Mail Notification model can be implemented in the context of the WhiteBerry/{Bluetooth} solution, thereby bringing enhanced Mobile Messaging functionality to this solution.

---

---

As in the case of the basic WhiteBerry/{Bluetooth} implementation, the cell phone normally remains on at all times, while the PDA may be turned on or off as desired by the user.

Whenever a short message arrives at the Message Center it is delivered to the cell phone via EMSD, then immediately transferred from the cell phone to the PDA, again via EMSD. If the PDA is off, the push mode delivery by the cell phone causes it to wake up automatically, so that the message is now immediately available to the user. No pull action is required by the user or the PDA.

The user can be alerted to the arrival of the message either by the cell phone or by the PDA, provided the PDA has suitable user alert functionality.

Whenever a long message arrives at the Message Center a notification of this is sent to the cell phone via EMSD, then immediately relayed to the PDA, also via EMSD. The notification could take the form either of a generic message arrival flag, or a message digest for review by the user. In the former case the Message Center, cell phone and PDA all require the appropriate Mail Notification Send and Mail Notification Receive functions.

If the PDA is off, the push mode delivery of the notification causes it to wake up, and the PDA then retrieves the long message from the Message Center via the IMAP protocol. Note that retrieval of the message takes place by direct IMAP communications between the PDA and the Message Center, as indicated in Figure 4. The cell phone is bypassed entirely at Layer 7, and provides only Layer 3 connectivity via IP. In other words, IP packets are routed through the cell phone transparently to Layer 7.

Retrieval of the message by the PDA may be initiated in any of the ways previously discussed: either by the user at his discretion sight unseen (in the case of a generic notification); or by the user at his discretion on the basis of the message digest; or receipt of the notification could trigger automatic retrieval of the message by the PDA.

As in the case of short message delivery, the user can be alerted to the availability/arrival of the long message either by the cell phone or by the PDA.

This implementation requires that the cell phone and PDA include all the components shown in Figure 4. Note that the implementation is based on the same readily available, open and free protocols as the basic WhiteBerry/{Bluetooth} implemenation; namely, TCP/IP, IMAP and EMSD.

As before, all those components which are not commonly pre-bundled are shown shaded in Figure 4. In addition to the components required for the basic WhiteBerry/{Bluetooth} implementation, the cell phone must now also be equipped with an EMSD Server Agent to deliver notifications and messages to the PDA. If the notifications are to take the form of a generic message arrival flag, then the cell phone also requires both a Mail Notification Receive function and a Mail Notification Send function.

In its turn the PDA requires an EMSD User Agent, and (possibly) a Mail Notification Receive function. If the PDA is to be used as the user alert device then it will also require an appropriate User Message Alert functionality; otherwise the user alert can be issued by the cell phone.

6 Development Framework and Resources

Those who find the WhiteBerry/{Bluetooth} scenario interesting or compelling are invited to participate in its implementation and deployment.

The WhiteBerry/{Bluetooth} solution is part of a more general industry effort which we call Operation WhiteBerry. A comprehensive development framework exists to assist organizations and individuals who wish to participate in Operation WhiteBerry in general, or the WhiteBerry/{Bluetooth} solution in particular. This framework provides a complete set of development resources, including:

• The MailMeAnywhere open-source software distribution center and development forum at
  http://www.MailMeAnywhere.org.
• The LEAP Forum at http://www.LeapForum.org
• The EMSD Organization at http://www.EMSD.org
• The IMAP Connection at http://www.imap.org/

Each of these forums hosts several mailing lists which facilitate various forms of participation. MailMeAnywhere hosts a public forum for the collective development and enhancement of LEAP protocol engines and integration tools, while EMSD.org is a development forum for the EMSD protocol.

LeapForum.org is oriented towards coordinating usage of the LEAP protocols from an industry and business development perspective; it provides a means for organizations and individuals to announce their participation in Operation WhiteBerry, seek out partners, and coordinate cooperative effort.

6.1 Development Support from Neda Communications, Inc.

In addition, development support is immediately available from Neda Communications, Inc. As the primary developer of the LEAP protocols, Neda is intimately familiar with all aspects of the WhiteBerry model, including the EMSD applications described in this paper.

Neda can provide assistance to manufacturers and systems designers at every stage of integration and implementation of WhiteBerry/EMSD-based solutions. Neda provides a comprehensive set of support services, including sales of software licenses, assistance with portation, and consulting services. For complete details, visit the Neda website at http://www.neda.com/.

6.2 Invitation to Cell Phone Manufacturers

We particularly encourage cell phone manufacturers such as Motorola, Nokia, Ericsson and others to do the simple engineering concept validation work required to prove the viability and ease of implementation of the basic WhiteBerry/{Bluetooth} model. This requires nothing more than:

• Acquiring the EMSD User Agent software in source form
• Acquiring a basic IMAP Server Agent implementation in source form
• Integrating these two protocol engines with the cell phone software

The EMSD User Agent source code is readily available at http://www.MailMeAnywhere.org. Alternative versions of the IMAP Server Agent software are available in source form from both the University of Washington and Carnegie-Mellon University; both versions are also readily available at http://www.MailMeAnywhere.org.

A complete package of resources required to emulate the basic implementation using a desktop PC in place of the cell phone is also available at http://www.MailMeAnywhere.org. This can be used for demonstration purposes, and as an example or starting point for software development purposes.

6.3 Open-Source Software Licensing

Both the EMSD and IMAP software is freely available in source code form. In particular, the EMSD software is available under the terms of the GNU General Public License (GPL). The GPL places no restrictions on use of the software for the development and proof-of-concept purposes described above. The GPL model is also very well-suited to allowing and encouraging widespread implementation of EMSD and IMAP on open PDA platforms. Specifically, the GPL is oriented towards environments which permit the integration of open-source software components.

However, the cell phone is not such an environment. On the contrary, cell phones have traditionally been regarded as closed consumer devices, for which the source code is almost always a proprietary trade secret.

The GPL places certain restrictions on commercial usage of the software, including its usage in closed devices, and such usage may be in violation of the GPL. Phone manufacturers are advised that they may need to acquire professional license agreements in order to make use of the EMSD and IMAP protocol engines in commercial contexts. Such commercial (non-GPL) licenses are readily available for use in cell phones and other closed environments.

A Device Options for the Mobile Professional

The mobile professional of today can choose to carry any of a wide variety of communications and productivity devices. Throughout this article, however, we make the basic assumption that carrying separate cell phone and PDA devices will remain a viable and important option for a large class of mobile users.

In this appendix we provide a general discussion of the device options available to the mobile end-user, and we provide justification for this assumption.

A.1 Device Options for Cell Phones and PDAs: Integrated vs. Specialist

Today’s mobile professional has at least three major communications and productivity requirements:

• Voice communications. The user requires voice communications for synchronous person-to-person interaction, and also for asynchronous voice messaging. This requirement is usually provided by the user’s cell phone.
• Personal information management (PIM). The user requires the usual set of information management tools, including calendar, address book, memopad and task list. These are most often provided by some sort of PDA (Personal Digital Assistant) device.
• Mobile Messaging. For those situations in which data messaging is more suitable or appropriate than voice interaction, the user requires Mobile Messaging capability, in particular e-mail. This can be provided by a stand-alone wireless e-mail device, or by integration of the e-mail application into the user’s cell phone or PDA.

If we leave Mobile Messaging out of the equation for the moment, and focus on just the voice communications and PIM requirements, our mobile professional has two basic choices:

• Carry separate and independent cell phone and PDA devices
• Carry an integrated cell phone/PDA device

Until quite recently, the mobile professional would have been obliged to carry a physically separate cell phone and PDA, since neither of these could provide the essential functionality of the other. Now, however, there are a variety of integrated cell phone/PDA appliances available in the marketplace, which combine voice communications and PIM capabilities into a single integrated device.

This phone/PDA integration has been approached from both the phone side and the PDA side. From the phone side, a number of cell phone manufacturers have marketed integrated phone/PDA models, including the Ericsson R380s, Kyocera Smartphone and QCP 6035, Mitsubishi/Trium Mondo, Motorola Accompli 009 and Accompli A6188, Nokia 9000, Microsoft/Sagem WA3050, and Samsung SCH-i201. And from the PDA side, Handspring has recently marketed its VisorPhone device, a snap-on module that turns its Visor handheld PDA device into a cell phone.

The great advantage of the integrated cell phone/PDA is the obvious convenience to the user of having both of these functions provided by a single device. However, this convenience is offset by certain disadvantages.

The cell phone/PDA is in many ways an integration mismarriage. Note that from a user interface point of view, cell phones are primarily ear and mouth devices, while PDAs are primarily hand and eye devices. For this reason the user interface and form factor requirements of the cell phone and the PDA are fundamentally different, and frequently in conflict. Furthermore, the cell phone represents the culture and traditions of the telecommunications industry, while the PDA represents those of the data communications industry. For all these reasons, marrying these two devices together requires major engineering compromises and tradeoffs.

As a result of this, the integrated phone/PDA lacks the form-follows-function elegance of the best of the cell phones, or the best of the PDAs. Though some of the models listed above demonstrate considerable ingenuity of design, there is no integrated phone/PDA available today that can match the functional or aesthetic integrity of either a specialized cell phone, or a specialized PDA.

This, of course, is a manifestation of a general principle: the features and performance of a multi-purpose device can never match those of a specialized device, when judged in the specialist arena. The Swiss Army Knife has undoubtedly earned its place in the world, but there are many situations in which the user is better off with a toolbox full of specialist devices.

In addition to this general consideration, there are various other drawbacks to the use of an integrated cell phone/PDA. For example, a dead battery is a constant hazard for any cell phone user, because of the inherent high-power requirements of cell phone usage. In this eventuality the multi-device user can simply use a payphone or a client’s phone, and look up the necessary numbers in his PDA address book. The integrated device user, on the other hand, has a much bigger problem, since he has now also lost his address book functionality.

A detailed comparison of integrated versus specialist cell phone/PDA functionality is outside the scope of this article. Suffice it to say that each has its own advantages and disadvantages, and neither is superior to the other under all circumstances. Which of the the two options is most appropriate for a given user depends on the usage patterns and preferences of that particular user.

Users who place a premium on convenience of portability will be more inclined to carry an integrated device, while those who place a premium on device specialization will be more inclined to carry independent cell phone and PDA devices. The integrated device and multi-device options are both viable alternatives, and each has its place in the mobile device marketplace.

A.2 Device Options for Mobile Messaging

Let us now add Mobile Messaging back into the mix. In terms of device integration, the mobile professional has four major options:

1. Messaging via specialist device. I.e. a specialized Mobile Messaging device, such as the RIM BlackBerry device
2. Messaging via cell phone. I.e. a cell phone with messaging capability, such as a WAP-enabled phone, or a phone with SMS capability
3. Messaging via PDA. I.e. a wireless-enabled PDA with bundled e-mail application, such as the integrated Palm PDA/Novatel wireless modem marketed by OmniSky
4. Messaging via integrated phone/PDA. I.e. an integrated cell phone/PDA with bundled e-mail application, such as the Nokia 9000 device

All of these are viable options, and all are in use today. Each has its own set of advantages and disadvantages, but in this article we will focus our attention on option 3 above, in which the user receives Mobile Messaging functionality via his PDA.

The great advantage of this is that, unlike the cell phone/PDA integration, this is a particularly smooth integration. The PDA is essentially a general-purpose data processing and user I/O device; and from this perspective e-mail is just another software application that fits perfectly into the PDA paradigm.

Certainly, integration of e-mail into a PDA is far more logical and practical than integration of e-mail into a cell phone, so for those users who choose to carry a cell phone and a PDA, option 3 above usually makes more sense than option 2.

Thus for the user who chooses to carry a PDA, there is little to be gained by also carrying a specialized wireless e-mail device – whatever advantage the specialist device can offer is likely to be more than offset by the portability convenience of having the e-mail functionality provided by the PDA.

Users who carry an integrated cell phone/PDA device will, of course, be most inclined to select option 4 above. But for those users who prefer to carry separate cell phone and PDA devices, we see that option 3 provides several major advantages, and for this reason is the preferred choice among mobile professionals.

A.3 Mobile Messaging via PDA: One Major Disadvantage

However, Mobile Messaging via the PDA has one major disadvantage. The PDA must be wireless-enabled, and this requires an additional device: the add-on wireless modem. This is inconvenient for the user in two respects. First, the add-on modem more than doubles the weight and dimensions of the PDA, greatly diminishing its portability, and relegating it from shirt pocket to jacket pocket. Second, the user must now maintain battery charge for two separate devices, requiring the use of two charging cradles, etc.

Eventually the modem functionality may become absorbed into and an integral part of the PDA, but we believe that this development is still some time away. For the moment the PDA and the modem are two separate devices, and will remain so for the immediate future.

In this article we describe how Mobile Messaging capability can be provided to the user who carries separate cell phone and PDA devices, while eliminating the modem requirement altogether.

A.4 Summary: Cell Phone/PDA Integration a Viable Option

As we have seen, the mobile professional can equip himself with voice, PIM and messaging capabilities in a variety of ways, including various levels of integration. The WhiteBerry/Bluetooth scenario we describe in this article is one more of these.

We do not claim to be able to predict which of these various alternatives will be more or less successful in the mobile marketplace. But we believe that each alternative is a viable option, and each has its place. The particular device configuration a user selects will depend on the specific requirements and preferences of that user.

In particular, the WhiteBerry/Bluetooth solution is appropriate for those users who want the performance and features of best-in-class, specialized cell phone and PDA devices, and who wish to have Mobile Messaging capability provided via the PDA.

References