A CONTENTION-BASED SERVICE SCHEDULING PROTOCOL FOR MULTINODE MULTI-SERVER WIRELESS SENSOR NETWORKS Dawood Al-Abri and Janise McNair Department of Electrical and Computer Engineering University of Florida, Gainesville, FL 32611 Email:
[email protected],
[email protected] ABSTRACT Many protocols designed for wireless sensor networks require the existence of special purpose nodes distributed throughout the network to perform such services as aggregation, access coordination, etc. To avoid inter-node interference, it is desirable to schedule beforehand the nodes that will interact with the servers in a given time interval. Previous solutions either assume a fully connected network with a single server or clustered architecture with one server per cluster and no intercluster interference. In this paper, we propose a contention-based protocol for scheduling service requests by nodes in environments with multiple servers without any assumption about clustering. We describe two versions of our protocol: one based on random backoff and the other on truncated binary exponential backoff. Results show that a high number of requests can be fulfilled within a reasonable response delay and its performance is better than TDMA-like clustering-based schemes when the interference between clusters is taken into account. I. INTRODUCTION Wireless sensor networks consist of devices that are highly constrained in their communication, computation, and power capabilities. The highly constrained nature of a WSN has resulted in many interesting scheduling problems that aim to improve the overall performance of the networks. For example, there is an extensive work on devising algorithms to schedule the sleep/wakeup intervals of nodes and link activation to conserve energy and hence extend the lifetime of the network. In this paper, we are interested in networks that employ special purpose nodes, refer to hereafter as servers, to perform special tasks such as data aggregation, access coordination. The other nodes in the network depend on these servers to function properly. Our focus in this paper is on scheduling the service in the sense that during the service phase the medium is reserved only for the node and the server that need to interact with each other (slot assignment). The problem that we are considering here
978-1-4244-2677-5/08/$25.00 ©2008 IEEE
overlaps with the reservation-based MAC protocols [1-2]. In general, most reservation-based protocols have two phases: reservation phase, and transmission phase. In the reservation phase, nodes usually contend through some form of random access (e.g. CSMA) to reserve transmission slot(s). A coordinator (e.g. cluster head) usually decides slots assignment to the nodes that made reservation request successfully. In the transmission phase, each node transmits during its assigned slot to its intended receiver. Our work differs from these schemes in that we are considering several servers and we are not assuming that the network is fully connected or that there is no interference between the server-based clusters. Moreover, in our protocol, we do not assume any frame structure as most reservation-based MAC protocols. We also note here that the problem of contention resolution in multiple-node multiple-server environment has been studied before (e.g. [3]). However, the problem setup assumes that each node has a set of messages with each destined to a specific server where the access to each server is done through a separate contention-based channel. This is different from our problem where the message is broadcast on a single channel shared by all servers and all nodes. In addition, in our case, any server of those that receive the broadcast can respond to the request. The rest of this paper is organized as follows. In Section II, we present the network model, followed by the protocol description in Section III. Our numerical results are presented in Section IV. Finally, the paper is concluded in Section V. II. THE NETWORK MODEL In this paper, we consider wireless networks that can be regarded from functional point of view as consisting of two components: servers and nodes. Servers are special nodes that perform a task crucial to the network operation (e.g. data aggregation). The nodes are the entities that are interested in receiving the service provided by the servers. Upon receiving a service request from a node, the servers determine an appropriate time that can be used to fulfilled the request and then broadcast that schedule. The service is
1 of 7
carried out during the assigned time. We assume that time is slotted and that the nodes and servers are time synchronized. In addition, we assume a single communication channel and half-duplex operation. From the point view of an entity (node or server), a timeslot can be either busy or idle. A busy timeslot is one that is reserved or one during which a transmission occurs. An idle timeslot is one that is not busy. A reserved timeslot is one that a server has designated to be used for fulfilling a particular node request. The Perceived Medium Status (PMS) of an entity is its view of the status of each timeslots (busy or idle) in the time line. Obviously, whenever the entity detects a transmission, it knows that that timeslot is busy. In addition, through extracting the reserved timeslots information from the broadcasted schedules, it can update the status of future timeslots. However, it possible that an entity perceived a timeslot as an idle when in fact that timeslot is reserved. This can happen, for example, if the node is hidden from the server that makes the schedule broadcast. Hence, the PMS provides only a partial view of the actual status of the medium. We refer to the actual status of the medium as the Global Medium Status (GMS). We define the direct link connectivity ( DLC ) as the probability that a link connecting two entities is present. For example, DLC = 1 represents the case where every entity is connected to every other entity (fully connected network) while DLC = 0 represents a network consisting of isolated entities.
copy of the received broadcasted schedule to help in spreading the scheduling information to the nodes/servers that are hidden from the server that originally made the schedule, and hence reduce the probability of collision. Following a successful acknowledgement, the node and the server enter the service phase which is carried in accordance with service protocol. Observe here that the particularities of the service phase are not of concern to us in this work and will depend on the service being sought. For example, the service phase may consist of several challenge/response packet exchanges between the server and the node to verify the location of the node. The content of these exchanged packets and how the information in these packets is utilized to verify the location of the node are dictated by the verification protocol. Our concern here is to guarantee that there is a time period that is assigned for the node and the server to carry out the service phase with minimal interference from neighbouring nodes and servers. At the end of the assigned time, the server removes the request out of its requests queue regardless of whether the service is completed correctly or not (say because the node acknowledgement is not received). It is the responsibility of the node to make the request again if its older request is not fulfilled. The protocol restrains the operation of both the nodes and the servers. Nodes are not allowed to transmit a new requests until its current request is cleared and servers cannot respond immediately but rather wait till the number of received requests exceeds the RST . Therefore, we refer to our protocol as the RESTRAIN protocol. Now we will describe the nodes and servers operations in more detail:
III. THE RESTRAIN PROTOCOL In this section, we describe the proposed random accessbased scheduling scheme operation. We first start by an overview of the scheme. A node interested in receiving the service makes a broadcast expressing its interest. Each server of those that receive this broadcast queues this request. Whenever the number of queued requests reaches a certain threshold, called the server response threshold ( RST ), the server schedules the first RpSB requests in the queue ( RpSB is a design parameter that determine the number of requests per schedule broadcasted) by picking a suitable future timeslots and then broadcasts this schedule. Every entity records the reserved timeslots specified in the received broadcasted schedule so as not to transmit during them. At the start of the time interval assigned to a node, that node makes a broadcast acknowledging the reception of the schedule and its readiness to enter the service phase. In this acknowledgement broadcast, the node includes a
A. Node Operation
Nodes use the ordinary CSMA/CA with Truncated Binary Exponential Backoff ( TBEB ) scheme to broadcast their requests (similar to [4]) with a timer to trigger retransmission. Briefly, this works as follows: whenever a node needs to make a request, it must sense the medium for Tn timeslots. If the medium is idle during this interval, the node sets its backoff counter bi to a value between 0 and CW − 1 where CW is contention window width. The node decreases bi every timeslot that is idle. Whenever bi reaches zeros, the node broadcasts its request. If during the backoff interval, the node senses that there is a busy timeslot (this includes reserved timeslots by definition), it must go through the same process again but it does not compute a new value for bi but rather uses whatever is left
2 of 7
from the previous backoff counter. Whenever the node makes a request, it sets its re-transmission timer. If the retransmission timer expires before the request is scheduled by some server, the node re-transmits the request again. However, before re-transmission, the node doubles its contention window; i.e. it picks randomly its backoff counter between 0 and 2CW − 1 . The value of CW is set to CWmin whenever a new request needs to be broadcasted and the node keep doubling it every time it needs to retransmit that request up a maximum limit of CWmax ; at which time, the node resets CW back to CWmin . The process continues until either the request is fulfilled or it is discarded after reaching the maximum number retransmission attempts (Re-Tx-Limit). Notice that we require that the node do not transmit more than one request until the current request is cleared (completed or discarded). This restraining reduces the possibility of a node dominating the service. Moreover, whenever the node receives a schedule broadcasted by a server, it considers the interval from the reception time till the last reserved timeslot specified in the broadcasted schedule as reserved timeslots. The reason to start the reservation interval from the reception time as opposed to starting it from the time specified in the schedule itself is mainly to reduce the probability of collision since, as we shall see shortly, the server will schedule in the first timeslot following the last busy slot known to that server. Hence, the node will be utilizing indirectly the PMS of the server. B. Server Operation
Whenever a server receives a new request, it adds the new request to a request queue that includes all received unscheduled requests so far. When the number of queued requests exceeds a certain threshold, called server response threshold ( SRT ), the server enters the scheduling phase where it attempts to schedule certain number of these queued unscheduled requests. The number of requests that is scheduled is determined by the requests per schedule broadcasted ( RpSB ). We require here that RpSB be less than or equal to the SRT value. Once the number of requests queued reaches SRT value, the sever starts competing for access by using a modified CMSA/CA. The modified version works in the same way as we have described in the node operation but with following changes: the medium is sensed for Ts timeslots instead of Tn ( Ts < Tn ) and the backoff counter is picked randomly between 0 and SSBW − 1 where SSBW is the servers’ scheduling broadcast window. SSBW is a fixed
design contention interval that should be large enough to reduce the probability of collision between the servers. Moreover, the server starts its Ts sensing interval following a busy timeslot. In most cases, this would be the timeslot in which the server receives the request that makes its total number of queued requests equal to SRT . Whenever a server receives the broadcasted schedule of another server, it removes from its requests queue any request that is included in the other sever schedule. If some of the removed requests are on the prepared schedule, the server prepares a new schedule by scheduling additional requests so that the total number of scheduled requests is RpSB again and the server continues its countdown to transmission. Notice that the server does not re-start its access process when it detects another server transmission (this is also different from the ordinary CSMA/CA operation, where nodes have to re-start the process whenever there is a transmission or a collision as we described in the nodes operation above). It only re-starts the process whenever it detects a collision or a reserved timeslot. Moreover, whenever the server enters the schedule broadcast process, it does not leave it until it makes a schedule broadcast or the number of request queued becomes less than RpSB value. Notice that SRT acts as a trigger to enter the schedule broadcast state but does not play any role on leaving it. To schedule the chosen set of requests, the server picks whichever is the maximum of the timeslots that comes directly after the last busy slot in its PMS or the slot that is SSBW − 1 timeslots after the current timeslot. This scheduling method ensures that there is at least SSBW − 1 timeslot not reserved which may be used by the other servers to make broadcast if they need to. For comparison reasons, we also implemented a version of the protocol where the servers use the TBEB scheme as the nodes. Of course, the server still cannot start the broadcast process before the number of queued requests reaches SRT and does not leave this state until it makes a schedule broadcast or the number of request queued becomes less than RpSB value. We refer to the original version as RESTRAIN-R and to the new version as RESTRAIN-E. C. Example
We will now present an illustrative example to highlight the key ideas using the RESTRAIN-R protocol. Toward that, consider Figure 1, where two servers are shown that are part of a larger network. Moreover, we assume that servers need to reserve two slots to each request (1 slot for
3 of 7
Ts
SSBW
Ts + 1 b1 = 1
Ts + 2 b2 = 2
Figure 1. Illustration of servers operation in the RESTRAIN-R Protocol.
the node acknowledgement and another for the actual service). Here, we assume that the two servers have received enough requests (i.e. ≥ SRT ) to enter the schedule broadcast phase and that RpSB = 1 . Observe that the two servers share two common requests r1 and r2 with server B having an additional request r3 (of some node that is hidden from server A ). In the top of the figure, we see the Global Medium Status (GMS) that indicates the busy slots with solid shades. However, this information may not be available to all servers. This is because some of the schedule broadcasts may not reach all entities in the network since some will be outside the communication ranges of both the server making the broadcast and the node acknowledging that schedule broadcast. For example, slots 7 and 8 are busy (probably reserved by a third server to fulfill the request of some node) but server B is not aware of this fact as can be seen from its Perceived Medium Status (PMS). Now, suppose that the backoff values of server A and server B are 1 and 2 respectively. Following the busy slot 0, both servers will wait for Ts (which is taken as 1 in this example) and since the slot 1 is idle, both servers start their countdown to transmission (server A for 1 slot and server B for 2 slots). As a result, server A will make a broadcast first and it will schedule the first request r1 in its queue. Since its PMS indicates that the last slot reserved, as known to server A , is slot 8 (which is also more than SSBW − 1 = 2 from
timeslot 3), then it will schedule r1 for timeslots 9 and 10. Server B will detect this transmission and because the transmission is done by another server, it will not re-start its medium access procedure but rather it will continue its countdown to broadcast. In addition, by examining the broadcasted schedule, server B learns that server A have already schedule r1 and hence it removes r1 from its requests queue and instead schedules r2 for slots 11 and 12 (since through server A broadcast, server knows that medium is reserved in slot 10). For illustration purposes, suppose that server B schedules r2 in any idle timeslots known to it as opposed to scheduling r2 in the slot that follows the last busy slot known to server B as done above. Following this “schedule in any idle slot” strategy, server B could potentially picks slots 7 and 8 since it is not aware that they are busy as seen from the GMS. This can create a situation where the nodes scheduled for 7 and 8 interfere with each other and/or with the servers that are suppose to serve them. In contrast, using “schedule in the first slot following the last busy one” reduces the occurrence of such undesirable situation as the servers will be indirectly utilizing each other knowledge of the medium. For example, due to server A broadcast, server B reasons out that sever A must have knowledge of some reserved slots that extend to slot 8 and as a result, it used 9 and 10 instead of any earlier slots.
4 of 7
At the start of the reserved time, the node, for which the reservation is made, broadcasts an acknowledgement message to confirm to the server that it is ready to enter service phase. The acknowledgement message includes a copy of the original schedule to help in spreading the scheduling information to the nodes that did not hear the original schedule (particular those hidden from the server). Here, any entity, that hears this acknowledgement broadcast, extracts the reserved timeslots information out of the schedule to update its PMS and hence obtains a better view of the medium status. Then, in the following timeslot, the service is carried out. Observe that, if both servers pick the same backoff value, there would be a collision and their attempts to schedule r1 will not be successful. However, it is possible that another server may schedule r1 if it hears this request, otherwise the node will have to re-transmit its request again if the re-transmission timer expires before receiving any scheduling information.
IV. Numerical Results In this section, we present our numerical results. The default simulation parameters are shown in Table 1. The results are the average of 30 experiments. Each node is assumed to have a request ready to transmit in any given timeslot.
Table 1. Default simulation parameters. No. of Servers 5 No. of Nodes 25 1 timeslots Ts 5 timeslots SSBW 7 timeslots Tn 0.5 DLC 8 timeslots CWmin 1024 timeslots CWmax Retransmission Timer Simulation Time
120 timeslots 10000 timeslots
with large value of SRT and small RpSB , servers need to make more schedule broadcasts to schedule all queued requests and hence the probability of collision increases. These observations suggest that to increase the number of requests completed, one should choose large value of SRT (at least 2) and set RpSB = SRT . However, this will also result in longer response delay as can be seen from Figure 2(b). This to be expected since servers will have to wait longer till the number of requests reaches the SRT value and hence start scheduling the requests. On the other hand, for a fixed SRT , the average response delay decreases with the increase of RpSB because of the fewer schedule broadcasts that the servers have to make as we have discussed previously.
A. The RESTRAIN Protocol Performance Figure 2(a) shows the average number of requests completed for different values of SRT and RpSB . From the figure, we notice that, in general, for a fixed SRT , the average number of requests completed increases with the increase of RpSB . For example, with SRT = 4 and for RESTRAIN-R protocol, the average number of requests completed is about 41 and 53 for RpSB = 1 and RpSB = 4 , respectively. The reason for this is that with large value of RpSB , the number of schedule broadcast needed by the servers to schedule the queued requests is less; hence reducing the probability of collision and improving the performance. Moreover, the RESTRAIN-R is generally performing better than the RESTRAIN-E. For example, with SRT = RpSB = 1 , the average number of requests completed is about 34 for the RESTRAIN-E, while it is about 45 for the RESTRAIN-R; about 32% better. Notice that for a fixed RpSB , the average number of requests completed decreases slightly as the value of SRT ( ≥ RpSB ) increases. The reason for this is again,
Figure 3 shows the impact of the direct link connectivity ( DLC ) on the percentage of requests completed and the response delay. In general, the performance degraded with large value of DLC because the number of neighbors per an entity increases and hence the collision probability also increases. This also implies that our scheme is much suited for a network environment since, in such case; each node/server will have a very small number of neighbors out of the total in the network (i.e. low value of DLC ). B. Comparison with TDMA-like Clustering-based (TLCB) Scheduling Schemes A typical TDMA-like scheme is a good choice for a single-server multiple-node environment. One way to use it in a large network is to create clusters around the servers typically under the assumption that there is no inter-cluster interference (ICI). However, in a dense network, such assumption may not hold well due to the close proximity of the clusters. In this section, we compare our proposed scheme with a simple TDMA-like Clustering-based (TLCB) scheme that we have designed as we are not able to find a scheme that uses the same set of assumptions that
5 of 7
60
RpSB=1,E
RpSB=1,R
RpSB=2,E
RpSB=2,R
RpSB=3,E
RpSB=3,R
RpSB=4,E
RpSB=4,R
RpSB=5,E
RpSB=5,R
RpSB=6,E
RpSB=6,R
250
RpSB=1,E
RpSB=1,R
RpSB=2,E
RpSB=2,R
RpSB=3,E
RpSB=3,R
RpSB=4,E
RpSB=4,R
RpSB=5,E
RpSB=5,R
RpSB=6,E
RpSB=6,R
50
40
Avg. Response Delay (slots)
Avg. Num Req. Completed per Node
200
30
150
100
20
50 10
0
0 1
2
3 4 Server Response Threshold (SRT)
5
6
1
2
3 4 Server Response Threshold (SRT)
5
6
(a) (b) Figure 2. Performance of the exponential (E) and random (R) versions of the RESTRAIN protocol for different combination of SRT and RpSB : (a) average number of requests completed, and (b) average response delay. we are considering in this paper. We believe that our TLCB scheme capture the essence of a typical TLCB. We will also see that our TLCB performs extremely well when there is no ICI as typically assumed in such approach. Our TLCB scheme is partially inspired by the Guaranteed Time Slots (GTS) mechanism in the IEEE 802.15.4 [5]. The designed TLCB scheme works as follows. Following a beacon slot, a node with a request to transmit picks a slot randomly within a request contention window ( RCW ) and transmits its request in the selected slot. In the slot that follows the RCW , the server broadcast a schedule that specifies which of the nodes will be served within a reserved slots window ( RSW ). Of course, the number of requests that can be served within RSW is determined by the size of RSW and the number of slots needed to serve each request. A new beacon is then broadcasted and the whole process is repeated. If the schedule broadcasted does not include a node request, that node will re-transmit its request again in the following beacon interval. The node keeps re-transmitting its request in each new beacon interval until it is scheduled by the server or it reaches the re-transmission limit (Re-TxLimit). To compare the different schemes, we set RCW = 8 and RSW = 4 (i.e., a maximum of two requests can be served within a beacon interval). We experimented with different values of RCW and RSW and the above chosen values are the ones that seems to give the best performance for our simulation setup. For the RESTRAIN protocol, we set SSBW = 0 and SRT = RpSB = 2 (i.e., in a single broadcast, two requests can be scheduled). To create a dense network, we placed 5 servers and 50 nodes randomly and uniformly in 20m by 20m network. The
communication range is set to 10m, i.e. two entities within 10m can “hear” each other. Figure 4 shows the simulation results for the various schemes. Observe first that, in the absence of inter-cluster interference (w/o ICI), the TLCB has the highest average number of requests completed per node (ANRCpN). However, with ICI, the value of ANRCpN drops sharply due to the collision that is caused by the transmission in the adjusting clusters. Moreover, the RESTRAIN-R has a better ANRCpN value compared to that of TLCB with ICI but of course the RESTRAIN-R does not require setting-up clusters and maintaining them. The performance of RESTRAIN-R can be further enhanced by setting up clusters in the sense that each node associates itself with one server which becomes responsible for serving that node (RESTRAIN-R, Clstr, w/ICI). Also, for comparison, the ANRCpN is shown for the RESTRAIN-R when there is no ICI interference which result in a performance jump although lower than TLCB under ideal condition. This suggests that, if the ICI is not present or negligible, a TLCB is a very efficient scheduling scheme. However, where ICI is significant or the cost of maintaining clusters is high, our RESTRAIN-R is a valuable choice. Observe also from Figure 4(a) that performance of RESTRAIN-E is lower than that of RESTRAIN-R but still it has a comparable performance to the TLCB with ICI. Moreover, when RESTRAIN-E is used in conjunction with clustering (and ICI), it will outperform TLCB with ICI. Figure 4(b) shows that the average response time (ART) for the TLCB scheme is the best. This is to be expected as TLCB uses a frame structure that repeats periodically and hence the requests are fulfilled faster than in the RESTRAIN protocol where the server has to wait till the number of requests reaches the threshold. However, the ART for the RESTRAIN is reasonable and not that excessive.
6 of 7
80
300 SRT=2, RpSB=2 (E)
SRT=2, RpSB=2 (R) 250
SRT=4, RpSB=2 (E) 60
SRT=4, RpSB=2 (E)
SRT=4, RpSB=2 (R)
Avg. Response Delay (slots)
Avg. Num Req. Completed per Node
SRT=2, RpSB=2 (E)
SRT=2, RpSB=2 (R)
70
SRT=4, RpSB=4 (E)
50
SRT=4, RpSB=4 (R) 40 30
SRT=4, RpSB=2 (R) 200
SRT=4, RpSB=4 (E) SRT=4, RpSB=4 (R)
150
100
20 50 10 0
0 0.2
0.4
0.6
0.8
1
0.2
0.4
0.6
DLC
0.8
1
DLC
(a) (b) Figure 3. Performance of the exponential (E) and random (R) versions of the RESTRAIN protocol for different values of DLC : (a) average number of requests completed, and (b) average response delay. 120
180
160 100
Avg. Response Delay (slots)
Avg. Num Req. Completed per Node
140
80
60
40
120
100
80
60
40 20 20
0
0 TLCB, w/o ICI
TLCB, w/ ICI
RESTRAIN-R
RESTRAIN-R, Clstr, w/o ICI
RESTRAIN-R, Clstr, w/ ICI
RESTRAIN-E
RESTRAIN-E, Clstr, w/o ICI
RESTRAIN-E, Clstr, w/ ICI
TLCB, w/o ICI
TLCB, w/ ICI
RESTRAIN-R
RESTRAIN-R, Clstr, w/o ICI
RESTRAIN-R, Clstr, w/ ICI
RESTRAIN-E
RESTRAIN-E, Clstr, w/o ICI
RESTRAIN-E, Clstr, w/ ICI
(a) (b) Figure 4. Performance of various schemes: (a) average number of requests completed, and (b) average response delay.
V. CONCLUSION
REFERENCES
In this paper, we have presented a protocol to schedule service requests using a contention-based approach. The protocol is designed for network with multiple nodes and servers without requiring a frame structure. Unlike many reservation protocols, ours does not assume a cluster-based hierarchy with zero-interference between clusters and hence it has better deployment advantage. The responsiveness of the servers can be controlled through two parameters: sever response threshold SRT , and requests per schedule broadcasted RpSB . Results show that a high number of requests can be completed by choosing large value for SRT and setting RpSB = SRT . Moreover, the RESTRAIN protocol outperforms the TDMA-like clustering-based approach in terms of the average number of requests completed per node under the practical consideration of inter-cluster interference. Further work is needed to assess under what network conditions (e.g. server density, network connectivity, etc.) the performance of the RESTRAIN protocol is optimum.
[1] S. Mishra and A. Nasipuri, "An adaptive low power reservation based MAC protocol for wireless sensor networks," In IPCCC04, Phoenix, Arizona, USA, 2004. [2] N. Aslam, W. Robertson, S. C. Sivakumar, and W. Phillips, "Reservation based medium access control protocol for wireless sensor networks," In 3rd CCNC 2006, Las Vegas, Nevada, USA, 2006. [3] L. A. Goldberg and P. D. MacKenzie, "Analysis of Practical Backoff Protocols for Contention Resolution with Multiple Servers," J. Computer and System Sciences, vol. 58, no. 1, pp. 232-258, Feb. 1999. [4] ANSI/IEEE Standard 802.11-1999, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications," 1999. [5] IEEE Standard 802.15.4-2006, "Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (LR-WPANs)," 2006.
7 of 7
