MCP: An Energy-Efficient Code Distribution Protocol for Multi-Application WSNs.
ABSTRACT In this paper, we study the code distribution problem in multi-application wireless sensor networks (MA-WSNs), i.e., sensor net- works that can support multiple applications. While MA-WSNs have many advantages over traditional WSNs, they tend to require frequent code movements in the network, and thus here new challenges for de- signing energy efficient code dissemination protocols. We propose MCP, a stateful Multicast based Code redistribution Proto- col for achieving energy efficiency. Each node in MCP maintains a small table to record the interesting information of known applications. The ta- ble enables sending out multicast-based code dissemination requests such that only a subset of neighboring sensors contribute to code dissemina- tion. Compared to broadcasting based schemes, MCP greatly reduces signal collision and saves both the dissemination time and reduces the number of dissemination messages. Our experiments results show that MCP can reduce dissemination time by 25% and message overhead by 20% under various network settings.
Conference Proceeding: Planning updates in multi-application wireless sensor networks.[show abstract] [hide abstract]
ABSTRACT: One of the arising issues in wireless sensor networks is running multiple applications to reduce deployment, administrative and management costs. In this paper we assume a sensor network in which nodes of a group have a set of same applications in their external flash memory that some of them are loaded and running. Occasionally, these applications should be updated for reasons that are manifold ranging from fixing software bugs to retasking. It is often that updates for a subset of applications happen at the same time, for example when a routing protocol shared among a subset of applications is changed. To bring the sensor nodes up to date with the new versions of the applications, existing strategies transfer the delta code, a smaller code obtained from the differential compression between the binary representations of the old and the new version of each application, and let the sensor nodes rebuild the new version from the received delta and the old version. We discuss that these strategies are blind to the order of updates when a set of updates occurs simultaneously. We introduce a heuristic planner that yields a sequence for a set of simultaneous updates, which minimizes the total delta size without adding overhead on the sensor nodes. We illustrate the efficiency of our planner on some TinyOS applications.Proceedings of the 16th IEEE Symposium on Computers and Communications, ISCC 2011, Kerkyra, Corfu, Greece, June 28 - July 1, 2011; 01/2011
MCP: an Energy-Efficient Code Distribution
Protocol for Multi-Application WSNs
Weijia Li, Youtao Zhang, Bruce Childers
Computer Science Department, University of Pittsburgh, Pittsburgh, PA 15260
Abstract. In this paper, we study the code distribution problem in
multi-application wireless sensor networks (MA-WSNs), i.e., sensor net-
works that can support multiple applications. While MA-WSNs have
many advantages over traditional WSNs, they tend to require frequent
code movements in the network, and thus here new challenges for de-
signing energy efficient code dissemination protocols.
We propose MCP, a stateful Multicast based Code redistribution Proto-
col for achieving energy efficiency. Each node in MCP maintains a small
table to record the interesting information of known applications. The ta-
ble enables sending out multicast-based code dissemination requests such
that only a subset of neighboring sensors contribute to code dissemina-
tion. Compared to broadcasting based schemes, MCP greatly reduces
signal collision and saves both the dissemination time and reduces the
number of dissemination messages. Our experiments results show that
MCP can reduce dissemination time by 25% and message overhead by
20% under various network settings.
Wireless sensor networks (WSNs) have recently emerged as a promising com-
puting platform for applications in non-traditional environments, such as deep
sea and wild fields. They are usually under tight memory and energy constraints,
e.g., a Telos sensor node has only 48KB program memory . Many WSNs can
load only one application per node and the same application to all nodes in the
network. We refer to these WSNs as single-application WSNs or SA-WSNs.
While one sensor is usually small and cheap, as the network size scales, a
large WSN may consist of thousands of sensors making it economically less ap-
pealing to run just one application. Recently, researchers have envisioned the
wide adoption of multi-application WSNs or MA-WSNs, which can support sev-
eral applications in one network infrastructure [20,17]. In a MA-WSN, a sensor
stores the code of multiple applications in its external flash memory and loads
the selected application into its program memory for the desired functionality.
The latter program is referred to as the active application. The recent technol-
ogy and research advances clear ways for adopting MA-WSN design. Firstly it is
now possible to integrate more memory (especially flash memory) with the same
budget ; secondly different sensing, clustering, routing and data aggregation
protocols have been proposed to reduce the energy consumption of performing
functionalities of one application . As a result, it is now possible to support
multiple applications during the lifetime of a MA-WSN.
MA-WSNs have many advantages over SA-WSNs. For example, MA-WSN
can be deployed in a national park to monitor both wildfires and animal move-
ment. More sensors could be set to monitor the animal movement in the early
morning or late afternoon when animals tend to leave from or return to their
habinates; while more sensors could be set to monitor wildfires in the summer
season when the weather is dry and the chance to catch fires is high. By ex-
ploiting the same network infrastructure for both events, (1) MA-WSNs save
the investment and effort in deploying and testing two sensor networks; (2) the
sensor network adapts better to the dynamic changing environment and even
adjusts the coverage according to the need.
However, not all nodes in MA-WSNs have the code of all running applica-
tions. Some sensors may need to switch to run the code that can be found neither
in their flash memory nor from their neighboring sensors. This results in more
code movements and makes it critical to design energy-efficient post-deployment
code dissemination/redistribution protocols in MA-WSNs. Most existing code
dissemination protocols, such as Deluge , MNP , Stream  are designed
to disseminate the same code to all sensors in the network. While it is possi-
ble to adopt a naive drop-after-receive scheme that discards unnecessary code
after dissemination, applying these protocols in MA-WSNs tends to introduce
high overhead. A recent proposed protocol, Melete , has a similar design
goal. However, it employs broadcast strategy in dissemination, which introduces
significant signal collision and communication overhead in disseminating appli-
cations with large code sizes. MDeluge  uses a tree-based routing approach to
disseminate the application code to the sensors that need to run the application.
The pre-computed routing table is fixed during one application upgrade, thus it
is subject to the network conjestion and single point failure.
In this paper, we propose a multicast-based code redistribution protocol,
MCP, for the purpose of achieving energy efficiency. MCP employs a gossip-based
source node discovery strategy. Each sensor summarizes the application infor-
mation from overheard advertisement messages. Future dissemination requests
are forwarded to nearby source nodes rather than flooding the network. Our ex-
periments show that MCP greatly reduces both dissemination time and message
overhead, and achieves 10-20% reductions in various settings.
In the remainder of the paper, we describe the code dissemination back-
ground in Section 2 and the MCP protocol in Section 3. Section 4 evaluates the
effectiveness of MCP under different settings. Related work is discussed in Section
5, andSection 6 concludes the paper.
shaded nodes needs to run “A”
Fig.1. A multi-application WSN (MA-WSN).
2 Code Dissemination and Problem Statement
As shown in Fig. 1, a WSN consists of one sink node and a number of sensors,
e.g. MICA2 nodes. The sink node connects directly to the PC and thus has no
power and computation restrictions. Each MICA2 node has 128KB program
memory, 4KB data memory and 512KB external flash memory.
A remote sensor in MA-WSN keeps the code images of several applications
in its external flash and loads the active application to its program memory. To
execute a different application, the bootloader of the sensor swaps in the desired
code image and reboots the sensor. A recent study showed that to support
effective dissemination, the whole code dissemination functionality or at least
part of it should be integrated in the active application . Thus, a sensor
normally performs the operations of the active application and enters the code
dissemination mode only after receiving special primitives, i.e., data packets with
special opcode bits.
An application to be disseminated is usually divided into a sequence of pages,
each of which consists of multiple data packets (Fig. 2). In TinyOS each packet
is 29 bytes long and contains a 23 byte payload. To adapt to the lossy wire-
less communication channel, Deluge  disseminates code at page granularity
in increasing order of page number. That is, a requesting sensor has to finish
receiving all the packets in one page before sending out requests for the next
page; however, packets within one page may be received out of order as some
packets may be lost and need to be retransmitted. During code dissemination,
the requesting sensor buffers packets from the current page in data memory and
writes to the external flash after receiving the whole page.
2.2 Problem Statement
The problem that we study in this paper is to design an energy-efficient
code dissemination protocol in MA-WSNs. We illustrate the protocol design
challenges using the following example. As shown in Fig. 1, three applications
(a) Sensor Memory
(b) Disseminating application in
pages and packets
Fig.2. Sensor memory organization and code dissemination in pages and packets.
are distributed across different nodes in a network. A problem arises when there
is a need to reprogram some nodes to run application A.
There are two existing approaches. A naive solution is to directly apply Del-
uge and disseminate application A from the sink to all sensors. After dissemi-
nation, the nodes that do not need A discard the code from their storage. The
solution is clearly not a good choice due to unnecessary packets transmissions
to the nodes that don’t need it. The other solution is to let requesting nodes
initiate code dissemination and fetch A from nearby sensors. Melete  is such
a protocol — the nodes that need to run A broadcast their requests within a
controlled range and discover the source nodes that have A. Sources then send
back the requested data packets. However, as a stateless protocol, Melete does
not record the source nodes and has to discover them repeatedly. When trans-
mitting applications with multiple pages, multiple sources within the range may
respond and thus create significant signal collision.
In this paper, our goal is to design an energy-efficient code dissemination
protocol for MA-WSNs. Our target is to reduce both dissemination completion
time and the number of messages transmitted during dissemination.
3 The MCP Protocol
An overview of our protocol is as follows.
– Sensors in MCP periodically broadcast ADV messages to advertise their knowl-
edge about running applications in the network, which is similar to Deluge.
Each sensor summarizes its overheard ADV messages in an application infor-
mation table (AIT).
– To reprogram a subset of sensors, the sink floods a dissemination command
that guides which sensors should switch to run application A. For example,
a command “[B→A, p=0.25]” indicates that the sensors whose active appli-
cation is “B” should switch to “A” with a 25% probability. That is 25% of
the nodes that are currently running application “B” will switch to “A”.
– After receiving the command from the sink, each sensor identifies its dissem-
ination role as one of the followings.
(i) a source if the sensor has the binary of application A;
(ii) a requester if the sensor does not have the binary of A but needs to switch
to run A; or
(iii) a forwarder if the sensor is neither a source nor a requester.
– A requester periodically sends out requests (i.e., REQ messages) to its closest
source, until it acquires all the pages of application A. Instead of broadcast,
the REQ messages are sent to the source via multicast. A requester resends
the REQ message until it timeouts. It tries to request data from each source
node several times before marking the node as a temporary non-available
– A source node responds with the data (i.e., Data messages) that contain
code fragments while a forwarder forwards both request and data packets.
Similar to Melete and Deluge, MCP has three types of messages: an ADV
message that advertises interesting applications; a REQ message that asks for
packets of a particular page; and a Data message that contains one data packet
(i.e, a piece of code segment).
3.2 ADV Message and Application Information Table (AIT)
In MCP, each sensor periodically broadcasts ADV messages, and summarizes
the information of overheard ADV messages into a small application information
table (AIT). Fig. 3 illustrates the algorithm.
Each ADV message contains the information of one application: (i) an applica-
tion ID and version number; (ii) the number of pages of the application; (iii) the
information of two closest source sensors — the source ID and number of hops
to the source (S, H); (iv) the CRC checksum. If a sensor has multiple known
applications, it advertises them in a round-robin fashion. Note that a sensor may
not have the code images of all its known applications.
The AIT summarizes the overheard ADV messages. In addition to the ap-
plication summary, AIT stores up to three closest source nodes for each known
application, and the uplink sensor ID for each source, i.e., from which the source
information was received. The size of each application entry in the AIT is 12
bytes. Assume that the number of the applications running in the network is 10,
the AIT size will be only 120 bytes, which makes it fit perfectly in the program
When an incoming ADV message contains new information, the correspond-
ing entry in the AIT is updated. Assume a sensor S1 receives an ADV message
from S2, and the message identifies two nearby sources (S3, H3) and (S4, H4)
where H3 and H4 indicate the number of hops from S2 to sources S3 and S4. If