The cloud providers, like everyone else, want to increase revenues. One path to that is to get more enterprise work into the cloud. Another is to get more new applications into the cloud, and it’s likely the easiest way to do that is to target the telecom vertical, who lags behind other verticals in cloud penetration. A Fierce Network report on cloud providers’ attendance at the TM Forum event, DTW Ignite, offers a chance to compare what came out of that effort with what I’ve heard from telcos themselves. It’s also an opportunity for me to address some email questions/comments I had on my recent blogs on OSS/BSS.
One thing that all parties agree on is that the logical low-apple target for the cloud is OSS/BSS. These systems are largely identical in requirements and architecture to the core business applications of other verticals; BSS in particular. However, as you move more into OSS, the network operations work (the NOC) and into hosting network/service logic, you enter more a realm of real-time processing, something that the cloud is still largely leaving on the table. As the article points out, there are elements of 5G running in the cloud, but so far the selection of target 5G features has focused on non-real-time missions, particularly ones that are linked to the interconnection of 5G with the Internet and content delivery networks (CDNs).
The problem with a cloud targeting of OSS/BSS is that these systems are relatively static, long-lived, deployments and that their utility has been under fire for decades. Not only that, telco comments indicate that more than two-thirds have already completed cloudification plans as far as they plan to go. If you want to make more money, you need to sell new stuff, which either means going beyond OSS/BSS or somehow getting them to embrace a broader mission.
Whether the cloud providers decide to broaden their target applications for the telco world or not, it’s important for them to engage with the standards processes as much as possible. Telcos make major infrastructure changes when standards change, and rarely otherwise. If the 6G goals of convergence of access technology, which are really goals of service independence, are met, mobile standards changes may well drive all future infrastructure opportunities. But the TM Forum is about OSS/BSS, which in traditional terms means the telco CIO operations group, separate from the group that participates in standards like 6G (the office of the CTO does that, usually) or that manages the network (operations group, or COO). In addition, the whole OSS/BSS space is in a state of dispute, and has been for decades. Will an OSS/BSS organization help telcos with greening up a brown-field hosting opportunity beyond OSS/BSS? No, but it might prepare them for how OSS itself could evolve, linking back to my comments in yesterday’s blog.
The BSS piece of OSS/BSS is the collection of activities that telcos share with any big company, things like customer and order management, payroll, personnel, regulatory, financial and taxes…you get the picture. OSS systems evolved to manage the activity of telco workers that related to service provisioning and support, what have typically been called “craft” activities. Most of these workers operated on the outside plant, and over the last couple decades telcos have been moving to self-provisioning steps to reduce the number of workers in that space. What remains has been increasingly focused on network operations, the NOC, and thus have shifted out of OSS/BSS. Today, about half of all the telcos I chat with say that service management is really an operations function, having left OSS.
That decision, though, may be a result of the way service management is viewed, which (typically for the telco world and standards) is bottom-up, meaning it’s derived from network and device management. If services were based on a template, a model, then the deployment process could assemble the management information from networks or subnetworks and digest it into service state, which could then be reported through an interface to the OSS, instead of having the OSS view (and potentially alter) network state. The change in management view means you could change the qualifications for the job of evaluating the data, making it a typical customer-service task consistent with the stuff the CIO group would normally take responsibility for.
What makes this all interesting in a non-historical sense is the 6G convergence goal, which as I said is (or should be) a goal of abstracting “service” from “network”, which lets it map to any set of networks or network elements with equal facility. The abstraction is separate from the network, which means that it (and the functions that create and maintain it) could fall into the realm of OSS as well as they could fall into the NOC. In fact, some of the past TM Forum work seemed to be preparing for this shift, though the body’s desire to always be talking about something new has submerged this work a bit in other initiatives, and it doesn’t seem to be a priority to address how 6G could change things.
If abstracting the service from the network is the key, then unlocking opportunity for cloud providers (and for the operators and vendors) is framing an OSS/BSS and network model that realizes that. A service can be viewed top-down (and it should be from the start) but also from the bottom up, to insure it can actually be implemented. In this latter view, a network and any associated hosting consists of a set of cooperative manageable units, domains of functionality that can be controlled through a common interface. These manageable units can be combined to create features that can be exposed to a service architect, and from these the architect builds a service model. This approach “submerges” resources, separating what is the domain of network operations from what could be the domain of OSS/BSS. As I said, there was a time when the TM Forum seemed to be heading to this, but they took the submerging in another direction.
Toward the market hype magnet of AI. The key point in this submerging push these days is the Forum’s five layers of autonomy, an abstract view of how networks could evolve toward fully autonomous operations. There doesn’t seem to be a lot of clarity in how each layer is realized, though. What’s also missing is the piece that says that in a fully autonomous network, you’d have services fully abstracted, so you could give the network a commercial service description and a model of the service, and it would build and sustain it. Thus, the separate model could be, and perhaps even should be, owned by the OSS element. To me, this should be the whole focus of the TM Forum.
The cloud providers may not be in a position to change the way the TM Forum works, which I’m sure frustrates them as much as the article suggests the whole network side of the telco world frustrates the cloud providers. They may be in a position to push that vision in order to create a ready new market for cloud services. To cede the network hosting mission to the cloud is a big step for operators to take. Only about ten percent of those I’ve chatted with say they’re prepared to take it, and that number hasn’t changed much over the last two years.
In a service-independent future, though, the frustrating network stuff, with its reliability and latency requirements, are separated from the service piece. You now have a service architect role, a role that defines a service in terms of feature combination and service parameters and SLAs. This role is clearly more a business activity, and it would be easy to see it being run by the OSS. In addition, when you press a service onto a network, you invoke a number of hierarchical steps, meaning that a top-layer feature-centric service model is decomposed into a successive layer of intent models, which at some point transition from what I’ve always called the “service domain” (where they are still abstracted) to the “resource domain” where they actually change infrastructure, and which is also logically the responsibility of the NOC. You could say that this is the domain of “resource architects”, who assemble primitive features from those manageable units to be composed into services. The whole of the service domain is arguably non-real-time in requirements, and so could be cloud-hosted. The resource domain is likely near-real-time.
It’s probably clear here that the kind of transformation that telcos need, and that cloud providers want, requires a formalization of a lot of concepts that have been circulating in the industry for two decades, but that have never seemed to attract the right levels of support. Can the TM Forum make that happen? I’m doubtful, so I think the cloud providers really don’t move their opportunity ball closer to the goal like by watching it. They need to push this service-abstraction story in it, and in the market at large, to get the most telco bucks out of their marketing bang.
