EP1599961A1 - Procede et systeme de correction d'erreurs sans voie de retour - Google Patents

Procede et systeme de correction d'erreurs sans voie de retour

Info

Publication number
EP1599961A1
EP1599961A1 EP04717730A EP04717730A EP1599961A1 EP 1599961 A1 EP1599961 A1 EP 1599961A1 EP 04717730 A EP04717730 A EP 04717730A EP 04717730 A EP04717730 A EP 04717730A EP 1599961 A1 EP1599961 A1 EP 1599961A1
Authority
EP
European Patent Office
Prior art keywords
data
mpe
characteristic values
directional arrangements
fec
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP04717730A
Other languages
German (de)
English (en)
Inventor
Harri Pekonen
Matti Puputti
Dominique MÜLLER
András BORSOS
Jussi Vesma
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Oyj
Original Assignee
Nokia Oyj
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US10/382,334 external-priority patent/US20050013274A1/en
Priority claimed from GB0306220A external-priority patent/GB0306220D0/en
Application filed by Nokia Oyj filed Critical Nokia Oyj
Publication of EP1599961A1 publication Critical patent/EP1599961A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4363—Adapting the video stream to a specific local network, e.g. a Bluetooth® network
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/03—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words
    • H03M13/05—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits
    • H03M13/09—Error detection only, e.g. using cyclic redundancy check [CRC] codes or single parity bit
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/03—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words
    • H03M13/05—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits
    • H03M13/13—Linear codes
    • H03M13/15—Cyclic codes, i.e. cyclic shifts of codewords produce other codewords, e.g. codes defined by a generator polynomial, Bose-Chaudhuri-Hocquenghem [BCH] codes
    • H03M13/151—Cyclic codes, i.e. cyclic shifts of codewords produce other codewords, e.g. codes defined by a generator polynomial, Bose-Chaudhuri-Hocquenghem [BCH] codes using error location or error correction polynomials
    • H03M13/1515—Reed-Solomon codes
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/27—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes using interleaving techniques
    • H03M13/2703—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes using interleaving techniques the interleaver involving at least two directions
    • H03M13/2707—Simple row-column interleaver, i.e. pure block interleaving
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/29—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes combining two or more codes or code structures, e.g. product codes, generalised product codes, concatenated codes, inner and outer codes
    • H03M13/2906—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes combining two or more codes or code structures, e.g. product codes, generalised product codes, concatenated codes, inner and outer codes using block codes
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/29—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes combining two or more codes or code structures, e.g. product codes, generalised product codes, concatenated codes, inner and outer codes
    • H03M13/2906—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes combining two or more codes or code structures, e.g. product codes, generalised product codes, concatenated codes, inner and outer codes using block codes
    • H03M13/2909—Product codes
    • H03M13/2915—Product codes with an error detection code in one dimension
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/29—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes combining two or more codes or code structures, e.g. product codes, generalised product codes, concatenated codes, inner and outer codes
    • H03M13/2906—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes combining two or more codes or code structures, e.g. product codes, generalised product codes, concatenated codes, inner and outer codes using block codes
    • H03M13/2927—Decoding strategies
    • H03M13/293—Decoding strategies with erasure setting
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/29—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes combining two or more codes or code structures, e.g. product codes, generalised product codes, concatenated codes, inner and outer codes
    • H03M13/2948—Iterative decoding
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/29—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes combining two or more codes or code structures, e.g. product codes, generalised product codes, concatenated codes, inner and outer codes
    • H03M13/2957—Turbo codes and decoding
    • H03M13/296—Particular turbo code structure
    • H03M13/2963—Turbo-block codes, i.e. turbo codes based on block codes, e.g. turbo decoding of product codes
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/37—Decoding methods or techniques, not specific to the particular type of coding provided for in groups H03M13/03 - H03M13/35
    • H03M13/3707—Adaptive decoding and hybrid decoding, e.g. decoding methods or techniques providing more than one decoding algorithm for one code
    • H03M13/3715—Adaptation to the number of estimated errors or to the channel state
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/63—Joint error correction and other techniques
    • H03M13/635—Error control coding in combination with rate matching
    • H03M13/6362—Error control coding in combination with rate matching by puncturing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0006—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission format
    • H04L1/0007—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission format by modifying the frame length
    • H04L1/0008—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission format by modifying the frame length by supplementing frame payload, e.g. with padding bits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0041—Arrangements at the transmitter end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0056—Systems characterized by the type of code used
    • H04L1/0057—Block codes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0056—Systems characterized by the type of code used
    • H04L1/0071—Use of interleaving
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/85—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression
    • H04N19/89—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression involving methods or arrangements for detection of transmission errors at the decoder
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614—Multiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4381—Recovering the multiplex stream from a specific network, e.g. recovering MPEG packets from ATM cells
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6131—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via a mobile phone network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64315—DVB-H

