integrated circuit

Abstract

An integrated circuit of a communication device for controlling a communication process, the communication process comprising: receiving a PHY protocol data unit comprising a duration field, the duration field comprising duration information indicating a duration for which the communication device is prohibited from transmitting a high efficiency, HE, trigger-based TB PHY protocol data unit; issuing a PHY-CCA clear channel assessment primitive parameter indicating bandwidth information about a busy or idle state of each subchannel within an operating bandwidth; updating a network allocation vector, NAV, value based on the duration information when the indicated duration is greater than a current NAV value, and when it is determined that the communication device is not a target receiver of the received PHY protocol data unit; determining a busy / idle state of at least one subchannel comprising a resource unit, RU, in which an HE TB PHY protocol data unit is to be transmitted; and controlling transmission of the HE TB PHY protocol data unit based on the updated NAV value and the busy / idle state of the at least one subchannel, and controlling transmission of the HE TB PHY protocol data unit when the at least one subchannel does not include a primary subchannel, regardless of whether the primary subchannel is busy or idle.

Description

[0001] This application is a divisional application of Chinese Invention Patent Application No. 201780050997.3, filed on October 25, 2017, entitled "Communication Apparatus and Communication Method", with Applicant Panasonic Intellectual Property Management Co., Ltd. (USA). TECHNICAL FIELD

[0002] The present disclosure generally relates to communication apparatus and communication methods, exploiting novel multi-channel virtual carrier sense, to enable more efficient use of the wireless medium when more than one wireless network are physically co-located. BACKGROUND

[0003] The IEEE (Institute of Electrical and Electronics Engineers) 802.11 Working Group is currently in the process of standardizing next generation WLAN (Wireless Local Area Network) technology under the 802.11ax Task Group. The main goal of the Task Group is to improve the spectral efficiency to enhance the system throughput per area in high density scenarios of Access Points (APs) and / or Terminal Stations (non-AP STAs or simply STAs in the rest of the document). Devices based on the IEEE 802.11ax specification are commonly referred to as High Efficiency (HE) devices. Among the various technologies proposed, Orthogonal Frequency Division Multiple Access (OFDMA) and Uplink Multi-User transmission are two key technologies adopted by the IEEE 802.11ax Task Group to achieve the throughput improvement goal. An 802.11 WLAN with an AP and at least one STA that has negotiated WLAN membership with the AP (referred to as the association process) is referred to as a Basic Service Set (BSS).

[0004] Figure 1 An example of two 802.11ax BSSs 100 and 145 is illustrated; each BSS includes a HE AP and several HE STAs that are respectively associated with the HE AP. A BSS operating on the same channel as the channel of a BSS of a STA and partially or totally within the radio coverage of the STA is referred to as an Overlapping Basic Service Set (OBSS). In Figure 1 In the example of Fig. 1, it is assumed that STA2 120 is associated with AP1 101, and BSS 145 is considered as an OBSS for STA2 120.

[0005] The medium access control (MAC) protocol of 802.11 devices, including 802.11ax devices, uses a contention-based carrier sense multiple access and collision avoidance (CSMA / CA) protocol to share the wireless medium. Collision avoidance is achieved by using a random backoff, while CSMA involves the use of physical and virtual carrier sense (CS) mechanisms. Physical CS mechanisms are provided by the physical layer (PHY) and involve the actual sensing of the wireless medium (preamble detection (PD) or energy detection (ED) or both). Virtual CS mechanisms are provided by the MAC layer and make use of the network allocation vector (NAV).

[0006] The NAV keeps a prediction of the future traffic on the medium based on the duration information announced in most IEEE 802.11 frames. This duration can be contained in the MAC header and / or also obtained from the transmit opportunity (TXOP) duration in the PHY header if present. The TXOP duration indicates the time interval during which a particular STA has the right to initiate a sequence of frames exchange over the wireless medium. When the physical or virtual CS indicates that the medium is busy, no device is allowed to transmit any signal except for certain specific frames such as acknowledgement (Ack) frames or block Ack frames, etc. To improve the efficiency of the medium access mechanism in the presence of OBSS, 802.11ax has approved the use of two NAVs: one called intra-BSS NAV and the second called basic NAV. The intra-BSS NAV is used to store the NAV value from PHY protocol data units (PPDUs) identified as intra-BSS (i.e. associated with the BSS of the STA) if applicable. On the other hand, the basic NAV is used to store another NAV value from inter-BSS PPDUs (i.e. OBSS PPDUs) or from PPDUs that cannot be identified as intra-BSS or inter-BSS if applicable.

[0007] Bibliographic List

[0008] Non Patent Literature

[0009] [NPL 1] IEEE 802.11-15 / 0132r17, Specification Framework for TGax, May 2015

[0010] [NPL 2] IEEE Std 802.11-2012

[0011] [NPL 3] IEEE 802.11-16 / 0024r1, Proposed TGax draft specification

[0012] [NPL 4] IEEE 802.11-16 / 0054r1, UL MU CCA Response SUMMARY

[0013] When the basic NAV of a STA is set to a non-zero value due to OBSS transmissions, the uplink multi-user channel sensing (UL MU CS) rule prohibits the STA from transmitting HE trigger based PPDU on the RUs allocated by the trigger frame due to the virtual CS indicating busy, even when the energy detection on the 20MHz channel containing the allocated RUs indicates the channel is idle. This results in a loss of transmission opportunity for the STA, thereby reducing the efficiency of uplink multi-user transmissions in the presence of OBSS traffic.

[0014] In an aspect of the disclosure, an integrated circuit of a communication apparatus for controlling a communication procedure is provided, the communication procedure comprising: receiving a PHY protocol data unit comprising a duration field, the duration field comprising duration information indicating a duration for which the communication apparatus is prohibited from transmitting a high efficiency HE trigger TB based PHY protocol data unit; issuing a PHY-CCA clear channel assessment primitive parameter indicating bandwidth information about a busy or idle state of each subchannel within an operating bandwidth; updating a network allocation vector NAV value based on the duration information when the indicated duration is greater than the current NAV value, and when it is determined that the communication apparatus is not a target receiver of the received PHY protocol data unit; determining a busy / idle state of at least one subchannel comprising a resource unit RU in which the HE TB PHY protocol data unit is to be transmitted; and controlling transmission of the HE TB PHY protocol data unit based on the updated NAV value and the busy / idle state of the at least one subchannel, and controlling transmission of the HE TB PHY protocol data unit when the at least one subchannel does not comprise a primary subchannel, regardless of whether the primary subchannel is busy or idle, when the at least one subchannel is considered idle.

[0015] One non-limiting and exemplary embodiment of the disclosure provides a communication apparatus and a communication method that can facilitate improving the efficiency of uplink multi-user transmissions in the presence of OBSS traffic.

[0016] In one general aspect, the technology disclosed herein features 1. A communication apparatus comprising: a receiving unit that receives a PHY layer data unit including a duration field, the duration field including duration information indicating a duration of prohibition of the communication apparatus from transmitting a high efficiency (HE) trigger-based (TB) PHY layer data unit; and a physical (PHY) layer circuit that issues a PHY-CCA (clear channel assessment) primitive parameter indicating bandwidth information about busy or idle status of each subchannel within an operating bandwidth; and a medium access control (MAC) circuit that updates a network allocation vector (NAV) value based on the duration information when the indicated duration is greater than a current NAV value and when it is determined that the communication apparatus is not a target receiver of the received PHY layer data unit; and determines a busy / idle status of at least one subchannel including a resource unit (RU) of the HE TB PHY layer data unit to be transmitted based on the bandwidth information; wherein the MAC circuit controls transmission of the HE TB PHY layer data unit based on the updated NAV value and the busy / idle status of the at least one subchannel.

[0017] These general and specific aspects can be implemented using a device, a system, a method, and a computer program, and any combination of a device, a system, a method, and a computer program.

[0018] The communication apparatus and the communication method described in this disclosure can help improve the efficiency of uplink multi-user transmission in the presence of OBSS traffic.

[0019] Other benefits and advantages of the disclosed embodiments will become apparent from the description and drawings. Benefits and / or advantages can be had from one or more of the embodiments and features without necessarily achieving all of them in the same application. Accordingly, the written description and drawings hereto enable a person of ordinary skill in the art to make and use the embodiments described herein. BRIEF DESCRIPTION OF DRAWINGS

[0020] Figure 1 is a diagram of an overlapping wireless network to which embodiments of the disclosure can be applied.

[0021] Figure 2 is a timing diagram of an example frame exchange sequence highlighting the NAV setup procedure.

[0022] Figure 3A is a timing diagram of another example frame exchange sequence illustrating how to update the two NAVs introduced in 802.11ax.

[0023] Figure 3B is a diagram showing the naming convention of 20 MHz channels in a wideband channel.

[0024] Figure 4is a diagram showing an example uplink multi-user transmission of UL MU CS rules in 802.11ax.

[0025] Figure 5 is a diagram showing the technical problem addressed in the present disclosure.

[0026] Figure 6 is a diagram showing how to update the various parameters related to the UL MU CS mechanism for Figure 4 is a table depicting the frame sequence update of various parameters related to the UL MU CS mechanism.

[0027] Figure 7A is an example of a frame exchange sequence showing the multi-channel virtual carrier sense (CS) introduced in the first embodiment.

[0028] Figure 7B is a table showing the encoding scheme of the BW field of the NAV according to the first embodiment.

[0029] Figure 8A is a flowchart showing the rules of the multi-channel virtual CS according to the first embodiment.

[0030] Figure 8B is a table showing how to update the various parameters related to the UL MU CS mechanism based on the modified multi-channel virtual CS rules according to the first embodiment.

[0031] Figure 9 is a diagram depicting three overlapping wireless networks.

[0032] Figure 10A is an example of a frame exchange sequence showing the basic NAV update rules in the presence of multiple OBSSs according to the first embodiment.

[0033] Figure 10B is a flowchart showing the basic NAV update rules in the presence of multiple OBSSs according to the first embodiment.

[0034] Figure 11A is an example of a frame exchange sequence showing alternative rules for basic NAV update in the presence of multiple OBSSs according to the first embodiment.

[0035] Figure 11B is a flowchart showing alternative rules for basic NAV update in the presence of multiple OBSSs according to the first embodiment.

[0036] Figure 11C is another flowchart showing alternative rules for basic NAV update in the presence of multiple OBSSs according to the first embodiment.

[0037] Figure 12is a table showing additional members proposed for the PHY-CCA.indication primitive according to the first embodiment.

[0038] Figure 13A is an example UL MU transmission showing the second embodiment of the present disclosure.

[0039] Figure 13B is a diagram of a bitmap used to record channel status according to the second embodiment of the present disclosure.

[0040] Figure 14 is an example of a frame exchange sequence showing the multi-channel virtual carrier sense (CS) introduced in the second embodiment.

[0041] Figure 15 is a simplified block diagram of an example STA implementing the disclosed multi-channel virtual carrier sense.

[0042] Figure 16 is a detailed block diagram of an example STA implementing the disclosed multi-channel virtual carrier sense.

[0043] Figure 17 is an example of a frame exchange sequence showing the multi-channel virtual carrier sense (CS) according to the third embodiment.

[0044] Figure 18 is 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.

[0045] Figure 19 is a flowchart showing the rules of the multi-channel UL MU CS mechanism according to the third embodiment.

[0046] Figure 20 is a table listing how a STA obtains channel bandwidth information from a received PPDU.

[0047] Figure 21 is a table showing additional members proposed for the PHY-CCA.indication primitive according to the third embodiment.

[0048] Figure 22 is the format of the NAV maintained by a STA and the encoding of the TX_Allowed field according to the fourth embodiment.

[0049] Figure 23 is an example of a frame exchange sequence showing the multi-channel virtual carrier sense (CS) according to the fourth embodiment.

[0050] Figure 24 is another diagram showing the technical problem addressed in the present disclosure to better highlight the improvements made by the fourth embodiment.

