Terminals, base stations, and communication methods

JP7909518B2Active Publication Date: 2026-08-21PANASONIC INTELLECTUAL PROPERTY CORP OF AMERICA
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
JP2023524017
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Priority Date
2021-05-27
Filing Date
2022-03-08
Publication Date
2026-08-21
Estimated Expiration
2042-03-08

Smart Images

  • Figure 0007909518000001
    Figure 0007909518000001
  • Figure 0007909518000002
    Figure 0007909518000002
  • Figure 0007909518000003
    Figure 0007909518000003
Patent Text Reader

Abstract

This terminal comprises a reception circuit for receiving a control signal, and a control circuit for controlling, on the basis of the buffer status of data satisfying a predetermined requirement condition, a method for transmitting a response signal in response to the reception of the control signal.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present disclosure relates to a terminal, a base station, and a communication method.

Background Art

[0002] In the Institute of Electrical and Electronics Engineers (IEEE), the standard IEEE 802.11be (hereinafter also referred to as "11be") for the next-generation wireless local area network (LAN), which is a successor standard to the standard IEEE 802.11ax (hereinafter also referred to as "11ax"), is being studied. IEEE 802.11ax is also called High Efficiency (HE), and IEEE 802.be is also called Extreme High Throughput (EHT).

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Non-Patent Document 2

Non-Patent Document 3

Non-Patent Document 4

Non-Patent Document 5

Summary of the Invention

[0004] There is room for further consideration regarding the method for the base station to recognize the requirements for the data transmitted by the terminal. In this disclosure, the base station may be referred to as an access point (AP), and the terminal may be referred to as a station (STA) or a non-AP STA.

[0005] Non-limiting embodiments of this disclosure contribute to providing a terminal, a base station, and a communication method that enable the base station to recognize the requirements for data transmitted by the terminal.

[0006] A terminal according to one embodiment of the present disclosure includes a receiving circuit for receiving a control signal and a control circuit for controlling the method of transmitting a response signal to the reception of the control signal based on the buffer state of data that satisfies predetermined requirements.

[0007] These comprehensive or specific embodiments may be implemented as systems, devices, methods, integrated circuits, computer programs, or recording media, or as any combination of systems, devices, methods, integrated circuits, computer programs, and recording media.

[0008] According to one embodiment of this disclosure, the base station can recognize the requirements for the data transmitted by the terminal.

[0009] Further advantages and effects of one embodiment of this disclosure will be made apparent from the specification and drawings. Such advantages and / or effects are provided by several embodiments and features described in the specification and drawings, but not all of them are necessarily provided in order to obtain one or more identical features. [Brief explanation of the drawing]

[0010] [Figure 1] A diagram showing an example of a trigger frame. [Figure 2] A diagram showing an example of a Common Info field (EHT variant). [Figure 3]Figure showing an example of Trigger type [Figure 4] Figure showing an example of the User Info field of Null Data Packet (NDP) Feedback Report Poll (NFRP) [Figure 5] Figure showing an example of the Feedback Type subfield [Figure 6] Figure showing an example of the tone set index of Resource unit (RU) [Figure 7] Figure showing an example of Pmatrix [Figure 8] Block diagram showing an example of a partial configuration of an AP [Figure 9] Block diagram showing an example of a partial configuration of a terminal [Figure 10] Block diagram showing an example of the configuration of an AP according to Embodiment 1 [Figure 11] Block diagram showing an example of the configuration of a terminal according to Embodiment 1 [Figure 12] Figure showing an example of Traffic indicator (TID) [Figure 13] Figure showing an example of the User info field of NFRP according to Request delay control method 1 [Figure 14] Figure showing an example of the User info field (bitmap configuration) of NFRP according to Request delay control method 1 [Figure 15] Figure showing an example of the User info field of NFRP according to Request delay control method 2 [Figure 16] Figure showing an example of the User info field of NFRP according to Request delay control method 3 [Figure 17] Figure showing an example of Feedback type [Figure 18] Figure showing an example of Feedback type (when multiple are specified) [Figure 19] Figure showing an example of Special user info <A diagram showing an example of a Feedback type (details of a resource request). [Figure 21] A diagram showing an example of the comparison of bit positions between Special user info and user info. [Figure 22] A diagram showing an example of a buffer for each TID. [Figure 23] A diagram showing an example of the configuration of the NDP Feedback Report Parameter Set element. [Figure 24] A diagram showing an example of User info field. [Figure 25] A diagram showing an example of resource partitioning. [Figure 26] Block diagram showing an example configuration of AP according to Embodiment 2 [Figure 27] Block diagram showing an example of the terminal configuration according to Embodiment 2 [Figure 28] A diagram showing an example of Pmatrix (when the number of symbols is 2). [Figure 29] A diagram showing an example of Pmatrix (when the number of symbols is 4). [Figure 30] A diagram showing an example of Pmatrix (when the number of symbols is 6). [Figure 31] A diagram showing an example of a Pmatrix (a combination of other information). [Figure 32] A diagram showing an example of the tone position. [Figure 33] Diagram illustrating the Restricted Target Wakeup Time (TWT) control method. [Figure 34] A diagram showing an example of a Restricted TWT Traffic info field. [Figure 35] Block diagram showing an example of the terminal configuration according to Embodiment 3 [Figure 36] A diagram showing an example of a control sequence according to Embodiment 3. [Modes for carrying out the invention]

[0011] Each embodiment of this disclosure will be described in detail below with reference to the drawings.

[0012] 11ax(HE) specifies the introduction of uplink OFDMA (Orthogonal Frequency-Division Multiple Access). A base station (e.g., AP) sends a control signal (hereinafter referred to as a "trigger frame") that instructs the transmission of an uplink OFDMA signal to multiple terminals (e.g., STAs) that the AP accommodates.

[0013] In 11be(EHT), it has been agreed to reuse the 11ax(HE) trigger frame in the control signal that instructs multiple terminals to transmit uplink OFDMA signals (see, for example, Non-Patent Documents 1 and 3).

[0014] As shown in Figure 1, the trigger frame includes, for example, a Common Info field that contains information common to multiple terminals performing OFDMA multiplexing (which may be called terminal common information), and a User Info List consisting of multiple User Info fields that contain information unique to each terminal (terminal specific information) (see, for example, Non-Patent Documents 1, 2, and 3).

[0015] Figure 2 shows an example of a Common Info field (Common Info field, EHT variant) currently under consideration in EHT. The Trigger Type subfield of the Common Info field indicates the type of trigger frame (the type of signal that the AP sends to the terminal).

[0016] In 11ax, the types shown in Figure 3 (for example, value=0 to 7) are defined as Trigger Types (see, for example, Non-Patent Document 2). In Figure 3, values ​​8 to 15 are undefined (reserved). The Trigger Dependent Common Info subfield can also contain common information that depends on the Trigger type.

[0017] An STA supporting EHT can transmit a TB-PPDU (Trigger-Based Physical Protocol Data Unit), which is an example of a response signal for a trigger frame, in either HE or EHT format. An AP can instruct the STA on which format to transmit the TB-PPDU in, for example, using the trigger frame common info field.

[0018] When sending a trigger frame to an EHT terminal, for example, a Special user info field is provided in which a special AID (Association ID, e.g., AID=2007) is set in the User info field. In the Special user info field, common information between terminals is notified, such as uplink bandwidth information for the EHT (see, for example, Non-Patent Document 1).

[0019] If the value of the Trigger type subfield is 7 (NFRP), the format of the User info field will be as shown in Figure 4, for example (see Non-Patent Document 2, for example). Note that NFRP is an abbreviation for NDP Feedback Report Poll, and NDP is an abbreviation for Null Data Packet.

[0020] In Figure 4, the Feedback Type subfield can be set to values ​​such as those shown in Figure 5 (for example, value=0 to 15). If the value of the Feedback Type subfield is 0, it is used for resource requests. Values ​​of 1 to 15 are reserved.

[0021] In other words, the AP can be notified (or instructed) by the response signal of the trigger frame whether or not the terminal is holding data to be transmitted on the uplink. For example, from the AID indicated by the StartingAID subfield, StartingAID+N STA A terminal holding an AID between -1 sends an NDP as a response signal to the Trigger frame (NFRP). STA This is expressed by the following equation 1.

[0022] N STA = 18 × 2 BW ×(MultiplexingFlag+1) (1)

