The basic concept of WhiteBerry is to bring the same true Mobile Messaging functionality to the user as does BlackBerry - but based on a set of open protocols, as opposed to RIM's proprietary protocols.
BlackBerry is a single-vendor solution, in which every system component is defined and supplied by RIM. By contrast, WhiteBerry is a multi-vendor solution, in which the same functionality is provided by a series of products and services, and the necessary cross-vendor interoperability is guaranteed by the openness and integrity of the underlying protocols.
WhiteBerry is thus not merely a competing system to BlackBerry - it is radically different in nature. WhiteBerry is not owned by anyone, any more than the economy is owned by anyone. Since the underlying protocols are completely open, WhiteBerry will expose every part of the generic Mobile Messaging value chain to market entry, cooperation, and competition. Mobile Messaging will be transformed from its incarnation of today, consisting of a melange of closed, non-interoperating systems, into a true industry.
All the technological components required to implement WhiteBerry already exist and are in place. These components are:
(Note: Throughout this paper we will frequently make use of CDPD as a specific example of a Wireless IP network. We do this not because we necessarily believe that CDPD has any greater relevance than other networks, but because as the largest native IP public wireless network in the world today, it provides a ready and familiar example. The WhiteBerry solution is in no way limited or specific to CDPD - WhiteBerry is compatible with any Wireless IP network.)
Given that all these technological components are well established and readily available, the final component required to bring WhiteBerry to life is the right set of open protocols to tie everything together. As we will see in the following sections, these are now available too.
The key to the open Mobile Messaging industry is the right set of protocols.
Existing Internet e-mail protocols are not suitable for this purpose, because they are lacking in two major respects. First, they lack the necessary efficiency characteristics. Wireless networks are severely constrained by bandwidth limitations, and mobile devices are constrained by limitations such as display size, battery capacity, and memory capacity. These constraints place an extremely high premium on the efficiency of data transfer. Existing Internet protocols such as SMTP [22], IMAP [8] and POP [21] do not provide the required efficiency.
Second, existing Internet e-mail protocols do not properly support the push mode of delivery, which is an essential aspect of true Mobile Messaging. For more detailed discussions of the shortcomings of existing protocols, see the Manifesto articles EMSD: The LEAP E-Mail Component [3], and Efficiency of EMSD [2].
The inadequacy of existing protocols has been well demonstrated by the business failure of Mobile Messaging services based on them. Several service providers (Omnisky and YadaYada among others) have offered mobile e-mail services based on existing land-based Internet protocols such as POP, IMAP and SMTP. But because of the inefficiency of these land-based protocols, and because they do not support the push mode of delivery, these services are no match for true Mobile Messaging systems like BlackBerry.
Therefore a new generation of high-performance, efficient protocols is required to address the demands of the mobile and wireless environment. The necessary protocols must satisfy the following key functional requirements:
In addition to these technical requirements, the required protocols must be truly open. They must satisfy the conventions and criteria of openness that have come to be expected by the Internet mainstream community, ensuring that there are no restrictions whatsoever on their availability and usage. Specifically, the protocols must satisfy the following criteria:
All the above requirements are fully satisfied by a set of mobile messaging protocols called the Lightweight & Efficient Application Protocols, or LEAP. LEAP is a set of high-performance, efficient protocols which are ideal for mobile and wireless applications.
LEAP is a layered family of protocols, of which two are of particular relevance to Mobile Messaging. The first of these is the Efficient Short Remote Operations protocol, or ESRO, published as RFC 2188 [25]. ESRO provides reliable connectionless transport services which can be used for a variety of applications, including but not limited to Mobile Messaging. For complete details on ESRO see the Manifesto article ESRO: A Foundation for the Development of Efficient Protocols, or visit the ESRO website at http://www.esro.org/.
Built on top of ESRO is the Efficient Mail Submission & Delivery protocol, or EMSD, published as RFC 2524 [1]. EMSD is a specialized native Internet messaging protocol which meets or exceeds the level of functionality, reliability and security provided by the existing SMTP protocols. EMSD has been designed with a major emphasis on efficiency, and fully supports the push mode of message delivery. For complete details on EMSD see the Manifesto article EMSD: The LEAP E-Mail Component, or visit the EMSD website at http://www.emsd.org/.
In addition to satisfying all the necessary functional and technical requirements, the LEAP protocols also fully satisfy the required openness characteristics. They are open in the broadest sense of the word: they are freely and permanently available, subject to public review and revision, and without usage restrictions of any kind. For complete details, see the Manifesto article The LEAP Protocol Development Model [4].
In principle, the WhiteBerry solution could be based on any set of protocols that satisfies the necessary requirements. Other than LEAP, however, we are aware of no set of protocol specifications that satisfies these requirements. Though we have actively searched for alternatives, to the best of our knowledge no such alternative exists. As the basis for WhiteBerry, therefore, the LEAP protocols are both ideal and unique.
The way in which the WhiteBerry solution brings Mobile Messaging capability to the user is illustrated in Figure 2. All LEAP-specific components are shown shaded in this figure. This figure is somewhat similar to Figure 1, and the description of WhiteBerry in this section is similar to the description of BlackBerry in Section 3.1. However, there are also very significant differences between the two systems.
First, the user must be provided with some form of mobile handheld device, as shown on the left side of the figure. In the case of BlackBerry, this could only be one of the two form factors provided by RIM. In the case of WhiteBerry, this could be any unconscious carry device, such as a PDA, a cell phone, or a dedicated two-way pager, from any device manufacturer who has chosen to adopt the WhiteBerry model by LEAP-enabling the device.
The mobile device must be equipped with a wireless modem. In the case of BlackBerry, this is the integral RIM modem for the BellSouth Intelligent Wireless Network. In the case of WhiteBerry, this could be any suitably miniaturized modem, which supports any appropriate wireless network, such as GSM/GPRS, Metricom, Packet CDMA, or CDPD. Though the device may be turned off, the modem will normally remain on at all times to accept incoming messages.
The device must also be equipped with LEAP device software, allowing it to communicate via the LEAP protocols with LEAP-enabled Message Centers.
Next, the user must be provided with a LEAP-enabled Message Center to support his Mobile Messaging capability. In the case of BlackBerry, this role could only be played by the RIM-operated/licensed BlackBerry Message Center. In the case of WhiteBerry, however, there is considerably more versatility in how this service can be provided.
Under one scenario, Message Center service can be provided by an independent Subscriber Services provider, as shown in the center of Figure 2. Under WhiteBerry, this role can be played by any Message Center operator - for example, by any one of the large number of existing ISP companies. All that is required for an ISP or other Message Center operator to become a provider of LEAP-based Mobile Messaging services, is for them to install the necessary LEAP Message Center software.
Anyone with access to the Internet can now exchange e-mails with the mobile user. E-mails addressed to the mobile account are fielded by the Subscriber Service provider from the Internet e-mail system using standard Internet protocols, then delivered to the mobile device using the LEAP protocols.
The device modem remains on at all times to accept incoming messages, and the device notifies the user immediately (in any of the ways commonly used for pager notification, e.g. beep, buzz or vibrate) whenever a new message arrives. The user can then activate the device and read the message.
To send a message, the user enters the message then submits it to the LEAP service provider via the LEAP protocols. The service provider then sends the message to its destination using standard Internet e-mail protocols.
Users typically wish their mobile messaging capability to function as a wireless extension of an existing land-based e-mail account. For example, the user may wish the mobile device to act as an extension of a home or office desktop mail application, as shown at the top of Figure 2. This functionality is provided by installing the appropriate mail forwarding software on the desktop system. This software integrates with the desktop mail application, and allows messages to be selectively forwarded to the mobile device on the basis of user-defined e-mail filters. Properly qualified e-mails are forwarded to the LEAP service provider using standard e-mail protocols, then delivered to the mobile device using the LEAP protocols.
When the user submits a message from the mobile device, the LEAP service provider sends the message to its destination as usual, and in addition it can send a notification to the desktop mail application, to maintain mailbox synchronization between the handheld device and the desktop system.
Under a different scenario, there may be a need to bring Mobile Messaging capability to a corporate e-mail system, as shown at the bottom of Figure 2. This functionality is provided by installing the appropriate LEAP software in the corporate Message Center. This endows the corporate Message Center with the same LEAP-enabled functionality as the independent LEAP Subscriber Service provider, which is therefore not needed under this scenario.
Like the desktop software, the LEAP Message Center software allows e-mails to be selectively forwarded to the mobile device. But since the corporate Message Center is fully LEAP-enabled, these can be delivered directly to the mobile device using the LEAP protocols.
This aspect of WhiteBerry operation constrasts starkly with the BlackBerry system, in which all messages must pass through the BlackBerry Message Center - even those forwarded from a peer Subscriber Service provider.
As described above, the WhiteBerry solution requires coordinated integration among several components. Figure 3 shows how these components fit together to provide true Mobile Messaging capability to the end user. If a sophisticated end user were to assemble these components himself, he would need to follow these steps:
And that's it. The user now has fully equivalent functionality to BlackBerry - but using his preferred choices of PDA, wireless network, wireless modem, network Service Provider, and Message Center operator. The user can assemble his WhiteBerry system using the best and/or most cost-effective option available for each component.
And if the user should happen to own a PDA/modem combination already, e.g. for wireless web browsing, then the user can provide himself with full Mobile Messaging capability at zero incremental hardware cost.
In principle, there is nothing to prevent an individual end user from doing all this for himself. In reality, of course, it is impractical for the typical user to do this on his own - which is why we have systems integrators. A systems integration company such as Omnisky or YadaYada can readily bundle together all the above components and present the end user with a complete, turnkey WhiteBerry solution.
These two scenarios (total assembly from scratch by the end user, vs. total third-party integration) represent two integration extremes. There are many shapes and sizes of partial integration lying between these extremes. For example, steps 3, 5 and 6 can readily be combined into a single product/service offering (as Omnisky does already, in fact, by packaging together a CDPD modem, AT&T account, and account activation as a wireless-enabling add-on for the Palm family of devices).
The open WhiteBerry paradigm allows a supplier to step into any conceivable market niche.
There are several challenges that can be made to the WhiteBerry model on technical and/or cost grounds. For example, the arguments can be made that wireless modems are too expensive to allow deployment of a cost-effective solution; or that battery longevity is too short to allow widespread acceptance by users.
However, these objections and others like them are ultimately without basis. In the case of the modem cost, and all other cost-related objections, the response is the same: modem and other hardware costs have been falling, and will continue to fall. There is nothing about any of the WhiteBerry hardware components to prevent them from eventually becoming available as inexpensive commodity items.
And there is no technical challenge that does not have a clear and straighforward resolution. To take the case of battery longevity, the responses are: (a) increased network cell density will reduce active device power consumption; (b) inactive device power consumption will be drastically reduced by implementation of network protocols for efficient device sleep mode, and also by close integration between the modem and the protocol software for sleep mode operation; and (c) inherent battery longevity will continue to undergo gradual improvement.
Clearly, there are no show-stoppers here. For a conclusive demonstration of this one need look no further than BlackBerry itself - if RIM can successfully bring a viable product to market, then so can others. And as the technical and cost considerations become even less relevant, things can only get easier.
In general, the desired characteristics of a network depend upon its intended usage. The ideal technical network requirements for paging, and for generalized wireless data transmission, are sufficiently different that these two applications have traditionally been considered to require different networks. Historically, paging networks (both one-way and two-way) have been considered unsuitable for generalized wireless data usage; while generalized wireless data networks have been considered inadequate for specialized paging and Mobile Messaging applications.
Because of this historical viewpoint, there is a continuing perception that only a certain class of networks are technically suitable for Mobile Messaging. However, this perception is incorrect.
The key functional criteria for suitability of a network for Mobile Messaging are:
Based on the above, it can be seen that a broad range of networks are entirely suitable for Mobile Messaging.
The BlackBerry system is currently limited exclusively to the BellSouth Intelligent Wireless Network. This network scores high marks on all four criteria listed above, and is therefore well-suited to Mobile Messaging.
But it is by no means the only network that is suitable for this. And the WhiteBerry model allows any suitable wireless data network to be used, including GSM/GPRS, Metricom, Packet CDMA, and CDPD - which collectively account for most of the wireless network market of today. With proper industry cooperation and integration, a messaging solution based on any of these networks can compete directly with closed solutions such as BlackBerry, or those based on the closed ReFLEX protocol.
The major differences between BlackBerry and WhiteBerry are summarized in Table 1.
In the world of closed systems, competition with BlackBerry takes the form of other proprietary turnkey systems, which provide similar functionality.
The WhiteBerry model is fundamentally different from this: it is an open industry model. Since the mobile messaging solution is based on a set of open protocols, each component of the solution is exposed to free competition. Vendors and service providers can now compete in every aspect of the mobile messaging solution: handheld devices, wireless modems, networks, message centers, and the provision of Subscriber Services to the user.
The result of this is not just a set of competing, closed, non-interoperating solutions. Rather it is a thriving industry, in which active and independent competition takes place within every component of the user's ultimate value proposition.
As noted previously, RIM has recently been granted a U.S. patent on the basis of its BlackBerry technology, which potentially threatens other closed Mobile Messaging systems.
The WhiteBerry solution, however, is radically different from closed systems in terms of its vulnerability to patents. Unlike BlackBerry and other closed systems, WhiteBerry is not a single static messaging solution; rather, it is a highly mutable meta-solution. That is, any particular WhiteBerry implementation is created by integrating together an appropriate set of components, so as to achieve the particular functionality desired by the systems integrator or the end user.
The components that go into any given WhiteBerry implementation may be drawn from a large family of components which includes the EMSD protocol engines, FetchMail, ProcMail, mail forwarders, and various others. Each of these components is independent, freely available, useful in its own right, and entirely unrelated to the RIM patent.
Because of this inherently component-based nature, the WhiteBerry solution is exceedingly resistant to the RIM patent claim, and indeed to patent infringement claims in general. By making all the necessary components freely and publicly available, WhiteBerry provides systems integrators and end users with a variety of methods and strategies to circumvent or nullify invalid patent assertions.
