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

Tuesday, June 16, 2015

WiFi Offload.... or Onload?


One of the things I get annoyed by regularly is the mis-characterisation of a lot of WiFi use on smartphones / tablets as "offload".

In my view, true "offload" is a term only applicable to data which would otherwise have transited a cellular network, and which has been deliberately pushed to WiFi at a public hotspot, with the intervention of a service provider.

It is very different to "private WiFi" use, where the user has unilaterally decided to connected to a network (for example at home or office) of their own volition, or because a venue or other sponsor has made WiFi access available.

Care also needs to be taken about elasticity - user behaviour may change when on WiFi, even with "proper offload" - if the connection is cheaper or (more often) free/unmetered. At that point, a notional volume of traffic X that might be used on mobile might become 2X or 10X when on WiFi. This could be because of a shift in user perception ("Hmm, yes I will watch Game of Thrones streamed on my phone"), or it could be because an app-developer has created a different experience when connected to WiFi (eg auto-playing video, or enabling downloads of updates).  

[Sidenote: connectivity is not "all the same" - both users and developers make very different decisions when a device is on WiFi vs. 3G/4G. People & apps/OSs are aware of, and care about, the type of network which they're connected to. The notion that it doesn't matter is a core fallacy behind the notion of so-called "seamless" HetNets and integrated infrastructure] 

In other words, only a tiny fraction of smartphone WiFi use can be called "offload" with any reasonable definition. I'd estimate that it's well under 5% globally, and probably under 10% of phones' WiFi usage even on those networks which have extensive operator-driven offload implemented. For tablets, the numbers will be lower still, as the majority are non-cellular and therefore can never "offload", while even mobile-enabled ones are mostly non-activated or primarily used in static locations with private WiFi.

But there is another trend emerging in parallel to "real offload" that will make the numbers even more confusing.

In some cases, people or applications might deliberately switch to cellular from WiFi, for example if the WiFi network is congested, coverage is poor, or there are localised authentication problems. In other words, we will see "offload" from both cellular-to-WiFi AND WiFi-to-cellular. It may be that one direction of this gets referred to as "onload". It may also be that the WiFi-to-cellular onload is larger in volume. This would mostly driven by users' deliberate switching, but perhaps also by WiFi-primary policy clients on devices, for example from services provided by cable operators.

Takeouts from this:
  • Be skeptical of most alleged "WiFi offload" figures - they're usually nonsense
  • Most smartphone WiFi usage is private - traffic that would never have used cellular anwhere
  • Be aware that WiFi/cellular onload happens, as well as cellular/WiFi offload
  • Claims that "nobody cares which network they are on" are either ignorant or duplicitous
  • View all discussions of cellular/WiFi combinations through the lens of WiFi-primary users as well as cellular-primary viewpoints

Friday, June 12, 2015

Qualcomm's MuLTEfire is what LTE-U should have been, instead of LAA

Yesterday, Qualcomm rather quietly announced a project called MuLTEfire on its blog.

It describes it as "a new, LTE-based technology that solely operates in unlicensed spectrum, and doesn’t require an 'anchor' in licensed spectrum"

This is a very different proposition to the other type of LTE-U, called LAA (licence-assisted access), which requires a provider to "anchor" the service in a separate (licensed) band. That has proven very controversial in recent months, with fears that its coexistence with WiFi in the 5GHz band could prove damaging, with extra interference. There are claims and counterclaims there, with both technical and "moral" viewpoints.

But I've been critical of LAA for another reason - I think it is potentially anti-competitive, as it is only usable by operators that have (paid) spectrum for other LTE networks. It could be seen as a way of extending an oligopoly position into an adjacent marketplace, as inevitably its use in a band reduces theoretical capacity available to others, even if it behaves "politely".

My view of unlicenced-band cellular has been that it should be available to all to implement, in the same way that WiFi is. At least in concept, MuLTEfire is what I'd envisioned when I first thought about unlicenced 4G.  

(I'm not 100% certain, but I think I may have personally invented the concept of unlicenced-band LTE myself, as per this blog post from July 2008 . I also suggested SIM-free LTE a couple of months later) 

Fully-open unlicenced LTE has some rather interesting possibilities.  By decoupling LTE from the constraints of licenced spectrum - and, ideally, without a SIM card or with some sort of soft- or programmable SIM - then we could see a set of revolutionary new business models. For example, it would become possible for venues to offer "free 4G" to visitors, or for all sorts of novel "anti-roaming" propositions to be provided. We could also see true "private cellular" networks - which have already been proven in concept by the use of light-licensed GSM guard-bands and pico/femtocells in the UK and Netherlands.

Obviously, any company considering its deployment could equally-well use WiFi in the same places. But LTE-U in MuLTEfire might allow easier roaming, especially in devices which don't have SIM-based WiFi capabilities enabled.There are also all sorts of interesting options for hybrid MVNOs/MNOs, neutral-hosts for indoor coverage, and a bunch of other concepts I've got at the back of my mind.

In particular, given this is cellular technology, it is actually much more aligned with the notion of "seamless" connection than the WiFi is. I'm a deep skeptic of integration of WiFi with cellular, as it introduces too many compromises in terms of user choice and policy/preference conflicts.

Qualcomm's timing here is very interesting - the FCC has been asking for submissions about LTE-U / LAA, with the initial comments also due yesterday. And there's a big spectrum management event in Brussels next week - I'm presenting on Tuesday afternoon and will be mentioning LTE-U on a panel which also includes a Qualcomm speaker.

Now clearly, a lot depends on the details (eg IPR costs, whether the coexistence works as billed) and whether the project gets traction. But for a mobile-industry giant such as Qualcomm to even suggest a SIM-free variants of cellular is a major step forward, and one that I've been advocating for years.

Thursday, June 04, 2015

What's YOUR view of contextual communications?

In recent months, I've been drilling into the new "hot topic" of contextual comms. Martin Geddes & I are so enthused by the topic that we're running a workshop on June 15th in London (details here), and we're already considering follow-ups, maybe in the US later in the year.

We're combining both the "here & now" of context with a view on where we might be heading in the medium-to-longer term. Martin wrote a very forward-looking and provocative piece on the possible future recently (here).

I'm really interested in what "contextual communications" means to everyone else. There's no fixed definition at the moment, and I suspect that we're going to get an "Olympic Rings" multi-way Venn diagram. Some views of context will overlap, while others will be miles apart. For instance, I've seen or heard all of these described as Contextual Comms:


  • Sending web-form info to an contact-centre agent during "click to call"
  • Embedding video/telepresence into a robot
  • Using mic & speakers on a phone to map out a room acoustically & tweak the echo/noise processing
  • Use a media-server to analyse a caller's tone (eg angry vs. happy) or facial expressions, and adjust the experience or script for a salesperson
  • Using a device orientation sensor to work out if a phone is flat on a table, or help to the ear, and adust the UI accordingly
  • Using machine-learning and analytics to assess the best time to call someone
  • Mechanisms for indicating the purpose of a call
  • Embedding a call into a timeline or activity-stream interface for UC and collaboration, so it can be recorded, captured & seen alongside text commentary or speech analytics
I'm sure there are dozens more as well. I'm looking forward to distilling some sort of map or ontology, so we can collectively understand this new landscape a bit more clearly. Is it one thing with lots of variants? Or 5 separate trends with a little overlap?

Do YOU have a good example or definition of Contextual Comms? I'd love to hear from you, either via a comment here, or by doing an interview briefing.

And if you'd like to talk about it publicly, we're offering all the workshop attendees an chance to present or demo their view - basically an "open mic" section of the day to showcase their unique take on context.

If you'd like more detail about the event, or to get in touch separately about context, please comment,  see this page to book a spacea, or email information AT disruptive-analysis DOT com.

Monday, June 01, 2015

WebRTC & Contextual Comms may help so-called "OTT" apps avoid regulation



Last week, the Belgian authorities tried to claim that Skype is a telecoms "operator" and should comply with a similar set of laws to fixed and mobile telcos, especially around data-retention and lawful interception.

The Indian regulator TRAI has been undertaking a consultation about whether so-called "OTTs" should be somehow "regulated". (TRAI's consultation document is one of the most woefully-written and factually incorrect pieces of official literature I've ever read).

Slightly different but in the same general domain, the UK Government is looking at ways to limit the use of encryption and anonymity with Internet communications services, again to collect metadata. (Sidenote: I think some of the proposals are rather technically ignorant and will get sidelines - and it's worth noting the UK remains one of a dwindling set of places without either official ID cards, nor a requirement to register SIM cards).

A major principle that keeps cropping up is that regulators, telcos and governments assert that services such as Skype and WhatsApp are somehow "equivalent" to traditional phone calls or SMS, and therefore should attract similar regulation.

This also intersects with another set of regulatory pushes (notably by Telefonica's increasingly shrill & incoherent policy team) to try to force interoperability onto 3rd-party communications apps. Sometimes calling it "platform neutrality" this seems to be a transparent attempt to reduce competition from new voice/video/messaging apps by dis-allowing "walled gardens". Given that the only likely medium for mass interop is the PSTN (and E.164 numbers), this is a blatantly defensive move to ensure the old phone network remains at the centre in future. It's unworkable, but unfortunately the current EU Commissioners seem more keen than their predecessors to try to implement stupid/unworkable ideas from the telco lobbyists.

Yet this is all very rearward-looking. The most successful future communications apps are not going to be yet more "free standalone messaging" services that look like SMS or WhatsApp, nor "cheap generic VoIP calling" ones that emulate Skype. 

Those ships have sailed already. It's another reason why most telcos' "IP communicator" apps will fail, especially if based on lower-than-lowest common denominators like RCS.

Instead, any new winners are going to be unique in some way - features like disappearing messages (SnapChat), blending realtime 2-way voice with asynchronous (eg Talko), embedded voice/video as a secondary feature in other social or business apps (probably with WebRTC), or with a strong contextual-comms element (using the user's physical status or intended purpose).

The interesting thing here is that not only would these be differentiated but it would also seem impossible, or at least much harder, to claim (note: I'm not a lawyer) that these are "equivalent to the phone service".

I also think existing services need to assert their "non-equivalence" much more vehemently - and point to the lack of innovation in telephony and SMS over decades. 

Regulators should not be accepting telcos' arguments that they need to cross-subsidise network investments with profits from over-priced, near-obsolete services.

In the Skype case, I'd say that one option Microsoft has in Belgium is to ditch the interconnection to the PSTN, and possibly move to a video-only model. Both would indicate that it is not a "phone service" but something entirely different. Given that there is no successful telco video-calling service (nor, with RCS & ViLTE as proposals, will there ever be) it would be much harder for the authorities to claim equivalence.

A more interesting defence of Skype's uniqueness could come from analysis of the proportion of calls preceded by a messaging session. In my view, the user experience of Skype is very different to the PSTN, as it is not based around unexpected, interruptive calls, but is instead an "escalation" method of rendezvous and arrangement. You use presence, chat with IM, and then say "OK for a call?". That is different to traditional comms experiences.
 
In fact, I'd argue that designing a new service to be too unique & differentiated to meaningfully interoperate with the PSTN or SMS means that:

a) It stands a chance of success, against 100s of "me too" apps and installed bases of 500m+ for entrenched competitors.
b) It will be harder to capture with pernicious regulations and telco lobbying, as it's clearly something new, and not just a cheaper substitute for protected legacy services.

Having given this a lot of thought, I've reached the following conclusions:
  • New communications apps SHOULD NOT interop with phone calls (like SkypeOut or iMessage) if at all possible. If they do, they risk being classified as "similar" to regulated services.
  • Avoid using E.164 phone numbers as identifiers as possible, for similar reasons
  • Ensure that user behaviour and features are very clearly distinct from traditional "calls" or SMS, to the degree that "interoperability" is meaningless
  • Concentrate on communications-as-a-feature rather than as a standalone service, unless it is a completely unique and differentiated format. WebRTC is the likely key enabler. (Click here for my research report)
  • Create "clear blue water" between legacy phone-calls / messages by using contextual communications capabilities that cannot be replicated in traditional telco service. Focus on how, and why a specific instance is occurring, and use external data to help reach the desired outcome.
  • Where there is a specific business need for interop, avoid using 3GPP/telco standards wherever possible (SMS, SS7, IMS, RCS) and use the web or proprietary mechanisms instead.

As a reminder, I'm running a workshop on Contextual Communications on June 15th in London, along with Martin Geddes. Sign up here.

Tuesday, May 26, 2015

WebRTC platforms & distribution partnerships: From evangelists to acolytes

Over the last month I've been to a number of WebRTC and related events - AdvancedComms Asia in Singapore & HK, WebRTC World Expo in Miami, and GenBand's Perspectives customer/analyst conference in Orlando, as well as numerous meetings and calls with WebRTC-related vendors, users, investors and clients.

A couple of themes that have emerged are mostly continuations of existing ones - the overall pendulum of WebRTC swinging towards enterprise "disunified comms", a broad recognition of the equal (or greater) importance of mobile WebRTC-embedded apps vs. browser experiences, and the continued steady growth in profile of telcos and other service providers. All of these I've covered recently on this blog, or in my regular WebRTC research report updates for clients.

But one additional trend really jumped out at me last week at the GenBand event: the importance of distribution and integration partnerships, for WebRTC PaaS players. It's something I'd started seeing signs of at Enterprise Connect in March, but some of the impressive activity that's been done by GenBand's Kandy "ecosystem" really threw it into stark relief, and brough a few separate things together for me.

The headline: Evangelism is not enough

Lots of WebRTC companies are out pounding the conference circuit, not just for the technology itself, but also at specialist events for healthcare, finance, general web-design and so on. They are running hackathons, providing developer out-reach via web forums and other avenues, and generally "getting the story out there", especially to the long tail of developers.

That is absolutely necessary. But it's not sufficient.

The WebRTC PaaS market needs not just evangelists, but acolytes too. These are third-parties who are "devotees", or "followers", or assorted other religiously-inspired terms that imply not just "belief" but also provision of active help in the priest in performing the rites.

Translating the metaphor to IT terminology, this means systems integrators, channel-partners, consultants and others who assist in the "go to market" for the PaaS providers and their SDKs. (A fairly similar argument also applies to WebRTC gateway vendors, although that's somewhat different given upfront costs and existing infrastructure. I'll cover it in another post/report).

This gives a multiplier effect, as various types of partner are able to reach out to their customer base, adding broader marketing and sales resouce, adding value through other products or software customisation, or giving an impression of greater credibility and stability.

I see at least important 4 go-to-market channels for PaaS providers, each with sub-divisions:
  • Major software companies embedding PaaS (or components). Temasys' recent announcement with Citrix for its browser plug-ins is a good example, as is Kandy's expanding role within SAP's applications, and also as a basis for its own fring application. At Enterprise Connect, I liked CafeX's integration with Humanify for contextual-comms in B2C websites as well.
  • Systems integrators. Acision announced last year that it was working with Capgemini, and Kandy is working with Tech Mahindra among others. I know from my own research sales and consulting that other major firms are interested in WebRTC, but it's less clear if they will "roll their own", work with established PaaS players, or pick-and-choose for particular projects.
  • Telcos & SPs: While some telcos are developing their own PaaS offers, others are acting more as solution integrators, combining an existing platform with other elements. Tata Communications is using SightCall's PaaS, as well as various other vendors' products in its Click2RTC offer.
  • Consultancies & agencies: There is a broad range of "general" web, comms and mobile-app professional services companies interested in WebRTC. They range from high-profile WebRTC specialists such as Quobis (which also has its own software products) through to "digital media agencies" that work with brands or B2C players on overall web/mobile strategy and design. Acision's work with Blacc Spot and Kandy's with Deloitte's Digital arm are examples.


The categorisation can never be perfect - various companies can exist in multiple roles, and sometimes the PaaS offer blends into the background, while sometimes it's more transparent as a "resell". But the general principle is the same - the PaaS provider gets the benefit of extra scale and reach, as their ecosystem is doing some of the heavy-lifting.

The relationships have to work two ways as well - the PaaS vendor needs to invest quite a lot of effort to turn a couple of isolated deals into a genuine "ecosystem", where there are genuine feedback effects. At the moment, I'd say Kandy is probably ahead in terms of brand-name partners, and seems to have invested quite a lot to get its message across, at least in North America. The heavily-branded tour bus is a nice touch.

There is also another spin on distribution here - some WebRTC PaaS providers have another ready-made channel: their own existing developer programme/community for other APIs. Twilio and AT&T are the two most obvious proponents of this approach, as well as Tropo although its acquisition by Cisco rather changes things.

I'm going to keep a close eye on the evolving partnerships here. I suspect some don't get much further than a press release, while there are certainly others that have not (yet) been publicly announced. 

I'm also curious to see if any of the gateway-specific SDKs evolve into full PaaS platforms (eg Oracle's, Sonus', Broadsoft's), or indeed the UC-centric APIs from Unify or Avaya. A number of those companies - notably Avaya and Oracle - could also WebRTC-ify their own company's vertical market apps via their own platforms. Cisco+Tropo is an obvious candidate for that as well, while Tokbox could potentially be leveraged by other units of Telefonica.

The bottom line is that the various WebRTC platform providers are doing a better job in 2015 at promoting their role in the industry. But signing up third parties and ecosystems should have a multiplier effect.

More detail on the WebRTC market, PaaS, gateways, channels and vertical solutions is included in the Disruptive Analysis research report & updates. The next edition, due in early July, will consider the channel/ecosystem dynamics in greater detail. To order the report & updates, click here.

If you want to discuss a more specific research project, or brief me on your company, please contact information AT disruptive-analysis DOT com .

Monday, May 18, 2015

Ad-blocking: No, mobile operators won't be blocking adverts & charging Google to restore them

The last few days have seen a bunch of articles (see here [paid], here, here)  suggesting that some mobile network operators - notably in Europe - are considering deploying ad-blocking capabilities in the network, and potentially charging companies such as Google for the right to "unblock" them via some sort of revenue-share agreement. A company called Shine has been mentioned as a possible vendor - I've spoken to the firm in the past and was unconvinced.

That said, the idea that mobile operators might block ads in their networks, or charge for the traffic they use, is not new.


In fact, I believe invented the concept myself, 4.5 years ago. (See this post  - sorry to anyone trying to patent the idea!). I wasn't entirely serious, but I could see it was a possible future.

Another thing I’ve said before is that telcos often “take 4 years to spot a good idea, 4 years to implement it & another 4 years to realise they’re too late”.

And in this case, it’s already too late. While ad-blocking might be effective for stopping in-browser ads, the technology will struggle with other formats like in-app ads (except where they are from an obvious source, or in a hybrid "webview" page in the app). It also struggles with various forms of “native” advertising embedded into content, such as video pre-roll ads or sponsored-content promotions. 

In addition, the landscape has changed massively since 2010, in terms of the way that ads are delivered, dataplan size and the large role that Google/Android and other advertising-centric companies have on the overall mobile landscape. 

There are also many possible responses and workarounds to “block the blockers” – see below. My view is that these experiments will not just fail - they could backfire spectacularly.


Regulatory & policy context

As context, there is also much more awareness – and much less tolerance – of networks “messing about” with Internet traffic in 2015 than 2010, although parallel concerns over privacy and the power of a few web players perhaps make ads “fair game” despite that.

There is also a growing war in Europe especially, against US-based Internet companies being waged by some of the more shrill “public policy” teams at major telcos. Telefonica is among those advancing the most egregious and hypocritical arguments – with its blog putting up strawman after strawman, which I sometimes try to counter in the comments.

This fight is tacitly supported by the new European Commissioners Ansip & Oettinger, who seem less capable of forming independent and coherent opinions about telecoms than their "steely" predecessor Kroes.

In a nutshell, some European telcos feel they can “get away with” harassing Google and to a lesser degree Apple and Facebook, and get air-cover from their national regulators and the European Commission. While the current trials might have the convenient excuse of “protecting users’ dataplans”, the reality is much more duplicitous – they are jealous that Google has out-innovated and out-maneouvred them, in a similar fashion to their rhetoric about “OTTs”, when they have been asleep at the communications wheel for 20 years.


Minimising the data burden on users

The point in my original post was that one of the few forms of non-neutrality that regulators and the public might tolerate is that of dealing with mobile adverts. Perhaps that traffic could be paid for by the advertisers and their channels. Advertising is widely disliked - as evidenced by the growing number of (mostly PC-based) browser users downloading ad-blocking software themselves. A recent German lawsuit by publishers was defeated, but we can expect additional action to follow if telcos try to take the same path - as well as worsened relationships between the two groups of companies.

While the morality of overall ad-blocking is dubious (it’s how useful free content is paid for), on mobile data-plans with low usage caps it may indeed be an onerous burden. Websites have a right to advertise at me, but don’t have a right to make me incur substantial extra costs for the “privilege” of being “advertised at”. Auto-playing video or audio adverts alongside static content are especially disproportionate. Various forms of pop-up or other intrusive formats are also occurring in mobile, as browsers get more capable – and there is justifiable resentment at some of these. 

Paying for ads’ data usage while roaming is especially awful, and is perhaps where the operators genuinely could offer user benefit and value by blocking them. Unsurprisingly, this will probably be the last use-case considered, given the perennial and profitable rip-off prices charged for data-roaming.

Sidenote: A compromise I’d suggest from the mobile advertising industry: ensure that ads take up no more than 10% of the total traffic needed for a given website or app when accessed over cellular networs. This would neutralise the bulk of the arguments being advanced here.

I actually believe that traffic for ads is one of the very few categories that might be viable as a source of “sponsored data” – although this will be in the form of discretionary promotions (eg bulky movie trailers downloaded for free) rather than some sort of across-the-board tollgate. I estimated the future market size of sponsored traffic for advertising in my recent report on new monetisation business models - it may reach $2bn by 2019 (see here). But the model suggested here – block ads unless the companies pay up or agree a revenue share – is the wrong one entirely.

Extortion only works against the weak.


Deploy counter-measures!

And in this case, the advertising machinery is anything but weak. The ridiculous thing about this concept is the ease with which such measures can be mitigated. I can think of 5-10 possible workarounds straight away. The most obvious group of approaches is to blend apps with content so they cannot be teased-apart, and another set involves using methods to avoid the filters in some way. There are plenty of other possibilities too.

Encryption of content is the most obvious. It is already widespread in mobile, and is growing fast – in some networks, more than 50% is encrypted. There are multiple styles, ranging from SSL built-in to HTTPS traffic, SRTP for WebRTC traffic, through to using compression and proxy servers. Some of these are still theoretically “blockable” based on IP address, but the risk of false positives increases hugely. The inclusion of Google’s SPDY technology into the HTTP2 standard has pretty much ensured this is a one-way ratchet for web traffic in future. 

Belated efforts by the telco industry such as the “Open Web Alliance” to limit crypto usage or propose “trusted proxies” for traffic management are already failing and, ironically, are undermined by “untrustworthy” actions such as this.

Google is already offering a VPN option in its new Fi service, intended to secure traffic over 3rd-party WiFi. It doesn’t take much imagination to see that this could become a ubiquitous feature for Chrome – or even Android OS – over any connection. All the operator would see would be a single stream of encrypted traffic to and from Mountain View or a local Google node – perhaps even inside its own network.

The other obvious fly in the ointment is WiFi. Most smartphone users already spend 50-90% connected to 3rd-party WiFi access in homes, offices, cafes, hotels and other places. Advertising will work normally in those places. Ignore the “seamless” carrier-WiFi hype – mobile operators’ own hotspots are a tiny fraction of the total in most countries, and will stay that way. We won’t see fixed ISPs and every WiFi operator pursuing a similar strategy of ad-blocking either – there is no rationale for it. This means that (a) Google and other advertisers will further assist users in finding WiFi, perhaps even subsidising it; and (b) Tools will be built into OS’s or 3rd-party SDKs to allow developers and advertisers to download and pre-cache advertising via WiFi, serving it up locally as-needed.

Indeed, we would likely see various new ad-related APIs, or delivery services, being rolled out in Android and iOS, plus browsers, to help work around the blockages. These developments will not have come as a surprise to many, and it is foolish to believe that countermeasures are not already being worked on. 

Of course, Fi also means that Google now has a very good view of the wholesale costs of mobile data provision, and this will impact the ridiculous "revenue share" concept still further. At absolute worse-case, it will be asked to pay fees much lower than the consumers' retail price of mobile data. There will also be no justification for "double-charging" consumers for the same data paid for by advertisers.



Actions have consequences

The mobile industry is playing with fire here. The countermeasures available to Google, Facebook and others are powerful. There is a very significant risk that rather than increasing revenues, that instead these moves will actually decrease revenues, as well as increase costs and have assorted other unintended consequences – especially more encryption, and more use of 3rd-party WiFi. 

Some of the ads that may get blocked will no doubt cause embarrassment or even legal action – I can’t imagine competition authorities being amused if TelcoA blocks ads for TelcoB, for example. There’s also a strong risk that TelcoA blocks some of its own advertising, given the typical distant and disconnected silos within a large operator. That should make for some lively boardroom discussions. The publishers vs. telcos fight won't be pretty either.

I also envision the system lacking “discrimination”. Unless there is a laborious "white list" process, it will probably block ads for charity appeals, or stop government-paid ads for voting registration or impending tax-return deadlines. That should cause much amusement in policy circles, I’m sure. There will inevitably be a host of “false positives” and “false negatives”, as you can expect companies to use the same distribution channels and “signatures” for both ads and “legitimate” content.

The biggest irony is that all this will just encourage continued advancement of native apps and OS’s vs. more-powerful browsers – the exact opposite of what many telcos would like to see happen. In-app advertising will inevitable be more block-proof than web-based versions.

It’s even possible that Google will start tiering or limiting its own services on “hostile” networks, to encourage users to churn to “friendly” ones. And in extremis you could even imagine MNOs being made to pay for subscribers’ access to certain apps or services. Most people would more happily switch telco, than switch Internet ecosystem.

My prediction is that these ad-blocking services will never see the light of day - and if they do sneak out, will cause untold amounts of pain. The idea the MNOs will get a signficant revenue-share of a business to which they add zero value is laughable.

Overall, trying to extort protection money “in case something nasty happens to your ads” is a silly and unnecessary risk. Never mind the old cliché about bringing a knife to a gunfight – the mobile industry is trying to act like a racketeer here, but is only packing a rusty spoon in its belt.


Thursday, May 07, 2015

RCS is still a zombie technology, "28 Quarters Later"

In February 2008, a number of major telcos and technology vendors announced the "Rich Communications Suite Initiative" (see here).  I first saw the details a couple of months later, at the April 2008 IMS World Forum conference in Paris.

It is now 7 years, 2 billion smartphones, and 800m WhatsApp users later.

Or to put it another way, 28 Quarters Later*.



However, unlike Danny Boyle's scary, fast-moving monsters in the 28 Days and 28 Weeks Later movies, RCS is not infected with the "Rage Virus", but is more of a traditional zombie: dead, but still shambling slowly about and trying to eat your brains. It's infected with bureaucracy, complexity and irrelevance.

To remind you: April 2008 was also a few months after the launch of the first iPhone, and a few months before the launch of the AppStore. It was also when Facebook Chat, now Messenger, was switched on in my browser for the first time - while I was waiting on the podium, to start chairing the IMS event. The world of mobile devices, apps and - above all - communications has moved on incredibly far since then.

But not for RCS.

The last 7 years have seen multiple iterations of RCS versions 1.0-5.2, RCSe as a short-lived spin-off, Joyn as the GSMA-sponsored brand, and more recently an attempt to piggy-back onto the deployment of VoLTE, as well as an attempt to reposition RCS as either "SMS 2.0" or some sort of API platform for developers.

Yet the active RCS user base is never quoted - I suspect it has fewer than 20m monthly users worldwide, and probably fewer than 5m active daily users. And by "active" usage, we should really focus on the "rich" aspect (see also below) with video or file-sharing, not just SMS-in-zombie's-clothing text. 

(Some vendors/operators are trying to replace native SMS apps on phones with RCS, to force people to "adopt" it. Most will just assume it's still SMS for text-messaging and avoid the other so-called "capabilities". Be wary of puffed-up future stats). 

The issue is that RCS has a large number of unfixable structural problems that guarantee its perpetual failure:

  • It is "engineered" not "designed". Nobody sat down to ask what human problems RCS is intended to fix. It's a random grab-bag of technical features designed to be "interoperable" rather than "be useful for a purpose". There were no psychologists, designers or behavioural specialists involved in its creation.
  • It has a bunch of expensive and complex "moving parts", using obscure and inaccessible protocols. Alan Quayle has a good run-down on its failings here
  • Nobody needs expensively-engineered network cellular "QoS" for messaging, especially when 50-90% of use will be over 3rd-party WiFi anyway.
  • It comes from an era where standardised app-level interop and federation was seen as a major benefit ("SMS only took off when networks interoperated") without recognising that 10-sec app downloads or 1-sec browser interactions now make this irrelevant. Popularity, design and purpose are keys to success - you can always interoperate later if needed, via the web.
  • It's very slow-moving, as it's standardised by a committee process and hundreds of pages of labyrinthine documentation. It can't rapidly respond to new developments - messaging as a platform, stickers, "last seen online", likes, filters, disappearing messages etc. While it is a bit more extensible today, with operators' own features, it is still hamstrung by the lowest-common denominator interop specs and unnecessary QoS and per-message charging machinery
  • RCS is often pitched as "competing against OTTs", but no reason is ever given why users should switch away from WhatsApp, LINE or WeChat, and for which use-cases. I have never seen a case-study interview of a teenager saying "I used to use SnapChat, but now all my friends have switched to Telco Messenger X"
  • There is no obvious business model, except giving it away for free and hoping it adds value to a service bundle. Given that VoLTE is already an expensive investment in a declining market, it seems unlikely that many telco CFOs are keen on throwing yet more money down the drain for zero/negative ROI.
  • Blending RCS with VoLTE overlooks the fact that VoLTE will not become "ubiquitous" for at least 10 years, and maybe never. I'm forecasting just 27% of LTE users to have VoLTE by end-2019  or in other words, less than 10% of overall mobile users. Limiting RCS to the niche of VoLTE users guarantees its irrelevance, given they're exactly the people most likely to use other apps on high-end devices.
  • There is (AFAIK) no free international interconnect model for RCS - yet an important use-case for Skype, WhatsApp, WeChat and others is chatting to friends abroad.
  • It is "any-to-any" rather than driven by buddy lists or whitelists, and so prone to spam and unsolicited marketing messages. Conversely, WhatsApp remains almost totally spam-free (helped by lack of an external spammable API, as well)
  • RCS needs an IMS, which no mobile operator really wants to deploy, unless/until they're forced into it by VoLTE. While some RCS-aaS cloud solutions exist and help manage the costs, they still require client solutions on devices
  • It's not supported by Apple and only half-heartedly by Google/Android and Microsoft, as they all have their own (better) communications products that tie into their own ecoystems (and their better understanding of user behaviour and design)
  • It's not widely supported in retail-market "unlocked" handsets, used by most of the world's majority of prepay mobile users.
  • It doesn't work very well with dual-SIM phones, or for people who have multiple SIMs and accounts.  
  • It's unclear how it will work for people who don't have data plans. It might be zero-rated, but that has its own complexities and risks. For example, are file-transfers zero'd as well? It would be ironic if RCS got pressed into service as a free way to download other messaging apps from appstores.
  • It is being pitched as a "platform" before it is a successful "product". That's not the way the technology industry works. Developers and enterprises will only sit up and listen when it has already got widespread adoption among the audience.
  • Ubiquity is earned. Whatsapp, WeChat, Facebook and others have achieved viral adoption by giving people what they want, being differentiated in some way and having them recommend it. RCS has attempted to force itself on people, with telcos assuming a sense of "network privilege and entitlement".
  • Users like fragmented communications experiences for many reasons - we see people happy with 5, 10 or more "messaging" or social apps, plus an increasing tendency to embed messaging capabilities as a feature into other apps. (Voice & video will follow suit, courtesy of WebRTC)
  • There is no relevance of RCS to the enterprise. It doesn't fit with the way businesses or their employees use mobile devices and corporate applications. (Yes, I'm baffled by the Mitel/Mavenir acquisition, too)
Perhaps the most obvious indicator of failure is the name. Nobody actually wants "richness". Users want the right tool for the job, not an overloaded Swiss Army knife made "rich" with useless gizmos. The name - much like the term "multimedia" in IMS and MMS - epitomises the muddle-headed thinking that went into its conception.  It's rooted in engineers wanting to throw in as much as possible, not designers actually considering how people might behave, and what purposes/contexts they might pursue.

It is notable that WhatsApp added voice (& features like photo-sharing) only after it was already popular for text messages, and its owners could examine user-behaviour, how they used it (and for what), and only then determined what secondary features they might want. Almost all the most successful Internet applications have started out with something simple, and then added on top of it. They are also able to roll back changes, and do large-scale A/B testing on a live audience.

By contrast, RCS has been developed as a rigid, all-singing, all-dancing application with minutely-specified details.

What the industry should have done was take SMS, and make continuous minor tweaks to the application. A better (& cheaper) SMS could have battled its rivals. Context-specific versions of SMS would have made sense, too. Trying to just swap out SMS for RCS will likely make the experience worse, and accelerate the move of users (and developers) to alternative products.

There are dozens of ways to improve the utility and value of SMS. Adding video-sharing isn't one of them. RCS is emphatically NOT the new SMS2.0, despite desperate marketeers trying to suggest it.

A couple of operators' own messaging apps allegedly have RCS as an external interface for others to connect to - but I suspect that's mostly just to tick a box and keep the GSMA's enforcers quiet. I'm not aware that Orange Libon has any active "federation" use, for example. I also think Genband's "fring alliance" attempt to white-label messaging apps to multiple telcos and then allow them to "federate" is an exercise in futility. 

RCS-based app federation is just a way to create a "coalition of the losers".

The way that RCS has been positioned and marketed has been woeful as well.

RCS has had slogans such as "It's just there, it's just works" which have been laughably false, while early deployments - including by multiple operators in some countries (eg South Korea & Spain) have faded rapidly from sight. I wrote a research report in September 2010 about its continued failure.

About 3 years ago, I heard a Metro PCS radio ad while driving in the US saying "try Joyn, the messaging service taking Europe by storm!". I assume that someone subsequently rescued the teacup suffering from bad weather.

I meet virtually nobody in the industry who thinks that RCS anything other than a joke, apart from a couple of tired-looking vendor representatives. Yet most won't say so in public, scared of pointing out the GSMA Emperor's nudity. A few bloggers occasionally put up half-baked "Will RCS finally allow telcos to beat the OTTs?" articles, but that's just as click-bait, and probably half of them hope I'll jump in personally, and start a fight in the comments. 

I see a few vendors still trying to pitch RCS as an API for developers, or adding WebRTC to it in the hope to "extend" it to the browser or other devices. Both are attempts to put lipstick on the pig zombie. The use of RCS for A2P messaging will not happen until there are sufficient users adopting it for P2P. It's doubtful anyone will want to "engage" via a medium their customers are unfamiliar with, or that they think is uncool or clunky.

In my view, the industry needs to stop messing around with RCS, and kill it loudly and clearly. It needs to die with a bang, not a whimper. Someone needs to drive a wooden stake through its heart, then we can "go to the Winchester, have a nice cold pint, and wait for all of this to blow over"

The "reset" can only come with 5G. Rather than wasting yet more time and money with the GSMA's "2020" vision and perpetuating legacy IMS, VoLTE & RCS, the industry needs to start again with a clean sheet. It needs to move towards contextualised communications, where voice/messaging/video is a feature of apps, websites and devices, not just a standalone service. It needs to decouple basic useful protocols from signalling, as in WebRTC. It needs to stop trying to define application behaviour, but leave that to the market.

Operators should pull the plug on all RCS investments now. Stop throwing good money after bad. Put the teams to work on thinking about what future communications could be - not trying to protect the obsolete "interop" models of the past, with clunky, expensive and unwanted new services. Operators needs to work individually - with vendors as and where appropriate, or with Internet/app providers if that makes more sense. They need to understand how and why their customers communicate, and predict how that will change.

The future of communications is about:

  • Context and purpose - help people achieve what they really want
  • Fragmentation & multiplicity
  • Flexibility & agility
  • Design & behaviour
  • Interop & federation only where it makes sense, not by default
  • QoS only where it makes sense, not by default
  • Differentiation
  • Multiple identity domains
  • Security, privacy & control
RCS was already dead in 2008. It's still dead now. Ignore the occasional twitches of its corpse. Instead, focus on the growing seeds of new sources of value in communications.

(As a good start, check out the upcoming Contextual Communications event I'm running with Martin Geddes, on June 15th in London. Details here)

* OK yes, it's 29 quarters since the original announcement, but 28 since I discovered the details. Who's counting.