Speaking Engagements & Private Workshops - Get Dean Bubley to present or chair your event

Looking for a provocative & influential keynote speaker, an experienced moderator/chair, or an effective workshop facilitator?
To discuss Dean Bubley's appearance at a specific event, contact information AT disruptive-analysis DOT com

Thursday, June 30, 2011

Something to watch - voice comms and voice apps in the browser

Tomorrow I'll be running the first of the Future of Voice Masterclasses I've been developing with Martin Geddes. We'll cover a broad array of topics around the value, business model and technology of voice communications, especially as we go beyond the basic telephony service we're so familiar with.

I've spent the last couple of days at the wonderful eComm conference in San Francisco, listening to a challenging series of speakers cover everything from telecom regulation to wireless sensors to the psychology of motivation.

One of the presentations that most struck me as surprising was one from Voxeo. It referred to the potential for running voice (specifically VoIP) inside HTML5 browsers and apps, rather than through standalone applications like a Skype client.

This made me wake up, as I've previously been following the whole native-apps/web-apps debate without really being swayed by the web side of the argument. Indeed, I went to a Mobile Monday London event recently which did actually debate the issue formally, with two opposing teams. I asked a question about whether web applications would be suitable for demanding apps like VoIP - and even the web advocates said no, that was out of scope.

The Voxeo presentation covered WebRTC and RTCWeb standards. (RTC=realtime communications). In a nutshell, there's basically a lot of work going on to enhance HTML5 so that it can deal with various codecs and streaming protocols, as well as Javascript APIs to control media - for example with access to the microphone and speaker.

But the really interesting things are that:
- Signalling is all done with web protocols like HTTP and XMPP, not SIP.
- Google has donated a ton of its GIPS code to the project, which does clever acoustic stuff like dealing with echo and packet loss
- Voxeo's platform called Phono.com has a variety of software functions which enable all this capability to bundled into useful formats - such as initiating a call.
- Using something called Phonegap, web developers can create web apps for Apple IOS which incorporate voice connections and calls natively .

So one web page (or browser) could make a voice connection with another server or browser. These are not phone calls. These are additional voice applications, which could theoretically connect to the public phone network, but don't need to. They might be voice-enabled game sites, or social networks, or whatever, where voice just works,

Think about that for a moment. Voice communications becomes a feature of a web page, the same way that tables, or style sheets, or embedded images are. Voice as a feature, not a service.

Now all of this is still some way away from being fully practical for mainstream phones. But over the next few years, it seems likely this going to get built into future browsers as part of the standard of HTML5. In other words, an HTML5-compliant mobile browser in 2013 may *have* to support this, although that may be dependent on whether a given device gives API access to all the relevant bits & pieces like microphone and speaker in the right way, without latency or other glitches.

I'm still trying to get my head around the ramifications of this - but either way, it's deeply, deeply important and potentially represents more of an alternative for LTE Voice than even some OTT apps like Skype. Because this isn't voice as a separate OTT application - it's voice *in* the web itself.

Wednesday, June 22, 2011

Is mobile voice revenue being hugely overstated? And if so, what does that imply for VoLTE?

In our upcoming Masterclasses on "The Future of Voice", Martin Geddes and I introduce the idea of "peak telephony". This is the point at which today's traditional telephony services, fixed or mobile, hit the top of the curve for both revenue and importance, after which price erosion and substitution by alternative applications means decline for normal operator voice.

Various mobile operators have already reported declining voice ARPU - even allowing for distortions from users spreading their spend over multiple SIMs and accounts. This is not just a mature-market problem either - at the Femtocell Summit yesterday, I saw a presentation from a Malaysian operator forecasting an overall drop in mobile voice revenues over the next few years in that market.

In order to stave off the inevitable, we believe that operators need to innovate in both technology and business model, looking beyond "plain old phone calls" to new ways of delivering and monetising voice services and functions.

Mobile operators also have to deal with a second disruption, as LTE networks force a push towards VoIP. They need to absorb the costs of implementation - without a clear path to delivering more revenue to justify that investment. The guest post I wrote on Visionmobile about The Future of Voice reflected that VoLTE is merely "old telephony" reinvented to run on LTE, rather than a platform for enhanced "neo-phone" services that could significantly add value to operator voice business models.

