WO2024206380A1

WO2024206380A1 - Forward error correction block partitioning

Info

Publication number: WO2024206380A1
Application number: PCT/US2024/021599
Authority: WO
Inventors: Sean Peter DEVINE; David Catapano
Original assignee: Triveni Digital Inc
Current assignee: Triveni Digital Inc
Priority date: 2023-03-30
Filing date: 2024-03-27
Publication date: 2024-10-03
Anticipated expiration: 2025-09-30

Abstract

A method and apparatus for reliable delivery of multicast data by a broadcast transmitter utilizing block partitioning is described. The method includes establishing a communication session with a receiver, selecting a maximum partition size to balance robustness and storage allocation requirements available in the receiver, and determining a number of blocks required to break the multicast data into partitions having the maximum partition size. The apparatus includes a controller that establishes a communication session with a receiver, the controller further providing an interface for selecting a maximum partition size to balance robustness and storage allocation requirements available in the receiver, and a segmenter that determines a number of blocks required to break the multicast data into partitions having the selected maximum partition size. The number of blocks and the size of the blocks may vary based on the maximum partition size.

Description

FORWARD ERROR CORRECTION BLOCK PARTITIONING

Technical Field

[0001 ] The present disclosure generally relates to communication systems and, more particularly, to terrestrial-based communication systems, such as terrestrial broadcast communication systems.

Background

[0002] In communications systems, such as broadcast communication systems, error detection / correction coding along with interleaving are often used to improve the reliability of transmission. Such error detection/correction codes include such techniques as, but not limited to, convolutional codes, trellis codes, and concatenated forward error correction (FEC) coding schemes. FEC coding can recover data lost due to errors introduced during signal transmission, often referred to as packet loss. Good FEC coding needs the broadcast content, such as audio, video, and other information, to be processed using sufficient portion sizes. In general, larger portion size can have better error-correction performance and less redundancy.

[0003] Interleaved broadcast is a conventional transmission strategy that works as follows. The transmission device splits the content into source blocks and each source block is independently FEC encoded. The FEC- encoded data is broadcast completely interleaved amongst the source blocks, i.e., all FEC-encoded-data for a source block is transmitted evenly interleaved with transmission of all FEC-encoded data for all other source blocks. One example of FEC that can be applied to interleaved broadcast is Application Layer (AL) FEC, such as RaptorQ™ from Qualcomm.

[0004] Interleaved data in a broadcast signal provides excellent protection against burst packet loss, as the loss is spread out equally over the FEC-encoded data for all the source blocks of the content rather than being concentrated on one source block, and thus the amount of FEC- encoded data that needs to be transmitted over the network relative to the content size to ensure reliable delivery of the content is commensurate with the overall amount of loss during the transmission of the content.

[0005] As an example, a receiver, such as a mobile receiver, receives a data interleaved broadcast signal delivering 100 megabytes (MB) of content transmitted over an 800 kilobit per second (Kbps) broadcast channel The transmission device partitions the content into 100 source blocks each having a block size of 1 MB. The transmission device generates FEC-encoded data for each of the source blocks and transmits the FEC-encoded data for each source block evenly interleaved amongst the FEC-encoded data for all the other source blocks. In other words, a portion of each of the 100 source blocks has been interleaved into the time locations of each of the 100 source blocks.

[0006] Without the data interleaved broadcast signal described above, a sequential (non-data interleaved) broadcast signal delivering WOMB of content over an 800 kbps may normally experience as much as 10 second bursts of packet loss at an average rate of 10 times per hour at the receiver, with high probability there will be at most 10 outages during the less than half hour of signal reception at the receiver or mobile device, or at most 100 seconds of outage overall during the reception. In contrast, each outage causes a small percentage of FEC-encoded data to be lost equally from each of the source blocks at the receiver or mobile device when using data interleaved broadcast signals. Thus, since the FEC-encoded data for each source block is spread equally across time during the entire transmission, at most 100 KB of data is lost from each source block due to the 100 seconds of outages. To protect against these outages for a single source block, the amount of FEC-encoded data that needs to be sent for each source block may be at most 1.1 MB, and the overall amount of FEC- encoded data transmitted for the 100 MB content file to ensure reliable recovery of the entire content file at the receiver device may be at most 1 10 MB, representing only a 10 percent overhead for error correction.

[0007] However, the data interleaved broadcast signal requires the receiver to allocate storage for all source blocks simultaneously. Some receivers, particularly mobile or portable receivers may have storage limitations that do not allow for storage of large amounts of data (e.g. , 100 MB) simultaneously. If the receiver is not able to allocate storage for all source blocks simultaneously, the receiver may require partial or complete retransmission of the signal, reducing the efficiency and benefits of the date interleaved broadcast signal. The present embodiment attempts to address the problems of large block data interleaving of broadcast signals in receivers having storage allocation limitations.

Summary

[0008] According to one implementation, a method for reliable delivery of multicast data by a broadcast transmitter utilizing block partitioning is described. The method includes establishing a communication session with a receiver, selecting a maximum partition size from a predetermined range of acceptable maximum partition sizes, the maximum partition size being selected to balance robustness and storage allocation requirements available in the receiver, and determining a number of blocks required to break the multicast data into partitions having the maximum partition size. At least one of the number of blocks and a size of the blocks may vary based on the maximum partition size. [0009] According to another implementation, an apparatus for providing multicast data that utilizes block partitioning as part of delivery by a broadcast transmitter is described. The apparatus includes a controller that establishes a communication session with a receiver, the controller further providing an interface for selecting a maximum partition size from a predetermined range of acceptable maximum partition sizes, the maximum partition size being selected to balance robustness and storage allocation requirements available in the receiver. The apparatus also includes a segmenter coupled to the controller, the segmenter determining a number of blocks required to break the multicast data into partitions having the selected maximum partition size. At least one of the number of blocks and a size of the blocks may vary based on the selected maximum partition size.

[0010] According to another implementation, a method for receiving multicast data utilizing block partitioning at a receiver, the multicast data delivered by a broadcast transmitter is described. The method includes receiving block partitioning operating parameters associated with delivery of the multicast data from the broadcast transmitter, the block partitioning operating parameters including a number of blocks used to break the multicast data into a maximum partition size. The method also includes receiving the multicast data and processing the received multicast data based on the received block partitioning operating parameters.

Brief Description of the Drawings

[0011 ] The above and other aspects, features, and advantages of the present disclosure will become more apparent in light of the following detailed description when taken in conjunction with the accompanying drawings to which the principles of the present disclosure are applicable:

[0012] FIG 1 is a block diagram of an exemplary broadcast content distribution system, according to aspects of the present disclosure;

[0013] FIG 2 is a block diagram of an exemplary content processing device used in a content distribution system, according to aspects of the present disclosure;

[0014] FIG 3a and FIG. 3b are diagrams representing two different configurations of partitioning of blocks as part of the block segmenting and partition segmenting used in block partitioning, according to aspects of the present disclosure;

[0015] FIG 4a and FIG. 4b are diagrams representing two different configurations for interleaving fundamental data elements within the blocks included in the partitions based on the partition segmenting shown in FIGs. 3a and 3b respectively, according to aspects of the present disclosure;

[0016] FIG . 5 is a screenshot of a graphical user interface (GUI) associated with the block partition process used with data in a communication signal, according to aspects of the present disclosure; [0017] FIG. 6 is a flow chart of an exemplary process for providing data for delivery as a communication signal utilizing block partitioning, according to aspects of the present disclosure;

[0018] FIG 7 is a block diagram of an exemplary communication receiver that can receive data content processed using block partitioning; and

[0019] FIG 8 is a flow of an exemplary process for receiving multicast data content processed using block partitioning.

Detailed Description

[0020] It should be understood that the elements shown in the figures may be implemented in various forms of hardware, software, or combinations on one or more appropriately programmed general-purpose devices, which may include a processor, memory, and input/output interfaces. Those skilled in the art will be able to devise various arrangements which, although not explicitly described or shown herein, embody the principles of the disclosure and are included within its scope.

[0021 ] All examples recited herein are intended to aid the reader in understanding the principles of the disclosure and the concepts and are to be construed as being without limitation to such specifically recited examples and conditions. Any flow charts, flow diagrams, state transition diagrams, pseudocode, and the like represent various processes which may be substantially represented in computer readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

[0022] The functions of the various elements shown in the figures may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term "processor”, "module” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, a system on a chip (SoC), digital signal processor (“DSP”) hardware, read only memory (“ROM") for storing software, random access memory (“RAM”), and nonvolatile storage.

[0023] As used herein, the term “processor” broadly refers to and is not limited to a single- or multi-core general purpose processor, a special purpose processor, a processor, a Graphics Processing Unit (GPU), a DSP, a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, one or more Application Specific Integrated Circuits (ASICs), one or more Field Programmable Gate Array (FPGA) circuits, any other type of integrated circuit (IC), an SoC, and/or a state machine. As used herein, the terms “transaction” and “electronic transaction” broadly refer to any transaction which may be electronically validated by the recited system, method, and apparatus.

[0024] One or more of the aspects of the embodiments described above may be implemented using application-specific hardware. Further, one or more aspects of the embodiments may be implemented using one or more processing elements, such as central processing units (CPUs) that may include specific operating instructions embedded as firmware in the processing element(s) or may operate from software code that is downloaded into the elements from one or more memory units coupled to the processing element(s).

[0025] The present disclosure addresses issues related to reliably delivering data over a broadcast communication channel to receiving devices that may have storage limitations that limit their ability to store large amounts of received data simultaneously. These issues are becoming more prominent as mobile and portable devices, having such storage limitations, are used for increasingly more complex media and data content. As a result, the block segmentation and interleaving often applied to media and data content objects as part of broadcast communication signals for delivery to larger types of receiving devices may not be as efficient when delivering a broadcast signal containing the processed media and data content to these mobile and portable devices.

[0026] The present disclosure addresses these issues by introducing an additional partitioning mechanism that can be flexible and adjustable to the needs of these storage limited receiving devices. The mechanism, referred to as block partitioning, further partitions groups of the blocks created as described above. The interleaving is now applied across the groups of blocks within each partition group rather than all of the blocks in the media and data content object. The maximum partition size and, as a result, the number of partition groups can be adjusted prior to transmission of the broadcast signal as needed to account for storage limitations of the receiver and considering the impact on performance (e.g., packet loss due to burst errors as discussed above). Information associated with the partitioning structure for the data may also be provided in order to allow the receiver to adjust its operation for recovering the media and data content from the delivered broadcast signal.

[0027] Advantages of the present disclosure will become more apparent from the detailed description given hereinafter. However, it should be understood that the detailed description and specific examples, while indicating preferred embodiments of the present disclosure, are given by way of illustration only, since various changes and modifications within the scope of the present disclosure will become apparent to those skilled in the art from this detailed description. [0028] FIG 1 illustrates a block diagram of an exemplary broadcast content distribution system 100 according to aspects of the present disclosure. In broadcast content distribution system 100, content from one or more content sources is provided to studio content processing system 105. Studio content processing system 105 is coupled to broadcast gateway 110. Broadcast gateway 110 is coupled to exciter 1 15. Exciter 115 is coupled to transmitter 120. Transmitter 120 is coupled to the transmitter antenna 125, which radiates a broadcast signal provided from transmitter 120 into the airwaves. Studio content processing system 105 is also coupled to transport multiplexer 130. Transport multiplexer 130 is coupled to exciter 135. Exciter 135 is coupled to transmitter 140. Transmitter 140 is coupled to the transmitter antenna 145, which radiates a broadcast signal provided from transmitter 140 into the airwaves. Broadcast gateway 1 10 is also coupled to gateway 160 through local network 150. Gateway 160 is coupled to exciter 165. Exciter 165 is coupled to transmitter 170. Transmitter 170 is coupled to the transmitter antenna 175, which radiates a broadcast signal provided from transmitter 170 into the airwaves. Local network 150 also interfaces with one or more network content service providers to provide data representing studio content to users of the network content services. Emergency alert content from one or more emergency alert sources is provided to emergency alert system (EAS) receiver 180. EAS receiver 180 is coupled to studio content processing system 150.

[0029] Most broadcast signals, as well as many communication signals, rely on a set of standards in order to maintain compatibility between the signal transmission and the signal receivers used for receiving the signal transmission. Most standards further implement the communication structures within various elements and signals based on protocol layers, starting at the physical radio frequency (RF) layer, referred to as the physical (PHY) layer, and moving lower through to the network layer, transport layer, and finally, the lowest or application layer. Aspects of the present disclosure utilize the various relationships that can exist between various elements and signals of each of the protocol layers.

[0030] Nominally, the studio content processing system 105, broadcast gateway 110, exciter 115, transmitter 120, and antenna 125 are collocated (e.g., in the same building or facility) and represent a broadcast signal transmission mechanism for delivering broadcast signals for use by the public within a first geographic area. As such, the transmitter 120 is configured as the main or original transmission source of a broadcast signal. Further, the transport multiplexer 130, exciter 135, transmitter 140, and transmitter antenna 145 may also be collocated at or near the same geographic location and provide the same or similar broadcast signals but using a different transmission format. Additionally, gateway 160, exciter 165, transmitter 170, and transmitter antenna 175 may be collocated at a geographic location that is different from the location of the elements mentioned above and may represent a broadcast signal transmission mechanism for delivering broadcast signals for use by the public within a second or different geographic area using either the same or a different transmission format. It is worth noting that the configuration of broadcast content distribution system 100 represents one or many possible configurations which may take advantage of the principles of the present disclosure.

[0031 ] Media content (e.g., audio, video, and/or data signals) as well as data associated with the media content is received by studio content processing system 105. The studio content processing system 105 may include one or more devices for processing media content for delivery and/or transmission through broadcast content distribution system 100. The studio content processing system 105 may include, but is not limited to, encoders, packagers, signal converters, encapsulators and the like. The media content may be provided from one or more media content sources including, but not limited to, content production studios, content distribution companies, broadcast content providers, and the like. Media content may also be provided from alternative content sources such as websites, content subscription service companies and interactive applications providers. Data content may also be provided by one or more of the above-mentioned content sources as well as from specific data content sources such as media content listing or content guide services companies. The media content and/or the data content may be provided as raw digital data that is unencoded and unencrypted, particularly with respect to any broadcast standard protocols. The studio content processing system 105 processes the media and data content from the various content sources to produce one or more content streams. The content streams may be encoded and/or compressed using one or more media content encoding or compression protocols including but not limited to, MPEG 2, MPEG-4, MPEG-4 advanced video coding (AVC), and MPEG-H Part-2 high efficiency video coding (HEVC). One or more of the content streams may also be encoded using error detection and/or correction encoding. The error detection and/or correction encoding may include, but is not limited to, data interleaving, parity, cyclical redundancy, and the like. Some of these content streams may further be formatted into internal protocol packets based on any one of several possible network friendly protocols. For example, the streams may be formatted as Real-time Transport Protocol (RTP)/User Datagram Protocol (UDP)/internet protocol (IP) multicast streams as part of data source layer processing. In some embodiments using ATSC 3.0 transmission standards, the streams may be formatted as Real-time Object Delivery over Unidirectional Transport (ROUTE) or MPEG Media Transport (MMT) packets. Some of these multicast streams allow the IP packets destined for broadcast signal receivers to be tunneled through any IP network without need to provide special routing or other consideration for the receiver IP address space. Tunneling is a networking mechanism that allows data in any format across diverse networks. In some embodiments, the content streams are further formatted using a data source transport protocol (DSTP) as described in the ATSC standard A/324. [0032] The studio content processing system 105 further includes a block partitioning mechanism as part of the application layer processing. The block partitioning mechanism may be used to reduce the potential for packet loss due to the inability to allocate storage for all of the source blocks simultaneously.

[0033] One or more of the content streams from studio content processing system 105 are provided to broadcast gateway 110 as part of an advance broadcast communication. Broadcast gateway 110 processes the one or more content streams and formats the signals into a broadcast signal transport stream. Broadcast gateway 110 processes one or more of several different types of elementary streams that may include packet formatting that is consistent with delivery as IP packets but can be adapted for delivery in a broadcast transport stream. As such, the processing in broadcast gateway 110 includes encapsulating and formatting the IP packets in the one or more content streams into link layer packets as part of a baseband data packet stream based on a specific transport protocol. In some embodiments, broadcast gateway 1 10 encapsulates the one or more content streams by adding a data link layer based on the ATSC Link Layer Protocol (ALP) described in ATSC Standard A/330 that carries the IP packets provided by studio content processing system 105 over the ATSC 3.0 broadcast standard physical layer. The encapsulation may further provide the mapping of some, or all of the IP packets extracted from the content streams into sub-streams within the broadcast streams, often referred to as physical layer pipes (PLPs).

[0034] The processing in broadcast gateway 1 10 also includes packet management or scheduling in order to convert the broadcast signal transport stream into a stream containing baseband data packets suitable for processing by the exciter 115. The broadcast gateway 1 10 also generates a network configuration and control stream as well as a preamble stream as part of the scheduling operation. In some embodiments, the network configuration and control stream may be referred to as a timing and management control data stream. The broadcast signal transport stream, including the network configuration and control stream and preamble data stream, are used by exciter 115 to create the broadcast emission signal waveform. In some embodiments, one or more packets of the broadcast signal transport stream may be tunneled using a protocol such as the studio to link transport protocol (STLTP) as described in ATSC standard A/324 as part of an ATSC broadcast. Further, in some embodiments, the tunneled packets may include a security mechanism, such as a packet or stream signature, allowing exciter 115 to determine if the packet or stream has been tampered with. Information associated with packet or stream security associated with the present disclosure will be described in further detail below.

[0035] Exciter 115 receives the broadcast signal transport stream, along with the network configuration and control stream and preamble data stream, from the broadcast gateway and provides additional link layer signal processing to the streams to form the broadcast emission signal based on the network configuration and control stream and preamble data stream. The link layer signal processing may include one or more forms of data error correction encoding, temporal interleaving encoding, and data signal modulation. The data error correction encoding may include, but is not limited to, Reed-Solomon encoding, Viterbi encoding, Bahl, Cocke, Jelinek, and Raviv (BCJR) encoding, and low-density parity check (LDPC) encoding. The data signal modulation may include but is not limited to vestigial sideband (VSB) modulation, multi-level quadrature amplitude modulation (QAM), and multi-level orthogonal frequency modulation (OFDM). The resulting broadcast signal is converted from a digital format signal to an analog format baseband or low frequency signal and further upconverted to a frequency for transmission as an analog transmission signal. In some embodiments the frequency for transmission may be in the very high frequency (VHF) range from 54 megahertz (MHz) to 88 MHz and 174 MHz to 216 MHz or in the ultra-high frequency (UHF) range from 470 MHz to 868 MHz. The exciter 115 may also apply analog signal transmission precorrection to account for known or anticipated signal distortion caused by signal amplification in transmitter 120.

[0036] It is important to note that the link layer signal processing, data signal modulation, and signal up- conversion used by exciter 115 may conform to one or more of several broadcast signal physical layer broadcast standards. Such broadcast standards include, but are not limited to, ATSC 3.0, the digital video broadcasting (DVB) standard DVB-T2, and the integrated services broadcasting (ISDB) standard ISDB-T.

[0037] Transmitter 120 receives the analog transmission signal from exciter 1 15 and amplifies the signal from its received signal level of around one milliwatt (mW) to a level between one kilowatt (kW) and ten kW. Transmitter 120 may perform the amplification in stages and may include signal filtering between the stages as well as at the output in order to remove signal distortion artifacts and other undesired signal energy outside of the desired frequency range for the transmitted signal. It is worth noting that the type and amount of amplification and filtering that is used in transmitter 120 may affect the type and necessity for analog signal transmission precorrection that may be applied by exciter 115. The amplified RF transmission signal is provided to transmitter antenna 125 for emission as an over the air broadcast signal. The transmitter antenna 125 may include one or more antenna elements that are arranged and/or configured to provide the necessary or desired radiated emission pattern in order to provide the proper geographic cover area for the RF transmission signal. As illustrated, transmitter antenna 125 is incorporated as part of a communication tower that may be 50 or more feet tall. In some embodiments, transmitter antenna 125 may be incorporated as part of other structures including, but not limited to, a residential or commercial dwelling, a utility pole, a bridge, and the like.

[0038] One or more of the content streams from studio content processing system 105 are also provided to transport multiplexer 130 as part of a legacy broadcast communication. Transport multiplexer 130 operates in a similar manner to broadcast gateway 1 10 but is intended to process different types of content streams. More specifically, transport multiplexer 130 is configured to process one or more elementary broadcast signal streams having uniform packets that can be rearranged into a single broadcast transport stream while broadcast gateway 1 10 is configured, as described above, to process one or more content streams into different types of streams that are based on packet protocols such as transport control protocol/internet protocol (TCP/IP) and formats these stream into a complex broadcast signal transport stream. As such, the processing in transport stream multiplexer 130 includes identifying and, formatting and combining the one or more elementary content streams into a broadcast transport stream. The processing may also include program identification (PID) remapping as well as service remapping and generation and insertion of service information tables directly into the broadcast transport stream. In some embodiments, transport multiplexer 130 processes content streams consistent with the ATSC A/53 and A/73 standards

[0039] Exciter 135 receives the broadcast signal transport stream from the transport multiplexer 130 and provides additional link layer signal processing to the streams to form the broadcast emission signal. The link layer signal processing may include one or more forms of data error correction encoding, temporal interleaving encoding, and data signal modulation similar to that described above for exciter 115. The resulting broadcast signal is converted from a digital format signal to an analog format baseband or low frequency signal and further upconverted to a frequency for transmission as analog transmission signal in transmitter 140 in a manner similar to that described above.

[0040] It is important to note that the link layer signal processing, data signal modulation, and signal up- conversion used by exciter 135 may conform to one or more of several broadcast signal physical layer broadcast standards. Such broadcast standards include, but are not limited to, ATSC 1.0 and DVB-T. Further, the link layer processing may also include some or all of the error correction/detection and interleaving processing similar to that described above. The link layer processing may further include a block partitioning mechanism similar to the mechanism in the application layer.

[0041 ] Transmitter 140 receives the analog transmission signal from exciter 135 and amplifies the signal to a level between one kW and ten kW as described above for transmitter 120. The amplified RF transmission signal is provided to transmitter antenna 145 for emission as an over the air broadcast signal. Transmitter antenna 145 may be configured and operates in a manner similar to that described for antenna 125 above. Further, in some embodiments, antenna 125 and antenna 145 may be incorporated as part of the same communication tower or other structure. [0042] The broadcast signal transport stream, along with the network configuration and control stream and preamble data stream, from the broadcast gateway 110 is also provided through local network 150 to gateway 160. Local network 150 may be configured to deliver data as signals between various devices connected to local network 150 using an IP. The local network 150 may use various arrangements and other facilities or devices (not shown) to physically connect the devices together including, but not limited to, a microwave communications link, a high-speed fiber communications link, a lower speed copper wire communications link, and cellular or wi-fi communications link.

[0043] Gateway 160 processes the one or more baseband content streams and formats the streams into one or more broadcast signal transport streams for use by exciter 165. The processing in gateway 160 includes encapsulating and formatting the IP packets contained in the one or more content streams into link layer packets as part of the baseband streams used as part of the re-broadcast of the received signal based on a specific transport protocol as described above for broadcast gateway 110.

[0044] It is worth noting that the processing capability in gateway 160, which may be referred to as an edge gateway device, differs in several aspects to broadcast gateway 1 10. For example, it is not common or, in many cases, practical, to use broadcast gateway 1 10, and similar broadcast gateways, as an edge gateway device for internet type communication due to the fact that a broadcast transmission channel does not have available bandwidth for a return communication path across the broadcast network. Further, gateway 160, and similar edge gateways, typically provide routing functionality that require only support for validating a limited key signing security system while broadcast gateway 110, and similar broadcast gateways, are configured to support a private key signing security system, such as is used in many broadcast content transmission protocols, a function not typically employed as part of an edge gateway. Gateway 160, and similar edge gateways, also can be controlled using a management stream that is included as part of the data provided in the streaming content allowing unattended operation.

[0045] Exciter 165 receives the broadcast signal transport stream(s) containing the one or more content streams from the gateway 160 and provides additional link layer signal processing to the streams to form a broadcast emission signal and, finally, an analog transmission signal, for re-broadcast in a manner similar to that described above for exciter 115. The one or more baseband streams are similar to the content streams received from broadcast gateway 110, as described above, may include, among other elements, a network configuration and control stream and a preamble data stream. Transmitter 170 receives the analog transmission signal from exciter 165 and amplifies the signal in a manner similar to that described above for transmitter 120. The amplified RF transmission signal is provided to antenna 175 for emission over the air as described above for antenna 125. It is worth noting that the frequency that is used for the analog transmission signal in exciter 165 may be the same as, or different from, the frequency used for the analog transmission signal from exciter 115 depending on the signal transmission format and/or protocol used.

[0046] It is worth noting that the configuration in FIG. 1 , that includes gateway 160, exciter 165, transmitter 170, and transmitter antenna 175, allows for a re-transmission of all or a portion of the broadcast signal transmitted by transmitter antenna 125 from transmitter 120. It is therefore expected that the geographic location of the transmission facility and the transmitter antenna 175 will be different from the geographic location of transmission facility and transmitter antenna 125.

[0047] EAS receiver 180 is configured to detect and receive emergency events that are broadcast as part of a separate network, such as the emergency broadcast network. If an emergency event is detected and received by EAS receiver 180, the information is provided to the studio content processing system 105. The studio content processing the system 105 processes the information and may insert the processed information into one or more of the content streams. In one embodiment, the processed information may be inserted into the secondary video and audio service portion of the broadcast signal transport stream.

[0048] In operation, media content is provided from a number of content sources to studio content processing system 105. Studio content processing system 105 processes the content streams to form one or more media streams. As part of the processing in studio content processing system 105 one or more media streams are processed for reliable delivery as multicast data utilizing block partitioning. The processing includes establishing a communication session with one or more broadcast signal receivers (not shown) that are capable of receiving broadcast signals from content distribution system 100. Once the communication session is established a maximum partition size is selected from a predetermined range of acceptable maximum partition sizes. The maximum partition size being selected to balance robustness and storage allocation requirements available in the receivers with which the communication session is established. The processing further includes determining the number of blocks required to break the multicast data into the maximum partition size that has been selected. Notably, one or both of the number of blocks and the size of the blocks may be varied based on the maximum partition size that has been selected.

[0049] The media streams, including the multicast data created and processed in studio content processing system 105, are further processed in various other components, or broadcast devices, in broadcast content distribution system 100 for delivery to the broadcast signal receivers operated by users or viewers. For example, the media streams may be processed in broadcast gateway 110 and exciter 115. The processed media stream may be transmitted to a group of broadcast signal receivers operated using transmitter 120 and transmitter antenna 125. Additionally, or alternatively, the broadcast gateway 110 may provide the processed media streams through a local network 150 to gateway 160 and exciter 165. The processed media streams may be transmitted to another group of broadcast signal receivers operated using transmitter 170 and transmitter antenna 175. The processed media streams may also be provided to other network content service providers through local network 150.

[0050] FIG 2 illustrates a block diagram of an exemplary content processing device 200 according to aspects of the present disclosure. The content processing device 200 may operate in a manner similar to studio content processing device 105 described in FIG. 1 The content processing device 200 may be used to process one or more media streams into multicast data that utilizes block partitioning in order to improve the reliability of the multicast data over a broadcast system, such as the broadcast content distribution system 100. One or more elements of content processing device 200 may also be used as part of other content distribution systems including, but not limited to, cable network systems, satellite network systems, fiber network systems, cellular communication network systems, and the like. It is to be appreciated that several components and interconnections necessary for complete operation of content processing device 200 are not shown in the interest of conciseness, as the components not shown are well known to those skilled in the art.

[0051 ] Signals from content sources are provided to encoder 210. The content sources may include, but are not limited to, content production studios, content distribution companies, broadcast content providers, as well as alternative content sources and EAS providers as described above. The encoder 210 is coupled to the packager/segmenter 220. The packager/segmenter 220 is coupled to the real time ROUTE/MMT encapsulator 230. A controller 250 is coupled to encoder 210, the packager/segmenter 220, and the real time ROUTE/MMT encapsulator 230. The real time ROUTE/MMT encapsulator 230 provides one or more media streams processed in studio content processing device 200 to other devices for further processing, such as the broadcast gateway 1 10 in FIG. 1 .

[0052] In real time ROUTE/MMT encapsulator 230, the content streams from the packager/segmenter 220 are provided to one or both of the A/V ingest 231 and non-real time (NRT) ingest 232. The NRT ingest 232 is coupled to the block segmenter 233. The block segmenter is coupled to the repair symbol generator 234. The repair symbol generator 234 is coupled to the partition interleaver 235. The partition interleaver 235, along with the A/V ingest 231 and the signaling generator 237, is coupled to the NRT ROUTE encapsulator 239. The NRT ROUTE encapsulator 239 provides the processed media streams for further processing as described above. [0053] The encoder 210 receives media (e.g., audio and video streams) and data content and encodes the media and content into one or more different encoded content streams. The encoder 210 may include the ability to encode the received media and data content into an encoded content stream according to one or more well known encoding standards. The encoding standards include, but are not limited to, high efficiency video coding (HEVC), scalable high efficiency video coding (SHVC), advance compression version 4 (AC- 4) from Dolby labs, and the like. The encoded content streams from encoder 210 are provided to packager/segmenter 220. The packager/segmenter 210 packages and formats the encoded streams into a format that is compatible with one or more communication standards. For example, packager/segmenter 220 may format the encoded streams into one or more stream segments compliant with International Standards Organization (ISO) Base Media File Format (BMFF). The packager/segmenter may also provide additional data, such as metadata from the encoding systems. The Real Time ROUTE/MMT encapsulator

230 takes in the stream segments (e.g., BMFF segments) and routes the stream segments for data to NRT ingest 232 and routes the stream segments for media (e.g., audio/video) to A/V ingest 231 . The A/V ingest

231 processes the media stream segments, adding any additional information as needed, and provides the processed media stream segments to NRT/ROUTE encapsulator 239.

[0054] The NRT ingest 232 processes the data stream segments, adding any additional information as needed, and provides the processed data stream segments to block segmenter 233. The block segmenter 233 processes the data stream segments as objects and creates blocks of data based on a size and number of blocks for each object. Each block of data includes a group of fundamental data elements (e.g., communication symbols, packets, bytes) that are consecutive in time. The blocks of data created in the block segmenter 233 for the data stream object are provided to repair symbol generator 234.

[0055] The repair symbol generator 234 generates FEC data for the fundamental data elements in the blocks. The FEC coding that is used is typically a systemic coding, such as a RaptorQ™ coding or a Reed Solomon coding. Systemic codes typically generate a number of repair elements (e.g., symbols, packets, bytes) from a set of source symbols (i.e., the fundamental data elements in the blocks). The amount of FEC coding that is used can be adjustable and controlled by a user or operator through the controller 250. These repair elements are then sent in one or more repair streams in addition to the source blocks, either as separate blocks or incorporated into the existing blocks. The blocks from the block segmenter 233 and the repair elements generated by repair symbol generator 234 are provided to partition interleaver 235.

[0056] The partition interleaver 235 performs an interleaving on the blocks and repair elements from the repair symbol generator. In addition, the partition interleaver 235 performs the interleaving based on any partitioning of groups of blocks. For example, if the blocks for data stream objects are not partitioned, the partition interleaver 235 interleaves the fundamental data elements for all of the blocks and distributes the fundamental data elements across the time span covered by all of the blocks. In order to implement the block partitioning process, partition interleaver 235 partitions groups of blocks into one or more partitions based on a selection of a maximum partition size. The partition interleaver 235 interleaves the groups of blocks in each of the partitions separately. As a result, less memory is needed to store the blocks of data in a receiver than if no partitioning is performed. The partitioned and interleaved blocks of data are provided to the NRT/ROUTE encapsulator 239.

[0057] The Signaling Generator 237 is configured to produce signaling that allows receivers to discover the other metadata and signaling produced by other data sources. The signaling generator 237 may also include the ability to take in program listing information for broadcast channels, format it, and provide the formatted information to NRT/ROUTE encapsulator 239. The NRT ROUTE encapsulator 239 takes the stream segments and data files A/V ingest 231 , signaling generator 237 and partition interleaver 235 and emits one or more ROUTE streams for inclusion in the broadcast.

[0058] The controller 250 interfaces with each of the elements in content processing device 200. Controller 250 may provide control information and commands for processing performed in each of the elements. For example, controller 250 may initiate a communication session with a signal receiver based on a request from the user or operator. As part of initiating the communication session, the controller 250 may send command information to the block segmenter 233, repair symbol generator 234, and partition interleaver 235 to process one or more data segments using a particular set of parameters as part of a block partitioning. The parameters may include the number of blocks to be created, the amount of EEC coding to apply, and the number of partitions to use. Additionally, the controller may generate operational parameters as part of a file delivery table (FDT) that is included in the data stream provided at the output of the real time ROUTE/MMT encapsulator 230. An example FDT is shown below in TABLE 1 .

TABLE 1

[0059] FIGs. 3 and 4 illustrate different configurations of data as part of the process of block partitioning multicast data content, according to various aspects of the present disclosure. More specifically, FIGs. 3a and 3b illustrate two different configurations of partitioning of blocks as part of the block segmenting and partition segmenting used in block partitioning as described above in FIG. 2. FIGs. 4a and 4b illustrate two different configurations for interleaving fundamental data elements within the blocks included in the partitions based on the partition segmenting shown in FIGs. 3a and 3b, respectively. The configuration of data shown in FIGs. 3a and 3b may be generated in one or both of the block segmenter 233 and/or the partition interleaver 235 as part of content processing device 200 in FIG. 2. The configuration of data in FIGs. 4a and 4b may be generated in partition interleaver 235. The configurations of data illustrated FIGs. 3 and 4 use a small number of blocks and partitions in order to provide an understandable representation of the block partition process. Actual configurations that apply block partitioning to large segments of multicast data may use a much larger number of blocks and partitions. [0060] FIG 3a shows a single partition 310 containing eight blocks, labeled “Blk1” to "Blk8” arranged as a sequence in time. The eight blocks make up an object, representing multicast data content. Typically, an object may represent a large or complete part of multicast data content that is delivered as a continuous or nearly continuous unit, such as a complete segment of compressed audio or video content, or a complete still picture or file. As such, the object of multicast data content in FIG. 3a has been broken or divided into eight blocks. Each of the eight blocks contains separate smaller portions of data referred to as fundamental data elements. These elements may be packets of data, bytes of data, processed data communication symbols of data, and the like. For example, each of the blocks contains six communication symbols of data. In general, fundamental data elements are arranged in roughly time order within each block, meaning that the second symbol in the first block (“BLK1") follows the first symbol. Additionally, the first symbol in the second block (“ BLK2”) follows the sixth or last symbol of the first block, and so on to the sixth or last symbol or the last block (“BLK8”).

