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

Friday, October 28, 2011

Telcos will find that API payments are a two-way street

Various telecom operators are rolling out paid-for API programmes, typically for charging against a phone bill, sending an SMS and so forth. There are some increasingly good individual operator strategies (eg Telefonica BlueVia) and the ongoing (but grindingly-slow evolution) of the industry-standard OneAPI from the GSMA.

However.... it's not easy. And not only that, but operators are increasingly going to find that payments for Internet APIs are two-way. They will (and indeed should) be paying for capabilities from Facebook, Google, Amazon and others, as well as (hopefully) making money from them elsewhere.

I first wrote about payments FROM telcos to Internet and so-called "OTT" players about 6 months ago. It's also something I suggested might happen in yesterday's post about OTTs potentially moving from being "dumb data centres" to charging differentially for priority access from some network operators.

I also asked people at this week's Rich Communications conference whether they expected to make more money from selling RCSe APIs than they'd likely have to pay out, for decent Facebook integration or other third-party services. I didn't get a satisfactory answer.

Today, another interesting development - a new charging structure for the Google Maps API. This one is interesting, as numerous operators use it for a variety of different purposes. Both the BTFon and Vodafone Wi-Fi Finder offload/connection clients use Google Maps to help me find the nearest hotspot, for example. T-Mobile's UK website uses it for helping customers find the nearest store. There are probably numerous other mashups as well.

While the operator may have its own location lookup from the network, or be able to extract it from a handset's integral GPS API, they often won't have a nice, familiar user-friendly map like Google's or Bing's. Especially where app development is being done by a small team decoupled from the main engineering units of the telco (eg a telco-OTT app skunk-works, or many WiFi add-ons), they will just tend to follow the usual paths taken by developers and use whichever APIs make sense.

But in a way, this is a good thing. Although the "balance of payments" for APIs may be negative in the short term (ie telcos paying more money to Internet companies than they get in return), that's not necessarily worrying.

Firstly, operators need to show that they "get" the whole API / web-services / mashup philosophy. By both buying and selling APIs, operators have a much better chance to show that they're serious members of the web ecosystem, rather than taking an arrogant stance that they are somehow entitled to "monetise their assets and capabilities" unilaterally, and have people flocking to their doors.

Secondly, operators should be using Web APIs for the same reason as everyone else - they help lower costs, improve time-to-market and add new and innovative features that improve the value of their own services. Similarly, they should be looking at tactically using hosted cloud services like Amazon's as well, not just trying to sell cloud services of their own.

Lastly, gaining greater experience with buying APIs should also yield a lot more insight into how to market, price, bill and support them, when they move into the API sales arena. That should yield better knowledge about good interfaces, speed and flexibility in evolving their API platforms, and the relative importance of "silo" APIs that just work, versus more complex federated or standardised ones.

Wednesday, October 26, 2011

There needs to be an Alternative Communications Providers Association (ACPA or OTTA) to counterbalance the GSMA

One of the speakers said something really profound at last week's Sonus Connexions event in Miami:

"Skype is now the world's biggest telco". It has more users than China Mobile has subscribers.

And one of the notable outputs from the Rich Communications summit in Munich this week has been the push by mobile operators and the GSMA for RCS-e to be embedded "natively" in mobile phones, so that "It's just there". The operators hope to use their purchasing leverage with the handset OEMs to encourage and cajole them into building RCS-e into the basic handset software/firmware stack - implicitly putting broader IMS capability in with it.

That got me thinking.

The GSMA talks incessantly about its 5 billion+ "community". Never mind the fact that it's no more a community than the 5 billion with electricity - or shoes, for that matter - it's a large number, irrelevant as it is. (And yes, riddled with errors because of multiple SIMs per person). One of the speakers at the event said this mean that RCS-e had the "potential" to reach 5 billion people in future.

I commented at the time that Facebook has similar potential, as it uses not just downloadable smartphone apps, but also Java ME, Facebook Zero (WAP) and even USSD menus. That takes it to a potential 5 billion user reach today, not at some indeterminate point in the future.

But thinking further - if the mobile operators can start trying to mandate "native" capabilities in devices, why can't Facebook as well? Or, indeed, its peers.

Let's imagine for a moment what an Alternative Communications Provider Association might look like, made up of the various non-MNO voice/video/messaging providers. You could even call it OTTA if you wanted a nice logo of an aquatic mammal.

We've got (roughly and non-comprehensively):

