Patent Description:
Fifth generation (<NUM>) wireless systems are the next telecommunications standards beyond fourth generation (<NUM>) standards. <NUM> generally aims at higher capacity than <NUM>, allowing a higher density of mobile broadband users, greater reliability, and supporting device-to-device and massive machine communications. Based on general requirements set out by International Telecommunication Union Radio communication (ITU-R), Next Generation Mobile Networks (NGMN) and <NUM>rd Generation Partnership Project (3GPP), a broad classification of use cases for <NUM> systems may include enhanced mobile broadband (eMBB), massive machine type communications (mMTC), and ultra-reliable and low latency communications (URLLC). These use cases may focus on different requirements such as high data rate, high spectrum efficiency, low power and high energy efficiency, low latency, and high reliability. A wide range of spectrum bands ranging from <NUM> to <NUM> may be considered for a variety of these deployment scenarios.

As carrier frequencies increase, severe path loss may become a crucial limitation to guarantee the sufficient coverage of wireless devices. For example, transmission in millimeter wave systems may suffer from non-line-of-sight losses such as diffraction loss, penetration loss, oxygen absorption loss, foliage loss, and the like. During initial access, a base station (BS) and a wireless transmit receive unit (WTRU) may need to overcome these high path losses and discover each other. Utilizing dozens or even hundreds of antenna elements to generate beam-formed signals in <NUM> wireless systems is an effective way to compensate the severe path loss by providing significant beam forming gain. However, these beam-formed signals may collide with each other during initial access or random access procedures. For example, synchronization signal (SS) blocks, random access channel (RACH) resources, control channels (DL/UL) and/or data channel (DL/UL) may collide with each other in <NUM> scenarios.

3GPP contribution document R1-<NUM> discusses details regarding NR-RACH formats and configurations. such as PRACH preamble formats.

Methods, systems, and devices for addressing collisions of possible random access channel (RACH) occasions. A wireless transmit receive unit (WTRU) may receive an indication of semi-static UL/DL information including configuration of RACH occasions in a remaining minimum system information (RMSI) via a PBCH and an indication of one or more actually transmitted synchronization signal (SS) blocks. The WTRU may then assess whether there are RACH occasions based on the configuration information and determine whether any of the RACH occasions are valid, wherein the RACH occasion may be valid based on Based on the RACH occasion is after all actually transmitted SS blocks indicated and/or whether an SS block override is disabled or enabled. The WTRU may transmit a RACH in one or more of the RACH occasions that have been determined to be valid.

The WTRU <NUM> may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the uplink (UL) (e.g., for transmission) and downlink (DL) (e.g., for reception) may be concurrent and/or simultaneous. The full duplex radio may include an interference management unit <NUM> to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor <NUM>). In an embodiment, the WTRU <NUM> may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the DL (e.g., for reception)).

For example, the CN <NUM> may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN <NUM>, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional landline communications devices.

The CN <NUM> shown in <FIG> may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b.

A radio access network (RAN) may be part of a mobile telecommunication system providing wireless transmit receive units (WTRUs) with connection to its core network (CN). In fifth generation (<NUM>) or next generation (NG) wireless systems, the RAN may be referred to as New Radio (NR) RAN or next generation RAN. Based on the general requirements set out by ITU-R, NGMN and 3GPP, a broad classification of use cases for NR may be Enhanced Mobile Broadband (eMBB), Massive Machine Type Communications (mMTC), and Ultra Reliable and Low latency Communications (URLLC). Different use cases may focus on different requirements such as higher data rate, higher spectrum efficiency, low power and higher energy efficiency, lower latency, and higher reliability. A wide range of spectrum bands ranging from <NUM> to <NUM> may be considered for a variety of deployment scenarios.

As carrier frequency increases severe path loss may become a crucial limitation to guarantee sufficient coverage. Transmission in millimeter wave systems may additionally suffer from non-line-of-sight losses, for example, diffraction loss, penetration loss, Oxygen absorption loss, foliage loss, and the like. During initial access, a base station and a WTRU may need to overcome these high path losses and discover each other, or a WTRU may need to discover another WTRU. Utilizing dozens or even hundreds of antenna elements to generate a beam formed signal may be an effective way to compensate the severe path loss by providing significant beam forming gain. Beamforming techniques may include digital, analogue, and hybrid beamforming.

Long Term Evolution (LTE), and other wireless systems, may use initial synchronization and broadcast channels. Cell search may be used by a WTRU to acquire time and frequency synchronization within a cell and detect the Cell ID of that cell. Synchronization signals, such as LTE, may be transmitted in the 0th and 5th subframes of every radio frame and may be used for time and frequency synchronization during initialization. As part of the system acquisition process, a WTRU may synchronize sequentially to the OFDM symbol, slot, subframe, half-frame, and/or radio frame based on the synchronization signals. There may be two synchronization signals: a primary synchronization signal (PSS) and a secondary synchronization signal (SSS). The PSS may be used to obtain slot, subframe, and half-frame boundary. It may also provide physical layer cell identity (PCI) within the cell identity group. The SSS may be used to obtain the radio frame boundary. It may also enable the WTRU to determine the cell identity group, which may range from <NUM> to <NUM>.

Following a successful synchronization and PCI acquisition, the WTRU may decode a channel, such as a Physical Broadcast Channel (PBCH), with the help of cell-specific reference signals (CRS) and acquire the master information block (MIB) information regarding system bandwidth, System Frame Number (SFN) and PHICH configuration. LTE synchronization signals and PBCH may be transmitted continuously according to the standardized periodicity.

LTE, and other wireless systems, may utilize random access (RA) procedures. A base station (e.g., eNodeB, eNB, gNB) and/or a WTRU may use a random access procedure for at least one of: WTRU initial access (e.g., to a cell or eNB); reset of UL timing (e.g., to reset or align WTRU UL timing with respect to a certain cell); and/or reset of timing during handover (e.g., to reset or align WTRU timing with respect to the handover target cell). The WTRU may transmit a certain physical random access channel (PRACH) preamble sequence at a certain power PRACH, which may be based on configured parameters and/or measurements, and the WTRU may transmit the preamble using a certain time-frequency resource or resources. The configured parameters, which may be provided or configured by the eNB, may include one or more of an initial preamble power (e.g., preambleInitialReceivedTargetPower), a preamble format based offset (e.g., deltaPreamble), a random access response window (e.g., ra-ResponseWindowSize), a power ramping factor (e.g., powerRampingStep), and/or a maximum number of retransmissions (e.g., preambleTransMax). The PRACH resources, which may include preambles or sets of preambles and/or time/frequency resources that may be used for preamble transmission, may be provided or configured by the eNB. The measurements may include path loss. The time-frequency resource(s) may be chosen by the WTRU from an allowed set or may be chosen by the eNB and signaled to the WTRU. Following the WTRU transmission of a preamble, if the eNB detects the preamble, it may respond with a random access response (RAR). If the WTRU does not receive an RAR for the transmitted preamble (e.g., which may correspond to a certain preamble index and/or time/frequency resource), within an allotted time (e.g., ra-ResponseWindowSize), the WTRU may send another preamble at a later time, at a higher power, (e.g., higher than the previous preamble transmission by powerRampingStep) where the transmission power may be limited by a maximum power, for example a WTRU configured maximum power that may be for the WTRU as a whole (e.g., PCMAX) or for a certain serving cell of the WTRU (e.g., PCMAX,c). The WTRU may wait again for receipt of an RAR from the eNB. This sequence of transmitting and waiting may continue until the eNB may respond with an RAR or until the maximum number of random access preamble transmissions (e.g., preambleTransMax) may have been reached. The eNB may transmit and the WTRU may receive the RAR in response to a single preamble transmission.

