A Reliable Multicast MAC Protocol for Wi-Fi Direct 802.11 Networks

2015 European Conference on Networks and Communications (EuCNC)

A Reliable Multicast MAC Protocol for Wi-Fi Direct 802.11 Networks Gul Zameen Khan1, Ruben Gonzalez2, Eun-Chan Park3, Xin-Wen Wu4, 1,2,4

Department of Information and Communication Technology, Griffith University, Australia Department of Information and Communication Engineering, Dongguk University, Seoul, Korea [email protected], [email protected], [email protected], [email protected] 3

Abstract—Wi-Fi Direct is one of the most prevailing technologies in the field of wireless networking. With the advent of various useful applications, it is facing many challenges namely: efficient group formation/communication, power saving, compatibility issues etc. In this paper, we focus on the fundamental problem of reliability in multicast communication in the context of Wi-Fi Direct. To this end, our paper makes the following contributions: 1) It explores the problems of multicast in the context of Wi-Fi Direct. 2) It checks the performance of Standard Multicast(SM) and Leader Based Multicast (LBM) protocols for Wi-Fi Direct. 3) It presents an Enhanced Leader Based Multicast (ELBM) protocol for Wi-Fi Direct. The ELBM reduces collision and interference of multicast data transmission by improving channel access mechanism and selecting an optimal representative multicast receiver, therefore, it enhances the reliability of multicast transmission. We have tested the performance of all the three protocols through simulations. The simulation results show that the ELBM increases throughput of multicast transmission by up to two times compared to the existing mechanisms, as well as improving packet delivery ratio of multicast data. Keywords—Wi-Fi Direct; Collision; Interference

I.

Multicast;

MAC;

Reliablility;

INTRODUCTION

IEEE 802.11 standard [1] is one of the mostly useful and common network access technologies that has evolved tremendously in last decade. Just like other standards, Wi-Fi has introduced a number of amendments in order to cope with the challenges of a new technological era where Internet of Things (IoT) is in the early stage of evolution. Wi-Fi Direct [2] is one such innovative technology proposed by Wi-Fi Alliance that provides device to device connectivity. The WiFi Direct aims to provide easy, fast and seamless connectivity between devices in the absence of an Access Point (AP). A point-to-point connectivity is available in the original Wi-Fi standard in the guise of adhoc networks. However, it lacks device/service discovery and efficient power saving techniques. Similarly, Tunneled Direct Link Setup (TDLS) allows two WiFi devices to connect directly to each other [3]. Nevertheless, both the devices must be associated with the same AP. Wi-Fi Direct can have tremendously huge impact on the current as well future technology due to the following three reasons: 1) the number of devices that are equipped with Wi-Fi interface is increasing exponentially [4]. 2) Wi-Fi Direct is relatively cost effective and practical solution to offloading for cellular networks i.e. Wi-Fi in conjunction with 3G/4G/5G [5, 6] . 3) Wi-Fi Direct can be easily implemented in the legacy Wi-Fi devices without modifying the hardware. Because of

978-1-4673-7359-3/15/$31.00 ©2015 IEEE

