With the advent of 5G, a much more highly virtualized and dense mobile network infrastructure will place greater demands on management. 5G virtualization presents new challenges, both through individual components running as Virtual Network Functions (VNFs) and through network slicing, chiefly because these factors result in complex networks and consequently, much more complex network management.
Work is underway among the industry groups charged with developing and ratifying standards for 5G implementation. However, the current visions for slice management run a high risk of making network management so complex that it will significantly impact 5G roll-out and flexibility. The burdens of complexity will likely drive service providers to avoid the problem by adopting single-vendor network solutions. This will impact openness, and reduced commitment to openness carries a high price.
But what if there were an approach that simplifies slice management and allows service providers to bring 5G quickly to market. Such an approach could base network management on a simple technology domain-based model, using standard interfaces per-domain to address 5G management and then evolving this design after initial deployment.
Engineering principles tell us the way to solve a complex problem is to break it down into simpler smaller problems. For 5G this means breaking the network into domains that can be managed individually but also linked to each other for capacity planning, service management, correlation, etc. A great deal of work is going into slice management for 5G, but it is also essential to think about the big picture and consider the entire approach for a fully manageable, easily implementable 5G network.
By breaking the problem down to domains, we can rely on each domain to understand the best way to provide resources for each 5G service class. These domains could also own the job of keeping service classes separate, so as to provide each as a separate network slice. It would then be the job of multi-domain orchestration to manage the combined resources to provide the end-to-end network and make it visible to the service layer.
The domains shown in Figure 1, and their interfaces are as follows:
- User Domain: The 5G user equipment, such as a smartphone, set-top box, PC, or IoT device. User equipment management standards will be part of the base specifications for 5G.
- Virtualized Radio Access: Contains the remote radio, distributed unit and central unit, and where possible, runs as VNFs on commercial off-the-shelf (COTS) compute, storage and inter-networking provided by the virtualized infrastructure domain. The ORAN (Open Radio Access Network) Alliance is standardizing management interfaces for the 5G RAN as well as for interworking interfaces in the network.
- Transport Domain: The transport domain is potentially split beyond what is in 4G. It contains fronthaul, midhaul, and backhaul elements, and will typically be an Ethernet over optical infrastructure. This domain may contain a cloud control layer based on virtualized compute. Existing transport interfaces across IP, Ethernet and optical layers are usable here including: Transport API (TAPI), Metro Ethernet Forum lifecycle orchestration (MEF LSO), and TM Forum interfaces. Open-source tools like OpenDaylight will be relevant to building interoperable controllers in this domain.
- 5G Core: The core 5G network functions for functions such as authentication, access and mobility management and policy control. The 5G Core runs as VNFs on COTS provided by the virtualized infrastructure domain. 5G Core domain functions will have management interfaces defined per-function as part of the base 5G specifications.
- 5G Services Domain: The 5G services domain understands the business logic and service class requirements for 5G services. Various standards and open source technologies may be applicable such as TM Forum and Open Network Automation Platform (ONAP), as well as work in the 5G Public Private Partnership (5G PPP) and other bodies.
- Virtualized Infrastructure Domain: This domain includes the COTS infrastructure and the software stack for virtualization, including technologies and APIs from OpenStack, Kubernetes, and the Cloud Native Computing foundation. Telecom-specific software such as ONAP and Open Source Mano (OSM) can be applied.
In the scenario represented by Figure 2, each domain understands how to deliver its own appropriate set of network slices. This set of slices is then brought together by the multidomain orchestration layer to deliver an end-to-end network. The service layer can then request an end-to-end network from the orchestration layer that specifies the service class required.
Clearly, there will be cases where one domain needs visibility or control of an adjacent domain to provide the service level required. The multidomain orchestration layer could provide a dependency model that ensures such dependencies between domains. Ultimately some form of peer interworking between domains will be needed.
Looking at the long term, one desired goal may be to reduce the overall number of domains by combining management to get better capacity utilization and control over the infrastructure. However, separation allows for smoother initial roll-outs while retaining the openness desired by network operators. Another goal will be to begin to implement the full network slicing models envisioned by groups like 5G PPP and European Telecommunications Standards Institute (ETSI) as the 5G network matures.
The simplicity of a technology domain-based approach in early roll-outs of 5G will ensure that operators can mix and match technologies and avoid vendor lock-in, while still providing the services needed by customers and fulfilling the overall potential of the 5G network.