WO2020236672A1

WO2020236672A1 - Wireless in-flight entertainment system

Info

Publication number: WO2020236672A1
Application number: PCT/US2020/033322
Authority: WO
Inventors: Brian Liu; Andrew BATTIGAGLIA; Christopher Plummer; Kenneth Bailey; Clifton MALECKI; Collin WATTS
Original assignee: Georgia Tech Research Corporation
Priority date: 2019-05-17
Filing date: 2020-05-17
Publication date: 2020-11-26

Abstract

A wireless in-flight entertainment system can include individual passenger interface devices integrated in aircraft providing content to passengers in a standalone fashion and/or via communication over an in-aircraft wireless network. The wireless network can include on-board data storage that can reside in a centralized on-board storage and/or decentralized among the passenger interface devices. The wireless network can include a centralized server system for communicating with off-aircraft networks. The wireless network can be implemented in the 5GHz frequency space, can facilitate dynamic SSID generation for passenger interface devices, can facilitate communications between passenger interface devices and the centralized server system, can facilitate communications between passenger interface devices, and/or can facilitate data caching at passenger interface devices. Hardware components of the wireless network can be pre-configured off aircraft.

Description

WIRELESS IN-FLIGHT ENTERTAINMENT SYSTEM

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 62/849,216, entitled“Wireless In-Flight Entertainment System,” filed on 17 May 2019, which is incorporated by reference herein in its entirety as if fully set forth below.

TECHNICAL FIELD

[0002] The various embodiments of the present disclosure relate generally to entertainment systems. More particularly, the various embodiments of the present disclosure are directed to in flight entertainment systems for aircraft.

BACKGROUND

[0003] Unless otherwise indicated herein, all disclosures in the background are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.

[0004] In-flight entertainment (“IFE”) systems used in commercial passenger aircraft have become ubiquitous, especially on aircraft designed for long-distance flights. Passengers have come to expect IFE services such as movies, audio programming, games, and internet connectivity through interactive displays affixed within the aircraft as well as through personal electronic devices brought aboard. Early IFE systems, which include ceiling mounted projectors or displays configured for synchronized display of content to all passengers, have all but disappeared as passengers expect greater interactivity from IFE systems through individual interactive displays at each seat. Additionally, passengers now carry an assortment of wirelessly connectable personal electronic devices and may choose to utilize both individual interactive displays and personal electronic devices for entertainment and internet connectivity during flights. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The example embodiments of the present disclosure are described below with reference to the accompanying drawings in which like numerals indicate like structural elements and features in various figures. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating principles of the present disclosure. The drawings illustrate only example embodiments of the present disclosure and are therefore not to be considered limiting of its scope. The present disclosure may admit to other equally effective embodiments not illustrated specifically in the drawings.

[0006] Fig. l is a line drawing illustrating network components of a wireless IFE system according to example embodiments of the present disclosure;

[0007] Fig. 2 is a line drawing illustrating a system for on-board aircraft services for supporting a wireless IFE system according to example embodiments of the present disclosure;

[0008] Fig. 3 is a flow diagram showing aspects of a method and modes of operation for caching data in an aircraft on-board network according to example embodiments the present disclosure;

[0009] Fig. 4 is a line drawing illustrating a system for caching data in an aircraft on-board network according to example embodiments of the present disclosure;

[0010] Fig. 5 is a line drawing illustrating a pre-configuration system for preconfiguring aircraft network hardware according to example embodiments of the present disclosure;

[0011] Fig. 6 is a line drawing illustrating a centralized network for wireless seat-to-seat interaction according to example embodiments of the present disclosure;

[0012] Fig. 7 is a line drawing illustrating a mesh network for wireless seat-to-seat interaction according to example embodiments of the present disclosure;

[0013] Fig. 8 is a line drawing illustrating an isolated regulated software module on an aircraft server according to example embodiments of the present disclosure; and

[0014] Fig. 9 is a line drawing illustrating an isolated regulated software module on a passenger interface according to example embodiments of the present disclosure. DETAILED DESCRIPTION

Overview

[0015] In certain IFE systems, movies, audio programming, internet data, and other information accessible by on-board systems are stored in an on-board server and delivered from the server to passenger interfaces by coaxial cable, optical fiber, or other physically-connected (e.g., wired) mediums as either analog or digital transmissions. In such systems, the main transmission cable from the server is generally located in the sidewall or ceiling of the aircraft, and other ceiling- mounted devices are connected by trunk lines from the main cable. In order to connect to devices located in floor-mounted seats, large numbers of relay cables are wired through the side walls of the aircraft.

[0016] Airlines frequently change the routes on which aircraft are used and the ticket class configuration of the aircraft. These changes often require seat position changes in the aircraft. If the seat position changes require changes to the relay lines in the side walls, this process can be time consuming and expensive.

[0017] A network architecture that replaces wired data transmission to in-seat passenger interfaces with a wireless configuration may reduce the time and expense of reconfiguring the seating arrangement within the aircraft. However, wireless networking configurations used in stationary, ground-based environments are not readily adaptable for use in an aircraft environment. For example, commercial passenger aircraft are subject to safety requirements, changing wireless transmission restrictions as aircraft travel through regions subject to differing regulatory requirements, and high data bandwidth requirements that are not typical design challenges of stationary or ground-based wireless networks.

[0018] As used herein, the term“wireless IFE” includes a system configured for use in an aircraft which provides entertainment, wirelessly, to aircraft equipment, where aircraft equipment generally excludes personal electronic devices such as phones, tablets, and computers brought on board by passengers. The equipment can be configured to wirelessly receive entertainment content and may include wired connections within the aircraft to receive power.

[0019] A particular challenge when implementing a wireless IFE system within an aircraft relates to the system’s ability to reliably mute passenger audio jacks when a public announcement (“PA”) system is active or during a decompression event as required by Federal Aviation Association (“FAA”) guidelines (and guidelines of other jurisdictions). When audio jacks are wired, this muting can be accomplished in hardware (e.g. with a hardwired relay on audio jack lines). However, such hardware solutions may be less desirable in a wireless system because the hardwired features could negate certain benefits of having a wireless system; with the hardwired features, the system might not be truly“wireless.”

[0020] Software solutions are complicated by the fact that muting passenger audio jacks during PA activation and during decompression are generally subject to stricter safety assessment processes and requirements than other IFE services and functionality. For example, DO-178C, “Software Considerations in Airborne Systems and Equipment Certification,” the primary document by which certification authorities such as the Federal Aviation Administration, European Aviation Safety Agency, and Transport Canada approve commercial software-based aerospace systems, classifies muting passenger audio jacks as a“Level D” development assurance level (“DAL”), while classifying other IFE services and functionality as a lower,“Level E” DAL.

[0021] Software systems categorized as Level D typically require recertification by the relevant certification authority when any changes are made to the software, whereas changes to software systems categorized as Level E typically do not require recertification. Therefore, in wired IFE systems using Level E software, software changes can be made within the IFE without typically requiring recertification, but a wireless IFE may include Level D software requiring recertification when changes are made.

[0022] Another design challenge characteristic of IFE systems is the physical hardware design of network components such as servers and passenger interfaces and the logistics of maintaining such hardware. Aircraft seats are passenger safety critical features of the aircraft that must pass strict safety requirements and testing. When an aircraft seat is designed to include a passenger interface (for example in the back of a headrest), the assembled seat including the passenger interface must pass the safety requirements and testing. In-seat device hardware is therefore expected to be robust and have a lifespan of several (e.g., ten or more) years, far beyond the lifespan typically expected of comparable consumer electronic devices. It can be difficult and costly to qualify hardware for safe use in aircraft and then deploy the hardware in an aircraft. Further, there is a need for commercial aircraft to remain in service, and there may be only limited, somewhat unpredictable windows of time in which the aircraft is grounded and available for updates. As a result, it can be difficult for the IFE experience to keep pace with advances that passengers have come to expect on their personal electronic devices (“PEDs”).

[0023] Systems, devices, and methods disclosed herein can provide an improved network for providing IFE and can generally include a wireless network design including individual passenger interface devices integrated in the aircraft configured to wirelessly receive communications from on-board data storage. Communications can include but are not limited to media content, data, software updates, firmware updates, new software or firmware installs, internet connectivity, control commands, status queries, safety functions, and other such communications as described herein or would be understood by a person of ordinary skill in the art. The wireless network can also generally include on-board data storage for storing media content, data, software updates, firmware updates, new software or firmware installs, and the like as described herein or would be understood by a person of ordinary skill in the art.

[0024] The wireless network design can include a centralized server or server subsystem configured to communicate with off-aircraft networking systems to provide off-aircraft connectivity and to download content and data to the on-board data storage. The centralized server or server subsystem can store the on-board data storage within the server or server subsystem and provide streaming content to each passenger interface via wireless access points (“WAPs”) distributed throughout the aircraft.

[0025] Servers and passenger interface devices can be configured with containerized software modules, and each software module can be independently modified or updated without affecting the functionality or integrity of other software modules. Software modules for a passenger interface device can include containerized applications based on DAL categorization, containerized third party applications and application platforms, a containerized maintenance interface, etc. Services provided by the server or server subsystem can include containerized services based on DAL categorization, containerized maintenance services, containerized aircraft communication bridge, containerized passenger seat services, containerized passenger interface device caching services, containerized media services, containerized flight data/mapping services, etc. [0026] The wireless network can operate via Wi-Fi in the 5GHz frequency space. The network can operate with the U-NII-1, U-NII-2, and U-NII-3 sub bands. The network can operate using 20 MHz, 40 MHz, 80 MHz, or 160 MHz channel widths, etc. In certain example embodiments, the network can include up to fifteen non-overlapping 20 MHz Dynamic Frequency Selection (“DFS”) channels and up to nine non-overlapping 20 MHz non-DFS channels. The network can include WAPs that are dynamically configured to utilize available DFS channels. Groups of passenger interfaces can be assigned to individual WAPs to form individual WAP networks.

[0027] Groups of passenger interfaces can be determined based on the physical placement of WAPs and passenger interfaces within the aircraft such that zones are determined based on WAPs and passenger interfaces that are within wireless range of each other. Service set identifiers (“SSIDs”) can be utilized to associate a group of passenger interfaces with a WAP. SSIDs and their respective authentication (password) can be created dynamically. Dynamic SSID creation can be configured such that no two aircraft ever have matching SSIDs, thereby reducing the likelihood that in-seat devices and WAPs from different aircraft would attempt to establish a connection. The network can include a setup process to create each SSID dynamically and pass appropriate authentication credentials to each in-seat device. The WAP networks can be dynamically reconfigured, and passenger interfaces can be dynamically re-grouped to distribute network load among the individual WAP sub-networks. A number of potential WAP configurations can be stored pre-flight and selected during flight to dynamically reconfigure the WAP networks during flight. Additionally, or alternatively, the wireless network can include a rules engine for evaluating WAP network performance during flight and dynamically reconfiguring the WAP networks during flight.

[0028] The wireless network design can include data caching strategies for distributed storage of data and content on network components including passenger interface devices distributed throughout the aircraft. Each individual passenger interface devices can include a data store, and each of the passenger interface devices can be configured to store at least a portion of the on-board data storage to the data store of the device.

[0029] A method for initializing data caching can include: a system initialization step proceeding to a flight open query step; entering a mode for supporting normal flight open operations if the flight is determined to be open in the flight open query step; proceeding to a content to cache query step if the flight is determined to be closed in the flight open query step; entering a mode to support normal flight closed operations if there is no content to be cached as determined by the content to cache query step; and entering a mode to engage multicast content push if there is content to be cached as determined by the content to cache query. Additionally or alternatively, while in the normal flight open operations mode the method can include: iteratively executing a should media playing be cached query; executing instructions to save while streaming if the playing media should be cached as determined by the should media playing be cached query; and remaining in normal flight open operations mode without executing instructions to save while streaming if the playing media should not be cached as determined by the should media playing be cached query.

[0030] As used herein, the terms“open” and“closed” in relation to aircraft operations as understood by persons skilled in the pertinent art. Generally, a flight may be considered“open” when cabin crew have determined cabin services can be initiated for a given flight. This determination may consider when flight data such as arrival/departure information is being passed to cabin systems via the flight computer, as well as when passengers and baggage are allowed to enter and/or exit the aircraft during normal (non-emergency) operation. A flight may be considered“closed” by the cabin crew by a combination of factors such as when passengers and baggage are prohibited from entering and exiting the aircraft, after a specific time interval after an aircraft lands, or other scenarios as the crew’s discretion. Other considerations such as maintenance, refueling, and aircraft personnel staffing may affect the status of the flight as“open” or“closed”.

[0031] For example, caching can occur between flights when the aircraft is parked at a gate, during flight when network usage is low, and/or while streaming from the centralized server. Content and data stored in on-board storage can be prioritized, high-value content and data can be identified for caching, the high-value data can be cached. Content and data to be cached can be wirelessly broadcast using a multicast protocol such as a User Datagram Protocol (“UDP”). Data transfer to the passenger interface device can utilize packetized file formats for wirelessly transmitting data for content such as a streaming standard format.

[0032] The wireless network can have a centralized network topology wherein each passenger interface can be configured to wirelessly receive content and data via WAPs from the centralized server. The server or server subsystem can include a caching service for monitoring network usage, determining a subset of passenger interface devices that are inactive, publishing a manifest of content to cache on the passenger interface devices, and controlling a sequence in which content and data is cached to the subset of passenger interface devices.

[0033] Passenger interface devices can operate in a disconnected local storage mode (“DLS”) in which the passenger interface devices are not in communication with a central server. In the DLS mode, passenger interface devices can provide entertainment and/or other interactions to passengers based on data stored in the passenger interface devices.

[0034] Aircraft network hardware can be pre-configured prior to installation in an aircraft with a pre-configuration system. The pre-configuration system can include centralized data storage including configurations for network hardware sets for one or more aircraft designs. Groups of hardware components including servers and passenger interface devices appropriate to outfit a specific aircraft can be selected, connected to the pre-configuration system, and pre-configured based on one of the one or more aircraft designs stored on the pre-configuration system. The pre configuration system can also include a loading device dedicated to a particular aircraft design or a small number of aircraft designs. The loading device can be configured with a virtualized aircraft network including hardware configurations for each hardware component in the aircraft network. The loading device can be physically located near an aircraft maintenance area and can be hardwired to hardware components to pre-configure the hardware components prior to the hardware components being installed in an aircraft.

[0035] The wireless network can include seat-to-seat communications for interaction between passengers or for communication of content and data between passenger interface devices. Seat- to-seat communications can be realized through a centralized network wherein a first passenger interface device communicates to a second passenger interface device via a path that includes communicating from the first passenger interface to a first WAP, communication from the first WAP to a server or server subsystem, communicating from the server to a second WAP, and communicating from the second WAP to the second passenger interface device. Additionally, or alternatively, seat-to-seat communications can be realized through a mesh network wherein passenger interface devices function as nodes in the mesh network. A communication path from a first passenger interface device to a second passenger interface device in a mesh network can include a communication directly from the first passenger interface device to the second passenger interface device if the two devices are in wireless range of each other, or the path can include a communication from the first passenger interface device that is repeated to one or more intermediate nodes in the mesh network (e.g., other passenger interface devices and/or WAPs) before being repeated from an intermediate node to the second passenger interface device.

[0036] Each passenger interface can be configured to act as a node in a wireless mesh network such that at least some of the passenger interfaces can transmit and/or receive communications to and/or from other passenger interfaces via the nodes of the wireless network.

[0037] These and other aspects of the present disclosure are described below in connection with the accompanying figures. Other aspects and features of embodiments of the present disclosure will become apparent to those of ordinary skill in the art upon reviewing the following description of specific, example embodiments of the present disclosure in concert with the figures. While features of the present disclosure may be discussed relative to certain embodiments and figures, all embodiments of the present disclosure can include any combination of features from any example discussed herein or as are known in the art. Further, while one or more embodiments may be discussed as having certain advantageous features, one or more of such features may also be used with the various embodiments of the disclosure discussed herein. In similar fashion, while example embodiments may be discussed below as device, system, or method embodiments, it is to be understood that such example embodiments can be implemented in various devices, systems, and methods of the present disclosure.

