Emerging risks to telcos from "Cuckoo Platforms"

Summary

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


Conclusions

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.

Data-over-Sound: An interesting approach to connectivity

I cover three main areas in my research & advisory work:

• Communications networks & services - mobile network evolution, IoT connectivity, telco business models and policy, and so on
• Communications applications & technologies - voice, video, messaging, UC etc
• Communications futurism - the intersection of comms. with other domains such as AI, IoT, blockchain, VR/AR and so forth 

All are evolving at speed, sometimes linked and sometimes in orthogonal - or even opposite - directions. Sometimes the intersections of these various threads yield some surprising combinations and innovations, which are interesting to explore.

I've just written and published a white paper for a client (Chirp.io), on one such intersection - the use of audio signals for short-range communications, or Data-over-Sound. It can be downloaded here (link). The easiest way to think about it is as an alternative to NFC or QR-codes for certain applications - but usable by any device with a microphone/speaker, and with less need for physical proximity or cumbersome pairing like Bluetooth. It's applicable to both normal phones and PCs, and also a variety of IoT devices.

(As always when I write documents like this, I have a stringent set of rules about my editorial independence. Given my normal "spikiness" when I write, in practice it means I need to have broadly-aligned opinions in advance. I've turned down writing papers when I've known the client wouldn't like the views & conclusions in the final report).

The emerging Data-over-Sound sector is currently quite fragmented, and has a mix of new platform players and point-solutions, integrated into customised vertical applications. It's being used for mobile payments in India, device-pairing for UC meeting-room whiteboard applications, and even between robots. Other use-cases exist in retail, advertising/marketing, ticketing and other domains. It can use both audible and inaudible frequency ranges.

In some ways it's similar to technologies like WebRTC, in that it's a capability rather than a product/service in its own right. It still needs some expertise to integrate into an application - and indeed, enough people with "vision" (OK, OK, hearing & inner voice...) to recognise the possible use-cases.  Ideally, it could benefit from more standards, better interoperability, the emergence of extra tools and platforms - and also some ethical standards around things like privacy & security, especially where ultrasound is used covertly.

I don't think Data-over-Sound is going to revolutionise the entire world of connectivity - the same way I'm always skeptical when people claim blockchain is "a new Internet". But I think it should be an important addition to device-to-device communications (I've never viewed NFC positively), and should yield a range of beneficial applications as awareness grows, and applications/tools mature. (And hey, who doesn't like technologies that let your phone speak R2D2 - video link)

The download link, again, is here. The paper gives some background to the technology and use-cases, as well as discussing the emerging structure of the sector.

Quick thoughts on MWC from afar

I'm not in Barcelona this week.

I stopped going to MWC a few years ago, when the hassle and costs involved started outweighing the benefits. One year I had 400 requests for meetings, and it took me a solid 2 weeks of email just to sort my diary. No more - I prefer smaller events, which have the added benefit of fewer "messages" being hammered into my skull by stressed marketing execs and their PR/AR minders.

But I am watching from afar, scanning Twitter and a few webcasts for nuggets of insight, from the comfort of my sofa, bed or local artisan coffee place.

A couple of quick observations so far:

• The most intriguing announcement is the Cisco/Ericsson blending of VoLTE and Cisco's Spark collaboration and messaging app (link). Although the PR is carrier-focused and around selling UCaaS, I suspect the real story is yet to come. Both companies also have close relationships with Apple and IBM. And I suspect that a future enterprise-centric solution could combine private (or virtual-private) mobile networks, optimised iPhone/iPad experience, maybe eSIM, Siri, Watson integration and more. Let's see if there's any different messaging, or more detail, at Enterprise Connect next month, the big UC/UCaaS shindig in Orlando. I'll be there, unlike MWC, as it gets the signal/noise ratio right. [Sidenote: if anyone at Ericsson or Cisco is now thinking "hmm, sounds interesting.... why haven't we thought of that?" then get in touch with me!]
• Nokia's reinvention continues. On its analyst/press webcast yesterday, it made a big deal about verticals and enterprise-related activities too. Utilities, transport, public sector and "webscale" companies were namechecked, including (again) private cellular either standalone or in partnership with classical MNOs. It also highlighted optical and IP networks (which came with the ALU acquisition) which was an interesting choice for a mobile event. Props to CEO Rajeev Suri for using "Webscale" instead of the pejorative "OTT": much more mature and inclusive language. 
• There's an awful of of 5G-washing going on, unsurprisingly, with plenty of references to its supposedly world-changing abilities. Governments and policymakers have all swallowed the 5G spin, without realising it's mostly just a pitch for more spectrum. Yet the GSMA head Mats Granryd talked in his keynote about 1.1 billion users in 2025. Given half of those (or more) are likely to be smartphones, that suggests that maybe 500m, at most, will be 5G IoT devices. Which, depending on your preferred overhyped forecast number, implies about 1-4% of the total IoT universe in 2025 - hardly the most indispensable enabler of the overall automated society of the future, nor an indicator that a spectrum monoculture policy is desirable. Doesn't suggest billions in new value from network-slicing capabilities, either. In a nutshell, 5G is important, but it's not the gamechanger many assert. Use the hashtag #5Gwash to call people out on it.
  
• The most-discussed new handset is HMD Global's new take on the classic Nokia 3310. As well as its retro looks, it sports a month-long battery, the Snake game, and a whole two (count 'em!) generations of cellular technology. That's right, it's a good-ole 2G GSM, calls+SMS device. Plus, it comes in a dual-SIM version. That's proper plastic SIMs, naturally, not this newfangled eSIM stuff. Sounds like a great backup device for 2-factor authentication when your main phone breaks or gets stolen.  
• GSMA published an eBook on "Messaging as a Platform" (link), tying its MaaP vision to RCS. There's a lot of generic stuff about chatbots, AI and "conversational commerce" in there, without explaining how it relates to a useless messaging service which isn't even a successful product, nor has any form of unifed API. Unless, as I suspect, it's aimed at making MNOs the distribution channel for Google's chat interface, Assistant and voice-recognition tools. Maybe there's a Google API / PaaS play to look forward to?  As I wrote last week, operators should ignore RCS and So-Called Advanced Messaging (yes, I like the acronym) and do more-relevant things instead. The same applies to contact-centre and multi-channel vendors: there are plenty of more-urgent things to look at. The GSMA's continued use of a Twitter SnapChat avatar points to the fact that platform status is earned not just imposed.
• The "official" announcement that Deutsche Telekom's immmr VoIP/messaging spin-off is using GenBand's Kandy cPaaS is interesting (link), although it was talked about informally last year at TADSummit (link). Looks like it's Internet/WebRTC-based and very much a good example of "post-IMS" mobile communications, with iOS and Android apps as well as browser access. No RCS nonsense visible, although I can imagine that DT's network-fundamentalist wing might have something to say about in future.

