eindhoven university of technology master dynamic centralized … · mac layer of the osi model. in...

Eindhoven University of Technology

MASTER

Dynamic centralized scheduler for time-slotted channel hopping wireless sensor networks

Naeem, F.

Award date:2016

Link to publication

DisclaimerThis document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Studenttheses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the documentas presented in the repository. The required complexity or quality of research of student theses may vary by program, and the requiredminimum study period may vary in duration.

General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain

https://research.tue.nl/en/studentthesis/dynamic-centralized-scheduler-for-timeslotted-channel-hopping-wireless-sensor-networks(b6d8bc70-5824-4a32-bc57-6ad5a6389150).html

Dynamic CentralizedScheduler for

Time-Slotted ChannelHopping Wireless Sensor

Networks

Master Thesis

Farhan Naeem

Department of Mathematics and Computer ScienceEIT Digital Masters in Embedded Systems

Supervisors:Prof.dr. K.G.W. Goossens

M.L.P.J. KoedamRasool Tavakoli

Eindhoven, August 31, 2016

Abstract

In the increasingly evolving world of technology, communication over wireless medium has becomea very popular choice. Wireless technology is gaining significant grounds in almost every field oflife giving rise to very interesting applications. In the automotive industry there is a significantinterest in converting the in vehicle sensors to communicate with wireless technology. This isbecause of some of the prominent benefits that a wireless network has over wired networks likereduction of weight, freedom from wiring as well as flexibility and ease in maintaining the sensorsand the system. The same is true for other technological domains giving rise to new innovativeapplications in healthcare, environmental monitoring, smart homes and industries.

There are several available wireless standards like Bluetooth,Wi-Fi and GSM. Apart from theseIEEE 802.15.4 standard is especially designed based on the requirements of Low Rate WirelessPersonal Area Networks (LR-WPAN). This standard defines the requirements of the Physical andMac layer of the OSI model. In 2012, an amendment was made in this standard (IEEE 802.15.4e)introducing a new feature named Time-slotted and Channel Hopping (TSCH). TSCH combinestime slots with channel (frequency) hopping scheme. In this way, the wireless nodes not only gaina contention free access to the wireless medium but also are secured from multi-path fading effects.Thus, in this manner wireless communication is made more reliable with reduced packet error bycoping better with contention.

The IEEE 802.15.4e standard only defines how a TSCH network should operate and providesthe basis for the implementation. However the standard does not specify how a list of nodesshould be scheduled to operate within the TSCH network. According to the standard this taskis left for the upper layers of the stack to manage. This thesis work focuses on the design andimplementation of a centralized TSCH scheduler. Provided a list of wireless links with source,destination and bandwidth requirements, the scheduler aims to satisfy not only the bandwidthrequirements but also is able to obtain a contention free schedule, considering the wireless mediumaccess constraints. Moreover, the designed scheduler makes use of Binomial Theorem to computethe probability for a transmission to be successful based on the network quality parameters,e.g. Packet Reception Ratio (PRR). In this way the scheduler is able to respond to run-timevariations in the network communication quality and assign extra timeslots to a link in orderto increase the chances of a successful transmission. The scheduler software library is designedto enable applications running on the CompSOC (Composable and Predictable Multi-ProcessorSystem on Chip) research platform to communicate through wireless medium. However, due totime limitation, the evaluation was done by running the scheduler library on a PC as a Windowsbased application. Furthermore, NXP JN5168 wireless dongles were used as sensor nodes for thenetwork in the evaluation. A small Contiki OS (Real time operating system for wireless sensors)based test application was developed for the JN5168 wireless dongles. The focus of the evaluationwas to observe how the scheduler responds to the changes in average PRR of the network. Furtherthe complexity of the scheduler algorithm was computed and is of the order of O(N3) where N isthe total number of nodes in the network.

Dynamic Centralized Scheduler for Time-Slotted Channel Hopping Wireless Sensor Networks iii

Acknowledgements

With immense pleasure I would like to express my gratitude to all those who have contributedand supported me during the thesis work. I would first express my deepest respect for my thesissupervisor Prof. Kees Goossens who gladly accepted and honored me to be one of his students andmade me a part of his research group. I would also thank him for his continuous support. Next, Iwould like to thank Rasool Tavakoli for all the insights he gave regarding wireless communicationand Martijn Koedam for extending my knowledge in embedded programming.

I would like to thank EIT Digital for providing me the opportunity and honoring me with anExcellence Scholarship to study at two different European Universities (KTH-Royal Institute ofTechnology, Stockholm, Sweden and Eindhoven University of Technology, Eindhoven, Nether-lands).

Last but not least, I would like to thank my parents, siblings and all the friends who have al-ways supported me and motivated me throughout my journey.

iv Dynamic Centralized Scheduler for Time-Slotted Channel Hopping Wireless Sensor Networks

Contents

1 Introduction 11.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 CompSOC Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Background 62.1 Wireless Sensor Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Wireless Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 Wireless Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.3 Terminologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.3.1 Wireless Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.3.2 Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.3.3 Wireless Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.3.4 Transmission Collisions . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Network OSI Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.1 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.2 Data Link Layer or MAC Layer . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.3 Network Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.4 Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.5 Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 IEEE 802.15.4 and IEEE 802.15.4e . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.1 Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1.1 Full Function Device (FFD) . . . . . . . . . . . . . . . . . . . . . 112.3.1.2 Reduced Function Device (RFD) . . . . . . . . . . . . . . . . . . . 11

2.3.2 IEEE 802.15.4 Network Topologies . . . . . . . . . . . . . . . . . . . . . . . 112.3.2.1 Star Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.2.2 Tree Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.2.3 Mesh Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.3 Data Rate and channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.4 Addressing Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.4.1 IEEE MAC Address or Extended Adrress . . . . . . . . . . . . . . 132.3.4.2 Short Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.5 Data Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 IEEE 802.15.4e - TSCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4.1 Key Features of Time Slotted and Channel Hopping . . . . . . . . . . . . . 142.4.2 TSCH Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4.2.1 Timeslots and Slotframe . . . . . . . . . . . . . . . . . . . . . . . 152.4.2.2 Absolute Slot Number . . . . . . . . . . . . . . . . . . . . . . . . . 152.4.2.3 Channel Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4.2.4 Enhanced Beacon . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5 Contiki OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Dynamic Centralized Scheduler for Time-Slotted Channel Hopping Wireless Sensor Networks v

CONTENTS

3 Related Work 19

4 Centralized TSCH Scheduler Implementation 22

4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2 Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3 Hop Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.4 Transmission Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.5 Network Model and Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.6 Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.6.1 Main Resource Manager Array (stRmTable) . . . . . . . . . . . . . . . . . . 25

4.6.2 Neighbour Node Information Array . . . . . . . . . . . . . . . . . . . . . . . 26

4.6.3 Resultant Schedule 2D Array . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.7 System Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.8 TSCH Scheduling Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.8.1 First and Second Hop Neighbor Search . . . . . . . . . . . . . . . . . . . . . 29

4.8.1.1 Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.8.2 Schedule Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.8.2.1 Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.8.2.2 Blocking of slots for links interfering with the reference link Lij . . 32

4.8.2.3 Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.8.2.4 Blocking of unassigned slots in a column for the reference link Lij 33

4.8.2.5 Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.8.2.6 Blocking of slots at same time offset but different frequency channelfor links other than the reference link Lij . . . . . . . . . . . . . . 34

4.8.2.7 Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.9 Generating the Resultant Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.9.0.1 Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.10 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.10.0.1 Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5 Evaluation and Results 40

5.1 Evaluation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2 Purpose of Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.3 Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.3.1 Network Arrangement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.3.2 Data Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.4 Link Schedule for Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.5 Test Software Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.5.1 Firmware Implementation for the End Node . . . . . . . . . . . . . . . . . . 44

5.5.2 Firmware Implementation for the PAN-coordinator . . . . . . . . . . . . . . 44

5.6 Test Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.7 Evaluation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.7.1 Test Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.7.2 Test Scenario 2(a) and 2(b) . . . . . . . . . . . . . . . . . . . . . . . . . . . 48




5.7.6 Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.8 Algorithm Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.9 Tradeoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.9.1 Memory Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.9.2 Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

vi Dynamic Centralized Scheduler for Time-Slotted Channel Hopping Wireless Sensor Networks

CONTENTS

6 Conclusions and Future Work 576.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Bibliography 63

Dynamic Centralized Scheduler for Time-Slotted Channel Hopping Wireless Sensor Networks vii

List of Figures

1.1 Problem Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 CompSOC platform high level overview . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Wireless Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Hidden Node Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Network OSI Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 Star Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5 Tree Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.6 Mesh Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.7 IEEE 802.15.4 frequency bands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.8 IEEE 802.15.4 data frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.9 IEEE 802.15.4 MAC frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.10 TSCH slotframe, ASN and timeslot . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.11 TSCH time slot operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.12 Channel Hopping Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.13 Contiki Process Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1 Hop Neighbors Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2 Transmission Constraint Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3 Main Wireless Resource Manager 4D Matrix Visualization . . . . . . . . . . . . . . 264.4 Example of 2D Neighbour Table for a network with four nodes . . . . . . . . . . . 274.5 High level flow diagram of TSCH scheduler . . . . . . . . . . . . . . . . . . . . . . 284.6 Network Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.7 First and Second Hop Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.8 Assigning a free slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.9 Blocking of Slots at same time and frequency for other links . . . . . . . . . . . . . 324.10 Blocking of unassigned slots in a column for link currently being considered . . . . 334.11 Blocking of slots at same time and different frequency channel for other links . . . 354.12 After completion of algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.13 Final generated schedule in the resultant 2-D Table . . . . . . . . . . . . . . . . . . 36

5.1 Network topology for experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2 Evaluation hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.3 Data Packet Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.4 Time slot allocation for one coordinator and one end node . . . . . . . . . . . . . . 445.5 Time slot allocation for one coordinator and two end nodes . . . . . . . . . . . . . 445.6 End node application flow diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.7 PAN-coordinator node application flow diagram . . . . . . . . . . . . . . . . . . . . 465.8 Test scenario 1 result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.9 Test scenario 2(a) result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.10 Test scenario 2(b) result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.11 Schedule generated after first minute in test scenario 2(b) . . . . . . . . . . . . . . 49

Dynamic Centralized Scheduler for Time-Slotted Channel Hopping Wireless Sensor Networks ix

LIST OF FIGURES

5.12 Test scenario 3(a) result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.13 Test scenario 3(b) result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.14 Schedule generated after first minute in test scenario 3(b) . . . . . . . . . . . . . . 505.15 Test scenario 4(a) result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.16 Test scenario 4(b) result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.17 Schedule generated after first minute in test scenario 4(b) . . . . . . . . . . . . . . 515.18 Test scenario 5(a) result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.19 Test scenario 5(b) result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.20 Schedule generated after first minute in test scenario 5(b) . . . . . . . . . . . . . . 525.21 Memory growth plot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.22 Plot of reliability vs number of redundant slots . . . . . . . . . . . . . . . . . . . . 555.23 Plot of power consumption vs number of redundant slots . . . . . . . . . . . . . . . 565.24 Plot of power consumption vs reliability . . . . . . . . . . . . . . . . . . . . . . . . 56

x Dynamic Centralized Scheduler for Time-Slotted Channel Hopping Wireless Sensor Networks

List of Tables

2.1 IEEE Wireless Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 IEEE Wireless Standards Comparison Table . . . . . . . . . . . . . . . . . . . . . . 72.3 ISM License Free Band . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Related work comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1 TSCH Scheduler Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2 Reliability computation example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1 Contiki OS Driver Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2 Centralized TSCH Scheduler Configuration . . . . . . . . . . . . . . . . . . . . . . 415.3 UART configuration for the JN5168 platform . . . . . . . . . . . . . . . . . . . . . 415.4 Evaluation Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Dynamic Centralized Scheduler for Time-Slotted Channel Hopping Wireless Sensor Networks xi

Chapter 1

Introduction

In the increasingly evolving world of technology communication over wireless medium has becomea very popular choice. Wireless technology is gaining significant grounds in almost every field of lifegiving rise to very interesting applications in domains such as smart cities, industrial applications,railway networks and automotive technology. Considering the automotive domain as an example,vehicles are getting smarter with the advent of technology and according to a recent survey asingle automobile may contain around 70 sensors [1]. These sensors support different applicationslike breaking systems, speed monitoring for cruise control, air-bag, seat belts, lighting indicators,tyre pressure sensors and many more. Communication of data from these sensors is done througha number of in-vehicle communication systems. The in-vehicle communication system is usuallycomprised of a bus based system or protocol like Controller Area Network (CAN), FlexRay andEthernet based wired network [2, 3]. All of the mentioned protocols are wired based. Since thenumber of electronic control units (ECU) within a vehicle is increasing at a rapid pace due tothe emergence of new innovative applications and market needs, this also means that more wiresshall be required to connect various ECU to the bus system. Further emerging applications likecamera based Advance Driver Assistance Systems and infotainment systems usually have a higherbandwidth requirements which shall stress the system [3]. All of this shall lead to a more complexin vehicle communication system with a lot of weight and complexity put up by the wires requiredto connect the system. This shall impact not only the cost of the vehicle but also the fuel con-sumption as well as the effort and time required for the maintenance of such a bulky wired system.

One possible and attractive solution would be to make use of wireless communication technol-ogy. Considering the automotive domain as an example some innovative applications are alreadyin use within vehicles like remote keyless entry and Bluetooth based infotainment and callingsystems. These system can be seen from a user to machine interface perspective. The underlyingcommunication between various ECUs is still wired based. Making the communication wirelessshall significantly reduce the weight, maintenance, time, effort and fuel costs incurred in operatingthe vehicle. The same is true for other technological domains like health, environmental monitor-ing, surveillance systems etc.

