CN107078975B - 发送装置、发送方法、接收装置以及接收方法 - Google Patents

发送装置、发送方法、接收装置以及接收方法 Download PDF

Info

Publication number
CN107078975B
CN107078975B CN201580057149.6A CN201580057149A CN107078975B CN 107078975 B CN107078975 B CN 107078975B CN 201580057149 A CN201580057149 A CN 201580057149A CN 107078975 B CN107078975 B CN 107078975B
Authority
CN
China
Prior art keywords
packet
header
destination
udp
address
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201580057149.6A
Other languages
English (en)
Other versions
CN107078975A (zh
Inventor
拉克伦·布鲁斯·迈克尔
高桥和幸
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
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 Sony Corp filed Critical Sony Corp
Publication of CN107078975A publication Critical patent/CN107078975A/zh
Application granted granted Critical
Publication of CN107078975B publication Critical patent/CN107078975B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23605—Creation or processing of packetized elementary streams [PES]
    • 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]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4343—Extraction or processing of packetized elementary streams [PES]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/633—Control signals issued by server directed to the network components or client
    • H04N21/6332—Control signals issued by server directed to the network components or client directed to client
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Burglar Alarm Systems (AREA)
  • Radar Systems Or Details Thereof (AREA)

Abstract

本技术涉及发送装置、发送方法、接收装置以及接收方法，由此可以有效地广播并快速地处理IP数据包。发送并接收包括IP数据包的传输数据包。传输数据包的报头由类型信息和长度信息组成，类型信息表示IP报头和UDP报头是否被压缩，并且长度信息表示用于发送包括UDP数据包的IP数据包的传输数据包的长度。传输数据包的有效载荷由目的地IP地址和目的地端口号组成，或由与目的地IP地址和目的地端口号相关联的目的地索引以及UDP数据包的有效载荷组成。例如，本技术可应用于广播IP数据包。

Description

