OOFSON 5 G SelfOrganizing Network SON using ONAP

OOF-SON: 5 G Self-Organizing Network (SON) using ONAP Optimization Framework (OOF): ONAP El Alto/Frankfurt Dec 20 2019 Po. C Collaborators: AT&T, Wipro, IBM, highstreet technologies, Tech. Mahindra, Lumina Networks, Nokia, Reliance Jio, Rutgers Winlab Acknowledgments: Feedback and support from participants in ONAP OOF-PCI team calls Sensitivity: Internal & Restricted

OOF-SON Frankfurt Plans Enhancements towards deployment readiness for ONAP SON • Demonstrate alignment with ORAN interfaces • Netconfig – O 1 -CM interface, Yang model sourced from OIM (ORAN Rel A O-1 v 1. x in Dec) • VES messages (FM, PM, CM) – O-1 interface (ORAN Rel A O-1 v 1. x in Dec) • Demonstrate alignment with Policy Control Loop Co-ordination – e. g. PCI and ANR CL • Role of RIC in OOF-SON for Frankfurt - ? (include abstraction in RAN-Sim? work with RIC implementation? ) • Enhance ONAP modules: • Runtime. DB/Config. DB – Contribute to Config. DB enhancements for OOF-SON – e. g. enhance data model, API spec • Policy/CLAMP/CLC – align with Policy roadmap, CL design, CL co-ordination • RAN Simulator – independent ONAP module in demo repository; also in ORAN • SO/SDC – initial PNF onboarding, initial PCI for new cell, start PCI and/or ANR, SON service design • Integrate with real systems – e. g. SDN-R controlling real g. Node. B/RIC in OWL • Workflow/Life. Cycle of SON § New cell addition, service model (SON functions) • PCI/ANR & SON Enhancements § Optimization features, e. g. incorporate support for ML-based solutions Sensitivity: Internal & Restricted

Requirements • https: //jira. onap. org/browse/REQ-154 Sensitivity: Internal & Restricted 3

ONAP Dublin Po. C: PCI & ANR Optimization using OOF REST API DMaa. P Message (Netconf/Yang) 7 OOF 4 b 6 1 c 8 4 a SON Handler 1 b MS 5 • PCI enhancements • Add ANR function 4 d FM/PM Database 4 c Policy 9 1 a 2 10 12 13 DCAE Collector (VES) 1 e Config. DB 1 d SDN-C* (SDN-R) SDC & CL setup Config Value Change Notifn 3 a 11 Config Value Changes 3 b Simulated RAN • ~2000 Cells • Nbr_list, PCI values FM/PM Data FM/PM KPIs DCAE • FM/PM Collector and Database Sensitivity: Internal & Restricted 4

ONAP Dublin Po. C (redrawn to show DMaa. P role) • CM via VES • Config DB (RCDB) model based on network yang DMaa. P OOF 4 c 9 1 c 8 13 9 10 12 4 a 5 7 4 d FM/PM DB DCAE 13 SDN-R (SDN-C) Policy SON Handler 1 b MS 6 2 1 a 4 a 4 b 4 c 10 12 4 a CDB Simulated RAN • ~2000 Cells • Nbrlist, PCI CM Notifn 3 a 1 d 11 CM Change • Cells/GNBs • RIC • Yang model 1 f CL setup VES Collector 1 e Netconf interface VES 3 c FM/PM KPIs VES outputs • FM/PM Collector and Database Sensitivity: Internal & Restricted 5

ONAP Frankfurt Po. C – aligning with ORAN • CM via VES • Config DB (RCDB) model based on network yang DMaa. P OOF 4 d 9 1 c 8 13 9 10 12 4 c 7 4 f FM/PM DB DCAE 13 6 4 d 2 1 a 1 d 4 b 4 e 4 a 10 12 SDN-R (SDN-C) Policy SON Handler 1 b MS 5 4 a 4 c CL setup 1 e Config Change 11 ORAN O 1 interface RCDB 1 f VES Collector Simulated RAN • ~2000 Cells • Nbrlist, PCI 3 a 3 d CM ORAN O 1 interface FM/PM KPIs O 1 - Netconf interface • Cells/GNBs • RIC • Yang model O 1 - VES outputs • FM/PM Collector and Database Sensitivity: Internal & Restricted 6

