an aircraft cabin wireless system for games and video entertainment

ACM Computers in Entertainment, Vol. 5, No. 1, Article 7, Publication date: April 2007.

An Aircraft Cabin Wireless System for Games and Video Entertainment DWAYNE FOLDEN, TRENT JACKSON, MICHAEL PANIQUE, RIANON TIENSVOLD, RICHARD S. WOLFF, TODD HOWARD, ERIC JULIAN, LEVI JUNKERT, DAVID LOPEZ, AND MICHAEL J. OUDSHOORN

Montana State University, Bozeman __________________________________________________________________________________________

Current aircraft cabin systems utilize a wired network topology and offer only limited passenger entertainment services. In this article we explore the feasibility of utilizing a wireless network to reduce cabin wiring and reconfiguration costs and to provide passengers with a high-quality entertainment experience, including person-alized video and audio as well as state-of-the-art computer games. The problem is to determine whether this is feasible given the computer system demands of state-of-the-art network-based games, combined with the design constraints imposed by the aircraft cabin environment and the bandwidth demands of streaming video. These constraints have both hardware and network design factors. In both cases, the study assumes functionality that would be commercially available in the 2008 timeframe and beyond. We develop several architectures, and through a combination of emulation and simulation, assess the viability of each alternative. We show that a highly distributed architecture, utilizing trends in mobile gaming devices and high-speed (802.11a/n) wireless LANs, together with MPEG-4 encoded video, yield a promising approach to providing passengers with a high-quality entertainment.

Categories and Subject Descriptors: C.2.1 [Computer-Communications Networks]: Network Architecture and Design – Distributed networks; I.2.1 [Artificial Intelligence]: Applications and Expert Systems – Games; J.7 [Computer Applications]: Computers in Other Systems – Consumer products.

General Terms: Design, Performance

Additional Keywords and Phrases: Computer architecture, computer games, wireless networks, mobile devices ACM Reference Format: Folden, D., Jackson, T., Panique, M., Tiensvold, R., Wolff, R.S., Howard, T., Julian E., Junkert, L., Lopez, D., and Oudshoorn, M.J. 2007. An aircraft cabin wireless system for games and video entertainment. ACM Comput Entertant. 5, 1, Article 7 (January 2007), 17 Pages. DOI=10.1145/1219124.1219131 http://doi.acm.org/ 10.1145/1219124.1219131 ____________________________________________________________ 1. INTRODUCTION Providing high-quality entertainment in an aircraft cabin environment presents significant engineering challenges. User expectations of video quality and game performance are demanding, and power, size, and weight constraints imposed by the aircraft are formida-ble. Furthermore, maintenance is costly and access to equipment for hardware and soft _________________________________________________________________________________________ This project was funded by Boeing Cabin System Group. The work was conducted as a senior design project by undergraduate students in the College of Engineering at Montana State University. Authors’ addresses: D. Folden, T. Jackson, M. Panique, R. Tiensvold, R. S. Wolff; email: [email protected]; Electrical and Computer Engineering Dept., Montana State University, Bozeman MT 59717. M. J. Oudshoorn; email: [email protected]; T. Howard, E. Julian, L. Junkert, D. Lopez, Computer Science Dept., Montana State University, Bozeman, MT 59171; Permission to make digital/hard copy of part of this work for personal or classroom use is granted without fee provided that the copies are not made or distributed for profit or commercial advantage, the copyright notice, the title of the publication, and its date of appear, and notice is given that copying is by permission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permis-sion and/or a fee. Permission may be requested from the Publications Dept., ACM, Inc., 2 Penn Plaza, New York, NY 11201-0701, USA, fax: +1 (212) 869-0481, [email protected] © 2007 ACM 1544-3574/07/0100-ART7 $5.00 DOI 10.1145/1219124.1219131 http://doi.acm.org/ 10.1145/ 1219124.1219131

An Aircraft Cabin Wireless System for Games and Video Entertainment ● 2


ware updates is limited by numerous operational constraints. User experiences with video entertainment and computer games, driven by the rapid evolution in digital technologies have led to on-demand home digital video services and extremely sophisticated computer games with multiplayer capabilities, high-quality three-dimensional video rendering, and special effects rely on high-end computational platforms equipped with power-intensive display engines and large amounts of memory. We consider here the feasibility of design-ing an aircraft entertainment cabin system with the capabilities of supporting state-of-the-art computer games and personalized video delivery that would approach the entertain-ment available to end-users in their home entertainment systems. We assume that such cabin systems might be deployed in the next generation of aircraft, rather than for retrofit use in today’s systems.

The constraints for an aircraft cabin entertainment system are formidable. We first assume that each passenger must have an individual flat panel display and input/output controls that enable personalized entertainment services. Size, weight, and power consid-erations dictate that the equipment must be compact, consume no more than 25 watts per passenger, and rely on passive heat dissipation. Furthermore, video entertainment and games must be supported on the same platform to conserve space and weight. Conven-tional hard drives, DVDs, and other removable storage media are not feasible for this environment.

Instead, the system must be capable of network-based delivery of video content and game software. Due to the need to rapidly reconfigure cabin seating, we further assume that wireless networking, rather than cable or fiber optics, must be used to interconnect passenger entertainment equipment with other elements of the system. A centralized server may be used to store game and video software, but this equipment must also con-form to stringent requirements and consume at most 1000 watts.Overall, an aircraft cabin may serve as many as 300 simultaneous users. We anticipate that a combination of wire-less and wired networking can be used to enable game and video services. The Airline Electronic Engineering Committee (AEEC) has proposed a third-generation cabin system network (3GCN) that outlines a high-level architecture and interfaces for a cabin distribu-tion system [ARINC 2005]. This architecture defines a fiber optic backbone interconnect-ing wireless access points distributed throughout the aircraft cabin with a centralized server cabinet. Each wireless access point would serve a cluster of 15 to20 passenger seats. We adopt this distribution network in our considerations of an entertainment sys-tem.

The characteristics of the network traffic associated with computer games has been studied and reported for several environments. Network game traffic on an Ethernet, as-sociated with a LAN party, where a client-server architecture was employed to support multiplayer games, is reported in Faber [2002]. These measurements show that for a popular multiplayer game, such as CounterStrike, the typical client-generated traffic is in the range of 10 to 20kb/s, and a server generates about 15 to 20kb/s per client. Other studies have examined packet sizes and distributions [Feng et al. 2002], as well as game software and network architecture considerations (e.g., client-server versus peer-peer) for multiplayer gaming [Pellegrino and Dovrolis 2003]. There are several reports of game performance on wireless networks. The use of GSM short message service (SMS) and other cellular network services for gaming were examined in Vlajic et al. [2004], Bendas and Myllyaho [2002], and Busse et al. [2004], but these studies consider relatively low-end games, rather than the state-of-the-art video-intensive games that are prevalent today. There have also been several studies examining the effects of latency on user perception

3 ● D. Folden et al.


of games. In Armitage [2003], experiments performed with game players showed that latency greater than 150 to180msec affected user perception of highly interactive “first-person shooter” games such as CounterStrike. Other studies of game player behavior examined the durations of sessions. An extensive survey of online game use reports that the duration of game sessions falls off rapidly after 15 to 30 minutes [Chang and Feng 2003]. All of the above studies are based on users in natural home and office environ-ments, using conventional computers, game boxes, and in some cases mobile devices such as PDAs. To our knowledge, there are no reports of game player behavior under the constrained conditions of an aircraft cabin, where the types of game platforms, network support, and competing diversions for user attention might be entirely different.

We combine these considerations of aircraft cabin constraints with the character-istics of computer game behavior to assess the feasibility of a network-based entertain-ment system. In Section 2 we outline our approach. We define metrics for evaluating al-ternative architectures in Section 3. In Section 4 we describe three alternative architec-tures and provide evaluation based on the metrics in Section 5. We report results of a large-scale computer simulation of network performance in Section 6. Section 7 provides a summary and key conclusions.

2. APPROACH Our approach is to define and consider several alternative architectures that might meet the requirements, and then, through a combination of emulation, modeling, and simula-tion, examine the strengths and weaknesses of each approach. The chief hardware and network design constraints are summarized in Table I.

We approached the problem by first defining three alternative architectures that could meet the service requirements. The architectures, described in detail below, were based on (i) single user per processor, three users per processor, and centralized processor de-signs. In the following discussion, we call these “Single User,” “3-seat,” and “central-ized.” The approach to each design took into account the practicality of deploying the system within the limited confines of an airplane. Additionally, the architecture design was considered with the understanding that decisions regarding specific products and technology performance today may no longer be relevant several years from now. For example, energy consumption and heat generation would almost invariably increase alongside increases in CPU processing speeds, and the 802.11a may universally give way

Table I. System Constrains Hardware design constraints Network design constraints Power consumption limited to 25 W per seat

Wireless protocol: 802.11a or 802.11n

Server location power limited to 1000 W Throughput: 1Mb/s per seat maximum No active cooling systems for heat dissipa-tion

18-20 seats per wireless access point.

First class display up to 17”-21”; Coach size 8”-10”

Multiple access points, serving 300 seats

Deployable 2008 or later Fiber backbone interconnecting access points and server

Common platform for games and personal-ized audio/video entertainment

Network must support games and person-alized MPEG4 video



to 802.11n. Similarly, trends in computer game software indicate that memory, process-ing, and display requirements will continue to increase.

We examined each of the architectures through a combination of emulation, experi-mentation, and simulation. We emulated each architecture using currently available com-ponents, modified in some instances to deliver the required functionality. We selected computer games as representative of three classes of complexity, and used them in experi mentswith each of the emulated architectures; the game classes are described in Section 3.We also defined nine metrics to serve as a basis for establishing a framework to quan-tify the hardware complexity, performance, and game support for each architecture. We captured traffic data for game and video in these experiments for use later to drive simu-lations. We then used the metrics as basis for comparison and evaluated each of the archi-tectures. We developed a network model and simulated the performance of combinations of games and video services under a variety of conditions, using the traffic traces from our experiments as inputs.

3. METRICS