However, all this potentially pales into insignificance compared to a third possible disruption for mobile voice revenues: The Revenge of the Accountants.


In a nutshell, the adoption of new international accounting standards may mean that users' repayment of handset subsidies have to be "unbundled" from the underlying service revenues. This applies most critically to postpaid users, who are given a "free" or heavily-discounted phone at the start of their contract. It is not uncommon for a $600 iPhone to be sold to a user for a headline price of $200, with the other $400 essentially recouped as part of the monthly service fees over two years.

At the moment, the whole of the user's billed payments - let's say $75 a month - is recognised as service revenues, and then sliced up into voice / data / SMS in their financial reports. So maybe $40 is deemed to be voice, $15 is messaging, and $20 is data. The $400 handset subsidy gets buried in the accounts as a cost of sale, or subscriber acquisition cost.

Now I'm not going to pretend to be an accountant or fully understand all the nuances here. I'm sure there are various wizards at some operators who can make the numbers "dance". But if I'm reading things right, the key thing to watch is Draft IAS (Intl. Accounting Standard) 18: Revenue in Relation to Bundled Sales  which forms part of the IFRS (International Financial Reporting Standards) approach to bean-counting.

My original reading was that the subsidy ($400) in this case, was divided up and stripped out of the monthly revenues. So for a 24-month contract, this would mean that $16.67 each month was essentially a loan repayment, meaning that the service component would have been $75-$17 = $58 "real ARPU".

Actually, that's oversimplified. This document from Etisalat gives an accountant's view of IFRS and treatment of handset subsidy, which actually involved the "fair value" of the standalone, SIM-free price of the handset - maybe $700, not $600.

Applying that here, we take the "total consideration" of the contract as $200 (upfront handset payment) plus 24x$75 to yield $2000 overall spend over the lifetime of the contract. That's set against the value of the deliverables as $2500, including the $700 fair-value of the handset. That then translates out to recognising 700/2500*2000 = $560 for the handset purchase, and $1440 for the service, over the life of the contract.

In other words, the allocated amount to operator services should be $60 a month, not $75. Which means that the voice portion is also reduced by 20%, from $40/month to $32. Obviously, the data element is also reduced.

I'm trying to work out where we are in the accounting standards draft / ratification cycle. This document from PWC seems to suggest that the regulations are likely to come in from 2014/2015, with a need to start preparing parallel accounts as early as next year. There are also various national bodies (eg FASB & IASB in the US) that have their own variations, detailed rules and so forth. PWC references the proposal "Revenue from contracts with customers” published in the US in June 2010. To be honest though, the details are beyond the point for this post. The key thing is that real mobile voice revenues (and data as well) are almost unarguably being overstated because of the blurring effect of handset subsidies. Exactly how, when and where the financial reports change doesn't change the fundamentals.

It could well be argued that these changes should be applied retrospectively anyway, so maybe it all just nets out so that the peak of peak telephony was simply lower, but the shape of the curve remained the same. And that's absolutely fair if we look at the past - maybe we just say "Oh, the market was worth $600bn, not $700bn, because we didn't split out the $100bn we spent on handsets" and leave things stand. But going forward, if we are specifically going to look at business cases for new voice-related capex, this all starts to matter much more - especially if we consider the relative business case against keeping voice on circuit-switched networks (2G, 3G) instead of migrating it to VoIP on 4G.

There is also a separate discussion to be had about service bundling and whether we should keep thinking of data services as something added "on top" of a voice and text plan, as many operators do today. Especially with LTE, there is a strong argument to say we should have a general "IP line access" fee, on top of which services - telephony, SMS, Internet access, content etc are layered. So maybe the $75 monthly fee should be allocated as $15 handset, $15 IP access, $24 IP telephony, $9 (IP) SMS and $12 Internet access.

That's a topic for another time, though, although I'd previously written about this type of approach here.

Either way, I think that today's mobile voice revenues are significantly overstated - perhaps by as much as 30-40%. As I said before, I'm not an accountant, but I think it is very important to recognise that some of our cherished data-points, which we're using to make investment decisions, are much more fluid and badly-defined than we might think.

EDIT - Another thought: it will be interesting to see if the accounting treatment of VoLTE (which clearly needs an IP connection and therefore 'data service' in order to work), will be different to that of either circuit-switched fallback or "Velcro-like" dual radio solutions. There is an argument that being able to continue selling separate voice plans on a voice-only network will be much easier for auditors to agree on, rather than the everything-over-IP approach.

