Improving Robustness by Using Application Layer Early Error Correction (AL-FEC) in an ATSC3 Receiver

Description

/ 22 Improving Robustness by Using Application Layer Early Error Correction (AL-FEC) in an ATSC3 Receiver FIELD

[001] This request relates to technical advances necessarily rooted in computer technology and directed toward digital television and, more particularly, to the Advanced Television Systems Committee (ATSC) 3.0. BACKGROUND

[002] The Advanced Systems Committee standards group ATSC 3.0 is a set of over a dozen industry technical standards, as indicated in A / 300, to provide the next generation of broadcast television. ATSC 3.0 supports the delivery of a wide range of television services, including televised video, interactive services, non-real-time data delivery, and personalized advertising, to a large number of receiving devices, from ultra-high-definition TVs to cordless phones. ATSC 3.0 also plans for coordination between broadcast content (referred to as "over-the-air" (via Hertzian waves)) and related broadband-delivered content and services (referred to as "over-the-top" (via the open Internet)). 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 related technical standard.

[003] As understood in this document, ATSC 3.0 can be used to provide data to mobile receivers, such as providing maps or operating manuals to moving vehicles. Error correction techniques can be applied to improve data reception. SUMMARY

[004] As understood in this document, the advance correction Petition 870260076490, dated 07 / 31 / 2026, page 10 / 31 / 22, Application Layer Forward Error Correction (AL-FEC) in ATSC3 is specified in the ATSC A / 331 standard to use the error correction technique described in RFC 6330 (“RaptorQ”) for packet data repair when data repair is desirable. Data repair is advantageous in data broadcasting where file delivery is especially sensitive to packet loss. Error hiding in video is well-established, but file delivery requires that all packets be correctly received to complete file reception. Large file delivery is of interest in many use cases, including when intended for platforms that do not have a large amount of CPU processing speed.Repairing Raptor-Q packets is computationally intensive, and the present principles address this requirement by splitting files into smaller pieces that can be processed separately.

[005] Each supplied collection of packets (file partition) may have associated repair bytes, but if the repair is incorrect, the ATSC3 receiver of the data may not be aware that this data is incorrect unless a single global MD5 checksum is included in the FDT-Instance signaling within the S-TSID table. This can cause an incorrect repair operation or no repair operation of the file partition, which can result in significant delays in the correct reception of large files. For NRT data provisioning, a single incorrect bit of data is enough to render it unusable, suggesting that this checksum is critical for correcting file partitions when they are received and do not expect the data (file partition) to be provided again by file carousels.However, these principles recognize that a single global checksum provides minimal information about the location of bad data and therefore all data will need to be discarded and the recipient will need to start again. Petition 870260076490, dated 07 / 31 / 2026, page 11 / 31 / 22 reception (assuming that the data, as is typical in emission scenarios, is in a carousel) of that specific file partition.

[006] Accordingly, the present principles apply a checksum to each source block (file partition) to minimize the effort required by a receiver to correct packet errors / losses, improving the probability of success after further attempts in a carousel, where sufficient repair blocks may not always be available for each source block. This is especially true with large files. Furthermore, the receiver can supplement missing packets and bad source blocks via a TCP / IP connection when a server and the connection to the server are available, requesting repair packets while minimizing data overhead on the unicast server.

[007] To improve robustness, it is therefore useful for the receiver to receive a checksum for each source block, allowing it to discard only a portion of the data as defined by the length of that source block in the AL-FEC parameters.

[008] A list of checksums can be included and correlated, for each checksum, with the source block to which it applies. In one embodiment, the list of checksums is included in the RepairFlow element of the Service Transport Session Instance Description (S-TSID), since only the RepairFlow element and AL-FEC provide the division of data into source blocks and have no meaning outside the RepairFlow element.

[009] In one embodiment, a transmitter provides a 32-bit Cyclic Redundancy Check (CRC) checksum (shortest reliable checksum) for each source block in the S-TSID / RepairFlow element when AL-FEC is supported. A receiver verifies the checksum of each source block and, if invalid, Petition 870260076490, dated 07 / 31 / 2026, p. 12 / 31 / 22, seeks data from the source block of a server (as a location specified in another flag) or waits to receive the data again in an emission carousel.

