OOF-PCI Use Case - Dublin Release - ONAP based SON for PCI and ANR



@N.K. Shankaranarayanan@Swaminathan Seetharaman5G - OOF (ONAP Optimization Framework) and PCI (Physical Cell ID) Optimization



Showcase VNF

Test Environment

Integration Team Liaison

Showcase VNF

Test Environment

Integration Team Liaison



Rutgers Winlab ONAP Wireless Lab: Use case testing, use case PoC demo setup, Minor part of Integration Testing

Windriver Lab: Major part of Integration Testing

@krishna moorthy









Component/Activity

Responsible(s)

Component/Activity

Responsible(s)

Overall Point of Contact,

Use case scope and content

@N.K. Shankaranarayanan (AT&T), @Swaminathan Seetharaman (Wipro)

ConfigDB

@Sandeep Shah, @Devendra Chauhan

DCAE

@ramya ravichandran, @Reshmasree c

OOF

@Vikas Varma, @Avteet Chayal , @Shankaranarayanan Puzhavakath Narayanan

Policy

@mehreen kaleem, @Saravanan Ayyadurai

SDN-R

@Sandeep Shah

RAN-Simulator

@Saravanan Ayyadurai

Winlab Setup

@George Clapp

E2E Use case/demo setup/config

@krishna moorthy, @George Clapp

Integration Testing

@krishna moorthy



Step

Functionality

Step

Functionality

1a-1e

All modules loaded to support CL (manual set up)

2

SON-Handler MS* fetches configuration policies from Policy

3a

Config change notification from RAN to SDN-C (e.g. Neighbor List change)

3b

FM/PM data sent from RAN (PNFs) to VES Collector

4a

SDN-C publishes config data change on DMaaP to SON-Handler-MS. SDN-C also updates Config DB.

4b

SON-Handler MS reads relevant info from ConfigDB

4c

SON-Handler MS receives FM/PM trigger (e.g. PCI Confusion alarm)

4d

SON-Handler MS writes/reads FM/PM database

5

SON-Handler MS invokes OOF for PCI / ANR Optimization

6

OOF gets PCI / ANR optimization policies from Policy

7

OOF queries ConfigDB database to fetch data for cells in the region

8

OOF provides PCI / ANR Optimization result to SON Handler MS

9

SON-Handler-MS provides PCI / ANR recommendation to Policy

10

Policy sends instruction for configuration changes to SDN-C

11

SDN-C applies config changes in RAN via Netconf and also updates Config DB.

12

SDN-C sends an acknowledge to Policy after applying config change in RAN

13

Policy sends an acknowledge to SON-Handler MS upon receiving an acknowledge from SDN-C



Blue - New/updated step for ONAP Dublin.



Trigger for PCI optimization

  1. Neighbor list change notification from RAN with PCI confusion and/or collision (Step 4a). The minimum number of collisions/confusions to trigger optimization are configurable in SON-Handler MS.

  2. FM alarms for PCI confusion and/or collision from RAN (Step 4c with FM data). The minimum number of collisions/confusions to trigger optimization are configurable in SON-Handler MS.

Trigger for Centralized ANR updates

PM data with Handover success rate (PM KPI) is reported by RAN (Step 4c with PM data), and Handover success rate is consistently below HO_bad threshold (e.g., 25%). HO_bad threshold value and the number of consecutive values (reported after each successive observation time window) of Handover success rate that should be checked for consistency are configurable (in SON-Handler MS).

Trigger for Joint PCI-ANR optimization

When PCI optimization is being triggered 'too often', i.e., > threshold_number within a given time window (say, 30 mins), then joint PCI-ANR optimization is triggered. Reason: Such frequent triggering is seen as an indication of difficulty in achieving convergence of PCI values. When triggering joint PCI-ANR optimization, details of the cell-pairs for which the Handover success rate (PM KPI) is consistently below HO_poor threshold (e.g., 50%) (but greater than HO_bad threshold) are also provided as input as "removable neighbors". HO_poor threshold value and the number of consecutive values (reported after each successive observation time window) of Handover success rate that should be checked for consistency are configurable (in SON-Handler MS).



Development Status & High-Level Requirements

Project

PTL

JIRA Epic / User Story*

Requirements

Project

PTL

JIRA Epic / User Story*

Requirements

AAI

@James Forsyth



  1. No impact. ConfigDB objects for pnf shall be aligned with with A&AI (e.g. use the same primary key for pnf, which is expecte to be pnf-id)

DCAE

@Vijay Kumar

  • Epic: DCAEGEN2-1108: DCAE Support for OOF-PCI solution

  • US DCAEGEN2-1109: Onboard SON Handler microservice to DCAE

  • US DCAEGEN2-1110: VES Collector for FM/PM data from RAN-SIM PNFs

  • US DCAEGEN2-1111: FM/PM Database for SON solution

  • US DCAEGEN2-1116: Preparation steps for onboarding of SON Handler MS

  • US DCAEGEN2-1219: Seed code check-in of SON Handler MS



  1. SON Handler Microservice shall be onboarded onto DCAE (DCAEGEN2-1109)

  2. A VES Collector shall accept FM/PM VES messages from RAN Simulator and publish to DMaaP - DCAEGEN2-1110

  3. SON Handler microservice shall filter for specific alarms (e.g. PCI Confusion) and trigger OOF Optimization as needed - DCAEGEN2-1109

  4. Implement PostgreSQL database to store FM/PM data and any other data needed by the SON Handler Microservice. This database provide a query interface so that the SON Handler MS can read and write data. - DCAEGEN2-1111

  5. The SON Handler microservice shall filter specific FM/PM messages published by the VES Collector and write to the FM/PM database. DCAEGEN2-1109

  6. The SON Handler MS interfaces to Policy, OOF, SDN-C, ConfigDB shall be modified as needed by DCAE onboarding. e.g. MS shall receive configuration policy via DCAE Controller - DCAEGEN2-1109

  7. Microservice shall support centralized ANR SON functionality to modify neighbor cell relations based on handover KPIs. DCAEGEN2-1109

 OOF

@Shankaranarayanan Puzhavakath Narayanan

  1. US - OPTFRA-416



  1. OOF PCI Solver and interface shall support at least two optimization objectives (e.g. minimize changes, minimize PCI confusion)

  2. OOF PCI Solver policy shall use a PCI range specified in the configuration policy

  3. OOF shall provide a joint PCI/ANR solver which will optimize PCI and also recommend a removal of a neighbor relation if there PCI allocation is difficult for a cell which also has a neighbor link for which the successful_handover KPI is below a pre-specified threshold

 Policy

 @Pamela Dragosh

EPIC POLICY-1438

US POLICY-1463:

US POLICY-1464:

EPIC POLICY-1438

  1. US POLICY-1463:

    1. Policy module shall support handling of partial success where only some of the PCI change actions from a set of changes are successful (e.g. allow partial changes, revert to previous state)

    2. Policy CLC shall co-ordinate between PCI SON Control Loop (CL) and some other control loops (CL) which are acting on the same cells.

  2. US POLICY-1464: Covers all additional/changed configuration related aspects, for e.g., algorithm names/constraints for optimization (e.g., minimize number of PCI values used, minimize number of changes), thresholds, etc.
    Note: Including CLAMP for Dublin is not recommended based on guidance from Policy and DCAE PTLs.

 SDC

 @Michael Lando



  1. SON Handler Microservice shall be onboarded manually and not via SDC (as agreed with DCAE PTL)

 SDNC

 @Dan Timoney

(Carryover items from Dublin)

-SDNC-430: Modify RAN informational model and yang model for RAN
-SDNC-431: Implement config DB and REST API (SDN-R / OOF interface)
-SDNC-432: Interfacing SDN-R with Policy
•Receive DMaaP message in CL format from Policy (Modify Config message using existing LCM API), send netconf message changing PCI value to cellID as specified, update config DB, and publish change on DMaaP (DMaaP client is available and can be called)
-SDNC-433: Receive netconf notification from RAN, update configDB, and publish change on DMaaP

  1. SDNC-430: Modify RAN informational model and yang model for RAN

  2. SDNC-431: Implement config DB and REST API which can be used by ONAP component. API shall support all CRUD operations. Schema and data model shall be aligned with A&AI.

  3. SDNC-432: Interfacing SDN-R with Policy - Receive DMaaP message in CL format from Policy (Modify Config message using existing LCM API), send netconf message changing PCI value to cellID as specified, update config DB, and publish change on DMaaP (DMaaP client is available and can be called)

  4. SDNC-433: Receive netconf notification from RAN, update configDB, and publish change on DMaaP

(RANSim)





  1. RANSim shall send FM/PM data (e.g. PCI confusion alarm, Handover KPI) to VES Collector

  2. Provide UI support to ANR updates @sa

*Each Requirement should be tracked by its own User Story in JIRA 

APIs

There are two inter-module API specifications in this use case. Both were defined for Casablanca and there will be enhancements done for Dublin release.
(Note: The API from the SON Handler MS to the FM/PM Database is internal to DCAE and the API is not exposed.)

(a) OOF API for PCI: 
Link to API spec on OOF page: PCI Optimization API
Link to OOF Impacts page for Dublin enhancments: OOF Impacts

(b) Config DB API: 
Link to Config DB spec: https://lf-onap.atlassian.net/wiki/download/attachments/16281383/SDNC_ConfigDB_API_Ver2.json?api=v2 (Nov 2018)

Link to Config DB page for Dublin enhancements: Config DB Impacts

Integration Testing

Note: The OOF-PCI Integration testing is being carried out at Windriver lab.
Please see this page for further test case details and up-to date status: Integration Testing

Note: DMaaP should be setup for most of the test cases below.

#

Component(s)

Test Case

Status

Remarks

#

Component(s)

Test Case

Status

Remarks

IT#001

DCAE (SON Handler MS)

SON Handler Micro-service successfully on-boarded on to DCAE

Complete



IT#002

DCAE (SON Handler MS)

SON Handler Micro-service's DB is up and the Micro-service is able to read/write data.

Complete



IT#003

DCAE (SON Handler MS)

SON Handler Micro-service is able to successfully fetch config policies from Consul.



NOT YET TESTED



IT#004

OOF and Policy

OOF is able to successfully fetch config policy from Policy

NOT YET TESTED



IT#005

DCAE (SON Handler MS)

SON Handler Micro-service is able to successfully receive a message over DMaaP containing PM/FM data (from VES Collector)

Complete



IT#006

DCAE (SON Handler MS) and DMaaP

SON Handler Micro-service is able to successfully receive a message over DMaaP containing neighbor list update

Complete



IT#007

DCAE (SON Handler MS) REST interface

SON Handler Micro-service is able to successfully fetch neighbor list details using REST interface (Config DB APIs)

Complete



IT#008

DCAE (SON Handler MS) and OOF

SON Handler Micro-service invokes REST API of OOF for PCI optimization

NOT YET TESTED



IT#009

OOF and Config DB (REST API)

OOF is able to obtain relevant neighbor list information for optimization algorithm from ConfigDB (REST API)

NOT YET TESTED



IT#010

DCAE (SON Handler MS) and OOF

SON Handler Micro-service receives optimization result from OOF (via callback URL) and sends response

NOT YET TESTED



IT#011

DCAE (SON Handler MS) and Config DB (REST API)

SON Handler Micro-service is able to successfully fetch PNF details from Config DB (using REST API call)

Complete



IT#012

DCAE (SON Handler MS) and Policy

SON Handler Micro-service is able to send PCI/neighbor list updates via DMaaP to Policy

NOT YET TESTED



IT#013

Policy and SDN-R

Policy is able to successfully send a DMaaP message (to SDN-R) with PCI/neighbor list updates.

NOT YET TESTED



IT#014

Policy and DMaaP

Policy is able to successfully receive a DMaaP message with PCI/neighbor list update response

NOT YET TESTED



IT#015

DCAE (SON Handler MS) and Policy

SON Handler Micro-service is able to receive PCI/neighbor list update response via DMaaP from Policy, process it and logs the results.

NOT YET TESTED



IT#016

DCAE (SON Handler MS)

SON Handler Micro-service is able to process PM KPI data, store as needed, and apply rules to recommend removal of a neighbor relationship.

Complete



IT#017

SDN-R

Upon receiving message from Policy, SDN-R sends netconf message to RAN-Sim.

NOT YET TESTED



IT#018

DCAE (VES Collector)

VES Collector receives VES messages from RAN-Simulator

Complete





Use Case Testing - End to End flow to be Tested

Note: The OOF-PCI use case implementation and testing will be done at the Rutgers University Winlab ONAP Wireless Lab. Access is available to interested ONAP members.

Please see this page for details: Open Wireless Laboratory (OWL) at Wireless Information Network Laboratory (WINLAB)

**This should be a summary level Sequence diagram done in Gliffy** 

Test Cases and Status



#

Test Case

Status

#

Test Case

Status

1

There should be a test case for each item in the sequence diagram

Not yet tested

2

create additional requirements as needed for each discreet step

Complete

3

Test cases should cover entire Use Case

Partially Complete

Test Cases should include enough detail for testing team to implement the test

 Failed