2009 International Conference on Advanced Information Networking and Applications Workshops Impact of IEEE 802.11n Operation on IEEE 802.15.4 Operation B Polepalli, W Xie, D Thangaraja, M Goyal, H Hosseini University of Wisconsin - Milwaukee Milwaukee, WI 53201 Email: {brpjr,wxie,thangar2,mukul,hosseini}@uwm.edu YBashir Johnson Controls Inc. Milwaukee, WI 53202 Email: yusuf.bashir@jci.com Abstract Wireless communication among sensor devices, enabled by IEEE 802.15.4 protocol, is increasingly replacing the existing wired technology in a wide range of monitoring and control applications. IEEE 802.15.4 networks typically operate in 2.4GHz ISM band, which is used by popular IEEE 802.11 (WiFi) networks as well. An overlap between the channels used by IEEE 802.15.4 and IEEE 802.11 networks may adversely impact the operation of IEEE 802.15.4 since it is a low power protocol using a small channel width compared to the transmitted power levels and channel width used by IEEE 802.11. Avoiding channel overlap between IEEE 802.15.4 and IEEE 802.11 networks will become difficult once proposed IEEE 802.11n technology becomes popular. This is because an IEEE 802.11n network may use two 20MHz wide channels for its operation, rather than a single 20MHz channel as is the case with other IEEE 802.11 PHY layers. In this paper, we evaluate, via test bed experiments, the impact of IEEE 802.11n operation on IEEE 802.15.4 performance when there is an overlap between the channels used by IEEE 802.15.4 and IEEE 802.11n networks. 1. Introduction Wireless communication among sensor devices, enabled by IEEE 802.15.4 protocol [1], is increasingly replacing the existing wired technology in a wide range of monitoring and control applications [2], [3]. IEEE 802.15.4 networks typically operate in 2.4GHz ISM band, which is used by popular IEEE 802.11 (WiFi) networks [4] as well. An overlap between the channels used by IEEE 802.15.4 and IEEE 802.11 networks may adversely impact their operation. This is especially true for IEEE 802.15.4 since it is a low power protocol using a small channel width compared to the transmitted power levels and channel width used by IEEE 802.11. Hence, IEEE 802.15.4 networks avoid using channels that overlap with the channels used by IEEE 802.11 networks. The IEEE 802.11 divides the 80MHz wide 2.4GHz band into 5MHz wide channels with an IEEE 802.11 network operating over a 20MHz wide range henceforth referred to as the control channel. The 2.4GHz band can support upto three non-overlapping control channels, centered at IEEE 802.11 channels 1, 6 and 11, in the same location. Thus, IEEE 802.11 networks, centered at IEEE 802.11 channels 1, 6 and 11 in 2.4GHz range, are popular. IEEE 802.15.4 also defines a number of 3MHz wide channels in the 2.4GHz band. There are several IEEE 802.15.4 channels (namely channels 15, 20, 25, 26) that do not overlap with the IEEE 802.11 networks centered at IEEE 802.11 channels 1, 6 and 11. To avoid interference from IEEE 802.11 networks, IEEE 802.15.4 networks typically operate in one of such WiFi-free channels. Such clear separation between the frequency ranges used by IEEE 802.15.4 and IEEE 802.11 networks may not be possible once proposed IEEE 802.11n networks become popular. IEEE 802.11n has several new features such as the use of multiple input and output streams(mimo) and channel bonding that would allow the data rates up to 450 Mbps to be achieved. In particular, channel bonding refers to the use of a 20MHz wide extension channel in addition to the control channel used by IEEE 802.11 networks. The extension channel would be used if the existing traffic load on an IEEE 802.11n network cannot be carried within the control channel. At high traffic loads, an IEEE 802.11n network would use a total bandwidth of 40MHz when operating in 2.4GHz band. Clearly, two or more IEEE 802.11n networks operating in the same location as an IEEE 802.15.4 network would leave no IEEE 802.15.4 channel free from IEEE 802.11n interference. 978-0-7695-3639-2/09 $25.00 2009 IEEE DOI 10.1109/WAINA.2009.102 328
In this paper, we perform test bed experiments to evaluate the impact of IEEE 802.11n operation on the performance of an IEEE 802.15.4 network when the IEEE 802.15.4 channel overlaps with the control or extension channel used in IEEE 802.11n network. The rest of the paper is organised as follows. Operation of IEEE 802.15.4 and IEEE 802.11 MAC protocols is described in Section 2. Section 3 describes the experimental setup. The results of the experiments are described in Section 4. Finally, Section 5 concludes the paper. 2. Overview of IEEE 802.15.4 and IEEE 802.11 MAC Operation 2.1. IEEE 802.15.4 Operation IEEE 802.15.4 [1] provides physical (PHY) and medium access control (MAC) layer functionality in low power and low data rate wireless sensor networks (WSN). IEEE 802.15.4 PHY layer can operate in 868MHz, 915MHz and 2.4GHz bands. In this paper, we focus on the popular 2.4GHz range operation of IEEE 802.15.4 PHY layer, where the information is sent 4 bits, or a symbol, at a time and the maximum data rate is 250kbps. IEEE 802.15.4 MAC operation has two modes - beacon-enabled and beaconless. The beacon-enabled mode allows splitting of time into multiple active durations with a cluster 1 having exclusive access to the transmission channel during its active duration. The coordinator broadcasts a beacon to inform other nodes in the cluster about the beginning of the cluster s active duration. The cluster nodes compete for channel access during their active period using a slotted CSMA/CA algorithm [5]. In the beaconless operation, there is no division of time into active durations and a node competes for channel access with other nodes in its radio range using an unslotted CSMA/CA algorithm. In this paper, we focus on the beaconless operation of IEEE 802.15.4 MAC layer. As per the unslotted CSMA/CA algorithm, the source node begins a transmission attempt with a CSMA wait for a random number of backoff periods (=20 symbols) between 0 and 2 BE 1. Here, BE refers to a variable called the backoff exponent that is initially set to the value of macminbe parameter. After the CSMA wait, the source node determines if the channel is available for transmission. This clear channel assessment (CCA) is performed over a time duration of 8 symbols. If the CCA fails (i.e. the 1. consisting of a coordinator and its associated nodes channel is found to be busy), the node increments BE and repeats the procedure. If the CCA fails even after macmaxcsmabackoffs CSMA waits, a channel access failure is declared and any further attempt to transmit the packet is abandoned. If the CCA succeeds, the source node performs an RX-to-TX turnaround 2 and transmits the packet. On receiving the packet, the destination node performs an RX-to-TX turnaround and sends the acknowledgement (ACK) if required by the source. No CSMA wait is performed for ACK transmission. However, the transmitted packet or its ACK may suffer a collision. In this case, the source node waits for the macackwaitduration for the ACK to arrive and then proceeds with next attempt to transmit the packet. The source node can make upto macmaxframeretries further attempts to transmit the packet and receive the ACK. The failure to receive an ACK even after macmaxframeretries +1 attempts causes the IEEE 802.15.4 MAC layer to accept failure in sending the packet. 2.2. IEEE 802.11 Operation IEEE 802.11 provides options for several different modes of operation involving both contention-based and contention free operation. We describe the popular distributed coordination function (DCF) [4], [6] mode operation. Like IEEE 802.15.4, IEEE 802.11 DCF operation is also based on the CSMA/CA algorithm. A source node that needs to transmit a packet monitors the channel status. If the channel is observed to be idle for a Distributed Inter Frame Space (DIFS) time interval, the source node immediately transmits the packet. Otherwise, the source node continues to monitor the channel status. When the channel is observed to be idle for DIFS duration, the source node selects a random CSMA wait duration. The CSMA wait duration is selected in a uniformly random fashion from the range (0,W) backoff slots, where W refers to the contention window initially set to a value CW min. A node transmits the packet when its CSMA wait is over. However, the CSMA wait does not include the time durations when the channel is busy. During the CSMA wait, whenever the node senses the channel to be busy, it freezes the count-down timer for the CSMA wait. The count-down timer is started again only when the node observes the channel to be idle for DIFS duration. Different IEEE 802.11 PHY layers 2. The IEEE 802.15.4 nodes are typically half-duplex in nature, i.e. they can not perform both the transmit (TX) and receive (RX) operations at the same time. The IEEE 802.15.4 specification [1] requires the RX-to-TX or TX-to-RX turnaround time to be 12 symbols or less. 329
have different criteria to judge whether the channel is idle or not. Proposed IEEE 802.11n PHY would consider the channel to be busy if the energy detected on the channel exceeds a threshold. On receiving a packet, the destination node waits for a Short Inter Frame Spacing(SIFS) interval and then transmits an ACK back to the source node. If the ACK does not reach the source node, the source node doubles up the contention window W upto a certain maximum value. The packet is abandoned if the source node fails to receive an ACK even after a certain maximum number of retransmissions. (a) Top View 3. Experimental Setup and Scenarios In this section, we describe the experimental setup and different scenarios that were considered to evaluate the impact of IEEE 802.11n networks on IEEE 802.15.4 operation. These experiments were performed on a test bed of commercial IEEE 802.15.4 and IEEE 802.11 hardware. The test bed consisted of 15 IEEE 802.15.4 nodes sending packet to their common coordinator using beaconless mode operation and two IEEE 802.11n nodes acting as a client/server pair. The dimensions of the test bed as well as the location of each node are shown in Figure 1. The IEEE 802.11n access point and cards followed the Draft 2.0 version of the proposed standard. The IEEE 802.11n cards used OFDM, 64-QAM with coding rate of 5/6 as the coding scheme and the PHY rate was fixed at 270Mbps. The traffic between the IEEE 802.11n client and server machines was generated using the iperf utility [7], which is an open source software used to generate UDP and TCP traffic loads. Each experiment begins with the iperf client sending a UDP stream to the iperf server over the IEEE 802.11n network. Each IEEE 802.11n packet was 63 KB long and the transmitted power level was 17 dbm. The IEEE 802.11n traffic loads used in the experiments were 1, 2, 5, 10, 15, 20, 30, 40, 50 and 60 Mbps. The IEEE 802.15.4 nodes start sending packets to their coordinator 10 minutes after the start of an experiment. Thus, for first 10 minutes of the experiment, only IEEE 802.11n traffic is present and in next 15 minutes, both IEEE 802.11n and IEEE 802.15.4 traffic streams are present. During the experiment, all 15 IEEE 802.15.4 nodes send 112 byte long packets to their common coordinator at the rate of one packet per second as per the Poisson distribution for 15 minutes. The transmitted power level for IEEE 802.15.4 nodes was 10 dbm. Both IEEE 802.15.4 and IEEE 802.11n operation required each packet to be acknowledged by the receiver. (b) Front View Figure 1. The Test Bed In each experiment, the IEEE 802.15.4 network was formed on a 3 MHz wide channel centered at 2425 MHz while the frequency range used by IEEE 802.11n network varied as described later. In each experiment, we note down the average loss rate observed by each IEEE 802.15.4 nodes as well as the average latency for successful packets as observed by each node. Here, the latency refers to the amount of time IEEE 802.15.4 MAC layer takes to report the fate of a packet (success/failure) to the higher layer. The reported results are average loss rate and latency values across all 15 IEEE 802.15.4 nodes. The corresponding 95% confidence intervals were always observed to be within a small range around the average values. 3.1. Experimental Scenarios Keeping the channel used by IEEE 802.15.4 fixed, we experimented with two different placements of IEEE 802.11n network in the 2.4 GHz band as shown in Figure 2: 1) Scenario 1: In this scenario, the IEEE 802.11n control channel is centered at IEEE 802.11 channel 1 and the extension channel overlaps with the channel used by the IEEE 802.15.4 network. 2) Scenario 2: In this scenario, the IEEE 802.11n control channel is centered at IEEE 802.11 channel 4, i.e. the IEEE 802.15.4 channel is right in 330
(a) Scenario 1 (a) Average Loss Rate for IEEE 802.15.4 Nodes (b) Scenario 2 Figure 2. The Frequency Range Occupied By IEEE 802.15.4 and IEEE 802.11n Networks the middle of IEEE 802.11n control channel. No extension channel is used. For each scenario, we experimented with different IEEE 802.11n traffic loads (1, 2, 5, 10, 15, 20, 30, 40, 50, 60 Mbps). Each experiment was repeated 10 times. In each repetition, we calculated the average loss rate and average latency (for successful packets) across all 15 IEEE 802.15.4 nodes. Then, we calculated the overall average and the confidence intervals for the loss rate and latency across 10 repetitions. The confidence intervals were always observed to be within a small range around the average values. 4. Experimental Results 4.1. The Impact of IEEE 802.15.4 Traffic on IEEE 802.11n Traffic In this section, we present the effect of IEEE 802.15.4 traffic load on IEEE 802.11n networks in different scenarios dicussed above. As mentioned earlier, in each experiment, IEEE 802.11n traffic runs unopposed for first 10 minutes and then for next 15 minutes both IEEE 802.11n and IEEE 802.15.4 traffic are present. (b) Average Packet Latency for Successful Packets for IEEE 802.15.4 Nodes Figure 3. The Impact of IEEE 802.11n Traffic on IEEE 802.15.4 Performance as IEEE 802.11n Traffic Load Incrases: Scenario 1 Experiments In scenario 1, there is a pronounced drop in IEEE 802.11n traffic load once the IEEE 802.15.4 traffic starts. The IEEE 802.15.4 channel lies in the middle of the extension channel used by IEEE 802.11n traffic. The use of two channels (control and extension) allows traffic load up to 60Mbps to be achieved on IEEE 802.11n traffic. However, the start of IEEE 802.15.4 traffic causes the IEEE 802.11n traffic load to drop significantly in case of higher traffic loads (30 to 60Mbps). At high traffic loads, there is significant competition between IEEE 802.11n and IEEE 802.15.4 traffic for access to the transmission channel. This competition causes IEEE 802.11n traffic load to drop significantly. At lower traffic loads (20 Mbps and lower), there is not much competition between IEEE 802.11n and IEEE 802.15.4 traffic for access to the extension channel. In fact, the extension channel may not even be used by IEEE 802.11n traffic at such low loads. Hence, the presence of IEEE 802.15.4 traffic does not have any significant impact on IEEE 802.11n traffic loads. In scenario 2,the IEEE 802.11n network uses just 331
(a) Average Loss Rate for IEEE 802.15.4 Nodes (b) Average Packet Latency for Successful Packets for IEEE 802.15.4 Nodes Figure 4. The Impact of IEEE 802.11n Traffic on IEEE 802.15.4 Performance as IEEE 802.11n Traffic Load Incrases: Scenario 2 Experiments the control channel and hence we were not able to achieve traffic loads higher than about 40 Mbps. In this scenario, the IEEE 802.15.4 channel lies right in the middle of the IEEE 802.11n channel and hence there is a significant drop in IEEE 802.11n traffic load (for traffic loads higher than 20 Mbps) once the IEEE 802.15.4 nodes start contending for the channel access. 4.2. The Impact of IEEE 802.11n Traffic on IEEE 802.15.4 Traffic In this section, we present the testbed results regarding the impact of IEEE 802.11n network operation on the performance of IEEE 802.15.4 nodes. The impact is measured in terms of the increase in average loss rate and the average latency (for successful packets) for IEEE 802.15.4 nodes caused by the competition from IEEE 802.11n traffic. In other words, we report the difference between the average loss rate /latency when IEEE 802.11n traffic is present and when it is not present. Figures 3 and 4 show this impact on IEEE 802.15.4 performance as the traffic load on IEEE 802.11n network increases. In scenario 1, the extension channel used by IEEE 802.11n traffic overlaps with the IEEE 802.15.4 channel. As Figure 3 shows, the impact of IEEE 802.11n traffic on IEEE 802.15.4 performance becomes more severe as the traffic load on the IEEE 802.11n network increases. It is observed that the loss rate of IEEE 802.15.4 nodes increases by around 30% and the latency for successful packets increases by around 160ms in presence of moderate IEEE 802.11n traffic load of 60 Mbps (Figure 3). Such increase in the loss rate and latency values may be unacceptable in many WSN applications. In scenario 2, the control channel used by IEEE 802.11n traffic overlaps with the IEEE 802.15.4 channel. Figure 4 shows the impact on IEEE 802.15.4 performance in scenario 2 as the IEEE 802.11n traffic load increases. Clearly, the impact is much more severe in scenario 2 than in scenario 1. The IEEE 802.11n traffic causes much severe increase in IEEE 802.15.4 loss rate in scenario 2 than in scenario 1. With 60Mbps IEEE 802.11n traffic, the IEEE 802.15.4 loss rate increases by 80% and the latency for successful packets increases by 180 ms whereas the corresponding increase in case of scenario 1 was about 30% and 160 ms respectively. This is because the IEEE 802.11n traffic uses the control channel much more extensively than the extension channel. 5. Conclusion In this paper, we presented testbed results regarding the impact of IEEE 802.111n traffic on the performance of an IEEE 802.15.4 network. We evaluated two different scenarios: 1) IEEE 802.15.4 channel overlapping with IEEE 802.11n extension channel, 2) IEEE 802.15.4 channel overlapping with IEEE 802.11n control channel. In each scenario, we observed that the loss rate and the latency for successful packets for IEEE 802.15.4 nodes traffic increase substantially with increase in the IEEE 802.11n traffic load. Specifically, we observed that: 1) Overlap with the IEEE 802.11n extension channel can cause IEEE 802.15.4 packet latency to suffer serious deterioration. The increase in packet latency may make successful packet delivery useless in many WSN applications. The impact on the IEEE 802.15.4 loss rate, although substantial, is not as severe as in case of an overlap with the IEEE 802.11n control channel. The deterioration in IEEE 802.15.4 performance worsens with increase in the IEEE 802.11n traffic load. The exact impact depends on the actual 332
usage of the extension channel in carrying IEEE 802.11n traffic. 2) Overlap with the IEEE 802.11n control channel causes severe deterioration in both the loss rate and the packet latency for IEEE 802.15.4 traffic. This impact is much more serious than the impact due to overlap with the IEEE 802.11n extension channel. The impact worsens with increase in the IEEE 802.11n traffic load. We also presented a qualitative account of the impact of IEEE 802.15.4 operation on IEEE 802.11n performance. In future, we intend to perform a systematic study of the impact of IEEE 802.15.4 operation on IEEE 802.11 performance. References [1] Part 15.4: Wireless MAC and PHY layer specifications for low-rate wireless personal area networks, IEEE Std 802.15.4-2006, 2006. [2] M. Dohler, T. Watteyne, T. Winter, and D. Barthel, Urban WSNs Routing Requirements in Low Power and Lossy Networks, IETF, Internet-Draft draft-ietfroll-urban-routing-reqs-02, Oct. 2008, work in progress. [3] Routing over low power and lossy networks. [Online]. Available: http://www.ietf.org/html.charters/roll-charter. html [4] Part 11: Wireless lan medium access control and physical layer specifications, IEEE Std 802.11-2007 (Revision of IEEE Std 802.11-1999), 12 2007. [5] L. Kleinrock and F. Tobagi, Packet switching in radio channels: Part 1 - carrier sense multiple-access modes and their throughput-delay characteristics, IEEE Trans. on Communications, vol. 23, no. 12, pp. 1400 1416, December 1975. [6] G. Bianchi, Performance analysis of the IEEE 802.11 distributed coordination function, IEEE JSAC, vol. 18, no. 3, pp. 535 547, March 2000. [7] NLANR/DAST, Iperf. [Online]. Available: http:// sourceforge.net/projects/iperf 333