WO2023228566A1 - アクセスポイント、端末、及び通信方法 - Google Patents

アクセスポイント、端末、及び通信方法 Download PDF

Info

Publication number
WO2023228566A1
WO2023228566A1 PCT/JP2023/013236 JP2023013236W WO2023228566A1 WO 2023228566 A1 WO2023228566 A1 WO 2023228566A1 JP 2023013236 W JP2023013236 W JP 2023013236W WO 2023228566 A1 WO2023228566 A1 WO 2023228566A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
terminals
transmission
destination
access point
Prior art date
Application number
PCT/JP2023/013236
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 WO2023228566A1 publication Critical patent/WO2023228566A1/ja

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/20Control channels or signalling for resource management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/40Resource management for direct mode communication, e.g. D2D or sidelink
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W74/00Wireless channel access
    • H04W74/04Scheduled access
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies
    • H04W84/02Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10Small scale networks; Flat hierarchical networks
    • H04W84/12WLAN [Wireless Local Area Networks]

Definitions

  • 11ax is also called High Efficiency (HE)
  • EHT Extremely High Throughput
  • the successor standard to 11be is also called “EHT-plus” or “beyond 11be.”
  • IEEE 802.11-21/0268r8 PDT: Channel access for Triggered TXOP Sharing IEEE 802.11-20/1312r8, AP assisted SU PPDU Tx for 11be R1 IEEE 802.11-22/0046r1, Next 802.11 generation after 11be IEEE 802.11-22/0059r0, Beyond ‘be’ IEEE 802.11-22/0039r3, CR for 35.2.1.3 part -2 IEEE 802.11-21/0485r3, EHT TF Clarifications
  • Non-limiting embodiments of the present disclosure contribute to providing an access point, a terminal, and a communication method that can improve transmission opportunity allocation efficiency in wireless communication.
  • the efficiency of allocating transmission opportunities in wireless communication can be improved.
  • AP Access Point
  • base station base station
  • TXOP sharing procedure for example, "Triggered TXOP sharing procedure"
  • 11be supports TXOP sharing to suppress STA uplink signal collisions and improve throughput performance through simple processing at the AP.
  • P2P peer to peer
  • DIL Direct Link
  • FIG. 1 is a diagram showing an example of a Trigger frame.
  • the Trigger frame is a field containing information common to multiple terminals (for example, a "Common Info field") for multiple terminals subjected to frequency division multiplexing (FDM). )”) and a field called User Info List.
  • the User Info List may include, for example, one or more fields (eg, "User Info field”) that include information that is individual (or unique) to the terminal.
  • FIG. 2 is a diagram showing a configuration example of a Common Info field considered in 11be (e.g., EHT) (see, e.g., Non-Patent Document 5).
  • FIG. 3 is a diagram showing a configuration example of the User Info field in the MU-RTS TXS TF considered in 11be (EHT) (see, for example, Non-Patent Document 5).
  • FIG. 4 is a diagram showing an example of the configuration of the Special User Info field (see, for example, Non-Patent Document 6).
  • the Trigger Type subfield in the Common Info field shown in FIG. 2 is a subfield that indicates the type of Trigger frame (for example, the type of signal that the AP transmits to the terminal).
  • the AP can instruct MU-RTS TXS Trigger frame to a predetermined terminal.
  • the terminal sends Clear To Send ( CTS) frames may be sent.
  • CTS Clear To Send
  • the area B20-21 in the Common Info field may be recognized as the "GI And HE/EHT-LTF Type" subfield.
  • the GI And HE/EHT-LTF Type subfield may include, for example, HE-Long Training Field (LTF) and parameter information related to EHT-LTF.
  • LTF HE-Long Training Field
  • the information included in the GI And HE/EHT-LTF Type subfield is information that is not used for transmitting a CTS frame that does not include HE/EHT-LTF.
  • TXOP sharing e.g., MU-RTS TXOP Sharing
  • the terminal for example, Send CTS frame to AP.
  • the scheduled terminal can transmit radio frames to the connected AP (e.g., associated AP) during the allocation period corresponding to a part of the TXOP. becomes.
  • TXOP Sharing Mode 1, the terminal does not transmit radio frames to an AP or STA different from the AP to which it connects.
  • the number of terminals that can be specified using the MU-RTS TXS Trigger frame is one, and one User Info field shown in Figure 3 is set in the MU-RTS TXS Trigger frame (for example, (See Patent Document 1).
  • the terminal determines parameters such as the MCS of the transmission signal and transmits a Single User (SU) PPDU in a specified band (for example, 20MHz ⁇ N (N is an integer) band). You may do so.
  • SU Single User
  • N is an integer
  • the method e.g., Trigger frame format or procedure
  • the AP instructs TXOP sharing to multiple terminals for which inter-terminal communication (e.g., P2P-link) is configured has not been sufficiently considered. do not have.
  • a P2P link is set up between terminal 1 (STA 1) and terminal 2 (STA 2), and a P2P link is set up between terminal 3 (STA 3) and terminal 4 (STA 4).
  • STA 1 terminal 1
  • STA 2 terminal 2
  • STA 3 terminal 3
  • STA 4 terminal 4
  • TDLS Tunneled Direct Link Setup
  • terminal 1 and terminal 3 may each determine the time length and transmission destination (for example, connection destination AP or another P2P terminal) of the uplink signal (for example, SU PPDU). Therefore, as shown in FIG. 7, the time length of the SU PPDU may differ between terminal 1 and terminal 3, and therefore the transmission timing and reception timing at the AP may overlap. For example, if the transmission timing and reception timing overlap, an AP that does not support full-duplex communication may not process either the transmission signal or the reception signal. Further, even if the AP supports full-duplex communication, for example, self-interference (when the received signal includes adjacent channel interference of the transmitted signal) may occur, and reception performance may deteriorate.
  • the AP supports full-duplex communication, for example, self-interference (when the received signal includes adjacent channel interference of the transmitted signal) may occur, and reception performance may deteriorate.
  • a SU PPDU frame e.g., DATA to AP in non-TB PPDU
  • the AP may not be able to receive the SU PPDU frame from the terminal 3, and the STA 3 may retransmit the SU PPDU. In this way, the time resources allocated by the AP may not be used effectively.
  • FIG. 8 is a block diagram showing a partial configuration example of the AP 100 according to an embodiment of the present disclosure.
  • a control unit e.g., corresponding to a control circuit
  • a control signal e.g., Trigger frame
  • a control signal is generated that includes information regarding the destination (eg, destination information).
  • a transmitter e.g., corresponding to a transmitter circuit transmits a control signal.
  • FIG. 9 is a block diagram illustrating a partial configuration example of the terminal 200 according to an embodiment of the present disclosure.
  • the receiving unit e.g., corresponding to a receiving circuit
  • sends a control signal e.g., trigger frame
  • a control signal including information regarding a destination e.g, destination information
  • a control unit controls uplink transmission based on the control signal.
  • the AP 100 generates a trigger frame (eg, MU-RTS TXS Trigger frame) that instructs TXOP Sharing to multiple terminals, and transmits the MU-RTS TXS Trigger frame to the terminal 200.
  • a trigger frame eg, MU-RTS TXS Trigger frame
  • scheduling section 101 Common Info generation section 102, User Info generation section 103, Trigger frame generation section 104, error correction encoding section 105, modulation section 106, demodulation section 108, error correction decoding section 109, and , at least one of the terminal information holding units 110 may be included in the control unit shown in FIG. 8, for example.
  • the wireless transmitter/receiver 107 shown in FIG. 10 may be included in the transmitter shown in FIG. 8, for example.
  • the scheduling unit 101 may perform scheduling for the terminal 200, for example. For example, the scheduling unit 101 determines at least the TXOP Sharing mode to be applied to the terminal 200 and the allocated radio resources (for example, the allocated period and allocated band in TXOP sharing) based on the terminal information input from the terminal information holding unit 110. (including one) may be determined.
  • the scheduling unit 101 determines at least the TXOP Sharing mode to be applied to the terminal 200 and the allocated radio resources (for example, the allocated period and allocated band in TXOP sharing) based on the terminal information input from the terminal information holding unit 110. (including one) may be determined.
  • the destination information may include, for example, information indicating whether upstream transmission to the AP 100 is permitted.
  • the destination information may include information indicating a destination that is permitted to transmit and receive signals using the allocated radio resources.
  • the destination information may include permission to communicate with any other terminal different from the multiple terminals 200 to which AP 100 and TXOP sharing are applied, and permission to communicate with another terminal (or permission to communicate with the AP 100). It may also be information indicating either (not permitted).
  • the terminal information may include, for example, Capability information of the terminal 200, transmission buffer status, control information regarding P2P settings, and information regarding Sub-Channel Selective Transmission (SST) Mode.
  • the Capability information may include, for example, information indicating whether the terminal 200 is capable of transmitting and receiving on a channel different from the primary channel (for example, secondary channel).
  • the Capability information includes, for example, information indicating whether or not simultaneous transmission and reception is possible (for example, whether the terminal supports Simultaneous transmit and receive (STR)). ) may be included.
  • STR Simultaneous transmit and receive
  • the transmission buffer status may include, for example, information regarding the AC and size of the transmission buffer addressed to the AP 100 in the terminal 200.
  • the transmission buffer status includes, for example, the AC and size of the transmission buffer destined for another terminal (for example, also called "Direct Link Peer (DLP) STA") connected to the terminal 200 in a P2P link (or Direct Link). may also include information regarding.
  • DLP Direct Link Peer
  • the scheduling unit 101 outputs information regarding the determined TXOP sharing mode and allocated radio resources of each terminal 200 to the Common Info generation unit 102 and the User Info generation unit 103.
  • the Common Info generation unit 102 may, for example, generate control information included in a Common Info field common to the plurality of terminals 200.
  • the Common Info generation unit 102 may generate information on the Trigger type subfield and the TXOP sharing mode subfield, for example, based on information regarding TXOP sharing input from the scheduling unit 101.
  • the Common Info generation unit 102 sets the Trigger type subfield to MU-RTS, and sets the TXOP sharing mode subfield to a predetermined value (for example, in the case of the TXOP sharing mode table in FIG. 11, 1 or more You can generate a MU-RTS TXS Trigger frame by setting it to any value).
  • the Common Info generation unit 102 may output information regarding the generated Common Info field to the Trigger frame generation unit 104.
  • the User Info generation unit 103 may generate control information included in a Special User Info field or a User Info field individual to the terminal 200, for example.
  • the User Info generation unit 103 generates information regarding a Special User Info field or an individual User Info field for each terminal 200 based on a prescribed format, and generates a User Info field including a User Info field for each of the plurality of terminals 200. May generate information about the Info List.
  • the User Info generation unit 103 may output information regarding the User Info List to the Trigger frame generation unit 104, for example.
  • the User Info generation unit 103 determines the ID of the terminal 200 (information in the AID12 subfield) and the allocation to the terminal 200, as shown in FIG.
  • Information about the band e.g., band in 20MHz channel units
  • RU Allocation subfield information information about the allocation period to the terminal 200
  • Allocation Duration subfield information information about transmission and reception using the radio resources allocated to the terminal 200.
  • Destination information (for example, information in the Destination Mode subfield) regarding permitted destinations may be generated.
  • the User Info generation unit 103 may output the generated User Info List to the Trigger frame generation unit 104, for example.
  • FIG. 13 is a diagram illustrating an example of a frequency resource notification method using the MU-RTS Trigger frame.
  • MU-RTS supported in 11ax
  • frequency resources for CTS may be individually notified to the terminal 200.
  • the UL BW subfield specifies the uplink operation bandwidth (for example, 20MHz, 40MHz, 80MHz, or 160MHz)
  • the RU allocation subfield specifies the frequency resources allocated to communication during the allocation period. The location is specified.
  • the channel to be used by the terminal 200 during the TXOP sharing allocation period may be specified by a method similar to the method shown in FIG. 13, for example. Note that the channel to be used by the terminal 200 during the TXOP sharing allocation period may be specified by a method different from the method shown in FIG. 13.
  • the Operation bandwidth may be notified to the terminal 200 by a combination of the UL BW subfield of the Common Info field and the UL Bandwidth Extension subfield of the Special User Info field.
  • the notification method shown in FIG. 13 is a method of notifying the frequency resource position including the Primary 20MHz channel, but the present embodiment is not limited thereto.
  • a method of notifying an arbitrary 20MHz ⁇ N channel frequency resource within the operation band that does not include the operation band may also be used.
  • the destination information that permits transmission and reception using the allocated radio resources is, for example, when the TXOP sharing mode to multiple terminals is applied (for example, when the TXOP Sharing Mode subfield value is 3 in FIG. 11),
  • the terminal 200 may also be notified. For example, when the TXOP Sharing mode is applied to one terminal, the terminal 200 does not need to be notified of destination information that permits transmission and reception using the allocated radio resources.
  • Special User Info field may include control information for one terminal 200, regardless of the TXOP sharing mode.
  • the Trigger frame generation unit 104 generates Common Info field information input from the Common Info generation unit 102 and User Info List (for example, Special User A Trigger frame may be generated that includes information about an Info field and at least one User Info field.
  • the Trigger frame may include, for example, at least one of MAC header, Padding, and frame check sequence (FCS) in addition to Common Info field and User Info List.
  • Trigger frame generation section 104 may output the generated trigger frame to error correction encoding section 105, for example.
  • the error correction encoding section 105 performs error correction encoding on the transmission data signal including the trigger frame input from the trigger frame generation section 104, and outputs the encoded signal to the modulation section 106.
  • the AP 100 maps the modulated signal to a specified frequency resource and performs inverse fast Fourier transform.
  • An OFDM signal may be formed by performing Inverse Fast Fourier Transform (IFFT) processing to convert the signal into a time waveform and adding a cyclic prefix (CP).
  • IFFT Inverse Fast Fourier Transform
  • CP cyclic prefix
  • 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. is transmitted to the terminal 200 via the . Furthermore, the wireless transmitter/receiver 107 receives, for example, a signal transmitted from the terminal 200 via an antenna, and performs wireless reception processing such as down-conversion to baseband and A/D conversion on the received signal. is performed, and the signal after the radio reception processing is output to 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 demodulation section 108 performs demodulation processing on the signal input from the wireless transmission/reception section 107 and outputs the demodulated signal to the error correction decoding section 109.
  • the AP 100 for example, the demodulation unit 108, may perform CP removal processing and Fast Fourier Transform (FFT) processing.
  • FFT Fast Fourier Transform
  • error correction decoding section 109 decodes the signal input from demodulation section 108 to obtain a received data signal from terminal 200. For example, if the decoded received data includes the terminal information described above, the error correction decoding unit 109 outputs decoded data including the terminal information to the terminal information holding unit 110.
  • the terminal information holding unit 110 stores, for example, terminal information (for example, capability information of the terminal 200, transmission buffer status, P2P setting information, or information regarding SST Mode) from the decoded data input from the error correction decoding unit 109.
  • terminal information for example, capability information of the terminal 200, transmission buffer status, P2P setting information, or information regarding SST Mode
  • the terminal information may be acquired (or held) and the acquired terminal information may be output to the scheduling unit 101.
  • FIG. 16 is a block diagram showing a configuration example of the terminal 200.
  • the terminal 200 shown in FIG. 16 includes, for example, a wireless transmitter/receiver 201, a demodulator 202, an error correction decoder 203, a Common Info acquirer 204, a User Info acquirer 205, a scheduler 206, and a data generator. 207, an error correction encoding section 208, and a modulation section 209.
  • At least one of the Common Info acquisition unit 204, the User Info acquisition unit 205, the scheduling unit 206, and the data generation unit 207 may be included in the access control unit (for example, the MAC processing unit).
  • the demodulation section 202, error correction decoding section 203, Common Info acquisition section 204, User Info acquisition section 205, scheduling section 206, data generation section 207, error correction encoding section 208, and modulation section 209 shown in FIG. At least one may be included in the control section shown in FIG. 9, for example. Further, the wireless transmitting/receiving section 201 shown in FIG. 16 may be included in the receiving section shown in FIG. 9, for example.
  • the wireless transmission/reception unit 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 unit 202. Furthermore, the wireless transmitting/receiving section 201 performs wireless transmission processing such as up-conversion and D/A conversion on the signal input from the modulation section 209, and transmits the signal after the wireless transmission processing from the antenna.
  • the demodulation section 202 performs demodulation processing on the received data input from the wireless transmission/reception section 201 and outputs the demodulated signal to the error correction decoding section 203.
  • terminal 200 for example, demodulation section 202 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. Furthermore, the error correction decoding section 203 outputs, for example, the Trigger frame of the received data signal to the Common Info acquisition section 204 and the User Info acquisition section 205.
  • the Common Info acquisition unit 204 may, for example, extract information corresponding to the Common Info field from the Trigger frame input from the error correction decoding unit 203, and acquire terminal common information regarding TXOP sharing.
  • the terminal common information regarding TXOP sharing may include, for example, information regarding TXOP sharing mode and information regarding channels assigned to the terminal 200. Further, the terminal common information may include information regarding the allocation period to the terminal 200. Further, the terminal common information may include, for example, information indicating that the TXOP sharing mode for multiple terminals is based on FDM.
  • the Common Info acquisition unit 204 may output the extracted terminal common information to the User Info acquisition unit 205.
  • the User Info acquisition unit 205 extracts information corresponding to a User Info List (for example, at least one User Info field and Special User Info field) from the Trigger frame input from the error correction decoding unit 203, and User Info field reception processing may be performed based on terminal common information (including, for example, TXOP sharing mode) input from the acquisition unit 204. For example, when the TXOP sharing mode instructs TXOP sharing to multiple terminals, the User Info acquisition unit 205 may perform the process of receiving multiple User Info fields. Further, the User Info acquisition unit 205 may perform reception processing for one User Info field, for example, when the TXOP sharing mode instructs TXOP sharing to one terminal.
  • a User Info List for example, at least one User Info field and Special User Info field
  • the User Info acquisition unit 205 decodes information that identifies the terminal 200 (for example, terminal ID or AID) included in the User Info field, and if it determines that there is an allocation instruction addressed to the terminal 200, the Individual information (e.g., allocated radio resources such as allocation period and allocated channel, destination information regarding destinations that permit transmission and reception using allocated radio resources), and terminal common information (e.g., TXOP Sharing Mode, UL BW information) ) may be obtained from the User Info field.
  • the Individual information e.g., allocated radio resources such as allocation period and allocated channel, destination information regarding destinations that permit transmission and reception using allocated radio resources
  • terminal common information e.g., TXOP Sharing Mode, UL BW information
  • the scheduling unit 206 determines the allocated radio resources and the destination of uplink transmission based on the information input from the User Info acquisition unit 205 (including, for example, terminal individual information and terminal common information). It's fine.
  • the scheduling unit 206 may, for example, control data transmission in the allocated radio resources that have undergone TXOP sharing instructed by the AP 100, based on the allocated radio resources. Control of data transmission may include, for example, control regarding an allocation period, an allocation channel, and a transmission destination within the allocation period.
  • the scheduling unit 206 transmits control information related to data generation (including, for example, radio parameters applied to the data signal (signal length, modulation method, error correction coding rate, spatial multiplexing number, transmission power, etc.)) to the data generation unit. 207.
  • control information related to data generation including, for example, radio parameters applied to the data signal (signal length, modulation method, error correction coding rate, spatial multiplexing number, transmission power, etc.)
  • the signal length of the data may be, for example, within the allocation period instructed by the AP 100.
  • the transmission channel assigned to the data signal may be determined based on the assigned channel instructed by AP 100.
  • the destination within the allocation period may be determined according to the information acquired by the User Info acquisition unit 205. For example, in the definition shown in FIG. 15, if the Destination Mode subfield value of the User Info field is 0, the scheduling unit 206 sets the signal transmission destination in the allocation period to another terminal configured for P2P (for example, limited )do. For example, if the Destination Mode subfield value is 0, the AP 100 does not need to be set as the signal transmission destination during the allocation period.
  • P2P for example, limited
  • the data generation unit 207 generates a data signal (for example, a CTS frame, data addressed to the AP 100, or another terminal destination data) and outputs the data signal to the error correction encoding section 208.
  • a data signal for example, a CTS frame, data addressed to the AP 100, or another terminal destination data
  • the error correction encoding section 208 performs error correction encoding on the data signal input from the data generation section 207 and outputs the encoded signal to the modulation section 209. Note that the coding rate for the data signal may be determined by the terminal 200, for example.
  • one Trigger frame (e.g., MU-RTS TXS Trigger frame) generated by the AP 100 (e.g., the Common Info generation unit 102, the User Info generation unit 103, and the Trigger frame generation unit 104) is used.
  • a method of instructing TXOP sharing for example, allocation of a portion of transmission opportunities (TXOP) acquired by AP 100) to a plurality of terminals 200 (for example, non-AP terminals) will be described.
  • the terminal common information may include, for example, information regarding TXOP sharing mode.
  • the AP 100 may generate TXOP sharing mode subfield information (for example, TXOP sharing mode subfield value) based on the TXOP sharing mode table shown in FIG. 11, for example.
  • the AP 100 may set information regarding TXOP sharing to multiple terminals (for example, information instructing multiple terminals to share a transmission opportunity) in the Common Info field common to the terminals 200 in the Trigger frame.
  • a band included in the transmission band of the MU-RTS TXS Trigger frame transmitted by the AP 100 may be set as the allocated band.
  • the allocated band may be at least a portion of the band to which the MU-RTS TXS Trigger frame is allocated.
  • information regarding the allocation period is not limited to being included in the terminal individual information, and may be included in other areas.
  • information regarding the allocation period may be included in some subfields (eg, UL Length subfield, Reserved subfield) of the Common Info field as terminal common information.
  • another terminal for example, a terminal that has P2P settings with terminal 200
  • is set for example, limited) as a destination to which transmission and reception using the allocated radio resources is permitted.
  • the AP 100 and another terminal may be configured.
  • terminal 200 may select either AP 100 or another terminal as the destination.
  • the AP 100 adds a subfield (for example, Destination Mode subfield) that indicates destination information in the area B29, which is a Reserved area in the existing User Info field in FIG. 3, in the User Info field. You can set it.
  • a subfield for example, Destination Mode subfield
  • the name of the subfield that indicates destination information is not limited to Destination Mode, but may be any other name.
  • the subfield indicating destination information is not limited to the area B29, but may be set in another area.
  • the types of destinations that can be notified in the destination information are not limited to two types as shown in FIG. 15, but may be three or more types.
  • the area B29 of the User Info field shown in Figure 12 is the Destination Mode subfield. If TXOP sharing to multiple terminals is not applied, the area B29 of the User Info field shown in FIG. 12 may be set to another subfield (for example, a Reserved area).
  • the destinations to which transmission and reception using the allocated radio resources of the terminal 200 indicated by the AID12 subfield shown in FIG. 12 are permitted include the AP 100 and Any other terminal (eg, P2P terminal) may be configured.
  • the AP 100 may be permitted.
  • the association between the Destination Mode subfield value and the destination (for example, a P2P terminal and an AP 100 and a P2P terminal) for which transmission and reception using allocated radio resources is permitted is not limited to the example shown in FIG. 15.
  • the destination setting may be such that transmission and reception with the AP 100 is permitted, but transmission and reception with the P2P terminal is not permitted.
  • the destination of the signal transmitted from the terminal 200 and the time length of the transmitted signal may be determined by the terminal 200, for example.
  • the terminal 2 transmits a CTS frame and data using a frequency resource that does not include the primary channel (for example, a band instructed to terminal 2) in response to the MU-RTS TXS Trigger frame. It's fine.
  • the terminal 200 that has received the MU-RTS TXS Trigger frame may transmit the CTS frame based on the carrier sense result in the CTS frequency resource notified by the MU-RTS TXS Trigger frame, for example. For example, if the frequency resource for CTS notified by the MU-RTS TXS Trigger frame does not include a primary channel, the terminal 200 transmits the CTS frame using the notified frequency resource even if the primary channel is busy. good.
  • the base station 100 transmits a response signal (CTS frames) can be received.
  • CTS frames response signal
  • the method of notifying the allocated channel is not limited to the case of indicating the position of the 20 MHz ⁇ N frequency resource allocated to the terminal 200 as described above, and may be a method of notifying other frequency resources.
  • FIG. 17 is a diagram illustrating an example of a sequence when instructing TXOP sharing to multiple terminals and instructing each terminal 200 as to a destination to which transmission and reception using allocated radio resources is permitted.
  • the AP 100 (referred to as "AP") stores multiple terminals 200 different from the AP 100 (Non-AP STA 1 (hereinafter referred to as terminal 1) and Non-AP STA 3 (hereinafter referred to as "terminal 1") in FIG. 17 as terminal common information).
  • terminal 1 Non-AP STA 1
  • terminal 3 Non-AP STA 3
  • terminal common information information regarding the TXOP sharing mode may be instructed to the terminal 3)).
  • the multiple terminals 200 to which TXOP sharing to multiple terminals is applied may be terminals that have been configured for P2P (eg, configured for TDLS or configured for Direct link).
  • a P2P link is set in advance (for example, TDLS is set) between terminal 1 and Non-AP STA 2 (hereinafter referred to as terminal 2), and terminal 3 and Non-AP STA 4 (hereinafter referred to as A P2P link is set in advance (TDLS is set) with the terminal 4).
  • the AP 100 provides destination information (for example, another terminal and AP 100, or permission to communicate with another terminal), information regarding the allocated channel (for example, RU allocation), and information regarding the allocation period (for example, Time allocated in MU- shown in FIG. 17).
  • destination information for example, another terminal and AP 100, or permission to communicate with another terminal
  • information regarding the allocated channel for example, RU allocation
  • information regarding the allocation period for example, Time allocated in MU- shown in FIG. 17. 17.
  • RTS TXS TF the same period is designated as the allocation period for terminal 1 and terminal 3.
  • the terminal 2 or the AP 100 may be specified.
  • the AP 100 allows the terminal 1 to perform uplink transmission to the AP 100, and does not permit the terminal 3 to perform uplink transmission to the AP 100.
  • the AP 100 may instruct terminal 1 and terminal 3 to communicate using orthogonal frequency resources (20 MHz ⁇ N channels), for example.
  • terminal 1 is instructed to use 20MHz channel #1
  • terminal 3 is instructed to use 20MHz channel #2.
  • terminal 1 and terminal 3 transmit a CTS frame addressed to AP 100 ( CTS response) and data signals (DATA) for each destination.
  • CTS response CTS response
  • DATA data signals
  • terminal 1 transmits a CTS frame to AP 100 on the designated 20MHz channel #1, and then sends a data signal (for example, SU PPDU) to AP 100, which is permitted as one of the transmission destinations. You may send it. Further, for example, in FIG. 17, the terminal 3 may transmit a CTS frame to the AP 100 on the instructed 20MHz channel #2, and then transmit a data signal to the terminal 4 that is permitted as a transmission destination.
  • a data signal for example, SU PPDU
  • the AP 100 causes each terminal 200 to transmit (for example, reply) a CTS frame in the allocated band (for example, including a band that does not include the primary channel) specified by the MU-RTS TXS Trigger frame. It's fine. As a result, the AP 100 receives a CTS frame in the allocated band specified by the MU-RTS TXS Trigger frame, thereby allowing the scheduled terminal 200 to start communication in the allocated period (for example, if the instruction from the AP 100 is transmitted normally). be able to understand things).
  • terminal 1 is permitted to communicate with AP 100
  • terminal 3 is permitted to communicate with AP 100. notifications are not allowed.
  • the AP 100 generates a trigger frame that instructs uplink transmission from multiple terminals and includes destination information regarding the upstream transmission destination for each of the multiple terminals 200.
  • Send For example, the AP 100 transmits destination information for multiple terminals 200 (for example, to the AP 100) so that the AP 100 communicates with one terminal 200 among the multiple terminals 200 to which TXOP sharing is applied within the TXOP sharing allocation period. Instructs whether upstream transmission is permitted or not.
  • TXOP sharing can be instructed to multiple terminals 200 using one Trigger frame, so allocation efficiency in TXOP sharing can be improved.
  • the transmission destination of the TXOP shared time resource can be appropriately controlled for a plurality of terminals 200 (for example, P2P terminals), so the transmission timing for the plurality of terminals 200 at the AP 100 can be adjusted. It is possible to prevent the reception timing from overlapping. Therefore, for example, it is possible to prevent an ACK frame transmitted from the AP 100 to a certain terminal 200 and an SU PPDU frame transmitted from another terminal 200 to the AP 100 from overlapping. Therefore, retransmission of SU PPDUs from other terminals 200 due to AP 100 being unable to receive SU PPDU frames from other terminals 200 can be suppressed, and the utilization efficiency of time resources allocated by AP 100 can be improved.
  • a plurality of terminals 200 for example, P2P terminals
  • At least some of the wireless parameters used for TXOP sharing may not be scheduled by the AP 100 but may be determined (or scheduled) by the terminal 200. can be achieved with simple processing.
  • the AP 100 when the AP 100 retains a function of suppressing self-interference, the AP 100 does not need to suppress the transmission timing and reception timing from overlapping in the AP 100.
  • both terminal 1 and terminal 3 are instructed to another terminal (terminal 2 or terminal 4) or AP 100 as a destination to which transmission and reception using the allocated radio resources is permitted, and terminal 1 and terminal 3 , the destination of uplink transmission can be selected flexibly.
  • the AP 100 performs TXOP sharing to multiple terminals based on the MU-RTS TXS Trigger frame format agreed upon in 11be Release 1 (for example, the format specified in 11be Release 1). Notify.
  • 11be Release 1 for example, the format specified in 11be Release 1.
  • a common trigger frame format can be applied to supported terminals 200 (for example, terminals compatible with future versions).
  • the AP 100 can notify the TXOP sharing mode to 11be Release 1 compatible terminals.
  • the terminal individual information notified by the AP 100 includes destination information that permits transmission and reception using the allocated radio resources for each portion of the TXOP sharing allocation period.
  • the destination information may indicate the destination of uplink transmission in each of a plurality of parts (or times) obtained by dividing the TXOP sharing allocation period (a part of time of TXOP).
  • the destination information (for example, information on the Destination Mode subfield) is divided into the first half and the second half of the assignment period, and transmission and reception using the assigned radio resources in the first half and the second half of the assignment period is performed. It may also indicate which destinations are allowed.
  • the value of the Destination Mode subfield is 0, communication to the AP 100 in both the first half and the second half of the allocation period is set to be disallowed.
  • the value of the Destination Mode subfield is 1, communication to the AP 100 in the first half of the allocation period is set to not be permitted, and communication to the AP 100 in the second half of the allocation period is set to be permitted.
  • the value of the Destination Mode subfield is 2 communication to the AP 100 in the first half of the allocation period is set to be permitted, and communication to the AP 100 in the second half of the allocation period is set to not permitted.
  • the value of the Destination Mode subfield is 3 communication to the AP 100 is set to be permitted in both the first half and the second half of the allocation period.
  • the AP 100 instructs the AP 100 to communicate with one terminal 200 among the multiple terminals 200 to which TXOP sharing is applied within the TXOP sharing allocation period. It is possible to prevent timing overlap.
  • modification 1 as shown in FIG. 19, by dividing the period in which transmission to the AP 100 is permitted in the TXOP sharing allocation period, multiple terminals 200 to which TXOP sharing is applied (for example, terminal 1 Even if each of the terminals 200 and 3) holds transmission data addressed to the AP 100 in a buffer, each of the plurality of terminals 200 can transmit transmission data addressed to the AP 100.
  • the setting method for the divided portions of the TXOP sharing allocation period is not limited to this.
  • the number of times the allocation period is divided is not limited to two, and may be divided into three or more periods (or parts).
  • the allocation period is not limited to being divided equally, but may be divided unevenly.
  • Modification 2 of Embodiment 1 In modification 1, as shown in FIG. 18, as a method of notifying destination information indicating destinations to which transmission/reception using allocated radio resources is permitted for each portion of the allocation period of TXOP sharing, although the case where the association between the combination of whether transmission/reception is permitted and the value of the Destination Mode subfield is defined is defined, the present invention is not limited to this.
  • the AP 100 notifies the same terminal 200 of the transmission destination information indicating the destination to which transmission and reception using the allocated radio resources is permitted for each part of the allocation period of TXOP sharing.
  • Multiple User Info fields may be notified, each corresponding to multiple parts of the .
  • the AP 100 transmits destination information indicating whether or not transmission and reception using the allocated radio resources is permitted for each Allocation Duration (for example, for each portion of the allocation period) in multiple User Info fields for the same terminal 200. (For example, Destination Mode) may be specified.
  • multiple User Info fields with the same AID may be arranged in one Trigger frame.
  • Each of the multiple User Info fields corresponds to a different period (part) within the allocation period, for example, and different values can be set for the destination information (for example, the value of the Destination Mode subfield) in each User Info field. be.
  • the wireless communication system may include an AP 100 and a terminal 200 as in the first embodiment.
  • the resource usage efficiency during the allocation period may decrease.
  • 20MHz channel #1 (Primary channel) is assigned to terminal 1 (Non-AP STA 1)
  • 20MHz channel #2 (Secondary channel) is assigned to terminal 3 (Non-AP STA 3).
  • the allocated periods (Time allocated in MU-RTS TXS TF) set for each of the terminals 1 and 3 are different. For example, the allocation period set for terminal 3 is shorter than the allocation period set for terminal 1.
  • the radio resource (assigned band) of 20MHz channel #2 (Secondary channel) indicated by the dotted line becomes an empty resource. Therefore, the radio resource of 20MHz channel #1 (Primary channel) is used by terminal 1. Therefore, since the Primary channel is being used by terminal 1, the carrier sense result at AP100 is Busy, so the radio resource (assigned band) of 20MHz channel #2 (Secondary channel) is a vacant resource (for example, the carrier sense result is Busy). Idle), the AP 100 may not be able to transmit a signal on the resource corresponding to the Secondary channel, which may reduce system performance.
  • the configuration example of AP 100 according to this embodiment may be the same as that shown in FIG. 10.
  • the operation of the scheduling unit 101 may be different from that in the first embodiment.
  • the AP 100 transmits signals from each terminal 200 (for example, in addition to the scheduled terminal 200, the transmission destination of the terminal 200).
  • the maximum transmission power that a P2P terminal (which may include a P2P terminal) can transmit during the allocation period may be notified by including it in the terminal individual information (for example, User Info field) of the Trigger frame. Adjacent channel interference in frequency multiplexing can be suppressed by notifying the maximum transmission power that can be transmitted.
  • TXOP sharing wireless resource allocation
  • TXOP sharing wireless resource allocation from the above-mentioned AP to multiple P2P terminals
  • TXOP sharing wireless resource allocation from Shared AP to pairs of multiple Sharing APs and terminals under the Sharing AP in multiple AP cooperative communication. (including).
  • the TXOP sharing mode for multi-AP cooperative communication may be explicitly notified. For example, in the Reserved area of TXOP Sharing Mode in the Common Info field shown in FIG. 2, the TXOP sharing mode for multiple AP cooperative communication may be notified. Alternatively, a subfield that notifies the TXOP sharing mode for multiple AP cooperative communication may be provided in a part of the subfield of the Common Info field (for example, a part of the subfield that is not used for transmitting a CTS frame).
  • the field that indicates the allocation period of TXOP sharing is not limited to the UL Length subfield, but may be another subfield.
  • the plurality of terminals 200 allocated in TXOP sharing may have signals multiplexed in at least one of a frequency resource and a time resource that are different during the allocation period.
  • another terminal that the terminal 200 reports in P2P communication may be a terminal under the AP 100 to which the terminal 200 connects, or a terminal under a different AP from the AP 100 to which the terminal 200 connects.
  • (supplement) Information indicating whether the terminal 200 supports the functions, operations, or processes shown in each of the embodiments described above is transmitted from the terminal 200 to the AP 100, for example, as capability information or capability parameters of the terminal 200 ( or notification).
  • Information regarding the capabilities or limitations of the terminal 200 may be defined in a standard, for example, or may be implicitly notified to the AP 100 in association with information known in the AP 100 or information sent to the AP 100. .
  • 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.
  • Communication includes data communication using cellular systems, wireless LAN systems, communication satellite systems, etc., as well as data communication using a combination of these.
  • the information regarding the transmission destination indicates whether or not the uplink transmission to the access point is permitted.
  • the plurality of terminals are terminals configured for inter-terminal communication.
  • An embodiment of the present disclosure further includes a receiving circuit that receives a response signal to the control signal in a band specified by the control signal.
  • the information regarding the transmission destination indicates the transmission destination in each of a plurality of parts obtained by dividing the part of time.
  • the allocated time to the terminal allocated to the Primary channel is shorter than the allocated time to the terminal allocated to the Secondary channel.
  • the access point and the plurality of terminals are permitted to communicate in a band that does not include the primary channel.
  • the access point and the plurality of terminals are permitted to communicate in a band that does not include the primary channel during the part of the time.
  • the terminal to which a band that does not include the primary channel is instructed is a terminal to which Sub-Channel Selective (SST) Mode is set.
  • SST Sub-Channel Selective
  • a terminal is a receiver that receives a control signal instructing uplink transmission of a plurality of terminals, the control signal including information regarding a destination of the uplink transmission for each of the plurality of terminals. and a control circuit that controls the uplink transmission based on the control signal.
  • the access point sends a control signal that instructs allocation of uplink transmission to a plurality of terminals, and includes information regarding a destination of the uplink transmission for each of the plurality of terminals. Generating the control signal and transmitting the control signal.
  • An embodiment of the present disclosure is useful for wireless communication systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

