ONAP Network Slicing Model 5 G Use Case

ONAP Network Slicing Model 5 G Use Case Team - Borislav Glozman (Amdocs) Modeling Service IM – Chuyi Guo (China. Mobile) Mar, 2019

Outline • Network Slicing definition • Network Slicing SDC model • SDC features to support Network Slicing model • Information Model • Tosca templates

3 GPP 5 G Network Slicing Concept leveraged by ONAP 3 GPP TS 28. 541 3 GPP TR 28. 801 • A service instance is realized by one or more network slice instances (NSIs), that in turn consists of network slice subnet instance(s) (NSSIs).

ONAP Network Slicing – Design Steps • ONAP Service Designer define TOSCA templates for the reusable tasks: • Model a RAN NSST, defining parameters that represent set of cells (tracking area), bandwidth, latency, priority etc. • Model a CN NSST with parameters like “capacity” and others • Model a suitably isolated transport network template for connecting the RAN to Core Network with Qo. S, 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) 4

Network Slice modeling • The proposal is to have different models for different network slices and slice segments. • There should be a model for e. MBB 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: E 2 E 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. 5

Example: e. MBB Network Slice e. MBB SVC PNF e. MBB-NS Transport Network VNF e. MBB-NS Properties: TAs: All Latency: 30 ms Mobility: fully mobility resource. Sharing: shared Shared Dedicated e. MBB-NSS 5 G-RAN-NSS VL RIC TRANS-NSS 5 GC-CP-SVC CU-CP TN DU 5 GC-NSS CU-UP VL 5 GC-UP-SVC 6

Example of 5 G e. MBB Network Slice Segment modeling • Example e. MBB NSS consists of 5 G-RAN-NSS, 5 GC-NSS and TRANSPORT NSS. e. MBB-NSS 7

Example of RAN NSS modeling • Example 5 G RAN NSS consists of DU (as a Service), CU-CP and CU-UP and virtual links between them. • There also External Connection Points. 5 G-RAN-NSS 8

Example of 5 G Core modeling • Example 5 GC NSS consists of 5 GC-CP-SVC, 5 GC-UP-SVC and virtual links between them. • There also External Connection Points. 5 GC-CP-SVC 5 GC-UP-SVC 9

Example of EPC NSS modeling • Example EPC NSS consists of EPC-CP-SVC, EPC-UP-SVC and virtual links between them. • There also External Connection Points. EPC-CP-SVC LTE-EPC-NSS EPC-UP-SVC 10

Service Modelling enhancements - Amdocs contribution in SDC FEATURE DESCRIPTION Service dependencies § § In Beijing there is the ability to model hierarchies, however there is no way to declare if the child service should have their own lifecycle or not i. e. is it an association or composition. In Dublin the ability to define rules on the child for the orchestrator to find an existing service instance of the correct specification will be added, this feature will use a TOSCA node filter in the model. NEW

Service Modelling enhancements - Amdocs contribution in SDC FEATURE DESCRIPTION Service properties top down modelling § § 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 the ability to add properties will be added to a Service and VNF NEW

Service Modelling enhancements - Amdocs contribution in SDC FEATURE DESCRIPTION Service operations (with associated workflows) § § In Beijing operations were added to VNFs including mapping of the properties needed by each operation, additionally workflows were added an association to a given operation in support of change management. In Dublin this same pattern will be replicated on a service. In addition we will allow creating of workflows in context of operation NEW

Service Modelling enhancements - Amdocs contribution in SDC FEATURE DESCRIPTION Consumption of service children operations § § NEW In Beijing there is no way to assign a value to a child (service or VNF) operation input. In Dublin the ability to define child operation input data including mapping from other children, static values and input properties

Information model

Filter illustration example Template u. LLC NSS RAN NSS (shared) Filter: latency<X Transport NSS Core NSS X is input parameter Instances RAN ins 1 latency = 10 ms RAN ins 2 latency = 7 ms RAN ins 3 Transport ins. A (new instance) Core ins. B (new instance) Upon u. LLC NSS instantiation, orchestrator will search for an existing RAN NSS and instantiate Transport and Core NSS services Choosing of RAN NSS will be according to requirements/capabilities (RAN NSS) and also according to filter parameter (latency) latency = 5 ms 16