[0023] The BW value is indicated, for example, in the UL BW (bandwidth) subfield in the Common Info field shown in Figure 2, and can take values ​​of 0, 1, 2, or 3. For example, 0 corresponds to a bandwidth of 20 MHz, 1 to 40 MHz, 2 to 80 MHz, and 3 to 80 + 80 MHz or 160 MHz. The MultiplexingFlag is indicated, for example, in the User info field shown in Figure 4, and indicates whether multiplexing for multiple terminals is applied. For example, MultiplexingFlag=1 indicates that multiplexing for multiple terminals is applied.

[0024] A terminal transmitting an NDP will, for example, set FEEDBACK_STATUS=1 if it holds more data than the buffer threshold (also called the Resource request buffer threshold exponential) indicated by a signal such as a beacon, and set FEEDBACK_STATUS=0 if it does not hold any data, and will transmit an NDP with an HE or EHT LTF (Long Training Field) placed at the tone location (in other words, frequency resource) as exemplified in Figure 6.

[0025] For example, the terminal of the AID indicated by StartingAID will use the frequency resources of the candidate tone positions for RU_TONE_SET_INDEX=1 to transmit NDP. Similarly, the terminal of the AID indicated by StartingAID+1 will use the frequency resources of the candidate tone positions for RU_TONE_SET_INDEX=2 to transmit NDP.

[0026] If the MultiplexingFlag subfield (also called the Number of Spatially Multiplexed Users subfield) is 1, then, for example, one RU_TONE_SET_INDEX resource may be used (or shared) by two terminals. In this case, the NDP between terminals is orthogonalized by, for example, a Pmatrix multiplied by the HE or EHT LTF. Note that in HE, the number of symbols in HE-LTF is fixed at 2.

[0027] For example, as shown in Figure 7, Starting AID to Starting AID + 18 × 2 BW STA holding an AID of -1 multiplies the Pmatrix [1 -1] by HE-LTF, resulting in Starting AID + 18 × 2 BW Starting AID+18×2 BWSTA holding an AID of ×2-1 multiplies the Pmatrix of

[0011] by HE-LTF. [1 -1] and

[0011] are examples of mutually orthogonal sequences (patterns).

[0028] Furthermore, in 11be (EHT), improvements to TWT (Target Wakeup Time) and other measures are being considered to handle data with high request latency (also known as low latency traffic) (see, for example, Non-Patent Documents 4 and 5).

[0029] However, with Resource requests using NFRP, the AP cannot determine the request delay of the data that the terminal wants to send. Therefore, the AP cannot determine the resource allocation priority based on the request delay for terminals holding data they want to send uplink. Consequently, terminals holding data with high request delay (low latency traffic) may not be able to send their data within the allotted time.

[0030] In non-limiting embodiments of this disclosure, the AP can recognize terminals holding data with high request delay (in other words, low delay). This makes it possible, for example, to allocate resources for data transmission preferentially to such terminals, enabling the terminals to transmit data within an acceptable delay time corresponding to the request delay.

[0031] <Embodiment 1> <Configuration of the wireless communication system> The wireless communication system according to this embodiment may include, for example, an AP100 shown in Figure 8 and a terminal 200 shown in Figure 9. There may be two or more AP100s and terminals 200s in the wireless communication system.

[0032] AP100 may, for example, send a Trigger frame to terminal 200 instructing it to perform an uplink OFDMA transmission. Terminal 200 may receive the Trigger frame and use the resources indicated by the received Trigger frame to send an uplink OFDMA signal to AP100.

[0033] Here, AP100 can be, for example, an AP that supports EHT and is backward compatible with HE (for example, an AP that also supports HE).

[0034] Furthermore, terminal 200 may be either an HE terminal or an EHT terminal, for example. For example, AP100 may send a single trigger frame to multiple terminals 200 with different versions of the wireless LAN standard (e.g., either HE or EHT) and receive uplink OFDMA signals from each terminal 200. AP100 may, for example, separate and decode the uplink signals of the resources allocated to each terminal 200 from the received signals.

[0035] Figure 8 is a block diagram showing a partial configuration example of AP100 according to one embodiment of the present disclosure. In the AP100 shown in Figure 8, the control unit (or control circuit) 11 sets information regarding the request conditions (for example, TID, AC, or Discard age, which will be described later) in a control signal (for example, a trigger frame) that requests the terminal 200 to transmit a response signal. This information may be used, for example, to control (or determine) how the terminal 200 transmits the response signal based on the buffer state of the transmission data that satisfies predetermined request conditions. The transmission unit (or transmission circuit) 12 transmits the control signal to the terminal 200, for example. The request conditions may be, for example, request conditions regarding the delay of the data transmitted by the terminal 200 (hereinafter sometimes referred to as "request delay").

[0036] FIG. 9 is a block diagram showing a configuration example of a part of the terminal 200 according to an embodiment of the present disclosure. In the terminal 200 shown in FIG. 9, a receiving unit (or receiving circuit) 21 receives, for example, a control signal. A control unit (or control circuit) 22 controls (or determines), for example, a transmission method of a response signal (e.g., resource request or NDP) to the reception of the control signal based on a buffer state of data that satisfies a predetermined request condition (e.g., request delay).

[0037] In a non-limiting embodiment of the present disclosure, for example, a method for determining a holding state (e.g., FEEDBACK_STATUS = 0 or 1) of a buffer in which the terminal 200 responds (or feeds back) to the AP 100 by a resource request according to a request delay will be described.

[0038] <Configuration example of AP100> FIG. 10 is a block diagram showing a configuration example of the AP 100 according to the present embodiment. The AP 100 shown in FIG. 10 may include, for example, a scheduling unit 101, a request delay control unit 102, a Trigger frame generation unit 103, an error correction encoding unit 104, a modulation unit 105, a wireless transmission / reception unit 106, a demodulation unit 107, an error correction decoding unit 108, and a terminal information acquisition unit 109.

[0039] At least one of the scheduling unit 101, the request delay control unit 102, the Trigger frame generation unit 103, and the terminal information acquisition unit 109 may be included in, for example, an access control unit (e.g., Medium Access Control (MAC) processing unit).

[0040] Also, at least one of the scheduling unit 101, the request delay control unit 102, the Trigger frame generation unit 103, the error correction encoding unit 104, the modulation unit 105, the demodulation unit 107, the error correction decoding unit 108, and the terminal information acquisition unit 109 shown in FIG. 10 may be included in, for example, the control unit 11 shown in FIG. 8. Also, the wireless transmission / reception unit 106 shown in FIG. 10 may be included in, for example, the transmission unit 12 shown in FIG. 8.

[0041] The scheduling unit 101 determines, for example, the trigger type corresponding to the type of uplink response signal and the radio resources for the uplink response signal of each terminal (for example, allocated bandwidth, target reception level, etc.) based on terminal information output from the terminal information acquisition unit 109 (for example, the version of terminal 200, wireless quality information for each predetermined bandwidth, buffer information, etc.).

[0042] Furthermore, the scheduling unit 101, for example, when triggering NFRP, determines the Starting AID and multiplexing Flag (in other words, whether or not to multiplex the HE or EHT LTF of multiple terminals 200 by Pmatrix) of the STA that transmits the uplink response signal. The scheduling unit 101 outputs the determined trigger type and the radio resource information of each terminal 200 to the trigger frame generation unit 103.

[0043] The request delay control unit 102 determines, for example, the request delay of the data stored in the buffer that responds to a resource request. The request delay is controlled by, for example, a TID (Traffic Indicator). Details of the request delay will be described later. The request delay control unit 102 outputs the determined request delay information to the trigger frame generation unit 103.

[0044] The Trigger frame generation unit 103 generates a Common Info field using, for example, a Trigger type instruction from the scheduling unit 101. It also generates a User Info field using a predetermined format depending on the Trigger type. If the Trigger type is NFRP, the User Info field may include, for example, the Starting AID subfield and the multiplexing Flag subfield instructed by the scheduling unit 101.

[0045] Furthermore, the Trigger frame generation unit 103 generates a User Info field based on, for example, the request delay information input from the request delay control unit 102. Details of the User Info field will be described later. If the Trigger type is NFRP, the configuration may not include a Special user info field even if it is a Trigger frame for an EHT terminal. The Trigger frame generation unit 103 outputs the generated Trigger frame to the error correction encoding unit 104, for example.

[0046] The error correction coding unit 104, for example, takes a transmission data signal including a trigger frame as input, performs error correction coding on the input signal, and outputs the coded signal to the modulation unit 105.

[0047] The modulation unit 105, for example, applies modulation processing to the signal input from the error correction coding unit 104 and outputs the modulated data signal to the wireless transmission / reception unit 106.

[0048] Furthermore, if the modulated data signal is an orthogonal frequency division multiplexing (OFDM) signal, AP100 (for example, the modulation unit 105) may map the modulated signal to a predetermined frequency resource, perform an inverse fast Fourier transform (IFFT) to convert it into a time waveform, and add a cyclic prefix (CP) to form an OFDM signal.

[0049] The wireless transceiver 106 performs predetermined wireless transmission processing on the modulated signal output from the modulation unit 105, such as D / A conversion and upconversion to the carrier frequency, and transmits the processed signal to the terminal 200 via the antenna. The wireless transceiver 106 also receives the signal transmitted from the terminal 200 via the antenna, performs wireless reception processing on the received signal, such as downconversion to baseband and A / D conversion, and outputs the processed signal to the demodulation unit 107.

[0050] The demodulation unit 107 performs demodulation processing on the input signal from the wireless transceiver unit 106, for example, and outputs the resulting signal to the error correction decoding unit 108. If the input signal is an OFDM signal, the AP100 (for example, the demodulation unit 107) may perform CP rejection processing and Fast Fourier Transform (FFT) processing on the input signal.

[0051] The error correction decoding unit 108 decodes the signal input from the demodulation unit 107, for example, to obtain the received data signal from the terminal 200. If the decoded received data contains the terminal information described above, the error correction decoding unit 108 outputs the decoded data to the terminal information acquisition unit 109.

[0052] The terminal information acquisition unit 109 acquires terminal information (such as the terminal version and wireless quality information for each predetermined bandwidth) from the decoded data output from the error correction decoding unit 108, and outputs it to the scheduling unit 101. Furthermore, if the decoded data is an NFRP response signal (NDP), the terminal information acquisition unit 109 acquires terminal information (such as buffer information) from the tone position of the HE or EHT LTF, and outputs the terminal information to the scheduling unit 101.

[0053] <Example configuration of terminal 200> Figure 11 is a block diagram showing an example configuration of a terminal 200 according to this embodiment. The terminal 200 shown in Figure 11 may include, for example, a wireless transmission / reception unit 201, a demodulation unit 202, an error correction / decoding unit 203, a trigger frame acquisition unit 204, a request delay control unit 205, a buffer determination unit 206, a response signal generation unit 207, an error correction / coding unit 208, and a modulation unit 209.

[0054] At least one of the Trigger frame acquisition unit 204, the request delay control unit 205, the buffer determination unit 206, and the response signal generation unit 207 may be included in, for example, the access control unit (e.g., the MAC processing unit).

[0055] Furthermore, at least one of the demodulation unit 202, error correction decoding unit 203, trigger frame acquisition unit 204, request delay control unit 205, buffer determination unit 206, response signal generation unit 207, error correction coding unit 208, and modulation unit 209 shown in Figure 11 may be included in the control unit 22 shown in Figure 9, for example. Also, the wireless transmission / reception unit 201 shown in Figure 11 may be included in the receiving unit 21 shown in Figure 9, for example.

[0056] The wireless transceiver 201, for example, receives a received signal using an antenna, performs wireless reception processing on the received signal such as down-conversion and A / D conversion, and outputs the resulting received signal to the demodulation unit 202.

[0057] The demodulation unit 202 performs demodulation processing on the received data input from the wireless transceiver unit 201, for example, and outputs the demodulated signal to the error correction decoding unit 203. If the input signal is an OFDM signal, the terminal 200 (for example, the demodulation unit 202) may perform CP removal processing and FFT processing on the input signal, for example.

[0058] The error correction decoding unit 203, for example, decodes the demodulated signal input from the demodulation unit 202 and outputs the decoded signal as a received data signal. The error correction decoding unit 203 also outputs the trigger frame from the received data signal to the trigger frame acquisition unit 204.

[0059] The Trigger frame acquisition unit 204 extracts information from the Common Info field from the Trigger frame output from the error correction decoding unit 203, for example, and obtains terminal common information for generating an uplink signal, including the type of uplink response signal (for example, the type of data to be transmitted and the duration of the uplink signal).

[0060] Furthermore, the Trigger frame acquisition unit 204 extracts, for example, the User info List (e.g., User Info field) from the Trigger frame and performs reception processing of the User info field based on terminal common information (e.g., including Trigger type) obtained from the Common Info field. The Trigger frame acquisition unit 204 then obtains, for example, information used for generating a response signal from the Common Info and User info fields and outputs the obtained information to the response signal generation unit 207 and the request delay control unit 205.

[0061] The request delay control unit 205 acquires request delay information contained in the User info field (for example, information regarding the type of buffer to respond to a resource request) and outputs the acquired request delay information to the buffer determination unit 206. Request delay information is, for example, the TID.

[0062] If the User info field does not contain request delay information, it may be treated as if there is no request delay information. Alternatively, request delay information specified in the specifications, or request delay information notified to terminal 200 via a beacon, may be output to the buffer determination unit 206. Details of request delay information will be described later. "Notification" may be read as "Instruction".

[0063] The buffer determination unit 206 determines, for example, whether or not there is data in the buffer according to the request delay information. For example, if the request delay information is a TID, the buffer determination unit 206 determines, for example, whether the data of the specified TID is held in the buffer above a threshold (e.g., Resource request buffer threshold exponential), and outputs buffer holding information (FEEDBACK_STATUS) to the response signal generation unit 207.

[0064] The buffer threshold may be instructed to the terminal 200, for example, by an NDP Feedback Report Parameter Set element included in a signal such as a beacon. If the request delay control unit 205 does not notify the buffer determination unit 206 of the request delay information, the buffer determination unit 206 may determine the buffer retention information based on the total amount of data in the buffer, regardless of the request delay, for example, similar to the control in the case of HE. Details of the operation of the buffer determination unit 206 will be described later.

[0065] The response signal generation unit 207 generates data of a predetermined type and size based on, for example, terminal common information and terminal individual information from the trigger frame acquisition unit 204, and outputs it to the error correction encoding unit 208. If the trigger type is NFRP, the response signal generation unit 207 may check, for example, whether the AID held by terminal 200 is included in the AID instructed by the Starting AID.

[0066] If, upon verification, the instructed AID includes an AID held by terminal 200, the response signal generation unit 207 may, for example, generate an NDP including an LTF of HE or EHT based on buffer holding information (e.g., FEEDBACK_STATUS) input from the buffer determination unit 206.

[0067] Further, the response signal generation unit 207 multiplies the Pmatrix by the LTF of HE or EHT, for example, according to the MultiplexingFlag included in the terminal-specific information. Whether to generate the response signal using either the HE or EHT format may be notified to the terminal 200 by, for example, the Common info (or Common info and Special user info) of the Trigger frame. Also, when NFRP is instructed, the response signal may be generated in the HE format. The generated response signal is output to, for example, the error correction encoding unit 208.

[0068] The error correction encoding unit 208, for example, takes the response signal from the response signal generation unit 207 as input, and based on the terminal common information and terminal-specific information from the Trigger frame acquisition unit 204, error correction encodes the response signal which is the transmission data, and outputs the encoded signal to the modulation unit 209.

[0069] The modulation unit 209, for example, modulates the signal input from the error correction encoding unit 208, and based on the terminal common information and terminal-specific information from the Trigger frame acquisition unit 204, outputs the modulated signal to the wireless transceiver unit 201. When the modulated signal is an OFDM signal, the terminal 200 (for example, the modulation unit 209) may form an OFDM signal by mapping the modulated signal to a frequency resource and then performing IFFT processing and adding a CP.

[0070] The wireless transceiver unit 201 performs wireless transmission processing such as up-conversion and D / A conversion on the input signal from the modulation unit 209, and transmits the signal after the wireless transmission processing from the antenna.

[0071] <Operation examples of AP100 and terminal 200> Next, operation examples of the AP100 and terminal 200 according to the present embodiment will be described.

[0072] <Operation example of the request delay control unit 102(205)> First, as an example of the operation of the request delay control unit 102(205), request delay control methods 1 to 3 will be described. Any one of request delay control methods 1 to 3 may be applied to the request delay control unit 102(205).

[0073] By controlling the buffer state in which terminal 200 responds to AP100 in response to a resource request, based on request delay information (e.g., TID, AC (Access category), or Discard age), AP100 can recognize the request delay of the data held by terminal 200.

[0074] Therefore, AP100 can, for example, preferentially allocate resources to terminal 200 holding data with high request delay (also called low delay). This allows terminal 200 holding data with high request delay to transmit the data within the acceptable delay time using the preferentially allocated resources.

[0075] Furthermore, the control of the request delay is not limited to the TID, AC, and Discard age shown in each of the following request delay control methods 1 to 3. Other information representing the request delay may also be used.

