vOBU: Example of NetApp Design and Development

To showcase how to design and develop a NetApp, the best possible exercise is by doing it with a real NetApp that is being developed in 5GASP: the virtual On-Board Unit (vOBU).

The vOBU NetApp proposes the virtualization of physical vehicle OBUs with the aim to create a MEC layer to offload heavy computational tasks from the vehicle and to serve data-access requests. By doing so, it provides the system with robustness against potential disconnections periods from the vehicle, it saves radio resources on the link and improves the data processing performance.

vOBU NetApp design

The first step to design the NetApp is to analyze the functioning and the architecture of the application or service. The NetApp developer must be able to clearly differentiate the multiple network functions and services that conform the application. The architecture of the vOBU NetApp can be seen below. The vOBU application can be divided in three different NFs, the vOBU itself, the data aggregator, and the vOBU manager. In consequence, they can be interconnected by using a single end-to-end NS, or by using three of them, one for the RAN, one for the MEC, and one for the core network. For simplicity, we will choose the first option.

Figure 1. Virtual On-Board Unit (vOBU) NetApp architecture

Once the number of NSs and VNFs is decided, it has to be discussed the information the NSDs should include, taking into account the requirements of the service. For example, the packaging type or the required hardware resources. Then, the dependencies with other NetApps must be considered. In this case, this NetApp do not have any dependency with other developments.

In the design of the network requirements of the NetApps, the developer has to define the network slices that are needed to host the NetApp, and their characteristics. In this case, the vOBU will simply need one network slice, whose requirements must be included in the NEST template. Some of them can be the isolation level, the 5GPP 5GI slice quality or the maximum PLR.

Finally, the last step of the design phase is the definition of the set of tests that must be performed in the 5GASP platform against the vOBU NetApp in order to ensure a valid functioning and, if successful, resulting in the certification of the NetApp. As the testing procedure and its insights are currently under design and development, here we will focus on simple tests, mainly focused in the infrastructure, that will be used to validate the KPIs of the vOBU NetApp. To this end, a series of infrastructure tests will be defined to evaluate the metrics from which the KPIs are computed. These KPIs are the initial deployment time and the PLR of the messages exchanged between the OBU and the vOBU.

vOBU NetApp development

Once the design phase has finished, the development of the NetApp can start. As the majority of the hard work has been already done in the previous steps, now it is time to reflect it in the multiple descriptors. In the following tables, the NetApp descriptors are shown: the NSD, a VNFD from one VNF of the service, the NEST, and the initial version of the test descriptor, which is still under design and will be enhanced in the next months.

Table 2. vOBU NetApp NSD
Table 3. vOBU NetApp vOBU VNFD
Table 4. vOBU NETAPP’s NEST



Table 5. Initial test descriptor