SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Qualcomm Moderated Thread - please read rules before posting
QCOM 174.01-0.3%Nov 14 9:30 AM EST

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: engineer who wrote (19997)3/6/2002 11:53:39 AM
From: Eric L  Read Replies (1) of 196650
 
engineer,

<< Killer apps are not developed in a vaccumm, but rather on working networks in stealth mode so that you have them working and tested >>

Pretty good article here on overcoming some of the obstacles attendant to this with some good comments on BREW and a link to another older very good BREW article:

>> The Electric Kool-Aid 3G Test

Carlo Longino
The Feature
Mar 06 2002

How can developers test 3G apps on non-existent networks?

Imagine yourself as Henry Ford for a moment - you've got a fantastic idea for this thing called a "car." You've given it an engine, nice bucket seats, a cover so the driver won't get wet, and wheels. You're ready to try it out for the first time, only there aren't any roads on which to drive. What's next?
This is how thousands of application developers must feel as they aim for that elusive 3G "killer app." Sure, you've got SDKs and basic emulators, but how can you be expected to deliver a fulfilling product that shoots data across a network when that network doesn't yet exist?

3G application testing poses this unique problem. Carriers are keen to have lots of applications in place for their mass-market launches, but programmers are building software for something that in most cases, they don't have access to. Want to test your new Windows product? No problem, just load it up on the nearest PC. Want to test your WAP site? Put it on the Net and dial that sucker up. Got a new GPRS tool? Find a handset, and you're in business.

Got Your 3G App Ready To Go? Hold On A Minute.

Although 3G networks aren't widespread, some carriers do offer developers access to their test and live networks for testing purposes, and others offer extensive developer support programs. Infrastructure manufacturers are getting in on the act, too, offering various test resources or even creating new application platforms.

Carriers' Burden

The onus is clearly on carriers to give developers all the support they need in the development of 3G applications. After all, they're the ones with something to lose (namely their shirts) here. So not surprisingly, many carriers are setting up far-reaching programs to offer developers testing assistance, as well as other developmental, financial, and strategic tools.

source O2 is one such program, set up by British carrier mmO2, to engender mobile application development for existing and future networks. It offers extensive testing resources along with other technical and business expertise to help developers quickly take their product to mmO2 customers. "The aim of source O2 is to partner with developers - not just test their applications - but get them launched on the O2 networks," says mmO2's Lucy Markham.

In a facility in the famous Ealing Studios in London, source O2 has six developer "pods" - areas where developers can connect to in-building GSM, GPRS, and 3G cells, as well as BT Cellnet's real and replica GSM and GPRS networks. There's also a technical hub located in Marlow, west of London, with additional testing facilities. The hub also offers developers access to various mmO2 service platforms, the first of which allows developers to create location-based services.

In addition to test networks, source O2 has complex network simulators that let developers see how their applications respond in the most demanding situations. The simulators can adjust the level of available throughput, drop packets, lose coverage, perform handovers, and tinker with latency and jitter, all to allow the developer to see how their app performs, as well as to test and create adequate recovery measures.

The facilities, which are open to any developer, (although for a fee) are also staffed by a team of mmO2 employees with pertinent technical and commercial expertise to assist developers on both sides of the start-up equation.

But it's not all the carriers trying to buddy up so they can fill their networks - developers need their help as well. "We expect any content we will have to be attractive and time-critical enough for operators to help us test and integrate it," says John Craig of Worldzap, a company who has been an early mover in delivering video over 2G and 2.5G networks.

Worldzap tested their first product (sending German soccer highlights to PDAs) on Finnish carrier Sonera's HSCSD network, where they were provided dedicated bandwidth of around 25kbps, which Craig admits, is an unlikely situation for mass-market 3G services. He adds, though, that their relationships with UK carriers Manx Telecom (an mm02 unit with a live 3G network) and Vodafone offer 3G testing opportunities.

QA The Hard Way

Infrastructure and device makers are getting in on the act, too. Their motives are just as clear - it's hard to sell 3G equipment to a bankrupt carrier.

Hardware manufacturers have looked after developers through traditional support programs featuring access to software development kits (SDKs) and other tools, as well as an introduction into a community where developers can discuss their work and gather relevant news and information - Forum Nokia is one such example.

Ericsson has sprinkled "Mobility World" centers around the globe, and stocked them with test products and experts so they function like the business incubators of a few years ago. Developers can get assistance with anything from business plans to complex technical issues.

But Qualcomm has gone a step further. After exiting the handset business (sold to Japanese concern Kyocera in 2000), the company has to do all it can to maintain demand for products based on its substantial CDMA intellectual property and CDMA chipsets and designs - see Ray Hegarty's excellent piece on BREW at:

thefeature.com

Accordingly, the company has developed its Binary Runtime Environment for Wireless, or BREW, an open, standardized application execution platform.

BREW basically runs over a device's operating system and allows developers to program an application once and have it run on any BREW-enabled device (sounds awfully Java-esque...). But of course, Qualcomm requires applications to be "certified," then hosted on a Qualcomm server, where it can be accessed by carriers who have signed on to use BREW and are running Qualcomm's middleware.

"For data applications, the wireless industry is currently in the situation the PC industry faced in the early 1980s. Device manufacturers are developing applications for their own hardware or must pay a few select developers to work with them on the arduous task of creating and integrating just a few applications on just a few handset models," says Peggy Johnson of Qualcomm. "In the PC industry, this led to fragmentation of resources and platform dead-ends. The BREW platform, which works on today's CDMAOne networks, encourages applications development by providing a standard platform for CDMA."

BREW removes several roadblocks for developers (perhaps the main being that it allows developers to program in the familiar C/C++), the least of which is done by pushing the bulk of their applications down the network into the handset. Instead of spending time working to make the handset do something within the limitations of the network, BREW developers can put the "thinking" into the handset and then into their servers at the other end of the network, only using the carrier's resources as a pipe for raw data.

Developers can concentrate on pushing the capabilities of the device, something far easier than creating an application that tries to stretch the capabilities of a carrier's network. A BREW-type approach allows for quite a bit of interoperability; while existing networks' capabilities vary from carrier to carrier, most of those differences disappear when networks are sending generic data to a common handset application execution system, be it an OS or otherwise.

And this reduces much of the testing burden for developers. They need not, to a certain extent, be concerned with specific networks' topographies - just as BREW devices will run applications similarly from one to the next, so will BREW networks. The testing model then moves closer to that of traditional software applications, and further away from the complex trials of mobile applications for each specific network, dependent on their set-up.

This, of course, shortens time to market and increases the number of networks an application will run on, rather than being limited to those carriers with which a developer has a relationship.

Carlo Longino is a freelance writer based in Austin, Texas. His previous experience includes work for The Wall Street Journal, Dow Jones Newswires, and Hoover's Online. <<

- Eric -
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext