B.Comp.

Dissertation

Power Aware Game Transport Protocol

for Mobile Multiplayer Games

By

Soh Yu Ming

Department of Computer Science

School of Computing

National University of Singapore

2009/2010
 B.Comp. Dissertation

Power Aware Game Transport Protocol

for Mobile Multiplayer Games

By

Soh Yu Ming

Department of Computer Science

School of Computing

National University of Singapore

2009/2010

Project No: H078700

Advisor: A/P Ananda A.L. and Mr Bhojan Anand

Deliverables:
Report: 1 Volume
Program: 1 Disc
 Abstract

Today’s mobile phones are powerful mini-computers capable of work and play. Applications
on the mobile phone are able to capitalize on the increasingly advanced hardware to provide a
user experience reasonably impressive. However, this accomplishment is short-lived because
it is limited by the battery’s lifetime. Applications like online games are especially power
hungry as they maximize the use of the network, graphics and CPU. This paper is part of a
bigger project, Power Aware Game API (PAG API) [1], which seeks to optimize the power
consumption when playing online games on a mobile phone through providing a power
aware middleware between the game and the device. Specifically, my research is targeted at
network transmission. A brief overview is provided in the beginning to give a sense of where
my work fits into the bigger picture. Following that, I will discuss the typical network
requirements of an online game, review the existing network protocols, present a new
protocol tailored to power saving and compare its performance with User Datagram Protocol
(UDP).

Subject Descriptors:
K.8.0 Personal Computing (General)
C.2.2 Network Protocols

Keywords:
Transport protocol, power/energy saving, games

Implementation Software and Hardware:

Microsoft Visual Studio 2008, Java Eclipse Galileo, Java JDK 1.5, Google Android
SDK 1.5 and NDK 1.5, Cygwin, HTC Magic mobile phone.
 Acknowledgement

I would like to express my gratitude to my supervisors, Professor Ananda and Mr. Anand, for
their patience and guidance. Many thanks to the research assistants, Mr. Pham Duc Dang and
Mr. Le Thanh Long, for their advice and assistance. Last but not least, I would like to thank
my family for their care and support, especially for the many late nights in completion of this
paper.
 List of Figures

1. Mobile game network scenario 1

2. PAG API flow diagram 2
3. TCP head-of-line blocking 7
4. PGTP Packet structure 10
5. Connection setup 12
6. Connection teardown 12
7. Bundled packet structure 14
8. PGTP state diagram 18
9. Implementation structure 19
10. Steps in opening client-server connection 20
11. Game screenshots 23
12. Packet sending interval 24
13. Test environment 24
14. Packet latency (PGTP, Resource Manager, bundling) 25
15. Effect of turning off wireless on the number of packets in send queue 26
16. Effect of turning off wireless on packet latency (bundling) 27
17. Comparison between number of packets in send queue and packet bundle 27
size
18. Effect of turning off wireless on packet latency (no bundling) 28
19. Packet latency (PGTP, no Resource Manager, bundling) 29
20. Packet delay jitter (PGTP, no Resource Manager, bundling) 30
21. Packet latency (PGTP vs UDP) 31
22. Packet delay jitter (PGTP vs UDP) 32
 List of Tables

1. Types of packet and channel 4

2. Power saving modes 16
3. PGTP API methods 22
4. Packet statistics (PGTP, Resource Manager, bundling) 25
5. Packet statistics (PGTP, Resource Manager, no bundling) 28
6. Packet statistics (PGTP, no Resource Manager, bundling) 30
7. Packet statistics (PGTP vs UDP) 31
 Table of Contents

Title i
Abstract ii
Acknowledgement iii
List of figures iv
List of tables v

1. Introduction 1
1.1 Power Aware Game API overview 1
1.2 Network Engine 4
1.3 Game transport protocol requirements 5

2. Related work 6
2.1 User Datagram Protocol 6
2.2 Transmission Control Protocol 6
2.3 Stream Control Transmission Protocol 7

3. Power Aware Game Transmission Protocol 9

3.1 Architecture 9
3.2 Packet Structure 10
3.3 Establishing a connection 11
3.4 Closing a connection 12
3.5 Data packet sending 13
3.6 Packet bundling 13
3.7 Keep-alive 15
3.8 Power save modes 16
3.9 State diagram 18

4. Implementation 19

4.1 Initial implementation 19

4.2 Final implementation 19

4.3 PGTP API 21

5. Evaluation 23
5.1 Packet characteristics 23
5.2 Test environment 24
5.3 Results 25

6. Conclusion 33

References vi
 1. Introduction

1.1 Power Aware Game API overview

With the proliferation of wireless technology, more end users are using their mobile devices
to play online games. These devices employ a variety of wireless technology including 3G,
GPRS and Wifi to connect to the game server. As per online games, the end user experience
is always affected by the client-to-server latency and bandwidth. For playing online games
on a mobile device, the experience is further affected by the device’s battery power. While
wireless and mobile CPU technologies are getting better, battery technology is not advancing
a comparable pace. Online games, unlike the regular mobile applications, consume more
power as they are naturally more computationally intensive and use more hardware
components including audio, display and network to their fullest capacities. The battery is
unable to meet the game’s huge power demand and thus the lifetime is greatly decreased. To
address this issue, we introduce the Power Aware Game API (PAG API), a middleware
which enables the clients to manage network and client resources to increase the power usage
efficiency without sacrificing the user experience.