[0051] Figure 25 is a table illustrating how various parameters related to UL MU CS mechanism are updated based on modified multi-channel virtual CS rules according to the fourth embodiment.

[0052] Figure 26 is a flow chart illustrating rules for multi-channel UL MU CS mechanism according to the fourth embodiment.

[0053] Figure 27 is an example of frame exchange sequence illustrating basic NAV update rules in presence of multiple OBSSs according to the fourth embodiment.

[0054] Figure 28 is a flow chart illustrating basic NAV update rules in presence of multiple OBSSs according to the fourth embodiment. DETAILED DESCRIPTION

[0055] The present disclosure can be better understood by way of the following figures and examples. The examples described herein are merely exemplary in nature and are intended to describe some possible applications and uses of the present disclosure and should not be construed as limiting the present disclosure with respect to alternative examples not explicitly described herein.

[0056] As previously mentioned, multi-user transmission using OFDMA in both downlink and uplink directions is a key technique adopted by IEEE 802.1 lax Task Group to achieve the throughput improvement goal. In the downlink direction, multi-user transmission is relatively simple since the AP will transmit all multi-user frames. A downlink (DL) multi-user PPDU consists of a wide channel PHY header that carries information about the narrowband channels (called resource units or RUs) that carry each individual PHY service data unit (PSDU). Transmission in the uplink direction is more complex than in the downlink direction since time synchronization of transmissions from multiple STAs is required and also must ensure that transmissions from different STAs do not interfere with each other, i.e. each STA must be assigned a unique RU. This is achieved in IEEE 802.1 lax by a special control frame called a trigger frame that is sent by the AP.

[0057] The trigger frame contains information to be used for the UL transmission, such as resource unit (RU) allocation, uplink (UL) PPDU length, MCS, etc. In addition, the trigger frame also contains a "CS requirement subfield" that informs the STAs whether carrier sensing is required before the UL MU transmission. Upon receiving the trigger frame, after a short interframe space (SIFS) period from the end of the trigger frame, the STAs that are allocated RUs in the trigger frame can send their respective UL frames in an UL multi-user (MU) PPDU. If the value of the "CS requirement subfield" in the trigger frame is 1, the STAs are required to follow the uplink multi-user channel sensing (UL MU CS) procedure, which dictates that the STAs need to consider virtual CS and also perform energy detection on all 20 MHz channels that have allocated RUs to the STAs in order to participate in the UL MU transmission. The STAs are only allowed to send the HE trigger-based PPDU if the virtual CS is idle and all 20 MHz channels that contain the allocated RUs in the trigger frame are also considered to be idle. If the 20 MHz channels are not all idle, the STAs are not allowed to transmit on the allocated RUs.

[0058] Reference Figure 1 depicts two overlapping BSSs (OBSSs). The first BSS, BSS1 100, includes an AP, AP1 101, and four STAs associated with AP1: STA1 110, STA2 120, STA3 130, and STA4 140. The second BSS, BSS2 145, includes an AP, AP2 102, and two STAs associated with AP2: STA5 150 and STA6 160. The circles around AP1 101 and AP2 102 also represent the radio coverage areas of AP1 and AP2, respectively. As can be seen from Figure 1 , STA2 120 is located at the edge of the radio coverage range of AP1 and happens to also be within the radio coverage range of AP2. As such, for STA2 120, BSS2 145 is considered to be an OBSS. The identity of the BSS to which a received frame belongs can be determined by the receiver 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.

[0059] Figure 2An example frame exchange sequence 200 highlighting the 802.11 NAV setting procedure is shown. AP1 101 intends to send a data frame to STA1 110 and to protect the transmission, AP1 first sends a request to send (RTS) frame to STA1, which responds with a clear to send (CTS) frame to be sent after a short interframe space (SIFS) period from the end of the RTS frame. The duration field in the RTS frame is set to a value indicating the time period between the end of the RTS frame and the end of the Ack frame sent in response to the data frame. All STAs other than the intended recipient STA1 that receive the RTS frame will update their NAVs to the value of the duration field in the RTS frame if their existing NAV value is smaller. Similarly, all STAs other than the intended recipient AP1 that receive the CTS frame will update their NAVs to the value of the duration field in the CTS frame if their existing NAV value is smaller. In this way, all STAs within the radio coverage of AP1 and STA1 will set their NAVs. After successfully receiving the CTS frame, AP1 sends the data frame after a SIFS period from the end of the STS frame, and STA1 responds to the CTS frame with an Ack frame. Since STA2 120 and all other STAs that receive the RTS / CTS frames have their NAVs set, they are not allowed to transmit during this duration, thus ensuring that AP1's data frame transmission is protected.

[0060] Figure 3A An example frame exchange sequence 200 highlighting the 802.11 NAV setting procedure is shown. AP1 101 intends to send a data frame to STA1 110 and to protect the transmission, AP1 first sends a request to send (RTS) frame to STA1, which responds with a clear to send (CTS) frame to be sent after a short interframe space (SIFS) period from the end of the RTS frame. The duration field in the RTS frame is set to a value indicating the time period between the end of the RTS frame and the end of the Ack frame sent in response to the data frame. All STAs other than the intended recipient STA1 that receive the RTS frame will update their NAVs to the value of the duration field in the RTS frame if their existing NAV value is smaller. Similarly, all STAs other than the intended recipient AP1 that receive the CTS frame will update their NAVs to the value of the duration field in the CTS frame if their existing NAV value is smaller. In this way, all STAs within the radio coverage of AP1 and STA1 will set their NAVs. After successfully receiving the CTS frame, AP1 sends the data frame after a SIFS period from the end of the STS frame, and STA1 responds to the CTS frame with an Ack frame. Since STA2 120 and all other STAs that receive the RTS / CTS frames have their NAVs set, they are not allowed to transmit during this duration, thus ensuring that AP1's data frame transmission is protected. Figure 1An example frame exchange sequence 300 within two BSSs 100 and 145 in the 40MHz, 80MHz, or 80+80MHz or 160MHz channel, and highlights the procedure for updating the two NAVs introduced in 802.11ax (intra-BSS NAV and basic NAV). Keeping both NAVs will enable more efficient spatial reuse of frequency resources under certain conditions. This example depicts two ongoing transmission sequences: first, TXOP1 310 in BSS1 100, between AP1 101 and STA1 110; and second, TXOP2 340 in BSS2 145, between AP2 102 and STA5 150. Upon receiving DL PPDU 312, STA2 120 determines that PPDU 312 is an intra-BSS PPDU by checking the BSS color field or the BSSID field or both, and since STA2 is not the recipient of PPDU 312, STA2 sets its intra-BSS NAV, NAV1 320, to a value indicating the time period between the end of DL PPDU 312 and the end of TXOP1. Similarly, upon receiving DL PPDU 342, STA2 determines that PPDU 342 is an inter-BSS PPDU by checking the BSS color field or the BSSID field or both, and STA2 sets its inter-BSS NAV, NAV2 330, to a value indicating the time period between the end of DL PPDU 342 and the end of TXOP2.

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

[0062] Further, in an infrastructure BSS, all beacon frames are transmitted on the primary 20 MHz channel. Any 20 MHz channel other than the primary 20 MHz channel is referred to as a non-primary channel. The 20 MHz channel 355 adjacent to the primary 20 MHz channel that together forms the 40 MHz BSS (or the primary 40 MHz of a wider BSS) is referred to as the secondary 20 MHz or simply the secondary channel. In an 80 MHz or wider BSS, the primary 20 MHz channel 350 and the secondary 20 MHz channel 355 together form the primary 40 MHz channel. In an 80 MHz or wider BSS, the 40 MHz channel (composed of two 20 MHz channels 360 and 365) adjacent to the primary 40 MHz channel that together forms the 80 MHz BSS or the primary 80 MHz of a wider BSS is referred to as the secondary 40 MHz channel. In an 80+80 MHz or 160 MHz BSS, the primary 40 MHz channel and the secondary 40 MHz channel together form the primary 80 MHz channel. In an 80+80 MHz or 160 MHz BSS, the 80 MHz channel that does not include the primary 20 MHz channel 350 (composed of four 20 MHz channels 370, 375, 380, and 385) and that together with the primary 80 MHz channel forms the 80+80 MHz or 160 MHz channel is referred to as the secondary 80 MHz channel. In a 160 MHz channel, the primary 80 MHz and the secondary 80 MHz channels are adjacent to each other, while in an 80+80 MHz channel, the primary 80 MHz and the secondary 80 MHz channels need not be adjacent to each other and can be located in different parts of the operating band.

[0063] Reference Figure 4 is shown to illustrate an example UL MU transmission sequence 400 to elucidate the UL MU CS procedure in 802.1 lax. The uplink multi-user (UL MU) transmission is initiated by the AP by sending a special control frame called the trigger frame 410. The trigger frame 410 contains information for the UL transmission by the STAs, such as resource unit (RU) allocation, PPDU length, MCS, etc. Upon receiving the trigger frame 410, the STAs that are allocated RUs in the trigger frame can send their respective UL frames in an UL multi-user PPDU after a period of SIFS from the end of the trigger frame without contending for the wireless medium.

[0064] The UL MU CS procedure in 802.11ax indicates that in order to participate in an UL MU transmission, a STA that is allocated a RU in a trigger frame with the CS requirement field set to 1 needs to consider the virtual CS and also perform an energy detection based clear channel assessment (ED based CCA) on all 20MHz channels that have been allocated to the STA. The STA is allowed to transmit its UL PPDU (HE triggered PPDU) only if the virtual CS is idle and the ED based CCA also considers all 20MHz channels containing the allocated RU to be idle. If the 20MHz channels are not all idle, the STA is not allowed to transmit on the allocated RU. The virtual CS is considered to be idle if both the BSS-internal NAV and the basic NAV have a counter value of zero. In this example, Figure 1 BSS1 100 in operates on an 80MHz channel and let CH1, CH2, CH3 and CH4 denote the primary, secondary, tertiary and quaternary 20MHz channels. In 802.11 terminology, CH1 is referred to as the primary 20MHz or simply the primary channel, CH2 is referred to as the secondary 20MHz or simply the secondary channel, and CH3 and CH4 together form the secondary 40MHz channel.

[0065] At the time when the STA receives the trigger frame 410 from AP1 101, there is no ongoing transmission within the radio coverage area of STA1, STA2, STA3 and STA4 on the primary 20MHz channel CH1 and both the BSS-internal NAV and the basic NAV of all four STAs are set to zero. However, as shown in 460, there is an ongoing transmission on CH3 within the radio coverage area of STA2. AP1 101 initiates the UL MU transmission sequence by sending the trigger frame 410 that allocates one 106-tone RU to STA1 110 and STA4 140 on CH1, one 242-tone RU to STA3 130 on CH2 and a 484-tone RU covering CH3 and CH4 to STA2 120. Since both the ED based CCA and the virtual CS return idle, STA1, STA3 and STA4 transmit their respective UL PPDUs 420, 440 and 430. However, in the case of STA2, although the virtual CS returns idle, the ED based CCA will return busy on CH3. Since the 20MHz channels containing the RU allocated to STA2 are not all idle, STA2 is prohibited from transmitting its UL PPDU 450 according to the UL MU CS rules.

[0066] Figure 5An example UL MU transmission sequence 400 under slightly different channel conditions is shown. At the time when the STA receives the trigger frame 410 from the AP1 101, there is no ongoing transmission within the radio coverage area of STA1, STA3, and STA4 on the primary 20MHz channel, and both the intra-BSS NAV and the basic NAV of the STAs are set to zero. However, as shown in the transmission sequence 500, there is an ongoing OBSS transmission in the BSS2 145 within the radio coverage area of STA2 on the primary channel CH1 and the secondary channel CH2. The AP2 102 initiates the UL MU transmission in BSS2 by sending the trigger frame 510. The trigger frame 510 is used to allocate RUs to STA5 150 and STA6 160. SIFS after the end of the trigger frame 510, STA5 and STA6 send their respective UL PPDUs on the corresponding allocated RUs. Upon receiving the DL PPDU carrying the trigger frame 510, STA2 determines that it is an OBSS PPDU and sets its basic NAV to a non-zero value.