Service               Users
Facebook            800m 
QQ (China)         800m
Skype                  600m
MSN                   500m
Sina Weibo         250m
Twitter                200m
Yahoo IM            200m
Renren                 200m
LinkedIn              150m

Orkut                    60m
Nimbuzz               50m
RIM BBM           50m
Google+               50m
Kakao                   25m
Cyworld (Korea)  20m
Viber                     20m
WhatsApp             20m

And then there's Apple's Facetime and iMessage, Google Voice, Kik, enterprise VoIP from Cisco and Avaya, IBM SameTime and many others. So, give or take, about 4.5 billion users collectively. You could also add in various providers of webmail for another 3 billion or so as well. Potentially, you could add in the telco-OTT operations like ON, Comoyo, Bobsled and O2 Connect as well. And yes, there's a lot of overlap in terms of the user base - but then that's also true (albeit to a lesser degree) of SIMs.

So now let's consider what specifications and other activities that ACPA / OTTA could start doing, if it acted collectively like the GSMA. (Obviously with appropriate anti-trust safeguards).

- Define handset standards that give equal priority to 3rd party communications services as the "official" MNO ones
- Define mechanisms that ensure that users can easily install - AND delete - any handset communications apps, including SMS, RCS etc.
- Specify multiple identity and authentication methods for services (leaving the SIM for network registration though, for now).
- Develop an equivalent to the GSMA IPX for interchange / backbone services
- Define methods for VoIP / social network portability
- Act for collective lobbying vs. regulators and governments on issues like Net Neutrality, termination regimes and structural separation
- Examine business models for monetising MNOs that currently deliver their services to users "for free", exploiting their R&D and data centre assets. (Who wants to be a dumb data centre, working equally with all networks?). For example, rev-shares on data roaming fees, which aren't even based on the billing operator's network assets.
- Market the benefits of unlocked "vanilla" handsets without operators' software add-ons
- Develop a shared approach to emergency calls / lawful intercept
- Work with banks or credit organisations to provide alternative sources of handset subsidy/loan
- Defining ways for multiple comms apps to "peacefully coexist" on handsets without software conflicts
- Examine ways to minimise battery drain, for example by using shared notification systems
- Work with network equipment & IT infrastructure providers to develop optimised hardware for data centres, private overlay networks etc

In a way, it surprises me that no such grouping exists already. For all their competitive animosity, I can't believe that Microsoft, Apple, Google and Facebook (and maybe QQ as an outsider) can't work together as effectively as the squabbling telco world - and probably make decisions and take action an order of magnitude faster. Perhaps there have already been secret discussions I'm not aware of, and they concluded that it wasn't necessary given the companies are still ascendant.

But given that the legacy telcos have failed to change their ridiculous "them and us" stance versus their newer peers, it is perhaps now appropriate for these maturing organisations to work to their mutual benefit against a common front.

This is just a starting point - I've literally just thought of this in the last hour or so.

Needless to say, if any of the organisations mentioned would like some analytical insight into this concept, I'd be delighted to assist in any way possible. You can contact me via @disruptivedean or information AT disruptive-analysis DOT com


Tuesday, October 25, 2011

Implementing native RCSe in devices brings operational risks from emergent behaviour

I'm at the Rich Communicatiosn conference in Munich today & tomorrow, listening to presentations on RCSe (asd asking critical questions).

I'll do a full summary another time (thus far: operators are more convincing - and more restrained - than vendors). But one point has struck me:

The big push from GSMA and the "Group of 5" lead operators is around natively embedding RCS capability into future mobile phones so that it "just works", and appears to the user in a similar way to today's SMS and voice diallers. On other devices, aftermarket apps for RCS may be available for download.

I can see the "elegance" here in native capabilities, but I think there is a huge risk which has not been identified. Downloaded apps can be updated "in the field" relatively easily. HTML5 apps can be updated even more simply as the functionality resides mostly in the cloud, or through browser plug-ins.

The risk is that of "emergent behaviour". Consumers and companies tend to find unexpected ways to use services - sometimes providing benefits and value, but sometimes creating problems. For the voice dialler, many people have started to use "missed calls" to notify friends of things, creating signalling load and congesting voice switches, but creating no revenues. SMS usage was essentially an "emergent" behaviour which drove huge revenues. SMS spam, however, has been a downside. Consumer use of BlackBerry Messenger has been largely emergent.

