Collisions & Virtual collisions in IEEE networks

Transcription

1 Collisions & Virtual collisions in IEEE networks Libin Jiang EE228a project report, Spring 26 Abstract Packet collisions lead to performance degradation in IEEE [1] networks. The carrier-sensing mechanisms (either Physical Carrier-Sensing or Virtual Carrier-Sensing) are designed to address hidden-terminal-induced packet collisions. However, we find that such collisions and "virtual collisions" still exist. Virtual collisions happen where a transmitter has to backoff and retransmit a packet even if its packet can be received correctly. The problem persists no matter how large the CS is. In this project, we describe two example symptoms caused by collisions and "virtual collisions": throughput unfairness and routing instability. Then we investigate a new design to overcome hidden-terminal-induced collisions. Through analysis and simulations, we evaluate its performance of the new design and show that the above two symptoms are successfully removed. Although the new design requires a relatively large CS to avoid collisions, a good tradeoff between throughput and collisions can be achieved by relaxing the range requirement. 1 Problem of Carrier-Sensing in IEEE It is well known that Hidden-terminal problem exists in random-access wireless networks. In Figure 1, (i.e., Transmitter2) cannot sense the transmission from T1 to R1 (i.e., Receiver 1), so it goes ahead and send a packet to R2. But it collides with T1 s transmission at R1, making R1 suffer from Hidden-terminal problem. T1 PCS R1 R2 IR: Interference PCS: Physical Carrier Sensing : Virtual Carrier Sensing 1 2 Basic Mode -R1 <IR; T1- <PCS Figure 1. Hidden-terminal problem Link contention Graph (Link: a Transmitter-Receiver pair) In the following, we use the term link to refer to a transmitter-receiver pair. For example, link 1 is the pair (T1, R1). There are some other terms in the green box of

2 Figure 1. IR is Interference : if a node is within the IR of either the transmitter or receiver in a link, it will cause interference to the link if they transmissions overlap. A node within the PCS of a transmitter can physically sense (not necessarily decode) the transmitted signal, and therefore is refrained from transmitting. A node within the of a transmitter (or receiver) can decode the RTS (or CTS) packet, and therefore is refrained from transmitting in the following data transmission interval specified in the RTS/CTS packets. RTS/CTS handshake was proposed to address this problem [2]. RTS and CTS clear the area around the transmitter and receiver, such that the two-way DATA-ACK exchange is not collided. In Figure 2, the problem in Figure 1 is solved. T1 R1 R2 RTS/CTS mode -R1 <IR; >IR Figure 2. Use RTS/CTS to address the problem However, using RTS/CTS cannot eliminate collisions introduced by hidden terminals. Consider Figure 3, collisions and virtual collisions happen when a receiver can sense busy channel but the transmitter cannot. For example, let s say link 1 starts first, so R2 and R3 receive RTS or CTS, and will keep quiet during this transmission on link 1. But and T3 do not know the transmission and may send a RTS to R2/R3. For link 3, T3 s packet is collided by T1 s packet, so this transmission fails. For link 2, R2 cannot reply to with a CTS because the CTS would collide with T1 s packet at R1. (since s RTS may not undergo a real collision, we call this a virtual collision.) For both link 2 and 3, the transmitters need to backoff and try again. However, and T3 can not sense link 1 and thus do not know when to send RTS (this is a failure of carrier-sensing). As a result, their transmissions will fail with high probability if link 1 is busy 1. In the rest of the report, if not specially noted, we use collisions to refer to hiddenterminal-induced collisions and virtual collisions. 1 There are in fact two kinds of collisions in IEEE networks. (1) Interfering links are within CS of each other, but multiple nodes happen to start transmission at the same time slot. This will not cause much trouble, since the collisions can be resolved quickly in the subsequent retransmissions. (2) A transmitter cannot sense the ongoing transmission on another interfering link. Collisions of this type are serious since the carrier-sensing mechanism has failed. The project focuses on the latter.

3 Collision Virtual Collision T3 R3 T1 R1 R2 RTS/CTS Mode >IR Figure 3. RTS/CTS do not eliminate collisions There are further problems in this topology. T1 knows Link 3 (T1 can receive the CTS from R3), but T3 does not know Link 1, resulting in collisions. This is Information asymmetry, which will cause link 3 to get a much lower throughput than link 1, if both links are saturated. How to solve the problem? A naïve approach is to increase the carrier-sensing range (in Figure 3, increase the ) to cover and T3, so that they can sense link 1. However, it is always possible that the receiver can sense busy channel but the transmitter cannot (i.e., the receiver is within the range but the transmitter is not). So using large CS alone does not help. Packets arriving at R2 R2 T1 R1 Packet T1->R1 Preamble, length MAC Data PCS Preamble, length MAC Data (->R2) Packet ->R2 Basic Mode Packets on Link 2 are often lost, for any PCS. If T1-R2 <PCS, R2 can miss the packet ->R2 Figure 4. Similar situation in Basic Mode Similar situation exists in "Basic Mode, if the receiver cannot restart to receive a stronger packet. Consider the scenario in Figure 4. Let s say T1 s packet arrives first at R2. In the Physical header, there is a preamble (indicating this is an IEEE packet) and a length field (indicating the duration of the following packet). Then R2 synchronizes with this packet and tries to decode it. Since the checksum is at the end of the packet, R2 does not know whether it is corrupted or not before finishing receiving the packet. In

4 the process, a packet from arrives. This packet is missed by R2 since it has synchronized with the earlier packet. Then will not receive ACK from R2, and it must backoff and try again. Since cannot sense link 1 (similar to Figure 3), the probability of failure is high. 2 Related Problems (Symptoms) The hidden-terminal-induced collisions are the root of many performance problems, which we call symptoms, to differentiate them from the underlying collision problem itself. Reference [3] identified at least two of them: Throughput Unfairness and Routing Instability. Our simulations were conducted in NS2 [4]. An network s data rate is set at 11Mbps, and it runs in Basic Mode. Two-ray ground propagation model [5] is adopted with the path loss exponent α =4. The SIR required for correct reception is 1dB. The carrier-sensing range is 55m. The Ad-hoc On-Demand Distance Vector (AODV) routing protocol [6] are used. All data sources use a fixed packet size 146 Bytes. TCP 1 TCP Throughput (Mbps) TCP 1 TCP 2 Throughput (Mbps) Time (s) Figure 5. Throughput Unfairness Time (s) Figure 6. Routing Instability 2.1 Throughput Unfairness Similar to [3], we consider a chain topology as in Figure 5. The 6 nodes in a straight line are equally spaced by 14 meters. TCP 1 is from node 1 to 3, and TCP 2 is from node 6 to 4. TCP 1 starts earlier at 3. sec, and TCP 2 starts at 1. sec. Note that node 1 is hidden from node 5, causing node 5 s DATA packet to be lost at node 4. Likewise, node 2 is hidden from node 6, causing node 6 s DATA packet to be lost at node 5. Because TCP 1 starts earlier and causes lots of collisions to TCP 2, TCP 2 virtually got no chance to obtain any throughput (Figure 5). We think the severe unfairness here is magnified by the fact that a TCP flow, at its starting phase, has disadvantages. First it needs to send SYN packet to establish connection. If SYN is lost, it has to retry. Also, after establishing the connection, its congestion window is so small that fast retransmission is impossible

5 due to the lack of 3 duplicate ACKs. So once a packet is lost, it resets the congestion window to one and waits for a timeout (which is usually in the order of 5ms). 2.2 Routing Instability Re-routing instability is triggered by excessive packet collisions, which is mistook by the routing protocol (such as AODV and DSR) for route unavailability. When the route is regarded as broken, a re-routing process is initiated, and no traffic can get through before a route is found. In Figure 6, there are 12 nodes in a straight line spaced by 14m. A UDP flow is sent by node 1 to node 12. There is self-interference in this flow: Node 5 is hidden from node 1, causing the packets of node 1 to be repetitively lost at node 2. Likewise, nodes 2, 3, 4, 5, face the same problems. The collisions trigger re-routing, which explains the gaps in the throughput curve (Figure 6). Since the route is not really broken, re-routing is not necessary. 3 New Design Before presenting the new design, first we give some definitions. Each link i has an "Interference ": IR = f( d ), where f(.) is an increasing function. IR = f( d ) links i, j are "interfering" if X X < IR or IR, where X { T, R}, X { T, R }. i i i j j j i i j i j i Note: (1). f(.) is an increasing function: when d i increases, the received power at the receiver decreases (we have assumed constant and the same transmission power for all the transmitters). To ensure a certain SIR (Signal-to-Interference Ratio), other transmitters must be farther from the receiver (i.e., IR increases). In Section 2, we have adopted two-ray ground propagation model with path loss exponent α =4, and the SIR required for correct reception is 1dB. It can be derived that IR=f(d)=1.78d. (2) Also, since there is always two-way traffic (RTS-CTS, DATA-ACK) in 82.11, so both the transmitter and receiver should be protected. This is how interfering links are defined. The new design consists of two parts. We now describe it for Basic Mode and RTS/CTS Mode, respectively. 3.1 Basic Mode (no RTS/CTS) 1. Requirement: Transmitter must sense the interfering link(s). The figure below shows the worst case scenario where the distance between the two transmitters in two interfering links reaches the imum.

