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

Sunday, December 27, 2015

New Year Rant: 10 Awful Tech-Industry Terms to Stop Using in 2016

In the spirit of the holiday season and New Year, this is another list about 2016. 

But it's from me, so it's a rant, rather than clairvoyancy with a crystal-ball.

There's a bunch of words and concepts used in the technology industry that make you look like a fool, or at least lazy and sloppy. They're often meaningless, duplicitously-used to "misframe" an argument, or just generally cringe-worthy. Some of them I've tackled before, and yes, mea culpa, I've been guilty of some of them before too. But I've learned from the errors of the past, and apologise unreservedly for any historical fluffiness and telcowash.

So let's double-check our terminology in 2016, call out offenders, and make a collective New Year resolution to ditch the telco-industry b*llocks....




1. Digital 

Meaningless drivel. The last time the word "digital" was informative or cool was in the 1970s, or maybe, if you absolutely must, relevant for newer telecoms switches in the 1980s. But apart from retro nods to Casio, it's now just a useful short-cut to determining if someone is ignorant, tech-illiterate, or desperate for a marketing hook - think "digital agency" as cringespeak for advertising, or "digital single market" for the EU's half-witted bureaucrats and their fawning legions of lobbyists. 

And don't get me started on the clueless telco and vendor folk talking about "digital" services. Because hey, we don't want to go back to those awful days of the analogue Internet in the 1990s, do we? I suppose I should be happy that at least some of the politicos have switched over from the similarly-execrable "ICT", but frankly "digital" is even worse. So sneer at the digitalistas with both pride and prejudice – and perhaps a raised middle-digit.


2. OTT 

This one I've tackled before, but it bears repetition. "OTT" just means "bits of the Internet we don't like". It's arbitrary, divisive and hypocritical (all telcos have websites & Internet apps). It’s also a form of telecom industry self-harm, as the "O" for "over" conjures images of a vertical hierarchy, with content/apps/comms being at the top (and therefore implicitly better) than everything "beneath". Along with “dumb pipe” the false-dichotomy of ISP vs. OTT is at the base of many of the industry’s current woes, as it re-frames a simple reality in a deliberately antagonistic way. Telecoms industry regulators and lobbyists who use “OTT” are especially unfit-for-purpose, and should be fired for incompetence.

There is an exemption for anyone saying “OTT” if they also refer to networks as “UTF” (Under the Floor) providers, as that’s where the plumbing goes.


3. Transformation 

I have a little bit more tolerance of this word, as it is slightly better than some of the industry’s other gibberish. Elements of the industry are undergoing profound change, yes… but that’s mostly being forced by events, with grudging acceptance, rather than true enthusiasm. Even where networks are genuinely being “transformed”, it is rare that the culture, process and business model is following suit. More generally, it’s important to note that telcos, and their networks and services, have been in a state of constant flux for the last century, often with discontinuities in technology.

Either way, the only meaningful use of the word "transform" I've heard this year was by my Haitian guide when I visited in July - to describe a voodoo curse which he reckoned was turning him into a cow. To listen to some of the snake-oil merchants in the telecoms industry, you'd think we were watching something similarly magical occurring, rather than just mythology.


4. Seamless 


Another one I’ve taken aim at before – seams are important. Seams are borders, where important things happen. Pretending that they don’t exist denies their significance – and can lead to mistakes or complacency, in terms of user perception, technical capabilities, pricing, security and more. A prime example is the combination of WiFi and cellular connectivity for smartphones, where two very different domains exist, and blending them needs to be done with care and humility. Creating frictionless shifts between one and the other is important – much like real-world borders. But the premise of “seamlessness” removes visibility and agency from end-users and other market participants – and often presupposes (wrongly) that network operators are the only/most-important actors involved. Seamless transitions allow inertia and lock-in to be perpetuated, rather than allowing users or app-developers scope to make “wrong” decisions.


5. Carrier-grade 

