ONAP Network Slicing Po C Proposal for Frankfurt

ONAP Network Slicing: Po. C Proposal for Frankfurt Aug 27, 2019 Swaminathan Seetharaman (Wipro), Shankaranarayanan P N (AT&T), Rakesh Sinha (AT&T), Dilip Krishnaswamy (Reliance Jio), Borislav Glozman (Amdocs), Rishi Tandon (Verizon)

Network Slicing: 3 GPP Context Ref. : 3 GPP TS 28. 530 Intel Confidential

Scoping Use case proposal - NSI Life Cycle (Frankfurt) Objective: Demonstrate e 2 e slice design and instantiation, including RAN & core slice sub-net design and instantiation. Ref. : 3 GPP TS 28. 530 Scope for Frankfurt Stretch goal for Frankfurt (a simple closed loop control) • Design and pre-provision: Creation of necessary slice/slice sub-net templates • Instantiation/Configuration & Activation: Instantiation of NSI (including instantiation/mapping of its constituent slice sub-nets) Stretch Goal: Modification (scaling/healing) based on Slice FM/PM data reporting (simple closed loop control) Note: This scope *may not* involve UE on boarding onto the slice as defined in 3 GPP TS 23. 501, if we don’t realize the traffic flow part.

Network Slicing: End-to-end view for Frankfurt Core slice sub-net 2 e. MBB RAN slice sub-net 2 RAN slice sub-net 1 Slice 2 Core slice sub-net 1 Slice 1 VNFs list Link BW BW needed Latency Throughput m. MTC Blue - Leverage functionality implemented in Dublin Realized using Simulators 1. Design slice sub-net templates for RAN and core (based on NRM in 3 GPP TS 28. 541). 2. Model a suitably isolated transport network template for connecting the RAN to Core Network with Qo. S, bandwidth, resiliency and other parameters. Alternatively it could be part of the core itself. 3. Design end-to-end slice template (based on NRM in 3 GPP TS 28. 541). 4. “Allocate” e 2 e slices (at least 2 – e. MBB and m. MTC) each with a RAN and core sub-net. 5. RAN and Core will be stubs. 6. A&AI could be a stub.

ONAP module mapping 3 GPP functions ONAP modules VID CSMF SO (Service Instantiation workflows) (Not in scope for Frankfurt) SO (Slice workflows) NSMF SO (Slice sub-net workflows) NSSMF SDN-R • Determining whether to create a new NSSI • Instantiate the new core NSSI (if needed involve VF-C) • Request OOF for resources • Instantiate the new RAN NSSI • Configure the NSSI

Flow diagram Note: SO may also directly interact with core NSSI without involving VF-C.

NSI Allocation Procedure - 3 GPP TS 28. 531 Only the NSI mapping and instantiation are within scope of Frankfurt. NSI modification is for future releases.

NSSI Allocation Procedure - 3 GPP TS 28. 531 Only the NSI mapping and instantiation are within scope of Frankfurt. NSI modification is for future releases.

Stretch Goals • Stretch Goal 1 - Introduce PM/FM data collection in DCAE, and OOF to use it for NSI allocation recommendation. - Demonstrate a simple closed loop control action for Slices (e. g. , scaling or healing trigger). - Impacts: New DCAE micro-service, RAN-Sim and Core-Sim to send PM/FM data, Policy and dashboard UI • Stretch Goal 2 - Flow of UE traffic using specified slice (abstract out registration, NSSAI, slice assignment) – e. g. , e 2 e flow of video traffic via an e. MBB slice - Interface to NSSF. - Impacts: Simulators, NSSF stub, Interface API to NSSF, traffic flow tool & setup. • Stretch Goal 3 - A&AI impacts

Slice Modeling – Leverage work done in ONAP Dublin (Borislav Glozman)

5 G Slice composition and modeling requirements Requirement Comm Service instance E 2 E Network Slice (e. g, URLLC) NST NSI NSST NSSI 5 G Core NSS VNFs Resource VL (dedicated/shared) Transport NSS 5 G (R)AN NSS VNFs PNFs VL (dedicated/shared) VNFD, PNFD, AR VNFI, PNFI, AR Cell ? 11

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

Example: e. MBB Network Slice e. MBB SVC PNF Transport Network VNF e. MBB-NS Shared Properties: TAs: All Latency: 30 ms Mobility: fully mobility resource. Sharing: 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 13

Information Models (work in progress) 14

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 Ø Sharing of Network Slice resources (PNF’s and VNF’s) for Frankfurt release is proposed using Nested services approach (based on work done for Dublin release) • Wrap PNFs/VNF’s with Services and define operations and properties on Service level • Assign workflows to the operations. 15

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: 16

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 17

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

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 19

