WO2017145790A1 - 受信装置、送信装置、及び、データ処理方法 - Google Patents

受信装置、送信装置、及び、データ処理方法 Download PDF

Info

Publication number
WO2017145790A1
WO2017145790A1 PCT/JP2017/004848 JP2017004848W WO2017145790A1 WO 2017145790 A1 WO2017145790 A1 WO 2017145790A1 JP 2017004848 W JP2017004848 W JP 2017004848W WO 2017145790 A1 WO2017145790 A1 WO 2017145790A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
header
payload
alp
transmission
Prior art date
Application number
PCT/JP2017/004848
Other languages
English (en)
French (fr)
Inventor
道人 石井
ロックラン ブルース マイケル
高橋　和幸
Original Assignee
ソニー株式会社
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
Application filed by ソニー株式会社 filed Critical ソニー株式会社
Priority to JP2018501567A priority Critical patent/JPWO2017145790A1/ja
Priority to US16/078,138 priority patent/US20200044774A1/en
Priority to EP17756231.1A priority patent/EP3422618A4/en
Publication of WO2017145790A1 publication Critical patent/WO2017145790A1/ja

Links

Images

Classifications

    • 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/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/0061—Error detection 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/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
    • H04L1/0083—Formatting with frames or packets; Protocol or part of protocol for error control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC

Definitions

  • the present technology relates to a receiving device, a transmitting device, and a data processing method, and more particularly, to a receiving device, a transmitting device, and a data processing method that can prevent packets from being discarded unnecessarily.
  • ATSC Advanced Television Systems Committee
  • the present technology has been made in view of such a situation, and is to be able to prevent packets from being discarded unnecessarily.
  • the receiving device is a plurality of transmission packets arranged in a payload of a baseband packet after demodulation, which is an IP including a header including an error detection code and a UDP (User Datagram Protocol) packet Internet Protocol)
  • a processing unit configured to process the transmission packet including a payload in which the packet is arranged, the processing unit performs an error detection process using the error detection code included in the header of the transmission packet It is a receiver.
  • the receiving device may be an independent device or an internal block that constitutes one device.
  • a data processing method is a data processing method corresponding to the receiving device according to the first aspect of the present technology described above.
  • a plurality of transmission packets are arranged in a payload of a baseband packet after demodulation, and include a header including an error detection code and a UDP packet.
  • the transmission packet including the payload in which the IP packet is arranged is processed, and an error detection process is performed using the error detection code included in the header of the transmission packet.
  • the transmission device is a transmission packet disposed in the payload of a baseband packet before modulation, and includes a header including an error detection code and a payload in which an IP packet including a UDP packet is disposed.
  • the processing unit includes a processing unit configured to generate the transmission packet, and the processing unit is a transmitting device that arranges a plurality of the transmission packets in a payload of the baseband packet.
  • the transmission device of the second aspect of the present technology may be an independent device or an internal block that constitutes one device. Further, a data processing method according to a second aspect of the present technology is a data processing method corresponding to the transmission device according to the second aspect of the present technology described above.
  • a transmission packet is disposed in the payload of a baseband packet before modulation, and includes a header including an error detection code and an IP including a UDP packet.
  • the transmission packet including the payload in which the packet is arranged is generated, and a plurality of the transmission packets are arranged in the payload of the baseband packet.
  • the receiving device is a baseband packet after demodulation, and includes a plurality of transmission packets including a header including an error detection code and a payload in which an IP packet including a UDP packet is arranged.
  • a processing unit configured to process the baseband packet including the arranged payload, wherein the processing unit performs the error detection processing using the error detection code included in the header of the baseband packet is there.
  • the receiving device of the third aspect of the present technology may be an independent device or an internal block that constitutes one device. Further, a data processing method according to a third aspect of the present technology is a data processing method corresponding to the receiving device according to the third aspect of the present technology described above.
  • the baseband packet after demodulation includes a header including an error detection code and a payload in which an IP packet including a UDP packet is arranged.
  • the baseband packet composed of a payload in which a plurality of transport packets are arranged is processed, and an error detection process is performed using the error detection code included in the header of the baseband packet.
  • the transmission device is a transmission packet disposed in a payload of a baseband packet before modulation, the transmission packet including a payload in which an IP packet including a UDP packet is disposed.
  • the transmission unit may include a processing unit that generates an error detection code in the header of the baseband packet, and the plurality of transmission packets in the payload of the baseband packet.
  • the transmission device of the fourth aspect of the present technology may be an independent device or an internal block that constitutes one device. Further, a data processing method according to a fourth aspect of the present technology is a data processing method corresponding to the transmission device according to the fourth aspect of the present technology described above.
  • the transmission packet is placed in the payload of the baseband packet before modulation, and includes the payload in which the IP packet including the UDP packet is placed.
  • the transmission packet configured is generated, an error detection code is placed in the header of the baseband packet, and a plurality of the transmission packets are placed in the payload of the baseband packet.
  • FIG. 1 is a diagram illustrating a configuration of an embodiment of a transmission system to which the present technology is applied. It is a figure which shows the structural example of a transmitter. It is a figure which shows the structural example of a receiver. It is a figure which shows the correlation of the packet used by this technique. It is a figure which shows the structure of BB header added to BB packet. It is a figure which shows the example of an optional field flag. It is a figure which shows the example of the syntax of the ALP header of an ALP packet. It is a figure which shows the example of the syntax of additional_header_for_single_packet ().
  • FIG. 1 is a diagram showing the configuration of an embodiment of a transmission system to which the present technology is applied.
  • a system is a system in which a plurality of devices are logically gathered.
  • the transmission system 1 includes a transmitting device 10 and a receiving device 20.
  • data transmission conforming to the digital broadcast standard such as ATSC 3.0 is performed.
  • IP including UDP / IP packets, that is, UDP (User Datagram Protocol) packets, not TS (Transport Stream) packets
  • UDP User Datagram Protocol
  • TS Transport Stream
  • the transmitter 10 transmits the content via the transmission path 30.
  • the transmitting apparatus 10 transmits a broadcast stream including signaling and video, audio, and the like that constitute content such as a broadcast program and the like via a transmission path 30 as a broadcast wave.
  • the receiving device 20 receives and outputs the content transmitted from the transmitting device 10 via the transmission path 30.
  • the receiving device 20 receives a broadcast wave from the transmitting device 10, acquires from the broadcast stream video and audio (components of the content) and signaling that constitute the content, and generates video and audio of content such as a broadcast program. To play.
  • the transmitting device 10 transmits Broadcast waves to be distributed can be received simultaneously by a plurality of receiving devices 20 via the transmission path 30.
  • a plurality of transmission devices 10 can also be provided.
  • Each of the plurality of transmitting devices 10 transmits a broadcast wave including a broadcast stream as a separate channel, for example, in a separate frequency band, and in the receiving device 20, from among the respective channels of the plurality of transmitting devices 10 , A channel to receive the broadcast stream can be selected.
  • the transmission path 30 is satellite broadcasting using, for example, a broadcasting satellite (BS: Broadcasting Satellite) or a communication satellite (CS: Communications Satellite) in addition to terrestrial waves (terrestrial broadcasting).
  • BS Broadcasting Satellite
  • CS Communications Satellite
  • CATV cable broadcasting
  • FIG. 2 is a diagram showing a configuration example of the transmission device 10 of FIG.
  • the transmitting apparatus 10 includes an AV encoder 101, a FLUTE encoder 102, a UDP / IP packetizer 103, an ALP packetizer 104, a BB packetizer 105, a scrambler 106, a BCH encoder 107, an LDPC encoder 108, a parity interleaver 109, column twist.
  • the AV encoder 101 encodes (components of) video and audio data according to a predetermined coding scheme, and supplies the encoded data to the FLUTE encoder 102.
  • the FLUTE encoder 102 processes (encodes) the data from the AV encoder 101 to generate data corresponding to a File Delivery over Unidirectional Transport (FLUTE) format, and supplies the data to the UDP / IP packetizer 103.
  • FLUTE File Delivery over Unidirectional Transport
  • the UDP / IP packetizer 103 processes the data from the FLUTE encoder 102 to generate an IP packet (UDP / IP packet) including a UDP packet, and supplies the IP packet to the ALP packetizer 104.
  • the ALP packetizer 104 processes UDP / IP packets from the UDP / IP packetizer 103 to generate ALP (ATSC Link layer Protocol) packets and supplies them to the BB packetizer 105.
  • ALP ATSC Link layer Protocol
  • the BB packetizer 105 processes the ALP packet from the ALP packetizer 104 to generate a BB (Base Band) packet and supplies it to the scrambler 106.
  • the scrambler 106 scrambles the data (BB packet) from the BB packetizer 105, and supplies the resultant data to the BCH encoder 107.
  • the BCH encoder 107 performs BCH (Bose-Chaudhuri-Hocquenghem) encoding on the data from the scrambler 106, and supplies the resulting data to the LDPC encoder 108.
  • the LDPC encoder 108 performs low density parity check (LDPC) coding on the data from the BCH encoder 107, and supplies the resulting data to the parity interleaver 109.
  • BCH Bit-Chaudhuri-Hocquenghem
  • the parity interleaver 109 performs parity interleaving on the data from the LDPC encoder 108, and supplies the data after the parity interleaving to the column twist interleaver 110.
  • the column twist interleaver 110 performs column twist interleaving on the data from the parity interleaver 109, and supplies the data after the column twist interleaving to the data mapper 111.
  • the data mapper 111 maps the data from the column twist interleaver 110 to signal points representing one symbol of orthogonal modulation in units of one or more code bits (symbols) of the data (LDPC code). Orthogonal modulation (multi-level modulation) is performed.
  • the data obtained by the processing by the data mapper 111 is supplied to the cell interleaver 113 via the CQ delay unit 112.
  • the cell interleaver 113 performs cell interleaving on the data from the CQ delay unit 112, and supplies the data after cell interleaving to the time interleaver 114.
  • the time interleaver 114 performs time interleaving on the data from the cell interleaver 113, and supplies the data after time interleaving to the frame mapper 115.
  • the frame mapper 115 processes the data from the time interleaver 114 regarding frames (physical layer frames), and supplies the resulting data to the frequency interleaver 116.
  • the frequency interleaver 116 performs frequency interleaving on the data from the frame mapper 115, and supplies the data after frequency interleaving to the OFDM transmission unit 117.
  • the OFDM transmitting unit 117 processes the data from the frequency interleaver 116 to generate an orthogonal frequency division multiplexing (OFDM) signal and supplies the signal to the RF output unit 118.
  • the RF output unit 118 is connected to an antenna (not shown), and transmits the OFDM signal from the OFDM transmission unit 117 via the transmission path 30 as an RF (Radio Frequency) signal.
  • the transmitter 10 is configured as described above.
  • FIG. 3 is a diagram showing a configuration example of the receiving device 20 of FIG.
  • the receiving apparatus 20 includes an RF input unit 201, an OFDM receiving unit 202, a frequency deinterleaver 203, a frame demapper 204, a time deinterleaver 205, a cell deinterleaver 206, a CQ delay unit 207, and a data demapper.
  • column twist deinterleaver 209 parity deinterleaver 210, LDPC decoder 211, BCH decoder 212, descrambler 213, BB depacketizer 214, ALP depacketizer 215, UDP / IP depacketizer 216, FLUTE decoder 217, and AV decoder 218 Configured
  • the RF input unit 201 is connected to an antenna (not shown), receives an RF signal transmitted from the transmission apparatus 10 via the transmission path 30, and supplies the signal as an OFDM signal to the OFDM reception unit 202.
  • the OFDM receiving unit 202 processes the OFDM signal from the RF input unit 201 and supplies data obtained thereby to the frequency deinterleaver 203.
  • the frequency deinterleaver 203 frequency deinterleaves the data from the OFDM reception unit 202, and supplies the data after frequency deinterleaving to the frame demapper 204.
  • the frame demapper 204 performs processing on a frame (physical layer frame) on the data from the frequency deinterleaver 203, and supplies the resulting data to the time deinterleaver 205.
  • the time deinterleaver 205 subjects the data from the frame demapper 204 to time deinterleaving, and supplies the data after time deinterleaving to the cell deinterleaver 206.
  • the cell deinterleaver 206 performs cell deinterleaving on the data from the time deinterleaver 205, and supplies the data after cell deinterleaving to the data demapper 208 via the CQ delay unit 207.
  • the data demapper 208 demaps the data (data on the constellation) from the CQ delay unit 207 based on the arrangement (constellation) of the signal points determined by the orthogonal modulation performed on the transmitting device 10 side.
  • Point constellation decoding is performed to perform orthogonal demodulation, and the resulting data (LDPC code) is supplied to the column twist deinterleaver 209.
  • the column twist deinterleaver 209 performs column twist deinterleaving on the data from the data demapper 208, and supplies the data after the column twist deinterleaving to the parity deinterleaver 210.
  • the parity deinterleaver 210 performs parity deinterleave on the data from the column twist deinterleaver 209, and supplies the data after the parity deinterleave to the LDPC decoder 211.
  • the LDPC decoder 211 performs LDPC decoding on the data from the parity deinterleaver 210, and supplies the resulting data to the BCH decoder 212.
  • the BCH decoder 212 BCH decodes the data from the LDPC decoder 211, and supplies the resulting data to the descrambler 213.
  • the descrambler 213 descrambles the data from the BCH decoder 212, and supplies the resulting data to the BB depacketizer 214.
  • the BB depacketizer 214 extracts and processes BB packets from the data from the descrambler 213, and supplies the resulting data to the ALP depacketizer 215. Further, error correction information is input to the BB depacketizer 214 from the LDPC decoder 211 or the BCH decoder 212. This error correction information is information indicating that an error has occurred in the processing of LDPC decoding or BCH decoding, and in the BB depacketizer 214, data that can not be corrected by LDPC decoding or BCH decoding by the error correction information. It can recognize that exists.
  • the ALP depacketizer 215 extracts and processes ALP packets from the data from the BB depacketizer 214 and supplies the resulting data to the UDP / IP depacketizer 216.
  • the UDP / IP depacketizer 216 extracts and processes UDP / IP packets from the data from the ALP depacketizer 215 and supplies the resulting data to the FLUTE decoder 217.
  • the FLUTE decoder 217 processes (decodes) data (data corresponding to the FLUTE format) from the UDP / IP depacketizer 216 and supplies the resultant data to the AV decoder 218.
  • the AV decoder 218 decodes the data from the FLUTE decoder 217 according to a predetermined decoding scheme, and outputs (the component of) video and audio data obtained as a result.
  • the receiving device 20 is configured as described above.
  • FIG. 4 is a diagram showing the correlation of packets used in the present technology.
  • the BB (Base Band) packet is a baseband layer 1 packet.
  • An ALP (ATSC Link layer Protocol) packet is a packet (transmission packet) of layer 2 which is an upper layer of layer 1.
  • An IP (Internet Protocol) packet is a packet of layer 3 which is an upper layer of layer 2.
  • the IP packet includes a UDP (User Datagram Protocol) packet.
  • the BB packet is composed of a BB header and a payload (BB packet payload).
  • One or more ALP packets are arranged in the payload of the BB packet.
  • the BB header contains information such as packet length and pointer. This pointer represents the position of the first ALP packet placed in the payload of the BB packet. In the following description, this pointer is referred to as a leading ALP pointer.
  • the maximum size of the BB packet is 8196 bytes.
  • An ALP packet is composed of an ALP header (ALP Header) and a payload (ALP payload).
  • ALP header contains information such as the packet length.
  • the ALP packet has a variable length, and its maximum size is 65536 bytes.
  • one or more ALP packets arranged in the payload of the BB packet can be extracted by using the head ALP pointer of the BB header and the packet length of the ALP header (packet length of the ALP packet). That is, if the position of a given ALP packet is specified using a leading ALP pointer in a given BB packet, the packet length of the ALP header is assumed even if the ALP packet is placed across the next BB packet. By using this, the position of the next ALP packet can be identified.
  • FIG. 4 illustrates the case where three ALP packets are arranged for three BB packets
  • some BB packets include ALP packets arranged across a plurality of BB packets. Existing.
  • the second ALP packet is placed across the first to third BB packets.
  • the position of the first (head) ALP packet is specified by the head ALP pointer of the BB header of the first (head) BB packet, so that the payload of the first (head) BB packet is determined. It is extracted.
  • the third ALP packet is extracted from the payload of the third BB packet by specifying its position by the top ALP pointer of the BB header of the third BB packet.
  • the position according to the packet length is specified from the top ALP pointer (of the BB header of the first BB packet) by the packet length of the ALP header of the first and second ALP packets It is extracted from the payloads of the first to third BB packets.
  • the value of the beginning ALP pointer of the BB header of the second BB packet is “0”.
  • ALP_packet_header which is a basic header (ALP Base Hdr) as the ALP header of the ALP packet
  • ALP_header which is an additional header
  • ALP Add Hdr an additional header
  • An extension header which is ALP Opt Hdr
  • IP packet is composed of an IP header (IP Header) and a data part (Data).
  • IP Header IP header
  • Data data part
  • a UDP packet is placed in the data portion of the IP packet.
  • the IP header of the IP packet is: Version (Ver), Header Length (Head Len), Service, Total Length (Total Len), ID, Flag, Flag offset, TTL (Time To Live), Protocol, Checksum, Source IP address ( Src Add), Destination IP address (Dest Add), and Option.
  • the maximum size of the IP packet is 65536 bytes.
  • the UDP packet is composed of a UDP header (UDP Header) and a data part (Data). In the data portion of the UDP packet, components such as video and audio and data of signaling are arranged.
  • the UDP header of the UDP packet has Source port number (Src Port), Destination port number (Dest Port), Length, and Checksum.
  • the maximum size of the UDP packet is 65,507 bytes.
  • FIG. 5 is a diagram showing the structure of the BB header added to the BB packet.
  • the BB packet is composed of a BB header and a payload.
  • BB header in addition to a 1- or 2-byte base field (Base Field), an optional field (Optional Field) and an extension field (Extension Field) can be arranged.
  • Base Field base field
  • Optional Field optional field
  • Extension Field Extension Field
  • a 7-bit pointer (Pointer (LSB)) is arranged.
  • This pointer is the top ALP pointer described above, and indicates the position of the top ALP packet placed in the payload of the BB packet. For example, when data of an ALP packet placed last in a certain BB packet is placed across the next BB packet, the position of the first ALP packet placed in the next BB packet is set as the first ALP pointer. It can be set.
  • a 6-bit pointer (Pointer (MSB))
  • an optional 2-bit flag besides a 7-bit pointer (OPTI: OPTIONAL)
  • the optional flag is information indicating whether or not to extend the header by arranging an optional field and an extension field.
  • the optional flag when extension of the optional field and the extension field is not performed, "00" is set in the optional flag.
  • the optional flag is set to “01”, which is a short extension mode.
  • the optional flag is set to "10" or "11”, and Long Extension Mode or Mixed Extension Mode It becomes.
  • extension_TYPE 3-bit extension type
  • EXT_TYPE 3-bit extension type
  • EXT_TYPE 5-bit extension data length
  • Extension 0 to 31 bytes of extension data
  • extension_TYPE extension type
  • EXT_LEN 5-bit extension data length
  • MSB 8-bit extension data length
  • Extension Extension
  • FIG. 7 is a diagram showing an example of the syntax of the ALP header.
  • the 3-bit packet_type indicates the packet type of the ALP packet.
  • One-bit payload_configuration is set to "0" or "1" according to the information set in the ALP header.
  • header_mode When “0" is specified as payload_configuration, header_mode and length are arranged in the ALP header.
  • One-bit header_mode indicates a header mode.
  • the 11-bit length indicates the packet length of the ALP packet (ALP packet length).
  • additional_header_for_single_packet is placed in the ALP header as an additional header.
  • the detailed structure of this additional_header_for_single_packet () will be described later with reference to FIG.
  • segmentation_concatenation length is placed in the ALP header. “1” is set to “0” or “1” according to the type of the additional header in 1 bit of segmentation_concatenation.
  • the 11-bit length indicates the packet length of the ALP packet (ALP packet length).
  • additional_header_for_segmentation is placed in the ALP header as an additional header.
  • the detailed structure of this additional_header_for_segmentation () will be described later with reference to FIG.
  • additional_header_for_concatenation is placed as an additional header in the ALP header.
  • the detailed structure of this additional_header_for_concatenation () will be described later with reference to FIG.
  • uimsbf unsigned integer most significant bit first
  • bslbf bit string, left bit first
  • FIG. 8 is a diagram illustrating an example of the syntax of additional_header_for_single_packet () of FIG. 7.
  • the 5-bit length_MSB indicates the packet length of the most significant bit (MSB: Most Significant Bit).
  • One-bit SIF indicates a flag indicating whether a substream ID (sub_stream_identification) exists. If there is a substream ID, SIF is set to "1".
  • sub_stream_identification is placed in the ALP header. The detailed structure of this sub_stream_identification () will be described later with reference to FIG.
  • header_extension () is arranged in the ALP header as an extension header. The detailed structure of this header_extension () will be described later with reference to FIG.
  • FIG. 9 is a diagram illustrating an example of the syntax of additional_header_for_segmentation () in FIG. 7.
  • segment_sequence_number indicates a segment sequence number.
  • last_segment_indicator indicates an indicator of the last segment.
  • SIF indicates a flag indicating whether a substream ID exists. If "1" is specified as SIF, sub_stream_identification () is placed in the ALP header. Moreover, HEF shows the flag of whether the extension header exists. If “1" is specified as HEF, header_extension () is placed in the ALP header. The detailed structures of sub_stream_identification () and header_extension () will be described later with reference to FIGS. 11 and 12.
  • FIG. 10 is a diagram illustrating an example of the syntax of additional_header_for_concatenation () of FIG. 7.
  • the 5-bit length_MSB indicates the packet length of the most significant bit (MSB).
  • the 3-bit count indicates a count value. In accordance with this count value, 12 bits of component_length are arranged.
  • component_length indicates the component length.
  • the 1-bit HEF indicates a flag indicating whether an extension header is present. If "1" is specified as HEF, header_extension () is placed in the ALP header. The detailed structure of header_extension () will be described later with reference to FIG.
  • FIG. 11 is a diagram illustrating an example of a syntax of sub_stream_identification () in FIGS. 8 and 9.
  • the 8-bit SID indicates a substream ID.
  • FIG. 12 is a diagram illustrating an example of the syntax of header_extension () in FIGS. 8 to 10.
  • the 8-bit extension_type indicates an extension type.
  • the 8-bit extension_length indicates the extension data length. In the extension loop according to the extension data length, 8-bit extension_byte is arranged. As this extension_byte, data of the extension type specified by the extension_type is arranged according to the extension data length specified by the extension_length.
  • extension type specified by the extension_type of the extension header (header_extension) of the ALP header is distinguished from the extension type (EXT_TYPE) of the optional field (Optional Field) of the BB header shown in FIG. For convenience, it is called "extended data type”.
  • one or more ALP packets placed in the payload of the BB packet have the header ALP pointer of the BB header and the packet length of the ALP header (packet of ALP packet By using long), it is read from the BB packet.
  • the BB depacketizer 214 can recognize that an error that can not be corrected by LDPC or BCH has occurred using this error correction information, only information indicating the presence or absence of an error is notified. I can not recognize if an error has occurred.
  • FIG. 13 is a diagram for explaining the current packet processing.
  • an error that can not be corrected by LDPC or BCH occurs in the payload of the first ALP packet among a plurality of ALP packets arranged in the payload of the BB packet.
  • the BB depacketizer 214 can recognize that an error that can not be corrected by LDPC or BCH is occurring according to the error correction information, the error occurred because the error occurrence position can not be identified. Discard not only the first ALP packet but also all ALP packets placed in the payload of the BB packet.
  • the current packet processing is executed by the BB depacketizer 214 to the UDP / IP depacketizer 216 (FIG. 3) of the reception apparatus 20 (FIG. 1) or the like.
  • step S511 the BB depacketizer 214 acquires the next processing target BB packet.
  • step S512 the BB depacketizer 214 applies the BB packet (a plurality of ALP packets arranged in the payload) acquired in the process of step S511 based on the error correction information from the LDPC decoder 211 or the BCH decoder 212. It is determined whether an error (LDPC / BCH error) that can not be corrected by the LDPC decoder 211 or the BCH decoder 212 has occurred.
  • step S512 If it is determined in step S512 that an LDPC / BCH error has occurred in the processing-targeted BB packet, the process returns to step S511, and the next processing-targeted BB packet is acquired (S511).
  • the BB depacketizer 214 when an error that can not be corrected by the LDPC decoder 211 or BCH decoder 212 occurs, all ALP packets placed in the payload of the BB packet in which the LDPC / BCH error has occurred. To get the next BB packet to be processed.
  • step S512 determines whether the ALP packet placed in the payload of the BB packet to be processed is in the middle of the ALP packet.
  • step S513 If it is determined in step S513 that the packet is not in the middle of the ALP packet, the process proceeds to step S514.
  • step S514 the BB depacketizer 214 acquires the BB header of the BB packet to be processed. Also, in step S515, the BB depacketizer 214 acquires the leading ALP pointer included in the BB header acquired in the process of step S514.
  • step S516 the BB depacketizer 214 acquires the ALP header of the processing target ALP packet (head ALP packet) based on the position specified by the top ALP pointer acquired in the process of step S515.
  • step S517 the BB depacketizer 214 acquires the ALP packet length (packet length of ALP packet) included in the ALP header acquired in the process of step S516.
  • step S518 the BB depacketizer 214 obtains the payload of the ALP packet to be processed.
  • the process proceeds to step S519.
  • step S519 it is determined whether the processing-targeted BB packet has ended. If it is determined in step S519 that the BB packet to be processed has not ended, the process proceeds to step S520.
  • step S520 it is determined whether the ALP packet to be processed has ended. If it is determined in step S520 that the ALP packet to be processed has not ended, the process returns to step S518, and the subsequent processing is repeated. That is, the payload of the processing target ALP packet is acquired until the processing target BB packet ends ("YES" in S519) or the processing target ALP packet ends ("YES" in S520) ( S518).
  • step S520 If it is determined in step S520 that the ALP packet to be processed has ended, the process proceeds to step S521.
  • step S521 UDP / IP processing is performed.
  • step S521 ends, the process proceeds to step S516.
  • the next ALP packet to be processed (ALP header or payload) is processed according to the position specified by the ALP packet length (packet length of ALP packet) acquired in the process of step S517.
  • a process similar to the process (the process after S516) on the acquired ALP packet to be processed is performed.
  • step S519 If it is determined in step S519 that the BB packet to be processed has ended, the process proceeds to step S511. Then, the next processing target BB packet is acquired, and the same processing as the processing (processing after S511) on the processing target BB packet described above is performed.
  • step S513 If it is determined in step S513 that the ALP packet is in the middle, the process proceeds to step S522.
  • step S522 the BB depacketizer 214 blanks the BB header of the BB packet to be processed.
  • step S528 the process proceeds to step S518, and the subsequent processes are performed.
  • the BB to be processed is All ALP packets placed in the packet payload are discarded, and the next BB packet to be processed is acquired (S511). That is, when an error that can not be corrected by LDPC or BCH occurs in a specific ALP packet, not only the ALP packet in which the error occurs but all the ALP packets in the BB packet to be processed are extracted. It will not be possible (all ALP packets will be discarded).
  • error detection code can be placed in the BB header of the BB packet or the ALP header of the ALP packet, so that the error correction by the LDPC or BCH can not be performed on the ALP packet in the BB packet. Even when an error occurs, the position where the error occurs can be detected to prevent the ALP packet in the target BB packet from being discarded unnecessarily.
  • FIG. 15 is a diagram showing an example of syntax of an ALP packet.
  • the structure of the ALP header described below is an extension of the structure of the ALP header shown in FIGS. 7 to 12 described above.
  • an ALP packet is composed of an ALP header and a payload.
  • the ALP header includes an ALP packet header (ALP_packet_header), an additional header (additional_header), and an extension header (header_extension).
  • the ALP packet header has packet_type, PC (payload_configuration), HM (header_mode), and length. However, as described above, by specifying “0” as the 1-bit payload_configuration, HM (header_mode) and length are arranged in the ALP packet header.
  • the 3-bit packet_type indicates the packet type of the ALP packet.
  • this packet type "000" is fixedly specified.
  • FIG. 16 shows an example of the packet type.
  • the packet is an IPv4 (Internet Protocol version 4) packet.
  • 1-bit HM header_mode indicates a header mode. As this header mode, "1" is fixedly specified. As described above, by specifying “1” as the header_mode, an additional header (additional_header) is placed in the ALP header.
  • the 11-bit length indicates the packet length of the ALP packet (ALP packet length).
  • the additional header has length_MSB, SIF (Substream Identification Flag), and HEF (Header Extension Flag).
  • the 5-bit length_MSB indicates the packet length of MSB (Most Significant Bit).
  • One-bit SIF indicates a flag indicating whether a substream ID (sub_stream_identification) exists. If there is a substream ID, SIF is set to "1".
  • data of the extension data type designated by extension_type can be arranged according to the extension data length designated by extension_length.
  • extension_type one or more extension data types (extension_type) can be specified by extending the 8-bit num_extension_type so that the number of extension data types can be specified.
  • Data (DATA [i] [j]) according to the extension data length (extension_length [i]) can be arranged for each [i]).
  • FIG. 18 shows an example of the extended data type.
  • extension data type extension_type
  • data (DATA) in a loop according to the extension data length extension_length
  • CRC Cyclic Redundancy Check: Cyclic Redundancy Check
  • the data structure of CRC_DATA of FIG. 19 can be arranged as data (DATA) in a loop corresponding to the extended data length of FIG. In FIG. 19, mode and CRC are arranged in CRC_DATA.
  • the 8-bit mode indicates a CRC mode (hereinafter referred to as a CRC mode).
  • a CRC mode of "0" represents CRC-8.
  • a CRC mode of "1" represents CRC-16.
  • CRC CRC data corresponding to the CRC mode specified by mode is arranged.
  • CRC-8 and CRC-16 due to differences in polynomial, here, for example, CRC-8 defined by CCITT (Comite Consultatif International Circuitique et Telephonique: International Brass and Telephone Consultative Committee) -CCITT (X 8 + X 7 + X 3 + X 2 + 1) or CRC-16-CCITT (X 16 + X 12 + X 5 + 1) can be used.
  • CRC-8s other than CRC-8-CCITT
  • CRC-16s other than CRC-16-CCITT
  • CRC-32 and CRC-64 may of course be used, for example, other CRCs such as CRC-32 and CRC-64.
  • the CRC is an example of an error detection code, and another error detection code may be used.
  • 0xff When “0xff” is specified as the extension data type in FIG. 18, it indicates that private user data (Private User Data) is arranged in data (DATA) in a loop according to the extension data length. ing. As this private user data, arbitrary data such as data to be notified between devices can be arranged, for example. Further, in FIG. 18, the extended data type of “0x01” to “0xfe” is set as a region for future extension (Reserved).
  • the CRC mode such as CRC-8 and CRC-16 is specified by CRC_DATA of FIG. 19, but the CRC corresponding to the CRC mode is It may be specified by the extended data type.
  • FIG. 20 shows an example of an extended data type that can specify a CRC according to the CRC mode.
  • extension data type extension_type
  • data of CRC-8 is included in the data (DATA) in the loop according to the extension data length (extension_length) of FIG. It represents that it is arranged.
  • extension data length extension_length
  • an error detection code for example, CRC-8 or CRC-16
  • the depacketizer 2114 performs error detection processing using the error detection code included in the ALP header, and the payload of the BB packet according to the detected position (the position where an error can not be corrected by LDPC or BCH). Can be processed ALP packets placed in
  • Second method place an error detection code in the BB header
  • FIG. 21 is a diagram illustrating an example of a data structure in the case of arranging a CRC in the BB header of the BB packet.
  • the structure of the BB header in FIG. 21 corresponds to the structure of the BB header shown in FIG. 5 described above, and the description of the portions where the description is repeated will be omitted as appropriate.
  • the BB packet is composed of a BB header and a payload.
  • BB header in addition to a base field (Base Field), an optional field (Optional Field) and an extension field (Extension Field) can be arranged.
  • Base Field Base Field
  • Optional Field optional field
  • Extension Field Extension Field
  • a 2-bit optional flag (OPTI: OPTIONAL) is placed.
  • OPTIONAL optional flag
  • optional fields and extension fields are expanded.
  • EXT_TYPE 3-bit extension type
  • extension type the type of extension field is specified. For example, when “001" is specified as the extension type, it indicates that data of CRC-8 is placed in the extension field. When “010” is specified as the extension type, it indicates that data of CRC-16 is placed in the extension field.
  • CRC-8 and CRC-16 e.g., CRC-8-CCITT (X 8 + X 7 + X 3 + X 2 + 1) or, CRC-16 -CCITT (X 16 + X 12 + X 5 + 1) can be used.
  • CRC-8s other than CRC-8-CCITT, and other CRC-16s other than CRC-16-CCITT may of course be used, for example, other CRCs such as CRC-32 and CRC-64.
  • the CRC is an example of an error detection code, and another error detection code may be used.
  • extension types of “011” to “110” are considered as areas for future extension.
  • “000” is specified as the extension type, it means that a counter is arranged, and when "111" is specified, it means that padding is performed.
  • an error detection code for example, CRC-8 or CRC-16
  • BB header extension field of the BB packet.
  • the depacketizer 214) can perform error detection processing using the error detection code contained in the BB header.
  • either the first method or the second method may be employed, or both methods may be employed simultaneously.
  • an error detection code is arranged for each of the ALP header of the ALP packet and the BB header of the BB packet.
  • the processing content for the ALP packet changes according to the detected position of the error (the position where the error can not be corrected by LDPC or BCH), so the detected position of the error is the ALP packet below.
  • the detected position of the error is the ALP packet below.
  • FIG. 22 is a diagram for explaining packet processing of the present technology in the case where the error detection position is the payload of the ALP packet.
  • the error detection processing using an error detection code (for example, CRC-8 or CRC-16) included in the ALP header of the ALP packet is placed in the payload of the BB packet to be processed. It is detected that an error that can not be corrected by LDPC or BCH has occurred in the payload of the leading ALP packet among a plurality of ALP packets.
  • an error detection code for example, CRC-8 or CRC-16
  • the error detection processing using the error detection code of the ALP header not only recognizes that an error that can not be corrected by LDPC or BCH is occurring, but also detects the position where the error has occurred. Therefore, by identifying (the payload of) an ALP packet in which an error has occurred and making sure that the variable-length chain of ALP packets is not interrupted in the payload of the BB packet to be processed, an error occurs. ALP packets are not discarded.
  • FIG. 23 is a diagram for explaining packet processing of the present technology in the case where an error detected position is an ALP header of an ALP packet.
  • the error detection processing using an error detection code (for example, CRC-8 or CRC-16) included in the ALP header of the ALP packet is placed in the payload of the BB packet to be processed.
  • an error detection code for example, CRC-8 or CRC-16
  • the packet processing of the present technology in FIG. 23 it is detected (recognized) that an error has occurred in the ALP header of the second ALP packet, so the information in the ALP header is not necessarily correct. Although the ALP packet after the second ALP packet is discarded, the first ALP packet is not discarded because the first ALP packet does not have an error.
  • the error detection processing using the error detection code of the ALP header not only recognizes that an error that can not be corrected by LDPC or BCH is occurring, but also detects the position where the error has occurred. Therefore, identify the ALP packet (the ALP header) in which the error has occurred, and ensure that the error-free ALP packet is not discarded as much as possible in the payload of the BB packet to be processed. There is.
  • the ALP header of the ALP packet placed in the payload of the BB packet is included in the payload of the BB packet to be processed.
  • the ALP packet can be extracted continuously until the ALP packet immediately before the containing ALP packet.
  • step S101 packet processing is performed on data of content such as a broadcast program.
  • processing of generating UDP / IP packets, ALP packets, and BB packets is performed by the UDP / IP packetizer 103, the ALP packetizer 104, and the BB packetizer 105.
  • the ALP header of the ALP packet generated in the process of step S101 is an error such as CRC-8 or CRC-16, for example.
  • a detection code is placed.
  • an error detection code (DATA) corresponding to the extension data type (extension_type) is arranged in the extension header (header_extension) of the ALP header.
  • the BB header of the BB packet generated in the process of step S101 is an error such as CRC-8 or CRC-16, for example.
  • a detection code is placed.
  • an error detection code for example, CRC-8 or CRC-16
  • EXT_TYPE extension type
  • step S102 an error correction coding process is performed on the data obtained in the process of step S101.
  • this error correction coding process processes such as BCH coding by the BCH encoder 107 and LDPC coding by the LDPC encoder 108 are performed.
  • step S103 modulation processing is performed on the data subjected to the error correction coding processing in the processing of step S102.
  • interleaving processing by various interleavers, processing by the data mapper 111, the OFDM transmission unit 117, and the like are performed.
  • an RF signal (OFDM signal) obtained by this modulation processing is transmitted through the transmission path 30.
  • step S201 demodulation processing is performed on the RF signal (OFDM signal) transmitted from the transmission apparatus 10 through the transmission path 30.
  • processing by the OFDM receiving unit 202 or the data demapper 208, deinterleave processing by various deinterleavers, and the like are performed.
  • step S202 an error correction decoding process is performed on the data demodulated in the process of step S201.
  • this error correction decoding process processes such as LDPC decoding by the LDPC decoder 211 and BCH decoding by the BCH decoder 212 are performed.
  • step S203 packet processing is performed on the data subjected to the error correction decoding process in the process of step S202.
  • packet processing is performed on BB packets, ALP packets, and UDP / IP packets by the BB depacketizer 214, the ALP depacketizer 215, and the UDP / IP depacketizer 216.
  • an extension data type (extension header (header_extension)) of the ALP header of the ALP packet processed in the process of step S203 is Since an error detection code (for example, CRC-8 or CRC-16) corresponding to the extension_type is arranged, an error detection process is performed using the error detection code of the ALP header.
  • an error detection code for example, CRC-8 or CRC-16
  • the extension type (Extension Field) of the BB header of the BB packet processed in the process of step S203 is Since an error detection code (for example, CRC-8 or CRC-16) corresponding to the EXT_TYPE is disposed, an error detection process using the error detection code of the BB header is performed.
  • an error detection code for example, CRC-8 or CRC-16
  • the data after packet processing is decoded by the AV decoder 218 or the like, whereby the receiving apparatus 20 reproduces content such as a broadcast program.
  • step S211 the BB depacketizer 214 acquires the next BB packet to be processed.
  • step S212 the BB depacketizer 214 determines whether the ALP packet placed in the payload of the processing-target BB packet acquired in the process of step S211 is in the middle of the ALP packet.
  • step S212 If it is determined in step S212 that the packet is not in the middle of the ALP packet, the process proceeds to step S213.
  • step S213 the BB depacketizer 214 acquires the BB header of the BB packet to be processed.
  • step S213A the BB depacketizer 214 acquires a CRC value (BB CRC value) included in (the extension field of) the BB header acquired in the process of step S213.
  • step S213B the BB depacketizer 214 calculates a CRC value (BB CRC value) based on the CRC value (BB CRC value) acquired in the process of step S213A.
  • step S213C the BB depacketizer 214 determines whether a comparison error of a CRC value (BB CRC value) has occurred according to the calculation result of step S213B.
  • the comparison error determination process (S213C) using the BB CRC value is processed in the same manner as the comparison error determination process (S218) using the ALP CRC value described later, so here The description is omitted.
  • step S213C If it is determined in step S213C that a CRC value (BB CRC value) comparison error has occurred, the process returns to step S211. Then, the next processing target BB packet is acquired, and the same processing as the processing (processing after S211) on the processing target BB packet described above is performed.
  • step S213C determines whether a CRC value (BB CRC value) comparison error has occurred. If it is determined in step S213C that a CRC value (BB CRC value) comparison error has not occurred, the process proceeds to step S214.
  • the BB depacketizer 214 acquires the leading ALP pointer included in the BB header acquired in the process of step S213.
  • step S215 the BB depacketizer 214 acquires the ALP header of the processing target ALP packet (head ALP packet) based on the position specified by the top ALP pointer acquired in the process of step S214.
  • step S216 the BB depacketizer 214 acquires a CRC value (ALP CRC value) included in (the extension header of) the ALP header acquired in the process of step S215.
  • step S217 the BB depacketizer 214 calculates a CRC value (ALP CRC value) based on the CRC value (ALP CRC value) acquired in the process of step S216.
  • step S218 the BB depacketizer 214 determines whether a comparison error of a CRC value (ALP CRC value) has occurred according to the calculation result of step S217.
  • a predetermined calculation is performed on the input data string from transmission device 10 through transmission path 30, and the remainder is used for checking. Since the data added as a value is transmitted, the receiver 20 (of the BB depacketizer 214) performs the same calculation (predetermined calculation) using the data from the transmitter 10, and checks the calculation result By comparing with the value of, it is determined whether the data is corrupted.
  • step S218 If it is determined in step S218 that a CRC value (ALP CRC value) comparison error has occurred, the process returns to step S211. Then, the next processing target BB packet is acquired, and the same processing as the processing (processing after S211) on the processing target BB packet described above is performed.
  • a CRC value ALP CRC value
  • step S218 if it is determined in step S218 that a comparison error of a CRC value (ALP CRC value) has not occurred, the process proceeds to step S219.
  • step S219 the BB depacketizer 214 acquires the ALP packet length (packet length of ALP packet) included in the ALP header acquired in the process of step S215. Since the ALP packet length acquired here is data acquired from the ALP header for which no error was detected by the error detection processing of the CRC, it can be said that it is reliable information.
  • step S220 the BB depacketizer 214 obtains the payload of the ALP packet to be processed.
  • the process proceeds to step S211.
  • step S221 it is determined whether the BB packet to be processed has ended. If it is determined in step S211 that the BB packet to be processed has not ended, the process proceeds to step S222.
  • step S222 it is determined whether the processing target ALP packet has ended. If it is determined in step S222 that the ALP packet to be processed has not ended, the process returns to step S220, and the subsequent processing is repeated. That is, the payload of the processing target ALP packet is acquired until the processing target BB packet ends ("YES" in S221) or the processing target ALP packet ends ("YES" in S222) ( S220).
  • step S222 If it is determined in step S222 that the processing target ALP packet has ended, the process proceeds to step S223.
  • step S223 UDP / IP processing is performed.
  • step S223 ends, the process proceeds to step S215.
  • the next ALP packet to be processed (ALP header or payload) is processed according to the position specified by the ALP packet length (packet length of ALP packet) acquired in the process of step S219.
  • a process similar to the process (the process after S215) on the acquired ALP packet to be processed is performed.
  • step S221 If it is determined in step S221 that the BB packet to be processed has ended, the process proceeds to step S211. Then, the next processing target BB packet is acquired, and the same processing as the processing (processing after S211) on the processing target BB packet described above is performed.
  • step S212 If it is determined in step S212 that the process is in the middle of the ALP packet to be processed, the process proceeds to step S224.
  • step S224 the BB depacketizer 214 blanks the BB header of the BB packet to be processed.
  • step S220 the process proceeds to step S220, and the subsequent processes are performed.
  • the ATSC in particular, ATSC 3.0
  • ATSC 3.0 which is a system adopted in the United States and the like
  • DVB Digital Video Broadcasting
  • the ATSC 3.0 in which the IP transmission method using the IP packet is adopted is described as an example, but not limited to the IP transmission method, for example, other than the MPEG2-TS (Transport Stream) method etc. It may be applied to the method of
  • satellite broadcasting that uses broadcasting satellites (BS) and communication satellites (CS), etc., and cable broadcasting (CATV), etc., should be applied as standards for digital broadcasting. Can.
  • BB packet Basic Packet
  • BBS Baseband Stream
  • BBF Baseband Frame
  • ALP ATSC Link layer Protocol
  • the present technology prescribes a predetermined standard (assuming use of a transmission line other than a broadcast network, ie, a communication line (communication network) such as the Internet or a telephone network) as a transmission line.
  • a communication line such as the Internet or a telephone network may be used as the transmission line 30 of the transmission system 1 (FIG. 1), and the transmission device 10 may be a server provided on the Internet.
  • the transmitting device 10 server
  • the transmitting device 10 processes data transmitted from the transmitting device 10 (server) via the transmission path 30 (communication line).
  • FIG. 27 is a diagram showing an example of a hardware configuration of a computer that executes the series of processes described above according to a program.
  • a central processing unit (CPU) 1001, a read only memory (ROM) 1002, and a random access memory (RAM) 1003 are mutually connected by a bus 1004.
  • An input / output interface 1005 is further connected to the bus 1004.
  • An input unit 1006, an output unit 1007, a recording unit 1008, a communication unit 1009, and a drive 1010 are connected to the input / output interface 1005.
  • the input unit 1006 includes a keyboard, a mouse, a microphone and the like.
  • the output unit 1007 includes a display, a speaker, and the like.
  • the recording unit 1008 includes a hard disk, a non-volatile memory, and the like.
  • the communication unit 1009 includes a network interface or the like.
  • the drive 1010 drives removable media 1011 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory.
  • the CPU 1001 loads the program stored in the ROM 1002 or the recording unit 1008 into the RAM 1003 via the input / output interface 1005 and the bus 1004, and executes the program. A series of processing is performed.
  • the program executed by the computer 1000 can be provided by being recorded on, for example, a removable medium 1011 as a package medium or the like. Also, the program can be provided via a wired or wireless transmission medium such as a local area network, the Internet, or digital satellite broadcasting.
  • the program can be installed in the recording unit 1008 via the input / output interface 1005 by mounting the removable media 1011 in the drive 1010. Also, the program can be received by the communication unit 1009 via a wired or wireless transmission medium and installed in the recording unit 1008. Besides, the program can be installed in advance in the ROM 1002 and the recording unit 1008.
  • the processing performed by the computer according to the program does not necessarily have to be performed chronologically in the order described as the flowchart. That is, the processing performed by the computer according to the program includes processing executed in parallel or separately (for example, parallel processing or processing by an object). Further, the program may be processed by one computer (processor) or may be distributed and processed by a plurality of computers.
  • the present technology can have the following configurations.
  • Processing unit for processing the transmission packet A receiving unit that performs an error detection process using the error detection code included in a header of the transmission packet; (2) The receiver according to (1), wherein the processing unit performs processing according to the detected position of the error when an error is detected by the error detection processing using the error detection code included in the header of the transmission packet.
  • the processing unit extracts the transmission packet disposed after the detection position of the error in the payload of the baseband packet and processes the transmission packet as it is 2) The receiving device as described in 2).
  • the transmission packet when the detection position of the error is a header of the transmission packet, the transmission packet disposed after the detection position of the error in the payload of the baseband packet is discarded (2).
  • Receiving device (5) The receiver according to any one of (1) to (4), wherein the error detection code is a cyclic redundancy check (CRC).
  • CRC cyclic redundancy check
  • the transmission packet is a variable-length packet
  • the header of the baseband packet includes a pointer indicating the position of the beginning of the transmission packet;
  • the header of the transmission packet includes the data length of the transmission packet,
  • the receiving device according to any one of (1) to (5), wherein arrangement positions of the plurality of transmission packets arranged in the payload of the baseband packet are specified by the pointer and the data length.
  • the receiving device A plurality of transmission packets arranged in the payload of the baseband packet after demodulation, the transmission packet including a header including an error detection code and a payload in which an IP packet including a UDP packet is arranged
  • a data processing method comprising the step of performing an error detection process using the error detection code.
  • a processing unit for generating the transmission packet the transmission packet being disposed in the payload of the baseband packet before modulation, the header including an error detection code, and the payload in which the IP packet including the UDP packet is disposed. Equipped The processing unit places a plurality of the transmission packets in the payload of the baseband packet.
  • the transmitting device A transmission packet disposed in a payload of a baseband packet before modulation, the transmission packet being composed of a header including an error detection code and a payload in which an IP packet including a UDP packet is disposed;
  • a data processing method comprising: arranging a plurality of the transmission packets in a payload of the baseband packet.
  • the baseband packet which is a baseband packet after demodulation, including a header including an error detection code, and a payload including a plurality of transmission packets including a payload including an IP packet including a UDP packet.
  • Processing unit to process A receiving unit that performs an error detection process using the error detection code included in a header of the baseband packet;
  • the error detection code is a cyclic redundancy check (CRC).
  • the transmission packet is a variable-length packet
  • the header of the baseband packet includes a pointer indicating the position of the beginning of the transmission packet;
  • the header of the transmission packet includes the data length of the transmission packet,
  • the receiving device according to (10) or (11), wherein arrangement positions of the plurality of transmission packets arranged in the payload of the baseband packet are specified by the pointer and the data length.
  • the receiving device In the data processing method of the receiving device, The receiving device
  • the baseband packet which is a baseband packet after demodulation, including a header including an error detection code, and a payload including a plurality of transmission packets including a payload including an IP packet including a UDP packet. Performing an error detection process using the error detection code included in the header of the data processing method.
  • a transmission packet disposed in a payload of a baseband packet before modulation the processing unit generating the transmission packet including a payload in which an IP packet including a UDP packet is disposed;
  • the processing unit places an error detection code in the header of the baseband packet, and places a plurality of the transmission packets in the payload of the baseband packet.
  • the transmitting device A transmission packet disposed in the payload of the baseband packet before modulation, wherein the transmission packet is configured to include the payload in which the IP packet including the UDP packet is disposed;
  • An error detection code is placed in the header of the baseband packet, and a plurality of the transmission packets are placed in the payload of the baseband packet.
  • Reference Signs List 1 transmission system 10 transmission devices, 20 reception devices, 30 transmission paths, 101 AV encoder, 102 FLUTE encoder, 103 UDP / IP packetizer, 104 ALP packetizer, 105 BB packetizer, 106 scrambler, 107 BCH encoder, 108 LDPC encoder, 109 parity interleaver, 110 column twist interleaver, 111 data mapper, 112 CQ delay block, 113 cell interleaver, 114 time interleaver, 115 frame mapper, 116 frequency interleaver, 117 OFDM transmitter, 118 RF output block, 201 RF input, 202 OFDM receiver, 203 frequency deinterleaver, 204 frame demapper, 205 time day Tarleaver, 206 Cell Deinterleaver, 207 CQ Delay Unit, 208 Data Demapper, 209 Column Twist Deinterleaver, 210 Parity Deinterleaver, 211 LDPC Decoder, 212 BCH Decoder, 213 Descram

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Communication Control (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

本技術は、パケットが無駄に破棄されるのを防止することができるようにする受信装置、送信装置、及び、データ処理方法に関する。 受信装置は、復調後のベースバンドパケットのペイロートに複数配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードとから構成される伝送パケットのヘッダに含まれる誤り検出符号を用いて、誤り検出処理を行う。本技術は、例えば、ATSC3.0等の放送規格に準拠したデータ伝送に適用することができる。

Description

受信装置、送信装置、及び、データ処理方法
　本技術は、受信装置、送信装置、及び、データ処理方法に関し、特に、パケットが無駄に破棄されるのを防止することができるようにした受信装置、送信装置、及び、データ処理方法に関する。
　現在、次世代地上放送規格の１つであるATSC(Advanced Television Systems Committee)3.0の策定が進められている（例えば、非特許文献１参照）。
ATSC Candidate Standard：Physical Layer Protocol（Doc. S32-230r21 28 September 2015）
　ところで、ATSC3.0等の放送規格では、パケット単位でデータを伝送することが規定されているが、パケット内のデータでエラーが発生した場合に、パケットが無駄に破棄されるときがあった。そのため、パケット内のデータでエラーが発生した場合であっても、パケットが無駄に破棄されるのを防止するための提案が要請されていた。
　本技術はこのような状況に鑑みてなされたものであり、パケットが無駄に破棄されるのを防止することができるようにするものである。
　本技術の第１の側面の受信装置は、復調後のベースバンドパケットのペイロートに複数配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDP(User Datagram Protocol)パケットを含むIP(Internet Protocol)パケットを配置したペイロードとから構成される前記伝送パケットを処理する処理部を備え、前記処理部は、前記伝送パケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う受信装置である。
　本技術の第１の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面のデータ処理方法は、上述した本技術の第１の側面の受信装置に対応するデータ処理方法である。
　本技術の第１の側面の受信装置、及び、データ処理方法においては、復調後のベースバンドパケットのペイロートに複数配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードとから構成される前記伝送パケットが処理され、前記伝送パケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理が行われる。
　本技術の第２の側面の送信装置は、変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードとから構成される前記伝送パケットを生成する処理部を備え、前記処理部は、前記ベースバンドパケットのペイロードに、複数の前記伝送パケットを配置する送信装置である。
　本技術の第２の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面のデータ処理方法は、上述した本技術の第２の側面の送信装置に対応するデータ処理方法である。
　本技術の第２の側面の送信装置、及び、データ処理方法においては、変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードとから構成される前記伝送パケットが生成され、前記ベースバンドパケットのペイロードに、複数の前記伝送パケットが配置される。
　本技術の第３の側面の受信装置は、復調後のベースバンドパケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される伝送パケットを複数配置したペイロードとから構成される前記ベースバンドパケットを処理する処理部を備え、前記処理部は、前記ベースバンドパケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う受信装置である。
　本技術の第３の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第３の側面のデータ処理方法は、上述した本技術の第３の側面の受信装置に対応するデータ処理方法である。
　本技術の第３の側面の受信装置、及び、データ処理方法においては、復調後のベースバンドパケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される伝送パケットを複数配置したペイロードとから構成される前記ベースバンドパケットが処理され、前記ベースバンドパケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理が行われる。
　本技術の第４の側面の送信装置は、変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される前記伝送パケットを生成する処理部を備え、前記処理部は、前記ベースバンドパケットのヘッダに、誤り検出符号を配置し、前記ベースバンドパケットのペイロードに、複数の前記伝送パケットを配置する送信装置である。
　本技術の第４の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第４の側面のデータ処理方法は、上述した本技術の第４の側面の送信装置に対応するデータ処理方法である。
　本技術の第４の側面の送信装置、及び、データ処理方法においては、変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される前記伝送パケットが生成され、前記ベースバンドパケットのヘッダに、誤り検出符号が配置され、前記ベースバンドパケットのペイロードに、複数の前記伝送パケットが配置される。
　本技術の第１の側面乃至第４の側面によれば、パケットが無駄に破棄されるのを防止することができる。
　なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
本技術を適用した伝送システムの一実施の形態の構成を示す図である。 送信装置の構成例を示す図である。 受信装置の構成例を示す図である。 本技術で用いられるパケットの相関を示す図である。 BBパケットに付加されるBBヘッダの構造を示す図である。 オプショナルフィールドフラグの例を示す図である。 ALPパケットのALPヘッダのシンタックスの例を示す図である。 additional_header_for_single_packet()のシンタックスの例を示す図である。 additional_header_for_segmentation()のシンタックスの例を示す図である。 additional_header_for_concatenation()のシンタックスの例を示す図である。 sub_stream_identification()のシンタックスの例を示す図である。 header_extension()のシンタックスの例を示す図である。 現状のパケット処理を説明する図である。 現状のパケット処理の流れを説明するフローチャートである。 ALPパケットのシンタックスの例を示す図である。 パケットタイプの例を示す図である。 ALPパケットの拡張ヘッダのシンタックスの例を示す図である。 拡張データタイプの例を示す図である。 拡張データにCRCを配置する場合のデータ構造の例を示す図である。 拡張データタイプの他の例を示す図である。 BBパケットのBBヘッダにCRCを配置する場合の構造の例を示す図である。 本技術のパケット処理（ケース１）を説明する図である。 本技術のパケット処理（ケース２）を説明する図である。 送信側データ処理の流れを説明するフローチャートである。 受信側データ処理の流れを説明するフローチャートである。 本技術のパケット処理の流れを説明するフローチャートである。 コンピュータの構成例を示す図である。
　以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
１．システムの構成
２．現状の規格の概要
３．本技術の実施の形態
（１）第１の方式：ALPヘッダに誤り検出符号を配置
（２）第２の方式：BBヘッダに誤り検出符号を配置
（３）本技術のパケット処理
４．変形例
５．コンピュータの構成
＜１．システムの構成＞
（伝送システムの構成例）
　図１は、本技術を適用した伝送システムの一実施の形態の構成を示す図である。なお、システムとは、複数の装置が論理的に集合したものをいう。
　図１において、伝送システム１は、送信装置１０と受信装置２０から構成される。この伝送システム１では、ATSC3.0等のデジタル放送の規格に準拠したデータ伝送が行われる。
　なお、次世代地上放送規格の１つであるATSC3.0では、データ伝送に、主として、TS(Transport Stream)パケットではなく、UDP/IPパケット、すなわち、UDP(User Datagram Protocol)パケットを含むIP(Internet Protocol)パケットを用いる方式が採用されることが想定されている。また、ATSC3.0以外の放送方式でも、将来的に、IPパケットを用いた方式が採用されることが期待されている。
　送信装置１０は、伝送路３０を介してコンテンツを送信する。例えば、送信装置１０は、放送番組等のコンテンツを構成するビデオやオーディオ等（のコンポーネント）とシグナリングを含む放送ストリームを、放送波として伝送路３０を介して送信する。
　受信装置２０は、送信装置１０から伝送路３０を介して送信されてくる、コンテンツを受信して出力する。例えば、受信装置２０は、送信装置１０からの放送波を受信して、放送ストリームから、コンテンツを構成するビデオやオーディオ等（のコンポーネント）とシグナリングを取得し、放送番組等のコンテンツの映像や音声を再生する。
　なお、図１の伝送システム１においては、説明を簡単にするために、受信装置２０を１つだけ図示しているが、受信装置２０は複数設けることができ、送信装置１０が送信（一斉同報配信）する放送波は、伝送路３０を介して複数の受信装置２０で同時に受信することができる。
　また、図１の伝送システム１においては、送信装置１０も複数設けることができる。複数の送信装置１０のそれぞれでは、別個のチャネルとしての、例えば、別個の周波数帯域で、放送ストリームを含む放送波を送信し、受信装置２０では、複数の送信装置１０のそれぞれのチャンネルの中から、放送ストリームを受信するチャネルを選択することができる。
　さらに、図１の伝送システム１において、伝送路３０は、地上波（地上波放送）のほか、例えば、放送衛星（BS：Broadcasting Satellite）や通信衛星（CS：Communications Satellite）を利用した衛星放送、あるいは、ケーブルを用いた有線放送（CATV）などであってもよい。
（送信装置の構成例）
　図２は、図１の送信装置１０の構成例を示す図である。
　図２において、送信装置１０は、AVエンコーダ１０１、FLUTEエンコーダ１０２、UDP/IPパケタイザ１０３、ALPパケタイザ１０４、BBパケタイザ１０５、スクランブラ１０６、BCHエンコーダ１０７、LDPCエンコーダ１０８、パリティインターリーバ１０９、カラムツイストインターリーバ１１０、データマッパ１１１、CQディレイ部１１２、セルインターリーバ１１３、時間インターリーバ１１４、フレームマッパ１１５、周波数インターリーバ１１６、OFDM送信部１１７、及びRF出力部１１８から構成される。
　AVエンコーダ１０１は、ビデオやオーディオ（のコンポーネント）のデータを、所定の符号化方式に従い、エンコードし、FLUTEエンコーダ１０２に供給する。FLUTEエンコーダ１０２は、AVエンコーダ１０１からのデータを処理（エンコード）して、FLUTE(File Delivery over Unidirectional Transport)形式に対応したデータを生成し、UDP/IPパケタイザ１０３に供給する。
　UDP/IPパケタイザ１０３は、FLUTEエンコーダ１０２からのデータを処理して、UDPパケットを含むIPパケット（UDP/IPパケット）を生成し、ALPパケタイザ１０４に供給する。ALPパケタイザ１０４は、UDP/IPパケタイザ１０３からのUDP/IPパケットを処理して、ALP(ATSC Link layer Protocol)パケットを生成し、BBパケタイザ１０５に供給する。
　BBパケタイザ１０５は、ALPパケタイザ１０４からのALPパケットを処理して、BB(BaseBand)パケットを生成し、スクランブラ１０６に供給する。スクランブラ１０６は、BBパケタイザ１０５からのデータ（BBパケット）にスクランブルを施し、その結果得られるデータを、BCHエンコーダ１０７に供給する。
　BCHエンコーダ１０７は、スクランブラ１０６からのデータをBCH(Bose-Chaudhuri-Hocquenghem)符号化し、その結果得られるデータを、LDPCエンコーダ１０８に供給する。LDPCエンコーダ１０８は、BCHエンコーダ１０７からのデータをLDPC(Low Density Parity Check)符号化し、その結果得られるデータを、パリティインターリーバ１０９に供給する。
　パリティインターリーバ１０９は、LDPCエンコーダ１０８からのデータに対し、パリティインターリーブを行い、そのパリティインターリーブ後のデータを、カラムツイストインターリーバ１１０に供給する。カラムツイストインターリーバ１１０は、パリティインターリーバ１０９からのデータに対し、カラムツイストインターリーブを行い、そのカラムツイストインターリーブ後のデータを、データマッパ１１１に供給する。
　データマッパ１１１は、カラムツイストインターリーバ１１０からのデータを、そのデータ（LDPC符号）の１ビット以上の符号ビットの単位（シンボル単位）で、直交変調の１つのシンボルを表す信号点にマッピングして直交変調（多値変調）を行う。データマッパ１１１での処理により得られるデータは、CQディレイ部１１２を介して、セルインターリーバ１１３に供給される。
　セルインターリーバ１１３は、CQディレイ部１１２からのデータに対し、セルインターリーブを行い、そのセルインターリーブ後のデータを、時間インターリーバ１１４に供給する。時間インターリーバ１１４は、セルインターリーバ１１３からのデータに対し、時間インターリーブを行い、時間インターリーブ後のデータを、フレームマッパ１１５に供給する。
　フレームマッパ１１５は、時間インターリーバ１１４からのデータに対し、フレーム（物理層フレーム）に関する処理を行い、その結果得られるデータを、周波数インターリーバ１１６に供給する。周波数インターリーバ１１６は、フレームマッパ１１５からのデータに対し、周波数インターリーブを行い、その周波数インターリーブ後のデータを、OFDM送信部１１７に供給する。
　OFDM送信部１１７は、周波数インターリーバ１１６からのデータを処理して、OFDM(Orthogonal Frequency Division Multiplexing)信号を生成し、RF出力部１１８に供給する。RF出力部１１８は、アンテナ（不図示）と接続され、OFDM送信部１１７からのOFDM信号を、RF(Radio Frequency)信号として、伝送路３０を介して送信する。
　送信装置１０は、以上のように構成される。
（受信装置の構成例）
　図３は、図１の受信装置２０の構成例を示す図である。
　図３において、受信装置２０は、RF入力部２０１、OFDM受信部２０２、周波数デインターリーバ２０３、フレームデマッパ２０４、時間デインターリーバ２０５、セルデインターリーバ２０６、CQディレイ部２０７、データデマッパ２０８、カラムツイストデインターリーバ２０９、パリティデインターリーバ２１０、LDPCデコーダ２１１、BCHデコーダ２１２、デスクランブラ２１３、BBデパケタイザ２１４、ALPデパケタイザ２１５、UDP/IPデパケタイザ２１６、FLUTEデコーダ２１７、及びAVデコーダ２１８から構成される。
　RF入力部２０１は、アンテナ（不図示）と接続され、送信装置１０から伝送路３０を介して送信されてくるRF信号を受信し、OFDM信号として、OFDM受信部２０２に供給する。OFDM受信部２０２は、RF入力部２０１からのOFDM信号を処理し、それにより得られるデータを、周波数デインターリーバ２０３に供給する。
　周波数デインターリーバ２０３は、OFDM受信部２０２からのデータに対し、周波数デインターリーブを行い、その周波数デインターリーブ後のデータを、フレームデマッパ２０４に供給する。フレームデマッパ２０４は、周波数デインターリーバ２０３からのデータに対し、フレーム（物理層フレーム）に関する処理を行い、その結果得られるデータを、時間デインターリーバ２０５に供給する。
　時間デインターリーバ２０５は、フレームデマッパ２０４からのデータに対し、時間デインターリーブを行い、その時間デインターリーブ後のデータを、セルデインターリーバ２０６に供給する。セルデインターリーバ２０６は、時間デインターリーバ２０５からのデータに対し、セルデインターリーブを行い、そのセルデインターリーブ後のデータを、CQディレイ部２０７を介して、データデマッパ２０８に供給する。
　データデマッパ２０８は、CQディレイ部２０７からのデータ（コンスタレーション上のデータ）を、送信装置１０側で行われる直交変調で定められる信号点の配置（コンスタレーション）に基づいて、デマッピング（信号点配置復号）して直交復調し、その結果得られるデータ（LDPC符号）を、カラムツイストデインターリーバ２０９に供給する。
　カラムツイストデインターリーバ２０９は、データデマッパ２０８からのデータに対し、カラムツイストデインターリーブを行い、そのカラムツイストデインターリーブ後のデータを、パリティデインターリーバ２１０に供給する。パリティデインターリーバ２１０は、カラムツイストデインターリーバ２０９からのデータに対し、パリティデインターリーブを行い、そのパリティデインターリーブ後のデータを、LDPCデコーダ２１１に供給する。
　LDPCデコーダ２１１は、パリティデインターリーバ２１０からのデータをLDPC復号化し、その結果得られるデータを、BCHデコーダ２１２に供給する。BCHデコーダ２１２は、LDPCデコーダ２１１からのデータをBCH復号化し、その結果得られるデータを、デスクランブラ２１３に供給する。デスクランブラ２１３は、BCHデコーダ２１２からのデータにデスクランブルを施し、その結果得られるデータを、BBデパケタイザ２１４に供給する。
　BBデパケタイザ２１４は、デスクランブラ２１３からのデータからBBパケットを抽出して処理し、その結果得られるデータを、ALPデパケタイザ２１５に供給する。また、BBデパケタイザ２１４には、LDPCデコーダ２１１又はBCHデコーダ２１２からエラー訂正情報が入力される。このエラー訂正情報は、LDPC復号化やBCH復号化の処理でエラーが発生したことを示す情報であり、BBデパケタイザ２１４では、エラー訂正情報によって、LDPC復号化やBCH復号化で訂正不可能なデータが存在することを認識することができる。
　ALPデパケタイザ２１５は、BBデパケタイザ２１４からのデータからALPパケットを抽出して処理し、その結果得られるデータを、UDP/IPデパケタイザ２１６に供給する。UDP/IPデパケタイザ２１６は、ALPデパケタイザ２１５からのデータからUDP/IPパケットを抽出して処理し、その結果得られるデータを、FLUTEデコーダ２１７に供給する。
　FLUTEデコーダ２１７は、UDP/IPデパケタイザ２１６からのデータ（FLUTE形式に対応したデータ）を処理（デコード）して、その結果得られるデータを、AVデコーダ２１８に供給する。AVデコーダ２１８は、FLUTEデコーダ２１７からのデータを、所定の復号方式に従い、デコードし、その結果得られるビデオやオーディオ（のコンポーネント）のデータを出力する。
　受信装置２０は、以上のように構成される。
＜２．現状の規格の概要＞
（パケットの相関図）
　図４は、本技術で用いられるパケットの相関を示す図である。
　本技術では、レイヤごとに、複数の種類のパケットが利用される。BB(BaseBand)パケットは、ベースバンドのレイヤ１のパケットである。ALP(ATSC Link layer Protocol)パケットは、レイヤ１の上位階層であるレイヤ２のパケット（伝送パケット）である。IP(Internet Protocol)パケットは、レイヤ２の上位階層であるレイヤ３のパケットである。また、IPパケットには、UDP(User Datagram Protocol)パケットが含まれる。
　BBパケットは、BBヘッダ（BB Header）とペイロード（BB packet payload）から構成される。BBパケットのペイロードには、１又は複数のALPパケットが配置される。BBヘッダには、パケット長とポインタなどの情報が含まれる。このポインタは、BBパケットのペイロードに配置される先頭のALPパケットの位置を表している。以下の説明では、このポインタを、先頭ALPポインタと称する。
　なお、BBパケットのBBヘッダの詳細な構造は、図５及び図６を参照して後述する。また、BBパケットの最大サイズは、8196バイトとされる。
　ALPパケットは、ALPヘッダ（ALP Header）とペイロード（ALP payload）から構成される。ALPパケットのペイロードには、１又は複数のIPパケットが配置される。ALPパケットのALPヘッダには、パケット長などの情報が含まれる。また、ALPパケットは可変長であり、その最大サイズは、65536バイトとされる。
　ここで、BBパケットのペイロードに配置される１又は複数のALPパケットは、BBヘッダの先頭ALPポインタと、ALPヘッダのパケット長（ALPパケットのパケット長）を用いることで、抽出することができる。すなわち、あるBBパケットにおいて、先頭ALPポインタを用いて、あるALPパケットの位置が特定されれば、仮に、次のBBパケットにまたがってALPパケットが配置されている場合でも、ALPヘッダのパケット長を用いることで、次のALPパケットの位置を特定することができる。
　例えば、図４においては、３個のBBパケットに対し、３個のALPパケットが配置される場合を例示しているが、BBパケットによっては、複数のBBパケットをまたいで配置されるALPパケットが存在している。この例では、２番目のALPパケットが、１番目乃至３番目のBBパケットをまたいで配置されている。
　この場合において、１番目（先頭）のALPパケットは、１番目（先頭）のBBパケットのBBヘッダの先頭ALPポインタによりその位置が特定されることで、１番目（先頭）のBBパケットのペイロードから抽出される。同様に、３番目のALPパケットは、３番目のBBパケットのBBヘッダの先頭ALPポインタによりその位置が特定されることで、３番目のBBパケットのペイロードから抽出される。
　一方で、２番目のALPパケットは、１番目と２番目のALPパケットのALPヘッダのパケット長により、（１番目のBBパケットのBBヘッダの）先頭ALPポインタからそのパケット長に応じた位置が特定されることで、１番目乃至３番目のBBパケットのペイロードから抽出される。なお、この例では、２番目のBBパケットには、ALPパケットの先頭が存在しないため、２番目のBBパケットのBBヘッダの先頭ALPポインタの値は、"0"とされる。
　なお、ALPパケットのALPヘッダとしては、基本のヘッダ（ALP Base Hdr）であるALPパケットヘッダ（ALP_packet_header）のほか、アディショナルなヘッダ（ALP Add Hdr）である追加ヘッダ（additional_header）と、オプショナルなヘッダ（ALP Opt Hdr）である拡張ヘッダ（header_extension）を配置することができる。なお、ALPパケットのALPヘッダの詳細な構造は、図７乃至図１２を参照して後述する。
　IPパケットは、IPヘッダ（IP Header）とデータ部（Data）から構成される。IPパケットのデータ部には、UDPパケットが配置される。IPパケットのIPヘッダは、Version(Ver)，Header Length(Head Len)，Service，Total Length(Total Len)，ID，Flag，Flag offset，TTL(Time To Live)，Protocol，Checksum，Source IP address(Src Add)，Destination IP address(Dest Add)，及び、Optionを有する。なお、IPパケットの最大サイズは、65536バイトとされる。
　UDPパケットは、UDPヘッダ（UDP Header）とデータ部（Data）から構成される。UDPパケットのデータ部には、ビデオやオーディオ等のコンポーネントや、シグナリングのデータが配置される。UDPパケットのUDPヘッダは、Source port number(Src Port)，Destination port number(Dest Port)，Length，及び、Checksumを有する。なお、UDPパケットの最大サイズは、65507バイトとされる。
（BBヘッダの構造）
　図５は、BBパケットに付加されるBBヘッダの構造を示す図である。
　図５において、BBパケットは、BBヘッダとペイロード（Payload）から構成される。BBヘッダには、1又は2バイトのベースフィールド（Base Field）のほか、オプショナルフィールド（Optional Field）と、拡張フィールド（Extension Field）を配置することができる。
　すなわち、ベースフィールドにおいて、1ビットのモード（MODE）として、"0"が設定された場合には、7ビットのポインタ（Pointer(LSB)）が配置される。このポインタは、上述した先頭ALPポインタであって、BBパケットのペイロードに配置される先頭のALPパケットの位置を表している。例えば、あるBBパケットに最後に配置されたALPパケットのデータが、次のBBパケットにまたがって配置される場合に、先頭ALPポインタとして、次のBBパケットに配置される先頭のALPパケットの位置を設定することができる。
　また、モード（MODE）として、"1"が設定された場合には、7ビットのポインタ（Pointer(LSB)）のほかに、6ビットのポインタ（Pointer(MSB)）と、2ビットのオプショナルフラグ（OPTI：OPTIONAL）が配置される。オプショナルフラグは、オプショナルフィールド（Optional Field）と、拡張フィールド（Extension Field）を配置して、ヘッダを拡張するかどうかを示す情報である。
　ここで、図６に示すように、オプショナルフィールドと拡張フィールドの拡張を行わない場合、オプショナルフラグには、"00"が設定される。また、1バイトのオプショナルフィールドと、拡張フィールドの拡張を行う場合、オプショナルフラグには、"01"が設定され、ショート拡張モード（Short Extension Mode）となる。一方で、2バイトのオプショナルフィールドと、拡張フィールドの拡張を行う場合、オプショナルフラグは、"10"又は"11"が設定され、ロング拡張モード（Long Extension Mode）又はミックス拡張モード（Mixed Extension Mode）となる。
　図５の説明に戻り、オプショナルフィールドの先頭には、3ビットの拡張タイプ（EXT_TYPE）が設定される。この拡張タイプには、拡張フィールドのタイプ（Extension type）が設定される。ショート拡張モードの場合には、拡張タイプ（EXT_TYPE）に続いて、5ビットの拡張データ長（EXT_LEN）と、0～31バイトの拡張データ（Extension）が配置される。
　ロング拡張モードの場合には、拡張タイプ（EXT_TYPE）に続いて、5ビットの拡張データ長（EXT_LEN(LSB)）と、8ビットの拡張データ長（EXT_LEN(MSB)）と、0～full BBPの拡張データ（Extension）が配置される。なお、ミックス拡張モードは、ロング拡張モードと基本的に同様であるため、その説明は省略する。
　以上、BBヘッダの構造について説明した。次に、図７乃至図１２を参照して、ALPパケットに付加されるALPヘッダについて説明する。
（ALPヘッダの構造）
　図７は、ALPヘッダのシンタックスの例を示す図である。
　3ビットのpacket_typeは、ALPパケットのパケットタイプを示す。1ビットのpayload_configurationは、ALPヘッダに設定される情報に応じて、"0"又は"1"が設定される。
　payload_configurationとして、"0"が指定された場合、ALPヘッダには、header_mode，lengthが配置される。1ビットのheader_modeは、ヘッダモードを示す。11ビットのlengthは、ALPパケットのパケット長（ALPパケット長）を示す。
　header_modeとして、"1"が指定された場合、ALPヘッダには、追加ヘッダとして、additional_header_for_single_packet()が配置される。このadditional_header_for_single_packet()の詳細な構造については、図８を参照して後述する。
　payload_configurationとして、"1"が指定された場合、ALPヘッダには、segmentation_concatenation，lengthが配置される。1ビットのsegmentation_concatenationは、追加ヘッダの種別に応じて、"0"又は"1"が設定される。11ビットのlengthは、ALPパケットのパケット長（ALPパケット長）を示す。
　segmentation_concatenationとして、"0"が指定された場合、ALPヘッダには、追加ヘッダとして、additional_header_for_segmentation()が配置される。このadditional_header_for_segmentation()の詳細な構造については、図９を参照して後述する。
　segmentation_concatenationとして、"1"が指定された場合、ALPヘッダには、追加ヘッダとして、additional_header_for_concatenation()が配置される。なお、このadditional_header_for_concatenation()の詳細な構造については、図１０を参照して後述する。
　なお、フォーマット（Format）として、uimsbf(unsigned integer most significant bit first)が指定された場合、ビット演算をして、整数として扱われることを意味する。また、bslbf(bit string, left bit first)が指定された場合には、ビット列として扱われることを意味する。
（additional_header_for_single_packetの構造）
　図８は、図７のadditional_header_for_single_packet()のシンタックスの例を示す図である。
　5ビットのlength_MSBは、最上位ビット（MSB：Most Significant Bit）のパケット長を示す。1ビットのSIFは、サブストリームID（sub_stream_identification）が存在するかどうかのフラグを示す。サブストリームIDが存在する場合、SIF="1"とされる。
　1ビットのHEFは、拡張ヘッダ（header_extension）が存在するかどうかのフラグを示す。拡張ヘッダが存在する場合、HEF="1"とされる。
　SIFとして、"1"が指定される場合、ALPヘッダには、sub_stream_identification()が配置される。このsub_stream_identification()の詳細な構造については、図１１を参照して後述する。
　HEFとして、"1"が指定される場合、ALPヘッダには、拡張ヘッダとして、header_extension()が配置される。このheader_extension()の詳細な構造については、図１２を参照して後述する。
（additional_header_for_segmentationの構造）
　図９は、図７のadditional_header_for_segmentation()のシンタックスの例を示す図である。
　5ビットのsegment_sequence_numberは、セグメントシーケンス番号を示す。1ビットのlast_segment_indicatorは、最後のセグメントのインジケータを示す。
　SIFは、サブストリームIDが存在するかどうかのフラグを示す。SIFとして、"1"が指定される場合、ALPヘッダには、sub_stream_identification()が配置される。また、HEFは、拡張ヘッダが存在するかどうかのフラグを示す。HEFとして、"1"が指定される場合、ALPヘッダには、header_extension()が配置される。なお、sub_stream_identification()と、header_extension()の詳細な構造は、図１１と、図１２を参照して後述する。
（additional_header_for_concatenationの構造）
　図１０は、図７のadditional_header_for_concatenation()のシンタックスの例を示す図である。
　5ビットのlength_MSBは、最上位ビット（MSB）のパケット長を示す。3ビットのcountは、カウント値を示す。このカウント値に応じて、12ビットのcomponent_lengthが配置される。component_lengthは、コンポーネント長を示す。
　1ビットのHEFは、拡張ヘッダが存在するかどうかのフラグを示す。HEFとして、"1"が指定される場合、ALPヘッダには、header_extension()が配置される。なお、header_extension()の詳細な構造は、図１２を参照して後述する。
（sub_stream_identificationの構造）
　図１１は、図８及び図９のsub_stream_identification()のシンタックスの例を示す図である。
　8ビットのSIDは、サブストリームIDを示す。
（header_extensionの構造）
　図１２は、図８乃至図１０のheader_extension()のシンタックスの例を示す図である。
　8ビットのextension_typeは、拡張タイプを示す。8ビットのextension_lengthは、拡張データ長を示す。拡張データ長に応じた拡張ループ内には、8ビットのextension_byteが配置される。このextension_byteとしては、extension_typeにより指定される拡張タイプのデータが、extension_lengthで指定される拡張データ長に応じて配置されることになる。
　なお、以下の説明では、ALPヘッダの拡張ヘッダ（header_extension）のextension_typeにより指定される「拡張タイプ」を、図５に示したBBヘッダのオプショナルフィールド（Optional Field）の拡張タイプ（EXT_TYPE）と区別するために、便宜的に「拡張データタイプ」と称するものとする。
　以上、ALPヘッダの構造について説明した。
（現状のパケット処理の問題点）
　上述したように、受信装置２０（のBBデパケタイザ２１４）において、BBパケットのペイロードに配置される１又は複数のALPパケットは、BBヘッダの先頭ALPポインタと、ALPヘッダのパケット長（ALPパケットのパケット長）を用いることで、BBパケットから読み出されることになる。
　一方で、その前段のLDPCデコーダ２１１によるLDPC復号化や、BCHデコーダ２１２によるBCH復号化の処理で、LDPCやBCHによる誤り訂正が不可能なエラーが発生した場合、その旨を通知するためのエラー訂正情報が、BBデパケタイザ２１４に通知されることになる。
　BBデパケタイザ２１４では、このエラー訂正情報によって、LDPCやBCHによる誤り訂正が不可能なエラーが発生したことを認識することはできるものの、エラーの有無を示す情報しか通知されないため、データのどの位置でエラーが発生しているのかを認識することができない。
　そのため、例えば、現状のATSC3.0では、あるBBパケットにおいて、LDPCやBCHによる誤り訂正が不可能なデータが存在する場合には、当該BBパケットのペイロードに配置される、すべてのALPパケットを破棄する（FECブロックに含まれるALPパケットをすべて破棄する）ことになる。このようにすべてのALPパケットを破棄してしまうと、結果として、エラーの発生していないデータを含むALPパケットまでも破棄してしまうことになる。
　図１３は、現状のパケット処理を説明する図である。
　図１３の現状のパケット処理においては、BBパケットのペイロードに配置される、複数のALPパケットのうち、先頭のALPパケットのペイロードで、LDPCやBCHによる誤り訂正が不可能なエラーが発生している。BBデパケタイザ２１４では、エラー訂正情報によって、LDPCやBCHによる誤り訂正が不可能なエラーが発生していることは認識できるが、エラーの発生位置までを特定することができないため、当該エラーが発生した先頭のALPパケットのみならず、BBパケットのペイロードに配置される、すべてのALPパケットを破棄する。
　そのため、実際には、BBパケットのペイロードに配置される、先頭のALPパケット（のペイロード）でのみエラーが発生しているにもかかわらず、当該エラーが発生した先頭のALPパケットだけでなく、BBパケットのペイロード内のすべてのALPパケット（エラーのないALPパケットを含む）を抽出することができなくなる。
（現状のパケット処理）
　ここで、図１４のフローチャートを参照して、現状のパケット処理の流れについて説明する。なお、この現状のパケット処理は、受信装置２０（図１）のBBデパケタイザ２１４乃至UDP/IPデパケタイザ２１６（図３）などにより実行される。
　ステップＳ５１１において、BBデパケタイザ２１４は、次の処理対象のBBパケットを取得する。ステップＳ５１２において、BBデパケタイザ２１４は、LDPCデコーダ２１１又はBCHデコーダ２１２からのエラー訂正情報に基づいて、ステップＳ５１１の処理で取得されたBBパケット（のペイロードに配置される複数のALPパケット）に対し、LDPCデコーダ２１１又はBCHデコーダ２１２による誤り訂正が不可能なエラー（LDPC/BCHエラー）が発生したかどうかを判定する。
　ステップＳ５１２において、処理対象のBBパケットで、LDPC/BCHエラーが発生したと判定した場合、処理は、ステップＳ５１１に戻り、次の処理対象のBBパケットが取得される（Ｓ５１１）。
　すなわち、BBデパケタイザ２１４においては、LDPCデコーダ２１１又はBCHデコーダ２１２による誤り訂正が不可能なエラーが発生した場合には、LDPC/BCHエラーが発生したBBパケットのペイロードに配置される、すべてのALPパケットを破棄して、次の処理対象のBBパケットを取得することになる。
　その理由であるが、BBデパケタイザ２１４の前段のLDPCデコーダ２１１又はBCHデコーダ２１２でパリティエラーが発生している場合には、そのFECブロックが破壊されていることになる。しかしながら、エラー訂正情報であると、どこが破壊されているのかが分からず、長さ情報を含むヘッダが壊れている可能性もあり、可変長連鎖が途切れるため、当該FECブロックを破棄することになるからである。
　一方、ステップＳ５１２において、処理対象のBBパケットで、LDPC/BCHエラーが発生していないと判定された場合、処理は、ステップＳ５１３に進められる。ステップＳ５１３において、BBデパケタイザ２１４は、処理対象のBBパケットのペイロードに配置されるALPパケットが、ALPパケットの途中であるかどうかを判定する。
　ステップＳ５１３において、ALPパケットの途中ではないと判定された場合、処理は、ステップＳ５１４に進められる。ステップＳ５１４において、BBデパケタイザ２１４は、処理対象のBBパケットのBBヘッダを取得する。また、ステップＳ５１５において、BBデパケタイザ２１４は、ステップＳ５１４の処理で取得されたBBヘッダに含まれる先頭ALPポインタを取得する。
　ステップＳ５１６において、BBデパケタイザ２１４は、ステップＳ５１５の処理で取得された先頭ALPポインタにより特定される位置に基づいて、処理対象のALPパケット（先頭のALPパケット）のALPヘッダを取得する。また、ステップＳ５１７において、BBデパケタイザ２１４は、ステップＳ５１６の処理で取得されたALPヘッダに含まれるALPパケット長（ALPパケットのパケット長）を取得する。
　ステップＳ５１８において、BBデパケタイザ２１４は、処理対象のALPパケットのペイロードを取得する。ステップＳ５１８の処理で、ALPパケットのペイロードが取得されると、処理は、ステップＳ５１９に進められる。
　ステップＳ５１９においては、処理対象のBBパケットが終了したかどうかが判定される。ステップＳ５１９において、処理対象のBBパケットが終了していないと判定された場合、処理は、ステップＳ５２０に進められる。
　ステップＳ５２０においては、処理対象のALPパケットが終了したかどうかが判定される。ステップＳ５２０において、処理対象のALPパケットが終了していないと判定された場合、処理は、ステップＳ５１８に戻り、それ以降の処理が繰り返される。すなわち、処理対象のBBパケットが終了するか（Ｓ５１９の「YES」）、あるいは、処理対象のALPパケットが終了する（Ｓ５２０の「YES」）まで、処理対象のALPパケットのペイロードが取得される（Ｓ５１８）。
　ステップＳ５２０において、処理対象のALPパケットが終了したと判定された場合、処理は、ステップＳ５２１に進められる。ステップＳ５２１においては、UDP/IP処理が行われる。このUDP/IP処理では、例えば、ALPデパケタイザ２１５によって、BBパケット（のペイロード）から抽出されたALPパケットに対する処理や、UDP/IPデパケタイザ２１６によって、ALPパケット（のペイロード）から抽出されたUDP/IPパケットに対する処理が行われる。
　ステップＳ５２１の処理が終了すると、処理は、ステップＳ５１６に進められる。そして、BBデパケタイザ２１４等では、ステップＳ５１７の処理で取得されたALPパケット長（ALPパケットのパケット長）により特定される位置に応じて、次の処理対象のALPパケット（のALPヘッダやペイロード）が取得され、上述した処理対象のALPパケットに対する処理（Ｓ５１６以降の処理）と同様の処理が行われる。
　また、ステップＳ５１９において、処理対象のBBパケットが終了したと判定された場合、処理は、ステップＳ５１１に進められる。そして、次の処理対象のBBパケットが取得され、上述した処理対象のBBパケットに対する処理（Ｓ５１１以降の処理）と同様の処理が行われる。
　なお、ステップＳ５１３において、ALPパケットの途中であると判定された場合、処理は、ステップＳ５２２に進められる。ステップＳ５２２において、BBデパケタイザ２１４は、処理対象のBBパケットのBBヘッダを空読みする。ステップＳ５２２の処理が終了すると、処理は、ステップＳ５１８に進められ、それ以降の処理が実行される。
　以上のように、現状のパケット処理では、LDPCデコーダ２１１又はBCHデコーダ２１２からのエラー訂正情報基づいて、LDPC/BCHエラーが発生したと判定された場合（Ｓ５１２の「YES」）、処理対象のBBパケットのペイロードに配置される、すべてのALPパケットを破棄して、次の処理対象のBBパケットを取得する（Ｓ５１１）。すなわち、特定のALPパケットで、LDPCやBCHによる誤り訂正が不可能なエラーが発生してしまうと、当該エラーが発生したALPパケットのみならず、処理対象のBBパケット内のすべてのALPパケットが抽出できなくなってしまう（すべてのALPパケットが破棄されてしまう）。
　このとき、エラーのないALPパケットも破棄されてしまうため、BBパケット内のALPパケットで、誤り訂正が不可能なエラーが発生した場合でも、処理対象のBBパケット内のALPパケットが無駄に破棄されるのを防止するための提案が要請されていた。
　そこで、本技術では、BBパケットのBBヘッダや、ALPパケットのALPヘッダに、誤り検出符号が配置されるようにすることで、BBパケット内のALPパケットで、LDPCやBCHによる誤り訂正が不可能なエラーが発生した場合であっても、そのエラーの発生位置を検出して、対象のBBパケット内のALPパケットが無駄に破棄されるのを防止することができるようにする。以下、このような本技術の実施の形態について説明する。
＜３．本技術の実施の形態＞
　本技術の実施の形態では、パケット内の誤り検出符号の伝送方式として、ALPパケットのALPヘッダに誤り検出符号を配置する第１の方式と、BBパケットのBBヘッダに誤り検出符号を配置する第２の方式について説明する。
（１）第１の方式：ALPヘッダに誤り検出符号を配置
（ALPパケットのシンタックス）
　図１５は、ALPパケットのシンタックスの例を示す図である。なお、以下で説明するALPヘッダの構造は、上述した図７乃至図１２に示したALPヘッダの構造を拡張したものである。
　図１５において、ALPパケットは、ALPヘッダとペイロードから構成される。また、ALPヘッダは、ALPパケットヘッダ（ALP_packet_header）、追加ヘッダ（additional_header）、及び拡張ヘッダ（header_extension）から構成される。
　ALPパケットヘッダは、packet_type，PC(payload_configuration)，HM（header_mode），及び、lengthを有している。ただし、上述したように、1ビットのpayload_configurationとして、"0"を指定することで、ALPパケットヘッダに、HM（header_mode）とlengthが配置されることになる。
　3ビットのpacket_typeは、ALPパケットのパケットタイプを示す。このパケットタイプには、"000"が固定で指定される。図１６には、パケットタイプの例を示している。例えば、パケットタイプとして、"000"が指定された場合、当該パケットは、IPv4(Internet Protocol version 4 )のパケットとされる。
　図１５の説明に戻り、1ビットのHM（header_mode）は、ヘッダモードを示す。このヘッダモードとしては、"1"が固定で指定される。上述したように、header_modeとして、"1"を指定することで、ALPヘッダに、追加ヘッダ（additional_header）が配置されることになる。11ビットのlengthは、ALPパケットのパケット長（ALPパケット長）を示す。
　追加ヘッダは、length_MSB，SIF(SubStream Identification Flag)，及び、HEF(Header Extension Flag)を有している。
　5ビットのlength_MSBは、MSB(Most Significant Bit)のパケット長を示す。1ビットのSIFは、サブストリームID（sub_stream_identification）が存在するかどうかのフラグを示す。サブストリームIDが存在する場合、SIF="1"とされる。
　1ビットのHEFは、拡張ヘッダ（header_extension）が存在するかどうかのフラグを示す。拡張ヘッダが存在する場合、HEF="1"とされる。本技術では、ALPパケットのALPヘッダに誤り検出符号を配置する場合に、この拡張ヘッダに誤り検出符号が配置されるようにするので、HEF="1"とされ、ヘッダが拡張される。この拡張ヘッダには、図１７に示すように、extension_typeにより指定される拡張データタイプのデータを、extension_lengthで指定される拡張データ長に応じて配置することができる。
　図１５の説明に戻り、図１５の拡張ヘッダ（header_extension）においては、8ビットのnum_extension_typeを拡張して、拡張データタイプの個数を指定できるようにすることで、１又は複数の拡張データタイプ（extension_type[i]）ごとに、拡張データ長（extension_length[i]）に応じたデータ（DATA[i][j]）を配置できるようにしている。
　ここで、図１８には、拡張データタイプの例を示している。図１８においては、拡張データタイプ（extension_type）として、"0x00"が指定された場合、拡張データ長（extension_length）に応じたループ内のデータ（DATA）には、CRC（巡回冗長検査：Cyclic Redundancy Check）が配置されることを表している。
　また、図１８の拡張データタイプを使用する場合、図１５の拡張データ長に応じたループ内のデータ（DATA）として、例えば、図１９のCRC_DATAのデータ構造を配置することができる。図１９において、CRC_DATAには、modeと、CRCが配置される。
　8ビットのmodeは、CRCのモード（以下、CRCモードという）を示す。例えば、"0"であるCRCモードは、CRC-8を表す。また、例えば、"1"であるCRCモードは、CRC-16を表す。CRCには、modeにより指定されるCRCモードに応じたCRCのデータが配置される。
　CRC-8やCRC-16には、多項式の違いにより様々な種類が存在するが、ここでは、例えば、CCITT (Comite Consultatif International Telegraphique et Telephonique：国際電信電話諮問委員会)で規定されたCRC-8-CCITT（X8 + X7 + X3 + X2 + 1）や、CRC-16-CCITT（X16 + X12 + X5 + 1）を用いることができる。
　ただし、CRC-8-CCITT以外の他のCRC-8や、CRC-16-CCITT以外の他のCRC-16は勿論、例えば、CRC-32やCRC-64などの他のCRCが用いられるようにしてもよい。また、CRCは、誤り検出符号の一例であり、他の誤り検出符号が用いられるようにしてもよい。
　なお、図１８の拡張データタイプとして、"0xff"が指定された場合、拡張データ長に応じたループ内のデータ（DATA）には、プライベートユーザデータ（Private User Data）が配置されることを表している。このプライベートユーザデータとしては、例えば、デバイス間で通知したいデータなど、任意のデータを配置することができる。また、図１８において、"0x01"～"0xfe"である拡張データタイプは、将来の拡張用の領域（Reserved）とされる。
　また、図１８の拡張データタイプでは、CRCのみを指定し、CRC-8やCRC-16などのCRCモードは、図１９のCRC_DATAで指定されるようにしたが、CRCモードに応じたCRCが、拡張データタイプにより指定されるようにしてもよい。
　図２０には、CRCモードに応じたCRCを指定可能な拡張データタイプの例を示している。図２０においては、拡張データタイプ（extension_type）として、"0x00"が指定された場合、図１５の拡張データ長（extension_length）に応じたループ内のデータ（DATA）には、CRC-8のデータが配置されることを表している。また、拡張データタイプとして、"0x01"が指定された場合、図１５の拡張データ長に応じたループ内のデータ（DATA）には、CRC-16のデータが配置されることを表している。
　以上のように、第１の方式を採用した場合、ALPパケットのALPヘッダ（拡張ヘッダ）に誤り検出符号（例えば、CRC-8やCRC-16）が配置されるので、受信装置２０（のBBデパケタイザ２１４）では、このALPヘッダに含まれる誤り検出符号を用いた誤り検出処理を行い、その検出位置（LDPCやBCHによる誤り訂正が不可能なエラーの発生位置）に応じて、BBパケットのペイロードに配置されたALPパケットを処理することができる。
（２）第２の方式：BBヘッダに誤り検出符号を配置
（BBヘッダの構造）
　図２１は、BBパケットのBBヘッダにCRCを配置する場合のデータ構造の例を示す図である。なお、図２１のBBヘッダの構造は、上述した図５に示したBBヘッダの構造に対応しており、説明が繰り返しになる部分については、その説明を適宜省略するものとする。
　図２１において、BBパケットは、BBヘッダとペイロード（Payload）から構成される。BBヘッダには、ベースフィールド（Base Field）のほか、オプショナルフィールド（Optional Field）と、拡張フィールド（Extension Field）を配置することができる。
　ベースフィールドには、2ビットのオプショナルフラグ（OPTI：OPTIONAL）が配置される。このオプショナルフラグとして、"01"，"10"，又は"11"が設定された場合、オプショナルフィールドと拡張フィールドの拡張が行われる。この拡張が行われた場合には、オプショナルフィールドの先頭に、3ビットの拡張タイプ（EXT_TYPE）が設定される。
　この拡張タイプには、拡張フィールドのタイプが指定される。例えば、拡張タイプとして、"001"が指定された場合、拡張フィールドには、CRC-8のデータが配置されることを表している。また、拡張タイプとして、"010"が指定された場合、拡張フィールドには、CRC-16のデータが配置されることを表している。
　ここでは、上述した第１の方式と同様に、CRC-8とCRC-16としては、例えば、CRC-8-CCITT（X8 + X7 + X3 + X2 + 1）や、CRC-16-CCITT（X16 + X12 + X5 + 1）を用いることができる。ただし、CRC-8-CCITT以外の他のCRC-8や、CRC-16-CCITT以外の他のCRC-16は勿論、例えば、CRC-32やCRC-64などの他のCRCが用いられるようにしてもよい。また、CRCは、誤り検出符号の一例であり、他の誤り検出符号が用いられるようにしてもよい。
　なお、図２１の拡張タイプ（EXT_TYPE）において、"011"～"110"である拡張タイプは、将来の拡張用の領域とされる。また、拡張タイプとして、"000"が指定された場合には、カウンタが配置されることを意味し、"111"が指定された場合には、パディングされることを意味する。
　以上のように、第２の方式を採用した場合、BBパケットのBBヘッダ（拡張フィールド）に誤り検出符号（例えば、CRC-8やCRC-16）が配置されるので、受信装置２０（のBBデパケタイザ２１４）では、このBBヘッダに含まれる誤り検出符号を用いた誤り検出処理を行うことができる。
　なお、第１の方式と第２の方式は、いずれか一方の方式を採用してもよいし、両方の方式を同時に採用してもよい。両方の方式を同時に採用した場合には、ALPパケットのALPヘッダと、BBパケットのBBヘッダのそれぞれに対し、誤り検出符号が配置されることになる。
（３）本技術のパケット処理
（本技術のパケット処理）
　次に、上述した第１の方式や第２の方式によって、ALPパケットのALPヘッダやBBパケットのBBヘッダに、誤り検出符号が配置された場合の具体的なパケット処理の内容について説明する。ここでは、パケット内の誤り検出符号の伝送方式として、第１の方式が採用された場合に、受信装置２０（のBBデパケタイザ２１４）で実行される、ALPパケットのALPヘッダに含まれる誤り検出符号（例えばCRC-8やCRC-16）を用いた誤り検出処理について説明する。
　ただし、この誤り検出処理では、エラーの検出位置（LDPCやBCHによる誤り訂正が不可能なエラーの発生位置）に応じて、ALPパケットに対する処理内容が変わるため、以下、エラーの検出位置がALPパケットのペイロードである場合と、エラーの検出位置がALPパケットのALPヘッダである場合についてそれぞれ説明する。
（Ａ）ケース１：エラー検出位置がペイロードの場合
　図２２は、エラーの検出位置がALPパケットのペイロードである場合における、本技術のパケット処理を説明する図である。
　図２２の本技術のパケット処理においては、ALPパケットのALPヘッダに含まれる誤り検出符号（例えばCRC-8やCRC-16）を用いた誤り検出処理によって、処理対象のBBパケットのペイロードに配置される、複数のALPパケットのうち、先頭のALPパケットのペイロードで、LDPCやBCHによる誤り訂正が不可能なエラーが発生したことが検出されている。
　図２２の本技術のパケット処理では、処理対象のBBパケットのBBヘッダの先頭ALPポインタによりその位置が特定される先頭のALPパケットのペイロードでエラーが発生していることを検出（認識）された場合でも、当該ALPパケットのALPヘッダにエラーがないので、ALPヘッダのパケット長（ALPパケットのパケット長）に応じて、エラーが検出された先頭のALPパケット以降のALPパケットを抽出することができる。
　すなわち、ALPヘッダの誤り検出符号を用いた誤り検出処理によって、LDPCやBCHによる誤り訂正が不可能なエラーが発生していることを認識するだけでなく、そのエラーの発生している位置が検出されるため、エラーが発生しているALPパケット（のペイロード）を特定して、処理対象のBBパケットのペイロード内で、ALPパケットの可変長連鎖が途切れないようにすることで、エラーの発生していないALPパケットが破棄されないようにしている。
　換言すれば、BBパケットのペイロードに配置されるALPパケットのペイロードで、LDPCやBCHによる誤り訂正が不可能なエラーが発生した場合でも、ALPパケットのALPヘッダ（の誤り検出符号）にエラーが発生していなければ、処理対象のBBパケットのペイロード内で、継続してALPパケットを抽出することができる。
　これにより、図２２の本技術のパケット処理では、上述した現状のパケット処理（図１３）のような、LDPCやBCHによる誤り訂正が不可能なエラーが発生したALPパケットのみならず、BBパケットのペイロードに配置される、すべてのALPパケットを破棄するといった処理が行われないため、ALPパケットが無駄に破棄されるのを防止することができる。
（Ｂ）ケース２：エラー検出位置がALPヘッダの場合
　図２３は、エラーの検出位置がALPパケットのALPヘッダである場合における、本技術のパケット処理を説明する図である。
　図２３の本技術のパケット処理においては、ALPパケットのALPヘッダに含まれる誤り検出符号（例えばCRC-8やCRC-16）を用いた誤り検出処理によって、処理対象のBBパケットのペイロードに配置される、複数のALPパケットのうち、２番目のALPパケットのALPヘッダで、LDPCやBCHによる誤り訂正が不可能なエラーが発生したことが検出されている。
　図２３の本技術のパケット処理では、２番目のALPパケットのALPヘッダでエラーが発生していることが検出（認識）されているため、当該ALPヘッダの情報が正しい情報とは限らないので、２番目のALPパケット以降のALPパケットは破棄するが、１つ前の先頭のALPパケットでは、エラーが発生していないため、先頭のALPパケットは破棄しないようにする。
　すなわち、ALPヘッダの誤り検出符号を用いた誤り検出処理によって、LDPCやBCHによる誤り訂正が不可能なエラーが発生していることを認識するだけでなく、そのエラーの発生している位置が検出されるため、エラーが発生しているALPパケット（のALPヘッダ）を特定して、処理対象のBBパケットのペイロード内で、可能な限り、エラーの発生していないALPパケットが破棄されないようにしている。
　換言すれば、BBパケットのペイロードに配置されるALPパケットのALPヘッダで、LDPCやBCHによる誤り訂正が不可能なエラーが発生した場合でも、処理対象のBBパケットのペイロード内で、当該ALPヘッダを含むALPパケットの直前のALPパケットまでは、継続してALPパケットを抽出することができる。
　これにより、図２３の本技術のパケット処理では、処理対象のBBパケットのペイロードに配置される、すべてのALPパケットを破棄しないようにすることはできないが（救うことはできないが）、エラーが発生したALPヘッダを含むALPパケットの直前のALPパケットまでの一部のALPパケットを破棄しないようにすることができる（ある程度のALPパケットを救うことができる）。
　つまり、図２３の本技術のパケット処理では、一部のALPパケットは破棄されるものの、上述した現状のパケット処理（図１３）のような、エラーが発生したALPパケットのみならず、BBパケットのペイロードに配置される、すべてのALPパケットを破棄するといった処理が行われないため、ALPパケットが無駄に破棄されるのを防止することができる。
　次に、図２４乃至図２６のフローチャートを参照して、図１の伝送システム１を構成する送信装置１０と受信装置２０で実行される処理の詳細な内容について説明する。
（送信側データ処理）
　まず、図２４のフローチャートを参照して、送信装置１０（図１）により実行される送信側データ処理の流れを説明する。
　ステップＳ１０１においては、放送番組等のコンテンツのデータに対するパケット処理が行われる。このパケット処理では、UDP/IPパケタイザ１０３、ALPパケタイザ１０４、及びBBパケタイザ１０５によって、UDP/IPパケット、ALPパケット、及びBBパケットを生成する処理が行われる。
　ただし、パケット内の誤り検出符号の伝送方式として、第１の方式を採用する場合、ステップＳ１０１の処理で生成されるALPパケットのALPヘッダには、例えば、CRC-8やCRC-16等の誤り検出符号が配置される。ここでは、例えば、図１５に示したように、ALPヘッダの拡張ヘッダ（header_extension）に、拡張データタイプ（extension_type）に応じた誤り検出符号（DATA）が配置される。
　また、パケット内の誤り検出符号の伝送方式として、第２の方式を採用する場合、ステップＳ１０１の処理で生成されるBBパケットのBBヘッダには、例えば、CRC-8やCRC-16等の誤り検出符号が配置される。ここでは、例えば、図２１に示したように、BBヘッダの拡張フィールド（Extension Field）に、拡張タイプ（EXT_TYPE）に応じた誤り検出符号（例えばCRC-8やCRC-16）が配置される。
　ステップＳ１０２においては、ステップＳ１０１の処理で得られるデータに対する誤り訂正符号化処理が行われる。この誤り訂正符号化処理では、BCHエンコーダ１０７によるBCH符号化や、LDPCエンコーダ１０８によるLDPC符号化などの処理が行われる。
　ステップＳ１０３においては、ステップＳ１０２の処理で誤り訂正符号化処理が施されたデータに対する変調処理が行われる。この変調処理では、各種のインターリーバによるインターリーブ処理や、データマッパ１１１やOFDM送信部１１７による処理などが行われる。そして、この変調処理で得られるRF信号（OFDM信号）が、伝送路３０を介して送信される。
　以上、送信側データ処理の流れについて説明した。
（受信側データ処理）
　次に、図２５のフローチャートを参照して、受信装置２０（図１）により実行される受信側データ処理の流れを説明する。
　ステップＳ２０１においては、送信装置１０から伝送路３０を介して送信されてくるRF信号（OFDM信号）に対する復調処理が行われる。この復調処理では、OFDM受信部２０２やデータデマッパ２０８による処理や、各種のデインターリーバによるデインターリーブ処理などが行われる。
　ステップＳ２０２においては、ステップＳ２０１の処理で復調されたデータに対する誤り訂正復号化処理が行われる。この誤り訂正復号化処理では、LDPCデコーダ２１１によるLDPC復号化や、BCHデコーダ２１２によるBCH復号化などの処理が行われる。
　ステップＳ２０３においては、ステップＳ２０２の処理で誤り訂正復号化処理が施されたデータに対するパケット処理が行われる。このパケット処理では、BBデパケタイザ２１４、ALPデパケタイザ２１５、及びUDP/IPデパケタイザ２１６によって、BBパケット、ALPパケット、及びUDP/IPパケットに対するパケット処理が行われる。
　ただし、パケット内の誤り検出符号の伝送方式として、第１の方式を採用する場合、ステップＳ２０３の処理で処理されるALPパケットのALPヘッダ（の拡張ヘッダ（header_extension））には、拡張データタイプ（extension_type）に応じた誤り検出符号（例えばCRC-8やCRC-16）が配置されているので、このALPヘッダの誤り検出符号を用いた誤り検出処理が行われる。
　また、パケット内の誤り検出符号の伝送方式として、第２の方式を採用する場合、ステップＳ２０３の処理で処理されるBBパケットのBBヘッダ（の拡張フィールド（Extension Field））には、拡張タイプ（EXT_TYPE）に応じた誤り検出符号（例えばCRC-8やCRC-16）が配置されているので、このBBヘッダの誤り検出符号を用いた誤り検出処理が行われる。
　なお、このパケット処理の詳細な処理内容については、図２６のフローチャートを参照して後述する。また、パケット処理後のデータが、AVデコーダ２１８等によりデコードされることで、受信装置２０では、放送番組等のコンテンツが再生される。
　以上、受信側データ処理の流れについて説明した。
（本技術のパケット処理）
　最後に、図２６のフローチャートを参照して、図２５のステップＳ２０３の処理に対応する本技術のパケット処理の流れを説明する。なお、この本技術のパケット処理は、受信装置２０（図１）のBBデパケタイザ２１４乃至UDP/IPデパケタイザ２１６（図３）などにより実行される。
　ステップＳ２１１において、BBデパケタイザ２１４は、次の処理対象のBBパケットを取得する。ステップＳ２１２において、BBデパケタイザ２１４は、ステップＳ２１１の処理で取得された処理対象のBBパケットのペイロードに配置されるALPパケットが、ALPパケットの途中であるかどうかを判定する。
　ステップＳ２１２において、ALPパケットの途中ではないと判定された場合、処理は、ステップＳ２１３に進められる。ステップＳ２１３において、BBデパケタイザ２１４は、処理対象のBBパケットのBBヘッダを取得する。
　ステップＳ２１３Ａにおいて、BBデパケタイザ２１４は、ステップＳ２１３の処理で取得されたBBヘッダ（の拡張フィールド）に含まれるCRC値（BB CRC値）を取得する。また、ステップＳ２１３Ｂにおいて、BBデパケタイザ２１４は、ステップＳ２１３Ａの処理で取得されたCRC値（BB CRC値）に基づいて、CRC値（BB CRC値）を計算する。
　ステップＳ２１３Ｃにおいて、BBデパケタイザ２１４は、ステップＳ２１３Ｂの計算結果に従い、CRC値（BB CRC値）の比較エラーが発生したかどうかを判定する。なお、このBB CRC値を用いた比較エラーの判定処理（Ｓ２１３Ｃ）は、後述するALP CRC値を用いた比較エラー判定処理（Ｓ２１８）と同様に処理されるので、ここでは、その詳細な内容の説明は省略する。
　ステップＳ２１３Ｃにおいて、CRC値（BB CRC値）の比較エラーが発生したと判定された場合、処理は、ステップＳ２１１に戻される。そして、次の処理対象のBBパケットが取得され、上述した処理対象のBBパケットに対する処理（Ｓ２１１以降の処理）と同様の処理が行われる。
　一方、ステップＳ２１３Ｃにおいて、CRC値（BB CRC値）の比較エラーが発生していないと判定された場合、処理は、ステップＳ２１４に進められる。ステップＳ２１４において、BBデパケタイザ２１４は、ステップＳ２１３の処理で取得されたBBヘッダに含まれる先頭ALPポインタを取得する。
　ステップＳ２１５において、BBデパケタイザ２１４は、ステップＳ２１４の処理で取得された先頭ALPポインタにより特定される位置に基づいて、処理対象のALPパケット（先頭のALPパケット）のALPヘッダを取得する。
　ステップＳ２１６において、BBデパケタイザ２１４は、ステップＳ２１５の処理で取得されたALPヘッダ（の拡張ヘッダ）に含まれるCRC値（ALP CRC値）を取得する。また、ステップＳ２１７において、BBデパケタイザ２１４は、ステップＳ２１６の処理で取得されたCRC値（ALP CRC値）に基づいて、CRC値（ALP CRC値）を計算する。
　ステップＳ２１８において、BBデパケタイザ２１４は、ステップＳ２１７の計算結果に従い、CRC値（ALP CRC値）の比較エラーが発生したかどうかを判定する。
　ここでは、例えば、CRC-8やCRC-16が用いられる場合に、送信装置１０から伝送路３０を介して、入力されたデータ列に対して所定の計算が行われ、その余りがチェック用の値として追加されたデータが送信されてくるので、受信装置２０（のBBデパケタイザ２１４）では、送信装置１０からのデータを用いて同じ計算（所定の計算）を行い、その計算結果を、チェック用の値と比較することで、データの破損の有無が判定されることになる。
　ステップＳ２１８において、CRC値（ALP CRC値）の比較エラーが発生したと判定された場合、処理は、ステップＳ２１１に戻される。そして、次の処理対象のBBパケットが取得され、上述した処理対象のBBパケットに対する処理（Ｓ２１１以降の処理）と同様の処理が行われる。
　すなわち、この場合、ALPパケットのALPヘッダでエラーが検出されたことになるので（図２３のケース２のエラー検出位置がALPヘッダの場合に相当）、当該ALPヘッダを含むALPパケット以降のALPパケットは破棄するが、当該ALPヘッダを含むALPパケットよりも前のALPパケットでは、エラーが発生していないため、それらのALPパケットが破棄されないようにしている。
　一方、ステップＳ２１８において、CRC値（ALP CRC値）の比較エラーが発生していないと判定された場合、処理は、ステップＳ２１９に進められる。ステップＳ２１９において、BBデパケタイザ２１４は、ステップＳ２１５の処理で取得されたALPヘッダに含まれるALPパケット長（ALPパケットのパケット長）を取得する。なお、ここで取得されるALPパケット長は、CRCのエラー検出処理よってエラーが検出されなかったALPヘッダから取得されたデータであるため、信頼できる情報であると言える。
　ステップＳ２２０において、BBデパケタイザ２１４は、処理対象のALPパケットのペイロードを取得する。ステップＳ２２０の処理で、ALPパケットのペイロードが取得されると、処理は、ステップＳ２１１に進められる。
　ステップＳ２２１においては、処理対象のBBパケットが終了したかどうかが判定される。ステップＳ２１１において、処理対象のBBパケットが終了していないと判定された場合、処理は、ステップＳ２２２に進められる。
　ステップＳ２２２においては、処理対象のALPパケットが終了したかどうかが判定される。ステップＳ２２２において、処理対象のALPパケットが終了していないと判定された場合、処理は、ステップＳ２２０に戻り、それ以降の処理が繰り返される。すなわち、処理対象のBBパケットが終了するか（Ｓ２２１の「YES」）、あるいは、処理対象のALPパケットが終了する（Ｓ２２２の「YES」）まで、処理対象のALPパケットのペイロードが取得される（Ｓ２２０）。
　ステップＳ２２２において、処理対象のALPパケットが終了したと判定された場合、処理は、ステップＳ２２３に進められる。ステップＳ２２３においては、UDP/IP処理が行われる。このUDP/IP処理では、例えば、ALPデパケタイザ２１５によって、BBパケット（のペイロード）から抽出されたALPパケットに対する処理や、UDP/IPデパケタイザ２１６によって、ALPパケット（のペイロード）から抽出されたUDP/IPパケットに対する処理が行われる。
　ステップＳ２２３の処理が終了すると、処理は、ステップＳ２１５に進められる。そして、BBデパケタイザ２１４等では、ステップＳ２１９の処理で取得されたALPパケット長（ALPパケットのパケット長）により特定される位置に応じて、次の処理対象のALPパケット（のALPヘッダやペイロード）が取得され、上述した処理対象のALPパケットに対する処理（Ｓ２１５以降の処理）と同様の処理が行われる。
　また、ステップＳ２２１において、処理対象のBBパケットが終了したと判定された場合、処理は、ステップＳ２１１に進められる。そして、次の処理対象のBBパケットが取得され、上述した処理対象のBBパケットに対する処理（Ｓ２１１以降の処理）と同様の処理が行われる。
　なお、ステップＳ２１２において、処理対象のALPパケットの途中であると判定された場合、処理は、ステップＳ２２４に進められる。ステップＳ２２４において、BBデパケタイザ２１４は、処理対象のBBパケットのBBヘッダを空読みする。ステップＳ２２４の処理が終了すると、処理は、ステップＳ２２０に進められ、それ以降の処理が実行される。
　以上、本技術のパケット処理の流れについて説明した。この本技術のパケット処理では、ALPパケットのALPヘッダでエラーが検出された場合に、一部のALPパケットは破棄されるものの、エラーの発生していないALPパケットは破棄されないため、ALPパケットが無駄に破棄されるのを防止することができる。
＜４．変形例＞
　上述した説明としては、デジタル放送の規格として、米国等で採用されている方式であるATSC（特に、ATSC3.0）を説明したが、本技術は、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。また、上述した説明では、IPパケットを用いたIP伝送方式が採用されるATSC3.0を例にして説明したが、IP伝送方式に限らず、例えば、MPEG2-TS(Transport Stream)方式等の他の方式に適用するようにしてもよい。
　また、デジタル放送の規格としては、地上波放送のほか、放送衛星（BS)や通信衛星（CS）等を利用した衛星放送や、ケーブルテレビ（CATV）等の有線放送などの規格に適用することができる。
　また、上述したパケットやヘッダなどの名称は、一例であって、他の名称が用いられる場合がある。例えば、BBパケット(Baseband Packet)は、BBS(Baseband Stream)やBBF(Baseband Frame)などと称される場合がある。また、ALP(ATSC Link layer Protocol)パケットは、Genericパケットなどと称される場合がある。ただし、これらの名称の違いは、形式的な違いであって、対象のパケットやヘッダなどの実質的な内容が異なるものではない。
　さらに、本技術は、伝送路として、放送網以外の伝送路、すなわち、例えば、インターネットや電話網等の通信回線（通信網）などを利用することを想定して規定されている所定の規格（デジタル放送の規格以外の規格）などにも適用することができる。その場合には、伝送システム１（図１）の伝送路３０として、インターネットや電話網などの通信回線が利用され、送信装置１０は、インターネット上に設けられたサーバとすることができる。そして、受信装置２０が通信機能を有するようにすることで、送信装置１０（サーバ）は、受信装置２０からの要求に応じて、処理を行うことになる。一方で、受信装置２０は、送信装置１０（サーバ）から伝送路３０（通信回線）を介して送信されてくるデータを処理する。
＜５．コンピュータの構成＞
　上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図２７は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
　コンピュータ１０００において、CPU(Central Processing Unit)１００１、ROM(Read Only Memory)１００２、RAM(Random Access Memory)１００３は、バス１００４により相互に接続されている。バス１００４には、さらに、入出力インターフェース１００５が接続されている。入出力インターフェース１００５には、入力部１００６、出力部１００７、記録部１００８、通信部１００９、及び、ドライブ１０１０が接続されている。
　入力部１００６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１００７は、ディスプレイ、スピーカなどよりなる。記録部１００８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１００９は、ネットワークインターフェースなどよりなる。ドライブ１０１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア１０１１を駆動する。
　以上のように構成されるコンピュータ１０００では、CPU１００１が、ROM１００２や記録部１００８に記録されているプログラムを、入出力インターフェース１００５及びバス１００４を介して、RAM１００３にロードして実行することにより、上述した一連の処理が行われる。
　コンピュータ１０００（CPU１００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア１０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
　コンピュータ１０００では、プログラムは、リムーバブルメディア１０１１をドライブ１０１０に装着することにより、入出力インターフェース１００５を介して、記録部１００８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部１００９で受信し、記録部１００８にインストールすることができる。そのほか、プログラムは、ROM１００２や記録部１００８に、あらかじめインストールしておくことができる。
　ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
　なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
　また、本技術は、以下のような構成をとることができる。
（１）
　復調後のベースバンドパケットのペイロートに複数配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDP(User Datagram Protocol)パケットを含むIP(Internet Protocol)パケットを配置したペイロードとから構成される前記伝送パケットを処理する処理部を備え、
　前記処理部は、前記伝送パケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う
　受信装置。
（２）
　前記処理部は、前記伝送パケットのヘッダに含まれる前記誤り検出符号を用いた誤り検出処理によりエラーが検出された場合、前記エラーの検出位置に応じた処理を行う
　（１）に記載の受信装置。
（３）
　前記処理部は、前記エラーの検出位置が、前記伝送パケットのペイロードである場合、前記ベースバンドパケットのペイロードにおいて、前記エラーの検出位置以降に配置される前記伝送パケットを抽出してそのまま処理する
　（２）に記載の受信装置。
（４）
　前記伝送パケットは、前記エラーの検出位置が、前記伝送パケットのヘッダである場合、前記ベースバンドパケットのペイロードにおいて、前記エラーの検出位置以降に配置される前記伝送パケットを破棄する
　（２）に記載の受信装置。
（５）
　前記誤り検出符号は、巡回冗長検査（CRC：Cyclic Redundancy Check）である
　（１）乃至（４）のいずれかに記載の受信装置。
（６）
　前記伝送パケットは、可変長のパケットであり、
　前記ベースバンドパケットのヘッダは、前記伝送パケットの先頭の位置を示すポインタを含み、
　前記伝送パケットのヘッダは、前記伝送パケットのデータ長を含み、
　前記ベースバンドパケットのペイロードに配置される複数の前記伝送パケットの配置位置は、前記ポインタと前記データ長により特定される
　（１）乃至（５）のいずれかに記載の受信装置。
（７）
　受信装置のデータ処理方法において、
　前記受信装置が、
　復調後のベースバンドパケットのペイロートに複数配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードとから構成される前記伝送パケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う
　ステップを含むデータ処理方法。
（８）
　変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードとから構成される前記伝送パケットを生成する処理部を備え、
　前記処理部は、前記ベースバンドパケットのペイロードに、複数の前記伝送パケットを配置する
　送信装置。
（９）
　送信装置のデータ処理方法において、
　前記送信装置が、
　変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードとから構成される前記伝送パケットを生成し、
　前記ベースバンドパケットのペイロードに、複数の前記伝送パケットを配置する
　ステップを含むデータ処理方法。
（１０）
　復調後のベースバンドパケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される伝送パケットを複数配置したペイロードとから構成される前記ベースバンドパケットを処理する処理部を備え、
　前記処理部は、前記ベースバンドパケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う
　受信装置。
（１１）
　前記誤り検出符号は、巡回冗長検査（CRC）である
　（１０）に記載の受信装置。
（１２）
　前記伝送パケットは、可変長のパケットであり、
　前記ベースバンドパケットのヘッダは、前記伝送パケットの先頭の位置を示すポインタを含み、
　前記伝送パケットのヘッダは、前記伝送パケットのデータ長を含み、
　前記ベースバンドパケットのペイロードに配置される複数の前記伝送パケットの配置位置は、前記ポインタと前記データ長により特定される
　（１０）又は（１１）に記載の受信装置。
（１３）
　受信装置のデータ処理方法において、
　前記受信装置が、
　復調後のベースバンドパケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される伝送パケットを複数配置したペイロードとから構成される前記ベースバンドパケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う
　ステップを含むデータ処理方法。
（１４）
　変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される前記伝送パケットを生成する処理部を備え、
　前記処理部は、前記ベースバンドパケットのヘッダに、誤り検出符号を配置し、前記ベースバンドパケットのペイロードに、複数の前記伝送パケットを配置する
　送信装置。
（１５）
　送信装置のデータ処理方法において、
　前記送信装置が、
　変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される前記伝送パケットを生成し、
　前記ベースバンドパケットのヘッダに、誤り検出符号を配置し、前記ベースバンドパケットのペイロードに、複数の前記伝送パケットを配置する
　ステップを含むデータ処理方法。
　１　伝送システム，　１０　送信装置，　２０　受信装置，　３０　伝送路，　１０１　AVエンコーダ，　１０２　FLUTEエンコーダ，　１０３　UDP/IPパケタイザ，　１０４　ALPパケタイザ，　１０５　BBパケタイザ，　１０６　スクランブラ，　１０７　BCHエンコーダ，　１０８　LDPCエンコーダ，　１０９　パリティインターリーバ，　１１０　カラムツイストインターリーバ，　１１１　データマッパ，　１１２　CQディレイ部，　１１３　セルインターリーバ，　１１４　時間インターリーバ，　１１５　フレームマッパ，　１１６　周波数インターリーバ，　１１７　OFDM送信部，　１１８　RF出力部，　２０１　RF入力部，　２０２　OFDM受信部，　２０３　周波数デインターリーバ，　２０４　フレームデマッパ，　２０５　時間デインターリーバ，　２０６　セルデインターリーバ，　２０７　CQディレイ部，　２０８　データデマッパ，　２０９　カラムツイストデインターリーバ，　２１０　パリティデインターリーバ，　２１１　LDPCデコーダ，　２１２　BCHデコーダ，　２１３　デスクランブラ，　２１４　BBデパケタイザ，　２１５　ALPデパケタイザ，　２１６　UDP/IPデパケタイザ，　２１７　FLUTEデコーダ，　２１８　AVデコーダ，　１０００　コンピュータ，　１００１　CPU

Claims (15)

  1. 　復調後のベースバンドパケットのペイロートに複数配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDP(User Datagram Protocol)パケットを含むIP(Internet Protocol)パケットを配置したペイロードとから構成される前記伝送パケットを処理する処理部を備え、
    　前記処理部は、前記伝送パケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う
    　受信装置。
  2. 　前記処理部は、前記伝送パケットのヘッダに含まれる前記誤り検出符号を用いた誤り検出処理によりエラーが検出された場合、前記エラーの検出位置に応じた処理を行う
    　請求項１に記載の受信装置。
  3. 　前記処理部は、前記エラーの検出位置が、前記伝送パケットのペイロードである場合、前記ベースバンドパケットのペイロードにおいて、前記エラーの検出位置以降に配置される前記伝送パケットを抽出してそのまま処理する
    　請求項２に記載の受信装置。
  4. 　前記伝送パケットは、前記エラーの検出位置が、前記伝送パケットのヘッダである場合、前記ベースバンドパケットのペイロードにおいて、前記エラーの検出位置以降に配置される前記伝送パケットを破棄する
    　請求項２に記載の受信装置。
  5. 　前記誤り検出符号は、巡回冗長検査（CRC：Cyclic Redundancy Check）である
    　請求項１に記載の受信装置。
  6. 　前記伝送パケットは、可変長のパケットであり、
    　前記ベースバンドパケットのヘッダは、前記伝送パケットの先頭の位置を示すポインタを含み、
    　前記伝送パケットのヘッダは、前記伝送パケットのデータ長を含み、
    　前記ベースバンドパケットのペイロードに配置される複数の前記伝送パケットの配置位置は、前記ポインタと前記データ長により特定される
    　請求項１に記載の受信装置。
  7. 　受信装置のデータ処理方法において、
    　前記受信装置が、
    　復調後のベースバンドパケットのペイロートに複数配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードとから構成される前記伝送パケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う
    　ステップを含むデータ処理方法。
  8. 　変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードとから構成される前記伝送パケットを生成する処理部を備え、
    　前記処理部は、前記ベースバンドパケットのペイロードに、複数の前記伝送パケットを配置する
    　送信装置。
  9. 　送信装置のデータ処理方法において、
    　前記送信装置が、
    　変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードとから構成される前記伝送パケットを生成し、
    　前記ベースバンドパケットのペイロードに、複数の前記伝送パケットを配置する
    　ステップを含むデータ処理方法。
  10. 　復調後のベースバンドパケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される伝送パケットを複数配置したペイロードとから構成される前記ベースバンドパケットを処理する処理部を備え、
    　前記処理部は、前記ベースバンドパケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う
    　受信装置。
  11. 　前記誤り検出符号は、巡回冗長検査（CRC）である
    　請求項１０に記載の受信装置。
  12. 　前記伝送パケットは、可変長のパケットであり、
    　前記ベースバンドパケットのヘッダは、前記伝送パケットの先頭の位置を示すポインタを含み、
    　前記伝送パケットのヘッダは、前記伝送パケットのデータ長を含み、
    　前記ベースバンドパケットのペイロードに配置される複数の前記伝送パケットの配置位置は、前記ポインタと前記データ長により特定される
    　請求項１０に記載の受信装置。
  13. 　受信装置のデータ処理方法において、
    　前記受信装置が、
    　復調後のベースバンドパケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される伝送パケットを複数配置したペイロードとから構成される前記ベースバンドパケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う
    　ステップを含むデータ処理方法。
  14. 　変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される前記伝送パケットを生成する処理部を備え、
    　前記処理部は、前記ベースバンドパケットのヘッダに、誤り検出符号を配置し、前記ベースバンドパケットのペイロードに、複数の前記伝送パケットを配置する
    　送信装置。
  15. 　送信装置のデータ処理方法において、
    　前記送信装置が、
    　変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される前記伝送パケットを生成し、
    　前記ベースバンドパケットのヘッダに、誤り検出符号を配置し、前記ベースバンドパケットのペイロードに、複数の前記伝送パケットを配置する
    　ステップを含むデータ処理方法。
