End-to-End Performance Analysis and Scalability of Tablets

M.Tech Stage 1 Report

Submitted for the fulfillment of requirements for the degree of

Master of Technology

by

Deepak Jayanth P M Roll No: 10305913

under the guidance of

Dr. Deepak.B Phatak a Department of Science and Engineering Indian Institute of Technology, Bombay Mumbai Contents

1 Introduction 1 1.1 Problem Statement ...... 1 1.2 Performance Analysis ...... 1 1.2.1 Why Necessary? ...... 1 1.3 Common Issues in Performance Analysis ...... 2 1.3.1 Sources of Bottlenecks[1] ...... 2 1.3.2 Difficulties & Limitations ...... 3 1.4 Scalability ...... 3 1.5 Report Outline ...... 3

2 Analytical Methods of Performance Analysis 4 2.1 Introduction ...... 4 2.2 CSMA/CD Basic Operation ...... 4 2.2.1 DCF mode ...... 4 2.3 A model for Throughput at MAC level [2] ...... 5 2.3.1 Model construction ...... 5 2.3.2 Duration for Transmission time ...... 5 2.3.3 Observations ...... 6 2.4 Delay analysis at MAC level ...... 7 2.4.1 Queuing Models ...... 7 2.4.2 Single queue model for MAC operation ...... 8 2.4.3 Delay Analysis [3] ...... 8 2.5 A model for Capacity of users [4] ...... 9 2.5.1 Working ...... 9 2.5.2 Mapping Application throughput from MAC level ...... 9

3 Approaches of Performance Analysis 11 3.1 Benchmarking ...... 11 3.2 Android Application Profiling and Characterization [5] ...... 11 3.2.1 Measurements ...... 12 3.3 Traffic Characterization ...... 12 3.3.1 Protocol Overheads ...... 12 3.3.2 Network Performance ...... 12 3.3.3 Browsing Performance ...... 12

i 3.4 Performance Measurement Tools ...... 13 3.4.1 Lack of Effective tools ...... 13 3.4.2 Representation for multidimentional Network ...... 13 3.5 Measurement Issues specific to Tablets ...... 14 3.5.1 Measurement from Android ...... 14 3.5.2 Unpredictable memory behaviors ...... 14 3.5.3 Application Vs Browser based ...... 14 3.5.4 Mapping Problems ...... 15

4 Scalability at Data Link layer 16 4.1 Bottlenecks at Data link layer ...... 16 4.1.1 802.11 DCF operation ...... 16 4.1.2 Problem of Electromagnetic Interferes ...... 16 4.2 Improving Scalability ...... 17 4.2.1 Fair Channel Usage ...... 17 4.2.2 Channel Planning ...... 17

5 Scalability in Higher Layers 18 5.1 Using IP Multicast ...... 18 5.1.1 Implementation Methods [9] ...... 18 5.2 Regulation of Wireless Traffic ...... 19 5.3 Scalability at Application Level ...... 19

6 Protocol Customization 20 6.1 MAC Broadcast using Beacon Stuffing[8] ...... 20 6.1.1 Mechanism ...... 20 6.2 Device Customization ...... 21 6.2.1 OpenWrt ...... 21 6.2.2 Opensource wireless drivers ...... 21

7 Experiments 22 7.1 Overview ...... 22 7.2 Experimental Setup ...... 23 7.3 Throughput ...... 23

8 Conclusions 25

9 Stage 2 Scope 26

ii List of Figures

1.1 Potential sources of bottlenecks during a communication ...... 2

2.1 Hidden markov model for contention process ...... 5 2.2 Time taken for transmission under Basic mode ...... 6 2.3 Time taken for transmission under RTS/CTS ...... 6 2.4 Throughput vs Transition probability under Basic mode [2] ...... 6 2.5 Throughput vs Transition probability under RTS/CTS [2] ...... 6 2.6 Wasted channel time vs number of stations[2] ...... 7 2.7 Queuing Systems in general ...... 8 2.8 Birth death process ...... 8 2.9 Throughput vs Mean dataframe delay [3] ...... 9

4.1 802.11b/g A.P frequency planning ...... 17 4.2 802.11a A.P frequency planning ...... 17

iii Abstract

Performance is the most important characteristic of any network, service, application ,etc. And the study of performance analysis is very important, as these study will help in making critical decision on which hardware to use, technologies to implement, how many users will be served, predict the trend of future inputs to system, etc., or make new better technologies. This work discusses performance analysis of Tablets in general and various ways of measurement and characterization of Tablet usage. It discusses various issues related to sources for bottlenecks of connecting a large number of Tablet users in a wireless network. It also discusses ways of mitigation of bottlenecks and improvements to scalability. Chapter 1

Introduction

1.1 Problem Statement

The main goal of this project is analysing and characterizing the behaviors of Tablets in terms of I/O operations, network traffic generation, application, traffic generation,amount of user interactions to touchscreen(swiping,clicking), etc., The other goal is to analyse for scalability issues in connecting huge number of simultaneous tablet users. The typical scenarios considered are scaling issues in a densely populated area like classroom supporting 100 plus tablet users(single hop) or it can be scaling issues in tablets connected through campus infrastructure distributed over a wide area using multiple access points,switches, routers inbetween them(multi hop). The performance analysis made should help in identifying the bottlenecks which exist in connecting and distributing data to huge number of tablets simultaneously.

1.2 Performance Analysis

1.2.1 Why Necessary?

Consider any infrastructure to support a design scenario, to answer questions such as how exactly things will run, how many maximum numbers of users can be connected at a time, how exactly the network will scale, how reliable a server will run on increased load,etc., performance analysis is required. For example a news site may get millions of request for a cricket page during world cup where it provides up to date coverage and in other days it will be normal. And same goes for a movie review site during a movie release. A typical web application is generated from a complex network of Application Servers, Database servers coupled with mechanisms such as content load balancing, content caching, resource pooling, etc., These are deployed on large number of servers that are clustered together. For a application to be served and function in a timely manner each of the above mentioned mechanisms should work effectively. So it will be inappropriate to leave any of the above mentioned concepts in the design of a better application. So performance analysis is required for planning of a system, network, infrastructure, application design and analysis to support a smooth running of this design in the future. Failure to predict and plan for a future demand may lead to overwhelming of the server with large number of requests and extreme cases shutting down of server. So the performance analysis is one of the important tasks

1 done, which will possibly give a way to avoid such situations. This is performance analysis at a server level. Another example is a institution wireless infrastructure to support wireless connectivity throughout the campus. In this case before designing such infrastructure an performance analysis interms of capacity planning,requirement of maximum user support must be done to efficient deployment of this infrastructure. Poor pre-performance analysis and planning will lead to poor maintenance and cost of this infrastructure.

1.3 Common Issues in Performance Analysis

1.3.1 Sources of Bottlenecks[1]

The performance bottleneck can happen at many places other than the network. The following will bring an idea of places where bottleneck arise. The queueing line represents potential sources of bottlenecks.

Figure 1.1: Potential sources of bottlenecks during a communication

The Figure 1.1 on page 2 shows pictorially the list of potential locations for bottlenecks which can happen during a communication between a client and a server. When a client requests a http connection, as shown in figure it undergoes the intermediate stages. The requests come in terms of packets to the NIC(Network Interface Card) of server and stored on a buffer as incoming request. The network buffer may already have similar kind of request packets obtained from other clients. This is possibly the first source of bottleneck, once this queue gets full the NIC wont be able to process further requests and it may become a source of bottleneck. If the packet gets through the above queue, packet may next need to do task which requires the access of either of CPU , Database, IO. Each of these three (the CPU, Database , and Disk) have themselves queues of their own, and the same rule of NIC queue apply for the other three device queue. The only difference they are called with different names. At cpu level the bottleneck is caused because of different scheduling methods of process/threads queues. At Network level it because of packets arrived at buffers at Network layer. The packet can be even broken down and correlated with buffer size of incoming Frames on data link layer. The bottleneck queues can also be thought from the point of view of application design level, for eg, a chatty protocol, which sends too many short messages between peers. Here the percentage of bandwidth is wasted as overhead.

2 1.3.2 Difficulties & Limitations

The sources of bottlenecks can be anything from a network device, or host computer to a bad application design. This complex network of systems as a whole has a lot a components to study about. A single linux has close to 100 tunable TCP and IP parameters[10]. Web administrator usually play with these parameters and may actually increase some perfor- mance which supports their particular configuration. So the way to measure performance and make sense out of the values obtained considering into account these many varying parameters is a very challenging task. And modelling this requires a careful understanding of each of such components.

1.4 Scalability

Scalability is one of the important characteristics of any system, which is the ability of the system to perform gracefully under increased load conditions. It is the ability of a hardware, infrastructure, application to perform gracefully when its size or operating function needs to be expanded. Its not only the function of just functioning properly on the new higher requirement system, but also to take full advantage of the hardware, infrastructure, underlying architecture. Scalability is talked in terms of scaling vertically or horizontally. Usually horizontal scalability is considered more cheaper.

1.5 Report Outline

This work is mainly oriented to the performance analysis issues at various layers of tablets. Although measuring Energy is also closely related performance in case of energy constrained devices such as tablets it is not focussed in this work.

• Chapter 1 Discusses performance analysis in general

• Chapter 2 Analytical approaches to performance analysis based on mathematical foun- dations and probabilistic models which models the operation of lower layers of the OSI protocol stack. It discusses analytical models defined in [2], [3] and [4]

• Chapter 3 Software Approaches to performance analysis which is more of application level of analysis.

• Chapter 4, 5 Discusses Scalability Issues and Improvements which can be made at Data Link layer and other higher layers.

• Chapter 6 Discusses Protocol Customization and a customization method defined in [8]

• Chapter 7 Experiments to support the idea of connecting huge number of simultaneous users.

• Chapter 8, 9 Conclusions and Stage 2 Scope

3 Chapter 2

Analytical Methods of Performance Analysis

The Analytical methods of performance analysis employ a bottom up approach of performance analysis. The analysis starts from modeling hardware layer functions and going to higher layers such as Transport, Application etc. All the following analytical methods are ways of analysing from bottom to top ie. starting from modeling the hardware and moving towards higher layers.

2.1 Introduction

Media Access Control (MAC) remains a major research in wireless networks, because of the difficulties caused by collisions, errors due to transmission, and hidden nodes. The following models mainly examine the reasearches based on analytical model in this area.

2.2 CSMA/CD Basic Operation

Carrier Sense Multiple Access with Collision Avoidance(CSMA/CA) is the access method on 802.11 Wireless Ethernet networks. A node wishing to transmit must first sense the medium, whether any other nodes are transmitting. If the medium is busy, the node waits for a period untill the medium is free. If the medium is not busy for a Short period known as the Interspace Time the node tries to transmit the frame. In infrastructure mode network each station needs a wireless access point act as a centralized hub. All wireless stations/tablets in an infrastructure mode network connect to an access point. All nodes connecting to the access point must have the same service set identifier (SSID) as the access point. In Ad-hoc mode network there is no need for an access point. All wireless nodes directly can interact with each other. All the nodes in an ad-hoc network must have the same channel and SSID.

2.2.1 DCF mode

DCF defines a basic access method, and an optional four-way handshaking technique, with Request-To-Send/Clear-To-Send (RTS/CTS) mechanism. A wireless tablet with a packet to transmit, monitors the channel whether busy or free. If the channel is free for more than a slotted period of interval known as DIFS. The time immediately following an idle DIFS is

4 slotted, and a station is allowed to transmit only at the beginning of each slot time. This duration is enough to for a station to identify whether other tablets are trying to transmit. The DCF employs an exponential backoff algorithm to mitigate collision. The time after DIFS is slotted and each stations willing to transmit will choose a random slot inbetween 0 and w-1. Then it starts counting till that value. Once it reaches the stations transmit. Here, w is called the contention window which varies from Cmin to Cmax. If the transmission is unsuccessful the current value of w is doubled, and the stations again choose a random time between 0 to new value of w and then transmit. The counting time of a station is frozen if it senses the medium to be busy, the counting is resumed once again after a DIFS duration of channel not being busy.

2.3 A model for Throughput at MAC level [2]

2.3.1 Model construction

Figure 2.1: Hidden markov model for contention process

The behavior of a single wireless station is modeled using a Markov model. The exponential backoff process exhibited by every wireless station is modeled using two dimentional stochastic process with two random variables exhibiting a discrete markov chain. As the Figure 2.1 indicates each of the state of the markov chain represents two random variables, one is for representing the current backoff stage, and another is for counting the backoff timer value.

2.3.2 Duration for Transmission time

The Duration of time in which the channel is busy is calculated using the following approach. The Figure 2.2 and 2.3 on page 6 shows the time spend for successful transmission as well as the time spend for collision under basic and four way handshake(RTS/CTS) mode as sensed by a tablet. Tsuccess represents the time for a successful transmission of data by a tablet. Tcollision represents the time spend by a channel to identify whether a collision is happened. Both Tsuccess and Tcollison are expressed by the following equations.

