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 communication devices and communication 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 located in the same place.

Background Art

[0002] The IEEE (Institute of Electrical and Electronics Engineers) 802.11 working group is currently promoting the standardization of next-generation WLAN (Wireless Local Area Network) technology under the 802.11ax task group. The main goal of this task group is to improve spectral efficiency to increase 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 generally called high-efficiency (HE) devices. Among the various proposed technologies, orthogonal frequency division multiple access (OFDMA) and uplink multi-user transmission are two major technologies adopted by the IEEE 802.11ax task group to achieve throughput improvement goals. An 802.11 WLAN having 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 two examples of 802.11ax BSS100 and 145, each BSS including an HE AP and several HE STAs associated with that HE AP. A BSS that operates on the same channel as the BSS of an STA and is partially or entirely within the radio coverage of the STA is known as an Overlapping Basic Service Set (OBSS). In Figure 1, assuming that STA2 120 is associated with AP1 101, BSS145 is considered an OBSS with respect to STA2 120.

[0004] The Medium Access Control (MAC) protocol for 802.11 devices, including 802.11ax devices, uses the Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) protocol to share wireless media. Collision avoidance is achieved through the use of random backoff, while CSMA includes the use of physical and virtual carrier sense (CS) mechanisms. The physical CS mechanism is provided by the physical layer (PHY) and includes actual detection of the wireless media (either preamble detection (PD) or energy detection (ED), or both). 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 subsequent traffic on the medium, based on duration information advertised in most IEEE 802.11 frames. This duration may be included in the MAC header and / or obtained from the Transmit Opportunity (TXOP) duration in the PHY header, if any. The TXOP duration represents the period during which a particular STA has the right to initiate a frame exchange sequence for a wireless medium. When either the physical CS or virtual CS indicates that the medium is busy, the device is not permitted to transmit signals except for certain frames, such as an acknowledgment (Ack) frame or a block acknowledgment frame. To improve the efficiency of the channel access mechanism in the presence of OBSS, 802.11ax approved the use of two NAVs: one known as the BSS-in-NAV and the other known as the base NAV. The BSS-in-NAV is used to store the NAV value from a PHY protocol data unit (PPDU) identified as BSS-in-, i.e., the BSS to which the STA is associated, where applicable. On the other hand, the basic NAV is used, where applicable, to store other NAV values ​​from inter-BSS PPDUs, i.e., from OBSS PPDUs, or from PPDUs that cannot be identified as being within or between BSSs. [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 [Overview of the project] [Problems that the invention aims to solve]

[0007] When the STA's base NAV is set to a non-zero value by OBSS transmission, the virtual CS indicates busy, and therefore the Uplink Multi-User Channel Sensing (UL MU CS) rule prohibits the STA from transmitting an HE trigger-based PPDU on the RU assigned by the trigger frame, even if energy detection for the 20MHz channel containing the assigned RU indicates that the channel is idle. This results in a loss of transmission opportunity for the STA and thus reduces 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 communication device and communication method that can help improve the efficiency of uplink multi-user transmission in the presence of OBSS traffic.

[0009] In a general embodiment, the technology disclosed herein is a communication device comprising: a receiving unit that in operation receives a PHY layer data unit including a duration field, wherein the duration field includes duration information indicating a duration for which the communication device is prohibited from transmitting a high-efficiency (HE) trigger-based (TB) PHY layer data unit; a physical (PHY) layer circuit that in operation issues PHY-CCA (Clear Channel Evaluation) primitive parameters indicating busy or idle bandwidth information for each subchannel within the operating bandwidth; and a medium access control (MAC) circuit that, based on the duration information, updates the NAV value in operation when the indicated duration is greater than the current network allocation vector (NAV) value and the communication device is determined not to be the target recipient of the received PHY layer data unit, and also determines in operation the busy / idle state of at least one subchannel including a resource unit (RU) to which the HE TB PHY layer data unit should be transmitted, wherein the MAC circuit determines the HE The system features a communication device that controls the transmission of TB PHY layer data units during operation.

[0010] These general and specific embodiments may be implemented using devices, systems, methods, and computer programs, or any combination thereof.

[0011] The communication devices and communication methods described herein 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 also be obtained individually from the various embodiments and features of the specification and drawings, and these do not all need to be provided to obtain one or more such benefits and / or advantages. [Brief explanation of the drawing]

[0013] [Figure 1] This is a diagram of an overlapping wireless network to which the embodiments of this disclosure may be applied. [Figure 2] This is an illustrative frame exchange sequence timing diagram highlighting the NAV configuration procedure. [Figure 3A] This is another illustrative frame exchange sequence timing diagram that clarifies how the two NAVs introduced in 802.11ax are updated. [Figure 3B] This diagram shows the naming convention for 20MHz channels in broadband channels. [Figure 4] This is an illustrative diagram of an uplink multi-user transmission illustrating the UL MU CS rule in 802.11ax. [Figure 5] This figure shows the technical issues addressed in this disclosure. [Figure 6] This table shows how various parameters related to the UL MU CS mechanism are updated with respect to the frame sequence shown in Figure 4. [Figure 7A] This is an example of a frame exchange sequence demonstrating multi-channel virtual carrier detection (CS) introduced in the first embodiment. [Figure 7B] This is a table showing the encoding scheme for the BW field of the NAV according to the first embodiment. [Figure 8A] This is a flowchart showing the rules for a multi-channel virtual CS according to the first embodiment. [Figure 8B] This table shows how various parameters related to the UL MU CS mechanism are updated based on the modified multi-channel virtual CS rules according to the first embodiment. [Figure 9] This diagram shows three overlapping wireless networks. [Figure 10A] This is an example of a frame exchange sequence that demonstrates the update rules for the basic NAV in the presence of multiple OBSSs according to the first embodiment. [Figure 10B]A flowchart showing the basic NAV update rules in the presence of multiple OBSS according to the first embodiment. [Figure 11A] An example of a frame exchange sequence showing alternative rules for updating the basic NAV in the presence of multiple OBSS according to the first embodiment. [Figure 11B] A flowchart showing alternative rules for updating the basic NAV in the presence of multiple OBSS according to the first embodiment. [Figure 11C] Another flowchart showing alternative rules for updating the basic NAV in the presence of multiple OBSS according to the first embodiment. [Figure 12] A table showing additional members proposed for the PHY-CCA.indication primitive according to the first embodiment. [Figure 13A] An exemplary UL MU transmission showing the second embodiment of the present disclosure. [Figure 13B] A diagram of a bitmap used to record channel states according to the second embodiment of the present disclosure. [Figure 14] An example of a frame exchange sequence showing multi-channel virtual carrier sensing (CS) introduced in the second embodiment. [Figure 15] A simplified block diagram of an exemplary STA that implements the disclosed multi-channel virtual carrier sensing. [Figure 16] A detailed block diagram of an exemplary STA that implements the disclosed multi-channel virtual carrier sensing. [Figure 17] An example of a frame exchange sequence showing multi-channel virtual carrier sensing (CS) according to the third embodiment. [Figure 18] A table showing 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] A flowchart showing the rules for the multi-channel UL MU CS mechanism according to the third embodiment. [Figure 20] This table lists how the STA obtains channel bandwidth information from the received PPDU. [Figure 21] This table shows additional members proposed for the PHY-CCA.indication primitive according to the third embodiment. [Figure 22] A fourth embodiment describes the format of the NAV held by the STA and the encoding of the TX_Allowed field. [Figure 23] This is an example of a frame exchange sequence demonstrating multi-channel virtual carrier detection (CS) according to the fourth embodiment. [Figure 24] Another figure illustrating the technical issues addressed in this disclosure is provided to further highlight the improvements made by the fourth embodiment. [Figure 25] This table shows 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] This is a flowchart showing the rules for the multi-channel UL MU CS mechanism according to the fourth embodiment. [Figure 27] This is an example of a frame exchange sequence that demonstrates the update rules for the basic NAV in the presence of multiple OBSSs, according to the fourth embodiment. [Figure 28] This is a flowchart illustrating the update rules for the basic NAV in the presence of multiple OBSSs according to the fourth embodiment. [Modes for carrying out the invention]

