Mobile Virtualization

According to Electronista, ARM’s next generation of chips for phones and tablets should start shipping in devices at the end of this year.

These chips are based on ARM’s big.LITTLE architecture. big.LITTLE chips aren’t just multi-core, they contain cores that are two different implementations of the same instruction set: a Cortex A7 and one or more Cortex A15s. The Cortex A7 has an identical instruction set to the A15, but is slower and more power efficient – ARM says it is the most power-efficient processor it has ever developed. The idea is that phones will get great battery life by mainly running on the slow, power-efficient Cortex A7, and great performance by using the A15 on the hopefully rare occasions when they need its muscle. Rare in this context is relative. Power management on modern phones involves powering up and powering down subsystems in microseconds, so a ‘rarely’ used core could still be activated several times in a single second.

The Cortex A15 and the Cortex A7 are innovative in another way, too: they are the first cores based on the ARMv7-A architecture. This is ARM’s first architecture with hardware support for virtualization.

Even without hardware support, virtualization on handsets has been around for a while; phone OEMs use it to make cheaper smartphones by running Android on the same CPU that runs the cellular baseband stack. ARM says:

Virtualization in the mobile and embedded space can enable hardware to run with less memory and fewer chips, reducing BOM costs and further increasing energy efficiency.

This application, running Android on the same core as the baseband, does not seem to have taken the market by storm. I presume because of performance. Even the advent of hardware support for virtualization may not rescue this application, since mobile chip manufacturers now scale performance by adding cores, and Moore’s law is rendering multicore chips cheap enough to put into mass-market smartphones.

So what about other applications? The ARM piece quoted above goes on to say:

Virtualization also helps to address safety and security challenges, and reduces software development and porting costs by man years.

In 2010 Red Bend Software, a company that specializes in manageability software for mobile phones, bought VirtualLogix, one of the three leading providers of virtualization software for phones (the other two are Trango, bought by VMWare in 2008 and OK Labs.)

In view of Red Bend’s market, it looks as if they acquired VirtualLogix primarily to enable enterprise IT departments to securely manage their employees’ phones. BYOD (Bring Your Own Device) is a nightmare for IT departments; historically they have kept chaos at bay by supporting only a limited number of devices and software setups. But in the era of BYOD employees demand to use a vast and ever-changing variety of devices. Virtualization enables Red Bend to add a standard corporate software load to any phone.

This way, a single phone has a split personality, and the hardware virtualization support keeps the two personalities securely insulated from each other. On the consumer side, the user downloads apps, browses websites and generally engages in risky behavior. But none of this impacts the enterprise side of the phone, which remains secure.

The Post PSTN Telco Cloud

I will be moderating a panel on this topic at ITExpo East 2012 in Miami at 3:00pm on Thursday, February 2nd.

The panelists are Brian Donaghy of Appcore, LLC, Jan Lindén of Google, Hugh Goldstein of Voxbone and Danielle Morrill of Twilio.

The pitch for the panel is:

The FCC has proposed a date of 2018 to sunset the Public Service Telephone Network (PSTN) and move the nation to an all IP network for voice services. This session will explore the emerging trends in the Telco Cloud with case studies. Learn how traditional telephone companies are adapting to compete, and new opportunities for service providers, including leveraging cloud computing and Infrastructure as a Service (IaaS) systems that are being deployed with scalable commodity hardware to deliver voice and video services including IVR, IVVR, conferencing plus Video on Demand and local CDNs.

In related news, a group of industry experts is collaborating on a plan for this transition. The draft can be found here. I volunteered as the editor for one of the chapters, so the current outline roughs out some of my opinions on this topic. This is a collaborative project, so please contact me if you can help to write it.

ITExpo: The Realities of Mobile Videoconferencing

I will be moderating a panel on this topic at ITExpo East 2012 in Miami at 1:00pm on Thursday, February 2nd.

The panelists will be Girish Khavasi of Dialogic, Trent Johnsen of Hookflash, Anatoli Levine of RADVISION and Al Balasco RadiSys. This is a heavy hitting collection of panelists. Come with your toughest questions – you will get useful, authoritative answers.

