Mobile Device Designers: You Can Relax Now – Part 1
I was recently talking to a new acquaintance and found that we had followed similar career paths up to a point. We had both spent some time developing mass-market consumer premises equipment, he in the cable-modem industry and myself in the DSL market. While I eventually moved to the dark side (Marketing), he now manages an R&D group for a cellular device manufacturer.
Somehow or other we started talking about the stresses of “launch day”. When you develop mass-market products, an error on your part doesn’t result in someone getting angry at you; it results in thousands or tens of thousands getting angry. On “launch day”, you know you might briefly step away from your desk and come back to dozens of emails and voice mails that essentially say, “Forget about sleeping for a few days or weeks.”
The fates of many companies rest on the shoulders of device designers. You might think these designers have access to the very best testing technology has to offer. That is not always the case, though, simply because of the related economies of scale. For example, network equipment manufacturers test their products using a network-grade packet core that works just like the live multi-RAT packet core. That works when your products are expensive network elements, but you often can’t justify a bunch of systems like that when you’re designing a $300 cell phone. Device developers therefore have to make do, spending an inordinate amount of time maintaining sets of scripts that allow a box to emulate the network.
This is not an easy job, either. In many cases emulating the network requires maintaining and editing layer-specific scripts, each of which is interdependent with others. Getting the system to run at all is a major victory, but unless the tester is an expert in NAS, RRC, etc. it’s almost a sure bet that some of the configuration is less than valid.
It’s bad enough that a development team has to spend weeks figuring out how to get a UE to attach to the scripted network. To add insult to injury, the scripted network will never truly include a network-grade core: the messaging will never be complete, latency will never be realistic, and fine details like security or IPv6 operation will never be fully tested. This all makes “launch day” very, very stressful.
So what if someone (like Spirent, for example) took a bunch of the well-proven technologies it had already developed for other testing purposes and bundled them into a single platform for the development lab? Since development costs have already been largely absorbed, that means a highly realistic testing station that is within reach of the folks who need it most, the device designers.
So, to all you device developers out there… do I have your attention? If so, relax. Help is on the way. Click here to find out more about Spirent’s CS8. And continue to look for installments of this blog for more on mobile device RF/baseband design, radio protocol design, device integration and DVT.