Interoperability is often good – but should not be mandated

Note: this post was first published via my LinkedIn Newsletter. Please subscribe (here) & also join the comment & discussion thread on LI

Context: I'm going to be spending more time on telecom/tech policy & geopolitics over the next few months, spanning UK, US, Europe & Global issues. I'll be sharing opinions & analysis on the politics of 5G & Wi-Fi, spectrum, broadband plans, supply-chain diversity & competition.

Recently, I've seen more calls for governments to demand mandatory interoperability between technology systems (or between vendors) as a regulatory tool. I think this would be a mistake - although incentivising interop can sometimes be a good move for various reasons. This is a fairly long post to explain my thinking, with particular reference to Open RAN and messaging.

Background & history

The telecoms industry has thrived on interoperability. Phone calls work from anywhere to anywhere, while handsets and other devices are tested & certified for proper functioning on standardised networks. Famously, interoperability between different “islands” of SMS led to the creation of a huge market for mobile data services, although that didn't happen overnight in many countries.

Much the same is true in the IT world as well, with everything from email standards to USB connections and Wi-Fi certification proving the point. The web and open APIs make it easier for cloud applications to work together harmoniously.

Image source: https://pixabay.com/illustrations/rings-wooden-rings-intertwined-100181/

 But not everything valuable is interoperable. It isn't the only approach. Proprietary and vertically-integrated solutions remain important too.

Many social media and communications applications have very limited touch-points with each other. The largest 4G/5G equipment companies don’t allow operator customers to mix-and-match components in their radio systems. Many IT systems remain closed, without public APIs. Consumers can’t choose to subscribe to network connectivity from MNO A, but telephony & SMS from ISP B, and exclusive content belonging to cable company C.

This isn't just a telecom or IT thing. It’s difficult to get different industrial automation systems to work together. An airline can’t buy an airframe from Boeing, but insist that it has avionics from Airbus. The same is true for cars' sub-systems and software.

Tight coupling or vertical integration between different subsystems can enable better overall efficiency, or more fluid consumer experience - but at the cost of creating "islands". Sometimes that's a problem, but sometimes it's actually an advantage.

Well-known examples of interoperability in a narrow market subset can obscure broader use of proprietary systems in a wider domain. Most voice-related applications, beyond traditional "phone calls", do not interoperate by default. You could probably connect a podcast platform to a karaoke app, home voice assistant and a critical-communications push-to-talk system.... but why would you? (This is one reason why I always take care to never treat "voice" and "telephony" synonymously).

Hybrid, competitive markets are optimal

