Versions Compared

Version Old Version 30 New Version 31
Changes made by

N.K. Shankaranarayanan

N.K. Shankaranarayanan

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

This use case started in Casablanca Release. We have carryover items and enhancements. Please see 5G - OOF (ONAP Optimization Framework) and PCI (Physical Cell ID) Optimization for the base wiki page for this use case.


Showcase VNFTest Environment

Integration Team Liaison







Development Status

ProjectPTLJIRA 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
 Sarat Puthenpura
  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-432: 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 


Integration Testing

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)


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

#Component(s)Test CaseStatusRemarks
1DCAE (SON Handler MS)SON Handler Micro-service successfully on-boarded on to DCAE

Status
titleNot yet tested


2DCAE (SON Handler MS)SON Handler Micro-service's DB is up and the Micro-service is able to read/write data.

Status
titleNot yet tested


3DCAE (SON Handler MS)SON Handler Micro-service is able to successfully fetch config policies from Consul.


Status
titleNot yet tested

4OOF and PolicyOOF is able to successfully fetch config policy from Policy

Status
titleNot yet tested


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

Status
titleNot yet tested


6

DCAE (SON Handler MS) and SDN-R

SON Handler Micro-service is able to successfully receive a message over DMaaP containing neighbor list update (from SDN-R)

Status
titleNot yet tested


7DCAE (SON Handler MS) and Config DBSON Handler Micro-service is able to successfully fetch neighbor list details from Config DB.

Status
titleNot yet tested


8DCAE (SON Handler MS) and OOFSON Handler Micro-service invokes REST API of OOF for PCI optimization and receives response from OOF

Status
titleNot yet tested


9DCAE (SON Handler MS) and OOFSON Handler Micro-service invokes REST API of OOF for PCI optimization and receives response from OOF

Status
titleNot yet tested


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

Status
titleNot yet tested


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

Status
titleNot yet tested


12DCAE (SON Handler MS) and Config DBSON Handler Micro-service is able to successfully fetch PNF details from Config DB

Status
titleNot yet tested


13DCAE (SON Handler MS) and PolicySON Handler Micro-service is able to send PCI/neighbor list updates via DMaaP to Policy

Status
titleNot yet tested


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

Status
titleNot yet tested


15Policy and SDN-RPolicy is able to successfully receive a DMaaP message (fromSDN-R) with PCI/neighbor list update response

Status
titleNot yet tested


16DCAE (SON Handler MS) and PolicySON Handler Micro-service is able to receive PCI/neighbor list update response via DMaaP from Policy, process it and trigger necessary actions

Status
titleNot yet tested



Use Case Testing - End to End flow to be Tested

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

Gliffy
nameSummary SeqDia Template
pagePin7

Test Cases and Status


#Test CaseStatus
1There should be a test case for each item in the sequence diagram

Status
titleNot yet tested

2create additional requirements as needed for each discreet step

Status
colourGreen
titleComplete

3Test cases should cover entire Use Case

Status
colourYellow
titlePartially Complete

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

 

Status
colourRed
titleFailed