Usecase proposal: ONAP service provision and activation system/function

Owned by xiangyang yuan
Last updated: Nov 06, 2017
3 min read

Name of Use Case:      

ONAP service provision and activation system/function

Use Case Authors:

China Mobile

Presentation Materials:

Description:

Process and system/function supporting service provision&activation in current network environment

The figure below shows the process and system/function supporting service provision&activation in current network environment:

 

There are two classes of service provision?

  • Short workflow service: when a customer requests this kind of service, BSS sends service activation instruction to the corresponding NE

  • Long workflow service: when a customer requests this kind of service, BSS sends service order ticket to OSS, service provision system/function of OSS schedules three main function/system to achieve: (1)resource request; (2)workforce scheduling; (3)service activation

In NFV/SDN network environment,  based the original workflow for service provision, one function “service orchestration” must be added

In NFV/SDN network environment,  based the original workflow for service provision, one function “service orchestration” must be added, “service orchestration” function apply VM resource\deploy NS/VNF\config NS/VNF\etc..., especially for vCPE\eBOD\etc… services, the figure below shows this point:



The new service provision system/function schedules four main function/system:

  1. resource request

  2. workforce scheduling

  3. service Orchestration: newly added

  4. service activation

Why suggest ONAP implements these functions?

These functions are implemented in BSS/OSS traditionly, then why suggest ONAP implements these functions? (1)BSS is confused about which service is provioned by OSS or ONAP; (2)Some requirements require ONAP to interface with PNF(for example: 5G slicing); (3)Along with more PNFs transformation to VNFs, all functions of OSS will be merged in ONAP.

The figure below shows this point:

 

Proposal about service provision system/function architecture

 

Proposal about service activation system/function architecture



How it supports S3P

Scalability

Since service provision and activation functions are provided to end users and clerks and maintainers, there may be lots of users online to use these functions, for example, there may be tens of thousands of users online at the same time, so the subsystem must have enough scalability.

Security

Service provision and activation are revelant to the accouting and billing that may cause losses if one pretends to be others to achieve service provision and activation. So the subsystem must assure the security of itself according to the authentication and authorization  to users.

Stabilility

The subsystem of service provision and activation must assure 7*24 service to all users, so it should use some HA technologies to provide stability.

Performance

The subsystem must use distributed technologies to provide enough performance to all online users.

Platform requirements/dependencies, flows, identifying “what”

ONAP External API – legacy subsystem:

BSS send the request to ONAP through External API subsystem, External API dispatches the requests to different subsystems according to the predefined rules.

ONAP Service Orchestration – legacy subsystem:

Service Orchestration subsystem may implement service provision and activation functions, if so, there’s no need to add new subsystems below.

ONAP Service Provision  – new subsystem:

If not implemented in SO, there must be a new subsystem “service provision” whose architecture is just like “Proposal about service provision system/function architecture”

ONAP Service Activation – new subsystem:

If not implemented in SO, there must be a new subsystem “service activation” whose architecture is just like “Proposal about service activation system/function architecture”

Any dependencies on specific VNF capabilities

“Service Activation”subsystem will send the corresponding instructions to VNF according to the service request,  so this subsystem must depend on different VNF. But there should be a common platform in which there may be different plugins to adapt different VNF. And this service request requires the VNF to open its activation capability.

VNFs that we would use to test the requirement

Service provision and activation functions may be tested in vCPE usecase and VoLTE usecase and enterprise vCPE usecase, etc. Since it has short workflow and long workflow services, it is recommended that it should be tested in both service scenarions.

Commitment - People/companies willing to work on the requirement

TBD.