[0010] These principles also apply to the provision of files in other multicast distribution methods where RFC 6330 (RAPTOR-Q) is used.

[0011] Accordingly, in data broadcasting, one method includes computing the respective 32-bit Cyclic Redundancy Code (CRC) checksums for each source block of a digital file. The method further includes transmitting the source blocks and a list of checksums to at least one receiver using ATSC 3.0 digital television transmission. The list is included in a RepairFlow element of a Service Transport Sessions (S-TSID) instance description.

[0012] In some embodiments, the method may further include, on an ATSC 3.0 data broadcast receiver, applying a checksum to each source block to improve the probability of success after further attempts in a broadcast carousel. This may be done at least in part by receiving the source blocks and the list of checksums, verifying each checksum, and discarding source blocks for which the respective checksums are not verified. Source blocks for which the respective checksums are verified are not discarded. The method may further include, for source blocks with unverified checksums, searching for the source blocks from at least one server having a network location specified in the S-TSID or waiting to receive the source blocks again in a broadcast carousel, or both.

[0013] In some examples, the verification of each checksum may include recomputing the checksum using contents of Petition 870260076490, dated 07 / 31 / 2026, page 13 / 31 / 22 respective source block and the comparison of the newly computed checksum with the checksum for the source block as received in the list.

[0014] In another aspect, a data broadcasting device includes at least one receiver configured to receive digital television from a digital television transmitter system. The receiver, in turn, includes at least one processor programmed with instructions to receive multiple source blocks from at least one file and a list of corresponding checksums associated with the source blocks from at least one digital television transmitter. The processor is configured to verify each checksum and discard source blocks for which the corresponding checksums are not verified. Source blocks for which the corresponding checksums are verified are not discarded.For source blocks with unverified checksums, the instructions are executable by fetching the source blocks from at least one server having a network location specified in the digital television signaling or by waiting to receive the source blocks again in a broadcast carousel, or either fetching the source blocks from at least one server and waiting to receive the source blocks again in a broadcast carousel.

[0015] In another aspect, a digital television set includes at least one transmitter which, in turn, includes at least one processor programmed with instructions in order to configure the processor to compute the respective checksums for each source block of a digital file and transmit the source blocks and a list of the checksums to at least one receiver using digital television transmission.

[0016] The details of the present application, both with regard to its structure and its operation, can be better understood by consulting the attached drawings, in which the same reference numbers refer to parts. Petition 870260076490, dated 07 / 31 / 2026, page 14 / 31 / 22 identical. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 illustrates an Advanced Television Systems Committee (ATSC) 3.0 system; Figure 2 illustrates components of the devices shown in Figure 1; Figure 3 illustrates an example architecture on the transmitter side; Figure 4 illustrates an example architecture on the receiver side; Figure 5 illustrates the example transmitter logic consistent with the present principles; and Figure 6 illustrates the example receiver logic consistent with the present principles. DETAILED DESCRIPTION

[0018] This disclosure relates to technical advances in digital television, such as in the Advanced Television Systems Committee (ATSC) 3.0 television. In the present document, an example system may include ATSC 3.0 source components and client components connected via transmission and / or through a network so that data can be exchanged between the client and ATSC 3.0 source components. Client components may include one or more computing devices, including portable televisions (e.g., smart TVs, Internet-enabled TVs), portable computers such as laptops and tablets, and other mobile devices, including smartphones and additional examples discussed below. These client devices may operate in a variety of operating environments.For example, some client computers might use, for instance, Microsoft operating systems, or a Unix operating system, or operating systems produced by Apple Computer or Google, such as. Petition 870260076490, dated 07 / 31 / 2026, page 15 / 31 / 22 Android®. These operating environments can be used to run one or more web browsing programs, such as a browser made by Microsoft, Google, or Mozilla, or another browser program that can access websites hosted by the internet servers discussed below.

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

[0020] ATSC 3.0 source components may include broadcast components and servers and / or gateways that may include one or more processors executing instructions that configure the source components to broadcast and / or transmit data over a network such as the Internet. A client component and / or a local ATSC 3.0 source component may be instantiated by a video game console, such as a Sony PlayStation®, a personal computer, etc.

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