发送装置、发送方法、接收装置以及接收方法
技术领域
本技术涉及发送装置、发送方法、接收装置以及接收方法。例如，本技术特别涉及有效地广播IP数据包以确保快速处理的发送装置、发送方法、接收装置以及接收方法。
背景技术
例如，作为下一代地面广播标准之一的高级电视系统委员会(ATSC)3.0确定不使用传输流(TS)数据包，而是使用UDP/IP(即包括UDP数据包的IP数据包)来用于数据发送。未来还期望在除了ATSC 3.0之外的广播系统中使用IP数据包。
附带地，IP数据包包括报头中的各条信息，并且这导致大的开销。因此，作为压缩IP数据包中的报头用于有效发送IP数据包的技术，已经提供了由因特网工程任务组(IETF)指定的健壮报头压缩(RoHC)。
在RoHC中，发送包括报头中的所有信息的IP数据包(下文中也称为完整IP数据包)。关于后续IP数据包中的报头，发送与先前完整IP数据包中的报头内的信息不同的信息。
与RoHC类似，IP数据包中的报头的压缩技术在下文中也称为差分压缩方法，该压缩技术发送完整IP数据包并且然后发送IP数据包(该IP数据包具有包括与完整IP数据包中的报头内的信息不同的信息的报头)。
例如，在高级广播卫星(BS)中，已经指定差分压缩方法作为压缩IP数据包中的报头的技术(非专利文献1)。
引用列表
专利文献
非专利文献1：“ARIB STD-B32 3.0版”，无线工业及商贸联合会
发明内容
本发明要解决的问题
在诸如ATSC 3.0的广播中使用差分压缩方法可能无法有效地广播IP数据包。
也就是说，在接收侧接收完整IP数据包之后，差分压缩方法可以恢复后续的IP数据包。因此，需要在一定程度上频繁地广播完整的IP数据包以在接收侧上恢复IP数据包。这使得难以期望压缩的实质效果。
此外，在接收侧开始接收IP数据包之后，接收侧在第一次接收完整IP数据包之前已经接收的IP数据包不能恢复。在第一次接收完整的IP数据包之后，IP数据包处理变为可能。
因此，接收侧可能难以在差分压缩方法下快速处理IP数据包。
考虑到这种情况，已经提出了本技术以有效地广播IP数据包并确保快速的处理。
问题的解决方案
根据本技术的第一发送装置包括：生成单元，配置为生成传输数据包，所述传输数据包由以下构成：由类型信息和长度信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度；以及由目的地索引和所述UDP数据包中的有效载荷构成的有效载荷，所述目的地索引与所述IP数据包的目的地IP地址和所述UDP数据包的目的地端口号建立对应关系；以及发送单元，配置为发送所述传输数据包。
根据本技术的第一发送方法包括以下步骤：生成传输数据包，所述传输数据包由以下构成：由类型信息和长度信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度；以及由目的地索引和所述UDP数据包中的有效载荷构成的有效载荷，所述目的地索引与所述IP数据包的目的地IP地址和所述UDP数据包的目的地端口号建立对应关系；以及发送所述传输数据包。
在根据本技术的第一发送装置和第一发送方法中，生成并发送传输数据包。传输数据包由报头和有效载荷构成。报头由类型信息和长度信息构成。类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩。长度信息表示用于发送包括UDP数据包的IP数据包的传输数据包的长度。有效载荷由目的地索引和UDP数据包中的有效载荷构成。使得目的地索引对应于IP数据包的目的地IP地址和UDP数据包的目的地端口号。
根据本技术的第一接收装置包括：接收单元，配置为接收传输数据包，所述传输数据包由以下构成：由类型信息和长度信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度；以及由目的地索引和所述UDP数据包中的有效载荷构成的有效载荷，所述目的地索引与所述IP数据包的目的地IP地址和所述UDP数据包的目的地端口号建立对应关系；以及恢复单元，配置为从所述传输数据包恢复所述IP数据包。
根据本技术的第一接收方法包括以下步骤：接收传输数据包，所述传输数据包由以下构成：由类型信息和长度信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度；以及由目的地索引和所述UDP数据包中的有效载荷构成的有效载荷，所述目的地索引与所述IP数据包的目的地IP地址和所述UDP数据包的目的地端口号建立对应关系；以及从所述传输数据包恢复所述IP数据包。
在根据本技术的第一接收装置和第一接收方法中，接收传输数据包并且恢复IP数据包。传输数据包由报头和有效载荷构成。报头由类型信息和长度信息构成。类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩。长度信息表示用于发送包括UDP数据包的IP数据包的传输数据包的长度。有效载荷由目的地索引和UDP数据包中的有效载荷构成。使得目的地索引对应于IP数据包的目的地IP地址和UDP数据包的目的地端口号。
根据本技术的第二发送装置包括：生成单元，配置为生成传输数据包，所述传输数据包由以下构成：由类型信息和长度信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度；以及由所述IP数据包的目的地IP地址、所述UDP数据包的目的地端口号以及所述UDP数据包中的有效载荷构成的有效载荷；以及发送单元，配置为发送所述传输数据包。
根据本技术的第二发送方法包括以下步骤：生成传输数据包，所述传输数据包由以下构成：由类型信息和长度信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度；以及由所述IP数据包的目的地IP地址、所述UDP数据包的目的地端口号以及所述UDP数据包中的有效载荷构成的有效载荷；以及发送所述传输数据包。
在根据本技术的第二发送装置和第二发送方法中，生成并发送传输数据包。传输数据包由报头和有效载荷构成。报头由类型信息和长度信息构成。类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩。长度信息表示用于发送包括UDP数据包的IP数据包的传输数据包的长度。有效载荷由IP数据包的目的地IP地址、UDP数据包的目的地端口号以及UDP数据包中的有效载荷构成。
根据本技术的第二接收装置包括：接收单元，配置为接收传输数据包，所述传输数据包由以下构成：由类型信息和长度信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度；以及由所述IP数据包的目的地IP地址、所述UDP数据包的目的地端口号以及所述UDP数据包中的有效载荷构成的有效载荷；以及恢复单元，配置为从所述传输数据包恢复所述IP数据包。
根据本技术的第二接收方法包括以下步骤：接收传输数据包，所述传输数据包由以下构成：由类型信息和长度信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度；以及由所述IP数据包的目的地IP地址、所述UDP数据包的目的地端口号以及所述UDP数据包中的有效载荷构成的有效载荷；以及从所述传输数据包恢复所述IP数据包。
在根据本技术的第二接收装置和第二接收方法中，接收传输数据包并且恢复IP数据包。传输数据包由报头和有效载荷构成。报头由类型信息和长度信息构成。类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩。长度信息表示用于发送包括UDP数据包的IP数据包的传输数据包的长度。有效载荷由IP数据包的目的地IP地址、UDP数据包的目的地端口号以及UDP数据包中的有效载荷构成。
应当注意，发送装置和接收装置可以是独立的装置，或者可以是构成一个装置的内部块。
本发明的效果
本技术有效地广播IP数据包以确保快速处理。
应当注意，这里描述的效果不必受限制，并且可以是本公开中描述的效果中的任何一个。
附图说明
图1是示出根据应用了本技术的广播系统的一个实施方式的配置的实例的图。
图2是示出通用数据包的格式的实例的图。
图3是示出IP数据包的格式的图。
图4是示出IP报头的格式的图。
图5是示出UDP报头的格式的图。
图6是描述通用报头中的类型信息(Type)的图。
图7是示出其中布置有IP数据包的通用数据包的配置的实例的图。
图8是示出目的地索引的实例的图。
图9是示出在超级压缩模式、压缩模式和非压缩模式下布置在各个通用数据包中的IP数据包内的IP报头和UDP报头(对应于其的部分)的长度的图。
图10是描述生成通用数据包的生成处理的实例的图。
图11是描述生成通用数据包的生成处理的实例的图。
图12是描述生成通用数据包的生成处理的实例的图。
图13是描述对于通用数据包的生成处理的实例的流程图。
图14是描述在超级压缩模式下的处理的实例的流程图。
图15是描述在压缩模式下的处理的实例的流程图。
图16是描述从通用数据包恢复IP数据包的恢复处理的实例的图。
图17是示出恢复为IP报头项中的固定值的项和固定值的实例的图。
图18是描述IP数据包的恢复处理的实例的流程图。
图19是示出根据应用了本技术的计算机的一个实施方式的配置的实例的框图。
具体实施方式
<应用了本技术的广播系统的配置的实例>
图1是示出根据应用了本技术的广播系统的一个实施方式的配置的实例的图。
在图1中，广播系统由发送装置10和接收装置20构成。
例如，发送装置10是符合诸如ATSC 3.0的预定广播标准的发送装置。发送装置10利用包括UDP数据包的IP数据包来发送数据。
也就是说，发送装置10包括生成单元11和发送单元12。
将包括用于广播的实际数据目标的UDP/IP中的IP数据包，即其中布置了包括实际数据的UDP数据包的IP数据包，提供给生成单元11。
生成单元11生成通用数据包(其将稍后描述)作为传输数据包，以发送提供给生成单元11的IP数据包，并将该通用数据包提供给发送单元12。
例如，发送单元12经由作为地波的发送路径30，发送从生成单元11提供的通用数据包。
例如，接收装置20是符合诸如ATSC 3.0的预定广播标准的接收装置。接收装置20接收从发送装置10发送的IP数据包。
也就是说，接收装置20包括接收单元21和恢复单元22。
接收单元21经由发送路径30接收从发送装置10发送的通用数据包，并将该通用数据包提供给恢复单元22。
恢复单元22从来自接收单元21的通用数据包恢复IP数据包，并且输出IP数据包。
应当注意，为了便于说明，图1仅示出一个接收装置20；然而，可以设置多个接收装置20。多个接收装置20可以同时接收由发送装置10发送(广播)的通用数据包。
还可以布置多个发送装置10。例如，多个发送装置10可以各自以不同的频带作为不同的信道发送通用数据包。接收装置20可以在多个发送装置10的各个信道中选择接收通用数据包的信道。
此外，虽然图1采用地波作为发送路径30，但是例如，也可以使用卫星信道和电缆(有线)作为发送路径30。
<通用数据包>
图2是示出通用数据包的格式的实例的图。
通用数据包包括报头(Header)和有效载荷(Payload)。
通用数据包中的有效载荷具有可变长度。例如，包括UDP数据包的IP数据包可以布置在具有可变长度的有效载荷中。
例如，报头配置为具有两个字节(16位)的固定长度。在报头中，例如，从头开始布置三位类型信息(Type)、11位长度信息(Length)、一位Ext以及一位Flg。
例如，类型信息表示布置在有效载荷中的IP数据包内的IP报头和包括在IP数据包中的UDP数据包内的UDP报头是否被压缩。类型信息的细节将稍后描述。
长度信息表示通用数据包的长度(例如字节数)。
由长度信息表示的长度可以是通用数据包自身的长度，即通用数据包中的报头和有效载荷的总长度，或者可以是通用数据包中的有效载荷的长度。在本实施方式中，例如，长度信息表示通用数据包中的有效载荷的长度，作为通用数据包的长度。
由于通用数据包中的报头具有固定长度，因此只要找到通用数据包中的有效载荷的长度，就可以唯一地确定通用数据包自身的长度。
这里，以下将通用数据包中的报头也指定为通用报头，并且将通用数据包中的有效载荷也指定为通用有效载荷。
Ext表示通用报头是常规报头还是扩展报头。
这里，常规报头意味着图2中所示的两字节报头。扩展报头意味着由三个字节的固定长度构成的报头，其中在常规报头之后添加一个字节。
如上所述，由于长度信息是11位，所以长度信息可以表示0到2047(＝211-1)字节的范围内的值作为通用有效载荷的长度。然而，11位长度信息不能表示具有2048字节或更多的通用有效载荷的长度。
因此，在具有2047字节或更少的数据布置在通用有效载荷中的情况下，常规报头用作通用报头。在具有2048字节或更多的数据布置在通用有效载荷中的情况下，扩展报头用作通用报头。
如上所述，扩展报头是在常规报头之后添加一个字节的报头。添加的一个字节也可以称为添加字节。扩展报头通过添加的字节的一部分或全部来表示通用数据包的长度信息和(有效载荷的)长度。
例如，伴随通用报头作为常规报头，Ext设为0。例如，伴随通用报头作为扩展报头，Ext设为1。
应当注意，当在以太网(注册商标)帧中发送IP数据包时，可以布置在一条以太网(注册商标)帧中的IP数据包的最大长度限制为近似1500字节，这是以太网(注册商标)帧的最大长度。鉴于此，假设IP数据包不超过2047字节，这通常可以由11位长度信息表示。
当布置在有效载荷中的IP数据包内的IP报头和包括在IP数据包中的UDP数据包内的UDP报头被压缩时，Flg用作表示IP报头和UDP报头的压缩种类的种类信息。种类信息的细节将稍后描述。
这里，可以不提供Ext和Flg中的一个或两个而配置通用报头。在不提供Ext和Flg的情况下的通用报头的配置允许将类型信息和长度信息的大小增加所述量。
图3是示出包括UDP数据包的IP数据包的格式的图。
例如，IP数据包包括布置在具有可变长度的有效载荷中的20字节IP报头(IPHeader)和UDP数据包。
UDP数据包包括八字节UDP报头(UDP Header)和具有可变长度的有效载荷。实际数据布置在UDP数据包中的有效载荷内。
如图3所示，在如上所述的IP数据包没有改变地布置在通用有效载荷中的情况下，出现总共28字节，20字节IP报头和八字节UDP报头的开销。
图4是示出IPv4中的IP报头的格式的图。
IP报头包括版本(Version)、IHL、DSCP、ECN、IP数据包长度(Total Length)、标识、标志、片段偏移、存活时间、协议、校验和(Header Checksum)、发送源IP地址(Source IPAddress)、目的地IP地址(Destination IP Address)以及所需选项。
这里，由于通常不使用选项(Options)，所以本实施方式不使用选项(Options)。
版本表示IP版本是IPv4(IP version4)还是IPv6(IP version6)。为了便于说明，本实施方式假设IP版本为IPv4。
IHL表示IP报头的长度。通过将IP报头的长度除以4得到的值设为IHL。当在IP报头中不存在选项(Options)时，IP报头的长度为20字节，并且因此将5(＝20/4)设为IHL。
DSCP表示IP数据包的优先级。ECN用于IP数据包的拥塞控制。
IP数据包长度(Total Length)表示IP数据包的总长度。
标识、标志和片段偏移是关于IP数据包的划分的信息。应当注意，假设布置在通用数据包中的IP数据包没有划分。也就是说，在通用有效载荷中，一条(或多条)IP数据包没有划分地布置。
存活时间(TTL)表示IP数据包的生存时间，也就是说，例如IP数据包可通过的路由器的数量。
协议表示包括在IP数据包中的有效载荷内的协议。在本实施方式中，IP数据包中的有效载荷包括UDP数据包。由于UDP由17表示，因此将17设为协议。
校验和(Header Checksum)用于检测IP报头中的错误。通过以16位为单元来分割IP报头、获得各个16位单元的“1”的补码的和、并且运算“1”的补码的和来计算IP的校验和。
IP数据包的发送源的IP地址设为发送源IP地址(Source IP Address)。
IP数据包的目的地的IP地址设为目的地IP地址(Destination IP Address)。
为了在通用数据包中广播IP数据包，在图4中的IP报头项之中，接收装置20中所需的用于恢复具有图4中格式的IP报头(以下也称为正确的IP报头)的必需项是IP数据包长度(Total Length)和目的地IP地址(Destination IP Address)。
也就是说，在IP报头项之中，对于除了作为接收装置20的必需项的IP数据包长度和目的地IP地址之外的项，没有要由接收装置20处理的问题的正确的IP报头可以通过使用预定的固定值等来恢复。
应当注意，在接收装置20中，IP报头项之中的除了IP数据包长度和目的地IP地址之外的发送源IP地址(Source IP Address)可以设为固定值，并且还可以从上层协议获得。
也就是说，在比作为UDP的层的传输层更高的上层中，发送装置10发送关于以诸如ATSC 3.0的广播标准进行广播的广播站的信息。因此，可以从由上层所获得的关于广播站的信息中获得发送源IP地址。应当注意，如上所述，发送源IP地址可以是固定值。
图5是示出UDP报头的格式的图。
UDP报头包括发送源端口号(Source port)、目的地端口号(Destination port)、UDP数据包长度(Length)以及校验和(Checksum)。
用于UDP数据包的发送源的端口号设为发送源端口号(Source port)。
UDP数据包的目的地的端口号设为目的地端口号(Destination port)。
UDP数据包长度(Length)表示UDP数据包的总长度。
校验和(Checksum)用于检测UDP数据包中的错误。使用UDP数据包中的UDP伪报头、UDP报头和有效载荷中的“1”的补码的运算来计算UDP的校验和。应当注意，UDP伪报头是仅用于计算UDP的校验和的虚数。
为了在通用数据包中广播包括UDP数据包的IP数据包，在图5中的UDP报头项之中，接收装置20中所需的用于恢复具有图5中格式的UDP报头(以下也称为正确的UDP报头)的必需项是目的地端口号(Destination port)和UDP数据包长度(Length)。
也就是说，在UDP报头项之中，对于除了作为接收装置20的必需项的目的地端口号和UDP数据包长度之外的项(发送源端口号和校验和)，没有要由接收装置20处理的问题的正确的UDP报头可以通过使用预定的固定值等来恢复。
应当注意，在接收装置20中，UDP报头项之中的除了UDP数据包长度和目的地端口号之外的发送源端口号(Source port)可以设为固定值，并且还可以从关于上层的协议获得。
也就是说，如图4所示，在上层中的发送装置10发送关于以诸如ATSC3.0的广播标准进行广播的广播站的信息。因此，可以从由上层所获得的关于广播站的信息中获得发送源端口号。应当注意，如上所述，发送源端口号可以是固定值。
这里，如图4所示，IP报头中的必需项是IP数据包长度和目的地IP地址。此外，如图5所示，UDP报头中的必需项是UDP数据包长度和目的地端口号。
因此，为了在通用数据包中广播IP数据包，IP报头可以压缩为仅包括关于IP数据包长度和目的地IP地址的信息的压缩的IP报头。UDP报头可以压缩为仅包括关于UDP数据包长度和目的地端口号的信息的压缩的UDP报头。
此外，当关于目的地IP地址和目的地端口号的信息设为具有固定长度时，由于IP报头和UDP报头各自分别具有20字节和8字节的固定长度，因此IP数据包长度和UDP数据包长度可以从通用报头(图2)中的长度信息获得。
如上所述，IP报头和UDP报头可以压缩为关于目的地IP地址和目的地端口号的信息。即使执行这样的压缩，也可以恢复没有要由接收装置20处理的问题的正确的IP报头和UDP报头。
因此，为了生成其中布置了IP数据包的通用数据包，在必要时发送装置10中的生成单元11将包括在IP数据包中的IP报头和UDP报头压缩为关于目的地IP地址和目的地端口号的信息。
图6是描述图2所示的通用报头中的类型信息(Type)的图。
如图2所示，类型信息表示压缩的IP报头和UDP报头的存在/不存在，即布置在通用有效载荷中的IP数据包内的IP报头和包括在IP数据包中的UDP数据包内的UDP报头是否被压缩。
类型信息表示布置在通用有效载荷中的IP数据包中的压缩的IP报头和UDP报头、以及还有关于布置在通用有效载荷中的数据的类型的信息的存在/不存在。
也就是说，在通用有效载荷中布置有用于填充(Padding)的数据的情况下，类型信息设为000b(b表示紧接在b之前的值是二进制数)。
此外，在通用有效载荷中布置有用于信令(Signaling)的数据的情况下，类型信息设为001b。
此外，在通用有效载荷中布置IPv4中的IP数据包(其中IP报头和UDP报头都没有压缩)的情况下，即IP数据包没有改变地布置在通用有效载荷中，类型信息设为010。
另外，在通用有效载荷中布置有具有压缩的IP报头和UDP报头的IPv4中的IP数据包的情况下，类型信息设为011。
此外，在通用有效载荷中布置有TS数据包的情况下，类型信息设为100。
在图6中，具有其他值的类型信息，即具有101、110和111的类型信息是未定义的(保留的)。
应当注意，例如，由于在通用有效载荷中布置具有未压缩的IP报头和UDP报头的IPv6中的IP数据包的事实以及在通用有效载荷中布置具有压缩的IP报头和UDP报头的IPv6中的IP数据包的事实，可以分配未定义的类型信息。
在这种情况下，可以通过类型信息来识别布置在通用有效载荷中的IP数据包是IPv4中的IP数据包还是IPv6中的IP数据包，从而确保IP报头(图4)的版本(Version)的恢复。
应当注意，如上所述，为了便于说明，本实施方式不使用IPv6中的IP数据包，而是使用IPv4中的IP数据包。
图7是示出其中布置有IP数据包的通用数据包的配置的实例的图。
例如，发送装置10(图1)中的生成单元11可以生成三种模式的通用数据包作为包括IP数据包的通用数据包。
三种模式包括超级压缩模式(Super compressed mode)、压缩模式(具有IP和UDP地址的压缩模式)以及非压缩模式(Non compressed mode)。
超级压缩模式和压缩模式将在布置于通用有效载荷中的IP数据包内包括的IP报头以及(在包括于IP数据包中的UDP数据包内的)UDP报头，压缩为关于目的地IP地址和目的地端口号的信息。
应当注意，压缩模式将IP报头和UDP报头压缩为目的地IP地址和目的地端口号本身。同时，超级压缩模式将IP报头和UDP报头压缩为表示目的地IP地址和目的地端口号的目的地索引以及其大小小于目的地IP地址和目的地端口号的总大小的目的地索引。
另外，非压缩模式不压缩在通用有效载荷中布置的IP数据包内包括的IP报头和UDP报头。
图7的A示出在超级压缩模式下的通用数据包的实例。
超级压缩模式下的通用数据包通过将IP数据包中包括的UDP数据包内的有效载荷中所布置的类型信息、长度信息、Ext、Flg、目的地索引以及实际数据按此顺序布置而配置。
在超级压缩模式下，通用报头中的类型信息设为011，其表示在通用有效载荷中的具有压缩的IP报头和UDP报头的IPv4中的IP数据包的布置。
另外，通用报头中的长度信息设为通用有效载荷的长度。
此外，通用报头中的Ext根据通用有效载荷的长度是否为2047字节或更小(即通用报头是常规报头还是扩展报头)而设为0或1。在图7的A中，由于通用有效载荷的长度为2047字节或更小，并且因此通用报头是常规报头，Ext设为0。
此外，通用报头中的Flg设为用于通用有效载荷中的IP数据包内的IP报头和UDP报头的压缩的种类信息。
种类信息是表示IP报头和UDP报头是否以任何种类(模式)的超级压缩模式或压缩模式压缩的信息。本实施方式分别为超级压缩模式和压缩模式分配0和1。
因此，图7的A中的Flg设为0，其表示超级压缩模式。
在通用有效载荷中，布置有作为压缩IP数据包中的IP报头和UDP报头的压缩结果的目的地索引。在目的地索引之后，布置IP数据包中包括的UDP数据包内的有效载荷中所布置的实际数据。
目的地索引具有小于目的地IP地址和目的地端口号的总大小的固定大小。
也就是说，目的地IP地址(dst IP Address)具有四个字节的大小，目的地端口号(dst port number)具有两个字节的大小，并且这些的总大小是六个字节。同时，在图7的A中，目的地索引具有一个字节的大小，其小于六个字节。
如上所述，超级压缩模式将IP报头和UDP报头仅压缩为具有一个字节的目的地索引。这确保有效地广播通用数据包，并且最终有效地广播IP数据包。
应当注意，稍后将描述目的地索引的细节。
另外，在图7(与稍后描述的图类似)中，布置在通用有效载荷中并且在UDP数据包中的实际数据部分内所描述的“可变长度”表示具有可变长度的实际数据。
在通用数据包中，UDP数据包中的除了实际数据之外的部分具有固定长度。
图7的B示出在压缩模式下的通用数据包的实例。
在压缩模式下的通用数据包是通过将IP数据包中包括的UDP数据包内的有效载荷中所布置的类型信息、长度信息、Ext、Flg、目的地IP地址、目的地端口号以及实际数据按此顺序布置而配置。
在压缩模式下，与超级压缩模式类似，通用报头中的类型信息设为011，其表示在通用有效载荷中的具有压缩的IP报头和UDP报头的IPv4中的IP数据包的布置。
另外，与超级压缩模式类似，通用报头中的长度信息设为通用有效载荷的长度。
此外，与超级压缩模式类似，通用报头中的Ext根据通用有效载荷的长度是否为2047字节或更小而设为0或1。在图7的B中，由于通用有效载荷的长度为2047字节或更小，并且因此Ext设为0。
此外，通用报头中的Flg设为用于通用有效载荷中的IP数据包内的IP报头和UDP报头的压缩的种类信息。图7的B中的Flg设为表示压缩模式的1。
在通用有效载荷中，布置作为压缩IP数据包中的IP报头和UDP报头的压缩结果的目的地IP地址和目的地端口号。在目的地IP地址和目的地端口号之后，布置IP数据包中包括的UDP数据包内的有效载荷中所布置的实际数据。
如上所述，压缩模式仅将IP报头和UDP报头压缩为目的地IP地址和目的地端口号。这确保有效地广播通用数据包，并且最终有效地广播IP数据包。
图7的C示出非压缩模式下的通用数据包的实例。
在非压缩模式下的通用数据包是通过将IP数据包中包括的UDP数据包内的有效载荷中所布置的类型信息、长度信息、Ext、Flg、IP报头、UDP报头以及实际数据按此顺序布置而配置。
在非压缩模式下，通用报头中的类型信息设为010，其表示在通用有效载荷中的具有未压缩的IP报头和UDP报头的IPv4中的IP数据包的布置。
另外，与超级压缩模式和压缩模式类似，通用报头中的长度信息设为通用有效载荷的长度。
此外，与超级压缩模式和压缩模式类似，通用报头中的Ext根据通用有效载荷的长度是否为2047字节或更小而设为0或1。在图7的C中，由于通用有效载荷的长度为2047字节或更小，并且因此Ext设为0。
由于通用报头中的Flg设为用于压缩通用有效载荷中的IP数据包内的IP报头和UDP报头的种类信息，所以Flg不在非压缩模式下起作用。在图7的C中Flg设为0。
包括UDP数据包的IP数据包没有改变地布置在通用有效载荷中。因此，在通用有效载荷中，布置有IP报头和UDP报头，并且随后布置有在UDP数据包中的有效载荷内所布置的实际数据。
应当注意，可以为类型信息分配容纳由Flg所表示的种类信息的值。
也就是说，例如，在上述图6中，根据具有布置在通用有效载荷中的压缩的IP报头和UDP报头的IPv4中的IP数据包，为类型信息分配011。同时，例如，可以根据IP报头和UDP报头被压缩为目的地索引的压缩，为类型信息分配011。可以根据IP报头和UDP报头被压缩为目的地IP地址和目的地端口号的压缩，为类型信息分配另一个值。
在这种情况下，Flg可以省去或用于表示除了种类信息之外的信息。
图8是示出目的地索引的实例的图。
对应于目的地IP地址和目的地端口号的集合形成目的地索引。使得目的地索引对应于目的地IP地址和目的地端口号的集合的表称为索引表。
图8示出索引表的实例。
在本实施方式中，由于目的地索引的大小是一个字节(8位)，所以存在目的地索引的256(＝28)个模式。
在索引表中，对应于目的地IP地址和目的地端口号的集合而形成目的地索引的相应256个模式。
这里，在图8的索引表中，除了对应于目的地索引而形成的目的地IP地址和目的地端口号的集合之外，还对应地形成发送源IP地址和发送源端口号的集合。
发送装置10中的生成单元11存储图8中的索引表。然后，生成单元11从索引表中搜索对应于目的地IP地址、目的地端口号、发送源IP地址以及发送源端口号而形成的目的地索引，以将IP报头和UDP报头压缩成目的地索引，其中目的地IP地址、目的地端口号、发送源IP地址以及发送源端口号设置成布置在通用数据包中的IP数据包内的IP报头和UDP报头。
类似于生成单元11，接收装置20中的恢复单元22也存储图8中的索引表。然后，恢复单元22搜索对应于目的地索引而形成目的地IP地址、目的地端口号、发送源IP地址以及发送源端口号。恢复单元22将IP报头和UDP报头的对应项恢复为目的地IP地址、目的地端口号、发送源IP地址以及发送源端口号。
应当注意，在图8的索引表中，除了目的地IP地址和目的地端口号的集合之外，还对应于目的地索引形成发送源IP地址和发送源端口号的集合。然而，可以仅使得目的地IP地址和目的地端口号的集合对应于目的地索引。在这种情况下，接收装置20中的恢复单元22可以将发送源IP地址和发送源端口号恢复为固定值，或者从关于上层的协议中获得值。由于可以通过上层中的信令获得用于识别广播站的信息，因此不需要参考发送源IP地址和发送源端口号用于广播。因此，将固定值设为发送源IP地址和发送源端口号不会特别引起问题。
这里，ATSC M/H A/153第3部分规定使用10.0.0.0-10.255.255.255、172.16.0.0-172.31.255.255、192.168.0.0-192.168.255.255作为发送源IP地址。图8中的索引表符合ATSC M/H A/153第3部分，并且发送源IP地址是192.168.0.0。应当注意，在图8的索引表中，使得相同的发送源IP地址192.168.0.0对应于目的地索引的所有256个模式。同时，可以形成对应于不同的目的地索引的不同的发送源IP地址。
此外，在图8的索引表中，目的地IP地址是用于IP多播的从224开始的IP地址。
此外，因特网号码分配机构(IANA)不在60000中特别地分配端口号。因此，在图8的索引表中，没有由IANA分配端口号的60000中的端口号原则上用于发送源端口号和目的地端口号。应当注意，在图8的索引表中，尽管使得相同的发送源端口号60000对应于目的地索引的所有256个模式，但是可以使得不同的发送源端口号对应于不同的目的地索引。
另外，在IANA中，注册了由ATSC服务使用的用于网络时间协议版本4(NTPv4)和服务信令信道的IP地址和端口号。也就是说，IANA注册224.0.1.1和123作为由ATSC服务使用的用于NTPv4的相应IP地址和端口号。此外，IANA注册224.0.23.60和4937作为由ATSC服务使用的用于服务信令信道的相应IP地址和端口号。
因此，在图8的索引表中，224.0.1.1和123分别注册为用于NTPv4的IP地址和端口号，并且224.0.23.60和4937分别注册为用于服务信令信道的IP地址和端口号。应当注意，在图8的索引表中，使得目的地索引0x00(0x表示紧随0x之后的值是十六进制数)对应于224.0.1.1和123的集合，224.0.1.1和123是NTPv4中的IP地址和端口号。此外，使得0x01的目的地索引对应于224.0.23.60和4937的集合，224.0.23.60和4937是服务信令信道中的IP地址和端口号。
如上所述，图1的广播系统中的生成单元11和恢复单元22存储图8中的索引表。
然后，在超级压缩模式下，生成单元11基于图8中的索引表将布置在通用数据包中的IP数据包内的IP报头和UDP报头压缩为目的地索引，使得该目的地索引对应于包括在IP报头和UDP报头中的目的地IP地址和目的地端口号的集合。
另一方面，恢复单元22基于图8中的索引表从目的地索引中恢复对应于该目的地索引而形成的目的地IP地址和目的地端口号。
应当注意，在图8的索引表中，除了目的地IP地址和目的地端口号的集合之外，还使得发送源IP地址和发送源端口号的集合对应于目的地索引；因此，除了目的地IP地址和目的地端口号之外，还可以从目的地索引恢复发送源IP地址和发送源端口号。
应当注意，在图8的索引表中，使得发送源IP地址和发送源端口号的相同集合对应于目的地索引的所有256个模式。在这种情况下，没有使得发送源IP地址和发送源端口号对应于目的地索引，而是可以将其预定为固定值。
另外，本实施方式采用一个字节作为目的地索引；然而，作为目的地索引的大小，可以采用小于一个字节和超过一个字节的大小。
当采用小于一个字节的大小作为目的地索引的大小时，尽管与目的地索引相对应的目的地IP地址和目的地端口号的集合的数量减少，但是通用数据包的大小可以减小。
尽管使用超过一个字节的大小作为目的地索引的大小增加了通用数据包的大小，但是可以增加对应于目的地索引的目的地IP地址和目的地端口号的集合的数量。
例如，目的地索引的大小可以通过作为目的地IP地址和目的地端口号的集合所需的自由度的程度来确定。
此外，目的地索引可以包括一位或更多位的表选择位。在这种情况下，以可由表选择位表示的数量来准备多个索引表。可以对应于目的地索引中的表选择位选择所使用的索引表。此外，在对应于表选择位所选择的索引表中，目的地IP地址和目的地端口号的集合可对应于目的地索引中的剩余位。
此外，在必要时发送装置10可以更新索引表。发送装置10可以在更新后向接收装置20广播索引表，以使接收装置20存储索引表。此外，例如，在图1中的广播系统符合的广播标准之下，为索引表指定用于生成索引表的生成规则。发送装置10和接收装置20可以根据生成规则来生成索引表。
应当注意，作为用于包括IP数据包的通用数据包的模式，除了超级压缩模式、压缩模式和非压缩模式之外，还可以提供超压缩模式(ultra-compressed mode)。
超压缩模式使用预定的固定值作为目的地IP地址和目的地端口号。通用有效载荷根本不包括关于IP报头和UDP报头的信息。
因此，虽然超压缩模式失去了用于目的地IP地址和目的地端口号的自由度，但是超压缩模式可以比超级压缩模式减小通用数据包的大小并且进一步有效地广播通用数据包，最终有效地广播IP数据包。
图9是示出在相应的超级压缩模式、压缩模式和非压缩模式下布置在通用数据包中的IP数据包内的IP报头和UDP报头(对应于其的部分)的长度的图。
在超级压缩模式(Super compressed mode)下的通用数据包中，IP数据包中的IP报头和UDP报头压缩为目的地索引。因此，IP数据包中对应于IP报头和UDP报头的部分的长度(报头长度)是一个字节，其是目的地索引的大小。
由于IP报头和UDP报头的总大小是28(＝20+8)字节，所以与IP报头和UDP报头都不压缩的情况相比，超级压缩模式可以实现27(＝28-1)字节大小的压缩(减小)。
在压缩模式(具有IP地址和UDP地址的压缩模式)下的通用数据包中，IP数据包中的IP报头和UDP报头压缩为目的地IP地址和目的地端口号。因此，IP数据包中对应于IP报头和UDP报头的部分的长度(报头长度)是6(＝4+2)字节，其是目的地IP地址和目的地端口号的总大小。
由于IP报头和UDP报头的总大小是28字节，所以与IP报头和UDP报头都不压缩的情况相比，压缩模式可以实现22(＝28-6)字节大小的压缩。
在非压缩模式(Non compressed mode)下的通用数据包中，IP数据包中的IP报头和UDP报头的长度(报头长度)保持为28字节。也就是说，非压缩模式不压缩的IP报头和UDP报头(实现0字节大小的压缩)。
如上所述，超级压缩模式和压缩模式可以实现超过20字节的压缩的效果。另外，超级压缩模式带来IP报头和UDP报头的压缩比压缩模式下的压缩大的效果。
例如，在ATSC 3.0中的物理层的平均发送速率为近似40Mbps。同时，利用超级压缩模式和压缩模式，可以节省近似40Mbps的1％(即近似400kbps)的发送容量。在通过超级压缩模式节省近似400kbps的发送容量的情况下，可以通过近似四个信道单独地广播具有近似100kbps的音频数据。
<通过生成单元11进行的通用数据包的生成处理>
下面参考图10、图11和图12描述通过生成单元11生成通用数据包的生成处理的实例。
图10示出在超级压缩模式下生成具有2047字节或更小的通用有效载荷的通用数据包的生成处理的实例。
在步骤S11，生成单元11从IP数据包中的IP报头识别目的地IP地址(DestinationIP Address)。此外，生成单元11从IP数据包中的UDP报头识别UDP数据包长度(Length)和目的地端口号(Destination port)。
在步骤S12，生成单元11生成通用报头。
这里，在超级压缩模式下，生成单元11将通用报头中的类型信息设为011，其表示IP报头和UDP报头的压缩。
另外，生成单元11从自UDP报头识别的UDP数据包长度中减去作为UDP报头的长度(大小)的八个字节，以便获得一个值，该值通过将减法得到的值与目的地索引的一个字节相加而得到，作为在超级压缩模式下的通用有效载荷的长度。然后，生成单元11将通用报头中的长度信息设为从UDP数据包长度获得的在超级压缩模式下的通用有效载荷的长度。
此外，在图10中，通用有效载荷是2047字节或更小；因此，常规报头用作常规报头和扩展报头中的通用报头。因此，生成单元11将通用报头中的Ext设为0，这表示通用报头是常规报头。
此外，生成单元11将通用报头中的Flg设为表示超级压缩模式的0。
应当注意，在步骤S12，可以从自UDP报头识别的UDP数据包长度获得在超级压缩模式下的通用有效载荷的长度。此外，可以从自IP报头识别的IP数据包长度获得通用有效载荷的长度。
也就是说，可以通过从IP数据包长度中减去作为IP报头和UDP报头的总大小的28(＝20+8)字节并且将目的地索引的一个字节与所述减法得的值相加，来获得在超级压缩模式下的通用有效载荷的长度。
在步骤S13，生成单元11参考索引表(图8)并搜索与从IP报头识别的目的地IP地址和从UDP报头识别的目的地端口号的集合相对应的目的地索引。然后，生成单元11将目的地索引作为通用有效载荷添加至在步骤S12生成的通用报头。
在步骤S14，生成单元11将包括在IP数据包中的UDP数据包内的有效载荷中布置的实际数据布置为紧随目的地索引之后的通用有效载荷。这在超级压缩模式下完成通用数据包。
图11示出生成具有大于2047字节的通用有效载荷的超级压缩模式下的通用数据包的生成处理的实例。
在步骤S21，类似于图10中的步骤S11，生成单元11从IP数据包中的IP报头识别目的地IP地址(Destination IP Address)。生成单元11从IP数据包中的UDP报头识别UDP数据包长度(Length)和目的地端口号(Destination port)。
在步骤S22，生成单元11生成通用报头。
这里，在超级压缩模式下，生成单元11将通用报头中的类型信息设为011，其表示IP报头和UDP报头的压缩。
另外，类似于图10中的情况，生成单元11从UDP数据包长度或IP数据包长度获得超级压缩模式下的通用有效载荷的长度。然后，生成单元11根据从UDP数据包长度或IP数据包长度获得的超级压缩模式下的通用有效载荷的长度，来设置通用报头中的长度信息。稍后将描述长度信息的设置的细节。
此外，在图11中，通用有效载荷大于2047字节；因此，扩展报头用作常规报头和扩展报头之中的通用报头。因此，生成单元11将通用报头中的Ext设为1，其表示通用报头是扩展报头。
此外，生成单元11将通用报头中的Flg设为表示超级压缩模式的0。
此外，生成单元11在Flg之后添加一个字节的添加字节，以将通用报头扩展为扩展报头。
在图11中，由于通用有效载荷大于2047字节，通用有效载荷的长度不能仅设为11位长度信息。在通用有效载荷大于2047字节的情况下，通用有效载荷的长度设为划分成11位长度信息以及一部分或所有添加字节。
也就是说，在图11中，一个字节的添加字节中的五位分配用于扩展的长度信息(Ext.Length)，并且剩余的三位变为未定义(Rsd)(无关)。
大于2047字节的通用有效载荷的长度，即由12位或更多表示的通用有效载荷的长度划分为低11位和剩余的一位或更多的高位。然后，用于通用有效载荷的长度的低11位(LSB)设为11位长度信息，并且剩余的高位(MSB)设为用于添加字节的扩展的长度信息。
应当注意，IP数据包的最大长度是65，535字节，并且可以由16位表示。考虑到IP数据包长度包括IP报头和UDP报头(28字节)的总大小，在超级压缩模式(与压缩模式类似)下，通用有效载荷的长度可以由16位表示，其是关于任何IP数据包的11位长度信息和用于扩展的5位长度信息的总和。
在步骤S23，类似于图10中的情况，生成单元11参考索引表(图8)，并搜索与从IP报头识别的目的地IP地址和从UDP报头识别的目的地端口号对应的目的地索引。然后，生成单元11将目的地索引作为通用有效载荷添加至在步骤S22生成的通用报头(扩展报头)。
在步骤S24，类似于图10中的情况，生成单元11将IP数据包中包括的UDP数据包内的有效载荷中布置的实际数据布置为紧随目的地索引之后的通用有效载荷。这在超级压缩模式下完成通用数据包。
图12示出生成具有2047字节或更小的通用有效载荷的压缩模式下的通用数据包的生成处理的实例。
在步骤S31，类似于图10中的步骤S11，生成单元11从IP数据包中的IP报头识别目的地IP地址(Destination IP Address)。生成单元11从IP数据包中的UDP报头识别UDP数据包长度(Length)和目的地端口号(Destination port)。
在步骤S32，生成单元11生成通用报头。
这里，在压缩模式下，类似于图10中的超级压缩模式，生成单元11将通用报头中的类型信息设为011，其表示IP报头和UDP报头的压缩。
另外，生成单元11从自UDP报头识别的UDP数据包长度中减去作为UDP报头的长度(大小)的8个字节，以获得一个值，该值通过将IP地址的四个字节和目的地端口号的两个字节与所述减法得到的值相加而得到，作为压缩模式下的通用有效载荷的长度。然后，生成单元11将通用报头中的长度信息设为从UDP数据包长度获得的超级压缩模式下的通用有效载荷的长度。
此外，在图12中，通用有效载荷是2047字节或更少；因此，常规报头用作常规报头和扩展报头之中的通用报头。因此，生成单元11将通用报头中的Ext设为0，这表示通用报头是常规报头。
此外，生成单元11将通用报头中的Flg设为表示压缩模式的1。
应当注意，在步骤S32，可以从自UDP报头识别的UDP数据包长度获得压缩模式下的通用有效载荷的长度。此外，通用有效载荷的长度可以从自IP报头识别的IP数据包长度获得。
也就是说，通过从IP数据包长度中减去作为IP报头和UDP报头的总大小的28(＝20+8)字节，并且将目的地IP地址的四个字节和目的地端口号的两个字节与减法所得到的值相加，可以获得压缩模式下的通用有效载荷的长度。
在步骤S33，生成单元11将从IP报头识别的目的地IP地址和从UDP报头识别的目的地端口号添加至在步骤S32生成的通用报头，作为通用有效载荷。
在步骤S34，生成单元11将IP数据包中包括的UDP数据包内的有效载荷中布置的实际数据布置为紧随目的地IP地址和目的地端口号之后的通用有效载荷。这在压缩模式下完成通用数据包。
应当注意，为了在压缩模式下生成具有大于2047字节的通用有效载荷的通用数据包，如图11所示，与图12中的情况不同在于，一点是Ext设为1，一点是扩展报头用作通用报头，以及一点是通用有效载荷的长度设置成划分为11位长度信息和添加字节。
图13是描述通过生成单元11进行的通用数据包的生成处理的实例的流程图。
在步骤S41，生成单元11等待向其自身提供IP数据包，并且获得向其自身提供的一条IP数据包(包括UDP数据包的IP数据包)作为发送目标IP数据包。处理进行到步骤S42。
在步骤S42，生成单元11从发送目标IP数据包中的IP报头获得目的地IP地址，并且从发送目标IP数据包中的UDP报头获得目的地端口号。处理进行到步骤S43。
在步骤S43，生成单元11确定与发送目标IP数据包中的目的地IP地址和目的地端口号的集合相对应的目的地索引是否存在于索引表(图8)中。
在步骤S43，当确定存在与发送目标IP数据包中的目的地IP地址和目的地端口号的集合相对应的目的地索引时，即当发送目标IP数据包中的目的地IP地址和目的地端口号的集合注册在索引表中时，处理进行到步骤S44。
在步骤S44，生成单元11获得与索引表中的发送目标IP数据包内的目的地IP地址和目的地端口号的集合相对应的目的地索引。处理进行到步骤S45。
在步骤S45，生成单元11执行处理以在超级压缩模式下生成通用数据包。处理返回到步骤S41。
另外，在步骤S43中，当确定不存在与发送目标IP数据包中的目的地IP地址和目的地端口号的集合相对应的目的地索引时，即当发送目标IP数据包中的目的地IP地址和目的地端口号的集合没有注册在索引表中时，处理进行到步骤S46。
在步骤S46，生成单元11执行处理以在压缩模式下生成通用数据包。处理返回到步骤S41。
生成单元11将在步骤S45或S46生成的通用数据包提供并发送到发送单元12。
应当注意，除了如图8所示的索引表中的目的地IP地址和目的地端口号之外，在目的地索引也对应于发送源IP地址和发送源端口号的情况下，可以在步骤S43确定是否存在这样的目的地索引。
也就是说，在步骤S43，可以确定是否存在与目标IP数据包中的目的地IP地址、目的地端口号、发送源IP地址以及发送源端口号相对应的目的地索引。
然后，在存在与目标IP数据包中的目的地IP地址、目的地端口号、发送源IP地址以及发送源端口号相对应的目的地索引的情况下，可以在超级压缩模式(步骤S45)下执行处理。在不存在这样的目的地索引的情况下，可以执行压缩模式(步骤S46)下的处理。
图14是描述在图13的步骤S45执行的超级压缩模式下的处理的实例的流程图。
在步骤S51，生成单元11将通用报头中的类型信息设为011，其表示IP报头和UDP报头的压缩。此外，生成单元11将通用报头中的Flg设为表示超级压缩模式的0。处理从步骤S51进行到步骤S52。
在步骤S52，生成单元11从发送目标IP数据包中的UDP报头或IP报头获得UDP数据包长度或IP数据包长度。此外，如图10和图11所示，生成单元11从发送目标IP数据包中的UDP数据包长度或IP数据包长度获得超级压缩模式下的通用有效载荷的长度。处理从步骤S52进行到步骤S53。
在步骤S53，生成单元11确定在步骤S52获得的超级压缩模式下的通用有效载荷的长度是否为2047字节或更小。
在步骤S53，当确定通用有效载荷的长度是2047字节或更小时，处理进行到步骤S54。生成单元11将通用报头中的Ext设为0，这表示通用报头是常规报头。处理进行到步骤S55。
在步骤S55，生成单元11将在步骤S52获得的超级压缩模式下的通用有效载荷的长度设为通用报头中的长度信息。处理进行到步骤S56。
在步骤S56，在通用报头之后，生成单元11立即布置(添加)目的地索引作为通用有效载荷。处理进行到步骤S57。
在步骤S57，生成单元11将发送目标IP数据包中包括的UDP数据包内的有效载荷中布置的实际数据布置为紧随目的地索引之后的通用有效载荷。这在超级压缩模式下完成通用数据包。
然后，生成单元11将超级压缩模式下的通用数据包提供给发送单元12，以在超级压缩模式下终止处理。
另一方面，在步骤S53，当确定通用有效载荷的长度不是2047字节或更小时，处理进行到步骤S58。生成单元11将通用报头中的Ext设为1，其表示通用报头是扩展报头。处理进行到步骤S59。
在步骤S59，生成单元11在常规报头中的Flg之后添加一个字节的添加字节，以将通用报头扩展为扩展报头。此外，生成单元11将添加的字节中的五位设为用于扩展的长度信息(Ext.Length)，通用有效载荷的长度的低11位设为11位长度信息(Length)，并且剩余的高位设为用于添加字节的扩展的长度信息(Ext.Length)。
之后，处理从步骤S56进行到步骤S59。在此之后，在步骤S56和S57，生成单元11执行上述处理以在超级压缩模式下完成通用数据包，并将通用数据包提供给发送单元12。
图15是描述在图13的步骤S46执行的压缩模式下的处理的实例的流程图。
在步骤S71，生成单元11将通用报头中的类型信息设为011，其表示IP报头和UDP报头的压缩。此外，生成单元11将通用报头中的Flg设为表示压缩模式的1。处理从步骤S71进行到步骤S72。
在步骤S72，类似于图14中的步骤S52，生成单元11从发送目标IP数据包中的UDP报头或自IP报头获得的UDP数据包长度或IP数据包长度，获得压缩模式下的通用有效载荷的长度。处理进行到步骤S73。
在步骤S73，生成单元11确定在步骤S72获得的压缩模式下的通用有效载荷的长度是否为2047字节或更小。
在步骤S73，当确定通用有效载荷的长度是2047字节或更小时，处理进行到步骤S74。在步骤S74和S75，生成单元11执行类似于图14中的步骤S54和S55的各个处理。
也就是说，在步骤S74，生成单元11将通用报头中的Ext设为0。在步骤S75，生成单元11将在步骤S72获得的压缩模式下的通用有效载荷的长度设为通用报头的长度信息。
然后，处理从步骤S75进行到步骤S76。生成单元11将紧接通用报头之后的发送目标IP数据包的目的地IP地址和目的地端口号布置(添加)为通用有效载荷。处理进行到步骤S77。
在步骤S77，生成单元11将发送目标IP数据包中包括的UDP数据包内的有效载荷中布置的实际数据布置为紧随目的地IP地址和目的地端口号之后的通用有效载荷。这在压缩模式下完成通用数据包。
然后，生成单元11将压缩模式下的通用数据包提供给发送单元12，以终止压缩模式下的处理。
另一方面，在步骤S73，当确定通用有效载荷的长度不是2047字节或更小时，处理进行到步骤S78。在步骤S78和S79，生成单元11执行与图14中的步骤S58和S59类似的各个处理。这将通用报头扩展为扩展报头，并且将通用有效载荷的长度设为长度信息(Length)和用于添加字节的扩展的长度信息(Ext.Length)。
之后，处理从步骤S79进行到步骤S76。在此之后，在步骤S76和S77，生成单元11执行上述处理以在压缩模式下完成通用数据包，并且将通用数据包提供给发送单元12。
这里，如图9所示，超级压缩模带来IP报头和UDP报头的压缩比压缩模式下的压缩大的效果。
在与发送目标IP数据包中的目的地IP地址和目的地端口号(以及发送源IP地址和发送源端口号)相对应的目的地索引存在于索引表中的情况下，图13中的生成处理在其压缩效果大于压缩模式下的压缩效果的超级压缩模式下，生成通用数据包。在不存在这样的目的地索引的情况下，生成处理在其压缩效果小于超级压缩模式下的压缩效果的压缩模式下，生成通用数据包。
因此，使高使用频率的目的地IP地址和目的地端口号(以及发送源IP地址和发送源端口号)对应于目的地索引并且用索引表注册该项，允许进一步有效地广播通用数据包并且最终有效地广播IP数据包。
<通过恢复单元22进行的IP数据包的恢复处理>
图16是描述由恢复单元22从通用数据包恢复IP数据包的恢复处理的实例的图。
在步骤S81，恢复单元22基于通用报头中的类型信息(Type)识别布置在通用有效载荷中的IP数据包内的压缩的IP报头和UDP报头的存在/不存在。
此外，恢复单元22基于通用报头中的Ext识别通用报头是常规报头还是扩展报头。
此外，当恢复单元22根据类型信息(Type)识别出布置在通用有效载荷中的IP数据包内的IP报头和UDP报头是压缩时，恢复单元22基于通用报头中的Flg识别该通用数据包是压缩模式下的通用数据包还是超级压缩模式下的通用数据包。
在图16中，由于类型信息(Type)为011，因此识别到布置在通用有效载荷中的IP数据包内的IP报头和UDP报头被压缩。
此外，在图16中，由于Flg是0，所以识别出通用数据包是超级压缩模式下的通用数据包。
此外，在图16中，由于Ext是0，因此识别到通用报头是常规报头。
之后，恢复单元22识别布置在通用有效载荷中的IP数据包内的通用有效载荷的长度(Length)和目的地IP地址(dest.IP add.)以及目的地端口号(dest.port)。
也就是说，在图16中，由于通用报头是常规报头，因此将设为通用报头(即常规报头)中的长度信息(Length)的值识别为通用有效载荷的长度(Length)。
另外，在图16中，由于通用数据包是超级压缩模式下的通用数据包，所以一字节目的地索引布置在紧接通用报头之后的通用有效载荷的头部。恢复单元22通过从索引表(图8)中搜索来识别与目的地索引相对应的目的地IP地址和目的地端口号。
这里，在通用报头作为扩展报头的情况下，将由这样的位串表示的值识别为通用有效载荷的长度(length)：位串中作为扩展报头的通用报头的长度信息(length)配置为低位并且用于扩展添加字节的长度信息(Ext.Length)配置为高位。
另外，在通用数据包是压缩模式下的通用数据包的情况下，由于四字节目的地IP地址和两字节目的地端口号布置在紧接通用报头之后的通用有效载荷的头部，因此恢复单元22识别目的地IP地址和目的地端口号。
在步骤S82，恢复单元22恢复IP数据包中的IP报头中包括的目的地IP地址和IP数据包长度，以及IP数据包中的UDP报头中包括的目的地端口号和UDP数据包长度。
也就是说，恢复单元22将从通用数据包识别的目的地IP地址和目的地端口号分别恢复为IP数据包中的IP报头内包括的目的地IP地址和IP数据包中的UDP报头内包括的目的地端口号。
此外，恢复单元22将IP报头的20字节和UDP报头的八字节与从通用数据包识别的通用有效载荷的长度(length)相加。恢复单元22从相加的值中减去目的地索引的一个字节，以恢复包括在IP报头中的IP数据包长度(长度+28-1)。
此外，恢复单元22将UDP报头的八个字节与从通用数据包识别的通用有效载荷的长度(length)相加。恢复单元22从相加的值中减去目的地索引的一个字节，以恢复UDP报头中包括的UDP数据包长度(长度+8-1)。
这里，在通用数据包是压缩模式下的通用数据包的情况下，将布置在紧接通用报头之后的通用有效载荷的头部的目的地IP地址和目的地端口号，分别恢复为IP数据包中的IP报头内包括的目的地IP地址和IP数据包中的UDP报头内包括的目的地端口号。
此外，IP报头的20个字节和UDP报头的八个字节与通用有效载荷的长度(length)相加，并且从相加的值中减去布置在通用有效载荷中的目的地IP地址和目的地端口号的总大小的六个字节，以恢复包括在IP报头中的IP数据包长度。
此外，将UDP报头的八个字节与通用有效载荷的长度(length)相加，并且从相加的值中减去布置在通用有效载荷中的目的地IP地址和目的地端口号的总大小的六个字节，以恢复包括在UDP报头中的UDP数据包长度。
在步骤S83，恢复单元22将除了包括在IP报头中的目的地IP地址、IP数据包长度和校验和以外的项恢复为预定的固定值。此外，恢复单元22将除了包括在UDP报头中的目的地端口号、UDP数据包长度和校验和以外的项(即发送源端口号)恢复为预定的固定值。
如上所述，恢复包括在IP报头中的除了校验和之外的项，并且恢复包括在UDP报头中的除了校验和之外的项。
在步骤S84，恢复单元22将布置在通用有效载荷中的实际数据布置在IP报头和UDP报头之后以便在UDP/IP中配置IP数据包，其中IP报头包括恢复到目前的项并且UDP报头包括恢复到目前的项。
然后，在步骤S85，恢复单元22使用在步骤S84配置的IP数据包实际计算包括在IP报头和UDP报头中的校验和，以恢复各个校验和。
如上所述，布置在通用有效载荷中的IP数据包(具有压缩的IP报头和UDP报头)恢复为具有正确的IP报头和UDP报头的IP数据包。
如上所述，恢复单元22可以将布置在通用有效载荷中的IP数据包仅从具有通用有效载荷的通用数据包(不使用另一通用数据包)恢复到具有正确的IP报头和UDP报头的IP数据包。
因此，IP数据包可以从通用数据包快速恢复以用于快速处理。
这里，除了如图8所示的索引表中的目的地IP地址和目的地端口号之外，在目的地索引还对应于发送源IP地址和发送源端口号的情况下，包括在IP报头中的发送源IP地址和包括在UDP报头中的发送源端口号可以分别恢复为与索引表中的目的地索引相对应的发送源IP地址和发送源端口号。
另外，在发送装置10在比传输层高的上层中发送关于广播站的信息并且接收装置20可以从关于广播站的信息中识别发送源IP地址和发送源端口号的情况下，包括在IP报头中的发送源IP地址和包括在UDP报头中的发送源端口号可以分别恢复为从关于广播站的信息识别的发送源IP地址和发送源端口号。
应当注意，如上所述，恢复单元22实际计算包括在IP报头和UDP报头中的校验和，以恢复各个校验和。因此，所恢复的校验和基本上不是有效的(不起作用)。
然而，在符合诸如ATSC 3.0的广播标准的广播中，物理层执行强的纠错。因此，即使包括在IP报头和UDP报头中的校验和基本上不是有效的，这也不会引起问题。
图17是示出在IP报头项之中恢复为固定值的项和固定值的实例的图。
例如，在IP报头项之中恢复为固定值的项是版本(Version)、IHL、DSCP、ECN、标识、标志、片段偏移、存活时间以及协议。
例如，版本(Version)恢复为固定值4，其表示IP版本是IPv4。
应当注意，如图6所示，例如，在通用数据包中的类型信息表示通用有效载荷中的IPv4中的IP数据包的布置和IPv6中的IP数据包的布置的情况下，版本可以根据类型信息恢复为表示IPv4的固定值4和表示Ipv6的固定值6中的任一个。
假设在IP报头中不存在选项，则IHL恢复为表示IP报头的长度为20字节的固定值5。
当使用通用数据包广播IP数据包时，不特别需要DSCP、ECN、标识，标志以及片段偏移，并且因此，例如将其恢复为0作为预定的固定值。
如果适宜的话，由接收装置20恢复的IP数据包通过诸如家庭网络的通信网络发送，存活时间恢复为例如128的固定值，在该固定值处IP数据包的生存时间可以在一定程度上得到保护。
协议恢复为17，其是表示IP数据包中的有效载荷内包括的协议(即UDP)的固定值。
应当注意，为了将发送源IP地址和发送源端口号恢复为固定值，例如，可以采用如图8中的索引表中所示的192.168.0.0和60000作为相应的固定值。应当注意，发送源IP地址和发送源端口号的固定值不限于分别是192.168.0.0和60000。
图18是描述通过恢复单元22进行的IP数据包的恢复处理的实例的流程图。
在步骤S91，恢复单元22等待从接收单元21提供的一条通用数据包，并且从接收单元21获得通用数据包作为恢复目标通用数据包。处理进行到步骤S92。
在步骤S92，恢复单元22确定恢复目标通用数据包中的类型信息。
在步骤S92，当类型信息确定为010(即当恢复目标通用数据包是非压缩模式(图7的C)下的通用数据包)，并且因此具有未压缩的IP报头和UDP报头的IP数据包(具有正确的IP报头和UDP报头的IP数据包)布置在通用有效载荷中时，处理进行到步骤S93。
在步骤S93，恢复单元22从通用有效载荷中提取(获得)具有未压缩的IP报头和UDP报头的IP数据包，并且输出该IP数据包。处理返回到步骤S91。
另外，在步骤S92，当类型信息确定为011时，即具有压缩的IP报头和UDP报头的IPv4中的IP数据包布置在通用有效载荷中，处理进行到步骤S94。
在步骤S94，恢复单元22确定恢复目标通用数据包中的Ext。
在步骤S94，当Ext确定为1时，即当通用报头是扩展报头时，处理进行到步骤S95。
在步骤S95，恢复单元22识别由位串表示的值，位串中作为扩展报头的通用报头的长度信息(length)配置为低位，并且用于扩展添加字节的长度信息(Ext.Length)配置为作为通用有效载荷的长度(length)的高位。处理进行到步骤S97。
此外，在步骤S94，当Ext确定为0时，即当通用报头是常规报头时，处理进行到步骤S96。
在步骤S96，恢复单元22将由通用报头(其是常规报头)中的长度信息表示的值识别为通用有效载荷的长度(length)。处理进行到步骤S97。
在步骤S97，恢复单元22根据在如图16所示的步骤S95或S96识别的通用有效载荷的长度来恢复IP数据包长度和UDP数据包长度(大小)，并且将相应的数据包长度布置(包括)(设置)在IP报头和UDP报头中。处理进行到步骤S98。
在步骤S98，恢复单元22确定恢复目标通用数据包中的Flg。
在步骤S98，当Flg确定为1时，即当恢复目标通用数据包是压缩模式(图7的B)下的通用数据包，并且四字节目的地IP地址和两字节目的地端口号布置在紧接通用报头之后的通用有效载荷的头部时，处理进行到步骤S99。
在步骤S99，恢复单元22获得布置在通用有效载荷的头部的目的地IP地址和目的地端口号，以将目的地IP地址和目的地端口号分别布置到IP报头和UDP报头。处理进行到步骤S101。
此外，在步骤S98，当Flg确定为0时，即当恢复目标通用数据包是超级压缩模式(图7的A)下的通用数据包，并且一字节目的地索引布置在紧接通用报头之后的通用有效载荷的头部时，处理进行到步骤S100。
在步骤S100，恢复单元22获得布置在通用有效载荷的头部的目的地索引。此外，恢复单元22通过从索引表(图8)搜索来识别与目的地索引相对应的目的地IP地址和目的地端口号。然后，恢复单元22将与目的地索引相对应的目的地IP地址和目的地端口号布置在相应的IP报头和UDP报头中。处理从步骤S100进行到步骤S101。
在步骤S101，恢复单元22将例如图17中所描述的预定的固定值布置为IP报头中的除了目的地IP地址、IP数据包长度以及校验和之外的项。此外，恢复单元22将预定的固定值布置为UDP报头中的除了目的地端口号、UDP数据包长度以及校验和之外的项，即发送源端口号。
这里，除了使用预定的固定值作为IP报头中的发送源IP地址和UDP报头中的发送源端口号之外，如上所述，在目的地索引对应于目的地IP地址和目的地端口号并且进一步对应于索引表中的发送源IP地址和发送源端口号的情况下，与目的地索引相对应的发送源IP地址和发送源端口号可以用作IP报头的发送源IP地址和UDP报头的发送源端口号。
另外，在上层中的发送装置10发送关于广播站的信息并且接收装置20可以从关于广播站的信息中识别发送源IP地址和发送源端口号作为IP报头中的发送源IP地址和UDP报头中的发送源端口号的情况下，可以使用从关于广播站的信息中识别的发送源IP地址和发送源端口号。应当注意，发送源IP地址和发送源端口号可以是如上所述的固定值。
在步骤S101，在如上所述布置IP报头和UDP报头中的除了校验和之外的项之后，处理进行到步骤S102。恢复单元22获得布置在通用有效载荷中的实际数据。
然后，恢复单元22使用直到目前获得的IP报头来计算用于IP的校验和，并且使用UDP报头和直到目前获得的实际数据来计算用于UDP的校验和。处理从步骤S102进行到步骤S103。
在步骤S103，恢复单元22将用于IP的校验和布置在IP报头中，并且将用于UDP的校验和布置在UDP报头中。此外，恢复单元22配置并输出IP数据包，其中IP报头、UDP报头和实际数据按此顺序布置。处理从步骤S103返回到步骤S91。
<关于应用了本技术的计算机的说明>
接下来，由生成单元11和恢复单元22进行的上述处理的序列可以由硬件执行，并且也可以由软件执行。为了通过软件执行处理的序列，构成软件的程序安装在计算机等上。
然后，图19示出根据安装有执行上述处理的序列的程序的计算机的一个实施方式的配置的实例。
作为内置在计算机中的记录介质的硬盘105和ROM 103可以预先记录程序。
可替换地，可移除记录介质111可以存储(记录)程序。这种可移除记录介质111可以提供为所谓的封装软件。这里，例如，列出软盘、压缩盘只读存储器(CD-ROM)、磁光(MO)盘、数字通用盘(DVD)、磁盘、半导体存储器等作为可移除记录介质111。
应当注意，可以从计算机上的上述可移除记录介质111安装程序。此外，程序可以经由通信网络和广播网络下载到计算机中以将程序安装到内置硬盘105中。也就是说，例如，程序可以从下载网站经由用于数字卫星广播的人造卫星无线地传递到计算机，或者可以通过诸如局域网(LAN)和互联网的有线网络传递到计算机。
计算机包括中央处理单元(CPU)102。输入/输出接口110经由总线101耦接到CPU102。
当用户通过经由输入/输出接口110等在输入单元107上通过操作输入命令时，CPU102遵从命令并执行存储在只读存储器(ROM)103中的程序。可替换地，CPU 102将存储在硬盘105上的程序加载到随机存取存储器(RAM)104上用于执行。
鉴于此，CPU 102执行跟随上述流程图之后的处理或执行通过框图中的上述配置执行的处理。然后，例如，CPU 102在必要时经由输入/输出接口110从输出单元106输出处理结果。可替换地，例如，CPU 102使通信单元108发送处理结果，并且还使硬盘105记录处理结果。
应当注意，输入单元107由键盘、计算机鼠标、麦克风等配置。另外，输出单元106由液晶显示器(LCD)、扬声器等配置。
这里，在本说明书中，由计算机遵从程序执行的处理不一定按如流程图所描述的顺序以时间序列执行。也就是说，由计算机遵从程序执行的处理还包括并发或单独地执行的处理(例如，并行处理或与对象的处理)。
另外，一个计算机(处理器)可以处理程序，或者多个计算机可以分散处理程序。
此外，在本说明书中，系统是指多个结构元件(装置、模块(部件)等)的集合。所有结构元件是否在同一壳体中并不重要。因此，容纳在不同壳体中并且通过网络耦接的多个装置和在一个壳体中容纳多个模块的一个装置全部称为系统。
应当注意，本技术的实施方式不限于上述实施方式。在不偏离本技术的主旨的范围内可以进行各种修改。
例如，上述流程图中描述的各个步骤可以由一个装置执行，并且还可以由多个装置共享并执行。
此外，在一个步骤包括多个处理的情况下，包括在一个步骤中的多个处理可以由一个装置执行，并且还可以由多个装置共享并执行。
另外，虽然显然可应用于ATSC，但是本技术还可应用于除了ATSC之外的广播标准(例如数字视频广播(DVB)和综合业务数字广播(ISDB))中的广播。
另外，本说明书中描述的效果仅仅是实例，并不限于此；因此，可以提供另一效果。
应当注意，本技术可以采用以下配置。
<1>
一种发送装置，包括：
生成单元，配置为生成传输数据包，所述传输数据包由以下构成：
由类型信息和长度信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度；以及
由目的地索引和所述UDP数据包中的有效载荷构成的有效载荷，所述目的地索引与所述IP数据包的目的地IP地址和所述UDP数据包的目的地端口号建立对应关系；以及发送单元，配置为发送该传输数据包。
<2>
根据<1>所述的发送装置，
其中，当存在与所述目的地IP地址和所述目的地端口号建立对应关系的所述目的地索引时，所述生成单元配置为生成由所述目的地索引和所述UDP数据包中的有效载荷构成的有效载荷的所述传输数据包，
当不存在与所述目的地IP地址和所述目的地端口号建立对应关系的所述目的地索引时，所述生成单元配置为生成由所述目的地IP地址、所述目的地端口号以及所述UDP数据包中的有效载荷构成的有效载荷的所述传输数据包，以及
所述传输数据包的报头由所述类型信息、所述长度信息以及种类信息构成，所述种类信息表示所述目的地索引、所述目的地IP地址以及所述目的地端口号中的任一个是否包括在所述传输数据包中的有效载荷内。
<3>
根据<1>或<2>所述的发送装置，
其中，所述目的地索引具有小于所述目的地IP地址和所述目的地端口号的总大小的大小。
<4>
一种发送方法，包括以下步骤：
生成传输数据包，传输数据包由以下构成：
由类型信息和长度信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度；以及
由目的地索引和所述UDP数据包中的有效载荷构成的有效载荷，所述目的地索引与所述IP数据包的目的地IP地址和所述UDP数据包的目的地端口号建立对应关系；以及发送该传输数据包。
<5>
一种接收装置，包括：
接收单元，配置为接收传输数据包，传输数据包由以下构成：
由类型信息和长度信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度；以及
由目的地索引和所述UDP数据包中的有效载荷构成的有效载荷，所述目的地索引与所述IP数据包的目的地IP地址和所述UDP数据包的目的地端口号建立对应关系；以及恢复单元，配置为从传输数据包恢复IP数据包。
<6>
根据<5>所述的接收装置，
其中，恢复单元配置为：
将与所述目的地索引建立对应关系的所述目的地IP地址和所述目的地端口号分别恢复为包括在所述IP报头中的目的地IP地址和包括在所述UDP报头中的目的地端口号；
从所述长度信息恢复包括在所述IP报头中的关于所述IP数据包的长度的信息和包括在所述UDP数据包中的关于所述UDP数据包的长度的信息；
将所述IP报头中包括的除了所述目的地IP地址、关于所述IP数据包的长度的信息以及校验和之外的项恢复为预定的固定值；
将所述UDP报头中包括的除了所述目的地端口号、关于所述UDP数据包的长度的信息以及校验和之外的项恢复为预定的固定值；以及
通过计算恢复用于所述IP数据包和所述UDP数据包的相应的校验和。
<7>
根据<5>所述的接收装置，
其中，除了所述目的地IP地址和所述目的地端口号之外，还将发送源IP地址和发送源端口号与所述目的地索引建立对应关系，
恢复单元配置为：
将与所述目的地索引建立对应关系的所述目的地IP地址和所述目的地端口号分别恢复为包括在所述IP报头中的目的地IP地址和包括在所述UDP报头中的目的地端口号；
将与所述目的地索引建立对应关系的所述发送源IP地址和所述发送源端口号分别恢复为包括在所述IP报头中的发送源IP地址和包括在所述UDP报头中的发送源端口号；
从所述长度信息恢复包括在所述IP报头中的关于所述IP数据包的长度的信息和包括在所述UDP数据包中的关于所述UDP数据包的长度的信息；
将所述IP报头中包括的除了目的地IP地址、关于IP数据包的长度信息、发送源IP地址以及校验和之外的项恢复为预定的固定值；以及
通过计算恢复所述IP数据包的校验和以及所述UDP数据包的校验和。
<8>
根据<5>至<7>中任一项所述的接收装置，
其中，目的地索引具有小于目的地IP地址和目的地端口号的总大小的大小。
<9>
一种接收方法，包括以下步骤：
接收传输数据包，传输数据包由以下构成：
由类型信息和长度信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度；以及
由目的地索引和所述UDP数据包中的有效载荷构成的有效载荷，所述目的地索引与所述IP数据包的目的地IP地址和所述UDP数据包的目的地端口号建立对应关系；以及
从传输数据包恢复IP数据包。
<10>
一种发送装置，包括：
生成单元，配置为生成传输数据包，传输数据包由以下构成：
由类型信息和长度信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度；以及
由IP数据包的目的地IP地址、UDP数据包的目的地端口号以及UDP数据包中的有效载荷构成的有效载荷；以及发送单元，配置为发送该传输数据包。
<11>
根据<10>所述的发送装置，
其中，传输数据包中的有效载荷仅包括IP报头和UDP报头中的目的地IP地址和目的地端口号。
<12>
一种发送方法，包括以下步骤：
生成传输数据包，传输数据包由以下构成：
由类型信息和长度信息构成的报头，类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，长度信息表示用于发送包括UDP数据包的IP数据包的传输数据包的长度；以及
由IP数据包的目的地IP地址、UDP数据包的目的地端口号以及UDP数据包中的有效载荷构成的有效载荷；以及发送该传输数据包。
<13>
一种接收装置，包括：
接收单元，配置为接收传输数据包，传输数据包由以下构成：
由类型信息和长度信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度；以及
由所述IP数据包的目的地IP地址、所述UDP数据包的目的地端口号以及所述UDP数据包中的有效载荷构成的有效载荷；以及恢复单元，配置为从传输数据包恢复IP数据包。
<14>
根据<13>所述的接收装置，
其中，恢复单元配置为：
将所述传输数据包中的报头内包括的所述目的地IP地址和所述目的地端口号分别恢复为包括在所述IP报头中的目的地IP地址和包括在所述UDP报头中的目的地端口号；
从所述长度信息恢复包括在所述IP报头中的关于IP数据包的长度的信息和包括在所述UDP数据包中的关于UDP数据包的长度的信息；
将所述IP报头中包括的除了所述目的地IP地址、关于所述IP数据包的长度的信息以及校验和之外的项恢复为预定的固定值；
将所述UDP报头中包括的除了所述目的地端口号、关于所述UDP数据包的长度的信息以及校验和之外的项恢复为预定的固定值；以及
通过计算恢复用于所述IP数据包和所述UDP数据包的相应的校验和。
<15>
根据<13>所述的接收装置，用于在比传输层高的层中获得IP数据包的发送源IP地址和UDP数据包的发送源端口号，
其中，恢复单元配置为：
将所述传输数据包中的报头内包括的所述目的地IP地址和所述目的地端口号分别恢复为包括在所述IP报头中的目的地IP地址和包括在所述UDP报头中的目的地端口号；
从所述长度信息恢复包括在所述IP报头中的关于IP数据包的长度的信息和包括在所述UDP数据包中的关于UDP数据包的长度的信息；
将在所述更高的层中获得的所述发送源IP地址和所述发送源端口号分别恢复为包括在所述IP报头中的发送源IP地址和包括在所述UDP报头中的发送源端口号；
将所述IP报头中包括的除了所述目的地IP地址、关于所述IP数据包的长度的信息、所述发送源端口号以及校验和之外的项恢复为预定的固定值；以及
通过计算恢复所述IP数据包和所述UDP数据包的相应的校验和。
<16>
一种接收方法，包括以下步骤：
接收传输数据包，传输数据包由以下构成：
由类型信息和长度信息构成的报头，类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，长度信息表示用于发送包括UDP数据包的IP数据包的传输数据包的长度；以及
由IP数据包的目的地IP地址、UDP数据包的目的地端口号以及UDP数据包中的有效载荷构成的有效载荷；以及从传输数据包恢复IP数据包。
参考符号列表
10 发送装置
11 生成单元
12 发送单元
20 接收装置
21 接收单元
22 恢复单元
101 总线
102 CPU
103 ROM
104 RAM
105 硬盘
106 输出单元
107 输入单元
108 通信单元
109 驱动
110 输入/输出接口
111 可移除记录介质

