WO2024038905A1 - 通信装置、及び通信方法 - Google Patents

通信装置、及び通信方法 Download PDF

Info

Publication number
WO2024038905A1
WO2024038905A1 PCT/JP2023/029821 JP2023029821W WO2024038905A1 WO 2024038905 A1 WO2024038905 A1 WO 2024038905A1 JP 2023029821 W JP2023029821 W JP 2023029821W WO 2024038905 A1 WO2024038905 A1 WO 2024038905A1
Authority
WO
WIPO (PCT)
Prior art keywords
signal
sta
transmission
txop
allocation period
Prior art date
Application number
PCT/JP2023/029821
Other languages
English (en)
French (fr)
Inventor
敬 岩井
裕幸 本塚
嘉夫 浦部
智史 高田
浩幸 金谷
Original Assignee
パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ filed Critical パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Publication of WO2024038905A1 publication Critical patent/WO2024038905A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W16/00—Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
    • H04W16/02—Resource partitioning among network components, e.g. reuse partitioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W16/00—Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
    • H04W16/14—Spectrum sharing arrangements between different networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H04W72/044—Wireless resource allocation based on the type of the allocated resource
    • H04W72/0446—Resources in time domain, e.g. slots or frames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]

Definitions

  • the present disclosure relates to a communication device and a communication method.
  • IEEE 802.11be The technical specifications for IEEE 802.11be (hereinafter referred to as “11be") are being developed as a successor standard to IEEE 802.11ax (hereinafter referred to as “11ax”), which is the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard. It is being 11ax is also called High Efficiency (HE), and 11be is also called Extreme High Throughput (EHT). Discussions are also underway regarding the required specifications for the successor standard to 11be. Hereinafter, the successor standard to 11be will be referred to as "Beyond 11be.”
  • HE High Efficiency
  • EHT Extreme High Throughput
  • Non-limiting embodiments of the present disclosure contribute to providing a communication device and a communication method that can improve transmission efficiency in wireless communication.
  • a Non-Access Point Station (Non-AP STA) according to an embodiment of the present disclosure includes a control unit that generates a signal instructing allocation of acquired resources with a specified allocation period, and a control unit that transmits the generated signal.
  • a wireless transmitting/receiving unit is provided.
  • transmission efficiency in wireless communication can be improved.
  • individual transmission opportunities may be prioritized for each access category (AC) using a priority control method called Enhanced Distributed Channel Access (EDCA).
  • EDCA Enhanced Distributed Channel Access
  • SIFS Short Inter Frame Space
  • TXOP Transmission Opportunity
  • the upper limit time of TXOP may be defined individually for AC, for example.
  • the AP STA (also referred to as an Access Point Station or base station) is transferred from a Non-AP STA (also called a Non-Access Point Station or a terminal, hereinafter referred to as Non-AP) to an AP STA (also referred to as an Access Point Station or base station. , AP) is being considered (for example, see Non-Patent Documents 3 to 5).
  • TXOP Sharing from an RD initiator to an RD responder was introduced by the RD (Reverse direction) protocol (see, for example, Non-Patent Document 6).
  • the RD protocol is controlled by the High Throughput (HT) Control field included in the MAC header in the Medium Access Control (MAC) frame shown in FIG. 1A.
  • HT High Throughput
  • MAC Medium Access Control
  • 11ax and 11be are controlled by the A-Control subfield included in the HT Control field.
  • the A-Control subfield includes a Control List.
  • the Control List includes a Control ID subfield and a Control Information subfield.
  • the format (transmission information, size, number of subfields included in the A-Control subfield) of the Control Information subfield changes depending on the value of the Control ID subfield.
  • Control Information subfield will be the CAS Control subfield defined in the format shown in Figure 2.
  • the RD protocol is controlled by changing the value of the RDG/More PPDU subfield in the CAS Control subfield in FIG. 2.
  • Both the RD initiator and the RD responder use the RDG/More PPDU subfield, but the RD initiator controls the value of the subfield with the intent of the RD Grant (RDG), and the RD responder controls the value of the subfield with the intention of the More PPDU.
  • TXOP Sharing using Multi-User Request-To-Send TXOP Sharing (TXS)
  • TXOP Sharing TXS
  • Trigger frame introduced in 11be allows TXOP sharing of a part of the TXOP acquired by an AP to a non-AP (for example, (See Non-Patent Document 7).
  • the AP can instruct one STA to perform TXOP sharing using a Trigger frame with MU-RTS set as the Trigger frame type (for example, called "Trigger Type"). are being considered (for example, see Non-Patent Document 7).
  • Trigger Type the Trigger frame that instructs TXOP sharing will be referred to as "MU-RTS TXS Trigger frame.”
  • FIG. 3 is a diagram showing an example of the Trigger frame.
  • the Trigger frame is a field containing information common to multiple Non-APs (for example, a common information field) for multiple Non-APs subjected to frequency division multiplexing (FDM). Common Info field)) and a field called User Info List.
  • the User Info List may include, for example, one or more fields (for example, a User Info field) containing individual (or unique) information for the Non-AP.
  • the Trigger frame may include a field (for example, "Special User Info field") that includes information for a terminal compatible with 11be (EHT) (not shown).
  • EHT 11be
  • FIG. 4 is a diagram showing an example of the configuration of the Common Info field considered in 11be (see, for example, Non-Patent Document 7).
  • FIG. 5 is a diagram showing a configuration example of the User Info field in the MU-RTS TXS Trigger frame considered in 11be (see, for example, Non-Patent Document 7).
  • FIG. 6 is a diagram showing an example of the configuration of the Special User Info field (see, for example, Non-Patent Document 7).
  • the Trigger Type subfield in the Common Info field shown in FIG. 4 is a subfield that indicates the type of Trigger frame (for example, the type of signal that the AP transmits to the Non-AP).
  • MU-RTS TXS Trigger frame By setting MU-RTS TXS Trigger frame to a predetermined value, it is possible to instruct a predetermined Non-AP.
  • a Non-AP receives an MU-RTS TXS Trigger frame and the Association Identifier (AID) of the Non-AP is specified in the User Info field included in the received MU-RTS TXS Trigger frame
  • the Non-AP Notify the start of TXOP Sharing by transmitting a Clear To Send (CTS) frame, and transmit PPDUs in the subsequent allocation period.
  • CTS Clear To Send
  • Trigger frames can only be sent by APs, so TXOP Sharing cannot be performed from non-APs.
  • the non-AP allocates a partial period of the acquired resource (TXOP) to the AP.
  • TXOP acquired resource
  • the wireless communication system according to Embodiment 1 includes, for example, the Non-AP 100 shown in FIG. 7 and the AP 200 shown in FIG. 8.
  • FIG. 7 is a block diagram showing a configuration example of the Non-AP 100.
  • the Non-AP 100 shown in FIG. 7 includes, for example, a scheduling section 101, a TXS control information generation section 102, a data generation section 103, a MAC information generation section 104, an error correction encoding section 105, a modulation section 106, a radio transmission/reception section 107, a demodulation section 108, an error correction decoding section 109, and a resource request information holding section 110.
  • the scheduling section 101, the TXS control information generation section 102, the data generation section 103, the MAC information generation section 104, and the resource request information holding section 110 may be included in the access control (eg, MAC) section.
  • the access control eg, MAC
  • scheduling section 101 TXS control information generation section 102, data generation section 103, MAC information generation section 104, error correction encoding section 105, modulation section 106, demodulation section 108, error correction decoding section 109, and resource request information holding section
  • At least one of the units 110 may be a control unit.
  • the Non-AP 100 may transmit to the AP 200 a PPDU containing a control signal (for example, MAC information defined in a format based on RDG or MU-RTS TXS Trigger frame) that instructs TXOP Sharing.
  • the AP200 receives a control signal instructing TXOP Sharing, and based on the allocation period, transmits the signal to the non-AP that has shared, another non-AP, or another AP that performs coordination. You may.
  • AP200 may be an AP (also called Associated AP) to which Non-AP100 connects. Further, the AP 200 may be any one of a plurality of APs that perform cooperative transmission with the non-AP 100.
  • the scheduling unit 101 performs scheduling for the AP 200, for example.
  • the scheduling unit 101 uses TXOP Sharing control information applied to the AP 200 (allocation period, communication destination in the allocation period, The communicable traffic type (TID: Traffic Identifier, etc.) may also be determined.
  • the allocation period to the AP 200 may be a part of the period of the TXOP acquired by the Non-AP 100.
  • the communication destination during the allocation period may include control that does not include the Non-AP 100.
  • it may communicate with a Non-AP different from the Non-AP 100 or an AP different from the AP 200 (for example, any AP that performs cooperative transmission).
  • traffic with a high priority may be specified as a traffic type (TID) that can be communicated during the allocation period. This allows transmission to be limited to traffic with a high priority during the allocation period to the AP.
  • TID traffic type
  • the scheduling unit 101 outputs control information for TXOP sharing to the determined AP 200 to the TXS control information generation unit 102.
  • the TXS control information generation unit 102 may generate TXS control information in a predetermined MAC frame format.
  • the TXS control information may be generated as MAC data (also called MAC Protocol Data Unit (MPDU)) including TXS control information in a format based on RDG or MU-RTS TXS Trigger frame, for example. Details will be described later.
  • MPDU MAC Protocol Data Unit
  • the TXS control information generation section 102 may output MAC data including TXS control information to the MAC information generation section 104.
  • the data generation unit 103 may generate MAC data (for example, MPDU format data) to be transmitted to the AP 200, and output the generated data to the MAC information generation unit 104. Note that if data to be transmitted to AP 200 is not held, it is not necessary to output it to MAC information generation section 104.
  • MAC data for example, MPDU format data
  • MAC information generation section 104 combines MAC data including TXS control information from TXS control information generation section 102 and MAC data including a data signal from data generation section 103, and outputs it to error correction encoding section 105.
  • MAC data that combines multiple types of MAC data is sometimes called Aggregated MPDU (A-MPDU).
  • the error correction encoding section 105 may, for example, perform error correction encoding on the MAC data input from the MAC information generation section 104 and output the encoded signal to the modulation section 106.
  • Modulating section 106 may, for example, perform modulation processing on the signal input from error correction encoding section 105 and output the modulated signal to radio transmitting/receiving section 107.
  • the Non-AP100 maps the modulated signal to a specified frequency resource and performs Inverse Fast Fourier Transform (IFFT).
  • IFFT Inverse Fast Fourier Transform
  • An OFDM signal may be formed by converting the signal into a time waveform by Fourier Transform processing and adding a cyclic prefix (CP).
  • the wireless transmitting/receiving section 107 performs wireless transmission processing such as D/A conversion and up-conversion to a carrier frequency on the modulated signal input from the modulation section 106, and sends the signal after the wireless transmission processing to the antenna. It may also be sent to the AP 200 via. Furthermore, the wireless transmitter/receiver 107 receives a signal transmitted from the AP 200 via an antenna, and performs wireless reception processing such as down-conversion to baseband and A/D conversion on the received signal. The signal after the radio reception processing may be output to the demodulation section 108.
  • wireless transmission processing such as D/A conversion and up-conversion to a carrier frequency on the modulated signal input from the modulation section 106
  • the wireless transmitter/receiver 107 receives a signal transmitted from the AP 200 via an antenna, and performs wireless reception processing such as down-conversion to baseband and A/D conversion on the received signal.
  • the signal after the radio reception processing may be output to the demodulation section 108.
  • demodulation section 108 may perform demodulation processing on the signal input from radio transmission/reception section 107 and output the demodulated signal to error correction decoding section 109.
  • the Non-AP 100 may perform CP removal processing and Fast Fourier Transform (FFT) processing.
  • error correction decoding section 109 decodes the signal input from demodulation section 108 to obtain a received data signal from AP 200. For example, if the decoded received data includes AP resource request information, error correction decoding section 109 may output decoded data including AP resource request information to resource request information holding section 110.
  • the resource request information holding unit 110 may acquire (or hold) the resource request information of the AP from the decoded data input from the error correction decoding unit 109 and output the acquired resource request information to the scheduling unit 101.
  • the AP resource request information includes, for example, whether the AP 200 requests resource allocation from the Non-AP 100, the request time for resource allocation in terms of a predetermined bandwidth (e.g., 20 MHz), information regarding the buffer state held by the AP 200 (e.g. , the destination of the buffer to be held, the AC or TID of the buffer to be held, the queue size of each AC and TID, the delay budget (tolerable range of delay), etc.).
  • the resource request information may include buffer status information held by the AP 200 and addressed to a Non-AP other than the Non-AP 100.
  • the AP 200 receives, for example, a PPDU including a control signal instructing TXOP Sharing from the Non-AP 100. Then, the AP 200 performs communication of the permitted traffic type with the permitted destination within the allocation period based on the control signal instructing TXOP Sharing. Furthermore, the AP 200 notifies the non-AP 100 of the resource request information of the AP 200 at a predetermined timing.
  • FIG. 8 is a block diagram showing a configuration example of the AP 200.
  • the AP 200 shown in FIG. 8 includes, for example, a wireless transmitting/receiving section 201, a demodulating section 202, an error correction decoding section 203, a TXS control information acquisition section 204, a scheduling section 205, a data generation section 206, an error correction encoding section 207, and a modulation section. 208 may be provided.
  • the TXS control information acquisition unit 204, the scheduling unit 205, and the data generation unit 206 may be included in the access control (eg, MAC) unit.
  • the access control eg, MAC
  • the wireless transmitting/receiving section 201 receives a received signal using an antenna, performs wireless reception processing such as down conversion and A/D conversion on the received signal, and outputs the signal after the wireless reception processing to the demodulation section 202. Good too. Furthermore, the wireless transmitting/receiving section 201 may perform wireless transmission processing such as up-conversion and D/A conversion on the signal input from the modulation section, and transmit the signal after the wireless transmission processing from the antenna.
  • the demodulator 202 may, for example, perform demodulation processing on the received data input from the wireless transmitter/receiver and output the demodulated signal to the error correction decoder 203.
  • AP 200 may perform, for example, CP removal processing and FFT processing.
  • the error correction decoding section 203 may, for example, decode the demodulated signal input from the demodulation section 202 and output the decoded signal as a received data signal. Further, error correction decoding section 203 may output, for example, MAC data including TXS control information from the received data signal to TXS control information acquisition section 204.
  • the TXS control information acquisition unit 204 extracts TXS control information from the MAC data input from the error correction decoding unit 203, and extracts control information regarding TXOP sharing (allocation period, communication destination during the allocation period, communication possible during the allocation period). At least one of the traffic types (TID), etc.) may be acquired.
  • the TXS control information acquisition unit 204 may output the extracted control information regarding TXOP sharing to the scheduling unit 205.
  • the scheduling unit 205 determines at least one of the signal length, destination, and traffic type of data that can be transmitted in the allocation period, based on the control information related to TXOP sharing input from the TXS control information acquisition unit 204. Good too. Furthermore, the wireless parameters (at least one of signal length, modulation method, error correction coding rate, spatial multiplexing number, transmission power, etc.) to be applied to the transmission data are determined, and the data generation section 206, error correction coding section 207, It may also be output to modulation section 208.
  • the wireless parameters at least one of signal length, modulation method, error correction coding rate, spatial multiplexing number, transmission power, etc.
  • the data generation section 206 may generate a data signal based on the radio parameters input from the scheduling section, and output the data signal to the error correction encoding section 207.
  • the error correction encoding section 207 may perform error correction encoding on the data signal input from the data generation section 206 and output the encoded signal to the modulation section 208.
  • the modulating section 208 may modulate the signal input from the error correction encoding section 207 and output the modulated signal to the wireless transmitting/receiving section 201. Further, when the modulated signal is an OFDM signal, the AP 200 may perform IFFT processing after mapping the modulated signal to a frequency resource and add a CP to form the OFDM signal.
  • operation example 1 in which Non-AP sends TXS information including the allocation period to AP200 in addition to RDG in the HT Control field
  • operation example 2 in which it is included in the MU-RTS TXS Trigger frame and notified.
  • Non-AP 100 for example, TXS control information generation unit 102 transmits TXOP Sharing control information generated by AP 200, and Non-AP 100 allocates a part of the acquired TXOP period to AP 200. I will explain about it.
  • the TXS control information generated by the TXS control information generation unit 102 may include the allocation period from the Non-AP 100 to the AP 200.
  • the allocation period may be a part of the TXOP acquired by the Non-AP 100.
  • the TXS control information including the allocation period may be notified along with the control information (RDG) of the RD protocol.
  • the allocation period of the TXOP to be allocated to the AP 200 may be specified by using the Reserved bit of the Control Information subfield in FIG. 2 as the Allocation Duration subfield.
  • an allocation period with a predetermined granularity for example, in units of 16 us (microseconds)
  • the allocation period may be defined with different granularity (for example, in units larger than 16 [us] or in units smaller than 16 [us]).
  • the granularity may be determined by considering the amount of signaling.
  • a percentage for example, in units of X%) of the remaining period of the TXOP acquired by the Non-AP 100 (time notified in the Duration field of the MAC header) may be notified.
  • the notified allocation period may include an instruction to allocate all remaining periods of the TXOP acquired by the Non-AP 100.
  • Figure 10 shows an example sequence in which Non-AP100 (Non-AP STA1 in Figure 10), which is an RD initiator, notifies RDG and allocation period, and instructs AP200 (AP in Figure 10), which is an RD responder, to perform TXOP sharing. show.
  • Non-AP100 Non-AP STA1 in Figure 10
  • AP200 AP in Figure 10
  • Non-AP100 acquires the right to transmit data and TXOP sharing control information ("Data + HTC" in the figure), sets TXOP, and allocates part or all of the remaining information to AP200 (TXOP sharing ) to demonstrate the behavior.
  • An example of transmitting the included TXS control information (S1001) and instructing AP200 to perform TXOP Sharing is shown.
  • the allocation period is set based on the resource request information of the AP 200 obtained from the AP 200 in advance.
  • the Non-AP 100 considers the buffer status (size, etc.) of high-priority traffic addressed to itself, calculates the period required to transmit that traffic, and sets an allocation period.
  • the AP 200 communicates during the allocation period instructed by the Non-AP 100.
  • the Non-AP 100 transmits a Block Ack (BA) as an acknowledgment (ACK) to the AP 200 (S1003), and after the allocation period to the AP 200 ends, the Non-AP 100 that has acquired the TXOP acquires the remaining TXOP again.
  • BA Block Ack
  • ACK acknowledgment
  • S1003 Block Ack
  • Non-AP 100 sends data to another Non-AP STA2 during the remaining period of the reacquired TXOP (S1004), and Non-AP STA2 sends BA to Non-AP 100 ( S1005)
  • S1005 An example is shown.
  • the TXS control information including the allocation period may be included and notified in the MU-RTS TXS Trigger frame for Non-AP transmission.
  • the allocation period of the TXOP allocated to the AP 200 may be specified in the Allocation Duration subfield of the User Info field shown in FIG.
  • an allocation period with a predetermined granularity for example, in units of 16 [us]
  • the allocation period may be defined with different granularity (for example, in units larger than 16 [us] or in units smaller than 16 [us]). The granularity may be determined by considering the amount of signaling.
  • the allocation period to be notified is not limited to a part of the period of the TXOP acquired by the Non-AP 100, but may include an instruction to allocate the entire remaining period of the TXOP acquired by the Non-AP 100.
  • the Trigger frame for Non-AP transmission may have a different format from the Trigger frame for AP transmission.
  • FIG. 11 shows an example of the Trigger frame format for Non-AP transmission.
  • the connection destination is defined in a User Info List consisting of multiple User Info fields.
  • the connection destination may be limited to the User Info field to which the Non-AP connects. Therefore, as shown in FIG. 11, the User Info List may be composed of one User Info field.
  • Non-AP when a Non-AP sends a Trigger frame for Non-AP transmission to multiple APs, such as when a Non-AP requests notification of resource allocation request information or uplink quality information from multiple APs that perform cooperative transmission, , multiple User Info fields may be included in the User Info List of the Trigger frame for Non-AP transmission.
  • Trigger frame format for AP transmission the frame defined in Frame Control filed in the MAC header is Trigger Subtype (Subtype subfiled value is 0010) of Control Type (Type subfiled value is 01).
  • Trigger frame format for Non-AP transmission to AP
  • the same Type and Subtype as for AP transmission may be used.
  • a Type and/or Subtype different from those for AP transmission may be newly defined for Non-AP transmission.
  • AP Trigger Subtype which is used to trigger the AP, may be newly defined using the Control Type (value of Type subfiled is 01) and the Reserved bits (0000-0001) of the Subtype.
  • Non-AP that receives a Trigger frame for Non-AP transmission (addressed to the AP) can identify from the MAC header that the Trigger frame is addressed to the AP, and therefore can stop subsequent reception processing.
  • the RA Receiveiver Address or Receiving station Address
  • the RA field is set even if the MAC address of AP200 to which Non-AP100 connects is set. good.
  • Broadcast address is set in the RA field. may be done.
  • FIG. 12 shows an example of the Common Info field for non-AP transmission.
  • the Common Info field for non-AP transmission has changed the information to be included and the subfield name, compared to the Common Info field for AP transmission (see Figure 4), such that UL information becomes DL information and STA information becomes AP information. may be done.
  • the UL Length subfield in FIG. 4 may be changed to the DL Length subfield that includes the value of the L-SIG LENGTH field of the Preamble of the downlink signal (PPDU) to which the AP responds.
  • the UL BW subfield in FIG. 4 may be changed to a DL BW subfield that includes the value of the EHT-SIG-A field of the Preamble of the downlink signal (PPDU) to which the AP responds.
  • the size of the DL BW subfield may be defined to be large enough to notify the supported bandwidth.
  • the AP TX Power subfield in FIG. 4 may be changed to the Non-AP STA TX Power subfield that includes the transmission power of the Non-AP 100.
  • some subfields may be deleted from the Common Info field for non-AP transmission compared to the Common Info field for AP transmission (see FIG. 4).
  • the Triggered TXOP Sharing Mode subfield in FIG. 4 may be deleted from the Common Info field when included in the User Info field.
  • the Reserved bit may be deleted.
  • the Special User Info field for AP transmission includes common information for the terminal, but in the Trigger frame for Non-AP transmission, the common information for the terminal is included in the Common Info field. You may be In that case, the Special User Info Field Flag may be deleted from the Common Info field for Non-AP transmission.
  • Figure 13 shows an example of the User Info field for MU-RTS TXS for Non-AP transmission.
  • unnecessary information may be deleted from the User Info field for AP transmission (see FIG. 5).
  • the RA field includes the MAC address of the connected AP
  • the AID12 subfield indicating the identification ID of the connected AP may be deleted.
  • the Reserved bit may be deleted.
  • a subfield may be added to the format of FIG. 13 to notify an ID that identifies an AP from among multiple APs.
  • the MU-RTS TXS Trigger frame and the CTS frame that responds to it may be sent in a non-HT PPDU or non-HT duplicate PPDU.
  • Non-AP100 (Non-AP STA1 in the figure) notifies the MU-RTS TXS Trigger frame including the allocation period and instructs AP200 (AP in the figure) to perform TXOP sharing. Two example sequences are shown.
  • Non-AP100 acquires the right to transmit TXOP sharing control information ("MU-RTS TXS TF" in the figure), sets TXOP, and Non-AP100 shares part or all of the remaining information with AP200.
  • TXOP sharing An example of a sequence for allocation (TXOP sharing) is shown below.
  • Non-AP100 sends an MU-RTS TXS Trigger frame in which the allocation period ("Allocation Duration in MU-RTS TXS TF" in the figure) is included in AD (S1401), and sends TXOP Sharing to AP200. Instructing. As in the example of FIG. 10, the allocation period is set by the non-AP 100 based on the resource request information of the AP 200 acquired from the AP 200 in advance.
  • the AP 200 communicates within the allocation period instructed by the Non-AP 100.
  • the AP 200 first transmits a CTS frame to the Non-AP 100 to notify the start of communication in the allocation period (S1402), and then transmits data (S1403).
  • the Non-AP 100 transmits BA to the AP 200 (S1404) and the allocation period to the AP 200 ends, the Non-AP 100 that has acquired the TXOP acquires the remaining TXOP again.
  • Non-AP 100 sends data to another Non-AP STA2 during the remaining period of the reacquired TXOP (S1405), and Non-AP STA2 sends BA to Non-AP 100 (S1406).
  • S1405 Non-AP STA2 sends BA to Non-AP 100
  • S1406 An example is shown.
  • FIG. 15 shows that Non-AP100 acquires the right to transmit data and TXOP sharing control information ("Data + MU-RTS TXS TF" in the figure), sets TXOP, and An example sequence of allocating the remaining portion to AP200 (TXOP sharing) is shown.
  • Non-AP 100 multiplexes uplink data to AP 200 in addition to the MU-RTS TXS Trigger frame whose allocation period ("Allocation Duration in MU-RTS TXS TF" in the figure) is included in AD.
  • A-MPDU (S1501) and instructs AP200 to perform TXOP Sharing.
  • the AP 200 is the same as FIG. 14, except that after transmitting the CTS frame (S1502), the AP 200 responds with data and BA for uplink data to the non-AP 100 (S1503).
  • transmission efficiency is improved by the non-AP 100 appropriately controlling the allocation period based on the resource request information of itself and the AP 200.
  • TXOP Sharing control information generated by the Non-AP 100 for example, a TXS control information generation unit
  • the Non-AP 100 controls the transmission destination of the AP 200 during the allocation period.
  • the TXS control information generated by the TXS control information generation unit may include information regarding the destination of the AP 200 during the allocation period.
  • Non-AP 100 may permit transmission that does not include Non-AP 100 itself during the allocation period to AP 200.
  • the Non-AP 100 may permit only high-priority traffic (for example, Low Latency traffic).
  • communication that does not include RD Initiator may be permitted only when the AP is RD Responder.
  • the destination information of the AP 200 during the allocation period may be notified along with the control information (RDG) of the RD protocol.
  • RDG control information
  • the destination of the AP 200 reports part of the Reserved bits of the Control Information subfield in FIG. 5 as information regarding the destination of the AP 200 during the allocation period (Destination mode subfield in FIG. 16). may be done.
  • the destination of the AP 200 during the allocation period may be, for example, any of the following information.
  • Non-AP100 knows that AP200 holds high-priority traffic (for example, Low Latency traffic) destined for a different Non-AP than Non-AP100. If so, Non-AP 100 may allow AP 200 to communicate to another Non-AP during the allocation period.
  • high-priority traffic for example, Low Latency traffic
  • Non-AP100 determines that a performance improvement effect can be expected by applying cooperative transmission by multiple APs
  • Non-AP100 determines that an AP that performs cooperative transmission other than AP200 will communicate during the allocated period. may be allowed.
  • Non-AP100 (Non-AP STA1 in the figure), which is an RD initiator, communicates with AP200 (in the figure) during the RDG and allocation period ("Allocation Duration in RDG (Remaining TXOP)" in the figure).
  • An example sequence is shown in which the AP200, which is the RD responder, is notified of the transmission destination and instructs TXOP sharing to the AP200, which is the RD responder.
  • RDG 1
  • An example is shown in which TXOP Sharing is instructed (S1701) to the AP200, including the destination (DM).
  • the destination of the AP 200 during the allocation period is set by the Non-AP 100 based on resource request information obtained from the AP in advance.
  • FIG. 17 shows that the Non-AP 100 allows the AP 200 to communicate with a Non-AP other than the Non-AP 100.
  • Non-AP100 allows response burst transmission without an RD initiator using the RD protocol.
  • the AP 200 After transmitting the BA to the Non-AP 100 (S1702), the AP 200 communicates with the authorized party within the allocation period (S1703) and receives the BA (S1704).
  • AP200 is sending Low Latency traffic to Non-AP STA2.
  • FIG. 18 also allows communication with a Non-AP other than the Non-AP 100.
  • AP200 which is an RD responder, uses a Trigger frame (for example, Basic Trigger frame) to instruct a Non-AP (Non-AP STA2) that is different from Non-AP100 to send uplink data (S1803 ), Non-AP STA2 is transmitting uplink data (S1804). Note that, similar to the specific example described above, this uplink transmission may be limited to Low Latency traffic.
  • the AP can only send a Basic Trigger frame whose Trigger Type is Basic.
  • the AP that is the RD responder may be allowed to transmit the MU-RTS TXS Trigger frame.
  • the AP can TXOP share resources within the allocation period to a Non-AP (a different Non-AP from Non-AP100) that holds a large size of Low Latency traffic. Can be done.
  • the PPDU transmission (Response Burst) during the allocation period may be specified to always include a message addressed to the RD initiator.
  • PPDU transmission during the allocation period may be a specification that does not require the inclusion of an RD initiator.
  • the Non-AP 100 may include the transmission destination information of the AP 200 in the allocation period in the MU-RTS TXS Trigger frame for Non-AP transmission and notify it.
  • the Non-AP 100 uses the Reserved bit of the User Info field shown in Figure 5 to indicate the destination of the AP 200 during the allocation period (Allocation Duration subfield in the diagram). It's okay.
  • the destination of the AP 200 during the allocation period is the same as the specific example of the RD protocol described above.
  • FIG. 19 shows an example in which the AID12 subfield indicating the identification ID of the connected AP and the Reserved bit are deleted.
  • Non-AP100 (Non-AP STA1 in the diagram) is an MU-AP that includes the transmission destination of AP200 (AP in the diagram) during the allocation period ("Allocation Duration in MU-RTS TXS TF" in the diagram).
  • An example sequence is shown that notifies RTS TXS Trigger frame and instructs AP200 to perform TXOP sharing.
  • the Non-AP 100 acquires the right to transmit TXOP sharing control information ("MU-RTS TXS TF" in the figure) and sets TXOP. Then, the Non-AP 100 shows an operation of allocating a part or the rest to the AP 200 (TXOP sharing).
  • TXOP sharing TXOP sharing control information
  • the Non-AP 100 transmits an MU-RTS TXS Trigger frame that includes the transmission destination of the AP 200 during the allocation period (S2001), and instructs the AP 200 to perform TXOP Sharing.
  • the non-AP 100 sets a communication destination that holds high-priority traffic based on the resource request information of the AP 200 acquired from the AP 200 in advance, as in the above example.
  • the AP 200 is communicating with a Non-AP (Non-AP STA2) that is different from the Non-AP 100.
  • Non-AP STA2 Non-AP
  • Non-AP 100 permits transmission that does not include Non-AP 100 during the allocation period.
  • the AP 200 communicates with the authorized party within the allocation period (S2003) and receives the BA (S2004).
  • AP200 sends Low Latency traffic to Non-AP STA2.
  • the AP 200 can transmit high priority traffic (low latency traffic) to other Non-APs 100 during the allocation period from the Non-AP 100. Furthermore, by allowing the non-AP 100 to communicate with other APs that perform cooperative transmission during the allocation period, throughput can be improved through cooperative communication from multiple APs.
  • the Non-AP 100 transmits the TXOP Sharing control information generated by the Non-AP 100 (for example, the TXS control information generation unit) to the AP 200, and controls the traffic type (TID, etc.) that can be communicated in the allocation period.
  • the traffic type TID, etc.
  • the TXS control information generated by the TXS control information generation unit includes information regarding the types of traffic that can be communicated during the allocation period.
  • the Non-AP 100 can limit communication to high-priority traffic (for example, Low Latency traffic) during the allocation period to the AP 200.
  • control information (RDG) of the RD protocol.
  • RDG control information
  • the reserved bit of the Control Information subfield may be used to indicate the type of traffic that can be communicated in the allocation period (Restricted TID Bitmap subfield in the figure).
  • the traffic types that can be communicated during the allocation period may be indicated for each TID, for example, in a bitmap format. If Restricted TID Bitmap subfield is 11000000, only traffic data with TID numbers 0 and 1 can be sent UL/DL during the allocation period. Since the TID is related to the amount of delay allowed, by specifying the TID, only traffic that requires low delay can be transmitted in the allocated section. Note that communicable traffic types may be notified separately for UL and DL. The number of traffic types does not have to be eight (the bitmap is 8 bits).
  • the new Control ID subfield will be added as a new Control ID for Non-AP and AP that support Beyond 11be.
  • the format only needs to be defined.
  • information regarding the traffic types that can be communicated in the allocation period may be included and notified in the MU-RTS TXS Trigger frame for Non-AP transmission.
  • a part of the Reserved bits of the User Info field shown in FIG. 5 may be used to indicate the type of traffic that can be communicated (Restricted TID Bitmap subfield in FIG. 22).
  • Non-AP100 (Non-AP STA1 in the figure) notifies the MU-RTS TXS Trigger frame including the traffic type that can be communicated during the allocation period, and sends a TXOP to AP200 (AP in the figure).
  • An example sequence for instructing sharing is shown.
  • the Non-AP 100 acquires the right to transmit TXOP sharing control information ("MU-RTS TXS TF" in the figure) and sets up TXOP. Then, the Non-AP 100 shows an operation of allocating a part or the rest to the AP 200 (TXOP sharing).
  • TXOP sharing TXOP sharing control information
  • Non-AP100 transmits an MU-RTS TXS Trigger frame that includes the traffic type that can be communicated during the allocation period ("Allocation Duration in MU-RTS TXS TF" in the figure) (S2301), and sends TXOP to AP200. Instructs Sharing.
  • the types of traffic that can be communicated during the allocation period are based on the resource request information of AP200 obtained from AP200 in advance, and the types of traffic that Non-AP100 can communicate based on the priority among the traffic destined for AP200 or from AP200 to another Non-AP.
  • Set a high traffic type TID
  • the Non-AP 100 has set Low Latency traffic as the traffic type that can be communicated during the allocation period.
  • the AP 200 transmits the instructed traffic type within the allocation period (S2303).
  • the AP will not send PPDUs even if the allocation period remains. do not.
  • the Non-AP 100 that has TXOP sharing does not detect a signal for a predetermined period of time (for example, PIFS: Point coordination function (PCF) Inter Frame Space) using carrier sense, it reacquires the TXOP and -AP100 sends data to AP200 (S2405). As a result, only high-priority traffic transmission is performed during the allocation period.
  • PIFS Point coordination function
  • the Non-AP 100 can instruct the AP 200 to transmit traffic (low latency traffic) that has a higher priority than the traffic it owns.
  • Non-AP 100 for example, a resource request information holding unit
  • resource request information of an AP For example, a resource request information holding unit
  • the resource request information that the AP 200 reports to the Non-AP 100 and that the resource request information holding unit generates is, for example, a request flag, request allocation time, or AP transmission buffer information.
  • the request flag is flag information indicating whether or not to request resource allocation to the non-AP 100.
  • the requested allocation time is the requested time for resource allocation in terms of a predetermined bandwidth (for example, 20MHz).
  • the transmission buffer information of the AP is at least one of the destination of the buffer held by the AP, the AC and TID of each buffer, the queue size of each AC and TID, and the delay budget.
  • the resource request information may be individual information for each of the multiple non-APs 100 connected to the AP 200. For example, it may be a set of the terminal ID (association identifier) of the non-AP 100 and a flag indicating whether to request resource allocation. Alternatively, a bitmap of the terminal ID may be used as information on whether to request resource allocation.
  • the Null Data Packet (NDP) Feedback Report in which the Non-AP sends resource request information to the AP may be used.
  • NDP Null Data Packet
  • flag information for multiple Non-APs may be frequency-multiplexed onto a predetermined tone within the channel, thereby transmitting it from the AP 200 to multiple Non-APs 100 in one PPDU.
  • the resource request information may be shared information among multiple non-APs 100 connected to the AP 200.
  • a common flag may be set for multiple Non-APs 100 based on the total buffer amount of multiple Non-APs 100 connected to AP 200.
  • the AP 200 may broadcast a request for resource allocation as broadcast information using a beacon to the plurality of non-APs 100 connected to the AP 200.
  • the transmission buffer information of the AP may include the transmission buffer information of other non-APs connected to the AP.
  • the Non-AP 100 can understand the buffer status and resource allocation request of the AP 200. Therefore, the Non-AP 100 can appropriately allocate necessary resources in TXOP Sharing.
  • the Non-AP 100 can grasp the resource allocation request of the AP 200 with little overhead.
  • the amount of signaling (overhead) will increase compared to the request flag, but since Non-AP100 can grasp the detailed buffer status, The TXOP sharing allocation period can be calculated more accurately.
  • the resource request information may be notified to the AP 200 after the non-AP 100 acquires the TXOP.
  • the AP 200 may multiplex resource request information (A-MPDU) and notify it when transmitting ACK to the non-AP 100.
  • A-MPDU resource request information
  • Non-AP 100 (Non-AP STA1 in the diagram) acquires TXOP, when it sends an ACK ("BA” in the diagram) to AP 200, resource request information ("BA” in the diagram) is sent. You may request that the "RR (Resource Request)" be included.
  • the AP 200 transmits resource request information to the Non-AP 100 in addition to the ACK in accordance with the instruction from the Non-AP 100 (S2502, S2602).
  • the Non-AP 100 determines whether to implement TXOP sharing based on the resource request information from the AP 200.
  • FIG. 25 shows a sequence when the priority of data held by the AP 200 is lower than the priority of data held by the Non-AP 100.
  • the Non-AP 100 does not perform TXOP sharing, gives priority to the data held by the Non-AP 100, and transmits the data held by the Non-AP 100 to the AP 200 in the remaining TXOP (S2503, S2505).
  • FIG. 26 shows a sequence when the priority of data held by AP 200 is higher than the priority of data held by Non-AP 100 (for example, when AP 200 holds Low Latency traffic).
  • the Non-AP 100 performs TXOP sharing (S2603) and gives priority to transmission of data held by the AP 200 (S2604).
  • the Non-AP 100 can appropriately perform TXOP sharing.
  • TXOP Sharing can combine the above descriptions.
  • the Non-AP 100 can give an allocation period to a predetermined traffic type for each destination.
  • the Non-AP 100 can give a predetermined allocated time to the AP 200, and can further give another predetermined allocated time to another AP.
  • Non-AP 100 may provide AP 200 with a predetermined time allocation for Non-AP STA1 and another predetermined time allocation for Non-AP STA2.
  • the resource request information can be buffer information for each traffic type for each STA.
  • the communication device may be configured to switch between Non-AP STA and AP STA depending on the settings.
  • the names of each frame, signal, and format may be different names.
  • the resource request information may have another name. For example, it may be resource information or a resource request.
  • the name of each field and subfield may be different.
  • the User Info field of the Trigger frame sent by Non-AP100 may have a different name. For example, it may be an AP Info field. For example, when performing MAP cooperative transmission, multiple AP Info fields may exist.
  • the Trigger frame sent by Non-AP100 may have a different format (data type and size) from the Trigger frame sent by AP200.
  • the Trigger Type that can be set by Non-AP100 may be part of the Trigger Type that can be set by AP200.
  • the Trigger frame transmitted by the Non-AP 100 may be limited to only Basic and MU-RTS. By restricting the functionality, it becomes easier to implement Trigger frame with Non-AP.
  • a new HT Control field including RDG/More PPDU subfield may be defined.
  • a new Control ID may be added using the Reserved bit, and a new Control Information subfield may be defined.
  • communicable traffic ID TID Constraint subfield in Figure 27
  • allocation period Allocation Duration subfield in Figure 27
  • allocation period A Control Information subfield including at least one of the communication destination information (Destination mode subfield in FIG. 27) may be newly defined.
  • the RDG/More PPDU subfield that instructs TXOP sharing does not include the RDG/More PPDU subfield included in the communication destination information (Destination mode subfield in Figure 28) during the allocation period, and the RD protocol is A possible Control Information subfield may be defined.
  • a format based on RTS frame may be used.
  • the RTS frame's MAC header does not contain an HT Control field (size 0).
  • HT Control field size 0
  • Beyond 11be may define a format that includes an HT Control field in the MAC header of an RTS frame.
  • the HT Control field may be included by wrapping the RTS frame in a Control Wrapper frame.
  • TXOP sharing may be realized with a new RTS frame in which a Control Information subfield as shown in FIGS. 27 and 28 is defined in the A-Control subfield included in the HT Control field.
  • a Control Information subfield as shown in FIGS. 27 and 28 is defined in the A-Control subfield included in the HT Control field.
  • an RTS TXS frame with fields such as those shown in FIGS. 27 and 28 added to the contents of the RTS frame may be defined as a new Control frame.
  • These frames based on the RTS frame may be used in place of the MU-RTS TXS Trigger frame in the above example.
  • Each functional block used in the description of the above embodiment is partially or entirely realized as an LSI that is an integrated circuit, and each process explained in the above embodiment is partially or completely realized as an LSI, which is an integrated circuit. It may be controlled by one LSI or a combination of LSIs.
  • the LSI may be composed of individual chips, or may be composed of a single chip that includes some or all of the functional blocks.
  • the LSI may include data input and output.
  • LSIs are sometimes called ICs, system LSIs, super LSIs, and ultra LSIs depending on the degree of integration.
  • the method of circuit integration is not limited to LSI, and may be realized using a dedicated circuit, a general-purpose processor, or a dedicated processor. Furthermore, an FPGA (Field Programmable Gate Array) that can be programmed after the LSI is manufactured or a reconfigurable processor that can reconfigure the connections and settings of circuit cells inside the LSI may be used.
  • FPGA Field Programmable Gate Array
  • reconfigurable processor that can reconfigure the connections and settings of circuit cells inside the LSI may be used.
  • the present disclosure may be implemented as digital or analog processing.
  • the present disclosure can be implemented in all types of devices, devices, and systems (collectively referred to as communication devices) that have communication capabilities.
  • the communication device may include a wireless transceiver and processing/control circuitry.
  • the wireless transceiver may include a receiving section and a transmitting section, or both as functions.
  • the wireless transceiver (transmitter, receiver) may include an RF (Radio Frequency) module and one or more antennas.
  • RF modules may include amplifiers, RF modulators/demodulators, or the like.
  • Non-limiting examples of communication devices include telephones (mobile phones, smart phones, etc.), tablets, personal computers (PCs) (laptops, desktops, notebooks, etc.), cameras (digital still/video cameras, etc.) ), digital players (e.g.
  • digital audio/video players wearable devices (e.g. wearable cameras, smartwatches, tracking devices), game consoles, digital book readers, telehealth/telemedicine (e.g. These include care/medicine prescription) devices, communication-enabled vehicles or mobile transportation (cars, airplanes, ships, etc.), and combinations of the various devices described above.
  • wearable devices e.g. wearable cameras, smartwatches, tracking devices
  • game consoles digital book readers
  • digital book readers e.g. These include care/medicine prescription) devices, communication-enabled vehicles or mobile transportation (cars, airplanes, ships, etc.), and combinations of the various devices described above.
  • Communication equipment is not limited to portable or movable, but also non-portable or fixed equipment, devices, systems, such as smart home devices (home appliances, lighting equipment, smart meters or It also includes measuring instruments, control panels, etc.), vending machines, and any other "things” that can exist on an Internet of Things (IoT) network.
  • IoT Internet of Things
  • Communication includes data communication using cellular systems, wireless LAN systems, communication satellite systems, etc., as well as data communication using a combination of these.
  • Communication devices also include devices such as controllers and sensors that are connected or coupled to communication devices that perform the communication functions described in this disclosure. Examples include controllers and sensors that generate control and data signals used by communication devices to perform communication functions of a communication device.
  • Communication equipment also includes infrastructure equipment, such as base stations, access points, and any other equipment, devices, or systems that communicate with or control the various equipment described above, without limitation. .
  • a Non-Access Point Station includes a control unit that generates a signal instructing allocation of acquired resources with a specified allocation period, and a control unit that transmits the generated signal. and a wireless transmitter/receiver unit.
  • the signal is a signal that permits transmission where the destination does not include the Non-AP STA.
  • the signal of the Non-AP STA is a signal that permits transmission of a predetermined traffic type when the destination does not include the Non-AP STA.
  • the signal of the Non-AP STA is a signal that permits transmission to other Access Point Stations (AP STA).
  • AP STA Access Point Stations
  • the signal of the Non-AP STA is a signal in which the Non-AP STA instructs the destination.
  • the signal is a signal instructing the AP STA of a traffic ID that can be communicated in the allocation period.
  • the control unit acquires resource request information from the AP STA.
  • the resource request information of the Non-AP STA is a request flag indicating whether to request a resource or not.
  • the resource request information of the Non-AP STA is an allocated time in terms of a predetermined bandwidth.
  • the resource request information of the Non-AP STA is transmission buffer information of the AP STA.
  • the resource request information of the Non-AP STA according to an embodiment of the present disclosure is included in the acknowledgment.
  • the Non-AP STA generates a signal instructing allocation of the acquired resource, with an allocation period specified, and transmits the generated signal.
  • An embodiment of the present disclosure is useful in communication systems.
  • Non-AP100 101, 205 Scheduling section 102 TXS control information generation section 103 Data generation section 104 MAC information generation section 105, 207 Error correction coding section 106, 208 Modulation section 107, 201 Wireless transmission/reception section 108, 202 Demodulation section 109, 203 Error correction decoding Section 110 Resource request information holding section 200 AP200 204 TXS control information acquisition unit 206 Data generation unit

