# TSCH Multiflow Scheduling with QoS Guarantees:
## 1 Introduction
### TSCH Schedulers and Protocols
#### 1.2.3 Centralised
The control plane is entirely software-controlled, where a centralised agent, in this case a controller, makes decisions to configure resources and rules in the nodes. The data or forwarding plane are made up of the nodes, which operate in plug and play mode, as it is the controller that sends each node all the necessary instructions to achieve maximum performance. As with all centralised schedulers, in SDN WISE-TSCH [17] message exchange between the nodes and the controller is required. However, as the whole protocol stack is designed for SDN, the topology discovery is optimised, so it does not require the use of the RPL protocol as shown in Figure 2c. For this reason, the control traffic is less than that used by AMUS, which in addition to communication with the controller, requires the use of RPL as shown in Figure 2d. The topology is managed through the following applications:  
* Traffic Manager: This contains the specifications of the different traffic flows, which are classified by priority, deadline, source and destination node. * Routing process: It is responsible for creating the source and destination routes for each flow. It uses as metrics the RSSI and the congestion level of each node which are updated each time a route is assigned. * TSCH Scheduler: For each route it allocates the corresponding TSCH resources, generating schedules that guarantee a minimum end-to-end delay and deadline for each flow. The integration of these three applications allows network slicing, which consists of the differentiation, isolation and logical segmentation of data flows, by means of the allocation of TSCH resources. This slicing makes it possible to guarantee QoS parameters for each data flow independently. The scheduling algorithm is composed of multiple matrices, which are responsible for storing the information of the allocated cells. In this case there are two matrices of the same dimension as the slotframe, one storing all transmitting nodes and one for receiving nodes. It uses the same constraints as AMUS to avoid collisions and interference. In addition, the hops are allocated consecutively, in order to obtain the shortest delay. It also uses the deadline to adapt the flows to the length of the slotframe. For this, repetitions are used, which consist of allocating the resources of the route in different positions of the slotframe. This guarantees the specific bandwidth for each flow and decreases latencies independently of the slotframe length. The steps performed by the algorithm are as follows:  
* Organize the traffic manager flow table by priority and deadline. * Calculate the routes for each of the flow table entries. * For each of the routes, perform a hop decomposition. * Calculate the number of iterations to install over this route, according to the length of the slotframe/deadline. * Perform cell assignment for each hop, where a conflict-free timeslot is sought, i.e., to search in the two matrices for a column where the transmitting and receiving node have no assigned states. * Shifts the next iteration of the route by number of timeslots equal to the deadline and repeats the cell allocation process. To increase flexibility and reduce the number of control packets, the sending of the scheduling is done by flows. This allows transmission of a single packet from the controller to configure a complete route from source to destination. This packet includes the routing and TSCH information. In addition, due to the integrated operation, these processes contain information on the type of traffic to be sent along this route, which allows allocation of dedicated resources for each type of traffic. The main features of each TSCH scheduler are summarised in the Table 1.