Speaking Engagements & Private Workshops - Get Dean Bubley to present or chair your event

Need an experienced, provocative & influential telecoms keynote speaker, moderator/chair or workshop facilitator?
To discuss Dean Bubley's appearance at a specific event, contact information AT disruptive-analysis DOT com

Monday, January 29, 2018

Telco use-cases for AI: A simple categorisation model

The coming years will see the application of AI technology across all sectors of the economy and life. The telecoms industry is no different. Although I’ve been commenting on telco-sector AI in the context of “TelcoFuturism” for some time (link), and co-ran a workshop on it in May 2017 (link), the last few months have seen a notable upswing in interest. I’d say that the public use-cases now seem to be significantly in advance of those for blockchain, in terms of potentially-transformational technologies.

That said, it can still be hard for many executives to grasp exactly what is likely to change, and when, for AI/telecoms combinations. This is highlighted by the surge in AI-related panels, presentations and even complete streams at industry conferences – although sometimes I see more interest from generalist AI people about the telecoms vertical, versus telecom specialists looking at what’s new. 

Both sides of the equation have large volumes of obscure acronyms, multi-layered technology stacks, and complex volume chains – which can mean that mutual understanding is often confined to narrow niches. AI covers machine- and deep-learning, language processing, machine-vision and much more. Telecoms includes vast realms of internal systems and processes that are unknown to most who are not insiders – domains like core networks, OSS/BSS, network optimisation, toll fraud and service-assurance are alien to those not steeped in the industry.

One of the ways I’ve been using to “set the scene” for describing AI/telecoms intersections is to simplify and categorise the use-case areas. I count three, possibly four, large “buckets” into which a variety of telecom AI impacts will fit. These buckets are not based on either specific AI or telecoms technology slices, but more on understandable business functions and roles:

  • Dealing with customers
  • Managing operations
  • Creating new services
  • (External risks)
 Within each of these areas, there are many, many sub-sectors – and also some overlap.

“Dealing with customers” can include everything from voice/text chatbots for customer-service, through to predictions of which customers are least-happy and may “churn” to competitors. Where telcos have retail outlets, it could incorporate various in-store technologies, or it could be about smarter web-consoles for B2B customers running complex managed services.

“Managing operations” is even more diverse – it could be fault prediction for network elements, optimising the 100s of configuration variables for radio networks, spotting fraudulent traffic to international premium-rate numbers, allocating engineering resources more productively, or protecting against hackers and malware. There are hundreds of possible uses here, which mostly overlay on top of existing operational/business support systems (OSS/BSS) See also my recent post (link)

“New services” also spans a range of areas, but broadly splits between AI-enabled and AI-enabling services. An AI-enabled service could be a local-language voice assistant added to a cable operator’s set-top box or remote control. Or it could be the provision of integrated “smart city” solutions including video-cameras and security analytics. AI-enablement could include offering “edge” servers for hosting local processing, milliseconds transport-time away from a device, or it could be the provision of anonymised bulk data for others to apply algorithms to. Telco opportunities with IoT+AI include both enablement and enabled services, in numerous manifestations.

The “risks” category includes a diffuse set of possibilities by which AI might harm the telecom industry, or dampen demand for services. Smarter devices (eg autonomous vehicles) will be able to host their own offline image processing & route-planning locally, rather than needing realtime connectivity at 5G speeds/latencies. Another threat could be customers’ smart assistants renegotiating price-plans on their behalf – after crowdsourcing millions of conversations to deduce how best to game the retention staff’s scripts and objections. (Of course in the latter example, the customer-retention team could themselves be bots). Numerous types of automated “least-cost X” and arbitrage engines are likely to emerge. Various security risks are also probable here too.

Clearly, using just these four "buckets" misses much of the fine-grained detail. But I find it helpful as a starting point, as most top-level industry issues apply differently to each. 

