Radio communication device

Abstract

To allocate a radio resource allocated from other APs to STAs.SOLUTION: A radio communication device is housed in a first radio communication group together with a first terminal. The first radio communication group constitutes an extended radio communication group together with a second radio communication group housing a second radio communication device and a second terminal. The radio communication device receives a first frame for providing a part of a first occupancy time of a communication medium acquired by the second radio communication device to the radio communication device. The first frame includes a first field indicating a part of the period and a second field specifying identification information of a target device to which the part of the frame is assigned. When the second field specifies the identification information on the radio communication device and uses a part of the period, the radio communication device transmits a response frame to the second radio communication device after receiving the first frame, and transmits a second frame including a third field indicating an available period in the part of the period to the first terminal.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] FIELD Embodiments of the present invention relate to carrier sense communication, and more particularly to communication in which multiple access points cooperate. [Background technology]

[0002] In wireless LAN (Local Area Network) systems, cooperative operation of multiple access points (APs, also called base stations) has been proposed. As an example, a method has been proposed in which an AP acquires a transmission right and then shares the wireless resources of time and frequency during the transmission opportunity (TXOP) with multiple other APs. The concept of this method has been decided to be adopted by the 802.11 Task Group (TG) be, which is standardizing the next-generation high-speed wireless LAN standard. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] U.S. Patent Application Publication No. 2021 / 0051722 [Patent Document 2] US Patent Application Publication No. 2020 / 0267636 [Patent Document 3] US Patent Application Publication No. 2020 / 0076551 [Patent Document 4] US Patent Application Publication No. 2020 / 0120544 [Non-patent literature]

[0004] [Non-Patent Document 1] IEEE 802.11-19 / 1582r1 [Non-patent document 2] IEEE 802.11-19 / 1262r23 [Non-patent document 3] IEEE 802.11-20 / 1935r44 [Non-patent document 4] IEEE Std 802.11-2020 [Non-Patent Document 5] IEEE Std 802.11ax-2021 Summary of the Invention [Problem to be solved by the invention]

[0005] However, in wireless communication systems using CSMA / CA (carrier sense multiple access with collision NAVoidance), a NAV (network allocation vector) is set for the purpose of protecting TXOP, so even if the proposed method is simply implemented in a wireless communication system using CSMA / CA, there is no mechanism for an AP that has been allocated wireless resources and its subordinate non-AP STAs (hereinafter simply referred to as STAs or terminals) to transmit within the allocated wireless resources.

[0006] An object of the present invention is to provide a mechanism in a wireless communication system using CSMA / CA where an AP that has been allocated wireless resources by another AP and its subordinate non-AP STAs can transmit within the allocated wireless resources. [Means for solving the problem]

[0007] A wireless communication device according to an embodiment is included in a first wireless communication group together with a first terminal. The first wireless communication group, together with a second wireless communication device and a second wireless communication group including the second terminal, forms an extended wireless communication group. The wireless communication device receives a first frame for allocating a portion of a first occupancy time of a communication medium acquired by the second wireless communication device to the wireless communication device. The first frame includes a first field representing the portion of the period and a second field specifying identification information of a target device to which the portion of the period is allocated. When the second field specifies the identification information of the wireless communication device and the wireless communication device uses the portion of the period, the wireless communication device transmits a response frame to the second wireless communication device a fixed time after receiving the first frame, and then transmits a second frame including a third field representing the portion of the period to the first terminal. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a diagram showing an example of a wireless communication system according to a first embodiment. [Figure 2] FIG. 1 is a diagram showing an example of a wireless communication device according to a first embodiment. [Figure 3] A diagram showing the basic format of a MAC frame. [Figure 4] FIG. 10 is a diagram showing the relationship between the states of basic NAV and intra-BSS NAV and whether or not a response to a trigger frame is possible. [Figure 5] FIG. 10 is a diagram showing an example of a format of a trigger frame. [Figure 6] 10 is a diagram showing an example of MAP in which a sharer AP divides some resources (time) of a TXOP by time and distributes the divided resources to multiple sharer APs. FIG. [Figure 7] FIG. 10 is a diagram for explaining an example of channel bonding. [Figure 8] FIG. 10 is a diagram for explaining a method for acquiring a transmission right in an example of channel bonding. [Figure 9] 10 is a diagram showing an example of MAP in which a sharing AP divides some resources (time) of a TXOP by frequency and distributes the divided resources to multiple sharing APs. [Figure 10] FIG. 10 is a diagram showing an example of information elements included in the Frame Body of a MAC frame. [Figure 11] FIG. 1 is a diagram for explaining an example of AP method 1. [Figure 12] FIG. 10 is a diagram for explaining an example of AP method 2. [Figure 13] FIG. 10 is a diagram showing the relationship between the two NAV states and whether or not a response to a trigger frame is possible in AP method 2. [Figure 14] FIG. 10 is a diagram for explaining an example of AP method 3. [Figure 15] FIG. 10 is a diagram showing the relationship between two NAV states and whether MAP transmission is possible in AP method 3. [Figure 16] FIG. 10 is a diagram for explaining an example of AP method 4. [Figure 17] FIG. 10 is a diagram showing the relationship between three NAV states and whether MAP transmission is possible in AP method 4. [Figure 18] FIG. 1 is a diagram for explaining an example of STA method 1. [Figure 19] FIG. 1 is a diagram for explaining an example of an AP / STA technique. [Figure 20] FIG. 10 is a diagram for explaining an example of STA method 2. [Figure 21] FIG. 10 is a diagram for explaining an example of STA method 3. [Figure 22] FIG. 10 is a diagram for explaining an example of STA method 4. [Figure 23] FIG. 10 is a diagram for explaining an example of STA method 5. [Figure 24] 10 is a flowchart showing an example of NAV setting in STA method 6. [Figure 25] FIG. 10 is a diagram for explaining an example of STA method 6. [Figure 26] A diagram showing the relationship between the three NAV states, whether or not a response to a trigger frame can be made, and whether or not a MAP can be transmitted in STA method 6. [Figure 27] FIG. 10 is a diagram showing an example of the format of a CF-End frame. [Figure 28] FIG. 10 is a diagram for explaining an example of STA method 7. [Figure 29] FIG. 2 is a functional block diagram of an example of an AP. [Figure 30] FIG. 1 is a diagram showing an example of the overall configuration of an STA or AP. [Figure 31] FIG. 2 is a diagram showing an example of the hardware configuration of a wireless LAN module. [Figure 32] FIG. 1 is a perspective view of an example of an STA. [Figure 33] FIG. 1 is a diagram showing an example of a wireless communication device mounted on a memory card. [Figure 34] FIG. 1 is a diagram showing an example of frame exchange during a contention period based on random access in a wireless LAN. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, embodiments will be described with reference to the drawings. The following description exemplifies devices and methods for embodying the technical concepts of the embodiments. The technical concepts of the embodiments are not limited to the structures, shapes, arrangements, materials, etc. of the components described below. Modifications that can be easily conceived by those skilled in the art are naturally included within the scope of the disclosure. For clarity of explanation, the drawings may schematically depict elements with different sizes, thicknesses, planar dimensions, shapes, etc., compared to the actual embodiment. Elements with different dimensional relationships or ratios may be included in multiple drawings. Corresponding elements may be designated by the same reference numerals in multiple drawings, and redundant description may be omitted. Some elements may be designated by multiple names, but these designations are merely examples and do not necessarily mean that these elements may be designated by other names. Furthermore, elements that do not have multiple names may also be designated by other names. In the following description, "connection" may include not only direct connection but also connection via other elements.

[0010] IEEE Std 802.11-2020 and IEEE Std 802.11ax-2021, known as wireless local area network (WLAN) standards, and IEEE 802.11-20 / 1935r44, dated September 23, 2021, which is the Specification Framework Document for IEEE Std 802.11be, the next-generation WLAN standard, are incorporated by reference in their entirety in this specification.

[0011] Hereinafter, the present embodiment will be described in detail with reference to the drawings.

[0012] <BSS、infrastructure BSS、ESS> FIG. 1 shows an example of a wireless communication system according to the first embodiment. In the IEEE 802.11 standard (including extended standards such as the aforementioned IEEE Std 802.11ax-2021, and the same applies hereinafter), the smallest unit of a wireless communication group is a basic service set (BSS). A BSS has a BSS identifier (BSSID). For example, in a broadcast frame transmitted to all terminals in a BSS, the BSSID is placed in one of the address fields of the transmitted data frame. A terminal that receives a data frame determines based on the BSSID whether the frame is intended for all terminals in the BSS to which the terminal belongs, and if so, performs processing such as extracting the payload of the data frame.

[0013] The IEEE802.11 standard defines two types of BSS configurations. One is a configuration in which a base station (AP; access point) establishes a BSS and terminals (STA; stations) connect to it. This is called an infrastructure BSS. The other is a configuration in which there is no AP and the BSS is formed only by STAs. This is called an independent BSS. In this embodiment, the BSS used is an infrastructure BSS.

[0014] In an infrastructure BSS (hereinafter referred to as a BSS unless specifically contrasted with an independent BSS), the BSSID is the MAC (medium access control) address of the AP. An AP is a type of STA, and in this specification, both are sometimes referred to as wireless communication devices. An AP has the function of enabling data transfer from another STA, which is the data source, to another STA, which is the data destination. An STA does not have this function. In this case, the other STA or the other STA does not necessarily have to be in the same BSS as the AP; it may be connected via another AP or connected to a wired LAN.

[0015] A system that connects an AP to other APs is called a distribution system (DS). Multiple APs can be connected to a DS, and the multiple APs connected by this DS form an extended service set (ESS). The identifier that identifies the same ESS is called a service set identifier (SSID).

[0016] In Figure 1, there are AP1 and AP2 as APs. AP1 accommodates STA11 and STA12 and forms BSS1. AP2 accommodates STA21 and STA22 and forms BSS2. BSS1 and BSS2 form an ESS.

[0017] <Wireless communication device> 2 shows an example of a wireless communication device according to the first embodiment. The wireless communication device includes a higher-level processing unit 10, a MAC processing unit 20, a PHY (Physical) processing unit 30, a MAC / PHY management unit 40, an analog processing unit 50, and an antenna 60. In FIG. 2, there is one analog processing unit 50 and one antenna 60, but a plurality of analog processing units 50 and a plurality of antennas 60 may be provided for multiplexed communication. The number of the plurality of analog processing units 50 and the number of the plurality of antennas 60 may be the same or different. For example, two or more antennas 60 may be commonly connected to one analog processing unit 50.

[0018] The MAC processing unit 20, MAC / PHY management unit 40, and PHY processing unit 30 correspond to a form of a control unit or baseband integrated circuit that performs processing related to communication with other wireless communication devices. The analog processing unit 50 corresponds to a form of a wireless communication unit or RF (Radio Frequency) integrated circuit that transmits and receives signals via, for example, an antenna 60. The wireless communication integrated circuit according to this embodiment includes at least the former of a baseband integrated circuit and an RF integrated circuit. The functions of the baseband integrated circuit may be performed by software (program) running on a processor such as a CPU, by hardware, or by both software and hardware. The software may be stored in a memory such as ROM or RAM, or in a storage medium such as a hard disk or SSD, and read and executed by a processor. The memory may be a volatile memory such as SRAM or DRAM, or a non-volatile memory such as NAND or MRAM.

[0019] The upper processing unit 10 performs processing for the upper layer with respect to the MAC layer. The upper processing unit 10 can exchange signals with the MAC processing unit 20. Typical examples of the upper layer include the TCP / IP layer, the UDP / IP layer, and the application layer above them, but this embodiment is not limited to these. The upper processing unit 10 may include a buffer for exchanging data between the MAC layer and the upper layer. The wireless communication device may be connected to a wired infrastructure via the upper processing unit 10.

[0020] The MAC processing unit 20 performs processing for the MAC layer. As described above, the MAC processing unit 20 can exchange signals with the upper processing unit 10. Furthermore, the MAC processing unit 20 can exchange signals with the PHY processing unit 30. The MAC processing unit 20 includes a MAC common processing unit 70, a transmission processing unit 80, a reception processing unit 90, and a memory 94. The memory 94 is connected to the MAC common processing unit 70, the transmission processing unit 80, and the reception processing unit 90. The memory 94 stores data necessary for processing by the MAC common processing unit 70, the transmission processing unit 80, and the reception processing unit 90. If the functions of the MAC processing unit 20 are performed by software, the memory 94 also stores the software for the MAC processing unit 20.

[0021] The MAC common processing unit 70 performs processing common to transmission and reception at the MAC layer. The MAC common processing unit 70 is connected to the upper processing unit 10, the transmission processing unit 80, the reception processing unit 90, and the MAC / PHY management unit 40, and exchanges signals with each of them.

[0022] The transmission processing unit 80 and the reception processing unit 90 are connected to each other. The transmission processing unit 80 is connected to the MAC common processing unit 70 and the PHY processing unit 30, respectively. The reception processing unit 90 is connected to the MAC common processing unit 70 and the PHY processing unit 30, respectively. The transmission processing unit 80 performs transmission processing at the MAC layer. The reception processing unit 90 performs reception processing at the MAC layer.

[0023] The PHY processing unit 30 performs processing for the PHY layer. As described above, the PHY processing unit 30 can exchange signals with the MAC processing unit 20. The PHY processing unit 30 is connected to an antenna 60 via an analog processing unit 50.

[0024] The MAC / PHY management unit 40 is connected to the upper processing unit 10, the MAC processing unit 20 (more specifically, the MAC common processing unit 70), and the PHY processing unit 30. The MAC / PHY management unit 40 manages MAC operations and PHY operations in the wireless communication device.

[0025] The analog processing unit 50 includes analog / digital and digital / analog (AD / DA) converters and RF circuits, and converts digital signals from the PHY processing unit 30 into analog signals of a desired frequency to transmit from the antenna 60, and also converts high-frequency analog signals received from the antenna 60 into digital signals. Note that although AD / DA conversion is performed by the analog processing unit 50 here, it is also possible to configure the PHY processing unit 30 to have an AD / DA conversion function.

[0026] In the wireless communication device according to this embodiment, the antenna 60 is included (integrated) as a component within one chip, so that the mounting area of ​​the antenna 60 can be kept small.

[0027] When transmitting a signal to the wireless medium, the PHY processing unit 30 receives a MAC frame from the transmission processing unit 80. The PHY processing unit 30 converts the MAC frame into a PHY packet by adding a preamble and a PHY header, encoding, modulating, and other processes. The analog processing unit 50 converts the PHY packet, which is a digital signal, into an analog signal of a desired frequency. The antenna 60 radiates the analog signal from the analog processing unit 50 to the wireless medium. During signal transmission, the PHY processing unit 30 outputs a signal indicating that the wireless medium is busy to the MAC processing unit 20 (more precisely, the reception processing unit 90).

[0028] The PHY processing unit 30 may perform processing related to at least one of uplink multi-user MIMO (DL-MU-MIMO) and downlink multi-user MIMO (DL-MU-MIMO), which are extensions of MIMO technology. In UL-MU-MIMO, an AP simultaneously receives streams transmitted from multiple STAs using spatial multiplexing (simultaneously in the same frequency band) using multiple antennas, and separates the received signals into frames for each STA by MIMO demodulating the received signals. This allows the AP to receive frames simultaneously transmitted from multiple STAs using the same frequency band. In DL-MU-MIMO, an AP transmits streams to multiple STAs using spatial multiplexing using multiple antennas, and each STA separates the received signals into frames by MIMO demodulating them, and receives the frames addressed to that STA. This allows the AP to simultaneously transmit frames to multiple STAs using the same frequency band.

[0029] When receiving a signal from a wireless medium, the analog processing unit 50 converts the analog signal received by the antenna 60 into a baseband signal that can be processed by the PHY processing unit 30, and then converts it into a digital signal. The PHY processing unit 30 receives the digital received signal from the analog processing unit 50 and detects its reception level. The detected reception level is compared with a carrier sense level (threshold value). If the reception level is equal to or greater than the carrier sense level, the PHY processing unit 30 outputs a signal indicating that the medium (CCA; clear channel assessment) is busy to the MAC processing unit 20 (more precisely, the reception processing unit 90). If the reception level is less than the carrier sense level, the PHY processing unit 30 outputs a signal indicating that the medium (CCA) is idle to the MAC processing unit 20 (more precisely, the reception processing unit 90).

[0030] The PHY processing unit 30 extracts the payload from the received signal by demodulating it and removing the preamble and PHY header. In the IEEE 802.11 standard, this payload is called a PSDU (physical layer convergence procedure (PLCP) service data unit) on the PHY side. The PHY processing unit 30 passes the extracted payload to the reception processing unit 90, which handles it as a MAC frame. In the IEEE 802.11 standard, this MAC frame is called an MPDU (medium access control (MAC) protocol data unit). Additionally, the PHY processing unit 30 notifies the reception processing unit 90 when it starts receiving the received signal, and also notifies the reception processing unit 90 when it has finished receiving the received signal. Furthermore, if the PHY processing unit 30 successfully decodes the received signal into a PHY packet (if no errors are detected), it notifies the reception processing unit 90 of the end of reception of the received signal and passes a signal indicating that the medium is idle to the reception processing unit 90. When the PHY processing unit 30 detects an error in the received signal, it notifies the reception processing unit 90 of the error detection with an appropriate error code according to the type of error. Furthermore, when the PHY processing unit 30 determines that the medium has become idle, it notifies the reception processing unit 90 of a signal indicating that the medium is idle.

[0031] The MAC common processing unit 70 mediates the transfer of transmission data from the upper processing unit 10 to the transmission processing unit 80, and the transfer of reception data from the reception processing unit 90 to the upper processing unit 10. In the IEEE 802.11 standard, the data in this MAC data frame is called an MSDU (medium access control (MAC) service data unit). The MAC common processing unit 70 also receives instructions from the MAC / PHY management unit 40, converts the instructions into ones suitable for the transmission processing unit 80 and reception processing unit 90, and outputs them.

[0032] The MAC / PHY management unit 40 corresponds to, for example, the SME (station management entity) in the IEEE802.11 standard. In that case, the interface between the MAC / PHY management unit 40 and the MAC common processing unit 70 corresponds to the MLMESAP (MAC sublayer managament entity service access point) in the IEEE802.11 standard. The interface between the MAC / PHY management unit 40 and the PHY processing unit 30 corresponds to the PLMESAP (physical layer management entity service access point) in the IEEE802.11 wireless LAN.

[0033] In addition, in FIG. 2, the MAC / PHY management unit 40 is depicted as if the functional unit for MAC management and the functional unit for PHY management are integrated, but they may be implemented separately.

[0034] <Connection method to BSS and start of data frame exchange> When the AP starts up the BSS, it periodically transmits beacon frames. In practice, since the beacon frames are transmitted using CSMA / CA (carrier sense multiple access with carrier avoidance), it does not have a strict fixed interval.

[0035] The beacon frame notifies the attributes of the BSS, the wireless communication capabilities of the AP, and the transmission time (timestamp) information for the STA to synchronize, and it is a broadcast frame. A broadcast frame is one in which all fields specifying the direct destination address (RA; receiver address) are set to 1. In the 802.11 standard, the RA is the first address field set when there are multiple address fields. The SSID may or may not be included in the beacon frame. The transmission form without including the SSID is called the stealth mode.

[0036] When an AP receives a probe request frame from a STA, it sends a probe response frame to that STA. Probe request frames are usually sent as broadcast frames. Probe response frames are unicast frames that basically convey the same information as beacon frames. A unicast frame is a frame that specifies the MAC address of a specific STA in the RA. A STA can also request more detailed information in a probe request frame. In that case, the AP adds the requested information to the probe response frame in addition to the same information as in the beacon frame and sends it. For example, if the STA specifies an additional element ID it requests in the probe request frame (requested using 9.4.2.10 Extended Request element in IEEE Std 802.11-2020), the AP adds the requested information to the probe response frame and sends it. Alternatively, if the STA includes a unique request in the probe request frame that is common among the same vendor (IEEE Std 802.11-2020, 9.4.2.218 Vendor Specific Request element), the AP may then include the requested information in a probe response frame and send it back. The STA can also include a specific SSID in the probe request frame. In this case, the AP with the matching SSID among the multiple APs that receive the probe request frame will send a probe response frame. The STA sends a probe request frame specifying an SSID based on information entered by the user. Therefore, if an AP in stealth mode with a matching SSID is within an area where it can receive the probe request frame, the STA can detect that AP.

[0037] By receiving a beacon frame or a probe response frame, the STA learns which APs it can connect to. If there are multiple APs to connect to, the STA selects one of them and attempts to connect to it.

[0038] In the IEEE802.11 standard, in order for a STA to connect to an AP and be able to exchange data frames with the AP, it is necessary to go through an authentication process and an association process.

[0039] During the authentication process, authentication frames are exchanged two or four times between the STA and the AP. The authentication process begins when the STA sends an authentication frame to the AP. The authentication frame is a unicast frame. The party that receives the authentication frame sends an Ack frame. If the receiving party then sends an authentication frame, it must re-acquire access rights before sending the authentication frame. Four exchanges are required when using WEP (wired equivalent privacy). However, due to its vulnerabilities, WEP is no longer used, so the process is usually completed in two exchanges: from the STA to the AP and from the AP to the STA. Four exchanges are not usually required. The authentication frame from the AP to the STA contains a status code field. The status code notifies the STA whether the AP will accept the request from the STA. If the AP accepts the request, it places a 0 in the status code field, indicating SUCCESS. If the AP does not accept the request, it can notify the STA of the reason for the rejection by putting a value other than 0 in the Status Code field. Examples of values ​​other than 0 include 1, which is used when rejecting without specifying a specific reason, and 13, which is used when rejecting with a reason given that the STA does not support a specific authentication algorithm specified by the AP.

[0040] In other words, if the authentication process initiated by the STA is successful, that is, if the AP places 0 in the Status Code field of the authentication frame, the STA then begins the association process. The association process begins when the STA sends an Association Request frame to the AP. The STA stores its wireless communication capabilities in the association request frame and can notify the AP of its capabilities by sending it. Both the association request frame and the association response frame are unicast frames, and the receiving side sends an Ack frame. When the AP receives an association request frame from the STA, it sends an association response frame to the STA. The association response frame contains the AP's wireless communication capability information as well as the Status Code field. If the Status Code field is 0 (SUCCESS), that is, the association response frame notifies the AP that the association request has been accepted, it contains an association identifier (AID), which identifies the STA within the BSS. The AP assigns an AID to each STA. Once an AID has been assigned, the STA is considered to have established a connection with the AP and can exchange data frames with the AP. When a STA is connected to the AP, the STA's AID is valid. The field that notifies the AID is the AID field, which consists of 16 bits. The actual valid range for AID is from 1 to 2007. If the AP sends a frame containing an AID field outside of the association process, it may use a value other than 1 to 2007 for the AID field. In that case, the AID field is used to specify the attributes of the target STA.

[0041] When a STA sends an association request frame in the reassociation process to reconnect from one AP to another, the same information exchange is performed using the same procedures as in the association process. The reassociation process differs from the association process in that when the STA sends a reassociation request frame to another AP to which it is requesting reconnection, the MAC address of the currently connected AP is added to the reassociation request frame. The other AP then sends a reassociation response frame in response to the reassociation request frame.

[0042] Once the STA is able to exchange data frames with the AP, it can connect to the authentication server via the AP, allowing it to apply encryption processing such as advanced security standard (AES) to the frames it transmits via a 4-way handshake procedure.

[0043] <MACフレーム> MAC frames are generated at the MAC layer. There are three basic types of MAC frames: management frames, data frames, and control frames. Some IEEE 802.11 extension standards also define extension frames.

[0044] The above-mentioned beacon frame, probe request frame, probe response frame, authentication frame, association request frame, association response frame, reassociation request frame, and reassociation response frame are classified as management frames within MAC frames. Management frames are used to manage communication links with other STAs.

[0045] The data frames mentioned above are classified as data frames within the MAC frame category. The data frames mentioned above are further divided into categories based on whether they support QoS (quality of service), whether they store only data, and whether they contain additional information such as an Ack frame. Data frames usually store data passed from a higher layer. However, as a special case, data frames also include data frames generated at the MAC layer that do not contain data. There are two types of data frames that do not contain data: Null frames and QoS Null frames.

[0046] The Ack frame mentioned above is classified as a control frame among MAC frames. Other response control frames include the BlockAck frame, the BlockAckReq frame that requests the transmission of a BlockAck frame, the RTS (request to send) frame that is sent at the beginning of a frame exchange to acquire the right to transmit in order to reduce the damage of retransmission, and the CTS (clear to send) frame that is sent as a response to an RTS frame or at the beginning of a frame exchange to acquire the right to transmit when no response is required from the destination. Control frames are used to control the transmission and reception (i.e., exchange) of management frames and data frames with other wireless communication devices.

[0047] <MACフレームフォーマット> 3A shows the basic format of a MAC frame. Management frames, data frames, and control frames according to this embodiment are based on this frame format. This frame format includes the following fields: MAC header, Frame Body (variable length in octets), and FCS (Frame Check Sequence) (4 octets). Note that there may also be MAC frames that do not have a Frame Body field, such as the Null frame, which is a data frame that does not contain any data, and the QoS Null frame.

[0048] 3(b) shows the basic format of the MAC header. The MAC header includes the following fields: Frame Control (2 octets), Duration / ID (2 octets), Address 1 (6 octets), Address 2 (0 or 6 octets), Address 3 (0 or 6 octets), Sequence Control (0 or 2 octets), Address 4 (0 or 6 octets), QoS Control (0 or 2 octets), and HT (High Throughput) Control (0 or 4 octets).

[0049] Not all of these fields necessarily need to be present, and some MAC headers may not contain all of the fields. For example, some MAC headers may not contain the Address 3 or Address 4 fields. Other MAC headers may also not contain either or both of the QoS Control and HT Control fields. Other fields not shown in Figure 3 may also be added to the MAC header.

[0050] The Frame Control field contains two fields: Type and Subtype. The Type field broadly classifies the frame as a management frame, data frame, or control frame. The Subtype field then specifies the specific type of frame within that broad classification. For example, for control frames, the Subtype field contains information on the resolution, such as BlockAck frame, BlockAckReq frame, RTS frame, or CTS frame, as mentioned above.

[0051] The medium reservation time is entered in the Duration / ID field. If a station other than the station specified in the RA receives the frame, the receiving station uses the Duration / ID field as the time (NAV value) to set the network allocation vector (NAV), which will be described later. In the PS (power save)-Poll frame, which is used in power saving mode among control frames, the Duration / ID field does not contain the medium reservation time, but contains the AID assigned by the AP to the transmitting station. If a station other than the station specified in the RA receives the PS-Poll frame, the receiving station can determine that it cannot set the NAV value from the Duration / ID field by determining that the Type field indicates a control frame and the Subtype field indicates a PS-Poll frame. In this case, the STA sets the NAV value to the sum of a fixed time called the short interframe space (SIFS) and the estimated time that the Ack frame sent in response to the PS-Poll frame will occupy the medium. The STA calculates the estimated time that this Ack frame will occupy the medium from the transmission rate of the Ack frame estimated from the transmission rate of the PS-Poll frame and the Ack frame length (fixed at 14 octets).

[0052] The Address 1 field contains the receiver address (RA). The Address 2 field may not be present in some control frames. If present, the Address 2 field contains the transmitter address (TA). The Address 3 field does not exist in control frames. The Address 3 field exists in management frames and data frames. Depending on the use of the frame, the Address 3 field contains the BSSID, which is the BSS identifier, the TA, the final destination address (DA) of the data, or the source address (SA) of the data. Note that the BSSID may be a wildcard BSSID (all bits are 1) that covers all BSSIDs. The Address 4 field exists in data frames when transferring data from a STA between APs. The Address 4 field is used to notify the DA. The Address 4 field is used to notify the SA.

[0053] The Sequence Control field is divided into a Sequence Number subfield and a Fragment Number subfield. The Sequence Number subfield contains the sequence number assigned to the frame, and the Fragment Number subfield contains the corresponding fragment number for the frame if the data is divided into multiple fragments by fragmentation processing.

[0054] The QoS field is used to perform QoS control for transmission considering the priority of the frame. The HT Control field is a field introduced in the IEEE802.11n standard and is also used in the IEEE802.11ac standard and the IEEE802.11ax standard, which are successors to the IEEE802.11n standard. When corresponding to the IEEE802.11n standard, an HT variant is provided in the HT Control field. When corresponding to the IEEE802.11ac standard, a VHT variant is provided. When corresponding to the IEEE802.11ax standard, a HE variant is provided. Each variant is identified by the first 1 bit or 2 bits of the HT Control.

[0055] The Frame Body field is a field for putting information according to the type and subtype of the frame. In data frames other than the Null frame and the QoS Null frame, data is put in the Frame Body field. In management frames, according to the subtype, a plurality of fixed fields and a plurality of information elements are put in the Frame Body field. In control frames, there may be no Frame Body field according to the subtype, or a plurality of fixed fields may be included in the Frame Body field.

[0056] In the FCS field, FCS information is set as a checksum code used for error detection of the frame on the receiving side. Examples of FCS information include CRC (cyclic redundancy code).

[0057] <Explanation of NAV> In the IEEE802.11 standard, after a STA (including an AP) acquires medium access rights (hereafter referred to as transmission rights) through CSMA / CA, it obtains a time period during which it can occupy the medium (transmission opportunity; TXOP) and can then continuously exchange MAC frames with other STAs (including APs), although this is subject to restrictions such as QoS (quality of service) attributes.

[0058] In this TXOP, if a third-party STA other than the two STAs exchanging MAC frames transmits another MAC frame, the frame being exchanged between the two STAs (strictly speaking, the physical packet (physical protocol data unit; PPDU) that stores the frame) will collide with the MAC frame transmitted by the third-party STA. Therefore, a mechanism called NAV is provided to postpone the acquisition of the transmission right by the third-party STA until the end of the TXOP. When NAV is set in a third-party STA near the two STAs exchanging MAC frames, the TXOP, i.e., the radio resources, are protected.

[0059] In CSMA / CA processing, the reception processor 90 first checks whether the medium is free, i.e., performs carrier sensing. Here, carrier sensing encompasses both physical carrier sensing (CCA) related to busy / idle status and virtual carrier sensing based on the value of the Duration / ID field of a received frame or the type of received frame. Physical carrier sensing is triggered when a signal of -62 dBm or higher is detected on the physical medium. The latter mechanism for virtually determining that the medium is busy, or the period during which the medium is virtually busy, is called NAV. Note that when a channel is divided into multiple resource units (RUs) and transmission and reception is performed using some of these RUs, the reception processor 90 may apply carrier sense information based on the results of CCA performed on a channel-by-channel basis or NAV to those RUs. For example, for RUs belonging to a channel whose carrier sense information indicates idle, the reception processor 90 determines that the carrier sense is idle. When a STA (including an AP) receives a MAC frame addressed to another STA, it sets its NAV from the end of the physical packet containing the MAC frame. The reception processing unit 90 can set the NAV by writing the NAV value to the memory 94. Furthermore, when a new frame is received and the NAV to be set is longer than the current NAV, i.e., the end timing of the NAV set by the new frame is later than the end timing set in the current NAV, the reception processing unit 90 updates the current NAV value written in the memory 94 with the NAV value of the new frame. This update of the NAV value extends the end time of the current NAV to the end time of the NAV of the new frame.

[0060] The 802.11ax standard also includes the medium occupancy time indicated by the Duration / ID field in the TXOP field of the HE-SIG-A field in the physical (PHY) header of the newly defined 802.11ax physical packet (HE PPDU). When a STA (including an AP) receives an HE PPDU that it cannot decode and finds a valid value in the TXOP field, it derives the NAV value from that value. The HE-SIG-A field of the HE PPDU also contains a BSS Color field. This field allows a STA (including an AP) to distinguish between an HE PPDU within its own BSS and one sent from another BSS (overlapping BSS; OBSS). When a STA (including an AP) transmits an HE PPDU, it sets the BSS Color value set in its own BSS to the BSS Color field. The BSS Color value used in its own BSS is determined by the AP.

[0061] Furthermore, the 802.11ax standard provides a special NAV called intra-BSS NAV, which is applied when a received physical packet is a physical packet transmitted from the BSS itself, to enable uplink (UL) multi-user (MU) transmission. The intra-BSS NAV is distinguished from the NAV applied in other cases, i.e., when a received physical packet is a physical packet transmitted from the BSS itself or when it is not possible to determine whether the source of the received physical packet is the BSS itself or the BSS itself. The NAV applied in other cases is called basic NAV. A trigger frame is a frame instructing one or more STAs to transmit an UL MU. A trigger frame is a type of control frame. Figure 4 shows whether an UL MU can be transmitted in response to a trigger frame, depending on the relationship between the basic NAV setting and the intra-BSS NAV setting. Strictly speaking, the trigger frame contains a CS Required subfield that indicates whether carrier sensing is required, and if this subfield is set to "1", i.e., carrier sensing is required, the STA (including the AP) can transmit a UL MU packet if it determines, taking into account the setting status of these two NAVs, that it is able to respond to the trigger frame.

[0062] (1) If both basic NAV and intra-BSS NAV are not 0 (ie, they are set), it is not possible to acquire the transmission right and it is not possible to respond to the trigger frame (ie, it is not possible to transmit a UL MU).

[0063] (2) If the basic NAV is not 0 (i.e., it is set) and the intra-BSS NAV is 0 (i.e., it is not set), it is not possible to acquire the transmission right and it is not possible to respond to the trigger frame (i.e., it is not possible to transmit a UL MU).

[0064] (3) If the basic NAV is 0 (i.e., not set) and the intra-BSS NAV is not 0 (i.e., set), acquisition of the transmission right is not possible, but a response to the trigger frame is possible (i.e., UL MU transmission is possible).

[0065] (4) When both basic NAV and intra-BSS NAV are 0 (ie, not set), it is possible to acquire the transmission right and to respond to the trigger frame (ie, it is possible to transmit a UL MU).

[0066] The intra-BSS NAV is set when the BSSID of the STA (including AP) is set as the RA, TA, or BSSID field value, which is the address field of the MAC frame stored in the physical packet received by the STA (including AP). Alternatively, the STA (including AP) determines that the control frame stored in the physical packet received by the STA does not contain a TA but does contain an RA, that the value written in the RA is identical to the MAC address held by the TXOP holder that previously acquired the transmission right, and that the intra-BSS NAV was set when the TXOP holder was held (i.e., when a frame is sent from the TXOP holder of a TXOP recognized as intra-BSS communication, and the response frame to that frame does not contain a TA but contains an RA, and it can be determined that the RA is addressed to the TXOP holder). The intra-BSS NAV is also set when the STA (including AP) cannot decode the physical packet but can determine from the header information of the physical packet that the communication is within the same BSS. In this case, the header information of the physical packet is, for example, the BSS Color field mentioned above. Alternatively, the STA (including the AP) may determine that the communication from which it received a data frame is a communication within the same BSS based on the Partial AID field of the VHT-SIG-A field that is placed in the header of the physical packet (VHT PPDU) specified in the 802.11ac standard.

[0067] In the 802.11ax standard, an AP does not necessarily have to have these two NAVs. In other words, it is optional for an AP to have an intra-BSS NAV. If an AP does not have an intra-BSS NAV, it operates in the same way as an AP with a single NAV, as in the 802.11ac standard. The reason why the intra-BSS NAV is optional for an AP is that in the 802.11ax standard, it is always the AP that sends the trigger frame, and it is always the STA that receives it and transmits an UL MU in response. In other words, there is no case in which an AP responds to a trigger frame as shown in Figure 4.

[0068] <Trigger frame> FIG. 5 is a diagram illustrating an example of a format of a trigger frame.

[0069] The Duration field (2 octets) is the Duration / ID field described above.

[0070] The Common Info field (8 octets or more) is an area that indicates instruction information common to all STAs that are the target of UL MU transmission. In addition to the CS Required subfield mentioned above, the Common Info field also includes a Trigger Type subfield that indicates the type of trigger frame, and a UL Length subfield that indicates the time length of the UL MU packet.

[0071] The User Info List field (variable length in octet units) consists of multiple User Info fields. Each User Info field notifies control information for each individual STA. The AID of each individual STA is specified in the AID12 subfield within the User Info field. Also, when targeting STAs (associated STAs) that are already connected to the AP using UL orthogonal frequency division multiple access (UL OFDMA) based random access (UORA) without specifying a particular STA, "0" is set in the AID12 subfield. When targeting STAs (unassociated STAs) that are not connected to the AP using UORA without specifying a particular STA, "2045" is set in the AID12 subfield. In addition to the AID12 subfield, User Info fields include an RU Allocation subfield indicating which RU is allocated for transmission, a UL HE-MCS subfield indicating the modulation and coding scheme (MCS) used for transmission, and so on.

[0072] <Description of multi-AP> Multi-AP coordination (MAP) is a general term for the coordinated operation of multiple APs that make up an ESS.

[0073] For example, there is a cooperative operation where, after an AP acquires the right to transmit, it allocates a portion of the wireless resources of the TXOP it has acquired to one or more other APs. Here, the AP that acquires the right to transmit and allocates a portion of the wireless resources of the TXOP is the sharing AP, and the AP that receives the allocation of a portion of the wireless resources is the shared AP. Also, wireless resources refer to time or frequency.

[0074] Figure 6 shows an example of a MAP in which a sharing AP divides some of the TXOP resources (time) it has acquired and allocates them to multiple sharing APs, without dividing the TXOP resources (time) by frequency. In this case, the sharing AP allocates the TXOP to multiple sharing APs in a time-sharing manner. AP1, the sharing AP, acquires TXOP1 and uses a portion of that time, TXOP11, for itself. After TXOP11 ends, AP1 allocates the remaining portion of the time, TXOP12, to AP2, one of the sharing APs. After TXOP12 ends, AP1 allocates the remaining portion of the time, TXOP13, to AP2, another of the sharing APs. The frequency width of the TXOP allocated to the sharing APs is the same as the frequency width for which the sharing AP acquired the transmission right. For example, if the sharing AP acquires four 80 MHz channels consisting of consecutive 20 MHz channels, multiple sharing APs will each use the 80 MHz channels in a time-sharing manner.

[0075] The technique of using multiple reference frequency channels (20 MHz in the above example) together is called channel bonding. Figure 7 is a diagram for explaining an example of channel bonding.

[0076] Figure 7(a) shows an example of channel bonding for generating 40 MHz, 80 MHz, and 160 MHz bonded channels. A BSS can accommodate STAs supporting various channel widths, up to the maximum channel width permitted by the AP. The 20 MHz channel that all STAs (including the AP) that make up the BSS can operate on is the primary channel. Beacon frames are always transmitted on the primary channel. The secondary channel is the 20 MHz channel that is adjacent to the primary channel and, together with the primary channel, forms a 40 MHz bonded channel. Figure 7(a) shows an example in which the secondary channel is located on the right side (higher frequency side) of the primary channel. However, the arrangement of secondary channels is not limited to the example shown in Figure 7(a). The secondary 40 MHz channel (bonded channel) is comprised of two 20 MHz channels that are adjacent to the 40 MHz bonded channel consisting of the primary and secondary channels and, together with the 40 MHz bonded channel, form an 80 MHz bonded channel. Figure 7(a) shows an example in which the secondary 40 MHz channel is located on the left side (lower frequency side) of the primary channel. However, the arrangement of secondary 40 MHz channels is not limited to the example shown in Figure 7(a). Four 20 MHz channels, contiguous with an 80 MHz bonding channel consisting of a primary channel, a secondary channel, and a secondary 40 MHz channel, form a 160 MHz bonding channel, forming a secondary 80 MHz channel (bonding channel). Figure 7(a) shows an example in which the right side (higher frequency side) of the secondary channel is the secondary 80 MHz channel. However, the arrangement of secondary 80 MHz channels is not limited to the example shown in Figure 7(a). In 320 MHz channel bonding, a secondary 160 MHz channel (bonding channel) consisting of eight contiguous 20 MHz channels is connected to the previous 160 MHz bonding channel.

[0077] As shown in FIG. 7(b), the secondary channel and the secondary 80 MHz channel can be spaced apart to secure a total of 160 MHz channels, which is called an 80+80 MHz bonding channel.

[0078] FIG. 8 is a diagram illustrating a method for acquiring transmission rights in the example of channel bonding shown in FIG. 7(a). The method illustrated in FIG. 8 is applied when each AP or STA acquires transmission rights for a channel width greater than 20 MHz. FIG. 8(a) illustrates a method for acquiring transmission rights in the case of 40 MHz channel bonding. The following describes an example in which the source AP acquires transmission rights. The source AP performs CS on the primary 20 MHz channel. If it is able to acquire transmission rights for the primary 20 MHz channel, it checks the CS status of the secondary 20 MHz channel during the period going back PIFS (SIFS + 1 slot time) from that point. If it is able to acquire transmission rights for the secondary 20 MHz channel without detecting a busy state during the PIFS period, the source AP transmits on the 40 MHz bonded channel. If the secondary 20 MHz channel is detected as busy during the PIFS period, it is determined that it was not possible to acquire the transmission right on the secondary 20 MHz channel, and the transmitting AP may transmit only on the primary 20 MHz channel, or may resume operation by checking the CS status on the primary 20 MHz channel in order to attempt transmission on the 40 MHz channel again.

[0079] Figure 8(b) explains how to acquire the transmission right in the case of 80 MHz channel bonding. For example, if the sharing AP supports a maximum channel width of 80 MHz in its own BSS, it sets the primary channel as the base and one adjacent 20 MHz channel as the secondary channel, and the 40 MHz bonding channel consisting of the primary and secondary channels as the two adjacent 20 MHz channels as the secondary 40 MHz channels. The sharing AP notifies the STA how to set the secondary channel and secondary 40 MHz channel in a beacon frame or probe response frame. Even if the sharing AP only uses up to 40 MHz channels in the BSS, it also notifies the secondary channel. In addition, in the case of a 160 MHz channel or an 80+80 MHz channel, the sharing AP also notifies the secondary 80 MHz channel, and in the case of a 320 MHz channel, it also notifies the secondary 160 MHz channel. When the source AP attempts to acquire the right to transmit on the 80 MHz channel, it performs the same procedure as in the 40 MHz channel described above. Using the primary 20 MHz channel as a reference, it checks the CS status of each secondary 20 MHz channel and each secondary 40 MHz channel within PIFS from the time it determined it could acquire the right to transmit on the primary 20 MHz channel, and transmits at the largest channel width that satisfies the conditions. In other words, if the source AP detects a busy state on the secondary 20 MHz channel within PIFS, it transmits only on the primary 20 MHz channel, even if it does not detect a busy state on the secondary 40 MHz channel within PIFS. Alternatively, in hopes of securing a wider bandwidth at the next opportunity, the source AP may resume operation by checking the CS status on the primary 20 MHz channel to attempt transmission on the 80 MHz channel again. If the primary 20 MHz channel and secondary 20 MHz channel meet the CS conditions and the secondary 40 MHz channel detects a busy state within PIFS, it can transmit on the 40 MHz channel using the primary 20 MHz channel and secondary 20 MHz channel.In other words, to transmit on an 80 MHz channel, the CS conditions for the primary channel must be met and neither the secondary 20 MHz channel nor the secondary 40 MHz channel must detect a busy state within the PIFS. Similarly, when transmitting on a 160 MHz channel, the condition is that none of the secondary 20 MHz channel, secondary 40 MHz channel, nor secondary 80 MHz channel must detect a busy state within the PIFS, based on the primary 20 MHz channel. When transmitting on a 320 MHz channel, the condition is also that none of the secondary 20 MHz channel, secondary 40 MHz channel, secondary 80 MHz channel, nor secondary 160 MHz channel must detect a busy state within the PIFS, based on the primary 20 MHz channel. While the above is the basics of CS using channel bonding, it is also possible to use a technique called puncturing, whereby wideband channels are CSed in 20 MHz subchannel units and some busy 20 MHz channels are not transmitted. There are two methods for transmitting physical packets using puncturing: puncturing the physical header and transmitting it as a single physical packet (puncture packet), or omitting transmission on some 20 MHz subchannels and transmitting the same physical packet on the remaining 20 MHz subchannels (duplicate packet). This method makes it easier to acquire wideband transmission rights. Even when using puncturing, the transmission right must be acquired on the primary 20 MHz channel. When transmitting a physical packet using puncturing, the physical header indicates which 20 MHz channels have been punctured. The combination of punctured 20 MHz subchannels may be limited. This allows for the transmission on any 20 MHz subchannel to be determined by obtaining the physical header on any of the 20 MHz subchannels. APs and STAs notify each other whether they can receive and decode punctured physical packets (APs notify in beacon frames or probe response frames, and STAs notify in association request frames or reassociation request frames), and transmit physical packets only to those that can.In MAP, a source AP can transmit a punctured physical packet if the destination AP can receive the punctured physical packet.

[0080] Figure 9 shows an example of MAP in which a sharing AP divides a portion of the TXOP resources (time) it has acquired by itself by frequency and allocates them to multiple sharing APs. In this case, the sharing AP allocates the TXOP to multiple sharing APs by frequency allocation. AP1, the sharing AP, acquires TXOP1 and uses a portion of that time, TXOP11, for itself. After TXOP11 ends, AP1 allocates TXOP12 with a first frequency width obtained by dividing the frequency width of TXOP12 for the remaining portion of the time to AP2, one of the sharing APs, and allocates TXOP12 with a second frequency width to AP3, another of the sharing APs. The total frequency width allocated to each sharing AP is the same as or narrower than the frequency width for which the sharing AP acquired the transmission right, i.e., it is equal to or smaller than the frequency width for which the sharing AP acquired the transmission right. Naturally, the frequencies allocated to each sharing AP are within the frequency range for which the sharing AP acquired the transmission right. This means that the TXOP, which is the period during which the transmission right is acquired, also extends in the frequency direction, and since the sharing AP's TXOP1 protects a certain frequency bandwidth, frequencies within that bandwidth can be shared with other APs. For example, in Figure 9, if the sharing AP1 acquires an 80 MHz channel, it allocates 40 MHz to the sharing AP2 and 40 MHz to the sharing AP3. In this case, the total frequency allocated to AP2 and AP3 is 80 MHz, the same as the 80 MHz bandwidth acquired by AP1. Alternatively, AP2 could be allocated 40 MHz and AP3 20 MHz. In this case, the total frequency allocated to AP2 and AP3 is 60 MHz, which is narrower than the 80 MHz bandwidth acquired by AP1.

[0081] Of course, time-division MAP and frequency-division MAP may be combined. Of course, the sharing AP may share some of the radio resources of the TXOP with other APs, and the AP itself may also use some of the radio resources of the TXOP again, just like the other APs. For example, in FIG. 6, if there is time remaining before TXOP1 ends after TXOP12 and TXOP13, AP1 may use the TXOP again. Also, for example, in FIG. 9, TXOP12 is allocated to AP2 and AP3 by frequency division, but AP1 itself may use some of the frequency of TXOP12 and use TXOP12 in parallel with AP2 and AP3.

[0082] When allocating some of the radio resources of a TXOP to a sharing AP, the AP uses a trigger frame. In the conventional 802.11ax standard, a trigger frame is used by an AP to allocate some of the radio resources of a TXOP to a STA connected to that AP. Therefore, in this embodiment, when a sharing AP allocates some of the radio resources of a TXOP to a sharing AP, a different Trigger Type subfield is defined. Alternatively, a new control frame different from the trigger frame may be defined. Alternatively, a currently unused (reserved) field of the existing Trigger Type subfield, a Basic variant (called a Basic Trigger frame) generally used to instruct UL MU transmission, or a partial field may be redefined while maintaining backward compatibility so that it can be used in this embodiment in which an AP allocates some of the radio resources of a TXOP to another AP. Note that when modifying and reusing the Basic Trigger frame or defining a new Trigger Type subfield, the User Info field may be kept the same as in the existing case. In this case, for example, an identifier may be assigned to each AP to identify each AP within the ESS, and the AP's identifier may be placed in the AID12 subfield. In this case, since the AIDs used by normal STAs are 1 to 2007, and since values ​​with special meanings are defined as the AID12 subfield in existing trigger frames as described above, it is possible to avoid these values ​​when assigning AP identifiers. For example, when forming an ESS, the first AP that starts forming the ESS may assign identifiers to the other APs, or the identifiers of each AP may be specified manually via a user interface. When defining a new control frame, a similar AID12 subfield may be provided in the User Info field as described above, and the sharing AP to which the sharing AP will allocate some of the wireless resources of the TXOP may be notified using the AP identifier, or the MAC address of the sharing AP may be notified directly.While the former can shorten the field specifying the AP, a method for allocating identifiers for identifying APs is required.

[0083] In the shared destination AP to which a part of the wireless resources of the TXOP is allocated from the shared source AP, it is used as if the AP itself has acquired the transmission right among the wireless resources allocated to each. For example, in FIG. 6, during TXOP12, AP2 transmits data frames to STA21 and STA22 connected to AP2 and receives response frames such as Ack frames and BlockAck frames for them, or transmits trigger frames to STA21 and STA21 to cause each to transmit data frames and transmit response frames for them. Of course, if it fits within TXOP12, these continuous frame exchanges may be performed.

[0084] <Notification of MAP compatibility ability> When implementing MAP, in the shared source AP, it is necessary to grasp in advance that the candidate shared destination AP is an AP that can perform special operations related to NAV as described below. Also, in the AP that has become the shared destination, when reallocating wireless resources to the STAs of its own BSS under the MAP operation, it is necessary to grasp in advance that the candidate STAs are STAs that can perform special operations related to NAV as described below. That is, it is necessary to notify the availability of capabilities that are essential for MAP correspondence, such as special operations related to NAV as described below.

[0085] For example, if each AP includes a notification related to the ability to perform MAP operation in the beacon frame transmitted and the action frame for transmission to other APs and transmits them, the multiple APs constituting the ESS can grasp the availability of MAP operation for each other by receiving those frames.

[0086] An action frame is also a type of management frame. The Subtype field of an action frame indicates "Action Frame." The Category subfield in the Action field located at the beginning of the Frame Body field of an action frame indicates the general category of the action frame. The Action Details subfield following the Category subfield further contains subfields that indicate the more specific type of action frame according to the Category subfield.

[0087] The capability of MAP operation is notified by using, for example, one of the information elements to be placed in the Frame Body field of a beacon frame or action frame. The information element notifying that MAP operation is possible may also contain notifications related to capabilities other than MAP operation. For example, there is an EHT Capabilities element as a field for notifying capabilities related to the 802.11be standard, and this may be placed here. Alternatively, a new information element may be defined to notify information related to MAP operation (and other information). In this case, a new identifier (Element ID, Element ID Extension) will be defined for this information element.

[0088] 10 shows an example of the format of an information element included in the Frame Body of a MAC frame. The information element includes an Element ID field (1 octet), a Length field (1 octet), an Element ID Extension field (0 or 1 octet), and an Information field (variable length in octets).

[0089] The Element ID Extension field is used when the Element ID number for identifying an information element reaches the upper limit of the number that can be expressed in one octet. Only when the Element ID takes the maximum value of "255", the Element ID Extension field is added, allowing a Subelement ID to be added to identify the information element.

[0090] The Element ID Extension field also has one octet, and in the wireless LAN standard that complies with the current 802.11 standard, a value of "0" in this field is reserved, and values ​​of "1" or greater are assigned to identify information elements, just like the Element ID. A unique value for identifying an information element is written here.

[0091] The Length field indicates the length (size) of the information element excluding the Element ID field and the Length field. The Information field indicates the content of the information.

[0092] When a STA connected to an AP capable of MAP operation receives a partial reallocation of radio resources from a TXOP allocated to the STA (the AP to which the STA is connected) by a sharing AP, the STA may, depending on the conditions, perform a special NAV-related operation and notify the AP that it is capable of transmitting data frames, etc., i.e., that it is capable of transmitting data frames and other data within the TXOP shared by the other APs. When the STA notifies the AP in this way, it may include an information element indicating that MAP operation is possible in an association request frame or a reassociation request frame. Furthermore, such a STA can determine in advance whether an AP is capable of MAP operation by checking that a candidate AP includes a similar information element in a beacon frame or a probe response. Therefore, if the STA confirms that the AP to which it sends an association request frame or a reassociation request frame is capable of MAP operation, it may include the above information element in the association request frame or the reassociation request frame to notify the AP that it is capable of MAP operation. When an AP receives notification from a STA that it can transmit according to its own instructions within the TXOP allocated by another AP in an association request frame or reassociation request frame, the AP may again include an information element in the association request frame or reassociation response frame notifying that MAP operation is possible.

[0093] <map candidate set> As described above, when the number of APs capable of performing the MAP operation within the same ESS is limited, for example, and the number of APs actually performing the MAP operation in cooperation is limited, each AP performing the MAP operation needs to identify other APs that are candidates for cooperation in the MAP operation. Such a group of APs that are candidates for cooperation in the MAP operation will be referred to as a MAP candidate set. In the description part regarding the NAV operation described later, the part that describes APs within the same ESS etc. should be read as APs in the MAP candidate set when the number of APs capable of performing the MAP operation within the same ESS is limited.

[0094] <Example of an operation for an AP to be able to use a part of the wireless resources of the TXOP allocated from another AP> As described above, in the 802.11ax standard, it is optional for an AP to have an intra-BSS NAV, and it may only have the conventional single NAV.

[0095] Hereinafter, an example of the MAP operation for enabling an AP to use a part of the wireless resources of the TXOP allocated from another AP will be described. The MAP operation examples are classified into examples implemented in an AP and examples implemented in a STA. First, the MAP operation examples implemented in an AP will be described.

[0096] <AP operation example 1: Only one NAV> First, an operation example will be described in which when only one NAV is set by the reception processing unit 90, the transmission processing unit 80 can use a part of the wireless resources of the TXOP allocated from another AP regardless of the NAV.

[0097] In this case, when the reception processing unit 90 of the AP receives a frame addressed to its own AP from another AP that shares part of the wireless resources of the TXOP, the transmission processing unit 80 ignores the NAV and transmits within the allocated wireless resources. Fig. 11 is a diagram for explaining an example of AP operation example 1. In Fig. 11, AP1 is the sharing AP, and part of the wireless resources of the TXOP acquired by AP1 are allocated to sharing AP2. The frame that allocates part of the wireless resources of the TXOP to AP2 is shown in the figure as a MAP Transmission Sharing Trigger frame (MAP TXS TF). Here, a frame that allocates part of the wireless resources of the TXOP to another AP is considered a type of trigger frame. When allocating only to AP2, the RA of the MAP TXS TF is set to the MAC address of AP2.

[0098] For example, if the RA of the MAP TXS TF specifies the MAC address of the AP, when AP2 receives and decodes the MAP TXS TF, it can determine from the Type and Subtype fields that the MAP TXS TF is a trigger frame, which is a control frame, and from the Trigger Type subfield that the MAP TXS TF is used when the AP, which is the MAP, allocates some of the wireless resources of the TXOP to another AP. Therefore, AP2 satisfies the condition that it has received a frame addressed to its own AP from another AP that shares some of the wireless resources of the TXOP. Therefore, if AP1 transmits a frame addressed to a STA in BSS1, which AP1 configures, or transmits a CTS frame addressed to AP1, when AP2 receives the frame, even if the NAV is set, AP2 (the transmission processing unit 80) can ignore the NAV and use the TXOP according to the MAP TXS TF, and can perform transmissions such as reallocating the wireless resources allocated to the STA in the BSS configured by AP2 itself. A CTS frame addressed to the own STA (including the AP) is specifically called a CTS-to-self frame. Addressed to the own STA means that the RA is set to the MAC address of the own STA.

[0099] 11 shows an example in which AP2, upon receiving a MAP TXS TF, transmits a response frame (corresponding to a Transmission Sharing Response frame (TXS RSP) in FIG. 11) to AP1 to notify that it will use some of the allocated radio resources, and then transmits a trigger frame (corresponding to a Trigger frame (TF) in FIG. 11) to instruct STA21 and STA22 connected to AP2 to transmit UL MUs. For example, AP2 transmits a TXS RSP after a SIFS interval of the MAP TXS TF, and transmits a TF after a SIFS interval of the TXS RSP. For example, if it is difficult for AP2 to prepare to transmit a TXS RSP in a SIFS interval, AP2 negotiates with AP1 in advance the adjustment time required by AP2, and when AP1 transmits the MAP TXS TF in a physical frame, it performs padding processing after the MAP TXS TF to match that adjustment time. This allows AP2 to gain processing time for transmission preparation while keeping the actual time between physical packets SIFS.

[0100] In order for AP2 to send a TXS RSP to AP1, the MAC header of the MAP TXS TF must contain an SA in addition to an RA, and the MAC address of AP1 must be set in the SA. AP2 copies the MAC address of AP1 set in the SA of the MAP TXS TF and sets it in the RA of the TXS RSP. It is desirable to include an SA in the TXS RSP to identify which AP is responding on the AP1 side, and AP2 sets its own MAC address in the SA when sending a TXS RSP to AP1.

[0101] Here, if AP2 determines that the MAC address of its own AP is set in the RA of the received frame and that the frame is a MAP TXS TF, it ignores the NAV and transmits the frame. Alternatively, the transmission condition may be further limited to when the source AP is an AP in the same ESS. To determine this, the TA of the MAP TXS TF can be used, as described above. Since AP1 already knows that AP2 is one of the APs constituting the same ESS, when AP2 receives a MAP TXS TF with AP2's MAC address in the TA, it can determine that the frame was sent by AP1 in the same ESS. Since some radio resources of the TXOP are used only when an AP in the same ESS has been allocated those resources, it is appropriate to further condition whether or not to transmit a TXS RSP frame on the basis that the MAP TXS RF is transmitted from one of the APs constituting the same ESS. This is because if the NAV has not been set before AP2 receives the MAP TXS TF, AP2 will not set the NAV if the MAP TXS TF is addressed to its own AP, and therefore AP2 will be able to transmit the TXS TF frame. However, even in this case, AP2 cannot send TF frames to STA21 and STA22. This is because, when it receives a frame addressed to its own STA (including AP), it does not set the NAV, but instead has a timer with a similar concept, and it knows that AP1, which initiated the TXOP (it is the TXOP holder), is in the middle of a TXOP, and should not attempt to acquire the right to transmit during that TXOP.

[0102] When AP1 allocates some resources of the TXOP to multiple APs, for example, AP2 and AP3, the RA of the MAP TXS TF is set to a broadcast address. Therefore, AP2 can recognize that the MAP TXS TF has allocated some radio resources of the TXOP to itself by, for example, checking that the MAP TXS TF has an identifier allocated to itself in the AID12 subfield of one of the User Info fields, just like a conventional trigger frame.

[0103] To allow the AP to easily identify that a received frame is from an AP in the same ESS, the SSID, which is the ESS identifier, may be included in the MAP TXS TF, as described above. The SSID can also be included in some management frames, but in those cases it is expressed in the form of an information element. This is because the SSID is variable in octet units, up to a maximum of 32 octets. Trigger frames are control frames and typically do not include information elements. This is to reduce the processing load when control frames are received. When storing fields whose length may vary, control frames do not include length information and extract the relevant field as in information elements, but instead include detailed types and special values ​​indicating the end of the field, making it possible to identify the field. Therefore, when including the SSID in the MAP TXS TF, it should be placed at the end of the frame body (before the FCS field), for example. Of course, if a configuration that allows for the inclusion of length information and an SSID value is acceptable, this is also acceptable. Alternatively, a 6-octet value can be defined as the ESS identifier, separate from the SSID (e.g., ESSID), similar to the MAC address. If the ESSID is used, it must be publicly known within the same ESS in advance.

[0104] Alternatively, in order for an AP to easily grasp that it is from the same ESS, a new identifier different from the SSID for identifying the same ESS, such as a BSS Color field, may be provided. In this case, the concept of putting an identifier for identifying the same ESS into, for example, a BSS Color field is basically followed. Usually, it is used to identify whether it is its own BSS, but for a certain value, it is used to notify that it is the same ESS. The ESS color value is determined by some method among the APs within the same ESS and shared among the APs within the same ESS. For example, one AP that starts the configuration of the ESS, etc., may determine the ESS color value, or the user may determine it and input it to each AP via a controller or the like. Also, like the conventional BSS color, the value may be changed midway.

[0105] Note that in AP operation example 1, when AP2 is allocated a part of the wireless resources of the TXOP, one of the STAs already connected to AP2 has acquired the transmission right, and in the case where there is intra-BSS communication and AP1 does not detect it. In this case, since AP2 may transmit ignoring the NAV, there is a risk of collision between the communication of AP2 and the intra-BSS communication. Also, when there is communication within another BSS (not limited to the same ESS) detected by AP2 but not detected by AP1, again AP2 may transmit ignoring the NAV, so there is a risk of collision with the communication in another BSS. Next, AP operation example 2 for eliminating this risk of collision will be described.

[0106] <AP Operation Example 2: Two NAVs in the 802.11ax standard (basic NAV, intra-BSS NAV)> In AP operation example 2, AP2 has two NAVs: basic NAV and intra-BSS NAV. AP operation example 2 differs from AP operation example 1 in that when intra-BSS NAV is set, even if the AP receives a frame addressed to itself from another AP that shares part of the TXOP wireless resources, it cannot ignore the intra-BSS NAV and transmit within the allocated wireless resources. On the other hand, when only basic NAV is set, it can ignore basic NAV and transmit frames according to the allocated frame from the other AP, just like AP operation example 1.

[0107] FIG. 12(a) is a diagram illustrating an example of AP operation example 2 when only basic NAV is configured. Even if basic NAV is configured, if intra-BSS NAV is not configured, AP2 ignores basic NAV, receives a MAP TXS TF, which is an allocation frame for MAP operation, from AP1, transmits a TXS RSP in response, and then transmits TF to STA21 and STA22 connected to AP2. FIG. 12(b) is a diagram illustrating an example of AP operation example 2 when intra-NAV is configured. AP2 respects intra-NAV and does not transmit a TXS RSP in response to the MAP TXS TF, nor does it transmit TF to STA21 and STA22. If intra-NAV ends midway through the MAP TXS TF and intra-NAV is not configured when determining whether to transmit a TXS RSP after a fixed time period for the MAP TXS TF (for example, after SIFS, as with normal TF transmission), AP2 may transmit the TXS RSP, even if basic NAV is configured, because the situation is the same as FIG. 12(a).

[0108] Figure 13 shows the relationship between the setting states of the two NAVs in AP operation example 2 and whether some wireless resources can be used when some wireless resources of a TXOP are allocated from another AP (the item in the figure is expressed as "MAP transmission").

[0109] (1) If both basic NAV and intra-BSS NAV are not 0 (i.e., they are set), the transmission right cannot be acquired and MAP transmission is not possible (i.e., the allocated radio resources cannot be used). This case corresponds to (b) in Figure 12.

[0110] (2) If basic NAV is not 0 (i.e., it is set) and intra-BSS NAV is 0 (i.e., it is not set), acquisition of the transmission right is not possible, but MAP transmission is possible (i.e., the allocated radio resources can be used). This case corresponds to (a) in Figure 12.

[0111] (3) If basic NAV is 0 (i.e., not set) and intra-BSS NAV is not 0 (i.e., set), acquisition of the transmission right is not possible and MAP transmission is not possible (i.e., the allocated radio resources cannot be used). This case corresponds to (b) in Figure 12.

[0112] (4) If both basic NAV and intra-BSS NAV are 0 (i.e., not set), acquisition of transmission rights is possible, and MAP transmission is possible (i.e., the allocated radio resources can be used).

[0113] In this way, transmission becomes possible when wireless resources are shared by other cooperating access points.

[0114] In AP operation example 2, similar to AP operation example 1, the transmission conditions may be limited so that the AP can transmit MAP only when the source is an AP in the same ESS. Also, the method for determining whether the AP itself is assigned when the RA of the MAP TXS TF is a broadcast address is the same as in AP operation example 1. The method in AP operation example 1 that allows the receiving AP to easily determine that the signal is from an AP in the same ESS can also be applied to AP operation example 2.

[0115] In AP operation example 2, in a situation where intra-BSS communication is in progress and AP1 fails to detect it, the situation in AP operation example 1 where AP2 transmits and collides with intra-BSS communication can be avoided. On the other hand, in AP operation example 2, although there is communication within another BSS that is detected by AP2 but not by AP1, when AP1 transmits a MAP TXS TF, AP2 may ignore the basic NAV and transmit, potentially resulting in a collision with communication in another BSS. Next, AP operation example 3 for resolving this risk of collision will be described.

[0116] <AP operation example 3: Two NAVs (a new ESS NAV for MAP (which replaces the intra-BSS NAV of non-AP STAs within the BSS), basic NAV)> AP operation example 3 provides two NAVs: a NAV for MAP (referred to as ESS NAV) that is set when a frame within the same ESS (including its own BSS) is received, and a NAV (referred to as basic-NAV) that is set under other conditions (when a frame or packet that is not within the same ESS is received). In the IEEE 802.11ax standard, STAs set the intra-BSS NAV and the basic NAV. In AP operation example 3, the intra-BSS NAV is not set, and the ESS NAV is set without distinction whether a frame within its own BSS or a frame from another AP / STA within the same ESS is received. The ESS NAV is an extension of the intra-BSS NAV among the two NAVs set in the IEEE 802.11ax standard. The ESS NAV encompasses the intra-BSS NAV.

[0117] If the RA, TA, or BSSID field value of the received MAC frame contains the BSSID of its own BSS (i.e., the MAC address of the AP of its own BSS) (in the case of a frame from its own BSS) or contains the MAC address of an AP in the same ESS, the AP determines that it has received a frame from the same ESS and sets the ESS NAV.The AP also sets the ESS NAV if it determines that the received frame is a response frame to the TXOP holder of a TXOP that it recognizes as communication within the same BSS.

[0118] The determination method in this case is the same as that for intra-BSS NAV in the 802.11ax standard NAV. Also, the ESS color (discussed in AP Operation Example 1) can be included in the header of the physical packet, or the BSS colors of each BSS within the ESS can be mutually communicated in advance between BSSs in the existing BSS Color field, allowing the AP to understand the BSS color and determine that the frame or physical packet received by the AP is a frame or physical packet from communication within the same ESS. Methods for including the ESS color in the header of the physical packet include, for example, adding a specific value to identify the same ESS and placing it in the BSS Color field value, or creating a new ESS Color field. A similar determination can also be made when using the Partial AID field.

[0119] The AP sets basic NAV when the ESS NAV setting conditions are not met (including when it cannot determine whether the ESS is the same). Therefore, the basic NAV setting conditions here are slightly different from the basic NAV setting conditions for the two conventional NAVs. In AP Operation Example 2, the AP respected intra-BSS NAV, whereas in AP Operation Example 3, the AP respects basic NAV, which is a counterpart of ESS NAV. This is similar to the behavior of a STA respecting basic NAV when responding to a trigger frame from an AP when two conventional NAVs are present. In AP Operation Example 3, if basic NAV is set, the AP cannot ignore basic NAV and transmit within the allocated wireless resources, even if it receives a frame from another AP addressed to itself that shares part of the TXOP wireless resources. On the other hand, if only ESS NAV is set, the AP can ignore ESS NAV and transmit according to the assigned frame from the other AP.

[0120] FIG. 14(a) is a diagram illustrating AP operation example 3 when only ESS NAV is configured. AP2 ignores ESS NAV, transmits a TXS RSP in response to a MAP TXS TF from AP1, and then transmits TF to STA21 and STA22 connected to AP2. FIG. 14(b) is a diagram illustrating AP operation example 3 when basic NAV is configured. AP2 respects basic NAV, does not transmit a TXS RSP in response to a MAP TXS TF, and does not transmit TF to STA21 and STA22. If basic NAV ends midway through a MAP TXS TF and basic NAV is not configured at the stage of determining whether to transmit a TXS RSP after a fixed time period following the MAP TXS TF, the situation would be the same as FIG. 14(a) even if ESS NAV was configured, and AP2 may transmit.

[0121] Figure 15 shows the relationship between the setting states of two NAVs and whether some wireless resources can be used when some wireless resources of a TXOP are allocated from another AP (the item in the figure is expressed as "MAP transmission").

[0122] (1) If both basic NAV and ESS NAV are not 0 (i.e., they are set), the transmission right cannot be acquired and MAP transmission is not possible (i.e., the allocated radio resources cannot be used). This case corresponds to (b) in Figure 14.

[0123] (2) If basic NAV is not 0 (i.e., it is set) and ESS NAV is 0 (i.e., it is not set), the transmission right cannot be acquired and MAP transmission is not possible (i.e., the allocated radio resources cannot be used). This case corresponds to (b) in Figure 14.

[0124] (3) When basic NAV is 0 (i.e., not set) and ESS NAV is not 0 (i.e., set), acquisition of the transmission right is not possible, but MAP transmission is possible (i.e., the allocated radio resources can be used). This case corresponds to (a) in Figure 14.

[0125] (4) When both basic NAV and ESS NAV are 0 (i.e., not set), acquisition of the transmission right is possible, and MAP transmission is possible (i.e., the allocated radio resources can be used).

[0126] In AP operation example 3, the conditions under which MAP transmission is possible may be limited so that MAP transmission is only possible when the sender is an AP in the same ESS, as in AP operation example 1. Also, the method for determining whether the own AP is assigned when the RA of the MAP TXS TF is a broadcast address is the same as in AP operation example 1. The method for the receiving AP to easily determine that the received frame or physical packet in AP operation example 1 was sent from an AP in the same ESS can also be applied to AP operation example 3.

[0127] In AP operation example 3, when AP1 does not detect the situation where communication is being performed within the BSS of AP2, if AP2 detects this, even if the ESS NAV is set, it will transmit, so this transmission may collide with intra-BSS communication. On the other hand, in a situation where there is communication within another BSS outside the ESS that AP2 detects but AP1 does not, the situation where AP2 transmits and this transmission collides with communication within another BSS outside the ESS can be avoided. Next, AP operation example 4 that eliminates this risk of collision will be described.

[0128] <AP operation example 4: Three NAVs (intra-BSS NAV, ESS NAV, basic NAV)> Operational example AP4 is similar to AP operational example 3, but differs in that while AP operational example 3 included the reception of a frame from its own BSS as a condition for setting the ESS NAV, AP operational example 4 distinguishes between ESS NAV and intra-BSS NAV and respects both basic NAV and intra-BSS NAV. The conditions for setting the intra-BSS NAV are the same as those for setting the intra-BSS NAV for the two conventional NAVs. That is, when the AP demodulates a received packet to obtain a MAC frame and determines that the MAC header contains the same BSSID as its own BSS, it extracts the NAV value from the MAC header and sets the NAV based on that value. If the AP cannot demodulate the received packet and determines that a packet from its own BSS has been received based on the BSS color value in the physical packet header, it extracts the TXOP from the physical packet header and sets the NAV according to the TXOP. The AP sets the ESS NAV when it determines that the communication is not within its own BSS but is within the same ESS. The conditions for setting ESS NAV are the same as those for setting ESS NAV in AP operation example 3, except that the conditions for setting intra-BSS NAV are excluded. If neither the intra-BSS NAV nor the ESS NAV setting conditions apply, the AP sets basic NAV. In AP operation example 4, if either basic NAV or intra-BSS NAV is set, the AP does not transmit even if it receives a frame addressed to itself from another AP that shares part of the TXOP's wireless resources. On the other hand, if only ESS NAV is set, the AP can ignore ESS NAV and transmit according to the assigned frame from the other AP.

[0129] FIG. 16(a) is a diagram illustrating AP operation example 4 when only ESS NAV is configured. If neither basic NAV nor intra-BSS NAV is configured, AP2 ignores ESS NAV and transmits a TXS RSP in response to a MAP TXS TF from AP1, even if ESS NAV is configured. AP2 then transmits a TF to STA21 and STA22 connected to AP2. FIG. 16(b) is a diagram illustrating AP operation example 4 when at least one of basic NAV and intra-BSS NAV is configured. AP2 respects at least one of basic NAV and intra-BSS NAV, and does not transmit a TXS RSP in response to a MAP TXS TF, nor does it transmit a TF to STA21 and STA22. If basic NAV is configured but the MAP TXS TF ends midway, and basic NAV is not configured and only ESS NAV is configured at the stage of determining whether to transmit a TXS RSP after a fixed time period for the MAP TXS TF, the AP may transmit a TXS RSP, as in FIG. 16(a). Also, if intra-BSS NAV is set, but MAP TXS TF ends halfway, and TXS RSP is set to MAP If intra-BSS NAV is not set and only ESS NAV is set at the stage of determining whether to transmit after the fixed time of TXS TF, the AP may transmit, as it is the same as (a) in Figure 16.

[0130] Figure 17 shows the relationship between the setting states of the three NAVs and whether some wireless resources can be used when they are allocated from another AP (the item in the figure is expressed as "MAP transmission").

[0131] (1) If basic NAV, intra-BSS NAV, and ESS NAV are all non-zero (i.e., set), the transmission right cannot be acquired and MAP transmission is not possible (i.e., the allocated radio resources cannot be used). This case corresponds to (b) in Figure 16.

[0132] (2) If both basic NAV and intra-BSS NAV are not 0 (i.e., they are set), and ESS NAV is 0 (i.e., not set), the transmission right cannot be acquired and MAP transmission is not possible (i.e., the allocated radio resources cannot be used). This case corresponds to (b) in Figure 16.

[0133] (3) If both basic NAV and ESS NAV are not 0 (i.e., they are set), and intra-BSS NAV is 0 (i.e., they are not set), the transmission right cannot be acquired and MAP transmission is not possible (i.e., the allocated radio resources cannot be used). This case corresponds to (b) in Figure 16.

[0134] (4) If basic NAV is not 0 (i.e., it is set), and both intra-BSS NAV and ESS NAV are 0 (i.e., they are not set), the transmission right cannot be acquired and MAP transmission is not possible (i.e., the allocated radio resources cannot be used). This case corresponds to (b) in Figure 16.

[0135] (5) If basic NAV is 0 (i.e., not set) and both intra-BSS NAV and ESS NAV are not 0 (i.e., set), acquisition of the transmission right is not possible and MAP transmission is not possible (i.e., the allocated radio resources cannot be used). This case corresponds to (b) in Figure 16.

[0136] (6) If both basic NAV and ESS NAV are 0 (i.e., not set) and intra-BSS NAV is not 0 (i.e., set), acquisition of the transmission right is not possible and MAP transmission is not possible (i.e., the allocated radio resources cannot be used). This case corresponds to (b) in Figure 16.

[0137] (7) If both basic NAV and intra-BSS NAV are 0 (i.e., not set) and ESS NAV is not 0 (i.e., set), acquisition of transmission rights is not possible, but MAP transmission is possible (i.e., the allocated radio resources can be used). This case corresponds to (a) in Figure 16.

[0138] (8) If basic NAV, intra-BSS NAV, and ESS NAV are all 0 (i.e., not set), acquisition of transmission rights is possible and MAP transmission is possible (i.e., the allocated radio resources can be used).

[0139] In AP operation example 4, the conditions under which MAP can be transmitted may be limited so that MAP transmission is only possible when the source is an AP in the same ESS, as in AP operation example 1. Also, the method for determining whether the AP itself is assigned when the RA of the MAP TXS TF is a broadcast address is the same as in AP operation example 1. The method used in AP operation example 1 for the receiving AP to easily determine that the address is from an AP in the same ESS can also be applied to this AP operation example 4.

[0140] In the AP operation example, if AP1 does not detect that communication is taking place within AP2's BSS, AP2 will detect it but will not transmit because intra-BSS NAV is set, thereby preventing AP2's communication from colliding with the intra-BSS communication. Also, if AP2 detects communication in another BSS outside the ESS but AP1 does not detect it, even if AP1 transmits a MAP TXS TF to AP2, AP2 will not transmit because basic NAV is set, thereby preventing AP2 from transmitting and colliding with communication in another BSS outside the ESS.

[0141] Next, an example of the MAP operation implemented in the STA will be described.

[0142] <Example of the operation where the AP (local AP) to which the STA is connected is allocated a part of the wireless resources of the TXOP from another AP and further allocated by the local AP to the STA, and the STA uses it> Here, the operation of the STA under the shared AP is described. Since the STA compliant with the 802.11ax standard supports UL MU transmission, the realization example in the case of having three NAVs as in AP operation example 4, and conventionally, it is expected to have two NAVs, but the realization example in the case of having only one NAV and realizing the expected operation similar to the case of having two NAVs will be explained in order.

[0143] <STA operation example 1: The STA treats the frame transmitted by the AP within the same ESS as the same as the frame within the same BSS> In STA operation example 1, the STA has two NAVs, that is, the intra-BSS NAV and the basic NAV, and treats the frame transmitted by the AP within the same ESS as the same as the frame transmitted by the AP or STA within the same BSS. That is, when the STA receives a frame transmitted by an AP other than the AP to which the STA is connected and within the same ESS, the STA sets the intra-BSS NAV in the same way as when the local AP transmits.

[0144] To achieve this, the STA needs to know in advance which APs are within the same ESS. For this purpose, for example, the AP to which the STA is connected includes information about the APs within the same ESS in the beacon frame, probe response frame, and association response frame. For the notification of this information, for example, an information element is used. This information may be added to the information element for performing the capability notification related to the previous MAP operation, or a new information element for notifying the information of the APs within the same ESS may be provided.

[0145] 18 is a diagram illustrating an example of STA operation example 1. AP2 receives a MAP TXS TF from AP1, transmits a TXS RSP to AP1 as a response to the MAP TXS TF, and then transmits a TF to STA21 and STA22 connected to AP2. STA21 and STA22 each determine that the TF transmission from AP1 is a transmission within the same ESS, and configure intra-BSS NAV. STA21 and STA22 can therefore respond to the TF from AP2 and transmit data frames Data1 and Data2 to AP2, respectively, using UL MU. If basic NAV is configured in STA21 or STA22, STA21 or STA22 will not respond to the TF (strictly speaking, if the CS Required subfield of the TF is set to "1").

[0146] STA21 and STA22 connected to AP2 determine whether the normal intra-BSS NAV setting conditions are met by, for example, whether the address field of a received frame contains the same BSSID as the MAC address of the AP to which they are connected, as described above. However, STAs supporting MAP operation also consider whether the SA of a received frame contains the MAC address of an AP in the same ESS when determining whether the setting conditions are met, and set intra-BSS NAV if this condition is met. Furthermore, as described above, if ESS information is included in the header of a physical packet, the STA determines that the received frame is a frame in the same BSS based on this information and sets intra-BSS NAV. In Figure 18, the SA of the MAP TXS TF is AP1, and STA21 and STA22 recognize that AP1 is an AP in the same ESS as AP2, so STA21 and STA22 set intra-BSS NAV. Note that when the MAP TXS TF is sent by unicast from AP1 to AP2, AP2 is set in the RA, so the normal setting conditions are met and intra-BSS NAV is set. However, even if RA is set to the broadcast address in MAP TXS TF, because SA is AP1, STA21 and STA22 set intra-BSS NAV according to the determination of the setting conditions described above.

[0147] In STA operation example 1, even if AP1 does not share some of the radio resources of the TXOP with AP2, STA21 and STA22 will set intra-BSS NAV. Therefore, if AP2 does not detect the transmission detected by STA21 and STA22, STA21 and STA22 will send a response to the TF sent by AP2.

[0148] To solve this problem, for example, even when an AP in the same ESS transmits a MAP TXS TF, STA21 and STA22 do not set the intra-BSS NAV in all cases, and only set the intra-BSS NAV when an AP in the same ESS transmits a MAP TXS TF to their own AP. In this case, STA21 and STA22 determine whether the RA of the received frame is their own AP, and if the RA of the received frame is their own AP, set the intra-BSS NAV. Alternatively, if the RA of the received frame is a broadcast address, and there is a field that further specifies an individual STA / AP, such as the AID12 field, STA21 and STA22 determine whether their own AP is specified in that field, and if their own AP is specified, set the intra-BSS NAV. However, in these cases, if the sharing AP first secures the TXOP by transmitting a CTS-to-self frame or the like, the intra-BSS NAV is not set, and then some of the radio resources of the TXOP are allocated to the AP to which the STA is connected, and when the radio resources are further reallocated from the AP to which the STA is connected to the STA, the SAT cannot be transmitted. One example of a solution to this problem is the method described in STA Operation Example 4.

[0149] Another solution is for a STA to configure intra-BSS NAV if the received power level (e.g., reported as receive signal strength indicator (RSSI)) of a frame transmitted from another AP within the same ESS is below a certain value (at least -62 dBm, e.g., -72 dBm or -82 dBm). If the received power level is above that value, the STA configures basic NAV. This approach allows a STA to configure intra-BSS NAV if it receives a frame from an AP within the same ESS, even if the frame is not from its own BSS, and the received power level is low enough. Even if communications from different BSSs collide, communication can be expected to continue due to the high signal-to-interference ratio (SIR). This approach incorporates the concept of spatial frequency reuse (SR) from the 802.11ax standard.

[0150] In STA operation example 1, if AP1 allocates some of the radio resources of the TXOP to AP2 and then allocates other parts of the radio resources of the TXOP to AP3, AP3 and its subordinate STAs will set basic NAV in frame exchange with AP2 and its subordinate STAs. Therefore, if AP2 sets the Duration / ID field or TXOP field to a time that covers the end of AP1's TXOP, AP3 and its subordinate STAs will not be able to transmit because basic NAV is set. Therefore, if AP2 sets the Duration / ID field or TXOP field to cover only the time allocated by AP1, and STAs connected to AP2 also set it according to AP2, AP3 and its subordinate STAs will be able to transmit.

[0151] Next, a description will be given of an AP / STA operation example, which is a modification of STA operation example 1. The AP / STA operation example defines not only the operation of the STA but also the operation of the AP.

[0152] <AP / STA Operation Example: Applying intra-BSS NAV to Frames within an ESS> In this operation example, when a frame within the same ESS is received, intra-BSS NAV is set. In this case, the NAV setting condition is an extension of the part that was the self BSSID in the aforementioned normal intra-BSS NAV setting condition to all BSSIDs within the ESS. This NAV setting condition may be applied only to the STAs connected to the AP, or may be applied to both the AP and the STAs connected to it. Here, an operation example of setting intra-BSS NAV for both the AP and the STA will be described. Assume that the STA can respond to the TF from its own AP when only intra-BSS NAV is set. Assume that the AP can respond to the MAP TXS TF from other APs within the same ESS when only intra-BSS NAV is set.

[0153] Figure 19 is a diagram for explaining an example of the AP / STA operation example. To protect the TXOP, AP1 or a STA under it transmits a CTS-to-self frame to AP2 and the STAs under it, for example, at the beginning of a frame exchange. AP2 and STAs 21 and 22 under it determine from the CTS-to-self frame that AP1 is an AP within its own ESS and set intra-BSS NAV. AP2 receives the MAP TXS TF from AP1. When AP2 determines that the MAP TXS TF is a frame within its own ESS and only intra-BSS NAV is set, it ignores it, transmits a TXP RES to AP1, and transmits the TF to STAs 21 and 22 under it. Since the TF is a frame from AP2 within the same BSS, when only intra-BSS NAV is set, STAs 21 and 22 ignore it and transmit Data1 and Data2 to AP2 respectively.

[0154] The setting condition of intra-BSS NAV based on the received power level described in STA operation example 1 may be added to the AP / STA operation example.

[0155] In the case of the AP / STA operation example, even if AP1 allocates some wireless resources to AP2 and then continues to allocate some wireless resources of the TXOP to another AP3, the problem as in STA operation example 1 where AP2 sets the basic NAV until the end of the TXOP of AP1 and transmission cannot be performed by AP3 and the STAs under it does not occur. Therefore, it may be done as in STA operation example 1, but in the AP / STA operation example, AP2 sets the time to cover until the end of the TXOP of AP1 in the Duration / ID field or the TXOP field, and the STAs under AP2 also make settings according to AP2 so that AP3 and the STAs under it can perform transmission.

[0156] Also, in the AP / STA operation example, as shown in FIG. 19, even if the shared source AP, AP1, transmits a CTS-to-self frame at the beginning of a frame exchange to protect the TXOP before transmitting the MAP TXS TF, the intra-BSS NAV will be set, and STA21 and STA22 can respond to the subsequent TF from AP2 without problems.

[0157] <STA operation example 2: In the frame sharing the TXOP with other APs, the NAV is not set> In STA Operation Example 2, the STA has two NAVs: intra-BSS NAV and basic NAV. Normally, when a STA receives a frame in which an AP shares some of its TXOP radio resources with another AP, the STA sets basic NAV, or sets intra-BSS NAV if its own AP is set in RA. However, in STA Operation Example 2, the STA does not set these NAVs. Whether a STA has received a frame in which an AP shares some of its TXOP radio resources with another AP can be determined by the frame type. For example, if the frame is a MAP TXS TF, which is a type of trigger frame as in the example above, the Type subfield of the Frame Control field indicates a control frame, the Subtype subfield indicates a trigger frame, and the Trigger Type subfield of the Common Info field indicates a MAP TXS variant. The type of this variant can be used to determine the frame type, and a decision can be made as to whether or not to set the NAV based on the results of this determination.

[0158] 20 is a diagram illustrating an example of STA operation example 2. When STA21 and STA22 detect that the frame type is MAP TXS TF, they determine that the frame is one for which NAV is not set. Therefore, AP2 subsequently transmits a TXS RSP to AP1, and when STA21 and STA22 receive it, they set intra-BSS NAV as before. When AP2 subsequently transmits a TF to STA21 and STA22, STA21 and STA22 can transmit a response to the TF if only intra-BSS NAV is set.

[0159] In STA operation example 2, only the frame type, i.e., whether it is MAP TXS TF or not, is used to determine NAV setting, and it is not necessary to determine whether the frame is from an AP in the same ESS or whether the received frame is addressed to the AP itself (whether the AP itself is set in the RA or the AP itself is specified in the AID12 subfield). Simply checking the frame type simplifies the criteria for NAV setting.

[0160] Since the MAP TXS TF does not set the NAV, it is not possible to protect the TXOP. However, if the local AP subsequently transmits a TXS RSP, STA21 and STA22 will set the intra-BSS NAV in response to that transmission. Also, if part of the TXOP is allocated to another AP and that other AP transmits a TXS RSP, STA21 and STA22 will set the basic NAV in response to that transmission. As a result, the TXOP of the AP that transmitted the MAP TXS TF is ultimately protected.

[0161] Note that if a MAP TXS TF is sent to multiple APs and the response TXS RSP is an MU sent to the AP that sent the MAP TXS TF (this will be called an inter-AP MU), STA21 and STA22 may initially set basic NAV. This is assuming that when an ESS color is included in the header of the physical packet of an inter-AP MU, STA21 and STA22 will set basic NAV because the ESS color is not the BSS color of their own BSS. Once STA21 and STA22 set basic NAV, they will not be able to send a response to a subsequent TF from AP2.

[0162] One way to avoid this is for the STA to cancel the previous basic NAV (set the NAV value to 0) if it sets intra-BSS NAV, for example, by receiving a TF from its own AP SIFS after the end time of the basic NAV setting. If the STA has previously set basic NAV, receives an inter-AP MU within that period to re-update the basic NAV, and then sets intra-BSS NAV SIFS after the end time of the newly updated NAV, the STA will not cancel the basic NAV. In other words, the STA can cancel basic NAV only if it sets a new basic NAV in the SIFS immediately before the physical packet that set the intra-BSS NAV.

[0163] Alternatively, another way to avoid this is for the STA to set intra-BSS NAV instead of basic NAV if it can determine from the ESS color in the header of the physical packet that it has received a frame within the same ESS.

[0164] Alternatively, yet another avoidance technique is for the STA not to set the NAV in the inter-AP MU physical packet immediately after receiving the MAP TXS TF, just as it would if it had received the MAP TXS TF (in this case, it does not particularly set the basic NAV).

[0165] In STA operation example 2, if AP1 allocates some wireless resources to AP2 and then subsequently allocates some wireless resources to another AP, basic NAV will be set in frame exchanges in other BSSs, just as in STA operation example 1. To avoid this, each AP sets the Duration / ID field or TXOP field to cover only the time allocated by the sharing AP. STAs connected to each AP also set their settings according to that AP.

[0166] Also, in STA operation example 2, when the shared source AP, AP1, transmits a CTS-to-self frame at the beginning of a frame exchange to protect the TXOP before transmitting the MAP TXS TF, the CTS-to-self frame has only the RA in the address field, and since the RA is AP1, STA21 and STA22 set the basic NAV and then cannot respond to the TF from AP2. Regarding STA operation example 2, the purpose is to enable the STA to perform desired transmissions under the MAP with as simple NAV setting conditions as possible. As a solution to this problem, for example, it is compatible to prohibit the transmission of the CTS-to-self frame in the AP that transmits the MAP TXF TF, as described as a solution to a similar problem in STA operation example 4 below. However, other solutions in STA operation example 4 may also be applied.

[0167] <STA operation example 3: When the frame shares the TXOP with other APs and the own AP is included in the TXOP sharing target, do not set the NAV> In STA operation example 3, similar to STA operation example 2, the STA has two NAVs, the intra-BSS NAV and the basic NAV. However, different from STA operation example 2, in addition to the frame type, the STA also checks whether the target is the own AP.

[0168] FIG. 21 is a diagram for explaining an example of STA operation example 3. In this example, AP1 is transmitting the MAP TXS TF to AP2 and other APs. Therefore, the RA of the MAP TXS TF is the broadcast address. When STA21 and STA22 receive this MAP TXS TF, they check whether the own AP is the assigned target. That is, STA21 and STA22 check whether AP2, which is the own AP, is specified in any of the AID12 sub-fields in the User Info field of the received MAP TXS TF. If the received frame is the MAP TXS TF and the own AP is specified, STA21 and STA22 do not set either the basic NAV or the intra-BSS NAV. If this condition is not met, STA21 and STA22 perform the normal NAV setting.

[0169] For example, when STA21 and STA22 receive a MAP TXS TF, if they cannot confirm that their own AP is specified in the MAP TXS TF, they set basic NAV. Note that if AP2 is set in the RA of the MAP TXS TF (i.e., if it is assigned only to AP2), STA21 and STA22 can set intra-BSS NAV according to the normal NAV setting procedure. Therefore, STA21 and STA22 first set NAV according to the normal procedure if the received frame is a MAP TXS TF and the RA is a unicast address. That is, STA21 and STA22 set intra-BSS NAV if the RA is their own AP, and set basic NAV if the RA is another AP. If the received frame is a MAP TXS TF and the RA is a broadcast address, STA21 and STA22 check whether their own AP is assigned, and if their own AP is assigned, they do not set NAV, but if they cannot confirm that their own AP is assigned, they set basic NAV.

[0170] In STA operation example 3, it is not necessary to check whether the transmission is from an AP within the same ESS (i.e., check the TA of the MAP TXS TF), but it is necessary to check the RA and, depending on the RA settings, further check the allocation destination.

[0171] In STA operation example 3, if the received frame is a MAP TXS TF, addressed to multiple APs, and assigned to the local AP, the TXOP cannot be protected by that frame. It is expected that the subsequent TXS RSP transmission from the local AP will be an inter-AP MU, in which case STA21 and STA22 may temporarily set basic NAV. This is the same situation as presented in STA operation example 2. Once STA21 and STA22 set basic NAV, they will not be able to respond to subsequent TFs from AP2.

[0172] To avoid this, as in STA Operation Example 2, methods include canceling the newly set basic NAV immediately before setting intra-BSS NAV, setting intra-BSS NAV instead of basic NAV if the ESS color in the header of the received physical packet indicates that the physical packet was sent from the same ESS, or not setting NAV in the inter-AP MU immediately after a MAP TXS TF in which no NAV was set. In any case, if transmissions from the AP to the BSS continue, the STA sets intra-BSS NAV, or the STA becomes the target of transmission for the AP and has a timer that limits it to sending only response frames to the AP. This protects radio resources during the TXOP period assigned to the AP, and then sets basic NAV when the STA is assigned only to another AP, thereby protecting radio resources. STA21 and STA22 only have intra-BSS NAV set when they receive the TF from AP2, so they can send responses to the TF.

[0173] In STA operation example 3, if AP1 allocates some of the radio resources of the TXOP to AP2 and then allocates some of the radio resources of the TXOP to another AP, basic NAV will be set in the other BSS, as in STA operation example 1, so each AP will set the Duration / ID field or TXOP field to cover only the time allocated to the sharing AP, and STAs connecting to each AP will also set it according to that AP.

[0174] In STA Operation Example 3, if a frame exchange is performed that protects the entire TXOP in advance, such as when AP1, the source AP, sends a CTS-to-self frame at the beginning of the frame exchange, STA21 and STA22 will set basic NAV, which may result in a problem where they cannot respond to subsequent TFs from AP2. To avoid this, apply the same solution as in STA Operation Example 4, which will be described later.

[0175] <STA Operation Example 4: When receiving a frame that shares the TXOP with other APs and the own AP is included in the destination of the TXOP sharing, set the intra-BSS NAV> In STA Operation Example 4, when the STA receives a frame in which the source AP that shares the TXOP allocates a part of the wireless resources to the destination AP, and the AP connected to the STA is allocated as the destination of the part of the wireless resources, the STA sets the intra-BSS NAV. In STA Operation Example 3, when the received frame satisfies the same condition, the basic NAV is not set, but in STA Operation Example 4, the intra-BSS NAV is set.

[0176] FIG. 22 is a diagram illustrating an example of STA operation example 4. AP1, which has acquired the transmission right, transmits a MAP TXS TF to AP2 and other APs, allocating some of its wireless resources. When this MAP TXS TF allocates some of its wireless resources to multiple APs, a broadcast address is set in the RA, as in FIG. 21 for STA operation example 3. Therefore, when STA21 and STA22 determine that the received frame is a MAP TXS TF frame type, they next check whether their own AP, AP2, is the target of the allocation. That is, STA21 and STA22 check whether AP2 is specified in any of the AID12 subfields in the User Info field of the MAP TXS TF. If AP2 is specified, STA21 and STA22 configure intra-BSS NAV. If the conditions for configuring intra-BSS NAV are not met, STA21 and STA22 perform normal NAV configuration, i.e., configure basic NAV. Note that if MAP TXF TF is sent only to AP2 and RA is set to AP2, STA21 and STA22 will set intra-BSS NAV according to the normal NAV setting procedure. Therefore, as a procedure, STA21 and STA22 will first set NAV according to the normal procedure if the received frame is MAP TXS TF and the RA is a unicast address. That is, STA21 and STA22 will set intra-BSS NAV if the RA is for their own AP, and will set basic NAV if the RA is for another AP. If the received frame is MAP TXS TF and the RA is a broadcast address, STA21 and STA22 will check whether their own AP is assigned, and if so, will set intra-BSS NAV; if not, they will set basic NAV.

[0177] When STA21 and STA22 receive a MAP TXS TF that allocates wireless resources to their own AP, AP2, they set intra-BSS NAV, which allows them to respond to subsequent TFs from AP2.

[0178] In STA operation example 4, as in STA operation example 3, it is not necessary to confirm whether the transmission is from an AP within the same ESS (i.e., to check the SA of the MAP TXS TF), but it is necessary to check the RA and, depending on the RA settings, to further check the allocation destination.

[0179] Unlike STA Operation Example 3, STA Operation Example 4 can protect the TXOP using a MAP TXS TF frame even if the received frame is addressed to multiple APs and radio resources are allocated to the local AP. The subsequent TXS RSP transmission from the local AP is expected to be an inter-AP MU transmission, but in this case, STA21 and STA22 will set basic NAV if they determine that the BSS color in the MU packet header is different from their own BSS. This is the same situation as presented in STA Operation Example 2 or STA Operation Example 3 above.

[0180] To avoid this, there are methods adopted in STA Operation Example 2 and STA Operation Example 3. For example, the STA sets intra-BSS NAV in TF, but cancels the newly set basic NAV immediately before that. Alternatively, the BSS color is usually placed in the header of the physical packet, but in inter-AP communication, the BSS color is placed there instead. Alternatively, a separate field for the ESS color is provided, and if it is determined that the communication is using the same ESS, intra-BSS NAV is set instead of basic NAV. Alternatively, if the intra-BSS NAV set in MAP TXS TF and the basic NAV set by TXS RSP have the same duration (i.e., the NAV end points are the same), the NAV set by TXS RSP is set to intra-BSS NAV instead of basic NAV.

[0181] In the example of FIG. 22, the physical packet (containing the TXS RSP) that determines whether to change the NAV type from basic NAV to intra-BSS NAV is preceded by a physical packet (containing the MAP TXS TF) that sets the intra-BSS NAV to be compared. However, the physical packet containing the TF that follows the physical packet containing the TXS RSP may be used as the physical packet that sets the intra-BSS NAV to be compared. In this case, if the basic NAV set by the TXS RSP and the intra-BSS NAV set by the TF that allocates radio resources to the STAs of the own BSS (the timer maintained when allocated only to the own STA) have the same period (i.e., the NAV end points are the same), the NAV set by the TXS RSP is set to intra-BSS NAV instead of basic NAV. When the set periods are the same, the aforementioned constraints of immediately before or immediately after may be combined when changing basic NAV to intra-BSS NAV. In this case, whether the interval between two frames is, for example, a SIFS frame interval, is used to determine whether it is immediately before or immediately after. To rewrite a basic NAV to an intra-BSS NAV only if the previous NAV was a basic NAV, when STA21 and STA22 set a new basic NAV, they may store the start and end points of the NAV (the end point of the physical packet) in a temporary memory (for example, memory 94 in FIG. 2), and then determine whether the difference between the start point of the physical packet and the start point of the NAV when setting the intra-BSS NAV (or the timer to be held) next is SIFS, or if the difference is SIFS, whether the end points of the NAV will be the same. If these two conditions are met, STA21 and STA22 may not set the basic NAV, but may set the basic NAV if they are not met.Alternatively, when STA21 and STA22 newly set basic NAV, they may store the end point of the NAV in a temporary memory, for example. When the frame interval with the next physical packet becomes SIFS or more (the processing time for comparison and setting may be added), they delete the stored information and confirm the basic NAV setting. If there is remaining information for comparing the end point of the inter-BSS NAV (or the timer held) of the next physical packet, they may determine whether the end points of the NAV are the same. If they are the same, they do not set basic NAV, and if they are not the same, they may set basic NAV. In either case, a mechanism for storing information in some temporary memory is required. This allows the allocated radio resources to be protected during the TXOP period allocated by the own AP, and furthermore, when some radio resources of the TXOP are subsequently allocated only by other APs, basic NAV is set, thereby protecting the allocated radio resources.

[0182] In this STA operation example 4, if AP1 allocates some wireless resources to AP2 and then subsequently allocates some wireless resources to another AP, basic NAV will be set in the other BSS, as in STA operation example 1. Therefore, each AP sets the Duration / ID field and TXOP field so that they cover only the time allocated by the sharing AP, and STAs connected to each AP also set them according to that AP.

[0183] In this STA operation example 4, if AP1, the source AP, sends a CTS-to-self frame at the beginning of the frame exchange and then allocates part of the wireless resources to AP2, STA21 and STA22 will set basic NAV and will not be able to respond to the TF even if they receive it from AP2 afterwards.

[0184] In this case, the first solution is for STA21 and STA22 to set intra-BSS NAV if the received frame is, for example, a CTS-to-self frame transmitted from an AP in the same ESS. Note that if only a few APs in the same ESS are capable of MAP operation, STA21 and STA22 will set intra-BSS NAV when they receive a CTS-to-self frame transmitted from an AP in the MAP candidate set.

[0185] The second solution is for STA21 and STA22 to set basic NAV with a CTS-to-self frame, but if the same sender allocates radio resources for a TXOP to their own AP immediately afterward, i.e., after SIFS, they set intra-BSS NAV and cancel the previous basic NAV. This method of canceling the basic NAV once set is the same as the method of canceling basic NAV with a TXS RSP described above. Alternatively, the transmission of a CTS-to-self frame can be prohibited before transmitting a frame allocating some of the radio resources of the TXOP to another AP.

[0186] The third solution is to prohibit the transmission of a CTS-to-self frame before the transmission of a TXOP shared frame, which prohibits STA21 and STA22 from setting basic NAV and allows them to respond to TFs received from AP2.

[0187] The fourth solution is to use a CTS frame (CTS-to-ESSself frame) with the RA set to a multicast address for the AP group within the ESS instead of the CTS-to-self frame. In this case, it is necessary to inform in advance each STA connected to each AP of the multicast address for the AP group within the ESS. Also, when the STA receives a CTS frame, if the RA is set to the multicast address for the AP group within the ESS (i.e., it is a CTS-to-ESSself frame directed to the self-ESS), the intra-BSS NAV should be set. However, if the entire TXOP is protected in advance, not limited to the CTS-to-self frame, such as when AP1 exchanges frames first with the STA connected to AP1, STA21 and STA22 will set the basic NAV by their frame exchange, and with these methods, they cannot respond to the TF from the self-AP after the wireless resources are allocated to the self-AP. To solve this most simply, it is conceivable that AP1 sets a limit when allocating a part of the wireless resources of the TXOP to other APs. For example, even if the BSS configured by the source AP for sharing is the self-BSS, when the source AP uses the TXOP, or when the source AP transmits a TF to the STAs within the BSS configured by the source AP itself and those STAs transmit to the source AP, and those STAs use the TXOP, the periods of the TXOP used by the source AP and the destination AP for sharing are made the same. Alternatively, after using the TXOP for the period allocated to the destination AP, or if a part of the wireless resources of the TXOP is allocated to the destination AP, then the destination AP can be decreased but not increased hereafter. By doing so, it is possible to avoid the situation where the STAs under each AP cannot respond to the TF from the self-AP due to the basic NAV.

[0188] <STA operation example 5: When it is determined that wireless resources are allocated to the self-STA by the TF from the self-AP during the period of the NAV set by the frame sharing the TXOP from the AP, ignore the NAV and respond)> STA Operation Example 5 is an example of operation that can be used even when a STA has only one NAV. The STA sets its NAV when it receives a frame from the sharing AP requesting that the local AP share some of its TXOP's wireless resources. However, if the STA receives a TF from the local AP within a fixed time period after receiving the frame (MAP TXF TF) from the sharing AP requesting that the local AP share some of its TXOP's wireless resources (more precisely, the time the physical packet containing the TF ends on the wireless medium), and if the local STA is assigned the TF, the STA ignores the NAV and responds. Furthermore, the local AP can continue to ignore the NAV and respond to the TF within the TXOP specified by the TF (actually, the portion of the TXOP of the sharing AP assigned by the sharing AP). The fixed time is, for example, the sum of the frame occupancy time during which the sharing AP transmits a response to the sharing notification to the sharing AP and the frame intervals required before and after the TF. For example, if the frame occupancy time varies, the frame occupancy time can be set to its expected maximum value. In Figure 23, the fixed time must be at least the time it takes for AP2 to transmit a TXS RSP and determine that AP2 has started transmitting a TF. If the interval between frames is SIFS, and the start of TF transmission can be determined from the TXS RSP by SIFS + slot time (= PIFS), then the fixed time is at least 2 x SIFS + the occupied time of the physical packet storing the TXS RSP + slot time. Since the occupied time of the physical packet storing the TXS RSP varies if the transmission rate or frame length is variable, for example, the expected maximum time is used. For example, a value is specified for this fixed time.

[0189] Alternatively, instead of within a fixed time, the NAV may be ignored and a response may be made on the condition that there is no free space of SIFS or more during the period that the CCA recognizes as idle (i.e., the medium is not being used) (STA operation example 5a).

[0190] FIG. 23 is a diagram illustrating an example of STA operation example 5. If AP1 transmits a MAP TXS TF to AP2, and AP2 transmits a TXS RSP to AP1 after a SIFS, and then AP2 transmits a TF to STA21 and STA22 after that SIFS, the time between the MAP TXS TF and the TF is the sum of 2 × SIFS and the occupied time of the physical packet storing the TXS RSP. For example, if the occupied time of the physical packet storing the TXS RSP is fixed or set to an expected maximum value and used, STA21 and STA22 can respond to the TF if they receive the TF from their own AP within the fixed time of the MAP TXS TF. Furthermore, because all physical packets are exchanged at SIFS intervals, if all of them can be observed, there will be no CCA time longer than SIFS. If this condition is met, STAs can respond when they receive a TF from their own AP. If the condition is that the occupancy time of the physical packet storing the TXS RSP is within a fixed time, if the AP first reallocates some wireless resources to another STA and then reallocates them to the STA, the fixed time condition is not met, and the STA may not be able to respond to the TF. This situation does not occur in STA operation example 5a.

[0191] Alternatively, if the local AP responds to a frame that shares some of the radio resources of the TXOP with another AP (since MU physical packets cannot be expected to be decoded by the STA, it is only possible to know whether the local AP has responded in this way if the response frame is transmitted as an SU), or if the local AP has been assigned a frame that shares some of the radio resources of the TXOP with another AP, STA21 and STA22 may ignore the NAV within that TXOP and respond to the TF from the local AP (STA operation example 5b).

[0192] Alternatively, as described in STA operation example 4, if the end point of the NAV by a frame that shares some of the radio resources of the TXOP with the local AP is the same as the end point of the NAV set by the local AP within a fixed time thereafter or the timer held by the local AP, STA21 and STA22 may ignore the NAV and respond to the TF from the local AP (STA operation example 5c). In this case, the method related to determining whether the end points are the same is the same as described in STA operation example 4.

[0193] In the case where AP1 allocates some radio resources to a certain AP and then allocates some radio resources of the TXOP to another AP, in STA operation example 5 (determining whether to ignore the NAV depending on whether a TF addressed to the STA arrives within the fixed time of the MAP TXS TF), the STA cannot cancel the NAV once the fixed time has elapsed, and cannot respond to the TF from the own AP. To avoid this, for example, once the sharing AP allocates some radio resources of the TXOP to the sharing AP, it can decrease the number of sharing APs but cannot increase them.

[0194] In STA operation example 5a (when the condition is the presence or absence of a CCA idle period of SIFS or more), if all physical packets can be observed, there is no problem of not being able to respond to a TF from the own AP. Also, in STA operation example 5b (when it can be determined that the own AP has been assigned some radio resources of the TXOP from another AP, the NAV is ignored) and STA operation example 5c (when the determination is made using the end time of the NAV), there is no problem of not being able to respond to a TF from the own AP.

[0195] Even if the transmission of the CTS-to-self frame occurs before the transmission of a frame that shares some of the wireless resources of the TXOP with other APs, in STA operation example 5 (determining whether to ignore the NAV based on whether a TF addressed to the self-STA arrives within the fixed time of the MAP TXS TF), STA21 and STA22 can respond to the TF from the self-AP if, for example, the fixed time includes the occupancy time of the physical packet storing the CTS-to-self frame at the fixed time and also the SIFS before the transmission of a frame that shares some of the wireless resources of the TXOP with other APs. If the inter-frame interval between the CTS-to-self frame before the MAP TXS TF is SIFS, the fixed time is set so as to cover up to the time required for CTS-to-self frame transmission + SIFS. The fixed time requires 3 × SIFS + the occupancy time of the physical packet storing CTS-to-self + the occupancy time of the physical packet storing TXS RSP + the slot time. Taking into account that there is also the transmission of CTS-to-self, a longer value can be defined as the fixed time. However, in special cases, STA21 and STA22 cannot respond to the TF from the self-AP. For example, when a frame exchange is carried out between the sharing source AP and other STAs to protect the entire TXOP before the transmission of a frame that shares some of the wireless resources of the TXOP with other APs, STA21 and STA22 cannot respond to the subsequent TF from the self-AP. To solve this, there is the same avoidance method as in STA operation example 4 in such cases. Note that in STA operation example 5a (when the condition for responding by ignoring the NAV is the presence or absence of a CCA idle period longer than SIFS), STA operation example 5b (ignoring the NAV when it can be determined that the self-AP has been allocated some of the wireless resources of the TXOP from other APs), and STA operation example 5c (determining whether to ignore the NAV using the end point of the NAV), in such cases, there is no problem that STA21 and STA22 cannot respond to the TF from the self-AP.

[0196] <STA Operation Example 6: Three NAVs> In STA Operation Example 6, a third NAV, ESS NAV, is introduced to the STA in addition to the conventional basic NAV and intra-BSS NAV. ESS NAV is set when a received frame / physical packet is not a frame / physical packet within its own BSS (i.e., intra-BSS NAV does not apply) but is determined to be a frame / physical packet within the same ESS. A STA with two conventional NAVs sets basic NAV when a received frame / physical packet is not a frame / physical packet within its own BSS. In STA Operation Example 6, the STA adds an identification of whether a frame / physical packet outside its own BSS is within the same ESS. If the STA determines that a frame / physical packet outside its own BSS is within the same ESS, it sets ESS NAV; otherwise, it sets conventional basic NAV. Figure 24 is a flowchart showing an example of STA NAV setting in STA Operation Example 6. The STA determines whether the received frame / physical packet is a frame / physical packet within its own BSS (step S102). If the STA determines that the received frame / physical packet is a frame / physical packet within its own BSS, it sets intra-BSS NAV (step S104). If the STA does not determine that the received frame / physical packet is a frame / physical packet within its own BSS, it determines whether the received frame / physical packet is a frame / physical packet within its own ESS (step S106). If the STA determines that the received frame / physical packet is a frame / physical packet within its own ESS, it sets ESS NAV (step S108). If the STA does not determine that the received frame / physical packet is a frame / physical packet within its own ESS, it sets basic NAV (step S110).

[0197] The determination used to set the ESS NAV is basically the same as the method for setting the intra-BSS NAV described above. The information used to determine whether to set the intra-BSS NAV in STA operation example 6 is different from the information used to determine whether to set the intra-BSS NAV described above.

[0198] In STA operation example 6, if the STA can receive and decode a physical packet and extract the address field from the MAC frame stored in the physical packet, it determines whether the received frame is a frame within its own ESS based on those address fields. Alternatively, if the MAC frame does not have a TA but does have an RA, it determines whether the received frame is a frame within its own ESS based on the relationship between the value written in the RA and the MAC address of the TXOP holder that previously obtained the transmission right. The STA obtains in advance the MAC addresses of other APs within its own ESS (i.e., the BSSIDs of other BSSs within its own ESS) from the AP to which it connects.

[0199] If a STA cannot decode a received physical packet, it determines from the header of the physical packet whether the received physical packet is for communication within the same ESS and sets the ESS NAV accordingly. This determination can be made, for example, by using the BSS color, as described above. Alternatively, the ESS color value may be included in the BSS Color field, as described above. Alternatively, if a new physical packet is defined that includes an ESS Color field in addition to the BSS Color field, the determination may be made based on the value of the ESS Color field. In this case, the value of the TXOP field in the physical header is used to set either NAV. To identify a received packet as a physical packet used for communication within the same ESS without specifically defining an ESS color in the BSS Color field, the STA needs to know not only the BSS color of its own BSS but also the BSS colors of other BSSs in the same ESS. The STA can obtain this information from the AP to which it is connected. To determine the BSS colors of other BSSs in the same ESS, the AP can first receive notification of the BSS colors of other BSSs in the same ESS from other APs in the same ESS, for example, via a beacon frame or an action frame used between APs. For example, if an AP within the same ESS can notify other APs within the same ESS of the BSS color used by them, the AP does not need to obtain the BSS color from each of the other APs, thereby improving efficiency.

[0200] If an ESS color is specially defined and can be notified in the BSS Color field, the BSS Color field value is checked to see if it is the BSS color of the local BSS (step S102). If the BSS Color field does not contain the BSS Color of the local BSS, the BSS Color field is checked to see if it is (step S106). In the case of a new physical packet in which the ESS Color field is provided separately from the BSS Color field, the BSS Color of the local BSS is first determined to be set in the BSS Color field (step S102). If it is determined that the BSS Color of the local BSS is not set, the BSS Color of the local ESS is then determined to be set in the ESS Color field (step S106). This ESS color must also be determined and shared by some method between APs in the same ESS, and must be made known to the STAs connected to each AP. Furthermore, if basic NAV is not set, the STA can respond to a TF from the local AP.

[0201] FIG. 25 is a diagram illustrating an example of this STA operation example 6. STA21 and STA22 connected to AP2 receive the MAP TXS TF sent by AP1 to AP2 and other APs. In this case, the RA of the MAP TXS TF is a broadcast address, and the TA is set to AP1. STA21 and STA22 then detect that the TA of the MAP TXS TF is not the BSSID of their own BSS (i.e., the MAC address of their own AP), but is one of the BSSIDs of other BSSs that can be recognized as being in the same ESS (i.e., the MAC address of an AP other than their own AP that can be recognized as being in the same ESS). STA21 and STA22 then set the ESS NAV using the TXOP field value in the physical header of the physical packet upon the termination of the physical packet containing the MAP TXS TF on the wireless medium.

[0202] AP2 then sends a TXS RSP to AP1 as a MU in response to the MAP TXS TF. At that time, AP2 puts, for example, an ESS color in the BSS Color field of the physical header of the physical packet sending the MU. For example, when an AP is communicating between APs, it decides to put the ESS color in that field if the physical packet it uses has a BSS Color field. STA21 and STA22 detect that the BSS Color field of the physical header of the TXS RSP sent in the MU contains the ESS color of their own ESS, not the BSS color of their own BSS, and extract the TXOP field value from the physical header of the physical packet containing this TXS RSP. If the NAV set by the TXS RSP is longer than the ESS NAV previously set by the MAP TXS TF, STA21 and STA22 overwrite the ESS NAV with the TXOP field value in the physical header of the physical packet containing the TXS RSP. For example, AP2 sets the Duration / ID field of the TXS RSP and the TXOP field of the physical packet to the same value as the NAV set by the MAP TXS TF, that is, a value that covers up to the end of the TXOP acquired by AP1. In this case, the ESS NAV set by STA21 and STA22 is set by the MAP TXS TF up to the end of the TXOP acquired by AP1. Therefore, there is no need to overwrite the ESS NAV by the MAP TXS TF.

[0203] After that, when STA21 and STA22 receive a TF from AP2, only ESS NAV is configured in STA21 and STA22. When STA21 and STA22 receive a TF from AP2, they recognize that the TF is a frame within their own BSS, and since they are not the TXOP holder while receiving the TF, they configure intra-BSS NAV. In this case, STA21 and STA22 (and AP2 as well) recognize that the TF for which the TXOP holder configured ESS NAV is a TF from AP1. When the TF is received, ESS NAV and intra-BSS NAV are configured, but basic NAV is not configured, so STA21 and STA22 can transmit frames in response to the TF.

[0204] In STA operation example 6, even if AP1 allocates some of the radio resources of the TXOP to its own BSS or other APs, and then allocates some of the radio resources of the TXOP to AP2 or multiple APs including AP2, STA21 and STA22 will be set to ESS NAV instead of the conventional basic NAV during the time when some of the radio resources of the TXOP are allocated to other APs. Therefore, there is no problem in setting the Duration / ID field and TXOP field that protect the entire TXOP in AP1 or the AP (including AP2) that allocated some of the radio resources of that TXOP. In other words, even if TF is received from AP2 during that period, STA21 and STA22 can send a response.

[0205] Furthermore, even if AP1 first protects the TXOP using a CTS-to-self frame or the like, STA21 and STA22 will set ESS NAV instead of the conventional basic NAV, and will then be able to send a response even if they receive a TF from AP2.

[0206] Figure 26 shows the three NAV settings (basic NAV, intra-BSS NAV, and ESS NAV) that allow a STA to respond to a TF from its own AP (Trigger frame response @ non-AP STA). Figure 26 also shows the conditions under which a response can be sent when an AP, as shown in AP operation example 4 above, is allocated some radio resources in a TXOP from another AP (MAP response @ AP). On the STA side, by replacing the communication between MAPs where basic NAV was previously set with ESS NAV, the STA can respond to a TF transmission from its own AP.

[0207] (1) If basic NAV, intra-BSS NAV, and ESS NAV are all not 0 (i.e., set), acquisition of transmission rights is not possible, TF response is not possible (i.e., the STA cannot use the allocated radio resources), and MAP transmission is not possible (i.e., the AP cannot use the allocated radio resources).

[0208] (2) If both basic NAV and intra-BSS NAV are not 0 (i.e., they are set) and ESS NAV is 0 (i.e., not set), acquisition of transmission rights is not possible, TF response is not possible (i.e., the STA cannot use the allocated radio resources), and MAP transmission is not possible (i.e., the AP cannot use the allocated radio resources).

[0209] (3) If both basic NAV and ESS NAV are not 0 (i.e., they are set) and intra-BSS NAV is 0 (i.e., not set), acquisition of transmission rights is not possible, TF response is not possible (i.e., the STA cannot use the assigned radio resources), and MAP transmission is not possible (i.e., the AP cannot use the assigned radio resources).

[0210] (4) If basic NAV is not 0 (i.e., it is set) and both intra-BSS NAV and ESS NAV are 0 (i.e., not set), acquisition of transmission rights is not possible, TF response is not possible (i.e., the STA cannot use the allocated radio resources), and MAP transmission is not possible (i.e., the AP cannot use the allocated radio resources).

[0211] (5) If basic NAV is 0 (i.e., not set) and both intra-BSS NAV and ESS NAV are not 0 (i.e., set), acquisition of transmission rights is not possible, TF response is possible (i.e., the STA can use the assigned radio resources), and MAP transmission is not possible (i.e., the AP cannot use the assigned radio resources).

[0212] (6) If both basic NAV and ESS NAV are 0 (i.e., not set) and intra-BSS NAV is not 0 (i.e., set), acquisition of transmission rights is not possible, TF response is possible (i.e., the STA can use the assigned radio resources), and MAP transmission is not possible (i.e., the AP cannot use the assigned radio resources).

[0213] (7) If both basic NAV and intra-BSS NAV are 0 (i.e., not set) and ESS NAV is not 0 (i.e., set), acquisition of transmission rights is not possible, TF response is possible (i.e., the STA can use the assigned radio resources), and MAP transmission is possible (i.e., the AP can use the assigned radio resources).

[0214] (8) If basic NAV, intra-BSS NAV, and ESS NAV are all 0 (i.e., not set), acquisition of transmission rights is possible, TF response is possible (i.e., the STA can use the allocated radio resources), and MAP transmission is possible (i.e., the AP can use the allocated radio resources).

[0215] In this STA operation example 6, similar to STA operation examples 2 to 4, when setting the ESS NAV, the frame type of the received frame may be restricted to MAP TXS TF, or further restrictions may be added such that the self-AP is included in the destination. However, if this is done, when AP1 allocates some of the radio resources of the TXOP to different APs (or AP groups) in a time division manner as shown above, the basic NAV will be set in the STAs under the later-allocated AP, resulting in the inability to use the allocated radio resources. Also, the basic NAV will be set by the CTS-to-self frame, leading to the inability to use the allocated radio resources. Thus, some countermeasures or restrictions as described above become necessary.

[0216] <STA Operation Example 7: Introduction of a Frame for Truncating the basic NAV> Up to STA operation examples 1 to 6, by changing the operation on the NAV on the STA side from the conventional method, it is possible to respond and transmit to the TF from the self-AP under MAP communication. However, in STA operation example 7, a situation where it is not possible to respond and transmit to the TF from the self-AP by setting the basic NAV using the conventional method is solved by the AP transmitting a frame that resets the basic NAV to 0. Resetting the NAV, in another expression, is called truncating the TXOP.

[0217] There is a CF-End frame as a frame for resetting the NAV. The CF-End frame is a type of control frame. First, the operation when receiving this conventional CF-End frame will be explained.

[0218] <Conventional Operation of CF-End> Figure 27 shows an example of the format of a CF-End frame. A CF-End frame consists of a Frame Control field, a Duration field, two address fields, and an FCS. The Duration field is set to 0. The first address field is the RA field, which contains the address field of the destination, but in the CF-End frame it contains a broadcast address. The second address field is the BSSID (TA) field, which contains the MAC address of the STA (including the AP) sending the CF-End frame.

[0219] When a STA (including an AP) that manages only one NAV receives a CF-End frame, it resets the NAV if one is set. Specifically, the timing for resetting the NAV is the end of the physical packet that stores the CF-End frame. Note that, in an 802.11ax-compliant AP (HE AP) that manages only one NAV, the NAV should be reset unless the frame in which the set NAV was last updated was a physical packet within the own BSS and the physical packet storing the CF-End frame is determined to be from another BSS. Conversely, the NAV should be reset unless the frame in which the set NAV was last updated was a physical packet from another BSS and the physical packet storing the CF-End frame is determined to be from the own BSS.

[0220] When a STA (including an AP) that manages two NAVs, basic NAV and intra-BSS NAV, receives a CF-End frame, it resets the basic NAV if it determines that the physical packet storing the CF-End frame is from another BSS, and resets the intra-BSS NAV if it determines that the physical packet storing the CF-End frame is from its own BSS.

[0221] As mentioned above, the determination of whether a physical packet is from within the current BSS or from another BSS is made based on the BSS Color field in the physical header of the physical packet, or, if the MAC frame stored in the physical packet can be decoded, based on the address field of that MAC frame (and also taking into account past history, since the address field is restricted depending on the frame type).If a CF-End frame can be extracted, it can be determined whether the physical packet is from within the current BSS or from another BSS by comparing whether the MAC address of the AP written in the BSSID (TA) field of the CF-End frame is the same as the MAC address of the current AP.

[0222] As in the above-mentioned STA operation example 6, when an STA that manages the three NAVs, basic NAV, intra-BSS NAV, and ESS NAV, receives a CF-End frame, it resets the intra-BSS NAV if it determines that the physical packet storing the CF-End frame is within its own BSS, resets the ESS NAV if it determines that the physical packet storing the CF-End frame is not within its own BSS but is within the same ESS, and resets the basic NAV if it determines that the physical packet storing the CF-End frame is neither within its own BSS nor within the same ESS, i.e., is from outside the same ESS.

[0223] Whether or not a packet is within the same ESS can be determined based on the BSS Color field in the physical header of the physical packet, or, if the MAC frame stored in the physical packet can be decoded, the address field of the MAC frame, just as when determining whether or not a packet is within the same BSS.

[0224] Returning to the explanation of STA Operation Example 7, here we show a method for STAs that manage two NAVs to use a frame that resets the basic NAV so that the STA can send a response to the TF from its own AP under MAP.

[0225] In conventional CF-End frames, the BSSID (TA) field contains the MAC address of the AP itself. Therefore, when managing two NAVs, the CF-End frame is intended to be sent to reset the NAV of the AP itself, i.e., the intra-BSS NAV, and the basic NAV remains unchanged. An AP in one BSS cannot set the MAC address of another AP in the BSSID (TA) field and transmit it. Even if it were possible to set the MAC address of another AP in the BSSID (TA) field and transmit it, conventional CF-End frames would reset the basic NAV if they were determined to be from another BSS. This would reset the basic NAV not only of the AP and STAs connected to it that were assigned some of the wireless resources in the TXOP by the original AP, but also of all surrounding APs and their connected STAs.

[0226] Therefore, in STA operation example 7, a new frame is provided to limit the APs and STAs (reset targets) whose basic NAV will be reset. For convenience, this frame is called the CF-End2 frame. The CF-End2 frame, like the CF-End frame, is treated as a type of control frame. The CF-End2 frame is a different subtype from the CF-End frame.

[0227] The format of the CF-End2 frame can be the same as that of the CF-End frame. The Duration field is set to 0. However, unlike the CF-End frame, the RA field of the CF-End2 frame specifies the BSSID of the BSS for which basic NAV is to be reset. Because the RA field specifies the BSSID, it may be referred to as the BSSID(RA) field instead of the RA field. STAs belonging to a BSS with the same BSSID as the value specified in the RA field will reset basic NAV if it is set. Even if intra-BSS NAV is set in a STA in the target BSS, it will remain set without being reset. For example, transmission of CF-End2 frames can be restricted to APs only. In this case, the sending AP sets its own MAC address in the BSSID(TA) field. The receiving STA may reset basic NAV only if the BSSID(TA) field contains the MAC address of its own AP. Alternatively, if it is permitted for an AP within the same ESS to transmit CF-End2 frames targeting the BSSs of other APs, the receiving STA can reset its basic NAV even if the BSSID (TA) field contains the MAC address of another AP within the same ESS. In this case, the STA must know the MAC addresses of APs other than its own AP in the same ESS in advance, using the method described above. It is also possible to format the CF-End2 frame so that it only specifies the BSS for which the basic NAV is to be reset in the RA field, without including the BSSID (TA) field. In this case, the receiving STA will reset its basic NAV if the RA field matches the BSSID of its own BSS. However, this means that any STA can reset the basic NAV of other STAs.Therefore, a STA receiving a CF-End2 frame may check the frame's source address based on the BSSID (TA) field and reset basic NAV only if the BSSID (TA) field meets certain conditions (for example, if it is the AP itself, as described above, or if it is an AP of the ESS itself). To allow a STA receiving a CF-End2 frame to easily determine whether the AP is in the same ESS, a field for the ESS identifier may be added to the CF-End2 frame, or a field for this ESS ID may be included instead of the TA field. As described above, the ESS identifier is typically the SSID. Therefore, when including the SSID in a CF-End2 frame, which is a control frame, because the SSID has a variable length, it should be included at the end of the frame body, as described in AP Operation Example 1. Alternatively, if a configuration allowing for the inclusion of length information and an SSID value is permitted, the SSID can be included together with the length information. Alternatively, a fixed 6-octet ESSID can be defined separately from the SSID as the ESS identifier, and this ESSID can be used.

[0228] FIG. 28 is a diagram illustrating an example of STA operation example 7. STA operation example 7 is an example in which this CF-End2 frame is used to enable a STA to transmit a response to a TF from its own AP under MAP. AP1 transmits MAP TXS TF for AP2 and other APs. Assume that the RA field of the MAP TXS TF is a broadcast address and the TA field is set to AP1. In this case, STA21 and STA22 connected to AP2 can decode a physical packet containing the MAP TXS TF. Even though STA21 and STA22 can extract the MAP TXS TF, since neither the RA field nor the TA field contains the BSSID of their own BSS, they determine that the received physical packet is a physical packet from another BSS and set basic NAV.

[0229] AP2 then transmits a TXS RSP to AP1 in response to the MAP TXS TF from AP1. If the physical header of the physical packet containing the MU does not contain the BSS color of the BSS configured by AP2, STA21 and STA22 determine that the physical packet is also from another BSS and compare the duration set by the TXOP field value of the physical header with the basic NAV duration set in the previous MAP TXS TF to determine whether to set the TXOP field value of the physical header as basic NAV. If AP2 sets the TXOP field value of the physical header to the value obtained by subtracting the occupancy time of the physical packet containing the SIFS and TXS RSP frame from the Duration / ID field value in the MAP TXS TF, that is, if it is set to protect the same duration as the TXOP obtained by the MAP TXS TF, the end point of the basic NAV already set in STA21 and STA22 is the same as the end point of the NAV value indicated by the physical packet containing the TXS RSP frame, so STA21 and STA22 do not need to overwrite the basic NAV.

[0230] Next, AP2 reallocates the allocated wireless resources to STA21 and STA22, but before that, it sends a CF-End2 frame to reset the basic NAV of STA21 and STA22. Here, the BSS for which the basic NAV is to be reset is the BSS of AP2, so AP2 sets the BSSID of AP2's BSS (referred to as BSSID2 in the figure for convenience; BSSID2 is the MAC address of AP2) in the RA field of the CF-End2 frame. In Figure 28, the setting status of the RA field, i.e., BSSID2, is shown in parentheses around the CF-End2 frame. AP2 transmits the CF-End2 frame within the wireless resources allocated by AP1. Following the explanation above, STA21 and STA22 receive the CF-End2 frame and, upon determining that the BSSID of their own BSS is specified, reset the basic NAV setting to 0 at the end of the physical packet containing the CF-End2 frame.

[0231] After sending the CF-End2 frame, AP2 sends TF to reallocate radio resources to STA21 and STA22. Because the RA of the TF is a broadcast address and the TA is set to AP2, STA21 and STA22 determine that the physical packet containing the TF is a physical packet within their own BSS, and then set the intra-BSS NAV because the received frame is a TF, not a TXOP holder. Because the set NAV is intra-BSS NAV, STA21 and STA22 can respond to the TF by, for example, sending a data frame after a SIFS.

[0232] In Figure 28, AP2 sent a CF-End2 frame, but since the MAP TXS TF is also sent to APs other than AP2, other APs that received the MAP TXS TF also send TXS RSPs via MU transmissions and then similarly transmit a CF-End2 frame within their assigned radio resources. If different frequency channels are assigned to the APs by AP1, each AP can transmit a CF-End2 frame on its assigned frequency channel due to the different frequencies. STAs under each AP can receive the CF-End2 frame from their own AP if they are listening on their assigned frequency channel.

[0233] Given that wireless resources have already been allocated, it would be appropriate for the destination AP to send the CF-End2 frame. However, the source AP, AP1, may also send the CF-End2 frame (shown by the dashed line in Figure 28). In this case, AP1 must reset the basic NAV in the BSSs of other APs in addition to AP2's BSS (BSSID2). Therefore, the CF-End2 frame must be able to set multiple BSSIDs. Because the CF-End2 frame is a control frame, its frame length must be fixed, or the first half of the frame must have a constraint that allows the final frame length to be predicted in advance. Considering this, one method is to include a fixed number of RA fields. For example, while the CF-End frame has one RA field, CF-End frame 2 can include four RA fields, such as an RA1 field, an RA2 field, an RA3 field, and an RA4 field, allowing up to four BSSIDs to be specified. When specifying BSSIDs, these fields are used in order from the beginning. If not all fields are used, these fields (e.g., six octets) can be filled with "0" (for example, all zeros). As mentioned above, if it becomes possible to construct a flexible control frame that can include length information, this will not be a problem. Alternatively, a multicast address specifying multiple BSSIDs can be prepared in advance and included in the RA. In this case, one field will suffice. However, if there are multiple target BSSID combinations, it is necessary to specify the addresses for each combination and to make them publicly known within the ESS in advance.

[0234] Furthermore, when each AP sends a CF-End2 frame to STAs under its own BSS, because the CF-End2 frame is a new frame as mentioned above, legacy STAs do not recognize its subtype and do not reset their basic NAV even when they receive it. Since the Duration field is set to 0, there is no risk that legacy STAs will receive the CF-End2 frame and set a new basic NAV. This new CF-End2 frame could be made mandatory for STAs supporting the new extended standard. This would allow the CF-End2 frame to be used to reset the basic NAV of STAs under the target BSS, not just when MAP is performed under the new extended standard. In this case, an AP could send a CF-End2 frame to reset the basic NAV of another AP's BSS within the same ESS. Alternatively, support for the CF-End2 frame could be made optional under the new extended standard. In this case, when a STA sends an association request frame or reassociation request frame to its own AP, it notifies its own AP whether it supports CF-End2 frames, allowing the AP to know in advance which of its subordinate STAs can receive CF-End2 frames and reset their basic NAV. Alternatively, MAP could be made an optional feature in the new extended standard, requiring MAP-capable STAs to also support CF-End2 frames. In this case, a STA notifies its own AP whether it supports MAP when sending an association request frame or reassociation request frame to its own AP. The AP can determine which subordinate STAs are MAP-capable and send CF-End2 frames to reset the basic NAV of MAP-capable STAs. If CF-End2 frame support is also required for MAP-capable STAs, other APs can also send CF-End2 frames to the BSS to which the STA belongs so that they can respond to TF transmissions from its own AP under MAP.

[0235] If the CF-End2 frame is to cause the basic NAV to be reset only in MAP-compatible STAs, then when the AP naturally transmits the CF-End2 frame under MAP and then transmits the TF, it is more effective to limit the STAs to which the wireless resources are allocated by the TF to only MAP-compatible STAs, that is, only the STAs corresponding to the CF-End2 frame. In this way, the number of STAs that can respond and transmit to the TF increases, and the wireless resources are utilized effectively.

[0236] In the method using this CF-End2 frame, for example, after AP1 allocates some wireless resources to AP2 and other APs, and then allocates some wireless resources to another group of APs, STAs under the first allocated AP, such as STA21 and STA22, will receive the MAP TXS TF from AP1 again. Even if they do not receive it, they can receive the TXS RSP from the newly targeted group of APs, reset the basic NAV again, and do not interfere with the communication. Also, in this method, even in a situation where the TXOP is protected in advance by a CTS-to-self frame or the like, the basic NAV protected by the CF-End2 frame can be canceled, so the STA can respond and transmit to the TF from its own AP.

[0237] Note that in STA operation example 7, if the basic NAV is set in advance by a frame unrelated to the MAP, it may be overwritten with 0 by the CF-End2 frame, and the STA may ignore the transmission of the frame that it originally had to protect and transmit it, resulting in a possible frame collision. Therefore, STA operation examples 7a, 7b, and 7c to solve this problem are shown below.

[0238] <STA operation example 7a: Reset the basic NAV only when the basic NAV is set by the MAP TXS TF and the CF-End2 frame is received before the end of the NAV.> In the first operation example 7a of the solution, by means of a frame (in accordance with the previous example, MAP TXS TF) in which the source AP allocates some wireless resources to the destination AP, the STA sets the basic NAV, and resets the basic NAV only when the CF-End2 frame targeted at its own BSS is received before the basic NAV expires, that is, ends.

[0239] As an example of the implementation method of STA operation example 7a, the STA may hold a flag indicating whether the basic NAV is set by the MAP TXF TF. When the basic NAV is extended by other frames or physical packets, the STA sets the flag to the off state. Also, if the basic NAV has already been set at the stage of receiving the MAP TXS TF, the STA does not set the flag to the on state and keeps it in the off state. Moreover, when the CF-End2 frame targeted at its own BSS is received, if this flag is in the on state, the STA resets the basic NAV.

[0240] However, in STA operation example 7a, when the TXOP is protected in advance by a CTS-to-self frame or the like, or when some wireless resources are allocated to its own AP after some wireless resources are allocated to other APs, the situation is such that the basic NAV is set before the MAP TXS TF. In that case, the STA cannot respond and transmit to the TF from its own AP. Therefore, although it was stated above that if the basic NAV has already been set at the stage of receiving the MAP TXS TF, the STA does not set the flag to the on state, if the assumed basic NAV set by the MAP TXS TF and the end time of the existing basic NAV are the same, the STA may set the flag to the on state.

[0241] <STA operation example 7b: Set a value covering the remaining TXOP in the CF-End2 frame, and the STA resets the basic NAV if the basic NAV and the end time are the same> In the second operational example 7b of the solution, the CF-End2 frame specifies the duration covering the remaining TXOP. When the STA receives the CF-End2 frame for its own BSS, if the remaining duration of the configured basic NAV is the same as the duration specified in the CF-End2 frame—that is, if the end time of the remaining TXOP specified in the CF-End2 frame is the same as the end time of the configured basic NAV—it resets the basic NAV. The duration covering the remaining TXOP may be specified in the Duration field, which is provided in the same way as in the CF-End frame. While the CF-End frame defines the Duration field to be set to a value of "0," the CF-End2 frame allows the Duration field to be set to a value of "1" or greater. As a result, a conventional STA extracts the value specified in the Duration field of the CF-End2 frame as a NAV setting candidate. However, if the end time of the NAV ends at the same time as or earlier than the already-set NAV, the NAV is not overwritten, and therefore the reception of the CF-End2 frame does not have any impact. Alternatively, the Duration field can be left as it is and set to "0" to reset the NAV, as in the CF-End frame, but a new field, such as a TXOP Duration field, can be added to describe the remaining TXOP. In this case, the new field should also be two octets, similar to the conventional Duration / ID field.

[0242] When the common source AP transmits a CF-End2 frame, the common source AP recognizes the TXOP acquired by the common source AP by the frame transmitted by the common source AP, for example, MAP TXS TF, and describes the remaining TXOP in the CF-End2 frame. Since the common destination AP recognizes that the common source AP is the TXOP holder, the common destination AP can grasp the TXOP acquired by the common source AP. Conventionally, the TXOP holder is held only when the transmission is within the same BSS. However, it is assumed that an AP that performs the MAP operation can recognize and hold the TXOP holder for at least the physical packets within the same ESS even for transmissions from other BSSs. Alternatively, it may be possible for an AP that performs the MAP operation to recognize and hold only the APs within the same ESS as the TXOP holder.

[0243] When the common source AP transmits a CE-End2 frame, since the common source AP itself is the TXOP holder, the remaining TXOP can be described in the CF-End2 frame.

[0244] When the STA receives a CF-End2 frame targeted at its own BSS and the basic NAV is set, it compares the value of the basic NAV with the remaining period of the TXOP described in the CF-End2 frame. If the end points are the same, that is, if the periods are the same, the basic NAV is reset.

[0245] <STA operation example 7c: Put the TXOP holder in the CF-End2 frame and reset the basic NAV only when it matches the holding information at the STA> In the third operational example 7c of the solution, the AP transmitting the CF-End2 frame writes the TXOP holder recognized by the CF-End2 frame, and when the STA sets the basic NAV, it extracts and retains the TXOP holder of the frame from which the NAV was set. That is, the STA retains the TA of the frame from which the NAV was set as the TXOP holder. If the frame is a CTS-to-self frame, the STA retains the RA as the TXOP holder. When the STA receives a CF-End2 frame targeted by its own BSS and determines that the TXOP holder described in the CF-End2 frame is the same as the MAC address retained as the TXOP holder of the set basic NAV, it resets the basic NAV. As mentioned above, conventionally, a STA retains a TXOP holder only if the packet was sent within its own BSS. However, a STA that can transmit a response to a TF from its own AP under MAP operation can recognize and retain the source AP of a received packet as the TXOP holder, even if the received packet is from a different BSS, as long as it determines that the received packet is at least a physical packet within the same ESS. Alternatively, the STA may be configured to recognize only the AP in the same ESS as the TXOP holder and hold it.

[0246] For example, the AP may set the BSS for which basic NAV is to be reset in the RA field of the CF-End2 frame as described above, set the address of the sending AP in the BSSID (TA) field of the CF-End2 frame, and then create a new field, the TXOP Holder field, to hold the TXOP holder. In this case, it is appropriate for the new field to be 6 octets, just like other address fields.

[0247] Alternatively, the AP may insert the address of the TXOP holder in the RA field of the CF-End2 frame instead of the BSSID of the BSS whose basic NAV is to be reset. Considering that the CF-End2 frame is used under MAP, the TXOP holder entered here is always an AP, and since the AP's MAC address is the BSSID, it can be said that the BSSID is entered. Note that this initial RA field may be changed to the TXOP Holder field. In STA operation example 7 of Figure 28, AP2 inserted its own BSSID, BSSID2, in the RA field of the CF-End2 frame it transmits. However, in STA operation example 7c, AP2 inserts its own BSSID, BSSID1, in the RA field of the CF-End2 frame it transmits. For example, if the AP of the BSS whose basic NAV is to be reset transmits the CF-End2 frame, the STA can use the BSSID(TA) field to determine whether the CF-End2 frame is to be reset. When AP2 sends a CF-End2 frame, the BSSID (TA) of the CF-End2 frame is set to BSSID2, which is the MAC address of AP2, and only AP2 itself and the STAs connected to AP2 are subject to reset.If the TXOP holder of the basic NAV held by those APs / STAs matches the MAC address (here, BSSID1(AP1)) written in the RA field of the CF-End2 frame, the basic NAV will be reset.

[0248] When the basic NAV is extended, the STA extracts the TXOP holder from the frame that originally extended the NAV, and overwrites the TXOP holder it held with the extracted TXOP holder.

[0249] When the STA limits the retention condition of the TXOP holder of the basic NAV to, for example, when receiving a physical packet within the same ESS, or when receiving a physical packet from an AP within the same ESS, and sets the basic NAV upon receiving a physical packet that is not subject to TXOP holder retention, the TXOP holder (specifically, the storage area for it) is left empty (void). Even when the basic NAV is extended due to the reception of a physical packet that leaves the TXOP holder empty (void), the TXOP holder is made empty (void) even if it was held. If the STA does not hold a TXOP holder when it receives a CF-End2 frame (i.e., if it is empty (void)), it does not reset the basic NAV.

[0250] The configuration of the AP or STA will be described below.

[0251] 29 is a functional block diagram of another example of an AP 400. The AP 400 includes a communication processing unit 401, a transmitting unit 402, a receiving unit 403, multiple (e.g., four) antennas 42A, 42B, 42C, and 42D, a network processing unit 404, a wired interface (I / F) 405, and a memory 406. The AP 400 is connected to a server 407 via the wired I / F 405. The communication processing unit 401 has a function similar to that of the MAC common processing unit 70 shown in FIG. 2. The transmitting unit 402 has a function similar to that of the transmission processing unit 80 shown in FIG. 2. The receiving unit 403 has a function similar to that of the reception processing unit 90 shown in FIG. 2. The network processing unit 404 has a function similar to that of the upper processing unit 10 shown in FIG. 2. The communication processing unit 401 may include an internal buffer for transferring data to and from the network processing unit 404. This buffer may be a volatile memory such as a DRAM, or a non-volatile memory such as a NAND or MRAM.

[0252] The network processing unit 404 controls data exchange with the communication processing unit 401, data writing and reading with the memory 406, and communication with the server 407 via the wired I / F 405. The network processing unit 404 may perform communication processing above the MAC layer, such as TCP / IP or UDP / IP, and application layer processing. The operation of the network processing unit 404 may be performed by software (program) processing by a processor such as a CPU, by hardware, or by both software and hardware.

[0253] As an example, the communication processing unit 401 corresponds to a baseband integrated circuit, and the transmitting unit 402 and the receiving unit 403 correspond to an RF integrated circuit that transmits and receives frames. The communication processing unit 401 and the network processing unit 404 may be configured as a single integrated circuit (single chip). The parts of the transmitting unit 402 and the receiving unit 403 that perform digital processing and the parts that perform analog processing may be configured on different chips. Furthermore, the communication processing unit 401 may be configured to perform communication processing above the MAC layer, such as TCP / IP or UDP / IP. Furthermore, although the number of antennas 42A, 42B, 42C, and 42D is four here, it is sufficient to have at least one antenna.

[0254] The memory 406 stores data received from the server 407 and data received by the receiving unit 403. The memory 406 may be, for example, a volatile memory such as a DRAM, or a non-volatile memory such as a NAND or MRAM. The memory 406 may also be an SSD, an HDD, an SD card, an eMMC, or the like. The memory 406 may be located outside the AP 400.

[0255] 29, communication with the server 407 is performed via a wired connection, but communication with the server 407 may also be performed wirelessly. In this case, a wireless I / F may be used instead of the wired I / F 405.

[0256] The server 407 is a communication device that receives a data transfer request for transmitting data and returns a response including the requested data, and is assumed to be, for example, an HTTP server (web server), an FTP server, etc. However, as long as it has the function of returning the requested data, it is not limited to these. It may also be a communication device operated by a user, such as a PC or smartphone. It may also communicate with the AP 400 wirelessly.

[0257] When a STA belonging to the BSS of the AP 400 issues a data transfer request to the server 407, a packet related to this data transfer request is transmitted to the AP 400. The AP 400 receives this packet via the antennas 42A, 42B, 42C, and 42D, and executes physical layer processing etc. in the receiver 403 and MAC layer processing etc. in the communication processor 401.

[0258] The network processing unit 404 analyzes the packet received from the communication processing unit 401. Specifically, it checks the destination IP address, destination port number, etc. If the data in the packet is a data transfer request such as an HTTP GET request, the network processing unit 404 checks whether the data requested in this data transfer request (for example, data present in the URL requested in the HTTP GET request) is cached (stored) in the memory 406. The memory 406 stores a table that associates URLs (or their reduced representations, such as hash values ​​or alternative identifiers) with data. Here, the fact that data is cached in the memory 406 is expressed as "cache data exists in the memory 406."

[0259] If the cache data does not exist in the memory 406, the network processing unit 404 transmits a data transfer request to the server 407 via the wired I / F 405. That is, the network processing unit 404 transmits the data transfer request to the server 407 on behalf of the STA. Specifically, the network processing unit 404 generates an HTTP request, performs protocol processing such as adding a TCP / IP header, and passes the packet to the wired I / F 405. The wired I / F 405 transmits the received packet to the server 407.

[0260] The wired I / F 405 receives a packet that is a response to the data transfer request from the server 407. The network processing unit 404 determines from the IP header of the packet received via the wired I / F 405 that the packet is addressed to an STA, and passes the packet to the communication processing unit 401. The communication processing unit 401 performs MAC layer processing and the like on the packet, and the transmitting unit 402 performs physical layer processing and the like, and transmits the packet addressed to the STA from antennas 42A, 42B, 42C, and 42D. Here, the network processing unit 404 associates the data received from the server 407 with a URL (or a reduced representation thereof) and stores it as cache data in the memory 406.

[0261] If cached data exists in memory 406, network processing unit 404 reads the data requested in the data transfer request from memory 406 and transmits this data to communication processing unit 401. Specifically, the network processing unit 404 adds an HTTP header and the like to the data read from memory 406, performs protocol processing such as adding a TCP / IP header, and transmits a packet to communication processing unit 401. At this time, as an example, the source IP address of the packet is set to the same IP address as server 407, and the source port number is also set to the same port number as server 407 (the destination port number of the packet transmitted by the STA that issued the data transfer request to server 407). Therefore, from the perspective of the STA, it appears as if it is communicating with server 407. The communication processing unit 401 performs MAC layer processing and the like on this packet, and the transmitting unit 402 performs physical layer processing and the like, and transmits the packet addressed to the STA from antennas 42A, 42B, 42C, and 42D.

[0262] By performing such an operation, frequently accessed data is responded to based on cached data stored in memory 406, thereby reducing traffic between server 407 and AP 400. Note that the operation of network processing unit 404 is not limited to the above-described operation. As long as it is a general cache proxy that obtains data from server 407 instead of an STA, caches the data in memory 406, and responds to a data transfer request for the same data from the cached data in memory 406, a different operation may also be used.

[0263] The AP 400 can be applied as the AP described with reference to Figures 1 to 28. The transmission of frames, data, or packets described with reference to Figures 1 to 28 may be performed using cached data stored in memory 406. Furthermore, information obtained from frames, data, or packets received by the AP described with reference to Figures 1 to 28 may be cached in memory 406. A frame transmitted by the AP described with reference to Figures 1 to 28 may include cached data or information based on the cached data. The information based on the data may be, for example, information on the presence or absence of data addressed to a STA, information on the size of the data, or information on the size of a packet required to transmit the data. It may also be information such as a modulation method required to transmit the data.

[0264] Although FIG. 29 illustrates an AP with a cache function, an STA with a cache function can also be realized with the same block configuration as FIG. 29. The STA here is a non-AP STA (as mentioned above, an AP is also a form of wireless communication device). In this case, the wired I / F 405 may be omitted. The transmission of frames, data, or packets by the STA described with reference to FIGS. 1 to 28 may be performed using cached data stored in memory 406. Furthermore, information obtained from frames, data, or packets received by the STA described with reference to FIGS. 1 to 28 may be cached in memory 406. A frame transmitted by the STA described with reference to FIGS. 1 to 28 may include cached data or information based on the cached data. The information based on the data may be, for example, information on the presence or absence of data to be transmitted, information on the size of the data, or information on the size of packets required to transmit the data. It may also be information such as a modulation method required to transmit the data.

[0265] FIG. 30 shows an example of the overall configuration of an STA (non-AP STA) or an AP. This configuration example is just an example, and the configuration example is not limited to this. The STA or AP has one or more antennas 1471 to 1477. n (n is an integer of 1 or more), a wireless LAN module (or wireless communication device) 148, and a host system 149. The wireless LAN module 148 has a host interface and is connected to the host system 149 via the host interface. The wireless LAN module 148 may be connected to the host system 149 via a connection cable, or may be connected directly to the host system 149. Also, a configuration is possible in which the wireless LAN module 148 is mounted on a board by solder or the like and is connected to the host system 149 via wiring on the board. The host system 149 communicates with the wireless LAN module 148 and antennas 1471 to 1472 according to an arbitrary communication protocol. n The WLAN module 148 communicates with external devices using the above protocol. The communication protocol may include TCP / IP and a higher-layer protocol. Alternatively, the TCP / IP may be installed in the WLAN module 148, and the host system 149 may execute only the higher-layer protocol. In this case, the configuration of the host system 149 can be simplified. The STA shown in FIG. 30 may be, for example, a mobile STA, a TV, a digital camera, a wearable device, a tablet, a smartphone, a game device, a network storage device, a monitor, a digital audio player, a webcam, a video camera, a projector, a navigation system, an external adapter, an internal adapter, a set-top box, a gateway, a printer server, a mobile access point, a router, an enterprise / service provider access point, a portable device, a handheld device, or an automobile. In addition to IEEE 802.11, the WLAN module 148 may also be equipped with functionality for other wireless communication standards such as LTE (Long Term Evolution) or LTE-Advanced (standards for mobile phones).

[0266] 31 shows an example of the hardware configuration of the wireless LAN module 148. This configuration is applicable whether the wireless LAN module 148 is installed in a non-AP STA or an AP. In this configuration example, only one antenna is used, but two or more antennas may be used. In this case, multiple sets of transmission systems (216, 222 to 225), reception systems (217, 232 to 235), PLLs 242, crystal oscillators (reference signal sources) 243, and switches 245 may be provided corresponding to the respective antennas, and each set may be connected to the baseband circuit 212. The PLLs 242, the crystal oscillators 243, or both of these correspond to oscillators.

[0267] The wireless LAN module includes a baseband integrated circuit (IC) 211, a radio frequency (RF) IC 221, a balun 225, a switch 245, and an antenna 247.

[0268] The baseband IC 211 includes a baseband circuit (control circuit) 212 , a memory 213 , a host interface 214 , a CPU 215 , a DAC (Digital to Analog Converter) 216 , and an ADC (Analog to Digital Converter) 217 ​​.

[0269] The baseband IC 211 and the RFIC 221 may be formed on the same substrate. Alternatively, the baseband IC 211 and the RFIC 221 may be configured on a single chip. Either or both of the DAC 216 and the ADC 217 may be disposed in the RFIC 221 or in a separate IC. Alternatively, either or both of the memory 213 and the CPU 215 may be disposed in an IC separate from the baseband IC.

[0270] The memory 213 stores data to be exchanged with the host system. The memory 213 also stores information to be notified to the STA or AP, information notified from the STA or AP, or both. The memory 213 also stores programs required for execution by the CPU 215, and may be used as a work area when the CPU 215 executes the programs. The memory 213 may be a volatile memory such as SRAM or DRAM, or a non-volatile memory such as NAND or MRAM.

[0271] The host interface 214 is an interface for connecting to a host system, and may be any interface such as UART, SPI, SDIO, USB, or PCI Express.

[0272] The CPU 215 is a processor that executes programs to control the baseband circuit 212. The baseband circuit 212 mainly performs MAC layer processing and physical layer processing. The baseband circuit 212, the CPU 215, or both of them correspond to a communication control device that controls communication, or a control unit that controls communication.

[0273] At least one of the baseband circuit 212 and the CPU 215 may include a clock generating unit that generates a clock, and manage internal time using the clock generated by the clock generating unit.

[0274] The baseband circuit 212 performs physical layer processing on the frame to be transmitted, such as adding a physical header, encoding, encryption, and modulation, and generates, for example, two types of digital baseband signals (hereinafter referred to as a digital I signal and a digital Q signal).

[0275] The DAC 216 performs digital-to-analog conversion of the signal input from the baseband circuit 212. More specifically, the DAC 216 converts the digital I signal into an analog I signal, and the digital Q signal into an analog Q signal. Note that it is also possible to transmit a single signal as is without quadrature modulation. When multiple antennas are provided and one or multiple transmission signals are distributed and transmitted in accordance with the number of antennas, a number of DACs and the like corresponding to the number of antennas may be provided.

[0276] The RFIC 221 is, for example, an RF analog IC or a radio frequency IC, or both. The RFIC 221 includes a filter 222, a mixer 223, a preamplifier (PA) 224, a phase-locked loop (PLL) 242, a low-noise amplifier (LNA), a balun 235, the mixer 233, and a filter 232. Some of these elements may be located on the baseband IC 211 or on a separate IC. The filters 222 and 232 may be band-pass filters or low-pass filters.

[0277] The filter 222 extracts signals of a desired band from each of the analog I signal and analog Q signal input from the DAC 216. The PLL 242 uses an oscillation signal input from a crystal oscillator 243 to divide and / or multiply the oscillation signal to generate a signal of a constant frequency synchronized with the phase of the input signal. The PLL 242 includes a VCO (Voltage Controlled Oscillator) and performs feedback control using the VCO based on the oscillation signal input from the crystal oscillator 243 to obtain the signal of the constant frequency. The generated signal of the constant frequency is input to the mixer 223 and the mixer 233. The PLL 242 corresponds to an example of an oscillator that generates a signal of a constant frequency.

[0278] The mixer 223 upconverts the analog I signal and analog Q signal that have passed through the filter 222 to a radio frequency using a constant-frequency signal supplied from the PLL 242. The preamplifier (PA) amplifies the radio-frequency analog I signal and analog Q signal generated by the mixer 223 to the desired output power. The balun 225 is a converter that converts a balanced signal (differential signal) to an unbalanced signal (single-ended signal). The RFIC 221 handles balanced signals, but unbalanced signals are handled from the output of the RFIC 221 to the antenna 247, so the balun 225 performs this signal conversion.

