re: Comprehensive BREW Article by EMC Cellular
Do you find this reasonably objective?
>> Will Qualcomm's BREW Kick Start The Mobile Data Market?
EMC Cellular
Mike Woolfrey
24-May-2001
Qualcomm will no doubt be hoping that the introduction of its BREW (Binary Runtime Environment for Wireless) will not suffer the same initial problems as the platform's recent launch: the BREW 2001 conference held in San Diego 9/10 May 2001 gave all non-Californians a first hand experience of the recent power problems. On both days presentations and panel discussions were disrupted by city wide rolling black-outs. That aside, the conference seemed well attended with a reported 800 people making the trip to San Diego. The vast majority of these were software and application developers. There was great excitement and expectancy at what is being developed. Operators and manufacturers were represented by existing Qualcomm licence holders and current CDMA carriers.
BREW was originally launched in January 2001 and is a follow-up to the Wireless Internet Launchpad, both part of the services offered by QIS (Qualcomm Internet Services). The conference to mark its official, promotional launch was accompanied with an expansive light show introduction and the choice of title ('BREW 2001') indicates that Qualcomm hopes to stage further events. Conferences in Japan, Korea, China and the east coast of the USA are being planned.
What is BREW?
BREW is a software layer that sits between the chip system and the application, allowing one application to be developed for multiple types of device. Currently, developers have to write separate programs for each individual handset. Whilst Java has attempted to resolve this issue, Qualcomm sees BREW as complementary to Java. To date most application development has been vertical, with major manufacturers and vendors allocating limited resources to application development. In his opening address, Paul Jacobs, Executive Vice-President of Qualcomm said that BREW will allow horizontal development, enabling smaller firms and entrepreneurs to concentrate on what they do best. A BREW-enabled handset will give users access to services that can be downloaded from a carrier's server. Applications include:
* Enhanced messaging
* Games
* Location based services and information
* Entertainment
* PIM tools
* Electronic wallet and banking.
The motivation for Qualcomm to drive a project such as BREW is to see an increase in mobile data/internet usage and applications. Questions still hang over 3G, and whether consumers will actually spend the money on new applications that will see a return on investment in licences and infrastructure. Qualcomm hopes that by improving the breadth and quantity of applications that such data usage will grow. In its recent white paper Qualcomm has forecast that mobile data usage will rise to a level beyond 200MB per user per month. Whilst this figure is Qualcomm's own, it is accepted that data usage will rise and will complement voice in raising and stabilising ARPU levels.
With the increase in the number of developers and the potential ease to market BREW offers, in theory usage will rise. This rise will coincide with the high speed offerings of 3G networks, something that Qualcomm wants and needs. Although Qualcomm continues to work hard in pushing its version of 3G, cdma2000, it also needs other 3G (W-CDMA and UMTS) networks to be launched. Qualcomm receives royalties from all variations of 3G networks, and it is therefore in its interest to see 3G applications and revenue happening as soon as possible. For these reasons, BREW could be perceived as giving a jump start to applications and to the data market generally.
Although BREW has been developed by Qualcomm, it is a three tiered arrangement. A developer must design and program the application, and the operator sell and market it. For BREW to succeed, all three need to function correctly.
How does BREW work?
The first phase is for a developer to come up with a suitable application. Applications are developed with the aid of Qualcomm's BREW SDK (Software Development Kit). The SDK allows development using Windows-based tools, and removes the need to work directly with a handset or integrate applications with the chipset. The SDK is currently available free to developers and comes with text-based support, although in various break-out sessions developers were critical of the SDK support.
Once a developer is happy with its application, it is submitted to Qualcomm for BREW certification. This is done by a third party, which checks that applications are not going to crash a handset or cause other technical and operational problems.
With the appropriate certification, an application is ready to be offered to operators. A list of approved applications will be located on a BREW website server. To speed the process it is perceivable that developers and operators may work together to get a product certified.
BREW properties
* Allows developers to work with C/C++
* Supports J2ME (Java)
* Can work alongside browsers (WAP, CHTML, HTML etc.)
* Will facilitate language conversion (fee charged by Qualcomm)
* Supports voice recognition
R* equires only 100KB of memory to operate
* Will manage incoming calls/SMS when applications are operational.
However, BREW does not currently integrate with Windows CE or Palm does not allow downloading of independent websites, unless a suitable application is written.
Qualcomm pushed the fact that through BREW it is aiming to bring together various protocols and platforms. Whilst there is no direct browser function, if an operator wants a browser on its handsets it can do so, with the browser sitting above BREW as an application.
Who's backing BREW?
Qualcomm claims to have over 1,700 parties working with the SDK already. Application developers include:
Pixo
MP3.com
Hewlett-Packard
KDDI R&D Labs
Wireless Knowledge
Bandai
fusionOne.
It is not likely that the application developers are going to be the parties that drive BREW. For it to be a success the operators and handset manufacturers are going to have to adopt and promote it. Current handset manufacturers are limited, with only Kyocera, Denso, LG and Samsung have signed up for BREW. These handset manufacturers are already strong supporters of CDMA and one would expect them to back a Qualcomm initiative. The widespread use of the Kyocera QCP3035 () for demonstrations illustrated the stage at which handset vendors are with BREW. Although the list is fairly small, as BREW is integrated with the new series of MSMs and MSPs, those who buy Qualcomm chipsets will automatically have BREW supplied by QIS. The chipsets will continue to be supplied by QCT (Spinco) following its spin-off, with QIS supplying BREW. It is anticipated that QIS will supply BREW to other chipset manufacturers in the future.
The sector of the industry that can really push BREW is the operators. If an operator wishes to use BREW and the associated applications, it is in a position to exert pressure on its vendors to supply enabled devices.
Companies committed to BREW
Operator Country
Telesp Celular Brazil
Bell Mobility Canada
Telus Mobility Canada
KDDI Japan
LG Telecom Korea
KT Freetel Korea
Pegaso Mexico
Alltel USA
Leap USA
Verizon USA
Source: Qualcomm
Whilst no exact launch dates or sales projections of BREW-enabled devices have been announced, Qualcomm say launches will quickly follow the implementation of cdma2000 1x networks, with the first BREW services being offered in Q4 2001. KDDI in Japan has announced that all handsets it sells will be BREW-enabled by YE 2002.
Who makes the money?
The pricing model proposed by Qualcomm for the three parties involved (developer, operator and Qualcomm) is basic. An application developer will receive 80% of the revenue and the remaining 20% split between the operator and Qualcomm. The exact split is not public knowledge, but EMC is lead to believe that it the majority of cases the 20% will simply be split in half.
So, 80% of what? The revenue for all three parties is based on the price agreed between the operator and the developer. This need not necessarily be the price the consumer is charged. For example operators may wish to give some services away to promote usage and if this is the case the revenues will be decided by the agreed charge 'per download' or DAP.
The price (Developer's negotiated Price or DAP) is agreed via the certification process. A developer would submit an application, which is accompanied by a price tag. If the application were a game the developer may suggest a fee of $1 per play. When the game or application is given the BREW certification it is posted on a website or server for operators to select. If an operator likes the application it can add this to its list of offerings by adding it to its server. The price and charging mechanism (per download, per number of uses, fixed date or fixed time) is negotiable and the operator and developer may engage in two-way discussions to finalise a price. Operators may also want to pay a premium to gain exclusivity of an application. Once an agreed price is set, so is the revenue share. Usage is tracked by the BREW server and revenue log created accordingly. Naturally the more an application is used the greater the revenues for all involved.
Operator specific issues
What the operator charges its end user is a totally different matter. As mentioned earlier an operator may want to give certain applications for free to stimulate minutes of use (MOU) or may wish to bundle services together into a package. One thing that was very evident is the concern that operators may not have the ability to market the various applications successfully. To date, cellular operators have concentrated on the voice market, and many do not have the expertise to promote data applications.
Not surprisingly branding was identified as a key element to allow BREW and applications to succeed. BREW is unlikely to be a market facing name. Carriers will come up with individual application management systems or menus, in a similar way to which NTT DoCoMo has branded its i-mode service.
The operator will also target an increase in data traffic as a revenue stream. The concept of using data as a means to push up usage is not a new one. The theory is that by giving access to external internet content, mobile data usage will go up. Some applications will earn the operator revenue through a download fee, others through usage. However the operator markets or charges for an application it will receive the airtime revenues, with Qualcomm and the developer's revenue linked back to the DAP.
There are various other issues that involve the operators: developers are concerned about how applications are promoted or made public. If a service merely appears as a menu item within the 'BREW management' page the user is unlikely to know how good or what the application is. Both operators and developers were agreed that word-of-mouth is likely to play a big part, especially in the area of entertainment and games.
The expense for the operator could be considered to be minimal. All it need do is introduce a billing system and an application server. Qualcomm also says it will deploy the server or act as a host, if necessary. The billing hardware is not likely to be the problem - the charging structure may be.
Application developers
BREW does seem to offer the developer a unified platform that will ease the process in producing good applications for a larger market. The process of writing one application for many terminals and markets will no doubt help the distribution of a company's product. However its fate and scope for success are governed by two key factors. Firstly, BREW has a limited market reach, in that it is just aimed at the CDMA world. The second is that the success of an application is very much influenced by how successfully marketed it is by the operator. Therefore the success of an application is somewhat out of the developer's hands. Qualcomm has indicated that it will help developers market products, but like the billing and revenue streams, it seems unclear how applications are going to be pushed.
Developers have also voiced concerns about the SDK. As well as the text-based support being less than ideal, the handset simulator on Windows runs faster than existing handsets, which therefore creates an unrealistic environment for application development and testing.
The fees charged and revenues may not be ideal for some developers, especially smaller ones. It could be between two and five months from when an application is used to when the developer gets paid (by Qualcomm). This takes into account billing cycles of indvidual operators, verification of usage by Qualcomm and then payment terms. Developers were also unclear on whether or not data history and usage would be accessible.
The current SDK kit is Qualcomm's own, but as more and more companies use it, it is likely to be subjected to alterations and improvements. Many of these are likely to be developer led; how a developer maybe rewarded for such improvements and the IPR (Intellectual Property Rights) associated with this appear unresolved.
The fees payable to Qualcomm were also discussed. Whilst BREW certification for each application is charged at cost, $500 - $2,000, there is a tiered system with developers. Enhanced level developers will pay a fee (unknown), but will be granted access to Qualcomm's BREW labs and will get applications certified quicker than standard developers. Other benefits to fee payers will include discounted exhibition space at developer events and a limited amount of additional developer support. One final expense is the need for VerSign's digital certificate, this costs $400 a year and provides access to the developer Extranet.
Handset manufacturers
For existing Qualcomm chip buyers the decision to install BREW on future handsets is not a major issue. As stated earlier, future MSMs will come with BREW as well as other application tools (GPS location, Bluetooth MP3 player etc). So if a company wants to put its BREW-based product on a handset it will only need to inform its supplier.
The problem lies with handset manufactures that do not use Qualcomm chipsets, and more importantly use GSM, TDMA and ultimately W-CDMA. Qualcomm maintains that it is working with such handset manufacturers, but as yet BREW is limited to CDMA handsets using Qualcomm chipsets. Whilst this is a large market, BREW will need to break into other areas if it is to become a global platform. How Qualcomm would financially facilitate BREW on handsets developed by non-Qualcomm licensees is likely to be a major issue. Vendors are unlikely to want to pay Qualcomm a fee to BREW enable handsets.
Will BREW be a success?
Like the rest of the mobile internet and data market it is unclear how the business will grow, but Qualcomm is clearly using BREW as a tool to promote growth in data. As the requirements grow for data and increasing data speeds, Qualcomm is likely to earn its revenue through royalties and licence fees from W-CDMA and cdma2000.
Qualcomm was very keen to stress that the positioning of BREW is seen as complementary to various other applications and platforms. This includes working alongside Java and allowing browsers to sit on top. With external sites and independent content (like the internet) BREW will act as an application-based bookmark with services accessed via a proxy server. The company is stressing the idea of BREW being a revenue share with the two other parties, rather than another licensing scheme for Qualcomm.
Many user interface problems will be no different on BREW than other 3G services and devices. However the option to access content through something other than a browser seems like a logical step, and as devices develop and move towards 3G, the UI and experience will improve.
One key point that seemed to be omitted was power. Much of the excitement and growth that those associated with BREW were showing centred around gaming. The CEO of Chasma, a games application development company managed by teenagers, predicted that games over cellular handsets will grow like sales of Nintendo's Gameboy (65 million to date). If this is to be realised the issues of getting enough battery life to the device need to be addressed, as one long game could leave a handset with insufficient power left for its primary function, voice.
Despite Qualcomm's beliefs, BREW does have a number of barriers to its expansion. Despite maintaining that it is not a licensing scheme, it could easily be perceived that way. The problems that dog the growth of cdma2000 networks in non-CDMA markets are likely to be mirrored by BREW. Not all companies are happy paying royalties and fees for IPR to Qualcomm and this is unlikely to change overnight. BREW is likely to find early success limited to existing cdmaOne markets. <<
- Eric - |
