CN111183617A

CN111183617A - Method and apparatus for indicating data packet attributes in wireless communications

Info

Publication number: CN111183617A
Application number: CN201780095175.7A
Authority: CN
Inventors: 陈晓刚; 蒋锋; 李庆华; R·斯泰西
Original assignee: Intel IP Corp
Current assignee: Intel Corp
Priority date: 2017-12-19
Filing date: 2017-12-19
Publication date: 2020-05-19
Anticipated expiration: 2037-12-19
Also published as: WO2019125416A1; CN111183617B

Abstract

Methods and apparatus for indicating data packet attributes in wireless communications are disclosed. An example apparatus includes a data packet information determiner to determine a length of a data packet to be transmitted to a receiving device; and a data packet length encoder for encoding the length of the data packet using at least one of the sub-fields of the control information field of the data packet.

Description

Method and apparatus for indicating data packet attributes in wireless communications

Technical Field

The present disclosure relates generally to wireless fidelity connections (Wi-Fi) and, more particularly, to methods and apparatus for indicating data packet attributes in wireless communications.

Background

Many locations provide Wi-Fi to connect Wi-Fi enabled devices to a network, such as the internet. Wi-Fi-enabled devices include personal computers, video game consoles, mobile phones and devices, digital cameras, tablet computers, smart televisions, digital audio players, and the like. Wi-Fi allows Wi-Fi enabled devices to wirelessly access the Internet through a Wireless Local Area Network (WLAN). To provide a Wi-Fi connection to a device, a Wi-Fi access point exchanges radio frequency Wi-Fi signals with Wi-Fi enabled devices within signal range of an access point (e.g., a hotspot). Wi-Fi is implemented using a set of Medium Access Control (MAC) and physical layer (PHY) specifications, such as, for example, the Institute of Electrical and Electronics Engineers (IEEE)802.11 protocols.

Drawings

Fig. 1 is an illustration of communications using a wireless local area network Wi-Fi protocol to indicate data packet length and/or data packet format.

Fig. 2 is a block diagram of the example data packet information encoder of fig. 1.

Fig. 3 is a block diagram of the example data packet analyzer of fig. 1.

Fig. 4 is an example data packet that may be generated by a transmitting device.

Fig. 5 is an example data packet with a unique end-of-packet pattern that may be generated by a transmitting device.

Fig. 6 illustrates an example constellation pattern that may be generated by the transmitting apparatus of fig. 1.

Fig. 7 illustrates an example repetitive long training field pattern that may be generated by a transmitting apparatus.

Fig. 8 is a flow diagram representing example machine readable instructions that may be executed to implement the example data packet information encoder of fig. 1 and/or 2.

Fig. 9 is a flow diagram representing example machine readable instructions that may be executed to implement the example data packet analyzer of fig. 1 and/or 3.

Fig. 10 is a flow diagram representing example machine readable instructions that may be executed to implement the example data packet information encoder of fig. 1 and/or 2.

Fig. 11 is a flow diagram representing example machine readable instructions that may be executed to implement the example data packet analyzer of fig. 1 and/or 3.

Fig. 12 is a block diagram of a radio architecture according to some examples.

Fig. 13 illustrates example front end module circuitry for the radio architecture of fig. 12, in accordance with some examples.

Fig. 14 illustrates an example radio IC circuit for the radio architecture of fig. 12, according to some examples.

Fig. 15 illustrates example baseband processing circuitry for the radio architecture of fig. 12, according to some examples.

Fig. 16 is a block diagram of a processor platform structured to execute the example machine readable instructions of fig. 8-11 to implement the example data packet information encoder and/or the example data packet analyzer of fig. 2-3.

The figures are not drawn to scale. Wherever possible, the same reference numbers will be used throughout the drawings and the accompanying written description to refer to the same or like parts.

Detailed Description

Various locations (e.g., home, office, coffee shop, restaurant, park, airport, etc.) may provide Wi-Fi to Wi-Fi enabled devices (e.g., Stations (STAs)) to most easily connect the Wi-Fi enabled devices to the internet or any other network. The location may provide one or more Wi-Fi Access Points (APs) to output Wi-Fi signals to Wi-Fi enabled devices within range of the Wi-Fi signals (e.g., hotspots). A Wi-Fi AP is structured to wirelessly connect Wi-Fi enabled devices to the Internet through a Wireless Local Area Network (WLAN) using a Wi-Fi protocol (e.g., such as IEEE 802.11). The Wi-Fi protocol is a protocol for how an AP communicates with devices to provide access to the internet by sending Uplink (UL) transmissions to the internet and receiving Downlink (DL) transmissions from the internet.

As unlicensed frequency bands (e.g., 2.4 gigahertz (GHz) and/or 5GHz) become congested, new unlicensed frequency bands (e.g., 3.5GHz or 6GHz) may be open for civilian use. Many conventional Wi-Fi devices may not be able to operate in such new unlicensed frequency bands. Thus, as such new unlicensed bands become available, there is an incentive in the industry to remove and/or adjust the legacy preamble of data packets to reduce overhead without impacting coexistence. In addition, removing the legacy preamble (e.g., corresponding to 20 microseconds (us)) will improve efficiency. In a conventional data packet (e.g., a legacy data packet), a length subfield in an L-SIG field of the data packet indicates a data packet (e.g., a physical layer convergence protocol-protocol data unit (PPDU)) length and a data packet format (e.g., a Single User (SU) PPDU, a multi-user (MU) PPDU, an Extended Range (ER) PPDU, and a trigger-based (TB) PPDU).

If the legacy preamble including length and format information is removed in the new unlicensed band, the data packet length and data packet format need to be encoded as another part of the data packet. Examples disclosed herein provide various techniques for providing a data packet length, an end of data packet identifier, and/or a data packet format into a data packet for use in a new band. Examples disclosed herein reduce the number of bits used in conventional data packet transmission by generating new data packets that encode the data packet format and data packet length in already dedicated fields, thereby allowing the data packets to maintain the data packet format and length without the number of bits used for conventional data packets, thereby reducing the overhead of data transmission and improving the efficiency of data transmission.

In some examples disclosed herein, a transmitting device (e.g., an AP transmitting a DL data packet or an STA transmitting an UL data packet) may encode a data packet length by generating a new control information subfield in a control information field (e.g., HE-SIGA) of the data packet. Some examples disclosed herein encode data packet attributes that are to be removed when a legacy preamble is removed into already dedicated fields of the data packet. In this manner, data packet attributes may be encoded into data packets without utilizing additional bits, thereby reducing overhead and increasing efficiency. In some examples disclosed herein, a transmitting device may provide a unique time and/or frequency domain pattern to the end of a data packet to identify the end of the packet (e.g., such that a data packet length is not required). In some examples, the transmitting device may encode the data packet format by: (A) modulating a constellation of the control information subfield in a mode corresponding to a data packet format, (B) negating a set of repeated long training field values at different subcarrier frequencies of the data packet to correspond to the data packet format, (C) dedicating one or more bits of the control information field to correspond to the data packet format, and/or (D) setting the length field value to correspond to the data packet format based on a modulo calculation technique. Using examples disclosed herein, a legacy preamble may be removed to reduce overhead and improve efficiency while still providing data packet length and/or format.

Fig. 1 illustrates communication using a wireless local area network Wi-Fi protocol to indicate data packet length and/or data packet format. The example of fig. 1 includes an example AP100, an example STA102, an example application processor 104, an example data packet information encoder 106, an example radio architecture 108, an example data packet analyzer 110, and an example network 112. Although the illustrated example of fig. 1 includes one STA102, the example AP100 may communicate with any number of STAs. As described herein, the example AP100 and/or the example STA102 may be a transmitting device and/or a receiving device based on the current operation of the devices. For example, when the AP100 transmits a DL packet to the STA102, the example AP100 is a transmitting device and the example STA102 is a receiving device. In another example, when the STA102 transmits an UL packet to the AP100, the example AP100 is a receiving device and the example STA102 is a transmitting device.

The example AP100 of fig. 1 is a device that allows the example STA102 to wirelessly access the example network 112. The example AP100 may be a router, a modem-router, and/or any other device that provides wireless connectivity to the network 112. The router provides a wireless communication link with the STA. The router accesses the network 112 through a wired connection via a modem. Modem-router combines the functions of a modem and a router. In some examples, the AP100 is a STA communicating in the example STA 102. The example AP100 includes an example data packet information encoder 106 to generate data packets to be transmitted to the example STA102 and/or an example data packet analyzer 110 to process data packets transmitted by the example STA102, as further described below.

The example STA102 of fig. 1 is a Wi-Fi enabled computing device. Example STAs 102 may be, for example, computing devices, portable devices, mobile phones, smart phones, tablets, gaming systems, digital cameras, digital video recorders, televisions, set-top boxes, e-book readers, and/or any other Wi-Fi enabled device. The example STA102 includes an example data packet information encoder 106 to generate data packets to be transmitted to the example AP100 and/or an example data packet analyzer 110 to process data packets transmitted by the example AP100, as described further below.

The example application processor 104 of fig. 1 generates data to be transmitted to a device and/or performs operations based on data extracted from one or more data packets. The application processor 104 instructs the example data packet information encoder 106 to generate data packets based on the desired data to be transmitted. In addition, the application processor 104 receives data that has been received from the transmitting apparatus.

The example data packet information encoder 106 of fig. 1 generates a data packet when the example application processor 104 of fig. 1 communicates a data packet information encoder 106 instruction to transmit a data packet (e.g., a PPDU). As described above, there may be reasons to remove the legacy preamble used in the 2.4GHz and/or 5GHz frequency bands for other frequency bands (e.g., frequency bands of about 3.5GHz or 6 GHz). For example, removing the legacy preamble (a) facilitates coexistence between legacy and non-legacy devices in the new frequency band, (B) reduces overhead, and (C) simplifies preamble redesign of data packets. Thus, the example data packet information encoder 106 generates data packets that do not include a legacy preamble, thereby providing more efficient data transmission than legacy transmission. The legacy preamble includes a data packet length and a data packet format. For example, a PPDU data packet may correspond to four different formats: SU PPDU, MU PPDU, ER PPDU, and TB PPDU. Thus, the example data packet information encoder 106 may generate the data packet to include the data packet length and/or the data packet format, without including the legacy preamble. Once the data packet is generated, the data packet information encoder 106 transmits the data packet to the example radio architecture 108 for wireless transmission. An example radio architecture 108 is further described below in conjunction with fig. 12.

In some examples, the data packet information encoder 106 of fig. 1 may encode the data packet length into a Pre-or Post-control information subfield (e.g., Pre-HE-SIGA or Post-HE-SIGA) of a control information field (e.g., HE-SIGA) of the data packet. In another example, the data packet information encoder 106 may encode the unique time-domain and/or frequency-domain pattern at the end of the data field of the data packet. In this manner, the receiving device may determine when a data packet is complete (e.g., when the data transmission ends) by sensing the unique pattern.

In some examples, to encode the data packet format, the example data packet information encoder 106 of fig. 1 generates the data packet by: (A) modulating a constellation of control information subfields of a data packet, (B) negating a set of subcarrier frequency values in a repeated long training field (R-LTF), (C) storing a value in one or more bits of a control information field (e.g., HE-SIGA), and/or (B) storing a value corresponding to a modulo calculation in a length field of the data packet. The example data packet information encoder 106 may generate the data packet based on user and/or manufacturer configuration and/or based on a standard (e.g., an IEEE standard). An example data packet information encoder 106 is further described below in conjunction with fig. 2.

