Interactive Gaming in Wireless Environments

Padova, 7 November 2008

Claudio E. Palazzicpalazzi@math.unipd.it

Dipartimento di Matematica Pura e Applicata Università degli Studi di Padova

Outline

• Introduction

• Fast and Fair synchronization (FILA)

• Wireless last hop scenario

• Gaming in VANETs

• Conclusion

Multiplayer Online Games (MOGs): Why?

• Very challenging research area

• Shares a family of problems with several traditional research fields in computer science:– Distributed simulations– Military simulations– Virtual reality– Safety ensuring applications– Homeland Security

• Exploding market

Main Problem: Synchronization Offset

GREEN PLAYER’S VIEW BLUE PLAYER’S VIEW

• Armagetron: game exploiting client­server architecture• Different delays between each player and the server

– The green player is closer to the server than the blue one– Physical distance but also different congestion levels

MOG’s Requirements

• Scalability: – the number of contemporary players should not be bounded– Massively Multiplayer Online Games (MMOGs)

• Interactivity: – multiplayer gaming is extremely delay­sensitive 

• Consistency:– uniformity of game state view in all nodes  

• (Network) Fairness: – simultaneous game evolution regardless of network conditions

Our Approach for Infrastructured Wireless Networks

architecture     +     synchronization scheme    +            “Smart” AP

Fairness and Interactivity Loss Avoidance (FILA)

Mirrored GameServer Architecture

1. Fast synchronization among servers

2. Delay equalizationamong players

Avoid queuing delaysdue to concurrent apps

Smart Access Point withLow Advertised Window

(SAP­LAW)

Ensure high interactivity and fairness degrees

Geographical/numerical scalability, simplicity, 

and centralized control

Core of the system Edge of the system

Internet

Game Constraints Relaxation 

• Semantics of the game used to relax constraints (e.g. total order and reliability) and gain interactivity

• The importance of certain game events diminishes when fresher game events make them superseded

• Correlated and interleaved events may preserve the importance of game events

p = 0p = 0

•    avgOL ∈ [0, min): no events are discarded•    avgOL ∈ [min, max): obsolete events are dropped with a probability p•    avgOL ∈ [max, ∞): all obsolete events are discarded

FILA’s Main Component: RED­based Dropping Scheme• Synchronization Algorithm able to drop superseded events• At each Server, for each received event, compute an average 

Overall Latency (avgOL) value– avgOL = avgOL + w * (sample – avgOL)

avgOLavgOL

Dropping Dropping ProbabilityProbability

PmaxPmax

11

maxmaxminmin

Phase 0Phase 0 Phase 1Phase 1 Phase 2Phase 2

min)(maxmin)(avgOLPmax

p−

−×=p = 1p = 1

Trading Reliability for Interactivity

• Contribution: in case of lousy interactivity then superseded game events may be dropped to speed up processing

• Consistency of the game state is fully maintained

0

0.2

0.4

0.6

0.8

1

1.2

0 30 60 90 120

150

180

210

240

270

300

330

msec

Prob

(GTD

 < x

)

OFF ON­OFF ILA

Synch­Offset cumulative function

Prob

 ( Sy

nch­

Off

set <

 x)

Also real experiments

Wireless Scenario: Last Hop• Homes are common places where 

enjoying different entertainment services– TiVo, Media Center (Home Entertainment 

Center)

• Vehicles will soon be generally endowed with entertainment hubs

• Increasing available wireless bandwidth– E.g., IEEE 802.11g, IEEE 802.11p

Problem: Delays on the Last Hop• Wireless is prone to errors, retransm., disconnections

• Wireless is a naturally shared environment– Many, heterogeneous flows may compete for the same channel

• General Belief: UDP’s lack of congestion control harms TCP flows

• Problem & Contribution: we showed that even TCP harms UDP flows– Window based flow control mechanism– Continuously probe the link for more bandwidth– Can fill up links and buffers with its packets– Increases delays cwnd

time

pipe capacity

Problem Statement: FTP Impact on Concurrent Real­Time Applications

time (sec)

jitte

r (m

sec)

VIDEO STREAM

ONLINE GAME

Starting times

VIDEO CHAT

FTP/TCP DOWNLOAD

Concurrent TCP traffic jeopardizes interactivity for online 

applications

Smart AP with Limited Advertised Window: SAP­LAW

)(#))((

)(tTCPflows

tUDPtrafficCtmaxTCPrate

−=

Contribution: SAP­LAW tries to avoid buffer utilization­ exploits information available at the AP ­ on­the­fly modification of the advertised window with appropriate values:

time

cwnd

pipe size

limited cwnd

regular cwnd

time

cwnd

pipe size

limited cwnd

regular cwnd

No queues: ­ lower delays ­ smoother throughput (no losses and reductions of the sending window for TCP flows)

SAP­LAW Applied to Vehicular Scenario

Urban scenario – 50km/h – grid topology

Highway scenario – 120km/h – linear topology

Heterogeneous traffic (FTP­TCP, online gaming­UDP)

1000m between APs

About 750m tx range

IEEE 802.11p

Both static and mobile (vehicle) nodes

Congestion Window Comparison

With SAP­LAW­ no congestion losses

­ advertised window dynamically changes with the number of TCP sessions on a certain AP

TCP regular

SAP­LAW

Jitter Comparison

SAP­LAW drastically reduces delays

(while maintaining the goodput) 

In Summary: Infrastructured Scenario

• System composed by – hybrid architecture– synchronization scheme– smart AP 

• Holistic approach to provide interactivity, fairness, consistency, and scalability

No Infrastructure: Online Gaming in a Car Platoon

• Scenario: online games played by passengers during long trips on a highway 

• Absence of infrastructure: VANET (Vehicular Ad­hoc Network)

• Game sessions of few minutes or tens of seconds (e.g., Armagetron)

AB

D

H IJ

C

F

GK

E

Assume that A sends a game message to all other cars

Gaming on VANETs: Problem Statement

• Game Messages have to be delivered very quickly to all cars in the gaming car platoon.

•  Problems arise from multiple transmissions–  multiple forwarders

•  Various proposals to reduce multiple (and redundant) transmissions.

Example of Optimal Solution

• Who has to forward a certain game message?– Optimal solution: A, C, F, G, and F broadcast the  

game message (one message and 4 hops)

AB

D

H IJ

C

F

GK

E

Assume that A sends a game message to all other cars

Related Works

• Vehicles have priorities in becoming the next forwarder – inverse proportion of the distance from the sender 

• Problem: limitation of preceding works:– Require perfect knowledge of the topology– Waste time in determining which is the last vehicle in the 

transmission range.– Unrealistically assume that there is a unique, constant, and 

known a priori transmission range for all cars in every moment• Problem: in a realistic environment they would use wrong 

parameters, thus not behaving efficiently (delays, losses).

Fast Multi­Broadcast Protocol: Basics

• We designed Fast Multi­Broadcast Protocol (FMBP) to have Game Messages covering the area­of­interest in as less time as possible (as few hops as possible)

• Contributions of FMBP:– Each vehicle dynamically computes its own transmission range– Tx range estimation is put to good use to reduce the number of 

hops that a Game Message will experience in its trip to destination. 

FMBP: the Estimator• In Game Messages: 

– Position– Tx range– Hearing distance

3. Game Message including B’s range estimation 

2. Game Messages also say how far C can hear 

1. Through being able to hear A’s Game Messages, C knows its “hearing distance”

A B C

• Collected info are periodically refreshed

Contention Window Computation• Cars broadcast Game Messages containing their Estimated Transmission Range and position

• Cars forward the Game Message after a contention window inversely proportional to the distance from the source:

• If another car that is farther from the source than the considered one already forwarded the Message, then the considered car aborts its sending procedure (the message has already been  propagated)

+

−×−

CWMin)CWMinCWMax(MaxRange

cetanDisMaxRange

Simulation Assessment

• Strip­shaped road (highway)• Area­of­interest of 8km. • Within the same simulation, cars have speeds 

uniformly distributed in the range 72­144Km/h. • CWMin and CWMax equal to 32 and 1024 slots 

– as the real IEEE 802.11 protocol• Two possible cases for the actual transmission 

range: 280m and 1000m.

Compared Schemes

• Fast Broadcasting– Exploits our tx range estimator

• Static300– considers 300m as a fixed parameter for the tx range– Ideal iff the actual transmission range is indeed 300m

• Static1000– considers 1000m as a fixed parameter for the tx range– Ideal iff the actual transmission range is indeed 1000m

Summarizing Results: 280m of Actual Transmission Range

• FMBP ensures a 200ms of average delay to deliver a game event from one extreme to the other of the gaming car platoon

• Static schemes are outperformed

FMBP is less sensitive to cars’ dispersion in the VANET

(now the last car in the tx range is in average at 240m instead of 280m)

Summarizing Results:Other Configurations

FMBP has the same performance than the ideal scheme (Static1000) on a configuration with 1000m of 

transmission range

Conclusion

• To support online gaming even for wireless and highly mobile users we proposed and evaluated:– synchronization mechanism based on an Internet 

server overlay that enables scalability, fairness, and interactivity;

– Smart AP to guarantee elastic (TCP) and real­time (games) coexistence on a wireless link;

– a fast multi­hop broadcast scheme that exploits a novel transmission range estimator to efficiently deliver game events to players in vehicles. 

Other Works

• Transport protocols design – (e.g., satellite links, RTT­fairness)

• Network parameters estimators– Capacity, bandwidth, shareable bandwidth

• Vehicular networks– MAC Protocols, Transport Protocols, applications– Infrastructured, ad hoc

• Multimedia over wireless networks– Gaming, videostreaming– Even on Mesh networks

• Altruistic­aimed web applications• Computer­based preservation of Cultural Heritage