I want to report a 3G coverage problem - how difficult can it be?

Various emerging business models demand good, reliable, near-ubiquitous mobile data coverage, especially in dense urban areas. We hear a lot about congestion, but rather less about the more basic problems of getting a signal. Whether it's a "not-spot" because of buildings, poor setup of the antennas, inability to site a base station, a recurring equipment fault or just some other RF weirdness, gaps and other coverage-free zones are going to be an increasing problem.

In particular, cloud-based services are going to be very sensitive to the quality of a given operator's network. It's bad enough losing access to the web and email in certain locations - think how much more problematic it would be for critical business processes dependent on hosted applications, used via mobile devices.

Because of this, you'd expect that operators would want to get prompt feedback from their customers about any real-world problems they've missed. Surely in this area of their business, they'd recognise that overall "quality of experience" is best monitored and reported by the end-user, not simply deduced and inferred from boxes & probes and software in the network.

Well, that's certainly not the case for Vodafone UK. Over the last year I've been on its network for my main phone, I've noticed quite a lot of coverage gaps and holes around central London. Sometimes I get bumped down to 2G, sometimes nothing at all. And some of those gaps are in absolutely predictable and consistent physical locations - I've encountered them repeatedly, at different times of day, to the extent that I can even plan my usage around them on certain trips around town. To me, this suggests that congestion and capacity isn't the problem - it's plain and simple coverage.

I've put them on this personalised Google Map - http://goo.gl/maps/hTv3 - both are near Regents Park and Camden in London. One is right in between two of the busiest train stations in the country - Euston  and Kings Cross, right outside the British Library and near the Eurostar terminal at St Pancras.

In the big scheme of things, the two most obvious gaps are not a huge problem for me. Given my typical travel patterns around London, I probably lose 2 mins of mobile data access a week, usually when I'm on a couple of specific bus routes and using my phone for a mix of email, personal apps and so forth. But they contribute to my sense that Vodafone's London network isn't that great - especially as the company hasn't detected and fixed the (very consistent) problems proactively using whatever "service assurance" tools it presumably has at its disposal.

So I decided to report the issue.

I've heard good things about the @vodafoneUK Twitter team, so I thought I'd try that route rather than calling customer service on the phone, especially as I was reporting outdoor locations without knowing the postcodes. The @vodafoneUK team pointed me towards the VFUK online e-forums, rather than (say) giving me a direct phone line or email address to report coverage issues.

Already feeling like this was a lot of work, I nevertheless proceeded to register for the eforum (which needs a different login to other VF services, naturally), read through their harsh instructions to search for pre-existing forum posts that might cover the problem already. Then I had to go to the coverage-checker engine to see if there were any existing problems reported - which meant that I had to use Google to find two appropriate post-codes to enter, as you can't just click on the map.

Both inquries gave the response "Important service information - we're working on correcting a network problem that may affect the performance of your device"

Given that both problems have been ongoing for months, I didn't have too much confidence in this being accurate, so I put this post up on the eforum. Nothing too controversial, just a quick note to tell Voda they've got some issues. I gave a link to this blog so that their support people would know I'm not just an "average user" but have some knowledge of the industry.

The first response almost beggars belief "Now I'm not saying there isn't a problem, but the investigation I've just done points to this at the moment." . Yes, that's right, I spend all day signing up for forums and posting messages about non-existing problems. I've got nothing better to do. And your "open cases" support system is obviously better than a real-world customer with a real-world device, reporting on a real-world problem. Unreal.

Somehow, I remain civil, writing another post pointing out that yes, these issues are still real. And give some hints on how the VF engineers might replicate them if they want to do tests.


The next reply takes the biscuit: "If you can provide 3 examples of these drops  for every area you experience these in then I will definitely raise this case.". Coupled with a request by email (with a spam-tastic "Customer Service" as sender and "No subject") for my information. So if I wanted to "raise a case", I had to send through not just my phone number, but also full name (OK), and also "for security" - two digits of my VF security code (!!! very secure via email), my address (irrelevant to the question and they know this from my number), and my date of birth.


Because "security" is always important when reporting network problems.... perhaps I am some evil-doer wanting to do a "denial of service" attack on their radio engineers' time by submitting fake faults?

Oh and then the email asks for a few more details, copy-and-paste from some stupid template (possibly the wrong one too, voice not data):

• Fault description: (please detail the exact nature of the fault)
• Tests performed (Manual roam SIM in different handset)
• Date issue started:
• Device make an model:
• Results of trying SIM in another handset:
• IMEI number of the handset:
• Postcode of location:
• How far do you have to travel to get signal?
• Address of issue:
• Error tone/wording:
• Numbers effected (Please provide 3 failures, including Number called, date, time and location when call made/received):

As you can understand, I decided that a more profitable use of my time was to write this blog post instead. I'm shaking my head in disbelief about how hard it is to report an important - but simple - problem. Without basic coverage, a whole host of future business models are rendered useless. The idea, for example, of getting media companies or Internet firms to pay for "priority delivery" for 3G data, or some other sort of non-neutral network approach, is totally contingent upon delivering a reliable service.

So just to spice things up a bit more, I've also reported some other holes.... in the road.... to my local council, Westminster. I pay them about the same per month as I pay Vodafone. The road in question is less than a mile from the other sites mentioned. Let's see which one has better processes & more efficient engineering. The Council has a head start, as they have a simple page to report problems, including doing it via street name (not postcode) or "pinpoint on a map". Asks for details, gives a reference number, sends an email acknowledgement. Not a complex customer interface, but about 10x better than a supposedly customer-centric phone company worried about churn.

So - it's definitely easier to report holes in the road, than holes in the air. Let's see if it's quicker to get them fixed too.

Policy and traffic management moves to the edge of the network - the device

One of the hidden trends that I've been watching for a while, in the complex world of mobile broadband traffic management, is now starting to come to the surface: the action is moving down to the device/handset itself.

While a lot of manufacturers of "big iron" boxes like to imagine that the core network or the RAN is all-seeing and all-powerful, the truth is that any discussion of "end-to-end" is only true if it extends out to the user's hand (or ideally, retina or ear-drum). That is where quality of experience (QoE) really manifests itself and where radio decisions (especially about WiFi) are controlled. Anything observed or inferred from within the network about the handset is a second-best simulacrum, if that.

That's not say that the network-side elements are not useful - clearly the policy engines, offload and femto gateways and analytical probes in the RAN have major (even critical) roles to play, as well as the billing/charging functions allowing the setting of caps & tiers - even if I am less convinced by the various optimisation servers sitting behind the GGSN on the way to the Internet.

But most major network equipment vendors avoid getting involved in client software for devices for a number of reasons:

• The standards bodies are generally very poor at specifying on-handset technology beyond the radio and low-level protocols, and even worse at encouraging OEMs to support it. Few network equipment firms are willing to go too far down the proprietary route
• There is a huge variety of device types and configurations, which means that vendors are likely to need to develop multiple complex solutions in parallel - a costly and difficult task. It is also unclear how device-level software can be easily monetised by network vendors, except in the case of integrated end-to-end solutions.
• There are various routes to market for devices, which makes it very difficult to put operator-centric software on more than a fraction of products. In particular, buyers of unlocked devices such as PCs or "vanilla" smartphones are going to be vary wary of installing software seen as controlling and restricting usage, rather than offering extra functionality
• Testing, support, localisation, upgrades and management are all headaches

But despite these difficulties, some vendors are (sometimes grudgingly) starting to change their stance and are dipping their toes into the on-handset realm.

There are various use cases and software types emerging around device "smarts" for assisting in mobile traffic management, for example:

• Offload assistance and WiFi connection management
• Security such as on-device application policy and encryption
• User alerting - or operator feedback - on congestion and realtime network conditions from the handset's point of view
• Quota / data-plan management
• Feedback to the network on device status (eg power level, processor load etc)
• User control of application data traffic
• Low-level connectivity aspects

 I'm maintaining a list of vendors active in these areas (and a few others) as well as my thoughts on who really "gets it", but I'm going to hold off on naming them all on this occasion, as I know many of my esteemed  rivals occasionally drop by this blog.

However, one that I will highlight as being very interesting is Mobidia [not a client], which aims to put control into users' hands, rather than boxes in the network making arbitrary policy decisions. For example, it's one thing for an optimisation server to guess whether the user prefers a "non-stalling" but degraded video - but quite another (and much better) solution, for a software client to let the user participate directly in that decision and trade off quality vs. impact on their monthly data quota, via an app. I was very impressed when speaking to them, especially in comparison with some of the purely network-centric DPI/policy/optimisation vendors I met in Barcelona. I think this type of user involvement in policy will be an important piece of the puzzle.

Management of WiFi connectivity is another area where device-level touch points are important. Although some aspects can be managed from a device management / configuration box in the network - or via standards like 802.11u - that is only ever going to be a partial answer. There will need to be a proper on-device client with a UI, in order to get the experience right in all contexts. (I'll do another post on WiFi offload soon as there's other important issues, especially about the idea of backhauling traffic through the core).

