Topic: Use Case expectations as to compliance to Standards: It would be helpful to the community delivering upon this use case to make explicit any success criteria related to conformance to Standards. A few areas that come to mind that would be important from this perspective would be in the VNF and Network Service models in support of on-boarding/service design. This is particularly important given the goal of attracting VNF suppliers to target the platform.

Will service assurance we included in the policy work item?  Ensuring that we have acceptable call quality and don't drop calls are two basic, but critical requirements.

It will be good to include the Onboarding of the NFVI itself (Compute, Storage, Memory) as part of this use case. As discussed during the meeting, this is in scope and we can discuss the finer details during the break-out sessions.

Regards

Aayush

Reliance Jio

We may need to consider the impact on Portal component to achieve the security, reliability, and performance of the ONAP platform.

I think open-loop operations needs access to performance and faults data from VNFs, for troubleshooting purposes. Could we consider for the use case to have the FM/PM data made available to operator? It could be from internal FM/PM ONAP GUI or sending data to external OSS assurance tools.

How are the core and edge data centers selected for the service deployment? When the number of the data centers (especially at the edge) becomes large and when there are a number of constraints related to the placement (e.g., latency to the customer, latency/distance between edge and core data centers, available capacity, legal/regulatory constraints, cost, etc), homing of the VNFs becomes a problem that needs automation.

The vMME placement in the Core DC may be questionable from the network design perspective a number of reasons (some are listed below). It may be better to move the vMME function to the Edge DC:

• The eNodeB's interface directly to MME with S1-MME logical links. So S1-MME traffic will need to go from eNB across the DCI links and overlays. There's latency sensitivity to this traffic as it carries UE registration, authentication, location updates, tracking area updates.
• UEs (mobile devices) communicate with MME using NAS. MME maintains state/context for every UE - session management, mobility management, UE capability, security keys
• In IoT use cases UE's without PDN (IP) capabilities transmit messages in the signaling path over NAS. This small data traffic is handled directly by MME

VoLTE calls require QoS both at the RAN/vEPC level (e.g. LTE QCI1) as well as at the IP transport level. The use case should reflect that as VoLTE QoS is usually a required part of the service.

From the vEPC perspective this use case will also require a vDNS VNF to handle the node selection and APN mapping.

auto-scaling and auto-healing feature are related/attached to the new Control Loop Component: "CLAMP", that should be introduced in the coming ONAP release. So it might be worth mentioning that Control Loop Component here.

Thank you for including the workflow diagrams.

The diagrams show only sunny-day scenarios. The use case should cover rainy-day scenarios, e.g. when one of the VNFs in the service fails to create due to lack of resources. What is the expected behavior? Should the process stop and all other VNFs be terminated? Should the process just stop and keep the already deployed VNFs? Addressing this in the flow diagrams may make them too complicated, but the project description should describe if rainy-day scenarios are in scope and what is the expected behavior.

Also, what does step 2.12 in the "Deploy" flow mean? What kind of grant action is performed there? Is that the NFVO resource grant to the VNFM as described by ETSI-NFV? If so, shouldn't the VF-C consult with the Service Orchestrator before granting?

There is a clear list of what VNFs and VNFs vendors are proposed to be used for this use case but I can't see any reference to what NFVI HW, and NFVI SW+VIM is proposed for this use case. After all the VNFs and NFVO will need to run on an infrastructure.

In the INSTANTIATION flow, the API call from SO to MultiVIM to instantiate the VNF isn't shown/being used.  It looks like MultiVIM isnt used at all for the VNF on instantiation, only setup of the Virtual Links. I think VM instantiation is only through the 3rd party VNFM but its not clear. I think for Instantiation you should show the openstack heat engine and the NOVA/NEUTRON calls that will help highlight the assumptions on what cloud is being used and the underlay/overlay assumptions inside that cloud if they are pertinent to ONAP.

To add on to Brain's point, for INSTANTIATION, SO would go through VNF-C which makes sense. But for actual VNF creation, whether it goes through VNF-C, or through 3rd party VNFM, eventually, it should come to MultiVIM, which will support VM lifecyle management such as VM instantiation, as proposed in the current MultiVIM project scope.