This is another term which exemplifies the telecom industry’s arrogance and self-absorption. It imbues certain bits of infrastructure – or engineering practices – with a magical aura of uniqueness and competence. And while many examples are indeed praise-worthy, they are far from the only purveyors of excellent network engineering. Corporate-grade networks are often just as secure, resilient and cost-effective – but also often more flexible. Military-grade networks are often more secure. Consumer-grade networks or various ad-hoc networks are often more democratic and market-responsive. Internet-grade networks such as Google/Facebook data-centres or Akamai’s CDNs are often cleverer. 

Telecoms carriers are not “special flowers” nor sit in “ivory towers”. Continually using terms like “carrier-grade” perpetuates the arbitrary distinctions between telecom and Internet worlds, and fosters harmful distinctions that inhibit service-providers from making pragmatic, market-aware decisions.


6. Engagement 

This is not limited to the telecoms industry, but is a general example of horrific marketing-industry and social-networking semantics and practice that needs to be stamped out. “Engagement” usually involves forcing people to “interact” when they’d often rather not, or measuring social-network actions in a cringe-worthy fashion. My recent example of WiFi “monetisation” charlatans bragging of “engaging” users for 45 seconds highlights the misanthropy present in this way of thinking. The whole area of “click-bait” posts, or those stupid list-based websites that force you to find the “next page” button, or click an invisible “x” on an intrusive floating advert are others.

This is not to say that it’s a bad thing to allow people to interact with you. Yes, they should be able to comment or share if they choose. But that’s the point: they are choosing to interact. They have agency, and take action. They should not be encouraged or forced to “engage”. It’s the coercivity that is wrong.


7. Content (& especially content-marketing)

“Content” is just one-directional application data, which flows from a “publisher” to a “consumer”. Despite some commentators’ and legislators’ ignorant comments, it does not constitute the whole Internet. While the likes of Netflix and the BBC are clearly important, so too are Amazon, Twitter, Skype, SAP, email, backups to iCloud, downloaded virus definitions and innumerable enterprise applications and services. The latter are communications, transactions, applications and raw data – not “content”. Yet too many laws and structures are designed with an historical “media” mindset, rather than an IT or Internet-native one. For example, the majority of the Net Neutrality discussion was centred on “content” and “content provdiers” – although to be fair, some regulators have talked about “edge providers”, which is a slightly more generic term.

Hopefully the rise of ever more non-content mobile apps, plus also IoT devices and traffic, will make more people (especially regulators and politicians) aware that networks are used for much more than lumps of video entertainment, media websites and music. 

To be honest, “content” is mostly another sleazy, marketing-inspired word anyway – often used with a hidden meaning of “that stuff we can embed advertising in”. That also gives rise to the most repugnant use of the term – in “content marketing”, which is basically just “long-form spam”, often masquerading as journalism or analysis. The technology industry is widely infested with dodgy “content marketing” – particularly corporate blogs masquerading as independent sources of news or analysis. You know the type: one-sided puff-pieces which laud a particular type of technology or product or brand. “Why WiFi-calling is transformational & will change telecoms for ever and allow operators to fight back against the OTTs with new digital services and improved customer engagement” (posted on WiFiCallingForEver.com, with a tiny note at the bottom that it’s sponsored by VendorX.com). The worst content-marketing of all is that derived from fake, quasi-corrupt, pay-for-play industry “awards”, where marketing companies offer “sponsors” a full package of PR and churnalism “content” in exchange for a “submission fee”.


8. Rich 

Obviously exemplified by the ludicrous RCS of zombie fame, the word “rich” also crops up in various other telecom and Internet contexts as well. It usually means “we didn’t have any proper designers involved, so we just threw in as many random features as we could, hoping that people would muddle through and ignore the incoherent clutter”. I don’t think I’ve ever seen Apple use the word – or even Facebook. I’m scared to look, but it wouldn’t surprise me if Yahoo or LinkedIn have used it, though. Rich services or apps don’t even have the redeeming benefits of rich food – they’re unpalatable as well, as bad for you.

