ATSC 3.0 Long Term Error Correction with Fast Channel Change for Real-Time Broadcast Mobile Applications

Abstract

Techniques are described for robustly delivering (400) TV programming to mobile receivers while ensuring error correction (408) using the Advanced Television Systems Committee (ATSC) 3.0 television protocol.

Description

[Technical field]

[0001] This application relates to technological advances that are naturally rooted in computer technology and directed to digital television, and in particular to Advanced Television Systems Committee (ATSC) 3.0. [Background technology]

[0002] The Advanced Television Systems Committee (ATSC) 3.0 standards suite is a set of over a dozen industry technology standards, as set forth in ATSC A / 300, for delivering the next generation of broadcast television. ATSC 3.0 supports the delivery of a wide range of television services, from ultra-high definition television to wireless telephony, including but not limited to broadcast video, interactive services, non-real-time delivery of data, and advertising tailored to a multitude of receiving devices. ATSC 3.0 also coordinates the coordination between broadcast content (called "over the air") and related broadband delivered content and services (called "over the top"). ATSC 3.0 is designed to be flexible so that as technology evolves, advances can be easily incorporated without requiring a complete overhaul of any related technical standards. The present principles address such advances, as described below. Summary of the Invention [Problem to be solved by the invention]

[0003] As understood herein, reception of ATSC 3.0 signals by mobile receivers can be impaired by signal loss or attenuation due to overpasses, tunnels, mountains, and tall buildings. Signal loss can last for many minutes. Furthermore, although ATSC 3.0 provides error correction as part of the modulation scheme to overcome many perceived impairments to the signal, complete loss of image can occur if the signal is lost for one second or more.

[0004] As further recognized herein, memory and processing power are becoming cheaper every day. Thus, the present principles utilize an infrastructure that allows a receiving device (e.g., a mobile TV) to request packets from a broadcaster to replace missing or corrupted packets in the receiver's large (10-15 minute) buffer. The replacement packets can be received from a back channel, such as a cellular system such as 5G or 4G, or the back channel can be Wi-Fi, if available.

[0005] To address channel change latency by using large buffers, multiple channels can be buffered in the same multiplex as the currently tuned channel and tuned in immediately in response to a channel change. Alternatively, multiple channels can be buffered in a different multiplex (received through a secondary tuner). Multiple antennas can be used to allow tuning to and buffering multiple different signals (instead of the same exact signal) to perform a fast channel change function without errors. [Means for solving the problem]

[0006] Accordingly, a digital television (TV) system includes at least one mobile receiver, the at least one mobile receiver including at least one processor, the at least one processor programmed with instructions for receiving a first digital TV broadcast stream, the instructions being executable to store at least one period of the first stream in at least one buffer prior to presenting the first stream, the instructions being further executable to identify at least one packet mismatch in the first stream and request data from at least one back-channel source to correct the packet mismatch, the instructions being executable to receive the data from the back-channel source, insert the data into the buffer to correct the packet mismatch, and play the first stream from the buffer.

[0007] In an exemplary embodiment, the back-channel sources include at least one wireless telephone network and / or at least one Wi-Fi source.

[0008] In some embodiments, the packet mismatch includes missing packets and / or corrupted packets.

[0009] In non-limiting examples, the instructions can be executable to buffer at least a second stream simultaneously with buffering the first stream, the second stream can be received in a multiplex including the first stream, or the first stream can be received at a first tuner of the mobile receiver and the second stream can be received at a second tuner of the mobile receiver.

[0010] In some examples, the instructions may be executable to receive a channel change command to present a new channel. In these examples, the instructions may be executable in response to the channel change command to determine whether packets associated with the new channel are present in the buffer, and in response to determining that packets associated with the new channel are present in the buffer, to immediately access the packets associated with the new channel from the buffer to present the new channel. In response to determining that packets associated with the new channel are not present in the buffer, the instructions may be executable to begin buffering packets of the new channel for a second period of time that is shorter than the first period of time. The instructions may be executable to present the new channel.

[0011] Moreover, in these last examples, the instructions may be executable to determine whether the new channel should be added to a set of streams to be buffered for the first period of time, and in response to identifying that the new channel should be added to the set of streams to be buffered for the first period of time, add the new channel to the set.

[0012] In a non-limiting embodiment, the instructions are executable to identify at least one outage period associated with at least one route. The outage period can be a period during which broadcast digital TV cannot be received. The instructions can be executable to establish a first time period based at least in part on the outage period.