Overall - device-based policy management is difficult, messy, heterogeneous and difficult to monetise. But it is going to be increasingly important, and the most far-sighted network vendors would do well to look to incorporate the "real edge" into their architectures.

2011 events I'm attending or speaking at

This is a quick post to list various conferences or other events I'm expecting to speak at or attend, primarily in H1 2011.

Please let me know if you're interested in meeting at one of these, developing custom material such as research studies or white papers, or indeed you're looking for a speaker or moderator for your own event. Email:  information AT disruptive-analysis DOT com


14th March, London: TEN (Telecom Executive Network) Next Generation Mobile Broadband

30th-31st March, London: Next Generation Core Networks

5th-7th April, Palo Alto: Telco 2.0 New Digital Economics Americas

11th-13th May, London: Telco 2.0 New Digital Economics EMEA

17th-18th May, Amsterdam:  LTE World Summit 

23rd-25th May, London: Managed Services & Network-Sharing

24th-26th May, London: Avren Connected Home Global Summit

14th-16th June, Berlin: Mobile Data Offloading

22nd-23rd June, Singapore (tentative) Telco 2.0 New Digital Economics Asia Pacific

27th-29th June, San Francisco (tentative) eComm Emerging Communications

In H2 2011, I'll probably be at another couple of Telco 2.0 events in Europe & the US, plus at least one of the IIR Broadband Traffic Management series of conferences.

1000th post - a retrospective. What I've got right, and what I've got wrong....

I started this blog about five and a half years ago, in October 2005. At the time, I said that "I specialise in looking for "failures of consensus" - either positive or negative" - and that is still true now.

Having watched various areas of the telecoms and IT industry for almost 20 years, it saddens me that that there is still a tendency towards "groupthink". I genuinely enjoy the speed of technological progress, yet it often amazes me that huge amounts of time and money are wasted going down obvious blind alleys. Too often, nobody stands up and says "No! You're all wrong!" - or just points out that a seemingly good idea will encounter a huge stream of "gotchas" that will derail its progress.

Conversely, there are sometimes new trends and truly disruptive opportunities that remain unexploited.

Flattening the "hype cycle"

We're all familiar with the famous Gartner "hype cycle" about technologies. I'd like to flatten it out, by alerting people to the inevitable "second order" problems well in advance, rather than suffering delays and disappointments because those issues are not pre-empted. They're not all predictable - but many of the most disruptive are, especially if you look at adjacent sectors and parallel trends.

Hype costs money. The whole process of innovation ---> unrealistic expectations ---> disappointment ---> renaissance ---> eventual success is deeply inefficient. It is driven by many understandable human psychological effects, especially around the fear of missing out on something. Yet this same herd-mentality and refusal to assess future problems can be catastrophic - especially if upcoming substitutes are evolving faster. 

I've got a few standard questions I use in my research, to see how clearly ideas have been thought out. For example: "will it work indoors?", "what's the impact on the battery?", or "does that proposition make sense for prepay users?". But sometimes there are bigger issues that are lurking like elephants in the room.

Five years ago, for example, I wrote a research report examining why the notion of using IMS for next-generation operator-controlled mobile services would likely fail, because nobody had worked out what an IMS-capable handset was, or had recognised the scale of the challenges involved in creating one. When the wheels finally started turning a few years later, it was fairly obvious that the RCS variant was also lacking both technically and in terms of user appeal. In the meantime, Facebook has 200m mobile users, while mobile IMS has (essentially) zero.