[0014] This disclosure can be better understood with the help of the following figures and embodiments. The embodiments described herein are essentially illustrative and are used to illustrate some of the possible uses and applications of this disclosure and should not be construed as limiting this disclosure with respect to alternative embodiments not expressly described herein.

[0015] As explained earlier, multi-user transmission using OFDMA in both the downlink and uplink directions is a key technique adopted by the IEEE 802.11ax task group to achieve throughput improvement goals. In the downlink direction, multi-user transmission is relatively simpler than in the uplink direction, as the AP transmits all multi-user frames. A 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. Uplink transmission is more complex than downlink transmission because it requires time synchronization of transmissions from multiple STAs, and it must be ensured that transmissions from different STAs do not interfere with each other, i.e., each STA must be assigned a unique RU. In IEEE 802.11ax, this is achieved by a special control frame called a trigger frame, which is transmitted by the AP.

[0016] The trigger frame contains information used for UL transmission, such as resource unit (RU) allocation, uplink (UL) PPDU length, and MCS. Furthermore, the trigger frame also includes a "CS request subfield" that informs the STA whether carrier detection is required before UL MU transmission. Upon receiving the trigger frame, the STA, which has been allocated an RU in the trigger frame, may transmit each UL frame of the UL multi-user (MU) PPDU after a period of Short Interframe Space (SIFS) from the end of the trigger frame. If the value of the "CS request subfield" in the trigger frame is 1, the STA is required to follow the Uplink Multi-User Channel Detection (UL MU CS) procedure, which states that the STA is required to consider a virtual CS and also perform energy detection on all 20MHz channels to which the RU is allocated to the STA in order to participate in UL MU transmission. The STA is permitted to transmit the HE trigger-based PPDU only if the virtual CS is idle and all 20MHz channels containing the allocated RU in the trigger frame are also considered idle. If not all 20MHz channels are idle, the STA will not be permitted to transmit on the assigned RU.

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

[0018] Figure 2 shows an exemplary frame exchange sequence 200 highlighting the 802.11 NAV setting procedure. AP1 101 is attempting to send a data frame to STA1 110. To secure the transmission, AP1 first sends a Request To Send (RTS) frame to STA1, to which STA1 responds with a Clear To Send (CTS) frame, which is sent after a period of Short Interframe Space (SIFS) from 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 sent in response to the data frame. All STAs that receive an RTS frame, except the intended recipient STA1, update their NAVs to the value of the Duration field in the RTS frame if their existing NAV values ​​are smaller. Similarly, all STAs that receive a CTS frame, except the intended recipient AP1, update their NAVs to the value of the Duration field in the CTS frame if their existing NAV values ​​are smaller. In this way, all STAs within the radio coverage of AP1 and STA1 will have their NAV sets. Upon successful reception of a CTS frame, AP1 transmits a data frame after a SIFS period from the end of the CTS frame, to which STA1 responds with an Ack frame. STA2 120 and all other STAs that have received an RTS / CTS frame will have their NAV sets and therefore will not be permitted to transmit to them during this period, thus ensuring that AP1's transmission of data frames is protected.

[0019] Figure 3A shows an exemplary frame exchange sequence 300 within two BSS100 and 145 in Figure 1, highlighting the procedure for updating the two types of NAVs introduced in 802.11ax, namely the in-BSS NAV and the base NAV. Maintaining two types of NAVs allows for more efficient spatial reuse of frequency resources under certain conditions. This 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 PPDU312, STA2 120 determines that PPDU312 is an intra-BSS PPDU by checking either the BSS color field or the BSSID field, or both. Since STA2 is not the recipient of PPDU312, STA2 sets its intra-BSS NAV, NAV1 320, to a value indicating the period between the end of DL PPDU312 and the end of TXOP1. Similarly, upon receiving DL PPDU342, STA2 determines that PPDU342 is an inter-BSS PPDU by checking either the BSS color field or the BSSID field, or both. STA2 sets its inter-BSS NAV, NAV2 330, to a value indicating the period between the end of DL PPDU342 and the end of TXOP2.

[0020] Referring to Figure 3B, the naming convention for 20MHz channels in an 802.11 infrastructure BSS operating on 40MHz, 80MHz, or 80+80MHz or 160MHz channels is shown. This is just one example of how broadband channels can be formed, and many other similar configurations are possible. When the BSS is first set up, one of the 350 20MHz channels is designated as the primary 20MHz channel. The primary 20MHz channel is also simply called the primary channel and is of great importance. The IEEE 802.11 specification requires that all transmissions in an infrastructure BSS include a primary 20MHz 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 a primary 20MHz channel.

[0021] Furthermore, in an infrastructure BSS, all beacon frames are transmitted on the primary 20MHz channel. 20MHz channels other than the primary 20MHz channel are called non-primary channels. 20MHz channels 355 adjacent to the primary 20MHz channel, which together form the 40MHz channel of a 40MHz BSS or the primary 40MHz of a wider BSS, are called secondary 20MHz channels or simply secondary channels. In an 80MHz BSS or wider BSS, the primary 20MHz channel 350 and secondary 20MHz channel 355 together form the primary 40MHz channel. In an 80MHz BSS or wider BSS, 40MHz channels adjacent to the primary 40MHz channel (consisting of two 20MHz channels 360 and 365), which together form the 80MHz channel of an 80MHz BSS or the primary 80MHz channel of a wider BSS, are called secondary 40MHz channels. 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, an 80MHz channel that does not include the primary 20MHz channel 350 and forms the 80+80MHz channel or 160MHz channel together with the primary 80MHz channel (consisting of four 20MHz channels 370, 375, 380, and 385) is called the secondary 80MHz channel. In a 160MHz channel, the primary 80MHz channel and the secondary 80MHz channel are adjacent to each other, but in an 80+80MHz channel, the primary 80MHz channel and the secondary 80MHz channel do not need to 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. 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 used by the STA for UL transmission, such as resource unit (RU) allocation, PPDU length, and MCS. Upon receiving the trigger frame 410, the STA, which was allocated RUs in the trigger frame, can transmit each UL frame of the UL multi-user PPDU after a SIFS period from the end of the trigger frame without having to compete for wireless medium.

[0023] The UL MU CS procedure in 802.11ax states that an STA assigned a RU in a trigger frame with a CS request field set to 1 in order to participate in UL MU transmission is required to consider a virtual CS and perform an energy-sensing clear channel evaluation (ED-based CCA) on all 20MHz channels to which the RU is assigned to that STA. The STA is permitted to transmit its UL PPDU (HE trigger-based PPDU) only if the virtual CS is idle and, furthermore, all 20MHz channels including the assigned RU are deemed idle by the ED-based CCA. If not all 20MHz channels are idle, the STA is not permitted to transmit on the assigned RU. The virtual CS is considered idle if the counter values ​​for both the BSS in-NAV and the base NAV are zero. In this example, BSS1 100 in Figure 1 operates on 80MHz channels, with CH1, CH2, CH3, and CH4 representing the primary 20MHz channel, secondary 20MHz channel, tertiary 20MHz channel, and quaternary 20MHz channel. In 802.11 terminology, CH1 is called the primary 20MHz channel or simply the primary channel, CH2 is called the secondary 20MHz channel or simply the secondary channel, and CH3 and CH4 together form the secondary 40MHz channel.

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

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

[0026] Table 600 in Figure 6 lists various parameters related to the UL MU CS mechanism for STA2 in the UL MU transmission sequence shown in Figure 5. Since the transmission on the primary channel CH1 belongs to OBSS, STA2's basic NAV is set to a non-zero value, and even if the NAV in BSS is zero, the virtual CS will show busy. Similarly, the ED-based CCA will return busy on CH1 and CH2, and idle on CH3 and CH4. According to the UL MU CS rules, even if there are no ongoing transmissions on both channels (CH3 and CH4) containing the RU for STA2, the virtual CS will show busy, so UL MU CS will consider the medium to be busy on all four 20MHz, and as a result, STA2's transmission of UL PPDU450 is not permitted. This can be seen as a case where the basic NAV is excessively protective. That is, even if STA2 were permitted to transmit its UL PPDU450 on CH3 and CH4, that transmission would not cause any interference to the OBSS transmission and would result in higher channel utilization efficiency.

[0027] The drawbacks described above stem from the fact that the NAV (Baseline NAV, or NAV within BSS, or Basic NAV) is based solely 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 due to the reception of the correct PPDU, 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 could be further improved if this excessive protection could be avoided.

[0028] Based on the above findings, the inventors of this application have arrived at this disclosure. A communication method and apparatus 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 for which a primary channel forming part of a broadband channel is busy, but also records which of the other non-primary channels of the broadband 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 detection proposed in this disclosure are described in detail in the following paragraphs.

[0030] <First Embodiment> As previously noted, currently, the NAV (Baseline NAV, or NAV within BSS, or Basic NAV) is based solely 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 channel is busy due to the reception of the correct PPDU, the NAV is set and the state 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 it not only records the duration for which the primary channel is busy, but also records which non-primary channels 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 up the NAV. Since the bandwidth of the PPDU that sets up the NAV always includes the primary 20MHz channel, the BW field indicates which non-primary channels are busy. This busy channel information allows the STA to easily infer which channels are idle and can be used for simultaneous transmission without causing interference to the busy channels.

[0031] Referring to Figure 7A, a series of exemplary frame exchange sequences are shown to visually illustrate the concept of the frequency dimension of the NAV in an 80 MHz BSS. The upper half of Figure 7A shows three transmit sequences of different bandwidths, namely TXOP1 712 at 80 MHz, TXOP2 722 at 40 MHz, and TXOP3 732 at 20 MHz. Each transmit sequence involves the exchange of PPDUs between an AP and one or more STAs belonging to the same BSS as this AP. For example, the first PPDU of a transmit sequence may be a trigger frame assigning the RU to a selected STA for UL MU transmission, followed by an 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, secondary 20 MHz channel, tertiary 20 MHz channel, and quaternary 20 MHz channel, respectively. The lower half of Figure 7A visually represents the two-dimensional NAV held by a third-party STA as proposed by this disclosure. The time points relevant to this example are indicated by t0, t1, t2, t3, t4, and t5.

[0032] An STA that is within the 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 PPDU710 of TXOP1 712, a third-party STA determines that it is not the receiver of the PPDU710, 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 the trigger frame carried by the PPDU710.

[0033] If the STA determines, in accordance with existing NAV rules, that it is not a receiver of PPDU710, it sets the NAV duration to a time period from time t0 to time t1, thereby prohibiting the STA from transmitting until time t1, which is the end of TXOP1 712. In addition to recording the NAV duration, according to the first embodiment, the STA also records 80 MHz, which is the bandwidth of the received PPDU710, as the BW field of the NAV. The two-dimensional NAV is represented by box 714, which represents the time period and frequency range over 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 PPDU720, the STA sets the NAV duration to the time period from time t2 to time t3, which is the end of TXOP2 722, while the BW field is set to 40 MHz, which is the bandwidth of PPDU720. This is shown as box 724. Furthermore, if the channel detection rules are modified accordingly, under certain conditions, a third-party STA may be permitted to transmit on unoccupied channels CH3 and CH4 within the NAV duration from t2 to t3 without causing interference to the ongoing transmit 722. This would facilitate 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 PPDU730, 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 20MHz, which is the bandwidth of PPDU730. This is shown as box 734. In this case, a third-party STA may be permitted to transmit on unoccupied channels CH2, CH3, and CH4 during the NAV duration from t4 to t5 without causing interference to the ongoing transmit 732. At time t5, when the NAV duration counts down to zero, the BW field is also reset to zero.

[0036] Figure 7B shows Table 750 of exemplary encodings for 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 enumerated in 750, in the example shown in Figure 7A, the BW field is set to 2 for NAV setting 714, to 1 for NAV setting 724, and to 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 or both of the NAVs can be extended to record the bandwidth of ongoing transmissions in their respective BSSs. Referring back to Figure 5, the overprotected NAV that prohibited STA2 from transmitting UL PPDU450 can be overcome by applying the concept of recording the bandwidth of ongoing OBSS transmissions as the BW field of the base NAV, while simultaneously making changes to the virtual CS rule and the UL MU CS mechanism.

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

[0039] Figure 8A shows a flowchart 800 illustrating how a virtual CS rule can be indicated for each 20MHz channel by adding a bandwidth field to the basic NAV. Starting with the primary 20MHz channel, for each 20MHz channel of the broadband channel from which a trigger frame is received, the process begins in step 810 when the STA receives a trigger frame that has a CS request field set to 1 and assigns a RU to the STA. Because the CS request field is set to 1 in the trigger frame, the STA is required to perform a UL MU CS before sending an HE trigger-based PPDU with the assigned RU. If the NAV in the BSS is non-zero in step 820, the process proceeds to step 830, indicating that the virtual CS is busy for that 20MHz channel, and the process ends, proceeding to the next 20MHz channel, if any. However, if the NAV in the BSS is zero in step 820, the process proceeds to step 840.

[0040] If the basic NAV duration is zero in step 840, the process proceeds to step 870, where the virtual CS indicates idle for that 20MHz channel, and the process terminates, proceeding to the next 20MHz channel, if any. However, if the basic NAV is not zero in step 840, the process proceeds to step 850. If a 20MHz channel is indicated as one of the busy channels by the BW field of the basic NAV in step 850, the process proceeds to step 860, where the virtual CS indicates busy for that 20MHz channel, and the process terminates, proceeding to the next 20MHz channel, if any. However, if a 20MHz channel is not indicated as one of the busy channels by the BW field of the basic NAV in step 850, the process proceeds to step 870, where the virtual CS indicates idle for that 20MHz channel, and the process terminates, proceeding to the next 20MHz channel, if any. The modified virtual CS rules allow virtual CS to be advertised for each individual 20MHz channel, and therefore the UL MU CS mechanism is also modified to advertise busy / idle for each individual 20MHz channel. If either energy-detect (ED) or virtual CS returns busy for a particular 20MHz channel, that 20MHz channel is considered busy.

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

[0042] Table 880 in Figure 8B lists various parameters related to the modified UL MU CS mechanism for STA2 in the UL MU transmission sequence shown in Figure 5. Compared to Table 600 in Figure 6, Table 880 includes one additional column 882 indicating the channel state based on the BW field of the basic NAV. Since transmission on the primary channel belongs to OBSS, the BSS-in-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 transmission sequence 500 in Figure 5, since OBSS transmission occurs only on CH1 and CH2, the BW field of the basic NAV is set to 1 (40MHz). This means that CH1 and CH2 are recorded as busy.