these points, it has a wide range of applications, for example: sharing of data, image, and audio/video files; accessing network services; video games, proximity and location based services etc. The architecture of Wi-Fi Direct consists of a Group Owner (GO) and one or more clients. The GO should be a Wi-Fi Direct enabled or Peer to Peer (P2P) device. On the contrary, a client can be any legacy Wi-Fi device or P2P device1 [2]. Any Wi-Fi enabled device like laptop, tablet, mobile phone, printer, digital camera/camcorder, IPTV, and speaker can be a part of Wi-Fi Direct network. The devices first form a group and then communicate with each other. Multicast is the communication of one sender to a group of receivers in order to transmit the same content to all receivers at the same time. A tremendous amount of literature has explored multicast in standard Wi-Fi [7]. It is more beneficial than unicast transmission in terms of efficient use of bandwidth, less power consumption, and increased throughput. Multicast in WiFi Direct has several applications, for example: sharing of text, photos, audio and video files, messaging, exchanging data and control information in location based services etc. In spite of its countless benefits, there are many problems and challenges with multicast in Wi-Fi Direct namely reliability, efficiency and compatibility issues. A considerable amount of literature [8-15] has investigated the reliability of multicast protocol at MAC layer in standard WiFi. A Leader Based Protocol (LBP) that is based on Ready to Send (RTS) and Clear to Send (CTS) is proposed in [8] to provide reliability. The AP selects a leader among the multicast receivers and gets feedback from the leader. S. Gupta et al [9] propose a tone based approach to minimize the problem of collision of multiple CTSs in LBP. Likewise, Batch Mode Multicast MAC (BMMM) and Location Aware Multicast MAC (LAMM) are other protocols to reduce the collision because of hidden node problem [10]. In the same way, Beacon Leader Based Protocol (BLBP) sends a beacon frame before sending multicast data to guide the non-leader receivers by setting timers and receiving sequence number of the multicast data frame [11]. Chandra et al. [12] propose another technique called DirCast, where the AP transmits multicast data packet addressed to a unicast receiver while the others listen promiscuously. Another similar pseudo-broadcast method is proposed in [13] for receiving a multicast IPTV transmission from a common gateway to various set-top-boxes in different rooms. In [14], a Multicast Collision Prevention

224

1

A device that supports only standard Wi-Fi is called legacy Wi-Fi device while a device with Wi-Fi Direct capability is called P2P device.


(MCP) protocol is presented to reduce collision among unicast and multicast traffic. However the current algorithms cannot be straightforwardly used for Wi-Fi Direct networks due to the following two main reasons: 1) Multicast data in Wi-Fi Direct is transmitted by GO which is not necessarily the AP, while the conventional multicast mechanisms assume that only AP transmits multicast data. 2) Unlike AP, GO is not the central controller, thus its communication can not only be collided or interfered by other stations or AP in its range but it is also more prone to the hidden node problem. In light of the above discussion, it is therefore necessary to explore the multicast problem with respect to Wi-Fi Direct. In addition, it is also mandatory that new algorithms be proposed to achieve a higher level of reliability in Wi-Fi Direct. To meet these requirements and achieve the targeted goals, we present this paper. Our major contributions are summarized as follow:  We develop a simple Wi-Fi Direct multicast scenario to test the performance of SM and LBM protocols where a GO sends multicast data to its clients in the presence of other unicast stations that send unicast data to AP.  We propose a new protocol called ELBM that introduces three features to enhance reliability in the presence of AP and other unicast stations : 1) An enhanced RTS/CTS mechanism 2) An optimally chosen client for sending CTS 3) An efficient access mechanism for multicast transmitter i.e. GO Rest of the paper is organized as follows: We discuss our proposed protocol in Section II. Then we present the simulation results and discussions in Section III. II.

PROPOSED PROTOCOL FOR MULTICAST IN WI-FI DIRECT

In this section, we present our proposed algorithm i.e. ELBM protocol for Wi-Fi Direct. We assume that the group has already been formed. This can be achieved by any one of the three group formation techniques defined in [2]. Likewise, we do not put any constraints on other schemes that can help in efficient group formation. We assume that only one multicast group consisting of GO and its clients exists and that the multicast group shares the same channel with the AP and other unicast stations (referred to as USTAs). A. ELBM Protocol The protocol works as follows: 1. GO chooses one of its clients as representative client (CTS-R) for sending CTS using an optimal method. 2. GO sends RTS to CTS-R with an enhanced RTS/CTS scheme 3. CTS-R sends CTS to GO 4. GO sends multicast data with an improved access method It is worthwhile to note that there is no acknowledgment (ACK) transmission by any multicast receiver including CTSR. In order to improve reliability of multicast without resorting to any ACK mechanism, we introduce the following three features in ELBM: 1) Optimal selection of CTS-R 2) Improved Channel Access Mechanism 3) Enhanced RTS/CTS method

