ONAP Network Slice Model 5G Use Case Team Oct, 2018

Outline Network Slice definition Network Slice model SDC features to support Network Slice model Additional points to address

5G Network Slicing - Services ONAP 5G: Service Providers (SP) need to support a rich set of advanced 5G wireless services for mission critical communications, such as enhanced Mobile Broad Band (eMBB) Ultra-Reliable, Low-latency Communications (URLLC ) massive Internet of Things (mIoT)

3GPP 5G Network Slicing Concept leveraged by ONAP A service instance is realized by one or more network slice instances (NSIs), that in turn may consist of network slice subnet instances (NSSIs).

ONAP Network Slicing – Design Steps ONAP Service Designer define TOSCA templates for the reusable tasks: Model a RAN NSST defining parameters that will define covering a specified set of cells, bandwise, latency, priority etc. Model a CN NSST defining parameters that will define a specified “capacity” and other parameters Model a suitably isolated transport network template for connecting the RAN to Core Network with QoS, bandwidth, resiliency and other parameters Model a Network Slice Template to be used to instantiate, modify, and remove the Network Slice (Network Slice as a Service)

Network Slice modeling The proposal is to have different models for different network slices and slice segments. There should be a model for eMBB slice and a different model for URLLC slice. The models will differ by composition of the comprised network slice segment services. Some models can have shared RAN while dedicated Core and Transport, others can have shared RAN, Core and Transport while yet others can have dedicated RAN, Core and Transport. The models should have parameters that operator will need to fill upon instantiation of the network slice / segment. The intention is to keep the number of these parameters as low as possible in order to reduce the need for operator to provide too much data. Internally the parameters should be interpreted into multiple services parameters as needed. For example: E2E slice maximum latency. This parameter will be on the Network Slice level, it will be mapped to segment level parameters and will be used in orchestration and homing to fulfill the required slice behavior. The orchestrator shall have a workflow associated to this slice with the ability to select segments according to allowed latency, and calculate the total maximum latency, summarizing the latency of each segment.

Service dependency Description: In Beijing there is the ability to model hierarchies, however there is no way to declare if the “internal” services should have their own lifecycle or not i.e. is it an association or composition. In Dublin we would like to add the ability to define rules on the “internal” service for the orchestrator to find an existing service instance of the correct specification. This feature will use a TOSCA node filter in the model.

NSS RAN service model (one of the options) Network Slice Segment RAN consists (for illustration only) of DU, CU-UP and CU-CP. There is an alternative approach to model RAN part of the slice by exposing RAN controller only (e.g. RIC), which is responsible for RAN configuration and control. The resource (PNF) DU (or could be RIC) is wrapped as a service and is consumed as a composition of a service. This means that for this slice segment instantiation, CU- CP and CU-UP will be created while orchestrator will search and use an existing instance of a DU service that encapsulates a DU resource. Choosing a DU service that fits certain criteria (like area, latency or bandwise) will be supported.

NSS Core service model (partial, for illustration only) Network Slice Segment Core consists (just for illustration) of AMF, SMF, UPF and NSSF. For this example the AMF, SMF and UPF are dedicated to this slice segment only. They will be instantiated upon slice segment instantiation and visible in context of this slice segment. Their lifecycle will be as the slice segment lifecycle. The NSSF is shared between different slices. Therefore it is encapsulated in a service and is modeled in the slice as a composite service.

NS service model Network Slice model is composed of NSS RAN, NSS Core and NSS Transport. In this example Transport and Core segments are dedicated and RAN is shared.

Service Properties Description: In Beijing there is no way to define top down properties on a service. You can only promote properties from children limiting the ability to model inputs used in processing the service. In Dublin will be added the ability to add properties to a service. For example, network slice e2e latency. This parameter will be on the slice service level. Slice creation operation workflow will be able to fulfill the service by aggregating latency on the different segments.

Points to address further E2E Slice / Slice Segment – E2E service topology diagram in SDC SLA/SLOs for the slice and segments Define Parameters that are part of each model component (resources, services) Define Parameters for the NS service / NSS services LCM operation for each component Policies (placement, scaling, sharing etc.) FM/PM for network slice services Sub-slices / services within a broad slice Resources requirements (Radio, Transport, Core), reservation mode (shared, reserved exclusively, right to preempt, etc.)

Thank you