Power-Aware Data Transmission for Real-Time Communication in Multimedia Sensor Networks

The availability of smart sensors equipped CMOS cameras made it possible to capture and transmit multimedia data ubiquitously. The real-time performance is essential in many applications including surveillance and healthcare monitoring in multimedia sensor networks (MSNs). One of the real-time performance indicators is to transmit the packets within their deadline. Furthermore, in information-rich, battery-powered, and resource-constrained MSNs, it is a challenging problem to extend network lifetime decreasing communication cost. In previous researches, periodic message exchange for neighbor information maintenance leads to reducing network lifetime. This paper presents a power-aware data transmission for real-time communication in MSNs. The proposed scheme not only provides real-time performance, but also conserves energy consumption through efficient transmission and without periodic message exchange. The simulation results show the effectiveness of the proposed scheme in achieving the desired deadline success ratio and prolonging the network lifetime.


Introduction
Advances in microelectromechanical systems (MEMS) technology and wireless communications have put forward the development of smart sensors which handle the various kinds of data and consist of sensing, data processing, and communicating components [1]. The camera-equipped sensors, a kind of smart sensor, are deployed in the target area for collaborative multimedia data processing. Multimedia sensor networks (MSNs) are identified as a dominant research area and have contributed to progress in military and environmental applications such as remote and distributed videobased surveillance, environmental and structural monitoring, and industrial process control [2].
It is imperative that data transmission in such applications meets real-time constraints. The image and video data captured by the sensors should be delivered to the control center within the predetermined time, that is, deadline. As shown in Figure 1, a smart sensor detects the enemy attack and then reports the information to control center through multihop communication. Many real-time routing protocols have been proposed for considering deadline satisfaction or the end-to-end delay to report the time critical data [3,4].
The performance is usually referred to as a quality of service (QoS) requirement [5,6]. Most real-time routing protocols have taken account of the end-to-end delay by means of summing up the whole links delay in each path. This causes much wasteful processing and much overheads with respect to route maintenance and delay measurement.
The consideration of the peculiarities of MSNs such as information-rich data, limited power, hardware constraints, dynamic network topology (easy to die due to limited battery or mobile sensors), and large-scale deployment has posed many challenges such as energy-aware routing protocols in the design and management of MSNs. Above all, the extension of network lifetime through improvement of energy efficiency is a critical design issue in most routing protocols for MSNs. In MSNs compared to the traditional sensor networks, image and video data is much bigger than the scalar data such as temperature, pressure, humidity, or location of objects. Due to the inherent constrains of MSNs and the requirement for real-time applications, it is vital to improve energy efficiency for data delivery through minimizing communication overheads. Communication overheads are involved in periodic message exchange for route discovery and maintenance. Geographic routing which forwards packets only based on the location of itself, its neighbors, and the destination sets out to remove communication overhead in conventional routing brought by route discovery and maintenance or topology updates. Instead of route discovery and maintenance, it is required to collect the location information of all its direct neighbors [7,8]. However, it is inevitable to exchange messages periodically to obtain the neighbor information. In contrast, flooding, a reactive technique with reliability, seems to be a good candidate for data transmission because it does not involve neighbor information maintenance, complex route discovery, and expensive topology updates. The flooding, a simple data transmission, suffers from the broadcast storm problem which leads to network lifetime depletion [9]. To solve the broadcast storm problem, several schemes have been proposed to reduce the redundancy in flooding mechanisms [10]. However, these algorithms either perform not good enough to reduce redundant transmissions or require each node to maintain one-hop or two-hop neighbor information using additional message exchange such as control message or HELLO message [11][12][13]. We have rethought of the periodic message exchange with respect to the overall energy consumption influencing on network lifetime.
In [14], author proposed a data transmission scheme enhancing real-time performance by increasing the deadline satisfaction ratio per unit energy consumption of timesensitive packets. It improved energy efficiency by flooding but effectively constrained energy consumption by controlling the scale of flooding, that is, flooding only when necessary. If unicasting meets the distributed subdeadline at a hop, CFlood aborts further flooding even after flooding has occurred in the current hop. However, author did not address the energy consumption owing to periodic HELLO message exchange for neighbor information maintenance. As mentioned above, it is required to consider both real-time performance and energy consumption in MSNs.
In this paper, we put forward a power-aware data transmission for real-time communication in MSNs in two aspects. (1) Real-time performance: the proposed scheme transmits data within the deadline by estimating end-to-end delay. Delay is proportional to the number of intermediate (forwarding) nodes on the transmission path between a source and SINK. In order to improve real-time performance, the proposed scheme provides the greedy forwarding which maximizes the distance between consecutive nodes on transmission path. Furthermore, the proposed scheme transmits data based on the neighbor information to enhance real-time data delivery. The information is maintained up to date at the nodes by piggy-backing during transmission.
(2) Energy conservation: the proposed scheme decreases the communication overhead in building and maintaining neighbor information with simple data transmission such as a constrained flooding. The constrained flooding screens redundant data transmission and is aware of residual energy for deciding next node called the forwarding node. Therefore, the proposed scheme extends network lifetime through balancing energy consumption. The objective of the proposed scheme not only provides real-time data delivery meeting the deadline but also extends the network lifetime through energy conservation.
Packets are transmitted to SINK within their deadline for real-time communication. The end-to-end delay is bounded to sum the one-hop delay. Each intermediate node on a transmission path can independently decide the one-hop delay using node information piggy-backed in the packet.
To build up the neighbor information efficiently, this is, without periodic message exchange, we introduce a simple and efficient data dissemination mechanism in the beginning as follows: the proposed scheme transmits data based on a constrained flooding-based mechanism which brings down the redundant transmission by reducing the number of the forwarding nodes. The proposed scheme provides the greedy forwarding maximizing the distance between consecutive forwarding nodes. It causes improved real-time performance because delay is proportional to the number of nodes on transmission path between source and SINK.
To extend network lifetime, if delay is bounded in the time requirement, it is considered the residual energy of the node which becomes the forwarding node. Consequently, the proposed scheme provides real-time data delivery extending network lifetime. The energy conservation derived from excluding periodic neighbor information exchange, decreasing the number of the forwarding nodes, and balancing the energy consumption caused by the forwarding node decision considering the residual energy of the nodes. The balanced energy consumption leads to distributing data transmission somewhat evenly and prolonging the network lifetime.
The rest of the paper is organized as follows. Section 2 introduces the related work. Section 3 illustrates the network model and definitions. In Section 4, we present a poweraware data transmission for real-time communication in MSNs. In Section 5, we analyze the simulation results of the proposed scheme by using NS-3. Finally, we conclude the work in Section 6.
International Journal of Distributed Sensor Networks 3

Related Work
Due to the above peculiarities of the networks, various routing protocols are proposed to provide QoS such as deadline success ratio, delay, and conservation of energy.
Researchers have continuously suggested real-time routing protocols in wireless sensor networks (WSNs). SPEED [15] is a real-time routing protocol in WSNs. It maintains the neighbor information and considers the end-to-end delay requirement taken in the method to sum up each links' delay. This leads to much wasteful calculation and overhead. It has not comprehensively taken the energy consumption into account. MMSPEED [16] provides the packet forwarding based on the probability distribution function and achieves the reliability by transmitting multiple copies of the packet. It does not consider the residual energy of each node. As a result, imbalance of energy distribution happens, which is to reduce the network lifetime.
Considering the properties of network, researchers have proposed various energy efficient routing protocols such as geographic routing and simple data transmission mechanisms, for example, flooding-based data transmission. Geographic routing does not require the route discovery or maintenance, which leads to conserve energy. It forwards the packet using the location [7,8]. However, the routing protocol exchanges the neighbor information (location) instead of route maintenance. It causes communication overheads.
There are many researches to improve the flooding efficiency. The location-aided flooding to reduce the number of redundant retransmission has proposed in [11]. It improves the energy efficiency by exploiting the location information. As a result, it prolongs the network lifetime. Another efficient flooding scheme has been introduced in [12]. It improves the performance with decreasing the amount of neighbor information. In the suggested algorithm, the number of hops to maintain in each node is limited to one hop. In [13], it provides both guaranteed data delivery and good bound on the number of forwarding nodes based on the partial two-hop neighbor information. In the flooding based data transmission, it cannot avoid the communication overhead caused by neighbor information maintenance.
An energy efficient flooding mechanism providing the real-time performance has been proposed in [14]. It achieves a higher deadline satisfaction ratio; however, the energy consumption due to periodic HELLO message exchange was not considered. Therefore, the periodic HELLO message exchange causes node depletion. Network dies due to the depleted node. The lifetime of a sensor network is most commonly defined as the time to the first node failure. In MSNs, it is crucial to data delivery failure.
Compared to previous researches, we provide a poweraware data transmission scheme for real-time communication. The deadline success ratio provides real-time performance. In addition, we improve network lifetime with power-aware data transmission without periodic control message exchange and with balancing energy consumption considering residual energy. We consider comprehensive communication cost concerning not only actual data transmission but also periodic control message exchange such as HELLO message for neighbor information maintenance. We could not afford to exclude periodic message exchange overheads with respect to the total communication cost because it is more crucial to prolong the network lifetime in MSNs which spends much more energy to deliver the multimedia data relatively much larger than scalar data in the traditional sensor networks. In this paper, we propose a real-time data transmission scheme without periodic control message exchange, which leads to energy conservation and then extending of network lifetime.