[0043] Similarly, CH3 and CH4 are recorded as idle as indicated by descriptions 884 and 886, respectively. According to the modified virtual CS rules described in Figure 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 idle, as indicated by descriptions 888, 890, 892, and 894, respectively. Since CH3 and CH4 are considered idle, according to the UL MU CS transmission rules, STA2 is permitted to transmit its UL PPDU450 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 an OBSS with respect to STA2. The BSS arrangement in Figure 9 is used to illustrate the rules regarding the updating of the NAV bandwidth field introduced in this disclosure. Two options can be considered regarding the updating of 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 STA's receiving range that is neither the sender nor receiver of the transmission. A NAV setting PPDU refers to a PPDU carrying at least one frame that may result in a change to the STA's NAV counter (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, the BW field is updated if the bandwidth of the new PPDU is wider than the existing BW field.

[0046] Option 2 (Dynamic Update): The BW field is dynamically adjusted to reflect the actual bandwidth of the NAV setting PPDU for the ongoing third-party transmission. This option is more complex than Option 1 and requires a temporary record of the bandwidth and duration of each third-party transmission received. 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 rule of Option 1 (static update) mentioned above regarding the bandwidth field of the STA2 base NAV in the BSS arrangement shown in Figure 9, assuming that all three BSSs, BSS1 100, BSS2 145, and BSS3 900, are 80 MHz BSSs. At the top of Figure 10A, two transmit sequences with different bandwidths are shown in BSS2 145, namely TXOP1 1012 at 80 MHz and TXOP2 1022 at 40 MHz. Similarly, at the bottom of Figure 10A, two transmit sequences with different bandwidths are shown in BSS3 900, namely TXOP3 1032 at 20 MHz and TXOP4 1034 at 80 MHz.

[0048] The central part of Figure 10A shows a visual representation of the two-dimensional basic NAV held by STA2 120 as proposed in this disclosure. The time points relevant to this example are indicated by t0, t1, t2, t3, t4, t5, t6, and t7. Upon receiving the first PPDU 1010 of TXOP1 1012, STA2 determines, based on the BSS color field in the PHY header or the BSSID field in the MAC header, that PPDU 1010 is an OBSS PPDU from BSS2 and that STA2 is not one of the recipients of PPDU 1010. In accordance with 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 80MHz (the bandwidth of the received PPDU 1010), and as a result, STA2 is prohibited from transmitting on CH1, CH2, CH3, and CH4 until time t2, which is the end of TXOP1 1012. The two-dimensional NAV is represented by box 1014, which indicates the time period and frequency range in 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 and that it is not one of the recipients of PPDU 1030. Because the duration indicated in 1030 is longer than the existing NAV duration, STA2 updates the NAV duration to time t3 in accordance with the NAV rules for updating the NAV duration, and as a result, STA2 is prohibited from transmitting until time t3, which is the end of TXOP3 1032. From time t2 to time t3, actual ongoing OBSS transmissions occur only on BSS3, but the NAV BW field indicates 80MHz. This can be considered an overprotection zone 1016. In an overprotection zone 1016, even if all channels CH2, CH3, and CH4 included in zone 1016 are idle for STA2 from time t2 to time t3, STA2 is restricted from transmitting on all three channels. At time t3, when the base 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. In accordance with the existing NAV rules for updating the NAV duration, STA2 sets the NAV duration from time t4 to time t7 and sets the NAV BW field to 40MHz (the bandwidth of the received PPDU 1020), and as a result, STA2 is 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 indicates the time period and frequency range over 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 indicated in 1034 is shorter than the existing NAV duration, STA2 does not renew the NAV duration according to the NAV rules for renewing NAV durations. However, because the bandwidth of PPDU 1034 is wider than the current NAV BW field, the BW field is updated to 80 MHz as indicated by 1026 and remains at 80 MHz until time t7.

[0052] From time t6 to time t7, actual ongoing OBSS transmissions occur only on BSS2, but the NAV BW field shows 80MHz. This can be considered an overprotection zone 1028. In overprotection zone 1028, even if both channels CH3 and CH4 included in zone 1028 are idle for STA2 from time t6 to time t7, STA2 is restricted from transmitting on these channels. However, if the OBSS transmission is on a narrower bandwidth channel, option 1 still allows for more efficient secondary channel reuse 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 flowchart 1040 in Figure 10B. The process begins in step 1042 when a NAV configuration PPDU is received. In step 1044, if the PPDU increments the duration field of the base NAV, the process proceeds to step 1046. In step 1046, the base NAV duration is updated according to the relevant duration information in the PPDU (for example, 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. In step 1044, if the PPDU does not increment the duration field of the base NAV, the process proceeds to step 1048. In step 1048, if the received PPDU increments the BW field, the process proceeds to step 1050; otherwise, the process terminates. In step 1050, the BW field of the base NAV is updated to reflect the bandwidth of the received PPDU, and the process terminates.

[0054] Referring to Figure 11A, the same exemplary transmission sequence shown in Figure 10A is reused to visually illustrate the Option 2 (dynamic update) rule mentioned above regarding the bandwidth field of the 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 and is not one of the recipients of PPDU 1010. Following the existing NAV rule for updating the NAV duration, STA2 sets the NAV duration from time t0 to time t2 and sets the NAV BW field to 80MHz (the bandwidth of the received PPDU 1010), which results in STA2 being prohibited from transmitting on CH1, CH2, CH3, and CH4 until time t2, which is the end of TXOP1 1012.

[0055] The two-dimensional NAV is represented by box 1110, which shows the time period and frequency range over 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 and that it is not one of the recipients of PPDU 1030. Because the duration indicated in 1030 is longer than the existing NAV duration, STA2 must update the NAV duration by time t3, according to the NAV rules for updating the NAV duration. However, from time t2 to time t3, actual ongoing OBSS transmissions are made only by 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. The bandwidth of PPDU1030 is 20MHz, which is narrower than the current NAV BW field, so no changes are made to the NAV BW field, but the bandwidth of PPDU1030 is stored as a temporary variable New_BW. When the BW_update_timer expires at t2, the NAV BW field is updated to New_BW(20MHz), 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, since all of CH2, CH3, and CH4 are idle for STA2. 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 from time t4 to time t7 and sets the NAV BW field to 40MHz (the bandwidth of the received PPDU 1020), and as a result, STA2 is prohibited from transmitting on CH1 and CH2 until time t7, which is the end of TXOP2 1022. The two-dimensional NAV is represented at time t4 by box 1024, which represents the time period and frequency range in which STA2 is prohibited from transmitting.

[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 renew the NAV duration according to the NAV rules for renewing NAV durations. 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 indicated by 1122. However, from time t6 to time t7, the bandwidth of the ongoing OBSS transmission 1022 is only 40MHz, and therefore, before the NAV BW field is updated to 80MHz, the current NAV BW is saved as New_BW, the end time t6 of the BSS3 transmission 1036 is recorded as BW_update_time, and the timer (BW_update_timer) is set to expire at BW_update_time. When BW_update_timer expires at time t6, the NAV BW field is updated to New_BW(40MHz), 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 these channels between time t6 and time t7, since both channels CH3 and CH4 are idle for STA2.

[0058] The NAV update rules according to option 2 are summarized by flowchart 1140 in Figure 11B and 1180 in Figure 11C. The process begins in step 1142 when a NAV configuration PPDU is received. In step 1144, if the PPDU increments the duration field of the base NAV, the process proceeds to step 1146; otherwise, the process proceeds to step 1162. In step 1146, if the bandwidth of the received PPDU is less than the base NAV BW field, the process proceeds to step 1148; otherwise, the process proceeds to step 1154. In step 1148, if the variable BW_update_time is zero, the expiration date of the current base 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 date of the current base NAV, is stored in BW_update_time, and the process proceeds to step 1150. In step 1150, the larger of the two values, namely 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 base NAV BW field, the process proceeds to step 1156; otherwise, the process proceeds to step 1158. In step 1156, the base NAV BW field is updated to the bandwidth of the received PPDU, and the process proceeds to step 1158. In step 1158, since the base NAV bandwidth is expected not to change until the end of the base NAV duration, BW_update_timer is stopped if it is running, both BW_update_time and New_BW are set to 0, and the process proceeds to step 1160. In step 1160, the base NAV duration is updated according to the relevant duration information in the PPDU (for example, based on the TXOP duration field in the PHY header or the duration field in the MAC header), and the process terminates.

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

[0061] The basic NAV BW adjustment process is summarized by process 1180. Process 1180 is initiated in step 1182 when the BW_update_timer expires. In step 1184, if the basic NAV duration is non-zero, the process proceeds to step 1186; otherwise, the process proceeds to step 1190. In step 1186, if the value of New_BW is non-zero, the process proceeds to step 1188; otherwise, the process proceeds to step 1190. In step 1188, the BW field of the basic NAV is updated to New_BW, and process 1180 terminates. In step 1190, both BW_update_time and New_BW are set to 0, and process 1180 terminates.

[0062] Referring to Figure 12, Table 1200 lists the possible values ​​and meanings of the channel-list parameter of the PHY-CCA.indication primitive used by HE STA. The PHY-CCA.indication(STATE,{channel-list}) primitive is used by the PHY layer of HE STA to indicate the state of a channel to the MAC layer. The PHY-CCA.indication primitive always includes a STATE parameter, but includes a channel-list parameter only when the STATE parameter is BUSY and the states of multiple channels are being 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 for three values ​​primary20, primary40, and primary80 listed in lines 1210, 1220, and 1230, respectively, which are added by the first embodiment of this disclosure. Referring to Figure 3B, the value of "primary" in the channel-list parameter indicates that the primary 20MHz channel 350 and all other non-primary channels are busy.

[0063] The value of "secondary" indicates that the secondary 20MHz channel 355 is busy while the primary 20MHz channel 350 is idle. The value of "secondary40" indicates that the secondary 40MHz channels (360 and 365) are busy while the primary 20MHz channel 350 and secondary 20MHz channel 355 are idle. The value of "secondary80" indicates that the secondary 80MHz channels (370, 375, 380, and 385) are busy while the primary 20MHz channel 350, the secondary 20MHz channel 355, and the two 20MHz channels 360 and 365 that together form the secondary 40MHz channel are idle. As mentioned earlier, the value of "primary" in the channel-list parameter indicates that the primary 20MHz 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 include the primary 20MHz channel, and the STA is not permitted to transmit as long as the primary 20MHz channel is busy.

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

[0065] For example, referring to Figure 7A, when PPDU710 is received, the PHY layer of the receiving STA issues the PHY-CCA.indication(BUSY,{primary}) primitive to the MAC layer to indicate that all four 20MHz channels are busy. Subsequently, when PPDU720 is received, the PHY-CCA.indication(BUSY,{primary40}) primitive is issued to indicate that the primary 20MHz channel CH1 and secondary 20MHz channel CH2 are busy, while channels CH3 and CH4 are idle. Similarly, when PPDU730 is received, the PHY-CCA.indication(BUSY,{primary20}) primitive is issued to indicate that the primary 20MHz 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 primitives to correctly set the BW field of the NAV.

[0066] <Second Embodiment> Referring to Figure 13A, an exemplary uplink multi-user transmit sequence 1300 shows the case where the bandwidth of the PPDU changes during the same TXOP 1305. AP2 102 in Figure 1 transmits an 80MHz DL MU PPDU 1310, in addition to other frames, which includes two unicast trigger frames 1312 and 1314 addressed to STA5 150 and STA6 160, respectively. Trigger frame 1312 assigns the RU to STA5 on the primary channel CH1, while trigger frame 1314 assigns the RU to STA6 on the secondary channel CH2. AP2 102 also protects subsequent uplink transmits by setting either the TXOP duration field 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. After SIFS from PPDU1310, STA5 transmits its UL PPDU1320 on CH1, while STA6 transmits its UL PPDU1330 on CH2.

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

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

[0069] Referring to Figure 14, a series of exemplary frame exchange sequences are shown to visually illustrate a two-dimensional NAV according to a second embodiment in an 80 MHz BSS. The upper half shows three transmit sequences with variable bandwidth, namely TXOP1 1412, TXOP2 1422, and TXOP3 1432. Each transmit sequence includes an exchange of PPDUs between an AP and one or more STAs belonging to the same BSS as this AP. For example, the first PPDU in a transmit sequence may be a trigger frame assigning a RU for UL MU transmission to a selected STA, followed by an 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, secondary 20 MHz channel, tertiary 20 MHz channel, and quaternary 20 MHz channel. The lower half of this example shows a visual representation of the two-dimensional NAV held by a third-party STA as proposed by this disclosure. A bitmap used to record the BW field of the NAV is also shown. The time points relevant to this example are indicated by t0, t1, t2, t3, t4, and t5. An STA that is within the 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.

[0070] Upon receiving the first PPDU1410 of TXOP1 1412, the third-party STA determines that it is not the recipient of the PPDU1410, 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 PPDU1410. If the STA determines that it is not the recipient of the PPDU1410 according to the existing NAV rules, 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 PPDU1410 and determines that RUs have been assigned on CH1, CH2, and CH3 for subsequent uplink transmissions. 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, which prohibits STA from transmitting on CH1, CH2, and CH3 until time t1, which is the end of TXOP1 1412.

[0071] Similarly, upon receiving PPDU1420, the STA sets the NAV duration to time t3, which is the end of TXOP2 1422. The STA decodes the trigger frame in PPDU1420 and determines that RUs have been allocated 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, which prohibits the STA from transmitting on CH1 and CH2 until time t3.

[0072] Similarly, when receiving the PPDU 1430, the STA sets the NAV duration until the time t5 which is the end of the TXOP3 1432. The STA decodes the trigger frame in 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 where the STA is prohibited from transmitting on CH1 until the 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] STA1500 may contain one or more instances of memory 1506. Memory 1506 records duration information carried by the received PPDU and, where applicable, the bandwidth occupied by the PPDU. If the PPDU decoder determines that the received PPDU was transmitted by the STA from its corresponding BSS, memory 1506 records only the duration information as an in-BSS NAV. However, if the PPDU decoder determines that the received PPDU was transmitted by an OBSS STA, 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] Figure 16 is a detailed block diagram of an exemplary STA1600 implementing the two-dimensional NAV described herein, which may be any one of the STAs in Figure 1. The STA1600, being a wireless device, comprises a memory 1620, a secondary storage device 1640, and a central processing unit (CPU) 1630 coupled to one or more wireless communication interfaces 1650. The secondary storage device 1640 may be a non-volatile computer-readable storage medium used to permanently store associated instruction code, data, etc. At startup, the CPU 1630 can copy the instruction code and associated data to the volatile memory 1620 for execution. The instruction code may be an operating system, user application, device driver, executable code, etc., required for the operation of the STA1600. The STA1600 may also be equipped with a power supply 1610, such as a lithium-ion battery or a coin cell battery, or it may be a mains electricty.

[0077] The wireless communication interface 1650 may include an interface for cellular communication, or an interface for short-range communication protocols such as Zigbee, or it may be a WLAN interface. The wireless interface 1650 may further include a MAC module 1652, a PHY module 1660, and an antenna 1670. Among the other submodules, the MAC module 1652 may include a carrier detection 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 contained in a received PPDU when the STA 1600 is not the intended recipient of the PPDU. The carrier detection module 1654 is responsible for performing both physical carrier detection (energy detection) and virtual carrier detection (NAV) before a transmission that requires carrier detection.

[0078] For clarity, the STA1600 may comprise many other components not shown in Figure 16. Only the components most relevant to this disclosure are shown.

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

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

[0081] The central part of Figure 17 shows a visual representation of the NAV duration held by a third-party STA in accordance with the rules defined by the IEEE 802.11 specification. An STA that is within the radio coverage of an ongoing transmission and is neither the sender nor the intended receiver of that transmission is considered a third-party STA with respect to that transmission. The lower part of Figure 17 shows a visual representation of the OBSS_BW information held by the same third-party STA. The time points 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 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 by PPDU 1710. If the STA determines that it is not the intended recipient of PPDU 1710, in accordance with the existing IEEE 802.11 NAV rules, it sets the NAV duration to a time period from time t0 to time t1, thereby prohibiting the STA from transmitting until time t1, which is the end of TXOP1 1712. In addition to recording the NAV duration, according to the third embodiment, the STA also records the bandwidth information of PPDU 1710 setting 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 in Figure 7B, or it may be held as an 8-bit bitmap 1390 in 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 time t3, which is the end of TXOP2 1722, while the OBSS_BW information field is set to 40MHz (the bandwidth of 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 time t5, which is the end of TXOP3 1732, while the OBSS_BW information field is set to 20MHz (the bandwidth of 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 reset to zero again. Furthermore, if the channel detection rules are modified accordingly, under certain conditions, a third-party STA may be permitted to transmit on unoccupied channels CH3 and CH4 during the time period from t2 to t3, and on channels CH2, CH3, and CH4 during the time period from t4 to t5, without causing interference to the ongoing transmissions 1722 and 1732, respectively. This results in more efficient reuse of unoccupied secondary channels.

[0084] Traditionally, an IEEE 802.11 STA is only required to receive and decode PPDUs that overlap with the STA's primary 20MHz channel, and is not required to receive or decode PPDUs that do not overlap with its primary 20MHz channel. However, if the STA is capable of receiving and decodering such PPDUs, it 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 20MHz channel and is used by a third-party STA. When the STA receives the first PPDU 1740 of TXOP4 1742, if the STA is capable of receiving and decoding the PPDU, it 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 by the STA as a reference to inform the associated AP of the channel availability. For example, if the STA performs the operation of a voluntary Bandwidth Query Report (BQR) as defined in IEEE 802.11ax, the STA can use the OBSS_BW information field to populate the available channel bitmap that the STA sends to its associated AP in the Bandwidth Query Report. TXOP4 1742 does not set a NAV duration for the STA and therefore does not prevent the STA from sending. However, by recording the bandwidth of TXOP4 1742 in the OBSS_BW information field, the STA can inform its AP that CH3 and CH4 are expected to be busy with respect to the STA over 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 transmissions to / from the STA during the time period from time t6 to time t7.

[0086] Referring back to Figure 5, the overprotective NAV that prohibited STA2 from transmitting UL PPDU450 can be overcome by applying the concept from BSS2 145 in Figure 1, which records bandwidth information of ongoing OBSS transmissions as the OBSS BW information field, while simultaneously making changes to the virtual CS rule and the UL MU CS mechanism.

[0087] Table 1800 in Figure 18 lists various parameters related to the modified UL MU CS mechanism for STA2 in the UL MU transmission sequence shown in Figure 5. Table 1800 and its contents are the same as Table 880 in Figure 8B, except that the OBSS_BW information field is provided separately from the basic NAV 1810 in Table 1800. Since OBSS transmissions from BSS2 145 overlap only 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 in Figure 18, respectively.

[0088] According to the third embodiment, the virtual CS rule is modified so that the busy / idle virtual CS state is considered for each 20MHz channel. If the base NAV duration counter is non-zero, only the 20MHz channels indicated as busy by the OBSS_BW information field are considered 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 to be busy, while CH3 and CH4 are considered 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 permitted to transmit its UL PPDU450 on 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 20MHz channel including the RU allocated for STA uplink transmission, NAV will be considered 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 up by an internal frame in BSS. - The NAV duration counter is zero. - The NAV duration counter is greater than zero, but its 20MHz channel is recorded as idle by the OBSS_BW information field.

[0089] If NAV is not considered, the virtual CS will show as idle for the 20MHz channel; otherwise, the virtual CS will show as busy for the 20MHz channel.

[0090] The UL MU CS rule 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 following the trigger frame, the STA must, in response to the trigger frame, consider the state of the CCA and virtual CS using the appropriate energy detection (ED) rules for at least each 20MHz channel containing the RU allocated for the STA's UL MU transmission. When the 20MHz channel containing the allocated RU in the trigger frame is considered idle, the STA may transmit an HE trigger-based PPDU. If the STA detects that not all 20MHz channels containing the allocated RU are idle, the STA must not transmit anything on the allocated RU.

[0091] Figure 19 shows a flowchart 1900 illustrating the UL MU CS transmission rule according to a third embodiment, where the virtual CS rule is indicated for each 20 MHz channel by holding OBSS transmission bandwidth information in OBSS_BW. The UL MU CS process is initiated in step 1910 for each 20 MHz channel of the broadband channel to which the AP has assigned a RU to the STA for uplink transmission in a trigger frame having a CS request field set to 1. 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 containing the assigned RU during the SIFS immediately following the end of the PPDU containing the trigger frame before transmitting the HE trigger-based PPDU.

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

[0093] In step 1980, a 20MHz channel is considered busy for UL MU transmission, and the process ends for that 20MHz channel. In step 1970, a 20MHz channel is considered idle for UL MU transmission, and the process ends for that 20MHz channel. This process is repeated for at least each 20MHz channel in the broadband channel to which an RU is assigned to the STA for uplink transmission. If all 20MHz channels containing RUs assigned to the STA are considered idle in the trigger frame, the STA can transmit its HE trigger-based PPDU.

[0094] Referring to Figure 20, Table 2000 lists various parameters from which an STA receiving a correct IEEE 802.11 PPDU to configure the 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 STA's PHY layer measures the received signal strength level, and if this signal strength level exceeds a certain threshold commonly called the preamble detection (PD) level, the PHY indicates this to the MAC layer with the PHY-CCA.indication(BUSY, primary) primitive. The STA continues to receive the remaining PHY header fields, and once the PHY header has been successfully received, the PHY layer issues the PHY-RXSTART.indication(RXVECTOR) primitive to the MAC.

[0095] The contents of RXVECTOR depend on the format of the received PPDU, and 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, which is based on the HE-SIG-A bandwidth field 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, which is based on the VHT-SIG-A1 bandwidth field of the PHY header of the received VHT PPDU.

[0096] If the received PPDU is an HT PPDU, the bandwidth is similarly indicated by the CH_BANDWIDTH parameter, where the CH_BANDWIDTH parameter is based on the CBW20 / 40 bits 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 complex because it can be either a legacy non-HT PPDU format or a non-HT duplicate PPDU format. The PPDU format of a non-HT PPDU can be determined by referring to the NON_HT_MODULATION parameter of 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 duplicate PPDU. That is, the same PPDU is duplicated on multiple 20MHz channels. In this case, the CH_BANDWIDTH parameter only indicates the estimated channel bandwidth. However, non-HT duplicate PPDUs may be transmitted by bandwidth signaling STAs. That is, the Transmitter Address (TA) field in the MAC header included in the received PPDU is a bandwidth signaling TA (the individual / group bits of the TA are 1). In such cases, the exact bandwidth of the PPDU can be determined by further referring to the CH_BANDWIDTH_IN_NON_HT parameter of RXVECTOR. In some cases, it may not be possible to determine the exact bandwidth of a non-HT duplicate PPDU. For example, CTS frames are typically transmitted in non-HT PPDU or non-HT duplicate PPDU format to ensure maximum NAV protection for legacy devices.

[0098] Since CTS frames do not even include a TA field, it is impossible to determine the exact bandwidth covered by a CTS frame if it is transmitted in a non-HT replication 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 so that all of the STA's operating channels are recorded as busy, in order to not allow the STA to transmit when the basic NAV duration counter is non-zero. This ensures that the STA does not inadvertently cause interference with an ongoing OBSS transmission.

[0099] Referring to Figure 21, Table 2100 lists the possible values ​​and meanings of the channel-list parameter of the PHY-CCA.indication primitive issued by the HE STA. In addition to the four existing members of the channel-list parameter, namely primary, secondary, secondary40, and secondary80, the HE STA may optionally include a per20MHz bitmap, in which case 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 ability to indicate channel states at such a 20MHz granularity, the STA may also alternatively use a per20MHz bitmap to set the OBSS_BW information field.

[0100] <Fourth Embodiment> As mentioned earlier, in some cases it may be impossible for the 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 PPDU setting up the NAV occupies only the primary 20MHz channel, the STA may have other information indicating that transmission on non-primary channels during the duration of the NAV may not be recommended.

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

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

[0103] Referring to Figure 22, 2200 shows the NAV held by the STA according to a fourth embodiment using two octets. According to the IEEE 802.11 specification, in most cases the STA updates its NAV based on the contents of the two-octet duration / ID field in the MAC header of a correct 802.11 frame. When used to carry the 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 may also use the 7-bit TXOP_DURATION parameter in RXVECTOR to update the NAV. In any case, 15 bits are sufficient to record the NAV duration, as shown by 2210.

[0104] The last bit, B15, is used as the 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 1, the STA may transmit on the non-primary 20MHz channel during the NAV duration, provided that other conditions permit (for example, if the energy detection (ED) base channel detection also returns the non-primary 20MHz channel as idle).

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

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

[0107] Upon receiving the first PPDU2310 from TXOP1 2312, the third-party STA determines that it is not the intended recipient of the PPDU2310, 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 by the PPDU2310. If the STA determines that it is not the recipient of the PPDU2310, according to existing NAV rules, it copies the protection duration from the relevant fields of the PPDU2310 and sets the NAV duration field 2210 to a time period, for example, from time t0 to time t1.

[0108] In addition to recording the NAV duration, according to the fourth embodiment, the STA also predicts whether transmission on another 20MHz channel within its operating bandwidth, separate from the primary 20MHz channel, is acceptable. To determine whether its transmission on a non-primary channel during the NAV duration is harmless, the STA may utilize information such as the bandwidth of the PPDU2310, its historical knowledge of neighboring OBSSs, relevant fields within the PPDU such as the Basic Service Set Identifier (BSSID), or sender / receiver addresses.

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

[0110] Similarly, upon receiving PPDU2330, STA sets the NAV duration to the time period from time t4 to time t5, which is the end of TXOP3 2332. However, at this point, STA predicts that its transmissions on non-primary 20MHz channels CH2, CH3, and CH4 during the NAV period will not interfere with subsequent transmissions of TXOP3 2332, and therefore STA sets the TX_Allowed flag 2220 to 1, indicating that STA may transmit on non-primary 20MHz channels during the NAV period from t4 to t5, provided otherwise permitted. This is visually shown by box 2336. However, as visually shown by box 2334, transmission on primary 20MHz channel CH1 during the NAV period is prohibited. At time t5, when the NAV duration counter becomes zero, the TX_Allowed flag is also reset to zero.

[0111] Figure 24 shows an exemplary UL MU transmit sequence 400 in yet another channel state to highlight the improved spectrum reuse made by the fourth embodiment. At the moment STA receives trigger frame 410 from AP1 (101 in Figure 1), there are no ongoing transmits on the primary 20 MHz channel within the radio coverage area of ​​STA1, STA3, and STA4, and both the BSS in-NAV and basic NAV for STA1, STA3, and STA4 are set to zero. However, as shown by transmit sequence 2400, in BSS2 (145 in Figure 1), there is an ongoing OBSS transmit on the primary channel CH1 within the radio coverage area of ​​STA2.

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

[0113] Upon receiving PPDU2410, STA2 determines it is an OBSS PPDU and sets its base NAV to the end of the transmit sequence 2400. The illustrated OBSS interference to STA2 is slightly different compared to that shown in Figure 5, where the OBSS transmit interferes only with the primary 20MHz channel CH1. However, under the original UL MU CS rules, the effect of the interference on STA2 is exactly the same. Since the base NAV is non-zero, the virtual CS returns busy, and even though energy detection returns idle on channels CH3 and CH4, STA2 is not permitted to transmit HE trigger-based PPDU450 on the assigned RUs of channels CH3 and CH4.

[0114] According to the fourth embodiment, the virtual CS rules are modified so that the busy / idle virtual CS state is considered differently with respect to different 20MHz channels. At a minimum, the virtual CS is considered differently with respect to the primary 20MHz channel and the remaining non-primary 20MHz channels within the STA operating bandwidth. When the base NAV duration counter is non-zero, the primary 20MHz channel is always indicated as busy by the virtual CS. However, whether a non-primary 20MHz channel is 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 20MHz 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 20MHz channels are indicated as idle.

[0115] Table 2500 in Figure 25 lists various parameters related to the modified UL MU CS mechanism according to the fourth embodiment with respect to STA2 in the UL MU transmission sequence 400 shown in Figure 24. Table 2500 and its contents are almost identical to Table 880 in Figure 8B, except that instead of maintaining the busy / idle state of each 20MHz channel by recording the bandwidth information of the PPDU that sets up the basic NAV when CH2 is idle, only the TX_Allowed flag is maintained, as indicated by the abbreviation TX_A2510. Upon receiving PPDU2410, STA2 determines that it is a BSS-to-BSS 20MHz PPDU based on relevant fields from the PPDU, such as the BSS color and the CH_BANDWIDTH parameter of RXVECTOR. STA2 can also have historical information that BSS2 operates only at 20MHz, and based on the BSS color or BSSID of the frame contained in PPDU2410, STA2 can reliably predict that OBSS transmission will be limited to the primary 20MHz channel CH1 during the NAV period. Therefore, STA2 determines that it is safe to transmit its UL MU PPDU on a non-primary channel during the NAV period and thus sets the TX_Allowed flag 2220 to 1.

[0116] According to the virtual CS rule in the fourth embodiment, CH1 is shown as busy 2522, but the non-primary channels CH2, CH3, and CH4 are shown as idle by the virtual CS because the TX_Allowed flag 2220 is 1. Similarly, when STA2 performs an energy detection (ED) based CCA during SIFS after PPDU410 containing the trigger frame, CH1 is shown as busy, while the three non-primary channels CH2, CH3, and CH4 are shown as idle. As shown by descriptions 2536, 2534, 2532, and 2530 respectively, the UL MU CS mechanism takes into account the states of both the virtual CS and energy detection, showing CH1 as busy, while CH2, CH3, and CH4 are considered 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 PPDU450 on the assigned RUs of CH3 and CH4, thereby promoting more efficient use of the wireless medium.

[0117] The virtual CS rule according to the fourth embodiment can be summarized as follows: - For each 20MHz channel including the RU allocated for STA uplink transmission, NAV will be considered 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 up by an internal frame in BSS. - 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 NAV is not considered, the virtual CS will show as idle for the 20MHz channel; otherwise, the virtual CS will show as busy for the 20MHz channel.

[0119] The UL MU CS rule 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 following the trigger frame, the STA must, in response to the trigger frame, consider the state of the CCA and virtual CS using the appropriate energy detection (ED) rules for at least each 20MHz channel containing the RU allocated for the STA's UL MU transmission. When the 20MHz channel containing the allocated RU in the trigger frame is considered idle, the STA may transmit an HE trigger-based PPDU. If the STA detects that not all 20MHz channels containing the allocated RU are idle, the STA must not transmit anything on the allocated RU.

[0120] Figure 26 shows a flowchart 2600 illustrating the UL MU CS transmission rule according to a fourth embodiment. The UL MU CS process is initiated in step 2610 for each 20 MHz channel of a broadband channel to which the AP has assigned a RU to the STA for uplink transmission in a trigger frame having a CS request field set to 1. 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 20 MHz channels containing 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 base 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 20MHz channel is the primary 20MHz 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 reports the 20MHz channel as idle, and the process proceeds to step 2670. In step 2660, the virtual CS reports the 20MHz channel as busy, and the process proceeds to step 2690.

[0122] In step 2670, the STA uses energy detection (ED) during the SIFS time immediately following the end of the PPDU containing the trigger frame to detect the wireless medium. If the channel is detected as busy, the process proceeds to step 2690; otherwise, the process proceeds to step 2680. In step 2690, the 20MHz channel is deemed busy with respect to UL MU transmission, and the process terminates with respect to this 20MHz channel. Similarly, in step 2670, the 20MHz channel is deemed idle with respect to UL MU transmission, and the process terminates with respect to this 20MHz channel. This process is repeated for at least each 20MHz channel in the broadband channel to which the STA has assigned a RU for uplink transmission. When all 20MHz channels containing the RU assigned to the STA in the trigger frame are deemed idle, the STA can transmit its HE trigger-based PPDU with the assigned RU.

[0123] Referring to Figure 27, a series of exemplary frame exchange sequences are shown to visually illustrate the updating rules for the TX_Allowed flag when there are multiple OBSSs within the STA's radio coverage, for example, in the BSS configuration shown in Figure 9, assuming that all three BSSs, BSS1 100, BSS2 145, and BSS3 900, are 80MHz BSSs. The top of Figure 27 shows three transmit sequences with different bandwidths in BSS2 145, namely the 80MHz TXOP1 2710 and two 20MHz TXOPs, TXOP2 2720 and TXOP3 2730. Similarly, the bottom of Figure 27 shows three transmit sequences with different bandwidths in BSS3 900, namely two 20MHz TXOPs, TXOP4 2740 and TXOP6 2760, and a variable bandwidth TXOP5 2750. The central portion of Figure 27 shows a visual description of the basic NAV held by the STA2 120 as proposed in the fourth embodiment. The time points relevant to this example are indicated by t0, t1, t2, t3, t4, t5, t6, t7, t8, t9, t10, and t11.

[0124] Upon receiving the first PPDU2712 of TXOP1 2710, STA2 determines, based on the BSS color field in the PHY header or the BSSID field in the MAC header, that PPDU2712 is an OBSS PPDU from BSS2 and that STA2 is not one of the recipients of the PPDU. In accordance with existing NAV rules regarding the updating of the NAV duration, STA2 sets the base NAV duration from time t0 to time t2. At the same time, based on the prediction of subsequent OBSS transmissions during the NAV duration, 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, STA2 updates the NAV duration to time t3, which is the end of TXOP4 2740, in accordance with the rules for updating NAV time. Even though STA2 determines that the bandwidth of TXOP4 2740 is only 20 MHz, based on its knowledge of the BSS2 transmission sequence 2710, STA2 determines that it should continue to prohibit transmission on non-primary channels during the extended NAV duration and therefore does not change the TX_Allowed flag.

[0126] Similarly, upon receiving the first PPDU 2722 from TXOP2 2720, STA2 sets the NAV duration from time t4 to time t7, since STA2 is not one of the PPDU recipients. STA2 determines that the bandwidth of TXOP2 2720 is only 20MHz and sets the TX_Allowed flag to 1, indicating that transmission on a non-primary 20MHz channel may be permitted 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 PPDU receivers. Because the duration indicated in 2752 is shorter than the existing NAV duration, STA2 does not renew the NAV duration in accordance with the NAV rules regarding NAV duration renewal. However, because the bandwidth of PPDU 2752 is wider than 20 MHz, STA2 anticipates the risk of interference to OBSS from transmission on a non-primary channel and therefore updates the TX_Allowed flag to 0 to prohibit initiating new transmissions on a non-primary channel during the remainder of the NAV duration. However, based on its prior knowledge of certain fields of PPDU2752 or BSS3 (for example, that this PPDU2752 includes frames that only request responses from 20MHz-only HE devices, i.e., devices that are only capable of operating on the primary 20MHz channel), if STA2 can determine that the bandwidth of TXOP5 is reduced to 20MHz, STA2 may also choose not to update the TX_Allowed flag, thereby continuing to allow transmission on the non-primary 20MHz channel during the NAV period.

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

[0129] Upon receiving the first PPDU 2762 from TXOP6 2760, STA2 determines that 2762 is an OBSS PPDU from BSS3 and that it is not one of the PPDU recipients. Since the duration indicated in PPDU 2762 is longer than the existing NAV duration, STA2 updates the NAV duration to time t11, which is the end of TXOP6 2760, according to the rules for updating the NAV duration. Since the bandwidth of TXOP6 2760 is also only 20MHz, STA2 chooses not to update the TX_Allowed flag, thereby continuing to allow transmission on the non-primary 20MHz channel during the NAV duration. 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 flowchart 2800 in Figure 28. The process begins in step 2810 when the NAV configuration OBSS PPDU is received. In step 2815, if the current value of the base 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 base NAV, the process proceeds to step 2830; otherwise, the process proceeds to step 2840. In step 2830, the base NAV duration is updated according to the relevant duration information in the PPDU (for example, 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 terminates.

[0132] In step 2850, the STA determines whether its transmission on the non-primary 20MHz channel could cause interference with the OBSS transmission. If so, the process proceeds to step 2860; otherwise, the process terminates. In step 2860, the STA sets the TX_Allowed flag to 0, and the process terminates.

[0133] In step 2870, if the bandwidth of the received PPDU is 20 MHz and the STA determines that its transmission on a non-primary 20 MHz channel will 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 base NAV, the process proceeds to step 2890; otherwise, the process terminates. In step 2890, the base 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 terminates.

[0134] It goes without saying that the configurations of the STA described above with reference to Figures 15 and 16 allow for the implementation of the third and fourth embodiments of this disclosure mentioned above.

[0135] In the embodiments described above, the disclosure is provided as hardware, for example, but it may also be implemented through the 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. Functional blocks may be formed as individual chips, or some or all of the functional blocks may be integrated onto a single chip. The term "LSI" is used herein, but depending on the degree of integration, the terms "IC," "system LSI," "super LSI," or "ultra LSI" may also be used.

[0137] Furthermore, circuit integration is not limited to LSIs and may be achieved by dedicated circuits other than LSIs or by general-purpose processors. After the manufacture of the LSI, a programmable field-programmable gate array (FPGA) or a reconfigurable processor that allows for the reconfiguration of the connections or settings of circuit cells within the LSI may be used.

[0138] If, as a result of advances in semiconductor technology or other technologies derived from it, alternative circuit integration technologies emerge to replace LSIs, functional blocks may be integrated using such technologies. Another possibility is the application of biotechnology, for example. [Industrial applicability]

[0139] This disclosure may be applied to wireless devices to perform efficient virtual carrier detection (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 Detection Module 1656 NAV bandwidth bitmap 1658 NAV duration counter 1660 PHY module 1670 Antenna

Claims

1. A receiver that receives duration information and physical layer protocol data units (PPDUs) indicating bandwidth information for one or more frequency channels from which the PPDUs have been received, The system includes a transmitter that transmits frames on frequency channels other than one or more frequency channels from which the PPDU was received, The transmitter does not transmit a frame on one or more frequency channels corresponding to the bandwidth information within the period indicated by the duration information. Communication device.

2. The communication device includes a circuit that determines whether the received PPDU is from the corresponding basic service set (BSS) or from an overlapping basic service set (OBSS). If the circuit determines that the PPDU is from an OBSS, or if the BSS to which the PPDU belongs is determined, it sets the period indicated in the PPDU as duration information and sets the bandwidth of one or more frequency channels from which the PPDU was received as bandwidth information. The transmitter transmits the frame on a frequency channel not covered by the bandwidth of one or more frequency channels corresponding to the bandwidth information. The communication device according to claim 1.

3. The circuit compares the bandwidth with the 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 2.

4. A communication method for a communication device, The duration information and physical layer protocol data unit (PPDU) are received, and the PPDU indicates the bandwidth information of one or more frequency channels. The PPDU transmits a frame on a frequency channel other than one or more frequency channels from which it 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 method.

5. Determine whether the received PPDU is from the corresponding Basic Service Set (BSS) or from an overlapping Basic Service Set (OBSS), If the PPDU is determined to be from an OBSS, or if the BSS to which the PPDU belongs is determined, the period indicated in the PPDU is set as duration information, and the bandwidth of one or more frequency channels from which the PPDU was received is set as bandwidth information. The frame is transmitted on a frequency channel not covered by the bandwidth of one or more frequency channels corresponding to the bandwidth information. The communication method according to claim 4.

6. The bandwidth is compared to the currently set value, and the value is updated only if the bandwidth of one or more channels is greater than the currently set value. The communication method according to claim 5.

Images