Abstract

Non-Access Point Station (Non-AP STA)は、割当期間が指定された、獲得したリソースを割当てる信号を生成する制御部と、生成した前記信号を送信する無線送受信部と、を具備する。

Description

通信装置、及び通信方法
　本開示は、通信装置、及び通信方法に関する。
　The Institute of Electrical and Electronics Engineers (IEEE)802.11の規格であるIEEE 802.11ax（以下、「11ax」と呼ぶ）の後継規格として、IEEE 802.11be（以下、「11be」と呼ぶ）の技術仕様策定が進められている。11axはHigh Efficiency (HE)とも呼ばれ、11beはExtreme High Throughput (EHT)とも呼ばれる。また、11beの後継規格についても要求仕様の議論が進められている。以下、11beの後継規格を「Beyond 11be」と呼ぶ。
IEEE 802.11-22/0729r1 IEEE 802.11-22/0734r0 IEEE 802.11-20/0005r1 IEEE 802.11-21/0894r6 IEEE 802.11-21/2032r2 IEEE P802.11-REVmeTM/D1.3, June 2022 IEEE P802.11beTM/D2.0, May 2022
　しかしながら、Non-APからAPへのTXOP Sharingを含むリソース割当方法の詳細は議論されていない。
　本開示の非限定的な実施例は、無線通信における伝送効率を向上することができる通信装置、及び通信方法の提供に資する。
　本開示の一実施例に係るNon-Access Point Station (Non-AP STA)は、割当期間が指定された、獲得したリソースの割当を指示する信号を生成する制御部と、生成した前記信号を送信する無線送受信部と、を具備する。
　なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
　本開示の一実施例によれば、例えば、無線通信における伝送効率を向上することができる。
　本開示の一実施例における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および／または効果は、いくつかの実施形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、１つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。
MAC frameの構成例を示す図 HT Control field構成例を示す図 A-Control subfield構成例を示す図 Control List構成例を示す図 Control Information subfield構成例を示す図 CAS Control subfieldの構成例を示す図 Trigger frameの一例を示す図 Common Info fieldの構成例を示す図 MU-RTS TXS Trigger frameにおけるUser Info fieldの構成例を示す図 Special User Info fieldの構成例を示す図 Non-AP100の構成例を示すブロック図 AP200の構成例を示すブロック図 TXOPの割当期間を指示する一例を示す図 RDGと割当期間を通知するシーケンス例を示す図 Non-AP送信用のTrigger frame format例を示す図 Non-AP送信用のCommon Info field例を示す図 Non-AP送信用のMU-RTS TXS用のUser Info field例を示す図 Non-AP100がTXOP sharing制御情報の送信権を獲得し、AP200へ割当てる動作を示す図 Non-AP100がデータとTXOP sharing制御情報の送信権を獲得し、AP200へ割当てる動作を示す図 RD protocolの構成例を示す図 Non-AP100とは別のNon-APとの通信を許可するシーケンス図 RD responderであるAP200が、Trigger frameを用いて Non-AP100とは別のNon-APへ上り送信を指示するシーケンス図 MU-RTS TXS Trigger frameの構成例を示す図 Non-AP100が、割当期間におけるAP200の送信先を含むMU-RTS TXS Trigger frameを送信し、AP200へTXOP Sharingを指示するシーケンス図 RD protocolの構成例を示す図 MU-RTS TXS Trigger frameの構成例を示す図 Non-AP100が、割当期間で通信可能なトラフィック種別を含むMU-RTS TXS Trigger frameを送信し、AP200へTXOP Sharingを指示するシーケンス図 APが保持するLow Latencyトラフィックが少ない場合、TXOP sharingしたNon-AP100が、TXOPを再取得するシーケンス図 AP200が保持するデータの優先度が、Non-AP100が保持するデータの優先度より小さい場合のシーケンス図 AP200が保持するデータの優先度が、Non-AP100が保持するデータの優先度より大きい場合のシーケンス図 HT Control fieldの新たな構成例を示す図 HT Control fieldの新たな構成例を示す図
　以下、本開示の各実施の形態について図面を参照して詳細に説明する。
　11be、及び、Beyond 11beでは、Gamingやvirtual reality (VR)のユースケースを想定し、更なる遅延の低減（Low latency）の必要性が提案されている（例えば、非特許文献１～２を参照）。
　11beでは、11axと同様に、Enhanced Distributed Channel Access (EDCA)と呼ばれる優先制御方式を用いて、アクセスカテゴリ（AC：Access Category）に個別の送信機会の優先付けが行われてよい。EDCAでは、例えば、一度送信権を獲得したACは、最小待ち時間（SIFS：Short Inter Frame Space）間隔での無線信号の連続送信を可能とする。この連続送信が可能な時間は「Transmission Opportunity (TXOP)」と呼ばれてよい。TXOPの上限の時間は、例えば、ACに個別に規定されてよい。
　低遅延を目的の一つとして、Non-AP STA（Non-Access Point Station、又は、端末とも呼ばれる。以下、Non-APと呼ぶ）からAP STA（Access Point Station、又は、基地局とも呼ばれる。以下、APと呼ぶ）へ、Non-APが獲得したTXOPを割り当てる（TXOP sharing）ことが検討される（例えば、非特許文献３～５を参照）。
　IEEE 802.11n（以下、11nと呼ぶ）では、RD (Reverse direction) protocolにより、RD initiatorからRD responderへTXOP Sharingすることが導入された（例えば、非特許文献６を参照）。
　RD protocolは、図１Ａに示すMedium Access Control (MAC) frameにおいて、MAC headerに含まれるHigh Throughput (HT) Control fieldで制御する。
　図１Ｂに示すように、11axおよび11beでは、HT Control fieldに含まれるA-Control subfieldで制御する。
　詳細には、図１Ｃに示すように、A-Control subfieldは、Control Listを含む。
　図１Ｄに示すように、Control Listは、Control ID subfieldとControl Information subfieldを含む。
　図１Ｅに示すように、Control Information subfieldは、Control ID subfieldの値(value)によってフォーマット（送信情報、サイズ、A-Control subfieldに含めるsubfield数）が変わる。
　Control ID subfieldの値がCommand and status (CAS)を示す場合(Control ID value = 6)、Control Information subfieldは、図２に示すフォーマットで定義されるCAS Control subfieldとなる。RD protocolは、図２のCAS Control subfieldにおいて、RDG/More PPDU subfieldの値を変えることで制御する。RD initiatorとRD responderともに、RDG/More PPDU subfieldを用いるが、RD initiatorはRD Grant (RDG)、RD responderはMore PPDUの意図で当該subfieldの値を制御する。
　TXOPを取得したRD initiatorは、RDG subfieldの値を１(RDG subfield = 1)に設定したPhysical layer Protocol Data Unit (PPDU)を送信することで、送信先であるRD responderに対し、RD initiatorが獲得した残りのTXOP期間での送信を許可する。RD responderは、割当てられたTXOP期間（残りのTXOP期間）でRD initiator宛を含むPPDU（Response Burstとも呼ばれる）を送信する。RD responderが割当期間においてPPDUの送信を継続する場合、More PPDU subfieldの値を１(More PPDU subfield = 1)に設定したPPDUを送信する。割り当てられたTXOP期間において、送信すべきデータが無くなり、RD responderが最後のPPDUを送信する場合、More PPDU subfieldの値を０(More PPDU subfield = 0)に設定したPPDUを送信する。これにより、RD responderは、RD initiatorにTXOPを戻すことができる。
　11beで導入されたMulti-User Request-To-Send (MU-RTS) TXOP Sharing (TXS) Trigger frameによるTXOP Sharingでは、APが獲得したTXOPの一部をNon-APへTXOP sharingができる（例えば、非特許文献７を参照）。
　11beでは、例えば、APは、Trigger frameの種別（例えば、「Trigger Type」と呼ぶ）として、MU-RTSを設定したTrigger frameを用いて、１つのSTAに対して、TXOP sharingを指示することが検討されている（例えば、非特許文献７を参照）。以下、TXOP sharingを指示するTrigger frameを「MU-RTS TXS Trigger frame」と呼ぶ。
　図３は、Trigger frameの一例を示す図である。図３に示すように、Trigger frameは、周波数多重（FDM：Frequency Division Multiplexing）される複数のNon-APに対して、複数のNon-APに共通の情報を含めるフィールド（例えば、共通情報フィールド（Common Info field））、及び、User Info Listと称されるフィールドを含む。User Info Listには、例えば、Non-APに個別（あるいは固有）の情報を含めるフィールド（例えば、ユーザ情報フィールド（User Info field））が１つ以上含まれてよい。
　また、11beでは、例えば、Trigger frameに、11be (EHT)に対応する端末向けの情報を含めるフィールド（例えば、「Special User Info field」）が含まれてよい（図示せず）。
　図４は、11beにおいて検討されるCommon Info fieldの構成例を示す図である（例えば、非特許文献７を参照）。
　図５は、11beにおいて検討されるMU-RTS TXS Trigger frameにおけるUser Info fieldの構成例を示す図である（例えば、非特許文献７を参照）。
　図６は、Special User Info fieldの構成例を示す図である（例えば、非特許文献７を参照）。
　例えば、図４に示すCommon Info field内のTrigger Type subfieldは、Trigger frameの種別（例えば、APがNon-APに送信させる信号種別）を指示するsubfieldである。例えば、APは、Trigger Typeの値を、MU-RTSを指示する値（例えば、11beの場合、Trigger Type subfield value = 3）に設定し、及び、Common Info field内のTriggered TXOP Sharing Mode subfieldの値を所定値に設定することにより、MU-RTS TXS Trigger frameを所定のNon-APに指示することができる。
　Non-APは、例えば、MU-RTS TXS Trigger frameを受信し、受信したMU-RTS TXS Trigger frameに含まれるUser Info fieldにおいて当該Non-APのAssociation Identifier (AID)を指定された場合、APへClear To Send (CTS)フレームを送信することでTXOP Sharingの開始を通知し、以降の割当期間でPPDUを送信する。Trigger frameはAPだけが送信できるので、Non-APからTXOP Sharingを行うことはできない。
　Non-APが獲得したTXOPのAPへの割り当ての詳細の検討は十分ではない。
　（実施の形態１）
　実施の形態１では、Non-APは、獲得したリソース(TXOP)の一部期間をAPへ割り当てる。Non-APからAPへの割当期間における通信を効率的に行う方法、トラフィックの優先度に応じた通信を行う方法について説明する。
　実施の形態１に係る無線通信システムは、例えば、図７に示すNon-AP100、及び、図８に示すAP200を備える。
　［Non-AP100の構成例］
　図７は、Non-AP100の構成例を示すブロック図である。
　図７に示すNon-AP100は、例えば、スケジューリング部101、TXS制御情報生成部102、データ生成部103、MAC情報生成部104、誤り訂正符号化部105、変調部106、無線送受信部107、復調部108、誤り訂正復号部109、及びリソース要求情報保持部110を備えてよい。
　例えば、スケジューリング部101、TXS制御情報生成部102、データ生成部103、MAC情報生成部104、及びリソース要求情報保持部110は、アクセス制御（例えば、MAC）部に含まれてよい。
　例えば、スケジューリング部101、TXS制御情報生成部102、データ生成部103、MAC情報生成部104、誤り訂正符号化部105、変調部106、復調部108、誤り訂正復号部109、及びリソース要求情報保持部110の少なくとも１つは、制御部であってもよい。
　Non-AP100は、AP200に対して、TXOP Sharingを指示する制御信号（例えば、RDG又は、MU-RTS TXS Trigger frameをベースとしたフォーマットで定義したMAC情報）を含むPPDUを送信してもよい。AP200は、TXOP Sharingを指示する制御信号を受信し、割当期間に基づいて、SharingしたNon-AP、あるいは、別のNon-AP、あるいは、別の協調送信(coordination)を行うAPへ信号を送信してもよい。AP200はNon-AP100が接続するAP（Associated APとも呼ばれる）としてもよい。また、AP200は、Non-AP100と協調送信を行う複数APのいずれかのAPとしてもよい。
　スケジューリング部101は、例えば、AP200に対するスケジューリングを行う。例えば、スケジューリング部101は、リソース要求情報保持部110から入力された、AP200が保持するバッファ情報に基づいて、AP200に適用するTXOP Sharingの制御情報（割当期間、割当期間における通信先、割当期間において通信可能なトラフィック種別（TID：Traffic Identifier）等）を決定してもよい。
　AP200への割当期間は、Non-AP100が獲得したTXOPの一部の期間としてもよい。
　また、割当期間における通信先は、Non-AP100との通信に限定した制御に加え、Non-AP100を含まない制御を含めてもよい。例えば、Non-AP100とは別のNon-AP、あるいは、AP200とは別のAP（例えば、協調送信を行うAPのいずれか）と通信してもよい。
　また、割当期間において通信可能なトラフィック種別（TID）として優先度が高いトラフィック（例えば、Low Latencyトラフィック）を指示してもよい。これにより、APへの割当期間で優先度が高いトラフィックに限定して送信させることができる。
　スケジューリング部101は、例えば、決定したAP200へのTXOP sharingの制御情報を、TXS制御情報生成部102に出力する。
　TXS制御情報生成部102は、所定のMAC frame formatで、TXS制御情報を生成してもよい。TXS制御情報は、例えば、RDGやMU-RTS TXS Trigger frameをベースとしたフォーマットでTXS制御情報を含むMACデータ（MAC Protocol Data Unit (MPDU)とも呼ばれる）を生成してもよい。詳細は後述する。
　TXS制御情報生成部102は、TXS制御情報を含むMACデータを、MAC情報生成部104へ出力してもよい。
　データ生成部103は、AP200へ送信するMACデータ（例えば、MPDU形式のデータ）を生成し、生成したデータをMAC情報生成部104へ出力してもよい。なお、AP200へ送信するデータを保持しない場合はMAC情報生成部104へ、出力しなくてもよい。
　MAC情報生成部104は、TXS制御情報生成部102からのTXS制御情報を含むMACデータと、データ生成部103からのデータ信号を含むMACデータを結合し、誤り訂正符号化部105へ出力する。なお、複数種別のMACデータを結合したMACデータは、Aggregated MPDU (A-MPDU）と呼ばれることもある。
　誤り訂正符号化部105は、例えば、MAC情報生成部104から入力されるMACデータを誤り訂正符号化し、符号化した信号を変調部106へ出力してもよい。
　変調部106は、例えば、誤り訂正符号化部105から入力される信号に対して変調処理を行い、変調後の信号を無線送受信部107へ出力してもよい。
　なお、変調後のデータ信号が直交周波数分割多重（OFDM：Orthogonal Frequency Division Multiplexing）信号である場合、Non-AP100は、変調信号を規定の周波数リソースにマッピングし、逆高速フーリエ変換（IFFT：Inverse Fast Fourier Transform）処理を行って時間波形に変換し、サイクリックプリフィックス（CP：Cyclic Prefix）を付加することにより、OFDM信号を形成してもよい。
　無線送受信部107は、例えば、変調部106から入力される変調信号に対して、D/A変換、及び、キャリア周波数へのアップコンバートといった無線送信処理を行い、無線送信処理後の信号を、アンテナを介してAP200へ送信してもよい。また、無線送受信部107は、例えば、AP200から送信された信号を、アンテナを介して受信し、受信した信号に対して、ベースバンドへのダウンコンバート、及び、A/D変換といった無線受信処理を行い、無線受信処理後の信号を復調部108へ出力してもよい。
　復調部108は、例えば、無線送受信部107から入力される信号に対して復調処理を行い、復調後の信号を誤り訂正復号部109へ出力してもよい。なお、復調部108に入力される信号がOFDM信号の場合には、Non-AP100は、CP除去処理、及び、高速フーリエ変換（FFT：Fast Fourier Transform）処理を行ってよい。
　誤り訂正復号部109は、例えば、復調部108から入力される信号を復号して、AP200からの受信データ信号を得る。誤り訂正復号部109は、例えば、復号後の受信データにAPのリソース要求情報が含まれる場合、APのリソース要求情報を含む復号データをリソース要求情報保持部110へ出力してもよい。
　リソース要求情報保持部110は、誤り訂正復号部109から入力される復号データから、APのリソース要求情報を取得（または保持）し、取得したリソース要求情報をスケジューリング部101へ出力してもよい。APのリソース要求情報は、例えば、AP200がNon-AP100にリソース割当を要求するか否か、所定帯域幅（例えば、20MHz）換算のリソース割当の要求時間、AP200が保持するバッファ状態に関する情報（例えば、保持するバッファの宛先、保持するバッファのACやTID、各ACおよびTIDのキューサイズ、遅延バジェット（遅延の許容範囲）等の少なくとも１つ）の少なくとも１つでもよい。また、リソース要求情報として、AP200が保持するNon-AP100以外のNon-AP宛のバッファ状態情報を含めてもよい。
　［AP200の構成例］
　AP200は、例えば、Non-AP100から、TXOP Sharingを指示する制御信号を含むPPDUを受信する。そして、AP200は、TXOP Sharingを指示する制御信号に基づいて、割当期間内において、許可された送信先と、許可されたトラフィック種別の通信を行う。また、AP200は、AP200のリソース要求情報を所定のタイミングでNon-AP100へ通知する。
　図８は、AP200の構成例を示すブロック図である。
　図８に示すAP200は、例えば、無線送受信部201、復調部202、誤り訂正復号部203、TXS制御情報取得部204、スケジューリング部205、データ生成部206、誤り訂正符号化部207、及び変調部208を備えてよい。
　例えば、TXS制御情報取得部204、スケジューリング部205、及びデータ生成部206は、アクセス制御（例えば、MAC）部に含まれてよい。
　無線送受信部201は、例えば、受信信号をアンテナによって受信し、受信信号に対して、ダウンコンバート及びA/D変換といった無線受信処理を行い、無線受信処理後の信号を復調部202へ出力してもよい。また、無線送受信部201は、例えば、変調部から入力される信号に対して、アップコンバート及びD/A変換といった無線送信処理を行い、無線送信処理後の信号をアンテナから送信してもよい。
　復調部202は、例えば、無線送受信部から入力される受信データに対して復調処理を行い、復調した信号を誤り訂正復号部203へ出力してもよい。なお、復調部202へ入力される信号がOFDM信号の場合、AP200は、例えば、CP除去処理及びFFT処理を行ってもよい。
　誤り訂正復号部203は、例えば、復調部202から入力される復調信号を復号し、復号された信号を受信データ信号として出力してもよい。また、誤り訂正復号部203は、例えば、受信データ信号のうち、TXS制御情報を含むMACデータを、TXS制御情報取得部204へ出力してもよい。
　TXS制御情報取得部204は、例えば、誤り訂正復号部203から入力されるMACデータから、TXS制御情報を抽出し、TXOP sharingに関する制御情報（割当期間、割当期間における通信先、割当期間において通信可能なトラフィック種別（TID）等の少なくとも１つ）を取得してもよい。TXS制御情報取得部204は、抽出したTXOP sharingに関する制御情報をスケジューリング部205へ出力してもよい。
　スケジューリング部205は、TXS制御情報取得部204から入力されるTXOP sharingに関する制御情報に基づいて、割当期間で送信可能なデータの信号長、送信先、送信するトラフィック種別の少なくとも１つを決定してもよい。また、送信データに適用する無線パラメータ（信号長、変調方式、誤り訂正符号化率、空間多重数、送信電力等の少なくとも１つ）を決定し、データ生成部206、誤り訂正符号化部207、変調部208へ出力してもよい。
　データ生成部206は、スケジューリング部から入力される無線パラメータに基づいて、データ信号を生成し、データ信号を誤り訂正符号化部207へ出力してもよい。
　誤り訂正符号化部207は、データ生成部206から入力されるデータ信号を誤り訂正符号化し、符号化した信号を変調部208へ出力してもよい。
　変調部208は、誤り訂正符号化部207から入力される信号を変調し、変調信号を無線送受信部201へ出力してもよい。また、変調信号がOFDM信号の場合には、AP200は、周波数リソースに変調信号をマッピング後にIFFT処理を行い、CPを付加することにより、OFDM信号を形成してもよい。
　［動作例］
　実施の形態１に係るNon-AP100及びAP200の動作例について説明する。
　割当期間を含むTXS情報を、Non-APがHT Control fieldでRDGに加えてAP200へ送信する動作例１と、MU-RTS TXS Trigger frameに含めて通知する動作例２の２つの例を説明する。
　Non-APが割当期間を制御することで、伝送効率が向上する。
　［動作例１］
　以下では、Non-AP100（例えば、TXS制御情報生成部102）によって生成されるTXOP Sharingの制御情報をAP200へ送信して、Non-AP100が、獲得したTXOPの一部の期間をAP200へ割り当てる例について説明する。
　TXS制御情報生成部102が生成するTXS制御情報には、Non-AP100からAP200への割当期間が含まれてよい。割当期間は、Non-AP100が獲得したTXOPの一部の期間としてもよい。例えば、割当期間を含むTXS制御情報は、RD protocolの制御情報（RDG）に付随させて通知されてもよい。
　具体的には、図９に示すように、図２のControl Information subfieldのReservedビットをAllocation Duration subfieldとして、AP200へ割り当てるTXOPの割当期間が指示されてもよい。例えば、所定粒度（例えば、16[us(マイクロ秒)]単位）の割当期間が通知されてもよい。あるいは、割当期間は、異なる粒度（例えば、16[us]より大きい単位又は16[us]より小さい単位）で定義されてもよい。シグナリング量を考慮して粒度を決定してもよい。または、Non-AP100が獲得したTXOPの残りの期間（MAC headerのDuration fieldで通知される時間）に対する割合（例えば、X%単位）が通知されてもよい。なお、通知される割当期間には、Non-AP100が獲得したTXOPの残り全ての期間が割り当てられる指示が含まれてもよい。
　なお、割当期間を、常にTXOPの残り期間の全てに限定する制御を行う場合、TXOPの残り期間は、MAC headerのDuration fieldで通知されるため、Control Information subfieldのAllocation Duration subfieldの通知は不要となる。
　図１０に、RD initiatorであるNon-AP100（図１０のNon-AP STA1）が、RDGと割当期間を通知し、RD responderであるAP200（図１０のAP）へTXOP sharingを指示するシーケンス例を示す。
　図１０は、Non-AP100がデータとTXOP sharing制御情報（図中の「Data + HTC」）の送信権を獲得し、TXOPを設定して、その一部または残り全部をAP200へ割当てる（TXOP sharingする）動作を示す。
　図１０は、Non-AP100が、AP200への上りデータに加えて、図９に示すフォーマットを用いて、RDG = 1に設定し、割当期間（図１０の「Allocation Duration in RDG」）がADに含まれたTXS制御情報を送信して(S1001)、AP200へTXOP Sharingを指示している例を示す。割当期間は、事前にAP200から取得したAP200のリソース要求情報に基づいて設定する。
　Non-AP100は、自身宛の優先度が高いトラフィックのバッファ状態（サイズ等）を考慮し、そのトラフィックを送信するために必要な期間を算出し、割当期間を設定する。AP200は、Non-AP100から指示された割当期間で通信を行う。
　割当期間で最後のPPDUを送信する場合、More PPDU subfieldの値を０(More PPDU = 0)に設定する(S1002)。Non-AP100がacknowledgement (ACK)としてBlock Ack (BA)をAP200へ送信し(S1003)、AP200への割当期間が終了後、TXOPを獲得したNon-AP100が再び残りのTXOPを取得する。図１０は、Non-AP100が、再び取得したTXOPの残りの期間で、別のNon-AP STA2へデータを送信し(S1004)、Non-AP STA2がBAをNon-AP100へ送信している(S1005)例を示している。
　［動作例２］
　例えば、割当期間を含むTXS制御情報は、Non-AP送信用のMU-RTS TXS Trigger frameに含まれて通知されてもよい。例えば、図５に示すUser Info fieldのAllocation Duration subfieldでAP200へ割り当てるTXOPの割当期間が指示されてもよい。例えば、所定粒度（例えば、16[us]単位）の割当期間が通知されてもよい。あるいは、割当期間は、異なる粒度（例えば、16[us]より大きい単位又は16[us]より小さい単位）で定義されてもよい。シグナリング量を考慮して粒度を決定してもよい。なお、通知する割当期間には、Non-AP100が獲得したTXOPの一部の期間に限定せず、Non-AP100が獲得したTXOPの残り全ての期間が割り当てられる指示が含まれてもよい。
　Non-AP送信用のTrigger frameは、AP送信用のTrigger frameとフォーマットが違ってもよい。図１１に、Non-AP送信用のTrigger frame format例を示す。
　AP送信用のTrigger frame formatでは、接続先が、複数のUser Info fieldで構成されるUser Info Listで定義される。Non-AP送信用のTrigger frame formatでは、接続先が、User Info fieldは、Non-APが接続するAPに限定されてもよい。よって、図１１に示すように、User Info List は、１つのUser Info fieldで構成されてもよい。
　なお、Non-APが、複数の協調送信を行うAPに対してリソース割当要求情報や上り品質情報の通知を要求する場合等、複数AP向けにNon-AP送信用のTrigger frameを送信する場合は、Non-AP送信用のTrigger frameのUser Info Listに複数のUser Info fieldが含まれてもよい。
　また、AP送信用のTrigger frame formatでは、MAC headerのFrame Control filedで定義されるframeは、Control Type（Type subfiledの値が01）のTrigger Subtype（Subtype subfiledの値が0010）である。実施の形態１のNon-AP送信用（AP宛）のTrigger frame formatは、AP送信用と同様のType及びSubtypeが用いられてもよい。あるいは、AP送信用とは異なるType及び／又はSubtypeがNon-AP送信用として新たに定義されてもよい。
　例えば、Control Type（Type subfiledの値が01）とし、SubtypeのReservedビット（0000-0001）を用いて、APをトリガーする用途である「AP Trigger Subtype」が新たに定義されてもよい。
　このように、AP送信用（Non-AP宛）とNon-AP送信用（AP宛）で、Type及び／又はSubtypeを変えることで、Non-APの受信処理量を削減することができる。例えば、Non-AP送信用（AP宛）のTrigger frameを受信したNon-APは、AP宛のTrigger frameであることをMAC headerで識別できるため、以降の受信処理を停止することができる。
　Non-AP送信用（AP宛）のTrigger frame formatでは、RA（Receiver Address、あるいは、Receiving station Address） fieldは、接続AP宛の場合、Non-AP100が接続するAP200のMAC addressが設定されてもよい。Non-APが、複数の協調送信を行うAPに対してリソース割当要求情報の通知を要求する等、複数AP向けにNon-AP送信用Trigger frameを送信する場合は、RA fieldにBroadcast addressが設定されてもよい。
　［通知フォーマット］
　図１２に、Non-AP送信用のCommon Info field例を示す。
　Non-AP送信用のCommon Info fieldは、AP送信用のCommon Info field（図４を参照）に対して、UL情報はDL情報へ、STA情報はAP情報へと、含める情報やsubfield名が変更されてもよい。例えば、図４のUL Length subfieldは、APが応答する下り信号（PPDU）のPreambleのL-SIG LENGTH fieldの中身の値を含めるDL Length subfieldに変更されてもよい。また、図４のUL BW subfieldは、APが応答する下り信号（PPDU）のPreambleのEHT-SIG-A fieldの中身の値を含めるDL BW subfieldに変更されてもよい。なお、DL BW subfieldのサイズはサポートする帯域幅を通知できる大きさのサイズが定義されてもよい。また、図４のAP TX Power subfieldは、Non-AP100の送信電力を含めるNon-AP STA TX Power subfieldに変更されてもよい。
　また、AP送信用のCommon Info field（図４を参照）に対して、Non-AP送信用のCommon Info fieldは、一部のsubfieldが削除されてもよい。例えば、図４のTriggered TXOP Sharing Mode subfieldは、User Info fieldに含める場合、Common Info fieldから削除されてもよい。また、Reservedビットが削除されてもよい。
　また、AP送信用のSpecial User Info field（図６を参照）には端末向けの共通情報が含まれるが、Non-AP送信用のTrigger frameでは、端末向けの共通情報は、Common Info fieldに含まれてもよい。その場合、Non-AP送信用のCommon Info fieldでは、Special User Info Field Flagを削除されてもよい。
　図１３に、Non-AP送信用のMU-RTS TXS用のUser Info field例を示す。
　Non-AP送信用のUser Info fieldでは、AP送信用のUser Info field（図５を参照）に対して、不要な情報（subfield）が削除されてもよい。例えば、上述したように、RA fieldに接続APのMAC addressが含まれる場合、接続APの識別IDを示すAID12 subfieldが削除されてもよい。また、Reservedビットが削除されてもよい。
　なお、RA fieldにBroadcast addressが含まれる場合、図１３のformatに、複数APの中からAPを識別するIDを通知するSubfieldが追加されてもよい。
　古い規格にしか対応しないLegacy STAとの共存のため、MU-RTS TXS Trigger frame及びそれに応答するCTS frameは、non-HT PPDUまたはnon-HT duplicate PPDUに含んで送信されてもよい。
　［シーケンス例］
　図１４、図１５を用いて、Non-AP100（図中のNon-AP STA1）が、割当期間を含むMU-RTS TXS Trigger frameを通知し、AP200（図中のAP）へTXOP sharingを指示する２つのシーケンス例を示す。
　［シーケンス例１］
　図１４は、Non-AP100がTXOP sharing制御情報（図中の「MU-RTS TXS TF」）の送信権を獲得し、TXOPを設定して、Non-AP100が、その一部または残り全部をAP200へ割当てる（TXOP sharingする）シーケンス例を示す。
　図１４では、Non-AP100が、割当期間（図中の「Allocation Duration in MU-RTS TXS TF」）がADに含まれたMU-RTS TXS Trigger frameを送信し(S1401)、AP200へTXOP Sharingを指示している。割当期間は、図１０の例と同様に、Non-AP100が、事前にAP200から取得したAP200のリソース要求情報に基づいて設定する。
　AP200は、Non-AP100から指示された割当期間内で通信を行う。AP200は最初に、割当期間での通信開始を通知するために、Non-AP100へCTSフレームを送信して(S1402)から、データの送信を行う(S1403)。Non-AP100がBAをAP200へ送信して(S1404)、AP200への割当期間が終了後、TXOPを獲得したNon-AP100が再び残りのTXOPを取得する。図１４では、Non-AP100は、再び取得したTXOPの残りの期間で、別のNon-AP STA2へデータを送信し(S1405)、Non-AP STA2がNon-AP100にBAを送信する(S1406)例を示している。
　［シーケンス例２］
　図１５は、Non-AP100がデータとTXOP sharing制御情報（図中の「Data + MU-RTS TXS TF」）の送信権を獲得し、TXOPを設定して、Non-AP100が、その一部又は残り全部をAP200へ割当てる（TXOP sharingする）シーケンス例を示す。
　図１５では、Non-AP100が、割当期間（図中の「Allocation Duration in MU-RTS TXS TF」）がADに含まれたMU-RTS TXS Trigger frameに加えて、AP200への上りデータを多重（A-MPDU）し(S1501)、AP200へTXOP Sharingを指示している。図１５の場合、AP200は、CTSフレームの送信(S1502)後にNon-AP100へデータと共に上りデータに対するBAを応答している(S1503)他は、図１４と同様である。
　上述した具体例に示すように、Non-AP100が自身およびAP200のリソース要求情報をもとに、割当期間を適切に制御することで、伝送効率が向上する。
　［TXOP Sharingにおける送信先］
　以下では、Non-AP100（例えば、TXS制御情報生成部）によって生成されるTXOP Sharingの制御情報をAP200へ送信し、Non-AP100が、割当期間におけるAP200の送信先を制御する方法について説明する。
　TXS制御情報生成部が生成するTXS制御情報には、割当期間におけるAP200の送信先に関する情報が含まれてもよい。例えば、Non-AP100は、AP200への割当期間においてNon-AP100自身を含まない送信を許可してもよい。なお、AP200が、Non-AP100とは別のNon-APと通信する場合、Non-AP100は、優先度が高いトラフィック（例えば、Low Latencyトラフィック）に限定して許可してもよい。また、APがRD Responderの場合のみ、RD Initiatorを含まない通信を許可するようにしてもよい。
　例えば、割当期間におけるAP200の送信先情報は、RD protocolの制御情報（RDG）に付随させて通知されてもよい。具体的には、図１６に示すように、図５のControl Information subfieldのReservedビットの一部を割当期間におけるAP200の送信先に関する情報（図１６のDestination mode subfield）として、AP200の送信先が通知されてもよい。
　割当期間におけるAP200の送信先は、例えば以下の情報のいずれかとしてよい。00：SharingしたNon-AP(Non-AP100)のみ01：SharingしたNon-AP(Non-AP100)、又は別のNon-APs10：SharingしたNon-AP(Non-AP100)、又はSharingするAP(AP200)とは別の協調送信を行うAPs11：SharingしたNon-AP(Non-AP100)、又は別のNon-APs、又はSharingするAP(AP200)とは別の協調送信を行うAPs
　例えば、AP200のリソース要求情報から、AP200がNon-AP100とは別のNon-AP宛の優先度が高いトラフィック（例えば、Low Latency トラフィック）を保持していることを、Non-AP100が把握している場合、Non-AP100は、割当期間でAP200が別のNon-APへ通信することを許可してもよい。
　また、Non-AP100が、複数APによる協調送信を適用することで性能改善効果が期待できると判断した場合、Non-AP100は、AP200とは別の協調送信を行うAPが割当期間で通信することを許可してもよい。
　図１７、図１８に、RD initiatorであるNon-AP100（図中のNon-AP STA1）が、RDGと割当期間（図中の「Allocation Duration in RDG (Remaining TXOP)」）におけるAP200（図中のAP）の送信先を通知し、RD responderであるAP200へTXOP sharingを指示するシーケンス例を示す。
　図１７、図１８は、Non-AP100が、データと共に、TXOP sharingの指示(RDG = 1)及び送信先に関する情報(DM)を含む制御情報の送信権を獲得し、TXOPを設定する（図中の「Data + HTC」）。そして、Non-AP100が、その一部または残り全部をAP200へ割当てる（TXOP sharingする）動作を示す。
　図１７では、Non-AP100が、AP200への上りデータに加えて、例えば、図１６に示すフォーマットを用いて、RDG subfieldの値を1（RDG = 1）に設定し、割当期間におけるAP200の送信先(DM)を含めて、AP200へTXOP Sharingを指示している(S1701)例を示している。割当期間におけるAP200の送信先は、事前にAPから取得したリソース要求情報に基づいて、Non-AP100が設定する。
　図１７は、Non-AP100が、AP200に対してNon-AP100とは別のNon-APとの通信を許可していることを示している。つまり、Non-AP100は、RD protocolでResponse burstでのRD initiatorを含まない送信を許可している。AP200は、Non-AP100にBAを送信した後(S1702)、割当期間内で許可された相手と通信を行い(S1703)、BAを受信する(S1704)。図１７では、AP200はNon-AP STA2へLow Latencyトラフィックを送信している。
　図１８も、図１７と同様に、Non-AP100とは別のNon-APとの通信を許可している。図１８では、RD responderであるAP200が、Trigger frame（例えば、Basic Trigger frame）を用いてNon-AP100とは別のNon-AP（Non-AP STA2）へ上りデータの送信を指示して(S1803)、Non-AP STA2が上りデータを送信している(S1804)。なお、上述した具体例と同様に、この上り送信は、Low Latencyトラフィックに限定されてもよい。
　ここで、11nのRD protocolでは、RD responderがAPの場合、APは、Trigger TypeがBasicであるBasic Trigger frameのみを送信することができる。しかし、本実施の形態は、割当期間において他のNon-APへの通信を許可する場合、RD responderであるAPがMU-RTS TXS Trigger frameを送信することを許可してもよい。例えば、MU-RTS TXS Trigger frame を用いて、APは、大きなサイズのLow Latencyトラフィックを保持するNon-AP（Non-AP100とは別のNon-AP）に割当期間内のリソースをTXOP sharingすることができる。
　なお、Non-APがRD Responderの場合には、割当期間のPPDU送信（Response Burst）は、RD initiator宛が必ず含まれる仕様でもよい。APがRD Responderの場合には、割当期間のPPDU送信は、RD initiatorが含まれる必要がない仕様としてもよい。
　また、例えば、Non-AP100は、割当期間におけるAP200の送信先情報を、Non-AP送信用のMU-RTS TXS Trigger frameに含めて通知してもよい。具体的には、図１９に示すように、図５に示すUser Info fieldのReservedビットを使用して、Non-AP100は、割当期間におけるAP200の送信先（図中のAllocation Duration subfield）を指示してもよい。例えば、割当期間におけるAP200の送信先は、上述のRD protocolの具体例と同様とする。図１９は接続APの識別IDを示すAID12 subfield及びReservedビットが削除された例を示している。
　図２０に、Non-AP100（図中のNon-AP STA1）が、割当期間（図中の「Allocation Duration in MU-RTS TXS TF」）におけるAP200（図中のAP）の送信先を含むMU-RTS TXS Trigger frameを通知し、AP200へTXOP sharingを指示するシーケンス例を示す。
　図２０は、Non-AP100が、TXOP sharing制御情報（図中の「MU-RTS TXS TF」）の送信権を獲得し、TXOPを設定する。そして、Non-AP100が、その一部または残り全部をAP200へ割当てる（TXOP sharingする）動作を示す。
　図２０では、Non-AP100が、割当期間におけるAP200の送信先を含むMU-RTS TXS Trigger frameを送信し(S2001)、AP200へTXOP Sharingを指示している。割当期間におけるAP200の送信先は、上述した例と同様に、Non-AP100が、事前にAP200から取得したAP200のリソース要求情報に基づいて、優先度が高いトラフィックを保持する通信先を設定する。
　図２０では、AP200は、Non-AP100とは別のNon-AP(Non-AP STA2)と通信している。つまり、Non-AP100が、割当期間でのNon-AP100を含まない送信を許可している例を示している。AP200は、CTSをNon-AP100に送信した後(S2002)、割当期間内で許可された相手と通信を行い(S2003)、BAを受信している(S2004)。図２０では、AP200はNon-AP STA2へLow Latencyトラフィックを送信する。
　上述した具体例に示すように、AP200が、Non-AP100からの割当期間で、他のNon-AP100へ優先度が高いトラフィック（Low latency トラフィック）を送信することができる。また、Non-AP100が、割当期間で、他の協調送信を行うAPの通信を許可することで、複数APからの協調通信により、スループットが向上できる。
　［TXOP Sharingのトラフィック種別］
　以下では、Non-AP100が、Non-AP100（例えば、TXS制御情報生成部）によって生成されるTXOP Sharingの制御情報をAP200へ送信し、割当期間で通信可能なトラフィック種別（TID等）を制御する方法について説明する。
　TXS制御情報生成部が生成するTXS制御情報には、割当期間で通信可能なトラフィック種別に関する情報が含まれる。例えば、Non-AP100は、AP200への割当期間において優先度が高いトラフィック（例えば、Low Latencyトラフィック）に通信を限定することができる。
　例えば、割当期間で通信可能なトラフィック種別に関する情報は、RD protocolの制御情報（RDG）に付随させて通知されてもよい。具体的には、図２１に示すように、Control Information subfieldのReservedビットを用いて、割当期間で通信可能なトラフィック種別（図中のRestricted TID Bitmap subfield）が指示されてもよい。
　割当期間で通信可能なトラフィック種別は、例えば、ビットマップ形式によりTID毎に送信可否が指示されてもよい。Restricted TID Bitmap subfield が11000000の場合、TID番号が0, 1のトラフィックデータのみ、割当期間でUL/DL送信が可能となる。TIDは許容される遅延量と関係するため、TIDを指定することにより、低遅延が要求されるトラフィックのみ割り当て区間での送信が可能となる。なお、UL、DLで別々に通信可能なトラフィック種別が通知されてもよい。トラフィック種別は８種類（ビットマップが８ビット）でなくてもよい。
　なお、図２に示すControl ID subfieldの値がCASを指示する場合のControl Information subfieldのサイズと異なる場合、Beyond 11beをサポートするNon-AP、AP向けの新Control IDとして、新たにControl Information subfieldのフォーマットが定義されればよい。
　また、例えば、割当期間で通信可能なトラフィック種別に関する情報は、Non-AP送信用のMU-RTS TXS Trigger frameに含めて通知されてもよい。具体的には、図２２に示すように、図５に示すUser Info fieldのReservedビットの一部を使用して、通信可能なトラフィック種別（図２２のRestricted TID Bitmap subfield）が指示されてもよい。
　図２３、図２４に、Non-AP100（図中のNon-AP STA1）が、割当期間で通信可能なトラフィック種別を含むMU-RTS TXS Trigger frameを通知し、AP200（図中のAP）へTXOP sharingを指示するシーケンス例を示す。
　図２３、図２４は、Non-AP100が、TXOP sharing制御情報（図中の「MU-RTS TXS TF」）の送信権を獲得しTXOPを設定する。そして、Non-AP100が、その一部または残り全部をAP200へ割当てる（TXOP sharingする）動作を示す。
　図２３では、Non-AP100が、割当期間（図中の「Allocation Duration in MU-RTS TXS TF」）で通信可能なトラフィック種別を含むMU-RTS TXS Trigger frameを送信し(S2301)、AP200へTXOP Sharingを指示している。割当期間で通信可能なトラフィック種別は、事前にAP200から取得したAP200のリソース要求情報に基づいて、Non-AP100が、AP200、あるいは、AP200から別のNon-AP宛のトラフィックの中で優先度が高いトラフィック種別（TID）を設定する。
　図２３では、Non-AP100は、割当期間で通信可能なトラフィック種別としてLow Latencyトラフィックを設定している。AP200は、割当期間内で指示されたトラフィック種別を送信する(S2303)。
　なお、割当期間が適切に設定されなかった場合など、Non-AP100から指示された割当期間に対し、APが保持するLow Latencyトラフィックが少ない場合、APは、割当期間が残っていてもPPDUを送信しない。図２４に示すように、TXOP sharingしたNon-AP100は、キャリアセンスで所定時間（例えば、PIFS：Point coordination function (PCF) Inter Frame Space）、信号を検出しない場合、TXOPを再取得して、Non-AP100がAP200へデータを送信する(S2405)。これにより、割当期間では、優先度が高いトラフィック送信のみが行われる。
　上述した具体例に示すように、Non-AP100は、自身が保持するトラフィックより優先度が高いトラフィック(Low latencyトラフィック)の送信を、AP200へ指示することができる。
　［TXOP Sharingのリソース要求情報］
　以下では、Non-AP100（例えば、リソース要求情報保持部）が、APのリソース要求情報を要求する方法について説明する。
　APが送信バッファ状態をNon-APへ報告することを可能とする。AP200がNon-AP100へ通知し、リソース要求情報保持部が生成するリソース要求情報は、例えば、要求フラグ、要求割当時間、APの送信バッファ情報のいずれかとする。
　要求フラグは、Non-AP100にリソース割当を要求するか否かのフラグ情報である。
　要求割当時間は、所定帯域幅（例えば、20MHz）換算のリソース割当の要求時間である。
　APの送信バッファ情報は、APが保持するバッファの宛先、及び各バッファのACやTID、各ACおよびTIDのキューサイズ、遅延バジェットの少なくとも１つである。
　リソース要求情報は、AP200に接続する複数のNon-AP100毎に個別情報としてもよい。例えば、Non-AP100の端末ID（Association identifier）とリソース割当を要求するか否かのフラグのセットとしてもよい。あるいは、端末IDのビットマップで、リソース割当を要求するか否かの情報でもよい。
　リソース割当を要求するか否かのフラグ情報は、Non-APがAPへリソース要求情報を送信するNull Data Packet (NDP) Feedback Reportを流用してもよい。つまり、複数のNon-APへのフラグ情報をチャネル内の所定Toneに周波数多重することで、AP200から複数のNon-AP100へ1つのPPDUで送信してもよい。
　また、リソース要求情報は、AP200に接続する複数のNon-AP100で共通情報としてもよい。例えば、AP200に接続する複数のNon-AP100のトータルのバッファ量をもとに、複数のNon-AP100で共通のフラグを設定してもよい。この場合、例えば、AP200は、接続する複数のNon-AP100に対し、ビーコンを用いたブロードキャスト情報としてリソース割当の要求を報知してもよい。
　APの送信バッファ情報は、APに接続される他のNon-APの送信バッファ情報を含めてもよい。
　上述した具体例によれば、Non-AP100が、AP200のリソース要求情報を把握することで、Non-AP100は、AP200のバッファ状態やリソース割当の要求を把握できる。したがって、Non-AP100は、TXOP Sharingにおいて、必要なリソースを適切に割り当てられる。
　また、リソース要求情報を、リソース割当の要求フラグにすることで、少ないオーバーヘッドで、Non-AP100がAP200のリソース割当の要求を把握できる。リソース要求情報を、要求割当時間やAP200が保持する送信バッファ情報にすることで、要求フラグよりシグナリング量（オーバーヘッド）が増加するものの、Non-AP100が詳細なバッファ状態を把握できるので、AP200へのTXOP sharingの割当期間をより正確に算出できる。
　リソース要求情報は、Non-AP100がTXOPを獲得した後でAP200に通知させてもよい。例えば、AP200は、Non-AP100へのACK送信時にリソース要求情報を多重（A-MPDU）して通知してもよい。
　例えば、図２５、図２６に示すように、Non-AP100（図中のNon-AP STA1）がTXOP獲得後、AP200に対し、ACK（図中の「BA」）送信時にリソース要求情報（図中の「RR (Resource Request)」）を含めることを要求してもよい。図２５、図２６では、Non-AP100は、AP200宛のデータに加えて、値を0に設定したRDG subfield（図中の「RDG = 0」）とリソース要求情報の送信を促す情報（例えば、RR Poll信号と呼ぶ。（図中の「RR Poll」））をAP200へ送信する(S2501,S2601)。
　AP200は、Non-AP100からの指示に従い、ACKに加えて、リソース要求情報をNon-AP100へ送信する(S2502,S2602)。
　Non-AP100は、取得したTXOP内で、AP200からのリソース要求情報をもとに、TXOP sharingの実施を判断する。
　図２５は、AP200が保持するデータの優先度が、Non-AP100が保持するデータの優先度より小さい場合のシーケンスを示す。この場合、Non-AP100は、TXOP sharingを実施せず、Non-AP100が保持するデータを優先し、残りのTXOPでは、Non-AP100が保持するデータをAP200へ送信する(S2503,S2505)。
　図２６は、AP200が保持するデータの優先度が、Non-AP100が保持するデータの優先度より大きい場合（例えば、AP200がLow Latencyトラフィックを保持する場合）のシーケンスを示す。この場合、Non-AP100は、TXOP sharingを実施し(S2603)、AP200が保持するデータの送信を優先する(S2604)。
　上述した具体例によれば、AP200がNon-AP100より高優先のトラフィックを保持する場合に、Non-AP100はTXOP sharingを適切に実施できる。
　［変形例］
　TXOP Sharingは、上述した記載を組み合わせることができる。
　例えば、Non-AP100は、送信先毎に所定のトラフィック種別に対して割当期間を与えることができる。例えば、Non-AP100は、AP200に対して所定の割当時間を与え、別のAPに対してさらに別の所定の割当時間を与えることができる。例えば、Non-AP100は、AP200に対してNon-AP STA1に対する所定の割当時間及びNon-AP STA2に対する別の所定の割当時間を与えることができる。例えば、リソース要求情報は、STA毎のトラフィック種別毎のバッファ情報とすることができる。また、設定によりNon-AP STAとAP STAを切り替えるような通信装置としてもよい。
　各フレーム、信号、及びフォーマットの名称は別の名称でもよい。リソース要求情報は別の名称でもよい。例えば、リソース情報又はリソース要求でもよい。
　各field及びsubfieldの名称は別の名称でもよい。Non-AP100が送信するTrigger frameのUser Info fieldは別の名称でもよい。例えば、AP Info fieldでもよい。例えばMAP協調送信を行う場合、AP Info fieldが複数存在してもよい。
　Non-AP100が送信するTrigger frameは、AP200が送信するTrigger frameとフォーマット（データ種別やサイズ）を変えてもよい。例えば、Non-AP100が設定可能なTrigger TypeはAP200が設定可能なTrigger Typeの一部としてもよい。例えば、Non-AP100が送信するTrigger frameは、BasicとMU-RTSのみに制限してもよい。機能を制限することで、Non-APによるTrigger frameの実装が容易になる。
　RDG/More PPDU subfieldを含むHT Control fieldが新たに定義されてもよい。例えば、A-Control fieldにおいて、Reservedビットを利用してControl IDを新たに追加し、新たなControl Information subfieldが定義されてもよい。
　例えば、図２７に示すように、TXOP sharingを指示するRDG/More PPDU subfieldに加えて、通信可能なトラフィックID（図２７のTID Constraint subfield）、割当期間（図２７のAllocation Duration subfield）、割当期間における通信先情報（図２７のDestination mode subfield）の少なくとも１つを含むControl Information subfieldが新たに定義されてもよい。
　また、図２８に示すように、TXOP sharingを指示するRDG/More PPDU subfieldは、割当期間における通信先情報（図２８のDestination mode subfield）に含めたRDG/More PPDU subfieldを含まず、RD protocolが実現できるControl Information subfieldが定義されてもよい。
　本開示では、RD protocol、MU-RTS TXS Trigger frameを用いたフォーマット例を記載したが、フォーマットはこれに限定されない。
　例えば、RTS frameをベースにしたフォーマットでもよい。RTS frameのMAC headerにはHT Control fieldが含まれない（サイズが0）。例えば、Beyond 11beでは、RTS frameのMAC headerにHT Control fieldを含めるフォーマットが定義されてもよい。あるいは、Control Wrapper frameにRTS frameを包むことでHT Control fieldが含まれてもよい。
　そして、HT Control fieldに含まれるA-Control subfieldに、図２７や図２８に示すようなControl Information subfieldが定義された新RTS frameでTXOP sharingを実現してもよい。または、RTS frameの内容に図２７や図２８のようなfieldが追加されたRTS TXS frameが新Control frameとして定義されてもよい。RTS frameをベースにしたこれらのframeは、上述の具体例におけるMU-RTS TXS Trigger frameの代わりに用いられてもよい。
　本開示はソフトウェア、ハードウェア、又は、ハードウェアと連携したソフトウェアで実現することが可能である。上記実施の形態の説明に用いた各機能ブロックは、部分的に又は全体的に、集積回路であるＬＳＩとして実現され、上記実施の形態で説明した各プロセスは、部分的に又は全体的に、一つのＬＳＩ又はＬＳＩの組み合わせによって制御されてもよい。ＬＳＩは個々のチップから構成されてもよいし、機能ブロックの一部または全てを含むように一つのチップから構成されてもよい。ＬＳＩはデータの入力と出力を備えてもよい。ＬＳＩは、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
　集積回路化の手法はＬＳＩに限るものではなく、専用回路、汎用プロセッサ又は専用プロセッサで実現してもよい。また、ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。本開示は、デジタル処理又はアナログ処理として実現されてもよい。
　さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
　本開示は、通信機能を持つあらゆる種類の装置、デバイス、システム（通信装置と総称）において実施可能である。通信装置は無線送受信機（トランシーバー）と処理／制御回路を含んでもよい。無線送受信機は受信部と送信部、またはそれらを機能として、含んでもよい。無線送受信機（送信部、受信部）は、ＲＦ（Ｒａｄｉｏ　Ｆｒｅｑｕｅｎｃｙ）モジュールと１または複数のアンテナを含んでもよい。ＲＦモジュールは、増幅器、ＲＦ変調器／復調器、またはそれらに類するものを含んでもよい。通信装置の、非限定的な例としては、電話機（携帯電話、スマートフォン等）、タブレット、パーソナル・コンピューター（ＰＣ）（ラップトップ、デスクトップ、ノートブック等）、カメラ（デジタル・スチル／ビデオ・カメラ等）、デジタル・プレーヤー（デジタル・オーディオ／ビデオ・プレーヤー等）、着用可能なデバイス（ウェアラブル・カメラ、スマートウオッチ、トラッキングデバイス等）、ゲーム・コンソール、デジタル・ブック・リーダー、テレヘルス・テレメディシン（遠隔ヘルスケア・メディシン処方）デバイス、通信機能付きの乗り物又は移動輸送機関（自動車、飛行機、船等）、及び上述の各種装置の組み合わせがあげられる。
　通信装置は、持ち運び可能又は移動可能なものに限定されず、持ち運びできない又は固定されている、あらゆる種類の装置、デバイス、システム、例えば、スマート・ホーム・デバイス（家電機器、照明機器、スマートメーター又は計測機器、コントロール・パネル等）、自動販売機、その他ＩｏＴ（Ｉｎｔｅｒｎｅｔ　ｏｆ　Ｔｈｉｎｇｓ）ネットワーク上に存在し得るあらゆる「モノ（Things）」をも含む。
　通信には、セルラーシステム、無線ＬＡＮシステム、通信衛星システム等によるデータ通信に加え、これらの組み合わせによるデータ通信も含まれる。
　また、通信装置には、本開示に記載される通信機能を実行する通信デバイスに接続又は連結される、コントローラやセンサー等のデバイスも含まれる。例えば、通信装置の通信機能を実行する通信デバイスが使用する制御信号やデータ信号を生成するような、コントローラやセンサーが含まれる。
　また、通信装置には、上記の非限定的な各種装置と通信を行う、あるいはこれら各種装置を制御する、インフラストラクチャ設備、例えば、基地局、アクセスポイント、その他あらゆる装置、デバイス、システムが含まれる。
　本開示の一実施例に係るNon-Access Point Station (Non-AP STA)は、割当期間が指定された、獲得したリソースの割当を指示する信号を生成する制御部と、生成した前記信号を送信する無線送受信部と、を具備する。
　本開示の一実施例に係るNon-AP STAは、前記信号は、送信先が前記Non-AP STAを含まない送信を許可する信号である。
　本開示の一実施例に係るNon-AP STAの前記信号は、送信先が前記Non-AP STAを含まない場合は所定トラフィック種別の送信を許可する信号である。
　本開示の一実施例に係るNon-AP STAの前記信号は、他のAccess Point Station (AP STA)への送信を許可する信号である。
　本開示の一実施例に係るNon-AP STAの前記信号は、送信先を前記Non-AP STAが指示する信号である。
　本開示の一実施例に係るNon-AP STAは、前記信号は、AP STAに対して前記割当期間で通信可能なトラフィックIDを指示する信号である。
　本開示の一実施例に係るNon-AP STAは、前記制御部は、AP STAからリソース要求情報を取得する。
　本開示の一実施例に係るNon-AP STAの前記リソース要求情報は、リソースを要求するか要求しないかを示す要求フラグである。
　本開示の一実施例に係るNon-AP STAのリソース要求情報は、所定帯域幅換算の割当時間である。
　本開示の一実施例に係るNon-AP STAの前記リソース要求情報は、前記AP STAの送信バッファ情報である。
　本開示の一実施例に係るNon-AP STAの前記リソース要求情報は、肯定応答に含まれている。
　本開示の一実施例に係る通信方法において、Non-AP STAは、割当期間が指定された、獲得したリソースの割当を指示する信号を生成し、生成した前記信号を送信する。
　２０２２年８月１９日出願の特願２０２２－１３１１６４の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
　本開示の一実施例は、通信システムに有用である。
　１００　Non-AP100
　１０１，２０５　スケジューリング部
　１０２　TXS制御情報生成部
　１０３　データ生成部
　１０４　MAC情報生成部
　１０５，２０７　誤り訂正符号化部
　１０６，２０８　変調部
　１０７，２０１　無線送受信部
　１０８，２０２　復調部
　１０９，２０３　誤り訂正復号部
　１１０　リソース要求情報保持部
　２００　AP200
　２０４　TXS制御情報取得部
　２０６　データ生成部
 

 

Claims (12)

  1. 　割当期間が指定された、獲得したリソースの割当を指示する信号を生成する制御部と、
    　生成した前記信号を送信する無線送受信部と、
    　を具備するNon-Access Point Station (Non-AP STA)。
  2. 　前記信号は、送信先が前記Non-AP STAを含まない送信を許可する信号である、
    　請求項１に記載のNon-AP STA。
  3. 　前記信号は、送信先が前記Non-AP STAを含まない場合は所定トラフィック種別の送信を許可する信号である、
    　請求項２に記載のNon-AP STA。
  4. 　前記信号は、他のAccess Point Station (AP STA)への送信を許可する信号である、
    　請求項２に記載のNon-AP STA。
  5. 　前記信号は、送信先を前記Non-AP STAが指示する信号である、
    　請求項２に記載のNon-AP STA。
  6. 　前記信号は、AP STAに対して前記割当期間で通信可能なトラフィックIDを指示する信号である、
    　請求項１に記載のNon-AP STA。
  7. 　前記制御部は、AP STAからリソース要求情報を取得する、
    　請求項１に記載のNon-AP STA。
  8. 　前記リソース要求情報は、リソースを要求するか要求しないかを示す要求フラグである、
    　請求項７に記載のNon-AP STA。
  9. 　前記リソース要求情報は、所定帯域幅換算の割当時間である、
    　請求項７に記載のNon-AP STA。
  10. 　前記リソース要求情報は、前記APの送信バッファ情報である、
    　請求項７に記載のNon-AP STA。
  11. 　前記リソース要求情報は、肯定応答に含まれている、
    　請求項７に記載のNon-AP STA。
  12. 　Non-AP STAは、
    　割当期間が指定された、獲得したリソースの割当を指示する信号を生成し、
    　生成した前記信号を送信する、
    　通信方法。
PCT/JP2023/029821 2022-08-19 2023-08-18 通信装置、及び通信方法 WO2024038905A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022-131164 2022-08-19
JP2022131164 2022-08-19

Publications (1)

Publication Number Publication Date
WO2024038905A1 true WO2024038905A1 (ja) 2024-02-22

Family

ID=89941810

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/029821 WO2024038905A1 (ja) 2022-08-19 2023-08-18 通信装置、及び通信方法

Country Status (1)

Country Link
WO (1) WO2024038905A1 (ja)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210315009A1 (en) * 2020-04-01 2021-10-07 Sony Corporation Coordinated wifi stations with shared txop in time domain

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210315009A1 (en) * 2020-04-01 2021-10-07 Sony Corporation Coordinated wifi stations with shared txop in time domain

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SHUBHODEEP ADHIKARI (BROADCOM): "Proposals on Latency Reduction", IEEE DRAFT; 11-20-0005-01-00BE-PROPOSALS-ON-LATENCY-REDUCTION, IEEE-SA MENTOR, PISCATAWAY, NJ USA, vol. 802.11 EHT; 802.11be, no. 1, 15 March 2020 (2020-03-15), Piscataway, NJ USA , pages 1 - 13, XP068167055 *

Similar Documents

Publication Publication Date Title
US11395349B2 (en) Wireless communication method and wireless communication terminal for receiving data from plurality of wireless communication terminals
US11825558B2 (en) Wireless communication method using enhanced distributed channel access, and wireless communication terminal using same
US11700546B2 (en) Multi-user wireless communication method and wireless communication terminal using same
US11637679B2 (en) Wireless communication method using trigger information, and wireless communication terminal
CN112217759B (zh) 发送关于缓冲状态信息的无线通信方法和无线通信终端
KR102054052B1 (ko) 무선 통신 방법 및 무선 통신 단말
KR102531753B1 (ko) 장거리 전송을 위한 무선 통신 단말과의 무선 통신 방법 및 이를 사용하는 무선 통신 단말
KR20190058499A (ko) 네트워크 얼로케이션 벡터를 사용하는 무선 통신 방법 및 이를 사용하는 무선 통신 단말
WO2024038905A1 (ja) 通信装置、及び通信方法
WO2022249633A1 (ja) 端末、基地局、及び、通信方法
US20180176789A1 (en) Spatial reuse ppdu indication
WO2024004596A1 (ja) アクセスポイント、端末、及び通信方法
WO2023228566A1 (ja) アクセスポイント、端末、及び通信方法
WO2023243568A1 (ja) アクセスポイント、端末、及び通信方法
WO2022264571A1 (ja) アクセスポイント、端末、及び通信方法
CN112787791B (zh) 使用触发信息的无线通信方法、和无线通信终端
KR20240036014A (ko) 통신 장치 및 통신 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23854939

Country of ref document: EP

Kind code of ref document: A1