Claims (16)

1.一种发送装置，包括：
生成单元，配置为生成传输数据包，所述传输数据包由以下构成：
由类型信息和长度信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度；以及
由目的地索引和所述UDP数据包中的有效载荷构成的有效载荷，所述目的地索引基于存储在所述发送装置中的索引表与所述IP数据包的目的地IP地址和所述UDP数据包的目的地端口号相对应；以及
发送单元，配置为发送所述传输数据包，
其中，所述发送单元还被配置为发送以广播标准进行广播的广播站的信息，所述广播站的信息包括为固定IP地址的发送源IP地址。
2.根据权利要求1所述的发送装置，
其中，当存在与所述目的地IP地址和所述目的地端口号建立对应关系的所述目的地索引时，所述生成单元配置为生成由所述目的地索引和所述UDP数据包中的有效载荷构成的有效载荷的所述传输数据包，
当不存在与所述目的地IP地址和所述目的地端口号建立对应关系的所述目的地索引时，所述生成单元配置为生成由所述目的地IP地址、所述目的地端口号以及所述UDP数据包中的有效载荷构成的有效载荷的所述传输数据包，以及
所述传输数据包的报头由所述类型信息、所述长度信息以及种类信息构成，所述种类信息表示所述目的地索引、所述目的地IP地址以及所述目的地端口号中的任一个是否包括在所述传输数据包中的有效载荷内。
3.根据权利要求1所述的发送装置，
其中，所述目的地索引具有小于所述目的地IP地址和所述目的地端口号的总大小的大小。
4.一种发送方法，包括以下步骤：
生成传输数据包，所述传输数据包由以下构成：
由类型信息和长度信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度；以及
由目的地索引和所述UDP数据包中的有效载荷构成的有效载荷，基于存储在发送装置中的索引表，所述目的地索引与所述IP数据包的目的地IP地址和所述UDP数据包的目的地端口号建立对应关系；以及
发送所述传输数据包；以及
发送以广播标准进行广播的广播站的信息，所述广播站的信息包括为固定IP地址的发送源IP地址。
5.一种接收装置，包括：
接收单元，配置为接收传输数据包，所述传输数据包由以下构成：
由类型信息和长度信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度；以及
由目的地索引和所述UDP数据包中的有效载荷构成的有效载荷，基于存储在发送装置中的索引表，所述目的地索引与所述IP数据包的目的地IP地址和所述UDP数据包的目的地端口号建立对应关系；以及
恢复单元，配置为从所述传输数据包恢复所述IP数据包，其中，所述IP数据包的源IP地址被所恢复的IP数据包中的固定IP地址所代替。
6.根据权利要求5所述的接收装置，
其中，所述恢复单元配置为：
将与所述目的地索引建立对应关系的所述目的地IP地址和所述目的地端口号分别恢复为包括在所述IP报头中的目的地IP地址和包括在所述UDP报头中的目的地端口号；
从所述长度信息恢复包括在所述IP报头中的关于所述IP数据包的长度的信息和包括在所述UDP报头中的关于所述UDP数据包的长度的信息；
将所述IP报头中包括的除了所述目的地IP地址、关于所述IP数据包的长度的信息以及校验和之外的项恢复为预定的固定值；
将所述UDP报头中包括的除了所述目的地端口号、关于所述UDP数据包的长度的信息以及校验和之外的项恢复为预定的固定值；以及
通过计算恢复用于所述IP数据包和所述UDP数据包的相应的校验和。
7.根据权利要求5所述的接收装置，
其中，除了所述目的地IP地址和所述目的地端口号之外，还将发送源IP地址和发送源端口号与所述目的地索引建立对应关系，
所述恢复单元配置为：
将与所述目的地索引建立对应关系的所述目的地IP地址和所述目的地端口号分别恢复为包括在所述IP报头中的目的地IP地址和包括在所述UDP报头中的目的地端口号；
将与所述目的地索引建立对应关系的所述发送源IP地址和所述发送源端口号分别恢复为包括在所述IP报头中的发送源IP地址和包括在所述UDP报头中的发送源端口号；
从所述长度信息恢复包括在所述IP报头中的关于所述IP数据包的长度的信息和包括在所述UDP报头中的关于所述UDP数据包的长度的信息；
将所述IP报头中包括的除了目的地IP地址、关于IP数据包的长度信息、发送源IP地址以及校验和之外的项恢复为预定的固定值；以及
通过计算恢复所述IP数据包的校验和以及所述UDP数据包的校验和。
8.根据权利要求5所述的接收装置，
其中，所述目的地索引具有小于所述目的地IP地址和所述目的地端口号的总大小的大小。
9.一种接收方法，包括以下步骤：
接收传输数据包，所述传输数据包由以下构成：
由类型信息和长度信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度；以及
由目的地索引和所述UDP数据包中的有效载荷构成的有效载荷，所述目的地索引与所述IP数据包的目的地IP地址和所述UDP数据包的目的地端口号建立对应关系；以及
从所述传输数据包恢复所述IP数据包，其中，所述IP数据包的源IP地址被所恢复的IP数据包中的固定IP地址所代替。
10.一种发送装置，包括：
生成单元，配置为生成传输数据包，所述传输数据包由以下构成：
由类型信息、长度信息和种类信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度，所述种类信息指示基于存储在所述发送装置中的索引表与所述IP数据包的目的地IP地址和所述UDP数据包的目的地端口号相对应的所述目的地索引是否包括在有效载荷中；以及
由所述IP数据包的目的地IP地址、所述UDP数据包的目的地端口号以及所述UDP数据包中的所述有效载荷构成的有效载荷；以及
发送单元，配置为发送所述传输数据包；
其中，所述发送单元还被配置为发送以广播标准进行广播的广播站的信息，所述广播站的信息包括为固定IP地址的发送源IP地址。
11.根据权利要求10所述的发送装置，
其中，所述传输数据包中的有效载荷仅包括所述IP报头和所述UDP报头中的所述目的地IP地址和所述目的地端口号。
12.一种发送方法，包括以下步骤：
生成传输数据包，所述传输数据包由以下构成：
由类型信息和长度信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度；以及
由所述IP数据包的目的地IP地址、所述UDP数据包的目的地端口号以及所述UDP数据包中的有效载荷构成的有效载荷；以及
发送所述传输数据包；
发送以广播标准进行广播的广播站的信息，所述广播站的信息包括为固定IP地址的发送源IP地址。
13.一种接收装置，包括：
接收单元，配置为接收传输数据包，所述传输数据包由以下构成：
由类型信息和长度信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度；以及
由所述IP数据包的目的地IP地址、所述UDP数据包的目的地端口号以及所述UDP数据包中的有效载荷构成的有效载荷；以及
恢复单元，配置为从所述传输数据包恢复所述IP数据包，其中，所述IP数据包的源IP地址被所恢复的IP数据包中的固定IP地址所代替。
14.根据权利要求13所述的接收装置，
其中，所述恢复单元配置为：
将所述传输数据包中的报头内包括的所述目的地IP地址和所述目的地端口号分别恢复为包括在所述IP报头中的目的地IP地址和包括在所述UDP报头中的目的地端口号；
从所述长度信息恢复包括在所述IP报头中的关于IP数据包的长度的信息和包括在所述UDP报头中的关于UDP数据包的长度的信息；
将所述IP报头中包括的除了所述目的地IP地址、关于所述IP数据包的长度的信息以及校验和之外的项恢复为预定的固定值；
将所述UDP报头中包括的除了所述目的地端口号、关于所述UDP数据包的长度的信息以及校验和之外的项恢复为预定的固定值；以及
通过计算恢复用于所述IP数据包和所述UDP数据包的相应的校验和。
15.根据权利要求13所述的接收装置，用于在比传输层更高的层中获得所述IP数据包的发送源IP地址和所述UDP数据包的发送源端口号，
其中，所述恢复单元配置为：
将所述传输数据包中的报头内包括的所述目的地IP地址和所述目的地端口号分别恢复为包括在所述IP报头中的目的地IP地址和包括在所述UDP报头中的目的地端口号；
从所述长度信息恢复包括在所述IP报头中的关于IP数据包的长度的信息和包括在所述UDP报头中的关于UDP数据包的长度的信息；
将在所述更高的层中获得的所述发送源IP地址和所述发送源端口号分别恢复为包括在所述IP报头中的发送源IP地址和包括在所述UDP报头中的发送源端口号；
将所述IP报头中包括的除了所述目的地IP地址、关于所述IP数据包的长度的信息、所述发送源端口号以及校验和之外的项恢复为预定的固定值；以及
通过计算恢复所述IP数据包和所述UDP数据包的相应的校验和。
16.一种接收方法，包括以下步骤：
接收传输数据包，所述传输数据包由以下构成：
由类型信息和长度信息构成的报头，所述类型信息表示互联网协议(IP)报头和用户数据报协议(UDP)报头是否被压缩，所述长度信息表示用于发送包括UDP数据包的IP数据包的所述传输数据包的长度；以及
由所述IP数据包的目的地IP地址、所述UDP数据包的目的地端口号以及所述UDP数据包中的有效载荷构成的有效载荷；以及
从所述传输数据包恢复所述IP数据包，其中，所述IP数据包的源IP地址被所恢复的IP数据包中的固定IP地址所代替。
CN201580057149.6A 2014-10-30 2015-10-19 发送装置、发送方法、接收装置以及接收方法 Active CN107078975B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2014222026 2014-10-30
JP2014-222026 2014-10-30
PCT/JP2015/079442 WO2016067954A1 (ja) 2014-10-30 2015-10-19 送信装置、送信方法、受信装置、及び、受信方法

