Exploiting EDCA for Feedback Channels in Hybrid VLC/WiFi Architectures

—In this paper, we consider integrating VLC and WiFi technologies in a scenario in which Light-Emitting-Diodes (LEDs), acting as network access points (APs) for ultra-dense Internet of Things applications, are deployed into an indoor lighting infrastructure. In such a scenario, RF-links can be exploited for complementing VLC-links in dealing with mobility and bidirectional communications, which can be problematic due to the limited coverage areas and self-generated interference of VLC APs. In particular, we consider the possibility of supporting a technology-based duplexing scheme, in which downlink and uplink transmissions are performed by means, respectively, of VLC and WiFi interfaces integrated into the same node. In order to fully exploit the VLC bandwidth in the presence of background WiFi trafﬁc and multiple coexisting VLC links, we discuss the importance of adopting a prioritization mechanism based on EDCA, as well as frame aggregation, for the uplink channel of the integrated architecture. Our considerations are corroborated by numerical results based on NS-3 simulations and a real simple experiment.


I. INTRODUCTION
In the last years, we have assisted to an impressive growth of capacity demand for wireless networks due to the proliferation of portable user devices and smart objects connected to the Internet. According to a recent Cisco report, mobile data traffic will account for 71% of Internet protocol traffic by 2022, in which more than 80% of mobile data traffic is generated in indoor spaces [1]. The rising demand for capacity, especially in indoor scenarios, overloads conventional RF-based technologies. Therefore, technologies working on advanced spectrum sharing solutions [2] [3], or innovative spectrum portions, such as millimeter waves (mmWave) and Visible Light Communications (VLCs), have been proposed as possible solutions. Among these, the VLC technology is a very promising alternative, explicitly considered in the design of 5G systems [4], [5], because it offers high bandwidth, immunity to interference from electromagnetic sources, and many possibilities for spatial reuse.
The up-taking of VLC communications is also due to the widespread adoption of Light-Emitting-Diodes (LEDs) for illumination. LED lights have several advantages compared with the traditional incandescent lamps, such as a 75% reduction of power consumption and 2500% increase in lifespan [6]. The market share of LED lighting is expected to rise with an annual growth rate of 13.4% from 2020 to 2027. Exploiting the LEDs deployed for illumination in order to modulate light signals and transmitting data is an exciting opportunity.
However, the design of an integrated illumination and data distribution infrastructure requires to solve some problems. The limited coverage area of VLC links, which enables highdensity spatial reuse, has the counter-effect of making node mobility management difficult. Another difficulty is due to the support of uplink channels because the light emitted for illumination purposes represents a high-power interference source for uplink signals. For this reason, uplink channels can be implemented by working on different spectrum portions, such as infrared signals [7] or RF signals [8].
Hybrid VLC and radio frequency (RF) systems have been proposed as state-of-the-art solutions to solve both the coverage and uplink transmission problems [9]- [11]. Several previous studies have applied hybrid VLC/RF connectivity schemes to improve the performance of both technologies [12]- [14]. In [9], an omni-directional RF link is integrated to multiple directional VLC links, for optimizing the downlink capacity under different network scenarios. A similar architecture is analyzed in [15], where the authors also focus on per-user rate performance. In general, the radio link is used as a backup channel, in case of VLC coverage holes, or as a feedback channel for VLC data and control information [8] (e.g., for sending signal strength reports to the transmitter).
In this paper, we focus on the limits of VLC/WiFi integrated architectures. In particular, we consider the possibility of supporting a technology-based duplexing scheme, in which downlink and uplink transmissions are performed, separately, on the VLC and WiFi interfaces deployed on the same node. Since WiFi links have a much wider coverage area than VLC ones, in the presence of high-density VLC links or other background WiFi traffic, the WiFi network may be congested. Congestion on the WiFi network, in turn, has an impact on the performance of the VLC links. More into detail, we consider a scenario in which VLC links are used for a reliable data transfer towards smart objects. We assume a congestion-control transport protocol such as TCP is used for data transfers. With this assumption, TCP acknowledgements are sent in uplink on the WiFi network and can result in a bottleneck for the whole integrated system. We then discuss some possible solutions for increasing the network capacity available for the WiFi feedback channel of the VLC nodes. The benefits of the proposed approach are shown by means of NS-3 simulations and a simple experiment.
The remainder of this paper is organized as follows. In Section II, we present our reference network scenario and some motivations for our work. In Section III, we discuss how the design of an integrated VLC/WiFi system creates some coupling effects between the performances perceived in both the VLC and WiFi network segments; we also introduce the channel access mechanisms which can be exploited for providing a feedback channel to VLC communications. Section IV provides numerical results obtained using NS-3 simulations and some preliminary experimental tests. Finally, conclusions are drawn in Section V.

II. SCENARIO AND MOTIVATIONS
This section describes our reference scenario for a hybrid VLC/WiFi network architecture and the scalability issues due to the usage of WiFi technology for implementing the uplink feedback channel.

A. Hybrid VLC/WiFi network architecture
We assume that an integrated VLC/WiFi network is available in an indoor space, where VLC Access Points are embedded into the ceiling lamps of the illumination infrastructure and connected, together with WiFi Access Points, to a local area network. Therefore, the indoor space is covered by multiple Access Points employing both the VLC and WiFi technology for supporting high-density terminal nodes. The configuration of each AP, in terms of physical and access layer parameters, as well as the configuration of the internal routes, are decided by a centralized controller called Intelligent Control Unit. In a similar fashion to what reported in [9], we assume that each VLC receiver also features a WiFi device, which is used for uplink transmissions. In case the VLC receivers are downloading data from the VLC APs, the common WiFi interface provides a feedback channel for the VLC connections.
The Intelligent Control Unit is the central controller, where all decisions about network configurations are taken based on network conditions and other variable channel factors. Indeed, network performances can be optimized by opportunistically adapting the WiFi contention parameters and operating channels as a function of the network load. Moreover, the usage of a central controller simplifies the mobility management: while static nodes can exploit the high-bandwidth VLC links for downloading data, highly dynamic nodes can be switched to the WiFi network to avoid service interruptions due to frequent handovers. Figure 1 shows a schematic view of our reference network architecture. For simplicity, we assume that each lamp available on the illumination infrastructure is serving one mobile node. Each VLC link is unidirectional, from a VLC AP to a mobile node also called VLC receiver, and it is labeled with a progressive identifier. No interference is generated between one VLC link and its neighbors. VLC receivers perform uplink transmissions towards the network infrastructure by means of the WiFi interface. A single WiFi Access Point covers the whole environment, where other (single-interface) WiFi nodes may be present.

B. Congestion impact on inter-technology performance
In our reference scenario, mobile nodes receive and transmit data by means of two different technologies, thus introducing some coupling effects between the performance of the coexisting VLC and WiFi networks. In particular, it is evident that uplink WiFi transmissions performed by neighbor mobile nodes may interfere with each other, while downlink VLC transmissions are orthogonal. Since most applications generate bidirectional traffic flows, even when the dominant flow is in the downlink, it is important to understand in which conditions the WiFi network can act as a bottleneck for the whole system. In particular, we consider the case in which mobile nodes are involved in a file download from the network, by using the TCP transport protocol. All the TCP acknowledgements generated by each VLC link contend in the same WiFi network. Therefore, the number of coexisting VLC links cannot be arbitrarily large, because the delays and losses of TCP acknowledgements will force VLC transmitters to reduce their transmission rate. Moreover, in presence of background WiFi traffic, the rate reduction due to TCP congestion control can occur even in presence of a single VLC link.
In order to demonstrate the impact of such a phenomenon, we ran a simple experiment in our lab at the University of Palermo by using the OpenVLC platform for implementing the VLC link. OpenVLC is an open-source, flexible, and low-cost VLC system [16] developed for testing innovative protocols exploiting the VLC technology. We implemented our mobile nodes on a Beaglebone Black (BBB), used as the embedded computer running the VLC access protocol and integrating a visible-light TX/RX front-end. The details on the hardware and software architecture are presented in [16]. We also integrated a WiFi interface on the same Beaglebone and configured the routing rules needed to send the uplink data through the WiFi interface. Although the OpenVLC interface can achieve a maximum throughput of 400 kbps (much lower than state-of-art VLC data rates), we were able to reproduce the above mentioned phenomenon by tuning the WiFi data rate to a fixed value of 6 Mbps.
In figure 2, the blue line shows the TCP throughput of the OpenVLC link configured between one node acting as VLC Access Point and one node acting as a mobile node, when the number of coexisting WiFi nodes varies from 0 to 5. VLC packets have a fixed size of 1500 bytes. Each coexisting WiFi node generates an UDP traffic flow towards the common WiFi Access Point at a source rate of 800 kbps. Packets are transmitted with a physical transmission rate of 6 Mbps. From the figure, we can observe that, when no coexisting WiFi node is active, the VLC link achieves a maximum rate slightly lower than 400 kbps. As the congestion level on the WiFi network increases, due to the activation of multiple WiFi nodes, such a throughput is progressively reduced down to almost zero (when 5 nodes are active). This happens despite the fact that the uplink traffic flow generated by the VLC receiver has a maximum rate of about 10 kbps (by considering that each TCP data frame will generate one acknowledgment, whose size is 40 bytes only). The figure also reports the observed minimum and maximum values for our experimental results, observed when repeating the experiments five times. The red line in figure 2 shows the performance achieved when the TCP acks are transmitted with a priority mechanism, as described in the following section.

III. INCREASING CAPACITY OF VLC FEEDBACK CHANNELS
This section presents some possible solutions for avoiding that the WiFi network will act as a bottleneck for multiple orthogonal VLC links. The idea is exploiting the EDCA access categories to prioritize the uplink data traffic generated by the VLC links, as well as frame aggregation for sending multiple TCP acknowledgements in a single channel access.

A. Priority on channel access and frame aggregation
In order to arbitrate the access to the shared wireless medium, WiFi nodes employ a random access mechanism based on the well-known EDCA protocol. Stations with frames to transmit start the carrier sense procedure and check whether the channel is available or busy. If the channel is sensed as idle for an arbitration inter-frame space (AIFS) interval, which depends on the access category of the pending frame, stations can transmit. Otherwise, a random backoff counter is extracted in a range called contention window, whose minimum (CW min ) and maximum (CW max ) values also depend on the access category. The backoff counter is decremented when the channel is idle and frozen when it is busy, until it reaches a value equal to zero. Only at this time, the station can attempt a channel transmission. Contention windows are doubled when a transmission attempt fails (up to the maximum value) and reset to the minimum value in case of success. Therefore, the probability to access the channel depends on the AIFS interval and on the average contention window, because both the parameters affect the time required for resetting the backoff counter to zero.
Four different access categories, called background (AC BK), best-effort (AC BE), video (AC VI), and voice (AC VO), are defined in EDCA for giving different channel shares to traffic flows with heterogeneous requirements. The high priority classes (AC VO and AC VI) have a default AIFS value set to 2 backoff slots; moreover, they use small contention windows (CW min equal to 3 and 7, CW max equal to 7 and 15, respectively, for AC VO and AC VI). Both of the low priority classes use CW min = 15 and CW max = 1023; best-effort flows employ an AIFS value of 3 backoff slots, while background flows adopt an AIFS value of 7 backoff slots.
Once a station wins the contention and obtains a channel access grant, it can hold the channel for a time interval called transmission opportunity (TXOP). In case the duration of the transmission opportunity exceeds a frame transmission time, multiple frames can be transmitted in the same channel access, with the possibility of using per-frame or cumulative acknowledgements. This mechanism allows to improve the channel utilization efficiency and to equalize the channel holding times of stations employing heterogeneous data rates or frame sizes. Another mechanism, introduced for improving the channel utilization efficiency in IEEE 802.11n and 802.11ac, is the usage of frame aggregation: multiple service data units sent by upper layers can be packed (up to a maximum size) and transmitted as a single frame [17]- [19]. This mechanism is suitable for the transmission of TCP acknowledgements, which are small in size and lead to significant MAC layer overheads when transmitted as independent frames.

B. EDCA-ACK: mapping TCP ACKs on AC VI
We propose to exploit EDCA prioritization mechanisms for the transmission of TCP acknowledgements (ACKs) generated by the VLC links. In particular, we propose to map these traffic flows to the priority class AC VI for two main reasons: i) reducing the access delays for TCP ACKs, and therefore the round trip time of TCP links, in order to fully exploit the capacity available on the VLC links; ii) enabling burst transmissions of multiple TCP acknowledgements within the AC VI transmission opportunity (whose default value is set to 3.01ms), thus reducing the number of contentions required by VLC nodes.
Indeed, although the bandwidth required by the TCP ACKs is a small fraction of the downlink VLC rate, the random access protocol of WiFi networks cannot guarantee the allocation of such a bandwidth. For analyzing the possibility of allocating the bandwidth required by the TCP ACKs, it is important to quantify the maximum possible channel share which can be allocated to VLC nodes when they are permanently in a contention state. Obviously, if the capacity demand of TCP ACKs is lower than the maximum possible share, other flows can grab the exceeding resources.
Consider the case in which each station has a single contending flow. Let M be the number of WiFi background nodes (i.e., greedy nodes requiring the maximum possible capacity) coexisting with N VLC receivers demanding s kbps on the WiFi network. These flows are originated by the TCP acknowledgements of the VLC links, and therefore s is proportional to the VLC link capacity. The total capacity C available on the WiFi network depends on: i) the total number of contending stations, which affects the amount of resources wasted because of channel idle intervals and collisions, ii) the channel holding times T WiFi and T VLC , experienced respectively by background WiFi nodes and VLC nodes. The maximum channel share x VLC available for each VLC node is given by T VLC /(M · T WiFi + N · T VLC ), which can be very penalizing in case each TCP ACK is transmitted in independent contentions (i.e. when T VLC is much smaller than T WiFi ). Whenever x VLC · C > s, in principle, the TCP ACK flows can be accommodated into the network. However, because of TCP congestion control, the ACK flow rate can be reduced to a value smaller than s, because of the delay jitters observed in the WiFi access network.
A priority scheme can be adopted for increasing the maximum share allocated to VLC nodes. Basically, if k is the ratio between the minimum contention window of background WiFi nodes and VLC receivers, the weight of the background WiFi nodes for deriving the VLC maximum share is approximately reduced by a factor equal to k, i.e.
x VLC = T VLC /(M/k · T WiFi + N · T VLC ). The capacity share of WiFi background nodes can be further reduced by increasing the AIFS value in comparison to the one used by VLC receivers. By assuming that background WiFi nodes employ the best effort access category, we propose to adopt the AC VI access priority for ensuring a good channel share to the TCP ACKs generated by VLC receivers. Indeed, AC VI employs smaller contention windows and AIFS values in comparison to AC BE value, and a transmission opportunity set to 3.01ms which makes possible the transmission of multiple TCP ACK frames in the channel access attempt. We call EDCA-ACK such a prioritization mechanism applied to the transmission of TCP ACKs.

IV. NUMERICAL RESULTS
In this section, we evaluate the performance of the integrated VLC/WiFi network, to see the impact of background WiFi nodes on VLC performance with and without EDCA-ACK or frame aggregation.

