Traffic Priority and Load Adaptive MAC Protocol for QoS Provisioning in Body Sensor Networks

. Body sensor networks (BSNs) carry heterogeneous traffic types having diverse QoS requirements, such as delay, reliability and throughput. In this paper, we design a priority-based traffic load adaptive medium access control (MAC) protocol for BSNs, namely, PLA-MAC, which addresses the aforementioned requirements and maintains efficiency in power consumption. In PLA-MAC, we classify sensed data packets according to their QoS requirements and accordingly calculate their priorities. The transmission schedules of the packets are determined based on their priorities. Also, the superframe structure of the proposed protocol varies depending on the amount of traffic load and thereby ensures minimal power consumption. Our performance evaluation shows that the PLA-MAC achieves significant improvements over the state-of-the-art protocols.


Introduction
Wireless body sensor networks (BSNs) are getting immense research interests worldwide as they make a paradigm shift in medical applications, and, in particular, health monitoring systems.With the advent of miniature, cost effective, and wearable sensor devices, they have attracted large amount of research time [1].BSNs provide the scope of early detection of critical health conditions and diseases.Nowadays, people suffer from many chronic diseases that require constant monitoring of health condition.By making the use of wireless body sensor network, a patient can be under constant monitoring without any restriction and expenses of being in a hospital.This process can be considered as the next step in enhancing the personal health care and in coping with the costs of the health care systems [2].Also, they can be deployed inexpensively in existing structures without IT infrastructure [3].The BSN technology can be used to help protect those exposed to potentially life-threatening environments, such as soldiers, first responders, and deep-sea and space explorers [4].It is also being used successfully for entertainment applications [5].
A BSN comprises of a number of biomedical sensor nodes which are placed on or implanted in a human body.These sensors collect various physiological data and transmit them to a coordinator node which in turn transmits the data to the main server via the Internet.BSNs primarily use a star topology (Figure 1) with a communication range of around 3 meters [6], and the sensors usually need to transmit data at relatively wide range of data rates from 1 Kbps to 1 Mbps [7].The two fundamental design challenges in BSNs are energy efficiency and quality of service (QoS) [8].And BSNs, which are deployed to permanently monitor human physiological parameters, must satisfy far more stringent quality of service (QoS) demands than those of other existing wireless sensor networks [9].Provisioning QoS such as reliability and timely delivery is very crucial for BSN.Most of the time, these sensors are very small in size and have low battery power; so, energy efficiency should also be maintained.Priority awareness is a significant matter in BSN as the various  data collected by the sensors can have different degree of importance and the resources are limited; so, emergency and highly important data packets should get a better chance to be transmitted.A number of medium access control (MAC) protocols have been proposed for provisioning QoS in BSN.IEEE 802.15.4 [10][11][12] (Figure 2) is a standard defining the specifications for the MAC layer of a low rate wireless personal area network (WPAN), which also provides a way for QoS provisioning in BSN.But the superframe structure of IEE 802.15.4 is not flexible and also the latency involved is high.BodyQoS [13] implements a virtual MAC to schedule and represent channel resources, which makes it radioagnostic.But there is no priority consideration and also high computational complexity is involved.ATLAS [14] proposes a traffic load aware MAC protocol where the structure of the superframe depends on the estimated traffic load.But it does not take priority into account.PNP-MAC [15] adopts the superframe structure of IEEE 802.15.4.It proposes an MAC protocol with preemptive slot allocation and nonpreemptive transmission and also takes priority into account.But it does not take traffic load into account; duration of the CFP period of its superframe structure is fixed.
In this paper, we propose a priority-based load aware MAC protocol for BSN where the data packets are served based on their priority and the superframe structure is dynamic.In the proposed MAC protocol, we categorize the data packets into four priority classes based on their data type and generation rate.Then, these packets are served according to their priority values.So, high priority and emergency packets are served first.The superframe structure of the protocol varies based on the traffic load as the number of slot allocations in the superframe structure depends on the traffic load.So, the superframe structure contains a large inactive period when the traffic load is low and the opposite when the traffic load is high.So, energy efficiency is also ensured.
The rest of the paper is organized as follows.In Section 2, we have discussed some related works and their limitations.Then, we present the network model in Section 3. In Section 4, we describe in detail the proposed prioritybased and traffic load adaptive MAC protocol for body sensor networks.The performance evaluation and results are presented in Section 5.Then, we conclude the paper in Section 6.