1) Optimal Selection of CTS-R The GO chooses a client as its CTS-R which is closest to the AP among all its clients in the multicast group. The rationale behind this is twofold: (i) it minimizes the interference of hidden nodes. (ii) it maximizes the effective coverage of CTS frame transmission. Most unicast stations in Basic Service Set (BSS) communicate with AP for most of time. We consider unicast stations communicate with AP for accessing internet, downloading a file, streaming multimedia files and so on. Since all the USTAs communicate with AP, a client who is closer to the AP can overhear more unicast transmission as compared to those clients which are far from AP. We want that client to be our CTS-R that can broadcast CTS to more USTAs to avoid collision or interference from them. We discuss later the underlying method for selecting the optimal CTS-R. 2) Improved Channel Access Mechanism When GO wants to send multicast data, it accesses the channel using Distributed Coordination Function (DCF) and then sends RTS to CTS-R. After sending RTS, GO enters into a wait state which ends after receiving CTS from CTS-R or ACK from USTAs/AP. If the transmissions of RTS and CTS succeed, the GO will send its multicast data. However, this will not be the case if the transmission of either RTS or CTS fails. Since all clients are synchronized with GO in multicast group, therefore an RTS packet sent by GO can only collide or interfere with data or control packets of AP or USTAs. Thus, when the RTS transmission fails, implying on-going transmission by other USTA or AP, the GO waits until the AP or USTAs complete the transmission. Here, we assume that the unicast transmission is performed without RTS/CTS exchange. Once this unicast transmission is successful, it will be followed by an ACK from AP or USTAs. Although this ACK packet is not destined to GO, the GO can decode this information from the header of the received packet. As soon as GO receives a CTS or ACK, it waits for SIFS interval and then transmits multicast data. 3) Enhanced RTS/CTS method The GO sends RTS and then waits for CTS or ACK before transmitting its multicast data. We loosly define two terms i.e. collisions and interference in the context of our algorithm. Collision When two or more stations that are in the transmission range of each other, access the channel at the same time, collision occurs. For example, when GO and USTA in Fig. 2 access the channel at the same time, their packets collide. In this case GO and USTA are not hidden to each other. Interference The hidden nodes cannot detect the transmission of each other, and they can transmit while the other node transmits, which is called as interference. For example, when GO and USTA are hidden nodes to each other as shown in Fig. 3 so that USTA cannot successfully decode RTS sent by GO and it sends its unicast data while CTS-R sends CTS. In this case, unicast data interferers with the transmission of CTS. Now we consider all possibilities that can happen. Note that there is no hidden node in case1 and 2, while USTA and GO are hidden nodes to each other in case 3 and 4 as follow below:

225


Case 1: Successful RTS and successful CTS It is the ideal case where GO sends RTS and CTS-R sends CTS successfully as shown in Fig. 1. Case 2: Unsuccessful RTS (Collision) When RTS collides with control or unicast data packet of AP or USTA, the GO does not resend RTS rather it waits for ACK from AP or USTAs. After detecting an ACK of unicast data, the GO sends its multicast after SIFS time without any additional back off time, which assures the transmission opportunity for the GO. This scenario is depicted in Fig. 2. Case 3: Successful RTS and Unsuccessful CTS (Interference) As shown in Fig. 3, it is possible that the transmission of CTS may fail due to the interference by the hidden USTA from the GO although the RTS is successfully transmitted. In this case, as similar to Case2, the GO sends its multicast data after detecting ACK from the AP, without retransmitting RTS. Case 4: Unsuccessful RTS or CTS (Collision or Interference) This is the case where GO competes with AP that transmits data to USTA as shown in Fig. 4. Thus USTA will send ACK to AP, but USTA is hidden to GO and GO cannot detect the termination of data. However, this does not make a serious problem because ACK is usually transmitted at the most robust modulation scheme and coding rate, so that even though GO cannot decode data sent by USTA but it can correctly decode ACK sent by USTA (with high probability).