CM Updates • OOF-SON Frankfurt approach for Config. DB: - Keep Config. DB small and focused on OOF-SON use case (build towards RCDB in next release) - Focus on config change via VES and data model/schema based on yang model • PM, FM Notifications already go to VES Collector - PM, FM posted on DMaa. P, consumed by SON-Handler MS • CM notifications will go to VES Collector - CM posted on DMaa. P, consume by SDNR - Assume DMaa. P provides reliable delivery • SDNR owns SON CM data in Config. DB (RCDB) - SDNR is only ONAP module which can update SON CM data in Config. DB • CM config by SDNR (e. g. PCI change) - SDNR sends config via netconf, gets success response, SDNR updates Config. DB, and also publishes on DMaa. P to notify SON Handler MS - SDNR needs to handle CM notifn via VES / DMaa. P - • CM config within RAN (e. g. neighbor change) - CM notifn via VES -> DMaa. P - SDNR updates Config. DB, and also publishes on DMaa. P to notify SON Handler MS Sensitivity: Internal & Restricted 7

ORAN Alignment: yang models, VES msg handling • OOF-SON objectives for ORAN alignment: - Ensure that SDNR config actions (step 11) align with ORAN yang models - Ensure that RCDB models/schema and SDNR updates of RCDB (step 4 a, 4 b) are aligned with ORAN yang models - Ensure that PM, FM, CM VES messages are aligned with ORAN O 1 standards - Use model-driven approach for above to adapt to changes in models • Yang model options 1) Use ORAN/3 GPP models for 5 G – final target, licensing issues prevent use of models available to ORAN members 2) Continue to use Dublin OOF-SON yang models (based on BBF/3 GPP) - model-driven solution may need re-working later • ORAN VES message (FM, PM, CM) handling best done by DCAE - CMNotify in VES standard not yet available - DCAE implementation of CM notification via VES deferred to beyond Frankfurt Sensitivity: Internal & Restricted 8

CM Notification options Note: In all options, the schema and API for RCDB will be strongly aligned with yang model (using yang-to-sql ongoing work). Target solution may not be available in Frankfurt. 1. RAN-SIM sends netconf notification for CM. SDNR will update RCDB - Dublin plan, with changes to model to make it model-driven) 2. Use netconf notification format, but send it as a DMaa. P message to SDNR from a test MS. SDNR will update RCDB - Similar to option 1 for processing CM msg and updating RCDB in SDNR, but uses DMaa. P listener and avoids netconf notification implementation in SDNR 3. Use pre-standard/standard CM VES format, and send as DMaa. P message to SDNR from a test MS. SDNR will update RCDB - Gets RAN-SIM aligned to ONAP CM VES. SDNR code will be close to final target if DMaa. P VES message is close to final target 4. Target solution: VES Collector gets CM VES message, and sends DMaa. P message to SDNR Sensitivity: Internal & Restricted 9

OOF-SON Frankfurt: Alternate with VES post-procesing DMaa. P OOF 4 c 9 1 c 8 13 9 10 12 4 b 5 7 4 d FM/PM DB DCAE 4 a 4 b 10 12 13 SDN-R (SDN-C) Policy SON Handler 1 b MS 6 2 1 a CL setup VES Collector 1 e Config Change 11 ORAN O 1 interface RCDB 1 f 4 c 4 a VES Filter ? 1 d 4 a 4 d Simulated RAN • ~2000 Cells • Nbrlist, PCI 3 a 3 c CM ORAN O 1 interface FM/PM KPIs O 1 - Netconf interface • Cells/GNBs • RIC • Yang model VES outputs • FM/PM Collector and Database Sensitivity: Internal & Restricted 10

OOF-SON use case interfaces for ONAP (Frk)/ORAN POC Change NCRT Flag Change PCI VES CM Change NCRT Flag (alt) VES PM Change PCI (alt) VES FM • Possible approaches for implementing ONAP/ORAN use case for OOF-SON for PCI and centralized ANR • ONAP use case has netconfig changes to RAN-Sim: • Change PCI • Change NCRT flag • ONAP use case gets following from RAN-Sim • FM VES, PM VES • CM netconf notifn • Can change to include CM VES, but need convergence on VES format for CM • RAN-Sim currently has netconf and VES format RAN-Sim function (? ) Sensitivity: Internal & Restricted 11