3,1 Game Software Classes Games were the primary test software for evaluating the architectures. Measuring game performance from a hardware perspective is useful to determine if the system can operate the software with specific and objective metrics, but actual user perceived performance is subjective, although important. We selected three classes of computer games that are rep-resentative of several critical features in game performance and user interaction. Due to hardware and proprietary software constraints not all games could be played on all of our architectures, hence some compromises and estimates were needed to fully explore all facets of performance.

The main high-end game used in all testing for the two personal computer (PC) based architectures was Unreal Tournament 2004 (UT2004). It is a game that has a scalable graphics capability that rivals any top-tier title when all of its effects are enabled, and, as mentioned above, was the only game that was capable of operating under Windows and Linux. Others are available, and the Linux gaming community is growing, with emulators to allow native Windows games to run within Linux. The graphics engine that UT2004 uses is based on one of the most widely used current software architecture for games.

For our “single seat” architecture, the emulation used the Sony Play Station Portable (PSP). The PC based games do not function on the PSP test platform, so different titles were used to ascertain its performance level. The two games tested on the PSP were WipeOut: Pure and Twisted Metal: Black. There are no corresponding titles that are cross-platform for all three architectures, but a reasonable comparison can be made based on the parameters given for this project and the others determined viable for the end re-sults table. Based on the current game technology and where the trends are moving we determined that each evaluation metric could be rated using a five-level ranking methodology de-scribed below, with the value for each metric entered into a metrics table row. These rankings represent where an average user would place a given aspect of the game experi-ence when played with a particular system architecture. Each game tested is classified to fit in one of the levels, and the hardware for each architecture is rated as to its ability to function with a game at that level. Again, UT2004 is the only title used that could scale to each of the levels of quality. We defined three broad game categories in terms of their



Table II. Game-Level Example Titles and Platforms

Level Platforms software High High-end PC/laptop Unreal Tournament 2004, Far Cry

Medium X-Box, Sony PSP, Playstation 2 UT 2004 (scaled down), Ballistics

Low Playstation Red Alert, UT 1999

Table III. Game Platform Requirements Level Memory RAM CPU Video processor

High 5 GB 1 GB 2 GHz 700 MHz, 256 Mbytes RAM 1Gbyte memory

Medium Up to 5 GB 512 MB 1.5 GHz 200 MHz, 32 MB RAM

Low Up to 1 GB 256 MB 1 GHz 100 MHz (no dedicated memory)

computational and display complexity as high, medium, and low. Table II shows the game software that we selected to characterize each level

We also examined the platform requirements in terms of processor speed, memory, and video support needed for each game level (summarized in Table III).

3.2 Evaluation Criteria We defined nine criteria to serve as a framework for measuring the ability of the architec-ture alternatives to meet cabin system requirements. These criteria, listed in Table IV,consist of both objective and subjective quantities selected to determine how well each of the approaches meet the cabin system requirements and provide high-end enter-tainment. As each of the three selected architectures had little similarity to the other two, establishing consistent evaluation parameters proved difficult. While the 3-seat and cen-tralized architecture emulations were PC-based, the Single User architecture emulation was based on the PSP mobile computing platform. The PC based systems were tested with both Linux and Windows as operating systems, but the PSP uses proprietary soft-ware running on specialized hardware. Additionally, not all of the game test software could run on all three operating systems, limiting the opportunities to do direct perform-ance comparisons. The assessment also included the capability of the architecture to sup-port multiple simultaneous applications (but this capability applied only to the centralized and 3-seat cases).

Each of these metrics was assigned a specific weight, W, between 1 (Least Important) and 10 (Very Important). Each architecture was then evaluated according to these metrics and rated as to how well it performed. A five-tiered rating system was used to rank a per-formance outcome, R: Low (1), Medium-Low (2), Medium (3), Medium-High (4), and High (5). An architecture’s rating for a metric was then multiplied by the weight assigned to the metric. Finally, these products were summed to produce a total rating for the archi-tecture, A, using the equation.



Table IV. Metrics for Architecture Evaluation Metrics Issues Game Quality: Graphics Dependent on display size, 1024 x 768

min., video processor and memory Game Quality: Performance (Frames/ Second)

Full motion needed for high-end games

Game Quality: User Input Latency Less than 150msec necessary for good eye-hand coordination

DC Power Usage Less than 25 watts/seat average Network Traffic Less than 1 Mb/sec per seat, average Game Titles Scope of software titles developed for

platform System Hardware Cost Considered trends and learning curves,

2008or later availability Upgradeability Openness of architecture, standards Peripheral Integration Support for multiple users, game ori-

ented I/O Finally, these products were summed to produce a total rating for the architecture A,

using the equation:

Some individual examples of test results are included in the different architecture sec-tions to further explain a particular outcome. While somewhat subjective, this rating ap-proach yields an effective method to compare the selected approaches and to identify their strengths and weaknesses.

4. SYSTEM CONFIGURATIONS

4.1 3-Seat Architecture The 3-seat architecture design takes the requirement of 25W per seat and couples three passenger display and I/O configurations together to achieve a platform with a new enve-lope of 75W. With a higher power ceiling, the system can now mirror a modern PC lap-top model that can operate three inputs and outputs to simultaneously satisfy the process-ing and display driver requirements for the 3 seats being served by a common computing and storage platform. This approach also shares a single wireless network interface, po-tentially lowering wireless network contention. The configuration for the emulation is summarized in Table V. We used an x86-based PC laptop as the platform for the single system that will operate for 3 seats. Testing was done in both Linux and Windows operat-ing systems to determine if one was more reliable and/or less hardware-demanding than the other. A workstation was used to provide the network game connection and to emu-late a game content and Internet server.

4.2 Centralized Architecture The centralized architecture is designed to have most of the processing power in a central server location, with only minimal processing and storage functionality at the passenger

iji

i ij RWA ×= ∑ =

=

9

1



seat. The server would likely be an array of processors, assigned on a demand basis to users on request, to assure optimal game performance through load balancing. Each player would have a small, embedded device at the seat that would connect wirelessly to an assigned processor in the server rack. The players would then have their content streamed to their individual seats. The video streaming hardware and software at both the server end and at the passenger seat are shared by the video, audio, and game applica-tions, providing an economy in equipment cost and power consumption.

The embedded processor at the passenger seat will have sufficient functionality to de-code and display the MPEG4 stream, manage the passenger I/O, and support low-end games locally. When the user selects gameplay, the system will make the decision whether the game is to be played on the individual’s seat processor or on a centralized processor. If the game is played on the central processor, the content will be encoded in

Table V. 3-seat Architecture Equipment Laptop Hardware • Make & Model

Dell Inspiron 9300 laptop PC • Processor

Pentium M 1.6 GHz • Video

Nvidia GeForce 6800 Go • Memory

1 GB DDR RAM 80 GB Storage Space

• Networking Intel wireless 802.11b/g inte-

grated device Linksys wireless 802.11a

PCMCIA card • Monitor

Dell 17 inch Liquid Crystal Display (LCD)

Server Hardware • Make & Model

Dell Xeon Tower Server • Processors

Dual Intel Xeon 3.2 GHz • Video

ATI Radeon 7000 • Memory

2 GB DDR2 RAM 100 GB hard drive

Networking Hardware • Linksys 802.11a/b access point • D-Link 10/100 Megabit Switch

real-time MPEG4 and streamed to the client over the wireless network. If the game is played on the local seat processor, then the game application software will be downloaded to the seat, if not already resident in the local memory, and played locally. Since the hardware at the seat is an embedded device with minimal computational power and minimal memory, games selected for local play will be basic. The equipment con-figuration for this emulation is summarized in table 6. Note that KVM over IP was used to stream the video and games as a high-quality real time MPEG4 encoder was not avail-able. This limited the evaluation in terms of video compression but provided a reasonable emulation of the final configuration.

4.3 Single-Seat Architecture Single-seat architecture is designed to have an individual gaming device at every seat with remote servers and/or local memory providing support for multiplayer games, downloads of new game application software, and movies. Each device would be able to download games, music, and video from the central servers and/or use games already



Table VI. Centralized Architecture Equipment Embedded Device

• Memory o 8-64 Megabytes

RAM o 1-4 Gigabytes Flash

• Processor o Minimum of 100Mhz o 32 Bit floating point

• Input/Output o Handheld Controller o Screen

• Minimum 640x480 Resolution

Central Server • Memory

o 1-4 Gigabytes RAM o 200+ Gigabytes Disk

• Processor o Pentium 4, 3.0 GHz o AMD Athlon 64 3200+

• Video Card o NVidia GeForce 6800 or

7800 • KVMoIP

o Near instantaneous return time (1-10 milliseconds)

• MPEG4 o Real-Time Encoding

Table VII.. Single-Seat Architecture Equipment PSP Hardware Processor

MIPS R4000 32-bit core 333mhz

Memory 4 MB embedded Ram 2 MB VRAM Up to 2 GB Main Memory

Input / Output IEEE 802.11b UMD Drive USB 2.0 Infrared Port

Monitor 480x272 Resolution 16:9 and 4:3 24 bit color

PSP Firmware Audio Codec Support

MP4 (AAC) MP3 ATRAC 3 WAV WMA

Video Codec Support MP4, H.264

Picture format support TIFF, GIF, PNG, BMP, JPEG

Ten languages supported Internet browser DRM mechanism for playing copyrighted

content. LocationFree TV player compatibility

loaded in local memory. We used the PSP to test whether hand-held mobile gaming de-vices are suitable for the entertainment system. We anticipate that the equipment will be mounted in the seat, not hand-held, and that the portable game systems serve as a good emulation of the architecture. We chose the PSP because it is arguably the most advanced mobile gaming device on the market and because it could play audio, video, and games.

There are other devices similar to the PSP, including the Gizmondo and Nintendo DS, but the PSP supports the largest number of games, and the development of additional features is proceeding rapidly. Table VII summarizes the equipment used for this emula-tion.



5 TEST RESULTS

5.1 Ratings The architectures were evaluated using combinations of high-, medium-, and low-end games and streaming video. The key results based on the evaluation metrics are given in Table VIII, which shows that the single-seat architecture yields the highest overall rat-ings. We discuss some of the key issues in the sections below.

5.2 3-Seat Architecture Findings For the 3-seat architecture, the main game processing is carried out locally, and the net-work connection is used to communicate with the game server to support multiplayer gaming. The real bottleneck for this design proved to be the hardware capabilities. Even at the lowest level of functionality, the results of subjective testing with three games were disappointing. Current and future graphics chips are developed to support a single proc-ess, while in this configuration, the graphics processor is used to run three different dis-plays simultaneously. While displaying a single game on multiple monitors is not a prob-lem for the hardware, and even one game with other applications on the other displays is also feasible, there are no video processors designed to support multiple discrete displays. We found that two low-to-medium games are playable but the game performance is mar-ginal. Furthermore, this architecture requires more than power than is available. The graphics unit alone consumes a minimum of 35W with new revisions of top of the line mobile graphics processors requiring nearly 50W. Factoring other system components into account, the power requirement climbs to above 100W. With two games running, the processor does not have enough capacity to support any other applications. For tests of just one game at the medium-level or higher, the CPU is operating at 100 percent capac-ity, as is the case with two or more lower-level games.

Tests with both Windows and Linux brought forward many problems that remain un-resolved. Windows is the dominant gaming platform on the PC, and between the DirectX

Table VIII. Combined Architecture Ratings Metrics Weight 3-Seat Centralized Single Set Game Quality: Graphics 7 ML L M Game Quality: Performance (Frames/ Second)

7 L L MH

Game Quality: User Input Latency

10 ML L MH

Power Usage 8 M M H Network Traffic 5 H H H Game Titles 1 L H H System Hardware Cost 5 M L MH Upgradeability 3 M H MH Peripheral Integration 3 M M MH Development Costs 3 ML M MH Durability 4 ML M MH Time To Market 5 M MH H Total Rating 153 148 260



and OpenGL APIs used in graphics programming, the Windows-only DirectX is the more widely used. Furthermore, the Microsoft operating system does not support

DirectX games over more than one display. OpenGL is supported though, and UT2004 operates in both. With Windows some games created conflicts when running together and randomly crashed the system. Linux proved very unstable with more than one game running, and was as unusable as Windows in those instances. Games would crash randomly, even when two instances of the same game were running. The system would remain operational, but multiple games were not playable. It should also be noted that neither Windows nor Linux support more than one discrete input to the single platform, as would be needed to enable several users to simultaneously share a common processor. Solutions such as software-based I/O multiplexing could add system overhead to an already overtaxed CPU, while new, specialized hardware might become a high-cost solution that includes a customized motherboard with specialized drivers to recognize it.

5.3 Centralized Architecture Findings Our test results for the centralized architecture were not very favorable, primarily due to the high bandwidth requirement of the streaming video and delays in the control signals introduced by the use of KVM. When conducting the high- and medium-quality game tests we found that the latency rendered every game unplayable, as the bandwidth de-mands were saturating the network. The low-end game tests were within network re-quirements for throughput, but the encoding delays were excessive and very displeasing to the eye. If the tests were performed using real-time MPEG4 encoding, they might have shown this design to be a viable solution in terms of bandwidth utilization, but the encod-ing delays are still likely to be a significant impediment to real-time, highly interactive game performance.

We found other potential bottlenecks in the centralized architecture associated with the use of shared processors. Based on trends in blade servers, designed for high process-ing capacity but not for low-power operation, we found that the power consumption of the high-end processors necessary to support a large number of simultaneous high-end games would far exceed the 1000W allocation.

5.4 Single-Seat Architecture Findings The mobile game platform served as an excellent emulation and indication of the future potential of single-seat architecture. The PSP has enormous game developer support, as large game developers like Electronic Arts, Konami, Lucus Arts, and RockStar continue to develop games for the PSP. Ports of new games are starting to appear for the PSP at the same time they are available for video game consoles. With the PSP able to run emu-lators for six different gaming platforms, it opens up the ability to play hundreds, if not thousands, of extra games, making the system a more viable gaming platform.

We found that the PSP had significantly lower power consumption and lower band-width usage than the other architectures tested. The PSP was designed with long battery life and used at most 5W of peak power, and often stayed around 3W. The power con-sumption of the PSP makes it an ideal candidate for the entertainment system. In game mode, the PSP used much less than the 1Mb/s maximum available bandwidth.

Considering the size of the device, the quality of gameplay is excellent. The PSP in-cludes both a directional pad and an analog control stick that can be used to control the games. Peripheral hardware companies have also created devices that allow alternative controls for the PSP. Currently, companies provide the ability to link a PS2 controller or



a USB keyboard to the PSP. The frame rates and picture quality of the PSP are excellent. The PSP has a high-definition TFT LCD screen capable of 480x272 resolution, 16:9 and 4:4 dimensions, and 24-bit color. This high-quality screen makes all games look ex-tremely crisp. The games tested on the PSP were all designed and ported for the PSP, hence frame rates were high and we never experienced any frame dropping. We did ex-perience choppy play on certain games when running an emulator program.

