A Method to Release NAV for Utilization of the Wireless Medium in IEEE802.11

Ⅰ. Introduction

IEEE802.11[1], which details the MAC protocol for wireless networks, is a protocol for efficient data communication among multiple nodes through the same channel. Unlike a wired network, a wireless network operates in half-duplex mode, making it difficult to detect collisions and lowering the data rate. Furthermore, a wireless network has a high possibility of data communication failure due to causes such as noise, offset, and fading. For this reason, it is critical to achieve successful data communication with minimum attempts in order to improve the efficiency of a wireless medium. Furthermore, it is crucial to accurately specify detailed protocol to support successful communication with no collisions between frames in the MAC level protocol[2].

IEEE802.11 describes distributed coordination function (DCF) and point coordination function (PCF) of the MAC protocol. Especially in DCF, several techniques are used to prevent collision when multiple nodes try to access the medium simultaneously. The channel access units are divided into time slots and nodes are allowed to access a channel after expiration of a random back-off timer for the time slot ^* contention window (CW). Furthermore, because the carrier sensing multiple access with collision avoidance (CSMA/CA) protocol [3] has been adopted, the transmission of a node is deferred if there is a neighbor node that has accessed the channel earlier. In this case, a duration field inserted into the data and control frames is used. Every node participating in the network sets a network allocation vector (NAV) to defer its transmission for the value in the duration field of the detected frame so that it will not interfere with other transmissions. This NAV feature prevents collisions between the frames of different nodes. However, this method has a drawback. It occurs in one case when using a 4-way handshake with request to send (RTS) and clear to send (CTS) as described in DCF. If a CTS frame is sent as a response to RTS, the medium occupation efficiency of surrounding nodes may decrease due to the NAV that has been set unnecessarily. Even if a CTS frame for RTS has been sent from the destination node, both data exchange and medium access attempts may not be carried out because the CTS frame is not successfully transmitted due to transient link noise. In this case, the surrounding nodes of the source and destination nodes can also decrease the medium occupation efficiency due to the preset NAV.

Therefore, we studied the mac protocol that is improve the channel efficiency by resolving the abovementioned case. The proposed protocol resets the NAVs of related neighbor when the corresponding transmission is broken. From this method, the channel utilization of overall network can be improved. This method has been confirmed through experiments using ordinarily applied network simulator(NS2). Simulation results have shown improved performances such as lower network delay and higher throughput compared to the existing IEEE802.11 MAC protocol and related studies.

The remaining part of this paper is organized as follows. First, background knowledge and related research are described, and then the core method of this study is detailed. Finally, the performance of the proposed method is evaluated through simulation and conclusions are presented.

Ⅱ. Background and Related Work

IEEE802.11 wastes the transmission medium due to the NAV settings of surrounding nodes when the source node loses the CTS frame from the destination node. If only the source node fails to receive the CTS frame due to transient noise of the channel or other reasons, the surrounding nodes do not try to occupy the medium quickly because they think that the medium is already occupied. Thus, the probability that the source node that has lost the prior CTS frame will make the next attempt to send data increases, and the medium occupation time of surrounding nodes is further delayed. Fig. 1 below illustrates this.

Fig. 1.

Delay when source node (A) loses CTS

The source node A sends a RTS for data transmission to the destination node B. Upon receiving the RTS, node B sends a CTS reply to A. However, A fails to receive the CTS from B due to channel noise between A and B or for other reasons. In this case, nodes C and D set their NAV value and defer transmission because they successfully received (overheard) the CTS. Not knowing this, node A restarts the RTS retransmission mechanism in line with the expiration of its CTS timer. Consequently, nodes C and D cannot attempt to send data even if they can occupy the channel, and node A occupies the channel again. At this time, the RTS retransmission back-off timer of A is reset to double the CW value that had been set in the first transmission timer. Hence, it is likely that medium idleness will worsen.

