Communication device

Abstract

To improve the efficiency of uplink multi-user transmission.SOLUTION: A communication device includes a receiver that, during operation, receives a physical layer protocol data unit (PPDU) indicating duration information, and bandwidth information about one or more frequency channels on which the PPDU is received, and a transmitter that, during operation, transmits a frame on a frequency channel other than the one or more frequency channels on which the PPDU is received. The transmitter does not transmit the frame on the one or more frequency channels corresponding to the bandwidth information within a period indicated by the duration information.SELECTED DRAWING: Figure 7A

Description

[Technical field]

[0001] The present disclosure generally relates to communications apparatus and methods that utilize novel multi-channel virtual carrier sensing to enable more efficient use of the wireless medium when more than one wireless network is physically co-located. [Background technology]

[0002] The IEEE (Institute of Electrical and Electronics Engineers) 802.11 Working Group is currently standardizing next-generation WLAN (Wireless Local Area Network) technologies under the 802.11ax Task Group. The main goal of this task group is to improve the spectral efficiency to increase the system throughput / area in high density scenarios of access points (APs) and / or terminal stations (referred to as "non-AP STAs" or simply STAs in other documents). Devices based on the IEEE 802.11ax specification are commonly referred to as High Efficiency (HE) devices. Among the various proposed technologies, Orthogonal Frequency-Division Multiple Access (OFDMA) and uplink multi-user transmission are the two main technologies adopted by the IEEE 802.11ax task group to achieve the throughput improvement goal. An 802.11 WLAN that has an AP and at least one STA that has negotiated WLAN membership with that AP (known as the association process) is called a Basic Service Set (BSS).

[0003] Figure 1 shows an example of two 802.11ax BSSs 100 and 145, each including a HE AP and a number of HE STAs associated with the HE AP. A BSS that operates on the same channel as the channel of the STA's BSS and is partially or entirely within the radio coverage of the STA is known as an overlapping basic service set (OBSS). In Figure 1, BSS 145 is considered an OBSS with respect to STA2 120, assuming that STA2 120 is associated with AP1 101.

[0004] The Medium Access Control (MAC) protocol for 802.11 devices, including 802.11ax devices, uses a contention-based Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) protocol to share the wireless medium. CSMA involves the use of physical and virtual Carrier Sense (CS) mechanisms, while collision avoidance is achieved through the use of random backoff. The physical CS mechanism is provided by the physical layer (PHY) and involves actual sensing of the wireless medium (either Preamble Detection (PD) and / or Energy Detection (ED)). The virtual CS mechanism is provided by the MAC layer and utilizes the Network Allocation Vector (NAV).

[0005] The NAV holds a prediction of the future traffic on the medium based on duration information signaled in most IEEE 802.11 frames. This duration may be included in the MAC header and / or may be obtained from the Transmit Opportunity (TXOP) duration in the PHY header, if present. The TXOP duration represents the period during which a particular STA has the right to initiate a frame exchange sequence on the wireless medium. When either the physical or virtual CS indicates that the medium is busy, the device is not allowed to transmit signals except for certain frames such as Acknowledgment (Ack) frames or Block Acknowledgement frames. To improve the efficiency of the channel access mechanism in the presence of OBSS, 802.11ax approved the use of two NAVs. One is known as the intra-BSS NAV and the other is known as the basic NAV. The intra-BSS NAV is used to store the NAV value from the PHY protocol data unit (PPDU) identified as intra-BSS, i.e., the BSS with which the STA is associated, when applicable. On the other hand, the Basic NAV is used to store alternative NAV values, if applicable, from inter-BSS PPDUs, ie OBSS PPDUs or PPDUs that cannot be identified as intra-BSS or inter-BSS. [Prior art documents] [Non-patent literature]

[0006] [Non-Patent Document 1] IEEE802.11-15 / 0132r17,Specification Framework for TGax,May 2015 [Non-Patent Document 2] IEEE Std 802.11-2012 [Non-Patent Document 3] IEEE 802.11-16 / 0024r1, Proposed TGax draft specification [Non-Patent Document 4] IEEE 802.11-16 / 0054r1,UL MU CCA Response Summary of the Invention [Problem to be solved by the invention]

[0007] When a STA's basic NAV is set to a non-zero value by an OBSS transmission, the virtual CS indicates busy, so the Uplink Multi-User Channel Sensing (UL MU CS) rules prohibit the STA from transmitting HE trigger-based PPDUs on the RU assigned by the trigger frame, even if energy detection on the 20 MHz channel containing the assigned RU indicates that the channel is idle. This leads to lost transmission opportunities for the STA, thus reducing the efficiency of uplink multi-user transmission in the presence of OBSS traffic.

[0008] One non-limiting, exemplary embodiment of the present disclosure provides a communications apparatus and method that can help improve the efficiency of uplink multi-user transmissions in the presence of OBSS traffic.

[0009] In one general aspect, the technology disclosed herein includes a communications device, the communications device comprising: a receiver that operatively receives a PHY layer data unit including a duration field, the duration field including duration information indicating a duration during which the communications device is prohibited from transmitting high efficiency (HE) trigger-based (TB) PHY layer data units; a physical (PHY) layer circuit that operatively issues PHY-CCA (clear channel assessment) primitive parameters indicating a busy or idle bandwidth information for each subchannel within an operational bandwidth; and a medium access control (MAC) circuit that operatively updates a network allocation vector (NAV) value based on the duration information when the indicated duration is greater than a current NAV value and when it is determined that the communications device is not a target recipient of the received PHY layer data unit, and that operatively determines a busy / idle status of at least one subchannel including a resource unit (RU) through which the HE TB PHY layer data unit is to be transmitted based on the bandwidth information, the MAC circuitry updating the HE TB PHY layer data unit based on the updated NAV value and the busy / idle status of the at least one subchannel. The present invention features a communications device that operatively controls transmission of TB PHY layer data units.

[0010] These general and specific aspects may be implemented using devices, systems, methods, and computer programs, as well as any combination of devices, systems, methods, and computer programs.

[0011] The communications apparatus and methods described in this disclosure can help improve the efficiency of uplink multi-user transmissions in the presence of OBSS traffic.

[0012] Further benefits and advantages of the disclosed embodiments will become apparent from the specification and drawings. Benefits and / or advantages may be obtained individually through various embodiments and features of the specification and drawings, which need not all be provided in order to obtain one or more of such benefits and / or advantages. [Brief description of the drawings]

[0013] [Figure 1] 1 is a diagram of an overlapping wireless network to which embodiments of the present disclosure may be applied. [Diagram 2] FIG. 13 is a timing diagram of an exemplary frame exchange sequence highlighting the NAV setting procedure. [Figure 3A] FIG. 13 is a timing diagram of another example frame exchange sequence that clarifies how the two NAVs introduced in 802.11ax are updated. [Figure 3B] A diagram showing the naming convention for 20 MHz channels in wideband channels. [Figure 4] FIG. 1 is a diagram of an example uplink multi-user transmission illustrating UL MU CS rules in 802.11ax. [Diagram 5] FIG. 1 illustrates the technical problem addressed in the present disclosure. [Figure 6] 5 is a table illustrating how various parameters related to the UL MU CS mechanism are updated with respect to the frame sequence shown in FIG. 4. [Figure 7A] 4 is an example of a frame exchange sequence illustrating multi-channel virtual carrier sensing (CS) introduced in the first embodiment. [Figure 7B] 1 is a table showing an encoding scheme of the BW field of the NAV according to a first embodiment. [Figure 8A] 1 is a flowchart showing rules for a multi-channel virtual CS according to a first embodiment. [Figure 8B] 1 is a table illustrating how various parameters related to the UL MU CS mechanism are updated based on the modified multi-channel virtual CS rule according to the first embodiment. [Figure 9] FIG. 1 illustrates three overlapping wireless networks. [Figure 10A] 4 is an example of a frame exchange sequence illustrating a basic NAV update rule in the presence of multiple OBSSs according to the first embodiment. [Figure 10B]4 is a flowchart showing the basic NAV update rules in the presence of multiple OBSSs according to the first embodiment. [Figure 11A] 4 is an example of a frame exchange sequence illustrating alternative rules for updating the basic NAV in the presence of multiple OBSSs according to the first embodiment. [Figure 11B] 4 is a flow chart illustrating alternative rules for updating the primary NAV in the presence of multiple OBSSs according to a first embodiment. [Figure 11C] 4 is another flow chart illustrating alternative rules for updating the primary NAV in the presence of multiple OBSSs according to the first embodiment. [Figure 12] 11 is a table showing additional members proposed for the PHY-CCA.indication primitive according to the first embodiment. [Figure 13A] 11 is an exemplary UL MU transmission illustrating a second embodiment of the present disclosure. [Figure 13B] FIG. 11 is a diagram of a bitmap used to record channel conditions according to a second embodiment of the present disclosure. [Figure 14] 6 is an example of a frame exchange sequence illustrating multi-channel virtual carrier sensing (CS) introduced in a second embodiment. [Figure 15] FIG. 2 is a simplified block diagram of an example STA implementing the disclosed multi-channel virtual carrier sensing. [Figure 16] FIG. 2 is a detailed block diagram of an example STA implementing the disclosed multi-channel virtual carrier sensing. [Figure 17] 11 is an example of a frame exchange sequence illustrating multi-channel virtual carrier sensing (CS) according to a third embodiment. [Figure 18] 11 is a table illustrating how various parameters related to the UL MU CS mechanism are updated based on the modified multi-channel virtual CS rules according to the third embodiment. [Figure 19] 13 is a flowchart illustrating rules for a multi-channel UL MU CS mechanism according to a third embodiment. [Figure 20] 1 is a table listing how a STA obtains channel bandwidth information from a received PPDU. [Figure 21] 13 is a table showing additional members proposed for the PHY-CCA.indication primitive according to the third embodiment. [Figure 22] 13 is a format of a NAV held by a STA and an encoding of a TX_Allowed field according to a fourth embodiment. [Figure 23] 13 is an example of a frame exchange sequence illustrating multi-channel virtual carrier sensing (CS) according to a fourth embodiment. [Figure 24] FIG. 11 is another diagram illustrating the technical problem addressed in the present disclosure to better highlight the improvement made by the fourth embodiment. [Diagram 25] 13 is a table illustrating how various parameters related to the UL MU CS mechanism are updated based on the modified multi-channel virtual CS rules according to the fourth embodiment. [Figure 26] 13 is a flowchart illustrating rules for a multi-channel UL MU CS mechanism according to a fourth embodiment. [Figure 27] 13 is an example of a frame exchange sequence illustrating a basic NAV update rule in the presence of multiple OBSSs according to the fourth embodiment. [Figure 28] 13 is a flowchart showing the basic NAV update rules in the presence of multiple OBSSs according to a fourth embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] The present disclosure can be better understood with the aid of the following figures and embodiments: The embodiments described herein are merely exemplary in nature and are used to illustrate some of the possible applications and uses of the present disclosure and should not be construed as limiting the present disclosure with respect to alternative embodiments not explicitly described herein.

[0015] As explained earlier, multi-user transmission using OFDMA in both downlink and uplink directions is the main technique adopted by the IEEE 802.11ax task group to achieve its throughput improvement goal. In the downlink direction, multi-user transmission is relatively simple compared to the uplink direction, since the AP transmits all multi-user frames. The downlink (DL) multi-user PPDU consists of a wide-channel PHY header that carries information about the narrowband channel (known as a resource unit or RU) on which each individual PHY Service Data Unit (PSDU) is carried. Transmission in the uplink direction is more complex than in the downlink direction, because it requires time synchronization of transmissions from multiple STAs and also ensures that transmissions from different STAs do not interfere with each other, i.e., each STA must be assigned a unique RU. This is achieved in IEEE 802.11ax by a special control frame called a trigger frame transmitted by the AP.

[0016] The trigger frame includes information such as resource unit (RU) allocation, uplink (UL) PPDU length, and MCS used for UL transmission. In addition, the trigger frame also includes a "CS request subfield" that informs the STA whether carrier sensing is required before UL MU transmission. Upon receiving the trigger frame, the STAs that are assigned RUs in the trigger frame can transmit their respective UL frames of UL multi-user (MU) PPDUs after a period of Short Interframe Space (SIFS) from the end of the trigger frame. If the "CS request subfield" value in the trigger frame is 1, the STAs are requested to follow the uplink multi-user channel sensing (UL MU CS) procedure, which states that the STAs consider a virtual CS to participate in UL MU transmission and that the RUs are also requested to perform energy detection for all 20 MHz channels assigned to the STA. Only if the virtual CS is idle and all 20 MHz channels including the RUs assigned in the trigger frame are considered idle, the STA is allowed to transmit the HE trigger-based PPDU. If the 20 MHz channels are not all idle, the STA is not allowed to transmit on the assigned RU.

[0017] Referring to FIG. 1, two overlapping BSSs (OBSSs) are shown. The first BSS, BSS1 100, includes an AP, AP1 101, and four STAs, STA1 110, STA2 120, STA3 130, and STA4 140, associated with AP1. The second BSS, BSS2 145, includes an AP, AP2 102, and two STAs, STA5 150 and STA6 160, associated with AP2. Also, the circles around AP1 101 and AP2 102 represent the wireless coverage areas of AP1 and AP2, respectively. As can be seen from FIG. 1, STA2 120 is located at the edge of the wireless coverage of AP1, yet happens to be within the wireless coverage of AP2. Thus, with respect to STA2 120, BSS2 145 is considered an OBSS. The identity of the BSS to which a received frame belongs can be determined by the recipient of this frame by checking the BSS Color field in the PHY header of the HE PPDU carrying this frame, or by checking the Basic Service Set Identifier (BSSID) field in the MAC header of this frame.

[0018] FIG. 2 illustrates an exemplary frame exchange sequence 200 highlighting the 802.11 NAV setting procedure. AP1 101 wishes to transmit a data frame to STA1 110, and to protect the transmission, AP1 first transmits a Request To Send (RTS) frame to STA1, to which STA1 responds with a Clear To Send (CTS) frame, transmitted a period of Short Interframe Space (SIFS) after the end of the RTS frame. The Duration field in the RTS frame is set to a value indicating the period between the end of the RTS frame and the end of the Ack frame transmitted in response to the data frame. All STAs receiving the RTS frame, except for the intended recipient STA1, update their NAV to the value of the Duration field in the RTS frame if their existing NAV value is less. Similarly, all STAs receiving the CTS frame, except for the intended recipient AP1, update their NAV to the value of the Duration field in the CTS frame if their existing NAV value is less. In this way, all STAs within the radio coverage of AP1 and STA1 will have their NAV set. After successfully receiving the CTS frame, AP1 will transmit a data frame SIFS after the end of the CTS frame, to which STA1 will respond with an Ack frame. STA2 120 and all other STAs that received the RTS / CTS frame will not be allowed to transmit to them for this duration, since they have their NAV set, thus ensuring that the transmission of data frames by AP1 is protected.

[0019] FIG. 3A illustrates an exemplary frame exchange sequence 300 within the two BSSs 100 and 145 of FIG. 1, highlighting the procedure for updating the two types of NAVs introduced in 802.11ax: intra-BSS NAV and basic NAV. Maintaining two types of NAVs allows for more efficient spatial reuse of frequency resources under certain conditions. The example shows two ongoing transmission sequences: the first is TXOP1 310 in BSS1 100 between AP1 101 and STA1 110, and the second is a second TXOP2 340 in BSS2 145 between AP2 102 and STA5 150. Upon receiving DL PPDU 312, STA2 120 determines, by checking either the BSS color field or the BSSID field, or both, that PPDU 312 is an intra-BSS PPDU, and because STA2 is not the recipient of PPDU 312, STA2 sets its intra-BSS NAV, NAV1 320, to a value indicative of the period between the end of DL PPDU 312 and the end of TXOP1. Similarly, upon receiving DL PPDU 342, by checking either the BSS color field or the BSSID field, or both, STA2 determines that PPDU 342 is an inter-BSS PPDU, and STA2 sets its inter-BSS NAV, NAV2 330, to a value indicative of the period between the end of DL PPDU 342 and the end of TXOP2.

[0020] Referring to FIG. 3B, the naming convention of the 20 MHz channels in an 802.11 infrastructure BSS operating in 40 MHz, 80 MHz, or 80+80 MHz or 160 MHz channels is shown. This is just one example of how wide bandwidth channels can be formed, and many other similar configurations are possible. When the BSS is first set up, one of the 20 MHz channels 350 is designated as the primary 20 MHz channel. The primary 20 MHz channel, also referred to simply as the primary channel, has a very important meaning. The IEEE 802.11 specification requires that all transmissions in the infrastructure BSS include the primary 20 MHz channel, except in the case of uplink OFDMA-based multi-user transmissions, where STAs may be permitted to transmit their uplink PPDUs on channels that do not include the primary 20 MHz channel.

[0021] Furthermore, in an infrastructure BSS, all beacon frames are transmitted on the primary 20 MHz channel. 20 MHz channels other than the primary 20 MHz channel are referred to as non-primary channels. A 20 MHz channel 355 adjacent to the primary 20 MHz channel, which together form the 40 MHz channel of a 40 MHz BSS or the primary 40 MHz of a wider BSS, is referred to as a secondary 20 MHz channel or simply a secondary channel. In an 80 MHz BSS or wider BSS, the primary 20 MHz channel 350 and the secondary 20 MHz channel 355 together form the primary 40 MHz channel. In an 80 MHz BSS or wider BSS, a 40 MHz channel adjacent to the primary 40 MHz channel (consisting of the two 20 MHz channels 360 and 365) which together form the 80 MHz channel of an 80 MHz BSS or the primary 80 MHz channel of a wider BSS, is referred to as a secondary 40 MHz channel. In an 80+80MHz BSS or 160MHz BSS, the primary 40MHz channel and the secondary 40MHz channel together form the primary 80MHz channel. In an 80+80MHz BSS or 160MHz BSS, the 80MHz channel not including the primary 20MHz channel 350 (consisting of the four 20MHz channels 370, 375, 380, and 385) which together with the primary 80MHz channel form the 80+80MHzz channel or 160MHz channel is called the secondary 80MHz channel. In a 160MHz channel, the primary 80MHz channel and the secondary 80MHz channel are adjacent to each other, whereas in an 80+80MHz channel, the primary 80MHz channel and the secondary 80MHz channel need not be adjacent to each other and may be located in different parts of the operating frequency band.

[0022] Referring to Figure 4, an exemplary UL MU transmission sequence 400 is shown to clarify the UL MU CS procedure in 802.11ax. An uplink multi-user (UL MU) transmission is initiated by the AP by transmitting a special control frame called a trigger frame 410. The trigger frame 410 contains information such as resource unit (RU) allocation, PPDU length, MCS, etc., used by the STAs for UL transmission. Upon receiving the trigger frame 410, the STAs that have been assigned RUs in the trigger frame can transmit their respective UL frames of the UL multi-user PPDU after a SIFS period from the end of the trigger frame without having to contend for the wireless medium.

[0023] The UL MU CS procedure in 802.11ax states that a STA that is assigned an RU in a trigger frame with the CS request field set to 1 to participate in UL MU transmission is requested to consider the virtual CS and also performs energy detection based clear channel assessment (ED-based CCA) on all 20 MHz channels that the RU is assigned to. The STA is allowed to transmit its UL PPDU (HE trigger-based PPDU) only if the virtual CS is idle and furthermore, all 20 MHz channels including the assigned RU are deemed idle by ED-based CCA. If the 20 MHz channels are not all idle, the STA is not allowed to transmit on the assigned RU. If the counter values ​​of both the intra-BSS NAV and the basic NAV are zero, the virtual CS is deemed idle. In this example, let us assume that the BSS1 100 in FIG. 1 is operating on 80 MHz channels, and CH1, CH2, CH3, and CH4 denote the primary 20 MHz channel, the secondary 20 MHz channel, the tertiary 20 MHz channel, and the quaternary 20 MHz channel. In 802.11 terminology, CH1 is called the primary 20 MHz channel or simply the primary channel, CH2 is called the secondary 20 MHz channel or simply the secondary channel, and CH3 and CH4 together form the secondary 40 MHz channel.

[0024] At the moment the STAs receive the trigger frame 410 from AP1 101, there is no ongoing transmission on the primary 20 MHz channel CH1 within the radio coverage areas of STA1, STA2, STA3, and STA4, and both the intra-BSS NAV and the basic NAV of all four STAs are set to zero. However, there is an ongoing transmission on CH3 within the radio coverage area of ​​STA2, as shown by 460. AP1 101 initiates the UL MU transmission sequence by transmitting the trigger frame 410, which assigns one 106-tone RU on CH1 to STA1 110 and STA4 140, respectively, one 242-tone RU on CH2 to STA3 130, and one 484-tone RU covering CH3 and CH4 to STA2 120. Since both the ED-based CCA and the virtual CS return idle, STA1, STA3, and STA4 transmit their respective UL PPDUs 420, 440, and 430. However, for STA2, the virtual CS returns idle, but the ED-based CCA returns busy on CH3. Since not all 20 MHz channels containing RUs assigned to STA2 are idle, STA2 is prohibited from transmitting its UL PPDU 450 according to the UL MU CS rules.

[0025] 5 illustrates an exemplary UL MU transmission sequence 400 in slightly different channel conditions. At the moment the STAs receive the trigger frame 410 from AP1 101, there are no ongoing transmissions on the primary 20 MHz channel within the radio coverage areas of STA1, STA3, and STA4, and both the STAs' intra-BSS NAV and basic NAV are set to zero. However, as illustrated by the transmission sequence 500, there is an ongoing OBSS transmission on the primary channel CH1 and secondary channel CH2 within the radio coverage area of ​​STA2 in BSS2 145. AP2 102 initiates a UL MU transmission in BSS2 by transmitting a trigger frame 510 to assign RUs to STA5 150 and STA6 160. After a SIFS from the trigger frame 510, STA5 and STA6 transmit their respective UL PPDUs on their respective assigned RUs. Upon receiving the DL PPDU carrying the trigger frame 510, STA2 determines that it is an OBSS PPDU and sets its basic NAV to a non-zero value.

[0026] Table 600 in FIG. 6 lists various parameters related to the UL MU CS mechanism for STA2 during the UL MU transmission sequence shown in FIG. 5. Since the transmission on the primary channel CH1 belongs to the OBSS, the basic NAV of STA2 is set to a non-zero value and the virtual CS indicates busy even though the intra-BSS NAV is zero. Similarly, the ED-based CCA returns busy on CH1 and CH2 and idle on CH3 and CH4. According to the UL MU CS rules, even though there is no ongoing transmission on both channels (CH3 and CH4) including the RU for STA2, the virtual CS indicates busy, so the UL MU CS considers the medium to be busy on all four 20 MHz, and as a result, the transmission of STA2's UL PPDU 450 is not allowed. This can be considered as a case where the basic NAV is overprotected. That is, even if STA2 was allowed to transmit its UL PPDU 450 on CH3 and CH4, its transmission would not have caused any interference to the OBSS transmission and would have resulted in a higher channel utilization efficiency.

[0027] The drawbacks presented above are caused by the fact that NAV (Baseline NAV or Intra-BSS NAV or Basic NAV) is based exclusively on the activity of the primary 20MHz channel and does not consider / provide information about the state of non-primary channels. As long as the primary 20MHz is busy by the reception of correct PPDUs, the NAV is set and the state of the remaining secondary channels is not recorded. Since 802.11ax introduces OFDMA-based narrowband transmission, channel reuse efficiency can be further improved if this overprotection can be avoided.

[0028] Based on the above findings, the inventors of the present application have arrived at the present disclosure. A communication method and a communication device are disclosed that improve the efficiency of uplink multi-user transmission in the presence of OBSS traffic. According to the disclosed method, a frequency dimension is added to the NAV, which not only records the duration during which a primary channel forming a part of the wideband channel is busy, but also records which other non-primary channels of the wideband channel are busy. By referring to this busy channel information, the STA can easily infer which channels are idle and can be used for simultaneous transmission without causing interference to the busy channels.

[0029] Various embodiments for efficient multi-channel virtual carrier sensing proposed in this disclosure are described in detail in the following paragraphs.

