Brief of the Call Flow Validation Feature Project
The E2E Call Flow Validation project would validate Use Cases defined in a BP based on the standard based messages, APIs, and any other external interfaces published by the BP. This project would use emulators to simulate other necessary peer nodes to perform e2e testing of the System Under Test BP. Since current and upcoming Akraino releases are targeting Application BPs like Network Nodes, VNFs, etc. it is important to test Inter Operability between them to ensure that e2e uses cases are met. This would help the end-user of these BPs to determine the functionality and maturity of a BP. Having clear validation of these kinds of call flows would increase adoption of the BP, hence increase user acceptance. Moreover, Infrastructure level KPIs collected for the BP's would be more relevant if they are done for real use case specific traffic data. Some standard test cases will be provided as default by the Call flow project team, additional test cases can be developed by the BP team members very easily. The Test Case format follows the BDD principles and is based on Opensource declarative language using Gherkin (https://cucumber.io/docs/gherkin/), which is English like, hence it is understandable by anyone with some domain knowledge of the BP.
This project also analyzes the execution data and generates various analytics. The analytic insights help in debugging by identifying expected/published interface specifications against actual while running the use case specific test cases.
Use Case Details
This Call Flow Validation framework provides a capability to ensure that a BP would be able to meet the basic requirements of the Use Cases it's targeting. This is achieved by executing e2e test cases involving the BP and other components of the end solution essential to the usage of the BP. The framework also offers insight into the integration points of peer components with the BP.
Impacted BP:
ICN: In order to validate the ICN NFV Stack BP, it is important to validate its ability to work with a Mobility Core and ensure that some e2e use cases are executed. This will ensure that the stack is compliant with the relevant mobility components.
Private LTE/5G ICN: The LTE and 5G components need to be emulated placed on the Edge network to validate the functionality of the Private Packet Core functions of this BP.
5G MEC Family: BPs like AR/VR, Cloud Gaming, Video Edge Caching, etc. would absolutely need to be validated against advertised Use Case working across Mobile (4G/5G) and Cloud network. Only then users will have confidence in the BP and be interested in adopting it to their solution.
Micro MEC: Successfully and efficiently connecting sensor and light embedded devices far from Telco edge, is an important element of IoT deployment. Micro MEC is an important BP that could enable this. However, validating this BP against embedded devices interface (protocols), Mobility Core, Cloud Platforms and Application Server is essential for the adoption of this BP.
Project Highlights:
| Feature | Description | Examples |
|---|---|---|
| Use Case Validation as per Specifications | Call Flow Validation framework would emulate the components that are necessary to exercise the published API or messages for the BP. This framework has protocol stacks and messages to support 4G and 5G mobility nodes. Besides mobility, this also has support for SSH, and CLI. Additional stacks and associated messages can be added to the framework using published interfaces easily. | |
| Test Cases to validate the E2E Use Cases | E2E test cases are written in an English like, domain specific declarative language following the BDD principles. Being domain-specific to the BP these test cases will be very well understood by any user knowledgable in the BP domain. The BDD declarative language can be processed by Opensource frameworks like Cucumber or Behave. Anyone with the knowledge of the BP, its APIs and message template with other peer nodes will be able to write a test case easily. 4G/5G and CIoT test cases already exist and will be made available. Other test cases can be developed using the template of the ones provided | |
| Node/Component emulator to enable Use Case validation | Components and Network Nodes can be easily developed for emulation and used in the test case using the framework. This is done by implementing the protocol and messages that need to be supported for the purpose of validating the BP and then its incorporated to the protocol layer of the framework | |
| Northbound API | The framework has REST API support for easy integration with any Northbound interface, like OSS, CI engine or an orchestrator | |
| Reporting and Analysis | The framework has the ability to generate execution reports with Call flow ladder diagrams, logs, pcap, and failure analysis for debugging and a better understanding of the use case supported by the BP. It also provides a deeper understanding of the different application-level functions being executed by the test cases and its KPI. Data from different levels of the NFV stack can be correlated and presented for the test cases executed. | |
| Configuring the testbed | The framework has the ability to work as a test orchestrator. Using the Configuration file one can define the deployment configuration of the nodes in the Edge, Mobile, or Cloud networks and execute the test cases to validate the use cases. The test case need not be changed. Hence different Comunity labs can be configured and associated configuration files can be maintained which BPs can use without worrying about the details. |
| Committer | Committer Company | Email address |
|---|---|---|
| Samir K Chatterjee | Rebaca | Samir Chatterjee |
| Srinivasa R Addepalli | Intel | |
| Amar Kapadia | Aarna Networks | |
| Prem Sankar G | Lumina Networks | |
| Pradnesh Dange | Rebaca | |
| Arif Khan | Voereir | Arif |
Presentation: