A method for signaling memory requirements when out-of-order data is used in ATSC 3.0

Abstract

Techniques are described for extending and / or improving the Advanced Television Systems Committee (ATSC) 3.0 television protocol to robustly deliver next-generation broadcast television services. To improve the robustness of datacast files to limited memory platforms, each file is divided into partitions, packets within the partitions are then ordered out of order (OOO), and the partitions are then transmitted in order, with each packet being OOO (out of order).

Description

[Technical Field]

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

[0002] The Advanced Television Systems Committee (ATSC) 3.0 family of standards, outlined in A / 300, is a set of numerous industry technical standards for delivering next-generation broadcast television. ATSC 3.0 supports the delivery of a wide range of television services, including broadcast video, interactive services, non-real-time data delivery, and targeted advertising, to a variety of receiving devices, from ultra-high-definition televisions to wireless telephones. ATSC 3.0 also coordinates coordination between broadcast content (referred to as "over the air") and related broadband-delivered content and services (referred to as "over the top"). ATSC 3.0 is designed to be flexible so that, as technology evolves, advancements can be easily incorporated without requiring a complete overhaul of any of the related technical standards.

[0003] As understood herein, ATSC 3.0 can be used to deliver data to mobile receivers (e.g., delivering maps and operating manuals to moving vehicles). As further understood herein, for file delivery, packet loss results in corruption. The present principles introduce error correction techniques to improve data reception for all files, including video media. Summary of the Invention [Problem to be solved by the invention]

[0004] Also as understood herein, ATSC3 Application Layer Forward Error Correction (AL-FEC) is specified in ATSC Standard A / 331 to use the error correction techniques described in publication RFC 6330 ("RaptorQ"). To improve robustness, given the possibility of file delivery under conditions of temporary reception interruptions (e.g., when a mobile receiver passes through a tunnel or in other areas of echo or dropout), all packets of a transmitted file can be sent out of order (OOO), or sections of the file can be spread apart in time. In this way, during periods of interruption, loss is limited to a small section of the file, and fewer repair bits can be used to correct missing or corrupted packets.

[0005] However, as recognized herein, sending packets out of order (OOO) across an entire file means that the location of the next packet in memory is unknown. Non-contiguous data is often stored in non-persistent memory, such as RAM, because storing individual packets in random-access locations in persistent memory (e.g., flash) is often too slow for the typical data reception speeds provided by ATSC 3.0. Therefore, out-of-order packet delivery without repair requires non-persistent memory up to the file length, which may be impractical for some receivers (with limited storage capacity). Furthermore, repairable source data requires the generation of intermediate symbols, which are also stored in non-persistent memory. Performing fountain code-based repair (RAPTOR-Q) is CPU-intensive and requires the source data and repair data to be processed together in a timely manner, resulting in longer repair times for persistent memory, such as flash.

[0006] Thus, the present principles recognize the benefits of first dividing a data file into partitions and then randomly ordering packets for each partition out of order. Partitioning out-of-order packet delivery reduces non-persistent memory requirements by knowing that consecutive blocks of data (partitions) are being delivered out-of-order at a time. Memory requirements must be sufficient to contain two partitions: one for the data currently being received and one for simultaneously moving previously received data to persistent memory to free up memory for the next partition. Thus, for example, repairing data in non-persistent memory requires two partitions and repair data (e.g., 2x percent repair). For 10% repair, the memory requirement is 2.2 times the size of the partition. If the receiver generates intermediate symbols for repair as source symbols are being received, the memory requirement is four times the partition.

[0007] Ideally, the receiver also retains partial data for incomplete partitions due to reception starting midway through a partition. In this example, the non-persistent memory requirement is three partitions plus repair data, or six times larger if intermediate symbols are generated. This allows a second file carousel to fill in the missing data in the first received partition. In either case, the total RAM memory can be much smaller than the size required to store the entire file transmitted with packets out of order (OOO). The time required for the receiver to move data from non-persistent memory to persistent memory and repair data as needed can be estimated based on the bit rate and partition size. [Means for solving the problem]

[0008] In a first aspect, in a digital television, a method includes dividing at least one file into a plurality of partitions, the method including, within each partition, ordering packets of the partition out of order, and transmitting the resulting partitions in order to at least one receiver, with each packet out of order.

[0009] In some embodiments, the method may include interleaving a plurality of source blocks of the file with repair symbols, each partition including a plurality of source blocks.

