A Self-Adaptive Spectrum Management Middleware for

Wireless Pers CommunDOI 10.1007/s11277-011-0443-z

A Self-Adaptive Spectrum Management Middlewarefor Wireless Sensor Networks

Robert Thompson · Gang Zhou · Lei Lu ·Sudha Krishnamurthy · Hover Dong · Xin Qi ·Yantao Li · Matthew Keally · Zhen Ren

© Springer Science+Business Media, LLC. 2011

Abstract The vision of the Internet of Things, wherein everyday objects are embedded withsmart wireless sensor devices, is making these sensor devices increasingly pervasive. As thedensity of their deployment in overlapping or adjacent areas increases, the contention for theunlicensed 2.4 GHz ISM band will also increase. To deal with the crowded spectrum, nodesmust use the channels more judiciously and be able to adapt by detecting and switching tothe most available channel. The SAS middleware that we have developed, is a self-adaptivespectrum management middleware for wireless sensor networks that enhances single-fre-quency MAC protocols with multi-frequency capability, without any change in hardware. Itallows a single-frequency MAC protocol, like B-MAC, to automatically adapt to the least

R. Thompson · G. Zhou (B) · L. Lu · H. Dong · X. Qi · Y. Li · M. Keally · Z. RenComputer Science Department, College of William and Mary, Williamsburg, VA, USAe-mail: [email protected]

R. Thompsone-mail: [email protected]

L. Lue-mail: [email protected]

H. Donge-mail: [email protected]

X. Qie-mail: [email protected]

Y. Lie-mail: [email protected]

M. Keallye-mail: [email protected]

Z. Rene-mail: [email protected]

S. KrishnamurthyUnited Technologies Research Center, East Hartford, CT, USAe-mail: [email protected]

123

R. Thompson et al.

congested physical channel at runtime. SAS supports a combination of receiver-initiatedand sender-initiated schemes to decide when to switch the channel and which channel toswitch to. We have implemented the B-MAC protocol integrated with SAS in TinyOS 2.1 onTelosB sensor devices and evaluated its performance on the conditions of varied data flowsand the interference produced by a jammer. The results demonstrate that the integratedB-MAC protocol outperforms B-MAC in terms of packet reception ratio, system throughput,average packet delay, and energy consumption.

Keywords Spectrum management · Wireless sensor networks · Mediaaccess control

1 Introduction

With the maturity and wide application of low-power wireless protocols, such as IEEE802.11b [1], 802.15.1 [2] and 802.15.4 [3], we envision a future in which wireless devices,such as wireless keyboards, power-point presenters, cell phone headsets, and health monitor-ing sensors [4] will be ubiquitous. Unfortunately, the pervasiveness of these devices leads toincreased interference and congestion within as well as between networks, since they adoptoverlapping physical frequencies. For example, 802.11b uses Direct Sequence Spread Spec-trum (DSSS) and divides the 2.4 GHz ISM band into 14 channels (5 MHz distance apart).IEEE 802.15.1 divides the 2.4 GHz ISM band into 79 1-MHz channels and uses FrequencyHopping Spread Spectrum (FHSS). IEEE 802.15.4 divides the 2.4 GHz ISM band into 165-MHz channels and uses DSSS. When these wireless devices are used in the same office orhome environment, there is a high likelihood that the 2.4 GHz ISM band will be overloadedand congested. This is particularly true, when the wireless nodes in the same vicinity aresending data at a high rate. One such example is a prognostic and health monitoring (PHM)application, in which multiple sensors are monitoring the load and status at a high samplingrate and transmitting that to a base station that is running the PHM algorithm.

In addition to the interference from co-existing networks and wireless devices, commu-nication in the 2.4 GHz ISM band may also be affected by existing electrical appliances. Forexample, Fig. 1 displays the carrier-sensed power levels of the 16 channels, from 11 to 26,in IEEE 802.15.4, as measured by the SeeMote [5] in a home environment. The x-axis is thechannel index number and the y-axis denotes the sensed power level in dBm. ComparingFig. 1a and b, it is quite clear that an existing WSN congests channel 11 (default channelin TinyOS 2.1) and also generates interference on the other channels. By comparing Fig. 1a

(a) (b) (c)

Fig. 1 2.4 GHz spectrum usage in a home environment. a Quiet environment. b Co-existing WSN. cMicrowave running

123

A Self-Adaptive Spectrum Management Middleware

with Fig. 1c, we observe that the presence of a microwave also greatly increases the sensedpower level in channel 19, from -94 dBm when the microwave is off to -52 dBm when it ison. When the microwave is on, it also leads to higher noise levels for the other channels. Bycomparing Fig. 1b and c, we find that the interference from the microwave is even strongerthan that arising from a co-existing WSN.

One method to address the problem arising from this crowded spectrum is to introducemore unlicensed frequency band. However, this usually needs approval from governmentagencies (such as the Federal Communications Commission (FCC) in the United States).Another method to address the crowded spectrum is to propose software solutions that canenable multiple nodes to conduct parallel communication at different frequencies (i.e. chan-nels). In the low power wireless communication literature, several approaches have beendeveloped to utilize multiple frequencies for parallel communication, including cognitiveradios [6] and multi-frequency MACs [7,8]. Even though these approaches have proven tobe effective in improving system performance for networks in which each individual nodehas only a half-duplex radio transceiver, they are usually designed for a specific PHY layer orencapsulated within a specific MAC protocol. These solutions are not generic and hence, cannot be used to easily enhance existing single-frequency MAC protocols with multi-frequencycapability, in order to support concurrent communication.

Therefore, the lack of a generic solution to leverage existing MAC protocols motivated usto design SAS: a Self-Adaptive Spectrum Management middleware for wireless sensor net-works, which allows an existing single-frequency MAC protocol to be self-adaptive and takeadvantage of multiple frequencies for parallel communication [9]. The main contributions ofthis work are: (1) We describe SAS as an adaptive middleware that easily enhances existingsingle-frequency MAC protocols with multi-frequency capability for system-wide parallelcommunication. (2) We propose the receiver-initiated scheme (SAS-RI) and the sender-ini-tiated scheme (SAS-SI) supported by SAS for channel switching that is triggered when thecurrent channel used by the application has a high load. (3) We present performance resultsbased on our implementation of SAS in TinyOS 2.1 with nesC on TelosB motes. The per-formance results demonstrate that SAS enhances the performance of single-frequency MACprotocols (e.g. B-MAC [10]).

The rest of this paper is organized as follows: In Sect. 2, we discuss the state of the art.In Sect. 3, we present the design of the SAS Middleware architecture. We then explain twoschemes SAS-RI in Sect. 4 and SAS-SI in Sect. 5 in detail. In Sect. 6, we describe the imple-mentation using TinyOS and TelosB. We evaluate the performance of SAS in Sect. 7. Ourconclusions are drawn in the last section.

2 State of the Art

A number of multi-frequency MAC protocols have been proposed for wireless networks inwhich each node only has a single half-duplex radio transceiver. According to [11], theseMAC protocols can be classified into two broad categories: those that adopt RTS/CTS con-trol packets and those that do not. Some multi-frequency MAC protocols rely on RTS/CTScontrol [12–15], because either their designs are based on IEEE 802.11b [1], or they adoptRTS/CTS control for frequency negotiation [7,16–18]. The work in [11,19] demonstratesthat even though RTS/CTS control exhibits good performance in general wireless ad-hocnetworks, it is not appropriate for WSNs, where the network bandwidth is very limited andthe MAC layer packet size is very small (typically 30 ∼ 50 bytes), compared to a packet sizeof at least 512 bytes in general wireless ad-hoc networks.

123

R. Thompson et al.

Some other multi-frequency MAC protocols are specially designed for wireless sensornetworks applications and do not use RTS/CTS controls [11,20]. These MAC protocolsdemonstrate largely improved system performance due to the use of multiple frequenciesfor parallel communication, but they are not generally designed for enhancing existing sin-gle-channel MAC protocols (e.g. B-MAC [10]). The SAS protocol we propose in this papertargets the same wireless sensor network applications, but without incurring the overheadof RTS/CTS packets. Instead of proposing another special-purpose multi-frequency MACprotocol, we propose SAS, which is a thin layer that can be integrated with existing sin-gle-frequency MAC layer and performs spectrum management on behalf of wireless sensornodes, in order to dynamically share the spectrum for parallel communication.

Some existing works pursue virtualization in the lower layers of the wireless networkstack. [21] and [22] propose a radio-agnostic design on MAC to release the upper layerfrom the tedious details of both MAC and PHY layers. BodyQoS [21] is built upon a virtualMAC that makes itself radio-agnostic, allowing BodyQoS to schedule wireless resourceswithout knowing the implementation details of the underlying MAC protocols. BodyT2 [22]which provides stringent performance assurance in terms of communication throughput andbounded time delay also enjoys the radio-agnostic design. With the virtual layer built uponMAC, the upper layers like the resource management do not need to know about the detailsof the underlying MAC and PHY layers. The virtual layer enables the BodyT2 framework toensure throughput and time delay performance across heterogeneous body sensor networks(BSN). In contrast to these two works, our work aims to provide users with a frequency-agnostic interface that enables the MAC to use multiple frequencies without knowing thephysical details. TinyOS 2.0 [23] extensively uses the virtualization techniques in its systemdesign. For example, ActiveMessageC is a Hardware Independent Layer component thatprovides general, cross-platform abstractions for packet transmission. Moreover, the TimerSubsystem is designed to multiplex a unique hardware timer to a bunch of portable andcomposable high-level services. But all of the techniques used in TinyOS 2.0 are aimed atvirtualizing the hardware. Unlike our work, they do not focus on multiplexing the physicalresources, like frequencies.

3 SAS Design

There are three important challenges to be addressed in designing SAS. First, SAS is a middle-ware positioned between the MAC and PHY layers, as shown in Fig. 2. So clear interface def-initions are needed between MAC and SAS and between SAS and PHY. Second, while neigh-boring nodes in SAS are encouraged to use different frequencies for parallel unicast commu-nication, broadcast needs to be supported from the root. SAS addresses this challenge throughvirtual transceiver design. Third, SAS needs to manage available physical frequencies duringruntime and make the right decisions for switching frequencies, according to current spectrumusage. In the following subsections, we elaborate how SAS addresses these challenges.

SAS is a generic multi-frequency middleware that can be accessed through the interfacesdefined in Fig. 2. The multi-frequency service provided by SAS can be invoked throughthree simple commands: UnicastSend, BroadcastSend and ClearChannelAs-sessment(CCA). UnicastSend is used to send unicast packets, BroadcastSend isused to transmit broadcast packets, andCCA is used for carrier sensing. In response, SAS usesthe SendDone event to inform the MAC layer whether the packet has been sent or dropped(transmission failure). The PacketReceived event is signaled to notify the MAC layerthat a packet has been correctly received.

123


MAC

Unicast SendBroadcast Send

Clear Channel Assessment

SAS

PHY

Send DonePacket Received

Broadcast SendClear Channel Assessment

Send DonePacket ReceivedPrepare for Reception

---Events

---Commands

Fig. 2 SAS middleware architecture

SAS builds its service upon functions provided by the PHY layer. As shown in Fig. 2, SAScalls PHY’s BroadcastSend command to send both unicast and broadcast packets, usingdifferent destination addresses for differentiation. The CCA command provided by PHY isused for carrier sensing. The SendDone and PacketReceived events generated by PHYare used to notify SAS about the result of packet transmission and reception, respectively.The PHY layer also generates the PrepareForReception event, which informs SASthat a valid packet has been detected in the air. Depending on the radio hardware at the PHYlayer, this event can have different implementations.