The pitch for the panel is:

As 4G mobile networks continue to be rolled out and new devices are adopted by end users, mobile video conferencing is becoming an increasingly important component in today’s Unified Communications ecosystem. The ability to deliver enterprise-grade video conferencing including high definition voice, video and data-sharing will be critical for those playing in this space. Mobile video solutions require vendors to consider a number of issues including interoperability with new and traditional communications platforms as well as mobile operating systems, user interfaces that maximize the experience, and the ability to interoperate with carrier networks. This session will explore the business-class mobile video platforms available in the market today as well as highlight some end-user experiences with these technologies.

ITExpo: The Future is Now: Mobile Callers Want Visuals with Voice over the existing network

I will be moderating a panel on this topic at ITExpo East 2012 in Miami at 2:30 pm on Wednesday, February 1st.

The panelists will be Theresa Szczurek of Radish Systems, LLC, Jim Machi of Dialogic, Niv Kagan of Surf Communications Solutions and Bogdan-George Pintea of Damaka.

The concept of visuals with voice is a compelling one, and there are numerous kinds of visual content that you may want to convey. For example, when you do a video call with FaceTime or Skype, you can switch the camera to show what you are looking at if you wish, but you can’t share your screen or photos during a call.

FaceTime, Skype and Google Talk all use the data connection for both the voice and video streams, and the streams travel over the Internet.

A different, non-IP technology for videophone service called 3G-324M, is widely used by carriers in Europe and Asia. It carries the video over the circuit-switched channel, which enables better quality (lower latency) than the data channel. An interesting application of this lets companies put their IVR menus into a visual format, so instead of having to listen through a tedious listing of options that you don’t want, you can instantly select your choice from an on-screen menu. Dialogic makes back-end equipment that makes applications like on-screen IVR possible on 3G-324M networks.

Radish Systems uses a different method to provide a similar visual IVR capability for when your carrier doesn’t support 3G-324M (none of the US carriers do). The Radish application is called Choiceview. When you make a call from your iPhone to a Choiceview-enabled IVR, you dial the call the regular way, then start the Choiceview app on your iPhone. The Choiceview IVR matches the Caller ID on the call with your phone number that you typed into the app setup, and pushes a menu to the appropriate client. So the call goes over the old circuit-switched network, while Choiceview communicates over the data network. Choiceview is strictly a client-server application. A Choiceview server can push any data to a phone, but the phone can’t send data the other way, neither can two phones exchange data via Choiceview.

So this ITExpo session will try to make sense of this mix: multiple technologies, multiple geographies and multiple use cases for visual data exchange during phone calls.

Droid Razr first look.

First impression is very good. The industrial design on this makes the iPhone look clunky. The screen is much bigger, the overall feel reeks of quality, just like the iPhone. The haptic feedback felt slightly odd at first, but I think I will like it when I get used to it.

I was disappointed when the phone failed to detect my 5GHz Wi-Fi network. This is like the iPhone, but the Samsung Galaxy S2 and Galaxy Nexus support 5 Ghz, and I had assumed parity for the Razr.

Oddly, bearing in mind its dual core processor, the Droid Razr sometimes seems sluggish compared to the iPhone 4. But the Android user interface is polished and usable, and it has a significant user interface feature that the iPhone sorely lacks: a universal ‘back’ button. The ‘back’ button, like the ‘undo’ feature in productivity apps, fits with the way people work and learn: try something, and if that doesn’t work, try something else.

The Razr camera is currently unusable for me. The first photo I took had a 4 second shutter lag. On investigation, I found that if you hold the phone still, pointed at a static scene, it takes a couple of seconds to auto-focus. If you wait patiently for this to happen, watching the screen and waiting for the focus to sharpen, then press the shutter button, there is almost no shutter lag. But if you try to ‘point and shoot’ the shutter lag can be agonizingly long – certainly long enough for a kid to dodge out of the frame. This may be fixable in software, and if so, I hope Motorola gets the fix out fast.