The IEEE 802.15.4 wireless standard is widely used in applications and devices with low powerconsumption requirements. This standard has been developed keeping in view the requirementsof wireless personal area networks (WPAN) in home, industry and environment applications [4].Just like Bluetooth technology the IEEE 802.15.4 also operates in the 2.4 GHz ISM frequencyband, but Bluetooth has an edge over the this standard since it makes use of Fast FrequencyHopping Spread Spectrum (FHSS) which makes it reliable and mitigates the effects of multipathfading [4]. The drawback of Bluetooth is that the algorithm is quite complex and might not besuitable for resource constrained low power devices. On the other hand IEEE 802.15.4 standardsupports a wide range of network topology like star and mesh as well, further its complexity is lessand can also operate at lower frequencies in the ISM band (868/915MHz and 2.4 GHz) to meet

Dynamic Centralized Scheduler for Time-Slotted Channel Hopping Wireless Sensor Networks 1

CHAPTER 1. INTRODUCTION

lower data rate requirements and save energy. Extensive research is being carried out to measurethe suitability of using this protocol within vehicles [5, 6].

The latest amendment of the IEEE 802.15.4 standard is called IEEE 802.15.4e [7] and itwas approved and published in the year 2012. This amendment has proposed an enhanced MACfeature which is Time slotted and Channel Hopping (TSCH) for low rate wireless networks. TSCHcombines time slotted access of the wireless medium with frequency or channel hopping to mitigatethe multi path fading effects and downgrading of packet reception ratio (PRR) in the case of alwaystransmitting at a bad frequency channel. A TSCH schedule is assigning of timeslots and frequencychannel offsets to a network link. The IEEE 802.14.5e standard only defines the mechanism bywhich a TSCH enabled node can communicate, it does not specify the policies or methods onbuilding and maintaining a communication schedule [8].

1.1 Problem Statement

Consider a wireless sensor network (WSN) in which each node is connected to a sensor or an actu-ator. The data from these sensors should be gathered in a central node to process the sensor dataand produce appropriate actuating commands. In order to support a large network, the centralnode should have enough processing power to manage and run different applications for this WSN.For this reason, we aim to use a CompSoC as the central possessing unit of this sensor networkin order to run multiple applications without collision and behave in a predictable manner. Onthe other hand communications in this sensor network should be reliable enough to provide therequired quality of service (QoS). For this purpose, as defined in the IEEE 802.15.4e standard, weuse TSCH as the MAC protocol for communication. This protocol uses dedicated timeslots andguarantees that each link in the network gets access to the wireless medium.

As mentioned previously the IEEE 802.15.4e standard does not specify how to create and main-tain a TSCH schedule. Thus, a scheduler is required to assign timeslots and frequency channeloffsets to the network links for communication. Furthermore, since the wireless links are asym-metric and their quality changes over time (due to external interference), the initial assignmentof timeslots and frequency channel offsets may not guarantee the QoS requirements over time.Therefore the scheduler is required to not only make assignments based on the application re-quirements but also be able to make adjustments during run-time based on network link quality.

In this work we aim to design a centralized scheduling algorithm as a library for CompSOCplatform (due to timing limitation the initial prototype was implemented on PC/Laptop serving asthe coordinator node). This scheduler should allocate time slots and frequency channel offsets forreliable TSCH communication between various nodes in the wireless sensor network in accordancewith the IEEE 802.15.4e standard. Furthermore, due to dynamism of network quality in urbanenvironments we aim in designing the scheduler to take into account the network quality variationsand make adjustments during runtime in order to ensure QoS.

2 Dynamic Centralized Scheduler for Time-Slotted Channel Hopping Wireless Sensor Networks


Figure 1.1: Problem Illustration

1.2 Contribution

Based on the discussion above, the thesis work aims

1. To do research on the possible network constraints in order to have a contention free wire-less transmission.

2. Based on the network transmission statistics and bandwidth requirements of an application,designing and implementing an appropriate TSCH link scheduler to dynamically assign requirednumber of time slots to that application for a requested link (source→ destination).

3. Evaluating the scheduler in terms of computation complexity and observing its real-time func-tionality using experiments.

1.3 CompSOC Platform

The CompSOC (Composable and Predictable System on Chip) [9] is a multi-processor researchplatform prototyped on Xilinx FPGA board. The platform can be instantiated by multiple Mi-croblaze 32-bit soft core tiles. For communication between various system resources dAElite [10]Network on Chip (NoC) is used to which various platform tiles are connected as shown in figure1.2. The tiles may be a processor tile, a memory tile or a peripheral tile etc. The main highlightof CompSOC is that it provides composability and predictability. Composability means that ap-plication can run in isolation, independent from other applications. Predictability means that thetiming of applications are well defined and predictable. A detailed discussion about CompSOC



platform resource manager is given in [11, 12]. The requirements for a virtual resource is expressedas a budget descriptor which captures the configuration requirements of an application for a par-ticular resource, for example, the network on chip TDM configuration like source, destination,throughput etc. The same implies for other resources in the CompSOC platform. The resourcesare allocated to an application through a resource manager API available in the CompSOC soft-ware. The resource manager is organised as a state machine in which state transitions is based onthe result of various API calls like reserve, release, program, reset, start and stop.

Figure 1.2: CompSOC platform high level overview

1.4 Outline

The remainder of the thesis is structured as follows. In Chapter 2 we provide a background onIEEE 802.15.4e standard while discussing the relevant concepts on TSCH mechanism, the networkOSI model for WSN and an overview about the Contiki OS. In Chapter 3 we present the detailsof existing TSCH link schedulers available in literature and in the Contiki OS library. In Chapter4 we describe the detailed implementation on our developed TSCH scheduler. In Chapter 5 wediscuss the evaluation results and in Chapter 6 we conclude with a summary and future work.


Chapter 2

Background

In this chapter we provide a background on IEEE 802.15.4 standard and its recent amendment.We also discuss about the relevant concepts on TSCH mechanism, the network OSI model forWSN and also briefly discuss the Contiki OS.

2.1 Wireless Sensor Network

2.1.1 Wireless Sensors

Wireless sensors are resource constrained devices equipped with certain sensors which are dis-tributed throughout the environment of interest to gather data of various events and states. Thegathered data is then transmitted through a wireless medium to a local coordinator or gatewaynode for data processing. These sensors may also play the role of an actuator and receive actua-tion data from other nodes to apply it to the relevant device. The wireless protocol that is useddepends on application requirements and can be based on many available standards for wirelesscommunication. Wireless sensor nodes are becoming a popular choice for data gathering and sens-ing in many technological domains. In the medical world, wireless sensor technology is makingless invasive patient monitoring and remote health care possible [13]. Wireless sensor networks arealso being used by municipalities to monitor utilities like energy and water [13]. Wireless sensornodes provides a low cost solution of monitoring system health and flexibility in managing systemresources. In the automotive domain wireless sensors are widely used in tyre pressure monitoring,remote key-less entry system and in advanced immobilizer systems that prevents engines fromstarting unless an authorized key is inserted into the ignition switch [14]. In short remote moni-toring and sensing using wireless sensors can cover a variety of applications and complement wiredsystems by reducing wiring costs and allowing new types of innovation.

2.1.2 Wireless Network

The wireless sensor nodes cooperate with each other to form a network. In order to communicatein a systematic manner, there are several wireless standards which defines the appropriate proto-col (packet format and transmission mechanisms) keeping in view various application needs likebandwidth, power consumption, reliability, etc. Some of the well known wireless standards areshown in table 2.1.

A comparison of different wireless standards in terms of power consumption, complexity, costand data rate is shown in table 2.2. For Low Rate Wireless Personal Area Network (LR-WPAN)the best choice of standard is IEEE 802.15.4, because of its low communication overhead, smallpacket size, low energy consumption as well as low cost.


CHAPTER 2. BACKGROUND

Before we further discuss about IEEE 802.15.4 standard and its amendment for LR-WPAN indetail, it would be good enough to discuss briefly about some terminologies related to wirelesscommunication.

IEEE Wireless Standard Description802.15.1 Bluetooth802.15.2 Address the coexistence of WPAN

with other technologies802.15.3 High Rate WPAN802.15.4 Low Rate WPAN802.15.5 Mesh networking

Table 2.1: IEEE Wireless Standards

LR-WPAN Bluetooth Wireless LANRange 10-30m 10-100m 100m

Data Throughput 0.25MBps 1 MBps 2-11 MBpsSize Smallest Smaller LargerCost $1 $10-$15 $40

Table 2.2: IEEE Wireless Standards Comparison Table

2.1.3 Terminologies

2.1.3.1 Wireless Nodes

A wireless sensor within a network will be referred to as a wireless node. A wireless sensor node caneither only be used for sensing data or for routing data to a destination which is out of the rangeof the source node by making use of appropriate network layer protocols optimised for wirelesssensor nodes like RPL [15] or Rime [16]. Sometimes a wireless node can perform both the sensingand routing.

2.1.3.2 Network Topology

The arrangement of wireless sensor nodes that suits a specific application in its working envi-ronment is referred to as the network topology. The network topology indicates the networkco-ordinator or gateway, the end devices and also shows possible connections between differentnodes and their neighbors.

2.1.3.3 Wireless Link

In a wired communication medium there is a dedicated link or wire available between two com-municating nodes. However in the wireless medium the concept is somewhat different. A wirelesstransceiver is usually equipped with a single antenna and can either transmit or receive at a time.In order to establish a wireless link, two important conditions needs to be satisfied. Firstly, thenodes that wish to communicate must be within the communication range of each other. Secondly,in order to communicate, the nodes must be tuned to the same frequency. In figure 2.1 the reddashed circle indicates the communication range of node A. Node A is tuned to a frequency say XHz. Node B, D and E are within the communication range of node A. However since nodes D andB are tuned to the same X Hz frequency as that of node A, so only these nodes would be able topick up signals from node A. On the other hand, node E although is within the communicationrange of A, would not be able to hear transmissions from node A since it is tuned to a differentfrequency Y Hz. Furthermore, node C would not be able to hear any transmission from node A,



since it lies outside the communication range. Based on this discussion we can say that when twonodes are able to communicate directly at a particular frequency, a wireless link exist betweenthem.

Figure 2.1: Wireless Link

2.1.3.4 Transmission Collisions

Transmission collisions can occur in a wireless transmission communication. Data from two nodestransmitting at the same time and frequency will collide at the third node also tuned to the samefrequency. This is shown in figure 2.2. Node A, B and D are tuned to the same frequency X Hz.If node B is in the reception mode and both the nodes A and D transmit a packet to node B atthe same time, the packets shall collide at the receiver of node B and cause corruption. This issometimes referred to as hidden node collision or hidden node problem. It can be seen that bothnodes A and D are out of the communication range of each other, however node B lies in therange of both. Node A or D would not be able to know who shall be transmitting first which isthe reason of collision. Implementing software schemes like RTS/CTS [17, 18] and contention freetransmission mechanism such as TDMA (Time Division Multiple Access) must be used.



Figure 2.2: Hidden Node Problem

2.2 Network OSI Model

The Open System Interconnection (OSI) [19] model which was proposed by International Organ-isation for Standardisation forms the basis of the wireless sensor network protocol stack. Theoriginal model comprises of seven layers but since wireless sensors are resource constrained onlyfive layers are sufficient as shown in figure 2.3. Following is a brief description of each of the fivelayers of the stack. It should be noted that each layer in the stack is assigned a specific set oftask (layer specific algorithms like routing, etc) which it performs independently. However someinformation sharing between layers is also possible.

(a) 7-Layer OSI Model (b) WSN Protocol Stack

Figure 2.3: Network OSI Model

2.2.1 Physical Layer

The physical layer is responsible for defining and managing the connections between individualdevices and their communication medium. The physical layer is responsible for frequency selection,carrier frequency generation, signal detection, and modulation and data encryption. All of thesetasks are related with the transceiver [20].



2.2.2 Data Link Layer or MAC Layer

The data link or MAC (Medium Access Control) layer is responsible for implementing mechanismby which multiple nodes can be allowed to access the medium. In order to avoid collision duringtransmissions, only one node should be able to transmit at a given time and frequency channel.It is the responsibility of the MAC layer protocol to regulate the access of the frequency channel.Furthermore, this layer also implements certain error correction and error detection schemes. TheIEEE 802.15.4 is a Physical and MAC layer standard specifying the requirements and implemen-tation of both of these layers. [20]

2.2.3 Network Layer

The network layer is mainly responsible for routing and establishing communication paths fromsource to destination by implementing certain routing algorithms. It should be noted that certainnetwork topologies do not require a network layer for instance a star topology network, it is becauseall the end nodes communicate directly with the central node and a star network is essentiallya single hop network. Since IEEE 802.15.4 is a Physical and MAC layer standard, to enablefull routing capabilities, standards and protocols such as ZigBee, RPL(Routing Protocol for Low-Power and Lossy Networks) [15] and Rime [16] can be used for nodes using IEEE 802.15.4 asits PHY/MAC layers. Extensive research is also being conducted in the development of 6TiSCHstack which is enabling internet connectivity over IEEE 802.15.4 PHY and MAC standard [20].

2.2.4 Transport Layer

The transport layer is mainly responsible for providing transparent and reliable communicationbetween the source and destination nodes. It comprises of some of the well known protocols likeUDP and TCP [20].

2.2.5 Application Layer

The application layer usually involves the user application which could be some kind of sensing orprocessing application. It can also request information from lower layers to make certain decisionsor to check whether enough resources are available to meet application requirements [20].

2.3 IEEE 802.15.4 and IEEE 802.15.4e

