SYST335FinalReportUpdated.docx

 Simulation & Analysis of the Johnson Center Third Floor 

Wireless Network 

 Chris Ludwig Ray Skaddan  Pwint Htwe  

Rebekah Orozco  Adnan Khan Iulian Gugiu  

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 

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 

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 

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 

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 

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 

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 

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 

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 

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 

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/navigator­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