6. NETWORK SIMULATIONS A network model was created using OPNET ModelerTM 11.5 to simulate the cabin sys-tem, which includes a model of 802.11 with service priority characteristics as defined in 802.11e. OPNET is a powerful discrete time simulation tool designed to allow detailed simulations of network architectures comprised of both wired and wireless links, clients, servers, and other network elements. The software contains accurate implementations of network protocols enabling realistic evaluations of performance characteristics, including throughout and delay, under user-controlled traffic and load conditions. The OPNET Ap-plication Characterization Environment (ACE) module was used to drive the simulations with network traffic traces acquired using Ethereal in the emulation experiments.

The cabin network was simulated using generic models for the different hardware in-volved. A section of the network was constructed consisting of 20 client nodes, one wire-less access point, and a server. The client nodes connected to the access point using 802.11a. The nominal available bandwidth for the access point wireless subnet was 54 Mbps. A fiber backbone connecting the access point to the server was modeled using a gigabit Ethernet connection between the server and the access point. The generic model for each seat emulated a fairly standard end-user configuration, similar in specifications to a portable gaming device. Figure 1 shows the OPNET model for the cabin system.

Fig. 1. Cabin system OPNET model.



We chose to model a 20-seat cluster rather than a full 300-seat aircraft cabin for sev-eral reasons. First, a large simulation with 300 nodes would be extremely slow, requiring long execution times. Furthermore, after some initial tests on the 20-seat subnet, it be-came apparent that the major factor influencing the overall system performance is the capacity of a single access point, and not the capacity of the fiber link or the central server. Hence the performance of a model with 20 access points and 300 clients would be effectively the same as a 20 client subnet. The only potential advantage of a larger scale network would be load balancing between access points. Since a client might be within range of 2-3 access points, it could be served by the access point with the lowest load. We did not quantitatively explore this possibility. In this sense, our results for a single subnet are conservative, in that load balancing among access points could lead to better performance We also note that from a MAC layer and wireless network perspective, there is little difference between the single-seat and 3-seat architectures. That is, the 3-seat architecture would offer the same load to the network with 20 clients being served by 7-seat proc-esssors and wireless interfaces as a single-seat configuration with 20 clients being served by 20 seat processors and 20 wireless links. There would be some improvement in MAC efficiency in the 3-seat approach, as there would be fewer demands to services (8 instead of 20), but the total traffic load would be the same. With this in mind, we focused the simulations on the single-seat architecture. To investigate the effect of scaling on the server, this basic service configuration was repeated in a larger model to simulate 80 cli-ents and 4 access points.

Four different traffic scenarios were defined and simulated. The four scenarios were defined in terms of the sets of clients viewing video or playing games. The scenarios were proportioned as follows: 100% gaming traffic; 0% movie traffic; 75% gaming traf-fic; 25% movie traffic; 50% gaming traffic; 50% movie traffic; 25% gaming traffic; 75% movie traffic; and 0% gaming traffic. Each scenario was simulated for both high-end and low-end games. This was done to investigate whether movies or games represent a larger share of the overall network usage and how the service mix affects performance.

Network traffic for the simulations was collected from actual multiplayer game ses-sions and movie streams. The data was collected during tests of the game performance using the architecture emulations and filtered for relevance with Ethereal. The game traf-fic was captured during multiplayer sessions of both high- and low-quality games. The high-quality game in this case was UT2004. Figure 2 shows an Ethereal plot of the cap-tured traffic. During multiplayer gaming, a server is used to “host” the game. The host server takes position and action data from each user and redistributes the relevant infor-mation out to the network to synchronize the players. The low-end game used for the simulations was Conquer Online; Figure 3 shows the traffic trace. Conquer Online is a massive multiplayer online role- playing game, and is also hosted on a server which dis-tributes player information, but the graphics processing for this game is much less than that required for UT2004. From a network throughput standpoint, the two games are fairly similar. The spikes in the data captures shown in Figures 2 and 3 correspond to large data transfers associated with changes in level.

The movie traffic for the simulations was captured from a streaming video clip taken from the Internet. The Ethereal plot is shown in Figure 4. This particular capture was in MPEG-2 format, but the quality was such that the throughput was very close to the 1 Mb/sec associated with MPEG-4 video.



Fig.2. Ethereal traffic capture for UT2004.

Fig.3. Ethereal traffic capture for Conquer Online.

Fig. 4. Ethereal traffic capture for streaming movie.

The 802.11e protocol supports quality of service through traffic assignment classes. In our simulations we assigned highest priority to the streaming video traffic and best-effort priority to the game traffic



High End: AP Load

0.00E+00

5.00E+06

1.00E+07

1.50E+07

2.00E+07

2.50E+07

0 50 100 150 200 250 300

Time (sec)Lo

ad (b

its/s

ec)

100% Game75% Game50% Game25% Game

Fig. 5. Access point load sending high-end games and movies.

These traffic traces were applied to the clients in various combinations, as defined in the previously described scenarios. The traces were not started simultaneously, but in a quasi-random sequential order prescribed by nominal 3-second offset for the initial in-stance of an application, followed by a uniformly distributed, randomly selected offset ranging from 5 to 10 seconds for each subsequent client. In this way, the same traffic traces could be reused up to 20 times and yield the effect of 20 uncorrelated and inde-pendent traffic streams.