[0010] In an exemplary implementation including repair, the file has Z source blocks, where Z is the upper bound on F / T. max is an integer greater than or equal to k max where Z is the number of symbols in each source block, T is the number of bytes in each symbol, and F is the size of the file. l Contains Z source blocks l is the upper limit of Z, n is equal to P divided by n is the total number of partitions, while at least one partition is s It can contain Z source blocks, s is the lower limit of Z n is equal to divided by . The upper bound means round up to the nearest integer, and the lower bound means round down to the nearest integer.

[0011] In another aspect, a digital television device includes at least one receiver configured to receive digital television from a digital television transmitter system, the receiver including at least one processor programmed with instructions for receiving, into a non-persistent memory, at least some of a plurality of partitions of at least one file, each partition including packets out of order (OOO), the instructions being executable to order the packets in order, transmit at least one partition in the non-persistent memory to a persistent memory, and receive additional partitions into the non-persistent memory.

[0012] In another aspect, a digital television apparatus includes at least one transmitter, the transmitter including at least one processor programmed with instructions for configuring the processor to divide at least one file into a plurality of partitions and, within each partition, to order packets of the partition out of order (OOO), the instructions are executable to transmit the partitions in order, with their respective packets out of order (OOO), to at least one receiver.

[0013] 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 reference numerals indicate like elements and in which: [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 1 illustrates the Advanced Television Systems Committee (ATSC) 3.0 system. [Figure 2] FIG. 2 illustrates components of the device shown in FIG. 1. [Figure 3] FIG. 1 illustrates an example of a transmitter side architecture. [Figure 4] FIG. 1 illustrates an example of a receiver-side architecture. [Figure 5]FIG. 10 illustrates a schematic partition in which inner packets are sent in order, with the inner packets arranged out of order (OOO). [Figure 6] FIG. 1 illustrates exemplary transmitter logic in exemplary flow chart form. [Figure 7] FIG. 1 illustrates exemplary receiver logic in exemplary flow chart form. [Figure 8] FIG. 2 illustrates source blocks of a file. [Figure 9] FIG. 9 shows a partition including the source block of FIG. 8. [Figure 10] FIG. 1 illustrates out-of-order (OOO) delivery with repair data and partitioning. DETAILED DESCRIPTION OF THE INVENTION

[0015] This 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 via broadcast and / or network to enable data exchange between the client component and the ATSC 3.0 source component. The client component may include one or more computing devices, such as portable televisions (e.g., smart TVs, Internet-enabled TVs), portable computers, such as laptops and tablet computers, and smartphones and other mobile devices, including further examples described below. These client devices may operate in a variety of operating environments. For example, some client computers may employ operating systems such as Microsoft's operating system, Unix operating system, or Android® manufactured by Apple Computer, Inc. or Google, Inc., as examples. These operating environments may be used to execute one or more browsing programs, such as browsers created by Microsoft, Google, or Mozilla, or other browser programs capable of accessing websites hosted by Internet servers, as described below.

[0016] ATSC 3.0 Publication A / 331, which is incorporated herein by reference, may be particularly relevant to the techniques described herein.

[0017] An ATSC 3.0 source component may include a broadcast transmission component and a server and / or gateway, which may include one or more processors that execute instructions that configure the source component to broadcast and / or transmit data over a network such as the Internet. Examples of client components and / or local ATSC 3.0 source components include gaming consoles such as the Sony PlayStation®, personal computers, etc.

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

[0019] As used herein, instructions refer to computer-implemented 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.

[0020] The processor can be a 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.

[0021] The software modules illustrated by the flowcharts and user interfaces herein may include various subroutines, procedures, etc. Without limiting the disclosure, logic referred to as being performed by a particular module may be redistributed among other software modules and / or combined into a single module and / or made available in a shareable library. While a flowchart format may be used, it should be understood that the software may also be implemented as a state machine or other logical method.

[0022] 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.

[0023] In addition to those suggested above, the logic blocks, modules, and circuits may be implemented or performed using general purpose processors, digital signal processors (DSPs), field programmable gate arrays (FPGAs) or other programmable logic devices such as application specific integrated circuits (ASICs), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor may be implemented by a controller, a state machine, or a combination of computing devices.

[0024] The functions and methods described below, when implemented in software, can be written in any suitable language, such as, but not limited to, Hypertext Markup Language (HTML)-5, Java / Javascript, C#, or C++, and can 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 disc 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 can constitute the computer-readable medium. Such connections can include wired cables, including, by way of example, optical fiber, coaxial cable, digital subscriber line (DSL), and twisted pair cable.

[0025] Components included in one embodiment may 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.

[0026] "An element having at least one of A, B, and C" (similarly, "having at least one of A, B, or C" and "having at least one of A, B, and C") includes A only, B only, C only, both A and B, both A and C, both B and C, and / or all of A, B, and C, etc.

[0027] Referring to FIG. 1 , an example of an ATSC 3.0 source component is designated as a “broadcast station facility” 10 and may include an over-the-air (OTA) facility 12 that broadcasts television data wirelessly, typically via orthogonal frequency division multiplexing (OFDM) in a one-to-many relationship, to multiple receivers 14, such as ATSC 3.0 televisions. The receivers 14 may have both non-persistent memory 14A, such as certain types of solid-state RAM, and persistent memory 14B, such as flash. The one or more receivers 14 may communicate with one or more companion devices 16, such as remote controls, tablet computers, and mobile phones, via a short-range link 18, which is typically wireless and may be implemented by Bluetooth®, Bluetooth Low Energy, other near-field communication (NFC) protocols, infrared (IR), or the like.

[0028] One or more of the receivers 14 may also communicate, typically in a one-to-one relationship, with over-the-top (OTT) equipment 22 of the broadcast facility 10 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 both facilities 12, 22 of the broadcast facility 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 air via a tuned ATSC 3.0 television channel, and may also receive related content, including television, over the air (broadband). Note that the computer devices described in all figures herein may include some or all of the components shown for the various devices in FIGS. 1 and 2.

[0029]

[0013] Referring now to Figure 2, details of example components shown in Figure 1 can be seen. Figure 2 illustrates an example protocol stack that can be implemented using a combination of hardware and software. A broadcaster can transmit a hybrid service delivery that delivers one or more program elements 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)) using the ATSC 3.0 protocol stack, appropriately modified for the broadcaster side, shown in Figure 2. Figure 2 also illustrates an example stack, including hardware that can be embodied by a receiver.