Definitions

  • This invention relates to systems and methods for data transmission and reception.
  • a DVB transmission system usually provides bandwidth of 10 Mbps or more. This provides a possibility to significantly reduce the average DVB receiver power consumption by introducing a schema based on time division multiplexing (TDM).
  • TDM time division multiplexing
  • the introduced schema is called time slicing.
  • time slicing is to send data in bursts using significantly higher bandwidth compared to the bandwidth required if the data was transmitted using static bandwidth.
  • time to the beginning of the next burst (delta-t) is indicated.
  • data of the service is not transmitted, allowing other services to use the bandwidth otherwise allocated for the service. This enables a receiver to stay active only a fragment of the time, while receiving bursts of a requested service. If the mobile handheld terminal requires a constant lower bitrate, buffering the received bursts may provide this.
  • time slicing also supports the possibility to use the receiver to monitor neighboring cells during the off-times. And by accomplishing the switching of the reception from transport stream to another during an off period, the reception of a service is seemingly uninterrupted. In a normal DVB-T systems a smooth hand-over would require two front-ends in a single terminal.
  • the data is formatted by using, for example, a multi-protocol encapsulator in accordance with Section 7 of European Standard EN 301 192 "Digital Video Broadcasting (DVB); DVB specification for data broadcasting.”
  • the multi-protocol encapsulator sends encapsulated data to a digital broadcast transmitter for broadcast to the digital broadcast receiver as a time-slicing signal.
  • the time-slicing signal comprises a continuous series of transmission bursts.
  • DVB European Telecommunications Standards Institute
  • ETSI EN 300 744 Digital Video Broadcasting (DVB) Framing structure, channel coding and modulation for digital terrestrial television
  • networks are increasingly used for the transmission and reception of, for example, media, applications, and personal communications.
  • a method for data transmission comprising: placing one or more data segments into a two-dimensional data structure having first directional arrangements and second directional arrangements, wherein said first directional arrangements are perpendicular to said second directional arrangements, and wherein placement is with respect to said first directional arrangements; adding to each of said second directional arrangements one or more corresponding computed characteristic values; transmitting the contents of one or more of said first directional arrangements that holds portions of said characteristic values; and transmitting said one or more data segments, wherein data segments placed into said two- dimensional structure are transmitted according to a first specific format and said first directional arrangements holding portions of said characteristic values are transmitted with a second specific format in the transport stream.
  • the transmitting according to first specific format may comprise encapsulating data segments placed into said two-dimensional structure into one or more data packets having a first header and the transmitting according to second specific format may comprise encapsulating data in each first directional arrangements that holds portions of said characteristic values into a data packet having a second header.
  • Each packet header may include data structure placement information and/or data indicating data segment boundaries.
  • the encapsulated contents of one or more of said first directional arrangements holding portions of said characteristic values may be transmitted in a different burst from said encapsulated data segments.
  • a transmitter node configured to perform the method.
  • a method of receiving data comprising: receiving one or more data segments in a transport stream, providing a two- dimensional data structure having first directional arrangements and second directional arrangements, wherein said first directional arrangements are functionally perpendicular to said second directional arrangements, and wherein placement of said data segments is with respect to said first directional arrangements; wherein data segments placed into said two-dimensional structure are received according to a first specific format; said first directional arrangements also receiving portions of characteristic values that are received with a second specific format in the transport stream, and processing the data segments with respect to the second directional arrangements using the received characteristic values to provide corrected data segments with respect to the first directional arrangements.
  • Figure 1 shows a communication system according to a first embodiment of the invention
  • Fig. 2 is a diagram depicting exemplary steps involved in data transmission according to embodiments of the present invention.
  • Fig. 3 is a diagram depicting exemplary steps involved in data reception according to embodiments of the present invention.
  • Fig.4 is a diagram depicting a first loading technique according to embodiments of the present invention.
  • Fig. 5 is a diagram depicting a second loading technique according to embodiments of the present invention.
  • Fig. 6 shows an exemplary general purpose computer employable in embodiments of the present invention.
  • Fig. 7 shows a functional block diagram of an exemplary node employable in embodiments of the present invention.
  • Fig. 8 is a diagram of the protocol stack of an embodiment of the invention.
  • Fig. 9 shows a diagram of header section format of MPE-FEC and MPE section.
  • Fig. 10 shows a MPE-FEC Frame structure of an embodiment of the invention.
  • Fig. 11 shows a Table showing a description of MPE and MPE-FEC section syntaxes.
  • FIG. 1 is a block diagram of a communication system 1 according to a first embodiment of the invention.
  • the communication system comprises a content provider 2 that has access to sources 3, 4 of content, such as audio-visual content, data files or images.
  • the content may be transmitted using IP over digital broadband network, like DVB-T network, in what is known as an IP Datacasting (IPDC) service, to one or more receiving devices 5a, 5b.
  • IPDC IP Datacasting
  • the receiving devices 5a, 5b e.g. mobile telephones with video capabilities, are configured to receive data from at least two different communication channels.
  • the content data is transmitted to a network element 6, which is a server configured to receive the content data and to generate recovery data for use in forward error correction of the content data.
  • the content data is transmitted to the receiving devices 5a, 5b via a first channel.
  • the first communication channel is provided by a Digital Broadcasting (like DVB-T) network 7, which includes a transmitter 8.
  • the content is broadcast, multicast or unicast to all suitable receiving devices 5a, 5b within a cell associated with the first communication network 7.
  • the recovery data is transmitted to the receiving devices 5a, 5b via a second communication channel provided e.g. by a Third Generation (3G) mobile network 9, which includes at least a transmitter 10.
  • 3G Third Generation
  • a two-dimensional array or the like of addressable storage locations could be created and/or accessed by a transmitting node.
  • packets or the like corresponding to data to be transmitted by the node could be loaded into the two-dimensional array or the like in a columnar-wise manner (step 101).
  • packets or the like might be, for instance, Internet Protocol (IP) packets. Accordingly, the contents of a loaded packet or the like could occupy one or more addressable storage locations of one or more columns.
  • IP Internet Protocol
  • one or more characteristic values could be computed with respect to each row of the two-dimensional array or the like (step 103).
  • Such characteristic values might, for example, express forward error correction (FEC) data.
  • FEC data might be Reed-Solomon (RS) error correction data.
  • RS Reed-Solomon
  • a computed characteristic value corresponding to a row could next be written as FEC data. Accordingly, the characteristic value could occupy one or more addressable storage locations of that row.
  • characteristic values could vary dynamically.
  • FEC data e.g., Reed-Solomon data
  • the amount of parity data to be added could vary dynamically. For instance, more parity data could be added where network conditions arose that were expected to result in greater transmission error. Further the quality of transmission may be evaluated and decision of error correction can be defined.
  • each originally loaded packet might be modified by the node so as to include an indication of where it was stored in the array or the like.
  • the indication might, for instance, state the row and/or column address corresponding to the first addressable storage location that was occupied by the packet or the like.
  • Such an indication might, for instance, be stored in a header corresponding to the packet or the like.
  • the indication corresponding to a packet or the like might, for example, be added to that packet or the like by the node soon after the node placed it in the array or the like.
  • the node might place the indication soon before unloading the packet from the array or the like.
  • data corresponding to computed characteristic values are unloaded and placed into one or more packets or the like (step 107).
  • the one or more packets or the like could, for example, be IP packets.
  • Such a packet could, for example, contain all of the data corresponding to computed characteristic values stored in a particular column of the array or the like. Accordingly, such a packet could contain data corresponding to more than one characteristic value.
  • such a packet could contain portions of the data corresponding to each of one or more certain characteristic values.
  • the data corresponding to a particular characteristic value could be dispersed among more than one of such packets.
  • appended to such a packet could be an indication of where the data it held was stored in the array or the like. The indication might, for instance, state the column address corresponding to the first addressable storage location that was occupied by the held data.
  • the transmitter node takes steps to transmit to one or more recipient nodes the created packets or the like holding characteristic values or parts thereof with specific section header and the, perhaps modified, originally-loaded packets or the like.
  • the created packets or the like holding characteristic values could be dispatched in a separate burst from the, perhaps modified, originally loaded packets or the like.
  • the characteristic values or parts thereof could be added to the, perhaps modified, originally loaded packets or the like.
  • a recipient node might or not make use of characteristic values supplied by the transmitting node.
  • a recipient node might not be capable of making use of characteristic values.
  • a user corresponding to a recipient node might specify, perhaps via a graphical user interface (GUI) or other interface, that characteristic values should not be employed by the node.
  • GUI graphical user interface
  • a recipient node might, as will be discussed in greater detail below, make a determination as to whether or not characteristic values should be employed.
  • a recipient terminal that, for instance, is incapable of making use of characteristic values, and/or has determined and or received indication that it would not or might not make use of characteristic values, might, in various embodiments, act not to receive packets or the like dispatched by the transmitting node at all, or to receive them and to store some or all of them in a manner of its own choosing.
  • the node might then make use of the received, perhaps modified, originally loaded packets or the like in a conventional manner.
  • the node might delete from storage the received packets corresponding to characteristic values.
  • Such packets maybe recognized, for example, via an dentifier such as PID (Program Identifier) or the like.
  • such a recipient node may act to drop packets or the like holding characteristic values without storing them.
  • the node could, in accordance with various embodiments, recognize such packets or the like in a number of ways.
  • packets could be recognized by their headers. More specifically, the headers of such packets might specify, for instance, a different source IP address or the like than those specified by the headers of the, perhaps modified, originally loaded packets or the like.
  • the node can perform appropriate actions to determine if the characteristic values would be employed. Such determination will be discussed in greater detail below.
  • the recipient node determines and/or receives an indication that the characteristic values are not to be employed, the node could act to, perhaps after storing the received packets or the like in a manner of its own choosing, make use of the received, perhaps modified, originally loaded packets or the like in a conventional manner.
  • the recipient node can create and/or access a two-dimensional array or the like corresponding to the array or the like created and/or accessed by the transmitting node.
  • the array or the like created and/or accessed by the recipient node can, for example, possess one or more properties in common with the array or the like created and/or accessed by the transmitting node.
  • the array or the like created and/or accessed by the recipient node could be of the same size and/or be addressed in the same way as the array or the like created and/or accessed by the transmitting node.
  • the transmitting node could, for example, dispatch to the recipient node an indication of properties relating to its created and/or accessed array or the like.
  • properties could include, for example, array or the like column size, row size, addressing information, and/or the like.
  • it could be established that indicated such properties be observed by all specified transmitting and recipient nodes. A system administrator or the like could set such properties.
  • the recipient node loads into its array or the like the received packets or the like holding characteristic values and the, perhaps modified, originally loaded packets or the like (step 207).
  • the loading could be in accordance with any received row and/or column address indications of the sort noted above. Accordingly, through such loading, the array or the like of the recipient load could come to match the transmitting node's array or the like before it was emptied. It is noted that, in various embodiments, such address indications would not need to be received in order for the recipient node to be able to load its array or the like so as to match the transmitting node's array or the like before it was emptied. For instance, where multiprotocol encapsulation (MPE) is employed, the recipient node might employ transport stream (TS) continuity counter values in such loading of its array or the like.
  • MPE multiprotocol encapsulation
  • TS transport stream
  • the recipient node Having effectively caused its array or the like to match the transmitting node's array or the like before it was emptied, the recipient node will have reassembled the above-noted characteristic values (step 209). As a next step, the recipient node may apply each of one or more of the characteristic values to its corresponding row in the array or the like (step 211). Such application could, for example, perform FEC with respect to received, perhaps modified, originally loaded packets or the like.
  • not all characteristic values would be applied. For example, where there is more than one characteristic value per row, less than all of those values might be applied to that row. As another example, corresponding characteristic values might be applied to each of one or more certain rows, while no corresponding characteristic values might be applied to one or more other rows.
  • the recipient node could act to unload its array or the like in a columnar-wise manner so as to extract the, perhaps modified and perhaps affected (e.g., corrected) in accordance with one or more characteristic values, originally-loaded packets or the like (step 213).
  • the node could then make use of those extracted packets or the like in a conventional manner.
  • the recipient node affecting (e.g., correcting) the, perhaps modified, originally-loaded packets or the like as they are stored in the array or the like
  • such application might be performed, for example with respect to such packets after their extraction from the array or the like.
  • iterative use of characteristic values e.g., Reed-Solomon data
  • turbo decoding could be employed. The performance of such turbo decoding, could involve, for example, repeated iterative of row-wise and columnar-wise use of characteristic values and/or data resulting from the application of those values. The iteration could also be performed between the proposed FEC decoding and some lower layer FEC decoding capable of delivering soft bit information.
  • embodiments described herein may discuss the use of packets or the like, embodiments of the present invention are applicable in an analogous manner, for instance, to bit streams or the like. Still further, it is noted that although the embodiments described herein may discuss computation of characteristic values with respect to rows, other techniques might be employed. For instance, in various embodiments, characteristic values might be calculated in a zigzag form. Additionally, although the embodiments described herein discuss columnar-wise loading of the array or the like, various embodiments of the present invention may act differently. For instance, such loading could be in a row-wise manner. The functionality for such embodiments would be analogous to those discussed herein, but with columnar operations being performed row-wise, and row-wise operations being performed in a columnar manner.
  • the characteristic values and sets of characteristic values maybe computed by selecting a number of data elements from an array having data segments comprising one or more data elements placed in row-wise or column-wise in the a ⁇ ay and applying the computation to the selected elements and placing the resulting characteristic value into one or more predetermined places reserved for characteristic values in the same or in another array.
  • the selection of the data elements may comprise selecting all or some of the elements in one row or column. Other selection methods, such as, for example, selecting elements from one or more diagonals in the array (zigzag), may be used as well as selecting the data elements according to a prescribed pattern.
  • the data elements are selected from the array in a random manner, wherein the number of elements may be fixed and the transmitter and the receiver know the random selection pattern.
  • all data elements in the array are not necessarily used in the computations, and in other embodiments of the invention some of the elements may be used more than one time in the computations for one or more characteristic values.
  • data to be transmitted is handled by a modified DVB encapsulator.
  • the encapsulator has the capability of receiving IP packets carried over Ethernet frames and outputting TS packets.
  • the modified encapsulator receives Ethernet frames sequentially.
  • the encapsulator might act to arrange and/or drop frames based on, for example, Ethernet MAC address and/or IP packet address. Criteria could be pre-determined, for instance, based on the nature of the data to be transmitted.
  • Ethernet frame structure is removed.
  • MPE multiprotocol encapsulation
  • layer-3 e.g. IP
  • IP IP
  • MAC media access control
  • FEC calculation is done row-wise. It is noted that, in the case where the IP datagrams are stored row- wise, rather than column-wise as just described, the FEC is calculated column-wise. In either case, IP datagram storing and FEC calculation could be thought of as being functionally disposed to one another at a 90 degree angle. It is also noted that IP datagrams could, alternatively, be transmitted in parallel of FEC calculation. In such a case, copies of IP datagrams could be left into memory to be used in FEC calculation. Each MPE-FEC section's address in memory is stored in a header.
  • MAC address bytes in the header of MPE section could be reserved for this purpose, in which case an MPE-FEC section's address in memory could be stored in the MAC (media access control) address bytes.
  • calculated FEC bytes i.e. the FEC data in a RS data table (transported in MPE-FEC sections) is separated from Application data (transported in MPE sections).
  • the Application data is carried within MPE sections, while RS data is carried within MPE-FEC sections.
  • each MPE section and MPE-FEC section carry data from one MPE-FEC frame only.
  • MPE-FEC Frame To cany all data of a MPE-FEC frame, multiple MPE sections and/or MPE-FEC sections may be needed. After this, all IP datagrams with MPE specific section format and FEC data with MPE-FEC specific section format are placed into TS packet payloads as a MPE-FEC Frame shown in Fig 10. In this exemplary embodiment, application data and RS data are sent in TS packets with the same PID value. Again, to prevent different MPE-FEC frames get mixed, interleaving of MPE section and MPE-FEC sections carrying data from different MPE-FEC Frames is not allowed.
  • the receiving node perhaps after filtering desired TS packets (e.g., packets with PID value "A"), removes TS packet headers and forms a respective table as in transmitting node from respective IP datagrams and FEC data from the TS packet payload data.
  • desired TS packets e.g., packets with PID value "A"
  • the receiving node stores received Application data (that has been transmitted to it in MPE sections) and RS data (that has been transmitted in MPE-FEC sections) into a decoding table or array.
  • the receiving node uses address values from MPE section headers and MPE-FEC section headers.
  • the receiver a ⁇ anges the received data in the receiver buffer memory. Based on the "address" bits from the real-time parameters (section header). Address specifies the location of the Application data datagram in the Application table and the MPE-FEC section payload in the FEC (RS) table.
  • MPE- FEC frames first and last sections are identified by address and burst boundary bits respectively.
  • the table_boundary can have a value of 0 in all but the last section of the application data and the RS data table (Fig. 11).
  • the size of the MPE-FEC Frame assuming the number of columns is known, following method can be used: Assuming the size of each MPE-FEC sections of the MPE-FEC frame is equal, the number of rows is the payload size of a single MPE-FEC section multiplied by the number of MPE-FEC sections and the result divided by the number of columns used in the RS data table. A "last_section_number" field within each MPE-FEC section indicates the number of MPE-FEC sections within a MPE-FEC Frame.
  • corrected IP datagrams that contain IP packet data are stored, preferably into same interleaving memory or forwards the data to the IP stack of the terminal to which the receiver is attached.
  • the IP datagrams are processed sequentially, and the IP datagram headers and trailers are removed. The resultant IP packets are passed on for conventional use.
  • time division multiplexing TDM
  • time slicing schema in which the receiver is turned on only for predefined reception times.
  • the receiver detects beginning and/ or end of the burst, and the receiver detects also beginning and/ or end of the frame.
  • MPE-FEC frame and time slicing may be used together, and then a time slice burst corresponds to a MPE-FEC frame. But it is possible to use FEC without timeslicing and timeslicing without FEC.
  • MPE sections and MPE-FEC sections may be carried in the same burst. In such case, the size of a burst is counted for MPE and MPE-FEC together.
  • MPE and MPE-FEC sections that belong together are transmitted on the same elementary stream (ES).
  • the ES is identified by the PID, which is an attribute of the transport stream packet header (transport stream packets form the MPEG-2 layer in the protocol stack picture).
  • the terminal knows which MPE sections and MPE-FEC sections belong to the same MPE-FEC frame because of the
  • FEC_frame_continuity_counter one of the real-time parameters, transported in the MPE section header and MPE-FEC section header respectively.
  • the FEC_frame_continutity_counter is not necessary.
  • the terminal knows which MPE sections and MPE-FEC sections belong to the same MPE-FEC frame (identical with burst) by the timing, ie. it wakes up, receives MPE and MPE- FEC sections of the burst, then goes to sleep again until the next burst starts.
  • the retransmission feature of Time Slicing can be used.
  • the MPE sections are carried in an "original burst", and MPE-FEC section in "copy bursts". It is possible to differentiate bursts as "original burst” and "copy burst” by using real time parameters in connection with MPE header section headers: SI descriptor: mode 1 (one mode) or 2 (three modes) bits max_burst_duration 3 bits max_frame_size N bits datajpadding_columns N bits rs_padding_columns N bits
  • MPE-FEC Frame Inside one elementary stream all the sections between the first and the last section of a MPE-FEC Frame belong to same MPE-FEC Frame as the first and the last section. Inside one elementary stream all the sections of the frame shall be transmitted between (and including) the first and the last section of the frame (i.e. interleaving sections of different MPE-FEC Frames is not allowed). Between first and last section inside one frame, sections may or may not need to be transmitted in order.
  • the MPE-FEC frames can be differentiated inside one elementary stream e.g. First and the last section maybe identified within the frame by following options:
  • Continuity counter or Adding a long time between MPE-FEC frames which can be achieved for example by binding one frame to be delivered within one time slice bursts, i.e. when receiver detects beginning and/ or end of the burst, receiver detects also beginning and/ or end of the frame, respectively.
  • Differentiation of different MPE-FEC frame streams may be conducted by lower level protocol (TS in DVB) identifier (PID in DVB) to identify frames from each other, i.e. in DVB we may use one elementary stream (e.g. identified by PID) per MPE-FEC frame stream.
  • TS in DVB lower level protocol
  • PID in DVB identifier
  • a two-dimensional array or the like of the sort noted above could, in accordance with various embodiments of the present invention, be loaded in a number of ways.
  • implementation could be such that only one packet or the like (e.g., IP packet) is loaded per column.
  • array row and/or column size could be chosen such that a column would be capable of holding a maximally-sized packet or the like.
  • the remaining portion of the column might be filled with "stuff data". As specific example, the remaining portion could be filled with zeros.
  • exemplary Fig. 4 Shown in exemplary Fig. 4 is loading of the sort just described.
  • exemplary packet or the like 301 is maximally sized, so no stuff data is added to the column 303 in which it resides.
  • packet or the like 305 is of less than the maximal size, and, accordingly, stuff data 307 is added to its column such that the combination of packet or the like 305 and stuff data 307 occupies the entire column. It is also possible that one or more entire columns contain only stuff data. Such columns may be placed before, between, or after the columns containing data, or a combination of these maybe used.
  • implementation could be such that in the case where a packet or the like did not fully occupy the column into which it was loaded, loading of the column could continue with the next packet or the like to be loaded into the array or the like. Further, in the case where a packet being loaded into a column could not fully fit into that column, those portions which did not fit could be placed in one or more additional column.
  • Such functionality could be implemented, for example, in such a manner that where a particular packet or the like did not fully fit inside a column, the column would be filled with contents of the packet or the like up to the column's last addressable element (e.g., the element of the column having the highest row-wise address), and the remainder of the packet or the like could be placed in the following column, starting with that columns first addressable element (e.g., the element of the column having the lowest row-wise address).
  • the column's last addressable element e.g., the element of the column having the highest row-wise address
  • exemplary Fig. 5 Shown in exemplary Fig. 5 is loading of the sort just described.
  • exemplary packet or the like 401 does not fully fill column 403 into which it was loaded, and the remainder of column 403 is accordingly filled with portions of packet or the like 405.
  • packet or the like 405 can not fully fit with in the portion of column 403 left unfilled by packet or the like 401, the remainder of that packet or the like is placed in column 407, starting, in this example, with the first element (e.g. the element of the column having the lowest row-wise address).
  • stuff data might be placed between placed packets or the like.
  • Such functionality might be implemented, for instance, with the goal of rounding out the lengths of packets or the like so that the length of a packet or the like and its associated stuff data would have, for instance, a length that was a whole wordlength (byte) multiple.
  • addressing schemes for the corresponding array or the like could be simplified, as, for embodiments where loading was to be columnar-wise, row-wise addressing could be implemented with a whole-byte granularity.
  • Implementation could, for example, be such that it would be understood at the recipient node that received packets or the like were to be placed in the first addressable element of the indicated column (e.g., the element of the column having the lowest row-wise address), and that unfilled portions of such a column were to be filled with stuff data.
  • the recipient node e.g., the element of the column having the lowest row-wise address
  • unfilled portions of such a column were to be filled with stuff data.
  • an indication of the sort noted above might need to specify both a row-wise and columnar address.
  • an addressing scheme could be determined for an array or the like of the sort noted above.
  • selection of addressing scheme might be viewed as having the effect of determining the number of addressable elements in that array or the like.
  • selection of a row-wise addressing scheme might be viewed as having the effect of determining the number of rows in an array or the like of the sort noted above
  • selection of a columnar-wise addressing scheme might be viewed as having the effect of determining the number of columns in an array or the like of the sort noted above.
  • selection of row- wise and columnar-wise addressing schemes might, when thought of with respect to an array or the like of a particular size, be thought of as selection of the size of each addressable element of the array or the like.
  • an array or the like of the sort noted above could be implemented so that both row and column addressing were implemented with one-byte granularity.
  • columnar-wise addressing could be chosen so as to make maximal use of available address space. For instance, where 32-bit addressing was available, columnar addressing could be chosen so as to allow for the maximum possible number of columns, the determination perhaps talcing into account the maximum size of data (e.g., IP packets) to be stored in the array or the like.
  • rowwise addressing could be implemented such that the resultant number of rows was optimized for channel error behavior.
  • row-wise addressing could be implemented such that the resultant number of rows would be consistent with the properties of a particular characteristic value determination (e.g., FEC) technique.
  • FEC characteristic value determination
  • column height could be chosen to be consistent with the maximal size of a packet or the like of the sort to be loaded into the array or the like. Alternately, some other value might be chosen. Such choice might be performed- for example, by a system administrator or other individual.
  • the row width for an array or the like with a column height so chosen could be selected in a number of ways. For instance, the row width could be chosen by deciding upon a maximum number of packets or the like that would be allowed to be sent within a burst, and then determining the extra room in the array or the like that would be required for the corresponding characteristic value or values. For such embodiments, array or the like characteristics could be known by transmitting nodes and recipient nodes ahead of time.
  • the width of an array may be chosen to comply with the selected method for computing characteristic values. The selected method can determine both the number of columns for data and the number of columns for characteristic values. As an example, the selection of Reed-Solomon encoding 255 can lead to 191 columns for data and 64 columns for characteristic values.
  • transmitting nodes could vary size of the array or the like for each burst dispatched.
  • a transmitting node might select column height and row width in such that the corresponding array or the like could hold all of the packets or the like and any corresponding characteristic data to be transmitted within a particular burst.
  • the transmitting node could act in a similar manner, but in accordance with a specified and/or fixed column height or row width. Where, for example, column height was specified, such column height might be consistent with the maximal size of a packet or the like of the sort to be loaded into the array or the like, or might be some other value.
  • a transmitting node could, as alluded to above, dispatch to a recipient node one or more size indications. It is noted that in various embodiments where the size of the array or the like is fixed, in the case where less than all of the array or like is used, the transmitting node might send to a recipient node an indication of what portion of the array or the like is to be used. Such an indication might be, for example, an address.
  • a recipient node might perform appropriate actions to determine if received characteristic values should be employed. Such actions might be performed, for example, in accordance with instructions placed by the node's user via, for instance, a GUI or other interface. Various schemes could be employable by a node for determining of characteristic values could be employed.
  • a scheme could be employed wherein a recipient node would determine if there were errors in the received, perhaps modified, packets or the like originally-loaded by the corresponding transmitting node.
  • the recipient node might, for example, employ CRC (Cyclic Redundancy Check) techniques in making the determination. In the case where errors were found, the recipient node might act to employ one or more of the received characteristic values.
  • CRC Cyclic Redundancy Check
  • other lower layer channel decoding maybe used for determination. The use of lower layer channel decoding may also give indication of where e ⁇ ors are.
  • the recipient node might act to employ, for each of those rows, only one of the corresponding characteristic values.
  • the recipient node might make such choice, for instance, in accordance with characteristics corresponding to detected error.
  • characteristics might include, for example, error type, extent, and/or the like.
  • the recipient node might choose to apply corresponding characteristic values with respect to certain rows but not others. As above, the recipient node might make such choice, for instance, in accordance with characteristics corresponding to detected error.
  • a recipient node might only act to employ received characteristic values if it determined that it had sufficient memory available. Having sufficient memory could, for instance, mean having sufficient memory to create and/or access an array or the like corresponding to the array or the like created and/or accessed by the corresponding transmitting node, and/or having sufficient memory to perform operations with regard to received characteristic values.
  • Performance of such a scheme could involve, for example, the recipient node consulting a specification of the required size for the array or the like, determining its amount of free and/or freeable memory, and determining if sufficient memory was available. As another example, performance of such a scheme could alternately or additionally involve the recipient node determining the amount of memory to perform operations with regard to received characteristic values.
  • the specification of required size could, for example, be included in a dispatched indication of the sort noted above. As another example, the specification of required size could be in compliance with a size set to be employed for all arrays or the like as discussed above.
  • a recipient node might only act to employ received characteristic values if it determined that there was sufficient energy (e.g., battery power) and/or available processing capacity to do so.
  • energy e.g., battery power
  • a recipient node could make the above-noted determination of the type, extent, and/or the like of errors to be corrected.
  • the node might next, perhaps taking into account the type or types of included characteristic data included (e.g., Reed- Solomon data), make an estimate of the necessary energy and/or available processing capacity to correct the errors. Viewing the estimate in light of determined available energy and/or processing capacity, the node could decide if there was sufficient energy and/or processing capacity to make use of the characteristic data.
  • the node could make the estimate, for example, by performing calculations using accessible algorithms, software modules, and/or the like. As another example, the node could make the estimate by consulting an accessible store that associated error types, error extents, and/or the like to be corrected with required energies and/or available processing capacities. The node could determine available energy and/or processing capacity, for instance, using functions provided by its operating system and/or loaded software modules.
  • a recipient node might only act to employ received characteristic values for certain services, channels, data types, and/or the like. For instance, a recipient node might only act to employ received characteristic data for software and/or file downloads.
  • a node's user might, in various embodiments, be able to specify the services, channels, data types, and/or the like for which received characteristic data should be employed. Further, in various embodiments, such might be specifiable by a system administrator or the like. Further services, channels, data types and/or the like may influence to payment of them and it may occur through graphical user interface (GUI) of the terminal.
  • GUI graphical user interface
  • a transmitting node may compute and employ characteristic values only for certain services, channels, data types, and/or the like.
  • Fig. 8 an example of the transmission protocol stack is shown.
  • Some basis for the transmission of the embodied invention can be based on the ISO/IEC 13818-1 MPEG-2 based stream transmission.
  • TS can be based on the transmission according to the ISO/IEC 13818-1.
  • PSI/SI tables contain the information necessary to announce and discover the transmitted service.
  • the MPE and FEC tables can be added to the protocol stack of Fig. 8 in parallel to the basics PSI SI information.
  • the PSI defines the table for focusing i.e.
  • the MPE focuses on the IP data packet, i.e. the IP payload.
  • the payload can be included in the MPE section packet along with a header.
  • the MPE section packet can be applied in the higher level FEC frame for the error correction procedure.
  • the FEC focuses on FEC payload.
  • the FEC based and MPE based information can be separated in respect to each other.
  • the FEC based information or the like and the MPE based information or the like are necessarily not broken into apart for good but the idea in some embodiments is to identify the FEC information and the MPE information with different header.
  • the FEC based information and MPE based information is preferably, in parallel with respect to the PSI and SI hierarchy layer level so that in some embodiments it is possible to perform and set the basis for the separation possibly in an early stage of the broadcast transmission/reception.
  • the PSI/SI set a basis for the early and basics service discovery.
  • a header for the protection payload relating, thus, to the MPE application data table or MPE section packets can be denoted by a unique identifying value or name.
  • the example in Fig. 9 is given with value Table_id set to correspond with N.
  • a header for the FEC data can be denoted by a unique identifying value or name.
  • the example in Fig. 9 is given with value Table id set lo indicate a value M. It should be noted that other values/characters can be presented to unique or at least with respect to each other separate and identify the MPE application data table and the FEC data table.
  • MPE can be employed in various embodiments of the present invention. As also alluded to above, such MPE might, for example, be DSM-CC MPE. Information regarding MPE can be found, for example, in ETSI document TR 101 202, incorporated herein by reference. An exemplary use of MPE in accordance in embodiments of the present invention is shown in Fig. 2.
  • a transmitting node places data segments into MPE DSM-CC sections packets or the like (e.g., IP packets) carrying data corresponding to computed characteristic values and or, perhaps modified, originally-loaded packets or the like (e.g., IP packets) (step 109).
  • the DSM-CC sections could, for example, be placed in MPEG-2 TS packets (step 111).
  • a first PID value is associated with TS packets carrying data corresponding to the, perhaps modified, originally-loaded packets or the like, while a second PID value is associated with TS packets carrying data corresponding to characteristic values.
  • the TS packets may be transmitted over a link such as, for example, a DVB link i.e. in a common elementary stream.
  • the characteristic values can be FEC data such as RS codes and that the encapsulated data can be placed in MPE-FEC frames as shown in Figure 10.
  • the application data segments may comprise layer-3 datagrams, namely IP datagrams. These IP datagrams are written columnwise into the two dimensional array structure at the transmitter node as previously described with reference to Figure 2.
  • the columns 101 shown in Figure 2 are loaded in to the application data table in a MPE-FEC frame shown in Figure 10. Each position in the array hosts an information byte.
  • the left part of the frame consists of the 191 leftmost columns, are dedicated for OSI layer 3 (Network layer) datagrams (e.g. IP datagrams) and possible padding, and is called the Application data table ADT in Figure 10.
  • the right part of the frame consists of 64 rightmost columns which are dedicated for the parity information of the FEC code and is referred to as the RS data table , which labeled RST in Figure 10.
  • Each byte position in the Application data table has an address ranging from 0 to 1 1 x number of rows - 1.
  • each byte position in the RS data table has an address ranging from 0 to 64 x number of rows - 1.
  • the Layer 3 datagrams are introduced datagram-by-datagram, starting with the first byte of the first datagram in the upper left corner of the matrix and going downwards the first column.
  • the length of the datagrams may vary arbitrarily from datagram to datagram. Immediately after the end of one datagram the following datagram starts. If a datagram does not end precisely at the end of a column, it continues at the top of the following column.
  • any unfilled byte positions are padded with zero bytes, which makes the leftmost 191 columns completely filled.
  • the position of the delivered RS data in the RS data table is indicated with a section_number. Section 0 carries the first (left most) column of the RS data table, section 1 carries the second column, and so on. Any columns not delivered are always the right most columns of the RS data table.
  • This 18-bit field specifies the byte position in the Application data table or RS data table of Figure 10 for the first byte of the payload carried within the section. All sections delivering data for Application data table or RS data table are delivered in ascending order according to the value of this field.
  • the bytes position is a zero-based linear address within Application data table or RS data table, starting from the first row of the first column, and increasing towards the end of the column. At the end of the column, the next byte position is at the first row of the next column.
  • the first section carrying data of a given MPE-FEC Frame is MPE section carrying the Application data datagram at address "0". All sections carrying Application data datagrams of a given MPE-FEC Frame are transmitted prior to the first section carrying RS-data of the MPE-FEC Frame (i.e. sections carrying Application data datagrams shall not be interleaved with sections carrying RS-data within a single MPE-FEC frame). All sections carried between the first and the last section of an MPE-FEC Frame carry the data belonging to the MPE-FEC Frame (i.e. only Application data and RS-data are allowed). Sections delivering data of different MPE-FEC Frames are not interleaved.
  • the section following the last section carrying Application data datagram on an MPE-FEC Frame contains either the first section carrying the RS-data of the same MPE-FEC Frame, or the first Application data section of the next MPE-FEC Frame.
  • RS- data of the first MPE-FEC Frame is not transmitted, for example when not needed by the recipient node.
  • Figure 10 is schematic and corresponds to columnar datagrams of equal length. This is theoretically possible and a network operator who manages and administers the network may define the height of the columns. However, in practice, the size of IP datagrams changes from datagram to datagram and typically the sizes are between -100...1500 Bytes and unfilled parts of the datagrams may be filled with '0' padding as previously described.
  • the RS data is computed by considering the rows of the array of application data table 101 in Figure 10 to create the configuration 103 shown in Figure 2, and the resulting rows of RS data are loaded into the RS data table of Figure 10.
  • the RS codes are computed to a predetermined resolution such as RS(255,191 or 64) and is calculated for every row separately.
  • the MPE-FEC frame of Figure 10 is emptied, starting from the first IP datagram of the application data table.
  • the IP datagrams are packed in MPE sections. (1 IP datagram per MPE section)
  • the address of IP datagram in application the data table 101 is put into a MPE section header field.
  • each MPE section and MPE-FEC section carries real time parameters in its header field as described in Table 1 below.
  • real time parameters are carried within the MAC_address_4...MAC_address_l , which would otherwise be unused, thereby optimizing bandwidth.
  • the RS bytes of each column of the MPE-FEC table are packed together an individual MPE-FEC section. As shown in Figure 11 the RS bytes are put to RS-FEC bytes).
  • the real time parameters are coupled to MPE-FEC section header respectively as done to MPE sections above.
  • the length of the MPE-FEC section - indicates to the receiver the number of rows of used in the MPE-FEC frame. The number of rows is signaled to the receiver in the time_slice_fec_identifier_descriptor.
  • the maximum allowed value for this is 1024, which makes the total MPE-FEC frame almost 2 Mbits in this example. All calculated RS data bytes need not to be sent depending on the capacity and/or service quality e.g. if the end user is happy with less quality of service. For example, such a packet could contain portions of the data corresponding to each of one or more certain characteristic values.
  • the exact amount of punctured RS columns does not need to be explicitly signalled and may change dynamically between frames.
  • the exact number of padding columns of the Application data table is signaled in the header of each MPE-FEC section. This 8-bit field indicates the number of full columns of the Application data table of the actual MPE-FEC Frame filled with padding bytes only. The value indicated shall be from 0 to 190.
  • the number of punctured RS columns can be calculated as 63 - last_section_number, since last_section_number indicates the section number of the last section. As the section numbering is zero based, the indicated number is one less than the number of columns.
  • the receiver introduces the number of padding bytes in the Application data table, as indicated in the MPE-FEC sections. These padding bytes it marks as reliable.
  • the receiver also introduces the number of punctured RS columns as calculated from last_section_number. The actual data in the introduced punctured RS columns are irrelevant, as all punctured data is considered unreliable.
  • All MPE and MPE-FEC sections are protected by a CRC-32 code, which reliably detects all erroneous sections. For every correctly received section belonging to the Application data table or to the RS data table, the receiver looks in the section header for the start address of the payload within the section and is then able to put the payload in the right position the respective table.
  • a recipient node having received TS packets of the sort noted above (step 201), can extract the DSM-CC sections carried by these packets (step 203).
  • the node cextracts from those DSM-CC sections packets or the like (e.g., IP packets) carrying data corresponding to computed characteristic values and/or carried, perhaps modified, originally-loaded packets or the like (e.g., IP packets) (step 205).
  • DSM-CC MPE has been discussed here, it will be noted that other MPE techniques could be employed. It is further noted that although the foregoing has described implementation of MPE such that DSM-CC sections are not placed into the array or the like, in various embodiments DSM-CC sections carrying above-described packets or the like could be placed there.
  • Puncturing corresponds to calculating all the characteristic values (all columns) but then some columns are discarded or "punctured" and therefore not transmitted. Puncturing can be performed in the embodiments described herein by discarding one or more of the last RS data columns.
  • the number of discarded (punctured) RS columns may vary dynamically between MPE-FEC frames within the range [0-63] and can be calculated as 63 - last_section_number, except for the case when no RS columns are transmitted (puncturing is 64 columns). Puncturing will decrease the overhead introduced by the RS data and thus decrease the needed bandwidth.
  • the drawback of puncturing is an effectively weaker error checking code rate.
  • the manner in which characteristic values were computed can vary dynamically.
  • characteristic values corresponded to FEC data e.g., Reed-Solomon data
  • the amount of parity data to be added could vary dynamically. For instance, more parity data could be added where network conditions arose that were expected to result in greater transmission error. Furthermore conditions when less parity information may be satisfactory may also exist.
  • This descriptor identifies whether Time Slicing or MPE-FEC are used on an elementary stream. Note that when this descriptor specifies an elementary stream being Time Sliced and/or MPE- FEC being used, a data_broadcast_descriptor parameter is provided in a service description for a particular service. This defines a MAC_address_range of value 0x01 or 0x02, indicating that the MAC_address_1...4 bytes are not used to differentiate receivers within the elementary stream. This descriptor is allowed in following tables: o Network Information Table (NIT) o When located in the first descriptor loop, the descriptor applies to all transport streams announced within the actual table.
  • NIT Network Information Table
  • descriptor ag will have a predetermined own value agreed by a standard.
  • descriptor_length This 8-bit field specifies the number of bytes of the descriptor immediately following this field.
  • time_slicing This 1-bit field indicates, whether the referred elementary stream is Time Sliced. Value '1' indicates Time Slicing being used. Value '0' indicates that Time Slicing is not used.
  • mpe_fec This 2-bit field indicates, whether the referred elementary stream uses MPE-FEC, and what algorithm is used. Coding can be as stipulated in Table 2 below.
  • time_slicing is set to "0" (i.e. Time Slicing not used)
  • this field is reserved for future use and shall be set to 0x00 when not used.
  • frame_size This 5-bit field is used to give information that a decoder may use to adapt its buffering usage. The exact interpretation depends on whether Time Slicing and/or MPE-FEC are used.
  • this field indicates the maximum number of bits on section level allowed within a Time Slice burst on the elementary stream. Bits are calculated from the beginning of the table_id field to the end of the CRC_32 field.
  • this field indicates the exact number of rows on each MPE-FEC Frame on the elementary stream.
  • the receiver shall assume the maximum burst size greater than 2
  • Computer refers but are not limited to a processor card smart card, a media device, a personal computer, an engineering workstation, a PC, a Macintosh, a PDA, a computerized watch, a wired or wireless terminal, a server, a network access point, a network multicast point, or the like, perhaps running an operating system such as OS X, Linux, Darwin, Windows CE, Windows XP, Palm OS, Symbian OS, or the like, perhaps with support for Java or .Net.
  • exemplary computer 5000 as shown in Fig.6 includes system bus 5050 which operatively connects two processors 5051 and 5052, random access memory 5053, read-only memory 5055, input output (I/O) interfaces 5057 and 5058, storage interface 5059, and display interface 5061.
  • Storage interface 5059 in turn connects to mass storage 5063.
  • Each of I O interfaces 5057 and 5058 may be an Ethernet, IEEE 1394, IEEE 1394b, IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE 802.16a, IEEE P802.20, Bluetooth, terrestrial digital video broadcast (DVB-T), satellite digital video broadcast (DVB-S), digital audio broadcast (DAB), general packet radio service (GPRS), universal mobile telecommunications service (UMTS), or other interface known in the art.
  • IEEE 1394, IEEE 1394b, IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE 802.16a, IEEE P802.20 Bluetooth, terrestrial digital video broadcast (DVB-T), satellite digital video broadcast (DVB-S), digital audio broadcast (DAB), general packet radio service (GPRS), universal mobile telecommunications service (UMTS), or other interface known in the art.
  • Mass storage 5063 may be a hard drive, optical drive, or the like.
  • Processors 5057 and 5058 may each be a commonly known processor such as an IBM or Motorola PowerPC, an AMD Athlon, an AMD Opteron, an Intel ARM, an Intel XScale, a Transmeta Crusoe, or an Intel Pentium.
  • Computer 5000 as shown in this example also includes an display unit 5001, a keyboard 5002 and a mouse 5003. In alternate embodiments, keyboard 5002, and/or mouse 5003 might be replaced and/or augmented with a touch screen, pen, and or keypad interface.
  • Computer 5000 may additionally include or be attached to card readers, DVD drives, floppy disk drives, and/or the like whereby media containing program code may be inserted for the purpose of loading the code onto the computer.
  • a computer may run one or more software modules designed to perform one or more of the above-described operations.
  • modules could be programmed using languages such as Java, Objective C, C, C#, and or C++ according to methods known in the art.
  • Corresponding program code might be placed on media such as, for example, DVD, CD-ROM, and/or floppy disk. It is noted that any described division of operations among particular software modules is for purposes of illustration, and that alternate divisions of operation maybe employed. Accordingly, any operations discussed as being performed by one software module might instead be performed by a plurality of software modules. Similarly, any operations discussed as being performed by a plurality of modules might instead be performed by a single module.
  • embodiments of the invention may disclose certain software modules, tiers, and/or the like as operating on certain devices, in alternate embodiments these modules, tiers, and/or the like might be distributed to run on other devices than those staled. For example, operations disclosed as being performed by a particular computer might instead be performed by a plurality of computers. It is further noted that, in various embodiments, grid computing techniques may be employed.
  • the receiving device 5a may be a mobile telephone with multimedia capabilities, which receives incoming data using one or more antennae 14 or several antennas and one or more receivers 15. For example, multiple antennae 14 and receivers 15 would be needed where the first and second communication network utilise different radio technologies. Especially this the case when the other communication link e.g. GSM, GPRS or 3G type communication link and the other one digital broadband, like DVB communication link as described in Fig. 1.
  • a battery 23 powers the mobile telephone 5a. As the reception of data consumes a large proportion of the battery power, the consumption of battery may be controlled, e.g.
  • the terminal of Fig. 7 has been discussed in the foregoing. In the following, corresponding reference signs have been applied to corresponding parts.
  • Terminal 5 of Fig. 7 maybe used in any/all of the embodiments described herein.
  • the terminal 5 comprises a processing unit CPU 20, a multi-carrier signal terminal part 15 and a user interface 24.
  • the multi-carrier signal terminal part 15 and the user interface 24 are coupled with the processing unit CPU 20.
  • DMA channels may exist between multi-carrier signal terminal part 15 and memory 21, 22.
  • the user interface 24 comprises a display and a keyboard to enable a user to use the terminal 5.
  • the user interface 24 comprises a microphone and a speaker for receiving and producing audio signals.
  • the user interface 24 may also comprise voice recognition (not shown).
  • the processing unit CPU 20 comprises a microprocessor (not shown), memory 604 and possibly software.
  • the software can be stored in the memory 21, 22.
  • the microprocessor controls, on the basis of the software, the operation of the terminal 5, such as the receiving of the data stream, the tolerance of the impulse burst noise in the data reception, displaying output in the user interface and the reading of inputs received from the user interface. The operations are described above.
  • the hardware contains circuitry for detecting the signal, circuitry for demodulation, circuitry for detecting the impulse, circuitry for blanking those samples of the symbol where significant amount of impulse noise is present, circuitry for calculating estimates, and circuitry for performing the corrections of the corrupted data.
  • the terminal 5 can be a hand-held device that the user can comfortably carry.
  • the terminal 5 can be a cellular mobile phone which comprises the multi-carrier signal terminal part 15 for receiving the multicast transmission stream. Therefore, the terminal 5 may possibly interact with the service providers.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Mathematical Physics (AREA)
  • Quality & Reliability (AREA)
  • Algebra (AREA)
  • General Physics & Mathematics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

