Does Online Mobile Gaming Overcharge You for The Fun?

De-Yu Chen, Po-Ching Lin, and Kuan-Ta Chen
Institute of Information Science, Academia Sinica
Department of Computer Science and Information Engineering, National Chung Cheng University

PDF Version | Contact Us


With the growing popularity of online mobile games, the network traffic generated by them accounts for an increasingly significant proportion of mobile Internet traffic; however, the game's traffic characteristics have not been well studied. To understand more about such traffic, we analyze the network traffic of 9 online mobile games from 3 genres, namely, first-person shooting games, role-playing games, and racing games. Our results show that small payloads, high packet rates, and an excessive number of pure TCP ACK packets incur high traffic overheads. The payloads may have redundant content, which can be properly compressed. Given the increasing number of pay-by-volume and throttling 3G/4G data plans, gamers may not realize they are being overcharged due to such overheads. We also find that the overheads can be reduced without compromising users' gaming experience because the packet payloads are highly redundant. Furthermore, none of the UDP-based games implement TCP-friendly congestion control, which suggests that the quality of experience (QoE) provided by the games may be undermined by the possibility of congestion collapse.

1  Introduction

Online mobile games are computer games played on mobile devices, such as smartphones and tablets, via the Internet. They have been extremely popular, thanks to the rapid growth of mobile devices that are based primarily on Android and iOS. Recently, Nouch [2] reported that the number of mobile gamers surpassed the 500 million mark in 2012, and they spent more than US$9 billions. Meanwhile, Khalaf [3] found that Android and iOS users spend 32% of their time in playing mobile games, which rank first among all types of mobile applications.
Network traffic from mobile devices now accounts for a significant proportion of Internet traffic. A recent survey [4] found that global mobile network traffic amounted to 885 petabytes per month at the end of 2012; and it is expected to increase 13-fold by 2017. As the number of online mobile games continues to grow rapidly, the network traffic generated by them will increase significantly [5]. Meanwhile, flat-rate 3G/4G data plans are being replaced by pay-by-volume or "throttling" data plan [6]; that is, full bandwidth is only provided when the volume of data is below a certain threshold. If the volume exceeds the threshold, a throttled bandwidth will be provided for the rest of the billing period. Because of the increasing amount of mobile game traffic, careful accounting of the network usage of mobile games is required.
The traffic characteristics of other network applications, such web browsing and video streaming, have been widely studied [7,[8]. However, most network game traffic is ad hoc and highly dependent on the design and implementation of each game because there is no standard library, middleware, or transport protocol for online games, especially online mobile games. Moreover, fast-paced games, such as FPS, tend to use UDP instead of TCP as the transport protocol because the latter is regarded as less suitable for real-time gaming [9]. Therefore, the traffic characteristics of online games should be quite distinct from those of other popular network applications, and characterizing online mobile game traffic has become an important research issue.
Currently, it is difficult to determine if online mobile games have been properly designed. Plus, it is not known if such games overcharge players by sending out more traffic than necessary in order to overcome the uncertainty inherent in network transmissions. Our objective is to determine whether current online mobile games have been carefully designed and handle network communications adequately. An inappropriate network design may cause 1) players to be overcharged, and 2) less than satisfactory game QoE due to too few updates (too conservative) or unnecessary congestion (too aggressive) and 3) congestion collapse due to non-TCP-friendly traffic.
In this paper, we study 9 online mobile games from 3 popular genres, namely, first-person shooting (FPS) games, role-playing games (RPGs) and racing games (RCGs), on Apple's App Store ( Based on the results, we make the following observations:
  1. The payload size of online mobile game traffic is generally rather small, which implies that the overheads of packet headers are relatively high.
  2. Certain games, particularly those over UDP, have high packet rates, while some TCP-based games generate an excessive number of pure TCP ACK packets. Both types of games are associated with high packet header overheads.
  3. Some games constantly send highly redundant packets that could be aggregated and compressed without compromising the gaming experience. Furthermore, none of the UDP-based games send TCP-friendly traffic, and that may cause congestion collapse.
The remainder of this paper is organized as follows. Section II provides a review of related works. In Section III, we describe the measurement setup for collecting the game traffic traces; in Section IV, we inspect the characteristics of mobile gaming traffic, such as header overhead and TCP friendliness; and, in Section V, we investigate whether online mobile games over-charge players and how the problem can be remedied. Section VI contains some concluding remarks.

2  Related Work

According to Suznjevic and Matijasevic [10], research on the characteristics of online game traffic tries to improve the scalability, efficiency and quality of service of games in order to maximize gamers' experience. They noted that the common characteristics of interest are the packet rate, payload size, bandwidth usage, and packet inter-arrival time. Chen et al. [11] observed that the payloads of ShenZhou Online, a Massive Multiplayer Online Role Playing Game (MMORPG), are rather small, particularly in traffic sent from clients to the server. The low packet rate leads to a relatively high ratio of pure TCP ACK packets because, normally, no more packets arrive before the expiry of the delayed ACK timer, which is usually set at 200 ms. The observations imply that the overheads of packet headers are relatively high in MMORPGs. Kim et al. [12] found that client packets in Lineage are quite small and narrowly distributed, whereas server packets are distributed more widely. Lineage II has highly asymmetric upstream traffic and downstream traffic; the latter requires much more bandwidth than the former [13].
While there have been a number of researches on the traffic analysis of online games, to the best of our knowledge, none have been dedicated to study the traffic of online mobile games and the unique implications associated with mobile game traffic, such as data charging.

3  Measurement Setup

We selected 9 mobile games from 3 popular genres (FPS, RPG and RCG) for analysis. All the games (see Table I) can be played on Apple iPad 2 and freely downloaded from Apple's App Store (as of June 2013). Since they are online games, they can only be played whenever an Internet connection is available. Among the 9 games, the 3 RPGs send packets over TCP connections, while the rest (3 FPS games and 3 RCGs) use UDP as their transport protocol. This split is basically consistent with the following suggestions in an FAQ article on [14]: "slow-paced games (e.g., RPGs) can use TCP, while fast-paced games (e.g., FPS games and RCGs) should use UDP."
Table 1: The 9 online mobile games evaluated in this paper
Category Abbv. Full game title Release date Publisher Developer
ar Archetype HD Aug 19 , 2010 Villain Munkyfun
bia2 Brothers In Arms 2 Free+ Feb 28 , 2010 Gameloft Gameloft
sg SHADOWGUN Sep 28 , 2011 Madfinger Games Madfinger Games
ah7 Asphalt 7: Heat Sep 19 , 2012 Gameloft Gameloft
rr2 Real Racing 2 Dec 16 , 2010 Electronic Arts Firemint
sr Sonic & SEGA All-Stars Racing Feb 23 , 2010 SEGA Sumo Digital
oc Order & Chaos Online Oct 31 , 2011 Gameloft Gameloft
pl Pocket Legends Apr 2 , 2010 Spacetime Studios Spacetime Studios
wom The World of Magic Apr 15 , 2010 Com2uS Com2uS
We connected an Apple iPad 2 to a wireless AP, which is provided by a Wi-Fi capable PC with an Intel i7 920 CPU and Windows 7, and ran tcpdump on it to capture all the packets flowing through the computer. Figure 1 illustrates the network topology in our experiment.
Figure 1: The network topology of our experiment setup
We asked five gamers to play each of the 9 games for more than 10 minutes, and recorded the game traffic flowing through the Wi-Fi AP. The time spent in non-game-play intervals (e.g., the login screen, the chat room, and the player matching phases) were excluded from the trace. In a total, we have collected 458 minutes of trace, which comprises 756 millions of packets and 95.8 GB of data.

4  Traffic Analysis

In this section, we investigate the mobile game traffic in a number of aspects. We start from inspecting their traffic patterns, examine the source of high packet header overhead and the TCP-friendliness property. We conclude this section with an empirical estimation of the games' network bandwidth charges on the players. For brevity, we refer to the network traffic sent from the client to the server as client traffic, and that sent from the server to the client as server traffic.

4.1  Traffic Patterns