Consider input data, for example – for both customer management and operations, telcos have abundant historical records and ongoing data collection that may generate terabytes per day. But for the former, privacy considerations often come to the fore in terms of regulation and risk, while this is far less of a concern for internal operational data, for example on how the network is running. For new services, almost by definition the focus is on collecting/processing/transporting new data, rather than deriving conclusions from existing sets. 

This four-way framework is also useful for thinking about different types of ROI model - split broadly between impacting existing revenues, existing costs, new revenues and potential changes to underlying assumptions. 

I'll be covering these topics in more depth in various upcoming presentations and reports, as well as looking at other areas of telco-linked innovation such as blockchain, 5G and enterprise verticals. Please get in touch if you would like more detail, or are interested in internal workshops, external support through events or white papers, or are seeking ongoing strategic advisory support.

Sunday, January 07, 2018

Update: Telecom & Network Cryptocurrencies, Tokens & ICOs


Back in August I wrote a post on blockchain-based ICOs and tokens/coins for the telecoms space (link). Quite a lot has happened since then - including a huge boom in Bitcoin and "AltCoin" valuations and public awareness - so I thought an update was useful. 

In a nutshell - there's a growing number of telecom/networking "coins" available, with a wide variety of concepts, team backgrounds and business models. Some are very interesting, but some others are... let's say, "ambitious".  And a few look like utter nonsense, seemingly lacking understanding of the relevant technology or marketplace dynamics. It's possible there's a couple of outright scams as well.

I'm not making recommendations, or giving warnings, about specific tokens here. But in the spirit of "caveat emptor", I also give a list of cautions and possible problems, that investors should think about, or ask the various currencies' teams. Telecoms is a lot more complex than many people think - especially  the "behind the scenes" bits of technology.

Note: If you've found this post via an ICO/cryptocurrency site, an introduction: I'm primarily a mobile and telecoms analyst. I advise on technology and business-model trends for networks and communications, eg 5G, IoT systems, Wi-Fi, voice & video & UC, regulatory policy, the future role of carriers/CSPs, and the impact of "futures" innovations like AI / ML, blockchains (public & private), quantum computing and drones on telecoms. Most of my clients are telcos or network equipment/software vendors. I'm not a fintech, crypto or blockchain generalist - I look at blockchains & tokens where they intersect with the telecom world. Please get in touch if you are interested in my research & advisory work, or if you are looking for a keynote speaker or moderator.

What's been happening with telecom cryptocurrencies?

I'm not going to repeat my previous posts on ICOs, tokens and the wider telecom blockchain space. You can read blog posts here and here, or download a full white paper I wrote for Juniper Networks, here and listen to an associated webinar here.

The second half of 2017 saw continued emphasis on private blockchain use-cases for telecoms and networks, although despite a few high-ish profile initiatives and press releases, there's not much in the "real world" yet besides pilots. I've been doing some interesting consulting work in this area, though - 2018 should throw up a lot more news.

But there has been far more noise - albeit often superficial - about public blockchain and token technologies. Few major telcos have (publicly) announced involvement, but there's growing attention from the type of smaller, competitive types of service provider. Think tier 2/3 MVNOs, travel-SIM providers, VoIP companies, messenger & mobile advertising providers and so on, rather than big carriers. [Telenor is working with a content-oriented token provider - link]

Obviously, that fits against a wider background of interest and investment in cryptocurrencies. Whether we're witnessing the birth of a new financial/transactional system, or a possible bubble, I'll leave for others to debate. To me, it looks a bit like 1995 - lots of innovative web companies, but also a lot of ridiculous concepts, with valuations to match. Which are the Amazons of the future - or the Altavistas, or the pets.com's - I'll leave to others to work out.

There has also been a corresponding rise in regulatory concern, and growing focus on so-called "utility tokens", where in theory a given coin isn't just a store of value or a payment mechanism, but has some underlying property that makes it of broader use to consumers or businesses. Typically this means that some other capability can be "tokenised" - which could be anything from property to an artist's work, and used within that business activity. 