More MWC de-spinning if I get a chance over the next couple of days.

Facebook Workplace: Just collaboration, or parking its tanks on UCaaS & cPaaS lawns?

Facebook has finally launched its enterprise collaboration offering, changing its name to Workplace, from the original beta-tested Facebook at Work (link). It certainly isn't a full UCaaS product - but it wouldn't surprise me if it heads (somewhat) in that direction over time, or adds in integration or PaaS capabilities that allow it to compete indirectly in future.

It's aggressively priced, and mostly targetted at the Slack-style market for timeline- and messaging-centric collaboration, also known as WCC (workstream collaboration & communication). It's got a free trial, it's free for educational users, and for businesses it costs just $1-3 per month depending on size of deployment. (For comparison, Facebook's global consumer ARPU is around 4, mainly from advertising, although this is much higher in North America - link).

Clearly, it's majoring on large similarity in user-experience to its social networking platform, which is familiar to a large % of humanity. Likes, reactions, groups and so on are all replicated.

It also has some communications capabilities already - FB's Live video-streaming service is built into the main Workplace service, while it has a separate "companion" app (Work Chat - link) for IM and voice/video. I strongly suspect it is based on WebRTC, as its consumer equivalent is one of the biggest users of the technology today. Work Chat also has file/image-sharing and (not all entirely professional) stickers, which are basically glorified emoji. 

Interestingly, the iOS appstore page for Chat - which says it's already at Version 48 - has a screenshot focusing on voice rather than video, although that may just be because it hasn't updated it yet (there's an old website link to At Work rather than Workplace too).

Some other things I've noticed:

• It references trial user companies (for internal deployment) include telcos Telenor and Telekom Austria
• Its partners / distributors include a division of Phillipines telco PLDT
• Unsurprisingly, there's a big pitch on security, privacy and data-ownership for companies that may be suspicious of FB's record.
• There's a big pitch for non-desk workers such as those in restaurants, on ships or industrial facilities (who are mostly likely to be mobile-first / mobile only, and which are often well outside the traditional UC/UCaaS universe). 
• It's apparently air-gapped from the consumer Facebook platform - although given WhatsApp's recent history, some may speculate how long that lasts.
• There's a way to create multi-company groups for federation, and presumably closed groups for suppliers/customers/partners.
• Various 3rd-party providers of identity for single sign-on support (including G Suite and MS Azure).

In common with Slack and some other UC and WCC-type offers, it suggests that use of messaging and workstreams may reduce the need for voice/video realtime communications as well as email. Its FAQ says that "Companies find that they can eliminate or drastically reduce their need for internal collaboration tools such as their intranet, telephony systems, video conferencing and distribution lists."

That is quite telling for me: "reduce their need" implies that Facebook doesn't immediately see its role as replacing old phone systems or UC (or UCaaS), or that it intends to jump into the conferencing space. Perhaps I'm inferring too much, but I suspect it means:

• Facebook isn't interested in becoming a business phone system or normal UCaaS platform, especially with PSTN interconnect. In any case, it is unclear that businesses would accept it any time soon - it's taking Microsoft a long time to move on from IM/UC to telephony.
• The apparent enthusiasm of various telco partners could just indicate prudent curiosity - or could indicate a future alignment with network-based telephony and numbering, especially given Facebook's love of phone number-based 2-factor authentication.
• Also at present, Workplace isn't being set up as a mechanism for B2C communications, as many thought it might. In many ways, that's more a role for consumer Facebook (& consumer FB identities) and perhaps WhatsApp for chatbots. Businesses have to pay for various services around their pages already.
• However, it would be very unsurprising if Workplace became more of an integration platform in future. I can easily imagine it - or partners - building ways to link it to other telephony, conferencing or CRM/call-centre systems or cloud providers. 
• Workplace could potentially become a hub for Slack-style "collaboration as a platform", also being done in various ways by Cisco Spark, Symphony, Broadsoft Tempo, Unify Circuit and many others.
• Given Facebook's enthusiasm for live video-streaming, video-calling and other communications abilities (especially in-app on mobile) it would not surprise me to see a cPaaS play or acquisition at some point. I suspect it wouldn't aim to compete with Twilio directly, or some other UC-style rivals such as Nexmo/Vonage, but either Cisco/Tropo or Tokbox could be closer to the firing line. (Actually, Tokbox would be an interesting M&A target, if Telefonica decides it can't leverage it more than it does today).
• I expect that a major push will be made later around "events" which seems to be mostly missing from the current release, and which is a huge draw on the consumer service. Renaming it to "meetings" or "appointments" would make a lot of sense, and absorb much more communications traffic in consequence.
• Facebook has perhaps the best way to categorising personal "context" of any company. Its status updates have a great set of tags of location, doing/feeling activities, tagged colleagues/friends and so forth. It has the potential to leverage this in Workplace to create a really interesting platform for Contextual Communications.

Overall, I think that Facebook Workplace looks like a much more subtle and oblique entry to enterprise communications than some people expected. It's not aiming to replace UC/UCaaS outright, but instead to gradually divert (steal?) a growing slice of the overall employee-to-employee (or cross-company) communications pie. This is very different to the way that the traditional enterprise comms companies like Cisco or Avaya or various cloud-based providers are going, where they typically aim to be at the centre of a firm's communications, radiating outward from phone or conferencing. Instead, Workplace seems to be a play for adjacency, siphoning off use from email and Slack and peripheral (often unloved) UC features, at a low price point.

If companies can get over their privacy-wariness from Facebook's consumer reputation, it has quite a lot of potential. I also suspect it could be seen as attractive as a channel play by some telcos' enterprise business units, especially where they have minimal mobile footprint today. It would probably sit alongside other UCaaS offers rather than replace them. Thus far, it's a bit unclear what Microsoft plans to do with LinkedIn, but that's also in the same universe.

But Workplace also represents a starting-point for some really interesting future cPaaS and integration plays. Facebook's familiar UI - and its vast realm of heritage and skill in design and UX - could be a gamechanger. It is rightly eschewing "boring old business phone systems" for now - but should be able to help create a variety of new voice and video experiences in subsequent enhancements, if it proves the basics, gains scale quickly, and mitigates residual concern about security and privacy.

If we call the message/timeline concept WCC, maybe this will end up being called wPaaS?

TelcoFuturism: Initial thoughts on Blockchain

An area I'm currently researching, as part of my ongoing analysis of telecoms/futurism intersections is Blockchain. (See here for an intro to what I mean by telcofuturism)

For the uninitiated, Blockchain (abbreviated here to BC) is the technology underpinning Bitcoin and other cryptocurrencies. It's a way to create distributed, secure, unchangeable, peer-to-peer databases for "trust" and transactions/applications which require it. It removes the need for central coordination and storage to prove that you own/bought/sold/transferred things, and stops the "double-spend" problem of digital copying of things like e-money. This is potentially great for finance, where a lot of cumbersome back-office processes could be made hugely more efficient.

When more extensive definitions of "trust" are considered (eg authentication of documents or relationships), it potentially has the ability to dis-intermediate all sorts of other existing businesses and even government functions, beyond just banking and digital money. There are tons of books, conferences and think-pieces about BC, from everyone from FinTech disruptors to governments to major IT and auditing companies. It's definitely a "thing" at the moment.

However, it is debatable whether some of the more far-fetched concepts presented are truly visionary - or sci-fi hype peddled by people who are less-than-objective wishful thinkers. It could become as important and ubiquitous as electricity, semiconductors or the Internet - or else it could just be an interesting platform for diverse applications, but not really a global "game-changer". 

An historian from the year 2100 might point to Blockchain as the most pivotal enabler of the restructuring of global business and society - or else it might be a minor footnote to the much-larger impact of other innovations around AI, CRISPR gene-editing and nanotechnology.

I'm trying to look at Blockchain through the lens of telecoms, networks, communications and cloud platforms. I can't really comment on the full impact on banking or manufacturing or property markets.... but I think I have an idea of the practicalities for telcos to deploy blockchains, and also the realities of networks as they might apply to other use-cases.

I haven't yet reached firm conclusions about the most important use-cases for blockchains in telcos & other communications infrastructure, or the probable timelines, but I'm starting to develop some initial hypotheses. There's some good arguments about BC's use in billing systems, IoT/network registration and control, vertical-market services in finance and healthcare, and perhaps integral network/OSS functions. I can also see it dovetailing with eSIM, cloud/PaaS platforms and numerous other niches in telcos, enterprise comms/UC domains and beyond.

I'm cautiously positive about the technology, rather being than a full-on religious convert and evangelist, as some Blockchain advocates seem to be. I don't buy into the notion that it's going to magically remove all intermediaries from all areas of human interaction, and lead to some anti-capitalist utopia/dystopia (delete according to taste) where middlemen no longer have roles to play.

I see a few major problem areas and "gotchas" emerging, that lie between the vision and possible reality, especially in the medium term:

• Often, blockchain is suggested as the "missing piece of the puzzle", after which a new low-friction process, or entire new industry can be born. Yet in many cases, it isn't transaction cost, or cumbersome trust arrangements that are the "gating factor" stopping deployment adoption today. There are other practicalities involved too - perhaps regulation, business model, customer preferences and loyalties, or 100 other factors. For instance, the idea that everything to do with IoT just needs a sprinkling of Blockchain pixie-dust, for trillions of dollars of value to be released, on interoperable open-source style platforms, is pure hyperbole. It might be desirable - even necessary - but it's certainly not sufficient for many things to take off.
• A fair amount of envisaged blockchain use-cases require perfect, ubiquitous connectivity. That might be OK for banks and fintech companies using multiple data-centres and redundant fibre links, but it doesn't work well for mobile/wireless which is not going to be ubiquitous any time soon (if ever). Unless the applications have some way of dealing with "offline mode", or patchy/intermittent connections, that's a major obstacle.
• Some blockchain architectures have significant time-lags involved, due to processing for verification and permanent storage/encryption ("mining" etc.) That's fine for things which operate on a scale of minutes/hours/days - say transfers of property deeds - but not ideal for network operations that involve subs-second decisions. As we move towards 5G and "millisecond latency" critical applications, this becomes even more imperative.
• Blockchain applications will need to "play nicely" with all sorts of other technology trends, such as distributed clouds, telecoms NFV/SDN architectures, third-party PaaS, integration with legacy systems, security gateways, policy-managed networks (can they spot, block or prioritise BC data flows?), AI and machine learning creating unpredictable or novel transactions/interactions and plenty more.
• Many suggested blockchain use-cases ignore what might be termed "immovable obstacles". It's all very well having a BC-based wireless mesh network, but if it's ignored by the companies owning big chunks of licenced spectrum, and creating non-BC back-office functions, it's a bit of a waste of time. The same thing applies to regulations, taxation and assorted other slow-moving areas of bureaucracy. It's all very well suggesting that your house can act as an autonomous business, renting out the WiFi to passers-by all by itself when you're out, and using the payments to pay the utility bill - but that my well cause consternation among people who tax and regulate such things. Other ideas - such as micropayments for IoT sensors selling weather data by themselves - sound great until people realise that the billing systems only support 2 decimal places, or ask the user to click "OK" or answer a captcha. There are many, many devils in the detail.
• A lot of the rhetoric seems to suggest that everyone wants a completely peer-to-peer, decentralised, no-intermediary, no-brand economy. However the evidence seems to suggest that humans actually quite like intermediaries for many things and are prepared to pay for them - Apple running an appstore, curators for a museum, editors and brand for a news service and so on. Add in the clear need for designers as the new uber-class of intermediaries, and the over-riding importance of UX in any situation, and the "fully automated world" seems even less plausible.

None of this means that blockchain based services are a bad idea, or irrelevant to telcos and network/software vendors. There are, undoubtedly, many important and possibly huge opportunities in blockchain-based telcofuturism.

But at the same time there is a lot of hype. Outside of financial services, we're still mostly at the napkin-diagram/Powerpoint/very-early prototype stage of telecom/BC use-cases. I'm hoping to get some more clarity over the next few weeks - and will try to assemble a realistic timeline that blends vision and pragmatism for comms and network applications.

Please get in touch with me if you'd like to discuss Telecoms + Blockchain combinations. I can be reached via information AT disruptive-analysis DOT com, or via Twitter or LinkedIn.

Cisco and Ericsson: Will the Enterprise move to Private IMS & Cellular?

A lot has been written already about the ramifications of the wide-ranging Cisco / Ericsson deal. Most industry analysts and other observers have already come up with assessments of areas of impact, effects on other vendors (eg Juniper), and the implications for various telco-network technologies such as SDN / NFV.

A fair amount of output has been interpreting the “official line” from the two vendors’ press releases and briefings, which have been a little thin on exact details of how the collaboration will evolve. Light Reading has collated a good set of opinions here, for example.

So I'm going to speculate a little - and consider what is not being mentioned so far. This is a blog post about "what might happen" - there's a lot of variables, complexity and execution risk. Caveat lector.


The story so far: Selling & integrating IP gear & cloud platforms for telcos

Looking around the web, it seems that there’s a roughly 80/20 split between analysis of telco-area implications vs. enterprise. This is unsurprising, given the early focus areas announced - the Ericsson CEO says “Initially the partnership will focus on SPs” in the release. Also, the bulk of observers who cover both companies are strongly focused on SP networks.

But my sense is that a few angles have been overlooked, especially about enterprise. I'll highlight a line in the slide-deck the companies used: "Creating leadership to address converging telco and enterprise domains".

The assumption among most people seems to be that "convergence" here is viewed only in one direction. It's assumed to mean an increasing role for telcos in managing enterprise networks and communications functions. And yes, a lot is about combined sales to/through telcos. Cisco gets to sell IP gear via Ericsson's huge SP-focused services and integration teams, and better integrate its products with the OSS/BSS domain. Going forward, the partnership can allow better network/service coverage in corporate offices, or enable assorted business cloud and IoT offers to be provided by telecom operators.

Yet "convergence" occurs when two trends meet in the middle. There's another side here: enterprises starting to adopt or manage telco-type networks and capabilities. 

But what's in it for the enterprise?

So what does Ericsson have, that Cisco can sell / add value to via its enterprise channels? And what new combined products might come from both firms' R&D labs that could be of interest beyond the reach of telcos, sold directly into the corporate domain?

I have sensed for a while that Ericsson wanted more direct business with enterprises and governments - it recognises that its addressable market for telco capex/opex (whether hardware or managed services) is limited by telcos' own growth difficulties, as well as competition from Huawei, wariness of IT players like Oracle, and the move to software-based (and sometimes open-source) infrastructure. 

It was no coincidence that last year's analyst conference in Stockholm was held partly in Volvo's premises. Or in another area I watch closely, that its WebRTC activities have involved things like online banking (see here) without a mention of telcos at all.

It's not just Ericsson. We've also seen other telecom vendors pitch to goverments, city authorities, utilities, transportation companies and so forth. There are private cellular networks intended for railways and mining operations, to e-commerce and cloud propositions, or re-use of billing/charging for utilities and smart city initiatives. Quite a few vendors also sell to "non-telco SPs", ranging from call-centre providers to (ssshhhhh!!!) big Internet firms, as well as amenity-type public WiFi implementors.

So - the question is what the joint Cisco/Ericsson initiatives might be for enterprise. The briefing deck gives some rather vague lines like "comprehensive systems integration, managed services and technical support for enterprises" as well as "cloud and data-centres" which potentially cover a multitude of sins.

Another interesting line is "Networks of the future require new design principles to ensure agility, autonomy, and security". The interesting word there is "autonomy" which means "the right or condition of self-government." For whom, exactly? For telcos, it could mean the freedom to choose between multiple vendors' platform ad 3rd-party VNFs - but I'm not convinced that's a story that Cisco and Ericsson really buy into.

My sense is that actually - and this is probably a medium-term thing rather than immediate - there are three aspects:

• Distributed enterprise cloud platforms. This should be unsurprising given both references in the announcement, and Cisco's data-centre expertise. Ericsson SDN/NFV work could fit in here, although it's not the main focus of this post.
• Private wireless. This includes both WiFi and potentially private cellular networks, indoor, on campuses, and perhaps for large areas or governmental applications.
• Comms, Collaboration & Private IMS. Both partners have a lot of history in voice, messaging and video communications, not just in telcos but also deployed by businesses. Ericsson used to make PBXs but sold to Aastra in 2008. While UC, cloud and collaboration is impacting the traditional PBX/IP-PBX market, that doesn't mean that enterprises want everything delivered "as a service". Cisco & Ericsson can help both telcos' UCaaS propositions - but also help corporations take back control in-house.

It should be noted that the last two points are unlikely to be especially popular with the telecom service provider community, and would thus not be the focus of the initial SP-friendly announcement.


Private Wireless

Together, Cisco and Ericsson have a decent chance of “fixing” indoor mobile coverage, capacity and control for large enterprises. Both have WiFi assets and also small-cell exposure (Cisco especially via its SpiderCloud partnership), but the kicker here is Cisco’s footprint and understanding of the enterprise fixed LAN and security domain. 

There are two angles here:

• Helping mobile operators "reach" deeper into enterprises to allow better in-building cellular coverage, WiFi offload/voice and (in the GSMA's dreams) run corporate wireless data connectivity as a fully-managed service. Print-over-4G....
• Allow enterprises to better manage and run their own mobile infrastructure, most obviously in unlicenced spectrum. This could extend beyond traditional WiFi towards allowing private management of LPWAN (low power networks) for IoT, rather than using Opex-centric services like SigFox's.

Historically, one of the main problems for enterprise pico/femtocells, or use of corporate WiFi for offload and carrier VoIP, has been how these coexist with the corporate-run firewalls and in-house network management and prioritisation. Normally, telco visibility/control ends “outside” a demarcation point. Most enterprises will view outbound VPN tunnels from small cells, or external control of devices on the LAN, as a security risk. Telcos, in turn, are hesitant to offer service guarantees where they have limited ability to measure or manage performance – and will also see security issues. 

There are also various issues with security, privacy and legal liability when using a 3rd-party cloud platform for identity, data processing or storage.

There is a chance here for Cisco and Ericsson to create solutions to all these areas. The short-term headlines will probably be around better in-building cellular (competing with DAS and, implicitly, SpiderCloud) and IMS WiFi-voice support, but the longer-term vision will perhaps include:

• Carrier-managed enterprise WiFi, perhaps in neutral-host mode to support multiple cellular operators' subscribers on the same network
• Private corporate-run LTE-U networks, maybe using Qualcomm's MuLTEfire or something similar, for indoor or campus usage
• Private IoT networks using both unlicenced and licenced spectrum, linked into corporate IT and communications systems directly, rather than via a service provider
• Licenced-band cellular for non-telco organisations with access to cellular spectrum (eg public safety networks, rail/transport systems, maybe smart cities or big oil/mining companies in remote areas)
• (Perhaps, depending on regulation) ways to enable "corporate MVNOs" 

This is all pretty speculative - and it may be that some of these concepts are a long way off, and perhaps not even fully-considered by Ericsson and Cisco themselves. (Get in touch if you'd like me to run a brainstorm workshop, guys!)
 
 
Comms, Collaboration & Private IMS

Absent from the announcement was any clear reference to communications: UC/UCaaS, IMS, VoLTE, WebEx, Spark, WebRTC and so forth are, to me, elephants in the room.
 

Predictable things we'll likely see include various Cisco-to-Ericsson moves, around UCaaS and WebEX linked to Ericsson's IMS. But I think that's only part of the story that will emerge.

 

Let's go back to that term "autonomy" from above. 

 

It's easier to get seduced by the idea that enterprises (and small businesses) want to get rid of their old on-premise phone systems, recognise their employees are mobile-first and BYOD-minded, and shift to some form of UCaaS platform linked to a telco network and number. Yet on the ground, plenty of enterprises either want to keep control of their own communications system, or are using 3rd-party Internet-based tools like Slack, rather than an SP's integrated proposition. 

 

I don't think that's going to change - many businesses prefer to keep hold of their own "phone" system, especially as it becomes part of their messaging or contact-centre or contextual-comms platform. That doesn't mean it has to be a lump of tin, or a proprietary IP-PBX platform for call control - it could be in the cloud, or using standardised software elements. It just doesn't have to be a "per-seat per-month" cost model. 

 

A rather surprising term I’ve heard a few times recently – mostly from folk in the IT/cloud industry – is “enterprise IMS”. It’s not an industry-standard term, but basically, it means that some large businesses want to deploy their own internal IMS-type infrastructures as communications/service platforms. These might be owned outright, managed on-site by third parties, or delivered from multi-tenant clouds in the same fashion as UCaaS today. But I think this area is one of the likely mid-term outcomes of the Ericsson / Cisco deal, if the concept comes to fruition.

Remember - PBX stood for Private Branch Exchange. We should not be surprised if the IP and Mobile equivalent turns out to be the enterprise-owned PIMS, not a "mobile PBX" run as a service in a telco network. 

 

It’s being catalysed by a few things:

• Mobile and BYOD: many employees are using mobile devices for most of their business communications. But most UC/smartphone implementations are still a bit clunky, with varying UIs depending on device and especially iOS vs. Android. Having an enterprise-run IMS (and voice application) would potentially allow the CIO to regain control of the “native dialler” on a phone, especially when connected in-building. There are open questions about numbering, but they may be tractable.
• Cloud / Open-Source IMS: A few years ago, the idea of an enterprise owning an IMS would have been ludicrous, given the costs involved. But now, with virtualisation, cost pressures by telcos wanting cheap VoLTE, the emergence of open-source options like Metaswitch Clearwater, it is becoming much more downward-scalable. PIMS is starting to look like a cost-effective option.
• Applications: Currently pretty much the only useful IMS application is straightforward VoIP/VoLTE phone calls. That isn't enterprise-optimised - it lacks the typical PBX-type functions that are needed. There aren't really telco-IMS contact centre apps, and nonsense like RCS certainly doesn't address enterprise messaging. Having a PIMS/WebEx/Spark combination would be much more interesting. Potentially it could also be run as an operator-hosted service, but I think the real value is where it is owned outright.
• Middleware & APIs: Where this starts getting really interesting is in the creation of integrated apps blending a corporate comms platform, with corporate IT systems. Hooking into existing software platforms for sales or field automation, line of business and so forth. Potentially this is where a combination of a Cisco/Ericsson PIMS + Tropo starts looking interest. (Sidenote: unlike GenBand with Kandy, Ericsson lacks a WebRTC PaaS)

There’s a few other angles that play in here too. Most notably Cisco's earlier partnership with Apple, which I think many have underestimated. It is likely to optimise iPhones & iPads for use with Cisco's security, WiFi and collaboration tools. I can envisage a situation where companies ditch their old desk-phones for Apple i-Devices, either BYOD or company-issued, linked to Cisco communications apps running via an Ericsson PIMS, with outbound SIP/IMS trunks if needed. Potentially this could work with virtual numbers as well - not just for the US where fixed/mobile numbers are indistinguishable, but the rest of the world where mobile numbers are from separate defined ranges. 

Having a corporate-issued mobile number, anchored in a PIMS, would make a lot of difference - ability to use SMS, better fit with assorted apps that use mobile numbers for identity or authentication, porting in/out, maybe even assigning mobile numbers to IoT objects. There's a lot of variables here, and the rules will likely vary by country.

And for a long-range view, consider Apple’s work on virtual / eSIMs added in to this. Telcos might not like the idea of virtual SIMs in phones – but an enterprise, running its own IMS, its own WiFi network, and perhaps having access to LTE-U and maybe even its own mobile network code – may not be so squeamish. There are various types and styles of enterprise MNO and MVNO that can be envisaged here, depending on local regulation, willingness of local operators to wholesale or allow roaming, or even share spectrum. I can even imagine an “enterprise MNO” being run as a managed service by Ericsson.

Who would be impacted by this? Microsoft is at the top of the list, and also the traditional mobile operators’ enterprise units which still make good margins on corporate mobile subscriptions. It also sits against the emerging Google/Android/Telcos/BroadSoft/Switch enterprise ecosystem. Avaya is left looking a bit lonely here (although it also works with Google), as are the smaller UC players like Shoretel. It possibly even makes the bizarre Mitel/Mavenir acquisition look more sensible in hindsight, although that’s still pretty baffling.

The interesting question is whether Cisco and Ericsson have actually looked closely at what they might be catalysing – or whether they are themselves likely to be as surprised by the direction of travel. Obviously there are lots of questions about execution that come first, but if things go well, there could be a game-changer afoot.

(None of this is entirely new as a concept. About 10 years ago, I did consulting for a company called Zynetix (later bought by Sonus Networks) that sold enterprise-grade cellular-core MSCs that linked to PBXs. They could allow businesses to run private mobile networks, especially when linked to pico/femtocells running in “guard band” spectrum in the UK. However it was perhaps ahead of its time, hampered by some of the practicalities such as spectrum/radio limitations, needing clunky user-experience hacks like manually selecting different networks).

Conclusion

The bottom line is this: the notion that ALL enterprises will outsource the bulk of their internal networking or communications functions, especially to telecoms service providers, is a comforting myth. Yes, some will - hence the rise of UCaaS for mid-market businesses, and telco-managed WiFi in places like airports or sports stadia.

But that is only part of the story.  

Some enterprises will want to continue managing networks and communications in-house (whether on-premise or in a private cloud). This will ideally expand to include aspects of mobile networks/services where possible. Expect PIMS, better WiFi, PLWPAN and maybe PLTE and PMVNO models. Others will want to outsource these functions to IT-type service providers like IBM, rather than telcos.

Potentially, Cisco+Ericsson (with a side-order of Apple) can facilitate all these different paths to the user. This might not be popular among traditional telcos, but in my view the trend is inevitable. Enterprises will re-assert their control (and sometimes ownership) of wireless/mobile networks and communications platforms, especially as they become more-integrated with business processes and applications. 

There's a lot of reasons why this partnership might fail to bear fruit. But a lack of potential exciting and disruptive opportunities in enterprise isn't one of them.