Energy Efficient MAC Protocol for Low-Energy Critical Infrastructure Monitoring Networks Using Wakeup Radio

Abstract

Critical infrastructure monitoring applications are rapidly increasing. Application requirements include reliable data transfer, energy efficiency, and long deployment lifetime. These applications must also be able to operate in an extremely low-cost communication environment in order to be attractive to potential users. A low rate wireless personal area network can help control and manage the operations of such applications. In this paper, we present a medium access control (MAC) protocol for low-energy critical infrastructure monitoring (LECIM) applications. The proposed MAC protocol is based on a framed slotted aloha multiple access schemes. For downlink communication, we use a wakeup radio approach to avoid complex bookkeeping associated with the traditional MAC protocols. Analytical expressions for power consumption and delay are derived to analyze and compare the performance of our proposed protocol with the existing well-known T-MAC, B-MAC, X-MAC, ZigBee, and WiseMAC protocols. It is shown that our proposed protocol outperforms all the other protocols in terms of power consumption and delay.

1. Introduction

Critical infrastructure monitoring has become a major research area in recent times. Critical infrastructure is a term used to describe assets that are essential for the functioning of a society and economy. Some of the applications are water leak detection, sewer monitoring, bridge and structural integrity monitoring, streetlight control systems, fault circuit indicators, soil monitoring, oil and gas pipeline monitoring, public transport tracking, cargo container monitoring, railroad condition monitoring, traffic congestion monitoring, gas/hazardous material detection, perimeter security, border surveillance, medical alert for at-risk populations, first responder tracking, and so forth. A summary of critical infrastructure applications is presented in [1] and is shown in Table 1.

Table 1

LECIM Applications.

Periodic Traffic Monitoring	Infrastructure Monitoring	Transportation and Asset tracking	Security and Life Safety
Gas meter	Water leak detection/Sewer monitoring	Cargo container monitoring	First responder monitoring/Personal tracking
Water meter	Oil & gas pipeline monitoring	Railroad condition monitoring	Perimeter security/Border surveillance
Electric meter	Urban WSN/Building monitoring	Traffic congestion monitoring	Medical alert for at-risk populations
Net metering	Streetlight control systems	Public transport tracking	Faulted circuit indicators
Transformer load monitoring	Agriculture/soil monitoring	Bridge/structural integrity monitoring	Gas/hazardous material detection

Addressing these assets and infrastructures is essential for the functioning of a society as well as the economy of a society. Therefore, monitoring of these is of high importance. Monitoring ensures the preventive maintenance, safety, and reliability. It can also significantly reduce the overall cost. It is needed for maintenance to improve operations and efficiency. It increases reliability, reduces outage, and speeds up the restoration service. The monitoring can increase safety through the prevention of catastrophic failures, environmental damage, hazardous leaks, and so forth [2]. The above-mentioned applications require extremely low energy usage to maximize the deployment lifetime. These are categorized as Low-energy critical infrastructure monitoring applications.

The requirements [3] for such a network are energy efficiency, long lifetime, scalability, reliability, availability, robustness, maintainability, and security. Low energy is required as the sensors are normally located where power mains and the network infrastructures are not readily available. These endpoints are highly distributed in challenging environments that include cities, rural areas, forests, mountains, and below-ground monitoring locations. The distance between the coordinator and the endpoints may vary from few meters to few kilometers. They also need to operate for long durations without human interactions.

The above application space is not well served by any existing or planned standard of IEEE. As a result, an IEEE TG4k is formed as an amendment to IEEE 802.15 family to address the LECIM. The intentions are to facilitate low-energy operation for multiyear battery life and establish a simple and low-cost communication environment with reliable data transfer capabilities.

Due to the unique features of LECIM networks, a great deal of research is required for the effective network management and operations. As LECIM network's battery powered endpoints must operate for years, it necessitates the needs for advanced power management of the radio. In this paper, we pursue the idea of using a second, ultra-low-power radio that can be used to trigger a remote interrupt, so that a receiver can shoot up its primary radio to engage in efficient communication with the sender. Wakeup radio is energy efficient though it needs additional hardware. The traditional MAC (medium access control) protocols may fail to achieve optimal power consumption when on demand functionality is needed and the coordinator is supposed to send data at long time intervals and at a random fashion to the endpoints which spend most of the time in off mode. Therefore, we propose a medium access protocol using wakeup radio for LECIM networks. This is the first protocol for LECIM networks using framed slotted aloha to the best of our knowledge.

The rest of the paper is structured as follows. In Section 2, we review related work. In Section 3, we present the overview of the IEEE 802.15.4k task group and the LECIM networks. In Section 4, we discuss our proposed MAC protocol. We describe the downlink communication process in Section 5. The performance of the proposed MAC is analyzed and compared with related protocols in Section 6. Results and discussions are carried out in Section 7. Finally, we conclude and discuss future work in Section 8.

2. Related Work

An ever increasing number of works are dealing with the protection of the sensed data in critical infrastructure monitoring applications; but, accessing the shared medium in such networks has received comparatively little attention. The survey in [4] covers the general ideas about using a WSN to ensure the protection of critical infrastructure. In [5], the authors provide an overview of the main challenges and open research issues on critical information infrastructure security. In [6], the authors identify the precise security requirements for distributing the symmetric keys along the one-dimensional WSN used for monitoring an extended piece of linear infrastructure such as a pipe. This paper also proposes lightweight key distribution schemes which could benefit applications like perimeter surveillance and pipeline monitoring. In [7], the authors make two contributions. First, they propose a model to maximize the amount of monitoring-related data that can survive after a portion of the critical infrastructure suffers a disaster. Second, they address the distribution of sensors in a specific application like oil pipeline so that an optimal placement of sensors could be achieved, while satisfying deployment constraints.

Due to the lack of an appropriate wireless technology which satisfies all the requirements of the LECIM, the IEEE 802.15 working group formed IEEE TG4k to develop a communication standard optimized for low-power devices to serve a variety of applications. Some proposals for LECIM on September 2011 meeting at Japan are discussed below. In [3], a preliminary fragmentation for TG4k to improve apparent reliability of the medium is proposed. It can adapt LECIM PHYs to operate with existing MAC transparently. It leverages the existing IEEE 802.15.4 MAC frame structures and can fit MAC frame structures into smaller chunks. In [8], IEEE 802.15.4e TSCH (time slotted channel hopping) resource management scheme is proposed for LECIM MAC. TSCH allows the endpoints, to hop over the entire channel space in a slotted way thus minimizing the negative effects of multipath fading and interference while avoiding collisions.

