WO2019125416A1

WO2019125416A1 - Methods and apparatus for indicating data packet attributes in wireless communication

Info

Publication number: WO2019125416A1
Application number: PCT/US2017/067384
Authority: WO
Inventors: Xiaogang Chen; Feng Jiang; Qinghua Li; Robert Stacey
Original assignee: Intel IP Corporation
Priority date: 2017-12-19
Filing date: 2017-12-19
Publication date: 2019-06-27
Also published as: CN111183617B; CN111183617A

Abstract

Methods and apparatus to indicate data packet attributes in wireless communication 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 to encode the length of the data packet using at least one of a subfield of a control information field of the data packet.

Description

METHODS AND APPARATUS FOR INDICATING DATA PACKET ATTRIBUTES IN

\\ 1R1 J.ES S COMMUNICATION

FIELD OF THE DISCLOSURE

This disclosure relates generally to wireless fidelity connectivity (Wi-Fi) and, more particularly, to methods and apparatus for indicating data packet attributes in wireless communication.

BACKGROUND

Many locations provide Wi-Fi to connect Wi-Fi enabled devices to networks such as the Internet. Wi-Fi enabled devices include personal computers, video-game consoles, mobile phones and devices, digital cameras, tablets, smart televisions, digital audio players, etc. Wi-Fi allows the Wi-Fi enabled devices to wirelessly access the Internet via a wireless local area network (WLAN). To provide Wi-Fi connectivity to a device, a Wi-Fi access point exchanges radio frequency Wi-Fi signals with the Wi-Fi enabled device within the access point (e.g., a hotspot) signal range. Wi-Fi is implemented using a set of media access control (MAC) and physical layer (PHY) specifications (e.g., such as the Institute of Electrical and Electronics Engineers (IEEE) 802 1 1 protocol).

BRIEF DESCRIPTION OF THE DRAWINGS

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

FIG. 2 is a block diagram of an example data packet information encoder of FIG. 1.

FIG. 3 is a block di agram of an 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 example constellation patterns that may be generated by a transmitting device of FIG 1.

FIG. 7 illustrates an example repeated long training field pattern that may be generated by a transmitting device. FIG. 8 is a flowchart representative of example machine readable instructions that may be executed to implement the example data packet information encoder of FIGS. 1 and/or 2.

FIG. 9 is a flowchart representative of example machine readable instructions that may be executed to implement the example data packet analyzer of FIGS. 1 and/or 3.

FIG. 10 is a flowchart representative of example machine readable instructions that may be executed to implement the example data packet information encoder of FIGS. 1 and/or 2.

FIG. 1 1 is a flowchart representative of example machine readable instructions that may be executed to implement the example data packet analyzer of FIGS. 1 and/or 3.

FIG. 12 is a block diagram of a radio architecture in accordance with some examples.

FIG. 13 illustrates example front-end module circuitry for use in the radio architecture of FIG. 12 in accordance with some examples.

FIG. 14 illustrates example radio IC circuitry for use in the radio architecture of FIG. 12 in accordance with some examples.

FIG. 15 illustrates example baseband processing circuitry for use in the radio architecture of FIG. 12 in accordance with some examples.

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

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

DETAILED DESCRIPTION

Various locations (e.g., homes, offices, coffee shops, restaurants, parks, airports, etc.) may provide Wi-Fi to the Wi-Fi enabled devices (e.g., stations (STA)) to connect the Wi-Fi enabled devices to the Internet, or any other network, with minimal hassle. The locations may provide one or more Wi-Fi access points (APs) to output Wi-Fi signals to the Wi-Fi enabled devices within a range of the Wi-Fi signals (e.g., a hotspot) A Wi-Fi AP is structured to wirelessly connect a Wi-Fi enabled device to the Internet through a wireless local area network (WLAN) using Wi-Fi protocols (e.g , such as IEEE 802.11). The Wi-Fi protocol is the protocol for how the AP communicates with the devices to provide access to the Internet by transmitting uplink (UL) transmissions and receiving downlink (DL) transmissions to/from the Internet. As unlicensed frequency bands (e g.. 2.4 Gigahertz (GHz) and/or 5 GHz) become congested, new unlicensed bands (e.g., 3.5 GHz or 6 GHz) may become open for civil usage. Many legacy Wi-Fi devices may not work in such new unlicensed bands. Accordingly, as such new unlicensed bands become available, there is an industry wide motivation to remove and/or adjust legacy preambles of data packets to reduce overhead, without effecting coexistence.

Additionally, removing a legacy preamble (e.g., corresponding to 20 microseconds (us)) will improve efficiency. In conventional data packets (e.g., legacy data packets), the length subfield in the L-SIG field of a data packet indicates the data packet (e.g., physical layer convergence protocol -protocol data unit (PPDU)) length and a data packet format (e.g., single user (SU) PPDU, multi-user (MU) PPDU, extended range (ER) PPDU, and trigger based (TB) PPDU).

If the legacy preamble, which included length and format information, were removed in a new unlicensed band the data packet length and the data packet format need to be encoded into another part of the data packet. Examples disclosed herein provide various techniques for providing data packet length, an end of data packet identifier, and/or data packet format into a data packet for use in a new frequency band. Examples disclosed herein reduce the number of bits used in legacy data packet transmissions by generating a new data packet that encodes data packet format and data packet length in already dedicated fields, allowing the data packet to keep data packet format and length without the number of bits used in legacy data packets, thereby- decreasing the overhead of data transmission and increasing the efficiency of the data transmission.

In some examples disclosed herein, a. transmitting device (e.g , an AP transmitting DL data packets or a STA transmitting UL data packets) 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 the data packet attributes that would be eliminated when the legacy preamble is eliminated into already dedicated fields of a data packet. In this manner, data packet attributes can 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., so that the data packet length is not needed). In some examples, a transmitting device may encode a data packet format by (A) modulating the constellations of the control information subfields in a pattern that corresponds to a data packet format, (B) negating a group of the repeated long training field values at different subcarrier frequencies of a data packet to correspond to a data packet format, (C) dedicating one or more bits of a control information field to correspond to a data packet format, and/or (D) setting the length field value to correspond to a data packet format based on a modulo calculation technique. Using examples disclosed herein, the legacy preambles may be removed to reduce overhead and increase efficiency while still providing data packet length and/or format.

FIG. 1 illustrates communications using wireless local area network Wi-Fi protocols to indicate data packet length and/or data packet format. The example of FIG. 1 includes an example AP 100, an example STA 102, 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 1 12. Although the illustrated example of FIG 1 includes one STA 102, the example AP 100 may communicate with any number of STAs. As described herein, the example AP 100 and/or the example STA 102 may he a transmitting device and/or a receiving device based on the current operation of the devices. For example, the example AP 100 is a transmitting device and the example STA 102 is a receiving device when the AP 100 transmits DL packets to the STA 102. In another example, the example AP 100 is a receiving device and the example STA 102 is a transmitting device when the STA 102 transmits UL packets to the AP 100.

The example AP 100 of FIG. 1 is a device that allows the example STA 102 to wirelessly access the example network 112. The example AP 100 may be a router, a modem-router, and/or any other device that provides a wireless connection to the network 112. A router provides a wireless communication link to a STA. The router accesses the network 1 12 through a wire connection via a modem. A modem-router combines the functionalities of the modem and the router. In some examples, the AP 100 is a STA that is communication in the example STA 102. The example AP 100 includes the example data packet information encoder 106 to generate data packets to be transmitted to the example STA 102 and/or the example data packet analyzer 1 10 to process the data packets transmitted by the example STA 102, as further described below.

The example STA 102 of FIG. 1 is a Wi-Fi enabled computing device. The example STA 102 may be, for example, a computing device, a portable device, a mobile device, a mobile telephone, a smart phone, a tablet, a gaming system, a digital camera, a digital video recorder, a television, a set top box, an e-book reader, and/or any other Wi-Fi enabled device. The example STA 102 includes the example data packet information encoder 106 to generate data packets to be transmitted to the example AP 100 and/or the example data packet analyzer 1 10 to process the data packets transmitted by the example AP 100, as further described 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. Additionally, the application processor 104 receives data that has been received a transmitting device.

