Sensitivity Internal Restricted OOFSON 5 G SelfOrganizing Network

  • Slides: 20
Download presentation
Sensitivity: Internal & Restricted

Sensitivity: Internal & Restricted

OOF-SON: 5 G Self-Organizing Network (SON) using ONAP Optimization Framework (OOF) Collaborators: AT&T, Wipro,

OOF-SON: 5 G Self-Organizing Network (SON) using ONAP Optimization Framework (OOF) Collaborators: AT&T, Wipro, IBM, highstreet technologies, Tech. Mahindra, Nokia, Reliance Jio, Rutgers Winlab, Ericsson, Verizon Acknowledgements: Feedback and support from participants in ONAP OOF-SON team calls Presenters: N. K. Shankaranayaranan (AT&T), Swaminathan S (Wipro) October 15, 2020 Sensitivity: Internal & Restricted

ONAP-based SON Optimization (OOF) Co-ordination, Decisions • SON Control Loop (CL) (Policy) • ONAP:

ONAP-based SON Optimization (OOF) Co-ordination, Decisions • SON Control Loop (CL) (Policy) • ONAP: Open-source platform, with basic open-source code • Companies can use framework to add proprietary SON solutions, including optimization algorithms, etc. Data Collection, & Analysis (DCAE) Control loop Action (SDN-R) • OOF-PCI Casablanca - First ONAP SON PCI use case - Po. C Demo in Dec 2018 • OOF-SON Dublin Data, FM, PM Config status - Added SON function: ANR - More SON data flows: FM, PM - New SON-Handler MS in DCAE 5 G/4 G Radio Network Sensitivity: Internal & Restricted 3

ONAP-based SON & O-RAN interfaces Optimization (OOF) Co-ordination, Decisions (Policy) • Radio network uses

ONAP-based SON & O-RAN interfaces Optimization (OOF) Co-ordination, Decisions (Policy) • Radio network uses common netconf/yang model Data Collection, & Analysis (DCAE) Control loop Data flows: Action (SDN-R) • SDN-R to RAN: netconf-based configuration RIC (non-RT) Data, FM, PM A-1/O-1 Config notify • OOF-SON use case has built a foundation for ONAP/O-RAN integration A-1/O-1 RIC (near RT) O-RAN Radio Network • RAN to DCAE: VES format for FM alarms, PM KPI, CM Notifn Config ack Sensitivity: Internal & Restricted • RAN to SDN-R: Netconf ack

SON use case: Roadmap R 6 Frankfurt • CM-Notify handling • Control Loop Coordination

SON use case: Roadmap R 6 Frankfurt • CM-Notify handling • Control Loop Coordination (CLC) first steps • Introduced Adaptive SON functionality • Checked in RANSim into ONAP repo R 7 Guilin • ML-based SON – first steps (training done offline), additional input from ML-model for PCI optimization (based on PM data) • Preparation work for 3 GPP/O-RAN yang model R 8 Honolulu R 9 Istanbul & beyond • O-RAN alignment (O 1 for configuration and CM notification) • C&PS - RAN config data base (first steps), cell models, initial alignment with 3 GPP NRM • SON coordination (preparation/initial steps) • CLC interaction (stretch) • O-RAN alignment (FM/PM over O 1) • C&PS – Full-fledged RAN data base, full alignment with 3 GPP NRM • Control Loop Coordination, SON function co-ordination • New SON use cases & interaction with Network Slicing • SON in context of LCM, SON function deployment Sensitivity: Internal & Restricted

Honolulu Requirement Summary Category Requirement Content Priority Interoperability O-RAN alignment (VES, O 1 interface)

Honolulu Requirement Summary Category Requirement Content Priority Interoperability O-RAN alignment (VES, O 1 interface) 1. Receive Configuration Management (CM) notifications over VES 2. Align with relevant aspects of O-RAN O 1 interface (netconfiguration, PM and FM notifications) HIGH Functional RAN Database (C&PS DB), including new RAN models 1. Data models/DB schema & APIs to be generated from yang models 2. Details of cells to be stored with PNF reference in AAI 3. Modeling of RAN functions and objects (align with NRM) HIGH Platform Control Loop Coordination (CLC) extensions Collaborate on CLC extensions (queueing, priority, …) (stretch goal) HIGH Functional SON co-ordination Co-ordination across SON functions – initial steps Functional SON function to evolve ONAP platform 1. 2. 3. 4. Functional SON in the context of LCM Role of SO (e. g. , new cell discovery/addition) (beyond H-release) LOW Platform SON function deployment SDC & CLAMP (for SON service/feature deployment) (beyond H-release) LOW Interoperability Real g. NB interaction Interaction with real g. Node. B in lab (over O 1 interface) LOW (New) SON use case based on data/KPI analysis Machine Learning (ML) SON aspects in DCAE (extension) Interaction with Network Slicing (stretch goal) CLC interaction (stretch goal) Sensitivity: Internal & Restricted MEDIUM

ONAP SON aligning with O-RAN: Release 7 POC • Network yang model update based

ONAP SON aligning with O-RAN: Release 7 POC • Network yang model update based on 3 GPP/O-RAN (to prepare for Rel. 8) • CM notification msg – Rel 6 “pre-standard” msg • Config DB (RCDB) Rel 6 DMaa. P OOF 4 d 1 c ML-based 8 5 9 13 Offline-training for ML-based SON function DES MS DCAE n Interface enhancements REST API 4 f FM/PM DB 4 a 4 c 13 2 6 1 a Config. DB 1 f O 1 - Netconf interface • Cells/GNBs • RIC • Yang model CM 3 d • FM/PM Collector and Database 11 [3 a] 4 a CL setup 1 e Config Change O-RAN O 1 interface VES Collector O-RAN O 1 interface FM/PM KPIs O 1 - VES outputs Note: DES MS is a new MS introduced in Release 7. m New interface DMaa. P Control Loop messages 1 d 4 b 4 e 4 d 10 12 SDN-R (SDN-C) Policy SON Handler 1 b MS 7 a 7 b 9 10 12 4 c Simulated RAN • ~2000 Cells • Nbrlist, PCI CM-FM-PM messages from RAN Sensitivity: Internal & Restricted Config updated to RAN (netconf) 7

ONAP SON aligning with O-RAN: Release 8 Target • CM via VES collector •

ONAP SON aligning with O-RAN: Release 8 Target • CM via VES collector • C&PS DB model based on O-RAN network yang model DMaa. P OOF 4 d ML-based 8 1 c 5 9 13 9 10 12 4 c Policy SON Handler 1 b MS 2 6 7 a 7 b Offline-training for ML-based SON function DES MS DCAE 4 f FM/PM DB 13 4 d 4 a 4 b 1 a 4 e 4 a 4 a 4 c 10 12 SDN-R (SDN-C) 1 d CL setup 1 e 3 a 3 d • FM/PM Collector and Database Config Change 11 O-RAN O 1 interface C&PS 1 f DB VES Collector Simulated RAN • ~2000 Cells • Nbrlist, PCI CM O-RAN O 1 interface FM/PM KPIs O 1 - Netconf interface • Cells/GNBs • RIC • Yang model O 1 - VES outputs n Interface enhancements REST API DMaa. P Control Loop messages CM-FM-PM messages from RAN Sensitivity: Internal & Restricted Config updated to RAN (netconf) 8

Rel 8 OOF-SON dependency on ONAP C&PS and O-RAN • OOF-SON use case created

Rel 8 OOF-SON dependency on ONAP C&PS and O-RAN • OOF-SON use case created Config. DB in Rel 5/Rel 6/Rel 7 which was the seed for C&PS • OOF-SON has a strong dependency on, and is an early adopter of, working instance of C&PS • REQ: Identify/support RAN yang model aligned with O-RAN/3 GPP – can be a very small subgraph for Rel. 8. SON use case with cellid, pci, neighbor cell relation • REQ: Support database API similar to existing Rel. 7 Config. DB API - For “quick POC” solution, limit impact on existing modules which are using the Rel 7 API for Config. DB Dependency Mitigation Availability of O-RAN yang models. Use 3 GPP TS 28. 541 NRM based attribute definitions and yang from https: //forge. etsi. org/rep/3 GPP/SA 5/datamodels/tree/master/yang-models. Availability of CM_Notify VES Spec, and confirmation that VES Collector will be updated to receive this. Continue to use custom-defined CM_Notify, however, there will be no additional value for Guilin release. Support of VES message (CM_Notify) processing by C&PS. SDN-C (R) will process the VES CM_Notify message and update C&PS. Action: Clarify by M 1 on C&PS functionality. Sensitivity: Internal & Restricted