The simulation results show the projected behavior of the cabin wireless network un-der differing loads of gaming and streaming video. The statistics measured at each node and the access point were the network load that each one placed on the network, the throughput received by each, and the end-to-end network delays. Using these definitions, the aggregate load generated by the clients is seen at the access point and server as net-work throughput. The network load generated by the server is divided up at the access point and shows up on the clients as throughput. Given the nature of the game and video traffic, the typical distribution of load and throughput was, on average, 5% of the avail-able wireless bandwidth. This meets the specification for available seat bandwidth dis-cussed above. When the game being played was a high-end game such as UT2004, the clients’ share of the bandwidth was more evenly divided between games and video. When the game was the low-end RPG, the movie clients dominated bandwidth usage. The results show that the network loads and throughputs do not represent a bottleneck for any type of game on either the single-seat or 3-seat architectures.

Figure.5 provides a typical example of our simulation results for several combina-tions, that is, clients playing high-end games and watching movies. The figure shows the access point load, or traffic sent from the access point to the clients. We note that if all the clients are playing games (e.g., there is no video traffic), the aggregate traffic sent by the access point is about 5Mb/s, well below its 54Mb/s capacity. When there is a mix of game and video traffic, the load rises, consistent with the increased network usage asso-ciated with video delivery.

We note in this figure that the access point load with combinations of video and game traffic is almost independent of the traffic percentage mix, and reaches an average value of about 13Mb/s. This is due to a wireless network saturation effect, and is evidenced in the access point and client delay behaviors, shown in Figures.6 and 7.

Analysis of the network delays associated with the access point and client nodes indi-cates that when the network traffic is all due to gaming, the delays are minimal. As the number of clients watching movies increases, however, the latency for all clients in-



creases. The highest delay at the access point was shown to be about 1.6 milliseconds. The latency at the end-clients reached a maximum of about 60 milliseconds, with an av-erage value of about 40 milliseconds. These delays are due to MAC layer resource con-tention in the wireless subnet. Studies have shown that humans start to notice game de-lays when they exceed 100 milliseconds. The fastest refreshing displays available require at least 15 milliseconds to refresh the screen. The total delay should then be approxi-mately 75 to 95 milliseconds at each end. This is when a full 20 clients are connected to each access point. For more normal access point loads, the delay would be less. Given this, we identified latency as a potential bottleneck for the cabin environment. This would favor the 3-seat architecture, where the number of links competing for the wireless subnet resource is fewer that in the single-seat architecture. Load balancing among access points could mitigate this latency effect.

With the current OPNET model, there are only 20 clients and 1 access point. However, this model can be easily scaled to model the 300 passengers that will be present on an aircraft. Based on the simulations worst-case scenario, a maximum of 1 Mbps was used per client. Scaling this data rate to meet 300 clients produces approximately 300 Mb/s that will be handled easily using the fiber backbone. Therefore, the use of a fiber back-bone will prevent any potential bottlenecks from occurring based on backbone traffic. Also, in the current model, a single, generic server is used, but when scaling the system to

High End: Access Point Delay

0.00E+00

1.00E-042.00E-04

3.00E-04

4.00E-04

5.00E-046.00E-04

7.00E-04

8.00E-049.00E-04

1.00E-03

0 50 100 150 200 250 300

Time (sec)

Dela

y (s

ec) 100% Game

75% Game50% Game25% Game

Fig. 6. Access point traffic delay. High-end games and video traffic.

High End: Client Delay

0.00E+00

1.00E-02

2.00E-02

3.00E-02

4.00E-02

5.00E-02

6.00E-02

0 50 100 150 200 250 300

Time (sec)

Dela

y (s

ec) 100% Game

75% Game50% Game25% Game

Fig. 7. Client traffic delay. High-end games and video traffic.



handle 300 clients, more than one server will be necessary. Based on throughput results, a single server would not be able to handle 300 Mbps, the load required for 300 passengers. A more realistic scenario would be designating one server per access point, or a similar scaling, depending on the type of gaming used. Also, implementing a system that could balance the load of the servers, rather than specifically designating one server to one ac-cess point, would prevent potential overloads to a server. If a particular access point had multiple gaming applications running while another access point had little to no load, the load of the active access point could be balanced and shared between two or more serv-ers.

7. CONCLUSIONS The directions in digital entertainment software and associated computing platforms tend toward higher processor speeds, more memory and sophisticated video rendering, with associated demands for electrical power and active heat dissipation. These trends are or-thogonal to the constraints of an aircraft cabin system. Our main finding is that the fully distributed approach shows the most promise in realizing the high-quality entertainment environment desired. The highly innovative mobile gaming device market is providing extremely sophisticated, low-power, and high-performance devices that could serve as the basis for the passenger-seat entertainment system. Devices such as the PSP support a rich choice of computer games, are well supported by numerous hardware and software companies, and are widely accepted in the market place. With modifications to support a larger display, input/output controls suitable for the passenger seat, MPEG4 decoding for movies, and firmware to allow software downloads to the passenger seat via the cabin wireless network, these devices would be an excellent match to the demanding con-straints of the aircraft cabin environment.

