1. VoLTE Use Case (Approved) Proposal Alternative Orchestration Workflow Approach and Model Gil Bullard – AT&T

2. VoLTE Use Case (Approved)

3. VoLTE Use Case (Approved) Sequence Diagram

4. Problem Statement Summary
VoLTE_Edge Service:
vIMS_Edge Service:
vEPC_Edge Service:
Homing_Policy: Latency {Tower, vSPGW} < Y ms
Homing_Policy: Latency {vSPGW, vSBC} < X ms
SO VoLTE-Level Flow
vIMS VF-C “Flow”
vEPC VF-C “Flow”
If a Service Provider deploys a vIMS Service Instance in a particular region, the vIMS VF-C will home the vSBC in whichever Cloud Zone it likes, as no homing policies constrain it.
If the Service Provider then decides to deploy a VoLTE Service Instance in the same region, they would like to write homing policies that indicate whether to reuse an existing vSBC VNF instance as is, or to migrate and then reuse an existing vSBC VNF instance, or to instantiate a new vSBC VNF instance.
However, because the VF-Cs operate only within the context of vIMS or vEPC, neither is a good candidate to execute homing policies spanning both.
Were both vIMS and vEPC provided by the same vendor, a common (VoLTE level) VF-C could operate across both. However, for Service Providers with different vIMS and vEPC vendors, this would not be a viable solution. For Service Providers with heterogeneous vendor vIMS and/or vEPC implementations, a VF-C centric approach becomes even less viable.
This illustrates the AT&T position that “service decomposition” and “homing” must be done holistically at the topmost-service level, which should always be at the SO level and not delegated to a VF-C. I.e., SO needs the ability to decompose and manage at the VNF level, and solution accordingly.
See subsequent slides for a more detailed treatment of the problem and a proposed solution

5. Assumptions
The nature of the VoLTE Use Case (Approved) demands that VoLTE be modeled as a Service.
Some Service Providers may want to also model vIMS and/or vEPC as Services. This would allow them, for example, to offer a complete VoLTE Service in some geographies, but only vIMS in others. It would also allow a Service Provider to start with a rollout of a vIMS based VoIP Service, and later expand to VoLTE, while re-using some of the vIMS assets (such as the vSBC VNF).
A Service Provider who models all three (vIMS, vEPC, and VoLTE) as separate Services will want VoLTE Service Creation to re-use the models, including homing polices, of vIMS and vEPC.
More than one Edge DC can be served by the Core, so it would be useful, at least from a service instantiation perspective, to model the “Edge” and the “Core” as separate Services.
Assume that vIMS and vEPC VNFs communicate across a common WAN VPN that is shared by all vIMS and vEPC VNFs, including in the context of VoLTE. Further assume that configuring the VPN presence at a given Cloud Zone for vIMS would enable that Cloud Zone to participate in vIMS, vEPC, and VoLTE.

6. Assumptions VoLTE Model as two Services: VoLTE_Edge and VoLTE_Core
Model as two Services: vIMS_Edge and vIMS_Core
Model as two Services: vEPC_Edge and vEPC_Core
Assume that vIMS and vEPC share a common WAN, along with VoLTE. Configuring a WAN presence at a given Cloud Zone for vIMS would enable that Cloud Zone to participate in vIMS, vEPC ,and VoLTE.

7. Assumptions (Continued)
Some Service Providers may want to use a single vendor for their entire VoLTE Service offering. Other Service Providers may want to use a single vendor for their vIMS solution, but a different vendor for their vEPC solution. Yet other Service Providers may want to have vendors provide individual VNF components, and integrate their own heterogeneous vIMS, vEPC, and VoLTE solutions.
The approved use case allows for a vIMS VF-C which is separate and distinct from the vEPC VF-C. The following slides assume this case.
“Homing” must take place prior to WAN configuration because the WAN must be configured at the proper Cloud Zones.
At least some vendors will build “homing” logic into their VF-C solutions. However, the “homing” that a VF-C performs would be limited to the context of the domain that it manages. For example, if a vEPC VF-C has a homing policy written relative to the SBC function, the vEPC VF-C would expect the location of the SBC as part of its inputs, and could not itself attempt to calculate a homing solution for the SBC function.

8. Homing Policy Assumptions
vEPC Service Homing Policies:
Latency {vSPGW, vSBC} < X ms In the context of the vEPC Service, the latency between the vSPGW and the SBC function must be less than X ms.
Latency {Tower, vSPGW} < Y ms In the context of the vEPC Service, the latency between the Cell Tower and the vSPGW must be less than Y ms.
vIMS Service Homing Policies:
Homing_Policy: vSBC Cost = Z The “cost” of instantiating a new vSBC is not insignificant. The cost component(s) represented here would include licensing and other costs.
VoLTE Service Homing Polices: The VoLTE Service Description would inherit each of the above Homing Policies
The EPC (LTE) specification defines a non-EPC “SBC” function, and states a maximum allowed latency between the vSPGW and this SBC function.

9. The Following Slides…
The slides immediately following step through an example that is intended to illustrate a challenge with the VoLTE (Approved) Use Case flow approach found on the ONAP wiki.
Subsequent slides provide an alternative approach that could be used to resolve those challenges.
Each of the approaches are based on the previous stated assumptions

10. 2.0: User requests vIMS_Edge Service instantiation
Challenging Scenario for Approved VoLTE Sequence Diagram Approach: Step 1: Service Provider deploys vIMS Edge infrastructure for VoIP services
vIMS
2.0: User requests vIMS_Edge Service instantiation
2.4: In order for SO to create the WAN connectivity between the vPCSCF and the vI/SCSCF, wouldn’t SO have to had decomposed the vIMS_Edge Service into its component VNFs?
2.7: The vIMS VF-C selects Edge CD A as the location for the vSBC.
Note that, because SO retains the WAN provisioning responsibilities, the VF-C cannot hide the VNF-level details of the vIMS_Edge Service from SO.
It is not obvious where “homing” for vIMS is intended to occur in the VoLTE approved sequence diagram. For purposes of this analysis it is assumed that the VF-C vendor provides this functionality at or near step 2.13 (as per Chengli’s comment on VoLTE Use Case wiki.

11. A&AI vIMS_Edge Service Instance Instance “A”
Challenging Scenario for Approved VoLTE Sequence Diagram Approach: Step 1: Service Provider deploys vIMS Edge infrastructure for VoIP services (Cont’d)
vIMS
2.8: Because the vSBC was instantiated in the context of the vIMS_Edge Service, there would be an association in A&AI between the vSBC VNF instance and this vIMS_Edge Service Instance.
A&AI
vIMS_Edge Service Instance
Instance “A”
vSBC VNF Instance
Instance “X”

12. Challenging Scenario for Approved VoLTE Sequence Diagram Approach: Step 2: Service Provider Deploys VoLTE_Edge infrastructure
2.0: User requests VoLTE_Edge Service instantiation
2.7: Because the vEPC_Edge Service has a latency policy written against the location of the vSBC instance, SO must pass in to the vEPC VF-C the vSBC location information (Edge DC “A”).
2.7+: vEPC VF-C attempts to home the vSPGW in Edge DC “B” to meet the Tower latency, but finds that would lviolate the vSBC latency policy. It also finds that homing the vSPGW in Edge DC “A” violates the Tower latency policy. The vEPC VF-C, having no control over the homing of the vSBC, can only return failure. It does not know the vSBC homing policies to even suggest a compromise location.

13. Observations on the Two-Step Scenario Just Covered
In order to maximize efficient use of network resources, it is desirable to migrate the vSBC instance from Edge DC A to Edge DC B.
Such a decision cannot be made by a vIMS VF-C because it doesn’t know the vEPC policies to understand what would be a better location to which to migrate the vSBC.
Nor can such a decision be made by the vEPC VF-C because it doesn’t understand the full set of constraints for vSBC homing.
This illustrates why AT&T holds that the homing decision for both the vIMS and the vEPC VNFs must be done holistically, at the level of the Service Instantiation request (in this case “VoLTE”).
Unless instructed otherwise by the ONAP community, it is possible that the vIMS and vEPC vendor(s) would include homing logic built into their VF-C for homing within their respective domains. It would introduce additional complexity into ONAP to be able to leverage this functionality at the VoLTE level.
The following slides suggest an alternative approach for consideration.

14. Alternate VoLTE Use Case Approach
The alternative approach suggested for handling this challenging scenario assumes the ONAP implementation as described in “Aligning Orchestration and Controller Per Merger Agreement” by:
Vimal Begwani – AT&T Jamil Chawki – Orange Alla Goldner – Amdocs
In this alternative approach, there is a clear separation between the Service- level and the Resource-level orchestration flows.

15. Separation of Service Level and Resource Level Flows
Because the Resource Level flow is Generic (i.e., not specific to any particular VNF type), it can be built once and leveraged across multiple VNF type/vendor combinations. Thus the Resource Orchestration functionality is shown as being provided by SO. Thus there is no need to have each vendor build this functionality in a vendor-specific VF-C.
Also, because this Resource level flow is clearly defined and distinct, one could readily envision the Resource Level flows executing on a remote SO instance, separate from the SO instance that is running the associated Service Level flows. This would result in a distributed SO deployment architecture.
Service Orchestration
Resource
Orchestration

16. Design Time Model Behind Alternate VoLTE Use Case Approach
Note that vSBC is modeled as an “Infrastructure Service” (vSBCaaS) that provides “Allotted Resources” to both vIMS and to VoLTE service instances.
vSBCaaS Service:
topology_template:
node_templates:
vSBC (VNF):
Capability:
vSBCaaS_Capability
vIMS_Edge Service:
topology_template:
node_templates:
vPCSCF (VNF):
vSBCaaS (Allot Res):
vPCSCF VNF:
VoLTE_Edge Service:
topology_template:
node_templates:
vEPC (Service):
vIMS (Service):
Policies:
vSBC VNF:
Policies:
“Compile Time” Nesting
(For Service Designer
Reuse Purposes)
vSBCaaS Allotted Resource:
Requirement:
vSBCaaS_Capability
Homing_Policy: vSBC Instantiation Cost = Z
“Compile Time” Nesting
(For Service Designer
Reuse Purposes)
Service Level
(TOSCA)
VNF Level
(TOSCA or HEAT)
Allotted Resource Level
Key:
vSPGW VNF:
vEPC_Edge Service:
topology_template:
node_templates:
vSPGW (VNF):
vEPDG (VNF):
Policies:
vPEDG VNF:
Homing_Policy: Latency {Tower, vSPGW} < Y ms
Homing_Policy: Latency {vSPGW, vSBC} < X ms

17. Run Time Model Behind Alternate VoLTE Use Case Approach (Homing Policy View)
vSBCaaS Service:
topology_template:
node_templates:
vSBC (VNF):
Capability:
vSBCaaS_Capability
vIMS_Edge Service:
topology_template:
node_templates:
vSBCaaS (Allot Res):
vPCSCF (VNF):
Policies:
vSBC VNF:
Policies:
vSBCaaS Allotted Resource:
Requirement:
vSBCaaS_Capability
vEPC_Edge Service:
topology_template:
node_templates:
vSPGW (VNF):
vEPDG (VNF):
Policies:
Homing_Policy: vSBC Instantiation Cost = Z
VoLTE_Edge Service:
topology_template:
node_templates:
vSBCaaS (Allot Res):
vPCSCF (VNF):
vSPGW (VNF):
vEPDG (VNF):
Policies:
Homing_Policy: Latency {Tower, vSPGW} < Y ms
Homing_Policy: Latency {vSPGW, vSBC} < X ms
“Compile Time” nesting results in the vEPC_Edge Service homing policies being replicated in the VoLTE_Edge service context.
Homing_Policy: Latency {Tower, vSPGW} < Y ms
Homing_Policy: Latency {vSPGW, vSBC} < X ms

18. A&AI Instance Model Assumed After Step 1 of Alternate Approach Flow
Instances in Inventory After Step 1 of Challenging Scenario
Instances in Inventory After Step 2 of Challenging Scenario
Key
vIMS Service Instance
Instance “A”
vSBCaaS Allotted Resource
Instance “J”
vSBCaaS Service Instance
Instance “C”
vSBC VNF Instance
Instance “X”

19. Alternate VoLTE Use Case Approach Sequence Diagram (Page 1)
In this alternative approach, the SO VoLTE Service Level workflow drives decomposition of VoLTE down to the VNF and Allotted Resource level. This allows Homing to take into consideration the vEPC aspects as well as the VoLTE aspects of a vSBC migration.
In this example we assume that Homing determines that a vSBC VNF migration from Edge DC “A” to Edge DC “B” is desirable. Homing determines this migration would meet all homing policies for vIMS, VoLTE, and vSBCaaS.
Homing returns as part of its homing solution an instruction which prescribes such a VNF-level migration.

20. Alternate VoLTE Use Case Approach Sequence Diagram (Page 2)
As mentioned, homing returned as part of its homing solution an instruction which prescribed a vSBC VNF-level migration.
SO VoLTE Service-level flow executes this instruction, delegating the migration to the vSBCaaS Service Level flow, waiting for disposition from this vSBCaaS flow prior to proceeding.
Note that ONAP determines from A&AI that the “Service Owner” of the vSBC VNF is in fact the “vSBCaaS” Service. Thus, the VoLTE Service Level flow invokes a vSBCaaS Service Level flow to perform the migration.

21. Alternate VoLTE Use Case Approach Sequence Diagram (Page 3)
As mentioned previously, the Resource Level flow is a generic workflow, not specific to any particular VNF type. Thus, the same flow to the right would serve for instantiation of each of the:
vPCSCF
vSPGW
vEPDG
One particularly challenging aspect of creating a “generic” workflow is handling the data mappings. For an illustration of how such data mappings could be handled for VoLTE, see the attached PPT which shows the approach for a simpler service: vCPE.

22. A&AI Instance Model Behind Alternate VoLTE Use Case Approach
Instances in Inventory After Step 1 of Challenging Scenario
Instances in Inventory After Step 2 of Challenging Scenario
Key
vIMS Service Instance
Instance “A”
vSBCaaS Allotted Resource
Instance “J”
vSBCaaS Service Instance
Instance “C”
vSBCaaS Allotted Resource
Instance “L”
VoLTE Service Instance
Instance “B”
vSBC VNF Instance
Instance “X”