So there is value in interoperable systems, and also in proprietary alternatives and niches. Some sectors gravitate towards openness, such as federation between different email systems. Others may create de-facto proprietary appoaches - which might risk harmful monopolies, or which may be transferred to become open standards (for instance, Adobe's PDF document format).

And even if something is based on theoretically interoperable underpinnings, it might still not interoperate in practice. Most enterprise Private 4G and 5G networks are not connected to public mobile networks, even though they use the same standards.

Interoperability can be both a positive and negative for security. Open and published interfaces can be scrutinised for vulnerabilities, and third-parties can test anything that can be attached to something else. Yet closed systems have fewer entry points – the “attack surface” may be smaller. Having a private technology for a specific purpose – from a military communications infrastructure to a multiplayer gaming network – may make commercial or strategic sense.

In many all areas of technology, we see a natural pendulum swing between openness and proprietary. From open flexibility to closed-system optimisation, and back again. Often there are multiple layers of technology, where the pendulum swings with a different cadence for each. Software-isation of many hardware products means a given system might employ multiple layers at the same time.

 Consider this (incomplete and sometimes overlapping) set of scenarios for interoperability:

• Between products: A device needs to be able to connect to a network, using the right radio frequencies and protocols. Or an electrical plug needs to fit into a standardised socket.
• Within products or solutions (between components): A product or service can be considered to be just a collection of sub-systems. A computer might be able to support different suppliers’ memory chips or disks, using the same sockets. A browser could support multiple ad-blockers. A telco’s virtualised network could support different vendors for certain functions.
• Application-to-application / service-to-service: An application can link to, integrate or federate with another - for instance a reader could share this article on their Twitter feed, or mobile user can roam onto another network, or a bank can share data access with an accounting tool.
• Data portability: Data formats can be common from one system to another, so users can own and move their "state" data and history. This could range from a porting a phone number, to moving uploaded photos from one social platform to another.

There’s also a large and diverse industry dedicated to gluing together things which are not directly interoperable – and acting as important boundaries to enforce security, charging or other functions. Session Border Controllers link different voice systems, with transcoders to translate between different codecs. Gateways link Wi-Fi or Bluetooth IoT devices to fixed or wireless broadband backhaul. Connectors enable different software platforms to work together. Mapping functions will eventually allow 5G network slicing to work across core, transport and radio domains, abstracting the complexities at the boundaries.

Added to this is the entire sphere of systems integration – the practice of connecting disparate systems and components together, to create solutions. While interoperability helps SIs in some ways, it also commoditises some of their business.

Coexistence vs. interoperation

Yet another option for non-interoperable systems is rules for how they can coexist, without damaging each other’s operation. This is seen in unlicensed or shared wireless spectrum bands, to avoid “tragedies of the commons” where interference would jam all the disparate systems. Even licensed bands can be "technology neutral".

Analogous approaches enable the safe coexistence of different types of road users on the same highway - or in the voice/video arena, technologies such as WebRTC which embed "codec negotiation" procedures into the standards.

Arguably, improving software techniques, automation, containerisation and AI will make such interworking and coexistence approaches even easier in future. Such kludginess might not please engineering purists who value “elegance”, but that’s not the way the world works – and certainly shouldn’t be how it’s regulated.

In a healthy and competitive market, customers should be able to choose between open and closed options, understanding the various trade-offs involved, yet be protected from abusive anti-competitive power.

A great example of consumer gains and "generativity" in innovation is that of the Internet itself, which works alongside walled-garden, telco or private-network alternatives to access content and applications.

Customers can have the best of both worlds - accelerated, because of the competitive tensions involved. The only risk is that of monopolies or oligopolies, which requires oversight.

Where does government & regulatory policy fit in this?

This highlights an important and central point: the role of government, and its attitude to technology standards, interoperability and openness. This topic is exemplified by various recent initiatives, ranging from enthusiasm around Open RAN for 5G in the US, UK and elsewhere, to the EU’s growing attempts to force Internet platform businesses to interoperate and enable portability of data or content, as part of its Digital Services Act.

My view is that governments should, in general, let technology markets, vendors and suppliers make their own choices.

It is reasonable that governments often want to frame regulation in ways to protect citizens from monopolists, or risks of harm such as cybersecurity. In general, competition rules are developed across industries, without specific rules about products, unless there is unfair vertical integration and cross-subsidy.

Governments can certainly choose to adopt or even incentivise interoperability for various reasons – but they should not enshrine it in laws as mandatory. If you're a believer in interventionist policies, then incentivising market changes that favour national champions, foster inward investment and increase opportunities can make sense - although others will clearly differ.

(Personally, I think major tranches of intervention and state-aid should only apply to game-changers with huge investment needs - so perhaps for carbon capture technology, or hydrogen-powered aviation).

Open RAN may be incentivised, not mandated

A particular area of focus by many in telecoms is around open radio networks. The O-RAN Alliance and the TIP OpenRan project are at the forefront, with many genuinely impressive innovations and evolutions occurring. Rakuten's deployment is proving to be a beacon - at least for greenfield networks - while others such as Vodafone are using this architectural philosophy for rural coverage improvements.

Governments are increasingly involved as well - seeing a possible way to meet voters' desires for better/cheaper coverage, while also offsetting perceived risks from concentrations of power in a few large integrated vendors. This latter issue has been pushed further into the limelight by Huawei's fall from favour in a number of countries, which then see a challenge from a smaller number of alternative providers - Nokia, Ericsson and in some cases Samsung and NEC or niche providers.

This combination of factors then gets further conflated with industrial policy goals. For instance, if a country is good at creating software but not manufacturing radios, then Open RAN is an opportunity, that might merit some form of R&D stimulus, government-funded testbeds and so on.

So I can see some arguments for incentives - but I would be very wary of a step to enshrine any specific interop requirements into law (or rules for licenses), or for large-scale subsidies or plans for government-run national infrastructure. The world has largely moved to "tech neutral" approaches in areas such as spectrum awards. In the past, governments would mandate certain technologies for certain bands - but that is now generally frowned upon.

No, message apps should not interoperate

Another classic example of undesirable "forced interoperability" is in messaging applications. I've often heard many in the telecoms industry assert that it would be much better if WhatsApp, iMessage, Telegram, Snap - and of course the mobile industry's own useless RCS standard - could interconnect. Recently, some government and lobbying groups have suggested much the same, especially in Brussels.

Yet this would instantly hobble the best and most unique features of each - how would ephemeral (disappearing) messages work on systems that keep them stored perpetually? How would an encrypted platform interoperate with a non-encrypted platform? How could an invite/accept contact system interwork with a permissive any-to-any platform? How would a phone-number identity system work with a screen-name one?

... and that's before the real unintended consequences kick in, when people realise that their LinkedIn messages now interoperate with Tinder, corporate Slack and telemedicine messaging functions.

That doesn't mean there's never a reason to interoperate between message systems. In particular, if there's an acquisition it can be useful and imporant - imagine if Zoom and Slack merged, for instance. Or a gaming platform's messaging might want users to send invitations on social media. I could see some circumstances (for business) where it might be helpful linking Twitter and LinkedIn - but also others where it would be a disaster (I'm looking at you, Sales Navigator spamming tools).

So again - interoperability should be an option. Not a default. And in this case, I see zero reasons for governments to incentivise.

Conclusion

Interoperability between technology solutions or sub-systems should be possible - but it should not be assumed as a default, nor legislated in areas with high levels of innovation. It risks creating lowest-common denominators which do not align with users' needs or behaviours. Vertical integration often brings benefits, and as long as the upsides and downsides are transparent, users can make informed trade-offs and choices.

Lock-in effects can occur in both interoperable and proprietary systems. I'll be writing more about the concept of path dependence in future.

Regulating or mandating interoperability risks various harms - not just a reduction in innovation and differentiation, but also unexpected and unintended consequences. Many cite the European standardisation of GSM 2G/3G mobile networks as a triumph - yet the US, Korea, Japan, China and others allowed a mix of GSM, CDMA and local oddities such as iDen, WiBro and PHS. No prizes for guessing which parts of the world now lead in 5G, although correlation doesn't necessarily imply causation here.

There's also a big risk from setting precedents that could lead to unintended consequences. Perhaps car manufacturers would be next in line to be forced to have open interfaces for all the electronic systems, impacting many automakers' potential revenues. Politicians need to think more broadly. As a general rule, if someone uses the obsolete term "digital" in the context of interop, they're not thinking much at all.

I've written before about the possible risks to telcos from the very "platform neutrality" concept that many have campaigned for. Do they imagine regulators wouldn't notice that many have their own ambitions to be platform providers too?

In my view, an ideal market is made up of a competitive mix of interoperable and proprietary options. As long as abuses are policed effectively, customers should be able to make their own trade-offs - and their own mistakes.

As always - please comment and discuss this. I'll participate in the discussions as far as possible. If you've found this thought-provoking, please like and share on LinkedIn, Twitter and beyond. And get in touch if I can help you with internal advisory work, or external communications or speaking / keynote needs.

Note: this post was first published via my LinkedIn Newsletter. Please subscribe (here) & also join the comment & discussion thread on LI

#5G #openran #regulation #telecom #mobile #interoperability #competition #messaging #voice #innovation

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.

Debunking the Network QoS myth

Every few years, the network industry - vendors, operators & industry bodies - suffers a mass delusion: that there is a market for end-to-end network QoS for specific applications. The idea is that end-users, application developers - or ideally both - will pay telcos for prioritised/optimised connections of specific "quality", usually defined in terms of speed, latency & jitter (variability).

I've watched it for at least a dozen years, usually in 3-year waves:

• We had enterprise networks promising differentiated classes of service on VPNs or the corporate connection to the Internet. Avoid the impact of the marketing department watching cat videos!
• We had countless failed iterations of the "turbo boost" button for broadband, fixed or mobile.
• We had the never-realised "two-sided markets" for broadband, featuring APIs that developers would use to pay for "guaranteed QoS"
• We had numerous cycles of pointless Net Neutrality arguments, talking about "paid prioritisation", a strawman of massive proportions. (Hint: no content or app developer has ever had lobbyists pleading for their right to buy QoS, only telcos asking to be able to sell it. Compare with, say, campaigns for marijuana decriminalisation).
• We currently have 5G "network slicing" concepts, promising that future MNOs will be able to "sell a slice" to an enterprise, a car manufacturer, a city or whatever.
• My long-standing colleague & interlocutor Martin Geddes is pitching a concept of app-focused engineering of networks, including stopping "over-delivering" broadband to best-efforts applications, thus forcing them to predict and right-size their demands on the network.

In my view, most of these attempts will fail, especially when applied to last-mile Internet access technologies, and even more-especially to wireless/mobile access. There isn't, nor ever will be, a broad and open market for "end-to-end network QoS" for Internet applications. We are seeing network-aware applications accelerating much faster than application-aware networks. (See this paper I wrote 2 years ago - link).

Where QoS works is where one organisation controls both ends of a connection AND also tightly-defines and controls the applications:

• A fixed-broadband provider can protect IP telephony & IPTV on home broadband between central office & the home gateway.
• An enterprise can build a private network & prioritise its most important application(s), plus maybe a connection to a public cloud or UCaaS service.
• Mobile operators can tune a 4G network to prioritise VoLTE.
• Telco core and transport networks can apply differential QoS to particular wholesale customers, or to their own various retail requirements (eg enterprise users' data vs. low-end consumers, or cell-site timing signals and backhaul vs. user data). 
• Industrial process & control systems use a variety of special realtime connection protocols and networks. Vendors of "OT" (operational technology) tend to view IT/telecoms and TCP/IP as quaint. The IT/OT boundary is the real "edge".

Typically these efforts are costly and complex (VoLTE was frequently-described as one of the hardest projects to implement by MNOs), make it hard to evolve the application rapidly because of dependencies on the network and testing requirements, and often have very limited or negative ROI. More importantly, they don't involve prioritising chunks of the public Internet - the telco-utopian "but Netflix will pay" story.

There are a number of practical reasons why paid-QoS is a myth. And there's also a growing set of reasons why it won't exist (for the most part) in future either, as new techniques are applied to deal with variable/unpredictable networks.

An incomplete list of reasons why Internet Access QoS isn't a "market" include:

• Coverage. Networks aren't - and won't be - completely ubiquitous. Self-driving cars need to be able to work offline, whether in a basement car-park, during a network outage in a hurricane, or in the middle of a forest. The vehicle won't ask the cloud for permission to brake, even if it's got promised millisecond latency. Nobody pays for 99.99% access only 80% of the time.
• The network can't accurately control or predict wireless effects at micro-scale, ie RF absorption or interference. It can minimise the damage (eg with MIMO, multiple antennas) or anticipate problems (weather forecast of rain = impact on mmWave signals).
• End-user connections to applications generally go via local WiFi or LAN connections, which service providers cannot monitor or control.
• No application developer wants to cut QoS deals with 800 different global operators, with different pricing & capabilities. (Or worse, 800 million different WiFi owners).
• 5G, 4G, 3G and zero-G all coexist. There is no blanket coverage. Nobody will pay for slicing or QoS (if it works) on the small islands of 5G surrounded by an ocean of lesser networks.

• "Applications" are usually mashups of dozens of separate components created by different companies. Ads, 3rd-party APIs, cloud components, JavaScript, chunks of data from CDNs, security layers and so on. Trying to map all of these to separate (but somehow linked) quality agreements is a combinatorial nightmare.
• Devices and applications have multiple features and functions. A car manufacturer wouldn't want one slice, but ten - engine telemetry, TV for the kids in the back seat, assisted-driving, navigation, security updates, machine-vision uploads and so on all have very different requirements and business models.
• Lots of IoT stuff is latency-insensitive. For an elevator maintenance company, a latency of a week is fine to see if the doors are sticking a bit, and an engineer needs to arrive a month earlier than scheduled.
• I don't know exactly how "serverless computing" works but I suspect that - and future software/cloud iterations - take us even further from having apps asking the network for permission/quality on the fly. 
• Multiple networks are becoming inevitable, whether they are bonded (eg SD-WANs or Apple's use of TCP Multipath), used in tandem for different functions (4G + SigFox combo chips), meshed in new ways, or linked to some sort of arbitrage function (multi-IMSI MVNOs, or dual-SIM/radio devices).  See also my piece on "Quasi-QoS" from last year (link)

• Wider use of VPNs, proxies and encryption will mean the network can't unilaterally make decisions on Internet QoS, even if the laws allow it.
• Increasing use of P2P technologies (or D2D devices) which don't involve service providers' control infrastructure at all.
• Network APIs would probably have to be surfaced to developers via OS/browser functions. Which then means getting Apple, Google, Microsoft et al to act as some sort of "QoS storefront". Good luck with that.
• No developer will pay for QoS when "normal" service is running fine. And when it isn't, the network has a pricing/delivery challenge when everyone tries to get premium QoS during congestion simultaneously. (I wrote about this in 2009 - link) 
• Scaling the back-end systems for application/network QoS, to perhaps billions of transactions per second, is a non-starter. (Or wishful thinking, if you're a vendor).
• There's probably some extra horribleness from GDPR privacy regulations in Europe and information-collection consent, which further complicates QoS as it's "processing". I'll leave that one to the lawyers, though.
• It's anyone's guess what new attack-surfaces emerge from a more QoS-ified Internet. I can think of a few.

But the bigger issue here is that application and device developers generally don't know or care about how networks work, or (in general) have any willingness to pay. Yes, there's a handful of exceptions - maybe mobile operators wanting timing sync for their femtocells, for example. Safety-critical communications obviously needs quality guarantees, but doesn't use the public Internet. Again, these link back to predictable applications and a willingness to engineer the connection specifically for them.

But the usually-cited examples, such as videoconferencing providers, IoT specialists, car companies, AR/VR firms and so on are not a viable market for Internet QoS. They have other problems to solve, and many approaches to delivering "outcomes" for their users.

A key issue is that "network performance" is not considered separately and independently. Many developers try to find a balance between network usage and other variables such as battery life / power consumption together. They also think about other constraints - CPU and screen limitations, user behaviour and psychology, the costs of cloud storage/compute, device OS variations and updates, and so on. So for instance, an app might choose a given video codec based on what it estimates about available network bandwidth, plus what it knows about the user, battery and so on. It's a multi-variable problem, not just "how can the network offer better quality".

Linked to this is analytics, machine learning and AI. There are huge advances in tuning applications (or connection-managers) to deal with network limitations, whether that relates to performance, cost or battery use. Applications can watch rates of packet throughput and drops from both ends, and make decisions how to limit the impact of congestion. (see also this link to an earlier piece I wrote on AI vs. QoS). 

Self-driving vehicles use onboard image-recognition. Data (real-world sensed data and "training" data) gets uploaded to the cloud, and algorithms downloaded. The collision-avoidance system will recognise a risk locally, in microseconds.

 They can focus resources on the most-important aspects: I saw a videoconference developer last week talk about using AI to spot "points of interest" such as a face, and prioritise "face packets" over "background packets" in their app. Selective forwarding units (SFUs) act as video-switches which are network-aware, device-aware, cost-aware and "importance-aware" - for example, favouring the main "dominant" speaker.
 
Another comms developer (from Facebook, which has 400 million monthly users of voice/video chat) talked about the variables it collects about calls, to optimise quality and user experience "outcome": network conditions, battery level before & after, duration, device type & CPU patterns, codec choice and much more. I suspect they will also soon be able to work out how happy/annoyed the participants are based on emotional analysis. I asked about what FB wanted from network APIs and capabilities - hoping for a QoS reference - and got a blank look. It's not even on the radar screen.

At another event, GE's Minds and Machines, the "edge" nodes have a cut-down version of their Predix software which can work without the cloud-based mothership when offline - essential when you consider the node could be on a locomotive in a desert, or on a plane at 35000ft.

The simple truth is that there is no "end to end QoS" for Internet applications. Nobody controls every step from a user's retina to a server, for generic "permissionless innovation" applications and services. Paid prioritisation is a nonsense concept - the Net Neutrality crowd should stop using that strawman.

Yes, there's a need for better QoS (or delta-Q or performance management or slicing or whatever other term you want to use) in the middle of networks, and for very specific implementations like critical communications for public safety. 

The big unknown is for specific, big, mostly mono-directional flows of "content", such as streaming video. There could be an argument for Netflix and YouTube and peers, given they already pay CDNs, although that's a flawed analogy on many levels. But I suspect there's a risk there that any QoS payments to non-neutral networks get (more than?) offset by reverse payments by those networks to the video players. If telcos charge Netflix for QoS, it wouldn't surprise me to see Netflix charge telcos for access. It's unclear if it's zero-sum, positive or negative net.

But for the wider Public Internet, for consumer mobile apps or enterprise cloud? Guaranteed (or paid) QoS is a myth, and a damaging one. Yes, better-quality, better-managed networks are desirable. Yes, internal core-network use of better performance-management, slicing and other techniques will be important for telcos. Private wireless or fixed broadband networks, where the owner controls the apps and devices, might be an opportunity too.

But the concept of general, per-app QoS-based Internet access remains a dud. Both network innovation and AI are taking it ever-further from reality. Some developers may work to mark certain packets to assist routing - but they won't be paying SPs for an abstract notion of "quality". The notion of an "application outcome" is itself a wide and moving target, which the network industry only sees through a very narrow lens.

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.

Telcos & OEMS: You should ignore the GSMA's "Advanced Messaging", RCS & "Universal Profile"

Summary: There are  10+ reasons why RCS messaging has failed, despite a decade of trying. Even with Google's involvement, the GSMA's "Universal Profile" and "Advanced Messaging" only fix, at most, two of these problems - and introduce new ones. Despite the hype, mobile operators should continue to deploy VoLTE only when it is really needed, and should avoid Advanced Messaging, RCS and ViLTE entirely. There are many other better ways for telcos to retain relevance in communications apps & services.



What's happening? 

In the next couple of weeks, we will likely be hearing a lot about the GSMA’s “Universal Profile” (UP), developed with Google as a standardised setup for new Android devices to support VoLTE, plus the latest version of the decade-old failed RCS messaging "zombie" service, now being rebranded as “Advanced Messaging”.

UP also incorporates a version of ViLTE, the video-calling application that can’t even be called a zombie, as it was never alive in the first place. Essentially, UP is a combination of VoLTE and RCS6.0. The first spec was published in Nov 16 (link). (Microsoft is also apparently supporting it, although seems less deeply involved than Google).

Expect the MWC announcements to talk breathlessly about how this is going to enable “Messaging as a Platform” (MaaP), and there will likely be some dubious-seeming big numbers mentioned. Any claims of "XXXmillion active users" should be *very* carefully questioned and analysed - what actually counts as use? There will be a lot of spin, painting what is essentially legacy SMS usage with a new app, as RCS. Daily is much more relevant than monthly data here.

Most probably, you’ll hear lots of hype and PR noise about “mobile operators winning back against the OTTs”, or “people won’t need to download apps”, or “everyone is fed up of having 17 messaging apps”. You’ll hear that it can use network—based QoS, which is great for VoLTE primary-telephony calls, but irrelevant otherwise. Vendors will probably say “well you’ve got an IMS for VoLTE so you should sweat the assets and add extra applications”.

We might even get an announcement about “advanced calling”, which is a way to improve phone calls with pre/mid/post-call capabilities (not actually a bad idea if done well) but force-fitted to use RCS rather than a more pragmatic and flexible approach (which is a very bad idea, and likely executed very poorly).

So ignore it. There are no customers, no use-cases, and no revenues associated with “advanced messaging”. It’s the same pointless RCS zombie-tech I’ve been accurately predicting would fail for the last decade. It’s still dead, still shambling around and still trying to eat your brain. It’s managed to bite Google and Samsung, and they’ll probably try to infect you as well.

What's the background?

If you're new here: I've been following and talking negatively about RCS for 9 years now. The project started in 2007, and emerged as a lukewarm 2008 IM concept for featurephones (link) in the days when both iOS and Facebook where just emerging onto the stage. I described it as a "coalition of the losers" in a report in 2010 (link) It evolved to a dead-on-arrival branded app called "joyn" as smartphones gained traction (link), and it has tried climbing out of its grave so many times since that I describe it as a zombie (link). Various operators have deployed it, then given up - even in markets like Spain and South Korea where multiple operators offered it at first.

I'm currently writing a report on VoLTE trends and implications for my STL/Telco 2.0 Future of the Network research stream (link). It should be out in the next month or so. As part of my research, I've been updating myself about the GSMA's plans to blend VoLTE with RCS - hence becoming aware of the Universal Profile and Advanced Messaging developments. 

Most people I speak to in the mobile industry privately admit that it's been a huge white elephant. I've met people who've been given the "poison chalice" of RCS inside operators and eventually quit their jobs in desperation. Huge slugs of time and money have been spent on a no-hope service, that could have been better deployed elsewhere, on things that could make a real difference. 

It's been pushed by:

• A few operators misunderstanding the nature of user behaviour, requirements and preferences for communications services, thinking that there had to be a standardised and interoperable "magic bullet" to compete with WhatsApp, Facebook, iMessage and WeChat (and 100's of others).
• The desperation of network vendors trying to make IMS seem relevant for something other than plain-old phone-call VoIP, either for fixed broadband voice, or VoLTE.
• The GSMA's stubborn belief that it needs to predefine interoperability and lengthy specifications, rather than iterate on something basic that people actually like. Also, the belief that it has to tie in the phone number / any-to-any model.
• Google, wanting to find a way to compete in the messaging space it has repeatedly failed with, especially creating an Android version of iMessage based on the Jibe acquisition. Samsung has recently joined in with its own acquisition of Newnet.

So my "coalition of the losers" joke (er... jibe?) in fact has a reasonable basis in history. And history doesn't record many such coalitions having great success at anything, except maybe keeping a few people occupied.

A couple of operators have launched recently - Rogers and Sprint in North America - but the other operators are still delaying, and have big iPhone populations anyway.
 
In the meantime, while the telecom industry has procrastinated over RCS, various other adjacent players such as Twilio and Nexmo (now Vonage) have pushed the supposedly "dead" SMS market to become the standard mechanism for A2P messaging, and signed up thousands of developers for that, plus voice/video/notification cPaaS capabilities. In the time it has taken RCS to get to its 10th anniversary, we have seen Apple, Facebook, Whatsapp, WeChat and others create huge value and loyalty.


But, but... Google!
 

It’s a little difficult to tell if Google actually believes in RCS, or whether it’s just cynically using the GSMA and gullible MNOs to push Android harder – and especially, help reduce the horrendous fragmentation of its platform in terms of both OEM-specific skews and non-updated older OS variants.

As I wrote previously (link), it also seems likely that Google is using the surprisingly-pliant cellular industry to help it create its own version of Apple’s iMessage. The optional hosted RCS Hub could also be an early foray by Google into the NFV and cloud communications space – perhaps with an eye to ultimately competing not just with the Huawei/Ericsson/Nokia axis, but also maybe Amazon and Twilio over time. That’s quite an extrapolation on my part, though - not based on anything public from Mountain View.

What’s definitely clear is that Google doesn’t see RCS as “the one messaging platform to rule them all”, nor the Universal Profile as a way to replace all other forms of voice and video communications. It has a broad range of other services, including Duo, Allo, Voice, HangOuts (now being reoriented towards enterprise), WebRTC support in Chrome and perhaps natively in Android at some point. It also has a stake in Symphony (messaging/UC for finance and other verticals), and works with most of the larger UCaaS and hosted PBX/UC players.

It also wouldn’t be a surprise if Google acquires other cool youth-oriented messaging apps to compete with Facebook’s Instagram, although a post-IPO Snap might be too pricey. And of course, it has its own push-notification platform which is probably (quietly) the world’s biggest messaging service that nobody talks about.

In other words, Google seems OK about creating a lowest-common denominator function that's no worse than what it has already, but which brings extra cooperation brownie-points from the mobile industry, and a bit more leverage with its wayward licensees. Its downside is limited - and if miraculously it somehow it can create a MaaP platform, its upside significant. There's probably also some interesting data-analytics and machine-learning gains in here somewhere too - even if it's just a better understanding of what Android users don't like.

In other words, from Google's point of view, it's a worthwhile and almost risk-free punt. Whether the mobile industry wants to over-rely on a company with a reputation for ruthlessly shutting down failed ventures is another matter.

 

What's wrong with UP/Advanced Messaging? 

Where do I start?! Well, perhaps by pointing out what actually has changed for the positive. It's true that Google is offering a hosted RCS platform for operators that don't yet have an IMS. ("Effectively sponsoring this piece" - link). That's helpful as it reduces friction and cost of operators getting RCS to market. So to does having a pre-certified set of devices that should work with that platform, or in-house deployments. 

But while perhaps those are necessary, they are very far from being sufficient. Many other problems and concerns abound.

The biggest lie about RCS and the “universal profile” is that it will become universal or ubiquitous. Not only is Apple not likely to support it, but it is far from clear that Android OEMs will implement it on all their devices, especially those sold in the open market. It is unlikely to have good PC support (although to be fair, neither does Whatsapp). It is unlikely to be downloaded onto older Android phones. It is unlikely to work smoothly on dual/multi-SIM handsets, of which there are hundreds of millions. It’s unlikely to work well on many MVNOs’ devices (neither does VoLTE). It’s also unlikely to work nicely on the vast plethora of smart IoT devices that support SMS – even those with decent web-browsers and app downloads. 

I've seen some of the projections for RCS-capable handset penetration, and I think they're significantly over-enthusiastic, especially if considered on a country-by-country basis.

There is no relevance of RCS for the enterprise UCaaS and vertical markets that telcos urgently need to focus on. That has to integrate with all manner of other communications services that seem unlikely to have more than a loose coupling with RCS, if at all. It won't be replacing email, Office365, Cisco Spark, Slack, HipChat and numerous other collaboration tools, not to mention the universe of video-conferencing. It's also going to be a long time before it becomes another channel in contact centres' multi-channel platforms - there's a long list of bigger fish, especially if WhatsApp and Facebook offer APIs to billions of users.

The MaaP approach seems doomed to failure – there are no examples of successful technology platforms that have not been based on successful technology products first. Trying to pre-guess the requirements for a platform – let alone creating voluminous standards for it - ignores a wealth of experience: customers use products in unexpected ways, with spikes in viral adoption, unpredictable demographic biases, emergent behaviour and geographical patchiness.

Platforms are created in response to a product’s growth, not pre-ordained. Nobody predicted that Snapchat had the potential to become a media channel and camera/AR platform – those angles represent reactions to actual real-world usage, as well as improvements in “adjacent” technology in the interim. More importantly, developers are unlikely to become interested until there is evidence of real-world usage among a decent slice of their target audiences. You'd have to be a brave airline to ditch your native apps, ignore Facebook and WeChat and iMessage, and port your main loyalty "experience" to a mini-app inside the RCS client.

There are assorted other problems lurking as well - interconnect and roaming should be interesting. Will it really be free to do video-sharing and file-transfer to your friend in Singapore? Trying to work out the pricing aspects will be challenging too - unless everything is free, for everyone, and to everyone. While that might be feasible for post-paid customers with big data quotas, it's unlikely to translate to the worlds billions of prepay users. 

It's slow to evolve, as it's designed by committee. It's not set up to do A/B testing on live audiences - maybe 100 million on a redesign first, to see how it goes and then make a call on full rollout. Standardisation and interoperability doesn't work with the agile, devops approach to apps that is de-rigeur here.

And another of the herd of elephants - what's it for? Who is going to use it, and why? I can't foresee any case-studies of teenagers saying "I used to SnapChat my friends all the time, but now we only use HyperMessage+ from NetworkXYZ!". Is it just generic SMS-style "Hi, I'm running 5mins late" stuff? But with "rich" elements, at least insofar as the person you're connecting with is another RCS user who can see them? Why else are people going to use it, except maybe as some sort of lower-than-lowest common denominator? And moreover, whats going to keep them using it, given how dynamic the communications app market is. Unless it can capture the "cool" factor, it's toast.

This is the problem - pretty much everyone can get WhatsApp or WeChat or Facebook. There's a 90%+ chance your friends are on your platform of choice and have no reason to switch. iMessage is the obvious anomaly, but it's more of a hygiene factor between Apple users - who often also have multiple devices like tablets and Macs as well, and who expect to "fall back" to FB or WA for friends (or groups of friends) who aren't Apple users. I guess in low-Apple penetration countries there could be tighter communities of Android buddies, but they may well include people with a lot of prepay accounts, older open-market handsets (some multi-SIM) and little likelihood to upgrade to a new UP-powered one soon. (One possible exception is India, given Reliance Jio's influence). 

So what should you do? (Or not do?)

If you’re the head of advanced communications at an operator, or looking into future voice and video services, don’t bother wasting your time in Barcelona on RCS or "advanced messaging". 

Sure, speak to vendors and look at cheap ways to implement VoLTE. The industry painted itself into a corner with a horrendously complex and expensive approach, so finding quick/simple/reliable ways to launch or scale it make sense. (Think open-source, cloud-based, pseudo-NFV for IMS without the hugely complex MANOs etc). VoLTE is becoming increasingly mainstream, although its adoption in many operators' networks is quite gradual. Insofar as the Universal Profile helps with handset/network interop for voice calls, it has a role to play.

But beyond VoLTE, operators and handset OEMs need to ignore the exhortations of the GSMA to implement so-called “Advanced Messaging” (I wrote that before I realised the acronym spells SCAM). It will soak up money, technical and marketing resources, customer attention and credibility. Even if the Google-hosted RCS platform reduces the cost of operators deploying their own servers, it will still need testing, integration with in-house IMS platforms and new NFV systems and other actions.

Be very very skeptical of all the announcements. Any user statistics should be scrutinised carefully - while some operators technically have RCS servers live, the key statistic that won’t be mentioned is how many active users are doing anything beyond basic SMS-type messaging. How many are actually using RCS properly - and like it? The reality is that essentially zero people have switched from using Facebook Messenger, WeChat or Snapchat to using RCS for any meaningful purposes – and a reasonable forecast for 2019 would be roughly zero as well.

Go and see genuine innovators in messaging and communications platforms for inspiration. Have a look at the various business UCaaS providers. Seek out anything based on WebRTC. Speak to the cPaaS providers & talk about partnerships. Look for open-source platforms for infrastructure and IMS (eg from Metaswitch & Canonical). Track down in-app messaging, or ways to hook IoT devices' signalling traffic into the mix (MQTT and so on). Look for companies doing interesting things with SMS - it's not dead, especially for A2P uses. Look at what some vendors are operators are doing with 2nd/3rd-generation API platforms for developers.

There are dozens of clever options for messaging innovation available for operators (or MVNOs, cPaaS providers, UCaaS players and other types of SPs). RCS is not one of them.
It's notable that in all of the GSMA's literature & commentary I've been able to find, I've seen almost zero mentions of these words: Viral, Fun, Snapchat, Slack, Instagram, Emoji, Twilio. But there's lots of "interoperable" and "rich" and scare-stories about telephony ARPU.

Although, ironically, GSMA's own Twitter avatar is a SnapChat ghost at the moment. And it has its own Snap channel (link). Maybe if it announces at MWC that SnapChat is transitioning to/interconnecting with RCS it'd be a gamechanger. But otherwise, it speaks volumes that it's promoting one of the Internet success stories in 2017 messaging.

As I've said before: Ubiquity is earned, not imposed. RCS stilll needs to prove that users actually want it before it can have pretensions to being a platform. For now, remember So-Called Advanced Messaging is still a failure - it's an unfortunate acronym, but amusingly appropriate. If the Universal Profile had just been about implementing - and improving - VoLTE to improve the telephony experience, it would make sense. Instead, it's been weighed down with a lot of harmful baggage.


 
If you're thinking "So what else should I do instead?" or "How do I stop my management team making an expensive mistake?" then you're in the right place. Contact me about possible workshops or other advice. information AT disruptive-analysis DOT com