WO2024100924A1 - 端末、基地局、及び、通信方法 - Google Patents

端末、基地局、及び、通信方法 Download PDF

Info

Publication number
WO2024100924A1
WO2024100924A1 PCT/JP2023/025372 JP2023025372W WO2024100924A1 WO 2024100924 A1 WO2024100924 A1 WO 2024100924A1 JP 2023025372 W JP2023025372 W JP 2023025372W WO 2024100924 A1 WO2024100924 A1 WO 2024100924A1
Authority
WO
WIPO (PCT)
Prior art keywords
signal
terminal
pdsch
rar
pusch
Prior art date
Application number
PCT/JP2023/025372
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 WO2024100924A1 publication Critical patent/WO2024100924A1/ja

Links

Images

Definitions

  • This disclosure relates to a terminal, a base station, and a communication method.
  • a communication system known as the fifth generation mobile communication system (5G) is currently under consideration.
  • the 3rd Generation Partnership Project (3GPP) an international standardization organization, is considering the advancement of the 5G communication system from the perspectives of both the advancement of the LTE/LTE-Advanced system and New Radio Access Technology (also known as New RAT or NR), a new method that is not necessarily backward compatible with the LTE/LTE-Advanced system (see, for example, Non-Patent Document 1).
  • Non-limiting examples of the present disclosure contribute to providing a terminal, a base station, and a communication method that can appropriately set the uplink transmission timing in the terminal.
  • a terminal includes a receiving circuit that receives a first signal and a transmitting circuit that transmits a second signal after receiving the first signal, and the transmission timing of the second signal varies depending on a parameter related to the resource size of the first signal.
  • the uplink transmission timing in the terminal can be appropriately set.
  • FIG. 1 shows an example of the operation of a base station and a terminal.
  • Diagram of an example architecture for a 3GPP NR system Schematic diagram showing functional separation between NG-RAN and 5GC Sequence diagram of Radio Resource Control (RRC) connection setup/reconfiguration procedure
  • RRC Radio Resource Control
  • RRC Radio Resource Control
  • eMBB enhanced Mobile BroadBand
  • mMTC massive Machine Type Communications
  • URLLC Ultra Reliable and Low Latency Communications
  • a radio frame, a slot, and a symbol are each units of physical resources in the time domain.
  • the length of one frame may be 10 milliseconds.
  • one frame may be composed of multiple slots (for example, 10, 20, or other values).
  • the number of slots constituting one frame may be variable depending on the slot length.
  • one slot may be composed of multiple symbols (for example, 14 or 12).
  • one symbol is the smallest physical resource unit in the time domain, and the symbol length may vary depending on the subcarrier spacing (SCS).
  • SCS subcarrier spacing
  • a subcarrier and a resource block are each units of physical resources in the frequency domain.
  • one resource block may consist of 12 subcarriers.
  • one subcarrier may be the smallest physical resource unit in the frequency domain.
  • the subcarrier spacing is variable and may be, for example, 15 kHz, 30 kHz, 60 kHz, 120 kHz, 240 kHz, 480 kHz, 960 kHz, or other values.
  • eRedCap terminals aim to reduce manufacturing costs, for example, by limiting the characteristics (e.g., capabilities) they support.
  • characteristics that eRedCap terminals may support include the following:
  • the maximum number of physical resource blocks (PRBs) that can be received and processed per unit time (for example, the total frequency bandwidth occupied by each PRB) is about 5 MHz.
  • PRBs physical resource blocks
  • SCS subcarrier spacing
  • the PRB number corresponding to the characteristics that the above eRedCap terminal can support will be referred to as the "PRB number equivalent to 5 MHz.”
  • terminals that support Release 15/16/17 for example, also called Rel-15/16/17) and terminals that support Rel-18 but whose capabilities are greater than those of eRedCap terminals (or terminals whose capabilities are not restricted) are called “non-eRedCap terminals” or “non-eRedCap terminals” in comparison to eRedCap terminals.
  • Non-eRedCap terminals terminals that support Release 15/16/17
  • Rel-18 terminals that support Rel-18 but whose capabilities are greater than those of eRedCap terminals (or terminals whose capabilities are not restricted)
  • Rel-17 RedCap terminals are also included in non-eRedCap terminals.
  • both eRedCap and non-eRedCap devices may coexist.
  • a base station also called a gNB, for example
  • the number of PRBs in the allocated resources may be more than the "number of PRBs equivalent to 5 MHz.”
  • a base station may allocate resources that exceed the characteristics that an eRedCap terminal can support.
  • this situation may occur during the initial access (random access procedure) when allocating resources for a data channel (e.g., PDSCH: Physical Downlink Shared Channel) that the terminal uses to receive Message 2 (also called Random Access Response (RAR) or Msg 2) and a data channel (e.g., PUSCH: Physical Uplink Shared Channel) that the terminal uses to transmit Message 3 (also called Msg 3).
  • a data channel e.g., PDSCH: Physical Downlink Shared Channel
  • PUSCH Physical Uplink Shared Channel
  • the timing at which the RAR reception process is completed in the eRedCap terminal may be slower than expected by the base station, and the RAR reception process may not be completed by the time resource (transmission timing) of the PUSCH to which Msg 3 is assigned.
  • the eRedCap terminal may not be able to transmit Msg 3 before the RAR reception process is completed in the time resource (transmission timing) scheduled by RAR.
  • a method may be used to set (or limit) the number of PRBs allocated to the PDSCH for RAR to less than the "number of PRBs equivalent to 5 MHz.”
  • the base station will not allocate resources greater than the "number of PRBs equivalent to 5 MHz" as PDSCH resources for RAR. This prevents the timing of completion of the RAR reception process in the eRedCap terminal from being slower than expected by the base station, and the eRedCap terminal can properly transmit Msg 3 in the time resource (transmission timing) of the allocated PUSCH.
  • the number of PRBs allocated to the PDSCH for RAR for non-eRedCap terminals is also set (or limited) to a number equal to or less than the "number of PRBs equivalent to 5 MHz", which may result in degraded reception performance for non-eRedCap terminals that are capable of allocating resources greater than the "number of PRBs equivalent to 5 MHz".
  • the communication system includes a base station 100 and a terminal 200.
  • the terminal 200 may be, for example, an eRedCap terminal or a non-eRedCap terminal.
  • FIG. 1 is a block diagram showing an example of the configuration of a portion of a base station 100 according to this embodiment.
  • a transmitting unit e.g., corresponding to a transmitting circuit
  • a receiving unit e.g., corresponding to a receiving circuit
  • receives a second signal e.g., a PUSCH for Msg 3 after transmitting the first signal.
  • FIG. 2 is a block diagram showing an example of the configuration of a portion of a terminal 200 according to this embodiment.
  • a receiving unit e.g., corresponding to a receiving circuit
  • receives a first signal e.g., a PDSCH for RAR
  • a transmitting unit e.g., a transmitting circuit
  • transmits a second signal e.g., a PUSCH for Msg 3 after receiving the first signal.
  • the transmission timing of the second signal varies depending on a parameter related to the resource size (e.g., number of PRBs, TB size, or TB scaling factor) of the first signal (e.g., PDSCH for RAR).
  • Fig. 3 is a block diagram showing an example of the configuration of a base station 100 according to this embodiment.
  • the base station 100 includes a control unit 101, a Downlink Control Information (DCI) generating unit 102, an RAR generating unit 103, an upper layer signal generating unit 104, an encoding and modulation unit 105, a signal mapping unit 106, a transmitting unit 107, an antenna 108, a receiving unit 109, a signal separating unit 110, and a demodulating and decoding unit 111.
  • DCI Downlink Control Information
  • At least one of the transmitting unit 107 and the antenna 108 shown in FIG. 3 may be included in the transmitting unit shown in FIG. 1.
  • at least one of the antenna 108 and the receiving unit 109 shown in FIG. 3 may be included in the receiving unit shown in FIG. 1.
  • the control unit 101 may, for example, determine the resources (e.g., including downlink resources and uplink resources) to be assigned to the terminal 200.
  • control unit 101 may instruct the upper layer signal generating unit 104 to generate an upper layer signal (e.g., also called an upper layer parameter or upper layer signaling) based on information about the determined resources.
  • control unit 101 may instruct the DCI generating unit 102 to generate control information (e.g., DCI) included in a downlink control channel (e.g., PDCCH) based on information about the determined resources.
  • control unit 101 may instruct the RAR generating unit 103 to generate an RAR in a random access procedure based on information about the determined resources.
  • the control unit 101 also outputs (or instructs) information regarding downlink resources to the signal placement unit 106, and outputs (or instructs) information regarding uplink resources to the signal separation unit 110.
  • the DCI generation unit 102 may generate DCI based on instructions from the control unit 101, and output the generated DCI to the signal placement unit 106, for example.
  • the RAR generation unit 103 may generate an RAR based on instructions from the control unit 101, and output the generated RAR to the encoding/modulation unit 105, for example.
  • the upper layer signal generating unit 104 may generate an upper layer signal such as system information based on instructions from the control unit 101, and output the generated upper layer signal to the coding and modulation unit 105.
  • the coding and modulation unit 105 may, for example, perform error correction coding and modulation on the downlink data, the RAR input from the RAR generation unit 103, and the upper layer signal input from the upper layer signal generation unit 104, and output the modulated signal to the signal arrangement unit 106.
  • the signal placement unit 106 may place at least one of the DCI input from the DCI generation unit 102 and the signal input from the coding and modulation unit 105 in resources, for example, based on information regarding downlink resources input from the control unit 101. For example, the signal placement unit 106 may place the signal input from the coding and modulation unit 105 in a PDSCH resource, and place the DCI in a downlink control channel (e.g., PDCCH: Physical Downlink Control Channel) resource. The signal placement unit 106 outputs the signal placed in each resource to the transmission unit 107.
  • a downlink control channel e.g., PDCCH: Physical Downlink Control Channel
  • the transmitter 107 performs wireless transmission processing, including frequency conversion (e.g., up-conversion) using a carrier wave, on the signal input from the signal placement unit 106, and outputs the signal after wireless transmission processing to the antenna 108.
  • frequency conversion e.g., up-conversion
  • the antenna 108 radiates a signal (e.g., a downlink signal) input from the transmitting unit 107 toward the terminal 200.
  • the antenna 108 also receives an uplink signal transmitted from the terminal 200, for example, and outputs the signal to the receiving unit 109.
  • the uplink signal may be, for example, a signal of a channel such as an uplink data channel (e.g., PUSCH), an uplink control channel (e.g., PUCCH: Physical Uplink Control Channel), or a random access channel (e.g., PRACH: Physical Random Access Channel).
  • PUSCH uplink data channel
  • PUCCH Physical Uplink Control Channel
  • PRACH Physical Random Access Channel
  • the receiving unit 109 performs radio reception processing, including frequency conversion (e.g., down-conversion), on the signal input from the antenna 108, and outputs the signal after radio reception processing to the signal separation unit 110.
  • frequency conversion e.g., down-conversion
  • the signal separation unit 110 extracts (or separates) signals on the PUCCH resource (e.g., UCI) and signals on the PRACH (e.g., preamble) from the signals input from the receiving unit 109, based on, for example, information on the uplink resource input from the control unit 101. Furthermore, the signal separation unit 110 outputs, for example, signals on the PUSCH resource from the signals input from the receiving unit 109 to the demodulation and decoding unit 111.
  • the PUCCH resource e.g., UCI
  • the PRACH e.g., preamble
  • the demodulation and decoding unit 111 demodulates and decodes the signal input from the signal separation unit 110 and outputs uplink data.
  • FIG. 4 is a block diagram showing an example of the configuration of terminal 200 according to this embodiment.
  • the terminal 200 has an antenna 201, a receiving unit 202, a signal separating unit 203, a DCI detecting unit 204, a demodulating and decoding unit 205, a control unit 206, an encoding and modulating unit 207, a signal arrangement unit 208, and a transmitting unit 209.
  • At least one of the antenna 201 and the receiving unit 202 shown in FIG. 4 may be included in the receiving unit shown in FIG. 2.
  • at least one of the antenna 201 and the transmitting unit 209 shown in FIG. 4 may be included in the transmitting unit shown in FIG. 2.
  • the antenna 201 receives, for example, a downlink signal (downlink channel) transmitted by the base station 100 and outputs it to the receiving unit 202.
  • the antenna 201 also radiates, for example, an uplink signal (uplink channel) input from the transmitting unit 209 to the base station 100.
  • the receiving unit 202 performs radio reception processing, including frequency conversion (e.g., down-conversion), on the signal input from the antenna 201, and outputs the signal after radio reception processing to the signal separation unit 203.
  • frequency conversion e.g., down-conversion
  • the signal separation unit 203 extracts (e.g., separates) signals on PDCCH resources from the signals input from the receiving unit 202, based on information on downlink resources input from the control unit 206, for example, and outputs the signals to the DCI detection unit 204. Furthermore, the signal separation unit 203 outputs signals on PDSCH resources from the signals input from the receiving unit 202 to the demodulation and decoding unit 205, based on instructions from the control unit 206, for example.
  • the DCI detection unit 204 may detect DCI, for example, from a signal (for example, a signal on a PDCCH resource) input from the signal separation unit 203.
  • the DCI detection unit 204 may output the detected DCI to the control unit 206, for example.
  • the demodulation and decoding unit 205 demodulates and performs error correction decoding on a signal (for example, a signal on a PDSCH resource) input from the signal separation unit 203 to obtain at least one of downlink data, an upper layer signal such as system information, and an RAR.
  • the demodulation and decoding unit 205 may, for example, output the upper layer signal and RAR obtained by decoding to the control unit 206.
  • the demodulation and decoding unit 205 may also, for example, output the downlink data obtained by decoding.
  • the control unit 206 may determine (or identify) downlink resources and uplink resources, for example, based on the DCI input from the DCI detection unit 204 and at least one of the higher layer signal (e.g., system information) and RAR input from the demodulation and decoding unit 205. For example, the control unit 206 may output (e.g., instruct) information regarding the identified downlink resources to the signal separation unit 203, and output (e.g., instruct) information regarding the identified uplink resources to the signal placement unit 208.
  • the higher layer signal e.g., system information
  • RAR input from the demodulation and decoding unit 205.
  • the control unit 206 may output (e.g., instruct) information regarding the identified downlink resources to the signal separation unit 203, and output (e.g., instruct) information regarding the identified uplink resources to the signal placement unit 208.
  • the encoding and modulation unit 207 may, for example, encode and modulate uplink data (e.g., Msg 3) and output the modulated signal to the signal arrangement unit 208.
  • uplink data e.g., Msg 3
  • the signal arrangement unit 208 may, for example, arrange the signal input from the coding and modulation unit 207 in a PUSCH resource, arrange the UCI in a PUCCH resource, and arrange the preamble in a PRACH resource based on information about the uplink resource input from the control unit 206.
  • the signal arrangement unit 208 outputs the signal arranged in each resource to the transmission unit 209.
  • the transmitter 209 performs wireless transmission processing, including frequency conversion (e.g., up-conversion), on the signal input from the signal placement unit 208, and outputs the signal after wireless transmission processing to the antenna 201.
  • frequency conversion e.g., up-conversion
  • a minimum time interval (e.g., "m') may be set between the PDSCH for RAR and the PUSCH for Msg 3 when the number of PRBs allocated to the PDSCH for RAR is greater than a threshold value (e.g., "the number of PRBs equivalent to 5 MHz").
  • the interval between the time resource of the PDSCH for RAR and the time resource of the PUSCH for Msg 3 may be set to be greater than or equal to the minimum time interval m'.
  • the terminal 200 may assume (or anticipate, assume) the transmission (or scheduling, setting) of Msg 3 (PUSCH) at an interval between the time resource of the PDSCH for RAR that is equal to or greater than the minimum time interval m'.
  • the terminal 200 may not assume (or anticipate, assume) the transmission (or scheduling, setting) of Msg 3 (PUSCH) at an interval between the time resource of the PDSCH for RAR that is shorter than the minimum time interval m'.
  • the terminal 200 can appropriately transmit Msg3 at a timing appropriate to the processing capabilities of the terminal 200.
  • FIG. 5 is a flowchart showing an example of processing by a base station 100 (e.g., a gNB) and a terminal 200 (e.g., a UE).
  • a base station 100 e.g., a gNB
  • a terminal 200 e.g., a UE
  • the base station 100 determines, for example, parameters related to the data size of the RAR.
  • the parameters related to the data size of the RAR may include at least the number of PRBs assigned to the PDSCH that transmits the RAR.
  • the parameters related to the data size of the RAR may include, for example, at least one of a transport block (TB) size set in the PDSCH for the RAR and a TB scaling factor used to determine the TB size set in the PDSCH for the RAR.
  • TB transport block
  • the base station 100 determines the PDSCH resource for RAR and the PUSCH resource for Msg 3 based on, for example, the parameter related to the data size of the RAR determined in S101 (for example, the number of PRBs).
  • the minimum time interval (m') between the PDSCH and the PUSCH when the number of PRBs assigned to the PDSCH is greater than the "number of PRBs equivalent to 5 MHz" may be specified (or set or defined).
  • the base station 100 may allocate resources for the PDSCH and PUSCH so that a minimum time interval (m') is secured as the interval between the timing (e.g., symbol, time, or time unit) at which the terminal 200 completes reception of a PDSCH having a PRB number greater than the "PRB number equivalent to 5 MHz" and the timing (e.g., symbol, time, or time unit) at which the terminal 200 starts transmitting a PUSCH (e.g., Msg 3).
  • the terminal 200 may perform reception processing of the PDSCH (e.g., RAR) between the timing at which the terminal 200 completes reception of the PDSCH and the timing at which the terminal 200 starts transmitting the PUSCH.
  • base station 100 may assign a PDSCH having a number of PRBs greater than "the number of PRBs equivalent to 5 MHz" to slot n, and assign a PUSCH to slot n+k'.
  • the value of k' e.g., a length of k' slots
  • Base station 100 may determine, for example, information regarding the value of k' as information regarding the PUSCH resource for Msg 3.
  • the minimum time interval (m') may be set to a time interval between PDSCH and PUSCH taking into consideration the case where the number of PRBs allocated to the PDSCH is greater than the "number of PRBs equivalent to 5 MHz".
  • the minimum time interval (m') may be set based on the receiving processing time (or receiving processing capability) of RAR in the eRedCap terminal when the number of PRBs allocated to the PDSCH for RAR is greater than the "number of PRBs equivalent to 5 MHz".
  • the minimum time interval (m') may be set based on the upper limit of the number of PRBs allocated to the PDSCH for RAR.
  • the minimum time interval (m') is not limited to being set based on the upper limit of the number of PRBs allocated to the PDSCH for RAR, and may be set based on any of the possible values for the number of PRBs allocated to RAR.
  • the minimum time interval (m') may be set to the minimum time interval between the PDSCH and the PUSCH when the number of PRBs allocated to the PDSCH is equal to or less than 20 MHz.
  • the number of PRBs used as a reference for setting the minimum time interval (m') is not limited to the number of PRBs equivalent to 20 MHz, and may be the number of PRBs equivalent to another frequency bandwidth.
  • the minimum time interval (m') may be set to the minimum time interval between the PDSCH and the PUSCH when the number of PRBs allocated to the PDSCH is within a certain range (for example, a range greater than the number of PRBs equivalent to 5 MHz and less than or equal to the number of PRBs equivalent to 20 MHz).
  • a certain range for example, a range greater than the number of PRBs equivalent to 5 MHz and less than or equal to the number of PRBs equivalent to 20 MHz.
  • the range of the number of PRBs used as the basis for setting the minimum time interval (m') is not limited to the range of the number of PRBs equivalent to 5 MHz to 20 MHz, and may be the number of PRBs corresponding to another frequency bandwidth range.
  • multiple setting value candidates are defined for the minimum time interval (m'), and one of the multiple setting value candidates may be set for the terminal 200, for example, depending on the number of PRBs allocated to the PDSCH.
  • the base station 100 may transmit (for example, notify, set) information on the PDSCH resource for RAR determined in S102 to the terminal 200.
  • the information on the PDSCH resource for RAR may be notified to the terminal 200 by, for example, a PDCCH (for example, DCI).
  • the PDCCH may be scrambled using, for example, a Random Access - Radio Network Temporary Identifier (RA-RNTI).
  • RA-RNTI Random Access - Radio Network Temporary Identifier
  • the terminal 200 may receive information regarding PDSCH resources for RAR notified from the base station 100, for example, and identify the PDSCH resources for RAR based on the received information.
  • Base station 100 transmits an RAR in the PDSCH resource notified in S103 to terminal 200.
  • the RAR may include information on the PUSCH resource for Msg3 determined in S102 (for example, information on k').
  • the terminal 200 receives the RAR, for example, in the PDSCH resource identified in S104.
  • Terminal 200 performs, for example, reception processing of the RAR, and identifies the PUSCH resource for Msg.3 based on information included in the RAR.
  • terminal 200 may assume that the resources of the PDSCH and PUSCH are set so that a minimum time interval (m') is secured as the interval between the timing (e.g., symbol or time) at which reception of a PDSCH having a PRB number greater than "the number of PRBs equivalent to 5 MHz" is completed and the timing (e.g., symbol or time) at which transmission of a PUSCH (e.g., Msg 3) is started.
  • a minimum time interval e.g., Msg 3
  • terminal 200 may assume that, when the number of PRBs allocated to the PDSCH placed in slot n is greater than the "number of PRBs equivalent to 5 MHz", the value of k' that makes the interval between the PDSCH and PUSCH equal to or greater than the minimum time interval m' is notified for slot n+k' in which the PUSCH resource is placed. Terminal 200 may assume, for example, that the length of k' slots (or the slot interval between the PDSCH and PUSCH) is greater than m'.
  • the terminal 200 may determine the number of PRBs to be allocated to the PDSCH based on, for example, control information received in advance or control information received using the above-mentioned PDCCH.
  • Terminal 200 transmits Msg 3 to base station 100, for example, using the PUSCH resource identified in S107.
  • the base station 100 receives Msg 3, for example, on the PUSCH resource determined in S102.
  • the base station 100 can allocate time resources for the PUSCH of Msg.3 to the PUSCH for Msg 3, taking into account the data size of the RAR (or the reception processing of the RAR in the eRedCap terminal). This allows the terminal 200 (e.g., the eRedCap terminal) to transmit Msg3 at an appropriate timing suited to the processing capacity of the eRedCap terminal, based on the allocation information included in the received RAR.
  • the time resources of the PUSCH may be allocated based on an existing allocation method (e.g., a method that does not consider the minimum time interval (m') or k').
  • the time resource interval between the PDSCH and the PUSCH may be set to an interval shorter than the minimum time interval (m').
  • the interval between the PDSCH and the PUSCH for slot n+k to which the PUSCH is allocated may be set to be less than m'.
  • the value of k e.g., the length of k slots
  • the base station 100 may notify the terminal 200 of information regarding the value of k as information regarding the PUSCH resources for Msg 3.
  • a minimum time interval (m) between the PDSCH and the PUSCH may be specified when the number of PRBs allocated to the PDSCH is equal to or less than the "number of PRBs equivalent to 5 MHz.”
  • the minimum time interval (m) may be set to be smaller than the minimum time interval (m').
  • the base station 100 may allocate resources for the PDSCH and PUSCH so that a minimum time interval (m) is secured as the interval between the timing (e.g., symbol or time) at which the terminal 200 completes reception of a PDSCH having a PRB number equal to or less than "a PRB number equivalent to 5 MHz" and the timing (e.g., symbol or time) at which the terminal 200 starts transmitting a PUSCH (e.g., Msg 3).
  • a minimum time interval e.g., Msg 3
  • terminal 200 may assume that the resources of the PDSCH and PUSCH are set so that a minimum time interval (m) is secured as the interval between the timing (e.g., symbol or time) at which reception of a PDSCH having a PRB number equal to or less than "the number of PRBs equivalent to 5 MHz" is completed and the timing (e.g., symbol or time) at which transmission of a PUSCH (e.g., Msg 3) is started.
  • terminal 200 need not assume reception of a PDSCH and transmission of a PUSCH at an interval shorter than the minimum time interval (m).
  • the PUSCH resource may be allocated to slot n+k.
  • a value of k may be set such that the interval between the PDSCH and PUSCH is equal to or greater than m, and this value may be notified to terminal 200.
  • the length of k slots may be set to be greater than m.
  • the reception processing time in the terminal 200 e.g., an eRedCap terminal
  • the terminal 200 can transmit Msg3 at an earlier timing compared to when the number of PRBs allocated to the PDSCH for RAR is greater than the "number of PRBs equivalent to 5 MHz.”
  • the timing of transmitting the PUSCH may be dynamically set (or switched or changed) depending on the number of PRBs allocated to the PDSCH.
  • the time resource interval between the PDSCH for RAR and the PUSCH for Msg 3 may differ depending on the number of PRBs allocated to the PDSCH.
  • the terminal 200 may transmit the PUSCH in slot n+k, and when the number of PRBs allocated to the PDSCH placed in slot n is greater than the "number of PRBs equivalent to 5 MHz", the terminal 200 may transmit the PUSCH in slot n+k'.
  • the terminal 200 can appropriately transmit Msg 3 at a timing according to the data size of the RAR (e.g., the number of PRBs).
  • the minimum time interval (m) may be set to a time interval between the PDSCH and the PUSCH that takes into consideration the case where the number of PRBs allocated to the PDSCH is equal to or less than "the number of PRBs equivalent to 5 MHz.”
  • the minimum time interval (m) may be set to the minimum time interval between the PDSCH and the PUSCH when the number of PRBs allocated to the PDSCH is equal to or less than 5 MHz.
  • multiple setting value candidates are defined for the minimum time interval (m), and one of the multiple setting value candidates may be set for the terminal 200 depending on the number of PRBs allocated to the PDSCH, for example.
  • the above describes an example of the operation of the base station 100 and the terminal 200.
  • base station 100 transmits a PDSCH for RAR, and receives a PUSCH for Msg 3 after transmitting the PDSCH for RAR.
  • terminal 200 receives a PDSCH for RAR, and transmits a PUSCH for Msg 3 after receiving the PDSCH for RAR.
  • the transmission timing of the PUSCH for Msg 3 differs depending on a parameter related to the resource size of the PDSCH for RAR (e.g., the number of PRBs).
  • the eRedCap terminal can transmit Msg 3 at an appropriate timing according to the processing capability of the eRedCap terminal (e.g., the receiving processing capability of RAR) depending on, for example, the data size of the PDSCH for RAR. Therefore, according to this embodiment, the transmission timing of the uplink in the terminal 200 can be appropriately set.
  • the processing capability of the eRedCap terminal e.g., the receiving processing capability of RAR
  • the transmission timing of the uplink in the terminal 200 can be appropriately set.
  • PRB number equivalent to 5 MHz is used as the reference PRB number for determining the transmission timing of the PUSCH, but this is not limited to this and other PRB numbers may also be used.
  • the base station 100 and the terminal 200 according to the present embodiment may be similar to those in the first embodiment.
  • a minimum time interval (e.g., "m') may be set between the PDSCH for RAR and the PUSCH for Msg 3 when the TB size of the PDSCH for RAR is greater than a threshold value.
  • the interval between the time resource of the PDSCH for RAR and the time resource of the PUSCH for Msg 3 may be set to be equal to or greater than the minimum time interval m'.
  • the base station 100 may determine the time resource of the PUSCH for Msg 3 so that the interval with the time resource of the PDSCH for RAR is equal to or greater than the minimum time interval m'.
  • the terminal 200 may assume (or anticipate, assume) the transmission (or scheduling, setting) of Msg 3 (PUSCH) at an interval between the time resource of the PDSCH for RAR that is equal to or greater than the minimum time interval m'.
  • the terminal 200 may not assume (or anticipate, assume) the transmission (or scheduling, setting) of Msg 3 (PUSCH) at an interval between the time resource of the PDSCH for RAR that is shorter than the minimum time interval m'.
  • the terminal 200 can appropriately transmit Msg3 at a timing appropriate to the processing capabilities of the terminal 200.
  • An example of the processing of the base station 100 (e.g., gNB) and the terminal 200 (e.g., UE) in this embodiment may be similar to the example of the processing in embodiment 1 shown in FIG. 5.
  • the base station 100 determines, for example, parameters related to the data size of the RAR.
  • the parameters related to the data size of the RAR may include at least the TB size of the PDSCH for the RAR.
  • the parameters related to the data size of the RAR may include, for example, at least one of the number of PRBs allocated to the PDSCH for the RAR and the TB scaling factor used to determine the TB size set in the PDSCH for the RAR.
  • the base station 100 determines the PDSCH resource for RAR and the PUSCH resource for Msg 3 based on, for example, the parameter related to the data size of the RAR determined in S101 (for example, TB size).
  • a minimum time interval (m') between the PDSCH and the PUSCH when the TB size of the PDSCH is greater than a threshold may be specified (or set or defined).
  • the threshold for the PDSCH TB size may be, for example, 1000 bits, or may be another value.
  • the threshold may be specified in a standard, may be set in advance in the terminal 200, or may be notified (or set) from the base station 100 to the terminal 200.
  • the base station 100 may allocate resources for the PDSCH and PUSCH so that a minimum time interval (m') is secured as the interval between the timing (e.g., symbol, time, or time unit) at which the terminal 200 completes reception of a PDSCH having a TB size larger than a threshold and the timing (e.g., symbol, time, or time unit) at which the terminal 200 starts transmitting a PUSCH (e.g., Msg 3).
  • the terminal 200 may perform reception processing of the PDSCH (e.g., RAR) between the timing at which the terminal 200 completes reception of the PDSCH and the timing at which the terminal 200 starts transmitting the PUSCH.
  • base station 100 may assign a PDSCH having a TB size larger than a threshold to slot n, and a PUSCH to slot n+k'.
  • the value of K' e.g., the length of k' slots
  • Base station 100 may determine, for example, information regarding the value of k' as information regarding the PUSCH resource for Msg 3.
  • the minimum time interval (m') may be set to a time interval between PDSCH and PUSCH that takes into account the case where the TB size of the PDSCH is larger than a threshold.
  • the minimum time interval (m') may be set based on the reception processing time (or reception processing capability) of RAR in an eRedCap terminal when the TB size of the PDSCH for RAR is larger than a threshold.
  • the minimum time interval (m') may be set based on the upper limit of the TB size of the PDSCH for RAR.
  • the minimum time interval (m') is not limited to being set based on the upper limit of the TB size of the PDSCH for RAR, and may be set based on any of the possible values of the TB size.
  • the minimum time interval (m') may be set to the minimum time interval between the PDSCH and the PUSCH when the TB size of the PDSCH is equal to or smaller than a specified value (e.g., 4000 bits).
  • a specified value e.g. 4000 bits.
  • the TB size value that is the basis for setting the minimum time interval (m') is not limited to 4000 bits and may be another size.
  • the minimum time interval (m') may be set to the minimum time interval between the PDSCH and the PUSCH when the TB size of the PDSCH is in a certain range (for example, a range of more than 1000 bits and less than or equal to 4000 bits).
  • a certain range for example, a range of more than 1000 bits and less than or equal to 4000 bits.
  • the range of TB sizes that is the basis for setting the minimum time interval (m') is not limited to the range of 1000 bits to 4000 bits, and may be other TB size ranges.
  • multiple setting value candidates may be specified for the minimum time interval (m'), and one of the multiple setting value candidates may be set for the terminal 200 depending on, for example, the TB size of the PDSCH.
  • the base station 100 may transmit (for example, notify, set) information on the PDSCH resource for RAR determined in S102 to the terminal 200.
  • the information on the PDSCH resource for RAR may be notified to the terminal 200 by, for example, a PDCCH (for example, DCI).
  • the PDCCH may be scrambled using, for example, the RA-RNTI.
  • the terminal 200 may receive information regarding PDSCH resources for RAR notified from the base station 100, for example, and identify the PDSCH resources for RAR based on the received information.
  • Base station 100 transmits an RAR in the PDSCH resource notified in S103 to terminal 200.
  • the RAR may include information on the PUSCH resource for Msg3 determined in S102 (for example, information on k').
  • the terminal 200 receives the RAR, for example, in the PDSCH resource identified in S104.
  • Terminal 200 performs, for example, reception processing of the RAR, and identifies the PUSCH resource for Msg.3 based on information included in the RAR.
  • the terminal 200 may assume that the resources of the PDSCH and PUSCH are set so that a minimum time interval (m') is secured as the interval between the timing (e.g., symbol or time) at which reception of a PDSCH having a TB size larger than the threshold is completed and the timing (e.g., symbol or time) at which transmission of a PUSCH (e.g., Msg 3) is started.
  • the terminal 200 may not assume reception of a PDSCH and transmission of a PUSCH at an interval shorter than the minimum time interval (m').
  • terminal 200 may assume that, when the TB size of the PDSCH placed in slot n is greater than a threshold, the value of k' that makes the interval between the PDSCH and the PUSCH equal to or greater than the minimum time interval m' for slot n+k' in which the PUSCH resource is placed is notified. Terminal 200 may assume, for example, that the length of k' slots (or the slot interval between the PDSCH and the PUSCH) is greater than m'.
  • the terminal 200 may determine the TB size of the PDSCH based on, for example, control information received in advance or control information received using the above-mentioned PDCCH.
  • Terminal 200 transmits Msg 3 to base station 100 in the PUSCH resource identified in S107, for example.
  • the base station 100 receives Msg 3, for example, in the PUSCH resource determined in S102.
  • the base station 100 can allocate time resources of the PUSCH for Msg 3 to the PUSCH for Msg 3, taking into account the data size of the RAR (or the reception processing of the RAR in the eRedCap terminal). This allows the terminal 200 (e.g., the eRedCap terminal) to transmit Msg 3 at an appropriate timing suited to the processing capacity of the eRedCap terminal, based on the allocation information included in the received RAR.
  • the time resources of the PUSCH may be allocated based on an existing allocation method (e.g., a method that does not consider the minimum time interval (m') or k').
  • the time resource interval between the PDSCH and the PUSCH may be set to an interval shorter than the minimum time interval (m').
  • the interval between the PDSCH and the PUSCH for slot n+k to which the PUSCH is assigned may be set to be less than m'.
  • the value of k e.g., the length of k slots
  • the base station 100 may notify the terminal 200 of information regarding the value of k as information regarding the PUSCH resource for Msg 3.
  • a minimum time interval (m) between the PDSCH and the PUSCH when the TB size of the PDSCH is equal to or smaller than a threshold may be specified.
  • the minimum time interval (m) may be set to be smaller than the minimum time interval (m').
  • the base station 100 may allocate resources for the PDSCH and PUSCH so that a minimum time interval (m) is secured as the interval between the timing (e.g., symbol or time) at which the terminal 200 completes reception of a PDSCH having a TB size equal to or less than a threshold, and the timing (e.g., symbol or time) at which the terminal 200 starts transmitting a PUSCH (e.g., Msg 3).
  • a minimum time interval e.g., Msg 3
  • terminal 200 may assume that the resources of the PDSCH and PUSCH are set so that a minimum time interval (m) is secured as the interval between the timing (e.g., symbol or time) at which reception of a PDSCH having a TB size equal to or less than a threshold is completed and the timing (e.g., symbol or time) at which transmission of a PUSCH (e.g., Msg 3) is started.
  • terminal 200 may not assume reception of a PDSCH and transmission of a PUSCH at an interval shorter than the minimum time interval (m).
  • the PUSCH resource may be allocated to slot n+k.
  • a value of k may be set so that the interval between the PDSCH and the PUSCH is equal to or larger than m, and this value may be notified to terminal 200.
  • the length of k slots may be set to be greater than m.
  • the terminal 200 e.g., an eRedCap terminal
  • the terminal 200 can transmit Msg3 at an earlier timing compared to when the TB size of the PDSCH for RAR is larger than the threshold.
  • the timing of transmitting the PUSCH may be dynamically set (or switched or changed) according to the TB size of the PDSCH.
  • the time resource interval between the PDSCH for RAR and the PUSCH for Msg 3 may differ according to the TB size of the PDSCH.
  • terminal 200 may transmit a PUSCH in slot n+k when the TB size of the PDSCH placed in slot n is equal to or smaller than a threshold, and transmit a PUSCH in slot n+k' when the TB size of the PDSCH placed in slot n is greater than the threshold.
  • terminal 200 can appropriately transmit Msg 3 at a timing according to the data size of the RAR (e.g., the TB size).
  • the minimum time interval (m) may be set to a time interval between the PDSCH and the PUSCH that takes into consideration the case where the TB size of the PDSCH is equal to or smaller than a threshold.
  • the minimum time interval (m) may be set to the minimum time interval between the PDSCH and the PUSCH when the TB size of the PDSCH is equal to or smaller than 1000 bits.
  • multiple setting value candidates are defined for the minimum time interval (m), and one of the multiple setting value candidates may be set for the terminal 200, for example, depending on the TB size set for the PDSCH.
  • the above describes an example of the operation of the base station 100 and the terminal 200.
  • base station 100 transmits a PDSCH for RAR, and receives a PUSCH for Msg 3 after transmitting the PDSCH for RAR.
  • terminal 200 receives a PDSCH for RAR, and transmits a PUSCH for Msg 3 after receiving the PDSCH for RAR.
  • the transmission timing of the PUSCH for Msg 3 differs depending on a parameter related to the resource size of the PDSCH for RAR (e.g., TB size).
  • the eRedCap terminal can transmit Msg 3 at an appropriate timing according to the processing capability of the eRedCap terminal (e.g., the receiving processing capability of RAR) depending on, for example, the data size of the PDSCH for RAR. Therefore, according to this embodiment, the transmission timing of the uplink in the terminal 200 can be appropriately set.
  • the processing capability of the eRedCap terminal e.g., the receiving processing capability of RAR
  • the transmission timing of the uplink in the terminal 200 can be appropriately set.
  • the TB size (e.g., threshold) that is the basis for determining the transmission timing of the PUSCH may be determined according to the characteristics or capabilities of the eRedCap terminal.
  • the base station 100 and the terminal 200 according to the present embodiment may be similar to those in the first embodiment.
  • the TB scaling factor (or scaling factor) used to calculate (or determine) the TB size of the PDSCH for RAR is used as a parameter related to the RAR data size.
  • a minimum time interval (e.g., "m'") may be set between the PDSCH for RAR and the PUSCH for Msg 3 when the TB scaling factor of the PDSCH for RAR is greater than a threshold.
  • the interval between the time resource of the PDSCH for RAR and the time resource of the PUSCH for Msg 3 may be set to be greater than or equal to the minimum time interval m'.
  • the base station 100 may determine the time resource of the PUSCH for Msg 3 so that the interval with the time resource of the PDSCH for RAR is greater than or equal to the minimum time interval m'.
  • the terminal 200 may assume (or anticipate, assume) the transmission (or scheduling, setting) of Msg 3 (PUSCH) at an interval between the time resource of the PDSCH for RAR that is equal to or greater than the minimum time interval m'.
  • the terminal 200 may not assume (or anticipate, assume) the transmission (or scheduling, setting) of Msg 3 (PUSCH) at an interval between the time resource of the PDSCH for RAR that is shorter than the minimum time interval m'.
  • the terminal 200 can appropriately transmit Msg3 at a timing appropriate to the processing capabilities of the terminal 200.
  • An example of the processing of the base station 100 (e.g., gNB) and the terminal 200 (e.g., UE) in this embodiment may be similar to the example of the processing in embodiment 1 shown in FIG. 5.
  • the base station 100 determines, for example, parameters related to the data size of the RAR.
  • the parameters related to the data size of the RAR may include at least a TB scaling factor used to determine a TB size set in the PDSCH for the RAR.
  • the parameters related to the data size of the RAR may include, for example, at least one of the number of PRBs assigned to the PDSCH for the RAR and the TB size set in the PDSCH for the RAR.
  • the base station 100 determines the PDSCH resource for RAR and the PUSCH resource for Msg 3 based on, for example, the parameter related to the data size of the RAR determined in S101 (for example, the TB scaling factor).
  • a minimum time interval (m') between PDSCH and PUSCH when the TB scaling factor of the PDSCH is greater than a threshold may be specified (or set, defined).
  • the threshold for the PDSCH TB scaling factor may be, for example, 0.5 or another value.
  • the threshold may be specified in a standard, may be set in advance in the terminal 200, or may be notified (or set) from the base station 100 to the terminal 200.
  • the base station 100 may allocate resources for the PDSCH and PUSCH so that a minimum time interval (m') is secured as the interval between the timing (e.g., symbol, time, or time unit) at which the terminal 200 completes reception of a PDSCH with a TB scaling factor greater than a threshold value and the timing (e.g., symbol, time, or time unit) at which the terminal 200 starts transmitting a PUSCH (e.g., Msg 3).
  • the terminal 200 may perform reception processing of the PDSCH (e.g., RAR) between the timing at which the terminal 200 completes reception of the PDSCH and the timing at which the terminal 200 starts transmitting the PUSCH.
  • base station 100 may assign a PDSCH with a TB scaling factor larger than a threshold to slot n, and assign a PUSCH to slot n+k'.
  • the value of K' e.g., the length of k' slots
  • Base station 100 may determine, for example, information regarding the value of k' as information regarding the PUSCH resource for Msg 3.
  • the minimum time interval (m') may be set to a time interval between PDSCH and PUSCH taking into consideration the case where the TB scaling factor set in the PDSCH is greater than a threshold value.
  • the minimum time interval (m') may be set based on the receiving processing time (or receiving processing capability) of RAR in an eRedCap terminal when the TB scaling factor set in the PDSCH for RAR is greater than a threshold value.
  • the minimum time interval (m') may be set based on the upper limit value of the TB scaling factor set in the PDSCH for RAR. Note that the minimum time interval (m') is not limited to being set based on the upper limit value of the TB scaling factor set in the PDSCH for RAR, and may be set based on any of the possible values of the TB scaling factor.
  • the minimum time interval (m') may be set to the minimum time interval between the PDSCH and the PUSCH when the TB scaling factor of the PDSCH is equal to or less than a specified value (e.g., 1).
  • a specified value e.g. 1
  • the value of the TB scaling factor that is the basis for setting the minimum time interval (m') is not limited to 1 and may be another value.
  • the minimum time interval (m') may be set to the minimum time interval between the PDSCH and the PUSCH when the TB scaling factor of the PDSCH is in a certain range (for example, a range greater than 0.5 and less than or equal to 1).
  • the range of the TB scaling factor that is the basis for setting the minimum time interval (m') is not limited to the range of 0.5 to 1, and may be other TB scaling factor ranges.
  • multiple setting value candidates may be specified for the minimum time interval (m'), and one of the multiple setting value candidates may be set for the terminal 200 depending on, for example, the TB scaling factor of the PDSCH.
  • the base station 100 may transmit (for example, notify, set) information on the PDSCH resource for RAR determined in S102 to the terminal 200.
  • the information on the PDSCH resource for RAR may be notified to the terminal 200 by, for example, a PDCCH (for example, DCI).
  • the PDCCH may be scrambled using, for example, the RA-RNTI.
  • the terminal 200 may receive information regarding PDSCH resources for RAR notified from the base station 100, for example, and identify the PDSCH resources for RAR based on the received information.
  • Base station 100 transmits an RAR in the PDSCH resource notified in S103 to terminal 200.
  • the RAR may include information on the PUSCH resource for Msg3 determined in S102 (for example, information on k').
  • the terminal 200 receives the RAR, for example, in the PDSCH resource identified in S104.
  • Terminal 200 performs, for example, reception processing of the RAR, and identifies the PUSCH resource for Msg.3 based on information included in the RAR.
  • the terminal 200 may assume that the PDSCH and PUSCH resources are set so that a minimum time interval (m') is secured as the interval between the timing (e.g., symbol or time) at which the terminal 200 completes reception of a PDSCH with a TB scaling factor set greater than the threshold and the timing (e.g., symbol or time) at which the terminal 200 starts transmitting a PUSCH (e.g., Msg 3).
  • a minimum time interval e.g., Msg 3
  • the terminal 200 receives a PDSCH with a TB scaling factor set greater than the threshold, the terminal 200 does not need to assume reception of a PDSCH and transmission of a PUSCH at an interval shorter than the minimum time interval (m').
  • terminal 200 may assume that, when the TB scaling factor of the PDSCH placed in slot n is greater than a threshold, the value of k' that makes the interval between the PDSCH and PUSCH greater than or equal to the minimum time interval m' for slot n+k' in which the PUSCH resource is placed is notified. Terminal 200 may assume, for example, that the length of k' slots (or the slot interval between the PDSCH and PUSCH) is greater than m'.
  • the terminal 200 may determine the TB scaling factor of the PDSCH based on, for example, control information received in advance or control information received using the above-mentioned PDCCH.
  • Terminal 200 transmits Msg 3 to base station 100 in the PUSCH resource identified in S107, for example.
  • the base station 100 receives Msg 3, for example, in the PUSCH resource determined in S102.
  • the base station 100 can allocate time resources of the PUSCH for Msg 3 to the PUSCH for Msg 3, taking into account the data size of the RAR (or the reception processing of the RAR in the eRedCap terminal). This allows the terminal 200 (e.g., an eRedCap terminal) to transmit Msg 3 at an appropriate timing suited to the processing capacity of the eRedCap terminal, based on the allocation information contained in the received RAR.
  • the time resources of the PUSCH may be allocated based on an existing allocation method (e.g., a method that does not consider the minimum time interval (m') or k').
  • the time resource interval between the PDSCH and the PUSCH may be set to an interval shorter than the minimum time interval (m').
  • the interval between the PDSCH and the PUSCH for slot n+k to which the PUSCH is assigned may be set to be less than m'.
  • the value of k e.g., the length of k slots
  • the base station 100 may, for example, notify the terminal 200 of information regarding the value of k as information regarding the PUSCH resources for Msg 3.
  • a minimum time interval (m) between the PDSCH and the PUSCH may be specified when the TB scaling factor of the PDSCH is equal to or less than a threshold.
  • the minimum time interval (m) may be set to be smaller than the minimum time interval (m').
  • the base station 100 may allocate resources for the PDSCH and PUSCH so that a minimum time interval (m) is secured as the interval between the timing (e.g., symbol or time) at which the terminal 200 completes reception of a PDSCH for which a TB scaling factor equal to or less than a threshold is set, and the timing (e.g., symbol or time) at which the terminal 200 starts transmitting a PUSCH (e.g., Msg 3).
  • a minimum time interval e.g., Msg 3
  • terminal 200 may assume that the PDSCH and PUSCH resources are set so that a minimum time interval (m) is secured as the interval between the timing (e.g., symbol or time) at which reception of a PDSCH with a TB scaling factor set below a threshold is completed and the timing (e.g., symbol or time) at which transmission of a PUSCH (e.g., Msg 3) is started.
  • a minimum time interval (m) is secured as the interval between the timing (e.g., symbol or time) at which reception of a PDSCH with a TB scaling factor set below a threshold is completed and the timing (e.g., symbol or time) at which transmission of a PUSCH (e.g., Msg 3) is started.
  • terminal 200 may not need to assume reception of a PDSCH and transmission of a PUSCH at an interval shorter than the minimum time interval (m).
  • the PUSCH resource may be allocated to slot n+k.
  • a value of k may be set such that the interval between the PDSCH and the PUSCH is equal to or greater than m, and this value may be notified to terminal 200.
  • the length of k slots may be set to be greater than m.
  • the terminal 200 e.g., an eRedCap terminal
  • the terminal 200 can transmit Msg3 at an earlier timing compared to when the TB scaling factor of the PDSCH for RAR is greater than the threshold.
  • the timing of transmitting the PUSCH may be dynamically set (or switched or changed) depending on the TB scaling factor of the PDSCH.
  • the time resource interval between the PDSCH for RAR and the PUSCH for Msg 3 may differ depending on the TB scaling factor of the PDSCH.
  • the terminal 200 may transmit a PUSCH in slot n+k when the TB scaling factor of the PDSCH placed in slot n is equal to or less than a threshold, and transmit a PUSCH in slot n+k' when the TB size of the PDSCH placed in slot n is greater than a threshold.
  • the terminal 200 can appropriately transmit Msg 3 at a timing according to the data size of the RAR (e.g., the TB scaling factor).
  • the minimum time interval (m) may be set to a time interval between the PDSCH and the PUSCH that takes into consideration the case where the TB scaling factor set in the PDSCH is equal to or less than a threshold.
  • the minimum time interval (m) may be set to the minimum time interval between the PDSCH and the PUSCH when the TB scaling factor of the PDSCH is equal to or less than 0.5.
  • multiple setting value candidates are defined for the minimum time interval (m), and one of the multiple setting value candidates may be set for the terminal 200 depending on the TB scaling factor set in the PDSCH, for example.
  • the above describes an example of the operation of the base station 100 and the terminal 200.
  • base station 100 transmits a PDSCH for RAR, and receives a PUSCH for Msg 3 after transmitting the PDSCH for RAR.
  • terminal 200 receives a PDSCH for RAR, and transmits a PUSCH for Msg 3 after receiving the PDSCH for RAR.
  • the transmission timing of the PUSCH for Msg 3 differs depending on a parameter related to the resource size of the PDSCH for RAR (e.g., TB scaling factor).
  • the eRedCap terminal can transmit Msg 3 at an appropriate timing according to the processing capability of the eRedCap terminal (e.g., the receiving processing capability of RAR) depending on, for example, the data size of the PDSCH for RAR. Therefore, according to this embodiment, the transmission timing of the uplink in the terminal 200 can be appropriately set.
  • the processing capability of the eRedCap terminal e.g., the receiving processing capability of RAR
  • the transmission timing of the uplink in the terminal 200 can be appropriately set.
  • the TB scaling factor (e.g., a threshold value) that is the basis for determining the timing of transmitting the PUSCH may be determined according to the characteristics or capabilities of the eRedCap terminal.
  • the base station 100 may apply the above-mentioned operation based on the data size of the RAR when the base station 100 permits a connection from an eRedCap terminal in the cell of the base station 100.
  • the transmission timing setting of the PUSCH for Msg 3 according to the parameters related to the data size of the RAR may be applied when the cell permits access from an eRedCap terminal (for example, a terminal with limited capability). That is, when the base station 100 prohibits a connection from an eRedCap terminal in the cell of the base station 100, the base station 100 may not apply the transmission timing setting of the PUSCH for Msg 3 according to the parameters related to the data size of the RAR.
  • the transmission timing setting of the PUSCH for Msg 3 according to the parameters related to the data size of the RAR described above may be applied to the PDSCH and PUSCH assigned to a terminal 200 that the base station 100 considers (recognizes) to be an eRedCap terminal.
  • the transmission timing setting of the PUSCH for Msg 3 according to the parameters related to the data size of the RAR described above may not be applied to the PDSCH and PUSCH assigned to a terminal 200 that the base station 100 does not consider to be an eRedCap terminal.
  • Whether or not a terminal 200 is considered by the base station 100 to be an eRedCap terminal can be determined, for example, based on whether or not the terminal 200 has already reported its capability to the base station 100 by a capability report or early indication (e.g., a PRACH transmitted under specific conditions, or an Msg 3 containing specific information).
  • a capability report or early indication e.g., a PRACH transmitted under specific conditions, or an Msg 3 containing specific information.
  • the values of parameters related to RAR data size may be set (scheduled) to values smaller than a threshold, and may not be set to values equal to or greater than the threshold.
  • the RAR data size is more easily set to a size that corresponds to the processing capabilities of the eRedCap terminal, so the RAR processing time can be shortened even on an eRedCap terminal, and the timing of transmitting the PUSCH for Msg3 can be advanced.
  • parameters related to data size In the above-mentioned embodiments, the number of PRBs, the TB size, and the TB scaling factor are described as examples of parameters related to data size, but the parameters related to data size may be other parameters different from these.
  • the parameters related to data size may be the modulation multi-level number, the code rate, the number of resource elements (RE), the number of transmission layers, or the amount of overhead of a control signal or a reference signal.
  • PRB Physical Resource Block
  • CRB Common Resource Block
  • the number of PRBs corresponding to the characteristics that the eRedCap terminal can support has been described as "a number of PRBs equivalent to 5 MHz," but the frequency bandwidth is not limited to 5 MHz and may be other bandwidths. Also, for the "number of PRBs equivalent to 5 MHz,” the maximum number of PRBs when the SCS is 30 kHz is described as 11, and the maximum number of PRBs when the SCS is 15 kHz is described as 25, but the maximum number of PRBs corresponding to the "number of PRBs equivalent to 5 MHz" in each SCS is not limited to these values and may be other values. Also, the SCS is not limited to 15 kHz and 30 kHz, and may be other values.
  • TB size and TB scaling factor values are merely examples, and other values may be used.
  • the PRBs in the PDSCH may be arranged contiguously in frequency or non-contiguously in frequency.
  • a combination of a PDSCH for RAR and a PUSCH for Msg3 has been described, but the downlink channel is not limited to the PDSCH for RAR and may be another downlink channel or signal, and the uplink channel is not limited to the PUSCH for Msg 3 and may be another uplink channel or signal. Also, the combination of the downlink channel and the uplink channel may be another combination.
  • each of the above embodiments may be applied to the following combinations of channels or signals: PDSCH and PRACH for RAR (for example, PRACH may be a signal transmitted when reception of PDSCH fails)
  • PDSCH and PUCCH for example, PUCCH may be a channel used to transmit ACK/NACK for PDSCH
  • PUSCH for example, PUSCH may be a channel assigned by PDCCH
  • SRS Sounding Reference Signal
  • a minimum time interval (m') between a PDSCH and a PUCCH may be set when the sum of parameter values related to the data size (e.g., number of PRBs, TB size, or TB scaling factor) of multiple (e.g., two) PDSCHs (e.g., a unicast PDSCH and a broadcast PDSCH, or two broadcast PDSCHs) assigned to terminal 200 at the same time (e.g., symbol or slot) is greater than a threshold.
  • the two PDSCHs and PUCCHs may be assigned such that the time interval between the two PDSCHs and PUCCHs is greater than m'.
  • a combination of a downlink channel (e.g., PDSCH) and an uplink channel (e.g., PUSCH) is described, but this is not limited thereto, and may be, for example, a combination of an uplink channel and a downlink channel, or a combination including a sidelink channel.
  • the values of the parameters (e.g., k, k', m, or m') used in each of the above embodiments may be predefined in a standard, or may be notified to the terminal 200 by a control signal or the like. Also, the values of the parameters (e.g., k, k', m, or m') may be different depending on the processing capability (e.g., 1 or 2), or may be uniquely determined regardless of the processing capability.
  • PDSCH or PUSCH resources are allocated by PDCCH, but this is not limiting, and for example, resources may be set by a higher layer signal.
  • the above embodiment may be applied to, for example, an "eRedCap terminal", a RedCap terminal, or a non-eRedCap terminal, or may be applied to other types of terminals.
  • the characteristic (e.g., characteristic, attribute, or capability) of an eRedCap terminal is that the maximum frequency allocation size (e.g., frequency bandwidth or number of PRBs) supported is below a threshold value.
  • the eRedCap terminal may be, for example, a terminal having at least one of the following characteristics.
  • an uplink channel such as PRACH and PUSCH, or an uplink signal such as a Sounding Reference Signal (SRS) may be used for the above notification (report).
  • SRS Sounding Reference Signal
  • uplink channels such as PRACH and PUSCH, or uplink signals such as UCI or SRS may be used for the above report.
  • a threshold e.g., 5 MHz or less.
  • - A terminal capable of transmitting and receiving signals in a frequency band below a threshold e.g. Frequency Range 1 (FR1) or band below 6 GHz).
  • FR1 Frequency Range 1
  • - A terminal whose processing time is greater than the threshold.
  • a terminal whose available transport block size (TBS) is below a threshold.
  • a terminal whose available transmission rank number (e.g., number of MIMO transmission layers) is below a threshold.
  • - A terminal whose available modulation order is below a threshold.
  • HARQ Hybrid Automatic Repeat reQuest
  • the parameters corresponding to the eRedCap terminal may include, for example, a parameter such as a Subscriber Profile ID for RAT/Frequency Priority (SPID).
  • SPID Subscriber Profile ID for RAT/Frequency Priority
  • non-eRedCap terminal or “non-eRedCap terminal” may refer to, for example, a terminal that supports Rel-15/16/17 (e.g., a terminal that does not support Rel-18), or a terminal that supports Rel-18 but does not have the above characteristics.
  • (supplement) Information indicating whether terminal 200 supports the functions, operations or processes described in the above-mentioned embodiments may be transmitted (or notified) from terminal 200 to base station 100, for example, as capability information or capability parameters of terminal 200.
  • the capability information may include information elements (IEs) that individually indicate whether the terminal 200 supports at least one of the functions, operations, or processes shown in the above-described embodiments.
  • the capability information may include information elements that indicate whether the terminal 200 supports a combination of any two or more of the functions, operations, or processes shown in each of the above-described embodiments, each of the modified examples, and each of the supplementary notes.
  • the base station 100 may, for example, determine (or decide or assume) the functions, operations, or processing that the terminal 200 that transmitted the capability information supports (or does not support). The base station 100 may perform operations, processing, or control according to the results of the determination based on the capability information. For example, the base station 100 may control the uplink resources to be assigned to the terminal based on the capability information received from the terminal 200.
  • the terminal 200 does not support some of the functions, operations, or processes described in the above-described embodiment may be interpreted as the fact that such some of the functions, operations, or processes are restricted in the terminal 200. For example, information or requests regarding such restrictions may be notified to the base station 100.
  • the 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 base station 100 in association with information already known at the base station 100 or information transmitted to the base station 100.
  • a downlink control signal (or downlink control information) related to an embodiment of the present disclosure may be, for example, a signal (or information) transmitted in a Physical Downlink Control Channel (PDCCH) in a physical layer, or a signal (or information) transmitted in a Medium Access Control Control Element (MAC CE) or Radio Resource Control (RRC) in a higher layer.
  • the signal (or information) is not limited to being notified by a downlink control signal, and may be predefined in a specification (or standard), or may be preconfigured in a base station and a terminal.
  • the PDCCH may also be transmitted, for example, in either the Common Search Space (CSS) or the UE Specific Search Space (USS).
  • CSS Common Search Space
  • USS UE Specific Search Space
  • the base station may be a Transmission Reception Point (TRP), a cluster head, an access point, a Remote Radio Head (RRH), an eNodeB (eNB), a gNodeB (gNB), a Base Station (BS), a Base Transceiver Station (BTS), a parent device, a gateway, or the like.
  • TRP Transmission Reception Point
  • RRH Remote Radio Head
  • eNB eNodeB
  • gNB gNodeB
  • BS Base Station
  • BTS Base Transceiver Station
  • a terminal may play the role of a base station.
  • a relay device that relays communication between an upper node and a terminal may be used.
  • a roadside unit may be used.
  • An embodiment of the present disclosure may be applied to, for example, any of an uplink, a downlink, and a sidelink.
  • an embodiment of the present disclosure may be applied to a Physical Uplink Shared Channel (PUSCH), a Physical Uplink Control Channel (PUCCH), a Physical Random Access Channel (PRACH) in the uplink, a Physical Downlink Shared Channel (PDSCH), a PDCCH, a Physical Broadcast Channel (PBCH) in the downlink, or a Physical Sidelink Shared Channel (PSSCH), a Physical Sidelink Control Channel (PSCCH), or a Physical Sidelink Broadcast Channel (PSBCH) in the sidelink.
  • PUSCH Physical Uplink Shared Channel
  • PUCCH Physical Uplink Control Channel
  • PRACH Physical Random Access Channel
  • PDSCH Physical Downlink Shared Channel
  • PDCCH Physical Broadcast Channel
  • PBCH Physical Broadcast Channel
  • PSSCH Physical Sidelink Shared Channel
  • PSCCH Physical Sidelink Control Channel
  • PSBCH Physical Sidelink Broadcast Channel
  • PDCCH, PDSCH, PUSCH, and PUCCH are examples of a downlink control channel, a downlink data channel, an uplink data channel, and an uplink control channel, respectively.
  • PSCCH and PSSCH are examples of a sidelink control channel and a sidelink data channel.
  • PBCH and PSBCH are examples of a broadcast channel, and PRACH is an example of a random access channel.
  • An embodiment of the present disclosure may be applied to, for example, any of a data channel and a control channel.
  • the channel in an embodiment of the present disclosure may be replaced with any of the data channels PDSCH, PUSCH, and PSSCH, or the control channels PDCCH, PUCCH, PBCH, PSCCH, and PSBCH.
  • the reference signal is, for example, a signal known by both the base station and the terminal, and may be referred to as a Reference Signal (RS) or a pilot signal.
  • the reference signal may be any of a Demodulation Reference Signal (DMRS), a Channel State Information - Reference Signal (CSI-RS), a Tracking Reference Signal (TRS), a Phase Tracking Reference Signal (PTRS), a Cell-specific Reference Signal (CRS), or a Sounding Reference Signal (SRS).
  • DMRS Demodulation Reference Signal
  • CSI-RS Channel State Information - Reference Signal
  • TRS Tracking Reference Signal
  • PTRS Phase Tracking Reference Signal
  • CRS Cell-specific Reference Signal
  • SRS Sounding Reference Signal
  • the unit of time resource is not limited to one or a combination of slots and symbols, but may be, for example, a time resource unit such as a frame, a superframe, a subframe, a slot, a time slot, a subslot, a minislot, a symbol, an Orthogonal Frequency Division Multiplexing (OFDM) symbol, a Single Carrier - Frequency Division Multiplexing (SC-FDMA) symbol, or another time resource unit.
  • OFDM Orthogonal Frequency Division Multiplexing
  • SC-FDMA Single Carrier - Frequency Division Multiplexing
  • the number of symbols included in one slot is not limited to the number of symbols exemplified in the above embodiment, and may be another number of symbols.
  • An embodiment of the present disclosure may be applied to both licensed and unlicensed spectrums (unlicensed spectrum, shared spectrum).
  • a channel access procedure (Listen Before Talk (LBT), carrier sense, Channel Clear Assessment (CCA)) may be performed before each signal transmission.
  • LBT List Before Talk
  • CCA Channel Clear Assessment
  • An embodiment of the present disclosure may be applied to any of communication between a base station and a terminal (Uu link communication), communication between terminals (Sidelink communication), and communication of Vehicle to Everything (V2X).
  • the PDCCH in an embodiment of the present disclosure may be replaced with a PSCCH, the PUSCH/PDSCH with a PSSCH, the PUCCH with a Physical Sidelink Feedback Channel (PSFCH), and the PBCH with a PSBCH.
  • an embodiment of the present disclosure may be applied to either a terrestrial network or a non-terrestrial network (NTN: Non-Terrestrial Network) using a satellite or a High Altitude Pseudo Satellite (HAPS: High Altitude Pseudo Satellite).
  • NTN Non-Terrestrial Network
  • HAPS High Altitude Pseudo Satellite
  • an embodiment of the present disclosure may be applied to a terrestrial network in which the transmission delay is large compared to the symbol length or slot length, such as a network with a large cell size or an ultra-wideband transmission network.
  • an antenna port refers to a logical antenna (antenna group) consisting of one or more physical antennas.
  • an antenna port does not necessarily refer to one physical antenna, but may refer to an array antenna consisting of multiple antennas.
  • an antenna port may be defined as the minimum unit by which a terminal station can transmit a reference signal, without specifying how many physical antennas the antenna port is composed of.
  • an antenna port may be defined as the minimum unit by which a weighting of a precoding vector is multiplied.
  • 5G fifth generation of mobile phone technology
  • NR radio access technology
  • the system architecture as a whole assumes an NG-RAN (Next Generation - Radio Access Network) comprising gNBs.
  • the gNBs provide the UE-side termination of the NG radio access user plane (SDAP/PDCP/RLC/MAC/PHY) and control plane (RRC) protocols.
  • the gNBs are connected to each other via an Xn interface.
  • the gNBs are also connected to the Next Generation Core (NGC) via a Next Generation (NG) interface, more specifically to the Access and Mobility Management Function (AMF) (e.g., a specific core entity performing AMF) via an NG-C interface, and to the User Plane Function (UPF) (e.g., a specific core entity performing UPF) via an NG-U interface.
  • the NG-RAN architecture is shown in Figure 6 (see, for example, 3GPP TS 38.300 v15.6.0, section 4).
  • the NR user plane protocol stack includes the PDCP (Packet Data Convergence Protocol (see, for example, TS 38.300, section 6.4)) sublayer, the RLC (Radio Link Control (see, for example, TS 38.300, section 6.3)) sublayer, and the MAC (Medium Access Control (see, for example, TS 38.300, section 6.2)) sublayer, which are terminated on the network side at the gNB.
  • PDCP Packet Data Convergence Protocol
  • RLC Radio Link Control
  • MAC Medium Access Control
  • SDAP Service Data Adaptation Protocol
  • a control plane protocol stack is also defined for NR (see, for example, TS 38.300, section 4.4.2).
  • An overview of Layer 2 functions is given in clause 6 of TS 38.300.
  • the functions of the PDCP sublayer, RLC sublayer, and MAC sublayer are listed in clauses 6.4, 6.3, and 6.2 of TS 38.300, respectively.
  • the functions of the RRC layer are listed in clause 7 of TS 38.300.
  • the Medium-Access-Control layer handles multiplexing of logical channels and scheduling and scheduling-related functions, including handling various numerologies.
  • the physical layer is responsible for coding, PHY HARQ processing, modulation, multi-antenna processing, and mapping of signals to appropriate physical time-frequency resources.
  • the physical layer also handles the mapping of transport channels to physical channels.
  • the physical layer provides services to the MAC layer in the form of transport channels.
  • a physical channel corresponds to a set of time-frequency resources used for the transmission of a particular transport channel, and each transport channel is mapped to a corresponding physical channel.
  • the physical channels include the PRACH (Physical Random Access Channel), PUSCH (Physical Uplink Shared Channel), and PUCCH (Physical Uplink Control Channel) as uplink physical channels, and the PDSCH (Physical Downlink Shared Channel), PDCCH (Physical Downlink Control Channel), and PBCH (Physical Broadcast Channel) as downlink physical channels.
  • PRACH Physical Random Access Channel
  • PUSCH Physical Uplink Shared Channel
  • PUCCH Physical Uplink Control Channel
  • PDSCH Physical Downlink Shared Channel
  • PDCCH Physical Downlink Control Channel
  • PBCH Physical Broadcast Channel
  • NR use cases/deployment scenarios may include enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), and massive machine type communication (mMTC), which have diverse requirements in terms of data rate, latency, and coverage.
  • eMBB enhanced mobile broadband
  • URLLC ultra-reliable low-latency communications
  • mMTC massive machine type communication
  • eMBB is expected to support peak data rates (20 Gbps in the downlink and 10 Gbps in the uplink) and effective (user-experienced) data rates that are about three times higher than the data rates offered by IMT-Advanced.
  • URLLC stricter requirements are imposed on ultra-low latency (0.5 ms for user plane latency in UL and DL, respectively) and high reliability (1-10-5 within 1 ms).
  • mMTC may require preferably high connection density (1,000,000 devices/km 2 in urban environments), wide coverage in adverse environments, and extremely long battery life (15 years) for low-cost devices.
  • OFDM numerology e.g., subcarrier spacing, OFDM symbol length, cyclic prefix (CP) length, number of symbols per scheduling interval
  • OFDM numerology e.g., subcarrier spacing, OFDM symbol length, cyclic prefix (CP) length, number of symbols per scheduling interval
  • low latency services may preferably require a shorter symbol length (and therefore a larger subcarrier spacing) and/or fewer symbols per scheduling interval (also called TTI) than mMTC services.
  • deployment scenarios with large channel delay spreads may preferably require a longer CP length than scenarios with short delay spreads.
  • Subcarrier spacing may be optimized accordingly to maintain similar CP overhead.
  • NR may support one or more subcarrier spacing values. Correspondingly, subcarrier spacings of 15 kHz, 30 kHz, 60 kHz... are currently considered.
  • a resource grid of subcarriers and OFDM symbols is defined for the uplink and downlink, respectively.
  • Each element of the resource grid is called a resource element and is identified based on a frequency index in the frequency domain and a symbol position in the time domain (see 3GPP TS 38.211 v15.6.0).
  • Figure 7 shows the functional separation between NG-RAN and 5GC.
  • the logical nodes of NG-RAN are gNB or ng-eNB.
  • 5GC has logical nodes AMF, UPF, and SMF.
  • gNBs and ng-eNBs host the following main functions: - Radio Resource Management functions such as Radio Bearer Control, Radio Admission Control, Connection Mobility Control, dynamic allocation (scheduling) of resources to UEs in both uplink and downlink; - IP header compression, encryption and integrity protection of the data; - Selection of an AMF at UE attach time when routing to an AMF cannot be determined from information provided by the UE; - Routing of user plane data towards the UPF; - Routing of control plane information towards the AMF; - Setting up and tearing down connections; - scheduling and transmission of paging messages; Scheduling and transmission of system broadcast information (AMF or Operation, Admission, Maintenance (OAM) origin); - configuration of measurements and measurement reporting for mobility and scheduling; - Transport level packet marking in the uplink; - Session management; - Support for network slicing; - Management of QoS flows and mapping to data radio bearers; - Support for UEs in RRC_INACTIVE state; - NAS
  • the Access and Mobility Management Function hosts the following main functions: – Ability to terminate Non-Access Stratum (NAS) signalling; - NAS signalling security; - Access Stratum (AS) security control; - Core Network (CN) inter-node signaling for mobility between 3GPP access networks; - Reachability to idle mode UEs (including control and execution of paging retransmissions); - Managing the registration area; - Support for intra-system and inter-system mobility; - Access authentication; - Access authorization, including checking roaming privileges; - Mobility management control (subscription and policy); - Support for network slicing; – Selection of Session Management Function (SMF).
  • NAS Non-Access Stratum
  • AS Access Stratum
  • CN Core Network
  • the User Plane Function hosts the following main functions: - anchor point for intra/inter-RAT mobility (if applicable); - external PDU (Protocol Data Unit) Session Points for interconnection with data networks; - Packet routing and forwarding; - Packet inspection and policy rule enforcement for the user plane part; - Traffic usage reporting; - an uplink classifier to support routing of traffic flows to the data network; - Branching Point to support multi-homed PDU sessions; QoS processing for the user plane (e.g. packet filtering, gating, UL/DL rate enforcement); - Uplink traffic validation (mapping of SDF to QoS flows); - Downlink packet buffering and downlink data notification triggering.
  • PDU Protocol Data Unit Session Points for interconnection with data networks
  • Packet routing and forwarding Packet inspection and policy rule enforcement for the user plane part
  • Traffic usage reporting - an uplink classifier to support routing of traffic flows to the data network
  • - Branching Point to support multi-homed PDU
  • Session Management Function hosts the following main functions: - Session management; - Allocation and management of IP addresses for UEs; - Selection and control of UPF; - configuration of traffic steering in the User Plane Function (UPF) to route traffic to the appropriate destination; - Control policy enforcement and QoS; - Notification of downlink data.
  • Figure 8 shows some of the interactions between the UE, gNB, and AMF (5GC entities) when the UE transitions from RRC_IDLE to RRC_CONNECTED in the NAS portion (see TS 38.300 v15.6.0).
  • RRC is a higher layer signaling (protocol) used for UE and gNB configuration.
  • the AMF prepares UE context data (which includes, for example, PDU session context, security keys, UE Radio Capability, UE Security Capabilities, etc.) and sends it to the gNB with an INITIAL CONTEXT SETUP REQUEST.
  • the gNB then activates AS security together with the UE. This is done by the gNB sending a SecurityModeCommand message to the UE and the UE responding with a SecurityModeComplete message to the gNB.
  • the gNB then performs reconfiguration to set up Signaling Radio Bearer 2 (SRB2) and Data Radio Bearer (DRB) by sending an RRCReconfiguration message to the UE and receiving an RRCReconfigurationComplete from the UE.
  • SRB2 Signaling Radio Bearer 2
  • DRB Data Radio Bearer
  • the steps related to RRCReconfiguration are omitted since SRB2 and DRB are not set up.
  • the gNB informs the AMF that the setup procedure is complete with an INITIAL CONTEXT SETUP RESPONSE.
  • a 5th Generation Core (5GC) entity e.g., AMF, SMF, etc.
  • a control circuit that, during operation, establishes a Next Generation (NG) connection with a gNodeB
  • a transmitter that, during operation, transmits an initial context setup message to the gNodeB via the NG connection such that a signaling radio bearer between the gNodeB and a user equipment (UE) is set up.
  • the gNodeB transmits Radio Resource Control (RRC) signaling including a resource allocation configuration information element (IE) to the UE via the signaling radio bearer.
  • RRC Radio Resource Control
  • IE resource allocation configuration information element
  • Figure 9 shows some of the use cases for 5G NR.
  • the 3rd generation partnership project new radio (3GPP NR) considers three use cases that were envisioned by IMT-2020 to support a wide variety of services and applications.
  • the first phase of specifications for enhanced mobile-broadband (eMBB) has been completed.
  • Current and future work includes standardization for ultra-reliable and low-latency communications (URLLC) and massive machine-type communications (mMTC), in addition to expanding support for eMBB.
  • Figure 9 shows some examples of envisioned usage scenarios for IMT beyond 2020 (see, for example, ITU-R M.2083 Figure 2).
  • the URLLC use cases have stringent requirements for performance such as throughput, latency, and availability. It is envisioned as one of the enabling technologies for future applications such as wireless control of industrial or manufacturing processes, remote medical surgery, automation of power transmission and distribution in smart grids, and road safety.
  • URLLC's ultra-high reliability is supported by identifying technologies that meet the requirements set by TR 38.913.
  • key requirements include a target user plane latency of 0.5 ms for UL (uplink) and 0.5 ms for DL (downlink).
  • the overall URLLC requirement for a single packet transmission is a block error rate (BLER) of 1E-5 for a packet size of 32 bytes with a user plane latency of 1 ms.
  • BLER block error rate
  • NR URLLC can be improved in many possible ways.
  • Current room for reliability improvement includes defining a separate CQI table for URLLC, more compact DCI formats, PDCCH repetition, etc.
  • this room can be expanded to achieve ultra-high reliability as NR becomes more stable and more developed (with respect to the key requirements of NR URLLC).
  • Specific use cases for NR URLLC in Release 15 include Augmented Reality/Virtual Reality (AR/VR), e-health, e-safety, and mission-critical applications.
  • AR/VR Augmented Reality/Virtual Reality
  • e-health e-safety
  • mission-critical applications mission-critical applications.
  • the technology enhancements targeted by NR URLLC aim to improve latency and reliability.
  • Technology enhancements for improving latency include configurable numerology, non-slot-based scheduling with flexible mapping, grant-free (configured grant) uplink, slot-level repetition in data channel, and pre-emption in downlink.
  • Pre-emption means that a transmission for which resources have already been allocated is stopped and the already allocated resources are used for other transmissions with lower latency/higher priority requirements that are requested later. Thus, a transmission that was already allowed is preempted by a later transmission. Pre-emption is applicable regardless of the specific service type. For example, a transmission of service type A (URLLC) may be preempted by a transmission of service type B (eMBB, etc.).
  • Technology enhancements for improving reliability include a dedicated CQI/MCS table for a target BLER of 1E-5.
  • the mMTC (massive machine type communication) use case is characterized by a very large number of connected devices transmitting relatively small amounts of data that are typically not sensitive to latency.
  • the devices are required to be low cost and have very long battery life. From an NR perspective, utilizing very narrow bandwidth portions is one solution that saves power from the UE's perspective and allows for long battery life.
  • the scope of reliability improvement in NR is expected to be broader.
  • One of the key requirements for all cases, e.g. for URLLC and mMTC, is high or ultra-high reliability.
  • Several mechanisms can improve reliability from a radio perspective and a network perspective.
  • these areas include compact control channel information, data channel/control channel repetition, and diversity in frequency, time, and/or spatial domains. These areas are generally applicable to reliability improvement regardless of the specific communication scenario.
  • NR URLLC For NR URLLC, further use cases with more demanding requirements are envisaged, such as factory automation, transportation and power distribution.
  • the demanding requirements are high reliability (up to 10-6 level of reliability), high availability, packet size up to 256 bytes, time synchronization up to a few ⁇ s (depending on the use case, the value can be 1 ⁇ s or a few ⁇ s depending on the frequency range and low latency of 0.5 ms to 1 ms (e.g. 0.5 ms latency at the targeted user plane).
  • NR URLLC there may be several technology enhancements from a physical layer perspective. These include PDCCH (Physical Downlink Control Channel) enhancements for compact DCI, PDCCH repetition, and increased monitoring of PDCCH. Also, UCI (Uplink Control Information) enhancements related to enhanced HARQ (Hybrid Automatic Repeat Request) and CSI feedback enhancements. There may also be PUSCH enhancements related to minislot level hopping, and retransmission/repetition enhancements.
  • minislot refers to a Transmission Time Interval (TTI) that contains fewer symbols than a slot (a slot comprises 14 symbols).
  • TTI Transmission Time Interval
  • QoS Quality of Service
  • the 5G Quality of Service (QoS) model is based on QoS flows and supports both QoS flows that require a guaranteed flow bit rate (GBR QoS flows) and QoS flows that do not require a guaranteed flow bit rate (non-GBR QoS flows).
  • GRR QoS flows Guarantee flow bit rate
  • non-GBR QoS flows QoS flows that do not require a guaranteed flow bit rate
  • QoS flows are the finest granularity of QoS partitioning in a PDU session.
  • QoS flows are identified within a PDU session by a QoS Flow ID (QFI) carried in the encapsulation header over the NG-U interface.
  • QFI QoS Flow ID
  • 5GC For each UE, 5GC establishes one or more PDU sessions. For each UE, the NG-RAN establishes at least one Data Radio Bearer (DRB) for the PDU session, e.g. as shown above with reference to Figure 8. Additional DRBs for the QoS flows of the PDU session can be configured later (when it is up to the NG-RAN).
  • DRB Data Radio Bearer
  • the NG-RAN maps packets belonging to different PDU sessions to different DRBs.
  • the NAS level packet filters in the UE and 5GC associate UL and DL packets with QoS flows, whereas the AS level mapping rules in the UE and NG-RAN associate UL and DL QoS flows with DRBs.
  • FIG 10 shows the non-roaming reference architecture for 5G NR (see TS 23.501 v16.1.0, section 4.23).
  • An Application Function e.g. an external application server hosting 5G services as illustrated in Figure 9
  • AF Application Function
  • NEF Network Exposure Function
  • PCF Policy Control Function
  • Application Functions that are considered trusted by the operator can interact directly with the relevant Network Functions.
  • Application Functions that are not allowed by the operator to access the Network Functions directly interact with the relevant Network Functions using an external exposure framework via the NEF.
  • Figure 10 further illustrates further functional units of the 5G architecture, namely Network Slice Selection Function (NSSF), Network Repository Function (NRF), Unified Data Management (UDM), Authentication Server Function (AUSF), Access and Mobility Management Function (AMF), Session Management Function (SMF), and Data Network (DN, e.g. operator provided services, Internet access, or third party provided services). All or part of the core network functions and application services may be deployed and run in a cloud computing environment.
  • NSF Network Slice Selection Function
  • NRF Network Repository Function
  • UDM Unified Data Management
  • AUSF Authentication Server Function
  • AMF Access and Mobility Management Function
  • SMSF Session Management Function
  • DN Data Network
  • All or part of the core network functions and application services may be deployed and run in a cloud computing environment.
  • an application server e.g., an AF in a 5G architecture
  • a transmitter that, in operation, transmits a request including QoS requirements for at least one of a URLLC service, an eMMB service, and an mMTC service to at least one of 5GC functions (e.g., a NEF, an AMF, an SMF, a PCF, an UPF, etc.) to establish a PDU session including a radio bearer between a gNodeB and a UE according to the QoS requirements; and a control circuit that, in operation, performs a service using the established PDU session.
  • 5GC functions e.g., a NEF, an AMF, an SMF, a PCF, an UPF, etc.
  • the parameter values such as the number of RBs, frequency bandwidth, and SCS are merely examples and may be other values.
  • Each functional block used in the description of the above embodiment may be realized partially or entirely as an LSI, which is an integrated circuit, and each process described in the above embodiment may be controlled partially or entirely by one LSI or a combination of LSIs.
  • the LSI may be composed of individual chips, or may be composed of one chip so as to include some or all of the functional blocks.
  • the LSI may have data input and output.
  • the LSI may be called an IC, a system LSI, a super LSI, or an ultra LSI.
  • the method of integration is not limited to LSI, and may be realized by a dedicated circuit, a general-purpose processor, or a dedicated processor.
  • a field programmable gate array that can be programmed after LSI manufacture, 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
  • the present disclosure may be realized as digital processing or analog processing.
  • an integrated circuit technology that can replace LSI appears due to advances in semiconductor technology or other derived technologies, it is natural that this technology can be used to integrate functional blocks. The application of biotechnology, etc. is also a possibility.
  • the present disclosure may be implemented in any type of apparatus, device, or system (collectively referred to as a communications apparatus) having communications capabilities.
  • the communications apparatus may include a radio transceiver and processing/control circuitry.
  • the radio transceiver may include a receiver and a transmitter, or both as functions.
  • the radio transceiver (transmitter and 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 the like.
  • Non-limiting examples of communication devices include telephones (e.g., cell phones, smartphones, etc.), tablets, personal computers (PCs) (e.g., laptops, desktops, notebooks, etc.), cameras (e.g., digital still/video cameras), digital players (e.g., digital audio/video players, etc.), wearable devices (e.g., wearable cameras, smartwatches, tracking devices, etc.), game consoles, digital book readers, telehealth/telemedicine devices, communication-enabled vehicles or mobile transport (e.g., cars, planes, ships, etc.), and combinations of the above-mentioned devices.
  • telephones e.g., cell phones, smartphones, etc.
  • tablets personal computers (PCs) (e.g., laptops, desktops, notebooks, etc.)
  • cameras e.g., digital still/video cameras
  • digital players e.g., digital audio/video players, etc.
  • wearable devices e.g., wearable cameras, smartwatches, tracking
  • Communication devices are not limited to portable or mobile devices, but also include any type of equipment, device, or system that is non-portable or fixed, such as smart home devices (home appliances, lighting equipment, smart meters or measuring devices, control panels, etc.), vending machines, and any other "things” that may exist on an IoT (Internet of Things) network.
  • smart home devices home appliances, lighting equipment, smart meters or measuring devices, control panels, etc.
  • vending machines and any other “things” that may exist on an IoT (Internet of Things) network.
  • IoT Internet of Things
  • Communications include data communication via cellular systems, wireless LAN systems, communication satellite systems, etc., as well as data communication via combinations of these.
  • the communication apparatus also includes devices such as controllers and sensors that are connected or coupled to a communication device that performs the communication functions described in this disclosure.
  • a communication device that performs the communication functions described in this disclosure.
  • controllers and sensors that generate control signals and data signals used by the communication device to perform the communication functions of the communication apparatus.
  • communication equipment includes infrastructure facilities, such as base stations, access points, and any other equipment, devices, or systems that communicate with or control the various non-limiting devices listed above.
  • a terminal includes a receiving circuit that receives a first signal and a transmitting circuit that transmits a second signal after receiving the first signal, and the transmission timing of the second signal varies depending on a parameter related to the resource size of the first signal.
  • a minimum time interval between the first signal and the second signal when the value of the parameter is greater than a threshold is set.
  • the interval of the time resource between the first signal and the second signal when the value of the parameter is greater than a threshold value is set to be greater than or equal to the minimum time interval.
  • the time resource interval between the first signal and the second signal is set to be shorter than the minimum time interval.
  • the time resource interval between the first signal and the second signal varies depending on the value of the parameter.
  • the parameters are at least one of the number of physical resource blocks (PRBs) assigned to the first signal, the transport block size (TB size) assigned to the first signal, and a TB scaling factor used to calculate the TB size assigned to the first signal.
  • PRBs physical resource blocks
  • TB size transport block size assigned to the first signal
  • TB scaling factor used to calculate the TB size assigned to the first signal.
  • the setting of the transmission timing according to the parameters is applied when the cell allows access by a terminal with restricted capabilities.
  • the setting of the transmission timing according to the parameters is applied to the first signal and the second signal that are assigned to a terminal that the base station regards as a terminal with limited capability.
  • the first signal is a signal on a downlink channel that transmits a random access response in a random access procedure
  • the second signal is a signal on an uplink channel that transmits Message 3 in the random access procedure.
  • a base station includes a transmitting circuit that transmits a first signal and a receiving circuit that receives a second signal after transmitting the first signal, and the timing of receiving the second signal varies depending on a parameter related to the resource size of the first signal.
  • a terminal receives a first signal and transmits a second signal after receiving the first signal, and the transmission timing of the second signal varies depending on a parameter related to a resource size of the first signal.
  • a base station transmits a first signal and receives a second signal after transmitting the first signal, and the timing of receiving the second signal varies depending on a parameter related to the resource size of the first signal.
  • An embodiment of the present disclosure is useful in wireless communication systems.
  • Base station 101 206 Control unit 102 DCI generation unit 103 RAR generation unit 104 Upper layer signal generation unit 105, 207 Coding and modulation unit 106, 208 Signal mapping unit 107, 209 Transmission unit 108, 201 Antenna 109, 202 Reception unit 110 Signal separation unit 111, 205 Demodulation and decoding unit 200 Terminal 203 Signal separation unit 204 DCI detection unit

Landscapes

  • Mobile Radio Communication Systems (AREA)

Abstract

端末は、第１の信号を受信する受信回路と、第１の信号を受信した後に第２の信号を送信する送信回路と、を具備し、第２の信号の送信タイミングは、第１の信号のリソースサイズに関するパラメータに応じて異なる。

Description

端末、基地局、及び、通信方法
　本開示は、端末、基地局、及び、通信方法に関する。
　第５世代移動通信システム（5G）と呼ばれる通信システムが検討されている。国際標準化団体である3rd Generation Partnership Project（3GPP）では、LTE／LTE-Advancedシステムの高度化と、LTE/LTE-Advancedシステムとは必ずしも後方互換性を有しない新しい方式であるNew Radio Access Technology（New RAT又はNRとも呼ぶ）（例えば、非特許文献１を参照）の両面から、5G通信システムの高度化が検討されている。
RP-181726, "Revised WID on New Radio Access Technology", NTT DOCOMO, September 2018 RP-213661, "New SID on Study on further NR RedCap UE complexity reduction", Ericsson, December 2021
　端末における上りリンクの送信タイミングの設定方法については検討の余地がある。
　本開示の非限定的な実施例は、端末における上りリンクの送信タイミングを適切に設定できる端末、基地局、及び、通信方法の提供に資する。
　本開示の一実施例に係る端末は、第１の信号を受信する受信回路と、前記第１の信号を受信した後に第２の信号を送信する送信回路と、を具備し、前記第２の信号の送信タイミングは、前記第１の信号のリソースサイズに関するパラメータに応じて異なる。
　なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
　本開示の一実施例によれば、端末における上りリンクの送信タイミングを適切に設定できる。
　本開示の一実施例における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および／または効果は、いくつかの実施形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、１つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。
基地局の一部の構成例を示すブロック図 端末の一部の構成例を示すブロック図 基地局の構成例を示すブロック図 端末の構成例を示すブロック図 基地局及び端末の動作例を示す図 3GPP NRシステムの例示的なアーキテクチャの図 NG-RANと5GCとの間の機能分離を示す概略図 Radio Resource Control(RRC)接続のセットアップ／再設定の手順のシーケンス図 大容量・高速通信（eMBB：enhanced Mobile BroadBand）、多数同時接続マシンタイプ通信（mMTC：massive Machine Type Communications）、および高信頼・超低遅延通信（URLLC：Ultra Reliable and Low Latency Communications）の利用シナリオを示す概略図 非ローミングシナリオのための例示的な5Gシステムアーキテクチャを示すブロック図
　以下、本開示の実施の形態について図面を参照して詳細に説明する。
　なお、以下の説明において、例えば、無線フレーム（frame）、スロット（slot）、シンボル（symbol）はそれぞれ時間領域の物理リソースの単位である。例えば、１フレームの長さは10ミリ秒でよい。例えば、１フレームは複数（例えば、10個、20個又は他の値）のスロットから構成されてよい。また、例えば、スロット長により、１フレームを構成するスロット数は可変となってよい。また、１スロットは、例えば、複数（例えば、14個又は12個）のシンボルから構成されてよい。例えば、１シンボルは時間領域における最小の物理リソース単位であり、サブキャリア間隔（SCS：subcarrier spacing）によってシンボル長が異なってよい。
　また、サブキャリア(subcarrier)、リソースブロック(RB：Resource Block)はそれぞれ周波数領域の物理リソースの単位である。例えば、1リソースブロックは12個のサブキャリアから構成されてよい。例えば、1サブキャリアは周波数領域における最小の物理リソース単位でよい。サブキャリア間隔は可変であり、例えば、15kHz、30kHz、60kHz、120kHz、240kHz、480kHz、960kHz、又は、他の値でよい。
　［evolved Reduced Capability NR Devicesについて］
　Release 18 NR（以下、Rel-18とも呼ぶ）では、evolved Reduced Capability NR Devices（eRedCap）と呼ばれる端末（例えば、移動局、又は、user equipment（UE））（例えば、eRedCap端末と呼ぶ）がサポートされる見込みである。eRedCap端末は、サポートする特性（例えば、capability）の制限により、例えば、製造コストの削減等を目指している。eRedCap端末がサポートし得る特性には、例えば、以下の例が挙げられる:
　或る時間あたりで受信処理可能なphysical resource block（PRB）数の最大値（例えば、各PRBが占有する周波数帯域幅の総和）が5MHz程度であること。例えば、
　－　サブキャリア間隔（SCS：subcarrier spacing）が15 kHzであるPRB数の最大値が25個程度、または、
　－　SCSが30 kHzであるPRB数の最大値が11個程度である。
　以下では、上記eRedCap端末がサポートし得る特性に対応するPRB数を、便宜上、「5 MHz相当のPRB数」と呼ぶ。
　ここで、Release 15/16/17（例えば、Rel-15/16/17とも呼ぶ）に対応する端末、及び、Rel-18に対応する端末であっても特性（capability）がeRedCap端末のcapabilityよりも大きい端末（又は、capabilityが制限されていない端末）を、eRedCap端末に対して、「非eRedCap端末」又は「non-eRedCap端末」と呼ぶ。例えば、Rel-17 RedCap端末もnon-eRedCap端末に含まれる。
　Rel-18をサポートするセルでは、eRedCap端末及び非eRedCap端末の両方が共存する可能性がある。
　以上、eRedCapについて説明した。
　基地局（例えば、gNBとも呼ぶ）は、リソースを割り当てる端末がeRedCap端末であるか否かを特定しない状況があり得る。この場合、割り当てリソースにおけるPRB数は、「5 MHz相当のPRB数」よりも多いことがあり得る。すなわち、基地局は、eRedCap端末がサポートし得る特性を超えるリソースを割り当てる場合があり得る。
　例えば、この状況は、初期アクセス（random access procedure）において、端末がMessage 2（又は、Random Access Response（RAR）又はMsg 2とも呼ぶ）の受信に用いるデータチャネル（例えば、PDSCH：Physical Downlink Shared Channel）、及び、端末がMessage 3（又は、Msg 3とも呼ぶ）の送信に用いるデータチャネル（例えば、PUSCH: Physical Uplink Shared Channel）のそれぞれのリソースの割り当ての際に起こり得る。
　例えば、RAR用のPDSCHの割り当てPRB数が「5 MHz相当のPRB数」よりも多い場合、eRedCap端末では、RARの受信処理の完了するタイミングが、基地局の想定より遅くなり、RARの受信処理がMsg 3が割り当てられるPUSCHの時間リソース（送信タイミング）までに完了しない可能性がある。このため、eRedCap端末は、RARによってスケジューリングされる時間リソース（送信タイミング）において、RARの受信処理の完了前にMsg 3を送信できない可能性がある。
　これに対して、例えば、RAR用のPDSCHの割り当てPRB数を「5 MHz相当のPRB数」以下に設定（又は、制限）する方法があり得る。この方法では、基地局は、RAR用のPDSCHリソースとして、「5 MHz相当のPRB数」より大きいリソースを割り当てない。これにより、eRedCap端末におけるRARの受信処理完了のタイミングが、基地局の想定より遅くなることを抑制し、eRedCap端末は、割り当てられるPUSCHの時間リソース（送信タイミング）においてMsg 3を適切に送信できる。
　その一方で、この方法では、非eRedCap端末に対するRAR用のPDSCHの割り当てPRB数も同様に「5 MHz相当のPRB数」以下に設定（又は、制限）されるため、「5 MHz相当のPRB数」より大きいリソース割り当てが可能な非eRedCap端末に対して、受信性能が劣化し得る。
　そこで、本開示の非限定的な実施例では、例えば、eRedCap端末と非eRedCap端末とが共存するセルにおいて、端末における上りリンクの送信タイミングを適切に設定する方法について説明する。
　［通信システムの概要］
　本実施の形態に係る通信システムは、基地局１００、及び、端末２００を備える。端末２００は、例えば、eRedCap端末でもよく、非eRedCap端末でもよい。
　図１は、本実施の形態に係る基地局１００の一部の構成例を示すブロック図である。図１に示す基地局１００において、送信部（例えば、送信回路に対応）は、第１の信号（例えば、RAR用のPDSCH）を送信し、受信部（例えば、受信回路に対応）は、第１の信号を送信した後に第２の信号（例えば、Msg 3用のPUSCH）を受信する。
　図２は、本実施の形態に係る端末２００の一部の構成例を示すブロック図である。図２に示す端末２００において、受信部（例えば、受信回路に対応）は、第１の信号（例えば、RAR用のPDSCH）を受信し、送信部（例えば、送信回路）は、第１の信号を受信した後に第２の信号（例えば、Msg 3用のPUSCH）を送信する。
　ここで、第２の信号（例えば、Msg 3用のPUSCH）の送信タイミングは、第１の信号（例えば、RAR用のPDSCH）のリソースサイズに関するパラメータ（例えば、PRB数、TBサイズ、又は、TB scaling factor）に応じて異なる。
　（実施の形態１）
　［基地局の構成］
　図３は、本実施の形態に係る基地局１００の構成例を示すブロック図である。図３において、基地局１００は、制御部１０１と、Downlink Control Information（DCI）生成部１０２と、RAR生成部１０３と、上位レイヤ信号生成部１０４と、符号化・変調部１０５と、信号配置部１０６と、送信部１０７と、アンテナ１０８と、受信部１０９と、信号分離部１１０と、復調・復号部１１１と、を有する。
　例えば、図３に示す送信部１０７及びアンテナ１０８の少なくとも一つは、図１に示す送信部に含まれてよい。また、例えば、図３に示すアンテナ１０８及び受信部１０９の少なくとも一つは、図１に示す受信部に含まれてよい。
　制御部１０１は、例えば、端末２００に対して割り当てるリソース（例えば、下りリンクリソース及び上りリンクリソースを含む）を決定してよい。
　例えば、制御部１０１は、決定したリソースに関する情報に基づいて、上位レイヤ信号（例えば、上位レイヤパラメータ又は上位レイヤシグナリングとも呼ぶ）の生成を上位レイヤ信号生成部１０４へ指示してもよい。また、制御部１０１は、例えば、決定したリソースに関する情報に基づいて、下りリンク制御チャネル（例えば、PDCCH）に含まれる制御情報（例えば、DCI）の生成をDCI生成部１０２に指示してよい。また、制御部１０１は、例えば、決定したリソースに関する情報に基づいて、ランダムアクセス手順（random access procedure）におけるRARの生成をRAR生成部１０３へ指示してよい。
　また、制御部１０１は、下りリンクリソースに関する情報を信号配置部１０６へ出力（又は、指示）し、上りリンクリソースに関する情報を信号分離部１１０へ出力（又は、指示）する。
　DCI生成部１０２は、例えば、制御部１０１からの指示に基づいて、DCIを生成し、生成したDCIを信号配置部１０６へ出力してよい。
　RAR生成部１０３は、例えば、制御部１０１からの指示に基づいて、RARを生成し、生成したRARを符号化・変調部１０５へ出力してよい。
　上位レイヤ信号生成部１０４は、例えば、制御部１０１からの指示に基づいて、システム情報といった上位レイヤ信号を生成し、生成した上位レイヤ信号を符号化・変調部１０５へ出力してよい。
　符号化・変調部１０５は、例えば、下りリンクデータ、RAR生成部１０３から入力されるRAR、及び、上位レイヤ信号生成部１０４から入力される上位レイヤ信号を、誤り訂正符号化及び変調し、変調後の信号を信号配置部１０６へ出力してよい。
　信号配置部１０６は、例えば、制御部１０１から入力される下りリンクリソースに関する情報に基づいて、DCI生成部１０２から入力されるDCI、及び、符号化・変調部１０５から入力される信号の少なくとも一つをリソースに配置してよい。例えば、信号配置部１０６は、符号化・変調部１０５から入力される信号をPDSCHリソースに配置し、DCIを下りリンク制御チャネル（例えば、PDCCH：Physical Downlink Control Channel）リソースに配置してよい。信号配置部１０６は、各リソースに配置された信号を送信部１０７へ出力する。
　送信部１０７は、例えば、信号配置部１０６から入力される信号に対して、搬送波を用いた周波数変換（例えば、アップコンバート）を含む無線送信処理を行い、無線送信処理後の信号をアンテナ１０８に出力する。
　アンテナ１０８は、例えば、送信部１０７から入力される信号（例えば、下り信号）を端末２００に向けて放射する。また、アンテナ１０８は、例えば、端末２００から送信された上り信号を受信し、受信部１０９に出力する。
　上り信号は、例えば、上りリンクデータチャネル（例えば、PUSCH）、上りリンク制御チャネル（例えば、PUCCH：Physical Uplink Control Channel）、又は、ランダムアクセスチャネル（例えば、PRACH：Physical Random Access Channel）といったチャネルの信号でもよい。
　受信部１０９は、例えば、アンテナ１０８から入力される信号に対して、周波数変換（例えば、ダウンコンバート）を含む無線受信処理を行い、無線受信処理後の信号を信号分離部１１０に出力する。
　信号分離部１１０は、例えば、制御部１０１から入力される上りリンクリソースに関する情報に基づいて、受信部１０９から入力される信号のうち、PUCCHリソース上の信号（例えば、UCI）、及び、PRACH上の信号（例えば、preamble）を抽出（又は、分離）する。また、信号分離部１１０は、例えば、受信部１０９から入力される信号のうち、PUSCHリソース上の信号を復調・復号部１１１へ出力する。
　復調・復号部１１１は、例えば、信号分離部１１０から入力される信号を復調及び復号して、上りリンクデータを出力する。
　［端末の構成］
　図４は、本実施の形態に係る端末２００の構成例を示すブロック図である。
　図４において、端末２００は、アンテナ２０１と、受信部２０２と、信号分離部２０３と、DCI検出部２０４と、復調・復号部２０５と、制御部２０６と、符号化・変調部２０７と、信号配置部２０８と、送信部２０９と、を有する。
　例えば、図４に示すアンテナ２０１及び受信部２０２の少なくとも一つは、図２に示す受信部に含まれてよい。また、例えば、図４に示すアンテナ２０１及び送信部２０９の少なくとも一つは、図２に示す送信部に含まれてよい。
　アンテナ２０１は、例えば、基地局１００が送信した下り信号（下りリンクチャネル）を受信し、受信部２０２に出力する。また、アンテナ２０１は、例えば、送信部２０９から入力される上り信号（上りリンクチャネル）を基地局１００に対して放射する。
　受信部２０２は、例えば、アンテナ２０１から入力される信号に対して、周波数変換（例えば、ダウンコンバート）を含む無線受信処理を行い、無線受信処理後の信号を信号分離部２０３に出力する。
　信号分離部２０３は、例えば、制御部２０６から入力される下りリンクリソースに関する情報に基づいて、受信部２０２から入力される信号のうち、PDCCHリソース上の信号を抽出（例えば、分離）し、DCI検出部２０４へ出力する。また、信号分離部２０３は、例えば、制御部２０６からの指示に基づいて、受信部２０２から入力される信号のうち、PDSCHリソース上の信号を復調・復号部２０５へ出力する。
　DCI検出部２０４は、例えば、信号分離部２０３から入力される信号（例えば、PDCCHリソース上の信号）から、DCIを検出してよい。DCI検出部２０４は、例えば、検出したDCIを制御部２０６へ出力してよい。
　復調・復号部２０５は、例えば、信号分離部２０３から入力される信号（例えば、PDSCHリソース上の信号）を復調及び誤り訂正復号して、下りリンクデータ、システム情報といった上位レイヤ信号、及び、RARの少なくとも一つを得る。復調・復号部２０５は、例えば、復号により得られた上位レイヤ信号及びRARを制御部２０６へ出力してよい。また、復調・復号部２０５は、例えば、復号により得られた下りリンクデータを出力してよい。
　制御部２０６は、例えば、DCI検出部２０４から入力されるDCI、及び、復調・復号部２０５から入力される上位レイヤ信号（例えば、システム情報）及びRARの少なくとも一つに基づいて、下りリンクリソース及び上りリンクリソースを決定（又は、特定）してよい。例えば、制御部２０６は、特定した下りリンクリソースに関する情報を信号分離部２０３に出力（例えば、指示）し、特定した上りリンクリソースに関する情報を信号配置部２０８に出力（例えば，指示）してよい。
　符号化・変調部２０７は、例えば、上りリンクデータ（例えば、Msg 3）に対して、符号化及び変調を行い、変調後の信号を信号配置部２０８へ出力してよい。
　信号配置部２０８は、例えば、制御部２０６から入力される上りリンクリソースに関する情報に基づいて、符号化・変調部２０７から入力される信号をPUSCHリソースに配置し、UCIをPUCCHリソースに配置し、preambleをPRACHリソースに配置してよい。信号配置部２０８は、各リソースに配置された信号を送信部２０９へ出力する。
　送信部２０９は、例えば、信号配置部２０８から入力される信号に周波数変換（例えば、アップコンバート）を含む無線送信処理を行い、無線送信処理後の信号をアンテナ２０１へ出力する。
　［基地局１００及び端末２００の動作例］
　次に、上述した基地局１００及び端末２００の動作例について説明する。
　本実施の形態では、RARのデータサイズに関するパラメータとして、RAR用のPDSCHに割り当てられるPRBサイズを用いる場合について説明する。
　例えば、RAR用のPDSCHの割り当てPRB数が閾値（例えば、「5 MHz相当のPRB数」）より大きい場合のRAR用のPDSCHと、Msg 3用のPUSCHとの間の最小時間間隔（例えば、「m'」)が設定されてよい。
　例えば、RAR用のPDSCHの割り当てPRB数が閾値（例えば、5 MHz相当のPRB数）よりも大きい場合、RAR用のPDSCHの時間リソースと、Msg 3用のPUSCHの時間リソースとの間隔は、最小時間間隔m'以上に設定されてよい。
　例えば、基地局１００は、RAR用のPDSCHの割り当てPRB数が閾値（例えば、5 MHz相当のPRB数）よりも大きい場合、RAR用のPDSCHの時間リソースとの間隔が最小時間間隔m'以上となるように、Msg 3用のPUSCHの時間リソースを決定してよい。
　また、例えば、端末２００は、RAR用のPDSCHの割り当てPRB数が閾値（例えば、5 MHz相当のPRB数）よりも大きい場合、RAR用のPDSCHの時間リソースとの間隔が最小時間間隔m'以上の間隔であるMsg 3（PUSCH）の送信（又は、スケジューリング、設定）を仮定（又は、予期、想定）してよい。または、端末２００は、例えば、RAR用のPDSCHの時間リソースとの間隔が最小時間間隔m'より短い間隔でのMsg 3（PUSCH）の送信（又は、スケジューリング、設定）を仮定（又は、予期、想定）しなくてよい。
　これにより、RARのデータサイズが大きい場合（例えば、PRB数が閾値より大きい場合）でも、端末２００（例えば、eRedCap端末）は、端末２００の処理能力に適したタイミングでMsg3を適切に送信できる。
　図５は、基地局１００（例えば、gNB）及び端末２００（例えば、UE）の処理の一例を示すフローチャートである。
　＜Ｓ１０１＞
　基地局１００は、例えば、RARのデータサイズに関するパラメータを決定する。RARのデータサイズに関するパラメータには、少なくとも、RARを送信するPDSCHに割り当てられるPRB数が含まれてよい。また、RARのデータサイズに関するパラメータには、例えば、RAR用のPDSCHに設定されるtransport block（TB）サイズ、及び、RAR用のPDSCHに設定されるTBサイズの決定に用いられるTB scaling factorの少なくとも一つが含まれてよい。
　＜Ｓ１０２＞
　基地局１００は、例えば、Ｓ１０１において決定したRARのデータサイズに関するパラメータ（例えば、PRB数）に基づいて、RAR用のPDSCHのリソース、及び、Msg 3用のPUSCHのリソースを決定する。
　例えば、PDSCHに割り当てられるPRB数が「5 MHz相当のPRB数」より大きい場合のPDSCHとPUSCHとの間の最小時間間隔（m'）が規定（又は、設定、定義）されてよい。
　この場合、基地局１００は、端末２００が「5 MHz相当のPRB数」より大きいPRB数を有するPDSCHの受信を完了するタイミング（例えば、シンボル、時刻、又は、時間単位）と、端末２００がPUSCH（例えば、Msg 3）の送信を開始するタイミング（例えば、シンボル、時刻、又は、時間単位）との間の間隔として、最小時間間隔（m'）が確保されるように、PDSCH及びPUSCHの各リソースを割り当ててよい。例えば、PDSCHの受信を完了するタイミングとPUSCHの送信を開始するタイミングとの間において、端末２００ではPDSCH（例えば、RAR）の受信処理が行われてよい。
　例えば、基地局１００は、「5 MHz相当のPRB数」より大きいPRB数を有するPDSCHをスロットnに割り当て、PUSCHをスロットn+k'に割り当ててもよい。ここで、例えば、k'の値（例えば、k'個のスロット長）は、PDSCHとPUSCHとの間隔がm'以上の間隔になるように設定されてよい（例えば、k'スロット＞m'）。基地局１００は、例えば、k'の値に関する情報を、Msg 3用のPUSCHのリソースに関する情報として決定してよい。
　なお、最小時間間隔（m’）には、例えば、PDSCHの割り当てPRB数が「5 MHz相当のPRB数」より大きい場合を考慮したPDSCHとPUSCHとの間の時間間隔が設定されてよい。例えば、最小時間間隔（m’）は、RAR用のPDSCHの割り当てPRB数が「5 MHz相当のPRB数」より大きい場合のeRedCap端末におけるRARの受信処理時間（又は、受信処理能力）に基づいて設定されてもよい。
　例えば、RAR用のPDSCHの割り当てPRB数が大きいほど、RARのデータサイズは大きく、eRedCap端末におけるRARの受信処理時間は長くなりやすい。そこで、一例として、最小時間間隔（m'）は、RAR用のPDSCHの割り当てPRB数の上限値に基づいて設定されてもよい。なお、最小時間間隔（m'）は、RAR用のPDSCHの割り当てPRB数の上限値に基づいて設定される場合に限定されず、RAR用の割り当てPRB数が採り得る値のうち何れかの値に基づいて設定されてもよい。
　また、例えば、最小時間間隔（m’）には、PDSCHの割り当てPRB数が20MHz相当以下である場合のPDSCHとPUSCHとの間の最小時間間隔が設定されてもよい。なお、最小時間間隔（m’）を設定する基準となるPRB数の値は20MHz相当のPRB数に限らず、他の周波数帯域幅相当のPRB数でもよい。
　また、例えば、最小時間間隔（m’）には、PDSCHの割り当てPRB数が或る範囲（例えば、5MHz相当のPRB数より多く、かつ、20MHz相当のPRB数以下の範囲）である場合のPDSCHとPUSCHとの間の最小時間間隔が設定されてもよい。なお、最小時間間隔（m’）を設定する基準となるPRB数の範囲は、5 MHz～20 MHz相当のPRB数の範囲に限らず、他の周波数帯域幅の範囲に対応するPRB数でもよい。
　また、最小時間間隔（m’）には複数の設定値の候補が規定され、例えば、PDSCHの割り当てPRB数に応じて、複数の設定値の候補の中から一つが端末２００に対して設定されてもよい。
　＜Ｓ１０３／Ｓ１０４＞
　基地局１００は、例えば、Ｓ１０２において決定したRAR用のPDSCHリソースに関する情報を端末２００へ送信（例えば、通知、設定）してよい。RAR用のPDSCHリソースに関する情報は、例えば、PDCCH（例えば、DCI）によって端末２００へ通知されてもよい。このとき、PDCCHは、例えば、Random Access - Radio Network Temporary Identifier（RA-RNTI）を用いてスクランブリングされてもよい。
　端末２００は、例えば、基地局１００から通知される、RAR用のPDSCHリソースに関する情報を受信し、受信した情報に基づいて、RAR用のPDSCHリソースを特定してよい。
　＜Ｓ１０５／Ｓ１０６＞
　基地局１００は、例えば、Ｓ１０３において通知したPDSCHリソースにおいてRARを端末２００へ送信する。RARには、例えば、Ｓ１０２において決定した、Msg3用のPUSCHリソースに関する情報（例えば、k'に関する情報）が含まれてよい。
　端末２００は、例えば、Ｓ１０４において特定したPDSCHリソースにてRARを受信する。
　＜Ｓ１０７＞
　端末２００は、例えば、RARの受信処理を行い、RARに含まれる情報に基づいて、Msg.3用PUSCHリソースを特定する。
　このとき、端末２００は、「5 MHz相当のPRB数」より大きいPRB数を有するPDSCHの受信を完了するタイミング（例えば、シンボル、又は、時刻）と、PUSCH（例えば、Msg 3）の送信を開始するタイミング（例えば、シンボル、又は、時刻）との間の間隔として、最小時間間隔（m'）が確保されるようにPDSCH及びPUSCHの各リソースが設定されると仮定してもよい。または、端末２００は、「5 MHz相当のPRB数」より大きいPRB数を有するPDSCHを受信する場合には、最小時間間隔（m'）よりも短い間隔でのPDSCHの受信及びPUSCHの送信を仮定しなくてよい。
　例えば、端末２００は、スロットnに配置されるPDSCHの割り当てPRB数が「5 MHz相当のPRB数」より大きい場合、PUSCHリソースが配置されるスロットn+k'について、PDSCHとPUSCHの間隔が最小時間間隔m'以上となるk'の値が通知されると仮定してよい。端末２００は、例えば、k'個のスロットの長さ（又は、PDSCHとPUSCHとのスロット間隔）は、m'より大きいと仮定してもよい。
　なお、端末２００は、例えば、予め受信した制御情報、又は、上述したPDCCHを用いて受信した制御情報に基づいて、PDSCHの割り当てPRB数を特定してもよい。
　＜Ｓ１０８／Ｓ１０９＞
　端末２００は、例えば、Ｓ１０７において特定したPUSCHリソースにてMsg 3を基地局１００へ送信する。
　基地局１００は、例えば、Ｓ１０２において決定したPUSCHリソースにてMsg 3を受信する。
　上述した動作例によれば、例えば、RAR用のPDSCHの割り当てPRB数が「5 MHz相当のPRB数」よりも大きく、eRedCap端末におけるRARの受信処理時間が長くなる可能性が高い場合でも、基地局１００は、Msg 3用のPUSCHに対して、RARのデータサイズ（又は、eRedCap端末におけるRARの受信処理）を考慮してMsg.3のPUSCHの時間リソースを割り当てることができる。これにより、端末２００（例えば、eRedCap端末）は、受信したRARに含まれる割り当て情報に基づいて、eRedCap端末の処理能力に適した適切なタイミングでMsg3を送信できる。
　＜他の動作例＞
　上記動作例では、PDSCHの割り当てPRB数が「5 MHz相当のPRB数」よりも大きい場合のPUSCHのリソース割り当てについて説明した。
　ここでは、PDSCHの割り当てPRB数が「5 MHz相当のPRB数」以下の場合のPUSCHのリソース割り当てについて説明する。
　例えば、PDSCHの割り当てPRB数が「5 MHz相当のPRB数」以下の場合、既存の割り当て方法（例えば、最小時間間隔（m'）又はk'を考慮しない方法）に基づいてPUSCHの時間リソースが割り当てられてもよい。
　または、例えば、PDSCHの割り当てPRB数が「5 MHz相当のPRB数」以下の場合、PDSCHとPUSCHとの間の時間リソースの間隔は最小時間間隔（m'）より短い間隔に設定されてもよい。例えば、PDSCHがスロットnに割り当てられる場合、PUSCHが割り当てられるスロットn+kについて、PDSCHとPUSCHとの間隔はm'未満となるように設定されてもよい。ここで、kの値（例えば、k個のスロット長）は、PDSCHとPUSCHとの間隔がm'未満の間隔になるように設定されてよい（例えば、kスロット＜m'）。基地局１００は、例えば、kの値に関する情報を、Msg 3用のPUSCHのリソースに関する情報として端末２００へ通知してもよい。
　または、例えば、PDSCHの割り当てPRB数が「5 MHz相当のPRB数」以下の場合における、PDSCHとPUSCHとの間の最小時間間隔（m）が規定されてもよい。最小時間間隔（m）は、最小時間間隔（m'）よりも小さく設定されてもよい。
　例えば、基地局１００は、端末２００が「5 MHz相当のPRB数」以下のPRB数を有するPDSCHの受信を完了するタイミング（例えば、シンボル、又は、時刻）と、端末２００がPUSCH（例えば、Msg 3）の送信を開始するタイミング（例えば、シンボル、又は、時刻）との間の間隔として、最小時間間隔（m）が確保されるように、PDSCH及びPUSCHの各リソースを割り当ててよい。
　また、例えば、端末２００は、「5 MHz相当のPRB数」以下のPRB数を有するPDSCHの受信を完了するタイミング（例えば、シンボル、又は、時刻）と、PUSCH（例えば、Msg 3）の送信を開始するタイミング（例えば、シンボル、又は、時刻）との間の間隔として、最小時間間隔（m）が確保されるようにPDSCH及びPUSCHの各リソースが設定されると仮定してもよい。または、端末２００は、「5 MHz相当のPRB数」以下のPRB数を有するPDSCHを受信する場合には、最小時間間隔（m）よりも短い間隔でのPDSCHの受信及びPUSCHの送信を仮定しなくてよい。
　例えば、スロットnに配置されるPDSCHの割り当てPRB数が「5 MHz相当のPRB数」以下の場合、PUSCHリソースがスロットn+kに割り当てられてよい。このとき、PDSCHとPUSCHの間隔がm以上となるようなkの値が設定され、端末２００へ通知されてもよい。例えば、k個のスロットの長さはmより大きく設定されてもよい。
　これらの方法により、RAR用のPDSCHの割り当てPRB数が「5 MHz相当のPRB数」以下の場合、端末２００（例えば、eRedCap端末）における受信処理時間が比較的短いことが想定されるため、端末２００は、RAR用のPDSCHの割り当てPRB数が「5 MHz相当のPRB数」より多い場合と比較して、より早いタイミングでMsg3を送信できる。
　なお、例えば、PUSCHの送信タイミングは、PDSCHの割り当てPRB数に応じて動的に設定（又は、切り替え、変化）されてもよい。例えば、RAR用のPDSCHとMsg 3用のPUSCHとの間の時間リソース間隔は、PDSCHの割り当てPRB数に応じて異なってよい。例えば、端末２００は、スロットnに配置されるPDSCHの割り当てPRB数が「5 MHz相当のPRB数」以下の場合、スロットn+kにおいてPUSCHを送信し、スロットnに配置されるPDSCHの割り当てPRB数が「5 MHz相当のPRB数」よりも大きい場合、スロットn+k'においてPUSCHを送信してもよい。このように、PDSCHの割当てPRB数に応じて、PUSCHの送信タイミングを動的に切り替えることにより、端末２００は、RARのデータサイズ（例えば、PRB数）に応じたタイミングにてMsg 3を適切に送信できる。
　また、最小時間間隔（m）には、例えば、PDSCHの割り当てPRB数が「5 MHz相当のPRB数」以下の場合を考慮したPDSCHとPUSCHとの間の時間間隔が設定されてよい。例えば、最小時間間隔（m）には、PDSCHの割り当てPRB数が5 MHz相当以下である場合のPDSCHとPUSCHとの間の最小時間間隔が設定されてもよい。また、最小時間間隔（m）には複数の設定値の候補が規定され、例えば、PDSCHに設定される割り当てPRB数に応じて、複数の設定値の候補の中から一つが端末２００に対して設定されてもよい。
　以上、基地局１００及び端末２００の動作例について説明した。
　以上のように、本実施の形態では、基地局１００は、RAR用のPDSCHを送信し、RAR用のPDSCHを送信した後にMsg 3用のPUSCHを受信する。また、端末２００は、RAR用のPDSCHを受信し、RAR用のPDSCHを受信した後にMsg 3用のPUSCHを送信する。このとき、Msg 3用のPUSCHの送信タイミングは、RAR用のPDSCHのリソースサイズに関するパラメータ（例えば、PRB数）に応じて異なる。
　これにより、eRedCap端末は、例えば、RAR用のPDSCHのデータサイズに応じて、eRedCap端末の処理能力（例えば、RARの受信処理能力）に応じた適切なタイミングにおいてMsg 3を送信することができる。よって、本実施の形態によれば、端末２００における上りリンクの送信タイミングを適切に設定できる。
　なお、本実施の形態では、PUSCHの送信タイミングを決定する際の基準となるPRB数として「5 MHz相当のPRB数」を用いる場合について説明したが、これに限定されず、他のPRB数でもよい。
　（実施の形態２）
　本実施の形態に係る基地局１００及び端末２００は、実施の形態１と同様でよい。
　本実施の形態では、RARのデータサイズに関するパラメータとして、RAR用のPDSCHのTBサイズを用いる場合について説明する。
　例えば、RAR用のPDSCHのTBサイズが閾値より大きい場合のRAR用のPDSCHと、Msg 3用のPUSCHとの間の最小時間間隔（例えば、「m'」)が設定されてよい。
　例えば、RAR用のPDSCHのTBサイズが閾値よりも大きい場合、RAR用のPDSCHの時間リソースと、Msg 3用のPUSCHの時間リソースとの間隔は、最小時間間隔m'以上に設定されてよい。
　例えば、基地局１００は、RAR用のPDSCHのTBサイズが閾値よりも大きい場合、RAR用のPDSCHの時間リソースとの間隔が最小時間間隔m'以上となるように、Msg 3用のPUSCHの時間リソースを決定してよい。
　また、例えば、端末２００は、RAR用のPDSCHのTBサイズが閾値よりも大きい場合、RAR用のPDSCHの時間リソースとの間隔が最小時間間隔m'以上の間隔であるMsg 3（PUSCH）の送信（又は、スケジューリング、設定）を仮定（又は、予期、想定）してよい。または、端末２００は、例えば、RAR用のPDSCHの時間リソースとの間隔が最小時間間隔m'より短い間隔でのMsg 3（PUSCH）の送信（又は、スケジューリング、設定）を仮定（又は、予期、想定）しなくてよい。
　これにより、RARのデータサイズが大きい場合（例えば、TBサイズが閾値より大きい場合）でも、端末２００（例えば、eRedCap端末）は、端末２００の処理能力に適したタイミングでMsg3を適切に送信できる。
　本実施の形態に係る、基地局１００（例えば、gNB）及び端末２００（例えば、UE）の処理の一例は、図５に示す実施の形態１の処理の一例と同様でよい。
　＜Ｓ１０１＞
　基地局１００は、例えば、RARのデータサイズに関するパラメータを決定する。RARのデータサイズに関するパラメータには、少なくとも、RAR用のPDSCHのTBサイズが含まれてよい。また、RARのデータサイズに関するパラメータには、例えば、RAR用のPDSCHの割り当てPRB数、及び、RAR用のPDSCHに設定されるTBサイズの決定に用いられるTB scaling factorの少なくとも一つが含まれてよい。
　＜Ｓ１０２＞
　基地局１００は、例えば、Ｓ１０１において決定したRARのデータサイズに関するパラメータ（例えば、TBサイズ）に基づいて、RAR用のPDSCHのリソース、及び、Msg 3用のPUSCHのリソースを決定する。
　例えば、PDSCHのTBサイズが閾値より大きい場合のPDSCHとPUSCHとの間の最小時間間隔（m'）が規定（又は、設定、定義）されてよい。
　なお、PDSCHのTBサイズに対する閾値は、例えば、1000ビットでもよく、他の値でもよい。閾値は、規格において規定されてもよく、端末２００に予め設定されてもよく、基地局１００から端末２００へ通知（又は、設定）されてもよい。
　この場合、基地局１００は、端末２００が閾値より大きいTBサイズを有するPDSCHの受信を完了するタイミング（例えば、シンボル、又は、時刻、又は、時間単位）と、端末２００がPUSCH（例えば、Msg 3）の送信を開始するタイミング（例えば、シンボル、又は、時刻、又は、時間単位）との間の間隔として、最小時間間隔（m'）が確保されるように、PDSCH及びPUSCHの各リソースを割り当ててよい。例えば、PDSCHの受信を完了するタイミングとPUSCHの送信を開始するタイミングとの間において、端末２００ではPDSCH（例えば、RAR）の受信処理が行われてよい。
　例えば、基地局１００は、閾値より大きいTBサイズを有するPDSCHをスロットnに割り当て、PUSCHをスロットn+k'に割り当ててもよい。ここで、例えば、K'の値（例えば、k'個のスロット長は、PDSCHとPUSCHとの間隔がm'以上の間隔になるように設定されてよい（例えば、k'スロット＞m'）。基地局１００は、例えば、k'の値に関する情報を、Msg 3用のPUSCHのリソースに関する情報として決定してよい。
　なお、最小時間間隔（m’）には、例えば、PDSCHのTBサイズが閾値より大きい場合を考慮したPDSCHとPUSCHとの間の時間間隔が設定されてよい。例えば、最小時間間隔（m’）は、RAR用のPDSCHのTBサイズが閾値より大きい場合のeRedCap端末におけるRARの受信処理時間（又は、受信処理能力）に基づいて設定されてもよい。
　例えば、RAR用のPDSCHのTBサイズが大きいほど、RARのデータサイズは大きく、eRedCap端末におけるRARの受信処理時間は長くなりやすい。そこで、一例として、最小時間間隔（m'）は、RAR用のPDSCHのTBサイズの上限値に基づいて設定されてもよい。なお、最小時間間隔（m'）は、RAR用のPDSCHのTBサイズの上限値に基づいて設定される場合に限定されず、TBサイズが採り得る値のうち何れかの値に基づいて設定されてもよい。
　また、例えば、最小時間間隔（m’）には、PDSCHのTBサイズが規定値（例えば、4000ビット）以下である場合のPDSCHとPUSCHとの間の最小時間間隔が設定されてもよい。なお、最小時間間隔（m'）を設定する基準となるTBサイズの値は、4000ビットに限らず、他のサイズでもよい。
　また、例えば、最小時間間隔（m’）には、PDSCHのTBサイズが或る範囲（例えば、1000ビットより多く、かつ、4000ビット以下の範囲）である場合のPDSCHとPUSCHとの間の最小時間間隔が設定されてもよい。なお、最小時間間隔（m’）を設定する基準となるTBサイズの範囲は、1000ビット～4000ビットの範囲に限らず、他のTBサイズの範囲でもよい。
　また、最小時間間隔（m’）に複数の設定値の候補が規定され、例えば、PDSCHのTBサイズに応じて、複数の設定値の候補の中から一つが端末２００に対して設定されてもよい。
　＜Ｓ１０３／Ｓ１０４＞
　基地局１００は、例えば、Ｓ１０２において決定したRAR用のPDSCHリソースに関する情報を端末２００へ送信（例えば、通知、設定）してよい。RAR用のPDSCHリソースに関する情報は、例えば、PDCCH（例えば、DCI）によって端末２００へ通知されてもよい。このとき、PDCCHは、例えば、RA-RNTIを用いてスクランブリングされてもよい。
　端末２００は、例えば、基地局１００から通知される、RAR用のPDSCHリソースに関する情報を受信し、受信した情報に基づいて、RAR用のPDSCHリソースを特定してよい。
　＜Ｓ１０５／Ｓ１０６＞
　基地局１００は、例えば、Ｓ１０３において通知したPDSCHリソースにおいてRARを端末２００へ送信する。RARには、例えば、Ｓ１０２において決定した、Msg3用のPUSCHリソースに関する情報（例えば、k'に関する情報）が含まれてよい。
　端末２００は、例えば、Ｓ１０４において特定したPDSCHリソースにおいてRARを受信する。
　＜Ｓ１０７＞
　端末２００は、例えば、RARの受信処理を行い、RARに含まれる情報に基づいて、Msg.3用PUSCHリソースを特定する。
　このとき、端末２００は、閾値より大きいTBサイズを有するPDSCHの受信を完了するタイミング（例えば、シンボル、又は、時刻）と、PUSCH（例えば、Msg 3）の送信を開始するタイミング（例えば、シンボル、又は、時刻）との間の間隔として、最小時間間隔（m'）が確保されるようにPDSCH及びPUSCHの各リソースが設定されると仮定してもよい。または、端末２００は、閾値より大きいTBサイズを有するPDSCHを受信する場合には、最小時間間隔（m'）よりも短い間隔でのPDSCHの受信及びPUSCHの送信を仮定しなくてよい。
　例えば、端末２００は、スロットnに配置されるPDSCHのTBサイズが閾値より大きい場合、PUSCHリソースが配置されるスロットn+k'について、PDSCHとPUSCHの間隔が最小時間間隔m’以上となるk'の値が通知されると仮定してよい。端末２００は、例えば、k'個のスロットの長さ（又は、PDSCHとPUSCHとのスロット間隔）は、m'より大きいと仮定してもよい。
　なお、端末２００は、例えば、予め受信した制御情報、又は、上述したPDCCHを用いて受信した制御情報に基づいて、PDSCHのTBサイズを特定してもよい。
　＜Ｓ１０８／Ｓ１０９＞
　端末２００は、例えば、Ｓ１０７において特定したPUSCHリソースにおいてMsg 3を基地局１００へ送信する。
　基地局１００は、例えば、Ｓ１０２において決定したPUSCHリソースにおいてMsg 3を受信する。
　上述した動作例によれば、例えば、RAR用のPDSCHのTBサイズが閾値よりも大きく、eRedCap端末におけるRARの受信処理時間が長くなる可能性が高い場合でも、基地局１００は、Msg 3用のPUSCHに対して、RARのデータサイズ（又は、eRedCap端末におけるRARの受信処理）を考慮してMsg 3用のPUSCHの時間リソースを割り当てることができる。これにより、端末２００（例えば、eRedCap端末）は、受信したRARに含まれる割り当て情報に基づいて、eRedCap端末の処理能力に適した適切なタイミングでMsg3を送信できる。
　＜他の動作例＞
　上記動作例では、PDSCHのTBサイズが閾値よりも大きい場合のPUSCHのリソース割り当てについて説明した。
　ここでは、PDSCHのTBサイズが閾値以下の場合のPUSCHのリソース割り当てについて説明する。
　例えば、PDSCHのTBサイズが閾値以下の場合、既存の割り当て方法（例えば、最小時間間隔（m'）又はk'を考慮しない方法）に基づいてPUSCHの時間リソースが割り当てられてもよい。
　または、例えば、PDSCHのTBサイズが閾値以下の場合、PDSCHとPUSCHとの間の時間リソースの間隔は最小時間間隔（m'）より短い間隔に設定されてもよい。例えば、PDSCHがスロットnに割り当てられる場合、PUSCHが割り当てられるスロットn+kについて、PDSCHとPUSCHとの間隔はm’未満となるように設定されてもよい。ここで、kの値（例えば、k個のスロット長）は、PDSCHとPUSCHとの間隔がm'未満の間隔になるように設定されてよい（例えば、kスロット＜m'）。基地局１００は、例えば、kの値に関する情報を、Msg 3用のPUSCHのリソースに関する情報として端末２００へ通知してもよい。
　または、例えば、PDSCHのTBサイズが閾値以下の場合における、PDSCHとPUSCHとの間の最小時間間隔（m）が規定されてもよい。最小時間間隔（m）は、最小時間間隔（m'）よりも小さく設定されてもよい。
　例えば、基地局１００は、端末２００が閾値以下のTBサイズを有するPDSCHの受信を完了するタイミング（例えば、シンボル、又は、時刻）と、端末２００がPUSCH（例えば、Msg 3）の送信を開始するタイミング（例えば、シンボル、又は、時刻）との間の間隔として、最小時間間隔（m）が確保されるように、PDSCH及びPUSCHの各リソースを割り当ててよい。
　また、例えば、端末２００は、閾値以下のTBサイズを有するPDSCHの受信を完了するタイミング（例えば、シンボル、又は、時刻）と、PUSCH（例えば、Msg 3）の送信を開始するタイミング（例えば、シンボル、又は、時刻）との間の間隔として、最小時間間隔（m）が確保されるようにPDSCH及びPUSCHの各リソースが設定されると仮定してもよい。または、端末２００は、閾値以下のTBサイズを有するPDSCHを受信する場合には、最小時間間隔（m）よりも短い間隔でのPDSCHの受信及びPUSCHの送信を仮定しなくてよい。
　例えば、スロットnに配置されるPDSCHのTBサイズが閾値以下の場合、PUSCHリソースがスロットn+kに割り当てられてよい。このとき、PDSCHとPUSCHの間隔がm以上となるようなkの値が設定され、端末２００へ通知されてもよい。例えば、k個のスロットの長さはmより大きく設定されてもよい。
　これらの方法により、RAR用のPDSCHのTBサイズが閾値以下の場合、端末２００（例えば、eRedCap端末）における受信処理時間が比較的短いことが想定されるため、端末２００は、RAR用のPDSCHのTBサイズが閾値より大きい場合と比較して、より早いタイミングでMsg3を送信できる。
　なお、例えば、PUSCHの送信タイミングは、PDSCHのTBサイズに応じて動的に設定（又は、切り替え、変化）されてもよい。例えば、RAR用のPDSCHとMsg 3用のPUSCHとの間の時間リソース間隔は、PDSCHのTBサイズに応じて異なってよい。例えば、端末２００は、スロットnに配置されるPDSCHのTBサイズが閾値以下の場合、スロットn+kにおいてPUSCHを送信し、スロットnに配置されるPDSCHのTBサイズが閾値よりも大きい場合、スロットn+k'においてPUSCHを送信してもよい。このように、PDSCHのTBサイズに応じて、PUSCHの送信タイミングを動的に切り替えることにより、端末２００は、RARのデータサイズ（例えば、TBサイズ）に応じたタイミングにてMsg 3を適切に送信できる。
　また、最小時間間隔（m）には、例えば、PDSCHのTBサイズが閾値以下の場合を考慮したPDSCHとPUSCHとの間の時間間隔が設定されてよい。例えば、最小時間間隔（m）には、PDSCHのTBサイズが1000ビット以下である場合のPDSCHとPUSCHとの間の最小時間間隔が設定されてもよい。また、最小時間間隔（m）には複数の設定値の候補が規定され、例えば、PDSCHに設定されるTBサイズに応じて、複数の設定値の候補の中から一つが端末２００に対して設定されてもよい。
　以上、基地局１００及び端末２００の動作例について説明した。
　以上のように、本実施の形態では、基地局１００は、RAR用のPDSCHを送信し、RAR用のPDSCHを送信した後にMsg 3用のPUSCHを受信する。また、端末２００は、RAR用のPDSCHを受信し、RAR用のPDSCHを受信した後にMsg 3用のPUSCHを送信する。このとき、Msg 3用のPUSCHの送信タイミングは、RAR用のPDSCHのリソースサイズに関するパラメータ（例えば、TBサイズ）に応じて異なる。
　これにより、eRedCap端末は、例えば、RAR用のPDSCHのデータサイズに応じて、eRedCap端末の処理能力（例えば、RARの受信処理能力）に応じた適切なタイミングにおいてMsg 3を送信することができる。よって、本実施の形態によれば、端末２００における上りリンクの送信タイミングを適切に設定できる。
　なお、本実施の形態では、PUSCHの送信タイミングを決定する際の基準となるTBサイズ（例えば、閾値）は、eRedCap端末の特性又は能力に合わせて決定されてもよい。
　（実施の形態３）
　本実施の形態に係る基地局１００及び端末２００は、実施の形態１と同様でよい。
　本実施の形態では、RARのデータサイズに関するパラメータとして、RAR用のPDSCHのTBサイズの算出（又は、決定）に用いるTB scaling factor（又は、scaling factorと呼ぶ）を用いる場合について説明する。
　例えば、RAR用のPDSCHのTB scaling factorが閾値より大きい場合のRAR用のPDSCHと、Msg 3用のPUSCHとの間の最小時間間隔（例えば、「m'」)が設定されてよい。
　例えば、RAR用のPDSCHのTB scaling factorが閾値よりも大きい場合、RAR用のPDSCHの時間リソースと、Msg 3用のPUSCHの時間リソースとの間隔は、最小時間間隔m'以上に設定されてよい。
　例えば、基地局１００は、RAR用のPDSCHのTB scaling factorが閾値よりも大きい場合、RAR用のPDSCHの時間リソースとの間隔が最小時間間隔m'以上となるように、Msg 3用のPUSCHの時間リソースを決定してよい。
　また、例えば、端末２００は、RAR用のPDSCHのTB scaling factorが閾値よりも大きい場合、RAR用のPDSCHの時間リソースとの間隔が最小時間間隔m'以上の間隔であるMsg 3（PUSCH）の送信（または、スケジューリング、設定）を仮定（又は、予期、想定）してよい。または、端末２００は、例えば、RAR用のPDSCHの時間リソースとの間隔が最小時間間隔m'より短い間隔でのMsg 3（PUSCH）の送信（または、スケジューリング、設定）を仮定（又は、予期、想定）しなくてよい。
　これにより、RARのデータサイズが大きい場合（例えば、TB scaling factorが閾値より大きい場合）でも、端末２００（例えば、eRedCap端末）は、端末２００の処理能力に適したタイミングでMsg3を適切に送信できる。
　本実施の形態に係る、基地局１００（例えば、gNB）及び端末２００（例えば、UE）の処理の一例は、図５に示す実施の形態１の処理の一例と同様でよい。
　＜Ｓ１０１＞
　基地局１００は、例えば、RARのデータサイズに関するパラメータを決定する。RARのデータサイズに関するパラメータには、少なくとも、RAR用のPDSCHに設定されるTBサイズの決定に用いられるTB scaling factorが含まれてよい。また、RARのデータサイズに関するパラメータには、例えば、RAR用のPDSCHに割り当てられるPRB数、及び、RAR用のPDSCHに設定されるTBサイズの少なくとも一つが含まれてよい。
　＜Ｓ１０２＞
　基地局１００は、例えば、Ｓ１０１において決定したRARのデータサイズに関するパラメータ（例えば、TB scaling factor）に基づいて、RAR用のPDSCHのリソース、及び、Msg 3用のPUSCHのリソースを決定する。
　例えば、PDSCHのTB scaling factorが閾値より大きい場合のPDSCHとPUSCHとの間の最小時間間隔（m'）が規定（又は、設定、定義）されてよい。
　なお、PDSCHのTB scaling factorに対する閾値は、例えば、0.5でもよく、他の値でもよい。閾値は、規格において規定されてもよく、端末２００に予め設定されてもよく、基地局１００から端末２００へ通知（又は、設定）されてもよい。
　この場合、基地局１００は、端末２００が閾値より大きいTB scaling factorが設定されるPDSCHの受信を完了するタイミング（例えば、シンボル、時刻、又は、時間単位）と、端末２００がPUSCH（例えば、Msg 3）の送信を開始するタイミング（例えば、シンボル、時刻、又は、時間単位）との間の間隔として、最小時間間隔（m'）が確保されるように、PDSCH及びPUSCHの各リソースを割り当ててよい。例えば、PDSCHの受信を完了するタイミングとPUSCHの送信を開始するタイミングとの間において、端末２００ではPDSCH（例えば、RAR）の受信処理が行われてよい。
　例えば、基地局１００は、閾値より大きいTB scaling factorが設定されるPDSCHをスロットnに割り当て、PUSCHをスロットn+k'に割り当ててもよい。ここで、例えば、K'の値（例えば、k'個のスロット長は、PDSCHとPUSCHとの間隔がm'以上の間隔になるように設定されてよい（例えば、k'スロット＞m'）。基地局１００は、例えば、k'の値に関する情報を、Msg 3用のPUSCHのリソースに関する情報として決定してよい。
　なお、最小時間間隔（m’）には、例えば、PDSCHに設定されるTB scaling factorが閾値より大きい場合を考慮したPDSCHとPUSCHとの間の時間間隔が設定されてよい。例えば、最小時間間隔（m’）は、RAR用のPDSCHに設定されるTB scaling factorが閾値より大きい場合のeRedCap端末におけるRARの受信処理時間（又は、受信処理能力）に基づいて設定されてもよい。
　例えば、RAR用のPDSCHのTBサイズ決定に用いられるTB scaling factorが大きいほど、RARのデータサイズは大きく、eRedCap端末におけるRARの受信処理時間は長くなりやすい。そこで、一例として、最小時間間隔（m'）は、RAR用のPDSCHに設定されるTB scaling factorの上限値に基づいて設定されてもよい。なお、最小時間間隔（m'）は、RAR用のPDSCHに設定されるTB scaling factorの上限値に基づいて設定される場合に限定されず、TB scaling factorが採り得る値のうち何れかの値に基づいて設定されてもよい。
　また、例えば、最小時間間隔（m’）には、PDSCHのTB scaling factorが規定値（例えば、1）以下である場合のPDSCHとPUSCHとの間の最小時間間隔が設定されてもよい。なお、最小時間間隔（m'）を設定する基準となるTB scaling factorの値は、1に限らず、他の値でもよい。
　また、例えば、最小時間間隔（m’）には、PDSCHのTB scaling factorが或る範囲（例えば、0.5より大きく、かつ、1以下の範囲）である場合のPDSCHとPUSCHとの間の最小時間間隔が設定されてもよい。なお、最小時間間隔（m’）を設定する基準となるTB scaling factorの範囲は、0.5～1の範囲に限らず、他のTB scaling factorの範囲でもよい。
　また、最小時間間隔（m’）に複数の設定値の候補が規定され、例えば、PDSCHのTB scaling factorに応じて、複数の設定値の候補の中から一つが端末２００に対して設定されてもよい。
　＜Ｓ１０３／Ｓ１０４＞
　基地局１００は、例えば、Ｓ１０２において決定したRAR用のPDSCHリソースに関する情報を端末２００へ送信（例えば、通知、設定）してよい。RAR用のPDSCHリソースに関する情報は、例えば、PDCCH（例えば、DCI）によって端末２００へ通知されてもよい。このとき、PDCCHは、例えば、RA-RNTIを用いてスクランブリングされてもよい。
　端末２００は、例えば、基地局１００から通知される、RAR用のPDSCHリソースに関する情報を受信し、受信した情報に基づいて、RAR用のPDSCHリソースを特定してよい。
　＜Ｓ１０５／Ｓ１０６＞
　基地局１００は、例えば、Ｓ１０３において通知したPDSCHリソースにおいてRARを端末２００へ送信する。RARには、例えば、Ｓ１０２において決定した、Msg3用のPUSCHリソースに関する情報（例えば、k'に関する情報）が含まれてよい。
　端末２００は、例えば、Ｓ１０４において特定したPDSCHリソースにおいてRARを受信する。
　＜Ｓ１０７＞
　端末２００は、例えば、RARの受信処理を行い、RARに含まれる情報に基づいて、Msg.3用PUSCHリソースを特定する。
　このとき、端末２００は、閾値より大きいTB scaling factorが設定されるPDSCHの受信を完了するタイミング（例えば、シンボル、又は、時刻）と、端末２００がPUSCH（例えば、Msg 3）の送信を開始するタイミング（例えば、シンボル、又は、時刻）との間の間隔として、最小時間間隔（m'）が確保されるようにPDSCH及びPUSCHの各リソースが設定されると仮定してもよい。または、端末２００は、閾値より大きいTB scaling factorが設定されるPDSCHを受信する場合には、最小時間間隔（m'）よりも短い間隔でのPDSCHの受信及びPUSCHの送信を仮定しなくてよい。
　例えば、端末２００は、スロットnに配置されるPDSCHのTB scaling factorが閾値より大きい場合、PUSCHリソースが配置されるスロットn+k'について、PDSCHとPUSCHの間隔が最小時間間隔m'以上となるk'の値が通知されると仮定してよい。端末２００は、例えば、k'個のスロットの長さ（又は、PDSCHとPUSCHとのスロット間隔）は、m'より大きいと仮定してもよい。
　なお、端末２００は、例えば、予め受信した制御情報、又は、上述したPDCCHを用いて受信した制御情報に基づいて、PDSCHのTB scaling factorを特定してもよい。
　＜Ｓ１０８／Ｓ１０９＞
　端末２００は、例えば、Ｓ１０７において特定したPUSCHリソースにおいてMsg 3を基地局１００へ送信する。
　基地局１００は、例えば、Ｓ１０２において決定したPUSCHリソースにおいてMsg 3を受信する。
　上述した動作例によれば、例えば、RAR用のPDSCHのTB scaling factorが閾値よりも大きく、eRedCap端末におけるRARの受信処理時間が長くなる可能性が高い場合でも、基地局１００は、Msg 3用のPUSCHに対して、RARのデータサイズ（又は、eRedCap端末におけるRARの受信処理）を考慮してMsg 3用のPUSCHの時間リソースを割り当てることができる。これにより、端末２００（例えば、eRedCap端末）は、受信したRARに含まれる割り当て情報に基づいて、eRedCap端末の処理能力に適した適切なタイミングでMsg3を送信できる。
　＜他の動作例＞
　上記動作例では、PDSCHのTB scaling factorが閾値よりも大きい場合のPUSCHのリソース割り当てについて説明した。
　ここでは、PDSCHのTB scaling factorが閾値以下の場合のPUSCHのリソース割り当てについて説明する。
　例えば、PDSCHのTB scaling factorが閾値以下の場合、既存の割り当て方法（例えば、最小時間間隔（m'）又はk'を考慮しない方法）に基づいてPUSCHの時間リソースが割り当てられてもよい。
　または、例えば、PDSCHのTB scaling factorが閾値以下の場合、PDSCHとPUSCHとの間の時間リソースの間隔は最小時間間隔（m'）より短い間隔に設定されてもよい。例えば、PDSCHがスロットnに割り当てられる場合、PUSCHが割り当てられるスロットn+kについて、PDSCHとPUSCHとの間隔はm'未満となるように設定されてもよい。ここで、kの値（例えば、k個のスロット長）は、PDSCHとPUSCHとの間隔がm'未満になるように設定されてよい（例えば、kスロット＜m'）。基地局１００は、例えば、kの値に関する情報を、Msg 3用のPUSCHのリソースに関する情報として端末２００へ通知してもよい。
　または、例えば、PDSCHのTB scaling factorが閾値以下の場合における、PDSCHとPUSCHとの間の最小時間間隔（m）が規定されてもよい。最小時間間隔（m）は、最小時間間隔（m'）よりも小さく設定されてもよい。
　例えば、基地局１００は、端末２００が閾値以下のTB scaling factorが設定されるPDSCHの受信を完了するタイミング（例えば、シンボル、又は、時刻）と、端末２００がPUSCH（例えば、Msg 3）の送信を開始するタイミング（例えば、シンボル、又は、時刻）との間の間隔として、最小時間間隔（m）が確保されるように、PDSCH及びPUSCHの各リソースを割り当ててよい。
　また、例えば、端末２００は、閾値以下のTB scaling factorが設定されるPDSCHの受信を完了するタイミング（例えば、シンボル、又は、時刻）と、PUSCH（例えば、Msg 3）の送信を開始するタイミング（例えば、シンボル、又は、時刻）との間の間隔として、最小時間間隔（m）が確保されるようにPDSCH及びPUSCHの各リソースが設定されると仮定してもよい。または、端末２００は、閾値以下のTB scaling factorを有するPDSCHを受信する場合には、最小時間間隔（m）よりも短い間隔でのPDSCHの受信及びPUSCHの送信を仮定しなくてよい。
　例えば、スロットnに配置されるPDSCHのTB scaling factorが閾値以下の場合、PUSCHリソースがスロットn+kに割り当てられてよい。このとき、PDSCHとPUSCHの間隔がm以上となるようなkの値が設定され、端末２００へ通知されてもよい。例えば、k個のスロットの長さはmより大きく設定されてもよい。
　これらの方法により、RAR用のPDSCHのTB scaling factorが閾値以下の場合、端末２００（例えば、eRedCap端末）における受信処理時間が比較的短いことが想定されるため、端末２００は、RAR用のPDSCHのTB scaling factorが閾値より大きい場合と比較して、より早いタイミングでMsg3を送信できる。
　なお、例えば、PUSCHの送信タイミングは、PDSCHのTB scaling factorに応じて動的に設定（又は、切り替え、変化）されてもよい。例えば、RAR用のPDSCHとMsg 3用のPUSCHとの間の時間リソース間隔は、PDSCHのTB scaling factorに応じて異なってよい。例えば、端末２００は、スロットnに配置されるPDSCHのTB scaling factorが閾値以下の場合、スロットn+kにおいてPUSCHを送信し、スロットnに配置されるPDSCHのTBサイズが閾値よりも大きい場合、スロットn+k'においてPUSCHを送信してもよい。このように、PDSCHに設定されるTB scaling factorに応じて、PUSCHの送信タイミングを動的に切り替えることにより、端末２００は、RARのデータサイズ（例えば、TB scaling factor）に応じたタイミングにてMsg 3を適切に送信できる。
　また、最小時間間隔（m）には、例えば、PDSCHに設定されるTB scaling factorが閾値以下の場合を考慮したPDSCHとPUSCHとの間の時間間隔が設定されてよい。例えば、最小時間間隔（m）には、PDSCHのTB scaling factorが0.5以下である場合のPDSCHとPUSCHとの間の最小時間間隔が設定されてもよい。また、最小時間間隔（m）には複数の設定値の候補が規定され、例えば、PDSCHに設定されるTB scaling factorに応じて、複数の設定値の候補の中から一つが端末２００に対して設定されてもよい。
　以上、基地局１００及び端末２００の動作例について説明した。
　以上のように、本実施の形態では、基地局１００は、RAR用のPDSCHを送信し、RAR用のPDSCHを送信した後にMsg 3用のPUSCHを受信する。また、端末２００は、RAR用のPDSCHを受信し、RAR用のPDSCHを受信した後にMsg 3用のPUSCHを送信する。このとき、Msg 3用のPUSCHの送信タイミングは、RAR用のPDSCHのリソースサイズに関するパラメータ（例えば、TB scaling factor）に応じて異なる。
　これにより、eRedCap端末は、例えば、RAR用のPDSCHのデータサイズに応じて、eRedCap端末の処理能力（例えば、RARの受信処理能力）に応じた適切なタイミングにおいてMsg 3を送信することができる。よって、本実施の形態によれば、端末２００における上りリンクの送信タイミングを適切に設定できる。
　なお、本実施の形態では、PUSCHの送信タイミングを決定する際の基準となるTB scaling factor（例えば、閾値）は、eRedCap端末の特性又は能力に合わせて決定されてもよい。
　以上、本開示の各実施の形態について説明した。
　（他の実施の形態）
　（１）上記各実施の形態において、基地局１００は、基地局１００のセルにおいてeRedCap端末からの接続を許可している場合に、上述したRARのデータサイズに基づく動作を適用してもよい。例えば、RARのデータサイズに関するパラメータに応じたMsg 3用のPUSCHの送信タイミング設定は、eRedCap端末（例えば、capabilityが制限される端末）のアクセスをセルが許可している場合に適用されてよい。すなわち、基地局１００は、基地局１００のセルにおいてeRedCap端末からの接続を禁止している場合、上述したRARのデータサイズに関するパラメータに応じたMsg 3用のPUSCHの送信タイミング設定を適用しなくてもよい。
　これにより、eRedCap端末からの接続を禁止している場合には、RARのパラメータに関わらず、PUSCHの送信タイミングが決定されるため、非eRedCap端末からのPUSCH送信タイミングが早まり得る。よって、eRedCap端末及び非eRedCap端末の両方が共存するセルにおいて、非eRedCap端末に対する影響を軽減できる。
　（２）上記各実施の形態において、基地局１００がeRedCap端末であると見なしている（認識している）端末２００に対して割り当てられるPDSCH及びPUSCHに対して、上述したRARのデータサイズに関するパラメータに応じたMsg 3用のPUSCHの送信タイミング設定が適用されてもよい。その一方で、基地局１００がeRedCap端末であると見なしていない端末２００に対して割り当てられるPDSCH及びPUSCHに対して、上述したRARのデータサイズに関するパラメータに応じたMsg 3用のPUSCHの送信タイミング設定が適用されなくてもよい。
　基地局１００がeRedCap端末であると見なしている端末２００であるか否かは、例えば、capability report又はearly indication(例えば、特定の条件において送信されるPRACHや、特定の情報を含むMsg 3)等によって基地局１００に対してcapabilityを既に報告している端末２００であるか否かに応じて判断可能である。
　これにより、eRedCap端末及び非eRedCap端末の両方のcapabilityに応じた適切なMsg3送信タイミングを割り当てることができる。
　（３）上記各実施の形態において、RARのデータサイズに関するパラメータ(例えば、PRB数、TBサイズ、TB scaling factor)の値として、閾値より小さい値が設定（スケジュール）され、閾値以上の値が設定されなくてもよい。
　これにより、RARのデータサイズは、eRedCap端末の処理能力に対応するサイズに設定されやすくなるので、eRedCap端末であってもRARの処理時間を短縮でき、Msg3用PUSCHの送信タイミングを早めることができる。
　（データサイズに関するパラメータ）
　上記各実施の形態では、データサイズに関するパラメータの例として、PRB数、TBサイズ、及び、TB scaling factorについて説明したが、データサイズに関するパラメータは、これらと異なる他のパラメータでもよい。例えば、データサイズに関するパラメータは、変調多値数、コードレート、リソースエレメント（RE：Resource Element）の数、送信レイヤ数、又は、制御信号又は参照信号のオーバーヘッドの量でもよい。
　また、上記各実施例では、PRBを用いる例について説明したが、これに限らず、例えば、Virtual Resource Block（VRB）、Common Resource Block（CRB、又は、他の種類のRBが用いられてもよい。
　また、上記各実施の形態では、上記eRedCap端末がサポートし得る特性に対応するPRB数を「5 MHz相当のPRB数」として説明したが、周波数帯域幅は、5MHzに限定されず、他の帯域幅でもよい。また、「5 MHz相当のPRB数」として、SCSが30kHzの場合のPRB数の最大値を11個、SCSが15kHzの場合のPRB数の最大値を25個として説明したが、各SCSにおける「5 MHz相当のPRB数」に対応するPRB数の最大数はこれらの値に限定されず、他の値でもよい。また、SCSは、15kHz及び30kHzに限らず、他の値でもよい。
　また、上述したTBサイズ及びTB scaling factorの値は一例であり、他の値でもよい。
　（PRBの配置方法）
　PDSCHにおけるPRBの配置は、周波数的に連続の配置でもよく、周波数的に非連続の配置でもよい。
　（下りリンクチャネルと上りリンクチャネルの組み合わせ）
　上記各実施の形態では、RAR用のPDSCHと、Msg3用のPUSCHとの組み合わせについて説明したが、下りリンクチャネルは、RAR用のPDSCHに限定されず、他の下りリンクチャネル又は信号でもよく、上りリンクチャネルは、Msg 3用のPUSCHに限定されず、他の上りリンクチャネル又は信号でもよい。また、下りリンクチャネルと上りリンクチャネルとの組み合わせは、他の組み合わせでもよい。
　例えば、上記各実施の形態は、以下のチャネル又は信号の組み合わせに適用されてもよい。
　－　RAR用PDSCHとPRACH（例えば、PRACHは、PDSCHの受信に失敗したときに送信される信号でもよい）
　－　PDSCHとPUCCH（例えば、PUCCHは、PDSCHに対するACK/NACKの送信に用いるチャネルでもよい）
　－PDCCHとPUSCH（例えば、PUSCHは、PDCCHによって割り当てられるチャネルでもよい）
　－PDCCHとSounding Reference Signal（SRS）（例えば、SRSは、PDCCHによって割り当てられる信号でもよい）
　例えば、端末２００に対して同じ時刻（例えば、シンボル、又は、スロット）に割り当てられる複数（例えば、２つ）のPDSCH（例えば、unicast PDSCHとbroadcast PDSCH、又は、2つのbroadcast PDSCH）のデータサイズに関するパラメータの値（例えば、PRB数、TBサイズ又はTB scaling factor)の総和が閾値よりも大きい場合のPDSCHとPUCCH（例えば、PDSCHに対するACK/NACKを送信するチャネル)の最小時間間隔（m'）が設定されてもよい。２つのPDSCHのデータサイズに関するパラメータの値の総和が閾値よりも大きい場合、２つのPDSCHとPUCCHは、当該２つのPDSCHとPUCCHとの間の時間間隔がm'以上となるように割り当てられてもよい。
　また、上記各実施の形態では、下りリンクチャネル（例えば、PDSCH）と上りリンクチャネル（例えば、PUSCH）との組み合わせについて説明したが、これに限定されず、例えば、上りリンクチャネルと下りリンクチャネルとの組み合わせでもよく、サイドリンクチャネルを含む組み合わせでもよい。
　（パラメータの設定）
　上記各実施の形態において用いるパラメータ（例えば、k、k'、m又はm'）の値は規格において予め規定されてもよく、制御信号等によって端末２００へ通知されてもよい。また、パラメータ（例えば、k、k'、m又はm'）の値は、processing capability（例えば、1又は2）に応じて異なる値でもよく、processing capabilityに依らず一意に決められる値でもよい。
　また、上記実施の形態では、PDSCH又はPUSCHのリソースがPDCCHによって割り当てられる例について説明したが、これに限定されず、例えば、上位レイヤ信号によってリソースが設定されてもよい。
　（端末の種類、識別）
　上記実施の形態は、例えば、“eRedCap端末”に適用されてもよく、RedCap端末、又は、非eRedCap端末に適用されてもよく、他の種類の端末に適用されてもよい。
　なお、上記実施の形態では、eRedCap端末の特徴（例えば、特性、属性又は能力）として、サポートする最大周波数割当サイズ（例えば、周波数帯域幅又はPRB数）が閾値以下である場合を例として説明したが、eRedCap端末は、例えば、以下の特徴の少なくとも一つを有する端末でもよい。
　（１）「カバレッジ拡張の対象である端末」、「繰り返し送信される信号を受信する端末」、又は、「eRedCap端末」であることを基地局１００へ通知（例えば、報告、report）する端末。なお、上記通知（report）には、例えば、PRACH及びPUSCHといった上りチャネル、又は、Sounding Reference Signal（SRS）といった上り信号が使用されてもよい。
　（２）以下の性能(capability)の少なくとも一つに該当する端末、または、以下の性能の少なくとも一つを基地局１００へ報告する端末。なお、上記報告には、例えば、PRACH及びPUSCHといった上りチャネル、又は、UCI又はSRSといった上り信号が使用されてもよい。
　－送受信可能な周波数帯域幅（例えば、最大値）が閾値以下（例えば、5MHz以下）の端末
　－送受信可能なPRB数（例えば、最大数）が閾値以下（例えば、25個以下又は11個以下）の端末
　－実装される受信アンテナ数が閾値以下（例えば、閾値=１本)の端末。
　－サポート可能な下りポート数（例えば、受信アンテナポート数）が閾値以下（例えば、閾値=２）の端末。
　－サポート可能な送信ランク数（例えば、最大Multiple-Input Multiple-Output（MIMO）レイヤ数（又はrank数））が閾値以下（例えば、閾値=2）の端末。
　－信号を閾値以下の周波数帯域（例えば、Frequency Range 1（FR1）又は6GHz以下の帯域）において送受信可能な端末。
　－処理時間が閾値以上の端末。
　－利用可能なトランスポートブロックの大きさ（TBS：transport block size）が閾値以下の端末。
　－利用可能な送信ランク数（例えば、MIMO送信レイヤ数）が閾値以下の端末。
　－利用可能な変調次数（modulation order）が閾値以下の端末。
　－利用可能なHybrid Automatic Repeat reQuest（HARQ） process数が閾値以下の端末。
　－Rel-18以降をサポートする端末。
　（３）eRedCap端末に対応するパラメータが基地局１００から通知される端末。なお、eRedCap端末に対応するパラメータには、例えば、Subscriber Profile ID for RAT/Frequency Priority（SPID）といったパラメータが含まれてもよい。
　なお、「非eRedCap端末」又は「non-eRedCap端末」は、例えば、Rel-15/16/17をサポートする端末（例えば、Rel-18をサポートしない端末）、又は、Rel-18をサポートする端末であっても上記特徴を有さない端末を意味してもよい。
　（補足）
　上述した実施の形態に示した機能、動作又は処理を端末２００がサポートするか否かを示す情報が、例えば、端末２００の能力（capability）情報あるいは能力パラメータとして、端末２００から基地局１００へ送信（あるいは通知）されてもよい。
　能力情報は、上述した実施の形態に示した機能、動作又は処理の少なくとも１つを端末２００がサポートするか否かを個別に示す情報要素（IE）を含んでもよい。あるいは、能力情報は、上述した各実施の形態、各変形例、及び、各補足に示した機能、動作又は処理の何れか２以上の組み合わせを端末２００がサポートするか否かを示す情報要素を含んでもよい。
　基地局１００は、例えば、端末２００から受信した能力情報に基づいて、能力情報の送信元端末２００がサポートする（あるいはサポートしない）機能、動作又は処理を判断（あるいは決定または想定）してよい。基地局１００は、能力情報に基づく判断結果に応じた動作、処理又は制御を実施してよい。例えば、基地局１００は、端末２００から受信した能力情報に基づいて、端末に割り当てる上りリンクリソースを制御してよい。
　なお、上述した実施の形態に示した機能、動作又は処理の一部を端末２００がサポートしないことは、端末２００において、そのような一部の機能、動作又は処理が制限されることに読み替えられてもよい。例えば、そのような制限に関する情報あるいは要求が、基地局１００に通知されてもよい。
　端末２００の能力あるいは制限に関する情報は、例えば、規格において定義されてもよいし、基地局１００において既知の情報あるいは基地局１００へ送信される情報に関連付けられて暗黙的（implicit）に基地局１００に通知されてもよい。
　（制御信号）
　本開示において、本開示の一実施例に関連する下り制御信号（又は、下り制御情報）は、例えば、物理層のPhysical Downlink Control Channel（PDCCH）において送信される信号（又は、情報）でもよく、上位レイヤのMedium Access Control Control Element（MAC CE）又はRadio Resource Control（RRC）において送信される信号（又は、情報）でもよい。また、信号（又は、情報）は、下り制御信号によって通知される場合に限定されず、仕様（又は、規格）において予め規定されてもよく、基地局及び端末に予め設定されてもよい。
　また、PDCCHは、例えば、Common Search Space（CSS）及びUE Specific Search Space（USS）の何れかにおいて送信されてもよい。
　（基地局）
　本開示の一実施例において、基地局は、Transmission Reception Point（TRP）、クラスタヘッド、アクセスポイント、Remote Radio Head（RRH）、eNodeB (eNB)、gNodeB(gNB)、Base Station（BS）、Base Transceiver Station（BTS）、親機、ゲートウェイなどでもよい。また、サイドリンク通信では、基地局の役割を端末が担ってもよい。また、基地局の代わりに、上位ノードと端末の通信を中継する中継装置であってもよい。また、路側器であってもよい。
　（上りリンク／下りリンク／サイドリンク）
　本開示の一実施例は、例えば、上りリンク、下りリンク、及び、サイドリンクの何れに適用してもよい。例えば、本開示の一実施例を上りリンクのPhysical Uplink Shared Channel（PUSCH）、Physical Uplink Control Channel（PUCCH）、Physical Random Access Channel（PRACH）、下りリンクのPhysical Downlink Shared Channel（PDSCH）、PDCCH、Physical Broadcast Channel（PBCH）、又は、サイドリンクのPhysical Sidelink Shared Channel（PSSCH）、Physical Sidelink Control Channel（PSCCH）、Physical Sidelink Broadcast Channel（PSBCH）に適用してもよい。
　なお、PDCCH、PDSCH、PUSCH、及び、PUCCHそれぞれは、下りリンク制御チャネル、下りリンクデータチャネル、上りリンクデータチャネル、及び、上りリンク制御チャネルの一例である。また、PSCCH、及び、PSSCHは、サイドリンク制御チャネル、及び、サイドリンクデータチャネルの一例である。また、PBCH及びPSBCHは報知（ブロードキャスト）チャネル、PRACHはランダムアクセスチャネルの一例である。
　（データチャネル／制御チャネル）
　本開示の一実施例は、例えば、データチャネル及び制御チャネルの何れに適用してもよい。例えば、本開示の一実施例におけるチャネルをデータチャネルのPDSCH、PUSCH、PSSCH、又は、制御チャネルのPDCCH、PUCCH、PBCH、PSCCH、PSBCHの何れかに置き換えてもよい。
　（参照信号）
　本開示の一実施例において、参照信号は、例えば、基地局及び端末の双方で既知の信号であり、Reference Signal（RS）又はパイロット信号と呼ばれることもある。参照信号は、Demodulation Reference Signal（DMRS）、Channel State Information - Reference Signal（CSI-RS）、Tracking Reference Signal(TRS）、Phase Tracking Reference Signal（PTRS）、Cell-specific Reference Signal（CRS）、又は、Sounding Reference Signal（SRS）の何れでもよい。
　（時間間隔）
　本開示の一実施例において、時間リソースの単位は、スロット及びシンボルの１つ又は組み合わせに限らず、例えば、フレーム、スーパーフレーム、サブフレーム、スロット、タイムスロット、サブスロット、ミニスロット又は、シンボル、Orthogonal Frequency Division Multiplexing（OFDM）シンボル、Single Carrier - Frequency Division Multiplexing（SC-FDMA）シンボルといった時間リソース単位でもよく、他の時間リソース単位でもよい。また、１スロットに含まれるシンボル数は、上述した実施の形態において例示したシンボル数に限定されず、他のシンボル数でもよい。
　（周波数帯域）
　本開示の一実施例は、ライセンスバンド、アンライセンスバンド（unlicensed spectrum, shared spectrum）のいずれに適用してもよい。アンライセンスバンドの場合、各信号の送信前にchannel access procedure (Listen Before Talk (LBT)、キャリアセンス、Channel Clear Assessment (CCA))が実施されてもよい。
　（通信）
　本開示の一実施例は、基地局と端末との間の通信(Uuリンク通信)、端末と端末との間の通信（Sidelink通信）、Vehicle to Everything（V2X）の通信のいずれに適用してもよい。例えば、本開示の一実施例におけるPDCCHをPSCCH、PUSCH／PDSCHをPSSCH、PUCCHをPhysical Sidelink Feedback Channel（PSFCH）、PBCHをPSBCHに置き換えてもよい。
　また、本開示の一実施例は、地上のネットワーク、衛星又は高度疑似衛星（HAPS：High Altitude Pseudo Satellite）を用いた地上以外のネットワーク（NTN：Non-Terrestrial Network）のいずれに適用してもよい。また、本開示の一実施例は、セルサイズの大きなネットワーク、超広帯域伝送ネットワークなどシンボル長やスロット長に比べて伝送遅延が大きい地上ネットワークに適用してもよい。
　（アンテナポート）
　本開示の一実施例において、アンテナポートは、１本又は複数の物理アンテナから構成される論理的なアンテナ（アンテナグループ）を指す。例えば、アンテナポートは必ずしも１本の物理アンテナを指すとは限らず、複数のアンテナから構成されるアレイアンテナ等を指すことがある。例えば、アンテナポートが何本の物理アンテナから構成されるかは規定されず、端末局が基準信号（Reference signal）を送信できる最小単位として規定されてよい。また、アンテナポートはプリコーディングベクトル（Precoding vector）の重み付けを乗算する最小単位として規定されることもある。
　＜５Ｇ　ＮＲのシステムアーキテクチャおよびプロトコルスタック＞
　３ＧＰＰは、１００ＧＨｚまでの周波数範囲で動作する新無線アクセス技術（ＮＲ）の開発を含む第５世代携帯電話技術（単に「５Ｇ」ともいう）の次のリリースに向けて作業を続けている。５Ｇ規格の初版は２０１７年の終わりに完成しており、これにより、５Ｇ　ＮＲの規格に準拠した端末（例えば、スマートフォン）の試作および商用展開に移ることが可能である。
　例えば、システムアーキテクチャは、全体としては、ｇＮＢを備えるＮＧ－ＲＡＮ（Next Generation - Radio Access Network）を想定する。ｇＮＢは、ＮＧ無線アクセスのユーザプレーン（ＳＤＡＰ／ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）および制御プレーン（ＲＲＣ）のプロトコルのＵＥ側の終端を提供する。ｇＮＢは、Ｘｎインタフェースによって互いに接続されている。また、ｇＮＢは、Next Generation（ＮＧ）インタフェースによってＮＧＣ（Next Generation Core）に、より具体的には、ＮＧ－ＣインタフェースによってＡＭＦ（Access and Mobility Management Function）（例えば、ＡＭＦを行う特定のコアエンティティ）に、また、ＮＧ－ＵインタフェースによってＵＰＦ（User Plane Function）（例えば、ＵＰＦを行う特定のコアエンティティ）に接続されている。ＮＧ－ＲＡＮアーキテクチャを図６に示す（例えば、3GPP TS 38.300 v15.6.0, section 4参照）。
　ＮＲのユーザプレーンのプロトコルスタック（例えば、3GPP TS 38.300, section 4.4.1参照）は、ｇＮＢにおいてネットワーク側で終端されるＰＤＣＰ（Packet Data Convergence Protocol（TS 38.300の第６．４節参照））サブレイヤ、ＲＬＣ（Radio Link Control（TS 38.300の第６．３節参照））サブレイヤ、およびＭＡＣ（Medium Access Control（TS 38.300の第６．２節参照））サブレイヤを含む。また、新たなアクセス層（ＡＳ：Access Stratum）のサブレイヤ（ＳＤＡＰ：Service Data Adaptation Protocol）がＰＤＣＰの上に導入されている（例えば、3GPP TS 38.300の第６．５節参照）。また、制御プレーンのプロトコルスタックがＮＲのために定義されている（例えば、TS 38.300, section 4.4.2参照）。レイヤ２の機能の概要がTS 38.300の第６節に記載されている。ＰＤＣＰサブレイヤ、ＲＬＣサブレイヤ、およびＭＡＣサブレイヤの機能は、それぞれ、TS 38.300の第６．４節、第６．３節、および第６．２節に列挙されている。ＲＲＣレイヤの機能は、TS 38.300の第７節に列挙されている。
　例えば、Medium-Access-Controlレイヤは、論理チャネル（logical channel）の多重化と、様々なニューメロロジーを扱うことを含むスケジューリングおよびスケジューリング関連の諸機能と、を扱う。
　例えば、物理レイヤ（ＰＨＹ）は、符号化、ＰＨＹ　ＨＡＲＱ処理、変調、マルチアンテナ処理、および適切な物理的時間－周波数リソースへの信号のマッピングの役割を担う。また、物理レイヤは、物理チャネルへのトランスポートチャネルのマッピングを扱う。物理レイヤは、ＭＡＣレイヤにトランスポートチャネルの形でサービスを提供する。物理チャネルは、特定のトランスポートチャネルの送信に使用される時間周波数リソースのセットに対応し、各トランスポートチャネルは、対応する物理チャネルにマッピングされる。例えば、物理チャネルには、上り物理チャネルとして、ＰＲＡＣＨ（Physical Random Access Channel）、ＰＵＳＣＨ（Physical Uplink Shared Channel)、ＰＵＣＣＨ(Physical Uplink Control Channel)があり、下り物理チャネルとして、ＰＤＳＣＨ（Physical Downlink Shared Channel)、ＰＤＣＣＨ（Physical Downlink Control Channel)、ＰＢＣＨ(Physical Broadcast Channel) がある。
　ＮＲのユースケース／展開シナリオには、データレート、レイテンシ、およびカバレッジの点で多様な要件を有するenhanced mobile broadband（ｅＭＢＢ）、ultra-reliable low-latency communications（ＵＲＬＬＣ）、massive machine type communication（ｍＭＴＣ）が含まれ得る。例えば、ｅＭＢＢは、ＩＭＴ－Ａｄｖａｎｃｅｄが提供するデータレートの３倍程度のピークデータレート（下りリンクにおいて２０Ｇｂｐｓおよび上りリンクにおいて１０Ｇｂｐｓ）および実効（user-experienced）データレートをサポートすることが期待されている。一方、ＵＲＬＬＣの場合、より厳しい要件が超低レイテンシ（ユーザプレーンのレイテンシについてＵＬおよびＤＬのそれぞれで０．５ｍｓ）および高信頼性（１ｍｓ内において１－１０－５）について課されている。最後に、ｍＭＴＣでは、好ましくは高い接続密度（都市環境において装置１，０００，０００台／ｋｍ２）、悪環境における広いカバレッジ、および低価格の装置のための極めて寿命の長い電池（１５年）が求められうる。
　そのため、１つのユースケースに適したＯＦＤＭのニューメロロジー（例えば、サブキャリア間隔、ＯＦＤＭシンボル長、サイクリックプレフィックス（ＣＰ：Cyclic Prefix）長、スケジューリング区間毎のシンボル数）が他のユースケースには有効でない場合がある。例えば、低レイテンシのサービスでは、好ましくは、ｍＭＴＣのサービスよりもシンボル長が短いこと（したがって、サブキャリア間隔が大きいこと）および／またはスケジューリング区間（ＴＴＩともいう）毎のシンボル数が少ないことが求められうる。さらに、チャネルの遅延スプレッドが大きい展開シナリオでは、好ましくは、遅延スプレッドが短いシナリオよりもＣＰ長が長いことが求められうる。サブキャリア間隔は、同様のＣＰオーバーヘッドが維持されるように状況に応じて最適化されてもよい。ＮＲがサポートするサブキャリア間隔の値は、１つ以上であってよい。これに対応して、現在、１５ｋＨｚ、３０ｋＨｚ、６０ｋＨｚ…のサブキャリア間隔が考えられている。シンボル長Ｔｕおよびサブキャリア間隔Δｆは、式Δｆ＝１／Ｔｕによって直接関係づけられている。ＬＴＥシステムと同様に、用語「リソースエレメント」を、１つのＯＦＤＭ／ＳＣ－ＦＤＭＡシンボルの長さに対する１つのサブキャリアから構成される最小のリソース単位を意味するように使用することができる。
　新無線システム５Ｇ－ＮＲでは、各ニューメロロジーおよび各キャリアについて、サブキャリアおよびＯＦＤＭシンボルのリソースグリッドが上りリンクおよび下りリンクのそれぞれに定義される。リソースグリッドの各エレメントは、リソースエレメントと呼ばれ、周波数領域の周波数インデックスおよび時間領域のシンボル位置に基づいて特定される（3GPP TS 38.211 v15.6.0参照）。
　＜５Ｇ　ＮＲにおけるＮＧ－ＲＡＮと５ＧＣとの間の機能分離＞
　図７は、ＮＧ－ＲＡＮと５ＧＣとの間の機能分離を示す。ＮＧ－ＲＡＮの論理ノードは、ｇＮＢまたはｎｇ－ｅＮＢである。５ＧＣは、論理ノードＡＭＦ、ＵＰＦ、およびＳＭＦを有する。
　例えば、ｇＮＢおよびｎｇ－ｅＮＢは、以下の主な機能をホストする：
　－　無線ベアラ制御（Radio Bearer Control）、無線アドミッション制御（Radio Admission Control）、接続モビリティ制御（Connection Mobility Control）、上りリンクおよび下りリンクの両方におけるリソースのＵＥへの動的割当（スケジューリング）等の無線リソース管理（Radio Resource Management）の機能；
　－　データのＩＰヘッダ圧縮、暗号化、および完全性保護；
　－　ＵＥが提供する情報からＡＭＦへのルーティングを決定することができない場合のＵＥのアタッチ時のＡＭＦの選択；
　－　ＵＰＦに向けたユーザプレーンデータのルーティング；
　－　ＡＭＦに向けた制御プレーン情報のルーティング；
　－　接続のセットアップおよび解除；
　－　ページングメッセージのスケジューリングおよび送信；
　－　システム報知情報（ＡＭＦまたは運用管理保守機能（ＯＡＭ：Operation, Admission, Maintenance）が発信源）のスケジューリングおよび送信；
　－　モビリティおよびスケジューリングのための測定および測定報告の設定；
　－　上りリンクにおけるトランスポートレベルのパケットマーキング；
　－　セッション管理；
　－　ネットワークスライシングのサポート；
　－　ＱｏＳフローの管理およびデータ無線ベアラに対するマッピング；
　－　ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態のＵＥのサポート；
　－　ＮＡＳメッセージの配信機能；
　－　無線アクセスネットワークの共有；
　－　デュアルコネクティビティ；
　－　ＮＲとＥ－ＵＴＲＡとの緊密な連携。
　Access and Mobility Management Function（ＡＭＦ）は、以下の主な機能をホストする：
　－　Non-Access Stratum（ＮＡＳ）シグナリングを終端させる機能；
　－　ＮＡＳシグナリングのセキュリティ；
　－　Access Stratum（ＡＳ）のセキュリティ制御；
　－　３ＧＰＰのアクセスネットワーク間でのモビリティのためのコアネットワーク（CN：Core Network）ノード間シグナリング；
　－　アイドルモードのＵＥへの到達可能性（ページングの再送信の制御および実行を含む）；
　－　登録エリアの管理；
　－　システム内モビリティおよびシステム間モビリティのサポート；
　－　アクセス認証；
　－　ローミング権限のチェックを含むアクセス承認；
　－　モビリティ管理制御（加入およびポリシー）；
　－　ネットワークスライシングのサポート；
　－　Session Management Function（ＳＭＦ）の選択。
　さらに、User Plane Function（ＵＰＦ）は、以下の主な機能をホストする：
　－　ｉｎｔｒａ－ＲＡＴモビリティ／ｉｎｔｅｒ－ＲＡＴモビリティ（適用可能な場合）のためのアンカーポイント；
　－　データネットワークとの相互接続のための外部ＰＤＵ(Protocol Data Unit)セッションポイント；
　－　パケットのルーティングおよび転送；
　－　パケット検査およびユーザプレーン部分のポリシールールの強制（Policy rule enforcement）；
　－　トラフィック使用量の報告；
　－　データネットワークへのトラフィックフローのルーティングをサポートするための上りリンククラス分類（uplink classifier）；
　－　マルチホームＰＤＵセッション（multi-homed PDU session）をサポートするための分岐点(Branching Point)；
　－　ユーザプレーンに対するＱｏＳ処理（例えば、パケットフィルタリング、ゲーティング（gating）、ＵＬ／ＤＬレート制御（UL/DL rate enforcement）；
　－　上りリンクトラフィックの検証（ＳＤＦのＱｏＳフローに対するマッピング）；
　－　下りリンクパケットのバッファリングおよび下りリンクデータ通知のトリガ機能。
　最後に、Session Management Function（ＳＭＦ）は、以下の主な機能をホストする：
　－　セッション管理；
　－　ＵＥに対するＩＰアドレスの割当および管理；
　－　ＵＰＦの選択および制御；
　－　適切な宛先にトラフィックをルーティングするためのUser Plane Function（ＵＰＦ）におけるトラフィックステアリング（traffic steering）の設定機能；
　－　制御部分のポリシーの強制およびＱｏＳ；
　－　下りリンクデータの通知。
　＜ＲＲＣ接続のセットアップおよび再設定の手順＞
　図８は、ＮＡＳ部分の、ＵＥがRRC_IDLEからRRC_CONNECTEDに移行する際のＵＥ、ｇＮＢ、およびＡＭＦ（５ＧＣエンティティ）の間のやり取りのいくつかを示す（TS 38.300 v15.6.0参照）。
　ＲＲＣは、ＵＥおよびｇＮＢの設定に使用される上位レイヤのシグナリング（プロトコル）である。この移行により、ＡＭＦは、ＵＥコンテキストデータ（これは、例えば、ＰＤＵセッションコンテキスト、セキュリティキー、ＵＥ無線性能（UE Radio Capability）、ＵＥセキュリティ性能（UE Security Capabilities）等を含む）を用意し、初期コンテキストセットアップ要求（INITIAL CONTEXT SETUP REQUEST）とともにｇＮＢに送る。そして、ｇＮＢは、ＵＥと一緒に、ＡＳセキュリティをアクティブにする。これは、ｇＮＢがＵＥにSecurityModeCommandメッセージを送信し、ＵＥがSecurityModeCompleteメッセージを用いてｇＮＢに応答することによって行われる。その後、ｇＮＢは、ＵＥにRRCReconfigurationメッセージを送信し、これに対するＵＥからのRRCReconfigurationCompleteをｇＮＢが受信することによって、Signaling Radio Bearer 2（ＳＲＢ２）およびData Radio Bearer（ＤＲＢ）をセットアップするための再設定を行う。シグナリングのみの接続については、ＳＲＢ２およびＤＲＢがセットアップされないため、RRCReconfigurationに関するステップは省かれる。最後に、ｇＮＢは、初期コンテキストセットアップ応答（INITIAL CONTEXT SETUP RESPONSE）でセットアップ手順が完了したことをＡＭＦに通知する。
　したがって、本開示では、ｇＮｏｄｅＢとのNext Generation（ＮＧ）接続を動作時に確立する制御回路と、ｇＮｏｄｅＢとユーザ機器（ＵＥ：User Equipment）との間のシグナリング無線ベアラがセットアップされるように動作時にＮＧ接続を介してｇＮｏｄｅＢに初期コンテキストセットアップメッセージを送信する送信部と、を備える、5th Generation Core（５ＧＣ）のエンティティ（例えば、ＡＭＦ、ＳＭＦ等）が提供される。具体的には、ｇＮｏｄｅＢは、リソース割当設定情報要素(IE: Information Element)を含むRadio Resource Control（ＲＲＣ）シグナリングを、シグナリング無線ベアラを介してＵＥに送信する。そして、ＵＥは、リソース割当設定に基づき上りリンクにおける送信または下りリンクにおける受信を行う。
　＜２０２０年以降のＩＭＴの利用シナリオ＞
　図９は、５Ｇ　ＮＲのためのユースケースのいくつかを示す。3rd generation partnership project new radio（３ＧＰＰ　ＮＲ）では、多種多様なサービスおよびアプリケーションをサポートすることがＩＭＴ－２０２０によって構想されていた３つのユースケースが検討されている。大容量・高速通信（ｅＭＢＢ：enhanced mobile-broadband）のための第一段階の仕様の策定が終了している。現在および将来の作業には、ｅＭＢＢのサポートを拡充していくことに加えて、高信頼・超低遅延通信（ＵＲＬＬＣ：ultra-reliable and low-latency communications）および多数同時接続マシンタイプ通信（ｍＭＴＣ：massive machine-type communicationsのための標準化が含まれる。図９は、２０２０年以降のＩＭＴの構想上の利用シナリオのいくつかの例を示す（例えばＩＴＵ－Ｒ　Ｍ．２０８３　図２参照）。
　ＵＲＬＬＣのユースケースには、スループット、レイテンシ（遅延）、および可用性のような性能についての厳格な要件がある。ＵＲＬＬＣのユースケースは、工業生産プロセスまたは製造プロセスのワイヤレス制御、遠隔医療手術、スマートグリッドにおける送配電の自動化、交通安全等の今後のこれらのアプリケーションを実現するための要素技術の１つとして構想されている。ＵＲＬＬＣの超高信頼性は、TR 38.913によって設定された要件を満たす技術を特定することによってサポートされる。リリース１５におけるＮＲ　ＵＲＬＬＣでは、重要な要件として、目標とするユーザプレーンのレイテンシがＵＬ（上りリンク）で０．５ｍｓ、ＤＬ（下りリンク）で０．５ｍｓであることが含まれている。一度のパケット送信に対する全般的なＵＲＬＬＣの要件は、ユーザプレーンのレイテンシが１ｍｓの場合、３２バイトのパケットサイズに対してブロック誤り率（ＢＬＥＲ：block error rate）が１Ｅ－５であることである。
　物理レイヤの観点では、信頼性は、多くの採り得る方法で向上可能である。現在の信頼性向上の余地としては、ＵＲＬＬＣ用の別個のＣＱＩ表、よりコンパクトなＤＣＩフォーマット、ＰＤＣＣＨの繰り返し等を定義することが含まれる。しかしながら、この余地は、ＮＲが（ＮＲ　ＵＲＬＬＣの重要要件に関し）より安定しかつより開発されるにつれて、超高信頼性の実現のために広がりうる。リリース１５におけるＮＲ　ＵＲＬＬＣの具体的なユースケースには、拡張現実／仮想現実（ＡＲ／ＶＲ）、ｅ－ヘルス、ｅ－セイフティ、およびミッションクリティカルなアプリケーションが含まれる。
　また、ＮＲ　ＵＲＬＬＣが目標とする技術強化は、レイテンシの改善および信頼性の向上を目指している。レイテンシの改善のための技術強化には、設定可能なニューメロロジー、フレキシブルなマッピングによる非スロットベースのスケジューリング、グラントフリーの（設定されたグラントの）上りリンク、データチャネルにおけるスロットレベルでの繰り返し、および下りリンクでのプリエンプション（Pre-emption）が含まれる。プリエンプションとは、リソースが既に割り当てられた送信が停止され、当該既に割り当てられたリソースが、後から要求されたより低いレイテンシ／より高い優先度の要件の他の送信に使用されることを意味する。したがって、既に許可されていた送信は、後の送信によって差し替えられる。プリエンプションは、具体的なサービスタイプと無関係に適用可能である。例えば、サービスタイプＡ（ＵＲＬＬＣ）の送信が、サービスタイプＢ（ｅＭＢＢ等）の送信によって差し替えられてもよい。信頼性向上についての技術強化には、１Ｅ－５の目標ＢＬＥＲのための専用のＣＱＩ／ＭＣＳ表が含まれる。
　ｍＭＴＣ（massive machine type communication）のユースケースの特徴は、典型的には遅延の影響を受けにくい比較的少量のデータを送信する接続装置の数が極めて多いことである。装置には、低価格であること、および電池寿命が非常に長いことが要求される。ＮＲの観点からは、非常に狭い帯域幅部分を利用することが、ＵＥから見て電力が節約されかつ電池の長寿命化を可能にする１つの解決法である。
　上述のように、ＮＲにおける信頼性向上のスコープはより広くなることが予測される。あらゆるケースにとっての重要要件の１つであって、例えばＵＲＬＬＣおよびｍＭＴＣについての重要要件が高信頼性または超高信頼性である。いくつかのメカニズムが信頼性を無線の観点およびネットワークの観点から向上させることができる。概して、信頼性の向上に役立つ可能性がある２つ～３つの重要な領域が存在する。これらの領域には、コンパクトな制御チャネル情報、データチャネル/制御チャネルの繰り返し、および周波数領域、時間領域、および／または空間領域に関するダイバーシティがある。これらの領域は、特定の通信シナリオにかかわらず一般に信頼性向上に適用可能である。
　ＮＲ　ＵＲＬＬＣに関し、ファクトリーオートメーション、運送業、および電力の分配のような、要件がより厳しいさらなるユースケースが想定されている。厳しい要件とは、高い信頼性（１０－６レベルまでの信頼性）、高い可用性、２５６バイトまでのパケットサイズ、数μｓ程度までの時刻同期（time synchronization）（ユースケースに応じて、値を、周波数範囲および０．５ｍｓ～１ｍｓ程度の短いレイテンシ（例えば、目標とするユーザプレーンでの０．５ｍｓのレイテンシ）に応じて１μｓまたは数μｓとすることができる）である。
　さらに、ＮＲ　ＵＲＬＬＣについては、物理レイヤの観点からいくつかの技術強化が有り得る。これらの技術強化には、コンパクトなＤＣＩに関するＰＤＣＣＨ（Physical Downlink Control Channel）の強化、ＰＤＣＣＨの繰り返し、ＰＤＣＣＨのモニタリングの増加がある。また、ＵＣＩ（Uplink Control Information）の強化は、ｅｎｈａｎｃｅｄ　ＨＡＲＱ（Hybrid Automatic Repeat Request）およびＣＳＩフィードバックの強化に関係する。また、ミニスロットレベルのホッピングに関係するＰＵＳＣＨの強化、および再送信／繰り返しの強化が有り得る。用語「ミニスロット」は、スロットより少数のシンボルを含むTransmission Time Interval（ＴＴＩ）を指す（スロットは、１４個のシンボルを備える）。
　＜ＱｏＳ制御＞
　５ＧのＱｏＳ（Quality of Service）モデルは、ＱｏＳフローに基づいており、保証されたフロービットレートが求められるＱｏＳフロー（GBR：Guaranteed Bit Rate　ＱｏＳフロー）、および、保証されたフロービットレートが求められないＱｏＳフロー（非ＧＢＲ　ＱｏＳフロー）をいずれもサポートする。したがって、ＮＡＳレベルでは、ＱｏＳフローは、ＰＤＵセッションにおける最も微細な粒度のＱｏＳの区分である。ＱｏＳフローは、ＮＧ－Ｕインタフェースを介してカプセル化ヘッダ（encapsulation header）において搬送されるＱｏＳフローＩＤ（ＱＦＩ：QoS Flow ID）によってＰＤＵセッション内で特定される。
　各ＵＥについて、５ＧＣは、１つ以上のＰＤＵセッションを確立する。各ＵＥについて、ＰＤＵセッションに合わせて、ＮＧ－ＲＡＮは、例えば図８を参照して上に示したように少なくとも１つのData Radio Bearers（ＤＲＢ）を確立する。また、そのＰＤＵセッションのＱｏＳフローに対する追加のＤＲＢが後から設定可能である（いつ設定するかはＮＧ－ＲＡＮ次第である）。ＮＧ－ＲＡＮは、様々なＰＤＵセッションに属するパケットを様々なＤＲＢにマッピングする。ＵＥおよび５ＧＣにおけるＮＡＳレベルパケットフィルタが、ＵＬパケットおよびＤＬパケットとＱｏＳフローとを関連付けるのに対し、ＵＥおよびＮＧ－ＲＡＮにおけるＡＳレベルマッピングルールは、ＵＬ　ＱｏＳフローおよびＤＬ　ＱｏＳフローとＤＲＢとを関連付ける。
　図１０は、５Ｇ　ＮＲの非ローミング参照アーキテクチャ（non-roaming reference architecture）を示す（TS 23.501 v16.1.0, section 4.23参照）。Application Function（ＡＦ）（例えば、図９に例示した、５Ｇのサービスをホストする外部アプリケーションサーバ）は、サービスを提供するために３ＧＰＰコアネットワークとやり取りを行う。例えば、トラフィックのルーティングに影響を与えるアプリケーションをサポートするために、Network Exposure Function（ＮＥＦ）にアクセスすること、またはポリシー制御（例えば、ＱｏＳ制御）のためにポリシーフレームワークとやり取りすること（Policy Control Function（ＰＣＦ）参照）である。オペレーターによる配備に基づいて、オペレーターによって信頼されていると考えられるApplication Functionは、関連するNetwork Functionと直接やり取りすることができる。Network Functionに直接アクセスすることがオペレーターから許可されていないApplication Functionは、ＮＥＦを介することにより外部に対する解放フレームワークを使用して関連するNetwork Functionとやり取りする。
　図１０は、５Ｇアーキテクチャのさらなる機能単位、すなわち、Network Slice Selection Function（ＮＳＳＦ）、Network Repository Function（ＮＲＦ）、Unified Data Management（ＵＤＭ）、Authentication Server Function（ＡＵＳＦ）、Access and Mobility Management Function（ＡＭＦ）、Session Management Function（ＳＭＦ）、およびData Network（ＤＮ、例えば、オペレーターによるサービス、インターネットアクセス、またはサードパーティーによるサービス）をさらに示す。コアネットワークの機能およびアプリケーションサービスの全部または一部がクラウドコンピューティング環境において展開されかつ動作してもよい。
　したがって、本開示では、ＱｏＳ要件に応じたｇＮｏｄｅＢとＵＥとの間の無線ベアラを含むＰＤＵセッションを確立するために、動作時に、ＵＲＬＬＣサービス、ｅＭＭＢサービス、およびｍＭＴＣサービスの少なくとも１つに対するＱｏＳ要件を含む要求を５ＧＣの機能（例えば、ＮＥＦ、ＡＭＦ、ＳＭＦ、ＰＣＦ、ＵＰＦ等）の少なくとも１つに送信する送信部と、動作時に、確立されたＰＤＵセッションを使用してサービスを行う制御回路と、を備える、アプリケーションサーバ（例えば、５ＧアーキテクチャのＡＦ）が提供される。
　また、上述した実施の形態における「・・・部」という表記は、「・・・回路（circuitry）」、「・・・デバイス」、「・・・ユニット」、又は、「・・・モジュール」といった他の表記に置換されてもよい。
　また、上述した実施の形態において、RB数、周波数帯域幅、SCSといったパラメータの値は一例であって他の値でもよい。
　本開示はソフトウェア、ハードウェア、又は、ハードウェアと連携したソフトウェアで実現することが可能である。上記実施の形態の説明に用いた各機能ブロックは、部分的に又は全体的に、集積回路であるＬＳＩとして実現され、上記実施の形態で説明した各プロセスは、部分的に又は全体的に、一つのＬＳＩ又はＬＳＩの組み合わせによって制御されてもよい。ＬＳＩは個々のチップから構成されてもよいし、機能ブロックの一部または全てを含むように一つのチップから構成されてもよい。ＬＳＩはデータの入力と出力を備えてもよい。ＬＳＩは、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。集積回路化の手法はＬＳＩに限るものではなく、専用回路、汎用プロセッサ又は専用プロセッサで実現してもよい。また、ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。本開示は、デジタル処理又はアナログ処理として実現されてもよい。さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
　本開示は、通信機能を持つあらゆる種類の装置、デバイス、システム（通信装置と総称）において実施可能である。通信装置は無線送受信機（トランシーバー）と処理／制御回路を含んでもよい。無線送受信機は受信部と送信部、またはそれらを機能として、含んでもよい。無線送受信機（送信部、受信部）は、ＲＦ（Ｒａｄｉｏ　Ｆｒｅｑｕｅｎｃｙ）モジュールと１または複数のアンテナを含んでもよい。ＲＦモジュールは、増幅器、ＲＦ変調器／復調器、またはそれらに類するものを含んでもよい。通信装置の、非限定的な例としては、電話機（携帯電話、スマートフォン等）、タブレット、パーソナル・コンピューター（ＰＣ）（ラップトップ、デスクトップ、ノートブック等）、カメラ（デジタル・スチル／ビデオ・カメラ等）、デジタル・プレーヤー（デジタル・オーディオ／ビデオ・プレーヤー等）、着用可能なデバイス（ウェアラブル・カメラ、スマートウオッチ、トラッキングデバイス等）、ゲーム・コンソール、デジタル・ブック・リーダー、テレヘルス・テレメディシン（遠隔ヘルスケア・メディシン処方）デバイス、通信機能付きの乗り物又は移動輸送機関（自動車、飛行機、船等）、及び上述の各種装置の組み合わせがあげられる。
　通信装置は、持ち運び可能又は移動可能なものに限定されず、持ち運びできない又は固定されている、あらゆる種類の装置、デバイス、システム、例えば、スマート・ホーム・デバイス（家電機器、照明機器、スマートメーター又は計測機器、コントロール・パネル等）、自動販売機、その他ＩｏＴ（Ｉｎｔｅｒｎｅｔ　ｏｆ　Ｔｈｉｎｇｓ）ネットワーク上に存在し得るあらゆる「モノ（Things）」をも含む。
　通信には、セルラーシステム、無線ＬＡＮシステム、通信衛星システム等によるデータ通信に加え、これらの組み合わせによるデータ通信も含まれる。
　また、通信装置には、本開示に記載される通信機能を実行する通信デバイスに接続又は連結される、コントローラやセンサー等のデバイスも含まれる。例えば、通信装置の通信機能を実行する通信デバイスが使用する制御信号やデータ信号を生成するような、コントローラやセンサーが含まれる。
　また、通信装置には、上記の非限定的な各種装置と通信を行う、あるいはこれら各種装置を制御する、インフラストラクチャ設備、例えば、基地局、アクセスポイント、その他あらゆる装置、デバイス、システムが含まれる。
　本開示の非限定的な実施例に係る端末は、第１の信号を受信する受信回路と、前記第１の信号を受信した後に第２の信号を送信する送信回路と、を具備し、前記第２の信号の送信タイミングは、前記第１の信号のリソースサイズに関するパラメータに応じて異なる。
　本開示の非限定的な実施例において、前記パラメータの値が閾値より大きい場合の前記第１の信号と前記第２の信号との間の最小時間間隔が設定される。
　本開示の非限定的な実施例において、前記パラメータの値が閾値より大きい場合の前記第１の信号と前記第２の信号との間の時間リソースの間隔は、前記最小時間間隔以上に設定される。
　本開示の非限定的な実施例において、前記パラメータの値が前記閾値以下の場合、前記第１の信号と前記第２の信号との間の時間リソース間隔は、前記最小時間間隔より短く設定される。
　本開示の非限定的な実施例において、前記第１の信号と前記第２の信号との間の時間リソース間隔は、前記パラメータの値に応じて異なる。
　本開示の非限定的な実施例において、前記パラメータは、前記第１の信号に割り当てられる物理リソースブロック（PRB）数、前記第１の信号に割り当てられるトランスポートブロックサイズ（TBサイズ）、及び、前記第１の信号に割り当てられるTBサイズの算出に用いるTB scaling factorの少なくとも一つである。
　本開示の非限定的な実施例において、前記パラメータに応じた前記送信タイミングの設定は、capabilityが制限される端末のアクセスをセルが許可している場合に適用される。
　本開示の非限定的な実施例において、前記パラメータに応じた前記送信タイミングの設定は、capabilityが制限される端末であると基地局が見なしている端末に対して割り当てられる前記第１の信号及び前記第２の信号に対して適用される。
　本開示の非限定的な実施例において、前記第１の信号は、ランダムアクセス手順におけるランダムアクセス応答を送信する下りリンクチャネルの信号であり、前記第２の信号は、ランダムアクセス手順におけるMessage 3を送信する上りリンクチャネルの信号である。
　本開示の非限定的な実施例に係る基地局は、第１の信号を送信する送信回路と、前記第１の信号を送信した後に第２の信号を受信する受信回路と、を具備し、前記第２の信号の受信タイミングは、前記第１の信号のリソースサイズに関するパラメータに応じて異なる。
　本開示の非限定的な実施例に係る通信方法において、端末は、第１の信号を受信し、前記第１の信号を受信した後に第２の信号を送信し、前記第２の信号の送信タイミングは、前記第１の信号のリソースサイズに関するパラメータに応じて異なる。
　本開示の非限定的な実施例に係る通信方法において、基地局は、第１の信号を送信し、前記第１の信号を送信した後に第２の信号を受信し、前記第２の信号の受信タイミングは、前記第１の信号のリソースサイズに関するパラメータに応じて異なる。
　２０２２年１１月７日出願の特願２０２２－１７８２１６の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
　本開示の一実施例は、無線通信システムに有用である。
　１００　基地局
　１０１，２０６　制御部
　１０２　DCI生成部
　１０３　RAR生成部
　１０４　上位レイヤ信号生成部
　１０５，２０７　符号化・変調部
　１０６，２０８　信号配置部
　１０７，２０９　送信部
　１０８，２０１　アンテナ
　１０９，２０２　受信部
　１１０　信号分離部
　１１１，２０５　復調・復号部
　２００　端末
　２０３　信号分離部
　２０４　DCI検出部
 

 

Claims (12)

  1. 　第１の信号を受信する受信回路と、
    　前記第１の信号を受信した後に第２の信号を送信する送信回路と、
    　を具備し、
    　前記第２の信号の送信タイミングは、前記第１の信号のリソースサイズに関するパラメータに応じて異なる、
    　端末。
  2. 　前記パラメータの値が閾値より大きい場合の前記第１の信号と前記第２の信号との間の最小時間間隔が設定される、
    　請求項１に記載の端末。
  3. 　前記パラメータの値が閾値より大きい場合の前記第１の信号と前記第２の信号との間の時間リソースの間隔は、前記最小時間間隔以上に設定される、
    　請求項２に記載の端末。
  4. 　前記パラメータの値が前記閾値以下の場合、前記第１の信号と前記第２の信号との間の時間リソース間隔は、前記最小時間間隔より短く設定される、
    　請求項２に記載の端末。
  5. 　前記第１の信号と前記第２の信号との間の時間リソース間隔は、前記パラメータの値に応じて異なる、
    　請求項２に記載の端末。
  6. 　前記パラメータは、前記第１の信号に割り当てられる物理リソースブロック（PRB）数、前記第１の信号に割り当てられるトランスポートブロックサイズ（TBサイズ）、及び、前記第１の信号に割り当てられるTBサイズの算出に用いるTB scaling factorの少なくとも一つである、
    　請求項１に記載の端末。
  7. 　前記パラメータに応じた前記送信タイミングの設定は、capabilityが制限される端末のアクセスをセルが許可している場合に適用される、
    　請求項１に記載の端末。
  8. 　前記パラメータに応じた前記送信タイミングの設定は、capabilityが制限される端末であると基地局が見なしている端末に対して割り当てられる前記第１の信号及び前記第２の信号に対して適用される、
    　請求項１に記載の端末。
  9. 　前記第１の信号は、ランダムアクセス手順におけるランダムアクセス応答を送信する下りリンクチャネルの信号であり、
    　前記第２の信号は、ランダムアクセス手順におけるMessage 3を送信する上りリンクチャネルの信号である、
    　請求項１に記載の端末。
  10. 　第１の信号を送信する送信回路と、
    　前記第１の信号を送信した後に第２の信号を受信する受信回路と、
    　を具備し、
    　前記第２の信号の受信タイミングは、前記第１の信号のリソースサイズに関するパラメータに応じて異なる、
    　基地局。
  11. 　端末は、
    　第１の信号を受信し、
    　前記第１の信号を受信した後に第２の信号を送信し、
    　前記第２の信号の送信タイミングは、前記第１の信号のリソースサイズに関するパラメータに応じて異なる、
    　通信方法。
  12. 　基地局は、
    　第１の信号を送信し、
    　前記第１の信号を送信した後に第２の信号を受信し、
    　前記第２の信号の受信タイミングは、前記第１の信号のリソースサイズに関するパラメータに応じて異なる、
    　通信方法。
PCT/JP2023/025372 2022-11-07 2023-07-10 端末、基地局、及び、通信方法 WO2024100924A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022178216 2022-11-07
JP2022-178216 2022-11-07

Publications (1)

Publication Number Publication Date
WO2024100924A1 true WO2024100924A1 (ja) 2024-05-16

Family

ID=91032101

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/025372 WO2024100924A1 (ja) 2022-11-07 2023-07-10 端末、基地局、及び、通信方法

Country Status (1)

Country Link
WO (1) WO2024100924A1 (ja)

Similar Documents

Publication Publication Date Title
WO2021210264A1 (ja) 移動局、基地局、受信方法及び送信方法
US20220256557A1 (en) Communication apparatuses and communication methods for dci for v2x communication apparatuses
US20220287008A1 (en) Communication apparatuses and communication methods for utilization of released resource
US20230171802A1 (en) Terminal, and communication method
US20230057436A1 (en) Communication apparatuses and communication methods for utilization of reserved resource
WO2024100924A1 (ja) 端末、基地局、及び、通信方法
WO2023013204A1 (ja) 端末、基地局、及び、通信方法
WO2023139852A1 (ja) 端末、基地局、及び、通信方法
WO2022201652A1 (ja) 端末、基地局、及び、通信方法
WO2024024259A1 (ja) 端末、基地局、及び、通信方法
WO2023013192A1 (ja) 端末、基地局及び通信方法
WO2023053564A1 (ja) 端末、基地局、及び、通信方法
WO2022195952A1 (ja) 端末、基地局及び通信方法
WO2022201651A1 (ja) 基地局、端末、及び、通信方法
WO2023203938A1 (ja) 端末、基地局、通信方法及び集積回路
WO2024100918A1 (ja) 端末、基地局及び通信方法
WO2022239289A1 (ja) 通信装置、及び、通信方法
WO2023013191A1 (ja) 通信装置、及び、通信方法
WO2023013217A1 (ja) 基地局、端末及び通信方法
WO2023100471A1 (ja) 基地局、端末及び通信方法
WO2024095677A1 (ja) 端末、基地局、通信方法及び集積回路
WO2023119756A1 (ja) 通信装置及び通信方法
WO2022030075A1 (ja) 端末、基地局、及び、通信方法
US20240188061A1 (en) Terminal, base station, and communication method
WO2023181557A1 (ja) 端末、基地局及び通信方法