Name of Use Case:
Use Case Authors:
combination of use cases proposed by (in alphabetical order):
AT&T, China Mobile, Ericsson, Metaswitch Network, Orange
Description:
A Mobile Service Provider (SP) plans to deploy VoLTE services based on SDN/NFV. The SP is able to onboard the service via ONAP. Specific sub-use cases are:
- Service onboarding
- Service configuration
- Service termination
- Auto-scaling based on fault and/or performance
- Fault detection & correlation, and auto-healing
- Data correlation and analytics to support all sub use cases
ONAP will perform those functions in a reliable way. Which includes:
- the reliability, performance and serviceability of the ONAP platform itself
- security of the ONAP platform
- policy driven configuration management using standard APIs or scripting languages like chef/ansible (stretch goal)
- automated configuration audit and change management (stretch goal)
To connect the different Data centers ONAP will also have to interface with legacy systems and physical function to establish VPN connectivity in a brown field deployment.
Users and Benefit:
SPs benefit from VoLTE use case in the following aspects:
- service agility: more easy design of both VNF and network service, VNF onboarding, and agile service deployment.
- resource efficiency: through ONAP platform, the resource can be utilized more efficiently, as the services are deployed and scaled automatically on demand.
- operation automation and intelligence: through ONAP platform, especially integration with DCAE and policy framework, VoLTE VNFs and the service as a whole are expected to be managed with much less human interference and therefore will be more robust and intelligent.
VoLTE users benefit from the network service provided by SPs via ONAP, as their user experience will be improved, especially during the peak period of traffic
VNF:
Utilize vendors VNFs in the ONAP platform.
TIC Location | VNFs | Intended VNF Provider |
Edge | vSBC | Huawei |
vPCSCF | Huawei | |
vSPGW | ZTE/Huawei | |
Core | vPCRF | Huawei |
VI/SCSCF | Huawei | |
vTAS | Huawei | |
VHSS | Huawei | |
vMME | ZTE/Huawei |
Note: The above captures the currently committed VNF providers, we are open to adding more VNF providers.
Note: The committed VNF providers will be responsible for providing support for licensing and technical assistance for VNF interowrking issues, while the core ONAP usecase testing team will be focused on platform validation.
NFVI+VIM:
Utilize vendors NFVI+VIMs in the ONAP platform.
TIC Location | NFVI+VIMs | Intended VIM Provider |
Edge | Titanium Cloud (OpenStack based) | Wind River |
VMware Integrated OpenStack | VMware | |
Core | Titanium Cloud (OpenStack based) | Wind River |
VMware Integrated OpenStack | VMware |
Note: The above captures the currently committed VIM providers, we are open to adding more VIM providers.
Note: The committed VIM providers will be responsible for providing support for licensing and technical assistance for VIM integration issues, while the core ONAP usecase testing team will be focused on platform validation.
Network equipment
Network equipment vendors.
Network equipment | intended provider |
---|---|
Bare Metal Host | Huawei, ZTE |
WAN/SPTN Router (2) | Huawei, ZTE |
DC Gateway | Huawei |
TOR | Huawei,ZTE |
Wireless Access Point | Raisecom |
VoLTE Terminal Devices | Raisecom |
Note: The above captures the currently committed HW providers, we are open to adding more HW providers.
Note: The committed HW providers will be responsible for providing support for licensing and technical assistance for HW integration issues, while the core ONAP usecase testing team will be focused on platform validation.
Topology Diagram:
Work Flows:
Customer ordering
- Design
- Instantiation
- VNF Auto-Scaling/Auto-healing
- Termination
Controll Automation:
Open Loop
- Auto ticket creation based on the policy (stretch goal)
Closed Loop
- Auto-scaling (stretch goal)
When a large-scale event, like concert, contest, is coming, the service traffic may increase continuously, the monitoring data of service may grow higher, or other similar things make the virtual resources located in TIC edge become resource-constrained. ONAP should automatically trigger VNF actions to horizontal scale out to add more virtual resource on data plane to cope with the traffic. On the contrary, when the event is done, which means the traffic goes down, ONAP should trigger VNF actions to scale in to reduce resource.
- Fault detection & correlation, and auto-healing
During the utilization of VoLTE service, faults alarms can be issued at various layers of the system, including hardware, resource and service layers. ONAP should detect these fault alarms and report to the system to do the alarm correlation to identify the root cause of a series of alarms and do the correction actions for auto healing accordingly.
After the fault detected and its root correlated, ONAP should do the auto-healing action as specified by a given policy to make the system back to normal.
Configuration flows (Stretch goal)
- Create (or onboard vendor provided) application configuration Gold standard (files) in Chef/Ansible server
- Create Chef cookbook or Ansible playbook (or onboard vendor provided artifacts) to audit and optionally update configuration on the VNF VM(s)
- Install the Chef client on the VM (Ansible doesn’t requires)
- After every upgrade or once application misconfiguration is detected, trigger auditing with update option to update configuration based on the Gold Standards
- Post-audit update, re-run audit, run healthcheck to verify application is running as expected
- Provide configuration change alert to Operation via control loop dashboard
Platform Requirements:
- Support for commercial VNFs
- Support for commercial S-VNFM/EMS
- Support for Multiple Cloud Infrastructure Platforms or VIMs
- Cross-DC NFV and SDN orchestration
- Telemetry collection for both resource and service layer
- Fault correlation application
- Policy for scaling/healing
Project Impact:
< list all projects that are impacted by this use case and identify any project which would have to be created >
- Modeling
Modeling will need to be added to describe how VNFs are to be instantiated, removed, healed (restart, rebuild), scaled, how metrics related are gathered, how events are received
Modeling will need to be added to describe the connection service (underlay/overlay) between cloud Edge and Core.
- SDC
Add logic to use the new modeling when designing the service, and then distribute the resulting artifacts - SO
Add logic to understand the new artifacts; orchestrate/manage changes according to it - SDN-C/SDN Agent
Add logic to support to provision the underlay and overlay connection service between clouds, including 3rd party commercial SDN controllers. - DCAE
Support statistics collection on the VoLTE case and receipt of events as per the new model - VNF
Support to integrate with S-VNFM/S-EMS to fulfill the NS lifecycle management and configuration.
- VF-C and DCAE
Support the above control loops - SO/SDN-C/SDN Agent/VF-C
Monitor the service to verify the all NSs/VNFs have been executed, and update A&AI. - A&AI
Support the new data model - Policy
Support new policy related to the scaling and healing in VoLTE use case - Multi-VIM
Support multiple VIMs
Priorities:
1 means the highest priority.
Functional Platform Requirement | Priority | basic/stretch goal default basic goal |
---|---|---|
VNF onboarding | 2 | |
Service Design | 1 | |
Service Composition | 1 | |
Network Provisioning | 1 | |
Deployment automation | 1 | |
Termination automation | 1 | |
Policy driven/optimal VNF placement | 3 | stretch |
Performance monitoring and analysis | 2 | |
Resource dedication | 3 | stretch |
Controll Loops | 2 | |
Capacity based scaling | 3 | stretch |
Triggered Healthcheck | 2 | |
Health monitoring and analysis | 2 | |
Data collection | 2 | |
Data analysis | 2 | |
Policy driven scaling | 3 | stretch |
Policy based healing | 2 | |
Configuration audit | 3 | stretch |
Multi Cloud Support | 2 | |
Framework for integration with OSS/BSS | 3 | stretch |
Framework for integration with vendor provided VNFM(if needed) | 1 | |
Framework for integration with external controller | 1 | |
Non-functional Platform Requirement | ||
Provide Tools for Vendor Self-Service VNF Certification (VNF SDK) | NA | NA |
ONAP platform Fault Recovery | NA | NA |
Security | NA | NA |
Reliability | NA | NA |
Dister Recovery | NA | NA |
ONAP Change Management/Upgrade Control/Automation | NA | NA |
Work Commitment:
< identify who is committing to work on this use case and on which part>
Work Item | ONAP Member Committed to work on VoLTE |
---|---|
Modeling | CMCC, Huawei, ZTE, BOCO |
SDC | CMCC, ZTE |
SO | CMCC, Huawei, ZTE |
SDN-C/SDN-Agent | CMCC, Huawei, ZTE |
DCAE/Homles/CLAMP | CMCC, ZTE, BOCO, Huawei, Jio |
VF-C | CMCC, HUAWEI, ZTE, BOCO, Nokia, Jio |
A&AI | HUAWEI, ZTE, BOCO |
Policy | ZTE |
Multi-VIM | VMWare, Wind River |
Portal | CMCC |
Name of Use Case: vEPC
Use cas authors:
Orange
Description:
Extend EPC capabilities with vSGW and vPGW. Demonstrate how to use a hybrid (PNF+VNF) solution using ONAP
Version 0: no automatic legacy configuration. Deployment on a single OpenStack data-center based with no SDNC
Version 1: only configure legacy MME. Deployment based on a single OpenStack data-center based with no SDNC
Version 2: configure the full EPC (legacy+virtualised) functions on 2 OpenStack data-centers using SDNC
VNF should be compliant with APP-C and DCAE using Netong/Yang for configuration and VES or SNMP for event collections
V0
On-boarding/Design phase
The ONAP designer onboards the VNF descriptors, define the Directed Graphs for the 2 VNF and the legacy MME for configuration and defines the service.
The ONAP designer defines a simple policy rule: to scale vPGW on the basis of the number of sessions and configure the MME to take into account the new vPGW
Open questions:
- do we need to describe the PNF in the SDC ?
- how to plug the legacy MME management solution to APP-C ?
Deployment phase
The ONAP-operating deploys the vEPC service.
As a result, one vSGW and one vPGW are deployed using SO and APP-C and updating AAI.
Closed loop
Triggered on a number of sessions, the policy engine executes the rule that triggers the SO to instantiate a new vPGW and will the APP-C to configure both the vPGW and the MME.
Users and benefits:
SPs benefit from vEPCuse case in the following aspects:
- service agility: more easy design of both VNF and network service, VNF onboarding, and agile service deployment.
- resource efficiency: through ONAP platform, the resource can be utilized more efficiently, as the services are deployed and scaled automatically on demand.
- operation automation and intelligence: through ONAP platform, especially integration with DCAE and policy framework, vEPC VNFs and the service as a whole are expected to be managed with much less human interference and therefore will be more robust and intelligent.
vEPC users benefit from the network service provided by SPs via ONAP, as their user experience will be improved, especially during the peak period of traffic
VNF:
VNF vendors to be defined
VNF open-source available: OAI, openEPC, C3PO
Summary
Full Description
children