In order to make systems manufactured and developed by various vendors to operate and interactwith each other, certain standards needs to be followed or realized. IEEE 802.15.4 is an exampleof such a standard for Physical and MAC layer. This standard is designed for Low-Rate WirelessPersonal Area Network (LR-WPAN) in which applications require low data throughput and deviceshave low computational resources. This standard lays down the specifications for only the Physicaland MAC layers of OSI model. This standard is a popular choice for low power applications. Inthis section we shall explain the main concepts of IEEE 802.15.4 standard protocol and thendiscuss about the important features introduced in the IEEE 802.15.4e amendment.

2.3.1 Devices

According to the IEEE 802.15.4 standard, there are two types of devices that can be a part ofsuch a network. One is the Full Function Device (FFD) and the second one is Reduced FunctionDevice (RFD).



2.3.1.1 Full Function Device (FFD)

A full function device implements the complete protocol stack. It can serve as the Personal AreaNetwork (PAN) coordinator and manage the network like initiating the network, accept associationrequests, etc. It can also function as coordinator only node, that does everything except initiatinga network. An FFD can talk to other FFDs and RFDs.

2.3.1.2 Reduced Function Device (RFD)

A reduced function device is implemented by limited resources and reduced protocol stack. Itsmain task is sensing related. It cannot serve as PAN coordinator and usually is the end device ina network topology. A RFD can only talk to a FFD.

2.3.2 IEEE 802.15.4 Network Topologies

IEEE 802.15.4 supports a variety of topologies like star, tree, cluster tree and mesh. It shouldbe noted that a network must at least contain two nodes and one of it should act as a PANcoordinator.

2.3.2.1 Star Topology

In a star topology there is only one PAN coordinator which is a full function device and is sur-rounded by remaining end devices of the network. In this topology, the end devices can onlycommunicate with other end devices through the PAN coordinator. The application software inthe PAN coordinator device is responsible to relay the message to the appropriate end device.

Figure 2.4: Star Topology [21]

2.3.2.2 Tree Topology

In a tree topology, each node has a parent child association except the PAN coordinator that hasno parent. The end devices are at the last level of the tree and does not have any children. Everynode can only talk to its parent or its children. A parent node can act as a local coordinator ofits children as shown in figure 2.5 marked in red.



Figure 2.5: Tree Topology [21]

2.3.2.3 Mesh Topology

In a mesh topology the nodes are placed without any specific network structure. The devices cancommunicate directly with each other and there may be more than one path from a source nodeto the destination node. However there must be at least one PAN coordinator to manage thenetwork.

Figure 2.6: Mesh Topology [21]

2.3.3 Data Rate and channels

The IEEE 802.15.4 operates in the ISM (Industry, Scientific and Medical) license free band. Thisband is divided into three frequency ranges each with multiple channels as shown in table 2.3.Further, in theory the achievable maximum data rate is 250 kbits/sec when operated at a fre-quency of 2.4 GHz. However in practice due to asymmetric links packets may be dropped andretransmissions may occur. According to the calculations made by NXP in its IEEE 802.15.4 stackguide [22] with a PER (Packet Error Rate) of 25% and only one retransmission allowed, the datarate comes out to be 101 kbps.



Frequency Band Number of Channels Data Rate kbps868 MHz 1 20902 MHz 10 402.4 GHz 16 250

Table 2.3: ISM License Free Band

Figure 2.7: IEEE 802.15.4 frequency bands [23]

2.3.4 Addressing Modes

According to the IEEE 802.15.4 standard, devices participating in a network have two types ofaddresses as follows.

2.3.4.1 IEEE MAC Address or Extended Adrress

This is a 64-bit address assigned by device manufacturers according to the IEEE standards anduniquely identifies a device. No two devices in the world can have the same address.[21]

2.3.4.2 Short Address

This is a 16-bit address and is used to uniquely identify a node within a network. This addressis local to the network which means that two nodes operating in two different networks can havethe same short address. The short address is normally allocated by the PAN coordinator orcoordinator of the network to which the end node wishes to associate.[21]

2.3.5 Data Frame Structure

The data frame structure of the IEEE 802.15.4 PHY/MAC standard is shown in figure 2.8. Itcan be seen that the packet is divided into several sections. The synchronization header (SHR)contains a preamble sequence of 4 bytes. The SHR is to enable the receiver to synchronize withthe incoming signal or packet. The start of frame delimiter signals the end of preamble after whichthe actual data packet starts. The MPDU is the MAC protocol data unit which is parsed by theMAC layer. A detailed figure of the MPDU structure is shown in figure 2.9. The maximum sizeof the MAC layer packet is 127 Bytes out of which the maximum data payload that a MAC framecan contain is 102 bytes and the remaining 25 bytes contributes towards the header of the packet.



Figure 2.8: IEEE 802.15.4 data frame[24]

Figure 2.9: IEEE 802.15.4 MAC frame[7]

2.4 IEEE 802.15.4e - TSCH

The IEEE 802.15.4 PHY and MAC layer standard was first introduced in the year 2003. Withthe advent of technology, the demands of various applications increased in terms of low powerconsumption, reliability and latency. In order to meet these requirements and introduce newconcepts and features into the already existing IEEE 802.15.4 standard a new working group wasformed in 2008 (Task Group 4e) to propose amendments in the previous standards to better suitthe industrial requirements. The amendments were published by the name IEEE 802.15.4e [7] inthe year 2012. The unique key feature of this amendment is the introduction of the concept ofTime slotted and channel hopping (TSCH) communication. TSCH is very effective in mitigatingmulti path fading and interference at a particular frequency. The standard describes how TSCHworks, however creating a TSCH schedule has been left open since it depends on the applicationrequirements and network topology.

2.4.1 Key Features of Time Slotted and Channel Hopping

Following are some of the highlights and benefits in combining channel hopping scheme with timeslotted access

1. Time slotted access enables the nodes to communicate and access the physical medium atfixed intervals or slots in time. This reduces collisions and ensures a contention free access.

2. Transmitting data using different channels at the same time increases the capacity of thenetwork and reduces delays.

3. Using multiple channels for each communication reduces the multi path fading effects andinterference due to various environmental conditions. This increases the reliability of the commu-nication.



2.4.2 TSCH Concepts

Following are some of the important terminologies and concepts related to TSCH.

2.4.2.1 Timeslots and Slotframe

In TSCH a frequency or a channel is sliced into multiple slots in time which is called a time slot.Combining multiple time slots forms a slotframe. Each slot is assigned to a source and destinationnode pair. A source node transmits at its assigned slot and the destination node wakes up in thereceiving mode in that slot. If a packet is dropped the re transmission occurs in the time slot ofthe next slotframe. A timeslot duration is long enough to transmit a packet of maximum payloadsize and to receive the corresponding acknowledgement. Typical duration of time slot is around10 msec but it can be configurable and depends on the hardware platform and application require-ments. For instance the T-mote sky hardware requires the TSCH time slot to be of atleast 15 msec.

According to the IEEE 802.15.4e standard a network can contain more than one slotframe eachcontaining different number of timeslots. In that way a network can cope with different bandwidthrequirements. The one with less time slots providing more bandwidth and much lower delay intransmission of the packet.

A slot in a slotframe can be marked as transmit only, receive only and shared. In transmitonly slot the transmitting node cannot receive a packet in case the transmit buffer is empty. In areceive only slot the node assigned is only allowed to receive and not transmit. If a slot is markedshared it means more than one nodes are allowed to transmit at the same time and frequencychannel, however this might cause collision which is resolved by using an exponential back-offretransmission algorithm called TSCH CSMA-CA [7]. Further a link may be assigned more thanone time slot in a slotframe.

2.4.2.2 Absolute Slot Number

Each slot in the slotframe is marked with a unique slot number called the absolute slot number(ASN). The ASN is used to have a global view of the current time slot in the network and helpsin synchronization for nodes that wants to join a network. The ASN is continuous and does notreset after a slotframe ends. It can be viewed as the total number of timeslots elapsed since thestart of the network.

Figure 2.10 shows an example schedule containing a single slotframe with four time slots. Therows represents two different channel offsets. It can be seen that a link (source → destination)can be assigned more than one time slots in a frame, e.g. C → D marked in red. It can also beseen that two different links can simultaneously be allowed to operate in a shared slot, e.g. A→ Dand E → F in ASN 2 marked in orange.

Figure 2.10: TSCH slotframe, ASN and timeslot



Figure 2.11 shows the time slot operation in a TSCH based network. It can be seen that ineach timeslot, the receiving node starts sensing the channel for packets after the startup time haselapsed. After the guard time elapses the transmitting nodes starts transmitting. In a TSCHnetwork, the transmitting node waits for an acknowledgment from the receiving node at the endof transmission. If an acknowledgement is not received within a defined time, then the packet isretransmitted at the next time slot allocated to the same sender-receiver pair. It should be notedthat in case of a broadcast link the sender does not wait for an acknowledgement.

Figure 2.11: TSCH time slot operation [25]

2.4.2.3 Channel Hopping

According to the IEEE 802.15.4e standard there are 16 channels that can be used for communica-tion at 2.4 GHz frequency. Depending on national legislation, not all channels might be availableto use. Each frequency channel is identified by a channel offset. Each transmission takes placeat a different frequency channel, which is picked up from a list of channels called the hoppingsequence list. The hopping sequence list may include a subset of those 16 available channels withgood communication conditions that can be obtained from different measurement techniques. Thefollowing equation is used to compute the next transmission channel. In order to ensure that com-munications take place at all the available frequency channels in the channel hopping sequencelist, the number of time slots in a slot frame (or the slotframe size) must be relatively prime to thelength of the channel hopping sequence list [8]. Figure 2.12 shows an example of channel hoppingscheme.

CH = HoppingSequenceList [(ASN + channeloffset) % macHoppingSequenceLength] (2.1)

Figure 2.12: Channel Hopping Example [26]

2.4.2.4 Enhanced Beacon

Enhanced Beacons (EB) are special beacons which a PAN or simple coordinator transmits atregular intervals to advertise about the network. A device can detect an EB by looking at the



frame version field of the packet since for an EB it is set to 0x0b10 (Hex) [7].The EBs containimportant information regarding the network, such as the current TSCH schedule, number ofslotframes, slotframe size, current ASN and schedule information of the links (timeslot and channeloffset). This information is important for a newly joining end node to smoothly integrate withthe network.

2.5 Contiki OS

Contiki [27] operating system was designed for resource constrained devices like wireless sensornodes. The latest stable version 3.x [28] also includes the implementation of TSCH according tothe IEEE 802.15.4e standards. Contiki OS supports a wide variety of radio enabled platforms. Itslibrary includes a complete TCP/IP stack for radio network communications. Some of the wellknown IETF (Internet Engineering Task Force) network and application standards implementedin its library are 6LowPAN, TCP, UDP, RPL, CoAP and IPv6 [28]. The Contiki OS has beenimplemented using the C language. It has an event driven kernel which is used to load and unloadprocesses at runtime [27]. Contiki applications are created using processes. Processes in Contikican be either cooperative or preemptive [29]. A cooperative process continues execution until ithas finished before another cooperative process can start execution. However in case of occurrenceof an interrupt from an external source or any timer expiration the preemptive code shall preemptthe currently executing cooperative process which shall be spawned back upon completion of thepreemptive code. In addition to this, Contiki also supports multi threaded message passing inthe form of event generation or process polling instructions. Figure 2.13 shows an example ofexecution of a Contiki process. In the figure it can be seen that process B cannot start untilprocess A completes its execution at time t1. It can be seen that while process B is executing,an interrupt occurs at time t2. At this point process B is preempted and the interrupt serviceroutine (ISR) is executed. After the ISR is executed, process B resumes its execution.

Figure 2.13: Contiki Process Example [29]


Chapter 3

Related Work

IEEE 802.15.4e standard is relatively a new concept. As mentioned earlier this standard specifieshow a TSCH based network should be executed, however the creation of Tx/Rx schedule, whichis the assignment of time slots and frequency offsets to different network links, has been left to behandled by the upper layers of the OSI stack. Since the publishing of IEEE 802.15.4e standard in2012, researchers have been investigating different methods for generating suitable schedule basedon different application requirements. The algorithms proposed to compute a TSCH schedule canbe classified into two categories, the decentralized or distributed approach and the centralizedapproach.

In centralized approach, a central management node, usually the PAN coordinator, is in chargeof computing and maintaining the schedule. The PAN coordinator in this case needs to have aglobal knowledge about the network topology, which includes the required links between differentnodes, traffic requirements and application specific configuration information [25]. Fiore et al. [30]proposed a multiple channel scheduling algorithm for WirelessHART multi-hop networks. Wire-lessHART [31] is a wireless extension of HART protocol suite for industrial networking devices.WirelessHART also makes use of TDMA scheme like TSCH. Fiore et al. [30] proposed an algo-rithm which assigns the first available channel and time slot to the link currently being considered,however Palattella et al. [32] suggested that this kind of approach might not meet the require-ments of industrial IoT applications. Palattella et al. [32] on the other hand proposed a trafficaware centralized scheduling algorithm for IoT based applications. The highlight of this scheduleris that it assigns timeslots and frequency based on the traffic of packets generated by each nodewhich is computed before hand using graph coloring techniques. The centralized approach is moresuitable for static networks in which the number of nodes and required links are known beforehand.

In decentralized or distributed approach the network nodes forms a TSCH schedule tablebased on local information. Each node in the network has a table of its own. This kind of ap-proach is suitable for moving/mobile networks in which nodes might join and leave the networkquite frequently. Tinka et al. [33] and Accettura et al. [34] have made contributions in proposingdistributed scheduling mechanisms for IoT applications. Orchestra [35] is also a distributed sched-uler, which is designed for RPL (Routing Protocol for low power lossy networks) based TSCHnetworks. In Orchestra the nodes maintain their schedule autonomously based on their RPLparents and neighbors. In Orchestra multiple slotframes of different lengths are available. Eachslotframe is dedicated for a specific type of traffic like TSCH Enhanced Beacons, RPL traffic orapplication data. Each node in the network select slots based on some predefined rules whichare Common Shared Slot Rule, Receiver Based Shared Slot Rule and Sender Based Shared SlotRule. These scheduling rules are designed to reduce contention and to adapt to dynamic networks.