The CCA command deserves further explanation. In a single-frequency MAC design, CCAmeans “Is the channel busy?”, since the MAC assumes that there is only one physical channel.However, when multiple frequencies are supported, aCCA request implies “Is the channel thatthe receiver is using busy?” Since the MAC layer does not know what channel the receivercurrently uses, it is not possible for the MAC layer to provide a frequency parameter within aCCA request. Instead, the CCA command is slightly modified to take the receiver ID as input,since the MAC layer knows the destination node that the packet is addressed to.

When SAS gets the receiver ID from the CCA request, it looks up its neighbor table tofind out the channel number that the destination node currently uses. The neighbor table ofa receiver contains the information of the channel IDs for transmitting packets to its neigh-boring nodes, which is constructed by notifications from its neighboring nodes accordingto their current spectrum usages. SAS conducts carrier sense on this specific channel andreturns the results to MAC. Thus, through this simple CCA interface reconfiguration, SASis able to enhance single-frequency MAC protocols to take advantage of multiple frequen-cies in a transparent manner, without the need for redesigning MAC protocols to achievemulti-frequency capability.

We will describe the two separate schemes that work together with SAS in the followingtwo sections: SAS receiver-initiated (SAS-RI) scheme and SAS sender-initiated (SAS-SI)scheme. Both of the two schemes have their advantages: SAS-RI scheme is inexpensive andefficient for the receiver to switch channel frequency according to current spectrum usage.SAS-RI uses fewer control packets, hence the control overhead for switching is minimized.SAS-SI is useful for the sender to address jamming and the exposed terminal problem. It isdesigned to quickly switch to a clear channel when sender is being jammed.

4 SAS-RI: SAS Receiver-Initiated Scheme

In this section, we present the receiver-initiated scheme for channel switching. First, webriefly introduce the SAS virtual transceiver, and then explicitly propose the runtime

123

R. Thompson et al.

frequency switching which is triggered when the packet reception ratio measured by a receiverfalls below a certain threshold.

4.1 SAS Virtual Transceiver

As mentioned in Sect. 2, a typical sensor device, like MICAZ and TelosB [24], is usuallyequipped with a single half-duplex radio transceiver, to reduce product cost, form factor, andenergy consumption. This limited radio transceiver needs to be enhanced by software, tosupport multi-frequency capability. The SAS virtual transceiver proposed in this subsectionis designed to meet this requirement.

In the multi-frequency context, we assign neighboring nodes different frequencies for uni-cast packet reception, and the same default channel for broadcast reception. This design phi-losophy maximizes parallel unicast communication and at the same time seamlessly supportsbroadcast from the root. With the help of SAS, the limited radio transceiver is transformedto a virtual transceiver that is able to snoop on three frequencies: fBC , fU N I , and fC AN ,simultaneously. fBC denotes the default frequency chosen for broadcast, and fU N I indicatesthe frequency for unicast reception. This unicast frequency is selected from the currently leastloaded frequencies and it may vary from time to time and from node to node, according to anode’s current spectrum usage within its local geographic area. When a node is first assigneda unicast frequency or when it switches frequency, it notifies its neighbors with the updatedfU N I value through a broadcast (reliability issues [25] in broadcast can be incorporated infuture). In addition to the broadcast and unicast frequencies, a candidate frequency, fC AN ,is guessed at runtime, in order to replace the current unicast frequency when it is congested.Details about how to pick the fC AN frequency is explained later in Sect. 4.2.

Figure 3 presents the detailed design of a SAS virtual transceiver. As shown in Fig. 3a, apacket normally starts with the preamble bytes, then follows with the Start-of-Frame Delim-iter (SFD) field, the packet length field, and then the data bytes. Also, an optional CRC fieldis usually added at the end of the data bytes.

In a single-frequency context, when a node is deployed and turned on, it enters into theidle listening state. However, in SAS’s multi-frequency context, the node enters the togglesnooping state, as shown in Fig. 3b. We can see from Fig. 3b, the transceiver alternates to firstlisten to the unicast frequency fU N I , then the broadcast frequency fBC , and then the candi-date frequency fC AN (with optional sleep periods for possible duty cycling extensions in thefuture). After listening to each frequency, the transceiver goes into sleep state to save power.

Packet Format: Preamble LengthSFD

Transmitter: Noti fication LengthSFDPreamble

(a)

fUNIReceiver: …...

TTS

(b)

(c)

Mac Protocol Data Unit

Mac Protocol Data Unit

Sleep fBC Sleep fCAN Sleep

TSlp

…

Fig. 3 SAS virtual transceiver. a Original packet format. b Toggle snooping. c SAS transmission

123


TT S denotes the time that a node stays on any of the three frequencies and TSlp denotes thetime that a node stays in the sleep state. Whenever the transceiver stays in frequency fU N I orfBC , and also detects a radio signal in the air, it stops frequency toggling to prepare for datareception. As shown in Fig. 3c, each data packet in SAS is preceded by notification bytes,which inform a receiver in the toggling state to stop frequency toggling and instead, switchto the data reception state. The toggle snooping resumes when the packet reception ends.

The toggle snooping performed by the receiver has the same implementation in differentradio hardware. However, the implementation of the notification bytes in the SAS transmis-sion depends on the hardware platform. Since currently many wireless sensor devices, likeMicaZ, Telos and IMote2, use the CC2420 radio, we will present the details of the SASvirtual transceiver that we implemented over the CC2420 radio in TelosB motes in Sect. 6.

4.2 Runtime Frequency Switching

We have explained the communication protocol when the SAS virtual transceiver operateson both broadcast and unicast frequencies. We now explain how SAS switches its unicastfrequency fU N I dynamically, according to the runtime spectrum usage. By switching unicastfrequencies, it is possible to take advantage of all available physical frequencies, in order tobalance the traffic load in both spatial and temporal dimensions.

In order to switch frequencies, SAS needs to answer two questions at runtime: 1)Is thecurrent frequency (i.e. channel) congested? and 2)What is the best frequency to switch towhen the current one is congested? To answer these two questions, SAS carefully managesits available resources, which are the physical frequencies. The state of each frequency ineach node varies according to the state machine depicted in Fig. 4.