Figure 1. Mobile game network scenario

1
The basis of our power optimization techniques is built on the understanding of the current
game state. Being “aware” of what is happening allows us to make certain decisions which
will save power without affecting the game performance significantly. In an earlier related
paper [2], the authors broadly classified game actions into critical and non-critical. A critical
game action is defined as an activity “that cannot experience any quality loss” such as
shooting in a First Person Shooter (FPS) game. The approach is to turn off the network
device during non-critical events so that the game can continue without significant impact
from the dropped or delayed packets. Based on the collected user activity levels of the Quake
II game, the authors were able to calculate the power savings if non-critical actions were
dropped or delayed. The results presented were promising but as the paper had indicated, the
data was manually collected from a single game. To extend the power saving technique to
any game, learning the game activity has to be automatic and unbiased of game genre. PAG
API aims to achieve that by allowing the game to pass genre unspecific hints to a resource
manager. This middleware will then make intelligent energy conservation decisions to control
the hardware devices of the mobile phone. The diagram shown in figure 1.1 gives the general
flow of the PAG API.

Figure 2. PAG API flow diagram

2
Below is the breakdown of the PAG API components:

Game
This is the game application itself. The game passes game “hints” to the Resource Manager
for processing. The game also passes data to the Network Engine to be sent to the game
server.

Resource Manager
This component is the “brain” of the PAG API. It takes in inputs from the Game and
information of status of the wireless device, cpu and battery life to make an informed
decision to control the power consumption of the hardware. It also exercises influence over
the Network Engine to control the network traffic behavior.

Network Engine
The Network Engine provides a network socket interface to the game and is responsible for
the flow control of the network traffic. Instructions from the Resource Manager are used to
fine tune the performance for power saving. My research focuses on the design and
implementation of the Network Engine.

OS/Hardware
The Resource Manager retrieves information regarding the wireless device, CPU workload
and battery from the OS/Hardware. The Network Engine sends the packet through the raw
sockets.

3
 1.2 Network Engine

The Network Engine is responsible for energy and bandwidth efficient network control. It is a
software approach to optimize the usage of the network device. As the Resource Manager can
turn off and on the network device, the Network Engine needs to manage the packets sent by
the game through its socket interface. The network traffic of an online game is also quite
different from other applications. An online game usually sends small packets in a consistent
and relatively slow rate [3]. By looking at the network traffic of an online game, the Network
Engine can be designed to handle the packets in a way which is bandwidth efficient. For
example, in a typical online game, some packets are time sensitive (for eg. movement update).
This means that a delayed packet may not longer contain useful information. If a newer
packet is generated with the latest information, the delayed packet can be simply dropped.
Chat messages can be sent unreliably and a dropped chat packet would not significantly
impact the game. In contrast, score updates can be delayed but they cannot be discarded. The
Network Engine should be able to support these different types of packet requirements to
effectively optimize the network traffic. The table below gives some examples of the packet
types and their associated type of channel required:

Table 1. Types of packet and channel

Type of packet
Ψ + # Type of channel
Example Time sensitive Critical* Order Priority
Important game Reliable, realtime,
Yes Yes Important High
world event ordered, prioritized
Movement Reliable, realtime,
Yes Yes Important Normal
update ordered
Not Reliable, buffered,
Score update No Yes Normal
Important unordered
Not
Chat Yes No Low Unreliable
important
Ψ
Time sensitive packets should be dropped if delayed
* Critical packets cannot be dropped
+
Packet’s order-of-arrival at destination
#
Priority of a packet (a higher priority packet will be processed first)

4
 1.3 Game transport protocol requirements

Having discussed the characteristics of a typical online game’s network traffic, I present
some recommendations for an ideal game transport protocol. It is worth mentioning that the
following points are made with energy conservation in mind.

 Lightweight and low overhead

o It has been shown that 98% of game packets have a payload of less than 32
bytes [3]. Thus, the overhead incurred by a transport protocol in managing the
connection should be proportionally small compared to the payload.

 Datagram-oriented
o Since a game packet is a complete piece of information by itself, it would
make sense to send and receive using datagram instead of bytes.

 Provides a range of delivery methods in a single connection

o Unreliable channel – packets that do not considerably affect the game if they
are lost or arrived out-of-order.
o Reliable channel – critical packets whose delivery must be guaranteed.
o Semi-reliable channel – time-sensitive packets that have become obsolete can
be dropped.
o Ordered arrival – critical packets whose order-of-arrival matters.
o Unordered arrival – critical packets whose order-of-arrival does not matter.
o Lifetime – time-sensitive packets should be discarded if their lifetime has
expired.
o Priority processing – important packets should be processed first.

 Allows throttling of transmission speed and temporary disconnection

o The protocol must permit parameter fine-tuning by the Resource Manager.
Most importantly, it should have built-in support for temporary disconnection
when the network device is turned off or put to sleep for power saving.

5
 2. Related Work

In this section, I look at the existing transport protocols and discuss their suitability as a game
transport protocol for the Network Engine.

User Datagram Protocol (UDP)

The UDP is a connectionless transport protocol that provides a best-effort delivery [4]. It has
a very small overhead (8 bytes header) and it preserves the message boundary of the data. It
makes no guarantee of the order-of-arrival and provides no indication if the packet is received,
dropped or duplicated. When data is passed to a UDP socket, it is not buffered but sent
immediately. UDP has low latency because of the little protocol overhead. However, to use
UDP as a game transport protocol, reliability and ordered delivery needs to be handled by the
game itself.

Transmission Control Protocol (TCP)

The TCP is a connection oriented transport protocol [5]. Packets sent are guaranteed to be
delivered and their order-of-arrival is enforced. TCP operates on the principle of byte stream
and has no concept of message boundaries. Data passed to a TCP socket is added to a byte
buffer and each byte received by the receiver is explicitly acknowledged. If an
acknowledgement is not received in a specified time frame, the sender resends the data and
waits for the acknowledgement. In addition, if an out-of-order byte is being received, it is
discarded or buffered. TCP will withhold the buffered data from the application until the
proper byte is received. This causes the head-of-line blocking problem shown in figure 2.1.

Since TCP is byte-oriented, the receiver is responsible to reconstruct the message structure
from the byte data. Congestion and flow control are implemented to throttle the sending rate
to avoid packet loss due to a congested network or an overloaded receiver. For these features,
TCP needs a bigger header (at least 20 bytes header) and thus incurs more overhead per
packet sent.

In a paper on TCP performance [9], the authors collected and analyzed game traces from
ShenZhou Online, a popular massively multiplayer online role playing game (MMORPG).
They found that TCP had features that make it unsuitable for online games. From the game
6
traces, it was shown that 46% of the bandwidth was occupied by packet headers alone. They
also found that congestion control and fast retransmission failed to correctly. Due to the
nature of games, data is not generated frequently and this causes lost packets to be detected
mostly through timeout. When timeout occurs, the congestion window is reset and this
reduces the amount of data that can be sent. The delay caused by waiting for a timeout before
resending a lost packet also introduces additional latency. The authors reasoned that some
packets can be processed out-of-order to avoid head-of-line blocking, which introduces
unnecessary latency and delay jitters.

Figure 3. TCP head-of-line blocking

Sender Receiver Receiver’s app
100
ACK 200
200
lost
300
iTitl
e ACK 200
Abst
ract
Receiver’s application cannot get byte 300-399 because
byte 200-299 has not been received.
 I
n
t
r
Stream Control Transmission
o Protocol (SCTP)
Broadly speaking, SCTP is a combination d of UDP and TCP. It is a connection oriented
u
transport protocol that provides unreliable-realtime,
c reliable-buffered-ordered and reliable-
buffered-unordered channels [6]. In SCTP, t an end-to-end connection is defined as an
i
association and many streams are multiplexed
o into a single association. Unlike TCP, a stream
n A chunk is akin to a datagram in UDP so the
is chunk-oriented instead of byte-oriented.
o P
message boundary of the data is preserved. SCTP o implements packet acknowledgement,
ordered delivery, congestion and flow control in a wmanner similar to TCP.
e
r
On top of the features provided by UDP and TCP, SCTP allows many “sessions” in one
A
single connection. These “sessions” are called streams.
w Each stream in SCTP behaves like a
a
connection and is independent of all other streams. This resolves the TCP head-of-line
r
blocking problem since a blocked stream does enot affect the remaining streams. Having
multiple streams also allows logical partitioning ofGpackets. For example, a game may wish to
a 7
m
e

A
send data and command packets separately. UDP and TCP would need 2 sockets whereas
SCTP requires only one socket, with the data and command packets sent in different streams.
SCTP also supports reliable-unordered delivery which essentially avoids the head-of-line
blocking problem. It should be noted that each stream can carry different delivery channels.
Redundancy is built into SCTP through its multi-homing feature. Each end of the association
can be represented by multiple IP addresses. If the primary IP address becomes unreachable,
SCTP will try sending to the secondary addresses. This makes SCTP fault tolerant and is well
suited in a wireless environment where the network is more susceptible to failure.

SCTP can be extended to provide more features. The Partial Reliability SCTP (PR-SCTP)
extension provides timed-reliability by dropping a packet that fails to send after its lifetime
has expired [7]. However, if the packet has been sent but not yet acknowledged, it will still be
re-sent even if the retry time exceeds the lifetime. Inter-stream Priority SCTP (pSCTP)
extension introduces the idea of assigning priorities to each stream [8]. Streams are processed
based on their priorities to service important packets first.

To provide a wide range of features, SCTP has to send a lot of control information in its
header. With a common header of 12 bytes, SCTP requires an additional 16 bytes for each
data chunk header, which is exclusive of the data payload. To acknowledge, a minimum of 16
bytes are needed for the SACK chunk header. For a typical packet which contains data and
acknowledgement, the total overhead incurred is at least 44 bytes. Since most game packets
are less than 32 bytes [3], more than half of the packet contains non-data and this makes
SCTP very inefficient. As SCTP is a connection-oriented protocol, it does not have support
for temporary disconnection. Custom modifications can be made but the potential amount of
change and effort may warrant it impractical.

8
 3. Power Aware Game Transport Protocol