Incidentally - one interesting comms-related trend that's appeared recently is the use of Telegram* (and some other group-messaging apps) as a mobile-friendly and anonymous/encrypted discussion & announcement forum for cryptocurrency teams. Many of the tokens use Telegram as an addition to public (often spam-infested) chat on Twitter, and private internal Slack channels, plus assorted blogging and forum tools. I haven't seen any with an RCS messenger link, obviously.

*EDIT: Telegram has just announced its *own* ICO plans, literally hours after I posted this. Details here (link)

What telecoms/networking tokens are available?

A growing number of tokens relate to things which look "telecoms-like" - whether that's data connectivity provided via cellular or WiFi, SMS or instant-messenger functions, voice-call minutes, SIM identities or something else similar. 

Some are trying to resell existing users' quotas or attention or connectivity, while others are trying to build new hardware platforms. Some are trying to create meshes or secure peer-to-peer connectivity, while others are looking to be wholesale marketplaces for service providers to offer smart-contracts to consumers (or other SPs).

(There's also another huge set of tokens for IoT-related functions and applications, but I'll consider those another time). 

Note: I'm using token, coin, cryptocurrency, altcoin etc interchangeably. Various people will assert differences vigorously, but it's not something that is relevant here.

Note 2: This is being written on 7th January 2018, so dates / funding & issuance status are accurate as of today, but obviously changing at a rapid pace.

Note 3: I am NOT making any recommendations by mentions here. Various ICOs and tokens have been of questionable quality, valuations are volatile & sometimes ridiculous, and some are rumoured to be outright scams. Be extremely careful.

Note 4: I've probably missed some out. Get in touch if you want to tell me about your telecom/network coin, or give me a detailed briefing on the ones below.

  • Airfox, Airtoken $AIR (link): Attempts to draw a link between mobile prepay credits, advertising, user-data and potentially micro-loans in future. It extends the current model of gifting or sending "recharges" to many international mobile operators' prepay customers, by shifting from normal payments to a cryptocurrency bought in a marketplace or earned by viewing ads. 
  • Althea (link): Aiming to build a network of WiFi and other wireless networks, underpinned by cryptocurrency micropayments and incentives. Recently decided against an ICO, in favour of being "cryptocurrency neutral" - see blog here
  • Ammbr [DISCLOSURE: I am an advisor], Ammbr, $AMR (link). Private investor funded, but tokens being listed on exchanges soon. Developing a hardware mesh networking system [Wi-Fi & other technologies], linked to blockchain-based micropayment and self-sovereign identity platform. Aiming first at locations with "unconnected" or poorly-connected communities, but with broader applicability.
  • Birdchain, $BIRD (link): Pre-ICO. Developing a messaging app & platform for users to re-sell their SMS allocation for application-to-person messaging 
  • Blocknum, $GIGA token (link) Token sale currently occuring. Looking at using the telephone network (PSTN), SIP signalling [used for VoIP] and phone numbers as a basis for a new blockchain for transactions.
  • Bubbletone, Universal Mobile Token, $UMT (link). Currently doing pre-sale before ICO. Intending to be a marketplace for MNOs/MVNOs to publish data-plans or content services as smart contracts, with the plans/identities pushed down to users via multi-IMSI SIM cards, or as eSIM profiles. Aims to remove premiums for roaming. 
  • Crypvisr, $CVN (link): ICO in 2017, listing on exchanges due soon. Encrypted messaging/communications platform, aimed at both consumers and enterprises.
  • DENT Wireless Dent-coin, $DNT (link). Platform for mobile data plan & allowance purchase and sale. Aiming to remove roaming fees. Early app version is live.
  • EncryptoTel, $ETT (link): Token-based enterprise "cloud PBX" communications system. 
  • Mobilink, Mobi-Coins $MOBI (link). Upcoming ICO. Attempting to create an ad-funded mobile voice and data service, with a custom SIM card and network of MNO/MVNO relationships.  
  • Mysterium, $MYST, (link) Decentralised VPN aiming to allow people to share unused network capacity, and use encryption to reduce the risk of intrusive data analytics of Internet usage by ISPs. It's a bit similar to Tor, but more flexible
  • Qlink, $QLC (link): Token sale ongoing. Platform for sharing & micropayments for a variety of telco "assets", starting with WiFi access & then aiming for cellular data, SMS and content. Also planning own access points, including LTE-U unlicenced cellular.
  • Rightmesh, $MESH (link): Upcoming ICO. Creating an incentivised device-to-device mesh (WiFi, Bluetooth etc). The company operating it (called Left.io) also offers another device-to-device communications/sharing app called Yo.
  • Smartmesh, $SMT (link) Tokenised device-to-device mesh based on WiFi, Bluetooth LE etc., starting with smartphones connecting via an incentivised peer-to-peer mechanism.
  • SMSChain, $SMSTO, (link): Creating a decentralised SMS gateway for application-to-person text messages. Incentivises users to donate their unused SMS quotas, via a mobile app. Cancelled proposed ICO (link) & may list tokens on exchanges at later date.
  • Telcoin, $TEL, (link): Payment/money-transmission token intended to be distributed through existing mobile operators, and aggregators.
  • Telegram, Grams: [Added as this emerged shortly after I published this - see link] The messenger app is considering a huge ICO and token sale, which could allow it to embrace payments and money-transfer, and perhaps other applications to become a cryptocurrency-enriched competitor to WeChat and FB Messenger.

