Seamless delivery of real-time media stream with intermittent signal loss

A real-time media stream, multicast by a remote computing system, is received by an on-board system of a vehicle. While being received, the real-time media stream is packaged into time-delineated media segments that are input to a buffer. One or more missing segments are identified after a signal loss event (e.g., a satellite handoff), and a request for the missing segment(s) is/are caused to be sent to the remote computing system. The missing segment(s) is/are received from the remote computing system via a unicast transmission, and inserted into the buffer in sequence with the time-delineated media segments. The buffered real-time media stream, including the inserted segment(s), is caused to be provided to one or more electronic devices on-board the vehicle. In this manner, the real-time media stream may be seamlessly delivered to the on-board electronic device(s) despite a loss of connectivity due to the signal loss event.

FIELD AND BACKGROUND OF THE DISCLOSURE

Technical Field

The instant disclosure generally relates to delivering real-time media streams (e.g., Internet Protocol television (IPTV), streaming radio, etc.) to electronic devices on-board vehicles, and, in particular, to a system that utilizes multicast communications to provide real-time media streams to devices on-board multiple vehicles and unicast communications to provide missing media segments that were lost due to handoffs or other events.

Background

Currently, some airlines provide a television service to devices that are on-board an aircraft (e.g., seatback monitors, smart phones, tablets and/or laptop computing devices of passengers), while the aircraft is traveling en route to a destination. In some such systems, television service is delivered to multiple aircraft via a multicast satellite uplink of Internet Protocol Television (IPTV), multiplexed alongside other Internet Protocol (IP) data services. During the course of a flight, however, an individual aircraft will likely lose connectivity momentarily due to one or more handoffs between satellite transponders. For example, longer (e.g., international) flights may require one or more handoffs as the aircraft moves between the coverage areas of different satellites. Even for relatively short flights, a number of beam handoffs (or “beam switches”) may be required if the satellite operator implements spot beam technology. Unfortunately, satellite handoffs (including spot beam handoffs for a single satellite) typically involve “break-before-make” connections. For example, 30 to 90 seconds of signal loss is typically expected when handing off from a spot beam of one satellite to a spot beam of another satellite, and roughly 10 seconds of signal loss is typically expected when handing off between spot beams of a single satellite.

