Design and implementation of heterogeneous IOT gateway based on dynamic priority scheduling algorithm

Abstract

In practice, IOT (Internet of things) gateways are often used between sensor networks and the Internet to provide advanced services such as device monitoring and control. Sensor networks are connected to the Internet via these gateways based on various transmission protocols. In particular, the main features of IOT gateways are reliability, high real-time, security and so on. This paper proposes a heterogeneous IOT gateway based on dynamic priority scheduling algorithm. This gateway realizes data conversion and transformation between the Internet and sensor networks as well as several kinds of communication protocol: RS485, Bluetooth, CAN, Zigbee and GSM. To ensure the data security and reliability for IOT gateway, some higher-level protocols are designed and implemented on the gateway. A dynamic priority scheduling algorithm of a real-time system is also used in the gateway to address the problem of data concurrency and improve real-time performance by efficiently scheduling tasks. Simulation results reveal that the gateway realizes the data transmission between sensor networks and the Internet using specific higher-level protocols and response within a very short delay, achieving the goal of addressing the problem of data concurrency.

Keywords

Data transmission gateway IOT scheduling

Introduction

As part of future trends, the Internet of things (IOT) can not only help improve the combination of information industry and service management but also expedite the combination of the digital world and the physical world. With the development of IOT technology, the applications of IOT cover many fields, from infrastructure constructions, public safety, environment protection, modern agriculture and smart homes to commercial and other services. IOT consists of a large number of devices, including many sensors, which are monitoring the physical world and organized in the form of sensor networks.

To achieve the goal of remote data transmission and uniform device management, sensor networks are usually partially or entirely connected to the Internet and communicate with remote servers through the Internet. A gateway is usually used as a bridge connecting the Internet and sensor networks, working as a data conversion and transmission device based on different types of communication protocols. In addition, IOT gateways also provide services of device management to users through the Internet. However, there are some critical issues in IOT gateways. First, some gateways just simply convert and transfer data without a security check and integrity verification for the sake of lack of higher-level protocols. Security problems are worrying because sensors are usually exposed to the outside environment and prone to suffering from cyber-attacks. Second, the problem of how to address each sensor correctly still exists. An IOT gateway can be addressed by a universal IP address, but sensors connected to the gateway cannot be addressed individually. Commands or data should be forwarded precisely but in practice IOT gateways usually adopt a polling method or forward them to all the interfaces inefficiently. Finally, IOT produces a large amount of data every moment. This data includes sensor and command data. IOT gateways need to forward a large amount of data in a very short time, which requires IOT gateways to have the ability to handle mass concurrent data.

A few papers discuss and present the implementations of IOT gateways. Chen et al. (2011) proposed a reference model of an IOT gateway with three main attributes: multiple interfaces, protocol conversion and manageability, but the paper does not present definite implementation. Jiang et al. (2012) implemented a specific IOT gateway to enhance the function and traffic of a CDBS IOT system. Becher et al. (2010) described a wireless sensor gateway to monitor people’s health. Both of these two gateways can be used only in a certain field. Zhu et al. (2010) put forward a concept that a typical IOT application architecture including three layers: 1) a perception layer; 2) a transmission layer; and 3) an application layer. Based on Zigbee-GPRS protocols, the paper implemented a prototyping gateway but users could not access the sensor data intuitively unless they installed server software on their PC. Hwang et al. (2003) realized a novel gateway for wireless sensor management, which can be accessed through the World Wide Web and users need to login by authentication. This gateway realized uniform management to the sensor nodes and presented the sensor data in a visual and flexible way because the gateway had a built-in Web-based server. Although this literature realized a gateway that solves the problem of data conversion and transmission between sensor networks and the Internet, these gateways cannot guarantee the integrity and security of sensor data. In addition, these gateways can only process the sensor data from a single interface at a time, which means the multi-way concurrent data are not fully considered. For a real-time system, devices need to respond in time. For example, in an industrial field, if gateways do not finish the tasks on time, it may lead to catastrophic failures, and cause casualties and property losses. For soft-real-time tasks, time limitation is not necessary, but it will cause performance reduction if these tasks are delayed. If the sensor data from all interfaces come to the gateway simultaneously, the gateway has to handle all these data in turn and acts like breaking down, which cannot be accepted by users. In response to this problem, solutions to handling concurrent sensor data and scheduling the tasks on an IOT gateway efficiently remain for further study.