Related Works
The IEEE 802.15.4 [10][11][12] standard was specifically devised to support low power, low data rate networks where latency and bit rate are not so critical.Although the design environment was different for IEEE 802.15.4,as a response to the growth in wireless personal area network, many earlier works [16] adopted the IEEE 802.15.4 MAC protocol and its superframe structure to support the QoS requirements of BSNs.The superframe structure of 802.15.4 consists of a contention access period (CAP), a contention free period (CFP), and an inactive period (IP).The CFP period contains up to seven guaranteed time slots (GTSs), which limits the adaptive operation of BSN applications.Secondly, IEEE 802.15.4 does not have any mechanism for prioritizing among different applications, and low priority data can block the transmission of the high priority one, which can cause a severe problem in BSN.Thirdly, the requested GTS time slots are not allocated in the current superframe; they are scheduled to the next superframe, which increases the packet delay or latency.
LDTA-MAC [16] protocol improves some of the shortcomings of IEEE 802.15.4.The guaranteed time slots (GTSs) are not fixed, allocated dynamically based on traffic load.And also on successful GTS request, data packets are transmitted in the current superframe.But there is no consideration of the priority of the applications or backoff value of them.Also the CFP's and IP's durations are fixed.
BodyQoS [13] separates QoS scheduler from the underlying MAC implementation, and thus it does not suffer from the limited number of GTSs.However, BodyQoS uses nonpreemptive slot allocation schemes; so, high priority applications can be blocked by low priority applications.Also, separate MAC implementation can increase computational complexity.
ATLAS [14] proposes a traffic load aware MAC protocol where the superframe structure varies based on the estimated traffic load and uses a multihop communication pattern.But it does not take the priority of different applications into account.There is also no indication of backoff class depending on the priority to avoid collision and to let higher priority application request first.Also, managing four types of adaptive superframe structure depending on traffic load may become a computational load on the gateway.PNP-MAC [15] protocol is based on IEEE 802.15.4 superframe structure.It can flexibly handle applications with diverse requirements through fast, preemptive slot allocation, nonpreemptive transmission, and superframe adjustments.But the duration of CFP is fixed; so, if we have lower data rate, it will cause loss of time and energy for being awake on this period.Again if the data rate is high, then the fixed inactive period (IP) can cause many important and high priority data to wait for the next superframe.Here, if any data is generated during the IP, then it will be lost or have to wait, which is not viable for emergency data.Again the CAP period only takes request for GTS, not data packets; for some application, this period of delay can be significant.There is no balance between the priority consideration and traffic load of sensor nodes.As low priority sensors can have a higher traffic load and they have greater backoff, they will not be able to send most of the data and drop them, which can cause a major problem in medical treatments.

Network Model and Assumption
In the proposed PLA-MAC protocol, we assume that several biomedical sensor devices are attached to a human body; they all collect data and transmit the data to a central coordinator node using a star topology.The coordinator node can be a Smartphone, a Smart watch, or PDA, which will transmit the data to the external network.The sensor nodes are assumed to have limited energy supply and limited processing power.The coordinator is significantly more powerful than the sensor nodes.Therefore, it is desirable to push as much computation and communication overhead to the coordinator as possible.
In addition, considering the normal application scenario of a BSN such as a data collection system where data are sent from the sensor nodes to coordinator, the down link traffic like notification or beacon from the coordinator is not considered significant.
We assume that every data packet has a lifetime  life , specified by an application, which indicates the time limit within which the packet should be delivered to the coordinator; otherwise, the information in the packet is useless, and it should be dropped.
In the proposed PLA-MAC protocol, the superframe structure is a modified version of the superframe of the IEEE 802.15.4 protocol.
A proper description of the superframe structure used in PLA-MAC can be found in Section 4.3.Here, we have assumed the superframe to have a dynamic structure; the length of the active part of the superframe changes based on the traffic load in the network.The superframe is assumed to contain a fixed CAP of 20 slots, and the length of the superframe is 128 slots.The number of CFP slots is not fixed.So, when there is minimal traffic, the length of the active part of the superframe can be just a little more than 20, and when there is a huge traffic load, the length of the active part of the superframe can be near 128.The rest of the superframe will inactive, which is specified by IP (inactive period).

