We need a technical framework for network evolution if we’re to go forward with the NetCo/ServCo organizational shift the TMF paper I’ve been blogging about suggests. If the Next Generation Mobile Networks Alliance (NGMN) could define anything useful as the model of next-generation telco-centric hosting infrastructure, it would be a great service. If they could actually do so in a way that fully exploits the cloud, it would be even better, and if we could use what it generated as the technical stepping-stone to a new operator organizational model, then better yet. And if it could also guide the evolution of infrastructure toward that next generation…well, it would be great. Can we do that? That’s what I propose to explore now.
I think the most practical way of assessing the value of the NGMN approach is to focus on its evolutionary value, since evolution considers present and future and the pathway that links them. The document does propose to support “Different types of infrastructure (VM, Bare metal, smart NIC and HW accelerators – Telco/Private Cloud or Public Cloud) are abstracted in a consistent and predictable way and made consumable by the applications, as required.” That’s a worthy goal, but it misses an important infrastructure category, and why that’s important is even more critical than the miss.
Networks today are made up primarily of routers, switches, optical gear, radios, and fiber trunks. Yes, 5G and NFV introduce hosted functions, but those functions are just a small piece of the total infrastructure budget. Can we say that the NGMN approach is covering the evolutionary bases when, first, it doesn’t include most current network elements, and second, the operators overwhelmingly say that hosted functions will not replace most of those current elements, but instead will augment them? I don’t think so.
But the big issue here is that hosting functions exposes a management dilemma, because we now have two levels of management when before we had one. Networks built from devices have device management capabilities that cover both the platform hardware and the software functionality. When you host functions, you necessarily separate these two things. Platform management is responsible for the hosting resources as a pool, and functional management is responsible for managing the functions themselves. You can see this in a simple example; a “firewall” virtual network function has to be managed as a firewall at the functional level, but its performance and even operational state depend on the platform it runs on.
And it gets more complex. If we accept the TMF notion of NetCo and ServCo, and my notion of FeatCo as outlined in the referenced blog, then we also have to say that there exists another management layer, “service management”, that integrates the management of the collective systems that make up a sellable user experience.
In all, these management issues may be the biggest challenge in infrastructure, service, and organizational shifts. To attack that angle, we need to start at the top.
Management at the highest level boils down to two options. First, you manage the services being sold, and from service issues you drill down to infrastructure issues. Second, you manage the infrastructure against capacity/performance plans, and presume that as long as the infrastructure is meeting its (presumably valid) objectives, the services will follow along. Even in that second case, though, I think we can assume that realistic customer care would demand some level of service awareness, since the most vulnerable piece of any service tends to be customer-specific—the end/access connection.
The big question regarding service management, and regarding just what the relationship between various infrastructure elements might be, is whether a service is composed of specific resource/function commitments or is based on a shared collective infrastructure set. In my past work on this, I called the latter “platform services”, and they’d include things like 5G elements because those elements aren’t deployed per-call or even per-caller, but rather are shared just as a public network (like the Internet) is based on shared infrastructure. Where platform services are involved, the capacity planning approach works and explicit service management is likely to be little more than service monitoring or even management by complaint. Where discrete functions are required, then the state of those functions determines the state of the service, and management must reflect that.
If a service is made up of multiple features/functions, then I think we must assume that service management has to unify the management viewpoints of the respective feature/function elements. I’ve long argued that this means having a service represented by a hierarchy of intent models, and that the management views at each level are obtained by querying databases that are populated by regular polling or events by a centralized process. That prevents having multiple services creating what’s effectively a DDoS attach of management APIs.
For these discrete-deployment models of service, I think the notion of a hierarchical model that’s managing the lifecycle of the service and its elements is the right approach. Such a model could accommodate not only multiple functions, but potentially multiple implementation options for the same function, depending on considerations like geography, availability, and cost.
The NGMN approach could accommodate this only if we assumed that either all functions (including those of the data plane) were hosted, or we assumed that some higher-level model showed how we’d integrate deployed functions with “platform services” or appliances. That, in my view, is a crippling limitation because having it in play means that NGMN doesn’t really move the ball in the infrastructure evolution space at all. We can do it if we go outside the platform strategy only.
But the biggest problem with the NGMN approach, IMHO, is that it falls prey to the same shortsighted vision problem that impacted the TMF paper, but in a different way. The problem the TMF had was a lack of a clear technical framework, which meant it could not guide infrastructure evolution. The problem NGMN has is that it lacks a complete framework for the functions to be hosted. Yes, it says “microservices” and “containers” and “Kubernetes”, but that only describes the relationship between element and host. It doesn’t describe how functions are turned into elements, or whether there is some platform-as-a-service API set that provides a toolkit for function authoring.
What’s at the root of all of this? I think that operators, and organizations that operators populate, tend to think of “NetCo” as the only “Co” in the story. Even as they admit to the need for partnerships with other players to create feature/function value-add for services, they expect those others to do all the heavy lifting with regard to establishing the architecture within which those services develop. That’s a sure invitation to silos at best and non-participation the likely worst case. Operators need to be thinking about the middleware for feature hosting if they expect that middleware to develop in a way that builds their own revenue streams.
