Denial is not a river in Russia, but VoLGA is

IMS has made some headway in network infrastructures in part because, if you have an all-IP network, as with cable or WiMAX, for example, IMS provides specs for two key parts of the network architecture:

• A secure carrier-grade signaling architecture based on SIP, an existing, widely used technology

• Interconnection and inter-operation with the worldwide telephone network.

Neither IMS's Vogon ambitions to make charge-able events out of Web site visits, nor the potentially creative aspects of SIP signaling in enabling novel communications features helped IMS. It was purely practical matters that brought implementations of SIP that happened to be IMS capable into the telephone network.

Will IMS therefore win by default?

The answer will emerge from the way LTE (a.k.a. 4G) networks are engineered. LTE is tipped to be the dominant all-IP mobile wireless network technology, and is therefore the big prize for IMS vendors. You can think of LTE (4G) as 3G without the circuit switched telephony. LTE is faster and simpler than 3G.

The question is: Can you build an all-IP LTE network without IMS? Unfortunately for those network infrastructure vendors with a big investment in IMS, the answer appears to be “Yes.”

VoLGA is a spec related to LTE that describes how to do circuit switched voice with an LTE generic access network (GAN), and how to hand off between an LTE VoLGA call and a 3G network and 3G call. By teaching the 3G GAN controller (GANC) node a few things about how VoLGA handsets want to do circuit-switched signaling over IP, and how to set up gateways for VoLGA calls, you do away with the need for a new kind of signaling for IP calls.

That is, VoLGA is a specialized form of IP telephony built to get signaling and payload between an LTE endpoint and a mobile switching center (MSC), which is connected to the conventional telephone network. From that point, the LTE network and the phone calls on it look like a 3G circuit switched mobile network.

VoLGA is, therefore, a dagger at the heart of IMS. A VoLGA handset doesn't need SIP, much less IMS, to make phone calls on an all-IP LTE network. And an LTE network doesn't need to support SIP and IMS to support LTE handsets that support VoLGA.

This is both good and bad:

It's good because it extends the attractive simplicity of LTE: Fewer, simpler nodes make LTE networks cheaper to build and operate and faster to deploy.

It's good because it does not preclude IP communications services in the handset. In fact, it raises the importance of IP in the handset because the network does not take on responsibility for mediating IP communication.

It's bad because it closes the window on operators' ability to create new service products based on IMS capabilities. Cynics might say this is a deservedly unused non-opportunity.

Nevertheless, it does make adding features like, for example, HD voice more challenging in that they will have to be done in the circuit switched signaling domain for LTE voice calls.

For handset makers, VoLGA marks a clear boundary: LTE handsets are mobile Internet nodes, for sure, but they are also endpoints of the conventional PLMN, with 3G signaling. The IP side, with the possible exception of some messaging services, belongs to the Internet. The VoLGA phone calls belong to the telephone network.

Handsets are, therefore, IP communications devices: They are on an IP network, and anything beyond conventional circuit switched calls is going to be IP communication, and it is not going to be mediated by IMS.

Networks will be simpler, leaving more responsibility and opportunity for endpoint devices: Functions depending on multiple IM/VoIM protocols, one-to-many messaging, presence from multiple services, etc. will not have the excuse that “the IMS system will eventually gateway that stuff.” It's up to the endpoint developer to make it happen.

And what do you do if you have already placed a significant bet on IMS? You take the intent of IMS: To make all modes of communication available to the user and inter-operating, and you implement that intent in an endpoint device that takes the new modes of IP communication and makes them first-class citizens of the handset user experience, and does that using not just an IMS service, but using the services the user may want to use on the Internet.

How a Customer's Question Frames the Definition of 'What Does a User Interface Architect Do?'

My title is Chief Architect, and the short description of what I do is that I designed the mCUE user interface and telephony middleware systems.

That's not a very satisfactory description for several reasons:

1. The product named mCUE is difficult to pin down: “Unified communications” and “middleware” are industry terms calculated to form meaning in the eye of the beholder.

2. When people hear “user interface” they think “draws pretty pictures”

3. The term “architect” is also nebulous – what is there to architect in a user interface? It's just presentation.

