Patent Description:
In release <NUM> of New Radio (NR), a <NUM>-step random access channel (RACH) procedure is supported on the uplink. There are several triggers that initiate a RACH procedure such as synchronization acquisition and handover. A <NUM>-step RACH procedure is being studied as an alternative to the <NUM>-step RACH procedure and the <NUM>-step RACH may be used in cases such as those which require low latency. At the RAN plenary #<NUM>, NR approved a working item for contention based <NUM>-step RACH.

The claimed invention is disclosed by the appended claims.

For example, the communications systems <NUM> may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform Spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

As shown in <FIG>, the communications system <NUM> may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) <NUM>, a core network (CN) <NUM>, a public switched telephone network (PSTN) <NUM>, the Internet <NUM>, and other networks <NUM>, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station (STA), may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like.

Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN <NUM>, the Internet <NUM>, and/or the other networks <NUM>. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation NodeB, such as a gNode B (gNB), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like.

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access, which may establish the air interface <NUM> using NR.

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 UL (e.g., for transmission) and DL (e.g., for reception) may be concurrent and/or simultaneous. 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 AP may have access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS. 11e DLS or an <NUM>.

The primary channel may be a fixed width (e.g., <NUM> wide bandwidth) or a dynamically set width. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in <NUM> systems.

11af and <NUM> ah. 11af and <NUM>. 11n, and <NUM>. 11af supports <NUM>, <NUM>, and <NUM> bandwidths in the TV White Space (TVWS) spectrum, and <NUM>. 11ah may support Meter Type Control/Machine-Type Communications (MTC), such as MTC devices in a macro coverage area.

11n, <NUM>. 11ac, <NUM>. 11af, and <NUM>. If the primary channel is busy, for example, due to a STA (which supports only a <NUM> operating mode) transmitting to the AP, all available frequency bands may be considered busy even though a majority of the available frequency bands remains idle.

The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a varying number of OFDM symbols and/or lasting varying lengths of absolute time).

For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like. The AMF 182a, 182b may provide a control plane function for switching between the RAN <NUM> and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi.

<FIG> is an example information exchange between a WTRU and a gNB for a <NUM>-step RACH procedure. The WTRU may send a first message (e.g. msg1) which may be a randomly selected random access preamble sequence. The first message may be sent during a PRACH opportunity. The gNB may receive the first message and may reply with a second message (e.g. msg2). The second message may be or comprise a random access response (RAR). The RAR may comprise a DCl. The DCI may be scrambled with a RA-RNTI corresponding to the PRACH occasion in which the preamble is sent. The DCI may contain a RAR grant. The RAR grant may comprise a time and frequency resource allocation for the WTRU. The RAR grant may comprise a modulation and coding scheme (MCS) and a transmit power control (TPC) command. The second message may contain a preamble index so that the WTRU may confirm the RAR is intended for the WTRU. The WTRU may monitor a control channel for the second message and decode it. The WTRU may scramble data with a TC-RNTI. The WTRU may send a third message (e.g. msg3). The third message may comprise a payload of the scrambled data. The third message may be sent according to scheduled resources provided in the RAR grant. The gNB may reply with a fourth message (e.g. msg4). The fourth message may be a contention resolution message. Upon reception of the fourth message, the WTRU may compare its TC-RNTI sent in the third message with the WTRU identity received in the fourth message. Contention may occur when two WTRUs select the same preamble because it may cause them to monitor the same RAR grant which may lead the WTRUs to send a third message on the same resources. In the event of a collision, a WTRU may attempt another RACH procedure. The WTRU may send an acknowledgment message to indicate successful reception of the fourth message.

<FIG> is an example information exchange between a WTRU and a gNB for a <NUM>-step RACH procedure. In a <NUM>-step RACH procedure, msg1 (e.g. a preamble) and msg3 (e.g. a payload) may be sent together in a first transmission (e.g. msgA). The preamble and the payload may be time division multiplexed. The payload may be transmitted on a channel such as a Rel-<NUM> NR PUSCH using a Rel-<NUM> NR demodulation reference signal (DMRS). The PRACH preamble sequences may be reused from Rel-<NUM> NR. In the <NUM>-step RACH procedure, msg2 and msg4 may be combined into a second message (e.g. msgB). An acknowledgement (ACK) or a negative acknowledgement (NACK) may be included in msgB and may indicate feedback for the preamble, PUSCH payload, and/or contention resolution.

In <NUM>-step RACH, the payload may be transmitted before receiving a resource assignment (e.g. grant) from a gNB. This may lead to a collision of payloads if WTRUs decide to transmit on the same set of resources. At the receiving end, the gNB may need to know the transmission configuration used by a WTRU to decode msgA. Therefore, assuming a signal structure for msgA comprising of a preamble and a PUSCH payload, the following issues may need to be addressed: (i) preamble and PUSCH resource mapping to reduce the probability of collision; (ii) how a WTRU based on preamble transmission may enable non-orthogonal multiple access (NOMA) detection at a gNB; (iii) how a WTRU determines a transmission configuration and indicates it to a gNB; and (iv) link adaption and power control mechanism for preamble and PUSCH.

Described herein, a reference symbol may be used to denote a symbol such as a complex number that is fixed and known and used as a pilot. A reference signal may be used to denote a time domain signal that is generated after processing the reference symbols. For example, in OFDM, reference symbols are the complex numbers that are fed into an IDFT block while a reference signal is the output of the IDFT block. Downlink control information (DCI) is a set of bits that may be transmitted over a PDCCH for a user or a group of users. A resource element (RE) may be one OFDM symbol on one subcarrier, and a resource element group (REG) may refer to a group of REs which may be used as building blocks of control channel element (CCE) which may assign resource elements to a user. Adjacent REGs in time or frequency that are grouped together and their associated precoder is the same are called REG bundles. NR-REG, NR-CCE, and NR-PDCCH may refer to REG, CCE, and PDCCH for the new radio (NR) in <NUM>. UE and user may be used interchangeably. gNodeB and gNB may be used interchangeably. A control resource set (CORESET) may be a set of resource elements used for a downlink control channel, configured by its frequency resources and its length in time (in terms of symbols) and the type of its REG bundles. A search space, or a set of search spaces, may be a set of PDCCH candidates that are monitored by a UE or a group of UEs during blind detection of a PDCCH.