[0013] In a non-limiting embodiment, the instructions may be executable to receive a command to stop presenting digital TV on the mobile receiver. The instructions may be executable to continue buffering at least one digital TV stream in the buffer in response to the command to stop the presenting. The instructions may be executable to identify whether packets associated with a stream to be played are present in the buffer in response to a command to start playing digital TV on the mobile receiver, and to begin buffering packets of the stream to be played for a second period of time that is shorter than the first period of time in response to determining that packets associated with the stream to be played are not present in the buffer. The instructions may be further executable to play the stream to be played from the buffer, create a duplicate buffer of the stream to be played that includes a period of time that is longer than the second period, and selectively switch to playing packets in the duplicate buffer.

[0014] In another aspect, an assembly includes at least one mobile receiver of digital television, at least one digital television over-the-air (OTA) source of over-the-air digital TV signals receivable by the mobile receiver from an OTA source, and at least one back-channel source of over-the-air digital TV replacement content receivable by the mobile receiver from a back-channel source, the back-channel source including at least one wireless telephone network, or at least one Wi-Fi source, or both a wireless telephone network and a Wi-Fi source.

[0015] In another aspect, a method includes broadcasting a digital TV signal to at least one mobile receiver and transmitting replacement packets for defective or lost packets in the digital TV signal from a cellular network or a Wi-Fi source to the mobile receiver.

[0016] The details of the present application, both as to its structure and operation, can best be understood in reference to the accompanying drawings, in which like elements are designated with like reference numerals and in which: [Brief description of the drawings]

[0017] [Figure 1] FIG. 1 is a block diagram of the Advanced Television Systems Committee (ATSC) 3.0 system. [Diagram 2] FIG. 2 is a block diagram illustrating components of the device shown in FIG. 1. [Diagram 3] FIG. 1 illustrates an example assembly including a mobile receiver, an OTA ATSC 3.0 source, and a backchannel source of corrected packets. [Figure 4] FIG. 2 illustrates exemplary logic in an exemplary flowchart format for buffering and error correction performed by a mobile receiver. [Diagram 5] FIG. 2 illustrates exemplary logic in an exemplary flowchart format for buffering and error correction performed by a mobile receiver. [Figure 6] FIG. 13 illustrates exemplary logic in exemplary flow chart format for dynamically establishing buffer sizes based on anticipated outage areas along a route. [Figure 7] FIG. 1 illustrates an exemplary logic in an exemplary flow chart format for a cold start of a mobile receiver. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] The present disclosure relates to technological advances in digital television, such as Advanced Television Systems Committee (ATSC) 3.0 television. An exemplary system herein may include an ATSC 3.0 source component and a client component connected over the air and / or over a network to exchange data with each other. The client components may include one or more computing devices, including portable televisions (e.g., smart TVs, Internet-enabled TVs), portable computers, such as laptop computers and tablet computers, as well as smartphones and other mobile devices, including further examples described below. These client devices may operate in a variety of operating environments. For example, some of the client computers may use, by way of example, an operating system produced by Microsoft Corporation, or a Unix operating system, or an operating system produced by Apple Computer, Inc. or Google, Inc. (e.g., Android®). These operating environments may be used to execute one or more browsing programs, such as browsers produced by Microsoft Corporation, Google Corporation, Mozilla, or other browser programs, that can access websites hosted by Internet servers, as described below.

[0019] The ATSC 3.0 source components may include broadcast transmission components and servers and / or gateways, which may include one or more processors that execute instructions that configure the source components to broadcast and / or transmit data over a network, such as the Internet. The client components and / or local ATSC 3.0 source components may also be exemplified by gaming consoles, such as a Sony PlayStation®, personal computers, and the like.

[0020] Information may be exchanged between clients and servers over a network. For this purpose and for security, the server and / or client may include firewalls, load balancers, temporary storage, and proxies, as well as other network infrastructure to enhance reliability and security.

[0021] As used herein, instructions refer to computer-executed steps for processing information within a system. Instructions may be implemented in software, firmware, or hardware and may include any type of program step performed by a component of the system.

[0022] The processor may be a general purpose single-chip or multi-chip processor capable of implementing logic through various lines such as address lines, data lines and control lines, as well as registers and shift registers.

