BREW Delivery System

(BDS) Overview

White Paper

| Internet Services
 QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA. 92121-1714
U.S.A.
Copyright © 2003 QUALCOMM Incorporated
All Rights Reserved

Binary Runtime Environment for Wireless and BREW SDK are trademarks of QUALCOMM
Incorporated.
TRUE BREW, BREW, and QUALCOMM are registered trademarks and registered service marks of
QUALCOMM Incorporated.
Sun, DiskSuite, Java, Netra and Solaris are trademarks or registered trademarks of Sun
Microsystems, Inc.
Zeus Web Server is a trademark or registered trademark of Zeus Technology.
Apache JServ is a trademark or registered trademark of The Java Apache Project.
Oracle is a trademark or registered trademark of Oracle Corporation.
All trademarks and registered trademarks referenced herein are the property of their respective
owners.
 Contents
Introduction.............................................................................................................. 1
BDS acronyms and terms ...................................................................................................2

The BREW Solution ................................................................................................. 3

The BREW solution .............................................................................................................3
Benefits to application developers.......................................................................................4
Benefits to device manufacturers ........................................................................................4
Benefits to operators ...........................................................................................................4
An integrated business model .............................................................................................5
About the BREW client........................................................................................................6

The BREW Delivery System: Managing the Business Aspects........................... 7

Steps 1a, 1b: Application Submission .................................................................................8
Steps 2, 3: Virtual negotiation .............................................................................................8
Step 4: Create/edit catalog..................................................................................................8
Step 5: Activate catalog.......................................................................................................9
Steps 6, 7: Subscriber views catalog and buys application over the air .............................9
Steps 8, 9: Creating the mediated usage record and exporting to billing systems .............9

BDS Component Descriptions.............................................................................. 10

Unified Application Manager (UAM) ..................................................................................10
Application Download Server (ADS) .................................................................................10
Transaction Manager (TXN)..............................................................................................11
BREW Billing Services ......................................................................................................12
BREW Solution Integration Options ..................................................................................12

Over-the-Air Application Download ..................................................................... 13

Application OTA download handshake between device and ADS....................................13
OTA application download processing for pre-pay subscriber..........................................14
OTA application download processing for post-pay subscriber ........................................16

Conclusion ............................................................................................................. 17
 Introduction
This document provides a general overview of the capabilities and components of the BREW
Delivery System (BDS), a key element of QUALCOMM’s BREW solution. The BDS is a wireless
data services delivery and billing environment. Leveraging open and extensible technology, the
BDS enables network operators to rapidly deploy wireless data services to subscribers network-
wide via mobile devices.

As a pioneer in the wireless space with core competencies in wireless network technology,
QUALCOMM has developed BREW as a complete, end-to-end solution for the wireless data
applications market. While other companies focus on the technical challenges of running
applications on mobile devices, QUALCOMM has an all encompassing approach to solving the
challenges facing the wireless industry – creating a framework that connects essential players in
the wireless data value chain, including network operators, device manufacturers and
developers, with the tools necessary for the creation, delivery and billing of wireless data
applications.

The result is an environment that combines an openly extensible technology platform and a
well-developed business model for revenue sharing along the entire value chain. The BREW
business model is supported by the activities performed by the components of the BDS.

This document will describe the various components of the BDS and how they work together to
enable a complete wireless data services delivery environment. This document is divided into
the following sections:

The BREW Solution Provides a general overview of BREW

The BREW Delivery System: Managing the
Business Aspects
BDS Component Descriptions
Over-the-Air (OTA) Application Download
Introduces the capabilities of the BDS
Provides information about the components of
the BDS
Describes the processing of a subscriber-initiated
OTA download

The positive implications of the complete BREW solution, including the BDS, for network
operators are undeniable. Millions of dollars are at stake as operators look to wireless data
services as a means to supplement voice services revenues. Those operators who can rapidly
diversify their wireless revenue sources are most likely to thrive in the new wireless economy.