[0030] <First embodiment> As pointed out earlier, currently, NAV (Baseline NAV or Intra-BSS NAV or Basic NAV) is solely based on the activity of the primary 20 MHz channel and does not consider / provide information about the status of non-primary channels. As long as the primary 20 MHz channel is busy by the reception of a correct PPDU, the NAV is set and the status of the remaining non-primary channels is not recorded. To overcome this limitation of the current NAV mechanism, the first embodiment adds a frequency dimension to the NAV so that the NAV not only records the duration that the primary channel is busy, but also records the non-primary channels that are busy. For this purpose, a field called BW (bandwidth) is added to the NAV to record the bandwidth information of the PPDU or frame that sets the NAV. Since the bandwidth of the PPDU that sets the NAV always includes the primary 20 MHz channel, the BW field indicates which non-primary channels are busy. With this information of busy channels, the STA can easily infer which channels are idle and can be used for simultaneous transmission without causing interference to the busy channels.

[0031] Referring to FIG. 7A, a series of exemplary frame exchange sequences are shown to visually illustrate the concept of frequency dimension of NAV in 80 MHz BSS. The top half of FIG. 7A shows three transmission sequences of different bandwidths, namely 80 MHz TXOP1 712, 40 MHz TXOP2 722, and 20 MHz TXOP3 732. Each transmission sequence includes an exchange of PPDUs between the AP and one or more STAs that belong to the same BSS as this AP. As an example, the first PPDU of the transmission sequence may be a trigger frame that assigns a RU to the selected STA for UL MU transmission, followed by a HE trigger-based PPDU from the STA, and ending with a DL PPDU from the AP carrying an acknowledgment frame. In this example, CH1, CH2, CH3, and CH4 represent the primary 20 MHz channel, the secondary 20 MHz channel, the tertiary 20 MHz channel, and the quaternary 20 MHz channel, respectively. The bottom half of FIG. 7A visually represents the two-dimensional NAV held by a third-party STA as proposed by the present disclosure. The relevant time points in this example are indicated by t0, t1, t2, t3, t4, and t5.

[0032] A STA that is within radio coverage of an ongoing transmission and is neither the sender nor the receiver of that transmission is considered a third party STA with respect to that transmission. Upon receiving the first PPDU 710 of TXOP1 712, a third party STA determines that it is not itself the receiver of the PPDU 710, for example, by reading the receiver address in the MAC header of the frame carried by the PPDU or by reading the AID12 subfield of the user information field of a trigger frame carried in the PPDU 710.

[0033] If the STA determines, according to existing NAV rules, that it is not the recipient of the PPDU 710, it sets the NAV duration to the time period from time t0 to time t1, which prohibits the STA from transmitting until time t1, the end of TXOP1 712. In addition to recording the NAV duration, according to the first embodiment, the STA also records the bandwidth of the received PPDU 710, 80 MHz, as the BW field of the NAV. The two-dimensional NAV is represented by box 714, which represents the time period and frequency range in which the STA is prohibited from transmitting. At time t1, when the NAV duration counts down to zero, the BW field is also reset to zero.

[0034] Similarly, upon receiving PPDU 720, the STA sets its NAV duration to the time period from time t2 to time t3, the end of TXOP2 722, while the BW field is set to 40 MHz, which is the bandwidth of PPDU 720. This is shown as box 724. Furthermore, if the channel sensing rules are modified accordingly, under certain conditions, third party STAs may be allowed to transmit on unoccupied channels CH3 and CH4 within the NAV duration from t2 to t3 without causing interference to the ongoing transmission 722. This promotes more efficient reuse of unoccupied secondary channels.

[0035] At time t3, when the NAV duration counts down to zero, the BW field is also reset to zero. Similarly, upon receiving the PPDU 730, the STA sets the NAV duration to the time period from time t4 to time t5, which is the end of TXOP3 732, while the BW field is set to 20 MHz, which is the bandwidth of the PPDU 730. This is shown as box 734. In this case, the third party STA may be allowed to transmit on the unoccupied channels CH2, CH3, and CH4 within the NAV duration from t4 to t5 without causing interference to the ongoing transmission 732. At time t5, when the NAV duration counts down to zero, the BW field is also reset to zero.

[0036] FIG. 7B shows a table 750 of example encodings of the BW field. Using two bits, the BW field can represent four different bandwidths supported by 802.11ax. A value of 0 indicates a busy primary of 20 MHz, a value of 1 indicates a busy primary of 40 MHz, a value of 2 indicates a busy primary of 80 MHz, and a value of 3 indicates that the entire 160 MHz channel or the 80+80 MHz channel is busy. According to the BW encodings listed in 750, in the example shown in FIG. 7A, the BW field is set to 2 for NAV setting 714, 1 for NAV setting 724, and 0 for NAV setting 734.

[0037] The concept of adding a frequency dimension to the NAV can be easily extended to the two NAVs described in Figure 3A. One of the NAVs or both NAVs can be extended to record the bandwidth of ongoing transmissions in the respective BSS. Referring back to Figure 5, the overprotected NAV that prohibited STA2 from transmitting UL PPDU 450 can be overcome by applying the concept of recording the bandwidth of ongoing OBSS transmissions as the BW field of the basic NAV while making modifications to the virtual CS rules and UL MU CS mechanism.

[0038] As explained above, in the example shown in Figure 5, the primary NAV of STA2 is set to a non-zero value the moment it receives the trigger frame 410 from AP1 101, which results in the virtual CS being busy for STA2. According to the current UL MU CS rules, since the virtual CS indicates busy even though there is no ongoing transmission on CH3 and CH4, the UL MU CS mechanism considers the medium to be busy on all four channels, and as a result, the transmission of STA2's UL PPDU 450 is not allowed, even though both channels including the RU for STA2 are not busy. The current virtual CS rules indicate busy for the entire wideband channel as long as either one of the NAVs is busy, regardless of the actual state of the non-primary channels.

[0039] FIG. 8A shows a flow chart 800 illustrating how a virtual CS rule can be indicated for each 20 MHz channel by adding a bandwidth field to the basic NAV. Starting with the primary 20 MHz channel, for each 20 MHz channel of the wideband channel where a trigger frame is received, the process begins at step 810 when the STA receives a trigger frame with the CS request field set to 1 and assigning an RU to the STA. Because the CS request field is set to 1 in the trigger frame, the STA is requested to perform UL MU CS before transmitting a HE trigger-based PPDU on the assigned RU. If the intra-BSS NAV is non-zero at step 820, the process proceeds to step 830, which indicates that the virtual CS is busy for that 20 MHz channel, and the process ends and proceeds to the next 20 MHz channel, if any. However, if the intra-BSS NAV is zero at step 820, the process proceeds to step 840.

[0040] If the basic NAV duration is zero at step 840, the process proceeds to step 870 where the virtual CS indicates idle for that 20 MHz channel, the process ends, and proceeds to the next 20 MHz channel, if any. However, if the basic NAV is non-zero at step 840, the process proceeds to step 850. If the 20 MHz channel is indicated as one of the busy channels by the BW field of the basic NAV at step 850, the process proceeds to step 860 where the virtual CS indicates busy for that 20 MHz channel, the process ends, and proceeds to the next 20 MHz channel, if any. However, if the 20 MHz channel is not indicated as one of the busy channels by the BW field of the basic NAV at step 850, the process proceeds to step 870 where the virtual CS indicates idle for that 20 MHz channel, the process ends, and proceeds to the next 20 MHz channel, if any. Since the modified virtual CS rule allows a virtual CS to be announced for each individual 20 MHz channel, the UL MU CS mechanism is also modified to announce busy / idle for each individual 20 MHz channel. If either energy-detect (ED) or virtual CS returns busy on a particular 20 MHz channel, that 20 MHz channel is considered busy.

[0041] If both energy detection (ED) and virtual CS return idle on a particular 20 MHz channel, that 20 MHz channel is considered idle. However, the UL MU transmission rules remain unchanged. That is, a STA is only allowed to transmit an HE trigger-based PPDU on an assigned RU by a trigger frame with the CS request field set to 1 if all 20 MHz channels, including the assigned RU, are idle. If not all 20 MHz channels, including the assigned RU, are idle, the STA is not allowed to transmit anything on the assigned RU.

[0042] Table 880 of FIG. 8B lists various parameters related to the modified UL MU CS mechanism for STA2 during the UL MU transmission sequence shown in FIG. 5. Compared to table 600 of FIG. 6, table 880 includes one additional column 882 indicating the state of the channel based on the BW field of the basic NAV. Since the transmission on the primary channel belongs to the OBSS, the Intra-BSS NAV of STA2 is zero, while the duration field of the basic NAV is set to the indicated duration of the OBSS transmission. As shown in the transmission sequence 500 of FIG. 5, since the OBSS transmission occurs only on CH1 and CH2, the BW field of the basic NAV is set to 1 (40 MHz). This means that CH1 and CH2 are marked as busy.

[0043] Similarly, CH3 and CH4 are recorded as idle, as indicated by statements 884 and 886, respectively. According to the modified virtual CS rules described in FIG. 8A, the virtual CS returns busy on CH1 and CH2 and idle on CH3 and CH4. Similarly, the ED-based CCA returns busy on CH1 and CH2 and idle on CH3 and CH4. According to the modified UL MU CS rules, since both the virtual CS and the ED-based CCA indicate busy on CH1 and CH2 and idle on CH3 and CH4, the UL MU CS mechanism considers CH1 and CH2 to be busy, while CH3 and CH4 are considered to be idle, as indicated by statements 888, 890, 892, and 894, respectively. Since CH3 and CH4 are considered to be idle, according to the UL MU CS transmission rules, STA2 is allowed to transmit its UL PPDU 450 on the assigned RUs of CH3 and CH4.

[0044] Figure 9 is based on the overlapping wireless network shown in Figure 1. Apart from BSS1 100 and BSS2 145, an additional BSS, BSS3 900, is shown. BSS3 900 includes AP3 901 and two STAs, namely STA7 910 and STA8 920. Since STA2 120 is also within the radio coverage of AP3 901, BSS3 900 is also considered as an OBSS with respect to STA2. The arrangement of BSSs in Figure 9 is used to explain the rules for updating the NAV bandwidth field introduced in this disclosure. Two options can be considered for updating the NAV bandwidth field BW.

[0045] Option 1 (Static Update): The BW field is always set to the maximum bandwidth of the NAV setting PPDU of an ongoing third-party transmission. A third-party transmission refers to a transmission within the reception range of the STA where the STA is neither the sender nor the receiver of that transmission. A NAV setting PPDU refers to a PPDU that carries at least one frame that may result in a change in the STA's NAV counters (either duration or BW or both). When a new NAV setting PPDU is received, if the bandwidth of the new PPDU is wider than the existing BW field, the BW field is updated to the wider bandwidth. However, if the bandwidth of the new PPDU is narrower than the existing BW field, the BW field is not changed. The BW field is updated independently of the NAV duration. That is, even if the new PPDU does not update the NAV duration, if the bandwidth of the new PPDU is wider than the existing BW field, the BW field is updated.

[0046] Option 2 (Dynamic Update): The BW field is dynamically adjusted to reflect the actual bandwidth of the NAV setting PPDU of an ongoing third party transmission. This option is more complex compared to option 1 and requires temporary recording of the bandwidth and duration of each received third party transmission. While the NAV duration is always set to the longest duration of all ongoing third party transmissions, the bandwidth field is checked at the end of the relevant third party transmission and updated to the actual bandwidth of the next section of the ongoing transmission.

[0047] Referring to Figure 10A, a series of exemplary frame exchange sequences are shown to visually illustrate the above-mentioned rules of option 1 (static update) for the bandwidth field of the basic NAV of STA2 in the BSS arrangement shown in Figure 9, and it is assumed that all three BSSs, BSS1 100, BSS2 145, and BSS3 900, are 80 MHz BSSs. The upper part of Figure 10A shows two transmission sequences of different bandwidths in BSS2 145, namely TXOP1 1012 at 80 MHz and TXOP2 1022 at 40 MHz. Similarly, the lower part of Figure 10A shows two transmission sequences of different bandwidths in BSS3 900, namely TXOP3 1032 at 20 MHz and TXOP4 1034 at 80 MHz.