A node uses one of the following three states to denote the usage status of each chan-nel: InUse, InPool and Candidate. The frequency that is chosen for current unicastreception is in the InUse state. The currently guessed candidate frequency is assigned theCandidate state. All the other frequencies are placed in the InPool state. The state tran-sition is triggered by one of the following four actions: warm up, frequency assignment,frequency guess, and frequency switch.

InUse Candidate

InPoolWarm Up

Switch

Assign. (Hit)

Switch (Hit) or

Guess (Hit)

Switch

Fig. 4 The SAS state machine

123

R. Thompson et al.

4.2.1 WarmUp and Frequency Assignment

When a sensor network is newly deployed and started, it is important to detect what frequen-cies are currently used and which of them suffer interference from existing electrical andelectronic devices. An initial warmup phase serves this purpose, during which the load oneach frequency is measured and recorded.

During warmup, each node scans all physical frequencies in multiple rounds. In eachround, the node stays on each frequency for a short time that is long enough for sampling thechannel status. The status is a binary result: 0 for idle and 1 for busy. This value is assignedto φ̄, which is used to generate a moving average value φ (see Table 1) with a decay of α:

φn+1 = α × φn + (1 − α)× φ̄ (1)

After collecting the channel load information, each node knows the current spectrum usageof existing networks and devices. Each node avoids choosing the congested frequenciesby checking corresponding φ values. Also, to avoid internal congestion within the newlydeployed network, frequency assignment is needed after the short warm-up. During frequencyassignment, each node backs off for a random time period before it chooses its frequency.During the backoff period, each node records the frequencies it overhears. When its backofftimer fires, a node chooses one of the least loaded frequencies for unicast reception.

4.2.2 Candidate Frequency Guess

In SAS, each node needs to be prepared for frequency switches when congestion occurs. Soit is helpful for each node to know the traffic load of other physical frequencies, even thoughthey are currently not in use. Considering scalability, it is energy and bandwidth intensivefor each node to keep track of the loads of all frequencies all the time. However, it is notnecessary to continuously carrier sense all the frequencies, since each node only needs onecandidate frequency to switch to when congested.

An energy-efficient and scalable design is to let each node guess one frequency that mayhave the highest possibility of being the most lightly loaded frequency in the near future, andplace that frequency in the Candidate state. A Candidate frequency may be discarded,when it is found to be likely overloaded and hence no longer promising. In that case, thefrequency is placed in the InPool state again.

Table 1 Table entry maintained for each physical frequency

Frequency state At any time, a frequency should be in one of the three states: InPool, InUse andCandidate

ω Frequency’s credit history: how many times a frequency/channel has beenchosen for unicast packet reception

φ Frequency’s load: it is calculated as a moving average with decay α. Themoving average computation gets re-initialized each time a frequency entersthe Candidate state again

ϕ Sharing density: the number of neighboring nodes that are using currentfrequency

ξ Composite metric: it reflects that how competitive a frequency is, and is usedfor frequency comparison. It is a balanced reflection of a frequency’s mostrecently measured load φ, the frequency’s credit history ω and its currentusage by neighboring nodes ϕ

123


To assist in deciding when and how to guess a candidate frequency, we introduce the ξparameter. As shown in Table 1, ξ is a composite metric, which characterizes the frequency’srecently measured load (φ), the frequency’s credit history (ω), and the frequency’s sharingdensity (ϕ) that is the number of neighboring nodes which are currently using it. The fre-quency load φ is computed as in Eq. (1). To compute a frequency’s credit history, SAS usesthe parameter ω to record how many times a frequency has been used, which reflects howmany times this frequency has been discarded and replaced by a better one. The greater theω value, the higher the probability that the frequency will be congested and discarded againin the near future, and hence, the less promising the frequency is. This figure is normalizedby the total history of all channels to give a figure between zero and one that represents thechannels proportion of all frequency shifts. Also, each node should avoid competing for thesame frequency with its neighbors. When the number of available physical frequencies is noless than the node density, SAS should give neighboring nodes different frequencies to avoidcongestion. When the number of available physical frequencies is very limited comparedto the node density, each node in SAS needs to give higher priority to frequencies that areshared among fewer neighbors. Hence, the ϕ parameter is introduced to indicate the numberof neighbors that share a frequency. A channel ϕ is normalized by the total number of neigh-bor nodes, in order to produce a value between zero and one. This normalization also allowsgreater emphasis to be placed on ϕ when node density is low, and less emphasis when nodedensity is high.

Taking these three into consideration, parameter ξ can be calculated as in Equation (2),where β and γ are coefficients:

ξ = β × ω + γ × φ + (1 − β − γ )× ϕ (2)

In Eq. (2), φ, ω, ϕ are all variables in the range of [0,1] and they have the same indicatorfunction for a certain frequency, i.e., the bigger the values of these variables are, the worsethe corresponding frequency is. Moreover, we add two coefficients (β and γ ) whose valuesare between 0 and 0.5. They are used to encode the frequency preference of the MAC layer.For example, if the MAC layer prefers the frequency that hasn’t been changed so frequently,it should set β to a higher value s.t., the frequency with bad credit history (high ω value) willnot become the candidate frequency. On the other hand, if the MAC layer prefers to not sufferheavy traffic congestion, it should set the value of γ to be high. Thus, the frequencies whosetraffic loads are heavy will not be chosen as candidates. Following the same principle, if theMAC layer needs the frequency to be shared by fewer neighbors, it should set the values ofboth β and γ to be small.

The first frequency guess happens at the end of warm-up, when the initial Candidatefrequency needs to be decided. After that, frequency guess is triggered when the Candi-date frequency’s ξ value exceeds ξT hr . If the frequency guessing causes the Candidate fre-quency to enter into the InPool state again, the Candidate frequency is replaced with thefrequency in the InPool state (see Fig. 4) that has the smallest ξ value.

4.2.3 Frequency Switch

As illustrated in Fig. 4, when a frequency switch happens, the current unicast frequency,fU N I , switches its state from InUse to InPool. In addition, the Candidate frequencyreplaces the InUse frequency, and a new Candidate frequency is picked out from thepool. Since fU N I is only used for unicast reception, the frequency switch is triggered whenthe monitored packet loss ratio of the application is above a threshold.

123

R. Thompson et al.

Typically, there are two ways for a receiver to obtain the packet loss ratio. One solution isto use a packet sequence number. By tracking the sequence numbers and calculating the gaps,a receiver is able to compute the packet loss ratio. The second scheme is to use transmitter-receiver handshakes, such as RTS-CTS-DATA-ACK in IEEE 802.11b [1]. However, both ofthem introduce extra overhead and neither of them takes advantage of the SAS design. Inthe first scheme, SAS is required to get access to and understand the upper layer’s sequencenumbers, which violates SAS’s design goal of being a generic multi-frequency middlewarethat does not depend on support from the MAC protocol layered above it. The second schemeintroduces significant communication overhead.

Hence, we propose a novel scheme to implicitly compute the packet loss ratio in SAS,by taking advantage of the toggle snooping design described in Sect. 4.1. In SAS, togglesnooping is the default behavior of each receiver, which only gets interrupted when a validdata signal is detected in the air. If a packet is correctly received after an interruption, thereceiver knows that the communication has succeeded, otherwise a communication failure isdetected. This success/failure binary status is obtained for free, and is recorded in the packetloss variable, ψ̄ , and a moving average value ψ is computed with decay η as follows:

ψn+1 = η × ψn + (1 − η)× ψ̄ (3)

By comparing the ψ value with a threshold ψT hr , the frequency switch is automaticallytriggered, when ψ ≥ ψT hr .

5 SAS-SI: SAS Sender-Initiated Scheme

In this section, we explicitly present the sender-initiated scheme for switching channels.Sender-Initiated Scheme involves two major parts: sender’s algorithm and receiver’s algo-rithms. This scheme is designed to be triggered when the Received Signal Strength (RSS)value of the sender side remains high for a certain period of time, which indicates the channelis in use by current traffic.

5.1 Sender’s Algorithm

In CSMA-based MAC protocols, each node is required to use CCA to check the signalstrength on the channel before transmission. CCA measures the RSS value on the channel.If CCA detects that the channel’s RSS value is above the CCA threshold, it assumes that thechannel is in use by genuine traffic and will postpone packet transmission. In CCA movingaverage based detection, the channel status is a binary result: 0 for idle and 1 for busy. If wedenote the current channel status by ϒ̄ (0 or 1), the moving average value ϒ with a decay ofβ is as follows:

ϒn+1 = (1 − β)× ϒn + β × ϒ̄ (4)

The sender’s algorithm is shown in Algorithm 1. When a sender detects that thereceiver’s current channel is experiencing interference, the sender unicasts an interfer-ence-notification packet on the broadcast channel to inform the receiver that its linkis experiencing interference. Then, the sender waits for the response from the receiver.

123


Algorithm 1: Sender’s algorithm

1 if receiver’s channel is detected as interfered then2 unicast interference-notification packet on broadcast channel;3 if new channel is assigned then4 continLue sending packets on new assigned channel;5 else if continue-sending packet is received then6 continue sending packets on original channel while ignoring CCA for ε time;7 else8 continue sending packets on original channel;9 end

10 else11 send packets;12 end

5.2 Receiver’s Algorithm

The receiver’s algorithm is shown in Algorithm 2. When a receiver gets the interf-erence-notification packet, it must then decide whether it is appropriate to switchchannels. Since there may be only one of several senders that detected the interference, thereceiver should not switch channels at the expense of the other senders. The receiver comparesthe current channel’s composite metric ξ with the candidate channel’s composite metric ξ .If the candidate’s is lower, switching channels will be beneficial for all senders. The receiverthen informs all of its senders about the switch to the candidate channel. On the other hand, ifthe candidate channel’s composite metric ξ is higher, the channel may be worse for the send-ers that are not being interfered with. In this case, the receiver decides not to switch channels.It then searches for a new candidate channel and sends a continue-sending packet backto the sender that sent the interference-notification packet. If the original senderreceives a continue-sending packet from the receiver, it will then ignore CCA whensending packets to that receiver for a certain amount of time ε, which is configurable. After εamount of time, the sender returns to normal operation and resets the CCA moving average.

Algorithm 2: Receiver’s algorithm

1 if interference-notification packet is received then2 if ξcurrent ≤ ξcandidate then3 switch channels to candidate;4 else5 unicast a continue_sending packet on broadcast channel;6 find new candidate channel;7 end8 end

The detection on the sender side has several benefits over using PRR on the receiving side,especially for cases of jamming and the exposed terminal problem. In the exposed terminalproblem, two senders are transmitting packets to different receivers, and each receiver isonly in the range of one sender. Thus, although both senders can transmit at the same timewithout causing interference, they will not, because they will detect each other’s transmissionwhen doing a CCA. No packets are lost, so this kind of congestion will not be detected byPRR drops at the receiver. On the other hand, the sender will be able to detect it using CCA

123

R. Thompson et al.

moving average based detection. If the sender is being jammed, it will send out a few tono packets, because its CCA will constantly return a busy status. This will cause the PRRto drop slowly on the receiving side, but the CCA moving average will rise quickly on thesender side, allowing quicker detection of jamming.

If the sender is being jammed, when it begins to ignore CCA most of its packets will startto be dropped. This causes the receiver to detect the jamming more quickly, causing it tochange channels. The sender’s and receiver’s algorithms are illustrated in Algorithm 1 andAlgorithm 2, respectively.

Sender-initiated scheme allows the sender-receiver system to respond to the interferenceon the sender side more quickly. As long as sender detects the interference on its channel, itnotifies the receivers of the interference event on the same channel. While the receiver maytake time to let the decay average reflect the degradation in the channel communication, thesender-initiated notification serves as an early warning to the receiver. The receiver can thendecide whether or not switch the current channel.

6 Implementation

We implemented SAS integrated with B-MAC in TinyOS 2.1 with nesC on TelosB motes.The performance results demonstrate that SAS is capable of enhancing the performance ofsingle-frequency MAC protocols (e.g. B-MAC [10]), and SAS-SI further enhances perfor-mance by effectively dealing with jamming. The experiments were conducted in a campusbuilding, where the primary source of interference was the wireless network in the building.As we mentioned in Sect. 4.1, the data packets themselves are used for notification. So theduration of the continuous CCA check interval should be longer than the interval betweenthe transmission of successive notification data packets. This check interval was set to be themaximum delivery delay in the network. During this interval, the CCA check was performed400 times, which is also the default value in the B-MAC code. In order to deal with heavytraffic, when a node receives a data packet on a channel, the radio continues to stay on thatchannel for a certain short period. We set this period to 100 ms, which is the default valueused in the B-MAC code. We set the notification time (Tsend) to 20 ms for the transmitterand let the transmitter send data packets as fast as possible.

The general SAS virtual transceiver design is given in Fig. 3, which consists of togglesnooping and SAS transmission. The toggle snooping happens at the receiver side, and hasthe same implementation in different radio hardware. However, the “notification” in SAStransmission needs to be implemented in accordance with the hardware platform. Since thecurrently dominant wireless sensor devices, like MicaZ, Telos and IMote2, favor CC2420radio, we present the SAS virtual transceiver implementation in CC2420 in Fig. 5.

Transmitter:

Receiver: SleepfBC

TTS TSlp

fUNI Sleep fCAN fBCSleep

Notification Preamble LengthSFD Mac Protocol Data Unit

TSend

…...

Fig. 5 SAS virtual transceiver implementation in CC2420 radio

123


We present the details of the SAS virtual transceiver that we implemented over the CC2420radio in TelosB motes. As shown in Fig. 5, for the SAS virtual radio transceiver to operatecorrectly, the time to send the notification (Tsend)must be greater than 3TT S + 2TSlp , whereTT S and TSlp are as defined in Sect. 4.1. When this condition is violated, the transmitter’snotification time is not long enough to ensure that the receiver is able to pick up a validpacket signal, and hence, can not make sure that the sending packet is received even withoutinterference.

CC2420 is a packet-level radio hardware. it does not provide software designers the abil-ity to either configure a long preamble or read individual preamble bytes when a packetis in the air. Instead, the radio hardware is in charge of adding and removing preamblebytes automatically. So, we can not use a long preamble to serve as the “notification” as ispossible in a byte-level radio hardware (like CC1000 in Mica2). Hence, in our implementa-tion, we use the data packet itself (multiple duplicates) as the notification, as illustrated inFig. 5.

7 Performance Evaluation

Based on the implementation in Sect. 6, we compare the performance of SAS integratedwith B-MAC in TinyOS 2.1 with that of the regular B-MAC protocol on TelosB motes. In

(a) (b)

(c) (d)

Fig. 6 Performance of SAS. a Packet reception ratio:BMAC w.o. SAS, BMAC w. SAS-RI, BMAC w. SASSI.b System throughput:BMAC w.o. SAS, BMAC w. SAS-RI, BMAC w. SAS-SI. c Average packet delay:BMACw.o. SAS, BMAC w. SAS-RI, BMAC w. SASSI. d Energy consumption:BMAC w.o. SAS, BMAC w. SAS-RI,BMAC w. SASSI

123

R. Thompson et al.

the following subsections, we evaluate the SAS performances with conditions of varied dataflows and interference in terms of packet reception ratio, system throughput, average packetdelay, and energy consumption, respectively.

7.1 Evaluation with Varied Data Flows

In each of the experiments, we varied the number of data flows from 1 to 3 and each sendertransmitted 10,000 data packets to a different receiver, to emulate an environmental monitor-ing application. When there was more than one flow, the receivers adaptively chose a differentfrequency during the warmup stage, when B-MAC with SAS was used. Only channel 11, 18,and 25 were allowed to be chosen and channel 26 was used for broadcast.

Figure 6a shows the packet reception ratio (PRR) achieved by B-MAC with and withoutSAS, as the number of contending flows in the network increases. The PRR is calculated asthe ratio of the total number of data packets successfully delivered to the total number of datapackets transmitted. The PRR when either SAS-RI or SAS-SI is used remains almost 100%,even when the number of flows increases. On the other hand, B-MAC without SAS deliversalmost 100% of its given load when there is only one sender-receiver pair. However, thereception ratio drops to 73% when there are 2 simultaneous data flows, and further drops to61% when there are 3 data flows. This degradation may either be due to collision or becausethe contention in the network may result in the transmitter queues being full, forcing someof the transmitters to drop some of the packets from their queues.

(a)

(b) (c)

Fig. 7 Packet reception ratio in the presence of jamming. a B-MAC w.o. SAS. b B-MAC w. SAS-RI. cB-MAC w. SAS-SI

123


(a)

(b) (c)

Fig. 8 System throughput in the presence of jamming. a B-MAC w.o. SAS. b B-MAC w. SAS-RI. c B-MACw. SAS-SI

Figure 6b shows the measured system throughput. The throughput measures the perfor-mance gain and is calculated as the total amount of useful data successfully delivered inthe network per unit time. The packet size we used is 54 bytes (data payload plus MACheader). With SAS-RI and SAS-SI, the total network throughput achieved when there are3 contending flows, is almost 3 times that achieved when there is a single flow. The reasonis that the multi-frequency management in SAS enables neighboring nodes to adaptivelychoose different physical frequencies. As a result, when the number of flows in the networkincreases, the MAC layer above SAS does not suffer as much radio interference as the reg-ular B-MAC and more nodes are able to simultaneously transmit without collisions. In thecase of B-MAC without SAS, the total throughput also increases when the number of flowsincreases. However, due to congested channels, each node has to backoff more number oftimes, in order to transmit one packet.