Proposed MAC Protocol
4.1.Overview.In this paper, we propose a priority-based MAC protocol for body sensor networks that modifies the superframe structure of IEEE 802.15.4.It has a dynamic superframe structure depending on the variation of traffic loads.Based on the delay and reliability constraints of data packets, we primarily perform a traffic classification.Using this classification and data generation rates from sensor nodes, we calculate the different priority and backoff values.The priority class is used by the coordinator while allocating slots for data packets.The backoff values are used by the sensor nodes to perform prioritized random backoff before transmitting the data packets.

Traffic Classification.
In this protocol, the generated data packets are divided into four types: ordinary data packets (OPs), delay-driven data packets (DPs), reliability-driven data packets (RPs), and critical data packets (CPs) [17] (Table 1).The OP corresponds to a data packet that contains regular physiological measurements like body temperature, which does not have any strict reliability or delay constraints.The DP corresponds with packets that have to be delivered timely but do not have much reliability constraint, for example, video streaming.The RP packets must be delivered with high reliability that is without any loss of data, but do not have any delay deadline, for example, respiration monitoring and PH monitoring.The CP packets have high reliability and delay constraints; they have to be delivered with higher reliability and lower end-to-end delay, for example, ECG data packets.Note also that the CP packets have the highest data generation rate and packet size compared to other classes; OP packets have lowest data generation rate and packet size compared to other classes of packets.
Here, the data packets are assigned a data type number   .The critical data packets are assigned the lowest and ordinary packets are assigned the highest data type number.Based on this data type number, the corresponding backoff and priority values will be calculated.
In Figure 3, we can see that every superframe starts with a beacon period.The beacon informs all member nodes about the basic information about the coordinator, other nodes, and about the start of the superframe.In the CAP period, the allocation requests for the CP, RP, and OP classes of data packets for the CFP slots, and data packets of the DP classes are received by the coordinator from sensor nodes.Whether a node will transmit a DP packet or a DP request in CAP period is totally implementation dependent.After CAP, the coordinator allocates DTS slots to the packets, and the allocation status is announced through a notification to all the sensor nodes.The coordinator node allocates DTS slots to the packets based on their priority values.Higher priority packets are allocated first.Then, there is a CFP period, during which the allocated packets are transmitted.Here, we have a dynamic size of CFP; so, the CFP can be very small when there is very low traffic load or it can occupy the rest of the superframe when there is a high traffic load.If the CFP does not occupy the entire superframe, then rest of the period is inactive period.This inactive period can be optionally used as low power listening (LPL).
In the CFP, a number of ETS slots are kept for transmitting emergency packets that are generated after the CAP period.Nodes having emergency packets perform clear channel assessment (CCA) to occupy an ETS slot.
If a sensor node cannot send slot allocation request to the coordinator successfully during the CAP period, the transmission of packets from those nodes will be handled as follows.
(i) As described earlier, the emergency packets will be sent in the ETS time slots, after doing a CCA.
(ii) For RP and OP packet types, they will be stored in the buffer of the corresponding node, waiting for slot allocation in the next superframe.Such packets may be dropped if the node buffer overflows or packet lifetime ( life ) exceeds.

Backoff Calculation.
Prioritized random backoff is performed in CAP.A node, which sends either a data packet or a request packet, performs a random backoff.The backoff value is chosen from the range [0, 2   +2 − 1], where   is the traffic class number.So, the probability of a critical data packet to enjoy less delay is higher than other data packets.
As the backoff value is calculated based on the traffic class value, data packet that has lower traffic class value will get small backoff value and have to wait small period of time before sending a data packet or request.And data packets with higher traffic class value will get larger backoff value.For example, assume that we have a critical data packet and an ordinary data packet to send.As traffic class value for CP is 1, it will get a random backoff value between the range of [0, 7].The traffic class value for OP is 4; so, its backoff will be in the range of [0, 63].As in most cases, OP will have higher backoff value than CP; so, request of CP will be sent before OP.

Priority Calculation.
The sensor nodes calculate the priority of each packet using the following equation: where   = priority,   = traffic class value,   = data generation rate, and   = size in bytes.
We can see that the priority value of a packet depends on its traffic class value and the data generation rate of the node.Based on the priority calculated earlier, the packets will be categorized to be in one of the four following classes: (i) emergency; (ii) high; (iii) average and; (iv) low.
The packets with the lowest traffic class value (critical packets) and highest data generation rate will have the lowest score and highest priority, and they will be defined to be in emergency class.The significance of doing this is that the packets with low traffic class value contains, the most important data which must be delivered timely and with reliability, and packets that are from a node with high data generation rate also must be delivered quickly as the buffer of the sensor node will overflow otherwise and data packets will be lost.Similarly, the packets with the highest traffic class value and lowest data generation rate will have the highest score and lowest priority, and they will be defined to be in low class.The data packets with priority values in between these two classes will be defined to be in high and average classes depending on their values.The range of the priority classes is application dependent.
The coordinator node will allocate slots in the CFP period for the sensor nodes based on aforementioned priority, classes.Emergency packets are given the highest priority and they are allocated slots before any other packets.When slot allocation for emergency packets is finished, then slots for high priority packets are allocated.Average priority packets are allocated next and followed by low priority packets.The rest of the superframe structure is considered as inactive period.