[0279] During transmission, switch 245 is connected to balun 225 on the transmitting side, and during reception, it is connected to balun 235 on the receiving side or RFIC 221. Switch 245 may be controlled by baseband IC 211 or RFIC 221, or a separate circuit may exist that controls switch 245, and switch 245 may be controlled from that circuit.

[0280] The radio frequency analog I signal and analog Q signal amplified by the preamplifier 224 are balanced-to-unbalanced converted by the balun 225 and then radiated as radio waves from the antenna 247 into space.

[0281] The antenna 247 may be a chip antenna, an antenna formed by wiring on a printed circuit board, or an antenna formed by using a linear conductive element.

[0282] The LNA 234 in the RFIC 221 amplifies the signal received from the antenna 247 via the switch 245 to a demodulatable level while suppressing noise. The balun 235 performs unbalanced-to-balanced conversion on the signal amplified by the low-noise amplifier (LNA) 234. The mixer 233 downconverts the received signal, converted to a balanced signal by the balun 235, to baseband using a constant-frequency signal input from the PLL 242. More specifically, the mixer 233 has means for generating carrier waves shifted in phase by 90° based on the constant-frequency signal input from the PLL 242, and quadrature-demodulates the received signal converted by the balun 235 using the carrier waves shifted in phase by 90° to generate an I (In-phase) signal that is in phase with the received signal and a Q (Quad-phase) signal that is delayed in phase by 90°. The filter 232 extracts a signal of a desired frequency component from these I and Q signals. The I and Q signals extracted by the filter 232 are output from the RFIC 221 after the gains are adjusted.

[0283] The ADC 217 in the baseband IC 211 performs A / D conversion on the input signal from the RFIC 221. More specifically, the ADC 217 converts the I signal into a digital I signal and the Q signal into a digital Q signal. Note that there may be cases where only one signal is received without quadrature demodulation.

[0284] When multiple antennas are provided, the number of ADCs provided may correspond to the number of antennas. The baseband circuit 212 performs physical layer processing, such as demodulation, error correction code processing, and physical header processing, based on the digital I signal and digital Q signal to obtain a frame. The baseband circuit 212 performs MAC layer processing on the frame. Note that, if TCP / IP is implemented, the baseband circuit 212 can also be configured to perform TCP / IP processing.

[0285] 32(a) and 32(b) are perspective views of two other examples of wireless STAs. The wireless STA in FIG. 32(a) is a laptop PC 301, and the wireless STA in FIG. 32(b) is a mobile terminal 321. The laptop PC 301 and the mobile terminal 321 are equipped with wireless communication devices 305 and 315, respectively. The wireless communication devices 305 and 315 may be the wireless communication devices installed in the STAs described above, the wireless communication devices installed in APs, or both. Wireless STAs equipped with wireless communication devices are not limited to laptop PCs and mobile terminals. For example, wireless STAs may also be installed in TVs, digital cameras, wearable devices, tablets, smartphones, game consoles, network storage devices, monitors, digital audio players, web cameras, video cameras, projectors, navigation systems, external adapters, internal adapters, set-top boxes, gateways, printer servers, mobile access points, routers, enterprise / service provider access points, portable devices, handheld devices, automobiles, etc.

[0286] Furthermore, a wireless communication device that is mounted on a wireless STA or AP, or both, can also be mounted on a memory card. An example of such a wireless communication device mounted on a memory card is shown in FIG. 33. Memory card 331 includes wireless communication device 355 and memory card main body 332. Memory card 331 uses wireless communication device 335 for wireless communication with an external device (wireless STA or AP, or both, etc.). Note that other elements (such as memory) within memory card 331 are omitted from FIG. 33.

[0287] Another example of a wireless communication device (a wireless communication device of an AP or a wireless communication device of a wireless STA, or both) will be described. Another example may include a bus, a processor, and an external interface. The processor and the external interface are connected to an external memory (buffer) via the bus. Firmware runs in the processor. By configuring the wireless communication device to include firmware in this way, it becomes possible to easily change the functions of the wireless communication device by rewriting the firmware. The processor on which the firmware runs may be a processing unit or a processor that performs processing of the processing unit, or may be a separate processor that performs processing related to functional expansion or modification of the processing. The processor on which the firmware runs may be included in the AP, the wireless STA, or both. Alternatively, the processor may be included in an integrated circuit in a wireless communication device mounted in an AP, or in an integrated circuit in a wireless communication device mounted in a wireless STA.

[0288] In addition to the configuration of the wireless communication device (wireless communication device of AP or wireless STA, or both) according to the above-described embodiment, a clock generation unit may be provided. The clock generation unit generates a clock and outputs the clock from an output terminal to the outside of the wireless communication device. In this way, by outputting the clock generated inside the wireless communication device to the outside and operating the host side using the clock output to the outside, it becomes possible to operate the host side and the wireless communication device side in synchronization.

[0289] In addition to the configuration of the wireless communication device (wireless communication device of AP or wireless STA) according to the above-described embodiment, a power supply unit, a power supply control unit, and a wireless power supply unit may be included. The power supply control unit is connected to the power supply unit and the wireless power supply unit, and controls the selection of a power source to be supplied to the wireless communication device. In this way, by configuring the wireless communication device to include a power supply, it becomes possible to operate with low power consumption by controlling the power supply.

[0290] In addition to the configuration of the wireless communication device according to the above-described embodiment, a SIM card may be included. The SIM card is connected to, for example, a control unit in the wireless communication device. By configuring the wireless communication device to include a SIM card in this way, authentication processing can be easily performed.

[0291] In addition to the configuration of the wireless communication device according to the above-described embodiment, the wireless communication device may include a video compression / decompression unit. The video compression / decompression unit is connected to the bus. By configuring the wireless communication device to include a video compression / decompression unit in this way, it becomes possible to easily transmit compressed video and decompress received compressed video.

[0292] In addition to the configuration of the wireless communication device (the wireless communication device of the AP or the wireless communication device of the wireless STA, or both of these) according to the above-described embodiment, an LED unit may be included. The LED unit is connected to the transmitter, the receiver, the controller, or a combination of these. In this way, by configuring the wireless communication device to include an LED unit, it becomes possible to easily notify the user of the operating status of the wireless communication device.

[0293] In addition to the configuration of the wireless communication device (the wireless communication device of the AP or the wireless communication device of the wireless STA, or both of them) according to the above-described embodiment, a vibrator unit may be included. The vibrator unit is connected to, for example, a control unit in the wireless communication device. By configuring the wireless communication device to include a vibrator unit in this way, it becomes possible to easily notify the user of the operating status of the wireless communication device.

[0294] In addition to the configuration of the wireless communication device (the wireless communication device of the AP or the wireless communication device of the wireless STA, or both of them) according to the above-described embodiment, a display may be included. The display may be connected to the control unit of the wireless communication device via a bus (not shown). By configuring the wireless communication device with a display in this way and displaying the operating status of the wireless communication device on the display, it becomes possible to easily notify the user of the operating status of the wireless communication device.

[0295] Next, we will explain [1] frame types in wireless communication systems, [2] methods for disconnecting connections between wireless communication devices, [3] access methods for wireless LAN systems, and [4] frame intervals in wireless LANs.

[0296] [1] Frame types in communication systems Generally, frames handled by wireless access protocols in wireless communication systems can be broadly divided into three types: data frames, management frames, and control frames, as mentioned above. These types are usually indicated in the header section that is common to all frames. Frame types can be indicated by one field to distinguish the three types, or by a combination of two fields. In the IEEE 802.11 standard, frame types are identified by two fields, Type and Subtype, in the FrameControl field in the frame header of a MAC frame. The Type field broadly distinguishes between data frames, management frames, and control frames, while the Subtype field distinguishes between more specific types within these broad frame categories, such as a beacon frame within a management frame.

[0297] Management frames are frames used to manage physical communication links with other wireless communication devices. For example, there are frames used to set up communication with other wireless communication devices, frames to release communication links (i.e., disconnect connections), and frames related to power saving operations in wireless communication devices.

[0298] A data frame is a frame for transmitting data generated within a wireless communication device to another wireless communication device after a physical communication link has been established with the other wireless communication device. The data is generated in a higher layer in this embodiment, for example, by a user operation.

[0299] A control frame is a frame used for controlling the transmission and reception (exchange) of data frames with other wireless communication devices. A response frame sent to a wireless communication device to confirm the receipt of a data frame or management frame belongs to the control frame category. Examples of response frames include an ACK frame and a BlockACK frame. RTS frames and CTS frames are also control frames.

[0300] These three types of frames are processed as necessary in the physical layer and then transmitted as physical packets via the antenna. Note that the IEEE802.11 standard (including extended standards such as the aforementioned IEEEStd802.11ac-2013) has an association process as one of the procedures for establishing a connection, and the AssociationRequest frame and AssociationResponse frame used in this process are management frames. Since the AssociationRequest frame and AssociationResponse frame are unicast management frames, they request the receiving wireless communication device to send an ACK frame, which is a response frame, and this ACK frame is a control frame as described above.

[0301] [2] Methods for Disconnecting Wireless Communication Devices There are two methods for disconnecting (releasing) a connection: explicit and implicit. In the explicit method, one of the wireless communication devices that has established a connection sends a frame for disconnection. In the IEEE 802.11 standard, this is called a Deauthentication frame, which is classified as a management frame. Typically, the wireless communication device that sends the frame for disconnection determines that the connection has been disconnected when it transmits the frame, and the wireless communication device that receives the frame determines that the connection has been disconnected when it receives the frame. After that, if the wireless communication device is not an AP, it returns to the initial state in the communication phase, for example, a state searching for a BSS to connect to. When a wireless communication AP disconnects a connection with a wireless communication device, for example, if the wireless communication AP has a connection management table that manages wireless communication devices that subscribe to its own BSS, it deletes information related to the wireless communication device from the connection management table. For example, when a wireless communication AP assigns an AID after allowing connection to each wireless communication device joining its own BSS in the association process, it may delete the retained information associated with the AID of the wireless communication device that has disconnected the connection, and release the AID so that it can be assigned to another newly joining wireless communication device.

[0302] On the other hand, an implicit method determines whether a connection has been disconnected when no frame transmission (data frame and management frame transmission, or response frame transmission to a frame transmitted by the device itself) is detected for a certain period of time from the wireless communication device with which a connection has been established. This method is used because, in the situation where a connection is determined to be disconnected as described above, it is possible that the communication distance from the wireless communication device to which the connection is connected is so great that a physical wireless link cannot be established, making it impossible to receive or decode wireless signals. In other words, this is because it is not expected that a frame to disconnect the connection will be received.

[0303] A specific example of an implicit method for determining whether to terminate a connection is to use a timer. For example, when transmitting a data frame that requires a delivery acknowledgment frame, a first timer (e.g., a retransmission timer for the data frame) is started to limit the retransmission period for that frame, and if a delivery acknowledgment frame for that frame is not received until the first timer expires (i.e., until the desired retransmission period has elapsed), the frame is retransmitted. When a delivery acknowledgment frame for that frame is received, the first timer is stopped.

[0304] On the other hand, if the first timer expires without receiving a delivery acknowledgment frame, for example, a management frame is transmitted to confirm whether the wireless communication device with which the connection is made is still present (within communication range) (in other words, whether the wireless link is secured), and at the same time, a second timer (for example, a retransmission timer for a management frame) is started to limit the retransmission period of the frame. As with the first timer, the second timer also performs retransmission if a delivery acknowledgment frame for the frame is not received until the second timer expires, and determines that the connection has been disconnected when the second timer expires. At the stage when it is determined that the connection has been disconnected, a frame to disconnect the connection may be transmitted.

[0305] Alternatively, a third timer is started when a frame is received from the wireless communication device of the other connection, and the third timer is stopped and restarted from its initial value each time a new frame is received from the wireless communication device of the other connection. When the third timer expires, a management frame is transmitted to confirm whether the wireless communication device of the other connection is still present (within communication range) (in other words, whether the wireless link is established), as described above, and at the same time, a second timer (e.g., a retransmission timer for the management frame) is initiated to limit the retransmission period of the frame. In this case, if a delivery acknowledgment response frame for the frame is not received until the second timer expires, a retransmission is performed, and when the second timer expires, the connection is determined to have been disconnected. In this case, a frame to disconnect the connection may also be transmitted when it is determined that the connection has been disconnected. The management frame for confirming whether the wireless communication device of the other connection is still present in the latter case may be different from the management frame in the former case. In addition, although the same second timer as in the former case is used here as the timer for limiting the retransmission of the management frame in the latter case, a different timer may be used.

[0306] [3] Wireless LAN System Access Methods: For example, there are wireless LAN systems designed to communicate with or compete with multiple wireless communication devices. IEEE 802.11 wireless LANs use CSMA / CA (Carrier Sense Multiple Access with Carrier Avoidance) as their basic access method. In a method in which a wireless communication device's transmission is detected and a fixed time elapses after the transmission ends, multiple wireless communication devices that have detected the transmission of that wireless communication device transmit simultaneously, resulting in wireless signal collisions and frame transmission failures. By detecting a wireless communication device's transmission and waiting a random time after the transmission ends, transmissions from multiple wireless communication devices that have detected the transmission of that wireless communication device are distributed probabilistically. Therefore, if there is one wireless communication device that has subtracted the earliest time from the random time, the wireless communication device's frame transmission will be successful, preventing frame collisions. Because the acquisition of transmission rights is fair among multiple wireless communication devices based on a random value, a method using Carrier Avoidance can be said to be suitable for sharing the wireless medium among multiple wireless communication devices.

[0307] [4] Frame spacing in wireless LANs: The frame spacing in IEEE802.11 wireless LANs is explained below. The frame spacings used in IEEE802.11 wireless LANs include distributed coordination function interframe space (DIFS), arbitration interframe space (AIFS), point coordination function interframe space (PIFS), short interframe space (SIFS), extended interframe space (EIFS), and reduced interframe space (RIFS).

[0308] In IEEE802.11 wireless LAN, the frame interval is defined as a continuous period that must be left after confirming carrier sense idle before transmission, and the exact period from the previous frame is not discussed. Therefore, this definition will be followed in the explanation of the IEEE802.11 wireless LAN system. In IEEE802.11 wireless LAN, the waiting time for random access based on CSMA / CA is the sum of the fixed time and the random time, and this definition is used to clarify the fixed time.

[0309] DIFS and AIFS are frame intervals used when attempting to start frame exchange during a contention period with other wireless communication devices based on CSMA / CA. DIFS is used when there is no distinction of priority based on traffic type, while AIFS is used when priority is set based on traffic type (Traffic Identifier; TID).

[0310] Since the operations involved in DIFS and AIFS are similar, the following explanations will mainly use AIFS. In IEEE802.11 wireless LANs, access control, including the initiation of frame exchange, is performed at the MAC layer. Furthermore, if QoS (Quality of Service) is supported when data is passed from a higher layer, the traffic type is notified along with the data, and the data is classified based on the traffic type for access priority. This access class is called an Access Category (AC). Therefore, an AIFS value is set for each access category.

[0311] PIFS is a frame interval that allows a device to have priority access over competing wireless communication devices, and is shorter than either DIFS or AIFS. SIFS is a frame interval that can be used when transmitting a response control frame or when continuing frame exchange in bursts after acquiring the right to transmit. EIFS is a frame interval that is activated when frame reception fails (the received frame is determined to be an error).

[0312] RIFS is a frame interval that can be used when transmitting multiple frames consecutively in a burst to the same wireless communication device after first acquiring the right to transmit, and while using RIFS, no response frame is requested from the wireless communication device at the other end of the transmission.

[0313] FIG. 34 shows an example of frame exchange during a contention period based on random access in an IEEE802.11 wireless LAN.

[0314] Assume that when a request to send a data frame (W_DATA1) occurs in a wireless communication device, the carrier sense result indicates that the medium is busy (busy). In this case, a fixed AIFS is opened from the point when the carrier sense becomes idle, and then a random backoff occurs after that, and then the data frame W_DATA1 is transmitted to the other party. Note that if the carrier sense result indicates that the medium is not busy, i.e., the medium is recognized as idle, then a fixed AIFS is opened from the point when the carrier sense started, and then the data frame W_DATA1 is transmitted to the other party.

[0315] The random time is a pseudo-random integer derived from a uniform distribution between 0 and the contention window (CW), which is given as an integer, multiplied by the slot time. Here, the CW multiplied by the slot time is called the CW time width. The initial value of CW is given by CWmin, and the CW value is increased with each retransmission until it reaches CWmax. Both CWmin and CWmax have values ​​for each access category, just like AIFS. If the wireless communication device to which W_DATA1 is sent successfully receives the data frame and if the data frame requests the transmission of a response frame, it sends a response frame (W_ACK1) SIFS after the end of the occupation of the wireless medium for the physical packet containing that data frame. When the wireless communication device that sent W_DATA1 receives W_ACK1, it can send the next frame (e.g., W_DATA2) SIFS after the end of the occupation of the wireless medium for the physical packet containing W_ACK1, as long as it is within the transmission burst time limit.

[0316] AIFS, DIFS, PIFS, and EIFS are functions of SIFS and slot time, but SIFS and slot time are specified for each physical layer. Also, parameters such as AIFS, CWmin, and CWmax, which have values ​​set for each access category, can be set for each communication group (Basic Service Set (BSS) in IEEE802.11 wireless LAN), but default values ​​are specified.

[0317] For example, in the 802.11ac standard, SIFS is 16 μs and slot time is 9 μs, which means that PIFS is 25 μs, DIFS is 34 μs, and for AIFS, the default frame interval for access categories BACKGROUND (AC_BK) is 79 μs, the default frame interval for BESTEFFORT (AC_BE) is 43 μs, the default frame interval for VIDEO (AC_VI) and VOICE (AC_VO) is 34 μs, and the default values ​​for CWmin and CWmax are 31 and 1023 for AC_BK and AC_BE, 15 and 31 for AC_VI, and 7 and 15 for AC_VO. Note that EIFS is basically the sum of SIFS, DIFS, and the time length of a response frame when transmitted at the slowest required physical rate. In addition, in wireless communication devices that can take an efficient EIFS, it is possible to estimate the length of time occupied by a physical packet that carries a response frame to a physical packet that initiated an EIFS, and use the sum of SIFS, DIFS, and the estimated time.

[0318] The frames described in each embodiment may refer to what is called a packet in the IEEE802.11 standard or a standard that complies with it, such as a NullDataPacket.

[0319] Furthermore, frames multiplexed by multiple STAs may have different or identical contents. In general terms, when multiple STAs are said to transmit or receive X frames, the contents of these X frames may be the same or different, where X is an arbitrary value.

[0320] The terms used in the present embodiments should be interpreted broadly. For example, the term "processor" may encompass a general-purpose processor, a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a controller, a microcontroller, a state machine, etc. Depending on the context, "processor" may refer to an application-specific integrated circuit, a field-programmable gate array (FPGA), a programmable logic device (PLD), etc. "Processor" may also refer to a combination of processing devices such as multiple microprocessors, a combination of a DSP and a microprocessor, or one or more microprocessors working in conjunction with a DSP core.

[0321] As another example, the term "memory" may encompass any electronic component capable of storing electronic information. "Memory" may refer to random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), nonvolatile random access memory (NVRAM), flash memory, magnetic or optical data storage, which is readable by a processor. Memory may be said to be in electronic communication with a processor if the processor reads and / or writes information to the memory. Memory may be integrated into the processor, in which case the memory may also be said to be in electronic communication with the processor. Also, a circuit may be multiple circuits located on a single chip, or one or more circuits distributed across multiple chips or multiple devices.

[0322] The present invention is not limited to the above-described embodiments, and the components can be modified and embodied in practice without departing from the spirit of the invention. Furthermore, various inventions can be created by appropriately combining multiple components disclosed in the above-described embodiments. For example, some components may be omitted from all the components shown in the embodiments. Furthermore, components from different embodiments may be appropriately combined. [Explanation of symbols]

[0323] AP...base station, STA...terminal, 10...upper processing unit, 20...MAC processing unit, 30...PHY processing unit, 40...MAC / PHY management unit, 50...analog processing unit, 60...antenna, 70...MAC common processing unit, 80...transmission processing unit, 90...reception processing unit.< / map>

Claims

1. A wireless communication device that is included in a first wireless communication group together with a first terminal, the first wireless communication group constitutes an extended wireless communication group together with a second wireless communication group including a second wireless communication device and a second terminal; the wireless communication device receives a first frame for allocating a portion of a first occupancy time of the communication medium acquired by the second wireless communication device to the wireless communication device; the first frame includes a first field representing the partial period and a second field specifying identification information of a target device to which the partial period is allocated; The wireless communication device When the second field specifies identification information of the wireless communication device and the partial period is used, a response frame is transmitted to the second wireless communication device after a fixed time has elapsed since the first frame was received, and then: The wireless communication device transmits to the first terminal a second frame including a third field indicating an available period within the allocated partial period.

2. the first frame is a Transmission Sharing Trigger frame, The wireless communication device of claim 1 , wherein the second field is an AID12 field.

3. The wireless communication device of claim 2 , wherein the AID12 field can include identification information of the first terminal and identification information of the wireless communication device.

4. The wireless communication device according to claim 2 , wherein any one of the wireless communication devices belonging to the extended wireless communication group assigns an identifier of the other wireless communication device to the other wireless communication device belonging to the extended wireless communication group.

5. The wireless communication device according to claim 2 , wherein the third field is a Duration / ID field.

6. The wireless communication device according to claim 1 , wherein the first terminal generates information indicating that the communication medium is virtually busy during the partial period based on the information in the third field.

7. The wireless communication device Obtain the right to send a packet, obtaining a second occupancy time of the communication medium; The wireless communication device according to claim 1 , further comprising: transmitting a third frame to the second wireless communication device for allocating a portion of the second occupancy time to the second wireless communication device.

8. 8. The wireless communication device according to claim 7, wherein the third frame includes a third field including information representing a portion of the second occupancy time, and a fourth field including identification information of the second wireless communication device.

9. the wireless communication device allocates a portion of the second occupancy time to the first terminal using the third frame; the fourth field includes identification information of the second wireless communication device or identification information of the first terminal, The wireless communication device according to claim 8 , wherein the identification information of the first terminal has a first range of values, and the identification information of the second wireless communication device has a second range of values ​​different from the first range.

Images