[0076] <Request Delay Control Method 1> Request delay control may be performed, for example, by TID. TID is defined as shown in Figure 12, for example. In Figure 12, User Priority corresponds to TID. A TID greater than or equal to a predetermined value indicates a high request delay, and a TID less than the predetermined value indicates a low request delay. For example, if the predetermined value is 4, then TID=0, 1, 2, 3 indicates a low request delay, and TID=4, 5, 6, 7 indicates a high request delay.

[0077] Alternatively, a new value greater than 7 for TID could be introduced to indicate high request delay when TID is 7 or greater.

[0078] Control using TID allows for finer control of the request delay compared to control using AC, such as the request delay control method 2 described later.

[0079] <Request Delay Control Method 2> Request delay control may be performed, for example, by AC. There are four types of AC: AC_BK, AC_BE, AC_VI, and AC_VO. AC_BK represents AC for background traffic, AC_BE represents AC for best-effort traffic, AC_VI represents AC for video traffic, and AC_VO represents AC for voice traffic.

[0080] The request delay (in other words, priority) tends to increase in the order of AC_BK, AC_BE, AC_VI, and AC_VO. Therefore, for example, if AC_BK is 0, AC_BE is 1, AC_VI is 2, and AC_VO is 3, then a value of AC above a predetermined value indicates a high request delay, and a value of AC below a predetermined value indicates a low request delay.

[0081] For example, if the predetermined value is 2, then AC=0 (AC_BK) and AC=1 (AC_BE) can be considered to indicate low request delay, while AC=2 (AC_VI) and AC=3 (AC_VO) can be considered to indicate high request delay.

[0082] Alternatively, a new AC (Acceptance Code) could be introduced (for example, 4 or higher) to indicate a high request delay when the value is 4 or higher. Since AC tends to have fewer possible values ​​compared to TID, controlling the request delay using AC allows for control with fewer bits compared to control using TID. Therefore, it has the effect of reducing the amount of control information.

[0083] <Request Delay Control Method 3> The control of the required delay may be performed, for example, by the time until an MSDU (MAC Service Data Unit) is discarded (also called Discard Age).

[0084] For example, it may be assumed that when the Discard age is less than or equal to a predetermined value [ms], it indicates a high required delay, and when the Discard age is greater than the predetermined value [ms], it indicates a low required delay. For example, when the predetermined value is 200 ms, a Discard age in the range of 0 to 200 ms indicates a high required delay, and a Discard age greater than 200 ms indicates a low required delay.

[0085] According to the control of the required delay by the Discard age, the required delay can be controlled with fine granularity (on the order of ms) in units of MSDU.

[0086] <Operation example of Trigger frame generation unit 103> Next, an operation example of the Trigger frame generation unit 103 in the AP is described.

[0087] <Trigger frame generation method 1> The Trigger frame generation unit 103 may, for example, set 0 (Resource request), which is an existing value, for the Feedback Type subfield, and indicate the type of buffer to which the terminal 200 responds by the resource request in a part of the Reserved in the User info field of the Trigger frame.

[0088] Furthermore, since the HE terminal 200 discards the Reserved information in the User info field, it may generate a Resource request based on the total amount of data in the buffer, regardless of the request delay, similar to the operation in HE. In contrast, the EHT terminal 200 may generate a Resource request based on the amount of data of a specific type in the buffer, based on the value indicated by the User Info field.

[0089] Thus, Trigger frame generation method 1 can be applied even in environments where HE terminals 200 and EHT terminals 200 are mixed.

[0090] Next, regarding the request delay control methods 1 to 3 described in <Example of Operation of Request Delay Control Unit 205>, an example of the configuration of the User info field is shown.

[0091] <In the case of request delay control method 1> For example, as shown in Figure 13, the User info field may specify a TID (called Request TID). Note that Figure 13 shows an example where the Request TID is 4 bits, but it is not limited to this and may be 5 bits or more.

[0092] Furthermore, the Request TID can also be configured as a bitmap, as shown in Figure 14, for example. For instance, if the condition for a high request delay is TID ≥ 4, then the four bits of TID#0 to 3 can be set to 0, and the four bits of TID#4 to 7 can be set to 1.

[0093] <In the case of request delay control method 2> For example, as shown in Figure 15, the User info field may specify AC (referred to as Request AC). Note that Figure 15 shows an example where Request AC is 2 bits, but it is not limited to this and may be 3 bits or more.

[0094] <In the case of request delay control method 3> For example, as shown in FIG. 16, in the User info field, Discard age (referred to as Request Discard age) may be indicated. Note that FIG. 16 shows an example where Request Discard age is 9 bits, but it is not limited to this, and the remaining 7 bits of the Reserved subfield may be additionally used to make it 16 bits. The more the number of bits is increased, the more fine-grained Discard age indication becomes possible.

[0095] <Trigger frame generation method 2> In Trigger frame generation method 2, for example, as shown in FIG. 17, a new set value (for example, 1) is provided for the Feedback Type subfield. When the value of the Feedback Type subfield is 1, it is required (or instructed) to send a Resource request based on the buffer of data with a high request delay. When the value of the Feedback Type subfield is 0, regardless of the request delay, it is required to send a Resource request based on the buffer of all data.

[0096] Also, in Trigger frame generation method 2, similar to Trigger frame generation method 1, for example, the Reserved subfield of the User info field may be used to indicate the request delay information to terminal 200. If there is no indication, terminal 200 may respond with a resource request to AP100 based on, for example, the request delay conditions specified in the specification in advance, or the request delay information notified by a beacon or the like.

[0097] The Feedback Type subfield may be divided into multiple stages (or levels) depending on the level of request delay, as shown in Figure 18, for example. For example, a setting of 1 may request a Resource request based on a buffer of data with a request delay of "medium" or higher, and a setting of 2 may request a Resource request based on a buffer of data with a request delay of "high" or higher.

[0098] Additionally, a Feedback type can be added to the Special user info field (for example, by replacing part of the U-SIG Disregard And Validate subfield shown in Figure 19), and the combination of the Special user info field and the Trigger type in the User info field can be used to specify the detailed type of resource request.

[0099] For example, the Special user info field could be used to indicate that the Feedback type is for low latency, as shown in Figure 17, while the Feedback type in the User info field could be used to indicate the type of request delay (request delay = "high", "medium", etc.), as shown in Figure 20.

[0100] Furthermore, if a Resource request is required for data with high request latency, a new Trigger type may be created. For example, Trigger type=8 may be defined as NFRP (low latency), and Trigger frame generation method 1 or 2 may be applied when Trigger type=8.

[0101] Furthermore, while Trigger frame generation method 1 shows an example of specifying TID etc. using the Reserved field in User Info, it is also possible to use unused areas of the Common info field or Special user info field instead of the User info field to specify the information.

[0102] For example, since fields such as The UL STBC, LDPC Extra Symbol Segment, Pre-FEC Padding Factor, PE Disambiguity, UL Spatial Reuse, and Doppler subfields in the Common info field are unused in NFRP, some of these fields may be replaced with information that controls the request delay, such as TID.

[0103] Alternatively, all information in the User info field (e.g., Starting AID, feedback Type, etc.) may be specified by the Special user info field. For example, the Starting AID, feedback Type, etc., may be specified by unused areas such as the Reserved subfield of the Special user info field, or by the Trigger dependent user info subfield.

[0104] Furthermore, the Multiplexing Flag and other parameters may be indicated by the feedback type. For example, Feedback type=0 may indicate a resource request when Multiplexing Flag=0, and Feedback type=1 may indicate a resource request when Multiplexing Flag=1. In this case, NFRP has a Special user info field, but no user info field. By consolidating the instruction information in NFRP into the Special user info field in this way, the amount of control information can be reduced.

[0105] Since HE terminals do not recognize the NFRP format for EHT terminals, they may, for example, mistakenly identify the Special Reuse 2 subfield, located at the bit position (Bits 21-24) corresponding to the Feedback type subfield of the User info field in the Special user info field, as the feedback type, as shown in Figure 21.

[0106] Therefore, when sending NFRP to an EHT terminal, set the Special Reuse 2 subfield of the Special user info field to a value other than one specified in the HE Feedback Type, such as 0 (which means PSR_DISALLOW in Special Reuse 2). For example, by fixing the value of the Special Reuse 2 subfield to 15 (which means PSR_AND_NON_SRG_OBSS_PD_PROHIBITED in Special Reuse 2), Special reuse is prohibited in NFRP. This prevents the HE terminal from misinterpreting the Special user info field and mistakenly sending an NFRP response signal.

[0107] <Example of operation of buffer determination unit 206> Next, an example of the operation of the buffer determination unit 206 in terminal 200 will be described. The buffer determination unit 206 determines, for example, whether or not there is data in the buffer based on the request delay information notified from AP100 by a trigger frame.