The above mentioned centralized and distributed schedulers were implemented specifically forthe IoT applications in which RPL (Routing Protocol for low power lossy networks) is used at


CHAPTER 3. RELATED WORK

the network layer. Furthermore, Orchestra [35] (software library available in the latest ContikiOS release), as described above, considers a tree like topology and is coupled with IPv6 net-work layer library of Contiki OS. Moreover, the scheduling techniques described above do notconsider the dynamism of the wireless medium, instead it only takes into account the amount ofdata traffic that each node generates and apply different rules or techniques to generate a schedule.

Our aim in this thesis is to implement a centralized TSCH scheduler that 1) takes into accountthe bandwidth requirement of applications, 2) can function independent of network topology and3) takes into account the changes in network link quality and adjusts the schedules dynamically.This work involves not only the development of scheduler software but also extensive modificationin the Contiki OS TSCH library files to make it compatible with our design. The novel feature inour approach is that our designed scheduler is able to respond to network link quality variationsby using Binomial theorem to compute the probability of a successful transmission. In this waythe scheduler is able to adjust the TDMA timslots and channel offset assignments of network linksin order to increase the chance of a successful transmission. The related work is summarised intable 3.1.

Related Work Scheduling Mechanism Network Topology Network Layer Network Link Quality ConsiderationTASA [32] Centralized Independent IPv6 with RPL only No

Work by Fiore et al. [30] Centralized Independent WirelessHART network layer NoOrchestra [35] Distributed Independent IPv6 with RPL only No

DeTAS work by Accettura et al. [34] Distributed Independent IPv6 with RPL only NoDynamic TSCH scheduler (Thesis Work) Centralized Independent Tested with Rime network layer in Contiki OS Yes

Table 3.1: Related work comparison


Chapter 4

Centralized TSCH SchedulerImplementation

In this section, we explain the implementation of a centralized TSCH scheduler in detail.

4.1 Requirements

Following are the requirements for the scheduler.

1. Given a list of links with source and destination addresses alongwith bandwidth requirements,the scheduler should be able to assign suitable timeslots and channel offsets to each of the linksin the list. Furthermore, the scheduler must take into account the network wide reliability metricassigned by the developer based on certain application standards, for maintaining QoS, while as-signing slots to the links.

2. The scheduler must function independent of the network topology.

3. The scheduler must take the constraints for contention free transmission into account.

4. The scheduler must be able to take into account the network quality variations and adjustthe allocated time slots accordingly in order to satisfy the QoS metric. This can be done byre-running the scheduler during runtime at regular intervals.

4.2 Design Considerations

Following are some of the key design consideration that were made.

1. As mentioned earlier in chapter 3, the TSCH scheduler can be of two types, centralized ordistributed. In our implementation we selected to proceed with a centralized approach since weare considering static networks with predefined parameters and are not dealing with mobile ormoving networks initially.

2. In order to maintain a global view of network timeslot and frequency channel allocations,the central management node makes use of a 4D matrix implemented in software, which storesthe global schedule information. This implementation might be memory inefficient but is rathereasy to operate on and manage in software. An efficient approach is to use linked list which shallsave memory but would increase the software coding complexity.


CHAPTER 4. CENTRALIZED TSCH SCHEDULER IMPLEMENTATION

3. In order to store the first and second hop neighbor of each node, a 2D matrix is used withappropriate structure fields. This information will help in creating a schedule.

4. In order to share the schedule with the end nodes, the final generated schedule is storedin a 2D matrix with link information. The dimension of each cell in the matrix is represented bya timeslot and channel offset.

5. The algorithm is implemented considering only one slotframe. However the IEEE 802.15.4estandard specifies that more than one slotframe can also exist in the same network. This featurecan be considered as a future work.

4.3 Hop Neighbors

Neighbor information is very critical in wireless sensor networks. It is used by MAC layer protocolsto decide which node is allowed to access the wireless medium at a particular time instant. Fur-thermore, this information is also used by network layer protocols in determining the routing path.

In our scheduler design we are typically interested in information about nodes that can bereached in two hops. A node n is said to be a First Hop Neighbor of a node m, if node n lieswithin the communication range of node m and a direct link can be established between node mand node n. On the other hand a node n is said to be a Second Hop Neighbor of a node m, if noden lies outside the communication range of node m but it can be reached through one intermediatenode y. In this case a direct link can be established between node m and node y as well as betweennode n and node y. However there is no direct link between node m and node n. Node m canonly communicate with node n through node y. This is illustrated in figure 4.1. It can be seenthat for node m, node y is the first hop neighbor and node n is the second hop neighbor. For noden, node y is the first hop neighbor and node m is the second hop neighbor. However, node y onlyhas two first hop neighbors which are node node m and node n.

Figure 4.1: Hop Neighbors Example



4.4 Transmission Constraints

Following are the transmission constraints that needs to be taken into account in order to obtaina contention free schedule.

1. When a node n wishes to transmit a packet, none of its first hop neighbors should be transmit-ting at the same time and the frequency channel offset that is used by node n. This is sometimesreferred to as Neighbouring Node collision. For example in figure 4.2, if node n wishes to transmitdata to node y and node m wishes to transmit data to node p, then node m should not be trans-mitting at the same time and frequency channel as that of node n. This is because it may corruptthe data at node p, since node p can directly listen to both node n and node m. The arrows in thefigure between two nodes indicates that a wireless link exists and direct communication is possiblebetween the two nodes.

2. When a node n wishes to transmit a packet, none of its second hop neighbor should betransmitting at the same time and the frequency channel offset that is used by node n. For ex-ample in figure 4.2, if node y wishes to transmit data to node n and node m wishes to transmitdata to node p, then node m should not be transmitting at the same time and frequency channelas that of node y. This is because it may corrupt the data at node n, since node n can directlylisten to both node m and node y. In this example node m and node y are second hop neighborsof each other.

Figure 4.2: Transmission Constraint Example

4.5 Network Model and Notation

The main aim of the scheduler is to assign frequency channel offset and timeslots to all the links inthe network, irrespective of the topology. Let us denote the total number of nodes in the networkto be N. Each node in the network is uniquely identifiable with 64-bit address or a 16–bit shortaddress as indicated in the IEEE 802.15.4 standard. For simplicity we denote an individual nodewith ni where 0 ≤ i < N. We denote a link between two nodes as Li,j where i, j ; 0 ≤ i, j < N.Li,j indicates a link from source or transmitting node ni to destination or receiving node nj. Itshould be noted here that a link comprises of a pair of nodes; a source node and a destination nodeand the destination node may not be the final destination of a data packet. It is the job of thenetwork layer to include appropriate routing protocols to route packets to the final destination.



The scheduler algorithm shall mainly work around the link information. Furthermore, consideringa TSCH network, let S be the slotframe size and tk be the kth timeslot where 0 ≤ k < S. LetF be the total number of frequency channels available and fm be the frequency channel at offsetm where 0 ≤ m < F. We also denote the main resource manager 4-D matrix as Mrm and eachindividual cell as msdft, where s,d,f,t ∈ N and s,d ≤ N (total number of nodes in the network),f ≤ F (total number of frequency channels) and t ≤ S (slot frame size). Let us denote the 2-Dneighbor information matrix as Mnegh and each individual cell as mqr(negh), where q, r ∈ N and q,r ≤ N (total number of nodes in the network).

The notations are summarised in table 4.1.

Notation DescriptionN Total number of nodes in the networkni i-th node in the network

Li,j Link between source node ni to destination node nj

S Slotframe sizetk kth timeslot in the slotframeF Total number of frequency channelsfm Frequency channel at offset m

Mrm Main 4D resource manager matrixmsdft A cell of 4D resource manager matrixMnegh Neighbour information matrix

mij(negh) A cell of neighbour information matrixMres Resultant 2D schedule matrix

mqr(res) A cell of resultant 2D matrixTtimeslot Duration of timeslot in millisecondsTslotframe Total duration of slotframe in milliseconds

Psize Size of data payload generated by applicationPperiod Interval at which packet is generated

Table 4.1: TSCH Scheduler Notation

4.6 Data Structures

In this section we, will describe the data structures that were used in order for the scheduler tomake computations.

4.6.1 Main Resource Manager Array (stRmTable)

The main TSCH schedule is visualized in the form of a 4D matrix or array. This array is meantfor the coordinator of the network (PAN) and contains the global view of the schedule of thewhole network. It is arranged as stRmTable[Source Node ID][Destination Node ID][FrequencyChannel Offset][Time slot]. The first dimension indicating source node ID, the second dimensionindicating the destination node ID, the third dimension indicating the frequency channel offsetand the fourth dimension indicating the time slot. The TSCH scheduler operates on this arrayand stores or marks the schedule for different links based on source and destination IDs. Eachcell of the array is marked by an Enumerator type NO LINK, FREE, OWNED and BLOCKED.If there is no link between two pair of nodes, then all the frequency and timeslot indexes forthe corresponding source and destination node IDs in the array are marked as NO LINK. Forexample if there is no link from node id 2 to node id 3, then in the resource manager matrix Mrm

the cell msdft = NO LINK where {s = 2, d = 3, ∀f,t | f ≤ F and t ≤ S}. Similarly if there isa link between two nodes, then initially for all the channel offsets and timeslot indexes for the



corresponding source and destination node IDs the cells are marked as FREE. When a slot isclaimed, it is marked as OWNED and when it is blocked due to certain transmission constraints,it is marked as BLOCKED. In this array the cells with same source and destination ID are reservedfor broadcast links. For example if node ID 2 wants to have a broadcast link then all those cellsmsdft shall be used such that s = 2, d = 2, ∀f,t | f ≤ F and t ≤ S. Figure 4.4 shows a visualizationof the 4D matrix for a system configured with four source,destination,frequency channel offsetsand timeslots.

Figure 4.3: Main Wireless Resource Manager 4D Matrix Visualization

//! Enum to indicate status of each cell in the resource manager matrix

typedef enum

{

NO_LINK , //! No Link exist

FREE , //! Slot not allocated

OWNED , //! Slot owned by a <src ,dest > pair

BLOCKED , //! Slot blocked because of constraints

}RM_TABLE_ENUM;

typedef struct

{

RM_TABLE_ENUM enSlotState; //! Slot State

LINK_ATTRB_STRUCT_RESULTANT unBlockedBy; //! To indicate which link blocked the

cell

}RM_STRUCT;

static RM_STRUCT stRmTable[MAX_NUM_OF_NODES ][ MAX_NUM_OF_NODES ][ MAX_NUM_OF_FREQ_CHNL

][ MAX_NUM_OF_TIME_SLOTS ];

Listing 4.1: Wireless Resource Manager 4D matrix and supporting Enumerator declarations

4.6.2 Neighbour Node Information Array

In order to have a contention free schedule allocation, it is necessary to know the first andsecond hop neighbors of a node and also to enforce the transmission constraints explained insection 4.4. The neighbour information table is visualized as a 2D matrix or array, enNegh-Info[NODE ID][NODE ID]. The array is arranged as source and destination nodes. Each cell con-tains an Enumerator value NOT LINKED,FIRST HOP,SECOND HOP and SAME SRC DES.For example if node Id 1 has a link to node ID 2, then the cell mij(negh) shall be marked as FI-IRST HOP for i = 1 and j = 2. Taking another example if node ID 1 has a link to node ID 2 and



node ID 2 has a link to node ID 3, then the cell m13(negh) shall be marked SECOND HOP. Thevalue SAME SRC DES is reserved for cells like m11(negh) where i = j.

Figure 4.4: Example of 2D Neighbour Table for a network with four nodes

//! Enum to indicate the hop neighbors in the hop table

typedef enum

{

NOT_LINKED , //! No link between source and destination

FIRST_HOP , //! First Hop Neighbor

SECOND_HOP , //! Second Hop Neighbor

SAME_SRC_DES //! Used to fill out when same source and destination nodes are

compared e.g. 0 with 0 or 1 with 1 etc

} HOP_INFO_ENUM;

static HOP_INFO_ENUM enNeghInfo[MAX_NUM_OF_NODES ][ MAX_NUM_OF_NODES ];

Listing 4.2: Neighbour Information 2D matrix Enumerator declarations

4.6.3 Resultant Schedule 2D Array

The 4D matrix is used by the PAN coordinator of the network to manage the schedule. Inorder to share the schedule with the end nodes, the outcome is stored in a resultant schedule 2Darray. This is because sharing the entire 4D array to the end nodes is not feasible since the endnode is usually a reduced function device with less memory on board. The resultant 2D array isarranged as stScheduleTable [MAX NUM OF FREQ CHNL][MAX NUM OF TIME SLOTS], onedimension being the frequency channel offset and the other being the time slots. Each cell withinthe table contains the source node and the destination node of a link. Currently each time slotcan be owned by only one link. According to the IEEE 802.15.4e standard each timeslot can beshared by more than one link, however this feature is left for future work.

//! Structure to represent a link for final schedule table

typedef struct

{

unsigned char unSource; //! Source Node

unsigned char unDest; //! Destination Node

}LINK_ATTRB_STRUCT_RESULTANT;

static LINK_ATTRB_STRUCT_RESULTANT stScheduleTable [MAX_NUM_OF_FREQ_CHNL ][

MAX_NUM_OF_TIME_SLOTS ];

Listing 4.3: Neighbour Information 2D matrix Enumerator declarations

4.7 System Configuration Parameters

In order to have a properly functional TSCH protocol, certain system configuration parametersneeds to be known. These are the total number of nodes in the network N, the slotframe size S,