Network Model.
We assume a homogeneous MSNs architecture. The nodes are densely and randomly deployed in MSNs. We assume that all nodes in the network are equipped with the global positioning system (GPS) or distributed location services [16]. All the camera sensor nodes are aware of their own locations. They are assumed to know the location of SINK. In general, most of imaging processing systems require the location information about the camera sensor nodes in MSNs. All nodes are static and the transmission range of all nodes is initialized by . We assume multihop communication. The distance between node and node is given by ( , ), which is the Euclidean distance between and . We give the following definitions.

Definition.
We define neighbor, forwarding candidate set, and forwarding node in the proposed scheme as follows.
Definition 1 (neighbors (NBR)). Let and NBR denote a node and the set of neighbors of , respectively. That is, nodes in NBR( ) are within the transmission range of node and can receive signals transmitted by node . The neighbors of node is defined as NBR( ) = { | ( , ) ≤ , ̸ = }.
Definition 2 (forwarding candidate set (FCS)). Let and FCS represent a node and the forwarding candidate nodes of node , respectively. The FCS( ) is a subset of NBR( ). Given the source and the SINK (destination) , node is a node in the transmission path from and . The forwarding candidate set of node Definition 3 (forwarding node (FWD)). Let and FWD represent a node and a forwarding node of , respectively. The FWD( ) is one of FCS( ) which received the packet from and it forwards the packet. In case the residual energy is higher than the high threshold of the energy, FWD( ) is determined by distance to the SINK in FCS( ). of energy and Low is the low threshold of energy. These two thresholds are configurable parameters.
As shown in Figure 2, a node ( ) is one node on the transmission path between the source ( ) and the SINK ( ). There are five nodes in communication range of .
and has the largest residual energy in FCS( ). On the transmission path, 1 is the upstream node for and 4 is the downstream node for if is the forwarding node of 4 . From Figure 2, we introduce how NBR, FCS, and FWD work together. A node ( ) transmits a packet. NBR( ), { 1 , 2 , 3 , 4 , 5 }, receives the packet. At first, { 3 , 4 } discards the packet because ( , ) is larger than ( , ). FCS( ), { 1 , 2 , 5 }, computes, respectively, waiting time before packet transmission depending on delay estimation, residual energy, and distance to . One of FCS( ), { 1 }, becomes FWD( ) which satisfies the conditions as follows: (i) it can transmit the packet within the predetermined in the packet, (ii) the distance between it and is the shortest in FCS( ), and (iii) its residual energy is larger than low energy threshold, Low , in FCS( ). The 1 forwards the packet. Due to flooding-based data transmission, the packet from FWD( ), { 1 }, results in abortion message to the others of FCS( ), { 2 , 5 }, which have already received the packet from in Figure 2. This means that I forward this packet, so you do not have to forward it. As a result, the others FCS( ) discard the packet. In sender-based flooding schemes, the sender decides the forwarding node, which introduces communication overheads on maintaining the neighbor information [15] and leads to increasing energy consumption. In contrast, it notes that the receiver itself seems to determine whether to forward the packet or not in the proposed scheme.
Furthermore, the forwarding packet from FWD( ) works as acknowledgment for the sender, . The sender knows who its forwarding node is. Consequently, the intermediate nodes on the transmission path know their upstream node and downstream node. Without periodic message exchange, one-hop neighbor information can be obtained after data transmission has proceeded for a while. After then the proposed scheme transmits packet using the neighbor information without flooding-based mechanism. Energy conservation is achieved through the receiver-based data transmission and neighbor information without periodic control message.