In Rel-<NUM> NR, a WTRU may initiate a PRACH transmission by randomly selecting a preamble from a list of configured preambles. The configuration may be communicated to the WTRU through a SIB during initial access. In <NUM>-step RACH, a PUSCH transmission may occur without receiving an uplink scheduling grant in a DCI to schedule on which resources the transmission may occur and with which transmission parameters. The content of the scheduling grant may be inferred by the selection of the preamble.

In an embodiment for <NUM>-step RACH, a WTRU may implicitly signal to a gNB additional information about the payload (PUSCH) portion of msgA's transmission by its choice of preamble. The following may be implicit details that may be inferred at a gNB: PUSCH resources; WTRU-ID; MCS; DMRS indices, and beam indices. For example, one preamble may be linked to a set of parameters. A WTRU may randomly select a preamble and transmit the preamble using the specified parameters. The gNB may detect a preamble index and based on the preamble index the gNB may implicitly determine that the transmission from the WTRU is performed using the specified parameters linked to the preamble. For example, if a WTRU selects preamble <NUM>, then it may transmit on PRB1 with MCS1 and using DMRS1. A WTRU-ID may also be associated with a preamble set partition.

Transmission of msgA may involve transmission of a preamble and a payload (PUSCH). <FIG> shows an example of a same mapping of preamble and PUSCH resources. In <FIG> the preamble resources are in a same frequency (e.g. same resource blocks (RBs)) as the PUSCH resources. The mapping of PUSCH resources may not occur in a same resource block range as preamble resources. <FIG> shows an example of a different mapping of preamble and PUSCH resources. In <FIG> the preamble resources are in a different frequency (e.g. same resource blocks (RBs)) as the PUSCH resources. The mapping of PUSCH resources may be independent of or a function of preamble resources in frequency and/or time.

In an embodiment, a WTRU may apply a frequency offset difference, which may be a fixed frequency offset difference, between a resource mapping of the preamble and a resource mapping of PUSCH resources. The frequency offset value (Δf) may be configured or reconfigured through a dynamic or a semi-static process. In an embodiment, a WTRU may apply a time varying frequency offset based on a pattern known to a gNB. The pattern may be preconfigured, or it may be based on one or more system parameters (e.g., symbol number, RB index, WTRU identity, type of RNTI).

A WTRU may be configured with one or more preambles and PUSCH resources for <NUM>-Step RACH. Despite having different preambles, msgA payloads of different WTRUs may collide during the <NUM>-Step RACH procedure. The relationship between the preamble and PUSCH resources may be fixed, semi-statically configured during initial access, or dynamically reconfigured.

The configured preamble and PUSCH resources may be linked such that by selection of a preamble, a WTRU may be able to select from a subset of the available PUSCH resources. A WTRU may implicitly indicate to a gNB some information for detection of a transmitted payload in a PUSCH. In an embodiment, a preamble may be associated with more than one set of PUSCH resources where each set of PUSCH resources may comprise of one or multiple PRBs.

A subset of PUSCH resources may be configured to be associated with one preamble. A WTRU may randomly select a preamble and the WTRU may randomly select one PUSCH resource from a partition associated with the preamble. If multiple WTRUs select the same preamble, they may each be able to transmit on one of the randomly selected resources from the configured partition. Through transmission of the preamble, a WTRU may indicate to the gNB the subset of interest for detection. The gNB may detect the preamble and may search through the associated PUSCH resources to decode the WTRUs.

In an embodiment, a preamble may be associated with multiple subsets of PUSCH resources where selection of a subset of PUSCH resources may be based on another system parameter or measurement. For example, selection of a subset of PUSCH resources may be based on the on a packet size, a service type, an expected reliability or delay, a bandwidth part, or an estimated pathloss.

In an embodiment, a WTRU may be configured with multiple subsets of PUSCH resources where selection of a subset of PUSCH resources may not be linked to a specific preamble. Selection of a subset of PUSCH resources may be based on another system parameter or measurement.

A WTRU may be configured with multiple PUSCH resources where each set of PUSCH resources may comprise of one or multiple PRBs. The PUSCH resources may follow a contiguous or a non-contiguous mapping. A WTRU may be configured to transmit its payload using more than one set of PUSCH resources for enhanced reliability as well as demonstrating robustness to potential collisions. The additional PUSCH resources may be the same or different than a size of the original PUSCH resource.

<FIG> shows an example of msgA transmission using a plurality of PUSCH resources. As shown in <FIG>, the mapping of each additional PUSCH resource may have a different time and/or frequency offset with respect to a preamble location that may be configured. In <FIG>, Δt2 represents a configurable time offset value of PUSCH Resource <NUM> and Δf2 represents a configurable frequency offset value of PUSCH Resource <NUM> with respect to the preamble location. In an example, Δt2 may be determined based on another system operational parameter (e.g., delay tolerance of the service, mobility state).

In an example, a WTRU may determine a mapping of additional PUSCH resources based on allocation information of the original PUSCH transmission and a time offset value (Δti,) and a frequency offset value (Δfi) value of additional PUSCH resources.

A multiplicity, size and pattern of additional PUSCH resources may be determined based on system configuration parameters (e.g., service type, delay, reliability requirements) or operational parameters (e.g. SINR, traffic load, interference). A WTRU may be configured with a plurality of additional PUSCH resources according to an expected transmission reliability and delay tolerance. In an example, a WTRU, such as a URLLC WTRU, may be configured with a plurality of PUSCH resources to enhance the likelihood of a successful msgA transmission.

The mapping of additional PUSCH resources may have a fixed or a variable pattern per slot that may be pre-configured. In an example, the mapping of additional PUSCH resources may be determined based on other system parameters (e.g., UE ID, slot number).

The pattern of additional PUSCH resources may be randomly selected by a WTRU. The pattern of additional PUSCH resources may be linked to the choice of the preamble.

In an embodiment, each transmission instance of an additional PUSCH resource may use a same panel as the original transmission, but may have a different precoding or beam than the original transmission. Alternatively, each transmission instance on an additional PUSCH resource may use a different panel.

In an embodiment, additional PUSCH resources may be used to repeat an original transmission with a same MCS. The repetition on each additional PUSCH resource may be with a same redundancy version (RV) as the original transmission. In an example, at least one repetition may have a different RV than the original transmission.

