Standards Watch : BREW Opens the Tap for Developers’ Capabilities

Wireless application developers struggle with writing applications because they must create them for countless devices, programming environments and operating systems—each with proprietary software layers and interfaces.

Because third-party developers often lack a close relationship to device manufacturers and carriers, they have had no channel for directly distributing and selling applications to wireless subscribers.

Qualcomm Internet Services (QIS) hopes to accommodate developers with the Binary Runtime Environment for Wireless (BREW), a thin applications execution environment that ostensibly is a development platform and a distribution environment that acts as a virtual market for delivering applications from developers to end users.

“In the past, developers would guess what applications might be popular, and then handset manufacturers would buy into that, and 18 months later a service would roll out. That is no longer an acceptable model, as proved by NTT DoCoMo,” says Jeremy James, senior director of marketing for QIS.

The vision for BREW is to offer third-party developers a model of faster deployment, quick access to a broader audience and an ensured payment system.

How It Works

In the BREW model, third-party developers negotiate terms and pricing directly with carriers, and then carriers place BREW applications on their download servers for end users to access from BREW-enabled handsets. Through an extranet connection, developers can see an aggregated view of what applications carriers have sold to subscribers. Subscribers are billed automatically once an application is downloaded. Through a separate extranet connection, carriers can track what applications are popular among their users as well as how much revenue to expect for the billing cycle.

“A $2 transaction doesn’t sound like a lot, but when you have multiple carriers offering the same applications to their users, it adds up into significant proportions,” says James, noting that KTF announced its annual revenue per user went up 9 percent after the November launch of its KTFreeTel Magic N Multipack service. The company boasts upwards of 250 applications offered by roughly 40 to 50 developers.

Verizon Wireless’ BREW Shop, launched in March, offers approximately 15 applications offered through 12 developers, and KDDI’s EZWeb is offering Panasonic handsets preloaded with BREW applications.

Although Verizon Wireless is a CDMA carrier, BREW is not a CDMA technology. However, James concedes that CDMA participation is expected to be a major force with BREW’s proliferation, as it is predicted that by 2005 the size of the global CDMA user base will grow to nearly 400 million subscribers, according to the CDMA Development Group.

Other CDMA carriers—such as KTF, LG Telecom, Alltel, Telesp and Pegaso, South Korean Telecom—and device manufacturers Samsung, Denso, Hyundai, LG Electronics and Kyocera Wireless have announced interest or begun initiatives to use BREW.

Offering Local- and Network-based Apps

BREW’s model is based on client-server software delivery, analogous to what Sun and Oracle tried to promulgate for computing years ago. James concedes that momentum didn’t build as readily as expected in the PC world, “but we recognize the fact there are just some things that run better locally,” he says.

So with BREW, Qualcomm and participating carriers are enabling both local and browser-based applications.

With such heavy investment in browser-based technologies such as WAP, Qualcomm includes the option to build those applications on top of BREW. “It’s not elegant that way, but carriers with legacy strategies usually have to stream in new services without disrupting existing services,” says James.

Native BREW applications are developed with C/C++ but can work in conjunction with other operating systems, such as Palm OS, Stinger or EPOC. These often act as an interface for other environments such as Java virtual machines (VMs), and allow any type of browser or microbrowser (HTML, WAP, cHTML and so on) to run on BREW as an application. Qualcomm is working with various virtual machine developers to integrate their VMs onto the BREW platform.

In fact, a live over-the-air deployment of the HP MicroChaiVM was accomplished in about three weeks. “Once the integration was complete, the virtual machine was downloaded over the air onto other BREW-enabled devices,” says James, who believes that capability will open a much broader market to virtual machines and applications written for the Java platform. He says several licensees of Sun’s Java technology have indicated they will develop software solutions for the Java platform to run on BREW in upcoming months.

Qualcomm expects provisioning applications over the air to eliminate the headaches that companies like DoCoMo sometimes experience in a browser model when deploying applications preloaded on handsets. “If you remember, NTT had to recall handsets when bugs were found after it launched on Java handsets with J2ME technology,” James says. He asserts that with BREW such repairs could be done via wireless downloads, and that Qualcomm demonstrated that capability with IBM in a virtual machine environment. “Wirelessly, IBM ran Java applets on a non-Java phone via wireless download,” he says.

Simplifying Development

The strategy with BREW is to decouple hardware and software. “Forcing each company to write its own highly constrained applications will not boost wireless applications; the competitive differentiation should be based on the quality of applications, rather than locking carriers into one technology solution or the other,” James says.

BREW is meant to simplify actual application development when writing for the requirements of wireless devices (such as memory, display and battery) and their capabilities (such as position location and telephony). Developers can tap into underlying chipsets to access local storage and processing, as well as built-in multimedia extensions, connectivity features and position location information.

“For wireless applications to gain traction, developers will have to take advantage of the phone as a unique computing platform, rather than a constrained one,” James says. Accordingly, developers are now working on direct hyperlinks that will cut down on the need for tapping navigation keys to click through multiple levels of data for one bit of information. “Rather, through one or two clicks,” he says, “users will be able to find traffic conditions or friend-finder applications, or access customer data on sales productivity applications.”

The Windows NT/2000-based BREW software development kit includes a phone emulator that eliminates the need to have established relationships with wireless OEMs, or physical possession of a handset prototype or production unit, in order to begin writing applications. The emulator supports a dynamic phone UI, phone UI customization and new device configuration by OEMs or developers.

Once an application is written, a common runtime environment—essentially a thin software interface layer that resides on a wireless device between the chip’s system software and the applications—enables end users to download programs over the air and run them on BREW-enabled devices.