In this way, ELBM effectively copes with collision and interference by USTAs and/or AP and assures the transmission opportunity of GO without significant overhead, which contributes to the reliability of multicast transmission by GO. Moreover, it is important to note that the ELBM protocol needs to be implemented only in the GO and it does not require any modification in the clients. Fig. 5 shows the overall flow of ELBM from the viewpoint of implementation. B. Distance of Client from AP In the ELBM protocol, the GO determines the CTS-R based on the distance between the AP and its clients. For this purpose, it can make use of many technique to estimate the distance of clients from the AP[16-18], e.g., Time of Arrival (TOA), Time Difference of Arrival (TDoA), or techniques based on Received Signal Strength Indicator (RSSI). In our algorithm, every client stores ToA, TDoA, or RSSI values from the beacon signal periodically transmitted by the AP, and sends this information to GO during the group formation method.

Fig. 4. A case where RTS or CTS is unsuccessful

Fig. 1. A case where both RTS and CTS are successful

Fig. 2. A case where RTS is unsuccessful

Fig. 3. A case where RTS is successful but CTS is unsuccessful

Fig. 5. Flow chart of ELBM protocol at GO

226


III.

SIMULATION

A. System Model We evaluate the performance of our proposed algorithm with the help of a time driven simulator that we have developed in matlab. It models DCF 802.11 with the MAC and PHY parameters listed in Table 1 [19]. The simulation time is set to 1 million time slots. To test the validity of our algorithm, we consider a simple scenrio that covers the basic cases as shown in Fig. 6. We have run each simulation 20 times and then taken the average. Table 1. Simulation parameters Parameters Packet Payload MAC Header PHY Header SIFS Transmission Rate of Data Packets Transmission Rate of Control Packets Transmission Time of Multicast Packet

Values

Parameters

Values

8184 bits 272 bits 128 bits 28 µs

DIFS CWmin CWmax Slot time

12 Mbps

ACK Frame

6 Mbps

RTS Frame

715 µs

CTS Frame

128 µs 32 1024 50 µs 112 bits + PHY Header 160 bits + PHY Header 112 bits + PHY Header

Network Topology

90 USTA-2 80

CTS-R Client

70

y-axis(m)

60 AP

50

Client GO

40 30 20

USTA-1

10 0

0

10

20

30

40

50 60 x-axis(m)

70

Fig. 6. Test case scenario

80

90

100

Pi 

Ni N total,i

2) Throughput Throughput is the number of bits transmitted successfully in a given time. The individual throughput, Si of a station i is: Si 

B. Test Case Scenario Description Our standard test case consists of one AP, one GO, two P2P clients, and two USTAs (USTA-1, USTA-2) in a single BSS as shown in Fig. 6. Later on, we add more USTAs shown as asterisks in Fig. 6. The USTAs send unicast data to AP while GO sends multicast data to clients. All unicast transmissions use standard DCF 802.11 to access the channel while multicast transmission uses three methods namely SM [1], LBM [8] and ELBM to access the channel. The GO and clients do not participate in unicast transmission. Similary, AP and USTAs do not participate in multicast transmission. However, unicast and multicast transmissions share the same channel, therefore both collision and interference can occur between unicast and unicast or unicast and multicast trnsmissions. For the sake of simplicity, we consider saturated unicast and multicast transmissions i.e USTAs and GO always have data to send. All stations are deployed in a square of area 100x100 m2. The transmission range of each station is 50 m and it follows a tworay ground propagation model with omni directional antenna. In Fig. 6, the transmission ranges of AP, GO and CTS-R are shown by solid, dotted and dashed lines respectively. AP is located at the centre of the square. Note that USTA-2 is a hidden node to GO, while USTA-1 is not. 100

C. Results and Discussions We use the following performance metrics to validate the performance of our protocol: 1) Packet Delivery Ratio(PDR) The packet delivery ratio of station i, Pi, is defined as the ratio of the number of packets delivered successfully (Ni) to the number of total packets sent by station i (Ntotal,i), i.e.