The example data packet analyzer 110 of fig. 1 analyzes a received packet based on how the example transmitting device encoded the data packet to identify a data packet length, an end of data packet transmission, and/or a data packet format. For example, the transmitting device may encode the data packet with a data packet length/end of data packet transmission and/or a data packet format based on the standard, condition, and/or preference. In some examples, a transmitting device may communicate how to encode a data packet based on a configuration that is communicated to an example receiving device during communication initiation. Thus, the example data packet analyzer 110 may process the received data packet based on the encoding configuration.

For example, the data packet analyzer 110 of fig. 1 may process the front or back control information subfields of the control information field to determine the data packet length. In another example, the data packet analyzer 110 may determine when a received data packet ends by identifying a predefined unique time-domain and/or frequency-domain pattern. In some examples, the data packet analyzer 110 sends an ACK when data transmission is stopped.

To determine the data packet format (e.g., SU PPDU, MU PPDU, ER PPDU, and TB PPDU), the example data packet analyzer 110 of fig. 1 may (a) determine a modulation constellation of the control information subfield to identify a constellation pattern corresponding to the transmission format, (B) determine a negation pattern of a subcarrier frequency of an R-LTF field corresponding to the transmission format, (C) determine a value corresponding to the transmission format stored in one or more bits of the control information field, and/or (D) perform a modulo technique on a value of a length field corresponding to the transmission format. An example data packet analyzer 110 is further described below in conjunction with fig. 3.

The example network 112 of FIG. 1 is a system of interconnected systems that exchange data. The example network 112 may be implemented using any type of public or private network, such as, but not limited to, the internet, a telephone network, a Local Area Network (LAN), a cable network, and/or a wireless network. To enable communication over the network 112, the example Wi-Fi AP100 includes a communication interface that supports connection to ethernet, Digital Subscriber Line (DSL), telephone line, coaxial cable, or any wireless connection, among others.

Fig. 2 is a block diagram of an example embodiment of the data packet information encoder 106 of fig. 1 as disclosed herein, the data packet information encoder 106 to indicate data packet attributes in a data packet. The example data packet information encoder 106 includes an example component interface 200, an example data packet length encoder 203, an example data packet format encoder 207, and an example data encoder 214. The example data packet length encoder 203 includes an example control information field encoder 204 and an example unique mode encoder 206. The example data packet format encoder 207 includes an example field modulator 208, an example field inverter 210, and an example length field value encoder 212.

The example component interface 200 of fig. 2 interfaces with components of a transmitting device (e.g., the example AP100 or the example STA102 of fig. 1) to transmit signals (e.g., data packets) and/or receive signals (e.g., instructions to generate data packets). For example, the component interface 200 may instruct the example radio architecture 108 of fig. 1 and/or 2 to transmit DL data and/or receive signals from the example application processor 104.

The example data packet information determiner 202 of fig. 2 determines attributes of the data packet based on instructions from the example application processor 104 of fig. 1. For example, the data packet information determiner 202 determines which data packet format and/or length of the data packet to use based on instructions from the application processor 104. In some examples, the example data packet information determiner 202 may determine the data packet format and/or the data packet length based on network parameters (e.g., capabilities of the receiving device, availability of the wireless medium, etc.).

The example data packet length encoder 203 encodes the data packet length information into the data packet without using additional bytes/bits corresponding to a legacy data packet preamble. In some examples, the data packet length encoder 203 may encode the data packet length as part of a field (e.g., a control information field or HE-SIGA) that is already utilized. In some examples, the data packet length encoder 203 encodes the end-of-packet pattern at the end of the data packet, thereby eliminating the need to encode the data packet length and reducing overhead. The example data packet length encoder 203 includes an example control information field encoder 204 and an example unique mode encoder 206 to encode the data packet length/end of packet mode.

The example control information field encoder 204 of fig. 2 encodes the control information field to include a front or rear control information subfield of the control information field of the data packet. For example, the control information field encoder 204 adjusts a legacy control information field (e.g., HE-SIGA field) to include a subfield corresponding to the length of the data packet. The control information field encoder 204 may encode the HE-SIGA subfield at the beginning of the control information field (e.g., a pre-HE-SIGA subfield) or at the end of the control information field (e.g., a post-HE-SIGA subfield). In addition, the example control information field encoder 204 may encode the control information subfield (e.g., pre-or post) as a self-decodable or non-self-decodable control information subfield. The self-decodable control information subfield includes its own tail bits to encode independently from other HE-SIGA fields. In this way, a receiving device using 802.11ax hardware can still decode the HE-SIGA field without requiring a hardware update at the expense of additional bits for the HE-SIGA field. The control information subfield that is not self-decodable does not include its own tail bits. In particular, the non-self-decodable control information subfield includes tail bits shared with adjacent HE-SIGA fields, thereby reducing the number of bits required for the HE-SIGA fields. The type of the front/rear control information subfield may be based on a predefined configuration and/or standard. Example HE-SIGA subfields are further described below in conjunction with fig. 4.

The example unique pattern encoder 206 of fig. 2 encodes a unique time-domain and/or frequency-domain pattern at the end of a data packet. In this manner, the receiving device may determine when the data packet ends by sensing the unique pattern without using X bits of overhead required to encode a length field (e.g., an example HE-SIGA field) in the PHY preamble. The unique mode may be transmitted to the receiving device during an initial communication between the example AP100 and the example STA 102. The unique time domain pattern corresponds to a repeatable signal that repeats, for example, three cycles. The unique time domain may be preset to be different from the time domain pattern of any other field, thereby reducing the likelihood of false triggers. The unique frequency domain pattern corresponds to a frequency domain phase shift of the constellation (e.g., a phase shift of the constellation between two adjacent subcarriers). The unique frequency domain may be preset to be different from the frequency domain pattern of any other field, thereby reducing the likelihood of false triggers. In some examples, the example unique pattern encoder 206 may encode the time-domain and frequency-domain patterns at the end of the data packet to identify the end of the data transmission.

The example data packet format encoder 207 encodes data packet format information into a data packet without using additional bytes/bits corresponding to a legacy data packet preamble. In some examples, the data packet format encoder 207 may encode the data packet format as part of a field already utilized (e.g., a control information field/HE-SIGA, a repeated LFT field, etc.), as described further below. The example data packet format encoder 207 includes an example field modulator 208, an example field inverter 210, and an example length field value encoder 212 to encode the data packet format in the data packet.

The example field modulator 208 of fig. 2 modulates a constellation of control signal subfields (e.g., HE-SIGA1, HE-SIGA2, PRE-/POST-HE SIGA) of a control information field (e.g., HE-SIGA) to generate a constellation pattern indicating a data packet format. For example, field modulator 208 may modulate each sub-field using quadrature phase shift keying (QBPSK or "Q") or using binary phase shift keying (BPSK or "B"), where Q corresponds to modulation of B rotated by 90 degrees. In this manner, the pattern of modulation corresponding to "Q" and/or "B" may correspond to a data packet format. For example, field modulator 2088 may modulate three control signal sub-fields to produce up to eight different combinations to correspond to different data packet formats. In such an example, modulating the three control signal subfields as "Q", "Q" may correspond to an MU PPDU, "B" may correspond to an ER PPDU, "Q", "B", "Q" may correspond to an SU PPDU, and "B", "Q", "B" may correspond to a TB PPDU, etc. Alternatively, any schema may correspond to any format. The mode-format correlation may be predefined in a standard and/or may be communicated to a receiving device during an initial communication between the example AP100 and the example STA 102.

The example field inverter 210 of fig. 2 utilizes a greenfield long training field (GF-LTF) and repeated GF-LTFs (R-GF-LTFs) to indicate different data packet formats. Although the examples disclosed herein correspond to a greenfield long training field, any type of long training field may alternatively be used. In conventional Wi-Fi protocols, the R-GF-LTF field is a repeated GF-LTF field that is used to minimize decoding errors, thereby improving the robustness of the transmission. The example field derotator 210 exploits the repetitive nature of the R-GF-LTF field by negating a set of values at different subcarrier frequencies of the R-GR-LTF to correspond to different data packet formats. For example, the field inverter 210 may (a) encode the subcarrier frequency of the R-GF-LTF to be the same as the GF-LTF to correspond to a first data packet format, (B) encode the subcarrier frequency of the R-GF-LTF to be the opposite of the GF-LTF to correspond to a second data packet format, (C) encode a first half of the subcarrier frequency of the R-GF LTF to be the same as the corresponding frequency of the GF-LTF and a second half of the subcarrier frequency of the R-GF-LTF to be the opposite of the corresponding frequency of the GF-LTF to correspond to a third data packet format, (D) encode the second half of the subcarrier frequency of the R-GF LTF to be the same as the corresponding frequency of the GF-LTF and the first half of the subcarrier frequency of the R-GF-LTF to be the opposite of the corresponding frequency of the GF-LTF, to correspond to a fourth data packet format, etc. The example field inverter 210 may generate an inversion pattern based on a configuration or standard and may send a pattern/format correlation to a receiving device during an initial communication.

The example length field value encoder 212 of fig. 2 encodes a value into a length field of a data packet to correspond to a data packet format. For example, the LENGTH field value encoder 212 may convey one bit of information by setting a value in the LENGTH field (LENGTH) equal to 3(N) + m, where N is an integer greater than zero and m is one or two. Thus, one bit of information is embedded in m, LENGTH modulo (mod)3, where m is 1 or 2. In this manner, the receiving device may execute a LENGTH mod 3 function to determine the value of m, where m corresponds to one bit of information (e.g., m-1 corresponds to a first data packet format and m-2 corresponds to a second data packet format). In some examples, the length field value encoder 212 stores the value into one or more bits of the control information field (e.g., reserved bits of the control information field) to correspond to a data packet format. Since more than two data formats may be to be identified in a data packet, length field value encoding techniques may be combined with other techniques (e.g., constellation modulation, repeated long training field negation, bit values of control information fields, etc.) to correspond to additional data formats. In some examples, any combination of the above techniques may be utilized to indicate a data packet format in a data packet.

The example data encoder 214 of fig. 2 encodes data from the example application processor 104 into data fields of a data packet. The data fields are further described below in conjunction with fig. 4.

Fig. 3 is a block diagram of an example embodiment of the example data packet analyzer 110 of fig. 1 disclosed herein, the example data packet analyzer 110 to determine data packet attributes from received data packets. The example data packet analyzer 110 includes an example component interface 300, an example field analyzer 302, an example pattern recognizer 304, an example constellation determiner 306, and an example mode executor 308.

The example component interface 300 of fig. 3 interfaces with components of a receiving device to receive signals (e.g., data packets) and/or transmit signals (e.g., instructions). For example, the component interface 300 may instruct the example radio architecture 108 of fig. 1 and/or 12 to send an Acknowledgement (ACK), receive a data packet from a sending device, and/or send a decoded data packet to the example application processor 104. In some examples, each received data packet is processed as it is received. In some examples, the data packets are grouped and processed together by the example data packet analyzer 110.

The example field analyzer 302 of fig. 3 processes fields of a received data packet to identify a data packet type, a data packet length, and/or an end of packet pattern based on the received data packet. For example, the field analyzer 302 may process the data packet based on a front or rear control information subfield of the control information field to identify a data packet length. As described further below in connection with fig. 4, the control information subfield may be self-decodable (e.g., corresponding to its own tail bits) or non-self-decodable (e.g., corresponding to sharing tail bits with neighboring control information subfields of the control information field). The pre-control information subfield is encoded at the beginning of the control information field and the post-control information subfield is encoded at the end of the control information field. How the control information is encoded (e.g., pre-and post-and/or self-decodable and non-self-decodable) may be predetermined based on a standard and/or may be pre-communicated to a receiving device during an initial communication. In some examples, the field analyzer 302 compares the subcarrier frequencies of the GF-LTF and the R-GF-LTF to determine whether the subcarrier frequencies of the GF-LTF and the R-GF-LTF correspond to the negation of the values of the fields at different subcarrier frequencies to identify a data packet format. As described above in connection with fig. 2, the example data packet information encoder 106 may negate a set of values at the subcarrier frequency of the R-GF-LTF to correspond to the data packet format. Thus, the field analyzer 302 identifies negations in the R-GF-LTF to identify data packet formats based on the comparison to the GF-LTF. In some examples, field analyzer 302 processes the field to identify a value in one or more bits of the data packet corresponding to the data packet format.

