Apparatus and method for reduced delay uplink transmission

Abstract

Techniques related to reducing uplink (UL) transmission delays for communications between a Wi-Fi workstation (STAs) and an access point (APs) are described. A device may send a request frame in a downlink (DL) physical protocol data unit (PPDU) to one or more workstations (STAs) associated with the device during a downlink (DL) transmission opportunity (TXOP) controlled by the device. The request frame may request one or more STAs to transmit uplink low latency (ULLL) data or one or more requests to transmit ULLL data to the apparatus. The apparatus may also receive the ULLL data or at least one request from at least one STA of the one or more STAs to transmit the ULLL data in a trigger base (TB) uplink (UL) PPDU that follows a transmission of the DL PPDU.

Description

[0001] Cross-referencing

[0002] This disclosure is part of a non-provisional patent application claiming priority to U.S. Provisional Patent Application No. 63 / 483,540 (filed February 7, 2023), the entire contents of which are incorporated herein by reference. [Technical Field]

[0003] The technical field of this disclosure is generally related to wireless communication, and in particular to data transmission between Wi-Fi workstations (STAs) and access points (APs). [Background Technology]

[0004] Unless otherwise stated herein, the methods described in this section are not prior art to the claims listed below and are not acknowledged as prior art by virtue of their inclusion in this section. For Wi-Fi communication, deterministic ultra-low latency data transmission can be crucial for certain consumer and automation applications. Such applications may include, for example, augmented reality (AR) / virtual reality (VR) / extended reality (XR), remote work, factory automation, process automation, robotics, audio / video streaming, etc. Current technology trends also show an increasing demand for event-based low-latency data transmission, such as for content rendering corresponding to user input / actions (e.g., VR, games, etc.), event-driven vision sensors with data rates that change according to perceived scene variations, or parsing time-critical events such as limit switches, emergency stops, etc. In such applications, low-latency traffic is typically event-driven and non-static.

[0005] Currently, some existing mechanisms provide channel access control for Low Latency (UL) transmissions for Stations (STAs), such as uplink OFDMA-triggered transmissions and service cycle allocation. These mechanisms allow Access Points (APs) to meet known scheduling requirements for UL transmissions from applications on STAs. For example, when the serving application has known characteristics, the AP can use these tools to trigger uplink transmissions. However, event-based applications may have unknown characteristics, and their UL data traffic is unpredictable. Therefore, when the AP's downlink (DL) transmissions occupy the transmission medium, the STA may not be able to preempt the medium to send low-latency uplink traffic using contention-based channel access mechanisms. In other words, for APs that control the transmission medium for DL ​​transmissions most of the time, it is difficult to know whether an STA has low-latency UL packets to transmit because the traffic is event-based. Therefore, techniques to improve uplink low-latency service performance are needed. [Summary of the invention]

[0006] The following summary is for illustrative purposes only and is not intended to be limiting in any way. That is, the following summary aims to introduce the concepts, highlights, benefits, and advantages of the novel and non-obvious techniques described herein. Selected embodiments will be further illustrated in the detailed description. Therefore, the following summary is not intended to identify the essential features of the claimed subject matter, nor is it intended to determine the scope of the claimed subject matter.

[0007] One objective of this disclosure is to provide schemes, concepts, designs, techniques, methods, and apparatus related to using request frames to reduce uplink (UL) transmission latency in communication between Wi-Fi workstations (STAs).

[0008] In one aspect, an apparatus may include a transceiver configured for wireless communication and a processor coupled to the transceiver. During a transmission opportunity (TXOP), the processor may send a request message in a downlink (DL) Physical Protocol Data Unit (PPDU) instructing one or more stations (STAs) associated with the apparatus to transmit uplink low-latency (ULLL) data or one or more requests to transmit ULLL data to the apparatus. The processor may also receive the ULLL data or at least one request from at least one of the one or more STAs to transmit the ULLL data in response to the request message. The apparatus may be a TXOP holder or a TXOP responder.

[0009] In another aspect, a method may include sending a request message from an access point (AP) during a TXOP, in a DL PPDU, instructing one or more STAs associated with the device to send ULLL data or one or more requests to transmit ULLL data to the AP. The method may also include receiving the ULLL data or at least one request from at least one of the one or more STAs in response to the request message to transmit the ULLL data. The AP may be a TXOP holder or a TXOP responder.

[0010] In another aspect, a method may include sending a request message from an access point (AP) during a TXOP, in a DL PPDU, instructing permission for one or more STAs associated with the device to send ULLL data or one or more requests to transmit ULLL data to the AP. The method may further include, after the AP receives a subsequent UL transmission including at least one request to transmit ULLL data from at least one of the one or more STAs, sending a trigger frame from the AP requesting the transmission of additional ULLL data from the one or more STAs during the TXOP or requesting the transmission of ULLL data. The AP may be a TXOP holder or a TXOP responder.

[0011] It is worth noting that while the descriptions provided herein may be made in the context of certain wireless access technologies, networks, and network topologies (such as Wi-Fi), the proposed concepts, schemes, and any variations / derivatives thereof can be implemented in other types of wireless access technologies, networks, and network topologies, such as, but not limited to, Bluetooth, ZigBee, 5G / New Radio (NR), LTE, LTE-Advanced, LTE-Advanced Pro, Internet of Things (IoT), Industrial Internet of Things (IIoT), and Narrowband Internet of Things (NB-IoT). Therefore, the scope of this disclosure is not limited to the examples described herein. [Attached Image Description]

[0012] Brief description of the drawings

[0013] The accompanying drawings are included to provide a further understanding of the present disclosure and form part of it. The drawings illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure. It should be noted that the drawings are not necessarily to scale, as some components may be shown out of proportion to their actual dimensions in order to clearly illustrate the concepts of the present disclosure.

[0014] Figure 1 This is a diagram of an example network environment in which various solutions and schemes conforming to this disclosure can be implemented.

[0015] Figure 2 This demonstrates how access points (APs) use request frames to reduce uplink transmission latency in communication between Wi-Fi workstations (STAs) and the AP.

[0016] Figure 3 This demonstrates that during downlink data, control frame, and / or management frame transmissions, the AP may allocate some resources to reduce the latency of uplink low-latency traffic.

[0017] Figure 4 A first implementation of using request frames to reduce uplink transmission latency in communication between Wi-Fi STA and AP is demonstrated.

[0018] Figure 5 A second implementation scheme is shown that uses request frames to reduce uplink transmission latency in communication between Wi-Fi STAs and APs.

[0019] Figure 6a and 6b A third implementation scheme is shown that uses request frames to reduce uplink transmission latency in communication between Wi-Fi STA and AP.

[0020] Figure 7a and 7bA fourth implementation is shown that uses request frames to reduce uplink transmission latency in communication between Wi-Fi STAs and APs.

[0021] Figure 8a and 8b A fifth implementation is shown that uses request frames to reduce uplink transmission latency in communication between Wi-Fi STAs and APs.

[0022] Figure 9 This is a block diagram of an example communication system, conforming to various embodiments of this disclosure.

[0023] Figure 10 This is a flowchart of a first example process conforming to various embodiments of this disclosure.

