1 Introduction

Recently, Body Sensor Network (BSN) has drawn huge research interest for its promising applications in medical monitoring systems and multimedia communications. [2, 4, 8–10, 13, 14]. The wearable and implantable sensors have become cheaper and this sophisticated BSN is more relevant now. The BSN gives us two major advantages in the context of health monitoring system: it allows mobility, so the patient is not bound to stay at the hospital for regular monitoring [3] and it facilitates the management of emergency situations in a faster and more efficient way. The transfer of multimedia packets can also be done efficiently in BSNs. A typical BSN consists of some low power implantable or wearable sensor devices in a single body [10, 17] and a PDA or a Smartphone working as the coordinator of the network.

In a health monitoring environment, there exists different types of data packets having different delay and reliability constraints in an application specific context [5]. For example, electrocardiogram (ECG) data requires high reliability and minimum delay, whereas body temperature measurements has neither delay nor reliability constraints. Furthermore, multimedia data packets should be treated differently than crucial physiological data packets. The most challenging job is to develop a protocol that takes the various QoS requirements in consideration and applies data delivery protocol actions accordingly. Medium Access Control (MAC) protocol can play a vital role in data packet transport performance and energy consumption pattern [21]. However, still there is scope to enhance the performance of QoS aware MAC protocol for BSN.

A number of existing works focus on the various QoS requirements [1, 12] and have tried to improve the energy efficiency. The IEEE 802.15.4 [23, 24] gives a basic idea by defining a superframe structure to meet the various QoS requirements. But, the superframe is not elastic, allowing only upto seven Guaranteed Time Slots (GTS) and the protocol does not take priority of the data packets into account. BodyQoS [28] solves the limited GTS problem by separating QoS scheduler from the underlying MAC protocol. However, it does not support preemption. Therefore, higher priority data packets are deprived of transmission slots due to high presence of lower priority packets. PNP-MAC [25] introduces the concept of preemption and ensures that higher priority data packets will always be transmitted before lower priority ones. But this can cause starvation for the lower priority data packets. Priority and traffic load aware MAC protocol (PLA-MAC) [6] introduces a new traffic class, thus differentiating among the QoS constraints for diverse traffic. It has optimized the number of Emergency Time Slots (ETS) by taking the traffic load in consideration. However, allocating pre-assigned ETS for emergency traffic which may or may not occur, is a wastage of resources. Instantaneous delivery of emergency data packets is not possible in PLA-MAC since it does not allow preemption of already allocated slots. An enhanced structure for the superframe is defined in McMAC [16]. It allows preemption of already allocated slots on arrival of urgent data packets. This preemptive data transfer is implemented using a polling based scheme that requires control information exchanges in each slot, incurring a huge communication overhead as well as wastage of bandwidth resources.

In this paper, we propose a low overhead multi constrained QoS aware MAC protocol for BSN, eMC-MAC, that can handle diverse traffic classes and multimedia data packets more efficiently. The sensed data traffic has been classified into five different categories having individual priority levels. The superframe structure is defined in a way that only reliability constrained data packets are transmitted during the Contention Free Period (CFP). Since delay constrained packets can be loss tolerant to some extent they don’t require GTSs. An algorithm is introduced for an optimized GTS allocation. eMC-MAC does not use pre-assigned ETSs and allows the delivery of urgent data packets at any time during the superframe. Instead of sending poll packets in each slot which is a huge waste of resources, eMC-MAC sends poll packets after a certain interval during the CFP for sending urgent data packets. The eMC-MAC protocol also includes an efficient algorithm for preempting already allocated GTS slots on the arrival of urgent data packets.

The contributions of this work is summarized as follows. We have designed an energy-efficient multiconstrained MAC protocol, eMC-MAC, that reduces data delivery delay for the delay constrained packets and maximizes reliability for the reliability constrained packets. We have also introduced mini slots during CFP period for allowing urgent data packets to transmit instantaneously, which is the foremost prerequisite for health monitoring applications. Our preemption algorithm gives higher priority to urgent packets and resolves the starvation problem, which is a major drawback in the existing works. Our performance evaluation shows that the proposed eMC-MAC outperforms a number of state-of-the-art protocols in terms of data delivery delay, reliability and energy consumption.

The rest of the paper is organized as follows. In Section 2, some state-of-the art works and their limitations are discussed. Then, the network model and our assumptions are discussed in Section 3. In Section 4, we present the details operation of our eMC-MAC protocol. The performance evaluation and results are presented in the Section 5 and we conclude the paper in Section 6.

2 Related works