[0030] 2 from the perspective of a broadcast station facility 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-level application layer 204. The application layer 204 can include one or more software applications written in, for example, HTML5 / Javascript, that operate in a runtime environment. Applications in the application stack 204 can include, but are not limited to, a linear TV application, an interactive services application, a companion screen application, a personalization application, an emergency alert application, and a usage reporting application. Typically, applications are embodied in software that represents elements of the viewer experience, including video coding, audio coding, and the runtime environment. As an example, applications can be provided that allow users to control dialogue, use alternate audio tracks, and control audio parameters such as normalization and dynamic range.

[0031] Below the application layer 204 is the presentation layer 206. The presentation layer 206 includes a broadcast audio-video playback device called a media processing unit (MPU) 208 on the over-the-air (OTA) side, which, when implemented in a receiver, decodes and plays over-the-air broadcast audio-video content on one or more displays and speakers. The MPU 208 is configured to present the International Organization for Standardization (ISO) Base Media File Format (BMFF) data representation 210 and video in High Efficiency Video Coding (HEVC) with audio in, for example, Dolby Audio Compression (AC-4) format. The ISO BMFF is a generic file structure for time-based media files, divided into "segments" and presentation metadata. Essentially, each file is a group of nested objects, each with its own type and length. The MPU 208 has access to a broadcast-side encrypted media extension (EME) / common encryption (CENC) module 212 to facilitate decryption.

[0032] 2 further shows that on the broadcast side, the presentation layer 206 can include signaling modules, including either a Moving 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 alternative advertisements.

[0033] 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 to decode and play audio-video content from the Internet. To this end, the DASH players 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.

[0034] The broadband side of the presentation layer 206, like the broadcast side, may contain NRT content in files 226 and signaling objects 228 that provide playback signaling.

[0035] Below the presentation layer 206 in the protocol stack is the session layer 230, which on the broadcast side includes either the MMTP protocol 232 or the ROUTE protocol 234. Note that the ATSC standard provides the option of using MPEG MMT for transmission, but this is not shown here.

[0036] The session layer 230 includes the HTTP protocol 236, which can be implemented on the broadband side as HTTP-secure (HTTP(S)). The broadband side of the session layer 230 may also employ an HTTP proxy module 238 and a service list table (SLT) 240. The SLT 240 contains a table of signaling information used to build a basic service list and provide bootstrap discovery of broadcast content. The "ROUTE signaling" table contains media presentation descriptions (MPDs) delivered over the User Datagram Protocol (UDP) by the ROUTE transport protocol.

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

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

[0039] Below the network layer 248 is a physical layer 250 that includes broadcast transmit / receive equipment 252 and computer network interface(s) 254 for communicating over the respective physical media associated with both sides. The physical layer 250 converts Internet Protocol (IP) packets for transmission over the associated media, adds forward error correction to enable error correction at the receiver, and may include modulation and demodulation modules to incorporate modulation and demodulation functions. The physical layer 250 converts bits into symbols for long-distance transmission and improved bandwidth efficiency. On the OTA side, the physical layer 250 typically includes a wireless broadcast transmitter that broadcasts data over the air using Orthogonal Frequency Division Multiplexing (OFDM), and on the OTT side, it includes a computer transmission component that transmits data over the Internet.

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

[0041] Typically, each receiver 14 includes a protocol stack that is complementary to the protocol stack of the broadcast station equipment.

[0042] Receiver 14 of FIG. 1 may include an Internet-enabled TV with an ATSC 3.0 TV tuner 256 (equivalent to a set-top box that controls a TV), as shown in FIG. 2. Receiver 14 may be an Android®-based system. Alternatively, receiver 14 may be implemented by a computerized Internet-enabled (“smart”) phone, a tablet computer, a notebook computer, a wearable computing device, or the like. Nevertheless, 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).

[0043] Accordingly, receiver 14 may be established with some or all of the components shown in FIG. 1 to implement such principles. For example, receiver 14 may include one or more displays 258, which may or may not be implemented with high-definition or ultra-high-definition “4K” or higher flat screens and may be touch-enabled to receive user input signals via touch on the display. Receiver 14 may also include one or more speakers 260 for outputting audio in accordance with present principles and at least one additional input device 262, such as an audio receiver / microphone, for inputting audible commands to receiver 14, e.g., to control receiver 14. An 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, or a PAN, under the control of one or more processors 266. Thus, interface 264 may 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. Interface 264 can 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, a powerline, or a Multimedia over Coax Alliance (MoCA). It should be understood that processor 266 controls receiver 14 to implement the present principles, including other elements of receiver 14 described herein, such as controlling display 258 to present images and receive input. Furthermore, network interface 264 can be, for example, a wired or wireless modem or router, or other suitable interface, such as a wireless telephone transceiver or Wi-Fi transceiver as described above.

[0044] 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 to present audio from receiver 14 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 separate or integrated set-top box or satellite receiver. Alternatively, the source may be a game console or disc player.

[0045] Receiver 14 may further include one or more computer memories 270, such as non-transitory, disk-based or solid-state storage, in some cases embodied as a stand-alone device within the receiver chassis, or as a personal video recorder (PVR) or video disc player for playing audio-video (AV) programs, or as removable storage media, either internal or external to the receiver chassis. Also, in some embodiments, receiver 14 may 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 geographic location information, for example, from at least one satellite or cellular telephone tower, and provide this information to processor 266 and / or determine the altitude at which receiver 14 is located with processor 266. However, it should be understood that other suitable position receivers other than a cellular telephone receiver, a GPS receiver, and / or an altimeter may be used in accordance with the present principles to determine the location of receiver 14, for example, in all three dimensions.

[0046] Continuing with the description of receiver 14, in some embodiments, receiver 14 may include one or more cameras 274, which may include one or more of a thermal imaging camera, a digital camera such as a webcam, and / or a camera integrated into receiver 14 and controllable by processor 266, for collecting photographs / 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 for communicating with other devices using Bluetooth® and / or NFC technology, respectively. An exemplary NFC element may be a radio frequency identification (RFID) element.

[0047] Additionally, receiver 14 may include one or more auxiliary sensors 278 (such as motion sensors, such as an accelerometer, gyroscope, cyclometer, or magnetic sensor, and combinations thereof), an infrared (IR) sensor for receiving IR commands from a remote control device, an optical sensor, a speed and / or cadence sensor, a gesture sensor (for detecting gesture commands), etc., to provide input to processor 266. 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.

[0048] Companion device 16 may include some or all of the elements shown in connection with receiver 14 above.

[0049] 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 any other convenient method as would be understood by one of ordinary skill in the art. The software instructions, if employed, may be embodied in a non-transitory device such as a CD-ROM or flash drive. Alternatively, the software code instructions may be embodied in a transitory configuration such as a radio or optical signal, or via download over the internet.