[0024] Figure 11 This is a flowchart of a second example process conforming to various embodiments of this disclosure. [Specific implementation method]

[0025] Detailed embodiments and implementations of the claimed content are disclosed herein. However, it should be understood that the disclosed embodiments and implementations are merely illustrative of the claimed content, which can be embodied in various forms. This disclosure can be embodied in many different forms and should not be construed as being limited to the exemplary embodiments and implementations described herein. Rather, these exemplary embodiments and implementations are intended to make the description of this disclosure comprehensive and complete, and to fully convey the scope of this disclosure to those skilled in the art. Details of well-known features and techniques may be omitted in the following description to avoid unnecessarily obscuring the presented embodiments and implementations.

[0026] Overview

[0027] The embodiments disclosed herein relate to various technologies, methods, schemes, and / or solutions that reduce uplink transmission latency in communication between Wi-Fi workstations (STAs) and access points (APs). According to this disclosure, multiple possible solutions can be implemented individually or in combination. That is, although these possible solutions may be described individually below, two or more of these possible solutions may be implemented in one or another combination. Various solutions and scheme implementations use request frames to reduce uplink (UL) transmission latency in communication between Wi-Fi workstations (STAs) and access points (APs). Therefore, the various solutions and schemes presented herein can address or mitigate the problem of workstations failing to meet Quality of Service (QoS) requirements for uplink low-latency (ULLL) data due to the event-driven and non-static nature of the data.

[0028] Figure 1An example network environment 100 is shown, in which various solutions and schemes according to this disclosure can be implemented. Figures 1 to 11 Examples of various proposed solutions in the network environment 100 disclosed herein are illustrated. The following description of the various proposed solutions is for reference only. Figures 1 to 11 Provided.

[0029] refer to Figure 1 Network environment 100 may include multiple workstations (e.g., STA1 102, STA2 104, STA1 106) associated with and wirelessly communicating with access point (AP) 108. According to various proposals disclosed herein, the multiple workstations of network environment 100 may send uplink transmissions to the AP and receive downlink transmissions from the AP.

[0030] According to the proposed scheme, an access point (e.g., AP 108) can use request information / frames with ULLL resource element (RU) allocation to request hybrid uplink orthogonal frequency division multiple access (OFDMA) transmissions (e.g., ULLL transmissions) from workstations (e.g., STA 102, 104, 106). Figure 2 As shown, the AP can send a request message / frame 202 to one or more workstations in a Transmission Opportunity (TXOP) via a downlink Physical Protocol Data Unit (PPDU) according to the proposed scheme. The request message / frame 202 may contain the allocation of one or more ULLL RUs so that one or more workstations can send any ULLL data that the one or more workstations may possess to the AP in a subsequent PPDU 204 (e.g., in a Trigger-Based (TB) Uplink (UL) PPDU format). Alternatively, the request message / frame 202 may contain the allocation of one or more ULLL RUs in a subsequent PPDU 204 so that one or more workstations can send one or more requests to the AP to transmit ULLL data. For example, each request is initiated by the corresponding workstation to request additional uplink resource allocation to send ULLL data to the AP. In this way, the AP can use the request frame 202 to request ULLL data or request the transmission of ULLL data by allocating one or more low-latency specific RUs during downlink transmission. Specific RUs may occupy part or all of the PPDU bandwidth. The request information can be carried in the physical layer (PHY) header of the downlink PPDU (e.g., the signaling field of the PHY header).

[0031] Furthermore, the allocated ULLL RU can be aggregated in OFDMA with the RU allocated for the response frame of the previous downlink transmission. For example, as Figure 2As shown, TB PPDU 204 may include ULLL RUs (Part A) allocated to one or more workstations and RUs (Part B) allocated to one or more workstations to provide downlink responses, such as acknowledgments of downlink transmissions received from the AP. In some cases, as further described below, any workstation with low-latency data may randomly or exclusively select one ULLL RU to transmit its low-latency data or to notify the AP that it has low-latency data. Furthermore, the AP may allocate more ULLL RUs in one or more subsequent request frames within the same DL TXOP for workstations indicating that they have more low-latency data.

[0032] Figure 3 This demonstrates that the AP can allocate some resources for ULLL traffic during downlink data, control frame, and / or management frame transmissions to reduce latency for uplink low-latency traffic. For example... Figure 3 As shown, the downlink multi-user (MU) PPDU 302 sent by the AP to a workstation (also referred to herein as a non-AP workstation) may include a request frame for polling ULLL traffic from one or more workstations. It is worth noting that in some implementations, one or more workstations may not be in the same group of workstations receiving data in the downlink MU PPDU 302. In some embodiments, the DL-MU PPDU 302 may include downlink data, one or more control frames, and / or one or more management frames in addition to the request frame, for certain associated workstations, which may include at least one workstation. In other embodiments, the one or more workstations polling ULLL traffic may not be the same workstation from which the AP sends data, control frames, and / or one or more management frames in the DL-MU PPDU 302.

[0033] Request frames can include resource allocation (ULLL RU allocation) for any potential ULLL data transmission or requests to transmit ULLL data from one or more STAs. In some cases, the AP can configure request frames to allocate one or more dedicated ULLL RUs to one or more specific STAs. For example, the AP can configure request messages / frames to allocate part or all of the bandwidth of a PPDU to a series of STAs. Each STA in this series of STAs can be assigned to a specific RU. ULLL RU 1 can be assigned to STA1, ULLL RU 2 can be assigned to STA2, ULLL RU 3 can be assigned to STA3, and so on. In other cases, the AP can configure request frames to allocate a predetermined number of ULLL RUs and instruct any STA with ULLL data that it can randomly select any available ULLL RU to send ULLL data or request to transmit ULLL data to the AP (this may result in collisions). Furthermore, as shown with respect to TB UL PPPU 304, the acknowledgment response / block acknowledgment (Ack / BA) of DL-MU PPDU 302 sent by one or more STAs can be aggregated in the frequency domain with ULLL data and / or one or more requests to transmit ULLL data.

[0034] Figure 4A first implementation of the proposed scheme is shown, in which the intended receiving STA of the DL-MU PPDU supports a specific acknowledgment policy (e.g., HETP acknowledgment policy). During an AP-controlled DL TXOP, the AP can request ULLL data from one or more STAs or request the transmission of ULLL data by including a request frame 404 in the DL-MU PPDU 402. As shown, the request frame 404 can be aggregated in the frequency domain with one or more Aggregated MAC Protocol Data Units (A-MPDUs) for one or more intended DL data receiving STAs (e.g., STA1, STA2, STA3) in the DL-MU PPDU 402. In this implementation, the signaling field (SIG-B) in the PHY header of the DL-MU PPDU 402 can include a special identifier (STA-ID) (e.g., STA-ID 2048) to indicate the presence of a request frame 404 in a specific RU of the DL-MU PPDU 402. Furthermore, the request frame 404 can allocate one or more ULLL RUs for one or more STAs to send ULLL data or request one or more ULLL data transmissions to the AP. The ULLL RUs allocated by request frame 404 can be dedicated ULLL RUs or randomly accessible ULLL RUs. Therefore, each STA with ULLL data that receives DL-MU PPDU 402 and discovers the special identifier in the signaling field can decode request frame 404 to determine the appropriate ULLL RU allocated for use. Subsequently, each STA with ULLL data can use the corresponding ULLL RU in TB UL PPDU 406 to send ULLL data or request transmission ULLL data to the AP. TBUL PPDU 406 can be sent by the AP after a short frame interval (SIFS) period 408 following the transmission of DL-MU PPDU 402. In other implementations, the signaling field (SIG-B) in the PHY header of DL-MU PPDU 402 can indicate the RU allocation for ULLL request or data transmission. For example, the entire bandwidth of the TXOP bandwidth is allocated to ULLL request or data transmission. RU allocation can be identified by a special identifier (STA-ID) (e.g., STA-ID 2048). Subsequently, each STA with ULLA data can send a ULLL request to the AP during the SIFS cycle following the DL-MU PPDU 402 transmission.

