# Enabling the Orchestration of IoT Slices through Edge and Cloud Microservice Platforms
## 3 System Design and Implementation
### Implementation  
The IoT gateway (Edge X Foundry [61]) and IoT server (Mainflux [62]) functions used in the validation environment are implemented using microservice-based architectures. In relation to the orchestration of the IoT functions, the REST interface offered by Kubernetes [20] is used to orchestrate the microservices composing these functions.  
As it was stated before, the IoT slice orchestrator that has been designed to be able to deploy IoT servers and IoT gateways in different locations (edge and cloud). From the implementation perspective, this is done through the command line interface described in Annex A and implementing the information model described in Section 3.1. In this paper, those locations are obviously Kubernetes clusters [20], but it could be any other type of infrastructure for virtual applications. For the microservice installation and initial configuration, Helm [60] is used in both cloud and edge environments.  
It is important to highlight that the Kubernetes cluster does not introduce a significant load that requires powerful and heavy equipment. On the contrary, it can be deployed in constrained devices like Raspberry Pis, which are single board computers with limited computing and storage capacity using Wi-Fi as radio access technology. In fact, this edge environment is configured in several Raspberry Pis (it can even be installed just in one) which could be easily assembled in a SUAV device, in a similar way as it is done by [PERSON] et al in [63]. Therefore, with the orchestrator, it is possible to deploy the IoT gateway in a Raspberry Pi installed in a SUAV device and connect it to an IoT server in a few seconds, even when it is in the air.  
Depending on the requirements, the IoT gateway (or even the IoT server) are deployed either at the edge cluster (at the network edge or at the device edge) or in the cloud Kubernetes cluster. In Figure 4 there is an example where the IoT slice orchestrator creates four slices, where one is entirely created in the cloud (slice 2), two where IoT gateway is deployed at the network edge (slices 1 and 3) and another one where the gateway is installed at the device edge assembled to a SUAV device.  
The IoT slice orchestrator also ensures that the IoT gateway and the IoT server are connected. Nowadays, the underlying connectivity between the pieces of the solution (IoT device to IoT gateway and IoT gateway to IoT server) is assumed to be manually done by configu  
Figure 4: Example of deployment of IoT end-to-end architecture using edge and cloud computing; and network slicing.  
a L3 VPN [64], a GRE tunnel [65] or a VxLAN tunnel [66], for instance. However, in the next phases of the investigation, the IoT slice orchestrator shall be able to configure the connectivity using an SDN controller. Further implementations of the orchestrator will allow the system to integrate with 5G networks, being able to define network slices or making use of pre-established network slices.  
In Figure 4, IoT devices are represented by sensors connected to Raspberry Pis or Arduino boards, which are also single board computers. However, the described system does not preclude from having other more constrained devices and other access technologies like Bluetooth Low Energy [67], ZigBee [5] or any cellular IoT technology (e.g., NB-IoT) [52].