[0050] Referring to FIG. 3, a ROUTE session 300 is established at an ATSC 3.0 transmitter to deliver Layered Coding Transport (LCT) packets 302. These packets can carry source objects or FEC repair data. In a top-down approach, the source protocol consists of one or more LCT channels, each carrying a delivery object and, optionally, object metadata 304. The metadata can be delivered statically in signaling metadata, dynamically as a composite object in entity mode, or as an LCT extension header in the packet header. Packets are transported over ROUTE using a specific FEC scheme 306 that allows flexible fragmentation of objects on any byte boundary. Furthermore, delivery objects can be FEC protected individually or in bundles 308. In either case, the bundled objects are encoded, and repair symbols are delivered over the ROUTE session via UDP / IP 310. The received repair symbols, by themselves or in combination with the received source packets, allow for the reconstruction of the delivery object bundle. Note that one or more repair flows can be created, each with different characteristics, for example to support different latency requirements, different protection requirements, etc.

[0051] Basic receiver operation is shown in Figure 4. A receiver 400, such as a suitably configured receiver herein, receives packets 402 and filters them appropriately. The receiver recreates delivery objects 404 from the ROUTE session and each LCT channel involved. The delivery objects are passed to an appropriate handler 406 for further data processing for use by an application or media player 408.

[0052] Please refer now to Figure 5. A file is divided into a number of partitions 500. A first partition P1 represents a first data sequence in the file, a second partition P2 represents the next subsequent data sequence in the file, and so on. n are arranged for transmission in the order defined by the file.

[0053] 5, the data packets 502 within each partition 500 are not ordered, but rather are arranged out of order (OOO) (e.g., by random distribution of packets within the partition). Thus, for example, packet #8 in the first partition P1 is first, followed by packet #2, then packet #20, then packet #3, and so on until all packets in the first partition P1 are arranged OOO (out of order).

[0054] Figure 6 shows the transmitter logic according to Figure 5. Starting at state 600, the number and / or size of partitions of a file requested to be transmitted over the air using, for example, ATSC 3.0 technology is determined. Moving to state 602, the file is split into multiple partitions.

[0055] Proceeding to state 604, within each partition, the data packets of the partition are ordered (or reordered) so that they are out of order (OOO). In one example, packets are randomly ordered within the partition to which they belong. Ending at state 606, the partition is transmitted to one or more receivers in the correct partition order, but with each packet out of order (OOO).

[0056] 7 shows the receiver-side logic. Starting at state 700, the receiver first receives the first partition of the transmitted file, which is stored in non-persistent memory. In block 702, packet information from the ATSC 3.0 signaling can be used to reorder the packets in the received partition into the correct order. Note that reordering can occur later, after the partition has been transferred to persistent memory.

[0057] State 704 indicates receiving the next subsequent partition into non-persistent memory, i.e., although multiple partitions can reside in non-persistent memory simultaneously, typically not all partitions will reside in non-persistent memory at the same time, as partitions are offloaded to persistent memory as the file is being received, as described below.

[0058] State 706 indicates that errors in the packets can be corrected, if necessary. In this example, the correction is performed while the partitions are still in non-persistent memory; however, it should be understood that error correction can occur after the partitions have been offloaded to persistent memory in states 708 (for a first partition) and 712 (for a second partition). Next, in state 710, one or more subsequent partitions of the file are received in non-persistent memory, and the process continues this loop 714 of receiving partitions of the file into non-persistent memory, offloading them to persistent memory, and continuing to receive subsequent partitions into non-persistent memory. Part or all of the file can be displayed or provided for use by another application.

[0059] See Figures 8 and 9. The partitioning equations described herein can be built on top of RaptorQ AL-FEC to achieve incremental repair while the next packet partition is being received. This involves re-encoding the original AL-FEC OTI parameters (defined in RFC 6330) to support this partitioning of the source blocks. In this way, a receiver can support the reception and repair of very large files of OOO (out-of-order) data in RAM. The size of this file is limited only by the available FLASH memory and the size of the OOO (out-of-order) partitions, as well as the repair data and intermediate symbols required in RAM to run the RaptorQ repair algorithm.

[0060] A number of source blocks 800 of the file are interleaved with repair symbols 801. As will be explained briefly below, each partition contains a number of source blocks.

