ONAP Network Slicing Joint Proposal for Frankfurt Oct

  • Slides: 27
Download presentation
ONAP Network Slicing Joint Proposal for Frankfurt Oct 22, 2019 Swaminathan Seetharaman (Wipro), Shankaranarayanan

ONAP Network Slicing Joint Proposal for Frankfurt Oct 22, 2019 Swaminathan Seetharaman (Wipro), Shankaranarayanan P N (AT&T), Rakesh Sinha (AT&T), Dilip Krishnaswamy (Reliance Jio), Borislav Glozman (Amdocs), Rishi Tandon (Verizon) Lin Meng (China Mobile), Wei Chen (Tencent), Chuanyu Chen (Huawei), Maopeng Zhang (ZTE)

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

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

Scoping Use case proposal - NSI Life Cycle view (Frankfurt) Objective: Demonstrate e 2

Scoping Use case proposal - NSI Life Cycle view (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 Simple KPI monitoring is included, but no closed loop control. • Design and pre-provision: Creation of necessary slice/slice sub-net templates • Instantiation/Configuration & Activation/Deactivation of NSIs (including instantiation/mapping of its constituent slice sub-nets) Stretch Goals: Deliver full A&AI, Runtime DB and VF-C implementation for ONAP Frankfurt (see later slides for details). 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 in the demo.

3 GPP Slice Management Functions Management Function Key tasks Communication Service Management Function (CSMF)

3 GPP Slice Management Functions Management Function Key tasks Communication Service Management Function (CSMF) • Responsible for translating the communication service related requirement to network slice related requirements. • Communicate with Network Slice Management Function (NSMF) • Responsible for management and orchestration of NSI. • Derive network slice subnet related requirements from network slice related requirements. • Communicate with the Network Slice Subnet Management Function (NSSMF) and Communication Service Management Function. Network Slice Sub-net Management Function (NSSMF) • Responsible for management and orchestration of NSSI. • Communicate with the NSMF. Remarks We propose that all actions except NSSI ‘selection’ or ‘instantiation’ decision is taken within ONAP (OOF guided).

Network Slice Lifecycle for Frankfurt: 3 GPP Management Function View • CSMF Portal &

Network Slice Lifecycle for Frankfurt: 3 GPP Management Function View • CSMF Portal & workflows 1. 5 G Service create/delete 2. On-demand Service activate/deactivate ONAP Northbound interface to CSMF Support interface to external CSMF U-UI, EXT-API, SO, OOF, A&AI*, Runtime DB*, Policy* NSMF Portal & workflows 1. Slice instantiate/Terminate 2. Slice activate/deactivate 3. Manual NSI/NSSI selection 4. Manual Service Profile decomposition U-UI, EXT-API, SO, OOF, A&AI*, Runtime DB*, Policy*, Modeling NSSMF within ONAP Support basic RAN & core NSSMF functionality 3 rd party NSSMF Interface between ONAP and 3 rd party core network NSSMF SO Adaptor will be developed to connect NSSMF (both internal & external), SDN-C (R), VF-C*, A&AI*, Runtime DB* A&AI, Runtime DB and VF-C impacts may not become official part of Frankfurt release (but will surely be, after Frankfurt). Policy – only config policies impact

Additional Frankfurt Scope: 5 G Service KPI monitoring Service Provider UUI/Portal 3. 1 Tenant

Additional Frankfurt Scope: 5 G Service KPI monitoring Service Provider UUI/Portal 3. 1 Tenant NSMF Portal (Management Portal) CSMF Portal (Tenant Portal) 3. 1 3. 2 2. 1 NSSMF reports PM data to ONAP via collector 2. 2 KPI Computes MS analyses template and processes data 2. 3 Data is stored in DCAE DB EXT-API Run Time Design Time NST Model (Including KPI Monitoring ) NSST Model SDC 1 KPI Compute MS 2. 3 2. 2 5 G KPI Collector (VES / REST ) Policy Config Policy DB (historic and current KPI) 1. SDC distributes KPI template to Compute MS in DCAE 3. 1 Tenant /Operator monitors PM KPI 3. 2 Operator searches PM KPI from DCAE DB (historic data can also be visualized in DB) DCAE Impacts 2. 1 ONAP Onboard Enhancement 3 rd Party CN NSSMF New for this use case NSST Model • DCAE – New KPI Compute MS, VES Collector, (new) DB • SDC – Slice template enhancements • Policy – Config policies • EXT-API – External interface

Frankfurt Scope: Summary : CSMF within ONAP; NSSMF within ONAP+ connect external NSSMF •

Frankfurt Scope: Summary : CSMF within ONAP; NSSMF within ONAP+ connect external NSSMF • Service instantiation requested to ONAP (to CSMF – CSMF is within ONAP for Frankfurt) - CSMF, in turn, triggers network slice “allocation” request to NSMF within ONAP - Involves network slice instantiation, service <-> slice mapping (manual and automated) • On demand service activate/deactivate requested to ONAP (time-based) - Activate the service, along with the slice (the NSI bound to the service) • KPI monitoring by 3 rd party - KPI monitoring template - New microservice for KPI computation, DB for storing KPI info Note: 1. For Frankfurt, the E 2 E network slice instance will consist only of RAN and Core slice sub-net instances (transport slice sub-net is assumed to be ‘part’ of the core, for simplicity) 2. Using external CSMF will also be one of the option for our future plan but not for Frankfurt. Stretch Goal: Simple closed loop involving KPI monitoring and triggering corrective actions. 7

Proposed Demo Setup for Frankfurt ONAP UUI CSMF Portal NSMF Portal EXT-API SDC Policy

Proposed Demo Setup for Frankfurt ONAP UUI CSMF Portal NSMF Portal EXT-API SDC Policy SO (CSMF + NSMF) SDN-C (R) – RAN NSSMF Runtime DB OOF DCAE A&AI VF-C – Core NSSMF*** Core NSSMF (3 rd party) RAN (Simulated) Remarks 1. Only the ONAP components that are impacted are shown in the figure. 2. NSMF portal is only for manual intervention to provide NSI/NSSI inputs. 3. SO adaptor will be developed to connect NSSMF (external & internal) Core (Simulated) 8

Proposed Demo Highlights Sequence 1 (Service instantiation) Sequence 2 (Service activation) Sequence 3 (KPI

Proposed Demo Highlights Sequence 1 (Service instantiation) Sequence 2 (Service activation) Sequence 3 (KPI Monitoring) Instantiate a Service (CSMF Portal) Activate a Service (CSMF Portal) (time range) Instantiate & activate a Service (CSMF Portal) with KPI monitoring Service profile mapping, NST determination Determine NSI binding NSMF flows triggered (NSI, NSSI instantiation) Activate NSI Show data collection actions by new DCAE MS Show storage of KPI data in DB Show internal slice creation steps (NSI, NSSIs) in RAN & Core Activate NSSIs NSSI bound to NSI, NSI bound to service, inventory updated Update inventory, status, etc. Display KPI info Note: Offline inputs/guidance may be provided for NST selection, NSI and NSSI allocation. Intel Confidential

3 GPP Slice Management Functions – Roles and mapping to ONAP Scenario 1: CSMF,

3 GPP Slice Management Functions – Roles and mapping to ONAP Scenario 1: CSMF, NSMF and NSSMF are all within ONAP 3 GPP defined Management Functions Mapping to ONAP Communication Service Management Function (CSMF) UUI EXT-API Network Slice Management Function (NSMF) Network Slice Subnet Management Function (NSSMF) SO Transport NSSMF Adaptor RAN NSSMF Adaptor SDN-C(R) (RAN) SDN-C (Transport) Core NSSMF Adaptor OOF VF-C (Core) ONAP Notes 1. EXT-API is to ensure standard interface, and to enable federated slicing in future. 2. SO plays the role of both CSMF and NSMF. 3. OOF will provide guidance w. r. to NSI/NSSI selection and instantiation & slide resource allocation 4. For RAN, SDN-C(R) will be the NSSMF

3 GPP Slice Management Functions – Roles and mapping to ONAP Scenario 2: CSMF

3 GPP Slice Management Functions – Roles and mapping to ONAP Scenario 2: CSMF is outside ONAP, NSMF and NSSMF are within ONAP 3 GPP defined Management Functions Communication Service Management Function (CSMF) Mapping to ONAP 3 rd party system (e. g. , OSS or an application) EXT-API Network Slice Management Function (NSMF) SO Transport NSSMF Adaptor RAN NSSMF Adaptor Network Slice Subnet Management Function (NSSMF) SDN-C(R) (RAN) SDN-C (Transport) Core NSSMF Adaptor VF-C (Core) OOF ONAP Notes 1. EXT-API is to ensure standard interface, and to enable federated slicing in future. 2. OOF will provide guidance w. r. to NSI/NSSI selection and instantiation & slide resource allocation 3. For RAN, SDN-C(R) will be the NSSMF

3 GPP Slice Management Functions – Roles and mapping to ONAP Scenario 3: CSMF

3 GPP Slice Management Functions – Roles and mapping to ONAP Scenario 3: CSMF and NSSMF are outside ONAP, NSMF is within ONAP 3 GPP defined Management Functions Communication Service Management Function (CSMF) Mapping to ONAP 3 rd party system (e. g. , OSS or an application) EXT-API Network Slice Management Function (NSMF) SO Transport NSSMF Adaptor RAN NSSMF Adaptor Network Slice Subnet Management Function (NSSMF) Transport NSSMF RAN NSSMF Core NSSMF Adaptor OOF ONAP Core NSSMF Notes 1. EXT-API is to ensure standard interface, and to enable federated slicing in future. 2. OOF will provide guidance w. r. to NSI/NSSI selection and instantiation & slide resource allocation 3. For RAN, SDN-R will interface with RAN NSSMF. 4. Core NSSMF interface could be realized from SO adaptor

3 GPP Slice Management Functions – Roles and mapping to ONAP Scenario 4: CSMF

3 GPP Slice Management Functions – Roles and mapping to ONAP Scenario 4: CSMF and NSMF are within ONAP, NSSMF is outside ONAP 3 GPP defined Management Functions Mapping to ONAP Communication Service Management Function (CSMF) UUI EXT-API Network Slice Management Function (NSMF) Transport NSSMF Adaptor RAN NSSMF Adaptor Network Slice Subnet Management Function (NSSMF) OOF SO Transport NSSMF RAN NSSMF Core NSSMF Adaptor Core NSSMF ONAP Notes 1. EXT-API is to ensure standard interface, and to enable federated slicing in future. 2. OOF will provide guidance w. r. to NSI/NSSI selection and instantiation & slide resource allocation 3. For RAN, SDN-R will interface with RAN NSSMF. 4. Core NSSMF interface could be realized from SO adaptor.

3 GPP Slice Management Functions – Roles and mapping to ONAP: Summary Scenario CSMF

3 GPP Slice Management Functions – Roles and mapping to ONAP: Summary Scenario CSMF NSSMF* 1 ONAP 2 3 rd party ONAP 3 rd party 4 ONAP 3 rd party Note: Hybrid NSSMF mapping is also possible, i. e. , some NSSMFs within ONAP and some outside ONAP. • We propose that the ONAP architecture should support all 4 scenarios by means of configurable (build-time) options. To be able to do so, following to be considered: (a) (b) (c) (d) Standardized APIs on northbound between NSMF <-> CSMF Standardized APIs on southbound between NSMF <-> NSSMF Functional alignment of NSSMF to be kept uniform for all scenarios (see later slides) Standardized format of FM/PM reporting from NSSMF (this may require plug-ins/ adaptors, and is not in scope of Frankfurt release) • For Frankfurt, the functionally supported scenario(s) are illustrated in a separate slide.

NSSMF - remarks • 3 GPP allows NSSMF to be completely decoupled from NSMF

NSSMF - remarks • 3 GPP allows NSSMF to be completely decoupled from NSMF – for decision to instantiate a new NSSI, perform modifications, check feasibility of modification/instantiation of a new NSSI, etc. • However, we propose that the decision to select/instantiate/modify an NSSI is done by ONAP. For doing this, the necessary information should be made available to ONAP in Option 3 and Option 4. • For Frankfurt, we may take a simplistic approach w. r. to NSSI selection/instantiation – we assume the required inventory info is available in ONAP, without having to query/interact with the NSSMF repeatedly before arriving at a decision. This can then be enhanced further in future ONAP releases. Intel Confidential

NSSMF realization with ONAP • We propose that the NSSMF functionality is realized as

NSSMF realization with ONAP • We propose that the NSSMF functionality is realized as follows: o RAN sub-net: SDN-C (SDN-R) o Transport sub-net: SDN-C (out of scope for Frankfurt) o Core sub-net: VF-C (stretch goal for Frankfurt) The rationale for this decision is role alignment of the respective components with ONAP architecture and functional split. For optimization and resource allocation, each of the NSSMFs may interact with OOF (not in Frankfurt scope). Notes (a) When interacting with an external 3 rd party NSSMF (Scenarios 3 and 4 shown earlier), SO can interface with the external NSSMFs as shown in the figures for the different options. Alternatively one of the components specified above can interface with the external NSSMF depending on the network segment. (b) However, for Frankfurt, if VF-C implementation for Core NSSMF is not completed, interface to 3 rd party Core NSSMF will be realized in SO itself.

Impact overview: Frankfurt U-UI ONAP SDC SO OOF CSMF WF KPI Monitoring ) (enhanced)

Impact overview: Frankfurt U-UI ONAP SDC SO OOF CSMF WF KPI Monitoring ) (enhanced) A&AI Service instance CSMF and NSMF interfaces*** EXT-API NST (with E 2 E NSST (enhanced) NSMF Portal CSMF Portal Service Profile Selection NST Selection (Config) policies for OOF Optimization Service Profile NST Policy NSI CSMF Policy NSST NSMF WF NSI Selection NSSMF Adaptor KPI DB E 2 E KPI MS (new) DCAE SDN-C (SDN-R) RAN NSSMF Runtime DB RAN NSSMF data Slice Profile NSMF Policy NSSI VF-C*** Core NSSMF • • • CSMF Functions Service create/delete; Service activate/deactivate KPI monitoring NSMF Functions CN NSSMF (3 rd party) *** NSMF interface refers to NSMF NB interface to CSMF, and not to NSMF Portal (which is used for providing offline inputs to NSMF). RAN (Simulator) Core (Simulator) Slice instantiate/delete; slice activate/deactivate KPI monitoring; Manual inputs and adjustment

Summary of Impacts for Frankfurt & commitment Component Impact(s) Commitment UUI CSMF portal: Service

Summary of Impacts for Frankfurt & commitment Component Impact(s) Commitment UUI CSMF portal: Service creation/deletion; Service (de)activation; Service KPI Monitoring NSMF portal: Slice instantiation (manual intervention) China Mobile, Huawei EXT-API* Northbound interface from NSMF to CSMF, Interface from CSMF to northbound systems (OSS, 3 rd party apps), External interface to DCAE DB TBD (check with EXT-API PTL) SO CSMF workflows, NSMF workflows, manual intervention, on-demand slice instantiation Wipro, China Mobile, Huawei enhancements, SO adaptor to connect NSSMF (external & internal) OOF NST selection, NSI selection, NSSI selection AT&T, Wipro, China Mobile, Huawei SDC & Modeling KPI monitoring requirement template, on-demand slice model updates Amdocs, China Mobile SDN-C (R) NSSMF for RAN Wipro VF-C* NSSMF for Core Wipro AAI* Slice and slice sub-net inventory, service mapping to slice, NST, NSST inventory Amdocs, China Mobile, Huawei Runtime DB* RAN (cell-level) inventory for RAN slice sub-nets TBD Policy Config policies for NST, NSI and NSSI selection, ONAP role in optimization Wipro DCAE New KPI Compute MS, VES interface updates, DB for KPI storage and interface for providing info to 3 rd party apps China Mobile, Huawei Simulators RAN-Simulator for RAN, Core VNFs * Code may become part of official ONAP only beyond Frankfurt Wipro: RAN-Simulator, TBD: Core-VNFs

Decisions/points to discuss • Support of all 4 options of CSMF, NSSMF realization •

Decisions/points to discuss • Support of all 4 options of CSMF, NSSMF realization • Realization of NSSMF within ONAP – component and functionality mapping • Interface to 3 rd party NSSMF from ONAP (for Frankfurt, and beyond) • AAI for nested services, and various views (service – slice sub-net, list of slices and slice sub-nets, resource mapping, etc. ) • Runtime DB impacts Note: VF-C, EXT-API, AAI and Runtime DB code impacts may not become part of Frankfurt release, however, it is certainly intended to become part of Guilin release. Intel Confidential

Actions • Present and obtain go-ahead from Arch. Com • Engage with ONAP PTLs

Actions • Present and obtain go-ahead from Arch. Com • Engage with ONAP PTLs who are not yet aware of all details (AAI, EXT-API, VF-C, SDN-C, SDC) • Work on modeling aspects (esp. related to A&AI) • Identify/realize VNF stubs/simulators to be used for the Po. C • Obtain commitment from 3 rd parties for a successful demo (and refine demo scope accordingly)

Stretch Goals • Stretch Goal 1 - Complete realization of Core NSSMF (basic) in

Stretch Goals • Stretch Goal 1 - Complete realization of Core NSSMF (basic) in VF-C • Stretch Goal 2 - Complete implementation of EXT-API functionality with ‘standardized’ APIs • Stretch Goal 3 - Complete implementation in A&AI and Runtime DB • Stretch Goal 4 - 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.

Future Roadmap (Guilin and beyond) • • E 2 E network slice instantiation including

Future Roadmap (Guilin and beyond) • • E 2 E network slice instantiation including transport Full alignment with PNF Pn. P use case Transport slice sub-net realization Alignment with O-RAN for RAN slicing, RAN slice modeling Slice ‘allocation’ (CSMF outside ONAP) 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.

ONAP module mapping for all scenarios 3 GPP Functi on Module (ONAP/3 rd party)

ONAP module mapping for all scenarios 3 GPP Functi on Module (ONAP/3 rd party) Scenario 2 (CSMF outside ONAP) Scenario 3 (CSMF and NSSMF outside ONAP) Scenario 4 (NSSMF outside ONAP) Not applicable Translates service requirements to a slice profile (NST selection) and sends request (to ONAP) for slice ‘allocation’ Not applicable SO • Receives service requirements from EXT-API • Translates service requirements to a slice profile (NST selection) and sends request to NSMF (realized within SO) for slice allocation Not applicable Same as for Scenario 1 SO • Receives request for slice allocation (slice profile, S-NSSAI, NST) • Determines slice instantiation/modification (with OOF) to fulfil the slice allocation request • Determines slice sub-net instantiation/modification (with OOF) to fulfil the slice allocation request • Responsible for e 2 e network slice orchestration (scaling, healing, optimization, modification, monitoring & control loops, etc. ), based on information from NSSMFs, Policy and/or trigger from CSMF • Update inventory (AAI, Runtime DB) and DCAE of NSIs. 3 rd party component CSMF NSMF Scenario 1 (All within ONAP)

ONAP module mapping for all scenarios 3 GPP Module Functi (ONAP/3 rd party) on

ONAP module mapping for all scenarios 3 GPP Module Functi (ONAP/3 rd party) on VF-C NSSM F Scenario 1 (All within ONAP) Scenario 2 (CSMF outside ONAP) Scenario 3 (CSMF and NSSMF outside ONAP) Scenario 4 (NSSMF outside ONAP) • Determines resources to be allocated/modified for core NSSI. • Responsible for orchestration of core slice sub-net (scaling, modification, healing, monitoring & control loops, etc. ). • Update inventory (AAI) and DCAE of core NSSIs. • Determines resources to be allocated/modified for the SDN-C RAN/Transport NSSI. (SDN-R - • Responsible for orchestration of core slice sub-net (scaling, RAN, SDN- modification, healing, monitoring & control loops, etc. ). C • Update inventory (AAI, Runtime DB (in case of RAN)) & DCAE Transport) of RAN/Transport NSSIs. SO 3 rd party compone nt • Receive information from NSMF & trigger RAN/Core/Transport NSSMF for orchestration actions. • Receive information from RAN/Core/Transport NSSMF & update other ONAP modules • Determines resources to be allocated/modified for the RAN/Transport/Core NSSI. • Responsible for orchestration of RAN/Transport/core NSSIs (scaling, , modification, healing, monitoring, etc. ). • Send inventory & FM/PM information for RAN/Transport/core NSSIs. Not applicable

Network Slicing: End-to-end view for Frankfurt Core slice sub-net 2 e. MBB RAN slice

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 BW needed Latency Slice 2 Core slice sub-net 1 VNFs list Link BW Latency Throughput Slice 1 Blue - Leverage functionality implemented in Dublin Realized using m. MTC Simulators 1. Design slice sub-net templates for RAN and core (based on NRM in 3 GPP TS 28. 541). 2. Model transport network template for connecting the RAN to Core Network with Qo. S, bandwidth, resiliency and other parameters as part of the core itself. 3. Design end-to-end slice template (based on NRM in 3 GPP TS 28. 541). 4. Request for services to be instantiated, which results in at least e 2 e slices (at least 2 – e. MBB and m. MTC) to be instantiated each with a RAN and core sub-net. This also includes on-demand service, and KPI monitoring scenarios. 5. RAN and Core will be stubs. 6. A&AI and Runtime DB could be stubs.

3 rd party dependencies • Core NSSMF, APIs from NSSMF to NSMF • Test

3 rd party dependencies • Core NSSMF, APIs from NSSMF to NSMF • Test setup dependencies o Third party NSSMF for core sub-net may be possible only to be made available in CMCC lab. o So Integration Test is proposed to be carried out partly in Windriver/Winlab and CMCC lab. Intel Confidential

s Thank You!

s Thank You!