As Lingli has been doing a create job putting this use case together I think it would be beneficial to schedule a review where we go through the flows together. I think that's the fastest way to resolve those questions. Not sure if that's something we want to do in Beijing next week or on the phone before.

+1.

As we already have Use case subcommittee established, if needed, we will have a Use cases (vCPE and VoLTE) discussion as a part of this subcommittee work during f2f meeting next week.

Hi Alla, we have suggested to allocate a slot for usecase in F2F meeting in the Tursday morning.

Yes, Lingli, I noticed that.

In the spirit of helping add more detail I used the Etherplant tool from Eric@Orange to create flows for onboard, instantiate and closedloop that hopefully will add value to the discussion. Sorry its such a long post but we dont have a common place to run this right now except a VM I put up on Azure to test the tool (which I like )

Brian

@startuml
title VOLTE Onboarding 
ONAP_User -> SDC : VOLTE_Edge_VNF(vSBC,vPCSCF,vEPGW,vEPDG) onboarding (TOSCA+image)
ONAP_User -> SDC : VOLTE_Core_VNF(vI/SCSC,vTAS,vPCRF,vJHSS,vMME) onboarding (TOSCA+image)
ONAP_User -> SDC : vVOLTE_Edge service description
ONAP_User -> SDC : vVOLTE_Edge distribution
ONAP_User -> SDC : vVOLTE_Core service description
ONAP_User -> SDC : vVOLTE_Core distribution
|||
ONAP_User -> SDC : vIMS-CW (vI-CSCF,vS-CSCF,vBGCF,vP-CSCF,vHSS,vDNS) onboarding (HOT+image)
ONAP_User -> SDC : vIMS-CW service description
ONAP_User -> SDC : vIMS-CW distribution
|||
SDC -> SO : artifact distribution
SDN -> AAI : artifact distrubtion
SDC -> APPC : artifact distrubtion 
note left: DCAE Telemetry ?
note right: VNFM is not part of ONAP so no distribtion
ONAP_User -> APPC : DG creation for vIMS-CW configuration
ONAP_User -> Policy: scaling rule for vIMS-CW
ONAP_User -> Policy: scaling rule for vVOLTE (Edge and Core)
note right: need to determine which VOLTE elements to scale for CI tests
@enduml

@startuml
title VOLTE Instantiation
ONAP_User -> VID : vIMS-CW deployment
VID -> SO : vIMS-CW instantiation
SO -> AAI : inventory update
SO -> MULTI_VIM : vIMS-CW Heat template
MULTI_VIM -> OS_Heat : vIMS-CW instantiation
OS_Heat -> KVM : vIMS-CW instantiation
SO -> APPC : vIMS-CW Configuration using DG
APPC -> vIMS_CW : vIMS-CW configuration
|||
ONAP_User -> VID : vVOLTE_Core deployment
VID -> SO : vVOLTE_Core instantiation
SO -> AAI : inventory update
SO -> VNFM1 : vVOLTE_Core TOSCA template
VNFM1 -> KVM : vVOLTE_Core instantiation
VNFM1 -> vVOLTE_Core: vVOLTE_Core configuration
|||
ONAP_User -> VID : vVOLTE_Edge deployment
VID -> SO : vVOLTE_Edge instantiation
SO -> AAI : inventory update
SO -> VNFM1 : vVOLTE_Edge TOSCA template
note right: Are there multiple VNFM's for vIMS vs vEPC
VNFM1 -> KVM : vVOLTE_Edge instantiation
VNFM1 -> vVOLTE_Edge: vVOLTE_Edge configuration
@enduml

