1. Beijing Release use cases/requirements for endorsement/approval
Alla Goldner (inputs from Usecase subcommittee)
October, 2017

2. Network Function Change Management
Change management activities in large operational networks require a significant investment of time, effort, and cost. Because of the complex network and service dependencies, change mechanisms, SLAs, the change management process can sometimes result in negative impacts on network and service performance. Thus, there is a pressing need to improve the state-of-art in change management. In this use case, we propose a new ONAP- enabled change management framework. Specifically, we focus on software upgrades, patches and configuration changes for NFs (network functions). The goal of the framework is to achieve programmable and automated creation, scheduling and execution of the change management workflow. It will offer
(i) modular composition of workflow that would enhance the creation process,
(ii) a layer of abstraction that would simplify creation and management,
(iii) programmatic updates and communication within and across workflows that would highlight and resolve any conflicts,
(iv) scheduling of instructions through sequential, parallel, or iterative operations,
(v) automated execution of the workflow that would speed up the roll-out and minimize any negative impacts.
resulted in lower cost, faster roll-outs and improved quality of experience.
Platform requirements/dependencies, flows
SDC (catalog of building blocks, designer for creating change management workflows),
SO (executing CM workflows),
A&AI (inventory of instances, enable/disable EIM flag for ticket suppression),
Controller (execution of upgrade mechanisms such as in-place software upgrade),
DCAE (health checks, analytics for impact assessment),
Policy and scheduling 
Any dependencies on specific VNF capabilities
None
VNFs that we would use to test the use cases
Any offered by ONAP
Companies willing to contribute
AT&T, Ericsson

3. Network Function Change Management
Locking mechanism
Platform capabilities exposure

4. General – Auto and manual scaling
This proposal is to suggest the feature auto & manual scaling to be implemented in R2.
Missing features which were not implemented in R1.
R46: VNF auto scaling is merged from Capacity based scaling and Policy driven scaling.
R47: VNF manual scaling (in/out) is a new feature.
Other Reqs are existed in R1 (stretch goal), but not implemented yet.
Req Id
Functional Requirement
Priority as initially submitted
Source
/ Use Case
New Component / Enhancement
Comments
R46
VNF autoscaling (in/out) 3
VoLTE
Enhancement
Merged from Capacity based scaling and Policy driven scaling.
R47
VNF manual scaling (in/out)
New
Manual scaling triggered from portal.
R48
Configuration audit
R49
Resource dedication
This came out of one of the other use cases. It’s the capability to specify constrains on VNFs (e.g. this VNF needs to be on it’s own dedicated server)
R50
Policy driven/optimal VNF placement
R51
Framework for integration with OSS/BSS

5. R46: VNF auto scaling (in/out) – Description, Flow
Description: VNF auto scaling is based on policies. The input of the policy can be either application aspect events/conditions (e.g. subscriber capabilities ,call loss rate) or non-application aspect events/conditions (e.g. CPU usage).
Portal
SDC/CLAMP
DCAE/Holms/Policy/VF-C
EMS/VNF
VIM&NFVI
1. Policy design, distribute and activation.
2.1. Report/collect application aspect data
2.2. Report/collect non-application aspect data
3. Trigger VNF auto scaling

6. R46: VNF auto scaling (in/out) – VNF capabilities
Any dependencies on specific VNF capabilities
VNF should support scaling in different flavors/levels
VNF/EMS should support the monitoring of the metrics which are used by auto-scaling policies
VNFs that we would use to test the use cases
VNFs in VoLTE usecase: MME, SAE-GW, CSCF, AS
Companies willing to contribute

7. R47: VNF manual scaling (in/out) – Description, Flow
Auto-scaling can trigger the scaling operation based on the real-time state of a VNF instance. But it cannot cover all operators’ requirements of scaling. For example, on holidays or in large activities, auto-scaling cannot provide an immediate response to the huge growth of traffic.
Manual scaling provide the capability of VNF scale in/out triggered by operators based on predicted demand.
Portal SO
VF-C
3rd VNFM
VIM/NFVI
3rd EMS/VNF
1. Manually trigger scaling operation
2. Scaling in/out
3. Operate scaling in/out

8. R47: VNF manual scaling (in/out) – VNF capabilities
Any dependencies on specific VNF capabilities
VNF should support scaling in different flavors/levels
VNFs that we would use to test the use cases
VNFs in VoLTE usecase: MME, SAE-GW, CSCF, AS
Companies willing to contribute

9. Non-functional requirements
Many will be covered by Beijing/OOM (mentioned already)
ents
Majority should be traced by Carrier Grage /S3P
Should we endorse?
What about development of tools? Who is in charge?

10. External Controller, E-vCPE, 5G/Network slicing
TBD

11. Backup slides

12. The list
PNF requirements category -   management of application  ( e.g. discover the presence, monitor, change configuration, do not manage physical hardware).
ONAP shall… - the requirement should be for ONAP’s support of PNFs (and eventually this may be translated into building an adaptation layer)
Modeling – harmonization of information/data model for services and resources.
Onboarding  - TOSCA onboarding support  - to complete onboarding VNFs/NSs by using TOSCA templates
Monitoring – multiVIM telemetry, working in the same way, independently of specific VIM, collecting and normalizing
VNF Homing optimization (including affinity/non-affinity rules)
Change management
Model driven interaction between the micro-services and the bus
External controller and interfaces to OSS/BSS – to specify standardized northbound/southbound interfaces 

13. PNF support https://wiki.onap.org/display/DW/PNF+Modelling+Capability
Support for PNF - Onboarding
Support for PNF - Data Collection & Monitoring
Support for PNF - Configuration & Control

14. Modeling
Harmonization of information and of data model for services and resources

15. Onboarding
TOSCA onboarding support  - to complete onboarding VNFs/NSs by using TOSCA templates
Support real-world   service design in SDC with standard based TOSCA model
Supported to some degree already in R1, used in the VoLTE use case, but not all Tosca constructs are supported, and not the latest Tosca version.

16. Monitoring
multiVIM telemetry, working in the same way, independently of specific VIM
By collecting and normalizing

17. VNF Homing

18. Model driven interaction between the micro-services and the bus
Will enable limiting the amount of pair-wise transactions between ONAP modules to minimum, resulting in a more robust software architecture, and more track-able and traceable transactioning

19. External controller and interfaces to OSS/BSS
OSS/BSS Integration
ONAP service   provision and activation system/function
External Controller Integration
Integration of external controller to Resource Orchestration – API, adapters
Integration of external controller to DCAE for events, metrics
Import of services, resources supported by external controller to VNF SDK/Onboarding and SDC
Representation/reference of services, resources supported by external controller in A&AI
Lifecycle management of external controller – Turn up, monitoring, scaling, termination

20. Yet to be determined and decided on
5G/Network slicing is considered to be a high priority requirement
Slice management – yet to be finalized and decided whether network slices introduces some new requirements or can be considered as any other Network service
In case of latter, will be recommended as a Use case for implementation/showing ONAP Platform capabilities for Beijing Release

21. Thank You!