number of frequency channel offset F, total number of links in the network and duration of onetimeslot. For our system we consider a star network topology in which the number of directionallinks can be written as a function of total number of nodes in the network as 2N-2 where N ≥ 2.

4.8 TSCH Scheduling Algorithm

The scheduling algorithm functions in several stages and each stage is explained in the followingsections. Figure 4.5 shows a high level overview of the scheduler working phases. The systemconfiguration parameters which are given as an input to the scheduler are list of links with Psize

and Pperiod information, number of network nodes N, slotframe size S, Number of frequency channeloffset F, duration of timeslot Ttimelsot and the total number of links. For better understanding weexplain the algorithm with the help of an example network shown in figure 4.6.

Figure 4.5: High level flow diagram of TSCH scheduler



4.8.1 First and Second Hop Neighbor Search

The first stage of the algorithm after receiving the system configuration is to extract the neigh-bor information from the provided list of links. The first hop and second hop neighbor for eachnode in the network is determined by the provided list of links. Searching for first and secondhop neighbors is necessary since it is important to avoid interference from neighbors by assigningdifferent timeslots and frequency channels. To search for neighbors the following condition is used.

1. If a link Li,j exist between node ni and nj, then both the nodes are first hop neighbors ofeach other since they can directly communicate with each other.

2. Any node nk is a second hop neighbor of node ni if there exist a link Lj,k between nodenj and nk as well as there exist a link Li,j between node ni and nj.

Figure 4.6: Network Example

Figure 4.7: First and Second Hop Neighbors



4.8.1.1 Pseudocode

Following is the pseudocode for neighbor node extraction from the list of links.

Algorithm 1 Gather Neighbor Information

Let L be a list of links L = {l0,l1,...,lk} and l total be the total number of links lk has two fieldssource node ID nsk and destination node ID ndk then

1: for k = 0 upto ltotal do2: if nsk != ndk then3: mij(negh) ← First Hop (where i= nsk and j = ndk)4: mij(negh) ← First Hop (where i= ndk and j = nsk)5: end if6: end for7: for i = 0 upto N do8: for j = 0 upto N do9: if i=j then

10: mij(negh) ← SAME SRC DES11: else if mij(negh) == First Hop then12: for q =0 upto N do13: if q == i OR q == j then14: continue15: else if mjq(negh)== First Hop AND miq(negh)== NOT LINKED then16: miq(negh) ← SECOND HOP17: end if18: end for19: end if20: end for21: end for

4.8.2 Schedule Assignment

The second stage of the algorithm is to search for a FREE slot in the main 4D resource managermatrix. The algorithm picks the first link from the list and looks up the 4D table against thesource and destination node IDs for a free frequency channel and timeslot. The number of times-lots required by a link depends on the bandwidth requested (or the number of packets generatedper second). The bandwidth requested by an application is provided as the period of packet gen-eration in milliseconds. The payload size of the packet which should not exceed 100 bytes. Thenumber of slots required (Sreq) is calculated using the following formula.

TSlotframe = S * Ttimeslot (4.1)

Sreq = (TSlotframe * Psize)/(Pperiod*100) (4.2)

In equation 4.1 TSlotframe is the duration of the slotframe in milliseconds, S is the slotframe sizeand Ttimeslot is the duration of one timeslot. In equation 4.2 Psize is the packet size generated bythe application and Pperiod is the period with which the packet is generated.

The search is done starting from the first column of the 4D matrix corresponding to the sourceand destination nod IDs and traversing through each row in search for a free slot. Once a slot isfound it is marked as OWNED. In case a schedule could not be found, a message is sent to the



higher layer to take appropriate measure based on the application.

For a link Lij in the resource manager Matrix Mrm for a cell msdft = FREE we do msdft = OWNED; where s = ni and d = nj by traversing through frequency channel offset f and time slot offset t.Let the selected frequency channel offset be fm and selected time offset be tk.

From the example as shown in figure 4.6, let us consider that the list of links provided to thescheduler is L = {L0,1, L0,2, L1,0, L1,2, L1,3, L3,1}. Initially the entries of the 4D matrix cor-responding to this link which is m01ft where f ≤ F and t ≤ S, is FREE. Assuming that this linkrequires only one slot, the algorithm shall assign the cell m0100 = OWNED which is shown infigure 4.8.

Figure 4.8: Assigning a free slot

4.8.2.1 Pseudocode

Following is the pseudocode for slot assignment in 4D matrix.

Algorithm 2 Slot Assignment in 4D Matrix

Let source node ID be ns, destination node ID be nd and required number of slots be Sreq

INPUT: ns,nd,Sreq

1: TotalSlotCount = S * F2: Allocated = 03: Temp = 04: if Sreq > 0 then5: for t = 0 upto (S-1) do6: Temp = 17: for f = 0 upto (F-1) do8: if mnsndft == FREE AND TotalSlotCount > 0 then9: mnsndft = OWNED

10: Sreq = Sreq -111: TotalSlotCount = TotalSlotCount -112: Block Other Link Slots(ns,nd,f,t) (see section 4.7.2.2)13: Block Own Link Slots(ns,nd,t) (see section 4.7.2.3)14: Block Link Based On Constraints(ns,nd,f,t) (see section 4.7.2.4)15: if sreq == 0 then16: Allocated = 117: else18: t = t + 119: end if



Algorithm 2 Slot Assignment in 4D Matrix (continued)

20: Temp = 021: break22: end if23: end for24: if Temp == 1 then25: t = t + 126: end if27: if Allocated == 1 then28: break29: end if30: end for31: end if

4.8.2.2 Blocking of slots for links interfering with the reference link Lij

In the third stage for all the available links in the provided list (except the one for which theschedule is being determined), for all the first and second hop neighbors of the source node of thelink being considered, we block exactly the same slot that was assigned to the link in the secondstage. This is because interference can occur if a source node and its second hop neighbor aretransmitting to the same or different destination node at the same time and frequency channel.Furthermore, we must also prevent the first hop neighbors of the source node (of the reference link)from transmitting at same time and frequency channel offset that was allocated to the source node.

For a link Lij considered in the second stage, in the resource manager Matrix Mrm, for everycell msdft, we do msdft = BLOCKED ; where s 6= ni , d 6= nj , f = fm and t = tk, which is thesame for msdft = OWNED for link Lij.

Figure 4.9 shows the result of this stage in red, with L0,1 as the reference link.

Figure 4.9: Blocking of Slots at same time and frequency for other links



4.8.2.3 Pseudocode

Following is the pseudocode for blocking of slots of other links.

Algorithm 3 Block Other Link Slots

Let L be a list of links L = {l0,l1,...,lk} and l total be the total number of links, lk has two fieldssource node ID nsk and destination node ID ndk, f be the frequency channel offset and t be thetimeslot offset. Furthermore, let nsl be the source node and ndl be the destination node of thereference link then:

1: for k=0 upto ltotal do2: if (nsk != nsl) AND (ndk != ndl) then3: if (mnslnsk(negh) != NOT LINKED)AND (mnskndkft == FREE ) then4: mnskndkft = BLOCKED5: end if6: end if7: end for

4.8.2.4 Blocking of unassigned slots in a column for the reference link Lij

In the fourth stage, for the link Lij that was considered in second stage, we block all the non-assigned or ”FREE” slots (if any) of the same column or time slot index it was assigned a scheduleby traversing through all the frequency offsets. This is because a transmitter normally is equippedwith a single transceiver and cannot transmit or receive data from multiple frequency channels atthe same time.

For a link Lij considered in the second stage, in the resource manager Matrix Mrm for a cellmsdft, we do msdft = BLOCKED ; where s = ni , d = nj , ∀ f | f ≤ F and f 6= fm. Here t is thesame as tk obtained in the second stage for link Lij.


Figure 4.10: Blocking of unassigned slots in a column for link currently being considered



4.8.2.5 Pseudocode

Following is the pseudocode for blocking of un-assigned slots of a reference link.

Algorithm 4 Block Own Link Slots

Let nsl be the source node, ndl be the destination node of the reference link and t be the timeslotoffset then:Input: nsl,ndl,t

1: for f=0 upto F do2: if (mnslndlft != OWNED) then3: mnslndlft = BLOCKED4: end if5: end for

4.8.2.6 Blocking of slots at same time offset but different frequency channel for linksother than the reference link Lij

In the fifth stage, except for the link Lij that was considered in second stage, we decide whetherthe source nodes in all the other remaining links can transmit at the same time offset but at adifferent frequency channel than the one assigned to link Lij. For this, we compare the source anddestination node IDs (or addresses) of the link Lij with the source and destination IDs with allthe remaining links. The following four cases arises in which the transmission is not possible.

While comparing link Lij with some other link Lqr

1. If node ni = nq, this means that source node of link Lij is the same as the source node oflink Lqr. In this case, for the link Lqr we block all the slots at the same time and all frequencychannels for which the link Lij was scheduled. This is because a source node ni cannot transmitat two different frequencies at the same time.

2. If node ni = nr, this means that source node of link Lij is the same as the destination nodeof link Lqr. In this case, for the link Lqr we block all the slots at same time and all frequencychannels for which the link Lij was scheduled. This is because a source node ni cannot transmitand receive at the same time.

3. If node nj = nq, this means that destination node of link Lij is the same as the source nodeof link Lqr. In this case, for the link Lqr we block all the slots at same time and all frequencychannels for which the link Lij was scheduled. This is because a source node nq cannot transmitand receive at the same time.

4. If node nj = nr, this means that destination node of link Lij is the same as the destina-tion node of link Lqr. In this case, for the link Lqr we block all the slots at same time and allfrequency channels for which the link Lij was scheduled. This is because a destination node nj

cannot receive from two different sources at same time (Hidden Neighbor Problem).

For a link Lij considered in the second stage, in the resource manager Matrix Mrm for a cellmsdft we do msdft = BLOCKED ; where s 6= ni , d 6= nj , ∀ f | f ≤ F and f 6= fm. Here t is thesame as tk obtained in the second stage for link Lij.




Figure 4.11: Blocking of slots at same time and different frequency channel for other links

At the end of this stage for the example network being considered the 4D resource manager matrixlooks similar to as shown in figure 4.12.

Figure 4.12: After completion of algorithm

4.8.2.7 Pseudocode

Following is the pseudocode for blocking of slots at same time offset but different frequency channeloffset for links other than the reference link .



Algorithm 5 Block Links Based On Constraints

Let L be a list of links L = {l0,l1,...,lk} and ltotal be the total number of links, lk has two fields,source node ID nsk and destination node ID ndk. Let t be the timeslot offset. Furthermore, let nsl

be the source node and ndl be the destination node of the reference link thenInput: nsl,ndl,t

1: for k=0 upto lk do2: if (nsk == nsl) OR (nsk == ndl) OR (ndk == nsl) then3: if (ndk == ndl) OR (nsk == ndk) OR (nsl == ndl) then4: for f=0 upto F do5: if mnskndkft = FREE then6: mnskndkft = BLOCKED7: end if8: end for9: end if

10: end if11: end for

4.9 Generating the Resultant Schedule

In the final step, the generated schedule is copied into the resultant 2D array Mres or stSched-uleTable [MAX NUM OF FREQ CHNL][MAX NUM OF TIME SLOTS] as mentioned in section4.6.3.In this array, for all the links provided in the list mqr(res) = Lij, where q = f and r = t from themain resource manager 4-D matrix cell mijft = OWNED, where s = i, d = j from the link Lij. Thecontents of the final resultant schedule table for the example shown in figure 4.6 is shown below.

Figure 4.13: Final generated schedule in the resultant 2-D Table

4.9.0.1 Pseudocode

Following is the pseudocode for generating the final 2D resultant table.

Algorithm 6 Generating 2D Resultant Table

Let L be a list of links L = {l0,l1,...,lk} and ltotal be the total number of links, lk has two fields,source node ID nsk and destination node ID ndk. Furthermore, let nsr be the source node fieldand ndr be the destination node field in the 2D resultant table mqr(res) then

1: for k=0 upto lk do2: for f=0 upto F do3: for t=0 upto S do4: if mnskndkft = OWNED then



Algorithm 6 Generating 2D Resultant Table (continued)

5: if nsk != ndk then6: mft(res).nsr = nsk

7: mft(res).ndr = ndk

8: else9: mft(res).nsr = nsk

10: mft(res).nsr = 0xFF (indicating a broadcast link)11: end if12: end if13: end for14: end for15: end for

4.10 Reliability

One of the requirements of the scheduler was to take the network variations into account and adjustthe slot assignments such that it meets the bandwidth requirement for the requested network links.The condition of wireless medium is dynamic and the links quality change over time. Some of thefactors that influence the link quality are interference from other devices that are transmitting atsame time and frequency channel, and environmental factors that causes diffraction and reflectionof waves. Since the wireless links quality changes over time, there is always a possibility of failurein transmission in each timeslot of a TSCH network. In order to determine the probability of asuccessful transmission, we make use of the famous Binomial Probability formula which is basedon Bernoulli trials. A Bernoulli trial is a set of distinct experiments or events that has only twopossible outcomes either a success or a failure. If n is the number of distinct bernoulli trials, p bethe probability of success, k be the number of successes in n trials then the Binomial probabilityequation is given as shown in equation 4.3.

P (k) =

(n

k

)pk(1− p)n−k (4.3)

In our implementation of the scheduler, we are interested in knowing the number of extra slotsassignment that needs to be done such that the probability of transmission success reaches acertain level (requested by the higher layers of the stack). For this purpose, we will have to sumup the probabilities of successful transmission until the probability is equal to or greater than thereliability level that was set. For computing the network link quality, we make use of the averagePacket Reception Ratio (PRR). PRR is a receiver side estimate of link quality and indicatesthe percentage of packets correctly received at a particular link. It can be found as shown inequation 4.4. In equation 4.4 Packetrcv is the total number of packets correctly received by thedestination and Packetsent is the total number of packets sent by source to that destination.

