Wireless Sensor Networks (WSNs) are a growing research area as a large of number portable devices are being developed. This fact makes operating systems (OS) useful to homogenize the development of these devices, to reduce design times, and to provide tools for developing complex applications. This work presents an operating system scheduler for resource-constraint wireless devices, which adapts the tasks scheduling in changing environments. The proposed adaptive scheduler allows dynamically delaying the execution of low priority tasks while maintaining real-time capabilities on high priority ones. Therefore, the scheduler is useful in nodes with rechargeable batteries, as it reduces its energy consumption when battery level is low, by delaying the least critical tasks. The adaptive scheduler has been implemented and tested in real nodes, and the results show that the nodes lifetime could be increased up to 70% in some scenarios at the expense of increasing latency of low priority tasks.
An operating system (OS) is a software layer that provides hardware abstraction and allows the developer to manage hardware resources. An OS also provides the developer standard mechanisms and services to ease and unify application development.
Therefore, the main advantages of using an OS are the software portability over heterogeneous hardware platforms and the ability to build application level developments regardless of the hardware used. OSes also provide other features such as multithreading capabilities or memory management. Wireless Sensor Networks (WSNs) are one of the most OSes demanding fields as these networks are composed by heterogeneous nodes where efficient hardware management is a main issue.
On the other hand, using an OS usually implies an overload in memory, CPU cycles, or energy consumption. This overload could be a critical issue in autonomous resource-constraint systems such as nodes present in WSNs. For this reason, OSes for WSNs must fulfil some specific requirements and features:
The scheduler is considered the core of an OS as it manages the tasks execution and could provide real-time management capabilities to the developer. Optimizing the scheduler is mandatory in OSes for WSNs in order to provide real-time multithread capabilities while using the lowest resources possible.
Our work proposes a scheduler that changes the task scheduling depending on environment conditions, which are treated as inputs. Energy efficiency could be improved with this algorithm as the scheduler adapts dynamically to the environment when it changes. In this work, we use the device battery level and the tasks priorities as environment inputs in order to reduce energy consumption when the battery is running low, while maintaining minimum latencies for high priority tasks.
This paper is organized as follows. Section
Operating systems for WSNs are a highly studied area in the last decade since the first networks were deployed. Many of them have been developed during the last years, with TinyOS [
These OSes fit the requirements of WSN OSes, as they have a very small memory footprint while providing development abstraction. They also provide full network stack, simple memory management, and some multithreading capabilities. These OSes can run well in resource-constraint low-power microcontrollers, such as the Texas Instruments MSP430 used in TelosB, running at 8 MHz with 10 KB RAM.
However, new microcontrollers, such as low-power ARM Cortex-M ones, have increased available resources while maintaining very low energy consumption, reaching up to 120 MHz clock speed and 320 KB RAM. Therefore, these new devices allow the usage of more advanced OSes that employ fully preemptive threads and other features such as mutexes, semaphores, timers, or queues. Real-time operating systems (RTOS), such as open sourced FreeRTOS, may be used for WSN on these new microcontrollers. A priority scheduler or a round-robin scheduler may be used to implement a real-time OS. Several studies have been conducted to compare performance of both and to decide the best situation for using each method [
Recent studies demonstrate that these real-time operating systems are being used in WSN monitoring systems [
Other open issues regarding OSes are also being studied in the last years such as their steep learning curve and their power management features. RIOT OS [
The distributed OSes for WSN field are also targeted by several research works in order to provide better management features and a highly transparent interface for the network developer [
Finally, other works target dynamic reconfiguration and operation of OSes. Lorien OS [
All these works show the interest in dynamic reconfiguration of OSes for WSNs. However, there are still open issues getting an adaptive scheduler that modifies its properties dynamically on changing environments. The main target of our work consists in improving WSN nodes lifetime in dynamic battery-operated environments by adapting dynamically a round-robin scheduler.
In this section, we explain an architecture for an adaptive scheduler that could modify its behaviour in changing environments. The global architecture is shown in Figure The duty cycle is the portion the node CPU is running with respect to total time; the rest of the time the node is in low-power mode, also called sleep mode. The tasks priorities allow managing tasks execution and real-time capabilities, as higher priority tasks are usually executed with lower latencies compared with low priority ones. The Systick is the main timer of the scheduler, so the execution could be changed from one task to another in every system timer interrupt.
Adaptive scheduler architecture.
In order to make decisions, the scheduler architecture proposed uses a decision period. At the starting time of this period a decision is made in order to change scheduler properties. This decision period is a multiple of the Systick so we use only one timer for OS kernel management. The Systick period and the CPU clock frequency are constant in our scheduler, so the CPU does not change its executing speed dynamically.
This architecture is scalable to adapt dynamically any scheduler property although in this work we manage only the scheduler duty cycle. Our target consists in extending lifetime through scheduler duty cycling control while maintaining low latency for real-time tasks. Duty cycle represents the time when the microcontroller is active, so it is directly proportional with energy consumption.
In most schedulers, the active duty cycle is set by the tasks load, so all energy management is expected to be done by the programmer of each task. This way, a badly programmed task that never sleeps causes the CPU always to be active, so the duty cycle will be 100%. In the scheduler proposed, the node active time is fixed by the duty cycling decision module independently of the task load. A task which is in ready state could not be executed if the fixed active time has lapsed. This could cause increasing latencies for some tasks but save large amount of energy in some situations. To avoid this effect for real-time tasks the scheduler allows them to execute even if the active time has lapsed. Therefore, the adaptive scheduler saves energy by delaying low priority tasks. It should be noted that this is done without slowing them down as the CPU clock frequency does not change.
The flowchart of the adaptive scheduler process with duty cycling decision is shown in Figure
Adaptive scheduler flowchart.
On the other hand, if there are active tasks, it checks if the decision has lapsed. If it does, a decision must be taken in order to set a new duty cycle for the next decision period. This duty cycle sets the maximum available executing time for the tasks during this period. For example, if we set the Systick timer to 1 time unit and the decision period to 5 time units, we will have 2 time units as available active time if the decision-making process sets the duty cycle to 40%.
Whether or not a decision is made, the next step consists in checking if there is any available active time to execute tasks during this period. If not, the system checks if there is any task with highest priority, as we need them to be executed even if there is not available time for this period. If there are not highest priority tasks, the system goes to sleep mode until the current period finishes.
Finally, if there is any available time or there is any highest priority task, the next task to be executed will be scheduled in a priority-based round-robin way. The task will be executed during the Systick time, and when it lapses the process will start again.
In Figure
Time diagrams for round-robin and adaptive schedulers.
The example shows the behaviour of our proposed scheduler. While round-robin scheduler executes all available tasks as soon as possible, the adaptive scheduler only executes the fixed duty cycle for each period. This causes low priority tasks to be delayed compared to round-robin scheduler. The result over large time scheduler operation will be a lower number of executions of these tasks which will lead to a large energy saving. On the other hand, high priority tasks, like task 3, execute the same way they do in a round-robin scheduler, meaning no extra latency for them. In this example task 3 executes during 3 time units in both schedulers, so it is not delayed. On the other hand, task 1 lasts 6 time units in round-robin scheduler to complete execution, while it needs 11 time units in our scheduler. This delay in executing low priority tasks results in large energy saving as the system is in sleep state for a longer time.
In this work, we make duty cycle decisions, so node active time is changed dynamically. Input data used on this model could be either environmental parameters such as temperature, humidity, and RSSI or node parameters like battery level, energy consumption, tasks priorities, and execution state. This data could be collected each time a decision is made or could be stored in node memory and accessed by the decision module.
In this section, we present a duty cycle decision algorithm targeted at improving nodes lifetime. We use the approach proposed by Sirakoulis and Karafyllidis [
As described by authors of [
In our work, we propose a variation of the standard PGG problem in order to get a duty cycle value for each decision period. First, we define the global game parameters. The players of our game are each active task for the decision period and the shared resource is the execution time. The players could cooperate investing part of their available time in the decision cycle resulting in a global lower execution time for all tasks. This way, the lifetime could be extended when tasks decide to invest part of their time.
The investment done by each task in a decision cycle
In order to get the desired behaviour, the gain function is defined increasing with the multiplication factor and decreasing with task priority and battery level. This way, for high battery level or high task priority the gain value is low since the task is less likely to invest its executing time. We have defined the gain function in (
Finally, the reward function Check the number of active tasks. For each active task, calculate reward value calculate reward function value obtain the inversion of this cycle for this task compute the gain value of this cycle Calculate the arithmetic mean investment over all active tasks ( Obtain the period duty cycle from the mean investment (
The duty cycle calculated has values between 0 and 1 as the investment has. The greater the investment made by all tasks is, the shorter the duty cycle of this period is. Therefore, by using this decision module in our adaptive scheduler architecture, the duty cycle is reduced when tasks decide to cooperate investing part of their time. This allows extending lifetime at the price of delaying low priority tasks that have decided to reduce their executing time.
The adaptive scheduler and the duty cycle decision algorithm proposed have been implemented in the YetiMote WSN node developed in the B105 Electronic Systems Lab which is shown in Figure
YetiMote WSN node used for testing the adaptive scheduler.
The test scenario consists of 16 periodic tasks running a fixed time of 60 seconds for each test. The tasks periods are all different as well as their executing time in order to get the most realistic scenario possible when the tasks do not execute synchronously. In our tests, three scenarios have been defined depending on average task load. The task load is defined as the sum of the tasks active times divided by the total test time. Therefore, the tests have been performed using low task load (5%), medium task load (10%), and high task load (25%). Although 25% may not seem as a high executing load for most systems, in an energy constrained WSN scenario this task load is considered very high.
The input values used in our adaptive scheduler are the battery level
The adaptive scheduler parameters have been set to fixed values for all tests as well as the duty cycle decision algorithm parameters. The decision period value is 10 ms, while the Systick time value is 250
Each test measures the energy consumption and each one lasts 60 seconds. Therefore, different battery level or multiplication factor values are fixed for each test so we can evaluate energy saving on different input conditions. The energy consumption is obtained counting the time the microcontroller is in sleep mode during the test time. For that reason, we need to suppose 30 mW average power consumption when microcontroller is running and zero milliwatts when it is sleeping.
The tasks latencies are also measured in order to evaluate how much the tasks execution is delayed in the proposed scheduler. We have measured the maximum and average latencies reached over all tasks during a test as well as the maximum and average latencies reached only by highest priority tasks, which should not be delayed in our adaptive scheduler.
For these tests, we use a modified version of FreeRTOS with most OS functionalities—in addition to the scheduler—such as memory management, tasks management, tasks communications, device drivers, and wireless stack. The tests are performed using the default FreeRTOS priority round-robin scheduler and using our adaptive scheduler in order to compare the performance of both.
For each of the three proposed scenarios, with different task load, tests have been performed varying the battery level from 1 to 0, with a step of 0.05. Therefore, up to 20 tests are executed for each scenario with different battery level values. Besides, the tests have been carried out with different multiplication factor values: 0.5, 1, 2, and 4. The priority round-robin scheduler has also been tested in order to compare the results with our scheduler.
First, we discuss the high task load scenario results. In Figure
High task load test: energy consumption.
Moreover, Figure
High task load test: average latency.
High task load test: maximum latency achieved by highest priority tasks.
From now on, we will present the results only for multiplication factor 1, as this factor just tunes the scheduler behaviour maintaining the same functionality. For medium task load and low task load the results are quite similar, but moving the average energy consumption and task latencies to lower levels.
The results for medium task load are presented in Figures
Medium task load test: energy consumption.
Medium task load test: average latency.
Low task load: energy consumption.
Low task load: average latency.
The latencies for highest priority tasks stand in the same level as in the round-robin scheduler, so real-time jobs could be performed with our scheduler even at low battery levels.
We also measure the overhead introduced by our scheduler in order to compare it to the overhead of a round-robin scheduler. In the tests performed the round-robin scheduler expends 58 milliseconds in the scheduling routines over 60-second tests. This time supposes 0.098% of the time which is despicable over the total time. On the other hand, our adaptive scheduler takes 83.4 ms during the scheduling routines and duty cycle decision algorithm. That means 0.14% of total time, which could be still considered despicable.
Finally, we obtain the expected lifetime of a node running our scheduler supposing it is powered by a 3000 mAh battery. Figure
Node lifetime for test scenarios.
In this case the lifetime is extended from 48 days to 82 days, which means up to 71% increment. The lifetime is also obtained for medium and low task loads, which leads to 57% and 21% improvement, respectively. That means that our scheduler performs better with a higher task load.
As the results obtained show, this scheduler could be highly suitable for battery-operated scenarios with energy harvesting sources. For example, if the nodes have solar panels as energy source, the battery is expected to be full during daylight hours, so the scheduler will run similar to a priority round-robin scheduler and low priority tasks will not be delayed. However, during night hours, the battery level will decay and the scheduler will start saving energy by delaying low priority tasks. This way, we could prevent the node running out of battery in cloudy days or in winter station when the night lasts longer than the day.
In this paper, we have proposed an adaptive scheduler architecture which makes possible change the task scheduling dynamically depending on the environment conditions. This could be very useful for WSN applications where changing environments are common. Specifically, we have targeted our scheduling algorithm at improving nodes lifetime, while it could be used for other optimization techniques in future works. The proposed scheduler changes dynamically its active duty cycle depending on battery level and tasks priorities. This leads to a large energy saving when battery charge is low and normal operation when battery is charged. For this duty cycle decisions, a PGG based algorithm is used and it is integrated in our scheduler architecture.
The scheduler proposed delays low priority tasks to achieve lower energy consumption, so they are executed with a higher period during low battery level states, which gives large energy saving. However, this latency does not affect high priority tasks as they are executed in all conditions, even when battery level is low.
Finally, the adaptive scheduler presented has been implemented and tested in real WSN nodes. The results show higher latencies when using our scheduler compared to a round-robin for low priority tasks. On the other hand, large energy saving is achieved and we can increase nodes lifetime up to 71% depending on the scenario.
The OS scheduler proposed is useful in many WSN scenarios to prevent nodes running out of battery by delaying noncritical tasks, while keeping high priority tasks running. This could lead to controlled degradation mechanisms for network nodes as they could maintain just critical functionality before the nodes run out of battery.
The authors declare that there are no conflicts of interest regarding the publication of this paper.
This work was partially funded by the Spanish Ministry of Economy and Competitiveness, under RETOS COLABORACION program (Reference Grants SONRISAS: RTC-2015-3601-3, All-in-One: RTC-2016-5479-4 and EASYSAFE RTC-2015-3893-4), and the Spanish Ministry of Industry, Energy, and Tourism through the Strategic Action on Economy and Digital Society (AEESD) under DEPERITA: TSI-100503-2015-39 and SENSORIZA: TSI-100505-2016-10 projects.