Figure  IV-A shows the cumulative distribution functions (CDFs) of the payload sizes (i.e., the packet sizes excluding the TCP/UDP/IP headers), the packet rates, and the bitrates for the client traffic in each game. Except sr, all the games have rather small payloads, i.e., most of them are 50 bytes or even smaller. While bia2, ah7, sr, and oc have slightly larger payloads in the server traffic, as shown in Figure  IV-A, the other games have small payloads in both directions of traffic.
client_traffic_cdf.png (a) Client traffic server_traffic_cdf.png (b) Server traffic
Figure 2: The CDF of the packet sizes, packet rates, and bitrates of observed game traffic.
The client packet rates of bia2 are generally higher than 80 pkts/sec, while those of the rest two FPS games are higher than 20 pkts/sec. Among the RPGs, pl has the highest packet rates as it generates 30 packets per second most of the time. The packet rates of the FPS games in the server traffic are higher than those in the client traffic, where the server packet rates of bia2 and sg can be even higher than 100 pkts/sec. In Section V, we will investigate whether such extremely high packet rates are really necessary for smooth gaming.
Considering the small payloads, the overheads of the TCP/UDP/IP headers (i.e., the total header length divided by the total packet length) are relatively high. Figure 3 shows the header overheads for each game. The rates indicate that the overheads are generally high due to two factors: 1) the small packets and 2) TCP pure ACK packets. It is noteworthy that a large number of client payload sizes are zero in the RPGs. These packets are pure TCP ACK packets because they simply acknowledge TCP information and do not carry any application data [15]. These pure ACK packets further increase the header overheads in the traffic of RPGs (as they use TCP to be the underlying transport protocol).
Figure 3: The TCP/UDP/IP header overhead in the game traffic

4.2  Pure TCP ACK packets

Figure 4 shows the ratios of pure TCP ACK packets in the RPG traffic. The server pure ACK packet rate is defined by the number of pure ACK packets sent to the server divided by the number of data packets (i.e., packets with a non-empty payload) sent by the server. The client pure ACK packet rate is defined similarly. According to the graph, almost every server data packet of pl triggers a pure ACK packet, which implies that 1) the delayed ACK mechanism [16] on the game client is ineffective; and 2) a prominently large traffic overhead due to packet headers (c.f., Figure 3). The phenomenon also occurs in the other two RPGs, though less evident. As shown in Figure 2, the RPG packet rates in both directions are similar; however, most of the client packets are pure ACK packets and most of the server packets are data packets.
Figure 4: The rates of pure TCP ACK packets in RPG traffic.
To verify our conjecture about the disabled delay ACK mechanism on the game client, we designed a pair of simple TCP client/server programs and conducted an experiment. In the experiment, the server program is running on a Linux and the client program is running on an Apple iPad2 in the same LAN. The server program sends out a one-byte message to the client every 1 second and 5 seconds respectively, and we record all the communications between both nodes using tcpdump. Then, tcptrace was used to compute how much time was elapsed before an ACK packet was generated in response to a new data packet [16]. We call the elapsed time as ACK delay time. The distributions of the ACK delay time from our simple TCP client/server programs and those from the RPG traffic traces are presented in Figure 5. As can be seen, the ACK delay time of the custom TCP client/server programs are uniformly distributed between 0 and 100 ms, which manifests a delayed ACK timer of 100 ms [16]. In contrast, the ACK delay time of oc and pl are extremely short with most of the delay time are nearly 0 ms, while those of wom show a mixed behavior-most of the pure ACK packets were sent with a 100-ms delay, but occasionally no ACK delay is present. The observations indicate that the delayed ACK mechanism on Apple iPad 2 is enabled by default, but mobile games can disable or even change the mechanism. We plan to look into this issue in the future.
Figure 5: The distribution of the ACK delay time for 3 RPGs and our custom client/server programs

4.3  TCP Friendliness

