AI/ML MS for IBN based closed Loop in E2E Network Slicing

•    Mainstreaming the ml-prediction-ms(New mS introduction)
•    Support for multiple slices (sNSSAIs) in training and prediction modules
•    Use CPS instead of Config DB
•    Remove RAN Simulator dependency

Commitment from WIPRO  

DCAEGEN2-3067

YES

CL message for ANR created by SON-Handler MS to be modified to align with A1-based flow/support

Commitment from WIPRO   WIPRO  

DCAEGEN2-3148

DCAE SDK alignment for SliceAnalysis MS & enhanching AAI interface for supporting IBN CL 

Commitment from HUAWEI/ChinaTelecom

DCAEGEN2-3195

Slice Analysis enhancement

1. Enhancement with AAI Interface/processing for CL notification

Commitment from HUAWEI/ChinaTelecom

DCAEGEN2-3194

Impact on DCAE components for migrating from exiting MR clients to use kafka native towards the strimzi cluster.

Dependent on resource availability

Commitment from EST

Complete the post-migration updates.

Commitment from AT&T

VES 7.2.1 support for DCAE Microservices (outside of collectors)

 - TCAgen2

Commitment from Wipro

DCAEGEN2-2975

DMAAP SDK standardization for DCAE Microservices

• SliceAnalysis mS
• KPI-mS
• SON-Handler mS

Commitment from Huawei for SliceAnalysis mS, KPI-ms and SON-handler - In discussion with Wipro

DCAEGEN2-3030

AAF certificate dependency to be removed by making it a configurable property for MS

• DFC, RESTConf

  Stretch goals: Nokia for DCAEGEN2-3039 (DFC), Huawei for DCAEGEN2-3095 (RESTConf)

DCAEGEN2-3037

Sonarcoverage improvements for DCAE components

• SliceAnalysis mS, SNMPTrap, TCA-gen2, SON-Handler,DL-Handler, KPi-MS, VES-HV*, VESCollector*, MOD/onboardingAPI*, SDK*, Mapper, RESTConf, MOD/genprocessor, MOD/distributorapi

Commitment from AT&T, Wipro, HUAWEI, ChinaTelecom, Nokia   Nokia (* stretch-goal)

Automated review tool integration with CI/verify

Commitment from AT&T

DCAEGEN2-3186

Enhancements to KPI Computation MS

• Support KPI to be defined spanning multiple resources
• Handle unavailability of required counter for calculation

Commitment from Wipro

DCAEGEN2-3193

No root (superuser) access to database from application container

• TCAgen2

Commitment from Wipro

DCAEGEN2-2907

DMAAP SDK standardization for DCAE Microservices

• SliceAnalysis , mS
• KPI-mS,
• SON-Handler , mS
• RESTConf*

Commitment from Huawei,  Wipro Wipro 

DCAEGEN2-3030

REQ-443 - CONTINUATION OF CII BADGING SCORE IMPROVEMENTS FOR SILVER LEVEL

Global-REQ 

CII badging score improvement

Commitment from AT&T 

DCAEGEN2-31923209

REQ-439 1211- CONTINUATION OF PACKAGES UPGRADES IN DIRECT DEPENDENCIES

Global-REQ

<Pending SECCOM analysis/report>

Commitment TBD

Kohn DCAE (SECCOM)

Commitment: AT&T, Wipro, HUAWEI, ChinaTelecom,  Nokia

REQ-437 - COMPLETION OF PYTHON LANGUAGE UPDATE (v2.7 → v3.8)

Global-REQ

(No new impact for DCAE in K Kohn release)

REQ-438 - COMPLETION OF JAVA LANGUAGE UPDATE (v8 → v11)

Global-REQ

• dcaemod-designtool
• dcaemod-nifi-registry

Exception will be filed with SECCOM for waivers due to upstream (NIFi) dependency

Enhance ONAP common-service template - add IPv4/IPv6 support

(No new impact for DCAE in J Kohn release)

REQ-441/REQ-1070 - LOGS MANAGEMENT - PHASE 1: COMMON PLACE FOR DATA - KOHN RELEASE

Global-REQ

New mS (ml-prediction-mS) will be complaint to the requirement. All other DCAE mS area already complaint STDOUT logging

Commitment from Wipro 

Tracked under DCAEGEN2-3067

REQ-1073 - Using basic image from Integration  

(No new impact for DCAE in J Kohn release)

NA

No change planned for existing DCAE microservice. New mS (ml-prediction-mS) will be developed to be complaint to this Best-practice requirement. 

Commitment from Wipro

• Level 0: no performance testing done
• Level 1: baseline performance criteria identified and measured  (such as response time, transaction/message rate, latency, footprint, etc. to be defined on per component)
• Level 2: performance improvement plan created 
• Level 3: performance improvement plan implemented for 1 release (improvement measured for equivalent functionality & equivalent hardware)

2

• Level 0: none beyond release requirements
• Level 1: 72 hour component-level soak test (random test transactions with 80% code coverage; steady load)
• Level 2: 72 hour platform-level soak test (random test transactions with 80% code coverage; steady load)
• Level 3: track record over 6 months of reduced defect rate

• • 0 – none
  • 1 – manual failure and recovery (< 30 minutes)
  • 2 – automated detection and recovery (single site)
  • 3 – automated detection and recovery (geo redundancy)

1+  

• Level 0: None
• Level 1: CII Passing badge
  • Including no critical and high known vulnerabilities > 60 days old
• Level 2: CII Silver badge, plus:
  • All internal/external system communications shall be able to be encrypted.
  • All internal/external service calls shall have common role-based access control and authorization using CADI framework.
• Level 3: CII Gold badge 

1

• Level 0: no ability to scale
• Level 1: supports single site horizontal scale out and scale in, independent of other components
• Level 2: supports geographic scaling, independent of other components
• Level 3: support scaling (interoperability) across multiple ONAP instances

1+  (Except logging, all other requirements are met)

• Level 1:
• All ONAP components will use a single logging system.
• Instantiation of a simple ONAP system should be accomplished in <1 hour with a minimal footprint
• Level 2:
  • A component can be independently upgraded without impacting operation interacting components
  • Component configuration to be externalized in a common fashion across ONAP projects
  • All application logging to adhere to ONAP Application Logging Specification v1.2
  • Implement guidelines for a minimal container footprint
• Level 3
  • Transaction tracing across components

1+

• • Level 1:
    • User guide created
    • Deployment documentation
    • API documentation
    • Adherence to coding guidelines
  • Level 2:
    • API Documentation
      • All new API’s must adhere to the ONAP API Common Versioning Strategy and Documentation Guidelines
      • All existing APIs must be documented in Swagger 2.0
  • Level 3
    • Consistent UI across ONAP projects
    • Usability testing conducted
    • API Documentation
      • All new API’s, all external APIs, and all existing API’s that are modified must adhere to the ONAP API Common Versioning Strategy and Documentation Guidelines
  • Level 4
    • API Documentation
      • All API’s for a given project must adhere to the ONAP API Common Versioning Strategy and Documentation Guidelines

No change for this release

https://git.onap.org/dcaegen2/tree/docs/sections/apis/pmsh_swagger.json

No change for this release

https://git.onap.org/dcaegen2/tree/docs/sections/apis/swagger_slice_analysis.json

https://wikilf-onap.onapatlassian.orgnet/wiki/download/attachments/11774039616493831/slice-analysis-swagger.yaml?version=1&modificationDate=1640159785000&api=v2