The example data packet information encoder 106 of FIG. 1 generates a data packet when the example application processor 104 of FIG. 1 sends the data packet information encoder 106 instructions to transmit a data packet (e.g., a PPDU). As described above, there may be reasons to remove legacy preambles used in the 2.4 GHz and/or 5 GHz frequency bands for other frequency bands (e.g , band(s) around 3 5 GHz or 6 GHz) For example, removing the legacy preamble (A) facilitates coexistence between legacy and nonlegacy devices in a new frequency band, (B) reduces overhead, and (C) simpli fies a redesign of the preamble of a data packet.

Accordingly, the example data packet information encoder 106 generates data packets that do not include the legacy preambles, thereby providing data transmission that are more efficient than legacy transmissions. A 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. Accordingly, the example data packet information encoder 106 may generate a data packet to include data packet length and/or 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 to be wirelessly transmitted. The 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 the control information field (e.g., HE-SIGA) of a data packet. In another example, the data packet information encoder 106 may encode a unique time domain and/or frequency domain pattern at the end of the data field of the data packet. In this manner, a receiving device may determine when the data packet is complete (e.g., when data transmission has ended) 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 a control information subfield of the data packet, (B) negating of a group of subcarrier frequency values in a repeated long training field (R-LTF), (C) storing a value in one or more bits of the control information field (e.g , HE-SIGA), and/or (B) storing a value in the length field of the data packet corresponding to a modulo calculation. The example data packet information encoder 106 may generate a data packet based on user and/or manufacturer configurations and/or based on a standard (e.g., an IEEE standard). The 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 received packets to identify data packet length, an end of a data packet transmission, and/or data packet format based on how the example transmitting device encoded the data packet. For example, the transmitting device may encode a data packet with the data packet length/end of data packet transmission and/or data packet format based on standard, condition, and/or preference. In some examples, the transmitting device may communicate how the data packet is encoded based on configurations that are communicated to the example receiving device during initiation of communication . Accordingly, the example data packet analyzer 110 may process a received data packet based on the encoding configurations.

For example, the data packet analyzer 1 10 of FIG. 1 may process a pre- or post-control information subfield of the control information field to determine the data packet length. In another example, the data packet analyzer 1 10 may determine when a received data packet has ended by identifying a predefined unique time domain and/or frequency domain pattern. In some examples, the data packet analyzer 110 transmits an ACK when the data transmission ceases.

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

The example network 1 12 of FIG. 1 is a system of interconnected systems exchanging 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 via the network 112, the example Wi-Fi AP 100 includes a communication interface that enables a connection to an Ethernet, a digital subscriber line (DSL), a telephone line, a coaxial cable, or any wireless connection, etc.

FIG. 2 is a block diagram of an example implementation of the data packet information encoder 106 of FIG. 1, disclosed herein, 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 pattern encoder 206. The example data packet format encoder 207 includes an example field modulator 208, an example field negator 210, and an example length field value encoder 212.

The example component interface 200 of FIG. 2 interfaces with components of the transmitting device (e ., the example AP 100 or the example STA 102 of FIG. 1) to transmit signals (e.g., data packets) and/or receive signals (e.g., instructions to generate a data packet).

For example, the component interface 200 may instruct the example radio architecture 108 of FIGS. 1 and/or 12 to transmit DL data and/or receive instructions from the example application processor 104.

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

The example data packet length encoder 203 encodes data packet length information into the data packet without using extra bytes/bits corresponding to legacy data packet preambles. In some examples, the data packet length encoder 203 may encode the data packet length as part of an already utilized field (e.g., the control information field or HE-SIGA). In some examples, the data packet length encoder 203 encodes an 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 the example control information field encoder 204 and the example unique pattern encoder 206 to encode the data packet length/end-of-packet pattern.

The example control information field encoder 204 of FIG. 2 encodes the control information field to include a pre- or post- control information subfield of the control

information field of the data packet. For example, the control information field encoder 204 adjusts the legacy control information field (e.g., the HE-SIGA field) to include a subfield that corresponds to the length of the data packet. The control information field encoder 204 can 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). Additionally, the example control information field encoder 204 may encode the control information subfield (e.g., pre- or post-) as self-decodable or non-self decodable. A self- decodable control information subfield includes its own tail bits to be encoded independently from the other HE-SIGA fields. In this manner, a receiving device using 802.1 lax hardware can still decode the HE-SIGA field without require hardware updates at the expense of extra bits for the HE-SIGA field. A non-self decodable control information subfield does not include its own tail bits. Rather, a non-self decodable control information subfield includes shared tail bits with a neighboring HE-SIGA field, thereby reducing the number of bits needed for the HE-SIGA field. The type of pre-/post- 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 and/or frequency domain pattern at the end of a data packet. In this manner, a receiving device can determine when the data packet has ended by sensing the unique pattern without using the hits of overhead required to encode the length field in the PHY preamble (e.g , the example HE- S1GA field). The unique pattern may be transmitted to the receiving device during initial communications between the example AP 100 and the example STA 102 A unique time domain pattern corresponds to a repeatable signal that repeats for three periods, for example. The unique time domain may be preset to be different from time domain patterns of any of the other fields, thereby reducing the probability of a false trigger. A unique frequency domain pattern corresponds to a frequency domain phase shift of a constellation (e.g., a shift phase of the constellations between two adjacent subcarriers). The unique frequency domain may be preset to be different from frequency domain patterns of any of the other fields, thereby reducing the probability of a false trigger. In some examples, the example unique pattern encoder 206 may encode a time and frequency domain pattern 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 the data packet without using extra bytes/bits corresponding to legacy data packet preambles. In some examples, the data packet format encoder 207 may encode the data packet format as part of an already utilized field (e.g., the control information field/HE-SIGA, the repeated LFT field, etc.), as further described below. The example data packet format encoder 207 includes the example field modulator 208, the example field negator 210, and the 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 the constellation of control signal subfields (e.g., HE-SIGA1, HE-SIGA2, PRE-/POST-HE SIGA) of the control information field (e.g., HE-SIGA) to generate a constellation pattern indicative of a data packet format. For example, the field modulator 208 can modulate each subfield with quadrature phase shirt keying (QBPSK or“Q”) or with binary phase shift keying (BPSK or“B”), where Q corresponds to the modulation of B rotated 90 degrees. In this manner, the pattern corresponding to the modulation of“Q” and/or“B” can correspond to a data packet format. For example, the field modulator 2088 may modulate three control signal subfields to result in 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”,“Q” can correspond to MU PPDU,“B”,“B”,“B”, may can correspond to ER PPDU,“Q”,“B”,“Q” can correspond to SU PPDU, and“B”,“Q”,“B” may correspond to TB PPDU, etc. Alternatively, any pattern may correspond to any format. The pattern-format correlation may be predefined in a standard and/or may be communicated to the receiving device during initial communications between the example AP 100 and the example STA 102.

The example field negator 210 of FIG. 2 leverages the greenfield long training field (GF- LTF) and the repeated GF-LTF (R-GF-LTF) to indicate different data packet formats. Although 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 fi eld used to minimize decoding errors, increasing the robustness of the transmission. The example field negator 210 leverages the repeated nature of the R-GF-LTF field by negating a group of the values at different subcarrier frequencies of the R-GR-LTF to correspond to different data packet formats. For example, the field negator 210 may (A) encode the subcarrier frequencies 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 frequencies 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 frequencies of the R-GF LTF to be the same as the corresponding frequenci es of the GF-LTF and a second half of the subcarrier frequencies of the R-GF-LTF to be the opposite of the correspondi ng frequencies of the GF-LTF to correspond to a third data packet format, (D), encode the second half of the subcarrier frequencies of the R-GF LTF to be the same as the corresponding frequencies of the GF-LTF and the first half of the subcarrier frequencies of the R-GF-LTF to be the opposite of the corresponding frequencies of the GF-LTF to correspond to a fourth data packet format, etc. The example field negator 210 may generate the negation pattern based on a configuration or standard and may transmit the pattern/format correlation to the receiving device during initial communications.