L'invention porte sur des systèmes et des procédés qui permettent d'utiliser un réseau bidimensionnel ou similaire dans la transmission et/ou la réception de données, au moyen duquel on peut calculer des valeurs caractéristiques se rapportant aux données à transmettre. Les valeurs caractéristiques sont transmises conjointement avec les données et peuvent être utilisées par un destinataire de données. Elles pourraient également intégrer des données de correction d'erreurs sans voie de retour. On peut mettre en oeuvre ces différents systèmes et procédés pour un certain nombre de réseaux dont, par exemple, les réseaux de radiodiffusion vidéonumérique.
EP04717730A 2003-03-05 2004-03-05 Procede et systeme de correction d'erreurs sans voie de retour Withdrawn EP1599961A1 (fr)

Applications Claiming Priority (11)

Application Number Priority Date Filing Date Title
US10/382,334 US20050013274A1 (en) 2003-03-05 2003-03-05 System and method for data transmission and reception
US382334 2003-03-05
GB0306220A GB0306220D0 (en) 2003-03-18 2003-03-18 System and method for data transmission and reception
GB0306220 2003-03-18
GB0309093 2003-04-22
GB0309093A GB0309093D0 (en) 2003-03-18 2003-04-22 System and method for data transmission and reception
GB0309234 2003-04-23
GB0309234 2003-04-23
PCT/US2003/012682 WO2004079956A1 (fr) 2003-03-05 2003-04-23 Systeme et procede de transmission et de reception de donnees
WOPCT/US03/12682 2003-04-23
PCT/IB2004/050204 WO2004079982A1 (fr) 2003-03-05 2004-03-05 Procede et systeme de correction d'erreurs sans voie de retour