[0022] As used herein, instructions refer to steps implemented by a computer for processing information in the system. Instructions can be implemented in software, firmware, or hardware and include any type of programmed step performed by system components.

[0023] A processor can be single-chip or multi-chip, capable of executing logic through multiple lines, such as address lines, data lines, and control lines, as well as registers and shift registers.

[0024] The software modules described through flowcharts and Petition 870260076490, dated 07 / 31 / 2026, page 16 / 31 / 22. User interfaces here may include various subroutines, procedures, etc. Without limiting disclosure, the logic declared to be executed by a particular module may be redistributed to other software modules and / or combined together into a single module and / or made available in a shareable library. Although the flowchart format may be used, it must be understood that software may be implemented as a state machine or other logical method.

[0025] The principles described herein can be implemented as hardware, software, firmware, or combinations thereof; therefore, illustrative components, blocks, modules, circuits, and steps are shown in terms of their functionality.

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

[0027] The functions and methods described below, when implemented in software, may be written in an appropriate language, such as, but not limited to, Hypertext Markup Language (HTML)-5, Java® / Javascript, C#, or C++, and may be stored or transmitted via a computer-readable storage medium, such as Random Access Memory (RAM), Read-Only Memory (ROM), or Electrically Erasable Programmable Read-Only Memory (EEPROM). Petition 870260076490, dated 07 / 31 / 2026, page 17 / 31 / 22 A connection can be a computer-readable medium (CD-ROM), read-only memory, or other optical disc storage such as digital versatile disc (DVD), magnetic disk storage, or other magnetic storage devices, including removable pen drives, etc. These connections can include, for example, connected cables including fiber optic and coaxial wires, as well as digital subscriber line (DSL) and twisted-pair wires.

[0028] The components included in one embodiment may be used in other embodiments in any appropriate combination. For example, any of the various components described herein and / or depicted in the Figures may be combined, exchanged, or excluded from other embodiments.

[0029] “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 alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.

[0030] Moving on to Figure 1, an example of an ATSC 3.0 source component is labeled as “transmitting equipment” 10 and may include “over-the-air” (OTA) equipment 12 for wireless transmission, typically via orthogonal frequency division multiplexing (OFDM) in a one-to-many relationship, of television data to multiple receivers 14, such as ATSC 3.0 televisions. One or more receivers 14 may communicate with one or more complementary devices 16, such as remote controls, tablets, mobile phones, and the like, over a short range, typically wireless link 18 which may be implemented by Bluetooth®, Bluetooth Low Energy, another Near Field Communication (NFC) protocol, infrared (IR), etc.

[0031] Likewise, one or more of the receivers 14 can communicate, Petition 870260076490, dated 07 / 31 / 2026, p. 18 / 31 / 22 via a wired and / or wireless network link 20, such as the Internet, with “over-the-top” (OTT) equipment 22 from the transmitting equipment 10 typically in a one-to-one relationship. The OTA equipment 12 may be co-located with the OTT equipment 22, or the two sides 12, 22 of the transmitting equipment 10 may be remote from each other and may communicate with each other by appropriate means. In either case, a receiver 14 may receive ATSC 3.0 television OTA signals via a television channel tuned to ATSC 3.0 and may also receive related content, including television, OTT (broadband). Note that the computerized devices described in all figures in this document may include some or all of the components shown for various devices in Figures 1 and 2.

[0032] With regard now to Figure 2, details of example components shown in Figure 1 can be seen. Figure 2 illustrates an exemplary protocol stack that can be implemented through a combination of hardware and software. Using the ATSC 3.0 protocol stack shown in Figure 2 and modified as appropriate for the sender side, senders can deliver hybrid service in which one or more program elements are delivered via a computer network (herein referred to as “broadband” and “over-the-top” (OTT)) as well as via a wireless broadcast (herein referred to as “broadcast” and “over-the-air” (OTA)). Figure 2 also illustrates an example stack with hardware that can be incorporated by a receiver.

[0033] Revealing Figure 2 in terms of emitting equipment 10, one or more processors 200 can be implemented accessing one or more computer storage media 202, such as any memories or storage described herein, to provide one or more software applications in a higher-level application layer 204. The application layer 204 may include one or more software applications. Petition 870260076490, dated 07 / 31 / 2026, page 19 / 31 / 22 written in, for example, HTML5 / Javascript running in a runtime environment. Without limitation, applications in the 204 application stack may include linear TV applications, interactive service applications, companion screen applications, personalization applications, emergency alert applications, and usage reporting applications. Typically, applications are embedded in software that represents the elements the viewer experiences, including video encoding, audio encoding, and the runtime environment. As an example, an application may be provided that enables a user to control dialogue, use alternative audio tracks, control audio parameters such as normalization and dynamic range, and so on.

[0034] Below the application layer 204 there is a presentation layer 206. The presentation layer 206 includes, on the broadcast (OTA) side, broadcast audio / video playback devices referred to as Media Processing Units (MPUs) 208 which, when implemented in a receiver, decode and reproduce, on one or more displays and loudspeakers, wireless broadcast audio / video content. The MPU 208 is configured to present data representations 210 of the International Organization for Standardization (ISO) Base Media File Format (BMFF) and video in High Efficiency Video Coding (HEVC) with audio in, e.g., Dolby audio compression format (AC-4). BMFF ISO is a general file structure for time-based media files divided into “segments” and presentation metadata.Each of the files is essentially a collection of nested objects, each with a type and a length. To facilitate decryption, MPU 208 can access an Encrypted Media Extension (EME) / Common Encryption (CENC Common Encryption) module 212 on the issue side. Petition 870260076490, dated 07 / 31 / 2026, page 20 / 31 / 22

[0035] Figure 2 further illustrates that, on the broadcast side, the presentation layer 206 may include signaling modules, including the Media Transport Protocol (MTP) signaling module of the MPEG Motion Pictures Expert Group (MMTP) 214 or real-time object provisioning via the one-way transport signaling module (ROUTE) 216 to provide non-real-time (NRT) content 218 that is accessible to the application layer 204. NRT content may include, but is not limited to, stored replacement announcements.

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

[0037] As was the case on the broadcast side, the broadband side of the presentation layer 206 can include NRT content in the files 226 and can also include signaling objects 228 to provide playback signaling.

[0038] Below the presentation layer 206 in the protocol stack, there is a session layer 230. The session layer 230 includes, on the transmission side, the MMTP protocol 232 or the ROUTE protocol 234. Note that the ATSC standard provides an option to use MMT MPEG for transport, although it is not shown here.

[0039] On the transmission side, the session layer 230 includes the HTTP protocol 236 which can be implemented as secure HTTP (HTTP(S) - HTTP Petition 870260076490, dated 07 / 31 / 2026, p. 21 / 31 / 22 Secure). The transmission side of the session layer 230 may also employ an HTTP proxy module 238 and a Service List Table (SLT) 240. The SLT 240 includes a signaling information table that is used to construct a listing of basic services and provide bootstrap discovery of the transmission content. Media Presentation Descriptions (MPDs) are included in the “ROUTE Signaling” tables provided via the User Datagram Protocol (UDP) by the ROUTE transport protocol.

[0040] To establish low-latency and loss-tolerant connections, there is a transport layer 242 below the session layer 230 in the protocol stack. On the transmission side, the transport layer 242 uses UDP 244 and, on the broadband side, Transmission Control Protocol (TCP) 246.

[0041] The non-limiting example protocol stack shown in Figure 2 also includes a network layer 248 below the transport layer 242. The network layer 248 uses Internet Protocol (IP) on both sides for IP packet communication, with multicast delivery being typical on the transmission side and unicast being typical on the broadband side.

[0042] Below network layer 248, there is physical layer 250 which includes transmission / reception equipment 252 and computer network interface(s) 254 for communication on the respective physical media associated with the two sides. Physical layer 250 converts Internet Protocol (IP) packets to be suitable for transport over the relevant medium and may add error-predicting functionality to enable error correction at the receiver, as well as contain modulation and demodulation modules to incorporate modulation and demodulation functionalities. This converts bits into symbols for long-distance transmission. Petition 870260076490, dated 07 / 31 / 2026, page 22 / 31 / 22 distance, as well as to increase bandwidth efficiency. On the OTA side, physical layer 250 typically includes a wireless broadcast transmitter to transmit data in a wireless mode using orthogonal frequency division multiplexing (OFDM), while on the OTT side physical layer 250 includes computer transmission components to send data over the Internet.

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

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

[0045] A receiver 14 in Figure 1 may include, as shown in Figure 2, an Internet-enabled TV with an ATSC 3.0 TV tuner (equivalently, a set-top box (television converter) controlling a TV) 256. The receiver 14 may be an Android®-based system. Alternatively, the receiver 14 may be implemented by an Internet-enabled computerized phone, a tablet, a notebook, a wearable computerized device, and so forth. In any case, it must be understood that the receiver 14 and / or other computers described herein are configured to perform the present principles (e.g., communicate with other devices to perform the present principles, execute the logic described herein, and perform any other functions and / or operations described herein).

[0046] Accordingly, to realize these principles, receiver 14 can be made up of some or all of the components shown in Figure 1. For example, receiver 14 can include one or more displays 258 Petition 870260076490, dated 07 / 31 / 2026, p. 23 / 31 / 22, which may be implemented by a high-definition or ultra-high-definition “4K” or higher flat screen and which may or may not be touch-activated to receive user input signals via touches on the display. The receiver 14 may also include one or more speakers 260 for audio output in accordance with the present principles and at least one additional input device 262, such as, for example, a microphone / audio receiver for, for example, entering audible commands into the receiver 14 in order to control the receiver 14. The example receiver 14 may further include one or more network interfaces 264 for communication through at least one network, such as the Internet, a WAN, a LAN, a PAN, etc., under the control of one or more processors 266.Thus, interface 264 can be, without limitation, a Wi-Fi transceiver, which is an example of a wireless computer network interface, as well as, but not limited to, a mesh network transceiver. Interface 264 can be, without limitation, a Bluetooth® transceiver, a Zigbee® transceiver, an Infrared Data Association (IrDA) transceiver, a Wireless USB transceiver, a Wired USB transceiver, a Wired LAN transceiver, a Powerline transceiver, or a MoCA (Multimedia over Coax Alliance) transceiver. It is important to understand that processor 266 controls receiver 14 to perform the present principles, including the other elements of receiver 14 described herein, such as, for example, controlling the display 258 to display images on it and receiving input from it. Furthermore, note that network interface 264 can be, for example... e.g., a wired or wireless modem or router, or other suitable interface, such as, for example, a wireless telephony transceiver or Wi-Fi transceiver, as mentioned above, etc.

[0047] 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 (using a wired connection) to another Petition 870260076490, dated 07 / 31 / 2026, page 24 / 31 / 22 CE device, and / or a headphone port for connecting headphones to receiver 14 for audio presentation from receiver 14 to a user through headphones. For example, input port 268 can be connected in a wired or wireless manner to a cable or satellite audio / video content source. Thus, the source can be a separate or integrated set-top box or a satellite receiver. Alternatively, the source can be a video game console or disc player.

[0048] The receiver 14 may also include one or more computer memories 270, such as disk-based or solid-state storage devices that are not transient signals, in some cases incorporated into the receiver chassis as stand-alone devices or as a personal video recording (PVR) device or video disc player, either internal or external to the receiver chassis, for playing audio / video (AV) programs or as removable memory media. Similarly, in some embodiments, the receiver 14 may include a position or location receiver 272, such as, but not limited to, a cellular phone receiver, a global positioning satellite (GPS) receiver and / or an altimeter, which is configured to, for example,, receive geographic position information from at least one satellite or cell phone tower and provide the information to processor 266 and / or determine an altitude at which receiver 14 is positioned in conjunction with processor 266. However, it must be understood that another suitable position receiver other than a cell phone receiver, GPS receiver and / or altimeter may be used in accordance with these principles to determine the location of receiver 14 in, e.g. (for example, all three dimensions).

[0049] Continuing 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 Petition 870260076490, dated 07 / 31 / 2026, p. 25 / 31 / 22 controllable by processor 266 to gather photos / images and / or video in accordance with these principles. In receiver 14, a Bluetooth® transceiver276 or other Near Field Communication (NFC) element may also be included for communication with other devices using Bluetooth® and / or NFC technology, respectively. An example of an NFC element could be a Radio Frequency Identification (RFID) element.

