Some of my current thinking about RCSe / Joyn

I realise that haven't commented on this blog about RCS in a while, although I've had numerous exchanges on Twitter over the past couple of months since the Joyn announcement. I've also had a chance to talk to various operators and vendors, both through general briefings and under-NDA private consulting engagements.

  

So this is a bit of an update on recent thoughts & conversations I've been having. The timing seems appropriate, given that next week there is both a legacy-view IMS conference in Spain, and for real telecoms thought-leadership, my own Future of Voice / Telco-OTT Strategies workshop with Martin Geddes (details here, sign up here).

That said, I'm not going to give away all of my new analysis about RCS in this post, just certain strands - the full story is reserved for my consulting and workshop clients, or paying subscribers to @DApremium on Twitter.

 

If you are interested in a consulting workshop about Joyn/RCSe please get in touch. I am particularly interested in hearing from COOs, CFOs or others having to make investment decisions, who need a counter-argument or "bear case" to set against the position of internal or vendor RCS advocates.

Note: One or two commentators on Twitter have accused me of having confirmation bias (giving disproportionate weight to data that confirms existing beliefs), so I've been very consciously "open-minded" about this whole area. At MWC I made sure I had a couple of Joyn demos without preconception or prejudice, and I seen the official GSMA "pitch" several times at conferences & webinars. Some of my opinions have shifted slightly, but overall I am still broadly negative.

*Sign up for this blog's email list*     *Attend #TelcoOTT / Future of Voice workshops*

Status

It's too early to judge based on results - we've only had Vodafone Spain launch, albeit in a very limited beta/trial fashion (5-10k downloads and very mixed reviews according to Google Play, especially as some comments seem to be from internal VF folk). German operators have talked about May as a target date, and "summer" seems to be the timeframe for a broader European launch. Overall, there have been many delays and slippages - it's interesting to compare each GSMA presenter's charts at conferences with the previous ones to see what dates have moved. France, Italy and South Korea are all allegedly launching in H1'2012 as well - I'm willing to bet that at least one misses that date, especially for a full, all-MNOs, interoperable launch.

That said, one thing that seems to be clear recently is that RCS is being driven very heavily "from the top". There's definitely tighter marketing and messaging. I'm expecting to see IMS conference speeches with "See? We were right all along!" self-congratulatory (and very premature) messages. And to be fair, Joyn as a brand isn't bad, even if some amusing acronyms are possible. 

There's also a sense of urgency and committment which is (just) the right side of desperation. There are a lot more companies with "skin in the game", albeit with different levels of financial imvolvement. (Notably though, most vendors are dual-purposing their solutions for both IMS/RCS and also TelcoOTT-type use cases). The concept of "fake it till you make it" is understandable from a marketing point of view, but the mantra of "it's just there, it just works" is a huge liability, if it isn't/doesn't.

In my view, a better strategy would have been to target RCS at specific niches or use-cases, rather than pretend (against all evidence and realistic expectation) that it's going to suddenly become "ubiquitous".  (I wrote a piece about "the death of ubiquity" a while back). Nobody in the industry believes RCS will be everywhere - and certainly not on a 2-3 year timeframe - so it is credibility-damaging to assert it anyway. Not to mention the increasing share-of-wallet that will accrue to fragmented rather than ubiquitous telecoms services & capabilities.

What's it for? And why will people use it?

There are still very mixed messages about whether RCS is supposed to be a competitor to so-called OTT players, or something else entirely. I've yet to hear a single compelling reason why any existing user of WhatsApp or Kakaotalk or Facebook or BBM would be persuaded to switch to Joyn, and for which use-cases. 

The usual argument seems to be that "not everyone has smartphones" or "not everyone downloads WhatsApp, so this is a service for everyone else". Both of these arguments are completely specious - I cannot think of a single successful technology or service that was driven by late-adopters, especially a communications service which relies on Metcalfe network-effect square/exponential laws, and which is heavily driven by popular individuals as trend-setters or social "hubs". Plus, downloading apps is no longer onerous. Some people even view it as fun. (I suspect a lot of IMS engineers still have old Symbian phones, which might explain a few things).