Power-Aware Data Transmission for Real-Time Communication in MSNs
We present a power-aware data transmission for real-time communication in MSNs. The proposed scheme transmits packets meeting their deadline. To provide real-time performance and conserve energy consumption, we design the data transmission scheme based on delay estimation (Algorithm 2) without periodic control message exchange. The proposed scheme decreases the redundancy in floodingbased operation by means of reducing the number of the forwarding nodes and greedy forwarding that transmits packet to the node closest to SINK. In the proposed scheme, the node broadcasts the packet; however, one node FWD( ) transmits the packet under normal condition. The proposed scheme does not exchange periodic control message to collect the neighbor information. The node caches the estimated delay time of neighbors when it receives a forwarding packet from the neighbors. In the beginning of communication, the proposed scheme (Algorithm 5) builds up the neighbor information with a constrained floodingbased mechanism. After a while, it enhances the real-time performance using the neighbor information as depicted in Figure 3.
Our proposed scheme consists of three components.
(1) Waiting time computation and delay estimation: computing the waiting time before forwarding; the waiting time of each node is different according to residual energy and distance to SINK and estimating delay to SINK based on one-hop neighbor information in the transmitted packet.
(2) Forwarding decision: forwarding the packet provides real-time performance.
(3) Neighbor information update: for communication, neighbor information is updated.
As shown in notations section the notations with a brief description are used in the proposed scheme. energy, then the node nearest to SINK will forward the packet because it will have the shortest waiting time to forward the packet. Algorithm 1 shows how to compute the waiting time (Time Wait ).
If the residual energy is between the high threshold of energy and the low threshold value of energy, then the waiting time, Time Wait , will depend on both of the residual energy and the distance to SINK. This will help balanced energy consumption among the nodes. If the residual energy is smaller than the low threshold value of energy, then it will wait the maximum time because it will not forward the packet unless all nodes which received the packet have the residual energy smaller than the low threshold value of energy. Due to this processing, it prevents a node from dying quickly even though other nodes have sufficient residual energy.
The value of is a configurable parameter that is set to any value between 0 and 1. assigns relative weights to distance to SINK and residual energy. The forwarding decision can be distance-based or energy-based depending on the value of . For example, the value of close to 0 favors the distance-based forwarding decision. Figure 4 demonstrates delay performance under different values of . The distancebased forwarding decision shows better performance than the energy-based forwarding decision in Figure 4. Figure 5 shows average energy consumption under different values of when the depleted nodes happen in the network. Average energy consumption is not quite different according to the value of . Therefore, the appropriate value of is less than 0.5 with respect to better delay performance.
As a result of the simulation, the delay and energy performance are better when the value of Factor is between 200 and 300. The performance is better when the value of Factor is 10. The value of Factor is influenced by network size.   hops and real transmission delay between two nodes. In the beginning, the node does not have any real value of transmission delay; therefore, it will use the estimated number of hops only to compute the estimated delay time. The estimated number of hops is calculated by dividing the distance to SINK by transmission range. One-hop delay is calculated at the upstream node using the transmission time and reception time. The elapsed time refers to Delay OneHop :

