WO2021231121A1 - Rta packet duplication in time and frequency - Google Patents
Rta packet duplication in time and frequency Download PDFInfo
- Publication number
- WO2021231121A1 WO2021231121A1 PCT/US2021/030475 US2021030475W WO2021231121A1 WO 2021231121 A1 WO2021231121 A1 WO 2021231121A1 US 2021030475 W US2021030475 W US 2021030475W WO 2021231121 A1 WO2021231121 A1 WO 2021231121A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- rta
- packet
- packets
- unsolicited
- link
- Prior art date
Links
- 230000005540 biological transmission Effects 0.000 claims abstract description 142
- 238000004891 communication Methods 0.000 claims description 73
- 238000000034 method Methods 0.000 claims description 42
- 101100172132 Mus musculus Eif3a gene Proteins 0.000 claims description 29
- 230000006978 adaptation Effects 0.000 claims description 13
- 230000001934 delay Effects 0.000 claims description 7
- 108700026140 MAC combination Proteins 0.000 claims description 5
- 101150081243 STA1 gene Proteins 0.000 description 59
- 101100161473 Arabidopsis thaliana ABCB25 gene Proteins 0.000 description 58
- 101100096893 Mus musculus Sult2a1 gene Proteins 0.000 description 58
- 101100395869 Escherichia coli sta3 gene Proteins 0.000 description 50
- 101000752249 Homo sapiens Rho guanine nucleotide exchange factor 3 Proteins 0.000 description 38
- 102100021689 Rho guanine nucleotide exchange factor 3 Human genes 0.000 description 38
- 238000010586 diagram Methods 0.000 description 38
- 230000004044 response Effects 0.000 description 22
- 238000012545 processing Methods 0.000 description 15
- 238000005516 engineering process Methods 0.000 description 14
- OVGWMUWIRHGGJP-WVDJAODQSA-N (z)-7-[(1s,3r,4r,5s)-3-[(e,3r)-3-hydroxyoct-1-enyl]-6-thiabicyclo[3.1.1]heptan-4-yl]hept-5-enoic acid Chemical compound OC(=O)CCC\C=C/C[C@@H]1[C@@H](/C=C/[C@H](O)CCCCC)C[C@@H]2S[C@H]1C2 OVGWMUWIRHGGJP-WVDJAODQSA-N 0.000 description 13
- 101000988961 Escherichia coli Heat-stable enterotoxin A2 Proteins 0.000 description 13
- 230000008569 process Effects 0.000 description 13
- 230000006870 function Effects 0.000 description 12
- 230000007246 mechanism Effects 0.000 description 11
- 238000004590 computer program Methods 0.000 description 8
- 230000009471 action Effects 0.000 description 6
- 230000008859 change Effects 0.000 description 5
- 238000007726 management method Methods 0.000 description 5
- YJLUBHOZZTYQIP-UHFFFAOYSA-N 2-[5-[2-(2,3-dihydro-1H-inden-2-ylamino)pyrimidin-5-yl]-1,3,4-oxadiazol-2-yl]-1-(2,4,6,7-tetrahydrotriazolo[4,5-c]pyridin-5-yl)ethanone Chemical compound C1C(CC2=CC=CC=C12)NC1=NC=C(C=N1)C1=NN=C(O1)CC(=O)N1CC2=C(CC1)NN=N2 YJLUBHOZZTYQIP-UHFFFAOYSA-N 0.000 description 3
- 108091027981 Response element Proteins 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 238000009826 distribution Methods 0.000 description 3
- KZEVSDGEBAJOTK-UHFFFAOYSA-N 1-(2,4,6,7-tetrahydrotriazolo[4,5-c]pyridin-5-yl)-2-[5-[2-[[3-(trifluoromethoxy)phenyl]methylamino]pyrimidin-5-yl]-1,3,4-oxadiazol-2-yl]ethanone Chemical compound N1N=NC=2CN(CCC=21)C(CC=1OC(=NN=1)C=1C=NC(=NC=1)NCC1=CC(=CC=C1)OC(F)(F)F)=O KZEVSDGEBAJOTK-UHFFFAOYSA-N 0.000 description 2
- 230000002776 aggregation Effects 0.000 description 2
- 238000004220 aggregation Methods 0.000 description 2
- 230000002457 bidirectional effect Effects 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 238000003722 High energy mechanical milling Methods 0.000 description 1
- 208000016709 aortopulmonary window Diseases 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- VYLDEYYOISNGST-UHFFFAOYSA-N bissulfosuccinimidyl suberate Chemical compound O=C1C(S(=O)(=O)O)CC(=O)N1OC(=O)CCCCCCC(=O)ON1C(=O)C(S(O)(=O)=O)CC1=O VYLDEYYOISNGST-UHFFFAOYSA-N 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 239000000725 suspension Substances 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W74/00—Wireless channel access
- H04W74/08—Non-scheduled access, e.g. ALOHA
- H04W74/0808—Non-scheduled access, e.g. ALOHA using carrier sensing, e.g. carrier sense multiple access [CSMA]
- H04W74/0816—Non-scheduled access, e.g. ALOHA using carrier sensing, e.g. carrier sense multiple access [CSMA] with collision avoidance
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/08—Arrangements for detecting or preventing errors in the information received by repeating transmission, e.g. Verdan system
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1685—Details of the supervisory signal the supervisory signal being transmitted in response to a specific request, e.g. to a polling signal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/1874—Buffer management
- H04L1/1877—Buffer management for semi-reliable protocols, e.g. for less sensitive applications like streaming video
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/1887—Scheduling and prioritising arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/1893—Physical mapping arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/50—Allocation or scheduling criteria for wireless resources
- H04W72/56—Allocation or scheduling criteria for wireless resources based on priority criteria
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
- H04L1/0002—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission rate
- H04L1/0003—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission rate by switching between different modulation schemes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
- H04L1/0009—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the channel coding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1864—ARQ related signaling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/50—Allocation or scheduling criteria for wireless resources
- H04W72/56—Allocation or scheduling criteria for wireless resources based on priority criteria
- H04W72/566—Allocation or scheduling criteria for wireless resources based on priority criteria of the information or information source or recipient
- H04W72/569—Allocation or scheduling criteria for wireless resources based on priority criteria of the information or information source or recipient of the traffic information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
- H04W84/10—Small scale networks; Flat hierarchical networks
- H04W84/12—WLAN [Wireless Local Area Networks]
Definitions
- the technology of this disclosure pertains generally to wireless communication networks (WLANS) using CSMA/CA, and more particularly to WLANS using CSMA/CA which duplicate Real Time Application (RTA) packets with respect to time and/or frequency domains, and transmit these packets during the same TXOP period.
- WLANS wireless communication networks
- CSMA/CA which duplicate Real Time Application (RTA) packets with respect to time and/or frequency domains, and transmit these packets during the same TXOP period.
- RTA Real Time Application
- RTA real time applications
- An RTA requires low latency communication and uses best effort communications in present wireless networks.
- RTA packets require low latency due to their high timeliness requirement on packet delivery.
- An RTA packet is only valid when it is delivered within a certain period of time.
- the present disclosure operates in a CSMA/CA WLAN and distinguishes Real-Time Application (RTA) traffic from non-RTA traffic and handles the RTA traffic in a manner which takes the timeliness of the packet into consideration, since RTA packets have to be transmitted within a limited lifetime or otherwise they are invalid.
- RTA Real-Time Application
- STAs stations
- the present disclosure separates the retransmission scheme for RTA packets from non-RTA packets, while non-RTA packets can still use the regular retransmission scheme defined in CSMA/CA.
- the proposed technology defines an unsolicited retry scheme for RTA traffic to transmit and retransmit the RTA packets in the same period of Transmit Opportunity (TXOP).
- TXOP Transmit Opportunity
- the present disclosure allows the STA to obtain the TXOP on multiple link devices (MLDs) to transmit the initial transmission of the RTA packets on one link and retransmit their retransmissions on the other link(s).
- MLDs multiple link devices
- the present disclosure is compatible with Orthogonal Frequency Division Multiple Access (OFDMA) systems.
- OFDMA Orthogonal Frequency Division Multiple Access
- the present disclosure allows the STA to use one Resource Unit (RU) to transmit the initial transmission of an RTA packet and another RU to transmit its retransmissions in the same Multi-User (MU) PPDU packet.
- a PPDU is a Physical Layer Conformance Procedure (PLCP) Protocol Data Unit (PPDU).
- the present disclosure allows the STA to set up a Block Acknowledgement (BA) agreement for RTA packets to obtain packet loss information on multiple links to adapt future packet transmissions.
- BA Block Acknowledgement
- the packet transmissions may also be adapted for example by using a Modulation Coding Scheme (MCS), unsolicited retry limit, or other adaptions, without departing from the teachings of the present disclosure.
- MCS Modulation Coding Scheme
- FIG. 1 is a data field diagram of a Traffic Specification (TSPEC) defined in IEEE 802.11.
- TSPEC Traffic Specification
- FIG. 2 is a data field diagram of a Traffic Stream (TS) Information field defined in IEEE 802.11.
- TS Traffic Stream
- FIG. 3 is a data field diagram of a Traffic Classification (TCLAS) Information field defined in IEEE 802.11.
- TCLAS Traffic Classification
- FIG. 4 is a data field diagram of a Traffic Classification (TCLAS) Process element field defined in IEEE 802.11.
- TCLAS Traffic Classification
- FIG. 5 is a hardware block diagram of wireless station hardware according to at least one embodiment of the present disclosure.
- FIG. 6 is a network topology diagram shown by way of example and not limitation with Basic Service Sets (BSS) scenario, one of which is configured for Multi-link Devices (MLDs), according to at least one embodiment of the present disclosure.
- BSS Basic Service Sets
- MLDs Multi-link Devices
- FIG. 7 is a communication sequence diagram of Low latency
- FIG. 8 is a data field diagram of a Low latency Transmission Service
- FIG. 9 is a data field diagram of a Low latency Transmission Service (LLTS) descriptor frame according to at least one embodiment of the present disclosure.
- LLTS Low latency Transmission Service
- FIG. 10 is a data field diagram of an RTA-TSPEC field according to at least one embodiment of the present disclosure.
- FIG. 11 is a data field diagram of an optional subelement field according to at least one embodiment of the present disclosure.
- FIG. 12 is a data field diagram of a Low latency Transmission
- LLTS Link Service Response frame
- FIG. 13 is a data field diagram of a Low latency Transmission
- LLTS Service Service
- FIG. 14 is a flow diagram for a STA deciding whether to apply the unsolicited retry policy to an RTA packet according to at least one embodiment of the present disclosure.
- FIG. 15 is a flow diagram for a STA transmitting RTA packets with unsolicited retry is performed having packet duplication with respect to time according to at least one embodiment of the present disclosure.
- FIG. 16 is a flow diagram for a Multi-Link Device (MLD) obtaining a
- TXOP Transmit Opportunity
- FIG. 17A and FIG. 17B is a flow diagram for an STR AP MLD obtaining a TXOP in a multi-link scenario to transmit to a non-STR non-AP
- MLD according to at least one embodiment of the present disclosure.
- FIG. 18 is a flow diagram for transmitting an RTA packet when unsolicited retry on multiple Resource Units (RUs) is allowed according to at least one embodiment of the present disclosure.
- FIG. 19 is a flow diagram for a STA dropping an RTA packet when unsolicited retry is allowed according to at least one embodiment of the present disclosure.
- FIG. 20 is a communication sequence diagram as Example 1 of a STA transmitting an RTA packet with unsolicited retry on a single link according to at least one embodiment of the present disclosure.
- FIG. 21 is a communication sequence diagram as Example 2 of a STA transmitting an RTA packet with unsolicited retry on a single link according to at least one embodiment of the present disclosure.
- FIG. 22 is a communication sequence diagram as Example 2-1 of a STA transmitting an RTA packet with unsolicited retry on a single link according to at least one embodiment of the present disclosure.
- FIG. 23 is a communication sequence diagram as Example 3 of a STA transmitting an RTA packet with unsolicited retry on a single link according to at least one embodiment of the present disclosure.
- FIG. 24 is a communication sequence diagram as Example 4 of a
- FIG. 25 is a communication sequence diagram as Example 5 of a STA transmitting an RTA packet with unsolicited retry on a single link according to at least one embodiment of the present disclosure.
- FIG. 26 is a communication sequence diagram as Example 6 of a STA transmitting an RTA packet with unsolicited retry on a single link according to at least one embodiment of the present disclosure.
- FIG. 27 is a communication sequence diagram as Example 6-1 of a STA transmitting an RTA packet with unsolicited retry on a single link according to at least one embodiment of the present disclosure.
- FIG. 28 is a communication sequence diagram as Example 6-1-1 of a STA transmitting an RTA packet with unsolicited retry on a single link according to at least one embodiment of the present disclosure.
- FIG. 29 is a communication sequence diagram as Example 6-2 of a STA transmitting an RTA packet with unsolicited retry on a single link according to at least one embodiment of the present disclosure.
- FIG. 30 is a communication sequence diagram as Example 6-3 of a STA transmitting an RTA packet with unsolicited retry on a single link according to at least one embodiment of the present disclosure.
- FIG. 31 is a communication sequence diagram as Example 7 of a STA transmitting an RTA packet with unsolicited retry on a single link according to at least one embodiment of the present disclosure.
- FIG. 32 is a communication sequence diagram as Example 8 of a STA transmitting an RTA packet with unsolicited retry on a single link according to at least one embodiment of the present disclosure.
- FIG. 33 is a data field diagram of a format of the Block Acknowledge
- FIG. 34 is a data field diagram of a Block Acknowledge (BA) Response frame according to at least one embodiment of the present disclosure.
- FIG. 35 is a communication sequence diagram as Example 9 of a STA transmitting an RTA packet with unsolicited retry on multiple links according to at least one embodiment of the present disclosure.
- FIG. 36 is a communication sequence diagram as Example 10 of a STA transmitting an RTA packet with unsolicited retry on a single link according to at least one embodiment of the present disclosure.
- FIG. 37 is a communication sequence diagram as Example 11 of how STA transmitting an RTA packet with unsolicited retry on a single link according to at least one embodiment of the present disclosure.
- FIG. 38 is a hardware block diagram of wireless communication stations affiliated in a multi-link device (MLD) configuration according to at least one embodiment of the present disclosure.
- MLD multi-link device
- FIG. 1 illustrates the contents in the Traffic Specification (TSPEC) element, which is defined in IEEE 802.11 as having the following fields.
- An Element ID field indicates the type of element. In this case it would indicate this is TSPEC element.
- a Length field indicates the length of the TSPEC element.
- a TS Information field contains the traffic stream information as described below for FIG. 2.
- a Nominal MAC Service Data Unit (MSDU) Size field indicates the nominal size of MSDUs or A-MSDUs belonging to the Traffic Stream (TS) under this TSPEC.
- a Maximum MSDU Size field indicates the maximum size of MSDUs or A-MSDUs belonging to the TS under this TSPEC.
- a Minimum Service Interval field indicates the minimum time between the start times of two successive service periods (SPs).
- a Maximum Service Interval field indicates the maximum time between the start times of two successive SPs.
- An Inactivity Interval field indicates the maximum amount of time to allow without arrival or transmission of a MSDU belonging to the TS before that TS is deleted.
- a Suspension Interval field contains the maximum amount of time without arrival or transmission of an MSDU belonging to the TS before the generation of successive Quality of Service (QoS): QoS(+)CF-Poll is stopped for this TS.
- QoS Quality of Service
- a Service Start Time field indicates the start time of the first SP.
- a Minimum Data Rate field indicates the lowest data rate specified by MAC SAP for transmitting MSDUs or A-MSDUs belonging to the TS under this TSPEC.
- a Mean Data Rate field indicates the average data rate specified by Media Access Control (MAC) Service Access Point (SAP) for transmitting MSDUs or A-MSDUs belonging to the TS under this TSPEC.
- a Peak Data Rate value field indicates the maximum data rate specified by MAC SAP for transmitting MSDUs or A-MSDUs belonging to the TS under this TSPEC.
- a Burst Size field indicates the maximum burst of MSDUs or A-MSDUs belonging to the TS under this TSPEC at the peak data rate.
- a Delay Bound field indicates the maximum time that is allowed for transmitting an MSDU or A-MSDU belonging to the TS under this TSPEC.
- a Minimum PHY Rate field indicates the lowest PHY rate for transmitting MSDUs or A-MSDUs belonging to the TS through the PHYsical layer under this TSPEC.
- a Surplus Bandwidth Allowance field indicates the ratio of the bandwidth used for transmitting a MSDU or A-MSDU belonging to the TS under this TSPEC and its retransmissions to the bandwidth used for a transmitting that MSDU or A-MSDU once at the minimum PHY rate.
- a Medium Time field indicates the time designated for accessing the medium.
- a DMG Attributes field is presented when the TSPEC is applied to a directional multi-gigabit (DMG) BSS.
- FIG. 2 shows the content in the TS Information field which is one of the fields in the TSPEC element described in FIG. 1 , as defined in IEEE 802.11 , and having the following subfields.
- a Traffic Type subfield specifies whether the traffic is periodic or not.
- a TSID subfield indicates the ID number to identify the Traffic Stream (TS).
- a Direction subfield specifies the direction of data transmission.
- An Access Policy subfield specifies the method to use for gaining channel access.
- An Aggregation subfield specifies whether an aggregation schedule is required.
- An APSD subfield indicates whether the automatic Power Save (PS) delivery is used.
- a User Priority subfield indicates the user priority of the MSDU or A-MSDU belonging to the TS.
- a TSInfo Ack Policy subfield indicates whether the ACK is required and which form of ACK is to be used.
- a Schedule subfield indicates the type of schedule.
- FIG. 3 shows the content in the TCLAS element which is defined in IEEE 802.11 , having the following fields.
- An Element ID field indicates the type of the element, and is used in this case to indicate a TCLAS element.
- a Length field indicates the length of the TCLAS element.
- a User Priority field indicates user priority from the upper layer.
- a Frame Classifier field indicates the method to be used in classifying the frames from the upper layer.
- FIG. 4 shows the contents of the TCLAS Processing element which is defined in IEEE 802.11 having the following fields.
- An Element ID field indicates the type of element; in this case a TCLAS Processing element.
- a Length field indicates the length of the TCLAS Processing element.
- a Processing field indicates the method of classifying the traffic from the upper layer when multiple TCLAS elements exist.
- wireless communication systems using CSMA/CA do not distinguish between RTA packets and non- RTA packets, and all the packets use the same retransmission scheme in CSMA/CA.
- the retransmission scheme in CSMA/CA aims to reduce the probability of packet collisions, while packet latency is not a primary concern.
- each retransmission requires the STA to contend for the channel with increasingly longer contention windows, which adds significant delay on packet transmissions, and thus increases packet latency.
- the retransmission scheme in CSMA/CA does not take packet timeliness into consideration.
- a transmitter STA retransmits the packet until either it is received by the receiver STA or it exceeds the retry limit.
- RTA packets have a lifetime within which they must be transmitted or be considered invalid. That is, the RTA packet has to be transmitted or retransmitted by a certain time.
- One solution under CSMA/CA wireless technology is to allow STAs to obtain channel access more rapidly with less channel contention time. Due to the random channel access scenario, STAs need to sense and contend for channel access before transmitting each packet. Although the short channel contention time accelerates channel access, it increases the probability of packet collision. The delay caused by packet collisions is still significant due to the channel contention time for each retransmission.
- a beneficial unsolicited retry scheme is described herein, in which RTA packets can be retransmitted without waiting for any feedback.
- a STA node duplicates the RTA packets in time and/or frequency domains.
- the duplications of an RTA packet are regarded as initial transmission and retransmissions of the RTA packets. They are transmitted during the same period of TXOP to achieve desired packet loss rates required by RTA traffic.
- the task of applying an unsolicited retry scheme for RTA packets in CSMA/CA system is more challenging due to the coexistence of the RTA traffic and non-RTA traffic.
- the challenge in this process can be summarized as: (a) identifying of RTA packet and non-RTA packet; (b) duplicating an RTA packet in time and/or frequency domains; (c) transmitting duplications of RTA packets during the same TXOP period.
- Designing an unsolicited retry scheme for RTA packets aims to consider the time-validity of RTA traffic and minimize its latency in a wireless network where RTA and non-RTA traffic coexist.
- RTAs can discern RTA packets from non-RTA packets.
- the timeliness of RTA traffic is taken into consideration, as STAs schedule the retransmission of RTA packets based on the lifetime of the RTA packet.
- STAs separate the retransmission scheme for RTA packets from that of non-RTA packets, while non-RTA packets can still use the regular retransmission scheme defined in CSMA/CA.
- An unsolicited retry scheme is provided for RTA traffic to transmit and retransmit the RTA packets in the same TXOP period.
- STAs are allowed to obtain TXOP on multiple links to transmit the initial transmission of the RTA packets on one link and retransmit their retransmissions on the other links.
- the present disclosure is compatible with OFDMA systems.
- STAs are allowed to use one resource unit (RU) to transmit the initial transmission of an RTA packet and another RU to transmit its retransmissions in the same MU-PPDU packet.
- a STA is allowed to set up a Block Acknowledgement (BA) agreement for RTA packets to obtain packet loss information on multiple links to adapt packet transmission, such as Modulation Coding Scheme (MCS), unsolicited retry limit, and others without limitation.
- BA Block Acknowledgement
- FIG. 5 illustrates an example embodiment 10 of a wireless communication circuit, one or more of which may be utilized in a station (STA).
- the station is shown having external I/O, CPU and Memory for executing a program that implements this communication protocol, and at least one modem and radio frequency (RF) circuit to transmit/receive data frames with neighboring STAs.
- RF radio frequency
- a WLAN station according to the present disclosure is shown with I/O path 14 into station circuit block 12 which has a bus 16 connected to at least one computer processor (CPU) 18, memory (RAM)
- CPU computer processor
- RAM random access memory
- Bus 14 allows connecting various devices to the CPU, such as to sensors, actuators and so forth.
- Instructions from memory 20 are executed on processor 18 to execute a program which implements the communication protocol, which is executed to allow the STA to perform the functions of an access point (AP) station, or a non-AP (regular) station (STA), or a Multi-Link Device (MLD) whether it's for an AP station or a non-AP station.
- AP access point
- STA non-AP (regular) station
- MLD Multi-Link Device
- the programming is configured to operate in different modes (source, intermediate, destination, first AP, other AP, non-AP stations associated with the first AP, stations associated with other AP, coordinator, coordinatee and so forth), depending on what role it is playing in the current communication context.
- This host machine is shown configured with at least one modem and RF circuit to generate and receive physical signals.
- a mmW modem 22 is coupled to at least one radio-frequency (RF) circuit 24 which connects to at least one antenna 26a, 26b, 26c through 26n (e.g., antenna array) to transmit and receive frames with neighboring STAs.
- RF radio-frequency
- the present disclosure can be utilized with stations which communicate directional signals, or omni-direction signals, or a combination of directional and omni-directional signals.
- an array of antennas such as seen 26a, 26b, 26c through 26n can allow a STA to transmit signals using multiple sets of beam patterns.
- the RF circuit generally includes a frequency converter, an array antenna controller, and other control and radio frequency circuits.
- the combination of processor, modem and RF circuits allow beamformed (directional) communications to be supported, as well as for supporting quasi-omni (referred to herein simply as omni) mode transmissions from the antenna array.
- nulls can be generated in directional patterns created by the antenna array to shield select directions (sectors) and thus reduce interference between stations.
- the STA HW is shown configured with at least one modem, and associated RF circuitry for providing communication on at least one band.
- the intended directional communication band is implemented with a mmW band modem and its associated RF circuitries for transmitting and receiving data in the mmW band.
- at least a second band is supported in hardware, generally referred to as a discovery band, which by way of example and not limitation may comprise a sub-6 GHz modem and its associated RF circuitry for transmitting and receiving data in the sub-6 GHz band.
- the present disclosure can be configured with multiple modems 22, with each modem coupled to any arbitrary number of RF circuits. In general, using a larger number of RF circuits will result in broader coverage of the antenna beam direction. It should be appreciated that the number of RF circuits and number of antennas being utilized is determined by hardware constraints of a specific device. Some of the RF circuitry and antennas may be disabled when the STA determines it is unnecessary to communicate with neighboring STAs.
- FIG. 38 illustrates a variation of FIG. 5, as embodiment 930 in which wireless communication stations are affiliated in a multi-link device (MLD) hardware configuration.
- MLD multi-link device
- Each STA operates on a link of a different frequency.
- Each station 10’ can be as that described in FIG. 5, with each having CPU, RAM, Modem, RF circuits and one or more antennas. It is seen in the figure that each of the n stations shown provide a different link (e.g., Link1, Link2 through Linkn are shown).
- the MLD is also seen with circuitry 932 of an MLD management entity having at least one processor (CPU) 934, memory 936 which provides external I/O to access applications of the MLD and to implement communication protocols at the MLD level.
- the MLD is configured to distribute tasks to, and collect information from, each affiliated STA and share information between affiliated STAs.
- each STA of the MLD need not have its own processor and memory.
- one or more stations may share processors and memory, or the processor and memory of the MLD circuit.
- the present disclosure contemplates many possible arrangements for communication over multiple links within an MLD.
- FIG. 6 illustrates an example embodiment 30 of a topology which is utilized herein for illustration purposes, and not by way of limitation, as the present disclosure can support network scenarios with various numbers of stations and station arrangements without limitation.
- the example describes seven STAs consisting of two BSSs in a surrounding enclosure (e.g., meeting room) 32, having any desired configuration and openings/apertures 34, furnishings and so forth. Each STA can communicate with the other STAs in the same BSS. All STAs use CSMA/CA for random channel access.
- all STAs are considered to run both applications requiring low latency communication and applications that use best effort communication.
- the data generated from the application requiring low latency communication is called RTA traffic and will be packetized as RTA packets at the transmitter STA.
- the data generated from the non-time sensitive application is called non-RTA traffic and will be packetized as non-RTA packets at the transmitter STA.
- the transmitter STA generates both RTA traffic and non-RTA traffic for communication.
- the location of the STAs and their transmission links are as shown in the figure.
- a first BSS comprises STA0 (AP) 36, STA1 38 and STA2 40 and is only able to transmit packets over a single channel/band.
- a second BSS comprises STA3 (AP) 46 and STA4 (AP) 48, which are affiliated by AP multi-link device (MLD) #1 42 to STA5 50 and STA6 52 affiliated by non-AP MLD #244.
- An MLD includes one MAC data service which is shared by the affiliated STAs.
- STA 5 is associated with STA 3 over Link1 52 and STA 6 is associated with STA 4 over Link2 54.
- MLD #1 and MLD #2 can transmit and receive data through either Link1 or Link2.
- a MLD has a link pair such that the MLD is not able to transmit on one link of the link pair and receive on the other link of the link pair simultaneously due to in-device operation constraints, then this MLD is referred to as non- Simultaneous Transmit/Receive (non-STR) MLD. Otherwise, a MLD is referred to as a Simultaneous Transmit/Receive (STR) MLD.
- STR Simultaneous Transmit/Receive
- RTAs generate traffic periodically, just as in connection- oriented communications.
- An RTA connection-oriented communication established by an application between STAs is called an RTA session. It is possible that a STA can have multiple RTA sessions in the network. A STA is able to manage those RTA sessions properly and applies the unsolicited retry policy to the RTA packets of an RTA session.
- An LLTS setup can be used for: (a) identifying RTA traffic of an RTA session from the upper layer; (b) setting the unsolicited retry configuration for RTA traffic of an RTA session; and (c) scheduling the unsolicited retry for RTA traffic of an RTA session to satisfy its Quality-of-Service (QoS) requirement.
- QoS Quality-of-Service
- FIG. 7 illustrates an example embodiment 70 of an LLTS setup communication shown between MAC Sublayer Management Entity (SME) 76 and MAC Sublayer Management Entity (MLME) 78 of a STA (e.g., non- AP STA) 72, and MLME 80 and SME 82 of another STA (e.g., an AP) 74.
- SME MAC Sublayer Management Entity
- MLME MAC Sublayer Management Entity
- STA e.g., non- AP STA
- MLME 80 and SME 82 of another STA e.g., an AP
- the interworking model of the STAs can utilize the same one as defined in the IEEE 802.11 standard.
- the non-AP STA decides to initiate an LLTS setup procedure with the AP.
- the Station Management Entity (SME) of the non-AP STA sends a MLME-LLTS. request message 84 to its MAC Sublayer Management Entity (MLME).
- MLME MAC Sublayer Management Entity
- the MLME of the non-AP STA receives the MLME- LLTS. request message, it collects the information in the MLME- LLTS. request message and sends a LLTS request frame 86 to the AP.
- the MLME of the AP receives the frame and generates a MLME- LLTS. indication message 88 to its SME.
- the SME of the AP processes 90 the message and sends an MLME-LLTS.
- response message 92 containing LLTS setup result to its MLME.
- the MLME of the AP sends an LLTS response frame 94 to the non-AP STA.
- the MLME of the non-AP STA receives the frame and sends an MLME-LLTS. confirm message 96 to its SME. From this exchange, the non-AP STA knows (can determine) whether the LLTS setup was successful or not.
- the lower portion of the figure shows an example of terminating an LLTS.
- the AP STA decides to terminate 98 a LLTS with the non-AP STA.
- the SME of the AP sends a MLME-LLTS-TERM. request message 100 to its MLME.
- the MLME of the AP receives the MLME-LLTS- TERM. request message, it collects the information in the MLME-LLTS- TERM. request message and sends a LLTS response frame 102 to the non- AP STA.
- the MLME of the non-AP STA receives the frame and generates a MLME-LLTS-TERM. indication message 104 to its SME.
- the non-AP knows (determines) that the LLTS is terminated.
- the RTA traffic of an RTA session can be classified by an LLTS setup.
- the traffic from the upper layer is RTA traffic of an RTA session if the upper layer information of the traffic matches the information of the TCLAS element and the TCLAS Process element which are exchanged during the LLTS setup procedure.
- the Quality-of-Service (QoS) requirements of the RTA traffic of an RTA session can be shared between AP and non-AP STAs by exchanging RTA-TSPEC elements during the LLTS setup procedure.
- the LLTS setup could also be used to check whether the AP and non-AP STAs have sufficient resources to support the RTA traffic transmission.
- FIG. 8 illustrates an example embodiment 110 of the format for an LLTS Request frame having the following fields.
- a Frame Control field indicates the type of frame.
- a Duration field contains NAV information used for CSMA/CA channel access.
- An Address 1 field contains an address for the recipient of the frame.
- An Address 2 field contains the address of the STA that transmitted the frame.
- An Address 3 field contains the BSSID.
- a Sequence control field indicates the sequence number of the frame.
- An HT control field indicates the extra control information for High-Throughput (HT) or Very-High-Throughput (VHT) frames.
- An Action field indicates the action to perform when it is the LLTS Request frame.
- a Frame Check Sequence (FCS) is seen here, and in other data formats described in the present disclosure, as it provides an error-detecting code added to a frame in a communications protocol.
- the above Action field includes an LLTS Request element, which in at least one embodiment has the following subfields.
- An Element ID subfield indicates the type of element, which in this case indicates an LLTS Request element.
- a Length subfield indicates the length of the LLTS Request element.
- An LLTS Descriptor List subfield indicates the sequence of LLTS Descriptor fields, with each LLTS Descriptor field set to indicate a LLTS setup request for the traffic under certain specification and classification information. When this information is received the recipient STA can understand (recognize) the specification and classification information of the traffic and decide to accept or reject the LLTS setup request.
- FIG. 9 illustrates an example embodiment 130 of an LLTS Descriptor having the following fields.
- An LLID field contains the identification of a low latency transmission service.
- the non-AP STA sets a number to represent the LLTS. The AP receiving this number can utilize it to identify the LLTS which is set with the non-AP STA.
- An LL Length field indicates the length of the LLTS Descriptor field.
- a Request Type field is set to indicate the type of LLTS descriptor. When the non-AP STA sets the request type field to “Add”, then the non-AP STA requests to add a new LLTS. The receiver AP should respond to this request whether the adding of a new LLTS is accepted by the AP or not.
- the non-AP STA sets the request type field to “Change”, then the non-AP STA requests to change the parameters of an existing LLTS.
- the AP receives this field, it can find the LLTS using the LLID, and either accept the parameter changes to that LLTS, or reject the change.
- the non-AP STA sets the request type to “Remove”, then the non-AP STA requests to remove an existing LLTS.
- the AP receives this field it can find the LLTS using the LLID and removes the LLTS.
- a TCLAS field can be identical to TCLAS element defined in IEEE 802.11.
- the non-AP STA sets this field to indicate the information of the traffic from the upper layer.
- the AP uses this information to identify the RTA traffic under this LLTS arriving from the upper layer when the traffic is downlink and the upper layer information of the traffic matches the TCLAS information.
- the LLTS Descriptor field can contain multiple TCLAS fields.
- a TCLAS Processing field can be identical to TCLAS Processing element defined in IEEE 802.11.
- the non-AP STA sets this field to indicate the rule of using multiple TCLAS fields to identify the RTA traffic when there exists multiple TCLAS fields in the LLTS Descriptor field.
- the AP receives this field in the LLTS Descriptor field, it can determine how to use multiple TCLAS fields to identify the traffic from the upper layer.
- An RTA-TSPEC field indicates the specification and the QoS requirement for the RTA traffic.
- the AP can use the information in this field to decide whether to accept or reject the LLTS request.
- This field also contains information on traffic direction under this LLTS (e.g., uplink, downlink, or bidirectional) which could be set in the Direction field of the TS Info field of TSPEC element.
- the TSID field in the TS Info field of TSPEC element can be set to indicate the TID of the RTA traffic belonging to the LLTS under this RTA-TSPEC.
- the Access Policy field in TS Info field of TSPEC element can be set to indicate the access method, such as EDCA, HCCA, HEMM, and so on (as defined in IEEE 802.11), to be used for the LLTS under this RTA-TSPEC.
- the User Priority field in TSPEC could be used to indicate the user priority of the RTA traffic belonging to the LLTS.
- STA1 could setup a LLTS with STA0.
- the LLID is set to “1”
- the TSID is set to “8”.
- An Optional Subelements field indicates the retransmission policy of the traffic under this LLTS. When an AP receives this field, it should respond to the non-AP STA whether or not it will provide the requested LLTS for the traffic.
- FIG. 10 illustrates an example embodiment 150 of the RTA-TSPEC having the following fields.
- a TSPEC field can be identical to the TSPEC element defined in IEEE 802.11.
- the non-AP sets this field to indicate the specification and partial QoS requirement for the RTA traffic under this RTA-TSPEC.
- the AP receives this field, it can use this information to estimate resource distribution for the transmission of the RTA traffic under this RTA-TSPEC. Based on the estimation, the AP can decide whether to accept the LLTS setup or not.
- An RTA Attributes field indicates the additional QoS requirement for RTA traffic under this RTA-TSPEC.
- a Reliability field indicates packet loss requirements of the RTA traffic under this RTA-TSPEC.
- the AP When the AP receives this field, it should estimate the resource distribution for the transmission of the RTA traffic under this RTA- TSPEC to ensure that the packet loss of the RTA traffic under this RTA- TSPEC is less than the packet loss indicated in the Reliability field, especially when the unsolicited retry is enabled.
- a jitter field indicates the jitter requirement of the delivery of the
- the non-AP sets this field to request the AP to guarantee that the maximum jitter limit of the MSDU or A-MSDU belonging to the LLTS under this RTA- TSPEC.
- AP receives this field and estimates whether this request can be satisfied or not. For example, the difference between Maximum service Interval and Minimum service Interval should be less than jitter to satisfy this request.
- the AP sets this field to indicate the jitter level it can support. When the non-AP receives this field, it either accepts the jitter provided by AP or renegotiates with the AP.
- An MSDU Lifetime field indicates that the MSDU lifetime represents the time that the MSDU can be stored at the queue.
- the STA sets this field to indicate the MSDU lifetime of the RTA traffic under this RTA-TSPEC when the Deterministic Service field is set to a first state (e.g., “1”).
- the Deterministic Service field is set to the first state (e.g., “1”).
- the MSDU is dropped when the MSDU is not transmitted successfully within this MSDU lifetime.
- the Deterministic Service field is set to a second state (e.g., “0”), then this field is reserved.
- a Deterministic Service field is set by the STA to indicate whether the MSDU of the RTA traffic under this RTA-TSPEC will be dropped when its lifetime expires. If a STA sets this field to a first state (e.g., “1”), then the MSDU of the RTA traffic under this RTA-TSPEC will be dropped when its lifetime expires; otherwise the STA sets this field to a second state (e.g., “0”). When the STA receives this field which is set to a first state (e.g., “1”), then the MSDU of the RTA traffic under this RTA-TSPEC will be dropped when its lifetime expires. When the STA receives this field which is set to a second state (e.g., “0”), then there is no lifetime value for the MSDU of the RTA traffic under this RTA-TSPEC.
- a first state e.g., “1”
- a second state e.g., “0”
- a Nominal Service Interval field indicates the nominal/average time between the start time of two successive SPs. It is possible that this field is only valid when the Traffic Type subfield in the LLTS Info is set to a first state (e.g., “1”).
- the Non-AP sets this field to request the AP to guarantee the service interval of the MSDU or A-MSDU belonging to the LLTS under this RTA-TSPEC.
- the AP receives this field and estimates whether this request can be satisfied or not. For example, the AP sets this field to indicate the Nominal service interval it can provide. When the non-AP receives this field, it either accepts the service interval provided by AP or renegotiates with AP.
- FIG. 11 illustrates an example embodiment 170 of an Optional Subelement having the following fields.
- a non-AP STA sets the following fields in LLTS request frame, then those fields represent the request of the non-AP STA to establish an LLTS.
- the AP receives this request, it can decide (determine) whether it can accept the request.
- a non-AP STA sets the following fields in the LLTS response frame to accept an LLTS setup, then those fields represent the setting of the LLTS.
- Both AP and non-AP STAs should follow the LLTS settings to execute the unsolicited retry for the RTA traffic under this LLTS.
- a Subelement ID field indicates the type of subelement. The field here indicates it is an optional subelement under LLTS Request element.
- a Length field indicates the length of the optional subelement field.
- An LLTS Retransmission Policy field indicates the retransmission policy for the LLTS. The non-AP STA sets this field to request application of this retransmission policy for the RTA traffic under this LLTS. When the AP STA receives this field it decides whether to accept or reject the request. The AP STA sets this field to indicate the request of the retransmission policy it provides when the LLTS setup is accepted.
- the non-AP STA When the non-AP STA receives this field, it can apply the retransmission policy given by the AP STA to the RTA traffic under this LLTS.
- this field When this field is set to “unsolicited retry”, then the packets under this LLTS will be transmitted with unsolicited retry on single link if the LLTS setup is successful.
- this field When this field is set to “unsolicited retry with BA”, then the packets under this LLTS will be transmitted with unsolicited retry on single links if the LLTS setup is successful.
- the transmitter of the packets may request block ACK feedback by sending a Block ACK Request (BAR) frame to the receiver.
- BAR Block ACK Request
- An Unsolicited Retry Limit field is set to limit the number of the packet retransmissions under this LLTS when unsolicited retry is applied. The number of retransmissions of each packet under this LLTS should not exceed the unsolicited retry limit. If the number of the retransmissions of a packet under this LLTS exceeds the unsolicited retry limit, then that packet should be dropped.
- An MAC Protocol Data Unit (MPDU) Lifetime field is set to indicate the lifetime of the MPDU under this LLTS. If the time since an MPDU arrives at the MAC layer is longer than the MPDU lifetime, then the lifetime of that MPDU expires and that MPDU should be dropped.
- MPDU MAC Protocol Data Unit
- a Duplication in Time Allowance field can be implemented as a one- bit indication to indicate whether packet duplication in the time domain is allowed.
- this field is set to a first state (e.g., “1”), then the packet under this LLTS is able to be retransmitted after its previous transmission attempt within the same TXOP or different TXOPs on a single link. No feedback is needed between those two transmission attempts.
- this field is set to a second state (e.g., “0”), then the packet duplication in time is not allowed.
- a Duplication in ML Allowance field can be implemented as a one-bit indication to indicate whether the packet duplication over multiple links is allowed.
- this field is set to a first state (e.g., “1”), then the packet under this LLTS is able to be transmitted on one link and retransmitted on another link. No feedback is needed between the two transmission attempts.
- this field is set to a second state (e.g., “0”), then the packet transmission and its retransmissions are only allowed to be transmitted over one link.
- a Maximum Number of Links field is set to indicate the maximum number of links that can be used for the unsolicited retry. When this field is set, the number of links which consist of a combination listed in the Allowed Combinations of Links field cannot exceed the Maximum Number of Links. This field is reserved when the Duplication in ML Allowance field is set to the second state (e.g., “0”).
- An Allowed Combinations of Links field is set to indicate the possible combinations of multiple links that could be used for unsolicited retry.
- a STA can pick one of the combinations to transmit the packet and its unsolicited retries over the links in the combination. It should be appreciated that the number of links in each combination cannot exceed the maximum number of links. This field is reserved when the Duplication in ML Allowance field is set to a second state (e.g., “0”).
- a Duplication in RU Allowance field can provide an indication (e.g., one-bit indication) to indicate whether the duplicated packets are allowed to be transmitted over multiple RUs in one MU PPDU/TB PPDU packet. “TB” indicates that the PPDU is Trigger Based.
- the indication (bit) is set to a first state (e.g., “1”), then the STA can use one RU to transmit the packet and use the other RUs to transmit its duplications. Otherwise, if the indication (bit) is set to a second state (e.g., “0”) then the packet duplication in RU is not allowed.
- a Maximum number of RUs field is set to indicate the maximum number of RUs of a MU PPDU/TB PPDU packet that can be used for the unsolicited retry.
- This field is reserved when the Duplication in RU Allowance field is set to a second state (e.g., “0”).
- An Allowed Combinations of RUs field is set to indicate the possible combinations of multiple RUs in one MU PPDU/TB PPDU packet that could be used for unsolicited retry.
- a STA can pick one of these combination to transmit the packet and its unsolicited retries over the RUs in the combination. It should be appreciated that the number of RUs in each combination cannot exceed the maximum number of RUs.
- This field is reserved when the Duplication in ML Allowance field is set to a second state (e.g., “0”). It will be noted that for each combination, it may also indicate which link this combination is applied to.
- FIG. 12 illustrates an example embodiment 190 of an LLTS
- a Frame Control field indicates the type of the frame.
- a Duration field contains NAV information used for CSMA/CA channel access.
- An Address 1 field contains an address for the recipient of the frame.
- An Address 2 field contains the address of the STA that transmitted the frame.
- An Address 3 field contains the BSS ID.
- a Sequence Control field indicates the sequence number of the frame.
- An HT control field indicates the extra control information for HT or VHT frames.
- An Action field indicates the action to perform when it is the LLTS Response frame.
- the fields in the Action field include an LLTS Response element, having the following subfields.
- An Element ID subfield indicates the type of the element, which in this case indicates it is an LLTS Response element.
- a Length subfield indicates the length of the LLTS Response element.
- An LLTS Status List subfield indicates a sequence for the LLTS Status fields. Each LLTS Status field is set to indicate the a LLTS setup response for the traffic under certain specification and classification information. When this information is received, the receiver STA can determine the results of the LLTS setup for the RTA traffic or the change of the existing LLTS.
- FIG. 13 illustrates an example embodiment 210 of an LLTS Status frame having the following fields.
- An LLID field contains the identification of a low latency transmission service.
- An LL Length field indicates the length of the LLTS Descriptor field.
- a Response Type field is set to indicate the type of LLTS setup result. When the AP sets the response type field to “Accept”, then the AP accepts the LLTS setup request from the non-AP STA. The non-AP STA receives this field and can determine that the LLTS setup was successful. When the AP sets the response type field to “Denied”, then the AP rejects the LLTS setup request from the non-AP STA.
- the non-AP STA When the non-AP STA receives this field, it may decide to attempt to initiate another LLTS setup with AP. When the AP sets the response type to “Terminate”, then the AP terminates an existing LLTS with the non-AP STA. When the non-AP STA receives this field, it knows (determines) that the LLTS with the corresponding LLID is terminated and that the LLTS should be removed.
- a TCLAS field can be identical to TCLAS element defined in IEEE 802.11.
- the AP sets this field to indicate the information of the traffic from the upper layer. When the non-AP STA receives this field, it can use this information to identify the traffic under this TTLS arriving from the upper layer when the traffic is an uplink.
- the LLTS Status field can contain multiple TCLAS fields.
- a TCLAS Processing field can be identical to the TCLAS Processing element defined in IEEE 802.11. The AP sets this field to indicate the rule of using multiple TCLAS fields to identify the RTA traffic when there exists multiple TCLAS fields in the LLTS Status field. When the non-AP STA receives this field in the LLTS Status field, it can determine how to use multiple TCLAS fields to identify the traffic from the upper layer.
- An RTA-TSPEC field is identical to RTA-TSPEC element defined in FIG. 9.
- the AP sets this field to indicate the specification and QoS requirements of the RTA traffic.
- This field also contains the information of the RTA traffic direction under this LLTS (e.g., uplink, downlink, or bidirectional).
- An Optional Subelements field is set by the AP to indicate the retransmission policy of the traffic under this LLTS.
- a non-AP STA receives this field, it knows (determines) that the retransmission policy provided by AP when the response type field is set to “Accept”.
- Tables 1 through 6 provide information about the above messages.
- Table 1 outlines the MLME-LLTS. request
- Table 2 outlines the MLME-LLTS. indication
- Table 3 outlines the MLME-LLTS.
- Table 4 outlines MLME-LLTS.
- Table 5 outlines the MLME-LLTS- TERM. request
- Table 6 outlines the MLME-LLTS-TERM. indication.
- FIG. 14 illustrates an example embodiment 230 of a STA deciding to apply the unsolicited retry policy to an RTA packet.
- the STA checks 234 whether this packet belongs to an existing LLTS with the unsolicited retry policy applied. If this packet belongs to an existing LLTS, then execution moves to block 238 and the STA applies the unsolicited retry policy to the packet. Otherwise, if the packet does not belong to an existing LLTS, then the STA uses the regular retransmission policy 236 in CSMA/CA for the packet.
- FIG. 15 illustrates an example embodiment 250 of a STA transmitting an RTA packets with unsolicited retry when the packet duplication in the time domain is allowed.
- STA When the STA is to transmit an RTA packet with unsolicited retry and the packet duplication in the time domain is allowed, that station contends for the channel, gains channel access and obtains the TXOP on a link 252.
- a check is then made 254 if the lifetime of the RTA packet has expired or the retry count exceeded the retry threshold. If either condition is met, then the RTA packet is dropped 260. Otherwise, if neither condition was met execution moves to block 256 and the STA makes one transmission attempt for the packet without waiting for feedback.
- a check 258 is made if the current TXOP has ended. If it has not ended, then execution returns to block 254 for another transmission attempt of the RTA packet in the next TXOP. Otherwise, execution moves to block 252 for the STA to again contend for the channel.
- FIG. 16 illustrates an example embodiment 270 of an MLD obtaining TXOP for RTA packets with unsolicited retry in a multi-link scenario.
- MLD has RTA packets to transmit with unsolicited retry, it contends 272 for the channel on multiple links simultaneously.
- a check is made 274 if all the links have gained channel access simultaneously. If the condition is true, then the MLD reserves 276 the same duration of TXOP on both links and the MLD transmits initial transmission of the packets on Link1 and their retransmissions on Link2. It should also be appreciated that the MLD can transmit another retransmission of the same packets on Link1 as they are retransmitted on Link2, instead of the initial transmission of those packets.
- the MLD fails 284 to obtain the TXOP on Link2 and no unsolicited retry occurs on Link2 with the process ending.
- the MLD could decide to drop the packets that are transmitted during the current TXOP after the end of the current TXOP. MLD could also decide to retransmit those packets in the next TXOP if their lifetime does not expire and their retry count does not exceed the unsolicited retry limit.
- the MLD could obtain TXOP on more than two links for the unsolicited retry.
- the link which obtains the TXOP first is regarded as Link1 and the other links follow the rule of Link2 as explained in the flowchart.
- the combination of links could be chosen from the Allowed Combinations of Links field in LLTS setup.
- the AP gains channel access and reserves another TXOP on Link1 whose end time is later than the TXOP of Link2, then the non-STR non-AP MLD is not able to access the channel until the end time of the second TXOP of Link1 and so on.
- the STR AP MLD would always occupy the multi-link and the non-STR non-AP MLD would have no chance to access the channel at all.
- FIG. 17A and FIG. 17B illustrates an example embodiment 290 for an STR AP MLD obtaining TXOP on multi-link to transmit to non-STR non- AP MLD indicating a way of solving the fairness issue between STR AP MLD and non-STR non-AP MLD as described above.
- STR AP MLD When STR AP MLD has packet(s) 292 to transmit to non-STR non-AP MLD, it generates a random value 294 and sets it as the number of backoff slots. It will be noted that each “slot” connotes a time increment, such as 20 microseconds. Then, each STA of the AP MLD starts to count down 296 the backoff on its own link independently.
- the method of obtaining TXOP as shown in the figure can also be used for transmitting either RTA packets or non- RTA packets.
- FIG. 18 illustrates an example embodiment 310 for transmitting an RTA packet when unsolicited retries on multi-RU is allowed.
- the AP contends for channel access and gains the channel 312 for an RTA packet when unsolicited retry on multi-RU is allowed.
- a check 314 determines if the transmission is an uplink (UL). If this is an uplink, then at block 316 the AP embeds the RU distribution for the unsolicited retry in the trigger frame (TF) and transmits it to STA.
- the STA uses the RUs distributed by TF to transmit 320 the initial transmission (it could also be a retransmission) and retransmission of the RTA packet in the TB PPDU packet and the process ends.
- the TB PPDU or the MU PPDU can only carry the retransmissions of the packet if the initial transmission of the RTA packet has been transmitted in the previous PPDU.
- FIG. 19 illustrates an example embodiment 330 for a STA dropping an RTA packet which was allowed unsolicited retry.
- a Check is made 332 to determine if the number of packet retransmissions has reached the unsolicited retry limit or the lifetime of the packet has expired. If either condition is met then the packet is dropped 334. Otherwise, execution moves from block 332 to block 336 and the STA is able to retransmit the packet without receiving any feedback in the current TXOP.
- FIG. 20 illustrates a first example embodiment 350 of an STA transmitting an RTA packet with unsolicited retry on a single link.
- This example can arise when the LLTS Retransmission Policy is set to “unsolicited retry” and the packet duplication in the time domain is allowed.
- the network topology of this example is shown in FIG. 6.
- Transmitter STA1 352 is to transmit an RTA packet to Receiver STAO (AP) 354.
- the unsolicited retry is allowed for transmitting the RTA packet which has arrived 356 in the queue.
- Transmitter STA1 contends 358 for the channel after RTA packet arrives in the queue and obtains the TXOP duration 360.
- STA1 is able to transmit the RTA packet 362 with two unsolicited retransmissions 366, 370.
- the time between two packet transmissions could be an interframe spacing 364, 368, which is depicted as xlFS, however, SIFS or PIFS or other spacing may be utilized without departing from the teachings of the present disclosure. It should be appreciated that the transmissions from STA1 were performed without the need of Receiver STAO transmitting any feedback to STA1.
- STA1 stops retransmitting the RTA packet when the packet reaches the unsolicited retry limit 372.
- FIG. 21 illustrates an example embodiment 390 as Example 2 of a STA transmitting multiple RTA packets with unsolicited retry on a single link. This example arises when the LLTS Retransmission Policy is set to “unsolicited retry” and the duplication in time is allowed.
- the network topology of this example is shown in FIG. 5.
- Transmitter STA1 352 is has two RTA packets to transmit, depicted as RTA packet #1 and RTA packet #2, to Receiver STAO (AP) 354.
- the unsolicited retry is allowed for transmitting the two RTA packets.
- the RTA packet arrives 356 in the queue and transmitter STA1 contends 358 for the channel and after backoff obtains the TXOP duration 360.
- STA1 first transmits the initial transmissions of all the packets 392 and 396. Then it commences a first retransmission of all the packets 400, 406, after which is shown starting a second retransmission 410 of RTA packet #2.
- STA1 is able to transmit the RTA packets with unsolicited retransmissions.
- the time between the initial transmissions of the two packets could be an interframe spacing, depicted herein as xlFS 394, 404, although other spacing, such as SIFS or PIFS can be used without limitation.
- Transmitter STA1 may wait another backoff time 398, 408 for the new retransmissions of RTA packet #1 and RTA packet #2. For example, transmitter STA1 invokes backoff 398 for the first retransmission of RTA packet #1 and #2. It also invokes backoff 408 for the second retransmission of RTA packet #2.
- the time between the retransmissions of the two packets with the same retry count could also be an xlFS, or other interframe spacing.
- transmitter STA1 stops retransmission 402 of RTA packet #1 because the lifetime of that RTA packet has expired.
- Transmitter STA1 also is seen stopping 412 retransmission of RTA packet #2 because the number of the retransmission of that RTA packet reached the unsolicited retry limit. It will be seen in the figure that receiver STA0354 did not need to transmit any feedback to STA1 during this process.
- FIG. 22 illustrates an example embodiment 430 as Example 2-1 of a STA transmitting multiple RTA packets with unsolicited retry on a single link. This example arises when the LLTS Retransmission Policy is set to “unsolicited retry” and the packet duplication in the time domain is allowed.
- the network topology of this example is shown in FIG. 5.
- Transmitter STA1 352 is to transmit two RTA packets, exemplified as RTA packet #1 and RTA packet #2, to Receiver STA0 (AP) 354, and the unsolicited retry is allowed for transmitting two RTA packets.
- An RTA packet arrives 356 in the queue.
- Transmitter STA1 contends 358 for the channel after the RTA packet arrives in the queue and obtains the TXOP duration 360.
- STA1 first transmits one packet (i.e. , RTA packet #1 ) 432 with its unsolicited retries 436. Then it transmits the second packet (i.e., RTA packet #2) 442 with its unsolicited retries 446, 450, and so forth.
- the retransmissions of RTA packet #2 are also seen with possible backoffs 444 and 448.
- STA1 is able to transmit the RTA packets with two unsolicited retransmissions.
- Transmitter STA1 may wait another backoff time 434, 440, 444 and 448 for the new transmission or retransmission of RTA packet.
- Transmitter STA1 stops retransmission 440 of RTA packet #1 because the lifetime of that RTA packet expires.
- Transmitter STA1 stops retransmission 452 of RTA packet #2 because the number of the retransmissions of that RTA packet has reached the unsolicited retry limit.
- Receiver STAO 354 does not need to transmit any feedback to STA1.
- FIG. 23 illustrates an example embodiment 470 as Example 3 of a STA transmitting an RTA packet with unsolicited retry on a single link when the BA is enabled. This example arises when the LLTS Retransmission Policy is set to “unsolicited retry with BA” and the packet duplication in the time domain is allowed.
- the network topology of this example is shown in FIG. 6.
- Transmitter STA1 352 is to transmit an RTA packet to Receiver STAO (AP) 354.
- the unsolicited retry is allowed for transmitting the RTA packet.
- Transmitter STA1 contends 358 for the channel after RTA packet arrives 356 in the queue and obtains the TXOP duration 360.
- TXOP duration 360 STA1 is able to transmit the RTA packet 472 with two unsolicited retransmissions 476 and 480.
- the time between two packet transmissions could be an interframe spacing as such an xlFS 474, 478 and 482 as shown in the figure, or other spacing 486 (e.g., SIFS or PIFS, etc.).
- Receiver STAO 354 does not need to transmit any feedback to STA1.
- STA1 may stop retransmitting the RTA packet when the packet reaches the unsolicited retry limit.
- STA1 After STA1 finishes retransmitting the RTA packet, it can transmit a BAR frame 484 to STAO to request an BA feedback. Then STAO receives the BAR and sends a BA 488 back to indicate the packet loss of the current packet.
- the BA in this example may be not transmitted for retransmissions but for adaptations, such as rate adaptation and unsolicited retry limit adjustment, for use in future RTA packet transmissions.
- FIG. 24 illustrates an example embodiment 490 as Example 4 of a STA transmitting an RTA packet with unsolicited retry on a single link when the BA is enabled.
- This example arises when the LLTS Retransmission Policy is set to “unsolicited retry with BA” and the packet duplication in the time domain is allowed.
- the network topology of this example is shown in FIG. 6.
- Transmitter STA1 352 is to transmit four RTA packets, exemplified here as RTA packet #1 492, RTA packet #2 496, RTA packet #3 512 and RTA packet #4 516, to Receiver STAO (AP) 354.
- the unsolicited retry is allowed for transmitting the RTA packets.
- RTA packets arrive 356 in the queue then transmitter STA1 contends 358 for the channel and obtains the TXOP duration 360.
- STA1 first transmits the initial transmissions 492, 496 of RTA packets #1 and #2. Then it transmits the first retransmissions 500, 504 for RTA packets #1 and #2.
- STA1 In the lower portion of the figure STA1 is seen obtaining the TXOP a second time for RTA packets #3 and #4.
- RTA packet(s) arrives 506 in the queue then transmitter STA1 contends 508 for the channel and obtains the TXOP duration 510.
- STA1 then transmits initial transmissions of RTA packet #3 512, and RTA packet #4 516, and then first retransmissions of RTA packet #3 520, and RTA packet #4 524.
- STA1 is able to transmit the RTA packets with unsolicited retransmissions.
- the time between two consecutive transmissions 494, 498, 502, 514, 518, 522, 526, 530 may comprise an interframe spacing, such as xlFS, SIFS, PIFS, or other interframe spacing mechanism.
- STA1 obtains the TXOP twice. During the first TXOP, RTA packet #1 and RTA packet #2 are transmitted. During the second TXOP, RTA packet #3 and RTA packet #4 are transmitted. After STA1 finishes retransmitting RTA packet #4, it transmits a Block Acknowledge Request (BAR) frame 528 to STA0 to request BA feedback. STA0 receives the BAR and responds by sending a BA 532 back to indicate the packet loss of the current packet as well as previous RTA packets (i.e. , RTA packets #1 , #2, #3 and #4) which have been received.
- BAR Block Acknowledge Request
- the BA in this example may be not transmitted for retransmissions but for adaptations, such as rate adaptation and unsolicited retry limit adjustment, of the RTA packet transmissions in the future.
- FIG. 25 illustrates an example embodiment 550 as Example 5 of a STA transmitting an RTA packet with unsolicited retry on a single link when the BA is enabled.
- This example scenario arises when the LLTS Retransmission Policy is set to “unsolicited retry with BA” and the packet duplication in the time domain is allowed.
- the network topology of this example is shown in FIG. 6.
- Transmitter STA1 352 is to transmit an RTA packet (RTA packet #1) to Receiver STA0 (AP) 354.
- RTA packet #1 RTA packet
- AP Receiver STA0
- the unsolicited retry is allowed for transmitting the RTA packet.
- An RTA packet 356 arrives in the queue and transmitter STA1 contends 358 for the channel and obtains TXOP duration 360.
- STA1 is able to transmit 552 RTA packet #1 with unsolicited retransmissions.
- the time between two packet transmissions can include a backoff time 554, after which is seen STA1 performing a first retransmission 556 of RTA packet #1. At which time the number of retransmissions has reached 558 the unsolicited retry limit.
- BAR frame 562 to STA0 to request BA feedback.
- STA0 receives the BAR and sends a BA 566 back to indicate packet loss information for the current packet.
- the time between the end of the first retransmission of RTA packet #1 and BAR frame, and between BAR and BA response, may be an interframe spacing 560 and 564, such as xlFS, SIFS, PIFS, or other spacing mechanism.
- the BA in this example may not be transmitted for the purpose of retransmissions but for adaptations, such as rate adaptation and unsolicited retry limit adjustment, to aid future RTA packet transmissions.
- FIG. 26 illustrates an example embodiment 570 as Example 6 of a STA transmitting an RTA packet with unsolicited retry on multiple links.
- This example scenario arises when the LLTS Retransmission Policy is set to “unsolicited retry” and packet duplication on multi-links is allowed.
- the network topology of this example is shown in FIG. 6.
- Transmitter MLD 1 571 is to transmit several RTA packets to Receiver MLD 2 (AP) (not shown) over multiple links.
- STA3 (AP) 572 of MLD1 transmits packets to STA5 (not shown) of MLD2 over Link1 and
- STA4 (AP) 574 of MLD1 transmits packets to STA6 (not shown) over Link2.
- the unsolicited retry is allowed for transmitting the RTA packets over multiple links.
- RTA packets arrive 576 and STA3 and STA4 start to contend 578, 580 for the channel on Link1 and Link2 at the same time.
- TXOP duration 582 on Link1 first, and transmits initial transmissions of its RTA packets depicted as sending 586 RTA packet #1 , sending 590 RTA packet #2, sending 594 RTA packet #3 and sending 598 RTA packet #4.
- the time between two packet transmissions may be an interframe spacing xlFS, SIFS, PIFS, or similar.
- STA4 obtains TXOP duration 584 on Link2 before the end of TXOP on Link1 and reserves it. During TXOP on Link2, STA4 transmits the retransmissions of the RTA packets whose initial transmissions were transmitted during TXOP on Link1. Specifically, STA4 sends first retransmissions 588, 592 and 596.
- the time between two packet transmissions can be an interframe spacing, such as xlFS, SIFS, PIFS, or other spacing mechanism as in the other examples of the present disclosure.
- STA4 may not be able to retransmit all the RTA packets if the TXOP duration on Link2 is of insufficient length. For example, as shown in this example, the first retransmission of RTA packet #4 is not retransmitted over Llnk2 since it cannot be transmitted within the TXOP. RTA Packet #4 could be dropped after the end of the TXOP even if its lifetime is not expired. It will be noted that MLD2 does not need to transmit any feedback to indicate the success of the RTA packet transmissions. It should also be noted that the number of backoff slots on the two links can be the same. STA3 and STA 4 gain the channel at different times due to CCA busy time during counting down the backoff.
- FIG. 27 illustrates an example embodiment 610 as Example 6-1 of a STA transmitting an RTA packet with unsolicited retry on multiple links.
- This example scenario arises when the LLTS Retransmission Policy is set to “unsolicited retry” and the duplication on multi-link is allowed, and as in the other examples is using the network topology as was shown in FIG. 6.
- Transmitter MLD 1 571 is to transmit several RTA packets to
- Receiver MLD 2 (AP) (not shown) over multiple links.
- STA3572 of MLD1 transmits packets to STA5 (not shown) of MLD2 over Link1 and STA4574 of MLD1 transmits packets to STA6 (not shown) over Link2.
- the unsolicited retry is allowed for transmitting the RTA packets over multiple links.
- STA3 obtains the channel access and reserves TXOP duration 582 on Link1 first. Then,
- STA1 is able to transmit the initial transmissions of the RTA packets during the TXOP on Link1. More specifically in this example STA3 sends 612,
- the time between two packet transmissions can be an interframe spacing, such as xlFS, or other spacing mechanism.
- the duration of xlFS can be adjusted in order to align 628 the end of the last PPDUs transmitted in the TXOP on both links. For example, as shown in the figure, the end of the initial transmission of RTA packet #4 and the end of the first retransmission 626 of RTA packet #4 are aligned. Since the transmissions of RTA packets #1 through #4 on the two links are known, the duration of xlFS can be calculated when STA4 gains channel access on Link2. It is possible that the xlFS is longer than SIFS but shorter than PIFS.
- STA4 obtains TXOP duration 584 on Link2 and reserves it before the end of TXOP on Link1.
- STA4 transmits the retransmissions 614, 618, 622 and 626 of RTA packets (RTA packets #1 , #2, #3 and #4) whose initial transmissions were transmitted during TXOP on Link1.
- the time between two packet transmissions is a form of interframe spacing, but since STA4 obtained the channel later than STA3, it is preferably a short interframe spacing (SIFS).
- SIFS short interframe spacing
- the number of backoff slots on the two links can be the same.
- STA3 and STA4 gain the channel at different times due to the CCA busy time during counting down backoff.
- FIG. 28 illustrates an example embodiment 630 as Example 6-1-1 of a STA transmitting an RTA packet with unsolicited retry on multiple links.
- This example scenario arises when the LLTS Retransmission Policy is set to “unsolicited retry” and the packet duplication on multi-link is allowed.
- the network topology of this example is shown in FIG. 6.
- This example shows that the packet duplication in multi-link transmission can be performed when the end time of TXOPs reserved on two links differ, which can arise when the AP MLD and non-AP MLD are STR. It is also possible that this can arise in cases whereby the AP MLD is either STR or NSTR, and the non-AP MLD is either STR or NSTR.
- Transmitter MLD 1 571 is to transmit several RTA packets to
- Receiver MLD 2 (AP) (not shown) over multiple links.
- STA3572 of MLD1 transmits packets to STA5 (not shown) of MLD2 over Link1 and STA4574 of MLD1 transmits packets to STA6 (not shown) over Link2.
- the unsolicited retry is allowed for transmitting the RTA packets over multiple links.
- RTA packets arrive 576 and STA3 and STA4 start to contend 578, 580 for the channel on Link1 and Link2 at the same time.
- STA3 obtains the TXOP duration 582 on Link1 first.
- STA1 is able to transmit the initial transmissions 632, 636, 640 and 644 of the RTA packets (#1 , #2, #3 and #4) during the TXOP on Link1.
- the time between two successive packet transmissions can be an interframe spacing, such as xlFS, SIFS, PIFS or other spacing mechanism.
- STA4 obtains the TXOP duration 584 on Link2 before the end of
- TXOP on Link1 STA4 reserves the TXOP whose end time is not the same as the end time of the TXOP on Link1. During the TXOP on Link2, STA4 transmits the retransmissions 634, 638, 642 and 646 of the RTA packets (#1 , #2, #3 and #4) whose initial transmissions were transmitted during the TXOP on Link1.
- MLD2 does not need to transmit any feedback to indicate the success of the RTA packet transmissions.
- the number of backoff slots on the two links can be the same.
- STA3 and STA4 gain the channel at different times due to CCA busy time during counting down the backoff.
- FIG. 29 illustrates an example embodiment 650 as Example 6-2 of a STA transmitting an RTA packet with unsolicited retries on multiple links when the BA is allowed.
- This example scenario arises when the LLTS Retransmission Policy is set to “unsolicited retry with BA” and the packet duplication on multi-link is allowed.
- the network topology of this example is again that shown in FIG. 6.
- Transmitter MLD 1 571 is to transmit several RTA packets to
- Receiver MLD 2 (AP) (not shown) over multiple links.
- STA3572 of MLD1 transmits packets to STA5 (not shown) of MLD2 over Link1 and STA4574 of MLD1 transmits packets to STA6 (not shown) over Link2.
- the unsolicited retry is allowed for transmitting the RTA packets over multiple links.
- STA3 obtains the channel access and reserves the TXOP duration 582 on Link1 first.
- STA1 is able to transmit the initial transmissions 652, 656, 660 and 664 of the RTA packets (#1 , #2, #3 and #4) during the TXOP on Link1.
- the time between two packet transmissions can be any desired interframe spacing, such as xlFS, SIFS, PIFS, or other spacing whose duration can be fixed (deterministic).
- STA4 obtains and reserves the TXOP duration 584 on Link2 before the end of TXOP on Link1 by the end of the TXOP on Link1.
- STA4 transmits the retransmissions 654, 658, 662 of the RTA packets whose initial transmissions are transmitted during the TXOP on Link1.
- the time between two packet transmissions can be an interframe spacing, such as xlFS, SIFS, PIFS, or other spacing mechanism.
- STA4 in this example decides to transmit a BAR frame 666 to request BA feedback from STA6 before the end of the TXOP.
- the BA feedback 668 should contain packet loss information of both links.
- the BA frame could indicate that the initial transmissions of RTA packet #1 , #3, and #4 on Link1 are successful while the initial transmissions of RTA packet #2 failed. The first retransmission of RTA packet #1 and packet #3 are successful but that the first retransmission of RTA packet #2 fails.
- the BA in this example may be not transmitted for retransmissions but for adaptations, such as rate adaptation and unsolicited retry limit, of RTA packet transmissions in the future.
- the BA can also be used to choose which links will be selected for transmitting RTA packets and their unsolicited retry to satisfy the packet loss requirement of the RTA traffic.
- the number of backoff slots on the two links can be the same.
- STA3 and STA4 gain channel access at different times due to CCA busy time during counting down the backoff.
- the BAR and BA frame format are shown in FIG. 33 and FIG. 34.
- FIG. 30 illustrates an example embodiment 670 as Example 6-3 of a STA transmitting an RTA packet with unsolicited retry on multiple links when the BA is allowed.
- This example scenario arises when the LLTS Retransmission Policy is set to “unsolicited retry” and the packet duplication on multi-link is allowed.
- the network topology of this example is that shown in FIG. 6.
- Transmitter MLD 1 571 is to transmit several RTA packets to
- Receiver MLD 2 (AP) (not shown) over multiple links.
- STA3572 of MLD1 transmits packets to STA5 (not shown) of MLD2 over Link1 and STA4574 of MLD1 transmits packets to STA6 (not shown) over Link2.
- the unsolicited retry is allowed for transmitting RTA packets over multiple links.
- RTA packets arrive 576 and STA3 and STA4 start to contend 578, 580 for the channel on Link1 and Link2 at the same time.
- STA3 obtains the 1st TXOP duration 582 on Link1.
- STA3 is able to transmit the initial transmissions 672, 676, 680 and 684 of the RTA packets (#1 , #2, #3 and #4) during the TXOP on Link1.
- the time between two packet transmissions can be an interframe spacing xlFS, SIFS, PIFS, or similar spacing mechanism.
- STA4 obtains and reserves the TXOP duration on Link2 before the end of 1st TXOP 582 on Link1.
- STA4 transmits 674, 678 and 682 the retransmissions of the RTA packets (#1 , #2 and #3) whose initial transmissions were transmitted during the 1st TXOP on Link1.
- the time between two packet transmissions can be an interframe spacing, such as xlFS, SIFS, PIFS, or similar spacing mechanism.
- STA4 may not be able to retransmit all the RTA packets since the TXOP duration on Link2 is not of sufficient duration. For example, as shown in this example, the first retransmission of RTA packet #4 is not transmitted over Llnk2 since it cannot be transmitted within TXOP interval 584.
- STA3 and STA4 in this example reset their backoffs 686, 688 to contend for the channel on Link1 and Link2 simultaneously.
- the number of backoff slots on the two links can be the same.
- STA3 and STA4 gain the channel at different times due to CCA busy time during counting down the backoff.
- STA4 and STA3 also obtain the 2nd TXOP as shown in the figure.
- STA4 obtains the second TXOP on Link2690 and transmits 692 the retransmissions of the RTA packet #4.
- STA3 obtains the second TXOP 694 continues to transmit the initial transmissions 696, 700 and 704 on Link1 of for sending packets #5, #6 and #7.
- STA4 is seen performing retransmissions 698, 702 and 706 on Link2 for sending RTA packets #5, #6 and #7 whose first transmission is in the 2 nd TXOP on Link1. It should be noted that during the second TXOP on Link2, if the lifetime of RTA packet #4 does not expire, then STA4 can transmit its retransmission, such as a first retransmission of RTA packet #4, during the 2nd TXOP.
- FIG. 31 illustrates an example embodiment 710 as Example 7 of a STA transmitting an RTA packet with unsolicited retries on multiple links when a BA is allowed.
- This example scenario arises when the LLTS Retransmission Policy is set to “unsolicited retry with BA” and the packet duplication in multi-link is allowed.
- the network topology of this example is shown in FIG. 6.
- Transmitter MLD 1 571 is to transmit several RTA packets to
- Receiver MLD 2 (AP) (not shown) over multiple links.
- STA3572 of MLD1 transmits packets to STA5 (not shown) of MLD2 over Link1 and STA4574 of MLD1 transmits packets to STA6 (not shown) over Link2.
- the unsolicited retry is allowed for transmitting the RTA packets over multiple links.
- STA3 and STA4 obtain channel access and reserve TXOP duration on Link1 582 and Link2 584 at the same time.
- STA1 transmits the initial transmissions 712, 716, 720 and 724 of RTA packets (#1 , #2, #3 and #4) during the TXOP on Link1.
- STA4 transmits 714, 718 and 722 on Link2 of the retransmissions of RTA packets (#1, #2 and #3) whose initial transmissions were transmitted during this same TXOP on Link1.
- the time between two packet transmissions can be an interframe spacing xlFS, SIFS, PIFS, or similar spacing mechanism whose duration can be fixed (deterministic).
- STA3 and STA4 can decide to transmit a BAR frame 724, 726 to request BA feedback from STA5 and STA6 before the end of the TXOP.
- the BAR and BA frames transmitted over Link2 are identical to those transmitted over Link1.
- the BA feedback 728, 730 preferably contains packet loss information for both links.
- the BA frame could indicate that the initial transmissions of RTA packet #1 and #3 on Link1 were successful while the initial transmissions of RTA packet #2 failed, and similarly that the first retransmission of RTA packet #1 and #2 were successful but the first retransmission of RTA packet #3 failed.
- the BA in this example may be not transmitted for retransmissions but for adaptations, such as rate adaptation and unsolicited retry limit, of the RTA packet transmissions in the future.
- the BA could also be used to choose which links will be used for transmitting RTA packets and their unsolicited retry to satisfy the packet loss requirement of the RTA traffic.
- the number of backoff slots on the two links can be the same. It should be noted that it is possible that STA3 and STA4 gain channel access on Link 1 and 2 at the same time when one backoff time count reaches zero and the STAs wait another PIFS time to access the both links.
- the BAR and BA frame format are shown in FIG. 33 and FIG. 34. It is possible that the BAR and BA frame may only carry the BA information of the link which the BAR and BA frames are transmitted. For example, the BAR and BA frame transmitted on Link1 may only carry the BA information of Link1.
- FIG. 32 illustrates an example embodiment 750 as Example 8 of a STA transmitting an RTA packet with unsolicited retry on multiple links.
- the network topology of this example is shown in FIG. 6.
- AP MLD 1 571 is to receive several RTA packets from MLD 2 (non- AP) (not shown) over multiple links.
- STA3 572 of MLD1 associates with STA5 (not shown) of MLD2 over Link1 and STA4 574 of MLD1 associates with STA6 (not shown) over Link2.
- the unsolicited retry is allowed for transmitting the RTA packets over multiple links.
- STA3 and STA4 start to contend 578, 580 for the channel on Link1 and Link2 at the same time when they know that RTA packets have arrived in the queues.
- STA3 and STA4 obtain channel access and reserve the TXOP duration on Link1 582 and Link2 584 at the same time.
- STA3 and STA4 transmit identical trigger frames (TFs) 752, 754 to STA5 and STA6, respectively.
- TFs trigger frames
- STA5 and STA6 receive the trigger frames, STA5 transmits 756, 760 the initial transmissions of the RTA packets #2 and #3, during the TXOP on Link1.
- STA6 transmits 758, 762 the retransmissions of the RTA packets #2 and #3 whose initial transmissions are being transmitted during the TXOP on Link1.
- the time between two packet transmissions can be an interframe spacing, such as xlFS, SIFS, PIFS, or similar spacing mechanism whose duration can be fixed (deterministic).
- TF can be similar to the TF defined in IEEE 802.11 ax.
- STA3 and STA4 can gain channel access at different times. If the end of the TFs on both links can be aligned, the uplink transmissions and retransmissions over the two links can occur as shown in this example. It is possible that the number of backoff slots on the two links may be the same.
- FIG. 33 illustrates an example embodiment 770 of a format for the Block Acknowledgement Request (BAR) frame.
- the purpose of this frame is to request the Block Acknowledge (BA) information on multiple links in one BA exchange. Meanwhile, the BA information exchange on each link can still follow the current IEEE 802.11 protocol, but is not limited to using that mechanism.
- the BAR frame contains the following fields.
- a Frame Control field indicates the type of frame.
- a Duration field contains NAV information used for CSMA/CA channel access.
- An RA field contains an address for a recipient of the frame.
- a TA field contains the address of the STA that transmitted the frame.
- a BA Control field indicates the type of BA request and the type of block ACK request variant in the BAR information field. The format of the BA control field is shown in the lower portion of the figure.
- the bits between B5 and B11 which are reserved in BA control defined in the current IEEE 802.11 protocol are utilized in the present disclosure.
- one bit referred to as a Multi-Link Mode subfield, is used to indicate that the BAR frame is to request information for multiple links.
- the Multi-Link Mode field When the Multi-Link Mode field is set to a first state (e.g., “1”), then the BAR information field in the BAR frame will carry the corresponding BlockAckReq variants of multiple links.
- the Multi-Link Mode field When the Multi-Link Mode field is set to a second state (e.g., “0”), then the BAR information field will carry the corresponding BlockAckReq variants as defined in the current IEEE 802.11 protocol, which is shown in Table 7.
- the remaining bits of the BA control field are the same as defined in the current IEEE 802.11 protocol.
- a BAR information field is used to carry the corresponding
- BlockAckReq variant according to the setting in BA control field.
- the figure shows the format of the BAR information field when the Multi-Link Mode field is set to a first state (e.g., “1”).
- a first state e.g., “1”.
- the STA receives this BAR frame, it can send the corresponding BA information of multiple links in one BA frame.
- the subfields in the BAR information are as follows.
- a Link Information subfield indicates which link the following
- a Length subfield indicates the length of BlockAckReq variant fields with respect to the link.
- a BlockAckReq variant subfield carries the corresponding BlockAckReq variants defined in IEEE 802.11. The types of the BlockAckReq and their corresponding parameter setting in the BA control field are shown in Table 7.
- the receiver STA can respond to the corresponding BA information following the rule of current IEEE 802.11 protocol for each link and put them in one BA frame. It should be noted that the above three fields are added to the BAR information field per link.
- FIG. 34 illustrates an example embodiment 790 of a format of the BA Response frame.
- the purpose of this frame is to respond with BA information on multiple links in one BA exchange. Meanwhile, the BA information exchange on each link can still follow the current IEEE 802.11 protocol.
- a Frame Control field indicates the type of frame.
- a Duration field contains NAV information used for CSMA/CA channel access.
- An RA field contains an address for the recipient of the frame.
- a TA field contains the address of the STA that transmitted the frame.
- a BA Control field indicates the type of BA request and the type of block ACK request variant in the BAR information field. The format of the BA control field is shown in the lower portion of the figure.
- B11 are reserved in BA control defined in the current IEEE 802.11 protocol.
- the present disclosure uses one bit of those previously reserved bits as a Multi-Link Mode subfield, for indicating that the BA frame is to provide the information of multiple links.
- the Multi-Link Mode field is set to a first state (e.g., “1”), then the BA information field carries the corresponding BlockAck variants of multiple links.
- the Multi-Link Mode field is set to a second state (e.g., “0”), then the BA information field will carry the corresponding BlockAck variants as defined in the current IEEE 802.11 protocol, which is shown in Table 8.
- the remaining bits of the BA control field are preferably the same as defined in the current IEEE 802.11 protocol.
- a BA information field is used to carry the corresponding BlockAck variants according to the setting in the BA control field.
- the figure shows the format of the BA information field when the Multi-Link Mode field is set to a first state (e.g., “1”).
- a Link Info subfield indicates which link the following BlockAck variants will be applied to.
- a Length subfield indicates the length of BlockAck variant field with respect to the link.
- a BlockAck variants subfield carries the corresponding BlockAck variants defined in IEEE 802.11. The types of the BlockAck and their corresponding parameter settings in the BA control field is shown in Table 8.
- the receiver STA can receive packet failure information of each link from BlockAck variants fields. It should be noted that the above three fields are added to the BA information field per link.
- FIG. 35 illustrates an example embodiment 810 as Example 9 of a STA transmitting an RTA packet with unsolicited retry on multiple links.
- the network topology of this example is shown in FIG. 6.
- Transmitter MLD 1 571 is to transmit several RTA packets to
- Receiver MLD 2 (AP) (not shown) over multiple links.
- STA3572 of MLD1 transmits packets to STA5 (not shown) of MLD2 over Link1 and STA4574 of MLD1 transmits packets to STA6 (not shown) over Link2.
- the unsolicited retry is allowed for transmitting the RTA packets over multiple links.
- STA3 and STA4 start to contend 578, 580 for the channel on Link1 and Link2 at the same time.
- STA3 obtains TXOP on Link1 582 and STA4 obtains TXOP on Link2584.
- STA3 and STA4 may obtain channel access on Link1 and Link2 at different times but their end times for the TXOP are the same.
- the duration of TXOP on each link are chopped (sequenced) by Downlink periods (i.e., DL as shown in the figure) and Uplink periods (i.e., UL as shown in the figure).
- the start time of the first DL period 812, 814 on the two links can be different but the end time of those two DL periods should be aligned.
- the figure depicts interspersed UL and DL periods 816, 818, 820, 822, 824 and 826 with the end of these periods on the two links being aligned as shown in the figure.
- STA3 and STA4 can transmit duplicated TFs on both links at the same time to request the UL transmission.
- AP MLD can start another DL period 828 on both links, with backoffs 830, 832 commencing.
- STA3 transmits or receives the initial transmission of the packets over Link1 and STA4 transmits or receives the retransmission of the packets over Link2.
- the first DL periods shown in the figure can use the methods as described in previous examples, such as Example 6-1 , to align the end time of the DL periods.
- the number of backoff slots on the two links can be the same.
- STA3 and STA4 may gain the channel at different times due to CCA busy time during counting down the backoff.
- FIG. 36 illustrates an example embodiment 850 as Example 10 of a STA transmitting an RTA packet with unsolicited retries on a single link.
- FIG. 6 depicts interactions between a receiver exemplified as STA0 (AP) 852, and transmitters STA1 854 and STA2 856.
- STA0 AP
- STA0 (AP) is to receive RTA packets from STA1 and STA2.
- the unsolicited retry is allowed for transmitting the RTA packet.
- STA0 gains channel access, it sends a TF 858 to STA1 and STA2.
- the format of TF can be similar to the TF defined in IEEE 802.11 ax, but is not limited thereto.
- STAO distributes RU1 and RU3 to STA1 for RTA packet transmission and STAO distributes RU2 and RU4 to STA2 for RTA packet transmission.
- STA1 transmits a frame having a header 860 and containing the initial transmission 864 of RTA packet #1 on RU1 , and the retransmission 866 of RTA packet #1 on RU3.
- STA2 transmits a frame having a header 862 and containing the initial transmission 868 of RTA packet #2 on RU2, and a retransmission 870 of RTA packet #2 on RU4.
- STA 1 and STA2 may set the retry subfield to a first state (e.g., “1”) in the MAC headers of the initial transmission of RTA packet #1 and #2 for packet duplication detection.
- a first state e.g., “1”
- FIG. 37 illustrates an example embodiment 890 as Example 11 of a STA transmitting an RTA packet with unsolicited retries on a single link.
- FIG. 6 The network topology of this example is shown in FIG. 6 and FIG. 36 depicts interactions between a receiver exemplified as STAO (AP) 892, and transmitters STA1 894 and STA2 896.
- STAO STAO
- STAO is to transmit RTA packets to STA1 and STA2.
- the unsolicited retry is allowed for transmitting the RTA packet.
- STAO gains channel access, it sends an MU-PPDU packet to STA1 and STA2.
- the format of MU-PPDU packet could be similar to the MU PPDU defined in IEEE 802.11 ax.
- the packet is seen with header 898 with RUs utilized as follows.
- STAO uses RU1 to transmit the initial transmission 900 of RTA packet #1 and RU3 to transmit the retransmission 904 of RTA packet #1.
- STAO uses RU2 to transmit the initial transmission 902 of RTA packet #2 and RU4 to transmit the retransmission 906 of RTA packet #2.
- STAO may set the retry subfield to a first state (e.g., “1”) in the MAC headers of the initial transmission of RTA packet #1 and #2 for packet duplication detection.
- RUs may be selected for use as desired in performing transmissions and retransmissions, and are thus not limited by these specific illustrative examples.
- wireless network communication stations are preferably implemented to include one or more computer processor devices (e.g., CPU, microprocessor, microcontroller, computer enabled ASIC, etc.) and associated memory storing instructions (e.g., RAM, DRAM, NVRAM, FLASH, computer readable media, etc.) whereby programming (instructions) stored in the memory are executed on the processor to perform the steps of the various process methods described herein.
- computer processor devices e.g., CPU, microprocessor, microcontroller, computer enabled ASIC, etc.
- memory e.g., RAM, DRAM, NVRAM, FLASH, computer readable media, etc.
- Embodiments of the present technology may be described herein with reference to flowchart illustrations of methods and systems according to embodiments of the technology, and / or procedures, algorithms, steps, operations, formulae, or other computational depictions, which may also be implemented as computer program products.
- each block or step of a flowchart, and combinations of blocks (and/or steps) in a flowchart, as well as any procedure, algorithm, step, operation, formula, or computational depiction can be implemented by various means, such as hardware, firmware, and / or software including one or more computer program instructions embodied in computer-readable program code.
- any such computer program instructions may be executed by one or more computer processors, including without limitation a general purpose computer or special purpose computer, or other programmable processing apparatus to produce a machine, such that the computer program instructions which execute on the computer processor(s) or other programmable processing apparatus create means for implementing the function(s) specified.
- blocks of the flowcharts, and procedures, algorithms, steps, operations, formulae, or computational depictions described herein support combinations of means for performing the specified function(s), combinations of steps for performing the specified function(s), and computer program instructions, such as embodied in computer-readable program code logic means, for performing the specified function(s).
- each block of the flowchart illustrations, as well as any procedures, algorithms, steps, operations, formulae, or computational depictions and combinations thereof described herein can be implemented by special purpose hardware-based computer systems which perform the specified function(s) or step(s), or combinations of special purpose hardware and computer-readable program code.
- these computer program instructions may also be stored in one or more computer-readable memory or memory devices that can direct a computer processor or other programmable processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory or memory devices produce an article of manufacture including instruction means which implement the function specified in the block(s) of the flowchart(s).
- the computer program instructions may also be executed by a computer processor or other programmable processing apparatus to cause a series of operational steps to be performed on the computer processor or other programmable processing apparatus to produce a computer-implemented process such that the instructions which execute on the computer processor or other programmable processing apparatus provide steps for implementing the functions specified in the block(s) of the flowchart(s), procedure (s) algorithm(s), step(s), operation(s), formula(e), or computational depiction(s).
- program executable refer to one or more instructions that can be executed by one or more computer processors to perform one or more functions as described herein.
- the instructions can be embodied in software, in firmware, or in a combination of software and firmware.
- the instructions can be stored local to the device in non-transitory media, or can be stored remotely such as on a server, or all or a portion of the instructions can be stored locally and remotely. Instructions stored remotely can be downloaded (pushed) to the device by user initiation, or automatically based on one or more factors.
- processor hardware processor, computer processor, central processing unit (CPU), and computer are used synonymously to denote a device capable of executing the instructions and communicating with input/output interfaces and/or peripheral devices, and that the terms processor, hardware processor, computer processor, CPU, and computer are intended to encompass single or multiple devices, single core and multicore devices, and variations thereof.
- An apparatus for wireless communication in a network comprising: (a) a wireless communication circuit configured as a first wireless station for wirelessly communicating over at least one channel with at least one other wireless station on a local area network (WLAN) in a reception area of the first wireless station; (b) said first wireless station including a processor configured for operating on the WLAN; (c) a non- transitory memory storing instructions executable by the processor; and (d) wherein said instructions, when executed by the processor, perform steps comprising: (d)(i) operating said wireless communication circuit as a wireless local area network (WLAN) station configured to support communicating real-time application (RTA) packets that are sensitive to communication delays as well as non-real time packets over a network supporting carrier sense multiple access/collision avoidance (CSMA / CA) in which real time application (RTA) traffic and non-RTA traffic coexist and RTA traffic is given a higher priority of transmission than lower priority traffic; (d)(ii) distinguishing real-time application (RT
- An apparatus for wireless communication in a network comprising: (a) a wireless communication circuit configured as a first wireless station for wirelessly communicating over at least one channel with at least one other wireless station on a local area network (WLAN) in a reception area of the first wireless station; (b) said first wireless station including a processor configured for operating on the WLAN; (c) a non- transitory memory storing instructions executable by the processor; and (d) wherein said instructions, when executed by the processor, perform steps comprising: (d)(i) operating said wireless communication circuit as a wireless local area network (WLAN) station configured to support communicating real-time application (RTA) packets that are sensitive to communication delays as well as non-real time packets over a network supporting carrier sense multiple access/collision avoidance (CSMA / CA) and multi-link operations, and in which real time application (RTA) traffic and non-RTA traffic coexist and RTA traffic is given a higher priority of transmission than lower priority traffic; (d)(ii) distinguish
- An apparatus for wireless communication in a network comprising: (a) a wireless communication circuit configured as a first wireless station for wirelessly communicating over at least one channel with at least one other wireless station on a local area network (WLAN) in a reception area of the first wireless station; (b) said first wireless station including a processor configured for operating on the WLAN; (c) a non- transitory memory storing instructions executable by the processor; and (d) wherein said instructions, when executed by the processor, performing:
- a wireless local area network (WLAN) station configured to support communicating real-time application (RTA) packets that are sensitive to communication delays as well as non-real time packets over a network supporting carrier sense multiple access/collision avoidance (CSMA / CA) and multi-link operations, in which real time application (RTA) traffic and non-RTA traffic coexist and RTA traffic is given a higher priority of transmission than lower priority traffic;
- RTA real time application
- non-RTA distinguishing real-time application (RTA) packets from non- real-time application (non-RTA) packets;
- MLD
- STA sets up a block ACK agreement to receive the feedback for adaptation of the packet transmission in the future; (d) STA drops an RTA packet if the retry count of that packet exceeds the unsolicited retry limit or the lifetime of that packet expires.
- RTA real time application
- RTA real time application
- LLTS low latency transmission service
- a PPDU is a Physical Layer Conformance Procedure (PLCP) Protocol Data Unit (PPDU); and wherein said instructions when executed by the processor further performing enabling an Access Point (AP) station to retransmit RTA packets under said unsolicited retry policy by transmitting the initial transmission of the RTA packet on a Resource Unit (RU) of a Multi-User (MU) PPDU packet and its retransmission on another RU of that MU-PPDU packet.
- PLCP Physical Layer Conformance Procedure
- AP Access Point
- a PPDU is a Physical Layer Conformance Procedure (PLCP) Protocol Data Unit (PPDU); and wherein said instructions when executed by the processor further performs enabling a non-access point station to retransmit RTA packets under said unsolicited retry policy by transmitting an initial transmission of an RTA packet on a Resource Unit (RU) of a trigger based (TB) PPDU packet and its retransmission on another RU of that TB-PPDU packet.
- PLCP Physical Layer Conformance Procedure
- PPDU Protocol Data Unit
- block acknowledgement (BA) frames received by the multi-link device (MLD) on one link is configured to contain packet loss information for said first link and said other links.
- Phrasing constructs such as “A, B and/or C”, within the present disclosure describe where either A, B, or C can be present, or any combination of items A, B and C.
- references in this specification referring to “an embodiment”, “at least one embodiment” or similar embodiment wording indicates that a particular feature, structure, or characteristic described in connection with a described embodiment is included in at least one embodiment of the present disclosure. Thus, these various embodiment phrases are not necessarily all referring to the same embodiment, or to a specific embodiment which differs from all the other embodiments being described.
- the embodiment phrasing should be construed to mean that the particular features, structures, or characteristics of a given embodiment may be combined in any suitable manner in one or more embodiments of the disclosed apparatus, system or method.
- Phrasing constructs such as “A, B and/or C”, within the present disclosure describe where either A, B, or C can be present, or any combination of items A, B and C.
- references in this specification referring to “an embodiment”, “at least one embodiment” or similar embodiment wording indicates that a particular feature, structure, or characteristic described in connection with a described embodiment is included in at least one embodiment of the present disclosure. Thus, these various embodiment phrases are not necessarily all referring to the same embodiment, or to a specific embodiment which differs from all the other embodiments being described.
- the embodiment phrasing should be construed to mean that the particular features, structures, or characteristics of a given embodiment may be combined in any suitable manner in one or more embodiments of the disclosed apparatus, system or method.
- a set refers to a collection of one or more objects.
- a set of objects can include a single object or multiple objects.
- the terms “approximately”, “approximate”, and “substantially” and “about” are used to describe and account for small variations. When used in conjunction with an event or circumstance, the terms can refer to instances in which the event or circumstance occurs precisely as well as instances in which the event or circumstance occurs to a close approximation.
- the terms can refer to a range of variation of less than or equal to ⁇ 10% of that numerical value, such as less than or equal to ⁇ 5%, less than or equal to ⁇ 4%, less than or equal to ⁇ 3%, less than or equal to ⁇ 2%, less than or equal to ⁇ 1 %, less than or equal to ⁇ 0.5%, less than or equal to ⁇ 0.1 %, or less than or equal to ⁇ 0.05%.
- substantially aligned can refer to a range of angular variation of less than or equal to ⁇ 10°, such as less than or equal to ⁇ 5°, less than or equal to ⁇ 4°, less than or equal to ⁇ 3°, less than or equal to ⁇ 2°, less than or equal to ⁇ 1 °, less than or equal to ⁇ 0.5°, less than or equal to ⁇ 0.1 °, or less than or equal to ⁇ 0.05°.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Description
Claims
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202180006629.5A CN114731710A (en) | 2020-05-11 | 2021-05-03 | Replication of RTA packets in time and frequency |
KR1020227037908A KR20220162757A (en) | 2020-05-11 | 2021-05-03 | RTA Packet Replication in Time and Frequency |
EP21805267.8A EP4118923A4 (en) | 2020-05-11 | 2021-05-03 | Rta packet duplication in time and frequency |
JP2022562047A JP7427170B2 (en) | 2020-05-11 | 2021-05-03 | In-time and in-frequency RTA packet duplication |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US202063022692P | 2020-05-11 | 2020-05-11 | |
US63/022,692 | 2020-05-11 | ||
US17/116,072 US11516846B2 (en) | 2020-05-11 | 2020-12-09 | RTA packet duplication in time and frequency |
US17/116,072 | 2020-12-09 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2021231121A1 true WO2021231121A1 (en) | 2021-11-18 |
Family
ID=78413474
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2021/030475 WO2021231121A1 (en) | 2020-05-11 | 2021-05-03 | Rta packet duplication in time and frequency |
Country Status (6)
Country | Link |
---|---|
US (1) | US11516846B2 (en) |
EP (1) | EP4118923A4 (en) |
JP (1) | JP7427170B2 (en) |
KR (1) | KR20220162757A (en) |
CN (1) | CN114731710A (en) |
WO (1) | WO2021231121A1 (en) |
Families Citing this family (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11452135B2 (en) * | 2018-05-23 | 2022-09-20 | Lg Electronics Inc. | Method and device for transmitting and receiving PPDU on basis of FDD in wireless LAN system |
US11706128B2 (en) * | 2020-01-04 | 2023-07-18 | Nxp Usa, Inc. | Method and apparatus for multi-link data transmission |
US20210274489A1 (en) * | 2020-05-20 | 2021-09-02 | Juan Fang | Enhanced retransmission mechanism using multi-link capability |
CN111641970B (en) * | 2020-05-29 | 2022-08-19 | 成都极米科技股份有限公司 | Method for receiving and transmitting data by using multilink through terminal and terminal |
US11924774B2 (en) * | 2020-09-02 | 2024-03-05 | Lg Electronics Inc. | Method for transmitting preferred link information |
US20210112615A1 (en) * | 2020-12-18 | 2021-04-15 | Po-Kai Huang | Multi-link device data continuity |
CN116684315B (en) * | 2021-02-04 | 2024-06-18 | 华为技术有限公司 | Service indication method and device |
JP7519538B2 (en) * | 2021-02-23 | 2024-07-19 | 華為技術有限公司 | Method and apparatus for link operation of multi-link devices - Patents.com |
US20230156687A1 (en) * | 2021-11-16 | 2023-05-18 | Sony Group Corporation | Non-r-twt member sta access grant for burst traffic transmission |
US20230180047A1 (en) * | 2021-12-07 | 2023-06-08 | Qualcomm Incorporated | Dynamic selection of parameters for enhanced quality of service (qos) and reliability |
US20230422316A1 (en) * | 2022-06-28 | 2023-12-28 | Samsung Electronics Co., Ltd. | Methods and procedure for nstr start time synchronization |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1686716A1 (en) * | 2005-02-01 | 2006-08-02 | NTT DoCoMo INC. | Communication system, transmitter and receiver with adaptive retransmission depending on the type of data |
US20200099482A1 (en) * | 2017-05-31 | 2020-03-26 | Huawei Technologies Co., Ltd. | Packet Retransmission Method and Apparatus |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1134942A1 (en) | 2000-03-15 | 2001-09-19 | Telefonaktiebolaget L M Ericsson (Publ) | Method and arrangement for control of non real-time application flows |
JP4065393B2 (en) | 2001-11-09 | 2008-03-26 | 松下電器産業株式会社 | Method for ensuring access to a medium in a wireless network |
WO2003040866A2 (en) | 2001-11-09 | 2003-05-15 | Matsushita Electric Industrial Co., Ltd. | Methods for ensuring medium access in a wireless network |
KR20050035294A (en) | 2002-09-06 | 2005-04-15 | 마츠시타 덴끼 산교 가부시키가이샤 | Methods for performing medium dedication in order to ensure the quality of service for delivering real-time data across wireless network |
KR100564761B1 (en) * | 2003-12-22 | 2006-03-27 | 한국전자통신연구원 | The hybrid inter token Carrier Sensing Multiple Access/Collision Avoidance protocol |
JP2006352545A (en) | 2005-06-16 | 2006-12-28 | Nippon Telegr & Teleph Corp <Ntt> | Method and device of wireless packet communication |
US10356014B2 (en) * | 2013-09-24 | 2019-07-16 | Innovasic, Inc. | Method of processing bus data |
US9913298B2 (en) * | 2015-06-24 | 2018-03-06 | Intel IP Corporation | Methods and apparatus to establish groupcast with retries service for wireless communications over bridged links |
US10673593B2 (en) * | 2016-11-03 | 2020-06-02 | Huawei Technologies Co., Ltd. | HARQ signaling for grant-free uplink transmissions |
-
2020
- 2020-12-09 US US17/116,072 patent/US11516846B2/en active Active
-
2021
- 2021-05-03 WO PCT/US2021/030475 patent/WO2021231121A1/en unknown
- 2021-05-03 CN CN202180006629.5A patent/CN114731710A/en active Pending
- 2021-05-03 EP EP21805267.8A patent/EP4118923A4/en active Pending
- 2021-05-03 JP JP2022562047A patent/JP7427170B2/en active Active
- 2021-05-03 KR KR1020227037908A patent/KR20220162757A/en unknown
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1686716A1 (en) * | 2005-02-01 | 2006-08-02 | NTT DoCoMo INC. | Communication system, transmitter and receiver with adaptive retransmission depending on the type of data |
US20200099482A1 (en) * | 2017-05-31 | 2020-03-26 | Huawei Technologies Co., Ltd. | Packet Retransmission Method and Apparatus |
Non-Patent Citations (4)
Title |
---|
"A Survey of Medium Access Mechanisms for Providing Robust Audio Video Streaming in IEEE 802.11 aa Standard", IEEE ACCESS, vol. 6, pages 27690 - 27705 |
KSENTINI ET AL.: "Toward an Improvement of H.264 Video Transmission over IEEE 802.11E Through a Cross Layer Architecture", IEEE COMMUNICATION MAGAZINE, January 2006 (2006-01-01), pages 107 - 114, XP001238792, DOI: 10.1109/MCOM.2006.1580940 |
LASELVA, DANIELA ET AL.: "Deliverable D3.2 Recommended Multi-Service Performance Optimization Solutions for Improved E2E Performance", CALL:H2020- ICT-2016-2, PROJECT REFERENCE: 760809, PROJECT NAME: E2E-AWARE OPTIMIZATIONS AND ADVANCEMENTS FOR NETWORK EDGE OF 5G NEW RADIO (ONE5G, 31 May 2019 (2019-05-31), pages 33,48,53,54,110, XP055713455, Retrieved from the Internet <URL:https://one5g.eu/wp-content/uploads/2019/07/ONE5G-D3.2.pdf> [retrieved on 20210707] * |
See also references of EP4118923A4 |
Also Published As
Publication number | Publication date |
---|---|
CN114731710A (en) | 2022-07-08 |
EP4118923A4 (en) | 2023-08-09 |
US20210352722A1 (en) | 2021-11-11 |
JP2023521173A (en) | 2023-05-23 |
KR20220162757A (en) | 2022-12-08 |
EP4118923A1 (en) | 2023-01-18 |
US11516846B2 (en) | 2022-11-29 |
JP7427170B2 (en) | 2024-02-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11516846B2 (en) | RTA packet duplication in time and frequency | |
CN113812205B (en) | MU-MIMO packet pre-arrival channel contention | |
EP2304890B1 (en) | Apparatus for requesting acknowledgement and transmitting acknowledgement of multicast data in wireless local area networks | |
KR20230035086A (en) | Request trigger frame and TXOP sharing initiated by non-AP STA | |
US11178694B2 (en) | RTA queue management in wireless local area network (WLAN) stations | |
US11122624B2 (en) | Pre-packet arrival channel contention | |
CN113875272B (en) | Real-time application | |
US20230058871A1 (en) | Stream classification service (scs) with restricted target wait time (r-twt) setup | |
US20220322460A1 (en) | Sharing an edca txop with rta traffic | |
WO2022208211A2 (en) | Sharing an edca txop with rta traffic | |
CN114303411B (en) | TS operation for RTA session management | |
JP2023521087A (en) | EDCA queue for RTA packets | |
EP4233457A1 (en) | Coordinated wifi stations with shared txop among dl and ul over time domain | |
US20230403741A1 (en) | Transmitting and receiving via remote radio head |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 21805267 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 2022562047 Country of ref document: JP Kind code of ref document: A |
|
ENP | Entry into the national phase |
Ref document number: 2021805267 Country of ref document: EP Effective date: 20221011 |
|
ENP | Entry into the national phase |
Ref document number: 20227037908 Country of ref document: KR Kind code of ref document: A |
|
NENP | Non-entry into the national phase |
Ref country code: DE |