What could possibly go wrong? A lot.

A lot of my work as an analyst and consultant involves "stress-testing" ideas and business-plans. Many concepts sound interesting, but face challenges of practicality - whether that's technical, commercial, legal or other. Reading through a lot of the tokens' documentation, or speaking to project teams, I see a lot of aspirations that are going to bang heads against reality.

Some problems can be fixed with time, or clever developers. Others are going to be intractable, and will need workarounds, or completely different strategies.

In this post, I'm not offering opinions or reviews of individual tokens, although I have private opinions on a number of them. A lot of what I read could be best described as "aspirational" - and in some cases, there are many layers of complexity or problems ahead, and I anticipate pivots and revised expectations, as practical issues come to light. Some that I've seen look completely naive or muddle-headed (or even, whisper it, fraudulent).

Some of the issues that could derail the various tokens' opportunity and prospects include:
  • Most existing telecom plans (fixed and mobile) have terms and conditions that prohibit resale of "unused capacity" - and are likely to be updated with new token-proof T's & C's if risks are seen.
  • Most MVNOs will also have a range of limitations in their contracts, from their host MNOs.
  • Security - everything new comes with its own novel risks, even if the blockchain itself is secure. For instance, would you fancy having your 2FA password codes sent via SMS, that transits some random person's phone and app?
  • Nobody likes paying for stuff (even micropayments) if it's also available for free via a different path. That means that there will be a lot of arbitrage - for example, it's hard to compete against free WiFi, or against the newer "roam like home" packages.
  • Nobody likes paying for stuff in a "currency" that changes in value compared to normal money. I don't want to use some sort of converter to know how many pennies it'll cost for a phone call or Wi-Fi connection.
  • There's all sorts of regulatory horribleness around telcos, at national, regional and global levels. Trying to assert "it's all decentralised, we don't need to follow the rules" won't work if it involves licensed spectrum, or messing with legal rules on registering network users' identities, lawful intercept etc.
  • Running anything blockchain-related on a smartphone uses power & battery - especially if it needs to keep radio connections active as well. Power-management is always a challenge.
  • Traditional telecom networks have complex operational and billing software. While some is too-inflexible and very expensive, most is a necessary evil to deal with performance management, customer service, creating innovative plans, deal with inter-party revenue-sharing and so on. In a decentralised world, how do you query charges, or call when something fails? How can you watch for problems emerging? (And who watches?)
  • The hard part of getting data connections working is often "backhaul", linking a base station or WiFi access point to the main Internet, especially from remote areas. It's quite hard to tokenise digging up roads to install fibres.
  • Slow deployment of eSIM-capable devices & back-end infrastructure, and willingness of carriers to offer remotely-provisioned "profiles" to third parties.
  • Private cellular networks (even in unlicensed / shared spectrum) need core-network software and numerous other "moving parts". Deploying LTE-U isn't like buying a Wi-Fi access point from a store & setting it up.
  • A lot of existing consumer Wi-Fi access points are provided by cable operators & broadband telcos, and integrated with a modem/router. Most people won't want to replace them, or daisy-chain a second device, or re-flash the hardware. Business Wi-Fi systems are usually locked-down by IT departments.
  • Anything using a mobile app for control, mining, transaction or advertising is at the whim of Apple's AppStore rules, and to a lesser degree Google's. They also need to deal with updates to features in new versions of iOS and Android, which may break things, or compete with them.
  • All of the various parallel schemes will need to inter-work with each other at some point, if they're successful.
  • Adding extra latency because of extra network hops (or worse, payment negotiations) is going to be a lousy user-experience. 
  • The Internet and telecoms are very bi-directional. Do packets (or SMSs or calls) in both directions get charged the same amounts?
  • Advertising-funded mobile connectivity has been tried multiple times, and has multiple problems. In particular, you can't insert ads into most apps, and use of encryption/privacy tools like VPNs mean that cookies in mobile browsers may not work properly forever.