Publications (2)

Publication Number Publication Date
CN107078975A CN107078975A (zh) 2017-08-18
CN107078975B true CN107078975B (zh) 2021-03-23

Family

ID=55857295

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201580057149.6A Active CN107078975B (zh) 2014-10-30 2015-10-19 发送装置、发送方法、接收装置以及接收方法

Country Status (8)

Country Link
US (1) US10367921B2 (zh)
EP (1) EP3255850B1 (zh)
JP (1) JPWO2016067954A1 (zh)
KR (1) KR102444168B1 (zh)
CN (1) CN107078975B (zh)
CA (1) CA2964728C (zh)
MX (1) MX2017005213A (zh)
WO (1) WO2016067954A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105981318B (zh) 2014-12-10 2019-08-09 Lg电子株式会社 广播信号发送装置、广播信号接收装置、广播信号发送方法和广播信号接收方法
US11095876B2 (en) 2018-01-26 2021-08-17 Samsung Electronics Co., Ltd. Image processing device
KR102626217B1 (ko) 2018-11-30 2024-01-16 삼성전자주식회사 프레임 버퍼 컴프레서 및 이를 포함하는 이미지 처리 장치
KR20200065367A (ko) 2018-11-30 2020-06-09 삼성전자주식회사 이미지 처리 장치 및 프레임 버퍼 컴프레서
CN112805979A (zh) * 2019-02-01 2021-05-14 Oppo广东移动通信有限公司 一种头压缩的处理方法及装置、通信设备
US11323552B2 (en) * 2019-04-19 2022-05-03 EMC IP Holding Company LLC Automatic security configurations in disaster recovery
CN112583472B (zh) * 2020-12-28 2023-05-19 四川安迪科技实业有限公司 批量升级卫星设备的组播文件发送、接收、传输方法及装置
CN115694563A (zh) * 2021-07-30 2023-02-03 国基电子（上海）有限公司 基于蓝牙的传输方法、发送装置、传输系统及存储介质
CN115134431B (zh) * 2022-05-27 2023-10-20 江苏金智科技股份有限公司 一种配电自动化5g差动保护的udp差动报文提取方法及系统

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1451981A1 (en) * 2001-10-29 2004-09-01 MPNET International, Inc. Method, system, and data structure for multimedia communications
WO2004017597A1 (en) * 2002-08-14 2004-02-26 Nokia Corporation Layered compression architecture for multi-hop header compression
FR2907624B1 (fr) * 2006-10-24 2009-02-20 Alcatel Sa Dispositif de compression a adaptation de compression en fonction du medium de transport, et dispositif de decompression associe, pour des equipements de communication
KR101366254B1 (ko) * 2007-08-03 2014-02-20 삼성전자주식회사 방송망을 통하여 전송되는 ｉｐ 패킷의 압축 및 복원 방법
JP4814864B2 (ja) * 2007-11-26 2011-11-16 日本放送協会 パケット多重化装置及びパケット多重化プログラム
CN101453465A (zh) * 2007-11-29 2009-06-10 中兴通讯股份有限公司 一种移动多媒体广播系统的ip包压缩、解压缩方法
JP4780345B2 (ja) * 2008-06-30 2011-09-28 日本電気株式会社 通信システム、接続装置、接続方法およびプログラム
JP5066064B2 (ja) 2008-11-28 2012-11-07 日本放送協会 一方向伝送路に用いる送信端末、受信端末及び伝送システム
CN101998511B (zh) * 2009-08-26 2013-04-24 华为技术有限公司 网络中继场景下的头压缩方法及装置
IL204515A (en) * 2010-03-16 2014-06-30 Amir Ilan A method and device for reducing packet network delays
US9357435B2 (en) * 2013-11-06 2016-05-31 Samsung Electronics Co., Ltd. Method and system for handling audio packets during a volte call
KR102192165B1 (ko) * 2013-11-25 2020-12-16 삼성전자주식회사 전자 장치에서 헤더 압축된 패킷을 처리하기 위한 장치 및 방법
US10135886B2 (en) * 2014-03-10 2018-11-20 Samsung Electronics Co., Ltd. Method and device for retaining robust header compression (ROHC) compressor state
KR20150145687A (ko) * 2014-06-20 2015-12-30 삼성전자주식회사 Ip 기반 방송 망에서 전송 패킷 압축 기법

