Thank you Eric for the input.
Given the limited time and the current content and format of proposal, I would strongly suggest to separate this proposal from the VoLTE usecase for the following reasons: Firstly, I see it quite different from the VoLTE usecase framework, as its scope is partially virtualized EPC (combination of PNF and VNF), which is completely different in VoLTE usecase with all VNFs for both IMS and EPC. Secondly, in the current proposal there are still open questions to be addressed and it is not following the usecase format (providing flow charts, etc.), while we are expecting to have the VoLTE usecase submitted for review and vote by this week. Hence I would prefer that we proceed with the current VoLTE usecase proposal, while in parallel working on refining the partially virtualized EPC usecase. Thanks, Lingli From: [email protected] [mailto:[email protected]] Sent: 2017年6月1日 22:59 To: 杨艳 <[email protected]>; [email protected] Cc: 'Lingli Deng' <[email protected]>; 'Chengli Wang' <[email protected]> Subject: RE: [onap-discuss] [ONAP] Use Case: VoLTE (vIMS + vEPC) Hello, Sorry for the delay Here is a proposal: The vEPC case Context : extend EPC capabilities with vSGW and vPGW Objective : Demonstrate how to use a hybrid (PNF+VNF) solution using ONAP Version 0: no automatic legacy configuration. Deployment on a single OpenStack data-center based with no SDNC Version 1: only configure legacy MME. Deployment based on a single OpenStack data-center based with no SDNC Version 2: configure the full EPC (legacy+virtualised) functions on 2 OpenStack data-centers using SDNC VNF should be compliant with APP-C and DCAE using Netong/Yang for configuration and VES or SNMP for event collections V0 On-boarding/Design phase The ONAP designer onboards the VNF descriptors, define the Directed Graphs for the 2 VNF and the legacy MME for configuration and defines the service. The ONAP designer defines a simple policy rule: to scale vPGW on the basis of the number of sessions and configure the MME to take into account the new vPGW Open questions: * do we need to describe the PNF in the SDC ? * how to plug the legacy MME management solution to APP-C ? Deployment phase The ONAP-operating deploys the vEPC service. As a result, one vSGW and one vPGW are deployed using SO and APP-C and updating AAI. Closed loop Triggered on a number of sessions, the policy engine executes the rule that triggers the SO to instantiate a new vPGW and will the APP-C to configure both the vPGW and the MME. VNF vendors to be defined VNF open-source available: OAI, openEPC, C3PO Best Regards Eric De : 杨艳 [mailto:[email protected]] Envoyé : mercredi 31 mai 2017 03:53 À : DEBEAU Eric IMT/OLN; [email protected] <mailto:[email protected]> Cc : 'Lingli Deng'; 'Chengli Wang' Objet : 答复: [onap-discuss] [ONAP] Use Case: VoLTE (vIMS + vEPC) Hi Eric, I did not see your reply until today and I would like to confirm whether you have suggestions and inputs for VoLTE Use Case. Any opinions and inputs would be appreciated. Looking forward to your reply. Thanks Yan 发件人: 杨艳 [mailto:[email protected]] 发送时间: 2017年5月25日 10:56 收件人: '[email protected]'; '[email protected]' 抄送: 'Lingli Deng'; 'Chengli Wang' 主题: 答复: [onap-discuss] [ONAP] Use Case: VoLTE (vIMS + vEPC) Hi Eric, Thanks for your questions and I will do some clarification. 1. The open source VNF you mentioned is open source VNF, or vendor VNF? who is responsible for maintaining in the integration test and if needs other VNFs in end-to-end testing? 2. The parser component in Instantiation figure is TOSCA parser which is included in the Modeling project. 3. User sends a request to Portal firstly and not to DCAE.it is just a mistake and we will correct it later. 4. Welcome to provide relevant workflow charts based app-c.For example,instantiation,termination and control loop. 5. Whether the minimum set of EPC scenes contains only two or three VNFs, and if so, it is no longer an end-to-end VoLTE Use Case, and whether need other VNFs.In this case how to do end-to-end business verification, or as a separate VNF to verify? Is there a closed loop control? Thanks, Yan 发件人: [email protected] <mailto:[email protected]> [mailto:[email protected]] 代表 [email protected] <mailto:[email protected]> 发送时间: 2017年5月24日 15:11 收件人: [email protected] <mailto:[email protected]> 主题: [onap-discuss] [ONAP] Use Case: VoLTE (vIMS + vEPC) Hello I would like to clarify some points on the use-case on the mailing-list before clarification on the wiki. For VNF, I believe that we should add a column for open-source based solution. There is a parser component in the Instantiation figure. What is it ? I understand as a TOSCA parser, but it is not described. On the termination call flow, I do not understand why the user sends a request to the DCAE…Why not using the SO directly ? The various call flows are based on VF-C, but why not using APP-C ? The use-case should include minimal vEPC use-case as proposed in MiddleTown (with PGW, MME and HSS). Regards Eric _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