[0038] The components, steps, and materials described hereinafter as making up various elements of the disclosed technology are intended to be illustrative and not restrictive. Many suitable components, steps, and materials that would perform the same or similar functions as the components, steps, and materials described herein are intended to be embraced within the scope of the disclosed technology. Such other components, steps, and materials not described herein can include, but are not limited to, similar components or steps that are developed after development of the disclosed technology.

[0039] Embodiments and examples presented herein can provide several advantages over known aircraft networks supporting IFE systems including providing wireless network topologies for communicating to interactive passenger interface devices, systems and methods for containerizing software for rapid reconfiguration and/or updating of network components, systems and methods for caching data to the passenger interface devices, and systems and methods for performing seat- to-seat interactions between the passenger interface devices. Features of the various examples and embodiments described herein can be used alone, in combination with features from a same or different example or embodiment, and/or in combination with features known in the art to provide an improved aircraft network.

Example Embodiments

[0040] The examples disclosed herein illustrate devices, systems, and methods for a wireless IFE system for an aircraft. Fig. 1 is a line drawing illustrating network components 100 of a wireless IFE system according to example embodiments of the present disclosure. The components 100 include one or more servers 110, one or more WAPs 140, wired connections which can include coaxial cable, optical fiber, or other wired medium 130 connecting the servers 110 to the WAPs 140, one or more passenger interfaces 160, and wireless connections 150 connecting the passenger interfaces 160 to the WAPs 140. The server(s) 110 can connect to a number n of WAPs 140 through n wired connections 130 such that each WAP 140 is connected to the server(s) 110 through a dedicated wired connection 130. The server(s) 110 can alternatively or additionally connect to a number (e.g., //) of WAPs 140 through a number (e.g., //) of wireless connections (not shown) such that each WAP 140 is connected to the server(s) 110 through a dedicated wireless connection. The WAPs 140 can connect to a number x of passenger interfaces 160 through x wireless connections 150 such that each passenger interface 160 is connected to one of the WAPs 140 through a dedicated wireless connection 150. Each passenger interface 160 can be integrated into passenger seats 162 or otherwise made available for individual passenger viewing and interaction.

[0041] In certain example embodiments, the network components 100 can be disposed on an aircraft (not shown). The server(s) 110 can act as a gateway for data both coming aboard the aircraft and leaving the aircraft. The terms“data” and“content” are used interchangeably herein to refer to any information or other items that may be communicated or stored via a computing device. For example, the data can include audio and/or visual entertainment content to be exhibited to passengers, metadata or other information related to the entertainment content or operation of the IFE system or aircraft, software (such as updates to the IFE system), etc. Entertainment content can include, but is not limited to, images, media for movies, TV shows, music, games, applications, etc., as well as metadata associated with such media and/or the IFE system more generally. For example, the IFE system may process, generate, store, or communicate content such as license key information associated with entertainment content media files and/or analytics regarding flights, passengers, aircraft, and/or entertainment content. In certain example embodiments, content can be synchronized from ground/cloud sources to storage associated with the server(s) 110. From there, the server(s) 110 can make at least some of the content available for downloading and/or streaming, as appropriate, to the passenger interfaces 160.

[0042] The server(s) 110 can also interface with aircraft components beyond the network components 100. For example, the sever(s) 110 can receive discrete inputs from PA systems, avionics data busses from flight management computers, navigation systems, crew consoles etc. In certain example embodiments, such inputs can serve as triggers for specific system behaviors and can enable the server(s) 110 to provide applications at passenger interfaces 160 with information about the aircraft or an applicable flight of the aircraft, such as a location and/or flight path of the aircraft, and more.

[0043] The passenger interfaces 160 including computing devices that can serve as the primary user interface for passengers on the aircraft to engage the IFE system. For example, the passenger interfaces can be designed to deliver an intuitive and fulfilling user experience to passengers aboard the aircraft. The passenger interfaces 160 can include, for example, displays, controllers, buttons, data ports, audio jacks, and other such components through which a passenger can receive and enjoy content via the IFE system 100 or otherwise interact with the IFE system 100 while aboard the aircraft. In certain example embodiments, the passenger interfaces 160 can include integrated tablet units (“ITUs”) having touch screen or other interactive display functionality, in seat devices (“ISD”) integrated into the back of a seat headrest, and/or any other such device through which the passenger can interface with the IFE system 100. As will be appreciated and understood, in the examples described herein, the passenger interfaces 160 need not be limited to ITUs and/or ISDs.

[0044] Fig. 2 is a line drawing illustrating a system 200 for on-board aircraft services according to example embodiments of the present disclosure. As illustrated in Fig. 2, the system 200 can include an on-board server subsystem 210, WAPs 240, and passenger interfaces 260, such as ITUs. The on-board server subsystem 210 can connect via communication paths 230 in the form of wired connections to the WAPs 240 (alternatively, some embodiments can employ wireless connections between the on-board server subsystem 210 and the WAPs 240), and the WAPs 240 can have communication paths 250 in the form of wireless communication links to each of the passenger interfaces 260. The server subsystem 210 can also be in communication with crew panels 280 through a wired (or wireless) communication path 282, and the crew panels 280 can include a web client interface 285.

[0045] In certain example embodiments, the system 200 can be designed with modular software architectures for the on-board server subsystem 210 and the passenger interfaces 260. For example, modular software architectures might enable rapid development, easier integration with new features, and efficient scaling across multiple fleets. In some implementations, the modular design can reduce the need for full regression testing of changes in software configurations. For example, a core software architecture can be common across some or all fleet implementations. Platform specific adapters can be implemented to adapt the core implementation to specific interfaces and features of particular aircraft type.

[0046] As illustrated in Fig. 2, capabilities and interfaces can be organized into different services and applications with specific roles and purposes within the system 200. Software can be containerized and packaged into separate modules, allowing for integration with third party packages and the ability to upgrade packages without affecting other modules. With this scheme, aircraft type specific software can be packaged separately from common core software packages.

[0047] In the example modular on-board server subsystem 210 illustrated in Fig. 2, the server subsystem 210 can provide one or more services including maintenance service 211, aircraft communication bridge 212, seat state service 214, caching service 215, control 216, logging service 218, synchronization service 222, map service 224, and media service 226. The maintenance service 211 can be configured to support maintenance activities associated with the aircraft, such as presenting maintenance user GUIs, running built in tests, and supporting fault isolation, for example. The aircraft communication bridge service 212 can be configured to support aircraft interfaces and data buses such as discrete Aeronautical Radio, Incorporated (ARINC) standard 429 data buses and the like.

[0048] The seat state service 214 can be configured to support transactions and maintain the proper state of each seat display unit (e.g., display units within the passenger interfaces 160). The caching service 215 can be configured to support caching of content from the server (e.g., 110) to the passenger interfaces 160. The control 216 can be configured to support coordination of all other services 211, 212, 214, 215, 218, 222, 224, 226. The logging service 218 can be configured to aggregate log files, logging system states and faults, and passenger usage data, for example. The synchronization service 222 can be configured to synchronize data, e.g., to update onboard media content sets, media assets, and other data. The map service 224 can be configured to support a moving map application. The media service 226 can be configured to support content cataloging, streaming, licenses, and playback.

[0049] The server subsystem 210 can include only a single server or a plurality of servers, such as the server(s) 110 described above with respect to Fig. 1. The services 211, 212, 214, 215, 216, 218, 222, 224, 226 can reside on the single server, or alternatively, each of the plurality of servers can be dedicated to one service or multiple services. The server subsystem 210 can include a communication trunk 220 over which the services 211, 212, 214, 215, 216, 218, 222, 224, 226 can communicate to networked components of the system 200. The communication truck 220 can communicate to the WAPs 240 and the crew panels 280.

[0050] In certain example embodiments, the synchronization service 222 within the server subsystem 210 can act as a gateway service for data and content coming aboard the aircraft and leaving the aircraft and can be in communication with services external to the aircraft such as cloud services 310. Additionally, or alternatively, the synchronization service 222 can be in communication with media storage residing or transported aboard the aircraft such as a loader 290. Content provided by cloud services 310 or other sources external to the aircraft can include, for example, media creation services 320 and analytics services 330. Media creation services, for example, can include licensed movie, TV, music, or other video and/or audio content, and license key management services. Analytics services 330, for example, can include flight data, passenger, and aircraft analytics.

[0051] In certain example embodiments, the server subsystem 200 can be configured to wirelessly broadcast, via the WAPs 240, a first signal to the passenger interfaces 260 and a second signal to an aircraft PA system 295, where the first signal includes video playback command data and the second signal includes audio. The aircraft com bridge 212 can be configured to transmit the second signal to the PA system 295 via the communication trunk 220 of the server subsystem 210. The first and second signals can cause video displayed on multiple different passenger interfaces 260 to be synchronized with each other and synchronized with audio from the PA system 295. To achieve synchronous video playback between all passenger interfaces 260, the first signal contains a data message which is transmitted to and received by all passenger interfaces 260. The message payload instructs the passenger interfaces 260 which video to play, a precise time at which playback will begin, and at which frame of the video playback should be initiated. By including all of this data, not only can the passenger interfaces 260 begin playing a specified video in a synchronous fashion, but the ensuing playback can be interrupted or paused and subsequently resumed while still maintaining synchronization. Underlying the video playback synchronicity is the role of the on-board server subsystem 210 as a Network Time Protocol server for the passenger interfaces 260 to synchronize against as a common reference time source. To achieve synchronicity of audio playback via the PA system 295 audio and the videos being displayed on the passenger interfaces 260, a tunable time offset is implemented between driving the first and second signals. Propagation delays of the physical signals as well as inherent delays of systems can be incorporated into a set and deterministic delay between scheduled video playback initiation and the separate initiation of audio playback. Ultimately, the first and/or second signals can each respectively include a synchronized starting time, so that the PA system 295 and the passenger interfaces 260 begin synchronized playback at the same time from the passenger perspective.

[0052] As illustrated in Fig. 2, each example passenger interface 260 can include modular applications and layers to provide passenger facing applications 265 and maintenance mode applications 275. A custom firmware load can be installed on each passenger interface 260, with the firmware controlling base operation and configuration of each passenger interface 260. On top of the firmware, applications and services can be installed to handle aircraft-wide events such as public addresses and to provide passenger facing applications such as a map client application 264 through which passengers may view geographical location and/or flight path information for the aircraft, as well as other applications such as third-party applications 266. For example, the other applications may include games or other content that the passengers can play, view, and/or interact with. The passenger interface 260 can function in a passenger facing mode based on software containerized or packaged in a passenger facing applications module 265 or a maintenance mode based on software containerized in a maintenance mode applications module 278. [0053] The passenger facing applications module 265 can be designed according to a Clean Architecture model where code is separated into layers such that inner layers do not depend on outer layers. To that end, the passenger facing applications module 265 can include a presentation layer 270 through which lower level layers such as a domain layer 272 including business logic and a model layer 274 managing the business logic and handling application programming interfaces can communicate with the applications 264, 266. The passenger facing applications module 265 can further include a compliant third-party interface 268 through which the presentation layer 270 can communicate with the third-party applications 266. The passenger facing applications module 265 can further include a logger 276 in communication with the model layer 274.

[0054] The maintenance mode applications module 275 can be accessible via the presentation layer 270 of the passenger facing applications module 265 and can include a software update and testing interface 278, for example.

[0055] In operation, the server subsystem 210 and the passenger interfaces 260 can be configured to coordinate seamlessly across mode and flight stage transitions. For example, a crew member could access a crew management panel 280 to control IFE functions, like opening or closing the flight. In some examples, a crew member can toggle the flight status between open and closed via the crew management panel 280. The system 200 for on-board aircraft services can include signals, variables, or other indicators related to the flight status as open or closed. The crew management panel 280 can be connected to the server subsystem 210, and the change in state of the IFE system to an open flight (or other status) can drive an interaction for the passenger interfaces 260 to change their state to a matching flight open (or other) status accordingly. A signal indicating the flight status can be transmitted from the crew panel 280 to the on-board server subsystem. The on-board server subsystem 210 can store the flight status indicated by the signal from the crew panel 280 as a variable globally and/or within one or more of the services 211, 212, 214, 215, 216, 218, 222, 224, 226. In some examples, signals indicative of flight status can be transmitted wirelessly from the server subsystem 210 via the WAPs 240 to the passenger interfaces 260. Some or all of the passenger interfaces can store the flight status globally and/or within one or more of the modules 265, 275. Aircraft events, operational events, system health checks and the ongoing interactions between the server subsystem 210 and the passenger interfaces 260 can be balanced to ensure reliability and operability of the base system 200, while also minimizing impact to bandwidth available for entertainment functions.

[0056] In examples described herein, the wireless IFE system can operationally involve both aircraft and ground operations. Aircraft operations can involve the installed IFE system aboard the aircraft interacting with crew, passengers, maintenance personnel or other aircraft systems. Ground operations describe off-aircraft activities within the overall operational workflow of IFE (e.g. media content ingest/delivery in the cloud),“ground” systems (potentially including satellite communications) interacting with the on-aircraft wireless IFE (e.g. connecting to a data store on the ground/cloud to offload flight data), etc.

[0057] Governmental regulations (e.g., from the FAA and other applicable regulatory bodies), airline specifications, and airframe manufacturer specifications contain minimum requirements for operation software that is related to critical and/or safety related functions. In some examples presented herein, software can be packaged according to its impact on safety, criticality, and/or effect on crew workload to form standalone aircraft-specific software packages. Most of the IFE systems are generally not considered critical, and Fig. 2 which focuses on the high-level system design, does not specifically illustrate isolated critical software packages. Isolation of critical software packages is discussed in greater detail in relation to Figs. 8 and 9.

[0058] Network optimization and configuration of the wireless network presents challenges unique to on-aircraft wireless IFE systems. Several major considerations and aspects of network optimization exist for the wireless IFE, including: allocation of frequency spectrum, modification of the frequency allocation based upon environmental factors, allocation of wireless client connections among available WAPs, etc.

[0059] Various embodiments of the present disclosure can employ many different frequency spectrums, numbers of channels, and bandwidths for wireless communication. In some examples presented herein, the wireless IFE can operate via Wi-Fi in the 5 GHz frequency space including three sub bands: U-NII-1, U-NII-2, and U-NII-3. This spectrum can be subdivided into 20 MHz channels where the U-NII-1 and U-NII-3 sub bands collectively include nine non-overlapping 20 MHz channels that can function as non-Dynamic Frequency Selection (“non-DFS”) channels, and the U-NII-2 includes fifteen non-overlapping 20 MHz Dynamic Frequency Selection (“DFS”) channels. In the U-NII-2 sub band, Wi-Fi network WAPs are required to implement DFS by the United States Federal Communications Commission (and other country spectrum regulatory commissions) to avoid interfering with weather and military radar. In certain embodiments where aircraft offer in-flight Wi-Fi internet access to passengers via PEDs, the wireless traffic generated by the PEDs can occur exclusively on the U-NII-1 and U-NII-3 sub bands, thereby avoiding the DFS requirement in the U-NII-2 sub band. In certain example IFE systems presented herein, WAPs can implement DFS to provide Wi-Fi connectivity to passenger interfaces in the U-NII-2 sub band, thereby significantly increasing the number of available 20 MHz channels compared to other aircraft Wi-Fi networks. Some example IFE systems presented herein can be used in parallel with a Wi-Fi system providing internet connectivity to PEDs onboard by passengers, and the IFE can coordinate with the PED Wi-Fi system to share sub-channels in the 5 GHz frequency space.

[0060] The example IFE and the PED Wi-Fi system can include separate WAPs, such that a WAP connected to PEDs does not also connect to passenger interfaces (such as interfaces 160, 260). For instance, a twin (i.e., two) aisle aircraft can have a total of 12 WAPs (though other number of WAPs are contemplated herein) in the 5 GHz frequency space, 6 of which are dedicated to the IFE system, and 6 of which are dedicated to the PED Wi-Fi system, and a single aisle aircraft can have a total of 9 WAPs (though other number of WAPs is contemplated herein), 5 of which are dedicated to the IFE system, and 4 of which are dedicated to the PED Wi-Fi system. In other examples, a WAP can provide both IFE connectivity to passenger interfaces and internet connectivity to PEDs in the 5 GHz frequency space so that the total number of WAPs is reduced, or to provide greater signal strength to some parts of the cabin without increasing the number of WAPs.

[0061] In other examples, a WAP can include a 2.5 GHz radio and a 5 GHz radio, with the 2.5 GHz radio servicing the PED Wi-Fi system and the 5 GHz IFE system servicing the passenger interface Wi-Fi system.

[0062] By implementing DFS, in the presence of radar, the WAPs can automatically change to a different available frequency channel to avoid interfering with weather and military radar. Dynamically changing frequency channels during flight as a result of utilizing DFS channels presents design challenges to maintain constant wireless connections within the IFE system to successfully deliver multimedia and safety information after a channel change.

[0063] In some examples presented herein, a strategy for maximizing available bandwidth for IFE applications includes making use of the maximum available frequency spectrum, meaning inclusion of DFS channels into the implementation. The strategy can include putting measures in place to manage the spectrum allocation and channel assignments of the wireless IFE network because switching channels dynamically can cause interruptions to service and possibly operation of regulated and/or critical functions. Additionally, certain geographical regions may have different rules and regulations regarding DFS or other channels, and altitude also comes into play as generally being over 10,000 ft in altitude removes an aircraft from necessarily being considered within a particular regional jurisdiction. Furthermore, passenger bandwidth usage profiles and expected bandwidth requirements can also factor in to how and when the IFE wireless network should be adapted and configured.

[0064] In some examples, U-NII-2 sub channels can be evaluated to determine the likelihood that each sub channel will be required to switch during its flight path, and U-NII-2 sub channels determined to likely require less switching can be prioritized for use over U-NII-2 sub channels determined to likely require more switching. The sub channels can be evaluated based on data collected in previous flights, known conflicting system locations, etc. In some examples, passenger interfaces can be prioritized such that the highest priority passenger interfaces communicate on U-NII-1 sub channels and U-NII-3 sub channels, medium priority passenger interfaces communicate on high priority U-NII-2 sub channels, and lowest priority passenger interfaces communicate on low priority U-NII-2 sub channels.

[0065] Passenger interfaces can be prioritized based on a number of factors, such as location of the passenger seat, needs or statuses of passengers assigned to the passenger seat, etc. For example, passenger interfaces communicating with audio output can be prioritized over passenger interfaces not providing audio to reduce the likelihood that the audio jack is active during a PA system activation or decompression event. In certain example embodiments, passenger interfaces providing content that is more affected by an interruption of service (e.g. streaming video) can be prioritized over passenger interfaces providing content that is less affected (e.g. web browsing).

[0066] In certain embodiments, if a Wi-Fi enabled device is paired to multiple access points (e.g. a smart phone paired to overlapping ground-based Wi-Fi networks), the device will dynamically poll the signal strength from each access point and dynamically transition from one access point to another. Transitioning typically results in a few seconds of down time. In certain situations, particularly when on the ground and off an aircraft, this transition does not present a safety or a regulatory issue. However, dynamically transitioning from one WAP to another based solely on signal strength can pose issues in an aircraft. For example, in a standard aircraft having approximately six WAPs, each in range of most (if not all) of about 200 passenger interfaces in about 200 passenger seats, the signal strength from each WAP to each seat can change often as the aircraft moves and as objects and people within the aircraft move. As a result, in this example, passenger interfaces could frequently transition from one WAP to another WAP, resulting, at the least, in frequent, short duration down time, and at worst, complete stalling of the network.

[0067] To adapt to the complex operating environment and optimize the wireless network, examples presented herein include capabilities to allow for dynamic changes to the WAP configuration. For example, with reference to Fig. 1, WAP configuration files can be stored or generated on by the IFE server(s) 110, and the WAPs 140 can be directed to load particular configurations depending upon the situation. The WAP configuration file can include instructions that cause the WAP 140 to be associated with a zone which is also associated with a subset of the passenger interfaces 160. In some embodiments, the WAP configuration can include an SSID.

[0068] With reference to Figs. 1 and 2, a rules engine 217 can be configured to perform analytics and decision making to optimize current and future configurations of the wireless network components 100 to ensure robust and seamless network performance. In certain example embodiments, the rules engine can include a table 219. The table 219 can include aircraft equipment configuration. In the table 219, each passenger interface (160, 260) is associated with a list of SSIDs and a set of rules. The list of SSIDs can include SSIDs of WAPs (140, 240) on the same aircraft as the associated passenger interface (160, 260). The list of SSIDs can be hierarchical. Additionally, or alternatively, each SSID can be associated with a list of passenger interfaces (160, 260), which can also be hierarchical. The set of rules can determine under what condition the respective passenger interface (160, 260) will be instructed, by the server 110, to transition from one SSID to another SSID based on the passenger interface’s (160, 260) list of SSIDs and/or the SSID’s list of passenger interfaces (160, 260). In certain example embodiments, the rules can include a bandwidth threshold which causes a passenger interface (160, 260) to transition from an SSID of a WAP (140, 240) operating at a bandwidth consumption over the threshold to an SSID of a WAP (140, 240) operating at a bandwidth consumption below the threshold. [0069] In some examples presented herein, a design strategy with respect to overall network performance involves optimal allocation of passenger interfaces (160, 260) to particular WAPs (140, 240). During setup, passenger interfaces (160, 260) can be assigned to a primary WAP (140, 240) and a hierarchical chain of backup WAPs (140, 240). In certain example embodiments, passenger interface assignments and hierarchical chains can be stored to WAP configuration files and/or the rules engine. The rules engine can dynamically assign passenger interfaces (160, 260) to WAPs (140, 240) with an overall strategy to optimize performance of the IFE and minimize the number of passenger interfaces (160, 260) that have limited or no Wi-Fi access. In certain example embodiments, some passenger interfaces (160, 260) can have deeper hierarchical chains of backup WAPs (140, 240) to facilitate those passenger interfaces (160, 260) staying connected over passenger interfaces (160, 260) having a shorter hierarchical chain if some passenger interfaces (160, 260) must be disconnected to avoid overloading operational WAPs (140, 240). In some example embodiments, hierarchical chains can be coordinated such that when a WAP (140, 240) fails, the migration of passenger interfaces (160, 260) from the failed WAP (140, 240) to other WAPs (140, 240) doesn’t inherently overload any of the remaining operating WAPs (140, 240).

[0070] Allocation of passenger interfaces (160, 260) to WAPs (140, 240) can be optimized based upon, for example, analysis of how many clients a particular WAP (140, 240) can support, location of each passenger interface (160, 260) with respect to each WAP (140, 240), the likely signal to noise ratio of a given passenger interface (160, 260) to a given WAP (140, 240), and the likely wireless interference sources aboard the aircraft. A second tier of next to most optimal allocations can also be determined that could enable a fall back behavior of passenger interface (160, 260) to secondary WAPs (140, 240) when the optimal WAP is unavailable. Alternatively, or additionally, thresholds can be set related to the allocation of clients per WAP (140, 240), signal to noise ratio between each client and WAP (140, 240), available bandwidth of each WAP, throughput from each WAP (140, 240)to client and a passenger interface (160, 260) can fall back to a secondary WAP (140, 240)when one or more of the thresholds is exceeded. The passenger interface (160, 260) can return to a primary WAP (140, 240)when the primary WAP (140, 240) is available to operate with the passenger interface (160, 260) under the given thresholds.

[0071] Allocation of passenger interfaces (160, 260) to WAPs (140, 240) can be achieved through predetermined and/or dynamic zoning of the aircraft. While each fleet type may be somewhat different, for each fleet an optimal zoning concept can be derived to segregate the cabin into several smaller sub-networks. For example, the first-class cabin can be separated from business class, which can also be separated from the economy class, and the economy class can be further subdivided into sections. Alternatively, or additionally, the aircraft can be split such that an even number of passenger interfaces (160, 260) are assigned to each WAP (140, 240), or a hybrid configuration may prove most appropriate. Alternatively, or additionally, the effects of the physical construction of the aircraft interior and position of obstructions such as bulkheads can be considered to determine how wireless signals propagate from each WAP (140, 240) and thereby assign passenger interfaces (160, 260) to each WAP (140, 240) that is in a path having a strong signal from that WAP (140, 240). Such an analysis could result in passenger interfaces (160, 260) assigned to WAPs (140, 240) that aren’t necessarily the closest WAP (140, 240) but are nevertheless the strongest signal provider.

[0072] The network 100 can therefore be configured to establish zones such that each WAP (140, 240) supports passenger interfaces (160, 260) only connecting to the most optimal WAP network (130, 230) available to it. In certain example embodiments, passenger interfaces (160, 260) can be prevented from associating with WAPs (140, 240) determined to be sub-optimal due to overall signal to noise, distance, and/or interference. Such a sub-optimal connection could provide for poor performance of that passenger interface (160, 260), potentially resulting in an overall effect of bringing down system level performance. Additionally, the accessibility of certain content can be determined at least in part based on the particular zone for a passenger interface (160, 260). For example, passenger interfaces (160, 260) in certain zones may have access to certain content (or priority speed at which content is delivered) that is unavailable to passenger interfaces (160, 260) in other zones.

[0073] In certain example embodiments presented herein, in order to realize the different aircraft zones, SSIDs can be generated which correspond to desired aircraft zoning. These SSIDs can be propagated to each passenger interface (160, 260) such that each passenger interface (160, 260) can be configured to connect to the appropriate SSID and therefore the appropriate WAP (140, 240). The passenger interfaces (160, 260) can ignore and not connect to WAPs (140, 240) which do not contain the hierarchical list of optimal SSIDs. [0074] In certain example embodiments, passenger interfaces (160, 260) can be associated with particular passengers for particular flights to provide a custom-tailored experience. For example, passenger data, flight data, marketing data, etc. can be provided via the server(s) (110, 210) and used to identify relevant content that the passenger is mostly likely interested in viewing during the flight. Identified content can be presented to the passenger at the associated passenger interface (160, 260) as part of a personalized IFE experience. The passenger can be associated with the passenger interface (160, 260) by default based on their seat assignment and/or can provide an identifier such as a frequent flier number, Bluetooth transmission from their PED, QR code, etc. to the passenger interface (160, 260) upon being seated. The personalized content can include, for example, suggestions for movies, music, games, etc., information regarding a connecting flight schedule, information regarding sites at the destination city, and/or instructions and maps for navigating to a connecting gate, baggage claim, ground transportation, parking, etc. at the destination airport.

[0075] In certain example embodiments, zoning can be maintained by the server(s) (110, 210). The server(s) (110, 210) can be configured to communicate with the WAPs (140, 240) and passenger interfaces (160, 260) to establish the zones (e.g. by managing SSIDs). For example, the server(s) (110, 210) can maintain a map, table, and/or listing of WAPs (140, 240) and passenger interfaces (160, 260) such that zones are determined based at least in part on physical locations of WAPs (140, 240) and passenger interfaces (160, 260) as indicated on the map/table/listing. The map/table/listing can include additional passenger accommodations not necessarily associated with in-flight entertainment such as information typically included in a layout of passenger accommodations (LOP A) map. Seat locations can also be included in the map/table/listing such that each passenger interface (160, 260) is associated with a corresponding seat number.

Data Caching

[0076] In certain example embodiments, data caching at passenger interfaces can be utilized as a strategy for reducing overall bandwidth requirements of the wireless network. In systems reliant solely on streaming from head end units or on-board servers, potentially hundreds of passenger interfaces (160, 260) in addition to PEDs brought aboard can be concurrently streaming movies, music, games, or other content/applications. An approach for reducing stress on the network during times of peak passenger usage can include a seat-centric mode of operation enabled through smart data caching of content at each passenger interface (160, 260). The wireless IFE implementation can use a two-tiered strategy to data caching to further optimize caching. Depending on the flight mode and on-board activities, the wireless IFE system can either cache content locally on the passenger interfaces (160, 260) through a wireless multicast content transfer or by saving target content while streaming.

[0077] Fig. 3 is a flow diagram showing aspects of a method 300 and modes of operation for caching data in an aircraft on-board network according to example embodiments of the present disclosure. The method 300 begins with system initialization 350 and proceeds to a flight open query step 352 that determines whether the current status of the flight is open or closed. During the system initialization step 350, components within the IFE system configured to communicate with other (non-IFE) systems within the aircraft can be initialized. For example, the server subsystem 210 can be booted or otherwise initialized. The flight open query step 352 can be performed at least in part by an onboard server such as server 210.

[0078] As determined in the flight open query step 352, if the flight is closed, the method 300 proceeds to a content cache query step 354 in which an evaluation is performed to determine whether a particular passenger interface (such as the passenger interfaces 160, 260) has a complete cached set of content and if any content missing from the passenger interface is available from servers (such as servers 110, 210). For example, the caching service 215 of the onboard server subsystem 210 can maintain a manifest of content available to cache.

[0079] A manifest of content cached at each passenger interface can be maintained by each respective passenger interface and/or by the caching service 215. The cache query step 354 can include comparing the server’s manifest of content to each respective passenger interface’s manifest of cached content to determine the missing content for each passenger interface. The manifest comparison can be performed, for example, by the server’s caching service 215 and/or by individual passenger interfaces. For example, the server’s manifest of content can be transmitted to some or all of the passenger interfaces so that the comparison can be performed at the passenger interface. In certain example embodiments, when a passenger interface maintains a manifest of cached content, some or all of the passenger interfaces can transmit their respective manifest of cached content to the server so that the comparison can be performed at the server. [0080] If it is determined in query step 354 that content is missing from the passenger interface, and the missing content is available from the server(s), the method 300 proceeds to engage in a multicast content push 356 where the server subsystem 210 transmits content to the passenger interface and potentially one or more other passenger interfaces for which content transmission is desired. For example, the server subsystem 210 can determine in step 354 whether content is missing from multiple passenger interfaces and, if so (and if the missing content is available from the server(s)), push the missing content to each of those passenger interfaces in step 356.

[0081] If it is determined in query step 354 that the passenger interface has a complete set of content or that content missing from the passenger interface is not available from servers, the method 300 proceeds to support normal flight closed operations 360. Returning to the flight open query step 352, if the flight is open, the method 300 proceeds to support normal flight open operations 358 and meanwhile iteratively executes a streaming media caching query 362 which can determine whether content currently streaming to a particular passenger interface includes content that is marked as a subset of data that should be cached by the passenger interface. So long as the streaming media caching query 362 results in a no, normal flight open operations 358 will be supported. When the streaming media caching query 362 results in a yes, the process 300 will engage a save while streaming mode 364 wherein content streaming to a particular passenger interface is cached by the passenger interface.

[0082] In certain example embodiments, content sets resident on the server(s) can be refreshed on an approximately monthly basis. Data size of monthly downloads can be on the order of tens to hundreds of gigabytes. The total content set stored on the server(s) can be on the order of terabytes. In certain example embodiments, marketing or other analysis can be performed to identify the sub content set of the overall content set, which is most likely to be viewed by a large majority of passengers or most relevant/desirable to certain respective passengers. For example, marketing, flight, and/or passenger data can be used to identify relevant content that each passenger or groups thereof are mostly likely interested in viewing during the flight. In certain example embodiments, the sub-content set can be flagged or annotated in content metadata to indicate that it includes “high value” content. The server(s) and/or each passenger interface can cause this sub-content data to be cached at the applicable passenger interface(s) so that the passenger(s) can access some or all of the identified content with no or minimal streaming during flight. [0083] In certain example embodiments, after content and metadata is made available in wireless IFE server storage, such as storage associated with the server subsystem 210 of Fig. 2, the high value content flagged as such in the metadata can be pushed to local storage on all or select passenger interfaces. Thus, each passenger interface can locally play popular/desired content without initiating a video streaming session with the server - thereby reducing its relative load on the network.

[0084] In some examples presented herein, during times where the on-board system is powered up, but the flight has not been opened for passenger use, the server(s) can engage in a multicast protocol such as User Datagram Protocol (“UDP”) to push content to all passenger interfaces leveraging a UDP -based File Transfer Protocol (“UFTP”). Content which can be cached can be organized into sections which are further split into serialized data packets. Content sections can be announced to the passenger interfaces, which can be registered as multicast receivers, and subsequently the server can engage the multicast push of the content section over Wi-Fi. Due to the nature of UDP multicast, some packet loss could occur. As passenger interfaces fail to receive specific packets, negative acknowledgements (“NAKs”) can be sent back to and tracked by the server. The missed packets can be later re-transmitted until all packets have been received by all passenger interfaces, or until specific failure criteria are met, at which point re-transmissions can be halted.

[0085] Generally speaking, multicast content transfers across Wi-Fi can be challenging; however, when used together with a modular wireless IFE architecture such as the architecture presented herein, shortcomings of multicast content transfers can be overcome, and advantages of multicast content transfers can be realized. In certain example embodiments, some content, such as high value content and/or content that is universally (or substantially universally) relevant/desirable, can be pushed to all passenger interfaces alike. With several, even hundreds of, passenger interfaces per cabin, the multicast approach of transacting identical payloads to all passenger interfaces concurrently can afford the benefit of scaling. As the numbers of passenger interfaces on an aircraft increases, so can the benefits of the multicast approach. The benefit of moving data simultaneously to all clients, albeit at slower rates, can be more advantageous, for example, than establishing TCP connections with a handful of passenger interfaces at a time and pushing content at higher rates. [0086] In certain example embodiments, an overall data caching strategy for IFE can include a second-tier in which content is saved as it is streaming. The server can be configured to provide a manifest to each passenger interface, which identifies each item of content to be cached locally on the passenger interface. For example, when a passenger accesses a particular video or other item of content on their passenger interface, the passenger interface can check that particular video/item against the manifest for the passenger interface to see if that item should be cached. If the item is identified on the manifest, and if a file for the item is locally available, the passenger interface can choose to exhibit the item (e.g., by displaying visual content and/or playing audio content, as applicable) from the locally stored copy of the file. If the file is not locally available, the passenger interface can begin streaming the content from the server - and saving the content to local storage. In this manner, content that is not successfully cached using the multicast push approach has a high probability of being accessed and then cached using the save while stream strategy. As more passengers board the aircraft and use the system, more content will be likely accessed and saved to passenger interface local storage. Examples presented herein can include the ability to remotely clear cached data from passenger interfaces.

[0087] In certain example embodiments, the IFE system can utilize a packetized file format for wireless file transfer. Packetized file formats break content into sequences of small HTTP -based file segments, with the segments being transmitted and sequentially reassembled at the destination device. These file segments can be packaged to optimize performance of the multicast content transfer when engaged in that mode of data caching. If only some segments of a particular piece of content are successfully transferred by the time the multicasting ceases, e.g., upon a flight opening, those segments can still represent valid, locally playable media which reduces network load. When the media player associated with the passenger interface recognizes that it reaches a point in the content where segments are not locally available, it can stream and save those segments from the server.

[0088] In certain example embodiments, the server(s) and passenger interfaces are configured to receive updated content, such as new media and software updates. For example, the server(s) can receive the updated content from one or more external devices (e.g., via the cloud services 310) and push the updated content, as appropriate, to the passenger interfaces. In certain example embodiments, components within the IFE system, such as the passenger interfaces, can include Commercial Off-The-Shelf (“COTS”) components running on third party operating systems. These components may be combined with custom software, such as a customer graphical user interface (GUI) for passenger interfaces or crew panels.

[0089] Passenger interfaces and other components utilizing such software and operating systems can receive software patches, updates, and the like, e.g., via the server(s). For example, the software can be periodically upgraded to correct flaws or enhance the user experience. Additionally, seasonal items such as safety videos, special user content, etc. can be updated from time to time. For example, an operator of the IFE system could upload new content to alter the look and feel of the interface for a specific holiday or destination.

[0090] In certain example embodiments, new or updated content, such as new entertainment media, safety videos, seasonal images, software updates, read-only memory (ROM) updates, operating system kit updates, upgrades, and the like, can be uploaded to the server and then pushed to the passenger interfaces, as applicable, for installation. The content may be loaded before the desired timeframe for installation/use. For example, a seasonal video might be loaded before the season to which it belongs. In certain example embodiments, this content can be preloaded to the server at any time with a set install date/time, and the server can hold the content for installation once the set installation date/time has arrived. For example, when the installation date/time arrives, the server can push the updated content to the passenger interfaces for installation/use on the passenger interfaces. Additionally, or alternatively, the server can push updated content to the passenger interfaces prior to the set installation date/time, and the passenger interfaces can store the content (e.g., data, updates, etc.) until the content is ready to be installed. For example, the passenger interfaces can store the content until a flight is closed or as part of a pre-cached installation plan.

[0091] In certain example embodiments, after new content is uploaded to the server, the server can distribute this content and the loading date/time to the passenger interfaces during downtime, such as when the flight is closed or when the aircraft is undergoing maintenance. Uploading data during downtime rather than streaming or uploading during flight could prevent the network from being overloaded during flight. Operators can have the option of letting the passenger interfaces automatically apply/use the update content or to apply/use the updated content following an input through the crew management panel. Additionally, pre-caching the content updates on the passenger interfaces during downtime can allow for simultaneous updating of all or a subset of the passenger interfaces, whereas pushing updates from the servers to the passenger interfaces during between-flight operation could result in a spurious or sporadic update to the passenger interfaces, with potentially a higher risk that the updates will not be complete before the aircraft resumes normal service.

[0092] In certain example embodiments, content can be multicast to passenger interfaces when the flight is closed or in maintenance mode; however, in cases involving a transfer of a significant amount of data, passenger interfaces may not receive their entire set of content before normal flight operations resume. In some examples, passenger interfaces can receive content during flight in times of low network utilization, such as during night flights across an ocean, when many passengers are sleeping.

[0093] Fig. 4 is a line drawing illustrating a system for caching data in an aircraft on-board network according to example embodiments of the present disclosure. As illustrated in Fig. 4, an on-board aircraft wireless network 400 can include a caching service 415 in communication with IFE servers 410. The caching service 415 can monitor communications between the IFE servers 410 and WAPs 440 and passenger interfaces (460a, 460b). The IFE servers 410, WAPs 440, and passenger interfaces (460a, 460b) may be substantially similar to the servers (110, 210), WAPs (140, 240), and passenger interfaces (160, 260) described above, for example. When bandwidth usage falls below a certain percentage, the caching service 415 can publish a manifest listing of content for the passenger interfaces (260a, 260b) to download. As illustrated in Fig. 4, during times of low usage, a majority of passenger interfaces 460a can be unused or lightly used, and a few passenger interfaces 460b can be busy. Each unused or lightly used passenger 460a can then choose or have selected by the server 410 or data cache service 415, for example, one item from the manifest list and commence downloading that item.

[0094] In certain example embodiments, the caching service 415 can roll through a list of passenger accommodations and only offer the manifest to a subset of the passenger interfaces (460a, 460b). For example, the subset can include all passenger interfaces (460a, 460b) on a single WAP 440 or a small number of passenger interfaces (460a, 460b) from a majority of the WAPs 440. Passenger interfaces (460a, 460b) can be prioritized by being queued in an earlier position in the list based on a number of factors, such as location of the passenger seat associated with the passenger interfaces (460a, 460b), needs or statuses of passengers assigned to the passenger seat, etc. As each passenger interface (460a, 460b) in the subset finishes its download, a new passenger interface (460a, 460b) can be offered the manifest. The caching service 215 can roll through the list of passenger accommodations until all unused or lightly used passenger interfaces 460a have downloaded content and/or all busy passenger interfaces 460b have refused to download content.

[0095] In certain example embodiments, the wireless IFE system can operate in a Disconnected Local Storage (“DLS”) mode in which the wireless IFE system can operate even if the WAPs and/or servers are offline. In DLS mode, each passenger interface can provide content and functionality based on software and media saved in memory of the passenger interface, thus ensuring that certain entertainment features are provided to passengers even if each passenger interface is not networked. For each passenger interface to function in a non-networked fashion, each passenger interface can contain in memory an operating system, software, and content for providing entertainment

Pre-Configuring Aircraft Network Hardware:

[0096] In certain example embodiments, management of IFE components and installation of firmware, data, software, content, and the like can be carried out by treating the individual hardware components as blank slates to be installed in the aircraft. The components can be configured after installation and then loaded with content. In such systems, content is typically brought to the aircraft via Single Large Expensive Disks (“SLEDs”) and uploaded to on-board IFE hardware through special loader devices while the aircraft is down for maintenance.

[0097] In alternative example embodiments, the IFE components and other aircraft hardware assets can be pre-configuring prior to installation into a target aircraft. Fig. 5 is a line drawing illustrating a pre-configuration system for preconfiguring aircraft network hardware according to example embodiments of the present disclosure. As illustrated in Fig. 5, instead of keeping IFE servers 510a-c, passenger interfaces 560a-c, and other aircraft hardware in cold storage, hardware can be pre-configured with a pre-configuration system 500. The configuration of aircraft hardware can be virtualized to a central storage location (or cloud) 505, and groups of aircraft network hardware components can be pre-configured based on a design for a particular aircraft. As illustrated, a first hardware set including a first server 510a and first set of passenger interfaces 560a can be pre-configured for installation in a first type of aircraft, a second hardware set including a second set of servers 510b and a second set of passenger interfaces 560b can be pre- configured for a second type of aircraft, and a third hardware set including a third set of servers 510c and a third set of passenger interfaces 560c can be pre-configured for a third type of aircraft, etc. As will be appreciated and understood, any number of pre-configurations can be virtualized thusly. When the time comes to install the IFE system and other aircraft network components, hardware components including passenger interfaces and servers can be selected from a collection of pre-configured hardware components grouped by aircraft type, reducing installation time.

[0098] The pre-configuration system 500 can include loading devices 520a-c connected to the central storage location 505. The loading devices 520a-c can be configured with a virtualized aircraft network including hardware configurations for each hardware component in an aircraft network. As illustrated in Fig. 5, a virtualized network loader 520a-c can be configured for a single aircraft. The configured virtualized network loader 520a-c can be hardwired to the hardware components such as servers 5 lOa-c and passenger interfaces 560a-c, and the hardware components can be pre-configured based on the configuration on the associated virtualized network loader 520a-c. With the pre-configurations system 500, content can be downloaded to the servers 510a- c and passenger interfaces 560a-c, including DLS content. When the time comes to replace a passenger interface in service in an aircraft, a replacement passenger interface can be selected that is pre-configured to have the most update-to-date content and software installed, eliminating the need to perform a laborious update process after installation of the replacement passenger interface.

[0099] In certain example embodiments, the pre-configuration system 500 can be configured to pre-configure the server(s) 510a-c in addition to (or in lieu of) the passenger interfaces 560a-c. In such example systems, replacing a defective server with a pre-configured server can be relatively easy, as compared to embodiments where a complete update is required upon installation of a new server. For example, it may be possible to complete a server replacement between flights so that fewer flights operate without an IFE following a server outage.

[0100] Another advantage of virtualization of the aircraft via a pre-configuration system is the ability to make use of hardwire connections for downloading configurations. Hardwired connections can offer several gigabytes of speed and better reliability than wireless connections, allowing for master configuration of the IFE hardware compared to systems which rely on configuring components after installation in an aircraft.

[0101] In certain example embodiments, virtualized network loaders 520a-c can be physically placed where aircraft are maintained, making it convenient for maintenance personnel to pull a replacement pre-configured component, such as a server 510a-c or a passenger interface 560a-c from the loader group and install the replacement device in the aircraft. Hardware components can be line replaceable units (“LRUs”) that can be pre-configured based on the virtualized network loader 520a-c to which it is connected. New LRUs connected to a virtualized network loader 520a- c can automatically begin to be configured as they are connected.

[0102] In certain example embodiments, a virtualized network loader 520a-c need not include a complete aircraft configuration, as data and updates can be pushed to aircraft network hardware through other means presented herein or through traditional means once the hardware is installed in an aircraft. For new installations, a complete shipset can be installed and configured on aircraft network components as the aircraft is being assembled. Preconfigured LRUs can be placed into service as aircraft assembly progresses.

Seat-to-Seat Networking:

[0103] Example wireless IFE systems presented herein can form a rather large wireless network. For example, an IFE system can include hundreds of passenger seats, each with a passenger interface or other interactive device having a wireless network connection, and the IFE system can include tens of WAPs that connect the passenger interfaces to a central server or server subsystem. The central server or server subsystem can host entertainment content and operating software, and it can also serve as a network hub for seat-to-seat interactions.

[0104] Example applications that could potentially take advantage of such seat-to-seat interaction include games and social networking. Fig. 6 is a line drawing illustrating a centralized network for wireless seat-to-seat interaction according to certain example embodiments of the present disclosure. As illustrated in Fig. 6, in some examples presented herein, within a seat-to-seat network 600, passenger interfaces 660a-b can host an application, such as a racing game, first person explorer game, a poker tournament, messaging application for passenger-to-passenger messaging at passenger interfaces 660a-b, or other such applications, while an on-board server or server subsystem 610 acts as an intermediary passing data between the passenger interfaces 660a-b to facilitate seat-to-seat interaction. As illustrated in Fig. 6, each passenger interface 660a-b can communicate via a wireless link 650a-b to a WAP 640 that is in communication with the on-board server or server subsystem 610. Data from a first passenger interface 660a to a second passenger interface 660b can therefore pass from the first passenger interface 660a through a first wireless connection 650a, to the WAP 640, to the server 610, from the server 610 to the same or different WAP 640, through a second wireless connection 650b, and out to the second passenger interface 660b.

[0105] In certain example embodiments, the seat-to-seat network 600 can include PEDs 670a-b, such as phones, tablets, computers, and the like brought aboard by passengers. Using Near-Field Communication (“NFC”), for example, passengers can pair their PEDs 670a-b to their passenger interface 660a-b and use the PEDs 670a-b to interact with the passenger interface 660a-b, e.g., as a form of a keyboard or game controller. Instead of reaching up to the passenger interface 660a-b (which may be close but optimized for viewing rather than interaction), the passenger can control the passenger interface 660a-b from their lap/hands.

[0106] Example seat-to-seat networks presented herein can allow passengers traveling together but seated apart to keep in contact without having to get out of their seat. For example, passengers can use NFC and/or short-range wireless technology, such as Bluetooth™ technology, within the PEDs 670a-b and/or passenger interfaces 660a-b to converse with other passengers at the opposite ends of the aircraft. Example seat-to-seat networks can also allow passengers seeking more competitive gaming to challenge other passengers to head-to-head competition. As illustrated in Fig. 6, the server 610 can act as the go between to transmit information between passenger interfaces 660a-b; however, the network 600 can also be configured to allow a passenger to broadcast a general challenge across the network 600 at a first passenger interface 660a, with other passengers being able to seek out that challenge or even make one themselves from a second passenger interface 660b.

[0107] Fig. 7 is a line drawing illustrating a mesh network for wireless seat-to-seat interaction according to example embodiments of the present disclosure. As illustrated in Fig. 7, an aircraft system can include a seat-to-seat network 700 having a mesh networking topology wherein passenger interfaces 760a-f can each act as a node in the network 700. [0108] Generally speaking, mesh networking is an Internet-of-Things (“IoT”) hot button. It can be defined as a decentralized form of creating a network in which no one device acts as a central facilitator. Generally, in a mesh network, each networked device can communicate with the other devices in the network that are in range of each device’s wireless antenna. Communication with devices beyond the range of the wireless antenna requires“hopping” through one or more nodes (connected devices) creating a path or a map to a location. Because mesh networks are based on wireless connections, and most wireless devices are portable, a general problem with many mesh networks is that, more often than not, the devices connected to the mesh network are transient, meaning a mesh map constructed from transient nodes once generated can quickly become obsolete. However, within an aircraft, passenger interfaces 760a-f can be generally stationary in relation to each other, and PEDs 770b, 770d carried by passengers can remain stationary (for the most part) during flight. Therefore, the general problem of frequent network map generation present in most networks is much less of a problem in an aircraft wireless network.

[0109] In wireless aircraft networks relying primarily on communication between passenger interfaces and a centralized server, problems can occur with network reliability during times of network stress, such as when the majority of the passengers are streaming movies or when the WAPs are not working as efficiently as they could be, and the passenger experience could be degraded. For example, those passengers wishing to interact with other passengers (such as through a social networking app like Instant Messenger) might find that their passenger interface simply will not hold a reliable connection to the central server.

[0110] In an example on-board wireless network utilizing a mesh network topology such as the network 700 illustrated in Fig. 7, in addition to a centralized network topology, during times of heavy load when the centralized wireless network is saturated, groups of underutilized passenger interfaces 760a-f can switch wireless channels and make themselves available as mesh network interfaces (nodes) to form the mesh network 700. In one implementation of the example mesh network 700, when a first passenger interface 760a is unable to connect to a second passenger interface 760f via a centralized wireless network (such as illustrated in Fig. 6 or otherwise known in the art) when using an application such as a messaging application, the passenger interface 760a can scan for and connect to in-range passenger interfaces 760b, 760d, 760e acting as mesh network nodes and communicate through the mesh network 700 to the second passenger interface 760f, thereby allowing a passenger using the first passenger interface 760a to interact with a passenger using the second passenger interface 760f over the mesh network 700.

[0111] In another implementation of the mesh network 700, if the passenger interfaces 760a-f are having trouble getting a complete set of content marked for caching via a centralized network, for example as a result of peak usage by passengers of the passenger interfaces 760a-f, the server or server subsystem in the centralized network could prevent the passenger interfaces 760a-f from being able to download the content. In this scenario, the mesh network 700 can provide a means of decentralized sharing of content by allowing content to pass, e.g., from the first passenger interface 760a in the mesh network 700 to the second passenger interface 760f in the mesh network. For example, underutilized passenger interfaces that are part of the mesh network 700 can push file updates and small software patches over the mesh network 700 between the first passenger interface 760a and the second passenger interface 760b. When the passenger interfaces 760a-f form nodes of a mesh network 700, each passenger interface node 760a-f can publish a list of software package versions and stored updates that are saved locally on that passenger interface 760a-f, and the passenger interface 760a-f can then share the local data with other passenger interface nodes 760a-f across the network 700, reducing the load on the centralized IFE server network.

Containerized Certified Software:

[0112] To comply with DO-178C and other regulatory requirements, when passengers are aboard and engaged in interactions with their respective passenger interfaces, IFE software must reliably be able to interrupt their interactions with the IFE to bring attention to safety related instructions or procedures as appropriate. Software functions classified as DAL Level D by DO-178C currently include (1) muting the audio on passenger interfaces when the PA mute keyline is activated, and (2) disabling inputs, display, and sound of passenger interfaces when the decompression keyline is activated. The software level establishes the rigor necessary to demonstrate compliance with DO-178C. Other IFE software functions are generally classified as DAL Level E, which is subject to less rigorous compliance requirements than software functions classified as DAL Level D.

[0113] In certain example embodiments, in the case where a crew member initiates a public address, passenger interface audio jacks can be muted such that the passenger can hear announcements made via the public address, e.g., via overhead cabin speakers; and in the case where a decompression event is recognized by the appropriate aircraft systems, the IFE server subsystem can be notified and can cause passenger interfaces to be muted with display screens disabled.

[0114] In certain example embodiments, the identified higher software level functions (e.g. Level D) can be packaged as standalone software modules which do not rely on software modules of the IFE that provide other content/data, e.g., entertainment content. In some examples, additional functions can be included in a higher-level software module as makes sense from an implementation perspective, despite not comprising safety critical functions in and of themselves. For example, unmuting the audio on the passenger interfaces when the PA mute keyline is deactivated is not a Level D function, but this function can be included in an example higher-level software module as appropriate. In certain example embodiments, functions that are tangential to Level D functions but do not in of themselves require Level D assurance can be excluded from a higher-level software module. For example, a decompression event typically triggers playback of a Pre-Recorded Audio Message (“PRAM”), and the PRAM can be engaged by a lower-level software module.

[0115] A potential advantage of standalone higher-level software modules is that only a one-time certification of the performance of the module may be required until changes are made to the module itself. This can allow the other many components of the IFE system and software to be updated and upgraded without affecting the higher-level software and therefore necessitating the added delays and expenses of recertification. In many cases, when upgrading lower level IFE software, so long as there is a high confidence that the upgrades do not affect higher level functionality, there is no need for recertification of either of the higher-level software modules or the lower-level software modules.

[0116] In certain example embodiments, higher-level modules can include a header, tag, or other associated data to indicate when changes in the software module occur. For instance, each higher- level module can be associated with a checksum or hash value. When changes in higher-level software occur, the software can be flagged for recertification. The checksum, hash, or other conformity check can be reported via an appropriate maintenance interface. [0117] In certain example embodiments, higher-level modules and lower-level modules can utilize differing network communication protocols. For instance, IFE modules, such as the modules 211, 212, 214, 215, 216, 218 and rules engine 217 illustrated in Fig. 2, can communicate via a bidirectional unicast protocol, while Level D software modules, such as Level D module 228 illustrated in Fig. 2 module can communicate using a one-way multicast protocol from the server to the passenger interfaces. The passenger interfaces can include modules such as the modules 265, 275 illustrated in Fig. 2 configured to receive the bidirectional unicast protocol from the server subsystem 200 and a Level D module 279 configured to receive the one-way multicast protocol. The multicast protocol allows simultaneous receipt by all passenger interfaces 260 and does not require a message broker such as is typical in unicast communications. By separating the communication schemes, entertainment content can be provided with a more complex transmission scheme allowing for greater efficiency and a tailored experience for each passenger while more tightly regulated and/or safety related functions can be provided over a separate transmission scheme that can remain operational even if the entertainment content transmissions go down due to message broker failure, etc.

[0118] Fig. 8 is a line drawing illustrating an isolated regulated software module 830 on an aircraft server 810 according to example embodiments of the present disclosure. Fig. 9 is a line drawing illustrating an isolated regulated software module 930 on a passenger interface 960 according to example embodiments of the present disclosure. For example, the software modules 830, 930 in Figs. 8 and 9 can include Level D software modules. In certain example embodiments, for each fleet, there can be an isolated higher-level server software module (such as the module 830 in Fig. 8) and an isolated higher-level passenger interface software module (such as the module 930 in Fig. 9). The full scope of the higher-level regulated functions of the IFE system can be captured within these isolated software modules 830, 930, and safety event messages can be transacted between the server and passenger interfaces by executing the isolated software modules 830, 930.

[0119] The software module 830 is implemented by server hardware 810. The server hardware 810 can be included, for example, in any of the example servers and server subsystems 110, 210, 410, 510a, 510b, 510c, 610 presented herein. The server hardware 810 can have hardwired inputs receiving a PA signal 802 and a decompression signal 804. The server hardware 810 can include a digitizer 812, an input/output expander 814, a processor 820, memory including a Level D software module 830 with instructions that can be executed by the processor 820, and Level E software modules 860. Aircraft interfaces providing the PA signal 802 and the decompression signal 804 can vary from fleet to fleet or aircraft to aircraft, therefore the digitizer 812, EO expander 814, and Level D software module 830 can be tailored for the specific aircraft or fleet.

[0120] The digitizer 812 can receive the analog PA signal 802 and decompression signal 804 and digitize each signal. In some examples, in response to a crew member initiating a public address through one of the several handsets in the cabin, an input discrete keyline 802 to the server 810 can be activated low. In some examples, the keyline 802 can include multiple keyline inputs and the keyline 802 can be considered active when at least one of the multiple keyline inputs is low. In some examples with multiple keyline inputs, the server 810 can broadcast a safety event message indicating PA activation to all zones of the aircraft regardless of which zone a single keyline input is activated.

[0121] In operation, electrical noise can impact the PA 802 and keyline 804 signals. The digitizer 812 can mitigate the effects of noise. In some examples, the digitizer can use debouncing to reduce the likelihood of false positives on the keylines by monitoring the state of the keyline and only providing an indication of an active keyline state if the keyline has transitioned to an active state and remained in an active state for a specified delay time.

[0122] The server Level D software module 830 can include a standalone software package to handle PA keyline and decompression discrete inputs and generate corresponding multicast safety event messages to the passenger interfaces as appropriate. As will be appreciated and understood by a person of ordinary skill in the art, incorporation of handle aircraft interfaces and transmitting system wide messages into a single software package is in contrast to the general layered / Clean Architecture design of entertainment related software modules as described in relation to Fig. 2.

[0123] As illustrated in Fig. 9, broadcasts from the server 810 initiated by the PA mute broadcast 834 or the decompression broadcast 835 can be received by each passenger interface 960 and the passenger interfaces 960 can have hardware 912, 920 and a corresponding software module 930 to receive and act upon the broadcasts.

[0124] In certain example embodiment, each software module 830, 930 can consider four potential input states: (0) PA keyline inactive and decompression keyline inactive; (1) PA keyline active and decompression keyline inactive; (2) PA keyline inactive and decompression keyline active; (3) PA keyline active and decompression keyline active. The software module 830 of the server 810 can initiate a safety event message broadcast according based on the input state: normal operation or no broadcast for input state (0); broadcast PA mute for input state (1); and broadcast decompression for input states (2) and (3). The software module 930 of each passenger interface 960 can receive each broadcast event message, extract that state of the message, respond accordingly, and forward intent messages to Level E software modules 970 on the passenger interface 960 to perform lower-level functions such as pausing or suspending user entertainment and other applications.

[0125] Referring to Fig. 8, a method is illustrated in the software module 830 as a flow diagram for receiving PA and decompression data and broadcasting accordingly. Block 831 illustrates the CPU 820 polling the PA and decompression states from the digitizer 812 and EO expander 814. Block 832 illustrates the next action to be executed based on the input states 0, 1, 2, and 3 as described above. If, at block 832, it is determined that the inputs are in state 0, meaning the PA and decompression keylines are inactive, the software module 830 can initiate a“normal operation” broadcast 833, or alternatively, no broadcast. A“normal operation” broadcast can be advantageous when there is an input state change. No broadcast during normal operation can be advantageous to reduce power and wireless bandwidth consumption. If at block 832, it is determined that inputs are in state 1, meaning the PA keyline is active and the decompression keyline is inactive, the software module 830 can initiate a PA mute broadcast 834. If at block 832, it is determined that inputs are in state 2 or 3, meaning the decompression keyline is active, the software module can initiate a decompression broadcast 835. In some examples, event messages broadcast from the server 810 to the passenger interfaces 960 can include a payload including a state enumeration value prepended to a timestamp string.

[0126] Referring to Fig. 9, the passenger interface Level D software module 930 can be implemented on passenger interface hardware 960. The passenger interface hardware 960 can be included in any of the example passenger interfaces 160, 260, 460a, 460b, 560a, 560b, 560c, 660a, 660b, 760a-f presented herein. The passenger interface hardware 960 can include, for example, an RF receiver 912, a processor 920, memory including Level D software module 930 with instructions that can be executed by the processor 920, and Level E software modules 970. [0127] A method is illustrated in the software module 930 as a flow diagram for receiving an event broadcast 902 from the server 810. Block 930 illustrates the RF receiver 912 receiving the broadcast 902 and the broadcast being received from the receiver 912 by the CPU 920. Block 932 illustrates the next action to be taken based on the type of event indicated in the received broadcast 902. In some examples, the broadcast can include an indication of a state 0, 1, 2, 3 as described above. If at block 932, it is determined that the event broadcast 902 indicates that normal operation is resumed (e.g. PA Mute event has ended), the software module 840 can reactivate the audio jack. In some examples, resuming normal operation following a decompression event can further require a reboot of the passenger interface 960. If at block 932 it is determined that a PA Mute event is received in the broadcast 902, the audio jack of the passenger interface can be muted at block 934. If at block 932 it is determined that a decompression event is received in the broadcast 902, the passenger interface can mute the passenger interface audio so that overhead speakers can be heard, a passenger interface display screen backlight can be turned off, and inputs to the passenger interface can be deactivated to prevent a user from interacting with the passenger interface at block 935.

[0128] In Figs. 8 and 9, responding to decompression events and to PA mute activation is handled by a single software module 830, 930, respectively, however, it is contemplated that the PA mute activation and the decompression could be handled by two separately isolated software modules on one or both of the server 810 and the passenger interface 960. An advantage of the combined module 830, 930 is that states wherein both decompression and PA mute are active can be seamlessly coordinated. However, it can be advantageous to separately isolate the PA mute and the decompression in separate software modules to reduce the size of the software that must be recertified when changes are made.

[0129] In some examples, to increase efficiency of safety event message broadcasts, Audio PA broadcasts 834 can be managed with two different delivery streams based on state changes from enabled to disabled and from disabled to enabled. For each send session, a connection can be established to a defined multicast group. The message payload can have a minimal footprint to minimize network impact and demand. A“1” or a“0” can be prepended to a timestamp value to indicate PA“active” or“inactive,” respectively. The message payloads can be received by the passenger interface 960, and the event 932 can proceed to block 934 for payloads prepended with a“1” and to block 933 for message payloads prepended with a“0”.

[0130] In some examples, when providing a PA mute broadcast 834, the broadcast can include a continuous stream of“Audio PA activation” messages at a predefined rate. While the continuous stream is broadcast, the software module 830 can iteratively poll the decompression state 831, and the“Audio PA activation” messages can be broadcast while it is determined at the state inquiry block 832 that the PA keyline is active and the decompression keyline is inactive. Upon transitioning from state 1 to state 0, a continuous stream of a predetermined count of Audio PA deactivation messages can be transmitted at a predetermined rate as part of a normal operation broadcast 833.

[0131] In some examples, decompression can largely follow the same implementation as the PA mute on both the server and passenger interface sides, with some differences. In some examples, in response to a cabin pressure monitoring/waming system in the cabin sensing a drop-in cabin pressure, an input discrete keyline(s) to the IFE server can be driven to an active low state to drive the IFE to initiate a decompression activation response. Following the same basic implementation described for the PA Mute, initiation of the decompression response can yield a multicast message being propagated to the system via UDP multicast. In some examples, the multicast messages will be propagated to all passenger interfaces for as long as the decompression keyline is active.

[0132] As with the PA Mute implementation, in some examples, the isolated IFE software module 830 on the server 810 can implement a basic debouncing of the decompression discrete input signal. In some examples, the server and/or passenger interface software module 830, 930 can be programmed such that the IFE will not recover from a decompression event until a power cycle is accomplished, meaning when the system initializes, the decompression discrete must be inactive in order for the system to re-initialize into an operational state. Therefore, if the decompression discrete is activated and the IFE responds appropriately, deactivating the discrete without cycling system power will not affect the system mode - in other words the system will remain in a state where the passenger interfaces are muted and screens are off.

[0133] Similar to PA mute handling, a multicast message can be sent out to the passenger interfaces 960 in order to propagate the notification of a decompression event at 835. In some examples, the message payload can be reduced to a minimal footprint to minimize network impact/demand. For instance, a“2” (corresponding to the state determined in block 832) can be prepended to a timestamp value to indicate decompression is“active”. Other message payloads can include additional states which can be supported, such as having both PA Mute and Decompression active at the same time (state 3 as determined in block 832). Passenger interfaces 960 can receive the prepended payload and the passenger interface software module 930 can process the state at block 932. In some examples, the passenger interfaces can include a timeout parameter such that after a long enough time has passed following a PA Mute active signal, the passenger interface will proceed as if having received a signal indicating that PA Mute deactivated.

[0134] In some examples, transitioning from‘enabled’ is FALSE to TRUE (keyline/discrete is activated), which can trigger a continuous stream of Decompression activation messages at block 835, at a rate which can be set via software defined configuration macros. As in the case with the PA Mute activation, the activation of the decompression event from the server can be subject to a specified debounce time delay value for activation.

[0135] In some examples, the IFE software does not deactivate a decompression event which has been activated, but rather, to resume normal operation of the IFE, the IFE system can be rebooted after the cabin pressure system has stop driving the decompression discrete input 804.

[0136] In some examples, the decompression activation message can be received and handled by the same dedicated, standalone system service as the Audio PA message. The service can listen on a specified port for the multicast message. Once the Decompression activation message is received, the service can mute audio, darken the screen, and the application is directed to a blank activity - preventing any further user interaction with the passenger interface. The passenger interface can be left in this state until the system is rebooted, and no further decompression messages are being sent from the server (discrete is deactivated).

[0137] In some examples, the server higher-level software module 830 is a service running on the server 810. As with other services on the IFE server 810, the service 830 can be initialized by the operating system’s high-level service management functionality. Furthermore, the service 830 can be monitored by the system’s high-level service management functionality, which can attempt to restore operation of the safety service 830 if its operation is observed as defunct or notify the IFE’s health monitoring capability that the safety software 830 is unavailable. [0138] In some examples, the passenger interface safety software 930 is a service. The service 930 can include a Broadcast Receiver 931 which can get called when the passenger interface 960 boots. Once the service 930 has been started, it can listen on the appropriate port and address for the multicast safety event messages. This approach facilitates the passenger interface safety software 930 being initialized when the device 960 is booted.

[0139] In some examples, logging mechanisms can be built into the respective software modules 830, 930. On the server 810, events that can be logged can include, for example: General Purpose Input/Output (“GPIO”) read or state change, message pack and multicast send, GPIO read errors, multicast socket errors, Application Program Interface (“API”) errors, and service startup errors. On the passenger interface 960, events that can be logged can include, for example: audio PA START/STOP, audio PA status change, decompression START, socket connections, disabling backlight and Light Emitting Diodes (“LEDs”), log writing errors, muted/unmuted audio streams, and multicast socket errors.

[0140] Referring to Fig. 9, the passenger interfaces 960, intents can be generated by the isolated module 930 and communicated to other IFE software modules 970. Intents can each be generated based on a multicast event message from the server 902. In addition to Level D functions such as muting and/or disabling the passenger interface 960, the passenger interfaces can include functionality initiated based on multicast event messages such as displaying an announcement, pausing media players, etc. Intents can be generated by the Level D software module 903 at blocks 933, 934, 935 and transmitted to the Level E software modules 970 which can act on them. For normal operation events, an intent can be generated at block 933 and received by a Level E software module 970 at block 971, and the method can proceed to block 972 where passenger interface applications resume normal operation. For PA mute events, an intent can be generated at block 934 and received by a Level E software module 970 at block 973, and the method can proceed to block 974 to pause applications on the passenger interface so that they can be resumed during normal operation without the user missing a part of movie or other content. For decompression events, an intent can be generated at block 935 and received by a Level E software module 970 at block 975, and the method can proceed to block 976 to suspend application on the passenger interface so that the passenger interface can function as desired following a reboot of the passenger interface . [0141] A first example method can include some or all of the following steps presented in no particular order. Some or all of the steps of the first example method can be executed by an in- aircraft computing device on an aircraft.

[0142] The first example method can include determining that an in-flight entertainment device on the aircraft does not have a locally stored copy of an item of entertainment content, identifying a flight mode of the aircraft, and causing the item of entertainment content to be downloaded for local storage at the in-flight entertainment device. A manner of downloading the item of entertainment content can be based at least in part on the identified flight mode.

[0143] In the first example method, the flight mode can include one of open or closed. The manner of downloading the item comprises engaging in a save while streaming mode if the identified flight mode is open. The manner of downloading the item can include a multicast transmission if the identified flight mode is closed.

[0144] A second example method can include some or all of the following steps presented in no particular order. Some or all of the steps of the second example method can be executed by a server on an aircraft.

[0145] The second example method can include wirelessly transmitting in-flight entertainment system data to a plurality of in-seat passenger interfaces in the aircraft, determining a flight mode of the aircraft, and initiating or ceasing delivery of the in-flight entertainment system data from the server to at least a portion of the in-seat passenger interfaces based at least in part on the determined flight mode.

[0146] In the second example method, the in-flight entertainment system data can include one or more of a firmware update, a software update, and/or entertainment content.

[0147] The second example method can further include, in combination with any of the aforementioned steps of the second example method, comparing content stored on the server to content cached on each of the wireless in-seat passenger interfaces, selecting respective content from the content stored on the server to cache for each one of the in-seat passenger interfaces, and transmitting at least a portion of the respective selected content to each one of the in-seat passenger interfaces based at least in part on the aforementioned comparison. [0148] The second example method can further include, in combination with any of the aforementioned steps of the second example method, comparing content stored on the server to content cached on each of the in-seat passenger interfaces, determining that content caching for at least a subset of the in-seat passenger interfaces is complete, based at least in part on the comparing, and transmitting flight closed operation instructions to the at least a subset of the in-seat passenger interfaces for which content caching is determined to be complete.

[0149] The second example method can further include, in combination with any of the aforementioned steps of the second example method, selecting data to be delivered wirelessly from the server to the plurality of in-seat passenger interfaces based at least in part on in-flight entertainment system metadata stored on the server.

[0150] The step of wirelessly transmitting can include wirelessly transmitting at least a portion of the in-flight entertainment system data to at least a portion of the in-seat passenger interfaces via a multicast protocol.

[0151] An in-aircraft server can include a processor and non-transitory computer readable medium in communication with the processor. The server memory can include instructions thereon that when executed by the processor cause the server to execute some or all of the steps presented in no particular order. When executed by the processor, the instructions can cause the server to determine whether a flight status of an aircraft is open or closed. When the flight status is determined to be open, the instructions can cause the server to stream entertainment content for exhibition via an in-seat passenger interface of the aircraft and instruct the in-seat passenger interface to cache the streaming entertainment content to a memory of the in-seat passenger interface. When the flight status is determined to be closed, the instructions can cause the server to determine whether entertainment content accessible to the server is not cached in the memory of the in-seat passenger interface wirelessly transmit the entertainment content to the in-seat passenger interface.

[0152] In combination with any of the aforementioned steps executable in response to the processor executing the instructions, when the flight status is closed, the instructions can cause the server to deliver a firmware and/or software update from the in-aircraft server to the memory of the in-seat passenger interface. [0153] In combination with any of the aforementioned steps executable in response to the processor executing the instructions, the instructions can cause the server to multicast entertainment content to the in-seat passenger interface.

[0154] In combination with any of the aforementioned steps executable in response to the processor executing the instructions, the instructions can cause the server to select the entertainment content to be streamed for exhibition via the in-seat passenger interface based at least in part on metadata stored on the in-aircraft server.

[0155] A third example method can include some or all of the following steps presented in no particular order. Some or all of the steps of the third example method can be executed at an in seat computing device of an aircraft.

[0156] The third example method can include receiving a request to exhibit entertainment content, determining that at least a portion of the entertainment content is not stored (un-stored portion) in a local storage of the in-seat computing device, and storing some or all of the previously un-stored portion of the entertainment content in the local storage of the in-seat computing device, where at least some of the previously un-stored entertainment content is wirelessly streaming from an in- aircraft server, and the storing is performed in response to determining that the portion of the entertainment content is not stored in the local storage.

[0157] In the third example method, the un-stored portion of the entertainment content becomes stored only if the un-stored portion is identified in a list of items of entertainment content selected for local storage at the in-seat computing device.

[0158] A fourth example method can include some or all of the following steps presented in no particular order. Some or all of the steps of the fourth example method can be executed at a wireless in-seat passenger interface in an aircraft.

[0159] The fourth example method can include receiving streaming in-flight entertainment data, caching at least a portion of the streaming in-flight entertainment data within a memory of the in seat passenger interface, and exhibiting entertainment content via the in-seat passenger interface such that the entertainment content is based in part on the streaming in-flight entertainment data and data stored within the memory of the in-seat passenger interface. [0160] In the fourth example method, the streaming in-flight entertainment data can include one or more of a firmware update, a software update, and/or entertainment content.

[0161] In the fourth example method, the caching step can further include comparing content present on the in-seat passenger interface to an in-flight entertainment content manifest and selecting the portion of the streaming in-flight entertainment data to cache based at least in part on the comparing.

[0162] A fifth example method can include some or all of the following steps presented in no particular order. Some or all of the steps of the fifth example method can be executed by an in- aircraft computing device.

[0163] The fifth example method can include monitoring bandwidth usage by in-seat entertainment devices, determining that the bandwidth usage is below a predetermined threshold, and causing each of the in-seat entertainment devices to download and locally store at least one item of entertainment content in response to determining that the bandwidth usage is below the predetermined threshold.

[0164] In the fifth example method, the at least one item of entertainment content can be selected from a list of a plurality of items of entertainment content to be locally stored at the one or more of the plurality of in-seat entertainment devices.

[0165] In the fifth example method, each one of the in-seat entertainment devices can select the at least one item of entertainment content that is downloaded and locally stored at the respective one of the one or more in-seat entertainment devices.

[0166] In the fifth example method, the causing step can include the step of selecting each of the in-seat entertainment devices based on at least one of a bandwidth usage of the respective in-seat entertainment device, a wireless access point associated by with the respective in-seat entertainment device, or a relative priority of the in-seat entertainment device.

[0167] The fifth example method can further include, in combination with any of the aforementioned steps of the fifth example method, prioritizing each of the in-seat entertainment devices for content caching in relation to other of the in-seat entertainment devices. [0168] An example system can include a server within an aircraft. The server can be configured to communicate with in-seat passenger interfaces and provide a caching service. The caching service can be configured monitor bandwidth usage of wireless communication between a plurality of in-seat passenger interfaces and the server, publish a manifest listing content to be transferred from the server to at least a portion of the plurality of in-seat passenger interfaces, and initiate transmission of content from the server to the portion of the in-seat passenger interfaces based at least in part on the manifest and the bandwidth usage.

[0169] In combination with any of the aforementioned features of the example system, the caching service can be further configured to prioritize each of the in-seat passenger interfaces for content caching in relation to other of the in-seat passenger interfaces.

[0170] A sixth example method can include some or all of the following steps presented in no particular order. Some or all of the steps of the sixth example method can be executed by an in- aircraft server.

[0171] The sixth example method can include identifying zones in an aircraft such that each zone includes one or more in-seat computing devices in the aircraft, associating each of the zones with a subset of wireless access points (WAPs) in the aircraft such that each WAP subset includes at least one of the aforementioned WAPs, and inhibiting, via a wireless protocol, each of the in-seat computing devices from communicating with any of the WAPs other than a WAP in the WAP subset associated with one of the identified zones which includes the respective in-seat computing device.

[0172] The sixth example method can further include, in combination with any of the aforementioned steps of the sixth example method, inhibiting, via the wireless protocol, at least a portion of the in-seat computing devices from communicating with a WAP on another aircraft.

[0173] In the sixth example method, the wireless protocol can include dynamic service set identifier creation.

[0174] The sixth example method can further include, in combination with any of the aforementioned steps of the sixth example method, creating the zones based at least in part on seat numbers associated with the in-seat computing devices. [0175] In the sixth example method, the inhibiting step can include the step of causing each of the in-seat computing devices to connect to a particular one of the WAPs only if the particular one of the WAPs has a service set identifier included on an approved list of service set identifiers.

[0176] The sixth example method can further include, in combination with any of the aforementioned steps of the sixth example method, changing at least one of the zones or the associations of zones and WAPs to improve overall network performance.

[0177] In the sixth example method, the associating step can further include associating each in seat computing device to a respective primary WAP of the aircraft WAPs, associating a first portion of the in-seat computing devices to a first secondary WAP of the aircraft WAPs, associating a second portion of the in-seat computing devices to a second secondary WAP of the aircraft WAPs, and maintaining a predetermined set of one or more rules for transitioning a respective in-seat computing device from its respective primary WAP to its secondary WAP.

[0178] The sixth example method can further include, in combination with any of the aforementioned steps of the sixth example method, transitioning at least a first in-seat computing device based on the predetermined set of one or more rules. The predetermined set of one or more rules can include at least one bandwidth threshold.

[0179] The sixth example method can further include, in combination with any of the aforementioned steps of the sixth example method, associating each of the plurality of in-seat passenger interfaces with a respective seat number of a respective aircraft seat and grouping each of the plurality of in-seat passenger interfaces into a respective zone of the plurality of zones based at least in part on the respective seat number.

[0180] The sixth example method can further include, in combination with any of the aforementioned steps of the sixth example method, predetermining at least a portion of the zones based at least in part on installation locations of the in-seat computing devices within the aircraft.

[0181] The sixth example method can further include, in combination with any of the aforementioned steps of the sixth example method, associating each zone with a respective unique service set identifier of a respective WAP of the plurality of WAPs. The unique service set identifiers can be hidden. [0182] The sixth example method can further include, in combination with any of the aforementioned steps of the sixth example method, distributing entertainment media to at least a portion of the in-seat passenger interfaces.

[0183] The sixth example method can further include, in combination with any of the aforementioned steps of the sixth example method, wirelessly communicating between at least a portion of the WAPs and at least a portion of the in-seat passenger interfaces over a U-NII-2 frequency sub band.

[0184] The sixth example method can further include, in combination with any of the aforementioned steps of the sixth example method, selecting the portion of in-seat passenger interfaces which communicate over the U-NII-2 sub band based on one or more of: a class of a respective aircraft set in which the respective in-seat passenger interface is integrated, status of audio output of the respective in-seat passenger interface, and a content streaming rate to the respective in-seat passenger interface.

[0185] The sixth example method can further include, in combination with any of the aforementioned steps of the sixth example method, wirelessly downloading software and/or firmware from an off-aircraft storage medium to an onboard storage medium and wirelessly distributing the software and/or firmware from the onboard storage medium to in-seat passenger interfaces.

[0186] The sixth example method can further include, in combination with any of the aforementioned steps of the sixth example method, configuring, via the wireless protocol, the WAPs such that the WAPs are not configured to communicate with a personal electronic device.

[0187] An example IFE server in an aircraft, can include a WAP configuration file stored thereon. The WAP configuration file can include instructions thereon, that when executed by a processor of the server, cause the server to perform some or all of the following steps presented in no particular order. When executed by the processor, the instructions can cause the server to associate each of a plurality of in-seat passenger interfaces to a respective primary WAP, associate at least a first portion of the in-seat passenger interfaces to a first secondary WAP, associate at least a second portion of the in-seat passenger interfaces to a second secondary WAP, and cause a respective in-seat passenger interface to transition from its respective primary WAP to its respective secondary WAP based on rules in the WAP configuration file.

[0188] A seventh example method can include some or all of the following steps presented in no particular order. Some or all of the steps of the seventh example method can be executed by an in-aircraft server.

[0189] The seventh example method can include executing instructions from a first software module to wirelessly broadcast a safety event message to in-seat passenger interfaces and executing instructions from a second software module to wirelessly transmit entertainment content to at least a portion of the plurality of in-seat passenger interfaces. The first software module and second software module can be isolated from one another.

[0190] The seventh example method can further include, in combination with any of the aforementioned steps of the seventh example method, receiving a PA signal. The step of executing instructions from the first software module to wirelessly broadcast the safety event message can be responsive to receiving the PA signal. The safety event message can be indicative of the PA announcement.

[0191] The seventh example method can further include, in combination with any of the aforementioned steps of the seventh example method, receiving a decompression signal. The step of executing instructions from the first software module to wirelessly broadcast the safety message can be responsive to receiving the decompression signal. The safety event message can be indicative of aircraft decompression.

[0192] The seventh example method can further include, in combination with any of the aforementioned steps of the seventh example method, receiving a PA signal and a decompression signal substantially simultaneously. The step of executing instructions from the first software module to wirelessly broadcast the safety event message can be responsive to receiving the decompression signal. The safety event message can be indicative of aircraft decompression.

[0193] The seventh example method can further include, in combination with any of the aforementioned steps of the seventh example method, executing additional instructions from the first software module to wirelessly broadcast, to the in-seat passenger interfaces, a normal operation message indicative of a lack of a safety event. [0194] In the seventh example method, the first software module can be certified as Design Assurance Level (DAL Level) D according to DO-178C. The second software module can be certified as DAL Level E according to DO-178C.

[0195] The seventh example method can further include, in combination with any of the aforementioned steps of the seventh example method, updating the first software module independent of the second software module.

[0196] An eighth example method can include some or all of the following steps presented in no particular order. Some or all of the steps of the eighth example method can be executed by an in seat passenger interface.

[0197] The eighth example method can include executing instructions from a first software module to wirelessly receive a safety event message and disable audio of the in-seat passenger interface in response to receiving the safety event message and executing instructions from a second software module to wirelessly receive entertainment content and provide an output based on the entertainment content. The first software module and second software module can be isolated from one another.

[0198] The eighth example method can further include, in combination with any of the aforementioned steps of the eighth example method, executing first software module instructions to transmit an intent message to the second software module. The intent message can be based at least in part on the safety event message. The intent message can be configured to communicate a mute command if the safety event message is indicative of a PA broadcast and a disable command if the safety event message is indicative of a decompression event. The intent message can be configured to communicate a reboot command following elapse of a predetermined time period following last receipt of the safety event message being indicative of the decompression event.

[0199] The eighth example method can further include, in combination with any of the aforementioned steps of the eighth example method, executing additional instructions from the second software module to mute upon receiving the mute command and to disable upon receiving the disable command. [0200] In the eighth example method, the first software module can be certified as Design Assurance Level (DAL Level) D according to DO-178C. The second software module can be certified as DAL Level E according to DO-178C.

[0201] The eighth example method can further include, in combination with any of the aforementioned steps of the eighth example method, updating the first software module independent of the second software module.

[0202] A first example aircraft computing system can include an IFE system including a first software module classifiable as Design Assurance Level (DAL Level) D according to DO-178C and a second software module classifiable as DAL Level E by DO-178C. The first and second software modules can be isolated from one another.

[0203] In combination with any of the aforementioned features of the first example aircraft computing system, the first software module can include a conformity check indicative of a change in the first software module. The conformity check can include at least one of a checksum and/or a hash value.

[0204] In combination with any of the aforementioned features of the first example aircraft computing system, the IFE system can further include an in-seat passenger interface including memory having the first software module and the second software module stored thereon and a processor in communication with the memory.

[0205] In combination with any of the aforementioned features of the first example aircraft computing system, the first software module can include instructions thereon that when executed by the processor cause the in-seat passenger interface to continuously monitor for a mute command and disable audio outputs of the in-seat passenger interface in response to receiving the mute command. The second software module can include instructions thereon that when executed by the processor cause the in-seat passenger interface to display entertainment content.

[0206] In combination with any of the aforementioned features of the first example aircraft computing system, the first software module can further include instructions thereon that when executed by the processor cause the in-seat passenger interface to unmute audio outputs of the in seat passenger interface in response to deactivation of the mute command. [0207] In combination with any of the aforementioned features of the first example aircraft computing system, the first software module can further include instructions thereon that when executed by the processor cause the in-seat passenger interface to interrupt inputs, display, and audio outputs of the in-seat passenger interfaces in response to receiving the mute command.

[0208] In combination with any of the aforementioned features of the first example aircraft computing system, the first software module can further include instructions thereon that when executed by the processor cause the in-seat passenger interface to initiate playback of a Pre- Recorded Audio Message (PRAM) in response to receiving a decompression command.

[0209] In combination with any of the aforementioned features of the first example aircraft computing system, the in-flight entertainment system can further include an in-aircraft server including memory having the first software module and the second software module stored thereon and a processor in communication with the memory. The first software module can include instructions thereon that when executed by the processor cause the in-aircraft server to provide wireless communications to a plurality of in-seat passenger interfaces via a multicast protocol. The second software module can include instructions thereon that when executed by the processor cause the in-aircraft server to provide wireless communications to the plurality of in-seat passenger interfaces via a unicast protocol.

[0210] In combination with any of the aforementioned features of the first example aircraft computing system, the in-aircraft server can further include a seat state software module stored on the memory that when executed by the processor causes the server to change a state of each of the plurality of in-seat passenger interfaces from a flight closed state to a flight open state.

[0211] In combination with any of the aforementioned features of the first example aircraft computing system, the server can further include a PA signal input and a decompression signal input. The PA signal input can be configured to receive a PA signal. The decompression signal input can be configured to receive a decompression signal. The first software module can include instructions that when executed by the server processor causes the server to initiate a safety event message broadcast based at least in part on the PA signal and/or the decompression signal. One or both of the PA signal and the decompression signal can be binary. [0212] In combination with any of the aforementioned features of the first example aircraft computing system, the server can further include a digitizer configured to filter signal noise from the PA signal and the decompression signal.

[0213] In combination with any of the aforementioned features of the first example aircraft computing system, the safety event message can be configured to communicate: a decompression broadcast when the decompression signal is active; a PA broadcast when the PA signal is active and the decompression signal is not active; and a normal operation broadcast when the PA signal is not active and the decompression signal is not active.

[0214] A second aircraft computing system can include in-seat passenger interfaces and a server. The in-seat passenger interfaces can each be integrated with a respective aircraft seat in an aircraft. Each in-seat passenger interface can include a respective DAL D software module classifiable as Design Assurance Level (DAL Level) D according to DO-178C and a respective DAL E software module classifiable as DAL Level E by DO-178C. The respective DAL D software module and the respective DAL E software module can be isolated from one another. The server within the aircraft can be configured to communicate with the in-seat passenger interfaces. The server can include a server DAL D software module classifiable as DAL Level D according to DO-178C and a server DAL E software module classifiable as DAL Level E by DO-178C. The server DAL D software module and the server DAL E software module can be isolated from one another.

[0215] In combination with any of the aforementioned features of the second example aircraft computing system, the server can further include a PA signal input, a decompression signal input, a server processor, and a server memory. The PA signal input configured to receive a PA signal. The decompression signal input can be configured to receive a decompression signal. The server processor. The server memory can be in communication with the server processor. The server memory can include the server DAL D software module and the server DAL E software module thereon. The server DAL D software module can include instructions that when executed by the server processor cause the server to initiate a safety event message broadcast based at least in part on the PA signal and/or the decompression signal. One or both of the PA signal and the decompression signal can be binary. [0216] In combination with any of the aforementioned features of the second example aircraft computing system, the server can further include a digitizer configured to filter signal noise from the PA signal and the decompression signal.

[0217] In combination with any of the aforementioned features of the second example aircraft computing system, the safety event message can be configured to communicate: a decompression broadcast when the decompression signal is active; a PA broadcast when the PA signal is active and the decompression signal is not active; and a normal operation broadcast when the PA signal is not active and the decompression signal is not active.

[0218] In combination with any of the aforementioned features of the second example aircraft computing system, each of the in-seat passenger interfaces can include a respective receiver, a respective interface processor, and a respective interface memory. The respective receiver can be configured to receive the safety event message. The respective interface memory can be in communication with the respective interface processor. The respective interface memory can include the respective DAL D software module and the respective DAL E software module thereon. The respective DAL D software module can include instructions that when executed by the respective interface processor cause the respective in-seat passenger interface to transmit an intent message to the DAL E software module. The intent message can be based at least in part on the safety event message.

[0219] In combination with any of the aforementioned features of the second example aircraft computing system, the safety event message can be configured to communicate a decompression broadcast when the decompression signal is active, a PA broadcast when the PA signal is active and the decompression signal is not active, and a normal operation broadcast when the PA signal is not active and the decompression signal is not active. The intent message can be configured to communicate a mute command upon the respective receiver receiving the PA broadcast and a disable command upon the respective receiver receiving the decompression broadcast.

[0220] In combination with any of the aforementioned features of the second example aircraft computing system, the respective DAL E software module can include instructions that when executed by the respective interface processor mutes audio outputs of the respective in-seat device upon receiving the mute command and disables inputs of the respective in-seat device upon receiving the disable command. The intent message can be configured to communicate a reboot command following elapse of a predetermined time period following last receipt of the respective receiver receiving the decompression broadcast.

[0221] An example IFE system can include a server within an aircraft. The server can include a processor and non-transitory computer readable medium with instructions thereon that when executed by the processor cause the server to perform some or all of the following steps presented in no particular order. When executed by the processor, the instructions can cause the IFE system to wirelessly broadcast a first signal to a plurality of in-seat devices within the aircraft to cause the plurality of in-seat devices to simultaneously display a video and broadcast a second signal to a public speaker system within the aircraft to cause the public speaker system to generate audio such that the audio and the video are synchronized. The first signal and the second signal can each include a synchronize starting time for initiating respective playback.

[0222] A ninth example method can include some or all of the following steps presented in no particular order. Some or all of the steps of the ninth example method can be executed by an in- aircraft server.

[0223] The ninth example method can include wirelessly broadcasting a first signal with instructions to cause a plurality of in-seat devices to simultaneously display a video and wirelessly broadcasting a second signal with instructions to cause a public speaker system to generate audio synchronized with the video. The first signal and the second signal can each include a synchronize starting time for initiating respective playback.

[0224] It is to be understood that the embodiments and claims disclosed herein are not limited in their application to the details of construction and arrangement of the components set forth in the description and illustrated in the drawings. Rather, the description and the drawings provide examples of the embodiments envisioned. The embodiments and claims disclosed herein are further capable of other embodiments and of being practiced and carried out in various ways. Also, it is to be understood that the phraseology and terminology employed herein are for the purposes of description and should not be regarded as limiting the claims.

[0225] Accordingly, those skilled in the art will appreciate that the conception upon which the application and claims are based may be readily utilized as a basis for the design of other structures, methods, and systems for carrying out the several purposes of the embodiments and claims presented in this application. It is important, therefore, that the claims be regarded as including such equivalent constructions.

[0226] Furthermore, the purpose of the foregoing Abstract is to enable the United States Patent and Trademark Office and the public generally, and especially including the practitioners in the art who are not familiar with patent and legal terms or phraseology, to determine quickly from a cursory inspection the nature and essence of the technical disclosure of the application. The Abstract is neither intended to define the claims of the application, nor is it intended to be limiting to the scope of the claims in any way. Instead, it is intended that the disclosed technology is defined by the claims appended hereto.

Claims

Claims:

1. A method, comprising:

determining, by an in-aircraft computing device on an aircraft, that an in-flight entertainment device on the aircraft does not have a locally stored copy of an item of entertainment content;

identifying, by the in-aircraft computing device, a flight mode of the aircraft; and causing, by the in-aircraft computing device, the item of entertainment content to be downloaded for local storage at the in-flight entertainment device, wherein a manner of downloading the item of entertainment content is based at least in part on the identified flight mode.

2 The method of claim 1, wherein the flight mode comprises one of open or closed.

3. The method of claim 1, wherein the manner of downloading the item comprises engaging in a save while streaming mode if the identified flight mode is open.

4. The method of claim 1, wherein the manner of downloading the item comprises a multicast transmission if the identified flight mode is closed.

5. A method, comprising:

wirelessly transmitting, by a server on an aircraft, in-flight entertainment system data to a plurality of in-seat passenger interfaces in the aircraft;

determining, by the server, a flight mode of the aircraft; and

initiating or ceasing, by the server, delivery of the in-flight entertainment system data from the server to at least a portion of the in-seat passenger interfaces based at least in part on the determined flight mode.

6. The method of claim 5, wherein the in-flight entertainment system data comprises one or more of a firmware update, a software update, and/or entertainment content.

7. The method of claim 5, further comprising:

comparing, by the server, content stored on the server to content cached on each of the wireless in-seat passenger interfaces; and

for each one of the in-seat passenger interfaces

selecting, by the server, respective content from the content stored on the server to cache for the one of the wireless in-seat passenger interfaces, based at least in part on the comparing, and

transmitting, by the server, at least a portion of the respective selected content to the one of the in-seat passenger interfaces.

8. The method of claim 5, further comprising:

comparing, by the server, content stored on the server to content cached on each of the in seat passenger interfaces;

determining, by the in-aircraft server, that content caching for at least a subset of the in seat passenger interfaces is complete, based at least in part on the comparing; and

transmitting, by the in-aircraft server, flight closed operation instructions to the at least a subset of the in-seat passenger interfaces for which content caching is determined to be complete.

9. The method of claim 5, further comprising:

selecting, by the server, data to be delivered wirelessly from the server to the plurality of in-seat passenger interfaces based at least in part on in-flight entertainment system metadata stored on the server.

10. The method of claim 5, wherein the step of wirelessly transmitting comprises wirelessly transmitting, by the server, at least a portion of the in-flight entertainment system data to at least a portion of the in-seat passenger interfaces via a multicast protocol.

11. An in-aircraft server comprising a processor and non-transitory computer readable medium in communication with the processor and comprising instructions thereon that when executed by the processor cause the server to:

determine whether a flight status of an aircraft is open or closed;

when the flight status is determined to be open:

stream entertainment content for exhibition via an in-seat passenger interface of the aircraft, and

instruct the in-seat passenger interface to cache the streaming entertainment content to a memory of the in-seat passenger interface; and

when the flight status is determined to be closed:

determine whether entertainment content accessible to the server is not cached in the memory of the in-seat passenger interface, and

wirelessly transmit the entertainment content to the in-seat passenger interface.

12. The in-aircraft server of claim 11, wherein the non-transitory computer readable medium further comprises instructions thereon that when executed by the processor cause the server to:

when the flight status is closed:

deliver a firmware and/or software update from the in-aircraft server to the memory of the in-seat passenger interface.

13. The in-aircraft server of claiml l, wherein the non-transitory computer readable medium further comprises instructions thereon what when executed by the processor cause the server to multicast entertainment content to the in-seat passenger interface.

14. The in-aircraft server of claim 11, wherein the non-transitory computer readable medium further comprises instructions thereon that when executed by the processor cause the server to:

select the entertainment content to be streamed for exhibition via the in-seat passenger interface based at least in part on metadata stored on the in-aircraft server.

15. A method, comprising:

receiving, at an in-seat computing device of an aircraft, a request to exhibit entertainment content;

determining, at the in-seat computing device, that at least a portion of the entertainment content is not stored in a local storage of the in-seat computing device; and

storing, in the local storage of the in-seat computing device, the at least a portion of the entertainment content upon wirelessly streaming the at least a portion of the entertainment content from an in-aircraft server, in response to determining that the at least a portion of the entertainment content is not stored in the local storage.

16. The method of claim 15, wherein the at least a portion of the entertainment content is stored only if the at least a portion of the entertainment content is identified in a list of items of entertainment content selected for local storage at the in-seat computing device.

17. A method, comprising:

receiving, at a wireless in-seat passenger interface in an aircraft, streaming in-flight entertainment data;

caching at least a portion of the streaming in-flight entertainment data within a memory of the in-seat passenger interface; and

exhibiting entertainment content via the in-seat passenger interface such that the entertainment content is based in part on the streaming in-flight entertainment data and data stored within the memory of the in-seat passenger interface.

18. The method of claim 17, wherein the streaming in-flight entertainment data comprises one or more of a firmware update, a software update, and/or entertainment content.

19. The method of claim 17, wherein the caching step further comprises:

comparing, by the wireless in-seat passenger interface, content present on the in-seat passenger interface to an in-flight entertainment content manifest; and

selecting, by the wireless in-seat passenger interface, the portion of the streaming in-flight entertainment data to cache based at least in part on the comparing.

20. A method, comprising:

monitoring, by an in-aircraft computing device, bandwidth usage by a plurality of in-seat entertainment devices;

determining, by the in-aircraft computing device, that the bandwidth usage is below a predetermined threshold; and

causing, by the in-aircraft computing device, each of one or more of the plurality of in-seat entertainment devices to download and locally store at least one item of entertainment content in response to determining that the bandwidth usage is below the predetermined threshold.

21. The method of claim 20, wherein the at least one item of entertainment content is selected from a list of a plurality of items of entertainment content to be locally stored at the one or more of the plurality of in-seat entertainment devices.

22. The method of claim 21, wherein each respective one of the one or more of the plurality of in-seat entertainment devices selects the at least one item of entertainment content that is downloaded and locally stored at the respective one of the one or more in-seat entertainment devices.

23. The method of claim 20, wherein the causing step comprises the step of selecting each respective one of the one or more of the plurality of in-seat entertainment devices based on at least one of a bandwidth usage of the respective one of the one or more of the plurality of in seat entertainment devices, a wireless access point associated by with the respective one of the one or more of the plurality of in-seat entertainment devices, or a relative priority of the respective one of the one or more of the plurality of in-seat entertainment devices.

24. The method of claim 20, further comprising:

prioritizing, by the in-aircraft computing device, each of the in-seat entertainment devices for content caching in relation to other of the in-seat entertainment devices.

25. A system, comprising:

a server within an aircraft configured to communicate with a plurality of in-seat passenger interfaces and configured to provide a caching service, the caching service configured to:

monitor bandwidth usage of wireless communication between a plurality of in-seat passenger interfaces and the server,

publish a manifest listing content to be transferred from the server to at least a portion of the plurality of in-seat passenger interfaces, and

initiate transmission of content from the server to the portion of the in-seat passenger interfaces based at least in part on the manifest and the bandwidth usage.

26. The system of claim 25, wherein the caching service is further configured to prioritize each of the in-seat passenger interfaces for content caching in relation to other of the in seat passenger interfaces.

27. A method, comprising:

identifying, by an in-aircraft server, a plurality of zones in an aircraft, each zone comprising one or more in-seat computing devices in the aircraft;

associating, by the in-aircraft server, each of the zones with a subset of a plurality of wireless access points (WAPs) in the aircraft, each subset comprising at least one of the plurality of WAPs; and

inhibiting, via a wireless protocol, each respective one of the in-seat computing devices from communicating with any of the plurality of WAPs other than the at least one of the plurality of WAPs in the subset associated with the zone comprising the respective one of the in-seat computing devices.

28. The method of claim 27, further comprising:

inhibiting, via the wireless protocol, at least a portion of the in-seat computing devices from communicating with a WAP on another aircraft.

29. The method of claim 27, wherein the wireless protocol comprises dynamic service set identifier creation.

30. The method of claim 27, further comprising a step of creating the zones based at least in part on seat numbers associated with the in-seat computing devices.

31. The method of claim 27, wherein the inhibiting step comprises the step of causing each respective one of the in-seat computing devices to connect to a particular one of the WAPs only if the particular one of the WAPs has a service set identifier included on an approved list of service set identifiers.

32. The method of claim 27, further comprising the step of changing at least one of the zones or the associations of zones and WAPs to improve overall network performance.

33. The method of claim 27, wherein the associating step further comprises:

associating, by the in-aircraft server, each in-seat computing device to a respective primary

WAP of the plurality of WAPs;

associating, by the in-aircraft server, a first portion of the in-seat computing devices to a first secondary WAP of the plurality of WAPs;

associating, by the in-aircraft server, a second portion of the in-seat computing devices to a second secondary WAP of the plurality of WAPs; and

maintaining, by the in-aircraft server, a predetermined set of one or more rules for transitioning a respective in-seat computing device of the plurality of in-seat computing devices from its respective primary WAP to its secondary WAP.

34. The method of claim 33, further comprising the step of transitioning at least a first in-seat computing device of the plurality of in-seat computing devices based on the predetermined set of one or more rules.

35. The method of claim 33, wherein the predetermined set of one or more rules comprises at least one bandwidth threshold.

36. The method of claim 27, further comprising:

associating, by the in-aircraft server, each of the plurality of in-seat passenger interfaces with a respective seat number of a respective aircraft seat; and

grouping, by the in-aircraft server, each of the plurality of in-seat passenger interfaces into a respective zone of the plurality of zones based at least in part on the respective seat number.

37. The method of claim 27, further comprising:

predetermining at least a portion of the plurality of zones based at least in part on installation locations of the in-seat computing devices within the aircraft.

38. The method of claim 27, further comprising:

associating, by the in-aircraft server, each zone with a respective unique service set identifier of a respective WAP of the plurality of WAPs.

39. The method of claim 38, wherein the unique service set identifiers are hidden.

40. The method of claim 27, further comprising:

distributing, by the in-aircraft server, entertainment media to at least a portion of the in seat passenger interfaces.

41. The method of claim 27, further comprising:

wirelessly communicating between at least a portion of the WAPs and at least a portion of the plurality of in-seat passenger interfaces over a U-NII-2 frequency sub band.

42. The method of claim 41, further comprising:

selecting the portion of in-seat passenger interfaces which communicate over the U-NII-2 sub band based on one or more of: a class of a respective aircraft set in which the respective in- seat passenger interface is integrated, status of audio output of the respective in-seat passenger interface, and a content streaming rate to the respective in-seat passenger interface.

43. The method of claim 27, further comprising:

wirelessly downloading, by the in-aircraft server, software and/or firmware from an off- aircraft storage medium to an onboard storage medium; and

wirelessly distributing, by the in-aircraft server, the software and/or firmware from the onboard storage medium to in-seat passenger interfaces.

44. The method of claim 27, further comprising:

configuring, via the wireless protocol, the plurality of WAPs such that the plurality of WAPs are not configured to communicate with a personal electronic device.

45. An in-flight entertainment (IFE) server in an aircraft, the server comprising a WAP configuration file stored thereon, the WAP configuration file comprising instructions thereon, that when executed by a processor of the server, cause the server to:

associate each of a plurality of in-seat passenger interfaces to a respective primary WAP; associate at least a first portion of the plurality of in-seat passenger interfaces to a first secondary WAP;

associate at least a second portion of the plurality of in-seat passenger interfaces to a second secondary WAP; and

cause a respective in-seat passenger interface of the plurality of in-seat passenger interfaces to transition from its respective primary WAP to its respective secondary WAP based on rules in the WAP configuration file.

46. A method, comprising:

executing, by an in-aircraft server, instructions from a first software module to wirelessly broadcast a safety event message to a plurality of in-seat passenger interfaces; and

executing, by the in-aircraft server, instructions from a second software module to wirelessly transmit entertainment content to at least a portion of the plurality of in-seat passenger interfaces, wherein the first software module and second software module are isolated from one another.

47. The method of claim 46, further comprising:

receiving, by the in-aircraft server, a public announcement (PA) signal,

wherein the step of executing instructions from the first software module to wirelessly broadcast the safety event message is responsive to receiving the PA signal, and

wherein the safety event message is indicative of the PA announcement.

48. The method of claim 46, further comprising:

receiving, by the in-aircraft server, a decompression signal,

wherein the step of executing instructions from the first software module to wirelessly broadcast the safety message is responsive to receiving the decompression signal, and

wherein the safety event message is indicative of aircraft decompression.

49. The method of claim 46, further comprising:

receiving, by the in-aircraft server, a public announcement (PA) signal and a decompression signal substantially simultaneously,

wherein the step of executing instructions from the first software module to wirelessly broadcast the safety event message is responsive to receiving the decompression signal, and

wherein the safety event message is indicative of aircraft decompression.

50. The method of claim 46, further comprising:

executing, by the in-aircraft server, additional instructions from the first software module, to wirelessly broadcast, to the plurality of in-seat passenger interfaces, a normal operation message indicative of a lack of a safety event.

51. The method of claim 46, wherein the first software module is certified as Design Assurance Level (DAL Level) D according to DO-178C, and wherein the second software module is certified as DAL Level E according to DO-178C.

52. The method of claim 46, further comprising:

updating the first software module independent of the second software module.

53. A method, comprising:

executing, by an in-seat passenger interface, instructions from a first software module to wirelessly receive a safety event message and disable audio of the in-seat passenger interface in response to receiving the safety event message; and

executing, by the in-seat passenger interface, instructions from a second software module to wirelessly receive entertainment content and provide an output based on the entertainment content,

wherein the first software module and second software module are isolated from one another.

54. The method of claim 53, further comprising:

executing, by the in-seat passenger interface, first software module instructions to transmit an intent message to the second software module, the intent message being based at least in part on the safety event message.

55. The method of claim 54, wherein the intent message is configured to communicate a mute command if the safety event message is indicative of a public announcement (PA) broadcast and a disable command if the safety event message is indicative of a decompression event.

56. The method of claim 55, further comprising:

executing, by the in-seat passenger interface, additional instructions from the second software module to mute upon receiving the mute command and to disable upon receiving the disable command.

57. The method of claim 55, wherein the intent message is configured to communicate a reboot command following elapse of a predetermined time period following last receipt of the safety event message being indicative of the decompression event.

58. The method of claim 53, wherein the first software module is certified as Design Assurance Level (DAL Level) D according to DO-178C, and wherein the second software module is certified as DAL Level E according to DO-178C.

59. The method of claim 53, further comprising:

updating the first software module independent of the second software module.

60. An aircraft computing system comprising:

an in-flight entertainment (IFE) system comprising a first software module classifiable as Design Assurance Level (DAL Level) D according to DO-178C and a second software module classifiable as DAL Level E by DO-178C,

the first and second software modules being isolated from one another.

61. The aircraft computing system of claim 60, wherein the first software module comprises a conformity check indicative of a change in the first software module.

62. The aircraft computing system of claim 61, wherein the conformity check comprises at least one of a checksum and/or a hash value.

63. The aircraft computing system of claim 60,

wherein the in-flight entertainment system further comprises an in-seat passenger interface comprising memory having the first software module and the second software module stored thereon and a processor in communication with the memory.

64. The aircraft computing system of claim 63,

wherein the first software module comprises instructions thereon that when executed by the processor cause the in-seat passenger interface to continuously monitor for a mute command and disable audio outputs of the in-seat passenger interface in response to receiving the mute command, and

wherein the second software module includes instructions thereon that when executed by the processor cause the in-seat passenger interface to display entertainment content.

65. The aircraft computing system of claim 64, wherein the first software module further comprises instructions thereon that when executed by the processor cause the in-seat passenger interface to unmute audio outputs of the in-seat passenger interface in response to deactivation of the mute command.

66. The aircraft computing system of claim 64, wherein the first software module further comprises instructions thereon that when executed by the processor cause the in-seat passenger interface to interrupt inputs, display, and audio outputs of the in-seat passenger interfaces in response to receiving the mute command.

67. The aircraft computing system of claim 66, wherein the first software module further comprises instructions thereon that when executed by the processor cause the in-seat passenger interface to initiate playback of a Pre-Recorded Audio Message (PRAM) in response to receiving a decompression command.

68. The aircraft computing system of claim 60,

wherein the in-flight entertainment system further comprises an in-aircraft server comprising memory having the first software module and the second software module stored thereon and a processor in communication with the memory,

wherein the first software module comprises instructions thereon that when executed by the processor cause the in-aircraft server to provide wireless communications to a plurality of in seat passenger interfaces via a multicast protocol; and

wherein the second software module comprises instructions thereon that when executed by the processor cause the in-aircraft server to provide wireless communications to the plurality of in-seat passenger interfaces via a unicast protocol.

69. The aircraft computing system of claim 68, wherein the in-aircraft server further comprises a seat state software module stored on the memory that when executed by the processor causes the server to change a state of each of the plurality of in-seat passenger interfaces from a flight closed state to a flight open state.

70. The aircraft computing system of claim 68, wherein the server further comprises: a public announcement signal input configured to receive a public announcement (PA) signal; and

a decompression signal input configured to receive a decompression signal,

wherein the first software module comprises instructions that when executed by the server processor causes the server to initiate a safety event message broadcast based at least in part on the PA signal and/or the decompression signal.

71. The aircraft computing system of claim 70, wherein the PA signal is binary and the decompression signal is binary.

72. The aircraft computing system of claim 70, wherein the server further comprises: a digitizer configured to filter signal noise from the PA signal and the decompression signal.

73. The aircraft computing system of claim 70, wherein the safety event message is configured to communicate: a decompression broadcast when the decompression signal is active; a PA broadcast when the PA signal is active and the decompression signal is not active; and a normal operation broadcast when the PA signal is not active and the decompression signal is not active.

74. An aircraft computing system comprising:

a plurality of in-seat passenger interfaces each integrated with a respective aircraft seat in an aircraft and each comprising a respective DAL D software module classifiable as Design Assurance Level (DAL Level) D according to DO-178C and a respective DAL E software module classifiable as DAL Level E by DO-178C, the respective DAL D software module and the respective DAL E software module being isolated from one another; and

a server within the aircraft configured to communicate with the plurality of in-seat passenger interfaces and comprising a server DAL D software module classifiable as DAL Level D according to DO-178C and a server DAL E software module classifiable as DAL Level E by DO-178C, the server DAL D software module and the server DAL E software module being isolated from one another.

75. The aircraft computing system of claim 74, wherein the server further comprises: a public announcement signal input configured to receive a public announcement (PA) signal;

a decompression signal input configured to receive a decompression signal;

a server processor; and

server memory in communication with the server processor and comprising the server DAL D software module and the server DAL E software module thereon,

wherein the server DAL D software module comprises instructions that when executed by the server processor cause the server to initiate a safety event message broadcast based at least in part on the PA signal and/or the decompression signal.

76. The aircraft computing system of claim 75, wherein the PA signal is binary and the decompression signal is binary.

77. The aircraft computing system of claim 75, wherein the server further comprises: a digitizer configured to filter signal noise from the PA signal and the decompression signal.

78. The aircraft computing system of claim 75, wherein the safety event message is configured to communicate: a decompression broadcast when the decompression signal is active; a PA broadcast when the PA signal is active and the decompression signal is not active; and a normal operation broadcast when the PA signal is not active and the decompression signal is not active.

79. The aircraft computing system of claim 75, wherein each of the plurality of in-seat passenger interfaces comprises:

a respective receiver configured to receive the safety event message;

a respective interface processor; and

respective interface memory in communication with the respective interface processor and comprising the respective DAL D software module and the respective DAL E software module thereon,

wherein the respective DAL D software module comprises instructions that when executed by the respective interface processor causes the respective in-seat passenger interface to transmit an intent message to the DAL E software module, the intent message based at least in part on the safety event message.

80. The aircraft computing system of claim 79,

wherein the safety event message is configured to communicate a decompression broadcast when the decompression signal is active, a PA broadcast when the PA signal is active and the decompression signal is not active, and a normal operation broadcast when the PA signal is not active and the decompression signal is not active, and

wherein the intent message is configured to communicate a mute command upon the respective receiver receiving the PA broadcast and a disable command upon the respective receiver receiving the decompression broadcast.

81. The aircraft computing system of claim 80,

wherein the respective DAL E software module comprises instructions that when executed by the respective interface processor mutes audio outputs of the respective in-seat device upon receiving the mute command and disables inputs of the respective in-seat device upon receiving the disable command.

82. The aircraft computing system of claim 80, wherein the intent message is configured to communicate a reboot command following elapse of a predetermined time period following last receipt of the respective receiver receiving the decompression broadcast.

83. An in-flight entertainment (IFE) system comprising:

a server within an aircraft comprising a processor and non-transitory computer readable medium with instructions thereon that when executed by the processor cause the server to:

wirelessly broadcast a first signal to a plurality of in-seat devices within the aircraft to cause the plurality of in-seat devices to simultaneously display a video; and

broadcast a second signal to a public speaker system within the aircraft to cause the public speaker system to generate audio, wherein the audio and the video are synchronized.

84. The IFE system of claim 83, wherein the first signal and the second signal each comprise a synchronized starting time for initiating respective playback.

85. A method, comprising:

wirelessly broadcasting, from an in-aircraft server, a first signal with instructions to cause a plurality of in-seat devices to simultaneously display a video; and

wirelessly broadcasting, from an in-aircraft server, a second signal with instructions to cause a public speaker system to generate audio synchronized with the video.

86. The method of claim 85, wherein the first signal and the second signal each comprise a synchronized starting time for initiating respective playback.