[0061] As shown in Figure 8, a file contains Z source blocks. As shown in the # source blocks equation in Figure 8, Z defines an upper bound for F / T. maxis greater than or equal to k divided by max (shown as 806 in Figure 8) represents the number of symbols in each source block, T (shown as 804 in Figure 8) is the number of bytes in each symbol, and F (shown as 802 in Figure 8) is the size of the file.

[0062] In one non-limiting example, between 5 and 25 percent of the number of symbols in a source block can be repair symbols. In a particularly specific embodiment, 10 percent of the number of symbols in a source block can be repair symbols.

[0063] Figure 9 provides additional disclosure. As shown in Figure 9, at least some partitions 900 are l source blocks (shown as 902 in FIG. 9 ), l is the upper limit of Z, n (shown as 904 in Figure 9) divided by P n is the total number of partitions in the file, while at least one partition (shown as 906 in Figure 9) is s Contains Z source blocks s is the lower limit of Z n Therefore, some partitions contain a different number of source blocks than other partitions.

[0064] Referring now to Figure 10, the top bar represents source block data symbols 1000 interleaved with repair symbols 1002. Both non-persistent memory 1004 and persistent memory 1006 are shown in Figure 10. For devices that include fast block reads from persistent flash, as shown at 1008 in Figure 10, incomplete data or data that does not contain sufficient repair data can be saved 1010 to flash (an example of persistent memory) along with a repair 1012 and / or a record of the gaps in the data. This incomplete data can be retrieved the next time a partition appears around the carousel. This maximizes the chances that the partition will be completed. In this case, the incomplete partition can be deleted from non-persistent memory.

[0065] ATSC 3.0 signaling, such as File Delivery Table (FDT) instance extensions, can include the following elements to support this technology: This signaling allows a receiver to evaluate whether it has the RAM memory capacity to receive large files that are delivered out of order (OOO) but are also partitioned. Additional signaling indicating the percentage of repair data is also included to complete this memory requirement evaluation.

[0066] @maxCacheMemory - If the FDT Instance Order attribute is false, this optional 32-bit unsigned integer attribute represents the maximum memory required to hold received file data in cache at any one time. This allows the receiver to evaluate its ability to receive data on non-persistent storage before block-transferring a complete block of contiguous data to persistent storage, or to repair data blocks if repairFlow is used. If not present, the receiver should use FDT-Instance.maxTransportSize, LCT header transfer length, or entity mode content length. If the FDT Instance Order attribute is true, data is not sent out of order.

[0067] 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]