With BREW, several operators are already seeing the success of this strategy. Leading
operators, such as KTF in South Korea, KDDI in Japan, and Verizon Wireless and ALLTEL in
the United States, have realized returns on investments and look forward to future increased
revenues from wireless data services. Other operators, such as Australia’s Telstra, China
Unicom and Vivo (the joint venture between Telefonica Moviles and Portugal Telecom) in Brazil

1
are deploying BREW-based products and services in a matter of weeks, rather than years. Time
is money, and the BREW solution, complete with BDS, provides the path to profit in today’s
wireless industry.

BDS acronyms and terms

Following are definitions for some acronyms and terms that are used in this document.

ADS Application Download Server. The ADS hosts the operator’s catalog of applications and is
the service to which subscribers connect for catalog browsing and OTA application
downloading.

Application An application that has been distributed for use on the BREW platform. Application
(apps) types include:
• Standard apps -- those that are only made available to operators after having
passed TRUE BREW testing. All billing collection and payment for these apps is
processed through BREW billing services.
• Operator-managed apps -- those that result from a direct relationship between
the operator and the developer for specific applications. Developers of these
apps are paid directly by the operator.
• Downloadable apps -- those that a wireless data subscriber can download over
the air (OTA) to their wireless device.
• Pre-installed apps -- those that an operator has made available to a device
manufacturer for the purpose of pre-installing (also called pre-loading) onto a
device. These applications are typically included in the purchase price of the
device.

Catalog An operator’s collection of application offerings to subscribers.

Category A grouping of related applications within a catalog. For example, an operator could create
one category called “Business Applications,” another called “Games,” and so on. An
application can be listed in multiple categories within a single catalog.

DAP The Developer Application Price, which is associated with payment to the developer
based on application usage. The DAP is analogous to a wholesale price.

List price The retail price for the application. This is the price that is set by the operator and
displayed to subscribers on a handset via the operator’s catalog prior to purchase and
OTA download.

Price plan Developers offer a wholesale price plan to operators for their applications. Each price
plan can have one or more of the following pricing methods: Monthly subscription, upfront
purchase, upgrade (if applicable), demonstration, or preinstall on device. If the developer
includes an upfront purchase method, it can be one of the following: Number of uses (a
use is defined by the developer), number of days the app is available to subscriber,
minutes the subscriber can use the application, or set a specific date when the application
can no longer be used. The developer can set up to three price points for the upfront
purchase method (e.g., $1 for 30 days, $2 for 90 days, and $5 for unlimited days).

2
Subscriber The user of a BREW-enabled device; customer of a network operator, also frequently
called “consumer” or “end user.”

TXN, MTXN, CTXN The Transaction Manager. The TXN binds device event data from the ADS with business
data from the UAM “virtual marketplace” into mediated usage records that are used for
billing.
MTXN refers to the Master (centralized) TXN located in the BREW Data Center.
CTXN refers to a TXN installed at the operator site, with data interfaces to BDS
components in the BREW Data Center and at the operator site.

UAM The Unified Application Manager. The UAM provides a virtual marketplace for application
acquisition, where application developers, via a Developer Extranet interface into the
UAM, can offer their wireless applications to operators. Operators can preview the
applications and negotiate price through a Carrier Extranet interface into the UAM.

The BREW Solution

This section provides an overview of the benefits of QUALCOMM’s complete BREW solution,
and describes in general terms the components of BREW and how they relate to one another.

The BREW solution

The BREW solution supports today’s business and technology requirements for rapid
deployment of wireless data applications services. The BREW solution is hardware-
independent, open to extension by third parties and consistently deployable on any network and
on virtually any mobile telephony device, including smartphones and PDA’s.* The BREW
solution consists of an application execution environment (the BREW client) that runs on top of
the device chipset software and integrates in a secure fashion with the BREW Delivery System
(BDS).

*
Implementation of the BREW client is not required when such an OS is present. BREW Shop, a native
PDA shopping application, communicates with the BDS, enabling BREW operators to offer PDA apps to
their wireless PDA subscribers with no back-end changes to the system they already have in place.

3
BREW is an end-to-end solution, encompassing both an openly extensible technology platform
and a well-developed business model for revenue sharing along the entire value chain.