PRR = Packetrcv/Packetsent (4.4)

In equation 4.4, PRR is computed at the node on which the scheduler is running. The period atwhich the PRR is computed is configurable and application dependent. In our prototype imple-mentation, the PRR is computed after every 15 seconds based on the number of correctly receivedpackets from a link. The average is computed after 1 minute and shared with the scheduler forprocessing. The scheduler computes the reliability and decides if redundant slots is needed to beassigned to a link.

In order to compute redundant slots, we make use of a variant of Binomial Probability formula asshown in equation 4.5.



P (k) = pkR∑i=0

(i + k − 1

k − 1

)(1− p)i (4.5)

In equation 4.5, p is the PRR obtained at the receiver side, in our case the receiver being the nodeon which the scheduler is running. Further k is the number of slots that was requested initially.R is the number of redundant slots required in order to meet the requested reliability level, basedon the current PRR. In general R will be the number of redundant slots required for a particularlink when the following condition is met P(k) ≥ Rl, where Rl is the reliability level set by thehigher layers in the stack.

In order to elaborate further and to emphasis on applicability of this approach, consider thefollowing example. Let the reliability level for the network be set to Rl = 0.9 also let us considerthere is a link between node A → B. Furthermore, based on the bandwidth requirements for acertain application, initially this link is assigned two slots by the scheduler which makes k = 2.Moreover let us consider that PRR for this link is p = 0.7. Table 4.2 below shows the probabilityof successful transmission when extra slots R is allocated to this link. The probability is calculatedusing equation 4.5. It can be seen that for this example, the link A → B needs two extra slots(since P(k) ≥ Rl) in order to not only keep meeting the bandwidth requirements but also adhereto the network quality conditions.

R (number of extra slots) P(k)0 0.491 0.7842 0.91633 0.96922

Table 4.2: Reliability computation example

4.10.0.1 Pseudocode

Following is the pseudocode for computing the redundant slots.

Algorithm 7 Redundant Slots Calculation For Reliability

Let ns be the source node and nd be the destination node of the link and k be the initially requestedslots by the reference link thenInput: ns,nd,AveragePRR

1: if (AveragePRR > 0) AND (AveragePRR < Rl) then2: if k > 0 then3: value1 = AveragePRRk

4: end if5: for P(K) < Rl do6: tmp1 = (i + k − 1)!/(k − 1)!i!7: tmp2 = 1−AveragePRRi

8: value2 = (tmp1 ∗ tmp2) + value29: P(K) = value1 * value2

10: i + +11: end for12: Additional Slots = i− 113: end if14: return Additional Slots


Chapter 5

Evaluation and Results

In this section, we explain the experiments performed in order to evaluate the centralized TSCHscheduler.

5.1 Evaluation Parameters

In order to evaluate our TSCH scheduler, we focus on the packet reception ratio (PRR) for mea-suring the link quality. With this, we investigate how PRR is affected by increasing or decreasingthe allocated time slots for a link. As indicated in the equation 4.4, packet reception ratio indicatesthe percentage of packets correctly received at a particular link. Apart from this, we also computethe overhead of the algorithm by making some reasonable assumptions.

5.2 Purpose of Experiment

The experiments are performed in order to investigate the following questions

1. How effective is the reliability feature of the centralized TSCH scheduler in maintaining theQoS requirements.

2. What effect does the length of channel hopping sequence have in maintaining reliability.

5.3 Experimental Setup

Following is the experimental setup:

1. For evaluation, we use the NXP JN5168 wireless dongles that runs an application built ontop of Contiki real-time OS. The wireless dongles are connected to a PC/Laptop via UART in-terface. Due to timing limitations and for our first prototype, instead of using the CompSOCplatform, we developed and executed the centralized TSCH scheduler as a Windows applicationon PC/Laptop to facilitate in the evaluation.

2. For simplicity we consider a star network topology for our evaluation. In a star networkthe PAN coordinator node (PC/laptop) shall always participate in a communication, since datacan only be sent or received through the PAN coordinator in this type of topology. Furthermore,using a mesh network would require the use of upper network routing layer which could potentiallyroute a packet to a healthy route, making it difficult to evaluate the scheduler.

3. We develop two different firmware for our experiments, one for the network coordinator and


CHAPTER 5. EVALUATION AND RESULTS

the second one for the end nodes. Furthermore, a Windows based application is also developedthat makes use of TSCH scheduler library.

4. In order to keep the experimental setup simple, we perform the experiments with a maxi-mum of two end nodes, one coordinator node and one node configured as a noise generator.

5. We consider only the uplink in which the end-node serves as the source and coordinator nodeserves as the destination. This is because in a typical WSN application the end-nodes are equippedwith sensors and it sends the sensor data to the coordinator for processing. Furthermore, our mainfocus is to evaluate the scheduler by keeping the application running on the end-nodes as sim-ple as possible, in our case we make the application to transmit random data in a periodic manner.

6. Following are various parameters for the experiment as configured in the Contiki OS driver

Configuration Parameter Configuration DescriptionNETSTACK CONF MAC tschmac driver MAC layer driverNETSTACK CONF NETWORK rime driver Network layer DriverNETSTACK CONF FRAMER framer 802154 Framer driver for packet formationNETSTACK CONF RDC nordc driver Radio duty cycling driver for energy preservationTSCH CONF DEFAULT TIMESLOT LENGTH 10msec Time slot lengthTSCH CONF INIT SCHEDULE FROM EB Enable Create schedule from received Enhanced BeaconUIP CONF IPV6 RPL Disable Disable IPv6 and RPL on network layerTSCH CONF JOIN MY PANID ONLY Enable Make end nodes to join PAN co-ordinator network onlyTSCH SCHEDULE CONF DEFAULT LENGTH 10 Default slot frame lengthTSCH CONF MAC MAX FRAME RETRIES 3 Number of Tx retries in case of failureTSCH CONF EB PERIOD 100 msec Enhanced beacon periodMICROMAC CONF TX POWER 0 dBm Radio transmission power

TSCH HOPPING SEQUENCE(uint8 t[]){11, 12, 15}(uint8 t[]){11, 12, 15, 14, 20, 22, 13}(uint8 t[]){11, 12, 15, 14, 20, 22, 13, 21, 24}

TSCH Hopping Sequence with 3, 7 and 11 channels

Table 5.1: Contiki OS Driver Configuration

7. Following is the configuration parameters used by the centralized TSCH scheduler

Configuration Parameter Configuration ValueTotal Number of Nodes (N) 2-3Slotframe size (S) 10Number of frequency channel offset (F) 2Total number of links in the network 2-3 (initial)Duration of one time slot 10 msec

Table 5.2: Centralized TSCH Scheduler Configuration

8. The UART configuration between the JN5168 platform and PC/Laptop is shown in table 5.3.

Configuration Parameter Configuration ValueBaud Rate 9600 bpsData bits 8Parity NoneStop bits 1Flow control None

Table 5.3: UART configuration for the JN5168 platform



9. To generate noise, ATmega256RFR2 Xplained Pro evaluation kit was used. The board wasconfigured to generate noise at Tx power of 0dBm on frequency channel 12 of IEEE 802.15.4.

10. We use a frequency hopping list in which the number of channels is relatively prime to theslotframe size. Since we set the slotframe size to 10, we perform the experiments using frequencyhopping lists containing three, seven and eleven channels. By selecting such a list, it is ensuredthat hopping takes place on every channel included in the list.

5.3.1 Network Arrangement

As mentioned earlier, we use a star network topology for evaluating the scheduler. As shown infigure 5.1 the network contains four nodes. The PAN-coordinator (Node 0 ) is connected to thePC/laptop through UART interface available on the NXP JN5168 wireless dongle. The laptop/PCexecutes the TSCH scheduler application and also performs reliability check based on the PRRvalues obtained from the PAN-coordinator through the UART interface. The end nodes (Node1 and Node 2 ), send data packets to the coordinator periodically. Two separate firmware isdeveloped, one for the network coordinator and the other for the end nodes. As an overviewfor our experiment, the end nodes transmit packets to the coordinator based on the schedulecomputed by the TSCH scheduler application. This schedule is shared with the end nodes by thecoordinator using enhanced beacons. The test phases will be explained in the following sections.

Figure 5.1: Network topology for experiment



(a) NXP JN5168 USB wireless dongle

(b) Atmel ATmega256RFR2 evaluation kit

Figure 5.2: Evaluation hardware

5.3.2 Data Payload

In the experiment, data packets are sent from the end-nodes to the coordinator. The packetsare standard IEEE 802.15.4 packets with a maximum payload of 100 bytes, making the totalpacket size to be 127 bytes. We define a packet structure for the application payload to extractmore details about the received packets, directly from the application data payload. The payloadstructure is shown in figure5.3 . The first byte of the packet contains an identifier to indicate thetype of packet. If it contains the value ’0x54’(hex) it indicates a normal test data packet. Thenext two bytes contains the destination ID of the node to which the packet is to be sent. Thenthere are two bytes indicating the sequence number of the packet. Then there are four bytes fortime stamp. The next one byte indicates the length of data. After this, there are ninety (90) bytesof randomly generated user data.

Figure 5.3: Data Packet Structure

5.4 Link Schedule for Evaluation

The links in the network topology (star network) used in the experiment, are given as an input tothe TSCH scheduler along with the configuration parameters of the system and QoS requirements



(bandwidth and reliability level). The generated schedule is then shared with the PAN-coordinatornode through the UART interface. The Contiki application firmware, running on the coordinatornode, assigns the schedule and shares it with the end nodes through the enhanced beacon in theallocated time-slot and channel offset. Figure 5.4 and figure 5.5 shows two different schedulesthat were generated by the TSCH scheduler and were used for evaluation. Figure 5.4 shows theschedule when evaluation is performed using one end node and figure 5.5 shows the schedule whenevaluation is done using two end nodes. In both the schedule the slot at t0 is used for broadcastingenhanced beacons. The empty slots in the slotframe are used as redundant slots for transmissionin order to maintain reliability when required.

Figure 5.4: Time slot allocation for one coordinator and one end node

Figure 5.5: Time slot allocation for one coordinator and two end nodes

5.5 Test Software Implementation

The test software is implemented as two different firmware one for the coordinator and the otherfor the end nodes. The functionality of each of the firmware is explained in the following sections.

5.5.1 Firmware Implementation for the End Node

In the end node a small test application was developed. In the application the end node firstperforms initialization of certain modules like timer, led and communication port. The end nodethen waits until it is associated with the PAN-coordinator. Upon successful association, the endnode then transmits one packet, of 100 bytes payload, every 100 milliseconds, this makes about 600packets in one minute. The transmission takes place in the timeslot and frequency channel offsetallocated by the TSCH scheduler running on the PC/laptop and shared by the PAN-coordinatorusing Enhanced Beacons. Figure 5.6 shows the flow diagram of the end node firmware.

5.5.2 Firmware Implementation for the PAN-coordinator

In the PAN-coordinator application, two Contiki processes are created. The first process handlesthe UART communication to and from the PC/laptop, in order to share schedule information.The second process handles the TSCH communication. The TSCH communication is blocked untilthe complete schedule information is received from the PC/laptop. Upon receiving the scheduleinformation, the PAN-coordinator makes use of the TSCH API functions of the Contiki OS toassign schedules and advertise it to the end nodes. After every 15 seconds, over a window of 1minute, the PAN-coordinator computes the packet reception ratio. After one minute the PAN-coordinator node takes an average of the computed PRR (four samples) and sends a one bytevalue of the averaged PRR to the PC/Laptop over the UART. The scheduler application, runningon the PC/laptop, computes the reliability based on the received PRR. If necessary, the schedulercreates a new schedule and shares it with the PAN-coordinator. After this, the process repeatsevery one minute.



Figure 5.6: End node application flow diagram



Figure 5.7: PAN-coordinator node application flow diagram



5.6 Test Scenarios

The experimental evaluation was conducted in an office environment. The end nodes were placedat a distance of 1 meter from the PAN coordinator. The noise generator was placed besides thePAN coordinator at a distance of 0.5 meter. Following are the scenarios that were considered inthe experiment.

1. One coordinator and one end node. This is to check for any noise in the environment prior toincluding the noise generator.

2(a). One coordinator and one end node with noise generator. This test is performed with afrequency hopping list containing three channels and with reliability check disabled.2(b). One coordinator and one end node with noise generator. This test is performed with afrequency hopping list containing three channels and with reliability check enabled.

3(a). One coordinator and one end node with noise generator. This test is performed with afrequency hopping list containing seven channels and with reliability check disabled.3(b). One coordinator and one end node with noise generator. This test is performed with afrequency hopping list containing seven channels and with reliability check enabled.

4(a). One coordinator and one end node with noise generator. This test is performed with afrequency hopping list containing eleven channels and with reliability check disabled.4(b). One coordinator and one end node with noise generator. This test is performed with afrequency hopping list containing eleven channels and with reliability check enabled.

5(a). One coordinator and two end nodes with noise generator. This test is performed witha frequency hopping list containing three channels and with reliability check disabled.5(b). One coordinator and two end nodes with noise generator. This test is performed with afrequency hopping list containing three channels and with reliability check enabled.

The test scenarios are summarised in table 5.4.

Test Scenario PAN coordinator End Nodes Hopping Sequence List Reliability Feature Reliability Level Noise Generator1 1 1 uint8 t[]){11, 12, 15} Disabled - No2a 1 1 uint8 t[]){11, 12, 15} Disabled 90 % Yes2b 1 1 uint8 t[]){11, 12, 15} Enabled 90 % Yes3a 1 1 (uint8 t[]){11, 12, 15, 14, 20, 22, 13} Disabled 90 % Yes3b 1 1 (uint8 t[]){11, 12, 15, 14, 20, 22, 13} Enabled 90 % Yes4a 1 1 (uint8 t[]){11, 12, 15, 14, 20, 22, 13, 21, 24} Disabled 90 % Yes4b 1 1 (uint8 t[]){11, 12, 15, 14, 20, 22, 13, 21, 24} Enabled 90 % Yes5a 1 2 (uint8 t[]){11, 12, 15} Disabled 85 % Yes5b 1 2 (uint8 t[]){11, 12, 15} Enabled 85 % Yes

