# A Lightweight Slice-Based Quality of Service Manager for IoT
## 4 Our Proposed Slice-Based QoS Manager for IoT
### Slice-Based QoS Manager Solution  
A functional SDN gateway is running and capable of fetching data from all proposed wireless technologies devices. Additionally, those devices can be assigned to different network slices (as virtual network partitions) if needed. However, all of them are being given the same connectivity conditions, which might not be the ideal scenario if their production environment is not the same. Hence, the solution  
Figure 9: Overall network architecture. is in need of a component that would be capable of providing each virtual network partition different QoS levels in order to better fit its use case application. Figure 10 represents our proposed slice-based QoS manager solution placement. The solution developed can provide each slice (virtual network partitions) with different QoS levels in order to better fit the application requirements. The Northbound API can program the Data Plane to perform QoS, and because of that, the VM-Application is the machine where the slice-based QoS manager solution takes place. The current solution has several lightweight SDN related running components, which are capable of setting QoS levels in which we have modified the original SDN module of SOFTWAY4 IoT. The network administrator is now able to perform REST API requests in order to install QoS rules. It must be noted that despite all those requests, rules are in reality imposed by OvS and OpenFlow. Hence, the Ryu REST API enables the user to perform requests in order to enable a more straightforward QoS implementation at an OvS and OpenFlow level. However, as the SDN core resides on the controller, the administrator can apply QoS on OvS switches that are connected to the Ryu controller. Taking a closer look at the VM-Application architecture and how it relates to OvS, all information that comes from the bottom layers passes through the VM _eth0_ interface and consequently _br-int_ as well. Each flow is then divided on _br-int_, taking the direction of the bridge that belongs to the destination slice. On that bridge, several ports are placed where they are meant to provide a connection to their application containers. On the other side, it is crucial to understand that policing can be applied on traffic that is entering a given OvS switch. Additionally, it should be noted that _br-int_ is connected to any container bridge through a patch port. OvS documentation claims that bridges that are connected through patch ports behave like  
Figure 10: QoS solution placement. a single one, which translates in the Northbound Interface to being represented by a switch in the QoS manager perspective. It is essential to mention that it could be overcome if it was chosen to implement those rules utilising the Linux Traffic Control (TC) tool [55]. However, as the OvS itself does not take advantage of TC in order to perform its QoS implementations, the implementation of those features that are not currently supported by OvS is not in the scope of our work. With that in mind, considering the current SOFTWAY4 IoT implementation, policing is applied to the port that is meant to provide a connection to the lower layers of the SOFTWAY4 IoT architecture (_br-int_ of VM-Application). Consequently, this kind of traffic limitation affects slices from a single-level perspective, and their traffic splits in order to respect those limits. Nonetheless, traffic shaping QoS rules are going to be applied in ports that allow traffic to egress the Northbound API environment, making sure our developed solution can be actuated in both an application and slice in an independent way. The next subsection explains in detail how our slice-based QoS manager solution can apply QoS rules. While Ryu provides a built-in REST API that enables QoS rules' application, those are implemented by OvS and OpenFlow features. Because of that, despite having different roles, it might be interesting to explain how those tools are put together in order to implement the major QoS models' characteristics.