Applications should be right not rich.


9. End-to-end

Whenever you see anyone in the telecom talking about “end-to-end” capabilities – especially QoS – you should laugh and dismiss them and their products/services immediately. In almost every case, the so-called “ends” just refer to arbitrary points over which they have some modicum of visibility and control. They are never the actual ends where a service is generated or consumed, just points on an architecture diagram where somebody else takes over responsibility. So for a streamed video, there are origination servers (perhaps even the production, editing and encoding process) and the end-device, with screen and associated processors and memory. Quality of experience ends at the retina, the eardrum – and maybe even the cortex of the brain. A great example of the end-to-end fallacy is around VoIP, where much of the quality and performance is gated by the device’s silicon and its microphone and speakers, as well as the various processing algorithms used. The network is important – and bits of it may indeed be well-managed. But they’re not “ends”. 

I’m writing this in an airport, where BA takes responsibility for getting me from gate to gate. It conspicuously doesn’t refer to my journey “end-to-end”. The handful of airlines which offer limo-service  to and from your home and hotel would have a better claim – but even they can’t control the traffic on the roads outside Heathrow, just the seat you sit in. 


10. Ecosystem

This is the term beloved of people who used to say “value chain”, especially as it allows a temporary warm & fuzzy feeling from its environmental and natural background. But for that very reason, it’s a lousy analogy. Ecosystems aren’t “built”, they evolve. It means a group of interacting organisms AND their (physical) environment and resources. It implies co-dependency – if one part of an ecosystem gets removed, damaged or destroyed, it has an impact on everything else. It’s not just a convenient term for a software or web company’s developer and partner programme.

While real ecosystems might have some symbiosis, they also typically have an apex predator, plus lots of unfortunate other creatures and plants that get eaten, or just manage to scratch a living, before rotting after their death with the help of microbes and parasites. Hmm, maybe it is a decent analogy after all. I’ll leave it to the reader to identify the parasites in the mobile “ecosystem”.


Summary

So let’s have a collective New Year’s resolution to avoid telecoms-sector “trigger words” and acknowledge what we actually mean in 2016. Let’s get rid of:



  • Digital
  • OTT
  • Transformation
  • Seamless
  • Carrier-Grade
  • Engagement
  • Content
  • Rich
  • End-to-End
  • Ecosystem


And, I’m sad to admit, there’s also probably a number 11 that’s past it’s sell-by: “Disruptive”. But yeah, let’s forget about that one, given that I was disruptive before it went mainstream. I reckon I can claim some form of retro-irony exemption…

Rant over. 

Happy New Year!




Thursday, December 17, 2015

Communications apps, APIs & integrations: Import vs. Export models

There is a huge and growing interest in blending communications apps/services with other software capabilities. We are moving from a world of standalone voice, video and messaging to a range of contextualised, workstream-based and embedded alternatives.

But there are two very distinct philosophies emerging for app/comms integration:


  • Export: this involves extending communications capabilities out from a central system (phone system, UC, messaging app, videoconferencing etc) into other applications or websites via APIs, or by offering granular service-components (eg WebRTC gateway, transcoding, recording etc) via a PaaS approach. Numerous examples exist, from
    • Vendors (eg Unify's Circuit APIs, Genband Kandy, Xura Forge, Cisco Tropo, ALU's Rapport APIs, BroadSoft, Vidyo etc)
    • Dedicated PaaS providers (eg Twilio, SightCall, Temasys) or niche specialists such as Voxbone (which does numbering for example)  
    • Telcos' API platforms, which may be network-integrated like AT&T's Developer Platform, standalone PaaS like Telefonica Toxbox, or even just web-embeddable objects like Telenor appear.in
  • Import: this involves treating the communications application or service as the user's primary experience, and bringing in other applications as "integrations" or mini-apps. These can be other communications tools (eg WebRTC video windows in a messaging app) or other functions (eg social or process-based integrations). This particularly fits with the "timeline" or "workstream" model, or perhaps a "dashboard". Examples exist in a number of areas:
    • Enterprise is moving towards "workstream collaboration and communications" (WCC) apps, such as Slack, Cisco Spark, Unify Circuit and various others which can embed external services into a timeline. BroadSoft's Tempo concept looks more like a dashboard model than a timeline, but also brings in sources like DropBox.
    • Consumers are moving towards "Messaging as a Platform" apps, notably in Asia with WeChat, which embeds mini-apps such as taxi-ordering into the message stream. Facebook is taking Messenger in the same direction, and even telcos want to replicate this - Deutsche Telekom is trying to reinvent RCS to take it in that direction, for example.