SDN-R Jira items Closed (El Alto) • • CCSDK-1364: DMAAP Listener bug fixes SDNC-772: DMAAP listener CCSDK-1544: Configuration updates in SDNR OOFPCIPOC DG/templates CCSDK-1560 CCSDK-1564 CCSDK-1565 SDNC-433 "Receive netconf notification from RAN, update config. DB, and publish change on DMaa. P" - The code was merged; however, not included in the oofpcipoc karaf feature. Need to identify root cause of the docker stability issues • CCSDK-1397 - support for config. DB update and DMAAP message publishing to SON MS Open (Target: El Alto) • CCSDK-1400: "DMAAP Listener - System Environment variable: DMAAPLISTENERROOT: still open" Did the work-around in a docker for a demo • SDNC-725 "Interfacing SDN-R with Policy - Part 2" (will create CCSDK Jira items, as this is CCSDK code base) • Config. DB Update in the forward path (DMAAP from Policy to SDNR) • SDNR sends ACK back to Policy after steps 10/11 Sensitivity: Internal & Restricted 12

Open items (for Frankfurt) • SDNC-431: Config. DB Integration in the CCSDK code base • Alignment and integration of ORAN YANG models into CCSDK/SDNC code base, including any required updates to provider, DG, and DMAAP listener code base • SDNC-433: "Receive netconf notification from RAN, update config. DB, and publish change on DMaa. P" - The code was merged; however, not included in the oofpcipoc karaf feature. Need to identify root cause of the docker stability issues • CCSDK-1033: Support for NETCONF Notifications in CCSDK/SDNC Sensitivity: Internal & Restricted 13

Links for More Information Description Link OOF-PCI Main Wiki Page https: //wiki. onap. org/display/DW/5 G++OOF+%28 ONAP+Optimization+Framework%29+and+PCI+%28 Physical+C ell+ID%29+Optimization OOF-PCI Dublin Release (Requirements and Test Cases) https: //wiki. onap. org/display/DW/OOF-PCI+Use+Case+-+Dublin+Release+ -+ONAP+based+SON+for+PCI+and+ANR (See the child wiki pages for functional & implementation details) OOF-PCI Dublin Release Plan 5 G - OOF and PCI (Casablanca carry-over items) OOF SON in R 5 El Alto and R 6 Frankfurt https: //wiki. onap. org/display/DW/PCI+%28 SON%29+in+R 5+El+Alto%2 C+P CI+%28 SON%29+in+R 6+Frankfurt SON-Handler MS Demo video recording https: //wiki. onap. org/download/attachments/53249727/DCAE_Weekly_0 4252019_Demo. Session 1. mp 4? version=1&modification. Date=1556202975000&api=v 2 (Latter part) OOF-PCI Dublin Po. C Demo video recording https: //wiki. onap. org/download/attachments/68539437/zoom_0. mp 4? ve rsion=2&modification. Date=1563985740000&api=v 2 Sensitivity: Internal & Restricted 14

s Thank You! Sensitivity: Internal & Restricted

OOF-SON El Alto/Frankfurt Plans El Alto (Maintenance Release) • • SDN-R/CC-SDK JIRA items: Complete carryover work and merge into El Alto/Frankfurt SON-Handler MS: Handle non-functional updates (e. g. , periodic config updates from Consul, container image minimization) Frankfurt – More enhancements towards deployment readiness for ONAP SON • • Include other ONAP modules: A&AI, SO, SDC, CLAMP Alignment with ORAN/3 GPP common model for SDN-R Integrate with real systems – e. g. SDN-R controlling real g. Node. B Demonstrate alignment with Policy Control Loop Co-ordination Establish Config. DB role in ONAP – align with A&AI and any new models RANSim part of Frankfurt – align with PNF Plug & Play, register with A&AI and SO PCI/ANR & SON Enhancements § New cell addition, optimization features § Incorporate support for ML-based solutions § Additional SON functions Sensitivity: Internal & Restricted

El Alto Carry Over Items ONAP -> RAN config change: • SDN-R processes msg from Policy – El Alto • sends config change to RAN-Sim – EL Alto • gets ack from RAN-Sim – El Alto • SDN-R updates Config. DB - El Alto • SDN-R sends ack to Policy - El Alto RAN -> ONAP config change notification • SDN-R receives netconf notification – El Alto/Frankfurt • SDN-R updates Config. DB – done, need above notifn feature to test • SDN-R sends DMaa. P msg for config change - done, need notifn to test Sensitivity: Internal & Restricted 17