In [9], the authors proposed contention free low-energy link access for LECIM by distributing the access load on a slotted link. In fact, it is similar to multiframe order in DSME (distributed synchronous multichannel extension) of TG4e. A flexible MAC proposal for TG4k networks is presented in [10]. A superframe structure is discussed in their proposal. Basically, this is a time slot allocation-based MAC. A batch transmission (BT) MAC-based on IEEE 802.15.4e basic CSL (coordinated sleeping) operation is proposed in [11].

A low-energy MAC proposed in [12] is based on non-beacon mode of IEEE 802.15.4. The authors analyzed the advantages and disadvantages of synchronous and asynchronous networks and the low-energy modes in IEEE 802.15.4e. The main idea is the coordinator keeps listening to the channel and the endpoints keep sleeping. If endpoint has data to transmit, send frame by using CSMA/CA, and waiting for ACK. In the case of receiving no ACK, the endpoints retransmit the frame. If the coordinator wants to send a unicast frame, it waits for the data packet from the desired endpoint and then sends the unicast frame piggybacked with the ACK. In the case of the broadcast or multicast frame, the coordinator sends a sequence of wakeup calls to make an appointment about the desired frame transmission time.

The main problem in many applications of LECIM is that some endpoints may sleep for years, some for months, and some for days. For those endpoints who wake up and communicate very rarely and sleep majority of the time, if coordinator wants to let them to change the data rate, frame format, or any other parameters within certain time limit, then making delay in making the respective changes beyond the desired time threshold would harm the whole system. But how the endpoints will know that coordinator want to send them the data is a challenging job especially in the case of LECIM networks where battery power is needed to work for many years.

Traditional WSN MAC protocols like T-MAC [13], B-MAC [14], X-MAC [15], WiseMAC [16], and Zigbee [17] cannot satisfy all the requirements of LECIM. T-MAC is the improved version of S-MAC. T-MAC does not use fixed active period but having the capability to shorten the active period if the channel is idle for a short time (TA). In the case of data, the node remains active till data reception or until the active period ends. B-MAC utilizes low power listening (LPL) and an extended preamble to achieve low power communication. Nodes wake up and perform channel sensing periodically. The transmitter precedes the data packet with a preamble that is equal to the longest wakeup period of any node. During the listening period if a node detects a preamble it remains active to receive the data. The lengthy preamble assures the sender that at some point the receiver will detect the preamble, and will become ready to receive the data. In the X-MAC, the receiver wakes up periodically to listen for the preamble and the transmitter continuously transmits strobed preambles (sends small bursts then waits for ACK then sends another preamble and so on). The receiver needs to listen to at least two preambles and one ACK before starting the data communication with the transmitter. WiseMAC is based on preamble sampling technique in which endpoints sample the medium with a constant period at regular intervals. In WiseMAC, the access point (AP) first learns the sampling schedule of all the endpoints in the network and then start the transmission at the right moment with a wakeup preamble of minimized duration. The AP regularly updates the sampling schedules of all the endpoints. Initially, the size of the preamble equals the wakeup interval and then it reduces the size of the preamble by knowing the sleep schedules of the neighboring endpoints. The ZigBee builds on IEEE 802.15.4 which provides MAC and PHY provides the network layer and the framework for the application layer. It uses beacon and nonbeacon modes. In beacon mode, the PNC (PAN Coordinator) transmits beacon and then waits for the data from the nodes in CAP period. Data exchanges in CAP are performed using a slotted variation of CSMA. Energy consumption is reduced by using blind backoff. The number of collisions is minimized by performing carrier sensing twice. It also supports a contention-free period (CFP) for time-sensitive data.

Traditional MAC protocols mainly focus on bandwidth utilization and throughput. However, they lack energy conservation mechanisms, which is one of the most important requirements of LECIM. Additionally contention-based protocols use CCA (clear channel assessment) to determine the status of the channel, however, this is not always guaranteed in LECIM due to the long distance among the nodes. Scheduled-based protocols provide good solutions for CCA problems, but these are also not suitable for LECIM due to large number of endpoints and event based traffic.

To solve the above-mentioned problems, we feel for a new MAC for IEEE 802.15.4k. As the downlink data which is rare but plays a very important role for network management, therefore, in this paper, we propose framed slotted aloha-based MAC using wakeup radio which mainly encompasses the downlink data communication in LECIM networks. There are number of approaches for wakeup radios. The most common approach is to use a zero-bias Schottky voltage doublers (voltage multiplier, envelope detector), as exemplified by [18–21]. The concept of wakeup radio approach is not new in WSNs. In [18], the authors used the wakeup radio approach for developing a low-power MAC for WBAN. Ansari et al. [19] presented a simple protocol for wakeup signal transmission and a wakeup receiver with addressing capabilities that include a voltage multiplier and a digital comparator. Durante and Mahlknecht [21] presented a solution with a Schottky voltage doublers followed by a programmable amplifier and integrator. The data rate and sensitivity are high because of the amplification stage, at the expense of power consumption. Malinowski et al. [22], presented a complete micropower sensor node with RF quasi-passive wakeup, using adjustable thresholds that adapt to dynamic environments. Their design consists of an envelope detector and an amplifier. Other solutions, such as Pletcher and Rabaey [23], advocated a design based solely on amplifiers with high sensitivity, at the expense of power consumption. Takiguchi et al. [24] proposed and simulated a solution with a bloom filter. Der Doorn et al. [25] proposed an On-Off Keying (OOK) wakeup radio for sensor networks that shares an antenna with the transceiver. Marinkovic and Popovici [26] developed a nanopower wakeup radio with 470 nW idle listening power.

3. Overview of LECIM Networks

The purpose of TG4k group is to facilitate single point to multi-thousands of points communication for critical infrastructure monitoring. It aims to address the needs of minimal network infrastructure and to collect the scheduled and event data from a large number of nonmain powered endpoints that are widely dispersed or are in challenging propagation environment. It supports low-energy operation which is necessary in order to maintain multiyear battery life. The amendment wishes to minimize the network maintenance traffic and endpoint active durations. The major goal is to support the monitoring of management requirements of critical infrastructure applications to enable preventive maintenance, safety, reliability, and cost reduction through operation efficiency. The call for proposal submission was issued on May 2011 [27].