Delay
where Time Rcv is the time when upstream node receives the last bit of packet to the physical link and Time Trans is the time when downstream node transmits the first bit of packet to the physical link. Time Wait is the duration that the packet is waited on the upstream node before transmission. Therefore, once upstream node successfully receives the packet, the node measures the elapsed time from transmission of downstream node to reception of upstream node. The total estimated delay time between node and SINK is calculated as where Delay to End is the estimated end-to-end delay. Hops Expected is the expected hop count to SINK, which is estimated by ( , SINK)/ . In other words, Delay to End is Delay OneHop multiplied by Hops Expected . Delay to End is compared to Deadline, the predetermined time requirement of the packet. After then the node updates the remaining time to Deadline. The deadline at node is computed as follows: When the node got the packet, it can know the actual transmission delay from −1 to because node knows the arrival time to node and the departure time at node −1 with the information in the received packet. The total delay time from node −1 to SINK equals the sum of the actual transmission delay from node −1 to node and the estimated delay from node to SINK. Because node knows the transmission delay from node −1 to node , the estimated delay from node to SINK can be replaced with transmission delay from −1 to × estimated number of hops as (3).
Furthermore, the node can receive the forwarding packet from node +1 as shown in Figure 2, the node can know the round traveling time between node and node +1 . Therefore, the node can compute the transmission delay time including the waiting time at node +1 . The node can compute the new estimated total delay from node . Due to the forwarding packet from next node, each node can know the actual transmission delay time to next node; the node will reflect those transmission delays more and more. Eventually, the total estimated delay will reflect actual transmission delay only. This reflects actual traffic condition at each node without additional message exchange as shown in Figure 6.

Round (k + 4)
Round (k + 5) Figure 6: The estimated delay is replaced with the actual delay in each round. Algorithm 1, Time Wait becomes the smallest if a node is the closest to SINK or has the larger residual energy. An example of forwarding decision is illustrated in Figure 7. When the node receives the packet, then it checks senders' location, sequence number of the packet, and Mode Trans in the header of the transmitted packet.

Out of Range.
When the receiver locates out between −60 degree and +60 degree from the line of sender to the sink, in this case most forwarding packet from the forwarder could not be received because there are high chance that the forwarder could locate close to the line from forwarder to sink node. Therefore the received packet will be discarded without receiving forwarding packet and comparing the sequence number of that packet.

4.3.2.
Receives the Packet from the FWD( ). If the sequence number of the received packet is same as the packet that the receiver sent before, then the receiver is the  original sender of the packet. Therefore, the packet can be regarded as the acknowledgment (ACK) signal from the first receiver, which means the packet was forwarded without hole. The packet can be used to compute the round trip latency time.

FCS( ) Receives the Packet from the FWD( ).
If the sequence number of the received packet is same as the packet the node received before, then other nodes already forwarded the packet. In addition, Mode Trans is FWD(0), which means that it does not need aid to forward the packet. Therefore, the node aborts the waiting event for the packet. This prevents flooding the packet.

NBR( ) Receives the Packet from the .
When the node receives the packet, it computes the transmission delay time, Delay OneHop , by checking the arrival time, Time Rcv . After deducting the transmission delay time, Delay OneHop , from Deadline, it compares the result with its estimated delay time, Delay to End . If the result is larger than the estimated delay time, Delay to End , then the node updates Deadline and transmission time, Time Trans , in the packet fields. This will be done while waiting for Time Wait . After Time Wait , it forwards the packet. If the result is smaller than the estimated delay time, Delay to End , that means that the node has a slim chance to deliver the packet within Deadline. Then the node shortens the waiting time a half, Time Wait /2 by changing Factor and Factor , and set Mode Trans bit to 1, that is, AID for help from the neighboring nodes. In addition, the node should modify Deadline and transmission time, Time Trans , in the packet header. The waiting event will be fired after Time Wait .