The example length field value encoder 212 of FIG. 2 encodes a value into the length field of the data packet to correspond to the data packet format. For example, the length field value encoder 212 may convey one-bit information by setting the value in the length field (LENGTH) equal to 3(N) + m, where Vis an integer greater than zero and m is either one or two. Accordingly, the one-bit information is embedded by m = LENGTH modulo (mod) 3, where m is either 1 or 2. In this manner, the receiving device can perform the LENGTH mod 3 function to determine a value for m, where m corresponds to one-bit 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 fi eld value encoder 212 stores a 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. Because there may be more than two data formats to identify in a data packet, the length field value encoding technique may be combined with other techniques (e.g., constellation modulation, repeated long training field negation, bit values of a control information field, etc.) to correspond to additional data formats. In some examples, any combination of the above techniques may be utilized to indicate data packet format in a data packet.

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

FIG. 3 is a block diagram of an example implementation of the example data packet analyzer 1 10 of FIG. 1 , disclosed herein, to determine data packet attributes from a received a data packet. The example data packet analyzer 1 10 includes an example component interface 300, an example field analyzer 302, an example pattern identifier 304, an example constellation determiner 306, and an example modulo performer 308.

The example component interface 300 of FIG. 3 interfaces with components of the 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 FIGS. 1 and/or 12 to transmit acknowledgements (ACKs), receive data packets from a transmitting device, and/or transmit decoded data packets to the example application processor 104. In some examples, each received data packet is processed as it is received. In some examples, data packets are group and processed together by the example data packet analyzer 1 10

The example field analyzer 302 of FIG. 3 processes fields of a received data packet to identify data packet type, data packet length, and/or are an end-of-packet pattern based on the received data packet. For example, the field analyzer 302 may process a data packet to identify the data packet length based on the pre- or post- control information subfield of a control information field. As further described below in conjunction 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 a sharing of tail bits with a neighboring control information subfield of the control information field). A pre-control information subfield is encoded at the beginning of the control information field and a post control information subfield is encoded at the end of the control information field. How the control information is encoded (e.g., pre- vs. post- and/or self-decodab le vs non-self decodable) may be predetermined based on a standard and/or previously communicated to the receiving device during initial communications. In some examples, the field analyzer 302 compares the subcarrier frequencies of the GF-LTF and the R- GF-LTF to determine if the subcarrier frequencies of the GF-LTF and the R-GF-LTF correspond to a negation of values of the fiel ds at different subcarrier frequencies to identify a data packet format. As described above in conjunction with FIG. 2, the example data packet information encoder 106 may negate a group of the values at the subcarrier frequencies of the R-GF-LTF to correspond to a data packet format. Accordingly, the field analyzer 302 identifies the negations in the R-GF-LTF based on a comparison with the GF-LTF to identify the data packet format. In some examples, the field analyzer 302 processes a field to identify a value in one or more bits of the data packet corresponding to the data packet format.

The example pattern identifier 304 of FIG. 3 processes a received data packet to identify a predetermined pattern corresponding to an end of the data packet (e.g., an end-of-packet pattern). As described above, in conjunction with FIG. 2, the example data packet information encoder 106 may encode a unique time domain and/or frequency domain pattern at the end of a data packet. The example pattern identifier 304 attempts to identify the unique time domain and/or frequency pattern to identify when the transmission of the data packet has ended. The unique pattern may be predetermined by a standard and/or may be communicated to the receiving device during initial communications between the example AP 100 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 a data packet format. For example, the constellation determiner 306 may demodulate one or more control information subfields (e.g., the pre-/post-HE-SIGA, HE-SIGA1, and/or HE-SIGA2) to determine if the control information subfields were modulated with BPSK (B) or QBPSK (Q), thereby generating an X-bit pattern (e.g., Q;Q;Q, B;B;B, Q;B;B, Q; Q; B, etc., when the number of control information subfields used for the patter (X) is 3), where each pattern may correspond to a different a different data packet format. Example constellation patterns are further described below in conjunction with FIG. 6.

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

FIG. 4 is an example data packet unit (e.g., PPDU) 400 that may be generated by the example AP 100 and/or the example STA 102 of FIG. I that includes fields that correspond to data packet length and/or 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, 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 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 example non-self decodable pre-HE SIGA subfield 416b). As the 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 the example tail bits 418a, 424a, 426b, 432a, example length bits 420a, 420b, 428a, 428b, and example reserved bits 422a, 422b, 430a, 430b.

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 data packet formats by negating a group of the values in subcarrier frequency bands of the R-GF-LTF field 404. For example, the subcarrier values corresponding to the example R-GF-LTF 404 being the same as the subcarrier values of the example GF-LTF field 402 may correspond to a first data packet type (e.g., MU PPDU), the subcarrier values corresponding to the example R-GF-LTF 404 being opposite the subcarrier values of the example GF-LTF field 402 may correspond to a second data packet type (e.g., SU PPDU), a first group of subcarrier values (e.g., half of the subcarrier frequency values) corresponding to the example R-GF-LTF 404 being opposite the subcarrier value of the first group of the example GF-LTF 402 may correspond to a third data packet type (e.g. ER PPDU), etc. 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 the example FIE- S IGA 1 subfield 410, the example HE-SIGA2 subfield 412, and the example post-HE-SIGA subfield 414 or the example pre-HE-SIGA subfield 416. The example HE-SIGA 1 subfield 410 and the example HE-SIGA2 412 include control data (e.g., demystifying modulation and coding scheme (MCS) data, coding data, spatial streams data, etc.). The example post-HE-SIGA subfield 414 and the example pre-HE-SIGA subfield 416 include 28 bits corresponding to a length/number of data bits 420a, 420b, 428a, 428b, reserved bits 422a, 422b, 430a, 430b, and tail bits 424a, 426b, 432a in the posWpre- HE SIGA subfield 414, 416. Additionally, the example post-HE-SIGA subfield 414 and the example pre-HE-SIGA subfield 416 may be self-decodable (e.g., corresponding to the subfields 414a, 416a) or non-self-decodable (e.g., corresponding to the subfields 414b, 416b). A self-decodable subfield has fewer reserved bits 422a, 430a (e.g., 10 bits vs. 16 bits) to make room for dedicated tail bits 424a, 432a. In this manner, the example self-decodable subfields 414a, 416a, are encoded independently such that 1 lax hardware can decode the post-HE SIGA subfield 414. A non-self-decodable bit has more reserved bits 422b, 430b (e.g., 16 bits vs. 10 bits) and shares tail bits 426b with a neighboring HE-SIGA subfield (e.g., the tail bots of the example HE-SIGA! 410 is now shown). For example, the example non-self deeodable subfield 414b shares tail bits 426b with the example HE-SIGA2 subfield 412 and the example non-self deeodable subfield 416b shares tail bits with the example HE-SIGA I subfield 410. In this manner, the example non-self-decodable fields 414a, 416a, are encoded together with the neighboring subfield.

FIG. 5 illustrates an example data packet unit (PPDIJ) 500 with an example end-of- packet pattern field 502 to encode identify an end of the data packet (e.g., to a receiving device) to eliminate a need to encode the data packet length in the data packet, thereby decreasing overhead. The example data packet unit 500 includes the example GF-LTF field 402, the example R-GF-LTF fi eld 404, and the example HE-SIG A field 406 of FIG. 4. The example data packet unit 500 further includes the example end-of-packet pattern field 502, an example time domain pattern 504, and an example frequency domain pattern 506.

As described above in conjunction with FIG. 2, the example data packet information encoder 106 may encode the example data packet unit 500 of FIG. 5 with the example end-of- packet pattern field 502 so that the receiving device can determine the end of the data packet without encoding a length field in the example data packet unit 500 In this manner, the size of the data packet can be reduced. The example end-of-packet field may he encoded with 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 that corresponds to the end of the data packet unit 500 The example time domain pattern 504 may be a pattern that does not correspond to a signal of any other field of the data packet unit 500, thereby reducing a false end-of-packet trigger by 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 us that repeats three times), any unique time domain pattern may be used.

The example frequency domain pattern 506 is a unique frequency signal pattern that corresponds to the end of the data packet unit 500. The example frequency domain pattern 506 may be a pattern that does not correspond to a signal of any other field of the data packet unit 500, thereby reducing a false end-of-packet trigger by the receiving device. Although the example of FIG. 5 corresponds to a particular frequency domain pattern 506 (e.g., a frequency spectrum, where each subsequent frequency is shifted by 180 degrees), any unique frequency domain pattern may be used.

FIG. 6 is an illustration of three different constellations patterns that may be modulated by the example data packet information encoder 106 that may be used to encode data format information into the data packet without dedicating bits, thereby reducing the overhead of the 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- S IGA field symbol 606, a second example HE-SIGA field symbol 608, and a third example HE-SIGA field symbol 610. The 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 to three different data packet formats. For example, the first constellation pattern 600 may correspond to an 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. Additionally, other patterns may correspond to additional data pattern formats (e.g., with a total of 8 different patterns 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 a QBPSK or BPSK constellation. For example, in the first constellation pattern 600, all the field symbols 606, 608, 610 are modulated using a QBPSK constellation; in the second constellation pattern 602, all the field symbols 606, 608, 610 are modulated using a BPSK constellation; and in the 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, the HE~ SIGA field 406 may only include one or two field symbols (e.g., HE-SIGA1 410 and/or HE- SIGA2 412). In such examples, the constellation pattern may only include 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 negation patterns 700, 710 that may be encoded by the example data packet information encoder 106 to encode data format information into the data packet without dedicating bits, thereby reducing the overhead of the data packet transmission. The example negation patterns 700, 710 include the example GF-LTF filed 404 and the example R-GF-LTF field 404 of FIG. 4.

The first example negation pattern 700 of FIG. 7 does not include any negation of the values at each subcarrier frequency (e.g., fzi-fzn). Accordingly, the subcarrier value at each frequency of the GF-LTF 404 is the same as the subcarrier value at corresponding frequencies of the R-GF-LTF 404. Such a pattern corresponds to a first data packet pattern. The second example negation pattern 710 includes a negation of the values at each subcarrier frequency. Accordingly, the value at each subcarrier frequency of the GF-LTF 402 is the opposite of the value at the corresponding subcarrier frequencies of the R-GF-LTF 404. Such a pattern corresponds to a second data packet pattern. In some examples, additional negation patterns may be generated to correspond to additional data packet patterns. For example, a first group of the subcarrier values (ai to ax/2) in a first group of the subcarrier frequencies (fzi to fzn/2) may be negated while a second group of the subcarrier values (e.g., aN/2+1 to ax) in a second group of subcarrier frequencies (fzn/2+1 to fzn) may not be negated to correspond to a third data packet pattern.

While an example manner of implementing the example data packet information encoder 106 and the example data packet analyzer 1 10 of FIG 1 is illustrated in FIGS. 2 and 3, one or more of the elements, processes and/or devices illustrated in FIGS. 2 and 3 may be combined,

6 divided, re-arranged, 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 negator 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 performer 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, any 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 negator 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 performer 308, and/or, more generally, the example data packet analyzer 1 10 of FIG. 3 could be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware

implementation, at least one of the example, 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 negator 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 performer 308, and/or, more generally, the example data packet analyzer 110 of FIG. 3 is/are hereby expressly defined to include a non-transitory computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc., including the software and/or firmware. Further still, 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 in addition to, or instead of, those illustrated in FIGS. 2 and/or 3, and/or may include more than one of any or all of the illustrated elements, processes and devices.

Flowcharts 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 instructi ons for implementing the example data packet analyzer 110 of FIG. 3 is shown in FIGS. 8-1 1. 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 a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), a Blu- ray disk, or a 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 flowchart illustrated in FIGS. 8-1 1, 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 circuitry, a Field

Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), a comparator, an operational -amplifier (op-amp), a logic circuit, etc.) structured to perform the corresponding operation without executing software or firmware.

As mentioned above, the example processes of FIGS. 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, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for 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 device and/or storage disk and to exclude propagating signals and to exclude transmission media.

“Including” and“comprising” (and all forms and tenses thereof) are used herein to be open ended terms. Thus, whenever a claim lists anything following any form of“include” or “comprise” (e.g., comprises, includes, comprising, including, etc.), it is to be understood that additional elements, terms, etc., may be present without falling outside the scope of the corresponding claim. As used herein, when the phrase "at least" is used as the transition term in a preamble of a claim, it is open-ended in the same manner as the term "comprising" and “including” are open ended.

FIG. 8 is an example flowchart 800 representative of example machine readable instructions that may be executed by the example data packet information encoder 106 of FIGS.

1 and/or 2 to indicate data packet length and/or an end of a data packet. Although the example of FIG. 8 is described in conjunction with the example AP 100 and the example STA 102 in the network of FIG. 1, the instructions may be executed by any type of AP and/or STA in any network.

At block 802, the example component interface 200 determines if the AP 100/STA 102 is ready to transmit a data packet to a receiving device. For example, the example component interface 200 may determine that the AP 100/STA 102 is ready to transit a data packet when the example application processor 104 of FIGS. 1 and/or 12 transmits instructions to transmit a data packet. If the example component interface 200 determines that the transmitting device is not to transmit a data packet to the receiving device (block 802: NO), the process continues to monitor instructions from the application processor 104 until instructions are received to transmit a data packet. 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 if the data packet length is to be encoded in the 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 manufacture 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 he encoded in the control information field (block 804: YES), the example control information field encoder 204 encodes the data packet length into a pre- or post- control information subfield of the data packet (block 806). For example, the control information field encoder 204 may encode the example pre- or post- control information subfield 414, 416, as described above in conjunction with FIG. 4

At block 808, the example unique pattern encoder 206 determines if 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 manufacture 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 is not to be encoded in the data packet (block 808: NO), the process continues to block 812. If the example unique pattern encoder 206 determines that the 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 conjunction with FIG. 5 At block 812, the example data encoder 214 encodes data into the 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 flowchart 900 representative of example machine readable instructions that may be executed by the example data packet analyzer 110 of FIGS. 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 conjunction with the example AP 100/STA 102 in the network of FIG. 1, the instructions may be executed by any type of AP/STA in any network.

At block 902, the example component interface 300 determines if the example radio architecture 108 of FIGS. 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 the transmitting device (block 902: NO), the process continues to interface with the receiving device components until a data packet has been received. If the example component interface 300 determines that a data packet has been received from the transmitting device (block 902: YES), the example field analyzer 302 determines if the data packet length is encoded in the 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 manufacture preferences and/or based on a standard (e.g., an IEEE standard). The receiving device may determine that the data packet length is encoded in the control information field and/or data corresponding to the encoding (e.g., pre- vs. post, self-decodabie vs. non-self decodable) based on a standard and/or initial communications between the AP 100 and the ST A 102

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 pre- or post- control information subfield of the control information field (e.g., the example HE-SIGA 406) to determine the data packet length (block 906). For example, the control information subfield may be encoded using the example pre- or post- control information subfield 414, 416, as described above in conjunction with FIG. 4.

At block 908, the example pattern identifier 304 determines if an end-of-packet pattern is encoded in the data packet. For example, the end-of-packet pattern may be encoded in the data packet based on user and/or manufacture preferences and/or based on a standard (e.g., an IEEE standard). If the example pattern identifi er 304 determines that the end-of-packet pattern is not encoded in the data packet (block 908: NO), the process continues to block 912. If the example pattern identifier 304 determines that the 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 by sensing a received unique time domain and/or frequency domain pattern (e.g., via the example component interface 300) (block 910), as described above in conjunction with FIG. 5 At block 912, the example component interface 300 interfaces with the radio architecture 108 to transmit the acknowledgement to the transmitting device.

