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

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

3. 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)

4. 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).

5. 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)

6. 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.

7. 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.)

13. Thank you