There's probably another 20-100 similar "gotchas" out there, applying to some or all of the token concepts. Part of my work is trying to predict these types of problem before they arise, and have an idea of how tractable they are, and what workaround might exist. If you're an innovator in this space, or an investor, and want someone to cast a critical eye over a project, get in touch. (information AT disruptive-analysis DOT com, or on LinkedIn)

Ironically one area that's almost certainly overestimated as a problem is anything to do with Net Neutrality, though. I've covered various examples of such nonsense in prior posts, such as this one (link).

It should be noted that many of these tokens are thinly-traded, or even unlisted on any major cryptocurrency exchanges. Some are pre-ICO / private-funding. Please note that I offer no recommendations on investing in anything, especially cryptocurrencies. Do your own research and use extreme caution if you're tempted. 


The tokenisation of telecoms and networks is evolving rapidly. It's genuinely fascinating, as are the potential uses of private/permissioned blockchains inside telcos. However, anyone expecting decentralisation to change the networking world in 2018 (or 2019) is going to be disappointed. 

There's lots of enthusiasm, but many roadblocks in the way. Many of the concepts are likely to prove unworkable - and while some projects may raise enough funds through ICOs or private investors to allow them to pivot, others will likely fail. If you're speculating in the short term, that might not matter. But be aware that harsh realities will come along with the new opportunities.