FIG. 10 is an example flowchart 1000 representative of example machine readable instructions that may be executed by the example data packet information encoder 106 of FIGS.

1 and/or 2 to indicate data packet format. Although the example of FIG. 10 is described in conjunction with the example AP 100/ST A 102 in the network of FIG. 1, the instructions may be executed 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, as described below, based on user and/or manufacture preferences and/or based on a standard (e.g., an IEEE standard).

At block 1002, the example component interface 200 determines if the transmi tting device is ready to transmit a data packet to a receiving device. For example, the example component interface 200 may determine that the transmitting device is ready to transit a data packet when the example application processor 104 of FIGS. 1 and/or 12 transmits instructions to transmit a data packet. If the example component interface 200 determines that the transmitting device is not to transmit a data packet to the receiving device (block 1002: NO), the process continues to monitor instructions from the application processor 104 until instructions are received to transmit a data packet. 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 if the data packet format is to be indicated in the constellation of the control information field (e.g., the example HE-SIGA 406 of FIG. 4) (block 1004).

If the example field modulator 208 determines that the data packet format is not to 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 subfields (e.g., one or more of the example HE-SIGA subfields 410, 412, 114, 416) in a constellation pattern to correspond to the data packet format (block 1006), as described above in conjunction with FIG. 6. The correlation between the constellation pattern and the data packet format may be predefined and/or based on a. standard (e.g , an IEEE standard).

At block 1008, the example field negator 210 determines if the data packet format is to be indicated in the R-LTF (e.g , using a negation pattern between the GF-LTF 402 and the R-GF- LTF 404). If the example field negator 210 determines that the data packet format is not to be indicated in the R-LTF (block 1008: NO), the process continues to block 1012. If the example field negator 210 determines that the data packet format is to be indicated in the R-LTF (block 1008: YES), the example field modulator 208 negates a group of the subcarrier values of the repeated long training field to correspond to a data packet format (block 1010). For example, the field modulator 208 may negate all, none, or part of the R-GF-LTF subcarrier frequency values to correspond to a data packet format, as described above in conjunction with FIG. 7.

At block 1012, the example length field value encoder 212 determines if the data packet format is to be indicated in one or more bits of the control information field (e.g., the example HE-SIGA 406 of FIG. 4). If the example length field value encoder 212 determines that the data packet format is not to be indicated in one or more of 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 of 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 a 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 information field.

At block 1016, the example length field value encoder 212 determines if the data packet is to be indicated based on the 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 the data packet is not 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 the 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 a data packet format using a modulo technique (block 1018). For example, the example length field value encoder 212 may encode the value to correspond to /¾^:=^:LENGTE1 mod 3, such that the m is either 1 or 2, to correspond to two different data formats. As described above, a

combination of the above techniques may be utilized to encode data packet formats. At block 1020, the example data encoder 214 encodes data into the 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 the receiving device.

FIG. 1 1 is an example flowchart 1 100 representative of example machine readable instructions that may be executed by the example data packet analyzer 1 10 of FIGS. 1 and/or 3 to determine a data packet format from a received data packet. Although the example of FIG. 1 1 is described in conjunction with the example AP 100/STA 102 in the network of FIG. 1 , the instructions may be executed by any type of AP/STA in any network. The data packet format may be encoded in the data packet in various ways, as described below, based on user and/or manufacture preferences and/or based on a standard (e.g., an IEEE standard). In some examples, how the data packet format is encoded into the data packet may be communicated between the example AP 100 and the example STA 102 during initial communications.

At block 1102, the example component interface 300 determines if 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 the transmitting device (block 1102: NO), the process continues to interface with the receiving device components until a data packet has been received. If the example component interface 300 determines that a data packet has been received from the transmitting device (block 1102: YES), the example constellation determiner 306 determines if the data packet format is indicated in the constellation of the control information field (e.g , the example HE- S IGA 406 of FIG 4) (block 1 104)

