Where Can Operators Go If Connectivity Services Aren’t Enough?

Services based on physical connectivity, like IP services today, seem to be hitting a profit wall.  As I’ve pointed out in other blogs, we’re seeing operators under pressure to cut costs because customer willingness to pay for more bandwidth isn’t particularly high.  There are surveys that suggest that plenty of users would like 100Mbps, or a gig, or more of both mobile and wireline capacity.  Data on current services, though, shows that users don’t cluster at the high end of speed options.  That suggests that they don’t really find even current maximum bandwidth all that cost-effective.  For free, people take what they can get.  For pay, it’s a different story.

The challenge this poses for operators and OTTs alike is that bandwidth is the key to increased profit for both groups.  You need to sell something more if you expect to get more revenue, and capacity seems the logical thing for operators to look at.  If you’re an OTT, you need bandwidth to carry new and improved services that can earn you more.  The combination means that operators do need to be willing to modernize and improve both wireless and wireline networks, but to do that they have to sustain an ROI on infrastructure that’s at least as high as their current average internal rate of return.  Revenue per bit hasn’t met that objective, which is why cost management has been such a recent focus.  However, cost reduction strategies vanish to a point; you can’t reduce costs to a negative level.  Revenue is needed.

There are two ways operators have looked at new revenue.  One is to add connectivity features that are valuable enough to pay for, and the other is to rise up the food chain to become more OTT-like, meaning features aimed more at delivering experiences than at connecting things.  There are problems/challenges with both.

Connectivity features are things like add-on higher-layer security elements, virtual networking, bandwidth on demand, and other things that relate to making connectivity better or cheaper.  The biggest problem with these features is that they have little value to consumers and their value to enterprises is more problematic than it might seem.  We’ve had story after story, claim after claim, on things like bandwidth on demand, and it’s never really gone anywhere.  One reason is that it’s hard to differentiate connection services—they connect or they don’t.  That means that something like bandwidth on demand is useful to buyers primarily if it’s cheaper, which defeats it as a source of new revenue to sellers.

Virtual networking is a connectivity feature that has the virtue of not having been discredited.  There are two dimensions to virtual networking—one that focuses on the concept as a means of exploiting lower-cost access/connection services (the Internet) as a replacement for more expensive tailored VPN services, and the other that focuses on the security and performance benefits of explicit connectivity control and application-specific prioritization.  This is where SD-WAN plays, with most vendors offering only the first of the two dimensions.  That’s a problem in my view, because it means that while those first-dimension SD-WANs could add some revenue by connecting sites that you can’t get on an IP VPN today, it also risks cannibalizing IP VPN revenues.

That leaves the second aspect of virtual networking as the focus point for revenue growth from connection services.  The fact that most operators today have settled for the first-dimension solutions is an indication that virtual networking is something that operators don’t really understand, and regarding which they aren’t finding much awareness among their prospects either.  Educating buyers to create demand is the antithesis of what network operators are used to; they’re the “Build it and they will come” crowd.

The whole point of virtual networking is that the goals of transport infrastructure and connection services are very different.  If you’re building a network for a given market area, it’s logical to look for an approach that lets you connect everything in the area.  That offers better operations and capital economies.  However, if you’re a network user, you don’t want to be connected to everyone, only to the things you want to use.  Promiscuous connectivity is a security problem, and network security is already eating way too much budget dollars.  Virtual networks, if they could make connectivity work as users want, could be a big boon.

The best way to use one of these second-dimension virtual networks would be to have all connectivity be explicit, meaning that it has to be called for.  Making that happen means either having the user (or the user’s application) establish the valid/used connections, or having the virtual network software make a determination based on something like the identity of the endpoints.  User-driven connection management would require changes in the users’ software platform, and probably a general elevation of user literacy—neither of which are likely.  That leaves us with the network-software approach.

To make explicit connectivity work at the network level, you need to start with a way of positive identification of endpoints.  In a VPN, that’s not all that difficult because (presumably) people wouldn’t admit someone onto a virtual network like an SD-WAN if they weren’t entitled to connect to something.  Just having positive user identification is a big step in improving connectivity management.

You can take further steps from there, the most obvious being the step that says “OK, these two endpoints are both mine, but are they really allowed to connect?”  If endpoints were assigned “roles” such as “member of the accounting management team” or “application to support payroll”, you could create role-based access rules that would add considerably to the effectiveness of connection management, without creating excessive effort and delay in getting things connected.  You could also track connection attempts that were not authorized, and bar them until they’re reviewed.

These are good features for revenue enhancement to business customers, but not for the mass market.  Does that mean operators need to get into the OTT business?  They probably should be looking into that, but there’s also an intermediate option, what might be called the “services” space.  For that, we’ll need an example.

Let’s say we have a desire to offer augmented reality, with a user having a “view” of a street that consists of the real world, overlaid by labels.  Each label represents a point of interest, not necessarily limited to landmarks, etc. but including places and even perhaps people.  Could a network operator build a model of labels, based on what a given user would be seeing, perhaps even getting feedback from the real-world side of the AR view?  If they did, they could sell this to OTTs who wanted to offer contextual services.

We could also sell augmentations to the basic service.  Suppose I’m shopping for something.  My hypothetical operator could obtain retail catalog information from stores and show me a point of interest label (with the item and price) on stores where my target purchase could be made.  Again, this could be sold as a service to OTTs.

The point of these examples is that there are plenty of things that are essential for the future of some key technologies (like augmented reality or autonomous vehicles) that everyone will need.  Should everyone produce them?  That would be a massive competitive overbuild, so to speak.  Better to obtain them from a third party.  Operators could be that third party, and participate in OTT services without taking on a retail role.

“Could”, again is the operative qualifier.  The problem operators clearly have is an institutional reluctance to embrace anything that’s not a simple connectivity service.  Even SD-WAN, the best opportunity to break out of the old mode, is being used in the minimalist mode, as nothing more than a higher-level version of basic IP.  The service model of OTT services would surely be easier for them, but at least at the moment they seem convinced that doing nothing is easier still.  And it may be; there are still at least some operators (in high demand-density areas) that could hope to make connectivity profitable enough.  The problem is that nobody knows who these are for sure, and it’s a pretty serious risk for any operator to assume they’re among the chosen.