Table 5.4: Evaluation Scenarios

5.7 Evaluation Results

In this section, we explain the results obtained by running the test software application in thescenarios as mentioned in section 5.6. In all of the scenarios the reliability level Rl was set to 90%except for scenario 5(a) and 5(b) in which the reliability level was set to 85%.

5.7.1 Test Scenario 1

In test scenario 1 the test software was executed on one coordinator and one end node. Thereliability feature of the scheduler was disabled. This was mainly to check if there is some noise in



the environment prior to deploying the noise generator. The PRR readings were taken after every15 seconds and averaged over one minute interval. The TSCH schedule generated is the same asshown in figure 5.4. The results obtained are shown in figure 5.8. It can be seen that without thedisturber node, there is a negligible loss of 0.4% over the span of five minutes. This high PRR ismainly because of short distance between transmitter and receiver, which makes the interferenceof nearby wireless devices (such as Wi-Fi devices) ineffective. It can also be seen that the PRRvalues remains above the assigned reliability level.

Figure 5.8: Test scenario 1 result

5.7.2 Test Scenario 2(a) and 2(b)

In test scenario 2(a), the test software was executed on one coordinator and one end node. Inthis scenario, the noise generator was also deployed to generate controlled interference. The noisegenerator continuously transmits packet to cause interference on channel 12. The PAN coordi-nator and the end nodes use a channel hopping list of three channels. In test scenario 2(a), thereliability feature of the scheduler was disabled. The initial schedule generated is the same asshown in figure 5.4. Figure 5.9 shows the results obtained in scenario 2(a). It can be seen that,there is an average loss of 35% over the span of five minutes. This is because the noise generatortransmits packets at frequency channel 12. Since the PAN coordinator and the end nodes usea frequency hopping list of three channels, which also includes the channel 12. Thus, every onepacket out of 3, gets dropped due to which the PRR obtained is around 66%.

Figure 5.9: Test scenario 2(a) result

In test scenario 2(b), the setup was the same as mentioned for the test scenario 2(a). Howeverin this case the reliability feature of the scheduler was enabled. The initial schedule is the same as



shown in figure 5.4. The results obtained can be seen in figure 5.10. In the first minute the PRR is66% due to the interference from the noise generator. At this point, the reliability feature comesinto action. Based on the calculations the scheduler assigns two redundant timeslots in order tomeet the reliability criteria. By assigning the redundant timeslots, the packet that gets droppedis re-transmitted in the newly assigned redundant slots. The result of this assignment can be seenfrom the second minute until the fifth minute in the figure 5.10, where the PRR remains above therequested reliability level with a value of 100%. This is because the noise generator generates noiseon one channel, even by adding one redundant slot, which uses a different channel, and performingone retransmission, we can transmit all the packets successfully. However based on the reliabilityformula as mentioned in equation 4.5, by adding one redundant slot the expected PRR comes outto be 88% whereas by adding two redundant slots the expected PRR comes out to be 96%. Theschedule generated after the first minute can be seen in figure 5.11.

Figure 5.10: Test scenario 2(b) result

Figure 5.11: Schedule generated after first minute in test scenario 2(b)


In test scenario 3(a), the test software was executed on one coordinator and one end node. In thisscenario the noise generator was also deployed. The PAN coordinator and the end nodes use achannel hopping list of seven channels. In test scenario 3(a), the reliability feature of the schedulerwas disabled where as in test scenario 3(b), the reliability feature of the scheduler was enabled.The initial schedule for both the scenarios is the same as shown in figure 5.4. Figure 5.12 showsthe result obtained in scenario 3(a). It can be seen that there is an average loss of 15% over thespan of five minutes. This is because the nodes now transmit using seven different channels. Inthis case one out of every seven packets gets dropped, due to which the PRR is 85% which ishigher than that obtained in scenario 2(a).

In test scenario 3(b), the reliability feature was enabled. The results obtained can be seenin figure 5.13. Similar to the result obtained in test scenario 2(b), the scheduler responds to thenetwork variations in the first minute and includes one redundant transmission slot to maintainthe reliability level. The result of this assignment can be seen from the second minute until thefifth minute in the figure 5.13, where the PRR remains above the requested reliability level witha value of 100%. The schedule generated after the first minute can be seen in figure 5.14.







In test scenario 4(a), the test software was executed on one coordinator and one end node. Inthis scenario the noise generator was also deployed. The PAN coordinator and the end nodesuse a channel hopping list of eleven channels. In test scenario 4(a), the reliability feature of thescheduler was disabled where as in test scenario 4(b), the reliability feature of the scheduler wasenabled. The initial schedule for both the scenarios is the same as shown in figure 5.4. Figure 5.15shows the result obtained in scenario 4(a). It can be seen that there is an average loss of 13% overthe span of five minutes. This is because the nodes now transmit using eleven different channels.In this case one out of every eleven packets gets dropped, due to which the PRR is 88% whichis higher than that obtained in scenario 3(a). Theoretically, the PRR should be 90% and noredundant slots are required in this case since the PRR is equal to the requested reliability level.However, due to possible interference from nearby devices, we achieve a PRR of 88%.

In test scenario 4(b), the reliability feature was enabled. The results obtained can be seen infigure 5.16. Similar to the result obtained in test scenario 2(b) and 3(b), the scheduler responds tothe network variations in the first minute and includes one redundant transmission slot to maintainthe reliability level. The result of this assignment can be seen from the second minute until the




fifth minute in the figure 5.16, where the PRR remains above the requested reliability level witha value of 100%. The schedule generated after the first minute can be seen in figure 5.14. It canbe seen that the schedule is same as that obtained in test scenario 3(b).




In test scenario 5(a), the test software was executed on one coordinator and two end nodes. Inthis scenario the noise generator was also deployed. The PAN coordinator and the end nodes use achannel hopping list of three channels. In test scenario 5(a), the reliability feature of the schedulerwas disabled where as in test scenario 5(b), the reliability feature of the scheduler was enabled.The initial schedule for both the scenarios is shown in figure 5.5. Figure 5.18 shows the resultobtained in scenario 5(a). It can be seen that there is an average loss of 35% over the span offive minutes, similar to results obtained in scenario 2(a). This is because the nodes now transmitusing three different channels. In this case, out of every six packets (two packets transmitted perslotframe), two gets dropped, thus the PRR, as expected, is 66%.

In test scenario 5(b), the reliability feature was enabled. The results obtained can be seenin figure 5.19. Similar to the result obtained in test scenario 2(b), the scheduler responds to the




network variations in the first minute and includes one redundant transmission slot to each of thetwo end node links in order to maintain the reliability level. The result of this assignment canbe seen from the second minute until the fifth minute in the figure 5.19, where the PRR remainsabove the requested reliability level of 85%, with a value of 100%. The schedule generated afterthe first minute can be seen in figure 5.20.



5.7.6 Reflection

From the above obtained results we can conclude the following

1. By assigning redundant time slots the PRR gets better significantly. This is because of assign-ing redundant time slots to a particular link. Due to the use of channel hopping in TSCH, thoseredundant slots use different channels than the channel which was used for the initial timeslot.Considering non-uniform distribution of noise over IEEE802.15.4 channels, these retransmissionscan provide a higher PRR for the link. Further in the case of a packet drop, no acknowledgement isreceived from the destination. Therefore, the sender attempts to retransmit in the next allocatedtime slot. So, by assigning redundant timeslots retransmission is done earlier and there is lowerlatency for packet delivery over a link, as well as a higher guarantee of the successful delivery. 2.



The reliability feature of the scheduler is effective in maintaining the QoS requirements. It can beseen in the results that without the reliability feature the PRR remains below the threshold levelRl. When the reliability feature is enabled, it effectively determines the number of redundant slotsrequired which in turn improves the PRR.

3. By selecting the slotframe size and number of channels in the hopping sequence list to berelatively prime, transmissions in a timeslot (overtime) is done using every channel in the list.This increases the chance of a successful transmission by avoiding the possibility of frequentlytransmitting using a bad quality channel.

4. Due to the non-uniform distribution of noise over different IEEE 802.15.4 channels, usinga longer channel hopping sequence list, containing distinct channels, may lower the chances ofpacket drops. This is because of lowering the chance of using only bad quality channels in thehopping sequence list for transmission.

5.8 Algorithm Complexity

It would be interesting to know the complexity of TSCH scheduler as the number of nodes in thenetwork increases. In order to compute the algorithm complexity we make a few assumptions. LetN be the total number of nodes in the network where N ≥ 2. Considering a star network, we as-sume the number of links to be a function of total number of nodes in the network, which is 2N−2.Furthermore, in a star network each link will always involve the PAN coordinator, this means thatlinks cannot be scheduled in parallel. For this reason we consider the number of timeslots in aslotframe to be the same as the number of links in the network, which is S = 2N − 2, so thatthere are enough slots to schedule each link. Furthermore, we also assume that the bandwidthrequirement of a certain application is such that only one slot is required by each link to meet theQoS. The number of configured frequency channel is set to be some constant value. Furthermore,we assume that load and store operations take some constant time.

Applying the above mentioned assumptions, the complexity of the algorithm for gatheringneighbor information as explained in section 4.8.1.1 comes out to be O(N3). The complexity ofthe algorithm for slot assignment in 4D matrix as explained in section 4.8.2.1 including the sub-function calls for cell blocking comes out to be O(N3) as well. However, the complexity of thealgorithm to generate the final 2D resultant table as explained in section 4.9.0.1 comes out tobe O(N2). Combining all these results, it can be seen that the worst case complexity is O(N3).Furthermore, it should be noted that the neighbor information gathering function is only usedonce during the initialization phase, so the slot assignment in 4D matrix function is the dominantone.

5.9 Tradeoff

5.9.1 Memory Consumption

It is important to analyse the memory usage of the algorithm when the number of nodes in thenetwork increases. In the algorithm software there are three major arrays which grows as thenumber of network nodes increases, namely the main resource manager 4D array (section 4.6.1),the 2D neighbor information array (section 4.6.2) and the final 2D resultant array (section 4.6.3).In order to simplify the analyses we consider a star network topology. Let L be total number oflinks in the network, N be the total number of nodes in the network, S be the slotframe size andF be the total number of frequency channel offsets. In a star network, two links can exist betweeneach node and a PAN coordinator, the downlink which is the link from the PAN coordinator to theend node and the uplink which is from the end node to the PAN coordinator. Considering this,



the total number of links L can be written as a function of total number of nodes in the networkas L = 2(N − 1). Similarly in order for all the links to be scheduled the slotframe size must beat least equal to the number of links in the network S = 2(N − 1). Furthermore, we considerF to be 16, which is the maximum number of frequency channel offset available. Based on thisinformation, we can drive equations to calculate the growth in memory for each of these arrays,when the number of network nodes increases. Using the notation as mentioned in table 4.1, wedrive the following equations.

Mrm(mem) = (16 ∗ F ∗N2)/210 (KB) (5.1)

Mnegh(mem) = (4 ∗N2)/210) (KB) (5.2)

Mres(mem) = (4 ∗ F ∗ (N− 1))/210 (KB) (5.3)

Equation 5.1 computes the memory for the main resource manager 4D array, equation 5.2computes the memory for the 2D neighbor information array and equation 5.3 computes thememory for the final 2D resultant array. The plots of these functions can be seen in figure 5.21.

(a) Plot of memory growth for the main resourcemanager 4D array

(b) Plot of memory growth for the 2D neighbor in-formation array

(c) Plot of memory growth for the final 2D resultantarray

Figure 5.21: Memory growth plot

From the plots it can be seen that with the increase in the number of network nodes the 4Darray memory consumption increases rapidly, for example for a 15 node network the 4D arrayoccupies almost 50 KB of memory whereas the neighbor information array and the final resultantarray occupies less than 1 KB. The JN5168 wireless dongle used in the evaluation contains 32 KBof RAM and 256 KB of flash memory. The application code binary file size, developed for thewireless dongles was 34 KB and the size of Windows application for the scheduler was 47 KB.Based on the memory plots it can be seen that it is possible to execute scheduler library on theJN5168 dongles directly. However based on the application requirements, the maximum numberof nodes it can support may be in the range of 15 to 20 and may not go beyond this. Furthermore,



it may also be slower to run the application library on the dongles because of the Contiki OSoverhead and the lower processing power as compared to a PC/laptop system. Code optimizationtechniques may be used to reduce the memory footprint of the algorithm.

5.9.2 Power Consumption

Improving reliability by adding redundant slots, comes at the expense of higher energy consump-tion. This is because when a transmission fails, an attempt to retransmit is made in the allocatedredundant slot of the slotframe. Without the reliability feature, the attempt of retransmission ismade in the next slotframe. Because of this, the node needs to keep its radio ON for the requiredtime. Considering the example shown in figure 5.11, the initial requested slot is one, whereas thenumber of redundant slots is two. If the transmission fails in timeslot t1, retransmission occurs intimeslot t2, thereby consuming more energy. The worst case would be when the transmission failsin atleast two or all of the allocated slots in the example shown in figure 5.11. In that case thepower consumption would be twice than the case when the transmission is successful in the firstattempt. Graphical plots showing the trend between redundant slots, power consumption andreliability can be seen below. For the plots, a link is considered for which the initially allocatedslots is 1 and the initial PRR value is 66%. For the plot shown in figure 5.22, equation 4.5 is usedin which k = 1 and p = 0.66. For the plot shown in figure 5.23, the equation P = (V ∗ I) ∗ (k +R)is used in which V = 3.6v and I = 15.6mA. These values were obtained from the datasheetof JN5168 device. In figure 5.22, it can be seen that increasing the number of redundant slotshave significant effect on reliability in the start after which nearly becomes constant and does notincrease further. It can also be seen in figure 5.23 that by increasing the number of redundantslots the power increases linearly. Furthermore, in figure 5.24, it can be seen that higher level ofreliability comes at the expense of higher power consumption.