[0108] For example, if the request delay information included in the trigger frame is a TID (in other words, in the case of request delay control method 1), it is determined whether the total amount of data equal to or greater than the specified TID (or, in the case of bitmap notification, a TID with a target bit of 1) is equal to or greater than the buffer threshold (Resource request buffer threshold exponential) indicated by an NDP Feedback Report Parameter Set element such as a beacon, and the buffer retention information (FEEDBACK_STATUS) is determined.

[0109] Figure 22 shows an example of a buffer for each TID. A data buffer exists for each TID from 0 to 7, and the amount of data held by each TID is represented, for example, by Xn (n=0 to 7). For example, if the TID indicated by the trigger frame is 4, the total amount of data accumulated in the buffers for TIDs 4 to 7 is (=X4+X5+X6+X7)[byte(s)] and the threshold is 2 Resource Request Buffer Threshold Exponent The value is compared with [byte(s)]. If the total amount of data is greater than the threshold, FEEDBACK_STATUS=1. Otherwise, FEEDBACK_STATUS=0.

[0110] Similarly, in cases where the request delay information is AC or Discard age, the buffer determination unit 206 manages the buffer at intervals until AC or MSDU is discarded, and calculates the total amount of data according to the value indicated by the Trigger frame.

[0111] In terminal 200, which supports HE but not EHT, the total amount of data can be calculated regardless of the requested delay information. For example, in the example in Figure 22, the total amount of data is X0+X1+X2+X3+X4+X5+X6+X7[byte(s)].

[0112] Multiple buffer thresholds may be notified. For example, as shown in Figure 23, the buffer threshold when request delay is not considered and the buffer threshold when request delay is considered (for example, the buffer threshold for data with high request delay) may be notified to the terminal 200 separately.

[0113] If, for example, a TID is notified as request delay information, the buffer determination unit 206 uses the buffer threshold indicated by Resource request buffer threshold exponential (Low latency) to determine whether or not there is a buffer for data with a high request delay (in other words, a TID or higher).

[0114] By notifying multiple buffer thresholds according to the request delay, the buffer threshold can be flexibly controlled according to the request delay. For example, if the data has a high request delay, the buffer threshold value can be reduced, allowing AP100 to request a resource request (in other words, resource allocation by scheduling) with minimal delay as long as any data is held. This allows resource allocation to terminal 200 to be expedited, enabling terminal 200 to start sending data with a high request delay earlier.

[0115] <Supplement to Embodiment 1> Furthermore, the frequency resources (e.g., tone positions) used may be separated (or, in other words, made different) for resource requests based on the total amount of data, or the total amount of data with low request delay, and for resource requests based on the total amount of data with high request delay.

[0116] For example, the Reserved subfield of the User info field is used to specify the resource location (called Starting RU_TONE_SET_INDEX) for resource requests (referred to as resource requests (low latency)) of data with high request latency.

[0117] Figure 24 shows an example of the configuration of the User info field. Figure 25 also shows an example where Starting RU_TONE_SET_INDEX=9 (BW=20MHz).

[0118] RU_TONE_SET_INDEX=1~8 corresponds to resource requests based on the total amount of data or the total amount of data with low request latency, while RU_TONE_SET_INDEX=9~18 corresponds to resource requests for data with high request latency.

[0119] In this case, STA200s in the range of StartingAID to StartingAID+8 will use resources RU_TONE_SET_INDEX=1 to 8 and RU_TONE_SET_INDEX=9 to 18 to send resource requests. For example, an STA200 will send a resource request based on the total amount of data or the total amount of data with low request delay using one of the resources RU_TONE_SET_INDEX=1 to 8, and will send a resource request for data with high request delay using one of the resources RU_TONE_SET_INDEX=9 to 18.

[0120] The configuration can involve sending resource requests using two resources, or it can use only one of the resources (for example, the resource for resource requests (low latency) if it holds data with high request latency).

[0121] As described above, by dividing resources into a resource request based on the total amount of all data or the total amount of data with low request latency, and a resource request based on the total amount of data with high request latency, AP100 can determine whether the terminal 200 holds data with low request latency or data with high request latency.

[0122] Therefore, AP100 can change the scheduling priority of the terminal 200 according to the determined request latency, making it easier to schedule the terminal 200 within the request latency.

[0123] Note that the resources of the resource request (for example, the range of RU_TONE_SET_INDEX) may be divided into multiple levels (or levels) according to, for example, the high or low request latency. For example, the range of RU_TONE_SET_INDEX may be divided for each of the "high", "medium", and "low" request latencies, and the resource position (for example, Starting RU_TONE_SET_INDEX) for each level of request latency may be indicated in the Reserved subfield of the User info field.

[0124] <Embodiment 2> In Embodiment 1, a method for determining the holding state (for example, FEEDBACK_STATUS = 0 or 1) of a buffer that responds by a resource request according to a request latency based on the control information notified by a Trigger frame in the terminal 200 was described. In this Embodiment 2, a method for changing the NDP transmission method according to the request latency of the data accumulated in the buffer held by the terminal 200 without being instructed by a Trigger frame from AP100 will be described.

[0125] <Configuration example of AP100> Figure 26 is a block diagram showing an example configuration of AP100 according to Embodiment 2. Compared to Embodiment 1 (Figure 10), the AP100 illustrated in Figure 26 does not require a request delay control unit 102, and the operation of the Trigger frame generation unit 103A is different. Other configurations and operations may be the same as in Embodiment 1.

[0126] The Trigger frame generation unit 103A generates a Common Info field, for example, using a Trigger type instruction from the scheduling unit 101. The Trigger frame generation unit 103A also generates a User Info field using a predetermined format, for example, according to the Trigger type.

[0127] If the trigger type is NFRP, the User Info field may include the Starting AID subfield and multiplexing Flag subfield instructed by the scheduling unit 101. The configuration of the User Info field may be the same as, for example, the User Info field of HE. The trigger frame generation unit 103A outputs the generated trigger frame to the error correction encoding unit 104, for example.

[0128] <Example configuration of terminal 200> Figure 27 is a block diagram showing an example configuration of terminal 200 according to Embodiment 2. The terminal 200 illustrated in Figure 27 differs from that of Embodiment 1 (Figure 11) in the operation of the request delay control unit 205A and the response signal generation unit 207A. Other configurations and processes may be the same as in Embodiment 1.

[0129] The request delay control unit 205A may determine, for example, whether the data has a high request delay based on the TID, AC, or Discard age described in Embodiment 1. The criteria for determining the request delay may be specified in the specifications, for example, or notified by control information such as a beacon or trigger frame. The request delay control unit 205A outputs the request delay information to the buffer determination unit 206 and the response signal generation unit 207A, for example.

[0130] Furthermore, request delay information may be omitted, meaning that a response signal is generated regardless of the request delay, similar to HE. The decision to omit request delay information may also be communicated via control information such as beacons or trigger frames. Additionally, the control method may be changed depending on the capabilities of terminal 200. For example, terminal 200 that does not support request delay control may be configured to omit request delay information.

[0131] The response signal generation unit 207A generates data of a predetermined type and size based on terminal common information and terminal individual information from the trigger frame acquisition unit 204, for example, and outputs it to the error correction encoding unit 208.

[0132] If the trigger type is NFRP, the response signal generation unit 207A checks whether the AID indicated by, for example, the Starting AID, includes an AID held by the terminal 200. If the indicated AID includes an AID held by the terminal 200, the response signal generation unit 207A generates an NDP including an HE or EHT LTF based on, for example, buffer holding information (e.g., FEEDBACK_STATUS) input from the buffer determination unit 206.

[0133] Also, the response signal generation unit 207A multiplies the Pmatrix by the LTF of HE or EHT, for example, according to the Multiplexing Flag included in the terminal-specific information. Here, the response signal generation unit 207A controls the tone position (or, in other words, the frequency mapping position) of the LTF of HE or EHT included in the NDP or the Pmatrix to be multiplied, for example, according to the request delay information input from the request delay control unit 205. Details of the response signal generation unit 207A will be described later.

[0134] Note that which format of HE and EHT is used to generate the response signal may be indicated by, for example, the Common info of the Trigger frame (or, the Common info and Special user info of the Trigger frame). Also, when NFRP is indicated, the response signal generation unit 207A may be configured to generate the response signal using, for example, the HE format. The generated response signal is output to, for example, the error correction coding unit 208.

[0135] <Operation example of response signal generation unit 207A> Next, an operation example of the response signal generation unit 207A will be described. The response signal generation unit 207A may change the NDP generation method, for example, according to the request delay information input from the request delay control unit 205A.

[0136] <NDP generation method 1> NDP generation method 1 is a method of notifying the AP100 whether the request delay of the data held by the terminal 200 is high or not, according to the pattern of the Pmatrix multiplied by the LTF of HE or EHT of the NDP.

[0137] The AP100 performs reception processing using, for example, a plurality of Pmatrix patterns, and determines whether the request delay of the data held by the terminal 200 is high or not, from the pattern of the Pmatrix for which signal detection has succeeded. Note that in HE, the number of symbols of the HE-LTF of the NDP, which is an example of the response signal of NFRP, is fixed to 2.

[0138] Therefore, in the NDP generation method 1, the number of symbols may be fixed at 2, or alternatively, the number of HE / EHT-LTF symbols of the NDP may be changed according to the value of the Number Of EHT-LTF Symbols And Midamble Periodicity subfield included in the common info of the Trigger frame. Details of the Pmatrix for each symbol number will be described later. Also, "HE / EHT-LTF" means the LTF of HE or EHT.

[0139] In this way, by notifying the AP100 of the required delay of the data held by the terminal 200 according to the pattern of the Pmatrix, the AP100 can recognize the required delay of the data held by the terminal 200.

[0140] Therefore, the AP100 can preferentially allocate resources to the terminal 200 holding data with a high required delay (also called low latency), for example. As a result, the terminal 200 holding data with a high required delay can transmit the data within the allowable delay time using the preferentially allocated resources.

[0141] <Specific example when the number of HE / EHT-LTF symbols is 2> When the Multiplexing Flag = 0 included in the User Info, if the terminal 200 holds data with a low required delay (or all data for which the required delay does not need to be considered), the response signal generation unit 207A may make the Pmatrix multiplied by the HE / EHT-LTF of the NDP, which is an example of the response signal of the NFRP, different from the pattern of the Pmatrix multiplied by the HE / EHT-LTF when holding data with a high required delay (in other words, the pattern of the orthogonal sequence).

[0142] For example, as shown in FIG. 28, when the terminal 200 holds data with a low required delay (or all data for which the required delay does not need to be considered), the response signal generation unit 207A may multiply the Pmatrix of [1 -1] by the HE / EHT-LTF, and when the terminal 200 holds data with a high required delay, may multiply the Pmatrix of

[0011] by the HE / EHT-LTF.

[0143] When the number of symbols is 2, control is possible even when HE terminals and EHT terminals are mixed. For example, when the Multiplexing Flag = 0, the HE terminal 200 uses the Pmatrix of [1 -1] among the two Pmatrices of [1 -1] and

[0011] , and the EHT terminal 200 may switch between the Pmatrix of [1 -1] and the Pmatrix of

[0011] and use them according to the required delay of the data it holds.

[0144] Note that it may also be possible to use the Pmatrix of

[0011] for data with a low required delay (or all data for which the required delay does not need to be considered), and use the Pmatrix of [1 -1] for data with a high required delay.

[0145] <Specific example when the number of HE / EHT-LTF symbols is 4> When the terminal 200 holds data with a low required delay (or all data for which the required delay does not need to be considered), the response signal generation unit 207A may vary the Pmatrix multiplied by the HE / EHT-LTF of the NDP, which is an example of the response signal of the NFRP, and the pattern of the Pmatrix multiplied by the HE / EHT-LTF when holding data with a high required delay.

[0146] For example, as shown in FIG. 29, when the response signal generation unit 207A holds data with a low request delay (or all data for which the request delay does not need to be considered), it may multiply the Pmatrix of [1 -1 1 1] or [1 1 -1 1] by the HE / EHT-LTF. When it holds data with a high request delay, it may multiply the Pmatrix of [1 1 1 -1] or [-1 1 1 1] by the HE / EHT-LTF.

[0147] Alternatively, when the response signal generation unit 207A holds data with a low request delay (or all data for which the request delay does not need to be considered), it may multiply the Pmatrix of [1 1 1 -1] or [-1 1 1 1] by the HE / EHT-LTF. When it holds data with a high request delay, it may multiply the Pmatrix of [1 -1 1 1] or [1 1 -1 1] by the HE / EHT-LTF.

[0148] In addition, when the number of symbols is more than 4 symbols, as shown in FIG. 30 for example, a plurality of types of request delays may be provided (for example, the request delay is "low", "medium", "high", etc.).

[0149] Also, in addition to the request delay, the pattern of the Pmatrix may be made different in combination with other information. For example, as shown in FIG. 31, the pattern of the Pmatrix may be made different according to the request delay and the data size stored in the buffer. Also, which information each Pmatrix pattern is associated with may be indicated to the terminal 200 by the Common info or the User info field.

[0150] <NDP Generation Method 2> The NDP generation method 2 is, for example, a method by which the terminal 200 notifies the AP100 whether the request delay of the data held by the terminal 200 is high or not based on the tone (frequency) position where the HE / EHT-LTF of the NDP is mapped.

[0151] For example, AP100 can perform reception processing at multiple HE / EHT-LTF tone locations and determine whether the data held by terminal 200 has a high request delay based on the tone location where a signal is successfully detected.

[0152] Figure 32 shows an example of the tone position for HE / EHT-LTF. Note that Figure 32 illustrates the tone position for HE / EHT-LTF for RU_TONE_SET_INDEX=1 and 2, and omits the illustration of the tone position for HE / EHT-LTF for other RU_TONE_SET_INDEX values.

[0153] If terminal 200 is holding data with low request delay (or all data for which request delay does not need to be considered), and there is data to be sent (for example, FEEDBACK_STATUS=1), then terminal 200, for example, when instructed to RU_TONE_SET_INDEX=1, will send HE / EHT-LTF at tone positions -113, -41, and 42.

[0154] On the other hand, if there is no data to send (for example, FEEDBACK_STATUS=0), terminal 200, which is instructed to RU_TONE_SET_INDEX=1, will send HE / EHT-LTF at tone positions -112, -40, 41, for example.

[0155] Similarly, for terminal 200, which is instructed to use RU_TONE_SET_INDEX=2, HE / EHT-LTF will be sent at different tone positions depending on whether it is holding data with low request delay (or all data for which request delay does not need to be considered) or whether it is not holding data to be sent.

[0156] In contrast, if terminal 200 is holding data with a high request delay and there is data to be sent (for example, FEEDBACK_STATUS=1), terminal 200, which has been instructed to RU_TONE_SET_INDEX=1, will send HE / EHT-LTF at tone positions -77, -6, and 78, for example.

[0157] On the other hand, if there is no data to send (for example, FEEDBACK_STATUS=0), terminal 200, which is instructed to RU_TONE_SET_INDEX=1, will send HE / EHT-LTF at tone positions -76, 7, and 79, for example.

[0158] Similarly, for terminal 200, which is instructed to use RU_TONE_SET_INDEX=2, it may send HE / EHT-LTF at different tone positions depending on whether it is holding data with a high requested delay or not holding data to be transmitted.

[0159] In this way, by implicitly notifying AP100 of the data request delay held by terminal 200 through the tone (frequency) position to which HE / EHT-LTF is mapped, AP100 can recognize the data request delay held by terminal 200.

[0160] Therefore, AP100 can, for example, prioritize allocating resources to terminal 200 holding data with high request delays, thereby enabling terminal 200 to transmit data within the acceptable delay time.

[0161] Furthermore, if terminal 200 holds both high-latency and low-latency data, terminal 200 may send HE / EHT-LTF at both resources, for example, at tone positions -113, -41, 42, -77, -6, 78.

[0162] Furthermore, when FEEDBACK_STATUS=0, the resources for data with low request delay (or all data where request delay does not need to be considered) and the resources for data with high request delay may be the same. In this case, terminal 200 may, for example, allocate the FEEDBACK_STATUS=0 tone for data with high request delay to another device. Since there is no data to send, for FEEDBACK_STATUS=0, it is not necessary to separate the resources for sending HE / EHT-LTF for data with high request delay and data with low request delay.

[0163] Furthermore, the candidate set of tone positions used for HE / EHT-LTF transmission may be divided into multiple stages (or levels), for example, depending on the high or low request delay. For example, a set of candidate tone positions may be defined for each of the "high," "medium," and "low" request delays.

[0164] <Embodiment 3> Embodiment 3 describes a method for switching between a Resource request for data with low request delay (or all data for which request delay does not need to be considered) and a Resource request for data with high request delay, depending on the timing of transmitting the NFRP response signal. One non-restrictive example of timing is timing based on TWT (Target Wakeup Time).

[0165] The TWT allows the AP100 to control the wake / doze state of terminal 200 in order to reduce power consumption of terminal 200 and resource conflicts between terminals 200 (see, for example, Non-Patent Document 2). The time interval during which terminal 200 wakes up due to TWT control is called the TWT service period (SP).

[0166] In EHT, Restricted TWT is considered in view of services for low latency (or high required latency) (see, for example, Non-Patent Documents 4 and 5). In the Restricted TWT SP, there are restrictions such that it is permitted only for transmitting data for low latency.

[0167] For example, in the Restricted TWT Traffic info field in the beacon shown in FIG. 34, information on low latency (high required latency) data is indicated. For this indication, for example, a bitmap format is used, and 1 is set for the low latency (high required latency) TID.

[0168] The control method of Restricted TWT is currently under discussion, but it may be indicated that it is Restricted TWT by Option b in FIG. 33, for example, by the Broadcast TWT Recommendation subfield in the Broadcast TWT Parameter Set field included in the beacon. For example, Restricted TWT is indicated by Val = 4.

[0169] <Configuration of AP100> The configuration example of the AP100 according to Embodiment 3 may be the same as that of Embodiment 2.

[0170] <Configuration of Terminal 200> FIG. 35 is a block diagram showing a configuration example of the terminal 200 according to Embodiment 3. Compared with the configuration of Embodiment 2 (FIG. 27), a timing determination unit 210 is added, and the operation of the required latency control unit 205B is different. The operation of the response signal generation unit 207 may be the same as that of Embodiment 1. Other configurations and operations may be the same as those of Embodiment 2.

[0171] The timing determination unit 210 determines, for example, whether the timing for transmitting the response signal of the NFRP is within the Restricted TWT Service period, and outputs the determination result to the required latency control unit 205B. An example of a detailed sequence will be described later.

[0172] The request delay control unit 205B differentiates the request delay information depending on the determination result input from the timing determination unit 210 (for example, whether or not the timing for transmitting the response signal is within the Restricted TWT Service period).

[0173] Whether or not data has a high request delay can be determined by parameters such as TID, AC, or Discard age as described in Embodiment 1. The criteria for determining the request delay may be specified in the specifications, or it may be instructed to the terminal 200 by control information such as beacons or trigger frames.

[0174] For example, if the determination result input from the timing determination unit 210 indicates that the timing for transmitting the response signal is within the Restricted TWT Service period, the request delay control unit 205B outputs, for example, request delay information with a high request delay (e.g., TID=4, 5, 6, 7) to the buffer determination unit 206.

[0175] The request delay information may be controlled based on the TID indicated by the Restricted TWT UL TID Bitmap in the Restricted TWT Traffic info field.

[0176] If the determination result input from the timing determination unit 210 indicates that the timing for transmitting the response signal is not within the Restricted TWT Service period, or is within the TWT service period, the request delay control unit 205B outputs to the buffer determination unit 206, for example, that there is no request delay information. In this case, the buffer determination unit 206 calculates the buffer size regardless of the request delay, for example, similar to HE.

[0177] <Example of control sequence> Figure 36 shows an example of a control sequence.

[0178] For example, if the value of the Broadcast TWT Recommendation subfield in the Broadcast TWT Parameter Set field of the beacon is not a Restricted TWT (for example, if val=0, 1, 2, or 3), AP100 will request a resource request from terminal (STA)200 via a Trigger frame (NFRP) at the TWT SP indicated by the beacon (S361). Note that the time interval of the TWT SP is an example of the first wake-up time.

[0179] For example, when transmitting an NDP, which is an example of a response signal, the STA200, in the TWT SP section, similar to the operation of HE, regardless of the requested delay, sends an NDP at the corresponding tone position if the held data is above a threshold, and if it is below the threshold, it sets BUFFER_STATUS=1 (S362).

[0180] Subsequently, AP100 recognizes, for example, the data retention status of STA200 from the response signal and sends a Trigger frame (basic) to STA200 that is holding the data (S363).

[0181] STA200 transmits data via a response signal (TB-PPDU) (S364), and AP100 returns an ACK to STA200 indicating whether the data was received correctly (S365).

[0182] On the other hand, if the value of the Broadcast TWT Recommendation subfield in the Broadcast TWT Parameter Set field of the beacon is Restricted TWT (for example, val=4), AP100 will request a resource request from STA200 via a Trigger frame (NFRP) for, for example, the Restricted TWT SP indicated by the beacon (S371).

[0183] Note that the time interval of the Restricted TWT SP is an example of a second wake-up time in which data transmission is restricted in accordance with the requested delay relative to the first wake-up time. The order of the TWT SP (first wake-up time) and the Restricted TWT SP (second wake-up time) may be reversed. In some cases, the TWT SP may be instructed after the Restricted TWT SP has been instructed.

[0184] For example, when transmitting an NDP, which is an example of a response signal, the STA200, in a Restricted TWT SP section, sends an NDP at the corresponding tone position if the held data with a high requested delay (e.g., TID=4, 5, 6, 7) is above a threshold, and if it is below the threshold, it sends an NDP (S372).

[0185] Subsequently, AP100 recognizes, for example, the data retention status of STA200 from the response signal and sends a Trigger frame (basic) to STA200 that is holding the data (S373).

[0186] STA200 transmits data via a response signal (TB-PPDU) (S374), and AP100 returns an ACK to STA200 indicating whether the data was received correctly (S375).

[0187] In this way, the request delay information differs depending on whether the timing of the response signal transmission by terminal 200 is within the Restricted TWT SP, allowing AP100 to be notified of the request delay of the data held by terminal 200.

[0188] Therefore, AP100 can recognize the request delay of the data held by terminal 200 and, for example, can preferentially allocate resources to terminal 200 that is holding data with a high request delay. Thus, terminal 200 can transmit the data within the acceptable delay time.

[0189] <Supplementary information for the whole> Embodiments 1, 2, and 3 may be used in combination of two or more. For example, Embodiment 1 and Embodiment 3 may be combined to control the buffer retention information (FEEDBACK_STATUS) based on the request delay information indicated by the User info field of the Trigger frame during the Restricted TWT SP period, and control the buffer retention information (FEEDBACK_STATUS) regardless of the request delay, similar to HE, when it is not the Restricted TWT Service period or is the TWT service period.

[0190] Furthermore, for example, by combining Embodiment 2 and Embodiment 3, the NDP generation method may be changed according to the request delay when it is a Restricted TWT SP period, and when it is not a Restricted TWT Service period period, or when it is a TWT service period period, the NDP may be generated regardless of the request delay, similar to HE.

[0191] The transmission access method for the uplink response signal to the trigger frame is not limited to OFDMA, but may be other methods.

[0192] Furthermore, while Embodiments 1 to 3 were described based on the 11be format as a non-limiting example, the format to which one embodiment of this disclosure is applied is not limited to the 11be format. One embodiment of this disclosure may, for example, be applied to the next-generation standard of the automotive standard IEEE 802.11p, IEEE 802.11bd (NGV (Next Generation V2X)).

[0193] Information indicating whether the terminal 200 supports the functions, operations, or processes described in each of the embodiments, modifications, and supplements described above may be transmitted (or notified or instructed) from the terminal 200 to the base station 100 as, for example, capability information or capability parameters of the terminal 200.

[0194] The capability information may include an information element (IE) that individually indicates whether the terminal 200 supports at least one of the functions, operations, or processes described in each of the embodiments, modifications, and supplements described above. Alternatively, the capability information may include an information element that indicates whether the terminal 200 supports any two or more combinations of the functions, operations, or processes described in each of the embodiments, modifications, and supplements described above.

[0195] The base station 100 may, for example, determine (or decide or assume) which functions, operations, or processes the source terminal 200 supports (or does not support) based on the capability information received from the terminal 200. The base station 100 may perform operations, processes, or controls in accordance with the determination result based on the capability information. For example, the base station 100 may control at least one of the functions, operations, or processes described in each embodiment, each modification, and each supplement described above based on the capability information received from the terminal 200.

[0196] The fact that terminal 200 does not support some of the functions, operations, or processes described in each embodiment, each modification, and each supplement described above may be interpreted as the terminal 200 having restrictions on such some functions, operations, or processes. For example, information or requests regarding such restrictions may be notified to base station 100.

[0197] Information regarding the capabilities or limitations of terminal 200 may be defined, for example, in a standard, or it may be implicitly communicated to base station 100 in association with information known at base station 100 or information transmitted to base station 100.

[0198] This disclosure can be implemented in software, hardware, or software in conjunction with hardware. Each functional block used in the description of the above embodiments may be implemented in part or in whole as an integrated circuit (LSI), and each process described in the above embodiments may be controlled in part or in whole by a single LSI or a combination of LSIs. An LSI may consist of individual chips, or it may consist of a single chip that includes some or all of the functional blocks. An LSI may have data inputs and outputs. Depending on the degree of integration, LSIs may be referred to as ICs, system LSIs, super LSIs, or ultra LSIs.

[0199] The method of integration is not limited to LSIs; it may also be implemented using dedicated circuits, general-purpose processors, or dedicated processors. Furthermore, FPGAs (Field Programmable Gate Arrays) that can be programmed after LSI manufacturing, or reconfigurable processors that allow for the reconfiguration of the connections and settings of circuit cells within the LSI, may also be used. This disclosure may be implemented as digital or analog processing.

[0200] Furthermore, if advancements in semiconductor technology or other derived technologies lead to the emergence of integrated circuit technologies that replace LSIs, then naturally, it would be possible to use those technologies to integrate functional blocks. The application of biotechnology, for example, is a possibility.

[0201] This disclosure is applicable to all types of devices, systems, and equipment having communication capabilities (collectively referred to as communication equipment). Communication equipment may include a radio transceiver and a processing / control circuit. A radio transceiver may include a receiver and a transmitter, or both as functions. A radio transceiver (transmitter, receiver) may include an RF (Radio Frequency) module and one or more antennas. The RF module may include an amplifier, an RF modulator / demodulator, or similar. Non-exclusive examples of communication devices include telephones (mobile phones, smartphones, etc.), tablets, personal computers (PCs) (laptops, desktops, notebooks, etc.), cameras (digital still / video cameras, etc.), digital players (digital audio / video players, etc.), wearable devices (wearable cameras, smartwatches, tracking devices, etc.), game consoles, digital book readers, telehealth / telemedicine devices, vehicles or mobile transport with communication capabilities (cars, airplanes, ships, etc.), and combinations of the above-mentioned devices.

[0202] Communication devices are not limited to portable or movable devices, but also include all kinds of non-portable or fixed devices, devices, and systems, such as smart home devices (appliances, lighting equipment, smart meters or measuring instruments, control panels, etc.), vending machines, and any other "things" that may exist on an IoT (Internet of Things) network.

[0203] Communication includes data communication via cellular systems, wireless LAN systems, and communication satellite systems, as well as data communication using combinations of these.

[0204] Furthermore, the communication device also includes devices such as controllers and sensors that are connected to or linked to a communication device that performs the communication functions described in this disclosure. For example, this includes controllers and sensors that generate control signals and data signals used by the communication device that performs the communication functions of the communication device.

[0205] Furthermore, communication equipment includes infrastructure facilities such as base stations, access points, and any other devices, devices, and systems that communicate with or control the aforementioned non-limited types of equipment.

[0206] A terminal according to one embodiment of the present disclosure may include a receiving circuit for receiving a control signal and a control circuit for controlling the method of transmitting a response signal to the reception of the control signal based on a buffer state of data that satisfies predetermined requirements.

[0207] In a terminal according to one embodiment of the present disclosure, the requirements may be requirements relating to the delay of the data.

[0208] In a terminal according to one embodiment of the present disclosure, the requirements may be based on a traffic indicator, an access category, or the time until the data is discarded.

[0209] In a terminal according to one embodiment of the present disclosure, the requirements may be indicated in the user information field of the control signal.

[0210] In a terminal according to one embodiment of the present disclosure, the control circuit may use different frequency resources for transmitting the response signal between the transmission data with high requirements and the transmission data with low requirements.

[0211] In a terminal according to one embodiment of the present disclosure, the user information field may indicate the location of the frequency resource for the transmission data with high requirements.

[0212] In a terminal according to one embodiment of the present disclosure, the presence or absence or high level of the requirement may be indicated by the value of the feedback type subfield in the user information field of the control signal.

[0213] In a terminal according to one embodiment of the present disclosure, the control circuit may indicate the requirements for the data held in the buffer in the response signal by an orthogonal sequence pattern applied to the training signal of the response signal.

[0214] In a terminal according to one embodiment of the present disclosure, the control circuit may indicate the requirement in the response signal when the number of symbols in the training signal is 2 and the value of the multiple flag subfield of the control signal is 0.

[0215] In a terminal according to one embodiment of the present disclosure, the control circuit may indicate the requirements for the data held in the buffer by the frequency resource that transmits the response signal.

[0216] In a terminal according to one embodiment of the present disclosure, if the control circuit receives the control signal within a second wake-up time in which data transmission is restricted according to the requirements with respect to a first wake-up time, the control circuit may indicate in the response signal that the buffer state of the data satisfies the requirements.

[0217] In a terminal according to one embodiment of the present disclosure, if the control signal is received within the first wake-up time, the control circuit may indicate the buffer state of the data in the response signal, regardless of the requirements.

[0218] A base station according to one embodiment of the present disclosure may include a control circuit that sets information regarding a predetermined requirement in a control signal that triggers the transmission of the response signal, so that the terminal can control the method of transmitting a response signal based on the data buffer state that satisfies the predetermined requirement, and a transmission circuit that transmits the control signal to the terminal.

[0219] In a communication method according to one embodiment of the present disclosure, the terminal may receive a control signal and control the method of transmitting a response signal to the reception of the control signal based on the buffer state of data that satisfies predetermined requirements.

[0220] All disclosures in the specification, drawings, and abstract contained in the Japanese application 2021-089176, filed on 27 May 2021, are incorporated herein by reference. [Industrial applicability]

[0221] One embodiment of this disclosure is useful for wireless communication systems. [Explanation of Symbols]

[0222] 100 AP 101 Scheduling Unit 102, 205, 205A, 205B Request Delay Control Unit 103 Trigger frame generation section 104,208 Error Correction Encoding Unit 105,209 Modulation section 106,201 Wireless Transceiver Unit 107,202 Demodulation section 108,203 Error Correction and Decoding Unit 109 Terminal Information Acquisition Unit 200 terminals (STA) 204 Trigger frame acquisition section 206 Buffer determination unit 207,207A Response signal generation unit

Claims

1. A receiving circuit that receives control signals, A control circuit controls the method of transmitting a response signal to the reception of the control signal based on the buffer state of data that satisfies predetermined requirements, Equipped with, The control circuit indicates the required conditions for the data held in the buffer in the response signal by applying an orthogonal sequence pattern to the training signal of the response signal. Terminal.

2. The aforementioned requirements are requirements relating to the delay of the data. The terminal according to claim 1.

3. The aforementioned requirements are based on traffic indicators, access categories, or the time until the data is discarded. The terminal according to claim 1.

4. The aforementioned requirements are indicated in the user information field of the control signal. The terminal according to claim 1.

5. The control circuit makes the frequency resources used for transmitting the response signal different between the transmission data with high requirements and the transmission data with low requirements. The terminal according to claim 3.

6. In the user information field of the control signal, the location of the frequency resource for the transmission data with the high requirement is indicated. The terminal according to claim 5.

7. The value of the feedback type subfield in the user information field of the control signal indicates whether the requirement is present or high. The terminal according to claim 1.

8. The control circuit indicates the requirement in the response signal when the number of symbols in the training signal is 2 and the value of the multiple flag subfield of the control signal is 0. The terminal according to claim 1.

9. The control circuit, by the frequency resource that transmits the response signal, indicates the requirements for the data held in the buffer. The terminal according to claim 1.

10. If the control signal is received within a second wake-up time in which data transmission is restricted according to the requirements with respect to the first wake-up time, the control circuit indicates in the response signal that the buffer state of the data satisfying the requirements is indicated. The terminal according to claim 1.

11. If the control signal is received within the first wake-up time, the control circuit indicates the buffer state of the data in the response signal, regardless of the requirements. The terminal according to claim 10.

12. A control circuit sets information regarding the requirements for controlling how a terminal transmits a response signal based on the buffer state of data that satisfies predetermined requirements, in a control signal that triggers the transmission of the response signal. A transmitting circuit that transmits the aforementioned control signal to the terminal, Equipped with, The orthogonal sequence pattern applied to the training signal of the response signal indicates the requirements of the data held in the buffer in the response signal. Base station.

13. The device is, We will receive the control signal. Based on the buffer state of data that satisfies predetermined requirements, the method of transmitting a response signal to the reception of the control signal is controlled. The orthogonal sequence pattern applied to the training signal of the response signal indicates the requirements of the data held in the buffer in the response signal. Communication method.

Citation Information

Patent Citations

  • QoS Management of Multi-User EDCA Transmission Modes in 802.11ax Networks

    JP2019536334A

  • Communication device, control method, and program

    WO2019167376A1