RCS messaging: still a zombie, but now wearing a suit

This post originally appeared on October 4 on my LinkedIn feed, which is now my main platform for both short posts and longer-form articles. It can be found here, along with the comment stream. Please follow / connect to me on LinkedIn, to receive regular updates (about 1-3 / week)

Yesterday I followed the Mobile Ecosystem Forum stream of its #RCSWorld conference, on #RCS #messaging, especially business messages. I thought it was time to get an update.
 
As regular followers know, I’m a long-time critic of RCS. I saw it announced in 2008, wrote reports & advised telco clients about its many problems in 2010-2013, called it a zombie tech in 2015 (“28 quarters later”) and have been sniping at it ever since, including at Google’s acquisition of Jibe and its attempt to turn it into Android’s equivalent of Apple #iMessage.
 
Some flaws have been addressed (it finally uses E2E encryption), while Google’s tightening control of its features has maybe fixed its “design by committee” paralysis and historic fragmentation. Google is now hosting the whole application for many MNOs, rather than telcos relying on (and paying for) in-network IMS integration, but with an implicit threat of end-running them if they don’t support the services to customers.

There's about 1.2bn phones with RCS active - mostly Google #Android but also about 200m in China. This has been driven by its adoption as the default messaging client on new phones, rather than by consumer download.

I didn't hear any stats on genuine active use - ie beyond just using it as a pseudo-#SMS/MMS app because it's the default. Numbers always seem to be monthly MAUs rather than meaningful DAUs. No anecdotes of teenagers who swapped from FB / WA / iMessage / WeChat / TikTok / whatever because RCS is cooler with better emojis, birthday greeting fireworks or cat-ear image filters.
 
To be fair, the conference name was misleading. Almost the entire event was about RCS Business Messaging (RBM) rather than personal or group messaging. It was about targeted marketing campaigns (that’s spam to most of us), customer interaction with so-called “brands”, multichannel whatnot, and blather about engagement and “digital” marketing

Apparently A2P revenues for SMS are flattening, but the addition of "rich" interactive in-messaging customer experience functions will reignite growth. One operator in the audience asked why the same forecasts have been shown (and not come true) for the past 4-5 years. Apparently it's too complex for most developers.

So the big innovation is "basic RCS" with 160 characters. SMS with a brand logo, a verification tick and read receipts. It's aiming at the #cPaaS market to get more devs/marketers onto the first rung & hope to catalyse more fancy use-cases later.
 
IMO this is why Apple isn’t going to support it anytime soon, despite Google's cringey social media exhortations. The notion RCS is a standard for P2P messaging is a smokescreen. It’s an ad & CRM platform, not an SMS replacement or default way to chat with friends. It’s not going to be the messaging equivalent of USB-C chargers & forced on Apple by the European Commission
 
In a nutshell, it’s still a zombie. But now it’s a zombie in a suit spamming you with ads and "engagement" while it eats your brain

 

.

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.

Mobile Multi-Connection & SD-WAN is coming

I’ve written before (link) about the impact of SD-WAN on fixed (enterprise) operators, where it is having significant effects on the market for MPLS VPNs, allowing businesses to bond together / arbitrage between normal Internet connection(s), small-capacity MPLS links and perhaps an LTE modem in the same box. Now, similar things are being seen in the mobile world. This is the "multi-network" threat I've discussed before (link).

Sometimes provided through a normal CSP, and sometimes managed independently, SD-WAN has had a profound impact on MPLS pricing in some corporate sectors. It has partly been driven by an increasing % of branch-site data traffic going into the HQ network and straight out again to the web or a cloud service. That “tromboning” is expensive, especially if it is using premium MPLS capacity.

The key enabler has been the software used to combine multiple connections – either to bond them together, send traffic via differential connections based on type or speed, add security and cloud-management functions, or offer arbitrage capabilities of varying sorts. It has also disrupted network operators hoping to offer NFV- and SDN-services alongside access: if only a fraction of the traffic goes through that operator’s core, while the rest breaks-out straight to the Internet, or via a different carrier, it’s difficult to add valuable functionality with network software.

But thus far, the main impact has been on business fixed-data connections, especially MPLS which can be 30-40x the cost of a “vanilla” ISP broadband line, for comparable throughput speeds. Many network providers have now grudgingly launched SD-WAN services of their own – the “if you can’t beat them, then join them” strategy aiming to keep customer relevance, and push their own cloud-connect products. Typically they’ve partnered with SD-WAN providers like VeloCloud, while vendors such as Cisco have made acquisitions.

I’ve been wondering for a while if we’d see the principle extended to mobile devices or users – whether it’s likely to get multiple mobile connections, or a mix of mobile / fixed, to create similar problems for either business or consumer devices. It fits well with my broader belief of “arbitrage everywhere” (link).

Up to a point, WiFi on smartphones and other devices already does this multi-connection vision, but most implementations have been either/or cellular and WiFi, not both together. Either the user, the OS, or one of the various cellular hand-off standards has done the switching.