The LECIM applications are set primarily in an outdoor environment. The major requirements for LECIM networks are that the application data rate can be as high as 40 Kbps, it includes thousands of endpoints per main powered infrastructure, it has an asymmetric application data flow, energy conservation is maintained for endpoints, has reliable operation in dramatically changing environments, it has a large coverage area, it has a long deployment life with minimal human contact, it can cope with small and infrequent messages, it is tolerant to data latency for uplink communication, it can address supporting thousands of connected endpoints, and so forth.

Two kinds of network devices are proposed for LECIM—coordinator (collector) which is typically main powered and endpoints which are battery powered. No mobility is needed for endpoints but limited portability for the coordinator is supported. The network forms a star topology as shown in Figure 1. The endpoints can only communicate with the coordinator.

Figure 1

LECIM network topology.

Like IEEE 802.15.4, we propose three applicable frequency bands, and 27 channels with different bandwidth for LECIM networks [28]. 16 channels are in 2.4 GHz band, 10 channels are in 915 MHz band and 1 channel is in the 868 MHz frequency band for certain applications. The operating frequency bands are shown in Figure 2.

Figure 2

The operating frequency bands.

4. Medium-Access Control Protocol for LECIM

In this section, we discuss our proposed MAC protocol for LECIM networks. The size of the LECIM network is very large and the scalability is one of the important issues. Energy consumption and lifetime are key design requirements. Most of the major existing MACs are unsuitable for LECIM network due to various reasons [2]. IEEE 802.11 networks are optimized for computing applications that require high data rate, high duty cycle, and high performance. The present 802.15.1, Bluetooth has a short range and cannot support thousands of endpoints due to low capacity. The IEEE 802.15.3 also has a short range and aimed high data rate applications. IEEE 802.15.4/4e MACs supports low data rate applications. However, they need modifications to support such a large network with very lossy channel. IEEE 802.15.4e [29] supports mainly TDMA approach which cannot work well for LECIM networks due to large number of endpoints.

Therefore, we realize the need of a new MAC protocol to support LECIM. In this paper, we propose a beacon-enabled framed slotted aloha-based MAC protocol. Our protocol is based on the use of wakeup radio approach. A CSMA/CA that uses a carrier sensing is not feasible due to the wide network range. The authors in [30, 31] have proposed framed aloha for RFID and other applications. Our protocol has less design complexity and can be used efficiently in light network loads at LECIM.

4.1. Superframe Structure and Slot Design

The superframe structure of the proposed MAC is shown in Figure 3. It contains a beacon, Emergency Access Period (EAP), Normal Access Period (NAP), and Guaranteed Access Period (GAP). The number of slots can vary as per the application need. We propose to use 128 ms, 256 ms, 512 ms, or 1024 ms duration for a superframe as per requirements.

Figure 3

Superframe structure.

The beacon is transmitted in the first slot of the superframe and is used to synchronize the endpoints and to transmit superframe information. EAP is further divided into emergency time slots (ETS) and management time slots (MTS). ETS are used for sending emergency commands to the coordinator describing the type of emergency happened to the endpoint. Emergency can be the problem happening to the endpoint itself like malfunctioning hardware or software and critical battery life situation. The coordinator treats it with high priority. The management time slots are used for sending downlink data to the endpoints. NAP is used for normal communication in the network. The number of slots in NAP can be optimized as per the network size.

The length of EAP is configurable (first 2, 4, or 8 slots) and 50% of them will be used for ETS and MTS, respectively. The length of NAP as well as GAP is also configurable and depends upon the applications and number of endpoints. Figure 3 also describes the slot design. All slots are of equal lengths. The slot length considers propagation delay (Tp), actual packet length, and nominal guard timings (GTn). The Tp is added to negate the delay occurred due to long distances. The different values of Tp can be found from Table 2. Nominal Guard time (GTn) is a time interval left vacant (i.e., during which no data is sent) on a transmission channel at the end of every slot for synchronization and to differentiate between slot boundaries.

Table 2

Propagation delay versus distance.

Distance (Km)	Propagation Delay (μs)
10	33.36
5	16.68
2	6.67
1	3.34
0.5	1.67

For our protocol, superframe duration, total number of slots in a superframe and slot length is important design parameters. In Table 3, we show the parameters for different superframe sizes in detail. The bold numbers show that data packet smaller than 20 bytes are not useable because if we use a packet of size less than 20 bytes then the payload will become very small (since the MAC overhead that is, the MAC header and CRC field are 13 Bytes long) and the information reached to the coordinator would not be meaningful.

Table 3

Superframe sizes with probable slot number and packet lengths.

			Superframe size (SF size)
	In milliseconds
In slots	1024 ms		512 ms		256 ms		128 ms
	Slot time (ms)	Packet size (Bytes)	Slot time (ms)	Packet size (Bytes)	Slot time (ms)	Packet size (Bytes)	Slot time (ms)	Packet size (Bytes)
16	64	320	32	160	16	80	8	40
32	32	160	16	80	8	40	4	20
64	16	80	8	40	4	20	2	10
128	8	40	4	20	2	10	1	5
256	4	20	2	10	1	5	0.5	2.5

For applications like meter reading (Gas, Water, Electric), where packet arrival is frequent, periodic and non-delay sensitive, a long superframe duration (i.e., SF Size = 1024 ms or SF Size = 512 ms) is useful. This long superframe duration will result in smaller number of collisions with the expense of some delay. But as stated earlier that delay is not a problem in those applications, so the use of longer superframe size will result in power efficiency and data reliability. In the case of security and life safety applications like medical alerts for at risk populations, bridge integrity monitoring, and so forth where packet arrival is infrequent, nonperiodic but is very much delay sensitive, the use of short superframe durations (i.e., SF Size = 128 ms) is useful. This short superframe duration will enable the endpoints to receive beacons quickly and transmit their data soon. If we use a long superframe duration and the endpoint just miss the beacon, then it will have to wait for the whole superframe to listen for the next beacon which may result in excessive delay. Also the long superframe duration in the case of packet retransmission requires more time. Since the coordinator uses main power, therefore, sending the beacons after a short interval will not affect the lifetime of LECIM network. The applications like agriculture/soil monitoring, railroad condition monitoring, and so forth where data arrival is infrequent and is not delay sensitive an SF size of 256 ms or SF size of 512 would be the better choice to use.