[0050] Furthermore, the receiver 14 may include one or more auxiliary sensors 278 (such as a motion sensor, such as an accelerometer, gyroscope, cyclometer, or a magnetic sensor and combinations thereof), an infrared (IR) sensor for receiving IR commands from a remote control, an optical sensor, a speed and / or cadence sensor, a gesture sensor (for perceiving gesture commands), and so forth, providing input to the processor 266. An IR sensor 280 may be provided for receiving commands from a wireless remote control. A battery (not shown) may be provided for powering the receiver 14.

[0051] The complementary device 16 may incorporate some or all of the elements shown in relation to the receiver 14 described above.

[0052] The methods described herein may be implemented as software instructions executed by a processor, suitably configured application-specific integrated circuits (ASICs) or field-programmable gate array (FPGA) modules, or any other convenient manner as would be perceived by those skilled in the art. When employed, the software instructions may be incorporated into a non-transient device, such as a CD-ROM or a Flash drive. Alternatively, the software code instructions may be incorporated into a transient arrangement, such as a radio or optical signal, or via an Internet download.

[0053] Now with regard to Figure 3, a ROUTE session is established. Petition 870260076490, dated 07 / 31 / 2026, page 26 / 31 / 22 300 in an ATSC 3.0 transmitter that delivers Layered Coding Transport (LCT) packets 302. These packets can carry source objects or FEC repair data. From a top-down approach, a source protocol consists of one or more LCT channels, each carrying delivery objects and optionally object metadata 304. Metadata can be statically provided in signaling metadata or can be dynamically provided, either as a composite object in entity mode or as LCT extension headers in packet headers. Packets are loaded into ROUTE using a specific FEC scheme 306 that allows flexible fragmentation of the object into arbitrary byte boundaries. Furthermore, delivery objects can be FEC-protected, individually or in clusters 308. In both cases, the clustered object is encoded and repair symbols are provided via a ROUTE session over UDP / IP 310.Individually, or in combination with any received source packets, the received repair symbols allow the recovery of supply object groupings. Note that one or more repair streams can be generated, each with different characteristics, for example, to support different latency requirements, different protection requirements, etc.

[0054] Figure 4 illustrates the basic operation of the receiver. In this document, a 400 receiver, like any appropriately configured receiver, receives 402 packets and filters them accordingly. From the ROUTE session and each contained LCT channel, the receiver regenerates the 404 supply objects of the ROUTE session and each contained LCT channel. The supply objects are, in turn, passed to the appropriate 406 handler for further data processing for use by an application or a 408 media player.

[0055] Now refer to Figure 5. Starting at block 500, an ATSC 3.0 or other suitable digital TV transmitter, such as a transmitter Petition 870260076490, dated 07 / 31 / 2026, page 27 / 31 / 22 For each source block of a data broadcast file, OTA digital computes a checksum at block 502. In one example, the checksum might be a 32-bit cyclic redundancy check (CRC) value. Alternatively, a Message Digest (MD)-5 checksum might be used. Moving to block 504, a list of checksums is generated and sent with the source blocks, for example (via OTA). In an example implementation, the checksum list might be included in the RepairFlow element of the Service Transport Sessions (S-TSID) instance description, as only the RepairFlow element and AL-FEC provide data division into source blocks and have no meaning outside the RepairFlow element. Each checksum in the list is thus correlated with the source block to which it belongs.

[0056] Accordingly, the present principles apply a checksum to each source block to minimize the effort required by a receiver, improving the probability of success after further attempts in a carousel, where sufficient repair blocks may not always be available for each source block. This is especially true with large files, where RFC 6330 only applies repair bytes at the end of the entire file.

[0057] Figure 6 illustrates the logic on the receiver side. Starting at block 600, the source blocks and the checksum list are received. In other words, to improve robustness, the receiver receives a corresponding checksum for each source block, and each checksum is verified at block 602, for example, by recalculating the checksum using the contents of the received source block and comparing the recalculated checksum with the checksum for the source block as received in the transmitter list. This allows the receiver to discard only a portion of the data in block 604 as defined by the length of that source block in the AL-FEC parameters. That is, in Petition 870260076490, dated 07 / 31 / 2026, page 28 / 31 / 22 block 604, the recipient discards the source blocks for which the newly computed checksum does not match the received checksum.