The IEEE 802.15.4 [23, 24] refers to a medium access control sub-layer specification that focuses on low-data-rate wireless connectivity as well as lower energy consumption. This specification proposed a superframe structure which has been considered by many earlier works of this literature. The Guaranteed Time Slots (GTS) provide bounded delay guarantee by controlling the slot allocation in Contention Free Period (CFP) to receive data from neighboring nodes. BSN coordinator allocates GTS slots according to the requests sent by the nodes during Contention Access Period (CAP). This protocol has some limitations that might hamper some features of BSN. Firstly, IEEE 802.15.4 only allows seven GTSs which are insufficient for BSN applications. Secondly, the latency for a slot allocation is pretty high. To transmit through a GTS, one node needs to wait one beacon interval. This latency might be harmful for time critical urgent data. Thirdly, BSN coordinator allocates GTS in an FCFS manner. No priority consideration of data packets is done in allocating slots.

LDTA-MAC [15] protocol has tried to overcome some of the shortcomings of IEEE 802.15.4. Number of GTSs is not fixed. This protocol allocates slots dynamically based on traffic load. For every successful GTS allocation request, data packets are transmitted in the current superframe. But LTDA-MAC does not consider the priority of the data packets or back-off value of them.

BodyQoS [28] took interference in account in data transmission. This protocol has separated QoS scheduler from the MAC implementation. This protocol overcomes the limitation of GTS number. However, in BodyQoS, lower priority data packets can block higher priority data packets due to non preemptive slot allocation. The polling scheme creates additional overhead, capturing scarce BSN resources.

ATLAS [18] is a traffic load aware MAC protocol defining a superframe structure which varies based on estimated traffic load. This protocol uses a multihop network model to mitigate the energy loss during long range transmission. But it does not consider the priority of different packets and back-off classes. It considers four types of adaptive superframe structure depending on traffic load. This may become a computational load.

PNP-MAC [25] protocol uses the superframe structure of IEEE 802.15.4. But it handles the GTS slot allocation with fast, preemptive slot allocation, non-preemptive transmission for diverse QoS requirements. PNP-MAC classified the traffic into 5 classes that separates the non-medical multimedia data packets from the medical data packets. It introduces non preemptive Emergency Time Slots (ETS) to handle emergency data during CFP. However the CFP is fixed. This causes the loss of time and energy. It can also cause emergency life critical data to wait for next superframe. During the Inactive Period (IP), if any data is generated, it will be lost because there is no idle listening which is not feasible for emergency and reliability constraint data. Another drawback of this protocol is that CAP only receives GTS requests. If any emergency data is generated in this period, it has to wait. PNP-MAC does not manage priority and traffic load effectively and the number of ETS is not defined.

PLA-MAC [6] overcomes the fixed CFP problem. This protocol introduces idle listening during IP. During CAP, PLA-MAC allows emergency data to be transmitted. It has calculated the number of ETSs based on past history and last number of ETSs used. This protocol also considers traffic load and calculates priority by taking the traffic generation rate into account. However preemption is not present. Therefore, emergency packets can’t be delivered instantaneously.

McMAC [16] introduces data types according to delay and reliability constraints. It also reduces the use of BSN resource as it differentiates the transmission of different types. For example, delay constrained packets and ordinary packets (which are neither delay nor reliability constrained) are not sent during the CFP period in superframe. It allows preemption and solves the starvation problem. But BSN coordinator sends polling message to sensors before and after every transmission. This captivates lots of scarce resources of BSN. Another major loophole is that this proposal separated the CAP and CFP in two separate sections for type1 and type2 data packet. But if there is no type1 packets, then type2 packets needs to wait for a pre-defined time periods causing wastage of bandwidth.

Besides the aforementioned works, many works have focused on increasing the energy efficiency of BSNs [11, 26, 27]. Zhang et al. [27] introduced periodic wake-up scheduling for sensor nodes to achieve energy-efficiency. But this mechanism suffers from accuracy needed for critical health monitoring. To solve the problem, the protocol introduced secondary transmission channel for passive receiver. These receivers are proposed to receive energy from radio frequency sent from coordinator, which might be very harmful for human health. Furthermore, this protocol does not discuss about reliability, delay and other critical QoS constrains for data generated from sensor nodes.

Among the existing works, McMAC [16] is the most similar to our approach but it has the following fundamental differences from our proposed eMC-MAC protocol. Firstly, McMAC considers a backlogged network traffic model, which is not practical for health monitoring applications; whereas, our proposed eMC-MAC allows data from one or more traffic classes to be unavailable at any moment. Moreover, unlike McMAC, eMC-MAC uses a concatenated CAP and CFP period that reduces the waiting time for some data packets while other packet types are not available. Secondly, McMAC uses an FCFS manner for allocating the same type of packets that might cause packet drops due to expiration of packet lifetime. On the contrary, eMC-MAC sorts the packets from the same traffic class in an increasing order of remaining packet lifetime. This method allows the most crucial data packets to be transmitted first, reducing the packet drops and thus increasing the reliability. Thirdly, instead of broadcasting poll packets in each slot for handling emergency traffic, eMC-MAC uses minislots at pre-defined interval to collect the urgent packets. Thus, our eMC-MAC reduces the protocol operation overhead while maintaining higher data delivery performance.