Please get in touch if you'd like to get deeper analysis, or if you're looking for advisory input as a project team or investor (although I'm not able to give investment recommendations).   

Tuesday, December 19, 2017

Emerging risks to telcos from "Cuckoo Platforms"

  • Telcos want to be platform players at varying points in their network architecture and service offerings. 
  • But successful platforms generally need "anchor tenants" to gain scale.
  • The problem comes when anchor-tenants are themselves other 3rd-party platforms.
  • There is a risk of platforms-on-platforms acting as "cuckoos", pushing the native owner's eggs out of the nest.
  • Telcos face a risk from major cloud platforms overwhelming their MEC edge-compute platforms.
  • ... and a risk from major AI-based commerce platforms overwhelming their messaging, voice and IoT platforms.
  • Other future platforms also face similar challenges.
  • To succeed as platform providers, telecom operators need to have their own anchor-type services, and to have a well-designed approach to combating the risk of parasitic cuckoo platforms.

Background: the Internet overcame its broadband host

The cuckoo bird is infamous for laying its eggs in other birds' nests. The young cuckoos grow much faster than the rightful occupants, forcing the other chicks out - if they haven't already physically knocked the other eggs overboard. (See "brood parasitism", here).

Analogies exist quite widely in technology - a faster-growing "tenant" sometimes pushes out the offspring of the host. Arguably Microsoft's original Windows OS was an early "cuckoo platform" on top of IBM's PC, removing much of IBM's opportunity for selling additional software. 

In many ways, Internet access itself has outgrown its own host: telco-provided connectivity. Originally, fixed broadband (and the first iterations of 3G mobile broadband) were supposed to support a wide variety of telco-supplied services. Various "service delivery platforms" were conceived, including IMS, yet apart from ordinary operator telephony/VoIP and some IPTV, very little emerged as saleable services.

Instead, Internet access - which started using dial-up modems and normal phone lines before ADSL and cable and 3G/4G were deployed - has been the interloping bird which has thrived in the broadband nest instead of telcos' own services. It's interesting to go back and look at the 2000-era projections for walled-garden, non-Internet services.

The need for an anchor tenant

The problem is that everyone wants to be a platform player. And when you're building and scaling a new potential platform, it's really hard to turn down a large and influential "anchor tenant", even if you worry it might ultimately turn out to be a Trojan Horse (apologies for the mixed metaphor). You need the scale, the validation, and the draw for other developers and partners.

This is why the most successful platforms are always the one which have one of their own products as the key user. It reduces the cannibalisation risk. Office is the anchor tenant on Windows. iTunes, iMessage and the camera app are anchors on iOS. Amazon.com is the anchor tenant for AWS.

Unfortunately, the telecoms industry looks like it will have to learn a(nother) tough lesson or two about "cuckoo platforms".

MEC is a tempting nest

The more I look at Multi-Access Edge Computing (MEC), the more I see the risks of a questionable platform strategy. Some people I met at the Small Cells event, in the US a couple of weeks ago, genuinely believe it can allow telcos to become some sort of distributed competitor to Amazon AWS. They see MEC as a general-purpose edge cloud for mainstream app and IoT developers, especially those needing low-latency applications. 

I think this is delusional - firstly because no developer will want to deal with 800 worldwide operators with individual edge-cloud services and pricing, secondly because this issue of latency is overstated & oversimplified (see my recent post, link), and thirdly because a lot of edge-computing tasks will actually be designed to reduce the use of the network and reliance/spend on network operators.

But also, this "MEC as quasi-Amazon" strategy will fail mostly because the edge/distributed version Amazon will be Amazon. The recent announcement by Nokia that it will be implementing AWS Greengrass in its MEC servers is a perfect example (link). I suspect that other MEC operators and vendors will end up acting as "nests" for Azure, IBM Bluemix and various other public cloud providers.

Apologies for the awful pun, but these "cloud-cuckoos" will use the ready-made servers at the telco edge to house their young distributed-computing services, especially for IoT - if the wholesale price is right. They will also build their own sites in other "deeper" network locations (link). 

In other words, telcos' MEC deployments are going to help the cloud providers become even larger. They may get a certain revenue stream from their tenancy, but this will likely be at the cost of further entrenching the major players overall. The prices paid by an Amazon-scale provider for MEC hosting are likely to be far lower than the prices that individual "retail" developers might pay.

(The real opportunity for MEC, in my view, lies in hosting the internal network-centric applications of the operators themselves, probably linked to NFV. Think distributed EPCs, security gateways, CDN nodes and so on. Basically, stuff that lives in the network already, but is more flexible/responsive if located at the edge rather than a big data centre).

End-running Messaging-as-a-Platform (MaaP)

Another example of platform-on-platform cannibalisation is around the concept of "messaging as a platform", MaaP. Notwithstanding WeChat's amazing success in China, my sense is that it's being vastly over-hyped as a potential channel for marketing and customer interaction. 

I just don't see the majority of people in other markets forgoing the web or optimised native apps, and using WhatsApp or iMessage or SnapChat or SMS as the centrepiece of their future purchases or "engagement" (ugh) with companies and A2P functions. But where they do decide to use messaging apps for B2C reasons, the chatbots they interact with will not be MaaP-dedicated or MaaP-exclusive

These chatbots will themselves be general "conversational platforms" that work across multiple channels, not just messaging, with voice as well as text, and with a huge AI-based back-end infrastructure and ongoing research/deployment effort. They'll work in messaging apps, browsers, smart speakers, wearables, car and general APIs for embedding in apps and all sorts of other contexts.

Top of the list of conversational platforms are likely to be Google Assistant, Amazon Alexa, Apple Siri, Microsoft Cortana and Facebook M, plus probably other emergent ones from the Internet realm.

MaaP is "just another channel" for broad conversational/commerce platforms

In other words, some messaging apps might theoretically become "platforms", but the anchor tenants will be "wholesale" conversational platforms, not individual brands or developers. In some cases they will again be in-house assistants (iMessage + Siri, or Google Allo + Assistant for instance). In other cases, they may be 3rd-party bot ecosystems - we already see Amazon Alexa integrated into numerous other devices.

Now consider what telcos are doing around MaaP. As well as extending their existing SMS business towards A2P (application-to-person), they have also allowed third-parties like Twilio to absorb much of the added value as cPaaS providers. And when it comes to RCS* which has an explicit MaaP strategy, they have welcomed Google as a key enabler on Android, despite its obvious desire to use it mainly as a free iMessage rival. (*obviously, I'm not a believer in RCS succeeding for many other reasons as well, but let's leave that for this argument).

What the GSMA seems to have also missed is that Google isn't really interested in RCS MaaP per-se - it simply wants as many channels as possible for its Assistant, and its DialogFlow developer toolkit. To be fair, Google announced Assistant, and acquired API.AI (DialogFlow's original source) after it acquired Jibe. It's moved from mobile-first, to AI-first, since September 2015.

The Google conversational interface is not going to be exclusive to RCS, or especially optimised for it. (I asked the DialogFlow keynote speaker about this at last week's AI World conference in Boston, and it was pretty clear that it wasn't exactly top-of-mind. Or even bottom-of-mind). Google's conversational platform will be native in Android, in other messaging apps like Allo, Chrome, Google Home and presumably 1000 other outlets.

From an RCS MaaP perspective, it's a huge cuckoo that will be more important than the Jibe platform. There is no telco "anchor tenant" for RCS-MaaP as far as I can tell - I haven't even seen large deployment of MNOs' own customer-care apps using it. If I was an airline's or a retailer's customer experience manager, and I was looking beyond my own Android & iOS apps for message-based interactions, I wouldn't be looking at creating an RCS chatbot. I'd be creating an Assistant chatbot, plus one for Alexa and maybe Siri.

Can you cuckoo-proof a platform?

Apple, incidentally, has a different strategy. It tends to view its own services as integrated parts of a holistic experience. It tries to make its various platforms cuckoo-proof, especially where it doesn't have an anchor tenant app. This is a major reason for the AppStore policies being so restrictive - it doesn't want apps to be mini-platforms in their own right, especially around transactions. Currently, Google and Amazon are fighting their own mutual anti-cuckoo war over YouTube on Fire TV, and sales of Google Home on Amazon.com (link). Amazon and Apple are also mutually wary.

It's worth noting that telcos are sometimes pretty good at cuckoo-deterrence too. In theory, wholesale mobile networks could have a been a platform for all manner of disruptive interlopers, but in reality, MVNO deals have been carefully chosen to avoid commoditisation. A similar reticence exists around eSIM and remote SIM provisioning - probably wisely, given the various platform-on-platform concepts for network arbitrage that have been suggested.


In my view, both MEC and (irrespective of its many other failings) RCS are susceptible to cuckoo platforms. I also wonder if various telco-run IoT initiatives, and potentially network-slicing will become a platform for other platforms in future too.

One of the key factors here is a "the rush to platformisation". Platforms only succeed when they evolve out of already-successful products, which can become inhouse anchor tenants. Amazon's marketplace platform grew on the back of its own book and other retail sales. AWS success grew on the back of Amazon using its own APIs and cloud-computing.