The Power Aware Game Transport Protocol (PGTP) is a flexible multi-channel transport
protocol. It supports temporary disconnection, thus “flexible”, and it is capable of working on
its own or together with the PAG API. PGTP treats data at the message-level and provides
transmission over unreliable, reliable-ordered and reliable-unordered delivery channels. The
game is able to specify parameters to describe how each data should be sent. These
parameters indicate the delivery channel, order-of-arrival, data priority and lifetime. Data is
processed in a highest-priority first-come-first-serve basis. If the data is flagged for the
unreliable channel, it is simply sent. For data using the reliable channel, the send queue
blocks and retransmit until an acknowledgement is received. During this blocking period, if
there are data in the queue that are bound for the unreliable channel, they will bypass the
block and be sent. Before sending each data, PGTP checks the lifetime parameter and drops
the data if it has expired. Multiple data can also be sent in a bundle to save bandwidth. During
the “connected” state, if the connection is idle, KEEPALIVE messages are sent periodically
to probe its status. When PAG API signals that the network device has been turned off, PGTP
enters the “disconnected” state where all sending are paused to prevent unnecessary
transmission.

3.1 Architecture
PGTP is designed to be implemented directly over the IP layer. However, to simplify
implementations, PGTP is built over UDP to avoid dealing with raw sockets.

PGTP uses two queues to store data. As data is passed from the game, PGTP inserts them
into a send queue according to their priorities to be sent later. It uses one stream for sending
of all packets to save on bandwidth. This is unlike SCTP, which uses a logical stream for
each delivery channel, resulting in very large packet headers. When packets are received, the
data is extracted and put into a receive queue. The data in the receive queue is de-queued
when the game calls the PGTP’s receive method.

9
 3.2 Packet structure
The PGTP header is designed to be as “slim” as possible to save on bandwidth. The common
header requires only 2 bytes. The Sequence field is optional and is added if the Reliable flag
is set to 1. Similarly, the Acknowledgement field is added only if the ACK flag is turned on.
No field is dedicated for payload length since this can be calculated by subtracting the header
size from the packet length.

16 bits 16 bits

Source Port Destination Port

UDP header
Length Checksum

PGTP
ACK

Type R O F B P Unused
common header

Sequence Optional
number sequence number

Acknowledgement Optional
number ACK number

Payload

Figure 4. PGTP Packet structure

Type – 4 bits
This field specifies the type of the packet.
 0000 – OPEN
 0001 – DATA
 0010 – KEEPALIVE
 1111 – CLOSE
 0011 – INTEREST
o The type INTEREST is used by the Resource Manager in PAG API. It has no
effect on the transmission behaviour of PGTP.

10
Reliable (R) – 1 bit
The reliability flag. When set to 1, this packet has a Sequence number and requires an
acknowledgement from the receiver.

Ordered (O) – 1 bit

The order-of-arrival flag. When set to 1, the receiver drops the packet if the Sequence number
is not within the range of the receive window.

Fragmented (F) – 1 bit

When set to 1, this packet contains only a fragment. When set to 0, this packet is the last or
only fragment. The order of fragment is given by the Sequence number.

Bundled (B) – 1 bit

When set to 1, it indicates that this packet contains more than 1 sub-packet.

Acknowledgement (ACK) – 1 bit

When set to 1, this packet carries an Acknowledgement number.

Priority (P) – 3 bits

This field specifies the packet priority. A bigger number corresponds to a higher priority.

Unused – 4 bits
This field is reserved for future use.

3.3 Establishing a connection

To simplify initial design, PGTP uses a 2-way handshake to establish a connection. The
Sender sends a packet with Type field OPEN to the Receiver. The Receiver acknowledges
the packet by sending a packet with Type field OPEN and Acknowledgement field set to 1. If
an acknowledgement is not received from the Receiver after some time, the OPEN packet is
retransmitted. If the number of resends exceeds the maximum number of retries, the Receiver
is deemed unreached and the connection fails. Note that no Sequence or ACK number is
required when establishing a connection.

11
 Sender Receiver

ACK
Type R O F B P
OPEN

ACK
Type R O F B P
OPEN 1

Figure 5. Connection setup

3.4 Closing a Connection

To close a connection, the Sender stops sending data and sends a CLOSE packet to the
Receiver to wait for the acknowledgement. Upon receiving the CLOSE packet, the Receiver
stops sending data and sends a CLOSE Acknowledgement packet. The Receiver then waits
for a period of time before terminating. This wait period is to allow the Sender to retransmit
the CLOSE packet if it fails to receive the CLOSE ACK packet. If a CLOSE packet is
received during this wait period, the Receiver resets the wait period timer. When the Sender
receives the CLOSE Acknowledgement packet, it terminates the connection immediately.
Note that no Sequence or ACK number is required when closing a connection.

Sender Receiver
ACK

Type R O F B P
CLOSE
ACK

Type R O F B P
CLOSE 1
Wait
Closed

Closed

Figure 6. Connection teardown

12
 3.5 Data packet sending
To send data, the Type is set to DATA and the appropriate flags are set, based on the
parameters specified by the game. If the Reliable flag is set, the Sequence number field is
added. Similar to TCP, this sequence number is used for identification purposes. But unlike
TCP, this sequence number identifies a packet instead of a byte. The reliable packet is placed
on a timer to be sent repeatedly until an acknowledgement arrives or if the maximum number
of retries has been exceed. While the packet waits for acknowledgement, the send queue is
scanned for data to be sent. Data requiring the reliable delivery channel are put on hold while
data bound for unreliable delivery is removed from the queue and sent immediately.
Unreliable data are not blocked because they do not need an acknowledgement and
consequently do not need to be resent. This prevents unnecessary packet hold up.

If the ACK flag is set, the ACK number field is added. Like TCP, the acknowledgement
number is used by the Receiver to notify the Sender that the reliable data has been received
and the Sender can proceed to send the next data specified by the number. The reliable data
received must have a sequence number that is expected by the Receiver. If the sequence
number is unexpected, the Receiver resends the expected sequence number. The Sender
receives the acknowledgement number and sends the expected data.

When data from the game is larger than the network’s MTU, the data is split into fragments
and sent separately. All fragments of data are sent reliably using different sequence numbers.
All fragments except the last have the Fragment flag set to 1 while the last fragment is set to
0. When the Receiver encounters the first packet with Fragment flag set to 1, that packet is
buffered to wait for the remaining fragments. As more fragments arrive, the Receiver
arranges them using their sequence number. When the Receiver encounters the last packet
with Fragment flag set to 0, the fragments are merged and passed to the game.

3.6 Packet Bundling

To reduce the bandwidth usage, many small packets can be bundled together and send as one
big packet. A new field is added to the start of each sub-packet to denote its length. The
common header is also added since each sub-packet may have varying transmission
properties. However, only one Sequence number and one ACK number is needed. If any of

13
the sub-packets have the Reliable and ACK flags turned on, the corresponding flags in the
first header will be set regardless of the transmission properties of the first sub-packet. This is
to denote the inclusion of the Sequence number and ACK number fields at the beginning. If
the Reliable flag is set, the bundled packet is to be acknowledged as a whole. The Reliable,
Bundled and ACK flags in the remaining common headers are then ignored.

Payload Length – 16 bits

This field indicates the length of the payload.
ACK

Type R O F B P Unused Sequence

number Acknowledgement
number Payload length

Payload #1
ACK

Type R O F B P Unused Payload length

Payload #n

Figure 7. Bundled packet structure

Packet bundling minimizes bandwidth usage by sending lesser headers. For example, given 5
unreliable packets to send, the total header size is calculated as:

Unbundled size = (UDP header + PGTP header) * packets

= (8 + 2) * 5
= 50 bytes

Bundled size = UDP header + (PGTP header + payload length) * packets

= 8 + (2 + 2) * 5
= 28 bytes

14
For unreliable packets, PGTP can save up to 44% of the original packet header size. For
reliable packets, the saving is even greater at 50% because only one Sequence number is
required.

Unbundled size = (UDP header + PGTP header + Sequence number) * packets

= (8 + 2 + 2) * 5
= 60 bytes

Bundled size = UDP header + Sequence number + (PGTP header + payload length) * packets
= 8 + 2 + (2 + 2) * 5
= 30 bytes

Besides saving bandwidth, packet bundling also helps to improve throughput. When there are
many reliable packets to be sent, the send queue is blocked until the current reliable packet
has been acknowledged. By bundling them together, these reliable packets can be sent
immediately, eliminating the time wasted on waiting for acknowledgement. This is
particularly useful when the network device is switched off by the PAG API Resource
Manager. As PGTP is notified of the switch off, all sending are paused. However, because
the game is not aware of the switch off, it continues to send data to the transport protocol.
This results in an accumulation of data in the send queue. When the network device is
switched on again, there is a sudden burst of data to be sent. Without packet bundling, these
data will take a longer time to be transmitted and this would cause undesirable delay jitter in
the game. With packet bundling, the artificial delay introduced by the Resource Manager
would be greatly minimized.

3.7 Keep-alive
After the connection has been established, the Sender knows the Receiver is still reachable
when it receives an acknowledgement for a reliable packet or when it receives a data packet.
If the Sender only sends unreliable packet and the Receiver does not send any data, the
Sender would not be able to detect a disconnected Receiver until it sends a reliable packet. As
such, probe packets are sent periodically when the last reliable packet was sent too long ago.
A KEEPALIVE timer is used to keep track of this duration. When the timer expires, a
KEEPALIVE packet is sent and it waits for an acknowledgement. The timer is reset

15
whenever a KEEPALIVE ACK or a normal ACK is received. When an acknowledgement is
received after repeated sending, the connection is deemed “broken”.

3.8 Power saving modes

Unlike conventional transport protocols that only interpret the network to manage packet
sending, PGTP factors in the state of the game and network device status to optimize power
and bandwidth consumption for online games on mobile phones. PGTP gets the game and
network states from the Resource Manager to adjust its transmission behavior accordingly.

PGTP operates in 5 modes that control how long packets are buffered. The modes are
determined by the network device status, criticality of game state and quality of the network
state.

Modes:
1. Optimal – no buffering
2. Good – short buffering duration
3. Normal – medium buffering duration
4. Saving – long buffering duration
5. Suspended – indefinite buffering duration

Net State Good Average Bad Wireless off

Game State
Non-critical Saving Normal Good Suspended
Semi-critical Normal Good Optimal Suspended
Critical Good Optimal Optimal Suspended

Table 2. Power saving modes

When the Resource Manager switches off the network device to save power, the PGTP is
notified and it goes into the Suspended mode to stop all sending. When the network device is
switched on, the Resource Manager passes the game and network states to PGTP. If the state
of the game is critical, the PGTP tries to send the packets as soon as possible to minimize any
disruption to the game. If the game state is less critical, PGTP will buffer the packets for a
longer period of time before sending. Through buffering, packets are accumulated in the send

16
queue and this increases the frequency of bundling. Although this would increase the latency,
the delay is tolerable as the game is not in a critical state. In addition, by buffering for a
longer duration, packets are more likely to expire. When a packet has expired, it is not send
but dropped. Since the packets are dropped during the non-critical state, it is not likely to
cause significant disruption to the game. Together with bundling, this translates to more
bandwidth saving.

In conjunction game state, the network state affects the buffering duration. If the game is in a
non-critical state but the network is poor, PGTP tries to send the packet as soon as possible.
This is to prevent adding on to the long latency caused by the poor network. If the game state
is non-critical and the network is good, PGTP will buffer the packets for a longer duration.

17
 3.9 PGTP state diagram
The diagram below gives the overall view of the transitions between the states of PGTP.

Figure 8. PGTP state diagram 18

 4. Implementation

The development destination was a Google Android OS mobile phone. The Android OS only
supports Java applications and linked native C libraries. To achieve the highest performance,
the first version of PGTP was implemented in C language and linked to a Java application
using the Java Native Interface. The game communicates with the PGTP through Java
method calls that are hooked up with the native C codes. The development process was very
challenging as C has primitive support for memory management, thread controls, data
structures and data synchronization. The phone emulator provided by Google Android OS
had limited support for debugging, making it hard to trace error messages and thus increasing
the development time substantially. I was able to implement multi-threaded unreliable and
reliable sending but was eventually impeded by a bug that took too long to trace. Eventually,
due to the lack of time, I decided to rewrite the program using Java.

Figure 9. Implementation structure

The second and current version includes most of the features of PGTP. It is multi-threaded
and has support for unreliable and reliable sending, packet bundling, proper connection
establishment, power saving modes and temporary disconnection. The PGTP API methods
are modelled after TCP’s. For the client socket, there are the standard constructor, send,
receive and close methods. For the server socket, besides the standard constructor that opens
a listening port, it has an accept method which returns a client socket to a connected client.
The server socket maintains a queue of connected client and each accept method call de-
queues a client socket. The client socket has the send, receive and close methods to interface
with the client.

19
Figure 10. Steps in opening client-server connection

20
The following table details the PGTP API methods

Client Socket class

constructor ClientSocket(String address, int port)
Creates a PGTP socket and connects it to the specified port number at the specified IP
address.

Parameters:
 address – the IP address of the destination host
 port – the port of the destination host

void send(byte[] data, boolean reliable, boolean ordered, int priority, int lifetime)
Sends the data array using the specified delivery parameters.

Parameters:
 data – the byte array containing the data to send
 reliable – if true, the data is sent reliably
 ordered – if true, the data must be received in-order before passing to the caller
of receive()
 priority – sets the priority of the data. 0 being the lowest and 7 being the highest
priority
 lifetime – sets the relative time in milliseconds before the data expires

byte[] receive(boolean blocking)

Call to receive incoming data. Returns a byte array containing the received data.

Parameters:
 blocking – if true, the method blocks until new data arrives

Returns:
 a byte array. If blocking is false, the array might be null

void void updateStatus(boolean wifiOn, int gameState, int netState)

This method is used by the Resource Manager to update the socket of the state of the
wireless device, game and network.

Parameters:
 wifiOn – if false, the socket pauses all sending
 gameState – 0 is critical, 1 is semi-critical and 2 is non-critical game state
 netState – 0 is good, 1 is average and 2 is bad network state

21
Server Socket class
constructor ServerSocket(int port)
Creates a PGTP server socket to listen for incoming connection on this port.

Parameters:
 port – the port to listen for incoming connection

ClientSocket accept(boolean blocking)

Listens for a connection to be made to this socket and accepts it.

Parameters:
 blocking – if true, the method blocks until a new connection is made

Table 3. PGTP API methods

22
 5. Evaluation

To evaluate the performance of PGTP, packets traces from the Armageddon game were
collected. Armageddon is a multiplayer online role-playing game created by the PAG API
team for testing purposes. Because no games have implemented the PGTP yet, Armageddon
was developed to include the transport protocol and the rest of the PAG API. In the
Armageddon game, each player controls an avatar that moves between game maps and
attacks monsters. The game packets were recorded for a period of 5 minutes with 4 players
connected to the game world. The pictures below are screenshots of the game in action.

Figure 11. Game screenshots

5.1 Packet characteristics

From the traces, 1748 packets were collected during the 5 minutes play test. Out of all the
packets, 99.7% were sent unreliably and the remaining was sent reliably. 99% of the client
packets were 6 bytes long. Most of the packets were sent at 110 to 120 ms interval. These
characteristics are in line with the general online game packet characteristics.

23
 Frequency Cumulative %