Benefits to application developers

The learning curve for application developers is minimal because the Binary Runtime
Environment for Wireless™ platform for wireless devices (the BREW client) is based on C/C++.
It also can be extended by third parties for other interpreted development languages. Three
Java technology-based virtual machines (VM) that comply with the J2ME™ specification of the
Java Community Process have already been publicly demonstrated or announced as BREW
extensions. The BREW SDK™ (software development kit) is available to all developers as a
free download from the BREW web site <http://www.qualcomm.com/brew>. The BREW
business model gives developers a convenient way to offer their applications to all participating
global operators simultaneously.

Benefits to device manufacturers

For device manufacturers, BREW provides tools that ease the integration of the BREW client
onto devices. The BREW client requires little memory on the device, which makes it easily
ported to memory-constrained, lower-cost devices that appeal to the mass market. At the same
time, because BREW enables the rapid deployment of services that provide wireless
subscribers with a multitude of interesting and useful non-voice capabilities, BREW is driving the
popularity of higher-margin, color-screen devices.

Benefits to operators
The BREW Delivery System provides operators with an integrated business model that allows
them to quickly bring to market a variety of offerings to their subscribers. A secure extranet site
gives operators complete control over the selection, management, pricing, usage tracking and
billing of applications.

4
An integrated business model
Distribution, management and the sale of wireless applications are the core of the BREW
business model.
BREW Delivery Process

The BDS enables a virtual marketplace that:

– Allows submission of applications from developers and facilitates application testing

through third-party test centers;
– Supports a global developer community from which an operator can choose from
myriad applications developed in varied languages (C/C++, Java, XML, etc.);
– Provides for virtual negotiation between operator and developer via the BREW Carrier
and Developer Extranet sites.
The BDS enables customization of product offerings to subscribers via operator catalogs,
providing:
– Comprehensive catalog management functions that enable an operator to maintain
product catalogs;
– Secure, reliable OTA download, execution and deletion of apps on wireless devices;
– Download services that are extensible and can integrate with operator pre-paid, post-
paid and user-authorization services.

5
The BDS enables financial services, including:
– Logging and propagation of subscriber BREW transactions through a Carrier Extract
XML interface containing mediated usage records for billing;
– Integrated developer billing services that support invoicing, adjustments, collections
and multi-party settlements based on mediated usage records;
– SNMP, HTTP, Java and XML data interfaces to support operator billing integration and
other services;
– Extranet reports and interfaces for subscriber support and billing reconciliation reports.

About the BREW client

The BREW client software exposes a common set of application programming interfaces (APIs)
for standardized development of wireless applications.
BREW Client Layer

In addition to the BREW client APIs, BREW provides an operator and its device manufacturers
with a BREW application manager, which is used by subscribers to purchase and manage
BREW applications on the device. A number of device manufacturers have already decided to
develop their subscriber interfaces on top of BREW, allowing for an OTA upgrade of the entire
subscriber experience, even after a device is sold and in the subscriber’s hands. The BREW
application manager is provided in source code, allowing the operator to customize the
subscriber experience. The BREW client software requires minimal memory, so the operator
can offer wireless application service on its entire device line-up, from low-end mass market
phones to high-end devices.

6
QUALCOMM has demonstrated the ability to run a single application on different device
platforms and across multiple network technologies (i.e., GSM/GPRS, CDMA IS-95, CDMA2000
1X, UMTS, etc.).

The BREW Delivery System:

Managing the Business Aspects

This section discusses the process of distributing and managing applications and describes the
BDS components tasked with handling each step of the process.

The following diagrams provide a graphical reference to the topics discussed in this section, and
present a comprehensive overview of the process and corresponding system flow.

This diagram shows the steps involved in the BREW lifecycle. Detailed descriptions of each
step and related components follow.

Key steps in the BDS process flow

7
This diagram shows the application distribution flow in terms of the various BDS components.

How the BDS works

Steps 1a, 1b: Application Submission

Applications (standard or operator managed) are submitted via a secure Web interface and are
processed and stored in a repository called the Unified Application Manager (UAM).