A random access procedure may be contention-based or contention-free. A contention-free procedure may be initiated by a request, for example from an eNB. The request may be received via physical layer signaling such as a PDCCH order or by higher layer signaling such as an RRC reconfiguration message (e.g., an RRC connection reconfiguration message) which may include mobility control information and may, for example, indicate or correspond to a handover request. For a contention-free procedure that is initiated by a PDCCH order in a subframe n, the PRACH preamble may be transmitted in the first subframe, or the first subframe available for PRACH, n+k2 where k2 may be greater than or equal to <NUM> (i.e., k2 >= <NUM>). When initiated by an RRC command, there may be other delays which may be specified (e.g., there may be a minimum and/or maximum required or allowed delays). The WTRU may autonomously initiate a contention-based procedure for reasons that include initial access, restoration of UL synchronization, and/or recovering from radio link failure, as examples. For certain events, such as events other than recovery from radio link failure, how long after such an event the WTRU may send the PRACH preamble may not be defined or specified.

For a contention-free random access (RA) procedure, a network-signaled PRACH preamble may be used, for example, by a WTRU. For a contention-based random access procedure, the WTRU may autonomously choose a preamble where the preamble format and/or the time/frequency resource(s) available for preamble transmissions may be based on an indication or index (e.g., PRACH configuration Index) which may be provided or signaled by the eNB.

One of the preambles transmitted at the progressively higher transmit powers may be detected by the eNB. An RAR may be sent by the eNB in response to that one detected preamble. A PRACH preamble may be considered a PRACH resource. For example, PRACH resources may include a PRACH preamble, time, and/or frequency resources. The terms RACH resources and PRACH resources may be used interchangeably herein. Also, the terms RA, RACH, and PRACH may be used interchangeably herein.

In some situations of path loss, such as in NR, synchronization signal (SS) blocks (SSBs), RACH resources, control channels (DL/UL) and/or data channel (DL/UL) may collide with each other. In order for a WTRU to perform initial access, channel access, maintain system operation, and/or maximize the system efficiency, rules may be needed to avoid, mitigate or handle these and other situations when collisions occur. Also, in other situations, a WTRU transmission may collide with another WTRU transmission during random access. For example, PRACH preambles may collide with each other, such as where multi-beam systems are used. Enhancement to collision reduction in beam-based systems may be needed to address these and other path loss situations. Furthermore, to support large numbers of beams for beam sweeping, a PRACH preamble format may not be sufficient due to the limited number of symbols. Thus, it may be desirable to have approaches that support large numbers of beams. In one or more embodiments, PRACH resources, DL/UL control, and/or SS/PBCH blocks may be handled to address problematic situations as discussed herein.

<FIG> illustrates an example of a RACH/PRACH transmission. Generally, a first DL <NUM> may be a first SS block and second DL <NUM> may be a second SS block. A slot could have both DL (<NUM> and <NUM>) and UL parts <NUM>. In addition, a flexible or unknown part X <NUM> could be used in a slot and could be configured as DL or UL. A DL signal/channel <NUM> may occupy the first K<NUM> OFDM symbols of a slot <NUM>, where K is some non-negative integer. Unknown/flexible part X <NUM> may occupy K<NUM> OFDM symbols. A second DL signal/channel <NUM> may occupy K<NUM> OFDM symbols, which may be the same or different as the first DL signal/channel <NUM> (e.g., DL signal/channel <NUM> may be a first SS/PBCH block and DL <NUM> may be a DL signal/channel <NUM> may be a second SS/PBCH block). UL signal/channel206 may occupy the last K<NUM> OFDM symbols of the slot <NUM>. An SS block and SS/PBCH block may be interchangeable as discussed herein. The slot <NUM> may be configured such that each, or some, symbol location may contain a specific type of content; for the example shown in <FIG>, DL signal/channel <NUM>, K<NUM> may be the first <NUM> symbols and the UL signal/channel <NUM>, K<NUM> may be the last <NUM> symbols. Periodicity may also be configured by a gNB to avoid a collision, however, when/if a PRACH collides with an SS block, some predetermined or predefined rules such as block, signal, and/or channel dropping rules may be used. SS blocks, DL/UL control, and PRACH may have predefined rules when they collide with each other to that the WTRU may implement to handle these issues.

When SS/PBCH blocks and RACH resources collide, a WTRU may take one or more actions to address this issue, such as where a WTRU drops a PRACH and receives an SS block, or the WTRU drops an SS block and transmits a PRACH. The WTRU may also partially transmit a PRACH or partially receive an SS block. These options for collision handling may be based on at least one of the following: actually transmitted SS blocks or maximum SS blocks; latency requirement; service type (e.g., URLLC, eMBB, mMTC, etc.); predefined or predetermined rules (e.g., always transmit SS blocks or always transmit PRACH and drop the other channel); priority of channels, where priority may be predefined or configured; preemption indication; indication received from a gNB regarding which to transmit and which to drop; transmitting partial or all channels when collision occurs using rate matching or puncturing; and/or, a combination of the aforementioned approaches.

If a WTRU receives the actual transmitted SS block indication, the WTRU may use actually transmitted SS block positions to handle the collision. For example, for a long sequence (e.g., a long preamble sequence for PRACH), a WTRU may drop the RACH when there is collision. Otherwise, the WTRU may transmit RACH. For a short sequence (e.g., for a short preamble sequence for PRACH), a WTRU may transmit RACH in a non-slot (e.g., <NUM> symbols, <NUM> symbols) where the symbols are not occupied by SS blocks. As discussed herein, a non-slot may be a any non-regular length slot (e.g., a mini-slot). Also, for a short sequence, a WTRU may transmit a partial RACH in a non-slot (e.g., <NUM> symbols, <NUM> symbols) where the symbols are partially occupied by SS blocks. An SS block may be an actually transmitted SS block or an SS block may be a candidate SS block location.

If a WTRU does not receive the actual transmitted SS block indication, the WTRU may use a maximum number L of SS block positions to handle the collision. For example, a WTRU may use L=<NUM> SS blocks for below <NUM>, L=<NUM> SS blocks for below <NUM> and above <NUM>, and L=<NUM> for above <NUM>.

As discussed herein, there may be situations where there is, or could be, a collision between RACH resources, or RACH occasions, and SS block(s). As discussed therein, reference to a RACH occasion may be interchangeable with RACH resource; a RACH occasion may be one or more symbols in a slot where a RACH/PRACH may be sent. The slot, non-slot, or mini-slot with SS blocks may be configured as a RACH occasion according to a RACH configuration table. If collision occurs between a RACH occasion and an SS block, a WTRU may still transmit a PRACH preamble or RACH message <NUM> by skipping the symbols occupied by the SS block(s). A gNB may perform partial correlation for the PRACH preamble or rate matching for RACH message <NUM> PUSCH. The number of SS blocks may change. For example, the number of SS blocks may change from <NUM> to <NUM>. The <NUM> SS blocks may occupy the first SS block slot. Alternatively, the position of <NUM> SS blocks may still be the same as when there were <NUM> SS blocks.

As discussed herein, there may be situations where there is, or could be, a collision of UL Control Channel and RACH Resources. To address such a situation, a WTRU may drop a PRACH and transmit a UL control channel. Alternatively/additionally, a WTRU may drop UL control channel and transmit PRACH. Alternatively/additionally, a WTRU may partially transmit PRACH or partially transmit UL control. Collision handling for these and similar situations may be based on at least one of the following: UL control channel (e.g., whether it is periodic or aperiodic UL control channel); latency requirement; service type (e.g., URLLC, eMBB, mMTC, etc.); predefined or predetermined rules (e.g., always transmit UL control channel or always transmit PRACH and drop the other channel); priority of channels, where priority may be predefined or configured; preemption indication; indication received from a gNB regarding which to transmit and which to drop; transmitting both or all channels when a collision occurs; and/or, any combination of the aforementioned approaches.

A gNB may configure PRACH to avoid the collision between UL control channel and PRACH. If the PRACH collides with the uplink control, the WTRU may either drop RACH or drop UL control.

Predefined rules may be used to handle a collision as discussed herein. For example, when a PRACH and an UL control channel collide, a WTRU may drop UL control and only transmit PRACH, or vice versa.

In one or more situations, an indication may be used to handle a collision. A WTRU may receive an indication regarding which element of a collision is to be dropped and which is to be transmitted. For example, a WTRU may be indicated to drop PRACH and transmit UL control channel, or the WTRU may be indicated to drop UL control channel and transmit PRACH.

In one or more situations, an implicit indication may be used to handle a collision. A WTRU may determine which element of a collision is to be dropped and which is to be transmitted based on the service type. For example, if the service provided to a WTRU is URLLC, the WTRU may drop uplink control channel and transmit PRACH, or vice versa.

In one or more cases, a gNB may transmit and receive simultaneously. When the gNB is transmitting the SS block, the gNB may also be receiving using a specific Rx beam, at the same or different carrier. Then the PRACH may be transmitted even though the gNB is transmitting the SS block.

There may be collisions between RACH occasion(s) and semi-static scheduling and/or dynamic slot format indicator(s) (SFI). Downlink and/or uplink signal and/or channel in semi-static DL/UL assignment may not be overwritten to the other direction. DL and/or UL signal and/or channel in dynamic SFI may not be overwritten by WTRU-specific control or data channel. The RACH occasion that could collide with dynamic SFI may be dropped. The RACH occasion that is could collide with semi-static DL/UL assignment may be dropped.

A gNB and a WTRU may derive valid RACH occasion(s) (VRO) based on at least one of the following: a RACH occasion mapping to slots with SS blocks; semi-static DL and UL; Dynamic SFI; and/or, UL and/or DL scheduling. A valid RACH occasion may be an occasion to transmit in a time increment (i.e., one or more symbols of a slot) where it has been predetermined, or determined, that no collision will occur.

In some situations there may be collisions between a DL control channel and a RACH resource. In these situations, a WTRU may drop the PRACH and receive the DL control channel. Additionally/alternatively, a WTRU may drop the DL control channel and transmit the PRACH. Additionally/alternatively, a WTRU may partially transmit the PRACH or partially receive the DL control. Collision handling may be based on at least one of the following: latency requirement; service type (e.g., URLLC, eMBB, mMTC, etc.); predefined or predetermined rules (e.g., always receive DL control channel or always transmit PRACH and drop the other channel); priority of channels, where priority may be predefined or configured; preemption indication; indication received from a gNB regarding which to transmit and which to drop; transmitting partially or all channels when a collision occurs; and/or some combination of the aforementioned approaches.

A gNB may configure a PRACH to avoid the collision between a DL control channel and a PRACH. If a PRACH collides with the DL control channel, a WTRU may either drop the PRACH or drop the DL control channel.

Predefined rules may be used to handle a collision. For example, when a PRACH and a DL control channel collides, the WTRU may drop the DL control and only transmit the PRACH, or vice versa.

In one or more cases, an indication may be used to handle a collision. A WTRU may indicate which element in a collision is to be dropped and which is to be transmitted. For example, a WTRU may receive an indication to drop the PRACH and receive the DL control channel, or the WTRU may receive an indication to drop the DL control channel and transmit the PRACH.

In one or more cases, an implicit indication may be used to handle the collision. A WTRU may determine which element in a collision to drop and which to transmit based on the service type. For example, if the service provided by a WTRU is URLLC, the WTRU may drop the DL control channel and transmit the PRACH, or vice versa.

A WTRU may receive an indication regarding whether there is a NR-PDCCH present, search space configured, or control resource set (CORESET) configured that may collide with a RACH resource.

A gNB and a WTRU may determine or derive a valid RACH occasion for a DL control channel based on at least one of the following: semi-static DL and UL; dynamic SFI; and/or, UL and/or DL scheduling.

In one or more situations with collisions, rules and RACH resources may be used to address the collisions. As described herein, a RACH resource, or RACH occasion, may collide with either a DL part or an UL part. A RACH resource, or RACH occasion, may also collide with an unknown part that may be configured as a DL part or an UL part. The DL part may be an SS block, DL control channel, other DL control channel, signal, transmission, or the like. The UL part may be an UL control channel, other UL control channel, signal, transmission, or the like. A WTRU may receive an indication regarding semi-static UL/DL configuration and RACH configuration at the same time. The WTRU may also receive an indication for the semi-static UL/DL configuration before the RACH configuration. If the WTRU receives the indication for semi-static UL/DL configuration either at the same time with RACH configuration or before RACH configuration, and if RACH occasions collide with a DL part, then the RACH occasions that collide with the DL part may not be transmitted, but RACH occasions within the UL part may be transmitted. If a WTRU is indicated for semi-static UL/DL configuration after RACH configuration, and the WTRU is not aware of semi-static UL/DL configuration when RACH occasions are transmitted, then the WTRU may assume that RACH occasions will not collide with the DL part, and therefore the RACH occasions may be used for transmission and are valid. A RACH resource, or RACH occasion, may be used or transmitted in an unknown part (i.e., part X) if the unknown part is not configured or if the unknown part is configured as UL for the RACH transmission.

To avoid a possible collision, a WTRU may check a DL/UL configuration. The WTRU may transmit RACH in an UL part. The WTRU may transmit a RACH in a DL part if the DL part is not used. An indication regarding whether the DL part is used or not may be received at the WTRU. If a DL part is indicated as "used" (e.g., used for an SS block which was indicated as an actually transmitted SS block), the WTRU may not transmit RACH in those DL parts. Alternatively or additionally, a WTRU may not transmit a RACH in any DL part, whether it is used or not. Such an alternative or different alternatives may be configured.