The single-seat architecture received high subjective marks for overall gaming experi-ence and practicality. Its seamless and consistent frame transfer makes it very appealing visually. Additionally, the large (and increasing) number of game titles available provides an abundance of game content to choose from. The intrinsic multiuser game support ca-pability of the PSP eliminates the need for game servers, and, as a mobile hand-held gam-ing console, it is hardened and designed for travel. A cabin entertainment system built on the PSP architecture also makes use of a successful commercial off-the-shelf product design.

While compute-intensive, computer games, even those involving multiple participants, are not highly bandwidth-intensive, although latency is a major consideration in real-time interactive games. Our measurements show that less than 20kb/s average throughput per client is necessary for a typical high- end game, and that wireless network technology such as 802.11a has adequate capacity to support a multiplayer game with upwards of 20 participants, as well as combinations of game players and video streams, with the caveat that the video is compressed to 1Mb/s per stream. Our simulations show that latency at-tributed to contention in the wireless network is typically less than 50msec, even with large numbers of video streams present, well within the 150msec envelope necessary to support high-quality interactive games.

The network model utilizes the IEEE 802.11a wireless protocol, modified to support the 802.11e QoS protocol features, and offers the Quality of Service (QoS) feature that allows the prioritization of user traffic, depending on the type of traffic being sent. The 802.11e protocol is compatible with the current 802.11a and 802.11b standards and offers some enhancements to the MAC layer to improve user experience in a multimedia-



intensive network. The enhancements include using a coordinated time-division multiple-access construct and an error-correcting mechanism for delay-sensitive applications such as video and voice. In our simulations, the priority of traffic was adjusted to maximize the gaming user experience. One issue that detracts from the usefulness of this protocol is that the enhancements to the higher priority traffic come at a cost of latency in the lower priority traffic. The video streams in the aircraft might be enhanced, but the latency in-curred in other types of traffic might make this option less attractive. Further work is needed to assess the effects of priority on MPEG4 encoded video streams. REFERENCES ARINC 2005. ARINC Project Paper 808. Cabin Equipment Interfaces (CEI), 3GCN Cabin Management and

Entertainment System, Cabin Distribution System. Aeronautical Radio, Inc., July. ARMITAGE, G. 2003. An experimental estimation of latency sensitivity in multiplayer quake 3. CAIA Tech.

Rep.030405A, April. BENDAS, D. AND MYLLYAHO, M. 2002.Wireless games: Review and experiment. In PROFES 2002, 587-600. BUSSE, M., LAMPARTER, B., MAUVE, M., AND EFFELSBERG, W. 2004. Lightweight QoS – Support for net-

worked mobile gaming. In SIGCOMM’04 Workshops (Aug. 30-Sept. 3), 85-92. CHANG. F. AND FENG, W. 2003. Modeling player session times of on-line games. In NetGames’03 (May 22-

23), 23-26. FABER, J. 2002.Network game traffic modeling. In ACM NetGames 2002 (April 16-17), 53-57. FENG, W., CHANG, F., AND WALPOLE, J. 2002. Provisioning on-line games: A traffic analysis of a busy counter-

strike server. In ACM IMW’02 (Nov. 6-8),151-156. PELLEGRINO, J. AND DOVROLIS, C. 2003. Bandwidth requirement and state consistency for three multiplayer

game architectures. In ACM NetGames 2003 (May 22-23), 52-59. VLAJIC, N., CHARALAMBOUS, C., AND MAKRAKIS, D. 2004. Performance aspects of data broadcast in wireless

networks with user retrials. IEEE/ACM Trans. Networking 12, 4, (Aug.),620-633. Received February 2006; revised March 2006; accepted April 2006

https://www.researchgate.net/publication/221219050_Wireless_Games_-_Review_and_Experiment?el=1_x_8&enrichId=rgreq-65d19a082b89d771d66398e4878e4de0-XXX&enrichSource=Y292ZXJQYWdlOzIyODc2MzI4ODtBUzo5OTkzMDMxNjIxNDI5MUAxNDAwODM2NjUyNjU3

https://www.researchgate.net/publication/221391523_Lightweight_QoS-support_for_networked_mobile_gaming?el=1_x_8&enrichId=rgreq-65d19a082b89d771d66398e4878e4de0-XXX&enrichSource=Y292ZXJQYWdlOzIyODc2MzI4ODtBUzo5OTkzMDMxNjIxNDI5MUAxNDAwODM2NjUyNjU3

https://www.researchgate.net/publication/221391523_Lightweight_QoS-support_for_networked_mobile_gaming?el=1_x_8&enrichId=rgreq-65d19a082b89d771d66398e4878e4de0-XXX&enrichSource=Y292ZXJQYWdlOzIyODc2MzI4ODtBUzo5OTkzMDMxNjIxNDI5MUAxNDAwODM2NjUyNjU3

an aircraft cabin wireless system for games and video entertainment

Documents