Wireless infrastructure & handset software - counter-synergies?

There are many providers of wireless network infrastructure and applications servers.

There are also many providers of embedded software for mobile handsets.

Surely, there must be synergies for companies (or deep partnerships) that provide both?

Not necessarily.

Generally, the only reason that an infrastructure company needs its own handset client software is if it has a proprietary product. If the technology isn't standardised or at least "open" to external developers, this means that the vendors needs to offer an "end-to-end solution". Great in principle, but it inevitably means it will only work on a restricted range of devices. Which is fine if the service is so compelling that customers will "take what they're given" in terms of phones, but not if they're average consumers deciding they need a pink RAZR or a black Chocolate before they think about what applications it can support.

What are the more successful examples of one company producing both sides of the equation, servers/infrastructure and also devices or device software? RIM springs to mind, but that's hardly mass-market. Maybe Motorola with its iDEN network & devices for Nextel. Macromedia/Adobe might get there with Flash. Opera's Java-based Mini client is getting some traction too. Maybe Real, and bits of Microsoft.

With the exception of iDEN (which looks like it's now on the wane anyway) all of these are "high level" applications, which can be ported relatively easily across devices and sit on top of smartphone OS's or featurephone app stacks or inside Java. They don't need too much messy integration with chipsets and protocol stacks.

(OK, Qualcomm is arguably the Daddy here, but it work on the basis of IPR licencing, rather than actually getting its hands dirty and building networks & phones itself).

I think there's another category of infrastructure vendors needing their own handset clients or integration expertise. It's where there aren't enough (or deep enough) standards spanning both protocol-level bits, and the higher-level user interface layers. In other words, handset vendors can't make decent phones even if they follow published standards, because they aren't sure how the user will interact with the service. Either that, or the chipset companies are unconvinced that it's worth them developing a full solution themselves.

I'd say UMA is a classic case here. Even though it's now been adopted by 3GPP as a standard, it's notable that its prime advocate, Kineto Wireless, has had to develop a large handset client arm to help foster development of UMA chipsets & phones. I can't believe it's actually making much money out of this - it's actually a "means to an end" to help it sell its networking hardware. No infrastructure company really wants to get their hands dirty with porting to 101 varieties of handset silicon, and the onerous & expensive development and testing work that entails, for a measly 50c or $1 per handset and some low-margin consulting fees. They'd much rather sell $100k or $1m lumps of tin & software.

Another example is IPWireless. Nobody seems particularly interested in making UMTS-TDD phones at the moment, so it has to try & stimulate demand itself, with its own reference design and a prototype developed with Atmel and UTStarcom.

Thought for the day: Has anyone noticed that it seems to be mostly IMS Infrastructure vendors that are developing their own IMS handset clients (eg Ericsson) , licencing them (Lucent, NEC), or acquiring them (NMS / Openera)? Now what might that tell us about IMS standards, interoperability, timelines, user experience and cross-platform portability? Stay tuned, I'll have more to say on this in coming weeks......