If the example constellation determiner 306 determines that the data packet format is not indicated in the constellation of the control information field (block 1 104: 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 subfields (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 conjunction with FIG. 6. The correlation between the constellation pattern and the data packet format may be predefined and/or based on a standard (e.g., an IEEE standard).

At block 1108, the example pattern identifier 304 determines if the 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 identifier 304 determines that the data packet format is not indicated in the R-LTF (block 1108: NO), the process continues to block 1112. If the example pattern identifier 304 determines that the data packet format is indicated in the R-LTF (block 1108: YES), the example pattern identifier 304 determines the data packet format based on the negation of a group of the subcarrier values of the repeated long training field (block 1110). For example, the pattern identifier 304 may determine that all, none, or part of the R-GF-LTF subcarrier frequency values are negated to correspond to a data packet format, as described above in conjunction with FIG 7.

At block 1 1 12, the example field analyzer 302 determines if the data packet format is indicated in one or more bits of the control information field (e.g., the example HE-SIGA 406 of FIG. 4). If the example field analyzer 302 determines that the data packet format is not indicated in one or more of 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 of 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 the data packet format information from a reserved subfield of the control information field.

At block 1116, the example modulo performer 308 determines if the data packet is indicated based on the 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 performer 308 determines that the data packet is not indicated based on the length field value (block 1116: NO), the process ends.

If the example modulo performer 308 determines that the data packet is indicated based on the length field value (block 1 116: YES), the example modulo performer 308 performs a modulo function using the length field value to determine the data packet format (block 1118). For example, the example modulo performer 308 may determine the value of m, where ?»=LENGTH mod 3, such that the m is either 1 or 2, to correspond to two different data formats. As described above, a combination of the above techniques may be utilized to determine the data packet formats

FIG. 12 is a block diagram of a radio architecture 108 of FIG. 1 in accordance with some examples that may be implemented in the example AP 100 and/or the exampl e STA 102. Radio architecture 108 may include radio front-end module (FEM) circuitry_' 1204, radio IC circuitry 1206 and baseband processing circuitry 1208 Radio architecture 108 as shown includes both Wireless Local Area Network (WLAN) functionality and Bluetooth (BT) functionality although examples are not so limited. In this disclosure,“WLAN” and“Wi-Fi” are used interchangeably.

FEM circuitry' 1204 may include a WLAN or Wi-Fi FEM circuitry 1204a and a Bluetooth (BT) FEM circuitry 1204b. The WLAN FEM circuitry 1204a may include a receive signal path comprising circuitry configured to operate on WLAN RF signals received from one or more antennas 1201, to amplify the received signals and to provide the amplified versions of the received signals to the WLAN radio IC circuitry 1206a for further processing. The BT FEM circuitry' 1204b may include a receive signal path which may include circuitry' configured to operate on BT RF signals received from one or more antennas 1201, to amplify the received signals and to provide the amplified versions of the received signals to the BT radio IC circuitry 1206b for further processing. 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 by one or more of the antennas 1201. In addition, 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 by the one or more antennas. In the examples 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 an 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 circuitries where at least some of the FEM circuitries share transmit and/or receive signal paths for both WLAN and BT signal s.

Radio IC circuitry 1206 as shown may include WLAN radio IC circuitry' 1206a and BT radio IC circuitry 1206b. The WLAN radio IC circuitry 1206a may include a receive signal path which may include circuitry to down-convert WLAN RF signals received from the FEM circuitry' 1204a and provide baseband signals to WLAN baseband processing circuitry_' 1208a.

BT radio IC circuitry 1206b may in turn include a receive signal path which may include circuitry' to down-convert BT RF signals received from the FEM circuitry 1204b and provide baseband signals to BT baseband processing circuitry 1208b WLAN radio IC circuitry 1206a may also include a transmit signal path which 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 by the one or more antennas 1201. BT radio IC circuitry 1206b may also include a transmit signal path which 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 by the one or more antennas 1201. In the example of FIG. 12, although radio IC circuitries 1206a and 1206b are shown as being distinct from one another, examples are not so limited, and include within their scope the use of a radio IC circuitry (not shown) that includes a transmit signal path and/or a receive signal path for both WLA and BT signals, or the use of one or more radio IC circuitries where at least some of the radio IC circuitries share transmit and/or receive signal paths for both WLAN and BT signals.

Baseband processing circuity 1208 may include a WLAN baseband processing circuitry' 1208a and a BT baseband processing circuitry' 1208b. 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 1208a. Each of the WLAN baseband circuitry 1208a and the BT baseband circuitry' 1208b may further include one or more processors and control logic to process the signals received from the corresponding WLAN or BT receive signal path of the radio IC circuitry 1206, and to also generate corresponding WLAN or BT baseband signals for the transmit signal path of the radio IC circuitry' 1206. Each of the baseband processing circuitries 1208a and 1208b may further include physical layer (PHY) and medium access control layer (MAC) circuitry', and may further interface with application processor 104 for generation and processing of the baseband signal s and for controlling operations of the radio IC circuitry' 1206.

Referring still to FIG. 12, according to the shown example, WLAN-BT coexistence circuitry 1213 may include logic providing an interface between the WLAN baseband circuitry' 1208a and the BT baseband circuitry' 1208b to enable use cases 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 the WLAN and BT radios according to application needs. In addition, although the antennas 1201 are depicted as being respectively connected to the WLAN FEM circuitry 1204a and the BT FEM circuitry 1204b, examples include within their scope the sharing of one or more antennas as between the WLAN and BT FEMs, or the provision of more than one antenna connected to each of FEM 1204a or 1204b.

In some examples, the front-end module circuitry 1204, the radio IC circuitry 1206, and baseband processing circuitry 1208 may be provided on a single radio card, such as wireless radio card 1202. In some other examples, the one or more antennas 1201, the FEM circuitry 1204 and the 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 IC 1206.

In some examples, the wireless radio card 1202 may include a WLAN radio card and may be configured for Wi-Fi communications, although the scope of the examples is not limited in this respect. In some of these examples, the 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. The OFDM or OFDMA signals may comprise a plurality of orthogonal subcarriers.

In some of these multicarrier examples, radio architecture 108 may be part of a Wi-Fi communication station (STA) such as a wireless access point (AP), a base station or a mobile device including a Wi-Fi device. In some of these examples, radio architecture 108 may be configured to transmit and receive signals in accordance with specific communication standards and/or protocols, such as any of the Institute of Electrical and Electronics Engineers (IEEE) standards including, 802.11n-2009, IEEE 802.11-2012, IEEE 802.11-2016, 802.11n-2009,

802.1 lac, 802.11 ah, 802.1 lad, 802.1 lay and/or 802.1 lax standards and/or proposed

specifications for WLANs, although the scope of examples is not limited in this respect. Radio architecture 108 may also be suitable to transmit 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) communications in accordance with the IEEE 802.1 lax standard. In these examples, the radio architecture 108 may be configured to communicate in accordance with an OFDMA technique, although the scope of the examples is not limited in this respect

In some other examples, the 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 be compliant with a Bluetooth (BT) connectivity standard such as Bluetooth, Bluetooth 9.0 or Bluetooth 7.0, or any other iteration of the Bluetooth Standard. In examples that include BT functionality as shown for example in FIG. 12, the radio architecture 108 may be configured to establish a BT synchronous connection oriented (SCO) 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 that include a BT functionality, the radio architecture may be configured to engage in a BT Asynchronous Connection-Less (ACL) communications, although the scope of the examples is not limited in this respect. In some examples, as shown in FIG. 12, the functions of a BT radio card and WLAN radio card may be combined on a single wireless radio card, such as single wireless radio card 1202, although 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 a cellular radio card configured for cellular (e.g., 5GPP such as LTE, LTE-Advanced or 7G communi cati ons) .

In some IEEE 802.1 1 examples, the radio architecture 108 may be configured for communication over various channel bandwidths including bandwidths having center frequencies of about 900 MHz, 2.4 GHz, 5 GHz, and bandwidths of about 2 MHz, 4 MHz, 8 5 MHz, 5.5 MHz, 6 MHz, 8 MHz, 10 MHz, 40 MHz, 9 GHz, 46 GHz, 80 MHz, 100 MHz, 80 MHz (with contiguous bandwidths) or 80+80 MHz (I60MHz) (with non-conti guous

bandwidths). In some examples, a 920 MHz channel bandwidth may be used. The scope of the examples is not limited with respect to the above center frequencies however.

FIG. 13 illustrates FEM circuitry 1204 in accordance with some examples. The FEM circuitry 1204 is one example of circuitry that may be suitable for use as the WLAN and/or BT FEM circuitry 1204a/1204b (FIG. 12), although other circuitry' configurations may also be suitable.

In some examples, the FEM circuitry 1204 may include a TX/RX switch 1302 to switch between transmit mode and receive mode operation. The FEM circuitry 1204 may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry'^· 1204 may include a low-noise amplifier (LNA) 1306 to amplify received RF signals 1303 and provide the amplified received RF signals 1307 as an output (e.g., to the radio IC circuitry'^· 1206 (FIG. 12)). The transmit signal path of the circuitry 1204 may include a power amplifier (PA) to amplify input RF signals 1309 (e.g., provided by the radio IC circuitry 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 communication, the FEM circuitry 1204 may be configured to operate in either the 2.4 GHz frequency spectrum or the 12 GHz frequency spectrum. In these examples, the receive signal path of the FEM circuitry 1204 may include a receive signal path duplexer 1304 to separate the signals from each spectrum as well as provide a separate LNA 1306 for each spectrum as shown. In these examples, the transmit signal path of the FEM circuitry' 1204 may also include a power amplifier 1310 and a filter 1312, such as a BPF, a LPF or another type of filter for each frequency spectrum and a transmit signal path duplexer 1314 to provide the signals of one of the different spectrums onto a single transmit path for subsequent transmission by the one or more of the antennas 1201 (FIG. 12). In some examples, BT communications may utilize the 2.4 GHZ signal paths and may utilize the same FEM circuitry 1204 as the one used for WLAN communications.

FIG. 14 illustrates radio IC circuitry 1206 in accordance with some examples. The radio IC circuitry 1206 is one example of circuitry_' that may be suitable for use as the WLAN or BT radio IC circuitry 1206a/1206b (FIG. 12), although other circuitry 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 circuitry 1206 may include at least filter circuitry 1412 and mixer circuitry 1414, such as, for example, up- conversion mixer circuitry. Radio IC circuitry 1206 may also include synthesizer circuitry 1404 for synthesizing a frequency 1405 for use by the mixer circuitry 1402 and the mixer circuitry 1414. The mixer circuitry? 1402 and/or 1414 may? each, according to some examples, be configured to provide direct conversion functionality . The latter type of circuitry presents a much simpler architecture as compared with standard super-heterodyne mixer circuitries, and any flicker noise brought about by the same may be alleviated for example through the use of OFDM modulation. FIG. 14 illustrates only a simplified version of a radio IC circuitry, and may include, although not shown, examples where each of the depicted circuitries may include more than one component. For instance, mixer circuitry 1414 may each include one or more mixers, and filter circuitries 1408 and/or 1412 may each include one or more filters, such as one or more BPFs and/or LPFs according to application needs. For example, when mixer circuitries are of the direct-conversion type, they may each include two or more mixers.

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

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

In some examples, the mixer circuitry 1402 and the mixer circuitry 1414 may each include two or more mixers and may be arranged for quadrature down-conversion and/or up- conversion respectively with the help of synthesizer 1404. In some examples, the mixer circuitry 1402 and the mixer circuitry 1414 may each include two or more mixers each configured for image rejection (e.g., Hartley image rejection). In some examples, the mixer circuitry 1402 and the mixer circuitry 1414 may be arranged for direct down-conversion and/or direct up- conversion, respectively. In some examples, the mixer circuitry' 1402 and the mixer circuitry 1414 may be configured for super-heterodyne operation, although this is not a requirement. Mixer circuitry 1402 may comprise, according to one example: quadrature passive mixers (e.g., for the in-phase (I) and quadrature phase (Q) paths). In such an example, RF input signal 1407 from FIG. 14 may be down-converted to provide I and Q baseband output signals to be sent to the baseband processor

Quadrature passive mixers may be driven by zero and ninety-degree time-varying LO switching signals provided by a quadrature circuitry which may be configured to receive a LO frequency (fLO) from a local oscillator or a synthesizer, such as LO frequency 1405 of synthesizer 1404 (FIG. 14). In some examples, the LO frequency may be the carrier frequency, while in other exampl es, the LO frequency may be a fraction of the carrier frequency (e.g., one- half the carrier frequency, one-third the carrier frequency). In some examples, the zero and ninety-degree time-varying switching signals may be generated by the synthesizer, although the scope of the examples is not limited in this respect.

In some examples, the LO signals may differ in duty cycle (the percentage of one period in which the LO signal is high) and/or offset (the difference between start points of the period).

In some examples, the LO signals may have a 125% duty cycle and a 120% offset. In some examples, each branch of the mixer circuitry (e.g., the in-phase (I) and quadrature phase (Q) path) may operate at a 120% duty cycle, which may result in a significant reduction is 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 low-nose amplifier, such as amplifier circuitry 1206 (FIG. 12) or to filter circuitry 1208 (FIG. 12).

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

In some dual-mode examples, a separate radio IC circuitry may be provided for processing signals for each spectrum, or for other spectrums not mentioned here, although the scope of the examples is not limited in this respect. In some examples, the synthesizer circuitry 1404 may be a fractional -N synthesizer or a fractional N/N+ I synthesizer, although the scope of the examples is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry' 1404 may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase- locked loop with a frequency divider. According to some examples, the synthesizer circuitry'

1404 may include digital synthesizer circuitry'. An advantage of using a digital synthesizer circuitry' is that, although it may still include some analog components, its footprint may be scaled down much more than the footprint of an analog synthesizer circuitry'. In some examples, frequency input into synthesizer circuity 1404 may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. A divider control input may further be provided by either the baseband processing circuitry 1208 (FIG. 12) or the application processor 104 (FIG.

12) depending on the desired output frequency 1405 In some examples, a 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 as determined or indicated by the application processor 104. The application processor 104 may include, or otherwise be connected to, the example data packet inform ation encoder 106 of FIG. 1 and/or the exampl e data packet analyzer 1 10 of FIG. 3.

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