In an embodiment, additional PUSCH resources may be used to repeat an original transmission with a different MCS. A WTRU may use different PUSCH resources according to the MCS selected for the additional PUSCH transmission.

In an embodiment, a set of preambles may be associated with a same set of PUSCH resources. A preamble selected from the set of preambles may refer to the same set of overlapped PUSCH resources. A WTRU that selects a preamble from this set triggers a WTRU-ID selection for the PUSCH transmission. In a WTRU-ID selection process, a WTRU combines its RA-RNTI with the additional parameter preamble index. The WTRU-IDs is used for WTRU specific scrambling.

In an embodiment, a WTRU may use a set of resources to transmit a resource assignment and use another set of resources to transmit other information. The content transmitted on the first set of resources may include PRBs, MCS, and DMRS indices. For example, a WTRU may use shared resources to transmit a resource assignment used by the WTRU for the non-shared resources. The content transmitted on the shared resources may include PRBs, MCS, and DMRS indices. One or several shared resources may be available for the WTRU to choose from. A WTRU may randomly select one or multiple sets from the non-shared resources to transmit its payload. A WTRU may randomly select one of the non-shared resources to transmit parameters that may be necessary to decode the payload sent on the shared resources. The parameters may include UE-ID, DMRS indices, or other identifiers.

<FIG> shows an example of a WTRU using a set of shared resources and a set of non-shared resources. A preamble may be associated with one or more sets of shared resources and one or more sets of non-shared resources. A set of shared resources may be used jointly with non-shared resources to complement each other. A WTRU may select a preamble (<NUM>). The WTRU may select a set of shared resources and a set of non-shared resources (<NUM>). The WTRU may transmit on the shared resources and the non-shared resources (<NUM>).

In an embodiment, a WTRU may dynamically switch between shared resources and non-shared resources by selecting different preambles. Preambles may be associated with either shared or non-shared resources. For example, preamble set <NUM> may be associated with non-shared resources while preamble set <NUM> may be associated to one or multiple sets of shared resources. A WTRU may randomly select one out of K preambles and transmit its payload on the associated PUSCH resources. If a WTRU selects a preamble associated to a set of shared resources, the WTRU may trigger a WTRU-ID selection for UL-SCH scrambling. A WTRU may be triggered by higher layers to select from either preamble set.

A WTRU may be configured with uplink grant resources that may be used for transmission of a PUSCH in a <NUM>-Step RACH procedure. The configured grant resources, or configuration, may be provided in a broadcast message (e.g. in a PBCH) or may be provided in a WTRU-specific manner (e.g. for CONNECTED mode WTRUs). The configured grant resources may have a specific time periodicity and offset and a specific frequency location.

A WTRU may transmit a preamble in a random access occasion. The WTRU may map a PUSCH transmission to an upcoming configured grant resource. The configured grant resource may include uplink control information that may indicate the PRACH transmission it is associated with. For example, uplink control information in the configured grant may include at least one of: a preamble sequence, PRACH resources, a timing offset (between the configured grant and the previously transmitted PRACH), or any parameter used by the WTRU to determine a PRACH parameter (e.g. WTRU ID).

A WTRU may determine a linkage or relationship between a preamble transmission and a configured grant resource based on a timing between the preamble transmission and the configured grant resource. For example, a WTRU transmitting a preamble at time x, may transmit on a first configured grant resource available after time x+t, where t may be configurable and may be provided by a gNB or may be determined by the WTRU as a function of WTRU capability.

A WTRU may determine a linkage between a preamble transmission and a configured grant resource based on a linkage to the preamble resource. For example, a WTRU may determine a configured grant resource based on the resource used to transmit the PRACH.

A WTRU may determine a linkage between a preamble transmission and a configured grant resource based on linkage to the preamble sequence. For example, a WTRU may determine a configured grant resource as a function of the selected PRACH preamble.

A WTRU may determine a linkage between a preamble transmission and a configured grant resource based on a synchronization signal block (SSB) measurement. For example, a WTRU may determine a configured grant resource based on at least one SSB measurement. This may enable the WTRU to use the appropriate configured grant that uses a same beam as that of the SSB.

A WTRU may determine a linkage between a preamble transmission and a configured grant resource based on a parameter of a PUSCH transmission. For example, different configured grants may enable different transport block sizes. The WTRU may select a configured grant resource that best matches its required transport block size. In another example, a WTRU may select a specific configured grant based on a low code rate spreading (LCRS) sequence or a DM-RS.

A WTRU may determine a linkage between a preamble transmission and a configured grant resource based on a parameter of a PRACH transmission. For example, depending on the number of PRACH retransmissions, the WTRU may select a specific configured grant resource.

A WTRU may determine a linkage between a preamble transmission and a configured grant resource based on BWP. For example, depending on a BWP used for the transmission of a preamble, the WTRU may select a specific configured grant.

A WTRU may determine a linkage between a preamble transmission and a configured grant resource based on a need for a future transmission. In an embodiment, a <NUM>-Step RACH procedure may enable a WTRU to transmit all the data it has in its buffer, whereas in another embodiment, the WTRU may require future resources to empty its buffer. A WTRU may select a configured grant resource depending on whether the <NUM>-Step RACH procedure is sufficient or whether future scheduling is required.

A WTRU, such as a Rel-<NUM> low code rate spreading (LCRS) WTRU, may scramble its bits with a WTRU-specific identity. <FIG> shows an example of using a bit sequence scrambled with a scrambling sequence which may be calculated based on the WTRU-specific identity. In Rel-<NUM>, a scrambling sequence generator may be initialized according to 3GPP TS <NUM>, section <NUM>. <NUM>: cinit = nRNTI · <NUM><NUM> + nID where nRNTI is the RNTI associated with the PUSCH transmission and <MAT> in a PRACH transmission.