In an embodiment, a WTRU may decide where to and/or whether to transmit a RACH resource depending on the location of an SS block or SS block transmission. For example, if the WTRU knows from an indication that an SS block is transmitted in a specific location (e.g., the specific location of a slot, subframe, or the like), then one or more RACH occasions (e.g., some or all of the RACH occasions) may be transmitted or not transmitted. Additionally/alternatively, for a given increment, a RACH may not be transmitted before an SS block but the RACH may be transmitted after the SS block. There may not be a RACH occasion, or RACH resource, before the SS block and the RACH occasion, or RACH resource, may be after the SS block. Additionally/alternatively, if an SS block is located or transmitted in the earlier part of a slot, then a RACH occasion/resource in the later part of a slot may be transmitted, and a RACH before the SS block may not be transmitted. If the SS block is located or transmitted in the later part of a slot, then the RACH in the earlier part of a slot may not be transmitted.

A WTRU may not transmit a RACH that will or may collide with an SS block in a slot, but the WTRU may still transmit the RACH that does not or will not collide with the SS block in the slot. Alternatively/additionally, the WTRU may not transmit all of the RACH occasions in a slot if one or more RACH occasions in a slot may collide with the SS block. The WTRU may transmit RACH or use a RACH occasion based on the collision condition with the SS block. Additionally/alternatively, the WTRU may transmit or not transmit the RACH, or use or not use the RACH occasion based on the location (e.g., in time or frequency) where the SS block is configured, indicated, or scheduled to be transmitted. In one case, a RACH occasion in a certain time, or frequency, location may be used even when it collides with an SS block. In another case, a RACH occasion in a certain time, or frequency, location may not be used if it collides with an SS block.

An indication of semi-static UL/DL configuration may be in New Radio-Physical Broadcast Channel (NR-PBCH), remaining minimum system information (RMSI), other system information (OSI), paging or the like. In addition, if a WTRU is indicated for dynamic UL/DL configuration, then dynamic UL/DL configuration may override the semi-static UL/DL configuration. If dynamic UL/DL configuration is indicated at the same time with RACH configuration or before RACH configuration and dynamic UL/DL configuration overrides the semi-static UL/DL configuration, the WTRU may follow the DL part and UL part in dynamic UL/DL configuration. The WTRU may then follow the rules for a RACH occasion transmission as described herein.

<FIG> illustrates an example process for a RACH transmission without SS block collision based on one or more embodiments described herein. At <NUM>, a WTRU may receive semi-static UL/DL Slot Configuration, such as in RMSI. In <NUM>, the WTRU may determine the ROs for the different parts of the slot (i.e., DL/X/DL/UL) based on the configuration information. In <NUM> the WTRU may receive a DL indication of the actually transmitted (Txed) SS blocks. In some cases, the WTRU may also receive an indication of an SS block enable/disable override, which may allow/disallow the WTRU to have a RO in a location where an SS block was indicated. Based on some or all or some of the information received, at <NUM> the WTRU may assess whether a given symbol is an occasion where a RACH may be sent (i.e., RO). In <NUM>, the WTRU may evaluate the ROs of the slot and determine whether they are valid ROs where there is no expected collision and any rules or indications are considered such that a RACH may actually be sent/scheduled. At <NUM>, the WTRU may transmit the RACH in the valid RO as determined in the previously.

<FIG> illustrates an example of a PRACH transmission without SS block collision based on one or more embodiments described herein. Each diagram (<NUM>, <NUM>, <NUM>) may be the result of one or more stages, in any order, of the process as described in <FIG>, as well as any of the rules or conditions for dealing with collisions as described herein. For this example, if there is an SS block in the DL control part, then the WTRU may not transmit a RACH in any of these symbols. Also, a RO may be valid if the occasion is after an indicated SS block, but not before. Generally, the transmission examples show only one slot broken up into parts with varying number of symbols (i.e., OFDM) that may be allocated to DL <NUM>, X <NUM>, DL <NUM>, and UL <NUM>. Each symbol may have a particular shading that corresponds to what occupies or is indicated to occupy that resource; for example, each possible RO has lines that go from top left to bottom right, such as RO <NUM>. No shading may mean that there is no, or no planned, use for that resource.

In diagram <NUM>, a WTRU may have completed <NUM>, <NUM>, and <NUM>. The WTRU may have determined that an SS block (SS block) <NUM> occupies a portion of the DL control <NUM> part of the slot <NUM>, therefore, the DL control part <NUM> may not contain any RO. Further, the remainder of the slot may have several ROs (<NUM>, <NUM>, <NUM>, <NUM>) configured, such as by the RMSI. Not shown, there may be a table for ROs. An index pointing to an entry of the table may indicate the ROs. A WTRU may be indicated by the index in an RMSI and determine the ROs based on the index received and the table which is known to WTRU.

Diagram <NUM> shows process <NUM>, the assessment of whether a RO is a valid opportunity to transmit (i.e., VRO), and may be similar to diagram <NUM>, except that an SS block <NUM> may be indicated to the WTRU, which results in only the UL part <NUM> having a valid RO since the X part <NUM>, which was a potential RO, cannot be valid since for this example a WTRU may only have valid ROs after an indicated SS block.

Diagram <NUM> shows process <NUM>, and may be similar to diagram <NUM>, except that there may be no SS block indicated for the DL <NUM>, which may lead to every RO after the DL control part <NUM> to be a valid RO.

In one or more embodiments, overlapped preamble subsets may be used. An SS block index may be embedded in an RA-RNTI. The RA-RNTI may be a function of an SS block index. Alternatively or additionally, an SS block index may be included in a random access response (RAR). Furthermore, an SS block index for the overlapped preambles may be embedded in the RA-RNTI and included in the RAR. For example, an SS block index (e.g., for the overlapped preambles) may be embedded in the RA-RNTI (e.g., using different RNTI for different SS block index, or using different CRC masking for different SS block index), and at the same time the same SS block index (e.g., for the overlapped preambles) may be included in an RAR.

<FIG> illustrates an example overlapping of preamble and synchronization signal (SS) block according to one or more embodiments described herein. In some situations, the association between SS blocks and RACH resources may overlap. That is, multiple SS blocks may be associated with the same RACH resource and/or PRACH preamble, or one SS block may be associated with multiple RACH resources and/or PRACH preamble. An SS block index for the overlapped preambles may be embedded in the RA-RNTI. The RA-RNTI may be a function of an SS block index. Alternatively or additionally, an SS block index for the overlapped preambles may be included in a random access response (RAR). By doing so, collisions among WTRUs as a result of overlapping may be avoided. Furthermore, the SS block index for the overlapped preambles may be embedded in the RA-RNTI and included in the RAR. A WTRU may acquire the SS block index obtained in the RA-RNTI and the SS block index obtained in the RAR. A WTRU may compare the SS block index obtained in the RAR, to the SS block index obtained in the RA-RNTI, and determine the final SS block index.