4.3.5.
Receives the Packet Whose Mode Trans Is 1 (AID). It means one of NBR( ) requires the emergent aid. Therefore, the receiver should forward the packet as soon as possible. The receiver checks whether it already received the packet same as this packet with the sequence number. If two packets have same sequence number and Time Trans of both is 1 (AID), then the receiver aborts the waiting event and discards those packets.
If there is no packet with same sequence number or Mode Trans is changed from 0 to 1 even though two packets have same sequence number, then do the following things. The node deducts the transmission delay time, Delay OneHop , from Deadline to compute new Deadline. Then it compares the value with the estimated delay time, Delay to End , at that node. If new value of Deadline is larger than the estimated delay time, Delay to End , then reset Mode Trans to 0 and wait for Time Wait before forwarding the packet. If new value of Deadline is smaller than the estimated delay, Delay to End , then the node shortens the waiting time a half, Time Wait /2, and fires the event, that is, forwards the packet.

Hole Management.
If the sender cannot receive any forwarding packet which can be used as acknowledgment during the maximum waiting time after sending a packet, there is no node within the transmission range. It is called International Journal of Distributed Sensor Networks 9 a hole. There can be two approaches to deal with hole. First, the sender increases the transmission range twice and retransmits the packet. Secondly, the sender, , let the previous sender, −1 , know that there exists hole around and retransmit the packet. In this case, the node will not be involved in forwarding the packet. Therefore, the packet will be forwarded by other nodes. The proposed scheme is the latency-sensitive approach. Thus, we choose the first approach.

Neighbor Information Update.
When the node −1 receives the forwarding packet from node , the node −1 can recognize that the packet is same as the packet it sent by comparing the sequence number of the packet. Then before discarding the packet, it reads the arrival time, Time Rcv , of that packet and updates the estimated delay time, Delay to End , at node −1 in the cache with sum of the estimated delay time, Delay to End , at node and the round trip time/2, that is, RTT/2. It is depicted in the line 5 of Algorithm 3.
When other nodes which received the packet whose Mode Trans is AID(1) from the node −1 receive the packet same as the packet from node , then they update their estimated delay, Delay to End , with the estimated delay, Delay Trans , from node before discarding the packet. It is illustrated in the line when other nodes which received the packet whose Mode Trans is FWD(0) from the node −1 receive the packet same as the packet from node except Mode Trans is AID(1); then they update their estimated delay, Delay to End , with the estimated delay, Delay to End , from node before forwarding the packet. When other nodes which received the packet whose Mode Trans is AID(1) from the node −1 receive the packet same as the packet from node , whether its Mode Trans is AID(1) or is FWD(0), then they discard it.
By doing this step, every node can use the estimated delay time which reflects actual delay time partially from second packet. As more packets flow, the estimated delay time reflect more actual delay time. Eventually every node involved in the transmission will use the actual delay time as its estimated delay time.
In order that the algorithm here operates, the packet header should have some fields including Deadline, Time Trans , estimated delay time Delay Trans , and Mode Trans as shown in Figure 8.

Simulation Environment.
In this section, we evaluate the proposed scheme in NS-3 v.3.19. According to [17], the energy consumption model is as follows:   where elec is the electronics energy, fs 2 is the amplifier energy in the free space and mp 4 is the amplifier energy in the multipath fading channel models, is the data size in bits, is the transmission distance, and 0 is a distance threshold. The simulation parameters are described in Table 1.