[0023] The software modules illustrated by the flowcharts and user interfaces herein may include various subroutines, procedures, etc. Without limiting the disclosure, logic disclosed as being performed by a particular module may also be redistributed among other software modules and / or combined into a single module and / or utilized within a shareable library. Although a flowchart format may be used, it is understood that the software may be implemented as a state machine or other logical method.

[0024] The principles described herein may be implemented as hardware, software, firmware, or a combination thereof, and thus, example components, blocks, modules, circuits, and steps are described in terms of their functionality.

[0025] In addition to those suggested above, the logic blocks, modules, and circuits may be implemented or performed with a processor, digital signal processor (DSP), field programmable gate array (FPGA) or other programmable logic device such as an application specific integrated circuit (ASIC), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor may be implemented with a controller, state machine, or combination of computing devices.

[0026] The functions and methods described below, when implemented in software, may be written in any suitable language, such as, but not limited to, HyperText Markup Language (HTML)-5, Java / Javascript, C#, or C++, and may be stored on or transmitted through a computer-readable storage medium, such as Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Compact Disk Read-Only Memory (CD-ROM), or other optical disk storage, such as a Digital Versatile Disk (DVD), magnetic disk storage, or other magnetic storage devices, including removable thumb drives, etc. A connection may constitute the computer-readable medium. Such connections may include wired cables, including, by way of example, optical fiber, coaxial cable, digital subscriber line (DSL), and twisted pair cable.

[0027] Components included in one embodiment may also be used in other embodiments in any suitable combination. For example, any of the various components described herein and / or illustrated in the figures may be combined, substituted, or excluded from other embodiments.

[0028] "A system having at least one of A, B, and C (and similarly, "a system having at least one of A, B, or C" and "a system having at least one of A, B, C")" includes systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or all of A, B, and C, etc.

[0029] 1, an example of an ATSC 3.0 source component is labeled "broadcaster equipment" 10 and may include over-the-air (OTA) equipment 12 for wirelessly broadcasting television data to multiple receivers 14, such as ATSC 3.0 televisions, typically via orthogonal frequency division multiplexing (OFDM), in a one-to-many relationship. The one or more receivers 14 may communicate with one or more companion devices 16, such as a remote control, tablet computer, mobile phone, etc., via a short-range, typically wireless link 18, which may be implemented by Bluetooth, low energy Bluetooth, other near-field communication (NFC) protocols, infrared (IR), etc.

[0030] One or more of the receivers 14 may also communicate with over-the-top (OTT) equipment 22 of the broadcaster equipment 10, typically in a one-to-one relationship, via a wired and / or wireless network link 20, such as the Internet. The OTA equipment 12 may be co-located with the OTT equipment 22, or the two sides 12, 22 of the broadcaster equipment 10 may be remote from each other and communicate with each other through suitable means. In either case, the receiver 14 may receive ATSC 3.0 television signals over the OTA through a tuned ATSC 3.0 television channel, and may also receive associated content, including television, over the OTT (broadband). It should be noted that the computerized devices described in all figures herein may include some or all of the components described in the various devices in FIGS. 1 and 2.

[0031] Reference is now made to Figure 2, which illustrates an example of the components shown in Figure 1 in greater detail. Figure 2 illustrates an example protocol stack that can be implemented by a combination of hardware and software. Using the ATSC 3.0 protocol stack illustrated in Figure 2 and modified as appropriate for the broadcaster side, a broadcaster can transmit a hybrid service delivery in which one or more program elements are delivered over a computer network (referred to herein as "broadband" and "over the top" (OTT)) and over the air (referred to herein as "broadcast" and "over the air" (OTA)). Figure 2 also illustrates an example stack including hardware that can be implemented by a receiver.

[0032] Disclosing FIG. 2 with respect to broadcaster equipment 10, one or more processors 200 accessing one or more computer storage media 202, such as any memory or storage described herein, can be implemented to provide one or more software applications at a top application layer 204. Application layer 204 can include, for example, one or more software applications written in HTML5 / Javascript executing in a runtime environment. Applications in application stack 204 can include, but are not limited to, linear TV applications, interactive services applications, companion screen applications, personalization applications, emergency alert applications, and usage reporting applications. Applications are typically implemented in software that represents the elements of the viewer experience, including video encoding, audio encoding, and runtime environment. As an example, applications can be provided that allow a user to control dialogue, use alternative audio tracks, and control audio parameters such as normalization and dynamic range.

