I am just as excited about the potential of 5G as anyone, but I’m also a little worried that we might fall prey to some of the same issues that have hurt SDN, NFV, and IoT. We have a lot of time to get this done right, but we do have to be sure to take some essential steps in the time we have.
Stripped of all the hype and nonsense, 5G is a set of specifications that are designed to bring mobile/cellular services into the mainstream. Up to now, we’ve based mobile services on a special set of standards that called out special infrastructure, custom devices, and so forth. The hope is that 5G will fix that. Up to now, we’ve had to build non-connection services above and independent of the mobile network; the hope is that 5G will fix that too. Segmentation of services and operators (MVNOs, roaming) were barely accommodated before, and should be fundamental to 5G.
If we had no mobile services today, all of these capabilities would be somewhat daunting. With mobile services being the profit focus of operators and the consumer’s target of desire, it’s way more than that. Given that we’re also trying to work in “revolutions” like SDN and NFV, you can start to appreciate the industry challenge this represents. To meet it we have to do something we’ve typically not done—start at the top.
Logically, the top of 5G is the user. Every user is represented by an appliance, and that appliance provides the user with a set of service connections. Since we don’t want to have an architecture that isolates 5G users from other users, we should visualize the user population as being connected to a series of “service planes”, like voice calling, SMS, and Internet.
So far, this model would describe not only current wireless services but also wireline. It’s a matter of how the service-plane implementation is handled. That’s a good thing, because the first test of an architecture is whether it can represent all the stages of what you’re trying to do.
The next thing, then, is to look at the service-plane connection and implementation. As I’ve just suggested, this is a two-stage process, meaning that we have a “connection” to services and an “implementation” of services. Let’s look at that with an illustration, HERE, and you can follow this along with the text below.
Today, in theory, we have a consumer and business service plane that can support three classes of users—wireline, wireless, and satellite. Today, each of these user types are supported by independent implementations within the service plane (though there is some trunk-sharing), connected into a cohesive service through a gateway process set. Voice and data services are converging on IP but still have a substantial service-specific set of elements. All of this is due to the way that services and infrastructure has evolved.
This now opens the discussion of 5G, because one of the goals of 5G is to converge mobile service implementation on a common model, probably one based on IP. So what we could say the future would look like is an expanded model for an IP service plane that could support not only mobility (for new mobile services) but also wireline IP and satellite services. This means that access-technology or device-specific service connectivity would be harmonized with generic service-plane behavior in the access connection.
That single service-plane implementation, as defined here, is based on IP connectivity. But in reality what we want is to be able to support service tenancy, meaning that we can segment the service plane by service, by operator (MVNO), etc. Each segment would be potentially a ship in the night, though any of them could still be integrated in some way with other segments. This is a mission that’s usually assigned to SDN in some form, including possibly the overlay-SD-WAN model.
Any of the service planes would be made up of trunks and nodes, and these trunks and nodes could be either physical devices/pathways or virtual (function) elements, meaning that they could be hosted on something. To me, this suggests that under the service plane and its tenants, we have an infrastructure plane that is made up of multiple layers. First, we have contributed services, meaning the fundamental services that are consumed by the service plane to create retail offerings. Second, we have a resource layer that provides the raw materials.
In the resource area, we have a combination of three things—real devices, virtual devices/functions, and hosting facilities. My view here is that we have function classes, meaning abstract things that can build up to services, and that these function classes can be fulfilled either with real appliances or hosted virtual functions. There should be a common model for all the necessary function classes; this wasn’t done with NFV and it’s essential if you’re going to harmonize service management and make operations more efficient.
Orchestration, as a function, is parallel with these layers, but you don’t necessarily have to use a single model or tool across them all. I do believe that a single orchestration model and software set would be beneficial, but I’m trying to be realistic here and avoid demanding uniformity when it’s not clear whether quick adoption and facile evolution might be better served with multiple models.
Management, in my view, focuses on managing function classes using class-specific APIs that would likely build from a base function-management set common to all function classes. The function-class model could assure that we have consistent management no matter how the specific component services are implemented at that moment, which makes it evolution-friendly.
Some people will argue that this approach doesn’t have much specific to do with 5G, but I disagree. 5G’s goals can be divided into the radio-network goal, which is wireless-specific, and the “convergence and segmentation” goal, which is generalized. We don’t need as much industry debate on the former as on the latter, and you can’t achieve a general goal while considering only one technology from the list your trying to converge.
The general, but largely unrecognized, trend in networking has been toward a specific overlay/underlay model, a model where infrastructure is harmonized in capabilities across a range of service options, and where service specificity is created like any other feature. Increasingly by hosting, obviously. Virtualization is the current way we see this model evolving, but we can’t lose sight of the goals by diddling with pieces of solution and small segments of the overall opportunity.