The API-led "export" model has been the primary trend in WebRTC, SMS and telcos' network/IMS strategies in recent years. We hear a lot about the "consumption" of APIs, "embedding" of communications or the "exposure" of a core system. It is definitely growing rapidly, in numerous guises. Click-to-call buttons embedded in websites or apps are a typical manifestation. (Video below is embedding AT&T capability into Plantronics' website)




But the success of apps such as Slack and WeChat have led to a resurgence of the idea of "unifying" communications, or using a "hub" approach, where a messaging/voice/video app becomes the central anchor of a user's "online life", either as a dedicated application or browser home-page.



Some vendors are trying both approaches - Unify and Cisco seem to be looking at both import and export models. It might be where Google is intending to take Jibe along with telcos and Android as well. Some UCaaS players seem to be taking a similar path (eg with ThinkingPhones acquisition of Fuze) as well as WCC specialists like Atlassian's HipChat.

Others are taking different angles - Microsoft seems to be using Office 365 as the anchor, importing its own Skype4Business UC application as well as maybe others in future, probably via ORTC. I suspect it will "export" more communications as well, in future. Apple (as usual) is different, still using iOS as its main platform for very selective import of a few comms/social tools such as Facebook and Twitter, and largely avoiding any export models at all. (There is no way to embed FaceTime or iMessage in a website, for example). Apple also tends to dislike apps acting as subsidiary platforms on mobile, especially if there are payments involved.

It is too early - and too polarised - to determine whether import or export will be most significant, and for which use-cases and customer segments. We may see different "balances of payments" for different vendors and service providers. However, there are a number of early conclusions to draw:

  • Import models need a good and usable / well-liked core product, before they can become a platform
  • Export models need the right "raw ingredients", eg simple video or SMS APIs, with the right (typically freemium) commercial model to attract developers
  • Import models tend to work best with a core that is text/timeline-based, ie non-realtime
  • There is a risk that some import models appear as "arrogant": I can imagine some users thinking "What, you expect me to spend the core of my day in your app?! You must be joking"
  • Export models face a lot of competition - external developers have many APIs to choose from, or can implement their own capabilities from scratch.
  • Import models involve competition between comms tools and other apps as the "anchor" - eg a UC tool, vs. social networks, or an Office/Google Apps suite as hub, or major enterprise products like SAP/Salesforce, or a vertical-specific platform like a medical practice-management app.
  • Import and export approaches often vary in implementation between Android, iOS, Windows and native chipset-level
  • Telcos have been trying export models for a long time, with limited success. Often, 3rd party platforms that act as aggregators / or "export agents". Cable / IPTV companies are closer to the import model as they own the set-top box interface to "on-board" other solutions
  • We might see NFV / VNF architectures helping with telco-grade import & export in future, but for communications services it's still a long way off
  • Mobile app usage tends to be fragmented. With the notable exception of WeChat, it's not clear that a full import model works well with the app paradigm on smartphones. That said, we may see greater cross-linkage between apps in future.
  • Certain groups of knowledge-workers may be more well-suited to "import" comms apps, especially if they are either communications-primary users (eg call centre agents) or heavily-collaborating teams.
  • Design skills are paramount throughout, for integrations to be usable. 
  • We will see some "importers" acquiring companies to extend the core app functions. Slack/Screenhero is a good example. This may compete with some 3rd-parties' integrations, but may also make life easier for iOS appstore approvals.
  • Both import and export models make life much harder for network policy-management (or industry regulation) as mashups are by their nature hard to pigeon-hole. 
  • Every export implicitly also means an import from the other side - sometimes into "product", but in many ways horizontal apps such as SAP and Saleforce are turning into full import platforms in their own right, especially where they support multiple communications integrations.