[0033] Below the application layer 204 is the presentation layer 206. On the broadcast (OTA) side, the presentation layer 206 includes a broadcast audio-video playback device called a media processing unit (MPU) 208 that, when implemented in a receiver, decodes and plays audio-video content for over-the-air broadcast on one or more displays and speakers. The MPU 208 is configured to present an International Organization for Standardization (ISO) Base Media File Format (BMFF) data representation 210 and video in High Efficiency Video Coding (HEVC) with audio, for example in Dolby Audio Compression (AC)-4 format. ISO BMFF is a generic file structure for time-based media files and presentation metadata that are divided into "segments." Each file is essentially a collection of nested objects, each containing a type and a length. To facilitate decoding, the MPU 208 can access the Encrypted Media Extensions (EME) / Common Encryption (CENC) module 212 on the broadcast side.

[0034] As further shown in FIG. 2, on the broadcast side, the presentation layer 206 can include signaling modules including either a Motion Picture Experts Group (MPEG) Media Transport Protocol (MMTP) signaling module 214 or a real-time object delivery over unidirectional transport (ROUTE) signaling module 216 to deliver non-real-time (NRT) content 218 accessible to the application layer 204. NRT content can include, but is not limited to, stored replacement advertisements. ROUTE sessions include audio-video (AV) streams. Within ROUTE sessions, layered coding transport (LCT) channels are set up. Each LCT channel carries either video, audio, captions, or other data.

[0035] On the broadband (OTT or computer network) side, when implemented by a receiver, the presentation layer 206 can include one or more dynamic adaptive streaming over hypertext transfer protocol (HTTP) (DASH) players / decoders 220 for decoding and playing audio-video content from the Internet. For this purpose, the DASH player 220 can access an EME / CENC module 222 on the broadband side. The DASH content can be provided as DASH segments 224 in ISO / BMFF format.

[0036] As with the broadcast side, the broadband side of the presentation layer 206 can include NRT content in files 226 and can also include signaling objects 228 for providing playback signaling.

[0037] Below the presentation layer 206 in the protocol stack is the session layer 230. The session layer 230 includes, on the broadcast side, either the MMTP protocol 232 or the ROUTE protocol 234.

[0038] On the broadband side, the session layer 230 includes the HTTP protocol 236, which can be implemented as HTTP-secure (HTTP(S)). The broadcast side of the session layer 230 can also use an HTTP proxy module 238 and a service list table (SLT) 240. The SLT 240 contains tables of signaling information used to build basic service listings and provide bootstrap discovery of broadcast content. The "ROUTE signaling" table, delivered over User Datagram Protocol (UDP) by the ROUTE transport protocol, contains the Media Presentation Description (MPD).

[0039] Below the session layer 230 in the protocol stack is the transport layer 242 for establishing low latency, loss tolerant connections. The transport layer 242 uses the User Datagram Protocol (UDP) 244 on the broadcast side and the Transmission Control Protocol (TCP) 246 on the broadband side.

[0040] 2 also includes a network layer 248 below the transport layer 242. The network layer 248 uses the Internet Protocol (IP) for IP packet communication on both sides, with multicast delivery being common on the broadcast side and unicast delivery being common on the broadband side.

[0041] Below the network layer 248 is the physical layer 250, which includes broadcast transmit / receive equipment 252 and computer network interface 254 for communicating over the respective physical media associated with the two sides. The physical layer 250 converts Internet Protocol (IP) packets suitable for transmission over the relevant media, can add forward error correction to enable error correction at the receiver, and can also include a modulation and demodulation module to incorporate modulation and demodulation functions. It converts bits into symbols for long distance transmission and to improve bandwidth efficiency. On the OTA side, the physical layer 250 typically includes a wireless broadcast transmitter for wireless broadcasting of data using Orthogonal Frequency Division Multiplexing (OFDM), while on the OTT side, the physical layer 250 includes a computer transmission component for transmitting data over the Internet.

[0042] On the broadband side, the protocol stack can use data in the DASH Industry Forum (DASH-IF) profile format, which is transmitted through various protocols (HTTP / TCP / IP). Media files in the ISO BMFF-based DASH-IF profile format can be used as a distribution media encapsulation and synchronization format for both broadcast and broadband distribution.

[0043] Each receiver 14 typically includes a protocol stack that is complementary to the protocol stack of the broadcaster equipment.

[0044] Receiver 14 of FIG. 1 may include an Internet-enabled TV including an ATSC 3.0 TV tuner 256 (corresponding to a set-top box that controls the TV), as shown in FIG. 2. Receiver 14 may be an Android®-based system. Receiver 14 may alternatively be implemented by a computerized Internet-enabled ("smart") phone, a tablet computer, a notebook computer, a computerized wearable device, or the like. In any case, it should be understood that receiver 14 and / or other computers described herein are configured to implement the present principles (e.g., to communicate with other devices to implement the present principles, to execute the logic described herein, and to perform any other functions and / or operations described herein).

[0045] Accordingly, the receiver 14 may be constructed with some or all of the components shown in FIG. 1 to implement such principles. For example, the receiver 14 may include one or more displays 258, which may be implemented with a high definition or ultra-high definition "4K" or higher flat screen and may or may not be touch enabled to receive user input signals via touching the display. The receiver 14 may also include one or more speakers 260 for outputting audio in accordance with the present principles, and at least one additional input device 262, e.g., an audio receiver / microphone, for inputting audible commands to the receiver 14 to control the receiver 14. The exemplary receiver 14 may further include one or more network interfaces 264 for communicating over at least one network, such as the Internet, a WAN, a LAN, a PAN, etc., under the control of one or more processors 266. The interface 264 may thus be a Wi-Fi transceiver, which is an example of a wireless computer network interface, such as, but not limited to, a mesh network transceiver. The interface 264 may be, but is not limited to, a Bluetooth transceiver, a Zigbee transceiver, an Infrared Data Association (IrDA) transceiver, a wireless USB transceiver, a wired USB, a wired LAN, Powerline, or a Multimedia over Coax Alliance (MoCA). It is to be understood that the processor 266 controls the receiver 14 to implement the present principles, including other elements of the receiver 14 described herein, such as, for example, controlling the display 258 to present images and receiving input from the display 258. It is further noted that the network interface 264 may be, for example, a wired or wireless modem or router, or a wireless telephone transceiver, or other suitable interface, such as a Wi-Fi transceiver as described above.

[0046] In addition to the above, receiver 14 may also include one or more input ports 268, such as a High-Definition Multimedia Interface (HDMI) port or a USB port, for physically connecting to another CE device (using a wired connection), and / or a headphone port for connecting headphones to receiver 14 so that sound from receiver 14 can be presented to a user through the headphones. For example, input port 268 may be connected via wire or wireless to a cable or satellite source of audio-video content. Thus, the source may be a stand-alone or integrated set-top box, or a satellite receiver. Alternatively, the source may be a game console or disc player.

[0047] The receiver 14 may further include one or more computer memories 270, such as non-transitory disk-based or solid-state storage, possibly embodied within the receiver chassis as a stand-alone device, or as a personal video recording device (PVR) or video disk player for playing audio-video (AV) programming inside or outside the receiver chassis, or as a removable storage medium. In some embodiments, the receiver 14 may also include a position or location receiver 272, such as, but not limited to, a cellular telephone receiver, a global positioning satellite (GPS) receiver, and / or an altimeter, configured to receive and provide geographic location information to the processor 266 from at least one satellite or cellular telephone tower, and / or configured to cooperate with the processor 266 to determine the altitude at which the receiver 14 is located. However, it should be understood that another suitable position receiver other than a cellular telephone receiver, a GPS receiver, and / or an altimeter may be used to determine the location of the receiver 14, for example in all three dimensions, in accordance with the present principles.

[0048] Continuing with the description of receiver 14, in some embodiments receiver 14 may also include one or more cameras 274, which may include one or more of a digital camera, such as a thermal imaging camera, a webcam, and / or a camera integrated into receiver 14 and controllable by processor 266 to collect pictures / images and / or videos in accordance with the present principles. Receiver 14 may also include a Bluetooth® transceiver 276 or other near field communication (NFC) element to communicate with other devices using Bluetooth® and / or NFC technology, respectively. An example of an NFC element may be a radio frequency identification (RFID) element.

[0049] Additionally, receiver 14 may include one or more auxiliary sensors 278 (e.g., motion sensors such as accelerometers, gyroscopes, wheel revolution recorders, or magnetic sensors, and combinations thereof) that provide input to processor 266, infrared (IR) sensors for receiving IR commands from a remote control, optical sensors, speed and / or gait sensors, gesture sensors (for sensing gesture commands), etc. An IR sensor 280 may also be provided for receiving commands from a wireless remote control. A battery (not shown) may also be provided to power receiver 14.

[0050] The companion device 16 may incorporate some or all of the elements shown in association with the receiver 14 above.

[0051] As shown in FIG. 3, the mobile ATSC 3.0 receiver 300 may include any of the receiver components described herein, and in the particular example shown, the mobile receiver 300 includes one or more antennas 302 (e.g., two shown) that receive and provide signals to one or more tuners 304 (e.g., two shown), which may process the signals and buffer packets carried in the signals in one or more content buffers 306. The signals may be received over the air from an ATSC 3.0 broadcast (OTA) source 308. The buffers 306 may be part of a digital video recorder (DVR) 310 for the mobile receiver 300 or the vehicle in which the mobile receiver 300 is located. The buffered signals may be presented on a display 312 of the mobile receiver 300 under the control of one or more processors 314.

[0052] Additionally, the mobile receiver 300 may include one or more out-of-band transceivers 316 for wirelessly communicating with one or more back-channel sources 318 of ATSC 3.0 packets. The back-channel sources 318 may include, for example, one or more wireless telephone networks, such as, but not limited to, one or more global system for mobiles (GSM) networks or code division multiple access (CDMA) networks. The back-channel sources 318 may include, for example, one or more Wi-Fi servers.

[0053] Figure 4 illustrates logic that may be executed by the mobile receiver 300 shown in Figure 3. Starting at block 400, the tuner 304 demodulates a tuned digital TV signal and, at block 402, stores packets of the stream in a buffer 306. The buffer 306 may be relatively large, for example, to hold several minutes (e.g., as non-limiting examples, 5, 10, or 20 minutes of one or more streams).

[0054] Additionally, the receiver 300 also demodulates one or more additional digital TV streams, at block 404, and buffers the packets of the streams in a buffer, at block 406. These streams may be received from the same tuner 304 in the same multiplex as the tuned stream was received, or from another tuner 304 (which may receive an over-the-air signal from a different antenna 302 than the tuned stream was received).

[0055] To accommodate error correction in mobile digital TV applications and to create costly services, in block 408, the mobile receiver 300 requests any missing or erroneous packets from the back channel source 318 and recognizes that ATSC 3.0 uses IP packets using the transceiver 316 shown in Figure 3. In block 410, replacement packets received from the back channel source 318 are inserted into the buffer at locations corresponding to the missing or corrupted packets. These steps can be performed for all streams in the buffer 306.

[0056] As shown in Figure 5, to address channel change latency through the use of a large buffer 306, a channel change command is received at block 500 to present a new channel in place of what was the currently tuned channel. Proceeding to decision diamond 502, it is determined whether new stream packets corresponding to the new channel are stored in the buffer. If so, the packets of the new stream are immediately accessed from the buffer, decoded, and immediately presented on the display 312 with minimal perceptible latency. The contents in this new stream buffer may also be assumed to be error corrected from Figure 4.

[0057] On the other hand, if it is determined at decision diamond 502 that the new stream selected at block 500 is not the one expected by virtue of pre-storage in the buffer, the logic proceeds from diamond 502 to block 506 to buffer an initial short period of the new stream (e.g., 2 seconds) sufficient to begin playback, and then begins playback of the new stream after this short buffering period at block 508. At block 510, error correction is performed on the new stream according to the logic of FIG.

[0058] Proceeding to decision diamond 512, it is determined whether the new stream should be added to the set of streams that are buffered long term (e.g., minutes) into the future. For example, if the new stream has been tuned in for a threshold number of times or for a threshold period of time, then in block 514 it can be added to the set of buffered streams or it can replace another stream in the set.

[0059] As can be seen in FIG. 6, some delivery routes may have known outages (e.g., tunnels that typically take 15 minutes to traverse, or other natural or man-made obstacles to digital TV broadcast signals, etc.). Thus, in block 600, a planned route, a current route, or a repeat route may be identified. This may be done by establishing a wireless connection between the mobile receiver 300 and, for example, a navigation application on the user's cell phone, or by other means of identifying a common route, a planned route, or a current route from the application. Proceeding to block 602, locations along the route where digital TV broadcasts may not be received (e.g., tunnels) are identified. This may be done by accessing an electronic route that includes the route and shows tunnels, etc.

[0060] Proceeding to block 604, the time to pass the locations identified in block 602 is identified. This may be done, for example, by using the current speed as indicated by a Global Positioning Satellite (GPS), or by accessing an electronic map of the route that indicates typical speeds through the locations, or by other means. As shown in block 606, the length of the stream buffered in the buffer 306 may be set according to the passing time. For example, the buffer length may be set approximately equal to the longest passing time identified in block 604.