[0035] Furthermore, each A-MPDU in DL-MU PPDU 402 may include one or more QoS data frames configured with a specific acknowledgment policy (e.g., "HETP acknowledgment"), wherein the corresponding A-MPDU for each receiving STA may include trigger information (e.g., trigger information in the trigger frame or the A-control field of the MPDU header) prompting each receiving STA to respond with a trigger-based ACK / BA. Therefore, as shown in TB UL PPDU 406, any ULLL data or request to transmit ULLL data from any ULLL STA can be aggregated with trigger-based ACK / BAs transmitted in the frequency domain by the receiving STA of DL-MU PPDU 402.

[0036] Figure 5 A second implementation of the proposed scheme is shown. In this implementation, the Access Point (AP) can use a Block Acknowledgment Request (BAR) frame or a Multi-User Block Acknowledgment Request (MU-BAR) trigger frame 502 as a request frame in a Downlink (DL) Physical Protocol Data Unit (PPDU) to request one or more Stations (STAs) to send Uplink Low Latency (ULLL) data or request the transmission of ULLL data during an AP-controlled DL Transmission Opportunity (TXOP). The BAR or MU-BAR trigger frame 502 is typically sent by the AP to trigger one or more receiving STAs to provide feedback and / or acknowledgment of DL data (e.g., QoS data frames) previously sent by the AP in the DL TXOP. In this implementation, the BAR or MU-BAR trigger frame 502 can be modified by ULLL trigger information. For example, the BAR or MU-BAR trigger frame can include a special identifier (STA-ID) (e.g., STA-ID 2048) to indicate the presence of ULLL trigger information in a specific Resource Unit (RU) of the DL PPDU 504 carrying the BAR or MU-BAR trigger frame 502. ULLL trigger information can assign one or more ULLL RUs to one or more STAs to send ULLL data or request one or more ULLL data transmissions to the AP. The ULLL RU assigned by the BAR or MU-BAR trigger frame 502 can be a dedicated ULLL RU or a randomly accessible ULLL RU. The trigger information can also identify a range of STAs or one or more associated IDs (AIDs) of a specific STA for polling for ULLL transmissions, i.e., identifying one or more specific STAs that are allowed to send their ULLL data or request ULLL data transmissions (if any) to the AP during DL TXOP.

[0037] Therefore, each STA with ULLL data, upon receiving a BAR or MU-BAR trigger frame 502 and discovering a special identifier, can decode the frame to determine whether the STA is permitted to send ULLL data or request transmission ULLL data to the AP. If permitted, it uses the correspondingly assigned ULLL RU. Subsequently, each permitted STA with such ULLL data can use the corresponding ULLL RU in the Trigger Base (TB) Uplink (UL) PPDU 506 to send ULLL data or request transmission ULLL data to the AP. The TB UL PPDU 506 can be sent by the AP after the Short Frame Interval (SIFS) period 508 following the transmission of the BAR or MU-BAR trigger frame 502. As shown, any ULLL data or request transmission ULLL data sent by any STA to the AP can be aggregated in the frequency domain with the Trigger Base Acknowledgment / Block Acknowledgment (ACK / BA) of the receiving STA (e.g., STA1-STAy) of the BAR or MU-BAR trigger frame 502.

[0038] Figure 6a and 6b A third implementation of the proposed scheme is shown. For example... Figure 6aAs shown, during an AP-controlled DL TXOP, the AP can request one or more STAs to send ULLL data or request the transmission of ULLL data by including a request frame 604 in the DL-MU PPDU 602. As illustrated, the request frame 604 can be aggregated in the frequency domain with the aggregated MAC Protocol Data Unit (A-MPDU) of one or more target DL data receiving STAs (e.g., STA1, STA2, STA3) in the DL-MU PPDU 602. In this implementation, the signaling field (SIG-B) in the physical layer (PHY) header of the DL-MU PPDU 602 can contain a special identifier (STA-ID) (e.g., STA-ID 2048) to indicate the presence of the request frame 604 in a specific RU of the DL-MU PPDU 602. Furthermore, the request frame 604 can allocate one or more ULLL RUs for one or more STAs to send ULLL data or request one or more ULLL data to be transmitted to the AP. The ULLL RU allocated by the request frame 604 can be a dedicated ULLL RU or a randomly accessible ULLL RU. Furthermore, each A-MPDU in DL-MU PPDU 602 can contain QoS data frames with an acknowledgment policy set to block acknowledgment, so that the receiver of the A-MPDU will not immediately send an acknowledgment / block acknowledgment after the SIFS period 606 following the receipt of DL-MU PPDU 602. In this implementation, the entire TXOP bandwidth can be allocated to ULLL request or data transmission. Any ULLL data sent by any ULLL STA or request to transmit ULLL data can be sent after the SIFS period following the transmission of DL-MU PPDU 602, without aggregating any acknowledgments / block acknowledgments from the receiving STA of DL-MU PPDU 602.

[0039] Therefore, each STA with ULLL data, upon receiving DL-MU PPDU 602 and discovering the special identifier in the signaling field, can decode request frame 404 to determine the appropriate ULLL RU allocated for use. Subsequently, each STA with ULLL data can use the corresponding ULLL RU in PPDU 608 to send ULLL data or request transmission of ULLL data to the AP. PPDU 608 can be sent to the AP during the UL transmission after SIFS cycle 606 following the transmission of DL-MU PPDU 602.

[0040] Therefore, if the access point (AP) determines at the end of the Short Frame Interval (SIFS) period 606 that it has received PPDU 608 with uplink low latency (ULLL) data or one or more requests to transmit ULLL data, the AP can use a Multi-User Block Acknowledgment Request (MU-BAR) trigger frame 610 to request a block acknowledgment from the receiving site for the downlink multi-user (DL-MU) PPDU 602. The MU-BAR trigger frame 610 may also include ULLL trigger information to request additional ULLL data or request the transmission of ULLL data from one or more sites during a DL transmission opportunity (TXOP), a process similar to... Figure 5 The process is described in [the document]. MU-BAR trigger frame 610 can be sent by the AP after SIFS period 612 following the transmission of PPDU 608. Therefore, if there is additional ULLL data or one or more additional requests to transmit ULLL data from one or more sites, these sites can use Trigger Base (TB) Uplink (UL) PPDU 614 to send additional ULLL data or request the transmission of ULLL data to the AP. TBUL PPDU 614 can be sent by the AP after SIFS period 616 following the transmission of MU-BAR trigger frame 610. Further, regarding TB UL PPDU 614, any additional ULLL data or requests to transmit ULLL data to the AP can be aggregated in the frequency domain with the Trigger Base Acknowledgment / Block Acknowledgment (ACK / BAs) of the receiving site of DL-MU PPDU 602.

[0041] However, as Figure 6b As shown, the AP can determine at the end of SIFS period 606 that it has not received ULLL data or requested to transmit ULLL data. For example, the AP can make this determination when it fails to receive the PHY-RXSTART.indication primitive during the timeout interval aSIFSTime+aSlotTime+aRxPHYStartDelay after the end of DL-MU PPDU 602. In this case, the AP can wait for a Point Coordination Function Frame Interval (PIFS) period 618, which is longer than SIFS period 616, before transmitting MU-BAR trigger frame 620 to request acknowledgments / block acknowledgments (Acks / BAs) from the receiving station for DL-MU PPDU 602. MU-BAR trigger frame 620 may cause the receiving station (e.g., STA1-STAy) to send trigger base acknowledgments / block acknowledgments 622 to the AP after SIFS period 624.

[0042] However, in an alternative scenario, the MU-BAR trigger frame 620 may also include ULLL trigger information to request additional ULLL data from one or more sites or to request the transmission of ULLL data during DLTXOP, a process similar to... Figure 5 The process described in [the document]. In an alternative scenario, the AP may send DL data frames to one or more sites at the end of PIFS period 618. Alternatively, the AP may send DL data frames to one or more sites at the end of PIFS period 618, including a request frame from the receiving site requesting ULLL traffic, which may be similar to [the previous sentence]. Figure 4 The request frame 404 is sent and the function described in the document.

[0043] Figure 7a and 7b A fourth implementation of the proposed scheme is shown. For example... Figure 7a As shown, during an AP-controlled DLTXOP, the AP can request the transmission of ULLL data from one or more sites by including a request frame 704 in the DL-MU PPDU 702. As illustrated, the request frame 704 can be aggregated in the DL-MU PPDU 702 in the frequency domain with one or more Aggregated MAC Protocol Data Units (A-MPDUs) for one or more expected DL data receiving sites (e.g., STA1, STA2, STAy). In this implementation, the signaling field (SIG-B) in the physical layer (PHY) header of the DL-MU PPDU 702 can include a special identifier (STA-ID) (e.g., STA-ID 2048) to indicate the presence of a request frame 704 in a specific resource unit (RU) of the DL-MU PPDU 702. Furthermore, the request frame 704 can allocate a symbol for a null packet (NDP) PPDU for one or more sites so that one or more sites can send one or more requests to transmit ULLL data to the AP. The NDPPPDU has only a PHY header but lacks the Media Access Control (MAC) payload. The request frame can assign a corresponding symbol to each receiving station, where each symbol can be used by the corresponding receiving station to indicate whether the station has a request via tone. For example, a station can use a specific tone in the corresponding symbol to indicate that it has a request to transmit ULLL data to the AP. Furthermore, each A-MPDU in DL-MU PPDU 702 can include a Quality of Service (QoS) data frame with an acknowledgment policy set to block acknowledgment, so that the receiver of the A-MPDU will not immediately transmit an acknowledgment / block acknowledgment after the SIFS period 706 following the received DL-MU PPDU 702.

[0044] Therefore, the receiving station that receives DL-MU PPDU 702 and finds a special identifier in the signaling field can decode request frame 404 to determine the appropriate symbol allocated for use. Subsequently, each station with ULLL data can use the appropriate symbol in NDPPPDU 708 to indicate to the AP that it requests to transmit ULLL data to the AP. NDPPPDU 708 can be transmitted to the AP during UL transmission after SIFS cycle 706 following the transmission of DL-MU PPDU 702.

[0045] Therefore, if the access point (AP) determines at the end of the Short Frame Interval (SIFS) period 706 that the non-data PPDU (NDP) 708 contains at least one request to transmit uplink low latency (ULLL) data, the AP can identify each ULLL requester workstation (STA) via the NDP PPDU 708 and trigger each ULLL requester STA to send ULLL data to the AP via the correspondingly allocated ULLL resource unit (RU) during the downlink transmission opportunity (DL TXOP) using a Multi-User Block Acknowledgment Request (MU-BAR) trigger frame 710. The MU-BAR trigger frame 710 can be sent by the AP after the SIFS period 712 following the transmission of the NDP PPDU 708.

[0046] Upon receiving the MU-BAR trigger frame 710, each ULLL requester STA can send ULLL data or request to transmit ULLL data to the AP using the corresponding ULLL RU in the Trigger Base (TB) Uplink (UL) PPDU 714. The TB ULPPDU 714 can be sent by the AP after the SIFS period 716 following the transmission of the MU-BAR trigger frame 710. As further shown with respect to the TB ULPPDU 714, the AP can further use the MU-BAR trigger frame 710 to request block acknowledgments (BAs) from the receiving STA. Therefore, the ULLL data sent by one or more ULLL requester STAs can be aggregated in the frequency domain with the trigger base acknowledgments / block acknowledgments (ACKs / BAs) of the receiving STA from the MU-BAR trigger frame 710.

[0047] However, as Figure 7bAs shown, the AP can determine at the end of SIFS period 706 that it has not received at least one NDP PPDU 708 requesting the transmission of ULLL data. For example, the AP can make this determination when it fails to receive the PHY-RXSTART.indication primitive within the timeout interval of aSIFSTime+aSlotTime+aRxPHYStartDelay at the end of DL-MU PPDU 702. In this case, the AP can wait for a point frame interval (PIFS) period 718 longer than SIFS period 716 before transmitting MU-BAR trigger frame 720 to request acknowledgments / block acknowledgments (Acks / BAs) for DL-MU PPDU 602. MU-BAR trigger frame 720 may cause the receiving STA (e.g., STA1-STAy) to send trigger base acknowledgments / block acknowledgments 722 to the AP after SIFS period 724.

[0048] However, in an alternative instance, the MU-BAR trigger frame 720 may further include ULLL trigger information to request additional ULLL data from one or more STAs or to request the transmission of ULLL data during the DL TXOP, a process similar to that regarding Figure 5 The process is described. In another alternative instance, the AP may send a DL data frame to one or more STAs at the end of PIFS period 718. In another alternative instance, the AP may send a DL data frame to one or more STAs at the end of PIFS period 718, which includes an ULLL traffic request from the receiving STA, wherein the request frame may be similar to... Figure 4 The request frame 404 is sent and the function described in the document.

[0049] Figure 8a and 8b This demonstrates a fifth implementation of the proposed solution. For example... Figure 8aAs shown, during an AP-controlled DLTXOP, the AP can request ULLL data from one or more STAs or request the transmission of ULLL data by including a request frame 804 in the DL-MU PPDU 802. As illustrated, the request frame 804 can be aggregated in the frequency domain with the aggregated MAC Protocol Data Units (A-MPDUs) of one or more expected DL data receiving STAs (e.g., STA1, STA2, STAy) in the DL-MU PPDU 802. In this implementation, the signaling field (SIG-B) in the physical layer (PHY) header of the DL-MU PPDU 802 can include a special identifier (STA-ID) (e.g., STA-ID 2048) to indicate the presence of a request frame 804 in a specific RU of the DL-MU PPDU 802. Furthermore, the request frame 804 can allocate one or more ULLL RUs for one or more STAs to send ULLL data to the AP or request one or more ULLL data transmissions. The ULLL RU allocated by the request frame 804 can be a randomly accessible ULLL RU. Furthermore, each A-MPDU in DL-MU PPDU 802 may include Quality of Service (QoS) data frames with an acknowledgment policy set to block acknowledgment, so that the receiver of the A-MPDU will not immediately transmit acknowledgments / block acknowledgments after the SIFS period 806 following the received DL-MU PPDU 802. In this implementation, the entire TXOP bandwidth can be allocated to ULLL requests or data transmission. Any ULLL data or requests to transmit ULLL data from any ULLL STA can be sent after the SIFS period following the transmission of DL-MU PPDU 802, without aggregating any acknowledgments / block acknowledgments from the receiving STA of DL-MU PPDU 802.

[0050] Therefore, each STA with ULLL data, upon receiving DL-MU PPDU 802 and discovering the special identifier in the signaling field, can decode request frame 404 to select a randomly accessible ULLL RU to use. Subsequently, each STA with ULLL data can send ULLL data or request to transmit ULLL data to the AP using the corresponding selected ULLL RU in PPDU 808. PPDU 808 can be transmitted to the AP in UL transmission after the SIFS period 808 following the transmission of DL-MU PPDU 802.

[0051] Therefore, if the AP determines at the end of SIFS cycle 806 that it has received a PPDU 808 containing ULLL data or one or more requests to transmit ULLL data, the AP can use MU-BAR trigger frame 810 to request a BA from DL-MUPPDU 802 of the receiving STA. MU-BAR trigger frame 810 may also include ULLL trigger information to request additional ULLL data or request the transmission of ULLL data from one or more STAs during DL TXOP, a process similar to... Figure 5 The process is described in [the diagram]. The MU-BAR trigger frame 810 can be sent by the AP after the SIFS period 812 following the transmission of PPDU 808. Therefore, if there is additional ULLL data or one or more additional requests from one or more STAs to transmit ULLL data, the STA can use TB ULPPDU 814 to transmit the additional ULLL data or one or more requests to the AP. TB UL PPDU 814 can be sent by the AP after the SIFS period 816 following the transmission of MU-BAR trigger frame 810. As shown in TB UL PPDU 814, any additional ULLL data or requests from any STA to transmit ULL data to the AP can be aggregated in the frequency domain with the trigger-based ACK / BA from the receiving STA of DL-MU PPDU 802.

[0052] However, as Figure 8b As shown, the AP can determine at the end of SIFS period 806 that it has not received ULLL data or requested to transmit ULLL data through the assigned randomly accessible ULLL RU. For example, the AP can make this determination when it fails to receive the PHY-RXSTART.indication primitive within the timeout interval of aSIFSTime+aSlotTime+aRxPHYStartDelay at the end of DL-MU PPDU 802. In this case, the AP can wait for a longer period than SIFS period 818 before transmitting MU-BAR trigger frame 820 to request an acknowledgment / BA from the receiving STA for DL-MU PPDU 802. MU-BAR trigger frame 820 may cause the receiving STA to send a trigger-based acknowledgment / BA to the AP after SIFS period 824.

[0053] However, in an alternative instance, the MU-BAR trigger frame 820 may also include ULLL trigger information to request additional ULLL data from one or more STAs or to request the transmission of ULLL data during DLTXOP, a process similar to... Figure 5The process described in [the document]. In another alternative instance, the AP may send a DL data frame to one or more STAs at the end of PIFS period 818. In another alternative instance, the AP may send a DL data frame to one or more STAs at the end of PIFS period 818, which includes an ULLL traffic request from the receiving STA, wherein the request frame may be sent and similar to [the process described in the document]. Figure 4 The request frame described in the document is 404.

[0054] Therefore, the request frame implemented according to the proposed scheme can be one of the following types: (a) a trigger frame with a new trigger type subfield that identifies a ULLL trigger for ULLL data or a request to transmit ULLL data; (b) a trigger frame that includes one or more user information fields that identify a series of related STAs for polling ULLL data or a request to transmit ULLL data. Regarding (b), the trigger frame type can be one of the following trigger variants: (1) a basic trigger frame, (2) a MU-BAR trigger frame, (3) a basic trigger frame with one or more randomly accessible RUs assigned, and (4) an NDP Feedback Report Polling (NFRP) trigger frame.

[0055] In addition, the request frame may indicate one or more ULLL RU allocations in the user information field. One or more ULLL allocations may correspond to a specific STA-AID of the associated STA or a series of associated STAs that will be polled for buffered ULLL data and / or request to transmit ULLL data. For example, the request frame may indicate that the ULLL RU access type is one of the following: (1) dedicated RU or (2) randomly selected RU. The request frame may also indicate one of the following subfields in the user information field or trigger-dependent user information field: (1) the starting STA-AID of the STA-AID range; (2) the starting ULLL RU allocation; (3) the number of ULLL RUs allocated; and (4) the number of STAs to be polled. In some implementations, the request frame may be a broadcast addressing trigger frame.

[0056] Example Implementation

[0057] Figure 9 An example system 900 is shown, having at least one example device 910 and one example device 920, according to an implementation of this disclosure. Devices 910 and 920 can perform various functions to implement the schemes, techniques, processes, and methods described herein for reducing UL transmission latency in communication between Wi-Fi STAs using request frames, including the various schemes, designs, concepts, systems, and methods described above, as well as the processes described below. For example, device 910 can be implemented in a STA (e.g., STA 102, 104, 106), and device 920 can be implemented in an AP, such as AP 108.

[0058] Each device 910 and device 920 can be part of an electronic device, such as a portable or mobile device, wearable device, wireless communication device, or computing device. When implemented in a workstation (STA), each device 910 and device 920 can be implemented in a smartphone, smartwatch, personal digital assistant, digital camera, or computing device such as a tablet, laptop, or notebook computer. Each device 910 and device 920 can also be part of a machine-type device, which may be an Internet of Things (IoT) device, such as a fixed or stationary device, home appliance, wired communication device, or computing device. For example, each device 910 and device 920 can be implemented in a smart thermostat, smart refrigerator, smart door lock, wireless speaker, or home control center. When implemented in or as a network device, device 910 and / or device 920 can be implemented in a network node, such as an access point (AP) or mesh device in a wireless local area network (WLAN).