5 Figure 2.2: Time taken for transmission under Figure 2.3: Time taken for transmission under Basic mode RTS/CTS

basic Tsuccess = H + E[P ] + SIFS + δ + ACK + DIFS + δ (2.1)

basic Tcollision = H + E[P ] + DIFS + δ (2.2)

RT S/CT S basic Tsuccess = RTS + SIFS + δ + CTS + SIFS + Ts (2.3)

RT S/CT S Tcollision = RTS + DIFS + δ (2.4)

If Ptr is the probability that there is at least one transmission in the considered slot time, Ps is the probability that the transmission occuring on the channel is successful, E[P] is average packet payload size and σ is the duration of the empty slot time, then the throughput can be expressed as a fraction of average time spend by a packet of average size to the effective time spend in sending that packet, which includes time spend on collision, successful retransmission and the time of the empty slot.

E[ payload information transmitted in a slottime] S = (2.5) E[length of a slot time ]

P P E[P ] S = s tr (2.6) (1 − Ptr)σ + PtrPsTs + Ptr(1 − Ps)Tc

2.3.3 Observations

Figure 2.4: Throughput vs Transition proba- Figure 2.5: Throughput vs Transition proba- bility under Basic mode [2] bility under RTS/CTS [2]

6 Figure 2.4 and 2.5 on page 6 shows the Throughput obtained vs the transmission probability(τ) of a tablet. The transmission probability is the probability that the given tablet will transmit in a randomly choosen time after sensing a free DIFS duration time slot. It has been noted that this probability is the main factor of determining the throughput. This probability does not depend on the access mechanism. Given ’n’ number of connected tablets, a lower value of τ means that very less no of tablets are interested to transmit. higher values of τ means more no of nodes are interested to transmit. It is very clear from the graph that as n goes higher and with a higher τ the system throughput decreases very fast. The graph can give a recom- mendation of values of τ each contenting tablet should have to achieve maximum throughput. Hence theoretically the maximum throughput can be obtained for any number of wireless users, but it cannot be practically achieved as this value is dependent on ’m’(maximum backoff stage) and ’W’ (maximum backoff window) which are hardcoded in the physical layer and cannot be changed dynamically.

Figure 2.6: Wasted channel time vs number of stations[2]

Figure 2.6 on page 7 is also another way to see the number of slots wasted, ie the number of time the channel is wasted on collision of data between one or more stations. If the initial backoff window size is very less, then for large values of ’n’ more no of slots are wasted. For higher values of initial backoff window size, the no of wasted slots is less. The no of slots wasted by RTS/CTS mechanism is very low, which implies that DCF is more efficient in avoiding collisions for higher values of ’n’ with RTS/CTS. The paper [2] discusses many other analysis on the above parameters under various circumstances.

2.4 Delay analysis at MAC level

2.4.1 Queuing Models

Queueing model represents a system is analytically tractable. Queueing models often has poisson arrival and exponential service time distribution. The poisson arrival rate is specified by the number of requests coming to the system. The parameter of interest out of this model is the time interval between two successful events served. The Poisson process models random events such as a requests for a webpage, number of process coming to a system, etc). Under markov

7 assumption the current event does not depend on the previous event. The book [1] describes many queueing models and its practical usage in various scenarios.

Figure 2.7: Queuing Systems in general

The Contention process can be modeled similar to that of M/M/1 queueing system. Consider a system, where a number of requests comes to the system. The system here is the access point. The arrival rate of the system is given by λ, which is the arrival rate of requests to the system. The arrival rate is the stations contenting of the channel access. The sytem services incoming requestion given by rate µ. Both Arrival rate and Service rate follows a probability distribution. λ follows a poisson distribution and µ follows exponential distribution. In the notation M/M/1 , first M means markov arrival process with poisson arrival and , second M means markov arrival process with exponential service distribution, and 1 indicates the number of systems.

2.4.2 Single server queue model for MAC operation

The [3] discusses a slightly modified version of this queuing system, from their analysis of service times of packets at MAC layer through simulations they identified that the service times does not follow exponential distribution. A more appropriate model to represent the service distribution at MAC is using Erlang function with j=8. Here the arrival rate is the number of active stations which requires to transmit. The service rate of each state is obtained from µ(i) = S(i)/ td , where i is the number of stations which requires to transmit, and S(i) is the saturated throughput obtained from 2.6

Figure 2.8: Birth death process

2.4.3 Delay Analysis [3]

Figure 2.9 on page 9 shows the delay performances exhibited for diferent frame sizes. Three different data frame sizes (512,4348,8184b bits) are considered. From the comparison of basic and RTS/CTS mode, it is noted that the larger data frame offers higher throughputs. It is also noted that the RTS/CTS method offers more throughput than that of basic mode of operation. This is mainly because of the collision overhead in basic mode of operation. In basic mode the collision can be detected only after the whole payload has be transmitted. Since this overhead is

8 Figure 2.9: Throughput vs Mean dataframe delay [3] not present in RTS/CTS mode, the collisions are less. This implies that the average delay due to RTS/CTS mode is lesser than that of basic mode. But it is also noted that in some cases the basic mode has higher throughputs, this can be attributed to the cases for smaller data frame (in this case for 512 bits). This implies that the overhead due to RTS/CTS is less prominant as the number of users gets higher.

2.5 A model for Capacity of users [4]

The paper [4] discusses a model to identify the ideal number of users which can be supported gracefully in a single hop network. That is clients accessing a server connected with a wireless access point in an Infrastructure mode. The inputs to this model are average rate of request λapp and average size of application payload Lapp , and average size of requested object. Outputs are the recommended number of users which can be supported with this mode of operation.

2.5.1 Working

Each http requests from client generate on an average 10 connections to-and-fro from client and server for a GET request. Out of which 5 small packets for upsteam direction and 4 small packets for downstream direction and 1 for the payload. For payload greater than MSS, the payload is divided by the MSS and response will be broken to multiple TCP segments. If lh Lapp is the length of the header and D = d MSS e If ’n’ nodes are present in the network and n-1 are clients and other is access point, then the average requested packets at mac layer can be calculate as λ (n − 1)(9 + 2D) λ = app packets/s/station (2.7) mac n Average packet size is given by (9 + 2D)l + L l = h app bytes (2.8) a (9 + 2D)

From λmac values the Smac can be calculated by [3] model. And application throughput for each value of n is calculated by formula

SmacLapp Sapp = (2.9) lh(9 + 2D) + Lapp

2.5.2 Mapping Application throughput from MAC level

The MAC level throughput is taken from the model of [3] and then mapped with the http throughput generated by the input arrival rate. A threshold is set to compare the differ- ence of the offered load and the application generated load for clients from 1 to n. The