One last plug for our Masterclasses on the Future of Voice (which I promise won't have more than a few minutes on accountancy): The first one is next week in Santa Clara, with the second one in London on July 14th. Details are at http://www.futureofcomms.com/ and booking is either via Amiando (linked from that site), or direct from me or Martin. (information AT disruptive-analysis DOT com )

Friday, June 17, 2011

Key takeouts from the Mobile Data Offload conference in Berlin - and why we need to keep some seams


I’ve just spent a couple of days at the first offload-specific conference I’ve come across, organised by IIR. It’s been useful, giving me some good new contacts and allowing me to reconnect with some existing clients and friends. This blog post is just a summary of some of my take-outs and reflections – some people may already have seen some tweets I posted with the #mobileoffload tag.

One thing that seems to be coming through quite strongly is that WiFi offload is currently taking the high ground in comparison to femtocells, especially in the residential marketplace. Conversely, there seems to be growing momentum for outdoor “small cells” of various types compared to WiFi hotzones. 

Neither of these are absolutes, but these fit into a general narrative that:
  • Outdoor coverage and capacity is “classical” mobile network territory in terms of both personnel, planning and operator processes. Consequently, the idea of small cells fits with the notion of “more of the same, but smaller and cheaper and easy to site and manage”.
  • Indoor data offload tends to be driven by consumers’ familiarity with – and often preference for – WiFi. The heaviest mobile data users are almost certainly a subset of those that are happy with the setup and operation of WiFi in their homes. Operators' ability to deal with WiFi's vagaries through device-side software or inbuilt standards is also improving.
The conference focused heavily on this last point - what I'm calling the “telco-isation” of WiFi. There are various standards and specifications being worked on by the WiFi Alliance, Wireless Broadband Alliance, 3GPP, GSMA and others. There’s an alphabet-soup of acronyms here – 802.1x, 802.11u, Hotspot 2.0, ANDSF, I-WLAN, WISPr and plenty of others. There was lots of talk of EAP-SIM authentication and so-called "seamless" mobility. There are various approaches to dealing with the operators' own and partnered WiFi accesses, especially around extensions of the mobile roaming mechanisms.

Some of this is very important and is being done intelligently and effectively. The idea of improved "network discovery" so that you can tell more about a WiFi access than it's SSID name makes a lot of sense. It is also important in some cases for operators to be able to "steer" users to particular APs or SSIDs, and collect information and maybe enforce certain policies. In some cases, SIM-based authentication can make sense as well - an area where my opinion has shifted a bit recently.

But however – and this is a big however – I think there are some serious issues. In my view, the industry is in danger of making the same mistakes it made with UMA about 5 years ago. The giveaway is in this cliched word "seamless". I spent a lot of timing criticising this aspect of UMA, and I can see myself having the same conversations all over again. Seamlessness is not the utopian ideal, just as it wasn't in 2006.

In a nutshell - sometimes, and for some use-cases - automated and seamless (ie zero user-touch) connection to WiFi is absolutely desirable, ideally with session continuity and all that other fine stuff. But, critically there are also various use cases where seams are important, and need to be made visible to the user and/or applications running on the device. The tricky part is designing the end-to-end system, and especially the user interface on the connection manager, to cope with both sets of scenarios.

Seams might be "messy", but they are appropriate for certain contexts. To reiterate the analogy I made in my presentation, we don't all go around wearing Lycra catsuits. Our clothes still have seams for good reasons, and the same is true of networks. Ultimately a seam is a border, at which things change - speed, latency, security, cost, ownership, policy, power consumption and many other parameters. The idea that the border should always be crossed with the user kept unawares risks a whole host of problems.

There are various angles here:
  • The user will often wish to connect to WiFi networks that are not "approved" or linked to the operator's network or WISP partnerships. Most obviously, the user will want to use home broadband WiFi, private enterprise networks (often behind a firewall and with the corporate network's own security and authentication) and free public WiFi where it is available. The operator-driven WiFi software must not get in the way of this type of scenario - and neither should it try to tunnel back via the operator core in these cases.
  • The user may have access to multiple WiFi networks in a given location. The operator-preferred one may not be the best - perhaps because it costs more, perhaps because it is slower, perhaps because policies are enforced that the user would rather were not. Auto-connecting anyway may be an undesirable outcome.
  • The same WiFi network may be available locally on better terms. I'd be annoyed if my phone automatically logged on to a hotel WiFi (at a cost or lower performance), when the conference organiser was giving out free pass-codes. (Not the at the useless Kempinski in Berlin though, obviously - no inclusive delegate WiFi at the offload conference, ironically).
  • Some applications may "come with WiFi" themselves. Skype partners with Boingo, for instance. A presentation by Sky's recently-acquired WiFi network The Cloud suggests that Sky's future video apps and content will be tightly coupled its own WiFi footprint. If I am watching Sky HD movies on my phone in a public place, I'll want to connect to its own optimised connectivity (apparently guaranteeing 1MBit/s per user) rather than someone else's that is heavily contended and which routes traffic through a video-compression box.