Ni  L T

where L = length of the packet (bits), T = Total time(sec) We calculate multicast PDR and throughput of GO and average PDR and unicast throughput of USTA-1 and USTA-2 to measure the gain and loss of our algorithm. As shown in Fig. 7, PDR of multciast data is 90% for SM, 95% for LBM and 100% for ELBM. This is because of different levels of collisions and interference for the three protocols. In case of SM, multicast packet of GO can be collided as well interefered with unicast packets of USTA-1 and USTA-2 respectively. On the other hand, collision is reduced in case of LBM, however, a hidden node like USTA-2 causes interference. Therefore PDR of LBM is partially improved. On the contrary, ELBM minimizes both collision and interference of unicast data with multicast data. Thus ELBM outperforms both SM and LBM. We observe a similar trend in case of multicast throughput as shown in Fig. 8. Multicast throughput of ELBM is increased by about 72% and 45% compared to that of SM and LBM respectively. This is due to reducing multicast collision, minimizing interference of hidden node, and decreasing the effects of RTS/CTS collision. We also investigate the effects of our proposed method on unicast data. As Fig. 7 shows, the average PDR of USTAs is 76.5% for SM, 74.5% for LBM and 75.5% for ELBM. A similar trend can be seen for unicast throughput of USTA-1 and USTA-2 as shown in Fig. 8. The reason for this tradeoff in ELBM and SM is the addition of RTS/CTS in case of ELBM. However, a comparison between the gain and loss in terms of PDR and throughput shows improvement. ELBM achieves 10% gain for multicast PDR at the cost of 2% loss in unicast PDR as compared to SM. Likewise, it achieves 72% gain in multicast throughput and about 10% loss in unicast throughput as compared to SM. In addition, ELBM outperforms LBM in terms of both PDR and throughput of both multicast and unicast transmisssions. We repeated the simulation with different number of USTAs such that the number of USTA1 is equal to that of USTA2 as shown in Fig. 6 by asterisks. Note that USTA1 refers to those USTAs that are not hidden nodes to GO while USTA2 refers to those USTAs that are hidden to GO. As shown in Fig. 9, multicast throughput decreases as the number of USTAs increases for all protocols however the rate is much lower for ELBM as compared to SM and LBM. The multicast

227


throughput of ELBM is higher by almost double and 1.8 times than those of SM and LBM respectively. Lastly, we show the advantages of ELBM over LBM in terms of overhead. As Table 2 illustrates, percent PDR of RTS/CTS of ELBM is greater than that of LBM due to enhanced RTS/CTS method and optimal selection of CTS-R for ELBM.

IV. CONCLUSION In this paper, we have investigated the problem of reliable multicast for Wi-Fi Direct and proposed a new algorithm called ELBM. ELBM improves reliability by reducing collision and interference from AP and other stations due to an improved access method, optimal CTS-R selection and enhanced RTS/CTS mechanism. The simulation results show better PDR and improved throughput for ELBM as compared to SM and LBM. REFERENCES

Fig. 7. PDR of multicast packets at GO and unicast packets at USTAs

Fig. 8. Multicast throughput of GO and unicast throughput of unicast stations

Fig. 9. Multicast throughput of GO with respect to increase of USTAs Table 2. % PDR of RTS/CTS for LBM and ELBM # of USTA1 + USTA2 2 4 6 8 10 12

% PDR of RTS Packets LBM ELBM 96.52 96.86 92.60 93.67 89.29 90.19 78.88 80.22 77.25 79.64 75.60 78.88

% PDR of CTS Packets LBM ELBM 99.69 100 99.57 99.98 99.06 99.93 98.60 99.80 98.57 99.74 97.90 98.89