While playing with the phone, I found it got warm. Not uncomfortably hot, but warm enough to worry about the battery draining too fast. Investigating this, I found a wonderful power analysis display, showing which parts of the phone are consuming the most power. The display, not surprisingly, was consuming the most – 35%. But the second most, 24%, was being used by ‘Android OS’ and ‘Android System.’ As the battery expired, the phone kindly suggested that it could automatically shut things off for me when the power got low, like social network updates and GPS. It told me that this could double my battery life. Even so, battery life does not seem to be a strength of the Droid Razr. Over a few days, I observed that even when the phone was completely unused, the battery got down to 20% in 14 hours, and the vast majority of the power was spent on ‘Android OS.’

So nice as the Droid Razr is, on balance I still prefer the iPhone.

P.S. I had a nightmare activation experience – I bought the phone at Best Buy and supposedly due to a failure to communicate between the servers at Best Buy and Verizon, the phone didn’t activate on the Verizon network. After 8 hours of non-activation including an hour on the phone with Verizon customer support (30 minutes of which was the two of us waiting for Best Buy to answer their phone), I went to a local Verizon store which speedily activated the phone with a new SIM.

Deciding on the contract, I was re-stunned to rediscover that Verizon charges $20 per month for SMS. I gave this a miss since I can just use Google Voice, which costs $480 less over the life of the contract.

iPhone 4S not iPhone 5

Technically the iPhone 4S doesn’t really pull ahead of the competition: Android-based phones like the Samsung Galaxy S II.

The iPhone 4S even has some worse specifications than the iPhone 4. It is 3 grams heavier and its standby battery life is 30% less. The screen is no larger – it remains smaller than the standard set by the competition. On the other hand the user experience is improved in several ways: the phone is more responsive thanks to a faster processor; it takes better photographs; and Apple has taken yet another whack at the so-far intractable problem of usable voice control. A great benefit to Apple, though not so much to its users, is that the new Qualcomm baseband chip works for all carriers worldwide, so Apple no longer needs different innards for AT&T and Verizon (though Verizon was presumably disappointed that Apple didn’t add a chip for LTE support).

Since its revolutionary debut, the history of the iPhone has been one of evolutionary improvements, and the improvements of the iPhone 4S over the iPhone 4 are in proportion to the improvements in each of the previous generations. The 4S seems to be about consolidation, creating a phone that will work on more networks around the world, and that will remain reliably manufacturable in vast volumes. It’s a risk-averse, revenue-hungry version, as is appropriate for an incumbent leader.

The technical improvements in the iPhone 4S would have been underwhelming if it had been called the iPhone 5, but for a half-generation they are adequate. By mid-2012 several technologies will have ripened sufficiently to make a big jump.

First, Apple will have had time to move their CPU manufacturing to TSMC’s 28 nm process, yielding a major improvement in battery life from the 45 nm process of the current A5, which will be partially negated by the monstrous power of the rumored 4-core A6 design, though the Linley report cautions that it may not be all plain sailing.

Also by mid-2012 Qualcomm may have delivered a world-compatible single-chip baseband that includes LTE (aka ‘real 4G’).

But the 2012 iPhone faces a serious problem. It will continue to suffer a power, weight and thin-ness disadvantage relative to Samsung smartphones until Apple stops using LCD displays. Because they don’t require back-lighting, Super AMOLED display panels are thinner, lighter and consume less power than LCDs. Unfortunately for Apple, Samsung is the leading supplier of AMOLED displays, and Apple’s relationship with Samsung continues to deteriorate. Other LCD alternatives like Qualcomm’s Mirasol are unlikely to be mature enough to rely on by mid-2012. The mid-2012 iPhone will need a larger display, but it looks as though it will continue to be a thick, power hungry LCD.

HTML 5 takes iPhone developer support full circle

Today Rethink Wireless reported that Facebook is moving towards HTML 5 in preference to native apps on phones.

When the iPhone in arrived 2007, this was Steve Jobs’ preferred way to do third party applications:

We have been trying to come up with a solution to expand the capabilities of the iPhone so developers can write great apps for it, but keep the iPhone secure. And we’ve come up with a very. Sweet. Solution. Let me tell you about it. An innovative new way to create applications for mobile devices… it’s all based on the fact that we have the full Safari engine in the iPhone. And so you can write amazing Web 2.0 and AJAX apps that look and behave exactly like apps on the iPhone, and these apps can integrate perfectly with iPhone services. They can make a call, check email, look up a location on Gmaps… don’t worry about distribution, just put ‘em on an internet server. They’re easy to update, just update it on your server. They’re secure, and they run securely sandboxed on the iPhone. And guess what, there’s no SDK you need! You’ve got everything you need if you can write modern web apps…

But the platform and the developer community weren’t ready for it, so Apple was quickly forced to come up with an SDK for native apps, and the app store was born.

So it seems that Apple was four years early on its iPhone developer solution, and that in bowing to public pressure in 2007 to deliver an SDK, it made a ton of money that it otherwise wouldn’t have:

A web service which mirrors or enhances the experience of a downloaded app significantly weakens the control that a platform company like Apple has over its user base. This has already been seen in examples like the Financial Times newspaper’s HTML5 app, which has already outsold its former iOS native app, with no revenue cut going to Apple.

Net neutrality – Holland leads the way

Service providers can offer any product they wish. But consumers have certain expectations when a product is described as ‘Internet Service.’ So net neutrality regulations are similar to truth in advertising rules. The primary expectation that users have of an Internet Service Provider (ISP) is that it will deliver IP datagrams (packets) without snooping inside them and slowing them down, dropping them, or charging more for them based on what they contain.

The analogy with the postal service is obvious, and the expectation is similar. When Holland passed a net neutrality law last week, one of the bill’s co-authors, Labor MP Martijn van Dam, compared Dutch ISP KPN to “a postal worker who delivers a letter, looks to see what’s in it, and then claims he hasn’t read it.” This snooping was apparently what set off the furor that led to the legislation:

“At a presentation to investors in London on May 10, analysts questioned where KPN had obtained the rapid adoption figures for WhatsApp. A midlevel KPN executive explained that the operator had deployed analytical software which uses a technology called deep packet inspection to scrutinize the communication habits of individual users. The disclosure, widely reported in the Dutch news media, set off an uproar that fueled the legislative drive, which in less than two months culminated in lawmakers adopting the Continent’s first net neutrality measures with real teeth. New York Times

Taking the analogy with the postal service a little further: the postal service charges by volume. The ISP industry behaves similarly, with tiered rates depending on bandwidth. Net neutrality advocates don’t object to this.

The postal service also charges by quality of service, like delivery within a certain time, and guaranteed delivery. ISPs don’t offer this service to consumers, though it is one that subscribers would probably pay for if applied voluntarily and transparently. For example, suppose I wish to subscribe to 10 megabits per second of Internet connectivity, I might be willing to pay a premium for a guaranteed minimum delay on UDP packets. The ISP could then add value for me by prioritizing UDP packets over TCP when my bandwidth demand exceeded 10 megabits per second. Is looking at the protocol header snooping inside the packets? Kind of, because the TCP or UDP header is inside the IP packet, but on the other hand, it might be like looking at a piece of mail to see if it is marked Priority or bulk rate.

A subscriber may even be interested in paying an ISP for services based on deep packet inspection. In a recent conversation, an executive at a major wireless carrier likened net neutrality to pollution. I am not sure what he meant by this, but he may have been thinking of spam-like traffic that nobody wants, but that neutrality regulations might force a service provider to carry. I use Gmail as my email service, and I am grateful for the Gmail spam filter, which works quite well. If a service provider were to use deep packet inspection to implement malicious-site blocking (like phishing site blocking or unintentional download blocking) or parental controls, I would consider this a service worth paying for, since the PC-based capabilities in this category are too easily circumvented by inexperienced users.

Notice that all these suggestions are for voluntary services. When a company opts to impose a product on a customer when the customer prefers an alternative one, the customer is justifiably irked.