Performance Metrics.
We evaluate the following performance metrics.
(i) Deadline success ratio is defined as the ratio of the number of successfully delivered packets which reach SINK within the deadline to the total number of packets transmitted.
(ii) Average energy consumption includes average energy dissipation for communication, computation, and sensing energy dissipation.
We will evaluate the performance by comparing our scheme with the related works, CFlood [14] and MMSPEED [16], using neighbor information exchanged periodically.

Average Energy Consumption.
The energy consumption is the most important for the sensor networks. As shown in Figure 9, our scheme performs better than the data transmission scheme with exchanging control message periodically. The average energy consumption is closely related to network lifetime. The larger the average energy consumption is, the shorter the network lifetime is. It illustrates that average energy consumption result bigger difference between our scheme and the scheme with periodic control message exchange. is a configurable parameter that is set to 0.1, 0.2, and 0.3 as explained in Section 4. In our scheme, the distancebased forwarding decision when is close to 0 performs better than CFlood and MMSPEED. The energy consumption performance can be maintained when the number of nodes increases in Figure 9. Figure 10 shows that our scheme yields good energy conservation performance according to endto-end deadline. Therefore, our scheme not only provides real-time performance, but also prolongs network lifetime without periodic control message exchange.

End-to-End Deadline Success Ratio.
The end-to-end deadline is critical in the real-time communication. Figure 11 shows end-to-end deadline success ratio for our scheme and the data transmission scheme such as CFlood and MMSPEED. Figure 11 shows the performance for node density. Our proposed scheme meets the tolerated latency independent from node density and good performance without periodic message exchange when it is compared with the CFlood and MMSPEED. Figure 12 illustrates end-to-end deadline success ratio according to the required deadline.
The total time of the simulation is 4,000 seconds. is a configurable parameter that is close to 0 such as 0.1, 0.2, and 0.3. The distance-based forwarding decision enhances the real-time performance. Our scheme yields an acceptable performance without periodic control message exchange (Algorithm 4).

Conclusion and Future Work
In this paper, we present and evaluate a power-aware data transmission for real-time communication in MSNs. It is designed to provide real-time performance delivering multimedia data within the predetermined time (deadline) through delay estimation and greedy forwarding. In addition, it improves the energy conservation without periodic control message exchange and the constrained flooding-based data transmission. In contrast to previous schemes, the proposed scheme builds up neighbor information using the transmitted packet instead of periodic message exchange. Consequently, the proposed scheme conserves the energy consumption and, therefore, extends network lifetime, which is one of crucial design issues in MSNs. Simulations show that the proposed scheme performs good with respect to the deadline success ratio compared to the existing schemes.
There are some issues that remain to be studied. We have not considered the mobility of the nodes including camera sensor nodes and SINK. The network mobility should be taken into account in accordance with the recent researches and characteristic of real-time application in MSNs. In addition, it is desirable to adapt data transmission by applying data aggregation to decrease the amount of information-rich data such as image, video, and multimedia data. Finally, the security is a demanding issue with respect to the application such as surveillance and health-care monitoring which deal with the important data.

NBR( ):
The neighbors of node FCS( ): Theforwardingcandidatesetofnode FWD( ): The forwarding node of node Time Trans : The time when the packet is transmitted Time Propg : The time which the packet flows in the air Time Rcv : The time when the packet is received Packet Trans : The Packet transmitted Packet Sent : The Packet sent before Packet Rcv : The packet received Packet Waiting : The packet waiting in the packet list before forwarding : Transmission range ( , ): The Euclidean distance between node and node , where and are integers and ̸ = . Delay OneHop : The calculated one-hop delay at node Hops Expected : The expected number of hops between node and SINK, which is calculated ⌈ ( , SINK)/ ⌉. ⌈ ⌉ is ceiling function, which is = if and only if − 1 < ≤ where is integer Delay to End : The estimated end-to-end delay, which is Delay OneHop × Hops Expected Deadline: The predetermined time requirement Time Wait : The time for waiting before transmission Residual : Theresidualenergy Factor : The distance factor Factor : The energy factor Mode Trans : The mode that is set by the receiver and can be AID(1) and FWD(0).