[0058] Moving on to block 606, for source blocks with disparate checksums, the receiver can attempt to repair the source block by retrieving the source block data from a server (as specified in another signaling location). That is, the receiver can supplement missing packets and bad source blocks via a TCP / IP connection when a server and the connection to the server are available, while minimizing data overhead on the unicast server. Alternatively, the receiver can simply wait to receive the data again in a broadcast carousel in block 608.

[0059] Table 1 below illustrates repair flow elements, data types, and descriptions as they can be sent in an S-TSID. The two data flow elements @percentRepair and @checksumList are relevant to the present principles. @percentRepair can be, in one implementation, a 16-bit unsigned integer that equates to the maximum ratio of repair symbols to source symbols as a percentage. The absence of this attribute means that the size of the AL-FEC repair data is not provided.

[0060] On the other hand, @checksumList is an optional space-separated list of, for example, 32-bit unsigned integers in hexadecimal format that is equivalent to the calculated CRC32 checksums of each source block. This list can be used by the receiver to determine the accuracy of received and / or repaired data in a source block. In its absence, the integrity of the complete received and / or repaired file may be available through the optional MD5 FDT-Instance Checksum. However, the CRC32 checksum list, when present, allows the receiver to more accurately assess the need to replace data in a Petition 870260076490, dated 07 / 31 / 2026, page 29 / 31 / 23 resolution level of the source block. Table 1 Element Name or Usage Attribute Data Type Description @appContextIdList 0..1 afdt:uriList A space-separated list of URIs representing one or more unique Application Context Identifiers. @filterCodes 0..1 afdt:listOfUnsignedInt A space-separated list of 32-bit unsigned integers representing Filter Codes that apply to this file. @maxCacheMemory 0..1 unsignedint The maximum memory required at any given time by the receiver to cache data when packets are being delivered out of order.

[0061] Table 2 reproduces ATSC 3.0 A / 331. Table 6.2 describes the S-TSID table, and these new AL-FEC parameters can be added as shown below. Table 2 Element or Attribute Name Usage Data Type Description RepairFlow stsid:rprFlowTy pe Repair flow transported on the LCT channel. FECParameters 0..1 FEC parameters corresponding to the repair flow. @maximumDelay 0..1 unsignedInt Maximum delivery delay between any source packet in the source flow and the repair flow. @overhead 0..1 unsignedShort (percentage) FEC overhead in a ROUTE packet represented as a percentage. @minBuffSize 0..1 unsignedInt Required buffer size to handle all associated objects that are assigned to a superobject. @fecOTI 1 hexBinary FEC-related information associated with an object, as well as FEC information associated with the object's encoding symbols, which must be included in this declaration and applies to all repair packets with the repair flow. @percentRepair 0..1 UnsignedShort The maximum ratio of repair symbols to source symbols as a percentage. @ChecksumList 0..N unsignedInts List of checksums formatted in CRC32 hexadecimal for each source block in the order of the source blocks. Petition 870260076490, dated 07 / 31 / 2026, page 30 / 31 / 22 Element or Attribute Name Usage Data Type Description ProtectedObject 0..N List(s) of the source stream(s) protected by this repair stream and details on how the protection is performed. It also defines how certain supply objects from a collection of objects are included in the repair stream. @sessionDescription 0..1 string Specifies the session description information for the source stream. @tsi 1 unsignedInt The Transport Session Identifier (TSI) for the source stream to be protected. SourceTOI 1..NO(s) Transport Object Identifier (TOI) value(s) of the supply object(s) corresponding to the TOI of a given FEC (super)object supplied by the repair stream. @x @x 0..1 unsignedShort Value of the constant X for use in deriving the TOI of the supply object from the TOI of the (super)object FEC. @y 0..1 unsignedShort Value of the constant Y for use in deriving the TOI of the supply object from the TOI of the (super)object FEC.