For a case with gNB Rx/Tx beam correspondence, preamble subsets corresponding to different SS blocks in one RACH slot may be overlapped to increase the capacity of initial access and random access.

For a case without gNB Rx/Tx correspondence, if preamble subsets corresponding to different SS blocks in one RACH slot are overlapped, multiple WTRUs with different SS blocks sending the same overlapped preamble may collide, because the gNB may not correctly separate the TAs associated to different SS blocks.

For a case with gNB Rx/Tx correspondence and overlap between gNB Tx beams, if preamble subsets corresponding to different SS blocks in one RACH slot are overlapped, multiple WTRUs with different SS blocks sending the same overlapped preamble may be separated by the gNB sending an SS block index inside the RARs, which may avoid collision among those WTRUs.

For a case with gNB Rx/Tx correspondence and no overlap between gNB Tx/Rx beams, if preamble subsets corresponding to different SS blocks in one RACH slot are overlapped, multiple WTRUs with different SS blocks sending the same overlapped preamble may be geographically separated by the gNB Rx/Tx beams, and gNB may not need to send an SS block index inside the RARs.

A gNB may configure whether to include SS block index in RAR, or RA-RNTI, based on antenna configuration, beam configuration, and/or beam correspondence.

As shown in <FIG>, there may be a set, or a pool, of PRACH preambles <NUM>, {<NUM>, <NUM>, <NUM>}, that may be partitioned into one or multiple subsets called preamble subsets. An SS block, such as a <NUM> SS block <NUM> or a <NUM> SS block <NUM>, may be associated with one or more preamble subsets. Preamble subsets may or may not overlap with one another. Preamble subsets may or may not share the same preamble(s). In one instance, a RACH configuration may allow that within one RACH Occasion (RO), preambles <NUM> and <NUM> may be associated with or mapped to the <NUM> SS block <NUM> creating a subset of {<NUM>, <NUM>} and preambles <NUM> and <NUM> may be associated with or mapped to the <NUM> SS block <NUM> creating the subset {<NUM>, <NUM>}. The first preamble subset {<NUM>, <NUM>} may be associated with or mapped to the <NUM> SS block <NUM> while the second preamble subset {<NUM>, <NUM>} may be associated with or mapped to the <NUM> SS block <NUM>. Just as in this example, preamble subsets may overlap with each other. Preamble <NUM> may be shared by the <NUM> SS block <NUM> and <NUM> SS block <NUM>.

At a gNB, the <NUM> Tx beam <NUM> may be associated with <NUM> SS block <NUM>, and the <NUM> Tx beam <NUM> may be associated with <NUM> SS block <NUM>.

In a case <NUM>, the <NUM> Tx beam <NUM> and <NUM> Tx beam <NUM> may overlap, which means that a WTRU may receive both of the signals from <NUM> Tx beam <NUM> and <NUM> Tx beam2. In a case <NUM>, the <NUM> Tx beam <NUM> and <NUM> Tx beam <NUM> do not overlap, which means that a WTRU may only receive the signal from either Tx beam <NUM> or Tx beam <NUM> but not both. Given these case <NUM> and case <NUM>, the following four scenarios may be considered: scenario <NUM>, case <NUM> - without gNB Tx/Rx beam correspondence; scenario <NUM>, case <NUM> - without gNB Tx/Rx beam correspondence; scenario <NUM>, case <NUM> - with gNB Tx/Rx beam correspondence; and scenario <NUM>, case <NUM> - with gNB Tx/Rx beam correspondence.

In an embodiment, a WTRU A may measure SS blocks and select <NUM> SS block <NUM>, and may randomly choose a preamble in the preamble subset associated with the <NUM> SS block <NUM>. A WTRU may select preamble <NUM>. The WTRU B may measure the SS blocks and select <NUM> SS block <NUM>, and may randomly choose a preamble. The WTRU B may also choose the preamble <NUM>.

A gNB may receive a single preamble (i.e., preamble <NUM>) from both WTRUs (WTRU A and WTRU B). When the gNB receives the preamble <NUM>, the gNB may determine that SS blocks (<NUM> SS block <NUM> and <NUM> SS block <NUM>) are associated with the detected preamble (preamble <NUM>). The gNB may send two RARs, RAR1 in <NUM> Tx beam <NUM> and RAR2 in <NUM> Tx beam <NUM>. The RAR1 may carry an SS block index <NUM> with RA-RNTI, and RAR2 may carry an SS block index <NUM> with the same RA-RNTI. Both WTRUs may decode the same RA-RNTI and decode the RAR accordingly. The WTRU A may obtain the SS block index in RAR1 (sent in <NUM> Tx beam <NUM>) and the WTRU B may obtain the SS block index in RAR2 (sent in <NUM> Tx beam <NUM>), and each WTRU may compare the received SS block index and its own selected SS block (WTRU A for <NUM> SS block <NUM> and WTRU B for <NUM> SS block <NUM>). If they match, each WTRU may assume that the RAR is intended for itself and send the Message <NUM> based on the grant received in its own RAR. Otherwise each WTRU may discard the received RAR. If both WTRU A and WTRU B select <NUM> SS block <NUM> (or <NUM> SS block <NUM>), WTRUs A and B may obtain the SS block index in RAR1 (or RAR2) and collision may occur. A redundancy version preamble method may be used to reduce or eliminate potential collision.

When a gNB has Tx/Rx beam correspondence, timing advance (TA) may be included in the RAR for beam transmitting a RAR. SS block specific TA and/or beam specific TA may be used in such a situation. Since the gNB may receive preambles from different Rx beams for different SS blocks, the gNB may estimate the TA for each Rx beam even though the same preamble is sent by both WTRUs. In RAR1, TA1 for WTRU A may be included in RAR1 sent in <NUM> Tx beam <NUM> associated with <NUM> SS block <NUM>. TA2 for WTRU B may also be included in RAR2 sent in <NUM> Tx beam <NUM> associated with <NUM> SS block <NUM>.

In some situations a gNB may have no Tx/Rx beam correspondence. For example, WTRU A's preamble <NUM> and WTRU B's preamble <NUM> may or may not be received from the same Rx beam. If they are received from the same Rx beam, then the gNB may not be able to tell that it is the same preamble but sent by two different WTRUs. If they are from different Rx beams, then the gNB knows that this preamble is sent from two different WTRUs in two different Rx beams and the TA corresponding to two WTRUs may be estimated. The gNB may not know which TA is fo <NUM> SS block <NUM> and which is for <NUM> SS block <NUM>, because there is no Tx/Rx correspondence. Therefore, the TA may be a function of beam correspondence.

For scenario <NUM> with Tx/Rx correspondence, a gNB may know the TA of preamble <NUM> for <NUM> SS block <NUM> and it may be included in RAR <NUM>. The gNB may also know that the TA of preamble <NUM> and it may be included in RAR <NUM>.

For scenarios <NUM> or <NUM>, the TA may not be estimated correctly for the WTRUs in an example.

For scenario <NUM>, the TA may be estimated correctly. The WTRU A may receive RAR1 through CORESET with RA-RNTI, and check that the preamble index (preamble <NUM>) and SS block index (<NUM> SS block <NUM>) are for itself. Similarly, the WTRU B may receive RAR2 through CORESET with RA-RNTI, and check that the preamble index (preamble <NUM>) and the SS block index (SS block <NUM>) are for itself.