Steps 2, 3: Virtual negotiation

After a standard application is processed by the UAM, the developer can create an operator
price plan(s). Once the price plan is created, the application is visible to the operators targeted
by the developer. Operator(s) can download and test any standard application before
negotiating the price plan with the developer.

Operators can use the BREW Carrier Extranet to negotiate developer pricing. In turn, the
developer uses the BREW Developer Extranet to negotiate pricing with operators. The UAM
stores the developer’s application price plan, which includes the Developer Application Price
(DAP). Only the developer can edit the price plan.

Step 4: Create/edit catalog

The operator catalog is a hierarchical structure of categories that contain applications. The
operator manages the catalog structure and the applications offered in the catalog. The operator
8
specifies the ordering of categories and the applications within them using catalog management
services available on the BREW Carrier Extranet. The operator has control of all retail pricing
exposed to its subscribers, but it cannot change the developer’s pricing (DAP). The retail
price/list price is designated to be a single, operator-selected currency throughout the catalog.
Operators can present the catalog in multiple languages.

Step 5: Activate catalog

Once catalog editing is complete, the operator can set a specific time/date to activate the
catalog on an Application Download Server (ADS) farm. Only one catalog can be active on an
ADS farm at any point in time. (See the BDS Component Descriptions section beginning on
page 13.)

Steps 6, 7: Subscriber views catalog and buys application over the air
After the catalog is activated on the ADS farm, the subscriber can access it through the BREW
client (defined on page 7). Operators may give this mobile shopping experience a brand and/or
service mark, such as Verizon Wireless has done with its “Get It Now” service or as South
Korea’s KTF has done with its “magic n multipack” service. If the subscriber decides to
download an application, a confirmation prompt is displayed to the subscriber indicating the
price of the application. If the subscriber confirms to proceed with the download, the application
files are downloaded to the device over the air from the ADS.

When all application files have been downloaded successfully and verified, a download
acknowledgement is sent to the ADS. The ADS then passes the transaction events to the
transaction manager (TXN). If the subscriber has previously downloaded the application and
decides to extend their ability to use the application through an additional purchase, the usage
license will be updated but the application will not be downloaded again, saving the subscriber
air-time charges.

Steps 8, 9: Creating the mediated usage record and exporting to billing

systems
The TXN processes the phone events collected by the ADS’s and converts each record into a
mediated usage record containing a rich set of usage information (e.g., subscriber ID, time
stamp, event type, developer name, DAP and retail price). The TXN-mediated usage records
are exported to the operator on a periodic basis. The same records sent to the operator are
used by BREW billing services to process BREW developer settlements. This is critical because
all financial reconciliation between BREW, the developer and the operator are based on a single
set of mediated usage records.

9
 BDS Component Descriptions
This section provides brief functional descriptions of the BDS components.

Unified Application Manager (UAM)

The UAM provides a virtual marketplace for application acquisition, wherein application
developers can offer their wireless applications to operators. The UAM stores BDS configuration
information, application files, application pricing structure, operator information, developer
information, system audit trails and operator catalogs. Both standard and operator-managed
applications (defined on page 10) are processed by the UAM.

Once applications are placed in the UAM, operators and developers can participate in virtual
marketplace activities, including negotiating price plans, selecting applications, creating and
activating catalogs (as described in previous section “The BREW Delivery System: Managing
the Business Aspects”). Developers and operators manage these various activities via the
BREW Developer Extranet and the BREW Carrier Extranet, which are initiated by the UAM.

The UAM stores the operator’s catalog structure, which includes category hierarchy, application
versions and pricing information. Activation requires the catalog and associated applications to
be propagated from the UAM to the operator ADS farm. This catalog activation is scheduled by
the operator via the BREW Carrier Extranet and is processed by activating a catalog dialog
between the UAM and the designated operator ADS farm.

The UAM also stores information that the Transaction Manager (TXN) requires to translate a
phone event into a billable mediated usage record. The UAM is the authoritative source for all
detailed pricing information. As such, the UAM contains a data interface to the TXN to replicate
pricing and business information.

Application Download Server (ADS)

The ADS is a load-balanced farm that consists of a collection of small, stateless servers used to
deliver applications to subscribers securely over the air. The ADS also stores and propagates
purchase transactions to the TXN. The ADS contains applications, category lists and logging
information on the file system. No relational database management system is required on the
ADS.

An ADS farm consists of a series of redundant Web servers behind a hardware-based load
balancer. The number of servers in a farm can vary based on load and availability requirements.
ADS servers can easily be added and removed without interruption of BREW OTA download
services to subscribers.

10
The configuration of the operator ADS farm for commercial operations is determined by the size
and activity characteristics of the operator’s subscriber base. The following figure depicts a
typical ADS network architecture.
Typical ADS network architecture

The operator can locate the ADS farm within its data network as a central service to all
subscribers, or the ADS farm can be regionalized.

Transaction Manager (TXN)

After an ADS collects subscriber application download and delete events, these phone events
are propagated to the TXN for billing mediation.

The TXN combines phone events from the ADS with business data from the UAM to create
mediated usage records. In addition to mediating the phone event data, the TXN includes
additional event types to be processed through operator and BREW billing services. These
additional events include transaction adjustments events, subscription billing events and public
extension events. (Public extension events occur when the BREW client is extended in a
standard fashion by developers or by the operator, and when subscribers purchase applications
that use the extension. A Java technology-based virtual machine is an example of an
extension.) All these events are visible and processed by the operator billing system and the
BREW billing service.

The operator can select to use either the master TXN (MTXN) located in the BREW Data Center
or to install and manage its own operator-based TXN (CTXN) hosted network-close to the
operator ADS farm. The CTXN interfaces with the necessary BDS components – such as the
UAM – that are housed at either the BREW Data Center or the operator data center.

11
Operators using the MTXN receive mediated usage records as XML extracts at specified
intervals (e.g., every 30 minutes). In a CTXN configuration, the ADS farm is typically co-located
with the CTXN server in the same data center to allow for a real-time mediation service.

BREW Billing Services

BREW Billing Services produce invoices to operators for fees due to application developers. A
developer providing standard applications can receive a consolidated monthly payment for all
BREW-related activity across all BREW operators offering that developer’s applications. BREW
Billing Services has embedded capabilities to support foreign currency, accounts receivable
aging reports, billing reconciliation reports, transaction usage reports, foreign withholding tax
and other financial services required for international business transactions.

Because BREW Billing Services and operator billing services process the same set of usage
records generated from the TXN, reconciliation between QUALCOMM and the operator for
invoice fees are resolved back to a common set of usage records. This enables easier multi-
party reconciliation efforts between developers, operators and QUALCOMM.

Operators are responsible for processing payments to developers providing operator-managed

applications as well as subscriber billing and collections for all BREW apps. These operator
billing services are based on common set of TXN-generated usage records.

NOTE: BREW Billing Services do not process fees associated with operator-required taxes (i.e.,
state and local taxes in the United States) due from the sale of an application.

BREW Solution Integration Options

To provide operators with flexibility and control in managing their wireless data services, BREW
provides other standard and optional interface points:

ƒ The ADS includes APIs for real-time pre-pay clearing, real-time subscriber access
authorization and system health monitoring.

ƒ From the BREW Carrier Extranet, the operator has access to subscriber activity and billing
reports, as well as an area to perform subscriber related adjustments.

ƒ The BREW client can be extended in a standard fashion by developers or by the operator.
The developer of a BREW extension, such as a Java technology-based virtual machine, is
compensated in a manner similar to BREW standard application developers, as
subscribers purchase applications that use the extension.

12
 Over-the-Air Application Download
This section discusses the processing of an OTA application download, which is invoked by the
subscriber on the device and may result in an application fee that is reflected on the
subscriber’s billing statement.

To describe the processing flow, this section is divided into the following sections:

ƒ Physical processing flow

ƒ Handshake between device and ADS

ƒ Processing for pre-pay subscriber transaction

ƒ Processing for post-pay subscriber transaction

Application OTA download handshake between device and ADS