Next, we consider the 3 FPS games and 3 RCGs, which adopt UDP as the underlying transport protocol, and investigate whether the UDP flows from the games are TCP-friendly [17]. To assess the TCP-friendliness of the games, we asked five subjects to play the 6 games and simultaneously send bulk data over a specific number of TCP connections that compete for the bottleneck bandwidth with the game traffic. To do so, we set up another PC X which is connected to the Wi-Fi AP and let the bulk data be transmitted from the AP to X, so the bulk data transmission would compete with the traffic sent from the game server to the client over the Wi-Fi link. In addition, to ensure the game traffic is competitive with the TCP connections, we used dummynet to cap the bandwidth at twice the average server bitrate of each game; that is, for a game with an average server bitrate B, we set the network bandwidth limit at 2×B2. Each round lasted 2 to 5+ minutes, depending on the actual length of the game sessions; and for each game, we collected longer than 10 minutes of total traces.
Figure 6 shows the average server bitrates of the games with various numbers of TCP connections (between 0 and 5), where the bandwidth cap is shown in each of the sub-figures. The bitrates of the six games remain approximately the same, while the average bitrate of the TCP connections declines with the increasing number of TCP connections. The behavior continues even when the average bitrate of the TCP connections is significantly lower than that of game traffic. This observation suggests that the games do not implement TCP-friendly congestion control. Such a design would 1) degrade the gaming experience due to potential congestion collapse; and 2) be harmful to other TCP and TCP-friendly applications because the games would "steal" bandwidth from them when the network bandwidth is not sufficient. As online mobile games are becoming increasingly popular and aggregated gaming traffic is more significant, the TCP-friendliness issue could affect the performance of the mobile Internet if it is not dealt with carefully.
Figure 6: The average bitrates of UDP based games and TCP connections in the TCP-friendliness experiment.

4.4  Online Mobile Gaming Can Be Expensive

Under the pay-by-volume and throttling data plans now offered by major cellular Internet access providers, the high bitrates and high packet rates (and therefore the high traffic overhead) incur huge costs that will be passed on to gamers without their knowledge. Table III summarizes the cost per hour of the 9 games based on the measured bitrates of the games according to the data plan listed in Table II. We observe that certain games, such as bia2 and sg, cost players higher than US$5 per hour under certain data plans; and under the T-Mobile data plan in the UK, 8 out of the 9 games cost players more than US$1 per hour. These high charges make us ponder: Are the high packet rates and bitrates for gaming really necessary? We will address this issue in the next section.
Table 2: Data plans offered by selected cellular service providers
Company Data plan Monthly Free/ High-Speed Equivalent Charge
Fee Data Volume (per 100MB)
NTT DoCoMo (Japan) Xi Pake-hodai Flat $61.26 7,168 MB $0.85
AT&T (US) Plan for Tablets $50.00 5,120 MB $0.97
T-Mobile (US) Simple Choice $60.00 2,560 MB $2.34
Verizon (US) Share Everything $70.00 4,096 MB $1.70
T-Mobile (UK) Pay Monthly $46.60 1,786 MB $2.60
Vodafone (UK) Pay Monthly $38.20 2,048 MB $1.86
† Currency unit is all unified to US dollars.
Table 3: Per-hour 3G data charges for selected games
Japan US UK
DoCoMo AT&T T-Mobile Verizon T-Mobile Vodafone
ar $0.78 $0.89 $2.13 $1.55 $2.37 $1.69
bia2 $5.06 $5.78 $13.87 $10.11 $15.44 $11.03
sg $3.22 $3.68 $8.83 $6.44 $9.83 $7.03
ah7 $0.73 $0.83 $2.00 $1.46 $2.22 $1.59
rr2 $0.39 $0.44 $1.06 $0.77 $1.18 $0.85
sr $0.61 $0.70 $1.67 $1.22 $1.86 $1.33
oc $0.55 $0.63 $1.51 $1.10 $1.69 $1.20
pl $0.93 $1.07 $2.56 $1.87 $2.85 $2.04
wom $0.19 $0.21 $0.52 $0.38 $0.57 $0.41
Currency unit is all unified to US dollars. Hourly rate higher than $2.0 is highlighted in boldface.

5  Are Online Mobile Gamers Over-Charged?

According to Figure 2, we can see that a considerable disparity exists between the bitrates and packet rates of the games that belong to the same genre. For example, the average bitrates of the FPS games (ar, bia, and sg) are 20, 80, and 140 Kbps respectively, which correspond to ratios of 1:4:7 in their bitrates. It is undoubtedly that the communication requirements for each game can be very different due to differences in game design, the complexity of game scenes, the granularity of player actions, and the number of movable objects in the scene, etc; therefore, simply comparing the bandwidth usage of two games (even in the same genre) without considering those factors would be meaningless. However, given the surprisingly large difference in bitrates, in this section, we will investigate whether those online mobile games overcharge the gamers. In other words, do they send more traffic than necessary?

5.1  Payload Can Be Less Redundant