I think that 2016 is going to see some epic battles between import and export philosophies for communications in general, and WebRTC in particular. The shift of communications to the cloud facilitates both directions. Worth watching very closely indeed.

Stop Press: just as I was about to publish, I read that Facebook is trialling Uber-in-Messenger, as part of its "Transportation on Messenger" initiative. This is a great example of an import model, and "messaging as a platform". Details are here.

Wednesday, December 09, 2015

Contextual communications - using device sensors as context

There are two main definitions of contextual communications that I encounter:


  • Communications ina context (ie in-app or in-website)
  • Communications using contextual data (ie what you're doing, or inferred/analysed information about the communications session)
A lot of the discussion in telecoms and WebRTC circles is about the first one - extending voice/video/realtime data uses, by embedding them into web pages or native mobile apps. These could be anything from video-chat in a banking app, to realtime voice chat in a game, or extending a corporate videoconference system to guests. This has many clear and obvious vector for innovation and value.

But the other dimension is perhaps slightly harder to grasp - using contextual data to improve a communications session in some way. Some examples are fairly straightforward - for example letting a contact centre agent know which page you were on when you hit "click to call", or do a database lookup: ("Ah, Mr Bubley, I see you were looking at flights to Singapore. Thank you for being a frequent flyer - would you like to redeem your miles, as the system shows that you have enough?"). 

That type of use is still in its infancy, and has a huge potential not just for customer service / call-centres, but also social network/comms, and enterprise UC/WCC implementations - as well as countless other niche software and web applications in consumer, telecom and business realms. Using contextual data during a call or conference or other session can meaningfully improve the "outcome" - whether that's making a sale, making a complaint, or working out how to meet up with friends.

But another area is less obvious - using contextual data from sensors as part of a voice/video session, to improve the interaction in some way. I've come across two examples in the past week:


  • Talklessnow.com using the mic & your speaking patterns to tell you if you're dominating the conversation too much, or gabbling.
  • Talko.com using motion-sensors in a phone, to allow callers to make better decisions about how/when to interact with you
The first one is a demo, not a full product, based on the idea that the microphone in a PC or smartphone is actually a general-purpose audio sensor. It's a project that's been driven by Chris Koehncke, and developed by &yet under the capable guidance of Philipp “fippo” Hancke, although the original idea came from me, which I then discussed over a beer in SF with Chris in October. My original vision was for this to be implemented in a wearable - so for example, a conference presenter could get a vibrating alert that he or she is talking too fast, and get a reminder to slow down, and add pauses. As Chris discusses on his post (here), when added to a browser it's also suitable for salespeople and others who really ought to be listening more and talking less.

 

There's many other use-cases for what's basically a simple idea - using the microphone as a sensor, answering questions like "how much of the time is sound coming in?" or "how fast is the person speaking compared to the pauses between words & sentences?". This is obviously different to the normal use of a mic, which is to actually capture and encode the content. This is more like audio metadata, which can then be applied to the logic of the communications application itself - whether that's a sales tool, or perhaps a conferences-speech coaching app.

I'm really excited by this - as it illustrates perfectly how a voice-app idea can go from a casual discussion in a bar to reality (or at least, proof of concept), with very little pain. I'm not sure exactly how much time Fippo and his team spent on this - but it wasn't a huge project. It's also only using one of the WebRTC APIs (to access the mic) so it's not hugely sophisticated, but that doesn't matter. It's the results and opportunities and services that are the point here.

The other example of sensor use + context + WebRTC is from a company I've talked about before - Ray Ozzie's Talko. This is a mobile collaboration app for teams, that blends one-way voice messages, text messages, two-way calls etc. into recorded and conversations-specific timelines.

I just reinstalled it on a new phone, and was interested in the permission it requested to get access to my iPhone's motion API, "so that, for example, others may choose not to disturb you while you're driving". Firstly it's great UI/UX design for an app to illustrate why it wants access to an API - it allows the user to make a more informed decision about privacy ad security. But more importantly, it's a great way to improve the communication experience.



Basically, the current concept of "presence" in IM is broken. "Offline" is usually a lie meaning "Don't talk to me". "Online" is usually a lie meaning "I forgot to reset my status" and so on. But by using the phone's sensors and APIs it's possible to get more useful presence indicators: "Dean is driving"; "Dean is at the airport and running"; "Dean's phone is on charge and in a timezone where it's 3am".

All of these are important contextual inputs for either the application, or the other people using it - to decide whether to interrupt you, initiate a "call" or send a message, and so forth. If the desired outcome is a successful collaboration, without unnecessarily disturbing people at the wrong times, this is a huge positive.

These are both comparatively simple examples of using available contextual data in new ways, to enhance a given instance of communications. This is where the value is in future for the telecom industry: not minutes, not filling in coverage gaps with WiFi, but actually helping voice/video become more useful and fulfil the actual user needs and purposes involved. But to do that, you need to have insight into specific problems that need to be solved for the user - whether that's dramatic pauses.......... in a conference speech, or avoiding interrupting someone while they're navigating Hyde Park Corner.

(There's a lot of other potential uses for this general idea, and various possible extensions, enhancements and integrations for Talklessnow and similar concepts. Get in touch with me if you'd like to discuss them, or if you want to arrange a speech or workshop about contextual communications more generally - information AT disruptive-analysis DOT com)


Wednesday, November 25, 2015

WiFi: Seamless is useless, but wide seams are horrible



In the last week I’ve attended and spoken at two WiFi conferences (both in Amsterdam, oddly). WiFi has also been a regular topic at other events recently, both in terms of access (eg SoftBank’s offload strategy) and applications (eg WiFi-calling and also more interesting/innovative telco VoWiFi apps like Orange Libon).

In the past, I’ve criticised the cellular industry for trying to subvert WiFi, as well as attempting massive over-reach in trying to create converged WiFi/cellular services, diminishing users’ choice and control over WiFi (see here).

But my recent learning has been that the mobile operators are not the only “bad actors” trying to undermine the utility of WiFi. A wide range of other companies are pitching ever-more-intrusive approaches to the “monetisation” of WiFi.

Both groups are pushing the boundaries of acceptability, from the point of view of users or other stakeholders. The former are attempting to create “seamless” networks, ignoring the importance and value of “seams” (aka boundaries) to many participants (link: such as venue owners). And some of the latter group are trying to create heavy, ugly, unnecessary seams – often with duplicitous words like “engagement”, when a more accurate term would be “grudgingly-accepted interruption & privacy invasion”.

Let’s try a thought experiment first. Next time you use the bathroom in a hotel or restaurant, consider two options:

1)     Imagine that before using the bathroom, you had to watch a 30-second video, download an app, or navigate various advertising and promotion menus. Various intrusive data would be collected about you to help better-target the adverts in future, and you might be asked to log in and like the bathroom on Facebook.
2)     Imagine instead that you could instantly access the bathroom, but only because you pre-identified yourself with your home water company’s customer number. For now, it’s free – but you’ve heard that some water companies are now starting to charge “roaming” fees for public bathrooms even if they’re free to other visitors, or include the volumes of water used in your normal quota. You’re also a bit concerned that residential drought restrictions & policies on water use might be applied for roaming use too.