Protocol Operation.
As sensor nodes have low battery life, computational load should be kept as small as possible.Also, each sensor node has a small buffer.If it has a data packet to send, the sensor stores it in the buffer and waits in low power listening mode for next beacon signal from coordinator.Each data packet has a maximum lifetime  life within which it has to reach the coordinator; otherwise, the sensor node drops the packet.
The BSN superframe structure has been designed to be flexible depending on the traffic need.Every superframe starts with a beacon signal.After the beacon signal, the contention access period (CAP) starts, in which the nodes having CP, RP, and OP type data packets make requests for DTS slots.CP and RP data packets are sent using reserved time slots since they are loss-sensitive ones.On the other hand, the loss-insensitive DP type data packets content with each other to be transmitted in the CAP slot.In CAP, the receiver node sends back an acknowledgement (ACK) message after a packet is successfully received.This strategy is much helpful for DP packets to reach the coordinator node within their lifetime.
The sensor nodes may also request DTS slots for sending DP during the contention free period (CFP), depending on the applications need.The requests for DTS slots, which have been received in CAP, are first sorted by the coordinator node based on their priority values and then allocated accordingly.The coordinator node sends this allocation information to all nodes in the notification period, and thus the sensors get to know whether their requests have been granted or not; it also informs the slot number if a request is granted.Therefore, there no need for sending ACK for every request; the notification does that part.A sensor node can sleep in the CAP period if it has nothing to send.The other nodes, after sending data or request packet, will go to LPL and wait for receiving any ACK (if data packet is sent) or notification (if request for DTS is sent).These sleep and LPL periods save the energy of sensor nodes.
The coordinator node allocates the DTS slots based on the priority of the requests.After completion of the transmissions in DTS slots during the contention free period (CFP), the BSN superframe proceeds with inactive period (IP) or LPL period.In IP, the coordinator node goes to sleep mode, and the sensor nodes turn off their transceiver circuitries, saving energy.In LPL, the sensor nodes might transmit emergency data packets only, depending on the implementation.Whether the IP or LPL will be activated can be determined dynamically by the coordinator node based on the traffic load of the network.Also, the IP may not be present in the superframe structure at very high traffic load conditions.
We also keep provisions of transferring emergency packets during contention free period by allocating few emergency time slots (ETSs).More specifically, the ETSs are for transmitting emergency data packets that are generated after the CAP period.Here, the number of ETSs can be calculated using exponential weighted moving average in the following way: Here, the value of NumETS is a weighted combination of the previous value of NumETS and the last value of NumEMR, which is the number of emergency data packets received in the last superframe.In this way, the number of ETSs will be dynamically adjusted during each superframe according to the number of emergency data packets received in the most recent superframe.So, the number of ETSs will increase when a large number of emergency data packets are generated and decrease when the number of emergency data packets goes down.

Performance Evaluation
In this section, we compare the performance of the proposed priority aware and traffic load adaptive MAC protocol with PNP-MAC [15] and IEEE 802.15.4 [10].Here, we have conducted simulation using a simulator which we have been implemented using object-oriented programming language C++.To analyze the performance of the studied protocols, we have compared them in the fields of average packet delay, throughput, and energy consumption.

Simulation Model.
For the simulation of the aforementioned MAC protocols, we consider a body area sensor network consisting of a single coordinator and a number of sensor devices.The sensor devices collect data and transmit them to the coordinator using a single-hop star topology.The superframe parameters used in this simulation are BO = 6, slot size = 7.68 ms, number of slots = 128, and the CAP size of proposed MAC protocol = 20.We consider the CFP size of the PNP-MAC [15] protocol as 40 slots in the simulation as there was no specific size mentioned in the paper.For the proposed MAC protocol, we consider the number of DP packets to be 20% to 30% of the total data packets and the CP, RP, and OP packets to be the other 70% to 80%.The network parameters used here are summarized in Table 2.The parameters used for evaluating power consumption are given in Table 3.