[0059] In some implementations, each device 910 and device 920 may be implemented as one or more integrated circuit (IC) chips, such as, but not limited to, one or more single-core processors, one or more multi-core processors, one or more Reduced Instruction Set Computing (RISC) processors, or one or more Complex Instruction Set Computing (CISC) processors. In all the above-described embodiments, each device 910 and device 920 may be implemented in or as a workstation (STA) or access point (AP). Each device 910 and device 920 may include... Figure 9 At least some of the components shown are, for example, processors 912 and 922. Each device 910 and device 920 may also include one or more other components unrelated to the proposed solutions of this disclosure (e.g., internal power supply, display device, and / or user interface device), therefore, for simplicity and brevity, these components are not listed. Figure 9 This is shown in the text and not described in the following text.

[0060] In one aspect, each processor 912 and processor 922 may be implemented as one or more single-core processors, one or more multi-core processors, one or more RISC processors, or one or more CISC processors. That is, although the singular term "processor" is used herein to refer to processor 912 and processor 922, in some implementations of this disclosure, each processor 912 and processor 922 may include multiple processors, while in other implementations it is a single processor. In another aspect, each processor 912 and processor 922 may be implemented in hardware (and optionally firmware) comprising, for example, but not limited to, one or more transistors, one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors, and / or one or more varactor diodes, these components being configured and arranged to achieve a specific purpose according to this disclosure. In other words, in at least some implementations, each processor 912 and processor 922 is a dedicated machine specifically designed, arranged, and configured to perform specific tasks, including those related to using request frames to reduce uplink transmission latency in communication between Wi-Fi workstations.

[0061] In some implementations, device 910 may further include a transceiver 916 coupled to processor 912. Transceiver 916 may include a transmitter capable of wireless transmission and a receiver capable of wirelessly receiving data. In some implementations, device 920 may further include a transceiver 926 coupled to processor 922. Transceiver 926 may include a transmitter capable of wireless transmission and a receiver capable of wirelessly receiving data. It is worth noting that although transceivers 916 and 926 are shown as external components independent of processors 912 and 922, respectively, in some implementations, transceiver 916 may be an integral part of processor 912 as a system-on-a-chip (SoC), and / or transceiver 926 may be an integral part of processor 922 as a SoC.

[0062] In some implementations, device 910 may further include a memory 914 coupled to processor 912 and capable of being accessed and storing data by processor 912. In some implementations, device 920 may further include a memory 924 coupled to processor 922 and capable of being accessed and storing data by processor 922. Each memory 914 and memory 924 may include a random access memory (RAM), such as dynamic RAM (DRAM), static RAM (SRAM), thyristor RAM (T-RAM), and / or zero-capacitance RAM (Z-RAM). Alternatively, each memory 914 and memory 924 may include a read-only memory (ROM), such as a mask ROM, programmable ROM (PROM), erasable programmable ROM (EPROM), and / or electrically erasable programmable ROM (EEPROM). Alternatively, each memory 914 and memory 924 may include a non-volatile random access memory (NVRAM), such as flash memory, solid-state memory, ferroelectric RAM (FeRAM), magnetoresistive RAM (MRAM), and / or phase-change memory.

[0063] Each device 910 and device 920 can be a communication entity capable of communicating with each other using various proposed schemes of this disclosure. For illustrative purposes and without limitation, the following descriptions of the capabilities of device 910 or device 920 as a workstation (e.g., workstations 102, 104, 106) or an access point (e.g., access point 108) are provided in the context of example processes 1000 and 1100, respectively. It is worth noting that although a detailed description of the capabilities, functions, and / or technical features of either device 910 or device 920 is provided below, the same description can also be applied to the other device 910 or device 920, although a detailed description is not provided for the sake of brevity. It is also worth noting that although the example implementations described below are provided in the context of WLAN, the same implementations can be implemented in other types of networks.

[0064] Example process

[0065] Figure 10 An example process 1000 according to an implementation of this disclosure is shown. Process 1000 may represent one aspect of implementing the various proposed designs, concepts, schemes, systems, and methods described above. More specifically, process 1000 may represent one aspect of proposed concepts and schemes related to using request frames to reduce uplink transmission latency in communication between Wi-Fi workstations. Process 1000 may include one or more operations, actions, or functions, as shown in blocks 1010 and 1020. Although shown as discrete blocks, the individual blocks of process 1000 may be divided into more blocks, merged into fewer blocks, or eliminated, depending on the desired implementation. Furthermore, the blocks / sub-blocks of process 1000 may be arranged according to... Figure 10The process can be executed in the order shown, or in a different order. Furthermore, one or more blocks / sub-blocks of process 1000 can be executed repeatedly or iteratively. Process 1000 can be implemented by devices 910 and 920, and any variations thereof. For illustrative purposes only and without limitation, process 1000 is described below in the context of device 910 being implemented as or as a workstation (e.g., workstation 102) and device 920 being implemented as or as an access point in a wireless network (e.g., a WLAN in network environment 100) and conforming to one or more IEEE 802.11 standards. Process 1000 may begin with block 1010.

[0066] At 1010, process 1000 may include the processor 922 of device 920, acting as an access point, sending a request message in a downlink (DL) Physical Protocol Data Unit (PPDU) during a transmission opportunity (TXOP) to instruct one or more workstations associated with the device to send uplink low latency (ULLL) data, or one or more requests to transmit ULLL data to device 920. Process 1000 may proceed from 1010 to 1020.

[0067] In 1020, process 1000 may include processor 922 receiving ULLL data or at least one request from one or more workstations to transmit ULLL data in response to the request.

[0068] In some implementations, the request information in the DL PPDU can be aggregated in the frequency domain with one or more Media Access Control (MAC) Protocol Data Units (MPDUs) or Aggregated MAC Protocol Data Units (A-MPDUs) for use with one or more DL data receiving workstations associated with device 920. In such an implementation, each A-MPDU can trigger the corresponding DL data receiving workstation to provide a corresponding trigger-based acknowledgment DLPPDU in a subsequent trigger-based uplink (TB UL) PPDU.

[0069] In some implementations, the request information in the DL PPDU can be located in the physical layer (PHY) header of the DL PPDU.

[0070] In some implementations, the request information may allocate one or more resource units (RUs) for one or more workstations to transmit ULLL data or one or more requests to the device, and receiving includes receiving ULLL data or at least one request for transmitting ULLL data in one or more RUs. In some implementations, ULLL data or at least one request is transmitted from at least one of the one or more workstations in a triggered uplink (TB UL) PPDU or a non-data PPDU (NDP) that follows a transmitted DL PPDU.

[0071] In some implementations, one or more RUs can be dedicated RUs assigned to a corresponding workstation, or randomly accessible RUs that can be selected by any of the one or more workstations.

[0072] In some implementations, the RU allocation for request information may correspond to a specific or reserved worksite-associated identifier (STA-AID) to indicate that the RU allocation is specific to ULLL data or one or more requests for transmitting ULLL data. In some implementations, the RU allocation for request information may correspond to a specific STA-AID of an associated worksite or a range of STA-AIDs for multiple associated worksites, or any associated worksite polled by the device to obtain ULLL data or one or more requests for transmitting ULLL data.