[0061] Thus, the mobile receiver 300 can have access to mapping software (e.g., running in the vehicle and communicated to the mobile receiver via Bluetooth). The mapping software knows the destination and route and can calculate the longest outage (e.g., a particular tunnel that is of a particular length and knows the average rate travel (or real-time updates on traffic speed) + some margin). The length of the buffer 306 can be dynamically set to be just that size. Thus, the particular route influences the buffer size selected when beginning a travel, minimizing the buffer to just what is needed and also minimizing the need to pre-cache the buffer while the receiver / player is "off". In that scenario, the user may need to wait several minutes for the buffer to fill before the content is rendered.

[0062] As shown in Figure 7, when the mobile receiver 300 is turned off, meaning that it is no longer in a presentation mode presenting digital TV content, block 700, the mobile receiver 300 can continue to receive content in the buffer 306 for the selected channel, block 702. When the receiver resumes digital TV presentation, block 704, the buffer 306 is full and playback can occur immediately, block 706. Alternatively, upon a "cold start" of the mobile receiver 300 beginning digital TV playback, block 704, a small buffer (e.g., of a few seconds) can be created so that the initial stream begins playing relatively quickly, while simultaneously and in parallel, block 708, a larger buffer for the stream can be created and, in the event of a signal outage, block 710, switched to the larger buffer.

[0063] The methods described herein may be implemented as software instructions executed by a processor, a suitably configured Application Specific Integrated Circuit (ASIC) or Field Programmable Gate Array (FPGA) module, or in any other convenient form as would be understood by one of ordinary skill in the art. If used, the software instructions may be embodied in a non-transitory device such as a CD ROM or flash drive. The software code instructions may also be embodied in a transitory configuration such as a radio or optical signal, or through downloading over the internet.

[0064] While the present principles have been described with reference to certain example embodiments, it will be understood that these embodiments are not intended to be limiting, and that the subject matter claimed herein may be implemented using a variety of alternative configurations. [Explanation of symbols]

[0065] 10 Broadcasting Equipment 12 Over-the-air (OTA) equipment 14 Receiver 16 Companion Devices 18 Wireless Links 20 Wired and / or Wireless Network Links 22 Over-the-top (OTT) equipment 200 processors 202 Storage medium 204 Application Layer 206 Presentation Layer 208 Media Processing Unit (MPU) 210 ISO BMFF Data Representation 212 EME / CENC module 214 MPEG MMTP signaling module 216 ROUTE signaling module 218 Non-Real-Time (NRT) Content 220 DASH Player / Decoder 222 EME / CENC module 224 DASH segments 226 NRT File 228 Signaling Objects 230 Session Layer 232 MMTP Protocol 234 ROUTE Protocol 236 HTTP Protocol 238 HTTP Proxy Module 240 Service List Table (SLT) 242 Transport Layer 244 User Datagram Protocol (UDP) 246 Transmission Control Protocol (TCP) 248 Network Layer 250 Physical layer 252 Broadcast transmitting / receiving equipment 254 Computer Network Interfaces 256 ATSC 3.0 TV Tuner 258 Display 260 Speaker 262 Input Devices 264 Network Interface 266 processors 268 input ports 270 Computer Memory 272 Position or location receivers 274 Camera 276 Bluetooth (registered trademark) transceiver 278 Auxiliary Sensor 280 IR Sensor 300 Mobile Receiver 302 Antenna 304 Tuner 306 Content Buffer 308 ATSC 3.0 Broadcast (OTA) Sources 310 Digital Video Recorder (DVR) 312 Display 314 processor 316 Transceiver 318 Back Channel Source Demodulates 400 tuned digital TV streams 402 Store in a large (5-15 minute) buffer 404 Demodulate additional streams 406 Buffered 408 Request to backchannel source for missing / corrupted packet 410 Insert replacement packet in correct place in buffer 500 Channel change command received 502 Is there a new channel in the buffer? 504 Play new channel immediately 506 Buffer new channels for a minimum period (e.g. 2 seconds) 508 Start playing 510 Error correction 512 Should I add to the long term buffer set? 514 Added 600 Identifying repeated or planned routes Identify outage locations along 602 routes 604 Identify the time to pass a location 606 Set buffer length according to transit time 700 Mobile Receiver Off 702 Keep Stream Buffered 704 On 706 Play from buffer 708 Create a duplicate buffer for the stream 710 Switch to duplicate (longer) buffer if signal is lost for shorter buffer

Claims

1. 1. A digital television (TV) system comprising: At least one mobile receiver, the at least one mobile receiver including at least one processor, the at least one processor including: receiving a first digital TV broadcast stream; storing at least one period of a first stream in at least one buffer prior to presenting said first stream; Identifying at least one packet mismatch in the first stream; requesting data from at least one back-channel source to remedy said packet mismatch; receiving the data from the backchannel source; inserting the data into the buffer to correct the packet mismatch; playing the first stream from the buffer; It is programmed with instructions for The instruction: receiving a command to stop presenting digital TV on the mobile receiver; continuing to buffer at least one digital TV stream in said buffer in response to a command to stop said presenting; receiving a command to initiate playback of digital TV on the mobile receiver; identifying whether packets associated with a stream to be played are present in the buffer in response to a command to initiate the playback; in response to determining that no packets associated with the stream to be played are present in the buffer, commence buffering packets of the stream to be played for a predetermined period of time; Playing the stream to be played from the buffer; creating a copy buffer of the stream to be played that includes a threshold period longer than the predetermined period; selectively switching to playing out packets in the replication buffer; It is feasible to A digital TV system comprising:

2. 2. The digital TV system of claim 1, wherein said back-channel sources include at least one wireless telephone network.

3. 2. The digital TV system of claim 1, wherein the back channel sources include at least one Wi-Fi source.

4. 2. The digital TV system of claim 1, wherein the packet discrepancies include missing packets.

5. 2. The digital TV system of claim 1, wherein the packet mismatch includes a corrupted packet.

6. 2. The digital TV system of claim 1, wherein the instructions are executable to buffer at least a second stream simultaneously with buffering the first stream.

7. 7. A digital TV system according to claim 6, characterised in that the second stream is received in a multiplex including the first stream.

8. 7. The digital TV system of claim 6, wherein the first stream is received at a first tuner of the mobile receiver and the second stream is received at a second tuner of the mobile receiver.

9. The instruction: receiving a channel change command to present a new channel; determining whether a packet associated with the new channel is present in the buffer in response to the channel change command; in response to determining that packets associated with the new channel are present in the buffer, immediately accessing the packets associated with the new channel from the buffer to present the new channel; in response to determining that no packets associated with the new channel are present in the buffer, begin buffering packets of the new channel for the predetermined period of time; presenting the new channel; 2. The digital TV system according to claim 1, characterized in that it is operable to:

10. The instruction: determining whether to add the new channel to a set of streams to be buffered for the threshold period; adding the new channel to the set of streams to be buffered for the threshold period in response to identifying that the new channel should be added to the set.

10. The digital TV system according to claim 9, characterized in that it is operable to:

11. The instruction: identifying at least one outage period associated with a transport route of at least one packet, said outage period being a period during which broadcast digital TV cannot be received; establishing the threshold time period for which the set of streams should be buffered based at least in part on the outage time period; 2. The digital TV system of claim 1, wherein the digital TV system is operable to:

12. 10. The digital TV system of claim 1, wherein the digital television system includes at least one Advanced Television Systems Committee (ATSC) 3.0 system.

13. 1. An assembly comprising: at least one mobile receiver of a digital television configured to receive content from at least one digital television over-the-air (OTA) source and at least one back-channel source; At least one processor associated with the mobile receiver and configured with the following instructions: Including, The instruction: receiving a command to stop presenting digital TV on the mobile receiver; continuing to buffer at least one digital TV stream in a buffer in response to a command to stop the presenting; receiving a command to initiate playback of digital TV on the mobile receiver; identifying whether packets associated with a stream to be played are present in the buffer in response to a command to initiate the playback; in response to determining that no packets associated with the stream to be played are present in the buffer, commence buffering packets of the stream to be played for a predetermined period of time; Playing the stream to be played from the buffer; creating a copy buffer of the stream to be played that includes a threshold period longer than the predetermined period; selectively switching to playing out packets in the replication buffer; 16. An assembly comprising:

14. 14. The assembly of claim 13, wherein the back-channel source includes at least one wireless telephone network.

15. 14. The assembly of claim 13, wherein the back channel source comprises at least one Wi-Fi source.

Images