[1] “IEEE Standard for Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specs,” Tech. Rep., June Std. 802.11-2007. [2] Wi-Fi Alliance, P2P Technical Group, Wi-Fi Peer-to-Peer (P2P) Technical Specification v1.0, Dec. 2009. [3] IEEE 802.11z-2010 —Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 7: Extensions to Direct-Link Setup (DLS). [4] WiFi Annual Report 2013, Dec 2013, p. 1-20. [Online]www.nxtbook.com /nxtbooks/wifi/annualreport2013_public/index.php [5] J Lee, Y Yi, S Chong, J Youngmi, "Economics of WiFi Offloading: Trading Delay for Cellular Capacity," IEEE Transactions on Wireless Communications, 2014, vol. 13, no. 3, p. 1540-1554. [6] A. Pyattaev, K. Johnsson, S. Andreev, and Y. Koucheryavy, “3GPP LTE traffic offloading onto WiFi direct,” in Proc. of the IEEE Wireless Communications and Networking Conference, 2013. [7] Vella, J. and S. Zammit, "A Survey of Multicasting over Wireless Access Networks," IEEE Communications Surveys & Tutorials, 2013, vol. 15, no. 2, p. 718-753. [8] J. Kuri and S. Kasera, “Reliable multicast in multi-access wireless LANs,” in Proc. the 18th Annual Joint Conference of the IEEE Computer and Communications Societies, (INFOCOM’99), vol. 2,Mar. 1999, pp. 760–767. [9] S. Gupta, V. Shankar, and S. Lalwani, “Reliable multicast MAC protocol for wireless LANs,” in Proc. IEEE International Conference on Communications, (ICC’03), vol. 1, May 2003, pp. 93–97. [10] M.-T. Sun, L. Huang, A. Arora, and T.-H. Lai, “Reliable MAC layer multicast in IEEE 802.11 wireless networks,” in Proc. International Conference on Parallel Processing, (ICPP’02), Aug. 2002, pp. 527–536. [11] Z. Li and T. Herfet, “Beacon-driven leader based protocol over a GE channel for MAC layer multicast error control,” International Journal of Communications, Network and System Services, pp. 144–153, Jun. 2008. [12] R. Chandra, S. Karanth, T. Moscibroda, V. Navda, J. Padhye, R. Ramjee, and L. Ravindranath, “Dircast: A practical and efficient Wi-Fi multicast system,” in Proc. 17th IEEE International Conference on Network Protocols, (ICNP’09), Oct. 2009, pp. 161–170. [13] Y. Park, C. Jo, S. Yun, and H. Kim, “Multi-room IPTV delivery through pseudo-broadcast over IEEE 802.11 links,” in Proc. IEEE 71st Vehicular Technology Conference (VTC-Spring’10), May 2010, pp. 1–5. [14] M. Santos, J. Villalón and L. Orozco-Barbosa, "Multicast Collision Free (MCF) Mechanism over IEEE 802.11 WLANs", WMNC, October 2010. [15] N. Choi, Y. Seok, T. Kwon, Y. Choi, Multicasting multimedia streams in IEEE 802.11 networks: a focus on reliability and rate adaptation, Wireless Networks archive, Volume 17 Issue 1, January 2011. [16] P. Bahl and V. N. Padmanabhan,”Radar: An In-Building RF-Based UserLocation and Tracking System", Proc. IEEE INFOCOM 2000, vol. 2, pp.775 -784 2000 [17] S. Saha, K. Chaudhuri, D. Sanghi, and P. Bhagwat. Location determination of a mobile device using IEEE 802.11 access point signals. In IEEE Wireless Communications and Networking Conference (WCNC), pages 1987–1992, New Orleans, LA, March 2003. [18] Y. T. Chan, W. Y. Tsui, H. C. So and P. C. Ching "Time of arrival based localizatoin under NLOS conditions", IEEE Trans. Veh. Technol., vol. 55, pp.17 -24 2006 [19] G. Bianchi, "Performance analysis of the IEEE 802.11 distributed coordination function", IEEE J. Sel. Areas Commun., vol. 18, no. 3, pp.535 -547 2000.

228