[0062] It will be understood that, although the present principles have been described with reference to some exemplary embodiments, they are not intended to be limiting and, to implement the matter claimed herein, various alternative arrangements may be used. Petition 870260076490, dated 07 / 31 / 2026, p. 31 / 31

Claims

1 / 4 CLAIMS 1. In data broadcasting, a method characterized in that it comprises: computing the respective 32-bit cyclic redundancy code (CRC) checksums for each source block of a digital file; and transmitting the source blocks and a list of the checksums to at least one receiver using digital television transmission, the list being included in a RepairFlow element of a Service Transport Sessions Instance Description (S-TSID).

2. A method according to claim 1, characterized in that it comprises: in a digital receiver, applying a checksum to each source block to improve the probability of success after further attempts in a transmission carousel, at least in part by: receiving the source blocks and the list of checksums; verifying each checksum; discarding source blocks for which the respective checksums are not verified and not discarding source blocks for which the respective checksums are verified;For source blocks with unverified checksums, searching for source blocks from at least one server having a network location specified in the digital television signaling or waiting to receive the source blocks again in a broadcast carousel, or both searching for source blocks from at least one server and waiting to receive the source blocks again in a broadcast carousel. Petition 870250072194, dated 08 / 15 / 2025, p. 34 / 43 2 / 4; 3. Method according to claim 2, characterized in that it comprises: searching for the source blocks of at least one server.

4. Method according to claim 2, characterized in that it comprises: waiting to receive the source blocks again in an emission carousel.

5. Method according to claim 1, characterized in that the verification of each checksum comprises: the recalculation of the checksum using content from the respective source block; and the comparison of the newly computed checksum with the checksum for the source block as received in the list.

6. Method according to claim 1, characterized in that the digital receiver comprises an Advanced Television Systems Committee (ATSC) 3.0 receiver.

7. Digital television set, characterized in that it comprises: at least one receiver configured to receive digital television from a digital television transmitter system, the receiver comprising at least one processor programmed with instructions to: receive multiple source blocks from at least one file and a list of corresponding checksums associated with the source blocks from at least one digital television transmitter; verify each checksum; discard source blocks for which the corresponding checksums are not verified and not discard source blocks for which the corresponding checksums are verified; and for source blocks with checksums not verified, the processor is ...; and for source blocks with non-verified checksums, the processor is programmed with instructions to: Petition 870250072194, dated 08 / 15 / 2025, page 1.35 / 43 3 / 4 verified, fetch the source blocks from at least one server having a network location specified in the digital television signaling or wait to receive the source blocks again in a broadcast carousel, or either fetch the source blocks from at least one server and wait to receive the source blocks again in a broadcast carousel.

8. Digital television set according to claim 7, characterized in that the instructions are executable to: fetch the source blocks from at least one server.

9. Digital television set according to claim 7, characterized in that the instructions are executable to: wait to receive the source blocks again in a broadcast carousel.

10. Digital television set according to claim 7, characterized in that the instructions are executable to perform the verification by: recalculating the checksum using content from the respective source block; and comparing the newly computed checksum with the checksum for the source block as received in the list.

11. Digital television set according to claim 7, characterized in that the digital television receiver comprises an Advanced Television Systems Committee (ATSC) 3.0 receiver.

12. Digital television set, characterized in that it comprises: at least one transmitter comprising at least one processor programmed with instructions in order to configure the processor to: compute the respective checksums for each source block of a digital file; and transmit the source blocks and a list of the checksums to at least one receiver using digital television transmission.

13. Digital television set according to claim 12, characterized in that the list is included in a description of the Service Transport Sessions (S-TSID) instance.

14. Digital television set according to claim 13, characterized in that the list is included in an S-TSID RepairFlow element.

15. Digital television set according to claim 12, characterized in that the checksums comprise 32-bit cyclic redundancy code (CRC) checksums.

16. Digital television set according to claim 12, characterized in that the checksums comprise message digest (MD)-5 checksums.

17. Digital television set according to claim 12, characterized in that the transmitter comprises an Advanced Television Systems Committee (ATSC) 3.0 transmitter. Petition 870250072194, dated 08 / 15 / 2025, pp. 37 / 43

Images