The following diagram depicts the call flow handshake process between the device and the ADS
as the subscriber requests an application download.

13
Each request to the ADS is routed based on the load balancer to independent servers in the
ADS farm. Because the architecture of the device to ADS is stateless, the device can connect to
a different server in the ADS farm for each request. The following summarizes the call flow:

1. Security and Setup Handshake -- The device is authenticated to verify that the requester is
an authorized operator device. BREW supports different device authentication services.
Additional activities taking place during this handshake include processing applications
designated for operator-wide recall, processing any queued transactions on the device and
performing optional subscriber authorization.
2. Get Category List -- The subscriber requests to view the applications in a specified
category list. This is a separate request to the ADS to get the list of applications for the
specified category. The application list returned is filtered based on the device model,
BREW client version and language on the device. The applications are listed, and the
subscriber can view available application pricing options.
3. Get Application Within Category -- The subscriber selects an application for download and
selects from one of the available pricing options. The download request is sent to the ADS,
which processes pre-pay authorization, if applicable. If the download request is post-pay,
the download is, by definition, authorized.
4. Application Download Request -- If authorized, the device proceeds to download all
appropriate files for the selected application. After verifying that all files were downloaded,
including a digital signature check, a download acknowledgement is sent immediately to
the ADS.
5. Download Acknowledgment -- Once the ADS confirms receipt of the download
acknowledgement from the phone, the phone activates the application for launch on the
device.

OTA application download processing for pre-pay subscriber

When a subscriber is designated by their operator as a pre-pay customer, the ADS performs an
authorization check for each download to their device. The BREW solution manages pre-
payment processing, referred to as BREW pre-pay, by integrating authorization and subscriber
debit services to operator provided pre-pay services. The following figure illustrates how a pre-
paid transaction is processed.

14
 Process for pre-paid transaction

The following steps address the figure above:

1. The subscriber is set up as pre-pay.

2. The subscriber initiates a purchase request.
3. The ADS detects that the download request is associated with a pre-pay subscriber.
4. The ADS contacts the operator pre-pay service to verify whether to proceed with the
application download request.
5. The operator pre-pay service checks the subscriber’s balance and returns a “yes” or “no”
response to the ADS, which tells the ADS whether to proceed with the download request.
6. If the response is “yes,” the ADS processes the download of all relevant application files to
the device.
7. If the response is “no,” the device displays notification that the download request is not
authorized for processing. The response might be “no” because the pre-pay account
cannot be verified, or because there are insufficient funds in the pre-pay account. (The
message displayed on the device can be customized.)
8. If the response is “yes,” all application files are downloaded to the device.
9. Once all application files are downloaded to the device and checked against a digital
signature, the ADS processes a second call to the operator pre-pay server. The operator
pre-pay service then debits the subscriber.
10. After the confirmation response is received, the ADS sends the device an
acknowledgement to activate the application on the device, and the ADS download
acknowledgement is propagated to TXN for usage record mediation.
11. The application is available for use on the device.

15
OTA application download processing for post-pay subscriber
In addition to pre-pay, the BDS also supports a post-pay model. The following steps describe
the processing of a post-pay transaction:

1. The subscriber is identified as a post-pay customer.

2. The subscriber requests an application download.
3. Download request is sent to the ADS.
4. The ADS delivers all relevant files for the requested application.
5. Once all application files are successfully downloaded to the device and checked against a
digital signature, a download acknowledgement is sent from the device to the ADS
confirming download completion.
6. The application is activated on the device.
7. The application is available for use on the device.
8. The ADS propagates the device event to the TXN for further usage record mediation.

16
 Conclusion
QUALCOMM’s BREW solution is hardware-independent and consistently deployable on any
network and on any wireless device. BREW is an end-to-end solution, encompassing both an
openly extensible client platform and a well-developed business model for revenue sharing
along the entire value chain.

The BDS is a key component in the BREW solution – providing the framework for selection,
delivery and billing of wireless applications by network operators. Using the BDS along with the
other elements of the BREW solution, network operators can quickly and easily deploy wireless
data services network-wide for subscribers.

# # #

17