4.2. MAC Frame Structures

Figure 4 describes the MAC frame structures. The general MAC frame consists of the MAC header, payload also called MAC service data unit (MSDU), and MAC footer (CRC). The first field of the MAC header is the 16 bits long frame control field. It specifies how the rest of the frame looks, that is, it indicates the type of MAC frame being transmitted, specifies the format of the address field, and information about acknowledgment. The size of the address field may vary between 0 and 48 bits. For instance, a data frame may contain both source and destination information, while the return acknowledgment frame does not contain any address information at all. On the other hand, a beacon frame may only contain source address information. This flexible structure helps increase the efficiency of the protocol by keeping the packets short. The payload field is variable in length; however, it may not exceed 114 bytes in length. The data contained in the payload is dependent on the frame type. Other fields in a MAC frame are the sequence number and cyclic redundancy check (CRC). The sequence number which is 8 bits long in the MAC header matches the acknowledgment frame with the previous transmission. The transaction is considered successful only when the acknowledgment frame contains the same sequence number as the previously transmitted frame. The CRC helps verify the integrity of the MAC frame. The wakeup packet consists of 4 fields and is 56 bits long. The first field is Sync which consists of 8 bits synchronization sequence, the second field is Receiver ID which is 16 bits long, the next is message field and in the last is 16 bits long CRC field. The address field shares the address space of the main radio. The immediate ACK field is 48 bits long.

Figure 4

MAC frame structures of the proposed protocol.

5. Communication Process

In [32], we presented a framed slotted aloha protocol for LECIM networks. In this section, we discuss the main idea of the uplink communication and complete details of the proposed downlink communication process. For uplink communication, our proposed MAC was appropriate but for downlink (coordinator to endpoints) we found some difficulties. To overcome these, we propose to use wakeup radio approach in this paper. It can be noted that the data transmission from the coordinator to the endpoints is very much needed for network management, for example, to let the endpoints know about the changes in topology, data rates, frame formats, and so forth.

5.1. Uplink Communication

Figure 5 shows the proposed uplink communication process. The uplink is for data transfer from endpoints to the coordinator either in the form of emergency data packets in the first half of EAP period or normal data packets in NAP or GAP periods.

Figure 5

Framed slotted aloha protocol.

In the beacon-enabled mode, coordinator broadcasts beacon packets at regular intervals. The beacon contains synchronization and slots information. The endpoint wakes up on its own schedule (i.e., when an event of interest happens) and listens to the beacon. When it gets the beacon, it synchronizes with the superframe (SF) and transmits the packet according to the following procedure.

After listening to the beacon, the endpoints randomly choose a slot between [LengthofEAP + 1, maxSlotnumber − 1] in the current SF. The maxSlotnumber is the number of total slots in the current SF. After successful transmission, the endpoints go to sleep mode. In the case of collision, it tries again in the next SF by taking a random slot again. Emergency events can happen to an endpoint. The occurrence of those events is extremely low and random. When an emergency event happens to an endpoint, it sends the emergency data packet using framed slotted aloha in the first half of the EAP period. The emergency data packet contains specific event type information, for example, malfunction or fire to an endpoint, critical battery situation, and so forth. An endpoint also sends an emergency command when the remaining battery power reaches 10% of its capacity.

The GAP period in our proposed MAC is optional and can be used for the applications where the traffic is deterministic and the number of endpoints is smaller in number. The main aim of using the GAP period is to provide predictable real-time guarantees for time-critical applications such as industrial applications, where a small delay makes a great difference in the on going process. The GTSs (guaranteed time slots) are assigned to the endpoints on demand bases. The coordinator announces in the beacon about the GTS allocated to the endpoints in the GAP period. The endpoints then transmit their data in the allocated GTS accordingly. We put it optional because in normal LECIM applications its use is very rare.

5.2. Downlink Communication

For downlink communication, our proposed MAC uses a separate and ultra-low-power wakeup radio along with the main radio. The wakeup radio allows the endpoints to go into deep sleep mode until they receive a special wakeup signal, after which the main radio (data channel) is invoked and is used for data transmission. Figure 6 describes downlink communication process. Since the wakeup radio is mainly used for the wakeup purposes, its power consumption requirements are considerably lower than the main radio.

Figure 6

Flowchart describing the downlink MAC process using wakeup radio.

In the case of downlink traffic where the coordinator wants to transmit data to an endpoint or group of endpoints, it is important to let the main radio of the desired endpoints to wakeup from sleep state. For achieving this, coordinator first sends a wakeup packet on the wakeup radio. This wakeup packet is in the form of modulated wakeup signal containing addressing information in order to avoid undesired endpoint wakeups. After receiving the wakeup packet, the wake-up receiver wakes up the microprocessor and the microprocessor then interprets the command and decides about the waking up of the main radio for data communication. Only the main radios of the desired endpoint(s) wakeup and microprocessors of the rest of the endpoints go to sleep mode again. The downlink communication can either be unicast or broadcast. Both of them require exchange of different packets in a specific order. Figure 7 shows the names and sequences of those packets.

Figure 7

Packets exchange for unicast and broadcast communication.

In the case of unicast message, the coordinator sends wakeup packets using wakeup radio continuously to the desired endpoint until ACK is received. After receiving the ACK, the coordinator sends the desired data in the downlink management time slots of the next superframe using the framed slotted aloha approach as discussed above.

In the case of broadcast message, the coordinator sends a wakeup call to wake up all the endpoints from sleep mode by specifying the broadcast address and then sends the desired data in the management time slots of the next superframe. For verification purposes, the coordinator checks the packets received from the endpoints after sending the information regarding those changes. If the coordinator finds that some of the packets are not according to the changed format, it informs those endpoints again about the desired changes in the next superframe using unicast approach as explained earlier.

5.2.1. Need of Wakeup Radio