What provoked KPN to start blocking WhatsApp, was that KPN subscribers were abandoning KPN’s SMS service in favor of WhatsApp. This caused a revenue drop. Similarly, as VoIP services like Skype grow, voice revenues for service providers will drop, and service providers will be motivated to block or impair the performance of those competing services.

The dumb-pipe nature of IP has enabled the explosion of innovation in services and products that we see on the Internet. Unfortunately for the big telcos and cable companies, many of these innovations disrupt their other service offerings. Internet technology enables third parties to compete with legacy cash cows like voice, SMS and TV. The ISP’s rational response is to do whatever is in its power to protect those cash cows. Without network neutrality regulations, the ISPs are duty-bound to their investors to protect the profitability of their other product lines by blocking the competitors on their Internet service, just as KPN did. Net neutrality regulation is designed to prevent such anti-competitive behavior. A neutral net obliges ISPs to allow competition on their access links.

So which is the free-market approach? Allowing network owners to do whatever they want on their networks and block any traffic they don’t like, or ensuring that the Internet is a level playing field where entities with the power to block third parties are prevented from doing so? The former is the free market of commerce, the latter is the free market of ideas. In this case they are in opposition to each other.

Using the Google Chrome Browser

I have some deep seated opinions about user interfaces and usability. It normally only takes me a few seconds to get irritated by a new application or device, since they almost always contravene one or more of my fundamental precepts of usability. So when I see a product that gets it righter than I could have done myself, I have to say it warms my heart.

I just noticed a few minutes ago, using Chrome, that the tabs behave in a better way than on any other browser that I have checked (Safari, Firefox, IE8). If you have a lot of tabs open, and you click on an X to close one of them, the tabs rearrange themselves so that the X of the next tab is right under the mouse, ready to get clicked to close that one too. Then after closing all the tabs that you are no longer interested in, when you click on a remaining one, the tabs rearrange themselves to a right size. This is a very subtle user interface feature. Chrome has another that is a monster, not subtle at all, and so nice that only stubborn sour grapes (or maybe patents) stop the others from emulating it. That is the single input field for URLs and searches. I’m going to talk about how that fits with my ideas about user interface design in just a moment, but first let’s go back to the tab sizing on closing with the mouse.

I like this feature because it took a programmer some effort to get it right, yet it only saves a user a fraction of a second each time it is used, and only some users close tabs with the mouse (I normally use Cmd-W), and only some users open large numbers of tabs simultaneously. So why did the programmer take the trouble? There are at least two good reasons: first, let’s suppose that 100 million people use the Chrome browser, and that they each use the mouse to close 12 tabs a day, and that in 3 of these closings, this feature saved the user from moving the mouse, and the time saved for each of these three mouse movements was a third of a second. The aggregate time saved per day across 100 million users is 100 million seconds. At 2,000 working hours per year, that’s more than 10 work-years saved per day. The altruistic programmer sacrificed an hour or a day or whatever of his valuable time, to give the world far more. But does anybody apart from me notice? As I have remarked before, at some level the answer is yes.

The second reason it was a good idea for the programmer to take this trouble is to do with the nature of usability and choice of products. There is plenty of competition in the browser market, and it is trivial for a user to switch browsers. Usability of a program is an accretion of lots of little ingredients. So in the solution space addressed by a particular application, the potential gradation of usability is very fine-grained, each tiny design decision moving the needle a tiny increment in the direction of greater or lesser usability. But although ease of use of an application is an infinitely variable property, whether a product is actually used or not is effectively a binary property. It is a very unusual consumer (guilty!) who continues to use multiple browsers on a daily basis. Even if you start out that way you will eventually fall into the habit of using just one. For each user of a product, there is a threshold on that infinite gradation of usability, that balances against the benefit of using the product. If the product falls below that effort/benefit threshold it gradually falls into disuse. Above that threshold the user forms the habit of using it regularly. Many years ago I bought a Palm Pilot. For me, that user interface was right on my threshold. It teetered there for several weeks as I tried to get into the habit of depending on it, but after I missed a couple of important appointments because I had neglected to put them into the device, I went back to my trusty pocket Day-Timer. For other people, the Palm Pilot was above their threshold of usability, and they loved it, used it and depended on it. Not all products are so close to the threshold of usability. Some fall way below it. You have never heard of them – or maybe you have: how about the Apple Newton? And some land way above it; before the iPhone nobody browsed the Internet on their phones – the experience was too painful. In one leap the iPhone landed so far above that threshold that it routed the entire industry.
The razor thin line between use and disuse
The point here is that the ‘actual use’ threshold is a a razor-thin line on the smooth scale of usability, so if a product lies close to that line, the tiniest, most subtle change to usability can move it from one side of the line to the other. And in a competitive market where the cost of switching is low, that line isn’t static; the competition is continuously moving the threshold up. This is consistent with “natural selection by variation and survival of the fittest.” So product managers who believe their usability is “good enough,” and that they need to focus on new features to beat the competition are often misplacing their efforts – they may be moving their product further to the right on the diagram above than they are moving it up.