FIG. 15 illustrates a functional block diagram of baseband processing circuitry' 1208 in accordance with some examples. The baseband processing circuitry 1208 is one example of circuitry that may be suitable for use as the baseband processing circuitry 1208 (FIG. 12), although other circuitry' configurations may also be suitable. The baseband processing circuitry 1208 may include a receive baseband processor (RX BBP) 1502 for processing receive baseband signals 1509 provided by the radio IC circuitry 1206 (FIG. 12) and a transmit baseband processor (TX BBP) 1504 for generating transmit baseband signals 151 1 for the radio IC circuitry' 1206. The baseband processing circuitry 1208 may also include control logic 1506 for coordinating the operations 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 ADC 1510 to convert analog baseband signals 1509 received from the radio IC circuitry 1206 to digital baseband signals for processing by the RX BBP 1502. In these examples, the baseband processing circuitry 1208 may also include DAC 1512 to convert digital baseband signals from the TX BBP 1504 to analog baseband signals 1511.

In some examples that communicate OFDM signals or OFDM A signals, such as through baseband processor 1208a, the transmit baseband processor 1504 may be configured to generate OFDM or OFDMA signals as appropriate for transmission by performing an inverse fast Fourier transform (IFFT). The receive baseband processor 1502 may be configured to process received OFDM signals or OFDMA signals by performing an 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 an autocorrelation, to detect a preamble, such as a short preamble, and by performing a cross-correlation, to detect a long preamble. The preambles may be part of a predetermined frame structure for Wi-Fi communication.

Referring back to FIG. 12, in some examples, the antennas 1201 (FIG. 12) may each comprise 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, the antennas may be effecti vely 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, although examples are not so limited.

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, the functional elements 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 FIGS. 1 and 2. The processor platform 1600 can be, for example, a server, a personal computer, a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad™), a personal digital assistant (PDA), an 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 can be implemented by integrated circuits, logic circuits, microprocessors or controllers from any- desired family or manufacturer.

The processor 1612 of the illustrated example includes a local memory- 1613 (e.g., a cache). The example processor 1612 of FIG. 16 executes the instructions of FIGS. 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 negator 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 performer 308 of FIG. 3, and/or the example application processor 104 of FIGS. 1 and/or 12. The processor 1612 of the illustrated example is in communication with a main memory including a volatile memory 1614 and a 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 memory device. Access to the main memory? 1614, 1616 is controlled by a clock controller.

The processor platform 1600 of the illustrated example also includes an interface circuit 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. The input device(s) 1622 permit(s) a user to enter data and commands into the processor 1612. The input device(s) can be implemented by, for example, a sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, isopoint and/or a voice recognition system.

One or more output devices 1624 are also connected to the interface circuit 1620 of the illustrated example. The output devices 1624 can be implemented, for example, by display devices (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). The interlace circuit 1620 of the illustrated example, thus, typically includes a graphics driver card, a graphics driver chip or a graphics driver processor.

The interface circuit 1620 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem and/or network interface card to facilitate exchange of data with external machines (e.g., computing devices of any kind) via a network 1626 (e.g , an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.).

The 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 drive disks, compact disk drives, Blu-ray disk drives, RAID systems, and digital versatile disk (DVD) drives.

The coded instructions 1632 of FIGS. 8-1 1 may be stored in the mass storage devi ce 1628, in the volatile memory 1614, in the non-volatile memory 1616, and/or on a removable tangible computer readable storage medium such as a CD or DVD.

From the foregoing, it would be appreciated that the above disclosed method, apparatus, and articles of manufacture indicate data packet attributes in wireless communication. In some examples disclosed herein, a transmitting device 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. 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., so that the data packet length is not needed). In some examples, a transmitting device may encode a data packet format by (A) modulating the constellations of the control information subfields in a pattern that corresponds to a data packet format, (B) negating a group of the repeated long training field subcarrier values at different subcarrier frequencies of a data packet to correspond to a data packet format, (C) dedicating one or more bits of a control information field to correspond to a data packet format, and/or (D) seting the length field value to correspond to a data packet format based on a modulo calculation technique. Using examples disclosed herein, the legacy preambles may be removed to reduce overhead and increase efficiency while still providing data packet length and/or format.

Example 1 is an apparatus to indicate data packet length in a wireless communication. 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 the length of the data packet using at least one of a subfield of a 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 the subfield of the control information field by encoding the data packet length into a pre-control information subfield or a post-control information subfield of the control information field.

Example 3 includes the subject matter of Example 2, wherein the at least one of the pre control information subfield or the post-control information subfield shares tail bits with a neighboring control information subfield.

Example 4 includes the subject matter of Example 1, wherein the control information field corresponds to an HE- S IGA field.

Example 5 is an apparatus to indicate data packet length in a wireless communication. Example 5 includes a component interface to receive instructions to generate a data packet. Example 5 further includes a data packet length encoder to encode an end-of-data packet pattern at an end of the data packet.

Example 6 includes the subject matter of Example 5, wherein the data packet length encoder is to encode the end-of-data packet pattern into a field of the data packet.

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

Example 8 includes the subject matter of Example 5, wherein the data packet length encoder is to encode the end-of-data packet pattern to be a unique time domain pattern.

Example 9 includes the subject matter of Example 8, wherein the unique time domain pattern is different than other possible time domain patterns of the data packet. Example 10 includes the subject matter of Example 5, wherein the data packet length encoder is to encode the end-of-data packet pattern to be a unique frequency domain pattern.

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