As in LECIM, the endpoints are deployed in inaccessible regions and the battery replacement is costly and difficult, therefore, energy efficient performance is a central challenge. The major contributor to the energy consumption is the radio transceiver. Several techniques have been proposed in the literature for wireless sensor networks (WSNs) to minimize the energy consumption of the transceiver by reducing the transceiver's duty cycle. But in the case of LECIM where lifetime is required in years and the events of interest happens rarely, turning off the radio transceiver can save energy but it cripples flexibility in terms of downlink traffic. In the case of downlink traffic where the coordinator wants to convey messages like change in data rate, topology or frame formats, the endpoints need to wake up periodically to check activity on channel. One solution is to let the endpoints wake up periodically and check the activity on the channel and if there is something for them then receive it otherwise sleep again. This periodic wake up and sleep results in idle listening. As messages from coordinator to the endpoints are rare and infrequent, therefore, great amount of energy is consumed in idle listening.

In order to reduce the idle listening problem, we need to increase wakeup interval and to decrease the sampling time. Increasing the length of this wakeup interval can save energy but can lead to a huge increase in delay which in certain circumstances is unaffordable. To avoid wasting energy and reduce the delay, we propose for LECIM that each endpoint is equipped with a low power wakeup radio which monitors the communication channel continuously, while keeping the other components in deep-sleep mode. When the coordinator wants to communicate with the desired endpoint, it sends a wakeup packet containing its address. All the endpoints receive the wakeup call but only the microcontroller (MCU) of the designated endpoint triggers its main radio. The main radios of all other endpoints remain in low power mode. Thus, in this way we can meet the energy requirements of LECIM applications.

5.2.2. Structure of Wakeup Radio Transmitter and Receiver

We consider the LECIM as a one-hop star topology built around a coordinator. The coordinator is typically mains powered and endpoints are power-constrained equipped with small batteries. The block diagram of the coordinator and an endpoint is shown in Figure 8. We propose for the coordinator to be equipped with the wakeup signal transmitter used in [26] which consists of ADF7020 RF transceiver and MSP430 microprocessor. The transceiver uses frequency shift keying (FSK) mode for actual data transfer and On Off Keying mode for sending wakeup packets. The transmitter can use any carrier frequency because there is no input filter at the wakeup receiver. The wakeup packet should be sent with lower data rate (5–10 Kbps) than the data rate of the regular transceiver (200 Kbps) [26].

Figure 8

Block diagram of the coordinator and an endpoint.

5.2.3. Wakeup Signal Receiver

Our MAC protocol is based on the wakeup receiver developed in [26]. Wakeup receiver allows an endpoint's main radio along with other components to sleep and to be awakened later. Figure 9 shows the block diagram of the wakeup receiver. The main building blocks include a charge pump, low-cut filter, and preamble detector and comparators. The charge pump is used to detect the received OOK signals envelop. The first comparator is used to form the correct bit sequence of a received packet. The preamble detector is used to exclude unnecessary wakeups from common interference sources by examining whether the wakeup preamble is generated in the expected data range or not. This filter needs to be passive for achieving low energy consumption. The optionally used second comparator checks the correctness of the preamble sequence and then generates the wakeup signal. For conserving energy instead of the second comparator, microcontroller generates an interrupt.

Figure 9

Block diagram of wake-up receiver.

6. Performance Analysis

In this section, we present analytical expressions for our main performance metrics of interest for downlink traffic that is, power consumption and delay. Delay in general is not a problem in LECIM, but in the case of downlink traffic it becomes one of the major focuses of interest. Wake up radio approach is the best approach for achieving low latency in low data rate applications at the rate of less energy consumption.

We derive power consumption and latency models for our proposed MAC and compare it with the existing MAC protocols like B-MAC, X-MAC, WiseMAC, T-MAC, and Zigbee. We use the parameters of the low power radio transceiver developed at CSEM (Swiss Center for Electronics and Micro technology) within the WiseNET project [33]. Table 4 defines the relevant parameters used in this modeling. Like other asymmetric systems, in LECIM, the coordinator works as a master node connected with the main supply and all other endpoints are slaves with small batteries. Therefore, the power consumption of the coordinator is less important and our focus is mainly on the endpoints.

Table 4

Parameters for modeling power consumption and latency.

Symbol	Description
$P_{\text{tx}}$	Power consumed in transmit mode
$P_{\text{rx}}$	Power consumed in receive mode
$P_{\text{rxwuc}}$	Power consumed in receiving wakeup packet
$L_{\text{wuc}}$	Length of wakeup packet
$R_{\text{wuc}}$	Data rate of the wakeup radio
$T_{\text{cca}}$	The time for clear channel assessment or carrier sensing
$P_{\text{sl}}$	Power consumed in sleep state
$L_{\text{wack}}$	Length of immediate ACK
$L_b$	Length of beacon
$L_{\text{ack}}$	Length of ACK Packet
$L_{\text{data}}$	Length of data packet
$T_{\text{set}}$	Time required to wakeup main transceiver
$P_{\text{set}}$	Power consumed in waking process
$T_{\text{tt}}$	Switching time from Rx to Tx and vice versa
N	Total number of endpoints in the network
$T_b$	The time required for beacon transmission
$P_{\text{tt}}$	Power consumed in switching
Batcap	Battery capacity
$T_{\text{sl}}$	Sleep duration
R	Data rate of main radio
$T_{\text{wuc}}$	Duration of wakeup call
$T_{\text{ack}}$	Time required to transmit ACK packet
$T_{\text{data}}$	Time required to transmit data packet
$T_{\text{hdr}}$	Time needed to transmit a message header
$T_{\text{cts}}$	Clear to send packet duration
$T_{\text{wi}}$	Duration of the wake-up Interval
$\mathrm{\Theta }$	Crystal tolerance of a wakeup timer
$T_p$	Time required to send preamble
$T_{\text{poll}}$	Channel sampling duration
$T_{\text{rts}}$	Ready to send packet duration
$T_{\text{sync}}$	Sync frames interval
T	Interval between two communications
Totenergy	Total energy consumed by the endpoint
$T_{\text{cw}}$	Length of contention window

The latency of each protocol requires three main components. The first component is the time required to receive a wakeup signal (including wakeup call (WUC), beacon, preamble, etc.), the second component is the time required to receive the desired data and sending the ACK, and the third component consists of the additional overheads like sleep time, turnaround time, time required for invoking the main radio, and so forth.

First, we model the power consumption and latency of our proposed MAC. For simplicity, we do not model power consumption due to retransmission and hence ignore transmission errors and collisions. The link is setup in two steps, at the first step the coordinator sends a WUC on the wakeup radio. When the receiver receives the WUC it transmits an ACK packet and wakes up the main radio. The average power consumption ( $P_{\text{avg}}^{\text{Prop}}$ ) of an endpoint for the successful reception of a downlink packet and the relevant latency (Delay_PropkMAC) of our proposed MAC is given by (1) and (2), respectively,