So, when asked, what can I say about the job I do? Recently, a customer's question brought the description of what I do in focus, and also helped clarify the nature of the product I designed. The question was:

How do you ensure consistency of customer experience from platform to platform?

The question was asked because we showed the customer our product in a very portable implementation that depends only on a reasonable Java VM and a small subset of the Java AWT classes, but they needed our product in an environment that requires use of that platform's UI classes and application framework. Why, in this new implementation, should they expect it to work like what they evaluated and liked?

That question gets right to the heart of what it means to design a mobile user experience, and, indeed, right to the heart of the whole project that I have been working on.

My work here started with discussions I had with D2 Technologies' founder David Wong, who is a pioneer in voice over IP technologies (VoIP) and DSP software, on the proposition that VoIP user interfaces were low-quality compared to mobile user interfaces, and that nobody had really thought about VoIP user interfaces the same way as mobile user interfaces.

That is, nobody had thought of VoIP user interfaces as a really important part of the product. VoIP users were fewer, and had fewer options than mobile users. VoIP users were generally enterprise users, accustomed to ill treatment by user-hostile software. VoIP user interface was immature because the resources applied to it were small, and the stakes in the market were correspondingly small. What if we took it seriously and put more mind-share and resources into it than our competitors? Could we make a breakthrough in VoIP user interface and, perhaps, ride that up the value hierarchy to a place among mobile handset technology providers, especially as they found they needed IMS endpoint technologies?

That is how the project that became the mCUE product started at D2 Technologies. It was about VoIP, but, specifically, about what we hoped would be the logical next step for VoIP endpoints: Instead of desk sets that tried to look like PBX phones, VoIP would logically be moving to mobile handset form factors and use WiFi to connect to VoIP systems.

That VoIP user interface market, however, proved to be too small even for a specialist company like D2: WiFi handsets are, still, a tiny fraction of VoIP endpoint market share, and desk sets are still saddled with crude user interfaces. Nor could we make an immediate jump to providing IMS endpoint technology. Only tier-1 OEMs were active in defining their IMS endpoint architectures, and these were mostly prototype efforts.

Nevertheless, we changed our design goals to aim at the intentions of IMS: To make every mode of communication a first-class citizen in the mobile endpoint. And, beyond that, we realized that IMS is not the be-all/end-all of mobile communication. We also made every service a user might want to use a first-class citizen alongside the mobile network. That is, we made IP communication in all modes and media able to either replace, as in a purely VoIP system, or stand alongside mobile service, without relying on an IMS network implementation to aggregate every conceivable IP communication service.

And that gets to the answer to our customer's question: How do we ensure consistency of customer experience from platform to platform? The answer is: we have to, otherwise we could not implement our goals. We must make a new “world” of communications objects that replaces the call-state management in a conventional mobile handset with a model of communication that encompasses all modes, all services, and all networks. And, if user interaction with this much-expanded communications model is consistent in all implementations, the user experience is consistent, no matter the UI toolkit we use to implement the presentation of the user experience.

So, what does an architect of mobile user interfaces do? He makes a model the user is comfortable manipulating, and presents that model in a consistent way across multiple platforms. This sounds a bit general, but aspects of this task are especially critical in mobile user interfaces: The mobile user interface is inherently a multimedia user interface – it used to be almost entirely presented as audible call progress tones and the billions of users of telephone systems worldwide have a strong expectation that the conventions of a telephony user interface and a mobile user interface will be preserved in an interface that brings in other modes of communication.

The mobile interface itself cannot be pulled in new directions very easily, yet assumptions have to be questioned: What, for example, can be done to enhance the task of starting a conversation? On-hook dialing was invented to keep the user off the precious resources of the mobile network until the last possible moment. Now that always-on data connectivity is inherent in VoIP networks and widely available in mobile networks, the “don't touch resources until you absolutely need to start signaling the network to connect a call” assumption is obsolete.

A mobile user interface designer not only makes the presentation of the user experience, he has to be able to design the model manipulated by the interface, and he has to know about the network, and even the business of operating the network, to make a presentation, a model, and a consistent set of functions that work together. And he has to know it all well enough to know the difference between a rule you have to observe and a rule you have to break in order to innovate.

