The architecture design, resulting implementation and operation of 5G network softwarization are recommended to provide a sustainable competition environment considering social and economic issues. This includes drastic reduction of the components and systems lifecycle and operational costs for efficient and sustainable deployment, enabling appropriate return for all actors involved in the networking and servicing ecosystem, a reduction of barriers to entry in the 5G networking and servicing ecosystem and solving tussles among the range of participants in the ecosystem—such as users, various providers, governments, and IPR holders — by providing proper economic motivation.
A number of technologies have failed to flourish, or be justifiable due to inadequate or unsuitable architecture, concerning essential economic and social aspects (i.e. including contention among participants and/or lack of competing technologies, and/or lack of mechanisms to stimulate fair competition)
Gap analysis
Sufficient attention needs to be paid to economic and social aspects such as economic incentives in designing and implementing the 5G Network softwarization and its architecture in order to provide a sustainable competition environment to the various participants.
Drastic reduction of the operational and lifecycle costs for all components and systems involved in the 5G network softwarization would be recommended for efficient and sustainable deployment enabling appropriate return for all involved actors.
Ways of resolving economic conflicts including tussles in 5G networking and servicing ecosystem that include economic reward for each participant’s contribution are becoming essential. Different participants may pursue conflicting interests, which could lead to conflict over the overall multi-domain operation of Network softwarization and controversy in international/domestic regulation issues.
There are two aspects to consider for the integrated network management and orchestration for the IMT-2020 network softwarization. First aspect is how to manage and orchestrate the softwarized network components in a uniform and e2e way. The second one is how to softwarize network management and orchestration functionality.
The former should address traditional management functionality such as fault, configuration, performance, accounting, and security and orchestration functionality for a multiple domains, layers, and technologies within a single slice and for a multiple slices. Especially, orchestration among multiple slices if those slices belong to the same administration responsibility is a very challenging problem which hasn’t been addressed up to now. ETSI NFV MANO architecture deals with orchestration of a single slice.
The latter should address optimal methodology of softwarizing and deploying management and orchestration functionality. The management and orchestration functionality consist of various sub-components such manager, agent, collector, virtual analytics instrumentation, autonomic management policy decision element, management information repository, etc. These components can be deployed as a standalone device or virtual function embedded in a hosting server. Optimal placement of these components is a new area to tackle with. In particular, dynamic runtime placement of such components is possible in the softwarized network environment to achieve optimal resource usage.
Another important issue is a multi-domain/layer/technology/slice orchestration. Within a single slice, there can be multiple domains of VNFs ranging from mobile access, core, and SDDC. Each domain can have one or more domain specific orchestrators. And some domain such as mobile core can have multi-layer (e.g., packet, PTN, OTN layers) networks and multi-layer orchestrator is required. For end-to-end orchestration, a multi-technology orchestrator that coordinates among domain or layer specific orchestrators is required. Also multi-slice orchestration is required for multiple slicesthat belong to the same network provider.
Figure 4 Multi-domain/layer/technology/slice Orchestration High-level Architecture
Figure 4 illustrates details of the multi-domain/layer/technology/slice orchestration. Within a single slice, there can be multiple domains of VNFs ranging from mobile access, core, and SDDC. Each domain can have one or more domain specific orchestrators. And some domain such as mobile core can have multi-layer (e.g., packet, PTN, OTN layers) networks and multi-layer orchestrator is required. For end-to-end orchestration, a multi-technology orchestrator that coordinates among domain or layer specific orchestrators is required. Also multi-slice orchestration is required for multiple slices which belong to the same network provider. Fig.x also shows that autonomic knowledge plane addresses optimal orchestration policy decisions.
Gap analysis:
There are two aspects to consider for the network management and orchestration for the network softwarization. First aspect is how to manage and orchestrate the softwarized network components. The second one is how to softwarize network management and orchestration functionality. The current technology gaps to be filled in are provided.
Some identified gaps which need to be filled in 5G network management are:
- Multi-technology orchestration across heterogeneous 5G multiple domains ranging from radio access, core, to SDDC.
- Multi-slice orchestration in case that multiple slices are allocated into a single tenant and service.
- Autonomic management capability for the efficient multi-technology/domain orchestration policy decision making.
- Optimal placement capability of virtualized management functional components in the 5G networks.
- Lightweight management and orchestration architecture to cope with performance problem and high OPEX
- In-system management capabilities empowering the network to control complexity using decentralization, self-organization, autonomy, and autonomicity as its basic enabling concepts. As such the management tasks are embedded in the network and the network as a managed system now executes management functions on its own.
- None-slio management and orchestration architecture to reduce both OPEX and CAPEX.
Share with your friends: |