$\begin{array}{cc}\hfill P_{\text{avg}}^{\text{Prop}}& =(P_{\text{rxwuc}}*\frac{L_{\text{wuc}}}{R_{\text{wuc}}}*N+P_{\text{tx}}*\frac{L_{\text{wack}}}{R_{\text{wuc}}}+P_{\text{rx}}\hfill \\ \hfill & \hspace{1em}\hspace{1em}*\left(\frac{L_b+L_{\text{data}}}{R_{}}\right)+P_{\text{tx}}*\frac{L_{\text{ack}}}{R_{}}\hfill \\ \hfill & \hspace{1em}\hspace{1em}+P_{\text{set}}*2T_{\text{set}}+P_{\text{sl}}*T_{\text{sl}}+P_{\text{tt}}*T_{\text{tt}}\phantom{\left(\frac{L_b+L_{\text{data}}}{R_{}}\right)})/T,\hfill \end{array}$

(1)

where $T_{\text{sl}}=T-(T_{\text{wuc}}+T_{\text{wack}}+T_{\text{set}}+T_b+T_{\text{data}}+T_{\text{ack}}+T_{\text{tt}})$ ,

$\begin{array}{cc}\hfill & {\text{Delay}}_{\text{PropkMAC}}\hfill \\ \hfill & \hspace{1em}=\left(T_{\text{wuc}}+T_{\text{wack}}+T_{\text{set}}+T_b+T_{\text{data}}+T_{\text{tt}}+T_{\text{ack}}\right).\hfill \end{array}$

(2)

The first term in (1) defines the power consumption in receiving a wakeup call from the coordinator by all N endpoints and the second term defines the power consumption of sending the ACK by the addressed endpoint only. The third term defines the power consumption in receiving the beacon and data. The fourth and fifth terms represent power consumption due to ACK transmission and other overheads (like waking up main radio from deep sleep, sleep power and turnaround power) respectively. Equation (2) represents the delay.

Next, we model the power consumption of B-MAC which is one of the most commonly used unsynchronized low duty cycle MAC protocol. Here, endpoints sleep, wakeup and poll the channels periodically at $T_{\text{wi}}$ intervals. The average power consumption ( $P_{\text{avg}}^{\text{BMAC}}$ ) of an endpoint is given by (3). As on average, the receiver catches the preamble half way through transmission, therefore, power consumption includes listening to the channel about half of the preamble, data reception, ACK transmission, and clear channel assessments during time (T). Other power consumption factors are overhearing of preamble, reception of packet headers by the nontargeted endpoints, sleeping, and switching from one state to another.

Equation (4) shows the average delay ( ${\text{Delay}}_{\text{B}-\text{MAC}}$ ) required for receiving the downlink packet:

$\begin{array}{cc}\hfill P_{\text{avg}}^{\text{BMAC}}& =(P_{\text{rx}}*\left(T_{\text{data}}+\frac{T_p}{2}\right)+P_{\text{tx}}\frac{L_{\text{ack}}}{R_{}}+P_{\text{rx}}*\left(\frac{T_{\text{cca}}}{T_{\text{wi}}}*T\right)\hfill \\ \hfill & \hspace{1em}\hspace{1em}+N*\left(T_{\text{hdr}}+\frac{T_p}{2}\right)*P_{\text{rx}}\hfill \\ \hfill & \hspace{1em}\hspace{1em}+\left(P_{\text{sl}}*T_{\text{sl}}+P_{\text{set}}*T_{\text{set}}+P_{\text{tt}}*2T_{\text{tt}}\right)\phantom{\left(\frac{T\text{cca}}{T\text{wi}}*T\right)})/T,\hfill \end{array}$

(3)

where $T_{\text{sl}}=T-(T_{\text{cca}}+T_{\text{data}}+T_{\text{ack}}+T_{\text{set}}+T_{\text{tt}}+T_p/2)$ ;

${\text{Delay}}_{\text{B<!--?btext?-->}-\text{<!--?etext?-->MAC}}=T_{\text{data}}+T_{\text{cca}}+T_{\text{ack}}+\frac{T_p^{\text{avg}}}{2}+T_{\text{tt}}+T_{\text{set}},$

(4)

where $T_p^{\text{avg}}=({\text{Delay}}_{\max \hspace{0.17em}}+{\text{Delay}}_{\min \hspace{0.17em}})/2$ , ${\text{Delay}}_{\max \hspace{0.17em}}=T_{\text{wi}}+T_{\text{data}}$ , ${\text{Delay}}_{\min \hspace{0.17em}}=T_{\text{data}}$ .

Equations (5) and (6) model the power consumption ( $P_{\text{avg}}^{\text{WMAC}}$ ) and latency (Delay_WiseMAC) of WiseMAC. The average power consumption includes power consumption on receiving the data packet, transmission of ACK, and other overheads:

$\begin{array}{cc}\hfill P_{\text{avg}}^{\text{WMAC}}& =(P_{\text{rx}}*\left(\frac{\bar{X}+L_{\text{data}}}{R}\right)+P_{\text{tx}}\frac{L_{\text{ack}}}{R}+\left(N-1\right)\hfill \\ \hfill & \hspace{1em}\hspace{1em}*\bar{Y}*P_{\text{rx}}+P_{\text{sl}}*T_{\text{sl}}\hfill \\ \hfill & \hspace{1em}\hspace{1em}+P_{\text{rx}}*\frac{T*T_p}{T_{\text{wi}}}+P_{\text{set}}*T_{\text{set}}+P_{\text{tt}}*T_{\text{tt}}\phantom{\left(\frac{\bar{X}+L_{\text{data}}}{R}\right)})/T,\hfill \end{array}$

(5)

where $\bar{X}=2\theta L(1-e^{{\hspace{0.17em}\hspace{0.17em}}^{-T_{\text{data}}/4\theta L}})$ , $\bar{Y}=(T_{\text{data}}+12\theta L*T_{\text{data}})/2T_{\text{wi}}(1-e^{{\hspace{0.17em}\hspace{0.17em}}^{-T_{\text{data}}/4\theta L}})$ , and $T_{\text{sl}}=T-(T_{\text{data}}+T_{\text{ack}}+T_{\text{set}}+T_{\text{tt}}+T_{\text{wi}}/2)$ ;