Figure 5.22: Plot of reliability vs number of redundant slots


Figure 5.23: Plot of power consumption vs number of redundant slots

Figure 5.24: Plot of power consumption vs reliability

Chapter 6

Conclusions and Future Work

6.1 Conclusion

In this thesis work, a centralized TSCH scheduler was designed and evaluated by implementing atest application running on NXP’s JN5168 wireless dongle, on top of Contiki OS. The novel featureof this scheduler is that by using Binomial theorem it takes into account the network qualityvariations and adjusts the link slot assignments by computing the probability of a successfultransmission. Furthermore, the scheduler is able to function independent of the network layerused in the Contiki OS for wireless communication. The scheduler is able to operate with all ofthe network topologies supported by the IEEE 802.15.4 standard. The reliability feature of thescheduler considers the packet reception ratio (PRR) as the network link quality indicator anduses it in the reliability computation. In the presence of an interfering node, the experimentalresults showed that the PRR significantly improved by enabling the reliability feature of thescheduler as compared to scenarios in which this feature was disabled. This is because of usingthe channel hopping technique in TSCH, which leads to using different channels for transmissionsin the different allocated timeslots for a wireless link. It can be concluded that the design andoperation of this could be fruitful in maintaining the reliability of critical links in the network.However, for large networks the memory requirements must be taken into account.

6.2 Future Work

Following are some of the future research directions which can be studied to improve the central-ized TSCH scheduler.

1. Multiple Slotframe: In the current implementation of the TSCH scheduler only one slot-frame was considered. IEEE 802.15.4e standard states that there can be multiple slotframes withdifferent sizes in a network which can operate concurrently. Using multiple slotframes can havethe benefit of defining different schedules for a group of nodes or an application having differentduty cycle or bandwidth requirements. Further in the current implementation, only the sched-ule information of six links in a slotframe can be shared in one enhanced beacon due to packetsize limitation. Multiple slotframes can enable the sharing of more link schedule information byassigning links to different slotframes based on application requirements. Including support formultiple slotframes in the current TSCH scheduler implementation as well as in the Contiki OSTSCH driver library can be further investigated.

2. Shared Time Slots: In the current implementation of the TSCH scheduler links were assigneddedicated time slots. However a case can arise when no free slots are available due to which anetwork link could not be given access to the wireless medium. In this case sharing a time slotbetween two or more links can be useful. Further research is required in investigating the impact


CHAPTER 6. CONCLUSIONS AND FUTURE WORK

of using shared slots on performance of the network. This work will require implementation of theshared link feature in the centralized TSCH scheduler and Contiki OS TSCH driver along withexperimental evaluation.

3. Dynamic Channel Blacklisting: In TSCH mechanism each transmission occurs at a differ-ent channel offset, depending on the entries of the channel hopping list. It is quite possible overthe time, the quality of some of the channels become poor thereby effecting the reliability of thelinks. The reliability feature of the scheduler is useful to counter the effects of such poor qualitylinks however it cannot assign redundant slots beyond a certain limit. It might be useful to iden-tify such poor frequency channels, blacklist it and maintain a list of good quality channels duringruntime. In this way the wireless communication in the network could be made more reliable.Further research could be done in studying the feasibility of this approach and its implementationin the centralized TSCH scheduler software.

4. Latency: In the current TSCH scheduler implementation for simplicity only applicationbandwidth requirement was considered. However in wireless communication latency is also a keyperformance indicator and needs to be taken into consideration. Further work can be done toconsider latency requirements of applications and to schedule links accordingly.

5. Unified Resource Manager for CompSOC Network on Chip and Wireless ResourceThe CompSOC platform has a Network On Chip (NOC) for communication between differentIP modules and resources within the platform. Network on chip is an alternative to bus basedinterconnects for different IPs in a system on chip (SOC). NOCs were proposed to cope withrising number of IPs in a SOC which the traditional buses could not handle in terms of efficiencyand performance. There are several different implementations of NOC available in literature likedAElite [10], aelite [36], TTNOC [37], aethereal [38], SPIN [39] and many more. As an overview,the dAElite NOC which is used in the CompSOC platform, comprises of a network interface (NI)which is directly connected to a router. IPs are connected to NI and data can be sent or receivedthrough this interface via a NI shell. A NI may be connected to one or more IPs. The NI containsa slot table which ensures a contention free communication by allowing only certain data to passthrough at a time depending on the table entry. This is in accordance with time division multi-plexing (TDM) scheme. Similarly the router also contains a slot table which contains informationabout the link that the data must be routed to at a particular time. Further the router containsno buffer and it relays data the moment it arrives, to the link as indicated by the slot table. Theslot tables in the NI and router is configured by a resource manager software for the CompSOCplatform. The TDM operation in dAElite NOC is similar to TSCH operation in wireless whenTSCH is fixed to a single frequency channel (when channel hopping is disabled). However thedifferences lie in the constraints of wired and wireless mediums where the wireless constraintsbeing more stricter than the wired. Currently the CompSOC has a single resource manager thatallocates the resources through an API as mentioned in section 1.3. As a future work the wirelessresource scheduler can be integrated into the existing resource manager of Compsoc instead ofrunning it as a separate library.


Bibliography

[1] W.J. Flemming. New automotive sensors-a review. IEEE sensors journal, pages 1900–1921,November 2008. 1

[2] D. Paret. Multiplexed Networks for Embedded Systems: CAN, LIN, FlexRay, Safe-by-Wire.Wiley, May 2007. 1

[3] S. Tuohy, M. Glavin, C. Hughes, E. Jones, M. Trivedi, and L. Kilmartin. Intra-vehiclenetworks: A review. IEEE Transactions on Intelligent Transportation Systems, pages 534–545, May 2014. 1

[4] Utayba Mohammad. Performance Analysis of IEEE 802.15.4 For Intra-Vehicle Wireless Net-works. Proceedings of The 2014 World Congress in Computer Science, 2014. 1

[5] J.A. Gutierrez, M. Naeve, E. Callaway, M. Bourgeois, V. Mitter, and B. Heile. IEEE 802.15.4:a developing standard for low-power low-cost wireless personal area networks. IEEE Network,pages 12–19, September 2001. 2

[6] D.V.R. Sudhakar. Effectiveness of Time-Slotted Channel Hopping in Wireless In-VehicleNetworks. Master Thesis Eindhoven University of Technology, September 2015. 2

[7] IEEE standard for local and metropolitan area networks part 15.4: Low-rate wireless. IEEEStd 802.15.4e, page 1225, April 2012. 2, 14, 15, 17

[8] Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT).Internet Engineering Task Force (IETF), May 2015. 2, 16

[9] A.Hansson, K.Goossens, Marco Bekooij, and Jos Huisken. CoMPSoC: A template for com-posable and predictable multi-processor system on chips. ACM Transactions on Design Au-tomation of Electronic Systems (TODAES), January 2009. 3

[10] Radu Stefan, Anca Molnos, and Kees Goossens. dAElite: A TDM NoC supporting QoS,multicast and fast connection set-up. IEEE Transactions on Computers, 2012. 3, 58

[11] S.Sinhaa, M.Koedama, G.Breaban, A.Nelsona, A.B.Nejadb, M.Geilena, and Kees Goossens.Composable and predictable dynamic loading for time-critical partitioned systems on multi-processor architectures. Microprocessors and Microsystems, Elsevier, pages 1087–1107, May2015. 4

[12] Kees Goossens, M.Koedam, S.Sinha, A.Nelson, and M.Geilen. Run-time middleware to sup-port real-time system scenarios. European Conference on Circuit Theory and Design (EC-CTD), pages 1–4, August 2015. 4

[13] National Instruments. What Is a Wireless Sensor Network? May 2016. [Online; accessed2-June-2016]. 6

[14] A.Francillon, B.Danev, and S.Capkun. Relay Attacks on Passive Keyless Entry and StartSystems in Modern Cars. [Online; accessed 2-June-2016]. 6


BIBLIOGRAPHY

[15] RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks. Internet Engineering TaskForce (IETF), March 2012. 7, 10

[16] Adam Dunkels. Rime A Lightweight Layered Communication Stack for Sensor Networks.European Conference on Wireless Sensor Networks (EWSN), January 2007. 7, 10

[17] A.Awang. Distributed Contention Arbitration using RTS/CTS versus DATA/ACK for Wire-less Sensor Networks. International Symposium on Telecommunication Technologies (ISTT),pages 100–105, November 2012. 8

[18] S.Ray and D.Starobinski. On False Blocking in RTS/CTS-Based Multihop Wireless Networks.IEEE Transactions on Vehicular Technology, pages 849–862, March 2007. 8

[19] Neil Briscoe. Understanding The OSI 7-Layer Model. PC Netwrok Advisor, 2002. [Online;accessed 2-June-2016]. 9

[20] Shuang-Hua Yang. Wireless Sensor Networks: Principles, Design and Applications. Springer,2013. 9, 10

[21] NXP. IEEE 802.15.4 stack, User Guide. NXP application note JN-UG-3024, January 2015.11, 12, 13

[22] NXP Laboratories UK. Calculating 802.15.4 Data Rates. November 2013. [Application Note:JN-AN-1035]. 12

[23] J.A.Gutierrez. IEEE std. 802.15.4 Enabling Pervasive Wireless Sensor Networks. PresentationSlides, Eaton Innovation Center, 2005. 13

[24] J. T. Adams. An introduction to IEEE STD 802.15.4. IEEE Aerospace Conference, 2006. 14

[25] Domenico De Guglielmo and Giuseppe Anastasi and Alessio Seghetti. From IEEE 802.15.4to IEEE 802.15.4e: A Step Towards the Internet of Things. Advances in Intelligent Systemsand Computing, pages 135–152, January 2014. 16, 19

[26] Majid Nabi. Communication standards for wireless sensor networks. Lecture Slides for thecourse Network Embedded Systems, TU/e, January 2015. 16

[27] A. Dunkels, B. Gronvall, and T. Voigt. Contiki - a lightweight and flexible operating systemfor tiny networked sensors. 29th Annual IEEE International Conference on Local ComputerNetworks, pages 455–462, November 2004. 17

[28] Contiki. Contiki 3.x. https://github.com/contiki-os/contiki.Online; accessed 2-June-2016. 17

[29] Contiki. Contiki processes. https://github.com/contiki-os/contiki/wiki/

Processes.Online; accessed 2-June-2016. 17

[30] G.Fiore, V.Ercoli, A.J.Isaksson, K.Landerns, and M. Di Benedetto. Multihop multi-channelscheduling for wireless control in wirelesshart networks. IEEE Conference on Emerging Tech-nologies and Factory Automation, pages 1–8, September 2009. 19, 20

[31] J.Song, S.Han, Al Mok, Deji Chen, M.Lucas, M.Nixon, and W.Pratt. Wirelesshart: Applyingwireless technology in real-time industrial process control. IEEE Real-Time and EmbeddedTechnology and Applications Symposium, RTAS’08, pages 377–386, April 2008. 19

[32] M.R.Palattella, N.Accettura, L.A.Grieco, G.Boggia, M.Dohler, and T.Engel. On optimalscheduling in duty-cycled industrial iot applications using ieee802.15.4e tsch. IEEE SensorsJournal, pages 3655–3666, October 2013. 19, 20


https://github.com/contiki-os/contiki

https://github.com/contiki-os/contiki/wiki/Processes

https://github.com/contiki-os/contiki/wiki/Processes

BIBLIOGRAPHY

[33] Andrew Tinka, T.Watteyne, and K.Pister. A decentralized scheduling algorithm for timesynchronized channel hopping. Ad Hoc Networks of the series Lecture Notes of the Institutefor Computer Sciences, Social Informatics and Telecommunications Engineering, pages 201–216, 2010. 19

[34] N.Accettura, M.R.Palattella, G.Boggia, L.A.Grieco, and M.Dohler. Decentralized trafficaware scheduling for multi-hop low power lossy networks in the internet of things. IEEE14th International Symposium and Workshops on a World of Wireless, Mobile and Multime-dia Networks (WoWMoM), pages 1–6, June 2013. 19, 20

[35] S.Duquennoy, B.Al Nahas, O.Landsiedel, and T.Watteyne. Orchestra: Robust mesh networksthrough autonomously scheduled tsch. Proceedings of the 13th ACM Conference on EmbeddedNetworked Sensor Systems, pages 337–350, 2015. 19, 20

[36] A. Hansson, M. Subburaman, and K. Goossens. aelite: A flitsynchronous network on chipwith composable and predictable services. DATE, 2009. 58

[37] Christian Paukovits and Hermann Kopetz. Concepts of switching in the Time-TriggeredNetwork-on-Chip. IEEE International Conference on Embedded and Real-Time ComputingSystems and Applications (RTCSA), 2008. 58

[38] K. Goossens, J. Dielissen, and A. Radulescu. thereal network on chip: Concepts, architectures,and implementations. IEEE Design and Test of Computers, 2005. 58

[39] A. Adriahantenaina, H. Charlery, A. Greiner, L. Mortiez, and C. A Zeferino. SPIN: a scalable,packet switched, on-chip micronetwork. DATE, 2013. 58


eindhoven university of technology master dynamic centralized … · mac layer of the osi model. in...

Documents