5G Network Slicing is a new concept to allow differentiated treatment to network traffic depending on each customer’s or use case’s requirements. With network slicing, it’s now possible for Network Operators to consider customers or use cases as different context types with each having different service requirements. In this blog, we shall uncover the architecture of NSSMF and its interaction with other components.
This article was originally published by Aarna Networks.
In order to orchestrate and manage 5G network slicing, the Linux Foundation Open Network Automation Platform (ONAP) project has come with E2E slice management architecture with different choices based upon various 3GPP defined components with specific roles (e.g CSMF, NSMF, NSSMF). As already mentioned, we shall delve deep into the architecture of NSSMF and the underlying components. First, let us have a look at some of the keywords about the subject in consideration:
5G ONAP Network Slicing
In ONAP, options 1 & 4 from the various slice management architecture choices are supported — see Figure-1.
Figure-1: Slice Management Architecture Choice
Essentially, the choices have evolved from the requirements of service providers and open source community contributors. In Architecture Choice#1, CSMF, NSMF, and NSSMF are internal components of ONAP in reference design and implementation. In this option, OSS/BSS can integrate with the runtime component CSMF hosted in SO for business and operational needs. In Choice#4, CSMF and NSMF are internal components of ONAP and hosted in a runtime component called SO. In Figure-1, CSMF takes the business requirements from OSS/BSS and transforms communication service requirements to network slice requirements and is consumed by NSMF. Moreover, NSMF is responsible for the management and orchestration of NSI and derive network slice subnet requirements. In choice#4, NSSMF is an external component and is responsible for the management and orchestration of NSSI. ONAP has implemented standard APIs defined by 3GPP towards NSSMF and the same is listed below in Table-1.
Table-1: NBI Interface exposed from NSSMF towards NSMF
Figure-2: NSSMF as external to ONAP (Choice#4)
As we uncover architecture choice#4, NSSMF performs communication with the ONAP NSMF component and that integration is done using the standard RestAPI interface as per Table-1 shown above. In our NSSMF architecture as shown below in Figure-2, consists of various elements and is defined as:
● NBI Interface: This is the reception point for all the incoming requests from NSMF using the RestAPIs as detailed in Table-1.
● Model Validator: This component validates the incoming NSMF requests with predefined models for various lifecycle events of a slice.
● NSS Manager: Network Slice Subnet manager decides the role of processing the incoming request in Asynchronous or Synchronous flow mode.
● Egress Manager/Ingress Manager: NSSMF is defined with two internal roles. First being a forwarder and second as a receiver. This helps in a distributed model for processing slice events.
● CnCfgManager: The core network configuration manager is responsible for processing the slice events received from the Ingress manager for event types as AllocateNSSI, ActivateNSSI, DeactivateNSSI, and DeAllocateNSSI. Core network configuration manager was built with the support of NETCONF client and RESTCONF interface to cater deployment of network functions (NF) as PNF and CNF respectively.
Refer to our webinar where we deep dive on NSSMF architecture and talk about insights and how the slice event lifecycle is processed by NSSMF and provisioning a commercial 5GC Network functions with a demo. You can refer to the video link: https://lnkd.in/gHvyFhx for details.
● 3GPP TS 28.541
● 3GPP TS 28.531