Nobody knows what the emergent properties of RCSe might be. They might be hugely addictive and valuable services, or they might cause huge problems. They are unpredictable and essentially untestable. There may be unexpected bugs or weird effects when users start behaving in a particular way.

One of the things we've seen in recent years is similar issues with Facebook and other online services, which have created risks such as privacy leaks, issues around personal safety / stalking and many other undesirable side-effects. When these occur however, they can be quite rapidly rectified, either by changing the web application, or perhaps by issuing an OS patch, or an amended or bug-fixed smartphone app.

It is far from clear how a "bug-fix" or emergency upgrade / alteration of RCSe clients could be achieved if the functionality is hard-coded into phones. Some might be updateable via FOTA (firmware-over-the-air) upgrades, but that is unlikely to be feasible across the board. Apple can update iOS via iTunes - but no similar mechanism will exist for RCSe.

The problem is that this risk is essentially unquantifiable - emergent behaviours are inherently surprising. I think that RCSe needs a clear and well-articulated strategy for "rapid response" if something untoward happens. This is not just the risk of creating network load either - there is the potential for reputational and legal risk as well. This needs to be considered and managed much more effectively than I've seen so far.


Thursday, October 20, 2011

Next few months are do-or-die (or die again) for RCS and RCS-e

A year ago, I published a report on why I thought RCS was dead , which also included some thoughts on how I thought it might be salvaged.

Since then, it has been reincarnated as RCS-e (e supposedly standing for "enhanced"), which takes out things like presence and focuses on IM and media-sharing. Less generously, I'd perhaps call it "reanimated" and RCS-z (z for zombie, as it's still shambling around despite being dead).

We're about to move into another season of marketing, hype and possibly propaganda for RCS-e, as the market has been promised launches from the European "group of five" major operators - Vodafone, T-Mobile, Orange, Telefonica and Telecom Italia Mobile, with interest from other telcos in Europe, Asia and Middle East (and, perhaps, the US).

Coming up are events such as next week's Rich Communications summit in Munich and Telco 2.0's New Digital Economics EMEA in early November, which has significant RCS-e presence from companies like Vodafone. I'll be at both events.

Although I've been negative about RCS / RCS-e since Day 1 - and various operators have commissioned me to explain my views and demonstrate the "bear case" - I'll try and attend with an open mind. I'm conscious that this time, my skepticism is actually mainstream - the market as a whole seems to agree with me. That worries me, as I don't think I'm influential enough to have convinced everyone, and normally I believe that the Tyranny of Consensus means that the majority is wrong.

So I'll listen to presentations, watch some demos - and grill some of the advocates. But there's a very high bar to make me change my mind, as I've identified at least a dozen reasons why RCS/e is a bad idea, and I suspect that many (most) haven't been addressed.

Some examples: lack of support from Apple, lack of business model, the slow pace of evolution, risks of security breaches or unwanted "emergent" behaviours, and the ridiculousness of trying to intermediate between a user & their Facebook experience.

So it's going to take quite a lot for me to be bitten by the RCS zombie and get infected by enthusiasm for it. Either way, it's not going to eat my brain - I'll be taking plenty of very sharp and pointy wooden stakes with me, ready to put RCS-z out of our collective misery if it's still dead.

Wednesday, October 12, 2011

Musings on my next personal phone & contract

I'm coming up to the point of deciding on my next main personal mobile phone & contract.I thought it might be worth going through my thought processes on the blog, which may highlight some factors that reflect wider industry trends - or perhaps just reflect my outlier status as a user.

Although I've usually got a couple of spare devices around, and occasionally play with new ones to get a feel for things, I don't tend to chop & change, and I don't review handsets. Up until two years ago, I had separate voice/SMS/camera and email/data-centric devices, but I've switched to a single-device approach since then.

I'm currently using an iPhone 3GS on Vodafone, with an 18-month contract that's just expired - but with the "grandfathered" 1GB a month allowance. It's still in decent condition after 15 months (my first one fried its baseband & was replaced), despite not using a case. I'd like a better camera but it's actually sill pretty functional.

I'm tempted to just keep the current phone, either get it unlocked & port to another network, or stay on Vodafone, and switch to a rolling 30-day contract at half the price.

My criteria for choosing an operator / plan are:

Mandatory:

  • 1GB+ per month (I use around 600-700MB typically). This could be done with 500MB + an extra 500MB package, or maybe just reasonable overage charges
  • Cheap data roaming. This is imperative. Vodafone (in Europe) is now good with its £2/day plan for 25MB
  • Cost - my base plan is £41 per month (which obviously included the initial subsidy repayment) & I have no desire to increase this.
  • No heavy-handed branded operator bloatware, or attempts to put an extra software layer between me & what I want to do.
Important considerations
  • Decent 3G coverage in central London (Vodafone is surprisingly poor)
  • Low network latency (difficult to tell network vs. phone, but I see 3G latency as *much* worse than WiFi - even when done via my 3UK MiFi)
  • Reasonable network policies (eg no VoIP blocking, no unnecessary data/video optimisations)
  • (up to a point) OK WiFi offload and a decent "my account" dashboard app
Basically, I want the best pipe I can get. On this basis I may have to grudgingly stick with VF, despite their iffy coverage (still no 3G in Primrose Hill, 7 months after this post) as the others don't stack up for roaming as well.

Choosing a phone is also complicated.

Let's get one thing out of the way first off - no Androids. I don't/won't use a Google login for my primary device account. For me, a Google account is purely for business, not personal, and I always try to avoid blending the two on any ecosystem (Facebook=personal, Twitter=business, iTunes=personal etc). I usually log out of Google when I'm not using Blogger (or if I'm forced to use Google Doc by a client). I've got a Gmail account but hardly use it, and have clicked the "stop spamming me with invites" link for G+. That's not changing. (Unless it's possible to fully log out of Google while using an Android phone? Let me know).

On "coolness" grounds I'd prefer not to have an iPhone, but something more individual & unusual. I see so many in London (and so many Macs), that having an Apple feels like driving something like a BMW: a boring, default, sheeplike choice. Well-engineered but a bit soulless & dehumanising.

On the other hand, it does "just work" (well, apart from my first one that committed suicide), the swipes and menus are pretty nice, and I can express my individuality in plenty of ways other than through the brand of telephone I'm carrying.

I've been tempted to switch to using a BlackBerry for a while, as so many of my younger friends have them for BBM but I'm sensing that that ship may have sailed (especially with WhatsApp and other similar messaging services on other platforms)... and the current (12/10) outage won't have helped.

Windows phones are appealing because they're different & I quite like UI. I'm interested in seeing what Nokia comes up with, but that may be too late for me anyway. Also, the tiles look a bit like another attempt at social network aggregation (no thanks) which I'd need to be able to switch off. I'll definitely check out one or two though... but... the kicker is application support.

Apps. Now I'll admit to being a Luddite here - I haven't *bought* an app for personal use since 2005. Apple doesn't have my credit card details on iTunes (one of my original criteria for getting an iPhone was the ability to sign up without adding any payment channel). But I do use some free apps quite a lot - almost exclusively for Social Networking, Travel/Transport and Connectivity.
  • Social networking: Facebook obviously, and recently LinkedIn, MeetUp  and Quora.  (I deleted the Twitter app, though)
  • Travel/transport: Barclays Bike Hire app (Boris Bikes in central London), Kayak, Tube Status, British Airways, Addison Lee taxi hire and MapsWithMe (offline Wikitravel)
  • Connectivity: BTFon (for WiFi access as I use BT broadband at home & this gives me a couple of million FON/Openzone spots) and Onavo (for data compression while roaming). I might add the O2 WiFi app at some point as well.
And unfortunately, most of these are iPhone / Android only at the moment (and some just iPhone, or different on Android). All of them also work fine on my 3GS - as yet I haven't really come across anything must-have that needs a 4 / 4S. The camera is tempting, though - but not worth the extra money vs. a small digicam I could carry if I wanted.

Actually, writing all this out has probably given me the answer - stick with the 3GS, batter Vodafone into giving me a new & much lower off-contract rolling 30-day price plan, and then wait until either something must-have drives me to a 4S (better camera maybe, or iOS 5-only apps), or until Windows Phones have enough app support & some cool devices. It's actually been an interesting exercise for me as well - forced me to think about what's important (eg which categories of apps I care about)

Monday, October 10, 2011

WiFi neutrality vs. the OMA

I've written before about the critical importance of "WiFi Neutrality" - the ability for the end-user, device OS or applications to choose which WiFi connection to use, over-riding any operator-defined preferences if such exist.

