Method and system for efficient data transmission

Abstract

Embodiments of this disclosure relate to methods and systems for efficient data transmission. Examples described herein relate to methods for efficiently transmitting a first data unit including a first header and a second data unit including a second header. Both the first and second data units may belong to the same service session. A networking device may identify one or more candidate header fields that have similar information in both the first and second headers, and generate a compressed header by removing candidate header fields from the second header. The networking device then inserts an availability bitmap into the compressed header and replaces the second header in the second data unit with the compressed header. The availability bitmap indicates which header fields from the second header have been included in the compressed header. The networking device can then transmit the first data unit having its original header and the second data unit including the compressed header.

Description

Background Technology

[0001] In wireless local area networks (WLANs), communication between transmitting and receiving devices involves significant overhead due to the transmission of corresponding header control fields, inter-frame spacing requirements, and acknowledgment processing for transmitted frames. As data rates increase, this overhead can lead to increased airtime usage, thus reducing airtime efficiency. Frame aggregation techniques are often used to improve network throughput and airtime efficiency. With frame aggregation, multiple frames are combined into a single transmission. Therefore, the transmitting device can send aggregated frame units (e.g., aggregated MPDUs (A-MPDUs) or aggregated MSDUs (A-MSDUs)) that include multiple subframes, instead of sending individual frames. Depending on the negotiated acknowledgment policy, the receiving device can acknowledge receipt of the aggregated frame unit by sending a block acknowledgment to the transmitting device. Attached Figure Description

[0002] One or more examples in this disclosure are described in detail with reference to the following accompanying drawings. These drawings are provided for illustrative purposes only and merely depict examples.

[0003] Figure 1 A block diagram of a wireless networking device, such as a wireless access point (AP), is depicted, which is capable of generating compressed headers for data units, thereby enabling efficient transmission of data units.

[0004] Figure 2 A block diagram depicts a receiving device (such as a client device) capable of recovering a complete header from a compressed header.

[0005] Figure 3 A flowchart is depicted for an example method for generating a compressed header and efficiently sending data units.

[0006] Figure 4 A flowchart is depicted for another example method for generating a compressed header and efficiently sending data units.

[0007] Figure 5 A sample compressed header is depicted.

[0008] Figure 6 Example aggregated data units, such as example A-MPDU, are described.

[0009] Figure 7 A flowchart is depicted for an example method of recovering a complete header from a compressed header.

[0010] Figure 8A flowchart is depicted for yet another example method for recovering a complete header from a compressed header.

[0011] Figure 9 A block diagram of the example computing system is depicted.

[0012] The accompanying drawings are not exhaustive and do not limit this disclosure to the precise form disclosed. Detailed Implementation

[0013] The A-MPDU and A-MSDU aggregation schemes specified in the IEEE 802.11n, IEEE 802.11ac, IEEE 802.11ax, and IEEE 802.11be specifications provide efficiency gains by reducing overhead and increasing throughput. For example, A-MPDU technology allows the transmission of multiple MPDUs within a single physical (PHY) frame. By aggregating MPDUs in a single frame, the overhead from the PHY preamble and header is distributed across multiple MPDUs, thus improving efficiency. Each MPDU within an A-MPDU includes its subframe header and Frame Check Sequence (FCS), which facilitates the selective retransmission of individual failed MPDUs rather than the entire aggregation unit. This capability significantly improves reliability and efficiency, especially in environments with varying signal quality.

[0014] Similarly, A-MSDU technology enables the combination of multiple MSDUs into a single A-MSDU. These aggregated MSDUs share a common 802.11 MAC header, which reduces the overhead associated with separate MAC headers for each MSDU. Therefore, A-MSDU aggregation minimizes the additional information sent in each MAC header, thereby improving the transmission efficiency of the MAC layer. However, it is important to note that, unlike A-MPDU transmission, if any part of an A-MSDU fails during transmission, the entire aggregated unit must be retransmitted, which can impact efficiency in certain scenarios.

[0015] Clearly, the efficiency of A-MPDU increases proportionally with the number of aggregated MPDUs, as per-MPDU overhead is reduced when more units are sent together. Similarly, A-MSDU aggregation benefits by reducing overall overhead by decreasing the frequency of MAC headers. However, the choice between A-MPDU and A-MSDU depends on specific network conditions and the desired balance between throughput and reliability.

[0016] While A-MPDU and A-MSDU aggregation techniques offer significant efficiency improvements, certain notable challenges, such as the overhead associated with certain header fields, may persist. For example, each subframe (e.g., MPDU or MSDU) within an aggregated data unit (e.g., A-MPDU or A-MSDU) includes several headers, such as Logical Link Control (LLC) / Subnet Access Protocol (SNAP) headers, Internet Protocol Version 4 (IPv4) / Internet Protocol Version 6 (IPv6) headers, and User Datagram Protocol (UDP) / Transmission Control Protocol (TCP) headers. These headers can remain largely the same for subframes within a common service session. For instance, in an A-MPDU frame, almost all subframes (i.e., MPDUs) include LLC / SNAP, IPv4 / IPv6, and UDP / TCP headers. When these subframes are part of the same traffic flow or session, they share the same 5-tuple (e.g., source IP address, source port number, destination IP address, destination port number, and transport protocol (e.g., TCP or UDP)). Typically, the IP (IPv4 / IPv6) and UDP / TCP headers are mostly identical, except for a few bits. This redundancy can incur considerable overhead because each subframe can carry its corresponding header. Therefore, even with aggregation techniques such as A-MPDU or A-MSDU, this duplicated header information in each subframe consumes valuable bandwidth, thus reducing the overall efficiency gain that A-MPDU and A-MSDU aim to achieve.

[0017] Based on the examples presented in this paper, a method is presented to improve transmission efficiency and air channel utilization by reducing certain overhead from headers (such as LLC, IP, and TCP / UDP headers) present in each subframe. In some examples, the proposed method can be implemented by a wireless networking device such as an access point (AP). The method begins with the AP's processing resources receiving data units (e.g., MPDUs or MSDUs), for example, data units serving as first and second data units (sequentially or in parallel) for the same session, each with a corresponding header, such as a first header in the first data unit and a second header in the second data unit. The processing resources then look for header fields containing the same information in both data units. After identifying these redundant header fields, the processing resources create a smaller and more efficient compressed header by removing duplicate content from the second header (i.e., the original header of the second data unit). Furthermore, in some examples, the processing resources may generate a session identifier based on the first data unit and insert the session identifier along with an availability bitmap into the compressed header. The availability bitmap includes flags corresponding to each header field of the second header, indicating the presence of the corresponding content in the compressed header. Then, the AP can replace the second header in the second data unit with a compressed header.

[0018] After modifying the second data unit to replace its original header with a compressed header, the processing resources can send the data unit to the receiving device (e.g., a client device or any other device with wireless capabilities). Specifically, the AP can send a first data unit with its original header and a second data unit with a compressed header. In some examples, the AP can send the first and second data units in a single transmission of aggregated data units (e.g., A-MPDU or A-MSDU) for efficient delivery. As will be understood, the transmission of compressed headers in the second and subsequent data units within the same traffic flow minimizes the overhead of headers from sources such as LLC, IP, and TCP / UDP headers, thereby maximizing the benefits of aggregation schemes such as A-MPDU and A-MSDU.

[0019] Furthermore, in some examples, this disclosure discloses a method for a networked device (hereinafter referred to as the receiving device) to recover the original detailed header from a compressed header by receiving a data unit having a compressed header. When the receiving device receives an aggregated data unit (e.g., an A-MPDU or A-MSDU), the receiving device may extract individual data units (e.g., a first data unit and a second data unit) from the aggregated data unit. The receiving device may then process the header of the first data unit to generate a verification session identifier, which the receiving device uses to find a match for a session identifier included in the compressed header of the second data unit. When the receiving device finds a match, the receiving device may recover the second header from the compressed header based on an availability bitmap and details from the first header. Specifically, the availability bitmap serves as a guide for determining which parts of the header need to be retrieved from the first header.

[0020] Reconstructing the second header requires the receiving device to analyze the availability bitmap contained in the compressed header to identify the header fields that need to be reconstructed. Based on the availability bitmap, the receiving device retrieves the relevant content from the corresponding fields in the first header. Once the necessary data is retrieved, the receiving device inserts the copied content into the compressed header, thereby recovering the second header from the compressed header. This insertion process helps to accurately reconstruct the second header at the receiving device, thus ensuring the integrity and consistency of the transmitted data while minimizing redundancy during transmission.

[0021] The following detailed description refers to the accompanying drawings. It should be clearly understood that the drawings are for illustration and description only. Although several examples are described in this document, modifications, adaptations, and other implementations are possible. Therefore, the following detailed description does not limit the disclosed examples. Rather, the appropriate scope of the disclosed examples may be defined by the appended claims.

[0022] Figure 1The illustration depicts a wireless networking device, such as an access point (AP) 100, which can implement various examples presented herein. AP 100 can be implemented in any setup, such as a home setup or an organization, including businesses, educational institutions, government entities, healthcare facilities, or other organizations. Specifically, AP 100 can provide wireless connectivity to client devices, enabling these client devices to connect with other electronic devices. Figure 1 (Not shown in the image) A networking device for communication. AP100 may include a combination of hardware, software, and / or firmware configured to provide wireless network connectivity to one or more client devices. In particular, AP100 may be used as an access point for client devices connected to AP100. In some examples, AP100 may include, be implemented as, or be referred to as a radio router, radio transceiver, switch, Wi-Fi hotspot device, basic service set (BSS) device, extended service set (ESS) device, radio base station (RBS), or some other term, and may act as a network access point for client devices connected to AP100.

[0023] The AP 100 can be implemented using one or more wireless devices to facilitate communication between the AP 100 and client devices and other wirelessly capable devices. Each wireless device of the AP 100 can operate on a corresponding radio frequency range known as a Wi-Fi band, such as the 2.4 GHz Wi-Fi band, the 5 GHz Wi-Fi band, the 6 GHz Wi-Fi band, etc. Although in Figure 1 Not shown, but in some examples, AP 100 can connect to one or more client devices and / or additional networking devices such as wireless LAN (WLAN) controllers, network switches, gateway devices, routers, etc. Through AP 100, client devices can communicate with each other and / or with any other networking devices communicatively connected to AP 100.

[0024] Client devices connected to AP 100 can be electronic devices capable of wirelessly communicating with AP 100 or other electronic devices. Examples of client devices may include desktop computers, laptop computers, servers, web servers, authentication servers, Authentication, Authorization and Accounting (AAA) servers, Domain Name System (DNS) servers, Dynamic Host Configuration Protocol (DHCP) servers, Internet Protocol (IP) servers, Virtual Private Network (VPN) servers, network policy servers, mainframes, tablet computers, e-readers, netbook computers, televisions and similar monitors (e.g., smart TVs), content receivers, set-top boxes, personal digital assistants (PDAs), mobile phones, smartphones, smart terminals, dumb terminals, virtual terminals, video game consoles, virtual assistants, Internet of Things (IoT) devices, etc. Communication between AP 100 and client devices can be facilitated via a wireless communication link established according to a wireless communication protocol such as the IEEE 802.11 standard, the Wi-Fi Alliance specification, or any other wireless communication standard. In some examples, communication between client devices and AP 100 may be implemented in accordance with the IEEE 802.11ax specification.

[0025] In some examples, the data units used for communication between the AP 100 and its connected devices (e.g., client devices and other networking devices) can be frames such as MPDUs and MSDUs. In some examples, the AP 100 can communicate with connected devices as aggregated data units (such as A-MPDUs or A-MSDUs). As previously mentioned, the A-MPDU and A-MSDU aggregation schemes specified in the IEEE 802.11n, IEEE 802.11ac, IEEE 802.11ax, and IEEE 802.11be specifications provide efficiency gains by reducing overhead and increasing throughput. In particular, A-MPDU technology allows the transmission of multiple MPDUs within a single physical (PHY) frame. By aggregating MPDUs in a single frame, the overhead from the PHY preamble and header is distributed across multiple MPDUs, thereby improving efficiency. This capability significantly improves reliability and efficiency, especially in environments with varying signal quality. Similarly, A-MSDU technology enables the combination of multiple MSDUs into a single A-MSDU. These aggregated MSDUs share a common 802.11 MAC header, which reduces the overhead associated with a separate MAC header for each MSDU. Therefore, A-MSDU aggregation minimizes the additional information sent in each MAC header, thereby improving the transmission efficiency of the MAC layer.

[0026] In some examples, AP 100 may include processing resources 102 and / or machine-readable storage medium 104 for AP 100 to perform several operations, as will be described in more detail below. Machine-readable storage medium 104 is a non-transitory medium, which is tangible and alternatively referred to as a non-transitory machine-readable storage medium that does not cover transient propagation signals. Machine-readable storage medium 104 can be any electrical, magnetic, optical, or other storage device capable of storing data and / or executable instructions. Examples of machine-readable storage medium 104 that can be used in AP 100 may include random access memory (RAM), non-volatile RAM (NVRAM), electrically erasable programmable read-only memory (EEPROM), storage drives (e.g., solid-state drives (SSDs) or hard disk drives (HDDs)), flash memory, etc. Machine-readable storage medium 104 can be used with executable instructions 108 (using... Figure 1 The dashed box in the figure depicts encoding used to generate a compressed header for data units transmitted by AP 100. Although not shown, in some examples, machine-readable storage medium 104 may be encoded with certain additional executable instructions that cause processing resources to perform any other operations intended to be performed by AP 100 (e.g., in conjunction with...). Figures 3 to 4 The description of the operations is not intended to limit the scope of this disclosure.

[0027] Processing resource 102 may be a physical device, such as a central processing unit (CPU), microprocessor, graphics processing unit (GPU), field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), other hardware device or combination thereof capable of retrieving and executing instructions stored in machine-readable storage medium 104. Processing resource 102 may extract, decode, and execute instructions 108 stored in machine-readable storage medium 104 to generate a compressed header for data units transmitted by AP 100. Alternatively to execute instructions 108, or in addition to executing instructions 108, processing resource 102 may include at least one integrated circuit (IC), control logic, electronic circuitry, or combination thereof, comprising multiple electronic components for performing functions to be performed by AP 100.

[0028] In some examples, machine-readable storage medium 104 hosts frame aggregation system 106 by storing corresponding program instructions and data. When executed by processing resource 102, frame aggregation system 106 causes processing resource 102 to: generate compressed headers for data units, aggregate data units in the form of aggregated data units, and send the aggregated data units to one or more connected devices in the connected devices.

[0029] As previously mentioned, data units such as MPDUs and MSDUs typically include verbose headers such as Logical Link Control (LLC), Internet Protocol (IP), Transmission Control Protocol (TCP), and User Datagram Protocol (UDP) headers. It has been observed that these headers often include certain header fields that are redundant for data traffic belonging to a common service session. For example, LLC is a sublayer of the Data Link Layer (Layer 2) in the Open Systems Interconnection (OSI) model. The LLC sublayer is primarily responsible for managing communication on a single network link. It provides both connection-oriented and connectionless services. LLC headers are used in IEEE 802 networks (such as Ethernet, Token Ring, and WLAN) to facilitate data communication. An LLC header typically contains three fields—Destination Service Access Point (DSAP), Source Service Access Point (SSAP), and Control Field (CTL). Generally, all content in the LLC header remains fixed for data traffic corresponding to the same service flow.

[0030] In the OSI model, the IP layer, often referred to as the network layer, is responsible for the logical addressing and routing of packets across network boundaries. Data units typically include a corresponding IP header to enable network layer communication. The IP header is a data structure that stores addressing and control information for packets in IP networks (e.g., IPv4 or IPv6 networks). The IP header allows networked devices (e.g., AP 100) to direct packets to their destinations. For example, an IPv4 header consists of several fields, some of which, along with their typical sizes, are shown in Table 1 below. Table 1: Typical header fields and their corresponding sizes in IPv4 headers

[0031] Some header fields in the IP header, such as "ihl", "version", "protocol", "check", "saddr", and "daddr", are typically consistent across frames belonging to the same traffic flow. Conversely, the "id" field can be different for each frame. On the other hand, header fields such as "tos", "tot_len", "frag_off", and "ttl" may not always be consistent across data traffic within the same traffic session. For the example header fields listed in Table 1, in one example, the IP header could be 20 bytes long.

[0032] Furthermore, TCP is a connection-oriented protocol that provides reliable, ordered, and error-checked delivery of data units between applications running on hosts communicating over IP networks. The TCP header consists of several fields, some of which, along with their typical sizes, are shown in Table 2 below. Table 2: Typical header fields and their corresponding sizes in TCP headers

[0033] Some header fields in the TCP header, such as "source," "dest," and "check," are typically kept the same for frames belonging to the same traffic flow. Conversely, the "seq" field can be different for each frame. On the other hand, the remaining fields of the TCP header listed in Table 2 may not always remain the same for data traffic within the same traffic session. For the example header fields listed in Table 2, in one example, the TCP header could also be 20 bytes long.

[0034] Furthermore, UDP is a core protocol within the core protocols of the IP suite. Unlike TCP, UDP is a connectionless protocol that provides minimal error recovery services. The UDP header is simpler than the TCP header and contains fewer fields. Table 3 below shows the UDP header fields along with their typical sizes. Table 3: Typical header fields and their corresponding sizes in UDP headers

[0035] Similar to the TCP header, the "source," "dest," and "check" fields are typically the same in the UDP header. However, the "len" field may not always be the same for data traffic within the same service session. For the example header fields listed in Table 3, in one example, the UDP header could be 8 bytes long.

[0036] If left uncontrolled, the transmission of all such lengthy headers with redundant information for a given traffic flow can consume increased airtime, thereby reducing overall transmission efficiency. Therefore, the proposed AP 100 intelligently controls the transmission of information in such headers for efficient data transmission. According to an example of this disclosure, the AP 100 with the proposed frame aggregation system 106 is configured to generate compressed headers for frames that can be transmitted by the AP 100. Specifically, the frame aggregation system 106 can generate compressed headers by intelligently removing certain redundant information (such as the contents of one or more header fields discussed above). For illustrative purposes, the frame aggregation system 106 and items within it are represented by dashed outlines because they represent digital entities, which can be in the form of data and / or instructions executable by physical processing resources (e.g., processing resource 102).

[0037] In some examples, AP 100 receives data units, such as a first data unit and a second data unit, both belonging to the same service session for transmission to a intended receiver. The first and second data units may include corresponding headers, such as a first header and a second header. Because both data units belong to the same service session, the corresponding headers may share certain redundant header fields. The proposed AP 100 can be configured to identify such redundant header fields across the first and second headers by comparing the corresponding header fields. For example, header fields whose content typically remains unchanged between the first and second headers can be identified as candidates for optimization.

[0038] After identifying these candidate fields, AP 100 can generate a compressed header by removing redundant information from the second header. This compressed header retains only the unique information specific to the second header, significantly reducing the header size and improving transmission efficiency. To ensure that the second header can be reconstructed in its original form at the receiving device, AP 100 can insert an availability bitmap into the compressed header. The availability bitmap includes flags corresponding to one or more header fields of the second header, indicating the presence of a specific field in the compressed header, thus providing a concise diagram of the retained information.

[0039] Then, AP 100 can replace the second header in the second data unit with the newly created compressed header. By replacing the original larger header with this optimized, smaller version, AP 100 reduces bandwidth consumption and speeds up the transmission process. Finally, AP 100 transmits the data units; specifically, the first data unit is transmitted with its original header (i.e., the first header), while the second data unit is transmitted with a compressed header. This transmission of data units, either individually or as aggregated data units such as Aggregated MAC Protocol Data Unit (A-MPDU) or Aggregated MAC Service Data Unit (A-MSDU), improves both transmission efficiency and overall network performance.

[0040] It will be understood that using a compressed header that includes certain selective fields from one or more of the LLC, IP, TCP, and / or UDP headers reduces the overall size of the transmitted data units. For example, as previously stated, for public service sessions, the LLC header can be completely eliminated from subsequent data units after the first data unit.

[0041] Furthermore, for IP headers such as the example header fields with a total size of 20 bytes as described in Table 1, certain header fields in the IP header, such as "ihl", "version", "protocol", "check", "saddr", and "daddr", are typically kept the same for frames belonging to the same service session. Therefore, all these fields can be eliminated, reducing the maximum IP header size to 8 bytes, thus achieving a 60% reduction in IP header size. In the example case, when header fields such as "tos", "tot_len", "frag_off", and "ttl" are also found to be the same within data units of the same service session, the IP header can be reduced to just 2 bytes, achieving a 90% reduction in IP header size. Therefore, using the proposed technique, the IP header size can be reduced by approximately 60% to 90% for data services belonging to the same service session.

[0042] Furthermore, for TCP headers such as those with example header fields of 20 bytes total size as described in Table 2, certain header fields such as "source," "dest," and "check" are typically identical for frames belonging to the same service session. Therefore, all these fields can be eliminated, resulting in a maximum TCP header size of 14 bytes, thus achieving a 30% reduction in TCP header size. In the example case, when identical header fields other than "seq" are found within data units of the same service session, the TCP header can be reduced to only 4 bytes, achieving an 80% reduction in TCP header size. Therefore, using the proposed technique, the TCP header size can be reduced by approximately 30% to 80% for data services belonging to the same service session.

[0043] Furthermore, for UDP headers, such as the example header header with a total size of 8 bytes as described in Table 3, certain header fields, such as "source," "dest," and "check," are typically kept identical for frames belonging to the same service session. Therefore, all these fields can be eliminated, resulting in a maximum UDP header size of 2 bytes, thus achieving a 75% reduction in UDP header size. In the example case, when all header fields are found to be identical within data units of the same service session, the UDP header can be completely eliminated, achieving a 100% reduction in UDP header size. Therefore, using the proposed technique, the UDP header size can be reduced by approximately 75% to 100% for data services belonging to the same service session.

[0044] Furthermore, as will be understood, data units with smaller frame lengths (e.g., MPDUs and MSDUs with frame lengths of 300 bytes) have greater header overhead compared to data units with relatively large frame lengths (e.g., MPDUs and MSDUs with frame lengths of 1500 bytes). Therefore, the proposed technique can achieve a greater overall frame length reduction for data units with smaller frame lengths compared to data units with larger frame lengths. As will be understood, the header size reduction achieved by using the proposed technique reduces the total size of the transmitted data units, thereby improving transmission efficiency and air channel utilization.

[0045] Combination Figure 3 and Figure 4 Describe additional details regarding the generation of the compressed header and the transmission of data units.

[0046] refer to Figure 2 The device presented is another networked device, also known as receiving device 200, which is configured to recover the complete header from the compressed header. Receiving device 200 can be an electronic device capable of communicating with other devices using a wireless communication protocol (e.g., the Wi-Fi communication standard). In some examples, receiving device 200 can be a wireless networking device, such as an access point (AP), radio router, radio transceiver, switch, Wi-Fi hotspot device, BSS device, ESS device, radio base station, WLAN controller, gateway device, etc. In some examples, receiving device 200 can be capable of communicating with devices such as… Figure 1 The AP 100 is a client device that communicates with wireless networking devices. In some examples, the functionality of the receiving device 200 can be embedded into... Figure 1 In AP 100, this enables AP 100 to recover the complete header of the data unit containing the compressed header.

[0047] To achieve wireless communication capabilities, the receiving device 200 can also be implemented using one or more radio devices, thereby allowing the receiving device 200 to communicate with other wirelessly capable devices (e.g., AP 100). Each radio device of the receiving device 200 can operate on a corresponding radio frequency range known as a Wi-Fi band, such as the 2.4 GHz Wi-Fi band, the 5 GHz Wi-Fi band, the 6 GHz Wi-Fi band, etc. The radio devices of the receiving device 200 can support communication according to wireless communication protocols (such as the IEEE 802.11 standard, the Wi-Fi Alliance specification, or any other wireless communication standard).

[0048] During operation, the receiving device 200 can receive aggregated data units containing data units (e.g., MPDU or MSDU), such as A-MPDU or A-MSDU. Some of the received data units may contain a compressed header, similar to a combined... Figure 1 The header is described. According to some examples of this disclosure, the receiving device 200 can be configured to recover a corresponding complete header from a compressed header. To aid in header recovery, the receiving device 200 may include processing resources 202 and / or machine-readable storage medium 204. The machine-readable storage medium 204 can accommodate a frame processing system 206 by storing corresponding program instructions and data. The frame processing system 206 can assist in recovering the complete header of a data unit from a corresponding compressed header, particularly by intelligently recovering the contents of certain header fields of the data unit.

[0049] For illustrative purposes, frame processing system 206 and items within frame processing system 206 are represented by dashed outlines because they represent digital entities, which are in the form of data and / or instructions executable by physical processing resources (e.g., processing resource 202). Processing resource 202 and machine-readable storage medium 204 may be... Figure 1 The example representation of processing resource 102 and machine-readable storage medium 104 is omitted for brevity. Machine-readable storage medium 204 may be encoded with executable instructions 208 (using...). Figure 2 The dashed box in the figure (depicted in the figure) is used to recover the complete header from the compressed header. Although not shown, in some examples, the machine-readable storage medium 204 may be encoded with certain additional executable instructions that cause the processing resource 202 to perform any other operation intended to be performed by the receiving device 200 (e.g., in conjunction with...). Figures 7 to 8 The description of the operations is not intended to limit the scope of this disclosure.

[0050] In some examples, processing resource 202 executes frame processing system 206 by executing instruction 208 to recover header information from the compressed header included in the received data unit. The process of recovering the complete header from the compressed header involves several steps performed by receiving device 200 (e.g., by processing resource 202 executing instruction 208). First, receiving device 200 receives an aggregated data unit, which may be an A-MPDU or an A-MSDU. The aggregated data unit includes a first data unit with a complete header (e.g., a first header) and a second data unit with a simplified compressed header. The compressed header contains an availability bitmap indicating which parts of the header are missing and a session ID to help identify the data stream. Receiving device 200 separates the aggregated data unit into individual data units and stores them for further processing.

[0051] Next, by extracting key information (such as IP address and port number) and running a hash function, receiving device 200 generates a verification session ID from the complete header of the first data unit. Then, receiving device 200 compares the generated verification session ID with the session ID included in the compressed header (e.g., the first session ID) to ensure that the two data units belong to the same business session. If they match, receiving device 200 examines the availability bitmap from the compressed header to determine which header fields need to be recovered. Then, receiving device 200 copies the missing information from the complete header of the first data unit (e.g., the first header) and inserts it into the compressed header, effectively reconstructing the complete header (e.g., the second header). Finally, receiving device 200 replaces the compressed header in the second data unit with the recovered complete header, ensuring that the second data unit is intact and ready for further processing.