[0061 ] FIG 3b shows the same eight blocks from FIG. 3a as a sequence in time but split between two partitions, 350a and 350b. The first four blocks, "BLK1” to “BLK4”, are included in partition 350a and the last four blocks, “BLK5” to “BLK8” are included in partition 350a. As such, each partition includes four blocks or one half of the object of multicast data content as part of a block partitioning process. It is worth noting that although FIG. 3a includes a partition 310, the configuration FIG 3a may be referred to as being unpartitioned.

[0062] FIG 4a shows a series of fundamental data elements for the unpartitioned blocks from FIG. 3a arranged in a particular sequence in time after interleaving the fundamental data elements of each of the blocks. As described above, each of the eight blocks contain six symbols with each of the symbols labeled “B1 S1", “B2S1”, and so on. Notably, the time order of the symbols contained in each of the blocks is changed from the description above FIG. 3a as a result of interleaving symbols in the blocks. In particular, element 412a, representing the first symbol of the second block, (“B2S1 "), follows element 41 1 a, representing the first symbol of the first block, ("B1 S1”). Additionally, element 411 b (“B1 S2”) follows element 418a (“B8S1”) and so on up to element 418h the last symbol of the last block (“B8S6”). The interleaving configuration in FIG. 3a is a conventional interleaving, referred to as block interleaving.

[0063] FIG 4b shows a series of fundamental data elements for the blocks partitioned into two partitions 450a and 450b as in FIG. 3b arranged in a particular sequence in time after interleaving the fundamental data elements of each of the blocks. The labeling of the symbols in FIG. 4b is the same as in FIG. 4a. Again, Notably, the time order of the symbols contained in each of the blocks is changed from the description above FIG. 3b as a result of interleaving symbols in the blocks. Further, the time order sequence of the symbols is different from the time order sequence shown in FIG. 4a. In particular, element 452a, (“B2S1”), follows element 451 a, (“B1 S1”) similar to above. However, element 451 b (“B1S2”) follows element 454a (“B4S1”). Continuing a similar pattern, element 455a (“B5S1”) follows element 454h ("B4S6”) and element 455h ("B5S6”) follows element 458g (“B8S5) on up to element 458h (“B8S6”). The interleaving configuration, referred to as partition interleaving, interleaves the symbols of the blocks in the first partition 450a and then interleaves the symbols of the blocks in the second partition 450b.

[0064] The use of partitioning sets of blocks of data as shown in FIG. 4b offers advantages with respect to the delivery of media or data content to some types of receivers, particularly receivers that may have storage allocation limitations (e.g , a limited amount of RAM or other temporary memory storage). In FIG. 4a, when the block symbols of data, represented as elements 41 1a to 418h, are transmitted, the receiver must allocate storage for all blocks (“BLK1”) to (“BLK8”) simultaneously because a portion of each block is distributed across the entire time span of delivery of the block symbols. If this is not possible in the receiver, recovery of the data or media cannot be performed in a single delivery transmission of the signal. By partitioning the blocks into smaller groups, 450a and 450b in FIG. 4b, the time span for delivering all of the block symbols for a set of blocks is reduced by one half. The number of partitions may be further increased as necessary based on the storage allocation limitations of the receiver.

[0065] FIG 5 shows an exemplary screenshot 500 of a graphical user interface (GUI) associated with the block partition process used with data in a communication signal, according to aspects of the present disclosure. The GUI may be used as part of the operation of one or more elements in a content processing device, such as studio content processing device 200 described in FIG. 2. In some embodiments, a control program may be included in processor 250 that is used to control the operation of block segmenter 233, repair symbol generator 234, and partition interleaver 235. The control program also includes a GUI that can be displayed on a display element (not shown) included with studio content processing device 200. In some embodiments, a local network connection may be provided to studio content processing device 200, as described above, that allows a user or technician to control the operation of block segmenter 233, repair symbol generator 234, and partition interleaver 235 in the studio content processing device 200 through screenshot 500 as part of the GUI used with a control program on an external device. More specifically, screenshot 500 may be used for setting up some or all of the operating parameters for performing block partitioning on the multicast data. The user or technician may use the elements in screenshot 500 to control one or both of the number of blocks of multicast data that will be used in the multicast data object as well as the number of blocks that will be in each partition.

[0066] Screenshot 500 includes an entry element 510, labeled “FEO mode’’ to choose a type of FEC used as part of the multicast data. A pull down selection window 515 provides a set of choices available for the type of FEC. As shown, the selection window 515 is displaying “RaptorQ™” as the current choice. Screenshot 500 also includes an entry element 520, labeled "FEC percentage” to choose an amount of FEC to apply to the multicast data. A slide adjustment 525 provides an adjustable range, from 0% to 100 % that can be selected and a visual element 526 shows the actual percentage selected. As shown, the slider control in the entry element 510 is set to “10%” as indicated by the visual element 526. Based on the settings for entry elements 510 and 520, the multicast data will include an additional 10% of redundant information using RaptorQ™ coding as part of the FEC for the data.

[0067] Screenshot 500 additionally includes an entry element 530, labeled “Max block size” to choose the maximum number of fundamental data elements that will be in each block. An entry window 535 allows a user or technician to enter a value for the maximum number of fundamental data elements and a pull down selection window 537 provides a set of types of fundamental data elements commonly used. As shown, entry “symbols” is displayed as the current choice in selection window 537 and a value of 56403 (symbols) is shown as the choice for entry element 530 (Max Block Size). Other types of fundamental data elements that may be used in selection window 537 include, but are not limited to, packets, bytes, cells, and the like. Screenshot 500 further includes an entry element 540, labeled “Max Partition Size” to choose the maximum number of blocks that can be in each partition. An entry window 545 allows a user or technician to enter a value for the maximum number of blocks, as indicated by display element 548. As shown, a value of 255 (blocks) is shown as the choice for entry element 540 (Max Partition Size).

[0068] As a result of the entries selected in screenshot 400, once the object size for the multicast data is known (i.e., the number of fundamental data elements in the object based on the type), processing (e.g., as part of the control program described above) is used to calculate the number of symbols, blocks, and partitions required based on the object size.

[0069] To calculate the number of symbols in the object: numSymbols = ceil(ObjectSize -s- SymbolSize)

[0070] To calculate the number of blocks needed: numBlocks - ceilfnumSymbols -r- maxBSockSize)