This seems daunting. It is, at least one of the most interdisciplinary pursuits in software design. It is full of both constraints and opportunities. If you are unaware of the constraints you will make mistakes that make you look amateur. If you are unaware of the opportunities and what it takes to exploit them, you only advance by luck. The reward is that good work in mobile user interface design expands your mind the way few tasks can in the increasingly specialized world of software design.

Does PA Semi make sense now?

About a year has passed since, in 2008, Apple acquired PA Semi, a fabless CPU maker with some success selling a high performance, low power 64-bit PPC CPU in embedded systems, for $289 million.

To put that number in perspective, it is less than half what Intel got for its Xscale product when it sold that to Marvell in order to get out of the ARM CPU business.

Apple immediately withdrew commitment to PA Semi's road map and notified PA Semi's customers they should not consider their supply of chips assured. Apple's investor relations put the acquisition into the category of small-firm acquisitions Apple does not feel obligated to explain in detail. In other words “move along, nothing to see here.”

But, of course, there is plenty to want to see: Sun crippled themselves by keeping a CPU business alive too long. Apple shifted CPUs twice in desktop products, from 68k to PPC and finally accepting that nobody can compete with Intel in the high-stakes game of general-purpose CPUs. So what is this dalliance with CPU designers? Is Apple losing the hard-won focus Jobs fought to restore? Is Apple really going to use three different CPU architectures in its product line?

At the time of the acquisition, Intel's Atom had still not found a market: Too power hungry for mobile handsets. Microsoft's UMPC had flopped. And first attempts at netbooks were not a success. Now, however, both markets and technologies have sorted themselves out, and we can discern if this acquisition makes more sense.

PA Semi is a second act for a serially successful founder, Dan Dobberpuhl. Ex of Digital's Alpha and StrongARM projects and founder of SiByte, which was sold at a handsome price to Broadcom, PA Semi is solidly in the first tier of what is a remarkably vital if not very visible market of CPU vendors based on licensed architectures (and novel ones, too, mainly in the area of multicore systems), mainly sold into embedded systems.

That's an important bit of background because it highlights the fact that Apple did not necessarily buy PA Semi to launch a system with a PPC CPU. Dobberpuhl and his team would be as wizardly at making an ARM, MIPS, or even x86 CPU as they would using the PPC architecture. The likeliest target for Apple is to come up with a variant of the ARM architecture with unique performance advantages.

The market has also evolved: Atom is the basis for the success of netbooks. Apple is locked out of the low-cost netbook market because the price points and margins are even harsher than mainstream PC products. Linux has become slick enough to gain customer acceptance in netbooks. Windows 7 got a bit quicker. Android successfully launched despite lackluster hardware and T-Mobile USA's struggles to get out of the lower tier in the US market. More recently, Android looks likely to go up-market from smartphones into a tablet/netbook form factor.

Everyone is gunning for iPhone, and Web access on-the-go is creating new product categories. Apple needs to be able to create a winning product in the Web-pad/netbook categories, and it looks like the PA Semi acquisition will be part of providing Apple with a truly unique advantage where other players are buying their CPUs from Intel or TI, or from makers of mobile SoCs, like Qualcomm.

This is made plausible by the fact that this low-cost/low-power CPU market cannot be dominated by Intel's unique ability to spend mind-boggling sums on state of the art fabs. The model for this segment has been established and refined by ARM and its biggest licensees, like TI. Apple, therefore, does not risk falling into the same trap that chasing architectural advantage in desktop CPUs led to.

In this case, there is no trap, but an opportunity: There is a seam in the market that runs between Atom performance and ARM power-efficiency. It is a complex seam that isn't just about CPU architecture, but also about compilers, operating systems, peripherals, drivers, user interface and SDKs. And the seam is multidimensional: It is not just between Apple and Atom and Windows 7 on cheap netbooks, but Android and larger-than-smartphone devices as well, and with Linux, in the form of Moblin and Netbook Remix also looking to become a threat.

If Apple can give themselves a unique advantage in hardware, with a uniquely powerful ARM or other CPU architecture, sufficient to overcome the netbook price/margin barrier, Apple is uniquely well-placed to provide a continuum of software, from desktop to smartphone and all points in between. If they fail to do this, Apple will give up the potential to create as much value in the emerging Web-pad and netbook segments as they created with iPhone.