Also Published As

Publication number Publication date
MX2017005213A (es) 2017-07-27
JPWO2016067954A1 (ja) 2017-08-31
CA2964728C (en) 2023-04-04
US10367921B2 (en) 2019-07-30
EP3255850B1 (en) 2021-12-01
EP3255850A4 (en) 2018-12-05
WO2016067954A1 (ja) 2016-05-06
EP3255850A1 (en) 2017-12-13
KR102444168B1 (ko) 2022-09-19
US20180027096A1 (en) 2018-01-25
CN107078975A (zh) 2017-08-18
CA2964728A1 (en) 2016-05-06
KR20170078625A (ko) 2017-07-07

Similar Documents

Publication Publication Date Title
CN107078975B (zh) 发送装置、发送方法、接收装置以及接收方法
US6711164B1 (en) Method and apparatus for performing IP-ID regeneration to improve header compression efficiency
CN107079028B (zh) 发送装置和接收装置及其信号处理方法
US20060104278A1 (en) Apparatus and method for compressing headers in a broadband wireless communication system
KR20160074530A (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US11792304B2 (en) Broadcast signal transmission apparatus, broadcast signal transmission method, broadcast signal reception apparatus and broadcast signal reception method
EP3422618A1 (en) Receiving device, sending device and data processing method
CN107925679B (zh) 用于在多媒体系统中发送和接收信号的装置和方法
KR102514752B1 (ko) 송신 장치, 수신 장치 및 데이터 처리 방법
KR102424932B1 (ko) 수신 장치 및 데이터 처리 방법
WO2016171008A1 (ja) 送信装置、送信方法、受信装置、及び、受信方法
CN111447243B (zh) 发送装置和接收装置及其信号处理方法
EP4089983A1 (en) Method and apparatus for processing multicast signal
US20240214234A1 (en) Multicast signal processing method and device
WO2017047423A1 (ja) 送信装置、受信装置、及び、データ処理方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant