Terminals, wireless communication methods, base stations and systems

Abstract

Improve coverage of random access procedures by properly receiving Msg4 for PRACH repeats. [Solution] A terminal according to one aspect of the present disclosure includes a transmitting unit that transmits one or more repetitions of a plurality of repetitions of a physical random access channel (PRACH) using each of the plurality of different beams, and a control unit that controls the reception of a response to the PRACH in a downlink beam having the same spatial relationship as each of the plurality of different beams used to transmit the one or more repetitions, wherein the spatial relationship overlaps in the time domain by at least a portion.

Description

Technical Field

[0001] This disclosure relates to a terminal, a wireless communication method, a base station, and a system in a next-generation mobile communication system.

Background Art

[0002] In a Universal Mobile Telecommunications System (UMTS) network, Long Term Evolution (LTE) was standardized for the purpose of further high-speed data rates, low latency, etc. (Non-Patent Document 1). Also, for the purpose of further large capacity and sophistication of LTE (Third Generation Partnership Project (3GPP) Release (Rel.) 8, 9), LTE-Advanced (3GPP Rel. 10-14) was standardized.

[0003] Successor systems to LTE (for example, also referred to as 5th generation mobile communication system (5G), 5G+(plus), 6th generation mobile communication system (6G), New Radio (NR), 3GPP Rel. 15 and later, etc.) are also under consideration.

Prior Art Documents

Non-Patent Documents

[0004]

Non-Patent Document 1

Summary of the Invention

[0005] Improvements to coverage are being considered for future wireless communication systems (e.g., NR).

[0006] However, the random access procedure for improving coverage is not clear. Without such a clear random access procedure, there is a risk of reduced communication throughput.

[0007] Therefore, one of the objectives of this disclosure is to provide terminals, wireless communication methods, base stations, and systems that improve coverage of random access procedures. [Means for solving the problem]

[0008] A terminal according to one aspect of the present disclosure includes a transmitting unit that transmits one or more repetitions of a plurality of repetitions of a physical random access channel (PRACH) using each of the plurality of different beams, and a control unit that controls the reception of a response to the PRACH in a downlink beam having the same spatial relationship as each of the plurality of different beams used to transmit the one or more repetitions, wherein the spatial relationship overlaps in at least part in the time domain. [Effects of the Invention]

[0009] According to one aspect of this disclosure, coverage of random access procedures can be improved. [Brief explanation of the drawing]

[0010] [Figure 1] Figure 1 shows an example of RACH configuration information elements. [Figure 2] Figures 2A and 2B show an example of the association between PRACH occasions and beams. [Figure 3] Figure 3 shows an example of PRACH settings. [Figure 4] Figure 4 shows an example of a PRACH mask index value. [Figure 5] Figures 5A and 5B show an example of a monitoring method for RAR windows that do not overlap in time. [Figure 6] Figures 6A and 6B show another example of a monitoring method for RAR windows that do not overlap in time. [Figure 7] Figures 7A and 7B show an example of a monitoring method for RAR windows that overlap in time. [Figure 8] Figure 8 shows another example of a monitoring method for RAR windows that overlap in time. [Figure 9] Figures 9A and 9B show examples of PUSCH transmission methods 1 and 2 for non-overlapping RAR windows. [Figure 10] Figure 10 shows an example of PUSCH transmission method 3 for non-overlapping RAR windows. [Figure 11] Figures 11A and 11B show examples of PUSCH transmission methods 2 and 3 for overlapping RAR windows. [Figure 12] Figure 12 shows an example of a TAC within RAR. [Figure 13] Figure 13 shows an example of PUSCH. [Figure 14] Figures 14A and 14B show examples of DL beam indicating methods 0 and 1. [Figure 15] Figure 15 shows an example of DL beam direction method 2 and RO case 2. [Figure 16] Figure 16 shows an example of UL beam direction method 1. [Figure 17] Figures 17A and 17B show examples of UL beam designation methods 2a and 2b. [Figure 18] Figure 18 shows variations of DL beam designation method 2 and an example of a combination with UL beam designation method 2a. [Figure 19] Figures 19A and 19B show examples of RA conflict resolution timer operations 1 and 2. [Figure 20] Figures 20A and 20B show an example of the unit resource 1 / 2. [Figure 21] Figures 21A and 21B show an example of the unit resource 3. [Figure 22] Figures 22A and 22B show an example of the unit resource 4 / 5. [Figure 23] Figures 23A and 23B show another example of the unit resource 5. [Figure 24] Figure 24 shows yet another example of the unit resource 5. [Figure 25] Figures 25A and 25B show an example of the unit resource 2 according to Variation A. [Figure 26] Figures 26A and 26B show an example of the unit resource 5 according to Variation A. [Figure 27] Figures 27A and 27B show an example of Variation A1. [Figure 28] Figure 28 shows an example of the transmission operation 1. [Figure 29] Figure 29 shows an example of the transmission operation 2. [Figure 30] Figure 30 shows an example of the transmission operation 3. [Figure 31] Figure 31 shows an example of the monitoring operation 2. [Figure 32] Figure 32 shows an example of the window operation 1 / 2. [Figure 33] Figure 33 shows an example of the window operation 3a / 3b / 3c. [Figure 34] Figures 34A and 34B show an example of Embodiment #A9. [Figure 35] Figure 35 shows an example of the RA setting for BFR. [Figure 36] Figures 36A to 36D show an example of the RAR window according to Embodiment #4. [Figure 37] Figures 37A and 37B show an example of the RAR window for PRACH repetition within a short period according to Embodiment #4. [Figure 38]Figures 38A and 38B show another example of a RAR window for short-term PRACH iterations according to Embodiment #4. [Figure 39] Figures 39A and 39B show an example of Option A of Embodiment #10. [Figure 40] Figures 40A and 40B show an example of option B of embodiment #10. [Figure 41] Figures 41A and 41B show an example of Option A of Embodiment #11. [Figure 42] Figures 42A and 42B show an example of Option B of Embodiment #11. [Figure 43] Figure 43 shows an example of a schematic configuration of a wireless communication system according to one embodiment. [Figure 44] Figure 44 shows an example of the configuration of a base station according to one embodiment. [Figure 45] Figure 45 shows an example of the configuration of a user terminal according to one embodiment. [Figure 46] Figure 46 shows an example of the hardware configuration of a base station and a user terminal according to one embodiment. [Figure 47] Figure 47 shows an example of a vehicle according to one embodiment. [Modes for carrying out the invention]

[0011] (TCI, spatial relations, QCL) In NR, it is being considered to control the receive processing (e.g., at least one of receive, demapping, demodulation, and decoding) and transmit processing (e.g., transmit, mapping, precoding, modulation, and encoding) of at least one of the signal and channel (referred to as signal / channel) at the UE based on the Transmission Configuration Indication state (TCI state).

[0012] The TCI state may represent the one applied to the downlink signal / channel. The equivalent of the TCI state applied to the uplink signal / channel may be expressed as a spatial relation.

[0013] TCI status refers to information about signal / channel quasi-co-location (QCL), and may also be called spatial reception parameters or spatial relation information. TCI status may be set for each channel or signal in the UE.

[0014] QCL is an index that indicates the statistical properties of a signal / channel. For example, if two signals / channels have a QCL relationship, it may mean that we can assume that at least one of the following is identical between these different signals / channels: Doppler shift, Doppler spread, average delay, delay spread, and spatial parameter (e.g., spatial Rx parameter).

[0015] The spatial reception parameters may correspond to the UE's received beam (e.g., the received analog beam), and the beam may be identified based on the spatial QCL. In this disclosure, QCL (or at least one element of QCL) may be interpreted as sQCL (spatial QCL).

[0016] QCL may have multiple types (QCL types). For example, there may be four QCL types A and D that differ in the parameters (or parameter sets) that can be assumed to be the same, and these parameters (which may also be called QCL parameters) are shown below: • QCL Type A (QCL-A): Doppler shift, Doppler spread, mean delay and delay spread, • QCL Type B (QCL-B): Doppler shift and Doppler spread, • QCL Type C (QCL-C): Doppler shift and mean delay, • QCL Type D (QCL-D): Spatial reception parameters.

[0017] The assumption by the UE that one control resource set (CORESET), channel, or reference signal is in a specific QCL (e.g., QCL type D) relationship with another CORESET, channel, or reference signal may be called a QCL assumption.

[0018] The UE may determine at least one of the transmit beam (Tx beam) and receive beam (Rx beam) of a signal / channel based on the TCI state or QCL assumption of the signal / channel.

[0019] The TCI state may, for example, be information regarding the QCL between the target channel (in other words, the reference signal (RS) for that channel) and another signal (e.g., another RS). The TCI state may be set (indicated) by upper-layer signaling, physical layer signaling, or a combination thereof.

[0020] Physical layer signaling may include, for example, Downlink Control Information (DCI).

[0021] The channel on which the TCI state or spatial relationship is set (specified) may be, for example, at least one of the following: Physical Downlink Shared Channel (PDSCH), Physical Downlink Control Channel (PDCCH), Physical Uplink Shared Channel (PUSCH), or Physical Uplink Control Channel (PUCCH).

[0022] Furthermore, the RS that has a QCL relationship with the channel may be at least one of the following: a Synchronization Signal Block (SSB), a Channel State Information Reference Signal (CSI-RS), a Sounding Reference Signal (SRS), a Tracking CSI-RS (also called a Tracking Reference Signal (TRS)), or a QCL detection reference signal (also called a QRS).

[0023] An SSB is a signal block that includes at least one of a Primary Synchronization Signal (PSS), a Secondary Synchronization Signal (SSS), and a Physical Broadcast Channel (PBCH). An SSB may also be called an SS / PBCH block.

[0024] The RS of a QCL type X in a TCI state may also mean the RS in the relationship between a channel / signal (or its DMRS) and a QCL type X, and this RS may also be called the QCL source of the QCL type X in that TCI state.

[0025] (Initial access procedure) In the initial access procedure, the UE (RRC_IDLE mode) receives the SS / PBCH block (SSB), sends Msg.1 (PRACH / Random Access Preamble / Preamble), receives Msg.2 (PDCCH, PDSCH including Random Access Response (RAR)), sends Msg.3 (PUSCH scheduled by the RAR UL grant), and receives Msg.4 (PDCCH, PDSCH including UE contention resolution identity). Subsequently, when the base station (network) sends an ACK to Msg.4 from the UE, the RRC connection is established (RRC_CONNECTED mode).

[0026] SSB reception includes PSS detection, SSS detection, PBCH-DMRS detection, and PBCH reception. PSS detection involves detecting part of the physical cell ID (PCI), detecting (synchronizing) OFDM symbol timing, and (coarse) frequency synchronization. SSS detection includes detecting the physical cell ID. PBCH-DMRS detection includes detecting part of the SSB index within a half-radio frame (5ms). PBCH reception includes detecting the system frame number (SFN) and radio frame timing (SSB index), receiving configuration information for receiving remaining minimum system information (RMSI, SIB1), and determining whether the UE can camp in that cell (carrier).

[0027] SSB has a bandwidth of 20 RB and a duration of 4 symbols. The transmission period for SSB can be set from {5, 10, 20, 40, 80, 160} ms. Within a half frame, multiple symbol positions for SSB are defined based on the frequency range (FR1, FR2).

[0028] A PBCH has a 56-bit payload. N repetitions of the PBCH are transmitted within an 80ms period. N depends on the SSB transmission period.

[0029] System information consists of MIBs carried by PBCH, RMSI (SIB1), and other system information (OSI). SIB1 contains information for RACH configuration and RACH procedures. The time / frequency resource relationship between SSB and PDCCH monitoring resources for SIB1 is set by PBCH.

[0030] A base station using beam correspondence transmits multiple SSBs using multiple beams during each SSB transmission cycle. Each of the multiple SSBs has multiple SSB indices. When a UE detects one SSB, it transmits a PRACH in the RACH occasion associated with that SSB index and receives a RAR in the RAR window.

[0031] (Beam and coverage) In the high-frequency band, if beamforming is not applied to the synchronization / reference signal, coverage will be narrow, making it difficult for the UE to find the base station. On the other hand, if beamforming is applied to the synchronization / reference signal to ensure coverage, a strong signal will reach in certain directions, but the signal will be even weaker in other directions. If the direction of the UE is unknown at the base station before the UE connects, it is impossible to transmit the synchronization / reference signal using a beam directed only in the correct direction. One possible solution is for the base station to transmit multiple synchronization / reference signals, each with a beam directed in a different direction, and for the UE to recognize which beam it has detected. Using a narrow beam for coverage requires transmitting many synchronization / reference signals, which increases overhead and may reduce frequency utilization efficiency.

[0032] Using wider beams (wider beams) to reduce overhead by decreasing the number of beams (synchronization / reference signals) results in narrower coverage.

[0033] In future wireless communication systems (e.g., 6G), the use of frequency bands such as millimeter waves and terahertz waves is expected to increase further. It is conceivable that communication services could be provided by constructing cell area / coverage using numerous narrow beams.

[0034] Possible approaches include expanding the area using existing FR2 beams and utilizing higher frequency bands than existing FR2 beams. To achieve these goals, improvements in beam management are preferable, in addition to multi-TRP and reconfigurable intelligent surface (RIS) systems.

[0035] Coverage extensions, including PRACH extensions for frequency range (FR) 2, are being considered. For example, PRACH repetition using the same beam or multiple different beams is being explored. This PRACH extension may also be applied to FR1.

[0036] The PRACH extension may be applied to the short PRACH format or to other formats.

[0037] As shown in the example in Figure 1, the common RACH configuration (RACH-ConfigCommon) may include the general RACH configuration (rach-ConfigGeneric), the total number of RA preambles (totalNumberOfRA-Preambles), and the SSBs and contention-based (CB) preambles per SSB for each RACH occasion (ssb-perRACH-OccasionAndCB-PreamblesPerSSB). rach-ConfigGeneric may also include the PRACH configuration index (prach-ConfigurationIndex) and the message 1FDM (msg1-FDM, the number of PRACH occasions FDMed within one time instance). ssb-perRACH-OccasionAndCB-PreamblesPerSSB may include the number of CB preambles per SSB for 1 / 8 (oneEighth, where one SSB is associated with eight RACH occasions).

[0038] For a Type 1 random access procedure (a 4-step random access procedure, messages 1 / 2 / 3 / 4), the UE may apply the number of SS / PBCH blocks N associated with a single PRACH occasion and the number of CB preambles R per valid PRACH occasion and per SS / PBCH block using ssb-perRACH-OccasionAndCB-PreamblesPerSSB.

[0039] For a Type 1 random access procedure, or a Type 2 random access procedure (2-step random access procedure, message A / B) with a PRACH occasion setting independent of the Type 1 random access procedure, if N < 1, one SS / PBCH block is mapped to 1 / N consecutive valid RACH occasions, and for each valid PRACH occasion, R CB preambles are generated, each with a consecutive index associated with the SS / PBCH block index, starting from preamble index 0. If N >= 1, for each valid PRACH occasion, R CB preambles are generated, each with a consecutive index associated with the SS / PBCH block index n (0 <= n < -N-1), starting from preamble index n·N_preamble^total / N. Here, N_preamble^total is given by totalNumberOfRA-Preambles for a Type 1 random access procedure, and by msgA-TotalNumberOfRA-Preambles for a Type 2 random access procedure with a PRACH occasion setting independent of the Type 1 random access procedure. N_preamble^total is a multiple of N.

[0040] Starting from frame 0, the association period for mapping SS / PBCH blocks to PRACH occasions is the minimum value in the set determined by the PRACH setting period, according to the relationship between the PRACH setting period and the association period (the number of PRACH setting periods) (the relationship defined in the specification), such that N_Tx^SSB SS / PBCH block indices are mapped to PRACH occasions at least once within that association period. Here, the UE obtains N_Tx^SSB from the value of ssb-PositionsInBurst in SIB1 or in the Common Serving Cell Configuration (ServingCellConfigCommon). If, after an integer number of mapping cycles from SS / PBCH block indices to PRACH occasions within the association period, there is a set of PRACH occasions or PRACH preambles that are not mapped to N_Tx^SSB SS / PBCH block indices, then one SS / PBCH block indice is also not mapped to that set of PRACH occasions or PRACH preambles. The association pattern period is determined to include one or more association periods, such that the pattern between the PRACH occasion and the SS / PBCH block index repeats at most every 160ms. If, after an integer number of association periods, there is a PRACH occasion that is not associated with an SS / PBCH block index, that PRACH occasion is not used for PRACH.

[0041] For PRACH setting periods of 10, 20, 40, 80, and 160 [msec], the association periods are {1,2,4,8,16}, {1,2,4,8}, {1,2,4}, {1,2}, and {1}, respectively.

[0042] Figure 2A shows an example of the association between PRACH occasions (RACH occasions (RO)) and beams (SSB / CSI-RS) (Mapping 1). When ssb-perRACH-OccasionAndCB-PreamblesPerSSB indicates oneHalf,n16 (N=1 / 2, R=16) and msg1-FDM is 4, four ROs are FDM'd in one time instance, and one SSB is mapped to two ROs. Preamble indices 0 to 15 are associated with the two ROs, and preamble indices 0 to 15 are associated with SS0B. Thus, when N<1, one SSB is mapped to multiple ROs. This increases the RO capacity per beam.

[0043] Figure 2B shows another example of RO-beam association (Mapping 2). When ssb-perRACH-OccasionAndCB-PreamblesPerSSB shows n4,n16 (N=4, R=16), msg1-FDM is 4, and N_preamble^total is 64, then in one time instance, four ROs are FDM'd and four SSBs are mapped to one RO. One RO is associated with SSB0 through 3. SSB0 is associated with preamble indices 0 through 15, SSB1 with preamble indices 15 through 31, SSB2 with preamble indices 32 through 47, and SSB3 with preamble indices 48 through 63. Thus, the same RO is associated with different SS / PBCH block indices, and different preambles use different SS / PBCH block indices. The base station can distinguish the associated SS / PBCH block indices by the received PRACH.

[0044] The random access preamble can only be transmitted on time resources specified in the random access configuration of the specification, and depends on whether it is FR1 or FR2, and the spectrum type (paired spectrum / supplementary uplink (SUL) / unpaired spectrum). The PRACH configuration index is given by the upper layer parameter prach-ConfigurationIndex, or by msgA-PRACH-ConfigurationIndex, if set. In the specification, each value of the PRACH configuration index is associated with at least one of the following: preamble format, x and y in n_f (frame number) mod x = y, subframe number, start symbol, number of PRACH slots in the subframe, number of time domain PRACH occasions N_t^RA,slot in the PRACH slot, and PRACH duration N_dur^RA (Figure 3).

[0045] Whether a PRACH iteration can be applied to a scenario depends on the type of RACH procedure triggered by different purposes. The type of RACH procedure may be at least one of the following: Contention-free random access (CFRA), PDCCH ordered RA (RA initiated by a PDCCH order), CFRA for beam failure recovery (BFR), CFRA for system information (SI) requests, CFRA for reconfiguration with sync, etc. Contention-based random access (CBRA), RAs triggered by MAC entities, RAs triggered by RRCs with events, CBRAs for BFRs, etc. • 4-step RACH. • 2-step RACH.

[0046] However, the configuration / procedure for PRACH repetition is unclear. For example, how PRACH resources for repetition (e.g., repetition pattern, number of repetitions) are configured, the UE behavior of preamble repetition transmission, and the impact of RACH on counters / timers are unclear. If such configuration / procedures are unclear, there is a risk of deterioration in communication quality / communication throughput.

[0047] (RA response window) The RA Response Window (ra-ResponseWindow) is a time window for monitoring the RA Response (RAR) (SpCell only). The RA Contention Resolution Timer (ra-ContentionResolutionTimer) is a timer for RA conflict resolution (SpCell only). The Msg.B Response Window is a time window for monitoring the RA Response (RAR) for 2-step RA types (SpCell only).

[0048] When the RA preamble is sent, the MAC entity performs actions 1 through 3 below, regardless of the possibility of a measurement gap occurring.

[0049] [Operation 1] If a contention-free RA preamble for a BFR request is sent by that MAC entity, that MAC entity performs the following actions 1-1 and 1-2: [[Action 1-1]] The MAC entity initiates the ra-ResponseWindow configured within the BFR setting (BeamFailureRecoveryConfig) during the first PDCCH occasion following the end of the RA preamble transmission. [[Operation 1-2]] The MAC entity monitors PDCCH transmissions in the search space indicated by the BFR search space ID (recoverySearchSpaceId) of the SpCell, which is identified by the C-radio network temporary identifier (RNTI), while the ra-ResponseWindow is running.

[0050] [Operation 2] Otherwise, the MAC entity performs actions 2-1 and 2-2 below. [[Operation 2-1]] The MAC entity initiates the ra-ResponseWindow configured within the Common RACH Configuration (RACH-ConfigCommon) during the first PDCCH occasion following the end of the RA preamble transmission. [[Operation 2-2]] The MAC entity monitors the PDCCH transmission of SpCells for RAR identified by RA-RNTI while ra-ResponseWindow is running.

[0051] [Operation 3] If the ra-ResponseWindow set in BeamFailureRecoveryConfig expires and a PDCCH transmission on the search space indicated by the recoverySearchSpaceId addressed to C-RNTI is received on the serving cell from which the preamble was sent, or if the ra-ResponseWindow set in RACH-ConfigCommon expires and an RAR containing an RA preamble identifier matching the transmitted preamble index (PREAMBLE_INDEX) is received, the MAC entity considers the RAR reception a failure and increments the preamble transmission counter (PREAMBLE_TRANSMISSION_COUNTER) by 1.

[0052] The MAC entity may stop the ra-ResponseWindow after successfully receiving a RAR containing RA preamble identifiers that match the transmitted PREAMBLE_INDEX (it may stop monitoring for RARs).

[0053] For PDCCH monitoring within the RA response window, there are two cases: PDCCH for the base station's response to the BFR, and PDCCH for the RAR. The following may apply to both cases.

[0054] When an MSGA (Msg.A) preamble is sent, regardless of the possibility of a measurement gap occurring, the MAC entity performs actions 4 through 6 below.

[0055] [Operation 4] The MAC entity initiates a Msg.B response window (msgB-ResponseWindow) within the PDCCH monitoring window defined in the specification.

[0056] The msgB-ResponseWindow may begin at the first symbol of the earliest CORESET in which the UE is configured to receive a PDCCH for a type 1-PDCCH CSS set, which is at least one symbol after the last symbol of the PRACH occasion corresponding to the PRACH transmission. The length of the msgB-ResponseWindow may correspond to the SCS for the type 1-PDCCH CSS set.

[0057] [Operation 5] The MAC entity monitors the PDCCH transmission of SpCells for RAR identified by MSGB-RNTI while the msgB-ResponseWindow is running.

[0058] [Operation 6] If a C-RNTI MAC CE is included within its MSGA, that MAC entity monitors the PDCCH transmission of the SpCell for RAR identified by C-RNTI while the msgB-ResponseWindow is running.

[0059] The RA-RNTI associated with a PRACH occasion in which an RA preamble is sent is calculated as follows: RA-RNTI = 1+s_id+14×t_id+14×80×f_id+14×80×8×ul_carrier_id

[0060] Here, s_id is the index of the first OFDM symbol in the PRACH occasion (0 <= s_id < 14). t_id is the index of the first slot of the PRACH occasion in the system frame (0 <= t_id < 80). The subcarrier spacing (SCS) for determining t_id is based on the value of μ. f_id is the index of the PRACH occasion in the frequency domain (0 <= f_id < 8). ul_carrier_id is the UL carrier used for RA preamble transmission (0 for normal uplink (NUL) carriers, 1 for supplementary uplink (SUL) carriers). RA-RNTI is calculated according to the specification. RA-RNTI is the RNTI for 4-step RACH.