6 PCS > { T T }, interfering links i, j { T T } = 2d + IR i j So, PCS > 2d + IR i j T1 R1 R2 d IR d 2. Receiver Requirement: Receiver assumes no role in Carrier-Sensing, (since the Requirement has ensured that the transmitter can sense any interfering links.) a. Restart : If a stronger packet arrives later, the receiver switches to receiving the packet. (This is to avoid the wrong behavior in Figure 4.) b. In any case, return ACK upon correctly receiving a DATA packet 3.2 RTS/CTS Mode The following requirements are very similar to the Basic Mode. 1. Requirement: transmitter must receive the RTS or CTS from interfering link(s). That is, > {min( Ti Tj, Ti Rj )}, interfering links i, j so, > d + IR Figure 7 shows a worst case scenario (between link 1 and link 2), a detailed proof of this requirement is in [7]. 2. Receiver Requirement: Receiver assumes no role in Carrier-Sensing a. Restart : If a stronger packet arrives later, the receiver switches to receiving the packet. b. In any case, return CTS/ACK upon correctly receiving a RTS/DATA packet (to avoid the situation in Figure 3) R2 T1 R1 d IR d R3 RTS/CTS mode If >d+ir, then R1-R3 >IR T3 Figure 7. The new design for RTS/CTS mode To get a concrete idea, Figure 7 illustrates how the new design works. Link 1 and link 2 are interfering with each other. Thanks to the Requirement, can hear the CTS

7 from R1, and T1 can hear the CTS from R2, so the transmitters can sense the interfering links and avoid overlapping transmissions. T3 cannot sense link 1 and can transmit at the same time with link 1. Because T3-R1 > IR + d, and T3-R3 < d, we have R3- R1 >IR. Continue the proof and it is easy to see link 1 and link 2 are not interfering. Upon receiving the RTS from T3, R3 sends a CTS to T3 (Receiver Requirement) and DATA-ACK exchange is started. In summary, for any scenario, no collisions will happen. 3.3 Performance evaluation To evaluate the performance of the new design, we revisit the symptoms in Section 2. We run the same simulations, but after meeting the two requirements in the new design (PCS = 55m > 2d + IR = 2*14m *14m, so it satisfies the Requirement). Figure 8 and Figure 9 give the results: both unfairness problem and routing instability have been removed. More importantly, by eliminating the underlying causes of these symptoms, collisions and virtual collisions, the new design will be able to remove any other symptoms caused by collisions. Throughput (Mbps) TCP 1 TCP Time (s) Figure 8. Removing Unfairness Throught (Mbps) Before After Time (s) Figure 9. Removing Routing Instability 4 Throughput-Collision Tradeoff Our primary objective up to now has been to remove collisions in networks. In general, there is a fundamental tradeoff between collisions and throughput. If some degree of collisions is allowed to exist, the throughput unfairness, routing instability, and other related symptoms may resurface somewhat. On the other hand, the overall network throughput may increase due to the smaller CS. To study this tradeoff, we simulate a random topology with 4*4=16 APs (i.e., 16 cells). The size of each cell is 175m*175m, and d = 175/ 2 m 123.8m. 64 clients are randomly placed with a uniform distribution. Each client is associated with the nearest AP and sends a saturated flow to the AP. Two settings are simulated: the curve IEEE shows the results if the standard protocol is used; the curve Meeting Receiver Requirement shows the results if the Receiver Requirement is the new design is met.

8 Note that the Requirement is not satisfied except when PCS = 47m. Figure 1 shows the total throughput and MAC-layer collision probability as a function of PCS, as well as the tradeoff between the throughput and collision probability. Collision Probability Collision Probability After meeting "Receiver Requirement" IEEE PCS (m) (a) Collision Probability vs. PCS Total Throughput (Mbps) Total Throughput After meeting "Receiver Requirement" IEEE PCS (m ) (b) Total throughput vs. PCS After meeting "Receiver Requirement" IEEE Collision Probability Total Throughput (Mbps) (c) Throughput-Collision Tradeoff in both settings Figure 1. Throughput-Collision Tradeoff There are three key observations from Figure 1: As expected, when PCS decreases, throughput decreases and collisions increase, in both curves. In other words, the tradeoff always exists. Although we begin with removing collisions, in practice one can relax the requirement of PCS to achieve a good tradeoff. With the same PCS setting, the Meeting Receiver Requirement curve always has a higher throughput and a lower collision probability than the IEEE curve with the same PCS. In other words, meeting Receiver Requirement improved the tradeoff. There is also a minor observation. Note that the floor collision probability in the new design (when PCS=47m in the blue curve) is about 7%. These MAC-layer collisions are due to the fact that backoff timers of different nodes may still choose the same random

