This document summarizes a simulation of the wireless network on the third floor of the Johnson Center at George Mason University. The simulation was conducted using Arena and Riverbed modeling software. It analyzed input data such as the number of access points, user locations and device usage. The Arena model divided the floor into quadrants and assigned access points and user capacities. The Riverbed model simulated individual applications to represent users. Both identified bottlenecks and analyzed statistics like network load and page response times. The simulations aimed to better understand wireless connectivity issues and potential optimizations.

1.
Simulation & Analysis of the
Johnson Center Third Floor
Wireless Network
Chris Ludwig
Ray Skaddan
Pwint Htwe
Rebekah Orozco
Adnan Khan
Iulian Gugiu

2. Table of Contents
Motivation & Problem Description……………………………………………….....pg.3
Input Data Analysis & Model Assumptions……………………………….…..…pg.3­6
Simulation Model/Codes…………………………………………………………...pg.6­7
Output Statistical Analysis……………………………………………………….pg.7­10
Discussion & Optimization……………………………………………………...pg.11­12
References………………………………………………………………………...….pg.12
2

3. Motivation & Problem Description
The internet is a necessity in all of our daily lives. It has become the foundation
for accomplishing many routine tasks. There are two major issues that affect users: poor
connectivity and slow speeds. Unfortunately, students who attend George Mason
University (GMU) know this problem all too well. If asked, most students would say that
a major issue on campus is “the Wi­Fi network.” Today’s academic environment heavily
requires being connected to the internet and when a student or teacher’s Wi­Fi connection
is disrupted, it has a detrimental effect on his or her learning or teaching. Since every
member of the group sees, hears, and experiences the problems with GMU’s Wi­Fi
network, we decided to simulate and analyze a problem that impacts our daily lives. As a
result of GMU being a large campus, we decided focus our simulation and analysis only
on the third floor of the Johnson Center (JC).
The Johnson Center third floor consists of many rooms and open areas where
students can interact and study. It also has large open air space in the middle of it for the
food court located on the first floor. This open space is one of the many causes of reduced
signal strength which degrades network performance. Another cause of reduced signal
strength is interference from signal generators such as microwaves, personal hotspots,
and print servers transmitting on the 2.4Ghz channel. There are twenty­nine wireless
access points for the Wi­Fi network and six different entrances where people can access
the third floor. According to Chase Gleason, a network engineer at our school, each
wireless access point can serve eighty devices and at peak hours and the third floor sees a
maximum of approximately 700 users. By simulating and analyzing the JC third floor, we
expect to gain a better understanding on how to rectify the Wi­Fi network connectivity
issues.
Figure 1:Schematic of the Johnson Center’s Third Floor. Each red symbol is a wireless access point.
Input Data Analysis & Model Assumptions
There are major differences between a wireless access point and a router. A router
is capable of transferring data at higher speeds and can handle a wider variety of
users. To make our simulation more manageable, we assumed the number of people able
to connect to an access point does not change throughout the day.
3

4. For the Arena model, we assumed that one entity equals four people to satisfy the
constraints of the student version of the software. Each person in the Arena model has
multiple internet capable devices that can connect to the internet. We based our inputs off
the six stairwells a person could enter or leave the third floor of the Johnson Center and
did not include the two elevators since they are very close to two of the stairwells. Each
stairwell was assigned different probabilities to account for differences in internet usage.
A uniform distribution was assigned to each event to account for students often arriving
in a group at the Johnson Center’s third floor. The floor was divided into four quadrants
to simplify the simulation and assignment of wireless access points to users. An Arena
decision block with different probabilities spreads entities across the four quadrants since
there is no way to predict where people will be located when they connect to the Wi­Fi
network.The Arena model assumes that users will not move between quadrants during
the simulation.
The process of users connecting to the wireless access points is simplified in the
simulation by locating the twenty­nine wireless access points on the third floor and then
placing these wireless access points in one of the four quadrants. It is assumed that all of
the wireless access points are operational during the entire simulation. A major
assumption is that a user is within the range of two quadrants. Based on this assumption,
we assumed that if a quadrant is overloaded and a neighboring quadrant has spare
capacity, a user should be able to connect to a wireless access point in the neighboring
quadrant. Thus, it is possible to have a user in one quadrant and connected to a router in
another quadrant. For example, a user in Quadrant1 can connect to Quadrant2 and
Quadrant4, a user in Quadrant2 can connect to Quadrant1 and Quadrant3, and so forth
(Figure 2).
Figure 2:Quadrants of the Johnson Center’s Third Floor
There are three levels of Wi­Fi usage defined in the Arena model: high, medium,
and low. The level of Wi­Fi usage relates to the amount of packets requested by the user
and sent through the router. High­usage users watch movies, play videogames, or
4