[0061] The MSGB-RNTI associated with a PRACH occasion in which an RA preamble is sent is calculated as follows: MSGB-RNTI = 1+s_id+14×t_id+14×80×f_id+14×80×8×ul_carrier_id+14×80×8×2

[0062] Here, s_id is the index of the first OFDM symbol of the PRACH occasion (0 <= s_id < 14). t_id is the index of the first slot of the PRACH occasion within the system frame (0 <= t_id < 80). The subcarrier spacing (SCS) for the determination of t_id is based on the value of μ. f_id is the index of the PRACH occasion in the frequency domain (0 <= f_id < 8). ul_carrier_id is the UL carrier used for RA preamble transmission (0 for normal uplink (NUL) carrier and 1 for supplementary uplink (SUL) carrier). MSGB-RNTI is the RNTI for two-step RACH.

[0063] (PDCCH order) <DCI format for PDCCH order> DCI format 1_0 includes an identifier field of the DCI format, a bit field always set to 1, and a frequency domain resource assignment field. The cyclic redundancy check (CRC) of DCI format 1_0 is scrambled by C-RNTI. When the frequency domain resource assignment field is all 1, that DCI format 1_0 is for a random access procedure started by a PDCCH order, and the remaining fields are a random access preamble, a UL / supplementary Uplink (SUL) indicator, an SS / PBCH index (SSB index), a PRACH mask index, and reserved bits (12 bits).

[0064] <PRACH occasion> For PRACH transmissions triggered by a PDCCH order, the PRACH mask index field indicates the PRACH occasion of the PRACH transmission associated with the SS / PBCH block index indicated by the SS / PBCH block index field of the PDCCH order, provided the value of the random access preamble index field is non-zero.

[0065] For PRACH transmissions triggered by higher layers (PRACH transmissions not triggered by PDCCH orders), if an ssb-ResourceList is provided, the PRACH mask index is indicated by ra-ssb-OccasionMaskIndex. This ra-ssb-OccasionMaskIndex indicates the PRACH occasion for PRACH transmissions associated with the selected SS / PBCH block index.

[0066] PRACH occasions are mapped sequentially for each corresponding SS / PBCH block index. The indexing of PRACH occasions, indicated by the mask index value, is reset for each SS / PBCH block index and for each consecutive PRACH occasion mapping cycle. In the first available mapping cycle, the UE selects the PRACH occasion indicated by the PRACH mask index value for the specified SS / PBCH block index for PRACH transmission.

[0067] For the specified preamble index, the order of the PRACH occasions is as follows: • Firstly, an increasing order of frequency resource indices for frequency-multiplexed PRACH occasions. Secondly, the time resource index increases for time-multiplexed PRACH occasions within a PRACH slot. Thirdly, the PRACH slot index is in ascending order.

[0068] For a PRACH transmission triggered in response to a request from the upper layer, if a csirs-ResourceList is provided, the value of ra-OccasionList indicates a list of PRACH occasions for the PRACH transmission, and the PRACH occasion is associated with the selected CSI-RS index indicated by the csi-RS. The indexing of the PRACH occasions indicated by ra-OccasionList is reset for each association pattern period.

[0069] FIG. 4 is a diagram showing an example of a PRACH mask index value. The PRACH mask index value / msgA-SSB-SharedRO-MaskIndex value is associated with the allowed PRACH occasions (values of PRACH occasion indices) of the SSB.

[0070] <Random Access Procedure in the MAC Entity> The random access procedure is started by a PDCCH order, the MAC entity itself, or the RRC for events compliant with the specification. Within the MAC entity, only one random access procedure can be in progress at any given time. The random access procedure for a SCell is started only by a PDCCH order with a ra-PreambleIndex different from 0b000000.

[0071] When a random access procedure is started on the serving cell, the MAC entity performs the following. · If the random access procedure is started by a PDCCH order and the ra-PreambleIndex explicitly provided by the PDCCH is not 0b000000, or if the random access procedure is started for reconfiguration with synchronization and a contention-free random access resource of the 4-step RA type is explicitly provided by rach-ConfigDedicated for the BWP selected for the random access procedure. Set RA_TYPE to 4-stepRA.

[0072] If the selected RA_TYPE is set to 4-stepRA, the MAC entity performs the following. · If ra-PreambleIndex is explicitly provided from the PDCCH and ra-PreambleIndex is not 0b000000, set PREAMBLE_INDEX to the notified ra-PreambleIndex and select the SSB notified by the PDCCH. · If the SSB is selected as above, determine the next available PRACH occasion from the PRACH occasions permitted by the restrictions given by ra-ssb-OccasionMaskIndex and corresponding to the selected SSB (the MAC entity randomly selects a PRACH occasion with equal probability from among consecutive PRACH occasions corresponding to the selected SSB according to the specification. The MAC entity may consider the possibility of occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the selected SSB).

[0073] <The time between PDCCH order reception and PRACH transmission> If the random access procedure is initiated by a PDCCH order, the UE shall transmit the PRACH within the selected PRACH occasion when the time between the last symbol of the PDCCH order reception and the first symbol of the PRACH transmission is greater than or equal to N_(T,2)+Δ_BWPSwitching+Δ_Delay+T_switch[msec] (time condition) as described in the specification, if required by the upper layer. Here, N_(T,2) is the duration of N_2 symbols corresponding to the PUSCH preparation time of UE processing capability 1. Assume that μ corresponds to the minimum SCS setting between the subcarrier spacing (SCS) setting of the PDCCH order and the corresponding SCS setting of the PRACH transmission. If the active UL BWP does not change, Δ_BWPSwitching = 0; otherwise, Δ_BWPSwitching is defined in the specification. In FR1, Δ_delay = 0.5 msec, and in FR2, Δ_delay = 0.25 msec. T_switch is the switching gap duration defined in the specification.

[0074] <Valid / Invalid Conditions of the PRACH Occasion (Valid Conditions)> In paired spectrum (FDD) or SUL band, all PRACH occasions are valid. In unpaired spectrum (TDD), the PRACH occasion may follow the following Provisions 1 and 2. [Provision 1] If the UE has not provided tdd-UL-DL-ConfigurationCommon, a PRACH occasion in a PRACH slot is valid if it does not precede an SS / PBCH block in the PRACH slot and begins at least N_gap symbols after the last SS / PBCH block received symbol, where N_gap is defined in the specification. If channelAccessMode=semistatic is provided, it does not overlap with a set of consecutive symbols before the start of the next channel occupancy time that the UE does not transmit. Candidate SS / PBCH block indices correspond to SS / PBCH block indices provided by ssb-PositionsInBurst in SIB1 or ServingCellConfigCommon. [Regulation 2] If the UE is providing tdd-UL-DL-ConfigurationCommon, the PRACH occasions within the PRACH slot are valid in the following cases: • The PRACH occasion is within the UL symbol. Or, The PRACH occasion does not precede an SS / PBCH block in the PRACH slot, and begins at least N_gap symbols after the last DL symbol and at least N_gap symbols after the last SS / PBCH block symbol, where N_gap is defined in the specification. If channelAccessMode=semistatic is provided, the PRACH occasion does not overlap with a consecutive set of symbols before the start of the next channel occupancy time, which should not involve any transmissions as described in the specification. Candidate SS / PBCH block indices for SS / PBCH blocks correspond to SS / PBCH block indices provided by ssb-PositionsInBurst in SIB1 or ServingCellConfigCommon, as described in the specification.

[0075] (Step 4 in CBRA) Step 4 (Msg4) of the RA procedure in Rel.16 NR follows the following Step 4 operation.

[0076] [Step 4 Action] If the UE is not provided with a C-RNTI, in response to a PUSCH transmission scheduled by the RAR UL grant, the UE attempts to detect DCI format 1_0 with a CRC scrambled by the corresponding TCI-RNTI, by scheduling a PDSCH containing the UE contention resolution identity. Upon receiving the PDSCH containing the UE contention resolution identity, the UE transmits HARQ-ACK information within the PUCCH. The PUCCH transmission is within the same active UL BWP as the PUSCH transmission. The minimum time between the last symbol of the PDSCH reception and the first symbol of the corresponding PUCCH transmission containing HARQ-ACK information is equal to N_T,1 [msec], where N_T,1 is the duration of the N_T,1 symbol, corresponding to the PDSCH processing time for UE processing capability 1 if an additional PDSCH DM-RS is configured. For μ=0, the UE assumes N_T,1=14.

[0077] When a DCI format is detected in response to a PUSCH transmission scheduled by a RAR UL grant, or in response to a corresponding PUSCH retransmission scheduled by DCI format 0_0 with a CRC scrambled by TC-RNTI provided in the corresponding RAR message, the UE may assume that the PDCCH carrying that DCI format has the same DM-RS antenna port quasi co-location (QCL) properties as the DM-RS antenna port quasi co-location (QCL) properties for the SS / PBCH block used by the UE for PRACH association.

[0078] (Assuming RAR reception and QCL) In response to a PRACH transmission, the UE attempts to detect DCI format 1_0 with the corresponding RA-RNTI-scrambled CRC within a window controlled by the aforementioned higher layer. The window begins at the first symbol of the earliest CORESET in which the UE is configured to receive a PDCCH for a type 1-PDCCH CSS set, i.e., at least one symbol after the last symbol of the PRACH occasion corresponding to the PRACH transmission. The symbol duration corresponds to the SCS for a type 1-PDCCH CSS set. The length of the window is provided as a number of slots by the ra-responseWindow, based on the SCS for a type 1-PDCCH CSS set.

[0079] If the UE detects its DCI format 1_0, which includes the CRC scrambled by the corresponding RA-RNTI and the LSBs of the SFN field in the DCI format, which are the same as the least significant bits (LSBs) of the system frame number (SFN) from which the UE sent the PRACH, and the UE receives the transport block in the corresponding PDSCH, the UE may assume the same DMRS antenna port QCL properties with respect to the SS / PBCH block or CSI-RS resource that the UE uses to associate the PRACH, regardless of whether the UE is provided with a TCI-State for CORESET to receive the PDCCH with the DCI format 1_0.

[0080] If a UE attempts to detect DCI format 1_0 with scrambled CRC by the corresponding RA-RNTI in response to a PRACH transmission initiated by a PDCCH order that triggers a CFRA procedure for a SpCell, the UE may assume that the PDCCH containing the DCI format 1_0 and the PDCCH order have the same DMRS antenna port QCL properties. If a UE attempts to detect DCI format 1_0 with scrambled CRC by the corresponding RA-RNTI in response to a PRACH transmission initiated by a PDCCH order that triggers a CFRA procedure for a secondary cell, the UE may assume that the DMRS antenna port QCL properties of the CORESET associated with the type 1-PDCCH CSS set for receiving the PDCCH containing the DCI format 1_0 are the same.

[0081] A RAR UL grant may include at least one of the following: a frequency hopping flag field, a PUSCH frequency resource allocation field, a PUSCH time resource allocation field, a modulation and coding scheme (MCS) field, a TPC command field for PUSCH, a CSI request field, and a channel access-cyclic prefix extension (CPext) field.

[0082] If the preamble is repeated with different multiple beams (on different ROs associated with different SSBs or different CSI-RSs), the UE may assume different QCLs (e.g., beams) for the reception of Msg2 (e.g., RAR, base station response to BFR). For a UE with limited coverage, the purpose of PRACH repetition with different multiple beams is to improve the base station's decoding performance (assuming beam correspondence at the UE, the same DL / UL beam at the UE). This does not mean that the UE can decode DL reception with different multiple beams. That is, the following viewpoint 1 is obtained.

[0083] [View 1] For Msg2 reception following PRACH repetitions involving multiple different beams, it is preferable (at least in FR2) for the UE to monitor Msg2 with a single beam.

[0084] Based on Viewpoint 1, it is necessary for base stations and UEs to have a common understanding regarding QCL assumptions for Msg2 reception. It is unclear how to achieve a common understanding of QCL assumptions for PRACH repetitions involving multiple different beams. That is, Viewpoint 2 follows.

[0085] [View 2] If the UE assumes one QCL assumption for reception (at least in FR2), the base station and UE should have a common understanding regarding the QCL assumption for Msg2 reception. CFRA can facilitate the creation of this common understanding.

[0086] CBRA is primarily initiated by MAC / RRC. CFRA can be initiated by PDCCH orders or MAC / RRC (e.g., BFR, Listen Before Transmission (LBT) failure, System Information (SI) request, etc.). Solutions to the following problems are unclear for different cases. • Whether or not PRACH iterations involving multiple different beams are applied. Determining the available different beams and the number of repetitions available with each of the different beams. • Determining the QCL assumption for receiving Msg2.

[0087] Here, we assumed the same beam for DL ​​and UL in the UE, and a single QCL (Quality Cross Layer) for the reference beam for RAR reception. However, due to maximum permitted exposure (MPE) / maximum power reduction (MPR), different best beams are possible for DL ​​and UL. In addition to PRACH coverage expansion, it is possible to use PRACH with multiple different beams to improve the UL beam. Here, the following assumptions 1 and 2 are possible.

[0088] [DL / UL beam assumption 1] An existing PRACH is performed to identify the best DL beam. In this case, an additional PRACH iteration with multiple different beams (CFRA or CBRA) may be triggered for UL beam management.

[0089] [DL / UL beam assumption 2] Embodiments #1 and #2, described later, are used for PRACH iterations involving multiple different beams. In these iterations, a reference resource / reference beam is specified, and the QCL assumption in Msg2 is assumed to be the same as that of the reference beam. Therefore, the best DL beam is identified as being the same as the reference beam. In this case, further extensions to achieve UL beam management are conceivable.

[0090] For Msg2 in PRACH repetitions involving multiple different beams, it is being considered that a single DL QCL (Digital Link Level) can be assumed using the setting of reference resources for RO (Region of Signal) / preamble for each SSB / CSI-RS. If such a setting is not present, a single DL QCL for Msg2 is not possible. In this case, the operation of PRACH repetitions involving multiple different beams is unclear. Furthermore, the operation of the UE (Unified End-User) without beam correspondence is unclear. If such operation is unclear, there is a risk of deterioration in communication quality / communication throughput.

[0091] Therefore, the inventors conceived of an operation involving PRACH repetition with multiple different beams. This operation can improve the reception performance of PRACH at base stations and improve PRACH coverage.

[0092] The embodiments of this disclosure will be described in detail below with reference to the drawings. Each wireless communication method according to the embodiments may be applied individually or in combination.

[0093] In this disclosure, "A / B" and "at least one of A and B" may be interpreted as mutually exclusive. In this disclosure, "A / B / C" may mean "at least one of A, B, and C".

[0094] In this disclosure, terms such as activate, deactivate, indicate, select, configure, update, and determine may be interpreted interchangeably. In this disclosure, terms such as support, control, controllable, operate, and operable may be interpreted interchangeably.

[0095] In this disclosure, Radio Resource Control (RRC), RRC parameters, RRC messages, higher-layer parameters, information elements (IE), settings, etc., may be interpreted interchangeably. In this disclosure, Medium Access Control elements (MAC Control Element (CE)), update commands, activation / deactivation commands, etc., may be interpreted interchangeably.

[0096] In this disclosure, the upper-layer signaling may be, for example, Radio Resource Control (RRC) signaling, Medium Access Control (MAC) signaling, broadcast information, or a combination thereof.

[0097] In this disclosure, MAC signaling may include, for example, MAC Control Elements (MAC CEs) and MAC Protocol Data Units (PDUs). Broadcast information may include, for example, Master Information Blocks (MIBs), System Information Blocks (SIBs), Remaining Minimum System Information (RMSIs), and Other System Information (OSIs).

[0098] In this disclosure, physical layer signaling may include, for example, Downlink Control Information (DCI) and Uplink Control Information (UCI).

[0099] In this disclosure, terms such as index, identifier (ID), indicator, and resource ID may be interpreted interchangeably. In this disclosure, terms such as sequence, list, set, group, cluster, and subset may be interpreted interchangeably.

