Children Display |
---|
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 |
Component/Activity | Responsible(s) |
---|---|
Overall Point of Contact, Use case scope and content | N.K. Shankaranarayanan (AT&T), Swaminathan Seetharaman (Wipro) |
ConfigDB | |
DCAE | |
OOF | |
Policy | |
SDN-R | |
RAN-Simulator | |
Winlab Setup | |
E2E Use case/demo setup/config | |
Integration Testing |
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
- 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.
- 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 |
---|---|---|---|
AAI |
| ||
DCAE |
|
| |
OOF |
|
| |
Policy | EPIC POLICY-1438 US POLICY-1463: US POLICY-1464: | EPIC POLICY-1438
| |
SDC |
| ||
SDNC | (Carryover items from Dublin) -SDNC-430: Modify RAN informational model and yang model for RAN |
| |
(RANSim) |
|
*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://wiki.onap.org/download/attachments/28382769/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
use case implementation and testing will be done at the Rutgers University Winlab ONAP Wireless Lab. Access is available to interested ONAP membersIntegration testing is being carried out at Windriver lab.
Please see this page for further test case details
: Open Wireless Laboratory (OWL) at Wireless Information Network Laboratory (WINLAB)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 |
---|
IT#001 | DCAE (SON Handler MS) | SON Handler Micro-service successfully on-boarded on to DCAE |
|
|
IT#002 | DCAE (SON Handler MS) | SON Handler Micro-service's DB is up and the Micro-service is able to read/write data. |
|
|
IT#003 | DCAE (SON Handler MS) | SON Handler Micro-service is able to successfully fetch config policies from Consul. |
Status | ||
---|---|---|
|
IT#004 | OOF and Policy | OOF is able to successfully fetch config policy from Policy |
Status | ||
---|---|---|
|
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) |
|
| |||
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 |
|
| |||
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) |
|
title | Not yet tested |
---|
Status | ||
---|---|---|
|
| ||||||
IT#008 | DCAE (SON Handler MS) and OOF | SON Handler Micro-service invokes REST API of OOF for PCI optimization |
Status | ||
---|---|---|
|
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) |
Status | ||
---|---|---|
|
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 |
Status | ||
---|---|---|
|
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) |
|
| |||
IT#012 | DCAE (SON Handler MS) and Policy | SON Handler Micro-service is able to send PCI/neighbor list updates via DMaaP to Policy |
Status | ||
---|---|---|
|
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. |
Status | ||
---|---|---|
|
NOT YET TESTED | |
IT#014 | Policy and DMaaP |
Policy is able to successfully receive a DMaaP message |
with PCI/neighbor list update response |
Status | ||
---|---|---|
|
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 |
Status | ||
---|---|---|
|
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. |
|
title | Not yet tested |
---|
Status | ||
---|---|---|
|
| ||||||
IT#017 | SDN-R |
Status | ||
---|---|---|
|
Upon receiving message from Policy, SDN-R sends netconf message to RAN-Sim. |
NOT YET TESTED |
title | Not yet tested |
---|
IT#018 | DCAE (VES Collector) | VES Collector receives VES |
messages from RAN-Simulator |
|
title | Not yet tested |
---|
|
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**
Gliffy Diagram | ||||
---|---|---|---|---|
|
Test Cases and Status
# | Test Case | Status | ||||||
---|---|---|---|---|---|---|---|---|
1 | There should be a test case for each item in the sequence diagram |
| ||||||
2 | create additional requirements as needed for each discreet step |
| ||||||
3 | Test cases should cover entire Use Case |
| ||||||
4 | Test Cases should include enough detail for testing team to implement the test |
|