アクセスポイントは、複数の端末の上り送信を指示する制御信号であって、複数の端末のそれぞれに対する上り送信の送信先に関する情報を含む制御信号を生成する制御回路と、制御信号を送信する送信回路と、を具備する。

Description

アクセスポイント、端末、及び通信方法
 本開示は、アクセスポイント、端末、及び通信方法に関する。
 The Institute of Electrical and Electronics Engineers(IEEE)において、規格IEEE 802.11ax(以下、「11ax」とも呼ぶ)の後継規格として、IEEE 802.11be(以下、「11be」とも呼ぶ)の仕様策定が進められている。例えば、11axはHigh Efficiency(HE)とも呼ばれ、11beはExtremely High Throughput(EHT)とも呼ばれる。また、11beの後継規格についても要求仕様の議論が進められている(例えば、非特許文献3、4を参照)。例えば、11beの後継規格を「EHT-plus」又は「beyond 11be」とも呼ぶ。
IEEE 802.11-21/0268r8, PDT: Channel access for Triggered TXOP Sharing IEEE 802.11-20/1312r8, AP assisted SU PPDU Tx for 11be R1 IEEE 802.11-22/0046r1, Next 802.11 generation after 11be IEEE 802.11-22/0059r0, Beyond ‘be’ IEEE 802.11-22/0039r3, CR for 35.2.1.3 part -2 IEEE 802.11-21/0485r3, EHT TF Clarifications
 しかしながら、無線LANのような無線通信における送信機会の割当方法については十分に検討されていない。
 本開示の非限定的な実施例は、無線通信における送信機会の割当効率を向上できるアクセスポイント、端末及び通信方法の提供に資する。
 本開示の一実施例に係るアクセスポイントは、複数の端末の上り送信を指示する制御信号であって、前記複数の端末のそれぞれに対する前記上り送信の送信先に関する情報を含む前記制御信号を生成する制御回路と、前記制御信号を送信する送信回路と、を具備する。
 なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
 本開示の一実施例によれば、例えば、無線通信における送信機会の割当効率を向上できる。
 本開示の一実施例における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および/または効果は、いくつかの実施形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、1つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。