[0068] 10 Broadcasting Station Equipment 12 Over-the-air (OTA) equipment 14 Receiver 14A Non-persistent memory 14B Persistent Memory 16 Companion Devices 18 Links 20 Links 22 Over-the-top (OTT) equipment 200 processors 202 Storage medium 204 Application Layer 206 Presentation Layer 208 MPU 210 ISO BMFF Data Representation 212 EME / CENC module 214 MMT-specific signaling 216 ROUTE-specific signaling 218 NRT files 220 DASH Player / Decoder 222 EME / CENC module 224 DASH segments 226 NRT files 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 UDP 246 Transmission Control Protocol (TCP) 248 Network Layer 250 Physical layer 252 Broadcast transmitting / receiving equipment 254 Computer Network Interface 256 ATSC3.0 TV Tuner 258 display 260 speakers 262 Input Device 264 Network Interface 266 processors 268 input ports 270 memory 272 Position or location receivers 274 Camera 276 Bluetooth® transceiver 278 Auxiliary Sensor 280 IR sensor 300 ROUTE Sessions 302 LCT packets 304 Object Metadata 306 FEC Scheme 308 Bundles 310 UDP / IP 400 receiver 402 packets 404 Delivery Object 406 Handler 408 Application or Media Player 500 partitions 502 Data Packet 600 Determine partition size 602 Split files into partitions 604 Reorder packets within each partition 606 Send partitions in order, with packets within each partition being OOO (out of order) 700 Receive partition N into non-persistent memory 702 Reorder packets per signaling 704 Receive partition N+1 into non-persistent memory 706 Error Correction 708 P N to persistent memory 710 Receive partition N+2 into non-persistent memory 712 P N+1 to persistent memory 714 Loops 800 source blocks 802 F (file size) 804 T (number of bytes in each symbol) 806k max (number of symbols in each source block) 900 partitions 902 Z l source blocks 904 Z l (The upper limit of Z is P n (divided by 906 Partition 1000 Data Symbol 1002 Repair symbol 1004 Non-persistent memory 1006 Persistent Memory 1008 For devices that include fast block reads from persistent flash, incomplete data, or data that does not contain sufficient repair data, can be stored in flash along with a record of the gaps in the data. This incomplete data can be retrieved the next time the partition appears around the carousel. This maximizes the chances that the partition will be completed. In this case, the incomplete partition can be removed from non-persistent memory. 1010 Save 1012 Repair

Claims

1. In digital television, Dividing at least one file into a plurality of partitions; within each partition, ordering the packets of said partition out of order (OOO); transmitting said partitions in order, with each packet being out of order (OOO), to at least one receiver; A method comprising:

2. 2. The method of claim 1, wherein the method includes interleaving a plurality of source blocks of the file with repair symbols, each partition including a plurality of source blocks.

3. The file contains Z source blocks, where Z is the upper bound of F / T. max greater than or equal to the upper limit of the division by k max 3. The method of claim 2, wherein T represents the number of symbols in each source block, T is the number of bytes in each symbol, F is the size of the file, and upper bound represents rounding up to the nearest integer.

4. At least some partitions are l number of source blocks, l The upper limit of Z is P n is equal to P divided by n The method of claim 3 , wherein: comprises a total number of partitions.

5. At least one partition is s number of source blocks, s The lower limit of Z is P n 5. The method of claim 4, wherein the lower bound represents rounding down to the nearest integer.

6. 10. The method of claim 1, wherein the digital television comprises an Advanced Television Systems Committee (ATSC) 3.0 system.

7. A digital television device, at least one receiver configured to receive digital television from a digital television transmitter system, the receiver including at least one processor programmed with instructions, the instructions comprising: receiving, into a non-persistent memory, at least some of a plurality of partitions of at least one file, each partition including packets in out-of-order (OOO); ordering said packets in correct order; transmitting at least one partition in the non-persistent memory to the persistent memory; receiving an additional partition into the non-persistent memory; The purpose is to A digital television device characterized by:

8. 8. The digital television device of claim 7, wherein the digital television receiver comprises an Advanced Television Systems Committee (ATSC) 3.0 receiver.

9. 8. A digital television apparatus as claimed in claim 7, characterized in that the source blocks of the file are interleaved with repair symbols, and each partition contains multiple source blocks.

10. The file contains Z source blocks, where Z is the upper bound of F / T. max greater than or equal to the upper limit of the division by k max 10. The digital television apparatus of claim 9, wherein ∑ represents the number of symbols in each source block, T is the number of bytes in each symbol, and F is the size of the file.

11. At least some partitions are l number of source blocks, l The upper limit of Z is P n is equal to P divided by n 11. The digital television apparatus of claim 10, wherein includes the total number of partitions.

12. At least one partition is s number of source blocks, s The lower limit of Z is P n 12. The digital television apparatus of claim 11, wherein the frequency is equal to the frequency divided by the frequency.

13. 8. The digital television apparatus of claim 7, wherein the instructions are executable to correct errors in the packets while the packets reside in non-persistent memory.

14. 8. The digital television apparatus of claim 7, wherein the instructions are executable to correct errors in the packets while the packets reside in persistent memory.

15. 8. The digital television apparatus of claim 7, wherein the instructions are executable to present the file.

16. A digital television device, at least one transmitter including at least one processor programmed with instructions, said instructions causing said processor to: Splitting at least one file into multiple partitions, Within each partition, the packets of said partition are ordered out of order (OOO); transmitting the partitions in order, with each packet being out of order (OOO), to at least one receiver; The purpose is to configure the A digital television device characterized by:

17. 17. The digital television apparatus of claim 16, wherein the instructions are executable to interleave multiple source blocks of the file with repair symbols, each partition including multiple source blocks.

18. The file contains Z source blocks, where Z is the upper bound of F / T. max greater than or equal to the upper limit of the division by k max 18. The digital television apparatus of claim 17, wherein ∑ represents the number of symbols in each source block, T is the number of bytes in each symbol, and F is the size of the file.

19. At least some partitions are l number of source blocks, l The upper limit of Z is P n is equal to P divided by n 20. The digital television apparatus of claim 18, wherein includes the total number of partitions.

20. At least one partition is s number of source blocks, s The lower limit of Z is P n 20. The digital television apparatus of claim 19, wherein the frequency is equal to the frequency divided by the frequency.

Images