9 number in a Contention Window. However, they do not belong to hidden-terminalinduced collisions (the focus of the project), and will not cause the symptoms discussed before. This is because when such a collision happens, it is likely to be resolved quickly in the retransmissions after new random backoff counters are chosen. 5 Related works Reference [8] provided an analysis on hidden-terminal-induced collisions in networks. There, it was argued that when the PCS range is larger than d plus IR, collisions can be avoided and RTS/CTS is no longer needed. This is true if data transmission is one-way. In 82.11, however, the two-way handshake (RTS-CTS-DATA- ACK) has complicated the issue. We have shown that both Requirement (different from the one mentioned above) and Receiver Requirement need to be met to avoid such collisions. Reference [9] studied false blockings and proposed a scheme to reduce them. A receiver is said to be blocked if a collision or virtual collision illustrated in Figure 3 happens. In Figure 3, R2 and R3 are blocked. A false blocking happens when a node near or T3 keeps silent after hearing an RTS, but the RTS actually suffers from a collision or virtual collision and therefore no DATA transmission follows. It was pointed out that false blockings lead to RTS/CTS congestion, which reduces the capacity of the network. A scheme called RTS validation was proposed in to reduce the false blockings. [9] focuses on the network capacity issue when false blockings happen, and the proposed RTS validation does not aim to removing hidden-terminal-induced collisions. Therefore the symptoms discussed in Section 2 may persist. Our study, on the other hand, focuses on eliminating the collisions themselves. If such collisions are avoided, false blocking will not occur since an RTS will be followed by DATA transmission with high probability (see Figure 7 for example. We note it is with high probability but not always since RTS can still be collided if two transmitters happen to transmit at the same time slot). 6 Conclusion In conclusion, we have identified the fundamental reason why hidden-terminal-induced collisions still exist in network; and provided a new design (including Requirement and Receiver Requirement a set of sufficient conditions) to remove such collisions. By fixing the root, the new design removes the symptoms described in [3], and is expected to also remove other symptoms caused by such collisions. Also, by relaxing the Requirement, a good tradeoff between throughput and collisions can be achieved. There are open problems in the new design. For example, we have assumed that f(.) is an increasing function (Interference increases with the link length), and is the same

10 for all the links. In an irregular propagation environment (e.g., there are walls, doors between transmitters and receivers), the assumptions do not hold. In this case, what matters is the channel gain between any pair of nodes, instead of distance. How to adapt the design to this situation is interesting for further investigation. Reference [1] IEEE Standards Department, IEEE Standard for Wireless LAN, Medium Access Control (MAC) and Physical Layer (PHY) Specifications, [2] V. Bharghavan, A. Demers, S. Shenker, and L. Zhang, MACAW: A media access protocol for wireless LANs, Proceedings of the ACM SIGCOMM Conference, volume 24, pages , Oct [3] Xu, S.; Saadawi, T., Does the IEEE MAC protocol work well in multihop wireless ad hoc networks? Communications Magazine, IEEE, Volume: 39, Issue: 6, June 21, Pages: [4] "The Network Simulator - ns2", [5] T. Rappaport, Wireless Communications: Principles and Practice, Prentice Hall, New Jersey, 22. [6] C. E. Perkins, E. M. Royer, Ad-hoc On-Demand Distance Vector Routing, Proc. 2 nd IEEE workshop on Mobile Computing Systems and Applications, Feb 1999, pp [7] L. Jiang, S. C. Liew, Hidden-node Removal and its Application in Cellular WiFi Networks, Submitted to IEEE transaction on Vehicular Technology. [8] K. Xu, M. Gerla, S. Bae, How Effective is the IEEE RTS/CTS Handshake in Ad Hoc Networks?, IEEE GLOBECOM '2, Vol. 1, pp , Nov. 22. [9] Saikat Ray, Jeffrey B. Carruthers, and David Starobinski, "RTS/CTS-induced congestion in ad-hoc wireless LANs," in IEEE Wireless Communication and Networking Conference, March 23, pp