Service Profile (3 GPP TS 28. 541) Service Profile: This data type represents the properties of network slice related requirement that should be supported by the network slice instance in 5 G network. Attribute name service. Profile. Id s. NSSAIList p. LMNId. List perf. Req max. Numberof. UEs coverage. Area. TAList latency u. EMobility. Level resource. Sharing. Level s. ST availability Support is. Readable Qualifier M T M T O T O T O T M T O T is. Writable is. Invariant is. Notifyable F T T T F F F F F T T T perf. Req: See TS 22. 261, includes experienced data rates, area traffic capacity, UE density, etc. u. EMobility. Level: stationary, nomadic, restricted mobility, full mobility. See TS 22. 261. resource. Sharing. Level: shared, non-shared

Slice Profile (3 GPP TS 28. 541) Slice Profile: This data type represents the properties of network slice subnet related requirement that should be supported by the network slice subnet instance in a 5 G network. Attribute name slice. Profile. Id s. NSSAIList p. LMNId. List perf. Req max. Numberof. UEs coverage. Area. TAList latency u. EMobility. Level resource. Sharing. Level Support is. Readabl Qualifie is. Writable e r M T F M T T O T T O T T is. Invariant is. Notifyable T F F F F T T T T T

e. MBB performance requirements (3 GPP TS 22. 261) Scenario Experienced data rate (DL) Experienced data rate (UL) Area traffic capacity (DL) 1 Urban macro 50 Mbps 25 Mbps 100 Gbps/km 2 (note 4) 50 Gbps/km 2 (note 4) 2 Rural macro 50 Mbps 25 Mbps 1 Gbps/km 2 (note 4) 3 Indoor hotspot Broadband access in a crowd Dense urban 1 Gbps 500 Mbps 25 Mbps 4 5 Area traffic capacity Overall user (UL) density Activity factor UE speed Coverage 10 000/km 2 20% Full network (note 1) 500 Mbps/km 2 (note 4) 100/km 2 20% 15 Tbps/km 2 250 000/km 2 note 2 Pedestrians and users in vehicles (up to 120 km/h Pedestrians 50 Mbps [3, 75] Tbps/km 2 [7, 5] Tbps/km 2 [500 000]/km 2 30% Pedestrians 300 Mbps 50 Mbps 750 Gbps/km 2 (note 4) 125 Gbps/km 2 (note 4) 25 000/km 2 10% N/A 30% 6 Broadcastlike services Maximum 200 Mbps (per TV channel) N/A or modest (e. g. , 500 kbps per user) N/A 7 High-speed train High-speed vehicle Airplanes connectivity 50 Mbps 25 Mbps 15 Gbps/train 7, 5 Gbps/train [15] TV channels of [20 Mbps] on one carrier 1 000/train 50 Mbps 25 Mbps [100] Gbps/km 2 [50] Gbps/km 2 4 000/km 2 50% 15 Mbps 7, 5 Mbps 1, 2 Gbps/plane 600 Mbps/plane 400/plane 20% 8 9 Full network (note 1) Office and residential (note 2) (note 3) Confined area Pedestrians and Downtown (note 1) users in vehicles (up to 60 km/h) Stationary users, Full network (note pedestrians and 1) users in vehicles (up to 500 km/h) Users in trains (up to 500 km/h) Users in vehicles (up to 250 km/h) Users in airplanes (up to 1 000 km/h) Along railways (note 1) Along roads (note 1)

PM/FM reporting (for OOF and/or Closed Loop) • PM for core NSSI: “mean usage of virtualised resource (e. g. processor, memory, disk) in single network slice instance during the granularity period” (Ref. 3 GPP TS 28. 552) • PM for RAN NSSI: upstream/downstream throughput, mean PDU sessions count • FM for NSSI: Alarm for “congestion” or “service drops threshold exceeded” or ? ? ? Ref. 3 GPP TS 28. 552, TS 28. 554 This is still work in progress – e. g. , models and UI aspects to be worked out. Intel Confidential

Points for Discussion • Notion of cell – representation, modeling in ONAP § Has implications beyond Network Slicing • O-RAN alignment for the RAN § Not feasible from timeline perspective for Frankfurt • Transport slice sub-net § Simplified for ONAP Frankfurt, to be taken up later • Service instantiation vs Slice instantiation Intel Confidential

ONAP component impacts – Initial view

Impacts in OOF Policy Models OOF SDNC CM Portal simulator PCI Handler MS Route CMSO PCI Optimizer SDNC API CMSO Optimizer HAS CMSO SO A&AI Slicing HAS OSDF Route Optimizer PCI Homing/Placement Optimizer (HAS) Multi Cloud MUSIC Slice Optimizer DCAE Policy Actual policies Dependencies on other ONAP Projects Updates for Slicing Notes • OOF shall fetch details of active slices, slice sub-nets and services from A&AI (optionally, PM/FM data from DCAE). For Frankfurt, A&AI could be a stub. • Given the similarities between Slicing and Service instantiation workflows, this could potentially be integrated/interact with HAS, but, if needed, can be seen as standalone for Frankfurt release.

Impacts in SO OE-4 Dashboard OA&M Select Recipe Data Store Service Models OI-1 Map Request Data to Recipe & Invoke BPEL Execution OI-3 OI-2 SDC Distribution Client Orchestrator Data Movement Store Request Orch Service & Resource Catalog Models Track Requests OI-8 OI-5 OI-4 Orch Execution Engine (BPMN/TOSCA) BPMN DB Service Level OI-7 Request DB Slice Level OI-6 Resource Level Orch OI-9 OI-12 OI-11 Resource/Controller Adapters Select Adapter Template Map Data to Template Execute Transaction Infrastructure/Network Adapter OE-8 Controller Adapter OE-9 OE-10 OI-7 Data Movement OI-10 Request Handler / / API Handler Micro Services Bus OE-3 OE-2 OE-1 Micro Services Bus External API Request handler to handle slice inst. request endpoint Recursive workflow option to be explored, if not workflows to be created for slice and slice sub-nets. Minimum changes to service workflows Store slice catalog items (templates, recipes)

Impacts in A&AI – to be discussed separately • Network Slice inventory (NSIs and NSSIs) - Service -> NSI -> NSSIs - NSI -> Service(s) it serves - NSSI -> Service(s) active, NSI(s) it serves We are checking if any existing/ongoing work can be leveraged (e. g. , work done for TM Forum Catalyst project). • Slice (NSI and NSSI) details - Cells (and resources in each cell) part of each (RAN) NSSI - VNF instances part of each (core) NSSI • Cell & virtual resource inventory - NSSI(s) already instantiated and resources used - Available and spare capacity - … Fallback option: Use a stub in Frankfurt

Impacts in Policy • Config policy for slice allocation, slice sharing, slice sub-net allocation and slice sub-net sharing • Config policy for resource allocation for a slice sub-net • Config policy for optimization constraints – e. g. , network resource optimization, resiliency, etc. • Stretch goal: Control loop for slice orchestration 29

Impacts in SDN-R • DGs for receiving DMaa. P message from SO with RAN NSSI details, map them to netconf messages and send to RAN. • Interaction with PNF Pn. P to be discussed • Config DB – could leverage existing Config DB and extend it. (Stretch goal: If simple control loop is realized, then SDN-R should receive DMaa. P message from Policy and send netconf message to RAN for RAN NSSI update). 30

Impacts in VF-C Intention is to avoid impact in VF-C, however, foll. aspects may have to be addressed based on further detailed impact analysis. • Input to be received from SO with NSSI details. • Create a new tenant in Openstack and instantiate “mandatory” VNFs for the NSSI. • In case the core sub-net is ‘shared’ map the request to an existing tenant. 31

Impacts in DCAE (stretch goal) • A new micro-service for PM/FM data aggregation per NSSI (leverage efforts from SON use case implementation) • VES Collector to be used for data collection • (PM/FM data specs to be defined) 32

Impacts for (potential) ONAP Stubs/UIs SO VID 1 E 2 E Slicing workflow 7 8 9 Existing workflows (for subnets) 3 2 OOF Policy 6 A&AI (stub) 4 5 DCAE Stub to show visually slice subnets created/mapped (stretch goal) – this could also be realized using A&AI. Store and provide necessary inventory data to OOF

Impacts for Simulators • RAN-Simulator § Support for network slice sub-net information models § Accept NSSI mapping/instantiation requests and respond (netconf/yang interface) § Simple UI showing mapping § Stretch Goal: PM/FM data generation and reporting to VES-Collector for Slices § To be discussed: PNF registration impacts We are exploring various options – RAN-Sim (used for 5 G OOF PCI SON use case), OAI, Flex. Ran, etc. • Core-Simulator § Sample VNFs for 5 G Core (Dummy AMF, SMF, NSSF, UPF, etc. ) § Stretch Goal: PM/FM data generation and reporting to VES-Collector for Slices Different options are being explored, including writing dummy VNFs.

To be discussed • Key assumptions • Use of simulators for RAN and Core § Feedback/inputs sought from ONAP community on availability of real NFs/simulators • Alignment with PNF Pn. P use case, RAN inventory (resources, cells) • Slice design and slice sub-net templates, information models § Leverage R 4 Modeling work - https: //wiki. onap. org/display/DW/5 G+-+Slicing • • Stretch goals A&AI modeling Interaction with 5 G core (NSSF and AMF) to be elaborated Po. C demo setup

Future Roadmap (Guilin and beyond) • • • E 2 E network slice instantiation including transport Full alignment with PNF Pn. P use case Alignment with O-RAN for RAN slicing NSI/NSSI modification Remaining aspects of network slice lifecycle orchestration Multi-level consideration by OOF for taking decision w. r. to NSI instantiation/modification, NSSI instantiation/modification • Closed loop control • Integration with 5 G-Core • Advance use cases covering URLLC, slice security & isolation, etc.

Next Steps • Finalize the details of use case flows based on feedback from ONAP community • Address open points, start discussions with respective ONAP PTLs • Work on modeling aspects (esp. related to A&AI) • Shortlist simulators/PNFs/VNFs to be used for the Po. C • Prepare the scope of stubs to be created

s Thank You!