Figure 7: The compression rate of payload streams with various compressor window sizes
We find that an online mobile game, if not well tuned, tends to send more data than necessary in order to handle potential network impairments. In this case, the game's payloads would contain a high degree of redundancy if the payload is not encrypted or obfuscated before transmission. According to this rationale, we extract and concatenate the payload stream of each game, and use gzip with different-sized compression windows to compress the payloads in order to compute the compressibility of the stream. Figure 7 shows the compression rates (derived by dividing the size of the compressed payload by the payload's original size) for both client and server traffic with various window sizes. A lower compression rate indicates a higher compressibility and thus a higher degree of redundancy. A side-by-side examination of Figure 2 and Figure 7 reveals that, generally, the games with higher packet rates tend to have a higher degree of redundancy. For example, bia2 has a high packet rate and a low compression rate, while the three RCGs and wom have low packet rates and high compression rates (i.e., lower redundancy). To illustrate the relationship more clearly, we plot the compression rates versus the packet rates and bitrates of the games in Figure 8. The graph shows that the payload compressibility is generally proportional to the packet rates and bitrates of the game traffic. This evidences that a game with a higher packet rate and bitrate may not be due to a more complicated game scene; the reason might simply be that more redundancy exist in its traffic.
Figure 8: The packet rates / bitrates of games vs. the payload stream compression rates (8 KB window size)

5.2  Packet Rate Can Be Lower

From another aspect, we also wonder whether a high packet rate is necessary for real-time online mobile gaming. To address this issue, we chose three games with higher packet rates, namely, bia2, sg, pl, and conducted a user study to empirically investigate whether the packet rates could be reduced without harming the user experience. A modified version of dummynet, which emulates a designated packet inter-arrival time for the server traffic, was run on the Wi-Fi AP. That is, the packets sent from the server to the client would be aggregated in the dummynet queue and released every t ms. Ten experienced mobile gamers were recruited to play the 3 games with t set between 0 ms (no aggregation) and 400 ms (corresponding to 2.5 pkts/sec), and we observed whether they perceived any negative effect due to the lower packet rates. More specifically, the subjects were asked to report their perceived level of "lags" in each round on a five-level scale (i.e., no delay, mild delay, moderate delay, severe delay, and very severe delay). Figure 9 presents the levels of perceived lags by the subjects. According to the graph, aggregation delays up to 100 ms do not degrade the gaming experience of most players. That is, a game's packet rates can be safely reduced to 10 pkts/sec without significantly degrading the gaming experience. More conservatively, a game can adopt a 50-ms aggregation delay (equivalent to 20 pkts/sec) that would yield significant reductions in packet rate and bitrate without sacrificing the QoE of the gamers.
Given the above results, we consider that the packet rates of the 3 FPS games we studied send out server packets with unnecessarily high packet rates; more specifically, ar, bia2, and sg can send 20 pkts/sec without QoE degradation instead of sending out 40, 100, and 150 packets per second on average and overcharging their players with excessive bandwidth usage.
Figure 9: The perceived level of latency when playing games with packet aggregation

5.3  A Remedy Proposal

Given that online mobile games tend to send redundant traffic in an unnecessarily high packet rate, we propose to use a traffic optimization approach (i.e., aggregation plus compression) to resolve this issue without modifying the network engine of the games. The advantage of this approach is that it shifts the traffic optimization workload from the usually overloaded game developers to network programmers. Practically, the traffic optimization can be implemented in a socket-wrapper library, where the the aggregation and compression are applied to any data to be sent by socket calls, and the reverse functions are applied to any data that is just received from another peer.
We verify the efficacy of the traffic optimization approach via simulations. In our simulations, the aggregation intervals are set to 100 ms as this seem to be an acceptable setting to most players (c.f., Figure 9). Rather than using a fixed window size as in Figure 7, the compressor now invokes gzip to compress the accumulated payload in the dummynet queue right before a packet is being released; also, we enable gzip to accumulate the dictionary across successive compression operations so that it can simply reuse symbols that have been stored for earlier packets. Figure 10 shows the relative bitrates (relative to the original bitrate without optimization) of the server traffic with aggregation and compression. We observe that even only with aggregation, the bitrate can be reduced to 45% to 80% on average. When aggregation and compression are both applied, the effect is significant-the bitrates of the FPS games can be reduced to 16% to 32% of the original bitrates; on average the games' bitrates can be saved by around 50%. The worst case occurs for wom, which is expectable as it use of network bandwidth is quite conservative (with an average of 5 Kbps).

6  Conclusion

The gaming experience is visible to players, but the network bandwidth charges are relatively "invisible" to them. Therefore, online mobile game developers tend to over use network bandwidth to ensure the network quality of online gaming regardless the overcharges for 3G/4G data plans paid by the gamers. Moreover, overuse of the bandwidth may cause congestion collapse if the traffic is not TCP-friendly. In this work, we have shown that some online mobile games send more than necessary non-TCP-friendly game traffic, which would cause problems for game players and the mobile Internet. We propose a remedy solution to optimize gaming traffic without changing the cores of the games; the simulation results show that the solution can save up to 88% of bandwidth charges for games without sacrificing gaming experience.
Figure 10: The relative server bitrate assuming aggregation (with 100 ms intervals) and a gzip compression algorithm is used


[1] D.-Y. Chen, P.-C. Lin, and K.-T. Chen, "Does online mobile gaming overcharge you for the fun?" in Proceedings of IEEE/ACM NetGames 2013 (extended abstract), Dec 2013.
[2] J. Nouch, "Mobile games market grew 33 percent in 2012 to $9 billion," 2013,
[3] S. Khalaf, "Flurry five-year report: It's an app world. the web just lives in it," 2013,
[4] Cisco, "Cisco visual networking index: Global mobile data traffic forecast update, 2012-2017," 2012,
[5] R. Weber, "Mobile gaming website modojo sees record traffic," 2013,
[6] W. Gordon, "The death of unlimited data: What it means, and how you can keep your unlimited data plan," 2012,
[7] Y. Bhole and A. Popescu, "Measurement and analysis of HTTP traffic," Journal of Network and Systems Management, vol. 13, no. 4, pp. 357-371, December 2005.
[8] A. Rao, A. Legout, Y. sup Lim, D. Towsley, C. Barakat, and W. Dabbous, "Network characteristics of video streaming traffic," in Proceedings of the Seventh Conference on emerging Networking Experiments and Technologies, December 2011.
[9] K.-T. Chen, C.-Y. Huang, P. Huang, and C.-L. Lei, "An Empirical Evaluation of TCP Performance in Online Games," in Proceedings of ACM SIGCHI ACE'06, Los Angeles, USA, Jun 2006.
[10] M. Suznjevic and M. Matijasevic, "Player behavior and traffic characterization for MMORPGs: a survey," Computer Networks, vol. 50, no. 16, pp. 3002-3023, June 2012.
[11] K.-T. Chen, P. Huang, and C.-L. Lei, "Game Traffic Analysis: An MMORPG Perspective," Computer Networks, vol. 50, no. 16, pp. 3002-3023, November 2006.
[12] J. Kim, E. Hong, and Y. Choi, "Measurement and analysis of a massively multiplayer online role playing game traffic," in Proceedings of Advanced Network Conference, August 2003.
[13] J. Kim, J. Choi, D. Chang, T. Kwon, Y. Choi, and E. Yuk, "Traffic characteristics of a massively multi-player online role playing game," in Proceedings of ACM NetGames 2003, October 2003.
[14], "Networking and multiplayer FAQ," 2004, module=forums section=rules f=15.
[15] K.-T. Chen, C.-Y. Huang, P. Huang, and C.-L. Lei, "An Empirical Evaluation of TCP Performance in Online Games," in Proceedings of ACM Advances in Computer Entertainment Technology (ACE), June 2006.
[16] R. Braden, "Requirements for Internet hosts-communication layers," 1989, RFC 1122 (Standard).
[17] S. Floyd and K. Fall, "Promoting the use of end-to-end congestion control in the internet," IEEE/ACM Transactions on Networking, vol. 7, no. 4, pp. 458-472, August 1999.


1. †. A preliminary version of this paper has been published in the Proceedings of IEEE/ACM NetGames 2013 as an extended abstract (2 pages) [1].
2. We set a higher cap if a game cannot normally be played with 2×B bandwidth.

Sheng-Wei Chen (also known as Kuan-Ta Chen) 
Last Update September 19, 2017