A Rel-<NUM> RA-RNTI may be calculated as: RA-RNTI= <NUM> + s_id + <NUM> × t_id + <NUM> × <NUM> × f_id + <NUM> × <NUM> × <NUM> × ul_carrier_id where s_id, t_id, f id, and ul_carrier_id are preconfigured parameters, where s_id is the index of the first OFDM symbol of the PRACH occasion (<NUM> ≤ s_id < <NUM>), t_id is the index of the first slot of the PRACH occasion in a system frame (<NUM> ≤ t_id < <NUM>), f_id is the index of the PRACH occasion in the frequency domain (<NUM> ≤ Lid < <NUM>), and ul_carrier_id is the UL carrier used for Random Access Preamble transmission (<NUM> for NUL carrier, and <NUM> for SUL carrier.

The RA-RNTI may be preconfigured during initial access as part of a SIB RACH configuration or it may be semi-statically RRC reconfigured. The RA-RNTI may be common to multiple preambles configured to the same PRACH transmission opportunity.

When initiating a PRACH, a WTRU may not have a WTRU-specific identity configured. A WTRU may only be configured with a RA-RNTI. Enhancements may be needed in <NUM>-step RACH such that a preamble may be used to partially or fully determine the WTRU-specific identity used for the scrambling in the UL-SCH processing chain and for transmitting a PUSCH.

In an embodiment, for <NUM>-step RACH operation, a WTRU may be configured with a unique RNTI, such as 2RA-RNTI. The 2RA-RNTI is to be considered as a WTRU-ID and is used for data and CRC scrambling. The 2RA-RNTI may be configured to a subset of WTRUs based on, for example, a service type, a measurement. In an embodiment, a WTRU may choose an RNTI based on the RA-RNTI as the nRNTI for the UL-SCH scrambling and the UE may link nRNTI to the preamble selection.

Each preamble may be associated with a different or a common RNTI which may be based on the RA-RNTI. The RNTI used for scrambling may be configured based in part or completely on the preamble in one of several ways.

The RNTI used for scrambling is configured based on a PRACH transmission opportunity. Each preamble may be configured to different PRACH transmission opportunities yielding different RA-RNTIs. A WTRU may randomly choose a preamble and may calculate an RA-RNTI to which it is uniquely associated. For example, one preamble may be associated with PRACH transmission opportunity <NUM> and another preamble may be associated with PRACH transmission opportunity <NUM>. The RA-RNTIs calculated for each PRACH transmission opportunity may be different and may be used as a multiple access signature.

The RNTI used for scrambling may be configured based on a preamble index. A modified RNTI may be used which may be made up of two parts. One part may be a common RA-RNTI used for a group of N preambles multiplexed in a same PRACH transmission opportunity. The second part may be the preamble identity within the group. A WTRU may choose (e.g. randomly) one out of N preambles within a group. The WTRU may calculate a common RA-RNTI for the PRACH opportunity configured for the group. For example, as shown in <FIG>, a WTRU initializes its scrambler as a function of RA-RNTI and a selected preamble index (Pi) (e.g., RA-RNTI+Pi). A gNB may detect the preamble (Pi) within a PRACH transmission opportunity and may unscramble the WTRU's data by determining the scrambler's initial seed based on a function (e.g., RA-RNTI+Pi).

In an embodiment, scrambling may be determined using a WTRU-specific interleaver. WTRU-specific interleavers may be obtained based on a detected preamble index. For example, cyclically shifting the interleaved bit sequence based on the preamble index may have the same effect as applying a WTRU-specific scrambler. The gNB may deinterleave the WTRU's data based on the detected preamble index.

Preamble collisions may occur when more than one WTRU randomly selects the same preamble which may lead to multiple WTRUs selecting the same WTRU-ID. To enable a gNB to successfully detect data, additional enhancements to the link between a preamble and WTRU-ID may be considered to reduce the probability of failed detections due to preamble collision. Assuming WTRUs transmit on overlapping PUSCH resources, the association between preambles and WTRU-IDs may be enhanced in the following ways.

In an embodiment, as shown in <FIG>, multiple WTRU-IDs may be associated to one preamble. A WTRU may randomly select a preamble (<NUM>). The preamble may be linked to a subset or to an entire set of available WTRU-IDs. The preamble selection may trigger a WTRU-ID selection. The WTRU may select (e.g. randomly) one or several WTRUs-IDs from the subset (<NUM>). The WTRU may transmit the selected preamble and scramble using the selected WTRU-ID (<NUM>). The gNB may detect the preamble and may infer that the WTRU-ID used is one from the linked subset. All WTRU-IDs used with the associated preamble may be used to transmit on the shared PUSCH resources.

In an embodiment, multiple preambles may be linked to a subset of WTRU-IDs. Multiple WTRUs may select a same or different preambles and the preambles may be associated to a common subset of WTRU-IDs. After selecting one of the preambles, a WTRU may select one of the WTRU-IDs from the common subset. All WTRU-IDs configured in the subset may be used to transmit on an overlapping set of shared PUSCH resources.

Multilayer LCRS transmissions may be enabled in the UL-SCH processing chain by splitting the raw bitstream into L layers and performing scrambling on each layer. One specific scrambling sequence may be used per layer. <NUM>, a WTRU may only use one WTRU-ID to scramble a PUSCH. However, for multilayer transmission, a WTRU may use multiple WTRU-IDs where each WTRU-ID may correspond to one layer. With a msgA preamble and payload transmission, a WTRU may select a preamble and may need to generate multiple WTRU-IDs. Enhancements may be needed to allow a WTRU to link multiple WTRU-IDs to one PUSCH transmission.

In an embodiment, a WTRU may select multiple WTRU-IDs based on a preamble and simultaneously use multiple WTRU-IDs in multilayer transmission (e.g. LCRS). For example, a set of preambles may be partitioned into groups depending on a number of layers and WTRU-IDs may be assigned to each group. As shown in <FIG>, for L layer transmission, one preamble may be associated with L WTRU-IDs. A WTRU may choose one preamble and may use the L associated WTRU-IDs to perform multilayer transmission. In an embodiment, the group for L layers may comprise more than L WTRU-IDs and the WTRU may choose L out of a total number of available WTRU-IDs. A gNB may detect the preamble and may implicitly determine that L layers are transmitted based on the group containing the preamble index.

In an embodiment, a WTRU may choose one WTRU-ID and determine the L-<NUM> other WTRU-IDs as a function of the first WTRU-ID. A predetermined function may be configured during RACH parameter configuration such that the WTRU may derive the L-<NUM> WTRU-IDs relative to the first one determined by the preamble. For example, a WTRU may choose one WTRU-ID based on the preamble and may compute L-<NUM> other WTRU-IDs such as WTRU-ID + <NUM>, WTRU-ID + <NUM>,. WTRU-ID + L - <NUM>. Other functions may be used to determine the L WTRU-IDs in a sequential or distributed manner.

In an embodiment, the number of layers and the WTRU-ID determination may be linked to DMRS selection. One DMRS may be mapped to multiple WTRU-IDs during RACH configuration. The number of WTRU-IDs associated with each DMRS may depend on the number of layers such that one DMRS may map to L WTRU-IDs. For example, a WTRU may randomly select a preamble to which a set of DMRS is linked. For an L layer transmission, the WTRU may select the DMRS linked to L WTRU-IDs. A gNB may detect the preamble and the DMRS index. Based on the DMRS index, the gNB may implicitly determine that the WTRU used L layers with corresponding WTRU-IDs. For example, the WTRU-IDs for the L layers may be based on the RA-RNTI+preamble index+DMRS index+L.

In an embodiment, DMRS configuration may be linked to a selected preamble. A DMRS configuration may be characterized with its time and frequency density, pattern, sequence and its scrambling mechanism.

In an embodiment, a preamble set may be partitioned in several groups based on channel dispersity in time and frequency, where each partition may be linked to a specific DMRS pattern with proper density and pattern. In an embodiment, a WTRU may select a preamble based on its estimate of the uplink channel. The WTRU may adopt a DMRS definition according to its selected preamble.

As part of a <NUM>-Step RACH procedure, a WTRU may select preamble and PUSCH resources. In addition, a WTRU may also require a DMRS port to assist a gNB in decoding the payload portion of msgA. A WTRU may select a DMRS port which may be generated for example according to Rel. <NUM>, a DMRS for a PUSCH is initialized using a random sequence which is generated with an initial seed cinit according to <NUM><NUM>. <NUM>:
<MAT>
where <MAT> is the number of symbols per slot, <MAT> is the slot number s within a frame f for subcarrier spacing µ, and l is the OFDM symbol number within the slot. <MAT> and nSCID represent the scrambling identity and may be configured to generate the DMRS sequence corresponding to a PUSCH transmission. Without an RRC configuration and without a configured grant or without a DCI to schedule the PUSCH, <MAT>. This may be the case when a WTRU is in IDLE mode and initiates a <NUM>-Step RACH procedure. The IDLE WTRUs within the cell may use the same scrambling identity to generate their DMRS sequences. A DMRS collision may occur if multiple WTRUs select a same DMRS port generated from a same sequence and map to the same physical resources. Enhancements may be needed to allow the IDLE WTRUs to generate their own DMRS sequences.

In an embodiment, a WTRU may determine <MAT> according to a mapping based on a preamble index. The mapping may be configured during initial access with RACH parameter configuration. A preamble may determine a scrambling identity by mapping to a set of valid values. For example, a gNB may preconfigure a one-to-one mapping between <MAT> and preambles. Each preamble choice may determine a DMRS sequence.

In an embodiment, multiple preambles may map to a scrambling identity. A unique scrambling identity may be derived as a function of a preamble, DMRS index and the common scrambling identity. For example, the scrambling identity may comprise of one part with a common value such as the RA-RNTI or a predefined set of values and another part such as preamble index or DMRS index.

In an embodiment, a preamble may be mapped to a set containing multiple <MAT>. If multiple WTRUs select a same preamble, they may randomly pick one value from the set of corresponding <MAT>. Multiple WTRUs may be able to generate different DMRS sequences even if they choose the same preamble.

Multiple WTRUs may randomly select a same preamble when multiple preambles are mapped to one DMRS sequence. The preamble may not be sufficient to generate a WTRU-specific DMRS sequence since the DMRS sequence may be generated similarly for multiple WTRUs with a scrambling identity initialized using <MAT>. <MAT> may be a preconfigured common value which may be shared by multiple WTRUs. A collision may occur if the same DMRS sequence is used with the same port by multiple WTRUs.

In an embodiment, a WTRU may generate a DMRS sequence based on a preamble and may select (e.g. randomly) a DMRS port. A DMRS port selection may be randomized and taken from a set of available ports that may be preconfigured with the RACH configuration during initial access. A WTRU may randomly choose a DMRS port to transmit and reduce the chance of a collision even if the same DMRS scrambling identity is used. Additionally, if multiple WTRUs share a same PUSCH resources, the DMRS scrambling identity may be used along with the port number to generate the scrambler for the UL-DSCH. For example, a WTRU may select a preamble and generate a DMRS sequence based on the preamble. The WTRU may choose an antenna port. The scrambler used for the UL-SCH may be for example <MAT> index. Multiple WTRUs may transmit with a same DMRS sequence on different ports with a PUSCH scrambled WTRU-ID based on the DMRS sequence associated to multiple preambles and the port numbers chosen by each WTRU. The receiver may decode the PUSCH based on the preamble index which may map to a DMRS sequence and to the port number which initializes the PUSCH scrambling.

The DMRS scrambling identity may be generated based on a preamble and port selection. In the event that multiple WTRUs select the same ports, different preambles may generate different scrambling identities for the DMRS, as shown <FIG>. A WTRU may choose a preamble (preamble n) from a pool of available preambles (<NUM>). The WTRU may choose a DMRS port (DMRS port k) from a pool of available DMRS ports (<NUM>). The WTRU may generate a DMRS sequence which may take as inputs preamble n and DMRS port k from which a sequence initialization value is calculated (<NUM>). The DMRS sequence may be generated as a function of (n,k). The pair (n,k) may be preconfigured to map to a set of <MAT> values from which the WTRU may randomly choose one <MAT> from the set. The <MAT> may be uniquely determined as a function of (n,k). For example, the identity may be computed based on a predetermined function of n and k.

In <NUM>-Step RACH, msgA may be expected to carry a random access preamble (msg1) and a RRC connection request (msg3). However, the RRC connection request may need to be transmitted on a PUSCH. Compared to <NUM>-Step RACH where the information regarding the PUSCH is transmitted on a RAR uplink grant as part of msg2, in <NUM>-Step RACH, a gNB may not be able to dynamically provide such information.

In an embodiment, the WTRU may use an uplink configured grant for transmission of the data part of msgA (e.g., RRC connection request). The WTRU may semi-statically be configured with one or more RAR uplink grants by higher layers on a licensed or unlicensed band. The WTRU may select one of the configured uplink grants for transmission of msgA on a PUSCH based on one or more combination of the following parameters.

A parameter may be a listen before talk (LBT) category for PUSCH transmission in an unlicensed band. In an example, if the LBT category for transmission of msgA is <NUM> or <NUM>, then it may mean that the WTRU may almost immediately transmit the PUSCH so the WTRU may need to select a configured PUSCH resource allocation which has a longer duration without any restriction on a starting symbol. In an example, if a LBT category <NUM> is needed for transmission of msgA, then the WTRU may use a configured PUSCH resource allocation where the start symbol is later in the slot and the length of PUSCH is shorter.

A parameter may be Channel Occupancy Time (COT) attributes in an unlicensed band (e.g., COT length, COT starting OFDM symbol, COT last OFDM symbol). In an example, if msgA is expected to be transmitted toward the end of the COT, then the WTRU may need to select a configured PUSCH resource allocation with the appropriate length which is aligned with the COT last OFDM symbol.

Other parameters may include: configured PUSCH start symbol and length; configured PUSCH mapping type; configured PUSCH frequency domain resource allocation; configured Modulation and Coding scheme; configured number of DM-RS CDM groups and DM-RS ports for the configured PUSCH; configured number of repetitions to be applied to the transmitted transport block on the configured PUSCH (for example, in the unlicensed bands, the COT duration could be 5msec or 10msec and each slot may be 1msec for <NUM> subcarrier spacing, then the WTRU may need to select a configured uplink grant where the number of repetitions are less than or equal a maximum length of COT (e.g., between <NUM> to <NUM>)); uplink measurements (e.g., L1-RSRP, RLM, RSRP, RSRQ); and channel sensing at the WTRU side.

In an embodiment, a WTRU may be semi-statically configured by a higher layer parameter, for example a configured RAR grant configuration (configuredRARGrantConfig) parameter. The following are examples of higher layer parameters that may be applied by the WTRU for a PUSCH transmission corresponding to msgA: frequency hopping flag; PUSCH frequency resource allocation; PUSCH time resource allocation; Modulation and Coding scheme; and TPC command for PUSCH.

A WTRU may be configured to transmit a PUSCH carrying msgA with repetitions. In this case, the WTRU may also be provided with a redundancy version pattern to be applied to the PUSCH repetitions carrying msgA. A configured RV sequence for msgA repetitions may be {<NUM>,<NUM>,<NUM>,<NUM>},{<NUM>,<NUM>,<NUM>,<NUM>}, or {<NUM>,<NUM>,<NUM>,<NUM>}. If the WTRU is configured to transmit the PUSCH carrying msgA without repetitions, then the WTRU may use the redundancy version <NUM> for the PUSCH transmission carrying msgA.

In an embodiment, in case msgA is transmitted with HARQ enabled, the WTRU may include one or a combination of the following information in a PUSCH carrying msgA to assist a gNB with the msgA detection: new data indicator (NDI); HARQ ID; redundancy version (RV); WTRU ID; COT sharing information (e.g., for the unlicensed band).

A WTRU may determine a parameter of a PUSCH transmission based on a measurement performed. The measurement may be performed prior to a transmission of the preamble and/or a PUSCH of msgA. The parameter of the PUSCH transmission may include at least one of: MCS, uplink power control (e.g. an initial offset value); precoding; analog beam; time location; frequency resource; LBT used (i.e. for an unlicensed channel access).

The measurement may include at least one of: SSB and/or DM-RS and/or CSI-RS measurements; LBT performance (for example, based on the number of failed LBTs prior to a successful LBT the WTRU may determine different PUSCH transmission parameters); channel occupancy (CO) or RSSI (this may enable better performance in unlicensed channels); RRM measurements (RSRP, RSRQ, SINR); RLM results (for example, for random access triggered by RLM, the parameters of the RLM may affect parameters of a future MsgA PUSCH); path loss.

In an embodiment, a WTRU may measure multiple CSI-RS prior to transmitting at least a PUSCH portion of msgA. The WTRU may determine a beam to transmit on based on at least one CSI-RS measurement. The WTRU may determine resources on which to transmit a PUSCH based on the selection of the beam. The WTRU may construct the transport block based on the outcome of such measurement process in order to enable refinement of at least the MCS to best match the channel conditions on the selected beam.

In an embodiment, a WTRU may determine a parameter of a PUSCH transmission based on a previous use of such a parameter for a previous transmission of a PUSCH on a same channel. In an embodiment, the parameter of the PUSCH may depend on a parameter of the preamble. For example, a power of the PUSCH transmission may be determined as a function of a power used for the preamble.

For a retransmission a WTRU may adapt at least one parameter of the preamble and/or PUSCH. The WTRU may behave differently depending on whether the WTRU is required to retransmit the preamble, the PUSCH, or both the preamble and the PUSCH.

In an embodiment where both a preamble and a PUSCH are to be retransmitted, the WTRU may use power ramping for the preamble and may maintain an association between the power of the preamble and the PUSCH (e.g. it may increase the power of the PUSCH as well). The WTRU may keep or modify other parameters of the PUSCH as well. For example, the WTRU may modify the MCS level which may improve PUSCH robustness.

In an embodiment, a WTRU may increment a power level of a preamble and not change a power of a PUSCH transmission. In an embodiment, the WTRU may maintain two separate uplink power control processes: one for the preamble and another one for the PUSCH. The WTRU may receive msgB indicating how to increment the separate uplink power control processes.

For a retransmission, a resource of the PUSCH may be modified such that an association with the resources of the preamble may not be maintained per retransmission.

In an embodiment where only a PUSCH is to be transmitted, a WTRU may be indicated to increase uplink power by closed loop power control. In an embodiment, the WTRU may independently increment a power of the PUSCH transmission (e.g. determined as a function of a number of retransmissions of msgA PUSCH). In an embodiment, the WTRU may reduce the MCS for each retransmission. In an embodiment, the WTRU may first increase a power, while keeping an MCS constant and upon reaching a maximum power may begin reducing MCS levels for subsequent retransmissions. In an embodiment, the WTRU may first reduce an MCS level, and upon reaching a minimum value, which may be configurable, the WTRU may begin incrementing uplink power for subsequent retransmissions.

In an embodiment where only a preamble is to be retransmitted, a WTRU may use power ramping for the preamble. The WTRU may perform virtual link adaptation on a PUSCH such that at a future time when a PUSCH is to be transmitted, the WTRU may determine a new value of uplink power and/or MCS as a function of a number of times the preamble was retransmitted (with or without PUSCH).

A preamble may be linked to multiple PUSCH resources. A WTRU may choose to transmit on a subset of available PUSCH resources and the WTRU may choose different transmission parameters. A subset of PUSCH resources may comprise one, multiple, or all RBs from the PUSCH resources. The resources may be located in different time/frequency regions as configured in the PUSCH transmission occasion. Since msgA may be transmitted without a resource assignment from the gNB, the WTRU may choose PUSCH resources from the configured PUSCH occasion. However, the gNB may not be aware of the WTRU's choice of PUSCH transmission parameters. The WTRU may need to signal to the gNB a location of resources for decoding to take place.

In an embodiment, a DMRS sequence or port may be linked to a configuration of PUSCH resources. The link may be preconfigured during initial access such that a DMRS sequence index or port may uniquely determine a set of PUSCH parameters. A gNB may implicitly determine a time and frequency location of PUSCH resources based on the DMRS sequence used. A DMRS sequence may be associated with a set of time and frequency offsets with respect to a preamble from which the PUSCH resource locations and quantity are determined.

In an embodiment, a WTRU may change a DMRS sequence or port to signal a change in transmission parameters. For example, in a situation where msgA fails, a WTRU may retransmit msgA with a different coding rate or with different PUSCH resources. The location of the PUSCH resources may be different than the initial transmission to accommodate a different coding rate or the additional PUSCH resources. After receiving the gNB's response to a msgA transmission failure, the WTRU may keep or change its DMRS sequence or port.

If a WTRU reuses, for the retransmission, a same DMRS sequence or port as an initial or previous transmission, the WTRU may implicitly signal to the gNB that the same transmission parameters for the PUSCH are reused. The gNB may determine that the retransmission occurs on a same part of the bandwidth as the initial transmission. If a different DMRS sequence or port is used for the retransmission, the location and number of resources used for the retransmission may be derived based on the choice of DMRS sequence or port and its associated PUSCH parameter list.

A WTRU may perform measurements on one or more received downlink synchronization signal blocks (SSBs). The WTRU may use the measurements in determining a beam or spatial filter to use for transmitting a msgA preamble. For a msgA PUSCH transmission, the WTRU may use a same beam or a same spatial filter used for the msgA preamble transmission. A gNB may use energy detection in receiving a msgA preamble and may use demodulation or decoding in receiving a msgA PUSCH payload. A beam that may be sufficient for a msgA preamble transmission may not be sufficient for a msgA PUSCH transmission. The msgA PUSCH transmission may require a higher signal to noise ratio (SNR) than for the msgA preamble transmission. A failure in a msgA PUSCH detection by a gNB may result in a WTRU retransmitting both the preamble part and the PUSCH part of a msgA, which may increase latency and delay. A WTRU may use a beam refinement procedure to refine a beam to use for a msgA PUSCH transmission, which may increase signal reception.

<FIG> shows an example beam refinement procedure. The beam refinement procedure may be in a context of a <NUM>-step RACH procedure where a WTRU may transmit a first message (e.g. msgA) that may comprise a preamble and a PUSCH payload.

A WTRU may receive configuration information (<NUM>). The configuration information may be received from a gNB. The configuration information may comprise an association between preambles and SSBs. The configuration information may comprise an association between preambles, references signal (RS) sets, and PUSCH resources. A reference signal may be, for example, a phase tracking reference signal (PTRS), a channel state information-reference signal (CSI-RS), or a demodulation reference signal (DMRS).

The WTRU may receive a plurality of SSBs (<NUM>). Each SSB may be transmitted on its own beam. Each SSB may be transmitted over a period of time from a same cell. The WTRU may perform measurements on the received SSBs (<NUM>). For example, the WTRU may measure a reference signal received power (RSRP). The WTRU may select an SSB (<NUM>). The SSB selected may be based on the measurement. For example, the WTRU may select an SSB with an RSRP greater than a threshold value. The WTRU may receive the threshold value as part of an initial access, for example in a system information block (SIB). As another example, the WTRU may select an SSB with the highest RSRP. The WTRU may select a preamble (<NUM>). The preamble may be selected based on the configuration information received from the gNB such that the preamble selected is associated with the selected SSB. The WTRU may transmit the selected preamble to the gNB using a first beam (<NUM>). The first beam may be a coarse or wide beam. The first beam may be the same beam that the selected SSB was received on. The gNB may receive and detect the preamble and select a RS to send to the WTRU that are associated with the preamble. The transmission of the preamble to the gNB may trigger the gNB to determine a set of RSs and to transmit the RSs to the WTRU to be used for beam refinement.

The WTRU may determine resources for receiving reference signals in response to transmitting the preamble (<NUM>). The WTRU may assume reception of K set of reference signals with K different narrow beams.

The WTRU may determine the resources for receiving the reference signals based on a parameter of an associated SSB. For example, depending on the SSB selected for the first beam, the WTRU may expect the presence of RS signals using resources associated to the selected SSB. The WTRU may expect different parameters of the RS to be associated to the SSB resource (e.g. sequence, transmit power, etc.).

The WTRU may determine the resources for receiving reference signals based on a parameter associated with the preamble transmission. For example, the resource used for the preamble transmission or the preamble sequence may be associated to a set of resources or set of RS parameters.

The WTRU may determine the resources for receiving reference signals be based on a parameter indicated in a broadcast message. For example, a PBCH may provide the resources on which the WTRU may expect reception of a RS.

The WTRU may determine the resources for receiving reference signals based on a WTRU specific configuration. For example, for CONNECTED mode WTRUs, a WTRU may be configured with resources on which to expect RS transmission.

The WTRU may receive one or more sets of RSs from the gNB (<NUM>). The set of RSs received may be associated with the transmitted preamble. The WTRU may receive K sets of RSs on K different narrow beams. Each of the K sets of RSs may be associated with PUSCH resources. The associated may be implicit, explicit, semi-statically, or dynamically configured. For example, the configuration information received by the WTRU may indicate the association between sets of RSs and PUSCH resources. The WTRU may perform measurements on the received set of RSs (<NUM>). The WTRU may select a RS (<NUM>). The selection may be based on the measurement performed. For example, the WTRU may select a RS with a highest RSRP or may select a RS with a RSRP greater than a threshold value. The WTRU may receive the threshold value as part of an initial access, for example in a system information block (SIB). The WTRU may assume that the set of RSs used for beam refinement are quasi co-located (QCL-ed) with an SSB. The WTRU may use a set of RSs that are not QCL-ed with the SSB. The WTRU may indicate its use of non-QCL-ed reference signals to a gNB to assist gNB reception. Based on the selection of the RS, the WTRU may select a second (narrow) beam to transmit a PUSCH payload. The WTRU may determine resources or other parameters associated with the PUSCH payload transmission. The WTRU may transmit uplink data on a PUSCH (<NUM>). The PUSCH may be transmitted on PUSCH resources that are associated with the selected RS. The PUSCH may be transmitted using the second (narrow) beam (or spatial filter) that is associated with the selected RS. The second beam may be the same beam that was used to receive the selected RS.

A WTRU may not receive a RS for beam refinement prior to transmission of a PUSCH payload. In such a case, the WTRU may indicate such to the gNB. The indication may be done implicitly based on the resource used to transmit the PUSCH. Failure to receive a beam refinement RS may cause the WTRU to retransmit the preamble. In such a case, the transmission power may be ramped up.

In an embodiment, an always on reference signal (RS) may be used for beam refinement. For example, a gNB may configure a set of periodic RSs (e.g. CSI-RS, PTRS) where each RS may be associated with a different spatial filter supporting different beams. A WTRU may perform measurements (e.g. RSRP) at any time on an always on RS to refine its beam selection. An always on signal may generate inter-cell interference because it is constantly broadcasted. It may also require reserving dedicated time/frequency resources in slots which may result in a large amount of overhead. A configured RS set (RSS) may be configured with a time offset relative to a RACH occasion (RO). In an embodiment, an RSS may be configured with a small time offset to occur prior to a RO which may allow sufficient time for a WTRU to perform beam measurement and adjustment.

In an embodiment, RS sets (RSSs) may be associated to one or more subsets of ROs through a PRACH configuration. For example, configured RSSs may have a same or a lower periodicity compared to a RO. A configuration of the RSSs may be provided with a RACH configuration in a SIB during initial access. For example, a WTRU in IDLE mode may have an option to wait for a RO that is supported by a configured RSS. An IDLE mode WTRU may refresh its RS selection based on the configured RSSs without having to request the RS transmission.

A WTRU in CONNECTED mode may benefit from a configured RS for beam refinement. A WTRU may determine the configuration of RSs associated to ROs from the TCI states of the configured bandwidth part.

The RSSs configuration may be associated with respect to a RACH configuration with a different periodicity. For example, a duty period of the RSSs may be flexibly configured to enable RSSs to be transmitted with every X RACH occasion. The RS transmission may be configured with a time hopping pattern corresponding to Y% of RACH occasions within a time period.

The RSSs configuration may be associated with respect to the RACH configuration with a different frequency granularity. For example, within a one time instance, there may be multiple ROs located in different PRBs. The RSSs may be transmitted every X PRBs. The RS transmission may be configured with a frequency hopping pattern corresponding to Y% of PRBs within a time instant.

The RSSs configuration may be associated with respect to a RACH configuration with a combination of different time and frequency parameters. For example, the configuration may be jointly such that X PRBs are occupied within Ytime instants.

<FIG> shows an example of beam refinement. A WTRU may receive configuration information (<NUM>). The configuration may be received from a gNB. The configuration information may be a PRACH configuration. The configuration information may indicate an association between SSBs and ROs. The configuration information may indicate an association between configured RSSs and ROs. A WTRU may receive SSBs and RSSs associated with RO #<NUM> and RO #<NUM> (<NUM>). The WTRU may receive the SSBs and RSSs from the gNB. In the example of <FIG>, <NUM> SSBs are configured with one RO linked per SSB. The ROs may be configured in a TDM manner. The RSSs in <FIG> are configured for RO #<NUM> and RO #<NUM> to provide some resources for WTRUs which require more beam choices. For the other ROs, only SSBs are transmitted. The RSSs allow the gNB to provide different beams with the RSS compared to SSB (e.g. narrower or more numerous).

The WTRU may wake up before a RO where only SSBs are available with no RSS (<NUM>). Based on the RSS configuration, the WTRU may determine that it may wait until RO #<NUM> to receive RSS which may provide alternative beam choices. The WTRU may decide to wait based on an expired timer since a last beam selection or based on an inadequate SSB beam quality measurement. The WTRU may perform measurements on the RSSs and may determine the best RS based on signal quality (e.g. RSRP) (<NUM>). As part of the RACH configuration, the RSSs may be associated to preambles within the corresponding RACH occasion. The WTRU may send a preamble (e.g. msgA preamble) corresponding to a best measured RS followed by a PUSCH payload (e.g. msgA PUSCH payload) (<NUM>). The gNB may receive msgA and may adjust its spatial transmission filter corresponding to the RSS linked to the detected preamble index. The gNB may send a msgB reply to the WTRU using an adjusted spatial transmission filter. The WTRU may monitor for a msgB response. The msgB response may be scheduled on resources identified by a PDCCH addressed to the WTRU's identity, or on resources that are linked to the RSS. The WTRU may receive the response (e.g. msgB response) based on the adjusted spatial transmission filter (<NUM>).

Claim 1:
A wireless transmit/receive unit (WTRU) configured to perform a <NUM>-step random access channel (RACH) procedure, the WTRU comprising:
a transceiver; and
a processor, wherein:
the processor is configured to select a random access preamble having a preamble index;
the processor is further configured to determine a scrambling sequence for a physical uplink shared channel (PUSCH) transmission, wherein the scrambling sequence is based on a random access - radio network temporary identifier (RA-RNTI) and the preamble index; and
the transceiver is configured to send a message to a network node, wherein the message comprises the selected random access preamble and the PUSCH transmission, wherein the PUSCH transmission is scrambled with the determined scrambling sequence that is based on the RA-RNTI and the preamble index.