.

1. An Analysis of a Large Scale Wireless Image
Distribution System Deployment
Gin Xian, Kok
Wireless Innovation Lab
Corporate Technology,
MIMOS Berhad
Kuala Lumpur, Malaysia
gx.kok@mimos.my
Khong Neng, Choong
Wireless Innovation Lab
Corporate Technology,
MIMOS Berhad
Kuala Lumpur, Malaysia
kn.choong@mimos.my
Chrishanton V
Wireless Innovation Lab
Corporate Technology,
MIMOS Berhad
Kuala Lumpur, Malaysia
chrishanton.v@mimos.my
Yasunori Owada
Applications Laboratory,
Resilient ICT Research
Center, Social Innovation
Unit, Open Innovation
Promotion Headquaters,
NICT, Japan
yowada@nict.go.jp
Goshi Sato,
Applications Laboratory,
Resilient ICT Research
Center, Social Innovation
Unit, Open Innovation
Promotion Headquaters,
NICT, Japan
sato_g@nict.go.jp
Abstract—In this paper, we describe two setups of a wireless
image distribution system using different network
architectures. In the first setup, commercial grade network
equipment was used in the network infrastructure of the system.
In the other setup, the network infrastructure consists of a
wireless mesh of NICT NerveNet nodes. For the first setup,
results showed that the choice of hardware and network
equipment used were sufficient to support the load of the system
in an auditorium with a capacity of about 160 people. For the
NerveNet setup, it superseded the first setup in terms of quick
and clean setup, leaving the performance aspect to be further
improved.
Keywords—wireless presentation system, wireless image
distribution, log analysis, data analytics, Wi-Fi, wireless
I. INTRODUCTION
Presentations are held in a variety of places and serve as a
platform for sharing information with a group of people. The
places they are held at can range from a small meeting room
with a capacity of eight to ten people, to a much larger place
such as an auditorium with capacity exceeding 3000 people in
some of the largest auditoriums in the world.
Fig. 1 shows a wireless presentation system. The wireless
presentation box acts as a Wi-Fi access point, allowing the
presenter device (laptop) to connect to it for streaming its
desktop to a large screen display such as a TV or projector.
Fig. 1: Wireless presentation system
In most presentations, the presentation materials are in the
form of Microsoft PowerPoint (PPT) slides or Adobe PDF
pages. Often, the audiences find it useful to obtain such
presentation materials. For one, it allows them to review the
presentation materials at a later time and instead place more
focus on the on-going presentation. There is also the
possibility that participants could be seated at suboptimal
locations and thus cannot see the display clearly. With this in
mind, a web application can be built whereby a screen capture
software is placed in the wireless presentation box to capture
the presented screen and distribute it to the audiences over
WiFi onto their personal computing devices such as laptop,
smartphone, or tablet. We refer to this feature as webviewing
and a user using this feature a webview client. In Fig. 1, the
five mobile devices correspond to the webview clients.
In this paper, we detailed two setups of such a system and
their test runs. The first setup operates on top of a Wi-Fi
network architecture using commercially-available network
equipment connected over a wired gigabit Ethernet backhaul.
The second setup operates on top of a wireless mesh network
consisting of wireless mesh nodes with Wi-Fi backhaul links.
The use of wireless mesh network is to achieve portability and
enable quick/clean setup, without the hassle of laying long
distance cables. The choice of having two setups is partly for
studying and evaluating available heterogeneous network
technologies for the smart community and smart city
applications, which is a project funded by NICT ASEAN IVO.
This paper is organized as follows. Related work is
reviewed in Section II. Detailed descriptions of the two
proposed setups are provided in Section III. Section IV
focuses the results and discussion. Finally, we provide
summary and conclude in Section V.
II. RELATED WORK
Most research in wireless networks are based on
simulations. In [1], computational and algorithmic challenges
of high-fidelity simulations of Wi-Fi-based wireless
communication and computing networks are reviewed.
Besides simulations, several testbeds have been setup for
wireless networks research. In [2], a wireless testbed for dense
Wi-Fi networks is presented which aims to provide insights on
operation of dense deployments and evaluate how different
Wi-Fi management strategies affect user experience and
network behavior. In [3], an open testbed composed of 2728
low-power wireless nodes and 116 mobile robots for
experimenting with large-scale wireless Internet-of-Things
(IoT) technologies is described. None of them conducted test
which meets the usage scenario of our system.
Wireless
presentation box
presenter
webview clients

2. III. DESIGN AND SETUP
A. Setup with Commercial Network Equipments
In this setup, commercially available network equipment
are used. More specifically, six Huawei access points (APs),
and one Huawei AC6605 [4] access controller (AC) were
used. Four APs are located at the rear of the auditorium, while
the remainder two APs are located in front of the auditorium
just in front of the stage. These six APs broadcast a single
SSID called “Smart_Auditorium” on eight non-overlapping
channels, i.e., 1, 6, 52, 56, 60, 64, 149, and 157. Channels 1
and 6 are on the 2.4 GHz radio band, while the other channels
are on the 5 GHz radio band. The AC is setup to load balance
the Wi-Fi stations (STAs) to connect to different channels.
The APs, AC, and HTTP server are interconnected within a
local area network (LAN) through a 1000 Mbps Ethernet
switch. This setup is as illustrated in Fig. 2. The auditorium is
located at MIMOS Berhad, Technology Park Malaysia, Kuala
Lumpur, Malaysia and have a seating capacity of 159.
Fig. 2: Auditorium setup using commercial network equipment
B. NerveNet Setup
The NerveNet setup consists of a wireless mesh network
consisting of three NerveNet nodes [5], as shown in Fig. 3.
The nodes are labeled nodes 13, 14, and 15. Node 13 was
designated as the front hotspot, node 15 as the rear left hotspot,
and node 14 as the rear right hotspot. The wireless
presentation box is connected to node 13 using Ethernet. The
inter-node (backhaul) wireless links (13, 14), (14, 15), and
(15, 13) operate on the 5 GHz radio band on channels 36, 40,
and 44, respectively. Each of these nodes also has an access
side Wi-Fi AP running on the 2.4 GHz radio band to allow
users to connect to the network. The access side APs on nodes
13, 14, and 15 were operating on channels 6, 1, and 11,
respectively. The purpose of using a wireless mesh network
are: i) enhanced reliability as there could be multiple paths
between any two nodes, and ii) ease of setup due to wireless
links between nodes (cable-less).
Fig. 3: NerveNet setup
IV. RESULTS & DISCUSSION
A. Commercially Network Equipments Setup
For the commercial setup, a test run was conducted on an
actual conference session on 6th
September 2018. The event
started at 8:30 a.m. and ended at about 12:15 p.m. on the same
day. The purpose of the event is to introduce a mobile app and
give a tutorial on how to use it. The flow of the events is as
follow: i) 8.30 a.m. – 10.45. a.m: welcoming and introduction,
and ii) 10.45 a.m. – 12.15 p.m.: slide presentation, and app
demonstration and hands-on.
Data from various sources were collected for analysis.
More specifically, radio lists and user lists were obtained from
the access controller at periodic intervals throughout the entire
event. The glances [6] monitoring tool was installed and ran
on the image distribution HTTP server to provide the system
resource utilization levels throughout the event. Additionally,
the access log of the server is also used for analysis.
1) Wi-Fi
A total of 125 unique stations were connected to the SSID
in consideration during the event. Seventy or 56% of them
have been connected to more than one AP. This could be due
to load balancing actions performed by the access controller,
or the STAs could have left the venue at some time and
rejoined the SSID at a later time.
Fig. 4: Distribution of STAs by channel
Stage
Seats Seats Seats

3. Fig. 5: Distribution of STAs by radio band
Fig. 4 shows the distribution of stations by channel while
Fig. 5 shows the distribution of stations by radio band. From
Fig. 5, it can be observed that at steady state, approximately
20% of the stations were connected to the 2.4 GHz radio band
while the remaining 80% of the users were connected to the 5
GHz radio band. This is consistent with the capabilities of the
stations as can be seen in Fig. 6, which shows the distribution
of the stations by supported band.
Fig. 6: Distribution of STAs by supported radio band
Fig. 7 shows the distribution of the stations by IEEE
802.11 mode. 59.2% of the stations operated in the 802.11ac
mode, 8.8% in 802.11n mode while 16.8% in 802.11g mode.
It is interesting to see that most stations operated either in the
legacy 802.11g mode or the recent 802.11ac mode as only a
minority of the stations operated in 802.11n mode.
Fig. 7: Distribution of STAs by IEEE 802.11 mode
Fig. 8 shows the mean downlink negotiation rate of the
stations by radio band. The stations on 2.4 GHz obtained a
mean downlink negotiation rate of 50 Mbps while the STAs
on 5 GHz obtained a mean downlink negotiation rate of 150
Mbps.
Fig. 8: Mean downlink negotiation rate by radio band
Fig. 9 shows the distribution of the stations by their
duration they were connected to the SSID in consideration.
The stay duration of a station is defined as the difference
between the last and first times the station appeared on the user
list as reported by the access controller. The majority of the
participants have their devices connected to the SSID in
consideration between one to two hours. Few stations were
connected to the SSID for three hours or more. We believe
that the long staying stations are devices belonging to the
conference committee personals such as technical support
people and presenters.
Fig. 9: Distribution of STAs by stay duration
2) Webview clients
Fig. 10: Webview client count, slide accesses, and slide downloads

4. Fig. 10 shows the number of webview clients, slide
accesses, and slide downloads during the course of the event.
The peak number of webview clients was 93. From the figure,
it can been observed that there was a sudden rise in the number
of webview clients at approximately 10:45 a.m.. This time is
consistent with the sudden rise in the number of stations as can
been seen in Fig. 4 and Fig. 5. The reason for this sudden
increase is because at this time, the audiences were introduced
to the proposed system and were encouraged to use the
app/system to for better user experience.
The number of slide accesses for the entire duration is
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. All of the
slide access HTTP requests were successful, i.e., they have
HTTP response status codes of 200 (OK), 206 (Partial
Content), or 304 (Not Modified).
The number of slides that users explicitly downloaded is
563. All of those HTTP requests were also successful, i.e.,
have HTTP response code of 200 (OK).
Fig. 11 shows the distribution of the webview clients by
their stay duration. The stay duration is defined as the
difference between the last and first times a webview client’s
IP address appeared in the image HTTP server access log.
Fifty four of the webview clients used the system between 0
and 30 minutes, 25 webview clients used the system between
30 and 60 minutes, and 25 webview clients used the system
between 1 and 1.5 hours. The mean and standard deviation of
the webview clients stay duration is 43 minutes and 3 seconds,
and 33 minutes and 39 seconds, respectively. The median of
the stay duration is 32 minutes and 56 seconds. This means
that 50% of the webview clients used the system for less than
32 minutes and 56 seconds, or less. The reason for the
shortlived interest in the system is suspected to be because the
presentation is about training of a mobile app which requires
the participants to try the app on their personal devices (Apple
iPhones or Android smartphones). When they are doing so,
they may no longer keep the webview browser app in their
foreground, or they close the browser entirely, thereby ending
their webview sessions.
Fig. 11: Distribution of webview clients by stay duration
3) HTTP server resource utilization
Fig. 12 shows the CPU and memory utilizations of the
HTTP server as recorded by the glances monitoring tool. We
found that the CPU utilization is high when glances is first
started, which could be due to the software performing various
initialization functions.
Fig. 12: CPU and memory utilization of HTTP server
The chart shows that the neither the CPU utilization nor
the memory utilization reached to a critical level and this
suggests that the server has additional headroom to support
more webview clients.
B. NICT NerveNet Setup
For the NerveNet setup, a test run of the system was
conducted on 22th October 2018 at a lecture hall in a local
university at about 8 p.m.. Custom software was installed on
the NerveNet nodes for data collection. Again, the glances
monitoring tool was used for monitoring the system resource
utilization of the NerveNet nodes.
Fig. 13 shows the number of stations connected to the
different NerveNet nodes. The combined total number of
stations peaked at 79 at about 8:21 p.m.. Specific instructions
were given to the audience to connect to the different
NerveNet nodes based on their classroom seating locations.
From the figure, it can be seen that the front center NerveNet
node, i.e., node 13 hosted the most stations and a roughly
equal amount of stations were hosted by the rear left and rear
right NerveNet nodes, i.e., nodes 15 and 14, respectively.
Fig. 13: Number of stations connected to different NerveNet nodes

5. Fig. 14: Receive & transmit bitrate on backhaul link (13, 14)
Fig. 14, Fig. 15, and Fig. 16 show the receive and transmit
bitrates on links (13, 14), (14, 15), and (15, 13), respectively.
Fig. 15: Receive & transmit bitrate on backhaul link (14, 15)
Fig. 16: Receive & transmit bitrate on backhaul link (15, 13)
Fig. 17 shows the packet failure rate on the NerveNet
backhaul links (13, 14), (14, 15), and (15, 13). From the figure,
we found two peaks at about 7.59 p.m. and 8.17 p.m.,
respectively. The packet failure rates at these peaks were
13.3% and 20%, respectively. Otherwise, packet failure rates
remained quite low.
Fig. 17: Packet failure rate on backhaul links
Fig. 18 shows the average signal power of the NerveNet
backhaul links. The time-average signal power is -47.5 dBm,
-50 dBm, and -64 dBm, for links (15, 13), (13, 14), and (14,
15), respectively.
Fig. 18: Average signal power of backhaul links
Fig. 19 shows the connected times of the NerveNet
backhaul links. From the figure, it can be observed that link
(13, 14) was broken and auto-reconnected once. Meanwhile,
links (14, 15) and (15, 13) were less stable as they
disconnected and auto-reconnected four and three times,
respectively. This is in agreement as the average signal power
for the links as link (14, 15) has the lowest average signal
power of all the links as shown in Fig. 18 and are thus the least
stable of the three links.
Fig. 19: Connected time of backhaul links

6. Fig. 20 shows the CPU utilization on the NerveNet nodes.
The maximum CPU utilizations are 41.4%, 37.7%, and 40.4%
on nodes 13, 14, and 15, respectively. However, the CPU
utilization were quite low most of the time as can be seen from
the figure.
Fig. 20: CPU utilization on NerveNet nodes
Fig. 21 shows the memory usage on the NerveNet nodes.
Memory usage maxed at 8.2% for both nodes 13 and 14, and
8.4% respectively. This figure, and Fig. 20 show that the
hardware used were more than sufficient for our application
for a max crowd size of 79.
Fig. 21: Memory usage on NerveNet nodes
Table 1 shows the mean webview access time for the two
setups. It can be observed that the mean webview HTTP
request access time for setup 2 was much higher as compared
to setup 2 (NICT NerveNet setup). One possible reason of this
could be due to the network interface used on the access side
of the NerveNet nodes. The Wi-Fi network interfaces used on
this setup are consumer grade network interfaces on the IEEE
802.11n 150 Mbps standard. Further it operated in the 2.4 GHz
frequency channel which is widely used, and therefore
generally quite congested due to limited channel selection. On
the contrary, the APs in setup 1 are capable of supporting
IEEE 802.11ac, which operated in both 2.4GHz and 5 GHz,
serving at a much higher speed.
Table 1: Mean webview HTTP request access time
Setup Max Stations Mean Webview HTTP
Request Access Time
1 125 1.7456 ms
2 79 4.5 s
Besides the slow performance, a potential problem with
the NerveNet setup is the lack of automatic load balancing of
Wi-Fi stations. In our test run, the load balancing function was
performed manually by instructing participants to connect to
different NerveNet APs based on their seating location in the
hall. This could deter less determined participants from using
the system altogether. Therefore, more work is needed before
the NerveNet setup is ready for actual deployments.
V. CONCLUSION
In this paper, the setup and analysis of a wireless image
distribution system is detailed. We have two different setups
of the system and conducted two test runs, one for each setup.
The first setup were put to test during a training event at
MIMOS Berhad. The second setup was put to test at a lecture
hall in a local university. For the first setup, results from the
analysis performed on the collected data shows that the system
was able to handle the load of during the trial run. For the
second setup, the system performed well functionality.
However, it can still be improved upon in the performance and
usability aspects.
ACKNOWLEDGMENT
This work is the output of the ASEAN IVO
(http://www.nict.go.jp/en/asean_ivo/index.html) project titled
“Study and evaluation of heterogeneous network for smart
community and smart city applications” and financially
supported by NICT (http://www.nict.go.jp/en/index.html).
REFERENCES
[1] M. Nekovee and R. S. Saksena, "Simulations of large-scale
WiFi-based wireless networks: Interdisciplinary challenges
and applications," Future Generation Computer Systems, vol.
26, no. 3, pp. 514-520, 2010.
[2] Y. Yiakoumis, M. Bansal, A. Covington, J. v. Reijendam, S.
Katti and N. Mckeown, "BeHop: A Testbed for Dense Wifi
Networks," ACM SIGMOBILE Mobile COmputing and
Communications Review, vol. 18, no. 3, pp. 71-80, 2014.
[3] C. Adjih, E. Baccelli, E. Fleury, G. Harter, N. Mitton, T.
Noel, R. Pissard-Gibollet, F. Saint-Marcel, G. Schreiner, J.
Vandaele and T. Watteyne, "FIT IoT-LAB: A large scale
open experimental IoT testbed," in 2015 IEEE 2nd World
Forum on Internet of Things (WF-IoT), Milan, 2015.
[4] "Huawei AC6605 Access Controller," [Online]. Available:
https://e.huawei.com/my/products/enterprise-
networking/wlan/access-controllers/ac6605.
[5] M. Inoue, M. Ohnishi, C. Peng, and Y. Owada, "NerveNet: A
Regional Platform Network for Context-Aware Services with
Sensors and Actuators," IEICE Transactions on
Communications, vol. 94, no. B(3), pp. 618-619, 2011.
[6] "Glances - An eye on your system," [Online]. Available:
https://github.com/nicolargo/glances.