Publications (1)

Publication Number Publication Date
EP1599961A1 true EP1599961A1 (fr) 2005-11-30

Family

ID=32966768

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04717730A Withdrawn EP1599961A1 (fr) 2003-03-05 2004-03-05 Procede et systeme de correction d'erreurs sans voie de retour

Country Status (3)

Country Link
EP (1) EP1599961A1 (fr)
UA (1) UA84557C2 (fr)
WO (1) WO2004079982A1 (fr)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2406483A (en) * 2003-09-29 2005-03-30 Nokia Corp Burst transmission
GB2406488A (en) * 2003-09-29 2005-03-30 Nokia Corp Sigalling in a communications network
GB2408433A (en) 2003-11-18 2005-05-25 Nokia Corp Datacasting service components sequentially within a burst
GB0420540D0 (en) * 2004-09-15 2004-10-20 Nokia Corp Burst transmission in a digital broadcasting network
EP1732235B1 (fr) * 2004-12-08 2013-02-13 Panasonic Corporation Dispositif de reception, circuit integre, programme, et procede de reception
US7738409B2 (en) * 2005-04-13 2010-06-15 Nokia Corporation System and method for wireless communications
AU2006248710B2 (en) * 2005-05-19 2011-01-20 Nokia Corporation System and method for providing unequal error protection to priority labeled datagrams in a DVB-H transmission system
FR2890519B1 (fr) * 2005-09-06 2007-12-28 Thales Sa Procede d'optimisation de l'utilisation de la bande passante d'une emission a diffusion en rafales
TWI415416B (zh) 2005-09-19 2013-11-11 St Ericsson Sa 在包含消除表格資料的移動式無線應用中用於校正錯誤的裝置及方法
TWI430611B (zh) 2005-09-19 2014-03-11 St Ericsson Sa 在包含旁路校正的移動式無線應用中用來校正錯誤的裝置與方法
TWI401910B (zh) * 2005-09-19 2013-07-11 St Ericsson Sa 在包含多層級與可適性消除資料的移動式無線應用中用來校正錯誤的裝置與方法
US8929444B2 (en) 2007-02-19 2015-01-06 Freescale Semiconductor, Inc. Data communication unit, data communication network and method of decoding
KR101983032B1 (ko) * 2012-05-07 2019-05-30 삼성전자주식회사 방송 및 통신 시스템에서 패킷 송수신 장치 및 방법
CN112333470B (zh) * 2020-10-27 2022-05-27 杭州叙简科技股份有限公司 一种基于视频帧的fec纠错系统
WO2022089752A1 (fr) * 2020-10-29 2022-05-05 Nokia Technologies Oy Codage réseau pour rafales de paquets de données

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03141752A (ja) * 1989-10-27 1991-06-17 Hitachi Ltd 画像信号伝送方法
AU665716B2 (en) 1993-07-05 1996-01-11 Mitsubishi Denki Kabushiki Kaisha A transmitter for encoding error correction codes and a receiver for decoding error correction codes on a transmission frame
AU2188500A (en) 1998-12-15 2000-07-03 Tiernan Communications, Inc. Method and apparatus for backward-compatible error correction for real time communication link

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2004079982A1 *

Also Published As

Publication number Publication date
WO2004079982A1 (fr) 2004-09-16
UA84557C2 (uk) 2008-11-10

Similar Documents

Publication Publication Date Title
US7747930B2 (en) Method and system for forward error correction
AU2003234204B2 (en) System and method for data transmission and reception
US8209586B2 (en) Burst transmission in a digital broadcasting network
EP1629615B1 (fr) Transmission par rafales
JP4242419B2 (ja) サービスインフォメーションにおけるタイムスライシングパラメーター信号伝達方法
EP1609264B1 (fr) Procede, systeme et entite reseau a protection d'en-tetes pour transmission et reception de donnees
EP1599961A1 (fr) Procede et systeme de correction d'erreurs sans voie de retour
US7877663B2 (en) Forward error correction decoders
JP4664413B2 (ja) 順方向エラー修正方法及びシステム
NZ541905A (en) Method and system for forward error correction

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20050808

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20101029

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20140211

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA CORPORATION

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20140624