Legal claims defining the scope of protection. Each claim is shown in both the original legal language and a plain English translation.
1. A device for compression of streams of packets of data, for a communication equipment comprising a transmission end point in an Internet Protocol (IP) communication network, said packets of a stream each comprising an IP header including a destination end point identifier, a session identifier and stream attributes, and a transport protocol header, and said packets to be transmitted after decomposition into cells, the device comprising: a processing module configured, in case of reception of a packet of a stream, to: determine if the IP header of said packet can be compressed as a function of at least one chosen criterion, then if so, to determine if said compression can lead to a reduction in the number of cells having to result from the decomposition of said packet, and if so, to replace in said packet at least said IP header by a compressed header comprising at least the session identifier and a compression identifier, after having transmitted beforehand to said destination end point of the received stream, in a partially compressed form, at least the IP header that has to be replaced; and in case of replacement of at least the IP header of a received packet by an at least partially compressed header, determine if the payload data associated with the at least partially compressed header can be compressed as a function of at least one chosen criterion, and if so, to integrate into the at least partially compressed header an identifier signaling the data compression.
A compression device for Internet Protocol (IP) networks compresses streams of data packets sent from a communication device acting as a transmission endpoint. Each packet includes an IP header (containing destination, session ID, and stream attributes) and a transport protocol header. The device determines if a packet's IP header can be compressed based on criteria. If compression reduces the number of resulting cells after packet decomposition, the IP header is replaced with a compressed header containing at least the session ID and a compression identifier. Before replacing, the original IP header is transmitted in a partially compressed form to the destination endpoint. If the IP header is replaced, the device checks if the associated payload can be compressed and signals payload compression in the compressed header.
2. The device according to claim 1 , wherein said processing module is adapted configured, in the presence of a Transmission Control Protocol (TCP) type transport protocol, to replace the IP header of the received packet by a compressed header of two bytes comprising at least the session identifier, a compression identifier and a transport protocol type identifier.
The compression device (as described in Claim 1) specifically handles Transmission Control Protocol (TCP) traffic. When a packet uses TCP, the device replaces the IP header with a compressed two-byte header. This header contains the session identifier, a compression identifier, and a transport protocol type identifier, optimizing header size for TCP-based communication streams within the IP network environment.
3. The device according to claim 1 , wherein said processing module is adapted configured, in the presence of a User Datagram Protocol (UDP) type transport protocol, to replace the IP header and the UDP header of the received packet by a compressed header of two bytes comprising at least the session identifier, a compression identifier and a transport protocol type identifier.
The compression device (as described in Claim 1) also handles User Datagram Protocol (UDP) traffic. When a packet uses UDP, the device replaces both the IP header and the UDP header with a compressed two-byte header. This header contains the session identifier, a compression identifier, and a transport protocol type identifier, achieving higher compression ratios for UDP-based streams compared to compressing only the IP header.
4. The device according to claim 1 , wherein said processing module is configured to determine if the header of the received packet can be compressed as a function of at least one criterion chosen in a group comprising at least the fragmentation of the packet, the transport protocol type, a transport protocol subtype, a compression authorization received from said destination end point, and a local compression authorization.
The compression device (as described in Claim 1) determines if a packet's header can be compressed based on one or more criteria. These criteria include packet fragmentation status, transport protocol type (e.g., TCP, UDP), transport protocol subtype, compression authorization received from the destination endpoint, and locally configured compression authorization settings. These factors dynamically influence the compression decision.
5. The device according to claim 1 , wherein said processing module is configured to determine first and second numbers of cells that would result from the decomposition of the packet of the stream respectively in the absence and in the presence of compression of their header, and to proceed to the replacement of at least the IP header of the last packet received by an at least partially compressed header if said first number is strictly greater than said second number.
The compression device (as described in Claim 1) determines header compression effectiveness by calculating the number of cells required to transmit a packet with and without compression. If compressing the header reduces the number of cells needed for transmission (original cell count is greater than compressed cell count), the device replaces at least the IP header of the received packet with a compressed header. This optimizes cell usage and reduces overhead.
6. The device according to claim 1 , wherein said processing module is configured, in case of reception of a packet of a stream and the taking of a decision to compress at least its IP header, assign a hashing key to said stream as a function of chosen fields of the IP header of its received packet, to determine in a storage module if that hashing key is stored therein, and if not, to consider said stream as a new stream, and then to store said hashing key in said storage module if the session identifier associated with said stream is available at least from the expiry of a first time-delay, and to proceed to the replacement of the IP header of said received packet by a partially compressed header, or if so to reset to zero said first time-delay associated with the session identifier of said stream and to proceed to said replacement of at least the IP header of said received packet by a compressed header.
The compression device (as described in Claim 1) assigns a hashing key to each stream based on chosen fields from the IP header of received packets. The device checks if this hashing key is already stored. If not, it considers the stream a new stream. If the session ID for the stream becomes available within a specified time, the hashing key is stored, and the IP header is replaced with a partially compressed header. If the hashing key *is* stored, the time delay is reset, and the IP header is replaced with a compressed header. This ensures efficient compression for new and established streams.
7. The device according to claim 6 , wherein said processing module is configured either to trigger a second time-delay associated with said stream just before proceeding to the replacement of the IP header of the received packet by a partially compressed header or, after having reset to zero said first time-delay associated with the session identifier of said stream, to determine if said second time-delay associated with said stream has expired in order either to proceed to said replacement of at least the IP header of the received packet by a compressed header if said second time-delay has not expired or to trigger a second time-delay associated with said stream just before proceeding to the replacement of the IP header of the received packet by a partially compressed header.
The compression device (as described in Claim 6) manages time delays associated with streams. When using partial compression, a second time delay is initiated just before replacing the IP header. If, after resetting the first time delay, the second time delay has *not* expired, the IP header is replaced with a compressed header. If the second time delay *has* expired, a new second time delay is started just before proceeding with partial compression. This controls the transition between partial and full compression based on stream activity.
8. The device according to claim 7 , wherein said processing module is configured, after having reset to zero said first time-delay associated with the session identifier of said stream and in the case of non-expiry of said second time-delay associated with said stream, to compare to a chosen threshold the number of packets of said stream that have been transmitted in the form of cells with a compressed header in order either to proceed to said replacement of at least the IP header of the last packet received by said compressed header if said second time-delay has not expired or to trigger said second time-delay associated with said stream just before proceeding to the replacement of the IP header of the received packet by a partially compressed header if said number of packets is greater than or equal to said threshold.
The compression device (as described in Claim 7) tracks the number of packets transmitted with a compressed header. After resetting the first time delay, if the second time delay is active, the number of compressed packets is compared to a threshold. If the packet count exceeds the threshold, the IP header is replaced with a compressed header. Otherwise, a new second time delay is triggered before replacing the IP header with a partially compressed header. This balances header compression with stream reliability and context retention.
9. The device according to claim 1 , wherein said processing module is configured to determine if the payload data associated with said at least partially compressed header can be compressed as a function of at least one criterion chosen in a group comprising at least the availability of local resources, the availability of decompression resources in said destination end point and the size of the received packet.
The compression device (as described in Claim 1) determines if the payload data associated with a partially compressed header can be compressed based on factors like the availability of local processing resources, the availability of decompression resources at the destination endpoint, and the size of the received packet. These factors help optimize resource usage.
10. The device according to claim 1 , wherein said processing module is configured, in case of determination of a possibility of compression of the payload data of the packet comprising the compressed header, to determine if said data compression can lead to a reduction in the number of cells that has to result from the decompression of said packet, then, if so, to integrate into said compressed header an identifier signaling said compression of the payload data, and if not, to integrate into said compressed header an identifier signaling the prohibition on compression of the payload data.
The compression device (as described in Claim 1) determines whether payload data compression will reduce the number of cells required for transmission. If payload compression decreases the cell count, the compressed header is marked with an identifier indicating payload data compression. If payload compression doesn't reduce the cell count, the header is marked with an identifier prohibiting payload data compression. This ensures that payload compression is only used when it improves cell efficiency.
11. A device for decompression of cells of a stream that have been the subject of compression by a compression device for a communication equipment constituting a transmission end point in an Internet Protocol (IP) communication network, the device comprising: a processing module configured, in case of reception of cells of a packet of a stream, determine if they comprise an at least partially compressed header including in particular a compression identifier and a session identifier, then if so to determine in a storage module if said session identifier is already stored therein and therefore corresponds to a known stream, then if so, either to store the information relating to said stream in said storage module if said compression identifier signals a partially compressed header, and then to reconstruct the original IP header from said partially compressed header, or, if said compression identifier signals a compressed header, to reconstruct the original header from corresponding information stored in said storage module and designated by the session identifier contained in the received compressed header; and a decompression module configured, in case of reconstruction of the original header of cells of a packet of a stream, to determine if said header comprises a data compression identifier signaling that the cells have been the subject of payload data compression, and if so, either to proceed to the decompression of said payload data if there exist locally resources that enable it, or to send the communication equipment constituting the source of said cells a message signaling saturation of the receive resources and then drop said received packet.
A decompression device receives data cells that have been compressed for Internet Protocol (IP) networks, operating at the receiving endpoint of a communication. Upon receiving cells, the device checks for a partially or fully compressed header (indicated by a compression identifier and session ID). It then checks if the session ID is known. If the header is partially compressed, stream information is stored, and the original IP header is reconstructed. If fully compressed, the original header is reconstructed using stored information. The device also checks for a data compression identifier, and if present, either decompresses the payload (if resources are available) or sends a resource saturation message to the sender and drops the packet.
12. The device according to claim 11 , wherein said processing module is configured, in case of reception of cells of a packet of a stream, to begin by determining if they concern an IP packet to be decompressed, and if so to determine if said cells comprise an at least partially compressed header only on condition that they concern chosen versions of the Internet Protocol (IP).
The decompression device (as described in Claim 11) initially checks if received data cells are part of an IP packet requiring decompression. Further decompression processing (identifying partially compressed header) is conditional and applied only to chosen Internet Protocol (IP) versions. This ensures that the decompression process is applied selectively and correctly.
13. The device according to claim 11 , wherein said processing module is configured, if said compression identifier signals a partially compressed header, to access said storage module to determine if the session identifier contained in that header is stored therein, and if not to store said session identifier in said storage module, and then to store the information relating to said stream in said storage module in corresponding relationship to said session identifier.
The decompression device (as described in Claim 11) handles partially compressed headers by accessing a storage module to check if the session ID is known. If the session ID is *not* in storage, it's stored, and stream information is associated with that ID in the storage module. This process enables the device to learn and reconstruct headers for new, partially compressed streams.
14. The device according to claim 11 , wherein said processing module is configured, if said compression identifier signals a compressed header, to access a storage module to determine if the session identifier contained in that compressed header is stored therein, and if not to drop said received packet.
The decompression device (as described in Claim 11) handles compressed headers by checking if the session ID is present in storage. If the session ID is *not* found, the device drops the received packet. This ensures that only packets from previously established and known streams are decompressed, mitigating potential errors or security vulnerabilities.
15. The device according to claim 11 , wherein the processing module is configured, if the compression identifier signals a partially compressed header, to store in said storage module the information relating to the stream of that header, then to trigger a first time-delay relating to that stream before reconstructing the original IP header from the partially compressed header.
The decompression device (as described in Claim 11) handles partially compressed headers by storing associated stream information. Subsequently, the device initiates a time delay specific to that stream before attempting to reconstruct the original IP header. This helps manage state and allows for potential subsequent compressed headers from the same stream.
16. The device according to claim 11 , wherein said processing module is configured, if the compression identifier signals a compressed header, to reset to zero (reactivate) the first time-delay associated with the stream of that header, before reconstructing the original header from corresponding information stored in said storage module and designated by the session identifier contained in the received compressed header.
The decompression device (as described in Claim 11) handles compressed headers by resetting (reactivating) a time delay associated with the stream. Then it reconstructs the original header using stored information identified by the session ID. This mechanism keeps stream contexts alive and optimizes the decompression process for recurring compressed streams.
17. A communication equipment comprising a transmission end point in an Internet Protocol communication network, wherein the communication equipment comprises a compression device and/or a decompression device according to claim 11 .
A communication device (e.g., a satellite terminal) in an Internet Protocol communication network comprises either the compression device described in Claim 11 or a decompression device described in Claim 11, or both. This integration enables efficient data transmission by compressing and decompressing packet headers.
18. The communication equipment according to claim 17 , wherein the communication equipment is chosen in a group comprising at least a satellite terminal and a satellite gateway.
The communication equipment as outlined in Claim 17 can be implemented in devices such as satellite terminals or satellite gateways. These network elements utilize the compression/decompression capabilities to enhance data throughput and resource utilization.
19. A device for compression of streams of packets of data, for a communication equipment comprising a transmission end point in an Internet Protocol (IP) communication network, said packets of a stream each comprising an uncompressed IP header including a destination end point identifier, a session identifier and stream attributes, and a transport protocol header, and said packets to be transmitted after segmentation into cells, the device comprising: a processing module operative, in case of reception of a packet of a stream, to: determine if the IP header of said packet can be compressed as a function of at least one chosen criterion, then if so, to determine if said compression can lead to a reduction in the number of cells having to result from the decomposition of said packet, and if so, to replace in said packet at least said IP header by a compressed header comprising at least the session identifier and a compression identifier, after having transmitted beforehand to said destination end point of the received stream, in a partially compressed form, at least the IP header that has to be replaced, wherein the compression identifier signals a partially compressed header or a compressed header, wherein a partially compressed header comprises a number of bytes that is less than the number of bytes in a standard header; and in case of replacement of at least the IP header of a received packet by an at least partially compressed header, determine if the payload data associated with the at least partially compressed header can be compressed as a function of at least one chosen criterion, and if so, to integrate into the at least partially compressed header an identifier signaling the data compression.
A compression device for Internet Protocol (IP) networks compresses data packets sent from a communication device acting as a transmission endpoint. Each packet includes an uncompressed IP header (containing destination, session ID, and stream attributes), and a transport protocol header. The device determines if the IP header can be compressed based on criteria. If compression reduces the number of resulting cells after packet decomposition, the IP header is replaced with a compressed header containing the session ID and a compression identifier. The compression identifier signals if the header is partially compressed (fewer bytes than a standard header) or fully compressed. Before replacing, the original IP header is sent in a partially compressed form to the destination endpoint. Finally, the device determines if the associated payload can be compressed and signals payload compression in the compressed header.
Unknown
November 11, 2014
Browse 5M+ US patents with plain-English claim translations and AI-generated analysis.