Trigger frameの一例を示す図 Common Info fieldの一例を示す図 User Info fieldの一例を示す図 Special User Info fieldの一例を示す図 TXOP Sharing modeの一例を示す図 TXOP Sharing mode 2の動作例を示すシーケンス図 周波数多重(FDM:Frequency Division Multiplexing)による複数端末(STA:Station)に対するTXOP Sharingの動作例を示すシーケンス図 アクセスポイント(AP:Access Point)の一部の構成例を示すブロック図 端末の一部の構成例を示すブロック図 APの構成例を示すブロック図 TXOP Sharing modeの一例を示す図 User Info fieldの一例を示す図 割当帯域の通知方法の一例を示す図 割当帯域の通知方法の一例を示す図 送信先情報の一例を示す図 端末の構成例を示すブロック図 TXOP Sharingの動作例を示すシーケンス図 送信先情報の一例を示す図 TXOP Sharingの動作例を示すシーケンス図 User Info fieldの一例を示す図 TXOP Sharingの動作例を示すシーケンス図 TXOP Sharingの動作例を示すシーケンス図 TXOP Sharingの動作例を示すシーケンス図 EHT Medium Access Control (MAC) Capabilities Information fieldの一例を示す図 User Info fieldの一例を示す図
 以下、本開示の各実施の形態について図面を参照して詳細に説明する。
 11beでは、11axと同様に、Enhanced Distributed Channel Access(EDCA)と呼ばれる優先制御方式を用いて、アクセスカテゴリ(AC:Access Category)に個別の送信機会の優先付けが行われてよい。EDCAでは、例えば、一度送信権を獲得したACは、最小待ち時間(SIFS:Short Inter Frame Space)間隔での無線信号の連続送信を可能とする。この連続送信が可能な時間は「Transmission Opportunity(TXOP)」と呼ばれてよい。TXOPの上限の時間は、例えば、ACに個別に規定されてよい。
 11beでは、例えば、アクセスポイント(AP:Access Point。又は、「AP-STA(Station)」、「基地局」とも呼ばれる)が獲得したTXOPの少なくとも一部の時間を端末(STA、又は、「non-AP STA」とも呼ばれる)に割り当てる「TXOP sharing」が検討される。例えば、APが1つのSTAに対してTXOP sharingをトリガする手順(例えば、「Triggered TXOP sharing procedure」)が検討される(例えば、非特許文献1、2を参照)。
 11axでは、例えば、APは、上り信号の送信を指示する制御信号(以下、「トリガーフレーム(TF:Trigger frame)」と呼ぶ)を用いてSTAの上り信号の無線リソースをスケジューリングする仕組み(例えば、「Triggered UL operation」と呼ぶ)が導入された。Triggered UL operationにより、STAの上り信号に対する直交多重の効率を向上でき、スループット性能を向上できる。
 例えば、Triggered UL operationでは、APは、各STAの送信バッファ状態(例えば、BSR:Buffer Status Report)又は通信品質といったSTAの状況を動的に把握し、STAの状況に基づいて各STAの上り信号(例えば、Trigger frameに対する上り応答信号)に適用する複数の無線パラメータを計算する。無線パラメータには、例えば、上り信号に対する、信号長、Modulation and Coding Scheme(MCS)、空間ストリーム数、及び、送信電力が挙げられる。このように、Triggered UL operationでは、APのスケジューリングにおける処理(例えば、計算)は複雑化する可能性がある。
 なお、上り応答信号は、例えば、trigger-based physical layer protocol data unit(TB PPDU)と呼ばれることもある。
 その一方で、TXOP sharingでは、例えば、APが獲得したTXOPの一部を或るSTAに割り当てた場合、TXOPの一部を割り当てられたSTAと異なるSTAには、送信禁止期間(NAV:Network Allocation Vector)が設定されてよい。NAVの設定により、TXOPの一部が割り当てられたSTAの送信信号の衝突を抑制できる。また、TXOP sharingが適用されるSTAは、当該STAの送信バッファ状態又は通信品質に基づいて、当該STAの送信信号に適用される無線パラメータを決定することにより、信号の送信効率を向上できる。例えば、TXOP sharingでは、APは、STAが送信する上り信号に対するスケジューリングの少なくとも一部を行わなくてよいので、Triggered UL operationと比較して、APの処理を簡易化できる。
 このように、11beでは、例えば、Triggered UL operationに加え、TXOP sharingのサポートにより、STAの上り信号の衝突を抑制し、また、APにおける簡易な処理によるスループット性能を改善できる。
 beyond 11beでは、例えば、端末間通信であるpeer to peer(P2P)又はDirect Link(DiL)の性能向上の必要性が提案されている(例えば、非特許文献3~4を参照)。例えば、APがP2P通信を行う複数の端末に対してTXOP sharingを指示する方法(例えば、Trigger frame format又は手順等)については十分に検討されていない。
 11beでは、例えば、APは、Trigger frameの種別(例えば、「Trigger Type」と呼ぶ)として、Multi-User Request-To-Send(MU-RTS)を設定したTrigger frame(以下、「MU-RTS Trigger frame」と呼ぶ)を用いて、1つの端末(STA)に対して、TXOP sharing(以下、「TXS」とも呼ぶ)を指示することが検討されている(例えば、非特許文献1を参照)。なお、TXOP sharingを適用するMU-RTS Trigger frameを、「MU-RTS TXS Trigger frame(MU-RTS TXS TF)」と呼ぶこともある。
 図1は、Trigger frameの一例を示す図である。図1に示すように、Trigger frameは、周波数多重(FDM:Frequency Division Multiplexing)される複数の端末に対して、複数の端末に共通の情報を含めるフィールド(例えば、「共通情報フィールド(Common Info field)」)、及び、User Info Listと称されるフィールドを含む。User Info Listには、例えば、端末に個別(あるいは固有)の情報を含めるフィールド(例えば、「ユーザ情報フィールド(User Info field)」)が1つ以上含まれてよい。
 また、11beでは、例えば、Trigger frameに、11be(EHT)に対応する端末向けの情報を含めるフィールド(例えば、「Special User Info field」)が含まれてよい(図示せず)。
 図2は、11be(例えば、EHT)において検討されるCommon Info fieldの構成例を示す図である(例えば、非特許文献5を参照)。また、図3は、11be(EHT)において検討されるMU-RTS TXS TFにおけるUser Info fieldの構成例を示す図である(例えば、非特許文献5を参照)。また、図4は、Special User Info fieldの構成例を示す図である(例えば、非特許文献6を参照)。
 例えば、図2に示すCommon Info field内のTrigger Type subfieldは、Trigger frameの種別(例えば、APが端末に送信させる信号種別)を指示するsubfieldである。例えば、APは、Trigger Typeを、MU-RTSを指示する値(例えば、11beの場合、Trigger Type subfield value = 3)に設定することにより、MU-RTS TXS Trigger frameを所定の端末に指示可能となる。端末は、例えば、MU-RTS TXS Trigger frameを受信し、受信したMU-RTS TXS Trigger frameに含まれるUser Info fieldにおいて当該端末のAssociation ID(AID)を指定された場合、APへClear To Send(CTS)フレームを送信してよい。
 11beでは、MU-RTS TXS Trigger frameの場合、例えば、図2に示すCommon Info field内のB20-B21の領域は、TXOP sharingの設定に関する「TXOP Sharing Mode」 subfieldと認識される。
 なお、MU-RTS TXS Trigger frameと異なる種別のTrigger frameの場合、Common Info field内のB20-21の領域は、「GI And HE/EHT-LTF Type」 subfieldと認識されてよい。GI And HE/EHT-LTF Type subfieldは、例えば、HE-Long Training Field(LTF)、EHT-LTFに関連するパラメータ情報を含んでよい。例えば、GI And HE/EHT-LTF Type subfieldに含まれる情報は、HE/EHT-LTFを含まないCTSフレームの送信には使用されない情報である。
 図5は、11beにおいて検討されるTXOP Sharing Modeの一例を示す図である(例えば、非特許文献1を参照)。
 図5において、TXOP Sharing Modeが0の場合(TXOP Sharing Mode subfield value=0)、TXOP sharing(例えば、MU-RTS TXOP Sharing)は実施されず、端末は、例えば、MTSフレームに対応する応答として、CTSフレームをAPへ送信する。
 また、図5において、TXOP Sharing Modeが1又は2の場合(TXOP Sharing Mode subfield value=1 or 2)、TXOP sharing(例えば、MU-RTS TXOP Sharing)は実施されてよい。
 例えば、TXOP Sharing Modeが1の場合(TXOP Sharing Mode 1とも呼ぶ)、TXOPの一部に相当する割当期間において、スケジューリングされる端末は、接続するAP(例えば、associated AP)に無線フレームを送信可能となる。例えば、TXOP Sharing Modeが1の場合、端末は、接続するAPと異なるAP又はSTAへの無線フレームを送信しない。
 また、例えば、TXOP Sharing Modeが2の場合(TXOP Sharing Mode 2とも呼ぶ)、図6に示すように、TXOPの一部に相当する割当期間(Time allocated in MU-RTS TX TF)において、スケジューリングされる端末(例えば、Non-AP STA 1又はSTA 1。例えば、「端末1」とも呼ぶ)は、接続するAP、あるいは、別の端末(例えば、Non-AP STA 2又はSTA 2。例えば、「端末2」とも呼ぶ)へ無線フレームを送信可能となる。
 上述したTXOP Sharing Modeが1以上の場合(又は、非ゼロの場合)、すなわち、TXOP sharingを適用するMU-RTS Trigger frameを、「MU-RTS TXS Trigger frame(MU-RTS TXS TF)」と呼ぶこともある。
 ここで、図6に示すように、APは、スケジューリングした端末(例えば、端末1)から、MU-RTS TXS Trigger frameに応答してCTSフレーム(例えば、CTS response)を受信した場合、当該端末に対してTXOP sharingが適切に指示されたと判断してよい。この場合、APは、割当期間においてスケジューリングした端末から要求されるACK応答(例えば、Block Ack)と異なる信号の送信を行わなくてよい。なお、例えば、図6に示すように、割当期間内に、Point Coordination Function(PCF) Interframe Space(PIFS)間においてキャリアセンスがIDLEの場合、APは、TXOPを端末から取り戻し、APが残りのTXOP期間において別の端末宛に信号を送信してもよい。
 例えば、11beでは、MU-RTS TXS Trigger frameを用いて指示可能な端末数は1つであり、MU-RTS TXS Trigger frameにおいて、図3に示すUser Info fieldが1つ設定される(例えば、非特許文献1を参照)。また、TXOP Sharingにおける端末に対する割当期間では、端末は、送信信号のMCSといったパラメータを決定し、規定された帯域(例えば、20MHz×N(Nは整数)帯域)のSingle User(SU) PPDUを送信してよい。また、端末に対する割当期間の指示には、例えば、図3に示すように、User Info fieldのAllocation Duration subfieldの使用が検討される。
 ここで、例えば、APが、端末間通信(例えば、P2P-link)が設定される複数の端末に対してTXOP sharingを指示する方法(例えば、Trigger frame format又は手順)については十分に検討されていない。
 本開示の非限定的な実施例では、P2P-linkが設定される複数の端末(例えば、「P2P端末」とも呼ぶ)に対してAPがTXOP sharingを指示する方法の例について説明する。
 (実施の形態1)
 本実施の形態では、FDMによって複数端末へのTXOP sharingを行う場合について説明する。
 図7は、APが、TXOP Sharing Mode 2の場合(例えば、スケジューリングされた端末が接続APあるいは別の端末と通信する場合)に、端末1(STA 1)及び端末3(STA 3)に対して、FDMによるTXOP sharingを行うシーケンスの一例を示す図である。
 図7では、一例として、端末1(STA 1)と端末2(STA 2)との間にP2Pリンクが設定され、端末3(STA 3)と端末4(STA 4)との間にP2Pリンクが設定される。なお、P2P通信を行う端末ペアは、802.11では、Tunneled Direct Link Setup(TDLS)と呼ばれる手順で設定されてよい。
 図7において、APは、例えば、MU-RTS TXS Trigger frameを用いて、端末1及び端末3のそれぞれに、直交する周波数リソース(例えば、20MHz channel×N(20MHz単位のchannel))を割り当ててよい。
 ここで、端末1及び端末3は、各々において上り信号(例えば、SU PPDU)の時間長及び送信先(例えば、接続先APあるいは別のP2P端末)を決定してよい。このため、図7に示すように、端末1と端末3との間においてSU PPDUの時間長が異なり得るので、APにおける送信タイミングと受信タイミングとが重なる可能性がある。例えば、全二重通信に未対応のAPは、送信タイミングと受信タイミングとが重なると、送信信号及び受信信号の何れか一方の信号に対する処理を行わない場合が生じ得る。また、APが全二重通信に対応する場合でも、例えば、自己干渉(受信信号に送信信号の隣接チャネル干渉が含まれる場合)が発生して、受信性能が劣化し得る。
 例えば、図7に示すように、APから端末1へ送信するACK(例えば、Block Ack)フレームと、端末3からAPへ送信するSU PPDUフレーム(例えば、DATA to AP in non-TB PPDU)とが重なる可能性がある。この場合、例えば、APは、端末3からのSU PPDUフレームを受信できず、STA 3がSU PPDUを再送することがあり得る。このように、APが割り当てた時間リソースを有効利用されない可能性がある。
 本実施の形態では、例えば、複数のP2P端末に対して、TXOP sharingされた時間リソースにおける送信先を制御する方法について説明する。
 [無線通信システムの構成]
 本実施の形態に係る無線通信システムは、例えば、図8に示すAP100、及び、図9に示す端末(STA)200を備えてよい。AP100及び端末200の少なくとも一方は、無線通信システムにおいて2つ以上存在してもよい。AP100は、例えば、端末200に対して、TXOP Sharingを指示するTrigger frame(例えば、MU-RTS TXS Trigger frame)を送信してよい。端末200は、MU-RTS TXS Trigger frameを受信し、受信したMU-RTS TXS Trigger frameによって指示されるリソース(例えば、割当時間(又は、割当期間)、及び、割当帯域(又は、割当channel))に基づいて、AP100あるいは別の端末へ信号を送信してよい。
 図8は、本開示の一実施例に係るAP100の一部の構成例を示すブロック図である。図8に示すAP100において、制御部(例えば、制御回路に対応)は、複数の端末の上り送信を指示する制御信号(例えば、Trigger frame)であって、複数の端末のそれぞれに対する上り送信の送信先に関する情報(例えば、送信先情報)を含む制御信号を生成する。送信部(例えば、送信回路に対応)は、制御信号を送信する。
 図9は、本開示の一実施例に係る端末200の一部の構成例を示すブロック図である。図9に示す端末200において、受信部(例えば、受信回路に対応)は、複数の端末の上り送信を指示する制御信号(例えば、Trigger frame)であって、複数の端末のそれぞれに対する上り送信の送信先に関する情報(例えば、送信先情報)を含む制御信号を受信する。制御部(例えば、制御回路に対応)は、制御信号に基づいて、上り送信を制御する。
 [AP100の構成例]
 AP100は、例えば、複数端末へのTXOP Sharingを指示するTrigger frame(例えば、MU-RTS TXS Trigger frame)を生成し、MU-RTS TXS Trigger frameを端末200へ送信する。
 図10は、AP100の構成例を示すブロック図である。図10に示すAP100は、例えば、スケジューリング部101と、Common Info生成部102と、User Info生成部103と、Trigger frame生成部104と、誤り訂正符号化部105と、変調部106と、無線送受信部107と、復調部108と、誤り訂正復号部109と、端末情報保持部110と、を備えてよい。
 例えば、スケジューリング部101と、Common Info生成部102と、User Info生成部103と、Trigger frame生成部104と、端末情報保持部110とは、アクセス制御部(例えば、Medium Access Control(MAC)処理部)に含まれてよい。
 また、図10に示すスケジューリング部101、Common Info生成部102、User Info生成部103、Trigger frame生成部104、誤り訂正符号化部105、変調部106、復調部108、誤り訂正復号部109、及び、端末情報保持部110の少なくとも一つは、例えば、図8に示す制御部に含まれてよい。また、図10に示す無線送受信部107は、例えば、図8に示す送信部に含まれてよい。
 スケジューリング部101は、例えば、端末200に対するスケジューリングを行ってよい。例えば、スケジューリング部101は、端末情報保持部110から入力される端末情報に基づいて、端末200に適用するTXOP Sharing mode、及び、割当無線リソース(例えば、TXOP sharingでの割当期間及び割当帯域の少なくとも一つを含む)を決定してよい。
 例えば、TXOP Sharing modeには、上述した1つの端末へのTXOP Sharing modeに加え、複数端末に対するTXOP Sharing modeが含まれてよい。複数端末へのTXOP Sharing modeを適用する場合、スケジューリング部101は、例えば、TXOP sharingを適用する複数の端末200に対して、上り送信の送信先に関する情報(以下、「送信先情報」と呼ぶ)を決定してよい。
 送信先情報には、例えば、AP100への上り送信を許可するか否かを示す情報が含まれてよい。例えば、送信先情報には、割当無線リソースを用いて信号の送受信を許可する送信先を示す情報が含まれてよい。一例として、送信先情報は、AP100及びTXOP sharingを適用する複数の端末200と異なる別の端末の何れかとの通信の許可、及び、別の端末との通信の許可(又は、AP100との通信の不許可)の何れかを示す情報でもよい。
 また、割当無線リソースには、例えば、AP100が獲得したTXOPの一部の期間(例えば、時間リソース)が含まれてよい。また、例えば、FDMによって複数端末へのTXOP sharingが適用される場合、割当無線リソースには、各端末200へ割り当てるchannel(例えば、20MHz単位の帯域)が含まれてよい。例えば、割当無線リソース(例えば、割当帯域)は、Trigger frameが割り当てられる帯域の少なくとも一部の帯域を含んでもよく、Trigger frameが割り当てられる帯域と異なる帯域を含んでもよい。
 また、端末情報には、例えば、端末200のCapability情報、送信バッファ状態、P2Pの設定に関する制御情報、Sub-Channel Selective Transmission(SST)Modeに関する情報が含まれてよい。
 Capability情報には、例えば、端末200がPrimary channelと異なるchannel(例えば、Secondary channel)における送受信が可能か否かを示す情報が含まれてよい。また、端末200が複数リンク送信に対応する場合、Capability情報には、例えば、同時に送受信が可能であるか否かを示す情報(例えば、Simultaneous transmit and receive (STR)に対応する端末であるか否か)が含まれてよい。
 送信バッファ状態には、例えば、端末200における、AP100宛ての送信バッファのAC及びサイズに関する情報が含まれてよい。また、送信バッファ状態には、例えば、P2Pリンク(又は、Direct Link)において端末200と接続する別の端末(例えば、「Direct Link Peer (DLP) STA」とも呼ばれる)宛ての送信バッファのAC及びサイズに関する情報が含まれてもよい。
 P2Pの設定情報には、例えば、端末200とP2P通信を行う端末情報(例えば、端末ID)が含まれてよい。また、P2Pの設定情報には、例えば、Off-channel(AP100のOperation帯域外でP2P通信を行う設定)を実施するか否かを示す情報が含まれてよい。
 SST Modeに関する情報には、例えば、端末200が、SST Modeが設定された端末であるか否かを示す情報が含まれてよい。また、端末200がSST Modeが設定された端末の場合、SST Modeに関する情報には、例えば、Target wake time(TWT)が適用された場合に用いるSub-Channel(Primary channelと異なるchannel)を示す情報が含まれてよい。
 スケジューリング部101は、例えば、決定した各端末200のTXOP sharing mode及び割当無線リソースに関する情報を、Common Info生成部102及びUser Info生成部103に出力する。
 Common Info生成部102は、例えば、複数の端末200に共通のCommon Info fieldに含まれる制御情報を生成してよい。Common Info生成部102は、例えば、スケジューリング部101から入力されるTXOP sharingに関する情報に基づいて、Trigger type subfield、及び、TXOP sharing mode subfieldの情報を生成してよい。
 また、Common Info生成部102は、例えば、スケジューリング部101から入力される割当無線リソースに関する情報に基づいて、端末200への割当期間に関する情報を生成してよい。
 TXOP sharing modeと、Trigger frame内のTXOP sharing modeを指示する情報(TXOP sharing mode subfieldの値)との関連付けは、例えば、テーブル形式の情報(例えば、「TXOP sharing modeテーブル」と呼ぶ)でもよく、テーブル形式と異なる形式の情報でもよい。図11は、TXOP sharing modeテーブルの一例を示す図である。TXOP sharing modeテーブルは、例えば、仕様書で定義されてもよい。図11に示すTXOP sharing modeテーブルには、例えば、図5に示す非特許文献1に記載されるTXOP sharing mode(例えば、TXOP sharing mode =0~2の何れか)、及び、複数の端末200に対するTXOP sharing mode(例えば、TXOP sharing mode =3)が含まれてよい。
 例えば、TXOP sharingを実施する場合、Common Info生成部102は、Trigger type subfieldをMU-RTSに設定し、TXOP sharing mode subfieldを所定値(例えば、図11のTXOP sharing modeテーブルの場合、1以上の何れかの値)に設定することで、MU-RTS TXS Trigger frameを生成してよい。
 Common Info生成部102は、生成したCommon Info fieldに関する情報を、Trigger frame生成部104へ出力してよい。
 なお、Trigger frame内のフィールド(例えば、subfield)の「設定」という用語は、例えば、「定義」、「解釈」などの他の用語に置き換えられてよい。
 User Info生成部103は、例えば、Special User Info field、又は、端末200に個別のUser Info fieldに含まれる制御情報を生成してよい。User Info生成部103は、例えば、規定されるフォーマットに基づいて、Special User Info field、又は、端末200に個別のUser Info fieldに関する情報を生成し、複数の端末200それぞれに対するUser Info fieldを含むUser Info Listに関する情報を生成してよい。User Info生成部103は、例えば、User Info Listに関する情報をTrigger frame生成部104へ出力してよい。
 また、User Info生成部103は、例えば、スケジューリング部101から入力される割当無線リソースに関する情報に基づいて、図12に示すように、端末200のID(AID12 subfieldの情報)、端末200への割当帯域(例えば、20MHz channel単位の帯域)に関する情報(例えば、RU Allocation subfieldの情報)、端末200への割当期間に関する情報(Allocation Duration subfieldの情報)、端末200に割り当てた無線リソースを用いた送受信を許可する送信先に関する送信先情報(例えば、Destination Mode subfieldの情報)を生成してよい。User Info生成部103は、例えば、生成したUser Info Listを、Trigger frame生成部104へ出力してよい。
 端末200への割当帯域情報(例えば、図12のRU allocation subfieldで通知される情報)は、例えば、端末200に割り当てられる20MHz×Nの周波数リソース位置を示してよい。例えば、20MHz×Nの周波数リソース位置の通知方法として、11axにおいて使用されるMU-RTSによるCTSフレームの周波数リソースの通知方法が適用されてもよい。
 図13は、MU-RTS Trigger frameによる周波数リソースの通知方法の例を示す図である。11axにおいてサポートされるMU-RTSでは、例えば、MU-RTS Trigger frameのCommon Info fieldに含まれる「UL BW subfield」と、MU-RTS Trigger frameのUser Info fieldに含まれる「RU Allocation subfield」との組み合わせによって、CTS用の周波数リソースが端末200に個別に通知されてよい。例えば、図13に示すように、UL BW subfieldによって、上りリンクのOperation帯域幅(例えば、20MHz、40MHz、80MHz又は160MHz)が指定され、RU allocation subfieldによって、割当期間における通信に割り当てられる周波数リソースの位置が指定される。本実施の形態では、例えば、図13に示す方法と同様の方法によって、TXOP sharingの割当期間において端末200が用いるchannelが指示されてもよい。なお、図13に示す方法と異なる方法によって、TXOP sharingの割当期間において端末200が用いるchannelが指示されてもよい。
 また、11beにおいて新たにサポートされる320MHzを含むOperation帯域において、割当期間における通信用の周波数リソース位置が通知される場合、例えば、図4に示すSpecial User Info fieldに含まれる「UL Bandwidth Extension subfield」が使用されてよい。例えば、Common Info fieldのUL BW subfieldと、Special User Info fieldのUL Bandwidth Extension subfieldとの組み合わせによって、端末200に対してOperation帯域幅が通知されてよい。
 なお、図13に示す通知方法は、Primary 20MHz channelを含む周波数リソース位置を通知する方法であるが、本実施の形態は、それに限定されず、例えば、図14に示すように、Primary 20MHz channelを含まないOperation帯域内の任意の20MHz×N channelの周波数リソースを通知する方法を用いてもよい。
 また、端末200への割当期間に関する情報(例えば、図12のAllocation Duration subfieldで通知される情報)には、例えば、AP100が取得したTXOP内において端末200へ共有する割当期間を、所定の時間粒度(例えば、16us単位)で、MU-RTS TXS TFの終了タイミングからの所定時間長(例えば、最大8ms)の範囲で示した情報が含まれてよい。
 また、割当無線リソースにおいて送受信を許可する送信先に関する送信先情報(例えば、図12のDestination Mode subfieldで通知される情報)には、例えば、図15に示す情報が含まれてよい。図15に示すように、例えば、Destination Mode subfieldの値が0の場合、割当無線リソースを用いた送受信を許可する送信先としては、別の端末が設定され、AP100が設定されなくてよい(例えば、別の端末のみに設定されてよい)。図15に示すように、例えば、Destination Mode subfieldの値が1の場合、割当無線リソースを用いた送受信を許可する送信先としては、AP100あるいは別の端末が設定されてよい。
 なお、割当無線リソースを用いた送受信を許可する送信先情報は、例えば、複数端末へのTXOP sharing modeが適用される場合(例えば、図11において、TXOP Sharing Mode subfield valueが3の場合)に、端末200へ通知されてもよい。例えば、1つの端末へのTXOP Sharing modeが適用される場合、割当無線リソースで送受信を許可する送信先情報は端末200へ通知されなくてもよい。
 また、User Info Listに含まれるUser Info field数は、例えば、TXOP sharing mode subfieldにおいて指示されるTXOP sharing modeに関連付けられてよい。例えば、TXOP sharing modeが1つの端末へのTXOP sharingを適用するmodeの場合(例えば、図11に示すTXOP sharing modeテーブルにおいてTXOP sharing mode =1, 2が指示される場合)、User Info Listには、1つのUser Info fieldが含まれてよい。また、TXOP sharing modeが複数端末へのTXOP sharingを適用するmodeの場合(例えば、図11に示すTXOP sharing modeテーブルにおいて、TXOP sharing mode=3が指示される場合)、User Info Listには、複数のUser Info fieldが含まれてよい。
 なお、Special User Info fieldには、TXOP sharing modeに依存せず、1つの端末200に対する制御情報が含まれてよい。
 Trigger frame生成部104は、例えば、図1に示すフォーマットに基づいて、Common Info生成部102から入力されるCommon Info fieldの情報、User Info生成部103から入力されるUser Info List(例えば、Special User Info field及び少なくとも一つのUser Info field)の情報を含むTrigger frameを生成してよい。Trigger frameには、例えば、Common Info field及びUser Info Listに加え、MAC header、Padding、frame check sequence(FCS)の少なくとも一つが含まれてよい。Trigger frame生成部104は、例えば、生成したTrigger frameを、誤り訂正符号化部105へ出力してよい。
 誤り訂正符号化部105は、例えば、Trigger frame生成部104から入力されるTrigger frameを含む送信データ信号を誤り訂正符号化し、符号化した信号を変調部106へ出力する。
 変調部106は、例えば、誤り訂正符号化部105から入力される信号に対して変調処理を行い、変調後の信号を無線送受信部107へ出力する。
 なお、変調後のデータ信号が直交周波数分割多重(OFDM:Orthogonal Frequency Division Multiplexing)信号である場合、AP100(例えば、変調部106)は、変調信号を規定の周波数リソースにマッピングし、逆高速フーリエ変換(IFFT:Inverse Fast Fourier Transform)処理を行って時間波形に変換し、サイクリックプリフィックス(CP:Cyclic Prefix)を付加することにより、OFDM信号を形成してよい。
 無線送受信部107は、例えば、変調部106から入力される変調信号に対して、D/A変換、及び、キャリア周波数へのアップコンバートといった無線送信処理を行い、無線送信処理後の信号を、アンテナを介して端末200へ送信する。また、無線送受信部107は、例えば、端末200から送信された信号を、アンテナを介して受信し、受信した信号に対して、ベースバンドへのダウンコンバート、及び、A/D変換といった無線受信処理を行い、無線受信処理後の信号を復調部108へ出力する。
 復調部108は、例えば、無線送受信部107から入力される信号に対して復調処理を行い、復調後の信号を誤り訂正復号部109へ出力する。なお、復調部108に入力される信号がOFDM信号の場合には、AP100(例えば、復調部108)は、CP除去処理、及び、高速フーリエ変換(FFT:Fast Fourier Transform)処理を行ってよい。
 誤り訂正復号部109は、例えば、復調部108から入力される信号を復号して、端末200からの受信データ信号を得る。誤り訂正復号部109は、例えば、復号後の受信データに上述した端末情報が含まれる場合、端末情報を含む復号データを端末情報保持部110へ出力する。
 端末情報保持部110は、例えば、誤り訂正復号部109から入力される復号データから、端末情報(例えば、端末200のCapability情報、送信バッファ状態、P2Pの設定情報、又は、SST Modeに関する情報が含まれてよい)を取得(又は、保持)し、取得した端末情報をスケジューリング部101へ出力してよい。
 [端末200の構成例]
 端末200は、例えば、AP100から、TXOP Sharingを指示するTrigger frame(例えば、MU-RTS TXS Trigger frame)を受信し、Trigger frameに対する上り応答信号(例えば、CTSフレーム)をAP100へ送信する。そして、端末200は、例えば、MU-RTS TXS Trigger frameの指示に基づいて、割当期間内において、割当channelを用いて、許可された送信先(例えば、AP100あるいは別の端末)と通信を行う。
 図16は、端末200の構成例を示すブロック図である。図16に示す端末200は、例えば、無線送受信部201と、復調部202と、誤り訂正復号部203と、Common Info取得部204と、User Info取得部205と、スケジューリング部206と、データ生成部207と、誤り訂正符号化部208と、変調部209と、を備えてよい。
 例えば、Common Info取得部204と、User Info取得部205と、スケジューリング部206と、データ生成部207との少なくとも一つは、アクセス制御部(例えば、MAC処理部)に含まれてよい。
 また、図16に示す復調部202、誤り訂正復号部203、Common Info取得部204、User Info取得部205、スケジューリング部206、データ生成部207、誤り訂正符号化部208、及び、変調部209の少なくとも一つは、例えば、図9に示す制御部に含まれてよい。また、図16に示す無線送受信部201は、例えば、図9に示す受信部に含まれてよい。
 無線送受信部201は、例えば、受信信号をアンテナによって受信し、受信信号に対して、ダウンコンバート及びA/D変換といった無線受信処理を行い、無線受信処理後の信号を復調部202へ出力する。また、無線送受信部201は、例えば、変調部209から入力される信号に対して、アップコンバート及びD/A変換といった無線送信処理を行い、無線送信処理後の信号をアンテナから送信する。
 復調部202は、例えば、無線送受信部201から入力される受信データに対して復調処理を行い、復調した信号を誤り訂正復号部203へ出力する。なお、復調部202へ入力される信号がOFDM信号の場合、端末200(例えば、復調部202)は、例えば、CP除去処理及びFFT処理を行ってよい。
 誤り訂正復号部203は、例えば、復調部202から入力される復調信号を復号し、復号された信号を受信データ信号として出力してよい。また、誤り訂正復号部203は、例えば、受信データ信号のうち、Trigger frameをCommon Info取得部204及びUser Info取得部205へ出力する。
 Common Info取得部204は、例えば、誤り訂正復号部203から入力されるTrigger frameから、Common Info fieldに対応する情報を抽出し、TXOP sharingに関する端末共通情報を取得してよい。
 TXOP sharingに関する端末共通情報には、例えば、TXOP sharing modeに関する情報、及び、端末200への割当channelに関する情報が含まれてよい。また、端末共通情報には、端末200への割当期間に関する情報が含まれてよい。また、端末共通情報には、例えば、FDMベースの複数端末へのTXOP sharing modeであることを示す情報が含まれてもよい。
 Common Info取得部204は、抽出した端末共通情報をUser Info取得部205へ出力してよい。
 User Info取得部205は、例えば、誤り訂正復号部203から入力されるTrigger frameから、User Info List(例えば、少なくとも一つのUser Info field及びSpecial User Info field)に対応する情報を抽出し、Common Info取得部204から入力される端末共通情報(例えば、TXOP sharing modeを含む)に基づいて、User Info fieldの受信処理を行ってよい。User Info取得部205は、例えば、TXOP sharing modeが複数端末へのTXOP sharingを指示する場合、複数のUser Info fieldの受信処理を行ってよい。また、User Info取得部205は、例えば、TXOP sharing modeが1つの端末へのTXOP sharingを指示する場合、1つのUser Info fieldの受信処理を行ってよい。
 例えば、User Info取得部205は、User Info fieldに含まれる端末200を識別する情報(例えば、端末ID又はAID)を復号し、端末200宛ての割当指示があると判断した場合、TXOP sharingに関する端末個別情報(例えば、割当期間及び割当channelといった割当無線リソース、割当無線リソースを用いた送受信を許可する送信先に関する送信先情報)、及び、端末共通情報(例えば、TXOP Sharing Mode、UL BWの情報を含む)の少なくとも一つを、User Info fieldから取得してよい。
 User Info取得部205は、例えば、端末個別情報、及び、端末共通情報を、スケジューリング部206、及び、データ生成部207へ出力してよい。
 スケジューリング部206は、例えば、User Info取得部205から入力される情報(例えば、端末個別情報、及び、端末共通情報を含む)に基づいて、割当無線リソース、及び、上り送信の送信先を決定してよい。スケジューリング部206は、例えば、割当無線リソースに基づいて、AP100から指示されるTXOP sharingされた割当無線リソースにおけるデータ送信を制御してよい。データ送信の制御には、例えば、割当期間、割当channel、及び、割当期間内の送信先に関する制御が含まれてよい。
 スケジューリング部206は、例えば、データ生成に関する制御情報(例えば、データ信号に適用する無線パラメータ(信号長、変調方式、誤り訂正符号化率、空間多重数、送信電力等)を含む)をデータ生成部207へ出力してよい。
 ここで、データ信号に適用する無線パラメータの一部(例えば、信号長、変調方式、誤り訂正符号化率、空間多重数、送信電力の少なくとも1つ)について、端末200が、端末200の送信バッファ状態又は通信品質といったパラメータに基づいて決定してよい。換言すると、データ信号に適用する無線パラメータの一部は、AP100から指示されなくてよい。
 なお、データの信号長は、例えば、AP100から指示される割当期間以内の長さでよい。また、データ信号に割り当てられる送信channelは、AP100から指示される割当channelに基づいて決定されてよい。
 また、割当期間内の送信先は、User Info取得部205において取得した情報に従って決定されてよい。例えば、図15に示す定義において、User Info fieldのDestination Mode subfield valueが0の場合は、スケジューリング部206は、割当期間における信号の送信先を、P2Pを設定した別の端末に設定(例えば、限定)する。例えば、Destination Mode subfield valueが0の場合、割当期間における信号の送信先に、AP100は設定されなくてよい。
 また、例えば、図15に示す定義において、Destination Mode subfield valueが1の場合は、スケジューリング部206は、割当期間における信号の送信先を、P2Pを設定した別の端末、あるいは、AP100に設定する。例えば、スケジューリング部206は、送信パケットの優先度に応じて送信先を選択してもよい。
 データ生成部207は、例えば、スケジューリング部206から入力される制御情報、User Info取得部205から入力される情報に基づいて、データ信号(例えば、CTSフレーム、AP100宛てのデータ、又は、別の端末宛てのデータ)を生成し、データ信号を誤り訂正符号化部208へ出力する。
 例えば、データ生成部207は、MU-RTS TXS Trigger frameを受信した後(例えば、直後)には、CTSフレームを生成してよい。また、データ生成部207は、例えば、CTSフレームの送信後(例えば、CTSフレームを送信してからSIFS後)に、許可された送信先に対するデータ信号(例えば、SU-PPDU)を生成してよい。
 誤り訂正符号化部208は、データ生成部207から入力されるデータ信号を誤り訂正符号化し、符号化した信号を変調部209へ出力する。なお、データ信号に対する符号化率は、例えば、端末200によって決定されてよい。
 変調部209は、誤り訂正符号化部208から入力される信号を変調し、変調信号を無線送受信部201へ出力する。なお、変調部209において適用される変調方式は、例えば、端末200によって決定されてよい。また、変調信号がOFDM信号の場合には、端末200(例えば、変調部209)は、周波数リソースに変調信号をマッピング後にIFFT処理を行い、CPを付加することにより、OFDM信号を形成してよい。
 [AP100及び端末200の動作例]
 次に、本実施の形態に係るAP100及び端末200の動作例について説明する。
 以下では、AP100(例えば、Common Info生成部102、User Info生成部103及びTrigger frame生成部104)によって生成される1つのTrigger frame(例えば、MU-RTS TXS Trigger frame)を用いて、AP100と異なる複数の端末200(例えば、Non-AP 端末)に対するTXOP sharing(例えば、AP100が獲得した送信機会(TXOP)の一部の割当)を指示する方法について説明する。
 なお、AP100と異なる複数の端末200には、例えば、P2P通信(例えば、端末間通信)を行う端末200のペアが含まれてよい。
 <端末共通情報の通知例>
 端末共通情報には、例えば、TXOP sharing modeに関する情報が含まれてよい。
 AP100は、例えば、図11に示すTXOP sharing modeテーブルに基づいて、TXOP sharing mode subfieldの情報(例えば、TXOP sharing mode subfield value)を生成してよい。図11に示すTXOP sharing modeテーブルには、例えば、複数端末へのTXOP sharingを指示する情報(例えば、TXOP Sharing Mode subfield value=3)が含まれてよい。
 例えば、AP100と異なる複数端末200へのTXOP sharingを指示する場合、AP100は、図11に示すTXOP sharing modeテーブルにおけるTXOP sharing mode subfield value = 3を示す情報を含むTrigger frameを生成してよい。例えば、AP100は、Trigger frameにおける端末200に共通のCommon Info fieldに、複数端末へのTXOP sharingに関する情報(例えば、複数端末に送信機会の共有を指示する情報)を設定してよい。
 また、複数端末へのTXOP sharingに関する情報を設定する場合、AP100は、例えば、Trigger frameにおいてTXOP sharingが適用される複数の端末200に個別の複数のUser Info fieldを設定してよい。
 <端末個別情報の通知例>
 端末個別情報には、例えば、端末200への割当帯域情報(例えば、20MHz×N帯域)、端末200への割当期間に関する情報、及び、端末200への割当無線リソースを用いた送受信を許可する送信先情報が含まれてよい。
 割当帯域には、例えば、AP100が送信するMU-RTS TXS Trigger frameの送信帯域に含まれる帯域が設定されてよい。例えば、割当帯域は、MU-RTS TXS Trigger frameが割り当てられる帯域の少なくとも一部の帯域でよい。
 割当期間には、例えば、AP100が取得したTXOP期間の一部の期間が設定されてよい。また、割当期間として、複数の端末200に異なる期間が指示されてもよい。
 なお、割当期間に関する情報は、端末個別情報に含める場合に限らず、他の領域に含まれてもよい。例えば、割当期間に関する情報は、端末共通情報として、Common Info fieldの一部のsubfield(例えば、UL Length subfield、Reserved subfield)に含まれてもよい。
 送信先情報には、例えば、図15に示すように、割当無線リソースを用いた送受信を許可する送信先として、別の端末(例えば、端末200とP2P設定済の端末)が設定(例えば、限定)されるか、AP100及び別の端末が設定されてよい。送信先情報に、AP100及び別の端末が設定される場合、端末200は、AP100及び別の端末の何れかを送信先として選択してよい。
 例えば、AP100は、図12に示すように、User Info fieldにおいて、図3の既存のUser Info fieldではReserved領域であるB29の領域に、送信先情報を指示するsubfield(例えば、Destination Mode subfield)を設定してよい。
 なお、送信先情報を指示するsubfieldの名称はDestination Modeに限らず、他の名称でもよい。また、送信先情報を指示するsubfieldは、B29の領域に限定されず、他の領域に設定されてもよい。また、送信先情報において通知可能な送信先の種別(例えば、送信先の候補)は、図15に示すような2種類に限定されず、3種類以上でもよい。
 また、例えば、複数端末へのTXOP sharing modeが適用される場合(例えば、図11において、TXOP sharing mode = 3の場合)には、図12に示すUser Info fieldのB29の領域は、Destination Mode subfieldに設定され、複数端末へのTXOP sharingが適用されない場合には、図12に示すUser Info fieldのB29の領域は別のSubfield(例えば、Reserved領域)に設定されてもよい。
 例えば、図15に示す定義において、Destination Mode subfield = 0の場合、図12に示すAID12 subfieldによって指示される端末200の割当無線リソースを用いた送受信を許可する送信先には、別の端末(例えば、P2P端末)が設定され、AP100が設定されなくてよい。例えば、Destination Mode subfield value = 0の場合、送信先は別の端末(例えば、P2P端末)に限定され、AP100への上り送信が許可されない。
 また、例えば、図15に示す定義において、Destination Mode subfield value = 1の場合、図12に示すAID12 subfieldによって指示される端末200の割当無線リソースを用いた送受信を許可する送信先には、AP100及び別の端末(例えば、P2P端末)の何れかが設定されてよい。例えば、Destination Mode subfield value = 1の場合、AP100への上り送信が許可されてよい。
 なお、Destination Mode subfield valueと、割当無線リソースを用いた送受信を許可する送信先(例えば、P2P端末、及び、AP100とP2P端末)との関連付けは、図15に示す例に限定されない。例えば、送信先の設定として、AP100との送受信が許可され、P2P端末との送受信が許可されない設定でもよい。
 また、Destination Mode subfield value = 1の場合、端末200から送信される信号の送信先、及び、送信信号の時間長は、例えば、端末200によって決定されてよい。
 例えば、1つのMU-RTS TXS Trigger frameによってTXOP sharingを指示される複数の端末200(例えば、端末1及び端末2を含む)のうち、端末1の送信帯域がPrimary 20MHzに設定される場合、端末2の送信帯域は、primary channelを含まない周波数リソースに設定されてもよい。この場合、端末2は、例えば、MU-RTS TXS Trigger frameに応答して、primary channelを含まない周波数リソース(例えば、端末2に対して指示された帯域)を用いてCTSフレーム及びデータを送信してよい。
 また、MU-RTS TXS Trigger frameを受信した端末200は、例えば、MU-RTS TXS Trigger frameによって通知されるCTS用の周波数リソースにおけるキャリアセンス結果に基づいてCTSフレームを送信してよい。例えば、端末200は、MU-RTS TXS Trigger frameによって通知されるCTS用の周波数リソースがprimary channelを含まない場合、primary channelがビジーであっても、通知された周波数リソースにおいてCTSフレームを送信してよい。
 基地局100は、例えば、MU-RTS TXS Trigger frameによって指示した各端末200に対する割当帯域(例えば、端末200の送信帯域又はCTS用の周波数リソース)において、MU-RTS TXS Trigger frameに対する応答信号(CTSフレーム)を受信してよい。
 なお、割当channelを通知する方法は、上述したような端末200に割り当てられる20MHz×Nの周波数リソース位置を示す場合に限定されず、他の周波数リソースを通知する方法でもよい。
 図17は、複数端末へのTXOP sharingを指示し、各端末200へ割当無線リソースを用いた送受信を許可する送信先を指示する場合のシーケンスの一例を示す図である。
 図17では、例えば、AP100(「AP」と表す)は、端末共通情報として、AP100と異なる複数の端末200(図17のNon-AP STA 1(以下、端末1)及びNon-AP STA 3(以下、端末3))に対して、TXOP sharing modeに関する情報を指示してよい。
 例えば、複数端末へのTXOP sharingが適用される複数の端末200は、P2P設定済(例えば、TDLS設定済又はDirect link設定済)の端末でよい。図17に示す例では、端末1とNon-AP STA 2(以下、端末2)との間においてP2P linkが予め設定(例えば、TDLSが設定)され、端末3とNon-AP STA 4(以下、端末4)との間においてP2P linkが予め設定(TDLSを設定)される。例えば、図17では、AP100は、図11に示すTXOP sharing mode subfield value=3を通知することにより、端末1及び端末3に対して、複数端末へのTXOP sharingを指示してよい。
 また、図17では、例えば、AP100は、複数の端末200(例えば、端末1及び端末3)のそれぞれに対する端末個別情報として、割当無線リソースを用いた送受信を許可する送信先情報(例えば、別端末及びAP100の何れかとの通信の許可、あるいは、別端末との通信の許可)、割当channelに関する情報(例えば、RU allocation)、及び、割当期間に関する情報(例えば、図17に示すTime allocated in MU-RTS TXS TF)を通知してよい。なお、図17の例では、端末1及び端末3に対する割当期間として同じ期間が指示されている。
 例えば、図17において、AP100は、MU-RTS TXS Trigger frameを用いて、端末1に対してDestination Mode subfield value = 1を通知することにより、割当無線リソースを用いた送受信を許可する送信先として、端末2あるいはAP100を指示してよい。また、例えば、図17において、AP100は、MU-RTS TXS Trigger frameを用いて、端末3に対してDestination Mode subfield value = 0を通知することにより、割当無線リソースを用いた送受信を許可する送信先として、端末4を指示してよい。換言すると、図17において、AP100は、端末1に対してAP100への上り送信を許可し、端末3に対してAP100への上り送信を許可しない。
 また、図17では、AP100は、例えば、端末1と端末3とで直交する周波数リソース(20MHz×N channel)の通信を指示してよい。図17に示す例では、端末1に対して20MHz channel#1が指示され、端末3に対して20MHz channel#2が指示される。
 図17において、例えば、端末1及び端末3は、受信したMU-RTS TXS Trigger frameに基づいて、TXOP sharingの割当期間における、端末1及び端末3のそれぞれの割当channelにおいて、AP100宛てのCTSフレーム(CTS response)、及び、各送信先に対するデータ信号(DATA)を送信してよい。
 例えば、図17において、端末1は、指示された20MHz channel#1において、CTSフレームをAP100へ送信し、その後、送信先の一つとして許可されたAP100へのデータ信号(例えば、SU PPDU)を送信してよい。また、例えば、図17において、端末3は、指示された20MHz channel#2において、CTSフレームをAP100へ送信し、その後、送信先として許可された端末4へのデータ信号を送信してよい。
 このように、AP100は、例えば、各端末200に対して、MU-RTS TXS Trigger frameで指示した割当帯域(例えば、Primary channelを含まない帯域を含む)においてCTSフレームを送信(例えば、返信)させてよい。これにより、AP100は、例えば、MU-RTS TXS Trigger frameで指示した割当帯域においてCTSフレームを受信することにより、スケジューリングした端末200による割当期間での通信開始(例えば、AP100からの指示が正常に伝わったこと)を把握できる。
 また、例えば、図17に示す例では、TXOP Sharingの割当期間において、TXOP Sharingが適用される端末1及び端末3のうち、端末1にはAP100との通信が許可され、端末3にはAP100との通知が許可されない。
 この設定により、AP100は、TXOP sharingの割当期間において、TXOP sharingが適用される端末1及び端末3のうちの1つの端末200(例えば、端末1)と通信(例えば、データ信号の受信、及び、ACKの送信)を行う。例えば、図17に示す例では、AP100は、TXOP sharingの割当期間において、端末1と通信を行い、端末1と異なる他の端末2~端末4と通信を行わない。これにより、AP100では、例えば、図17に示すように、端末1に対する信号(例えば、Block Ack)の送信タイミングが、他の端末(例えば、端末2~端末4の何れか)からの信号の受信タイミングと重なることを抑制できる。また、AP100では、例えば、端末1からの信号の受信タイミングが、他の端末(例えば、端末2~端末4の何れか)に対する信号の送信タイミングと重なることを抑制できる。
 このように、本実施の形態では、AP100は、複数端末の上り送信を指示するTrigger frameであって、複数の端末200のそれぞれに対する上り送信の送信先に関する送信先情報を含むTrigger frameを生成し、送信する。例えば、AP100は、TXOP sharingの割当期間内において、TXOP sharingが適用される複数の端末200のうち1つの端末200と通信を行うように、複数の端末200に対する送信先情報(例えば、AP100への上り送信の許可の有無)を指示する。
 これにより、1つのTrigger frameによって、複数の端末200に対してTXOP sharingを指示できるので、TXOP sharingにおける割当効率を向上できる。
 また、本実施の形態では、例えば、複数の端末200(例えば、P2P端末)に対して、TXOP sharingされた時間リソースにおける送信先を適切に制御できるので、AP100における複数の端末200に対する送信タイミングと受信タイミングとが重なることを抑制できる。よって、例えば、AP100から或る端末200へ送信するACKフレームと、他の端末200からAP100へ送信されるSU PPDUフレームとが重なることを抑制できる。このため、AP100が他の端末200からのSU PPDUフレームを受信できないことによる他の端末200のSU PPDUの再送を抑制でき、AP100が割り当てる時間リソースの利用効率を向上できる。
 また、図17では、例えば、TXOP sharingに使用される無線パラメータの少なくとも一部は、AP100によってスケジューリングされずに、端末200によって決定(又は、スケジューリング)されてよいので、複数の端末200に対するTXOP sharingを簡易な処理で実現できる。
 よって、本実施の形態によれば、無線通信におけるTXOP sharingにおける割当効率を向上できる。
 なお、AP100は、例えば、自己干渉を抑圧する機能を保持する場合、AP100における送信タイミングと受信タイミングとが重なることを抑制しなくてもよい。例えば、図17において、AP100は、自己干渉を抑圧する機能を保持する場合、MU-RTS TXS Trigger frameを用いて、端末1及び端末3ともにDestination Mode subfield value = 1を通知してもよい。これにより、例えば、端末1及び端末3の双方とも、割当無線リソースを用いた送受信を許可する送信先として、別の端末(端末2又は端末4)あるいはAP100が指示され、端末1及び端末3は、上り送信の送信先を柔軟に選択できる。
 また、本実施の形態では、AP100は、11be Release 1において合意されるMU-RTS TXS Trigger frame format(例えば、11be Release 1において規定されたフォーマット)に基づいて、複数端末へのTXOP sharingを端末200へ通知する。これにより、例えば、1つの端末へのTXOP sharingをサポートする11be Release 1に対応する端末(例えば、「11be Release 1対応端末」と呼ぶ)と、本実施の形態における複数の端末へのTXOP sharingをサポートする端末200(例えば、将来バージョンに対応する端末)とで、共通のTrigger frame formatを適用できる。例えば、本実施の形態において説明したMU-RTS TXS Trigger frame formatを用いて、11be Release 1対応端末が対応するTXOP sharing mode(例えば、valueが0, 1, 2の何れか)の設定(例えば、一部の値に限定した設定)を行うことにより、AP100は、11be Release 1対応端末に対するTXOP sharing modeを通知できる。
 (実施の形態1の変形例1)
 図17に示す例では、送信先情報が、複数の端末200に対する割当期間全体を対象とした、割当無線リソースを用いた送受信を許可する送信先を示す場合について説明した。このため、図17に示す例では、端末1及び端末3のそれぞれがAP100宛の送信データをバッファに保持する場合、端末3は、AP100への送信が許可されないので、TXOP sharingの割当期間においてAP100宛の送信データを送信しない。送信先情報による指示内容は、これに限定されない。
 変形例1では、例えば、AP100が通知する端末個別情報に、図18に示すように、TXOP sharingの割当期間の部分毎に、割当無線リソースを用いた送受信を許可する送信先情報が含まれてもよい。例えば、送信先情報は、TXOP sharingの割当期間(TXOPの一部の時間)を分割した複数の部分(又は、時間)のそれぞれにおける上り送信の送信先を示してもよい。
 図18に示す例では、送信先情報(例えば、Destination Mode subfieldの情報)は、割当期間を前半部分と後半部分とに分割し、割当期間の前半及び後半のそれぞれにおける割当無線リソースを用いた送受信を許可する送信先を示してもよい。
 例えば、図18において、Destination Mode subfieldの値が0の場合、割当期間の前半及び後半の双方におけるAP100への通信が不許可に設定される。Destination Mode subfieldの値が1の場合、割当期間の前半におけるAP100への通信が不許可に設定され、割当期間の後半におけるAP100への通信が許可に設定される。Destination Mode subfieldの値が2の場合、割当期間の前半におけるAP100への通信が許可に設定され、割当期間の後半におけるAP100への通信が不許可に設定される。Destination Mode subfieldの値が3の場合、割当期間の前半及び後半の双方におけるAP100への通信が許可に設定される。
 図19は、複数端末へのTXOP sharingを指示し、各端末200へ割当無線リソースを用いた送受信を許可する送信先を指示する場合のシーケンスの一例を示す図である。
 図19に示す例では、AP100は、TXOP sharingの割当期間の各部分(前半及び後半)において、TXOP sharingが適用される端末1及び端末3のうち、1つの端末と通信(例えば、データ信号の受信、及び、ACKの送信)を行う。例えば、AP100は、MU-RTS TXS Trigger frameを用いて、端末1に対してDestination Mode subfield value = 2を通知し、端末3に対してDestination Mode subfield value = 1を通知してよい。これにより、図19に示すように、AP100は、TXOP sharingの割当期間の前半では、端末1と通信を行い、端末1と異なる他の端末2、端末3及び端末4と通信を行わない。また、図19に示すように、AP100は、TXOP sharingの割当期間の後半では、端末3と通信を行い、端末3と異なる他の端末1、端末2及び端末4と通信を行わない。
 このように、変形例1では、AP100は、TXOP sharingの割当期間内において、TXOP sharingが適用される複数の端末200のうち1つの端末200と通信を行うように指示することで、AP100における送受信タイミングが重なることを抑制できる。また、変形例1では、図19に示すように、TXOP sharingの割当期間において、AP100への送信が許可される期間を分けることにより、TXOP sharingが適用される複数の端末200(例えば、端末1及び端末3)のそれぞれがAP100宛の送信データをバッファに保持する場合でも、複数の端末200のそれぞれがAP100宛の送信データを送信可能となる。
 なお、図18及び図19では、TXOP sharingの割当期間を前半及び後半の2つに等分割する場合について説明したが、TXOP sharingの割当期間を分割した部分の設定方法はこれに限定されない。例えば、割当期間が分割される個数は、2つに限定されず、3つ以上の期間(又は、部分)に分割されてもよい。また、割当期間は、等分割される場合に限定されず、不均等に分割されてもよい。
 また、図18では、一例として、Destination Mode subfieldの値が何れの場合でも別の端末への送信が許可される場合について説明したが、これに限定されず、Destination Mode subfieldの値に応じて、別の端末への送信の許可の有無が設定されてもよい。例えば、Destination Mode subfieldの値の何れかにおいて、AP100への送信が許可され、別の端末への送信が不許可に設定されてもよい。
 (実施の形態1の変形例2)
 変形例1では、TXOP sharingの割当期間の部分毎に、割当無線リソースを用いた送受信を許可する送信先を示す送信先情報を通知する方法として、図18に示すように、割当期間の各部分における送受信の許可の有無の組み合わせと、Destination Mode subfieldの値との関連付けを定義する場合について説明したが、これに限定されない。
 変形例2では、TXOP sharingの割当期間の部分毎に、割当無線リソースを用いた送受信を許可する送信先を示す送信先情報を通知する方法として、AP100は、同一端末200に対して、割当期間の複数の部分それぞれに対応する複数のUser Info fieldを通知してもよい。例えば、AP100は、同一端末200に対して、複数のUser Info field内のAllocation Duration毎に(例えば、割当期間の部分毎に)、割当無線リソースを用いた送受信の許可の有無を示す送信先情報(例えば、Destination Mode)を指示してもよい。
 例えば、図20に示すように、1つのTrigger frameにおいて、同一AID(又は、重複したAID)が設定された複数のUser Info fieldが配置されてもよい。複数のUser Info fieldのそれぞれは、例えば、割当期間内の異なる期間(部分)に対応し、各User Info fieldにおける送信先情報(例えば、Destination Mode subfieldの値)には、異なる値が設定可能である。
 これにより、例えば、図19の例のように、端末1及び端末3のそれぞれがAP100宛の送信データをバッファに保持する場合でも、AP100へ送信を許可する割当期間を、端末1及び端末3のそれぞれにおける送信データのバッファ量に応じて柔軟に設定(例えば、分割)可能となる。よって、変形例2によれば、AP100宛の送信データを効率的に送信できる。
 (実施の形態2)
 本実施の形態では、複数の端末(例えば、STA)に対して割当期間が異なるTXOP sharingを行う場合について説明する。
 本実施の形態に係る無線通信システムは、実施の形態1と同様、AP100及び端末200を備えてよい。
 AP100は、例えば、P2Pを行う端末200(例えば、P2P端末)それぞれの送信バッファ量に応じて、各端末200に対して異なる割当時間を設定することにより、無線リソースの利用効率を向上でき、システム性能を向上できる。
 例えば、TXOP sharingにおいて、Secondary channel及び割当期間の設定によっては、割当期間のリソースの利用効率が低下する場合があり得る。
 一例として、図21に示すように、20MHz channel#1(Primary channel)が端末1(Non-AP STA 1)に割り当てられ、20MHz channel#2(Secondary channel)が端末3(Non-AP STA 3)に割り当てられる場合について説明する。図21に示すように、端末1及び端末3のそれぞれに設定される割当期間(Time allocated in MU-RTS TXS TF)は異なる。例えば、端末3に設定される割当期間は、端末1に設定される割当期間よりも短い。
 この場合、図21に示すように、端末3への20MHz channel#2(Secondary channel)の割当期間終了後、点線で示す20MHz channel#2(Secondary channel)の無線リソース(割当帯域)は、空きリソースとなり、20MHz channel#1(Primary channel)の無線リソースは、端末1によって使用される。よって、Primary channelが端末1によって使用中のため、AP100でのキャリアセンス結果がBusyとなるため、20MHz channel#2(Secondary channel)の無線リソース(割当帯域)が空きリソース(例えば、キャリアセンス結果がIdle)であるにもかかわらず、AP100は、Secondary channelに対応するリソースにおいて信号を送信できず、システム性能が低減する可能性がある。
 本実施の形態では、1つのMU-RTS TXS Trigger frameを用いて、複数の端末200に対して割当期間が異なるTXOP sharingを効率的に行う方法について説明する。
 [基地局の構成]
 本実施の形態に係るAP100の構成例は、図10と同様でよい。例えば、本実施の形態に係るAP100において、スケジューリング部101の動作が実施の形態1と異なってよい。
 スケジューリング部101は、例えば、端末情報保持部110から入力される端末情報に基づいて、端末200に適用する割当期間、及び、割当無線リソースを決定する。
 例えば、スケジューリング部101は、スケジューリング対象の端末200の送信バッファ量に応じて、端末200それぞれの割当期間を決定してよい。また、スケジューリング部101は、例えば、1つのMU-RTS TXS Trigger frameを用いてスケジューリングする複数の端末200のうち、決定された割当期間が短い端末200ほど、割当帯域をPrimary channel(20MHz primary channelを含む20MHz×N channel)に割り当てやすくしてよい。例えば、スケジューリング部101は、1つのMU-RTS TXS Trigger frameを用いてスケジューリングする複数の端末200のうち、割当期間が最小の端末200に対して、Primary channelを割り当て、他の端末200に対して、Secondary channelを割り当ててよい。これにより、TXOP sharingの割当期間(例えば、TXOPの一部の時間)において、複数の端末200のうち、Primary channelに割り当てられる端末200に対する割当時間は、Secondary channelに割り当てられる端末200に対する割当時間よりも短い。
 また、スケジューリング部101は、例えば、複数端末200への割当時間の差に基づいて、Primary channelでの割当期間終了後に送信するデータ長(例えば、PPDU長)を決定してよい。例えば、スケジューリング部101は、複数端末200への割当時間のうち、Secondary channelでの割当期間と、Primary channelでの割当期間との差に基づいて、データ長(例えば、PPDU長)を決定してよい。例えば、Primary channelでの割当期間終了後に送信されるPPDU長は、スケジューリング対象の端末200間の最大割当期間と最小割当期間との差に基づいて決定されてもよい。
 AP100における他の構成部の処理は、例えば、実施の形態1における処理と同様でよい。
 [端末の構成]
 本実施の形態に係る端末200の構成例は、図16と同様でよい。例えば、本実施の形態に係る端末200において、復調部202の動作が実施の形態1と異なってよい。
 例えば、実施の形態1では、復調部202は、接続するAP100が決定したPrimary channelにおいて最初に復調処理を行い、復調した信号が当該端末200宛の信号でない場合、Secondary channelの復調処理を行わない。
 本実施の形態では、例えば、MU-RTS TXS Trigger frameにおいて、複数端末200に対するTXOP Sharingが適用される場合、AP100が取得したTXOP期間(例えば、Trigger Frameの端末共通情報のUL Length subfieldで通知される期間)においては、Primary channelを含まないSecondary channelへのPPDU送信を許可する仕様としてよい。
 よって、本実施の形態では、例えば、AP100のTXOPの時間内、又は、MU-RTS TXS Trigger frame(例えば、UL length subfield)によって通知される時間内では、AP100及び端末200に対して、Primary channelを含まないSecondary channelでの通信が許可されてよい。
 端末200において、復調部202は、例えば、Primary channelに加えて、Secondary channelについても同様の復調処理を行ってよい。例えば、復調部202は、Primary channelにおいて復調した信号が当該端末200宛の信号であるか否かに依らず、Secondary channelの復調処理を行ってよい。
 なお、端末200における処理量の低減のため、Secondary channelの復調処理を行う端末200は、MU-RTS TXS Trigger frameのUser Info subfieldで指示された端末200に限定されてもよい。
 端末200における他の構成部の処理は、例えば、実施の形態1の処理と同様でよい。
 [AP100及び端末200の動作例]
 次に、本実施の形態に係るAP100及び端末200の動作例について説明する。
 図22は、複数端末200へのTXOP sharingを指示し、各端末200へ割当無線リソースを用いた送受信を許可する送信先を指示する場合のシーケンスの一例を示す図である。
 図22では、例えば、AP100(「AP」と表す)は、端末共通情報として、AP100と異なる複数の端末200(図22の端末1及び端末3)に対して、TXOP sharing modeに関する情報を指示してよい。
 例えば、複数端末へのTXOP sharingが適用される複数の端末200は、P2P設定済(例えば、TDLS設定済又はDirect link設定済)の端末でよい。図22に示す例では、端末1と端末2との間においてP2P linkが予め設定(例えば、TDLSが設定)され、端末3と端末4との間においてP2P linkが予め設定(TDLSを設定)される。例えば、図22では、AP100は、図11に示すTXOP sharing mode subfield value=3を通知することにより、端末1及び端末3に対して、複数端末へのTXOP sharingを指示してよい。
 また、図22では、例えば、AP100は、複数の端末200(例えば、端末1及び端末3)のそれぞれに対する端末個別情報として、割当無線リソースを用いた送受信を許可する送信先情報(例えば、Destination Mode)、割当channelに関する情報(例えば、RU allocation)、及び、割当期間に関する情報を通知してよい。
 例えば、図22に示す例では、AP100は、端末1の割当期間(図22のTime allocated in MU-RTS TXS TF to STA1)と比較して、送信バッファ量がより小さい端末3に対して、より短い割当期間(図22のTime allocated in MU-RTS TXS TF to STA3)を指示してよい。よって、図22に示す例では、端末3に対する割当期間は、端末1に対する割当期間よりも短い。
 そして、AP100は、端末3に対する割当帯域をPrimary channel(20MHz channel#1)に設定し、他のスケジューリング対象の端末200(例えば、端末1を含む)の割当帯域をSecondary channel(例えば、20MHz channel#2を含む)に設定してよい。
 これにより、Primary channelにおける端末3の割当期間終了後、AP100は、所定時間(例えば、PIFS)でのキャリアセンスの結果がIdleであれば、図22に示すように、Secondary channelが使用されている場合でも、空きリソースであるPrimary channelにおいて、別の端末宛の信号を送信可能となる。よって、本実施の形態によれば、複数の端末200に対して割当期間が異なるTXOP sharingにおいて、一部の端末200の割当期間が終了した後の無線リソースを有効利用できるので、リソースの利用効率を向上でき、システム性能を向上できる。
 また、AP100は、例えば、Primary channelでの割当期間の終了後に送信するデータ長(PPDU長)を、スケジューリングされる端末200間の最大割当期間と最小割当期間の差に設定してよい。図22の例では、AP100は、端末1の割当期間と端末3の割当期間との差に基づいて、PPDU長を決定してよい。これにより、空きリソースを有効利用できるので、システム性能を向上できる。
 また、例えば、全ての端末200の割当期間終了後の残りのTXOP期間において、AP100は、Secondary 20 MHz channelを含む、Trigger frameの送信帯域全ての帯域を用いて、信号を送信してよい。これにより、複数の端末200に対して割当期間が異なるTXOP sharingにおいて、無線リソースを有効利用できるので。システム性能を向上できる。
 例えば、図23に示すように、AP100は、端末3の割当期間終了後に、Primary channelにおいて、別の端末宛ての信号を送信してよい。
 その後、AP100は、全ての端末200(例えば、端末1及び端末3)の割当期間終了後の残りのTXOP期間において、Primary channelに加え、Secondary channelでも信号を送信してよい。このとき、AP100は、例えば、図23に示すように、Primary channelを含まないSecondary channelでのPPDU送信を行ってよい。また、端末200は、例えば、Primary channelにおける復調の結果に依らず、Secondary channelの復調処理を行ってよい。
 図23に示すように、Primary channelが、端末3の割当期間終了後に別の端末に割り当てられた場合でも、AP100は、Secondary channelにおける端末1の割当期間終了後に、Primary channelを含まないSecondary channelでの通信を行うことができる。
 これにより、全ての端末200の割当期間終了後の残りのTXOP期間において、AP100は、Secondary 20 MHz channelで信号を送信できる。よって、本実施の形態によれば、無線リソースを有効利用でき、システム性能を向上できる。
 また、例えば、図23において、Secondary channelの復調処理を行う端末200が、MU-RTS TXS Trigger frameのUser Info subfieldで指示された端末200に限定される場合、Secondary channelで送信される信号は、端末1あるいは端末3宛の信号でもよい。端末200は、複数端末に対するTXOP Sharingが指示される場合、Trigger frameで通知されるTXOP期間において、Primary channelに加えて、Secondary channelの復調処理を行ってもよい。
 なお、図22及び図23に示す例では、TXOP sharingが適用される端末200の数が2つの場合について説明したが、これに限定されず、3つ以上でもよい。
 また、図22及び図23に示す例では、TXOP sharingが適用される端末200に対する割当期間のうち、最大割当期間と最小割当期間との差に基づいてPPDU長を決定する場合について説明したがこれに限定されない。例えば、TXOP sharingが適用される端末200に対する割当期間のうち、Primary channelに対する割当期間と、Primary channelに対する割当期間よりも長い割当期間との差に基づいてPPDU長が決定されてもよい。
 また、図22及び図23に示す例では、TXOP sharingが適用される端末200のうち、最小の割当期間が設定される端末200に対する割当帯域をPrimary channelに設定する場合について説明したが、これに限定されない。例えば、Primary channelと、Primary channelに対する割当期間よりも長い割当期間が設定されるSecondary channelとの間において、上述した実施の形態が適用されてもよい。
 以上、本開示の各実施の形態について説明した。
 (他の実施の形態)
 (1)実施の形態1、2では、Secondary channel(例えば、Primary 20MHz channelを含まないchannel)における送受信の例について説明したが、Secondary channelの設定方法として、以下の設定例を適用してもよい。
 <設定例1>
 設定例1では、MU-RTS TXS Trigger frameによってスケジューリングされる端末200は、TXOP sharingされる期間において、当該Trigger frameによって指示される帯域にてP2P linkの送信を行ってもよい。例えば、Trigger frameによって指示される帯域がSecondary channelを含む帯域(又は、Primary channelを含まない帯域)の場合、端末200は、当該帯域においてP2P linkの送信を行ってもよい。
 例えば、設定例1では、既存のTrigger frame(例えば、Basic Trigger等)によるUL MU送信と同様のルールが適用されてよい。このように、設定例1では、既存のルールの適用により、Secondary channelでの送信を容易に実現できる。
 <設定例2>
 設定例2では、AP100がSecondary channelに割り当てる端末200は、Sub-Channel Selective(SST)Modeが設定される端末(例えば、SST端末と呼ぶ)とする。
 AP100は、例えば、TXOP Sharingを指示するMU-RTS TXS Trigger frameにより、SST端末に対して、TXOP sharing期間内のSST Modeで設定したSecondary channelでの送信を指示してもよい。
 SST setupは、例えば、11axと同様に、Trigger-enabled TWTのネゴシエーションにより確立され、AP100は、TWT期間において、設定例2に係るMU-RTS TXS Trigger frame(例えば、拡張MU-RTS TXS TF)を用いて、Secondary channelでの送信を指示してもよい。このように、設定例2では、既存の機能の再利用により、Secondary channelでの送信を容易に実現できる。
 <設定例3>
 設定例3では、TXOP sharingされる割当期間において送受信に用いるchannelの事前通知の方法には、TDLSにおいてP2Pの端末ペア間において送受信するchannelをネゴシエーションするOff-channel設定の仕組み(TDLS Channel Switch Request/Response frame)が流用されてもよい。このように、設定例3では、既存の機能の再利用により、Secondary channelでの送信が容易に実現できる。
 以上、設定例1~3について説明した。
 なお、上記の設定例1~3の何れかを組み合わせて適用してもよい。例えば、設定例1及び設定例2の組み合わせにより、AP100がSecondary channelに割り当てる端末200はSST端末であり、AP100がPrimary channelへ割り当てる端末200はSST Modeが未設定の端末200でもよい。
 (2)実施の形態1、2では、TDLS(P2P link)が設定済の端末200に対するTXOP Sharingについて説明したが、TDLSに関連するTXOP sharingの動作として、以下の動作例が適用されてもよい。
 <動作例1>
 動作例1では、複数リンクにおいてTDLSが設定済のNon-STR(non-simultaneous transmit and receive)端末は、複数リンクのうち、或るリンクでTXOP sharingが実行中の場合、他のリンクではAP100からのRTSフレームに対するCTSフレームを送信(又は、応答)しなくてもよい。
 これにより、例えば、複数のP2P linkにおいてTXOP sharingが設定される場合でも、Non-STR端末の送信タイミングと受信タイミングとが重なることを抑制できる。
 <動作例2>
 動作例2では、TXOP sharing向けのTDLS手順が新たに規定されてもよい。
 既存のTDLSでは、AP100は、P2P端末間のRequest frame及びresponse frame(以下、Request/response frameとも表す)を中継してよい。この場合、TDLSにおける設定内容はカプセル化されたデータでやりとりされるので、AP100は、P2P端末間のRequest/response frameを復号しなくてよい。
 動作例2では、TXOP sharing向けのTDLSでは、AP100は、P2P端末間のRequest/response frameの内容を復号し、解釈(又は、特定、把握)してもよい。例えば、TXOP sharing向けのRequest/response frameには、P2P通信の送信先の端末情報(例えば、端末ID、Capability情報など)が含まれてもよい。
 これにより、AP100は、P2Plinkに関する情報を特定できるので、例えば、P2P linkにおける端末ペア(例えば、通信相手)が重複する複数の端末200に対して同時にTXOP sharingを指示することを避けることができる。例えば、AP100は、P2P端末間のRequest/response frameの解釈により、端末1と端末2との間でP2P linkが設定され、端末1と端末3との間でP2P linkが設定されることを把握した場合、それぞれが端末1と端末ペアである端末2と端末3とに対して同時にTXOP sharingを指示しなくてよい。
 よって、動作例2では、P2P端末の送信タイミングと受信タイミングとが重なることを抑制できる。前述の例の場合、端末1について、端末2と端末3との間で送受信タイミングが重なることを抑制できる。
 また、P2P linkの設定において、Off-channel(例えば、AP100のOperation帯域外でP2P通信を行う設定)が実施される場合、AP100は、P2P端末間のRequest/response frameの解釈により、Off-channelを把握できる。Off-channelを実施するP2P端末は、例えば、AP100のOperation帯域でのスケジューリングができない。よって、AP100は、Off-channelを実施する端末200を、TXOP sharingのスケジューリング対象から除外してもよい。これにより、AP100におけるTXOP sharingのスケジューリングの効率を向上できる。
 <動作例3>
 動作例3では、端末200がAP100に通知又はネゴシエーションするframe(例えば、TDLS Action frameのタイプ)を新たに定義してよい。
 動作例3では、例えば、上述した動作例2のように既存のRequest/response frameを流用する代わりに、新たなframeを定義してよい。これにより、動作例2で示した情報のやり取りをより効率的に実施できる。
 以上、動作例1~3について説明した。
 なお、上記の動作例1~3の何れかは組み合わせて適用されてもよい。例えば、動作例2及び動作例3の組み合わせにより、TXOP sharingに用いるTDLSに関連する情報の一部は既存のTDLS frameによってAP100へ通知され、他の情報は新たに定義されるframeによってAP100へ通知される手順でもよい。
 (3)上記各実施の形態において、端末200がTXOP sharing modeの各モードをサポートするか否かを示すCapability情報を定義し、端末200からAP100へ通知されてもよい。
 例えば、上記各実施の形態において説明したTXOP Sharing Mode 3が設定される場合、図24に示すように、Capability情報を通知するfield(例えば、EHT MAC Capabilities Information field)に、端末200がTXOP Sharing Mode 3をサポートするか否かを示すsubfield(例えば、Triggered TXOP Sharing Mode 3 Support subfield)が設定(例えば、追加)されてもよい。
 例えば、Triggered TXOP Sharing Mode 3 Support subfieldは、既存のEHT MAC Capabilities Information fieldにおけるReservedビットの一部(図24に示す例ではB9)を用いて定義されてもよい。
 これにより、AP100は、端末200がサポートするTXOP sharing modeに応じて(例えば、限定して)、TXOP Sharingを指示できる。
 (4)上記各実施の形態において、複数の端末200の信号を周波数多重(FDM)する場合、AP100は、各端末200(例えば、スケジューリングされる端末200に加えて、当該端末200の送信先のP2P端末を含めてもよい)が割当期間において送信可能な最大送信電力を、Trigger frameの端末個別情報(例えば、User Info field)に含めて通知してもよい。送信可能な最大送信電力の通知により、周波数多重における隣接チャネル干渉を抑圧できる。
 例えば、図25に示すように、上記各実施の形態におけるUser Info field(例えば、図12)のReserved領域の一部を用いて最大送信電力(図25ではMaximum Transmit Power subfield)が指示されてもよい。
 例えば、AP100は、端末200から予めフィードバックされるAP及びP2P端末との間のパスロス又は受信電力情報に基づいて、各端末200の最大送信電力を決定してもよい。
 (5)上述した各実施の形態では、APから複数端末へのTXOP sharingを通知する場合について説明したが、TXOP sharingを通知する装置は、STAに限定されない。
 例えば、実施の形態1及び2において説明したAPから複数端末へのTXOP sharingの通知方法は、Multi-AP Coordination transmission(複数AP協調通信)におけるSharing APからShared APへの無線リソース(時間リソース、及び、周波数リソース)割当の通知方法に適用してもよい。
 複数AP協調通信には、例えば、複数のAP間に異なる周波数リソースが割り当てられる「Coordinated-Frequency Division Multiple Access(FDMA)」、及び、複数のAP間に異なる時間リソースが割り当てられる「Coordinated-Time Division Multiple Access(TDMA)」がある。これらの複数AP協調通信において、Sharing APからShared APへの無線リソース割当に、上述したMU-RTS TXS Trigger frameによる通知方法を利用してもよい。
 例えば、上述したAPから複数端末へのTXOP sharing(無線リソース割当)を、複数AP協調通信におけるShared APから複数Sharing APへの無線リソース割当(TXOP sharingを含む)に読み替えてもよい。
 また、上述したAPから複数P2P端末へのTXOP sharing(無線リソース割当)を、複数AP協調通信におけるShared APから複数のSharing APと当該Sharing AP配下の端末とのペアに対する無線リソース割当(TXOP sharingを含む)に読み替えてもよい。
 また、複数AP協調通信において、MU-RTS TXS Trigger frameを用いる場合、複数AP協調通信向けのTXOP sharing modeを明示的に通知してもよい。例えば、図2に示すCommon Info fieldのTXOP Sharing ModeのReserved領域において、複数AP協調通信向けのTXOP sharing modeが通知されてもよい。あるいは、Common Info fieldのsubfieldの一部(例えば、CTSフレームの送信には使用されないsubfieldの一部)に複数AP協調通信向けのTXOP sharing modeを通知するsubfieldを設けてもよい。
 (6)上述した各実施の形態において示すシーケンス図は、一例として、MU-RTS TXS Trigger frameに対してCTSフレームを応答する場合について説明したが、本開示の一実施例は、これに限定されない。例えば、CTSフレームの応答の有無をAP100がTrigger frameによって端末200へ指示してもよい。これにより、隠れ端末の発生が少ないと想定される環境では、端末200からのCTSフレームの応答を省略でき、スループット性能を改善できる。
 (7)上述した各実施の形態において、TXOP Sharing Mode、Destination Mode、又は、Maximum Transmit Powerを含む各制御情報が配置されるフィールドは、上述したフィールドに限定されず、他のフィールドに配置されてもよい。また、TXOP Sharing Mode、Destination Mode、又は、Maximum Transmit Powerを含む各制御情報を通知するためのビット数は、上述した例に限定されず、他のビット数でもよい。
 また、上述した各実施の形態において、TXOP sharingの割当期間を指示するフィールドは、UL Length subfieldに限らず、他のsubfieldでもよい。
 また、上述した各実施の形態において、Trigger frameの構成、及び、Trigger frame内のCommon Info field及びUser Info fieldの構成は、上述した例に限定されず、例えば、上述した各fieldにおいて、他のsubfieldの追加及び一部のsubfieldの削除の少なくとも一方が行われた他の構成でもよい。
 また、例えば、TXOP sharingにおいて割り当てられる複数の端末200は、割当期間において周波数リソース及び時間リソースの少なくとも一方が異なるリソースにおいて信号多重されてもよい。
 また、上述した各実施の形態では、一例として、複数端末へのSharing APの通知にMU-RTS TXS Trigger frameを用いる場合について説明したが、複数端末へのSharing APの通知におけるTrigger typeはMU-RTSに限定されず、他のTrigger typeでもよく、将来のバージョンにおいて新たに定義されるTrigger typeでもよい。
 また、P2P通信において端末200が通知する別の端末は、当該端末200が接続するAP100配下の端末でもよく、端末200が接続するAP100と異なるAP配下の端末の何れでもよい。
 また、上記実施の形態では、一例として、11beのフォーマットに基づいて説明したが、本開示の一実施例を適用するフォーマットは、11beのフォーマットに限定されない。本開示の一実施例は、例えば、車載向け規格であるIEEE 802.11pの次世代規格であるIEEE 802.11bd(NGV(Next Generation V2X))向けに適用されてもよい。
 (補足)
 上述した各実施の形態に示した機能、動作又は処理を端末200がサポートするか否かを示す情報が、例えば、端末200の能力(capability)情報あるいは能力パラメータとして、端末200からAP100へ送信(あるいは通知)されてもよい。
 能力情報は、上述した各実施の形態に示した機能、動作又は処理の少なくとも1つを端末200がサポートするか否かを個別に示す情報要素(IE)を含んでもよい。あるいは、能力情報は、上述した各実施の形態に示した機能、動作又は処理の何れか2以上の組み合わせを端末200がサポートするか否かを示す情報要素を含んでもよい。情報要素は単に要素(element)とも呼ばれる。
 AP100は、例えば、端末200から受信した能力情報に基づいて、能力情報の送信元端末200がサポートする(あるいはサポートしない)機能、動作又は処理を判断(あるいは決定または想定)してよい。AP100は、能力情報に基づく判断結果に応じた動作、処理又は制御を実施してよい。例えば、AP100は、端末200から受信した能力情報に基づいて、複数STAへのTXOP sharingを制御してよい。
 なお、上述した各実施の形態に示した機能、動作又は処理の一部を端末200がサポートしないことは、端末200において、そのような一部の機能、動作又は処理が制限されることに読み替えられてもよい。例えば、そのような制限に関する情報あるいは要求が、AP100に通知されてもよい。
 端末200の能力あるいは制限に関する情報は、例えば、規格において定義されてもよいし、AP100において既知の情報あるいはAP100へ送信される情報に関連付けられて暗黙的(implicit)にAP100に通知されてもよい。
 本開示はソフトウェア、ハードウェア、又は、ハードウェアと連携したソフトウェアで実現することが可能である。上記実施の形態の説明に用いた各機能ブロックは、部分的に又は全体的に、集積回路であるLSIとして実現され、上記実施の形態で説明した各プロセスは、部分的に又は全体的に、一つのLSI又はLSIの組み合わせによって制御されてもよい。LSIは個々のチップから構成されてもよいし、機能ブロックの一部または全てを含むように一つのチップから構成されてもよい。LSIはデータの入力と出力を備えてもよい。LSIは、集積度の違いにより、IC、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。
 集積回路化の手法はLSIに限るものではなく、専用回路、汎用プロセッサ又は専用プロセッサで実現してもよい。また、LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)や、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。本開示は、デジタル処理又はアナログ処理として実現されてもよい。
 さらには、半導体技術の進歩または派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
 本開示は、通信機能を持つあらゆる種類の装置、デバイス、システム(通信装置と総称)において実施可能である。通信装置は無線送受信機(トランシーバー)と処理/制御回路を含んでもよい。無線送受信機は受信部と送信部、またはそれらを機能として、含んでもよい。無線送受信機(送信部、受信部)は、RF(Radio Frequency)モジュールと1または複数のアンテナを含んでもよい。RFモジュールは、増幅器、RF変調器/復調器、またはそれらに類するものを含んでもよい。通信装置の、非限定的な例としては、電話機(携帯電話、スマートフォン等)、タブレット、パーソナル・コンピューター(PC)(ラップトップ、デスクトップ、ノートブック等)、カメラ(デジタル・スチル/ビデオ・カメラ等)、デジタル・プレーヤー(デジタル・オーディオ/ビデオ・プレーヤー等)、着用可能なデバイス(ウェアラブル・カメラ、スマートウオッチ、トラッキングデバイス等)、ゲーム・コンソール、デジタル・ブック・リーダー、テレヘルス・テレメディシン(遠隔ヘルスケア・メディシン処方)デバイス、通信機能付きの乗り物又は移動輸送機関(自動車、飛行機、船等)、及び上述の各種装置の組み合わせがあげられる。
 通信装置は、持ち運び可能又は移動可能なものに限定されず、持ち運びできない又は固定されている、あらゆる種類の装置、デバイス、システム、例えば、スマート・ホーム・デバイス(家電機器、照明機器、スマートメーター又は計測機器、コントロール・パネル等)、自動販売機、その他IoT(Internet of Things)ネットワーク上に存在し得るあらゆる「モノ(Things)」をも含む。
 通信には、セルラーシステム、無線LANシステム、通信衛星システム等によるデータ通信に加え、これらの組み合わせによるデータ通信も含まれる。
 また、通信装置には、本開示に記載される通信機能を実行する通信デバイスに接続又は連結される、コントローラやセンサー等のデバイスも含まれる。例えば、通信装置の通信機能を実行する通信デバイスが使用する制御信号やデータ信号を生成するような、コントローラやセンサーが含まれる。
 また、通信装置には、上記の非限定的な各種装置と通信を行う、あるいはこれら各種装置を制御する、インフラストラクチャ設備、例えば、基地局、アクセスポイント、その他あらゆる装置、デバイス、システムが含まれる。
 本開示の一実施例に係るアクセスポイントは、複数の端末の上り送信を指示する制御信号であって、前記複数の端末のそれぞれに対する前記上り送信の送信先に関する情報を含む前記制御信号を生成する制御回路と、前記制御信号を送信する送信回路と、を具備する。
 本開示の一実施例において、前記上り送信に割り当てられる無線リソースは、前記アクセスポイントが獲得した送信機会の少なくとも一部の時間、及び、前記制御信号が割り当てられる帯域の少なくとも一部の帯域である。
 本開示の一実施例において、前記送信先に関する情報は、前記アクセスポイントへの前記上り送信を許可するか否かを示す。
 本開示の一実施例において、前記送信先に関する情報は、前記複数の端末と異なる他の端末及び前記アクセスポイントの何れかとの通信の許可、及び、前記他の端末との通信の許可の何れかを示す。
 本開示の一実施例において、前記複数の端末は、端末間通信が設定された端末である。
 本開示の一実施例において、前記制御信号によって指示した帯域において、前記制御信号に対する応答信号を受信する受信回路、をさらに具備する。
 本開示の一実施例において、前記送信先に関する情報は、前記一部の時間を分割した複数の部分のそれぞれにおける前記送信先を示す。
 本開示の一実施例において、前記一部の時間において、前記複数の端末のうち、Primary channelに割り当てられる端末に対する割当時間は、Secondary channelに割り当てられる端末に対する割当時間よりも短い。
 本開示の一実施例において、前記送信機会の時間内では、前記アクセスポイント及び前記複数の端末に対して、Primary channelを含まない帯域での通信が許可される。
 本開示の一実施例において、前記一部の時間内では、前記アクセスポイント及び前記複数の端末に対して、Primary channelを含まない帯域での通信が許可される。
 本開示の一実施例において、前記Primary channelを含まない帯域が指示される端末は、Sub-Channel Selective(SST) Modeが設定される端末である。
 本開示の一実施例に係る端末は、複数の端末の上り送信を指示する制御信号であって、前記複数の端末のそれぞれに対する前記上り送信の送信先に関する情報を含む前記制御信号を受信する受信回路と、前記制御信号に基づいて、前記上り送信を制御する制御回路と、を具備する。
 本開示の一実施例に係る通信方法において、アクセスポイントは、複数の端末の上り送信の割り当てを指示する制御信号であって、前記複数の端末のそれぞれに対する前記上り送信の送信先に関する情報を含む前記制御信号を生成し、前記制御信号を送信する。
 本開示の一実施例に係る通信方法において、端末は、複数の端末の上り送信の割り当てを指示する制御信号であって、前記複数の端末のそれぞれに対する前記上り送信の送信先に関する情報を含む前記制御信号を受信し、前記制御信号に基づいて、前記上り送信を制御する。
 2022年5月24日出願の特願2022-084544の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
 本開示の一実施例は、無線通信システムに有用である。
 100 AP
 101,206 スケジューリング部
 102 Common Info生成部
 103 User Info生成部
 104 Trigger frame生成部
 105,208 誤り訂正符号化部
 106,209 変調部
 107,201 無線送受信部
 108,202 復調部
 109,203 誤り訂正復号部
 110 端末情報保持部
 200 端末
 204 Common Info取得部
 205 User Info取得部
 207 データ生成部
 

 