PCT/JP2017/004848 2016-02-26 2017-02-10 受信装置、送信装置、及び、データ処理方法 WO2017145790A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2018501567A JPWO2017145790A1 (ja) 2016-02-26 2017-02-10 受信装置、送信装置、及び、データ処理方法
US16/078,138 US20200044774A1 (en) 2016-02-26 2017-02-10 Reception apparatus, transmission apparatus, and data processing method
EP17756231.1A EP3422618A4 (en) 2016-02-26 2017-02-10 RECEIVING DEVICE, SENDING DEVICE AND DATA PROCESSING METHOD

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016-035731 2016-02-26
JP2016035731 2016-02-26

Publications (1)

Publication Number Publication Date
WO2017145790A1 true WO2017145790A1 (ja) 2017-08-31

Family

ID=59686119

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/004848 WO2017145790A1 (ja) 2016-02-26 2017-02-10 受信装置、送信装置、及び、データ処理方法

Country Status (4)

Country Link
US (1) US20200044774A1 (ja)
EP (1) EP3422618A4 (ja)
JP (1) JPWO2017145790A1 (ja)
WO (1) WO2017145790A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019239695A1 (ja) * 2018-06-13 2019-12-19 ソニーセミコンダクタソリューションズ株式会社 復調回路、処理方法、および処理装置
JP2020043524A (ja) * 2018-09-13 2020-03-19 株式会社日立国際電気 配信システム

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110601971B (zh) * 2019-09-17 2021-10-26 南京林业大学 一种数据传输方法、装置、电子设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006352897A (ja) * 2006-07-07 2006-12-28 Toshiba Corp 通信装置、通信方法、および通信システム
JP2013520036A (ja) * 2010-02-26 2013-05-30 パナソニック株式会社 デジタル放送システムにおける物理レイヤシグナリング
US20150229443A1 (en) * 2014-02-13 2015-08-13 Lg Electronics Inc. Apparatus and method for sending and receiving broadcast signals

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010036739A1 (en) * 2008-09-26 2010-04-01 Telegent Systems, Inc. Devices and methods of digital video and/or audio reception and/or output having error detection and/or concealment circuitry and techniques
KR101670723B1 (ko) * 2011-01-04 2016-11-01 삼성전자주식회사 비디오 및 오디오 통신 시스템에서 가변 길이의 전송 패킷 지원 방법 및 장치
EP2552042B1 (de) * 2011-07-28 2013-03-13 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Demultiplexen eines paketbasierten Transportstroms
WO2015055256A1 (en) * 2013-10-18 2015-04-23 Huawei Technologies Co., Ltd. Transmission and receiving method in a wireless communication system
US9917930B2 (en) * 2015-01-07 2018-03-13 Samsung Electronics Co., Ltd. Transmitting apparatus and receiving apparatus and signal processing method thereof

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006352897A (ja) * 2006-07-07 2006-12-28 Toshiba Corp 通信装置、通信方法、および通信システム
JP2013520036A (ja) * 2010-02-26 2013-05-30 パナソニック株式会社 デジタル放送システムにおける物理レイヤシグナリング
US20150229443A1 (en) * 2014-02-13 2015-08-13 Lg Electronics Inc. Apparatus and method for sending and receiving broadcast signals

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
PHYSICAL LAYER PROTOCOL, 28 September 2015 (2015-09-28)
See also references of EP3422618A4

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019239695A1 (ja) * 2018-06-13 2019-12-19 ソニーセミコンダクタソリューションズ株式会社 復調回路、処理方法、および処理装置
KR20210018994A (ko) * 2018-06-13 2021-02-19 소니 세미컨덕터 솔루션즈 가부시키가이샤 복조 회로, 처리 방법, 및 처리 장치
US11432036B2 (en) 2018-06-13 2022-08-30 Sony Semiconductor Solutions Corporation Demodulation circuit, processing method, and processing device
KR102654958B1 (ko) 2018-06-13 2024-04-05 소니 세미컨덕터 솔루션즈 가부시키가이샤 복조 회로, 처리 방법, 및 처리 장치
JP2020043524A (ja) * 2018-09-13 2020-03-19 株式会社日立国際電気 配信システム
JP7058576B2 (ja) 2018-09-13 2022-04-22 株式会社日立国際電気 配信システム