More generally, this fits with my concern that the telco-isation of WiFi is starting to look quite Machiavellian and unrealistic. Speaking to people with a view on the evolution of standards, some operators are apparently attempting to own and control WiFi on smartphones outright. While some level of improved control is understandable, we should be wary of the idea that an operator might control the overall WiFi connectivity on a device. 

There are plenty of use-cases for WiFi which are not service-provider centric but "private"- notably enterprise connectivity, or connected-home technologies such as DLNA. If someone sends photos from their phone to their TV or home media server, that is not a "service", but merely data transferred locally over the individual's own network. You wouldn't expect an operator to be involved if you just moved the memory card, which is functionally identical to local WiFi use.

Ultimately, WiFi is a form of Wireless LAN. It's a form of Ethernet. In general, companies that don't understand LANs in general are not the right one to get wireless vesions working properly in particular. Most ethernet use is private, and WLAN is no different.

Some other points from the event:
  • Offloading signalling does not appear to be well-understood yet, but was at least a topic of discussion
  • There wasn't as much talk about on-device client software for offload control/management as I'd expected, a on lthough there were companies such as Roke and Onavo in attendance
  • The session on Net Neutrality was lively, but didn't really touch on offload that much. The AT&T speaker was  very vocal against the hard neutrality laws being mooted in the Netherlands, but conspicuously silent on how non-neutrality might impact its own femtocell traffic when carried over competing fixed/cable ISPs broadband.
  • Some very good sessions on mobile broadband economics - especially around the mix of data from different devices, and the fact that for most operators, only a few cells really face congestion at the moment. 
  • It's worth bearing in mind that for those MNOs selling USB dongles as an alternative to fixed broadband, that means that their customers won't have home DSL/cable to which to attach a femto or use WiFi for offload....
  • Offloading traffic from a MiFi-style personal hotspot (or smartphone tethering) clearly makes no sense
  • There are plenty of complex connection-management scenarios to deal with around offload, for instance selecting between LTE macrocell, HSPA femtocell and various WiFi connections, especially with multi-radio capable devices and multi-tasking where certain apps have different needs.
  • LTE offload is going to get tricky around managing VoIP, whether it's operator-based or third party.
  • Use of WiFi when travelling internationally is going to be an important part of operator strategy. I wouldn't be surprised to see aggregate WiFi+3G roaming statistics being used to convince regulators that "average" data roaming prices are falling fast, even though the cellular portion remains very high-cost.

One other thing I'm becoming aware of: there’s quite a lot of smoke & mirrors about WiFi offload stats. In particular, a lot of the published numbers for “% of data offloaded by operator X” need to be viewed through a lens of scepticism. 

In my view, WiFi usage on smartphones falls into three main categories:
  • Private WiFi use, typically either in the home or office but also elsewhere. As discussed above, this is WiFi access that is used with the mindset of “having a small computer connected to a LAN or broadband” – ie those applications and content that might have been used even without having a cellular data plan anyway. One way to think about it is the type of use that you might see with an iPod Touch – which clearly isn’t offload WiFi traffic as it doesn’t have a 3G modem.
  • Offload WiFi – this is the traffic which is directly moving from 3G/4G connectivity over to the WiFi access, directly substituted. This is the number that is the most important in terms of the economics – traffic which would otherwise have gone over the macro-cellular infrastructure.
  • Elastic WiFi – this is linked to offloaded traffic, but represents the extra amount that users will tend to consume given faster speeds or (perceived) lower price. In other words, this is incremental and not substitutional, even if it is mobility-centric use cases (eg watching video in a cafĂ© or airport) 
I suspect that we'll see a lot of over-inflated WiFi offload business cases based on spurious calculations that don't take this into account.

I'll be uploading my presentation to Scribd and Slideshare soon & will post accordingly.

Tuesday, June 07, 2011

A classic example of app complexity that network DPI would find hard to resolve

Today seems to be the day for me to needle some of my main targets. This morning I had another shot at the hapless RCS service, and now it's the turn of my biggest network-side punchbag, application-based charging.

I've just been given a classic example of why this is going to be nigh-on impossible to ever get right.

In theory, the network should be able to pick out the fact that I'm using Google Maps. I'm sure it's got a pretty predictable "signature" that the average DPI can spot.

But what it probably can't spot is *why* there is Google Maps traffic being used. I've just downloaded the latest version of the Vodafone "MyVodafone" app for my iPhone. It's pretty useful, with a good dashboard feature showing how much data I've used against my cap and so on. This version also comes with a WiFi logon feature.

The sign-up for this has a warning message, telling you that in order to find the nearest WiFi access point, the app uses (guess what) Google Maps. And that I am liable for the data charges incurred in doing so. Now I'm guessing that this is done for a good reason - most probably speed and expediency of getting the thing released, plus I also expect it doesn't use *that* much data in the big scheme of things.

In theory, Vodafone ought to have set up some sort of rule in its network to obviate this, and zero-rate its own offload-location data consumption, especially as its reduced macro network load makes it the main beneficiary. But that would have needed to somehow check that the offload app was indeed the "user" of Google Maps, rather just than me trying to find my way around normally. And that's rather hard, without some sort of agent on the device watching what's going on and trying to decode what GMaps packets are "native" in the mapping client, and which are used via the local API for specific apps.

This is precisely sort of hard and complex situation that I have in mind when I say that app-specific charging is going to be a nightmare. Imagine for a moment that Vodafone had a "menu-driven" non-neutral pricing model, where I got charged £3 a month for using the Google Map app. I'd be rightly irritated if *I* didn't use it, but the operator did itself through its own software, charging me for the privilege anyway. I don't expect the regulator would be too happy either.

On another note, let's see how the Vodafone WiFi app manages to coexist with my other WiFi finder (BT Fon) on my handset. I don't think either is auto-logon, but I can imagine some interesting situations if they are, as both use BT Openzone. Will I be able to tell which "virtual" WISP I've logged into? 

Creating user engagement in RCS and other communications services

I've been having many more discussions recently about my vehement views on RCS and why I think it is (still) destined for failure. In short, the current hoopla about various operators and vendors doing a big push to "make it happen" is not enough.

Yes, it helps that DT, FT, the US & Korean operators and (belatedly) Vodafone seem to be getting their marketing machines & spin-merchants lined up. Yes, it helps that RCS-e ditches the early RCS presence function which normally kills batteries and generates large amounts of extra signalling traffic. Yes it helps that Android is "malleable" so operators can get RCS-e clients onto some future handsets without too much pain. Yes, Orange and others are reportedly trying to strong-arm handset vendors into implementing it. Yes, executives from DT and other operators are name-checking it wherever possible on the conference circuit. Yes, I've even heard the word "freemium" mentioned in the same sentence as RCS.

All good stuff. But falling under the banner of "necessary but not sufficient".

These improvemens still don't mean that RCS-e somehow overcomes the other dozen or so problems I identified last year in my report on its near-inevitable demise. I predicted it would launch, splutter along for a bit, and then fail.

It's notable that when I have discussions with operators or vendors about what the problems really are, the one theme that seems to resonate is that of user engagement. How do you encourage people to actually use and exploit RCS rather than the myriad of other messaging and sharing and social-networking tools at their disposal? What makes them "invite friends" and others to accept those invitations? What makes them "invest" in the service?

Top of the list of things that versions of RCS I've seen *don't* do is permit the little snippets of user interaction that make alternatives like Facebook or Twitter or BlackBerry BBM so engaging.