[0100] In this disclosure, the terms used include: panel, UE panel, panel group, beam, beam group, precoder, Uplink (UL) transmit entity, Transmission / Reception Point (TRP), base station, Spatial Relation Information (SRI), spatial relationship, SRS Resource Indicator (SRI), Control Resource Set (CORESET), Physical Downlink Shared Channel (PDSCH), Codeword (CW), Transport Block (TB), Reference Signal (RS), antenna port (e.g., Demodulation Reference Signal (DMRS) port), antenna port group (e.g., DMRS port group), group (e.g., spatial relationship group, Code Division Multiplexing (CDM) group, reference signal group, CORESET group, Physical Uplink Control Channel (PUCCH) groups, PUCCH resource groups, resources (e.g., reference signal resources, SRS resources), resource sets (e.g., reference signal resource sets), CORESET pools, downlink Transmission Configuration Indication state (TCI state) (DL TCI state), uplink TCI state (UL TCI state), unified TCI state, common TCI state, quasi-co-location (QCL), QCL assumptions, etc., may be interpreted interchangeably.

[0101] In this disclosure, the SSB / CSI-RS index / indicator, beam index, and TCI status may be interpreted as mutually interchangeable.

[0102] (Wireless communication method) In each embodiment, period, cycle, frame, subframe, slot, symbol, occasion, and RO may be interpreted as interchangeable.

[0103] In each embodiment, the terms "period," "configuration period," "periodicity," and "cycle" may be interchangeable.

[0104] In each embodiment, occasion, RACH occasion (RO), PRACH occasion, repeat resource, repeat setting resource, resource set for RO / repeat, time instance and frequency instance, time resource and frequency resource, and RO / preamble resource may be interpreted as one another.

[0105] In each embodiment, the remaining RO, the next available RO and subsequent ROs, and the RO that satisfies the time condition may be interpreted as mutually exclusive.

[0106] In each embodiment, RO indexing and repeating resource patterns may be interchangeable.

[0107] In each embodiment, the PDCCH order, PDCCH order DCI, DCI format 1_0, and message (Msg.) 0 may be interchangeable. In each embodiment, PRACH, preamble, PRACH preamble, sequence, preamble format, and Msg. 1 may be interchangeable. In each embodiment, the response to PRACH, RAR, Msg. 2, Msg. B, Msg. 4, base station response to BFR, and DCI scheduling the response may be interchangeable. In each embodiment, the non-PRACH transmission in the random access procedure, Msg. 3, PUSCH scheduled by RAR, HARQ-ACK / PUCCH for Msg. 4, and Msg. A PUSCH may be interchangeable. In each embodiment, Msg. 3, PUSCH scheduled by RAR UL grant, and RRC connection request may be interchangeable. In each embodiment, Msg4, contention resolution, RRC connection setup, and PDSCH with UE contention resolution identity may be interchangeable.

[0108] In each embodiment, beam, SSB, and SSB index may be interchangeable.

[0109] In each embodiment, repetition, repetition with the same beam, repetition RO with the same beam, and repetition associated with the same SSB index may be interpreted as one another.

[0110] In each embodiment, random access (RA) procedures, CFRA / CBRA, 4-step RACH / 2-step RACH, specific types of random access procedures, random access procedures using specific PRACH formats, random access procedures initiated by a PDCCH order, random access procedures not initiated by a PDCCH order, and random access procedures initiated by a higher layer may be interpreted as one another.

[0111] In each embodiment, the reference resource, reference beam, resource corresponding to the reference beam, indicated resource, indicated beam, selected resource, and selected beam may be interpreted as one another.

[0112] In each embodiment, the following RO cases 1 and 2 are possible. [RO Case 1] The distance between the two ROs for the corresponding repeat settings between the two SSBs is relatively long (or they do not overlap in time). [RO Case 2] The distance between the two ROs for the corresponding repeat settings between the two SSBs is relatively short (or they overlap in time).

[0113] Even if no example for RO case 2 is provided in the following embodiments, each embodiment can be applied to both RO cases 1 and 2.

[0114] The UE may receive settings for multiple repetitions of PRACH. The UE may control the transmission of those multiple repetitions with different beams.

[0115] The UE may transmit one or more repetitions of a physical random access channel (PRACH) using multiple different beams, each for a different beam. The UE may determine pseudo-collocation (QCL) assumptions for receiving one or more responses corresponding to each of those one or more repetitions. Based on those one or more repetitions, the UE may control at least one of the downlink (DL) beam, the uplink (UL) beam, and the random access contention resolution (RA) timer.

[0116] <Embodiment #1> If a UE sends PRACH preambles on X beams, the UE may start a RAR window (ra-ResponseWindow) in the first PDCCH occasion after the end of each repeat transmission, assuming a PDCCH / Msg2 in each window having the same DMRS QCL as the SSB / CSI-RS beam used by the UE for each PRACH transmission association. The PDCCH may use a different RA-RNTI corresponding to each PRACH transmission.

[0117] The UE may follow at least one of the following monitoring methods 1 to 3 for monitoring Msg2 (Msg2 scheduling PDCCH).

[0118] Monitoring Method 1 After the UE decodes one Msg2 with one QCL assumption from the base station, the UE may stop monitoring other Msg2s within other windows. If there is a subsequent PRACH repeat, the UE may stop that PRACH repeat.

[0119] This monitoring method 1 may be applied to CFRA. It may not be applied to CBRA (it may not be suitable for CBRA) because one of the decoded Msg2s may be unfavorable for contention resolution.

[0120] Monitoring Method 2 The UE may monitor and decode each Msg2 from each window associated with each QCL assumption.

[0121] This monitoring method 2 is preferred when multiple RAR windows do not overlap in time. Otherwise, the UE may not be able to receive using two or more different QCL type D assumptions without corresponding UE capabilities.

[0122] Monitoring Method 3 Instead of monitoring / decoding all Msg2s within all windows, the UE may select a portion of Msg2s / windows for reception, or assume a portion of QCLs for reception.

[0123] For example, for multiple windows with overlapping time intervals, the UE may decide to use a single DL QCL for reception based on the DL measurement results.

[0124] For example, for all windows, the UE may decide to send Msg2 to only two windows.

[0125] For example, the UE may decide to stop monitoring Msg2 after receiving two Msg2s.

[0126] Figure 5A shows an example of RAR windows that do not overlap in time. PRACH resources (RO / preamble) #0 to #3 are associated with SSB (beam) #0 to #3, respectively. The UE starts windows #0 to #3 for monitoring the RAR scheduling PDCCH after RO #0 to #3. Windows #0 to #3 do not overlap in time.

[0127] Figure 5B shows an example of monitoring method 1 for RAR windows that do not overlap in time. If the UE decodes Msg2(RAR) in window #1, it may stop subsequent PRACH iterations and at least one of the RAR windows. If the UE fails to receive Msg2, it may send the remaining PRACHs or monitor the remaining Msg2.

[0128] Figure 6A shows an example of monitoring method 2 for RAR windows that do not overlap in time. The UE may monitor Msg2 within each window. In this example, the UE successfully decodes Msg2 (RAR#1) in window #1 and Msg2 (RAR#3) in window #3.

[0129] Figure 6B shows an example of monitoring method 3 for RAR windows that do not overlap in time. The UE may stop subsequent PRACH iterations and RAR windows after successfully decoding two Msg2s. In this example, the UE may stop sending the remaining PRACHs or stop monitoring the remaining Msg2s after successfully decoding Msg2 (RAR#1) in window #1 and Msg2 (RAR#2) in window #2.

[0130] Figure 7A shows an example of RAR windows that overlap in time. RO#0 to #3 are associated with SSB (beam) #0 to #3, respectively. RO#0 and #1 overlap in the time domain (FDM). RO#2 and #3 overlap in the time domain (FDM). The UE starts windows #0 to #3 after RO#0 to #3, respectively. Windows #0 to #3 overlap in time.

[0131] Figure 7B shows an example of a combination of monitoring methods 1 and 3 for overlapping RAR windows in time. The UE may stop subsequent RAR windows if it decodes Msg2 (RAR#1) within window #1. The UE may assume QCL using SSB#1 upon receiving Msg2 within window #1.

[0132] Figure 8 shows an example of a combination of monitoring methods 2 and 3 for RAR windows that overlap in time. The UE decodes Msg2 (RAR#1) in window #1 and Msg2 (RAR#3) in window #3. The UE may assume QCL using SSB#1 when receiving Msg2 in window #1. The UE may assume QCL using SSB#3 when receiving Msg2 in window #3.

[0133] This embodiment may be applied to CBRA / CFRA.

[0134] According to this embodiment, the UE can use a suitable QCL for monitoring Msg2 for PRACH repetitions involving multiple different beams.

[0135] <Embodiment #2> If the UE can decode multiple Msg2 / RARs for PRACH repetitions, the UE may be required to send a PUSCH scheduled by the UL grant in the Msg2 / RAR. The UE may follow at least one of the following PUSCH transmission methods 1 to 3.

[0136] 《PUSCH transmission method 1》 The UE sends only one PUSCH scheduled by the selected RAR. The UE may follow either of the following PUSCH transmission methods 1A or 1B. [PUSCH transmission method 1A] The SSB / CSI-RS beam associated with that one pusher may be considered a good DL beam / QCL for subsequent DL reception (e.g., Msg4 reception).

[0137] [PUSCH transmission method 1B] The SSB / CSI-RS beam associated with that one push may be considered a good UL beam / QCL for subsequent UL transmissions (e.g., ACK / NACK transmissions to Msg4).

[0138] PUSCH transmission method 1 does not have to be applied to the CBRA. If the UE decides to skip the first PUSCH, the UE does not have to be guaranteed to receive subsequent RARs.

[0139] 《PUSCH transmission method 2》 For each decoded RAR, the UE may send the PUSCH scheduled by each RAR. In this case, the UE may assume that the PUSCHs scheduled by each RAR do not overlap in time. If overlapping occurs, the UE may apply PUSCH transmission method 3.

[0140] 《PUSCH transmission method 3》 A UE may decide not to send a PUSCH scheduled by a certain RAR, according to a rule or implementation. The rule may be at least one of the following sending rules 1 and 2.

[0141] [Sending Rule 1] If two pushes scheduled by two RARs overlap in time, the UE may select only one push for transmission. That selected push may be the one with the earlier start time.

[0142] [Sending Rule 2] The UE may decide whether or not to send each PUSCH based on the DL measurement results. The DL measurement results may also be the measurement results for the corresponding beam (SSB / CSI-RS). The DL measurement results may also be RSRP / RSRQ / SINR using that SSB / CSI-RS. If the DL measurement results are above a threshold, the UE may decide to send the corresponding PUSCH. If the DL measurement results are below a threshold, the UE may decide not to send the corresponding PUSCH.

[0143] In PUSCH transmission methods 2 and 3, the UE may transmit two or more PUSCHs. In PUSCH transmission method 3, the UE may avoid overlapping PUSCHs in the time domain (reducing the probability of competition).

[0144] In the examples in Figures 9A, 9B, and 10, RO#0 to #3 are associated with SSB(beams) #0 to #3, respectively. The UE starts windows #0 to #3 after RO#0 to #3. Windows #0 to #3 do not overlap in time.

[0145] Figure 9A shows an example of PUSCH transmission method 1 for non-overlapping RAR windows. The UE decodes Msg2(RAR) in windows #1, #2, and #3. In this example, the UE selects SSB #3 and transmits the PUSCH scheduled by the RAR in window #3 corresponding to SSB #3.

[0146] Figure 9B shows an example of PUSCH transmission method 2 for non-overlapping RAR windows. The UE decodes Msg2(RAR) in windows #1, #2, and #3. The UE transmits each PUSCH scheduled by each RAR.

[0147] Figure 10 shows an example of PUSCH transmission method 3 for non-overlapping RAR windows. The UE decodes Msg2(RAR) in windows #1, #2, and #3. The UE does not transmit the PUSCH scheduled by the RAR in window #2, according to the rules. The rules may also select the SSB associated with the window based on the DL measurement results. The UE transmits the PUSCH scheduled by the remaining windows #1 and #3, respectively.

[0148] In the examples in Figures 11A and 11B, RO#0 to #3 are associated with SSB(beams) #0 to #3, respectively. RO#0 and #1 overlap in the time domain (FDM). RO#2 and #3 overlap in the time domain (FDM). The UE starts windows #0 to #3 after RO#0 to #3. Windows #0 to #3 overlap in time.

[0149] Figure 11A shows an example of PUSCH transmission method 2 for overlapping RAR windows. The UE decodes Msg2(RAR) in windows #1 and #3. The UE transmits each PUSCH scheduled by each RAR.

[0150] Figure 11B shows an example of method 3 for sending a PUSCH to overlapping RAR windows. The UE decodes Msg2(RAR) in windows #1 and #3. If two PUSCHs scheduled by two RARs overlap in time, the UE may select only one PUSCH to send. That selected PUSCH may have an earlier start time. Since the start time of the PUSCH scheduled by the RAR in window #1 is earlier than the start time of the PUSCH scheduled by the RAR in window #3, the UE sends only the PUSCH scheduled by the RAR in window #1 and does not send the PUSCH scheduled by the RAR in window #3.

[0151] According to this embodiment, the UE can appropriately transmit Msg3 for PRACH repetitions involving multiple different beams.

[0152] <Embodiment #3> When the UE decodes multiple RARs corresponding to PRACH repetitions, it may assume that the value of at least one specific field within each RAR is the same. The specific field may be at least one of the following fields: ·timing advance command (TAC). Considering different timing advances (TAs) for different beams, the TACs within each RAR may differ. • UL grant (or a portion of a field within a UL grant, e.g., frequency domain resource allocation for PUSCH). Considering different time-domain resource allocations for different beams in PUSCH, the UL grants within each RAR may differ. TC-RNTI. For the same UE, it is preferable that the TC-RNTI (TEMPORARY_C-RNTI) within each RAR is the same. • Random access preamble identity (RAPID, random access preamble index in the MAC subheader for RAR). If repetitions involving multiple different beams are performed using the same preamble, a particular field may be RAPID.

[0153] For each TAC (and its TA value) within a RAR, the UE may apply that TA value to the scheduled PUSCH based on the associated preamble and the timing of the associated preamble. This behavior may also mean that the TAC within the corresponding RAR is applied only once to the 2nd / 3rd / ...PUSCH scheduled by the 2nd / 3rd / ... RAR of the 2nd / 3rd / ... preamble iteration, based on the timing of the associated preamble. This behavior does not require considering the TAC / TA within the RAR of previous iterations, and may apply a non-accumulating TA to the PUSCH corresponding to the repeated PRACH.

[0154] In the example in Figure 12, RO#0 to #3 are associated with SSB(beam)#0 to #3, respectively. The UE starts windows #0 to #3 after RO#0 to #3. Windows #0 to #3 do not overlap in time.

[0155] In this example, the UE decodes Msg2(RAR) in windows #1, #2, and #3. Each RAR contains TC-RNTI#y. The RARs in windows #1, #2, and #3 each contain TAC#1, #2, and #3, respectively. Based on the timing of the corresponding RO / preamble, the UE adjusts the TAC in the corresponding RAR and applies that TAC to the PUSCH scheduled by that RAR.

[0156] Similarly, for transmission power control (TPC) commands for pushes within a RAR UL grant, the UE may apply the TPC only once for a scheduled push, or it may apply a non-accumulating TPC to pushes corresponding to repeated pushes.

[0157] According to this embodiment, Msg3 can be appropriately transmitted for PRACH repetitions involving multiple different beams.

[0158] <Embodiment #4> The following parameters may be the same for multiple PUSCH / Msg3s sent by the UE during the CBRA iterative procedure. • An RNTI for scrambling initialization of each PUSCH corresponding to each RAR UL grant. If a TC-RNTI is provided by a higher layer, that RNTI may be that TC-RNTI. Otherwise, that RNTI may be a C-RNTI. • A C-RNTI MAC CE or common control channel (CCCH) service data unit (SDU) contained within the UL-SCH in Msg3. The CCCH SDU may be associated with a UE contention resolution identity MAC CE. The ID communicated by the UE may be the same within each PUSCH for contention resolution in Msg4.

[0159] In the example in Figure 13, RO#0 to #3 are associated with SSB(beam)#0 to #3, respectively. The UE starts windows #0 to #3 after RO#0 to #3. Windows #0 to #3 do not overlap in time.

[0160] In this example, the UE decodes Msg2(RAR) in windows #1, #2, and #3. Each PUSCH may be scrambled with the same TC-RNTI#y or C-RNTI#c. Each PUSCH may also be transmitted with the same C-RNTI MAC CE or CCCH SDU.

[0161] According to this embodiment, the UE can appropriately transmit Msg3 for PRACH repetitions involving multiple different beams.

[0162] <Analysis> In embodiments #1 to #4, steps 1 to 3 of the RA procedure (sending Msg1, receiving Msg2, sending Msg3) are performed. In step 4 (receiving Msg4), the following problems can be considered to be resolved. • DL beam instruction. • UL beam instruction (for UE in beam correspondence). • Conflict resolution against CBRA.

[0163] <Embodiment #5> Regarding how the selected DL beam is instructed from the UE to the base station, at least one of the following DL beam instruction methods 0 to 2 may be applied. In the existing specifications, the beam associated with the selected RO / preamble is the DL beam.

[0164] DL Beam Direction Method 0 Similar to embodiments #C1 / #C2, a reference resource in the RO / preamble is set / determined for each beam, and in each iteration, the DL beam may be indicated by the reference beam associated with the reference resource in the RO / preamble.

[0165] DL Beam Direction Method 1 In Msg3 PUSCH, at least one of the new MAC CEs in the CCCH SDU and the C-RNTI MAC CE may indicate the DL beam (SSB / CSI-RS) index selected by the UE. After decoding Msg3, the base station may know the DL beam index selected by the UE. The DL beam index may also be explicitly indicated in Msg3.

[0166] DL Beam Direction Method 2 A selected Msg3 PUSCH transmission and its associated RAR / RO / preamble / beam may imply the DL beam (SSB / CSI-RS) index selected by the UE.

[0167] Variations of DL beam direction method 2 More than one (e.g., P) Msg3 push transmissions are permitted, and for each Msg3, the associated beam may be considered a candidate DL beam. There may be a total of P candidate DL beams.

[0168] If a UE schedules a PDSCH containing a UE conflict resolution identifier (a PDSCH transmitted in response to a PUSCH scheduled by a RAR UL grant and accompanied by a UE conflict resolution identifier) ​​and attempts to detect DCI format 1_0 with a CRC scrambled by the corresponding TC-RNTI, the UE may assume that the PDCCH carrying that DCI format has the same DM-RS antenna port QCL properties as the DM-RS antenna port QCL properties of the DL beam (SSB / CSI-RS) identified in any of the DL beam indicating methods 0 to 2 described above.

[0169] This operation may also mean that the DL beam selected in any of the DL beam designation methods 0 to 2 described above is assumed by the QCL and UE for Msg4 reception.

[0170] In a variation of DL beam indication method 2 (where there are P candidate DL beams), the associated candidate DL beam corresponding to each Msg4 reception may be assumed to be the QCL for that Msg4 reception. The UE may follow either of the following Msg reception methods 1 and 2. [Msg4 Reception Method 1] The UE may assume that it receives only one Msg4. This Msg4 may imply a DL beam selected from P candidate DL beams. [Msg4 Reception Method 2] The UE may receive multiple Msg4s with different QCLs for each iteration. For the indication of a selected DL beam, the (same) beam / TCI state indication may be transmitted within each Msg4 (new RRC IE / MAC CE). The selected DL beam may then be assumed by the DL QCL and UE for subsequent DL reception.

[0171] Figure 14A shows an example of DL beam indication method 0. Resources #0b, #1c, #2b, and #3d in the RO / preamble are associated with SSB(beams) #0, #1, #2, and #3, respectively. The UE starts windows #0 through #3 after resources #0b, #1c, #2b, and #3d. Windows #0 through #3 do not overlap in time. In this example, the UE receives RARs #1 through #3, respectively, within windows #1 through #3. The UE transmits PUSCHs #1 through #3, which are scheduled by RARs #1 through #3, respectively. In this example, resource #2b is the reference resource, and its corresponding SSB #2 is the reference beam. The UE assumes a QCL for SSB #2 for the PDCCH received in Msg4.

[0172] Figure 14B shows an example of DL beam indication method 1. Resources #0, #1, #2, and #3 in the RO / preamble are associated with SSB(beams) #0, #1, #2, and #3, respectively. The UE starts windows #0 through #3 after resources #0, #1, #2, and #3. Windows #0 through #3 do not overlap in time. In this example, the UE receives RARs #1 through #3, respectively, within windows #1 through #3. The UE transmits PUSCHs #1 through #3, as scheduled by RARs #1 through #3, respectively. In this example, SSB #2 is communicated by a new MAC CE in each Msg3 of PUSCHs #1 through #3 to indicate the DL beam. The UE assumes a QCL for SSB #2 for the PDCCH received in Msg4.

[0173] Figure 15 shows an example of DL beam designation method 2 and RO case 2. Resources #0, #1, #2, and #3 in the RO / preamble are associated with SSB(beams) #0, #1, #2, and #3, respectively. Resources #0 and #1 overlap in the time domain (FDM). Resources #2 and #3 overlap in the time domain (FDM). The UE starts windows #0 to #3 after resources #0 to #3. Windows #0 to #3 overlap in time. In this example, the UE receives RAR #1 and #3, respectively, within windows #1 and #3. The UE transmits PUSCH #1 and #3, scheduled by RAR #1 and #3, respectively. In this example, SSB #2 is communicated by new MAC CEs in Msg3 of PUSCH #1 and #3 to designate the DL beam. The UE assumes a QCL of SSB#2 for the PDCCH received in Msg4.

[0174] According to this embodiment, the UE can properly receive Msg4 for PRACH repetitions involving multiple different beams.

[0175] <Embodiment #6> Regarding how the selected UL beam is instructed from the base station to the UE, at least one of the following UL beam instruction methods 1 to 2 may be applied. In the existing specifications, beam correspondence is assumed, and the selected DL beam is assumed to be the selected UL beam.

[0176] 《UL Beam Instruction Method 1》 (Suggestive Instruction) If the UE has sent multiple PUSCH / Msg3s within a PRACH iteration procedure, and the UE has received Msg4 (by detecting the DCI format corresponding to a PUSCH), the PUSCH (and its UL beam) associated with the decoded Msg4 and RAR / RO / preamble / SSB / CSI-RS may be assumed by the UE to be the selected UL beam (and its corresponding beam). The UE may use that selected UL beam as the default UL beam / QCL for subsequent UL transmissions (e.g., ACK / NACK for Msg4 PDSCH).

[0177] This operation may mean that, in response to multiple Msg3s from the UE, the base station evaluates the UL performance and selects one Msg4 for conflict resolution.

[0178] When the base station sends Msg4, a DCI scheduling Msg4 may be sent using the QCL of one DL beam selected in the above embodiment #5 (excluding the variation of DL beam instruction method 2).

[0179] UL Beam Instruction Method 2 (Explicit Instruction) The base station may transmit a beam / TCI state / spatial relationship instruction within a new MAC CE for specifying the UL beam in Msg4. That UL beam may be assumed as the default UL beam / QCL for subsequent UL transmissions (e.g., ACK / NACK for Msg4 PDSCH). An example of UL beam instruction is the base station specifying the index of a PRACH repetition (e.g., the first PRACH beam). The UE may follow either of the following UL beam instruction methods 2a and 2b.

[0180] [UL beam direction method 2a] The UE may monitor each PDCCH of each Msg4. After the UE successfully decodes one Msg4 and resolves the conflict, the UE may stop sending and receiving subsequent Msg1 / 2 / 3 / 4 messages within the iterative procedure, if there are any. This behavior may mean that the base station may send multiple Msg4s even if the UE has decoded only one Msg4.

[0181] [UL Beam Direction Method 2b] The UE may monitor only the PDCCH of Msg4 for the last iteration, or it may monitor only the PDCCH of a specific Msg4. In this case, the base station may have time to evaluate / compare all UL beams and indicate the index of the best UL beam within Msg4.

[0182] Figure 16 shows an example of UL beam designation method 1. Resources #0, #1, #2, and #3 in the RO / preamble are associated with SSB(beams) #0, #1, #2, and #3, respectively. The UE starts windows #0 through #3 after resources #0, #1, #2, and #3. Windows #0 through #3 do not overlap in time. In this example, the UE receives RARs #1 through #3, respectively, within windows #1 through #3. The UE transmits PUSCHs #1 through #3, as scheduled by RARs #1 through #3, respectively. In this example, SSB #2 is communicated by new MAC CEs in each Msg3 of PUSCHs #1 through #3 to designate the DL beam. Msg4 corresponding to PUSCHs #1 and #2 is not transmitted. The UE decodes Msg4 corresponding to PUSCH #3. If the UE decodes Msg4 with conflict resolution for PUSCH#3, it means that the selected UL beam / QCL is SSB#3. SSB#3 is associated with Msg4 / 3 / 2 / 1. The UE may use SSB#3 as the default UL QCL for subsequent UL transmissions.

[0183] Figure 17A shows an example of UL beam designation method 2a. Resources #0, #1, #2, and #3 in the RO / preamble are associated with SSB(beams) #0, #1, #2, and #3, respectively. The UE starts windows #0 through #3 after resources #0, #1, #2, and #3. Windows #0 through #3 do not overlap in time. In this example, the UE receives RARs #1 through #3, respectively, within windows #1 through #3. The UE transmits PUSCHs #1 through #3, as scheduled by RARs #1 through #3, respectively. In this example, SSB #2 is communicated by new MAC CEs within each Msg3 of PUSCHs #1 through #3 to designate the DL beam. The UE monitors each PDCCH in each Msg4, assuming the DL QCL for SSB #2. In this example, SSB #3 is communicated within each Msg4 to designate the UL beam. The UE fails to decode Msg4#1 corresponding to PUSCH#1, but succeeds in decode Msg4#2 corresponding to PUSCH#2 (with conflict resolution). The UE may then stop sending / receiving subsequent Msg1 / 2 / 3 / 4.

[0184] Figure 17B shows an example of UL beam designation method 2b. Resources #0, #1, #2, and #3 in the RO / preamble are associated with SSB(beams) #0, #1, #2, and #3, respectively. The UE starts windows #0 through #3 after resources #0, #1, #2, and #3. Windows #0 through #3 do not overlap in time. In this example, the UE receives RARs #1 through #3, respectively, within windows #1 through #3. The UE transmits PUSCHs #1 through #3, scheduled by RARs #1 through #3, respectively. In this example, SSB #2 is communicated by new MAC CEs in each Msg3 of PUSCHs #1 through #3 to designate the DL beam. The UE monitors the PDCCH in Msg4#3 corresponding to the last repetition, assuming the DL QCL for SSB #2. In this example, SSB#3 is transmitted within Msg4#3 to indicate the UL beam.

[0185] Figure 18 shows an example of a combination of variations of DL beam designation method 2 and UL beam designation method 2a. Resources #0, #1, #2, and #3 in the RO / preamble are associated with SSB (beams) #0, #1, #2, and #3, respectively. The UE starts windows #0 through #3 after resources #0, #1, #2, and #3. Windows #0 through #3 do not overlap in time. In this example, the UE receives RARs #1 through #3, respectively, within windows #1 through #3. The UE transmits PUSCHs #2 through #3, scheduled by RARs #2 through #3, respectively. In this example, the transmission of PUSCH #2 implicitly indicates DL beam candidate #2, and the transmission of PUSCH #3 implicitly indicates DL beam candidate #3. The UE monitors each PDCCH of each Msg4, assuming the corresponding QCL (different QCL). In this example, within Msg4#2 corresponding to PUSCH#2, SSB#2 for UL beam indication and SSB#2 for DL ​​beam indication are transmitted. In this example, within Msg4#3 corresponding to PUSCH#3, SSB#2 for UL beam indication and SSB#2 for DL ​​beam indication are transmitted.

[0186] This embodiment relates to the UL beam after Msg4 (e.g., Msg4 HARQ-ACK), but some of these embodiments may be applied to the UL beam indication of Msg3.

[0187] According to this embodiment, the UE can appropriately determine the UL beam after Msg4 for PRACH repetitions with multiple different beams.

[0188] <Embodiment #7> For an RA conflict resolution timer (e.g., ra-ContentionResolutionTimer) for resolving conflicts with CBRA, the UE may follow one of the following RA conflict resolution timer operations 1 to 2.

[0189] 《RA Conflict Resolution Timer Operation 1》 (for UL beam instruction method 1 / 2a) After each Msg3 transmission, the UE may start / restart the RA conflict resolution timer, and may restart the RA conflict resolution timer for each HARQ retransmission in the first symbol after the end of that Msg3 transmission.

[0190] 《RA Conflict Resolution Timer Operation 2》 (for UL beam instruction method 2b) After the last repeated transmission of Msg3, the UE may start the RA conflict resolution timer and restart it for each HARQ retransmission in the first symbol after the end of that Msg3 transmission.

[0191] While the RA conflict resolution timer is running, the UE may monitor the PDCCH of Msg4.

[0192] If the C-RNTI MAC CE is included in Msg3, the UE may, as with existing procedures, consider the conflict resolution successful and stop the RA conflict resolution timer, and furthermore, stop sending and receiving subsequent messages Msg / 1 / 2 / 3 / 4 if any.

[0193] If a CCCH SDU is included in Msg3, and PDCCH is addressed to TC-RNTI, and the UE conflict resolution identifier decoded in Msg4 PDSCH matches the CCCH SDU sent in Msg3, the UE may, as with existing procedures, consider the conflict resolution successful and stop the RA conflict resolution timer, and further, stop sending and receiving subsequent messages Msg / 1 / 2 / 3 / 4, if any.

[0194] Figure 19A shows an example of RA conflict resolution timer operation 1. Resources #0, #1, #2, and #3 in the RO / preamble are associated with SSB (beams) #0, #1, #2, and #3, respectively. The UE starts windows #0 through #3 after resources #0, #1, #2, and #3. Windows #0 through #3 do not overlap in time. In this example, the UE receives RAR #1 through #3, respectively, within windows #1 through #3. The UE transmits PUSCH #1 through #3, which are scheduled by RAR #1 through #3, respectively. In this example, SSB #2 is communicated within each Msg3 of PUSCH #1 through #3 to indicate the DL beam. After transmitting each Msg3, the UE starts / restarts the RA conflict resolution timer. While the RA conflict resolution timer is operating, the UE monitors the PDCCH of each Msg4, assuming the DL QCL of SSB #2.

[0195] Figure 19B shows an example of RA conflict resolution timer operation 2. Resources #0, #1, #2, and #3 in the RO / preamble are associated with SSB (beams) #0, #1, #2, and #3, respectively. The UE starts windows #0 through #3 after resources #0, #1, #2, and #3. Windows #0 through #3 do not overlap in time. In this example, the UE receives RAR #1 through #3, respectively, within windows #1 through #3. The UE transmits PUSCH #1 through #3, as scheduled by RAR #1 through #3, respectively. In this example, SSB #2 is transmitted within each Msg3 of PUSCH #1 through #3 to indicate the DL beam. After transmitting the last Msg3 (PUSCH #3), the UE starts the RA conflict resolution timer. The UE monitors the PDCCH of the last Msg4, assuming DL QCL for SSB#2 while the RA conflict resolution timer is running. SSB#3 is communicated within that Msg4 for UL beam indication.

[0196] RO case 2 may be applied to RA conflict resolution timer operation 1 or 2.

[0197] According to this embodiment, the UE can appropriately use the RA conflict resolution timer for PRACH iterations involving multiple different beams.

[0198] <Embodiment #A0> PRACH iteration may be applied to extend coverage.

[0199] If PRACH is repeated multiple times, the coverage (link budget) of PRACH increases. Only PRACH format B4 (the longest (most symbolic) format for short sequences) may be applied to PRACH repetitions, several other PRACH formats may be applied, or all PRACH formats may be applied. For short sequences, the PRACH format may be adjusted (scaled) based on the PRACH SCS.

[0200] Only 4-step RACH may be applied to PRACH iterations. 4-step RACH is most likely to be used in scenarios where coverage is limited. 2-step RACH may also be applied to PRACH iterations.

[0201] According to this embodiment, PRACH coverage can be improved.

[0202] <Embodiment #A1> This embodiment relates to the PRACH iteration.

[0203] For CFRA / CBRA, PRACH repetitions with the same beam may be applied to at least one of the following RAs from 1a-1 to 1a-6. [Target 1a-1] CFRA only. [Target 1a-2] CBRA only. [Target 1a-3] Both CFRA and CBRA. [Target 1a-4] RAs among CFRAs and CBRAs reported by UE capability. For at least one of the CFRAs and CBRAs, UE capability for PRACH repeats with the same beam may be defined, and that UE capability may report that the UE supports PRACH repeats with the same beam for at least one of the RAs of the CFRAs and CBRAs. [Target 1a-5] Among the CFRA and CBRA, the RA is set by RRC signaling. For RRC CONNECTED UE, RRC signaling may enable / disable PRACH repetition for at least one of the CFRA and CBRA. [Target 1a-6] RA for a specific RA purpose. With respect to PRACH repetition, at least one of availability and UE capability is defined for a specific RA purpose, and the specific RA purpose may be indicated by at least one of availability and UE capability. Availability may be an information element (higher-layer parameter) that enables PRACH repetition for the RA for the specific RA purpose. UE capability may indicate that it supports PRACH repetition for the RA for the specific RA purpose. A specific RA purpose may be, for example, a PDCCH order RA, an SI request RA, a BFR RA, an RA triggered by the MAC layer, an RRC layer triggered RA, etc.

[0204] For 2-step RA / 4-step RA, a PRACH repetition with the same beam may be applied to at least one of the following RAs from 1b-1 to 1b-5. [Target 1b-1] 2-step RA only. [Target 1b-2] 4-step RA only. [Target 1b-3] Both 2-step and 4-step RA. [Target 1b-4] Among the 2-step RAs and 4-step RAs, the RA reported by the UE capability. For at least one of the 2-step RAs and 4-step RAs, a UE capability for PRACH repeats with the same beam may be defined, and that UE capability may report that the UE supports PRACH repeats with the same beam for at least one of the RAs of the 2-step RAs and 4-step RAs. [Target 1b-5] Among the 2-step RAs and 4-step RAs, the RAs are set by RRC signaling. For RRC_CONNECTED UE, RRC signaling may enable / disable PRACH repetition for at least one of the 2-step RAs and 4-step RAs.

[0205] Considering different PRACH formats, PRACH repetitions may apply to some or all PRACH formats. UE capabilities for PRACH repetitions may be defined for one, some, or all PRACH formats.

[0206] PRACH repetitions involving the same beam may be applied to some or all of the RRC IDLE UE, RRC INACTIVE UE, and RRC CONNECTED UE. A new PRACH setting may be provided within the SIB for the application of PRACH repetitions involving the same beam to the IDLE / INACTIVE UE. A new PRACH setting / instruction for the application of PRACH repetitions involving the same beam to the CONNECTED UE may be provided by RRC signaling / MAC CE / DCI.

[0207] At least one of the conditions / targets under which PRACH repetitions with the same beam are available in this embodiment may also be a condition / target under which PRACH repetitions with multiple different beams are available.

[0208] This embodiment clarifies the conditions / targets under which PRACH repetitions involving the same beam or multiple different beams are applicable.

[0209] <Embodiment #A2> This embodiment relates to the setting of the repetition pattern / resource / number of repetitions in PRACH.

[0210] The PRACH repeating pattern / resource may be repeated for at least one of the following unit resources 1 to 6. At least one of the unit resources 1 to 6 may be set by the SIC / RRC IE or specified in the specification. [Unit Resource 1] Association period. The association period may be X SSB mapping periods / cycles, or it may be a period that includes ROs mapped to all SSBs and unused ROs that can be mapped to beams for repetition. [Unit Resource 2] PRACH setting period / cycle. [Unit Resource 3] X time units. For example, a time unit may be a PRACH occasion (RO) in a slot / subframe / time domain. [Unit Resource 4] X frequency units. For example, a frequency unit may be a PRACH occasion in the frequency domain. [Unit Resource 5] X PRACH Occasions (ROs). [Unit Resource 6] X SSBs (PRACH Occasions (ROs) mapped to X SSBs).

[0211] As we move from unit resource 1 to unit resource 6, the two PRACH repeats corresponding to the same SSB become closer to each other.

[0212] For a given unit resource 1, subsequent repeating resources may occur after all SSBs have been mapped to a PRACH occasion at least once. In the example in Figure 20A, the length of the PRACH setting period is 10 ms. In this example, the repeating resources (association periods) consist of two PRACH setting periods. Within each repeating resource, the first PRACH setting period has ROs for SSBs 0 through 40, and the second PRACH setting period has ROs for SSBs 41 through 63 and unused ROs. PRACH is repeated for the same ROs for the same SSBs within each repeating resource. In this example, unused ROs are not used in the repetition.

[0213] For unit resources 2 through 6, the second repeating resource may occur before all SSBs have been mapped to a PRACH occasion at least once. In the example in Figure 20B for unit resource 2, the repeating resource is one PRACH setting period. In this example, the number of repeats is 2. Within each of the first and second repeating resources (PRACH setting periods), there are ROs for SSBs 0 through 40. Within the next first and second repeating resources (PRACH setting periods), there are ROs for SSBs 41 through 63 and unused ROs. PRACH is repeated for the ROs for the same SSBs within each repeating resource.

[0214] In the example in Figure 21A relating to unit resource 3, the repeating resource is 2ms. In this example, the number of repetitions is 2. In the first and second repeating resources, there are ROs for SSBs 0 through 9. In the next first and second repeating resources, there are ROs for SSBs 10 through 19. PRACH is repeated in the ROs for the same SSBs within each repeating resource.

[0215] In the example of Figure 21B for unit resource 3, according to the aforementioned mapping 1, the repeating resources are two time-domain ROs. In the first repeating resource, SSB0, 0, 1, 1 are mapped to four ROs within the first time-domain RO, and SSB2, 2, 3, 3 are mapped to four ROs within the second time-domain RO. In the second repeating resource, the same SSBs as in the first repeating resource are mapped. PRACH is repeated for the ROs corresponding to the same SSB within each repeating resource.

[0216] In the example of Figure 22A for unit resource 4, according to the aforementioned mapping 2, the repeating resources are two frequency-domain ROs. SSB0 to 3 and SSB4 to 7 are respectively mapped to two frequency-domain ROs within the first time-domain RO in the first repeating resource. In the second repeating resource, the same SSBs as in the first repeating resource are mapped. PRACH is repeated for the ROs corresponding to the same SSB within each repeating resource.

[0217] In the example of Figure 22B for unit resource 5, according to the aforementioned mapping 2, the repeating resources are four ROs. SSB0 to 3, SSB4 to 7, SSB8 to 11, and SSB12 to 15 are respectively mapped to four ROs within the first repeating resource (the first time-domain RO). In the second repeating resource (the second time-domain RO), the same SSBs as in the first repeating resource are mapped. PRACH is repeated for the ROs corresponding to the same SSB within each repeating resource.

[0218] In the example of FIG. 23A regarding unit resource 5, according to the aforementioned mapping 2, the repeating resource is one RO. SSB0 to 3 are mapped to one RO within the first repeating resource (the first frequency domain RO). In the second repeating resource (the second frequency domain RO) as well, the same SSB as in the first repeating resource is mapped. PRACH is repeated for the ROs corresponding to the same SSB within each repeating resource.

[0219] In the example of FIG. 23B regarding unit resource 5, according to the aforementioned mapping 1, the repeating resource is one SSB (the ROs mapped to one SSB). One SSB is mapped to two frequency domain ROs. SSB0 is mapped to the first and second ROs (the first and second frequency domain ROs) within the first repeating resource. In the second repeating resource (the third and fourth ROs, the third and fourth frequency domain ROs) as well, the same SSB as in the first repeating resource is mapped. PRACH is repeated for the ROs corresponding to the same SSB within each repeating resource.

[0220] The number of repetitions may be set / instructed explicitly or implicitly by SIB / RRC IE, or may be defined in the specification.

[0221] In an explicit instruction, the number of repetitions Y may be set to 1, 2, 3, 4, etc. Y = 1 may indicate no repetition. Along with the number of repetitions, the repetition period / cycle may be set for the UE or calculated / determined by the UE. For example, in the aforementioned unit resource 1, when the number of repetitions is 2, the UE may determine / calculate the repetition period as 20 * 2 = 40 ms. That is, Y repetitions may occur within 40 ms.

[0222] The explicit instruction may only indicate whether repetition is invalid (none) or repetition is valid. In this case, a default number of repetitions may be specified in the specification. When the explicit instruction indicates that repetition is valid, the number of repetitions may be the default number of repetitions.

[0223] The cell-specific PRACH repetition number may be broadcast by the SIB. The UE-specific PRACH repetition number may be set by the RRC. The UE-specific PRACH repetition number may be applied to the PRACH of the RRC INACTIVE / CONNECTED UE. The UE may determine the actual PRACH repetition number according to a determination rule or UE implementation. For example, when the measured values of the SSB's RSRP / RSRQ / SINR / quality / power are lower than the threshold and the UE is set with PRACH repetition, the UE may transmit the PRACH multiple times (transmit the PRACH repetition). The threshold may be specified in the specification or set by the RRC IE. A plurality of thresholds / ranges associated with the PRACH repetition number may be set. For example, the UE may determine the PRACH repetition number corresponding to the maximum threshold below which its measured value falls among the plurality of thresholds, or may determine the PRACH repetition number corresponding to the range including its measured value among the plurality of ranges. For example, when the measured value is RSRP and the measured value < M_1 [dBm], the number of repetitions may be 4, when M_1 < measured value <= M_2 [dBm], the number of repetitions may be 2, and when M_2 < measured value [dBm], the number of repetitions may be 1.

[0224] The operation for the UE to determine the number of repetitions may be applicable only to UEs that support PRACH repetition.

[0225] In implicit instructions, the UE may determine / calculate the number of repetitions based on a decision rule or limitation. For example, the UE may calculate the number of repetitions based on an instructed / specified repetition period. For example, if the repetition period is specified / set to 160ms in the aforementioned unit resource 1, the UE may determine / calculate the repetition period as 160ms / 20 = 8ms.

[0226] The repetition period may mean that the mapping from all specified SSB indices to ROs was repeated Y times within that period.

[0227] In the example in Figure 24 relating to unit resource 5, according to mapping 2 described above, the number of repetitions is 3, and the repetition resource is one RO. SSBs 0 through 3 are mapped to one RO within the first repetition resource (first frequency domain RO). The same SSBs as in the first repetition resource are mapped to each of the second and third repetition resources (second and third frequency domain ROs). PRACH is repeated in the RO for the same SSB within each repetition resource.

[0228] The first PRACH transmission may always be a single PRACH transmission. If Msg.2(RAR) is not received, the UE may send a PRACH with repetitions. A PRACH with repetitions may be accompanied by power ramping.

[0229] Variation A Different PRACH resources (including preambles / ROs) may be configured with different number of repetitions. In this case, the UE can choose ROs / preambles with repetition settings for cases where coverage is limited. A UE with good coverage can choose ROs / preambles without repetition settings. For example, the UE may have 1 repetition for SSBs 0 through 15, 2 repetitions for SSBs 16 through 31, 3 repetitions for SSBs 32 through 47, and 4 repetitions for SSBs 48 through 63. For example, the number of repetitions for preambles 0 through 31 may be 1, and the number of repetitions for preambles 32 through 63 may be 4.

[0230] In the example in Figure 25A for unit resource 2, the repeating resource is one PRACH setting period (10ms). There are 2 repeats of RO for SSB0 to 40 and 1 repeat for SSB41 to 63. Within each of the first and second repeating resources (PRACH setting periods), there is RO for SSB0 to 40. PRACH is repeated for the same RO for the same SSB within each repeating resource. Within the next PRACH setting period, there is RO for SSB41 to 63 and unused RO. PRACH is not repeated within this PRACH setting period.

[0231] In the example in Figure 25B for unit resource 2, the repeating resource is one PRACH setting period (10ms). In this example, the number of repetitions for preambles 0 through 15 is 2, and the number of repetitions for preambles 16 through 31 is 1.

[0232] If any of preambles 0 through 15 are used, the number of repetitions is 2. Within each of the first and second repetition resources (PRACH setting periods), there are ROs for SSBs 0 through 40. Within the next first and second repetition resources (PRACH setting periods), there are ROs for SSBs 41 through 63 and unused ROs. PRACH is repeated for the ROs for the same SSB within each repetition resource. If the base station decodes / receives preamble 1 associated with SSB#x within the first repetition resource, it is assumed that the base station will decode / receive the same preamble associated with the same SSB within the second repetition resource. The base station may perform joint decoding / reception to improve the performance of PRACH decoding / reception.

[0233] If any of preambles 16 through 31 are used, there is no repetition. If the base station decodes / receives preamble 17 associated with SSB#y in the first repetition resource, the base station assumes there is no repetition associated with the same SSB in the second repetition resource. However, the base station may decode / receive a preamble associated with SSB#y in the second repetition resource. In this case, the base station may recognize that preamble as a preamble from another UE for access. The base station does not have to perform joint decoding / reception of the two preambles.

[0234] In the example of Figure 26A for unit resource 5, according to mapping 2 described above, the repeating resources are four ROs. There are 2 repeats for ROs corresponding to SSB0 to 31 and 1 repeat for ROs corresponding to SSB32 to 63. SSB0 to 3, SSB4 to 7, SSB8 to 11, and SSB12 to 15 are mapped to the four ROs in the first repeating resource (first time domain RO), respectively. The same SSBs are mapped to the second repeating resource (second time domain RO). PRACH is repeated for ROs corresponding to the same SSBs in each repeating resource. SSB32 to 35, SSB36 to 39, SSB40 to 43, and SSB44 to 47 are mapped to the four ROs in the fifth time domain RO, respectively. There are no PRACH repeats for these ROs.

[0235] In the example of Figure 26B relating to unit resource 5, according to the mapping 2 described above, there are four repeating resources: 1 repeat for preamble indices 0 through 7 for SSB0, and 2 repeats for preamble indices 8 through 15 for SSB0. 1 repeat for preamble indices 16 through 23 for SSB1, and 2 repeats for preamble indices 24 through 31 for SSB1. 1 repeat for preamble indices 32 through 39 for SSB2, and 2 repeats for preamble indices 40 through 47 for SSB2. 1 repeat for preamble indices 48 through 55 for SSB3, and 2 repeats for preamble indices 56 through 63 for SSB3.

[0236] In the first time-domain RO, SSB0 to 3, SSB4 to 7, SSB8 to 11, and SSB12 to 15 are mapped to the four ROs respectively. For SSB0, any one of the preamble indices from 8 to 15 is used. For SSB1, any one of the preamble indices from 24 to 31 is used. For SSB2, any one of the preamble indices from 40 to 47 is used. For SSB3, any one of the preamble indices from 56 to 63 is used. In this case, the repetition number for the first time-domain RO is 2. In the second repetition resource (the second time-domain RO), the same SSBs as those in the first repetition resource are mapped. In the ROs for the same SSB within each repetition resource, PRACH is repeated.

[0237] 《Variation A1》 When the number of SSBs per RO (ssb-perRACH-Occasion) < 1, there may be no setting for (additional) repetition resources. If repetition is enabled, several ROs mapped to one SSB may be regarded as repetition resources. The repetition number may be set.

[0238] In the example of FIG. 27A, according to the aforementioned mapping 1, when OccasionAndCB-PreamblesPerSSB indicates oneHalf,n16 (N = 1 / 2, R = 16) and msg1-FDM is 4, 4 ROs are FDM in one time instance and 1 SSB is mapped to 2 ROs (the aforementioned mapping 1).

[0239] In this example, if repetition is set, the UE may regard the second RO mapped to each SSB as the RO for the second repetition of that SSB. In this example, several SSB / ROs may be set with a certain repetition number, and several SSB / ROs may not be set with repetition. In this example, different preambles may be associated with different repetition numbers including repetition number = 1 (no repetition).

[0240] In the example in Figure 27B, if ssb-perRACH-OccasionAndCB-PreamblesPerSSB is oneFourth,n16 (N=1 / 4, R=16) and msg1-FDM is 4, then four ROs are FDM'd in one time instance, and the four ROs are mapped to one SSB (mapping 2 as described above).

[0241] In this example, if repetition is set and the number of repetitions is 2, the UE may consider two of the four ROs mapped to each SSB as the RO of the second repetition for that SSB. In this example, if repetition is set and the number of repetitions is 4, the UE may consider the second, third, and fourth ROs of the four ROs mapped to each SSB as the RO of the second, third, and fourth repetitions for that SSB, respectively. In this example, different SSBs / ROs may be associated with different repetition counts, including repetition count = 1 (no repetition). In this example, different preambles may be associated with different repetition counts, including repetition count = 1 (no repetition).

[0242] According to this embodiment, the repetition pattern / resources / number of repetitions of PRACH can be appropriately determined.

[0243] <Embodiment #A3> In Rel.15 / 16, PRACH occasions and SSB indices are typically mapped in the specification. The specification does not define the PRACH beam. However, since beam correspondence is mandatory in Rel.15, the most likely UE implementation is to use the SSB beam associated with the PRACH occasion. In this case, the base station can use SSB to receive PRACH associated with the PRACH occasion. That beam may also be a CSI-RS beam.

[0244] This embodiment relates to UE behavior concerning repeated PRACH transmissions.

[0245] For any of the aforementioned unit resource settings 1 through 6, the UE may recognize the association between multiple PRACH resources repeated for the same beam. The UE may also recognize which RO is the x-th repeated transmission.

[0246] 《Transmission Operation 1》 For a selected beam (timing of beam determination), if the next available RO associated with that beam is not the first repeating transmit RO within the repeating period, the UE may follow one of the following transmit start RO1 or RO2.

[0247] [Transmission started RO1] The UE may transmit the same PRACH preamble on the ROs associated with the same PRACH preamble for all ROs up to the last RO in the repetition period (from the x-th repetition to the last repetition). The actual number of repetitions may be less than the maximum number of repetitions (configured / reported) in a single repetition period. This behavior may mean that if a base station receives a PRACH preamble on the x-th RO associated with SSB, the base station will assume that it will receive the same preamble on the (x+1)th RO, the (x+2)th RO, and so on. This behavior does not necessarily mean that the base station must receive the same preamble on the (x+1)th RO, the (x+2)th RO, and so on.

[0248] In the example in Figure 28, the number of repetitions is 4. There are 4 repeating ROs within one repetition period. After the second repeating RO, if the UE selects an SSB0 for PRACH, the UE may send that PRACH preamble from the third repeating RO to the last (fourth) repeating RO, which is associated with the same PRACH preamble / SSB0.

[0249] [Transmission started RO2] The UE may wait until the next iteration period and, starting from the first iteration RO, begin sending the PRACH preamble at the associated RO.

[0250] 《Transmission Operation 2》 For the selected beam, the UE may determine the PRACH resource (RO / preamble) based on the RSRP value. In this case, the UE may assume that different PRACH resources are configured with different repetition counts.

[0251] For example, if the threshold is 1 <= measured RSRP and the channel condition is good, the UE may select a PRACH resource with repetition count = 1. Here, if for the selected SSB#0, preambles 0 through 15 correspond to repetition count = 1, preambles 16 through 31 correspond to repetition count = 2, and preambles 32 through 47 correspond to repetition count = 4, the UE may select one preamble from preambles 0 through 15. In this case, as in the example in Figure 29 (Good RSRP), the UE may select preamble 5.

[0252] For example, if threshold 3 <= measured RSRP < threshold 2 and the channel state is intermediate, the UE may select a PRACH resource with repetition count = 2. Here, the UE may select one preamble from preambles 16 to 31. Threshold 2 = threshold 1 may also be the case. In this case, as in the example in Figure 29 (Medium RSRP), the UE may select preamble 20.

[0253] For example, if threshold 5 <= measured RSRP < threshold 4 and the channel condition is poor, the UE may select a PRACH resource with repetition count = 4. Here, the UE may select one preamble from preambles 32 to 47. Threshold 4 = threshold 3 may also be the case.

[0254] In this transmission operation, the UE may consider (or treat as) the configured number of repetitions for each PRACH resource.

[0255] In this transmission operation, the UE may consider (or treat as) the remaining actual number of repetitions for each PRACH resource.

[0256] 《Transmission Operation 3》 When a UE selects a beam for PRACH transmission (from multiple beams), the UE may select that beam according to at least one of the following selection methods 1 to 3 (taking into consideration at least one parameter of selection method 1 to 3).

[0257] [Selection Method 1] The UE takes into account the RSRP value of each beam, as with existing specifications.

[0258] [Selection Method 2] The UE considers the RSRP value of each beam, as well as the number of repetitions set for the PRACH resource associated with each beam. For example, for beams with the same number of repetitions for the PRACH resource, the UE may need to compare the RSRP values ​​of each beam. For example, for beams with similar RSRP values ​​but different numbers of repetitions for the PRACH resource, the UE may select the beam with the appropriate number of repetitions based on the RSRP range (similar to transmission operation 2 described above). For example, for beams with similar RSRP values ​​but different numbers of repetitions for the PRACH resource, the UE may select the beam with the highest number of repetitions. For example, for beams with different numbers of repetitions for the PRACH resource and different RSRP measurement results, the UE may select the beam by prioritizing either the RSRP measurement result or the number of repetitions.

[0259] (To ensure all beams have the same coverage performance,) all SSBs may be configured with the same maximum number of repetitions. However, for a given PRACH resource (RO / preamble) associated with an SSB, some PRACH resources may be configured with a large number of repetitions, while others may be configured with a smaller number of repetitions or no repetitions at all. A UE accessing any SSB may select PRACH resources corresponding to different numbers of repetitions.

[0260] In the example in Figure 30, the number of repetitions is 4, and there are 4 repeating ROs within one repetition period. SSB0, 1, 30, and 31 are mapped within each repeating RO. The UE may select an SSB for PRACH considering SSB0 and SSB30 which have the highest RSRP values. Considering that the next RO for SSB30 is the second repeating RO and the next RO for SSB0 is the third repeating RO, the UE may select SSB30, which has a larger number of actual repetitions.

[0261] [Selection Method 3] The UE considers the RSRP value of each beam, as well as the order of the next available RO repetitions associated with that beam (or the remaining actual number of repetitions associated with each beam). This is similar to selection method 2, but differs in that it considers the actual number of repetitions associated with each beam instead of the number of repetitions set for each beam. In this case, all SSBs may be associated with the same maximum number of repetitions. The remaining actual number of repetitions associated with each beam may be different at the time the UE selects a beam for access.

[0262] For example, for several beams that exceed the RSRP threshold, the UE may assign a beam with the first repeating RO (second repeating RO, third repeating RO, etc.) as the next available repeating RO associated with a beam that has a higher priority than a beam with the second repeating RO (third repeating RO, fourth repeating RO, etc.). This may mean that the UE selects beams and their ROs with a larger actual repeating count from all beams that satisfy the RSRP threshold.

[0263] According to this embodiment, the UE can appropriately determine the PRACH resource / beam.

[0264] <Embodiment #A4> This embodiment relates to a counter for a preamble.

[0265] If subsequent repetitions of the preamble (second, third, ...) are transmitted, at least one of the following parameters 1 through 3 may remain unaffected (not be incremented). This may mean that repeated preamble transmissions do not affect the maximum number of transmissions / count / power ramping. [Parameter 1] Preamble transmission counter (PREAMBLE_TRANSMISSION_COUNTER). [Parameter 2] Preamble power ramping (PREAMBLE_POWER_RAMPING_COUNTER). [Parameter 3] Preamble received target power (PREAMBLE_RECEIVED_TARGET_POWER).

[0266] According to this embodiment, the UE can properly transmit PRACH repetitions.

[0267] <Embodiment #A5> This embodiment relates to the number of iterations in the RACH procedure.

[0268] Whether the number of PRACH iterations affects the number of iterations for the remaining RACH steps may be due to one of the following effects 1 or 2.

[0269] [Impact 1] The number of PRACH iterations affects the number of iterations for the remaining RACH steps. At least one of the following iteration numbers, from 1 to 4, may be derived from the number of PRACH iterations. [Number of repetitions 1] The number of repetitions of Msg.2. [Number of repetitions 2] The number of repetitions of Msg.3. [Number of repetitions: 3] The number of repetitions of Msg.4. [Number of repetitions: 4] Number of repetitions of Msg.4 HARQ-ACK transmission (PUCCH).

[0270] The mapping between a PRACH iteration and at least one of the iteration counts from 1 to 4 may be configured by upper-layer signaling or specified in the specification.

[0271] [Impact 2] The number of PRACH iterations does not affect the number of iterations for the remaining RACH procedures. At least one of the iteration numbers from 1 to 4 may be determined independently of the PRACH iterations or may be specified in the specification.

[0272] According to this embodiment, the UE can appropriately determine the number of iterations in the RACH procedure.

[0273] <Embodiment #A6> This embodiment relates to Msg.2 / Msg.B.

[0274] Regarding repetition, Msg.2 may follow either Msg.2 Action 1 or 2 below. [Msg.2 Operation 1] Whether Msg.2 supports repetition may be set by SIB / RRC or in conjunction with RACH settings. UE capabilities regarding Msg.2 repetition may be defined. [Msg.2 Operation 2] Repeating Msg.2 is not supported.

[0275] Regarding repetition, Msg.B may follow either Msg.B action 1 or 2 below. [Msg.B operation 1] Whether Msg.B supports repetition may be set by SIB / RRC or together with the RACH setting. UE capabilities regarding Msg.B repetition may be defined. [Msg.B operation 2] Repeating Msg.B is not supported.

[0276] According to this embodiment, the UE can properly receive Msg.2 / Msg.B.

[0277] <Embodiment #A7> This embodiment relates to DCI for Msg.2 and at least one monitoring of Msg.2.

[0278] Whether the UE monitors at least one of the following before sending all PRACH iterations—DCI with a cyclic redundancy check (CRC) scrambled by RA-RNTI, Msg.2, or Msg.2—may depend on one of the following monitoring actions 1, 2, or 2a.

[0279] [Monitoring operation 1] The UE does not monitor at least one of the following before sending all PRACH repetitions: DCI with CRC scrambled by RA-RNTI, Msg.2, and so on. In this case, the power consumption of the DCI measurement can be reduced.

[0280] [Monitoring operation 2] The UE monitors at least one of the following before sending all PRACH repetitions: DCI with CRC scrambled by RA-RNTI, and Msg.2. In this case, initial access is faster. After receiving at least one of the following: DCI with CRC scrambled by RA-RNTI, and Msg.2, the UE does not have to send the remaining PRACH, nor is it required to send the remaining PRACH.

[0281] In the example in Figure 31, the number of PRACH repetitions is 4. The UE may monitor at least one of the following after the second repetition RO: DCI with CRC scrambled by RA-RNTI, Msg.2, and

[0282] [Monitoring operation 2a] The UE may monitor at least one of the following (if it can / wants to monitor) before sending all of the PRACH repetitions: the DCI with the CRC scrambled by RA-RNTI, and Msg.2. Even if the base station can detect the first PRACH and sends Msg.2, the base station does not know whether the UE can monitor Msg.2. Therefore, until the base station receives Msg.3, the base station may send Msg.2 assuming that the UE can monitor at least one of the following after sending all of the PRACH repetitions: the DCI with the CRC scrambled by RA-RNTI, and Msg.2.

[0283] According to this embodiment, the UE can properly receive Msg.2.

[0284] <Embodiment #A8> In this embodiment, it is assumed that there is no repetition of Msg.2 / Msg.B.

[0285] If Msg.1 is repeated, the UE / MAC entity may follow at least one of the following window behaviors 1 through 3 with respect to the ra-ResponseWindow.

[0286] 《Window Operation 1》 The UE / MAC entity initiates the ra-ResponseWindow on the first PDCCH occasion following the end of the last actual repeat transmission of the RA preamble. The last actual repeat transmission may be the last repeat RO for the associated SSB within the repeat period. This behavior may mean that the UE begins monitoring the RAR (which may include monitoring the base station's response to the BFR) after all repeated preambles have been transmitted.

[0287] 《Window Operation 2》 The UE / MAC entity starts / restarts the ra-ResponseWindow on the first PDCCH occasion from the end of each actual repeated transmission of the RA preamble. This behavior may mean that the UE monitors the RAR (which may include monitoring the base station's response to the BFR) before completing the transmission of all repeated preambles. Subsequent preamble repetitions may be dropped.

[0288] [Case A] If the ra-ResponseWindow length is less than the gap distance between two PRACH preamble repetitions, the ra-ResponseWindow may be considered as three separate windows for RAR monitoring after each PRACH. If a RAR is successfully received within the ra-ResponseWindow, the UE may stop / drop subsequent PRACH / Msg.1 repetitions. If a RAR is successfully received within the ra-ResponseWindow, the UE may stop / drop subsequent PRACH / Msg.1 repetitions after sending Msg.3. If a RAR is successfully received within the ra-ResponseWindow, the UE may stop / drop subsequent PRACH / Msg.1 repetitions after receiving Msg.4.

[0289] [Case B] If the ra-ResponseWindow length is greater than the gap distance between two PRACH preamble repetitions, the ra-ResponseWindow may be considered as one window for RAR monitoring after the first actual PRACH transmission, with the window restarting after each repetition transmission. If RAR reception is successful after a PRACH repetition, the UE may stop / drop subsequent preamble repetitions (this may or may not be after Msg.3 / Msg.4). In this case, the UE may also stop the window.

[0290] Using the repeating settings of unit resources 2 to 6 described above, the gap distance is very small, and Case B may also be acceptable.

[0291] In the example in Figure 32, as in Figure 30 above, the UE selects SSB30 and starts repeating transmission from the second repeating RO. In the example of window operation 1, the UE starts the ra-ResponseWindow after all repeats (the fourth repeating RO). In the example of window operation 2 case A, the UE starts the ra-ResponseWindow after each repeat (the second, third, and fourth repeating ROs, respectively). The length of each ra-ResponseWindow is shorter than the time interval between two repeats. In the example of window operation 2 case B, the UE starts the ra-ResponseWindow after each repeat (the second, third, and fourth repeating ROs, respectively). The length of each ra-ResponseWindow is longer than the time interval between two repeats.

[0292] 《Window Operation 3》 The UE / MAC entity initiates the ra-ResponseWindow on the first PDCCH occasion following the end of the first actual iteration transmission of the RA preamble. This window may expire before the UE receives the RAR and before the PRACH iteration transmission is complete. If the base station sends the RAR after the second iteration of the PRACH, the UE may not be able to monitor that RAR.

[0293] After the UE starts a ra-ResponseWindow after the first actual iteration, the UE may follow one of the following window behaviors 3a, 3b, or 3c.

[0294] [Window operation 3a] The UE does not need to assume that the ra-ResponseWindow expires before the end of the last preamble iteration, or before the end of the last preamble iteration by a specific time X.

[0295] [Window operation 3b] If a window expires and the timing of its expiration is before the last repetition RO of the SSB associated with the same preamble, or before time X after the last repetition RO of the SSB associated with the same preamble, and the UE fails to receive the RAR, the UE may reopen the window (taking into consideration that the ra-ResponseWindow length is not sufficient for the last repetition, i.e., the ra-ResponseWindow expires before the last repetition of the last preamble, or before time X (a specific time) after the last repetition of the last preamble).

[0296] [Window operation 3c] Based on window behavior 3b, if the window expires before the last iteration RO of the SSB associated with the same preamble, or before time X after the last iteration RO of the SSB associated with the same preamble, the UE may, in addition to resuming the window after the expiration, also resuming the window after the last iteration.

[0297] In each of window actions 3a through 3c, if RAR is successfully received after a PRACH repetition, the UE may stop / drop the subsequent repetition of the preamble (this may or may not occur after Msg.3 / Msg.4). In this case, the UE may also stop the window.

[0298] In the example in Figure 33, as in Figure 30 above, the UE selects SSB30 and starts repeating transmission from the second repeat RO. In the example of window operation 3a, the ra-ResponseWindow starts after the first repeat (1st repeat RO) and expires time X after the end of the last repeat (4th repeat RO). In the example of window operation 3b, the ra-ResponseWindow starts after the first repeat (1st repeat RO), expires before the end of the last repeat (4th repeat RO), is restarted, and expires after the last repeat (4th repeat RO). In another example of window operation 3b, the ra-ResponseWindow starts after each repeat and is restarted if it expires before the next repeat. In the last repeat (4th repeat RO), the ra-ResponseWindow expires time X after the end of that repeat. In the example of window operation 3c, the ra-ResponseWindow starts after the first repeat (1st repeat RO), expires before the last repeat (4th repeat RO), and is restarted. Furthermore, the ra-ResponseWindow is restarted after the last iteration (the fourth iteration RO).

[0299] UE capabilities related to window behavior 1 / 2 / 3 / 3a / 3b / 3c may be defined. UE capabilities related to whether or not to support resuming a window when it expires or is repeated may also be defined.

[0300] Window operations 1 / 2 / 3 / 3a / 3b / 3c may be applied to the msgB-ResponseWindow for two-step RACH. In this case, for the start of the window after each PRACH preamble in each window operation, at least one additional symbol of the value of the last symbol of the PRACH occasion corresponding to the PRACH transmission may be considered.

[0301] According to this embodiment, the UE can properly receive Msg.2 / Msg.B.

[0302] <Embodiment #A9> This embodiment relates to RNTI.

[0303] The RA-RNTI calculation may follow at least one of the following calculation methods 1 to 4.

[0304] 《Calculation method 1》 The RA-RNTI calculation uses the parameters of the first actual PRACH transmission among all iterative ROs. For example, these parameters may include s_id / t_id / f_id. This calculation method can be applied to all window operations of the aforementioned embodiment #A8.

[0305] In the example in Figure 34A, the number of repetitions is 4, and at least one of the DCI with the CRC scrambled by RA-RNTI, Msg.2, and is associated with the first repetition RO. RA-RNTI is calculated using the parameters of the first actual PRACH transmission.

[0306] 《Calculation method 2》 The RA-RNTI calculation uses the parameters of the last iteration's PRACH transmission. For example, these parameters may include s_id / t_id / f_id. This calculation method can be applied to window operation 1 of Embodiment #A8 described above.

[0307] 《Calculation method 3》 The RA-RNTI calculation uses the parameters of the PRACH transmission from each iteration prior to the end of the next iteration RO (the most recent iteration). For example, these parameters may include s_id / t_id / f_id. This calculation method can be applied to window operation 2 / 3 of Embodiment #A8 described above.

[0308] In the example in Figure 34B, the number of repetitions is 4, and at least one of the following is associated with each repetition RO: DCI with CRC scrambled by RA-RNTI, Msg.2, and RA-RNTI for DCI after the last repetition. The RA-RNTI for DCI after the last repetition is calculated using the parameters of the last PRACH transmission.

[0309] 《Calculation method 4》 The RA-RNTI calculation takes into account different parameters after the restart of the ra-ResponseWindow. For example, these parameters may include s_id / t_id / f_id. For example, if the window is restarted after a certain iteration, the RA-RNTI calculation may use the parameters of the most recent iteration for the RA-RNTI within the subsequent window time. For example, if the window is restarted after the window expires, the RA-RNTI calculation may use the parameters of the most recent iteration for the RA-RNTI within the subsequent window time, or it may not be necessary to update the parameters for the RA-RNTI under this condition.

[0310] UE capability may be defined regarding whether or not to change RA-RNTI for the window for repeated PRACH preamble transmissions.

[0311] A different calculation method from calculation methods 1 to 4 may be applied to multiple window operations in the above-described embodiment #A8, to different windows in a certain window operation in embodiment #A8, or to different durations / lengths of each window in embodiment #A8.

[0312] Calculation methods 1 to 4 may be applied to MSGB-RNTI of a two-step RACH.

[0313] According to this embodiment, the UE can properly receive Msg.2 / Msg.B.

[0314] <Embodiment #A10> This embodiment relates to UE capabilities.

[0315] The UE may report its ability to support PRACH repetitions according to either of the following reporting methods 1 or 2.

[0316] 《Reporting method 1》 Different preambles / occasions for PRACH may be specified for UEs that support PRACH repetition and UEs that do not support PRACH repetition. UEs that do not support PRACH repetition may include UEs of Rel. 15 / 16.

[0317] For UEs that support different numbers (maximum number) of PRACH repetitions, different preambles / occasions for PRACH may be specified.

[0318] By using different preambles / occasions for PRACH, the base station can determine whether the UE supports PRACH repetitions. The UE may further send additional information about its ability to support PRACH repetitions in Msg.3 or a subsequent RRC IE / MAC CE. For example, the additional information may be the maximum number of PRACH repetitions the UE supports, or it may indicate whether it supports at least one of the following: PRACH repetitions in 2-step RACH and PRACH repetitions in 4-step RACH.

[0319] 《Reporting method 2》 The same preamble / occasion for PRACH may be specified for UEs that support PRACH repetitions and UEs that do not support PRACH repetitions. UEs that do not support PRACH repetitions may include UEs from Rel. 15 / 16.

[0320] The base station cannot determine whether the UE supports PRACH repetitions by PRACH measurement. The UE may send additional information about its ability to support PRACH repetitions in Msg.3 or a subsequent RRC IE / MAC CE. For example, the additional information may indicate whether the UE supports PRACH repetitions, the maximum number of PRACH repetitions the UE supports, or whether it supports at least one of the following: PRACH repetitions in 2-step RACH and PRACH repetitions in 4-step RACH.

[0321] According to this embodiment, the UE can properly transmit PRACH repetitions.

[0322] <Embodiment #C0> Embodiments #A0 to #A10 describe the applicability of PRACH repetitions with the same beam or multiple different beams in the following cases. 2-step RACH / 4-step RACH. CFRA / CBRA. • Different PRACH formats. ·UE of RRC IDLE / RRC INACTIVE / RRC CONNECTED.

[0323] The applicability of PRACH repetitions involving the same beam or multiple different beams may be defined for the following cases. For that applicability, new restrictions, new UE capabilities, or RRC setting signaling may be defined in the specification. FR1 / FR2 / FR2-1 / FR2-2 / FRx. RA procedures (CBRA / CFRA) triggered by different purposes (PDCCH order PRACH, BFR, LBT failure, SI request, UL unsync, UL data transmission when SR is unavailable).

[0324] PRACH repetitions with multiple different beams may be applied only to specific RA schemes (e.g., at least one of CFRA, PDCCH order RA, RA for BFR, RA for LBT failure, RA for SI request, RA for UL out-of-sync, RA for UL data transmission when SR is unavailable).

[0325] According to this embodiment, for a given RA, the UE can appropriately determine PRACH repetitions with the same beam or multiple different beams.

[0326] <Embodiment #C1> If, in an SIB / RRC IE, a PRACH repetition with different multiple beams is configured / enabled for a certain purpose from among the RO / preamble resources associated with SSB / CSI-RS, and in one repetition, at least one resource of the RO / preamble is selected by the UE, then that at least one resource may be designated as its reference resource, and the associated beam (SSB / CSI-RS) may become the reference beam for that repetition. For one repetition, the reference beam may be assumed by the UE as the QCL for receiving Msg2, such as base station responses to RAR and BFR, after the PRACH repetition with different multiple beams.

[0327] The reference resource for each SSB / CSI-RS in the RO / preamble may be explicitly set by the RRC or specified in the specification based on certain rules. The RO / preamble index corresponding to each beam may be considered the reference resource for each beam. The rule may, for example, select the resource corresponding to the minimum or maximum index of the beam / RO / preamble / resource as the reference resource.

[0328] If the UE determines X iterations for a PRACH transmission, with multiple beams different for each iteration, for the selected beam and selected RO / preamble resources, then only one beam reference resource may be selected for the PRACH transmission so that there is only one QCL assumption for Msg2 reception. If it is permissible to select more than one beam reference resource for a single transmission iteration, then a rule may be defined for determining the QCL assumption for Msg2 reception. This rule may, for example, select the resource corresponding to the minimum or maximum index of the beam / RO / preamble as the reference resource.

[0329] It can be assumed that the UE uses the same preamble for multiple repetitions with different beams. If the UE uses different preambles for multiple repetitions, it may be difficult for the base station to know that the preambles for multiple repetitions are from the same UE, and the base station may not be able to decode combinations for different preambles. These problems can be mitigated if the preamble is the same for multiple repetitions.

[0330] Figure 35 shows an example of RA configuration for BFR. One or more RO / preamble indices are associated with each beam (SSB index). Of these one or more indices, one of the RO / preamble reference resource indices is set by the RRC IE. In this example, resources #0a, #0b, #0c, and #0d are associated with SSB#0, and reference resource #0a is set. In this example, resources #1a, #1b, #1c, and #1d are associated with SSB#1, and reference resource #1a is set. In this example, resources #2a, #2b, #2c, and #2d are associated with SSB#2, and reference resource #2b is set. In this example, resources #3a, #3b, #3c, and #3d are associated with SSB#3, and reference resource #3c is set. Examples 1 to 3 below are possible for this configuration.

[0331] [Example 1] The UE selects SSB#0 and #1 for preamble repetition and sends PRACH on resource #0a (referenced resource) and #1c (non-referenced resource). The UE assumes the same QCL as SSB#0 for receiving Msg2.

[0332] [Example 2] The UE selects SSB #0 and #1 for preamble iteration and sends PRACH on resource #0a (reference resource) and #1a (reference resource). The UE does not select resource #0a and #1a (reference resources for the two beams) in one iteration.

[0333] [Example 3] The UE selects SSB#0, #1, #2, and #3 for preamble repetition and sends PRACH on resources #0b, #1c, #2b (reference resource), and #3d. The UE assumes the same QCL as SSB#2 for receiving Msg2.

[0334] According to this embodiment, the UE can appropriately determine the resources / beams for PRACH iterations involving multiple different beams.

[0335] <Embodiment #C2> The aforementioned embodiment #C1 can be applied to the PDCCH order PRACH and other CFRA / CBRAs triggered by MAC / RRC. However, several other options are possible for the PDCCH order PRACH.

[0336] In the PDCCH order PRACH, the following solutions may be used for the selected beam and the reference beam for the QCL assumption for Msg2.

[0337] 《Solution 1》 For beams selected for PRACH repetitions involving multiple different beams, the PDCCH order DCI format 1_0 may indicate one or more additional fields of the beam index (SSB index, 'SS / PBCH index') for indicating more than one beam for PRACH repetitions involving multiple different beams. The number of additional beam index indications may be set by the RRC or specified in the specification. The number of additional beam index indications may be one, two, or more. The additional one or more fields may reuse at least some of the 12-bit or 10-bit reserved bits. The additional one or more fields may conform to either of the following fields 1 and 2. For one field of [Field 1] 'SS / PBCH index', the field size may be the existing 6 bits. For one field of [Field 2] 'SS / PBCH index', the field size may be set by the RRC or determined according to the SSB setting (e.g., SSB-PositionInBurst). If the number of SSBs being transmitted is small, the field size may be less than 6 bits.

[0338] 《Solution 2》 For QCL assumptions for Msg2 reception, if there are multiple fields for the SSB index within the PDCCH order DCI format 1_0, the UE may assume the SSB index of the first or last of those fields is the reference beam. When the UE receives Msg2 PDCCH, it may assume the same QCL as the reference beam. In this case, setting a reference resource for each SSB is not necessary.

[0339] A QCL assumption of order DCI format 1_0 in PDCCH may be assumed by the UE as the reference beam for the QCL assumption for Msg2 reception.

[0340] According to this embodiment, the UE can appropriately determine the beams of the PRACH repetition / Msg2 with multiple different beams initiated by the PDCCH order.

[0341] <Embodiment #C3> A new repetition resource setting may be defined for setting the repetition pattern or repetition resource for PRACH repetitions involving multiple different beams. The PRACH association period, configuration period, or PRACH occasion mapping cycle within an existing SIB / RRC may be considered a PRACH repetition period. The UE may select multiple beams for RA preamble repetitions from that PRACH repetition period.

[0342] The number of repetitions X may also be the number of different beams selected by the UE for repetitions involving different beams.

[0343] The number of repetitions may be set by the RRC IE / MAC CE, explicitly indicated in the PDCCH Order DCI Format 1_0, implicitly indicated by the number of SSB index fields in the PDCCH Order DCI Format 1_0, or determined by the UE based on the RSRP measurement results. Similar to embodiments #A2 / #A3, the UE may determine X based on the RSRP. There may be association settings between the number of repetitions 1, 2, ..., X and the RO / preamble resources.

[0344] The UE's rule for selecting multiple beams (SSB / CSI-RS) for a single PRACH repetition may be either of the following selection rules 1 or 2.

[0345] [Selection Rule 1] The UE uses an existing method for selecting N beams. For example, the existing method may select N beams corresponding to measurement results that exceed a threshold (e.g., RSRP). The existing method / threshold may be an existing threshold (e.g., rsrp-ThresholdSSB / rsrp-ThresholdCSI-RS), or a new parameter for PRACH iteration, or a new parameter for PRACH iteration with the same beam or multiple different beams.

[0346] [Selection Rule 2] The UE uses an existing method for selecting a reference beam. The UE may then follow either of the following selection rules 2-1 or 2-2. [[Selection Rule 2-1]] The UE selects N-1 repeating beams based on a new absolute RSRP threshold parameter. [[Selection Rule 2-2]] The UE selects N-1 repeating beams based on a new relative RSRP threshold parameter (e.g., rsrp-offset-ThresholdSSB / rsrp-offset-ThresholdCSI-RS) that is offset relative to the reference beam. For example, a beam may be selected for repeating if the offset is 6 dB or less.

[0347] Considering that UEs within SSB#A coverage may not be able to detect SSB#M, there may be restrictions on the beams selected. In addition to selection rules 1 / 2, either of the following restriction methods 1 and 2 may be applied to further restrict the beams selected.

[0348] [Restriction Method 1] The RRC sets up multiple groups of beams. In one iteration, the UE may select beams from one group.

[0349] This section describes an example of RRC setting up multiple groups for SSB / CSI-RS. Assuming SSB#0-#15, group #1 includes SSB#0, #1, #2, and #3; group #2 includes SSB#4, #5, #6, and #7; group #3 includes SSB#8, #9, #10, and #11; and group #4 includes SSB#12, #13, #14, and #15.

[0350] [Restriction Method 2] (Especially for selection rule 2,) for each beam, the RRC sets up a list of beams associated with that beam. In one iteration, the UE may select beams within one group. If one beam is selected by the UE as a reference beam, the UE may select N-1 other beams from the list of beams set up by the RRC and associated with that reference beam.

[0351] This section describes an example where RRC sets up a list of SSB / CSI-RS associated with each SSB. Assuming SSB#0-#15, SSB#0 is associated with SSB#14, #15, #1, and #2; SSB#1 is associated with SSB#15, #0, #2, and #3; and so on, with the SSB index in the association being incremented sequentially until SSB#15 is associated with SSB#13, #14, #0, and #1.

[0352] According to this embodiment, the UE can appropriately configure PRACH repetitions with multiple different beams.

[0353] <Embodiment #C4> Embodiments #A0 to #A10 describe the start / restart of the RAR window for PRACH repeats with the same beam. For example, the RAR window may start from the end of the first repeat, each repeat, or the last repeat. At least one of the methods in Embodiments #A0 to #A10 may be applied to PRACH repeats with different multiple beams.

[0354] On the other hand, considering the QCL assumption for Msg2 reception in Embodiments #C1 / #C2, a new method may be defined for starting / restarting the RAR window for PRACH repetitions involving multiple different beams.

[0355] The RAR window (ra-ResponseWindow) may be started / restarted in the first PDCCH occasion following the end of the RA preamble iteration of a reference resource or reference beam within a single iteration. The RAR window (ra-ResponseWindow) may also be started / restarted in the first PDCCH occasion following the end of one or more RA preamble iterations after the RA preamble iteration of a reference resource or reference beam within a single iteration (each RA preamble iteration after the RA preamble iteration of a reference resource or reference beam within a single iteration).

[0356] Before a reference resource or reference beam is transmitted, the network is unaware of the QCL assumptions for RAR. Therefore, the network cannot send Msg2 to the UE, and the UE may not need to monitor RAR.

[0357] A new RAR window (e.g., ra-ResponseWindow-r18) may be introduced for PRACH iterations. Different new parameters may be introduced for PRACH iterations involving the same beam or multiple different beams.

[0358] In the examples shown in Figures 36A to 36D, resource #0b of the RO / preamble using the SSB#0 beam, resource #1c of the RO / preamble using the SSB#1 beam, resource #2b of the RO / preamble using the SSB#2 beam, and resource #3d of the RO / preamble using the SSB#3 beam are used for transmitting PRACH repetitions. Resource #2b may be a reference resource, or SSB#2 may be a reference beam.

[0359] Figure 36A shows Example 1 of the RAR window. In this example, window operation 1 of Embodiment #A8 is applied. The RAR window starts after the last resource #3d has finished sending.

[0360] Figure 36B shows example 2 of the RAR window. In this example, case A of window operation 2 of embodiment #A8 is applied. The RAR window is started after the transmission of resources #0b, #1c, #2b, and #3d is completed.

[0361] Figure 36C shows Example 3 of the RAR window. In this example, Embodiment #C4 is applied. The RAR window starts after resource #2b and resource #3d, respectively, have finished transmitting, corresponding to resource #2b and subsequent resources of the reference beam. The QCL assumption for RAR reception may be the same as for SSB #2.

[0362] Figure 36D shows Example 4 of the RAR window. In this example, Embodiment #C4 is applied. The RAR window starts after the transmission of resource #2b corresponding to the reference beam has finished. The QCL assumption for RAR reception may be the same as that for SSB #2.

[0363] Based on the repetition resource settings for PRACH repetitions with multiple different beams in Embodiment #C4, the RO for each SSB is likely to be within a short duration, rather than using a large gap as shown in the examples in Figures 36A to 36D.

[0364] Figure 37A shows an example of SSB and RO association. RO#0a, #0b, #0c, and #0d associated with SSB#0, and RO#1a, #1b, #1c, and #1d associated with SSB#1 are placed in a certain time resource. RO#2a, #2b, #2c, and #2d associated with SSB#2, and RO#3a, #3b, #3c, and #3d associated with SSB#3 are placed in a subsequent time resource. In the examples in Figures 37B, 38A, and 38B, RO#0b, #1c, #2b, and #3d are used for transmitting PRACH repetitions.

[0365] Figure 37B shows Example 1 of the RAR window. In this example, window operation 1 of Embodiment #A8 is applied. The RAR window starts after the last resources #2b and #3d have finished being sent.

[0366] Figure 38A shows example 2 of the RAR window. In this example, case A of window operation 2 of embodiment #A8 is applied. The RAR window is started after the transmission of resources #0b and #1c, and resources #2b and #3d, respectively, is completed.

[0367] Figure 38B shows Example 3 of the RAR window. Embodiment #C4 is applied in this example. The RAR window starts after the transmission of resource #2b corresponding to the reference beam has finished. The QCL assumption for RAR reception may be the same as that for SSB #2.

[0368] According to this embodiment, the UE can properly receive RAR for PRACH repetitions involving multiple different beams.

[0369] <Embodiment #C5> This embodiment relates to a combination of PRACH iterations with the same beam and PRACH iterations with different beams. The UE may support a combination of two or more iterations with the same beam and one or more iterations with one or more different beams.

[0370] The UE may specify that it does not assume that PRACH repetitions with the same beam and PRACH repetitions with different beams will be set up simultaneously.

[0371] Separate UE capabilities may be defined / reported for support of PRACH repetitions with the same beam and support of PRACH repetitions with different beams. The UE may apply supported PRACH repetition schemes without conditions / limitations (at the UE's discretion). The UE may apply supported PRACH repetition schemes according to conditions / limitations. These conditions / limitations may be that RSRP / RSRQ is below a threshold, or that the initial PRACH transmission failed, i.e., Msg2 was not received.

[0372] The base station may be instructed / configured by the SIB / RRC settings to use either PRACH repetition with the same beam or PRACH repetition with multiple different beams. This instruction / configuration may apply to only a few scenarios, which may include at least one of handover and UL synchronization.

[0373] If this instruction / setting is not present, the UE may apply the default behavior. The default behavior may be one of the following: • Sending PRACH messages for Rel.15 / 16 (no repetition). • PRACH repetition with the same beam • PRACH repetition with multiple different beams

[0374] According to this embodiment, the UE can appropriately perform at least one of the following: a PRACH repetition with the same beam and a PRACH repetition with a different beam.

[0375] <Embodiment #C10> This embodiment relates to the aforementioned DL / UL beam assumption 1.

[0376] 《Option A》 After each beam's PRACH repetition, the UE may initiate a RAR window (ra-ResponseWindow) in the first PDCCH occasion following the end of each repeated transmission of the RA preamble. The UE may assume that at most one Msg2 (e.g., a base station response to the RAR, BFR) will be received within all RAR windows. The UE may assume that the beam associated with the received Msg2 (the PRACH repeated transmission beam) is the selected UL beam. That selected UL beam may be used as the default UL beam / QCL source for subsequent UL transmissions.

[0377] The QCL assumption in DL Msg2 may be the same as the selected DL beam identified in a previous 4-step RACH or in an earlier operation. The selected DL beam may be, for example, the beam of the PDCCH order DCI that triggers a PDCCH order PRACH iteration with multiple different beams.

[0378] The selection of the UL beam may mean that the base station measures the PRACH preamble reception conditions, selects one preamble with good UL quality, and sends Msg2 within the RAR window for the selected good UL beam. If the base station sends Msg2 before the last PRACH iteration, that UL beam may not be the best beam, but it is still a sufficiently good UL beam.

[0379] If the RAR windows for each beam do not overlap, the timing of decoding Msg2 may be used to identify the UL beam corresponding to that Msg2.

[0380] In the examples in Figures 39A and 39B, the four UL beams used in the four iterations of PRACH correspond to SSB#0, #1, #2, and #3, respectively. SSB#1 is the best identified DL beam.

[0381] In the example in Figure 39A, four repetitions of PRACH are transmitted in ROs of different time resources. In this example, the UE starts a RAR window after each repetition. The four RAR windows do not overlap. Within each RAR window, the QCL assumption for DL ​​reception is SSB#1, which is the best DL beam. In this example, the UE decodes the RAR within the RAR window for SSB#2. This means that the selected good UL beam / UL QCL assumption is SSB#2.

[0382] If the RAR windows for each beam overlap, the Msg2 for each beam may be identified by RA-RNTI. For example, the parameters (s_id / t_id / f_id) used to calculate RA-RNTI may differ for each iteration. This identification method may require the UE to attempt to receive multiple RA-RNTIs (multiple CRCs scrambled by multiple RA-RNTIs, and multiple DCIs associated with each of those CRCs) within the overlapping time period.

[0383] In the example in Figure 39B, RO#0b associated with SSB#0 and RO#1c associated with SSB#1 are in the same time resource, and then RO#2b associated with SSB#2 and RO#3d associated with SSB#3 are in the same time resource. In this example, the UE starts RAR window #0 after RO#0b, RAR window #1 after RO#1c, RAR window #2 after RO#2b, and RAR window #1 after RO#3d. RAR windows #0, #1, #2, and #3 overlap. When Msg2 for SSB#0 is sent within RAR window #0, RA-RNTI#0 is used. When Msg2 for SSB#1 is sent within RAR window #1, RA-RNTI#1 is used. When Msg2 for SSB#2 is sent within RAR window #2, RA-RNTI#2 is used. When Msg2 is sent for SSB#3 within RAR window #3, RA-RNTI#3 is used. Within each RAR window, the QCL assumption for DL ​​reception is SSB#1, which is the best DL beam. In this example, the UE uses different RA-RNTIs to decode Msg2 for each SSB. In this example, the UE decodes the RAR using RA-RNTI#3 for SSB#3. This means that the selected good UL beam / UL QCL assumption is SSB#3.

[0384] 《Option B》 After multiple PRACH repetitions of different beams, the UE may initiate a RAR window (ra-ResponseWindow) in the first PDCCH occasion from the end of the last repetition transmission of the RA preamble. The UE may assume that at most one Msg2 (e.g., a base station response to the RAR, BFR) will be received within that RAR window. The UE may assume that the beam associated with the received Msg2 (the PRACH repetition transmission beam) is the selected (best) UL beam. That selected UL beam may be used as the default UL beam / QCL source for subsequent UL transmissions.

[0385] The QCL assumption in DL Msg2 may be the same as the selected DL beam identified in a previous 4-step RACH or in an earlier operation. The selected DL beam may be, for example, the beam of the PDCCH order DCI that triggers a PDCCH order PRACH iteration with multiple different beams.

[0386] The selection of the UL beam may also mean that the base station measures the PRACH preamble reception conditions, selects one preamble with good UL quality, and sends Msg2 within the RAR window for the selected good UL beam.

[0387] The UE may be required to attempt to receive all RA-RNTIs (multiple CRCs scrambled by multiple RA-RNTIs, each with multiple DCIs associated with those multiple CRCs) for multiple preambles transmitted within its RAR window. The beam associated with the decoded Msg2 may be identified by the RA-RNTI (corresponding to that decoded Msg2). For example, the parameters (s_id / t_id / f_id) used to calculate the RA-RNTI may differ for each iteration.

[0388] In the examples in Figures 40A and 40B, the four UL beams used in the four iterations of PRACH correspond to SSB#0, #1, #2, and #3, respectively. SSB#1 is the best identified DL beam.

[0389] In the example in Figure 40A, four repetitions of PRACH are transmitted at ROs with different time resources. In this example, the UE starts a RAR window after the last repetition. Within that RAR window, the QCL assumption for DL ​​reception is SSB#1, which is the best DL beam. Within that RAR window, the UE attempts to receive the RAR scheduling DCI using different RA-RNTIs. In this example, the UE decodes the RAR (RAR scheduling DCI) using the RA-RNTI of the RO for SSB#2. This means that the selected best UL beam / UL QCL assumption is SSB#2.

[0390] In the example in Figure 40B, RO#0b associated with SSB#0 and RO#1c associated with SSB#1 are in the same time resource, and subsequently, RO#2b associated with SSB#2 and RO#3d associated with SSB#3 are in the same time resource. In this example, the UE starts a RAR window after the last RO#2b and #3d in the time domain. Within that RAR window, the QCL assumption for DL ​​reception is SSB#1, which is the best DL beam. Within that RAR window, the UE attempts to receive the RAR scheduling DCI using different RA-RNTIs. In this example, the UE decodes the RAR (RAR scheduling DCI) using the RA-RNTI for SSB#3. This means that the selected best UL beam / UL QCL assumption is SSB#3.

[0391] According to this embodiment, the UE can appropriately perform at least one of the following: a PRACH repetition with the same beam and a PRACH repetition with a different beam.

[0392] <Embodiment #C11> This embodiment relates to the aforementioned DL / UL beam assumption 2.

[0393] 《Option A》 In addition to embodiments #C1 / #C2, which involve the instruction / determination of a reference beam / reference resource, after each beam PRACH repetition, the UE may initiate a RAR window (ra-ResponseWindow) in the first PDCCH occasion from the end of each repeated transmission of the RA preamble. For Msg2 reception within each RAR window, the UE may assume a reference beam as the QCL assumption for Msg2 reception. However, the UE may assume that at most one Msg2 (e.g., a base station response to a RAR, BFR) will be received within all RAR windows. The UE may assume that the beam associated with the received Msg2 (the PRACH repeated transmission beam) is the selected UL beam. That selected UL beam may be used as the default UL beam / QCL source for subsequent UL transmissions.

[0394] The QCL assumption for DL ​​Msg2 may be the reference beam in Embodiment #C1 / #C2.

[0395] The selection of the UL beam may also mean that the base station measures the PRACH preamble reception conditions, selects one preamble with good UL quality, and sends Msg2 within the RAR window for the selected good UL beam.

[0396] If the RAR windows for each beam do not overlap, the timing of decoding Msg2 may be used to identify the UL beam corresponding to that Msg2.

[0397] In the examples in Figures 41A and 41B, the four UL beams used in the four iterations of PRACH correspond to SSB #0, #1, #2, and #3, respectively. The reference beam is SSB #2. The reference resource is resource #2b in the RO / preamble.

[0398] In the example in Figure 41A, four repetitions of PRACH are transmitted using RO / preamble resources #0b, #1c, #2b, and #3d, respectively, with different time resources. In this example, the UE starts a RAR window after each repetition. The four RAR windows do not overlap. Within each RAR window, the QCL assumption for DL ​​reception is SSB#2, which is the reference beam. In this example, the UE decodes the RAR within the RAR window for SSB#1. This means that the selected good UL beam / UL QCL assumption is SSB#1.

[0399] If the RAR windows for each beam overlap, the Msg2 for each beam may be identified by RA-RNTI. For example, the parameters (s_id / t_id / f_id) used to calculate RA-RNTI may differ for each iteration. This identification method may require the UE to attempt to receive multiple RA-RNTIs (multiple CRCs scrambled by multiple RA-RNTIs, and multiple DCIs associated with each of those CRCs) within the overlapping time period.

[0400] In the example in Figure 41B, RO#0b associated with SSB#0 and RO#1c associated with SSB#1 are in the same time resource, and then RO#2b associated with SSB#2 and RO#3d associated with SSB#3 are in the same time resource. In this example, the UE starts RAR window #0 after RO#0b, RAR window #1 after RO#1c, RAR window #2 after RO#2b, and RAR window #1 after RO#3d. RAR windows #0, #1, #2, and #3 overlap. When Msg2 for SSB#0 is sent within RAR window #0, RA-RNTI#0 is used. When Msg2 for SSB#1 is sent within RAR window #1, RA-RNTI#1 is used. When Msg2 for SSB#2 is sent within RAR window #2, RA-RNTI#2 is used. When Msg2 is sent for SSB#3 within RAR window #3, RA-RNTI#3 is used. Within each RAR window, the QCL assumption for DL ​​reception is the reference beam, SSB#2. In this example, the UE uses a different RA-RNTI to decode Msg2 for each SSB. In this example, the UE decodes the RAR using RA-RNTI#3 for SSB#3. This means that the selected good UL beam / UL QCL assumption is SSB#3.

[0401] In Embodiment #C10, the PRACH iteration with multiple different beams may be an additional method solely for UL beam management, having a function similar to that of an SRS for beam management.

[0402] In Embodiment #C11, the PRACH iteration with multiple different beams may be a novel method that can be used to identify both DL beams and UL beams within a single procedure.

[0403] 《Option B》 In addition to embodiments #C1 / #C2, which involve the instruction / determination of a reference beam / reference resource, after PRACH repetitions of multiple different beams, the UE may initiate a RAR window (ra-ResponseWindow) in the first PDCCH occasion from the end of the last repetition transmission of the RA preamble. For Msg2 reception within that RAR window, the UE may assume the reference beam as the QCL assumption for Msg2 reception. The UE may assume that at most one Msg2 (e.g., a base station response to a RAR, BFR) will be received within that RAR window. The UE may assume that the beam associated with the received Msg2 (the PRACH repetition transmission beam) is the selected best UL beam. That selected UL beam may be used as the default UL beam / QCL source for subsequent UL transmissions.

[0404] The QCL assumption for DL ​​Msg2 may be the reference beam in Embodiment #C1 / #C2.

[0405] The selection of the UL beam may also mean that the base station measures the PRACH preamble reception conditions, selects one preamble with good UL quality, and sends Msg2 within the RAR window for the selected good UL beam.

[0406] The UE may be required to attempt to receive all RA-RNTIs (multiple CRCs scrambled by multiple RA-RNTIs, each with multiple DCIs associated with those multiple CRCs) for multiple preambles transmitted within its RAR window. The beam associated with the decoded Msg2 may be identified by the RA-RNTI (corresponding to that decoded Msg2). For example, the parameters (s_id / t_id / f_id) used to calculate the RA-RNTI may differ for each iteration.

[0407] In the examples in Figures 42A and 42B, the four UL beams used in the four iterations of PRACH correspond to SSB #0, #1, #2, and #3, respectively. The reference beam is SSB #2. The reference resource is resource #2b in the RO / preamble.

[0408] In the example in Figure 42A, four repetitions of PRACH are transmitted at ROs of different time resources. In this example, the UE starts a RAR window after the last repetition. Within that RAR window, the QCL assumption for DL ​​reception is SSB#2, which is the reference beam. Within that RAR window, the UE attempts to receive the RAR scheduling DCI using different RA-RNTIs. In this example, the UE decodes the RAR (RAR scheduling DCI) using the RA-RNTI of the RO for SSB#1. This means that the best selected UL beam / UL QCL assumption is SSB#1.

[0409] In the example in Figure 42B, RO#0b associated with SSB#0 and RO#1c associated with SSB#1 are in the same time resource, and subsequently, RO#2b associated with SSB#2 and RO#3d associated with SSB#3 are in the same time resource. In this example, the UE starts a RAR window after the last RO#2b and #3d in the time domain. Within that RAR window, the QCL assumption for DL ​​reception is SSB#2, which is the reference beam. Within that RAR window, the UE attempts to receive the RAR scheduling DCI using different RA-RNTIs. In this example, the UE decodes the RAR (RAR scheduling DCI) using the RA-RNTI for SSB#1. This means that the best selected UL beam / UL QCL assumption is SSB#1.

[0410] According to this embodiment, the UE can appropriately determine the UL beam for PRACH iterations with different beams, based on the indicated reference resource / reference beam.

[0411] <Other Embodiments> 《UE Ability Information / Higher Layer Parameters》 Higher layer parameters (RRC IE) / UE capabilities may be defined corresponding to the features in each of the above embodiments. The higher layer parameters may indicate whether or not to enable the feature. The UE capabilities may indicate whether or not the UE supports the feature.

[0412] A UE that has the corresponding higher-level parameter set may perform that function. It may also be stipulated that "a UE that does not have the corresponding higher-level parameter set may not perform that function (for example, according to Rel. 15 / 16)."

[0413] A UE that reports / submits UE capability indicating support for that function may perform that function. It may be stipulated that "a UE that has not reported UE capability indicating support for that function shall not perform that function (e.g., in accordance with Rel. 15 / 16)."

[0414] If the UE reports / sends a UE capability indicating support for that function, and the corresponding higher-layer parameters are set, the UE may perform that function. It may also be stipulated that "if the UE does not report / send a UE capability indicating support for that function, or if the corresponding higher-layer parameters are not set, the UE shall not perform that function (e.g., in accordance with Rel. 15 / 16)."

[0415] Which of the above multiple embodiments / options / choices / features is used may be set by higher-layer parameters, reported by the UE as UE capability, specified in the specification, or determined by the reported UE capability and the setting of the higher-layer parameters.

[0416] UE capability may indicate whether the UE supports at least one of the following features: • Dynamic / explicit indication of the number of repetitions within the PDCCH order DCI. • Count the set RO (Routing Order) for the specified number of repetitions. • Count the valid ROs for the specified number of repetitions. • The same PRACH preamble repeats across multiple iteration periods. • The repetition of the same PRACH preamble is limited to within a single repetition period. • The number of specified iterations is limited. For example, the number of specified iterations does not exceed the RRC-configured value (maximum value). For example, the number of specified iterations does not exceed the remaining configured number of ROs within one iteration period. For example, the number of specified iterations does not exceed the number of valid ROs within one iteration period. • Introduce the assumption of a default number of repetitions in different cases (combinations). • PRACH repetition, or PRACH repetition resource setting. • At least one of the following: a PRACH repeat in CFRA and a PRACH repeat in CBRA. At least one of the following: a PRACH iteration in a 2-step RACH, and a PRACH iteration in a 4-step RACH. • PRACH repetition in specific-purpose RA. • One or more unit resources from Unit Resource 1 to 6. Repeat Msg.2. Repeat Msg.B. Window operation 1 / 2 / 3 / 3a / 3b / 3c. • Reopening a window when it expires or repeats. • Modify RA-RNTI for the window of repeated PRACH preamble transmissions. • PRACH iterations with multiple different beams (e.g., the first embodiment). • At least one of the following: a reference beam and a reference resource in the RO / preamble. Support for at least one of the following in each of multiple different cases: a reference beam and a reference resource in the RO / preamble. • The QCL assumption for Msg2 (such as base station response to RAR and BFR) is the reference beam. In each of the multiple different cases, the QCL assumption for Msg2 is the reference beam. • Limitations on the beams selected for each repetition. • The RAR window should start after the referenced resource / referenced beam. • Separate RAR windows for each PRACH iteration (with the same beam / multiple different beams). • The RAR window after the last PRACH iteration (with the same beam / multiple different beams). • Separate RA-RNTI for Msg2 monitoring within each RAR window for each PRACH repetition (with the same beam / multiple different beams). • The association between Msg2 and the UL beam / QCL assumption. That is, receiving Msg2 implies that the associated beam is a good / best selected UL beam, or a QCL assumption for subsequent UL transmission. • Multiple Msg3 transmissions for PRACH repetitions (with multiple different beams). • A new MAC CE for SSB / CSI-RS beam indication (for the selected DL beam) for PRACH repetitions (with multiple different beams). The MAC CE should be communicated within Msg3. • Multiple Msg4 reception for PRACH repetitions (with multiple different beams). Multiple Msg4 with the same QCL assumption (PDCCH of multiple Msg4). Start / restart RA conflict resolution timer after each Msg3. Start conflict resolution timer after only Msg3 for the last repetition. • Msg4 implies the selected UL beam. • A new MAC CE for SSB / CSI-RS beam designation (for the selected UL beam). The MAC CE should be communicated within Msg4.

[0417] UE capability may represent at least one of the following values: • Maximum number of repetitions for PDCCH order PRACH. • Number of PRACH repetitions (maximum number). • Setting the repetition period. • The maximum number of repetitions (with multiple different beams) in a PRACH iteration involving multiple different beams.

[0418] Based on the above UE capabilities / higher layer parameters, the UE can achieve the above functions while maintaining compatibility with existing specifications.

[0419] (Wireless communication system) The configuration of a wireless communication system according to one embodiment of this disclosure will be described below. In this wireless communication system, communication is performed using any or a combination thereof of the wireless communication methods according to the above embodiments of this disclosure.

[0420] Figure 43 shows an example of a schematic configuration of a wireless communication system according to one embodiment. The wireless communication system 1 may be a system that realizes communication using Long Term Evolution (LTE), 5th generation mobile communication system New Radio (5G NR), etc., as specified by the Third Generation Partnership Project (3GPP).

[0421] Furthermore, the wireless communication system 1 may support dual connectivity between multiple Radio Access Technologies (RATs) (Multi-RAT Dual Connectivity (MR-DC)). MR-DC may include dual connectivity between LTE (Evolved Universal Terrestrial Radio Access (E-UTRA)) and NR (E-UTRA-NR Dual Connectivity (EN-DC)), dual connectivity between NR and LTE (NR-E-UTRA Dual Connectivity (NE-DC)), and so on.

[0422] In EN-DC, the LTE (E-UTRA) base station (eNB) is the Master Node (MN), and the NR base station (gNB) is the Secondary Node (SN). In NE-DC, the NR base station (gNB) is the MN, and the LTE (E-UTRA) base station (eNB) is the SN.

[0423] The wireless communication system 1 may support dual connectivity between multiple base stations within the same RAT (for example, dual connectivity where both MN and SN are NR base stations (gNB) (NR-NR Dual Connectivity (NN-DC))).

[0424] The wireless communication system 1 may include a base station 11 that forms a macrocell C1 with relatively wide coverage, and base stations 12 (12a-12c) located within the macrocell C1 that form a small cell C2 that is narrower than the macrocell C1. User terminals 20 may be located within at least one cell. The arrangement and number of each cell and user terminal 20 are not limited to the configuration shown in the figure. Hereinafter, when base stations 11 and 12 are not distinguished, they will be collectively referred to as base station 10.

[0425] The user terminal 20 may be connected to at least one of the multiple base stations 10. The user terminal 20 may utilize at least one of Carrier Aggregation (CA) using multiple Component Carriers (CC) and Dual Connectivity (DC).

[0426] Each CC may be included in at least one of the first frequency band (Frequency Range 1 (FR1)) and the second frequency band (Frequency Range 2 (FR2)). A macrocell C1 may be included in FR1, and a small cell C2 may be included in FR2. For example, FR1 may be a frequency band of 6 GHz or less (sub-6 GHz), and FR2 may be a frequency band above 24 GHz (above-24 GHz). Note that the frequency bands and definitions of FR1 and FR2 are not limited to these, and for example, FR1 may fall in a frequency band higher than FR2.

[0427] Furthermore, the user terminal 20 may communicate using at least one of the following methods at each CC: Time Division Duplex (TDD) and Frequency Division Duplex (FDD).

[0428] Multiple base stations 10 may be connected by wire (e.g., optical fiber compliant with Common Public Radio Interface (CPRI), X2 interface, etc.) or wireless (e.g., NR communication). For example, if NR communication is used as a backhaul between base stations 11 and 12, base station 11, which is the upstream station, may be called an Integrated Access Backhaul (IAB) donor, and base station 12, which is the relay station, may be called an IAB node.

[0429] Base station 10 may be connected to the core network 30 via other base stations 10 or directly. The core network 30 may include at least one of the following: Evolved Packet Core (EPC), 5G Core Network (5GCN), Next Generation Core (NGC), etc.

[0430] The user terminal 20 may be a terminal that supports at least one of the following communication methods: LTE, LTE-A, 5G, etc.

[0431] In the wireless communication system 1, an orthogonal frequency division multiplexing (OFDM)-based wireless access scheme may be used. For example, Cyclic Prefix OFDM (CP-OFDM), Discrete Fourier Transform Spread OFDM (DFT-s-OFDM), Orthogonal Frequency Division Multiple Access (OFDMA), Single Carrier Frequency Division Multiple Access (SC-FDMA), etc., may be used in at least one of the downlink (DL) and uplink (UL).

[0432] The wireless access method may also be called a waveform. In wireless communication system 1, other wireless access methods (for example, other single-carrier transmission methods, other multi-carrier transmission methods) may be used for the UL and DL wireless access methods.

[0433] In the wireless communication system 1, a Physical Downlink Shared Channel (PDSCH), a Broadcast Channel (PBCH), or a Physical Downlink Control Channel (PDCCH) may be used as the downlink channel, shared by each user terminal 20.

[0434] Furthermore, in the wireless communication system 1, the uplink channel may include a Physical Uplink Shared Channel (PUSCH), a Physical Uplink Control Channel (PUCCH), a Physical Random Access Channel (PRACH), or the like, all of which are shared by each user terminal 20.

[0435] User data, higher-layer control information, and System Information Blocks (SIBs) are transmitted via PDSCH. User data and higher-layer control information may also be transmitted via PUSCH. Furthermore, Master Information Blocks (MIBs) may be transmitted via PBCH.

[0436] Lower-layer control information may be transmitted by PDCCH. The lower-layer control information may include, for example, Downlink Control Information (DCI) which includes scheduling information for at least one of PDSCH and PUSCH.

[0437] Furthermore, the DCI that schedules PDSCH may be called a DL assignment or DL ​​DCI, and the DCI that schedules PUSCH may be called a UL grant or UL DCI. Furthermore, PDSCH may be interpreted as DL data, and PUSCH may be interpreted as UL data.

[0438] PDCCH detection may utilize a Control Resource Set (CORESET) and a search space. A CORESET corresponds to the resources used to search for DCIs. A search space corresponds to the search area and search method for PDCCH candidates. A single CORESET may be associated with one or more search spaces. The UE may monitor CORESETs associated with a particular search space based on the search space configuration.

[0439] A single search space may correspond to one or more PDCCH candidates corresponding to aggregation levels. One or more search spaces may be referred to as a search space set. In this disclosure, "search space," "search space set," "search space configuration," "search space set configuration," "CORESET," and "CORESET configuration" may be interpreted interchangeably.

[0440] PUCCH may transmit uplink control information (UCI) which includes at least one of the following: channel state information (CSI), delivery acknowledgment (e.g., Hybrid Automatic Repeat reQuest ACKnowledgement (HARQ-ACK), ACK / NACK, etc.), and scheduling request (SR). PRACH may transmit a random access preamble for establishing a connection with the cell.

[0441] In this disclosure, downlinks, uplinks, etc., may be expressed without the prefix "link." Also, the prefix "physical" may be omitted when describing various channels.

[0442] In the wireless communication system 1, a synchronization signal (SS), a downlink reference signal (DL-RS), etc., may be transmitted. In the wireless communication system 1, as DL-RS, a cell-specific reference signal (CRS), a channel state information reference signal (CSI-RS), a demodulation reference signal (DMRS), a positioning reference signal (PRS), a phase tracking reference signal (PTRS), etc., may be transmitted.

[0443] The synchronization signal may be, for example, at least one of a Primary Synchronization Signal (PSS) and a Secondary Synchronization Signal (SSS). A signal block including SS (PSS, SSS) and PBCH (and DMRS for PBCH) may be called an SS / PBCH block, SS Block (SSB), etc. SS, SSB, etc., may also be called reference signals.

[0444] Furthermore, in the wireless communication system 1, the Uplink Reference Signal (UL-RS) may transmit the Sounding Reference Signal (SRS), Demodulation Reference Signal (DMRS), etc. The DMRS may also be called the User-Specific Reference Signal (UE-specific Reference Signal).

[0445] (base station) Figure 44 shows an example of the configuration of a base station according to one embodiment. The base station 10 includes a control unit 110, a transceiver unit 120, a transceiver antenna 130, and a transmission line interface 140. Note that one or more of the control unit 110, transceiver unit 120, transceiver antenna 130, and transmission line interface 140 may be provided.

[0446] In this example, the functional blocks of the characteristic parts of this embodiment are mainly shown, and it may be assumed that the base station 10 also has other functional blocks necessary for wireless communication. Some of the processing of each part described below may be omitted.

[0447] The control unit 110 controls the entire base station 10. The control unit 110 can be composed of a controller, control circuit, etc., as described based on common understanding in the art relating to this disclosure.

[0448] The control unit 110 may control signal generation, scheduling (e.g., resource allocation, mapping), etc. The control unit 110 may also control transmission and reception, measurement, etc., using the transceiver unit 120, the transceiver antenna 130, and the transmission path interface 140. The control unit 110 may generate data to be transmitted as signals, control information, sequences, etc., and transfer them to the transceiver unit 120. The control unit 110 may also perform call processing of communication channels (setting, releasing, etc.), status management of the base station 10, management of radio resources, etc.

[0449] The transmitting / receiving unit 120 may include a baseband unit 121, a radio frequency (RF) unit 122, and a measurement unit 123. The baseband unit 121 may include a transmission processing unit 1211 and a reception processing unit 1212. The transmitting / receiving unit 120 can be composed of a transmitter / receiver, RF circuit, baseband circuit, filter, phase shifter, measurement circuit, transmitting / receiving circuit, etc., as described based on common understanding in the art relating to this disclosure.

[0450] The transmitting / receiving unit 120 may be configured as an integrated transmitting / receiving unit, or it may be composed of a transmitting unit and a receiving unit. The transmitting unit may consist of a transmitting processing unit 1211 and an RF unit 122. The receiving unit may consist of a receiving processing unit 1212, an RF unit 122 and a measuring unit 123.

[0451] The transmitting and receiving antenna 130 can be composed of an antenna described based on common understanding in the art relating to this disclosure, such as an array antenna.

[0452] The transmitting / receiving unit 120 may transmit the downlink channel, synchronization signal, downlink reference signal, etc. The transmitting / receiving unit 120 may also receive the uplink channel, uplink reference signal, etc.

[0453] The transmitting / receiving unit 120 may form at least one of the transmitting beam and the receiving beam using digital beamforming (e.g., precoding), analog beamforming (e.g., phase rotation), or the like.

[0454] The transmitting / receiving unit 120 (transmission processing unit 1211) may perform processing on data and control information acquired from the control unit 110, for example, at the Packet Data Convergence Protocol (PDCP) layer, the Radio Link Control (RLC) layer (e.g., RLC retransmission control), the Medium Access Control (MAC) layer (e.g., HARQ retransmission control), etc., to generate a bit sequence to be transmitted.

[0455] The transmitting / receiving unit 120 (transmission processing unit 1211) may perform transmission processing on the bit sequence to be transmitted, such as channel coding (which may include error correction coding), modulation, mapping, filtering, discrete Fourier transform (DFT) processing (if necessary), inverse fast Fourier transform (IFFT) processing, precoding, and digital-to-analog conversion, and output a baseband signal.

[0456] The transmitting / receiving unit 120 (RF unit 122) may perform modulation, filtering, amplification, etc., of the baseband signal to the radio frequency band and transmit the signal in the radio frequency band via the transmitting / receiving antenna 130.

[0457] On the other hand, the transmitting / receiving unit 120 (RF unit 122) may perform amplification, filtering, demodulation to a baseband signal, etc., on the radio frequency band signal received by the transmitting / receiving antenna 130.

[0458] The transmitting / receiving unit 120 (receiving processing unit 1212) may apply reception processing to the acquired baseband signal, such as analog-to-digital conversion, Fast Fourier Transform (FFT) processing, Inverse Discrete Fourier Transform (IDFT) processing (if necessary), filtering, demapping, demodulation, decoding (may include error correction decoding), MAC layer processing, RLC layer processing, and PDCP layer processing, to acquire user data, etc.

[0459] The transmitting / receiving unit 120 (measurement unit 123) may perform measurements related to the received signal. For example, the measurement unit 123 may perform Radio Resource Management (RRM) measurements, Channel State Information (CSI) measurements, etc., based on the received signal. The measurement unit 123 may also measure received power (e.g., Reference Signal Received Power (RSRP)), reception quality (e.g., Reference Signal Received Quality (RSRQ), Signal to Interference plus Noise Ratio (SINR), Signal to Noise Ratio (SNR)), signal strength (e.g., Received Signal Strength Indicator (RSSI)), propagation path information (e.g., CSI), etc. The measurement results may be output to the control unit 110.

[0460] The transmission path interface 140 may send and receive signals (backhaul signaling) with devices included in the core network 30, other base stations 10, etc., and may acquire and transmit user data (user plane data), control plane data, etc. for the user terminal 20.

[0461] In this disclosure, the transmitting and receiving units of the base station 10 may consist of at least one of a transmitting / receiving unit 120, a transmitting / receiving antenna 130, and a transmission path interface 140.

[0462] The transmitting / receiving unit 120 may receive one or more repetitions of a physical random access channel that have been transmitted using multiple different beams. The control unit 110 may determine a pseudo-collocation assumption for receiving one or more responses corresponding to each of the one or more repetitions.

[0463] The transmitting / receiving unit 120 may receive one or more repetitions of a physical random access channel transmitted using multiple different beams. The control unit 110 may control at least one of the downlink beam, the uplink beam, and the random access contention resolution timer based on the one or more repetitions.

[0464] (User terminal) Figure 45 shows an example of the configuration of a user terminal according to one embodiment. The user terminal 20 includes a control unit 210, a transmitting / receiving unit 220, and a transmitting / receiving antenna 230. Note that one or more of the control unit 210, the transmitting / receiving unit 220, and the transmitting / receiving antenna 230 may be provided.

[0465] In this example, the functional blocks of the characteristic parts of this embodiment are mainly shown, and it may be assumed that the user terminal 20 also has other functional blocks necessary for wireless communication. Some of the processing of each part described below may be omitted.

[0466] The control unit 210 controls the entire user terminal 20. The control unit 210 can be composed of a controller, control circuit, etc., as described based on common understanding in the technical field related to this disclosure.

[0467] The control unit 210 may control signal generation, mapping, etc. The control unit 210 may also control transmission and reception, measurement, etc., using the transmitting / receiving unit 220 and the transmitting / receiving antenna 230. The control unit 210 may generate data to be transmitted as signals, control information, sequences, etc., and transfer them to the transmitting / receiving unit 220.

[0468] The transmitting / receiving unit 220 may include a baseband unit 221, an RF unit 222, and a measurement unit 223. The baseband unit 221 may include a transmission processing unit 2211 and a reception processing unit 2212. The transmitting / receiving unit 220 can be composed of a transmitter / receiver, RF circuit, baseband circuit, filter, phase shifter, measurement circuit, transmitting / receiving circuit, etc., as described based on common understanding in the art relating to this disclosure.

[0469] The transmitting / receiving unit 220 may be configured as an integrated transmitting / receiving unit, or it may be composed of a transmitting unit and a receiving unit. The transmitting unit may consist of a transmitting processing unit 2211 and an RF unit 222. The receiving unit may consist of a receiving processing unit 2212, an RF unit 222 and a measuring unit 223.

[0470] The transmitting and receiving antenna 230 can be composed of an antenna described based on common understanding in the art relating to this disclosure, such as an array antenna.

[0471] The transmitting / receiving unit 220 may receive the downlink channel, synchronization signal, downlink reference signal, etc. The transmitting / receiving unit 220 may also transmit the uplink channel, uplink reference signal, etc.

[0472] The transmitting / receiving unit 220 may form at least one of the transmitting beam and the receiving beam using digital beamforming (e.g., precoding), analog beamforming (e.g., phase rotation), or the like.

[0473] The transmitting / receiving unit 220 (transmission processing unit 2211) may perform PDCP layer processing, RLC layer processing (e.g., RLC retransmission control), MAC layer processing (e.g., HARQ retransmission control), etc., on data and control information acquired from the control unit 210, etc., to generate a bit sequence to be transmitted.

[0474] The transmitting / receiving unit 220 (transmission processing unit 2211) may perform transmission processing on the bit sequence to be transmitted, such as channel coding (which may include error correction coding), modulation, mapping, filtering, DFT processing (if necessary), IFFT processing, precoding, and digital-to-analog conversion, and output a baseband signal.

[0475] Whether or not to apply DFT processing may be based on the transform precoding settings. The transmitting / receiving unit 220 (transmission processing unit 2211) may perform DFT processing as part of the transmission process to transmit a channel (for example, PUSCH) using a DFT-s-OFDM waveform if transform precoding is enabled for that channel, or it may not perform DFT processing as part of the transmission process if transform precoding is not enabled for that channel.

[0476] The transmitting / receiving unit 220 (RF unit 222) may perform modulation, filtering, amplification, etc., of the baseband signal to the radio frequency band and transmit the signal in the radio frequency band via the transmitting / receiving antenna 230.

[0477] On the other hand, the transmitting / receiving unit 220 (RF unit 222) may perform amplification, filtering, demodulation to a baseband signal, etc., on the radio frequency band signal received by the transmitting / receiving antenna 230.

[0478] The transmitting / receiving unit 220 (receiving processing unit 2212) may apply reception processing such as analog-to-digital conversion, FFT processing, IDFT processing (if necessary), filtering, demapping, demodulation, decoding (may include error correction decoding), MAC layer processing, RLC layer processing, and PDCP layer processing to the acquired baseband signal to acquire user data, etc.

[0479] The transmitting / receiving unit 220 (measuring unit 223) may perform measurements related to the received signal. For example, the measuring unit 223 may perform RRM measurement, CSI measurement, etc., based on the received signal. The measuring unit 223 may also measure received power (e.g., RSRP), received quality (e.g., RSRQ, SINR, SNR), signal strength (e.g., RSSI), propagation path information (e.g., CSI), etc. The measurement results may be output to the control unit 210.

[0480] In this disclosure, the transmitting and receiving units of the user terminal 20 may consist of at least one of a transmitting / receiving unit 220 and a transmitting / receiving antenna 230.

[0481] The transmitting / receiving unit 220 may transmit one or more repetitions of a physical random access channel using multiple different beams. The control unit 210 may determine pseudo-collocation assumptions for receiving one or more responses corresponding to each of the one or more repetitions.

[0482] The control unit 210 may control the transmission of one or more physical uplink sharing channels based on the one or more responses.

[0483] The values ​​of one or more specific fields within each response may be the same between the one or more responses.

[0484] The values ​​of the parameters used for transmission on each physical uplink sharing channel may be the same among the one or more physical uplink sharing channels.

[0485] The transmitting / receiving unit 220 may transmit one or more repetitions of a physical random access channel using multiple different beams. The control unit 210 may control at least one of the downlink beam, the uplink beam, and the random access contention resolution timer based on the one or more repetitions.

[0486] The control unit may determine the downlink beam. The downlink beam may be associated with a resource in one of the plurality of repetitions, or may be reported using one or more physical uplink sharing channels corresponding to one or more of the repetitions.

[0487] The control unit 210 may determine the uplink beam based on the physical downlink sharing channel transmitted in accordance with the physical uplink sharing channel corresponding to one of the plurality of repetitions.

[0488] The control unit 210 may start a random access contention resolution timer after the completion of transmission on one or more physical uplink sharing channels corresponding to one or more repetitions.

[0489] (Hardware configuration) The block diagrams used in the description of the above embodiments show functional units. These functional blocks (components) are realized by any combination of at least one of hardware and software. Furthermore, the method of realizing each functional block is not particularly limited. That is, each functional block may be realized using one device that is physically or logically coupled, or it may be realized using two or more physically or logically separated devices that are directly or indirectly connected (for example, using wired or wireless connections). A functional block may also be realized by combining the above one device or the above multiple devices with software.

[0490] Here, functions include, but are not limited to, judgment, decision, determination, calculation, calculation, processing, derivation, investigation, search, confirmation, reception, transmission, output, access, resolution, selection, selection, establishment, comparison, assumption, expectation, consideration, broadcasting, notifying, communicating, forwarding, configuring, reconfiguring, allocating (mapping), and assigning. For example, a functional block (configuration part) that enables transmission may be called a transmitting unit or transmitter. In all cases, as mentioned above, the method of implementation is not particularly limited.

[0491] For example, a base station, user terminal, etc. in one embodiment of the present disclosure may function as a computer that processes the wireless communication method of the present disclosure. Figure 46 is a diagram showing an example of the hardware configuration of a base station and user terminal according to one embodiment. The base station 10 and user terminal 20 described above may be physically configured as a computer device including a processor 1001, memory 1002, storage 1003, communication device 1004, input device 1005, output device 1006, bus 1007, etc.

[0492] In this disclosure, terms such as apparatus, circuit, device, section, and unit are interchangeable. The hardware configuration of the base station 10 and the user terminal 20 may include one or more of the devices shown in the figure, or it may be configured to omit some of the devices.

[0493] For example, although only one processor 1001 is shown in the diagram, there may be multiple processors. Furthermore, processing may be performed by one processor, or by two or more processors simultaneously, sequentially, or by other means. Note that processor 1001 may be implemented using one or more chips.

[0494] Each function in the base station 10 and the user terminal 20 is realized, for example, by loading predetermined software (programs) onto hardware such as the processor 1001 and memory 1002, which allows the processor 1001 to perform calculations and control communication via the communication device 1004, or to control at least one of the reading and writing of data in the memory 1002 and storage 1003.

[0495] The processor 1001 controls the entire computer, for example, by running an operating system. The processor 1001 may be composed of a central processing unit (CPU) that includes interfaces with peripheral devices, control units, arithmetic units, registers, etc. For example, at least a part of the control unit 110 (210) and the transmitting / receiving unit 120 (220) described above may be implemented by the processor 1001.

[0496] Furthermore, the processor 1001 reads programs (program code), software modules, data, etc., from at least one of the storage 1003 and the communication device 1004 into the memory 1002 and executes various processes accordingly. The program used is one that causes the computer to execute at least a part of the operations described in the above embodiment. For example, the control unit 110 (210) may be implemented by a control program stored in the memory 1002 and running on the processor 1001, and other functional blocks may be implemented similarly.

[0497] Memory 1002 is a computer-readable recording medium and may consist of at least one of the following: Read Only Memory (ROM), Erasable Programmable ROM (EPROM), Electrically EPROM (EEPROM), Random Access Memory (RAM), or other suitable storage medium. Memory 1002 may also be called a register, cache, or main memory. Memory 1002 can store executable programs (program code), software modules, etc., for carrying out a wireless communication method according to one embodiment of this disclosure.

[0498] Storage 1003 is a computer-readable recording medium and may consist of at least one of the following: a flexible disk, a floppy disk, a magneto-optical disk (e.g., a compact disk (Compact Disc ROM (CD-ROM)), a digital multipurpose disk, a Blu-ray disk), a removable disk, a hard disk drive, a smart card, a flash memory device (e.g., a card, stick, key drive), a magnetic stripe, a database, a server, or other suitable storage medium. Storage 1003 may also be called an auxiliary storage device.

[0499] The communication device 1004 is hardware (transmitting / receiving device) for communicating between computers via at least one of a wired network and a wireless network, and is also referred to as a network device, network controller, network card, communication module, etc. The communication device 1004 may be configured to include, for example, a high-frequency switch, duplexer, filter, frequency synthesizer, etc., in order to implement at least one of frequency division duplex (FDD) and time division duplex (TDD). For example, the above-mentioned transmitting / receiving unit 120 (220), transmitting / receiving antenna 130 (230), etc., may be implemented by the communication device 1004. The transmitting / receiving unit 120 (220) may be implemented with physically or logically separated implementations of a transmitting unit 120a (220a) and a receiving unit 120b (220b).

[0500] The input device 1005 is an input device that accepts input from an external source (e.g., a keyboard, mouse, microphone, switch, button, sensor, etc.). The output device 1006 is an output device that outputs to an external source (e.g., a display, speaker, light-emitting diode (LED) lamp, etc.). The input device 1005 and the output device 1006 may be configured as an integrated unit (e.g., a touch panel).

[0501] Furthermore, each device, such as the processor 1001 and memory 1002, is connected by a bus 1007 for communicating information. The bus 1007 may be configured using a single bus, or different buses may be configured for each device.

[0502] Furthermore, the base station 10 and the user terminal 20 may be configured to include hardware such as a microprocessor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a programmable logic device (PLD), and a field programmable gate array (FPGA), and some or all of each functional block may be implemented using such hardware. For example, the processor 1001 may be implemented using at least one of these hardware components.

[0503] (modified version) In addition, terms used in this disclosure and terms necessary for understanding this disclosure may be replaced with terms having the same or similar meanings. For example, channel, symbol, and signal (signal or signaling) may be used interchangeably. Also, a signal may be a message. A reference signal may be abbreviated as RS and may be called a pilot, pilot signal, etc., depending on the applicable standard. Also, a component carrier (CC) may be called a cell, frequency carrier, carrier frequency, etc.

[0504] A wireless frame may consist of one or more periods (frames) in the time domain. Each of these periods (frames) constituting a wireless frame may be called a subframe. Furthermore, a subframe may consist of one or more slots in the time domain. A subframe may have a fixed time length (e.g., 1 ms) that is independent of numerology.

[0505] Here, the neuralelogy may be communication parameters applied to at least one of the transmission and reception of a signal or channel. The neuralelogy may be, for example, at least one of the following: subcarrier spacing (SCS), bandwidth, symbol length, cyclic prefix length, transmission time interval (TTI), number of symbols per TTI, radio frame configuration, specific filtering processes performed by the transceiver in the frequency domain, or specific windowing processes performed by the transceiver in the time domain.

[0506] A slot may consist of one or more symbols in the time domain (such as Orthogonal Frequency Division Multiplexing (OFDM) symbols or Single Carrier Frequency Division Multiple Access (SC-FDMA) symbols). Alternatively, a slot may be a time unit based on neurology.

[0507] A slot may include multiple mini-slots. Each mini-slot may consist of one or more symbols in the time domain. Mini-slots may also be called sub-slots. Mini-slots may consist of fewer symbols than a slot. A PDSCH (or PUSCH) transmitted in a time unit larger than a mini-slot may be called a PDSCH (PUSCH) mapping type A. A PDSCH (or PUSCH) transmitted using a mini-slot may be called a PDSCH (PUSCH) mapping type B.

[0508] Wireless frames, subframes, slots, minislots, and symbols all represent units of time when transmitting a signal. Wireless frames, subframes, slots, minislots, and symbols may each be referred to by different names. Furthermore, the units of time such as frames, subframes, slots, minislots, and symbols in this disclosure may be interpreted as interchangeable.

[0509] For example, one subframe may be called TTI, multiple consecutive subframes may be called TTI, or one slot or one mini-slot may be called TTI. In other words, at least one of the subframe and TTI may be a subframe (1ms) in existing LTE, a period shorter than 1ms (e.g., 1-13 symbols), or a period longer than 1ms. Note that the unit representing TTI may be called a slot, mini-slot, etc., instead of a subframe.

[0510] Here, TTI refers to, for example, the smallest unit of time for scheduling in wireless communication. For example, in an LTE system, the base station schedules each user terminal to allocate wireless resources (such as the frequency bandwidth and transmission power available to each user terminal) in TTI units. However, the definition of TTI is not limited to this.

[0511] TTI may be a transmission time unit for channel-encoded data packets (transport blocks), code blocks, code words, etc., or it may be a processing unit for scheduling, link adaptation, etc. Given a TTI, the actual time interval (e.g., number of symbols) to which the transport block, code block, code word, etc. are mapped may be shorter than the given TTI.

[0512] Furthermore, if one slot or one mini-slot is referred to as TTI, then one or more TTIs (i.e., one or more slots or one or more mini-slots) may constitute the minimum time unit of scheduling. In addition, the number of slots (number of mini-slots) that constitute the minimum time unit of scheduling may be controlled.

[0513] A TTI with a time length of 1 ms may also be called a normal TTI (TTI in 3GPP Rel.8-12), a long TTI, a normal subframe, a long subframe, or a slot. A TTI shorter than a normal TTI may also be called a shortened TTI, a short TTI, a partial or fractional TTI, a shortened subframe, a short subframe, a mini slot, a sub slot, or a slot.

[0514] Furthermore, long TTIs (e.g., normal TTIs, subframes, etc.) may be interpreted as TTIs with a time length exceeding 1 ms, and short TTIs (e.g., shortened TTIs, etc.) may be interpreted as TTIs with a TTI length less than that of a long TTI but 1 ms or more.

[0515] A Resource Block (RB) is a resource allocation unit in the time domain and frequency domain, and in the frequency domain, it may contain one or more consecutive subcarriers. The number of subcarriers in an RB may be the same regardless of the neurology, for example, 12. The number of subcarriers in an RB may be determined based on the neurology.

[0516] Furthermore, an RB may contain one or more symbols in the time domain and may have the length of one slot, one minislot, one subframe, or one TTI. Each TTI, subframe, etc., may consist of one or more resource blocks.

[0517] One or more RBs may also be called Physical RBs (PRBs), Sub-Carrier Groups (SCGs), Resource Element Groups (REGs), PRB pairs, RB pairs, etc.

[0518] Furthermore, a resource block may consist of one or more resource elements (REs). For example, one RE may be a radio resource area comprising one subcarrier and one symbol.

[0519] A Bandwidth Part (BWP) (also called a partial bandwidth) may represent a subset of consecutive common resource blocks (RBs) for a given neurology in a given carrier. Here, the common RBs may be identified by an index of the RBs relative to the carrier's common reference point. PRBs may be defined and numbered within a BWP.

[0520] A BWP may include UL BWPs (BWPs for UL) and DL BWPs (BWPs for DL). One or more BWPs may be configured within a single carrier for a UE.

[0521] At least one of the configured BWPs may be active, and the UE does not need to assume that it will send or receive a given signal / channel outside of the active BWP. In this disclosure, terms such as "cell" and "carrier" may be read as "BWP".

[0522] The structures described above, such as wireless frames, subframes, slots, minislots, and symbols, are merely illustrative examples. For instance, the number of subframes included in a wireless frame, the number of slots per subframe or wireless frame, the number of minislots within a slot, the number of symbols and RBs included in a slot or minislot, the number of subcarriers included in an RB, and the number of symbols, symbol length, and cyclic prefix (CP) length within a TTI can be varied in various ways.

[0523] Furthermore, the information, parameters, etc., described in this disclosure may be expressed using absolute values, relative values ​​from a predetermined value, or corresponding other information. For example, wireless resources may be indicated by a predetermined index.

[0524] The names used for parameters and other elements in this disclosure are not restrictive in any way. Furthermore, mathematical formulas and other elements that use these parameters may differ from those expressly disclosed in this disclosure. Various channels (PUCCH, PDCCH, etc.) and information elements can be identified by any suitable name, and therefore, the various names assigned to these various channels and information elements are not restrictive in any way.

[0525] The information, signals, etc. described in this disclosure may be represented using any of the various different techniques. For example, the data, instructions, commands, information, signals, bits, symbols, chips, etc. that may be referred to throughout the above description may be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, optical fields or photons, or any combination thereof.

[0526] Furthermore, information, signals, etc., can be output from upper layers to lower layers and from lower layers to upper layers, or to at least one of the two. Information, signals, etc., may also be input and output via multiple network nodes.

[0527] Input and output information and signals may be stored in a specific location (e.g., memory) or managed using a management table. Input and output information and signals may be overwritten, updated, or appended to. Output information and signals may be deleted. Input information and signals may be transmitted to other devices.

[0528] Information notification is not limited to the embodiments described herein and may be carried out by other means. For example, information notification in this disclosure may be carried out by physical layer signaling (e.g., Downlink Control Information (DCI), Uplink Control Information (UCI)), higher layer signaling (e.g., Radio Resource Control (RRC) signaling, broadcast information (Master Information Block (MIB), System Information Block (SIB)), Medium Access Control (MAC) signaling), other signals, or a combination thereof).

[0529] Physical layer signaling may also be called Layer 1 / Layer 2 (L1 / L2) control information (L1 / L2 control signals), L1 control information (L1 control signals), etc. RRC signaling may also be called RRC messages, for example, RRC Connection Setup messages, RRC Connection Reconfiguration messages, etc. MAC signaling may also be communicated using, for example, MAC Control Element (CE).

[0530] Furthermore, notification of the specified information (for example, notification that "X is the case") is not limited to explicit notification, but may also be made implicitly (for example, by not notifying the specified information or by notifying other information).

[0531] The determination may be made by a value represented by 1 bit (0 or 1), by a boolean value represented as true or false, or by a numerical comparison (for example, a comparison with a predetermined value).

[0532] Software should be broadly interpreted to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, execution threads, procedures, functions, and so on, whether they are called software, firmware, middleware, microcode, hardware description languages, or by any other name.

[0533] Furthermore, software, instructions, information, etc., may be transmitted and received via a transmission medium. For example, if software is transmitted from a website, server, or other remote source using at least one of wired technology (such as coaxial cable, fiber optic cable, twisted pair, or Digital Subscriber Line (DSL)) and wireless technology (such as infrared or microwave), then at least one of these wired and wireless technologies is included in the definition of a transmission medium.

[0534] The terms “system” and “network” as used in this disclosure may be used interchangeably. “Network” may also mean the equipment included in the network (e.g., base stations).

[0535] In this disclosure, terms such as "precoding," "precoder," "weight (precoding weight)," "quasi-co-location (QCL)," "transmission configuration indication state (TCI state)," "spatial relation," "spatial domain filter," "transmit power," "phase rotation," "antenna port," "antenna port group," "layer," "number of layers," "rank," "resource," "resource set," "resource group," "beam," "beam width," "beam angle," "antenna," "antenna element," and "panel" may be used interchangeably.

[0536] In this disclosure, terms such as "Base Station (BS)", "wireless base station", "fixed station", "NodeB", "eNB (eNodeB)", "gNB (gNodeB)", "access point", "Transmission Point (TP)", "Reception Point (RP)", "Transmission / Reception Point (TRP)", "panel", "cell", "sector", "cell group", "carrier", and "component carrier" may be used interchangeably. Base stations may also be referred to by terms such as macrocell, small cell, femtocell, and picocell.

[0537] A base station can house one or more (e.g., three) cells. If a base station houses multiple cells, the entire coverage area of ​​the base station can be divided into several smaller areas, each of which may also be provided with communication services by a base station subsystem (e.g., a small indoor base station (Remote Radio Head (RRH))). The terms “cell” or “sector” refer to part or all of the coverage area of ​​at least one of the base station and / or base station subsystems that provide communication services in that coverage.

[0538] In this disclosure, terms such as "Mobile Station (MS)," "user terminal," "User Equipment (UE)," and "terminal" may be used interchangeably.

[0539] A mobile station may also be called a subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, handset, user agent, mobile client, client, or some other appropriate term.

[0540] At least one of the base station and the mobile station may be called a transmitting device, a receiving device, a wireless communication device, etc. At least one of the base station and the mobile station may also be a device mounted on a moving object, the moving object itself, etc.

[0541] The term "mobile object" refers to any movable object, regardless of its speed, and naturally includes cases where the mobile object is stationary. Examples of such mobile objects include, but are not limited to, vehicles, transport vehicles, automobiles, motorcycles, bicycles, connected cars, excavators, bulldozers, wheel loaders, dump trucks, forklifts, trains, buses, handcarts, rickshaws, ships and other watercraft, airplanes, rockets, satellites, drones, multicopters, quadcopters, balloons, and items carried on them. Furthermore, such mobile objects may be autonomously driven objects operating based on operational commands.

[0542] The mobile entity may be a vehicle (e.g., a car, an airplane), an unmanned mobile entity (e.g., a drone, an autonomous vehicle), or a robot (manned or unmanned). At least one of the base station and the mobile station may be a device that does not necessarily move during communication operations. For example, at least one of the base station and the mobile station may be an Internet of Things (IoT) device such as a sensor.

[0543] Figure 47 shows an example of a vehicle according to one embodiment. The vehicle 40 includes a drive unit 41, a steering unit 42, an accelerator pedal 43, a brake pedal 44, a shift lever 45, left and right front wheels 46, left and right rear wheels 47, an axle 48, an electronic control unit 49, various sensors (including a current sensor 50, a rotation speed sensor 51, a pneumatic pressure sensor 52, a vehicle speed sensor 53, an acceleration sensor 54, an accelerator pedal sensor 55, a brake pedal sensor 56, a shift lever sensor 57, and an object detection sensor 58), an information service unit 59, and a communication module 60.

[0544] The drive unit 41 consists of, for example, at least one of an engine, a motor, or an engine-motor hybrid. The steering unit 42 includes at least a steering wheel (also called a handle) and is configured to steer at least one of the front wheels 46 and the rear wheels 47 based on the operation of the steering wheel operated by the user.

[0545] The electronic control unit 49 consists of a microprocessor 61, memory (ROM, RAM) 62, and communication ports (e.g., input / output (IO) ports) 63. Signals from various sensors 50-58 installed in the vehicle are input to the electronic control unit 49. The electronic control unit 49 may also be called an Electronic Control Unit (ECU).

[0546] Signals from various sensors 50-58 include current signals from current sensor 50 for sensing motor current, rotational speed signals of front wheels 46 / rear wheels 47 acquired by rotational speed sensor 51, air pressure signals of front wheels 46 / rear wheels 47 acquired by air pressure sensor 52, vehicle speed signals acquired by vehicle speed sensor 53, acceleration signals acquired by acceleration sensor 54, accelerator pedal depression signal of accelerator pedal 43 acquired by accelerator pedal sensor 55, brake pedal depression signal of brake pedal 44 acquired by brake pedal sensor 56, operation signals of shift lever 45 acquired by shift lever sensor 57, and detection signals for detecting obstacles, vehicles, pedestrians, etc., acquired by object detection sensor 58.

[0547] The information service unit 59 consists of various devices for providing (outputting) various types of information such as driving information, traffic information, and entertainment information, including a car navigation system, audio system, speakers, displays, television, and radio, and one or more ECUs that control these devices. The information service unit 59 uses information acquired from external devices via a communication module 60 or the like to provide various types of information / services (e.g., multimedia information / multimedia services) to the occupants of the vehicle 40.

[0548] The information service unit 59 may include input devices that accept input from the outside (e.g., keyboard, mouse, microphone, switch, button, sensor, touch panel, etc.) and output devices that perform output to the outside (e.g., display, speaker, LED lamp, touch panel, etc.).

[0549] The driver assistance system unit 64 consists of various devices that provide functions to prevent accidents or reduce the driver's workload, such as millimeter-wave radar, Light Detection and Ranging (LiDAR), cameras, positioning locators (e.g., Global Navigation Satellite System (GNSS)), map information (e.g., High Definition (HD) maps, Autonomous Vehicle (AV) maps), gyro systems (e.g., Inertial Measurement Unit (IMU), Inertial Navigation System (INS)), artificial intelligence (AI) chips, and AI processors, as well as one or more ECUs that control these devices. The driver assistance system unit 64 also transmits and receives various information via the communication module 60 to realize driver assistance functions or autonomous driving functions.

[0550] The communication module 60 can communicate with the microprocessor 61 and components of the vehicle 40 via the communication port 63. For example, the communication module 60 sends and receives data (information) via the communication port 63 to the drive unit 41, steering unit 42, accelerator pedal 43, brake pedal 44, shift lever 45, left and right front wheels 46, left and right rear wheels 47, axle 48, the microprocessor 61 and memory (ROM, RAM) 62 in the electronic control unit 49, and various sensors 50-58 provided in the vehicle 40.

[0551] The communication module 60 is a communication device that can be controlled by the microprocessor 61 of the electronic control unit 49 and can communicate with external devices. For example, it can send and receive various types of information to and from external devices via wireless communication. The communication module 60 may be located either inside or outside the electronic control unit 49. The external device may be, for example, the base station 10 or the user terminal 20 described above. Alternatively, the communication module 60 may be, for example, at least one of the base station 10 and the user terminal 20 (it may function as at least one of the base station 10 and the user terminal 20).

[0552] The communication module 60 may transmit at least one of the following to an external device via wireless communication: signals from the various sensors 50-58 input to the electronic control unit 49, information obtained based on said signals, and information based on input from an external source (user) obtained via the information service unit 59. The electronic control unit 49, the various sensors 50-58, the information service unit 59, etc., may also be called input units that accept input. For example, the PUSCH transmitted by the communication module 60 may include information based on the above input.

[0553] The communication module 60 receives various information (traffic information, signal information, inter-vehicle information, etc.) transmitted from an external device and displays it on the information service unit 59 installed in the vehicle. The information service unit 59 may also be called an output unit, which outputs information (for example, it outputs information to devices such as displays and speakers based on the PDSCH (or data / information decoded from the PDSCH) received by the communication module 60).

[0554] Furthermore, the communication module 60 stores various information received from external devices in a memory 62 that can be used by the microprocessor 61. Based on the information stored in the memory 62, the microprocessor 61 may control the drive unit 41, steering unit 42, accelerator pedal 43, brake pedal 44, shift lever 45, left and right front wheels 46, left and right rear wheels 47, axle 48, various sensors 50-58, etc., which are provided in the vehicle 40.

[0555] Furthermore, the term "base station" in this disclosure may be interpreted as "user terminal." For example, the various aspects / embodiments of this disclosure may be applied to a configuration in which communication between a base station and a user terminal is replaced with communication between multiple user terminals (which may be called, for example, Device-to-Device (D2D), Vehicle-to-Everything (V2X)). In this case, the user terminal 20 may have the functions that the base station 10 has. Also, terms such as "uplink" and "downlink" may be interpreted as terms corresponding to terminal-to-terminal communication (for example, "sidelink"). For example, uplink channel and downlink channel may be interpreted as sidelink channel.

[0556] Similarly, the term "user terminal" in this disclosure may be replaced with "base station." In this case, the base station 10 may be configured to have the same functions as the user terminal 20 described above.

[0557] In this disclosure, operations performed by a base station may, in some cases, be performed by its upper node. In a network including one or more network nodes with base stations, it is clear that various operations performed for communication with terminals may be performed by the base station, one or more network nodes other than the base station (for example, a Mobility Management Entity (MME), a Serving Gateway (S-GW), etc., but not limited to these), or a combination thereof.

[0558] Each aspect / embodiment described in this disclosure may be used individually, in combination, or switched between during execution. Furthermore, the processing procedures, sequences, flowcharts, etc., of each aspect / embodiment described in this disclosure may be rearranged in order, provided they are consistent. For example, the methods described in this disclosure present various step elements in an exemplary order and are not limited to that specific order.

[0559] Each aspect / embodiment described in this disclosure includes Long Term Evolution (LTE), LTE-Advanced (LTE-A), LTE-Beyond (LTE-B), SUPER 3G, IMT-Advanced, 4th generation mobile communication system (4G), 5th generation mobile communication system (5G), 6th generation mobile communication system (6G), xth generation mobile communication system (xG (where x is, for example, an integer or decimal)), Future Radio Access (FRA), New-Radio Access Technology (RAT), New Radio (NR), New radio access (NX), Future generation radio access (FX), Global System for Mobile communications (GSM®), CDMA2000, Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi®), IEEE 802.16 (WiMAX®), and IEEE This may apply to systems utilizing 802.20, Ultra-WideBand (UWB), Bluetooth®, or other appropriate wireless communication methods, as well as next-generation systems that are extended, modified, created, or defined based on these. It may also apply to combinations of multiple systems (e.g., a combination of LTE or LTE-A and 5G).

[0560] In this disclosure, the phrase "based on" does not mean "based solely on" unless otherwise specified. In other words, the phrase "based on" means both "based solely on" and "based at least on."

[0561] Any reference to elements using the designations “first,” “second,” etc., as used in this disclosure does not generally limit the quantity or order of those elements. These designations may be used in this disclosure as a convenient way to distinguish between two or more elements. Accordingly, the references to the first and second elements do not imply that only two elements may be employed or that the first element must precede the second element in any way.

[0562] The term “determining” as used in this disclosure may encompass a wide variety of actions. For example, “determining” may be considered to include judging, calculating, computing, processing, deriving, investigating, looking up, searching, inquiry (e.g., searching in tables, databases, or other data structures), ascertaining, etc.

[0563] Furthermore, "judgment (decision)" may be considered as "judging (deciding)" things like receiving (e.g., receiving information), transmitting (e.g., sending information), input, output, accessing (e.g., accessing data in memory).

[0564] Furthermore, "judgment (decision)" can be considered as "judging (deciding)" something like resolving, selecting, choosing, establishing, comparing, etc. In other words, "judgment (decision)" can be considered as "judging (deciding)" something about an action.

[0565] Furthermore, "judgment (decision)" can be replaced with "assuming," "expecting," or "considering."

[0566] The term "maximum transmit power" as used in this disclosure may mean the maximum transmit power, the nominal UE maximum transmit power, or the rated UE maximum transmit power.

[0567] As used in this disclosure, the terms “connected,” “coupled,” and any variations thereof mean any direct or indirect connection or coupling between two or more elements, and may include one or more intermediate elements between two elements that are “connected” or “coupled” with each other. The coupling or connection between elements may be physical, logical, or a combination thereof. For example, “connection” may be replaced with “access.”

[0568] In this disclosure, when two elements are connected, they can be considered to be “connected” or “coupled” to each other using one or more wires, cables, printed electrical connections, etc., and, in some non-exclusive and non-exclusive examples, electromagnetic energy having wavelengths in the radio frequency domain, microwave domain, or optical domain (both visible and invisible).

[0569] In this disclosure, the term "A and B are different" may mean "A and B are different from each other." The term may also mean "A and B are each different from C." Terms such as "separate" and "combine" may be interpreted similarly to "different."

[0570] Where the terms “include,” “including,” and variations thereof are used in this disclosure, these terms are intended to be inclusive, as is the term “comprising.” Furthermore, the term “or” as used in this disclosure is not intended to mean exclusive OR.

[0571] In this disclosure, if articles are added by translation, such as a, an, and the in English, this disclosure may include the fact that the noun following these articles is plural.

[0572] Although the invention described herein has been explained in detail above, it will be clear to those skilled in the art that the invention described herein is not limited to the embodiments described herein. The invention described herein can be implemented in modified and altered forms without departing from the spirit and scope of the invention as defined by the claims. Therefore, the descriptions herein are for illustrative purposes only and do not imply any limitation on the invention described herein.

Claims

1. A transmitting unit that uses each of the aforementioned different beams to transmit one or more repetitions of a physical random access channel (PRACH) from among multiple repetitions, The system includes a control unit that controls the reception of a response to the PRACH in a downlink beam having the same spatial relationship as each of the multiple different beams used in the one or more repeated transmissions, The aforementioned spatial relationship is a terminal that overlaps in the time domain by at least a portion.

2. The steps include transmitting one or more repetitions of a physical random access channel (PRACH) using each of the aforementioned different beams, The step of controlling the reception of a response to the PRACH in a downlink beam having the same spatial relationship as each of the multiple different beams used in the one or more repeated transmissions, The aforementioned spatial relationship overlaps in the time domain at least partially, in a wireless communication method for terminals.

3. A receiving unit that receives one or more repetitions of a plurality of repetitions of a physical random access channel (PRACH) transmitted using the plurality of different beams, The system includes a control unit that controls the transmission of a response to the PRACH in each of the multiple different beams used for the one or more repeated transmissions, each having the same spatial relationship as the downlink beam. The aforementioned spatial relationship overlaps with the base station in the time domain, at least in part.

4. A system comprising the terminal described in claim 1 and a base station, The base station is a system having a receiving unit that receives one or more repetitions.

Images