5. perform some other intensive internet activity. Medium­usage users do homework and
occasionally load something such as a video or two. Low­usage users are connected to
the internet but are not using it. There are plenty of people in the Johnson Center who are
connected to the Wi­Fi network but not sending packets through the router.
Similar assumptions were made for the Riverbed model. After it was discovered
that the 80 node limit in the student version was binding, one workstation was modeled as
one device running 24 “applications”. An ​application ​is representative of a user
performing some type of internet­dependent task. Not all applications are running
simultaneously in our simulation. Each has a start time and a duration which is modeled
by a user­specified probability distribution and associated parameters. One “workstation”
is assigned to each access point which translates to 29 workstations running 24
applications each. As a result, there are a total of 696 applications, each representing a
user. Arrivals to the third floor of the Johnson Center were divided into two categories:
lunch rush and regulars. The regulars were assumed to use the light web browsing profile
and the lunch rush was assumed to user the heavy file transfer profile. These two profiles
were chosen in a way that conforms to the 80 million event limit, another restriction in
the student version of Riverbed.
Events ​are described in the user guide as “warnings, errors, unexpected protocol
behavior, and anything that may be significant or unusual” (Sethi & Hnatyshin, 2013, p.
110). Simplified models were created to explore the definition of an event. It was
discovered that events are related to the amount of data transmitted through the network.
A simplified model running one workstation with one application, one router, and one
ethernet server was studied. With the applications disabled, a one­hour simulation
generated 1,478 events. The same model with one light web browsing application
running from start to finish resulted in 9,506 events. When the light web browsing
application was substituted with the heavy file transfer application, the number of events
rose to 28,302. In the complete simulation including all users and workstations, there
were approximately 18.6 million events. It was concluded that “event” is an umbrella
term which includes overall activity during the simulation. This differs from the
classroom definition in which events are limited to entity arrivals, departures, and other
entity­related actions.
The main Riverbed simulation was run for 8 hours and was designed to simulate
network operation between 8:00am and 4:00pm on a weekday. Information desk staff
mentioned that the peak hours occur from 11:00am to 2:00pm. “Regulars” were assigned
arrival times modeled by an exponential random variable with a mean of 3600 seconds,
which is 1 hour from the simulation start time. Their duration is modeled with an
exponential random variable with a mean of 14,400 seconds (4 hours) and a poisson
inter­repetition time with a 7200 second (3 hour) mean. Lunch rush user arrivals are
modeled with expo(10,800 seconds) and duration with poisson(10,800 seconds). This
corresponds to an arrival time mean of 3 hours after the simulation start time (11:00am)
and a duration of approximately three hours. Lunch rush users are not configured to
repeat. The distributions chosen for arrival times, durations and repetitions are not
considered ideal. The simulation would benefit from a collection of arrival times and
subsequent input analysis with probability distribution fits. For the purposes of this
5

6. project, distribution parameters were instead derived theoretically due to inadequate
logistical capacity and support from school staff.
Simulation Model/Codes
It was decided that two models should be created in order to simulate the network.
The Arena model simulates the network using AP maximum user limits as estimated by
expert opinion, creating a queueing system for the purpose of identifying bottlenecks.
The Riverbed simulation contains the underlying technical details involved in wireless
networks and analyzes domain­specific statistics such as page response time and network
load.
The Arena simulation begins with six source nodes to generate users. Each node
has a triangular distribution which generates a minimum of one student, a mode of two
students, and maximum of five students every fifteen minutes for Stairs1 and Stairs2,
every twenty minutes for Stairs3 and Stairs4, and every thirty minutes for Stairs5 and
Stairs6. The variable names Stairs1­Stairs6 correspond to the six possible entrances to the
third floor of the JC. All entities entering the simulation pass through a probabilistic
decision node that sends entities to a quadrant. An assignment block gives an entity a
location, initializes a counter, and assigns the entity to a wireless access point to establish
a connection.The wireless access point first checks to see if it has available capacity to
accommodate the entity. If it is full, it checks the neighboring quadrants to see if any
other wireless access points in range of the entity have capacity. If there are no wireless
access points with available capacity for the device, the entity is sent to a loop function.
The loop function determines if the entity will try again to establish a connection
with the Wi­Fi network by turning off his or her computer’s Wi­Fi card and then turning
it back on again. This process is represented by having a small delay and sending the
entity back through the decision blocks to attempt to establish connectivity. This process
may repeat a maximum of three times in the simulation. If the entity does not connect
after three attempts, the entity is disposed and this statistic is recorded. If an entity is able
to establish a connection, it is seized by a resource associated with the maximum number
of users a wireless access point can handle, and is assigned a value to indicate which
router it is connected to. This helps later with deciding which wireless access point to
release. A file size whose value is high, medium, or low and uniformly distributed is
randomly assigned to the entity. The file is broken up into smaller pieces (packets) based
off the previously assigned value. Each packet represents a request sent through the
router. The router is a seize, delay, and release block that has eight resources that
represent the eight processors in the router. There is a function that contains a modulo
operator which is used to calculate the number of packets the file is split into. A feedback
loop will circulate the entity through the router’s processors the correct number of times
to fully load the file. After the file is loaded, the amount of time the entity was in the
system is recorded and we added a delay that has a normal distribution with a mean of
two hours. This delay represents the time the entity is connected to the Wi­Fi network
with an expression that calculates how long the entity has spent loading data and
subtracts it from the time the entity is using the network. This is done to quantify the
amount of time the entity is in the network system without adding extra time for
establishing a Wi­Fi connection and loading data. After checking which router the entity
6

7. is connected to, the release block releases the wireless access point and disposes the
entity after recording the statistic.
In the Riverbed model a map of the third floor is used as a template so that nodes
could be added in the proper locations. There are only four types of nodes, each
representing some component of wireless network. The nodes named “3702 LAP” refer
to the Cisco 3702 lightweight access points (LAP) which are used in the JC. Node
properties such as the data rate, physical characteristics, and number of spatial streams
have been modified to match the datasheet of the Cisco 3702 LAP. The wireless
controller which the APs rely on is not modeled as it is unavailable in the version of
Riverbed used to create this simulation. The Cisco WiSM2 controller is designed to
handle 15,000 APs and is therefore not considered a possible bottleneck of the system.
Other nodes include the WLAN workstations named “Student_xx”. Each of these nodes
represents one device running several applications and simulating a maximum load
equivalent to 24 users. Other two nodes are the ethernet server which represents the JC
router, and the Cisco 2940 ethernet switch which is designed to model the Cisco 2948
ethernet switch connected to each LAP via ethernet. The application node defines the
type of applications users can run (parameters can be changed to customize applications)
and the ​profile ​node allows the administrator to create different profiles representing
users who have unique arrival, duration and repetition properties.
Output Statistical Analysis ­ Arena
We calculated that the number of replications had to be 160 to bring our
half­width to an appropriate number. Our original half width for VA Time was .13 with
ten replications. We decided to bring the half­width down to .04, and calculated that our
replication number needed to be 160. This amount of replications brought down all the
half­widths to more precise estimations. It should be noted that this is a bit impractical
since a simulation is a simplified model of the real world. Although our simulation is
very precise on paper, it is possible to continue modifying the simulation to more
accurately represent a real life situation.
The Arena simulation model is built to calculate the waiting time for the router
and the number of entities that were rejected from the Wi­Fi network before a connection
was established with the wireless access point. These statistics allow us to assess user
satisfaction with the Wi­Fi network. For instance, if the wait time for the router is low
and the amount of people rejected from the network equals zero, then the Wi­Fi network
is considered very successful.
From our statistical readout, we found that the router resource has the lowest
utilization value when compared to the utilization of the wireless access points. This was
expected because the wireless access points maintain connection with an entity for the
total time the entity is using the Wi­Fi network. The router only receives packets
sporadically. Therefore, the total time the router is being used is when it is processing a
request from an entity. This was further substantiated by looking at the number of
arrivals for the wireless access points and comparing it to the number of arrivals for the
router processor. The router processes far more entities than a wireless access point
handles, and yet the router processor has a much lower utilization.
7

8.
Figure 3: Process Analyzer Results
Output and Statistical Analysis ­ Riverbed
Two main statistics were analyzed in the main simulation: network load and page
response time (latency). Latency is often used in industry as a metric to determine
network performance. Page response times (assuming the associated web server is not
overutilized) were analyzed in the JC using the windows ping command and compared
with the simulation output. Figure 4 shows simulation web page response times:
Figure 4: Simulated web page response time in seconds
Figure 5 shows a chart of five data points corresponding to ping delay times. Data was
recorded in the JC at different times throughout the day. The x­axis has been converted to
8

9. simulation time and the y­axis limits are consistent with those on Figure 4. These changes
are made so the graphs can be visually compared.
Figure 5: Actual web page response times in JC
The simulation page response time in the eight hour period has an average of 0.103
seconds with a standard deviation of 0.029 seconds, whereas the actual JC page response
times had an average of 0.078 seconds and a standard deviation of 0.041 seconds. The
averages being approximately 25 percent from each other suggests that the model is a
fairly accurate representation of the actual network. It is possible that user profiles
representing heavier traffic should be used to model behavior to increase the delay time
in order to match actual values.
Figure 6: Network load in bits per second
9

10. Figure 6 provides a visual of network load over the 8 hour period. Warm up time should
be ignored as the large number of arrivals at the simulation start cause an artificial load.
The visual is useful in that it identifies peak usage intervals so resources can be allocated
to alleviate network load during said interval. There is no provision in Riverbed to
change replication parameters but simulation accuracy can be discussed.
Ideally, each workstation would be modeled by a workstation node. Due to the
node limit that exists in the student version, multiple users are represented by one node
which degrades simulation accuracy. Accuracy is also degraded due to the restrictions in
user profiles, as heavier profiles cause the simulation to crash due to excessive generation
of events which exceed the 80 million event limit.
Due to the degradation of simulation accuracy caused by software restrictions,
focus was shifted to studying individual user profiles. Particularly, the role of probability
distributions in modeling user behavior was studied and statistics analyzed. Figure 7
shows the difference in output between the two profiles used in the simulation: light web
browsing and heavy file transfer:
Figure 7: Difference in user profiles
The two profiles have expectedly different characteristics with regard to the amount of
traffic generation. The light web browsing profile consist of a default page interarrival
time of X~expo(12 minutes). Page properties are modeled by one constant 500 byte
object as well as 5 images whose size is modeled by U(100,400 bytes). Heavy file
transfer is characterized by downloads whose inter­request time is modeled by expo(6
minutes) with a constant file size of 0.05 Mb. Administrators are able to define random
variables with one of several available probability distributions to achieve desired output.
It was realized that the large role of probability distributions in defining user behavior
reveals the large scale of randomness that is inherent in wireless network simulations.
Discussion & Optimization
Comparison of Riverbed and Arena
10