Performance Metrics.
The following four metrics have been considered for the performance evaluation of our proposed PLA-MAC.(i) Average Packet Delivery Delay.In our network, there are several sensor nodes and a coordinator.Each of the nodes transmits packets, which are received by the coordinator.Packet delivery delay here is the time between generation of a packet at a sensor node and its reception at the coordinator node in specific slot of the corresponding superframe.
(ii) Average Delivery Delay for Delay Driven Packets.Delay-driven packets correspond to packets that have to be delivered timely.If they are not delivered in time, they are useless.In our protocol, we have given special treatment to the delay-driven packets; the delaydriven packets are transferred in the CAP period; so, they do not have to make request and then transmit in CFP slots.
(iii) Throughput.In communication networks, throughput or network throughput is the average rate of successful packet delivery over a communication channel.This data may be delivered over a physical or logical link or pass through a certain network node.The throughput is usually measured in bits per second (bps) and sometimes in data packets per second or data packets per time slot.In our evaluation, we have used kbps (kilobits per second); we have calculated the amount of payload bits carried in the total number of data packets received at the coordinator node.
(iv) Coordinator Power Consumption.Coordinator power consumption is the amount of power consumed at its different states, like transmit, receive, sleep, and low power listening states.As the architecture and orientation of the superframe in PLA-MAC is different than IEEE 802.15.4 and PNP-MAC, there is a significant difference in amount of power consumption as well.

Simulation Results.
In our simulation performance evaluation, we study the impacts of the number of end devices and the amount of traffic loads from different devices.

Impacts of the Number of End Devices.
Here, we vary the number of end devices from 1 to 10.Each node generates data at the rate of 5 Pkts/s.First, we measure the average packet delay, the time needed to transmit a data packet to the coordinator shown in Figure 4. We can see that the average delay increases with the increase in the number of nodes; the reason behind that is the increased traffic and collision.In IEEE 802.15.4,as the GTS allocation information for the requests received in the  current superframe is broadcasted in the beacon of the next superframe, the sensor has to wait for the next superframe to transmit data.So, the delay for IEEE 802.15.4 protocol is quite long.In the PNP-MAC protocol, the sensor nodes can transmit data in the same superframe in which they make request for slots; so, the delay is much less than the IEEE 802.15.4.But as PNP-MAC contains a fixed number of GTS slots, the delay increases when the number of data packet exceeds the number of GTS slots.However, in PLA-MAC, the CFP duration is not fixed and depends on the traffic load, and also the DP packets are transmitted in the CAP period; thus, the waiting time of a packet is reduced, and the average packet delivery delay is minimized even when there is a large amount of data traffic in the network.
In Figure 5, we plot the average delay for the delay-driven packets.These packets have delay constraints, and they need to be delivered to the coordinator node within their lifetime.The IEEE 802.15.4 does not contain any special mechanism for handling delay-driven packets; so, they are transmitted in the same way the other packets do.The PNP-MAC protocol has a priority classification, and the packets are transmitted based on their priority values; still the sensor nodes have to send requests first and then the packets are transmitted in the allocated GTS slots.Furthermore, in case an allocation fails, the packet has to wait for the next superframe, and thus the delay increases a lot.However, in PLA-MAC, sensor nodes do not have to send requests and wait for slot allocation for the DP packets; rather they can send the DP packets in the CAP period, minimizing the delay considerably.
Next, we evaluate the throughput of the studied protocols in Figure 6.Throughput is the amount of data packets received by the coordinator in a specific time unit.Here, the throughput of all protocols increases with the increase in number of nodes.We can see that, as the IEEE 802.15.4 has only 7 GTS slots, the throughput becomes constant when the limit of 7 slots is reached.PNP-MAC also has a fixed CFP period; so, the throughput of PNP-MAC also becomes constant after the traffic load exceeds the number of CFP slots.As the proposed protocol contains a dynamic CFP period and also some packets are passed through the CAP period, the throughput of the proposed protocol continues to grow.
In Figure 7, we evaluate the power consumption of the compared protocols.Here, the IEEE 802.15.4 protocol shows a low consumption due to the long inactive period.The IEEE 802.15.4 contains a fixed CAP and a fixed CFP of 7 slots; so,   the power consumption is also fixed, regardless of the traffic load.The PNP-MAC protocol also has a fixed number of CFP periods, which is 40 in this simulation; so, the power consumption here is fixed as well.But the proposed protocol consists of a dynamic superframe structure that varies depending on the traffic load.So, the power consumption of the proposed protocol is low when the traffic is low, and it increases linearly with the traffic load.

