Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »


Name of Use Case:


VoLTE


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:

  1. service agility: more easy design of both VNF and network service, VNF onboarding, and agile service deployment.
  2. resource efficiency: through ONAP platform, the resource can be utilized more efficiently, as the services are deployed and scaled automatically on demand.
  3. 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 GatewayHuawei
TORHuawei,ZTE
Wireless Access Point Raisecom
VoLTE Terminal DevicesRaisecom

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 RequirementPriority

basic/stretch goal

default basic goal

VNF onboarding2
Service Design1
Service Composition1
Network Provisioning1
Deployment automation1
Termination automation1
Policy driven/optimal VNF placement3stretch
Performance monitoring and analysis2
Resource dedication3stretch
Controll Loops 2
Capacity based scaling3stretch
Triggered Healthcheck2
Health  monitoring and analysis2
Data collection2
Data analysis2
Policy driven scaling3stretch
Policy based healing2
Configuration audit3stretch
Multi Cloud Support2
Framework for integration with OSS/BSS3stretch
Framework for integration with vendor provided VNFM(if needed) 1
Framework for integration with external controller1
Non-functional Platform Requirement

Provide Tools for Vendor Self-Service VNF Certification (VNF SDK)NANA
ONAP platform  Fault RecoveryNANA
SecurityNANA
ReliabilityNANA
Dister RecoveryNANA
ONAP Change Management/Upgrade Control/Automation NANA

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

 PortalCMCC 
  • No labels