1. Proposal about ONAP service provision and activation system/function

2. Class 1: short workflow service Class 2: long workflow service
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:
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
Customer requests a kind of service
BSS
Class 1: short workflow service
Class 2: long workflow service
Service order ticket
OSS
Service provision system/function
Resource Mgt system/function
Res Req
Workforce ticket
Activation ticket
Service activation instruction
Workforce schedule system/function
Service activation system/function
Workforce ticket
Service activation instruction
HSS
SCP
AS…
OMC/
EMS
OMC/
EMS
OMC/
EMS…

3. Class 2: long workflow service
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
Customer requests a kind of service
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
BSS
Class 2: long workflow service
Service order ticket
OSS
Service provision system/function
Resource Mgt system/function
Res Req
Workforce ticket
Orches. ticket
Activation ticket
Workforce schedule system/function
Service Orchestration system/function
Service activation system/function
Workforce ticket
Service Orchestration
Service activation instruction
VIM
VNF NS
OMC/
EMS
OMC/
EMS
OMC/
EMS…

4. (1)？ (3)？ (2)？ 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.
Customer requests service provision
Customer requests service provision
BSS
BSS
(1)？
evolving
OSS
ONAP
ONAP
(3)？
(2)？
OMC/EMS… …
OMC/EMS/VNFM… …
OMC/EMS… …
OMC/EMS/VNFM… …
PNF… …
NFV… …
SDN… …
PNF… …
NFV… …
SDN… …

5. Proposal about service provision system/function architecture
North Bound Interface
Interface with Resource Management
Database
Order split and workflow control
Workflow Engine
Workforce and workflow process
Service Orchestration Interface
Service Activation Interface

6. Proposal about service activation system/function architecture
North Bound Interface
Database
Control FSM interface with NE
Instruction transformation Engine
NE instruction adapter
NE instruction adapter
NE instruction adapter

7. How it supports S3P Scalability Security Stabilility Performance
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.

8. 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”

9. 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.

10. 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.

11. Commitment - People/companies willing to work on the requirement
TBD.

12. Thanks！