In other words, where WiFi is provided as an amenity (not a service), it is important to just offer it with a simple mechanism (but not without the user being unaware) and then get out of the way. For instance, I’m writing this in Amsterdam Airport, where there’s a simple splash page offering 4hrs connection with a single click and no registration/password requirement. Contrast this with my awful recent experience at JFK, where I was exhorted to download an app for a measly 30mins access. (Hilariously, the app wasn’t available for people using non-US Apple AppStores – utter cluelessness at an international airport).

Now in other situations, putting simple ads or useful services on a splash page is useful – maybe a hotel offering other services, or an airline lounge WiFi showing departure gate information. Sometimes I’ve seen “WiFi sponsored by Brand X”, and it’s OK to get a quick screen of their logo before connecting. Quid pro quo is fine, in moderation. But lengthy video ads, intrusive registration (except where local laws insist) and 2-factor authentication via SMS/PIN-code seem like overkill.

On the telco side, I’ve written before why so-called seamless WiFi-to-cellular integration is often bad for users, app developers, enterprises and venue owners. Fortunately, the market has wisely overseen the failure of pointless ANDSF standard, and very limited rollout of HotSpot 2.0. These are arrogant standards, based on the flawed assumption that mobile operators are able to determine “always best connected” options. Given the number of stakeholders involved – users, fixed operators, mobile operator, OS providers, venues, employers, app developers and more – it is mathematically impossible to define “best” from all perspectives, with all criteria.