Several studies have been conducted to solve the aforementioned problem[3]. Most of these studies are based on the method of setting one’s own timer so that the nodes will attempt to occupy a medium if the medium is idle for a specific period of time[4]. In particular, in a study[5], an additional frame (MRTS) is broadcast to enable the occupation of the medium by surrounding nodes if the source node loses a CTS and fails to send data[6]. The efficiency of medium occupation is improved by making any node among the surrounding nodes that have received the additional frame and wishes to occupy the medium eligible to exchange data immediately. However, one drawback of this MAC protocol is that the node must obtain specific routing information from the upper-level network layer[7].

The problem can cause greater waste in an infrastructure where multiple mobile nodes are connected to one Access Point (AP). Because every node wants to communicate with the AP, when the duration in which they cannot communicate with the AP increases due to the AP already being occupied, all the nodes in the basic service set (BSS) must defer communication. In this study, therefore, a MAC protocol to solve this problem is proposed, and the proposed protocol has been simulated in an infrastructure network to evaluate its performance.

Ⅲ. Proposed MAC Protocol

In this study, a MAC protocol that resets the NAVs of surrounding nodes to zero when the CTS frame of 801.11 is lost is proposed. The goal of this protocol is to improve the total throughput of the network by redistributing a high probability of medium occupation given to a specific node to other nodes by resetting the NAV.

The process of source node A preparing for data retransmission immediately after the expiration of its own CTS timer in the situation discussed in Fig. 1 is identical. However, immediately before preparing for data retransmission, node A broadcasts a BNACK frame that releases the NAV to surrounding nodes. Upon receiving this frame, the surrounding nodes recognize that source node A failed to receive the CTS and attempt medium occupation that has been deferred. The possibility of occupying the medium by surrounding nodes increases because the timer range of the RTS retransmission of node A is larger than the range of the first retransmission timer. This process increases the throughput of the channel that could otherwise be wasted, which is identical to the proposal by[8].

The protocol proposed in this study has improved an additional problem that may occur. Although the network throughput could be increased by the release of NAV by BNACK, it has the drawback of interfering with the data exchange between nodes that are unrelated to the communication due to the indiscriminately released NAV. In other words, resetting the NAVs of nodes that have set their NAVs for data exchange between E and F, instead of between A and B, can interfere with the communication between E and F. Therefore, in the protocol proposed in this study, the surrounding nodes memorize the address of the node that set their NAV and only reset their NAV if the address of the node sending BNACK is identical to the address that they have memorized. Fig. 2 illustrates this.

Fig. 2.

If the source node (A) loses CTS, BNACK to reset the NAV is broadcast. However, node E does not release its NAV because its NAV was not set by A.

The situation where node A fails to receive the CTS reply to the RTS sent from node A is identical to Fig. 1. As described in the proposed protocol, node A broadcasts BNACK indicating that it failed to receive CTS and the NAV of node C is reset. After that, node A and C compete fairly in their attempt to occupy the medium, and C succeeds in occupying the medium in the figure. In this case, node E does not reset its NAV to zero even if it received the BNACK from node A because its NAV was not originally set by node A.

Fig. 3 shows the frame structure of BNACK. The duration field for NAV is set to zero, the receiver address is set in the broadcast header, and the node’s own address is set in the sender address. Therefore, the surrounding nodes receiving this frame can modify their NAV value by referring to the sender address. The surrounding nodes have to save the sender field of the RTS frame and the receiver field of the CTS frame for comparison with the address field of BNACK. This requires additional memory, but it is not a burden because its size is only six bytes.

Fig. 3

Frame structure of BNACK. The receiver address is set in broadcast and the node’s own address is set in the sender address

Ⅳ. Performance Verification

To verify the performance of the proposed MAC protocol, the network simulation tool NS2 (version 2.32)[9] was used. The simulation settings used in this experiment are as follows. The routing of each node was fixed as static and the agent of a data packet as UDL/NULL for transmission/reception, respectively, the interval of the data packets is 0.01 sec, and the data packet size is 1,052 bytes. Therefore every node in the network continuously transmits the data to the other. We have was measure the performances of legacy MAC(IEEE802.11) and the previous protocols of [8] for comparison. We had modified the MAC protocol of NS2 program.