For scenarios <NUM> or <NUM>, the WTRU A may also receive RAR2, however the SS block index (<NUM> SS block <NUM>) in the RAR2 may not match with what it selects an for SS block (<NUM> SS block <NUM>), and thus WTRU A may discard RAR2. Similarly, the WTRU B may also receive RAR1, however the SS block index (<NUM> SS block <NUM>) in the RAR1 may not match with what it selects for SS block (<NUM> SS block <NUM>), and thus the WTRU B may discard RAR1.

For scenario <NUM>, the WTRU A may only receive the RAR for its own and the WTRU B may only receive the RAR for its own. A gNB may not need to include the SS block index in RARs.

A gNB may be configured to include an SS block index in RAR or not to include the SS block index in the RAR. Furthermore, a gNB may be configured to include, or embed, SS block indexes in RAR and/or RA-RNTI. A gNB may be configured not to include, or embed, SS block indexes in any of the RAR and RA-RNTI. The configuration for the SS block index inclusion in RAR and/or RA-RNTI may be indicated in NR-PBCH, RMSI, OSI, paging, or the like.

A WTRU may receive a beam correspondence (BC) indication from a gNB regarding the gNB's BC. If the BC indication indicates "BC" and PRACH preamble subset overlap is configured, the WTRU may assume that an SS block index is present in the RAR or RA-RNTI. Otherwise, the WTRU may assume that an SS block index is not present in RAR or RA-RNTI. A flag or <NUM>-bit indicator may be used to indicate the presence/absence of the SS block index in RAR, NR-PBCH, remaining minimum system information (RMSI), or the like.

For the RACH configuration of scenario <NUM>, a WTRU may select <NUM> SS block <NUM> and send preamble <NUM>; a gNB may receive preamble <NUM> with Rx beam <NUM> and estimate the TA accordingly. Due to beam correspondence, the TA may be known for <NUM> SS block <NUM>. The gNB may send the RAR with RA-RNTI and RAR with random access preamble ID (RAPID) for preamble <NUM> corresponding to <NUM> SS block <NUM> as well as the corresponding TA and RACH Msg3 grant. The WTRU may receive RAR successfully and obtain the RACH Msg3 grant.

In an embodiment, WTRU A may select <NUM> SS block <NUM> and send preamble <NUM>. At the same time, WTRU B may select <NUM> SS block <NUM> and send preamble <NUM>. A gNB may receive preamble <NUM> with Rx beam <NUM>, and estimate TA1; the gNB may receive preamble <NUM> with Rx beam <NUM>, and obtain TA2. According to the beam correspondence, TA1 may be for <NUM> SS block <NUM>, and TA2 may be for <NUM> SS block <NUM>. A gNB may send RAR1 in gNB <NUM> Tx beam <NUM>, with RA-RNTI with information for preamble <NUM>, <NUM> SS block <NUM>, TA1, and Msg3 grant. The gNB may also send RAR2 in gNB <NUM> Tx beam <NUM>, with RA-RNTI with information for preamble <NUM>, <NUM> SS block <NUM>, TA2, and another Msg3 grant. The WTRU A may receive RAR1 since the SS block index in RAR1 is intended for the WTRU A. The WTRU B may receive RAR2 since the SS block index in RAR2 is intended for WTRU B.

In an embodiment for three WTRUs (not shown), WTRUs A, B, and C may send preamble <NUM> at the same time. The WTRUs A and C may select SS block <NUM>, and the WTRU B may select SS block <NUM>. A gNB may receive preambles by both Rx beams <NUM> and <NUM>, and may send RAR1 and RAR2, respectively. The WTRU A and WTRU C may receive RAR1 because the SS block index in RAR1 is <NUM>, and, both WTRUs may send a RACH Msg3 using the same UL grant and applying TA1. The WTRU B may receive RAR2 and send a RACH Msg3 by applying TA2. The RACH Msg3 of the WTRU A and WTRU C may collide with each other and the gNB may successfully receive only one RACH Msg3 from one of the WTRUs whose TA is correct, and may fail decoding the other RACH Msg3 (i.e., the gNB may fail to receive both RACH Msg3).

In one or more embodiments, a preamble type may be based on a hierarchical association of an SS Block and RACH. An SS block may be associated with a RACH occasion. For example, one SS block may be associated with one RACH occasion. All the preamble indexes for the RACH occasion may be associated with the same SS block. A WTRU may randomly select any one preamble and transmit the selected preamble in the RACH occasion associated with the selected SS block that the WTRU may want to convey to a gNB.

In an alternative, an SS block may be associated with both RACH occasion and preamble. Multiple SS blocks may also be associated with one RACH transmission occasion, and hierarchical association may be used. SS blocks (e.g., actually transmitted SS block) may be divided into groups, for example, K groups, where K is some non-negative integer. The SS block group may be associated with a RACH occasion. Within each RACH occasion, an SS block within the SS block group may be associated with the preamble belonging to the corresponding RACH occasion. An SS block may be associated with a combination of a RACH occasion and a preamble index. The preamble indexes for the RACH occasion may be associated with the SS block. One or more preamble indexes within the RACH occasion may be associated with an SS block. The preamble indexes for each SS block may be mapped consecutively or non-consecutively. For non-consecutive mapping, the preamble indexes for each SS block may be mapped in an interleaved fashion or distributed fashion. A WTRU may select the preamble associated with the selected SS block to be sent to a gNB and transmit the selected preamble in the RACH occasion associated with these multiple SS blocks.

In one or more cases, SS blocks may be actually transmitted SS blocks. Alternatively or additionally, SS blocks may be candidate SS blocks, nominal SS blocks, or all SS blocks including transmitted or not transmitted SS blocks. If a WTRU is indicated for actually transmitted SS blocks, the WTRU may use actually transmitted SS blocks for the association with RACH occasions or resources. If a WTRU is not indicated for actually transmitted SS blocks, the WTRU may use candidate SS blocks, nominal SS blocks, or all SS blocks including transmitted or not transmitted SS blocks for the association with RACH occasions or resources. If a WTRU is indicated or configured to use candidate SS blocks, nominal SS blocks, or all SS blocks to associate with RACH occasions or resources, this may override the case of using actually transmitted SS blocks even if the WTRU may be indicated for actually transmitted SS blocks. For example, such override indication or association configuration may be in RRC signaling or NR-PBCH. The actually transmitted SS blocks may be indicated in RMSI or OSI.

The techniques described herein may be applied to either contention based random access or contention free random access, and/or may also be applied to both contention based random access and contention free random access.

<FIG> illustrates an example of preamble and SS block association. As shown, preambles partitioned <NUM> into multiple subsets A, B, and C with two, or more, types. A first type of preamble subsets may be associated with one SS block. The second type of preamble subsets may be associated with more than one SS block. For example, preamble subsets A and B each may be the first type of preamble subsets which may be associated with one SS block, such as SS block <NUM> and SS block <NUM>, respectively. A preamble subset C may be the second type of preamble subset which may be associated with more than SS block, such as SS block <NUM> and <NUM>.