(Incidentally my most-read, most-circulated post is the one in which I re-wrote the script of the famous Monty Python Dead Parrot sketch as a discussion about IMS and LTE - it's here)


My 2005 predictions and their outcomes

I'm a big fan of looking back at the accuracy of predictions. I reckon I've scored quite a lot of "I told you so's" over the years, although I've called a few things wrongly as well. Going back to my very first post, I said that the following were over-hyped and wouldn't live up to expectation, as at late-2005. Let's see how I fared. (2011 comments in italic)

Overhyped in 2005 #1) UMA (unlicenced mobile access)  - Yes, absolutely spot-on. Never got traction outside T-Mobile US and Orange France. Still trickling on with Kineto's WiFi offload client.

Overhyped in 2005 #2) Cellular operator IM - With a couple of niche exceptions, again absolutely on-the-money. RCS is just the latest version of failure here.


Overhyped in 2005 #3) Near-term massmarket WiMAX - Yes. 'Nuff said

Overhyped in 2005 #4) Free wireless VoIP - Also true. Starting to happen more now (as predicted in my VoIPo3G report in 2007), but has been a distraction not major cannibalisation.

Overhyped in 2005 #5) Dual-mode WLAN/cellular phones - OK, I got this one rather wrong, at least in the mid-term after the iPhone's launch 18 months later. Although that said, globally WiFi is probably present in less than 30% of new shipped handsets because of the sheer volumes of low-end devices.


Overhyped in 2005 #6) Wireless presence - Yes. Still very little use of PC-style presence engines on phones. A bit of Skype, maybe the next rev of Facebook on mobile. RCS failure unsurprising.

Overhyped in 2005 #7) Smartphones - Sort of. In terms of 2005-era definition of smartphones, as just phones with an open OS, I wasn't too far wrong - as the Nokia/Microsoft deal has proven. The *new* definition of smartphones that act as part of an ecosystem had not been invented at that point, and only started to become *really* important from 2008 onwards.
 
Overhyped in 2005 #8) "Seamless" roaming (especially WiFi to cellular) - Correct. We're still talking about it today as if WiFi / 3G (or 3G / LTE) handover is some sort of magical Holy Grail. Classic case of technologists solving the wrong problem, and not realising that "seams" are actually important.


Conversely, at the time I thought some other things were being *under-hyped* and would get more attention from vendors, investors or operators in coming years:

Underhyped in 2005 #1) PBX/cellular integration - Fair. A lot more attention, but still never really got to the stage I'd hoped. Too much futile focus on cellular substitution of PBXs instead, with a variety of pointless and niche hosted "mobile PBX" solutions.

Underhyped in 2005 #2) Poor indoor performance of 3G, WiMAX and other services - Absolutely right. I said in 2005 that nobody paid attention to indoor coverage, especially for data. It was indeed a problem that has since had much more attention...

Underhyped in 2005 #3) Novel in-building wireless coverage solutions - ... especially around innovations such as femtocells, which I was the first analyst to discuss and cover.

Underhyped in 2005 #4) "Single-mode" (non-cellular) VoWLAN phones - OK OK, I was flat out wrong on this. So much for DECT-replacement spurring demand for cheap cordless WLAN phones in-building. Although there *is* a lot of VoIP over WLAN from PCs and now tablets.

Underhyped in 2005 #5) Impact of VoIP on cellular pricing - Difficult to distil out the impact of VoIP vs. impact of regulation vs. market saturation. But there's certainly be a broad decline in per-minute pricing, especially for roaming. I think that VoIP will impact cellular telephony pricing more from now on, as it enables "non-telephony voice" applications to substitute for expensive proper phone calls.


Underhyped in 2005 #6) Upgrading cellular network backhaul - Absolutely right. Easily identifiable as a bottleneck in 2005, even with HSDPA still only just appearing over the horizon.

Underhyped in 2005 #7) Difficulty of integrating & testing new features on mobile handsets - There *still* isn't a proper IMS-capable phone. And Apple proved that good integration/testing was *hard* and expensive if done right. Getting much easier now with Android and Appstores, but 6 years ago nobody (especially network vendors) appreciated how much of a tough problem the little UE box on the end of the chart actually was.

Underhyped in 2005 #8) The impact of a lack of "email portability" on FMC business models - I had to look this one up & remind myself what I was talking about. Essentially I was saying that the stickiness of ISP email addresses would mean a reluctance to switch ISP to one offering an FMC-style voice service. I hadn't accounted for the fact that FMC-style services would be so poor, that few people got to a decision point around email anyway.

Underhyped in 2005 #9) The role of "service enabled" home gateways for FMC - True up to a point. Again, 2005-era voice FMC as espoused by the UMA or SIP voice advocates, never really took off. The home gateways, like email, weren't really the weak points of the proposition - it was the business model. On the other hand, the gateway/STB market has certainly evolved to support some cool services such as IPTV and FON.


More recent "I told you so" and "OK, mea culpa" moments

Looking back at some other predictions from the past 1000 posts, I've got quite a few other things spot-on - but I've also made a couple of howlers as well.

Back in 2006, I noted that operators'  "pipe" revenues from mobile broadband were going to be much more important than other supposed value-added services such as content downloads or mobile TV. Other analysts at the time were advising against open-Internet access, while my view was that it was an inevitable consequence of consumer demand.

Also in 2006, I laughed at the notion of the phone as "mobile wallet" . It still hasn't happened in the last 5 years, and phones still won't replace cash in the next 5 either, no matter how hard some other analysts blow that NFC-enabled trumpet.

On the other hand, I wasn't a believer of the Amazon Kindle in 2007.  It's been moderately successful, especially in more recent versions, so I'll hold my hands up and admit I mis-judged the e-book phenomenon a bit.

More accurate was my prediction about "multiplicity" - that people would have multiple SIMs, multiple devices, multiple service providers and so on. It's a theme I've expanded upon several times and is why I have such as negative view on concepts like "family plans" for mobile. The future is going to get more heterogenous, not consolidated.

Later in 2007, I published a report which suggested that by end-2012, I was expecting to see as many as 250m users of mobile VoIP over 3G/LTE networks. Given that there are now various 3G-capable VoIP clients for Android, Symbian and iPhone - plus heavy use of VoIP among dongle-connected laptop users - and likely more coming in the next 2 years of LTE, I reckon the top-level numbers were prescient. On the other hand, I'd been expecting operators to have developed a workable carrier-grade LTE VoIP solution by now, as long as they had got some "practice" in tuning it on older HSPA networks first. I also suggested they should work with Skype, Fring and others in the meantime, getting experience in real-world mobile VoIP. It hasn't happened, and so one of my predicted scenarios is now happening - Skype, Google and others will take the lead, not the operators. The operator community's over-focus on slow-moving standards like IMS and VoLTE/MMTel allows swifter alternatives to gain a foothold.


In 2008, I pointed out that while embedded-3G notebooks and netbooks seemed to be "elegant", the business model and economics didn't stack up. Users prefer the flexibility of dongles (which can be prepaid as well as contract), PC OEMs don't want to wear the cost of a module which costs a sizeable % of the device gross margin, and retailers would much rather stock a 3-inch stick than a large laptop box in their store-rooms. Today, only a small % of laptops have 3G built-in, and only a small % of those are actually activated ("attach rate").

My predicted timing on femtocell market evolution has been pretty decent as well, despite more bullish forecasts from some of my peers. From early 2008 "Some niche success, but practicalities will mean it's H2'09 or 2010 before massmarket deployment."

One topic where I have to admit defeat is in my effort to get the telecoms industry to abandon the term "Over the top" (OTT) to refer to Internet or other access-independent service providers. I still think it's a stupid and derogatory term for companies that should be considered as respected and equal peers, or potential partners/customers. In my view, this attitude symptomises the problems of the traditional telecoms industry today. It's also utterly hypocritical, given that virtually ever operator is developing its own portfolio of OTT-style services. Meanwhile, there is a larger threat emerging from "under the floor" providers such as wholesale networks or vendor-outsourced infrastructure.


The next 1000 posts

I'm obviously not going to go through every post I've made to date, and it's certainly possible to find more examples of things I've got wrong. But on balance, I'm pretty pleased with the calls I've made - but somewhat saddened that I have not managed to stop some of the more predictable mistakes.

Going forward, I can see other imminent issues with technology and business models. I think that current forms of mobile video optimisation are likely to face severe push-back from regulators, customers, content companies and competitors. There is a huge amount of wishful thinking about "monetising" and "personalising" services based on the network trying to decode application flows and treat them differently. They won't work - the network doesn't and cannot understand applications from a user's perspective, and they are inherently game-able.

The industry still isn't thinking about the big-picture impact of Moore's Law (hints: intelligence moves to the edge, while applications-oriented standards reduce in importance as inter-working boxes improve in capability). There is also too much legacy thinking about links between access and service - operators should be spending more effort on creating their own OTT-style services, and less on vertical integration. There is still a "them and us" stance between traditional operators and new incumbents such as Google and Facebook. They are competitors, yes - but also peers, and equally deserving of customer respect even if they do not own (or pay for) physical networks.

I hope that my next 1000 posts help to flatten out the telecoms hype curve in coming years. I'm intending to continue giving early warning of avoidable problems - and highlight new opportunities that have not been addressed. I will call out bad ideas - or ineffective companies - even if they are my clients. And I'll try and add a dose of humour, irreverence and fresh air. And maybe even another Pythonesque satirical post....


The sales pitch

While I enjoy writing and being opinionated anyway, the main reason I write this blog is to drive consulting & advisory business for my company Disruptive Analysis and its partners. The blog posts illustrate areas of knowledge and expertise, as well as the type of research, critical thinking and challenging stance I employ.

Much of Disruptive Analysis' consulting work involves critiquing business plans & propositions, or helping firms find new addressable markets and business models that fit with their capabilities. Often, I will "stress test" ideas against plenty of possible "gotchas".

Similarly, my published research tends to focus on contrarian themes - there's a ton of larger research houses looking at mainstream and uncontroversial topics and I see little value in adding my own "me too" reports.


If you find this blog interesting & useful, then please get in touch with me. As well as in-depth consulting assignments, I also do more free-form brainstorm workshops and public presentations.

Email information AT disruptive-analysis DOT com

MWC 2011 round-up: Smartphones, Policy/Offload and VoLTE/RCS

I've now had a chance to gather my thoughts about last week's Barcelona Bunfight. I can't say I enjoyed the trip this year (having only grudgingly decided to go right at the last minute), but it was nonetheless productive and informative. That said, it's still got to have been better in Barca, than if it was held in the other 2013-2017 MWC candidate cities of Paris, Munich or Milan.

For me, there were three standout themes:

- Handset OS's and ecosystems, especially the rise of Android, and the Nokia/Microsoft fall-out
- Ongoing discussion about the 3G/4G data traffic "problem", and how to add capacity, manage traffic and hopefully generate new revenue opportunities
- The future of personal communications, especially around VoIP on 3G/4G networks and the evolution of social networks and messaging.

Of course, there was a ton of other stuff going on as well - such as a lot of hype about mobile money / payments, the reality-distortion field around NFC, zillions of identiclone tablets, assorted fluffy apps/content things, and an absolutely bubble-tastic fleet of private jets at BCN airport.

Android gave everyone something to talk about & play with, while conveniently ignoring that the people with money (and especially discretionary technology income) still prefer Apple, while BlackBerry seems to be winning the hearts and minds of the next generation better than either. Nevertheless, the Android zone in Hall 8 was pretty much a full-on party, and maybe free smoothies can start to catalyse a sense of "cool" around the brand over time.

For me, perhaps the most interesting thing about Android isn't the high-end but the opposite. The sheer volume of designs and OEMs involved is driving the inevitable downward pressure on phone prices and margins. We can't be too far away from having a "good enough" smartphone at $100 price points - which then opens the market up to the vast prepay subscriber base. It also makes it harder for the operators to convince users to go for long contracts with subsidised devices - who's going to sell their soul for a 24-month contract (and a possibly locked-down device), just for the benefit of a $100 loan?

I'm not going to re-hash all the arguments about Microsoft / Nokia (apart from anything else, my input is going into something soon to be published by my friends over at Telco 2.0) but it was certainly on everyone's lips throughout the week. Overall, I'm cautiously positive, although the killing of Symbian seems to have been done a bit too abruptly. There's certainly going to be an uncomfortable transition period before any WP7 Nokia devices ramp up to take its place, plus the company seems to have lost an awful lot of developer goodwill. On the other hand, not dashing after the unproven non-Apple tablet space immediately seems very wise. My view is that there's going to be at least a year of disappointments around Android / WebOS / whatever tablets, and Nokia/Microsoft might be better off waiting to pick up the pieces in 2012 after the inevitable short-term bloodbath.

I stopped off to see HP and its new WebOS phones & tablet. Seem to be nicely engineered, although without *quite* the level of UI intuitiveness I might have expected, but I suspect that would change with practice. The larger phone with the QWERTY was quite appealing - the sort of thing I'd consider replacing my iPhone with next time, as it has a hint of individuality about it. In fact, I thought much the same about some of the WP7 devices as well.

(With impeccable timing, my iPhone black-screened and refused to restart, while I was standing at the Microsoft booth. Either the iPhone has a hidden "tantrum" feature triggered by detecting potential disloyalty from its owner, or else the guys from Redmond have special competitor-disruptor rays mounted on their stand).

One of my largest research themes in the last year has been around mobile data traffic management. It was at MWC in 2010 that I realised quite how many silo solutions there were - everyone had an answer to the "data tsunami" generated by dongles and smartphones, but there was no consistent approach to stitching together the various bits. Various flavours of offload, optimisation, policy, charging, connection managers, protocol tweaks and assorted other were around, but there was a lack of any "holistic" approach to blending these intelligently. I published a research note on this theme last May.

Since then, I've been continuing to see the evolution of the space, which has been fuelled by many operators' short-term needs for a "quick fix" to their data problems, coupled with some longer-term strategic thinking. I've been pretty vociferous about the claims of video optimisation as "the answer", in particular where it's done way back in the network without any decent awareness of the radio. I also have a lot of doubts about so-called "application-based policy", whereby operators can supposedly create "personalised" mobile data plans which include/exclude/prioritise specific traffic types or web destinations.

This trip to Barcelona enabled me to catch up with some of the latest developments around sub-topics such as offload and connection-manager software on devices, which I see as more strategic for overall traffic management than core-network heavy machinery. I was also struck by the fact that the largest believers in the "holistic" approach are actually the largest traditional network vendors, not some of the startups.

Ericsson's deal with Akamai looks truly important here, as in theory it should be able to combine video optimisation / caching with the ability to tweak policy right the way down to the scheduling algorithms in the base stations. All the boxes sitting in the core network or out on the Gi interface have a critical flaw - they neither understand the radio domain very well (eg is the user temporarily out of coverage, rather than in a congested area?), or else aren't in a position to "enforce" anything sufficiently granular to deal with the problem. Alcatel-Lucent is also tying various bits of its policy and content portfolio together - it bought CDN vendor Velocix last year, and also has some probe/DPI cleverness in the RAN.

More importantly, getting a firm like Akamai involved in video optimisation and policy is important, because unlike the operators, content publishers actually trust a CDN not to mangle or degrade video content without permission. Unnecessary transcoding or compression of video, without the awareness or permission of the producer, is extremely unpopular. While "in extremis" it may be necessary in times of congestion, it would still be better done with the involvement of the originator, not by the operator's network operating autonomously. I'm expecting to see some smarter content companies put notifications in their apps that monitor when telcos are "fiddling about" with their traffic, and inform the user of who is to blame if "artistic integrity" is compromised.

Among the policy & DPI vendors, I was particularly impressed by those that are offload-centric (eg Bridgewater), rather than those that are app-centric (eg Sandvine). I also saw some neat on-device software from the likes of Roke, which also optimises for cost/battery life as well as radio bearer availability.

It's time for an over-generalisation with a large kernel of truth here: network people don't *really* understand applications. They don't understand how users perceive applications, they don't understand how apps evolve and interact, they don't understand the limitations of their own boxes, and they don't understand the difference between an application and a traffic flow.

It's not their fault, to be honest - it's more the paucity of the English language for helping us distinguish between different grades of "things that run on top of platforms". Everything is an "application", from the silicon to the ecosystem as a whole. The mobile industry now has a layer-cake of different platform tiers and applications, and it's not the network vendors' fault that the app-stratum they can watch isn't as useful as the semantics would have them believe.

I lost count of the number of people suggesting that operators could have tiered services, say with one mobile broadband package optimised for "social networking". The descriptions of a theoretical "Facebook data plan" I heard from a few just don't stack up. For example, none of them had a good answer for me when asked what they'd be able to do now that Facebook forces its sites to encrypted SSL. Nor did they have a good answer about whether zero-rating Facebook traffic would include web links shared by friends, which are displayed *inside* the Facebook app on a smartphone. Or what would would happen if the June update of the FB app added something new, like video.


The other theme I was following at the show was the evolution of personal communications, and especially the role of operators and other participants. Various of my clients have been asking me to advise on "the future of voice" and new business models which take account of fully IP-ised networks like LTE. Much of the discussion is around new voice apps and revenue streams, and especially the growing distinction between "voice" in general and "telephony" as merely one specific voice application.

As expected, we heard a fair amount of noise about VoLTE for voice on LTE, as well as the news that T-Mobile was dropping its cherished advocacy of VoLGA. There were also quiet a few companies quietly pitching non-IMS approaches to LTE VoIP, which I think have a strong chance of adoption. I'm extremely skeptical about the suggested timelines I've heard from VoLTE, which seem to be driven by the needs of both PR and the desire to foster consensus through inertia (or at least collectivising the risk of failure). In my view, the likelihood of getting normal handsets into the market, running VoLTE for "primary mobile telephony" with good quality, battery life & mobility, before 2013 is very slim indeed. Yes, even on Verizon. Nevertheless, I do agree that VoLTE will eventually happen, for some operators in some contexts - although it will certainly never be ubiquitous. My post-MWC views are essentially unchanged since the pre-MWC post & lengthy discussion in the comments here.

If VoLTE doesn't deliver, I wouldn't be surprised if VoLGA gets reincarnated at some point - probably with a face-saving rebrand. I'm sure T-Mobile knows this as well. (I tried to come up with an amusing pun for a future DaNUBE or THaMeS acronym for LTE Voice, but I haven't managed it yet - suggestions welcome).