The example pattern recognizer 304 of fig. 3 processes the received data packet to identify a predetermined pattern (e.g., an end of packet pattern) corresponding to the end of the data packet. As described above in connection with fig. 2, the example data packet information encoder 106 may encode the unique time-domain and/or frequency-domain pattern at the end of the data packet. The example pattern identifier 304 attempts to identify a unique time and/or frequency pattern to identify when transmission of the data packet ends. The unique pattern may be predetermined by a standard and/or may be communicated to a receiving device during an initial communication between the example AP100 and the STA 102.

The example constellation determiner 306 of fig. 3 determines the constellation(s) of the control information subfield(s) to identify a constellation pattern corresponding to the data packet format. For example, constellation determiner 306 may demodulate one or more control information subfields (e.g., pre-/post-HE-SIGA, HE-SIGA1, and/or HE-SIGA2) to determine whether the control information subfields are modulated with BPSK (B) or QBPSK (Q) to generate X bit patterns (e.g., Q; Q; Q, B; B; B, Q; B; B, Q; Q; B, etc., when the number of control information subfields for a pattern (X) is 3), where each pattern may correspond to a different data packet format. An example constellation pattern is further described below in conjunction with fig. 6.

The example modulo executor 308 of fig. 3 performs a modulo function of a length field of a received data packet to identify or partially identify a data packet format. For example, the modulo executor 308 collects values stored in a LENGTH field of the data packet and executes a modulo function (e.g., LENGTH mod 3) to identify a bit value (e.g., 1 or 2) corresponding to the data packet format.

Fig. 4 is an example data packet unit (e.g., PPDU)400 that may be generated by the example AP100 and/or the example STA102 of fig. 1 and that includes fields corresponding to a data packet length and/or a data packet format. The example PPDU 400 includes an example GF-LTF field 402, an example R-GF-LTF field 404, an example HE-SIGA (e.g., control information) field 406, and an example data field 408. The example HE-SIGA field 406 includes an example HE-SIGA1 (e.g., control information) subfield 410, an example HE-SIGA2 subfield 412, an example post-HE SIGA subfield 414 (e.g., corresponding to an example self-decodable post-HE SIGA subfield 414a or an example non-self-decodable post-HE SIGA subfield 414b), and an example pre-HE SIGA subfield 416 (e.g., corresponding to an example self-decodable pre-HE SIGA subfield 416a or an example non-self-decodable pre-HE SIGA subfield 416 b). As an example of fig. 4, the example data packet unit 400 does not include a legacy preamble. The example pre-/post-HE SIGA subfields 414, 416 include

example tail bits

418a, 424a, 426b, 432 a;

example length bits

420a, 420b, 428a, 428b and example reserved

bits

422a, 422b, 430a, 430 b.

The example GF-LTF field 402 and the example R-GF-LTF field 404 of fig. 4 are fields that may be used to correspond to a data packet format by negating a set of values in the subcarrier band of the R-GF-LTF field 404. For example, a subcarrier value corresponding to the example R-GF-LTF 404 that is the same as the subcarrier value of the example GF-LTF field 402 may correspond to a first data packet type (e.g., MU PPDU), a subcarrier value corresponding to the example R-GF-LTF 404 that is opposite the subcarrier value of the example GF-LTF field 402 may correspond to a second data packet type (e.g., SU PPDU), a first set of subcarrier values corresponding to the example R-GF-LTF 404 that is opposite the first set of subcarrier values of the example GF-LTF field 402 (e.g., half the subcarrier frequency value) may correspond to a third data packet type (e.g., ER PPDU), and so on. The GF-LTF field 402 and the example R-GF-LTF field 404 are further described below in conjunction with fig. 7.

The example HE-SIGA field 406 of fig. 4 includes an example HE-SIGA1 sub-field 410, an example HE-SIGA2 sub-field 412, and an example post-HE-SIGA sub-field 414 or an example pre-HE-SIGA sub-field 416. The example HE-SIGA1 sub-field 410 and the example HE-SIGA2412 include control data (e.g., reveal Modulation and Coding Scheme (MCS) data, encoded data, spatial stream data, etc.). The example post-HE-SIGA subfield 414 and the example pre-HE-SIGA subfield 416 include

data bits

420a, 420b, 428a, 428b corresponding to the data bits in the post-/

pre-HE SIGA subfield

414, 416; the length/number of the

reserved bits

422a, 422b, 430a, 430b and

tail bits

424a, 426b, 432a is 28 bits. In addition, the example post-HE-SIGA subfield 414 and the example pre-HE-SIGA subfield 416 may be self-decodable (e.g., corresponding to subfields 414a, 416a) or non-self-decodable (e.g., corresponding to subfields 414b, 416 b). The self-decodable subfields have fewer reserved

bits

422a, 430a (e.g., 10 bits and 16 bits) to make room for the

special tail bits

424a, 432 a. In this manner, the example self-decodable subfields 414a, 416a are independently encoded such that 11ax hardware can decode the post-HE SIGA subfield 414. The non-self-decodable bits have more

reserved bits

422b, 430b (e.g., 16 bits and 10 bits), and share tail bits 426b with adjacent HE-SIGA subfields (e.g., the tail bits of example HE-SIGA 1410 are now shown). For example, example self-decodable subfield 414b shares tail bits 426b with example HE-SIGA2 subfield 412, and example self-decodable subfield 416b shares tail bits with example HE-SIGA1 subfield 410. In this way, the example non-self-

decodable field

414a, 416a is encoded with the adjacent sub-fields.

Fig. 5 illustrates an example data packet unit (PPDU)500, the example data packet unit (PPDU)500 having an example end of packet mode field 502 to identify the end of a data packet (e.g., to a receiving device) to eliminate the need to encode the length of the data packet in the data packet, thereby reducing overhead. The example data packet unit 500 includes the example GF-LTF field 402, the example R-GF-LTF field 404, and the example HE-SIGA field 406 of FIG. 4. The example data packet unit 500 further includes an example end-of-packet mode field 502, an example time-domain mode 504, and an example frequency-domain mode 506.

As described above in connection with fig. 2, the example data packet information encoder 106 may encode the example data packet unit 500 of fig. 5 using the example end-of-packet mode field 502 so that the receiving device may determine that the data packet is ended without encoding the length field in the example data packet unit 500. In this way, the size of the data packet can be reduced. The example end-of-packet field may be encoded using the example time-domain pattern 504 and/or the example frequency-domain pattern 506.

The example time domain pattern 504 of fig. 5 is a unique periodic signal corresponding to the end of the data packet unit 500. The example time domain pattern 504 may be a pattern of signals that do not correspond to any other field of the data packet unit 500, thereby reducing erroneous end of packet triggers for the receiving device. Although the example of fig. 5 corresponds to a particular time-domain pattern 504 (e.g., a sinusoid with a period of 2 mus repeated three times), any unique time-domain pattern may be used.

The example frequency domain pattern 506 is the only frequency signal pattern corresponding to the end of the data packet unit 500. The example frequency domain pattern 506 may be a pattern of signals that do not correspond to any other field of the data packet unit 500, thereby reducing erroneous end of packet triggers for the receiving device. Although the example of fig. 5 corresponds to a particular frequency domain pattern 506 (e.g., a spectrum in which each subsequent frequency is offset by 180 degrees), any unique frequency domain pattern may be used.

Fig. 6 is an illustration of three different constellation patterns that may be modulated by the example data packet information encoder 106, which example data packet information encoder 106 may be used to encode data format information into a data packet without the need for dedicated bits, thereby reducing the overhead of data packet transmission. The example of fig. 6 includes a first example constellation pattern 600, a second example constellation pattern 602, a third example constellation pattern 604, a first example HE-SIGA field symbol 606, a second example HE-SIGA field symbol 608, and a third example HE-SIGA field symbol 610. Example HE-

SIGA field symbols

606, 608, 610 correspond to the example HE-

SIGA subfields

410, 412, 414/416 of fig. 4. Although the example of fig. 6 includes three field symbols, any number of field symbols may be used.

The

example constellation patterns

600, 602, 604 of fig. 6 represent three different data packet formats. For example, the first constellation pattern 600 may correspond to a MU PPDU, the second constellation pattern 602 may correspond to a SU PPDU, and the third constellation pattern 604 may correspond to an ER PPDU, and further, other patterns may correspond to additional data pattern formats (e.g., having 8 different patterns in total for the three

field symbols

606, 608, 610). In each

constellation pattern

600, 602, 604, the example HE-

SIGA field symbols

606, 608, 610 are modulated with QBPSK or BPSK constellations. For example, in the first constellation pattern 600, all

field symbols

606, 608, 610 are modulated using the QBPSK constellation; in the second constellation pattern 602, all

field symbols

606, 608, 610 are modulated using a BPSK constellation; and in a third constellation pattern 604 the first and

third field symbols

606, 610 are modulated with a BPSK constellation and the second field symbol 608 is modulated with a QBPSK constellation. In some examples, HE-SIGA field 406 may include only one or two field symbols (e.g., HE-SIGA 1410 and/or HE-SIGA 2412). In such examples, the constellation pattern may include only one or two field symbols (e.g., corresponding to two or four different data formats, respectively).

Fig. 7 illustrates two example GF-LTF/R-GF-

LTF inversion patterns

700, 710 that may be encoded by the example data packet information encoder 106 to encode data format information into a data packet without the need for dedicated bits, thereby reducing the overhead of data packet transmission. The

example negation patterns

700, 710 include the example GF-LTF field 404 and the example R-GF-LTF field 404 of FIG. 4.

The first example negation pattern 700 of fig. 7 is not included at each subcarrier frequency (e.g., fz)₁-fz_n) Any negation of the value of (a). Thus, the subcarrier values at each frequency of the GF-LTF 404 are correlated with the subcarrier values at the corresponding frequency of the R-GF-LTF 404The same is true. This pattern corresponds to the first data packet pattern. The second example negation mode 710 includes negation of values at each subcarrier frequency. Thus, the value at each subcarrier frequency of the GF-LTF 402 is opposite to the value at the corresponding subcarrier frequency of the R-GF-LTF 404. This pattern corresponds to the second data packet pattern. In some examples, additional negation patterns may be generated to correspond to additional data packet patterns. For example, a first set of subcarrier frequencies (fz) may be mapped₁To fz_n/2) Of the first set of subcarrier values (a)₁To a_N/2) Negating without a second set of subcarrier frequencies (fz)_n/2+1To fz_n) Of (e.g., a)_N/2+1To a_N) Negated to correspond to the third data packet pattern.