[0048] The center part of FIG. 10A shows a visual representation of a two-dimensional basic NAV maintained by STA2 120 as proposed by the present disclosure. The relevant time points in this example are indicated by t0, t1, t2, t3, t4, t5, t6, and t7. Upon receiving the first PPDU 1010 of TXOP1 1012, based on the BSS color field in the PHY header or the BSSID field in the MAC header, STA2 determines that the PPDU 1010 is an OBSS PPDU from BSS2 and that STA2 is not one of the recipients of the PPDU 1010. Following the existing NAV rules for updating the NAV duration, STA2 sets the NAV duration from time t0 to time t2 and sets the NAV BW field to 80 MHz (the bandwidth of the received PPDU 1010), which results in STA2 being prohibited from transmitting on CH1, CH2, CH3, and CH4 until the end of TXOP1 1012 at time t2. The two-dimensional NAV is represented by box 1014, which represents the time periods and frequency ranges during which STA2 is prohibited from transmitting at time t0.

[0049] Upon receiving the first PPDU 1030 of TXOP3 1032, STA2 determines that 1030 is an OBSS PPDU from BSS3, which is not one of the recipients of PPDU 1030. Since the duration shown in 1030 is longer than the existing NAV duration, according to the NAV rules for updating the NAV duration, STA2 updates the NAV duration by time t3, which results in STA2 being prohibited from transmitting until the end of TXOP3 1032, time t3. From time t2 to time t3, the actual ongoing OBSS transmission is only on BSS3, but the NAV BW field indicates 80 MHz. This can be considered an over-protected zone 1016. In the over-protected zone 1016, STA2 is restricted from transmitting on all three channels, even though all of the channels CH2, CH3, and CH4 included in the zone 1016 are idle to STA2 from time t2 to time t3. At time t3, when the basic NAV duration counts down to zero, the NAV BW field is also reset to zero.

[0050] Similarly, upon receiving the first PPDU 1020 of TXOP2 1022, STA2 determines that 1020 is an OBSS PPDU from BSS2 and that it is not one of the recipients of PPDU 1020. Following the existing NAV rules for updating the NAV duration, STA2 sets the NAV duration to from time t4 to time t7 and sets the NAV BW field to 40 MHz (the bandwidth of the received PPDU 1020), which results in STA2 being prohibited from transmitting on CH1 and CH2 until time t7, which is the end of TXOP2 1022.

[0051] The two-dimensional NAV is represented by box 1024, which represents the time period and frequency range in which STA2 is prohibited from transmitting at time t4. Upon receiving the first PPDU 1034 of TXOP4 1036, STA2 determines that 1034 is an OBSS PPDU from BSS3 and that it is not one of the recipients of PPDU 1034. Because the duration shown in 1034 is shorter than the existing NAV duration, STA2 does not update the NAV duration, per the NAV rules for updating the NAV duration. However, because the bandwidth of PPDU 1034 is wider than the current NAV BW field, the BW field is updated to 80 MHz as shown by 1026 and remains as 80 MHz until time t7.

[0052] From time t6 to time t7, actual ongoing OBSS transmissions are only on BSS2, but the NAV BW field indicates 80 MHz. This can be considered an over-protected zone 1028. In the over-protected zone 1028, STA2 is restricted from transmitting on channels CH3 and CH4 included in the zone 1028, even though both of these channels are idle for STA2 from time t6 to time t7. However, when the OBSS transmissions are of narrower bandwidth channels, option 1 still allows more efficient reuse of secondary channels compared to the existing UL MU CS mechanism. At time t7, when the basic NAV duration counts down to zero, the NAV BW field is also reset to zero.

[0053] The NAV update rule according to option 1 is summarized by the flow chart 1040 in FIG. 10B. The process starts at step 1042, where a NAV setting PPDU is received. At step 1044, if the PPDU increases the duration field of the basic NAV, the process proceeds to step 1046. At step 1046, the basic NAV duration is updated according to the relevant duration information in the PPDU (e.g., based on the TXOP duration field in the PHY header or the duration field in the MAC header), and the process proceeds to step 1048. At step 1044, if the PPDU does not increase the duration field of the basic NAV, the process proceeds to step 1048. At step 1048, if the received PPDU increases the BW field, the process proceeds to step 1050, otherwise the process ends. At step 1050, the BW field of the basic NAV is updated to reflect the bandwidth of the received PPDU, and the process ends.

[0054] 11A, the same exemplary transmission sequence shown in FIG. 10A is reused to visually illustrate the above-mentioned rules of option 2 (dynamic update) for the bandwidth field of STA2's basic NAV. Upon receiving the first PPDU 1010 of TXOP1 1012, based on the BSS color field in the PHY header or the BSSID field in the MAC header, STA2 determines that 1010 is an OBSS PPDU from BSS2, which is not one of the recipients of PPDU 1010. Following the existing NAV rules for updating the NAV duration, STA2 sets the NAV duration from time t0 to time t2 and sets the NAV BW field to 80 MHz (the bandwidth of the received PPDU 1010), which results in STA2 being prohibited from transmitting on CH1, CH2, CH3, and CH4 until the end of TXOP1 1012 at time t2.

[0055] The two-dimensional NAV is represented by box 1110, which represents the time period and frequency range in which STA2 is prohibited from transmitting at time t0. Upon receiving the first PPDU 1030 of TXOP3 1032, STA2 determines that 1030 is an OBSS PPDU from BSS3, which is not one of the recipients of PPDU 1030. Since the duration shown in 1030 is longer than the existing NAV duration, according to the NAV rules for updating the NAV duration, STA2 must update the NAV duration by time t3. However, from time t2 to time t3, the actual ongoing OBSS transmission is only in BSS3, and therefore, before the NAV duration is updated by t3, the end time t2 of the current NAV duration is recorded as a temporary variable BW_update_time, and a timer (BW_update_timer) is set to expire at BW_update_time. Because the bandwidth of the PPDU 1030 is 20 MHz, which is less than the current NAV BW field, no change is made to the NAV BW field, but the bandwidth of the PPDU 1030 is saved as a temporary variable, New_BW. When the BW_update_timer expires at t2, the NAV BW field is updated to New_BW (20 MHz), which represents the actual bandwidth 1112 of the ongoing third-party transmission 1032.

[0056] As a result, the basic NAV does not restrict STA2 from transmitting on any of the three channels between time t2 and time t3 because CH2, CH3, and CH4 are all idle to STA2. Similarly, upon receiving the first PPDU 1020 of TXOP2 1022, STA2 determines that 1020 is an OBSS PPDU from BSS2, which is not one of the recipients of PPDU 1020. In accordance with the existing NAV rules for updating the NAV duration, STA2 sets the NAV duration to from time t4 to time t7 and sets the NAV BW field to 40 MHz (the bandwidth of the received PPDU 1020), resulting in STA2 being prohibited from transmitting on CH1 and CH2 until time t7, the end of TXOP2 1022. The two-dimensional NAV is represented by box 1024, which represents the time period and frequency range in which STA2 is prohibited from transmitting at time t4.

[0057] Upon receiving the first PPDU 1034 of TXOP4 1036, STA2 determines that 1034 is an OBSS PPDU from BSS3 and that it is not one of the recipients of PPDU 1034. Because the duration indicated in PPDU 1034 is shorter than the existing NAV duration, STA2 does not update the NAV duration, per the NAV rules for updating the NAV duration. However, because the bandwidth of PPDU 1034 is 80 MHz, which is wider than the current NAV BW field, the BW field must be updated to 80 MHz as shown by 1122. However, from time t6 to time t7, the bandwidth of the ongoing OBSS transmission 1022 is only 40 MHz, so before the NAV BW field is updated to 80 MHz, the current NAV BW is saved as New_BW, the end time t6 of BSS3's transmission 1036 is recorded as BW_update_time, and a timer (BW_update_timer) is set to expire at BW_update_time. When the BW_update_timer expires at time t6, the NAV BW field is updated to New_BW (40 MHz), which represents the actual bandwidth 1124 of the ongoing third party transmission 1022. As a result, the basic NAV does not restrict STA2 from transmitting on either of channels CH3 and CH4 from time t6 to time t7, since both of these channels are idle for STA2.

[0058] The NAV update rules according to option 2 are summarized by the flow chart 1140 in FIG. 11B and 1180 in FIG. 11C. The process starts at step 1142 where a NAV setting PPDU is received. At step 1144, if the PPDU increases the duration field of the basic NAV, the process proceeds to step 1146, otherwise the process proceeds to step 1162. At step 1146, if the bandwidth of the received PPDU is smaller than the basic NAV BW field, the process proceeds to step 1148, otherwise the process proceeds to step 1154. At step 1148, if the variable BW_update_time is zero, the expiration time of the current basic NAV is stored in the variable BW_update_time, otherwise if the variable BW_update_time is non-zero, the smaller of the two values, i.e. BW_update_time or the expiration time of the current basic NAV is stored in BW_update_time and the process proceeds to step 1150. In step 1150 , the greater of the two values, New_BW or the bandwidth of the received PPDU, is stored in the variable New_BW and the process proceeds to step 1152 .

[0059] In step 1152, a timer called BW_update_timer is set to expire at BW_update_time and the process proceeds to step 1160. In step 1154, if the bandwidth of the received PPDU is greater than the basic NAV BW field, the process proceeds to step 1156, otherwise the process proceeds to step 1158. In step 1156, the basic NAV BW field is updated to the bandwidth of the received PPDU and the process proceeds to step 1158. In step 1158, since the bandwidth of the basic NAV is expected to remain unchanged until the end of the basic NAV duration, the BW_update_timer is stopped if running, both BW_update_time and New_BW are set to 0 and the process proceeds to step 1160. In step 1160, the basic NAV duration is updated according to the associated duration information in the PPDU (e.g., based on the TXOP duration field in the PHY header or the duration field in the MAC header) and the process ends.

[0060] In step 1162, if the bandwidth of the received PPDU is greater than the basic NAV BW field, the process proceeds to step 1164, otherwise the process ends. In step 1164, if the NAV expiration time according to the received PPDU is less than the expiration time of the basic NAV, the process proceeds to step 1168, otherwise the process proceeds to step 1170. In step 1168, the value of the basic NAV BW field is stored in a variable New_BW and the process proceeds to step 1170. In step 1170, the NAV expiration time according to the received PPDU is stored in a variable BW_update_time and the process proceeds to step 1172. In step 1172, the BW_update_timer is set to expire at BW_update_time and the process proceeds to step 1174. In step 1174, the basic NAV BW field is updated to the bandwidth of the received PPDU and the process ends.

[0061] The Basic NAV BW adjustment process is summarized by process 1180. Process 1180 begins at step 1182 where the BW_update_timer expires. At step 1184, if the Basic NAV duration is non-zero, the process proceeds to step 1186, otherwise the process proceeds to step 1190. At step 1186, if the value of New_BW is non-zero, the process proceeds to step 1188, otherwise the process proceeds to step 1190. At step 1188, the BW field of the Basic NAV is updated to New_BW and process 1180 ends. At step 1190, both BW_update_time and New_BW are set to 0 and process 1180 ends.

[0062] Referring to FIG. 12, table 1200 lists possible values ​​and meanings of the channel-list parameter of the PHY-CCA.indication primitive used by the HE STA. The PHY-CCA.indication(STATE,{channel-list}) primitive is used by the PHY layer of the HE STA to indicate the state of the channels to the MAC layer. The PHY-CCA.indication primitive always includes the STATE parameter, but includes the channel-list parameter only when the STATE parameter is BUSY and the state of multiple channels is indicated. The PHY-CCA.indication primitive indicates which channels are busy and which are idle within the BSS operating bandwidth. The first four values ​​of the channel-list parameter and their meanings are the same as those defined in the IEEE 802.11 specification, except that three values ​​primary20, primary40, and primary80 listed in lines 1210, 1220, and 1230, respectively, are added by the first embodiment of the present disclosure. Referring to FIG. 3B, a value of "primary" in the channel-list parameter indicates that the primary 20 MHz channel 350 and all other non-primary channels are busy.

[0063] A value of "secondary" indicates that the primary 20 MHz channel 350 is idle while the secondary 20 MHz channel 355 is busy. A value of "secondary40" indicates that the secondary 40 MHz channels (360 and 365) are busy while the primary 20 MHz channel 350 and the secondary 20 MHz channel 355 are idle. A value of "secondary80" indicates that the secondary 80 MHz channels (370, 375, 380, and 385) are busy while the primary 20 MHz channel 350, the secondary 20 MHz channel 355, and the two 20 MHz channels 360 and 365 that together form the secondary 40 MHz channel are idle. As mentioned earlier, a value of "primary" in the channel-list parameter indicates that the primary 20 MHz channel and all other non-primary channels that form part of the BSS operating channel are busy. In legacy 802.11 systems, all transmissions in the infrastructure BSS involve the primary 20 MHz channel, and STAs are not allowed to transmit as long as the primary 20 MHz channel is busy.

[0064] Thus, in a legacy 802.11 BSS, a busy primary 20 MHz channel is considered equivalent to all non-primary channels also being busy. However, for uplink OFDMA-based multi-user transmission in an 802.11ax BSS, a STA may be allowed to transmit its uplink PPDU on a channel that does not include a primary 20 MHz channel if the AP assigns an RU to the STA on a non-primary channel. As an example, referring to FIG. 4, in the trigger frame 410, the AP assigns an RU to STA3 on secondary channel CH2, and according to the 802.11ax UL MU transmission rules, STA3 is allowed to transmit its UL PPDU 440 on secondary channel CH2 if the UL MU CS considers CH2 idle. Three additional values ​​(primary20, primary40, and primary80) are added to the PHY-CCA.indication primitive to allow the STA's PHY layer to inform the status of the non-primary channels when the primary channel is busy. A value of "primary20" indicates that the primary 20 MHz channel 350 is busy while all remaining non-primary channels are idle. A value of "primary40" indicates that the primary 40 MHz channels (350, 355) are busy while all remaining non-primary channels are idle. A value of "primary80" indicates that the primary 80 MHz channels (350, 355, 360, and 365) are busy while all remaining non-primary channels are idle.

[0065] As an example, referring to FIG. 7A, when PPDU 710 is received, the PHY layer of the receiving STA issues a PHY-CCA.indication(BUSY,{primary}) primitive to the MAC layer to indicate that all four 20 MHz channels are busy. Then, when PPDU 720 is received, a PHY-CCA.indication(BUSY,{primary40}) primitive is issued to indicate that primary 20 MHz channel CH1 and secondary 20 MHz channel CH2 are busy, while channels CH3 and CH4 are idle. Similarly, when PPDU 730 is received, a PHY-CCA.indication(BUSY,{primary20}) primitive is issued to indicate that primary 20 MHz channel CH1 is busy, while channels CH2, CH3, and CH4 are idle. The MAC layer of the STA uses the information from the PHY-CCA.indication primitive to properly set the BW field of the NAV.

[0066] <Second embodiment> Referring to FIG. 13A, an example uplink multi-user transmission sequence 1300 illustrates a case where the bandwidth of a PPDU is changed during the same TXOP 1305. AP2 102 of FIG. 1 transmits an 80 MHz DL MU PPDU 1310 that contains, among other frames, two unicast trigger frames 1312 and 1314 addressed to STA5 150 and STA6 160, respectively. The trigger frame 1312 assigns an RU to STA5 on the primary channel CH1, while the trigger frame 1314 assigns an RU to STA6 on the secondary channel CH2. AP2 102 also protects subsequent uplink transmissions by setting either the TXOP duration in the PHY header of the PPDU 1310 or the duration field in the MAC header of the individual frames carried by the PPDU 1310 to the end of the TXOP 1305. SIFS after PPDU 1310, STA5 transmits its UL PPDU 1320 on CH1, while STA6 transmits its UL PPDU 1330 on CH2.

[0067] The AP completes the frame exchange by transmitting DL MU PPDUs carrying Ack frames 1340 and 1350 to STA5 and STA6, respectively. When an OBSS STA, e.g., STA2 120 in FIG. 1, receives the PPDU 1310, STA2 determines that the PPDU 1310 is an OBSS PPDU from BSS2 145. STA2 sets the basic NAV duration 1362 to the end of the TXOP 1305 based on the duration information in the PPDU 1310. However, if STA2 can decode the individual frames in the MU PPDU 1310, STA2 can predict the bandwidth of the subsequent uplink transmission. For example, by decoding the trigger frames 1314 and 1312, STA2 can determine that RUs are assigned to the uplink only on CH1 and CH2. Thus, STA2 can predict that the subsequent uplink transmission triggered by the PPDU 1310 will cover only CH1 and CH2. Thus, instead of setting the BW field of the basic NAV to 80 MHz, which is the bandwidth of the PPDU 1310, in accordance with the second embodiment, STA2 sets the BW field 1364 to 40 MHz, which is the expected bandwidth of the subsequent uplink transmission. This provides an opportunity for STA2 to utilize the idle secondary channels CH3 and CH4 for its own uplink transmissions. The two-dimensional basic NAV is visually indicated by the rectangle 1360.

[0068] 13B, the BW field of the NAV may be stored as an 8-bit bitmap 1390, one bit per 20 MHz channel. Using the 8 bits, the status of all 20 MHz channels used in an 802.11 BSS operating up to 160 MHz channels can be recorded. A busy state of a channel is recorded by setting the corresponding bit to 1, while an idle state is represented by 0.

[0069] Referring to FIG. 14, a series of exemplary frame exchange sequences are shown to visually illustrate a two-dimensional NAV according to the second embodiment in an 80 MHz BSS. The top half shows three transmission sequences with variable bandwidths, namely TXOP1 1412, TXOP2 1422, and TXOP3 1432. Each transmission sequence includes an exchange of PPDUs between the AP and one or more STAs that belong to the same BSS as this AP. As an example, the first PPDU of the transmission sequence may be a trigger frame that assigns a RU for UL MU transmission to the selected STA, followed by a HE trigger-based PPDU from the STA, and ending with a DL PPDU from the AP carrying an acknowledgment frame. In this example, CH1, CH2, CH3, and CH4 represent the primary 20 MHz channel, the secondary 20 MHz channel, the tertiary 20 MHz channel, and the quaternary 20 MHz channel. The bottom half of this example shows a visual representation of the two-dimensional NAV maintained by a third party STA as proposed by the present disclosure. Also shown is a bitmap used to record the BW field of the NAV. The relevant points in time in this example are indicated by t0, t1, t2, t3, t4, and t5. A STA that is within radio coverage of an ongoing transmission and is neither the sender nor the receiver of this transmission is considered a third party STA with respect to that transmission.

[0070] Upon receiving the first PPDU 1410 of TXOP1 1412, the third party STA determines that it is not the recipient of the PPDU 1410, for example, by reading the recipient address in the MAC header of the frame carried by the PPDU, or by reading the AID12 subfield of the user information field of the trigger frame carried in the PPDU 1410. According to the existing NAV rules, once the STA determines that it is not the recipient of the PPDU 1410, the STA sets the NAV duration from t0 to t1. In addition to recording the NAV duration, according to the second embodiment, the STA decodes the trigger frame in the PPDU 1410 and determines that RUs have been allocated on CH1, CH2, and CH3 for subsequent uplink transmission. Based on this, in the BW field of the NAV, the STA sets bits 0, 1, and 2 to 1 (busy) and the remaining bits to 0 (idle). The two-dimensional NAV is represented by box 1414 where the STA is prohibited from transmitting on CH1, CH2, and CH3 until time t1, which is the end of TXOP1 1412.

[0071] Similarly, upon receiving PPDU 1420, the STA sets its NAV duration to time t3, which is the end of TXOP2 1422. The STA decodes the trigger frame in PPDU 1420 and determines that it has been allocated RUs on CH1 and CH2 for subsequent uplink transmissions. Based on this, in the BW field of the NAV, the STA sets bits 0 and 1 to 1 (busy) and the remaining bits to 0 (idle). This is shown as box 1424, where the STA is prohibited from transmitting on CH1 and CH2 until time t3.

[0072] Similarly, when receiving the PPDU 1430, the STA sets the NAV duration until time t5, which is the end of the TXOP3 1432. The STA decodes the trigger frame within the PPDU 1430 and determines that an RU is allocated on CH1 for subsequent uplink transmissions. Based on this, in the BW field of the NAV, the STA sets bit 0 to 1 (busy) and the remaining bits to 0 (idle). This is shown as the box 1434 that prohibits the STA from transmitting on CH1 until time t5. In this case, a third-party STA may be permitted to transmit on the non-occupied channels CH2, CH3, and CH4 during the NAV duration from t4 to t5 without causing interference to the ongoing transmission 1432.

[0073] <STA Configuration> FIG. 15 is a block diagram of an exemplary STA 1500 that implements the two-dimensional NAV described in the present disclosure. This device may be any one of the STAs in FIG. 1. The STA 1500 includes a receiver 1502, a PPDU decoder 1504, a memory 1506, and a transmitter 1508.

[0074] The receiver 1502 receives PPDUs from other wireless devices within its wireless coverage area. The PPDU decoder 1504 examines each received PPDU to determine whether the PPDU was transmitted by a STA belonging to the corresponding BSS of the STA or by an OBSS STA. The PPDU decoder 1504 also determines whether the STA is the intended recipient of the PPDU, and if not, the PPDU decoder further extracts duration information from either the PHY header of the PPDU or the MAC header of the frame carried by the PPDU. The PPDU decoder also determines the bandwidth occupied by the received PPDU.

[0075] The STA 1500 may include one or more instances of memory 1506. The memory 1506 records duration information carried in the received PPDU and, if applicable, the bandwidth occupied by the PPDU. If the PPDU decoder determines that the received PPDU was transmitted by a STA from its corresponding BSS, the memory 1506 only records the duration information as an intra-BSS NAV. However, if the PPDU decoder determines that the received PPDU was transmitted by an OBSS STA, the memory 1506 records both the duration information and the bandwidth information as part of the basic NAV. When instructed, the transmitter 1508 transmits on a frequency channel other than the frequency channel indicated by the bandwidth information of the basic NAV without causing interference to the channel indicated by the bandwidth of the basic NAV.

[0076] FIG. 16 is a detailed block diagram of an example STA 1600 implementing the two-dimensional NAV described in this disclosure, which may be any one of the STAs of FIG. 1. The STA 1600, which is a wireless device, includes a Central Processing Unit (CPU) 1630 coupled to a memory 1620, a secondary storage 1640, and one or more wireless communication interfaces 1650. The secondary storage 1640 may be a non-volatile computer-readable storage medium used to persistently store relevant instruction code, data, and the like. Upon startup, the CPU 1630 may copy instruction code and relevant data to the volatile memory 1620 for execution. The instruction code may be an operating system, user applications, device drivers, executable code, and the like required for the operation of the STA 1600. The STA 1600 may also include a power source 1610, such as a lithium-ion battery or a coin cell battery, or it may be a mains electricity.

[0077] The wireless communication interface 1650 may comprise an interface for cellular communication or an interface for a short-range communication protocol such as Zigbee, or it may be a WLAN interface. The wireless interface 1650 may further comprise a MAC module 1652, a PHY module 1660, and an antenna 1670. Among other sub-modules, the MAC module 1652 may comprise a carrier sense module 1654, a NAV bandwidth bitmap 1656, and a NAV duration counter 1658. The NAV bandwidth bitmap 1656 and the NAV duration counter 1658 are used to record bandwidth and duration information included in a received PPDU when the STA 1600 is not the intended recipient of the PPDU. The carrier sense module 1654 is responsible for performing both physical carrier sense (energy sense) and virtual carrier sense (NAV) prior to a transmission that requires carrier sense.

[0078] The STA 1600 may comprise many other components that are not shown in Figure 16 for clarity. Only the components most relevant to this disclosure are shown.

[0079] <Third embodiment> In the previous embodiment, the bandwidth information of the PPDU that sets the NAV is recorded as a field of the NAV itself. However, it is also possible to record the bandwidth information separately from the NAV. According to the third embodiment, the STA records the bandwidth information of the PPDU that sets the NAV as a separate entity, for example, as an OBSS_BW information field.

[0080] Referring to Fig. 17, a series of exemplary frame exchange sequences 1700 are shown to visually illustrate the recording of bandwidth information according to the third embodiment in an 80 MHz BSS. The upper part of Fig. 17 shows four transmission sequences with variable bandwidths, namely TXOP1 1712, TXOP2 1722, TXOP3 1732, and TXOP4 1742. Each transmission sequence includes an exchange of PPDUs between an AP and one or more STAs that belong to the same BSS as the AP.

