# A Lightweight Slice-Based Quality of Service Manager for IoT
## 4 Our Proposed Slice-Based QoS Manager for IoT
### Data Plane Networking
#### 4.4.2 VI-BLE and VI-LoRa in the SDWI Module  
It is important to notice that SOFTWAY4 IoT uses IP when it comes to the Network Layer of the OSI Model. Therefore, having in mind the BLE and LoRa protocol stack lacking the IP, those technology devices would not be able to properly communicate with the gateway. Hence, the new version of the SDWI module is required to perform the received packets' IP encapsulation and their redirection to the assigned OvS bridge. For that reason, two new components are created, VI-BLE and VI-LoRa.  
All BLE devices use the Generic Attribute Profile (GATT), which can be translated into APIs offered by operating systems that support BLE technology likely being based on its concepts [51]. GATT is built on top of the Attribute Protocol (ATT) and establishes common operations and a framework for the data transported and stored by a generic data protocol [52]. In order to better understand how VI-BLE works, it is necessary to inspect the profile terminology, which works around the server/client relationship and has essentially five important concepts: Client; Server; Profile; Services; Characteristics.  
Because BLE focuses on low power consumption, their devices are not willing to send information by themselves and need to be requested to do so. Hence, the GATT client (VI-BLE on the Host) has the responsibility to start a transaction on the GATT server (a given peripheral device), which suggests a connection interval that the client will respect in order to inspect if any new data are available.  
VI-BLE takes advantage of GATT and one of its Python modules [53] in order to fetch information from the intended BLE devices, using the Host Bluetooth adapter to do so. Because it might be interesting to filter the devices VI-BLE wants to connect to, a JSON file is kept containing a list of MAC addresses. Additionally, that file has a related IP address to each assigned device, which is used to create a Linux virtual interface and consequently send the fetched information to the Gateway upper layers by means of MQTT.  
The used LoRa network architecture is deployed in a star topology in which nodes, gateway, network servers, and application servers are placed. A node collects sensor records and sends them to a gateway by using single-hop wireless communication with LoRa modulation. The gateway is connected to a central network server and acts as a bridge between the node and the network server, converting radio frequency signals into IP packets. The network server determines which data belong to which node and removes duplicated data, redirecting them to the Application Layer. Hence, the applications that reside on the top of the SDN architecture are used to collect and analyse data from nodes [54].  
As might be noticed, in this work solution context, the LoRa network Application Server is represented by the running applications on the corresponding VM. Additionally, the component VI-LoRa joins forces with Arduino LoRa Shield in order to perform not only data interpretation, but also packet IP conversion. Because of that, it is responsible for functioning as both the Network Server and Gateway in the technology network architecture. The nodes are the end devices whose information is fetched from the sensors. The LoRa network architecture and its relation with SOFTWAY4 IoT can be seen in Figure 8.  
The utilised Arduino LoRa Shield device is able to interpret data by itself, and contrary to BLE devices, LoRa nodes do not need to be stimulated in order to send the fetched sensors data. Hence, when a node connects to SOFTWAY4 IoT, both IP and MAC addresses are generated and kept in a small database, which resides inside the SDWI module. After receiving the sensor's information, under the same approach of VI-BLE, VI-LoRa uses MQTT in order to exchange data with applications.