Although an example manner of implementing the example data packet information encoder 106 and the example data packet analyzer 110 of fig. 1 is shown in fig. 2 and 3, one or more of the elements, processes and/or devices shown in fig. 2 and 3 may be combined, divided, rearranged, omitted, eliminated and/or implemented in any other way. Further, the example component interface 200, the example control information field encoder 204, the example unique pattern encoder 206, the example field modulator 208, the example field inverter 210, the example length field value encoder 212, and/or, more generally, the example data packet length encoder 203, the example data packet format encoder 207, and/or the example data packet information encoder 106 of fig. 2, and the example component interface 300, the example field analyzer 302, the example pattern identifier 304, the example constellation determiner 306, the example mode executor 308, and/or, more generally, the example data packet analyzer 110 of fig. 3 may be implemented by hardware, software, firmware, and/or any combination of hardware, software, and/or firmware. Thus, for example, the example component interface 200, the example control information field encoder 204, the example unique mode encoder 206, the example field modulator 208, the example field inverter 210, the example length field value encoder 212, and/or the more generally example data packet length encoder 203, the example data packet format encoder 207, and/or the example data packet information encoder 106 of FIG. 2, and any of the example component interface 300, the example field analyzer 302, the example pattern recognizer 304, the example constellation determiner 306, the example modulo executor 308, and/or, more generally, the example data packet analyzer 110 of fig. 3 may be implemented by one or more analog or digital circuits, logic circuits, programmable processors, Application Specific Integrated Circuits (ASICs), Programmable Logic Devices (PLDs), and/or Field Programmable Logic Devices (FPLDs). When reading any of the device or system claims of this patent to encompass purely software and/or firmware implementations, at least one of the example component interface 200, the example control information field encoder 204, the example unique pattern encoder 206, the example field modulator 208, the example field inverter 210, the example length field value encoder 212, and/or, more generally, the example data packet length encoder 203, the example data packet format encoder 207, and/or the example data packet information encoder 106 of FIG. 2, and the example component interface 300, the example field analyzer 302, the example pattern identifier 304, the example constellation determiner 306, the example modulo executor 308, and/or, more generally, the example data packet analyzer 110 of FIG. 3 is hereby expressly defined to include a non-transitory computer-readable storage device or memory disk, such as memory, Digital Versatile Disks (DVDs), Compact Disks (CDs), blu-ray disks, etc., including software and/or firmware. Still further, the example data packet information encoder 106 of fig. 2 and/or the example data packet analyzer 110 of fig. 3 may include one or more elements, processes and/or devices and/or may include more than one of any or all of the illustrated elements, processes and devices in addition to, or in place of, the elements, processes and/or devices illustrated in fig. 2 and/or 3.

A flowchart representative of example machine readable instructions for implementing the example data packet information encoder 106 of fig. 2 is shown in fig. 4, and flowcharts representative of example machine readable instructions for implementing the example data packet analyzer 110 of fig. 3 are shown in fig. 8-11. In this example, the machine readable instructions comprise a program for execution by a processor (such as the processor 1612 shown in the example processor platform 1600 discussed below in connection with fig. 16). The program may be embodied in software stored on a non-transitory computer readable storage medium such as: CD-ROM, floppy disk, hard drive, Digital Versatile Disk (DVD), blu-ray disk, or memory associated with the processor 1612, but the entire program and/or parts thereof could alternatively be executed by a device other than the processor 1612 and/or embodied in firmware or dedicated hardware. Further, although the example program is described with reference to the flowcharts shown in fig. 8-11, many other methods of implementing the example data packet information encoder 106 and/or the example data packet analyzer 110 may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined. Additionally or alternatively, any or all of the blocks may be implemented by: one or more hardware circuits (e.g., discrete and/or integrated analog and/or digital circuits, Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), comparators, operational amplifiers (op-amps), logic circuits, etc.) structured to perform corresponding operations without the execution of software or firmware.

As described above, the example processes of fig. 8-11 may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as: a hard disk drive, flash memory, read-only memory, compact disk, digital versatile disk, cache, random-access memory, and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended periods of time, permanently, brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage and/or storage disk and to exclude propagating signals and to exclude transmission media. The terms "comprising" and "including" (and all forms and tenses thereof) are used herein as open-ended terms. Thus, whenever a claim recites anything following "including" or "comprising" any form thereof (e.g., comprising, including, etc.), it should be understood that additional elements, terms, or the like may be present without departing from the scope of the corresponding claim. As used herein, the phrase "at least" when used as a transitional term in the preamble of a claim is open-ended in the same way as the term "comprising" and "comprises" is open-ended.

Fig. 8 is an example flow diagram 800 representing example machine readable instructions that may be executed by the example data packet information encoder 106 of fig. 1 and/or 2 to indicate a data packet length and/or an end of a data packet. Although the example of fig. 8 is described in connection with the example AP100 and the example STA102 in the network of fig. 1, the instructions may be performed by any type of AP and/or STA in any network.

At block 802, the example component interface 200 determines whether the AP100/STA102 is ready to transmit a data packet to a receiving device. For example, when the example application processor 104 of fig. 1 and/or 12 transmits an instruction to transmit a data packet, the example component interface 200 may determine that the AP100/STA102 is ready to transmit the data packet. If the example component interface 200 determines that the sending device is not sending data packets to the receiving device (block 802: no), the process continues to monitor for instructions from the application processor 104 until an instruction to send a data packet is received. If the example component interface 200 determines that the transmitting device is to transmit a data packet to the receiving device (block 802: Yes), the example control information field encoder determines whether the data packet length is to be encoded in a control information field (e.g., the example HE-SIGA field 406 of FIG. 4) (block 804). For example, the data packet length may be encoded in the control information field based on user and/or manufacturing preferences and/or based on a standard (e.g., an IEEE standard).

If the example control information field encoder 204 determines that the data packet length is not to be encoded in the control information field (block 804: no), the process continues to block 808. If the example control information field encoder 204 determines that the data packet length is to be encoded in the control information field (block 804: yes), the example control information field encoder 204 encodes the data packet length into a front or back control information subfield of the data packet (block 806). For example, the control information field encoder 204 may encode the example front or rear control information subfields 414, 416, as described above in connection with fig. 4.

At block 808, the example unique pattern encoder 206 determines whether an end-of-packet pattern is to be encoded in the data packet. For example, the end-of-packet pattern may be encoded in the data packet based on user and/or manufacturing preferences and/or based on a standard (e.g., an IEEE standard). If the example unique pattern encoder 206 determines that the end-of-packet pattern will not be encoded in the data packet (block 808: no), the process continues to block 812. If the example unique pattern encoder 206 determines that an end-of-packet pattern is to be encoded in the data packet (block 808: Yes), the example unique pattern encoder 206 encodes a unique time-domain and/or frequency-domain pattern at the end of the data packet (block 810), as described above in connection with FIG. 5. At block 812, the example data encoder 214 encodes the data into a data packet (e.g., the example data field 408 of fig. 4). At block 814, the example component interface 200 interfaces with the example radio architecture 108 to transmit the data packet to a receiving device.

Fig. 9 is an example flow diagram 900 representing example machine readable instructions that may be executed by the example data packet analyzer 110 of fig. 1 and/or 3 to determine a data packet length and/or an end of a data packet from a received data packet. Although the example of fig. 9 is described in connection with the example AP100/STA102 in the network of fig. 1, the instructions may be performed by any type of AP/STA in any network.

At block 902, the example component interface 300 determines whether the example radio architecture 108 of fig. 1 and/or 12 has received a data packet to a transmitting device. If the example component interface 300 determines that a data packet has not been received from a sending device (block 902: no), the process continues with interfacing with the receiving device component until a data packet has been received. If the example component interface 300 determines that a data packet has been received from a transmitting device (block 902: Yes), the example field analyzer 302 determines whether the data packet length is encoded in a control information field (e.g., the example HE-SIGA field 406 of FIG. 4) (block 904). For example, the data packet length may be encoded in the control information field based on user and/or manufacturing preferences and/or based on a standard (e.g., an IEEE standard). The receiving device may determine, based on the standard and/or initial communication between the AP100 and the STA102, that the data packet length and/or data corresponding to the encoding (e.g., pre-and post, self-decodable and non-self-decodable) is encoded in the control information field.

If the example field analyzer 302 determines that the data packet length is not encoded in the control information field (block 904: no), the process continues to block 908. If the example field analyzer 302 determines that the data packet length is encoded in the control information field (block 904: yes), the example field analyzer 302 processes the front or back control information field sub-field of the control information field (e.g., the example HE-SIGA406) to determine the data packet length (block 906). For example, the control information subfield may be encoded using the example front or rear control information subfields 414, 416, as described above in connection with fig. 4.

At block 908, the example pattern recognizer 304 determines whether to encode an end-of-packet pattern in the data packet. For example, the end-of-packet pattern may be encoded in the data packet based on user and/or manufacturing preferences and/or based on a standard (e.g., an IEEE standard). If the example pattern recognizer 304 determines that the end-of-packet pattern is not to be encoded in the data packet (block 908: no), the process continues to block 912. If the example pattern identifier 304 determines that an end-of-packet pattern is encoded in the data packet (block 908: Yes), the example pattern identifier 304 determines the end of the data packet (block 910) by sensing the unique time-domain and/or frequency-domain pattern received (e.g., via the example component interface 300), as described above in connection with FIG. 5. At block 912, the example component interface 300 interfaces with the radio architecture 108 to send an acknowledgement to the sending device.

Fig. 10 is an example flow diagram 1000 representative of example machine readable instructions that may be executed by the example data packet information encoder 106 of fig. 1 and/or 2 to indicate a data packet format. Although the example of fig. 10 is described in connection with the example AP100/STA102 in the network of fig. 1, the instructions may be performed by any type of AP and/or STA in any network. The data packet format may be encoded in the data packet in various ways based on user and/or manufacturing preferences and/or based on a standard (e.g., an IEEE standard), as described below.

At block 1002, the example component interface 200 determines whether the sending device is ready to send a data packet to the receiving device. For example, when the example application processor 104 of fig. 1 and/or 12 sends an instruction to send a data packet, the example component interface 200 may determine that the sending device is ready to send the data packet. If the example component interface 200 determines that the sending device is not sending data packets to the receiving device (block 1002: no), the process continues to monitor for instructions from the application processor 104 until an instruction to send a data packet is received. If the example component interface 200 determines that the transmitting device is to transmit a data packet to the receiving device (block 1002: yes), the example field modulator 208 determines whether a data packet format is indicated in a constellation of control information fields (e.g., the example HE-SIGA406 of fig. 4) (block 1004).

If the example field modulator 208 determines that the data packet format will not be indicated in the constellation of the control information field (block 1004: no), the process continues to block 1008. If the example field modulator 208 determines that the data packet format is to be indicated in the constellation of the control information field (block 1004: yes), the example field modulator 208 modulates the constellation of the control information subfield (e.g., one or more of the example HE-

SIGA subfields

410, 412, 114, 416) in a constellation pattern corresponding to the data packet format (block 1006), as described above in connection with fig. 6. The correlation between constellation patterns and data packet formats may be predefined and/or based on a standard (e.g., an IEEE standard).

At block 1008, the example field inverter 210 determines whether a data packet format will be indicated in the R-LTF (e.g., an inversion mode is used between the GF-LTF 402 and the R-GF-LTF 404). If the example field inverter 210 determines that the data packet format will not be indicated in the R-LTF (block 1008: NO), the process continues to block 1012. If the example field inverter 210 determines that a data packet format is to be indicated in the R-LTF (block 1008: YES), the example field modulator 208 inverts a set of subcarrier values of the repeated long training field to correspond to the data packet format (block 1010). For example, the field modulator 208 may negate all, none, or a portion of the R-GF-LTF subcarrier frequency values to correspond to the data packet format, as described above in connection with FIG. 7.

At block 1012, the example length field value encoder 212 determines whether a data packet format is to be indicated in one or more bits of a control information field (e.g., the example HE-SIGA406 of fig. 4). If the example length field value encoder 212 determines that the data packet format will not be indicated in one or more bits of the control information field (block 1012: no), the process continues to block 1016. If the example length field value encoder 212 determines that the data packet format is to be indicated in one or more bits of the control information field (block 1012: yes), the example length field value encoder 212 stores a value in one or more bits of the control information field (e.g., HE-SIGA) to correspond to the data packet format (block 1014). For example, the length field value encoder 212 may encode the data packet format information in a reserved subfield of the control field.

At block 1016, the example length field value encoder 212 determines whether a data packet is to be indicated based on a length field value (e.g., a value stored in the length field to correspond to the length field of the data packet). If the example length field value encoder 212 determines that no data packet is to be indicated based on the length field value (block 1016: no), the process continues to block 1020. If the example length field value encoder 212 determines that a data packet is to be indicated based on the length field value (block 1016: yes), the example length field value encoder 212 sets the length field value to correspond to the data packet format using modulo techniques (block 1018). For example, the example LENGTH field value encoder 212 may encode a value to correspond to m LENGTH mod 3 such that m is 1 or 2 to correspond to two different data formats. As described above, the data packet format may be encoded using a combination of the above techniques. At block 1020, the example data encoder 214 encodes the data into a data packet (e.g., the example data field 408 of fig. 4). At block 1022, the example component interface 200 interfaces with the example radio architecture 108 to transmit the data packet to a receiving device.

Fig. 11 is an example flow diagram 1100 representative of example machine readable instructions that may be executed by the example data packet analyzer 110 of fig. 1 and/or 3 to determine a data packet format from a received data packet. Although the example of fig. 11 is described in connection with the example AP100/STA102 in the network of fig. 1, the instructions may be performed by any type of AP/STA in any network. The data packet format may be encoded in the data packet in various ways based on user and/or manufacturing preferences and/or based on a standard (e.g., an IEEE standard), as described below. In some examples, how the data packet format is encoded into the data packet may be communicated between the example AP100 and the example STA102 during the initial communication.

At block 1102, the example component interface 300 determines whether a data packet has been received from a transmitting device. If the example component interface 300 determines that a data packet has not been received from the example sending device (block 1102: no), the process continues with interfacing with the receiving device component until a data packet has been received. If the example component interface 300 determines that a data packet has been received from a transmitting device (block 1102: yes), the example constellation determiner 306 determines whether a data packet format is indicated in a constellation of a control information field (e.g., the example HE-SIGA406 of fig. 4) (block 1104).

If the example constellation determiner 306 determines that a data packet format is not indicated in the constellation of the control information field (block 1104: no), the process continues to block 1108. If the example constellation determiner 306 determines that the data packet format is indicated in the constellation of the control information field (block 1104: yes), the example constellation determiner 306 determines the data packet format based on the constellation of the control information subfield (e.g., one or more of the example HE-

SIGA subfields

410, 412, 114, 416) in a constellation pattern corresponding to the data packet format (block 1106), as described above in connection with fig. 6. The correlation between constellation patterns and data packet formats may be predefined and/or based on a standard (e.g., an IEEE standard).

At block 1108, the example pattern recognizer 304 determines whether a data packet format is indicated in the R-LTF (e.g., based on a negation pattern between the GF-LTF 402 and the R-GF-LTF 404). If the example pattern recognizer 304 determines that a data packet format is not indicated in the R-LTF (block 1108: NO), the process continues to block 1112. If the example pattern recognizer 304 determines that a data packet format is indicated in the R-LTF (block 1108: Yes), the example pattern recognizer 304 determines the data packet format based on the negation of a set of subcarrier values for the repeated long training field (block 1110). For example, the pattern identifier 304 may determine to negate all, none, or a portion of the R-GF-LTF subcarrier frequency values to correspond to a data packet format, as described above in connection with FIG. 7.

At block 1112, the example field analyzer 302 determines whether a data packet format is indicated in one or more bits of a control information field (e.g., the example HE-SIGA406 of fig. 4). If the example field analyzer 302 determines that a data packet format is not indicated in one or more bits of the control information field (block 1112: no), the process continues to block 1116. If the example field analyzer 302 determines that the data packet format is indicated in one or more bits of the control information field (block 1112: yes), the example field analyzer 302 determines the data packet format based on the value(s) of the one or more bits of the control information field (e.g., HE-SIGA) (block 1114). For example, the field analyzer 302 may process data packet format information from the reserved subfield of the control information field.

At block 1116, the example modulo executor 308 determines whether a data packet is indicated based on a length field value (e.g., a value stored in the length field to correspond to the length field of the data packet). If the example modulo executor 308 determines that a data packet is not indicated based on the length field value (block 1116: no), the process ends. If the example modulo executor 308 determines that a data packet is indicated based on the length field value (block 1116: yes), the example modulo executor 308 performs a modulo function using the length field value to determine a data packet format (block 1118). For example, the example modulo executor 308 may determine a value of m, where m is LENGTH mod 3 such that m is 1 or 2 to correspond to two different data formats. As described above, the data packet format may be determined using a combination of the above techniques.

Fig. 12 is a block diagram of the radio architecture 108 of fig. 1, the radio architecture 108 being implementable in an example AP100 and/or an example STA102, according to some examples. The radio architecture 108 may include radio Front End Module (FEM) circuitry 1204, radio IC circuitry 1206, and baseband processing circuitry 1208. The radio architecture 108 as shown includes Wireless Local Area Network (WLAN) functionality and Bluetooth (BT) functionality, but examples are not so limited. In this disclosure, "WLAN" and "Wi-Fi" are used interchangeably.

The FEM circuitry 1204 may include WLAN or Wi-Fi FEM circuitry 1204a and Bluetooth (BT) FEM circuitry 1204 b. WLAN fem circuitry 1204a may include a receive signal path including circuitry configured to operate on WLAN RF signals received from one or more antennas 1201, amplify the received signals, and provide an amplified version of the received signals to WLAN radio IC circuitry 1206a for further processing. The BT FEM circuitry 1204b may include a receive signal path that may include circuitry configured to operate on a BTRF signal received from one or more antennas 1201, amplify the received signal, and provide an amplified version of the received signal to the BT radio IC circuitry 1206b for further processing. The FEM circuitry 1204a may also include a transmit signal path, which may include circuitry configured to amplify WLAN signals provided by the radio IC circuitry 1206a for wireless transmission through one or more of the antennas 1201. Additionally, the FEM circuitry 1204b may also include a transmit signal path, which may include circuitry configured to amplify BT signals provided by the radio IC circuitry 1206b for wireless transmission through one or more antennas. In the example of fig. 12, although FEM 1204a and FEM 1204b are shown as being distinct from one another, examples are not so limited and include within their scope the use of a FEM (not shown) that includes a transmit path and/or a receive path for both WLAN and BT signals, or the use of one or more FEM circuits, wherein at least some of the FEM circuits share transmit and/or receive signal paths for both WLAN and BT signals.

The radio IC circuit 1206 as shown may include a WLAN radio IC circuit 1206a and a BT radio IC circuit 1206 b. WLAN radio IC circuitry 1206a may include a receive signal path that may include circuitry to down-convert WLAN RF signals received from FEM circuitry 1204a and provide baseband signals to WLAN baseband processing circuitry 1208 a. The BT radio IC circuitry 1206b may then include a receive signal path, which may include circuitry to down-convert the BT RF signal received from the FEM circuitry 1204b and provide a baseband signal to the BT baseband processing circuitry 1208 b. The WLAN radio IC circuitry 1206a may also include a transmit signal path that may include circuitry to up-convert WLAN baseband signals provided by the WLAN baseband processing circuitry 1208a and provide WLAN RF output signals to the FEM circuitry 1204a for subsequent wireless transmission through the one or more antennas 1201. The BT radio IC circuitry 1206b may also include a transmit signal path that may include circuitry to up-convert BT baseband signals provided by the BT baseband processing circuitry 1208b and provide BT RF output signals to the FEM circuitry 1204b for subsequent wireless transmission via the one or more antennas 1201. In the example of fig. 12, although the

radio IC circuits

1206a and 1206b are shown as being different from each other, examples are not so limited and include within their scope the use of radio IC circuits (not shown) that include transmit and/or receive signal paths for both WLAN and BT signals, or the use of one or more radio IC circuits, wherein at least some of the radio IC circuits share transmit and/or receive signal paths for both WLAN and BT signals.

The baseband processing circuits 1208 may include WLAN baseband processing circuits 1208a and BT baseband processing circuits 1208 b. The WLAN baseband processing circuitry 1208a may include a memory, such as, for example, a set of RAM arrays in a fast fourier transform or inverse fast fourier transform block (not shown) of the WLAN baseband processing circuitry 1208 a. Each of the WLAN baseband circuitry 1208a and BT baseband circuitry 1208b may further include one or more processors and control logic to process signals received from the corresponding WLAN or BT receive signal path of the radio IC circuitry 1206 and also to generate corresponding WLAN or BT baseband signals for the transmit signal path of the radio IC circuitry 1206. Each of the

baseband processing circuits

1208a and 1208b may further include physical layer (PHY) and medium access control layer (MAC) circuitry and may further interface with the application processor 104 for generating and processing baseband signals and controlling operation of the radio IC circuit 1206.

Still referring to fig. 12, in accordance with the illustrated example, the WLAN-BT coexistence circuit 1213 may include logic to provide an interface between the WLAN baseband circuit 1208a and the BT baseband circuit 1208b to implement a use case requiring WLAN and BT coexistence. In addition, a switch 1203 may be provided between the WLAN FEM circuitry 1204a and the BT FEM circuitry 1204b to allow switching between WLAN and BT radios depending on the application needs. Additionally, although antenna 1201 is depicted as being connected to WLAN FEM circuitry 1204a and BT FEM circuitry 1204b, respectively, examples include sharing one or more antennas between the WLAN and BT FEMs within their range, or providing more than one antenna connected to each of

FEMs

1204a or 1204 b.

In some examples, front-end module circuitry 1204, radio IC circuitry 1206, and baseband processing circuitry 1208 may be provided on a single radio card (such as radio card 1202). In some other examples, one or more antennas 1201, FEM circuitry 1204, and radio IC circuitry 1206 may be provided on a single radio card. In some other examples, the radio IC circuitry 1206 and the baseband processing circuitry 1208 may be provided on a single chip or Integrated Circuit (IC), such as the IC 1206.

In some examples, wireless radio card 1202 may comprise a WLAN radio card and may be configured for Wi-Fi communication, although the scope of the examples is not limited in this respect. In some of these examples, radio architecture 108 may be configured to receive and transmit Orthogonal Frequency Division Multiplexed (OFDM) or Orthogonal Frequency Division Multiple Access (OFDMA) communication signals over a multicarrier communication channel. An OFDM or OFDMA signal may include a plurality of orthogonal subcarriers.

In some of these multicarrier examples, the radio architecture 108 may be part of a Wi-Fi communication Station (STA), such as a wireless Access Point (AP), base station, or mobile device, including Wi-Fi devices. In some of these examples, radio architecture 108 may be configured to transmit and receive signals in accordance with particular communication standards and/or protocols, such as any of the Institute of Electrical and Electronics Engineers (IEEE) standards including the 802.11n-2009, IEEE802.11-2012, IEEE 802.11-2016, 802.11n-2009, 802.11ac, 802.11ah, 802.11ad, 802.11ay, and/or 802.11ax standards, and/or the proposed specifications for WLANs, although the scope of the examples is not limited in this respect. The radio architecture 108 may also be adapted to send and/or receive communications in accordance with other techniques and standards.

In some examples, the radio architecture 108 may be configured for high-efficiency Wi-Fi (HEW) communication in accordance with the IEEE802.11 ax standard. In these examples, radio architecture 108 may be configured to communicate in accordance with OFDMA techniques, although the scope of the examples is not limited in this respect.

In some other examples, radio architecture 108 may be configured to transmit and receive signals transmitted using one or more other modulation techniques, such as spread spectrum modulation (e.g., direct sequence code division multiple access (DS-CDMA) and/or frequency hopping code division multiple access (FH-CDMA)), Time Division Multiplexing (TDM) modulation, and/or Frequency Division Multiplexing (FDM) modulation, although the scope of the examples is not limited in this respect.