While some services may not be greatly impacted by this loss of connectivity (e.g., non-real time IP data services, such as email or web browsing), quality of service and the overall user experience can be significantly impacted when providing IPTV or other real-time content (e.g., other streaming video/audio, or streaming audio only). In these cases, loss of connectivity may cause users to miss some or all of the content that was multicast during that time period (e.g., in a manner similar to unplugging a television or radio in one's home for a period of time while watching or listening to a broadcast program). At a minimum, such an interruption of service is likely to annoy the end user. Moreover, if the end user paid any fees for real-time content (e.g., for general access to broadcast television programming, or to watch a specific program such as a boxing match), the interruption is very likely to result in more customer and/or airline complaints, and/or more requests for refunds.

BRIEF SUMMARY OF THE DISCLOSURE

In an embodiment, a method of seamlessly providing a real-time media stream to one or more electronic devices on-board a vehicle is implemented by an on-board system of the vehicle. The method includes receiving a real-time media stream that is multicast by a remote computing system. The method also includes, while receiving portions of the real-time media stream, packaging the real-time media stream into a plurality of time-delineated media segments, inputting the plurality of time-delineated media segments into a buffer, identifying, after a signal loss event, one or more missing time-delineated media segments, causing a request for the one or more missing time-delineated media segments to be sent to the remote computing system, receiving the one or more missing time-delineated media segments from the remote computing system via a unicast transmission, inserting the one or more missing time-delineated media segments into the buffer in sequence with the plurality of time-delineated media segments, and causing the buffered real-time media stream, including the inserted one or more missing time-delineated media segments, to be provided to the one or more electronic devices on-board the vehicle. The buffer delays the real-time media stream by a buffer time value that is equal to or greater than a duration of N of the time-delineated media segments, where N is an integer greater than or equal to one.

In another embodiment, an on-board system for seamlessly providing real-time media streams to one or more electronic devices on-board a vehicle carrying the on-board system includes one or more processors and one or more non-transitory, tangible computer-readable storage media. The one or more non-transitory, tangible computer-readable storage media store computer-executable instructions that, when executed by the one or more processors, cause the on-board system to receive a real-time media stream that is multicast by a remote computing system and, while receiving portions of the real-time media stream, package the received real-time media stream into a plurality of time-delineated media segments, input the plurality of time-delineated media segments into a buffer, identify, after a signal loss event, one or more missing time-delineated media segments, cause a request for the one or more missing time-delineated media segments to be sent to the remote computing system, receive the one or more missing time-delineated media segments from the remote computing system via a unicast transmission, insert the one or more missing time-delineated media segments into the buffer in sequence with the plurality of time-delineated media segments, and cause the buffered real-time media stream, including the inserted one or more missing time-delineated media segments, to be provided to the one or more electronic devices on-board the vehicle. The buffer delays the real-time media stream by a buffer time value that is equal to or greater than a duration of N of the time-delineated media segments, where N is an integer greater than or equal to one.

In another embodiment, a method of seamlessly providing a real-time media stream at least to one or more electronic devices on-board a first vehicle of a plurality of vehicles is implemented by a computing system located remotely from the plurality of vehicles. The method includes encoding a real-time media stream, at least in part by generating metadata indicating boundaries between segments of the real-time media stream. The method also includes, while encoding portions of the real-time media stream, packaging a first copy of the encoded real-time media stream into a plurality of time-delineated media segments, caching a sliding window of N segments of the plurality of time-delineated media segments, causing a second copy of the encoded real-time media stream to be transmitted to the plurality of vehicles via a multicast transmission, receiving, from the first vehicle and after a signal loss event, a request for one or more missing time-delineated media segments, retrieving the one or more missing time-delineated media segments from among the cached N segments, and causing the retrieved one or more missing time-delineated media segments to be transmitted to the first vehicle via a unicast transmission. Packaging the first copy of the encoded real-time media stream into the plurality of time-delineated media segments includes segmenting the real-time media stream according to the boundaries indicated by the metadata. N is an integer greater than or equal to one.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1is a block diagram depicting an exemplary content provision system100for seamlessly delivering real-time media streams to electronic devices that are on-board (e.g., being transported by) a number of vehicles102. As described in further detail below, the system100includes a data center104that is generally configured to multicast real-time media streams to the vehicles102, and to unicast missing segments of the media streams to specific ones of the vehicles102that experience signal loss events. As used herein, the terms “signal loss” and “connectivity loss” may be used interchangeably, and may, in some implementations and/or scenarios, refer to a degradation of the signal rather than a complete loss of signal (e.g., if the signal passes below a threshold signal-to-noise or signal-to-interference-plus-noise ratio for at least some threshold amount of time, and/or if some other quality of service metric is not achieved). In a preferred embodiment, however, “signal loss” or “connectivity loss” refers to a complete loss of signal, such as the loss of signal that occurs during a satellite or satellite spot beam handoff.

Each of the vehicles102is equipped with an on-board system106(e.g., as depicted within vehicle102xinFIG. 1) that is generally configured to buffer a multicast, real-time media stream, package it into time delineated media segments on boundaries identified by metadata present in the real-time stream, identify any media segments that are missing from the media stream (e.g., segments that were not properly received), request the missing media segments (if any) from the data center104, receive the requested media segments via a unicast transmission from the data center104, and insert the missing media segments into the media stream at the appropriate buffer locations. In this manner, the real-time media stream may be reconstructed and provided to entertainment devices108transported by the vehicles102(e.g., as depicted within the vehicle102xinFIG. 1) in a seamless manner, e.g., such that end users are unaware of any gap in connectivity during the received multicast.

One or more of the vehicles102may be owned and/or operated by a specific individual. In some cases, one or more of the vehicles102may be owned and/or operated by a company, organization or government entity. For example, the vehicles102may include a fleet of vehicles that are used to transport passengers who pay for or otherwise are granted passage on one of the vehicles of the fleet. The vehicles102may include one or more vehicles that are used by an organization to transport employees and their guests, in some situations. One or more of the vehicles102may be used to transport live or inanimate cargo, packages, mail, and/or other types of cargo. It is noted that althoughFIG. 1depicts the vehicles102as being airplanes, the techniques and principles described herein equally apply to other types of vehicles such as trucks, automobiles, busses, trains, boats, ships, barges, subway cars, helicopters or other types of aircraft, ambulances or other emergency vehicles, military vehicles, other air-borne, water-borne, or land-borne vehicles, and vehicles that are suitable for space travel.

The entertainment devices108may be devices that are temporarily being transported by the vehicles102(e.g., seatback monitors, smart phones, tablets, laptops and/or other mobile computing devices) and are part of or belong to passengers and/or crew on-board the vehicles102. In an embodiment, each of the entertainment devices108is a computing device including at least one memory, at least one processor, at least one user interface, and at least one wired and/or wireless network interface. In some implementations, the real-time media streams are instead, or additionally, provided to other devices carried by the vehicles102, such as components of integrated subsystems that each include a large display screen to be simultaneously viewed by multiple passengers.

Each real-time media stream may include video (e.g., one or more IPTV programs, including audio), or audio only (e.g., a live podcast or radio show), for example. As used herein, “real-time” content/media encompasses “near-real-time” content/media, i.e., where some perceivable amount of intentional time delay (e.g., 30 seconds, or 90 seconds, etc., due to buffering) and/or other time delay (e.g., a much smaller delay due to processing and over-the-air propagation time) is introduced between the time of transmission and the time of presentation to end users.

The data center104may be located at least partially in a terrestrial environment, e.g., in one or more stationary buildings or structures. For example, one or more portions of the data center104may be included in a ground distribution network. In an embodiment, at least a portion of the data center104may be located in a non-terrestrial environment, e.g., on a satellite or space station. In an embodiment, the data center104may include multiple data centers for servicing different sources of content, different customers, different geographical areas, and/or any other desired or suitable differentiations.

The data center104may be communicatively connected via a gateway110to another network112. Generally, the gateway110may include one or more computing devices in communicative connection, and may serve as a boundary between the rest of the content provision system100and the other network112. In some embodiments, at least a portion of the gateway110may be included in the data center104. The other network112in communicative connection with the gateway110may include, for example, the Internet, a PSTN (Public Switched Telephone Network), and/or one or more other public networks. Additionally or alternatively, the other network112may include one or more Wide Area Networks (WAN). The network112may include any number of wired and/or wireless networks, such as TV Receive Only (TVRO) sitcom networks (e.g., Ku-band, C-band). AlthoughFIG. 1illustrates the data center104as being connected to one other network112via one gateway110, the techniques and principles described herein equally apply to content provision systems100having and/or being in communicative connection with any desired number of other networks112via any number of gateways110. In some embodiments of the content provision system100, the gateway110is omitted.

In one implementation, the other network112provides to the data center104(e.g., via the gateway110, or via another route) data representing a real-time media stream that is ultimately to be delivered to some or all of the entertainment devices108on-board some or all of the vehicles102. In one implementation, the other network112is communicatively connected to a server of a streaming media provider (e.g., an IPTV provider), not shown inFIG. 1, that provides the real-time media stream to the data center104. While other protocols may be used, in some implementations, the real-time media stream may be sent/pushed to the data center104using UDP (User Datagram Protocol) in order to prioritize timely delivery over reliability.

The data center104includes a live encoder114, a delay unit116and a ground packager120. In some implementations, the live encoder114, delay unit116and/or ground packager120are located remotely from each other (e.g., if data center104includes multiple data centers or components distributed across a large geographic area). Alternatively, the live encoder114, delay unit116and ground packager120may all be co-located, and/or included within a single server or other computing device.

Generally, the live encoder114encodes the real-time media stream (received from the other network112) as the data of the media stream is received. The encoding process may generate metadata that indicates how the media stream should be segmented by downstream packagers. In one implementation, for example, the live encoder114embeds markers within the real-time media stream (e.g., within the UDP stream). The markers, embedded at specific time offsets, may indicate desired boundaries between consecutive media “segments,” and specify unique identifiers for each segment (e.g., “0001,” “0002,” etc., or some other suitable labeling scheme), for example. In a preferred implementation, the markers inserted by the live encoder114in the UDP (or other protocol) media stream are modified versions of the data structure defined by the CableLabs® Encoder Boundary Point (EBP) specification. Currently, the EBP specification describes a data structure that may be inserted in a stream at points where boundaries are desired, and defines a number of general-purpose extension fields. In this preferred implementation, the content and duration of each segment are defined by the placement of the EBP data structures/markers, and at least one extension field of each of the EBP data structures/markers specifies the unique identifier for the respective segment. In other implementations, different suitable techniques (e.g., non-EBP approaches) may be used to indicate boundaries, indicate durations, and/or specify unique segment identifiers.

The live encoder114may output the marked, real-time media stream using the same general protocol or format in which the stream was received from the other network112(e.g., UDP). The data center104may direct the encoded real-time media stream output by the live encoder114along two paths. A first path from the live encoder114is directed to the ground packager120, which generates time-delineated media segments based on the segmentation markers (and/or other metadata) added by the live encoder114. In particular, in one implementation, the ground packager120generates media segments aligning (content-wise) with the embedded boundary markers, and names the media segments based on the unique segment identifiers present in the markers. The ground packager120may package the real-time media stream into segments according to any protocol suitable for delivery to the entertainment devices108via a delivery mechanism available on the vehicles102(e.g., WiFi delivery, as discussed further below in connection withFIG. 2). For example, the ground packager120may package the real-time media into segments using MPEG's Dynamic Streaming over HTTP (DASH) protocol, Adobe's HTTP Dynamic Streaming (HDS) protocol, or Apple's HTTP Live Streaming protocol.

The ground packager120may store the packaged media segments in a cache122, which maintains a sliding window of N packaged segments (N being an integer greater than zero). The data center104may delete old media segments as needed based on the maximum buffer size. The maximum buffer size and the value of N may be configured to be exceed the maximum duration of signal loss that is anticipated for some or all of vehicles102receiving the multicast stream, as discussed further below.

A second path from the live encoder114is directed to the delay unit116, which contains a buffer that delays the real-time media stream by a predetermined amount of time. The delay unit116may be configured to delay the encoded media stream by an amount of time that is equal to or greater than the duration of one media segment, or by another suitable length of time. The delay may be set to a level that ensures segments will be present in the cache122of the ground packager120before those same segments could possibly be needed by any of the vehicles102. In the example system100, the data center104multicasts the encoded and delayed real-time media stream to the vehicles102via a vehicle delivery network124, a number of teleporters126, and a number of satellites130.

The vehicle data delivery network124may include one or more packet network routers, optical switches, and/or other network elements, and may be at least partially disposed in a terrestrial location (e.g., within a climate-controlled structure). In an embodiment, at least a portion of the vehicle data delivery network124may be disposed in a non-terrestrial location (e.g., a routing node disposed on a satellite). The vehicle data delivery network124may include a public network, a private network, or some combination of one or more public networks and one or more private networks. The vehicle data delivery network124may include a communications network, a data network, a packet network, or some combination thereof. Moreover, the vehicle data delivery network124may include a hosted network, and/or a peer-to-peer or other type of ad-hoc network. Generally, the vehicle data delivery network124may use any known networking technology or combination(s) thereof for delivering data. For example, the vehicle data delivery network124may use any known networking technology or combination(s) thereof for delivering data between the teleporters126and the data center104. Generally, the vehicle data delivery network124may include a plurality of computing devices that are communicatively connected.

Each of the vehicles102may be communicatively connected to the data center104via one of a number of satellite links132, and one of a number of communication paths134, at any given time (e.g., other than during periods of connectivity loss, such as during satellite handoff). The satellite links132may be collectively supported by one or more radio frequency (RF) bands. For example, the satellite links132may make use of the L band (e.g., 40 to 60 GHz or 1 to 2 GHz), the Kuband (e.g., 12-18 GHz), the Kaband (e.g., 26.5-40 GHz), and/or other spectrum that is allocated for satellite communications. Generally, each frequency band may include one or more channels. The channels may be formed, defined or allocated by frequency division, time division, code division, some other suitable channel division, or some combination of divisions. Signals that are carried on a channel may or may not be multiplexed. Any one or more channels included in a frequency band may support (or may be designated to support) a forward link and/or a reverse link for wireless communications. Additionally, any one or more of the channels included in a frequency band may be used to deliver signaling, data payload, or a combination of signaling and data payload. For example, a particular frequency band may support an in-band protocol in which signaling and payload are transmitted over a same channel within the band, and/or the particular frequency band may support an out-of-band protocol in which the signaling and payload are respectively transmitted over different channels within the band.

As described further below in connection withFIG. 2, each of the vehicles102may include a satellite transceiver or modem and one or antennas to enable communications via one of satellite links132. Similarly, a satellite transceiver or modem that is fixedly connected to one of the teleporters126may serve as the other end of the satellite link132over which data is received onto and/or sent from the vehicles102. The teleporters126that support the non-vehicle end of the satellite links132may include or be mounted on, for example, entirely stationary terrestrial structures such as buildings or towers on the ground, or relatively stationary terrestrial structures such as barges in an ocean. In some instances, a single one of the teleporters126may include multiple transceivers or modems, each of which may be tuned to a different frequency band.

In addition to having a satellite transceiver or modem supporting one end of a particular satellite link132to one of the vehicles102, each of the teleporters126may include another interface for communicatively connecting to the data center104via one of the communication paths134. The interface to the communication path134may include a wired or a wireless communications interface.

The delayed and multicast real-time media stream is received by the on-board node106of each of the vehicles102. The manner in which each on-board node106may receive the delayed, multicast media stream is discussed further below in connection withFIG. 2. Each on-board node106includes a packager136, a buffer140and a segment retrieval and insertion unit142. As the delayed media stream is received by a respective on-board node106, the packager136generates time-delineated media segments based on the segmentation markers (and/or other metadata) inserted by the live encoder114. In particular, in one implementation, the packager136generates media segments aligning with the embedded boundary markers, and names the media segments based on the unique segment identifiers specified in the markers. The packager136packages the received real-time media stream (e.g., the UDP stream) into segments according to the same protocol used by the ground packager120(e.g., DASH, HDS, HTTP Live Streaming protocol, etc.).

As the packaged media stream is generated, the on-board node106stores the packaged media segments in the buffer140. The packager136may operate similarly or identically to ground packager120, for example, such that the packaged media segments stored in the buffer140precisely match the packaged media segments stored in the cache122of ground packager120, but in a delayed manner due to the delay unit116and any differences in transmission/processing times.

Each on-board node106may provide the buffered segments of the received media stream to one of more entertainment devices108of the respective vehicle102, at which point the entertainment devices108may consume the segments (i.e., present the real-time video and/or other media to users of the entertainment devices108). The delay of the buffer140may be at least as long as the maximum duration of signal loss that is anticipated for some or all of vehicles102receiving the multicast stream, as discussed further below. In one implementation, the size/delay of the buffer140is designed to be equal to the size/delay of the buffer in the cache122in ground packager120.

As indicated above, certain signal loss events may be somewhat predictable, and may have somewhat predictable durations and/or frequencies of occurrence. For example, it is well known that a handoff between two spot beams of a single satellite is a “break-then-make” process that causes up to about 10 seconds of connectivity loss for an aircraft. Similarly, it is well known that a handoff between two satellites is a “break-then-make” process that causes about 30 to 90 seconds of connectivity loss for an aircraft. Thus, assuming that relatively long inter-satellite handoffs are expected (or, at least, are accounted for as a worst case scenario), both the buffer140and the cache122may buffer at least 90 seconds of packaged media segments (e.g., at least nine segments if each segment is 10 seconds long, etc.). In other implementations, the buffer lengths may be longer or shorter (e.g., 30 seconds, 120 seconds, etc.).

When a handoff or other signal loss event occurs for a particular one of the vehicles102, that vehicle102will fail to correctly receive the portion of the multicast stream, multicast by the data center104, which comprises one or more media segments. Thus, the packager136of that vehicle102will not be able to produce the corresponding packaged media segments for storage in the buffer140. Meanwhile, the ground packager120will (typically) not be subject to any connectivity problems, and therefore will continue to produce packaged media segments for storage in the cache122. When the handoff or other signal loss event is complete, the vehicle102resumes receiving the multicast media stream, and the packager136resumes packaging the stream into time-delineated media segments. However, any media segments corresponding to the portion of the media stream that was multicast during the signal loss event will be missing from the buffer140.

To remedy this, the segment retrieval and insertion unit142of the vehicle102experiencing the signal loss event identifies which media segments are missing/needed, requests those signals from the ground packager120, and inserts the missing media segments into the buffer140(in proper order) after receiving the segments from the data center104via a unicast transmission. To first identify which media segments are missing, the segment retrieval and insertion unit142may analyze the unique segment identifiers within the UDP (or other protocol) media stream (received from the live encoder114via the delay unit116) as the media stream is received. If the segment identifiers are arranged as sequential numbers (e.g., “0001” for the first segment, “0002” for the second segment, etc.), for instance, the segment retrieval and insertion unit142may identify missing media segments by continually comparing identifiers in successive markers (i.e., the identifiers specified by the i-th and (i+1)-th markers in the received stream) and flagging missing media segments whenever the difference is greater than one. In such a scenario, the segment retrieval and insertion unit142may identify the first missing media segment as being the media segment having an identifier that is one greater than the identifier of the segment corresponding to the i-th marker, and the last missing media segment (of a contiguous block of segments) as being the media segment having an identifier that is one less than the identifier of the segment corresponding to the (i+1)-th marker. If successive markers in the received media stream include segment identifiers of “0052” and “0058,” for example, the segment retrieval and insertion unit142may identify media segments “0053” through “0057” as the missing segments for that particular signal loss event. In other implementations, different suitable techniques are used. For example, in a less preferred embodiment, the on-board node106may include a timer, and may calculate the number of missing media segments based on the amount of time in which no signal is received, the locations of embedded boundary markers in the media stream, and the known duration of each media segment.

After the missing segment(s) is/are identified, the segment retrieval and insertion unit142may utilize the newly restored satellite connectivity to request the missing media segment(s) from the ground packager120, which will by that time have stored (in the cache122) a number of recent media segments each packaged according to the appropriate protocol, as described above. The request may include the unique identifier for each media segment being requested (or, alternatively, the unique identifier for only the first missing media segment, along with a total count of the number of consecutive media segments that are needed, etc.). The request may be sent to the ground packager120via one of the satellite links132and one of the communication paths134, for example. In response, the ground packager120may deliver the identified media segment(s) to the on-board node106via a unicast transmission specifically targeted/addressed to the vehicle102that sent the request (e.g., using a communication path134and satellite link132, but in the reverse direction). Note that this unicast transmission, unlike the original real-time multicast transmission, is not bound to the data rate of the original multicast transmission. The unicast transmission may be transmitted to the vehicle102at any data rate equal to or greater than the data rate of the multicast transmission. The segment retrieval and insertion unit142may fetch the missing media segment(s) from the ground packager120using a unicast HTTP interface provided by a computing device of the ground packager120, or another computing device of the data center104, for example.

Upon receiving the missing media segment(s) that was/were previously packaged by the ground packager120, the segment retrieval and insertion unit130inserts the media segment(s) into the buffer140in the proper order (e.g., sequentially according to segment name). The media segments are then presented to the end users of the entertainment devices108(of the vehicle102that experienced the signal loss event) in the buffered order. The entertainment devices108may fetch new media segments as needed to provide a continuous display or other presentation to the respective users, for example. Provided that the handoff or other signal loss event does not last longer than the time it takes for a media segment to pass through the buffer140, plus the time needed for requesting, receiving and inserting any missing media segments, the entertainment devices108should be able to continuously read from the buffer140and present the real-time media stream to the end users in a seamless manner.

It is understood that other alternatives, beyond those described above and/or shown inFIG. 1, are also possible. As noted above, for example, the vehicles102may be vehicles other than airplanes. Moreover, the links132may be other types of links (i.e., non-satellite links) that are subject to intermittent signal loss events, and/or the unicast of missing media segments may be requested and/or made via another type of link (e.g., via an air-to-ground (ATG) link).

FIG. 2illustrates an example on-board system200of a vehicle202, according to one implementation. The on-board system200may generally cause real-time media streams to be provided, in a seamless manner, to one or more entertainment devices204being transported by the vehicle202. In an embodiment, the vehicle202is the vehicle102xofFIG. 1, and the entertainment devices204are the entertainment devices108depicted within the vehicle102x.

The example on-board system200includes an on-board node206, such as an Airborne Control Processor Unit (ACPU) or other computing device(s). The on-board node206is communicatively connected to one or more external communication links via one or more antennas208and one or more modems or transceivers210. In an embodiment, the on-board node206may be the on-board node106ofFIG. 1, and may include an instance of the packager136, the buffer140and the segment retrieval and insertion unit142(represented inFIG. 2by the blocks212,214and216, respectively).

Each of the antennas208may receive and transmit signals via a frequency band allocated for satellite communications, e.g., the Kaband, the L band, the Kuband, and/or any other suitable frequency band(s). Each of the antennas208may be communicatively connected to an associated one of the modems or transceivers210. The modems or transceivers210may be fixedly connected to the vehicle202and configured to encode and decode information and data corresponding to signals at the respective antenna208, in one implementation.

The entertainment devices204may be capable of establishing wireless communicative connections with the on-board node206via one or more wireless access points220, e.g., via wireless network interfaces (e.g., WiFi interfaces) of the entertainment devices204. In an embodiment, each of the entertainment devices204may include an instance of a vehicle travel application (VTA) installed thereon and particularly configured to support services while the entertainment device204is being transported by the vehicle202, e.g., when the vehicle202is traveling en route between ports. For example, the vehicle travel application may be configured to serve as the on-board end of a data tunnel that is established with the data center104. In an embodiment, the vehicle travel application may communicate with other applications installed on a particular entertainment device204(e.g., native terrestrial applications) so that the other applications may operate as desired (e.g., in a native manner) while the entertainment device204is being transported by the vehicle202.

FIG. 3illustrates an exemplary time sequence250depicting the manner in which a real-time media stream is seamlessly provided to one or more electronic devices on-board a vehicle despite being interrupted by a handoff, according to one implementation. The time sequence250may correspond to events taking place within the content provision system100ofFIG. 1, and are described below with reference to the elements ofFIG. 1.

Horizontally across the top ofFIG. 3, a timeline252shows the number of seconds elapsed starting from a time T. InFIG. 3, in order to better illustrate the delays between various operations, T represents the time when the real-time media first starts streaming. The rows in the time sequence250represent the timing with which media segments are transmitted, received, input or output at a particular element of the content provision system100(i.e., depending on the context, as indicated by the text by each row). InFIG. 3, “Sx” refers to the portion of the real-time media stream corresponding to the x-th media segment (e.g., a UDP stream encoded by the live encoder114, before packaging by either the packager136or the ground packager120), and “PSx” refers to the x-th packaged media segment (e.g., after packaging by the packager136or the ground packager120using DASH or another suitable protocol). It is to be understood thatFIG. 3is somewhat simplified in order to facilitate understanding of the concepts being described, and therefore does not show, for example, offsets due to differences in processing or transmission times. Moreover, whileFIG. 3depicts media segments that are 30 seconds long for ease of illustration, the media segments are preferably shorter (e.g., 10 seconds, or 8 seconds, 5 seconds, etc.).

As seen inFIG. 3, rows254,256and258correspond to operations at the data center104(e.g., at one or more ground stations), whereas rows260,262and264correspond to operations on-board one of the vehicles102(e.g., on-board an airplane). At the data center104, row254represents the packaged media segments that are input to the cache122of the ground packager120, row256represents the media stream that is multicast by the data center104(after encoding by the live encoder114and buffering by the delay unit116), and row258represents the packaged media segments that are unicast by the data center104after being retrieved from the cache122. At the vehicle102, row260represents the multicast media stream that is received by the on-board node106, row262represents the packaged media segments that are input to the buffer140, and row264represents the packaged media segments that are retrieved/output from the buffer140for consumption by the entertainment devices108.

As seen in row254, the cache122at the ground packager120begins buffering packaged media segments at time T. As seen in rows256and260, in this particular embodiment, the real-time media stream from the live encoder114is multicast after a delay of 30 seconds (i.e., after the delay unit116delays the media stream by the duration of a single segment), and received by the on-board node106via one of the satellite links132. As seen in row262, the multicast media stream is packaged and input to the buffer140as the corresponding portions of the media stream are received. As seen in row264, packaged segments are output from the buffer140after the buffer140has introduced a further delay of 90 seconds (i.e., the duration of three segments). Thus, the buffer140is designed to accommodate signal outages of up to 90 seconds, in this particular implementation. The cache122may also store a sliding window of three segments, in this implementation.

At a time between approximately T+80 and T+110 seconds, a handoff270occurs, causing a loss of connectivity between the data center104and the on-board node106. The handoff270may be a handoff between two of the satellites130, for example. In other implementations and/or scenarios, the handoff270may be a different type of signal loss event (e.g., an intermittent, strong interferer that causes a quality of service metric to fall below a threshold value, etc.). Due to the handoff270, the media stream portions S2and S3are not received by the on-board node106, and therefore the corresponding segments PS2and PS3are not generated by the packager136or input to the buffer140(as seen in rows260and262). While shown as being “missing” in their entireties, the media stream portions S2and S3may be partially received (e.g., before and/or after the handoff270). In some implementations, however, any portion of the media stream that corresponds to a fractional segment is discarded if the portion corresponding to the remainder of that segment is not properly received.

Once connectivity is restored, the segment retrieval and insertion unit142identifies segments PS2and PS3as the missing segments (e.g., by comparing the unique identifiers of the successive, fully-received media stream portions S1and S4), and requests those missing segments from the data center104in an operation not shown inFIG. 3. In response, the data center104retrieves the packaged segments PS2and PS3from the cache122of the ground packager120, and delivers PS2and PS3to the vehicle102via a unicast transmission as shown in row258. As seen inFIG. 3, the missing segments may, in some implementations, be unicast more quickly (i.e., at a higher data rate) than the multicast transmission would provide the corresponding portions of the real-time media stream. Upon receiving the packaged segments PS2and PS3, the segment retrieval and insertion unit142inserts those segments into the buffer140, in the proper sequence (e.g., as determined based on the segment names for PS2and PS3) and prior to outputting those segments to the entertainment devices108as seen in row264. Because the buffer output264has no missing segments, the presentation to each of the entertainment devices108may be seamless, with the end user being unaware that the handoff270or any loss of connectivity occurred.

To provide a further understanding of the time sequence250shown inFIG. 3,FIG. 4illustrates exemplary contents300of the buffer140of the on-board node106, at various different times represented in the time sequence250.FIG. 4illustrates an implementation in which the buffer140is a first-in-first-out (FIFO) buffer storing up to three packaged media segments. For each snapshot-in-time of the contents300, the left-most block represents the most recently added media segment, and the right-most block represents the oldest media segment that has not yet been retrieved (for consumption by the entertainment devices108) and deleted from the buffer140.

As seen inFIG. 4, the first packaged segment PS1has been fully input to the buffer140at the time T+60. While the second packaged segment PS2would be expected to be fully input by the time T+90, however, the handoff270ofFIG. 3results in a missing segment (depicted as “[0]” inFIG. 4). Similarly, while the third packaged segment PS3would be expected to be fully input by the time T+120, the handoff270results in another missing segment. Due to the restoration of connectivity prior to the time T+120, the fourth packaged segment PS4is fully received and input to the buffer by the time T+150. Moreover, upon restoring connectivity at approximately T+110 and after identifying the missing segments PS2and PS3, the request/reception/insertion of the missing segments takes place, such that the segments may be inserted (in the proper order) in the buffer140by the time T+150. By the time T+180, the first inserted segment PS2has been output for consumption by the entertainment devices108on the vehicle experiencing the handoff270, and the second inserted segment PS3is in line to be output next. In other implementations, the timing of the contents300within the buffer140may differ somewhat from what is shown inFIG. 4. For example, the segment PS3may not be inserted into the buffer140until a time between T+150 and T+180.

FIG. 5illustrates an exemplary method400, implemented by an on-board node such as the on-board node106ofFIG. 1or the on-board node206ofFIG. 2, of seamlessly providing a real-time media stream to one or more electronic devices on-board a vehicle (e.g., one or more of the entertainment devices108on-board the vehicle102xofFIG. 1or the entertainment devices204on-board the vehicle202ofFIG. 2). The real-time media stream may be a video stream (e.g., IPTV) or an audio-only stream (e.g., Internet radio), for example.

At block402, the real-time media stream is received as the stream is multicast by a remote computing system. The real-time media stream may be multicast by the data center104ofFIG. 1, for example, after encoding by the live encoder114and buffering by the delay unit116. As portions of the real-time media stream are received at block402(e.g., in a continuous or periodic manner), a number of operations may occur, as represented inFIG. 5by the blocks404through416. The multicast real-time media stream may be received via a satellite link, such as one of the links132inFIG. 1, for example. In some implementations, metadata is received along with (e.g., embedded in) the real-time media stream. The metadata may indicate boundaries between segments of the real-time media stream, and/or specify segment identifiers that each correspond to a different one of those segments. In one implementation, the metadata includes data structures that are arranged in accordance with a modified version of the EPB specification, and embedded as markers at the start or end of each segment (e.g., as discussed above in connection withFIG. 1).

At block404, as the portions of the stream are received, the real-time media stream is packaged into a plurality of time-delineated media segments. The real-time media stream may be a UDP stream, for example, and may be packaged into the segments using DASH, HDS, HTTP Live Streaming (HLS) or another suitable protocol. In some implementations where metadata associated with the real-time media stream is received at block402, block404includes segmenting the real-time media stream according to boundaries indicated by the metadata, and/or naming the plurality of time-delineated media segments based on segment identifiers specified by the metadata.

At block406, the time-delineated media segments are input into a buffer, such as the buffer140ofFIG. 1or the buffer214ofFIG. 2, for example. The buffer delays the real-time media stream by a buffer time value that is equal to or greater than the duration of N time-delineated media segments. N may be an integer greater than or equal to one, or greater than or equal to three, etc.

At block408, after a signal loss event, one or more missing time-delineated media segments are identified. The signal loss event may be a satellite or satellite spot beam handoff, for example. Alternatively, in some implementations and/or scenarios, the signal loss event may be a period of poor signal reception (e.g., due to low signal power or high interference, etc.), or any other event that causes a part of the real-time media stream to be incorrectly received. The missing segment(s) may be identified before the segment(s) would normally (i.e., but for the signal loss event) have been produced by the packaging at block404, and/or after that time, in different implementations. The duration of the N segments associated with the buffer, discussed above in connection with block406, may be designed to be greater than or equal to the maximum amount of time that is anticipated to be needed for the handoff or other signal loss event.

The missing segment(s) may be identified using various different techniques, depending on the embodiment. If the real-time media stream includes embedded metadata specifying segment identifiers for each segment, for example, successive segment identifiers may be compared at block408to determine whether an unexpected gap exists (e.g., for sequentially-numbered identifiers, by determining whether a number value of an (i+1)-th marker in the received real-time media stream is greater than a number value of an i-th marker in the received real-time media stream by more than one).

At block410, a request for the missing time-delineated media segment(s) is caused to be sent to the remote computing system. The request may be sent via a new satellite link (e.g., a link unicast HTTP interface of a server or other computing device in the remote computing system, for example. Moreover, the request may be sent to the same remote computing system component and/or location from which the real-time media stream is multicast, or to a different component and/or location.

At block412, in response to the request, the one or more missing time-delineated media segments are received from the remote computing system via a unicast transmission. The missing segment(s) may be received via the same satellite link that was used to send the request, and/or may be received via the same unicast HTTP interface that was used to send the request. Moreover, the missing segment(s) may be received from the same remote computing system component and/or location to which the request was sent, or from a different component and/or location.

At block414, the missing time-delineated media segment(s) is/are inserted into the buffer, in sequence with the plurality of time-delineated media segments being packaged at block404. For example, if two contiguous segments in the buffer have been named “0045” and “0049” (e.g., as named by the packager136ofFIG. 1based on segment identifiers in metadata embedded in the real-time media stream), and if missing segments named “0046” through “0048” (e.g., as named by the ground packager120ofFIG. 1, also based on embedded segment identifiers) are received at block412, the missing segments may be inserted into the buffer in numeric order between the segments “0045” and “0049” such that the segments are read out of the buffer (at block416, discussed below) in the order: “0045,” “0046,” “0047,” “0048,” “0049.”

At block416, the buffered real-time media stream, including the missing time-delineated media segment(s) inserted at block414, is caused to be provided to the one or more electronic devices on-board the vehicle, e.g., for presentation to one or more respective end users. The real-time media stream may be provided to the electronic device(s) using any suitable technique, such as providing the media stream to one or more on-board wireless access points (e.g., wireless access point(s)220ofFIG. 2) for transmission to the electronic device(s), for example.

FIG. 6illustrates an exemplary method500, implemented by a computing system (e.g., the data center104ofFIG. 1) located remotely from a plurality of vehicles (e.g., the vehicles102ofFIG. 1), of seamlessly providing a real-time media stream at least to one or more electronic devices on-board a first vehicle of the plurality of vehicles (e.g., the entertainment devices108on-board the vehicle102xofFIG. 1, or the entertainment devices204on-board the vehicle202ofFIG. 2). It is understood that portions of the method500may be repeated (e.g., blocks510,512and514) to provide a similar seamless experience for electronic devices on-board one or more others of the plurality of vehicles, in addition to the first vehicle. The real-time media stream may be a video stream (e.g., IPTV) or an audio-only stream (e.g., Internet radio), for example. In one embodiment, the method500occurs in parallel with the method400, with the former representing ground operations and the latter representing airplane (or other vehicle) operations.

At block502, the real-time media stream is encoded (e.g., by the live encoder114ofFIG. 1). As portions of the real-time media stream are encoded at block502(e.g., in a continuous or periodic manner), a number of operations may occur, as represented inFIG. 6by the blocks504through514. The encoding at block502may include generating metadata indicating boundaries between segments of the real-time media stream, and/or specifying information such as segment identifiers for each segment. In one implementation, the metadata includes data structures that are arranged in accordance with a modified version of the EPB specification, and embedded as markers at the start or end of each segment (e.g., as discussed above in connection withFIG. 1). The encoded real-time media stream may be a UDP stream, for example.

At block504, a first copy of the encoded real-time media stream is packaged, as the portions of the stream are encoded, into a plurality of time-delineated media segments. The first copy of the real-time media stream (e.g., UDP stream) may be packaged into the time-delineated media segments using DASH, HDS, HTTP Live Streaming or another suitable protocol (e.g., a same protocol used for packaging real-time media streams at the first vehicle), for example. The packaging may include segmenting the real-time media stream according to boundaries indicated by the metadata generated at block502, and/or naming the segments based on segment identifiers specified by the metadata generated at block502.

At block506, a sliding window of N segments of the time-delineated media segments are cached (e.g., stored in a buffer, such as a buffer of the cache122ofFIG. 1), where N is an integer greater than or equal to one (or greater than or equal to some other integer, such as two, three, etc.). The value of N may be set equal to a number of segments buffered at the first vehicle (e.g., as discussed above in connection with block406of the method400).

At block508, a second copy of the encoded real-time media stream is caused to be transmitted to the plurality of vehicles via a multicast transmission (e.g., via a number of satellite links132ofFIG. 1). In some implementations, the method500further includes buffering the second copy of the encoded real-time media stream by a buffer time value to delay the multicast transmission, thereby ensuring that missing segments are available in the cache when needed. The buffer time value may be equal to or greater than the duration of one (or two, three, etc.) of the time-delineated media segments.

At block510, a request for one or more missing time-delineated media segments is received from the first vehicle (e.g., via one of satellite links132ofFIG. 1) after a signal loss event occurs. The signal loss event may be a satellite or satellite spot beam handoff, for example. Alternatively, in some implementations and/or scenarios, the signal loss event may be a period of poor signal reception (e.g., due to low signal power or high interference, etc.), or any other event that causes the first vehicle to incorrectly receive a part of the multicast copy of the real-time media stream. The duration of the N segments associated with the cache/buffer, discussed above in connection with block506, may be designed to be greater than or equal to the maximum amount of time that is anticipated to be needed for the handoff or other signal loss event. The received request may include one or more segment identifiers each corresponding to a different one of the one or more missing segments, for example, or may include a segment identifier of a first missing segment along with a count of missing, contiguous segments, etc.

At block512, the one or more missing time-delineated media segments are retrieved from among the N cached segments. To identify which segments are to be retrieved, one or more segment identifiers (and/or a count of missing segments) included in the request may be analyzed. The segment identifiers may match the names of segments in the cache exactly (e.g., an identifier of “0077” in the request indicating that a packaged segment named “0077” should be retrieved from the cache), or a correlation between segment identifiers and names may be known in advance (e.g., an identifier of “0077” in the request indicating that a packaged segment named the hexadecimal equivalent “4D” should be retrieved from the cache), for example.

At block514, the one or more missing time-delineated media segments retrieved at block512are caused to be transmitted to the first vehicle via a unicast transmission (e.g., via a same one of satellite links132on which the request was received at block510, but in the reverse direction). The method500may include providing a unicast HTTP interface, via which the request is received at block512and the missing segment(s) is/are provided at block514. The missing segment(s) may be transmitted to the first vehicle at a higher data rate than the multicast transmission.

FIG. 7illustrates a block diagram of an example computing device550that may be utilized in the content provision system100. For example, one or more computing devices550may be particularly configured to be utilized as at least a portion of the data center104, the ground packager120, the on-board node106or206, or the entertainment devices108or204.

The computing device550may include, for example, one more central processing units (CPUs) or processors552, and one or more busses or hubs553that connect the processor(s)552to other elements of the computing device550, such as a volatile memory554, a non-volatile memory555, a display controller556, and an I/O controller557. The volatile memory554and the non-volatile memory555may each include one or more non-transitory, tangible computer readable storage media such as random access memory (RAM), read only memory (ROM), FLASH memory, a biological memory, a hard disk drive, a digital versatile disk (DVD) disk drive, etc.

In an embodiment, the memory554and/or the memory555may store instructions558that are executable by the processor552. For example, in a computing device particularly configured to be included in the data center104, the instructions558may be the instructions for executing the operations of the ground packager120, as described above. In another example, in a computing device550particularly configured to be the on-board node206, the instructions558may be the instructions for executing the operations of the packager212and/or the segment retrieval and insertion unit216, as described above. In yet another example, in a computing device550particularly configured to be one of entertainment devices108, the instructions558may be the instructions for executing the VTA. Indeed, each of the modules, applications and engines described herein can correspond to a different set of machine readable instructions for performing one or more functions described above. These modules need not be implemented as separate software programs, procedures or modules, and thus various subsets of these modules can be combined or otherwise re-arranged in various embodiments. In some embodiments, at least one of the memories554,555stores a subset of the modules and data structures identified herein. In other embodiments, at least one of the memories554,555stores additional modules and data structures not described herein.

In an embodiment, the display controller556may communicate with the processor (s)552to cause information to be presented on a connected display device559. In an embodiment, the I/O controller557may communicate with the processor(s)552to transfer information and commands to/from the user interface560, which may include a mouse, a keyboard or key pad, a touch pad, click wheel, lights, a speaker, a microphone, etc. In an embodiment, at least portions of the display device559and of the user interface560are combined in a single, integral device, e.g., a touch screen. Additionally, data or information may be transferred to and from the computing device550via a network interface570. In some embodiments, the computing device550may include more than one network interface570, such as a wireless interface and a wired interface.

The illustrated computing device550is only one example of a computing device suitable to be particularly configured for use in the content provision system100. Other embodiments of the computing device550may also be used in the content provision system100, even if the other embodiments have more, fewer and/or different components than those shown inFIG. 7, have one or more combined components, or have a different configuration or arrangement of the components. Moreover, the various components shown inFIG. 7can be implemented in hardware, a processor executing software instructions, or a combination of both hardware and a processor executing software instructions, including one or more signal processing and/or application specific integrated circuits.

Of course, the applications and benefits of the systems, methods and techniques described herein are not limited to only the above examples. Many other applications and benefits are possible by using the systems, methods and techniques described herein.

Furthermore, when implemented, any of the methods and techniques described herein or portions thereof may be performed by executing software stored in one or more non-transitory, tangible, computer readable storage media or memories such as magnetic disks, laser disks, optical discs, semiconductor memories, biological memories, other memory devices, or other storage media, in a RAM or ROM of a computer or processor, etc.

1. A method, implemented by an on-board system of a vehicle, of seamlessly providing a real-time media stream to one or more electronic devices on-board the vehicle, the method comprising: (1) receiving a real-time media stream, the real-time media stream being multicast by a remote computing system; and while receiving portions of the real-time media stream: (2) packaging the real-time media stream into a plurality of time-delineated media segments; (3) inputting the plurality of time-delineated media segments into a buffer, wherein the buffer delays the real-time media stream by a buffer time value that is equal to or greater than a duration of N of the time-delineated media segments, and wherein N is an integer greater than or equal to one; (4) identifying, after a signal loss event, one or more missing time-delineated media segments; (5) causing a request for the one or more missing time-delineated media segments to be sent to the remote computing system; (6) receiving the one or more missing time-delineated media segments from the remote computing system via a unicast transmission; (7) inserting the one or more missing time-delineated media segments into the buffer in sequence with the plurality of time-delineated media segments; and (8) causing the buffered real-time media stream, including the inserted one or more missing time-delineated media segments, to be provided to the one or more electronic devices on-board the vehicle.

2. The method of aspect 1, wherein: the vehicle is an aircraft; the method comprises receiving the real-time media stream via a first satellite link; the signal loss event is a handoff between either (i) two satellites, or (ii) two spot beams of a single satellite; and the duration of the N time-delineated media segments is greater than or equal to an anticipated maximum time needed for the handoff.

3. The method of aspect 2, wherein the method comprises, while receiving the portions of the real-time media stream: causing the request for the one or more missing time-delineated media segments to be sent to the remote computing system via a second satellite link; and receiving the one or more missing time-delineated media segments via the second satellite link.

4. The method of any one of aspects 1 through 3, wherein: receiving the real-time media stream includes receiving metadata associated with the real-time media stream, the metadata being indicative of boundaries between segments of the real-time media stream; and packaging the received real-time media stream into the plurality of time-delineated media segments includes segmenting the real-time media stream according to the boundaries indicated by the metadata.

5. The method of aspect 4, wherein: the metadata further specifies segment identifiers each corresponding to a different one of the segments of the real-time media stream; and packaging the received real-time media stream into the plurality of time-delineated media segments further includes naming the plurality of time-delineated media segments based on the segment identifiers specified by the metadata.

6. The method of aspect 5, wherein identifying the one or more missing time-delineated media segments includes comparing successive segment identifiers specified by the metadata.

7. The method of aspect 6, wherein: the successive segment identifiers include a first segment identifier corresponding to an i-th marker in the received real-time media stream and a second segment identifier corresponding to an (i+1)-th marker in the received real-time media stream; and comparing the successive segment identifiers specified by the metadata to identify the one or more missing time-delineated media segments includes subtracting a value of the first segment identifier from a value of the second segment identifier to determine a number of missing time-delineated media segments.

8. The method of any one of aspects 1 through 7, wherein the method comprises: causing the request for the one or more missing time-delineated media segments to be sent to the remote computing system via a unicast HTTP interface; and receiving the one or more missing time-delineated media segments via the unicast HTTP interface.

9. The method of any one of aspects 1 through 8, wherein: the real-time media stream is multicast by a first component of the remote computing system; the method comprises causing the request for the one or more missing time-delineated media segments to be sent to a second component of the remote computing system, the second component being remote from the first component; and the method comprises receiving the one or more missing time-delineated media segments from the second component of the remote computing system via the unicast transmission.

10. The method of any one of aspects 1 through 9, wherein causing the buffered real-time media stream, including the inserted one or more missing time-delineated media segments, to be provided to the one or more electronic devices includes providing the buffered real-time media stream to an on-board wireless access point for transmission to the one or more electronic devices.

11. The method of any one of aspects 1 through 10, wherein N is an integer greater than or equal to three.

12. An on-board system for seamlessly providing real-time media streams to one or more electronic devices on-board a vehicle carrying the on-board system, the on-board system comprising: one or more processors; and one or more non-transitory, tangible computer-readable storage media storing computer-executable instructions that, when executed by the one or more processors, cause the on-board system to: (1) receive a real-time media stream that is multicast by a remote computing system; and while receiving portions of the real-time media stream: (2) package the received real-time media stream into a plurality of time-delineated media segments; (3) input the plurality of time-delineated media segments into a buffer, wherein the buffer delays the real-time media stream by a buffer time value that is equal to or greater than a duration of N of the time-delineated media segments, and wherein N is an integer greater than or equal to one; (4) identify, after a signal loss event, one or more missing time-delineated media segments; (5) cause a request for the one or more missing time-delineated media segments to be sent to the remote computing system; (6) receive the one or more missing time-delineated media segments from the remote computing system via a unicast transmission; (7) insert the one or more missing time-delineated media segments into the buffer in sequence with the plurality of time-delineated media segments; and (8) cause the buffered real-time media stream, including the inserted one or more missing time-delineated media segments, to be provided to the one or more electronic devices on-board the vehicle.

13. The on-board system of aspect 12, wherein: the vehicle is an aircraft; the computer-executable instructions, when executed by the one or more processors, cause the on-board system to (i) receive the real-time media stream via a first satellite link, (ii) cause the request for the one or more missing time-delineated media segments to be sent to the remote computing system via a second satellite link, and (iii) receive the one or more missing time-delineated media segments via the second satellite link; the signal loss event is a handoff between either (i) two satellites, or (ii) two spot beams of a single satellite; and the duration of the N time-delineated media segments is greater than or equal to an anticipated maximum time needed for the handoff.

14. The on-board system of aspect 13, further comprising: one or more on-board wireless access points configured to transmit WiFi signals; one or more satellite transceivers configured to transmit and receive satellite signals, wherein the computer-executable instructions, when executed by the one or more processors, cause the on-board system to (i) receive the real-time media stream via the one or more satellite transceivers, (ii) cause the request for the one or more missing time-delineated media segments to be sent via the one or more satellite transceivers, (iii) receive the one or more missing time-delineated media segments via the one or more satellite transceivers, and (iv) cause the buffered real-time media stream, including the inserted one or more missing time-delineated media segments, to be provided to the one or more electronic devices via the one or more on-board wireless access points.

15. The on-board system of any one of aspects 12 through 14, wherein the computer-executable instructions, when executed by the one or more processors, cause the on-board system to: receive the real-time media stream along with metadata associated with the real-time media stream, the metadata (i) being indicative of boundaries between segments of the real-time media stream and (ii) specifying segment identifiers each corresponding to a different one of the segments of the real-time media stream; package the received real-time media stream into the plurality of time-delineated media segments at least by (i) segmenting the real-time media stream according to the boundaries indicated by the metadata and (ii) naming the plurality of time-delineated media segments based on the segment identifiers specified by the metadata; and identify the one or more missing time-delineated media segments at least by comparing successive segment identifiers specified by the metadata.

16. A method, implemented by a computing system located remotely from a plurality of vehicles, of seamlessly providing a real-time media stream at least to one or more electronic devices on-board a first vehicle of the plurality of vehicles, the method comprising: (1) encoding a real-time media stream, at least in part by generating metadata indicating boundaries between segments of the real-time media stream; and while encoding portions of the real-time media stream: (2) packaging a first copy of the encoded real-time media stream into a plurality of time-delineated media segments, at least in part by segmenting the real-time media stream according to the boundaries indicated by the metadata; (3) caching a sliding window of N segments of the plurality of time-delineated media segments, N being an integer greater than or equal to one; (4) causing a second copy of the encoded real-time media stream to be transmitted to the plurality of vehicles via a multicast transmission; (5) receiving, from the first vehicle and after a signal loss event, a request for one or more missing time-delineated media segments; (6) retrieving the one or more missing time-delineated media segments from among the cached N segments; and (7) causing the retrieved one or more missing time-delineated media segments to be transmitted to the first vehicle via a unicast transmission.

17. The method of aspect 16, further comprising: buffering the second copy of the encoded real-time media stream by a buffer time value to delay the multicast transmission, the buffer time value being equal to or greater than a duration of one of the time-delineated media segments.

18. The method of aspect 16 or 17, wherein: the metadata also specifies segment identifiers each corresponding to a different one of the segments of the real-time media stream; and packaging the first copy of the encoded real-time media stream into the plurality of time-delineated segments includes naming the plurality of time-delineated media segments based on the segment identifiers specified by the metadata.

19. The method of aspect 18, wherein: receiving a request for the one or more missing time-delineated media segments includes receiving a set of one or more segment identifiers each corresponding to a different one of the one or more missing time-delineated media segments; and retrieving the one or more missing time-delineated media segments from among the cached N segments includes retrieving the one or more missing time-delineated media segments using the received set of one or more segment identifiers.

20. The method of any one of aspects 16 through 19, wherein: the vehicle is an aircraft; the signal loss event is a handoff between either (i) two satellites, or (ii) two spot beams of a single satellite; the duration of the N time-delineated media segments is greater than or equal to an anticipated maximum time needed for the handoff; and the method comprises, while encoding the portions of the real-time media stream: causing the second copy of the encoded real-time media stream to be transmitted to the plurality of vehicles via a plurality of satellite links; receiving the request for the one or more missing time-delineated media segments via a first satellite link; and causing the retrieved one or more missing time-delineated media segments to be transmitted to the first vehicle via the first satellite link.

Thus, many modifications and variations may be made in the techniques, methods, and structures described and illustrated herein without departing from the spirit and scope of the present claims. Accordingly, it should be understood that the methods and apparatus described herein are illustrative only and are not limiting upon the scope of the claims.