MEC needs to succeed on the basis of telcos' own use of their edge-computing resources - which don't currently exist in a meaningful way, partly because NFV has been slower than expected. MaaP needs telcos' own messaging services and use-cases to be successful before it should look at external developers. With RCS, that's not going to happen.

Network-slicing needs to have telcos' own slices in place, before pitching to car manufacturers (or Internet players, again). IoT is the same too. Otherwise, expect even more telco eggs to be pushed out of the nest, as they help to foster other birds' offspring.

Monday, December 04, 2017

5G & IoT? We need to talk about latency

Much of the discussion around the rationale for 5G – and especially the so-called “ultra-reliable” high QoS versions – centres on minimising network latency. Edge-computing architectures like MEC also focus on this. The worthy goal of 1 millisecond roundtrip time is often mentioned, usually in the context of applications like autonomous vehicles with snappy responses, AR/VR headsets without nausea, the “tactile Internet” and remote drone/robot control.

Usually, that is accompanied by some mention of 20 or 50 billion connected devices by [date X], and perhaps trillions of dollars of IoT-enabled value.

In many ways, this is irrelevant at best, and duplicitous and misleading at worst.

IoT devices and applications will likely span 10 or more orders of magnitude for latency, not just the two between 1-10ms and 10-100ms. Often, the main value of IoT comes from changes over long periods, not realtime control or telemetry.

Think about timescales a bit more deeply:

  • Sensors on an elevator doors may send sporadic data, to predict slowly-worsening mechanical problems – so an engineer might be sent a month before the normal maintenance visit.
  • A car might download new engine-management software once a week, and upload traffic observations and engine-performance data once a day (maybe waiting to do it over WiFi, in the owner’s garage, as it's not time-critical).
  • A large oil storage tank, or a water well, might have a depth-gauge giving readings once an hour.
  • A temperature sensor and thermostat in an elderly person’s home, to manage health and welfare, might track readings and respond with control messages every 10 minutes. Room temperatures change only slowly.
  • A shared bicycle might report its position every minute – and unlock in under 10 seconds when the user buys access with their smartphone app
  • A payment or security-access tag should check identity and open a door, or confirm a transaction, in a second or two.
  • A networked video-surveillance system may need to send a facial image, and get a response in a tenth of a second, before they move out of camera-shot.
  • A doctor’s endoscope or microsurgery tool might need to respond to controls (and send haptic feedback) 100 times a second – ie every 10ms
  • A rapidly-moving drone may need to react in a millisecond to a control signal, or a locally-recognised risk.
  • A sensitive industrial process-control system may need to be able to respond in 10s or 100s of microseconds to avoid damage to finely-calibrated machinery
  • Image sensors and various network sync mechanisms may require response times measured in nanoseconds
I have not seen any analysis that tries to divide the billions of devices, or trillions of dollars, into these very-different cohorts of time-sensitivity. Given the assumptions underpinning a lot of 5G business cases, I’d suggest that this type of work is crucial. Some of these use-cases are slow enough that sending data by 2G is fine (or by mail, in some cases!). Others are so fast they’ll need fibre – or compute capability located locally on-device, or even on-chip, rather than in the cloud, even if it’s an “edge” node.

I suspect (this is a wild guess, I'll admit) that the proportion of IoT devices, for which there’s a real difference between 1ms and 10ms and 100ms, will be less than 10%, and possibly less than 1% of the total. 

(Separately, the network access performance might be swamped by extra latency added by security functions, or edge-computing nodes being bypassed by VPN tunnels)

The proportion of accrued value may be similarly low. A lot of the IoT examples I hear about are either long time-series collections of sensor data (for asset performance-management and predictive maintenance), or have fairly loose timing constraints. A farm’s moisture sensors and irrigation pumps don’t need millisecond response times. Conversely, a chemical plant may need to alter measure and alter pressures or flows in microseconds.

Are we focusing 5G too much on the occasional Goldilocks of not-too-fast and not-too-slow?