Figure 6c shows the average packet delay as the number of contending flows in the net-works increases. The packet delay measures the one-way latency experienced by a data packetfrom the time it is transmitted by the MAC layer on the transmitter side to the time at whichit is received by the MAC layer on the receiver side. The average delay for SAS remainsaround 22ms, even as the number of flows increases. This is higher than that for B-MACwithout SAS, because of the overhead of channel switching. However, the difference is notlarge enough to affect the throughput significantly.

The energy consumed per byte of successfully delivered data is shown in Fig. 6d. This isthe sum of the energy consumed for sending a packet and for performing the CCA check.The power level used for transmissions is 0 dBm. With SAS, the energy consumed remains

123

R. Thompson et al.

(a)

(b) (c)

Fig. 9 Average packet delay in the presence of jamming. a B-MAC w.o. SAS. b B-MAC w. SAS. c B-MACw. SAS-RS

almost constant, as the number of flows increases from 1 to 3, whereas in the case of B-MACwithout SAS, the energy consumed increases with the number of flows. The reason is thatwhen the traffic is heavy, the packet loss is higher in the case of B-MAC without SAS (seeFig. 6a) and hence, more energy is spent in retransmissions.

7.2 Evaluation with Interference

The second group of evaluations involved running 3 streams for 5 min. After 1 min a jam-mer starts sending packets every 15 ms on channel 18 for a minute. For the final minute anearby laptop runs using Wi-Fi. Motes 1, 3, and 5 were receivers while motes 2, 4, and 6were senders. In each experiment, mote 1 started on channel 11, mote 3 on channel 18, andmote 5 on channel 25. Figure 7 shows the overall PRR achieved. In all three charts, a cleardrop can be seen at the 60 s mark when the jammer starts. B-MAC without SAS in Fig. 7adrops quickly and levels back out once the jammer stops sending. B-MAC with SAS-RI (inFig. 7b), on the other hand, only mote 3 is affected by the jammer while the other motesremain around 1. Around the 90s mark mote 3 switched channels to channel 25 and the PRRleveled off as it shared a channel with mote 5. Once the jammer stops, mote 3 switched backto channel 8 and the PRR began to rise. Even at its lowest it never dropped as low as B-MACwithout SAS, never dropping below 93%. B-MAC with SAS-SI performs even better byswitching channels to avoid the jammer earlier, and never dropping below 98%. Mote 4 sentan interference-notification packet around the 70 s mark with mote 3 switchingto channel 11 immediately.

123


(a)

(b) (c)

Fig. 10 Energy consumption in the presence of jamming. a B-MAC w.o. SAS. b B-MAC w. SAS-RI. cB-MAC w. SAS-SI

Figures 8 and 9 show the average throughput and packet delivery delay in the presenceof jamming. Once again, B-MAC without SAS has lower packet delay, but not by an amountsignificant enough to affect throughput. Overall, the average delay seems relatively unaf-fected by the jammer and the laptop has no effect. The throughput achieved by B-MAC withSAS-RI and SAS-SI is higher than the throughput achieved by B-MAC without SAS. Mote3 has a high average throughput, because it was able to switch channels and adapt faster byusing B-MAC with SAS-SI, when there was jamming.

The energy consumption per byte of successfully delivered data in the presence of jam-ming is shown in Fig. 10. Once again B-MAC with SAS-SI performs the best, consumingthe least energy per delivered byte, while B-MAC without SAS performs the worst. Theseexperiments clearly show that B-MAC with SAS-RI outperforms B-MAC without SAS, andthat B-MAC with SAS-SI provides a significant improvement when there is jamming.

8 Conclusions

SAS is an adaptive spectrum management middleware for wireless sensor networks, whichprovides a way to address the problem of crowded spectrum. SAS is designed to enhancesingle-frequency MAC protocols with multi-frequency capability, so that an existing MACprotocol like B-MAC, can switch to the least congested physical frequency at runtime. Thisadaptive channel switching is useful, in order to address the performance degradation result-ing from interference and time-varying traffic patterns. SAS supports both a sender-initiatedand a receiver-initiated scheme to trigger this switching, when the current channel is no

123

R. Thompson et al.

longer beneficial. Our performance results, based on an implementation on a TelosB testbed,demonstrate that SAS improves the performance of single-frequency B-MAC, and resultsin higher packet reception ratio and system throughput, with lower energy use. Evaluationsinvolving jammers and other commercial interference shows that the sender-initiated schemein SAS is effective in maintaining good performance even when there is jamming.

References

1. IEEE (1999). Wireless LAN medium access control (MAC) and physical layer (PHY) specification.ANSI/IEEE Std. 802.11.

2. IEEE (2002). Wireless medium access control (MAC) and physical layer (PHY) specifications forwireless personal area networks (WPANs). IEEE Std. 802.15.1.

3. IEEE (2003). Wireless medium access control (MAC) and physical layer (PHY) specifications forlow-rate wireless personal area networks (LR-WPANs). IEEE Std. 802.15.4.

4. Zhou, G., Stankovic, J. A., & Son, S. F. (2006). Crowded spectrum in wireless sensor networks. InIEEE EmNets.

5. Selavo, L., Zhou, G., & Stankovic, J. A. (2006). See mote: In-site visualization and logging devicefor wireless sensor networks. In IEEE BASENETS.

6. Wang, F., Krunz, M., & Cui, S. (2007). Spectrum sharing in cognitive radio networks. Tech. Rep.,University of Arizona.

7. So, J., & Vaidya, N. (2004). Multi-channel MAC for Ad-Hoc networks: handling multi-channel hiddenterminal using a single transceiver. In ACM MobiHoc.

8. Mo, J., So, H., & Walrand, J. (2005). Comparison of multi-channel MAC protocols. In Symposiumon modeling, analysis, and simulation of wireless and mobile systems.

9. Zhou, G., Lei, L., Krishnamurthy, S., Keally, M., & Rhen, Z. SAS: Self-adaptive spectrum managementfor wireless sensor networks. In Proceedings of international conference on computer communicationsand networks (ICCCN).

10. Polastre, J., Hill, J., & Culler, D. (2004). Versatile low power medium access for wireless sensornetworks. In ACM SenSys.