The most obvious is "Like". On Facebook, you get instant validation that you've posted a cool picture, added a fun status update, attended a great event, listened to a great music track or whatever. It's a single click, but it communicates involvement, friendship, respect, attention, humour and all those other human qualities. It's a way to say "No, I haven't forgotten you, I am reading your stuff but don't have time to write a full message". It's like smiling at a friend, rubbing your partner's back, winking at someone in a crowd.

"Retweet" is similar. As are a whole host of "Vote up/down", "+1", "Recommend", "Share" and so forth.

These create user involvement and engagement, with a simple HTML link. They also tend to be extensible - as seen by the amount of Facebook Connect logos around the web.

Maybe a future version of RCS - or perhaps some operator-specific variants - will do something similar. Because if not, the services are likely to be very "dry".

There's another form of user interaction for messaging I've just become aware of in this context as well, triggered by this article about Apple's new iMessage service. It has something that most PC-based IM software has had for years, as well as BlackBerry Messenger - "typing indication". That's the little animation on a Skype or Yahoo IM window that shows that the other person is composing a reply. It will be interesting to see if any RCS clients can do the same thing - some of the specification documentation suggests it should.

The problem is that in future, communications users will have a very low tolerance of "clunkiness" - and they will also expect features to be upgraded like today's best apps, on a monthly or quarterly basis. There will also need to be a mechanism for operators to test different types of apps on certain groups of *live* customers. Google and Facebook can change their web page layouts, or app behaviours, for certain groups of their users, to see what works best. In my experience, it's pretty rare for telcos to do comparison-testing of different versions of services on their "production" customer base.

Overall, I still think that RCS is going to face insurmountable challenges - especially with newcomers like iMessage and whatever Google does with adding communications services into the browser. I think there will be a few niche usage cases - and perhaps specific countries where local conditions are unique enough to support it. But unless they get the user experience not just "good", but "fun" and "engaging" as well, it will struggle to gain traction.

Monday, June 06, 2011

Can telcos compete in an era of fashion-driven services?

NEW: Download the Future of Voice Masterclass flyer here

We're all used to the descriptions of the mobile phone business being (to some extent) fashion-driven. Just like clothes, some things go in and out of style - touchscreens, clamshells, big, small, black, coloured and so on. We've also heard plenty of handset brands described as cool / uncool - obviously with variations around the world.

I remember a few years ago, for example, SonyEricsson was very much an edgier and slightly counter-cultural brand in the UK, back in the pre-iPhone / Android era. I remember being at a gig and noticing which phones were being lofted overhead to take photos or videos of the band - S-E's were dominant among the younger fans.

So we see device brands - SonyEricsson, Apple, Nokia, HTC, Motorola and so forth - compared with cars (Audi, BMW, Ford, Nissan or whatever) or clothes (Ted Baker, Calvin Klein, Marks & Spencer, Armani and so on).

Up to a point, that's been mostly irrelevant to the mobile operators - barring the need to subsidise the more expensive ones, but that's usually (pre-iPhone) meant particular models rather than the whole brand. Sure, they've been able to exploit exclusive deals or other arrangements - but I don't think they've particularly cared if LG is seen as the equivalent of Mercedes or Citroen or Hyundai.

But now there is another issue - one already seen in the fixed-Internet world.

*Services* are now being driven by fashion, as well hardware. With the coming of smartphones and apps - and fast access to the public Internet, with new ways of creating "viral" adoption among communities - we have seen the rapid rise (and often fall) of novel ways to communicate. Facebook, Twitter, WhatsApp, BBM, Skype, Viber, LinkedIn and so on have grown in part because of adoption within groups. They can be tribal, cliquey, ephemeral - used for a season and then discarded (remember MySpace, Bebo, MSN?). Or they can be regional (Hyves, Friendster, Cyworld, vKontakt, Orkut, QQ etc).

This is much more problematic for telcos, as operators are used to egalitarian, very long-lived service offerings that don't vary much in popularity, awareness or coolness. This has been because in the past, there were very few communications services - phone calls, SMS, email, fax. All were essentially "designed by committee" and so none could possibly be thought of as cool or fashionable - they just "were there".

Sure, there are parts of the communications-using population which aren't particularly fashion-driven, but fewer than you might think. Plenty of CEOs want to connect their latest, shiniest i-Toy to the corporate network. Plenty of businesspeople were using BBM long before the teenagers go hold of their 'Berries. Even 10 years ago, people in finance were sending messages (and jokes) via the proprietary Bloomberg messaging system rather than corporate email.

But in any case, two important groups - people with money, and younger people - often *are* fashion-driven, or at least status-driven.

Now there's an important distinction here between equating phones, services and other non-tech brands such as cars and clothes. Phones are similar to cars in that most people only have one, or maybe two, keeping them for a considerable time. But people have wardrobes full of clothes, some new, some old, some cool, some utilitarian - and buy new ones regularly. They might buy the trendiest new shirt or coat for socialising, or something cheap and comfortable to chill out with on the sofa.

I think the PSTN and SMS and basic mobile telephony are going sofa-wards. They're not going to be made obsolete, but relegated to the status of lowest common denominator clothes essentials that everyone has. Underwear that gets worn when nobody else is likely to see it. Sweat-pants for doing the gardening. Comfy shoes for a long-haul flight. Stuff that gets worn when you don't care about being fashionable.

It's quite common even for the coolest of hipsters to buy their socks from Marks & Spencer. Plenty of people pair one item unique and expensive, with another which is totally generic. Prada + Primark. Zegna + Zara. Missoni + M&S. Tiffany + TopShop. (Not sure of the US or China or India equivalents here...)

The question is whether - and how - telcos could either turn into Primark equivalents, or develop platforms that could form the basis of continually-churning fashion-driven services. Primark, for those unaware, is hugely popular and quite profitable, even for low-end clothes. Its shop on London's Oxford Street is always swarming with people buying basic, cheap, almost-disposable clothes which nevertheless have an essence of coolness. Like Zara, it's been radically engineered to be responsive, with great back-office supply chain management. Conversely, other higher-end clothes brands have developed the annual cycles of fashion shows and manage to reinvent themselves regularly - and you also have fashion house with multiple brands.

Some operators - notably DoCoMo in Japan - have long been pitching "this season's new services", but that's still not common given the lengthy cycle times for development and standardisation.

It's really not obvious to me how standards-based telecoms offerings can ever again play at the top end of communications services. Even if industry initiatives like RCS succeed, I suspect that the best they can aim for is the being the next universal telecoms equivalent of a pack of £6-for-three Primark Y-fronts, worn underneath a pair of £300 designer/developer jeans. And to get to where Primark is today, they will still need prime retail space, a very hard-working team and flawless back-office functions.

NEW: Download the Future of Voice Masterclass flyer here
For Santa Clara event tickets on June 30th, book here  
For London tickets for July 14th, please contact me at information AT disruptive-analysis DOT com

Wednesday, June 01, 2011

Inspecting the inspectors & throttlers - reverse engineering network policy

I first wrote three years ago about the likelihood of various companies or other organisations starting to "reverse engineer" operators' traffic management policies.

Indeed, one of the common features of most regulators' pronouncements on more "flexible" regimes for Net Neutrality is that any traffic management is absolutely transparent to the user. Clearly, that transparency will need to be tested, either by regulators, consumer advocacy organisations or application providers.

So a hat-tip to Azi Ronen's great blog on Traffic Management for spotting this research paper from the US state of Georgia, which does some great analysis of US ISPs' throttling activities. A whole range of other tools are also listed on this page: http://rk.posterous.com/tools-for-testing-your-internet-connection

Over time, I'm expecting to see much more granular approaches to this - for example tracking application-specific policies or other rules and controls. I've seen some analysis by Epitiro presented at a conference, which showed a certain ISP degrading IPsec traffic at certain times each day. It seems likely that many others will join this trend as well - the EFF has certainly been doing it for a while, for example. 

I also expect that Google, Apple, Netflix or others are collecting a huge amount of their own data and measurements about application performance metrics from smartphones and other devices. They probably have very good views on what looks like "natural" variation in congestion and throughput, versus that which looks "unnatural". As is the case with the Georgia study, any "messing about" with the IP stream will stick out like a sore thumb - as well any background optimisation, content adaptation and so forth.

In other words, operators' network policies are likely to be transparent - whether they want it or not.

What will be interesting is what happens in circumstances in which the network's performance appears to have been modified - in direct contradiction to an operator's marketing campaigns or the local laws. It will be unsurprising if we see some prosecutions for mis-selling or outright fraud in some cases.