3 Network model and assumption

We assume a BSN where several wearable or implantable sensor nodes are attached to different parts of a human body. These sensor devices sense and generate data packets and then transmit them to a coordinator device, arranged in a star topology as shown in Fig. 1. The coordinator node may be a Smartphone or a PDA, which will communicate with external network. This coordinator device has higher calculation and processing power as well as higher energy supply, whereas sensor nodes have limited energy and processing power. So we put more complex computational works to the coordinator. All the nodes of our proposed network are clock synchronized [20]. The coordinator can synchronize its own clock with the server and sync the sensors under it accordingly. We can use an environmental-aware time prediction algorithm [19]. Again, the sensor nodes can be clock synchronized by using the periodic broadcast of regular data messages and exploiting the inter-arrival times to predict future arrivals within tight boundaries. This synchronization method helps to avoid gaining extra overhead on these purposes [7]. Few more efficient synchronization methods are available in the literature. We can adopt the best suited method for ournetwork.

Fig. 1
figure 1

Network topology

Full size image

Considering delay and reliability requirements, we have classify sensed data traffic into five different classes as shown in Table 1. We assign priority according to the traffic class values to satisfy diverse QoS requirements.

  • Urgent Packet (UP): These type of packets possess tight QoS constraints both in delay and reliability. UP is usually event-triggered traffic and is generated whenever a life-threatening situation occurs. For example, when the heartbeat rate of a patient exceeds a certain level, an urgent remedy is needed, which surely requires instantaneous transmission with the highest reliability and bounded delay constraint. In this work, we have designed a novel ata delivery mechanism for UP packets even if they are generated during the CFP period of the Superframe.

  • Critical Packet (CP): Both delay and reliability constrained packets are kept in this type. These data packets have stringent delay and reliability requirements. A number of medical applications, for example, ECG generate real-time medical continuous data that must be transmitted to coordinator with higher reliability within a certain deadline.

  • Reliability constrained Packet (RP): This type of data is reliability-constrained but not delay-constrained. These packets have to meet reliability requirements strictly but are delay sustainable. For example, the transmission of medical images, such as X-ray, dermatology images, etc., along with some vital sign monitoring applications, such as respiration monitoring, pH-level monitoring, etc can be mentioned. The packet losses may cause devastating consequences. So these packets get reliable data transmission but can tolerate delay.

  • Delay constrained Packet (DP): These packets are delay-constrained but not reliability-constrained. This type of data must be delivered within a certain time limit. However some packet loss can be sustainable. Examples of this type include telemedicine video streaming applications and other loss tolerant applications. Although the packet loss in this type of applications can deteriorate the quality to some extent, it is ensured that the data are valid.

  • Normal Packet (NP): These packets do not have to meet either the delay or reliability constraints. Routine checking of physiological condition of a patient such as temperature, blood pressure etc are included to this type. Multimedia services, such as video streaming, audio streaming etc. are also included to this type.

Table 1 Traffic classification
Full size table

Although we define these packet classes, the packets might vary its class according to context. For instance, if NP data as blood pressure goes extremely high beyond a threshold, this data packet will be switched to UP class. So packet classification is context-based. Again, we assume that data generation rate is different for different sensors. So, it is not guaranteed that every sensor will generate and transmit data in a periodic way. That is why, we assume that our network traffic model is not backlogged.

The rationale behind assigning traffic class values to different traffic type is that, an eMCMAC node chooses random back-off time before sending request during CAP and PCAP (a specific period in the superframe, discussed in details in Section 4.2). The sensor nodes having UP data packets also choose random back-off time before sending requests to avoid collision. This random back-off is chosen probabilistically based on the urgency of the data packet. This urgency is denoted by the traffic class values. RP and CP packets are assigned traffic class value 0, as they do not need to choose random back-off to send data during CFP.

4 Proposed eMC-MAC protocol

4.1 Basic idea

Our proposed eMC-MAC protocol designs a new superframe structure based on the diverse QoS requirements of the sensed data packets. A higher priority data packet gets a better chance to request for GTS over a low priority data packet implemented through prioritized random back-off. Nodes generating CP and RP, are allocated GTSs during the CFP for achieving reliable data transfer to the coordinator. Urgent traffics are given a special treatment, discussed in detail in Section 4.6. For instantaneous delivery of emergency traffic GTS preemption algorithm is introduced in Algorithm 2.

4.2 Superframe structure

To allocate the diverse traffic classes the superframe structure needs to have distinct period for each class. We have designed a new superframe structure shown in Fig. 2.

Fig. 2
figure 2

Superframe structure

Full size image