On the messaging and social-network side, MWC included a lot of discussion about integrating incumbent platforms such as Skype and Facebook, as well new telco-centric niche efforts such as the GSMA's RCS-e (a new revised version). My views on RCS have been pretty consistent since its announcement 3 years ago, so it's good to see that finally the GSMA has ditched the focus on presence because it kills the phone battery and floods the network with signalling. I'm still wading through the new specs, but despite the high-profile announcement of future operator support and a few demos, I still think it is too little, too late.

And there's still no involvement from the key players in messaging and social communications such as Facebook, Apple, RIM or Skype - the operators need to stop the ridiculous "them and us" stance and prove their credentials in social communications, interoperating via the web, and gaining viral adoption because users find the services valuable. For RCS to succeed there also need to be a firm commitment to a "freemium" business model, and a route to getting away from the legacy of the "phonebook" - a hundred-year old way of viewing your social affiliations, that is rapidly becoming obsolete. Anyone wanting a full critique of RCS should obtain a copy of my report from the end of last year, available here.

Nokia + Microsoft: is there an effective third silent partner, Qualcomm?

I'm at the Nokia strategy event in London today, listening to Stephen Elop discussing the Microsoft deal & wider issues around the company's strategy for smartphones, mobile phones and "future disruptions".

There's a ton of angles on this, which I've been dropping comments about on Twitter, and which are well covered elsewhere.

But I'm wondering if there's another angle here in the discussion of "the Windows Phone ecosystem". All of the first batch of WP7 devices have been based on Qualcomm hardware and specifically the Snapdragon processor.

Nokia had a long-running legal spat over patents with Qualcomm, which was resolved in mid-2008. Added towards the traditional antipathy of the GSM community towards CDMA, this meant that Nokia firstly never developed Symbian devices for the broader US market, and also missed Qualcomm's increasing competitiveness in creating 3G basebands and application processors. A year ago at MWC, Nokia announced the first Snapdragon-powered phone would ship by end-2010. It didn't happen. The N8 uses a Texas Instruments apps processor, and the rumoured N9 hasn't appeared.

It's also not clear what's happening now to Nokia's deal with Broadcom for 3G chipset supply - or what happens with its future LTE devices.

I suspect that Qualcomm may - explicitly or implicitly - turn out to be a big winner with today's announcement. It certainly seems likely that for Nokia to get its first WP7 phones to market ASAP ("focus on speed"), it will go down the proven route to get devices out as fast as possible.

The interesting thing here is that the big Q could therefore end up as a pivotal player in Apple, Android and WP7/Nokia ecosystems - although in the iPhone it's on the baseband side than the apps processor.

The big questionmark is around the future role of Intel in mobile. It is clearly now being left out in the cold (again), as Meego is effectively being mothballed, at least from Nokia's point of view. It will be interesting to see its next move - partnership with Samsung on Bada, or RIM on QNX, perhaps? An acquisition of a company like MediaTek? Or a wholehearted move to support WP7 and Android however possible?

NFC will be about free "interactions", not monetised transactions

One of the mobile operators' big problems at the moment is their inability (or unwillingness) to deal with Freemium-style business models. The sheer "weight" and complexity of operator infrastructure and bureaucracy makes it ill-suited to managing events that are unbilled and non-monetisable. This is especially true in circumstances where free calls/sessions/events massively outweigh paid ones. It's a problem exacerbated by many vendors selling them boxes or software based on usage tiers.

This is almost certainly going to be a problem for operator appstores. A large % of Apple downloads, and a huge % of Android downloads are for free applications. People wanting clients for Facebook, Twitter or a million advertising- or brand-led apps. The implicit (and irretrievable) costs of managing, uploading, storing and delivering free applications is likely to be a significant part of the business model for Apple, Google and others. It will be interesting to see how telcos cope with this challenge.

This problem is likely to arise again with NFC. I suspect that once Apple and Google and RIM and Nokia expose NFC/contactless APIs to their developer communities, there will be a huge rise in the number of transactions that don't involve any form of payment. Many of these will not need the "secure element", which is the focus of much of the political wrangling around NFC.

If someone walks out of a restaurant, and taps their phone on a theoretical Facebook-branded "Like" terminal on the way out, there isn't really a need for an uber-secure back end system. Same deal if I tap my phone at a gig, to get added to a band's mailing list. Or a million other applications and use cases.