Yang model needed for OOF-SON R 8 • For Rel 5/6/7, OOF-SON used a

Yang model needed for OOF-SON R 8 • For Rel 5/6/7, OOF-SON used a sub-tree from Broadband Forum RAN model based on 3 GPP - We have been preparing for, and advocating for, a common O-RAN/3 GPP network model • For Rel 8 of OOF-SON, we need to identify a suitable sub-tree of a standard 5 G RAN yang model and include the minimal set below (O-RAN if available, else from 3 GPP TS 28. 541 Rel. 16): • Basic ids for GNB and cell: g. NBDUId, n. CI etc • PCI property: n. RPCI • Neighbor Relations – for PCI and ANR functions Note: The initial yang models based on 3 GPP TS 28. 541 NRM have already been defined for Network Slicing use case. These should be aligned and enhanced suitably for SON use case in Rel. 8. Sensitivity: Internal & Restricted

YANG Model Tree Used for Rel. 5/6/7 OOF PCI/ANR POC 1 • The platform

YANG Model Tree Used for Rel. 5/6/7 OOF PCI/ANR POC 1 • The platform ready to support any YANG Model Number & List of Cells PCI and PNF-NAME for a Cell List of Neighbors RPC Netconf Notification 1 https: //gerrit. onap. org/r/gitweb? p=ccsdk/features. git; a=tree; f=sdnr/northbound/oofpcipoc/model/src/main/yang; h=5 b 3 ef 2 c 03 cf 516 ba 716 f 69076 a 780 a 95 e 96 fadc 2; hb=refs/heads/dublin Sensitivity: Internal & Restricted

3 GPP Network Resource Models Figure 4. 2. 1. 1 -1: NRM for all

3 GPP Network Resource Models Figure 4. 2. 1. 1 -1: NRM for all deployment scenarios Figure 4. 2. 1. 1 -3: NRM for <<IOC>>NRSector. Carrier and <<IOC>>BWP for all deployment scenarios Reference: 3 GPP NRM TS 28. 541 Rel. 16 (v 16. 5. 0) Figure 4. 2. 1. 1 -4: Cell Relation view for all deployment scenarios Sensitivity: Internal & Restricted

Network yang models & ONAP DB models/API – Rel 6 & 7 DMaa. P

Network yang models & ONAP DB models/API – Rel 6 & 7 DMaa. P Read network configuration • SON-H MS • OOF 4 a DB-Update 4 e 7 Config 1 f DB Database • Schema • API “PCI” value: ONAP Rel 4 implementation Cell. pci. Value 10 12 4 c SDN-R (SDN-C) 4 b 1 d Model Mapping Netconf Configuration Config Change 11 O-RAN O 1 CM interface 4 a VES 1 e Collector 3 a O-RAN O 1 interface CM Notification Sensitivity: Internal & Restricted Simulated RAN • ~2000 Cells • Nbrlist, PCI O 1 - Netconf interface • Cells/GNBs • RIC • Yang model O 1 - VES outputs “Data model” used at interfaces: Config. DB RAN Network Yang Model “PCI” value: BBF Yang model lte-ran-rf-g/ phy-cell-id

Network yang models & ONAP DB models/API – Rel 8 (proposed) DMaa. P Read

Network yang models & ONAP DB models/API – Rel 8 (proposed) DMaa. P Read network configuration • SON-H MS • OOF 4 c 4 e 7 4 b DB-Update C&PS 1 f DB 10 12 SDN-R (SDN-C) 11 a Model Mapping Database • Schema • API “PCI” value: ONAP Rel 8 implementation NRCell. DU/n. RPCI 1 d Netconf Configuration Config Change 11 b O-RAN O 1 CM interface 4 a VES 1 e Collector 3 a O-RAN O 1 interface CM Notification Sensitivity: Internal & Restricted Simulated RAN • ~2000 Cells • Nbrlist, PCI O 1 - Netconf interface • Cells/GNBs • RIC • Yang model O 1 - VES outputs “Data model” used at interfaces: C&PS DB RAN Network Yang Model “PCI” value: (O-RAN or 3 GPP Yang model) NRCell. DU/n. RPCI

Config DB Data Model and APIs • Config DB (Maria. DB) used by PCI-H-MS

Config DB Data Model and APIs • Config DB (Maria. DB) used by PCI-H-MS (step 4 b) and OOF (step 7) • Query API (swagger JSON spec) exposed to other ONAP modules • cell. Id needs to be globally unique (assumed e. CGI) and align with ONAP YANG model, O-RAN, 3 GPP • pnf-name/pnf-id indicates netconf server to be used for interactions regarding cells • ‘ho’ property added to support ANR use case Cell (Object) Cell_Nbr_Info (Object) Attribute Format network. Id string cell. Id String cell. Id string target_cell_id String pci. Value uint 64 ho BIT(1) nbr. List list of cell. Id last. Modified. TS timestamp pnf-id string Sensitivity: Internal & Restricted

ML-based SON functions • Consensus from DCAE and OOF is that ML training should

ML-based SON functions • Consensus from DCAE and OOF is that ML training should be done outside the ONAP control loop – use “offline training” • SON function applying an ML model is incorporated in OOF in R 7. This provides additional input on cells whose PCI values should be fixed during PCI optimization (based on handover PM data). • Since it is a SON use case, possible later extensions could include: - Consider Policy-based decision to pick from multiple models - Influence of other SON functions (e. g. , ANR influence on PCI) in the optimization - Etc. • We have an offline-trained SON model hosted in OOF in R 7. Further enhancements to be explored in R 8. Sensitivity: Internal & Restricted

Control Loop Coordination (CLC) enhancements (stretch goal) • Interaction between Target lock and CLC

Control Loop Coordination (CLC) enhancements (stretch goal) • Interaction between Target lock and CLC • Definition of target – PNF, VNF, cell, service, NSI, etc. • Queueing/de-queuing of CL messages by CLC logic • Separate DMaa. P topic for each CL response (e. g. , DCAE-CL-RSP) We are working with Policy Team to address these enhancements. All consequent updates in SON-Handler MS and SDN-C will be handled by our SON use case team. Sensitivity: Internal & Restricted

SON coordination • CLC in Policy is currently designed to co-ordinate actions AFTER individual

SON coordination • CLC in Policy is currently designed to co-ordinate actions AFTER individual micro-services (components) have decided to take an action and trigger Policy. • SON co-ordination involves the impact of one SON function on another before or during the determination of action (e. g. , optimization) - For example, when a cell outage is being compensated, coverage and capacity optimization should be deferred or should take cell outage into consideration. • SON co-ordination could be viewed as a platform enhancement => Policy and/or SO shall do the co-ordination. Sensitivity: Internal & Restricted

Links • OOF SON Guilin release use case wik: https: //wiki. onap. org/display/DW/R 7+OOF+SON+Use+Case

Links • OOF SON Guilin release use case wik: https: //wiki. onap. org/display/DW/R 7+OOF+SON+Use+Case • OOF SON Frankfurt release use case wiki: https: //wiki. onap. org/display/DW/OOF+%28 SON%29+in+R 5+El+Alto%2 C+OOF+%28 SO N%29+in+R 6+Frankfurt • OOF SON base wiki page: https: //wiki. onap. org/display/DW/5 G++OOF+%28 ONAP+Optimization+Framework%29+and+PCI+%28 Physical+Cell+ID%29+O ptimization Sensitivity: Internal & Restricted

Thank You Sensitivity: Internal & Restricted

Thank You Sensitivity: Internal & Restricted