The superframe has a flexible structure depending on the current traffic volume of the network. It starts with an advertisement during which the coordinator synchronizes and broadcasts the network information to the sensor nodes. Unlike McMAC, the CAP is concatenated. During CAP, nodes having CP and RP packets can make requests for GTS slots. Since delay constrained packets are loss-tolerant to some extent, they do not require GTSs. During the beacon period the coordinator broadcasts the allocation status to the sensor nodes. Beacon is followed by CFP during which the allocated nodes send data to the coordinator. CFP is of dynamic length consisting of equally sized variable number of GTS slots.

In the proposed superframe structure, we introduce mini slot, named as Urgent Time Slot (UTS), which is much smaller than the regular GTS slots. These UTSs are placed in between GTSs during the CFP at a pre-determined interval. An UTS is used by nodes having urgent packets generated due to emergency situation and its detail operation is presented in Section 4.6. Then comes the PCAP, which is used by nodes having DP and NP type packets to send data. The superframe ends with an inactive period (IP), wherein, the sensor nodes go to sleep mode for energy conservation. However, an optional strategy is used in the literature to send UP packets during the IP period, if there is any such packet generated at a node.

4.3 Protocol operation

The data transmission from the sensor nodes is controlled by the coordinator. The sensor nodes listen to the advertisement from the coordinator and synchronize themselves. Then, during the CAP period, the nodes having urgent data packets send their data directly to the coordinator. Also, the nodes having CP and RP type packets send requests for GTS slot allocation to the coordinator during the CAP period. The requests are sent using prioritized random back-off (discussed in detail in Section 4.4) and clear channel assessment (CCA) to avoid collision. At the end of CAP period, the coordinator determine the GTS slots to be allocated for each requests following the Algorithm 1. The coordinator allocates slots to the critical packets (CPs) first in an increasing order of remaining packet lifetime. This allocation ensures the older and highly constrained packets to transmit first, reducing the packet delivery delay as well as increasing the ontime packet reachability, i.e., the reliability for packets reaching the coordinator within a predefined delay-deadline.

The coordinator allocates slots to the RP type packets only after all the CPs have been allocated GTSs. The coordinator then broadcasts a beacon message notifying all the sensing nodes the superframe structure and slot allocation information, i.e., the coordinator informs the GTS slot number during which a particular sensor node is allowed to send data. The nodes that have been allocated GTSs then send data packets during the CFP.

Nodes that generate DP and NP type packets wait till the PCAP. Just like in CAP, the nodes perform prioritized random back-off and CCA during PCAP to send data packets to the coordinator. To send DP and NP type packets, requests for slot allocation is not needed since these are not reliability constrained packets and can tolerate some packet losses due to collision. As the data packets compete among themselves using prioritized random back-off, there is a greater probability that DP will be sent before NP. After reception of a packet during PCAP, the coordinator sends an acknowledgement to the sender. In this way, a sensor node will know whether it’s packet has been received or not. If the transmission fails the sender will not get acknowledgement and will send the packet again. Each packet has a lifetime after which the packet is dropped. During IP the coordinator is either in sleep mode or low power listening mode.

The eMC-MAC nodes will employ the following energy saving approaches to increase the network lifetime. A sensor node will wake up only when necessary. The sensor nodes will be in sleep mode when it has no data packets to send. For example, nodes generating DP and NP type of packets will be in sleep mode during CAP as they will not send requests for GTS. They will wake up at the start of PCAP period. Moreover, nodes generating CP and RP type of packets will be in sleep mode during PCAP. Also, nodes generating CP and RP packets will go to sleep mode after sending requests in CAP and wake up to listen to the beacon sent by the coordinator. It will then know the GTS slot where to transmit its data packet and wake up at that allocated time slot only. Therefore, sensor nodes are awake only when necessary. In this way, energy-efficiency is increased.

4.4 Prioritized back-off

The main issue of providing multiconstrained QoS is to differentiate the service needed for different data packets. For that, classification of data packets is a must. The idea of priority is introduced to classify the packets according to their urgency. Furthermore, setting different priorities helped the protocol to take decision itself. During CAP and PCAP data packets and requests for slots will be sent using prioritized random back-off that facilitates nodes having important or urgent data packets to access the media earlier than others. The sensor nodes calculate this back-off period using the following (1),

$$ T_{back-off} = [0, 2^{2 \times T_{class-value}} -1], $$
(1)

where, T b a c k−o f f is the back-off period randomly selected by a sensor node and T c l a s s−v a l u e is the assigned value against each type of traffic class.

The rationale behind this equation is that, a node, having data packet with lower traffic class value, will randomly choose a back-off period smaller than a node having data packets with higher traffic class value. This will probabilistically increase the chance for DP packets to be transferred before NP packets during the PCAP period. Also, in CAP period, requests for GTS slots and data packets need to compete with each other for the transmission. For example, suppose sensor node A has a DP type data packet which has the traffic class value of 2 and sensor node B has an NP type data packet which has the traffic class value of 3. Now, the back-off value for DP will be between 0 to 15 following the (1). Let’s assume that, sensor node A chooses 7. However, sensor node B will choose a back-off value between 0 to 63. Suppose, sensor node B chooses 30. It can be seen that node B has chosen a higher back-off value than node A, which allows sensor node A to transmit data packets before sensor node B. Therefore, prioritized back-off time reduces collision and allows higher class traffic to transmit before lower class ones following CSMA/CA.

4.5 GTS allocation

As stated above, during CAP period, the sensing nodes, having CP and RP type of packets, send requests to the coordinator for GTS in CFP period. The coordinator determines the GTS slots for each received requests based on the packet priorities and then allocates the slots to the corresponding sensor nodes. This selection and allocation is maintained following Algorithm 1.

The basic idea is to allocate GTS slots to the sensor nodes according to their QoS requirements. Here the coordinator takes all the requests and sorts them according to the traffic class values. During the CFP period, the CP packets will be allocated before the RP packets. The rationale behind this choice is that the CP packets are both delay reliability constrained and thus they need to be delivered before the RP packets that are only reliability constrained. Again, if there are multiple requests from same type of packets, the packet that has the lowest remaining lifetime will be allocated first. This strategy helps in reducing the number of packet drops due to expiration of their lifetime and thus increasing the ontime packet reachability of the network traffic. After sorting the requests of CP and RP type of packets into two separate sets according to their remaining lifetime values, the coordinator will merge the sorted lists of requests by placing the elements of CP set in front and then the elements of RP set. It will then start to allocate available slots to the sorted requests. Then, the coordinator broadcasts the slot allocation message to all the sensor nodes during the beacon period of the superframe, as stated in Section 4.2.

4.6 Handling urgent traffic

In this section, we propose a special data delivery mechanism for urgent packets. A packet is said to be urgent when its reliability and delay requirements cross a certain predefined thresholds. As stated in Section 3, a UP can be generated at any moment during the superframe and needs to be delivered instantaneously. In our proposed eMC-MAC, a UP can be sent during CAP and PCAP using prioritized random back-off. Since the UP has the lowest traffic class value, it will choose a smaller random back-off value, following (1). Therefore, the probability is very high that it will be transmitted before any other packets. The UP can also be sent during Inactive Period (IP). Our eMC-MAC proposes a new GTS slot preemption mechanism for sending UP packets during CFP. In between the GTS slots of the CFP, there will be mini-slots, named UTSs, during which the coordinator asks for UP packets from the sensor nodes. The structure of a UTS is shown in Fig. 3.

Fig. 3
figure 3

UTS structure

Full size image
Table 2
Full size table

At the beginning of the UTS, the nodes that have UP, send request during UCAP (Urgent CAP). After receiving the requests the coordinator decides which GTS slot will be preempted to allocate the UP. The coordinator tries to find RP packets first. If no RP packets are found then CP packets are preempted, since CP has higher priority. If there are multiple RP packets, the coordinator must decide which RP will be preempted. We can’t use a mechanism where the first available RP is preempted, because the slots are allocated in an increasing order of remaining packet lifetime. Therefore, the packet with the lowest remaining lifetime will always be preempted first. Thus, it will cause starvation, resulting in packet dropping and decreased reliability of the network. In this case, an efficient algorithm is needed for preemption that reduces starvation.

During the notification period the coordinator will broadcast which slot has been preempted and to which UP the GTS has been allocated. The number of UTSs in next superframe, N u m U T S can be calculated based on the number of UTSs utilized on the current superframe, N u m U T S(c). We use the exponentially weighted moving average (EWMA) formulae to calculate the number of UTSs to be allocated in the next superframe,

$$ NumUTS = (1-\alpha) \times NumUTS + \alpha \times NumUTS(c), $$
(2)

where, α is the smoothing weight factor for the EWMA equation and we set its value α=0.2 during our simulation. As the number of UTSs to be allocated for the next superframe is dynamically determined at the end of each superframe according to the number of UTSs used in the current superframe by the coordinator, the bandwidth wastage can be reduced to a large extent.

4.7 GTS preemption mechanism

In our proposed protocol, we have developed an algorithm for preempting allocated data transmission GTS slots to facilitate urgent packets to transmit earlier with higher priority. We can avoid starvation as well as provide in-time delivery of urgent packets through preempting nodes with less significant packets. The nodes that are preempted in the current superframe are most likely to send data packets without being preempted in the following superframe, because the packet lifetime reduces with time and our mechanism tries to avoid preempting the packets with less remaining packet lifetime.

At first, the coordinator gathers all the requests from nodes having UP during UCAP. The coordinator has the prior knowledge of number of slots ζ and ψ that are allocated to nodes having RP and CP type of packets, respectively. Suppose, η is the number of requests for UP packets that were received during UCAP period. After receiving requests from the current UTS, the coordinator starts allocating slots to the UP packets. The slot to be preempted is chosen by comparing the η with ζ.

If η≤ζ, then the first UP is allocated to the η th slot from the last of the CFP, preempting the existing node with RP packets. Similarly, the second UP is given (η−1)th slot and so on. This scenario is shown in Fig. 4a. If more than ζ number of UP packets are requested to be sent in the current UTS, then all slots with RP are preempted and allocated to nodes requested for UP packets during UTS. η is updated whenever a request is handled, as shown in line numbers 6, 12, and 15 in Algorithm 2. The rests of the UP packets are allocated by preempting slots that are currently reserved by nodes with CP packets. First of the remaining η number of UP packets is allocated at η th slot, calculated backward from the last slot held by any node with CP packet. Similarly, the second UP is allocated at (η−1)th slot and so on. This scenario is shown in Fig. 4b. The detail operation of our proposed GTS slot preemption procedure is presented in Algorithm 2.

Fig. 4
figure 4

GTS Slot preemption mechanism

Full size image
Table 3
Full size table

The basic idea of this algorithm is to determine the most suitable GTS allocation that will be preempted, causing least harm to the lower priority packets. Repeated preemption of the RP or CP type of packets having lowest lifetime might cause starvation problem. In eMC-MAC, we start preemption from the middle, counting backward from the end and thus facilitate UP packets to transmit earlier as well as avoid repetitive preemption of the same CP or RP packets. Thus, the judicious choice of the GTS slot to be preempted in our proposed eMC-MAC has overcome this problem.

A quick look up table for the abbreviations used in this paper is given in Table 2.

Table 2 Look-up table
Full size table

5 Performance evaluation

For performance evaluation, we have done a comparative study among eMC-MAC, PLA-MAC [6] and McMAC [16]. We have chosen these two protocols since they aim at achieving the same objectives as eMC-MAC. We have evaluated the effectiveness of our proposed protocol compared to the others in this section. The simulations were conducted on ns-3 [22], which is a newly developed object-oriented simulation tool, implemented using C++. We have analyzed the results in terms of average delay, reliability, energy consumption and protocol operation overhead.

5.1 Simulation environment

We have considered a BSN consisting of one coordinator node and a number of sensor nodes with diverse traffic generation capability. It is a single hop, star topology network, where the sensor nodes send generated data to the coordinator. The superframe parameters used in this simulation is shown in Table 3, where beacon order, BO =6, slot size = 7.68ms, number of slots = 128 and CAP size = 10 slots. We have considered a certain percentage of packets generated for each type from the sensor nodes: 5 % UP packets, 30% RP and CP packets, and 65 % DP and NP packets, which we believe a reasonable assumption for typical health monitoring applications. The number of sensor nodes varies from 2 to 11 and the network traffic model is not backlogged. We have also assumed that an urgent packet can appear at any time period during the superframe. Synchronization of the network is done using [7]. We have selected these parameters and their values since they are the most reasonable assumption in an environment of BSNs. The parameter selection is mainly based on the IEEE 802.15.4 standard [24]. The simulation is run for 1000 seconds and for each data point in the graphs, we take the average of the results of ten simulation runs with different seed values.

Table 3 Simulation parameters
Full size table

5.2 Performance metrics

In this section, we have used the following performance metrics to evaluate eMC-MAC.

  • Average Packet Delivery Delay: In our simulation environment, the sensor nodes generate data packets and send them to the coordinator. The packet delivery delay of a single packet is the time difference between when the packet is received at the coordinator and its generation at the source node. Delays experienced by individual data packets are averaged over the total number of packets received by the coordinator. Lower value is corresponding to the better performance.

  • On-time Reachability: Ontime reachability is a crucial criteron in medical applications. Therefore, eMC-MAC takes certain measures to ensure it. Ontime reachability is measured as the ratio of the total number of packets received by the coordinator within delay-deadline to the total number of data packets generated by all the sensor nodes during the simulation period. Higher value is corresponding to better transmission efficiency.

  • Energy Consumption: Since the sensor nodes are not rechargeable and have low battery power, energy consumption must be reduced as much as possible. We have measured the total amount of energy consumed by all nodes in the network during the simulation period for comparing energy performance of the studied protocols.

  • Protocol Operation Overhead: Protocol operation overhead is the number of control messages per successful data delivery, i.e., it can be measured as the ratio of the number of control messages transmitted to the number of data packets delivered to the coordinator during the simulation period.

5.3 Simulation results

5.3.1 Impact of number of sensor nodes

At first, we have calculated the average packet delivery delay for varying number of sensor nodes. In Fig. 5a, we have considered all types of traffics including urgent packets. The graphs show that the average packet delivery delay is increased with the number of sensing nodes in all the studied protocols. We observe that our eMC-MAC has the least delay as it ensures instantaneous delivery of urgent packets by preempting the allocated GTSs for RP or CP packets. Since McMAC has an extra overhead for broadcasting polling and ACK message in each GTS slot, it’s delay is a bit higher than our proposed eMC-MAC. Moreover, the CAP and CFP periods are divided into two separate parts in McMAC. Therefore, if there is less number of type 1 traffic packets generated in the network, type 2 packets has to wait unnecessarily which increases the average packet delivery delay. The average delay for PLA-MAC is much higher as DP and NP packets are sent during CAP and nowhere else. If the DP and NP packets are generated after the CAP period, they have to wait until the next superframe to be transmitted. Again, instantaneous delivery of urgent packets is not ensured as the emergency packets are sent in the next ETS slot. This causes more delay than the other two protocols. Figure 5b shows the average packet delivery delay without considering the urgent packets. The average packet delivery delay is increased in all the studied protocols due to the absence of urgent packets. But, still eMC-MAC performs better than PLA-MAC and McMAC because of the reasons stated above.

Fig. 5
figure 5

Average packet delivery delay vs. number of sensing nodes

Full size image

The average delay for the delay constrained packets are measured for increasing number of sensor nodes and plotted in Fig. 6a. In our proposed eMC-MAC, CP and DP type packets are both delay constrained, where, CP is both delay and reliability constrained and DP is only delay constrained. Therefore, CP and DP packets are sent in different time periods, in CFP and PCAP, respectively, during the superframe. Thus, the transmission of DP packets does not compete with the urgent packet or the request packets for CP and RP type of packets, reducing the collision as well as delivery delay to the coordinator. This gives an overall better performance than PLA-MAC, where delay constrained packets are sent only during the CAP period, in which the request packets are also transmitted by other nodes. The packets that could not be sent in the current superframe, had to wait till the next superframe to be transmitted. As stated before, McMAC adds extra control messages in each slot during CFP period, which causes more delay for CP packets.

Fig. 6
figure 6

Delay and energy consumption vs. number of sensing nodes

Full size image

The energy consumption of the network nodes is depicted in Fig. 6b for increasing number of sensor nodes. Each node is assigned an initial energy, which decreases with time as the nodes transmit data packets and listen to the coordinator. The total energy expenditure of the network nodes is calculated at the end of the simulation period. The figure shows that the total amount of energy consumption is increased with the number of sensor nodes. Our proposed eMC-MAC protocol consumes the least energy and is the most energy-efficient as the nodes transmit data packets only on specific time periods with reduced control message overhead as well as the reduced number of packet collisions. Furthermore, an eMC-MAC sensor node wakes up only when it has to listen to the coordinator or it has data packet to send during its allocated slots. On the contrary, the McMAC nodes consume more energy due to polling mechanism since it forces the nodes to stay awake for longer period of time in order listen to the broadcasted poll messages. PLA-MAC has some pre allocated slots which is the cause of more energy consumption.

We have evaluated ontime reachability of the studied protocols for all types of traffics exlcluding the urgent packets, as shown in Fig. 7a. As there are no urgent packets, no packet is lost due to preemtion. The graphs in Fig. 7a shows that the ontime reachability decreases at higher number of sensor nodes in all the studied protocols. However, the rate of decrease in our proposed eMC-MAC protocol is less than those of PLA-MAC and McMAC. Our proposed eMC-MAC protocol takes remaining packet lifetime into consideration and allocates the slots according to the increasing order of packet lifetime. Therefore, most of the reliability constrained packets reach it’s destination. Packets may be dropped in the network nodes only when the packet generation rate and the number of sensing nodes is very high. Since, neither the PLA-MAC nor the McMAC takes remaining packet lifetime into consideration, many packets can get dropped due to lifetime expiration and thereby resulting in a decreased ontime rechability of the network traffic.

Fig. 7
figure 7

Ontime rechability vs. number of sensor nodes

Full size image

The Fig. 7b shows the ontime reachability of the network with respect to varying number of nodes. This time, we include the generation of urgent packets from sensing nodes and we observe that the on-time reachability drastically falls at higher number of sensing nodes in the all the studied protocols. The PLA-MAC does not use preemption of allocated GTS slots by urgent packets, therefore, not all of its urgent packets can get transmitted when the number of generated urgent packets exceeds the pre-assigned number of ETSs. However, the joint effort of GTS preemption mechanism and packet lifetime aware GTS allocation, employed in our proposed eMC-MAC protocol, ensures that all the urgent packets are received by the coordinator in minimum delay and maximum ontime rechability. Furthermore, in eMC-MAC, the nodes can make requests for sending preempted packets to the coordinator in the following superframe, ensuring higher ontime reachability. Again for packets that are transmitted during the CAP or PCAP period, acknowledgement is sent by the coordinator. Thus, the nodes can retransmit the packets that have not been reached at the destination. However, neither the PLA-MAC nor the McMAC has taken remaining packet lifetime in consideration and thus their ontime packet reachability decreases. Moreover, McMAC uses preemption, but it doesn’t take any measures to avoid starvation problem. As a result, the head of the line packet might be preempted many times and its lifetime would be expired and finally it will be dropped from the node, reducing the ontime reachability.