In one case, SS block <NUM> and SS block <NUM> may be adjacent to each other in terms of their associated transmitted beams. SS block <NUM> may have index m and SS block <NUM> may have index n. In this case, m may be n+<NUM> or n-<NUM>.

<FIG> illustrates an example method of RACH resource and SS block association. For purposes of the illustration, RACH Resource and RACH Occasion may be interchangeable when appropriate. As shown, RACH Resources may be partitioned <NUM> into multiple subsets A, B, and C with two, or more, types. A first type of RACH Resource subsets may be associated with one SS block. The second type of RACH Resource subsets may be associated with more than one SS block. For example, RACH Resource subsets A and B each may be the first type of preamble subsets which may be associated with one SS block, such as SS block <NUM> and SS block <NUM>, respectively. RACH Resource subset C may be the second type of preamble subset which may be associated with more than one SS block, such as both SS block <NUM> and SS block <NUM>.

<FIG> illustrates an example process of SS block association and mapping to RACH. The WTRU may carry our one or more of the stages as disclosed. At <NUM>, actually transmitted SS blocks (SS blocks) may be indicated to a WTRU. At <NUM>, the actually transmitted SS blocks may be partitioned into an SS block group. At <NUM>, the SS blocks or SS block groups are mapped to ROs or RACH Resources. At <NUM>, if there is more than one SS block per RO or RACH resource, then the SS blocks may be mapped to preambles for each RO or RACH resource in <NUM>, after which there may be preamble-type based or non-preamble-type based preamble subset partitioning and mapping of <NUM>. If there is not more than one SS block per RO or RACH Resource according to <NUM>, then the process may stop at <NUM>.

<FIG> is a diagram illustrating another example method of SS block association and mapping to RACH. A WTRU may perform one or more stages of this example. At <NUM>, a number of actually transmitted SS blocks may be indicated to a WTRU. At <NUM> a number of preambles per SS block per RO may be indicated to a WTRU. At <NUM>, a number of SS blocks per RO may be indicated to a WTRU. At <NUM>, a number of ROs in the Frequency Domain (FDM ROs) may be indicated to a WTRU. At <NUM>, a number of ROs in a slot (TDM ROs) may be indicated to a WTRU. At <NUM>, a number of slots for RACH may be indicated to a WTRU. At <NUM>, there may be a preamble-first-mapping that maps SS blocks to preambles. At <NUM> there may be frequency-second-mapping that maps SS blocks to Frequency Domain ROs (FDM ROs). At <NUM> there may be time-third-mapping that maps SS blocks to Time Domain ROs (TDM ROs). At <NUM>, there may be same-slot first-mapping that maps SS blocks to Time Domain ROs within a slot. At <NUM>, there may be cross-slot second-mapping that maps SS blocks to Time Domain ROs across slots. If same-slot mapping is sufficient, the cross-slot mapping may not be needed. If same-slot mapping is not sufficient (e.g., there are many SSBs needed to be mapped to ROs), then cross-slot mapping may be performed. At <NUM>, if mapping cycle is finished for all ROs, then proceed to <NUM> and stop. Also at <NUM>, if mapping cycle is not finished for ROs, then discard the remaining ROs at <NUM>.

In one or more embodiments, there may be PRACH resource package based beam sweeping. The number of OFDM symbols in a PRACH preamble format or the repetition number of a PRACH preamble format may be smaller than the number of a gNB Rx beam. A gNB may sweep Rx beams for PRACH using multiple RACH occasions. The multiple RACH occasions may consist of one or multiple RACH resources (e.g., one or multiple slots, non-slots, mini-slots or OFDM symbols). The multiple RACH occasions may be consecutive or may not be consecutive. Multiple RACH occasions may be configured to one WTRU. In one case, the WTRU may assume that there may be multiple RACH occasions as a package. The WTRU may start a PRACH preamble transmission using the <NUM>st RACH occasion, <NUM>nd RACH occasion, <NUM>rd RACH occasion, and so on, until all the beams have been swept. Depending on the number of actually transmitted SS blocks, or number of beams at a gNB, multiple RACH occasions (as a package) with K OFDM symbols may be configured to the WTRU for K actually transmitted SS blocks or beams at the gNB. To further support WTRU Tx beam sweeping in addition to gNB Rx beam sweeping, if the WTRU has M Tx beams, then multiple RACH occasions (as a package) with K times M OFDM symbols may be configured to the WTRU. Different PRACH preamble formats may be used, such as preamble format A, B and/or C. For example, PRACH preamble format A may be A0, A1, A2, A3, preamble format B may be B1, B2, B3 and B4. Preamble format C may be C0 and C1. The number of SS blocks may be notated as L. The number of gNB Rx beams may be notated as Nrx. The repetition number of configured preamble format may be notated as Nrp.

If there is no beam correspondence, in order to ensure that a gNB can sweep all Rx beams to receive multiple RACH trials from a WTRU, the gNB may configure ceiling <MAT> types of RACH occasions. All gNB Rx beams may be swept by a "RACH occasion package". This may be configured for each SS block or for all SS blocks. Different types of RACH occasions may correspond to different Nrp gNB Rx beams. The ceiling <MAT> types of RACH occasions may be defined as a "RACH occasion package".

For a retransmission of RACH Msg1, the WTRU may pick up a different RACH occasion type that has not been used in the previous RACH Msg1 (re)transmissions in order to complete the gNB Rx beam sweeping.

For RACH Msg1 retransmission, it may be configured or determined by the WTRU to decide whether to change WTRU UL Tx beam, ramp up the power, or change the type of RACH occasion.

<FIG> illustrates an example configuration of a window length for each random access channel (RACH) occasion type where the window length, such as <NUM> and <NUM>, of a RACH occasion may be the same as the RACH configuration period, such as <NUM>. The window length for each RACH occasion type may be configured such that the window lengths of all RACH occasion types are the same. For example, the window length <NUM> may be the same as the RACH Configuration period <NUM>. Alternatively or additionally, the window lengths of all RACH occasion types may be N times a RACH configuration period (not shown), where N may be configured in the remaining minimum system information (RMSI). In one example, N may be an integer greater than <NUM>.

<FIG> illustrates an example configuration of a window length for each random access channel (RACH) occasion type where the window length of a RACH occasion is twice of the RACH configuration period. As shown, the window length <NUM> for a RACH occasion type is configured to be twice the RACH Configuration period <NUM>.

<FIG> illustrates an example configuration of window length for each random access channel (RACH) occasion type where the window length of a RACH occasion is smaller than the RACH configuration period. As shown, the window length <NUM> for each RACH occasion type may be smaller than a RACH configuration period <NUM>. All RACH occasion types may be within a RACH configuration period. In some embodiments, window lengths of different RACH occasion types may be different. Predefined patterns of window lengths may be used. A WTRU may be configured with one pattern in an RMSI.