A. Simulation platform and setup
We used NS-3 for simulating our hybrid VLC/WiFi network. NS-3 is widely adopted for simulating the performance of large-scale networks. Moreover, it provides an extensive library with many standard network protocols and local access technologies, and an easy interface for defining the network topology. The configuration of each network node requires installation of protocol stacks and can mimic every aspect of real nodes. Several tools are included in the simulator for visualizing the behavior of the networks, debugging through analysis of the event log, and collecting results for performance evaluation. Figure 3 summarizes the simulation scenario created in NS-3. There are two types of nodes in the simulation: nodes employing only a single WiFi interface (STA 1 to STA M), and nodes integrating one WiFi and one VLC interface (VLC 1 to VLC N, also called VLC nodes). The first group of nodes will act as background traffic for studying the impact of WiFi congestion on the VLC links. Since NS-3 is lacking support for high-speed VLC simulation, we also employed WiFi links in order to emulate those. Specifically, we configured IEEE 802.11ac orthogonal channels with a fixed VHT MCS with a maximum measured throughput of 60 Mbps. The shared WiFi network is configured in infrastructure mode, with QoS support, and a physical layer based on 802.11a (configured with a fixed data rate of 6 Mbps). The reason for choosing a low data rate for the WiFi network is guaranteeing that  VLC data rates are one order of magnitude greater than WiFi ones, as expected in current state-of-art solutions (at different scales). The VLC-emulating access points were placed close to their respective mobile node (with no mobility model in this simulation), in order to guarantee high-quality channel conditions. Furthermore, all the STAs are placed at the same distance from the AP. Emulation of the simplex links was carried out by setting up static routes on the mobile nodes, so that the uplink data is forwarded through the common WiFi network. Regarding the contention parameters, we configured background nodes as belonging to the access category AC BE, while VLC nodes employ AC BE (with and without frame aggregation) or AC VI in different simulation scenarios. Other configuration parameters are listed in Table I.

B. Performance analysis of the VLC/WiFi integrated network
As a first simulation scenario, we considered a network topology similar to our simple experiment, with one VLC link and several greedy WiFi nodes in background. The downlink source rate of the VLC node is configured at 10Mbps, which is higher than the maximum rate currently supported by the OpenVLC prototype. At the maximum downlink rate, with a segment size equal to 1500 bytes, the uplink traffic flow due to TCP ACKs was measured to be approximately 190 kbps. Figure 4 shows the downlink throughput results (solid lines) obtained by the reference VLC node, as the number of background WiFi nodes M increases from 0 to 10, and under different options for the contention protocol. We used the flow monitor function in NS-3 to compute the throughput When the TCP ACKs are sent by using the same AC BE access category of the WiFi background nodes (blue line) without frame aggregation, the source rate of the VLC link cannot be sustained. One active WiFi background node is enough for observing a throughput reduction. If we also give a look to the uplink throughput (dashed lines, y-axis scale indicated on the right), we see a sudden reduction to 80 kbps with a number of background stations M equal to 1. Indeed, being TCP ACKs small in size, the channel share available for the VLC node is not enough for allocating a flow of 190 kbps. As a consequence, the TCP congestion control reacts by reducing the transmission rate on the VLC link.
In case we activate the frame aggregation option (green solid line), VLC links are able to work at the maximum rate up to a number of background stations M = 5. This happens despite the fact that the uplink throughput (green dashed line) is slightly lower than 190 kbps, thanks to the possibility of exploiting cumulative ACKs for tolerating some ACK losses.
Finally, when we set the AC VI priority for the TCP ACKs (red solid line), the reference VLC link works well up to M = 10 background nodes. For this access mode, we also observe that the uplink throughput (dashed line) is able to guarantee a rate of about 140 kbps for transmitting TCP ACKs, when M is in the range [5,10]. Note that the number of TCP ACKs which can be accommodated in a single transmission opportunity with the default AC VI settings is equal to 15, which is smaller than the number of TCP ACKs which can be aggregated in a MAC service data unit (A-MSDU) of 1500 byte. Therefore, the sustainability of the VLC downlink throughput is not only due to the improvement on channel utilization, but also on the channel access prioritization mechanism. Reducing the access delays and delay jitters improves TCP performance. Figure 5 shows the throughput results of our reference VLC node, in a new simulation scenario, in which a total number N = 4 of VLC links are active, together with a variable number M of WiFi background nodes. Again, we consider three different access modes: using the same access category of background WiFi nodes (blue curves), activating frame aggregation (green curves), exploiting EDCA prioritization (red curves). The behavior of the curves are similar to the previous scenario, although in such a case multiple TCP ACK   flows are contending simultaneously. Priority AC VI flows can be particularly sensitive to collisions in case of congestion generated by the same access category, because of the small contention window values used in contention. However, we want to remark that the rate of each uplink flow is a small percentage of the VLC link capacity, and therefore the WiFi network can accommodate several coexisting VLC links before saturating (indeed, for M = 0 our reference VLC link works at the maximum rate without using prioritization). As the number M of background node increases, the throughput degradation is more evident for the case in which TCP ACKs are transmitted using frame aggregation, while the usage of prioritization only leads to a throughput reduction of about 4% for the worst congested case M = 10. Figure 6 shows the end-to-end average delays of the TCP ACK flows, measured under the three different access modes considered in our study, and for both the scenarios of a single VLC link (solid line) and four VLC links (dashed lines). When TCP ACKs are mapped to the AC BE access category (blue and green lines), we observe that the increased congestion level due to VLC links has a minimal impact on the average delays (i.e. dashed and solid lines almost coincide). Conversely, when the TCP ACK flows are mapped to the AC VI access category, the performance degrade in presence of competing high priority flows (dashed red line). However, the prioritization mechanism allows to achieve access delays which are one order of magnitude smaller than Background throughput [Mbps] 1xVLC BK throughput 1xVLC w/EDCA BK throughput 1xVLC w/A-MSDU BK throughput 4xVLC BK throughput 4xVLC w/EDCA BK throughput 4xVLC w/A-MSDU BK throughput Fig. 7. Background STAs overall throughput the ones achieved when using AC BE and frame aggregation (red curves vs. green curves). Figure 7 shows the throughput achieved by the WiFi background nodes, in both the scenarios of a single VLC link (solid line) and four VLC links (dashed lines). As expected, the throughput reduction for WiFi background nodes is more evident in case the VLC links employ a prioritization mechanism (red curves), especially when multiple priority flows are active (dashed red curve).
Summarizing, our simulation results show that EDCA-ACK provides a standards compliant, reliable system, which improves the performance of the hybrid system we simulated. In order to better support our results, we added the EDCA AC VI priority class on the WiFi device used for the VLC return channel in the OpenVLC experiment reported in Fig.2. The measured throughput is presented by the red line in the figure, which shows how the system throughput exhibits a significant improvement.

V. CONCLUSIONS
In this paper, we have discussed how the random access protocol employed in WiFi networks can impair a hybrid VLC/WiFi communication system. Indeed, in case of congestion, channel access delays can suffer significant jitters, while the transmission of small feedback frames (such as the TCP ACKs) can significantly reduce the overall network capacity. To cope with these limitations, we analyzed the impact of different options available at the MAC layer on the performance of both VLC links and WiFi nodes.
Although the random nature of the WiFi access mechanisms does not allow to guarantee a fixed channel share to VLC feedback channels, several optimizations are possible. On one side, using frame aggregation (at the MAC service level) or enabling transmissions of TCP frames in bursts (within a single transmission opportunity) allows a dramatic reduction on the number of contentions required by the feedback traffic flows and an improvement of the channel utilization efficiency. On the other side, using a prioritization mechanism for TCP ACKs is important for optimizing the behavior of the TCP transport protocol, and therefore fully utilizing the VLC downlinks. We quantified the performance benefits which can be achieved on the VLC network segment, by using different options on the access protocol employed in the WiFi network segment, in several simulation scenarios and in a simple (small-scale) experiment.
Further investigations will involve the generalization of these results when both the VLC and WiFi network segments employ state-of-art data rates, as well as the analysis of solutions for allocating VLC feedback channels in presence of node mobility, competing high-priority flows, and multiple coexisting WiFi networks.