[0052] In the following description, by means of Figure 3 and Figure 4 The flowcharts depicted describe the various operations performed by networked devices (such as AP100). Figure 3 and Figure 4 A flowchart is depicted illustrating an example method for efficiently transmitting data units by AP 100. Figure 3 and Figure 4 The steps shown can be performed locally on any suitable device, such as a wirelessly networked device (e.g., Figure 1 (AP 100). In some examples, suitable devices may include processing resources adapted to retrieve and execute instructions (e.g., instruction 108) stored in a machine-readable storage medium. The processing resources and the machine-readable storage medium may be... Figure 1 The AP 100's processing resource 102 and machine-readable storage medium 104 are exemplified. As an alternative to retrieving and executing instructions, or in addition to retrieving and executing instructions, the processing resource may include one or more electronic circuits, including functional electronic components for executing one or more instructions, such as FPGAs, ASICs, or other electronic circuits. Furthermore, Figure 3 and 4 The flowchart shown includes several steps in a specific order. However, the order of steps shown in the corresponding flowchart should not be interpreted as the only order for the steps. These steps can be performed at any time in any order. Additionally, these steps can be repeated or omitted as needed.

[0053] Figure 3 A flowchart depicts an example method 300 for efficiently transmitting data units. Method 300 can be derived from, for example... Figure 1 The AP 100 network device is used to perform this.

[0054] At step 302, the networked device receives a first data unit for transmission to a intended recipient. In some examples, receiving the first data unit at step 302 includes the networked device's processing resources retrieving the first data unit from a transport store. The transport store stores data units to be sent by the networked device. Specifically, the first data unit may belong to a first service session and include a first header. A service session can be defined as a set of interactions between a source device and a destination device within a given time period. Typically, in data units belonging to a given service session (also alternatively referred to as a service flow), certain session-specific parameters such as the source IP address, source port, destination IP address, destination port, and the protocol type used for communication between the two devices may remain the same. As an example, the first data unit may be a data frame such as an MPDU or MSDU, which includes a corresponding data payload and one or more headers, such as an LLC header, an IP header (e.g., an IPv4 header or an IPv6 header), or a TCP / UDP header.

[0055] Furthermore, at step 304, the networking device receives a second data unit for transmission to the intended recipient. In some examples, receiving the second data unit at step 304 includes the networking device's processing resources retrieving the second data unit from a transport store. The second data unit may also belong to a first service session (also referred to as a first service flow) and include a second header. In some examples, in response to determining that the second data unit has the same session-specific parameters as the first data unit (e.g., source IP address, source port, destination IP address, destination port, and protocol type), the networking device's processing resources may determine that the second data unit also belongs to the first service session. The second data unit may also include a corresponding data payload and protocol header, such as an LLC header, an IP header (e.g., an IPv4 or IPv6 header), or a TCP / UDP header.

[0056] It can be noted that the network device can receive the first data unit and the second data unit serially or in parallel. Furthermore, as previously mentioned, several header fields in each header of the LLC header, IP header, or TCP / UDP header belonging to the same service session may be identical. Therefore, at step 306, the network device can identify one or more candidate header fields that contain similar information in both the first and second headers. To identify header fields that remain identical between the first and second headers, the network device can compare the corresponding header fields of the first and second headers at step 306. This identification of candidate header fields with redundant content between data units within the same service session (e.g., the first service session) is useful in optimizing data transmission, as described later. Common header fields that can be identified as candidates for optimization include source and destination addresses and protocol-specific information that remains constant throughout the session.

[0057] As mentioned earlier, all three fields of the LLC header can generally remain the same for data units belonging to the same business session. In this example, since both the first and second data units belong to the same business session (e.g., the first business session), all three fields of the LLC header, such as "dsap", "ssap", and "ctl", will be the same in both the first and second headers. Therefore, the fields "dsap", "ssap", and "ctl" of the LLC header can be identified as candidate header fields.

[0058] Furthermore, for the IP headers of the first and second data units, certain header fields, such as "ihl", "version", "protocol", "check", "saddr", and "daddr", are generally the same for frames belonging to the same service session. Therefore, the IP header fields "ihl", "version", "protocol", "check", "saddr", and "daddr" can also be identified as candidate header fields. Additionally, in another example, if a comparison of the first and second headers reveals that the fields "tos", "tot_len", "frag_off", and "ttl" are also the same in both headers, then in addition to "ihl", "version", "protocol", "check", "saddr", and "daddr", the fields "tos", "tot_len", "frag_off", and "ttl" can also be identified as candidate header fields.

[0059] Furthermore, for the TCP headers of the first and second data units, certain header fields such as "source," "dest," and "check" are generally the same for frames belonging to the same traffic flow, and therefore can be identified as candidate header fields. Additionally, in another example, fields in the TCP header other than "seq" may be redundant in frames belonging to the same traffic flow. Therefore, all such fields with redundant content can be identified as candidate header fields.

[0060] Furthermore, for the TCP headers of the first and second data units, certain header fields such as “source,” “dest,” and “check” are generally the same for frames belonging to the same traffic flow, and therefore can be identified as candidate header fields.

[0061] This identification of similarity between header fields helps retain useful information while eliminating redundancy in the transmission of data units, thus making the communication process more efficient without compromising the accuracy or reliability of the data being transmitted. Identifying candidate header fields is a useful step that balances efficiency with the need to preserve the useful information required for successful data transmission.

[0062] With the candidate header fields identified, at step 308, the network device continues to generate a compressed header (see description later). Figure 5 (Example compressed header depicted in the text). This step involves creating a new, streamlined header by removing redundant information from the second header. Specifically, a compressed header can be generated by removing the contents of one or more candidate header fields from the second header. As a result, the newly generated compressed header retains information that is unique to the second header, thus significantly reducing the header size and consequently the total size of the data unit. The compressed header is designed to improve transmission efficiency by minimizing the amount of header data that needs to be transmitted. This reduction in header size speeds up the transmission process and frees up bandwidth for appended data, thereby enhancing overall network performance.

[0063] To maintain tracking of candidate header fields and aid the receiving device in reconstructing the original header information, the networking device may include certain useful additional information in the compressed header. For example, at step 310, the networking device may insert an availability bitmap into the compressed header. The availability bitmap includes flags corresponding to one or more header fields of the second header, indicating the presence or absence of a specific header field in the compressed header, thus providing a concise map of the information in the compressed header. In particular, the availability bitmap acts as a guide, allowing the receiving device to understand which fields have been retained in the compressed header and which have been omitted due to redundancy. This allows the receiving device to accurately recover the complete header from the compressed header (in... Figures 7 to 8(More details will be provided in the text).

[0064] After updating the compressed header with the availability bitmap, at step 312, the networking device can replace the original header (i.e., the second header) of the second data unit with the compressed header. Specifically, this step involves replacing the full, detailed second header in the second data unit with a newly created compressed header. By replacing the larger original header with a smaller, optimized compressed header, the device ensures that less bandwidth is consumed for sending header information. Replacing the verbose second header with a compressed header reduces the overall data size and improves transmission efficiency.

[0065] Finally, at step 314, the networked device can transmit data units. Specifically, the first data unit can be transmitted with its original first header, while the second data unit can be transmitted with a compressed header. In one example implementation, the networked device can transmit the first data unit serially by transmitting the first data unit followed by the second data unit. In another example, the networked device can transmit the first and second data units as such as an A-MPDU or A-MSDU (see description later). Figure 6 The example aggregated data unit depicted in the text is used to send aggregated data units.

[0066] Turn now Figure 4 The diagram presents a flowchart of another example method 400 for efficiently sending data units. Method 400 can be derived from methods such as... Figure 1 The AP 100 network device is used to perform this. Figure 4 Method 400 includes similar Figure 3 For the sake of brevity, some of the steps described in the previous section will not be repeated in this article.

[0067] At step 402, the networking device receives a first data unit for transmission to the intended recipient. Similarly, at step 404, the networking device may receive a second data unit for transmission to the intended recipient. As previously described, receiving the first and second data units may require the networking device's processing resources to retrieve the first and second data units from a transport store. Both the first and second data units may belong to the same service session, such as a first service session. Moreover, the first and second data units may include corresponding headers, such as a first header and a second header. Each of the first and second headers may include one or more of the following headers: an LLC header, an IP header (e.g., an IPv4 or IPv6 header), a TCP header, or a UDP header. In some examples, the networking device may receive the first and second data units serially or in parallel.

[0068] Furthermore, at step 406, the networking device may generate a first session identifier based on the first data unit. Specifically, the networking device may generate a first session identifier as a unique session identifier for the service session associated with the first data unit. This process involves extracting specific header fields from the first header that can uniquely identify the service session associated with the first data unit. As previously mentioned, session-specific parameters such as source IP address, source port, destination IP address, destination port, and protocol type can collectively identify a given service session. The networking device then applies a predefined hash function to these extracted fields. Example hash functions used by the networking device to generate the session identifier may include Secure Hash Algorithm (SHA)-1, SHA-2, SHA-3, SHA-256, Whirlpool, BLAKE2, BLAKE3, and / or Message Digest (MD)5, or a custom-designed hash function. The resulting hash value is used as the session identifier, thereby providing a unique and compact representation of the first service session.

[0069] To effectively manage the transmission of data packets, the networking device maintains separate transmission queues corresponding to different service sessions. Specifically, a transmission queue is a data structure, typically implemented as a linked list, circular buffer, or priority queue, that organizes data units awaiting transmission. To effectively manage transmission queues, a session identifier can be used as a key to place a given data unit in the correct queue, thereby ensuring that all data units belonging to the same service session are sent in a predefined order. During the operation of this example, after generating the first session identifier, at step 408, the networking device can store the first data unit in the transmission queue corresponding to the first service session uniquely identified by the first session identifier.

[0070] As previously mentioned, certain header fields in each header of the LLC, IP, or TCP / UDP headers within a data unit belonging to the same service session may be identical. At step 410, the networking device may identify one or more candidate header fields containing redundant information. Specifically, the networking device may scan the header of the second data unit (e.g., the second header) to identify which fields can be avoided for transmission, thereby optimizing the header size without losing useful information. Fields containing redundant information in both the first and second headers are primary candidates for compression. Figure 3 Step 304 describes several examples of keeping header fields static across all data units within the same session; for brevity, these descriptions will not be repeated here. Considering protocol specifications and session context, this step involves analyzing the structure and content of the second header. Efficient identification of candidate fields can significantly reduce header size and improve transmission efficiency.

[0071] After identifying the candidate header fields, the network device generates a compressed header at step 412 (see description later). Figure 5 (Example compressed header depicted). The process involves creating a new, streamlined header by specifically removing redundant information from the second header. The compressed header is generated by eliminating the contents of identified candidate header fields deemed unnecessary for each data unit within the same service session. For example, static fields that remain constant for all packets in the session can be excluded from the compressed header, resulting in a compressed header that retains information unique to the second data unit. This reduction in header size significantly reduces the overall size of the data unit, leading to improved transmission efficiency and reduced bandwidth usage.

[0072] Furthermore, at step 414, the networking device inserts a first session identifier into the newly generated compressed header. The first session identifier, generated at step 406, provides a unique reference to the first service session to which the second data unit belongs. Inserting the first identifier into the compressed header ensures that the session context is preserved even with a reduced header size. This identifier allows the networking device, as well as other devices in the network, to correctly associate the second data unit with its service session. This step involves modifying the compressed header structure to include information elements that can be easily accessed and interpreted by the receiving device to recover complete header information (see [link to relevant documentation]). Figure 7 and Figure 8 (Method).

[0073] Furthermore, at step 416, the networking device inserts an availability bitmap into the compressed header. For example, the availability bitmap is a series of bits, where each bit indicates the presence or absence of a corresponding header field from the second header. The availability bitmap provides a concise way to indicate which header fields from the original header (e.g., the second header) have been included in the compressed header and which header fields have been omitted. This availability bitmap is useful for reconstructing the original header when needed (e.g., at the receiving device), thereby ensuring that no critical information is lost during compression. This step involves generating a bitmap based on the identified candidate fields and inserting it into the compressed header.

[0074] Furthermore, at step 418, the networking device replaces the second header in the second data unit (i.e., the original header of the second data unit) with a newly generated compressed header. This step involves modifying the second data unit by replacing the complete, detailed second header in the second data unit with a newly created compressed header. Replacing the original header with a compressed header reduces the overall size of the data unit, thereby improving transmission efficiency.

[0075] Furthermore, at step 420, the networking device may store the second data unit in the transmission queue after replacing the second header in the second data unit with a compressed header. Specifically, the networking device stores the modified second data unit, now with a compressed header, in the same transmission queue as the first data unit. This ensures that the two data units are sent in the correct order and within the same session context.

[0076] At step 422, the networking device may generate an aggregated data unit including a first data unit having a first header and a second data unit having a compressed header (see description later). Figure 6 (Example aggregated data unit depicted). In some examples, the aggregated data unit generated at step 422 may be an aggregated MAC protocol data unit (A-MPDU) or an aggregated MAC service data unit (A-MSDU). If the first and second data units are MPDUs, the networking device may generate an A-MPDU as an aggregated data unit. Similarly, if the first and second data units are MSDUs, the networking device may generate an A-MSDU as an aggregated data unit. As will be understood, in high-throughput wireless networks, such as those conforming to the IEEE 802.11n / ac / ax standard, these individual data units into aggregated data units enhance transmission efficiency.

[0077] For A-MPDU generation, the networked device aggregates multiple MPDUs (e.g., a first data unit and a second data unit, assuming the first and second data units are MPDUs) into a single transmission frame. Each MPDU retains its own MAC header and is encapsulated with a delimiter that allows the receiving device to identify and extract individual MPDUs even if errors occur during transmission. The MPDUs are concatenated within the A-MPDU frame, which reduces the overhead of transmitting each MPDU separately. This method improves overall throughput by maximizing the use of available bandwidth and minimizing contention overhead in the wireless medium.

[0078] For A-MSDU generation, the networking device aggregates multiple MSDUs into a single transmission frame called the A-MSDU (e.g., a first data unit and a second data unit, assuming the first and second data units are MSDUs). This process involves the networking device encapsulating several MSDUs, which are higher-level data units, into the payload of a single MPDU with a shared MAC header. The aggregated MSDUs share the same destination address and other relevant attributes to be combined. By reducing the number of MAC headers sent, A-MSDU aggregation minimizes overhead and improves transmission efficiency. In both cases, the networking device ensures that the aggregated data unit (whether an A-MPDU or an A-MSDU) adheres to the Maximum Transmission Unit (MTU) size and other relevant protocol constraints. The generated aggregated unit enhances transmission efficiency by reducing protocol overhead and efficiently utilizing available bandwidth.

[0079] Finally, at step 424, the networked device sends the aggregated data units to the intended recipient. This involves, for example, using a network interface such as a transceiver to queue the aggregated data units for transmission. The networked device employs a suitable transport protocol, such as Wi-Fi, to ensure successful delivery.

[0080] refer to Figure 5 , Figure 5 Example compressed header 500 is depicted. Figure 5 The compressed header 500 is an example representing a “compressed header” generated by an example networking device based on the full header. The compressed header 500 may include an availability bitmap 502, a first session identifier 504, and selected header fields 506 to 524. As previously described, the availability bitmap 502 provides a concise way to indicate which header fields from the original full header have been included in the compressed header and which have been omitted. Specifically, the availability bitmap 502 may be a series of bits, where each bit indicates the presence or absence of a corresponding header field in the second header (e.g., the original header of the second data unit described in conjunction with the previous figures). This allows the receiving device to efficiently recover the original header when necessary. Furthermore, the first session identifier 504 may be a unique identifier for the service session associated with the first and second data units (e.g., the session identifier generated at step 406).

[0081] The selected header fields 506 to 524 may include header fields that are unique to the second header of the second data unit compared to the first header of the first data unit. Figure 5In the illustrated use case, the second data unit is identified as including unique content in its header fields, such as "tos", "tot_len", "frag_off", and "ttl" in the IP header, "seq", "ack_seq", "flag", "window", and "urg_ptr" in the TCP header, and "len" in the UDP header. Therefore, the compressed header 500 is shown to include these fields, and the remaining fields of the corresponding headers can be identified as candidate header fields and are thus removed.

[0082] For example, header fields 506, 508, 510, 512, and 514 of compressed header 500 can represent the non-redundant IP header fields "tos", "tot_len", "frag_off", and "ttl" between the first and second headers, respectively. Similarly, header fields 516, 518, 520, 522, and 524 of compressed header 500 can represent the non-redundant TCP header fields "seq", "ack_seq", "flag", "window", and "urg_ptr" between the first and second headers, respectively. Finally, header field 526 of compressed header 500 can represent the header field "len" of the UDP header, which is unique to the second header. It can be noted that... Figure 5 The header fields depicted in the compressed header 500 are for illustrative purposes only. In practice, the compressed header 500 may include those fields that are unique to the second header compared to the first header. Therefore, in some examples, the number of header fields in the compressed header 500 may also be different.

[0083] Figure 6 Example aggregated data units, such as example A-MPDU 600, are depicted. A-MPDU 600 can represent data that can be aggregated into... Figure 3 Step 314 or Figure 4 Step 424 is performed by a networked device (e.g., Figure 1 The aggregated data unit (A-MPDU 600) is sent by the AP 100. In some examples, A-MPDU 600 can represent a data unit that can be sent by a receiving device (e.g., AP 100). Figure 2 The receiving device 200) in Figure 7 Step 702 or Figure 8 The aggregated data unit received at step 802.

[0084] The A-MPDU 600 includes a PHY header 602 and a data unit section 604. The PHY header 602 of the A-MPDU 600 plays a role in preparing the receiving device to receive and decode the A-MPDU 600. It provides synchronization, channel estimation, and certain additional information about frame structure and transmission parameters, thereby ensuring robust and efficient wireless communication.

[0085] Furthermore, the data unit portion 604 of the A-MPDU 600 includes one or more data units, such as the MPDU in the present case. For illustrative purposes, the data unit portion 604 is depicted as including two data units, such as a first data unit 606 (also referred to as the first MPDU) and a second data unit 608 (also referred to as the second MPDU). It will be understood that the data unit portion 604 may include more data units within the maximum transmission unit (MTU) size and other relevant protocol constraints. Additionally, in some examples, adjacent MPDUs are separated within the A-MPDU via delimiters (e.g., delimiter 610). Delimiter 610 may represent a predefined set of bytes added between the various MPDUs and serves as a marker to separate one MPDU within the A-MPDU from another.

[0086] As previously described, the first data unit 606 may include a first header 612 and a first data payload 614, while the second data unit 608 may include a compressed header 616 and a second data payload 618. The first header 612 may be the original, complete form, while the compressed header 616 is generated by removing certain redundant header fields from the second header of the second data unit (see [link to documentation]). Figure 3 Steps 308 to 312 and Figure 4 Steps 412 to 416). In one example, the compressed header 616 could be similar to... Figure 5 The compressed header 500 is depicted.

[0087] In the following description, by means of Figure 7 and Figure 8 The flowchart depicted in the diagram describes the receiving device (e.g., receiving data units with compressed headers) described in the diagram. Figure 2 The receiving device (200) performs various operations on the networked device. In some examples, the receiving device can be a wireless networking device, such as an access point (AP), radio router, radio transceiver, switch, Wi-Fi hotspot device, BSS device, ESS device, radio base station, WLAN controller, gateway device, etc. In some examples, the receiving device can be capable of communicating with devices such as… Figure 1 The AP 100 is a client device that communicates with wireless networking devices. In some examples, the functionality of the receiving device can be embedded in... Figure 1In AP 100, so that AP 100 can recover the header of the aggregated data unit that it can receive.

[0088] Specifically, Figure 7 and Figure 8 A flowchart is depicted for an example method for a receiving device to recover a complete header from a compressed header in response to receiving a data unit with a compressed header. This method can be executed locally on any suitable device. Figure 7 and Figure 8 The steps shown, such as receiving devices, for example Figure 2 The receiving device 200. In some examples, suitable devices may include processing resources adapted to retrieve and execute instructions (e.g., instruction 208) stored in a machine-readable storage medium. The processing resources and the machine-readable storage medium may be... Figure 2 The receiving device 200 includes processing resources 202 and machine-readable storage medium 204 as examples. As an alternative to retrieving and executing instructions, or in addition to retrieving and executing instructions, the processing resources may include one or more electronic circuits, comprising functional electronic components for executing one or more instructions, such as FPGAs, ASICs, or other electronic circuits. Furthermore, Figure 7 and Figure 8 The flowcharts shown include several steps in a specific order. However, the order of steps shown in the corresponding flowcharts should not be interpreted as the only order for the steps. These steps can be performed at any time in any order. Additionally, these steps can be repeated or omitted as needed.

[0089] Now for reference Figure 7 The flowchart presents an example method 700 for recovering a complete header from a compressed header.

[0090] At step 702, the receiving device receives an aggregated data unit including a first data unit and a second data unit. In some examples, the aggregated data unit may be an A-MPDU or an A-MSDU. The aggregated data unit includes at least a first data unit and a second data unit. The first data unit includes a first header, which is a complete header containing all necessary fields for proper identification and routing of the data unit. The second data unit includes a compressed header (e.g., in...). Figure 3 Step 308 or Figure 4The compressed header generated at step 412 has been optimized to reduce redundancy and improve transmission efficiency. As previously mentioned, the compressed header contains an availability bitmap (i.e., a series of bits indicating the presence or absence of a particular header field) and a first session identifier (i.e., identification information that uniquely identifies the service session to which the data unit belongs). Upon receiving the aggregated data unit, the receiving device stores the aggregated data unit in a suitable buffer (e.g., an incoming data buffer) and parses the data unit to extract the header.

[0091] Furthermore, at step 704, the receiving device generates a verification session identifier based on the first header of the first data unit. This process involves extracting certain session-specific parameters from the first header, such as the source IP address, destination IP address, source port, destination port, and protocol type. These session-specific parameters uniquely identify the service session. The receiving device applies the same predetermined hash function used by the sending device to these extracted session-specific parameters to generate the verification session identifier. This ensures the consistency and accuracy of the session identifier. The verification session identifier serves as a reference for verifying the session context of the second data unit. The hash function is designed to produce the same output for the same input fields, thereby ensuring that if the two data units do indeed belong to the same session, the verification session identifier matches the first session identifier in the compressed header.

[0092] Furthermore, at step 706, the receiving device may, in response to determining that the verification session identifier matches the first session identifier, identify one or more candidate header fields from the compressed header for recovery. This identification is based on an availability bitmap, which indicates which fields are present or absent in the compressed header. The receiving device compares the verification session identifier generated in step 704 with the first session identifier extracted from the compressed header. If the identifiers match, it is confirmed that the first and second data units belong to the same session, and header recovery can proceed. The receiving device then uses the availability bitmap to determine which specific header fields to recover. The bitmap provides a bit-by-bit representation, where each bit corresponds to a header field, where "1" indicates presence and "0" indicates absence of the field, and vice versa. This step ensures that only necessary fields are recovered, thereby maintaining the efficiency of the compressed header.

[0093] Furthermore, at step 708, the receiving device can recover the second header by filling one or more candidate header fields into the compressed header from the corresponding header fields of the first header. Specifically, the receiving device copies the values ​​of missing fields from the first header to their appropriate positions within the compressed header. The receiving device uses an availability bitmap as a guide to determine which fields need to be copied from the first header and inserted into the compressed header. This recovery process ensures that the second header is fully reconstructed, thus containing all the necessary information for proper routing and processing. The recovered second header now includes fields that were previously omitted when the compressed header was created.

[0094] Then, at step 710, the receiving device can replace the compressed header in the second data unit with the reconstructed second header. Specifically, this step involves the receiving device modifying the second data unit in the input data buffer to ensure that the restored second header is correctly placed and aligned. The receiving device updates any necessary pointers or offsets to reflect changes in header size and structure. By replacing the compressed header with the fully restored second header, the receiving device ensures that the second data unit is now complete and ready for further processing or forwarding. The receiving device then continues to process or forward the data unit according to its network protocol and policies.

[0095] Now go to Figure 8 The diagram presents a flowchart of another example method 800 for recovering a complete header from a compressed header. Method 800 can be provided by a receiving device (e.g., Figure 2 The receiving device 200) performs the operation. Figure 8 Method 800 includes similar Figure 7 For the sake of brevity, some of the steps described in the previous section will not be repeated in this article.

[0096] At step 802, the receiving device receives an aggregated data unit comprising a first data unit and a second data unit. The aggregated data unit comprises at least a first data unit and a second data unit, wherein the first data unit includes a first header, which is a complete header containing all necessary fields for proper identification and routing of the data unit, and the second data unit includes a compressed header containing an availability bitmap and a first session identifier (e.g., in...). Figure 3 Step 308 or Figure 4 (The compressed header generated at step 412).

[0097] At step 804, the receiving device extracts the first and second data units from the aggregated data unit. This involves parsing the structure of the aggregated data unit to identify and separate the individual data units. For an A-MPDU, the receiving device locates the delimiters in the A-MPDU to extract each MPDU. For an A-MSDU, the receiving device separates the individual MSDUs from the payload of the single MPDU. The extracted data units are stored in a suitable storage buffer, such as an input data buffer, for further processing, thereby ensuring their integrity and preparation for subsequent header recovery steps.

[0098] Furthermore, at step 806, similar to bonding Figure 7 As described, the receiving device generates a verification session identifier based on the first header of the first data unit. The verification session identifier serves as a reference for the session context of verifying the second data unit. Furthermore, at step 808, in response to determining that the verification session identifier matches the first session identifier, the receiving device can identify one or more candidate header fields from the compressed header for recovery. This identification is based on an availability bitmap, which indicates which fields are present or absent in the compressed header. The receiving device compares the verification session identifier generated in step 806 with the first session identifier extracted from the compressed header. If the identifiers match, it is confirmed that the first and second data units belong to the same session, and header recovery can proceed. The receiving device then uses the availability bitmap to determine which specific header fields to recover.

[0099] After identifying candidate header fields, the receiving device can recover the second header by filling one or more candidate header fields into the compressed header from the corresponding header fields of the first header. For example, this recovery process requires the receiving device to perform steps 810 and 812. Specifically, at step 810, the receiving device copies the contents of one or more candidate header fields from the first header. This involves accessing the complete header of the first data unit and retrieving the values ​​of the candidate header fields identified in step 808 for recovery. The receiving device reads the appropriate fields based on the availability bitmap, ensuring that it captures all the necessary information required to reconstruct the second header. Furthermore, at step 812, the receiving device inserts the contents of one or more candidate header fields into the compressed header to generate the second header. This involves placing the copied content from step 810 into the appropriate positions within the compressed header. The device carefully reconstructs the second header by filling in missing fields guided by the availability bitmap. The result is a fully recovered second header containing all the necessary fields for the correct identification, routing, and processing of the second data unit. This step ensures the integrity and completeness of the second data unit, enabling it to be correctly processed by subsequent network nodes.

[0100] After restoring the second header, at step 814, the receiving device can replace the compressed header in the second data unit with the second header. This step involves modifying the second data unit in the input data buffer to ensure that the restored header is correctly placed and aligned. By replacing the compressed header with the fully restored second header, the receiving device ensures that the second data unit is now complete and ready for further processing or forwarding.

[0101] Figure 9 A block diagram of an example computing system 900 is depicted, in which various examples described herein can be implemented. In some examples, the computing system 900 can be configured to operate as a wireless networking device, such as an access point (AP). Figure 1 AP100) or receiving device (e.g., Figure 2 The receiving device 200 can perform various operations described in one or more of the previous figures.

[0102] The computing system 900 may include a bus 902 or other communication mechanism for conveying information, a hardware processor also referred to as processing resource 904, and a machine-readable storage medium 905 coupled to the bus 902 for processing information. In some examples, processing resource 904 may include one or more CPUs, semiconductor-based microprocessors, and / or other hardware devices suitable for retrieving and executing instructions stored in machine-readable storage medium 905. According to the examples presented herein, processing resource 904 may retrieve, decode, and execute instructions to generate a compressed header for data units and / or recover a complete header from the compressed header. As an alternative to retrieving and executing instructions, or in addition to retrieving and executing instructions, processing resource 904 may include one or more electronic circuits, including functional electronic components for executing one or more instructions, such as FPGAs, ASICs, or other electronic circuits.

[0103] In some examples, machine-readable storage medium 905 may include main memory 906, such as RAM, cache memory, and / or other dynamic storage devices, coupled to bus 902 for storing information and instructions to be executed by processing resource 904. Main memory 906 may also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by processing resource 904. When stored in a storage medium accessible to processing resource 904, such instructions make computing system 900 a dedicated machine customized to perform the operations specified in the instructions. Machine-readable storage medium 905 may further include read-only memory (ROM) 908 or other static storage devices coupled to bus 902 for storing static information and instructions for processing resource 904. Additionally, storage devices 910 (such as disks, optical discs, or USB thumb drives (flash drives)) may be provided in machine-readable storage medium 905 and coupled to bus 902 for storing information and instructions.

[0104] Furthermore, in some implementations, the computing system 900 may be coupled to a display 912, such as a liquid crystal display (LCD) (or a touch-sensitive screen), via a bus 902 for displaying information to a computer user. In some examples, an input device 914, including alphanumeric keys and other keys (physical or software generated and displayed on the touch-sensitive screen), may be coupled to the bus 902 for conveying information and command selections to the processing resource 904. Additionally, in some examples, another type of user input device may be a cursor control 916, such as a mouse, trackball, or cursor arrow keys that can be connected to the bus 902. The cursor control 916 may convey directional information and command selections to the processing resource 904 for controlling the movement of the cursor on the display 912. In some other examples, the same directional information and command selections as those for the cursor control may be received via touch on a touchscreen without a cursor.

[0105] In some examples, computing system 900 may include a user interface module that implements a GUI, which may be stored as executable software code executed by computing devices(s). As examples, this and other modules may include components (such as software components, object-oriented software components, class components, and task components), processes, functions, properties, procedures, subroutines, program code segments, drivers, firmware, microcode, circuit systems, data, databases, data structures, tables, arrays, and variables.

[0106] The computing system 900 also includes a network interface 918 coupled to a bus 902. The network interface 918 provides bidirectional data communication coupled to one or more network links connected to one or more local networks. For example, the network interface 918 may be an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem providing data communication connections to a corresponding type of telephone line. As another example, the network interface 918 may be a Local Area Network (LAN) card or a wireless communication unit (e.g., a Wi-Fi chip / module).

[0107] In some examples, machine-readable storage medium 905 (e.g., one or more of main memory 906, ROM 908, or storage device 910) stores instructions 907 that, when executed by processing resource 904, can cause processing resource 904 to perform one or more of the methods / operations described above. Instructions 907 can be stored on any of the main memory 906, ROM 908, or storage device 910. In some examples, instructions 907 can be distributed across one or more of the main memory 906, ROM 908, or storage device 910. In some examples, when computing system 900 is configured to operate as an AP (e.g., AP 100 transmitting data units with compressed headers), instructions 907 can include instructions that, when executed by processing resource 904, can cause processing resource 904 to perform... Figure 3 and Figure 4 Instructions for one or more of the methods described herein. In some examples, when computing system 900 is configured to act as a receiving device (e.g., receiving device 200 receives data units with compressed headers), instructions 907 may include instructions that, when executed by processing resource 904, may cause processing resource 904 to perform... Figure 7 and Figure 8 Instructions for one or more of the methods described in the document.

[0108] Unless otherwise expressly stated, the terms and phrases used in this document, and their variations, should be interpreted as open-ended rather than restrictive. As an example of the foregoing, the term “comprising” should be understood as “including, but not limited to,” etc. The term “example” is used to provide exemplary instances of the items under discussion, not an exhaustive or limiting list. The terms “a” or “an” should be interpreted as meaning “at least one,” “one or more,” etc. In some cases, the presence of extended words and phrases such as “one or more,” “at least,” “but not limited to,” or other similar phrases should not be interpreted as implying an intention or requirement for a narrower meaning where such extended phrases may not be present. Furthermore, the term “and / or” as used herein refers to and covers any and all possible combinations of the associated listed items. It will also be understood that although the terms first, second, etc., may be used herein to describe various elements, these elements should not be limited by these terms, as these terms are used only to distinguish one element from another, unless otherwise stated or indicated by the context.

Claims

1. A method for efficiently transmitting data units, comprising: A networked device receives a first data unit of a first session, wherein the first data unit includes a first header; The networked device receives a second data unit of the first session, wherein the second data unit includes a second header; The network device identifies one or more candidate header fields that have similar information in both the first header and the second header; The network device generates a compressed header by removing the contents of one or more candidate header fields from the second header. The networking device inserts an availability bitmap into the compressed header, wherein the availability bitmap includes flags corresponding to one or more header fields of the second header, the flags indicating whether the corresponding content exists in the compressed header; The networking device replaces the second header in the second data unit with the compressed header; and The networked device sends a first data unit including the first header and a second data unit including the compressed header.

2. The method according to claim 1, further comprising: The network device generates a first session identifier corresponding to the first session based on the first data unit; as well as The networking device stores the first data unit in a transmission queue corresponding to the first session identifier.

3. The method of claim 2, wherein generating the first session identifier comprises: A hash value is generated by applying a predefined hash function to one or more header fields of the first header.

4. The method according to claim 2, wherein generating the compressed header further includes: The first session identifier is inserted into the compressed header.

5. The method according to claim 4, further comprising: After the second header in the second data unit is replaced with the compressed header, the networking device stores the second data unit in the transmission queue.

6. The method of claim 5, wherein the sending comprises: The networked device generates an aggregated data unit, the aggregated data unit comprising a first data unit having the first header and a second data unit having the compressed header; and The aggregated data unit is sent by the networked device.

7. The method of claim 6, wherein each of the first data unit and the second data unit is a Media Access Control Protocol Data Unit (MPDU), and the aggregated data unit is an aggregated Media Access Control Protocol Data Unit (A-MPDU).

8. The method of claim 6, wherein each of the first data unit and the second data unit is a Media Access Control Service Data Unit (MSDU), and the aggregated data unit is an aggregated Media Access Control Service Data Unit (A-MSDU).

9. The method according to claim 8, further comprising: The aggregated data unit is received by the second networked device; The second network device extracts the first data unit and the second data unit from the aggregated data unit; The second network device generates a verification session identifier based on the first header of the first data unit; as well as In response to determining that the verification session identifier matches the first session identifier, the second networking device uses the availability bitmap and the first header to recover the second header from the compressed header.

10. The method of claim 9, wherein restoring the second header comprises: The second networking device identifies one or more candidate header fields based on the availability bitmap; The second network device copies the contents of one or more candidate header fields from the first header; as well as The second network device inserts the contents of one or more candidate header fields into the compressed header, thereby generating the second header at the second network device.

11. An access point (AP), comprising: Machine-readable storage medium that stores executable instructions; as well as Processing resources, connected to the machine-readable storage medium and configured to execute one or more of the instructions to: Receive a first data unit of a first session, wherein the first data unit includes a first header; Receive a second data unit of the first session, wherein the second data unit includes a second header; One or more candidate header fields that identify similar information in both the first header and the second header; A compressed header is generated by removing the contents of one or more candidate header fields from the second header; An availability bitmap is inserted into the compressed header, wherein the availability bitmap includes flags corresponding to one or more header fields of the second header, the flags indicating whether the corresponding content exists in the compressed header; Replace the second header in the second data unit with the compressed header; and Send the first data unit including the first header and the second data unit including the compressed header.

12. The AP of claim 11, wherein the processing resource is configured to execute one or more of the instructions to: Based on the first data unit, a first session identifier corresponding to the first session is generated; and The first data unit is stored in the transmission queue corresponding to the first session identifier.

13. The AP of claim 12, wherein, in order to generate the first session identifier, the processing resource is configured to execute one or more of the instructions to: generate a hash value by applying a predefined hash function to one or more header fields of the first header.

14. The AP of claim 12, wherein the compressed header includes the first session identifier.

15. The AP of claim 14, wherein the processing resource is configured to execute one or more of the instructions to: store the second data unit in the transmission queue after replacing the second header in the second data unit with the compressed header.

16. The AP of claim 15, wherein, in order to transmit the first data unit and the second data unit, the processing resource is configured to execute one or more of the instructions to: Generate an aggregated data unit, the aggregated data unit comprising a first data unit having the first header and a second data unit having the compressed header; and Send the aggregated data unit.

17. The AP according to claim 16, wherein the aggregated data unit is an aggregated media access control protocol data unit (A-MPDU) or an aggregated media access control service data unit (A-MSDU).

18. A method for recovering header information in a data unit, comprising: The networked device receives an aggregated data unit including a first data unit and a second data unit, wherein the first data unit includes a first header and the second data unit includes a compressed header, wherein the compressed header includes an availability bitmap and a first session identifier; The network device generates a verification session identifier based on the first header of the first data unit; In response to determining that the verification session identifier matches the first session identifier, the networking device identifies one or more candidate header fields for recovery from the compressed header based on the availability bitmap; The networked device recovers the second header by filling the compressed header with one or more candidate header fields from the corresponding header fields of the first header; as well as The networked device replaces the compressed header in the second data unit with the second header.

19. The method of claim 18, wherein restoring the second header comprises: The network device copies the contents of one or more candidate header fields from the first header; as well as The network device inserts the contents of one or more candidate header fields into the compressed header, thereby generating the second header at the network device.

20. The method of claim 18, wherein the aggregated data unit is an aggregated media access control protocol data unit (A-MPDU) or an aggregated media access control service data unit (A-MSDU).

Images