The telecommunication operators focus on the Internet of Things (IoT) and route the traffic of several clients on a multi-hop infrastructure. Operators need to offer Service Level Agreements (SLAs) to each client, guaranteeing a minimum reliability or a maximum delay for each application. The deterministic IETF 6TiSCH protocol stack is particularly appropriate to provide SLA guarantees, because it allocates dedicated time-frequency blocks for a given traffic. We propose Kausa, a scheduling algorithm to assign a route and allocate resources to each client flow. We optimize the network lifetime while respecting the flow-level requirements. Kausa efficiently deals with lossy links, by scheduling ad-hoc retransmission opportunities. It limits both the buffer occupation and the end-to-end delay. Our simulations mimic multiple scenarios on multi-hop topologies, highlighting the relevance of our approach.

The era of the Internet of Things brings complexity and deployment costs in smart cities, particularly in Wireless Sensor Networks (WSNs). Utilities such as gas or water providers are keen on delegating the management of the communications to specialized firms, namely WSN Operators, that will share the WSN resource among their various clients. WSN operators will use a functional architecture to manage the Service Level Agreements (SLAs), i.e. the Quality of Service (QoS) clauses they contract with their clients. WSN operators will need a robust and reliable technology in order to guarantee QoS constraints in a wireless environment, as in the industrial world. IEEE 802.15.4e Time Slotted Channel Hopping (TSCH) [1] is one good candidate. Moreover, the IETF experience in IP networks management is an important input for monitoring and QoS control over WSNs. This article gives formal guidelines for the implementation of a SLA architecture for operated WSNs. It distinguishes the various formal algorithms that are necessary to operate a WSN according to SLAs, and determines which functional entities are necessarily technology-dependent. Detailed examples of such entities are developed in an IPv6 over IEEE 802.15.4e TSCH context, such as advocated in the IETF 6TiSCH Working Group [2].

The industrial Internet of Things (IoT) relies on multi-hop radio paths. Synchronized nodes follow a Frequency-Time Division Multiple Access (FTDMA) schedule, but even using channel-hopping to mitigate interference, the radio links suffer packet losses. Resource allocation algorithms must consider the requirements of the applications in terms of delivery and allocate extra resource to compensate for anticipated losses. We propose a hop-by-hop allocation mechanism that extends the Traffic-Aware Scheduling Algorithm (TASA) by enabling retransmissions. We give each flow on the network the possibility to satisfy its applicative end-to-end delivery constraint. We keep the amount of resource allocated for retransmissions low, and balance the allocations on the relay nodes. By means of simulations, we show the gain in terms of reliability, and the cost in terms of number of allocations. 1

Smart Cities rely on smart devices connected to the Internet of Things (IoT). The wireless multi-hop networks are a key building block to enable the IoT. We focus on a mutualized deployment, where a network operator offers IoT connectivity to multiple urban clients, with their specific Quality of Service (QoS) requirements. Hence, such a network must guarantee some minimum level of end-to-end delivery ratio and delay, and isolate each traffic from the others. In this paper, we aim at providing the tools to individually monitor and verify the requirements of each client. We propose to use the IETF 6TiSCH stack (IPv6 over the Time Slotted Channel Hopping mode of IEEE 802.15.4e), because it is a promising basis for meeting the latency and packet delivery ratio constraints, and because it intrinsically provides flow isolation. We propose a mechanism that collects the monitoring blocks for each client / application, by piggybacking Information Elements (IEs) onto the data packets. We show that, by using piggybacking, we save up to 45% on the monitoring overhead compared to a traditional approach.