Put another way - this late-adopters-first approach sounds like an attempt to "cross the chasm", but backwards.

Nevertheless, the force being applied to try to "make RCS a success" is commendable. I've met a number of people from operators recently - even from disruptive Telco-OTT business units - who seem to have had an edict handed down that they MUST have RCS compatibility. That said, it's fair to say I've spoken to a few supposed "converts" who have been singing its praises through gritted teeth.

Attitudes also seem to be different in the US to Europe. 

In Europe, the story is muddled. RCSe is being pitched as an OTT-beater (by some), SMS 2.0 (by others), an easy option for late-adopters without smartphones or Facebook (uh huh) and a variety of other mostly unconvincing stories. There's quite a lot of general skepticism about IMS, and an awareness of awkward practicalities such as 50-90% prepay users who buy phones unlocked without operator apps (and who SIM-swap a lot).

In the US, the approach is about much tighter coupling of RCS to VoLTE, to create a completely new personal communications experience for all-IP mobile networks. There's much more homogeneity in the user base (mostly on long contracts), less fragmentation among service providers, and a mentality that they can make IMS work. [We should see the re-unification of the now-divergent RCSe and full RCS in RCS5.0. At some point].

There's also more emphasis in the US on using RCS as a developer platform. In my view, it's a bigger bet, but a rather more coherent one, especially as 4G has become a marketing issue and the CDMA operators are being forced to LTE anyway. So they really need VoLTE or a VoIP alternative, and thus they seem to think that RCS might as well come along for the ride. Some of the demos and mockups I've seen (eg from Summit and D2) even look quite slick.

But it's also heavily interdependent on other issues - for example, if VoLTE struggles with radio issues (eg voice quality, cell handover or battery consumption) then RCS is tightly coupled and gets delayed as well. LTE outages on Verizon have also been blamed on the IMS core, which doesn't bode well.

Competition is intensifying - and not just from apps

And delay is critical here, because the longer it takes, the greater a foothold Apple, Google, Facebook and others (Microsoft/Skype?) will have. I can't see Apple ever putting a full, native RCS capability in its devices - they might do a server-side cludge via iCloud, but put a new telco comms client (and IMS!) on an iPhone to compete with iMessage and FaceTime, much less a SIM-free WiFi iPad or iPod? No, that seems implausible, especially in the short term.

Google is already allowing Android OEMs to implement RCS and presumably will do its own variants within Motorola (for now), but I'm unconvinced they'd put it in the basic Android build - again, not least because it's used increasingly in non-SIM/non-telco devices like tablets, and it won't want to sideline Google Voice, G+, GTalk, GMail and its various other comms properties.

There's also a sub-story with Google's involvement in WebRTC - it knows that much P2P communications isn't going to remain a "service" or even an "app" for long - it's going to be a simple feature of the browser, and that any service will need to be something provided over and above simple transport of voice, message or video. (WebRTC is a large-but-silent elephant in the communications services room. It'll take a few years to hit mobile in a big way, but has the potential to be the single biggest disruptor for the entire industry).

Facebook's 400m mobile users makes the Joyn story of "it's just there, it just works" look ridiculous already. It's already much more widely available than RCS will ever be (including down to featurephones with Facebook Zero, Java and even USSD / SIM toolkit applications - as well as being on PCs and tablets everywhere). If the telecom industry wants something "ubiquitous" it needs to go well beyond IMS-capable devices.

Then we have Microsoft, BlackBerry and numerous other players, none of which must see RCS as a panacea, even if they are getting arm-twisted into including it in devices by carriers. But if anyone thinks that RIM is going to willingly downplay the BBM experience, or that Windows/Skype messaging is going to be based 100% on an RCS API, they're on a different planet to me. [Edit - some details on WP8 + RCS here]

Developers, developers

Overall, I've got more sympathy for the US RCS approach, because at least there's a consistent story - and, critically, there's a clear developer angle. I think that RCS/RCSe/Joyn has very little chance of success (anywhere) as a messaging app but I can just about buy into the API story, at least in concept if not execution.

  

I can envisage certain B2C use-cases for video-share, such as customer support ("No, connect the wire to that socket"), or perhaps C2C mashups with a map ("I'm in the pub... where are you exactly? Look, I'll just send you a navigation widget"). But the problem with all of these - as with all other telco APIs - is convincing developers that this is the best route to solving the problem, something that is going to get ever-harder as the same features start appearing in HTML5 as well as native app plaforms. And I suspect that HTML5 - and even the telcos' own WAC-type device APIs - will be "just there" and should "just work" at least as well.

(It wouldn't surprise me if the industry tries to somehow tie such device APIs into RCS as part of its work in WAC and W3C - but I really don't expect that to be universal as HTML5 will extend far beyond mobile phones / SIM-enabled devices)

Some of what companies like Solaimes are doing around "thin client" RCS, with the bulk of the work done in the cloud, and just a much lighter app (or browser) on the device makes sense, especially as it makes it easier to do RCS-as-OTT implementations - something I think is critical if it's to succeed at  all. I'm less convinced that the phonebook / contact-list is where you would want to anchor such services on the phone, though.

OTT-RCS

One of the biggest failings of the current crop of RCSe concepts is tying the app to the SIM card - firstly because many devices don't have SIMs, and secondly because there needs to be the ability to download 3rd-party apps onto phones running on networks which haven't signed up. (eg a Vodafone Joyn app on a 3UK phone).

Increasingly,  people will also have multiple connected devices, and will start to want the same experience on all of them. If I've got a Vodafone SIM in my iPhone, an Orange one in my tablet, an unlocked MiFi with various national SIMs, a PC on WiFi, an MVNO-powered smart-grid electricity gadget, and a dual-SIM Android for travelling, I won't want to have a dozen separate RCS accounts. And that's even before I try porting them when I churn.

RCS is already usable over WiFi, so it will have to be OTT at least some of the time, especially on devices that don't have a SIM card. So that begs the question - why not have it OTT all of the time?

Interconnect

This plays into a critical theme. What's the interconnect business model (between operators) for RCS/Joyn? It's not something I've heard discussed openly anywhere.

Does an operator "terminating" messages or video-sharing get paid by the "originator"? On what basis? And if I start a chat with another person, but *they* upgrade the session to video or sharing, who's the originator anyway? Or is RCS going to be a "bill and keep" service where there is no commercial arrangement? How does it change for OTT-style RCS?

It could be that the reason I haven't heard anything is because RCS is going to be free at retail in perpetuity - and therefore will also be free between operators, so interconnect billing isn't needed. But that would be most unlike any other area of the telecoms industry, which mostly hasn't even been able to grasp the idea of "freemium" to any extent.

It's notable that some of the smaller European operators seem to be the most skeptical of RCSe, and I wonder if that's because they're worried that they become "net exporters" and end up having to pay out cash, just to deliver a service they can't even monetise directly with end-users.

In any case, re-hacking the wholesale billing and mediation side of operators' IT stack to handle RCS can't be too palatable for many, especially if they're currently in the middle of a transformation/upgrade cycle anyway. Add in dealing with RCS in the network policy and charging (eg how do you treat the "OTT" bits of RCSe traffic when it's sent to/from a PC?) and it becomes an even more expensive exercise.


International

The assumption behind Joyn is that the main use-case is similar to SMS - domestic peer-to-peer messaging between friends, for example. While that's also true for a lot of BlackBerry BBM use and (in certain countries) WhatsApp and some other Internet services, it's much less true for platforms like Skype which have a large international component.

Because RCS will only get adopted slowly (I think it will be doing very well if it achieves over 2% global active use, or over 10% for any country/operators, by end-2014) its uptake is likely to be much more community driven, or by specific niche use-cases. It will take a long time (if ever) to be expected to be available as a default by users.

One group that needs to be addressed, if RCS is really going to compete with Internet peers, is the international user base. Firstly: does it work, and secondly, does it cost extra? This brings the interconnect question right back to centre stage. To use an example, a friend of mine in London currently uses WhatsApp primarily to chat and exchange videos/photos/links with her girlfriend who's studying in the US (with a local US SIM). Alternatively, they use Skype for long calls or videocalls. The alternative - paid per-message international SMS or IDD voice - is clearly not a viable option.

Will RCS make any different to that scenario, where perhaps one user is on Orange, and the other on AT&T? Neither telco will want to risk cannibalising IDD telephony and international SMS revenues today, so can they construct a mechanism to allow Joyn-type apps to compete for that use case? If not, they can't expect RCS to be a realistic competitor to WhatsApp, Skype and its peers: "free IM... as long as your buddies aren't abroad" is a poor fit with user expectations.


Summary
 
As I noted above, this is a snapshot of my current thinking, on a few areas that RCS/RCSe/Joyn needs to address.  Overall, the technology is starting to look a bit more like a complete proposition, but it was already much too little, too late at end-2011 and it's now even later.

In 2012 we've already had Instagram annointed as "the next big thing", we've seen new services like Pinterest spring up as flavour of the month, and only yesterday I heard about astonishingly fast viral growth to 30m users of "Line" a new Japanese messaging app. It's added 20m just in the extra time that RCS launch in Spain has been delayed.

The idea that RCSe will be a "Top 10" success against such a fast-moving competitive background is improbable - and even if it does, getting beyond a short-term "one-hit-wonder" must have lottery-scale odds. I really can't see how it might stay the favoured, coolest messaging app given the furious pace of evolution by startups who actually employ designers and behavioural psychologists, and who can roll out an updated version tomorrow.

There is a (small) chance that RCS might evolve to be the next "lowest common denominator"  communications platform alongside telephony, SMS, email and postal services. But even if it does, it's far from clear that such ubiquitous forms of communication can retain more than a tiny fraction of today's telecom market - especially as WebRTC takes hold. Every user is building their favoured personal "wardrobe" of fashionable communications services. The share-of-wallet of the telecoms equivalent of basic, proletarian Marks & Spencer underpants isn't going to be very high.

I'm running out of terms for RCS - I've used "dead" and "zombie" already in the past. So I think I'll just stick with "inanimate". It's still not moving, and it's certainly not capable of running after its competition with much vigour.


*Sign up for this blog's email list*     *Attend #TelcoOTT / Future of Voice workshops*

Which operator app-level collaborations actually work?

*Sign up for this blog's email list*     *Attend #TelcoOTT / Future of Voice workshops*

I've just been having an email exchange with a client about telco collaborations.

The net result is a question I'm struggling with - have any recent multi-telco collaborations at the app or service level actually borne fruit?

There have been plenty of trials, initiatives, and pilots. WAC, OneAPI, in-country attempts at collaborative payment platforms (eg PayForIt in the UK), API exposure (eg in Canada) or IM connectivity (various).... but I'm struggling to think of anything new that has proven substantive so far.

The possible exceptions are for M2M (which is still quite slow-moving & actually involves a lot of in-the-network techniness rather than app skills), and a few security-type things like content-filtering for kids, alerts (eg tsunami warnings), or stolen-phone disablement, which are often driven by regulators anyway.

SMS, MMS and roaming don't count as they're all old, albeit with a few modern tweaks like roaming steering or local partnerships. But that's not app/service level really anyway.

Various collaborations between operators and non-operators are successful (eg 3UK/Skype, initial AT&T/Apple, Facebook Zero + various).

Yes, there's a bunch of new stuff just starting - Joyn/RCSe, payment collaborations in various places like New Zealand, identity stuff, talk about federating telco CDNs and so on.

But are there any recent examples of these type of collaborative arrangements actually working?

(Note: this isn't a "bash the operators" post - I'm genuinely interested in hearing of examples that have worked, because off the top of my head I can't think of any. And if they've all failed... what lessons have been learned so that the new ones might succeed?)

*Sign up for this blog's email list*     *Attend #TelcoOTT / Future of Voice workshops* 

London Telco-OTT & Future of Voice workshops April 26-27

Coming up in 3 weeks' time is the next of my & Martin Geddes' workshops on the Future of Voice (and messaging), in Mayfair in Central London. 

This time around, however, we're running two days rather than one - bookable separately or together. The first day is FoV, but the second is the first workshop specifically on Telco-OTT services, as covered in my recent report.

There's a lot of rhetoric about how operators should "deal with OTT", but I'm the only person to publish and speak specifically about how operators can and should become OTT players themselves. I've examined more than 100 different telco Internet-based offers, spanning a wide variety of service segments, and have advised operators around the world on opportunities and risks.
 
As before, these are small, interactive workshops - not just hours of slides. With a maximum of 25 attendees, there will be break-out group exercises, Q&A sessions with Martin & myself, roundtable debate and plenty of opportunities for networking. We carefully curate the attendees, to give a mix of operators (incumbent & challenger), vendors of different types, developers, consultants and sometimes regulators and investors.

The cost per delegate is £700 for one day, or £1000 for both days, plus 20% UK VAT.

(Also, if you're interested in attending / sponsoring a US TelcoOTT/FoV event in May or June, please get in touch with me)

Future of Voice

Day 1 (April 26th) is an evolution of our previous workshop format on the evolution of telephony, voice services, new communications business models and hot topics around personal connectivity and interaction. It spans everything from underlying psychology (why do people make phone calls? what are the fundamental drivers that determine why we want to connect with each other?) to the evolving nature of voice "beyond the phone call". It considers concepts such as:

- Peak Telephony
- Free, Freemium and Less-than-Free business models
- Why "voice" and "telephony" are not the same thing
- Personal portfolios of voice & messaging
- The slow death of standards & interoperability
- VoLTE & RCS / RCSe (including thoughts on Joyn)
- APIs and developer initiatives around VoIP & communications
- "Cloud voice"
- Operator innovation around voice
- Thoughts on regulation, interconnect & fixed VoIP

More detail and registration can be found here



Telco-OTT strategies & services

Day 2 (April 27th) is the first public workshop on Telco-OTT services. I'll cover some of the key themes explored in my recent report, plus additional insights gleaned in recent months of engagement with various clients, plus meetings at MWC and other events. It will span fixed and mobile OTT services, from mobile VoIP to online video, and from femtocells to cloud SaaS.

- History of Telco-OTT (there's a surprising amount!)
- The import / export model for telcos
- Death of Ubiquity: Why OTT is inevitable for operators
- Segmentation of Telco-OTT (comms, content, cloud, connectivity)
- Technology enablers & platforms
- Specific analysis of Telco-OTT VoIP & messaging services
- Partnering with Internet-OTT players vs. developing own-brand operator services
- Build vs. buy vs. acquire
- Case studies - success, failure & innovation
- Organisational & operational challenges for telco-OTT
- Implications for investors, regulators & industry bodies
- Round-up of vendors and operators' activities on Telco-OTT

Please get in touch with me if you'd like more details, or to book a place for one or both days. (information AT disruptive-analysis DOT com) or online booking via Amiando here

Operator WiFi: Seamless is the wrong approach

*Sign up for this blog's email list*     *Attend #TelcoOTT / Future of Voice workshops*

As well as #TelcoOTT services and voice & messaging, many of my meetings over the last month or two have been about WiFi - specifically, its evolution as a carrier-driven technology for offload and other purposes. I've been speaking with various operators, vendors and industry associations. I also participated in a recent webinar (sponsored by iPass, a client of mine) about this theme.

There appear to be two broad trends:

1) There is massive operator interest in large-scale WiFi deployments - for example, the Chinese operators, KDDI in Japan and various players in North America
2) However, there is also massive confusion and naivety about exactly how WiFi is going to be controlled, especially in terms of the user experience from the handset

There seem to be various underlying causes of this confusion:

1) Market participants from the cellular side of the industry are mistakenly assuming that "offload" is the only, or most important, use of WiFi on a handset - often without a decent definition of what offload actually means.
2) Some market participants know that there are multiple use-cases for WiFi, but are actually engaged in trying to subvert this so that their needs and requirements are better-served than those of end-users.

The problems can be largely summed up with a single word: "seamless". The cellular industry has an unhealthy obsession with getting rid of "seams", not understanding that sometimes they are valuable and worth keeping (or even worth adding deliberately).

Sometimes, seamless is good - for example, when a mobile phone user is moving and moves from one cell-tower to the next mid-call, without noticing. Having your phone automatically hook up to WiFi when you get home is good too.

But in other cases, seamlessness is a mixed blessing - for example in the case of international roaming. While it undeniably convenient at one level for handsets to transparently connect to a visited network, the downside is that this can lead to "bill shock", anticompetitive pricing or conditions - especially for the dark art of data roaming. This is why the European Commission is currently trying to re-introduce seams, potentially allowing users to select a separate roaming provider to their home operator. It is also why so many users create their own seam - switching off data roaming entirely.

And finally, there are times when seamless connection is outright bad - for example, if a device is "forced" to use a specific network, when the user or perhaps an app would prefer a different one. This is especially relevant for WiFi, where there are frequently various options for connection, with different ownership, speed, price, security and features. Most WiFi use is private connectivity (it's WLAN - ie wireless ethernet), not offload, and operators have no business becoming involved in it.
 
Think about an iPhone versus an iPod Touch. Any WiFi use on the iPod is by definition private - it can't be offload as it doesn't have a cellular radio to offload from. Therefore the same use on an iPhone should also be considered as private WiFi access, not offload, and outside of telco visibility and control.

Some of the proposed standards even suggest switching on the device WiFi non-consensually by the network (see this post of mine about OMA), while others such as the 3GPP's ANDSF tries to push or enforce preferences for network selection.

While for certain use-cases this might be beneficial (eg a Kindle-type device connecting to WiFi in the background, with no user intervention), in other cases it will lead to a significant restriction in user freedoms, and may directly inhibit some innovative business models. For example, O2 UK is exploring an onload model for WiFi, aiming to capture users from other network operators, rather than offloading its own subscribers' cellular traffic. There is plenty of scope for conflict where the device (and its SIM-driven seamless connection policies) contradict an app the user has empowered to make its own WiFi decisions.

Another angle on seamlessness comes from a venue-owners' perspective. Imagine that you run a cafe, with WiFi available for customers as perk (pun, apologies!) for their patronage. Your customers like it, some of them connect their phones or laptops, and come back regularly for coffee. Others ignore the WiFi sign for various reasons - perhaps because they are chatting rather than browsing Facebook or doing Skype video calls. Now imagine the same cafe with seamless WiFi. All customers' phones connect automatically. The net result is congestion - users get a poor experience, the cafe owner needs to upgrade the broadband connection, and meanwhile the atmosphere of the venue changes as people spend more time on their phones than with their friends. That is not a positive outcome for seamlessness and automated WiFi log-on. In some cases a little friction is a *positive* for loyalty and promotion - it gives the marketeer a better image of customer-friendliness, while limiting their extra capex/opex. The same is true of airline frequent flyer schemes, which gain loyalty despite the fact it can be hard to actually redeem points for flights.

There are also other insidious aspects here - various vendors I've spoken to have products that can monitor a user's entire handset WiFi experience, tracking which access points you connect to, perhaps enforcing policies even where those APs are not operator-owned or -affiliated. While there are some corner-case exceptions here (eg the perennial content-control for kids use case), this is not acceptable for massmarket use. Indeed, for many enterprises, an attempt by a carrier to check up on private WiFi use could constitute an unacceptable security breach.

Overall, many of the operators and standards bodies involved in carrier WiFi need to go back to the drawing board and start again. Their connection-management designs need to recognise that seams must sometimes remain visible to users, or applications acting on their behalf.

Another way to think about it is that seam=border . And borders can be crossed in many ways - a simple signpost by the roadside (eg in Schengen Europe), basic passport checks, more involved arrival cards, paid visas, deliberate illegal entry (smuggling). Or you can be taken across against your will, blindfolded in the back of a van.

Personally, I don't want my WiFi "trafficked" across borders without my consent. Seamless WiFi has its uses, but it should not be viewed as a universal target or "obvious truth" by the cellular industry.

*Sign up for this blog's email list*     *Attend #TelcoOTT / Future of Voice workshops*