9 value of n is choosen such that this difference becomes less. If S0 is the offered load given Pn by Lapp i=1 λapp,i bytes/sec and Sapp is the application saturation point, then the maximum value N which can be supported is given by the equation

S0 − Sapp N = largest value of N such that < t (2.10) S0

The Sapp is calculated for every value of ranging from 1 to n and the value can be substituted in equation 2.10 and this process is iterated until the difference between offered load and S0 becomes less. That value of ’n’ which makes this difference lesser than the threshold will the required sizing value N.

10 Chapter 3

Software Approaches of Performance Analysis

The software approach employs a Top-Down approach of performance analysis. Analysis starts at Application Level and moved to hardware level. Since analytical methods always cannot model every thing, sometimes parameters measured through software approaches such as pro- filing, logging ,simulation can be used to approximate a parameter or distribution, etc for an analytical model. Also many times the analytical model may lose the details which are at application level. Like analytical models this method of analysis also gives some insight into predictions on the number of users supported, capacity of a network., etc. The software meth- ods are normally employed when analytical models are very difficult to realize. They are useful whenever a distribution of a certain behaviors is difficult to model, but are easy to simulate or measure and can be matched with a known curve which is closely matching to measurements. This curve can be used as a distribution for certain arrival rate or service rate of an analytical model.

3.1 Benchmarking

Benchmarks give a relative measure of estimating the performance of any system and assigns a number to say how one machines scores high or low to another. The release of most of the new smartfones, tablets are usually followed by reviews about this new hardware’s performance over already existing hardware. But it a very abstract level of classifying a device. For somecases it may be sufficient, but in many cases this top level classification is not sufficient.

3.2 Android Application Profiling and Characterization [5]

Profiling of Application is done to classify application behaviors. Here the performance analysis is carried from a single tablet/smartfone. This kind of analysis of performance analysis from a single device would provide a valuable solution to 1) app developers for better understanding of network operation and provide improved user experience , 2)the end users to understand strange behaviour of any application. The profiling used in this method to classify applications based on (a) app specification, (b) user interaction(swipe,click) (c) operating system IO (d) network. These details of analysis has other benefits such as to construct a models which closely resemble with the measurement performance parameter. These models can be then be used by analytical

11 models, as analytical does not work with real datas as raw. They have to be approximated to close some known distribution.

3.2.1 Measurements

This paper[5] identifies discrepancies exist between the app specification and app execution of many selected paid and free version apps from android market. These apps are carefully choosen amoung 0.6 billion android apps based on number of downloads, ratings given by users,etc so as to represent a wide usage by many users. By the analysis they have found that free versions of apps could end up costing more(data usage costs) to the users than their paid counterparts, due to an traffic differences between free version and paid version. The methods identified that most of the network traffic is not encrypted. It is also noted that some apps communicate with more than 13 different sources for some operation with most of them being content distribution networks (CDN). The main problem was that the this operation of reading and writing to disk a relatively large file is both network intensive and IO intensive task. If any IO or network intensive task is run directly from the main thread, it simple hangs. So these kind of cpu blocking ( intensive time consuming tasks) has to made from a background child thread rather than the main thread. This information was obtained after perusing android documentation on threads.

3.3 Traffic Characterization

3.3.1 Protocol Overheads

The overhead of lower layer protocols can be high based on the traffic. The experiments done in [7] of a dataset of 33 android phones suggests that the overhead due to lower layer protocol adds to 12% for regular traffic and 40% for traffic with Transport layer securities.

3.3.2 Network Performance

The network performance is characterized using TCP throughput, retransmission rate, DNS lookup time, Round Trip Time (RTT),latency. to the first responsive IP hop as our metrics. Since most network applications use TCP, TCP is an important performance metric of analysis. A request for a web object is initially done through a local DNS lookup , and the establishment of TCP handshake, Hence these two factors contribute heavily to user-perceived performance of many network applications. The RTT and TCP retransmission rate are calculated by matching each TCP packet with its Acknowlegded packet. In case of retramission the RTT for that packet should not be taken into account.

3.3.3 Browsing Performance

The Webbrowsing performance is a little complex because of the dynamic nature of content. Some of the metrics measured are TCP handshake time, TCP transfer time , DNS lookup time, Page loading time Content types, sizes and Javascript execution time etc., Some of the performance metrics like Page loading time which can be calculated by time it starts from a DNS lookup packet to the last connection data served of that request. This is slightly user-perceived measure of page loading time since even after the last data object delivery to client, the client

12 needs to parse and run javascript functions and render a page hence adding a significant amount of rendering time. The experimental results from [6] suggests some interesting analysis on packet losses. For small packet loss rate, e.g.,2%, there is little performance degradation. However, with 10% loss rate, the loading time rises up significantly. Compression can dramatically reduce web content size. For text objects, such as HTML, CSS, Javascript, PHP, etc., the object size can be reduced by around 70%. It shows that the content size can be reduced by more than 50% for most of the URLs. While compression reduces the bytes of data transferred over the network, decomression will increase computation overhead on the phone. Current web browsers on tablets allow concurrent connections. In browsers settings, there is a parameter specifying the maximum number of concurrent TCP connections per domain. This value is 4 by default. Experiments made by [6] suggests that changing this value to 1 would degrade the performance by a factor to 3.5.

3.4 Performance Measurement Tools

3.4.1 Lack of Effective tools

There are lot of tools available such as Jmeter, httperf,wireshark to analyse performance by means of logging of request datas. These logs ranges from application level information logs, transport level logs such as TCP, Network level logs such as IP packets. The main problem with the tools which are available is that they are too much verbose. The Dumps which are produced is typically very large even for a 1 minute interval of logging. Almost all of these tools produce graphs to compare two or more related fields. Although Graphical interface exist they are still not enough to represent in a manner which is easily perceivable. Some of these tools which exist today can be only used by experts and only after a deep knowlegde of usage in the tool. As in case of most of the tools a single tool is not robust enough to diagnose a problem such a scalability. Although tools such as wireshark exist to analyse OSI layers from linux environment, the same doesnt exist to analyse the operation of live access point, hence it is difficult to analyse and characterize operation at Data link layer of wireless such as channels , contenting stations, data link layer packets, MAC operation, etc., Hence these operation are usually analysed only through simulation. The use of open source linux wireless firmwares such as provided by open wrt may be possible to some extent.

3.4.2 Representation for multidimentional Network