In some examples, as further shown in fig. 12, the BT baseband circuitry 1208b may conform to a Bluetooth (BT) connection standard, such as bluetooth, bluetooth 9.0, or bluetooth 7.0, or any other iteration of the bluetooth standard. In examples including BT functionality, such as shown in fig. 12, the radio architecture 108 may be configured to establish a BT Synchronous Connection (SCO) -oriented link and/or a BT low energy (BT LE) link. In some of the examples that include functionality, the radio architecture 108 may be configured to establish an extended SCO (eSCO) link for BT communications, although the scope of the examples is not limited in this respect. In some of these examples including BT functionality, the radio architecture may be configured to participate in BT Asynchronous Connectionless (ACL) communications, although the scope of the examples is not limited in this respect. In some examples, as shown in fig. 12, the functionality of the BT radio card and the WLAN radio card may be combined on a single radio card (such as a single radio card 1202), but examples are not so limited and include within their scope discrete WLAN and BT radio cards.

In some examples, the radio architecture 108 may include other radio cards, such as cellular radio cards configured for cellular (e.g., 5GPP, such as LTE, LTE-advanced, or 7G communications).

In some IEEE802.11 examples, radio architecture 108 may be configured for communication over various channel bandwidths, including bandwidths having center frequencies of approximately 900MHz, 2.4GHz, 5GHz, and bandwidths of approximately 2MHz, 4MHz, 85MHz, 5.5MHz, 6MHz, 8MHz, 10MHz, 40MHz, 9GHz, 46GHz, 80MHz, 100MHz, 80MHz (with continuous bandwidth), or 80+80MHz (160MHz) (with discontinuous bandwidth). In some examples, a 920MHz channel bandwidth may be used. However, the range of the example is not limited to the above center frequency.

Fig. 13 illustrates a FEM circuit 1204 according to some examples. FEM circuit 1204 is one example of a circuit that may be suitable for use as WLAN and/or BTFEM circuit I204a/1204b (fig. 12), but other circuit configurations may also be suitable.

In some examples, FEM circuitry 1204 may include TX/RX switch 1302 to switch between transmit mode and receive mode operation. FEM circuitry 1204 may include a receive signal path and a transmit signal path. The receive signal path of FEM circuitry 1204 may include a Low Noise Amplifier (LNA)1306 to amplify received RF signal 1303 and provide an amplified received RF signal 1307 as an output (e.g., to radio IC circuitry 1206 (fig. 12)). The transmit signal path of the circuit 1204 may include a Power Amplifier (PA) to amplify an input RF signal 1309 (e.g., provided by the radio IC circuit 1206); and one or more filters, such as Band Pass Filters (BPFs), Low Pass Filters (LPFs), or other types of filters, to generate RF signals 1315 for subsequent transmission (e.g., by one or more of the antennas 1201 (fig. 12)).

In some dual-mode examples for Wi-Fi communications, FEM circuitry 1204 may be configured to operate in the 2.4GHz spectrum or the 12GHz spectrum. In these examples, the receive signal path of FEM circuitry 1204 may include a receive signal path duplexer 1304 to separate signals from each frequency spectrum and, as shown, to provide a separate LNA 1306 for each frequency spectrum. In these examples, the transmit signal path of FEM circuitry 1204 may also include a power amplifier 1310 and a filter 1312 (such as a BPF, LPF, or another type of filter for each spectrum), as well as a transmit signal path duplexer 1314 to provide a signal in one of the different spectrums onto a single transmit path for subsequent transmission through one or more of the antennas 1201 (fig. 12). In some examples, BT communications may utilize a 2.4GHZ signal path and may utilize the same FEM circuitry 1204 as circuitry for WLAN communications.

Fig. 14 illustrates a radio IC circuit 1206 according to some examples. The radio IC circuit 1206 is one example of a circuit that may be suitable for use as the WLAN or BT radio IC circuits 1206a/1206b (fig. 12), but other circuit configurations may also be suitable.

In some examples, the radio IC circuitry 1206 may include a receive signal path and a transmit signal path. The receive signal path of the radio IC circuitry 1206 may include at least mixer circuitry 1402 (such as, for example, down-conversion mixer circuitry), amplifier circuitry 1406, and filter circuitry 1408. The transmit signal path of the radio IC circuit 1206 may include at least a filter circuit 1412 and a mixer circuit 1414, such as, for example, an upconversion mixer circuit. The radio IC circuit 1206 may also include a synthesizer circuit 1404 for synthesizing the frequency 1405 for use by the mixer circuit 1402 and the mixer circuit 1414. According to some examples, the mixer circuits 1402 and/or 1414 may each be configured to provide direct conversion functionality. The latter type of circuit presents a much simpler architecture compared to standard superheterodyne mixer circuits, and any flicker noise caused by it can be mitigated, for example by using OFDM modulation. Fig. 14 shows only a simplified version of the radio IC circuitry, and although not shown, may include examples in which each of the depicted circuits may include more than one component. For example, the mixer circuits 1414 can each include one or more mixers and the filter circuits 1408 and/or 1412 can each include one or more filters, such as one or more BPFs and/or LPFs as desired by the application. For example, when the mixer circuits are of the direct conversion type, they may each comprise two or more mixers.

In some examples, the mixer circuit 1402 may be configured to down-convert an RF signal 1407 received from the FEM circuitry 1204 (fig. 12) based on a synthesized frequency 1405 provided by the synthesizer circuit 1404. The amplifier circuit 1406 may be configured to amplify the downconverted signal and the filter circuit 1408 may include an LPF configured to remove unwanted signals from the downconverted signal to generate the output baseband signal 1407. The output baseband signal 1407 may be provided to baseband processing circuitry 1208 (fig. 12) for further processing. In some examples, the output baseband signal 1407 may be a zero frequency baseband signal, but this is not required. In some examples, mixer circuit 1402 may include a passive mixer, although the scope of the examples is not limited in this respect.

In some examples, the mixer circuit 1414 may be configured to upconvert an input baseband signal 1411 based on a synthesized frequency 1405 provided by the synthesizer circuit 1404 to generate an RF output signal 1409 for the FEM circuit 1404. The baseband signal 1411 may be provided by the baseband processing circuitry 1408 and may be filtered by the filter circuitry 1412. The filter circuit 1412 may include an LPF or BPF, although the scope of the examples is not limited in this respect.

In some examples, mixer circuit 1402 and mixer circuit 1414 may each include two or more mixers and may be arranged for quadrature down-conversion and/or up-conversion, respectively, with the aid of synthesizer 1404. In some examples, mixer circuit 1402 and mixer circuit 1414 may each include two or more mixers, each configured for image rejection (e.g., Hartley image rejection). In some examples, mixer circuit 1402 and mixer circuit 1414 may be arranged for direct down-conversion and/or direct up-conversion, respectively. In some examples, mixer circuit 1402 and mixer circuit 1414 may be configured for superheterodyne operation, but this is not required.

According to an example, the mixer circuit 1402 may include: quadrature passive mixers (e.g., for in-phase (I) and quadrature-phase (Q) paths). In such an example, the RF input signal 1407 of fig. 14 may be down-converted to provide I and Q baseband output signals to be transmitted to the baseband processor.

The quadrature passive mixer may be driven by zero and ninety degree time-varying LO switching signals provided by a quadrature circuit that may be configured to receive an LO frequency (fLO), such as LO frequency 1405 of synthesizer 1404 (fig. 14), from a local oscillator or synthesizer. In some examples, the LO frequency may be the carrier frequency, while in other examples, the LO frequency may be a portion of the carrier frequency (e.g., half the carrier frequency, one third of the carrier frequency). In some examples, the zero degree and ninety degree time varying switching signals may be generated by a synthesizer, although the scope of the examples is not limited in this respect.

In some examples, the duty cycle (a percentage of one period in which the LO signal is high) and/or the offset (the difference between the start of periods) of the LO signal may be different. In some examples, the LO signal may have a duty cycle of 125% and an offset of 120%. In some examples, each branch of the mixer circuit (e.g., in-phase (I) and quadrature-phase (Q) paths) may operate at a duty cycle of 120%, which may result in a significant reduction in power consumption.

The RF input signal 1407 (fig. 14) may comprise a balanced signal, although the scope of the examples is not limited in this respect. The I and Q baseband output signals may be provided to an amplifier, such as amplifier circuit 1206 (fig. 12), or to filter circuit 1208 (fig. 12).

In some examples, output baseband signal 1407 and input baseband signal 1411 may be analog baseband signals, although the scope of the examples is not limited in this respect. In some alternative examples, output baseband signal 1407 and input baseband signal 1411 may be digital baseband signals. In these alternative examples, the radio IC circuitry may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry.

In some dual-mode examples, separate radio IC circuits may be provided to process signals for each spectrum or other spectrum not mentioned herein, although the scope of the examples is not limited in this respect.

In some examples, synthesizer circuit 1404 may be a fractional-N synthesizer or a fractional-N/N +1 synthesizer, although the scope of examples is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuit 1404 may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer including a phase locked loop with a frequency divider. According to some examples, synthesizer circuit 1404 may include a digital synthesizer circuit. An advantage of using a digital synthesizer circuit is that although it may still include some analog components, its footprint may be much reduced compared to that of an analog synthesizer circuit. In some examples, the frequency input into the synthesizer circuit 1404 may be provided by a Voltage Controlled Oscillator (VCO), but this is not required. The divider control input may further be provided by baseband processing circuit 1208 (fig. 12) or application processor 104 (fig. 12), depending on the desired output frequency 1405. In some examples, the divider control input (e.g., N) may be determined from a look-up table (e.g., within a Wi-Fi card) based on a channel number and a channel center frequency determined or indicated by application processor 104. The application processor 104 may include or otherwise be coupled to the example data packet information encoder 106 of fig. 1 and/or the example data packet analyzer 110 of fig. 3.

In some examples, synthesizer circuit 1404 may be configured to generate a carrier frequency as output frequency 1405, while in other examples, output frequency 1405 may be a portion of the carrier frequency (e.g., half the carrier frequency, one third of the carrier frequency). In some examples, the output frequency 1405 may be the LO frequency (fLO).

Fig. 15 illustrates a functional block diagram of a baseband processing circuit 1208 according to some examples. The baseband processing circuit 1208 is one example of a circuit that may be suitable for use as the baseband processing circuit 1208 (fig. 12), but other circuit configurations may also be suitable. Baseband processing circuitry 1208 may include a receive baseband processor (RX BBP)1502 for processing receive baseband signals 1509 provided by radio IC circuitry 1206 (fig. 12), and a transmit baseband processor (TX BBP)1504 for generating transmit baseband signals 1511 for radio IC circuitry 1206. The baseband processing circuitry 1208 may further include control logic 1506 for coordinating the operation of the baseband processing circuitry 1208.

In some examples (e.g., when analog baseband signals are exchanged between the baseband processing circuitry 1208 and the radio IC circuitry 1206), the baseband processing circuitry 1208 may include an ADC 1510 to convert analog baseband signals 1509 received from the radio IC circuitry 1206 into digital baseband signals for processing by the RX BBP 1502. In these examples, baseband processing circuitry 1208 may also include DAC 1512 for converting the digital baseband signals from TX BBP 1504 to analog baseband signals 1511.

In some examples, such as communicating OFDM signals or OFDMA signals through baseband processor 1208a, transmit baseband processor 1504 may be configured to generate OFDM or OFDMA signals suitable for transmission by performing an Inverse Fast Fourier Transform (IFFT). The receive baseband processor 1502 may be configured to process a received OFDM signal or OFDMA signal by performing FFT. In some examples, the receive baseband processor 1502 may be configured to detect the presence of an OFDM signal or OFDMA signal by performing autocorrelation to detect a preamble (such as a short preamble) and by performing cross-correlation to detect a long preamble. The preamble may be part of a predetermined frame structure for Wi-Fi communications.

