Network Slicing Joint Proposal and Management Functions Overview

Explore the joint proposal for ONAP network slicing in Frankfurt, detailing the involvement of prominent industry players and the scoping of use cases for NSI lifecycle view. The document outlines the key tasks of 3GPP slice management functions and the network slice lifecycle specific to Frankfurt, including management function views, portal workflows, and support interfaces within ONAP.

• Network Slicing
• ONAP Proposal
• Management Functions
• 3GPP
• Scoping

hamza Follow

Uploaded on Jul 31, 2024 | 0 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

Presentation Transcript

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

2. Network Slicing: 3GPP Context Ref.: 3GPP TS 28.530 Intel Confidential

3. Scoping Use case proposal - NSI Life Cycle view (Frankfurt) Objective: Demonstrate e2e slice design and instantiation, including RAN & core slice sub-net design and instantiation. Ref.: 3GPP 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 3GPP TS 23.501, if we don t realize the traffic flow part in the demo.

4. 3GPP Slice Management Functions Management Function Key tasks Remarks 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). 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. We propose that all actions except NSSI selection or instantiation decision is taken within ONAP (OOF guided).

5. Network Slice Lifecycle for Frankfurt: 3GPP Management Function View CSMF Portal & workflows 1. 5G 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* CSMF 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 NSMF NSSMF within ONAP Support basic RAN & core NSSMF functionality 3rd party NSSMF Interface between ONAP and 3rdparty core network NSSMF SO Adaptor will be developed to connect NSSMF both internal & external), SDN-C (R), VF-C*, A&AI*, Runtime DB* NSSMF 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

6. Additional Frankfurt Scope: 5G Service KPI monitoring Service Provider UUI/Portal NSMF Portal (Management Portal) CSMF Portal (Tenant Portal) 3.1 3.1 Tenant 1. SDC distributes KPI template to Compute MS in DCAE 3.2 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 Policy KPI Config Policy Compute MS NST Model (Including KPI Monitoring ) 3.1 Tenant /Operator monitors PM KPI 3.2 Operator searches PM KPI from DCAE DB (historic data can also be visualized in DB) 1 DB (historic and current KPI) 2.3 2.2 5G KPI Collector (VES / REST ) NSST Model DCAE Impacts DCAE New KPI Compute MS, VES Collector, (new) DB SDC Slice template enhancements Policy Config policies EXT-API External interface 2.1 SDC ONAP Onboard Enhancement 3rdParty CN NSSMF New for this use case NSST Model

7. Frankfurt Scope: Summary: CSMF within ONAP; NSMF 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 3rd party - KPI monitoring template - New microservice for KPI computation, DB for storing KPI info Note: 1. For Frankfurt, the E2E 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.

8. Proposed Demo Setup for Frankfurt ONAP CSMF Portal NSMF Portal UUI 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) EXT-API SDC SO (CSMF + NSMF) A&AI OOF Policy SDN-C (R) RAN NSSMF VF-C Core NSSMF*** Runtime DB DCAE Core NSSMF (3rd party) RAN (Simulated) Core (Simulated)

9. Proposed Demo Highlights Sequence 1 (Service instantiation) Sequence 2 (Service activation) Sequence 3 (KPI Monitoring) Activate a Service (CSMF Portal) (time range) Instantiate & activate a Service (CSMF Portal) with KPI monitoring Instantiate a Service (CSMF Portal) Service profile mapping, NST determination Determine NSI binding Show data collection actions by new DCAE MS NSMF flows triggered (NSI, NSSI instantiation) Activate NSI 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 Display KPI info Update inventory, status, etc. Note: Offline inputs/guidance may be provided for NST selection, NSI and NSSI allocation. Intel Confidential

10. 3GPP Slice Management Functions Roles and mapping to ONAP Scenario 1: CSMF, NSMF and NSSMF are all within ONAP 3GPP defined Management Functions Mapping to 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 Communication Service Management Function (CSMF) UUI EXT-API Network Slice Management Function (NSMF) SO Transport NSSMF Adaptor RAN NSSMF Adaptor Core NSSMF Adaptor OOF Network Slice Subnet Management Function (NSSMF) SDN-C(R) (RAN) VF-C (Core) SDN-C (Transport) ONAP

11. 3GPP Slice Management Functions Roles and mapping to ONAP Scenario 2: CSMF is outside ONAP, NSMF and NSSMF are within ONAP 3GPP defined Management Functions Communication Service Management Function (CSMF) Mapping to 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 3rd party system (e.g., OSS or an application) EXT-API Network Slice Management Function (NSMF) SO Transport NSSMF Adaptor RAN NSSMF Adaptor Core NSSMF Adaptor OOF Network Slice Subnet Management Function (NSSMF) SDN-C(R) (RAN) SDN-C (Transport) VF-C (Core) ONAP

12. 3GPP Slice Management Functions Roles and mapping to 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 Scenario 3: CSMF and NSSMF are outside ONAP, NSMF is within ONAP 3GPP defined Management Functions Communication Service Management Function (CSMF) Mapping to ONAP 3rd party system (e.g., OSS or an application) EXT-API Network Slice Management Function (NSMF) SO OOF Transport NSSMF Adaptor RAN NSSMF Adaptor Core NSSMF Adaptor ONAP Network Slice Subnet Management Function (NSSMF) Core NSSMF Transport NSSMF RAN NSSMF