This paper proposes a novel heterogeneous IOT gateway based on a dynamic priority scheduling algorithm to solve the problems discussed above, especially the data concurrency problem. Based on the TCP/IP protocol, this gateway can access to the Internet through an Ethernet interface. On the other hand, this gateway can communicate with different sensor nodes using various data communication protocols and some higher-level protocols. Meanwhile, in order to address the problem of handling concurrent sensor data and make the gateway work more smoothly and efficiently, a dynamic priority scheduling algorithm is implemented on the gateway, which reduces the average response time and improved the performance of the IOT gateway.

This paper is organized as follows: the next section describes the overall scheme of the gateway including hardware and software architecture. Some higher-level protocols are also given. The dynamic scheduling algorithm is analysed and the algorithm on the gateway is realized. An experimental test is described and a conclusion about the work is given.

Proposed gateway architecture

As a connection between sensor networks and the Internet, the IOT gateway must have the ability to aggregate all the sensor data and upload it to remote servers through the Internet. The gateway must also forward the request command from remote servers to specific sensor devices to control them. Therefore, the IOT gateway must provide stable and flexible interfaces in practical applications. This gateway adopts a layered structure in order to improve the stability and reliability. It consists of three layers: a hardware layer, a software layer and a communication layer. The bottom layer is the hardware layer, which is an independent hardware installation as well as the physical realization of the gateway. It is the basis of the gateway. The middle layer is the software layer, providing the software with the implementation of the gateway and management to all the drivers of the chips. A lightweight TCP/IP protocol is also used in this layer, which is suitable for embedded systems. The top layer is the communication layer and it is responsible for main implementation of the logic function of the gateway. In this layer, data conversion and transmission operations are packed into independent tasks for later scheduling and the details will be discussed below.

Hardware layer structure

In IOT, there are various communication standards for different sensor nodes. Consequently, IOT gateways should try to be compatible with different communication protocols. Our proposed IOT gateway supports five types of data communication protocols: Bluetooth, Zigbee, GSM, RS485 and CAN. When sensor nodes connect to the gateway, these nodes and gateway constitute a control network, which can be controlled and monitored by remote users through the Internet. The gateway system is developed using STM32F107 as the processor. STM32F107 has 10/100 MAC with dedicated DMA and SRAM (4 kbytes). The chip has 64K SRAM and 256K Flash Memory. Its core is an ARM Cotex-M3, which is suitable for the IOT gateway. A chip called DP83848 (Ethernet Physical Layer Transceiver) is used to design the Ethernet interface circuits. Furthermoe, STM32F107 has five UART interfaces and two CAN interfaces. Taking advantage of this, the Zigbee Coordinator interface, GSM module interface, Bluetooth module interface, RS485 interface and CAN interface are realized respectively. The architecture of hardware layer is shown in Figure 1.

Figure 1.

Architecture of hardware layer.

Software layer structure

The second layer is the basic running environment, which supports the upper layer. This layer consists of drivers of all the components. Thus, on one hand, it is responsible for the management to the chips, including the initializations and settings for the chips as shown in Figure 2. There are in total six modules in the layer, including the Zigbee module, Bluetooth module, GSM module, RS485 module and Ethernet module. The Zigbee module is realized as a Zigbee Coordinator and it establishes the Zigbee communication network and controls the Zigbee nodes. STM32F107 communicates with the Bluetooth module through UART and it is served as master-device. The GSM module enables the gateway to send and receive AT commands for communication with sensor nodes. The CAN module can transmit data as a master-node using the CANopen protocol. The gateway can also communicate with sensor nodes using the RS485 protocol. Lastly, an Ethernet module is realized for which the gateway is used to connect to remote servers through the Internet. All of these modules are realized using standard STM32 official libraries. Furthermore, a lightweight TCP/IP protocol called the lwIP TCP/IP stack is implemented (Dunkels, 2001). The lwIP is known for its good performance in low-cost embedded systems. On the other hand, it is responsible for providing the upper layer (communication layer) with API by encapsulation implementation details.

Figure 2.

Software layer structure.

Realization of communication layer