5.3.2 Impact of number of urgent packets

In this section, we have calculated average packet delivery delay for varying number of urgent packets, keeping the number of the number of sensor nodes fixed at 10. Figure 8a shows that the ontime reachability of the packets in our proposed eMC-MAC is higher than that of other studied protocols. This result is achieved since it ensures that most of the urgent packets generated during a superframe reach the destination without experiencing further delay. The McMAC shows lower ontime reachability since it does not take remaining packet lifetime into account while scheduling and preempting the GTS slots. The ontime reachability of the PLA-MAC is poorer than the other protocols since it does not employ any slot preemption mechanism. As a result, most of the urgent packets may be dropped because of insufficient ETS slots.

Fig. 8
figure 8

Impacts of number of urgent packet on ontime reachability and packet delivery delay

Full size image

Figure 8b shows that our proposed eMC-MAC protocol has the least delay, because it provides special treatment for urgent packets. Since McMAC has an extra overhead for each urgent slot in CFP, it’s delay is higher. Moreover, during CFP in worst case scenario, preemption takes place twice. That is why, the average delay increases with the increasing number of urgent packets in McMAC. The average delay for the PLA-MAC is also much higher as there is no preemption. As a result, with the increasing number of urgent packets, loss of packet increases. Again number of ETS slots is fixed according to the historical arrival pattern, there may be a number of unused ETS slots that might increase the delay. Instantaneous delivery of urgent packets is not ensured as the emergency packets are sent in the next ETS slot. This causes more delay than the other two protocols.

In Fig. 9, we have calculated the protocol operation overhead of the studied protocols. Figure 9a shows the protocol operation overhead for varying the number of sensor nodes. The McMAC has the highest overhead since it exchanges huge number of control messages during the simulation runtime. It sends poll packets and acknowledgements in each slot in the CFP period of the superframe, increasing the protocol operation overhead rapidly. The PLA-MAC and eMC-MAC has similar overhead, although when the number of sensor nodes is very high eMC-MAC has less overhead than PLA-MAC. We have calculated the protocol operation overhead per successful data delivery, so in spite of exchanging less number of control messages PLA-MAC has more overhead than eMC-MAC when the number of sensor nodes is high, because eMC-MAC has a much higher successful data delivery rate than PLA-MAC.

Fig. 9
figure 9

Protocol operation overhead

Full size image

Figure 9b depicts the protocol operation overhead with varying number of urgent packets. Because of extra control messages in each slots of CFP, the McMAC shows very high protocol operation overhead than the others. The PLA-MAC has a higher overhead than our proposed eMC-MAC in this case, as the success rate of packets delivered in eMC-MAC for varying number of urgent packets is much higher than PLA-MAC. Besides, in PLA-MAC, nodes having NP send requests for GTSs thereby increasing the number of control messages, whereas eMC-MAC doesn’t use any control messages for nodes having NP packets.

5.4 Discussion

The nice performance of the proposed eMC-MAC protocol does not come out of any additional costs. Our in-depth look into the simulation trace file contents reveals that the protocol operation overhead of our proposed eMC-MAC is similar to the PLA-MAC. But, we have measured this performance metric as the ratio of the amount of control messages exchanged for each successful data delivery. Since our protocol gives better performance in terms of data delivery ratio, it shows better protocol operation overhead compared to others.

The novelty of this work lies in formulating more intelligent data transmission rules and preemption of already allocated slots on the arrival of urgent data packets. Our data traffic prioritization and accordingly the slot allocation methodologies are also new.

6 Conclusion

In this paper, we have presented our proposed MAC protocol for a BSN that handles multiconstrained QoS requirements for heterogeneous traffic and increases energy effiency. It has classified the traffic in such a way that higher priority packets can always get better treatment. We have redefined the suferframe structure by overcoming the limitations of the existing literature. Remaining packet lifetime has been taken into account in GTS scheduling and preemption mechanisms to make sure that packets are not dropped due to expiration of their lifetimes. We have proposed some new urgent data handling techniques using preemtion, that has faciliated our proposed eMC-MAC protcol to acheive minimum delay and maximum reliability in the simulation results. However, to stop a certain node from being preempted multiple times necessary measures were taken in order avoid starvation problem. Our proposed protocol for multimedia health monitoring has decreased the energy consumption of the network nodes as they can sleep more and conserve energy.