The net result is that an overwhelming % of all NFC connections will probably be non-financial. Not mobile payments. Not mobile ticketing with a pseudo-Oyster. Not peer-to-peer money transfer. They will be inter-actions, not trans-actions. Not only that, but these apps will appear much faster, assuming that readers are affordable and easy to use (more on that in a moment).

I know I've been very skeptical about NFC in the past, but that's because the focus was on payments or convoluted operator-inclusive value chains. Not just simple "tap to do stuff" apps - basically similar to 2D barcode use cases but much simpler and far less geeky. In other words, it finally looks like we'll get offline applications for NFC - something that's been key to virtually every handset innovation in recent years.

All of which makes the operator business model around NFC rather tricky, in terms of justifying any additional subsidy or promotion, or somehow taking a margin. All the complex mobile-money, transportation ticket and government projects are huge systems integration and IT minefields, likely to need $$$ being spent with IBM or Accenture and taking years to implement.

The big question is around readers and how they are connected. For big complex projects (eg integration into retailers' point of sale terminals), telcos may have a role to play. But for the Facebook-style touch-to-like concept I mentioned above, it should be possible to get USB-connected standalone readers hooked into a PC for a few 10's of dollars.

I have a hunch about this. Sooner or later (sooner?) Apple will put not just the NFC chip into phones, it will put the *readers* into next-gen iPads. I've already had an experience in a restaurant where the host came around with an iPad for people to enter their email addresses for the mailing list. Touching the phone could be to a tablet (or a USB-connected reader to a PC) should be a no-brainer, especially if it allows the user to decide whether to provide specific information sets (name, email, phone-number.... or just a Facebook ID or even a pseudonym).

The question will then be how operators manage to regain relevance for their role in NFC transactions (which will come later, if at all), when the first trillion NFC interactions will have bypassed them.

My guess is that Apple and Google will (initially at least), focus on using NFC as just another tool to entrench their developers and extend their ecosystems. Apple isn't especially bothered about really monetising apps - its own profit on the Appstore is peanuts - it just uses it as a way to add utility to its hardware and sell more units. If NFC-capable iPhone 5's and iPad 2/3's help it sell another 50 million units @$300 gross margin a time, it really doesn't need to care about slicing 2% off of the handful of financial transactions it might facilitate. And Google, Facebook or others could subsidise readers for a variety of advertising / marketing purposes.

So what should operators do about this?

One thing is to have some "skin in the game" in terms of interactions as well as transactions. That will mean acting just like all the other developers and exploiting the NFC APIs on all the various handset platforms. Potentially, they could act as an interaction clearing-house, or even adding value through other internal APIs and assets. They should NOT assume that the key identity layer is around the SIM card, but should look to develop OTT-style applications that can be downloaded to any handset running on any operator's network.


I have other thoughts on this as well, but I'll reserve those for other channels and paying clients. This is my own freemium strategy....

New stats from Cisco on mobile data traffic

Cisco's VNI data traffic forecasts are quoted almost ubiquitously by vendors and operators in the industry.

They've just released some new mobile-specific figures and breakdowns - http://bit.ly/aFcWYa . I haven't had a chance to go through everything yet, but some initial highlights that jumped out at me:

• Top 10% of mobile users=60% of data and falling quickly, Top 1%=20%. Now similar to fixed. Panic over - and any vendors still citing scaremongering "data hog" slides at MWC will look rather silly. My view on the reason for this: a year ago, the semi-mythical 10% were almost all PC users with dongles. Now the smartphones have caught up a bit & evened things out.
• Offload is already diverting 31% of smartphone mobile data traffic to WiFi or femtos. Many of the other stats I've seen don't count or cover offload in their discussions of capacity use. Edit: on the other hand, the offload stats are still a bit vague. They don't distinguish between real offload substituting directly for macrocell data, vs. the incremental amount of traffic which would never have been used on the cellular network because of speed/price/coverage (ie elasticity effects).
• By 2015, M2M data will exceed tablet-based traffic, 295 vs 248 PetaBytes/month . That is hugely significant, because a lot of M2M stuff needs different business models, core architectures etc. Edit: my analysis is that because many of the use cases (eg CCTV) will be *upstream*, M2M will have an even more disproportionate impact on the cellular network.
• At end-2010, there were only 14m mobile-only Internet users, but this will grow to 788m in 2015. I've been saying for ages that the true importance of mobile-only was being overstated. I might have to have a closer look at their definitons & methods for forecasts, but nice to have 3rd-party corroboration of the current reality. Edit: looking at the stats, this seems to exclude non-Internet mobile data. It also appears to assume most users have at least *some* fixed web access, eg through schools or cafes.
• Laptops will still account for more than 50% of mobile data traffic in 2015
• Wireless home gateways generate mobile traffic than tablets - and still will in 2015. Edit: that's a fascinating insight, reflecting the importance & challenges of fixed wireless broadband beyond the "sexier" mobility-enabled devices like iPads. I'd be unsurprised if such users are far bigger generators of mobile video traffic, when connected to TVs and STBs.

Unfortunately, no mention in the study of signalling load - it's all about MB/GB of "tonnage".It's also not 100% clear if the figures are inclusive / exclusive of "optimisation" - ie whether it is data volumes actually flowing to & from the user device, or which comes in via the Gi Interface

More to follow when I get a chance

I'm picking a fight with a peer, about VoLTE and IMS

It's quite rare for me to take direct pot-shots at other specific analysts. While I'm often confrontational, I try to avoid ad-hominem attacks, or cast doubts on specific items of work.

I'll make an exception in this case, because I know the analyst quite well & have a lot of respect for his other commentary, as well as our banter on Twitter, via blog comments, or over a beer at various conferences.

I reckon Gabriel Brown (@GabeUK) has called it wrongly on VoLTE and IMS in his latest article. I vehemently disagree - based on discussions with operators, vendors and my own analysis - that IMS platforms are likely to become the main long-term platform for telephony or other applications in mobile operators in the long term. IMS will most likely be used patchily, by some operators, for some purposes, in some places. (Note: I haven't read his full report, which the article is a trailer for, so there may be some more contrarian viewpoints contained in it).

I certainly don't see that VoLTE will be the catalyst to "set the stage for a more fundamental transition to operator-provided real-time, rich-media services" - that is more GSMA-style wishful-thinking, rather than a probable outcome. And I completely dispute his assertion that with VoLTE/IMS "investment won't be sunk into interim measures that close off that route to innovation".

What he doesn't discuss is that VoLTE is mis-named. It's actually more correctly called ToLTE - Telephony over LTE, not a generic voice platform. It isn't designed as a ground-up answer to the question "what should voice communications look like in future?". I wrote a report in 2007 saying that there needed to be a 3GPP standard for "plain old mobile telephone" service for IP-based mobile networks, and that it was urgently required to stave off the fast-improving third party VoIP providers. The belated answer is VoLTE, aka ToLTE. It's now 2011 and the expectation is that the majority of 3GPP operators are unlikely to deploy VoLTE commercially until 2013-2014. Which means it won't gain significant uptake among massmarket users until perhaps 2015-2016.

Don't get me wrong, an agreed solution for ToLTE would have been important in 2007-2008, because it would have been ready at the launch of LTE last year.  It could have been a good defensive move, adding in all the legacy baggage around telephony such as "supplementary services", roaming and assorted requirements for regulation and control. But the problem with defensive strategies is that they have a timing window, after which they're useless. A missile defense scheme needs to destroy rockets in the launch phase, before they break into multiple warheads and re-enter. A football defender needs to tackle someone before they run past towards an open goal.

In many, perhaps most, cases for LTE, it now seems clear that defence will be too late by 2014-2016. For all but the fastest and most value-chain controlling operators or countries, several things will have happened by then:

• A significant proportion of voice application usage will be "non-telephony" by 2015. This is happening already - voice is being embedded in applications and software as a feature, not a service. It might be using a Skype connection as a baby-monitor, or in-game speech between players, or 10,000 other voice use cases. These are not in any sense "phone calls" and are very poor fits with both VoLTE/ToLTE or today's circuit infrastructure.
• A further substantial amount of the VALUE of both telephony and voice applications generally will have migrated to "cloud voice" by 2015, embedded into websites or business processes, especially for high-end users who will be first to LTE. VoLTE is not designed as being developer-friendly or "mashable" as a #1 goal, which would have been fine in 2007 but not in 2011. (I remember being the chair of an IMS conference on the day that Facebook launched its HTTP-based IM chat. So it's slightly ironic that this debate is happening the day Facebook seems to have trialled its "call" function.)
• More regulators will have started to allow portability of mobile numbers to third-party VoIP services, and more companies will support it. Google Voice announced it for the US last week. At the moment, mobile number ranges - especially in Europe - are sacrosanct and only available to network owners and their MVNOs. Lets see how long that lasts, and indeed whether numbering retains its psychological importance against other identifiers.
• The stickiness from SMS, which keeps people from moving to VoIP for primary telephony today, may start to be eroded, especially among LTE users who are likely to have smartphones. Facebook and BBM (and maybe Twitter) are starting to attack the SMS messaging citadel and it is naive to assume that it will remain impregnable.
• The voice roaming model will have broken down significantly by 2015. It's already crumbling fast, with regional zero-premium agreements and government intervention. Whilst it's understandable that the operators don't want to hasten its demise, they shouldn't be tying  themselves up in time-consuming knots, in desperate attempts to revive it. That ship hasn't sailed yet, but it's pulling up the gang-plank and if you're honest with yourselves, you'll recognise it.
• The fallacy that the operators "own the social graph" via the handset phonebook will become even more wrong that it is today. As I discuss in my report on IMS/RCS it's a great example of self-delusion that Mark Zuckerberg must be sniggering about on a daily basis.
• There will likely be various dual-radio / dual-SIM phones capable of running simultaneous LTE data and GSM voice, without horrible battery impacts. They will also likely be capable of VoIP over HSPA+ where it is reliable. VoIP over LTE will be a nice-to-have, not a must-have, for these users.
• By 2015, the concept of a link between an operator's access business and its services will have fractured. Many service providers will want VoIP services that can extend outside their own access footprint, without "interoperability" concerns. VoLTE is unsuitable as a basis for operators "own-brand OTT" activities.

Some of the people at operators already know most of this, even though they're trying to ignore the full ramifications. In general, I find that the strategy officers are much more realistic about the challenges than those at the coal-face of the core network - after all, it's not their jobs that are ultimately threatened, so there's less of an incentive to want to BELIEVE in things like IMS as a saviour.

But as well as mine and Gabriel's differences in the vision of voice/telephony - which obviously is subjective and opinion-led - there are some other more hard and concrete issues. He writes " it should be possible to at least match [in VoLTE] the service capability of the existing circuit-switched domain used in 2G and 3G networks."

Capability, yes. But quality? Here, there's an interesting gulf emerging between the "establishment" 3GPP, GSMA and vendors, versus the newcomers such as Skype and Google. The old-school approach to QoS is about packet scheduling, managing latency and delay-sensitive traffic, different classes of service and so on. Get the network to minimise dropped packets, and minimise jitter (variations in latency). The new kids try something different. They assume that there will be problems, and look for work-arounds. Clever buffering techniques, new codecs, packet-loss concealment algorithms, echo-cancellation to deal with weird VoIP side-effects, acoustic wizardry to fool the ear.

IMS and VoLTE is about prevention, while 3rd-party VoIP is about cure.

It's easy to say that "prevention is better than cure", but if it comes years later, is that really true?

Skype acquired Camino, while Google acquired GIPS, specifically to deal with speech processing. The GSMA's IR92 specifications for VoLTE largely ignore this whole area. Speaking to a network vendor yesterday, their view is that the bulk of this responsibility in VoLTE falls to the handset vendors. Yet looking at the Internet companies, my understanding is that their QoE (not QoS) engines involve a complex dance between device and server, watching network quality and adapting in real-time. I don't think VoLTE does that. The application isn't really network- or acoustic-aware. One of IMS's core principles is that applications should be "network agnostic", which is a major point-of-failure for the whole architecture.

Yesterday, I did a conference call over WiFi to personal hotspot, and then via HSPA to the Internet, on to Skype, and finally out to circuit via SkypeOut. It wasn't perfect, but it was perfectly usable. Roll that forward 5 years, and Skype-over-LTE should be better than circuit (HD, built-in ambient noise cancellation and so on). Google Voice over LTE in 2015 will probably feature realtime translation between languages using speech recognition in the cloud. Yes, if the cell is congested there might be some problems with QoS. But I'm willing to bet that the overall QoE will be miles ahead of VoLTE's.

As I've written before, it's pretty clear that 3GPP and GSMA are attempting to use LTE as an excuse to crowbar-in IMS to the operators who've been recalcitrant in adopting it so far. I can use various analogies - it's like Ferrari making a 2-ton boat anchor a mandatory accessory on a new car, or as I put in my most popular-ever blog post, like using LTE as the perch to which to nail the dead parrot of IMS.

In some instances, they may succeed - but perhaps to a bare minimum. For instance, I've recently met an operator who's told me, resignedly, that they might put in a small IMS to handle roaming LTE users. However, he has no intention of offering IMS-based services to his own users.

To be fair to Gabriel, he does sign off the article with a doubt "Can operators reinvent and extend the voice model into billable rich media services? I think it's too early to say". That encapsulates our differences - I also believe that reinventing the voice model is absolutely something that operators need to do. I just think that VoLTE is absolutely the wrong way to approach it. As for "billable rich media services", the answer is maybe - but only if they ditch IMS as a flawed legacy technology and look for other solutions, even if they are proprietary and don't have the false comfort-blanket of interoperablity.

The bottom line is that operators considering investing in VoLTE or IMS need to think twice. What is the actual problem you are attempting to solve, and the business case associated with it? Is it purely a defensive move, and if so is it already too late? Is your "voice" (ie telephony) business as valuable as you think, or is it being inflated by accounting oddities around subsidy repayments and classification of "line access" as voice revenue?

Do you really understand what the difference is between Telephony, and Voice as a whole? Is the old-style telephony service worth replicating in LTE at all - will it be monetisable in 2015 and beyond? Will VoLTE actually deliver good-quality speech when acoustic factors are involved too? Are there ever going to be any IMS mobile services that actually add value and provide a good user experience? Or should LTE be used to introduce a proper vision of "services", "cloud" and "voice", with low-margin legacy phone calls kept for the 2G circuit networks that will be here for another 20 years anyway?

For more detailed analysis and advice on these matters, please contact me at information AT disruptive-analysis DOT com.

Paradoxes in the notion of mobile billing replacing cash or credit cards

I continue to read supposedly-visionary pieces proclaiming the imminent death of either cash or credit cards, proclaiming that mobile operators will run the banks into the ground. As this wise sage points out, "Banks and credit card companies of the world, be very afraid. The operators will come to take your business away".

Apparently, we'll all be waving NFC-enabled phones at retailers' readers or transport systems' ticket barriers, and can kiss good-bye to the mess of credit and store cards lurking in our wallets.

In fact, we can forget about wallets too - the leather industry is destined for an implosion of catastrophic proportions. The coin industry is, similarly, quaking in its boots, seemingly scared of the "truth" as peddled by the all-knowing T Ahonen and others.

We have, of course, all the reference sites we need, with Safaricom's impressive M-Pesa mobile money platform, and NTT DoCoMo's Felica NFC-style functionality. And of course, the rumours suggest that the iPhone 5 will be NFC-enabled.

So this must all be true.

But just for the sake of argument, and being disruptive, let's have a look at some contrarian observations:

• 70%+ of the world's mobile subscribers, and essentially all those who are "unbanked", rely on prepay. The most typical way to top up prepay accounts is with scratch-cards or vouchers. Which are usually paid for with cash.
• There's also quite a lot of prepay credit that's bought with the help of bank cards, at an ATM machine. Probably more, in fact, than we're seeing bank card payments substituted by phone payments.
• The average mobile prepaid credit balance is something like $5 (much lower in developing countries) and is frequently zero. Not idea for doing your shopping, or even buying a coffee.
• Even some of the most enthusiastic NFC-promoting operators don't believe in the idea that customers will charge purchases to their phone bill or prepay accounts. They're providing hooks so that they can funnel payments to the user's choice of credit-card account, Paypal or another source of funds. Few customers want a fridge or airfare appearing on their bills at the end of the month. I had a recent conversation with a senior exec in one of the most NFC-friendly operators, and his view is that the bill is fine for small digital goods, but not major purchases
• Governments rather like cash and seem unlikely to want to permit or encourage its death. It's a bit difficult to do quantitative easing via mobile phone.
• In the SafariCom example, M-Pesa accounts are distinct from the mobile phone airtime account. It's basically a bank with a mobile-phone front end. Which makes a lot of sense, especially for the "unbanked" who would otherwise have cash stuffed under the bed & would be unable to make payments. But it's not the mainstream view of a "mobile wallet" substituting for cards or cash in developed economies.
• There are no "payment portability" or "mobile banking portability" laws yet. Given that most (all?) operator mobile payments linked to an access account, users unlikely to lock themselves in & embrace huge switching costs when they want to churn phone provider. Obviously operators want to reduce churn, but assuming your customers are gullible and stupid is not a longterm winning strategy. Loyalty isn't the same as lock-in.
• DoCoMo has spent rather a lot of money to get its payment solution accepted - including a near-$1bn investment in Sumitomo Mitsui Card in 2005 and the purchase of a stake in Lawson's convenience store chain. I don't see many other telcos stepping up to the plate with that sort of cash or serious intent.
• Central banking stats generally show "currency in circulation" continuing to rise, despite the presence of many alternative large and successful payment mechanisms such as debit cards. The chances that mobile payments will make a dent? Almost zero.

Taken as a whole, my view is that mobile payments have a very important role to play in markets like Kenya, where there are significant numbers "unbanked", big problems in distributing money such as salaries (eg Afghanistan) or Japan where a combination of culture (eg trusting the telcos) and heavy investment by the likes of DoCoMo can make a big impact.

I can also see some payments being facilitated by mobile phones (and in some cases operators) and being directed to existing channels such as cards, bank accounts, Paypal or iTunes.

But this clamour that "cash is dead", "the wallet is dead" or "credit cards are toast" is complete nonsense, now and for the forseeable future. I'd be more willing to believe that retina-scans, DNA authentication, telepathy or a William Gibson style direct neural interface for payments will happen first.

Is mobile video traffic quite the threat that everyone thinks? Is the so-called "optimisation" approach flawed?

I smell the "Tyranny of Consensus", about mobile video data traffic.

This is a long blog post examining the "optimisation" of video for mobile. It forms part of Disruptive Analysis' ongoing research into policy & traffic management. For more details on custom work, please contact Dean Bubley directly.

Recently I’ve been bombarded with vendor announcements of video optimisation solutions, DPI and charging products, and lots of slides suggesting that operators might try to charge extra for mobile video traffic that is "swamping" 3G and 4G networks. Everyone is gearing up for "personalisation", tiered services and so forth – and even trying to talk up the prospect of video-optimised data plans. Everyone's putting out PR-driven surveys with predictably trite answers to loaded questions, usually ignoring cause-and-effect.

Normally when there's this level of consistency in stance, it's wrong. Or it's hiding something.

Most of the noise is coming from vendors of traffic management solutions sitting in the GGSN or in a box on the Gi interface – the link between the operator’s core and the Internet itself. Typically, these compress, transcode, buffer, block or generally fiddle-about with video traffic, with varying levels of sophistication and subtlety. Vendors in this general area here include Acision, ByteMobile, Cisco, Flash Networks, Mobixell, OpenWave, Vantrix and assorted others.

Some of them try to second-guess what’s going on in the radio by looking at throughput rates and other indirect indicators and only act when there's a perceived problem. Some can do relatively benign "lossless" compression which doesn't actually change the content. Some try to limit the amount of video that gets downloaded to the player's buffer, in case the user abandons viewing, closes the session and "wastes" the data already transmitted. Some control the numbers of parallel (concurrent) IP connections the device can use.

Conspicuously, the more radio-centric vendors have been comparatively quiet about video – although it’s possible they’re just looking forward to selling upgrades to LTE, rather than reducing traffic.

What's the problem?

So, is mobile video (a) really the problem that everyone suggests, and (b) if it is a problem, are they going about fixing it in the right way?

Obviously, it needs to be acknowledged that there's a ton of published information (and obviously more in private) that talks about the % of traffic volumes attributable to "video". So we know from Bytemobile, for example, that >40% of total global mobile data traffic in 2010 was video - at least from the networks they can measure. But then there's a bit of a "so what" there - as other analysis points out that usually only a few cells in a mobile network are actually congested, and we also know that there are plenty of other weak spots beyond data volume, such as RNC signalling storms, that cause congestion.

(The actual definition of video is that's something that's rarely or poorly defined itself. Is near-photorealistic cloud gaming video? Augmented reality overlays? A flash animation of a cartoon? Discuss)


It's about User Experience. Really?

So should we take at face value the claims of the video-optimisers that it's really about "enhancing user experience" as many people claim? (Everyone hates stalling video streams, don't they?). Or is it more about manufacturing a convenient bogeyman: an excuse to sell boxes to help operators "personalise" their mobile broadband or raise prices?

Video "consumes" lots of bits, so it must be evil, right? Never mind that in most of the world, mobile data is now priced by MB / GB tiers and quotas, so surely 3GB of email is just as evil as 3GB of video? Or more, given the greater signalling load. And doesn't the act of compressing traffic *unnecessarily* reduce the chance of upselling the user to a larger quota? Surely, when there's no real cost impact or congestion risk, doesn't it make sense to let users download as much as they want? Let the user, or app/content provider take the responsibility for reducing volumes if needed.

And never mind that the majority of mobile video still goes to PCs with USB modems, not tablets or smartphones, especially outside the US. Modems that have generally been sold by operators as alternatives or complements to fixed broadband, so it should be neither surprising nor a cause for action when customers use them for that purpose. (Although it’s interesting that T-Mobile UK has recently suggested that you should save your video usage for your proper network at home). It's desktop versions of YouTube or iPlayer, using Flash or HTTP, that are generating the tonnage - typically indoors. And people are tolerant of delays & buffering on PCs, and also know how to use the toggle for 360/480p or SD/HD.

In other words, a sizeable proportion of mobile video traffic is solely generated by operators' mis-selling and mis-pricing of PC dongles as real alternatives to ADSL and cable broadband.

Now obviously here there is a major issue: *when* a given cell or sector is actually congested, or a backhaul link, then one incremental video causes much more of a problem than an extra email. But all the coffee-table stats about "10% of users consuming 90% of the bandwidth" generally fail to state whether they also cause 90% of the problems. It's an anecdote, not a problem statement - especially as most of that 10% are PC users who've been sold a product designed specifically (and knowingly) for high consumption.

There's much less data to suggest that actual congestion is caused by bulky things like video streaming, or just that there are 20,000 people at Kings Cross Station at 9am on a Monday morning checking their email simultaneously. Anecdotally, I've spoken to operators that have agreed that the real busy-hour, busy-cell situation is much more complex than just blaming YouTube.

To give an analogy: I drive my car 4000 miles a year, as I live in central London and mostly use public transport. But I contribute more to road congestion than someone living in the middle of Wales, driving 40,000 miles annually from their cottage to town and back. Data “tonnage”, like mileage, is a lousy predictor of problem causation – yes, there’s probably a positive r-squared, but correlation is weak. But volume is easily measured, and to an uneducated ear it “sounds” fair to penalise volume, especially when prefixed with emotive PR gibberish like “data hogs”.

Forecasts

Everyone's seen the Cisco VNI forecasts for mobile video network traffic... but are they (and others) quite as accurate and meaningful as many seem to think?

I certainly agree that larger screen sizes means that video data will expand for the same duration of viewing. But other mobile applications for smartphones are proliferating too. Yet unless I'm missing something, the biggest growth in usage (minutes / events) is around social networking, gaming and the like. Yes, Facebook friends can embed or link to a video clip... but doesn't the growing amount of time spent messaging and communicating reduce the number of "snacking" opportunities to watch video? If you have 3 minutes waiting for a bus, do you watch YouTube on your phone, or message your friends or send a cleverly-crafted tweet or status update? 

I'm also not convinced that there's going to be a perpetual growth in minutes of video delivered over cellular macro networks to mobile devices *in congested cells*. There's too going to be many ways to offload and cache the content (eg podcasts, or connecting via WiFi or femtocells). Many of the places where people watch video or use 2-way video applications will be those with WiFi available. Those home with both fixed and mobile broadband will also increasingly use femtocells. Both almost completely eliminate congestion - especially if they route traffic promptly to the Internet rather than piping it back through the core. In any case, video will need to be treated differently by charging, optimisation and policy servers if it is delivered by a dedicated indoor solution. All such elements need to be made femto-aware to be useful.

So is the overall "problem" of macro-cellular mobile video going to get worse? Or is it manageable just with normal capacity upgrades and tiered pricing rather than complex control infrastructure, and questionable "optimisation" practices that are perhaps not optimal for user, content owner or operator?

Why optimise in the network anyway?

It's also worth noting that two of the most widely-used and successful mobile applications actually monetised by operators - BlackBerry's email service and Opera's Mini web browsing proxy-based service - are both self-optimised and data-compressed. The special magic is in RIM's or Opera's own servers and clients, not in the operator network in between. So why should video be any different? YouTube, the BBC and others are much more mindful of their users' quality of experience when watching their content than the operators.

The only way to measure real QoE is directly from the device or software client. Trying to decode "user experience" from the Gi interface is like a doctor diagnosing an illness by looking at how red your nose is, through a telescope from a mile away. Maybe the throughput has dropped because the user went to the basement for 30secs? Maybe a window was minimised? Maybe another app on a multitasking device squeezed out the video client with a big download? Maybe there's an OS glitch, or some other user intervention? The network does not - and cannot - know this.

There has even been some talk of network boxes checking that the video size doesn't exceed the phone's screen resolution, and reducing it to fit. This is astonishingly arrogant and apt to create huge user dissatisfaction (and perhaps lawsuits), as it ignores the possibility of the user zooming-in to part of the video, saving it to memory for later use, outputting via the TV port on some phones, or just using the device as a tether or modem.

Yes, some network elements can, in some instances, improve experience, some of the time. But it's inconsistent and unprovable, and may well have hidden side effects elsewhere. But it's like a spark-plug manufacturer claiming it can improve your driving experience with a new type of "optimising" plug. Yes, sometimes it could make the engine smoother and the driver experience better. But it's not much help if the tyres are bald - and it might also mess up the fine calibration and actions of the engine-management chip.

The gating factor is the radio network

The other elephant in the room is radio *coverage*, not capacity. Many 3G networks are still like Swiss cheese, with "not-spots" still common, especially indoors. The woolly survey questions about video user experience generally don't ask respondents if they live in a basement, or a building with metallised windows. Much of the problem is nothing to do with congestion - it's the pesky nature of radio link budgets. You can’t “optimise” video through brickwork.

Not only that, but the risible notion of offering "premium video" mobile data plans with so-called silver/gold/platinum service tiers generally overlooks the realities of physics, and the inter-dependence of shared media. Who’s going to extra pay for “priority” video when often you can’t get 3G at all? I’m writing this on a train – where I might actually want to watch video on my PC via mobile – and I’m lucky if I can get GPRS connection most of the time. I might pay extra for national roaming onto a competing network which can actually supply me with connectivity - but I'd rather just churn outright.

  

And what happens when a platinum user is right at the edge of the cell & wants a video? Do you boot off 70 gold-tier users who've got better radio conditions in the middle of the cell, just to serve them? In fact, even doing this potentially raises issues with consumer protection laws - the only way that HSPA can even theoretically get to 7.2 / 14.4 / 21 Mbit/s is by biasing traffic towards those people who've got the best signal. If you change the algorithm, it potentially makes the advertising claims false.

In conclusion

Overall, Disruptive Analysis believes that there is a good chance that the fears about mobile video traffic are being overstated, and being used as a smoke-screen to permit arbitrary degradation of video content, by unsophisticated boxes placed in the wrong part of the network, ill-equipped to understand the real causes of congestion and poor end user-experience. 

Regulators should scrutinise very carefully whether covert transcoding of video on uncongested links contravenes new views on Net Neutrality that permit only necessary and proportionate management. They should also enforce requirements on transparency stringently – a subtle “we reserve the right to manage traffic” in the terms & conditions is insufficient: there should be detailed and possibly realtime information on any active management / compression of traffic.

Content providers and aggregators should track whether their output is being modified over cellular networks without their permission or awareness, and should consider using encryption to protect against covert manipulation. The should embed agents in the browser or client app to detect unwanted “optimisation” (perhaps through digital watermarks or steganography) and alert the user when the operator is modifying the content in the background.

Operators should aim to work with content providers to enable them to optimise their content in the best fashion – either via rate-adaptive codecs, user alerts about congestion, altering frame rates, editing the video or other mechanisms. Some form of congestion API (ideally real-time but initially less-accurate) will help immensely. They should also pressure all of their core network and so-called "optimisation" vendors to adopt strong measures for radio-awareness and device/user-awareness.

Despite the hype about charging upstream content providers for "premium" QoS, operators should recognise that this will remain a pipe dream owing to the complexities of radio. If it works, it'll happen first in fixed networks, not mobile, where there's much more control and predictability. There's certainly no chance that a video provider, or user, will pay extra for so-called QoS if the network still has poor coverage

For those operators looking at offload, they should reject any policy management or optimisation solution which cannot distinguish between macro and femtocell traffic, or which cannot "optimise" by helping the user to connect to faster/less-congested WiFi if available. They should also be extremely sceptical of so-called personalisation services, pricing different traffic types (not “services”) differently, that look good on paper, but which are completely impractical and don’t reflect the reality of applications and the web, such as mashups.

Remember, video is not “an application”, it’s 10,000 applications, each of which needs individual consideration if personalisation is to be applied usefully. Unless there's someone with the skill and authority to think about this sensibly, there's a huge risk of failures and hidden gotchas.

Overall, I'm increasingly moving to the view that GGSN/Gi-based solutions for video traffic management are OK for urgent firefighting, but need to be very well-integrated with both RAN probes and, crucially, device-side intelligence to have longevity of usefulness. Most of the network vendors (understandably) shy away from working directly with handset OS's, connection managers and other tools - this will need to change.

Disruptive Analysis is one of the leading analysts covering mobile broadband business models, policy management and next-generation "holistic" models for controlling traffic and user experience. Please contact information AT disruptive-analysis DOT com for information about workshops and custom research projects.

Why developers need to take responsibility and create more network-aware applications

In all the brouhaha about traffic management and Net Neutrality, it is startling that one aspect is often completely overlooked - the need for mobile application developers to become much more network-aware, and write their software to take account of the realities of the user's situation.

This is not, primarily, about saving money for the network operators. It is about creating a better all-round experience for the applications' users, whether that is through improved or more consistent performance, less impact on device battery life, easier monitoring and feedback, or saving users time and money.

Ideally, applications should be aware of a broad plethora of network-related variables, and be able to act on them accordingly. An incomplete list includes:

- Real-world end-to-end speed, latency and jitter, for both uplink and down
- Bearer type - WiFi (and SSID and security method), 3G, 2G etc - or combinations of the above
- Which bearers are potentially available, but not being used
- Whether the cellular connection is routed via a macro- or femtocell
- Roaming status
- Variations in network quality, either predicted or real-time measured
- Price plan details - eg per-MB billing, time- or location-variable, proximity of thresholds & caps
- Probable future connection status - eg likelihood of going out of coverage, or switching to another network
- Awareness of current or likely future congestion on the network
- Mechanisms used for offload
- Policies applied by the network, and how these vary by time or bearer
- What types of signalling the application is likely to generate, directly or indirectly
- Handset capabilities & status (eg ability to use multiple radios, battery level, whether WiFi or 3G or roaming are switched on, potential for side-loading via Flash memory or Bluetooth and so on)
- Whether the phone is being used as a tether, or could use another device as a tether / peer

In reality, no application is going to be able to deal with all of these, or pick a comprehensive decision-tree route to decide on how to behave. Instead, there is likely to be a sub-set chosen - based on the nature of the application, the availability of the various input data, and the preferences of the user. A certain proportion of these "network-aware" elements will also be the responsibility of the OS, which might dictate either universal rules ("no updates while roaming") or might bundle some up into a general "network status API" or "bearer-awareness recommendations" accessible by all apps.

Some apps already make use of this type of data, at least in part and on some platforms. VoIP and streaming-video applications are typically the most bearer-sensitive, able to choose different codecs or frame rates based on observed network performance.

But we are still at very early days, especially with regard to the ability of apps to understand or predict mobile broadband congestion, offload dynamics, or cell-edge drop-off effects.

There are three main sources of this data:

- Direct measurement and input by the app itself. For example, Skype clients can measure latency and packet-loss directly.
- From the handset OS, which may expose some of this data centrally - eg WiFi vs. 3G connections, or perhaps in future the aggregate cellular data consumption vs. a user-defined monthly cap.
- From an operator API - perhaps roaming status, or ideally information on the user's data plan. Ultimately, operators will expose "congestion APIs" to applications and devices, although this is still a future-looking concept.

There may also be data that can be gathered from other sources, such as utility applications in the handset or in the cloud, or via direct provision from network elements in the data path.

There is likely to be a considerable amount of push-back from parts of the developer community towards this concept. This stuff is complex, perhaps boring, and will add time and risk to the development process. Some will undoubtedly say "It's not my problem" and attempt to abdicate their part of the decision-making. Nevertheless, mobile application (and mobile web) developers need to take responsibility for their creations' actions and performance.

There are far more variables - and variability - involved in wireless connectivity than is the case on fixed broadband, or a company LAN. On an ADSL line, you're not at risk of suddenly "going out of coverage". On a local gigabit ethernet connection in an office, you don't have to conisder the impact of roaming or the benefits/drawbacks of switching to an alternative connection. Using normal home WiFi you don't have to think about signalling loads.

Mobile *is* different and is much less predictable, and that should be reflected in application design where connectivity is required.

Disruptive Analysis believes that it is incumbent open both device and OS vendors to educate their developer base on the importance of "network-awareness", to a much greater degree than in the past. It may even need some sort of app certification as "network-friendly" to identify which software acts as a good mobile citizen.

Operators also have a role to play - firstly by exposing the right information via APIs or other mechanisms, and secondly by being honest and communicating the limitations of their infrastructure. Whether they are ever going to be able to charge extra for this information is unclear, but it is certainly in their own self-interest to enable network-friendly applications. That said, they also need to be wary of providing tools to those trying to "game the system".

Overall, the next few years will continue to see grudging moves to more network-aware applications, and more application-aware networks that aim to actively help applications rather than just use DPI or PCC to arbitrarily enforce blind network policies.

In fact, all of this is an absolute prerequisite for the success of future mobile cloud applications. Without this bearer/radio-aware knowledge and the development of network-based feedback loops, cloud services are doomed to niche status.