2. Fig. 1. An overview of wireless presentation system
The limitation of existing WPS is its inability to serve large number of audiences.
WPS systems found in the market today typically state their capacity of concurrently
connecting 32 or 64 client devices, but do not explicitly mentioned its maximum sup-
ported webview client size. This means it would be a challenge to employ existing
WPS in an auditorium or lecture hall scenario for distributing content to an audience
size of 150 and above.
In this paper, we describe an improved version of WPS, with an emphasis on the
mechanism used to distributing content to larger audience size along with perfor-
mance measurement. Our enhanced WPS (eWPS) runs on top of a Wi-Fi infrastruc-
ture which consists of multiple access points and network switch connected over a
wired gigabit Ethernet backhaul. It utilizes an external web server which receives
periodical screenshots from the eWPS and subsequently makes them accessible by the
audience web devices. As opposed to conducting simulation of large-scale Wi-Fi
based system as in [6], we approach the challenges with prototype implementation
over a testbed as in [7-8] for practical performance studies.
This paper is organized as follows. Related work is discussed in Section II. Section
III describes the experimental setups and the test configurations/flow. Section IV
explains on the performance results. Summary and conclusion are found in Section V.
2 Related works
A diversity of products and solutions can be found in the literature offering basic
features of a WPS. Some of these products even offer content sharing/distribution.
However, the number of supported client devices is below 64. Based on our latest
review, none of these products is designed to support larger scale of audience size.
3. Table 1 summarises the features of some prominent WPS found in the market and
their differences. Basic mirroring refers to the ability of a user device to capture and
stream screen/desktop activity to the connected display. Basic Webviewing means the
system is capable of distributing screenshots captured at the presenter/user device.
Advanced Webviewing goes beyond basic webviewing, by further allowing users to
navigate across all past/presented content. As an example, users who are late to the
session is now able to flip back to previously presented slides/content and later slip
forward to the current/latest screenshot content.
Table 1. Features comparison of WPS products or solutions against the proposed eWPS
Basic Mirroring Basic
Webviewing
Advanced
Webviewing
Wireless Projector [1] Yes No No
Chromecast [2] Yes No No
Barco Clickshare [3] Yes No No
Displaycast [4] Yes No No
wePresent [5] Yes Yes No
eWPS Yes Yes Yes
Wireless projector [1] is the most common and widely used product in the market.
Even though it is a self-contained device, it has many shortcomings. It is not a
straight-forward process for connecting laptops to the wireless projectors as each
brand comes with its own configuration and execution steps. In addition, they support
only basic mirroring and lacking of broadcasting presentation content to audience.
Chromecast [2], Barco Clickshare [3] and Displaycast [4] are standalone hardware
appliance/system which support only basic mirroring without any content sharing
capability. The wePresent system [5] is the few in the market which provides basic
webviewing capability. There is no product which supports advanced webviewing as
proposed in this paper.
The use of IP multicast on multimedia applications such as live lecture broadcasts
are increasingly being adopted in both enterprise and campus networks. It is therefore
a potential mechanism to be explored in the design of eWPS. However, multicast over
Wi-Fi suffers from various well-known problems such as low data rate, high losses
and unfairness against contending unicast transmission [9]. Moreover, not all Wi-Fi
access points support multicasting [9]. For the end client devices, customized applica-
tion will be needed to subscribe and receive these multicast packets. Our design is to
allow any user device which has a browser to work, without the need of any specific
application installation. Hence, in this paper, we utilized unicast instead of multicast
in our design and implementation of the current system.
4. 3 Experimental setup
3.1 Setup of Network Connectivity and Server
The eWPS system is designed with scalability in mind to ensure continuous support
for growing audience size. As shown in Fig. 2, the eWPS system is therefore divided
into two parts, namely the connectivity infrastructure section and the presentation
management section. The connectivity infrastructure section focuses mainly on man-
aging the networking aspect, from providing Wi-Fi accessibility, load balancing
across various Wi-Fi access points (AP) controlled by the Access Controller (AC), to
enabling Internet connectivity. There is no favour of any specific brand in our design,
as long as the chosen Wi-Fi access points are matched to their designated access con-
troller of the same brand/model. The presentation management section manages the
content capturing from the source device, to storing the content at the distribution
server (HTTP server) for accessibility by the end client devices over the connectivity
infrastructure described earlier. All the above devices, which include APs, AC, and
HTTP server are connected via a 1000 Mbps Ethernet switch in a local area network
(LAN) setup.
Fig. 2. Network architecture of eWPS consist of two parts, namely the connectivity infrastruc-
ture and the presentation management section.
Fig. 3 shows the layout of the auditorium measured 54’x40’ where our experiment
has been conducted. Commercially available network equipment from Huawei was
used to set up the connectivity infrastructure. There were a total of six units Huawei
access points (APs), and one unit of Huawei access controller (AC) [4]. Two APs
were located at the front of the auditorium, with the remaining four located at the rear
of the auditorium.
5. Fig. 3. Layout of the auditorium
All six APs have been configured to share a common SSID named
“Smart_Auditorium” on eight non-overlapping channels. These channels are 1, 6, 52,
56, 60, 64, 149, and 157. Six channels are on 5 GHz radio band, leaving only Chan-
nels 1 and 6 sitting on the 2.4 GHz radio band. The reason to allocate 2.4GHz serving
band was to serve older phones which may not support 5 GHz band. The AC is used
to perform load balancing/distribution, by directing different Wi-Fi stations (STAs),
which are the end client devices, to connect to different channels based on the radio
condition.
The distribution server runs on an Intel i5 micro-PC with 4GB Ram and 500GB
SATA hard disk. We have chosen such form factors and configuration for its light-
weight size to ease portability.
3.2 Test Event and Metrics
A test run has been conducted on an actual event, which last about 4 hours from 8:30
a.m.. The event was conducted as a workshop which introduces the use of a new mo-
bile app with general explanation followed by tutorial sessions. The flow of the work-
shop is as follow:
1. 8:30 a.m. – 10:45 a.m.: Welcoming speech
2. 10:45 a.m. – 12:15 p.m.: Slide presentation, app demonstration/hands-on
There were 15 and 52 pages of slides for the above session 1 and 2. Data from vari-
ous monitoring sources were collected for analysis. Both the radio lists and user lists
were obtained from the AC at periodic intervals throughout the session. Radio lists
provide detailed information of the wireless conditions and status of all connected
6. APs, which includes the link type, both uplink and downlink rate, number of
sent/received packets, retransmission rate and packet loss ratio etc. The glances [10]
monitoring tool was installed and ran on the distribution server to access/monitor the
system resource utilisation levels. The HTTP access log of the distribution server was
also used for studying the server performance, total number of accesses and server
resource utilization.
4 Results and Analysis
A total of 125 client devices were connected to the given SSID during the event. The
radio list recorded that 70 devices, which were 56% of the total have been connected
to more than one AP. This could be the effect of AC performing load balancing
among the APs. It could also be caused by certain STAs which left the venue and
rejoined the SSID at a later time.
Fig. 4 shows the distribution of stations by radio band. By referring to the flow of
the workshop in Section 3.2, the actual slide presentation is to start around 10:45 a.m.,
which corresponds to the sudden spike in Fig. 4. It can be observed that post 10:45
a.m., approximately 20+% of the stations were connected to the 2.4 GHz radio band
while the remaining 70+% of the users were connected to the 5 GHz radio band. It fit
in quite nicely to our frequency band allocation as described in Section 3.1 where 2
out of 8 frequency bands (25%) are at 2.4GHz.
Fig. 4. Distribution of STAs by radio band
Fig. 5 shows the distribution of stations by channel. It can be observed that the dis-
tribution for 2.4GHz is of an average difference of about 5 stations. Station distribu-
tion on 5GHz has a much bigger variance with channel 149 utilised by more 25 sta-
tions, while channel 60 was utilized by fewer than 5 stations. This could be due to the
7. seating location of the users, who could be closer to the AP configured to operate at
channel 149.
Fig. 5. Distribution of STAs by both 2.4 and 5GHz frequency channel
Fig. 6 shows the mean downlink negotiation rate of the stations by radio band. The
mean downlink negotiation rate for both 2.4 GHz and 5 GHz was 50 Mbps and 150
Mbps respectively. Again this downlink rate fit nicely to the initial configuration,
where 5GHz was used to handle most of the traffic load.
Fig. 6. Mean downlink negotiation rate by radio band
Fig. 7 shows both the total number of slide accesses and downloads. There was a
sudden rise in the number of webview clients at approximately 10:45 a.m.. This is the
starting time scheduled for the second event. The sudden surge on slide accesses cor-
responded to the sudden network load as seen in Fig. 4 and Fig 5. The sudden surge is
8. mainly caused by the instant connectivity requests from the audience immediately
after the proposed system has been introduced in the session.
The total number of slide accesses for the entire duration was 9273. Dividing this
by 1.5 hours (10:45 a.m. - 12:15 a.m.) results in about 1.71 HTTP requests/sec on
average. Each slide access HTTP request was successful performed, with positive
HTTP response status codes of 200 (OK), 206 (Partial Content), or 304 (Not Modi-
fied). The number of slides that users explicitly downloaded was 563. Again, all these
requests were successfully received and responded by our distribution HTTP server.
Fig. 7. Total number of content access for both direct access and downloads
Fig. 8 shows the number of webview clients. The maximum number of webview
clients recorded was 93. Given the total number of slide accesses for the entire dura-
tion was 9273, there was an average of 99 slide accesses per webview clients. Given
the total pages of slides for the entire session was 67, it shows the eWPS has even
captured and shared the animated details on certain slide pages, which made up of the
remaining 32 slide accesses.
Fig. 8. Total number of Webclients connected for content access
9. Fig. 9 shows both the CPU and memory utilisations of the HTTP server as record-
ed by the glances monitoring tool. We ignored the first peak utilization (at 20%)
which occurred at the start of the session because it was mainly caused by the loading
of the glances software itself. The second peak, which was around 12.5% would be a
correct representation of the actual CPU utilization of serving HTTP requests. This
corresponded to the time of 10:45 a.m. where there was a surge on the number of
webview clients.
As for the memory utilization, it was maintained below 5% throughout the session.
The chart in general shows that both the CPU and memory were very much idle
throughout the session. Based on such utilization, we foresee the system is capable of
serving 6 times more the workload as experienced in this current setup.
Fig. 9. CPU and memory utilization of the HTTP server
The mean access time (delay) for webview client was 1.74 ms for a maximum of
125 stations. This means the setup is capable of serving 1000 stations with an estimat-
ed average access time of 13.96 ms. Such good performance was due to a few rea-
sons. First, the backbone of the setup is on a 1000 Mbps Ethernet. Second is the use
of 6 Wi-Fi APs are overly sufficient for the client size. Further, the workload and
traffic of these 6 APs were centrally managed by AC. Lastly the size of the content
(i.e. size of screenshot images range from 300-500 KB) has been optimized for distri-
bution over network.
5 Conclusion
In this paper, an enhanced wireless presentation system which focuses on large-scale
content distribution has been presented. This system has made use of Wi-Fi APs as
the access infrastructure for end user devices/stations to request and receive presenta-
tion screenshots captured from the live presentation device. Results from our experi-
ments showed that the system was able to handle workload of an actual event with
good performance. Moving forward, we planned to investigate on the optimum num-
ber of APs which are needed to deliver content within an acceptable range of delay
intervals.
10. References
1. Wireless Projector, https://www.epson.com.my/Projectors/Epson-EB-1785W-Wireless-
WXGA-3LCD-Projector/p/V11H793052
2. Chromecast, https://store.google.com/product/chromecast_2015?srp=/product/chromecast
3. Barco Clickshare, https://www.barco.com/en/clickshare
4. Chandra, S., Rowe, L. A.: DisplayCast: A High Performance Screen Sharing System for In-
tranets. In: 20th ACM international conference on Multimedia (2012)
5. wePresent, https://www.barco.com/en/page/wepresent
6. Nekovee, M., Saksena, R. S.: Simulations of large-scale WiFi-based wireless networks: In-
terdisciplinary challenges and applications. In: Future Generation Computer Systems, vol.
26, no. 3, pp. 514-520 (2010)
7. Yiakoumis, Y., Bansal, M., Covington, A., Reijendam, J. V., Katti, S., Mckeown, N.: Be-
Hop: A Testbed for Dense Wifi Networks. In: ACM SIGMOBILE Mobile COmputing and
Communications Review, vol. 18, no. 3, pp. 71-80 (2014)
8. Adjih, C., Baccelli, E., Fleury, E., Harter, G., Mitton, N., Noel, T., Pissard-Gibollet, R.,
Saint-Marcel, F., Schreiner, G., Vandaele, J., Watteyne, T.: FIT IoT-LAB: A large scale
open experimental IoT testbed. In: IEEE 2nd World Forum on Internet of Things (WF-IoT),
Milan (2015)
9. Pace, P., Aloi, G.: WEVCast: Wireless eavesdropping video casting architecture to over-
come standard multicast transmission in Wi-Fi networks. J. of Telecommunication Systems
52(4), 2287--2297 (2013)
10. Glances - An eye on your system, https://github.com/nicolargo/glances