Abstract
Wireless sensor networks (WSNs) find applications in the industrial automation where periodic and sporadic events occur. The combined propagation of information generated by periodic and sporadic events from a sensor node to an actuator node is challenging due to random nature of sporadic events, particularly, if the deadlines are hard. The IEEE 802.15.4 standard provides the basis for a real-time communication mechanism between neighboring nodes of the WSN at the media access control layer. However, the standard does not address such communications over multiple hops. To support the industrial applications with such requirements, this work proposes a novel online control protocol that exploits the basis provided by the IEEE 802.15.4 standard. The proposed control protocol ensures that a given offline sporadic schedule can be adapted online in a timely manner such that the static periodic schedule has not been disturbed and the IEEE 802.15.4 standard compliance remains intact. The proposed protocol is simulated in OPNET. The simulation results are analyzed and presented in this paper to prove the correctness of the proposed protocol regarding the efficient real-time sporadic event delivery along with the periodic event propagation.
1. Introduction
Industrial automation, body sensing, and home automation are a few examples that require hard real-time data propagation [1–3]. In such environments, there are events requiring real-time actuation. For example, in home automation the press of a switch and the actuation require real-time response, in body sensor networks detection of an event indicating a threshold violation requires real-time response, and in an industrial environment the detection of a contaminated food product on a conveyor belt and the actuation of a robotic arm to remove the product require a hard real-time response.
For this study we considered an industrial environment where the sensor nodes, fixed at predetermined positions in an industrial setup, sense events and propagate information to other nodes for real-time actuation decisions. If the actuation nodes are multihop away, data propagation may be across multiple clusters, requiring real-time communication tasks on each of the intervening nodes. Distributed scheduling of such tasks is a complex undertaking as it involves multiple sensing and communicating nodes.
In this regard, two distinct bodies and work are identifiable in the literature. First is the generation of real-time distributed schedules, which is performed offline and is based on the knowledge of source and destination of the data and the periodicity of periodic events or the maximum frequency of the sporadic events. Second is the allocation of resources according to an offline schedule to enable control protocols for real-time operations. For periodic events, the problem scope is limited to the bandwidth allocation before network convergence. However, sporadic events require a real-time control protocol which can be used to adapt the generated schedule in a distributed environment, such as a wireless sensor network (WSN), reactively at the occurrence of a sporadic event within an existing periodic schedule.
Routing is also of great importance [4]. If there is a single sink for all of the events, then the routing is relatively simple. However, if destination of each sporadic event is distinct, routing decisions are complicated. The scarce resources of WSN (energy, processing power, and memory) complicate the design of the routing protocol. Due to hard real-time requirements of sporadic tasks and the distributed nature of the WSN, routing poses significant difficulty in the design of such a control protocol, if the nodes are scarce in memory, as is the case with WSN. The requirements to preserve static schedules of periodic tasks add to this difficulty as care must be taken not to disturb such schedules while reactively allocating resources for sporadic events.
The IEEE 802.15.4 standard provides mechanism for real-time communication between two neighboring nodes through the use of guaranteed time slot (GTS) mechanism at the MAC layer. Being a MAC layer protocol, the IEEE 802.15.4 standard does not propose any routing mechanism for multihop propagation, which it leaves to higher layers. Hanzálek and Jurčík [5] have adapted the GTS mode of the IEEE 802.15.4 standard to generate the cyclic schedule for periodic real-time propagation information to destinations that are multihop away, using offline cluster scheduling techniques. In our prior work reported in [6], we proposed offline and online techniques by using the IEEE 802.15.4 standard for sporadic tasks scheduling. However, the proposal was for root of cluster tree being used as the destination of all of the sporadic events.
In this paper, we propose a control protocol for joint propagation of both the periodic and sporadic events from any node to any other node, efficiently, over multiple hops. The aforementioned enables a distributed decision-making process by any node based on the information that it can receive from one or more of the sensing nodes. To achieve this, an offline scheduling technique, laxity calculation, and an online acceptance test were to be devised and were contributed by this paper. The protocol was made energy efficient by many implicit decisions.
The remainder of the paper is organized as follows. Section 2 provides a high level discussion of the related works. Section 3 introduces the relevant sections of the IEEE 802.15.4 standard. Section 4 describes the proposed protocol. The IEEE 802.15.4 standard compliant data-structure modifications are given in Section 5. Results of the simulations have been discussed in Section 6. Section 7 concludes the paper giving future directions.
2. Related Work
The WSNs provide a distributed system of computing and communicating nodes. Different network topologies and various MAC layers have been developed for such a communication as per requirement. The IEEE 802.15.4 standard specifies a MAC layer specification for low-power devices that also support the basic real-time communications. The ZigBee has adapted the IEEE 802.15.4 standard as the MAC layer for communication. In this regard, the research community has come up with techniques for real-time scheduling of tasks for centralized and distributed system on the basis of the IEEE 802.15.4 standard. Such techniques can be adapted for the scheduling of real-time communications. Most of the research, in this regard, is focused on task scheduling.
In [7–11], researchers have explored generic real-time scheduling techniques. Ideas from these efforts are used in the current work for sporadic event propagation, by using the IEEE 802.15.4 standard.
In this respect, Isovic and Fohler [10] proposed the concept of “spare capacity” calculated offline and used online for sporadic event handling.
In [8, 9], Isovic and Fohler proposed the mathematical analysis of offline and online techniques to schedule a mixed set of periodic, aperiodic, and sporadic tasks, by using modified Earliest Deadline First (EDF) algorithm. Their proposal is for the scheduling of tasks on a single node not related to the 802.15.4 standard or WSN. Therefore they have not proposed any control protocol for use with the WSN.
The work of Jurick et al. [12] helps in determining the resource requirements in a cluster tree of a WSN. It does not, however, propose any routing or resource allocation protocol. The work of Koubba et al. [13] proposes improved CSMA/CA parameters for prioritized data transmission through the CAP which can be used for the GTS request forwarding required for the sporadic event resource allocation.
Hanzálek and Jurčík [5] have proposed the time division cluster scheduling (TDCS) technique for distributed scheduling for multihop periodic flow propagation. They have not dealt with the sporadic tasks scheduling and have no proposal for any online control protocol for schedule propagation. We have used their work to schedule sporadic tasks.
Nastasi et al. [14] also proposed an offline extra bandwidth allocation scheme and an online reallocation for the sporadic events. However, the multihop information propagation and the control protocols for the framework were not covered.
Kunert et al. [15] proposed a multichannel MAC for the diversity and reliability through the use of redundancy and concurrency in the frequency domain. The proposal was for a single cluster network periodic traffic handling and exhibited energy efficiency. The tasks scheduling are not considered.
Semprebom et al. [16] proposed a scheme to deal with the GTS starvation due to limit of maximum seven GTSs imposed by the IEEE 802.15.4 standard. The PAN coordinator receiving more than seven GTS requests decides how to accommodate all the requests. However, the work did not address any scheme pertaining to the multihop real-time communication and it did not deal with the control protocol to adapt a schedule reactively.
Choi and Lee [17] have proposed a multihop event propagation mechanism. It proposes a scheme for multihop GTS allocation by modifications in beacon and data frames to carry the destination information for bandwidth allocation. However, it differs from our work in that we provide GTS request success guaranteed by offline bandwidth estimation and reservation for online use. Additionally, we use implicit GTS allocation and deallocation scheme which makes our proposal energy efficient. These qualities make the efficient propagation of SE possible.
In our previous work [6], we proposed a control protocol and an acceptance test for root-oriented sporadic event propagation. Our proposed work simplified the routing decisions and consequently the control messages while guaranteeing the deadlines. However, the work does not provide any-to-any event propagation. This work proposes a novel mechanism for the propagation of SEs from any node to any other node. If there are any prescheduled PEs, their deadlines are not disturbed if a feasible SE is accepted for propagation. Many people like Awais et al. [18] are working for energy efficiency which is also a major area of work for WSN nodes being scarce in battery source. Due to multiple implicit decisions, control traffic is kept low which makes it energy efficient.
3. Introduction to the 802.15.4 Standard
The IEEE 802.15.4 standard provided a wireless communication mechanism between low powered devices. The Abbreviations Section provides the list of abbreviations and their definitions used throughout this paper. The standard provides different modes of operation for different application requirements. The beacon enabling mode described in the standard is for applications requiring best effort, as well as real-time communication services between neighboring nodes. The mode is cluster based with one node acting as the cluster head (CH). All of the communication between the two nodes during this mode is through the CH. The CH generates periodic beacons for synchronization. The time between consecutive beacons is called the beacon interval (BI). As shown in Figure 1, the BI is divided into two periods: (a) active period, Tag A, and (b) inactive period, Tag B. During the inactive period, the cluster sleeps to save energy. No intracluster communication is possible in such a period. The active period is where the actual communication is possible. The time immediately following the beacon frame is the contention access period (CAP) (Tag C). This is the time during which the nodes can contend to communicate, using carrier sense multiple access/collision avoidance (CSMA/CA), and support the best effort service. After the CAP and before the inactive period, is the TDMA based contention free period (CFP), Tag D. Any node desiring to communicate during such a period must get a slot allocated to it before any communication. The CH is the entity that allocates the time slots during such a period. The allocated slots are called the guaranteed time slots (GTS). The slot during which a node can send data to the CH is called the transmit GTS (T_GTS, represented by up arrow) and the slot during which the CH can send data to the other node of the cluster is called the receive GTS (R_GTS represented by down arrow).
In a cluster tree topology, more than one clusters can partially overlap with each other. These overlapping clusters have a common collision domain; therefore, the nodes of one cluster can communicate when the nodes of the neighboring cluster are asleep. The aforementioned results in the avoidance of collision due to the communications going on in the neighboring clusters. The aforementioned phenomenon can be observed in Figure 1, where the inactive part of Cluster 1 is overlapping with the active part of Cluster 2. In this way, the data can traverse many clusters to reach the destination that may be multiple hops (particularly many clusters) away. The scheme has been adapted by [5] to generate cyclic schedule for periodic flows to carry data from the source to destinations that are many clusters away.
3.1. Addressing and Routing in the 802.15.4/ZigBee and the Routing Module (RM)
The nodes within a WSN are identified on the bases of unique addresses. The routing decisions, among other parameters, are dependent on the type of addresses used. The address of a node with the IEEE 802.15.4/ZigBee cluster tree is hierarchical and is calculated, using the function. The function is explained in [19] and is defined as follows: where denotes the maximum number of children of a ZigBee Router (ZR), represents depth of the network, is the maximum number of routers of a ZR, and provides the network depth of the current node.
In a cluster tree topology of a WSN, the routing decisions are not based on the routing tables. Such decisions are made on the analysis of the destination address that are inherently hierarchical. A packet arriving at a node is either forwarded to the parent node or to one of the child nodes, depending on the destination. Suppose is the address of the node making the decision, is the address of the parent, and is the destination address of the packet received by an intermediate router . Consequently which is the next hop address of a packet received by a node is calculated based on (2) that is given below: As we know, routing is the responsibility of the network layer, as indicated in Figure 2. The RM uses (2) for the next hop calculation and is invoked to serve the purpose whenever a packet is needed to be routed.
4. The Control Protocol for Any to Any (A2A) GTS Allocation (CPAGA)
In our previous work [6], we showed that, in a cluster tree topology, when the root of the tree is the designated sink of sporadic data, then every node receiving a sporadic packet must forward the data to its parent. Therefore, the routing decisions are straight forward and the packet will ultimately reach the root (the designated sink of sporadic data). For data to be moved to the parent of a node, the GTS request primitive is used at each of the hops to allocate the GTS and the packet is forwarded in the allocated slot.
When the root is not necessarily the destination, then the data routing decisions are to be made at each of the nodes en route for the destination. The routing decisions are made by the RM and are relatively complicated, as the next hop is either the CH of a node or a child if the node itself is CH. However, the hierarchical addressing makes next hop calculation relatively simple as represented by (2). Section 4.2 explains the proposed control protocol. This protocol employees (2) for route calculation.
4.1. Offline Spare Capacity Allocation
The Spare capacity (SC) is the spare space allocated within a CAP during an offline scheduling. The quantity of the SC in a particular cluster depends on the parameters of the expected SEs of the node. These parameters are used during the offline schedule calculation by an offline scheduler (OS). Therefore, the resultant CAP is sufficient to accommodate all of the feasible SEs. If an SE occurs at a node, then the node sends a GTS request to the corresponding CH, which in response allocates space from the SC of the CAP. Such an allocation request never fails due to the presence of adequate SC within the CAP.
Although the SEs are aperiodic events, by considering a hypothetical period equal to the maximum occurrence frequency, the OS is able to generate a worst case schedule, in which all of the SEs can be accommodated. If the schedule is feasible, then the generated schedule will be such that the delay of the sporadic tasks will be less than or equal to the deadline of these tasks as can be seen in Figure 4. Next, we define a term Laxity that is a binary decision variable, which is equal to “zero,” when there is no cushion between the deadline and the delay, and the schedule cannot be delayed. The laxity is equal to “one,” if there is sufficient cushion between the deadline and delay and the delay of particular SE can be extended to include another BI. The laxity calculation is detailed in [6] and is used to devise the online feasibility test that is one of the contributions of this work and is described in Section 4.3.
4.2. Packet Routing and OnLine Reactive GTS Reservation
When every sporadic packet has to have a different destination, then the routing decisions must be made at each of the nodes en route for the destination. The routing decisions are made at the RM at the network layer, as shown in Figure 2. Whenever a sporadic packet reaches the MAC layer of a node from another node, the packet is forwarded to the RM to decide the next hop. The next hop might be the parent or the child of the current node. Consider the network shown in Figure 3(a) and the corresponding tree that is reported in Figure 3(b), which is composed of three clusters, named Cluster 1, Cluster 2, and Cluster 3. A SE occurs at node N1 and must traverse the clusters to reach the sink node N2. As for the RM decision, three types of GTS allocation protocols are followed: (i) upstream allocation (for a node to its parent), as shown in Figures 3 and 4 at Tag A, and (ii) downstream allocation (for a node to its children), as shown in Figures 3 and 4 at Tag B. There is also a third type of GTS allocation protocol that is the hybrid of the two aforementioned basic cases, as shown with Tag C in Figures 3 and 4.
(a) Cluster tree
(b) Tree structure
Figure 4 shows the corresponding GTS allocations at various stages of the cluster traversal. Tag A, Tag B, and Tag C correspond to both of Figures 3 and 4.
In the following paragraphs, we describe the proposed protocol to be implemented to handle the above mentioned three cases.
Upstream GTS Allocation/Inflation. A sporadic event occurs at N1 and the corresponding RM decides that the next hop of the data packet towards the destination is R4 (the parent of the current node). The data can be sent to the designated next hop R4 during the CFP of Cluster 1, of which the designated node is the CH. To realize this, the sporadic packet needs a T_GTS to be allocated for N1 by R4. Therefore, N1 uses the GTS request primitive to request R4 for the allocation of a T_GTS in the forthcoming beacon interval.
Due to the reception of the GTS request and the resultant GTS allocation (Tag A in Figure 4), R4 comes to know that it will receive a sporadic packet in the next BI.
Downstream GTS Allocation/Inflation Protocol. When R2 receives an unsolicited GTS allocation in a beacon frame, R2 finds (with the help of RM) that it will receive a sporadic packet in the forthcoming BI. The RM of the node finds that N2 (which is one of its children) is the next hop for the sporadic packet. Therefore, R2, implicitly allocates a R_GTS in the next beacon. Tag B in Figure 4 represents resultant R_GTS allocation.
Hybrid GTS Allocation/Inflation. After the receipt of GTS request from N1, the next beacon from R4 contains a T_GTS allocated to N1. Therefore the N1 will send the sporadic packet during the forthcoming beacon period through the T_GTS, to R4. The R4 (due to the receipt of GTS Request from N1) analyzes that the PC will be the next hop for the sporadic packets under consideration. Therefore the R4 implicitly sends a GTS Request towards the PC for a T_GTS to be allocated beforehand. The PC, upon the reception of such a GTS request, finds (using RM) that the PC must also allocate an R_GTS to the R2, as it will be next hop for the packet. Therefore, the PC allocates an T_GTS for R4 and an R_GTS for R2. Such a twin allocation by the PC, in response to the implicit GTS Request from R4, is referred to as the Hybrid GTS allocation and is represented by the Tag C in Figures 3 and 4.
Therefore, according to this proposal, it may be observed that for the upstream GTS allocation we suggest explicit or implicit GTS request. Whereas, the downstream GTS requirement of a node is fulfilled implicitly when a node receives a beacon from the CH. Because such a GTS is received without a corresponding GTS request, we refer to it as an unsolicited GTS allocation. The above mentioned technique does not violate the IEEE 802.15.4 standard, as a CH can allocate/de-alloate the GTS on its discretion.
4.3. Timeline Guarantees
In the design of hard real-time systems, it is necessary to ensure that whatever deadlines are set aside for a task set, deadlines must be met or otherwise the task set should not be accepted for execution. The aforementioned phenomenon is decided by performing an online acceptance test at the occurrence of an SE and is another contribution of our study. The acceptance test determines whether an event must be accepted for propagation or not.
The OS performs a feasibility test offline to generate a schedule. The resultant schedule is such that if followed exactly, then the periodic and sporadic tasks are guaranteed to meet the deadlines. The GTS allocation for the PEs is done during the network convergence. Consequently the order of the GTS is exactly followed. On the other hand, for the SEs, the order of the GTSs for a particular cluster is exactly unknown. This is because the GTS allocation is reactive and is actually performed one BI earlier than the BI in which the actual transmission will be done. Moreover, the effective delay depends on two issues: (i) the time of occurrence of SE and (ii) the position of the GTS that is allocated at the last cluster. The position of the GTS within the clusters other than the last cluster is irrelevant. The only surety that a packet will be delivered within the assigned BI is sufficient. Figure 5 represents the snapshot of last-hop BI for a typical scenario.
(a) Periodic GTSs
(b) One sporadic GTS beyond deadline
(c) A GTS before and after deadline
Figure 5(a) represents the GTS allocation at the last hop of the sporadic packet route. There are three T_GTSs and one R_GTS. All these slots are for PEs. Figure 5(b) shows one shaded GTS labeled as ① that is allocated in response to a GTS request for a SE from node . This is the sporadic R_GTS. The vertical dotted line within the GTS represents the deadline. It may by observed that the position of the R_GTS is beyond the deadline. Therefore, the deadline will be missed, as the deadline is before the completion of the particular R_GTS labeled as ①. Figure 5(c) shows two shaded GTSs, labeled as ① and ②. The GTS ② was for an SE of a node other than N1, allocated prior to ①. Due to such an allocation, the GTS allocated in response to a GTS Request from N1 is the GTS ① that is earlier in time than ① in Figure 5(b). Because the deadline is beyond the R_GTS, as can be seen in Figure 5(c) labeled ①, the deadline will be met. However, the position of the GTSs cannot be determined before the occurrence of the SE. Therefore, the guarantee of delivery of the respective SE cannot be provided. The only condition sufficient to guarantee a deadline will be as follows: if a deadline is beyond the CFP of the last cluster (as shown with encircled 3, in Figure 5(c)), then the deadline will be met. Such a condition can be determined by the OS, by the use of laxity. The OS, after generating the schedules of the BIs, checks to see whether any deadline is beyond the CFP of the last cluster. If the SE is feasible and the corresponding schedule is generated to be adapted online, then the laxity that is determined offline can be used online, as described in our prior work [6], for performing online acceptance test at the occurrence of a SE.
The Acceptance Test. While generating a schedule, the OS does not take into account the time of occurrence of an event. The OS treats the SEs as the PEs to generate a schedule of clusters, if one is possible. For the PEs, the schedule is followed by statically allocating the GTS slots for various nodes within the respective clusters, before the network convergence. However, for the SEs, the required GTS slots are not allocated until the SE actually occurs. From the above discussion and closely observing Figure 4, it can be determined that a sporadic packet may have to wait for the GTS allocation only at the first hop (from N1 to R4). The aforementioned phenomenon is due to the fact that after the occurrence of a SE, the relevant data can be sent in the GTS allocated in response to the first GTS request sent by N1 to R4. As was detailed in [6], if the event occurs somewhere within the CAP period such that there is ample amount of time that a GTS request can be sent before the start of CFP, then the GTS request will be sent and will get the GTS allocation in the forthcoming beacon; otherwise, the GTS request will be sent during the CAP of the next BI and the packet must wait until the GTS allocation is received a beacon later. The GTS request initiates a chain of GTS allocations, resulting in an allocated GTS at each of the hops prior to the arrival of a sporadic packet at a node. The ultimate result is that the sporadic packet does not have to wait for the GTS allocation at any hop other than the first.
Therefore, even if the OS renders a set of events as schedulable, it cannot be guaranteed that the event will meet the deadline. This is due to the nondeterministic nature of GTSs that is decided online only. Suppose is the deadline calculated by the OS from the generated schedule, and (3) is used to implement the offline feasibility test;
Equation (4), on the other hand, is used to implement the online acceptability test: where represents time of occurrence of SE, gives the length of GTS request, and laxity is .
These equations govern the guaranteed delivery of the accepted SEs.
5. The CPAGA Implementation and the IEEE 802.15.4 Standard Compliance
The routing decisions are made at the network layer by the RM. In the original implementation of the IEEE 802.15.4 standard, the routing decisions are made when a data packet is received at the MAC layer depending on the destination of the packet. However, in the case of the CPAGA, there are other issues to be considered: (i) when a data packet is received, (ii) when a GTS request is received and, (iii) when a beacon is received. The implementation of the CPAGA requires changes in the algorithm at various levels and the related data structures of the IEEE 802.15.4 standard.
The CPAGA uses a reactive GTS allocation that requires an implicit and instantaneous GTS allocation for efficient bandwidth utilization. The RM produces the next hop address that a packet (data, GTS request, or beacon) uses to reach the destination. The RM needs the current node’s address and the destination address to calculate the next hop address. The current implementation of the GTS request and the beacon frame does not carry the destination address. Therefore,one must modify the formats. Moreover, modifications are needed in the algorithms that create and utilize such packets according to the CPAGA.
5.1. The CPAGA GTS Request
The main idea behind introducing the CPAGA GTS request and the corresponding GTS transmission/reception algorithm is to obtain sufficient space within the CFP for the propagation of the sporadic packets. After the occurrence of the SE at a node, the node creates an explicit GTS request and sends the request to the CH. The receiver of the request, if not the destination, implicitly generates a CPAGA GTS request and forwards the request to one of the neighbors towards the destination node. The RM decides the next hops. To include the destination node address, the GTS request packet fields must be modified. From the literature survey, we find that similar modifications were introduced by Koubba et al. [20], where they used the reserved 6th bit of the allocation type field of the GTS characteristics frame to carry the information of interest. We use the same technique to carry the destination address within the GTS Request. Therefore, the GTS characteristics frame is modified to carry the destination node address. The modified GTS characteristics frame consists of the fields, as shown in Figure 6(a).
(a) The GTS characteristics extension field format
(b) Destination address field
When the destination address is to be carried within the GTS request, the allocation type bit is set to one. This bit is set to zero by default. Therefore, when the receiver of the GTS request finds that the allocation type bit is set to one, then the receiver knows that the received GTS request is not a regular GTS request but is a sporadic GTS request. Therefore, the receiver can extract the destination address of the sporadic data that is to travel within the slot. The receiver uses the address for the proactive reservation of the GTSs.
The IEEE 802.15.4 Standard Compliant CPAGA Beacon Frame. The beacon frame usually contains information about one or more of the GTSs in response to the GTS requests from various children of the node in the GTS list field of the beacon frame. However, the CPAGA requires an unsolicited sporadic GTS allocation within a beacon frame, as described in Section 4.2. Such a sporadic GTS is to carry the address of the sink node along, with the GTS list. The default formation of the beacon is such that it contains a list of GTS descriptors. The GTS descriptor count field of the GTS specification field has the length equal to that of the GTS list. If the inflation flag bit of the GTS specification field is set to one, then the next byte after GTS list is bit-mapped sporadic specifier, equal in bit length to the descriptor count. Each bit of the bit-mapped sporadic specifier is related to one element of the GTS descriptor list, and if set to one, then it indicates that the corresponding GTS has a sporadic allocation. There is another list of the sporadic allocation parameters after the bit-mapped sporadic specifier. The length of the list is equal to the number of “ones” in the bit-mapped sporadic specifier. Each element of the sporadic allocation parameters is composed of two fields, namely, the splength and the daddress. The splength is the space of the GTSs reserved for sporadic data transmission and the daddress is the destination address of the sporadic data for which such an allocation has been made. This is the field on the basis of which implicit and reactive generation of a beacon is possible.
Special care has been taken while suggesting a modification in GTS specification and GTS descriptor list to keep CPAGA beacon frame, the IEEE 802.15.4 standard compliant. The modified beacon frame is shown in Figure 7. The third bit of the GTS specification is a “do-not care” bit according to standard but is defined as an inflation flag bit for the CPAGA usage. In the CPAGA, the inflation flag bit, if set to one, indicates the presence of extra information at the end of the GTS descriptor list. A node with the CPAGA implementation will be able to correctly interpret the standard beacon frame received from a node with the non-CPAGA implementation. This is because such a beacon will never contain the inflation flag bit of the GTS characteristics specifier set to one. Therefore, the interoperability will not be an issue. Similarly, the standard implementation can accept the GTS list sent by the CPAGA implementation.
(a) Modified GTS specifications
(b) Appended GTS list
Data Frame. The data frame already contains a field to hold the address of the sink node. Therefore, no modification is required in the data frame format for the CPAGA.
5.2. Sporadic Slot Deallocation/Deflation
The deallocation of the sporadic allocations is implicit. The allocation/inflation remains there for “one” BI, after which it is automatically considered deallocated by the child node, as well as the CH. For the purpose of automatic deflation, the nodes keep a record of the accumulated inflation size of a slot for all of the nodes. The deflation occurs after one beacon.
6. The Simulation and Comparative Study
In this section, we validate the proposed protocol by analyzing the simulation traces collected from OPNET. For the purpose of this study, a small network consisting of three clusters and six nodes as shown in Figure 8 was simulated. A larger sized network was not considered for simulation as analyzing messages of a small network was sufficient for validation. In the simulated network, the PEs generated by the node N11 and the SE generated by node R5 were tested to be feasible by the OS. The parameters of the feasible set of events are reported in Table 1.
The OS generates a schedule which can be followed by various clusters so that the event data arrives at the destination within the specified deadlines. Table 2 depicts the information related to the generated schedule. The GTS column of the table indicates the GTSs that must be allocated for periodic tasks during the network initialization.
The values in the GTS column are in the subscripted format like , where is the number of slots required for node . The subcolumns T and R under the GTS column represent the slots reserved for transmission or reception, respectively.
The simulation parameters are used to simulate the network as shown in Figure 8 by using the modified IEEE 802.15.4 standard. Simulation traces are collected and are presented in Table 3.
Before we start the analysis of the traces shown in Table 3, the following are a few conventions that we considered during the generation of Table 3.(i)The first column of the table has the row numbers for referencing. The second column shows the simulation time in seconds. The third column (src./dst.) represents the source and destination of a particular activity. The absence of a particular source or destination of an activity is represented by a hyphen.(ii)An encircled row number highlights a particular activity in that row.(iii)Activities related to the PEs are represented by italicized fonts.(iv)Activities related to the SEs are shown by bold fonts.(v)The beacon reception activity is shown as beacon rx[TRR]. The T or R in the square bracket represents the GTSs information contained within the received beacon. For example, [TTRR] represents that two transmit and two receive slots are allocated for the respective node. The or in a beacon represents either a sporadic or inflated GTS.
The table contains chunk of traces from time interval 3.640320 to 4.398720 secs. The eighth row shows the occurrence of sporadic event, at N11 at time 3.7 secs. The related data has to arrive at R6 within the deadline. For propagation of the sporadic event from N11 to R6, the event must traverse Cluster R3, Cluster R1, and Cluster R2 as can be seen in Figure 8. For the PE, the GTSs are allocated beforehand during the network initialization. The GTSs remain allocated until the end of the simulation period. In this respect, the periodic data is transmitted from N11 to R3 (Row 13), R3 to R1 (Row 26), R1 to R2 (Row 27), and R2 to R6 (Row 35). The data crosses two hops (Row 26 and Row 27) during a single BI of Cluster 1, as both of the nodes belong to Cluster 1. From R3 to R1, a transmit slot is required; whereas, from R1 to R2, a receive slot is required, where R1 is the CH. These two slots can be seen reserved at Row 37.
On the other hand, a sporadic event occurs, as shown at Row 18, within Cluster R5, and data is to reach R3 before the deadline. No GTS is allocated for such a traversal beforehand. Therefore, a GTS request can be seen at Row 19 in Cluster 2 from R5. This GTS request is sent by R5 to its R2. Consequently, a sporadic GTS is allocated when the next beacon is received, as shown in Row 31. Row 2, Row 16, Row 31, and Row 43 show that beacons are received from the CH of Cluster 2. Of these beacons, only the one received at Row 31 that is received after GTS request contains the sporadic GTS. Thereafter, it is implicitly deflated/unallocated. Therefore, sporadic data moves from R5 to R2 during the BI, as shown at Row 34. Because R2 is also a child node of Cluster 1, R2 generates an implicit GTS request during the CAP of Cluster 1, as shown at Row 24. The aforementioned phenomenon results in sporadic allocation/inflation of the GTS with the beacon received by R2 at Row 37. Therefore, the sporadic data that was received by R2 as in Row 34 now propagates to R1 and then to R3 during the same Beacon, as both R1 and R3 belong to Cluster 1. The node R3 being the destination of the sporadic data does not need to further propagate further.
The effective delays can be calculated from the time column of Table 3. It can be calculated from Row 35 and Row 13 of Table 3 that it takes secs for periodic data to reach the destination, where the deadline set aside was 0.5 secs. On the other hand, it can also be calculated from Row 39 and Row 34 of Table 3 that it takes secs for sporadic data to reach the destination, where the deadline set aside was 0.8 secs.
Timeliness and Energy Efficiency. The bar charts of Figure 9 have been plotted from the data collected from the simulation results. Figure 9(a) shows the timeliness of the periodic and sporadic data whereas Figure 9(b) gives the minimal increase in energy consumption when SEs are scheduled along with the PEs versus PEs only.
(a) Delay versus deadline for periodic and sporadic events
(b) Increase in energy consumption due to sporadic events
Simulation was run for 5 minutes during which 297 PEs were generated. In addition 127 SEs were also generated with their maximum frequencies, accepted, and delivered before the deadlines. It can be observed in Figure 9(a) that for both the PEs and SEs the effective delays is less than the set asides deadlines. The important point to be noted here is that bandwidth allocation of SEs was reactively done at the occurrence of SEs. Additionally the simulation was also run in the absence of SEs and the effective delay remained unchanged. Therefore, PEs are timely delivered irrespective of SEs. These observations reveal the correctness of control protocol which is invoked at each occurrence of the SE.
Figure 9(b) shows a 6% increase in battery consumption when SEs are accommodated along with the PEs. This increase in battery consumption is due to extra control and data traffic required to transmit 127 SEs during this run of 5-minute simulation. The increase is minimal due to the fact that many implicit decisions are taken during the protocol design and the control traffic is kept minimum.
The real-time scheduling of sporadic tasks, along with periodic tasks, requires work in two directions: firstly, to find schedule for processing and communicating tasks on different nodes of the network, such that the data can reach the intended destination on or before the desired deadline and secondly, to develop control protocol, so that the generated schedule can be adapted in the intended network reactively at the occurrence of sporadic event. Table 4 reports various research works [5, 6, 14–16, 20, 21], in this regard and their characteristics. Of these, [5, 6, 14–17, 20, 21] do not propose to any control protocol for sporadic tasks. The work of Choi and Lee [17] does not handle the sporadic events nor energy efficiency. Most of work, except [5, 6, 14, 15], does not provide techniques for end-to-end real-time multihop communication. Our proposal provides mechanism for joint propagation of both the periodic and sporadic events from any node to any other node, efficiently, over multiple hops.
7. Conclusions and Future Work
With the use of OS to generate schedule of sporadic tasks and the invention of the CPAGA, proposed in this paper, it makes it possible to implement this schedule over the IEEE 802.15.4 standard at the occurrence of sporadic event. The generated GTS parameters were such that there was enough spare capacity for the sporadic events whenever the events occurred. Moreover, the proposed acceptance test rejected the events that were unsure to meet the deadlines. Similarly, while remaining compliant with the IEEE 802.15.4 standard, we modified the control structures to propagate a sporadic event to the destination. The simulation analysis proved the validity of the proposed protocol.
The proposed acceptance test accepts sporadic tasks which can be ensured to meet the deadlines. However, to keep the test simple, the algorithm rejects some of the sporadic events that the algorithm found being unsure to meet the deadline.
More work is required to improve the acceptance test to be able to reduce the false rejections of sporadic events. Moreover, the sporadic allocation/inflation remains there for “one” BI only. Further work is required to extended it to desired number of beacons if the sporadic data cannot be fitted within one GTS of a cluster.
Abbreviations
| BACCARAT: | Bandwidth allocation for content based and context aware real-time application |
| BI: | Beacon interval |
| BO: | Beacon order |
| CAP: | Contention access period |
| CFP: | Contention free period |
| CH: | Cluster head |
| CSMA/CA: | Carrier sense multiple access/collision avoidance |
| CPAGA: | Control protocol for any-to-any GTS allocation |
| DIID: | Dynamic inflation implicit deflation |
| EDF: | Earliest deadline first |
| FFD: | Fully functional device |
| GTS: | Guaranteed time slot |
| OS: | Offline scheduler |
| PC: | PAN coordinator |
| PE: | Periodic event |
| R_GTS: | Receive GTS |
| RFD: | Reduced function device |
| RM: | Routing module |
| SC: | Spare capacity |
| SD: | Superframe duration |
| SE: | Sporadic event |
| SO: | Superframe order |
| T_GTS: | Transmit GTS |
| TDCS: | Time division cluster scheduling |
| TDMA: | Time division multiple access |
| ZR: | ZigBee Router. |
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.