Referring back to fig. 12, in some examples, antennas 1201 (fig. 12) may each include one or more directional or omnidirectional antennas, including, for example, dipole antennas, monopole antennas, patch antennas, loop antennas, microstrip antennas or other types of antennas suitable for transmission of RF signals. In some multiple-input multiple-output (MIMO) examples, antennas may be effectively separated to take advantage of spatial diversity and the different channel characteristics that may result. Antennas 1201 may each include a set of phased array antennas, but examples are not limited thereto.

Although the radio architecture 108 is illustrated as having several separate functional elements, one or more of the functional elements may be combined and may be implemented by combinations of software-configured elements, such as processing elements including Digital Signal Processors (DSPs), and/or other hardware elements. For example, some elements may comprise one or more microprocessors, DSPs, Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), Radio Frequency Integrated Circuits (RFICs), and combinations of various hardware and logic circuitry for performing at least the functions described herein. In some examples, a functional element may refer to one or more processes operating on one or more processing elements.

Fig. 16 is a block diagram of an example processor platform 1600 capable of executing the instructions of fig. 8 and 10 to implement the example data packet information encoder 106 of fig. 1 and 2. Processor platform 1600 may be, for example, a server, a personal computer, a mobile device (e.g., a cellular phone, a smart phone, such as an iPad), a smart phone^TMTablet computer), Personal Digital Assistant (PDA), internet appliance, or any other type of computing device.

The processor platform 1600 of the illustrated example includes a processor 1612. The processor 1612 of the illustrated example is hardware. For example, the processor 1612 may be implemented by an integrated circuit, logic circuit, microprocessor, or controller from any desired family or manufacturer.

The processor 1612 of the illustrated example includes local memory 1613 (e.g., a cache). The example processor 1612 of fig. 16 executes the instructions of fig. 8-11 to implement the example component interface 200, the example data packet information determiner 202, the example data packet length encoder 203, the example control information field encoder 204, the example data packet format encoder 207, the example unique pattern encoder 206, the example field modulator 208, the example field inverter 210 and/or the example length field value encoder 212 of fig. 2, the example component interface 300, the example field analyzer 302, the example pattern identifier 304, the example constellation determiner 306, and/or the example modulo executor 308 of fig. 3, and/or the example application processor 104 of fig. 1 and/or 12. The processor 1612 of the illustrated example is in communication with a main memory (including volatile memory 1614 and non-volatile memory 1616) via a bus 1618. The volatile memory 1614 may be implemented by: synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM), and/or any other type of random access memory device. The non-volatile memory 1616 may be implemented by flash memory and/or any other desired type of storage device. Access to the

main memory

1614, 1616 is controlled by a clock controller.

The processor platform 1600 of the illustrated example also includes interface circuitry 1620. The interface circuit 1620 may be implemented by any type of interface standard, such as an ethernet interface, a Universal Serial Bus (USB), and/or a PCI express interface.

In the illustrated example, one or more input devices 1622 are connected to the interface circuit 1620. Input device(s) 1622 allow a user to enter data and commands into the processor 1612. The input device(s) may be implemented by, for example, sensors, microphones, cameras (still or video), keyboards, buttons, mice, touch screens, track pads, track balls, an iso-mouse, and/or voice recognition systems.

One or more output devices 1624 are also connected to the interface circuit 1620 of the illustrated example. The output device 1624 may be implemented, for example, by a display device (e.g., a Light Emitting Diode (LED), an Organic Light Emitting Diode (OLED), a liquid crystal display, a cathode ray tube display (CRT), a touchscreen, a tactile output device, and/or speakers). Thus, the interface circuit 1620 of the illustrated example generally comprises a graphics driver card, a graphics driver chip, or a graphics driver processor.

The interface circuit 1620 of the illustrated example also includes communication devices such as transmitters, receivers, transceivers, modems, and/or network interface cards to facilitate the exchange of data with external machines (e.g., any kind of computing device) via a network 1626 (e.g., an ethernet connection, a Digital Subscriber Line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.).

Processor platform 1600 of the illustrated example also includes one or more mass storage devices 1628 for storing software and/or data. Examples of such mass storage devices 1628 include floppy disk drives, hard disk drives, optical disk drives, blu-ray disk drives, RAID systems, and Digital Versatile Disk (DVD) drives.

The encoded instructions 1632 of fig. 8-11 may be stored in mass storage device 1628, in volatile memory 1614, in non-volatile memory 1616, and/or on a removable tangible computer-readable storage medium, such as a CD or DVD.

In light of the foregoing, it will be appreciated that the above disclosed methods, apparatus and articles of manufacture are indicative of data packet attributes in wireless communications. In some examples disclosed herein, a transmitting device may encode the data packet length by generating a new control information subfield in a control information field (e.g., HE-SIGA) of the data packet. In some examples disclosed herein, a transmitting device may provide a unique time and/or frequency domain pattern to the end of a data packet to identify the end of the packet (e.g., such that a data packet length is not required). In some examples, the transmitting device may encode the data packet format by: (A) modulating a constellation of control information subfields in a pattern corresponding to a data packet format, (B) negating a repeated set of long training field subcarrier values at different subcarrier frequencies of the data packet to correspond to the data packet format, (C) dedicating one or more bits of the control information field to correspond to the data packet format, and/or (D) setting the length field value to correspond to the data packet format based on a modulo calculation technique. Using examples disclosed herein, a legacy preamble may be removed to reduce overhead and improve efficiency while still providing data packet length and/or format.

Example 1 is an apparatus for indicating a data packet length in wireless communications. Example 1 includes a data packet information determiner to determine a length of a data packet to be transmitted to a receiving device. Example 1 further includes a data packet length encoder to encode a length of the data packet using at least one of the sub-fields of the control information field of the data packet.

Example 2 includes the subject matter of example 1, wherein the data packet length encoder is to encode the data packet length using a subfield of the control information field by encoding the data packet length into a front control information subfield or a rear control information subfield of the control information field.

Example 3 includes the subject matter of example 2, wherein at least one of the front control information subfield or the back control information subfield shares tail bits with adjacent control information subfields.

Example 4 includes the subject matter of example 1, wherein the control information field corresponds to a HE-SIGA field.

Example 5 is an apparatus for indicating a data packet length in wireless communications. Example 5 includes a component interface to receive an instruction to generate a data packet. Example 5 further includes a data packet length encoder to encode the data packet end pattern at an end of the data packet.

Example 6 includes the subject matter of example 5, wherein the data packet length encoder encodes the data packet end pattern into a field of the data packet.

Example 7 includes the subject matter of example 6, wherein the field is located at an end of the data packet.

Example 8 includes the subject matter of example 5, wherein the data packet length encoder encodes the data packet end pattern as a unique time domain pattern.

Example 9 includes the subject matter of example 8, wherein the unique time domain pattern is different from other possible time domain patterns of the data packet.

Example 10 includes the subject matter of example 5, wherein the data packet length encoder encodes the data packet end pattern as a unique frequency domain pattern.

Example 11 includes the subject matter of example 10, wherein the unique frequency domain pattern is different from other possible frequency domain patterns of the data packet.

Example 12 is an apparatus for indicating a data packet format in wireless communications. Example 12 includes a data packet information determiner to determine a format of a data packet to be transmitted to the receiving device. Example 12 further includes a data packet format encoder to encode a format of the data packet using at least one of: (A) a duplicate field of a data packet, or (B) a control information field of a data packet.

Example 13 includes the subject matter of example 12, wherein the data packet format encoder is to encode the data packet format using the control information field by modulating a constellation of a second subfield of the control information field, the constellation corresponding to the data packet format.

Example 14 includes the subject matter of example 13, wherein the data packet format encoder is to modulate the constellation using Binary Phase Shift Keying (BPSK) or quadrature phase shift keying (QBPSK), the QBPSK corresponding to a ninety degree rotation of BPSK.

Example 15 includes the subject matter of example 12, wherein the data packet format encoder is to encode the data packet format using the control information field by storing a value in one or more bits of the control information field, the value corresponding to the data packet format.

Example 16 includes the subject matter of example 12, wherein the data packet format encoder is to set a value of a subfield of the control information field to correspond to the data packet format based on a modulo technique.

Example 17 includes the subject matter of example 12, wherein the data packet format encoder is to encode a format of the data packet by negating the first set of subcarrier frequency values of the duplicate field to correspond to the first data packet format.

Example 18 includes the subject matter of example 17, wherein the first set of subcarrier frequency values corresponds to all subcarrier frequencies of the data packet.

Example 19 includes the subject matter of example 17, wherein the data packet format encoder is to encode the format of the data packet to correspond to a second data packet by not negating a second set of subcarrier frequency values of the repetition field, the second set different from the first set.

Example 20 includes the subject matter of example 12, wherein the data packet format encoder is to encode the data packet format to correspond to the third data packet format by not negating a set of subcarrier frequency values of the repetition field.

Example 21 includes the subject matter of example 12, wherein the repetition field corresponds to a repetition long training (R-LTF) field.

Example 22 is a tangible computer storage readable medium comprising instructions that, when executed, cause a machine to at least determine a length of a data packet to be transmitted to a receiving device; and encoding the length of the data packet using at least one of the sub-fields of the control information field of the data packet.

Example 23 includes the subject matter of example 22, wherein the instructions cause the machine to encode the data packet length using a subfield of the control information field, including encoding the data packet length into a front control information subfield or a rear control information subfield of the control information field.

Example 24 includes the subject matter of example 23, wherein at least one of the front control information subfield or the back control information subfield shares tail bits with adjacent control information subfields.

Example 25 includes the subject matter of example 22, wherein the control information field corresponds to a HE-SIGA field.

Example 26 is a tangible computer storage readable medium comprising instructions that, when executed, cause a machine to at least receive instructions to generate a data packet; and encodes the data packet end pattern at the end of the data packet.

Example 27 includes the subject matter of example 26, wherein the instructions cause the machine to encode an end of data packet pattern into a field of the data packet.

Example 28 includes the subject matter of example 27, wherein the field is located at an end of the data packet.

Example 29 includes the subject matter of example 26, wherein the instructions cause the machine to encode the end of data packet pattern as a unique time domain pattern.

Example 30 includes the subject matter of example 29, wherein the unique time domain pattern is different from other possible time domain patterns of the data packet.

Example 31 includes the subject matter of example 26, wherein the instructions cause the machine to encode the end of data packet pattern as a unique frequency domain pattern.

Example 32 includes the subject matter of example 31, wherein the unique frequency domain pattern is different from other possible frequency domain patterns of the data packet.

Example 33 is a tangible computer storage readable medium comprising instructions that, when executed, cause a machine to at least determine a format of a data packet to be transmitted to a receiving device; and encoding the format of the data packet using at least one of: (A) a duplicate field of a data packet, or (B) a control information field of a data packet.

Example 34 includes the subject matter of example 33, wherein the instructions cause the machine to format the data packet by modulating a constellation of a second subfield of the control information field, the constellation corresponding to the data packet format, using the control information field.

Example 35 includes the subject matter of example 34, wherein the instructions cause the machine to modulate the constellation using Binary Phase Shift Keying (BPSK) or quadrature phase shift keying (QBPSK), the QBPSK corresponding to a ninety degree rotation of BPSK.

Example 36 includes the subject matter of example 33, wherein the instructions cause the machine to encode the data packet format using the control information field by storing a value in one or more bits of the control information field, the value corresponding to the data packet format.

Example 37 includes the subject matter of example 33, wherein the instructions are to cause the machine to set a value of a subfield of the control information field to correspond to a data packet format based on a modulo technique.

Example 38 includes the subject matter of example 33, wherein the instructions cause the format of the machine-encoded data packet to correspond to the first data packet format by negating a first set of subcarrier frequency values of the repetition field.