Also Published As

Publication number Publication date
EP3422618A4 (en) 2019-03-13
JPWO2017145790A1 (ja) 2018-12-20
US20200044774A1 (en) 2020-02-06
EP3422618A1 (en) 2019-01-02

Similar Documents

Publication Publication Date Title
TWI501579B (zh) 使用透過單播系統接收之增量冗餘以在廣播系統中接收資料的接收器與接收方法
US7889707B2 (en) Method and system for unequal error protection with block codes for wireless transmission
KR100913108B1 (ko) 수신 시스템 및 데이터 처리 방법
KR102445458B1 (ko) 송신 장치, 송신 방법, 수신 장치 및 수신 방법
US8406211B2 (en) Forward error correction for broadcast/multicast service
US20070240027A1 (en) Forward Error Correction Decoders
KR100998454B1 (ko) 인 밴드 에러 패턴을 사용한 에러 복원
US20070277209A1 (en) Robust transmission system and method for mobile television applications
KR102386821B1 (ko) 방송 시스템에서 시스템 시간 정보를 송수신하는 기법
KR20090031323A (ko) 디지털 방송 시스템 및 데이터 처리 방법
CN111373759B (zh) 广播信号传输设备、广播信号传输方法、广播信号接收设备及广播信号接收方法
KR102603460B1 (ko) 방송 신호 송신 장치, 방송 신호 송신 방법, 방송 신호 수신 장치 및 방송 수신 신호 방법
WO2017145790A1 (ja) 受信装置、送信装置、及び、データ処理方法
KR102163338B1 (ko) 방송 및 통신 시스템에서 패킷 송수신 장치 및 방법
KR100955814B1 (ko) 순방향 오류 정정을 포함하는 수신기를 동작시키기 위한장치 및 방법
JP3730977B2 (ja) データ伝送方法およびデータ処理方法
WO2021153301A1 (ja) 情報処理装置、情報処理方法、及び、プログラム
JP2018160752A (ja) 送信装置、受信装置及びプログラム
US20040114599A1 (en) Massive packet transmitter in wide area network and transmitting and receiving method thereof
JP2009201117A (ja) データ受信装置及びそのプログラム
WO2017130724A1 (ja) データ処理装置、及び、データ処理方法
CN101938439A (zh) 移动多媒体广播系统中复用数据的传送方法与装置

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2018501567

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2017756231

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2017756231

Country of ref document: EP

Effective date: 20180926

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17756231

Country of ref document: EP

Kind code of ref document: A1