This is now starting to change. We are seeing early examples of mobile / WiFi / fixed combinations, where connections from multiple SPs and MNOs are being bonded, or where traffic is intelligently switched-between multiple “live” connections. (This is separate from things like eSIM- or multi-IMSI enabled mobile devices or services like Google Fi, which can connect to different networks, but only one at a time).

The early stages of mobile bonding / SD-WAN are mostly appearing in enterprise or IoT scenarios. The onboard WiFi in a growing number of passenger trains is often based on units combining multiple LTE radios. (And perhaps satellite). These can use multiple operators’ SIMs in order to maximise both coverage and throughput along the track. I’ve seen similar devices used for in-vehicle connections for law enforcement, and for some fixed-IoT implementations such as road-tolling or traffic-flow monitors.

At a trade show recently I saw the suitcase-sized unit below. It has 12 LTE radios and SIMs, plus a switch, so it can potentially combine 3 or 4 connections to each network operator. It’s used in locations like construction sites, to create a “virtual fibre” connection for the project office and workers, where normal fixed infrastructure is not available. Usually, the output is via WiFi or fixed-ethernet, but it can also potentially support site-wide LPWAN (or conceivably even a local private unlicensed/shared-band LTE network). 

It apparently costs about $6000 or so, although the vendor prefers to offer it as a service, with the various backhaul SIMs / data plans, rather than on a BYO basis. Apparently other similar systems are made by other firms – and I can certainly imagine less-rugged or fewer-radio versions having a much lower price point.

But what really caught my eye recently is a little-discussed announcement from Apple about the new iOS11. It supports “TCP Multipath”. (this link is a good description & the full Applie slide-deck from WWDC is here). This should enable it to use multiple simultaneous connections – notably cellular and WiFi, although I guess that conceivably a future device could even support two cellular radios (perhaps in an iPad with enough space and battery capacity). 

That on its own could yield some interesting results, especially as iOS already allows applications to distinguish between network connections (“only download video in high quality over WiFi”, etc).It also turns out that Apple has been privately using Multipath TCP for 4 years, for Siri - with, it claims, a 5x drop in network connection failure rates.

The iOS11 APIs offer various options for developers to combine WiFi and cellular (see slide 37 onward here). But I’m also wondering what future generations of developer controls over such multipath connectivity might enable. It could allow novel approaches to security, performance optimisation on a per-application or per-flow basis, offload and on-load, and perhaps integration with other similar devices, or home WiFi multi-AP solutions that are becoming popular. Where multiple devices cooperate, many other possibilities start to emerge.

What we may well see in future is multi-device, multi-access, P2P meshes. Imagine a family at home, with each member having a subscription and data-plan with a different mobile network. Either via some sort of gateway, or perhaps using WiFi or Bluetooth directly between devices, they can effectively share each others’ connections (and the fixed broadband), while simultaneously using their own “native” cellular data. Potentially, they can share phone numbers / identities this way as well. An advanced connection-management tool can optimise for throughput, latency or just simply coverage anywhere in the house or garden. 

This could have a number of profound implications. It would lead to much greater substitution between different networks and plans. It would indirectly improve network coverage, especially indoors. It could either increase or decrease demand for small cells (are they still needed, if phones can act as multi-network relays? Or perhaps operators try to keep people “on net” and give them away for free?). From a regulatory or law-enforcement standpoint it means serious challenges around identifying individual users. It could mean that non-neutral network policies could be “gamed”, as could pricing plans.

Now I’ll fully admit that I’m extrapolating quite a bit from a seemingly simple enhancement of iOS. (I’m also not sure how this would work with Android devices). But to me, this looks analogous to another Apple move last year – adding CallKit to iOS, which allowed other voice applications to become “first-class citizens” on iPhones, with multiple diallers and telephony experiences sharing call-logs and home-screen answerability.

Potentially, multipath in iOS allows other networks to become (effectively) first-class citizens as well as the “native” MNO connection controlled from the SIM.

I’m expecting other examples of mobile connection-bonding and arbitrage to emerge in the coming months and years. The lessons from SD-WAN in the fixed domain should be re-examined by carriers through a wireless lens: expect more arbitrage in future.

Communications apps, APIs & integrations: Import vs. Export models

There is a huge and growing interest in blending communications apps/services with other software capabilities. We are moving from a world of standalone voice, video and messaging to a range of contextualised, workstream-based and embedded alternatives.

But there are two very distinct philosophies emerging for app/comms integration:

• Export: this involves extending communications capabilities out from a central system (phone system, UC, messaging app, videoconferencing etc) into other applications or websites via APIs, or by offering granular service-components (eg WebRTC gateway, transcoding, recording etc) via a PaaS approach. Numerous examples exist, from
• Vendors (eg Unify's Circuit APIs, Genband Kandy, Xura Forge, Cisco Tropo, ALU's Rapport APIs, BroadSoft, Vidyo etc)
• Dedicated PaaS providers (eg Twilio, SightCall, Temasys) or niche specialists such as Voxbone (which does numbering for example)  
  