The main problems with tools available is that most of the tools use graphs to represent the change of one or more parameters with other parameters with x,y axis. One question which needs to be answered is that whether they are sufficient enough to really represent something which is multidimentional and vary with time. Graphs are enough to represent two dimentional things such as a comparison of throughput Vs time, etc. But a typical network has parameters very large and multidimentional. Graphs are fine to identify problems at one level. To represent something as big as a network, a representation which is more robust is required. An analogy to think for a better representation is to think about maps. Maps can be zoomed in again and

13 again to obtain fine details for every zoomed level. Likewise if a tool exist to view network problems it would be close to perfect to analyse and solve scalability problems.

3.5 Measurement Issues specific to Tablets

3.5.1 Measurement from Android

Although a variety of open source tools exist to measure performance from a pc, the opensource tools exist to measure from android devices are very less. The variety of testing which can be done from these devices is also less. For example tools such as Jmeter exist for generating customized test cases from PC, similar opensource tools of generating test cases of such high numbers are not available for android. There are so many tools available to measure performance, benchmarking of systems. The tools used to measure from tablet should be relatively lightweight when compared to tools like jmeter which is used to measure performance from pc. Tools written in native c language are preferable. There is a possibility to port tools which are currently used to measure performance from linux system to android application through Java Native Developing support. But this requires compiling and cross building of this source code to Android. which interns required a compiler to compiler which is not available on android. One possible solution is to port a cross build compiler first on the android. And then it will be possible to build any tool which works on PC to android itself which is basically a stripped down linux version. Problems usually scale when no of users, distance increase , unanticipated loads , miscon- figurations. One way to solve the problem is looking in to one aspect of a protocol and get a clear picture of bottlenecks surrounding that protocol and then move for a variable tuning parameters. This paper[11] says about various performance terms related to HTTP and TCP protocol, latency, how the MTU depends on throughout, etc.

3.5.2 Unpredictable memory behaviors