Example 39 includes the subject matter of example 38, wherein the first set of subcarrier frequency values correspond to all subcarrier frequencies of the data packet.

Example 40 includes the subject matter of example 38, wherein the instructions cause the format of the machine-encoded data packet to correspond to a second data packet by not negating a second set of subcarrier frequency values of the repetition field, the second set different from the first set.

Example 41 includes the subject matter of example 33, wherein the instructions cause the machine-encoded data packet format to correspond to the third data packet format by not negating a set of subcarrier frequency values of the repetition field.

Example 42 includes the subject matter of example 33, wherein the repetition field corresponds to a repetition long training (R-LTF) field.

Example 43 is a method for indicating a data packet length in wireless communications. Example 43 includes determining a length of a data packet to be transmitted to a receiving device; and encoding the length of the data packet using at least one of the sub-fields of the control information field of the data packet.

Example 44 includes the subject matter of example 43, wherein encoding the data packet length using the subfield of the control information field comprises encoding the data packet length into a front control information subfield or a rear control information subfield of the control information field.

Example 45 includes the subject matter of example 44, wherein at least one of the front control information subfield or the back control information subfield shares tail bits with an adjacent control information subfield.

Example 46 includes the subject matter of example 43, wherein the control information field corresponds to a HE-SIGA field.

Example 47 is a method for indicating a data packet length in wireless communications. Example 47 includes receiving an instruction to generate a data packet; and an end of data packet encoding mode at the end of the data packet.

Example 48 includes the subject matter of example 47, further comprising encoding an end of data packet pattern into a field of the data packet.

Example 49 includes the subject matter of example 48, wherein the field is located at an end of the data packet.

Example 50 includes the subject matter of example 47, further comprising encoding the end of data packet pattern as a unique time domain pattern.

Example 51 includes the subject matter of example 50, wherein the unique time domain pattern is different from other possible time domain patterns of the data packet.

Example 52 includes the subject matter of example 47, further comprising encoding the end of data packet pattern as a unique frequency domain pattern.

Example 53 includes the subject matter of example 52, wherein the unique frequency domain pattern is different from other possible frequency domain patterns of the data packet.

Example 54 is a method for indicating a data packet length in wireless communications. Example 54 includes determining a format of a data packet to be transmitted to a receiving device; and encoding the format of the data packet using at least one of: (A) a duplicate field of a data packet, or (B) a control information field of a data packet.

Example 55 includes the subject matter of example 54, further comprising encoding the data packet format using the control information field by modulating a constellation of a second subfield of the control information field, the constellation corresponding to the data packet format.

Example 56 includes the subject matter of example 55, further comprising modulating the constellation using Binary Phase Shift Keying (BPSK) or quadrature phase shift keying (QBPSK), the QBPSK corresponding to a ninety degree rotation of BPSK.

Example 57 includes the subject matter of example 54, further comprising encoding the data packet format using the control information field by storing a value in one or more bits of the control information field, the value corresponding to the data packet format.

Example 58 includes the subject matter of example 54, further comprising setting a value of a subfield of the control information field to correspond to a data packet format based on a modulo technique.

Example 59 includes the subject matter of example 54, further comprising encoding a format of the data packet by negating the first set of subcarrier frequency values of the repetition field to correspond to the first data packet format.

Example 60 includes the subject matter of example 59, wherein the first set of subcarrier frequency values correspond to all subcarrier frequencies of the data packet.

Example 61 includes the subject matter of example 59, further comprising encoding a format of the data packet to correspond to a second data packet by not negating a second set of subcarrier frequency values of the repetition field, the second set different from the first set.

Example 62 includes the subject matter of example 54, further comprising encoding the data packet format to correspond to a third data packet format by not negating a set of subcarrier frequency values of the repetition field.

Example 63 includes the subject matter of example 54, wherein the repetition field corresponds to a repetition long training (R-LTF) field.

Example 64 is an apparatus for indicating a data packet length in wireless communications. Example 64 includes first means for determining a length of a data packet to be transmitted to a receiving device; and second means for encoding the length of the data packet using at least one of the sub-fields of the control information field of the data packet.

Example 65 includes the subject matter of example 64, wherein the second means comprises means for encoding the data packet length using a subfield of the control information field by encoding the data packet length into a front control information subfield or a rear control information subfield of the control information field.

Example 66 includes the subject matter of example 65, wherein at least one of the front control information subfield or the back control information subfield shares tail bits with an adjacent control information subfield.

Example 67 includes the subject matter of example 64, wherein the control information field corresponds to a HE-SIGA field.

Example 68 is an apparatus for indicating a data packet length in wireless communications. Example 68 includes first means for receiving an instruction to generate a data packet; and second means for encoding an end of data packet pattern at the end of the data packet.

Example 69 includes the subject matter of example 68, wherein the second means comprises means for encoding an end of data packet pattern into a field of the data packet.

Example 70 includes the subject matter of example 69, wherein the field is located at an end of the data packet.

Example 71 includes the subject matter of example 68, wherein the second means comprises means for encoding the end of data packet pattern as a unique time domain pattern.

Example 72 includes the subject matter of example 71, wherein the unique time domain pattern is different from other possible time domain patterns of the data packet.

Example 73 includes the subject matter of example 69, wherein the second means comprises means for encoding the end of data packet pattern into a unique frequency domain pattern.

Example 74 includes the subject matter of example 73, wherein the unique frequency domain pattern is different from other possible frequency domain patterns of the data packet.

Example 75 is an apparatus for indicating a data packet format in wireless communications. Example 75 includes first means for determining a format of a data packet to be transmitted to a receiving device; and second means for encoding a format of the data packet using at least one of: (A) a duplicate field of a data packet, or (B) a control information field of a data packet.

Example 76 includes the subject matter of example 75, wherein the second means is for encoding the data packet format using the control information field by modulating a constellation of a second subfield of the control information field, the constellation corresponding to the data packet format.

Example 77 includes the subject matter of example 76, wherein the second means comprises means for modulating the constellation using Binary Phase Shift Keying (BPSK) or quadrature phase shift keying (QBPSK), the QBPSK corresponding to a ninety degree rotation of BPSK.

Example 78 includes the subject matter of example 75, wherein the second means includes means for encoding the data packet format using the control information field by storing a value in one or more bits of the control information field, the value corresponding to the data packet format.

Example 79 includes the subject matter of example 75, wherein the second means comprises means for setting a value of a subfield of the control information field to correspond to a data packet format based on a modulo technique.

Example 80 includes the subject matter of example 75, wherein the second means comprises means for encoding the format of the data packet by negating the first set of subcarrier frequency values of the duplicate field to correspond to the first data packet format.

Example 81 includes the subject matter of example 80, wherein the first set of subcarrier frequency values correspond to all subcarrier frequencies of the data packet.

Example 82 includes the subject matter of example 80, wherein the second means comprises means for encoding a format of the data packet to correspond to a second data packet by not negating a second set of subcarrier frequency values of the repetition field, the second set different from the first set.

Example 83 includes the subject matter of example 75, wherein the second means comprises means for encoding the data packet format to correspond to the third data packet format by not negating a set of subcarrier frequency values of the repetition field.

Example 84 includes the subject matter of example 75, wherein the repetition field corresponds to a repetition long training (R-LTF) field.

Although certain example methods, apparatus, and articles of manufacture have been described herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus, and articles of manufacture fairly falling within the scope of the appended claims either literally or under the doctrine of equivalents.

Claims

1. An apparatus for indicating a data packet format in wireless communications, the apparatus comprising:

a data packet information determiner for determining a format of a data packet to be transmitted to a receiving device; and

a data packet format encoder for encoding a format of the data packet using at least one of: (A) a repetition field of the data packet, or (B) a control information field of the data packet.

2. The apparatus of claim 1, wherein the data packet format encoder is to encode the data packet format using the control information field by modulating a constellation of a second subfield of the control information field, the constellation corresponding to the data packet format.

3. The apparatus of claim 2, wherein the data packet format encoder is to modulate the constellation using Binary Phase Shift Keying (BPSK) or quadrature phase shift keying (QBPSK), QBPSK corresponding to a ninety degree rotation of BPSK.

4. The apparatus of claim 1, wherein the data packet format encoder is to encode the data packet format using the control information field by storing a value in one or more bits of the control information field, the value corresponding to the data packet format.

5. The apparatus of claim 1, wherein the data packet format encoder is to set a value of a subfield of the control information field to correspond to a data packet format based on a modulo technique.

6. The apparatus of claim 1, wherein the data packet format encoder is to encode a format of the data packet to correspond to a first data packet format by negating a first set of subcarrier frequency values of the repetition field.

7. The apparatus of claim 6, wherein the first set of subcarrier frequency values corresponds to all subcarrier frequencies of the data packet.

8. The apparatus of claim 6, wherein the data packet format encoder is to encode a format of the data packet to correspond to a second data packet by not negating a second set of subcarrier frequency values of the repetition field, the second set different from the first set.

9. The apparatus of claim 1, wherein the data packet format encoder is to encode the data packet format to correspond to a third data packet format by not negating a set of subcarrier frequency values of the repetition field.

10. The apparatus of claim 1, wherein the repetition field corresponds to a repetition long training (R-LTF) field.

11. A tangible computer storage readable medium comprising instructions that, when executed, cause a machine to at least:

determining a format of a data packet to be transmitted to a receiving device; and is

Encoding a format of the data packet using at least one of: (A) a repetition field of the data packet, or (B) a control information field of the data packet.

12. The computer storage readable medium of claim 11, wherein the instructions cause the machine to encode the data packet format using the control information field by modulating a constellation of a second subfield of the control information field, the constellation corresponding to the data packet format.

13. The computer storage readable medium of claim 12, wherein the instructions cause the machine to modulate the constellation using Binary Phase Shift Keying (BPSK) or quadrature phase shift keying (QBPSK), QBPSK corresponding to a ninety degree rotation of BPSK.

14. The computer storage readable medium of claim 11, wherein the instructions cause the machine to encode the data packet format using the control information field by storing a value in one or more bits of the control information field, the value corresponding to the data packet format.

15. The computer storage readable medium of claim 11, wherein the instructions cause the machine to set a value of a subfield of the control information field to correspond to a data packet format based on a modulo technique.

16. The computer storage readable medium of claim 11, wherein the instructions cause the machine to encode the format of the data packet to correspond to a first data packet format by negating a first set of subcarrier frequency values of the repetition field.

17. The computer storage readable medium of claim 16, wherein the first set of subcarrier frequency values correspond to all subcarrier frequencies of the data packet.

18. The computer storage readable medium of claim 16, wherein the instructions cause the machine to encode the format of the data packet to correspond to a second data packet by not negating a second set of subcarrier frequency values of the repetition field, the second set different from the first set.

19. The computer storage readable medium of claim 11, wherein the instructions cause the machine to encode the data packet format to correspond to a third data packet format by not negating a set of subcarrier frequency values of the repetition field.

20. The computer storage readable medium of claim 11, wherein the repetition field corresponds to a repetition long training (R-LTF) field.

21. A method for indicating a data packet length in wireless communications, the method comprising:

determining a format of a data packet to be transmitted to a receiving device; and

22. The method of claim 21, further comprising encoding the data packet format using the control information field by modulating a constellation of a second subfield of the control information field, the constellation corresponding to the data packet format.

23. The method of claim 22, further comprising modulating the constellation using Binary Phase Shift Keying (BPSK) or quadrature phase shift keying (QBPSK), QBPSK corresponding to a ninety degree rotation of BPSK.

24. The method of claim 21, further comprising encoding the data packet format using the control information field by storing a value in one or more bits of the control information field, the value corresponding to the data packet format.

25. The method of claim 21, further comprising setting a value of a subfield of the control information field to correspond to a data packet format based on a modulo technique.