Neobility is a SME established in 2019 with the vision to revolutionise urban mobility, by developing technologies that support the new wave of urban mobility globally.
Neobility has joined the 5GASP consortium in 2021 as an SME with the goal to contribute to the development and validation of innovative 5G solutions. Through 5GASP, we transitioned our applications to Network Applications, and this post shares our experiences, challenges and achievements. We also contributed to a couple of tutorials in the Community Portal, for a more in depth and “step by step” understanding of the processes.
Before 5GASP, our applications were being deployed in the cloud (“AWS”) using a fully managed container orchestration service provided by Amazon (“Amazon ECS”). This implies that we already have a Dockerfile for each service of our application.
In order to deploy using the 5GASP CI/CD, we had to migrate, from the managed service we used in AWS, to Kubernetes and Helm. So, for the first time, we started working with Kubernetes and Helm, which is a must if you intend to use a container based deployment and not a VM based deployment. A relevant tutorial on how to develop a Helm chart can be found here. Network Application 10’s Helm Chart can be found in this GitHub repository.
The next step was to create the Cloud-native Network Functions (CNFs) and the Network Service Descriptors (NSDs) for our services, in order to be validated and uploaded in OSM. Although not required, since testbeds already have OSM installed, in our case we installed OSM in our local environment in order to better understand and be able to experiment. Although the comprehensive tutorial to install OSM can be found here, we preferred the Charmed OSM installation with “–small-profile” option targeted to deploy CNFs only.
The most straightforward way to develop the CNF and NSD is reading and following the step-by-step tutorial on “How to develop your CNF and orchestrate it through OSM”. If you don’t want (or don’t have) a Helm Chart Repository, then you can follow this tutorial to bundle the Helm chart inside the CNF artifact. Network Application 10’s descriptors can be found in this GitHub repository.
Writing tests was the next step. Robot Framework is used for the test automation, but also a specific 5GASP testing descriptor is used to define the list of Robot tests that need to be run. A tutorial on writing tests can be found here. 5GASP requires two types of tests.
The first type of tests are developer-defined tests. These are tests that the developer writes to test and validate that its services are functioning properly. Examples of developer defined tests can be found in the Network Application 10 GitHub repository.
The second type of tests are the predefined tests. The predefined tests are already written by 5GASP and can be run just by referencing them. All the tests can be found in the CICD_LTR GitHub repository.
Lastly, the testing descriptor needs to be defined. This is done using the 5gasp-cli, choosing a testbed (for example testbed_itav) and choosing the (predefined) tests. A tutorial for creating the testing descriptor can be found here.
The integration with the NEF is the next step. The Network Exposure Function (NEF) is defined as a component of a 5G Core, located between the 5G Core network and the third party application. A more detailed description of the NEF can be found here.
5GASP CI/CD is using a NEF Emulator for the testing of the interaction with the NEF. The NEF Emulator can be found in the 5GASP GitHub repository. In order to integrate with the NEF, you can deploy the NEF Emulator locally (or in your infrastructure) and develop the integration.
To test the NEF integration, 5GASP created the “MiniAPI” (that can be found in the GitHub repository) and the “MiniAPI” tests (which are found in the same CICD_LTR GitHub repository). Network Application 10 also created a custom implementation of the MiniAPI for TypeScript/JavaScript which can be found publicly in this GitHub repository.
The employment of such an API is justified by the need to control the lifecycle of the Network Applications during 5GASP’s testing process. Through the MiniAPI, the CI/CD Service triggers various Network Application-level operations, which allows for the CI/CD Service to control when these operations occur and monitor its outcomes, which will later be validated by the CI/CD Service. After the NEF integration and MiniAPI integration is done, the scripts inside the CICD_LTR GitHub repository can be used to test everything locally.
Finally, the Network Application needs to be onboarded in 5GASP in order to be run on a testbed (or in multiple testbeds) and in order to get the 5GASP Certification Report. The certificate is attached to the Network Application and the artifacts become available in 5GASP’s marketplace. When available in 5GASP’s marketplace, the Network Application becomes available to be seamlessly acquired and deployed by a vertical. More details about the 5GASP Certification Process can be found here and here.
A video on the 5GASP Network Applications Onboarding can be found on the 5GASP YouTube channel here.
In order to be able to onboard your Network Application using 5GASP and get the 5GASP Certification Report you need to contact 5GASP at contact@5gasp.eu.