[0067] Figure 6 The table 600 in the above lists the various parameters related to the UL MU CS mechanism of STA2 during the UL MU transmission sequence shown in Figure 5 The various parameters related to the UL MU CS mechanism of STA2 during the UL MU transmission sequence shown in FIG. 5 are listed in the table 600 in FIG. 6. Since the transmission on the primary channel CH1 belongs to an OBSS, the basic NAV of STA2 is set to a non-zero value, and the virtual CS indicates busy even if the intra-BSS NAV is zero. Similarly, the ED-based CCA returns busy on CH1 and CH2, and returns idle on CH3 and CH4. According to the UL MU CS rules, even though there is no ongoing transmission on the channels containing the RUs for STA2, CH3, and CH4, the UL MU CS considers the medium busy on all four 20MHz because the virtual CS indicates busy, and therefore does not allow the transmission of the UL PPDU 450 of STA2. This can be considered as a case of basic NAV over-protection. That is, even if STA2 is allowed to transmit its UL PPDU 450 on CH3 and CH4, the transmission would not cause any interference to the OBSS transmission, and would result in higher channel usage efficiency.

[0068] The above drawback is caused by the fact that the NAV (either the baseline NAV or the intra-BSS NAV or the basic NAV) is based only on the activity on the primary 20MHz channel, and does not take into account / provide information about the status of the non-primary channels. As long as the primary 20MHz is busy due to the reception of a valid PPDU, the NAV is set and the status of the rest of the secondary channels is not recorded. Since 802.1 lax introduced OFDMA-based narrowband transmissions, further gains in terms of channel reuse efficiency can be obtained if such over-protection can be avoided.

[0069] Based on the above knowledge, the inventors of this application have arrived at the present disclosure. Disclosed are a communication method and apparatus 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, and the NAV records not only the duration that a primary channel forming part of a wideband channel is busy, but also which other non-primary channels of the wideband channel are busy. By referring to this information about busy channels, STAs can easily infer which channels are idle and can be used for concurrent transmission without interfering with the busy channels.

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

[0071] <First embodiment>

[0072] As mentioned earlier, currently, NAV (baseline NAV or intra-BSS NAV or basic NAV) is based only on activity on the primary 20 MHz channel and does not consider / provide information about the status of non-primary channels. As long as the primary 20 MHz channel is busy due to receiving a valid PPDU, NAV is set and the status of the remaining non-primary channels is not recorded. In order to overcome this limitation of the current NAV mechanism, the first embodiment adds the frequency dimension to NAV so that NAV records not only the duration that the primary channel is busy, but also the busy non-primary channels. To this end, a field called BW (bandwidth) is added to NAV to record the bandwidth information of the PPDU or the frame in which NAV is set. Since the bandwidth of the PPDU in which NAV is set always includes the primary 20 MHz channel, the BW field indicates which non-primary channel is busy. With this information of the busy channels, the STA can easily infer which channels are idle and can be used for concurrent transmission without causing interference to the busy channels.

[0073] refer to Figure 7A , shows a series of example frame exchange sequences to provide a conceptual visual illustration of the frequency dimension of NAV in an 80 MHz BSS. Figure 7A The upper portion of the diagram depicts three transmission sequences of different bandwidths: 80 MHz TXOP1 712, 40 MHz TXOP2 722, and 20 MHz TXOP3 732. Each transmission sequence includes a PPDU exchange between the AP and one or more STAs belonging to the same BSS as the AP. As an example, the first PPDU in the transmission sequence can be a trigger frame that allocates a RU to the selected STA for ULMU transmission, followed by a HE-triggered PPDU from the STA, and ends with a DL PPDU carrying an acknowledgment frame from the AP. In this example, CH1, CH2, CH3, and CH4 represent primary, secondary, tertiary, and quaternary 20 MHz channels, respectively. Figure 7AThe lower half of Figure 7 provides a visual representation of the two-dimensional NAV maintained by a third-party STA as proposed by the present disclosure. The time points relevant to this example are denoted by tO, tl, t2, t3, t4, and t5.

[0074] Any STA that is within radio coverage of the ongoing transmission and that is neither the sender nor the receiver of the transmission is considered a third-party STA of the transmission. Upon receiving the first PPDU 710 of TXOP1 712, the third-party STA determines that it is not the receiver of PPDU 710, for example, by reading the receiver address in the MAC header of the frame carried by the PPDU, or by reading the AID 12 subfield of the user info field of the trigger frame carried in PPDU 710, etc.

[0075] Once the STA has determined that it is not the receiver of PPDU 710, it sets the NAV duration according to existing NAV rules to the duration from time tO to time tl, prohibiting the STA from transmitting until time tl, which is the end of TXOP1 712. In addition to recording the NAV duration, according to the first embodiment, the STA also records the BW field of the NAV as 80 MHz, which is the bandwidth of the received PPDU 710. The two-dimensional NAV is represented by block 714, indicating the duration and frequency range during which the STA is prohibited from transmitting. At time tl, when the NAV duration counts down to zero, the BW field is also reset to zero.

[0076] Similarly, upon receiving PPDU 720, the STA sets the NAV duration to the duration 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 PPDU 720. This is shown as block 724. If the channel sensing rules are also modified accordingly, then under certain conditions, the third-party STA can be allowed to transmit on the unoccupied channels CH3 and CH4 during the NAV duration from t2 to t3 without causing interference to the ongoing transmission 722, thereby facilitating more efficient reuse of the unoccupied secondary channels.

[0077] At time t3, when the NAV duration counts down to zero, the BW field is also reset to zero. In the same way, upon receiving PPDU 730, the STA sets the NAV duration to the duration 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 PPDU 730. This is shown as block 734. In this case, the third party STA can be allowed to transmit on the unoccupied channels CH2, CH3, and CH4 during the NAV duration from t4 to t5 without causing interference to the ongoing transmission 732. At time t5, when the NAV duration counts down to zero, the BW field is also reset to zero.

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

[0079] The concept of adding a frequency dimension to the NAV can be easily extended to Figure 3A two NAVs described in the Background section. Either or both of the NAVs can be extended to record the bandwidth of the ongoing transmissions in their respective BSS. Referring back to Figure 5 , the overly protective NAV that prohibits STA2 from transmitting UL PPDU 450 can be overcome by applying the concept of recording the bandwidth of the ongoing OBSS transmissions as the BW field of the basic NAV, and at the same time making some modifications to the virtual CS rules and the UL MU CS mechanism.

[0080] As mentioned earlier, in the example shown in Figure 5 , the basic NAV of STA2 is set to a non-zero value when it receives trigger frame 410 from AP1 101, which results in the virtual CS being busy for STA2. According to the current UL MU CS rules, even though there is no ongoing transmission on CH3 and CH4, the UL MU CS mechanism considers the medium on all four channels busy due to the virtual CS indicating busy, and therefore does not allow STA2’s UL PPDU 450 to be transmitted, even though two of the channels containing STA2’s RU are not busy. The current virtual CS rules indicate the entire wideband channel busy as long as one of the NAVs is busy, regardless of the actual situation of the non-primary channels.

[0081] Figure 8A The flowchart 800 is depicted to illustrate how the virtual CS rules can be indicated per 20MHz channel by adding a bandwidth field to the basic NAV. Starting with the primary 20MHz channel, for each of the 20MHz channels of the wideband channel that receives the trigger frame, at step 810, the process starts when the STA receives a trigger frame with the CS requirement field set to 1 and allocates an RU to the STA. Since the CS requirement field is set to 1 in the trigger frame, the STA is required to perform UL MU CS before transmitting the HE trigger-based PPDU on the allocated RU. At step 820, if the intra-BSS NAV is not zero, the process moves to step 830 where the virtual CS indicates the 20MHz channel as busy and the process ends and moves to the next 20MHz channel (if any). However, if the intra-BSS NAV is zero at step 820, the process moves to step 840.

[0082] At step 840, if the basic NAV duration is zero, the process proceeds to step 870 where the virtual CS indicates the 20MHz channel as idle and the process ends and moves to the next 20MHz channel (if any). However, if the basic NAV is not zero at step 840, the process moves to step 850. At step 850, if the 20MHz channel is indicated as one of the busy channels by the BW field of the basic NAV, the process moves to step 860 where the virtual CS indicates the 20MHz channel as busy and the process ends and moves to the next 20MHz channel (if any). However, at step 850, if the 20MHz channel is not indicated as one of the busy channels by the BW field of the basic NAV, the process moves to step 870 where the virtual CS indicates the 20MHz channel as idle and the process ends and moves to the next 20MHz channel (if any). Since the modified virtual CS rules allow reporting the virtual CS for each of the individual 20MHz channels, the UL MU CS mechanism is also modified such that the busy / idle status is reported for each individual 20MHz channel. If the energy detection (ED) or the virtual CS returns busy on a particular 20MHz channel, the 20MHz channel is considered busy.

[0083] However, the UL MU transmission rules remain the same, i.e., the STA is allowed to transmit the HE trigger-based PPDU on the RU allocated by the trigger frame with the CS requirement field set to 1 only when all the 20MHz channels containing the allocated RU are idle. If the 20MHz channels containing the allocated RU are not all idle, the STA is not allowed to transmit anything on the allocated RU.

[0084] Figure 8B Table 880 in Figure 5 Various parameters related to the modified UL MU CS mechanism for STA2 during the UL MU transmission sequence shown in Figure 6 Table 880 includes one additional column 882 indicating the channel status based on the basic NAV based BW field. Since the transmission on the primary channel belongs to an OBSS, the intra-BSS NAV for STA2 is zero, while the duration field of the basic NAV is set to the indicated duration of the OBSS transmission. Since the OBSS transmission only occurs on CH1 and CH2, as Figure 5 The BW field of the basic NAV is set to 1 (40MHz) as indicated by block 500 in

[0085] Similarly, CH3 and CH4 are recorded as idle, indicated by entries 884 and 886, respectively. According to the modified virtual CS rules explained in Figure 8A According to the modified virtual CS rules explained in

[0086] Figure 9 is built on top of the overlapping wireless network depicted in Figure 1 In addition to BSS1 100 and BSS2 145, another BSS, BSS3 900, is shown. BSS3 900 includes AP3 901 and two STAs: STA7 910 and STA8 920. Since STA2 120 is also within the radio coverage of AP3 901, BSS3 900 is also considered an OBSS for STA2. Figure 9 The BSS layout in

[0087] Option 1 (Static Update): The BW field is always set to the maximum bandwidth of the NAV setting PPDU of the ongoing third-party transmission. A third-party transmission refers to any transmission within the reception range of the STA, where the STA is neither the sender nor the receiver of the transmission. A NAV setting PPDU refers to a PPDU that carries at least one frame and can cause a change in the STA's NAV counter (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, if the bandwidth of the new PPDU is wider than the existing BW field, the BW field is updated even if the new PPDU does not cause the NAV duration to be updated.

[0088] Option 2 (Dynamic Update): The BW field is dynamically adjusted to reflect the actual bandwidth of the NAV-setting PPDU for ongoing third-party transmissions. This option is more complex than Option 1 and requires temporarily recording the bandwidth and duration of each received third-party transmission. While the NAV duration is always set to the maximum 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 portion of the ongoing transmission.

[0089] refer to Figure 10A , shows a series of example frame exchange sequences to provide Figure 9 A visual illustration of the above Option 1 (static update) rule for the Bandwidth field of the Basic NAV of STA2 in the BSS layout shown in , assuming that all three BSSs, BSS1 100, BSS2 145, and BSS3 900, are 80 MHz BSSs. Figure 10A The top portion of FIG depicts two transmission sequences of different bandwidths in BSS2 145: 80 MHz TXOP1 1012 and 40 MHz TXOP2 1022. Similarly, in Figure 10A The bottom portion of FIG. 1 depicts two transmission sequences of different bandwidths in BSS3 900 : 20 MHz TXOP3 1032 and 80 MHz TXOP4 1034 .

[0090] Figure 10AThe middle of Figure 10 depicts a visual representation of a two-dimensional basic NAV maintained by STA2 120 proposed by the present disclosure. The time points relevant to this example are denoted by tO, tl, t2, t3, t4, t5, t6, and t7. Upon receiving the first PPDU 1010 of TXOP1 1012, STA2 determines that PPDU 1010 is an OBSS PPDU from BSS2 based on the BSS color field in the PHY header or the BSSID field in the MAC header, and STA2 is not one of the receivers. According to the existing NAV rule for updating the NAV duration, STA2 sets the NAV duration from time tO to time t2, and the NAV BW field to 80MHz, the bandwidth of the received PPDU 1010, prohibiting STA2 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 represents the time duration and frequency range that STA2 is prohibited from transmitting at time tO.

[0091] Upon receiving the first PPDU 1030 of TXOP3 1032, STA2 determines that 1030 is an OBSS PPDU from BSS3 and it is not one of the receivers of PPDU 1030. Since the duration indicated in 1030 is longer than the existing NAV duration, according to the NAV rule for updating the NAV duration, STA2 updates the NAV duration until time t3, prohibiting STA2 from transmitting until time t3, which is the end of TXOP3 1032. From time t2 to time t3, the actual ongoing OBSS transmission is only on BSS3, but the NAV BW field indicates 80MHz. This can be considered as over-protection zone 1016, whereby STA2 is restricted from transmitting on any of the channels CH2, CH3, and CH4 that fall within zone 1016, even though all three channels are idle for STA2 from time t2 to time t3. At time t3, when the basic NAV duration counts down to zero, the NAV BW field is also reset to zero.

[0092] Similarly, upon receiving the first PPDU 1020 of TXOP2 1022, STA2 determines that 1020 is an OBSS PPDU from BSS2 and it is not one of the receivers of PPDU 1020. According to the existing NAV rule 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, prohibiting STA2 from transmitting on CH1 and CH2 until time t7, which is the end of TXOP2 1022.

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

[0094] From time t6 to time t7, the actual ongoing OBSS transmission is only on BSS2, but the NAV BW field indicates 80MHz. This can be considered as over-protection zone 1028, whereby STA2 is restricted from transmitting on channels CH3 and CH4 that fall within zone 1028, even though both channels are idle for STA2 from time t6 to time t7. However, with the OBSS transmission on a narrower bandwidth channel, it is possible to more efficiently reuse the secondary channels compared to the existing UL MU CS mechanism, even with Option 1. At time t7, when the basic NAV duration counts down to zero, the NAV BW field is also reset to zero.

[0095] The update rule for the NAV according to Option 1 is summarized by flowchart 1040 in Figure 10B . At step 1042, the process starts when a NAV set PPDU is received. At step 1044, if the PPDU causes the duration field of the basic NAV to increase, the process moves to step 1046. At step 1046, the basic NAV duration is updated according to the relevant duration information in the PPDU (e.g., based on the TXOP duration field in the PHY header or the duration field in the MAC header), and the process moves to step 1048. At step 1044, if the PPDU does not cause the duration field of the basic NAV to increase, the process moves to step 1048. At step 1048, if the received PPDU causes the BW field to increase, the process moves to step 1050, otherwise the process ends. At step 1050, the BW field of the basic NAV is updated to reflect the bandwidth of the received PPDU, and the process ends.

[0096] Referring to Figure 11A , the reuse Figure 10AThe same example transmission sequence shown in FIG. 10 is used to provide a visual illustration of the above Option 2 (dynamic update) rule for the bandwidth field of the basic NAV of STA2. Upon receiving the first PPDU 1010 of TXOP1 1012, STA2 determines 1010 is an OBSS PPDU from BSS2 based on the BSS color field in the PHY header or the BSSID field in the MAC header and it is not one of the recipients of PPDU 1010. According to the existing NAV rule for updating the NAV duration, STA2 sets the NAV duration from time to to time t2, and sets the NAV BW field to 80MHz, the bandwidth of the received PPDU 1010, prohibiting STA2 from transmitting on CH1, CH2, CH3, and CH4 until time t2, which is the end of TXOP1 1012.

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

[0098] As a result, the basic NAV does not restrict STA2 from transmitting on any of channels CH2, CH3, and CH4 from time t2 to time t3, since all three channels are idle to STA2. Similarly, upon receiving the first PPDU 1020 of TXOP2 1022, STA2 determines 1020 is an OBSS PPDU from BSS2 and it is not one of the recipients of PPDU 1020. According to the existing NAV rule for updating 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, prohibiting STA2 from transmitting on CH1 and CH2 until time t7, the end of TXOP2 1022. The two-dimensional NAV is represented by block 1024, which represents the duration and frequency range during which STA2 is prohibited from transmitting at time t4.

[0099] Upon receiving the first PPDU 1034 of TXOP4 1036, STA2 determines 1034 is an OBSS PPDU from BSS3 and it is not one of the recipients of PPDU 1034. Since the duration indicated in PPDU 1034 is shorter than the existing NAV duration, according to the NAV rule for updating NAV duration, STA2 does not update the NAV duration. However, since the bandwidth of PPDU 1034 is 80MHz and wider than the current NAV BW field, the BW field should be updated to 80MHz, as shown by 1122. However, from time t6 to time t7, the bandwidth of the ongoing OBSS transmission 1022 is only 40MHz, and thus before the NAV BW field is updated to 80MHz, the current NAV BW is saved as New_BW and the end time t6 of BSS3 transmission 1036 is recorded as BW_update_time, and a 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 of the ongoing third-party transmission 1022 1124. As a result, the basic NAV does not restrict STA2 from transmitting on any of channels CH3 and CH4 from time t6 to time t7, since both channels are idle to STA2.

[0100] The updating rule of the NAV according to Option 2 is represented by the flowchart 1140 in Figure 11B and the flowchart 1142 in Figure 11Cthe processing moves to step 1146, otherwise the processing moves to step 1162. At step 1146, if the bandwidth of the received PPDU is less than the Basic NAV BW field, the processing moves to step 1148, otherwise the processing moves to step 1154. At step 1148, if the variable BW_update_time is zero, the expiration time of the current Basic NAV is stored in the variable BW_update_time, otherwise if the variable BW_update_time is non-zero, the smaller of the two values, BW_update_time or the expiration time of the current Basic NAV, is stored in BW_update_time and the processing moves to step 1150. At step 1150, the larger of the two values, New_BW or the bandwidth of the received PPDU, is stored in the variable New_BW and the processing moves to step 1152.

[0101] At step 1152, a timer called BW_update_timer is set to expire at the BW_update_timer and the processing moves to step 1160. At step 1154, if the bandwidth of the received PPDU is greater than the Basic NAV BW field, the processing moves to step 1156, otherwise, the processing moves to step 1158. At step 1156, the Basic NAV BW field is updated to the bandwidth of the received PPDU and the processing moves to step 1158. At step 1158, since it is expected that the bandwidth of the Basic NAV will not change until the end of the Basic NAV duration, the BW_update_timer, if running, is stopped and both BW_update_time and New_BW are set to 0 and the processing moves to step 1160. At step 1160, the Basic NAV duration is updated according to the relevant duration information in the PPDU (e.g., based on the TXOP duration field in the PHY header or the duration field in the MAC header) and the processing 1140 ends.

[0102] At step 1162, if the bandwidth of the received PPDU is greater than the basic NAV BW field, then processing moves to step 1164, otherwise processing 1140 ends. At step 1164, if the NAV expiration time according to the received PPDU is less than the expiration time of the basic NAV, then processing moves to step 1168, otherwise processing moves to step 1170. At step 1168, the value of the basic NAV BW field is stored in the variable New_BW, and processing moves to step 1170. At step 1170, the NAV expiration time according to the received PPDU is stored in the variable BW_update_time, and processing moves to step 1172. At step 1172, the BW_update_timer is set to expire at the BW_update_timer expiration time, and processing moves to step 1174. At step 1174, the basic NAV BW field is updated to the bandwidth of the received PPDU, and processing 1140 ends.

[0103] The basic NAV BW adjustment processing is summarized by processing 1180. At step 1182, processing 1180 starts when the BW_update_timer expires. At step 1184, if the basic NAV duration is not zero, then processing moves to step 1186, otherwise processing moves to step 1190. At step 1186, if the value of New_BW is not zero, then processing moves to step 1188, otherwise, processing moves to step 1190. At step 1188, the BW field of the basic NAV is updated to New_BW, and processing 1180 ends. At step 1190, both BW_update_time and New_BW are set to zero and processing 1180 ends.

[0104] Reference Figure 12 Table 1200 lists the possible values and meanings of the channel-list parameter of the PHY-CCA.indication primitive used by the HE STA. The PHY layer of the HE-STA uses the PHY-CCA.indication (STATE, {channel-list}) primitive to indicate the status of the channels to the MAC layer. The PHY-CCA.indication primitive always includes the STATE parameter, but only contains the channel-list parameter when the STATE parameter is BUSY and the status of multiple channels is reported. The PHY-CCA.indication primitive indicates which channels are busy and which channels are idle within the BSS operating bandwidth. The first four values of the channel-list parameter and their meanings are the same as defined in the IEEE 802.11 specification, while the three values primary20, primary40, and primary80 listed in rows 1210, 1220, and 1230, respectively, have been added by the first embodiment of the present disclosure. ReferenceFigure 3B The value "primary" indicates that the primary 20 MHz channel 310 and all other non-primary channels are busy.

[0105] The value "secondary" indicates that the secondary 20 MHz channel 320 is busy while the primary 20 MHz channel 310 is idle. The value "secondary40" indicates that the secondary 40 MHz channels (330 and 340) are busy while the primary 20 MHz channel 310 and the secondary 20 MHz channel 320 are idle. The value "secondary80" indicates that the secondary 80 MHz channels (350, 360, 370, and 380) are busy while the primary 20 MHz channel 310, the secondary 20 MHz channel 320, and the two 20 MHz channels 330 and 340 that together form the secondary 40 MHz channel are idle. As mentioned previously, the value "primary" for the channel list parameter indicates that the primary 20 MHz channel and all other non-primary channels that form part of the BSS operating channel are busy. In a legacy 802.11 system, all transmissions in an infrastructure BSS include the primary 20 MHz channel, and no STA is allowed to transmit as long as the primary 20 MHz channel is busy.

[0106] Therefore, in a legacy 802.11 BSS, a busy primary 20 MHz channel is considered equivalent to all non-primary channels being busy as well. However, in the case of uplink OFDMA-based multi-user transmissions in an 802.11 ax BSS, if the AP allocates RUs to STAs on a non-primary channel, the STAs can be allowed to transmit their uplink PPDUs on channels that do not include the primary 20 MHz channel. As an example, refer to Figure 4 In the trigger frame 410, the AP allocates RUs to STA3 on the secondary channel CH2, and according to the 802.11 ax UL MU transmission rules, STA3 is allowed to transmit its UL PPDU 440 on the secondary channel CH2 if the UL MU CS considers CH2 to be idle. In order for the PHY layer of a STA to report the conditions of non-primary channels when the primary channel is busy, three additional values (primary20, primary40, and primary80) are added to the PHY-CCA.indication primitive. The value "primary20" indicates that the primary 20 MHz channel 310 is busy while the remaining non-primary channels are all idle. The value "primary40" indicates that the primary 40 MHz channel (310, 320) is busy while the remaining non-primary channels are all idle. The value "primary80" indicates that the primary 80 MHz channel (310, 320, 330, and 340) is busy while the remaining non-primary channels are all idle.

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

[0108] <Second Embodiment>

