Use Case Description and Blueprint

Owned by LIN MENG
Last updated: Mar 05, 2020
4 min read

E2E Network Slicing Blueprint

The objective of this use case is to realize End-to-End 5G Network Slicing using ONAP. An End-to-End Network Slice consists of RAN (Radio Access Network), Transport Network (TN) and Core Network (CN) slice sub-nets. This use case intends to demonstrate the modeling, orchestration (life cycle and resources) and assurance of a network slice which are implemented in alignment with relevant standards. The key highlights of this use case include:

  • Modular architecture providing building blocks and flexibility under various deployment scenarios

  • Functionality aligned with 3GPP and other relevant standards such as ETSI and IETF

  • Interfaces and APIs aligned with relevant standards (3GPP, IETF, ETSI, TM Forum, etc.) while enabling easy customization through use of appropriate plug-ins. This would enable easier interoperability of slice management functions realized within ONAP with 3rd party slice management functions, as well as northbound and southbound systems.

  • Taking a step-by-step approach to realizing different architectural options in an extendable manner.

  • Providing flexibility in network slice selection by providing an option of manual intervention, as well as abstracting the network internals as needed.

  • The use case implementation team is composed of service providers, software and hardware vendors, solution providers and system integrators thereby taking into consideration different perspectives and requirements.



This use case is a multi-release effort in ONAP with the first steps taken in Frankfurt release. It will continue to expand in scope both in breadth and depth, and along the journey it shall also align with updates to the relevant standards which are also currently evolving. This use case shall also collaborate with other open initiatives such as O-RAN to enable wider adoption and use.

Overall High level view for ONAP-based Slice Management 

Architecture Choice

3GPP(TS 28.801) defines three layer slice management functions which include:

CSMF(Communication Service Management Function):

•Responsible for translating the communication service related requirement to network slice related requirements.

•Communicate with Network Slice Management Function (NSMF).

NSMF(Network Slice Management Function):

•Responsible for management and orchestration of NSI.
•Derive network slice subnet related requirements from network slice related requirements.
•Communicate with the Network Slice Subnet Management Function (NSSMF) and Communication Service Management Function.

NSSMF(Network Slice Subnet Management Function):

•Responsible for management and orchestration of NSSI.
•Communicate with the NSMF.



To realize the three layers of the slice management function, we need to decide whether to implement CSMF, NSMF or NSMF within ONAP, or use the external CSMF, NSMF or NSSMF. This implies that for ONAP-based network slice management, we have different choices from an architectural perspective:

1) Implement CSMF, NSMF, NSSMF all within ONAP;

2) Connect an external CSMF from the Northbound, Implement NSMF and NSSMF within ONAP;

3) Connect an external CSMF from the Northbound, Implement NSMF within ONAP, Connect a 3rd party NSSMF from the Southbound;

4) Implement CSMF, NSMF within ONAP, Connect a 3rd party NSSMF from then Southbound.

5) Use external CSMF and NSMF, only implement NSSMF within ONAP.

























External Interfaces

The guiding principle is when a Slice Management function is outside ONAP, standard interfaces/APIs (3GPP, IETF, ETSI, TM Forum, etc.) can be supported by default, while any customization of such interfaces shall also be supported by ONAP using suitable plug-ins/adaptors. This would enable easier interoperability of slice management functions realized within ONAP with 3rd party slice management functions, as well as northbound and southbound systems.

Another key point would be that  both internal and external interface mechanisms should be supported by the corresponding ONAP modules. To be more specific, communication between Slice Management Functions within ONAP (e.g., CSMF and NSMF) shall use ONAP internal mechanisms such as workflow calls, DMaaPmessages, etc. or standard APIs as appropriate. For example, SO acting as NSMF should support API call directly from CSMF in ONAP, as well as API trigger from an external CSMF via EXT-API.

NSI Life Cycle View

3GPP Specification (3GPP TS 28.530) describes management aspects of a Network Slice Instance, which can be described by the four phases:

  • Preparation: The preparation phase includes network slice design, network slice capacity planning, on-boarding and evaluation of the network functions, preparing the network environment and other necessary preparations required to be done before the creation of an NSI

  • Commisioning: NSI provisioning in the commissioning phase includes creation of the NSI. During NSI creation all needed resources are allocated and configured to satisfy the network slice requirements. The creation of an NSI can include creation and/or modification of the NSI constituents

  • Operation:The Operation phase includes the activation, supervision, performance reporting (e.g. for KPI monitoring), resource capacity planning, modification,and de-activation of an NSI.

  • Decommissioning: Network slice instance provisioning in the decommissioning phase includes decommissioning of non-shared constituents if required and removing the NSI specific configuration from the shared constituents. After the decommissioning phase, the NSI is terminated and does not exist anymore.

The ONAP-based NSI lifecycle management will finally provide the demonstration of all these phases.