• Telcos' API platforms, which may be network-integrated like AT&T's Developer Platform, standalone PaaS like Telefonica Toxbox, or even just web-embeddable objects like Telenor appear.in
• Import: this involves treating the communications application or service as the user's primary experience, and bringing in other applications as "integrations" or mini-apps. These can be other communications tools (eg WebRTC video windows in a messaging app) or other functions (eg social or process-based integrations). This particularly fits with the "timeline" or "workstream" model, or perhaps a "dashboard". Examples exist in a number of areas:
• Enterprise is moving towards "workstream collaboration and communications" (WCC) apps, such as Slack, Cisco Spark, Unify Circuit and various others which can embed external services into a timeline. BroadSoft's Tempo concept looks more like a dashboard model than a timeline, but also brings in sources like DropBox.
• Consumers are moving towards "Messaging as a Platform" apps, notably in Asia with WeChat, which embeds mini-apps such as taxi-ordering into the message stream. Facebook is taking Messenger in the same direction, and even telcos want to replicate this - Deutsche Telekom is trying to reinvent RCS to take it in that direction, for example.

The API-led "export" model has been the primary trend in WebRTC, SMS and telcos' network/IMS strategies in recent years. We hear a lot about the "consumption" of APIs, "embedding" of communications or the "exposure" of a core system. It is definitely growing rapidly, in numerous guises. Click-to-call buttons embedded in websites or apps are a typical manifestation. (Video below is embedding AT&T capability into Plantronics' website)

But the success of apps such as Slack and WeChat have led to a resurgence of the idea of "unifying" communications, or using a "hub" approach, where a messaging/voice/video app becomes the central anchor of a user's "online life", either as a dedicated application or browser home-page.

Some vendors are trying both approaches - Unify and Cisco seem to be looking at both import and export models. It might be where Google is intending to take Jibe along with telcos and Android as well. Some UCaaS players seem to be taking a similar path (eg with ThinkingPhones acquisition of Fuze) as well as WCC specialists like Atlassian's HipChat.

Others are taking different angles - Microsoft seems to be using Office 365 as the anchor, importing its own Skype4Business UC application as well as maybe others in future, probably via ORTC. I suspect it will "export" more communications as well, in future. Apple (as usual) is different, still using iOS as its main platform for very selective import of a few comms/social tools such as Facebook and Twitter, and largely avoiding any export models at all. (There is no way to embed FaceTime or iMessage in a website, for example). Apple also tends to dislike apps acting as subsidiary platforms on mobile, especially if there are payments involved.

It is too early - and too polarised - to determine whether import or export will be most significant, and for which use-cases and customer segments. We may see different "balances of payments" for different vendors and service providers. However, there are a number of early conclusions to draw:

• Import models need a good and usable / well-liked core product, before they can become a platform
• Export models need the right "raw ingredients", eg simple video or SMS APIs, with the right (typically freemium) commercial model to attract developers
• Import models tend to work best with a core that is text/timeline-based, ie non-realtime
• There is a risk that some import models appear as "arrogant": I can imagine some users thinking "What, you expect me to spend the core of my day in your app?! You must be joking"
• Export models face a lot of competition - external developers have many APIs to choose from, or can implement their own capabilities from scratch.
• Import models involve competition between comms tools and other apps as the "anchor" - eg a UC tool, vs. social networks, or an Office/Google Apps suite as hub, or major enterprise products like SAP/Salesforce, or a vertical-specific platform like a medical practice-management app.
• Import and export approaches often vary in implementation between Android, iOS, Windows and native chipset-level
• Telcos have been trying export models for a long time, with limited success. Often, 3rd party platforms that act as aggregators / or "export agents". Cable / IPTV companies are closer to the import model as they own the set-top box interface to "on-board" other solutions
• We might see NFV / VNF architectures helping with telco-grade import & export in future, but for communications services it's still a long way off
• Mobile app usage tends to be fragmented. With the notable exception of WeChat, it's not clear that a full import model works well with the app paradigm on smartphones. That said, we may see greater cross-linkage between apps in future.
• Certain groups of knowledge-workers may be more well-suited to "import" comms apps, especially if they are either communications-primary users (eg call centre agents) or heavily-collaborating teams.
• Design skills are paramount throughout, for integrations to be usable. 
• We will see some "importers" acquiring companies to extend the core app functions. Slack/Screenhero is a good example. This may compete with some 3rd-parties' integrations, but may also make life easier for iOS appstore approvals.
• Both import and export models make life much harder for network policy-management (or industry regulation) as mashups are by their nature hard to pigeon-hole. 
• Every export implicitly also means an import from the other side - sometimes into "product", but in many ways horizontal apps such as SAP and Saleforce are turning into full import platforms in their own right, especially where they support multiple communications integrations.

I think that 2016 is going to see some epic battles between import and export philosophies for communications in general, and WebRTC in particular. The shift of communications to the cloud facilitates both directions. Worth watching very closely indeed.

Stop Press: just as I was about to publish, I read that Facebook is trialling Uber-in-Messenger, as part of its "Transportation on Messenger" initiative. This is a great example of an import model, and "messaging as a platform". Details are here.

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.