I noted in yesterday’s blog that there were AI missions that could generate telco revenues. I’m not suggesting that these would be telcos selling AI, nor am I suggesting that these services would necessarily even depend on AI. In fact, they might depend on something else.
What we know is that they’re almost certainly business services. There is no indication that telcos could sell incremental services to consumers without abandoning their bias toward connectivity-based services. What new service could telcos offer enterprises that would be transformational? That’s a question that telcos should be trying to answer, but one that probably has to be answered by enterprises. I’ve had enterprise comments from over 400 enterprises on telecom evolution, but only 93 comments on an optimum future service offering. I’m going to focus on those today, or more properly on the 63 that described something both very different (25 said “just cut prices for current services”) and converged at least somewhat on a common theme. The theme? IoT.
Telcos loved the idea of IoT, for all the wrong reasons. Why rely on human reproduction and upward economic mobility to increase your TAM and ARPU, respectively? Get machines to consume telecom services. OK, that sounds cynical, but you’d be surprised at the number of telecom CxOs who admit that their thinking reduced to that. The presumption was that “Internet of Things” would mean a major connectivity, authentication, and thing-management burden that they’d be paid to carry. Obviously, this drove nearly all the early IoT initiatives, but when it didn’t pan out as expected, things floundered.
Enterprises’ comments suggest that the telcos got part of the answer, but only a small part, in their initial planning. That wasn’t enough to move the ball in terms of project generation, approvals, and execution. What’s needed isn’t what telcos find convenient or interesting, but what’s needed to drive the buyer to commit. An IoT service isn’t just connectivity and management, it’s not even just about networks, and it’s even somewhat about stuff that never gets off the customer’s premises.
One comment I made about edge computing resonated with most of the 63 enterprises I’m citing here. I visualized hosting as a set of layers, starting with stuff that was so sensitive to latency and QoS that it had to be proximate to the business activity being supported, and then building outward/upward to things that could be done in an enterprise or cloud data center. The comment I got most often on this point was something like “Yes! And there has to be a set of middleware and service tools that builds application components so they can run in any of these layers.”
This reflects a reality we miss often in tech, which is that you can’t launch a revolution from a standing start unless you have both an absolutely compelling buyer need and an absolutely compelling seller opportunity. Such a thing isn’t likely to happen, which means that a future transformation evolves from some limited attempt to transform in the present. IoT as a telco opportunity grows out of…IoT as it is today. That’s local process control using specialized “embedded control” systems and software. If there’s a telco IoT opportunity, it’s logical to see it as evolving somehow from opportunistic changes in the mission of these current systems. Network connectivity opportunity, central to a telco role in anything, comes about because something requires these applications (in whole or in part) to migrate off their local hosts. Find that, and find how to make the migration work for enterprises, and you have the basis for a telco IoT service.
Why not just address the remote hosting of the current embedded IoT applications? Because enterprises say there’s no business case to be made there, because the mission is already being filled in a way that’s proven satisfactory. Without the Internet and e-commerce, we’d not have cloud computing today, at least not at the level we do. Change drove the cloud, and change has to drive IoT services.
What would a real driver of change look like? The 63 enterprises offer the same answer—integration. Right now, businesses tend to be a series of loosely connected processes, each of which is automated in its own way. The office/transaction stuff is divided as we all have seen; accounting, payroll and personnel, order and inventory. The IoT stuff tends to be compartmentalized by facility. You have factories, you have warehouses, and you automate them. For transactional systems, we integrate through APIs, API brokers, service busses and meshes. For IoT, we need to integrate more than the automation, we need to integrate the real-world stuff being made and moved. Thus, we need a kind of transportation process, something to link facilities. That process has to be driven by what it links, and its automation has to link to the automation of the linked facilities.
The nice thing about transportation automation is that it relies on assets that move around, that are not currently controlled by local embedded processor systems. There are many transportation systems that do have sensor/controller elements, but most of these are really about finding the vehicles and contents or maintaining specific conditions inside to protect that which is being moved. There’s room to create a two-level (many-layered) system for transportation of goods, parts, even people. One level has to be abstraction-based, a digital twin of real-world elements. The other has to be software, portable through all manner of hosting points, designed to be distributed to the points of shipment and reception and integrate with the systems there to drive the real-world movement of things.
Another nice thing? This ties in with 5G. One of the 63 enterprises described a project to use an open-source O-RAN implementation to create a hosting point for edge components of an IoT application. They jokingly called their model the “RIC-Rack”, referencing the RAN Intelligent Controller. Their implementation created a platform linked to the O-RAN RIC via an API set, one for the non-real-time and one for the near-real-time piece. This tightly couples the contents of the virtual rack with the RAN implementation. They’ve been discussing the extension of the approach to public 5G, but with more cloud providers than telcos.
All the telco IoT elements of the past can fit into this “rack”, and be justified by it. It could be the basis for a telecom IoT service that would transform the whole of IoT. But there’s a problem. Not a single telco has even suggested thinking about this, and none of the 63 enterprises believed that the telcos could build the necessary software architecture. Could the cloud providers? Yes, and they could also facilitate the integration of the RIC-Rack, but they couldn’t guarantee it was universally accepted, and the opportunity can’t wait for 6G to firm up. Could cloud/telco partnering work? That’s probably the best shot at turning away the risk that the new IoT model is another source of disintermediation for telcos. From disintermediation to remediation? Not quite. Maybe to mitigation, which is all you can expect if you don’t want to play the right game.
Or, maybe, a telco-centric vendor? Nokia has Open RAN credentials. Nokia has private 5G, digital twins, advanced IoT work. Might they step up here? I’m not hearing about it yet, but it wouldn’t surprise me a bit.