[0109] Reference Figure 13A An exemplary uplink multi-user transmission sequence 1300 shows the case where the bandwidth of the PPDU changes during the same TXOP 1305. Figure 1 The AP2 102 in sends an 80MHz DL MU PPDU 1310 containing, among other frames, two unicast trigger frames 1312 and 1314 addressed to STA5 150 and STA6 160, respectively. Trigger frame 1312 allocates RUs on the primary channel CH1 for STA5, while trigger frame 1314 allocates RUs on the secondary channel CH2 for the STA6. The AP2 102 also protects the subsequent uplink transmissions until the end of the TXOP 1305 by setting the TXOP duration in the PHY header of the PPDU 1310 or the duration field in the MAC header of each frame carried by the PPDU 1310. After a SIFS from the end of the PPDU 1310, STA5 sends its UL PPDU 1320 on CH1, while STA6 sends its UL PPDU 1330 on CH2.

[0110] The AP ends the frame exchange by sending DL MU PPDUs carrying Ack frames 1340 and 1350 to STA5 and STA6, respectively. If OBSS STAs (e.g., STA3 140 and STA4 145) are in the same BSS as the AP, the AP can send a single DL MU PPDU carrying Ack frames for all STAs in the BSS. Figure 1If STA2 120 receives PPDU 1310, STA2 determines that PPDU 1310 is an OBSS PPDU from BSS2 145. STA2 sets the basic NAV duration 1362 based on the duration information in PPDU 1310 until the end of TXOP 1305. However, if STA2 is able to decode the individual frames within MU PPDU 1310, STA2 is able to predict the bandwidth of the subsequent uplink transmission. For example, by decoding trigger frames 1314 and 1312, STA2 is able to determine that only CH1 and CH2 are assigned RUs for uplink. As such, STA2 can predict that the subsequent uplink transmission triggered by PPDU 1310 will only cover CH1 and CH2. As such, 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, i.e., the predicted bandwidth of the subsequent uplink transmission. This provides STA2 with an opportunity to utilize the idle secondary channels CH3 and CH4 for its own uplink transmission. The two-dimensional basic NAV is shown visually by rectangle 1360.

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

[0112] With reference to Figure 14Figure 14 shows a series of example frame exchange sequences to provide a visual illustration of two-dimensional NAV in an 80MHz BSS according to a second embodiment. The upper half depicts three transmission sequences with variable bandwidth: TXOP1 1412, TXOP2 1422, and TXOP3 1432. Each transmission sequence includes PPDU exchange between an AP and one or more STAs belonging to the same BSS as the AP. As an example, the first PPDU in the transmission sequence can be a trigger frame allocating RUs for UL MU transmission to selected STAs, followed by HE trigger-based PPDUs from the STAs, and ending with a DL PPDU from the AP carrying an acknowledgement frame. In this example, CH1, CH2, CH3, and CH4 represent primary, secondary, tertiary, and quaternary 20MHz channels. The lower half of this example depicts a visual representation of the two-dimensional NAV maintained by a third-party STA proposed by the present disclosure. A bitmap of the BW field used to record the NAV is also shown. The time points relevant to this example are denoted by t0, t1, t2, t3, t4, and t5. Any STA within the radio coverage of the ongoing transmission and neither the transmitter nor the receiver of the transmission is considered a third-party STA of the transmission.

[0113] Upon receiving the first PPDU 1410 of TXOP1 1412, the third-party STA determines that it is not the recipient of PPDU 1410, e.g., by reading the recipient address in the MAC header of the frame carried by the PPDU, or by reading the AID 12 subfield of the user info field of the trigger frame carried in PPDU 1410, etc. Once the STA determines that it is not the recipient of PPDU 1410, it sets the NAV duration from t0 to t1 according to existing NAV rules. In addition to recording the NAV duration, according to the second embodiment, the STA decodes the trigger frame in PPDU 1410 and determines that RUs have been allocated for subsequent uplink transmissions on CH1, CH2, and CH3. 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 denoted by box 1414, prohibiting the STA from transmitting on CH1, CH2, and CH3 until time t1, which is the end of TXOP1 1412.

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

[0115] In the same way, upon receiving PPDU 1430, the STA sets the NAV duration until time t5, which is the end of TXOP3 1432. The STA decodes the trigger frame in PPDU 1430 and determines that RUs have been allocated for subsequent uplink transmissions on CH1. Based on this, in the BW field of the NAV, the STA sets bit 0 to 1 (busy) and the rest of the bits to 0 (idle). This is shown as block 1434, which prohibits the STA from transmitting on CH1 until time t5. In this case, a third-party STA can be allowed to transmit on the unoccupied channels CH2, CH3, and CH4 during the NAV duration from t4 to t5 without causing interference to the ongoing transmission 1432.

[0116] <Configuration of the STA>

[0117] Figure 15 is a block diagram of an example STA 1500 that implements the two-dimensional NAV described in this disclosure. The device can be any one of the STAs in Figure 1 The STA 1500 includes a receiving unit 1502, a PPDU decoder 1504, a memory 1506, and a transmitting unit 1508.

[0118] The receiving unit 1502 receives PPDUs from other wireless devices within its radio 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 whether the PPDU was transmitted by an OBSS STA. The PPDU decoder 1504 also determines whether the STA is the intended recipient of the PPDU; if not, the PPDU decoder also extracts the duration information from the PHY header of the PPDU or the MAC header of the frame carried in the PPDU. The PPDU decoder also determines the bandwidth occupied by the received PPDU.

[0119] The STA 1500 can include one or more instances of a memory 1506. The memory 1506 records the duration information carried in the received PPDU and, if applicable, the bandwidth occupied by the PPDU. If the PPDU decoder determines that the STA transmitted the received PPDU from its corresponding BSS, the 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, the memory 1506 records both the duration information and the bandwidth information as part of the basic NAV. When instructed, the transmitting unit 1508 transmits on frequency channels other than the frequency channel indicated by the bandwidth information of the basic NAV without causing interference to the channel indicated by the basic NAV bandwidth.

[0120] Figure 16 is an example STA 1600 of any one of the STAs in Figure 1 A detailed block diagram of the example STA 1600 of any one of the STAs in

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

[0122] The STA 166 can include the MAC module 1652, the PHY module 1660, and the antenna 1670 for clarity Figure 16Many other components are not shown. Only those components most relevant to the present disclosure are shown.

[0123] <Third Embodiment>

[0124] In the preceding embodiments, the bandwidth information of the PPDU setting the NAV is recorded as a field of the NAV itself. However, the bandwidth information can also be decoupled from the NAV and recorded separately. According to the third embodiment, the STA records the bandwidth information of the PPDU setting the NAV as a separate entity, e.g., as an OBSS_BW information field.

[0125] Reference Figure 17 Fig. 17 shows a series of example frame exchange sequences 1700 providing a visual illustration of recording bandwidth information in an 80MHz BSS according to the third embodiment. Figure 17 The top part of Fig. 17 depicts four transmission sequences with variable bandwidth: TXOP1 1712, TXOP2 1722, TXOP3 1732, and TXOP4 1742. Each transmission sequence comprises an exchange of PPDUs between an AP and one or more STAs belonging to the same BSS as the AP.

[0126] Figure 17 The middle part of Fig. 17 depicts a visual representation of the NAV duration maintained by a third-party STA according to rules defined by IEEE 802.11 specifications. Any STA within the radio coverage of an ongoing transmission and neither the sender nor the intended receiver of the transmission is considered a third-party STA for this transmission. Figure 17 The bottom part of Fig. 17 depicts a visual representation of the OBSS_BW information maintained by the same third-party STA. The time points relevant to this example are denoted by tO, tl, t2, t3, t4, t5, t6, and t7.

[0127] On receiving the first PPDU 1710 of TXOP1 1712, the third party STA determines that it is not the intended recipient of the PPDU 1710, e.g., by reading the recipient address in the MAC header of the frame carried by the PPDU, or by reading the AID 12 subfield of the user info field of the trigger frame carried in the PPDU 1710, etc. Once the STA determines that it is not the intended recipient of the PPDU 1710, it sets the NAV duration to the duration from time tO to time ti according to existing IEEE 802.11 NAV rules, prohibiting the STA from transmitting until time ti as the end of TXOP1 1712. In addition to recording the NAV duration, according to the third embodiment, the STA also sets the bandwidth information of the PPDU 1710 that set the NAV in the OBSS_BW info field to 80 MHz. At time ti, when the NAV duration 1714 counts down to zero, the OBSS_BW info field is also reset to zero. Block 1716 depicts the OBSS_BW info between time tO and time ti. The OBSS_BW info field can be represented as a two-bit variable as shown in Table 750 in Figure 7B or it can also be kept as an 8-bit bitmap 1390 in Figure 13B

[0128] Similarly, on receiving the first PPDU 1720 of TXOP2 1722, the STA sets the NAV duration 1724 to the duration from time t2 to time t3, which is the end of TXOP2 1722, while the OBSS_BW info field is set to 40 MHz, the bandwidth of the PPDU 1720; this is shown as block 1726. At time t3, when the NAV duration 1724 counts down to zero, the OBSS_BW info field is also reset to zero. In the same manner, on receiving the first PPDU 1730 of TXOP3 1732, the STA sets the NAV duration 1734 to the duration from time t4 to time t5, which is the end of TXOP3 1732, while the OBSS_BW info field is set to 20 MHz, the bandwidth of the PPDU 1730; this is shown as block 1736. At time t5, when the NAV duration 1734 counts down to zero, the OBSS_BW info field is again reset to zero. If the channel sensing rules are also modified accordingly, the third party STA can be allowed to transmit on the unoccupied channels CH3 and CH4 during the duration from t2 to t3, and on channels CH2, CH3, and CH4 during the duration from t4 to t5, under certain conditions, without causing interference to the ongoing transmissions 1722 and 1732, respectively, thus facilitating more efficient reuse of the unoccupied secondary channels. ​

[0129] Traditionally, an IEEE 802.11 STA only needs to receive and decode a PPDU that overlaps with the STA’s primary 20 MHz channel; the STA does not need to receive or decode a PPDU that does not overlap with its primary 20 MHz channel. However, if the STA has the capability to receive and decode such a PPDU, the STA can also use the OBSS_BW information field to record the bandwidth of such a PPDU. TXOP4 1742 represents a sequence of frame exchanges that does not overlap with the primary 20 MHz used by a third-party STA. Upon receiving the first PPDU 1740 of TXOP4 1742, if the STA has the capability to receive and decode the PPDU, the STA can record the bandwidth in the OBSS_BW information field. Note that in this case, the STA does not set the NAV duration.

[0130] The bandwidth information recorded by the OBSS_BW information field can also be used as a reference by the STA to inform its associated AP of its channel availability. For example, if the STA implements the unsolicited bandwidth query report (BQR) operation defined in IEEE 802.11ax, the OBSS_BW information field can be used to populate the available channel bitmap that the STA sends to its associated AP in the bandwidth query report. TXOP4 1742 does not set the STA’s NAV duration, and thus does not prevent the STA from transmitting. However, recording the bandwidth of TXOP4 1742 in the OBSS_BW information field enables the STA to report to its AP that CH3 and CH4 are expected to be busy for the STA during the duration from time t6 to time t7. This would help the AP to avoid using CH3 and CH4 in any resource unit (RU) allocation to the STA for downlink OFDMA transmission to / from the STA during the duration from time t6 to time t7.

[0131] Referring back to Figure 5 The overprotective NAV that prohibits STA2 from transmitting UL PPDU 450 can be overcome by the concept of recording the bandwidth information from the ongoing OBSS transmission by BSS2 145 in the OBSS_BW information field, while making some changes to the virtual CS rules and UL MU CS mechanism. Figure 1

[0132] Figure 18 Table 1800 in Figure 5 illustrates various parameters related to the modified UL MU CS mechanism for STA2 during the UL MU transmission sequence shown in Figure 8B ​The contents of Table 880 in FIG. 9 are the same as Table 1800 in FIG. 18, except that the OBSS_BW information field is provided independently of the basic NAV 1810 in Table 1800. Since the OBSS transmissions from BSS2 145 only overlap in CH1 and CH2, CH1 and CH2 are recorded as busy, while CH3 and CH4 are recorded as idle in the OBSS_BW information field, respectively, by entries 1822 and 1820 in FIG. 18. Figure 18

[0133] According to a third embodiment, the virtual CS rules are modified such that the busy / idle virtual CS status is considered per 20MHz channel. Only those 20MHz channels that are indicated as busy by the OBSS_BW information field are considered busy by the virtual CS when the basic NAV duration counter is not zero. Similarly, the UL MU CS rules are also modified to consider the busy / idle status of the wireless medium on a per 20MHz channel basis. According to the modified UL MU CS rules, since both the virtual CS and energy detection (ED) based CCAs indicate busy on CH1 and CH2, and idle on CH3 and CH4, the UL MU CS mechanism considers CH1 and CH2 busy, while CH3 and CH4 are considered idle, as shown by entries 1836, 1834, 1832, and 1830, respectively. Since both CH3 and CH4 are considered idle, according to the modified UL MU CS transmission rules, STA2 is allowed to transmit its UL PPDU 450 on the allocated RU on CH3 and CH4, thereby facilitating more efficient use of the wireless medium. The virtual CS rules according to the third embodiment can be summarized as follows:

[0134] - For each 20MHz channel containing an allocated RU for an uplink transmission by a STA, the NAV is considered in the virtual CS of the STA triggering the frame requesting the transmission, unless one of the following conditions is met:

[0135] - The NAV is set by an intra-BSS frame

[0136] - The NAV duration counter is zero

[0137] - The NAV duration counter is greater than zero, but the 20MHz channel is recorded as idle by the OBSS_BW information field

[0138] If the NAV is not considered, the virtual CS indicates the 20MHz channel as idle, otherwise the virtual CS indicates the 20MHz channel as busy.

[0139] The UL MU CS rules according to the third embodiment can be summarized as follows:

[0140] ​- If the CS requirement subfield in the trigger frame is set to 1, the STA shall consider the status of CCA using appropriate energy detection (ED) rules and virtual CS prior to UL MU transmission in response to the trigger frame during the SIFS time following the trigger frame at least for each 20MHz channel containing the allocated RU for UL MU transmission by the STA. The STA can transmit HE Trigger-based PPDU when the 20MHz channel containing the allocated RU is considered idle in the trigger frame; the STA shall not transmit anything in the allocated RU if the STA detects that the 20MHz channel containing the allocated RU is not all idle.

[0141] Figure 19 A flowchart 1900 is depicted illustrating the UL MU CS transmission rules according to the third embodiment when the virtual CS rules are indicated per 20MHz channel by keeping the OBSS transmission bandwidth information in the OBSS_BW. The UL MU CS processing starts at step 1910 for each of the 20MHz channels of the wideband channel for which the STA has been allocated a RU by the AP for uplink transmission in the trigger frame for which the CS requirement field is set to 1. Since the CS requirement field is set to 1 in the trigger frame, the STA is required to perform UL MU CS on at least all 20MHz channels containing the allocated RU during the SIFS time immediately following the end of the PPDU containing the trigger frame before transmitting the HE Trigger-based PPDU.

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

[0143] At step 1980, the 20MHz channel is considered busy for UL MU transmission and the process ends for this 20MHz channel. At step 1970, the 20MHz channel is considered idle for UL MU transmission and the process ends for this 20MHz channel. The process 1900 is repeated at least for each of the 20MHz channels of the wideband channel for which the STA has been allocated a RU for uplink transmission. If all the 20MHz channels containing the RU allocated to the STA in the trigger frame are considered idle, the STA can transmit its HE-triggered PPDU.

[0144] Reference Figure 20 Table 2000 lists various parameters for which a STA receiving a valid NAV setting IEEE 802.11 PPDU can determine the channel bandwidth information of the PPDU. According to the IEEE 802.11 specification, upon reception of a valid IEEE 802.11 PHY preamble, the PHY layer of the STA measures the received signal strength level and if the signal strength level is above a certain threshold, usually referred to as the Preamble Detection (PD) level, the PHY indicates this to the MAC layer by the PHY-CCA.indication(BUSY, primary) primitive. The STA continues to receive the remaining PHY header fields and if the PHY header reception is successful, the PHY layer issues the PHY-RXSTART.indication(RXVECTOR) primitive to the MAC.

[0145] The content of RXVECTOR depends on the format of the received PPDU and the STA determines the bandwidth of the received PPDU based on the relevant parameters of RXVECTOR listed in table 2000. If the received PPDU is a HE PPDU, the bandwidth is indicated by the CH_BANDWIDTH parameter. The CH_BANDWIDTH parameter in turn is based on the bandwidth field in the HE-SIG-A of the PHY header of the received HE PPDU. If the received PPDU is a VHT PPDU, the bandwidth is also indicated by the CH_BANDWIDTH parameter. The CH_BANDWIDTH parameter in turn is based on the bandwidth field in the VHT-SIG-A1 of the PHY header of the received VHT PPDU.

[0146] If the received PPDU is an HT PPDU, the bandwidth is also indicated by the CH_BANDWIDTH parameter. The CH_BANDWIDTH parameter is in turn based on the CBW 20 / 40 bit in the HT-SIG of 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, as the non-HT PPDU can be either a legacy non-HT PPDU format or can be a non-HT duplicate PPDU format. The PPDU format of the non-HT PPDU can be determined by reference to the NON_HT_MODULATION parameter of the RXVECTOR. If the NON_HT_MODULATION parameter is OFDM, the PPDU is a legacy non-HT PPDU and the channel bandwidth is equal to 20 MHz.

[0147] However, if the NON_HT_MODULATION parameter is NON_HT_DUP_OFDM, the PPDU is a non-HT duplicate PPDU, i.e. the same PPDU is duplicated over multiple 20 MHz channels. In this case, the CH_BANDWIDTH parameter only indicates the estimated channel bandwidth. However, a non-HT duplicate PPDU can be sent by a bandwidth signaling STA, i.e. the transmitter address (TA) field of the MAC header contained in the received PPDU is a bandwidth signaling TA (the individual / group bit of the TA is 1). In this case, the exact bandwidth of the PPDU can be determined by further reference to the CH_BANDWIDTH_IN_NON_HT parameter of the RXVECTOR. In some cases, it can not be possible to determine the exact bandwidth of a non-HT duplicate PPDU, e.g. a CTS frame is typically transmitted in non-HT PPDU or non-HT duplicate PPDU format to ensure maximum NAV protection for legacy devices.

[0148] As a CTS frame does not even contain a TA field, it is not possible to determine the exact bandwidth covered by a CTS frame if sent in non-HT duplicate format. If such a PPDU is received and the STA is not able to determine the exact bandwidth of the PPDU, according to the third embodiment, the OBSS_BW information field is set such that all operating channels of the STA 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 unintentionally cause interference to ongoing OBSS transmissions.

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

[0150] <Fourth Embodiment>

[0151] As mentioned previously, sometimes a STA can not be able to determine the exact bandwidth of a received PPDU, or the STA can choose not to record the bandwidth information of a received PPDU for implementation ease or any other reason. At other times, even if the PPDU setting the NAV only occupies the primary 20MHz channel, the STA can have other information that indicates that transmissions on non-primary channels during the NAV duration can not be desirable.

[0152] Similarly, even if a STA can not be able to determine the exact bandwidth of a received PPDU based on its historical knowledge of neighboring OBSSs, the STA can still be able to accurately predict the bandwidth of the PPDU. For example, based on previously received OBSS frames, the STA can know that a certain OBSS only operates on the 20MHz primary channel, or that a certain HE STA is a 20MHz-only device (based on frames received during the capability exchange between the STA and its AP). The STA can build such a repository of knowledge of its neighborhood over time, and when a PPDU is received, based on some relevant fields in the PPDU, such as the basic service set identifier (BSSID) or the sender / receiver address, etc., the STA can be able to decide that its transmissions on non-primary channels during the NAV period (i.e., the duration for which the NAV duration counter is non-zero) are harmless.

[0153] According to a fourth embodiment, instead of recording the bandwidth information of the NAV- setting PPDU, the STA maintains a flag TX_Allowed that indicates whether the STA can transmit on non-primary 20MHz channels during the NAV period. The TX_Allowed flag can be maintained independently of the NAV, or it can also be closely related to the NAV.

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

[0155] The last bit, B15, is used as the TX_Allowed flag 2220. The encoding of the TX_Allowed flag is illustrated in table 2230. When 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. When it is set to 1, the STA can transmit on the non-primary 20MHz channel during the NAV period if other conditions allow (e.g., if energy detection (ED)-based channel sensing also returns the non-primary 20MHz channel as idle).

[0156] Reference Figure 23 A series of example frame exchange sequences 2300 are shown to provide a visual illustration of recording the NAV in an 80MHz BSS according to the fourth embodiment.

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

[0158] Upon receiving the first PPDU 2310 of TXOP1 2312, e.g., by reading the recipient address in the MAC header of the frame carried by the PPDU, or by reading the AID 12 subfield of the user info field of the trigger frame carried in the PPDU 2310, etc., the third party STA determines that the third party STA itself is not the intended recipient of the PPDU 2310. Once the STA determines that the STA itself is not the recipient of the PPDU 2310, then according to existing NAV rules, it copies the protection duration from the relevant field of the PPDU 2310 and sets the NAV duration 2210 to, e.g., the duration from time to to time ti.

[0159] In addition to recording the NAV duration, according to the fourth embodiment, the STA also predicts whether transmissions on other 20 MHz channels within its operating bandwidth other than the primary 20 MHz channel are allowed. The STA can use information such as the bandwidth of the PPDU 2310, its historical knowledge of its neighboring OBSS, relevant fields in the PPDU such as the basic service set identifier (BSSID) or transmitter / receiver addresses, etc., to decide whether transmissions on non-primary channels are harmless within the NAV duration.

[0160] In the case of the PPDU 2310, the STA predicts that transmissions on other non-primary 20 MHz channels are not recommended during the NAV period to ti due to the high risk of interference from the subsequent transmission of TXOP1 2312 on CH2, CH3, and CH4. Therefore, it sets the TX_Allowed flag 2200 to 0. This is shown visually by block 2314. Similarly, upon receiving the PPDU 2320, the STA sets the NAV duration to the duration from time t2to time t3, which is the end of TXOP2 2322. In this case, the STA also predicts that transmissions on other non-primary 20 MHz channels are not recommended during the NAV period t2to t3due to the risk of interference from the subsequent transmission of TXOP1 2322 on CH2, therefore it sets the TX_Allowed flag 2200 to 0. This is shown as block 2324.

[0161] In the same manner, upon receiving PPDU 2330, the STA sets the NAV duration to the duration from time t4 to time t5, which is the end of TXOP3 2332. At this point, although the STA predicts that its transmissions on the non-primary 20MHz channels CH2, CH3, and CH4 during the NAV period do not interfere with the subsequent transmissions of TXOP3 2332, it sets the TX_Allowed flag 2200 to 1, indicating that the STA can transmit on the non-primary 20MHz channels during the NAV period t4 to t5, if other conditions allow. This is shown visually by block 2336. However, transmissions on the primary 20MHz channel CH1 are prohibited during the NAV period, as indicated visually by block 2334. At time t5, when the NAV duration counter becomes zero, the TX_Allowed flag is also reset to zero.

[0162] Figure 24 An example UL MU transmission sequence 400 in yet another channel condition is shown to highlight the improvement in spectrum reuse made by the fourth embodiment. At the time STA 1 receives the trigger frame 410 from AP1 Figure 1 At the time STA 1 receives the trigger frame 410, there are no ongoing transmissions within the radio coverage area of STA1, STA3, and STA4 on the primary 20MHz channel, and the intra-BSS NAV and the basic NAV of STA1, STA3, and STA4 are all set to zero. However, as shown in the transmission sequence 2400, there is an ongoing OBSS transmission within the BSS2 Figure 1

[0163] AP2 (102) and STA5 (150) exchange frames using the Reverse Direction Protocol (RDP). AP2 sends a PPDU 2410 to STA5 including an RDP A-Control field, with the Reverse Direction Grant (RDG) / More PPDU field set to 1. And STA5 replies with a PPDU 2420 SIFS after the end of PPDU 2410. AP2 ends the frame exchange by sending an ACK frame 2430 to STA5.

[0164] Upon receiving PPDU 2410, STA2 determines that it is an OBSS PPDU and sets its basic NAV until the end of the transmission sequence 2400. The shown OBSS interference to STA2 is the same as in the transmission sequence 2000. Figure 5 ​The virtual CS rules are modified according to the fourth embodiment such that the busy / idle virtual CS status is considered differently for different 20MHz channels. At least, the virtual CS is considered differently for the primary 20MHz channel within the operating bandwidth of the STA and the remaining non-primary 20MHz channels. When the basic NAV duration counter is non-zero, the primary 20MHz channel is always indicated as busy by the virtual CS. However, whether the non-primary 20MHz channels are considered as idle or busy by the virtual CS depends on the TX_Allowed flag. When the TX_Allowed flag is not set, i.e., the TX_Allowed bit 2220 is 0, all non-primary 20MHz channels are also indicated as busy. However, when the TX_Allowed flag is set, i.e., the TX_Allowed bit 2220 is 1, all non-primary 20MHz channels are indicated as idle.

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

[0166] Figure 25 The table 2500 in FIG. 25 lists various parameters related to the modified UL MU CS mechanism according to the fourth embodiment for STA2 during the UL MU transmission sequence 400 shown in FIG. 24. Figure 24 The table 2500 in FIG. 25 lists various parameters related to the modified UL MU CS mechanism according to the fourth embodiment for STA2 during the UL MU transmission sequence 400 shown in FIG. 24. Figure 8B The table 880 in FIG. 28 lists various parameters related to the UL MU CS mechanism for STA2 during the UL MU transmission sequence 400 shown in FIG. 27. The content of the table 880 and its content is almost the same as that of the table 2500 in FIG. 25, except that CH2 is idle, and instead of keeping the busy / idle status of each 20MHz channel by recording the bandwidth information of the PPDU that set the basic NAV, only the TX_Allowed flag is kept, as shown by the abbreviation TX_A 2510. Upon receiving the PPDU 2410, based on the relevant fields from the PPDU, such as the BSS color, the CH_BANDWIDTH parameter of the RXVECTOR, STA2 determines that it is an inter-BSS 20MHz PPDU. STA2 can also have the historical information that BSS2 operates on 20MHz only, and based on the BSS color or BSSID of the frame contained in the PPDU 2410, STA2 can reliably predict that during the NAV period, the OBSS transmission 2400 will be limited to the primary 20MHz channel CH1. In this way, STA2 determines that it is safe to transmit its UL MU PPDU on the non-primary channels during the NAV period, and thus it sets the TX_Allowed bit 2200 to 1.

[0167] According to the virtual CS rule of the fourth embodiment, CH1 is indicated as busy 2522, but since the TX_Allowed bit 2200 is equal to 1, the non-primary channels CH2, CH3, and CH4 are indicated as idle by the virtual CS. Similarly, when STA2 performs energy detection (ED) based CCA during SIFS after the PPDU 410 containing the trigger frame, CH1 is indicated as busy, while the three non-primary channels CH2, CH3, and CH4 are indicated as idle. The UL MU CS mechanism takes into account the status of the virtual CS and energy detection sensing and indicates CH1 as busy, while CH2, CH3, and CH4 are considered as idle, indicated by entries 2536, 2534, 2532, and 2530, respectively. Since CH3 and CH4 are both considered as idle, according to the modified UL MU CS transmission rule, STA2 is allowed to transmit its UL PPDU 450 on the allocated RU on CH3 and CH4, thus facilitating more efficient use of the wireless medium.

[0168] The virtual CS rule according to the fourth embodiment can be summarized as follows:

[0169] - For each 20 MHz channel containing an allocated RU for UL transmission by a STA, the NAV is considered in the virtual CS of the STA requested by the trigger frame for transmission, unless one of the following conditions is met:

[0170] - The NAV is set by an intra-BSS frame

[0171] - The NAV duration counter is zero

[0172] - The 20 MHz channel is not the primary 20 MHz channel and the TX_Allowed flag is set to 1.

[0173] If the NAV is not considered, the virtual CS indicates the 20 MHz channel as idle, otherwise the virtual CS indicates the 20 MHz channel as busy.

[0174] The UL MU CS rule according to the fourth embodiment can be summarized as follows:

[0175] - If the CS requirement subfield in the trigger frame is set to 1, during the SIFS time after the trigger frame, at least for each 20 MHz channel containing an allocated RU for UL MU transmission by a STA, the STA shall respond to the trigger frame, prior to the UL MU transmission, taking into account the status of CCA using the appropriate energy detection (ED) rule and virtual CS. The STA can transmit a HE trigger-based PPDU when the 20 MHz channel containing the allocated RU is considered as idle in the trigger frame; if the STA detects that the 20 MHz channel containing the allocated RU is not all idle, the STA shall not transmit anything in the allocated RU.

[0176] Figure 26 A flowchart 2600 illustrating the UL MU CS transmission rule according to the fourth embodiment is depicted. The UL MU CS process starts at step 2610 for each of the 20 MHz channels of the wideband channel for which the STA has been allocated a RU for uplink transmission by the AP in the trigger frame with the CS requirement field set to 1. Since the CS requirement field is set to 1 in the trigger frame, the STA is required to perform UL MU CS on at least all the 20 MHz channels containing the allocated RU during the SIFS time immediately after the end of the PPDU containing the trigger frame before transmitting the HE trigger-based PPDU. At step 2620, the basic NAV duration counter is checked and if it is zero, the process moves to step 2640, otherwise the process moves to step 2630.

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

[0178] At step 2670, the STA listens to the wireless medium using energy detection (ED) during the SIFS time immediately after the end of the PPDU containing the trigger frame and if the channel is heard as busy, the process moves to step 2690, otherwise the process moves to step 2680. At step 2690, the 20 MHz channel is considered busy for UL MU transmission and the process ends for this 20 MHz channel. Similarly, at step 2670, the 20 MHz channel is considered idle for UL MU transmission and the process ends for this 20 MHz channel. The process 2600 is repeated at least for each of the 20 MHz channels of the wideband channel for which the STA has been allocated a RU for uplink transmission. When all the 20 MHz channels containing the RU allocated to the STA in the trigger frame are considered as idle, the STA can transmit its HE trigger-based PPDU on the allocated RU.

[0179] Reference Figure 27 A series of example frame exchange sequences are shown, for example, in Figure 9A visual illustration of the update rule for the TX_Allowed flag is provided in the top of the BSS layout shown in FIG. 13 (assuming all three BSSs, BSS1 100, BSS2 145, and BSS3 900, are 80MHz BSSs) when there are multiple OBSSs within the radio coverage of the STA. In Figure 27 The top of FIG. 13 depicts three transmission sequences of different bandwidths in BSS2 145: an 80MHz TXOP1 2710 and two 20MHz TXOPs: TXOP2 2720 and TXOP3 2730. Similarly, the bottom of FIG. 13 depicts three transmission sequences of different bandwidths in BSS3 900: two 20MHz TXOPs: TXOP4 2740, TXOP6 2760, and a variable bandwidth TXOP5 2750. Figure 27 The middle of FIG. 13 depicts a visual illustration of the basic NAV maintained by STA2 120 as proposed by the fourth embodiment. The time points relevant to this example are denoted by tO, tl, t2, t3, t4, t5, t6, t7, t8, t9, tlO, and tl 1. Figure 27 Upon receiving the first PPDU 2712 of TXOP1 2710, STA2 determines that PPDU 2712 is an OBSS PPDU from BSS2 based on the BSS color field in the PHY header or the BSSID field in the MAC header and that STA2 is not one of the recipients of the PPDU. According to the existing NAV rule for updating the NAV duration, STA2 sets the basic NAV duration from time tO to time t2. At the same time, based on its prediction of future OBSS transmissions during the NAV period, STA2 sets the TX_Allowed flag to 0.

[0180] 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, according to the rule for updating the NAV duration, STA2 updates the NAV duration until time t3, the end of TXOP4 2740. Even though STA2 determines that the bandwidth of TXOP4 2740 is only 20MHz based on its knowledge of the BSS2 transmission sequence 2710, STA2 decides that it should continue to prohibit transmissions on the non-primary channel during the extended NAV period, so it does not change the TX_Allowed flag.

[0181]

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

[0183] Upon receiving the first PPDU 2752 of TXOP5 2750, STA2 determines that 2752 is an OBSS PPDU from BSS3, and it is not one of the recipients of the PPDU. Since the duration indicated in 2752 is shorter than the existing NAV duration, STA2 does not update the NAV duration according to the NAV rule for updating the NAV duration. However, since the bandwidth of PPDU 2752 is wider than 20MHz, STA2 predicts the risk of interference to OBSS from transmissions on the non-primary channel, and thus updates the TX_Allowed flag to 0, prohibiting new transmissions on the non-primary channel during the rest of the NAV period. However, based on some fields of PPDU 2752 or its priori knowledge of BSS3 (e.g., PPDU 2752 contains a frame soliciting response from only HE 20MHz-only devices (i.e., devices with capability to work on only the primary 20MHz channel)), if STA2 is able to determine that the bandwidth of TXOP5 will reduce to 20MHz, STA2 can also choose not to update the TX_Allowed flag, thus continuing to allow transmissions in the non-primary 20MHz channel during the NAV period.

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

[0185] On receiving the first PPDU 2762 of TXOP6 2760, STA2 determines 2762 is an OBSS PPDU from BSS3 and it is not one of the recipients of the PPDU. Since the duration indicated in PPDU 2762 is longer than the existing NAV duration, STA2 updates the NAV duration until time t11, i.e., the end of TXOP6 2760, according to the rule of updating the NAV duration. Since the bandwidth of TXOP6 2760 is also only 20MHz, STA2 chooses not to update the TX_Allowed flag, thus continuing to allow transmissions in the non-primary 20MHz channel during the NAV period. At time t11, when the NAV duration counter reaches zero, STA2 resets the TX_Allowed flag to zero.

[0186] The update rule for the TX_Allowed flag is summarized by flowchart 2800 in Figure 28 When a NAV setting OBSS PPDU is received, the process starts at step 2810. If the current value of the basic NAV duration is equal to zero, the process moves to step 2870, otherwise it moves to step 2820.

[0187] If the PPDU causes an increase in the NAV duration of the basic NAV, the process moves to step 2830, otherwise the process moves to step 2840. At step 2830, the basic NAV duration is updated according to the relevant duration information in the PPDU (e.g., based on the TXOP duration field in the PHY header, or the duration field in the MAC header), and the process moves to step 2840. At step 2840, if the TX_Allowed flag is equal to 1, the process moves to step 2850, otherwise the process ends.

[0188] At step 2850, the STA determines whether its transmission on the non-primary 20MHz channel can cause interference to OBSS transmissions, and if so, the process moves to step 2860, otherwise the process ends. At step 2860, the STA sets the TX_Allowed flag to 0 and the process ends.

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

[0190] It goes without saying that the use of Figure 15 and 16 The above-described configuration of the STA described can implement the above-described third and fourth embodiments of the present disclosure.

[0191] According to an aspect of the present application, there is provided a communication apparatus comprising: a receiving unit receiving a PHY layer data unit comprising a duration field, the duration field comprising duration information indicating a duration during which the communication apparatus is prohibited from transmitting a high efficiency, HE, trigger based TB PHY layer data unit; and a physical, PHY, layer circuitry issuing a PHY-CCA idle channel assessment primitive parameter indicating bandwidth information about a busy or idle state of each subchannel within an operating bandwidth; and a medium access control, MAC, circuitry updating a NAV value based on the duration information when the indicated duration is greater than a current NAV value, and when it is determined that the communication apparatus is not a target receiver of the received PHY layer data unit; and determining a busy / idle state of at least one subchannel comprising a resource unit, RU, on which the HE TB PHY layer data unit is to be transmitted, based on the bandwidth information; wherein the MAC circuitry controls transmission of the HE TB PHY layer data unit based on the updated NAV value and the busy / idle state of the at least one subchannel, and controls the PHY circuitry to transmit the HE TB PHY layer data unit when the at least one subchannel does not comprise a primary subchannel, regardless of whether the primary subchannel is busy or idle, when the at least one subchannel is considered idle.

[0192] According to the aforementioned communication apparatus, wherein the MAC circuitry updates a NAV bandwidth value based on the bandwidth information when it is determined that the communication apparatus is not a target receiver of the received PHY layer data unit, when the indicated bandwidth is wider than a current NAV bandwidth value.

[0193] According to the preceding communication apparatus, wherein the operating bandwidth comprises a plurality of 20MHz sub-channels, and the PHY-CCA primitive parameter comprises an 8-bit bitmap, wherein each bit of the 8 bits corresponds to a respective one of the plurality of 20MHz sub-channels, and the 8-bit bitmap indicates a busy state of each 20MHz sub-channel by setting the corresponding bit to 1, and indicates an idle state of each 20MHz sub-channel by setting the corresponding bit to 0.

[0194] According to the preceding communication apparatus, wherein when the receiving unit receives a trigger frame comprising a carrier sense, CS, requirement subfield, and the CS requirement subfield indicates that carrier sense is required, the MAC circuit performs the carrier sense on the at least one sub-channel within the operating bandwidth after receiving the trigger frame.

[0195] According to the preceding communication apparatus, wherein after receiving the trigger frame transmitted from an access point in communication with the communication apparatus, the MAC circuit controls transmission of the HE TB PHY layer data unit.

[0196] According to the preceding communication apparatus, wherein the RU to transmit the HE TB PHY layer data unit is assigned by the trigger frame.

[0197] According to the preceding communication apparatus, wherein the MAC circuit controls transmission of the HE TB PHY layer data unit after a short interframe space, SIFS, from the end of the trigger frame.

[0198] According to the preceding communication apparatus, wherein the operating bandwidth comprises a plurality of 20MHz sub-channels including a primary 20MHz sub-channel and at least one secondary 20MHz sub-channel, and the PHY-CCA primitive parameter indicates that the primary 20MHz sub-channel is busy and the at least one secondary 20MHz sub-channel is idle.

[0199] According to the preceding communication apparatus, wherein the PHY-CCA primitive parameter is used for a bandwidth query report, BQR, operation for providing channel availability information on at least one 20MHz sub-channel, and the MAC circuit sets an available channel bitmap field in the BQR according to the PHY-CCA primitive parameter, and controls transmission of a HE TB PHY layer data unit comprising the BQR.

[0200] According to the preceding communication apparatus, wherein the PHY layer circuit performs actual sensing of the wireless medium using at least one of a preamble detection, PD, and an energy detection, ED, and issues the PHY-CCA primitive parameter based on a result of the actual sensing.

[0201] According to another aspect of the present application, there is provided a communication method, comprising: receiving a PHY layer data unit comprising a duration field, the duration field comprising duration information indicating a duration for which a communication device is prohibited from transmitting a high efficiency, HE, trigger based TB PHY layer data unit; issuing a PHY-CCA clear channel assessment primitive parameter indicating bandwidth information about busy or idle status of each subchannel within an operating bandwidth; updating a network allocation vector, NAV, value based on the duration information when the indicated duration is greater than a current NAV value, and when it is determined that the communication device is not a target receiver of the received PHY layer data unit; and determining a busy / idle status of at least one subchannel comprising a resource unit, RU, on which the HE TB PHY layer data unit is to be transmitted based on the bandwidth information; and controlling transmission of the HE TB PHY layer data unit based on the updated NAV value and the busy / idle status of the at least one subchannel, and controlling transmission of the HE TB PHY layer data unit when the at least one subchannel does not comprise a primary subchannel, regardless of whether the primary subchannel is busy or idle, when the at least one subchannel is considered idle.

[0202] According to the aforementioned communication method, comprising: updating a NAV bandwidth value based on the bandwidth information when the indicated bandwidth is wider than a current NAV bandwidth value when it is determined that the communication device is not a target receiver of the received PHY layer data unit.

[0203] According to the aforementioned communication method, wherein the operating bandwidth comprises a plurality of 20MHz subchannels, the PHY-CCA primitive parameter comprises an 8-bit bitmap, wherein each bit of the 8 bits corresponds to a respective one of the plurality of 20MHz subchannels, and the 8-bit bitmap indicates a busy status of each 20MHz subchannel by setting the corresponding bit to 1 and an idle status of each 20MHz subchannel by setting the corresponding bit to 0.

[0204] According to the aforementioned communication method, wherein when a trigger frame comprising a carrier sense, CS, requirement subfield is received, and the CS requirement subfield indicates that carrier sensing is required, the carrier sensing is performed on the at least one subchannel within the operating bandwidth after the trigger frame is received.

[0205] According to the aforementioned communication method, comprising: controlling transmission of the HE TB PHY layer data unit after receiving the trigger frame transmitted from an access point in communication with the communication device.

[0206] According to the aforementioned communication method, wherein the RUs on which the HE TB PHY layer data unit is to be transmitted are assigned by the trigger frame.

[0207] According to the aforementioned communication method, the HE TB PHY layer data unit is controlled to be transmitted after a short interframe space, SIFS, from the end of the trigger frame.

[0208] According to the aforementioned communication method, the operating bandwidth comprises a plurality of 20MHz sub-channels including a primary 20MHz sub-channel and at least one secondary 20MHz sub-channel, and the PHY-CCA primitive parameter indicates that the primary 20MHz sub-channel is busy and the at least one secondary 20MHz sub-channel is idle.

[0209] According to the aforementioned communication method, the PHY-CCA primitive parameter is used for a bandwidth query report, BQR, operation for providing channel availability information on at least one 20MHz sub-channel, and the communication method comprises setting an available channel bitmap field in the BQR according to the PHY-CCA primitive parameter, and controlling transmission of the HE TB PHY layer data unit including the BQR.

[0210] According to the aforementioned communication method, the PHY-CCA primitive parameter is used for a bandwidth query report, BQR, operation for providing channel availability information on at least one 20MHz sub-channel, and the communication method comprises setting an available channel bitmap field in the BQR according to the PHY-CCA primitive parameter, and controlling transmission of the HE TB PHY layer data unit including the BQR.

[0211] In the foregoing embodiments, the present disclosure is configured with hardware by way of example, but can also be provided by software cooperating with hardware.

[0212] In addition, the functional blocks used in the description of the embodiments are generally implemented as LSI devices, which are integrated circuits. The functional blocks can be formed as separate chips, or a part or all of the functional blocks can be integrated into a single chip. The term "LSI" is used here, but the term "IC", "system LSI", "super LSI", or "ultra LSI" can also be used depending on the degree of integration.

[0213] In addition, circuit integration is not limited to LSI, and can be implemented by dedicated circuit or general purpose processor other than LSI. After LSI is manufactured, a field programmable gate array (FPGA) that can be programmed, or a reconfigurable processor that allows reconfiguration of the connection and settings of circuit units in LSI can be used.

[0214] If a circuit integration technology replacing LSI emerges as a result of the progress of semiconductor technology or other technologies derived from the technology, the functional blocks can be integrated using such technology. Another possibility is the application of biotechnology and / or the like.

[0215] [Industrial applicability]

[0216] The present disclosure can be applied to a wireless device for efficient virtual carrier sense (CS) in a multi-channel wireless communication system.

[0217] [List of reference numerals]

[0218] 1500 STA (station)

[0219] 1502 reception unit

[0220] 1504 PPDU decoder

[0221] 1506 memory

[0222] 1508 transmission unit

[0223] 1600 STA (station)

[0224] 1610 power supply

[0225] 1620 memory

[0226] 1630 central processing unit (CPU)

[0227] 1640 secondary storage

[0228] 1650 wireless communication interface

[0229] 1652 MAC module

[0230] 1654 carrier sense module

[0231] 1656 NAV bandwidth bitmap

[0232] 1658 NAV duration counter

[0233] 1660 PHY module

[0234] 1670 antenna

Claims

1. An integrated circuit for controlling a communication process of a communication device, comprising: means for receiving a PHY protocol data unit including a duration field, the duration field including duration information indicating a duration for which the communication device is prohibited from transmitting a PHY protocol data unit based on a high-efficiency HE triggering TB; means for issuing PHY-CCA idle channel assessment primitive parameters indicating bandwidth information regarding a busy or idle status of each subchannel within an operating bandwidth; Parts for: When the indicated duration is greater than a current network allocation vector (NAV) value and when it is determined that the communication device is not an intended recipient of the received PHY protocol data unit, updating the NAV value based on the duration information; Determine, based on the bandwidth information, a busy / idle state of at least one subchannel of a resource unit RU including a PHY protocol data unit for transmitting the high-efficiency HE triggering TB; as well as The transmission of the PHY protocol data unit based on the high-efficiency HE triggered TB is controlled based on the updated NAV value and the busy / idle status of the at least one subchannel, and when the at least one subchannel excluding the primary subchannel is considered idle, the PHY protocol data unit based on the high-efficiency HE triggered TB is controlled to be sent regardless of whether the primary subchannel is busy or idle.

2. The integrated circuit of claim 1 , wherein the means for updating the NAV value is operable to: When it is determined that the communication device is not the intended recipient of the received PHY protocol data unit, and when the indicated bandwidth is wider than the current NAV bandwidth value, the NAV bandwidth value is updated based on the bandwidth information.

3. The integrated circuit according to claim 1, wherein: The operating bandwidth includes multiple 20MHz sub-channels, and the PHY-CCA primitive parameter includes an 8-bit bit map, wherein each of the 8 bits corresponds to a corresponding one of the multiple 20MHz sub-channels, and the 8-bit bit map indicates the busy state of each 20MHz sub-channel by setting the corresponding bit to 1, and indicates the idle state of each 20MHz sub-channel by setting the corresponding bit to 0.

4. The integrated circuit according to claim 1, wherein: When a trigger frame including a carrier sensing CS requirement subfield is received, and the CS requirement subfield indicates that carrier sensing is required, after receiving the trigger frame, the carrier sensing is performed on the at least one subchannel within the operating bandwidth.

5. The integrated circuit of claim 4 , wherein the means for updating the NAV value is operable to: After receiving the trigger frame transmitted from an access point communicating with the communication device, transmission of the high-efficiency HE trigger TB-based PHY protocol data unit is controlled.

6. The integrated circuit according to claim 4, wherein: The RU to send the PHY protocol data unit based on the high-efficiency HE trigger TB is assigned by the trigger frame.

7. The integrated circuit of claim 4 , wherein the means for updating the NAV value is operable to: The PHY protocol data unit based on the high-efficiency HE trigger TB is controlled to be sent within a short interframe space (SIFS) after the end of the trigger frame.

8. The integrated circuit according to claim 1, wherein: The operating bandwidth includes a plurality of 20 MHz subchannels including a primary 20 MHz subchannel and at least one secondary 20 MHz subchannel, and a PHY-CCA primitive parameter indicates that the primary 20 MHz subchannel is busy and the at least one secondary 20 MHz subchannel is idle.

9. The integrated circuit according to claim 1, wherein: The PHY-CCA primitive parameter is used for a bandwidth query report (BQR) operation to provide channel availability information on at least one 20 MHz subchannel, and the component for updating the NAV value can be used to set the available channel bitmap field in the BQR according to the PHY-CCA primitive parameter and control the transmission of the PHY protocol data unit based on the high-efficiency HE triggering TB including the BQR.

10. The integrated circuit of claim 1 , wherein the means for issuing PHY-CCA idle channel assessment primitive parameters is operable to: performing actual listening of the wireless medium using at least one of preamble detection (PD) and energy detection (ED); and The PHY-CCA primitive parameters are issued based on the result of the actual listening.

Images