@startuml
title VOLTE Closed Loop
participant vIMS_CW
participant VOLTE_Edge
vIMS_CW -> DCAE : Number of sessions
DCAE -> Policy : Threshold crossing event
Policy -> APPC : scale vIMS-CW
note right: this makes ONAP consistent since \nAPPC has main interface \nto AAI for L4-L7 VNFs
APPC -> SO : instantiat new PGW with scaling template
SO -> MULTI_VIM : instantiate new PGW
MULTI_VIM -> OS_Heat : instantiate new PGW
OS_Heat -> KVM : vPGW instantiation 
SO -> APPC : configure vIMS-CW
APPC -> vIMS_CW : configure
|||
VOLTE_Edge -> DCAE : PGW Number of session
DCAE -> Policy : Threshold crossing event
Policy -> VF_C : scale VOLTE_Edge 
VF_C -> VNFM1 : scale PGW
VNFM1 -> OS : instantiate new PGW
OS -> KVM : instantiate new PGW
VNFM1 -> VOLTE_Edge : configure new PGW
@enduml

I apologize in advance for the length of this post.  I hope it adds clarity that is worth the space consumed.  After looking more carefully at the VoLTE use case I thought I would provide some thoughts on how we would do this with the seed code AT&T has provided into ONAP.  This is intended to provide a more detailed “Instantiate” sequence diagram view that builds on Brian’s sequence diagrams, and which illustrates an option to organize our SO internal structure, leveraging seed code that AT&T has provided into ONAP.  We will be supporting the approach described below as an option in SO since we have much of this already implemented, but others may want to use the same approach.

Gil 

Here is a set high level summary points to introduce the sequence diagrams:

1. The main SO participants in the sequence diagrams are a “service level” workflow, referred to as the “E2E Service Level Workflow” in the diagrams, and a “VNF-level” workflow referred to as the “Create VNF Instance BB”, where “BB” stands for “Building Block”.
2. The VNF-level workflow execution threads across all the various VNF types share the same participant lifeline because they all are instances of the same generic SO BPMN based “building block” workflow.  This building block’s runtime behavior is model-driven, where the model is an instance structure derived from the corresponding VNF’s TOSCA service template.
3. In a similar manner, the E2E Service-level workflow is a generic SO BPMN based workflow whose runtime behavior is model-driven, where the model is an instance structure derived from the corresponding Service’s TOSCA service template.
4. The functionality performed by the “Create VNF Instance BB” VNF-level SO workflow includes much of that which is performed by the “VF-C” participant in the “Instantiate” sequence diagram that appears in the “Workflows” section above on this wiki page.  Thus one can think of the "Create VNF Instance BB" VNF-level SO workflow has having genericized this functionality and pulled it into the SO component.
5. Recognizing that different Service Providers may want to model VoLTE differently, I have provided two different TOSCA modeling alternatives.  The sequence diagrams are organized according to these TOSCA models.  Note, however, that irrespective of the TOSCA model, the sequence diagrams look basically the same.  This is intended to illustrate the point that the workflows are intended to be implemented in a “generic” manner, and not specific to any particular Service or VNF type.  The model-driven behavior of ONAP as illustrated in the sequence diagrams would support either TOSCA modeling approach with no code impacts.
6. The sequence diagrams assume that there is a private VPN already established in the WAN, and that network already has presence at each Cloud Zone via a set of pre-configured VLAN tags.  Thus, all that is required is to assign one of these tags to each instantiated VNF, and to configure the Compute Host via HEAT to access this network via that VLAN tag.
7. Note that the TOSCA models interpret the VoLTE network VNF architecture such that vMME is considered to be part of the vEPC “Edge”.

Example A: Model and sequence diagrams whereby VoLTE is modeled as a Service:

The following sequence diagram illustrates SO behavior driven from a VoLTE service instantiation request, assuming TOSCA modeling example A:

Example B: Model and sequence diagrams whereby vEPC_Edge, vEPC_Core, vIMS_Edge, and vIMS_Core are each modeled as separate independently deployable Services:

The following sequence diagram illustrates SO behavior driven from a vIMS service instantiation request, assuming TOSCA modeling example B:

The following sequence diagram illustrates SO behavior driven from a vEPC service instantiation request, assuming TOSCA modeling example B:

Sorry for the fuzziness of the diagrams.  Here is a PDF of the original slide set, which will hopefully render better.

Gil Bullard