11. Riverbed is a simulation software that is built specifically to model wireless
networks. One of the components that Riverbed handled, which Arena did not, was that it
simulated entities coming in for the lunch rush. Arena could have been modified to
account for a rush, but a lot of changes would be required to simulate a specific type of
entity entering and leaving the simulation. Another thing that Riverbed was able to
account for is specific hardware capabilities. There are precise technicalities of data
handling and package transfer dependent on the technology involved. Arena’s capability
is heavily restricted by the student version and our technical knowledge of how the Wi­Fi
system truly works. Arena is capable of producing a high level view of students entering
the system, accessing the router, and leaving the system. Arena had about ten entities
disposed from the system. This would equal about 60 students unable to connect to the
Wi­Fi network throughout the eight hour run time. Arena could be overestimating the
amount of people entering the system, and therefore not truly modeling what overloads
the system.
Discussion and Conclusion
Our experience indicates that the scale of the simulation is too large for student
version software. No such simulation was conducted prior to the design of JC
infrastructure per Chase Gleason, and in an academic setting such a project should span
several semesters and utilize professional version software. Once completed, however, a
simulation of this magnitude could be used to model similar campus wireless networks
for improvement and design purposes. Additionally, after network infrastructure
components were identified, it was realized that compartmentalization of the network
would degrade simulation accuracy due to the omission of additional components such as
the core routers and firewalls. In the Fall 2015 semester an outage was observed which
was thought to be caused by overloading of firewalls, a component outside the JC
infrastructure. By only simulating hardware inside the JC, high­level components outside
the JC which are possible bottlenecks could be ignored.
Nevertheless, design changes can be proposed based on simulation output,
personal observation and expert opinion. Currently, individual user bandwidth is throttled
(load balanced) at 24 Mbps per user. Load balancing allows network administrators to
increase connectivity and reduce network load at the expense of decreased network
speeds. Given that academic­related internet use holds the highest priority, it is
recommended that the bandwidth allocation be further reduced to 18 Mbps. This can be
justified by recalling that the network is primarily intended for academic use which
requires a relatively small amount of bandwidth.
The system can be further optimized by observing user density in areas around the
third floor and relocating access points based on observation. Access points should be
relocated from areas with low user activity and concentrated in areas with high user
activity. Resources should be allocated to perform site testing and network performance
analyzed using different configurations.
Finally, the amount of wireless networks and other signal generators in operation
must be acknowledged and interference reduced. These devices include print servers,
personal hotspots, wireless TVs, and microwaves. Hardware should be installed that
11

12. minimizes interference from such devices as they all transmit on the common 2.4GHz
frequency.
References
1) Estimate Your Web Usage. Cable One Inc., 2016. Web. 20 Apr. 2016.
http://www.cableone.net/Docs/datacalculator.html
2) Facilities Management. George Mason University, 2016. Web. 20 Apr. 2016.
https://mason.oncfi.com/archibus/schema/ab­core/views/process­navigator/naviga
tor­details.axvw
3) Chase Gleason Network Engineer [Personal interview]. (2016, April 20).
4) Information Technology Services.George Mason University, 2015. Web. 24 Feb.
2016.
https://itservices.gmu.edu/
5) H. (2012). Opnet Tutorial ­ Setup Network. Retrieved April 20, 2016, from
https://www.youtube.com/watch?v=XAzXKnAwKxo
6) OPNET Modeler. Riverbed Modeler Tutorial ­ Documents. Retrieved April 20,
2016, from ​http://docslide.us/documents/riverbed­modeler­tutorial.html
7) Adarshpal S. Sethi & Vasil Y. Hnatyshin. (2013). ​The Practical OPNET User
Guide for Computer Network Simulation.​ Boca Raton, FL: Taylor & Francis
Group.
12