Claims (14)

  1.  複数の端末の上り送信を指示する制御信号であって、前記複数の端末のそれぞれに対する前記上り送信の送信先に関する情報を含む前記制御信号を生成する制御回路と、
     前記制御信号を送信する送信回路と、
     を具備するアクセスポイント。
  2.  前記上り送信に割り当てられる無線リソースは、前記アクセスポイントが獲得した送信機会の少なくとも一部の時間、及び、前記制御信号が割り当てられる帯域の少なくとも一部の帯域である、
     請求項1に記載のアクセスポイント。
  3.  前記送信先に関する情報は、前記アクセスポイントへの前記上り送信を許可するか否かを示す、
     請求項1に記載のアクセスポイント。
  4.  前記送信先に関する情報は、前記複数の端末と異なる他の端末及び前記アクセスポイントの何れかとの通信の許可、及び、前記他の端末との通信の許可の何れかを示す、
     請求項1に記載のアクセスポイント。
  5.  前記複数の端末は、端末間通信が設定された端末である、
     請求項1に記載のアクセスポイント。
  6.  前記制御信号によって指示した帯域において、前記制御信号に対する応答信号を受信する受信回路、をさらに具備する、
     請求項1に記載のアクセスポイント。
  7.  前記送信先に関する情報は、前記一部の時間を分割した複数の部分のそれぞれにおける前記送信先を示す、
     請求項2に記載のアクセスポイント。
  8.  前記一部の時間において、前記複数の端末のうち、Primary channelに割り当てられる端末に対する割当時間は、Secondary channelに割り当てられる端末に対する割当時間よりも短い、
     請求項2に記載のアクセスポイント。
  9.  前記送信機会の時間内では、前記アクセスポイント及び前記複数の端末に対して、Primary channelを含まない帯域での通信が許可される、
     請求項2に記載のアクセスポイント。
  10.  前記一部の時間内では、前記アクセスポイント及び前記複数の端末に対して、Primary channelを含まない帯域での通信が許可される、
     請求項2に記載のアクセスポイント。
  11.  前記Primary channelを含まない帯域が指示される端末は、Sub-Channel Selective(SST) Modeが設定される端末である、
     請求項10に記載のアクセスポイント。
  12.  複数の端末の上り送信を指示する制御信号であって、前記複数の端末のそれぞれに対する前記上り送信の送信先に関する情報を含む前記制御信号を受信する受信回路と、
     前記制御信号に基づいて、前記上り送信を制御する制御回路と、
     を具備する端末。
  13.  アクセスポイントは、
     複数の端末の上り送信の割り当てを指示する制御信号であって、前記複数の端末のそれぞれに対する前記上り送信の送信先に関する情報を含む前記制御信号を生成し、
     前記制御信号を送信する、
     通信方法。
  14.  端末は、
     複数の端末の上り送信の割り当てを指示する制御信号であって、前記複数の端末のそれぞれに対する前記上り送信の送信先に関する情報を含む前記制御信号を受信し、
     前記制御信号に基づいて、前記上り送信を制御する、
     通信方法。
PCT/JP2023/013236 2022-05-24 2023-03-30 アクセスポイント、端末、及び通信方法 WO2023228566A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022084544 2022-05-24
JP2022-084544 2022-05-24

Publications (1)

Publication Number Publication Date
WO2023228566A1 true WO2023228566A1 (ja) 2023-11-30

Family

ID=88918992

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/013236 WO2023228566A1 (ja) 2022-05-24 2023-03-30 アクセスポイント、端末、及び通信方法

Country Status (1)

Country Link
WO (1) WO2023228566A1 (ja)

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
DIBAKAR DAS (INTEL): "PDT channel access Triggered SU", IEEE DRAFT; 11-21-0268-08-00BE-PDT-CHANNEL-ACCESS-TRIGGERED-SU, IEEE-SA MENTOR, PISCATAWAY, NJ USA, vol. 802.11 EHT; 802.11be, no. 8, 13 May 2021 (2021-05-13), Piscataway, NJ USA , pages 1 - 7, XP068181688 *
JAY YANG(NOKIA): "TB SU PPDU and TB P2P PPDU Consideration ( TXOP sharing for use in MU P2P)", IEEE DRAFT; 11-20-1938-08-00BE-TB-SU-PPDU-AND-TB-P2P-PPDU-CONSIDERATION, IEEE-SA MENTOR, PISCATAWAY, NJ USA, vol. 802.11 EHT; 802.11be, no. 8, 25 June 2021 (2021-06-25), Piscataway, NJ USA , pages 1 - 8, XP068182203 *
META: "p2p Support in Restricted TWT: Use Cases and Signaling Design Discussion", IEEE DRAFT; 11-21-1855-00-00BE-P2P-SUPPORT-IN-RESTRICTED-TWT-USE-CASES-AND-SIGNALING-DESIGN-DISCUSSION, IEEE-SA MENTOR, PISCATAWAY, NJ USA, vol. 802.11 EHT; 802.11be, no. 0, 12 November 2021 (2021-11-12), Piscataway, NJ USA, pages 1 - 9, XP068198052 *
YANJUN SUN (QUALCOMM): "PDT on MU-RTS", IEEE DRAFT; 11-21-0991-03-00BE-PDT-ON-MU-RTS, IEEE-SA MENTOR, PISCATAWAY, NJ USA, vol. 802.11 EHT; 802.11be, no. 3, 6 July 2021 (2021-07-06), Piscataway, NJ USA , pages 1 - 9, XP068182305 *

Similar Documents

Publication Publication Date Title
US10206070B2 (en) Space division multiple access for wireless LAN, and channel estimation for the same
EP3512289B1 (en) Wireless communication method using enhanced distributed channel access, and wireless communication terminal using same
US10542557B2 (en) System and method for digital communications with interference avoidance
JP2022111242A (ja) 通信装置、通信方法および集積回路
JP2017522836A (ja) 無線lanシステムにおいて上りリンク多重ユーザ送信方法及びそのための装置
US20230077920A1 (en) Wireless communication method and wireless communication terminal for transmitting information on buffer status
JP2012070090A (ja) 無線通信装置
GB2571250A (en) Method and apparatus for reporting quantity of data for direct-link transmission in a wireless network
US11844106B2 (en) Low latency schemes for peer-to-peer (P2P) communications
US20230135332A1 (en) Method and device for direct communication in wireless lan system
EP4199636A1 (en) Method and wireless communication terminal for transmitting/receiving data in wireless communication system
US20240049304A1 (en) Wireless communication method using multi-link, and wireless communication terminal using same
KR20110020750A (ko) 고용량 무선 통신 시스템에서 통신 장치 및 방법
US11191093B2 (en) Method for wireless communication with wireless communication terminal for long range transmission and wireless communication terminal using same
KR20100011141A (ko) Vht 무선랜 시스템에서 데이터 전송 방법 및 이를지원하는 스테이션
EP3818759A1 (en) Direct link and downlink transmissions in trigger-based multi-user transmissions
WO2023228566A1 (ja) アクセスポイント、端末、及び通信方法
CN107509251B (zh) 一种退避方法和装置
WO2023107181A1 (en) Dynamic selection of parameters for enhanced quality of service (qos) and reliability
WO2022264571A1 (ja) アクセスポイント、端末、及び通信方法
WO2024004596A1 (ja) アクセスポイント、端末、及び通信方法
WO2024038905A1 (ja) 通信装置、及び通信方法
WO2023243568A1 (ja) アクセスポイント、端末、及び通信方法
WO2022249633A1 (ja) 端末、基地局、及び、通信方法
WO2023013254A1 (ja) 通信装置及び通信方法

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: 23811445

Country of ref document: EP

Kind code of ref document: A1