The number of RACH occasion types, Q, may be indicated to a WTRU in NR-PBCH or RMSI. Depending on beam correspondence, Q may have different values. For example, for a gNB without beam correspondence, <MAT>. For a gNB with beam correspondence, Y = <NUM>. For a gNB with partial beam correspondence, <MAT>, where <MAT> is the number of gNB Rx beams that have overlap with the gNB Tx beam corresponding to the SS block. For example, Nrx= <NUM>; Nrp= <NUM>; L = <NUM>. There may be two types of RACH occasion for each SS block. The type <NUM> RACH occasion may be received by gNB Rx beams <NUM> and <NUM>. The type <NUM> RACH occasion may be received by gNB Rx beams <NUM> and <NUM>.

In an embodiment, Nrx may be set to <NUM>, Nrp may be set to <NUM>, and L may be set to <NUM> (i.e. Nrx = <NUM>; Nrp= <NUM>; L = <NUM>). There may be <NUM> types of RACH occasions for each SS block. Each type of RACH occasions may be received by <NUM> gNB Rx beams, and the subset of gNB Rx beams may be different for different types of RACH occasions.

In another embodiment, Nrx may be set to <NUM> and Nrp may be set to <NUM> (i.e. Nrx = <NUM>; Nrp = <NUM>). There may be only one type of RACH occasion in this embodiment.

<FIG> illustrates an example redundancy version of a preamble based on SS beam reporting. A WTRU <NUM> may perform listen before talk (LBT) and transmit a RACH preamble. A gNB <NUM> may perform the LBT and transmit RAR. If the gNB <NUM> fails LBT in <NUM> beam <NUM>, it may not transmit RAR in <NUM> beam <NUM>. If the WTRU <NUM> reports only one beam (e.g., <NUM> beam <NUM>), the WTRU <NUM> may not receive RAR due to the LBT failure of the gNB <NUM>.

In an embodiment, a WTRU <NUM> may report more than one beam (especially at overlap area of beams) such as <NUM> beam <NUM> and <NUM> beam <NUM>. The WTRU <NUM> may report the SS block for the strongest beam along with SS block for other beams. The WTRU <NUM> may perform LBT and transmit a RACH preamble which may associate with SS block#<NUM> (e.g., <NUM> beam <NUM>) and SS block#<NUM> (e.g., <NUM> beam <NUM>). A gNB <NUM> may perform LBT on more than one beam (e.g., <NUM> beams <NUM> & <NUM> beam <NUM>) and may transmit RAR accordingly. If the gNB <NUM> fails LBT in <NUM> beam <NUM>, it may transmit RAR in other beams (e.g., <NUM> beam <NUM>). On the other hand, if the gNB <NUM> fails LBT in <NUM> beam <NUM>, it may transmit RAR in other beams (e.g., <NUM> beam <NUM>). Unless the gNB <NUM> fails LBT in both or all beams, the gNB <NUM> may need to continue performing LBT until the channel is clear before transmitting RAR. This may cause significant delay and high latency. By reporting more than one SS block from the WTRU <NUM>, the gNB <NUM> may be able to transmit RAR with no delay. Association of preamble and SS block may be one preamble to many SS blocks. For example, preamble #<NUM> may be associated with SS block#<NUM> and #<NUM>, preamble #<NUM> may be associated with SS block#<NUM> and #<NUM>, and so on.

However, when more than one WTRUs are in the same overlapped area of beams, multiple WTRUs may report the same preamble which results in collision (not shown). In NR or NR-Unlicensed, WTRUs in the same overlapped area of beams may report the same preamble which may result in a preamble collision if a WTRU selects the same RACH occasion.

In an embodiment, redundancy version based SS block reporting may be used, and a gNB may be able to transmit RAR with no delay. The association of a preamble and an SS block may be based on redundancy of the preamble.

In an embodiment, a redundancy version of a preamble association may be used, where an association of a preamble and an SS block may be one preamble to many SS blocks and a redundancy version of the same association of the preamble and SS block may be used. For example, in a case where preamble #<NUM> is associated with SS block #<NUM> and #<NUM>, the preamble #<NUM> may be a redundancy version of preamble #<NUM> and may also be associated with the same SS blocks (e.g., SS block #<NUM> and #<NUM>). This may eliminate or reduce WTRU collision since the WTRUs in the same overlapped area of beams may not report the same preamble.

In one case, a WTRU may report more than one SS block using a preamble or RACH Msg3. Where preamble-based SS block reporting is used, one preamble may be mapped to multiple SS blocks (e.g., preamble#<NUM> is mapped to SS block#<NUM> and SS block#<NUM>). In order to further reduce collision, the same mapping may be repeated for another preamble. For example, a redundancy version of preamble #<NUM> may be produced for preamble #<NUM>. In another example, redundancy version of preamble #<NUM> may be one or the following: preamble #<NUM>, which may be mapped to the same SS blocks (e.g., SS block#<NUM> and SS block#<NUM>); or preamble #<NUM>, which may be mapped to the same SS blocks (e.g., SS block#<NUM> and SS block#<NUM>). A gNB may perform directional a LBT and send RAR. If the LBT fails in SS block1, the gNB may have flexibility to send RAR in SS block2.

In a case where RACH Msg3-based SS block reporting is used, the RACH Msg <NUM> may include the redundant version for mapping in its payload as follows: preamble#<NUM> may be mapped to SS block#<NUM> and SS block#<NUM>; preamble#<NUM> may be mapped to SS block#<NUM> and SS block#<NUM>; and/or, preamble#<NUM> may be mapped to SS block#<NUM> and SS block#<NUM>.

A redundancy version of a preamble based SS block reporting may be applied to initial access and channel access including random access, beam management for data, and/or control, mobility, and/or other use cases and scenarios. A redundancy version of a preamble based SS block reporting may be applied to NR licensed band or unlicensed bands as well as standalone or non-standalone systems.

Although the features and elements of the present invention are described in the preferred embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the preferred embodiments or in various combinations with or without other features and elements of the present invention.

Although the embodiments described herein consider LTE, LTE-A, New Radio (NR) or <NUM> specific protocols, it is understood that the embodiments described herein are not restricted to this scenario and are applicable to other wireless systems as well.

Claim 1:
A method implemented by a wireless transmit receive unit, WTRU, the method comprising:
receiving configuration information, the configuration information indicating that a plurality of physical random access channel, PRACH, preambles are divided into a plurality of PRACH preamble subsets, wherein each PRACH preamble subset is associated with a respective synchronization signal, SS, block transmission, a plurality of SS blocks transmissions are associated with a random access channel, RACH, occasion, and preamble indexes of the plurality of PRACH preambles are used to consecutively map each of the plurality of PRACH preambles into one of the respective PRACH preamble subsets;
receiving the plurality of SS block transmissions;
selecting a first SS block transmission of the plurality of SS block transmissions;
selecting a first PRACH preamble based on selecting the first SS block transmission, wherein the first PRACH preamble is one of the PRACH preambles comprised in a PRACH preamble subset indicated as being associated with the first SS block transmission by the configuration information; and
transmitting the first PRACH preamble in the RACH occasion, wherein the first PRACH preamble is indicative of the WTRU selecting the first SS block transmission of the plurality of SS block transmissions associated with the RACH occasion.