The critical control point is the "connection manager" on a device - the bit of software that determines which accesses are available, and how/when to connect to them. For WiFi, this is usually done as a core role of the device OS - most people are used to seeing the Windows or Mac choices for WiFi APs, or a similar function on their smartphones. For cellular connections, it doesn't really exist as such on phones (beyond a primitive menu somewhere with auto/manual network-select). But on laptops, there's usually a customised client from the operator that gets auto-loaded when inserting a 3G USB dongle for the first time, or pre-loaded if it's got a built-in module.

I've long predicted that the CM would become a strategic battleground, especially for the WiFi aspects. Much to service providers' continued annoyance, most WiFi isn't a service at all (ie at a hotspot), but is just a wireless connection to a local LAN. The biggest use of WiFi is for connection to a fixed-broadband router or gateway, and then direct to the Internet. Various other LAN use-cases are important as well, notably enterprise network connections, or UPnP links to other devices in a user's home (TV, printer, server etc).

The mobile operator community would dearly love to have greater control and visibility over users' WiFi connections - ideally capturing data connections and putting them through the core network (for billing, charging, policy, QoS reasons etc). "Uncontrolled" (ie user-driven) WiFi connections are often seen as undesirable because they represent a second access path for data on or off the device. This both implicitly reduces the perceived value of the paid cellular/hotspot connections, and also allows easier access to applications that the operator may not want (eg competing VoIP).

The Open Mobile Alliance is currently working on a "solution" for the fact that CM's currently are not standardised. The Open Connection Manager programme and its associated APIs are being worked on by a group of its members (Intel, Orange, Huawei, HP & Deutsche Telekom) with various objectives.

"Up to now, there is no existing standard or de facto standard for Connection Managers.  Operators and OEM/ODM have to develop and use different and dedicated solutions, thus increasing the effort and time to market.

For Mobile Broadband devices, this situation is critical and leading to a strong effort for service providers to develop connection manager applications as there are already several networks to support and any new mobile broadband device such as USB modem requires to redevelop existing connection managers to be implemented and supported by these applications.

For smartphones or tablets, the importance of management of Wi-Fi offloads for example and/or the need to expose information status on the connection to applications is requiring a solution through the connection manager application.

Furthermore, new fast growing businesses such as Connected Devices & M2M are facing the same hurtles and will need as well a solution to reduce the impacts and efforts to deal with the connection management aspects."

Now, for cellular data connections this is fair enough. There is a fair amount of work needed to reinvent the UI for each new device or module, so standardising some aspects certainly makes sense.

For WiFi, however, the situation is much murkier. There are already various efforts such as Hotspot 2.0, I-WLAN and ANDSF which are attempting to "steer" smartphones to use operator-provided WiFi. The dreaded term "seamless offload" still crops up regularly. While I've had some positive recent conversations with operators and vendors - who realise that control over WiFi ultimately should and will continue to reside with the user, I'm not so sure that OMA has got that particular memo.

"The OpenCMAPI enabler SHALL be configured to use the operator defined list of preferred SSID preconfigured in the device and/or the WSID (Wlan Specific Identifier) list in accordance with [3GPP TS 24.234] if present in the SIM/RUIM/NAA on UICC"

"The OpenCMAPI enabler SHALL be able to force the association on a SSID, visible or not" 

"The OpenCMAPI enabler SHALL be able to modify or delete only WiFi profile that are not predefined by the operator"

Now to be fair, it also says this:

"The OpenCMAPI enabler SHALL allow the user or the application using the Open CMAPI to connect to Known network or Unknown network manually"

But it's entirely unclear how that will work if that conflicts with the previous requirement. So for example, could an enterprise user delete the operator's WiFi profile & stop offload, if they decide it is incompatible with their security policy?

The bottom line is that as far as I can see, the OMA Connection Manager API sits very uneasily with the concept of WiFi Neutrality - I really can't see many device vendors (especially Apple) relinquishing control of this pivotal part of the stack. In any case, the Open CM is unlikely to be seen as a useful basis for the expanding number of WiFi-only devices.

If implemented in this WiFi-unfriendly fashion, it is also going to be something that will further dissuade users from buying 3G-embedded laptops (which I've been negative about for years), if the operator also controls the WiFi connectivity settings. You don't let a service provider dictate how you use your USB ports or fixed-ethernet RJ45 socket on your PC, so why on earth would you accept controls on the wireless-ethernet?

I have a simple adage with anything to do with WiFi : If you don't understand fixed ethernet, then you have no business doing anything with the wireless version either. Quod erat demonstrandum....