[0081] The center part of Fig. 17 shows a visual representation of the NAV duration maintained by a third party STA according to the rules defined by the IEEE 802.11 specification. A STA that is within radio coverage of an ongoing transmission and is neither the sender nor the intended recipient of this transmission is considered a third party STA with respect to that transmission. The bottom part of Fig. 17 shows a visual representation of the OBSS_BW information maintained by the same third party STA. The points in time relevant to this example are indicated by t0, t1, t2, t3, t4, t5, t6, and t7.

[0082] Upon receiving the first PPDU 1710 of TXOP1 1712, the third party STA determines that it is not the intended recipient of the PPDU 1710, for example, by reading the recipient address in the MAC header of the frame carried by the PPDU, or by reading the AID12 subfield of the user information field of the trigger frame carried in the PPDU 1710. Once the STA determines, according to the existing IEEE 802.11 NAV rules, that it is not the intended recipient of the PPDU 1710, it sets the NAV duration to the time period from time t0 to time t1, which prohibits the STA from transmitting until the end of TXOP1 1712, time t1. In addition to recording the NAV duration, according to the third embodiment, the STA also records the bandwidth information of the PPDU 1710 that sets the NAV as 80 MHz in the OBSS_BW information field. At time t1, when the NAV duration 1714 counts down to zero, the OBSS_BW information field is also reset to zero. Box 1716 shows the OBSS_BW information between time t0 and time t1. The OBSS_BW information field may be represented as a 2-bit variable as shown in table 750 of Figure 7B, or may be maintained as an 8-bit bitmap 1390 of Figure 13B.

[0083] Similarly, upon receiving the first PPDU 1720 of TXOP2 1722, the STA sets the NAV duration 1724 to the time period from time t2 to the end of TXOP2 1722 at time t3, while the OBSS_BW information field is set to 40 MHz (the bandwidth of the PPDU 1720). This is shown as box 1726. At time t3, when the NAV duration 1724 counts down to zero, the OBSS_BW information field is also reset to zero. Similarly, upon receiving the first PPDU 1730 of TXOP3 1732, the STA sets the NAV duration 1734 to the time period from time t4 to the end of TXOP3 1732 at time t5, while the OBSS_BW information field is set to 20 MHz (the bandwidth of the PPDU 1730). This is shown as box 1736. At time t5, when the NAV duration 1734 counts down to zero, the OBSS_BW information field is again reset to zero. Furthermore, if the channel sensing rules are modified accordingly, under certain conditions, a third party STA may be permitted to transmit on unoccupied channels CH3 and CH4 in the time period from t2 to t3, and on channels CH2, CH3, and CH4 in the time period from t4 to t5, without causing interference to the ongoing transmissions 1722 and 1732, respectively. This promotes more efficient reuse of unoccupied secondary channels.

[0084] Conventionally, an IEEE 802.11 STA is only required to receive and decode PPDUs that overlap with the STA's primary 20 MHz channel, and the STA is not required to receive or decode PPDUs that do not overlap with its primary 20 MHz channel. However, if the STA has the ability to receive and decode such PPDUs, the STA can use the OBSS_BW information field to further record the bandwidth of such PPDUs. TXOP4 1742 represents a frame exchange sequence that does not overlap with the primary 20 MHz used by a third party STA. When receiving the first PPDU 1740 of TXOP4 1742, if the STA has the ability to receive and decode the PPDUs, the STA can record the bandwidth in the OBSS_BW information field. Note that in this case, the STA does not set the NAV duration.

[0085] The bandwidth information recorded by the OBSS_BW information field may be used as a reference by the STA to inform the AP with which the STA is associated of the availability of its channels. As an example, if the STA implements the spontaneous Bandwidth Query Report (BQR) operation defined in IEEE 802.11ax, the STA can use the OBSS_BW information field to fill the available channel bitmap that the STA sends to its associated AP in the Bandwidth Query Report. The TXOP4 1742 does not set a NAV duration for the STA and therefore does not prevent the STA from transmitting. However, recording the bandwidth of the TXOP4 1742 in the OBSS_BW information field allows the STA to inform its AP that CH3 and CH4 are expected to be busy for the STA during the time period from time t6 to time t7. This helps the AP avoid CH3 and CH4 when allocating resource units (RUs) to the STA for downlink or uplink OFDMA transmission to / from the STA during the time period from time t6 to time t7.

[0086] Referring back to FIG. 5 , the overprotected NAV that prohibited STA2 from transmitting UL PPDU 450 can be overcome by applying the concept of recording the bandwidth information of the ongoing OBSS transmission from BSS2 145 in FIG. 1 as an OBSS BW information field while making modifications to the virtual CS rules and UL MU CS mechanism.

[0087] Table 1800 of Figure 18 lists various parameters associated with the modified UL MU CS mechanism for STA2 during the UL MU transmission sequence shown in Figure 5. Table 1800 and its contents are the same as table 880 of Figure 8B, except that the OBSS_BW information field is separate from the basic NAV 1810 of table 1800. Since the OBSS transmissions from BSS2 145 only overlap on CH1 and CH2, CH1 and CH2 are recorded as busy, while CH3 and CH4 are recorded as idle in the OBSS_BW information field, as shown by entries 1820 and 1822, respectively, of Figure 18.

[0088] According to the third embodiment, the virtual CS rule is modified to consider the virtual CS state of busy / idle for each 20MHz channel. When the basic NAV duration counter is non-zero, only the 20MHz channel indicated as busy by the OBSS_BW information field is considered to be busy by the virtual CS. Similarly, the UL MU CS rule is also modified to consider the busy / idle state of the wireless medium for each 20MHz channel. According to the modified UL MU CS rule, since both the virtual CS and the energy detection (ED)-based CCA indicate busy on CH1 and CH2 and idle on CH3 and CH4, the UL MU CS mechanism considers CH1 and CH2 as busy, while CH3 and CH4 are considered as idle, as shown by descriptions 1836, 1834, 1832, and 1830, respectively. Since both CH3 and CH4 are considered idle, according to the modified UL MU CS transmission rules, STA2 is allowed to transmit its UL PPDU 450 in the assigned RUs of CH3 and CH4, thereby promoting more efficient use of the wireless medium. The virtual CS rules according to the third embodiment can be summarized as follows: - For each 20 MHz channel that contains an RU assigned for the STA's uplink transmission, the NAV is taken into account in the virtual CS of the STA requested by the trigger frame for transmission unless one of the following conditions is met: - NAV was set by an intra-BSS frame. - The NAV duration counter is zero. - The NAV duration counter is greater than zero, but the 20 MHz channel is recorded as idle by the OBSS_BW information field.

[0089] If the NAV is not taken into account, the virtual CS indicates idle for the 20 MHz channel, otherwise the virtual CS indicates busy for the 20 MHz channel.

[0090] The UL MU CS rules according to the third embodiment can be summarized as follows: - If the CS request subfield in the trigger frame is set to 1, during the SIFS time after the trigger frame, at least for each 20 MHz channel that contains an RU assigned for the STA's UL MU transmission, the STA shall consider the state of CCA and virtual CS using the appropriate energy detection (ED) rules in response to the trigger frame. When the 20 MHz channel that contains the assigned RU in the trigger frame is considered idle, the STA may transmit an HE trigger-based PPDU. If the STA detects that the 20 MHz channel that contains the assigned RU is not all idle, the STA shall not transmit anything on the assigned RU.

[0091] 19 shows a flowchart 1900 illustrating the UL MU CS transmission rule according to the third embodiment when the virtual CS rule is indicated for each 20 MHz channel by keeping the OBSS transmission bandwidth information in OBSS_BW. For each 20 MHz channel of the wideband channel for which the STA has been assigned RUs for uplink transmission by the AP in the trigger frame with the CS request field set to 1, the UL MU CS process is initiated in step 1910. Because the CS request field is set to 1 in the trigger frame, before transmitting the HE trigger-based PPDU, the STA is required to perform UL MU CS on at least all of the 20 MHz channels including the assigned RUs during the SIFS immediately following the end of the PPDU containing the trigger frame.

[0092] In step 1920, the basic NAV duration counter is checked, and if it is zero, the process proceeds to step 1940, otherwise the process proceeds to step 1930. In step 1930, if the 20 MHz channel is recorded as busy by the OBSS_BW, the process proceeds to step 1950, otherwise it proceeds to step 1940. In step 1940, the virtual CS advertises the 20 MHz channel as idle, and the process proceeds to step 1960. In step 1950, the virtual CS advertises the 20 MHz channel as busy, and the process proceeds to step 1980. In step 1960, the STA senses the wireless medium using energy detection (ED) during the SIFS time immediately following the end of the PPDU containing the trigger frame, and if the channel is sensed as busy, the process proceeds to step 1980, otherwise the process proceeds to step 1970.

[0093] In step 1980, the 20 MHz channel is deemed busy for UL MU transmission and the process ends for this 20 MHz channel. In step 1970, the 20 MHz channel is deemed idle for UL MU transmission and the process ends for this 20 MHz channel. This process is repeated for at least each 20 MHz channel of the wideband channel that has an RU assigned to the STA for uplink transmission. If all of the 20 MHz channels, including the RU assigned to the STA in the trigger frame, are deemed idle, the STA may transmit its HE trigger-based PPDU.

[0094] Referring to Figure 20, table 2000 lists various parameters from which a STA receiving a correct IEEE 802.11 PPDU setting NAV can determine the channel bandwidth information of the PPDU. According to the IEEE 802.11 specification, upon receiving a correct IEEE 802.11 PHY preamble, the PHY layer of the STA measures the received signal strength level, and if this signal strength level is above a certain threshold, commonly called the preamble detection (PD) level, the PHY indicates this to the MAC layer by a PHY-CCA.indication(BUSY, primary) primitive. The STA continues to receive the remaining PHY header fields, and upon successful reception of the PHY header, the PHY layer issues a PHY-RXSTART.indication(RXVECTOR) primitive to the MAC.

[0095] The contents of RXVECTOR depend on the format of the received PPDU, and the STA determines the bandwidth of the received PPDU based on the relevant parameters of RXVECTOR as listed in Table 2000. If the received PPDU is an HE PPDU, the bandwidth is indicated by the CH_BANDWIDTH parameter, where the CH_BANDWIDTH parameter is based on the bandwidth field of the HE-SIG-A of the PHY header of the received HE PPDU. If the received PPDU is a VHT PPDU, the bandwidth is similarly indicated by the CH_BANDWIDTH parameter, where the CH_BANDWIDTH parameter is based on the bandwidth field of the VHT-SIG-A1 of the PHY header of the received VHT PPDU.

[0096] If the received PPDU is a HT PPDU, the bandwidth is also indicated by the CH_BANDWIDTH parameter, where the CH_BANDWIDTH parameter is based on the CBW20 / 40 bit of the HT-SIG in the PHY header of the received HT PPDU. However, if the received PPDU is a non-HT PPDU, determining the exact bandwidth of the PPDU is more complicated, because the non-HT PPDU may be in a legacy non-HT PPDU format or a non-HT duplicate PPDU format. The PPDU format of the non-HT PPDU can be determined by referring to the NON_HT_MODULATION parameter of the RXVECTOR. If the NON_HT_MODULATION parameter is OFDM, the PPDU is a legacy non-HT PPDU and the channel bandwidth is 20 MHz.

[0097] However, if the NON_HT_MODULATION parameter is NON_HT_DUP_OFDM, the PPDU is a non-HT replicated PPDU, i.e. the same PPDU is replicated in multiple 20 MHz channels. In this case, the CH_BANDWIDTH parameter only indicates the estimated channel bandwidth. However, the non-HT replicated PPDU may be transmitted by a bandwidth signaling STA, i.e. the Transmitter Address (TA) field of the MAC header included in the received PPDU is a bandwidth signaling TA (the individual / group bit of the TA is 1). In such a case, the exact bandwidth of the PPDU can be determined by further referring to the CH_BANDWIDTH_IN_NON_HT parameter of the RXVECTOR. In some cases, it may not be possible to determine the exact bandwidth of the non-HT replicated PPDU. For example, the CTS frame is usually transmitted in a non-HT PPDU or non-HT replicated PPDU format to ensure maximum NAV protection for legacy devices.

[0098] Since the CTS frame does not even include a TA field, it is not possible to determine the exact bandwidth covered by the CTS frame if it is transmitted in a non-HT duplicated format. If such a PPDU is received and the STA is unable to determine the exact bandwidth of the PPDU, according to the third embodiment, the OBSS_BW information field is set such that all of the STA's operating channels are marked as busy in order not to allow the STA to transmit when the basic NAV duration counter is non-zero. This ensures that the STA does not accidentally cause interference to ongoing OBSS transmissions.

[0099] Referring to Figure 21, table 2100 lists possible values ​​and meanings of the channel-list parameter of the PHY-CCA.indication primitive issued by an HE STA. In addition to the four existing members of the channel-list parameter, namely primary, secondary, secondary40, and secondary80, an HE STA may also optionally include a per20MHz bitmap, where each bit of the bitmap that is 0 indicates an idle 20MHz channel and each bit that is 1 indicates a busy 20MHz channel. If the PHY layer of the HE STA has the capability to indicate channel conditions at such 20MHz granularity, the STA may alternatively use the per20MHz bitmap to set the OBSS_BW information field.

[0100] <Fourth embodiment> As mentioned above, in some cases, it may not be possible for a STA to determine the exact bandwidth of a received PPDU, or the STA may choose not to record the bandwidth information of a received PPDU for ease of implementation or other reasons. In other cases, even if the NAV-setting PPDU occupies only the primary 20 MHz channel, the STA may possess other information that indicates that transmissions on non-primary channels during the NAV duration may not be advisable.

[0101] Similarly, even if a STA is unable to determine the exact bandwidth of a received PPDU, based on its historical knowledge of neighboring OBSSs, the STA may still be able to accurately predict the bandwidth of the PPDU. For example, based on previously received OBSS frames, the STA may know that a particular OBSS only operates on 20 MHz primary channels, or that a particular HE STA is a 20 MHz-only device (based on frames received during capability exchange between the STA and its AP). The STA may build up such a knowledge base about its neighbors over time, and when a PPDU is received, based on some relevant fields in the PPDU, such as the Basic Service Set Identifier (BSSID) or sender / receiver addresses, the STA may be able to determine whether its transmission on a non-primary channel during the NAV period (i.e., the duration that the NAV duration counter is non-zero) is harmless.

[0102] According to the fourth embodiment, instead of recording the bandwidth information in the NAV setting PPDU, the STA maintains a flag TX_Allowed that indicates whether the STA can transmit on a non-primary 20 MHz channel during the NAV period. The TX_Allowed flag may be maintained independently of the NAV or may be tightly tied to the NAV.

[0103] Referring to FIG. 22, 2200 shows the NAV held by a STA according to the fourth embodiment using two octets. According to the IEEE 802.11 specification, in most cases, a STA updates its NAV based on the contents of the two-octet Duration / ID field in the MAC header of a valid 802.11 frame. When used to carry a duration value, bit 15 of the Duration / ID field is set to 0, while the remaining 15 bits carry the duration value in microseconds. In some cases, the HE STA can also use the 7-bit TXOP_DURATION parameter in the RXVECTOR to update the NAV. In any case, 15 bits are sufficient to record the NAV duration, as indicated by 2210.

[0104] The last bit B15 is used as a TX_Allowed flag 2220. The encoding of the TX_Allowed flag is described in table 2230. If the TX_Allowed flag is set to zero, the STA is not allowed to transmit when the NAV duration field 2210 indicates a non-zero value. If it is set to one, the STA may transmit on a non-primary 20 MHz channel during the NAV period if other conditions allow it (e.g., if energy detection (ED)-based channel sensing also returns the non-primary 20 MHz channel as idle).

[0105] Referring to FIG. 23, a series of exemplary frame exchange sequences 2300 are shown to visually illustrate recording of NAV according to the fourth embodiment in an 80 MHz BSS.

[0106] The top part of Figure 23 shows three transmission sequences with variable bandwidth: 80 MHz TXOP1 2312, 40 MHz TXOP2 2322, and 20 MHz TXOP3 2332. The relevant time points in this example are indicated by t0, t1, t2, t3, t4, and t5. A STA that is within radio coverage of an ongoing transmission and is neither the sender nor the intended recipient of this transmission is considered a third party STA with respect to that transmission.

[0107] Upon receiving the first PPDU 2310 of TXOP1 2312, the third party STA determines that it is not the intended recipient of the PPDU 2310, e.g., by reading the recipient address in the MAC header of the frame carried by the PPDU or by reading the AID12 subfield of the user information field of the trigger frame carried in the PPDU 2310. Once the STA has determined, in accordance with existing NAV rules, that it is not itself the intended recipient of the PPDU 2310, it copies the protection duration from the relevant field of the PPDU 2310 and sets the NAV duration field 2210 to the time period, e.g., from time t0 to time t1.

[0108] In addition to recording the NAV duration, according to the fourth embodiment, the STA also predicts whether transmissions on other 20 MHz channels within its operating bandwidth apart from the primary 20 MHz channel are permissible. The STA can utilize information such as the bandwidth of the PPDU 2310, its historical knowledge of nearby OBSSs, relevant fields in the PPDU such as the Basic Service Set Identifier (BSSID) or sender / receiver addresses to determine whether its transmissions on non-primary channels during the NAV duration are harmless.

[0109] For PPDU 2310, the STA predicts that transmitting on other non-primary 20 MHz channels during the NAV period from t0 to t1 is not advisable due to a high risk of interference to subsequent transmissions of TXOP1 2312 on CH2, CH3, and CH4, and therefore sets the TX_Allowed flag 2220 to 0. This is visually illustrated by box 2314. Similarly, upon receiving PPDU 2320, the STA sets the NAV duration to the time period from time t2 to time t3, the end of TXOP2 2322. Again, the STA predicts that transmitting on other non-primary 20 MHz channels during the NAV period from t2 to t3 is not advisable due to a high risk of interference to subsequent transmissions of TXOP2 2322 on CH2, and therefore sets the TX_Allowed flag 2220 to 0. This is illustrated as box 2324.

[0110] Similarly, upon receiving PPDU 2330, the STA sets its NAV duration to the time period from time t4 to time t5, the end of TXOP3 2332. However, at this point, the STA predicts that its transmissions on non-primary 20 MHz channels CH2, CH3, and CH4 during the NAV period will not interfere with subsequent transmissions of TXOP3 2332, and therefore the STA sets the TX_Allowed flag 2220 to one indicating that the STA may transmit on non-primary 20 MHz channels during the NAV period from t4 to t5 if other conditions permit. This is visually indicated by box 2336. However, transmissions on the primary 20 MHz channel CH1 during the NAV period are prohibited, as visually indicated by box 2334. At time t5, when the NAV duration counter goes to zero, the TX_Allowed flag is also reset to zero.

[0111] 24 illustrates an exemplary UL MU transmission sequence 400 in yet another channel condition to highlight the improvement in spectrum reuse made by the fourth embodiment. At the moment the STAs receive the trigger frame 410 from AP1 (101 in FIG. 1), there are no ongoing transmissions on the primary 20 MHz channel within the wireless coverage area of ​​STA1, STA3, and STA4, and both the intra-BSS NAV and the basic NAV of STA1, STA3, and STA4 are set to zero. However, as illustrated by the transmission sequence 2400, there is an ongoing OBSS transmission on the primary channel CH1 in BSS2 (145 in FIG. 1) within the wireless coverage area of ​​STA2.

[0112] AP2 (102) and STA5 (150) are engaged in a bidirectional frame exchange using the reverse direction protocol (RDP). AP2 sends PPDU 2410 to STA5, which includes an RDP A control field with a Reverse Direction Grant (RDG) / More PPDU field set to 1. STA5 then responds with PPDU 2420 after a time SIFS from PPDU 2410. AP2 completes the frame exchange by sending an ACK frame 2430 to STA5.

[0113] Upon receiving PPDU 2410, STA2 determines that it is an OBSS PPDU and sets its basic NAV until the end of transmission sequence 2400. The illustrated OBSS interference to STA2 is slightly different compared to that shown in FIG. 5, with the OBSS transmission only interfering with the primary 20 MHz channel CH1. However, under the original UL MU CS rules, the interference impact to STA2 is exactly the same. Because the basic NAV is non-zero, STA2 is not allowed to transmit HE trigger-based PPDU 450 on the assigned RUs of channels CH3 and CH4, even though the virtual CS returns busy and energy detection returns idle on channels CH3 and CH4.

[0114] According to the fourth embodiment, the virtual CS rules are modified so that the busy / idle virtual CS status is considered differently for different 20 MHz channels. At least, the virtual CS is considered differently for the primary 20 MHz channel and the remaining non-primary 20 MHz channels in the STA's operating bandwidth. When the basic NAV duration counter is non-zero, the primary 20 MHz channel is always indicated as busy by the virtual CS. However, whether the non-primary 20 MHz channels are considered idle or busy by the virtual CS depends on the TX_Allowed flag. When the TX_Allowed flag is not set, i.e., when the TX_Allowed flag 2220 is 0, all non-primary 20 MHz channels are also indicated as busy. However, when the TX_Allowed flag is set, i.e., when the TX_Allowed flag 2220 is 1, all non-primary 20 MHz channels are indicated as idle.

[0115] Table 2500 of FIG. 25 lists various parameters related to the modified UL MU CS mechanism according to the fourth embodiment for STA2 during the UL MU transmission sequence 400 shown in FIG. 24. Table 2500 and its contents are almost the same as table 880 of FIG. 8B, except that CH2 is idle and instead of retaining the busy / idle status of each 20 MHz channel by recording the bandwidth information of the PPDU setting the basic NAV, only the TX_Allowed flag is retained as indicated by the abbreviation TX_A 2510. Upon receiving PPDU 2410, based on the relevant fields from the PPDU, such as the BSS color, the CH_BANDWIDTH parameter of the RXVECTOR, STA2 determines that it is an inter-BSS 20 MHz PPDU. STA2 may also have historical information that BSS2 operates only at 20 MHz, and based on the BSS color or BSSID of the frame included in PPDU 2410, STA2 may reliably predict that the OBSS transmission will be restricted to the primary 20 MHz channel CH1 during the NAV period. Therefore, STA2 determines that it is safe to transmit its UL MU PPDUs on the non-primary channel during the NAV period and therefore sets the TX_Allowed flag 2220 to 1.

[0116] According to the virtual CS rule according to the fourth embodiment, CH1 is indicated as busy 2522, while the non-primary channels CH2, CH3, and CH4 are indicated as idle by the virtual CS because the TX_Allowed flag 2220 is 1. Similarly, when STA2 performs energy detection (ED)-based CCA during the SIFS after the PPDU 410 containing the trigger frame, CH1 is indicated as busy, while the three non-primary channels CH2, CH3, and CH4 are indicated as idle. As shown by descriptions 2536, 2534, 2532, and 2530, respectively, the UL MU CS mechanism considers both the virtual CS and energy detection sensing states and indicates CH1 as busy, while CH2, CH3, and CH4 are considered as idle. Since both CH3 and CH4 are considered idle, according to the modified UL MU CS transmission rules, STA2 is permitted to transmit its UL PPDU 450 in the assigned RUs of CH3 and CH4, thereby promoting more efficient use of the wireless medium.

[0117] The virtual CS rules according to the fourth embodiment can be summarized as follows: - For each 20 MHz channel that contains an RU assigned for the STA's uplink transmission, the NAV is taken into account in the virtual CS of the STA requested by the trigger frame for transmission unless one of the following conditions is met: - NAV was set by an intra-BSS frame. - The NAV duration counter is zero. - The 20MHz channel is not the primary 20MHz channel and the TX_Allowed flag is set to 1.

[0118] If the NAV is not taken into account, the virtual CS indicates idle for the 20 MHz channel, otherwise the virtual CS indicates busy for the 20 MHz channel.

[0119] The UL MU CS rules according to the fourth embodiment can be summarized as follows: - If the CS request subfield in the trigger frame is set to 1, during the SIFS time after the trigger frame, at least for each 20 MHz channel that contains an RU assigned for the STA's UL MU transmission, the STA shall consider the state of CCA and virtual CS using the appropriate energy detection (ED) rules in response to the trigger frame. When the 20 MHz channel that contains the assigned RU in the trigger frame is considered idle, the STA may transmit an HE trigger-based PPDU. If the STA detects that the 20 MHz channel that contains the assigned RU is not all idle, the STA shall not transmit anything on the assigned RU.

[0120] FIG. 26 shows a flow chart 2600 illustrating the UL MU CS transmission rule according to the fourth embodiment. For each 20 MHz channel of the wideband channel in which the STA has been assigned an RU for uplink transmission by the AP in the trigger frame with the CS request field set to 1, the UL MU CS process is started in step 2610. Because the CS request field is set to 1 in the trigger frame, the STA is required to perform UL MU CS on at least all of the 20 MHz channels that contain the assigned RU during the SIFS immediately following the end of the PPDU containing the trigger frame before transmitting the HE trigger-based PPDU. In step 2620, the basic NAV duration counter is checked, and if it is zero, the process proceeds to step 2640, otherwise the process proceeds to step 2630.

[0121] In step 2630, if the 20 MHz channel is the primary 20 MHz channel, the process proceeds to step 2660, otherwise it proceeds to step 2650. In step 2650, if the TX_Allowed flag is set to 0, the process proceeds to step 2660, otherwise it proceeds to step 2640. In step 2640, the virtual CS advertises the 20 MHz channel as idle and the process proceeds to step 2670. In step 2660, the virtual CS advertises the 20 MHz channel as busy and the process proceeds to step 2690.

[0122] In step 2670, the STA senses the wireless medium using energy detection (ED) during the SIFS time immediately following the end of the PPDU containing the trigger frame, and if the channel is sensed to be busy, the process proceeds to step 2690, otherwise, the process proceeds to step 2680. In step 2690, the 20 MHz channel is deemed busy for UL MU transmission and the process ends for this 20 MHz channel. Similarly, in step 2670, the 20 MHz channel is deemed idle for UL MU transmission and the process ends for this 20 MHz channel. This process is repeated for at least each 20 MHz channel of the wideband channel that has RUs assigned to the STA for uplink transmission. When all of the 20 MHz channels, including the RUs assigned to the STA in the trigger frame, are deemed idle, the STA may transmit its HE trigger-based PPDU on the assigned RUs.

[0123] Referring to Figure 27, a series of exemplary frame exchange sequences are shown to visually illustrate the update rules of the TX_Allowed flag when there are multiple OBSSs within the radio coverage of a STA, for example in the BSS arrangement shown in Figure 9, and it is assumed that all three BSSs, BSS1 100, BSS2 145, and BSS3 900, are 80 MHz BSSs. The upper part of Figure 27 shows three transmission sequences of different bandwidths in BSS2 145, namely, TXOP1 2710 of 80 MHz, and two 20 MHz TXOPs, TXOP2 2720 and TXOP3 2730. Similarly, the lower part of Figure 27 shows three transmission sequences of different bandwidths in BSS3 900, namely, two 20 MHz TXOPs, TXOP4 2740, TXOP6 2760, and TXOP5 2750 of variable bandwidth. The center part of Figure 27 shows a visual representation of the base NAV maintained by STA2 120 as proposed by the fourth embodiment. The relevant times in this example are indicated by t0, t1, t2, t3, t4, t5, t6, t7, t8, t9, t10, and t11.

[0124] Upon receiving the first PPDU 2712 of TXOP1 2710, based on the BSS color field in the PHY header or the BSSID field in the MAC header, STA2 determines that the PPDU 2712 is an OBSS PPDU from BSS2 and that STA2 is not one of the recipients of the PPDU. According to the existing NAV rules for updating the NAV duration, STA2 sets the basic NAV duration from time t0 to time t2. At the same time, based on the prediction of the subsequent OBSS transmission during the NAV period, STA2 sets the TX_Allowed flag to 0.

[0125] Upon receiving the first PPDU 2742 of TXOP4 2740, STA2 determines that 2742 is an OBSS PPDU from BSS3 and that STA2 is not one of the recipients of the PPDU. Since the duration indicated in PPDU 2742 is longer than the existing NAV duration, following the rules for updating the NAV time, STA2 updates the NAV duration to time t3, which is the end of TXOP4 2740. Even though STA2 determines that the bandwidth of TXOP4 2740 is only 20 MHz, based on its knowledge of the transmit sequence 2710 of BSS2, STA2 determines that it should continue to prohibit transmissions on non-primary channels during the extended NAV period and therefore makes no change to the TX_Allowed flag.

[0126] Similarly, upon receiving the first PPDU 2722 of TXOP2 2720, STA2 sets the NAV duration from time t4 to time t7 because STA2 is not one of the recipients of the PPDU. STA2 determines that the bandwidth of TXOP2 2720 is only 20 MHz and sets the TX_Allowed flag to 1 indicating that transmissions on non-primary 20 MHz channels may be allowed during the NAV period.

[0127] Upon receiving the first PPDU 2752 of TXOP5 2750, STA2 determines that 2752 is an OBSS PPDU from BSS3 and that it is not one of the recipients of the PPDU. Since the duration indicated in 2752 is shorter than the existing NAV duration, STA2 does not update the NAV duration according to the NAV rules for updating the NAV duration. However, since the bandwidth of PPDU 2752 is wider than 20 MHz, STA2 predicts a risk of interference to the OBSS by transmissions on non-primary channels and therefore updates the TX_Allowed flag to 0, prohibiting it from starting new transmissions on non-primary channels during the remaining NAV period. However, if STA2 can determine, based on some fields of PPDU2752 or its previous knowledge of BSS3 (e.g., that this PPDU2752 contains a frame that solicits responses only from 20 MHz-only HE devices, i.e., devices capable of operating only on the primary 20 MHz channel), then STA2 may choose not to update the TX_Allowed flag, thereby continuing to allow transmissions on non-primary 20 MHz channels during the NAV period.

[0128] Similarly, upon receiving the first PPDU 2732 of TXOP3 2730, STA2 sets the NAV duration from time t8 to time t10 because STA2 is not one of the recipients of the PPDU. STA2 also determines that the bandwidth of TXOP3 2730 is only 20 MHz and sets the TX_Allowed flag to 1 indicating that transmission may be allowed during the NAV period.

[0129] Upon receiving the first PPDU 2762 of TXOP6 2760, STA2 determines that 2762 is an OBSS PPDU from BSS3 and that it is not one of the recipients of the PPDU. Since the duration indicated in PPDU 2762 is longer than the existing NAV duration, following the rules for updating the NAV duration, STA2 updates the NAV duration by time t11, which is the end of TXOP6 2760. Since the bandwidth of TXOP6 2760 is also only 20 MHz, STA2 chooses not to update the TX_Allowed flag, which continues to allow transmissions on non-primary 20 MHz channels during the NAV period. At time t11, when the NAV duration counter reaches zero, STA2 resets the TX_Allowed flag to zero.

[0130] The update rules for the TX_Allowed flag are summarized by the flowchart 2800 in Figure 28. The process begins in step 2810 where a NAV setting OBSS PPDU is received. In step 2815, if the current value of the basic NAV duration is zero, the process proceeds to step 2870, otherwise it proceeds to step 2820.

[0131] In step 2820, if the PPDU increases the NAV duration of the basic NAV, the process proceeds to step 2830, otherwise the process proceeds to step 2840. In step 2830, the basic NAV duration is updated according to the associated duration information in the PPDU (e.g., based on the TXOP duration field in the PHY header or the duration field in the MAC header) and the process proceeds to step 2840. In step 2840, if the TX_Allowed flag is 1, the process proceeds to step 2850, otherwise the process ends.

[0132] In step 2850, the STA determines whether its transmissions on non-primary 20 MHz channels may cause interference to OBSS transmissions, and if so, the process proceeds to step 2860, otherwise the process ends. In step 2860, the STA sets the TX_Allowed flag to 0, and the process ends.

[0133] In step 2870, if the bandwidth of the received PPDU is 20 MHz and the STA determines that its transmission on the non-primary 20 MHz channel does not cause interference to the OBSS transmission, the process proceeds to step 2880, otherwise the process proceeds to step 2875. In step 2880, the STA sets the TX_Allowed flag to 1, and the process proceeds to step 2885. In step 2875, the STA sets the TX_Allowed flag to 0, and the process proceeds to step 2885. In step 2885, if the PPDU increases the NAV duration of the basic NAV, the process proceeds to step 2890, otherwise the process ends. In step 2890, the basic NAV duration is updated according to the associated duration information in the PPDU (e.g., based on the TXOP duration field in the PHY header or the duration field in the MAC header) and the process ends.

[0134] It goes without saying that the configuration of the STA described above using FIG. 15 and FIG. 16 can implement the third and fourth embodiments of the present disclosure mentioned above.

[0135] In the above-described embodiment, the present disclosure is configured by hardware as an example, but may be realized by cooperation of hardware and software.

[0136] Furthermore, the functional blocks used in the description of the embodiments are generally implemented as LSI devices, which are integrated circuits. The functional blocks may be formed as individual chips, or some or all of the functional blocks may be integrated into a single chip. Although the term "LSI" is used in this specification, the terms "IC", "system LSI", "super LSI", or "ultra LSI" may also be used depending on the degree of integration.

[0137] Furthermore, the integration of the circuit is not limited to LSI, but may be achieved by a dedicated circuit other than LSI or a general-purpose processor. A field programmable gate array (FPGA) that can be programmed after the LSI is manufactured or a reconfigurable processor that allows the reconfiguration of the connection or setting of the circuit cells in the LSI may be used.

[0138] If an alternative circuit integration technique to LSI appears as a result of progress in semiconductor technology or other technologies derived from this technology, the functional blocks may be integrated using such a technique. Another possibility is applications such as biotechnology. [Industrial Applicability]

[0139] The present disclosure may be applied to wireless devices to perform efficient virtual carrier sensing (CS) in multi-channel wireless communication systems. [Explanation of symbols]

[0140] 1500 STA(station) 1502 Receiving unit 1504 PPDU Decoder 1506 Memory 1508 Transmitter 1600 STA (station) 1610 Power supply 1620 Memory 1630 Central Processing Unit (CPU) 1640 Secondary storage 1650 Wireless Communication Interface 1652 MAC Module 1654 Carrier Detect Module 1656 NAV Bandwidth Bitmap 1658 NAV Duration Counter 1660 PHY Module 1670 Antenna

Claims

1. a receiver that, during operation, receives a physical layer protocol data unit (PPDU) indicating duration information and bandwidth information for one or more frequency channels on which the PPDU is received; a transmitter that, during operation, transmits frames on a frequency channel other than the one or more frequency channels on which the PPDUs were received; the transmitter does not transmit a frame on one or more frequency channels corresponding to the bandwidth information within a period of time indicated by the duration information; Communications equipment.

2. the communication device comprising: circuitry for determining whether the received PPDU is from a corresponding basic service set (BSS) or an overlapping basic service set (OBSS); When the circuit determines that the PPDU is from an OBSS or when the circuit determines the BSS to which the PPDU belongs, the circuit sets a period indicated in the PPDU as duration information, and sets a bandwidth of one or more channels on which the PPDU is received as bandwidth information; the transmitter, in operation, transmits the frames on a frequency channel not covered by a bandwidth; The communication device according to claim 1 .

3. the circuitry compares the bandwidth to a currently set value and updates the value only if the bandwidth of one or more channels is greater than the currently set value. The communication device according to claim 1 .

4. receiving a physical layer protocol data unit (PPDU) indicating duration information and bandwidth information for one or more frequency channels on which the PPDU is received; transmitting a frame on a frequency channel other than the one or more frequency channels on which the PPDU was received; no frame is transmitted on one or more frequency channels corresponding to the bandwidth information within the period indicated by the duration information; Communication methods.

5. determining whether the received PPDU is from a corresponding basic service set (BSS) or an overlapping basic service set (OBSS); if it is determined that the PPDU is from an OBSS or if the BSS to which the PPDU belongs is determined, setting a period indicated in the PPDU as duration information and setting a bandwidth of one or more channels on which the PPDU is received as bandwidth information; transmitting the frame on a frequency channel not covered by a bandwidth. The communication method according to claim 4.

6. comparing said bandwidth with a currently set value and updating said value only if the bandwidth of one or more channels is greater than the currently set value; The communication method according to claim 4.

Images