The concept of “always best connected” is a lie (OK, I’ll be generous a euphemism). There is no one “best” which all involved can agree upon.

We can also now see the usual engines of cellular Machiavellianism revving up in anticipation of 5G. Once again there is the rhetoric of WiFi being “part of future 5G standards” – the assertion being that it will be "brought under the umbrella".  While some WiFi may become integrated into the pseudo-mythical “HetNets”, most will not. The issue is that venue owners, enterprise LAN managers, end-users, and network-aware app developers don’t have loud voices to protect their interests.


Regulators should keep close watch too, especially given the consolidation being seen in many mobile telecom industries. Public/venue/amenity WiFi provides an arbitrage path for consumers, to play off against their cellular provider’s data plans as and when they can. This is important – even if 3rd party WiFi can be slightly cumbersome to access, it essentially provides partial competition to the mobile industry. It is therefore critical for regulators to ensure that WiFi is kept as independent as possible, and that users have to make an explicit choice between telco-offered WiFi and that available from the venue itself or another service provider. As some operators are trying to bundle WiFi data use (in GB terms) with LTE, it becomes even more important that users can see and choose alternative sources of WiFi easily. It is also important for application developers to have visibility (and sometimes control) of network access – and not be subjected to the whim of the operator’s core network and policy servers.


To sum up – the battle for the soul of WiFi continues. On one hand the mobile industry is hoping to subsume (or, though LTE-U interference, subvert) public WiFi access. But at the other end, over-aggressive “monetisation” is likely to reduce its utility and convenience too. There needs to be concerted effort to keep WiFi implementations user-friendly and open to easy choice.

The seams need to be finely tailored and elegant, not removed entirely, nor bulked-up and intrusive.
                                                                                                              

Friday, November 20, 2015

Decoding T-Mobile's WiFi-Calling and VoLTE stats

A quick analytical post. I'm currently re-doing my WebRTC model for service provider use-cases, and as part of that I'm looking at data on adoption of VoLTE, WiFi-calling and other services/applications.

T-Mobile US is interesting as it's revealed various data-points over the past couple of years:
  • 2007 - original launch of UMA-based WiFi calling, notably on BlackBerry
  • May 2014 (link) - VoLTE launch, although the acquired MetroPCS had had a limited deployment since 2012
  • June 2014 (link) - 17m WiFi-calling enabled devices, with "almost 5m" WiFi calling users (including older UMA/GAN). The user base quoted is monthly average users (MAU)
  • July 2014 (link) - total of 52m VoLTE calls made
  • December 2014 (link) - 19.2m VoLTE calls per day & 6.6m WiFi calls per day
  • March 2015 (links here & here) -  7m WiFi calling users per month, 7.6m WiFi calls per day, 10% of calls on VoLTE
  • October 2015 (link) c12m WiFi calls per day
  • November 2015 (link) - a third of calls on VoLTE