[0071 ] It is worth noting that, as part of determining the number of blocks needed, the last block may not be the maximum block size depending on the ratio of the size of the object and the maximum block size.

[0072] To calculate the number of partitions needed: numPartitlons ~ ceil(numB locks -e maxPartitionSize)

[0073] As with the number of blocks, one or more of the partitions, such as the last partition, may not be the maximum partition size. This information is included as part of the information associated with the multicast data when it is transmitted.

[0074] I o calculate the size of the large & small blocks: largeBlockSize = ceil(numB locks -e numpartitions') smallBlockSize = floor(numBlocks + numP artitions)

[0075] To calculate the number of large & small partitions: numLar geP artitions = numP ar titions mod largeBlockSize numSmallP art itions — numPartitlons -■ numLarg ePar titions

[0076] It is worth noting that selection of the value for maximum partition size (entry element 540) should be between 1 and the total number of blocks (numBlocks in equations above), in order to increase transmission robustness and reliability to receivers that will be receiving the transmitted multicast data, the largest possible value for entry element 540 should be selected based on the expected memory limitations in the receivers.

[0077] As a simplified example, for a multicast data object requiring 54 blocks, the following maximum partition for partition interleaving the data may be identified as the possible range of acceptable maximum allowable partition sizes.

* Using a maximum partition size of 5 blocks, 11 total partitions are created. 10 partitions will interleave 5 large blocks of data and 1 small partition will interleave the remaining 4 blocks of data.

• Using a maximum partition size of 6 blocks, 9 partitions are created. All 9 partitions will interleave

6 blocks of data.

« Using a maximum partition size of 7 blocks, 8 partitions are created, 6 large partitions will interleave

7 blocks of data and 2 small partitions will interleave 6 blocks of data.

[0078] As part of the tradeoff between memory limitations of the receiver and robustness of the transmission, a maximum partition size of 5 requires less memory to recover on the receiver than a max partition size of 7. However, a max partition size of 7 allows for a more robust transmission as fundamental data elements (e.g., symbols) can be interleaved from 7 blocks as opposed to 5. A maximum partition size of 5 blocks may be selected from the above predetermined range of acceptable maximum partition sizes. In some embodiments, the selection may be performed by either a user or operator and may be based on, for example, the information for the memory limitations of the receiver.

FIG. 6 illustrates a flow chart of an exemplary process 600 for providing data for delivery as a communication signal utilizing block partitioning , according to aspects of the present disclosure, Process 600 will be primarily described with respect to a content distribution system, such as broadcast content distribution system 100, described in FIG. 1 . One or more of the elements of process 600 may be used in a content processing device, such as content processing device 200 described in FIG. 2 or studio content processing device 105 in FIG. 1 . Although process 600 depicts steps performed in a particular order for purposes of illustration and discussion , the operations discussed herein are not limited to any particular order or arrangement.

[0079]At step 610, a communication session with one or more communication receivers is established as part of delivering multicast data content from a broadcast transmitter (e.g., transmitter 120, 170 in FIG. 1) in a content distribution system (e.g , content distribution system 100). The communication session is established to deliver media or data content to the receiver(s). In some embodiments, establishing the communication session, at step 620, may further include establishing a set of communication parameters associated with the delivery of the multicast data content. The set of communication parameters may include, but are not limited to, the storage allocation limitations in the receiver for processing received multicast data content. The communication session may be established by a gateway device (e.g., broadcast gateway 110 or gateway 160) or by a processing element in the content processing device (e.g., studio content processing device 105 or content processing device 200 in FIG. 2).

[0080]At step 620, a maximum partition size is selected from a predetermined range of acceptable maximum partition sizes. The predetermined range of acceptable maximum partition sizes may be identified in a manner similar to that described above, The maximum partition size may be selected in manner to balance the robustness and reliability of the delivery of the multicast data content and storage allocation requirements available in the communication receiver(s) for processing the multicast data content In some embodiments, the storage allocation limitations are important such as when delivering multicast data content to mobile or portable communication receivers, as described above. In some embodiments, the maximum partition size is selected by an operator or a user of the content distribution system (e.g., broadcast content distribution system 100 in FIG. 1 ), such as an operator controlling the content processing device (e.g., content processing device 200 in FIG. 2). [0081 ] At step 630, the number of blocks required to break the multicast data into partitions having the maximum partition size is determined. The number of blocks may be determined in a manner similar to that described above. In particular, the number of blocks may vary between the partitions and additionally, or alternatively, the size of the blocks may vary between the partitions based on the maximum partition size selected at step 620. The determination, at step 630, may be performed in a processing element, such as a block segmenter or partition interleaver, within the content processing device (e.g., content processing device 200 in FIG, 2 or studio content processing device 105 in FIG. 1 ).

[0082] At step 640, the multicast data content is processed for delivery to the communication receiver(s) using the block partitioning determined as part of steps 620 and 630. The processing may be carried out in one or more processing elements in the content processing device (e.g content processing device 200 in FIG. 2 or studio content processing device 105 in FIG. 1 . In some embodiments, the block partitioning further uses a partition interleaving based on the maximum partition size as part of the communication session. The partition interleaving may be performed in a partition interleaver (e.g., partition interleaver 235 in FIG. 2). For example, the partition interleaving may include interleaving portions (e.g., bytes, packets, or symbols) of each block of the number of blocks within the maximum partition size in a manner similar to that described above in FIGs. 3 and 4.

[0083] In some embodiments, the processing, at step 640 may further include broadcasting the multicast data as part of a broadcast signal to the communication receiver(s). The broadcasting may be performed using a transmitter connected to a transmit antenna (e.g., transmitter 120 connected to transmitter antenna 125 and/or transmitter 170 connected to transmitter antenna 175 in FIG, 1 ). In some embodiments, the broadcast signal may be a signal complying with the advanced television systems committee (ATSC) 3.0 standard.

[0084] It is worth noting that in some embodiments, the communication receiver(s) may be configured to automatically adapt to the block partitioning without any interruption.

[0085] FIG. 7 iiiustrates a block diagram of an exemplary communication receiver 700 that can receive data content processed using block partitioning, according to aspects of the present disclosure. The communication receiver 700 may be used to receive broadcast content from a signal transmission device in a communication system. For example, the communication receiver 700 may be used to receive broadcast content delivered from transmitter 120, through transmitter antenna 135 and/or transmitter 175, through transmitter antenna 175 as part of broadcast content distribution system 100 described in FIG. 1 , The communication receiver 700 may also be used to receive content delivered using other communication or transmission methods. These methods may include, but are not limited to, satellite communications, fifth generation (5G) cellular communications, and bidirectional wireless communications, and the like. It is to be appreciated that several components and interconnections necessary for complete operation of communication receiver 700 are not shown in the interest of conciseness, as the components not shown are well known to those skilled in the art.

[0086] In communication receiver 200, a signal that is transmitted or broadcast from a signal transmission device (e.g,, transmitter antennas 125, and/or 175) is provided to receiver 220 Receiver 220 is coupled to processor 240. Processor 240 is coupled to memory 250. Processor 240 is also coupled to external storage interface 260 which communicates with external storage devices. Processor 240 is additionally coupled to user input interface 270 which communicates with, and receives Inputs from, user control elements. Processor 240 is further coupled to output interface 280 which provides audio and/or video signals to audio/visual (AAZ) elements.

[0087] Receiver 720 receives the broadcast signal through an antenna (not shown) The antenna may be located internal to an enclosure for the communication receiver 700. Additionally, or alternatively, the antenna may be located external to the disclosure and connected to the receiver 720 through a suitable RF connector, such as an F-type connector. Receiver 720 tunes and demodulates the broadcast signal to generate a data content stream containing one or more signals that can be processed in processor 740. Receiver 720 can be controlled to perform its tuning and demodulation, along with any physical layer error correction processing that is included as part of the broadcast, signal based on a specific broadcast signal transmission protocol (e.g., ATSC 3.0, ATSC 1 .0) using control signals from processor 740. The components or elements used in receiver 720 may include, but are not limited to, filters, amplifiers, frequency downconverters, analog to digital signal converters, multi-phase multi-amplitude demodulators, error correction decoders, and the like. The components or elements may be combined or integrated into one or more larger components, such as integrated circuits or multi-chip modules. In some cases, one or more of the elements may be implemented as part of firmware or software in a digital signal processor.

[0088] Processor 740 receives the one or more signals containing data and information from receiver 720 and further processes the signal(s) to separate out groups of data packets from any sub-streams present in the signal(s). Processor 740 may also reformat any of the data in the groups of data packets, as needed, for further processing in other components, such as output interface 780. For example, the data received may be in the form of content or a content stream for sound and video reproduction to a user and processor 740 may reformat the content, stream for delivery to output interface 780 as a high definition multimedia interface (HDM I) signal. Processor 740 may further receive control information associated with the broadcast signal received and processed by receiver 720. The control information may be interpreted by processor 740 and provided one or more of the elements in communication receiver 700, such as the receiver 720, and output interface 780, in order to change their operation,

[0089] It is worth noting that processor 740 may be embodied using a programmable microprocessor that is reconfigurable with downloadable instructions or software code stored in memory 750. Processor 740 may alternatively be a specifically programmed processing circuit configured as a signal and data processor as well as a controller with internal control code for controlling, managing, and processing all functions and data in communication receiver 700. Further, one or more of the elements described in communication receiver

700 may be combined into a larger component and may be implemented as a programmable microprocessor or as a specifically programmed processing circuit.

[0090] Memory 750 supports the operation of processor 740, as well as the other elements of communication receiver 700, by storing and retrieving programming instructions and data associated with the control and operation of the communication receiver 700. A portion of memory 750 stores and retrieves a portion of the broadcast signal received by receiver 720 as part of the content stream processing in processor 740, as described above. Memory 750 may include one or more of the following storage elements including, but not limited to, RAM, ROM, Electrically Erasable Programmable ROM (EEPROM), and flash memory. Memory 750 may also encompass one or more integrated memory elements including, but not limited to, magnetic media hard disk drives and optical media disk drives, that are housed within the enclosure for communication receiver 700.

[0091 ] User input interface 770 provides a mechanism for receiving inputs from a user in order to facilitate control and operation of communication receiver 700. User input interface 770 may include a user input or entry mechanism, such as a set of buttons, a keyboard, or a microphone. User input interface 770 may also include circuitry for converting user input, signals into a data communication format to provide to processor 740. User input interface 770 may further include some form of user notification mechanism to show device functionality or status, such as indicator lights. User interface 770 may also include circuitry for converting data received from processor 740 into signals that may be used to operate the user notification mechanism. It is worth noting that one or more of the input circuitry or mechanisms may be external to the communication receiver and connected to the user input interface 770 through a connector system, such as universal serial bus (USB).

[0092] Output interface 780 provides a mechanism for delivering media content, such as audio and video content, to one or more audio and/or video reproduction elements, such as a display element, or an audio speaker. Output interface 780 receives an audio and/or video signal that has been processed and generated in processor 740 and processes the signal(s) for delivery to the reproduction device Output interface 780 may include additional signal processing circuitry including, but not limited to, digital to analog converters, signal filters, digital and/or analog signal format converters, modulators, and the like. Output interface 780 may include display elements and audio speakers as part of communication receiver 700. It is worth noting that the output interface 780 may also include one or more physical connectors to connect to external devices capable of audio/video reproduction, such as televisions, sound processors, display monitors, laptop computers, and the like. The one or more physical connectors may include, but are not limited to, RCA or phone type connectors, HDMI connectors, digital visual interface (DVI) connectors, Sony/Phiiips digital interface (S/PDIF) connectors, Toshiba Link (Toslink) connectors, and F-type coaxial connectors. And the like.

[0093] In operation, the receiver 720 receives block partitioning operating parameters associated with delivery of the multicast data from a broadcast transmitter (e.g., transmitter 120 or transmitter 170 in FIG. 1). The block partitioning operating parameters include a number of blocks used to break the multicast data into a maximum partition size as described earlier. The block partitioning operating parameters along with the multicast data, representing a media or data content stream, may be delivered as part of a broadcast signal from the broadcast transmiter. In some embodiments, the block partitioning operating parameters as well as the multicast data may be included in a broadcast that complies with the AST 03.0 standard . The receiver 720 also begins receiving multicast data utilizing block partitioning delivered from the broadcast transmitter. The block partitioning operating parameters and the multicast data utilizing the block partition parameters are provided to processor 740. Processor 740 processes the received multicast data based on the received block partitioning operating parameters. In some embodiments, the processor 740 may use a partition deinterleaving process to recover the content from the multicast data based on the maximum partition size used with the block partitioning. After processing the received multicast data to recover the media or data content, the processor 740 may provide the content to the output interface 780 as part of presenting the content to a user.

[0094] It is worth noting that the same or different multicast data may be delivered by the broadcast transmitter (e.g., transmitter 120 or transmitter 170 in FIG. 1) to communication receiver 700 as well as other communication receivers using different block partitioning operating parameters, such as the maximum partition size. For example, allowing the maximum partition size to be varied instead of also adjusting the size and/or number of blocks of data representing the multicast data object, the delivery of the multicast data to communication receiver 700 and other communication receivers that have memory storage limitations is more efficient and easier. [0095] It Is also worth noting that in some embodiments, communication receiver 700 may include additional circuitry and elements that, allow the communication receiver 700 to provide a signal back to the content distribution system. For example, when used as part of a cellular data network, communication receiver 700 may also include signal transmission circuitry within receiver 720. The signal transmission circuitry may allow information and/or data, such as storage allocation limitations, to be provided back to a content processing device allowing the content processing device (e.g., content processing device 200 in FIG. 2) to make adjustments to the block partition processing of the multicast data prior to delivering the multicast data for broadcast transmission , as described above, Still further, communication receiver 700 may include circuitry and elements for an alternative network communication, such as through a wide area network and/or the internet. In this case, the communication receiver 700 may communicate to a content distribution system (e.g., broadcast content distribution system 100 in FIG. 1) through the network connection into a gateway device (e.g., gateway 160) and provide information and/or data to make adjustments to the block partition processing at the content processing device (e.g., studio content processing device 105).

[0096] FIG. 8 illustrates a now chart of an exemplary process 800 for receiving multicast data content processed using block partitioning, according to aspects of the present disclosure. The multicast data content that is processed and delivered as part of a broadcast signal in a manner similar to that described for process 600 in FIG. 6. Process 800 will be primarily described with respect to the communication receiver 700 described in FIG. 7. One or more aspects of process 800 may also be used with other type communication receivers including, but not limited to, satellite signal receivers, cellular data signal receivers, and wi-fi signal receivers, Although process 800 depicts steps performed in a particular order for purposes of illustration and discussion, the operations discussed herein are not limited to any particular order or arrangement.

[0097] At step 810, information associated with the multicast data content included in the broadcast transmission signa! is received. The information includes parameters associated with the block partitioning process applied to the multicast data representing a content or media stream prior to delivery as part of a broadcast transmission signal as described above. The information may be received in a communication receiver by a receiver circuit, such as receiver 720, and is processed in a processing device, such as processor 740. In some embodiments, the communication receiver may be a mobile or portable receiver. In some embodiments, the broadcast transmission signal may be a signal complying with the ATSC 3.0 standard.

[0098] At step 820, the multicast data content is received as part of the broadcast transmission signal. At step 830, the multicast data content, received at step 820, is processed based on the parameters associated with the block partitioning process received at step 810. In some embodiments, the processing further includes using a partition deinterleaving based on the maximum partition size. The partition deinterleaving process reverses the partition interleaving process applied prior to delivery of the multicast, data to the receiver, such as in a mariner described at step 640 of process 600 in FIG. 6, In some embodiments, the processing, at step 830, may be performed in such a manner as to automatically adapt Io the parameters associated with the block partitioning process without any interruption to providing the content or media stream from the processed multicast data content to the user as described above.

[0099] It is to be appreciated that although the embodiments described above focus on physical hardware and eiements within a signal communication system, the principles of the present disclosure may be easily extended to implementations that involve software based programming that are stored in a computer readable medium, such as a magnetic optical based storage structure. Further, in some embodiments, one or more of the elements of a process based on the principles of the present disclosure, such as process 900 described may be implemented utilizing cloud-based operations and/or storage. It is to be appreciated that, except where explicitly indicated in the description above, the various features included as part of the principles of the present disclosure can be considered cumulative and interchangeable, that is, a feature shown in one embodiment may be incorporated into another embodiment.

[0100] Although embodiments which incorporate the teachings of the present disclosure have been shown and described in detail herein, those skilled in the art can readily devise many other varied embodiments that still incorporate these teachings. Having described preferred embodiments for forward error correction block partitioning, it is noted that modifications and variations can be made by persons skilled in the art in light of the above teachings. It is therefore to be understood that changes may be made in the particular embodiments of the disclosure which are within the scope of the disclosure as outlined by the appended claims.

Claims

1 . A method for reliable delivery of multicast data by a broadcast transmitter utilizing block partitioning , the method comprising: establishing a communication session with a receiver; selecting a maximum partition size from a predetermined range of acceptable maximum partition sizes, the maximum partition size being selected to balance robustness and storage allocation requirements available in the receiver; and determining a number of blocks required to break the multicast data Into partitions having the maximum partition size, wherein at least one of the number of blocks and a size of the blocks may vary based on the maximum partition size.

2. The method of claim 1 , further comprising processing the multicast data utilizing the block partitioning as part of the communication session with the receiver.

3. The method of claim 2, wherein the block partitioning further includes using a partition interleaving based on the maximum partition size.

4. The method of claim 2, wherein the block partitioning further includes interleaving portions of each block within at least one partition having a number of blocks equal to or less than the maximum partition size.

5. The method of claim 2, wherein processing the multicast data further includes broadcasting the multicast data as part of a broadcast signal using a broadcast transmitter.

6. The method of claim 1 , wherein establishing a session with the receiver further includes establishing a set of communication parameters associated with the delivery of the multicast data, the set of communication parameters including the storage allocation limitations for multicast data available in the receiver.

7. The method of claim 1, wherein the receiver is a mobile receiver.

8. The method of claim 1, wherein the receiver is configured to automatically adapt to the block partitioning without any interruption.

9. The method of claim 1 , wherein the broadcast signal Is a signal complying with the advanced television systems committee (ATSC) 3.0 standard.

10. The method of claim 1, wherein the maximum partition size is determined based on information received from at least one of an operator or a user.

11. An apparatus for providing multicast data that utilizes block partitioning as part of delivery by a broadcast transmitter, the apparatus comprising: a controller that establishes a communication session with a receiver, the controller further providing an interface for selecting a maximum partition size from a predetermined range of acceptable maximum partition sizes, the maximum partition size being selected to balance robustness and storage allocation requirements available in the receiver; and a segmenter coupled to the controller, the segmenter determining a number of blocks required to break the multicast data into partitions having the selected maximum partition size, wherein at least one of the number of blocks and a size of the blocks may vary based on the selected maximum partition size.

12. The apparatus of claim 11 , further comprising an interleaver coupled to the segmenter, the interleaver processing the multicast data utilizing the block partitioning as part of the communication session with the receiver.

13. The apparatus of claim 12, wherein the block partitioning further includes using a partition interleaving based on the selected maximum partition size.

14. The apparatus of claim 12, wherein the block partitioning further includes interleaving portions of each block within at least one partition having a number of blocks equal to or less than the selected maximum partition size.

15. The apparatus of claim 12, wherein the processed multicast data is provided to a broadcast transmitter for broadcasting as part of a broadcast signal.

16. The apparatus of claim 11 , wherein establishing a session with the receiver further includes establishing a set of communication parameters associated with the delivery of the multicast data, the set of communication parameters including the storage allocation requirements available in the receiver.

17. The apparatus of claim 11, wherein the receiver is a mobile receiver.

18. The apparatus of claim 11, wherein the receiver is configured to automatically adapt to the block partitioning without any interruption.

19. The apparatus of claim 11 , wherein the broadcast signal is a signal complying with the ATSC 3.0 standard.

20. The apparatus of claim 11. wherein the maximum partition size is determined based on information received from at least one of an operator or a user.

21. A method for receiving multicast data utilizing block partitioning at a receiver, the multicast data delivered by a broadcast transmitter, the method comprising: receiving block partitioning operating parameters associated with delivery of the multicast data from the broadcast transmitter, the block partitioning operating parameters including a number of blocks used to break the multicast data into a maximum partition size; receiving the multicast data; and processing the received multicast data based on the received block partitioning operating parameters.

22. The method of claim 21 , wherein the processing further includes using a partition deinterleaving based on the maximum partition size.

23. The method of claim 21 , wherein the receiver is a mobile receiver.

24. The method of claim 21 , wherein the broadcast signal is a signal complying with the ATSC 3.0 standard.

25. The method of claim 21 , wherein the receiver is configured to automatically adapt to the block partitioning without any interruption.