A customized communication protocol is used in this layer. This protocol consists of a series of interaction standards and processes, in order to ensure the security and integrity of the sensor data. First, the gateway adopts some mechanisms to provide a more reliable connection between sensor nodes and the gateway. Usually, a sensor node will be tested to see whether it is connected to the gateway and working properly before requests or commands are sent to it. Nevertheless, when a test request is sent to a sensor that is out of order, the sensor may happen to send a correct confirmation back to the gateway. The gateway may think that the sensor is working properly. So, two or even more confirmations are necessary. Therefore, all the sensor nodes that are connected to the gateway have to carry out a handshake process with the gateway and we name this process the ‘four-way handshake’ protocol. On the basis of the first successful confirmation, the gateway will send a second different request to the target sensor node and test whether the sensor node is really ready. Second, in order to monitor all the sensor devices connected to the gateway easily and consistently as well as to reduce the time of the addressing specific sensor nodes, the gateway creates an address index table at the beginning of the system’s initialization. The table will record and maintain the current active connections of sensor nodes. Suppose every sensor has its own unique identifier. Once a sensor node successfully carries out a four-way handshake protocol with the gateway, the gateway will add the sensor’s identifier and its corresponding connecting physical interface to the index table. When the request command from remote server arrives, the gateway will first analyse the target sensor’s identifier from the contents of the data, and then query the index table to obtain the destination physical interface. If the record of destination physical interface is found, the gateway will forward data to the correct physical interface immediately instead of querying all of the sensor nodes, reducing the query time at the expense of using extra memory. Third, sensor data integrity and security are also essential so we put forward data format for transmission as shown in Table 1.

Table 1.

Data format.

Data size	Data content	Checksum
8 bits	8×(data size) bits	8 bits

Data size specified the number of bytes of data, a total of 8 bits, which indicates that up to 255 bytes of data can be sent in a packet. Data size can help divide the data stream into data packets. To prevent data from being tampering with or suffering from theft, raw data need to be encrypted before being encapsulated into one packet. Raw data will be encrypted using a symmetric encryption method, which means that the sender and receiver share the same key. The length of encrypted data is identical to the length of original data. Finally, in order to avoid data errors, data transmission protocol adopts checksum to check on the size of the data and encrypted data. Once such a data packet is received, the receiver first calculates the checksum to verify the data integrity. Then receiver can use the shared key to decrypt the data packet to obtain the original data.

Dynamic priority scheduling algorithm

Necessity of real-time scheduling

Generally, IOT gateways need to response to outside events in time so they can be classified into real-time systems. That means that the response time of the IOT gateway is limited. At the same time, IOT gateways act as a bridge between two networks, which need to deal with many concurrent data and handle many tasks. If the tasks are not scheduled properly, it may lead to the loss of system performance (Burns, 1991). At present, there are many task scheduling algorithms aiming at solving this problem on real-time systems, but these algorithms are hardly used in IOT gateways.

Using these real-time scheduling algorithms can fully utilize CPU resources to improve performance. In an IOT gateway, one of the most important issues is how to deal with the problem of data concurrency fairly. In practice, IOT gateways are connected to a large number of sensor nodes. Each connection between sensor node and gateway has a regular periodic communication. A common measure is polling each sensor node in turn; the inadequacy of this method is inflexible and unfair because a sensor node may occupy the processor most of the time if it is trying to send back mass data to the gateway. As a result, other sensor nodes are blocked until the transmission is completed, which affects the gateway’s normal operations. So it is necessary to adopt a method to prevent this phenomenon from happening or reduce the response time.

Description of dynamic priority scheduling algorithm

In the research of a real-time system, there are two types of task: hard-real-time tasks and soft-real-time tasks. Hard-real-time tasks must be completed before a fixed time while soft-real-time tasks do not have to. Real-time tasks can also be divided into two types: periodic tasks and aperiodic tasks. Periodic tasks will be released in a regular time and aperiodic tasks will emerge occasionally. So far, there are two acknowledged real-time scheduling algorithms that have become industrial standards. One is the optimal fixed priority scheduling algorithm called RM, which is short for rate monotonic (Katcher et al., 1993), the other is the optimal dynamic priority scheduling algorithm called EDF, which is short for earliest deadline first (Blazewiez, 1977). RM computes the priorities of tasks according to their periods. If the period of a task is shorter, then its priority is higher and RM always schedules the task with the highest priority. Obviously, RM is easy to implement. Suppose U is the utilization of processor and can be defined as:

U = \sum_{i = 1}^{n} \frac{C_{i}}{T_{i}}

(1)

In Equation (1), n is the number of total tasks number, C is the task’s execution time and T is the period of the task. Liu and Layland (1973) proved that all the tasks can be scheduled by the RM algorithm as long as U satisfies the expression below:

U \leq n (2^{1 / n} - 1)

(2)

When n approaches infinity, the value of Equation (2) is about 0.693, which means that the CPU load can be up to around 70%. EDF schedules tasks using priorities like th RM does, but EDF calculates the priorities of tasks based on the tasks’ deadlines. EDF assigns a higher priority to a task with an earlier deadline. So, the task closest to its deadline has the highest priority and EDF always chooses the task with highest priority to run. Because the priority of a tasking is not fixed, the priorities are calculated dynamically. Liu and Layland (1973) also give a conclusion that all the tasks can be scheduled if and only if U satisfies:

U \leq 1

(3)

According to Equations (1) and (3) we have:

\sum_{i = 1}^{n} \frac{C i}{T_{i}} \leq 1

(4)

In conclusion, the utilization can go up to 100% at most if EDF is used for scheduling. As for IOT gateways, every sensor node needs to communicate with the gateway periodically and has a hard real-time demand, but sometimes, some nodes need to have a further interaction with the gateway such as transforming mass log data. This case may happen randomly and cannot be predicted. In this case, the execution time of task is not fixed such that it makes the scheduling more complicated. To solve this problem, a mixed scheduling method should be used, such as SATSS (Yin and Guo, 2009) and the hybrid scheduling scheme (Tan et al., 2006), but these algorithms are more complicated and require more CPU resource. So this paper adopts another scheduling algorithm mainly based on EDF, which is called background tasks (Lehoczky et al., 1987) with low overhead. The main idea of this algorithm is described as follows: communication with each sensor node for each time is regarded as a task. The less important part of the task such as mass of data transmission that can be executed later is extracted and put into an independent soft-real-time task. These soft-real-time tasks do not have time limitations so they will be assigned with the lowest priority. As a result, soft-real-time tasks can be executed only when there are no hard-real-time tasks running. This algorithm can ensure the low response time of hard-real-time tasks in the IOT gateway. Meanwhile, it can prevent any burst data or aperiodic events from using the gateway’s CPU for long time. Soft-real-time tasks can be executed without affecting hard-real-time tasks.

Implementation of scheduling algorithm

In the proposed IOT gateway, every regular communication with each sensor node is treated as a periodic hard-real-time task. Usually, hard-real-time tasks only contain routine operations such as the four-way handshake protocol, which require fewer processor resources and lasts for a short time. The other operations can be executed in the soft-real-time tasks. Because the execution time of hard-real-time tasks can be measured in advanced, we can arrange reasonable periods for the tasks. While hard-real-time tasks are defined and their periods are established, extract bandwidth should be reserved for soft-real-time tasks because soft-real-time tasks execute the operations that have not finished in hard-real-time tasks. Every time when a hard-real-time is released or finished, the priorities of hard-real-time tasks will be calculated again and a new urgent hard-real-time task is selected to run. Since there may be more than one soft-real-time task, the scheduling problem in soft-real-time tasks still exists. So in order to schedule the soft-real-time tasks fairly and quickly, the scheduling policy is randomly to choose one of the soft-real-time tasks that are waiting to be scheduled. The overall scheduling flow chart is shown in Figure 3. Every time when scheduling starts, the hard-real-time tasks will be scheduled first and soft-real-time tasks can only be scheduled in the case of no hard-real-time tasks.

Figure 3.

Flow chart of tasks scheduling in Internet of things (IOT) gateway.

Experiment and test results:

In order to demonstrate the performance of the scheduling algorithm, we use MATLAB programming to simulate the process of scheduling. A system model is proposed under the following assumptions:

Each task is independent and there are no shared resources.

Each hard-real-time task is released at the beginning (release time=0).

Each hard-real-time task must be completed before it occurs next time.

Each hard-real-time task is preemptive.

Execution time of each task is constant.

Single processor is used.

Each soft-real-time task has no deadline and it may occur only after the completion of last released.

For the sake of simplicity, we use h=(C,T) to represent a hard-real-time task while C is the execution time and T is the period and use s=(C, r) to represent a soft-real-time task while C is the execution time and r is the probability of the task being generated by a hard-real-time task. Let $t$ be the elapsed time, then t can be represented as:

t = t_{r} + t_{i}

(5)

where $t_{r}$ denotes the CPU running time and $t_{i}$ denotes the CPU idle time.

CPU utilization can be represented as:

U = \frac{t_{r}}{t} = \frac{t - t_{i}}{t}

(6)

Design of tasks

According to Equation (4), the EDF algorithm can successfully schedule the tasks if and only if the utilization of tasks is not larger than 1. Furthermore, extra bandwidth should be reserved for the soft-real-time tasks. Hence, the design of tasks should be considered carefully. Tables 2 –5 show the details of tasks. Each task set in the simulation consists of six hard-real-time tasks and six soft-real-time tasks. In particular, we design in total four task sets. Task Set 1 only contains hard-real-time tasks where all the work is handled, so the execution time is very large and the utilization is about 90%. In order to compare the difference between EDF and this algorithm, we design Task Set 2. Task Set 2 separates soft part of the work into soft-real-time tasks by setting the probability to 100%. That means when a hard-real-time task is released, it generates a soft-real-time task that handles the soft part of the work. As for Task Set 2, a soft-real-time task is generated if: 1) a corresponding hard-real-time task is released; 2) no such a soft-real-time task is running. When a hard-real-time task is released, a previous soft-real-time task may still exist due to most of the CPU resources assigned to hard-real-time tasks. As a result, the generated times of soft-real-time tasks is equal or less than the released times of hard-real-time tasks. Hence $t_{r}$ of Task Set 2 is equal or less than that of Task Set 1. According to Equation (6), CPU utilization of Task Set 2 is equal or less than Task Set 2. Task Set 3 also separates soft part of the work into soft-real-time tasks and it can reduce the response time of hard-real-time tasks. In Task Set 3, the probability of generating every soft-real-time task is 5% to simulate the practical operations and we arrange the hard-real-time tasks with 67% of CPU utilization. In Task Set 4 we design the tasks to simulate the situation in which the gateway has to interact with the outside a lot by setting the probability to 10%.

Table 2.

Details of Task Set 1.

Module	Hard-real-time	Soft-real-time
CAN	h1=(17,120)	s1=(0, 0%)
Bluetooth	h2=(17,120)	s2=(0, 0%)
GSM	h3=(17,130)	s3=(0, 0%)
RS485	h4=(17,120)	s4=(0, 0%)
Zigbee	h5=(17,120)	s5=(0, 0%)
Ethernet	h6=(17,80)	s6=(0, 0%)

Table 3.

Details of Task Set 2.

Module	Hard-real-time	Soft-real-time
CAN	h1=(2,120)	s1=(15,100%)
Bluetooth	h2=(2,120)	s2=(15,100%)
GSM	h3=(2,130)	s3=(15,100%)
RS485	h4=(2,120)	s4=(15,100%)
Zigbee	h5=(2,120)	s5=(15,100%)
Ethernet	h6=(2,80)	s6=(15,100%)

Table 4.

Details of Task Set 3.

Module	Hard-real-time	Soft-real-time
CAN	h1=(2, 20)	s1=(15, 5%)
Bluetooth	h2=(2, 20)	s2=(15, 5%)
GSM	h3=(2, 30)	s3=(15, 5%)
RS485	h4=(2, 20)	s4=(15, 5%)
Zigbee	h5=(2, 20)	s5=(15, 5%)
Ethernet	h6=(2, 10)	s6=(20, 5%)

Table 5.

Details of Task Set 4.

Module	Hard-real-time	Soft-real-time
CAN	h1=(2, 20)	s1=(15, 10%)
Bluetooth	h2=(2, 20)	s2=(15, 10%)
GSM	h3=(2, 30)	s3=(15, 10%)
RS485	h4=(2, 20)	s4=(15, 10%)
Zigbee	h5=(2, 20)	s5=(15, 10%)
Ethernet	h6=(2, 10)	s6=(20, 10%)

Simulation of scheduling

Task Set 1 is tested and the result is shown in Figure 4. In Figure 4(a), the CPU utilization is about 90%. In Figure 4(b), the average response time of hard-real-time tasks is very large because all the work is done in hard-real-time tasks. In particular, the response time of task h5 goes up to 80 units of time because ‘First In First Service’ is used to schedule the task with identical priorities. In Figure 5, the scheduling result of mixed tasks is given. In Figure5(b), we can see that after the soft part of the work is extracted from hard-real-time tasks, the response time of hard-real-time tasks become as small as less than 10 units of time while the average response time of soft-real-time tasks is a little higher than that in Figure 4(b). We can also notice that the CPU utilization of Task Set 2 is about 5% less than that of Task Set 1 as shown previously. In Task Set 3, the parameters are adjusted to simulate the practical application. So in Figure 6(a), we can see that the CPU utilization is below 80% at first because not all soft-real-time tasks have been generated. After a while, CPU utilization is stabilized at 90%. In Figure 7(a), nearly 100% of CPU utilization is used, which indicates the CPU is under high workload. In Figure 7(b), the average response time of soft-real-time tasks is 15 times larger than their execution time and even higher than that in Figure 6(b), but the average response time of hard-real-time tasks is still very small, which implies that the gateway works efficiently under high workload. From all the results, we can see that after using this algorithm, the average response time of hard-real-time tasks remains at a lower level, but compared with EDF, the CPU utilization decreases.

