Method and system for UHR trigger frame design
New UHR trigger frame formats with expanded fields address the bit limitations in existing IEEE 802.11bn standards, enabling UHR features while ensuring backward compatibility and future expandability.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-12-03
- Publication Date
- 2026-03-12
AI Technical Summary
Existing trigger frame formats in the IEEE 802.11bn standard lack sufficient reserved bits for accommodating Ultra-High Reliability (UHR) features, particularly in the Common Info, Special User Info, and User Info fields, limiting backward compatibility and future expansion.
Introduce new UHR trigger frame formats with additional fields in the Common Info, Special User Info, and User Info fields, utilizing reserved values and expanding existing fields to accommodate UHR features while maintaining backward compatibility.
Enables the inclusion of UHR features in trigger frames without disrupting existing network operations, providing enhanced capabilities for future network enhancements.
Smart Images

Figure CN2024136505_12032026_PF_FP_ABST
Abstract
Description
METHOD AND SYSTEM FOR UHR TRIGGER FRAME DESIGNCROSS-REFERENCE TO RELATED APPLICATION
[0001] This application claims the benefit of priority to U.S. Provisional Patent Application No. 63 / 690, 566, filed on 4 September 2024, the contents of which are incorporated herein by reference, in their entirety.TECHNICAL FIELD
[0002] The present disclosure pertains to the field of communication networks, and in particular to methods and systems for structuring a trigger frame in a communication network.BACKGROUND
[0003] Trigger frames are poised to be a cornerstone of the IEEETM 802.11bn standard, serving as a versatile mechanism for a wide range of advanced network operations. Numerous proposals underscore the pivotal role of trigger frames in facilitating Ultra-High Reliability (UHR) features, such as, for example, triggering a trigger-based (TB) Physical Layer Data Unit (PPDU) , multi-access point (AP) coordination, in-device coexistence management, dynamic power saving, dynamic sub-band operation, and non-primary channel access. These enhancements are desirable for the evolution of the IEEETM 802.11bn standard, to allow the standard to support the growing demands for UHR features and adaptability in wireless local area networks (WLANs) .
[0004] The primary focus has been on several specific types of trigger frames with their own format. Such trigger frames include, for example, trigger frames, Multi-User (MU) Request-to-Send (RTS) trigger frames, MU-RTS Transmit Opportunity Sharing (TXS) trigger frames, Buffer Status Report Poll (BSRP) trigger frames, Bandwidth Query Report Poll (BQRP) trigger frames, and Beamforming Report Poll (BFRP) trigger frames. These trigger frame types are important for the efficient functioning of various network operations.
[0005] Therefore, improvements in trigger frames that would allow backward compatibility with existing trigger frame formats and provide UHR features are desirable.SUMMARY
[0006] In order to accommodate at least some of these new Ultra-High Reliability (UHR) features, embodiments disclosed herein provide for new trigger frames using new trigger types, new trigger subtypes, or a combination of a new trigger types and a new trigger subtypes. One or more reserved value (s) from value 9 to 15 may be utilized in the type subfield in the Common Info field to define these new trigger frame types.
[0007] In order to maintain backward compatibility, existing trigger frame format is proposed to be reused for the UHR variant. However, enabling these new features necessitates the definition of several additional fields for the Common Info, Special User Info, and User Info fields in trigger frames for IEEETM802.11bn standard.
[0008] For EH / EHT Trigger frame variants (except for Multi-User Request-to-Send (MU-RTS) and MU-RTS Transmit Opportunity Sharing (TXS) ) , there are too few reserved bits remaining in the Common Info field.
[0009] In the IEEETM 802.11be standard, the Special User Info field (Associated Identifier AID12=2007) was proposed for expansion of EHT variant Common Info, but also has only 3 reserved bits remaining.
[0010] Regarding the EH / EHT User Info variants, they have only 1 reserved bit after the MCS field and it is not recommended to be utilized now for potential MCS expansion.
[0011] Based on the current HE / EHT User Info format, there is not enough space to accommodate any UHR features.
[0012] Other potential UHR info may also need to be added in the future. In this case, more bits will be needed within the UHR User Info field.
[0013] In summary, the main limitations of the existing trigger frame format include the Common Info having limited reserved bits for EH / EHT trigger frame variants; the Special User Info having only 3 reserved bits for EHT variant expansion; the User Info having no available space for UHR features without impacting existing functionality (e.g., MCS) ; and the Additional UHR Features needing more bits in the User Info field for future UHR information, as anticipated.
[0014] The primary focus has been on several specific types of trigger frames, including basic Trigger Frame (TF) , MU-RTS, MU-RTS TXS, Buffer Status Report Poll (BSRP) , Bandwidth Query Report Poll (BQRP) , and Beamforming Report Poll (BFRP) . These trigger frame types are important for the efficient functioning of various network operations.
[0015] To maintain backward compatibility, existing trigger frame format is proposed to be reused for the UHR variant. However, enabling these new features necessitates the definition of several additional fields for the Common Info, Special User Info, and User Info fields in trigger frames for IEEETM 802.11bn standard.
[0016] In this disclosure, a novel UHR trigger frame is provided by introducing: UHR variant Common Info field, UHR variant Special User Info field, UHR variant Extended Special User Info field, 10-byte UHR variant Special User Info field, UHR variant User Info field, UHR variant Extended User Info field, and 10-byte UHR variant User Info field.
[0017] In this disclosure, novel UHR trigger frame format is provided by reformulating one or more subfields of the Common Info, Special User Info, and User Info fields within the existing trigger frame to accommodate potential UHR supported features and capabilities while maintaining backward capability.
[0018] Relevant technical terms include IEEETM 802.11 standard, Equal / Unequal Modulation (EQM / UEQM) , Trigger-based Aggregated Physical Layer Data Unit (TB PPDU) , Trigger Frame (TF) , Ultra-High Reliability, Wireless Local Area Network (WLAN) .
[0019] In a first aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a UHR Common info field, the UHR Common info field having a format of an Extremely High Throughput (EHT) Common info field. the UHR Common info field has bit 54 indicating a presence of one of: a High Efficiency (HE) physical layer data unit (PPDU) in a 160 MHz primary channel, and a non-HE PPDU in the 160 MHz primary channel. The UHR Common info field has at least some of bits 22, 26, 53, and 56 to 63 defining common UHR capabilities. The method also comprises transmitting the UHR trigger frame to a client device.
[0020] In implementations of the first aspect, bit 54 may indicate, in accordance with a value of a physical version identifier in a Special User info field, one of an EHT PPDU and a UHR or beyond PPDU.
[0021] In implementations of the first aspect, the common UHR capabilities may include at least one of: distributed resource unit info, an intermediate FCS presence flag, and an initial control frame Special info field presence indication.
[0022] In implementations of the first aspect, forming the UHR trigger frame may comprise including, in the UHR trigger frame, an extended common info field to define further common UHR capabilities, and setting one bit among bits 56 to 63 to indicate a presence of the extended common info field.
[0023] In implementations of the first aspect, the UHR trigger frame may have a trigger type field, and the method may further comprise: setting bits 9-15 of the trigger type field to indicate a new trigger type.
[0024] In a second aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a UHR Special User info field, the UHR Special User info field having an Extremely High Throughput (EHT) Special User info field format. The UHR Special User info field has a twelve-bit Association Identifier (AID12) field with a value set to 2007. The UHR Special User info field has a physical layer (PHY) version identifier with a value of ‘1’ to indicate physical protocol data units (PPDUs) are to have a UHR format, and bits 37 to 39 being set to define UHR common info. The method further comprises transmitting the UHR trigger frame to a client device.
[0025] In implementations of the second aspect, the UHR common info may includes at least one of: a non-primary channel access indication, a dynamic sub-band operation indication, distributed resource unit Info, an extended ICF Special Info field presence indication, and multi-access point coordination info.
[0026] In a third aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a UHR Special User info field, the UHR Special User info field having an Extremely High Throughput (EHT) Special User info field format, the UHR Special User info field having a U-SIG Disregard and Validate field. The UHR Special User info field has a twelve-bit Association Identifier (AID12) field with a value set to 2007. The UHR Special User info field has a physical layer (PHY) version identifier with a value of ‘1’ to indicate physical protocol data units (PPDUs) are to have a UHR format, and bits 0 to 5 and bits 7 to 10 of the U-SIG Disregard and Validate field being set to define UHR common info. The method further comprises transmitting the UHR trigger frame to a client device.
[0027] In implementations of the third aspect, the UHR common info may include at least one of: a non-primary channel access indication, a dynamic sub-band operation indication, distributed resource unit Info, an extended ICF Special Info field presence indication, and multi-access point coordination info.
[0028] In implementations of the third aspect, wherein bits 37 to 39 of the UHR Special User info field may be set to define additional UHR common info.
[0029] In implementations of the third aspect, the additional UHR common info may include at least one of:a non-primary channel access indication, a dynamic sub-band operation indication, distributed resource unit Info, an extended ICF Special Info field presence indication, and multi-access point coordination info.
[0030] In a fourth aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame that has a UHR Special User info field. The UHR Special User info field has: an Extremely High Throughput (EHT) Special User info field format; a twelve-bit Association Identifier (AID12) field with a value set to 2007; and a physical layer (PHY) version identifier with a value of ‘1’ to indicate physical protocol data units (PPDUs) are to have a UHR format. A reserved bit of the UHR Special User info field is set to indicate a presence of an Extended UHR Special User info field. The UHR Special User info field also has the Extended UHR Special User info field. The Extended UHR Special User info field immediately follows the UHR Special User info field. The Extended UHR Special User info field is 5 bytes in length. Bits 0 to 11 of the Extended UHR Special User info field define a common AID12 field with a value not equal to 2007. Bits 12 to 39 of the Extended UHR special user info field define additional UHR info. The method further comprises transmitting the UHR trigger frame to a client device.
[0031] In implementations of the fourth aspect, the additional UHR info may include at least one of: one or more multi-access point coordination scheme, a non-primary channel access indication, a dynamic sub-band indication, and dynamic power save info.
[0032] In implementations of the fourth aspect, the one or more multi-AP coordination scheme may include at least one of: coordinated spatial reuse info, coordinated beamforming info, coordinated time division multiple access info, and coordinated restricted target wake time info.
[0033] In implementations of the fourth aspect, bits 37 to 38 may define UHR Common info, including one or more of: one or more multi-access point coordination scheme, a non-primary channel access indication, a dynamic sub-band operation indication, and dynamic power save info.
[0034] In implementations of the fourth aspect, the one or more multi-AP coordination scheme may include at least one of: coordinated spatial reuse info, coordinated beamforming info, coordinated time division multiple access info, and coordinated restricted target wake time info.
[0035] In implementations of the fourth aspect, the UHR Special User info field may have a U-SIG Disregard and Validate field, and bits 0 to 5 and bits 7 to 10 of the U-SIG Disregard and Validate field may be set to define UHR common info.
[0036] In implementations of the fourth aspect, the UHR common info may include at least one of: one or more multi-access point coordination scheme, a non-primary channel access indication, a dynamic sub-band operation indication, and dynamic power save info.
[0037] In implementations of the fourth aspect, the one or more multi-AP coordination scheme may include at least one of: coordinated spatial reuse info, coordinated beamforming info, coordinated time division multiple access info, and coordinated restricted target wake time info.
[0038] In a fifth aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a UHR Special User info field that is 10 bytes in length, a first five bytes of the UHR Special User info field having an Extremely High Throughput (EHT) Special User info field format. The UHR Special User info field has a twelve-bit Association Identifier (AID12) field with a value set to 2007. The UHR Special User info field has a physical layer (PHY) version identifier with a value of ‘1’ to indicate physical protocol data units (PPDUs) are to have a UHR format. Bit 40 of the UHR Special User info field is a disambiguation bit set to ‘0’ , and bit 51 of the UHR Special User info field being a disambiguation bit set to ‘1’ . The method further comprises transmitting the UHR trigger frame to a client device.
[0039] In implementations of the fifth aspect, at least one of: bits 41 to 50, and bits 52 to 79 may define UHR common info that may include one or more of Multi-AP coordination schemes.
[0040] In implementations of the fifth aspect, the UHR common info may include at least one of: one or more multi-access point coordination scheme, a non-primary channel access indication, a dynamic sub-band operation indication, and dynamic power save info.
[0041] In implementations of the fifth aspect, the one or more multi-AP coordination scheme includes at least one of: coordinated spatial reuse info, coordinated beamforming info, coordinated time division multiple access info, and coordinated restricted target wake time info.
[0042] In a sixth aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field. The UHR user info field includes: an equal modulation (EQM) or an unequal modulation (UEQM) pattern variation field at bits 25 to 26 of the UHR User info field; and a spatial stream (SS) allocation field at bits 27 to 31 of the user info field. The method further comprises transmitting the UHR trigger frame to a client device.
[0043] In a seventh aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field. The UHR User info field includes: at least one UHR info subfield at bits 25 to 26 of the UHR User info field; and a spatial stream (SS) allocation field at bits 27 to 31 of the UHR User info field. The method further comprises transmitting the UHR trigger frame to a client device.
[0044] In implementations of the seventh aspect, the at least one UHR info subfield may include one or more of: a modulation and coding scheme subfield, an equal modulation or unequal modulation indicator subfield, a distributed bandwidth subfield, and two low-density parity check flag subfields.
[0045] In an eighth aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field. The UHR User info field includes: an uplink (UL) target receive power field at bits 32 to 36 of the UHR User info field; and an equal modulation (EQM) or an unequal modulation (UEQM) pattern variation field at bits 37 to 38 of the user info field. The method further comprises transmitting the UHR trigger frame to a client device.
[0046] In a ninth aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field. The UHR User info field includes an equal modulation (EQM) or an unequal modulation (UEQM) pattern variation field at bits 32 to 33 of the UHR User info field; and an uplink (UL) target receive power field at bits 34 to 38 of the UHR User info field. The method further comprises transmitting the UHR trigger frame to a client device.
[0047] In a tenth aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field. Th UHR User info field includes an equal modulation (EQM) or an unequal modulation (UEQM) indicator at bit 25 of the UHR User info field, an uplink (UL) target receive power field at bits 32 to 36 of the UHR User info field, and an unequal modulation (UEQM) pattern variation field at bits 37 to 38 of the UHR User info field. The method further comprises transmitting the UHR trigger frame to a client device.
[0048] In an eleventh aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field. The UHR User info field includes an equal modulation (EQM) or an unequal modulation (UEQM) indicator at bit 25 of the UHR User info field, an unequal modulation (UEQM) pattern variation field at bits 32 to 33 of the UHR User info field, and an uplink (UL) target receive power field at bits 34 to 38 of the UHR User info field. The method further comprises transmitting the UHR trigger frame to a client device.
[0049] In a twelfth aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field. The UHR User info field includes at least one UHR info subfield at bits 32 to 33 of the UHR User info field, and an uplink (UL) target receive power field at bits 34 to 38 of the UHR User info field The method further comprises transmitting the UHR trigger frame to a client device.
[0050] In implementations of the twelfth aspect, the at least one UHR info subfield may include one or more of: a modulation and coding scheme subfield, an equal modulation or unequal modulation indicator subfield, a distributed bandwidth subfield, and two low-density parity check flag subfields.
[0051] In a thirteenth aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field. The UHR User info field includes a UHR info subfield at bit 25 and at bits 32 to 33 of the UHR User info field, and an uplink (UL) target receive power field at bits 34 to 38 of the UHR User info field. The method further comprises transmitting the UHR trigger frame to a client device.
[0052] In a fourteenth aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field. The UHR User info field includes a spatial stream (SS) allocation field at bits 26 to 30 of the UHR User info field, an uplink (UL) target receive power field at bits 33 to 38 of the UHR User info field, and an equal modulation (EQM) pattern variation field or an unequal modulation (UEQM) pattern variation field at bits 31 to 32 of the UHR User info field. The method further comprises transmitting the UHR trigger frame to a client device.
[0053] In implementations of the fourteenth aspect, bit 25 of the UHR user info field may be an indicator of a presence of the EQM pattern variation field or the UEQM pattern variation field.
[0054] In a fifteenth aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field. The UHR User info field includes a spatial stream (SS) allocation field at bits 26 to 30 of the UHR User info field, an uplink (UL) target receive power field at bits 33 to 38 of the UHR User info field, and at least one UHR info subfield at bits 31 to 32 of the UHR User info field. The method further comprises transmitting the UHR trigger frame to a client device.
[0055] In implementations of the fifteenth aspect, the at least one UHR info subfield may include one or more of: a modulation and coding scheme subfield, an equal modulation or unequal modulation indicator subfield, a distributed bandwidth subfield, and two low-density parity check flag subfields.
[0056] In implementations of the fifteenth aspect, bit 25 of the UHR user info field may be an indicator of a presence of the UHR info subfield.
[0057] In a sixteenth aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field. The UHR User info field includes a spatial stream (SS) allocation field at bits 26 to 30 of the UHR User info field, an uplink (UL) target receive power field at bits 31 to 35 of the UHR User info field, an indicator bit at bit 36, to indicate a presence of an equal modulation (EQM) pattern variation or an unequal modulation (UEQM) pattern variation. The EQM pattern variation or the UEQM pattern variation is at bits 37 to 38. The method further comprises transmitting the UHR trigger frame to a client device.
[0058] In a seventeenth aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field. The UHR User info field includes: a spatial stream (SS) allocation field at bits 26 to 30 of the UHR User info field; an uplink (UL) target receive power field at bits 34 to 38 of the UHR User info field; an indicator bit at bit 38, to indicate a presence of an equal modulation (EQM) pattern variation or an unequal modulation (UEQM) pattern variation; and the EQM pattern variation or the UEQM pattern variation at bits 32 to 33. The method further comprises transmitting the UHR trigger frame to a client device.
[0059] In an eighteenth aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field. The UHR User info field includes: a spatial stream (SS) allocation field at bits 26 to 30 of the UHR User info field; an uplink (UL) target receive power field at bits 31 to 35 of the UHR User info field; and at least one UHR info subfield at bits 36 to 38 of the UHR User info field. The method further comprises transmitting the UHR trigger frame to a client device.
[0060] In implementations of the eighteenth aspect, the at least one UHR info subfield includes one or more of: a modulation and coding scheme subfield, an equal modulation or unequal modulation indicator subfield, a distributed bandwidth subfield, and two low-density parity check flag subfields.
[0061] In a nineteenth aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field. The UHR User info field includes: a spatial stream (SS) allocation field at bits 26 to 30 of the UHR User info field; an uplink (UL) target receive power field at bits 34 to 38 of the UHR User info field; and at least one UHR info subfield at bits 31 to 33 of the UHR User info field. The method further comprises transmitting the UHR trigger frame to a client device.
[0062] In implementations of the nineteenth aspect, the at least one UHR info subfield may include one or more of: a modulation and coding scheme subfield, an equal modulation or unequal modulation indicator subfield, a distributed bandwidth subfield, and two low-density parity check flag subfields.
[0063] In a twentieth aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame that has a UHR User info field. The UHR Special User info field has: a 12-bit UHR station (STA) association identifier (AID) having a value; and bit 25 set to indicate a presence of an Extended UHR User info field. The UHR trigger frame has the Extended UHR User info field. The Extended UHR User info field has: a 12-bit UHR STA AID with a same value as the value of 12-bit UHR STA AID of the UHR User info field; two or three bits to define unequal modulation (UEQM) patter variations; and twenty five or twenty six bits defining UHR supported features. The method further comprises transmitting the UHR trigger frame to a client device.
[0064] In a twenty-first aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field. The UHR Special User info field has: a 12-bit UHR station (STA) association identifier (AID) having a value; an uplink (UL) target receive power field at bits 32 to 36 of the UHR User info field; a reserved bit at bit 37; and an indicator bit at bit 38 to indicate a presence of an Extended UHR User info field. The UHR trigger also has the Extended UHR User info field. The Extended UHR User info field has: a 12-bit UHR STA AID with a same value as the value of 12-bit UHR STA AID of the UHR User info field; two or three bits to define unequal modulation (UEQM) patter variations; and twenty five or twenty six bits defining UHR supported features. The method further comprises transmitting the UHR trigger frame to a client device.
[0065] In a twenty-second aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame that has a UHR User info field, the UHR Special User info field has: a 12-bit UHR station (STA) association identifier (AID) having a value; an uplink (UL) target receive power field at bits 32 to 37 of the UHR User info field; and an indicator bit at bit 38 to indicate a presence of an Extended UHR User info field. The UHR trigger frame also has the Extended UHR User info field. The Extended UHR User info field has: a 12-bit UHR STA AID with a same value as the value 12-bit UHR STA AID of the UHR User info field; two or three bits to define unequal modulation (UEQM) patter variations; and twenty five or twenty six bits defining at least one UHR supported feature. The method further comprises transmitting the UHR trigger frame to a client device.
[0066] In implementations of the twenty-second aspect, the at least one UHR supported feature may include at least one of: an advanced UHR or Beyond User-Specific transmitter (TX) / receiver (RX) feature, one or more multiple-access point coordination feature, a non-primary channel access feature, a dynamic sub-band operation feature, and a dynamic power save feature.
[0067] In implementations of the twenty-second aspect, the at least one multiple-access point coordination scheme may include one or more of: a coordinated spatial reuse scheme, coordinated beamforming scheme, coordinated time division multiple access scheme, and coordinated restricted target wake time scheme.
[0068] In a twenty-third aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field. The UHR Special User info field has: a 12-bit UHR station (STA) association identifier (AID) having a value; a spatial stream allocation field at bits 26 to 30 of the UHR User info field; and an indicator bit at bit 31 to indicate a presence of an Extended UHR User info field. The UHR trigger frame also has the Extended UHR User field. The Extended User info field has: a 12-bit UHR STA AID with a same value as the value of the 12-bit UHR STA AID of the UHR User info field; two or three bits to define unequal modulation (UEQM) pattern variations; and twenty-five or twenty-six bits defining UHR supported features. The method further comprises transmitting the UHR trigger frame to a client device.
[0069] In implementations of the twenty-third aspect, the at least one UHR supported feature may include at least one of: an advanced UHR or Beyond User-Specific transmitter (TX) / receiver (RX) feature, one or more multiple-access point coordination feature, a non-primary channel access feature, a dynamic sub-band operation feature, and a dynamic power save feature.
[0070] In implementations of the twenty-third aspect, the at least one multiple-access point coordination scheme may include one or more of: a coordinated spatial reuse scheme, coordinated beamforming scheme, coordinated time division multiple access scheme, and coordinated restricted target wake time scheme.
[0071] In a twenty-fourth aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame that has a UHR User info field. The UHR Special User info field has: a 12-bit UHR station (STA) association identifier (AID) having a value; a spatial stream allocation field at bits 27 to 31 of the UHR User info field; and an indicator bit at bit 26 to indicate a presence of an Extended UHR User info field. The UHR trigger frame has the Extended UHR User info field. The Extended UHR User info field has: a 12-bit UHR STA AID with a same value as the value of the 12-bit UHR STA AID of the UHR User info field; two or three bits to define unequal modulation (UEQM) patter variations; and twenty five or twenty six bits defining UHR supported features. The method further comprises transmitting the UHR trigger frame to a client device.
[0072] In implementations of the twenty-fourth aspect, the at least one UHR supported feature may include at least one of: an advanced UHR or Beyond User-Specific transmitter (TX) / receiver (RX) feature, one or more multiple-access point coordination feature, a non-primary channel access feature, a dynamic sub-band operation feature, and a dynamic power save feature.
[0073] In implementations of the twenty-fourth aspect, the at least one multiple-access point coordination scheme may include one or more of: a coordinated spatial reuse scheme, coordinated beamforming scheme, coordinated time division multiple access scheme, and coordinated restricted target wake time scheme.
[0074] In a twenty-fifth aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame that has a UHR User info field. The UHR Special User info field has: a 12-bit UHR station (STA) association identifier (AID) that has a value; a spatial stream allocation field at bits 26 to 30 of the UHR User info field; bits 31 to 32 defining EQM / UEQM pattern variations; bits 33 to 37 defining an uplink target receive power; and an indicator bit at bit 38 to indicate a presence of an Extended UHR User info field. The UHR trigger frame also has the Extended UHR User info field. The Extended UHR User info field has a 12-bit UHR STA AID with a same value as the value of the 12-bit UHR STA AID of the UHR User info field; and twenty eight bits defining UHR supported features. The method further comprises transmitting the UHR trigger frame to a client device.
[0075] In implementations of the twenty-fifth aspect, the at least one UHR supported feature may include at least one of: an advanced UHR or Beyond User-Specific transmitter (TX) / receiver (RX) feature, one or more multiple-access point coordination feature, a non-primary channel access feature, a dynamic sub-band operation feature, and a dynamic power save feature.
[0076] In implementations of the twenty-fifth aspect, the at least one multiple-access point coordination scheme includes one or more of: a coordinated spatial reuse scheme, coordinated beamforming scheme, coordinated time division multiple access scheme, and coordinated restricted target wake time scheme.
[0077] In a twenty-sixth aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame that has a UHR User info field. The UHR Special User info field has: a 12-bit UHR station (STA) association identifier (AID) having a value; a spatial stream allocation field at bits 26 to 30 of the UHR User info field; bits 31 to 32 defining EQM / UEQM pattern variations; bits 33 to 37 defining an uplink target receive power; and an indicator bit at bit 38 to indicate a presence of an Extended UHR User info field. The UHR trigger frame also has the Extended UHR User info field. The Extended UHR User info field has: a 12-bit UHR STA AID with a same value as the value of the 12-bit UHR STA AID of the UHR User info field; and twenty eight bits defining UHR supported features. The method further comprises transmitting the UHR trigger frame to a client device.
[0078] In implementations of the twenty-sixth aspect, the at least one UHR supported feature may include at least one of: an advanced UHR or Beyond User-Specific transmitter (TX) / receiver (RX) feature, one or more multiple-access point coordination feature, a non-primary channel access feature, a dynamic sub-band operation feature, and a dynamic power save feature.
[0079] In implementations of the twenty-sixth aspect, the at least one multiple-access point coordination scheme may include one or more of: a coordinated spatial reuse scheme, coordinated beamforming scheme, coordinated time division multiple access scheme, and coordinated restricted target wake time scheme.
[0080] In a twenty-seventh aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame that has a UHR User info field. The UHR Special User info field has: a 12-bit UHR station (STA) association identifier (AID) having a value; a spatial stream allocation field at bits 26 to 30 of the UHR User info field; a UHR info subfield at bits 31 to 32; bits 33 to 37 defining an uplink target receive power; and an indicator bit at bit 38 to indicate a presence of an Extended UHR User info field. The UHR trigger frame has the Extended UHR User info field. The Extended UHR User info field has: a 12-bit UHR STA AID with a same value as the value of the 12-bit UHR STA AID of the UHR User info field; and twenty eight bits defining UHR supported features. The method further comprises transmitting the UHR trigger frame to a client device.
[0081] In implementations of the twenty-seventh aspect, the at least one UHR supported feature may include at least one of: an advanced UHR or Beyond User-Specific transmitter (TX) / receiver (RX) feature, one or more multiple-access point coordination feature, a non-primary channel access feature, a dynamic sub-band operation feature, and a dynamic power save feature.
[0082] In implementations of the twenty-seventh aspect, the at least one multiple-access point coordination scheme includes one or more of: a coordinated spatial reuse scheme, coordinated beamforming scheme, coordinated time division multiple access scheme, and coordinated restricted target wake time scheme.
[0083] In a twenty-eighth aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame that has a UHR User Station (STA) info field. The UHR User STA field is 10 bytes in length. The UHR User STA info field has: bit 40 set to zero; bit 51 set to one; a first UHR info subfield at bits 41 to 50; and a second UHR info subfield at bits 52 to 79; and the method comprises transmitting the UHR trigger frame to a client device.
[0084] In implementations of the twenty-eighth aspect, the UHR User STA info field is one of: an MCS extension bit; or a TBD feature bit.
[0085] In a twenty-ninth aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a User info list. The User info list has multiple entries, each entry of the multiple entries has: a twelve-bit Association Identifier (AID12) field with a value set to 2007; a physical layer (PHY) version identifier with a value of ‘1’ to indicate physical protocol data units (PPDUs) are to have a UHR format; a Special User info field; a common AID12 set to a value not equal to 2007; and an Extended Special User info field. The Extended UHR Special User info field immediately follows the UHR Special User info field. The method further comprises transmitting the UHR trigger frame to a client device.
[0086] In a twenty-ninth aspect, the present disclosure provides a method that comprises forming an Ultra-High Reliability (UHR) trigger frame having a User info list. The User info list has multiple entries, each entry of the multiple entries has: a twelve-bit Association Identifier (AID12) field with a value set to 2007; and a 10-byte Special User info field. The method further comprises transmitting the UHR trigger frame to a client device.
[0087] In a thirtieth aspect, the present disclosure provides an apparatus that comprises a processor configured to execute instructions stored, in a memory, to enable the apparatus to perform the method defined by any one the method defined herein.
[0088] Other aspects of the disclosure provide for apparatus, and systems configured to implement the methods according to the first aspect disclosed herein. Various components can be configured with machine readable memory containing instructions, which when executed by the processors of these devices, configures the device to perform one or more of the methods and systems described herein.
[0089] Embodiments have been described above in conjunction with aspects of the present disclosure upon which they can be implemented. Those skilled in the art will appreciate that embodiments may be implemented in conjunction with the aspect with which they are described but may also be implemented with other embodiments of that aspect. When embodiments are mutually exclusive, or are incompatible with each other, it will be apparent to those skilled in the art. Some embodiments may be described in relation to one aspect, but may also be applicable to other aspects, as will be apparent to those of skill in the art.BRIEF DESCRIPTION OF THE FIGURES
[0090] Further features and advantages of the present disclosure will become apparent from the following detailed description, taken in combination with the appended drawings, in which:
[0091] FIG. 1 is a schematic illustration of an example communication network, according to embodiments of the present disclosure.
[0092] FIG. 2 is a schematic illustration of another example communication network, according to embodiments of the present disclosure.
[0093] FIG. 3 is a schematic illustration of an apparatus wirelessly communicating with another apparatus within a communication system, according to embodiments of the present disclosure.
[0094] FIG. 4 is a schematic illustration of an example apparatus configured to implement one or more methods disclosed herein, according to embodiments of the present disclosure.
[0095] FIG. 5 is a schematic illustration of another example apparatus configured to implement one or more methods disclosed herein, according to embodiments of the present disclosure.
[0096] FIG. 6 is a schematic illustration of an example electronic device that may perform any or all of the operations of the methods and features, according to embodiments of the present disclosure.
[0097] FIG. 7 is a schematic illustration of a trigger frame in accordance with a format of the IEEETM802.11ax standard, according to prior art.
[0098] FIG. 8 is a schematic illustration of HE variant Common Info field format, according to prior art.
[0099] FIG. 9 is a schematic illustration of EHT variant Common Info field format, according to prior art.
[0100] FIG. 10 is a schematic illustration of HE variant User Info field, according to prior art.
[0101] FIG. 11 is a schematic illustration of EHT variant User Info field network, according to prior art.
[0102] FIG. 12 is a schematic illustration of an example of a Special User Info field, according to prior art.
[0103] FIG. 13 is a schematic illustration of an example bit allocation of a UHR variant Common Info Field, according to an embodiment of the present disclosure.
[0104] FIG. 14 is a schematic illustration of a first example bit allocation of a Special User Info field format, according to an embodiment of the present disclosure.
[0105] FIG. 15 is a schematic illustration of a second example bit allocation of a Special User Info field format, according to an embodiment of the present disclosure.
[0106] FIG. 16 is a schematic illustration of a third example bit allocation of a Special User Info field format, according to another embodiment of the present disclosure.
[0107] FIG. 17 is a schematic illustration of a fourth example bit allocation of a Special User Info field format, according to an embodiment of the present disclosure.
[0108] FIG. 18 is a schematic illustration of a fifth example bit allocation of a Special User Info field format, according to an embodiment of the present disclosure.
[0109] FIG. 19 is a schematic illustration of a sixth example bit allocation of a Special User Info field format, according to an embodiment of the present disclosure.
[0110] FIG. 20A is a schematic illustration of a seventh example bit allocation of a Special User Info field format, according to an embodiment of the present disclosure.
[0111] FIG. 20B shows, in accordance with the present disclosure, an embodiment of a trigger dependent user info subfield that may be present in the extended Special User info field.
[0112] FIG. 21A is a schematic illustration of an eighth example bit allocation of a Special User Info field format, according to an embodiment of the present disclosure.
[0113] FIG. 21B is a schematic illustration of bit allocation of a Special User Info field format, according to an embodiment of the present disclosure.
[0114] FIG. 22 is a schematic illustration of option A example bit allocation of a first example of a UHR User Info Field format, according to an embodiment of the present disclosure.
[0115] FIG. 23 is a schematic illustration of option B example bit allocation of a first example of a UHR User Info Field format, according to an embodiment of the present disclosure.
[0116] FIG. 24 is a schematic illustration of option C example bit allocation of a first example of a UHR User Info Field format, according to an embodiment of the present disclosure.
[0117] FIG. 25 is a schematic illustration of option D example bit allocation of a first example of a UHR User Info Field format, according to an embodiment of the present disclosure.
[0118] FIG. 26 is a schematic illustration of option E example bit allocation of a first example of a UHR User Info Field format, according to an embodiment of the present disclosure.
[0119] FIG. 27 is a schematic illustration of option F example bit allocation of a first example of a UHR User Info Field format, according to an embodiment of the present disclosure.
[0120] FIG. 28 is a schematic illustration of option G example bit allocation of a first example of a UHR User Info Field format, according to an embodiment of the present disclosure.
[0121] FIG. 29 is a schematic illustration of option H example bit allocation of a first example of a UHR User Info Field format, according to an embodiment of the present disclosure.
[0122] FIG. 30 is a schematic illustration of a first example bit allocation of a second example of a UHR User Info Field format, according to an embodiment of the present disclosure.
[0123] FIG. 31 is a schematic illustration of a second example bit allocation of a second example of a UHR User Info Field format, according to an embodiment of the present disclosure.
[0124] FIG. 32 is a schematic illustration of a third example bit allocation of a second example of a UHR User Info Field format, according to an embodiment of the present disclosure.
[0125] FIG. 33 is a schematic illustration of a fourth example bit allocation of a second example of a UHR User Info Field format, according to an embodiment of the present disclosure.
[0126] FIG. 34 is a schematic illustration of option A example bit allocation of a third example of a UHR User Info Field format, according to an embodiment of the present disclosure.
[0127] FIG. 35 is a schematic illustration of option B example bit allocation of a third example of a UHR User Info Field format, according to an embodiment of the present disclosure.
[0128] FIG. 36 is a schematic illustration of option C example bit allocation of a third example of a UHR User Info Field format, according to an embodiment of the present disclosure.
[0129] FIG. 37A is a schematic illustration of an example bit allocation of a fifth example of a UHR User Info Field format, according to an embodiment of the present disclosure.
[0130] FIG. 37B shows an embodiment of utilizing an Extended User info field in accordance wit the present disclosure.
[0131] FIG. 38 is a schematic illustration of an example bit allocation of a sixth example of a UHR User Info Field format, according to an embodiment of the present disclosure.
[0132] FIG. 39 is a schematic illustration of an example implementation of a UHR Trigger frame, according to an embodiment of the present disclosure.
[0133] FIG. 40 is a schematic illustration of another example implementation of a UHR Trigger frame, according to another embodiment of the present disclosure.
[0134] It will be noted that throughout the appended drawings, like features are identified by like reference numerals.DETAILED DESCRIPTION
[0135] This disclosure is related to the standardization of next generation of IEEETM 802.11bn standard. This disclosure is applicable to UHR APs and Stations (STAs) . In particular, Wi-FiTM 8 AP or device (Future devices) .
[0136] The present disclosure sets forth various embodiments via the use of block diagrams, flowcharts, and examples. Insofar as such block diagrams, flowcharts, and examples contain one or more functions and / or operations, it will be understood by a person skilled in the art that each function and / or operation within such block diagrams, flowcharts, and examples can be implemented, individually or collectively, by a wide range of hardware, software, firmware, or combination thereof. As used herein, the term “about” should be read as including variation from the nominal value, for example, a + / -10%variation from the nominal value. It is to be understood that such a variation is always included in a given value provided herein, whether or not it is specifically referred to. The phrase “in embodiments” can be interpreted to mean “in one or more, but not necessarily all embodiments. ”
[0137] FIG. 1 schematically illustrates a communication network 100, according to embodiments. The communication network 100 may include an underlay network, such as a transport network. The communication network 100 may include an overlay network, such as a mobile network. The communication network 100 may include an application-driven network. The communication network 100 may include a radio access network (RAN) 120. The RAN 120 may be a next generation (e.g., 6th generation (6G) or later) radio access network, or a legacy (e.g., 5th generation (5G) , 4th generation (4G) , 3rd generation (3G) or 2nd generation (2G) ) radio access network. In some implementations, the 6G radio access refers to a next generation air interface of standards which may comprise both terrestrial networks (TNs) and non-terrestrial networks (NTNs) . The communication network 100 may include a core network (CN) 130 that may be dependent or independent of the radio access technology used in the network. The communication network 100 may include a public switched telephone network (PSTN) 140, the internet 150, and other networks 160. In general, the communication network 100 enables communication of multiple wireless or wired nodes thereof. One or more nodes 110a, 110b, 110c, 110d, 110e, 110f, 110g, 110h, 110i, 110j may be interconnected to one another and / or connected to one or more network elements 170a, 170b, such as base stations, aquatic stations, aerial stations, or ground stations, in the RAN 120.
[0138] The communication network 100 may provide content, such as voice, data, video, and / or text, via broadcast, multicast, groupcast, unicast, etc. The communication network 100 may operate by sharing resources, such as carrier spectrum bandwidth, among its constituent elements. The communication network 100 may provide a wide range of communication services and applications to network users including enhanced Mobile Broadband (eMBB) services, ultra-reliable low-latency communication (URLLC) services, massive machine type communication (mMTC) services, integrated sensing and communication (ISAC) , immersive communication, massive communication, Hyper reliable and low-latency communication, ubiquitous connectivity, integrated AI and communication, and other services that can be provided by a future generation communication system. The communication network 100 may provide other services and applications such as earth monitoring, remote sensing, passive sensing and positioning, navigation and tracking, autonomous delivery and mobility, etc.
[0139] The communication network 100 may include a terrestrial network and / or a non-terrestrial network. The communication network 100 may provide a high degree of availability and robustness through a joint operation of a terrestrial network and a non-terrestrial network. For example, integrating a non-terrestrial network (or components thereof) into a terrestrial network can result in a heterogeneous network comprising multiple blocks. The heterogeneous network may achieve better overall performance through efficient multi-link joint operation, more flexible functionality sharing, and faster physical block link switching between terrestrial networks and non-terrestrial networks. The terrestrial network and the non-terrestrial network could be considered sub-systems of the communication network 100.
[0140] The communication network 100 may be compliant with one or more regional, national and / or international standard, such as the Internet Engineering Task Force (IETF) , the European Telecommunications Standards Institute (ETSITM) , and the Third Generation Partnership Project (3GPPTM) .
[0141] FIG. 2 illustrates another example communication system 100 according to an implementation of the present disclosure. The communication system 100 includes user equipment / electronic devices (UEs / Eds) 110a, 110b, 110c, 110d (collectively referred to as a UE / ED 110) , RANs 120a, 120b, one or more CNs 130, a PSTN 140, the Internet 150, and other networks 160. Additionally, the communication system 100 may also include a non-terrestrial network (NTN) 120c. The RANs 120a and120b may include network elements 170a and 170b respectively. Examples of network elements 107a, 107b include base stations, which can be generally referred to as terrestrial network (TN) devices or terrestrial transmit and receive points (T-TRPs) 170a and 170b (collectively referred to as 170) . In this context, the terms "TRP" and "base station" are used interchangeably unless otherwise specified. For simplicity, this disclosure primarily refers to network nodes as base stations; however, unless explicitly stated otherwise, references to TRP are considered non-limiting and interchangeable. The T-TRPs 170a, 170b may be base stations mounted on a building or tower. In one implementation, the NTN 120c includes a RAN node such as a base station 172, which may be generally referred to as an NTN device, a non-terrestrial node, a non-terrestrial network device, a non-terrestrial base station, or a non-terrestrial transmit and receive point (NT-TRP) 172.
[0142] In some implementations, the NT-TRP 172 is not attached to the ground, for example, as in the case of an airborne base station. An airborne base station may be implemented using communication equipment supported or carried by a flying device. For example, a flying device may include, but is not limited to, an airborne platform (such as a blimp or an airship) , balloon, drone (such as quadcopter) , and other types of aerial vehicles. In some implementations, an airborne base station may be supported or carried by an unmanned aerial system (UAS) or an unmanned aerial vehicle (UAV) , such as a drone. An airborne base station may be a moveable or mobile base station that can be flexibly deployed in different locations to meet network demand. A satellite base station is another example of a non-terrestrial base station. A satellite base station may be implemented using communication equipment supported or carried by a satellite. A satellite base station may also be referred to as an orbiting base station. High altitude platforms are yet another example of non-terrestrial base stations, including international mobile telecommunication base stations.
[0143] As referred to herein, and unless specified otherwise, a “TRP” may also refer to a T-TRP or an NT-TRP, a “T-TRP” may also refer to a “TN TRP” , and an “NT-TRP” may also refer to an “NTN TRP” . The NTN 120c may be considered a RAN, sharing operational aspects with RANs 120a, 120b. The NTN 120c may include at least one NTN device and at least one corresponding terrestrial network device. The at least one NTN device may function as a transport layer device and the at least one corresponding terrestrial network device may function as a RAN node, communicating with the UE / ED 110 via the NTN device. Additionally, there may be an NTN gateway on the ground (referred to as a terrestrial network device) that also functions as a transport layer device facilitating communication with both the NTN device and the RAN node. The RAN node may communicate with the UE / ED 110 via the NTN device and the NTN gateway. In some implementations, the NTN gateway and the RAN node may be located within the same device.
[0144] A base station 170 (also referred to as a TRP as stated above) is a network element within a radio access network responsible for radio transmission and reception in one or more cells to or from the UE / ED (such as a user equipment) . In different implementations, the base station 170 may also be known as a base transceiver station (BTS) , a radio base station, a network node, a network device, a device on the network side, a transmit / receive node, a Node B, an evolved NodeB (eNodeB or eNB) , a Home eNodeB, a next Generation NodeB (gNB) , a transmission point (TP) , a site controller, an access point (AP) , a wireless router, a relay station, a terrestrial node, a terrestrial network device, a terrestrial base station, a non-terrestrial node, a non-terrestrial network device, a non-terrestrial base station, and a positioning node, among other possibilities. The base station 170 may be a macro base station (BS) , a pico BS, a relay node, a donor node, or combinations thereof. When the base station 170 performs (or is configured to perform) a method described herein, it may be interpreted as the base station itself, one or more modules (or units) in the base station, a circuit or chip, or a combination thereof, performing the method. For example, the circuit or chip may include a modem chip, also referred to as a baseband chip, a system on chip (SoC) including a modem core, system in package (SIP) ) , and the like, and may be responsible for one or more communication functions within the base station.
[0145] The UEs / EDs 110a-110d and TRPs 170a-170b, 172 are examples of communication equipment configured to implement some or all of the operations and / or implementations described herein. The T-TRP 170a forms part of the RAN 120a, which may include other TRPs, and / or other devices. Also, the TRP 170b forms part of the RAN 120b, which may include other TRPs, and / or devices. Each TRP 170a, 170b may transmit and / or receive wireless signals within a particular geographic region or area, sometimes referred to as a “cell” or a “coverage area” . The TRPs 170a-170b may be responsible for allocating and / or configuring resources and transmission and / or reception in a set of cell (s) . A cell is a radio network object that can be uniquely identified by a cell identification that is broadcasted over a geographical region or area from base stations associated with the cell. A cell can work in either FDD or TDD mode. A cell may be further divided into cell sectors, and a base station 170a-170b may, for example, employ one or more transceivers to provide services to one or more sectors. Some implementations may include pico or femto cells if supported by the radio access technology. In some implementations, one or more transceivers could be used for each cell, such as with Multiple-Input Multiple-Output (MIMO) technology. The number of RANs 120a-120b shown is merely an example. Any number of RANs may be contemplated when designing the communication system 100.
[0146] A base station may be a single element, as shown in the figures, or multiple elements distributed throughout the corresponding RAN, or otherwise configured. In some implementations, a plurality of RAN nodes coordinate to assist the UE / ED 110 in implementing radio access, and different RAN nodes separately implement and handle different functions of the base station. For example, the RAN node may be a central unit (CU) , a distributed unit (DU) , a CU-control plane (CP) , a CU-user plane (UP) , or a radio unit (RU) etc. The CU and the DU may be separately deployed, or included within the same element (i.e., a baseband unit (BBU) ) . The RU may be included in a radio frequency device or a radio frequency unit (i.e., a remote radio unit (RRU) , an active antenna unit (AAU) , or a remote radio head (RRH) ) . In different systems, the CU (or the CU-CP and the CU-UP) , the DU, or the RU may be known by different names, but their functions are understood by person skilled in the art. For example, in an open radio access network (ORAN) system, a CU may be referred to as an open CU (O-CU) , a DU may be referred to as an open DU (O-DU) , and a CU-CP may be referred to as an open CU-CP (O-CU-CP) . The CU-UP may also be referred to as an open CU-UP (O-CU-UP) , and the RU may also be referred to as an open RU (O-RU) . Any one of the CU (or the CU-CP, the CU-UP) , the DU, and the RU may be implemented using a software module, a hardware module, or a combination of a software module and a hardware module.
[0147] Furthermore, communication between different devices / apparatuses in various implementations of this disclosure may refer to direct communication (that is, without the need of forwarding by another device / apparatus) , or may refer to communication (s) between different devices / apparatuses via another device / apparatus (that is, requiring forwarding by another device / apparatus) . Alternatively, such communication (s) may involve one functional unit inside a device / apparatus using another functional unit within the device / apparatus to communicate with another device / apparatus. In other words, phrases such as "sending (or transmitting) information to... (a UE / ED or a base station) " in this disclosure may be understood as a destination endpoint of the information being an ED or a base station, including, sending / transmitting information directly or indirectly to an ED or a base station. Similarly, phrases like "receiving information from... (an ED or a base station) " may be understood as a source endpoint of the information being an ED or a base station, including directly or indirectly receiving information from an ED or a base station. Between the source endpoint that sends the information and the destination endpoint, necessary processing such as, but not limited to, format conversion, digital-to-analog conversion, amplification, and filtering may be performed on the information. However, the destination endpoint may understand valid information from the source endpoint. A similar understanding applies to other descriptions in this disclosure without reiterating details already described. In the present disclosure, the terms "send" and "transmit" may be used interchangeably in different implementations of this disclosure.
[0148] The UE / ED 110 is used to connect people, objects, machines, and other entities. The UE / ED 110 may be widely used in various scenarios including, but not limited to, cellular communications, device-to-device (D2D) , vehicle to everything (V2X) , peer-to-peer (P2P) , machine-to-machine (M2M) , MTC, internet of things (IoT) , virtual reality (VR) , augmented reality (AR) , mixed reality (MR) , metaverse, digital twin, industrial control, self-driving, remote medical, smart grid, smart furniture, smart office, smart wearable, smart transportation, smart city, drones, robots, remote sensing, passive sensing, positioning, navigation and tracking, and autonomous delivery and mobility.
[0149] Each UE / ED 110 represents any suitable end user device for wireless operation and may include such devices (or may be referred to as, but not limited to) a user equipment (UE) or a user device or a terminal device, a wireless transmit / receive unit (WTRU) , a mobile station, a fixed or mobile subscriber unit, a cellular telephone, a station (STA) , an MTC device, a personal digital assistant (PDA) , a smartphone, a laptop, a computer, a tablet, a wireless sensor, a consumer electronics device, a smart book, a vehicle, a car, a truck, a bus, a train, or an IoT device, wearable devices (such as a watch, a pair of glasses, head mounted equipment, etc. ) , an industrial device, or an apparatus (such as a module, modem, or chip) in the forgoing devices, among other possibilities. Future generation UEs / EDs 110 may be referred to by other terms. When a UE / ED 110 performs (or is configured to perform) a method described herein, it may be interpreted as the UE / ED itself, one or more modules (or units) in the UE / ED, a circuit or chip, or a combination thereof, performing the method. For example, the circuit or chip may include a modem chip, also referred to as a baseband chip, a system on chip (SoC) including a modem core, or system in package (SIP) ) , and the like, and may be responsible for one or more communication functions in the UE / ED.
[0150] Each UE / ED 110 connected to TRPs 170a-170b, and / or TRPs 172 can be dynamically or semi-statically turned-on (i.e., established, activated, or enabled) , turned-off (i.e., released, deactivated, or disabled) and / or configured in response to one of more of: connection availability and connection necessity.
[0151] Any UE / ED 110 may be alternatively or additionally configured to interface, access, or communicate with any of the TRPs 170a, 170b and 172, the Internet 150, the CN 130, the PSTN 140, the other networks 160, or any combination thereof. In some examples, the UE / ED 110a may communicate an uplink (UL) and / or downlink (DL) transmission over a terrestrial air interface 190a with station-TRP 170a. In some examples, the UEs / EDs 110a, 110b, 110c, and 110d may also communicate directly with one another via one or more sidelink (SL) air interfaces 190b. In some examples, the UEs / EDs 110a, 110d may communicate using an UL and / or DL transmission over a non-terrestrial air interface 190c with NT-TRP 172.
[0152] An air interface (such as, for example, 190a, 190b, 190c) generally includes a number of components and associated parameters that collectively specify how a transmission is to be sent and / or received over a wireless communications link between two or more communicating devices such as UEs / EDs and base station (s) . For example, an air interface may include one or more components defining the waveform (s) , frame structure (s) , multiple access scheme (s) , protocol (s) , coding scheme (s) and / or modulation scheme (s) for conveying information (such as, data) over a wireless communications link. The air interfaces 190a and 190b may use similar communication technology, that may include any suitable radio access technology.
[0153] The non-terrestrial air interface 190c can enable communication between the UEs / EDs 110a, 110d and one or more NT-TRPs 172 via a wireless link or simply a link. For some examples, the link is a dedicated connection for unicast transmission, a connection for broadcast transmission, or a connection between a group of UEs / EDs 110 and one or more NT-TRPs 172 for multicast transmission.
[0154] The TRPs 170a-170b, 172 may communicate with one another over one or more air interfaces 190e, 190f using wireless communication links (such as radio frequency (RF) , microwave, infrared (IR) , etc. ) or wired communication links. The air interfaces 190e, 190f may utilize any suitable radio access technology, and may be substantially similar to the air interfaces 190a, 190c over which the UEs / EDs 110a-110d communicate with one or more of the TRP 170a-170b, 172 or they may be substantially different. For example, the communication system 100 may implement one or more channel access methods, such as Time Division Multiple Access (TDMA) , Frequency Division Multiple Access (FDMA) , Code Division Multiple Access (CDMA) , Single Carrier Frequency Division Multiple Access (SC-FDMA) , Low Density Signature Multicarrier Code Division Multiple Access (LDS-MC-CDMA) , Non-Orthogonal Multiple Access (NOMA) , Pattern Division Multiple Access (PDMA) , Lattice Partition Multiple Access (LPMA) , Resource Spread Multiple Access (RSMA) , and Sparse Code Multiple Access (SCMA) .
[0155] The RANs 120a and 120b are in communication with the CN 130 to provide the UEs / EDs 110a 110b, and 110c with various services such as voice, data, multimedia, and other services. The RANs 120a and 120b and / or the CN 130 may be in direct or indirect communication with one or more other RANs (not shown) , which may or may not be directly served by the CN 130, and may employ different radio access technologies from RAN 120a and / or RAN 120b. The CN 130 may also serve as a gateway access between (i) the RANs 120a and 120b and / or the UEs / EDs 110a 110b, and 110c, and (ii) other networks (such as the PSTN 140, the Internet 150, and the other networks 160) . In addition, some or all of the UEs / EDs 110a 110b, and 110c may include functionality for communicating with different wireless networks over different wireless links using different wireless technologies and / or protocols. For example, the UEs / EDs 110a 110b, and 110c communicate using different cellular communications protocols, such as, but not limited to, a Global System for Mobile Communications (GSMTM) protocol, a code-division multiple access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, a Universal Mobile Telecommunications System (UMTSTM) protocol, a 3GPPTM Long Term Evolution (LTETM) protocol, a fifth generation (5G) protocol, a New Radio (NR) protocol, and the like. Instead of wireless communication (or in addition thereto) , the UEs / EDs 110a 110b, and 110c may communicate using wired communication channels to a service provider or switch (not shown) , and / or to the Internet 150. The PSTN 140 may include circuit switched telephone networks for providing plain old telephone service (POTS) . The Internet 150 may include a network of computers and subnets (intranets) or both, and incorporate protocols, such as internet protocol (IP) , transmission control protocol (TCP) , user datagram protocol (UDP) . UEs / EDs 110a 110b, and 110c may be multimode devices capable of operation according to multiple radio access technologies, and may incorporate one or multiple transceivers necessary to support such.
[0156] In addition, the communication system 100 may comprise a sensing agent (not shown) to manage the sensed data from UE / ED 110 and / or any one of TRPs 170a, 170b, 172. In one implementation, the sensing agent may be part of any one of TRPs 170a, 170b, 172. In another implementation, the sensing agent is a separate node that can communicate with the CN 130 and / or the RAN 120 (such as any one of TRPs 170a, 170b, 172) .
[0157] FIG. 3 is a schematic illustration showing an apparatus 310 wirelessly communicating with another apparatus 320 within a communication system (e.g., the communication system 100) according to an implementation of the present disclosure. The apparatus 310 may be an electronic device (such as ED 110) . The apparatus 320 may be a network node (e.g., the network node 170) such as T-TRP 170 or an NT-TRP 172. Although only one apparatus 310, and one apparatus 320 are shown in the figure, the number of apparatus 310 and / or number of apparatus 320 can vary, potentially including one or more of each. For example, a single ED 110 may be served by a single T-TRP 170 (or a single NT-TRP 172) , or by multiple T-TRPs 170 (or multiple NT-TRPs 172) . Similarly, a single ED 110 may be served by one or more T-TRPs 170 and one or more NT-TRPs 172. Similarly, a single T-TRP 170 (or a single NT-TRP 172) may serve one or more EDs 110.
[0158] The apparatus 310 may include one or more processors 210. For clarity and to avoid overcrowding the illustration, only a single processor 210 is illustrated. The apparatus 310 may further include a transmitter 201 and a receiver 203 coupled to one or more antennas 204. For clarity, only a single antenna 204 is illustrated. One, some, or all of the antennas 204 may alternatively be panels. In some implementations, the transmitter 201 and the receiver 203 are separate from each other. In other implementations, the transmitter 201 and the receiver 203 may be integrated into a single unit, for example, as a transceiver. The transceiver is configured to modulate data or other content for transmission by the one or more antennas 204 or a network interface controller (NIC) . The transceiver may also be configured to demodulate data or other content received by the one or more antennas 204. A transceiver may include any suitable structure for generating signals for wireless or wired transmission and / or for processing signals received through wireless or wired communication. Each antenna 204 includes any suitable structure for transmitting and / or receiving wireless or wired signals. The apparatus 310 may include a memory 208. In some implementations, the apparatus 310 may include multiple memories 208. Only a single transmitter 201, receiver 203, processor 210, memory 208, and antenna 204 is illustrated for simplicity, but the apparatus 310 may include one or more other components. In some implementations of the present disclosure, the transceiver (or transmitter 201 and / or receiver 203) may be viewed as an interface circuit.
[0159] The memory 208 is configured to store instructions used to perform operations described herein. The memory 208 may also be configured to store data that is used, generated, or collected by the apparatus 310. For example, the memory 208 can store software instructions or modules configured to implement some or all of the functionalities and / or operations described herein and that which are executed by the one or more processors 210.
[0160] The apparatus 310 may further include one or more input / output devices (not shown) or interfaces. The input / output devices or interfaces facilitate interaction with a user or other devices in the network. Each input / output device or interface includes suitable components for facilitating transmission of information to a user and reception of information from a user, and for various network interface communications. Such components may include, but are not limited to, a speaker, microphone, keypad, keyboard, display, touch screen, and the like.
[0161] The processor 210 may be configured to perform (or control the apparatus 310 to perform) operations (or methods) described herein as being performed by the apparatus 310. For example, the processor 210 performs or controls the apparatus 310 to perform the operations of: a) receiving one or more transport blocks (TBs) , b) using a resource for decoding at least one of the received TBs, c) releasing the resource for decoding another of the received TBs, and / or d) receiving configuration information configuring a resource. Specifically, the operations may include tasks related to: preparing a transmission for UL transmission to the apparatus 320, processing DL transmissions received from the apparatus 320, and handling SL transmission to and from another apparatus 310. Processing operations related to preparing a transmission for UL transmission may include operations such as, but not limited to, encoding, modulating, transmit beamforming, and generating symbols for transmission. Processing operations related to processing DL transmissions may include operations such as, but not limited to, receive beamforming, demodulating and decoding received symbols. Processing operations related to processing SL transmissions may include operations such as, but not limited to, transmit / receive beamforming, modulating / demodulating and encoding / decoding symbols. Depending upon the implementation, a DL transmission may be received by the receiver 203, possibly using receive beamforming, and the processor 210 may extract signaling from the DL transmission (such as by detecting and / or decoding the signaling) . An example of signaling may be a reference signal transmitted by the apparatus 320. In some implementations, the processor 210 implements the transmit beamforming and / or the receive beamforming based on the indication of beam direction, such as beam angle information (BAI) , received from the apparatus 320. In some implementations, the processor 210 may be configured to perform operations relating to network access (such as initial access) and / or downlink synchronization, which includes operations for detecting a synchronization sequence, decoding and obtaining the system information, and the like. In some implementations, the processor 210 may perform channel estimation, such as using a reference signal received from the apparatus 320.
[0162] Although not illustrated, in some implementations, the processor 210 may either be a part of the transmitter 201 or a part of the receiver 203 or a part of both the transmitter 201 and the receiver 203. Although not illustrated, in some implementations, the memory 208 may be a part of the processor 210.
[0163] The processor 210, along with the processing components of the transmitter 201 and the receiver 203 may each be implemented by one or more processors that may the same or different. These processors are configured to execute instructions stored in a memory (such as in the memory 208) .
[0164] The apparatus 320 includes one or more processors 260 (only one processor 260 is illustrated) . The apparatus 320 may further include one or more transmitters 252 and one or more receivers 254 coupled to one or more antennas 256. Only a single antenna 256 is illustrated to avoid clutter in the illustration. One, some, or all of the antennas 256 may alternatively be panels. In some implementations, the transmitter 252 and the receiver 254 are separate from each other. In other implementations, the transmitter 252 and the receiver 254 may be integrated into a single unit such as, for example, as a transceiver. The apparatus 320 may further include a memory 258. In some implementations, the apparatus 320 may include multiple memories 258. The apparatus 320 may further include a scheduler 253. Only a single transmitter 252, receiver 254, processor 260, memory 258, antenna 256 and scheduler 253 are illustrated for simplicity, however the apparatus 320 may include one or more other components. In the present disclosure, in some implementations, the transceiver (or transmitter 252 and / or receiver254) may be viewed as an interface circuit.
[0165] In some implementations, various components of the apparatus 320 may be distributed. For example, some of the modules of the apparatus 320 may be located remotely from the equipment housing the antennas 256 for the apparatus 320 (and therefore also can be viewed as one or more nodes) . These modules, which can be considered as one or more nodes, may be coupled to the equipment that houses the antennas 256 over a communication link (not shown) , sometimes referred to as front haul, such as the Common Public Radio Interface (CPRI) . Therefore, in some implementations, the term apparatus 320 may also refer to network-side nodes that perform processing operations such as, but not limited to, determining the location of the apparatus 310, resource allocation (scheduling) , message generation, and encoding / decoding, and that which are not necessarily part of the equipment that houses the antennas 256 of the apparatus 320. The nodes may also be coupled to other apparatuses 320. In some implementations, the apparatus 320 may actually be a plurality of nodes that are operating together to serve the apparatus 310, such as through the use of coordinated multipoint transmissions, or through the use of ORAN system as described above in the disclosure.
[0166] The processor 260 is configured to perform operations including those related to: preparing a transmission for DL transmission to the apparatus 310, processing an UL transmission received from the apparatus 310, preparing a transmission for backhaul transmission to another apparatus 320, and processing a transmission received over backhaul from another apparatus 320. Processing operations related to preparing a transmission for DL or backhaul transmission may include operations such as, but not limited to, encoding, modulating, precoding (such as MIMO precoding) , transmit beamforming, and generating symbols for transmission. Processing operations related to processing received transmissions in the UL or over backhaul may include operations such as, but not limited to, receive beamforming, demodulating received symbols, and decoding received symbols. The processor 260 may also be configured to perform operations relating to network access (such as initial access) and / or DL synchronization, such as generating the content of synchronization signal blocks (SSBs) , generating the system information, and the like. In some implementations, the processor 260 is further configured to generate an indication of beam direction, such as BAI, which may be scheduled for transmission by the scheduler 253 which will be described below. In some implementations, the processor 260 implements the transmit beamforming and / or receive beamforming based on beam direction information (such as BAI) received from another apparatus 320. The processor 260 is configured to perform other network side processing operations described herein, such as, but not limited to, determining the location of the apparatus 310, determining where to deploy another apparatus 320, and the like. In some implementations, the processor 260 may generate signaling data, to configure one or more parameters of the apparatus 310 and / or one or more parameters of another apparatus 320. Any signaling data generated by the processor 260 is sent by the transmitter 252. In some implementations, the apparatus 320 implements physical layer processing. In some implementations, the apparatus 320 may perform higher layer functions such as those at the Medium Access Control (MAC) or Radio Link Control (RLC) layers in addition to physical layer processing. In the apparatus 320, the scheduler 253 may be coupled to the processor 260 or integrated within the processor 260. In some implementations, the scheduler 253 may be integrated within the apparatus 320 or may be operated separately from the apparatus 320. The scheduler 253 may schedule UL, DL, SL, and / or backhaul transmissions, including issuing scheduling grants and / or configuring scheduling-free (such as “configured grant” ) resources.
[0167] The apparatus 320 may further include a memory 258 that is configured to store instructions for performing the operations described herein. The memory 258 may also store data that is used, generated, or collected by the apparatus 320. For example, the memory 258 can store software instructions or modules configured to implement some or all of the functionalities and / or implementations described herein and that which are executed by the processor 260.
[0168] Although not illustrated, the processor 260 may be implemented as part of the transmitter 252 and / or a part of the receiver 254. Although not illustrated, in some implementations, the processor 260 may implement the scheduler 253 and the memory 258 may be implemented as part of the processor 260.
[0169] The processor 260, the scheduler 253, the processing components of the transmitter 252, and the processing components of the receiver 254 may each be implemented by the same or different processors that are configured to execute instructions stored in a memory, such as in the memory 258.
[0170] The apparatus 320 and / or the apparatus 310 may include other components, not shown or described herein for the sake of clarity.
[0171] Note that the term “signaling” , as used herein, may alternatively be referred to as control signaling, control message, control information, or message for simplicity. Signaling between a base station (such as the TRP 170a. 170b, 172) and a UE or sensing device (such as ED 110) , or signaling between a different UE or sensing device (such as between ED 110a and ED 110b) may be carried in physical layer signaling (also called as dynamic signaling) , which is transmitted in a physical layer control channel. For DL, the physical layer signaling may be known as downlink control information (DCI) which is transmitted in a physical downlink control channel (PDCCH) . For UL, the physical layer signaling may be known as uplink control information (UCI) which is transmitted in a physical uplink control channel (PUCCH) . For SL, signaling between different UEs or sensing devices (such as between ED 110a and ED 110b) may be known as SL control information (SCI) which is transmitted in a physical sidelink control channel (PSCCH) . Signaling may be carried in a higher layer (such as higher than physical layer) signaling, which is transmitted in a physical layer data channel, such as in a physical downlink shared channel (PDSCH) for downlink signaling, in a physical uplink shared channel (PUSCH) for uplink signaling, and in a physical sidelink shared channel (PSSCH) for SL signaling. Higher layer signaling may also be called static signaling, or semi-static signaling. The higher layer signaling may include radio resource control (RRC) protocol signaling or media access control -control element (MAC-CE) signaling. Signaling may be included in a combination of physical layer signaling and higher layer signaling.
[0172] It should be noted that in the present disclosure, “information” , when different from “message” , may be carried within a single message, or may be carried in multiple separate messages.
[0173] FIG. 4 illustrates an example apparatus 410 according to an implementation of the present disclosure. The apparatus 410 may be a communication device or an apparatus implemented in a communication device such as the ED 110 or the TRPs 170a, 170b, 172. For example, the apparatus 410 implemented in an ED may be an integrated circuit, which in some instances may be referred to as a chip, a modem, a modem chip, a baseband chip, or a baseband processor. In some implementations, one or more integrated circuits can be packaged into a system-on-chip, a system-in-package, or a multi-chip module. The apparatus 410 can include one or more integrated circuits and other discrete components. In some implementations, the apparatus 410 may be a module within the ED 110, or within the apparatus 310. In some implementations, the apparatus 410 may be a module within one of the TRPs 170a, 170b, 172, or the apparatus 320.
[0174] In an example, the apparatus 410 may include one or more processors 411, and an interface circuit 412. The apparatus 410 may further include a memory 413. The one or more processors 411 are configured to process signals and execute one or more communication protocols. The memory 413 is configured to store at least a part of corresponding computer program instructions and / or data. In an example, the one or more processors 411 execute the computer program instructions stored in the memory 413 to implement related operations (for example, inputting, outputting, receiving, and transmitting) in the method embodiments disclosed herein. In some implementations, the memory 413 being configured to store the corresponding computer program instructions and / or data may mean that the memory 413 is configured to store all of the corresponding computer program instructions and / or data for execution by the one or more processors 411. In some implementations, the memory 413 being configured to store the corresponding computer program instructions and / or data may mean that the memory 413 is configured to store a part of the corresponding computer program instructions and / or data. For example, the part of the corresponding computer program instructions and / or data may include computer program instructions and / or data that need to be currently executed by the one or more processors 411. Thus, the memory 413 may store different parts of computer program instructions and / or data for a plurality times for the one or more processors 411 to perform related operations in the method embodiments disclosed herein. As a communication interface, the interface circuit 412 is configured to implement communication with another component. For example, the interface circuit 412 may communicate a signal with other apparatus / system such as a radio frequency processing apparatus, or processor system. The communication includes transmitting signal (or data, information) to another component or device, or receives signal from another component or device. “transmitting” includes outputting the signal to a component or device that is directly or indirectly coupled to the interface circuit (transmitting unit) . “receiving” includes inputting or obtaining a signal from a component or device that is directly or indirectly couped to the interface circuit (receiving unit) . Optionally, to reduce a load of the one or more processors, a baseband signal processing circuit 414 may be also disposed to implement processing of at least a part of baseband signals, including signal demodulation, modulation, encoding, decoding, or the like.
[0175] The apparatus 410 may be the processor 210 (or 260) within the apparatus 310 (or 320) , in some scenarios, or may be included within the processor 210 (or 260) within the apparatus 310 (or 320) in some scenarios. The apparatus 410 may be a baseband chip or may include a baseband chip. In some implementations, the apparatus 410 may be independently packaged into a chip. In some implementations, the apparatus 310 (or 320) includes different types of chips. The apparatus 410 may be packaged into a processor chip (for example, an SoC chip or an SIP chip) with the different types of chips. In some implementations, the apparatus 410 may be packaged into a chip with some or all of circuits of a radio frequency processing system that may further be included in the apparatus 310 (or 320) .
[0176] FIG. 5 illustrates example apparatus 510 according to an implementation of the present disclosure. The apparatus 510 may include corresponding modules or units configured to implement methods and / or implementations described herein. In some implementations, the apparatus 510 includes a processing unit 512 and a communication unit 513. Optionally, the apparatus 510 may further include a storage unit 511 configured to store apparatus program code (or instructions) and / or data.
[0177] The apparatus 510 may be an ED side apparatus, for example, an ED or a module in an ED, or a circuit or a chip responsible for a communication function in an ED. In some implementations, apparatus 510 may be the apparatus 310. The processing unit 512 may be the processor 210. The communication unit 513 may comprise a receiving unit and / or a transmitting unit. The receiving unit and / or the transmitting unit may be the transmitter 201 and / or the receiver 203 respectively. The storage unit 511 may be the memory 208.
[0178] The apparatus 510 may be a base station side apparatus, for example, a base station or a module in a base station, or a circuit or a chip responsible for a communication function in a base station. In some implementations, apparatus 510 may be apparatus 320. The processing unit 512 may be the processor 260 (the scheduler 253 may also be included) . The communication unit 513 may comprise a receiving unit and / or a transmitting unit. The receiving unit and / or the transmitting unit may be the transmitter 252 and / or the receiver 254 respectively. The storage unit 511 may be the memory 258.
[0179] In some implementations, when the apparatus 510 is an ED 110 or a module in an ED 110, a function of the apparatus 510 may be implemented by one or more processors. Specifically, the processor may include a modem chip, or a system on chip (SoC) chip or an SIP chip that includes a modem core. A function of the communication unit 513 may be implemented by a transceiver circuit.
[0180] In some implementations, when the apparatus 510 is a circuit or a chip that is responsible for a communication function in an ED 110, -such as a modem chip, a system on chip (SoC) chip or an SIP chip that includes a modem core -a function of the processing unit 512 may be implemented by a circuit system within the chip which includes one or more processors. A function of the communication unit 513 may be implemented by an interface circuit or a data transceiver circuit on the chip.
[0181] It may be understood that the units in the apparatus 510 may be logical or functional. Each function may correspond to one functional unit, or two or more functions may be integrated into a single functional unit. In actual implementation, all or some of the units may be integrated into a single physical entity or may be distributed across different physical entities. In addition, the functional units may be implemented in the form of hardware, software, or a combination of hardware and software. Whether a function is implemented in the form of hardware or software depends on particular applications and design constraint conditions of the technical solutions. A person skilled in the art may use different methods to implement the described functions for specific applications, but it should not be considered that the implementation goes beyond the scope of this disclosure.
[0182] In an example, a functional unit in any one of the apparatuses may be configured as one or more integrated circuits for implementing the methods disclosed herein, for example, as one or more application-specific integrated circuits (application-specific integrated circuits, ASICs) , one or more central processing units (CPUs) , one or more microprocessors or microprocessor units (MPUs) , one or more microcontrollers or microcontroller units (MCUs) , one or more digital signal processors (DSPs) , one or more field programmable gate arrays (FPGAs) , or a combination of these.
[0183] In an example, the storage unit 511 may include a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, and / or a register.
[0184] A processor may be referred to as a processor system, an application processor, a baseband processor, a processor circuit, or a processor core. The processor may include one or a combination of one or more central processing units (CPUs) , one or more digital signal processors (DSPs) , one or more microprocessors (microprocessor units, MPUs) , one or more microcontrollers (microcontroller units, MCUs) , one or more graphics processing units (GPUs) , one or more field programmable gate arrays (FPGAs) , one or more artificial intelligence processors (AI processors) , or one or more neural network processing units (NPUs) .
[0185] Memory or a storage unit may include one or more of the following storage media: a random access memory (RAM) , a static random access memory (static RAM, SRAM) , a dynamic random access memory (dynamic RAM, DRAM) , a phase-change memory (PCM) , a resistive random access memory (resistive RAM, ReRAM) , a magnetoresistive random access memory (magnetoresistive RAM, MRAM) , a ferroelectric random access memory (ferroelectric RAM, FRAM) , a cache, a register, a read-only memory (ROM) , a flash memory (flash memory) , an erasable programmable read-only memory (erasable programmable ROM, EPROM) , a hard disk, and the like. In an example, computer program instructions used to execute embodiments may be stored in a non-volatile memory, for example, at least a part of a memory or storage unit (for example, one or more of a ROM, a flash memory, an EPROM, or a hard disk) . When a terminal runs, a part or all of corresponding computer program instructions may be loaded to a memory that has a higher transmission speed with the processor, for example, at least a part of a memory or a storage unit (for example, one or more of a RAM, an SRAM, a DRAM, a PCM, a RERAM, an MRAM, a FRAM, a cache, or a register) , so that the processor executes the computer program instructions to perform the steps in the method embodiments disclosed herein.
[0186] FIG. 6 shows a schematic diagram of an electronic device 500that may perform any or all of the operations of the above methods and features explicitly or implicitly described herein, according to different embodiments of the present disclosure. For example, a computer equipped with network function may be configured as electronic device 500. The electronic device 500 may be used to implement the methods and systems described herein.
[0187] As shown, the electronic device 500 may include at least one processor 560, such as a Central Processing Unit (CPU) or specialized processors such as a Graphics Processing Unit (GPU) , a Neural Processing Unit (NPU) or other such processor unit, memory 565, network interface 575, and a bi-directional bus 580 to communicatively couple the components of electronic device 500. The at least one processor 560 may be operatively coupled to a caching server. Electronic device 500 may also optionally include non-transitory mass storage 570, an I / O interface 585, and a transceiver 590. According to certain embodiments, any or all of the depicted elements may be utilized, or only a subset of the elements. Further, the electronic device 500 may contain multiple instances of certain elements, such as multiple processors, memories, or transceivers. Also, elements of the hardware device may be directly coupled to other elements without the bi-directional bus 580. Additionally, or alternatively to a processor and memory, other electronics, such as integrated circuits, may be employed for performing the required logical operations.
[0188] The memory 565 may include any type of tangible, non-transitory memory such as static random access memory (SRAM) , dynamic random access memory (DRAM) , synchronous DRAM (SDRAM) , read-only memory (ROM) , any combination of such, or the like. The memory 565 in communication with the at least one processor 560 may have stored thereon a set of counters or slots for such set of counters or both. The mass storage element 570 may include any type of tangible, non-transitory storage device, such as a solid state drive, hard disk drive, a magnetic disk drive, an optical disk drive, USB drive, or any computer program product configured to store data and machine executable program code. According to certain embodiments, the memory 565 or mass storage 570 may have recorded thereon statements and instructions executable by the at least one processor 560for performing any of the aforementioned method operations described above.
[0189] Network interface 575 may include at least one of a wired network interface and a wireless network interface. The network interface 575 may include a wired network interface to connect to a communication network 577 and may also include a radio access network interface 576 for connecting to the communication network or other network elements over a radio link. The network interface 575 enables the electronic device 500 to communicate with remote entities such as those connected to the communication network 577.
[0190] FIG. 7 shows a trigger frame 700 in accordance with a format of the IEEETM 802.11ax standard. In this standard, the Common Info field 702 has two variants: the High-Efficiency (HE) variant and the Extremely High Throughput (EHT) variant. The HE variant Common Info field and the EHT variant Common Info field use the same encoding method for the Trigger Type, the uplink (UL) Length, More TF, CS Required, Low-Density Parity-Check (LDPC) Extra Symbol Segment, AP transmission (TX) Power, Pre-forward Error Correction (Pre-FEC) Padding Factor, Packet Extension (PE) Disambiguity, and Trigger Dependent Common Info subfields. The key distinction between the HE variant and the EHT variant lies in the repurposing of specific bits. In the EHT variant, bits B22, B26, and B53 are kept reserved, while bits B54 and B55 are repurposed to indicate HE / EHT in P160 and special user info indication, respectively. For backward compatibility with HE variant Common Info field, an EHT AP sets B22, B26, B53, and B63 to 0 and sets B56–B62 to 1 in the EHT variant Common Info field.
[0191] FIG. 8 shows an HE variant Common info field and FIG. 9 shows an EHT variant Common info field.
[0192] Referring to FIG. 8, the UL BW subfield 805 (bits 18 and 19) of the HE variant Common Info field indicates the bandwidth in the HE-SIG-A of the HE TB PPDU and is defined in accordance with Table 1 below. Table 1 –UL BW subfield encoding
[0193] Referring to FIG. 9, The UL BW subfield 905 (bits 18 and 19) of the EHT variant Common Info field along with the UL BW Extension subfield of the Special User Info field (e.g., 1203 in FIG. 12) indicates the bandwidth in the U-SIG field of the EHT TB PPDU.
[0194] There are three variants for the User Info field, which are: the Special User Info field, the HE variant User Info field, and the EHT variant User Info field. All User Info fields (including the Special User Info field) in the User Info List field of a Trigger frame have the same length unless the Trigger frame is Multi-User (MU) -Block-ACK Request (BAR) Trigger frame.
[0195] A User Info field that is addressed to a non-AP station (STA) is either an HE variant User Info field or an EHT variant User Info field. FIG. 10 shows an HE variant User Info field. FIG. 11 shows an EHT variant User Info field.
[0196] The User Info field is an HE variant addressed to a non-AP EHT STA if B39 of the User Info field is set to 0 and B54 of the Common Info field is set to 1 in the Trigger frame; otherwise, it is an EHT variant. Bit B39 of an HE variant User Info field is reserved for a non-EHT HE STA. B39 is set to 0 for an HE variant User Info field by an EHT AP and is the PS160 subfield for an EHT variant User Info field.
[0197] The Special User Info field is a User Info field that does not carry user specific information but carries extended common information not provided in the Common Info field. FIG. 12 shows an example of a Special User Info field. The Special User Info field is identified by an Associated Identifier AID12 (1201) value of 2007 and is optionally present in a Trigger frame that is generated by an EHT AP. An EHT AP does not use the value 2007 as an AID for any STA associated to it. The Special User Info field is not included in the Trigger frame unless the Trigger frame includes one or more EHT variant User Info fields. The Special User Info field, if present, is located immediately after the Common Info field of the Trigger frame and carries information for the U-SIG field of a solicited EHT TB PPDU.
[0198] The Physical (PHY) Version Identifier subfield indicates the PHY version of the solicited TB PPDU that is not an HE TB PPDU. The PHY Version Identifier subfield is set to 0 for EHT. The values from 1 to 7 are reserved.
[0199] The UL Bandwidth Extension subfield (e.g., 1203 in FIG. 12) , together with the UL BW subfield (e.g., 905 in FIG. 9) in the Common Info field, indicates the bandwidth of the solicited TB PPDU (i.e., the bandwidth in the U-SIG field of the EHT TB PPDU) . The UL Bandwidth Extension subfield is defined in Table 2 below. Table 2 –UL Bandwidth Extension subfield encoding
[0200] To maintain backward compatibility, an existing trigger frame format is proposed to be reused for the UHR variant. However, enabling new UHR features may need the definition of several additional fields for the Common Info, Special User Info, and User Info fields in trigger frames for IEEETM 802.11bn standard. For example, for EH / EHT Trigger frame variants (except for MU-RTS and MU-RTS TXS) , there are too few reserved bits remaining in the Common Info field. In another example, in IEEETM 802.11be standard, the Special User Info field (AID12=2007) was proposed for expansion of EHT variant Common Info, but also has only 3 reserved bits remaining. In a further example, regarding the EH / EHT User Info variants, each of them has only 1 reserved bit (e.g., bit B25 1105 in FIG. 11) after the MCS field (e.g., 1104 in FIG. 11) and it is not recommended to be utilized now for potential MCS expansion. Furthermore, based on the current HE / EHT User Info format, there is no space to accommodate any UHR features. Therefore, various embodiments disclosed herein are directed to providing solutions to one or more of these shortcomings.
[0201] Unequal modulation (UEQM) Info is an example of a potential UHR feature requiring inclusion within the User Info field in the trigger frame. The UEQM information can be included over different spatial streams as a potential UHR feature. For max NSS = 4 per STA, as in IEEETM 802.11be standard and expected in IEEETM 802.11bn standard, 2 bits or 3 bits are needed to indicate EQM / UEQM pattern variations in the User Info field.
[0202] In some prior art studies, 2 bits are taught to be enough to represent the EQM / UEQM Pattern Variation for max NSS=4, for example as detailed Table 3 below. Table 3 –Unequal QAM Variation patterns, according to existing TF format
[0203] In another prior art study, 2 bits were taught to be enough to represent the UEQM Pattern Variation for NSS=4, but another bit is needed as a flag to indicate the EQM case. In this case, 3 bits are needed to represent the EQM / UEQM, e.g., as detailed Table 4 below. Table 4 –Unequal QAM Variation patterns, according to an existing TF format
[0204] Other potential UHR info may be needed in the future. This could include a 1-bit EQM / UEQM indication to specify whether EQM or UEQM is applied, and a 2-bit UEQM pattern field. Additionally, a 5-bit Modulation and Coding Scheme (MCS) field, requiring a 1-bit MCS expansion, might be included. Information related to Distributed Resource Unit (DRU) could also be incorporated, such as a 2-bit DBW (Distributed Bandwidth) field, a 3-bit CSD (Cyclic Shift Diversity) indication, and a 1-bit 2x LDPC (Low-Density Parity-Check) flag, among other TBD UHR parameters. In this case, more bits may be needed within the UHR User Info field.
[0205] In summary, the main limitations of the existing trigger frame format include The Common Info having limited number of reserved bits for EH / EHT trigger frame variants, The Special User Info having only 3 reserved bits for EHT variant expansion, The User Info having no available space for UHR features without impacting existing functionality (e.g., MCS) , and Additional UHR Features being anticipated to require more bits in the User Info field for future UHR information.
[0206] The present disclosure is directed at providing solutions to one or more of the following technical problems. One problem includes insufficient space for UHR-specific information within the existing trigger frame format. The limited number of reserved bits in the Common Info, Special User Info, and User Info fields of the current trigger frame structure is inadequate to accommodate the growing requirements of IEEETM 802.11bn standard. This limitation hinders the efficient and flexible implementation of UHR features, such as UEQM, non-primary channel access, DRU Info, 2x LDPC, multi-access point (AP) coordination (Coordinated TDMA, Coordinated Spatial Reuse, Coordinated Beamforming, Coordinated restricted Target Wake Time, …, etc. ) , in-device coexistence management, intermediate FCS presence, etc.
[0207] Another problem includes potential backward compatibility issues. Expanding the trigger frame format to accommodate UHR information without disrupting existing network operations is a complex challenge. Introducing new fields or modifying existing ones necessitates careful consideration to facilitate seamless integration with legacy devices and systems.
[0208] Another problem includes efficient utilization of available resources. Optimizing the use of reserved bits and defining clear guidelines for extended fields are important to maximize the capacity of the trigger frame while maintaining backward compatibility.
[0209] By addressing one or more of the above noted problems, the present disclosure aims to provide a flexible and efficient solution for incorporating UHR-specific information into the trigger frame structure, thereby facilitating the realization of advanced wireless communication capabilities.
[0210] The present disclosure attempts to enhance the trigger frame structure to accommodate at least some of the existing and / or future UHR features and capabilities. Embodiments disclosed herein include several key modifications.
[0211] In embodiments, an improved utilization of reserved bits is provided. Existing reserved bits within one or more of the Common Info, Special User Info, and User Info fields are repurposed to carry essential UHR-related information. This approach reduces the need for introducing new fields, thereby at least in part facilitating preservation of backward compatibility.
[0212] In embodiments, re-designing of the representation of certain subfields within one or more of the Common Info, Special User Info, and User Info fields in fewer bits while preserving their functionality is provided. Advantageous effects include freeing up or make available space for at least some of the UHR features (e.g., such as UEQM, NPCA, DRU Info, 2x LDPC, multi-access point (AP) coordination (Coordinated TDMA (Co-TDMA) , Coordinated Spatial Reuse (CSR) , Coordinated Beamforming (COBF) , Coordinated restricted Target Wake Time (C-r-TWT) , …, etc. ) , in-device coexistence management (IDC) , and other TBD features) . The saved bits within one or more of the Common Info, Special User Info, and User Info fields are repurposed to carry at least some of the UHR-related information.
[0213] In embodiments, a flexible extension mechanism is provided. To accommodate potential growth in UHR requirements, embodiments introduce the concept of extended fields (e.g., one or more) . One or more of these extended fields can be dynamically added to the trigger frame as needed, providing flexibility while facilitating preservation of existing functionalities.
[0214] In embodiments, an Expanded User Info Field is provided that includes a larger 10-byte User Info field to accommodate UHR and beyond features.
[0215] In embodiments, careful consideration of backward compatibility is provided. The proposed modifications are designed to at least in part facilitates maintaining compatibility with existing wireless devices and systems. This can be achieved at least in part by strategically utilizing reserved bits and limiting changes that could impact legacy equipment.
[0216] By improving the use of one or more of existing fields and introducing a flexible extension mechanism, the present invention offers a robust solution for integrating UHR capabilities into the trigger frame structure while facilitating preserving backward compatibility.
[0217] A first embodiment pertains to the UHR variant Common Info Field.
[0218] In one example implementation of the first embodiment schematically illustrated in FIG. 13, one or more of the existing reserved bits may be utilized in the EHT variant Common Info field (e.g., bits B22 1307, B26 1309, B53 1315, and B56-B63 1318 and 1319) to include the common UHR Info (e.g., DRU info and intermediate FCS presence flag, Initial Control Frame (ICF) Special Info field presence indication, …, etc. ) in the UHR variant Common Info field (e.g., may be a preferred utilization in some implementations) . For TB Aggregated Physical Layer Data Unit (A-PPDU) , since the PHY Version Identifier within the UHR variant Special User Info field will accommodate non-EHT variants, bit B54 1316 may be utilized to signal the presence of HE or non-HE PPDUs in P160, instead of restricting it for only the HE / EHT in P160. This may contribute to expanding the capability beyond the current EHT variant Common Info field, which is limited to HE and EHT PPDUs.
[0219] In another example implementation of the first embodiment, if more UHR supported capabilities need to be included within the Common Info field, one of their reserved bits can be utilized to indicate the presence of Extended Common Info field (may be inapplicable in some cases due to backward compatibility issues) . This may include utilizing bit B63 1319 or any other reserved bit from B56 to B62 1318 in the Common Info field to indicate the presence of extended Common Info field. In this case, a new trigger type within the trigger type subfield may be defined (e.g., repurpose one of the reserved values (9-15) in the trigger type to indicate the new trigger type) .
[0220] The second embodiment pertains to the UHR Special User Info Field.
[0221] In a first example implementation of the second embodiment schematically illustrated in FIG. 14, the same format of the Special User Info Field supported by EHT variant may be used by repurposing the reserved value of 1 1431 in the PHY Version Identifier 1402 to indicate UHR variant. This can include AID12 = 2007 1401. This can include PHY Version Identifier 1402 = 001 to indicate UHR. This can include keeping values 2-7 1432 within PHY Version Identifier 1402 reserved for future Wi-FiTMgenerations (e.g., Wi-FiTM 9 variant, ..., so on) . There are only at most 3 bits (B37-B39 1407) reserved in the current EHT Special User Info field, which can be used to accommodate limited To Be Defined (TBD) Common UHR info (e.g., NPCA indication, Extended ICF Special Info field presence indication, Multi-AP coordination info, …, etc. ) . One, some, or all of the reserved bits B37-B39 1407 may be utilized 1424 to include TBD UHR Common Info (e.g., NPCA indication, a dynamic sub-band operation (DSO) indication, DRU Info, Extended ICF Special Info field presence indication, Multi-AP coordination info, …, etc. ) .
[0222] In a second example implementation of the second embodiment schematically illustrated in FIG. 15, the same format of the Special User Info Field supported by EHT variant may be used by repurposing the reserved value of 1 1531 in the PHY Version Identifier 1502 to indicate UHR variant. This can include AID12 1501 = 2007. This can include PHY Version Identifier 1502 = 001 to indicate UHR. This can include keeping values 2-7 1532 within PHY Version Identifier 1502 reserved for future Wi-FiTMgenerations (e.g., Wi-FiTM 9 variant, etc. ) . One, some, or all of 10 bits of the U-SIG Disregard subfield (1511 and 1513) within the U-SIG Disregard And Validate subfield 1506 may be utilized for accommodating potential TBD UHR Common Info (e.g., NPCA indication, DSO indication, DRU Info, Extended ICF Special Info field presence indication, Multi-AP coordination info, …, etc. ) . One or more of the 6 bits B25-B30 (B0-B5 in the Disregard In U-SIG-1 subfield 1511) and the 4 bits B32-B35 (B7-B10 in the Disregard In U-SIG-2 subfield 1513) can be utilized for accommodating potential TBD UHR Common Info (e.g., NPCA indication, DSO indication, DRU Info, Extended ICF Special Info field presence indication, Multi-AP coordination info, …, etc. )
[0223] In a third example implementation of the second embodiment schematically illustrated in FIG. 16, the same format of the Special User Info Field supported by EHT variant may be used by repurposing the reserved value of 1 1631 in the PHY Version Identifier 1602 to indicate UHR variant. This can include AID12 1601 = 2007. This can include PHY Version Identifier 1602 = 001 to indicate UHR. This can include keeping values 2-7 1632 within PHY Version Identifier 1602 reserved for future Wi-FiTMgenerations (e.g., Wi-FiTM 9 variant, etc. ) One or more of the reserved bits B37-B39 1607 may be utilized 1624 to include TBD UHR Common Info. One or more of 10 bits of the U-SIG Disregard subfield (1621 and 1623) within the U-SIG Disregard And Validate subfield 1606 may be utilized for accommodating potential TBD UHR Common Info (e.g., NPCA indication, DSO indication, DRU Info, Extended ICF Special Info field presence indication, Multi-AP coordination info, …, etc. ) . One, some, or all of 10 bits of the U-SIG Disregard subfield (1621 and 1623) within the U-SIG Disregard And Validate subfield 1606 may be utilized for accommodating potential TBD UHR Common Info. One or more of the 6 bits B25-B30 (B0-B5 in the Disregard In U-SIG-1 subfield 1621 ) and B32-B35 (B7-B10 in the Disregard In U-SIG-2 subfield 1623) can be utilized for accommodating potential TBD UHR Common Info
[0224] In a fourth example implementation of the second embodiment schematically illustrated in FIG. 17, for example if more UHR and Beyond supported capabilities need to be included within the Special User Info field 1741, one of the reserved bits from B37 to B39 (1707 and 1708) in the Special User Info field 1741 or any reserved bit in the Common Info field (e.g. B56 of bits B56-B62 1318 in FIG. 13) may be utilized (e.g., 1724) to indicate the presence of Extended Special User Info 1742 that can include common TBD UHR Common Info. For instance, this Extended Special User Info 1742 can be used to include common Info for the Initial Control Frame (ICF) for Multi-AP coordination schemes, NPCA, DSO, dynamic power save (DPS) , IDC info, and other UHR and Beyond features. Any bit from B37-B39 (1707 and 1708) in the Special User Info field 1741 or any reserved bit in the Common Info field (e.g. B56 of bits B56-B62 1318 in FIG. 13) may be utilized to indicate the presence of extended special user info field 1742. One or more of the remaining reserved bits in the Special User Info field 1741 may remain reserved and / or one or more bit may be utilized for limited UHR common Info (e.g., NPCA indication, DSO indication, …, etc. ) . The Extended Special User Info field 1742 has a common new AID 1731 (AID ≠2007) that is different from the common AID 1701 of the Special User Info field 1741 (i.e., AID=2007) to avoid associated backward compatibility issues with EHT variant. The Extended Special User Info field 1742 immediately follows the UHR Special User Info field 1741.
[0225] In a fifth example implementation of the second embodiment schematically illustrated in FIG. 18, for example if more UHR and Beyond supported capabilities need to be included within the special user info field 1841, one of the reserved bits from B37 to B39 (1807 ad 1808) (e.g., if it is equal to 1, this means an Extended Special User Info field 1842 is presented, otherwise it is equal 0) , one of the 10 bits of the U-SIG Disregard subfield (1821 and 1823) within the U-SIG Disregard And Validate subfield 1806 (B25-B30 or B0-B5 in the Disregard In U-SIG-1 subfield 1821 and B32-B35 or B7-B10 in the Disregard In U-SIG-2 subfield 1823) in the Special User Info field 1841, or any reserved bit in the Common Info field (e.g., B56 of bits B56-B62 1318 in FIG. 13, where B56 = 0, means an Extended Special User Info field is presented, otherwise B56 = 1) may be utilized to indicate the presence of Extended Special User Info 1842 that can include common TBD UHR-specific parameters. Any bit from B37-B39 (1807 ad 1808) may be utilized in the special user info field 1841 to indicate the presence of extended special user info field 1842. One or more of the reserved bits B37-B39 (1807 ad 1808) may be utilized to include TBD UHR Common Info. One or more of 10 bits of the U-SIG Disregard subfield (1821 and 1823) within the U-SIG Disregard and Validate subfield 1806 (B25-B30 or B0-B5 in the Disregard In U-SIG-1 subfield 1821, and B32-B35 or B7-B10 in the Disregard In U-SIG-2 subfield 1823) may be utilized for accommodating potential TBD UHR Common Info. One or more of the remaining reserved bits may remain reserved and / or one or more may be utilized for limited TBD UHR common Info (1824) . The Extended Special User Info field 1842 has a common new AID 1831 that is different from the AID 1801 of the Special User Info field 1841 (AID=2007) to avoid associated backward compatibility issues with EHT variant. The Extended Special User Info field 1842 immediately follows the UHR Special User Info field 1841.
[0226] In a sixth example implementation of the second embodiment schematically illustrated in FIG. 19, for example if more UHR and Beyond supported capabilities need to be included within the Special User Info field 1941, an Extended Special User Info field 1942 that can accommodate TBD UHR Common Info may be introduced. Since the Extended Special User Info Field 1942 can be defined without causing any backward compatibility or decoding issues, the indicator bit for the Extended Special User Info Field does not necessarily need to be included in the Special User Info field 1941 or Common Info field, thereby a bit (e.g., bit B39) that may otherwise have been used for indicating the Extended Special User Info Field, may be utilized for any other TBD UHR Common Info. One or more of the reserved bits B37-B39 1907 may be utilized to include TBD UHR Common Info. One or more of 10 bits of the U-SIG Disregard subfield (1921 and 1923) within the U-SIG Disregard And Validate subfield 1906 (B25-B30 or B0-B5 in the Disregard In U-SIG-1 subfield 1921, and B32-B35 or B7-B10 in the Disregard In U-SIG-2 subfield 1923) may be utilized for accommodating potential TBD UHR Common Info. One or more of the remaining reserved bits may remain reserved and / or one or more may be utilized for limited TBD UHR common Info. The Extended Special User Info field 1942 has a common new AID 1931 (AID ≠ 2007) that is different from the common AID 1901 of the Special User Info field 1941 (i.e., AID=2007) to limit associated backward compatibility issues with EHT variant. The Extended Special User Info field 1942 immediately follows the UHR Special User Info field 1941.
[0227] In a seventh example implementation of the second embodiment schematically illustrated in FIG. 20A, for example if more UHR and Beyond supported capabilities need to be included within the Special User Info field, an Extended Special User Info field that can accommodate TBD UHR Common Info may be introduced. If more than one Extended Special User Info field is needed, one of the bits from B12 to B39 within the Extended Special User Info field 1 2042, for example bit B39 2003, may be used as a flag to indicate the presence of a subsequent Extended Special User Info field 2 2043. This subsequent Extended Special User Info field 2 2043 can have the common AID 2005 that may be the same as the AID 2001 of the first Extended Special User Info field 1 2042 or be assigned a different AID.
[0228] The Trigger Dependent User Info subfield may be present in the Extended Special User Info field based on the Type of the trigger frame, as shown in the embodiment of FIG. 20B.
[0229] As an example of utilizing the Extended Special User Info field, the BSRP trigger frame and MU-RTS Trigger Frame emerge as strong candidates for carrying advanced UHR and Beyond control information. These frames could serve as initial control frames to trigger or enable various advanced operations and features, including Multi-AP coordination schemes (e.g., CSR, COBF, C-r-TWT, etc. ) , NPCA, DSO, DPS, and more. Given that the BSRP and MU-RTS trigger frames lack sufficient space to accommodate these advanced operations, the Extended Special User Info field within these trigger frames can be leveraged to carry the common information for one or more of these features. The proposed format for this field includes, as shown in FIG. 20B, an AID value not equal to 2007. Additionally, Bits B12–B15 may be utilized to indicate the type of the common control information including Multi-AP coordination schemes (e.g., CSR, COBF, C-r-TWT, etc. ) , NPCA, DSO, DPS, and more, while Bits B16–B39 may be utilized to carry the common information associated with the selected type.
[0230] In an eighth example implementation of the second embodiment schematically illustrated in FIG. 21A, for example if more Common UHR or Beyond (next future generations) Info needs to be included within the Special User Info field, the size of the Special User Info field can be expanded to 10 bytes 2109 instead of 5 bytes as in legacy EHT devices. This approach can be readily applied to trigger frame types that do not incorporate Trigger Dependent User Info subfields within their User Info fields (e.g., BSRP, MU-RTS, BQRP, NFRP) . In order to, at least in part, avoid wrong detection of STA AID or start of Padding field by HE / EHT devices, two disambiguation bits are needed, namely always setting B40 2108 =0 and B51 2110 = 1. As a result, the value of B40-B51 (2108, 2109 and 2110) is always between 2048 and 4094, which are reserved values for HE / EHT variants. Of note, reserved bits B37 to B39, can be used for UHR or Beyond Common Info, including common Info for the Initial Control Frame (ICF) for Multi-AP coordination schemes, NPCA, DSO, dynamic power save (DPS) , IDC info, and other UHR and Beyond features.
[0231] FIG. 21B shows another example of bit allocation of a Special User Info field format, according to an embodiment of the present disclosure. As an example of utilizing the 10-byte Special User Info field, the BSRP trigger frame and MU-RTS Trigger Frame emerge as strong candidates for carrying advanced UHR and Beyond control information. These frames could serve as initial control frames to trigger or enable various advanced operations and features, including Multi-AP coordination schemes (e.g., CSR, COBF, C-r-TWT, etc. ) , NPCA, DSO, DPS, and more. Given that the BSRP and MU-RTS trigger frames lack sufficient space to accommodate these advanced operations, the Special User Info field within these trigger frames can be expanded to 10 bytes to carry the common information for one or more of these features. In order to, at least in part, avoid wrong detection of STA AID or start of Padding field by HE / EHT devices, two disambiguation bits are needed, namely always setting B40 2108 = 0 and B51 2110 = 1. As a result, the value of B40-B51 (2108, 2109 and 2110) is always between 2048 and 4094, which are reserved values for HE / EHT variants. This saves 10 bits to be used for carrying additional control information. Additionally, Bits B41–B44 may be utilized to indicate the type of the common control information including Multi-AP coordination schemes (e.g., CSR, COBF, C-r-TWT, etc. ) , NPCA, DSO, DPS, and more, while Bits B45–B50 and B52-B79 may be utilized to carry the common information associated with the selected type.
[0232] Notably, in cases where the 10-byte Special User Info field is utilized, the size of each UHR or Beyond User Info field may also be set to 10 bytes. Alternatively, the UHR or Beyond Special User Info field could independently have a size of 10 bytes. To accommodate the need for expanding the Special User Info field size to 10 bytes, one of the reserved bits in the Common Info field or Special User Info field can be repurposed to indicate this change. For instance, the reserved bit could signify that the trigger frame is being used as an ICF frame, instructing UHR STAs to interpret the Special User Info field as 10 bytes instead of the default 5 bytes. Another approach could involve using the reserved bit to explicitly denote the field size, with a value of 0 representing a 5-byte field and a value of 1 indicating a 10-byte field.
[0233] The third embodiment pertains to the UHR User Info Field. Potential UHR supported features can be included within the UHR variant of the user info field as described below. However, only B25 is reserved within the current format of the user info field.
[0234] In a first example implementation of the third embodiment one UHR feature may be included by utilizing existing User Info field. The motion to include UEQM information over different spatial streams has been previously approved as potential UHR feature. For max NSS = 4, EQM / UEQM pattern variations can be indicated in 2 bits or 3 bits. Other potential UHR info may be needed in the future. This could include a 1-bit EQM / UEQM indication to specify whether EQM or UEQM is applied, and a 2-bit UEQM pattern field. Additionally, a 5-bit Modulation and Coding Scheme (MCS) field, requiring a 1-bit MCS expansion, might be included. Information related to Distributed Resource Unit (DRU) could also be incorporated, such as a 2-bit DBW (Distributed Bandwidth) field, a 3-bit CSD (Cyclic Shift Diversity) indication, and a 1-bit 2x LDPC (Low-Density Parity-Check) flag, among other TBD UHR parameters. In this case, more bits may be needed within the UHR User Info field.
[0235] Following and building onto the prior art, option A of the first example implementation of the third embodiment, schematically illustrated in FIG. 22, includes including the UEQM information over different spatial streams within the UHR variant of the user info field in 2 bits. Only one reserved bit B25 is available within the user info field. Since the total number of supported NSS is 8 and the total number of NSS per user is 4, the SS Allocation subfield can be reformulated, for example in 5 bits (e.g., 2216, 2226) , instead of 6 bits. One bit can be saved from the Starting Spatial Stream subfield 2201.
[0236] For example, reserved bit B25 and the saved bit from the SS Allocation may be utilized to indicate the UEQM Pattern subfield 2215.
[0237] In another example, reserved bit B25 and the saved bit from the SS Allocation may be utilized to indicate other TBD UHR Info 2225, e.g. B25 may be used for MCS expansion and B26 may be used for EQM / UEQM indication or 2x LDPC flag.
[0238] Following and building onto the prior art, option B of the first example implementation of the third embodiment, schematically illustrated in FIG. 23, includes the UEQM information over different spatial streams within the UHR variant of the user info field in 2 bits.
[0239] Bit B25 2315, 2325 may need to remain reserved for future MCS expansion. In this case, the UL Target Receive Power field 2317, 2328 may be represented in 5 bits, instead of 7 bits.
[0240] As detailed in Table 5 and Table 6 below, Targetpwr can be calculated according to Targetpwr=-110+3Fval, where Fval is the subfield value represented in 5 bits (values 0-30) . In 11be, Targetpwr=-110+Fval, where Fval is the subfield value represented in 7 bits (values 0-90) . Table 5 –UL Target Receive Power subfield in Trigger frame (11ax) Table 6 –UL Target Receive Power subfield in Trigger frame (11bn)
[0241] Following the above, it is possible to cover the same -110 dBm≤Targetpwr ≤-20 dBm, while saving 2 bits for the UEQM subfield, EQM / UEQM indication, DBW field, 2x LDPC flag, and / or other TBD UHR parameters.
[0242] As a result of the above, the saved 2 bits from the UL Target Receive Power subfield may be used for the UEQM subfield, EQM / UEQM indication, DBW field, 2x LDPC flag, and / or other TBD UHR parameters, for example as bits B37-B38 2318 or bits B32-B33 2327 in FIG. 23.
[0243] In another example option C of the first example implementation of the third embodiment, schematically illustrated in FIG. 24, a 3 bit EQM / UEQM pattern can be included. The reserved bit B25 2415, 2425 can be utilized as an indicator for the support of EQM / UEQM. If the value of the EQM / UEQM 2415, 2425 indicator is set to zero, the value of B37 and B38 2418, 2427 may correspondingly be set to 0 as reserved.
[0244] In another example option D of the first example implementation of the third embodiment, schematically illustrated in FIG. 25, the saved bits may be utilized to indicate other TBD UHR Info, e.g. MCS expansion, EQM / UEQM indication, DBW field, 2x LDPC flag, and / or other TBD UHR parameters, as bits B32-B33 2517 or bits B25 2525 and B32-B33 2527.
[0245] Following and building onto the prior art, option C of the first example implementation of the third embodiment, discussed above with reference to FIG. 24, includes the UEQM information over different spatial streams within the UHR variant of the user info field in 2 bits.
[0246] In some cases, bit B25 may need to remain reserved for future MCS expansion. One bit may be saved by representing the SS Allocation subfield in 5 bits as in option A described earlier with reference to FIGS. 22 and 23. In another example option E of the first example implementation of the third embodiment, schematically illustrated in FIG. 26, one bit may be saved by representing the UL Target Receive Power subfield in 6 bits B33-B38 2618, 2628 through calculating Targetpwr=-110+1.451Fval. The latter can save 1 bit (e.g., improved power resolution compared to option B) while still covering -110 dBm≤Targetpwr ≤-20 dBm, for Fval values from 0 to 62. When Fval= 63, the STA transmits the TB PPDU at the STA’s maximum transmit power for the assigned MCS, as detailed below in Table 7. Table 7 –Target Receive Power subfield in Trigger frame (11bn)
[0247] In some cases, the 3 bits EQM / UEQM pattern may need to be included. The reserved bit B25 2625 may be utilized, as an indicator for the support of EQM / UEQM, as shown in FIG. 26. One bit may be saved by representing the SS Allocation subfield (e.g., 2626) in 5 bits as described above. One bit may be saved by representing the UL Target Receive Power subfield (e.g., 2628) in 6 bits.
[0248] In another example option F of the first example implementation of the third embodiment, schematically illustrated in FIG. 27, the saved bits may be utilized to indicate other TBD UHR Info, e.g. MCS expansion, EQM / UEQM indication, DBW field, 2x LDPC flag, and / or other TBD UHR parameters, using bits B31-B32 2717 or bits B25 2725 and B21-B32 2727.
[0249] Another example option G of the first example implementation of the third embodiment, schematically illustrated in FIG. 28 includes cases where the 3 bits EQM / UEQM pattern may need to be included, for example as suggested in the prior art. Bit B25 2815, 2825 may remain reserved, FIG. 29 Emb 3-1h
[0250] The saved bits can be utilized to indicate other TBD UHR Info, e.g. MCS expansion, EQM / UEQM indication, DBW field, 2x LDPC flag, and / or other TBD UHR parameters, as shown as an illustrative example in FIG. 29. Notably, reserved bit B25 can similarly be used to indicate TBD UHR Info (e.g., MCS expansion bit) as described above.
[0251] In a second example implementation of the third embodiment, other potential UHR info may need to be added in the future. In this case more bits may be needed. As an example solution result, the Extended User Info field may be utilized.
[0252] In case including more UHR or Beyond supported features within the UHR variant of the User Info field is needed, the new Extended User Info field, that can include relevant TBD UHR-specific transmit or receive parameters related to multi-AP coordination schemes (CSR, COBF, Co-TDMA, C-r-TWT, …, etc. ) , NPCA, DSO, DPS, IDS, DRU Info, CSD, DBW, or / and other features, may be utilized. The Extended UHR User Info field immediately follows the UHR User Info field. The AID12 fields for the UHR User Info field and the Extended User Info field can be the same and equal the STA AID12, for example.
[0253] In an example option A of the second example implementation of the third embodiment, schematically illustrated in FIG. 30, any one or more of the reserved bits in the Common Info field or the Special User Info field 3041 may be utilized to indicate the presence of the extended UHR User Info field 3042. Another option is to utilize the value of the reserved bit B25 to indicate the presence of extended UHR User Info field 3015.
[0254] In case bit B25 needs to remain reserved or utilized for another TBD UHR Info, for example for future MCS expansion, the required bit may be obtained, for example, from representing the UL Target Receive Power subfield 3117 to 5 bits as discussed elsewhere herein with reference to Option B of the first example implementation of the third embodiment, and shown in FIG. 31.
[0255] In another example schematically illustrated in FIG. 32, the required bit may be obtained from representing the UL Target Receive Power subfield 3217 to 6 bits as discussed elsewhere herein with reference to Option C of the first example implementation of the third embodiment.
[0256] In another example schematically illustrated in FIG. 33, in case bit B25 needs to remain reserved or utilized for another TBD UHR Info, for example for future MCS expansion, the required bit can be obtained from representing the SS Allocation subfield to 5 bits using bits B26-B30 3316 or bits B27-B31 3327, as discussed elsewhere herein with reference to Option A of the first example implementation of the third embodiment, while using the remaining bit B31 3317 or B26 3326, respectively, for the Extended User Info Indicator.
[0257] In a third example implementation of the third embodiment, the first and the second example implementations of the third embodiment may be combined, for example as in option A illustrated in FIG. 34, option B illustrated in FIG. 35, or option C illustrated in FIG. 36.
[0258] In a fourth example implementation of the third embodiment (not shown) , for example if more UHR or beyond supported capabilities need to be included within the UHR User Info field, an Extended User Info field that can accommodate TBD UHR Info transmit or receive parameters related to multi-AP coordination schemes (CSR, COBF, Co-TDMA, C-r-TWT, …, etc. ) , NPCA, DSO, DPS, IDS, DRU Info, CSD, DBW, or / and other features, may be introduced. Since the Extended User Info Field can be defined without causing backward compatibility or decoding issues, it may be not necessary to include the Extended User Info indicator bit in the User Info field, Special User Info field, or Common Info field, and therefore the bit that otherwise would have been utilized for the Extended User Info indicator, may be utilized, for example for any other TBD UHR Info or may maintain its same functionality as in EHT variant.
[0259] In a fifth example implementation of the third embodiment schematically illustrated in FIG. 37A, for example if more UHR or beyond supported capabilities need to be included within the User Info field, an Extended User Info field that can accommodate TBD UHR Info transmit or receive parameters related to multi-AP coordination schemes (CSR, COBF, Co-TDMA, C-r-TWT, …, etc. ) , NPCA, DSO, DPS, IDS, DRU Info, CSD, DBW, or / and other features, may be introduced. If more than one Extended User Info field is needed, one (or more) of the bits from B12 to B39 within the Extended User Info field 1 3742, for example bit B39 3703 may be used as a flag to indicate the presence of a subsequent Extended Special User Info field 2 3743. This subsequent Extended User Info field 2 3743 can have an STA AID 3705 that is same as the STA AID 3701 of the first Extended User Info field 1 3742.
[0260] The Trigger Dependent User Info subfield may be present in the Extended User Info field based on the Type of the trigger frame.
[0261] FIG. 37B shows, in accordance with the present disclosure, an example of utilizing the Extended User Info field, the BSRP trigger frame and MU-RTS Trigger Frame emerge as strong candidates for carrying advanced UHR or Beyond User-Specific TX / RX information. These frames could serve as initial control frames to trigger or enable various advanced operations and features, including Multi-AP coordination schemes (e.g., CSR, COBF, C-r-TWT, etc. ) , NPCA, DSO, DPS, and more. Given that the BSRP and MU-RTS trigger frames lack sufficient space to accommodate these advanced operations, the Extended User Info field within these trigger frames can be leveraged to carry UHR or Beyond Info transmit or receive parameters related to multi-AP coordination schemes (CSR, COBF, Co-TDMA, C-r-TWT, …, etc. ) , NPCA, DSO, DPS, IDS, or / and other features for one or more of these features. The proposed format for this field includes an AID value equal to STA AID. Additionally, Bits B12–B15 may be utilized to indicate the type of the common control information including Multi-AP coordination schemes (e.g., CSR, COBF, C-r-TWT, etc. ) , NPCA, DSO, DPS, and more, while Bits B16–B39 may be utilized to carry the common information associated with the selected type.
[0262] In a sixth example implementation of the third embodiment schematically illustrated in FIG. 38, for example if more UHR or Beyond supported features need to be included within the UHR variant of the User Info field, the size of the UHR User STA Info field may be extended to 10 bytes instead of 5 bytes as in legacy HE / EHT devices. The Extended UHR User Info field immediately follows the UHR User Info field.
[0263] In order to limit wrong detection of STA AID or start of Padding field by HE / EHT devices, two disambiguation bits are needed, namely always setting B40 3809 = 0 and B51 3811 = 1. As a result, the value of B40-B51 3810 is always between 2048 and 4094, which are reserved values for HE / EHT variants. This option is aligned with eighth example implementation of the second embodiment (Special User Info Embodiment) described herein with reference to FIG. 21.
[0264] Regarding the format of the first 5 bytes, they can follow one of the options introduced in Embodiment 3-1.
[0265] As an example of utilizing the 10 bytes User Info field, the BSRP trigger frame and MU-RTS Trigger Frame emerge as strong candidates for carrying advanced UHR or Beyond User-Specific TX / RX information. These frames could serve as initial control frames to trigger or enable various advanced operations and features, including Multi-AP coordination schemes (e.g., CSR, COBF, C-r-TWT, etc. ) , NPCA, DSO, DPS, and more. Given that the BSRP and MU-RTS trigger frames lack sufficient space to accommodate these advanced operations, the Special User Info field within these trigger frames can be expanded to 10 bytes to carry transmit or receive parameters related info to multi-AP coordination schemes (CSR, COBF, Co-TDMA, C-r-TWT, …, etc. ) , NPCA, DSO, DPS, IDS, DRU Info, CSD, DBW, or / and other features, for one or more of these features. In order to, at least in part, avoid wrong detection of STA AID or start of Padding field by HE / EHT devices, two disambiguation bits are needed, namely always setting B40 2108 = 0 and B51 2110 = 1. As a result, the value of B40-B51 (2108, 2109 and 2110) is always between 2048 and 4094, which are reserved values for HE / EHT variants. This saves 10 bits to be used for carrying additional control information. Additionally, Bits B41–B44 may be utilized to indicate the type of the common control information including Multi-AP coordination schemes (e.g., CSR, COBF, C-r-TWT, etc. ) , NPCA, DSO, DPS, and more, while Bits B45–B50 and B52-B79 may be utilized to carry the common information associated with the selected type.
[0266] The fourth embodiment includes an example implementation of the UHR TF, as schematically illustrated in FIGS. 39 and 40.
[0267] By efficiently utilizing reserved bits in one or more of the Common Info, Special User Info, and User Info fields for UHR-specific parameters, as described herein, for example with reference to example implementations, the use of available space within the trigger frame can be harnessed, thereby limiting a need for additional fields and improving overall efficiency.
[0268] Re-designing the representation of certain one or more subfields within one or more of the Common Info, Special User Info, and User Info fields in fewer bits while preserving their functionality is provided. This frees up space for one or more of the UHR features. The saved one or more bits within one or more of the Common Info, Special User Info, and User Info fields are repurposed to carry at least some of the essential UHR-related information.
[0269] Repurposing bit B54 within the Common Info field is provided to indicate the presence of HE / non-HE PPDUs in P160 for TB A-PPDU. This facilitates enhancement of the capability of the trigger frame to support various combinations of TB A-PPDU. Compared to the EHT variant for example, such repurposing solution not limited to HE / EHT combinations only.
[0270] Extended UHR Special User Info field, Extended UHR User Info field, or both, as disclosed herein, can be provided and utilized for accommodating additional UHR-specific parameters. This improves flexibility to support future UHR requirements within the UHR Special User Info field and UHR User Info field while limiting disruptions of existing functionalities.
[0271] Methods and systems of increasing the size of the User Info field to 10 bytes to accommodate UHR and beyond features have been provided. The increased field size facilitates the inclusion of more detailed information and control parameters, enabling the support of at least some of the advanced UHR features and potential future enhancements. The additional space allows flexibility for future modifications and additions to the trigger frame, while limiting significant changes to the overall structure.
[0272] Careful consideration is given to backward compatibility by reusing existing fields and structures, in order to facilitate seamless integration with legacy devices and systems, and limit the impact on existing networks.
[0273] It will be appreciated that, although specific embodiments of the technology have been described herein for purposes of illustration, various modifications may be made without departing from the scope of the technology. The specification and drawings are, accordingly, to be regarded simply as an illustration of the disclosure as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the present disclosure. In particular, it is within the scope of the technology to provide a computer program product or program element, or a program storage or memory device such as a magnetic or optical wire, tape or disc, or the like, for storing signals readable by a machine, for controlling the operation of a computer according to the method of the technology and / or to structure some or all of its components in accordance with the system of the technology.
[0274] Acts associated with the method described herein can be implemented as coded instructions in a computer program product. In other words, the computer program product is a computer-readable medium upon which software code is recorded to execute the method when the computer program product is loaded into memory and executed on the microprocessor of the wireless communication device.
[0275] Further, each operation of the method may be executed on any computing device, such as a personal computer, server, PDA, or the like and pursuant to one or more, or a part of one or more, program elements, modules or objects generated from any programming language, such as C++, Java, or the like. In addition, each operation, or a file or object or the like implementing each said operation, may be executed by special purpose hardware or a circuit module designed for that purpose.
[0276] Through the descriptions of the preceding embodiments, the present disclosure may be implemented by using hardware only or by using software and a necessary universal hardware platform. Based on such understandings, the technical solution of the present disclosure may be embodied in the form of a software product. The software product may be stored in a non-volatile or non-transitory storage medium, which can be a compact disk read-only memory (CD-ROM) , USB flash disk, or a removable hard disk. The software product may include a number of instructions that enable a computer device (personal computer, server, or network device) to execute the methods provided in the embodiments of the present disclosure. For example, such an execution may correspond to a simulation of the logical operations as described herein. The software product may additionally or alternatively include number of instructions that enable a computer device to execute operations for configuring or programming a digital logic apparatus in accordance with embodiments of the present disclosure.
[0277] The word “a” or “an” when used in conjunction with the term “comprising” or “including” in the claims and / or the specification may mean “one” , but it is also consistent with the meaning of “one or more” , “at least one” , and “one or more than one” unless the content clearly dictates otherwise. Similarly, the word “another” may mean at least a second or more unless the content clearly dictates otherwise.
[0278] The terms “coupled” , “coupling” or “connected” as used herein can have several different meanings depending on the context in which these terms are used. For example, as used herein, the terms coupled, coupling, or connected can indicate that two elements or devices are directly connected to one another or connected to one another through one or more intermediate elements or devices via an electronic element depending on the particular context. The term “and / or” herein when used in association with a list of items means any one or more of the items comprising that list.
[0279] Although a combination of features is shown in the illustrated embodiments, not all of them need to be combined to realize the benefits of various embodiments of this disclosure. In other words, a system or method designed according to an embodiment of this disclosure will not necessarily include all features shown in any one of the Figures or all portions schematically shown in the Figures. Moreover, selected features of one example embodiment may be combined with selected features of other example embodiments.
[0280] Although the present disclosure has been described with reference to specific features and embodiments thereof, it is evident that various modifications and combinations can be made thereto without departing from the disclosure. The specification and drawings are, accordingly, to be regarded simply as an illustration of the disclosure as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the present disclosure.
Claims
A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having a UHR Common info field, the UHR Common info field having a format of an Extremely High Throughput (EHT) Common info field,the UHR Common info field having bit 54 indicating a presence of one of:a High Efficiency (HE) physical layer data unit (PPDU) in a 160 MHz primary channel, anda non-HE PPDU in the 160 MHz primary channel,the UHR Common info field having at least some of bits 22, 26, 53, and 56 to 63 defining common UHR capabilities; andtransmitting the UHR trigger frame to a client device.The method of claim 1, wherein bit 54 indicates, in accordance with a value of a physical version identifier in a Special User info field, one of an EHT PPDU and a UHR or beyond PPDU.The method of claim 1, wherein the common UHR capabilities include at least one of:distributed resource unit info,intermediate FCS presence flag, andan initial control frame Special info field presence indication.The method of claim 1, wherein:forming the UHR trigger frame comprises including, in the UHR trigger frame, an extended common info field to define further common UHR capabilities, andsetting one bit among bits 56 to 63 to indicate a presence of the extended common info field.The method of claim 4, wherein the UHR trigger frame has a trigger type field, the method further comprising:setting bits 9-15 of the trigger type field to indicate a new trigger type.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having a UHR Special User info field, the UHR Special User info field having an Extremely High Throughput (EHT) Special User info field format,the UHR Special User info field having a twelve-bit Association Identifier (AID12) field with a value set to 2007,the UHR Special User info field having a physical layer (PHY) version identifier with a value of ‘1’ to indicate physical protocol data units (PPDUs) are to have a UHR format, andbits 37 to 39 being set to define UHR common info; andtransmitting the UHR trigger frame to a client device.The method of claim 6, wherein the UHR common info includes at least one of:a non-primary channel access indication,a dynamic sub-band operation indication,distributed resource unit Info,an extended ICF Special Info field presence indication, andmulti-access point coordination info.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having a UHR Special User info field, the UHR Special User info field having an Extremely High Throughput (EHT) Special User info field format, the UHR Special User info field having a U-SIG Disregard and Validate field,the UHR Special User info field having a twelve-bit Association Identifier (AID12) field with a value set to 2007,the UHR Special User info field having a physical layer (PHY) version identifier with a value of ‘1’ to indicate physical protocol data units (PPDUs) are to have a UHR format,andbits 0 to 5 and bits 7 to 10 of the U-SIG Disregard and Validate field being set to define UHR common info;transmitting the UHR trigger frame to a client device.The method of claim 8, wherein the UHR common info includes at least one of:a non-primary channel access indication,a dynamic sub-band operation indication,distributed resource unit Info,an extended ICF Special Info field presence indication, andmulti-access point coordination info.The method of claim 8, wherein bits 37 to 39 of the UHR Special User info field are set to define additional UHR common info.The method of claim 10, wherein the additional UHR common info includes at least one of:a non-primary channel access indication,a dynamic sub-band operation indication,distributed resource unit Info,an extended ICF Special Info field presence indication, andmulti-access point coordination info.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having:a UHR Special User info field, the UHR Special User info field having:an Extremely High Throughput (EHT) Special User info field format;a twelve-bit Association Identifier (AID12) field with a value set to 2007; anda physical layer (PHY) version identifier with a value of ‘1’ to indicate physical protocol data units (PPDUs) are to have a UHR format,a reserved bit of the UHR Special User info field being set to indicate a presence of an Extended UHR Special User info field;andthe Extended UHR Special User info field,the Extended UHR Special User info field immediately following the UHR Special User info field;the Extended UHR Special User info field being 5 bytes in length;bits 0 to 11 of the Extended UHR Special User info field defining a common AID12 field with a value not equal to 2007;bits 12 to 39 of the Extended UHR special user info field defining additional UHR info; andtransmitting the UHR trigger frame to a client device.The method of claim 12, wherein the additional UHR info includes at least one of:one or more multi-access point coordination scheme,a non-primary channel access indication,a dynamic sub-band indication, anddynamic power save info.The method of claim 13, wherein the one or more multi-AP coordination scheme includes at least one of:coordinated spatial reuse info,coordinated beamforming info,coordinated time division multiple access info, andcoordinated restricted target wake time info.The method of claim 12, wherein bits 37 to 38 define UHR Common info, including one or more of:one or more multi-access point coordination scheme,a non-primary channel access indication,a dynamic sub-band operation indication, anddynamic power save info.The method of claim 15, wherein the one or more multi-AP coordination scheme includes at least one of:coordinated spatial reuse info,coordinated beamforming info,coordinated time division multiple access info, andcoordinated restricted target wake time info.The method of claim 12, wherein:the UHR Special User info field has a U-SIG Disregard and Validate field,bits 0 to 5 and bits 7 to 10 of the U-SIG Disregard and Validate field are set to define UHR common info.The method of claim 17, wherein the UHR common info includes at least one of:one or more multi-access point coordination scheme,a non-primary channel access indication,a dynamic sub-band operation indication, anddynamic power save info.The method of claim 18, wherein the one or more multi-AP coordination scheme includes at least one of:coordinated spatial reuse info,coordinated beamforming info,coordinated time division multiple access info, andcoordinated restricted target wake time info.A method comprising:forming an Ultra-High Reliability (UHR) trigger frame having a UHR Special User info field that is 10 bytes in length, a first five bytes of the UHR Special User info field having an Extremely High Throughput (EHT) Special User info field format,the UHR Special User info field having a twelve-bit Association Identifier (AID12) field with a value set to 2007,the UHR Special User info field having a physical layer (PHY) version identifier with a value of ‘1’ to indicate physical protocol data units (PPDUs) are to have a UHR format,bit 40 of the UHR Special User info field being a disambiguation bit set to ‘0’ , andbit 51 of the UHR Special User info field being a disambiguation bit set to ‘1’ ;andtransmitting the UHR trigger frame to a client device.The method of claim 20, wherein:at least one of:bits 41 to 50, andbits 52 to 79 define UHR common info, including one or more of Multi-AP coordination schemes.The method of claim 21, wherein the UHR common info includes at least one of:one or more multi-access point coordination scheme,a non-primary channel access indication,a dynamic sub-band operation indication, anddynamic power save info.The method of claim 22, wherein the one or more multi-AP coordination scheme includes at least one of:coordinated spatial reuse info,coordinated beamforming info,coordinated time division multiple access info, andcoordinated restricted target wake time info.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field, the UHR user info field including:an equal modulation (EQM) or an unequal modulation (UEQM) pattern variation field at bits 25 to 26 of the UHR User info field; anda spatial stream (SS) allocation field at bits 27 to 31 of the user info field;andtransmitting the UHR trigger frame to a client device.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field, the UHR User info field including:at least one UHR info subfield at bits 25 to 26 of the UHR User info field; anda spatial stream (SS) allocation field at bits 27 to 31 of the UHR User info field;andtransmitting the UHR trigger frame to a client device.The method of claim 25, wherein the at least one UHR info subfield includes one or more of:a modulation and coding scheme subfield,an equal modulation or unequal modulation indicator subfield,a distributed bandwidth subfield, andtwo low-density parity check flag subfields.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field, the UHR User info field including:an uplink (UL) target receive power field at bits 32 to 36 of the UHR User info field; andan equal modulation (EQM) or an unequal modulation (UEQM) pattern variation field at bits 37 to 38 of the user info field;andtransmitting the UHR trigger frame to a client device.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field, the UHR User info field including:an equal modulation (EQM) or an unequal modulation (UEQM) pattern variation field at bits 32 to 33 of the UHR User info field; andan uplink (UL) target receive power field at bits 34 to 38 of the UHR User info field; andtransmitting the UHR trigger frame to a client device.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field, the UHR User info field including:an equal modulation (EQM) or an unequal modulation (UEQM) indicator at bit 25 of the UHR User info field;an uplink (UL) target receive power field at bits 32 to 36 of the UHR User info field; andan unequal modulation (UEQM) pattern variation field at bits 37 to 38 of the UHR User info field;andtransmitting the UHR trigger frame to a client device.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field, the UHR User info field including:an equal modulation (EQM) or an unequal modulation (UEQM) indicator at bit 25 of the UHR User info field;an unequal modulation (UEQM) pattern variation field at bits 32 to 33 of the UHR User info field;an uplink (UL) target receive power field at bits 34 to 38 of the UHR User info field; andtransmitting the UHR trigger frame to a client device.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field, the UHR User info field including:at least one UHR info subfieldat bits 32 to 33 of the UHR User info field; andan uplink (UL) target receive power field at bits 34 to 38 of the UHR User info field;andtransmitting the UHR trigger frame to a client device.The method of claim 31, wherein the at least one UHR info subfield includes one or more of:a modulation and coding scheme subfield,an equal modulation or unequal modulation indicator subfield,a distributed bandwidth subfield, andtwo low-density parity check flag subfields.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field, the UHR User info field including:a UHR info subfield at bit 25 and at bits 32 to 33 of the UHR User info field; andan uplink (UL) target receive power field at bits 34 to 38 of the UHR User info field;andtransmitting the UHR trigger frame to a client device.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field, the UHR User info field including:a spatial stream (SS) allocation field at bits 26 to 30 of the UHR User info field;an uplink (UL) target receive power field at bits 33 to 38 of the UHR User info field; andan equal modulation (EQM) pattern variation field or an unequal modulation (UEQM) pattern variation field at bits 31 to 32 of the UHR User info field;andtransmitting the UHR trigger frame to a client device.The method of claim 34, wherein bit 25 of the UHR user info field is an indicator of a presence of the EQM pattern variation field or the UEQM pattern variation field.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field, the UHR User info field including:a spatial stream (SS) allocation field at bits 26 to 30 of the UHR User info field;an uplink (UL) target receive power field at bits 33 to 38 of the UHR User info field; andat least one UHR info subfield at bits 31 to 32 of the UHR User info field;andtransmitting the UHR trigger frame to a client device.The method of claim 36, wherein the at least one UHR info subfield includes one or more of:a modulation and coding scheme subfield,an equal modulation or unequal modulation indicator subfield,a distributed bandwidth subfield, andtwo low-density parity check flag subfields.The method of claim 36, wherein bit 25 of the UHR user info field is an indicator of a presence of the UHR info subfield.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field, the UHR User info field including:a spatial stream (SS) allocation field at bits 26 to 30 of the UHR User info field;an uplink (UL) target receive power field at bits 31 to 35 of the UHR User info field;an indicator bit at bit 36, to indicate a presence of an equal modulation (EQM) pattern variation or an unequal modulation (UEQM) pattern variation; anthe EQM pattern variation or the UEQM pattern variation at bits 37 to 38;andtransmitting the UHR trigger frame to a client device.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field, the UHR User info field including:a spatial stream (SS) allocation field at bits 26 to 30 of the UHR User info field;an uplink (UL) target receive power field at bits 34 to 38 of the UHR User info field;an indicator bit at bit 38, to indicate a presence of an equal modulation (EQM) pattern variation or an unequal modulation (UEQM) pattern variation; andthe EQM pattern variation or the UEQM pattern variation at bits 32 to 33;andtransmitting the UHR trigger frame to a client device.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field, the UHR User info field including:a spatial stream (SS) allocation field at bits 26 to 30 of the UHR User info field,an uplink (UL) target receive power field at bits 31 to 35 of the UHR User info field; andat least one UHR info subfield at bits 36 to 38 of the UHR User info field;andtransmitting the UHR trigger frame to a client device.The method of claim 41, wherein the at least one UHR info subfield includes one or more of:a modulation and coding scheme subfield,an equal modulation or unequal modulation indicator subfield,a distributed bandwidth subfield, andtwo low-density parity check flag subfields.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having a UHR User info field, the UHR User info field including:a spatial stream (SS) allocation field at bits 26 to 30 of the UHR User info field,an uplink (UL) target receive power field at bits 34 to 38 of the UHR User info field; andat least one UHR info subfield at bits 31 to 33 of the UHR User info field;andtransmitting the UHR trigger frame to a client device.The method of claim 43, wherein the at least one UHR info subfield includes one or more of:a modulation and coding scheme subfield,an equal modulation or unequal modulation indicator subfield,a distributed bandwidth subfield, andtwo low-density parity check flag subfields.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having:a UHR User info field, the UHR Special User info field having:a 12-bit UHR station (STA) association identifier (AID) having a value; andbit 25 set to indicate a presence of an Extended UHR User info field; andthe Extended UHR User info field having:a 12-bit UHR STA AID with a same value as the value of 12-bit UHR STA AID of the UHR User info field;two or three bits to define unequal modulation (UEQM) patter variations; andtwenty five or twenty six bits defining UHR supported features;andtransmitting the UHR trigger frame to a client device.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having:a UHR User info field, the UHR Special User info field having:a 12-bit UHR station (STA) association identifier (AID) having a value;an uplink (UL) target receive power field at bits 32 to 36 of the UHR User info field;a reserved bit at bit 37; andan indicator bit at bit 38 to indicate a presence of an Extended UHR User info field; andthe Extended UHR User info field having:a 12-bit UHR STA AID with a same value as the value of 12-bit UHR STA AID of the UHR User info field;two or three bits to define unequal modulation (UEQM) patter variations; andtwenty five or twenty six bits defining UHR supported features;andtransmitting the UHR trigger frame to a client device.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having:a UHR User info field, the UHR Special User info field having:a 12-bit UHR station (STA) association identifier (AID) having a value;an uplink (UL) target receive power field at bits 32 to 37 of the UHR User info field; andan indicator bit at bit 38 to indicate a presence of an Extended UHR User info field; andthe Extended UHR User info field, the Extended UHR User info field having:a 12-bit UHR STA AID with a same value as the value 12-bit UHR STA AID of the UHR User info field;two or three bits to define unequal modulation (UEQM) patter variations; andtwenty five or twenty six bits defining at least one UHR supported feature; andtransmitting the UHR trigger frame to a client device.The method of claim 47, wherein the at least one UHR supported feature includes at least one of:an advanced UHR or Beyond User-Specific transmitter (TX) / receiver (RX) feature,one or more multiple-access point coordination feature,a non-primary channel access feature,a dynamic sub-band operation feature, anda dynamic power save feature.The method of claim 48, wherein the at least one multiple-access point coordination scheme includes one or more of:a coordinated spatial reuse scheme,coordinated beamforming scheme,coordinated time division multiple access scheme, andcoordinated restricted target wake time scheme.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having:a UHR User info field, the UHR Special User info field having:a 12-bit UHR station (STA) association identifier (AID) having a value;a spatial stream allocation field at bits 26 to 30 of the UHR User info field; andan indicator bit at bit 31 to indicate a presence of an Extended UHR User info field; andthe Extended UHR User field, the Extended User info field having:a 12-bit UHR STA AID with a same value as the value of the 12-bit UHR STA AID of the UHR User info field;two or three bits to define unequal modulation (UEQM) patter variations; andtwenty five or twenty six bits defining UHR supported features;andtransmitting the UHR trigger frame to a client device.The method of claim 50, wherein the at least one UHR supported feature includes at least one of:an advanced UHR or Beyond User-Specific transmitter (TX) / receiver (RX) feature,one or more multiple-access point coordination feature,a non-primary channel access feature,a dynamic sub-band operation feature, anda dynamic power save feature.The method of claim 51, wherein the at least one multiple-access point coordination scheme includes one or more of:a coordinated spatial reuse scheme,coordinated beamforming scheme,coordinated time division multiple access scheme, andcoordinated restricted target wake time scheme.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having:a UHR User info field, the UHR Special User info field having:a 12-bit UHR station (STA) association identifier (AID) having a value;a spatial stream allocation field at bits 27 to 31 of the UHR User info field; andan indicator bit at bit 26 to indicate a presence of an Extended UHR User info field; andthe Extended UHR User info field, the Extended UHR User info field having:a 12-bit UHR STA AID with a same value as the value of the 12-bit UHR STA AID of the UHR User info field;two or three bits to define unequal modulation (UEQM) patter variations; andtwenty five or twenty six bits defining UHR supported features;andtransmitting the UHR trigger frame to a client device.The method of claim 53, wherein the at least one UHR supported feature includes at least one of:an advanced UHR or Beyond User-Specific transmitter (TX) / receiver (RX) feature,one or more multiple-access point coordination feature,a non-primary channel access feature,a dynamic sub-band operation feature, anda dynamic power save feature.The method of claim 54, wherein the at least one multiple-access point coordination scheme includes one or more of:a coordinated spatial reuse scheme,coordinated beamforming scheme,coordinated time division multiple access scheme, andcoordinated restricted target wake time scheme.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having:a UHR User info field, the UHR Special User info field having:a 12-bit UHR station (STA) association identifier (AID) having a value;a spatial stream allocation field at bits 26 to 30 of the UHR User info field;bits 31 to 32 defining EQM / UEQM pattern variations;bits 33 to 37 defining an uplink target receive power; andan indicator bit at bit 38 to indicate a presence of an Extended UHR User info field; andthe Extended UHR User info field, the Extended UHR User info field having:a 12-bit UHR STA AID with a same value as the value of the 12-bit UHR STA AID of the UHR User info field; andtwenty eight bits defining UHR supported features;andtransmitting the UHR trigger frame to a client device.The method of claim 56, wherein the at least one UHR supported feature includes at least one of:an advanced UHR or Beyond User-Specific transmitter (TX) / receiver (RX) feature,one or more multiple-access point coordination feature,a non-primary channel access feature,a dynamic sub-band operation feature, anda dynamic power save feature.The method of claim 57, wherein the at least one multiple-access point coordination scheme includes one or more of:a coordinated spatial reuse scheme,coordinated beamforming scheme,coordinated time division multiple access scheme, andcoordinated restricted target wake time scheme.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having:a UHR User info field, the UHR Special User info field having:a 12-bit UHR station (STA) association identifier (AID) having a value;a spatial stream allocation field at bits 26 to 30 of the UHR User info field;bits 31 to 32 defining EQM / UEQM pattern variations;bits 33 to 37 defining an uplink target receive power; andan indicator bit at bit 38 to indicate a presence of an Extended UHR User info field; andthe Extended UHR User info field, the Extended UHR User info field having:a 12-bit UHR STA AID with a same value as the value of the 12-bit UHR STA AID of the UHR User info field; andtwenty eight bits defining UHR supported features;andtransmitting the UHR trigger frame to a client device.The method of claim 59, wherein the at least one UHR supported feature includes at least one of:an advanced UHR or Beyond User-Specific transmitter (TX) / receiver (RX) feature,one or more multiple-access point coordination feature,a non-primary channel access feature,a dynamic sub-band operation feature, anda dynamic power save feature.The method of claim 60, wherein the at least one multiple-access point coordination scheme includes one or more of:a coordinated spatial reuse scheme,coordinated beamforming scheme,coordinated time division multiple access scheme, andcoordinated restricted target wake time scheme.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having:a UHR User info field, the UHR Special User info field having:a 12-bit UHR station (STA) association identifier (AID) having a value;a spatial stream allocation field at bits 26 to 30 of the UHR User info field;a UHR info subfield at bits 31 to 32;bits 33 to 37 defining an uplink target receive power; andan indicator bit at bit 38 to indicate a presence of an Extended UHR User info field; andthe Extended UHR User info field, the Extended UHR User info field having:a 12-bit UHR STA AID with a same value as the value of the 12-bit UHR STA AID of the UHR User info field; andtwenty eight bits defining UHR supported features;andtransmitting the UHR trigger frame to a client device.The method of claim 62, wherein the at least one UHR supported feature includes at least one of:an advanced UHR or Beyond User-Specific transmitter (TX) / receiver (RX) feature,one or more multiple-access point coordination feature,a non-primary channel access feature,a dynamic sub-band operation feature, anda dynamic power save feature.The method of claim 63, wherein the at least one multiple-access point coordination scheme includes one or more of:a coordinated spatial reuse scheme,coordinated beamforming scheme,coordinated time division multiple access scheme, andcoordinated restricted target wake time scheme.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having:a UHR User Station (STA) info field, the UHR User STA field being 10 bytes in length, the UHR User STA info field having:bit 40 set to zero;bit 51 set to one;a first UHR info subfield at bits 41 to 50; anda second UHR info subfield at bits 52 to 79;andtransmitting the UHR trigger frame to a client device.The method of claim 65, wherein bit 25 of the UHR User STA info field is one of:an MCS extension bit; ora TBD feature bit.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having a User info list, the User info list having multiple entries, each entry of the multiple entries having:a twelve-bit Association Identifier (AID12) field with a value set to 2007;a physical layer (PHY) version identifier with a value of ‘1’ to indicate physical protocol data units (PPDUs) are to have a UHR format;a Special User info field;a common AID12 set to a value not equal to 2007; andan Extended Special User info field,the Extended UHR Special User info field immediately following the UHR Special User info field;andtransmitting the UHR trigger frame to a client device.A method, comprising:forming an Ultra-High Reliability (UHR) trigger frame having a User info list, the User info list having multiple entries, each entry of the multiple entries having:a twelve-bit Association Identifier (AID12) field with a value set to 2007; anda 10-byte Special User info field;andtransmitting the UHR trigger frame to a client device.An apparatus, comprising:a processor configured to execute instructions stored, in a memory, to enable the apparatus to perform the method defined by any one of claims 1 to 68.
Citation Information
Patent Citations
Defining bit sources for ignored bits in trigger frames and releasing redundant beamforming bits
CN116601927A
Method and apparatus for transmitting and receiving PPDU on basis of trigger frame in wireless LAN system
WO2024150994A1
Method and device for transmitting / receiving PPDU in wide bandwidth on basis of trigger frame in wireless LAN system
WO2024167208A1