Impacts of Traffic
Load.Now, we measure the performance of PLA-MAC with respect to various traffic load.For this, we having are a fixed number of nodes which is seven, and the traffic load will vary from 1 Pkts/s to 7 Pkts/s.In Figure 8, we perform the evaluation of average packet delivery delay with respect to diverse traffic load.We can see that PLA-MAC shows a good result compared to the other protocols specially in the higher traffic load section.The IEEE 802.15.4 experiences a large amount of delay, and the delay increases with the increasing traffic loads.The PNP-MAC protocol shows lower delay than the IEEE 802.15.4,but this delay is increased when traffic load is larger than the fixed number of GTS slots of PNP-MAC.The PLA-MAC is capable to achieve consistent low packet delivery delay with the increasing traffic loads.This nice result is the artifact of traffic load adaptive dynamic superframe structure and special treatment of DP packets defined in our proposed PLA-MAC.
In Figure 9, we can see the average delivery delay for the delay-driven packets.Here, PLA-MAC shows an overall low delay, but the PNP-MAC fails to do so.The PNP-MAC is a priority-based protocol, but it does not have any special scheme for the delay-driven packets; they are transmitted in the same way the other packet follows in the CFP periods.But in PLA-MAC, delay-driven packets enjoy a special service so that they can be delivered within their time constraint.In PLA-MAC, the delay-driven packets can be transmitted directly in the CAP period.So, the delay is low even in diverse traffic loads.
Next, we evaluate the throughput of the compared protocols in Figure 10.We can see that PLA-MAC achieves the maximum throughput of 16.3 kbps in the compared protocols.Here, as the IEEE 802.15.4 has only 7 GTS slots, so the throughput never increases from the first transmission.The growth of PNP-MAC also stops after the traffic load exceeds the fixed number of CFP slots.But because of the adaptive CFP period in PLA-MAC, the throughput of the proposed protocol continues to grow gradually.
In Figure 11, we evaluate the power consumption of the coordinator of the studied protocols.It presents similar results with that in Figure 7. Here, the IEEE 802.15.4 and the PNP-MAC protocol show a fixed power consumption, the reason being the fixed number of CFP slots in both protocols.But the PLA-MAC protocol shows a varying power consumption depending on the amount of traffic load, as it contains a dynamic superframe structure with adaptive CFP period.
In Figures 7 and 11, we observe that PLA-MAC consumes more power than IEEE 802.15.4 and PNP-MAC protocols when the number of source nodes is more than 8. Actually, there is a tradeoff here between the network throughput and energy consumption of nodes.In Figures 6 and 10, we see that the achieved throughput of our proposed PLA-MAC protocol is better than the other two state-of-the-art protocols.Also, the average packet delay is much lower than the other two (Figures 4, 5, 8, and 9).However, the energy consumption of the PLA-MAC is little higher than the other two when the number of end devices is more than 8.This is happening due to carrying additional data packets compared to others.For example, our PLA-MAC consumes 10% additional energy compared to PNP-MAC when the number of end devices is 10 however, it achieves 22% better throughput performance.

Conclusion
In this paper, we have proposed an MAC protocol that provisions QoS to the packets according to their importance.The packets with higher priority get better service than the packets with lower priorities, which is very significant in medical applications of body area sensor network, as the higher priority packets may contain emergency data.The delay-driven packets are transmitted in the CAP period; so, they encounter minimum delay.The critical and reliability packets are transmitted in CFP period; so, reliability is also ensured.The superframe structure adapts its active section length according to the traffic load and the calculations for priority classification at the sensor nodes are kept to a minimum level; so, efficiency in power consumption is also maintained.Based on the simulation results, we can state that our PLA-MAC significantly improves the QoS performances due to its judicious transmission scheduling according to traffic prioritization and load adaptiveness.
Average packet delivery delay (ms) IEEE 802.15.4

Figure 4 :Figure 5 :
Figure 4: Average packet delivery delay versus number of end devices.

Figure 6 :
Figure 6: Throughput versus number of end devices.

Figure 7 :
Figure 7: Coordinator power consumption versus number of end devices.

Figure 9 :Figure 10 :
Figure 9: Average delay for delay-driven packet versus traffic load.

Figure 11 :
Figure 11: Coordinator power consumption versus traffic load.