Source: https://patents.google.com/patent/US8897298B2/en
Timestamp: 2019-09-18 19:14:42
Document Index: 188797778

Matched Legal Cases: ['§119', 'Application No. 61', '§119', 'Application No. 61', 'arts 1116', 'arts 1118', 'arts 1116', 'arts 1116']

US8897298B2 - Systems and methods for compressing headers and payloads - Google Patents
Systems and methods for compressing headers and payloads Download PDF
US8897298B2
US8897298B2 US13/663,837 US201213663837A US8897298B2 US 8897298 B2 US8897298 B2 US 8897298B2 US 201213663837 A US201213663837 A US 201213663837A US 8897298 B2 US8897298 B2 US 8897298B2
US13/663,837
US20130107895A1 (en
2011-11-02 Priority to US201161554562P priority Critical
2012-06-06 Priority to US201261656403P priority
2012-10-30 Priority to US13/663,837 priority patent/US8897298B2/en
2013-05-02 Publication of US20130107895A1 publication Critical patent/US20130107895A1/en
2013-09-09 Assigned to QUALCOMM INCORPORATED reassignment QUALCOMM INCORPORATED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: WENTINK, MAARTEN MENZO
2014-11-25 Publication of US8897298B2 publication Critical patent/US8897298B2/en
Methods, devices, and computer program products for compressing packet headers and payloads are described herein. In one embodiment, a packet including a packet header and a packet payload is compressed in accordance with a compression map, and the compressed packet is transmitted. The compression map includes a run-length encoded data set identifying at least one data field of the packet header and the packet payload to compress. In another embodiment, a packet including a packet header and a packet payload is received and decompressed in accordance with a decompression map. The decompression map includes a run-length encoded data set identifying at least one data field of the packet header and the packet payload to decompress.
This application claims benefit under 35 U.S.C. §119(e) to U.S. Provisional Patent Application No. 61/554,562 entitled “SYSTEMS AND METHODS FOR COMPRESSING HEADERS AND PAYLOADS” filed on Nov. 2, 2011, the disclosure of which is hereby incorporated by reference in its entirety. This application additionally claims benefit under 35 U.S.C. §119(e) to U.S. Provisional Patent Application No. 61/656,403 entitled “SYSTEMS AND METHODS FOR COMPRESSING HEADERS AND PAYLOADS” filed on Jun. 6, 2012, the disclosure of which is hereby incorporated by reference in its entirety.
The present application relates generally to wireless communications, and more specifically to systems, methods, and devices for compressing packet headers and payloads.
The devices in a wireless network may transmit or receive information between each other. The information may take the form of packets transmitted from a source device (the transmitting device) to a destination device (the receiving device). Since each packet takes time and energy for the source device to transmit and for the destination device to receive, improved systems, methods, and devices for expediting the transmission and receipt of packets, as well as reducing power consumption, are desired.
The systems, methods, and devices of the invention each have several aspects, no single one of which is solely responsible for its desirable attributes. Without limiting the scope of this invention as expressed by the claims which follow, some features will now be discussed briefly. After considering this discussion, and particularly after reading the section entitled “Detailed Description” one will understand how the features of this invention provide advantages that include reduced packet transmission time and reduced power consumption in a wireless network.
One aspect of this disclosure is a method for wireless communication implemented in a wireless communication device. The method includes compressing a packet in accordance with a compression map. The packet includes a packet header and a packet payload. The compression map includes a run-length encoded data set identifying at least one data field of the packet header and the packet payload to compress. The method further includes transmitting the compressed packet.
Another aspect of this disclosure is a method for wireless communication implemented in a wireless communication device. The method includes receiving a packet comprising a packet header and a packet payload. The method further includes decompressing the packet in accordance with a decompression map. The decompression map includes a run-length encoded data set identifying at least one data field of the packet header and the packet payload to decompress.
In yet another aspect of this disclosure is an apparatus operable in a wireless communication system including a processor and a transmitter. The processor is configured to compress a packet in accordance with a compression map. The packet includes a packet header and a packet payload. The compression map includes a run-length encoded data set identifying at least one data field of the packet header and the packet payload to compress. The transmitter is configured to transmit the compressed packet.
Another aspect of this disclosure is an apparatus operable in a wireless communication system including a receiver and a processor. The receiver is configured to receive a packet comprising a packet header and a packet payload. The processor is configured to decompress the packet in accordance with a decompression map. The decompression map includes a run-length encoded data set identifying at least one data field of the packet header and the packet payload to decompress.
In yet another aspect of this disclosure is an apparatus operable in a wireless communication system comprising: means for compressing a packet in accordance with a compression map, the packet comprising a packet header and a packet payload, the compression map comprising a run-length encoded data set identifying at least one data field of the packet header and the packet payload to compress; and means for transmitting the compressed packet.
Another aspect of this disclosure is an apparatus operable in a wireless communication system comprising: means for receiving a packet comprising a packet header and a packet payload; and means for decompressing the packet in accordance with a decompression map, the decompression map comprising a run-length encoded data set identifying at least one data field of the packet header and the packet payload to decompress.
In yet another aspect of this disclosure is a non-transitory computer readable medium comprising instructions that when executed cause an apparatus to: compress a packet in accordance with a compression map, the packet comprising a packet header and a packet payload, the compression map comprising a run-length encoded data set identifying at least one data field of the packet header and the packet payload to compress; and transmit the compressed packet.
Another aspect of this disclosure is a non-transitory computer readable medium comprising instructions that when executed cause an apparatus to: receive a packet comprising a packet header and a packet payload; and decompress the packet in accordance with a decompression map, the decompression map comprising a run-length encoded data set identifying at least one data field of the packet header and the packet payload to decompress.
The methods, apparatus, and computer program products of the preceding paragraphs can include a combination of one or more of the following features: A packet may be compressed by excluding data of at least one data field identified by the compression map. A packet may be decompressed by determining stored data values for at least one data field identified by a decompression map. A compression map may direct compression of a data field when data of the data field of a first packet is the same as data of a corresponding data field of a second packet. A compression map may direct compression of a data field corresponding to a data field identified in a decompression map stored in a receiver configured to receive the compressed packet. A compression map may not direct compression of a first set of data fields of the packet payload, the first set of data fields comprising at least one checksum data field, a sequence number data field, and an acknowledgment number data field. A compression map may not direct compression of a second set of data fields of the packet header, the second set of data fields comprising a frame control data field, an address 1 data field, an address 2 data field, a sequence control data field, a counter-mode/cbc-mac protocol data field, a message integrity check data field, and a frame control sequence data field. A packet may comprise an aggregated media access control service data unit (A-MSDU), and the packet payload may comprise at least one A-MSDU subframe. It may be signaled or detected in a header of a compressed packet that at least one A-MSDU subframe in a payload of a compressed packet is compressed. It may be signaled or detected in an A-MSDU subframe of a compressed packet that the A-MSDU subframe is compressed. A payload of a compressed packet may comprise a decompression map identifying at least one MSDU subframe to decompress and at least one MSDU subframe not to decompress. A packet may comprise an aggregated media access control protocol data unit (A-MPDU), and the packet payload comprises at least one MPDU. It may be signaled or detected in a header of a compressed packet that at least one MPDU in a payload of the compressed packet is compressed. It may be signaled or detected in a MPDU of a compressed packet that the MPDU is compressed. A payload of a compressed packet may comprise a decompression map, the decompression map identifying at least one MPDU to decompress and at least one MPDU not to decompress and comprising a second run-length encoded data set identifying at least one data field of the header and payload of the compressed packet to decompress. A portion of a packet may be encrypted separately from compressing an unencrypted portion of the packet. A packet may be compressed prior to encrypting of a portion of the packet.
FIGS. 3A and 3B illustrate an example of a media access control protocol data unit (MPDU) with IPv4 TCP Ack (MPDU IPv4 packet).
FIGS. 4A and 4B illustrate an example of a media access control protocol data unit with IPv6 TCP Ack (MPDU IPv6 packet).
FIGS. 5A and 5B illustrate an example of a compressed MPDU IPv4 packet header and payload in accordance with an exemplary embodiment.
FIGS. 6A and 6B illustrate an example of a compressed MPDU IPv6 packet header and payload in accordance with an exemplary embodiment.
FIG. 7 illustrates run-length encodings of a MPDU IPv4 packet payload compression and a MPDU IPv6 packet payload compression, according to an exemplary embodiment.
FIG. 8 illustrates an exemplary set compression frame in accordance with an embodiment.
FIG. 9 illustrates an exemplary compression map in the form of run-length encoding.
FIG. 10 illustrates an exemplary set compression action frame in accordance with an embodiment.
FIG. 11 illustrates an example MPDU that contains an aggregated media access control service data unit (A-MSDU).
FIGS. 12A and 12B illustrate contents of example compression run-length encoding fields.
FIG. 13 illustrates another example MPDU that contains an A-MSDU.
FIG. 14 illustrates an example aggregated MPDU (A-MPDU).
FIG. 15 illustrates example communications in a wireless communication system.
FIG. 16 illustrates example communications in a wireless communication system.
FIG. 17 illustrates example communications in a wireless communication system.
FIG. 18 illustrates example communications in a wireless communication system.
FIG. 19 is flowchart of an exemplary process of compressing and transmitting a packet header and payload in accordance with an exemplary embodiment.
FIG. 20 is a functional block diagram of an exemplary wireless device that may be employed within the wireless communication system of FIG. 1.
FIG. 21 is flowchart of an exemplary process of receiving and decompressing a packet header and payload in accordance with an exemplary embodiment.
FIG. 22 is a functional block diagram of another exemplary wireless device that may be employed within the wireless communication system of FIG. 1.
The transmitter 210 may be configured to wirelessly transmit packets, which may include header and payload information as discussed below. For example, the transmitter 210 may be configured to transmit packets generated by the processor 204, discussed above.
The receiver 212 may be configured to wirelessly receive packets and process the packets.
As discussed above, the wireless device 202 may comprise an AP 104 or an STA 106, and may be used to transmit and/or receive data.
Described herein are systems, methods, and devices for reducing the amount of header and payload information transmitted from a source device, such as the wireless device 202 t, to a destination device, such as the wireless device 202 r. Certain aspects are described herein with respect to media access control (MAC) headers and payloads. However, the aspects described are not limited to MAC headers and can equally be applied to other appropriate types of headers and packets.
FIG. 3A illustrates an example of a media access control protocol data unit (MPDU) with IPv4 TCP Ack packet (MPDU IPv4 packet) 300, includes a 3-address MAC header using counter-mode with cipher block chaining message authentication code protocol (CCMP) encryption. As shown, the MPDU IPv4 packet 300 includes 11 different fields: a frame control (fc) field 302, a duration/identification (dur) field 304, a receiver address or address 1 (a1) field 306, a transmitter address or address 2 (a2) field 308, a destination address or address 3 (a3) field 310, a sequence control (sc) field 312, a quality of service (QoS) control (qc) field 314, a counter-mode/cbc-mac protocol (ccmp) field 316, a packet payload (payload) field 318, a message integrity check (mic) field 320, and a frame control sequence (fcs) field 322. FIG. 3A further indicates the size in octets of each of the fields 302-322. Summing the size of all of the fields gives the overall size of the MPDU IPv4 packet 300, which is 94 octets. Although not noted in FIG. 3A, the frame control field 302 may further include a frame type field and a frame subtype field, among other fields.
FIG. 3B illustrates an example of the fields that may be included in the payload field 318 of the MPDU IPv4 packet 300. As shown, the payload field 318 includes 19 different fields: a logical link control (llc)/sub-network access protocol (snap) field 352, a version (ver)/internet header length (ihl) field 354, a type of service (tos) field 356, a total length (tlen) field 358, an identification (id) field 360, a flags/fragment offset (fo) field 362, a time to live (ttl) field 364, a protocol (prot) field 366, a checksum (check) field 368, a source address (sa) field 370, a destination address (da) field 372, a source port (sp) field 374, destination port (dp) field 376, a sequence number (sn) field 378, an acknowledgement number (an) field 380, a length (len)/flags field 382, a window size (ws) field 384, a checksum (check) 386, and an urgent (urg) field 388. FIG. 3B further indicates that fields 352-372 comprise the IPv4 portion of the payload field 318 while fields 374-388 comprise the TCP portion of the payload field 318. Additionally, FIG. 3B indicates the size in octets of each of the fields 352-388. Summing the size of all of the fields gives the overall size of the payload field 318, which is 48 octets.
Systems and methods for processing MAC headers and payloads of reduced size (compressed MAC headers and payloads) are described herein. The use of such compressed MAC headers and payloads permit less data to be transmitted overall. Less transmission of data can increase the speed with which data is transmitted, reduce the use of bandwidth by a transmitter, and reduce the power needed for transmission as fewer resources are used to transmit less data.
Compression of MAC headers or payloads may be performed by removing or modifying certain fields of the MAC header or payload. The compressed MAC header or payload may then be sent from the wireless device 202 t to the wireless device 202 r. Removal or modification of the fields may be based on the information to be communicated to the wireless device 202 r. For example, the wireless device 202 r may not use information in each field of the MPDU IPv4 packet 300 to receive and process the packet since some information may be redundant or superfluous to the wireless device 202 r. In some cases, the receiver may already have some information stored in memory that may have been transmitted in the MPDU IPv4 packet 300. Further, in one case, the wireless device 202 r may have received identical, matching, or corresponding information in one or more previously received packets from the wireless device 202 t, such as in the MAC header and payload of the previous packet. In another case, the wireless device 202 r may have such information pre-programmed, such as at the time of manufacture or through communication with another device.
In some embodiments, the wireless device 202 t may signal whether a packet has been compressed by placing a specific value in the frame type field or frame subtype field of the frame control field 302. The wireless device 202 r may determine whether the MAC header or packet is compressed based on the value of the frame type field or frame subtype field. In yet other embodiments, compression of a header and packet may be signaled using other fields or methods.
FIG. 4A illustrates an example of a MPDU with IPv6 TCP Ack packet (MPDU IPv6 packet) 400, includes a 3-address MAC header using counter-mode with cipher block chaining message authentication code protocol (CCMP) encryption. As shown, the MPDU IPv6 packet 400 includes 11 different fields: a frame control (fc) field 402, a duration/identification (dur) field 404, a receiver address or address 1 (a1) field 406, a transmitter address or address 2 (a2) field 408, a destination address or address 3 (a3) field 410, a sequence control (sc) field 412, a quality of service (QoS) control (qc) field 414, a counter-mode/cbc-mac protocol (ccmp) field 416, a packet payload (payload) field 418, a message integrity check (mic) field 420, and a frame control sequence (fcs) field 422. FIG. 4A further indicates the size in octets of each of the fields 402-422. Summing the size of all of the fields gives the overall size of the MPDU IPv6 packet 400, which is 114 octets. Although not noted in FIG. 4A, the frame control field 402 may further comprise a frame type field and a frame subtype field, among other fields.
FIG. 4B illustrates an example of the fields that may be included in the payload field 418 of the MPDU IPv6 packet 400. As shown, the payload field 418 includes 17 different fields: a logical link control (llc)/sub-network access protocol (snap) field 452, a version (ver) field 454, a traffic class (tc) field 456, a flow label (fl) field 458, a length (len) field 460, a next header (nh) field 462, a hop limit (hl) field 464, a source address (sa) field 466, a destination address (da) field 468, a source port (sp) field 470, a destination port (dp) field 472, a sequence number (sn) field 474, an acknowledgement number (an) field 476, a length (len)/flags field 478, a window size (ws) field 480, a checksum (check) 482, and an urgent (urg) field 484. FIG. 4B further indicates that fields 452-468 comprise the IPv6 portion of the payload field 418 while fields 370-384 comprise the TCP portion of the payload field 418. Additionally, FIG. 4B indicates the size in octets of each of the fields 452-484. Summing the value of all of the field sizes gives the overall size of the payload field 418, which is 68 octets.
Compression of MAC headers or payloads may be performed by removing or modifying certain fields of the MAC header or payload. The compressed MAC header or payload may then be sent from the wireless device 202 t to the wireless device 202 r. Removal or modification of the fields may be based on the information to be communicated to the wireless device 202 r. For example, the wireless device 202 r may not use information in each field of the MPDU IPv6 packet 400 to receive and process the packet since some information may be redundant or superfluous to the wireless device 202 r. In some cases the receiver may already have some information stored in memory that may have been transmitted in the MPDU IPv6 packet 400. Further, in one case, the wireless device 202 r may have received identical, matching, or corresponding information in one or more previously received packets from the wireless device 202 t, such as in the MAC header and payload of the previous packet. In another case, the wireless device 202 r may have such information pre-programmed, such as at the time of manufacture or through communication with another device.
In some embodiments, the wireless device 202 t may signal whether a packet has been compressed by placing a specific value in the frame type field or frame subtype field of the frame control field 402. The wireless device 202 r may determine the whether the MAC header or packet is compressed based on the value of the frame type field or frame subtype field. In yet other embodiments, compression of a header and packet may be signaled using other fields or methods.
FIG. 5A illustrates an example of a compressed MPDU IPv4 packet header and payload in accordance with an exemplary embodiment. The duration/identification (dur) field, address 3 (a3) field, quality of service control (qc) field, and payload field are compressed in whole or in part. In some aspects, the duration/identification (dur) field, address 3 (a3) field, and quality of service control (qc) field or data contents of those fields are completely removed by compression and may not be transmitted by the wireless device 202 t. The payload field is compressed in part so that 12 octets of the original 48 octets may be transmitted by the wireless device 202 t. The total size in octets of the transmitted compressed MPDU IPv4 packet equals 48 octets. In some aspects, compression may signify that a data field of a packet was removed, suppressed, or erased so that the data field may not be transmitted by the wireless device 202 t. In addition, compression may signify that data contents of one or more fields of a packet are excluded from inclusion in the packet or a compressed packet obtained by compressing the packet. The compression process may further be reversed by decompression and the original packet may be obtained from the compressed packet, for example, using stored data values to populate the compressed fields.
FIG. 5B further details payload fields of a MPDU IPv4 packet may be compressed in accordance with an exemplary embodiment. After compression, only the checksum (check) field, sequence number (sn) field, acknowledgement number (an) field, and checksum (check) field or data contents of those fields of the TCP portion of the payload may be included and transmitted by the wireless device 202 t. The total size in octets of the transmitted compressed MPDU IPv4 packet payload equals 12 octets. The compression process may further be reversed by decompression and the original packet may be obtained from the compressed packet, for example, using stored data values to populate the compressed fields.
FIG. 6A illustrates an example of a compressed MPDU IPv6 packet header and payload in accordance with an exemplary embodiment. The duration/identification (dur) field, address 3 (a3) field, quality of service control (qc) field, and payload field are compressed in whole or in part. In some aspects, the duration/identification (dur) field, address 3 (a3) field, and quality of service control (qc) field or data contents of those fields are completely removed by compression and may not be transmitted by the wireless device 202 t. The payload field is compressed in part so that 10 octets of the original 68 octets may be transmitted by the wireless device 202 t. The total size in octets of the transmitted compressed MPDU IPv6 packet equals 46 octets. In some aspects, compression may signify that a data field of a packet was removed, suppressed, or erased so that the data field may not be transmitted by the wireless device 202 t. In addition, compression may signify that data contents of one or more fields of a packet are excluded from inclusion in the packet or a compressed packet obtained by compressing the packet. The compression process may further be reversed by decompression and the original packet may be obtained from the compressed packet, for example, using stored data values to populate the compressed fields.
FIG. 6B further details payload fields of a MPDU IPv6 packet may be compressed in accordance with an exemplary embodiment. After compression, only the sequence number (sn) field, acknowledgement number (an) field, and checksum (check) field or data contents of those fields of the TCP portion of the payload may be included and transmitted by the wireless device 202 t. The total size in octets of the transmitted compressed MPDU IPv6 packet payload equals 10 octets. The compression process may further be reversed by decompression and the original packet may be obtained from the compressed packet, for example, using stored data values to populate the compressed fields.
FIG. 7 illustrates run-length encodings of a MPDU IPv4 packet payload compression and a MPDU IPv6 packet payload compression, according to an exemplary embodiment. Run-length encoding may be a form of data compression where runs of data are stored as a data value and count. In some aspects, the payload compression run-length encoding is expressed in terms of a data set that includes a number of consecutive octets that are alternately compressed and not compressed. Although examples such as FIG. 7 in this disclosure are described in terms of compressed or not compressed, the coding may apply and be understood in terms of decompression, such as to decompress or not to decompress. Accordingly, compression maps and decompression maps may be used to perform compression or decompression, depending on the process performed by a device.
The example MPDU IPv4 packet payload compression begins with compressing the first 18 octets of the MPDU IPv4 packet payload. Second, the following 2 octets of the MPDU IPv4 packet payload are not compressed. Third, the next 12 octets of the MPDU IPv4 packet payload are compressed. Fourth, the following 8 octets of the MPDU IPv4 packet payload are not compressed. Fifth, the next 4 octets of the MPDU IPv4 packet payload are compressed. Sixth, the following 2 octets of the MPDU IPv4 packet payload are not compressed. Seventh, the next 2 octets of the MPDU IPv4 packet payload are compressed. In some aspects, after the final compressed 2 octets, any number of additional payload octets that are not compressed may follow.
The example MPDU IPv6 packet payload compression begins with compressing the first 52 octets of the MPDU IPv6 packet payload. Second, the following 8 octets of the MPDU IPv6 packet payload are not compressed. Third, the next 4 octets of the MPDU IPv6 packet payload are compressed. Fourth, the following 2 octets of the MPDU IPv6 packet payload are not compressed. Fifth, the next 2 octets of the MPDU IPv6 packet payload are compressed. In some embodiments, after the final compressed 2 octets, any number of additional payload octets that are not compressed may follow.
FIG. 8 illustrates an exemplary set compression frame in accordance with an embodiment. A set compression frame may also be known as a management frame or a management action frame. The compressed parts of a packet payload and values of compressed parts may be programmed at a wireless device 202 r through a set compression frame as shown in FIG. 8. The MPDU packet payload values may be programmed with the values of the compressed fields of an initial, example, or representative MPDU packet header.
In FIG. 8, the frame control (fc) field, duration/identification (dur) field, address 1 (a1) field, address 2 (a2) field, address 3 (a3) field, sequence control (sc) field, and frame control sequence (fcs) field may be the MPDU packet header fields of a management frame. The a3 value field may specify the value of the address 3 field of the compressed MPDU packet header. The qc value field may specify the value of the quality of service control (qc) field of the compressed MPDU packet header. The compression map field may specify which fields of the MPDU payload are compressed and not compressed. In some embodiments, the formatting of the compression map field may be a run-length encoded data set as shown in FIG. 7. In yet other embodiments, the compression map field may be formatted or encoded using another approach. The compressed parts values field may specify the values of the compressed parts of the MPDU packet payload. The length of the compressed parts values field may equal the total of the compressed parts or data contents from the compression map field. In the example discussed next in FIG. 9, the total length of the compressed parts values field is 36 octets.
FIG. 9 illustrates an exemplary compression map in the form of a run-length encoded data set. The compression map shown in FIG. 9 corresponds in part to the MPDU IPv4 packet payload compression shown in FIG. 7. In some aspects, a compression map may refer to a data set identifying one or more data fields of a packet to compress. Although the example of FIG. 9 is described in terms of compressed and not compressed parts for a compression map, the coding scheme may apply also and be used with a decompression map, which may include a run-length encoded data set identifying one or more data fields of the packet to decompress or not decompress. Moreover, although compression maps may be used as examples throughout in this disclosure, the same or similar principles may apply to decompression maps, which may be compression maps used by the wireless device 202 r to determine which fields of a packet to decompress or not decompress.
In FIG. 9, the first value signifies the total number of compressed or not compressed parts to follow, which in this instance is 7 compressed or not compressed parts. The next value, 18, signifies the number of first compressed octets of the MPDU IPv4 packet payload. The following 2 value signifies that the following 2 octets of the MPDU IPv4 packet payload are not compressed. The next 12 value signifies that the next 12 octets of the MPDU IPv4 packet payload are compressed. The following 8 value signifies that the following 8 octets of the MPDU IPv4 packet payload are not compressed. The next 4 value signifies that the next 4 octets of the MPDU IPv4 packet payload are compressed. The following 2 value signifies that the following 2 octets of the MPDU IPv4 packet payload are not compressed. The next 2 value signifies that the next 2 octets of the MPDU IPv4 packet payload are compressed.
In some aspects, each value in the compression map may be one octet in length, meaning that the compressed parts or not compressed parts of the compression map may have a maximum length of 255 octets. Accordingly, the first octet of the compression map may have a maximum of 255 parts that may be specified.
FIG. 10 illustrates an exemplary set compression action frame that may be used to program a wireless device 202 r. As shown in FIG. 10, the compression map field and compressed parts values field may be included in an information element before being included in a set compression frame. Consequently, an element identifier field and a length field may be added to the set compression frame, and the length subfield of the compression map field may be omitted.
In FIG. 10, the frame control (fc) field, duration/identification (dur) field, address 1 (a1) field, address 2 (a2) field, address 3 (a3) field, sequence control (sc) field, and frame control sequence (fcs) field may be the MPDU packet header fields of a management frame. The category field and action field may specify the value for compression action and set compression, respectively. The first element id field may specify the value of the address 3 field and quality of service control (qc) field of the compressed MPDU packet header. The first length field in this case may be 8 octets. The a3 value field may specify the value of the address 3 field of the compressed MPDU packet header. The qc value field may specify the value of the quality of service control (qc) field of the compressed MPDU packet header.
Further, the second element id field may specify the compression map and the compressed parts values. The second length field in this case may be 44 octets. The compression map field may specify which fields of the MPDU payload are compressed and not compressed. In some embodiments, the formatting of the compression map field may be a run-length encoded data set as shown in FIG. 9. In yet other embodiments, the compression map field may be formatted or encoded using another encoding or approach. The compressed parts values field may specify the values of the compressed parts or data contents of one or more fields of the MPDU packet payload before compression.
FIG. 11 illustrates an example MPDU 1100 that contains an aggregated media access control service data unit (A-MSDU). The MPDU 1100 includes a MPDU header field 1102, a counter-mode/cbc-mac protocol (CCMP) field 1104, n number of A-MSDU subframe fields 1106, a message integrity check (MIC) field 1108, and a frame control sequence (FCS) field 1110. Each A-MSDU subframe of the n A-MSDU subframes includes an A-MSDU subframe header field, such as A-MSDU subframe header field 1112, and a compressed payload field, such as compressed payload field 1114. Further, each compressed payload field, such as compressed payload field 1114, may include a transmitted payload with compressed parts portion (e.g., transmitted payload with compressed parts 1116) and without compressed parts portion (e.g., transmitted payload without compressed parts 1118).
Since each of the n A-MSDU subframes of the MPDU 1100 may be compressed in accordance with the teachings of this disclosure, the teachings of this disclosure may enable compression of the MPDU 1100 that contains the A-MSDU as well. Additionally, the parts for each A-MSDU subframe in the MPDU 1100 that are not compressed may vary per A-MSDU subframe, providing additional compression and data transmission flexibility.
In some aspects, the MPDU header 1102 may indicate that the MPDU 1100 contains an A-MSDU. Further, the MPDU header 1102 may indicate that the MPDU 1100 is a protected frame so that, for example, the n A-MSDU subframe fields 1106 and the MIC field 1108 may be encrypted. In some aspects, the CCMP field 1104 or MIC 1108 field may be excluded from the MPDU 1100.
The compressed payload 1114 may include an individual MSDU, and the transmitted payload with compressed parts 1116 of the compressed payload 1114 may include a compressed portion of the individual MSDU. In one example, the transmitted payload with compressed parts 1116 may include a run-length encoded data set for an IPv4 TCP Ack packet payload compression as discussed in this disclosure (e.g., 18 octets compressed, 2 octets transmitted, 12 octets compresses, 8 octets transmitted, 4 octets compressed, 2 octets transmitted, 2 octets compressed).
In one aspect, the MPDU header 1102 may include a compression map and/or compressed parts values for compression or decompression of one or more of the n A-MSDU subframes included in the MPDU 1100. The MPDU header 1102 may also contain an indication of which A-MSDU subframes are compressed. A transmitting device, such as wireless device 202 t, may use the compression map and/or compressed parts values in the MPDU header 1102 to compress the one or more n A-MSDU subframes. A receiving device, such as wireless device 202 r, may use the compression map and/or compressed parts values in the MPDU header 1102 to decompress the one or more n A-MSDU subframes.
In one aspect, a compression bit may be added to an A-MSDU subframe header, such as A-MSDU subframe header 1112. The compression bit may indicate that the A-MSDU subframe is compressed or not compressed. A transmitting device, such as wireless device 202 t, may use the compression bit to determine whether to compress the A-MSDU subframe. A receiving device, such as wireless device 202 r, may use the compression bit to determine whether to decompress the A-MSDU subframe.
In some aspects, one or more MPDU, such as MPDU 1100, may be aggregated to produce an aggregated MPDU (A-MPDU). Since the MPDU frames of an A-MPDU may be compressed in accordance with the teachings of this disclosure, the teachings of this disclosure may enable compression of the A-MPDU that contains compressed MPDU frames.
FIG. 12A illustrates contents of an example compression run-length encoding field 1200. The compression run-length encoding field 1200 may be a compression map include a length (len) field 1202, a compress field 1204, a transmit field 1206, a series of repeating compressed and not compressed fields, and a pad field 1208. The length field 1202 may be 4 bits in size, the compressed and not compressed fields may be 6 bits in size, and the pad field may be 2 bits in size. Accordingly, the total size of the compression run-length encoding field 1200 may be 96 bits or 12 octets as indicated at total 1210.
FIG. 12B illustrates contents of an example compression run-length encoding field 1250 for an IPv4 TCP Ack packet. The compression run-length encoding field 1250 may be a compression map and include a length (len) field 1252, a compressed field 1254, a not compressed field 1256, a series of repeating compressed and not compressed fields, and a pad field 1258. The length field 1252 may be 4 bits in size, the compressed and not compressed fields may be 6 bits in size, and the pad field may be 2 bits in size. The compression run-length encoding field 1250 may store the compression run-length encoding for the IPv4 TPC Ack packet as follows: the length field 1252 stores the value 7, the compressed field 1254 stores the value 18, the not compressed field 1256 stores the value 2, the following compressed and not compressed fields store the values 12, 8, 4, 2, 2, as shown in FIG. 12B. Accordingly, the total size of the compression run-length encoding field 1250 may be 48 bits or 6 octets as indicated at total 1260, and 12 octets may be not compressed and 36 octets may be compressed.
FIG. 13 illustrates another example MPDU 1300 that contains an A-MSDU. The MPDU 1300 includes a MPDU header field (MAC header) 1302, a counter-mode/cbc-mac protocol (CCMP) field 1304, a compression run-length encoding field 1306, an A-MSDU subframe 1 field 1308, nine other A-MSDU subframe fields 1310, a message integrity check (MIC) field 1312, and a frame control sequence (FCS) field 1314. The MPDU header field 1302, the CCMP field 1304, the MIC field 1312, and the FCS field 1314 may serve similar functions as the MPDU header field 1102, the CCMP field 1104, the MIC field 1108, and the FCS field 1110, respectively, of FIG. 11.
The compression run-length encoding field 1306 may include data such as the values of the compression run-length encoding fields 1200 or 1250 of FIGS. 12A and 12B. Further, the fields of the compression run-length encoding field 1306 may correspond to the fields of the A-MSDU subframe 1 field 1308 such that the compression run-length encoding field 1306 and the A-MSDU subframe 1 field 1308 in combination indicate which fields of the nine other A-MSDU subframe fields 1310 may be compressed. For example, the A-MSDU subframe 1 field 1308 may include a payload that is not compressed. The nine other A-MSDU subframes fields 1310 may include a compressed payload. Using the compression run-length encoding field 1306 and the A-MSDU subframe 1 field 1308, a wireless device may determine the data contents of the compressed fields for the nine other A-MSDU subframes fields 1310.
Advantageously, given this design, the MPDU 1300 may include information necessary to determine a compression map and/or compressed parts values, so the wireless device 202 t may compress the MPDU 1300 or the wireless device 202 r may decompress the MPDU 1300.
In some aspects, one or more MPDU, such as MPDU 1300, may be aggregated to produce an A-MPDU. Since the MPDU frames of an A-MPDU may be compressed in accordance with the teachings of this disclosure, the teachings of this disclosure may enable compression of the A-MPDU that contains the compressed MPDU frames.
FIG. 14 illustrates an example A-MPDU 1400. The A-MPDU 1400 may include a physical (PHY) header field 1402, a MPDU delimiter 1404, a compression run-length encoding field 1406, a second MPDU delimiter, a MPDU 2 field 1408, a third MPDU delimiter, a MPDU 3 field 1410, and a series of additional MPDU delimiters and MPDUs.
The compression run-length encoding field 1406 may include data such as the values of the compression run-length encoding fields 1200 or 1250 of FIGS. 12A and 12B. Further, the fields of the compression run-length encoding field 1406 may correspond to the fields of the MPDU 2 field 1408 such that the compression run-length encoding field 1406 and the MPDU 2 field 1408 in combination indicate which fields of the eight other MPDU fields, such as MPDU 3 field 1410, may be compressed. For example, the MPDU 2 field 1408 may include a payload that is not compressed. The eight other MPDU fields, including MPDU 3 field 1410, may include a compressed payload. Using the compression run-length encoding field 1406 and the MPDU 2 field 1408, a wireless device may determine the data contents of the compressed fields for the eight other MPDU fields.
Advantageously, given this design, the A-MPDU 1400 may include information necessary to determine a compression map and/or compressed parts values, so the wireless device 202 t may compress the A-MPDU 1400 or the wireless device 202 r may decompress the A-MPDU 1400.
FIG. 15 illustrates example communications 1500 in a wireless communication system. The communications 1500 may be by a STA1 and a STA2. The top line illustrates communications by the STA1, and the bottom line illustrates communications by the STA2. Time increases horizontally across the page to the right.
At block 1502, the STA1 transmits a reverse direction grant (RDG) to STA2. The reverse direction grant may grant the STA2 the opportunity to transmit data with a certain period of time. Further, the reverse direction grant may mean that the MPDU or MPDUs transmitted may have a RDG/More PPDU subfield equal to 1.
A short interface space (SIFS) time later at block 1504, the STA2 may transmit an acknowledgement (ACK) to STA1. A second SIFS time later at block 1506, the STA2 may transmit a multiple user (MU) transmission to STA1, STA4, and STA5. The transmitted MPDU or MPDUs to STA1 may carry an implicit block acknowledgment request (BAR) acknowledgment policy and the RDG/More PPDU subfield may equal to 1. The MPDU or MPDUs to STA4 and STA5 may carry a block acknowledgment policy.
FIG. 16 illustrates example communications 1600 in a wireless communication system. The communications 1600 may be by a STA1 and a STA2. The top line illustrates communications by the STA1, and the bottom line illustrates communications by the STA2. Time increases horizontally across the page to the right.
At block 1602, the STA1 transmits a reverse direction grant to STA2. The reverse direction grant may grant the STA2 the opportunity to transmit data with a certain period of time. Further, the reverse direction grant may mean that the MPDU or MPDUs transmitted may have a RDG/More PPDU subfield equal to 1.
A SIFS time later at block 1604, the STA2 may transmit an acknowledgement to STA1. A second SIFS time later at block 1606, the STA2 may transmit a multiple user transmission to STA3, STA4, and STA5. The MPDU or MPDUs to STA3, STA4, and STA5 may carry a block acknowledgment acknowledgment policy. A third SIFS time later at block 1608, the STA2 may transmit a block acknowledgment request to STA1. A fourth SIFS time later at block 1610, the STA1 may transmit a block acknowledgment in response to STA2.
FIG. 17 illustrates example communications 1700 in a wireless communication system. The communications 1700 may be by a STA1 and a STA2. The top line illustrates communications by the STA1, and the bottom line illustrates communications by the STA2. Time increases horizontally across the page to the right.
At block 1702, the STA1 transmits a reverse direction grant to STA2. The reverse direction grant may grant the STA2 the opportunity to transmit data with a certain period of time. Further, the reverse direction grant may mean that the MPDU or MPDUs transmitted may have a RDG/More PPDU subfield equal to 1.
A SIFS time later at block 1704, the STA2 may transmit an acknowledgement to STA1. A second SIFS time later at block 1706, the STA2 may transmit a multiple user transmission to STA3, STA4, and STA5. The MPDU or MPDUs to STA3, STA4, and STA5 may carry a block acknowledgment acknowledgment policy. A PCF interframe space (PIFS) time later at block 1708, the STA 1 may transmit data to STAG.
FIG. 18 illustrates example communications 1800 in a wireless communication system. The communications 1800 may be by a STA1 and a STA2. The top line illustrates communications by the STA1, and the bottom line illustrates communications by the STA2. Time increases horizontally across the page to the right.
At block 1802, the STA1 transmits a reverse direction grant to STA2. The reverse direction grant may grant the STA2 the opportunity to transmit data with a certain period of time. Further, the reverse direction grant may mean that the MPDU or MPDUs transmitted may have a RDG/More PPDU subfield equal to 1.
A SIFS time later at block 1804, the STA2 may transmit an acknowledgement to STA1. A second SIFS time later at block 1806, the STA2 may transmit via a direct link transmission to STA3 (e.g., STA2 and STA3 may be connected via a TDLS direct link). The MPDU or MPDUs to STA3 may carry a block acknowledgment policy. A third SIFS time later at block 1808, the STA2 may transmit a block acknowledgment request to STA1. A fourth SIFS time later at block 1810, the STA1 may transmit a block acknowledgment in response to STA2.
FIG. 19 is flowchart of an exemplary method 1900 of compressing and transmitting a packet header and payload in accordance with an embodiment. The method 1900 may be used to transmit a packet header and payload compressed as discussed regarding in FIGS. 5A, 5B, 6A, 6B, 11, 13, and 14, for example. The packet may be generated at either the AP 104 or the STA 106 and transmitted to another node in the wireless network 100. Although the method 1900 is described below with respect to the elements of the wireless device 202 t, other components may be used to implement one or more of the steps described herein.
At block 1905, the packet header and payload are compressed in accordance with a compression map to obtain a compressed packet. The compression map may include a run-length encoded data set identifying at least one data fields of the packet header or payload to compress. The compression may be performed by the processor 204 and/or the DSP 220, for example. In some embodiments, the packet payload may be compressed separately from the packet header.
At block 1910, the compressed packet is encrypted. In particular embodiments only the compressed packet payload is encrypted while the compressed packet payload remains unencrypted in others. Additionally, in some embodiments, the encrypted part of the packet may be compressed separately from the unencrypted part of the packet. Furthermore, in other embodiments, additional header fields may be added to the compressed packet, such as a ccmp field and a mic field. The encryption may be performed by the processor 204 and/or the DSP 220, for example.
At block 1915, the compressed packet is wirelessly transmitted. The transmission may be performed by the transmitter 210 of wireless device 202 t, for example.
FIG. 20 is a functional block diagram of an exemplary wireless device 2000 that may be employed within the wireless communication system of FIG. 1. The wireless device 2000 comprises a processing module 2005 for compressing a packet header or payload in accordance with a compression map. The processing module 2005 may be configured to perform one or more of the functions discussed above with respect to the blocks 1905 and 1910 of FIG. 19. The processing module 2005 may correspond to one or more of the processor 204 and the DSP 220. The wireless device 2000 further comprises a transmitting module 2010 for wirelessly transmitting the compressed packet. The transmitting module 2010 may be configured to perform one or more of the functions discussed above with respect to the block 1915 illustrated in FIG. 19. The transmitting module 2010 may correspond to the transmitter 210.
Moreover, in one aspect, means for compressing a packet in accordance with a compression map may comprise the processing module 2005. In yet another aspect, means for transmitting the compressed packet may comprise the transmitting module 2010.
In some wireless communication systems, the values in various fields of transmitted packet headers and payloads may be fixed from transmitted packet to transmitted packet. The processing module 2005 in particular embodiments may determine which fields contain values that are fixed and compress those fields before transmission. For example, the wireless device 202 t may compress fields corresponding to MAC addresses, IP addresses, and port numbers since the particular fields may be fixed when the wireless device 202 t and the wireless device 202 r are known to be in wireless communication.
In yet other embodiments, the processing module 2005 may verify whether a packet is eligible for compression. The processing module 2005 may verify that a set of compressed parts values are the same as the values in the packet. To make this determination, the processing module 2005 may perform an XOR operation of the compressible packet with the compressed parts values or data contents. If the determination is zero, the compressible parts of the packet are the same as the set compressed parts values, so the packet is eligible for compression. Furthermore, in some embodiments, the processing module 2005 may signal that a packet is compressed. For example, the processing module 2005 may place a particular value, which corresponds to a compressed packet, within the frame type field or the frame subtype field of the frame control field 302 or 402.
FIG. 21 is flowchart of an exemplary process 2100 of receiving and decompressing a packet header and payload in accordance with an exemplary embodiment. The method 2100 may be used to receive a packet header and payload compressed as discussed regarding FIGS. 5A, 5B, 6A, 6B, 11, 13, and 14, for example. The packet may be received at either the AP 104 or the STA 106 from another node in the wireless network 100. Although the method 2100 is described below with respect to the elements of the wireless device 202 r, other components may be used to implement one or more of the steps described herein.
At block 2105, a wireless communication comprising the encrypted, compressed packet is received. The reception may be performed by the receiver 212 of wireless device 202 r, for example.
At block 2110, the encrypted portions of the received packet are decrypted. The processing may be performed by the processor 204 and/or the DSP 220, for example.
At block 2115, the decrypted packet is decompressed in accordance with a decompression map. The decompression map may include a run-length encoded data set identifying at least one data field of the packet to decompress. After decompression, the obtained packet may be identical or correspond to the transmitted packet data before compression or encryption, for example, by determining and placing calculated or stored values for compressed data fields. In some embodiments, the packet payload may be decompressed separately from the packet header. The processing may be performed by the processor 204 and/or the DSP 220, for example.
At block 2120, the obtained packet is forwarded to the next protocol layer for further processing. The forwarding and processing may be performed by the processor 204 and/or the DSP 220, for example.
FIG. 22 is a functional block diagram of another exemplary wireless device 2200 that may be employed within the wireless communication system of FIG. 1. The device 2200 comprises a receiving module 2205 for wirelessly receiving a wireless communication comprising a compressed, encrypted packet. The receiving module 2205 may be configured to perform one or more of the functions discussed above with respect to the block 2105 illustrated in FIG. 21. The receiving module 2205 may correspond to the receiver 212. The wireless device 2200 further comprises a processing module 2210 for processing the received packet. The processing module 2210 may be configured to perform one or more of the functions described above with respect to the blocks 2110, 2115, and 2120 illustrated in FIG. 21. The processing module 2210 may correspond to one or more of the processor 204, signal detector 218, and the DSP 220.
Moreover, in one aspect, means for receiving a packet comprising a packet header and payload may comprise the receiving module 2205. In another aspect, means for decompressing the packet in accordance with a decompression map may comprise the processing module 2210. In yet another aspect, means for determining whether the packet is compressed may comprise the processing module 2210.
In one embodiment, the processing module 2210 may be pre-programmed with the decompression map and compressed parts values or data contents. The pre-programming may occur at the time of manufacture or through communication with another device. For example, the wireless device 202 t or wireless device 202 r may determine whether the data of corresponding data fields of two packets are the same to obtain the decompression map. In another case, the processing module 2210 may receive the decompression map and compressed parts values in a received data packet or packets from the wireless device 202 t.
In yet other embodiments, the processing module 2210 may determine whether a packet is compressed. Since some packets may be compressed while other packets may not, the processing module may advantageously first determine whether a packet is compressed before determining how to process the packet. The processing module 2210 may determine, for example, that the packet is compressed by evaluating a value within the frame type field or frame subtype field of the frame control field 302 or 402 of the packet.
1. A method for wireless communication implemented in a wireless communication device, the method comprising:
compressing a packet in accordance with a compression map, the packet comprising a packet header and a packet payload, the compression map comprising a run-length encoded data set identifying at least one data field of the packet header and the packet payload to compress and wherein compressing the packet further excluding data of at least one data field identified by the compression map; and
transmitting the compressed packet.
2. The method of claim 1, wherein the compression map directs compression of a data field when data of the data field of a first packet is the same as data of a corresponding data field of a second packet.
3. The method of claim 1, wherein the compression map directs compression of all data fields of the packet payload except at least one checksum data field, a sequence number data field, and an acknowledgment number data field.
4. The method of claim 1, wherein the compression map directs compression of all data fields of the packet header except a frame control data field, an address 1 data field, an address 2 data field, a sequence control data field, a counter-mode/cbc-mac protocol data field, a message integrity check data field, and a frame control sequence data field.
5. A method for wireless communication implemented in a wireless communication device, the method comprising:
receiving a packet comprising a packet header and a packet payload; and
decompressing the packet in accordance with a decompression map, the decompression map comprising a run-length encoded data set identifying at least one data field of the packet header and the packet payload to decompress and wherein decompressing the packet further excluding data of at least one data field identified by the decompression map.
6. The method of claim 5, wherein said decompressing the packet comprises determining stored data values for at least one data field identified by the decompression map.
7. The method of claim 6, wherein the decompression map directs decompression of a data field when data of the data field of a first packet is the same as data of a corresponding data field of a second packet.
8. The method of claim 6, wherein the decompression map directs decompression of all data fields of the packet payload except at least one checksum data field, a sequence number data field, and an acknowledgment number data field.
9. The method of claim 6, wherein the decompression map directs decompression of all data fields of the packet header except a frame control data field, an address 1 data field, an address 2 data field, a sequence control data field, a counter-mode/cbc-mac protocol data field, a message integrity check data field, and a frame control sequence data field.
10. An apparatus operable in a wireless communication system comprising:
a processor configured to compress a packet in accordance with a compression map, the packet comprising a packet header and a packet payload, the compression map comprising a run-length encoded data set identifying at least one data field of the packet header and the packet payload to compress and wherein compressing the packet further excluding data of at least one data field identified by the compression map; and
a transmitter configured to transmit the compressed packet.
11. The apparatus of claim 10, wherein the compression map directs compression of a data field when data of the data field of a first packet is the same as data of a corresponding data field of a second packet.
12. The apparatus of claim 10, wherein the compression map directs compression of a data field corresponding to a data field identified in a decompression map stored in a receiver configured to receive the compressed packet.
13. The apparatus of claim 10, wherein the compression map does not direct compression of a first set of data fields of the packet payload, the first set of data fields comprising at least one checksum data field, a sequence number data field, and an acknowledgment number data field.
14. The apparatus of claim 10, wherein the compression map does not direct compression of a second set of data fields of the packet header, the second set of data fields comprising a frame control data field, an address 1 data field, an address 2 data field, a sequence control data field, a counter-mode/cbc-mac protocol data field, a message integrity check data field, and a frame control sequence data field.
15. The apparatus of claim 10, wherein the packet comprises an aggregated media access control service data unit (A-MSDU), and the packet payload comprises at least one A-MSDU subframe.
16. The apparatus of claim 15, wherein the processor is further configured to signal in a header of the compressed packet that at least one A-MSDU subframe in a payload of the compressed packet is compressed.
17. The apparatus of claim 15, wherein the processor is further configured to signal in an A-MSDU subframe of the compressed packet that the A-MSDU subframe is compressed.
18. The apparatus of claim 15, wherein a payload of the compressed packet comprises a decompression map identifying at least one MSDU subframe to decompress and at least one MSDU subframe not to decompress.
19. The apparatus of claim 10, wherein the packet comprises an aggregated media access control protocol data unit (A-MPDU), and the packet payload comprises at least one MPDU.
20. The apparatus of claim 19, wherein the processor is further configured to signal in a header of the compressed packet that at least one MPDU in a payload of the compressed packet is compressed.
21. The apparatus of claim 19, wherein the processor is further configured to signal in a MPDU of the compressed packet that the MPDU is compressed.
22. The apparatus of claim 19, wherein a payload of the compressed packet comprises a decompression map, the decompression map identifying at least one MPDU to decompress and at least one MPDU not to decompress and comprising a second run-length encoded data set identifying at least one data field of the header and payload of the compressed packet to decompress.
23. The apparatus of claim 10, wherein the processor is further configured to compress an encrypted portion of the packet separately from compressing an unencrypted portion of the packet.
24. The apparatus of claim 10, wherein the processor is further configured to compress the packet prior to encrypting of a portion of the packet.
25. An apparatus operable in a wireless communication system comprising:
a receiver configured to receive a packet comprising a packet header and a packet payload; and
a processor configured to decompress the packet in accordance with a decompression map, the decompression map comprising a run-length encoded data set identifying at least one data field of the packet header and the packet payload to decompress and wherein decompressing the packet further excluding data of at least one data field identified by the decompression map.
26. The apparatus of claim 25, wherein the processor is configured to decompress the packet by determining stored data values for at least one data field identified by the decompression map.
27. The wireless apparatus of claim 25, wherein the decompression map does not direct decompression of a first set of data fields of the packet payload and a second set of data fields of the packet header, the first set of data fields comprising at least one checksum data fields, a sequence number data field, and an acknowledgment number data field, the second set of data fields comprising a frame control data field, an address 1 data field, an address 2 data field, a sequence control data field, a counter-mode/cbc-mac protocol data field, a message integrity check data field, and a frame control sequence data field.
the packet comprises an aggregated media access control service data unit (A-MSDU), the packet payload comprises one or more A-MSDU subframes and the decompression map, the decompression map identifying at least one MSDU subframe to decompress and at least one MSDU subframe not to decompress, and
the processor is further configured to detect a first signal in a first A-MSDU subframe of the packet that the first A-MSDU subframe is compressed or a second signal in the packet header that at least one A-MSDU subframe in the packet payload is compressed.
the packet comprises an aggregated media access control protocol data unit (A-MPDU), the packet payload comprises at least one MPDU and the decompression map, the decompression map identifying at least one MPDU to decompress and at least one MPDU not to decompress, and
the processor is further configured to detect a first signal in a first MPDU of the packet that the first MPDU is compressed or a second signal in the packet header that at least one MPDU in the packet payload is compressed.
30. An apparatus operable in a wireless communication system comprising:
means for compressing a packet in accordance with a compression map, the packet comprising a packet header and a packet payload, the compression map comprising a run-length encoded data set identifying at least one data field of the packet header and the packet payload to compress and wherein means for compressing the packet further excluding data of at least one data field identified by the compression map; and
means for transmitting the compressed packet.
31. An apparatus operable in a wireless communication system comprising:
means for receiving a packet comprising a packet header and a packet payload; and
means for decompressing the packet in accordance with a decompression map, the decompression map comprising a run-length encoded data set identifying at least one data field of the packet header and the packet payload to decompress and wherein means for decompressing the packet further excluding data of at least one data field identified by the decompression map.
32. A non-transitory computer readable medium comprising instructions that when executed cause an apparatus to:
compress a packet in accordance with a compression map, the packet comprising a packet header and a packet payload, the compression map comprising a run-length encoded data set identifying at least one data field of the packet header and the packet payload to compress and wherein compress the packet further exclude data of at least one data field identified by the compression map; and
transmit the compressed packet.
33. A non-transitory computer readable medium comprising instructions that when executed cause an apparatus to:
receive a packet comprising a packet header and a packet payload; and
decompress the packet in accordance with a decompression map, the decompression map comprising a run-length encoded data set identifying at least one data field of the packet header and the packet payload to decompress and wherein decompress the packet further exclude data of at least one data field identified by the decompression map.
US13/663,837 2011-11-02 2012-10-30 Systems and methods for compressing headers and payloads Active 2033-03-01 US8897298B2 (en)
US201161554562P true 2011-11-02 2011-11-02
US201261656403P true 2012-06-06 2012-06-06
US13/663,837 US8897298B2 (en) 2011-11-02 2012-10-30 Systems and methods for compressing headers and payloads
PCT/US2012/063271 WO2013067316A1 (en) 2011-11-02 2012-11-02 Systems and methods for compressing headers and payloads
US20130107895A1 US20130107895A1 (en) 2013-05-02
US8897298B2 true US8897298B2 (en) 2014-11-25
ID=48172398
US13/663,837 Active 2033-03-01 US8897298B2 (en) 2011-11-02 2012-10-30 Systems and methods for compressing headers and payloads
US (1) US8897298B2 (en)
WO (1) WO2013067316A1 (en)
EP3182677A4 (en) * 2014-08-10 2018-03-14 LG Electronics Inc. Method and device for enabling station to receive signal in wireless communication system
EP3275240A4 (en) * 2015-03-27 2018-11-07 Intel IP Corporation Mac header compression for high efficiency wlan
US10205660B2 (en) * 2015-06-03 2019-02-12 Avago Technologies International Sales Pte. Limited Apparatus and method for packet header compression
US20050083944A1 (en) 2003-10-17 2005-04-21 Nokia Corporation Compressing header data
EP2131501A1 (en) 2008-06-06 2009-12-09 Harman Becker Automotive Systems GmbH Data compression and decompression method and data processing apparatus
US8046496B1 (en) 2007-12-12 2011-10-25 Narus, Inc. System and method for network data compression
US8165165B2 (en) 2006-09-29 2012-04-24 Electronics And Telecommunications Research Institute Apparatus for dynamic header compression and method thereof
2012-10-30 US US13/663,837 patent/US8897298B2/en active Active
2012-11-02 WO PCT/US2012/063271 patent/WO2013067316A1/en active Application Filing
"Session Header Compression Scheme Using Differential Run-Length Encoding", IBM Technical Disclosure Bulletin, International Business Machines Corp, (Thornwood), US, vol. 40, No. 12, Dec. 1, 1997, p. 125/126, XP000754111.
International Search Report and Written Opinion-PCT/US2012/063271-ISA/EPO-Feb. 18, 2013.
International Search Report and Written Opinion—PCT/US2012/063271—ISA/EPO—Feb. 18, 2013.
US20130107895A1 (en) 2013-05-02
WO2013067316A1 (en) 2013-05-10
WO2005104442A2 (en) 2005-11-03 Packet concatenation in wireless networks
EP2870715A1 (en) 2015-05-13 Methods and apparatuses for transmission and reception of full beacons and compressed beacons
US20150092697A1 (en) 2015-04-02 Methods for determining information about a communication parameter and communication devices
EP2124494A2 (en) 2009-11-25 Method and related apparatus for performing status report procedure in a wireless communication system
KR101728038B1 (en) 2017-04-18 The apparatus and method for an improved frame
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:WENTINK, MAARTEN MENZO;REEL/FRAME:031165/0501