700 100%
Frequency of packets (# packets)
90%
600
80%
500 70%
400 60%
50%
300 40%
200 30%
20%
100
10%
0 0%

sending time (ms)

Figure 12. Packet sending interval

5.2 Test environment

To compare the performance, the same game packets are sent using different transport
protocols and settings. The sending of the game packets is replayed using the timestamp that
was recorded earlier. To simulate a more realistic geographic distance between the game
client and server, the server is originally deployed in NUS whereas the client connects from
home at Ang Mo Kio. However, due to the inconvenience of having to travel back and fro
from home to school to fix or change the code in the game server, the server is also hosted at
home. Instead, a packet relay program is hosted in school and the client and server connects
to each other through the relay. In this way, a greater distance is simulated and with more
convenience.

Figure 13. Test environment 24

 5.3 Results

In this section, I present the results of PGTP under different settings and the results of UDP.

PGTP with Resource Manager and bundling

The Cumulative distribution function (CDF) graph below show the latency experienced by
packets sent using PGTP. The latency is calculated as the time the packet is received and
passed to the game layer, minus the time the packet is passed down from the game layer. This
version of PGTP receives status updates from the Resource Manager to adjust its
transmission behaviour. Since the input from the Resource Manager would cause the packets
to buffer longer and even pause the sending, the average latency is slightly high at 249ms
with 72.2% of packets with latency below 250ms. Packets that were lost are denoted as
“More” in the graph.

1.0
.9
.8
.7
Packet CDF

.6
.5
.4
.3
.2
.1
.0
50
100

850
150
200
250
300
350
400
450
500
550
600
650
700
750
800

900
950
1000
More

latency (ms)

Figure 14. Packet latency (PGTP, Resource Manager, bundling)

The latency statistics are presented in the table below. Packet loss was at minor 0.7% and
with average throughput of 192.64bps. The results show that with Resource Manager, the
latency fluctuation is rather great from the lowest at 98ms to highest at 936ms.

PGTP with Resource Manager and bundling

min latency max latency mean latency throughput packet loss
98 ms 936 ms 249 ms 192.64 bps .7% (13)

Table 4. Packet statistics (PGTP, Resource Manager, bundling)

25
The fluctuation can be explained by the Resource Manager switching off the wireless device,
causing the packets to be delayed. The time series graph below shows the number of packets
in the send queue and when the wireless is switched off and on. The red line shows the
number of packets in the send queue while the blue line shows the wireless status. When the
wireless is switched on, it is displayed with a value of 1 and 0 if otherwise. It can be seen that
when the wireless is switched off, packets start accumulating in the send queue. When the
wireless is switched on, the send queue is cleared immediately and the number of packets is
maintained at 1.

Packets Wifi

9
8
# packets in send queue

7
6
5
4
3
2
1 on
0 off
0 25000 50000 75000 100000 125000 150000 175000 200000
sending time (ms)

Figure 15. Effect of turning off wireless on the number of packets in send queue

The graph below shows the correlation between the packet latency and the period of wireless
on and off status. It is clear that the high latency experienced by majority of packets are
caused by the wireless turning off.

26
 latency Wifi

1000
900
800
700
latency (ms)

600
500
400
300
200
100 on
0 off
0 25000 50000 75000 100000 125000 150000 175000 200000
sending time (ms)

Figure 16. Effect of turning off wireless on packet latency (bundling)

To investigate the effect of packet bundling, the time when bundling occurs was recorded
together with the number of sub packets in one bundle. The time series graph below shows
the comparison between the packets in the send queue and the packet bundle size. From the
graph, it can be observed that packet bundling was working as intended. When the send
queue had more than one packet, the packets were de-queued and bundled before sending.
The maximum number of packets that can be bundled together was capped at 5 due to the
maximum payload size of the Zigbee device. The Zigbee was used as the network device
because of its ability to turn off and on in a very short time.

Packets Bundling

9
8
# packets in send queue

7
6
5
4
3
2
1
0
0 25000 50000 75000 100000 125000 150000 175000 200000
time (ms)

Figure 17. Comparison between number of packets in send queue and packet bundle size

27
 PGTP with Resource Manager and no bundling
To compare the effect of packet bundling on latency, the same game packets were resent
using PGTP without bundling. The results show that without bundling, the packets
experienced a higher average latency. It can be seen from the graph that during periods where
the wireless device alternates between off and on states frequently, the latency is greater than
when bundling is used. This is an indication that the send queue was not able to clear the
accumulated packets as fast as when there is bundling. Without bundling, only one packet can
be sent at a time while bundling allows multiple packets to be sent at a time. However,
without bundling, PGTP experience a lower level of packet loss. This is expected as a
bundled packet is larger in size and is more likely to be dropped in a congested network.
Fortunately, the packet loss rate for bundling is low due to the fact that game packets are
inherently small and thus a bundled packet is not too large.

Latency Wifi

1100
1000
900
800
latency (ms)

700
600
500
400
300
200
100
0
0 25000 50000 75000 100000 125000 150000 175000 200000
sending time (ms)

Figure 18. Effect of turning off wireless on packet latency (no bundling)

PGTP with Resource Manager and no bundling

min latency max latency mean latency throughput packet loss
57 ms 1082 ms 277 ms 172.856 bps 0.1% (1)

Table 5. Packet statistics (PGTP, Resource Manager, no bundling)

28
 PGTP with bundling and no Resource Manager
The effect on latency caused by the Resource Manager can be seen clearly from the previous
results. To see the performance of PGTP if the wireless is never off, the Resource Manager
was removed during the test. Without the updates from the Resource Manager, PGTP
assumes the game state is always critical and thus goes into the “Optimal” power saving
mode. In this mode, there is no buffering and packets are sent as soon as they are passed
down from the game. This allows PGTP to behave in a manner similar to conventional
transport protocols, where they have no knowledge of the criticality of the game state and this
information is not used to regulate the transmission rate.

The results show considerable increase in performance. PGTP had an average latency of 120
ms with 95.7% of packets experiencing less than 180 ms latency. The delay jitter, calculated
as the difference of the packet latency from the average latency, does not vary greatly with
92.66% below 40 ms. Delay jitter is also an important metric because it is less tolerable than
latency when playing online games.

1.0
0.9
0.8
0.7
Packet CDF

0.6
0.5
0.4
0.3
0.2
0.1
0.0
More
20
40
60
80
100
120
140
160
180
200
220
240
260
280
300
320
340
360

latency (ms)

Figure 19. Packet latency (PGTP, no Resource Manager, bundling)

29
 60%

50%

Packet frequency
40%

30%

20%

10%

0%
0 20 40 60 80 100 120 140 160 180 200 220 240
delay jitter (ms)

Figure 20. Packet delay jitter (PGTP, no Resource Manager, bundling)

PGTP with bundling and no Resource Manager

min latency max latency mean latency throughput packet loss
68 ms 360 ms 120 ms 398.936 bps 0.7% (13)

Table 6. Packet statistics (PGTP, no Resource Manager, bundling)

30
 Comparing with UDP
Finally, to find out how PGTP fare in comparison to conventional transport protocol, the
game packets were also tested using UDP. Comparison was done with UDP because it is
widely used in online games and it has the lowest latency.

Interesting, the results of UDP were very close to PGTP (without Resource Manager). Both
protocols have similar latencies, delay jitters and packet loss rates. This shows that PGTP has
comparable performance with UDP.

min latency max latency mean latency throughput packet loss

PGTP 68 ms 360 ms 120 ms 398.936 bps 0.7% (13)
UDP 68 ms 363 ms 124 ms 384.479 bps 0.6% (12)

Table 7. Packet statistics (PGTP vs UDP)

1.0
0.9
0.8
0.7
Packet CDF

0.6
0.5
0.4
0.3 PGTP
0.2 UDP
0.1
0.0

latency (ms)

Figure 21. Packet latency (PGTP vs UDP)

31
 60%
50%

Packet frequency
40%
30%
PGTP
20%
UDP
10%
0%
0 20 40 60 80 100120140160180200220240
delay jitter (ms)

Figure 22. Packet delay jitter (PGTP vs UDP)

The reason for PGTP’s good performance can be attributed to the characteristics of the game
packets and the implementation of the protocol. As mentioned earlier, 99.7% of the game
packets were unreliable and thus the overhead incurred for reliable sending was minimal.
PGTP is essentially implemented on top of UDP sockets. Thus, PGTP benefits from the same
lightweight-ness of UDP. Like UDP, PGTP without Resource Manager sends packet as soon
as they are passed down from the game to the socket. This eliminates any processing delay
that adds on to the latency. Since games usually send a fixed amount of packets in one time
period, the network is unlikely to be congested from the immediate packet sending. PGTP
also has packet bundling to help improve latency and reduce bandwidth. Although the
usefulness of packet bundling is more prominent when used with Resource Manager,
bundling still occurs whenever the send queue has more than one packet to send.

32
 6. Conclusion

In this report, I have presented the network requirements of games and how they are different
from other applications. Based on the requirements, I have analyzed the existing transport
protocols and showed that they are not suitable for online games in general and are not
compatible with the PAG API. As such, I have designed and implemented a new transport
protocol that caters to the special needs of games and to support the mechanisms of PAG API.

To evaluate the performance of PGTP, I have collected packet traces from the Armageddon
game and measured the network statistics of sending them using UDP and PGTP with
different settings. The results showed the effects of PGTP working together with the
Resource Manager and how packet bundling was able to minimize the latency penalty
incurred when turning off the wireless device. More importantly, the results showed that
PGTP’s performance was very close to UDP in terms of latency and delay jitter. This proves
that PGTP is a viable transport protocol for games even without the Resource Manager.
Furthermore, PGTP provides more features compared to UDP such as reliable sending,
packet priority and lifetime. Besides being optimized for power saving, PGTP is also
optimized for bandwidth saving through packet bundling and dropping expired packets. For
online games that can have thousands of players, bandwidth quickly becomes the bottleneck
of smooth game play. By using PGTP, games are able to optimize power and bandwidth
usages and still have the benefit of low latency and delay jitter.

33
 References

[1] Power and Network-Aware Software Infrastructure for Multiplayer Mobile Games,
a joint research project between National University of Singapore and Singapore
Management University, funded by the Singapore Ministry of Education.
[2] Anand, B., Ananda, A.L., Balan, R.K., Chan, M.C., and Le, T.L., “Game Action
Based Power Management for Multiplayer Online Game”, August 2009.
[3] Chen, K.T., Huang, C.Y., Huang, P., and Lei, C.L., “An Empirical Evaluation of
TCP Performance in Online Games”, June 2006.
[4] RFC 768, “User Datagram Protocol”, August 1980.
[5] RFC 793, “Transmission Control Protocol”, September 1981.
[6] RFC 2960, “Stream Control Transmission Protocol”, October 2000.
[7] RFC 3758, “Stream Control Transmission Protocol, Partial Reliability Extension”,
May 2004.
[8] Laafif, M., Tabbane, S., “Inter-Stream Priority Management in SCTP-
Multistreaming or HTTP Traffic in UMTS”, April 2008.
[9] Chen, C.W., Kua, T.C., Chih, M.C., Huang, P., and Chin, L.L, “On the challenge
and design of transport protocols for MMORPGs”