Now let’s go on to Chrome’s single field for URLs and searches. Computer applications address complicated problem spaces. In the diagram below, each circle represents the aggregate complexity of an activity performed with the help of a computer. The horizontal red line represents the division between the complexity handled by the user, and that handled by the computer. In the left circle most of the complexity is dealt with by the user, in the right circle most is dealt with by the computer. For a given problem space, an application will fall somewhere on this line. For searching databases HAL 9000 has the circle almost entirely above this line, SQL is way further down. The classic example of this is the graphical user interface. It is vastly more programming work to create a GUI system like Windows than a command-line system like MS-DOS, and a GUI is correspondingly vastly easier on the user.

Its single field for typing queries and URLs clearly makes Chrome sit higher on this line than the browsers that use two fields. With Chrome the user has less work to do: he just gives the browser an instruction. With the others the user has to both give the instruction and tell the computer what kind of instruction it is. On the other hand, the programmer has to do more work, because he has to write code to determine whether the user is typing a URL or a search. But this is always going to be the case when you make a task of a given complexity easier on the user. In order to relieve the user, the computer has to handle more complexity. That means more work for the programmer. Hard-to-use applications are the result of lazy programmers.

The programming required to implement the single field for URLs and searches is actually trivial. All browsers have code to try to form a URL out of what’s typed into the address field; the programmer just has to assume it’s a search when that code can’t generate a URL. So now, having checked my four browsers, I have to partially eat my words. Both Firefox and IE8, even though they have separate fields for web addresses and searches, do exactly what I just said: address field input that can’t be made into a URL is treated as a search query. Safari, on the other hand, falls into the lazy programmer hall of shame.

This may be a result of a common “ease of use” fallacy: that what is easier for the programmer to conceive is easier for the user to use. The programmer has to imagine the entire solution space, while the user only has to deal with what he comes across. I can imagine a Safari programmer saying “We have to meet user expectations consistently – it will be confusing if the address field behaves in an unexpected way by doing a search when the user was simply mistyping a URL.” The fallacy of this argument is that while the premise is true (“it is confusing to behave in an unexpected way,”) you can safely assume that an error message is always unexpected, so rather than deliver one of those, the kind programmer will look at what is provoking the error message, and try to guess what the user might have been trying to achieve, and deliver that instead.

There are two classes of user mistake here: one is typing into the “wrong” field, the other is mistyping a URL. On all these browsers, if you mistype a URL you get an unwanted result. On Safari it’s an error page, on the others it’s an error page or a search, depending on what you typed. So Safari isn’t better, it just responds differently to your mistake. But if you make the other kind of “mistake,” typing a search into the “wrong” field, Safari gives an error, while the others give you what you actually wanted. So in this respect, they are twice as good, because the computer has gracefully relieved the user of some work by figuring out what they really wanted. But Chrome goes one step further, making it impossible to type into the “wrong” field, because there is only one field. That’s a better design in my opinion, though I’m open to changing my mind: the designers at Firefox and Microsoft may argue that they are giving the best of both worlds, since users accustomed to separate fields for search and addresses might be confused if they can’t find a separate search field.