Example 12 is an apparatus to indicate data packet format in a wireless communication. Example 12 includes a data packet information determiner to determine a format of a data packet to be transmitted to a receiving device. Example 12 further includes a data packet format encoder to encode the format of the data packet using at least one of (A) a repeated field of the data packet or (B) a control information field of the 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), 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 mater 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 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 the format of the data packet by negating a first group of subcarri er frequency values of the repeated field to correspond to a first data packet format.

Example 18 includes the subject matter of Example 17, wherein the first group 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 by not negating a second group of subcarrier frequency values of the repeated field to correspond to a second data packet, the second group being different than the first group.

Example 20 includes the subject matter of Example 12, wherein the data packet format encoder is to encode the data packet format by not negating a group of subcarrier frequency value of the repeated field to correspond to a third data packet format.

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

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

Example 23 includes the subject mater of Example 22, wherein the instructions cause the machine to encode the data packet length using the subfield of the control information field includes encoding the data packet length into a pre-control information subfield or a post-control information subfield of the control information field.

Example 24 includes the subject matter of Example 23, wherein the at least one of the pre-control information subfield or the post-control information subfield shares tail bits with a neighboring control information subfield.

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

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

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

Example 28 includes the subject matter of Example 27, wherein the field is at the 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 than 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 mater of Example 31, wherein the unique frequency domain pattern is different than other possible frequency domain patterns of the data packet.

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

Example 34 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 modulating a constellation of a second subfield of the control information field, the constellation

corresponding to the data packet format.

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), QBPSK corresponding to a ninety-degree rotation of BPSK.

Example 36 includes the subject mater 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 cause the machine to set a value of a subfield of the control information field to correspond to data packet format based on a modulo technique.

Example 38 includes the subject matter of Example 33, wherein the instructions cause the machine to encode the format of the data packet by negating a first group of subcarrier frequency values of the repeated fi eld to correspond to a first data packet format.

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

Example 40 includes the subject matter of Example 38, wherein the instructions cause the machine to encode the format of the data packet by not negating a second group of subcarrier frequency values of the repeated field to correspond to a. second data packet, the second group being different than the first group. Example 41 includes the subject matter of Example 33, wherein the instructions cause the machine to encode the data packet format by not negating a group of subcarrier frequency value of the repeated field to correspond to a third data packet format.

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

Example 43 is a method to indicate data packet length in a wireless communication. 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 a subfield of a 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 includes encoding the data packet length into a pre-control information subfield or a post-control information subfield of the control information field.

Example 45 includes the subject matter of Example 44, wherein the at least one of the pre-control information subfield or the post-control information subfield shares tail bits with a neighboring control information subfield.

Example 46 includes the subject matter of Example 43, wherein the control information field corresponds to an HE- S IGA field.

Example 47 is a method to indicate data packet length in a wireless communication. Example 47 includes receiving instructions to generate a data packet; and encoding an end-of- data packet pattern at an end of the data packet.

Example 48 includes the subject matter of Example 47, further including encoding the 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 at the end of the data packet.

Example 50 includes the subject matter of Example 47, further including 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 than other possible time domain patterns of the data packet.

Example 52 includes the subject matter of Example 47, further including 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 than other possible frequency domain patterns of the data packet.

Example 54 is a method to indicate data packet length in a wireless communication. 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 repeated field of the data packet or (B) a control information field of the data packet.

Example 55 includes the subject matter of Example 54, further including 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 including modulating the constellation using binary phase-shift keying (BPSK) or quadrature phase shift keying (QBPSK), QBPSK corresponding to a ninety-degree rotation of BPSK.

Example 57 includes the subject matter of Example 54, further including 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 including setting a value of a subfield of the control information field to correspond to data packet format based on a modulo technique.

Example 59 includes the subject matter of Example 54, further including encoding the format of the data packet by negating a first group of subcarrier frequency values of the repeated field to correspond to a first data packet format.

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

Example 61 includes the subject matter of Example 59, further including encoding the format of the data packet by not negating a second group of subcarrier frequency values of the repeated field to correspond to a second data packet, the second group being different than the first group.

Example 62 includes the subject matter of Example 54, further including encoding the data packet format by not negating a group of subcarrier frequency value of the repeated field to correspond to a third data packet format. Example 63 includes the subject matter of Example 54, wherein the repeated field corresponds to a repeated long training (R-LTF) field.

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

Example 65 includes the subject matter of Example 64, wherein the second means includes means for encoding the data packet length using the subfield of the control information field by encoding the data packet length into a pre-control information subfield or a post-control information subfield of the control information field.

Example 66 includes the subject matter of Example 65, wherein the at least one of the pre-control information subfield or the post-control information subfield shares tail bits with a neighboring control information subfield.

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

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

Example 69 includes the subject matter of Example 68, wherein the second means includes means for encoding the 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 at the end of the data packet.

Example 71 includes the subject matter of Example 68, wherein the second means includes means for encoding the end-of-data packet pattern to be a unique time domain pattern.

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

Example 73 includes the subject matter of Example 69, wherein the second means includes means for encoding the end-of-data packet pattern to be a unique frequency domain pattern.

Example 74 includes the subject matter of Example 73, wherein the unique frequency- domain pattern is different than other possible frequency domain patterns of the data packet. Example 75 is an apparatus to indicate data packet format in a wireless communication. Example 75 includes a first means for determining a format of a data packet to be transmitted to a receiving device; and a second means for encoding the format of the data packet using at least one of (A) a repeated field of the data packet or (B) a control information field of the data packet.

Example 76 includes the subject matter of Example 75, wherein the second means 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 includes means for modulating the constellation using binary phase-shift keying (BPSK) or quadrature phase shift keying (QBPSK), 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 includes means for setting a value of a subfield of the control information field to correspond to data packet format based on a modulo technique.

Example 80 includes the subject matter of Example 75, wherein the second means includes means for encoding the format of the data packet by negating a first group of subcarrier frequency values of the repeated field to correspond to a first data packet format.

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

Example 82 includes the subject matter of Example 80, wherein the second means includes means for encoding the format of the data packet by not negating a second group of subcarrier frequency values of the repeated field to correspond to a second data packet, the second group being different than the first group.

Example 83 includes the subject matter of Example 75, wherein the second means includes means for encoding the data packet format by not negating a group of subcarrier frequency value of the repeated field to correspond to a third data packet format. Example 84 includes the subject matter of Example 75, wherein the repeated field corresponds to a repeated 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 claims of this patent.

Claims

What Is Claimed Is:

1. An apparatus to indicate data packet format in a wireless communication, the apparatus comprising;

a data packet information determiner to determine a format of a data packet to be transmitted to a receiving device, and

a data packet format encoder to encode the format of the data packet using at least one of (A) a repeated 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 data packet format based on a modulo technique.

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

7. The apparatus of claim 6, wherein the first group 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 the format of the data packet by not negating a second group of subcamer frequency values of the repeated field to correspond to a second data packet, the second group being different than the first group.

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

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

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

determine a format of a data packet to be transmitted to a receiving device; and encode the format of the data packet using at least one of (A) a repeated 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 1 1 , wherein the instructions cause the machine to set a value of a subfield of the control information field to correspond to 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 by negating a first group of subcarrier frequency values of the repeated field to correspond to a first data packet format.

17. The computer storage readable medium of claim 16, wherein the first group of subcarrier frequency values corresponds 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 by not negating a second group of subcarrier frequency values of the repeated field to correspond to a second data packet, the second group being different than the first group.

19. The computer storage readable medium of claim 1 1 , wherein the instructions cause the machine to encode the data packet format by not negating a group of subcarrier frequency value of the repeated field to correspond to a third data packet format.

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

21. A method to indicate data packet length in a wireless communication, the method comprising:

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 repeated field of the data packet or (B) a control information field of the data packet.

22. The method of claim 21, further including 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 including 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 including 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 including setting a value of a subfield of the control information field to correspond to data packet format based on a modulo technique.