${\text{Delay}}_{\text{WiseMAC}}=T_{\text{data}}+T_p+T_{\text{ack}}+T_{\text{tt}}+T_{\text{set}}+\frac{T_{\text{wi}}}{2}.$

(6)

Next, we model the power consumption and latency of X-MAC. It uses small strobe preambles. The polling time for the receiver is equal to $2T_P+T_{\text{ack}}$ , where $T_P$ represents preamble time and $T_{\text{ack}}$ represents ACK timings. Equations (7) and (8) describe the average power consumption ( $P_{\text{avg}}^{\text{XMAC}}$ ) and latency (Delay_XMAC) for receiving a downlink packet from the coordinator:

$\begin{array}{cc}\hfill P_{\text{avg}}^{\text{XMAC}}& =(P_{\text{rx}}*\frac{L_{\text{data}}}{R_{}}+P_{\text{tx}}\frac{L_{\text{ack}}}{R_{}}+T_{\text{poll}}*P_{\text{rx}}*T*N\hfill \\ \hfill & \hspace{1em}\hspace{1em}+P_{\text{sl}}{*T}_{\text{sl}}+P_{\text{set}}*T_{\text{set}}+P_{\text{tt}}*T_{\text{tt}}\phantom{\frac{L_{\text{data}}}{R_{}}})/T,\hfill \end{array}$

(7)

where $T_{\text{poll}}=(2*T_{\text{set}}+2*L_p+L_{\text{ack}})/T_{\text{wi}}$ and $T_{\text{sl}}=T-(T_{\text{data}}+2T_{\text{ack}}+T_p+3T_{\text{set}}+T_{\text{tt}}+T_{\text{wi}}/2)$ ;

$\begin{array}{cc}\hfill & {\text{Delay}}_{\text{XMAC}}\hfill \\ \hfill & \hspace{1em}=T_{\text{data}}+T_b*\frac{T_{\text{wi}}}{2(T_p+T_{\text{ack}})}+2T_{\text{ack}}+T_{\text{tt}}+3T_{\text{set}}.\hfill \end{array}$

(8)

Equations (9) and (10) model the power consumption ( $P_{\text{avg}}^{\text{Zigbee}}$ ) and latency (Delay_Zigbee) of Zigbee MAC. For the best energy efficiency, we analyze the beacon-enabled mode of Zigbee. Endpoints maintain synchronization by receiving beacon from coordinator, which is transmitted at $T_{\text{wi}}$ intervals. The coordinator transmits the data by using CSMA/CA scheme. The endpoint then acknowledges the successful reception of the data by transmitting the ACK frame. The average power consumption includes power consumption of receiving data packet and beacon, transmission of ACK, overheads involved like sleep power, wakeup power, turnaround power, and beacon overhearing by the nontargeted endpoints:

$\begin{array}{cc}\hfill P_{\text{avg}}^{\text{Zigbee}}& =(P_{\text{rx}}*T_{\text{data}}+P_{\text{tx}}\frac{L_{\text{ack}}}{R}+P_{\text{rx}}*\left(T_{\text{poll}}*T*N\right)\hfill \\ \hfill & \hspace{1em}\hspace{1em}+P_{\text{sl}}*T_{\text{sl}}+P_{\text{set}}*T_{\text{set}}+P_{\text{tt}}*2T_{\text{tt}}\phantom{\frac{L_{\text{ack}}}{R}})/T,\hfill \end{array}$

(9)

where $T_{\text{poll}}=(T_{\text{set}}+2*T_{\text{wi}}*\theta +T_b)/T_{\text{wi}}$ , $T_{\text{sl}}=T-(T_b+T_{\text{data}}+T_{\text{ack}}+2T_{\text{cca}}+2T_{\text{set}}+T_{\text{tt}})$ ;

${\text{Delay}}_{\text{Zigbee}}=T_{\text{data}}+2T_{\text{cca}}+T_b+T_{\text{ack}}+2T_{\text{tt}}+T_{\text{set}}.$

(10)

In the last, we found the average power consumption and latency of T-MAC protocol. A beacon frame of length (Lb) is transmitted at $T_{\text{sync}}$ intervals for the synchronization of endpoints. Each endpoint polls the channel for RTS messages at $T_{\text{wi}}$ intervals. A data frame transmission consists of a random delay due to random back off within contention window (CW) followed by RTS, CTS, Data, and ACK frames. After receiving the RTS frame the nontargeted endpoints go to sleep mode again. Equation (11) describes the average power consumption ( $P_{\text{avg}}^{\text{TMac}}$ ) and equation (13) defines the latency (Delay_TMAC) involved in receiving the data packet from the coordinator. Equation (12) shows the polling interval:

$\begin{array}{cc}\hfill P_{\text{avg}}^{\text{TMac}}& =(P_{\text{rx}}*\frac{L_{\text{data}}}{R}+P_{\text{tx}}\frac{L_{\text{cts}}+L_{\text{ack}}}{R}+\left(\frac{T_{\text{cw}}}{2}+\frac{L_{\text{rts}}}{R}\right)\hfill \\ \hfill & \hspace{1em}\hspace{1em}*N*P_{\text{rx}}*T+T_{\text{poll}}*P_{\text{rx}}*T+P_{\text{sl}}*T_{\text{sl}}\hfill \\ \hfill & \hspace{1em}\hspace{1em}+\left(T_{\text{cw}}-\frac{L_b}{R}\right)*\frac{1}{T_{\text{sync}}}*P_{\text{rx}}\hfill \\ \hfill & \hspace{1em}\hspace{1em}+P_{\text{set}}*4T_{\text{set}}+P_{\text{tt}}*T_{\text{tt}}\phantom{\left(\frac{T_{\text{cw}}}{2}+\frac{L_{\text{rts}}}{R}\right)})/T,\hfill \end{array}$

(11)

where

$T_{\text{poll}}=\frac{2*T_{\text{set}}+T_{\text{cw}}+T_{\text{rts}}}{T_{\text{wi}}}$

(12)

and $T_{\text{sl}}=T-(T_{\text{rts}}+T_{\text{cts}}+(T_{\text{cw}}+T_b)/4+T_{\text{data}}+T_{\text{ack}}+4T_{\text{set}}+T_{\text{tt}})$ ;