Filter illustration example – cont. Let’s say there is a Slice (ULLC) that needs RAN Slice Subnet with latency < 5 ms There will be a runtime attribute (Latency) that will hold the latency value of a specific slice subnet instance A filter of the Service that consumes this shared Service will be RAN Latency < u. LLC NSS. Latency Consuming Services Consumed Service 5 G RAN NSS ULLC NSS Filter: RAN Latency < u. LLC NSS. Latency RAN Latency = 4 ms ULLC NSS Filter: RAN Latency < u. LLC NSS. Latency 17

Filter illustration – another example Another example: Filter functionality may be used for accounting of resource sharing Let’s say there is a Service that can be shared K times There will be a runtime attribute (available. Instances) that will hold the number of times this Service can be shared A filter of the Service that consumes this shared Service will be (available. Instances > 0) Upon consumption of the Service (Z), its attribute (available. Instances) will be decreased Shared Service Z Consuming Service A Filter: available. Instances > 0 available. Instances = K Consuming Service B Filter: available. Instances > 0 Consuming Service C Filter: available. Instances > 0 18

Rational of Using the Nested Service Approach for Network Slicing Ø Nested Network Service is the only approach for shared resources (PNF/VNF/NS) approved by ETSI IFA specs • See also the Nested network service TOSCA implementation contributed to ETSI NFV-SOL 001 (NFVSOL(19)000101 r 1_SOL 001 ed 261_Support_of_nested_NS) • PNFD does not currently allow to have any LCM operations so the operations can be applied to Nested Service Ø Allotted resources approach based on current understating is not planned to be contributed in Dublin release Ø Sharing of Network Slice resources (PNF’s and VNF’s) for Dublin release is proposed using Nested services approach • Wrap PNFs/VNF’s with Services and define operations and properties on Service level • Assign workflows to the operations. 19

Example: DUaa. S Example of a PNF resource that is shared between different network slice subnets using shared nested service: DUaa. S (NS) Frequencies Bandwidth Latency … DU (PNF) Properties: Name Vendor Location … Properties: Operation A: Parameters: Operation B: … Parameters: Operation C: … Parameters: ETSI SOL 001 does not define operations and custom properties on PNFs. ONAP SDC does not allow operations on PNFs (even though it allows to define properties). Solution: Wrap PNFs with Services and define operations and properties on Service level. Assign workflows to the operations. … DU 20

Example: DUaa. S – Initial deployment 21

Example: DUaa. S – Sharing 22

Example: DUaa. S – Sharing with RIC 23

Tosca template for Service Sharing using Node Filters example tosca_definitions_version: tosca_simple_yaml_1_1 metadata: invariant. UUID: 64139478 -5 b 7 c-4 da 9 -bf 3 e-5 f 4 a 8 f 0 f 4243 UUID: 8 ec 2 fed 7 -a 759 -43 b 0 -aafd-b 9 cd 6 b 8 dbced name: e. MBB NSS description: Enhanced Mobile Broad Band Network Slice Subnet type: Service category: Network Service service. Type: '' service. Role: '' instantiation. Type: A-la-carte service. Ecomp. Naming: false ecomp. Generated. Naming: false naming. Policy: '' environment. Context: General_Revenue-Bearing imports: - nodes: - datatypes: file: data. yml - capabilities: file: capabilities. yml - relationships: file: relationships. yml - groups: file: groups. yml - policies: file: policies. yml - annotations: file: annotations. yml - service-e. MBB NSS-interface: file: service-Embb. Nss-template-interface. yml - resource-service. Proxy: node_types: org. openecomp. nodes. netaas_proxy: org. openecomp. nodes. 5 gcnss_proxy: org. openecomp. nodes. 5 grannss_proxy: topology_template: node_templates: TRANS NSS: 5 G RAN NSS: type: org. openecomp. nodes. 5 grannss_proxy directives: - selectable node_filter: properties: - RAN Latency: less_than: - e. MBB NSS - Latency - Mobility: equal: - e. MBB NSS - Mobility - Resource. Sharing: equal: - e. MBB NSS - Resource. Sharing metadata: requirements: capabilities: 5 GC NSS: substitution_mappings: 24

s Thank you

3 GPP TS 28. 541 26