13. 3GPP Slice Management Functions Roles and mapping to 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. Scenario 4: CSMF and NSMF are within ONAP, NSSMF is outside ONAP 3GPP defined Management Functions Communication Service Management Function (CSMF) Mapping to ONAP UUI EXT-API Network Slice Management Function (NSMF) OOF SO Transport NSSMF Adaptor ONAP Adaptor RAN NSSMF Adaptor Core NSSMF Network Slice Subnet Management Function (NSSMF) Transport NSSMF Core NSSMF RAN NSSMF

14. 3GPP Slice Management Functions Roles and mapping to ONAP: Summary Scenario CSMF NSMF NSSMF* 1 ONAP ONAP ONAP Note: Hybrid NSSMF mapping is also possible, i.e., some NSSMFs within ONAP and some outside ONAP. 3rd party 2 ONAP ONAP 3rd party 3rd party 3 ONAP 3rd party 4 ONAP 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) Standardized APIs on northbound between NSMF <-> CSMF (b) Standardized APIs on southbound between NSMF <-> NSSMF (c) Functional alignment of NSSMF to be kept uniform for all scenarios (see later slides) (d) 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.

15. NSSMF - remarks 3GPP 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

16. 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 3rd 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 3rd party Core NSSMF will be realized in SO itself.

17. Impact overview: Frankfurt U-UI NSMF Portal CSMF Portal A&AI ONAP Service instance EXT-API CSMF and NSMF interfaces*** (Config) policies for OOF Optimization Service Profile SO Service Profile Selection NST Selection SDC OOF NST Policy CSMF WF NSI NST (with E2E KPI Monitoring ) (enhanced) CSMF Policy NSST NSMF WF NSI Selection NSSISelection Slice Profile NSMF Policy NSSI NSSMF Adaptor NSST (enhanced) CSMF Functions Service create/delete; Service activate/deactivate KPI monitoring Runtime DB RAN NSSMF data KPI DB DCAE SDN-C (SDN-R) VF-C*** E2E KPI MS (new) Core NSSMF RAN NSSMF NSMF Functions Slice instantiate/delete; slice activate/deactivate KPI monitoring; Manual inputs and adjustment CN NSSMF (3rd 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

18. 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, 3rd party apps), External interface to DCAE DB TBD (check with EXT-API PTL) SO CSMF workflows, NSMF workflows, manual intervention, on-demand slice instantiation enhancements, SO adaptor to connect NSSMF (external & internal) Wipro, China Mobile, Huawei 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 3rd party apps China Mobile, Huawei Simulators RAN-Simulator for RAN, Core VNFs Wipro: RAN-Simulator, TBD: Core-VNFs * Code may become part of official ONAP only beyond Frankfurt

19. Decisions/points to discuss Support of all 4 options of CSMF, NSMF, NSSMF realization Realization of NSSMF within ONAP component and functionality mapping Interface to 3rd party NSSMF from ONAP (for Frankfurt, and beyond) AAI for nested services, and various views (service slice 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

20. Actions Present and obtain go-ahead from ArchCom 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 PoC Obtain commitment from 3rd parties for a successful demo (and refine demo scope accordingly)

21. 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., e2e flow of video traffic via an eMBB slice - Interface to NSSF. - Impacts: Simulators, NSSF stub, Interface API to NSSF, traffic flow tool & setup.

22. Future Roadmap (Guilin and beyond) E2E network slice instantiation including transport Full alignment with PNF PnP 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 5G-Core Advance use cases covering URLLC, slice security & isolation, etc.

23. ONAP module mapping for all scenarios 3GPP Functi on Module (ONAP/3rd party) Scenario 1 (All within ONAP) Scenario 2 (CSMF outside ONAP) Scenario 3 (CSMF and NSSMF outside ONAP) Scenario 4 (NSSMF outside ONAP) Translates service requirements to a slice profile (NST selection) and sends request (to ONAP) for slice allocation 3rd party component Not applicable Not applicable 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 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 e2e 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. CSMF SO Not applicable Same as for Scenario 1 NSMF SO

24. ONAP module mapping for all scenarios 3GPP Functi on Module (ONAP/3r d party) 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. VF-C Determines resources to be allocated/modified for the RAN/Transport NSSI. Responsible for orchestration of core slice sub-net (scaling, modification, healing, monitoring & control loops, etc.). Update inventory (AAI, Runtime DB (in case of RAN)) & DCAE of RAN/Transport NSSIs. SDN-C (SDN-R - RAN, SDN-C - Transport) NSSM F Receive information from NSMF & trigger RAN/Core/Transport NSSMF for orchestration actions. Receive information from RAN/Core/Transport NSSMF & update other ONAP modules Receive information from NSMF & trigger RAN/Core/Transport NSSMF for orchestration actions. SO 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. 3rd party compone nt Not applicable

25. Network Slicing: End-to-end view for Frankfurt Core slice sub-net 2 Slice 2 RAN slice sub-net 2 RAN slice sub-net 1 eMBB Core slice sub-net 1 Slice 1 VNFs list Link BW BW needed Latency Blue - Leverage functionality implemented in Dublin Latency Throughput Realized using Simulators mMTC 1. Design slice sub-net templates for RAN and core (based on NRM in 3GPP TS 28.541). 2. Model transport network template for connecting the RAN to Core Network with QoS, bandwidth, resiliency and other parameters as part of the core itself. 3. Design end-to-end slice template (based on NRM in 3GPP TS 28.541). 4. Request for services to be instantiated, which results in at least e2e slices (at least 2 eMBB and mMTC) 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.

26. 3rd 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

27. s Thank You!