$\begin{array}{cc}\hfill & {\text{Delay}}_{\text{TMAC}}\hfill \\ \hfill & \hspace{1em}=T_{\text{data}}+\frac{T_b+T_{\text{wi}}}{4}+T_{\text{ack}}+T_{\text{rts}}+T_{\text{cts}}+T_{\text{cw}}+T_{\text{tt}}+3T_{\text{set}}.\hfill \end{array}$

(13)

7. Results and Discussions

We found the average power consumption of the different MAC protocols using the input parameters shown in Tables 5 and 6. The parameters are taken from [28–30, 33]. Figure 10 shows the power consumptions during the downlink communication of our proposed MAC protocol and other existing MAC protocols. The proposed MAC outperforms the existing protocols in terms of power consumption. The main reason of more power consumption of these protocols as compared to our proposed one is that all these MAC protocols spend energy in periodic channel assessment and polling activities, while in the proposed MAC only the low power radio is in receiving mode all the time for monitoring the channel activities with a negligible power and all other components are in deep sleep mode.

Table 5

Common Input Parameters.

Symbol	Value
$P_{\text{tx}}$	26 mW
$P_{\text{rx}}$	13.5 mW
$T_{\text{data}}$	8 ms
$T_{\text{ack}}$	0.6 ms
$P_{\text{tt}}$	13.5 mW
$T_{\text{tt}}$	0.4 ms
R	40 Kbps
$L_{\text{data}}$	40 Bytes
$P_{\text{set}}$	0.0043 mW
$T_{\text{set}}$	0.25 ms
$T_{\text{cca}}$	3 ms
$P_{\text{sl}}$	0.0015 mW
$L_b$	20 Bytes
$L_{\text{ack}}$	5 Bytes
$L_{\text{wup}}$	7 Bytes
N	20
$\mathrm{\Theta }$	30 ppm
$P_{\text{wur}}$	470 nW

Table 6

Parameters specific to each MAC.

Proposed MAC
$P_{\text{rxwuc}}$	910 nW
$T_{\text{wuc}}$	3.75 ms
$P_{\text{twack}}$	26 mW
$R_{\text{wuc}}$	9 Kbps
B-MAC
$T_{\text{wi}}$	50 ms
$T_p$	86.7 ms
Wise MAC
$T_{\text{wi}}$	400 ms
$T_p$	20 ms
X-MAC
$T_{\text{wi}}$	100 ms
$T_p$	2.41 ms
Zigbee
$T_b$	20 ms
TMAC
$T_{\text{cw}}$	4 ms
$T_{\text{cts}}$	1.2 ms
$T_{\text{rts}}$	1.2 ms
$T_{\text{sync}}$	900 ms
$T_{\text{wi}}$	90 ms
$T_b$	4 ms

Figure 10

Power consumption versus packet interarrival time.

We also found from Figure 10 that due to long preamble, B-MAC needs more power than other protocols. The performance improvement of X-MAC over B-MAC is due to small strobe preambles, which reduces receiving power up to certain limit. The reason for the improved power consumption of our proposed MAC is that the coordinator sends a wakeup call and wakes up the main radio of the desired endpoint only when it is needed, thus resulting in reduced idle listening and overhearing.

Figure 11 shows the latency comparison of our proposed MAC with B-MAC and T-MAC for downlink communication. We consider B-MAC and T-MAC as representatives of asynchronous and synchronous MAC protocols, respectively. The main components responsible for the delay in our proposed MAC are the time required for receiving the wakeup call using the wakeup radio and the reception of the beacon and data packets using the main radio. Unlike the LPL protocols, it does not depends on wakeup interval. Hence, the latency remains constant.

Figure 11

Delay versus wakeup interval.

On the other hand, the latency of B-MAC and T-MAC depends on wakeup interval (the interval within which endpoint alternates between sleeping and listening for activity on the channel). From Figure 11, we observe that latency for T-MAC and B-MAC is several orders of magnitude higher than that of our proposed MAC. It is significant for the scenarios like bridge monitoring, river monitoring, building monitoring, and so forth where the sampling rate can be in the order of months to years. For wakeup intervals less than 10 ms, the B-MAC and T-MAC dominates but such low wakeup interval is not applicable in any LECIM applications. For LECIM applications where the data arrival is rare and infrequent, the polling mechanism is not suitable because it trades off energy with latency. Hence, the use of wakeup radio is better solution to use. This eliminates the polling and waking up the endpoints only when there is data to send.

Figure 12 shows the energy consumption for over all communication, that is, for both uplink and downlink communication using our proposed MAC against the other existing MAC protocols for different arrival rates. As our proposed method does not use the duty cycling and periodic sampling or channel assessment, it dominates other MAC protocols in terms of energy consumption.

Figure 12

Energy Consumption versus packet interarrival time.

The battery lifetime for the number of events per day is shown in Figure 13. For finding lifetime of the endpoint, we consider the energy consumption during communication as well as during sleep time. We can see that for low events, smaller superframe duration has a longer lifetime. Lifetime is very high for low arrival rate, but eventually saturates for higher arrival rates due to the large number of packets generation. The lifetime model for the proposed MAC to find the lifetime of an endpoint, is given by equation (14):

${\text{Life}}_{\text{time}}=\frac{V*{\text{Bat}}_{\text{cap}}}{\text{To}{\text{t}}_{\text{energy}}}*60*60.$

(14)

Figure 13

Lifetime versus load per day.

8. Conclusions

We proposed a beacon-enabled framed slotted aloha MAC for LECIM. For downlink communication, we used a wake-up radio approach which promises low energy consumption and low latency. We investigated probable superframe sizes, slot sizes, slot durations, and corresponding packet sizes.

We compared our protocol with the well-known beacon-enabled ZigBee MAC, WiseMAC, T-MAC, B-MAC, and X-MAC protocols and found that our protocol outperformed those MAC protocols in terms of power consumption and delay. We further investigated energy consumption and lifetime of our protocol for different arrival rates. The energy consumption and battery lifetime are satisfactory and can meet the LECIM requirements. Latency, which is an important parameter for downlink communication, is also satisfactory. The proposed protocol is simple to implement and flexible in terms of network size.

In the future, we will extend our work to include clustering and multihop communication.