Now, consider a few other data points. According to various surveys, a typical US mobile user makes/receives 6-7 calls per day. And T-Mobile had 61.2m subscribers at end-Q3.

That implies that T-Mobile US carries around 400m calls per day, assuming its users are fairly similar in usage pattern to AT&T & Verizon. (Note that the US quotes statistics including both inbound and outbound calls, in contrast to most other operators/countries which just count outbound)

In other words, only about 3% of T-Mobile's calls use WiFi calling. Put another way, VoLTE is 10x larger, despite being launched much more recently. And T-Mobile US has been by far the longest, largest proponent of WiFi calling, for more than 8 years, in both IMS and pre-IMS variants. The number is growing, as new devices support WiFi calling, but it's still a relatively small part of the total.

Also, looking at the user numbers, it seems probable that T-Mo is now on perhaps 10-11m MAUs for WiFi calling. But that's monthly - and those people collectively make more than 2 billion calls per month. So even among those users, only around 17% of calls are on WiFi - which makes sense as many will be using their phones outside their homes/offices.

To reconcile the numbers, it's probably better to think of perhaps 2m regular daily users, accounting for perhaps 8m calls per day, plus maybe another 8-9m per month whose phones switch to WiFi calling occasionally - perhaps in poor-coverage areas, or while travelling. The regular users will likely be those with poor coverage at home.

What does all this mean? In a nutshell, it suggests that WiFi calling is less of a big deal than many think - and is primarily a customer-retention tool for operators with in-building network limitations. It's not (currently) a meaningful source of voice traffic offload. 

3% of calls and 3% of subscribers as regular users, for the most-aggressive operator pushing the technology, is not hugely impressive. By contrast, the adoption of VoLTE has been surprisingly rapid, although the stats are possibly skewed a bit by high-end/telephony-heavy users.

It also implies that many operators may well not bother with full IMS-powered WiFi calling, instead taking a path towards using separate VoIP (or video) apps such as Orange Libon or Telefonica Tuenti Mobile. In particular, these "secondary" apps can offer a different experience to ordinary phone-calls from the native dialler, especially with WebRTC as a more flexible enabler/platform than IMS.

It's also worth noting that T-Mobile is starting to push its new 3G/4G small cell ("CellSpot") for people with poor coverage, which may mean that some users actually reduce their reliance on WiFi for calls at home or in small offices. (link)

Some of the comments I heard at yesterday's WiFi Now conference in Amsterdam seem over-hyped. I'm yet to be convinced that many enterprises will open up their private WiFi networks for carrier VoWiFi in large numbers, in particular.

So overall, I expect IMS-based WiFi calling to continue growing, especially in markets that have high numbers of calls-per-subscriber, plus variable-quality coverage indoors, or for operators with limited sub-1GHz coverage. Maybe, with Herculean and very expensive efforts, a few operators might reach the 10% mark for calls carried over WiFi. And that's only if they get all phones auto-provisioned, they work with enterprises and venues to integrate WiFi calling with in-house WiFi, and don't push hard on small cells or LTE-U.

Meanwhile, the overall market for "boring old phone calls" will continue to drop regardless. Yes, if WiFi-calling can be added cheaply and easily then it's a useful "maintenance" enhancement of legacy telephony. But it's not a substitute for (or component of) proper innovation around voice, video, WebRTC and contextual communiations. That needs to be the strategic priority, not window-dressing for a few percentage points on a decades-old service.

Disruptive Analysis publishes research & does private consulting/workshops, as well as conference speeches, on areas such as WiFi calling, VoLTE, WebRTC and next-generation voice/video/messaging applications. It has covered the convergence between WiFi and VoIP since 2003. Please contact information AT disruptive-analysis DOT com for more information.