On order to test performance from an android and to benchmark it, the tests should be performed such that it takes into consideration the android environment. Android has a complex life cycle. And if testing is done without knowing of how its memory model work , and request serving mechanisms work, the results will be inaccurate. The android application runs on DVM (Dalvik Virtual Machine. Dalvik is the virtual machine (VM) in Google’s Android operating system. Dalvik is thus an integral part of Android operating system which runs the applications. The Programs for Android application are written in a dialect of Java and compiled to bytecode. Then they are converted from Java Virtual Machine-compatible .class files to Dalvik-compatible .dex (Dalvik Executable) files before installation on a device. This convertion is done through a tool called dx tool. This Dalvik executable is tailor made to run efficiently for systems which are constrained with relatively low memory and processor speed. And because of this there may to unpredictable results because of the decision made to save energy. So the measurements made should be account for such cases.

3.5.3 Application Vs Browser based

There are applications that exists to measure performannce which can be either webbased or a complete application. But for an effective measurement and prediction based on the better

14 control of underlying layers of communication should be employed. Since a http connections underlying methods of connections cannot be defined form a webbased method, a web based method is inadequate or inaccurate for modelling or measurement for performance parameters of a tablet. Hence Android application based measurement seems to be the right choice.

3.5.4 Mapping Problems

Problem of logging overheads exists, basically if we examine the TCP connections from the same machine or device the url is loaded. since every packet is logged, it will increase the disk overhead. The max throughput measured will be inaccurate, since the systems utilization will rise quickly as more and more packets are coming. Which leads to more and more logging of datas. So there is an inherent bottleneck to the device as it is doing an IO operation extra by saving the dump. So at high rates of incoming request the device which does TCP examining will perform and serve less when compared to device which doesn’t do TCP examining. An alternative method is to examine the packets from a third machine whose NIC( Network Interface card) which will act in promiscouos mode as a sniffer. It will get all the input requests as if it were forwarded to it, and store all the records of TCP SYN signals. This method seems to be good, but even this also has some inherent problems. There are always packets which gets missed on the air due to collision, and SYN signal are resent by a request machine or ACK gets missed out in the air , the device might send the ACK signal again. In this method since the packets are not addressed to this sniffer machine, it cannot account either for the lost SYN signal,ACK signal or resent SYN,ACK signal. It simply assumes that each of SYN, ACK pair are new connection. As this is a wireless sniffer, it can itself miss out SYN, ACK signals. Delayed acknowledgments can cause other problems such as measuring the Round Trip time(RTT) which is the measure of time between SYN and SYN-ACK packets. Because of delayed acknowledgments it is quite difficult to identify the data and its corresponding Ac- knowledgement. Hence there seems to be is always a trade of between different methods. But the problems inherent due to self overhead in measurement can also be generalised and classified to overhead of certain known percentage associated with any measurement.

15 Chapter 4

Scalability at Data Link layer

The following are some of possible problems identified which contribute to scaling issues at Medium access level. For each identified problems possible solution to tackle the problem is also identified.

4.1 Bottlenecks at Data link layer

4.1.1 802.11 DCF operation

From the analytical throughput models and simulation results of DCF operation, it is evident that as the number of wireless network tablets grows higher, the tablets contention for the wireless medium remains the main bottleneck. As a result the more number of collisions happen when the number of wifi devices connected to Access Point exceeds 50 to 60. The wireless network gets congested with packets, resulting in more errors, more retransmissions and a final congestion collapse. This is because of the wireless medium is Half-Duplex and only one tablet can receive or transmit data at a time. A tablet cannot simultaneously listen and transmit. It can do only one operation at a time. Although some new technologies exist where multi antenna support is provided, where one antenna can transmit and other can listen, but they are not largly available and still large number of users use age old standards. As the number of tablets increase the probability of collisions go larger, and the probability of the wireless medium to transmit any data without collisions is very less. Thus theoretically this defines a maximum limit of the number of wireless nodes connected simultaneously to a single wifi router.

4.1.2 Problem of Electromagnetic Interferes

Since Wireless Networks works under frequencies which are publically available, there are a variety of other devices such as ZigBee devices, Bluetooth devices ,microwave ovens, ISM band devices, security cameras, video senders, cordless phones operate or even other wireless routers under almost same frequencies close to 2.4Ghz, hence there is a huge probability in densely populated areas for the frequencies of other devices to overlap on the channels used. Hence for deployment for high capacity networks care should be taken such that it the wireless devices wont suffer electromagnetic interference from other devices using the same channel.

16 4.2 Improving Scalability

4.2.1 Fair Channel Usage

The high throughput/bandwidth measured doesnt ensure fair usage of channel because of the fact that in DCF it is possible for a single wireless node to hog the channel once it acquired it for a duration of burst of consecutive frames. The IEEE 802.11b/g/n doesn’t ensure fair share of channel access. It is designed for maximum bandwidth. IEEE 802.11e has Qualitity of Service(QoS) support using priority queues, but this is also not available with commercial routers which are cheap. This option may not be available to many routers available today. Even if it available on the router through flashing custom opensource firmware, due to the interoperatability standard the connected wireless cards also need to have this mode which is highly unlikely. Most users today still have wireless cards which supports only 802.11 b/g today. And there is no interoperatability standard exist between 802.11e with legacy systems.

4.2.2 Channel Planning

Figure 4.1: 802.11b/g A.P frequency planning Figure 4.2: 802.11a A.P frequency planning

The Figure 4.1 and 4.1 show how the Access points should be deployed to minimize channel overlaps. Here each cell represents a single Access Point(A.P). Each cell(access point) can connect to 20 or 30 wireless systems. For 802.11 b/g the frequency of operation is 2.4Ghz with only 3 non-overlapping channels. But for 802.11a the frequency of operation is 5Ghz and the number of non-overlapping channels is 12. The Figure shows how they can be arranged in a hexagonal cell manner to avoid channel overlapping. For 2.4Ghz operation, a cell’s interference with another cell using the same channel frequency is just 1 cell away. But for 5Ghz operation a cell’s interference with another cell using the same channel frequency is almost two cell away. Each cell can accomodate 20 to 30 users. By this method, the A.P’s can scale horizontally to connect practically countless number of users. Only thing is that the Access points should be interconnected to switches of backbone via wired connection such as ethernet. There is still a small possibility of interference in terms of signals from wireless connected tablets/laptops. Since we can only control the signal strength of an A.P but not the wireless stations, the stations at the cell boundary of any cell can emit strong signal enough to interfere with next cell with same frequency at one cell distance from current cell, this may lead to hidden node problems. This is especially problematic in terms of 2.4Ghz band, since there is only single cell gap between cells of same frequency.

17 Chapter 5

Scalability in Higher Layers

5.1 Using IP Multicast

Although the support for multicasting exist on IP protocol since almost two decades, it is not widely used. One reason is because of the complexity involved in configuration and it is still a mystery for many ordinary users, network administrators. The difficulties lie in the implementation of routing tables to support the multicast operation which is not supported mode of operation of routers in general. IP Multicasting is supported by group addressing where a source doesn’t need to know the ip address of the receiver, clients which needs to be associated with a group by means of IGMP protocol. Packets are delivered to receivers that have declared their membership in the group over a tree that spans all such receivers. The challenge lies in construction of the path tree on each routers. Whenever new devices joins or leaves a group this information has to be updated with path tree. This tree can itself become an overhead when the number of routers increases. IP Multicast is suitable if there are more than one than one hop between source to destination.

5.1.1 Implementation Methods [9]

There are a lot of open source routing software available, this can be installed on a stand alone server. Some of the opensource routing software available are , B.A.T.M.A.N., Bird In- ternet routing , OpenBGPD, , XORP, GNU Zebra, . The server installed with this opensource router software should then be configured in a mode to provide support for building multicast trees on it through Internet Group Management Protocol(IGMP). The servers should be coupled with the router flashed with an OpenWrt firmware. Any Routers on the path between source and client which needs to support multicast needs to be replaced with this (Server with open source routing software + OpenWrt firmware flashed routers) combina- tion. If end user computer is behind NAT, it can not subscribe to multicast directly, so it needs some kind of proxy to do it for him. OpenWRT comes with igmpproxy utility to provide support automatically. A method of implementation of this technique is in detail is discussed in the paper[9].

18 5.2 Regulation of Wireless Traffic

In a classroom scenario it is possible to increase the capacity of the wireless network by selectively discarding packets other than intended by teacher and student tablet devices through protocol examination. From the software approaches to performance of chapter 3 , it is noted that a android tablet device may automatically try to connect to google servers or any other CDNs of applications installed on it. This leads to additional network traffic going on for android tablets. So the main idea is to identify this kind of other traffic data other than that of teacher student interactions and discard them. The challenge lies in identifying this other google server and CDNs datas. One way to realize is at router with application level sniffing analysis where routers are configured to ditch packets other than that indented by teacher device to students. But this method doesn’t completely improve the situation. Because the student tablet which is connected may still request for such data again and again which is still a overhead. The only overhead solved by this method is not to allow that some particular type to be downloaded. But still it doesn’t restrict the machine at medium access level . The request of such data is still a little overhead at connectivity level.

5.3 Scalability at Application Level

The experiments done on android programs suggests that improper application design can lead to hinder the scalability of the application run on the tablets. Background data contributes to overhead to the current network traffic. Some improper application design may make small data requests at very low latencies, and making channel always busy by frequent requests. Application scalability is another big topic on its own, with issues on databases , servers, load balancing, caching., etc.

19 Chapter 6

Protocol Customization

Tweaking or tuning is the process of modifying the existing system,application,protocol to get the maximum performance out of it. While it is not always done to improve only performance some times it can be done to accomplish a specific need. The following is one such method of modification of the protocol to suit the needs. The challenge lies in ensuring the compatibility of the protocol after modification to operate along similar devices. Other challenges include keeping up to date with different future versions of devices.

6.1 MAC Broadcast using Beacon Stuffing[8]

This paper [8] discusses a method of low bandwidth communication protocol for IEEE 802.11 networks that enables APs to communicate with clients without association. The idea is not for increasing the throughput but using this modification to support a low bandwidth broadcast transmission to all connected wireless devices from an access point. This is done by overloading 802.11 management frames with data while still maintaining the interoperatability of the proto- col. The beacon stuffing protocol is based on two main operation of wireless devices. First, the wireless clients receive a particular access point’s beacon signals even without associating with it. Second, it is possible to overload management frame with data.

6.1.1 Mechanism

This approach is based on the push model of information delivery. The key idea is to overload IEEE 802.11 beacons to carry additional information. Beacon frames are used to announce the presence of a Wi-Fi network. As a result, an 802.11 client receives the beacons sent from all nearby APs, even when it is not connected to any network. In fact, even when a client is connected to a specific AP, it periodically scans all the channels to receive beacons from other nearby APs to keep track of networks in its vicinity. The client does not have to transmit anything to receive the beacons; it merely has to listen. This push model is in contrast to the model currently being used where a client establishes an Internet connection, transmits information about its location (obtained in a variety of ways), and pulls information relevant to that location. Under common environmental conditions, the beacons frames have a range of 100-200 meters. All the information are treated as broadcast string of data bytes. The data can be anything ranging from text,audio,video,etc. only main thing is at the client side this information has to be ordered properly to make sense out of the data.

20 6.2 Device Customization

For many of the scalability issues identified almost all of the solutions requires some form of customization to support the operation stated. Customization modify cheap existing hardwares to make more out of it. But all existing wireless routers and wireless cards cannot be customized because it is mainly controlled by vendors. Most of the vendors dont want to make source for firmware open, in the fear of losing their market share to new growing company. For some of the hardwares available even if the code is opensource, some part of the code may use some form binary Hardware Abstraction Layer(HAL). Hence making this HAL unmodifiable eventhough its under opensource as a whole entity. The following methods are some of the methods to achieve some levels of customization.

6.2.1 OpenWrt

OpenWrt is a Linux distribution for embedded devices which can be used to customize the commercial Access Points to get the most out of it. In a nutshell using one can get features only found in expensive enterprise solutions by installing its firmware on a cheap router. It can be used as a study tool to get hands on experience with 802.11 network layer and other higher layer operations rather than studying through simulations which sometimes doesn’t give exact results. OpenWrt supports many Routers available today.

6.2.2 Opensource linux wireless drivers

There are several opensource drivers available for linux wireless devices. Although drivers are available as opensource for most of the devices the firmwares are available only in a binary form. Madwifi[13] is project which provides opensource drivers for Wireless LAN devices of Atheros wireless chipsets. MadWifi is one of the most advanced WLAN drivers available for Linux today. It is stable and has an established userbase. The driver itself is open source but depends on the proprietary Hardware Abstraction Layer (HAL) that is available in binary form only. ath5k and ath9k are newer version of this driver. ath9k is the youngest of the three drivers. Initial development was done by Atheros, who then released the complete source code to the community. ath9k supports all currently available 802.11n chipsets from Atheros. Many Realtek chipsets has complete opensource code available. Intel based cards use proprietary firmware.

21 Chapter 7

Experiments

The following experiment is a proof of concept for a method which does not have the limits of maximum no of simultaneously connected user to a single wireless Access Point/ Hotspot. Under existing mode of operation a single wireless access point is limited to a certain number of connections associated to it at a time. The recommended numbers range between 20 to 30 per access point. This may be because of the limited memory present in the Access points which has to store some details of list of wireless devices associated with it. After this memory gets exhausted , the access point may drop further connections. Hence if no such information are stored in data link layer level, and if End-to-End connection is maintained in application level, then it is possible to connect 100 or 200 of users from a single access point in a classroom like environment. Though the data rate may be low for this kind of communication since end-to-end connectivity is moved to the the protocol stack. But this method surely ensures guaranteed connection to simultaneously huge number of users. This method can be perfected and can be applied to scenarios such as conducting quiz to large number of peoples in a classroom environment from a single access point.

7.1 Overview

The 802.11 frames are classified into three types of frames management frames, control frames and data frames. Under normal operation each wireless client’s network interface card handles all these frames and only shows data which are intended for the particular device to the higher layers. Hence all management frames such as beacon frame, association request, association response, disassociation, authentication, deauthentication and control frames such as Request to Send(RTS) , Clear to Send (CTS) , acknowledgments.,etc are hidden to the other layers under the normal operation. They are filtered by the wireless card on the clients. There is a special mode which a wireless device can operate which is called monitor mode. This mode is not supported by some cards. Under monitor mode, none of the management and control frame are filtered. This mode is useful to see what’s going on on the network. It is possible to have the wireless card in both monitor mode and normal mode by means of the mac80211 framework for linux. When wireless devices are under this mode, it can see all the management and control frames which are not meant for it. The main idea is to exploit this method, and send datas along any one of this management frames and control frames. Considering a single server and multiple no of client model, by this method it is possible to send data by a server machine to all the

22 clients at once , since all data is visible to everyone without even the clients actually connecting to an Access point. But the received data has to be arranged in a meaning full format by the application layer of the client side since the End-to-End connectivity is done at the application layer instead of the Transport layer(since there is no actual connection involved).

7.2 Experimental Setup

The experiments where done with two different types of wireless cards. The first one was TP Link WL721N USB wireless card with atheros 9721 chipset. Although the ath9k htc driver available for this card was opensource, the firmware htc 9271.fw was proprietary and was available only in a binary form. The second was Intel Wireless WiFi Link 4965AGN adapter card(which came with laptop), and like the previous card, the firmware was available only in the binary form and a opensource driver wrapper. On sending machine airplay-ng package should be installed. This package provides the way to inject frames. Although this package was originally intended for wireless cracking with its additional set of packages, this experiment just exploits the tool for a different use. The transmiting machine must be patched with On receiving machines either airodump-ng tool needs to be installed or tcpdump which is already available in most of the linux distributions. As explained earlier there is no actual wireless connection made, and the wireless medium is simply used to broadcast data, and all data are visible to all wireless clients inside the signal range covered by the transmiting machine. The only requirement in the client side is to turn on the monitor mode. No additional tools is required to turn this mode in linux machine. It can be done using iwconfig command which is present by default for linux distributions. The datas can be viewed by tcpdump with filter for particular channel and mac id of transmitting node. This has to be preconfigured from the application level. However on sending machine the requirements of tools is slightly higher based on which type of custom management and control frames to generate and send. The amount of datas which can be send along with management frames like deauthentication and authentication is very less but it is relatively easy to configure any wireless card to send this type of frame. And it is also directly proportional to the opensource support the wireless card chipset on the sending station poses. In the experiments the deauthentication management frame was used as the frame to overload data. Since every wireless station sees this frame the destination address field was not useful, hence the data was transmitted in place of the destination address. From the sender machine a fake deauthentication frame was generated with required data in the destination address field and injected, the client machine with monitor mode was able to see this frame and hence the data was able to be retrived without even actually connecting to any wireless access points.

7.3 Throughput

The amount of data which can be transmitted directly depends on transmiting machine’s wireless cards support for opensource drivers and firmwares. If both driver and firmware of the wireless card’s chipset is available under opensource code, then there exists many ways of transmitting the data under maximum rate. However the firmware’s of most of the devices are available only under free license and in binary form. In a nutshell the data rate directly depends on the

23 802.11 custom frame generation mechanism from the sending device. The experiments where done using commercially available very cheap wireless cards. There exist high cost sniffers in the market which has the ability to completely generate all kinds of custom forged framed. The data transfer rates using these devices will be higher. The Throughput for broadcast operation, when only one machine is sending and all ’N’ number of client machines are receiving can be calculated by,

N ∗ E[D] S = (7.1) Backoff time + T ransfer time for E[D]

CWmin X CWmin(CWmin + 1) Backoff T ime = σ ∗ i P (i) = σ ∗ (7.2) 2 i=1 E[D] T ransfer time for E[D] = Length of frame (7.3) { channel bandwidth } Where, E[D] = Effective Data Size send through frame injection (7.4)

σ = Duration of a slot (7.5)

If E[D] = 12 bytes, Length of frame = 60 bytes, then S = 1kBps, 10kBs and 100KBps a for N=1, 10, 100 respectively. Here since all client nodes are simultaneous listening and getting data(broadcast), the effective throughput is multiplied with the number of client devices as long as all the clients are within the range of the sender machine. The throughput under acknowledgments is same as that of equation2.6 except the values of Tsuccess and Tcollision changes according to management frame headers.

24 Chapter 8

Conclusions

Analytical models gives insight into performance, and finding out the bottlenecks in a math- ematical way. By the use of Analytical models of performance it is clear that contention for wireless medium ( through Distributed Coordination Function) restricts theoretically limits the number of wireless users connected to a single access points. Although analytical models has been approximated to some extent for keeping the model relatively small, they still provide a valid way to theoretically identifying the limits of a wireless networks and invidual devices. On the Other hand, the performance Analysis of tablets done through software approches are mostly implemented through tools in which performance analysis is done at application level. Many of the inherent problems will be unable to measured since the details of complex underlying layers of protocols are not visible at application level. Application level performance analysis can be sometimes used by analytical models by constructing an approximated distribu- tion corresponding to the application level measurement. It has been noted from the literature survey that although theoretical solutions to the prob- lem statement expressed earlier started forming shape as early as from a decade before, the consumer ways of getting it is still limited, because of the unavailability of acheiving using com- mercially available wireless devices. And because of this most new ideas from the net- working research community remains on the shelf for a long time. Even if it is available as a product, it cannot be still deployed widescale because most of the newer wireless devices doesn’t always work along side of legacy devices. The custom modification to existing protocols on the other hand can be implemented on only few devices for which opensource drivers and firmwares available. Experimental results suggests the possibilities of a connection less data transfer by overload- ing the management frames, although the data transfer rate is less, it doesn’t put limits to the number of connection to a single access point which is ideal for scenario such as quiz condution in a classroom environment.

25 Chapter 9

Stage 2 Scope

The literature studies made helped in identifying the gap between theoretical solutions and its practical availablility. Analytical studies helped in identifying the underlying problems of wireless LANs mathematically. The work done in current stage 1 makes way to continue the work in the following areas for Stage 2.

• Implementation of a Framework whose main priority is supporting an easy to configure wifi hotspot on linux machine with high network capacity of serving 100 to 200 of users in a classroom environment at a time, through existing cheap wireless devices. The experiments made support this goal but it has to be shaped up to a complete product to easily configure and deploy datalink level Multicasting utilizing the broadcast nature of wireless access point. The main challenge of this is maintaining end-to-end connectivity as this has to maintained at application level.

• Construction of a Analytical models of the above framework, which takes more accurate details of the Tablet under android environment. Also to calculate the sizing,capacity of the infrastructure connecting many tablets through wireless.

26 Acknowledgements

It is my great pleasure and privilege to have Dr. Deepak B. Phatak, of the Department of Computer Science and Engineering as my guide and to take up the MTech Project under him. His inspiring guidance, experienced suggestions keeps me motivated to do research work in technologies supporting education. I also thank Mr. Nagesh Karmali for his valuable suggestions and open ended discussions which kept me motivated.

27 Bibliography

[1] K.S. Trivedi. Probability and Statistics with Reliability, Queuing, and Computer Science Applications, (second ed.) Wiley, New York (2001).

[2] G. Bianchi. Performance analysis of the IEEE 802.11 Distributed Coordination Function. IEEE JSAC, 18(3):535–547, March 2000.

[3] C. Foh and M. Zukerman. Performance analysis of IEEE 802.11 MAC protocol. In Proc. of the European Wireless Conference, pages 184–190, February 2002.

[4] Preetam Patil and Varsha Apte. 2005. Sizing of IEEE 802.11 wireless LANs. In Proceedings of the 3rd ACM international workshop on Wireless mobile applications and services on WLAN hotspots (WMASH ’05). ACM, New York, NY, USA, 96-99.

[5] Xuetao Wei, Lorenzo Gomez, Iulian Neamtiu, and Michalis Faloutsos. 2012. ProfileDroid: multi-layer profiling of android applications. In Proceedings of the 18th annual international conference on Mobile computing and networking (Mobicom ’12). ACM, New York, NY, USA, 137-148.

[6] Junxian Huang, Qiang Xu, Birjodh Tiwana, Z. Morley Mao, Ming Zhang, and Paramvir Bahl. 2010. Anatomizing application performance differences on smartphones. In Proceedings of the 8th international conference on Mobile systems, applications, and services (MobiSys ’10). ACM, New York, NY, USA, 165-178.

[7] Hossein Falaki, Dimitrios Lymberopoulos, Ratul Mahajan, Srikanth Kandula, and Debo- rah Estrin. 2010. A first look at traffic on smartphones. In Proceedings of the 10th ACM SIGCOMM conference on Internet measurement (IMC ’10). ACM, New York, NY, USA, 281-287.

[8] Ranveer Chandra, Jitendra Padhye, Lenin Ravindranath, and Alec Wolman. 2007. Beacon-Stuffing: Wi-Fi without Associations. In Proceedings of the Eighth IEEE Workshop on Mobile Computing Systems and Applications (HOTMOBILE ’07). IEEE Computer Society, Washington, DC, USA, 53-57. DOI=10.1109/HOTMOBILE.2007.3 http://dx.doi.org/10.1109/HOTMOBILE.2007.3

[9] Chmielewski, M.; Szyszkowski, P.; Piechowiak, M.; Application of IP multicast in embedded systems with OpenWRT, Communication Systems, Networks & Digital Signal Processing (CSNDSP), 2012 8th International Symposium on, vol., no., pp.1-5, 18-20 July 2012

[10] Oskar Andreasson. Ipsysctl tutorial 1.0.4, Sept 30, 2012 , Internet: http://www. frozentux.net/ipsysctl-tutorial/ipsysctl-tutorial.html , Sept 30, 2012.

28 [11] S. Spero. Analysis of HTTP performance problems, Internet: http://sunsite.unc.edu/ mdma-release/http-prob.html, Sept 30, 2012

[12] Table of Hardware. Internet: http://wiki.openwrt.org/toh/start, Oct 1, 2012

[13] Comparison of open-source wireless drivers. Internet: http://en.wikipedia.org/wiki/ Comparison\_of\_open-source\_wireless\_drivers. Oct 10, 2012.

29