11. Zhou, G., Huang, C., Yan, T., He, T., Stankovic, J. A., & Abdelzaher, T. F. (2006). MMSN:Multi-frequency media access control for wireless sensor networks. In IEEE INFOCOM.

12. Bahl, P., Chancre, R., & Dungeon, J.: SSCH: Slotted seeded channel hopping for capacity improvementin IEEE 802.11 Ad-Hoc wireless networks. In ACM MobiCom.

13. Raniwala, A., & Chiueh, T. (2005). Architecture and algorithm for an IEEE 802.11-based multi-channelwireless mesh network. In IEEE INFOCOM.

14. Adya, A., Bahl, P., Padhye, J., Wolman, A., & Zhou, L. (2004). A multi-radio unification protocolfor IEEE 802.11 wireless networks. In BroadNets.

15. Li, J., Haas, Z. J., Sheng, M., & Chen, Y. (2003). Performance evaluation of modified IEEE 802.11MAC for multi-channel multi-hop Ad Hoc network. In IEEE AINA 2003.

16. Jain, N., & Das, S. R. (2001). A multichannel CSMA MAC Protocol with receiver-based channelselection for multihop wireless networks. In IEEE IC3N.

17. Tzamaloukas, A., & Garcia-Luna-Aceves, J. J. (2001). A receiver-initiated collision-avoidance protocolfor multi-channel networks. In IEEE INFOCOM.

18. Tang, Z., & Garcia-Luna-Aceves, J. J. (1999). Hop-reservation multiple access (HRMA) for Ad-Hocnetworks. In IEEE INFOCOM.

19. Zhou, G., Wu, Y., Yan, T., He, T., Huang, C., Stankovic, J. A., & Abdelzaher, T. F. (2010). Amulti-frequency MAC specially designed for wireless sensor network applications. In ACM TECS.

20. Wu, Y., Stankovic, J., He, T., Lu, J., & Lin, S. (2008). Realistic and efficient multi-channelcommunications in wireless sensor networks. In IEEE INFOCOM.

21. Zhou, G., Lu, J., Wan, C.-Y., Yarvis, M. D., & Stankovic, J. A. (2008). Bodyqos: Adaptive andradio-agnostic qos for body sensor networks. In INFOCOM.

22. Ren, Z., Zhou, G., Pyles, A., Keally, M., Mao, W., & Wang, H. (2011). Bodyt2: Throughput andtime delay performance assurance for heterogeneous bsns. In INFOCOM.

23. Levis, P., Gay, D., Vlado, H., Hauer, J. H., Greenstein, B., Turon, M., et al. (2005). TechnischeUniversitt Berlin, Crossbow Inc, and Arched Rock Corpration. T2: A second generation os forembedded sensor networks, Tech. Rep.

123


24. Polastre, J., Szewczyk, R., & Culler, D. (2005). Telos: Enabling ultra-low power wireless research.In ACM/IEEE IPSN/SPOTS.

25. Chang, J., & Maxemchuk, N. F. (1984). Reliable broadcast protocols. In ACM Transactions oncomputer systems.

Author Biographies

Robert Thompson got his Bachelor and Master Degrees from theComputer Science Department at the College of William and Mary. Heis now a software engineer in Fairfax, VA.

Gang Zhou is an Assistant Professor in the Computer Science Depart-ment at the College of William and Mary. He received his Ph.D. degreefrom the University of Virginia in2007. His research interest lies in thearea of wireless communication and networking, sensor networks andubiquitous computing, and cyber-physical systems. He has publishedmore than 40 peer reviewed papers in prestigious conferences and jour-nals. According to Google Scholar, there have been more than 2000citations of his papers, among which the MobiSys’04 paper has beencited more than 500+ times. He received an award for his outstandingservice to the IEEE Instrumentation and Measurement Society in 2008.He is also a recipient of the Best Paper Award of IEEE ICNP 2010.

Lei Lu received his B.S. degree in Computer Science from NanjingUniversity, China, in 2005, and his M.E. degree in Systems Engineer-ing from Nanjing University, in 2008. He is currently a Ph.D. candidatein the Department of Computer Science, College of William and Mary,Williamsburg, VA. His research interests include middleware for sim-plifying data center management, performance analysis of multi-tieredsystems, resource allocation policies and wireless sensor networks.

123

R. Thompson et al.

Sudha Krishnamurthy is a research staff member at United Technol-ogies Research Center. She got her Ph.D. degree in Computer Sciencefrom the University of Illinois, Urbana-Champaign. Her research inter-ests are in wireless and sensor networks, distributed systems, and dataanalytics.

Hover Dong is currently a doctor candidate of Computer Science at theCollege of William and Mary, conducting research on graphics, espe-cially appearance acquisition. He got his Master Degree in ComputerScience from the Texas A and M University-Corpus Christi in 2009.During his master study, his research is focused on wireless sensor net-works, especially underwater sensor networks.

Xin Qi received the B.Sc. degrees in computer science from NanjingUniversity, China, in 2007 and the M.E. Degree from INRIA-LIAMA,Chinese Academy of Science, in 2010, respectively. He has been work-ing in declarative networking. He is currently pursuing Ph.D. degreein the Department of Computer Science, The College of William andMary. His research interests are mainly in wireless networking and per-vasive computing.

123


Yantao Li is a Ph.D. candidate in College of Computer Science atChongqing University, China. Currently, he is a visiting scholar sup-ported by China Scholarship Council working with Professor GangZhou at Department of Computer Science in College of William andMary, USA. His research area includes wireless communication andhash function construction.

Matthew Keally is a Ph.D. candidate in Department of ComputerScience at College of William and Mary. His research is with wire-less sensor networks and embedded systems, specifically with routing,machine learning, and event detection.

Zhen Ren received the B.S. degrees in Computer Science from Nan-jing University, China, in 2003. She is currently pursuing Ph.D. degreein the Department of Computer Science, The College of William andMary. Her research interests are mainly in wireless communication,network Quality of Service, and pervasive computing.

123

A Self-Adaptive Spectrum Management Middleware for

Documents