Figure 4.

Results of simulating scheduling Task Set 1: (a) CPU utilization; (b) average response time.

Figure 5.

Results of simulating scheduling Task Set 2: (a) CPU utilization; (b) average response time.

Figure 6.

Results of simulating scheduling Task Set 3: (a) CPU utilization; (b) average response time.

Figure 7.

Results of simulating scheduling Task Set 4: (a) CPU utilization; (b) average response time.

Conclusion

In this paper, we propose an IOT gateway system. As a bridge between sensor networks and the Internet, this gateway has three main features. First, it can support six types of communication protocols including RS485, Zigbee, Bluetooth, GSM, CAN and Ethernet. Second, some higher-level communication protocols are implemented, which can ensure data security and integrity, and expedite the addressing process of each sensor node by maintaining an index table. Third, a dynamic priority scheduling algorithm is adopted to address the problem of data concurrency and tasks scheduling.

The dynamic priority scheduling algorithm is mainly based on a mixed scheduling algorithm. The work of the gateway can be classified into hard-real-time tasks and soft-real-time tasks. The proposed gateway preferentially schedule hard-real-time tasks, which handle the urgent part of the work. Other work like log data transmission, which requires much of the CPU resources, is moved to soft-real-time tasks scheduled randomly.

Experimental results show that the gateway has a good performance under multi-way connections and it can efficiently communicate with each sensor nodes. Using the dynamic priority scheduling algorithm can reduce the average response time of hard-real-time tasks, but the average response time of soft-real-time tasks may be enlarged if CPU is under a high workload. In future work, we will study how to improve the performance by scheduling the soft-real-time tasks and put more emphasis on handling shared data.

Footnotes

Funding

This research received no specific grant from any funding agency in the public, commercial, or not-for-profit sectors.

References

Becher

Mühle

Ruff

. (2010) Design and realization of a wireless sensor gateway for health. 32nd Annual International Conference of the IEEE EMBS, pp. 374–377.

Blazewiez

(1977) Deadline scheduling of tasks – a survey. Foundations of Control Engineering 203–216.

Burns

(1991) Scheduling hard real-time systems: a review. Software Engineering Journal 6: 116–128.

Chen

Jia

(2011) A brief introduction to IOT gateway. IET International Conference, pp. 610–613.

Dunkels

(2001) Design and implementation of the lwIP TCP/IP stack. Swedish Institute of Computer Science, 20 February.

Hwang

Park

. (2003) A design and implementation of wireless sensor gateway for efficient querying and managing through World Wide Web. IEEE Transactions on Consumer Electronics 49: 1090–1097.

Jiang

Nie

. (2012) An enhanced IOT gateway in a broadcast system. International Conference on Ubiquitous Intelligence and Computing and 9th International Conference on Autonomic and Trusted Computing, pp. 746–751.

Katcher

Arakawa

Strosnider

(1993) Engineering and analysis of fixed priority schedulers. IEEE Transactions on Software Engineering 19(9): 920–934.

Lehoczky

Sha

Strosnider

(1987) Enhanced aperiodic responsiveness in hard real-time environments. In: Proceedings of the Real-Time Systems Symposium 1(3): 261–270.

10.

Liu

Layland

(1973) Scheduling algorithms for multi-programming in hard real-time environment. Journal of the ACM 20(1): 46–61.

11.

Tan

Jin

Zhang

(2006) A hybrid scheduling scheme for hard, soft and non-real-time tasks. Ninth IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing.

12.

Yin

Guo

(2009) An algorithm for scheduling aperiodic real-time tasks on a static schedule. Second International Conference on Information and Computing Science 1: 70–74.

13.

Zhu

Wang

Chen

. (2010) IOT gateway bridging wireless sensor networks into Internet of Things. 2010 IEEE/IFIP International Conference on Embedded and Ubiquitous Computing, pp. 347–352.