Amazon Tech Support

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Tuesday, 25 October 2011

Implementing native RCSe in devices brings operational risks from emergent behaviour

Posted on 04:20 by Unknown
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.


Email ThisBlogThis!Share to XShare to FacebookShare to Pinterest
Posted in | No comments
Newer Post Older Post Home

0 comments:

Post a Comment

Subscribe to: Post Comments (Atom)

Popular Posts

  • The Number 1 problem for "seamless" models of WiFi offload / network selection
    I frequently argue against the assumption that "seamless" connection to WiFi is practical or desirable, especially for the general...
  • Mobile social networking - how I'll know when it's going mainstream....
    This falls into the category of "amusing personal anecdotes" rather than "rigorous industry analysis". But it also refle...
  • Part of Nokia's problem - making Ovi compelling
    I've got a Nokia Ovi account somewhere. Signed up for it ages ago, to play around with the Ovi Store when I had an N97 to play with, ba...
  • Putting a value on customer data with reference to offload
    There continues to be a ferocious discussion about AT&T's new data plans - and also, as I commented a couple of weeks ago, about the...
  • Android - the retail experience
    I just stopped off at my local branch of Carphone Warehouse on a whim, to have a quick look at what's being sold and how. (By coincidenc...
  • For telcos, "Monetising OTT" is about distribution partnerships & revshare, not QoS or termination fees
    A couple of years ago, I moderated a panel session at a conference on broadband business models and "traffic management". It was o...
  • BT WiFi smartphone application
    I've just seen BT's announcement of its new iPhone and Android app, offering free WiFi access at its Openzone and FON hotspots to i...
  • An update on @DApremium - the world's first paid Twitter channel. Now available with quarterly or annual subscriptions
    It's now been six weeks since I announced the launch of @DApremium , my second Twitter stream - one which is available only to paid subs...
  • The Novatel MiFi - possibilities for new mobile broadband business models
    OK, I realise that I've been a bit grumpy and critical of some things recently. But before everyone assumes I'm getting more cantank...
  • There really needs to be a "User tariff API" for developers
    Generally speaking, app developers and website owners know what device you've got, what OS, and what browser. Furthermore, they know wha...

Blog Archive

  • ►  2013 (31)
    • ►  October (2)
    • ►  September (3)
    • ►  August (1)
    • ►  July (2)
    • ►  June (6)
    • ►  May (5)
    • ►  April (1)
    • ►  March (3)
    • ►  February (3)
    • ►  January (5)
  • ►  2012 (46)
    • ►  December (5)
    • ►  November (4)
    • ►  October (3)
    • ►  September (2)
    • ►  August (4)
    • ►  July (3)
    • ►  June (1)
    • ►  May (6)
    • ►  April (4)
    • ►  March (1)
    • ►  February (9)
    • ►  January (4)
  • ▼  2011 (73)
    • ►  December (4)
    • ►  November (10)
    • ▼  October (8)
      • Telcos will find that API payments are a two-way s...
      • There needs to be an Alternative Communications Pr...
      • Implementing native RCSe in devices brings operati...
      • Next few months are do-or-die (or die again) for R...
      • Musings on my next personal phone & contract
      • WiFi neutrality vs. the OMA
      • My suspicions on iPhone delays - chipset integrati...
      • 3GPP gets serious about the Future of Voice beyond...
    • ►  September (6)
    • ►  August (3)
    • ►  July (5)
    • ►  June (7)
    • ►  May (9)
    • ►  April (4)
    • ►  March (7)
    • ►  February (6)
    • ►  January (4)
  • ►  2010 (130)
    • ►  December (4)
    • ►  November (10)
    • ►  October (10)
    • ►  September (6)
    • ►  August (9)
    • ►  July (7)
    • ►  June (19)
    • ►  May (19)
    • ►  April (11)
    • ►  March (18)
    • ►  February (7)
    • ►  January (10)
  • ►  2009 (126)
    • ►  December (4)
    • ►  November (14)
    • ►  October (9)
    • ►  September (8)
    • ►  August (9)
    • ►  July (10)
    • ►  June (21)
    • ►  May (14)
    • ►  April (2)
    • ►  March (11)
    • ►  February (15)
    • ►  January (9)
  • ►  2008 (94)
    • ►  December (24)
    • ►  November (26)
    • ►  October (25)
    • ►  September (19)
Powered by Blogger.

About Me

Unknown
View my complete profile