• JoomlaWorks Simple Image Rotator
  • JoomlaWorks Simple Image Rotator
Telecom Blog Feeds
Dean Bubley's Disruptive Wireless
Dean Bubley's Disruptive Wireless: Thought-leading wireless industry analysis

  • Telecom regulation and blockchain - is #RegTech the killer application?

    One of the most interesting developments in telecoms technology for a while occurred this week ? India?s telecom regulator TRAI issued a set of draft regulations aimed at combating spam and nuisance calls. (link)

    At first glance, you could be forgiven for asking why anti-spam rules could possibly be more important than all the hoopla about 5G, market consolidation, network-slicing and, especially, ?digital transformation? or RCS messaging (I jest).

    The reason is in the details: TRAI has stipulated that telcos should use blockchain-based technologies to enforce its proposed rules, creating a tamper-proof and encrypted ledger of consent records, given by users for opt-in telemarketing. If the rules translate to reality, this is a major step forward in commercialisation of digital ledger technology, and at scale.

    "Access  Providers  shall  adopt  Distributed  Ledger  Technology  (DLT)  with
    permissioned and private DLT  networks for  implementation of  system, functions and processes as prescribed in Code(s) of Practice: -
    (1) to  ensure  that  all  necessary  regulatory  pre-checks  are  carried  out  for  sending
    Commercial Communication;
    (2) to operate smart contracts among entities for effectively controlling the flow of Commercial Communication;
    Access Providers may authorise one or more DLT network operators, as deemed fit, to provide technology solution(s) to all entities to carry out the functions as provided for in these regulations."

    But in my view, this could be just the tip of a quite large iceberg. I'm starting to think that regulatory uses for blockchain (especially private/permissioned versions) could be central to the technology's success in telecoms.

    Innovation in Regulation Technology, or RegTech, is already a huge domain, especially in sectors like financial services and healthcare. Historic methods for regulatory enforcement, from money-laundering rules, to certification of professionals, have often used reams of paperwork and had cumbersome processes. There is a huge need for automation, better provision of security and authentication, and simpler online access to regulatory resources and approval.

    Obviously, telecoms has itself long had technical means for creating and enforcing rules, from spectrum-monitoring and radio-coverage tools, through automated platforms for telecoms licensing, to software aimed at checking broadband QoS and spotting net-neutrality violations.

    But given that a lot of telecoms rules tend to involve multiple parties (eg user, telco, advertiser as here, or multiple telcos doing interconnect or wholesale agreements), requirements for "credentials", and there are often registries and other databases involved, the whole sphere looks like an archetypal match for the types of capability normally found in blockchains.

    In particular, I think there are many potential use-cases for regulators to assist - or keep tabs on - telco activities that relate to regulatory policy. Adding unarguable timestamps to tamper-proof data storage has huge potential, in particular. Ones that immediately leap out to me include:
    • Number portability databases and porting requests
    • Storage of call detail records, that may be subject to lawful request at a later date
    • Spectrum allocations and permissions, especially for shared, local and dynamic spectrum models.
    One other that I think has longer-term potential, but which nobody has talked about yet, is in secure and encrypted storage of network configuration and log files. One of the problems with regulating wholesale interconnect, peering, net neutrality and other rules, is that it is exceptionally hard to prove what happened retrospectively, if someone makes a complaint. This issue will be exacerbated with NFV/SDN, and the move to network slicing, when network configurations will be temporary and highly dynamic.

    Given that law-enforcement insists that ISPs retain theur users' data records, it doesn't seem unreasonable to retain the ISPs' own information as well - obviously in a form that's secure and encrypted unless needed for evidence in the case of a legal intervention. It could also make a clear distinction between a problem of network failure (or happenstance in the way the maths of contention works), and deliberate actions.

    The Net Neutrality angle here is particularly potent - it would allow any egregious behaviour to be dealt with post-hoc. Most anti-neutrality lobbyists dislike ex-ante regulation, but few could argue against allowing competition authorities or others from investigating alleged infringements that occurred deep inside the network's configurations and policies.

    I'm just musing here, but I definitely feel that there's a lot more to telecom #RegTech using #blockchain than just tracking spam calls and SMS. 

    This is one of the topics that will get discussed at my upcoming workshop on telecoms blockchain, on July 3 in London. Full details are here (link) or email information AT disruptive-analysis dot COM

  • MEC and network-edge computing is overhyped and underpowered
    I keep hearing that Edge Computing is the next big thing - and specifically, in-network edge computing models such as MEC. (See here for a list of all the different types of "edge"). 

    I hear it from network vendors, telcos, some consultants, blockchain-based startups and others. But, oddly, very rarely from developers of applications or devices.

    My view is that it's important, but it's also being overhyped. Network-edge computing will only ever be a small slice of the overall cloud and computing domain. And because it's small, it will likely be an addition to (and integrated with) web-scale cloud platforms. We are very unlikely to see edge-first providers become "the next Amazon AWS, only distributed".

    Why do I think it will be small? Because I've been looking at it through a different lens to most: power. It's a metric used by those at the top- and bottom ends of the computing industry, but only rarely by those in the middle, such as network owners. This means they're ignoring a couple of orders of magnitude.

    (This is a long post. You might want to grab a coffee first....)

    How many zeroes?

    Cloud computing involves huge numbers. There are many metrics that you can use - numbers of servers, processors, standard-sized equipment racks, floorspace and so on. But the figure that gets used most among data-centre folk is probably power consumption in watts, or more commonly here kW, MW & GW. (Yes, it's a lower-case k for kilo). 

    Power is useful, as it covers the needs not just of compute CPUs and GPUs, but also storage and networking elements in data centres. It's not perfect, but given that organising and analysing information is ultimately about energy it's a valid, top-level metric. [Hey, I've got a degree in physics, not engineering. Helloooo, thermodynamics & entropy!]

    Roughly speaking, the world's big data centres have a total power consumption of about 100GW. A typical one might have a capacity of 30MW, but a number of the world's largest data centres already use over 100MW individually, and there are enormous plans for locations with 600MW or even 1GW (link). No, they're not all running at full power, all the time - but that's true of any computing platform.

    This growth is partly driven by an increase in the number of servers and equipment racks needed (hence growing floor-space for these buildings). But it also reflects power consumption for each server, as chips get more powerful. Most equipment racks use 3-5kW of power, but some can go as high as 20kW if that power - and cooling - is available.

    So, to power "the cloud" needs 100GW, a figure that is continuining to grow rapidly. We are also seeing a rise in smaller, regional data-centres in second- and third-tier cities. Companies and governments often have private data-centres as well. These vary quite a bit, but 1-5MW is a reasonable benchmark.

    How many decimal places?

    At the other end of the computing power spectrum, are devices, and the components inside them. Especially for battery-powered devices, managing the power-budget down to watts or milliwatts is critical. This is the "device edge".

    • Sensors might use less than 10mW when idle & 100mW when actively processing data
    • A Raspberry Pi might use 0.5W
    • A smartphone processor might use 1-3W
    • An IoT gateway (controlling various local devices) might be 5-10W
    • A laptop might draw 50W
    • A decent crypto mining rig might use 1kW

    New innovations are pushing the boundaries. Some researchers are working on sub-milliwatt vision processors (link). ARM has designs able to run machine-learning algorithms on very low-powered devices.

    But perhaps the most interesting "device edge" is the future top-end Nvidia Pegasus board, aimed at self-driving vehicles. It is a 500W supercomputer. That might sound a lot, but it's still less than 1% of the engine power on most cars. A top-end Tesla P100D puts over 500kW to the wheels in "ludicrous mode", or 1000x that figure. Cars' aircon might use 2kW, to give context.

    Of course, all of these device-edge computing platforms are numerous. There are billions of phones, and hundreds of millions of vehicles and PCs. Potentially, we'll get 10s of billions of sensors. Most aren't coordinated, though. 

    And in the middle?

    So we have milliwatts at one end of distributed computing, and gigawatts at the other, from device to cloud.

    So what about the middle, where the network lives?

    There are many companies talking about MEC (multi-access edge computing) and fog-computing products, with servers designed to run at cellular base stations, network aggregation points, and also in fixed-network nodes and elsewhere. 

    Some are "micro-data-centres" capable of holding a few racks of servers near the largest cell towers. The very largest might be 50kW shipping-container sized units, but those will be pretty rare and will obviously need a dedicated power supply.

    It's worth noting here that a typical macro-cell tower might have a power supply of 1-2kW. So if we consider that maybe 10% could be dedicated to a compute platform rather than the radio (a generous assumption), we get 100-200W, in theory. Or in other words, a cell tower edge-node will be less than half as powerful as a single car's computer.

    Others are smaller server units, intended to hook into cellular small-cells, home gateways, cable street-side cabinets or enterprise "white boxes". For these, 10-30W is more reasonable.

    Imagine the year 2023

    Let's think 5 years ahead. By then, there could probably be 150GW of large-scale data centres, plus a decent number of midsize regional data-centres, plus private enterprise facilities.

    And we could have 10 billion phones, PCs, tablets & other small end-points contributing to a distributed edge, although obviously they will spend a lot of time in idle-mode. We might also have 10 million almost-autonomous vehicles, with a lot of compute, even if they're not fully self-driving. 

    Now, imagine we have a very-bullish 10 million "deep" network-compute nodes, at cell sites large and small, built into WiFi APs or controllers, and perhaps in cable/fixed streetside cabinets. They will likely have power ratings between 10W and 300W, although the largest will be numerically few in number. Choose 100W on average, for a simpler calculation. (Frankly, this is a generous forecast, but let's run with it for now).

    And let's add in 20,000 container-sized 50kW units, or repurposed central-offices-as-datacentres, as well. (Also generous)

    In other words, we might end up with:

    150GW large data centres
    50GW regional and corporate data centres
    20,000x 50kW = 1GW big/aggregation-point "network-edge"
    10m x 100W = 1GW "deep" network-edge nodes
    1bn x 50W = 50GW of PCs
    10bn x 1W = 10GW "small" device edge compute nodes
    10m x 500W = 5GW of in-vehicle compute nodes
    10bn x 100mW = 1GW of sensors & low-end devices

    Now admittedly this is a very crude analysis. And a lot of devices will be running idle most of the time, and may need to offload functions to save battery power. Laptops are often switched off entirely. But equally, network-edge computers won't be running at 100%, 24x7 either.

    The 1% edge

    So at a rough, order-of-magnitude level, we can see that the total realistic "network edge", with optimistic assumptions, will account for less than 1% of total aggregate compute capability. And with more pessimistic assumptions, it might easily be just 0.1%. 

    Any more will simply not be possible to power, unless there are large-scale upgrades to the electricity supply to network infrastructure - installed at the same time as backhaul upgrades for 5G, or deployment of FTTH. (And unlike copper, fibre can't even power small devices on its own). And haven't seen announcements of any telcos building hydroelectric power stations anywhere.

    Decentralised, blockchain-based edge "fogs" are unlikely to really solve this problem either, even if they also use decentralised, blockchain-based power supply and management.

    Now it could be argued that this 0.1-1% of computing workloads will be of such pivotal importance, that they will bring everything else into their orbit and indirect control. Could the "edge" really be the new frontier? 

    I think not.

    In reality, the reverse is more likely. Either device-based applications will selectively offload certain workloads to the network, or the webscale clouds will distribute certain functions. Yes, there will be some counter-examples, where the network-edge is the control point for certain verticals or applications - I think some security functions make sense, for instance, as well as an evolution of today's CDNs. But will IoT management, or AI, be concentrated in these edge nodes? It seems improbable.

    Conclusion & TL:DR

    In-network edge-computing architectures, such as MEC, will become more important. There are various interesting use-cases. But despite that, they will struggle to live up to the hype. 

    There will be almost no applications that run *only* in the network-edge - it?ll be used just for specific workloads or microservices, as a subset of a broader multi-tier application. The main compute heavy-lifting will be done on-device, or on-cloud. As such, collaboration between edge-compute providers and industry/webscale cloud will be needed, as the network-edge will only be a component in a bigger solution, and will only very rarely be the most important component. 

    One thing is definite: mobile operators won?t become distributed quasi-Amazons, running image-processing for all nearby cars or industry 4.0 robots in their networks, linked via 5G. 

    Yes, MEC nodes could host Amazon Greengrass or other functions on a wholesale basis, but few developers will want to write directly to telcos' distributed-cloud APIs on a standalone basis, with or without network-slicing or 5G QoS mechanisms.

    Indeed, this landscape of compute resource may throw up some unintended consequences. Ironically, it seems more likely that a future car's hefty computer, and abundant local power, could be used to offload tasks from the network, rather than vice versa.

    Comments and feedback are very welcome. I'm aware I've made many assumptions here, and will doubtless generate various comments and detailed responses, either on my blog or LinkedIn posts. I haven't seen an "end to end" analysis of compute power before - if there's any tweaks to my back-of-envelope calculations, I'd welcome suggestions. If you'd like to contact me about projects or speaking engagements, I can be reached via information at disruptive-analysis dot com.

  • 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.

  • 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).   

    • 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.

    Joomla Templates by Joomlashack