In this study, the experiment was performed using two scenarios. In the first scenario, one node was randomly moved to cause an error in a fullyconnected network, as shown in Fig. 4. From the missing CTS, the network utilization of node 2 and 3 could be reduced. The proposed protocol can improved the network performance in this situation. The average throughput of the network during a specified simulation time is shown in Fig. 5.

Fig. 4.

First scenario

As shown in Fig. 5, the proposed method achieved a higher throughput than that of the legacy IEEE802.11 protocol. The proposed protocol has a throughput of 103.9kb/s , which is about 9.6% higher than legacy protocol of 94.8kb/s. Furthermore, as the simulation time increased, the difference between the two protocols gradually increased.

Fig. 5.

Average throughput (Legacy and Proposed Methods)

In the second scenario, a total of nine nodes were deployed and one node was set as an AP so that the data generated in the other eight nodes would be concentrated on one node. In other words, the nodes were deployed in a network infrastructure setting for the experiment.

Therefore, this scenario gets the competition worse between node in network. In this case, transmission delay could be getting worse when the AP miss CTSs. We want to show you the improvement of performance in the missing CTS case. The results of this experiment, which was carried out for 100 seconds in total, are shown in Figs. 6 and 7.

Fig. 6.

Average delay (sec)

Fig. 7.

Average throughput

The average delay and average throughput during the simulations greatly improved compared to the existing IEEE802.11 protocol. The proposed MAC has average delay and throughput of 3ms and 332KB/s, which is improved performance than legacy protocol of 4.4ms and 224KB/s. Furthermore, the performance improved by approximately 5% compared to the experimental results of 32.ms and 312KB/s in [8]. This improvement was the result of not releasing the NAV set of nodes unrelated to the node whose CTS failed

Ⅴ. Conclusion and Future Research

This study proposed a solution for the problem of lowering the efficiency of medium occupation in the MAC protocol of IEEE802.11. In the case where the source node fails to receive a CTS frame during the CTS time, a frame for resetting the NAVs of specific surrounding nodes is broadcast. Subsequently, the nodes that have deferred medium occupation due to the preset NAV can quickly respond to the network situation and restart making attempts to occupy the medium. The experiments using the NS2 simulator confirmed that the proposed method produced a higher throughput and a lower delay compared to the existing IEEE802.11 MAC protocol and related studies.

Acknowledgments

This work was supported by 2017 Autonomous car key technology development projects by KEIT and MOTIE (10080063).

References

• "IEEE Wireless LAN medium access control (MAC) and physical layer (PHY) specifications", IEEE standard 802.11-2007, (2012).
• Sungmook Lim, and Kyunbyoung Ko, "Performance Evaluation of MAC Layer Due to Vehicle Intensities in V2V Communications Based on IEEE 802.11p", The Journal of KIIT, 14(8), p41-46, Aug), (2016. [https://doi.org/10.14801/jkiit.2016.14.8.41]
• P. Karn, "MACA – a new channel access method for packet radio", In: Proc. 9th ARRL Computer Networking Conference, (1990).
• A. Chayabejara, S. M. S. Zabir, and N. Shiratori, "An Enhancement of the IEEE 802.11 MAC for multihop Ad hoc Networks", In: IEEE VTC, 5, p3020-3024, (2003).
• Taekon Kim, Hyungkeun Lee, Jang-Yeon Lee, and Jin-Woong Cho, "Cross-Layer Enhancement of IEEE 802.11 MAC for Mobile Ad Hoc Networks", ICCS LNCS, 4490, p482-489, (2007).
• L. Du, and L. Chen, "Receiver Initiated Network Allocation Vector Clearing Method in WLANs", APCC, p615-619, (2005).
• R. Gunasekaran, R. Sumitha, and U. V. Rhymend, "Throughput Enhancement in ad hoc Networks Using Virtual Carrier Sensing Mechanism", ICEIE, 1, p105-109, (2010).
• Inhye Park, and Hyungkeun Lee, "An Effective Method for Fairness in the Case of Missing CTS", ICHIT LNCS, 6935, p189-196, (2011).
• "NS2: The Network Simulator – ns-2", http://www.isi.edu/nsnam/ns/ [Accessed: 09. 01. 2017].