Bds

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 networkwide 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

Introduces the capabilities of the BDS

BDS Component Descriptions

Provides information about the components of the BDS

Over-the-Air (OTA) Application Download

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 hardwareindependent, 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 . 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, postpaid 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 multiparty 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 prepayment 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 prepaid 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