[0073] In some implementations, the request information may indicate the starting STA-AID, starting RU allocation, number of allocated RUs, range of allocated RUs, and range of STA-AIDs to be polled for ULLL data, or one or more requests to transfer ULLL data, for at least one or more related workstations.

[0074] In some implementations, the request information may be contained in a trigger frame that includes ULLL trigger information to obtain ULLL data or to request the transmission of ULLL data, or a trigger frame that identifies a series of related workstations to poll for ULLL data or to request the transmission of ULLL data.

[0075] In some implementations, the trigger frame can be a basic trigger frame, a BAR trigger frame, a MU-BAR trigger frame, a basic trigger frame with one or more randomly accessible RU assignments, or an NDP Feedback Report Polling (NFRP) trigger frame. In such implementations, a BAR trigger frame or a MU-BAR trigger frame can trigger ULLL data in one or more trigger-based acknowledgments integrated with data received from a DL PPDU in the frequency domain, or at least request the transmission of ULLL data. In other implementations, an NFRP trigger frame can trigger / polle a request to transmit ULLL data in a TB NDP PPDU.

[0076] Figure 11 An example process 1100 according to an implementation of this disclosure is shown. Process 1100 may represent an aspect of the designs, concepts, schemes, systems, and methods proposed above. More specifically, process 1100 may represent an aspect of proposed concepts and schemes related to reducing uplink transmission latency in communication between Wi-Fi workstations using request frames. Process 1100 may include one or more operations, actions, or functions represented by one or more blocks 1110 and 1120. Although shown as discrete blocks, the individual blocks of process 1100 may be divided into more blocks, merged into fewer blocks, or eliminated, depending on the desired implementation. Furthermore, the blocks / sub-blocks of process 1100 may be arranged according to... Figure 11 The execution may be performed in the order shown, or in a different order. Furthermore, one or more blocks / sub-blocks of process 1100 may be executed repeatedly or iteratively. Process 1100 may be implemented by or in devices 910 and 920, and any variations thereof. For illustrative purposes only and without limitation, process 1100 is described below in the context of device 910, which is implemented in network environment 100 as or as a workstation (e.g., STA 102) according to one or more IEEE 802.11 standards, while device 920 is implemented as or as an access point (AP) for a wireless network such as a WLAN. Process 1100 may begin at block 1110.

[0077] At 1110, process 1100 may include, during TXOP, device 920, acting as processor 922 of the AP, sending a request message in a DL PPDU instructing permission for one or more STAs associated with the device to send ULLL data or one or more requests to transfer ULLL data to the AP. Process 1100 may proceed from 1110 to 1120.

[0078] At 1120, process 1100 may include processor 922 sending a trigger frame from AP to request the transmission of additional ULLL data from one or more STAs or to request the transmission of ULLL data during TXOP in response to receiving ULLL data transmitted from at least one of one or more STAs or requesting the transmission of ULLL data after a period of time following DL PPDU transmission.

[0079] In some implementations, the request information may assign one or more RUs to one or more STAs to send ULLL data or one or more requests to transmit ULLL data to the AP, and receiving subsequent UL transmissions includes receiving ULLL data or at least one request from at least one STA among the one or more RUs. In some implementations, the ULLL data or at least one request may be transmitted from at least one STA among the one or more STAs in a TB UL PPDU or an NDP PPDU after the DL PPDU is sent. In some embodiments, each of the one or more RUs may be a dedicated RU assigned to a corresponding STA, or a randomly accessible RU that can be selected by any STA among the one or more STAs.

[0080] In some implementations, where the trigger frame is a MU-BAR trigger frame, process 1100 may additionally include operations performed by processor 922, including receiving additional ULLL data or requesting the transmission of ULLL data from one or more STAs in a TB PPDU after the MU-BAR trigger frame is sent.

[0081] In some implementations, this time period can be the SIFS period, and the request frame in the DL PPDU can be aggregated in the frequency domain with one or more MAC protocol data A-MPDUs for one or more DL data receiving STAs associated with the AP. Each A-MPDU can be configured with a corresponding DL data receiving STA to avoid providing a trigger-based DL PPDU acknowledgment immediately after the SIFS period ends. In such an implementation, the TB PPDU can further include a trigger-based acknowledgment of the DL PPDU by the corresponding DL data receiving STA.

[0082] In some implementations, where the time period is the SIFS period, process 1100 may additionally include operations performed by processor 922, including sending an additional frame from the AP at the end of the PIFS period following the DLPPDU transmission if no subsequent UL transmission is received after the SIFS period ends. The PIFS period is longer than the SIFS period. In such an implementation, the TB PPDU may further include a trigger-based acknowledgment of the DL PPDU by the corresponding DL data receiving STA.

[0083] The topics described herein sometimes demonstrate different components contained within or connected to different other components. It should be understood that the architectures depicted are merely examples, and many other architectures can actually be implemented to achieve the same functionality. Conceptually, any arrangement of components to achieve the same function is effectively “associated” together to achieve the desired functionality. Therefore, any two components combined in this document to achieve a particular function can be considered “interrelated” to achieve the desired functionality, regardless of the architecture or intermediate components. Similarly, any two components so associated can also be considered “operably connected” or “operably coupled” together to achieve the desired functionality, and any two components that can be so associated can also be considered “operably coupled” together to achieve the desired functionality. Specific examples of being operablely coupled include, but are not limited to, physically matable and / or physically interacting components and / or wirelessly interactive and / or logically interacting and / or logically interactive components.

[0084] Furthermore, regarding the use of virtually any plural and / or singular terms in this document, anyone with the technical skill can appropriately translate from plural to singular and / or from singular to plural depending on the context and / or application. For clarity, various singular / plural permutations may be explicitly listed in this document.

[0085] Furthermore, those skilled in the art will understand that, generally, the terms used herein, especially in appended claims, such as the body of an appended claim, are generally interpreted as “open” terms; for example, the word “comprising” should be interpreted as “comprising but not limited to,” the word “having” should be interpreted as “having at least,” and the word “including” should be interpreted as “including but not limited to,” etc. Those skilled in the art will also understand that if a specific number of claim statements is intentional, such intention will be explicitly stated in the claims, and without such a statement, such intention does not exist. For example, to aid understanding, the following appended claims may contain the use of introductory phrases “at least one” and “one or more” to introduce claim statements. However, the use of these phrases should not be construed as implying that the introduction of claim statements by the indefinite article “a” or “an” restricts any particular claim containing such an introductory claim statement to containing only one such statement, even if the same claim includes the introductory phrase “one or more” or “at least one” and indefinite articles such as “a” or “an,” for example, “a” and / or “an” should be interpreted as “at least one” or “one or more”; the same applies to definite articles used to introduce claim statements. Furthermore, even if the specific number of claims is explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as at least the number of claims. For example, the simple statement "two claims," ​​without any other modifiers, means at least two claims, or two or more claims. Additionally, in cases where conventions such as "at least one A, B, and C, etc." are used, this structure is generally interpreted in a way that is understood by those skilled in the art. For example, "a system having at least one A, B, and C" will include, but is not limited to, systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. Similarly, in cases where conventions such as "at least one A, B, or C, etc." are used, this structure is generally interpreted in a way that is understood by those skilled in the art. For example, "a system having at least one A, B, or C" will include, but is not limited to, systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. Those skilled in the art will also understand that virtually any extractive word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to include the possibility of including one, any, or both terms. For example, the phrase "A or B" will be understood to include the possibility of including "A" or "B" or "A and B".

[0086] As can be understood from the foregoing, various implementations of this disclosure have been described herein for illustrative purposes, and various modifications may be made without departing from the scope and spirit of this disclosure. Therefore, the various implementations disclosed herein are not intended to be limiting, and the true scope and spirit are indicated by the following claims.

Claims

1. An apparatus for reducing latency in uplink transmission, comprising: A transceiver; as well as A processor coupled to the transceiver and configured to perform operations includes: During a transmission opportunity (TXOP), a request message is sent in a downlink (DL) physical protocol data unit (PPDU) indicating permission for one or more sites associated with the device to send uplink low latency (ULLL) data or one or more requests to transmit ULLL data to the device. as well as The ULLL data is received from at least one workstation (STA) of one or more sites, or at least one request is made in response to the request to transmit the ULLL data.

2. The apparatus of claim 1, wherein the request information is aggregated in the DL PPDU with one or more Media Access Control (MAC) Protocol Data Units (MPDUs) or Aggregated MAC Protocol Data Units (A-MPDUs) for use with one or more DL data receiving stations associated with the apparatus.

3. The apparatus of claim 1, wherein the request information is located in the physical layer (PHY) header of the DL PPDU.

4. The apparatus of claim 1, wherein the request information allocates one or more resource units (RUs) for one or more sites to transmit the ULLL data or one or more requests to the apparatus, and wherein the receiving includes receiving the ULLL data or at least one request in the one or more RUs to transmit the ULLL data.

5. The apparatus of claim 4, wherein the ULLL data or at least one request is transmitted from at least one STA of the one or more sites in a trigger-based (TB) uplink (UL) PPDU or a non-data PPDU (NDP), the NDP following the transmitted DL PPDU.

6. The apparatus of claim 4, wherein each of the one or more RUs is a dedicated RU assigned to a corresponding STA, or a randomly accessible RU that can be selected by any STA of the one or more sites.

7. The apparatus of claim 4, wherein the RU allocation of the request information corresponds to a special or reserved workstation-associated identifier (STA-AID) to indicate that the RU allocation is specific to the ULLL data or one or more requests for transmitting the ULLL data.

8. The apparatus of claim 4, wherein the RU allocation of the request information corresponds to a specific STA-AID of a related STA or a range of STA-AIDs of multiple related STAs, or any related STA is polled by the apparatus to obtain the ULLL data or one or more requests to transmit the ULLL data.

9. The apparatus of claim 4, wherein the request information indicates the starting STA-AID, starting RU allocation, number of allocated RUs, range of allocated RUs, and range of STA AIDs to be polled for at least one plurality of associated STAs to obtain the ULLL data or one or more requests to transmit the ULLL data.

10. The apparatus of claim 1, wherein the request information is contained in a control frame, the control frame including ULLL trigger information to obtain ULLL data or request to transmit ULLL data, or a control frame that identifies a series of related STAs to poll for ULLL data or request to transmit ULLL data.

11. The apparatus of claim 10, wherein the control frame is a basic trigger frame, a block acknowledgment request (BAR) frame, a multi-user block acknowledgment request (MU-BAR) frame, a basic trigger frame having one or more randomly accessible RU allocations, or a null packet (NDP) feedback report polling (NFRP) frame.

12. The apparatus of claim 10, wherein the control frame triggers ULLL data or at least one request to transmit ULLL in the TBUL PPDU, the PPDU being integrated in the frequency domain with one or more acknowledgments of the data received from the DL PPDU.

13. A method for reducing uplink transmission latency, comprising: A request message is sent from an access point (AP) during a transmission opportunity (TXOP) in a downlink (DL) physical protocol data unit (PPDU) to instruct one or more stations (STAs) associated with the device to send uplink low latency (ULLL) data or one or more requests to transmit ULLL data to the AP. as well as Receive the uplink low latency (ULLL) data or at least one request from one or more workstations (STAs) in response to the request information transmission of ULLL data.

14. A method for reducing uplink transmission latency, comprising: During a Transmission Opportunity (TXOP), a request message in a Downlink (DL) Physical Protocol Data Unit (PPDU) is sent from the Access Point (AP) to instruct one or more Stations (STAs) associated with the device to send Uplink Low Latency (ULLL) data or one or more requests to transmit ULLL data to the AP. and After the AP receives a subsequent UL transmission including the ULLL data or the at least one request to transmit the ULLL data from at least one of the one or more workstations (STAs), it sends a trigger frame from the AP requesting the transmission of additional ULLL data from the one or more STAs during the TXOP or requesting the transmission of ULLL data.

15. The method of claim 14, wherein the request information allocates one or more resource units (RUs) to the one or more STAs to send the ULLL data or the one or more requests to transmit the ULLL data to the AP, and wherein the receiving includes receiving the ULLL data or the at least one request to transmit the ULLL data from at least one of the one or more STAs in the one or more RUs.

16. The device of claim 15, wherein the ULLL data or the at least one request to transmit ULLL data from at least one of the one or more STAs is transmitted in a Trigger Base (TB) Uplink (UL) PPDU or Non-Data PPDU (NDP) after the transmission of the DL PPDU.

17. The method of claim 15, wherein each of the one or more RUs is a dedicated RU assigned to a corresponding STA, or a randomly accessible RU that can be selected by any STA of the one or more STAs.

18. The method of claim 14, wherein the trigger frame is a basic trigger frame or a multi-user block acknowledgment request (MU-BAR) trigger frame, and wherein the method further comprises receiving the additional ULLL data or request in a trigger base (TB) PPDU after the transmission of the trigger frame to transmit ULLL data from the one or more STAs.

19. The method of claim 18, wherein the time period is a Short Frame Interval (SIFS) period, and the request frame in the DLPPDU is aggregated in the frequency domain with one or more MAC Protocol Data Units (MPDUs) for one or more DL data receiving STAs associated with the AP, wherein each MPDU is configured with a corresponding DL data receiving STA to avoid providing a corresponding DL PPDU acknowledgment immediately after the end of the SIFS period, and wherein the TB PPDU further includes a trigger-based acknowledgment of the DL PPDU by the corresponding DL data receiving STA.

20. The method of claim 14, wherein the time period is a Short Frame Interval (SIFS) period, further comprising, if the subsequent UL transmission is not received at the end of the SIFS period, sending an additional frame from the AP at the end of the Point Coordination Function Frame Interval (PIFS) period, which begins after the transmission of the DL PPDU, wherein the duration of the PIFS period is longer than that of the SIFS period, and wherein the additional frame is a MU-BAR trigger frame, a request for transmission of the ULLL data from the one or more STAs or the at least one requested MU-BAR frame, a DL data frame, or a request for transmission of the ULLL data from the one or more STAs or the at least one requested DL data frame.

Images