WTRU and method used in WTRU

Abstract

The invention discloses a WTRU and a method used in the WTRU. A wireless transmit / receive unit (WTRU) may be configured to receive configuration information. The configuration information may indicate an association between a preamble, a synchronization signal block (SSB), a reference signal (RS) set, and a physical uplink shared channel (PUSCH) resource. The WTRU may be configured to receive a plurality of SSBs, determine a measurement of the received SSBs, and select an SSB based on the determined measurement. The WTRU may be configured to select and transmit a preamble using a first beam. The WTRU may be configured to receive a plurality of RS sets based on the transmitted preamble, and determine measurements for the received RS sets. The WTRU may be configured to select an RS based on the determined measurements of the received set of RSs. The WTRU may be configured to transmit uplink data on the PUSCH using a second beam.

Description

[0001] This case is a divisional application of Chinese invention patent application 202080026343.9, entitled “Method and device for msg-A transmission in two-step RACH”, filed on February 11, 2020.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. Provisional Application No. 62 / 805,079, filed February 13, 2019; U.S. Provisional Application No. 62 / 824,715, filed March 27, 2019; U.S. Provisional Application No. 62 / 840,698, filed April 30, 2019; and U.S. Provisional Application No. 62 / 908,878, filed October 1, 2019, the contents of which are incorporated herein by reference Background Art

[0004] In Release 15 of New Radio (NR), a 4-step Random Access Channel (RACH) procedure is supported on the uplink. There are several triggers to initiate the RACH procedure, such as synchronization acquisition and handover. The 2-step RACH procedure is being studied as an alternative to the 4-step RACH procedure, and the 2-step RACH can be used in situations such as those that require low latency. At RAN Plenary Meeting #82, NR approved a work item for contention-based 2-step RACH. Summary of the invention

[0005] Methods and apparatus for beam refinement are disclosed. In one embodiment, a wireless transmit / receive unit (WTRU) may be configured to receive configuration information. The configuration information may indicate an association between a preamble and a synchronization signal block (SSB). The configuration information may indicate an association between a preamble, a reference signal (RS) set, and a physical uplink shared channel (PUSCH) resource. The WTRU may be configured to receive multiple SSBs. The WTRU may be configured to determine a measurement of the received SSB. The WTRU may be configured to select an SSB based on the determined measurement of the received SSB. The WTRU may be configured to select a preamble. The WTRU may be configured to transmit the selected preamble using a first beam. The WTRU may be configured to receive multiple RS sets based on the transmitted preamble. The WTRU may be configured to determine a measurement of the received RS set. The WTRU may be configured to select an RS based on the determined measurement of the received RS set. The WTRU may be configured to transmit uplink data on the PUSCH using a second beam. Each SSB may correspond to a beam. The SSB with the highest reference signal received power (RSRP) may be selected. The selected preamble may be a preamble associated with the selected SSB. The PUSCH transmission may be scrambled with a WTRU identity. The WTRU identity may be based on a common random access radio network temporary identifier (RA-RNTI) and a preamble index. The WTRU may be configured to determine resources for receiving the multiple RS sets in response to the transmitted preamble. The received multiple RS sets may be associated with the transmitted preamble. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The present invention may be understood in more detail from the following description given by way of example in conjunction with the accompanying drawings, in which like reference numerals represent like elements, and in which:

[0007] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented;

[0008] Figure 1B It is shown that according to the embodiment, Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used in a communication system is shown;

[0009] Figure 1C It is shown that according to the embodiment, Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) used within a communication system as shown in FIG.

[0010] Figure 1D It is shown that according to the embodiment, Figure 1AA system diagram of another example RAN and another example CN used within the communication system shown in;

[0011] Figure 2 is an example information exchange for a 4-step RACH procedure;

[0012] Figure 3 is an example information exchange for a 2-step RACH procedure;

[0013] Figure 4A is an example of the same mapping between preamble and PUSCH resources;

[0014] Figure 4B is an example of different mappings between preamble and PUSCH resources;

[0015] Figure 5 is an example of msgA transmission using multiple PUSCH resources;

[0016] Figure 6 is an example of WTRU selection of shared and non-shared resources;

[0017] Figure 7 is an example of a WTRU scrambling sequence based on a WTRU specific identity;

[0018] Figure 8 is an example of a WTRU-ID based on the RA-RNTI and the preamble index;

[0019] Fig. 9 is an example of preamble and WTRU-ID selection;

[0020] Fig.10 is an example of multi-layer transmission;

[0021] Fig.11 is an example DMRS sequence generation;

[0022] Fig.12 is an exemplary beam refinement for PUSCH transmission for msgA; and

[0023] Fig.13 is an example of beam refinement. DETAILED DESCRIPTION

[0024] Figure 1A1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources including wireless bandwidth. For example, the communication system 100 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 DTS-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0025] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a CN 106, a public switched telephone network (PSTN) 108, the Internet 110 and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network components. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. 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 user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or MiFi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), consumer electronic devices, devices operating on a commercial and / or industrial wireless network, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0026] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device that is 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 106, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation Node B such as a gNode B (gNB), a New Radio (NR) Node B, a site controller, an access point (AP), a wireless router, and the like. While each of the base stations 114a, 114b is depicted as a single component, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network components.

[0027] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network components (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114a and / or the base station 114b may be configured to send and / or receive wireless signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Therefore, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology, and may use multiple transceivers for each sector of the cell. For example, beamforming may be used to send and / or receive signals in a desired spatial direction.

[0028] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d via an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0029] More specifically, as described above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​Uplink (UL) Packet Access (HSUPA).

[0030] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro).

[0031] In one 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 116 using NR.

[0032] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may together implement LTE radio access and NR radio access, for example using dual connectivity (DC) principles. Thus, the air interface used by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations, such as eNBs and gNBs.

[0033] In other embodiments, the base station 114a and the wireless transmit / receive units 102a, 102b, and 102c may implement wireless technologies, such as IEEE802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000EV-DO, International Standard 2000 (IS-2000), International Standard 95 (IS-95), International Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0034] Figure 1A The base station 114b in the example may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a residence, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. Figure 1A As shown, the base station 114b may be directly connected to the Internet 110. Therefore, the base station 114b may not need to access the Internet 110 via the CN 106.

[0035] The RAN 104 may be in communication with the CN 106, which may be any type of network that provides voice, data, applications, and / or voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions (e.g., user authentication). Although Figure 1AAlthough not shown in the figure, it will be appreciated that the RAN 104 and / or CN 106 may be in direct or indirect communication with other RANs that employ the same RAT or a different RAT as the RAN 104. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also be in communication with another RAN (not shown) employing GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0036] The CN 106 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may use the same RAT as the RAN 104 or a different RAT.

[0037] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114A, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0038] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0039] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0040] The transmit / receive component 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) via an air interface 116. For example, in one embodiment, the transmit / receive component 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive component 122 may be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive component 122 may be configured to transmit and / or receive both RF and optical signals. It should be understood that the transmit / receive component 122 may be configured to transmit and / or receive any combination of wireless signals.

[0041] Although the transmit / receive element 122 is Figure 1B Although depicted as a single component in the embodiment, the WTRU 102 may include any number of transmit / receive components 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive components 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0042] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11).

[0043] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keyboard 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keyboard 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0044] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0045] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more neighboring base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0046] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Module, FM radio unit, digital music player, media player, video game player module, Internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, etc. The peripheral device 138 may include one or more sensors. The sensor may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, etc.

[0047] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., signals associated with particular subframes for UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. A full-duplex radio may include an interference management unit that reduces and / or substantially eliminates self-interference by means of hardware (e.g., chokes) or by signal processing by a processor (e.g., a separate processor (not shown) or by the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio that transmits and receives some or all signals (e.g., signals associated with particular subframes for UL (e.g., for transmission) or DL ​​(e.g., for reception).

[0048] Figure 1C 1 is a system diagram showing the RAN 104 and the CN 106 in accordance with an embodiment. As described above, the RAN 104 may employ an E-UTRA radio technology and communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0049] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. Each of the eNode-Bs 160a, 160b, 160c may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0050] Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, etc. Figure 1C As shown in FIG. , the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0051] Figure 1C The CN 106 shown in FIG. 1 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. Although the foregoing components are depicted as part of the CN 106, it will be understood that any of these components may be owned and / or operated by an entity other than the CN operator.

[0052] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other wireless technologies, such as GSM and / or WCDMA.

[0053] The SGW 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during inter-eNode-B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the contexts of the WTRUs 102a, 102b, 102c, and the like.

[0054] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0055] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0056] Although the WTRU Figures 1A-1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may use (eg, temporarily or permanently) a wired communications interface with a communications network.

[0057] In a representative embodiment, other network 112 may be a WLAN.

[0058] A WLAN in an infrastructure basic service set (BSS) mode may have an access point (AP) for a BSS and one or more stations (STAs) associated with the AP. The AP may access or dock to a distribution system (DS) or send traffic into and / or out of another type of wired / wireless network carrying the BSS. Traffic initiated from outside the BSS and destined for the STA may be reached through the AP and may be delivered to the STA. Traffic initiated from the STA and destined for a destination outside the BSS may be sent to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP, and the AP may deliver traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. The point-to-point traffic may be sent between the source STA and the destination STA (e.g., directly between the source STA and the destination STA) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0059] When using the 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., a 20MHz wide bandwidth) or a width dynamically set via signaling. The primary channel can be a working channel of the BSS and can be used by the STA to establish a connection with the AP. In certain representative embodiments, such as in an 802.11 system, carrier sensing multiple access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, STAs including the AP (e.g., each STA) can sense the main channel. If the main channel is sensed / detected and / or determined to be busy by a specific STA, the specific STA can back off. One STA (e.g., only one station) can transmit at any given time in a given BSS.

[0060] A high throughput (HT) STA may communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with an adjacent or non-adjacent 20 MHz channel to form a 40 MHz wide channel.

[0061] Very high throughput (VHT) STA can support channels with a width of 20MHz, 40MHz, 80MHz and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. A 160MHz channel can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be subjected to inverse fast Fourier transform (IFFT) processing and time domain processing, respectively. The stream can be mapped onto two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the above 80+80 configuration can be opposite, and the combined data can be sent to the medium access control (MAC).

[0062] The operating mode below 1 GHz is supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to the channel operating bandwidth and carrier used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz and 20MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support metering type control / machine type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, for example, limited capabilities including support for certain and / or limited bandwidths (e.g., only support for certain and / or limited bandwidths). MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0063] A WLAN system that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) includes a channel that can be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA among all STAs operating in the BSS, and the STA supports the minimum bandwidth operating mode. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) a 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (which only supports a 1MHz operating mode) transmits to the AP, all available bands may be considered busy even if most of the available bands in the band remain idle.

[0064] In the United States, the available frequency band that 802.11ah can use is from 902MHz to 928MHz. In South Korea, the available frequency band is from 917.5MHz to 923.5MHz. In Japan, the available frequency band is from 916.5MHz to 927.5MHz. Depending on the country code, the total bandwidth available for 802.11ah is 6MHz to 26MHz.

[0065] Figure 1D1 is a system diagram showing the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using NR radio technology. The RAN 104 may also communicate with the CN 106.

[0066] The RAN 104 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with the embodiment. Each of the gNBs 180a, 180b, 180c may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In one embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation techniques. For example, the gNB 180a may transmit multiple component carriers (not shown) to the WTRU 102a. A subset of these component carriers may be on an unlicensed spectrum, while the remaining component carriers may be on a licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) techniques. For example, the WTRU 102a may receive coordinated transmissions from the gNB 180a and gNB 180b (and / or gNB 180c).

[0067] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable parameter configurations (numerology). For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0068] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without also accessing other RANs (e.g., the eNode-Bs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNBs 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more of the gNBs 180a, 180b, 180c and one or more of the eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-B 160a, 160b, 160c may serve as mobility anchor points for the WTRUs 102a, 102b, 102c and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0069] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support network slicing, interworking between DC, NR, and E-UTRA, route user plane data to a user plane function (UPF) 184a, 184b, route control plane information to an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

[0070] Figure 1DThe CN 106 shown in FIG. 1 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although the foregoing components are depicted as part of the CN 106, it will be understood that any of these components may be owned and / or operated by an entity other than the CN operator.

[0071] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, and the like. The AMF 182a, 182b may use network slicing to customize the CN support of the WTRU 102a, 102b, 102c according to the type of service used by the WTRU 102a, 102b, 102c. 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, etc. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and non-3GPP access technologies such as WiFi.

[0072] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 106 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 106 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b, and configure service routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy implementation and QoS, providing DL data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0073] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

[0074] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) or may communicate with an IP gateway that acts as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In an embodiment, the WTRUs 102a, 102b, 102c may be connected to the DNs 185a, 185b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b, and through the UPFs 184a, 184b.

[0075] Given that Figures 1A-1D and Figures 1A-1D In accordance with the corresponding description of the present invention, one or more or all of the functions described herein with respect to one or more of the following items may be performed by one or more simulation devices (not shown): WTRU 102a-d, base station 114a-b, eNodeB 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF184a-b, SMF 183a-b, DN185ab and / or any other device (one or more) described herein. The simulation device may be one or more devices configured to simulate one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0076] The simulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, one or more simulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can be directly coupled to another device for testing purposes and / or can perform tests using over-the-air wireless communications.

[0077] One or more simulation devices can perform one or more functions (including all functions) without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test lab and / or a non-deployed (e.g., testing) wired and / or wireless communication network to enable testing of one or more components. The one or more simulation devices can be test devices. The simulation device can transmit and / or receive data using direct RF coupling and / or wireless communication with the aid of RF circuits (e.g., which can include one or more antennas).

[0078] Figure 2is an example information exchange between a WTRU and a gNB for a 4-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 include a random access response (RAR). The RAR may include a DCI. The DCI may be scrambled with a RA-RNTI corresponding to the PRACH opportunity during which the preamble was sent. The DCI may include a RAR grant. The RAR grant may include a time and frequency resource allocation for the WTRU. The RAR grant may include a modulation and coding scheme (MCS) and a transmit power control (TPC) command. The second message may include a preamble index so that the WTRU may confirm that the RAR is for the WTRU. The WTRU may monitor a control channel for the second message and decode the second message. The WTRU may scramble data with a TC-RNTI. The WTRU may send a third message (e.g., msg3). The third message may include a payload of scrambled data. The third message may be sent based on the scheduling 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 receiving the fourth message, the WTRU may compare its TC-RNTI sent in the third message with the WTRU identity received in the fourth message. When two WTRUs select the same preamble, contention may occur as this may cause them to monitor the same RAR grant, which may cause the WTRU to send the third message on the same resources. In case of a collision, the WTRU may attempt another RACH procedure. The WTRU may send an acknowledgment message to indicate successful reception of the fourth message.

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

[0080] In 2-step RACH, the payload may be transmitted before receiving a resource allocation (e.g., grant) from the gNB. This may result in a collision of payloads if the WTRU decides to transmit on the same set of resources. At the receiving end, the gNB may need to know the transmission configuration that the WTRU uses to decode msgA. Therefore, assuming that the signal structure for msgA includes a preamble and a PUSCH payload, the following issues may need to be addressed: (i) mapping of preamble to PUSCH resources to reduce the probability of collision; (ii) how a WTRU based on preamble transmission can perform non-orthogonal multiple access (NOMA) detection at the gNB; (iii) how the WTRU determines the transmission configuration and indicates it to the gNB; and (iv) link adaptation and power control mechanisms for preamble and PUSCH.

[0081] The reference symbols described herein may be used to represent symbols such as complex numbers that are fixed and known and used as pilots. Reference signals may be used to represent time domain signals generated after processing the reference symbols. For example, in OFDM, the reference symbol is a complex number fed into the IDFT block, and the reference signal is the output of the IDFT block. Downlink control information (DCI) is a set of bits that may be sent on the PDCCH for a user or user group. 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 that may be used as a building block for a control channel element (CCE) that may allocate resource elements to a user. Adjacent REGs that are grouped together in time or frequency and whose associated precoders are the same are referred to as REG bundles. NR-REG, NR-CCE, and NR-PDCCH may refer to REGs, CCEs, and PDCCHs for new radio (NR) in 5G. UE and user may be used interchangeably. G node B 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 resource and its time length (in symbols) and its type of REG bundle. A search space or search space set may be a set of PDCCH candidates monitored by a UE or a group of UEs during blind detection of a PDCCH.

[0082] In Release-15 NR, the WTRU may initiate a PRACH transmission by randomly selecting a preamble from a configured list of preambles. This configuration may be communicated to the WTRU via the SIB during initial access. In 2-step RACH, PUSCH transmissions may occur without receiving an uplink scheduling grant in the DCI to schedule which resources the transmission may occur on and with which transmission parameters. The content of the scheduling grant may be inferred from the choice of preamble.

[0083] In an embodiment of 2-step RACH, the WTRU may implicitly signal the gNB with additional information about the payload (PUSCH) portion of the msgA transmission through its selection of preamble. The following may be implicit details that may be inferred at the gNB: PUSCH resource; WTRU-ID; MCS; DMRS index and beam index. For example, a preamble may be linked to a set of parameters. The WTRU may randomly select a preamble and transmit the preamble using specified parameters. The gNB may detect the preamble index and based on the preamble index the gNB may implicitly determine to perform a transmission from the WTRU using the specified parameters linked to the preamble. For example, if the WTRU selects preamble 1, it may use MCS1 and transmit on PRB1 using DMRS1. The WTRU-ID may also be associated with a preamble set partition.

[0084] The transmission of msgA may include the transmission of a preamble and a payload (PUSCH). Figure 4A An example of the same mapping of preamble and PUSCH resources is shown. Figure 4A In the present invention, the preamble resources and the PUSCH resources are in the same frequency (eg, the same resource block (RB)). The mapping of the PUSCH resources may not occur in the same resource block range as the preamble resources. Figure 4B Examples of different mappings of preambles and PUSCH resources are shown. Figure 4B In the present invention, the preamble resources and the PUSCH resources are in different frequencies (eg, the same resource block (RB)). The mapping of the PUSCH resources may be independent of the preamble resources in frequency and / or time or may vary with the preamble resources in frequency and / or time.

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

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

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

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

[0089] In an embodiment, the preamble may be associated with multiple subsets of PUSCH resources, wherein the selection of the subset of PUSCH resources may be based on another system parameter or measurement. For example, the selection of the subset of PUSCH resources may be based on packet size, service type, expected reliability or delay, bandwidth fraction, or estimated path loss.

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

[0091] A WTRU may be configured with multiple PUSCH resources, where each PUSCH resource set may include one or more PRBs. The PUSCH resources may follow a contiguous or non-contiguous mapping. A WTRU may be configured to transmit its payload using more than one PUSCH resource set to enhance reliability and to prove robustness to potential collisions. The additional PUSCH resources may be the same or different size as the original PUSCH resources.

[0092] Figure 5 An example of msgA transmission using multiple PUSCH resources is shown. Figure 5 As shown, the mapping of each additional PUSCH resource may have a different time and / or frequency offset relative to the preamble position which may be configured. Figure 5, Δt2 represents a configurable time offset value of PUSCH resource 2, and Δf2 represents a configurable frequency offset value of PUSCH resource 2 relative to the preamble position. In one example, Δt2 may be determined based on another system operating parameter (e.g., delay tolerance of the service, mobility state).

[0093] In one example, the WTRU may allocate additional PUSCH resources based on the allocation information of the original PUSCH transmission and the time offset value (Δt i ) and frequency offset value (Δf i ) to determine the mapping of additional PUSCH resources.

[0094] The diversity, size and pattern of the 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). The WTRU may be configured with multiple additional PUSCH resources based on the expected transmission reliability and delay tolerance. In one example, a WTRU (e.g., a URLLC WTRU) may be configured with multiple PUSCH resources to enhance the likelihood of a successful msgA transmission.

[0095] The mapping of the additional PUSCH resources may have a fixed or variable pattern per time slot that may be preconfigured. In one example, the mapping of the additional PUSCH resources may be determined based on other system parameters (eg, UE ID, time slot number).

[0096] The pattern of additional PUSCH resources may be randomly selected by the WTRU.The pattern of additional PUSCH resources may be linked to the selection of the preamble.

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

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

[0099] In an embodiment, additional PUSCH resources may be used to repeat the original transmission with a different MCS.The WTRU may use different PUSCH resources depending on the MCS selected for the additional PUSCH transmission.

[0100] In an embodiment, a set of preambles may be associated with the same set of PUSCH resources. A preamble selected from the set of preambles may refer to the same set of overlapping PUSCH resources. A WTRU selecting a preamble from the set may trigger a WTRU-ID selection for PUSCH transmission. During the WTRU-ID selection process, the WTRU may combine its RA-RNTI with additional parameters such as the preamble index. The WTRU-ID may be used for WTRU-specific scrambling.

[0101] In one embodiment, the WTRU may use a resource set to transmit resource allocations and another resource set to transmit other information. The content sent on the first resource set may include PRBs, MCSs, and DMRS indices. For example, the WTRU may use shared resources to transmit resource allocations used by the WTRU for non-shared resources. The content sent on shared resources may include PRBs, MCSs, and DMRS indices. One or more shared resources are available for the WTRU to choose from. The WTRU may randomly select one or more sets from the non-shared resources to transmit its payload. The WTRU may randomly select one of the non-shared resources to transmit parameters that may be necessary for decoding the payload sent on the shared resources. These parameters may include UE-ID, DMRS index, or other identifiers.

[0102] Figure 6 An example of a WTRU using a shared resource set and a non-shared resource set is shown. A preamble may be associated with one or more shared resource sets and one or more non-shared resource sets. A shared resource set may be used in conjunction with a non-shared resource to complement each other. The WTRU may select a preamble (610). The WTRU may select a shared resource set and a non-shared resource set (620). The WTRU may transmit on the shared resources and the non-shared resources (630).

[0103] In one embodiment, the WTRU may dynamically switch between shared resources and non-shared resources by selecting different preambles. A preamble may be associated with a shared or non-shared resource. For example, preamble set 1 may be associated with non-shared resources, while preamble set 2 may be associated with one or more sets of shared resources. The WTRU may randomly select a preamble from the K preambles and transmit its payload on the associated PUSCH resources. If the WTRU selects a preamble associated with a shared resource set, the WTRU may trigger WTRU-ID selection for UL-SCH scrambling. The WTRU may be triggered by higher layers to select from either preamble set.

[0104] A WTRU may be configured with uplink grant resources that may be used to transmit PUSCH in a 2-step RACH procedure. The configured grant resources or configuration may be provided in a broadcast message (e.g., in the 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 period and offset and a specific frequency location.

[0105] The WTRU may transmit a preamble in a random access opportunity. 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 with which it is associated. For example, the uplink control information in the configured grant may include at least one of the following: a preamble sequence, a PRACH resource, a timing offset (between the configured grant and a previously transmitted PRACH), or any parameter used by the WTRU to determine PRACH parameters (e.g., a WTRU ID).

[0106] The WTRU may determine a link or relationship between a preamble transmission and a configured granted resource based on the timing between the preamble transmission and the configured granted resource. For example, a WTRU transmitting a preamble at time x may transmit on the first configured granted resource available after time x+t, where t may be configurable and may be provided by the gNB or may be determined by the WTRU based on WTRU capabilities.

[0107] The WTRU may determine the linkage between the preamble transmission and the configured granted resources based on the linkage to the preamble resources. For example, the WTRU may determine the configured granted resources based on the resources used to transmit the PRACH.

[0108] The WTRU may determine the linkage between the preamble transmission and the configured granted resources based on the linkage to the preamble sequence. For example, the WTRU may determine the configured granted resources based on the selected PRACH preamble.

[0109] The WTRU may determine the linkage between the preamble transmission and the configured granted resources based on synchronization signal block (SSB) measurements. For example, the WTRU may determine the configured granted resources based on at least one SSB measurement. This may enable the WTRU to use an appropriately configured grant that uses the same beam as the SSB.

[0110] The WTRU may determine the link between the preamble transmission and the configured grant resources based on the parameters of the PUSCH transmission. For example, different configured grants may enable different transport block sizes. The WTRU may select the configured grant resources that best matches its required transport block size. In another example, the WTRU may select a specific configured grant based on a low code rate extension (LCRS) sequence or DM-RS.

[0111] The WTRU may determine the linkage between the preamble transmission and the configured granted resources based on the parameters of the PRACH transmission. For example, depending on the number of PRACH retransmissions, the WTRU may select a specific configured granted resource.

[0112] The WTRU may determine the linkage between the preamble transmission and the configured grant resources based on the BWP. For example, depending on the BWP used for the preamble transmission, the WTRU may select a specific configured grant.

[0113] The WTRU may determine the link between the preamble transmission and the configured granted resources based on the need for future transmissions. In one embodiment, the 2-step RACH procedure may enable the WTRU to transmit all the data it has in its buffer, while in another embodiment, the WTRU may need future resources to empty its buffer. The WTRU may select the configured granted resources based on whether the 2-step RACH procedure is sufficient or whether future scheduling is needed.

[0114] A WTRU, such as a Release-15 low coding rate extension (LCRS) WTRU, may scramble its bits with a WTRU specific identity. Figure 7 An example of using a bit sequence scrambled with a scrambling sequence is shown, which may be calculated based on a WTRU specific identity. In Release-15, the scrambling sequence generator may be initialized according to 3GPP TS 38.211 section 6.3.1.1: init =n RNTI 2 15 +n ID , where n RNTI is the RNTI associated with the PUSCH transmission and in the PRACH transmission

[0115] The version-15 RA-RNTI can be calculated as: RA-RNTI=1+s_id+14×t_id+14×80×f_id+14×80×8×ul_carrier_id, where s_id, t_id, f_id, and ul_carrier_id are pre-configured parameters, where s_id is the index of the first OFDM symbol of the PRACH opportunity (0≤s_id<14), t_id is the index of the first time slot of the PRACH opportunity in the system frame (0≤t_id<80), f_id is the index of the PRACH opportunity in the frequency domain (0≤f_id<8), and ul_carrier_id is the UL carrier used for random access preamble transmission (0 for NUL carrier and 1 for SUL carrier).

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

[0117] When initiating PRACH, the WTRU may not have a WTRU specific identity configured. The WTRU may be configured with only the RA-RNTI. Enhancements may be required in 2-step RACH so that the preamble can be used to partially or completely determine the WTRU specific identity used for scrambling in the UL-SCH processing chain and for sending PUSCH.

[0118] In one embodiment, for 2-step RACH operation, the WTRU may be configured with a unique RNTI, such as a 2RA-RNTI. The 2RA-RNTI may be considered as a WTRU-ID and may be used for data and CRC scrambling. The 2RA-RNTI may be configured to a subset of WTRUs based on, for example, service type, measurement. In one embodiment, the WTRU may select the RNTI as the n for UL-SCH scrambling based on the RA-RNTI. RNTI , and the UE can link n RNTI to preamble selection.

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

[0120] The RNTI used for scrambling may be configured based on the PRACH transmission opportunity. Each preamble may be configured for a different PRACH transmission opportunity resulting in a different RA-RNTI. The WTRU may randomly select a preamble and may calculate a RA-RNTI that is uniquely associated with it. For example, one preamble may be associated with PRACH transmission opportunity 1 while another preamble may be associated with PRACH transmission opportunity 2. The RA-RNTI calculated for each PRACH transmission opportunity may be different and may be used as a multi-access signature.

[0121] The RNTI used for scrambling may be configured based on the preamble index. A modified RNTI consisting of two parts may be used. One part may be a common RA-RNTI for a group of N preambles multiplexed in the same PRACH transmission opportunity. The second part may be the preamble identifier within the group. The WTRU may select (e.g., randomly) one of the N preambles within the group. The WTRU may calculate a common RA-RNTI for the PRACH opportunities configured for the group. For example, Figure 8 As shown, the WTRU may initialize its scrambler based on the RA-RNTI and the selected preamble index (Pi) (e.g., RA-RNTI + Pi). The gNB may detect the preamble (Pi) within the PRACH transmission opportunity and may descramble the WTRU's data by determining the initial seed for the scrambler based on a function (e.g., RA-RNTI + Pi).

[0122] In one embodiment, scrambling may be determined using a WTRU-specific interleaver. The WTRU-specific interleaver may be obtained based on the 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.

[0123] Preamble collisions may occur when more than one WTRU randomly selects the same preamble, which may result in multiple WTRUs selecting the same WTRU-ID. In order to enable the gNB to successfully detect the data, additional enhancements to the link between the preamble and the WTRU-ID may be considered to reduce the probability of failed detections due to preamble collisions. Assuming that the WTRUs transmit on overlapping PUSCH resources, the association between the preamble and the WTRU-ID may be enhanced in the following manner.

[0124] In one embodiment, Fig. 9As shown, multiple WTRU-IDs may be associated with one preamble. The WTRU may randomly select a preamble (910). The preamble may be linked to a subset or the entire set of available WTRU-IDs. Preamble selection may trigger WTRU-ID selection. The WTRU may select (e.g., randomly) one or several WTRU-IDs from the subset (920). The WTRU may use the selected WTRU-ID to transmit the selected preamble and scramble (930). 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.

[0125] In one embodiment, multiple preambles may be linked to a subset of WTRU-IDs. Multiple WTRUs may select the same or different preambles, and the preambles may be associated with a common subset of WTRU-IDs. After selecting one of the preambles, the 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.

[0126] Multi-layer LCRS transmission can be achieved in the UL-SCH processing chain by splitting the original bit stream into L layers and performing scrambling on each layer. Each layer can use a specific scrambling sequence. In Release 15, the WTRU can use only one WTRU-ID to scramble the PUSCH. However, for multi-layer transmission, the WTRU can use multiple WTRU-IDs, where each WTRU-ID can correspond to one layer. With the msgA preamble and payload transmission, the WTRU can select the preamble and may need to generate multiple WTRU-IDs. Enhancements may be required to allow the WTRU to link multiple WTRU-IDs to one PUSCH transmission.

[0127] In one embodiment, the WTRU may select multiple WTRU-IDs based on the preamble and use multiple WTRU-IDs simultaneously in a multi-layer transmission (e.g., LCRS). For example, the preamble set may be divided into groups based on the number of layers, and a WTRU-ID may be assigned to each group. Fig.10 As shown, for L layer transmissions, one preamble may be associated with L WTRU IDs. The WTRU may select one preamble and may use the L associated WTRU-IDs to perform multiple layers of transmission. In one embodiment, the group for L layers may include more than L WTRU-IDs and the WTRU may select L from the total number of available WTRU-IDs. The gNB may detect the preamble and may implicitly determine to transmit L layers based on the group containing the preamble index.

[0128] In one embodiment, the WTRU may select a WTRU-ID and determine L-1 other WTRU-IDs based on the first WTRU-ID. A predetermined function may be configured during RACH parameter configuration so that the WTRU may derive L-1 WTRU-IDs associated with the first WTRU-ID determined by the preamble. For example, the WTRU may select a WTRU-ID based on the preamble and may calculate L-1 other WTRU-IDs (e.g., WTRU-ID+1, WTRU-ID+2, ... WTRU-ID+L-1). Other functions may be used to determine the L WTRU-IDs in a sequential or distributed manner.

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

[0130] In an embodiment, the DMRS configuration may be linked to the selected preamble.The DMRS configuration may be characterized by its time and frequency density, pattern, sequence and its scrambling mechanism.

[0131] In an embodiment, the preamble set may be partitioned into several groups based on channel dispersion in time and frequency, where each partition may be linked to a specific DMRS pattern with appropriate density and pattern. In one embodiment, the WTRU may select a preamble based on its estimate of the uplink channel. The WTRU may adopt the DMRS definition based on the preamble it selects.

[0132] As part of the 2-step RACH procedure, the WTRU may select the preamble and PUSCH resources. In addition, the WTRU may also need a DMRS port to assist the gNB in ​​decoding the payload portion of msgA. The WTRU may select a DMRS port, which may be generated, for example, according to Release 15. In Release 15, the DMRS for PUSCH is initialized using a random sequence generated according to 38.211 6.4.1.1 using the initial seed cinit Generated: in is the number of symbols per time slot, is the number of slots s within a frame f for the subcarrier spacing μ, and l is the number of OFDM symbols within a slot. and n SCID Indicates the scrambling identifier and can be configured to generate a DMRS sequence corresponding to a PUSCH transmission. In the absence of RRC configuration and no configured grant or DCI to schedule PUSCH, n SCID =0, This may be the case when the WTRU is in idle mode and a 2-step RACH procedure is initiated. Idle WTRUs within a cell may use the same scrambling identity to generate their DMRS sequences. DMRS collisions may occur if multiple WTRUs select the same DMRS port generated from the same sequence and mapped to the same physical resource. Enhancements may be needed to allow idle WTRUs to generate their own DMRS sequences.

[0133] In one embodiment, the WTRU may determine based on a mapping based on the preamble index The mapping can be configured using RACH parameter configuration during initial access. The preamble can be mapped to a set of valid values ​​to determine the scrambling identity. For example, the gNB can pre-configure A one-to-one mapping between the DMRS and the preamble. Each preamble selection can determine the DMRS sequence.

[0134] In an embodiment, multiple preambles may be mapped to a scrambling identifier. A unique scrambling identifier may be derived based on the preamble, the DMRS index, and the public scrambling identifier. For example, the scrambling identifier may include a portion having a public value such as an RA-RNTI or a predefined value set and another portion such as a preamble index or a DMRS index.

[0135] In one embodiment, the preamble may be mapped to a If multiple WTRUs select the same preamble, they can randomly Multiple WTRUs may be able to generate different DMRS sequences even if they select the same preamble.

[0136] When multiple preambles are mapped to one DMRS sequence, multiple WTRUs may randomly select the same preamble. The initial scrambling identity is generated for multiple WTRUs, so the preamble may not be sufficient to generate a WTRU-specific DMRS sequence. It may be a pre-set common value that may be shared by multiple WTRUs. If the same DMRS sequence is used by multiple WTRUs for the same port, a conflict may occur.

[0137] In one embodiment, the WTRU may generate a DMRS sequence based on the preamble and may select a DMRS port (e.g., randomly). The DMRS port selection may be randomized and may be obtained from a set of available ports that may be pre-configured using a RACH configuration during initial access. The WTRU may randomly select a DMRS port for transmission and may reduce the chance of collision even if the same DMRS scrambling identifier is used. Additionally, if multiple WTRUs share the same PUSCH resources, the DMRS scrambling identifier may be used along with the port number to generate a scrambler for the UL-DSCH. For example, the WTRU may select a preamble and generate a DMRS sequence based on the preamble. The WTRU may select an antenna port. The scrambler for the UL-SCH may be, for example, + preamble index + antenna port index. Multiple WTRUs may transmit with the same DMRS sequence on different ports with PUSCH scrambled WTRU-ID based on the DMRS sequence associated with the multiple preambles and the port number selected by each WTRU, wherein the receiver may decode the PUSCH based on the preamble index, which may be mapped to the DMRS sequence and the port number that initialized the PUSCH scrambling.

[0138] The DMRS scrambling identifier may be generated based on the preamble and port selection. In the case where multiple WTRUs select the same port, different preambles may generate different scrambling identifiers for the DMRS, such as Fig.11 As shown. The WTRU may select a preamble (preamble n) from a pool of available preambles (1110). The WTRU may select a DMRS port (DMRS port k) from a pool of available DMRS ports (1120). The WTRU may generate a DMRS sequence that may take preamble n and DMRS port k as inputs and calculate a sequence initialization value based on the inputs (1040). 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 values ​​from which the WTRU may randomly select a It may be uniquely determined as a function of (n, k). For example, the identity may be calculated based on a predetermined function of n and k.

[0139] In 2-step RACH, msgA can be expected to carry the random access preamble (msg1) and the RRC connection request (msg3). However, the RRC connection request may need to be sent on the PUSCH. Compared to 4-step RACH, where information about the PUSCH is transmitted on the RAR uplink grant as part of msg2, in 2-step RACH, the gNB may not be able to dynamically provide such information.

[0140] In one embodiment, the WTRU may use an uplink configured grant to transmit the data portion of msgA (e.g., RRC Connection Request). The WTRU may be semi-statically configured with one or more RAR uplink grants on a licensed or unlicensed band by higher layers. The WTRU may select one of the configured uplink grants for msgA transmission on PUSCH based on one or more combinations of the following parameters:

[0141] The parameter may be a listen-before-talk (LBT) category for PUSCH transmission in an unlicensed band. In one example, if the LBT category for transmission of msgA is 0 or 1, this may mean that the WTRU may transmit the PUSCH almost immediately, so the WTRU may need to select a configured PUSCH resource allocation with a longer duration without any restriction on the starting symbol. In one example, if LBT category 4 is required for transmission of msgA, the WTRU may use a configured PUSCH resource allocation where the starting symbol is later in the slot and the length of the PUSCH is shorter.

[0142] The parameters may be channel occupancy time (COT) attributes in the unlicensed band (e.g., COT length, COT start OFDM symbol, COT last OFDM symbol). In one example, if msgA is expected to be transmitted towards the end of the COT, the WTRU may need to select a configured PUSCH resource allocation with an appropriate length that is aligned with the last OFDM symbol of the COT.

[0143] Other parameters may include: configured PUSCH start symbol and length; configured PUSCH mapping type; configured PUSCH frequency domain resource allocation; configured modulation and decoding 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 transport blocks transmitted on the configured PUSCH (e.g., in an unlicensed band, the COT duration can be 5 ms or 10 ms, and for a 15 kHz subcarrier spacing, each time slot can be 1 ms, and then the WTRU may need to select a configured uplink grant where the number of repetitions is less than or equal to the maximum length of the COT (e.g., between 5 and 10)); uplink measurements (e.g., L1-RSRP, RLM, RSRP, RSRQ); and channel sensing on the WTRU side.

[0144] In one embodiment, the WTRU may be semi-statically configured by higher layer parameters, such as the ConfiguredRARGrantConfig parameter. The following are examples of higher layer parameters that may be applied by the WTRU for PUSCH transmissions corresponding to msgA: frequency hopping flag; PUSCH frequency resource allocation; PUSCH time resource allocation; modulation and coding scheme; and TPC command for PUSCH.

[0145] The WTRU may be configured to utilize repeated transmissions of the PUSCH carrying msgA. In this case, the WTRU may also be provided with a redundancy version mode to be applied to the PUSCH repetitions carrying msgA. The configured RV sequence for msgA repetitions may be {0, 2, 3, 1}, {0, 3, 0, 3}, or {0, 0, 0, 0}. If the WTRU is configured not to employ repeated transmissions of the PUSCH carrying msgA, the WTRU may use redundancy version 0 for the PUSCH transmissions carrying msgA.

[0146] In one embodiment, if msgA is transmitted with HARQ enabled, the WTRU may include one or a combination of the following information in the PUSCH carrying msgA to assist the gNB in ​​msgA detection: New Data Indicator (NDI); HARQ ID; Redundancy Version (RV); WTRU ID; COT sharing information (e.g., for unlicensed bands).

[0147] The WTRU may determine the parameters of the PUSCH transmission based on the measurements performed. The measurements may be performed prior to sending the preamble of msgA and / or the PUSCH. The parameters of the PUSCH transmission may include at least one of: MCS, uplink power control (e.g., initial offset value); precoding; analog beam; time positioning; frequency resources; LBT used (i.e., for unlicensed channel access).

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

[0149] In one embodiment, the WTRU may measure multiple CSI-RS before transmitting at least the PUSCH portion of msgA. The WTRU may determine the beam to transmit based on at least one CSI-RS measurement. The WTRU may determine the resources on which to transmit the PUSCH based on the selection of the beam. The WTRU may construct a transport block based on the results of this measurement process so as to be able to refine at least the MCS to best match the channel conditions on the selected beam.

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

[0151] For retransmission, the WTRU may adjust at least one parameter of the preamble and / or PUSCH.The WTRU may behave differently depending on whether the WTRU needs to retransmit the preamble, the PUSCH, or both the preamble and the PUSCH.

[0152] In embodiments where both the preamble and the PUSCH are to be retransmitted, the WTRU may use a power ramp for the preamble and may maintain the association between the power of the preamble and the PUSCH (e.g., it may also increase the power of the PUSCH). The WTRU may also maintain or modify other parameters of the PUSCH. For example, the WTRU may modify the MCS level, which may improve the robustness of the PUSCH.

[0153] In one embodiment, the WTRU may increase the power level of the preamble without changing the power of the PUSCH transmission. In one embodiment, the WTRU may maintain two independent uplink power control procedures: one for the preamble and the other for the PUSCH. The WTRU may receive msgB indicating how to increase the separate uplink power control procedures.

[0154] For retransmission, the resources of the PUSCH may be modified so that the association with the resources of the preamble may not be maintained during each retransmission.

[0155] In an embodiment where only PUSCH is transmitted, the WTRU may be instructed to increase the uplink power through closed loop power control. In one embodiment, the WTRU may independently increase the power of the PUSCH transmission (e.g., determined based on the number of retransmissions of msgA PUSCH). In one embodiment, the WTRU may reduce the MCS for each retransmission. In one embodiment, the WTRU may first increase the power while keeping the MCS constant and when the maximum power is reached may start to reduce the MCS level for subsequent retransmissions. In one embodiment, the WTRU may first reduce the MCS level and when a configurable minimum value is reached, the WTRU may start to increase the uplink power for subsequent retransmissions.

[0156] In embodiments where only the preamble is to be retransmitted, the WTRU may use a power ramp for the preamble. The WTRU may perform virtual link adaptation on the PUSCH so that at a future time when the PUSCH will be transmitted, the WTRU may determine a new value for uplink power and / or MCS based on the number of times the preamble (with or without PUSCH) is retransmitted.

[0157] The preamble may be linked to multiple PUSCH resources. The WTRU may choose to transmit on a subset of the available PUSCH resources and the WTRU may choose different transmission parameters. The subset of PUSCH resources may include one, multiple or all RBs from the PUSCH resources. The resources may be located in different time / frequency regions configured in the PUSCH transmission opportunities. Since msgA may be transmitted without resource allocation from the gNB, the WTRU may select PUSCH resources from the configured PUSCH opportunities. However, the gNB may not be aware of the WTRU's selection of PUSCH transmission parameters. The WTRU may need to signal the gNB with the location of the resources where decoding occurs.

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

[0159] In one embodiment, the WTRU may change the DMRS sequence or port to signal a change in transmission parameters. For example, in the case of a msgA failure, the WTRU may retransmit msgA using a different coding rate or different PUSCH resources. The location of the PUSCH resources may be different from the initial transmission to accommodate a different coding rate or additional PUSCH resources. After receiving a gNB response to a msgA transmission failure, the WTRU may maintain or change its DMRS sequence or port.

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

[0161] The 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 the msgA preamble. For msgA PUSCH transmission, the WTRU may use the same beam or the same spatial filter as used for msgA preamble transmission. The gNB may use energy detection when receiving the msgA preamble and may use demodulation or decoding when receiving the msgA PUSCH payload. A beam that is sufficient for msgA preamble transmission may not be sufficient for msgA PUSCH transmission. A msgA PUSCH transmission may require a higher signal-to-noise ratio (SNR) than a msgA preamble transmission. Failure in msgA PUSCH detection performed by the gNB may cause the WTRU to retransmit the preamble portion and the PUSCH portion of msgA, which may increase latency and delay. The WTRU may use a beam refinement process to refine the beam for msgA PUSCH transmission, which may increase signal reception.

[0162] Fig.12An example beam refinement procedure is shown. The beam refinement procedure may be in the context of a 2-step RACH procedure, where the WTRU may transmit a first message (eg, msgA) that may include a preamble and a PUSCH payload.

[0163] The WTRU may receive configuration information (1205). The configuration information may be received from the gNB. The configuration information may include an association between a preamble and an SSB. The configuration information may include an association between a preamble, a reference signal (RS) set, and a PUSCH resource. The 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).

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

[0165] The WTRU may determine 1235 resources for receiving reference signals in response to transmitting the preamble. The WTRU may assume that K reference signal sets are received using K different narrow beams.

[0166] The WTRU may determine the resources for receiving the reference signal based on the parameters of the associated SSB. For example, based on the SSB selected for the first beam, the WTRU may use the resources associated with the selected SSB to expect the presence of the RS signal. The WTRU may expect different parameters of the RS (e.g., sequence, transmit power, etc.) to be associated with the SSB resources.

[0167] The WTRU may determine the resources for receiving the reference signal based on the parameters associated with the preamble transmission. For example, the resources used for the preamble transmission or the preamble sequence may be associated with a set of resources or a set of RS parameters.

[0168] The WTRU may determine the resources for receiving the reference signal based on the parameters indicated in the broadcast message. For example, the PBCH may provide the resources on which the WTRU may expect to receive the RS.

[0169] The WTRU may determine the resources for receiving the reference signal based on the WTRU specific configuration. For example, for a connected mode WTRU, the WTRU may be configured with the resources for which RS transmission is desired.

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

[0171] The WTRU may not receive the RS for beam refinement prior to the transmission of the PUSCH payload. In this case, the WTRU may indicate this to the gNB. This indication may be made implicitly based on the resources used to send the PUSCH. Failure to receive the beam refinement RS may cause the WTRU to retransmit the preamble. In this case, the transmit power may be ramped up.

[0172] In an embodiment, beam refinement may be performed using an always-on reference signal (RS). For example, the gNB may configure a periodic set of RS (e.g., CSI-RS, PTRS), where each RS may be associated with a different spatial filter supporting different beams. The WTRU may perform measurements (e.g., RSRP) on the always-on RS at any time to refine its beam selection. An always-on signal may create inter-cell interference because it is constantly broadcast. It may also require the reservation of dedicated time / frequency resources in a timeslot, which may result in significant overhead. The configured RS set (RSS) may be configured with a time offset relative to the RACH opportunity (RO). In one embodiment, the RSS may be configured with a small time offset that occurs before the RO, which may allow the WTRU to have sufficient time to perform beam measurements and adjustments.

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

[0174] A WTRU in connected mode may benefit from the configured RS for beam refinement.The WTRU may determine the configuration of the RS associated with the RO from the TCI state of the configured bandwidth portion.

[0175] RSS configuration can be associated with RACH configuration with different periodicity. For example, the duty cycle of RSS can be flexibly configured so that RSS can be sent with every X RACH opportunities. RS transmission can be configured with a time hopping pattern corresponding to Y% of RACH opportunities in a time period.

[0176] RSS configuration can be associated with RACH configuration with different frequency granularity. For example, within a time instance, there may be multiple ROs located in different PRBs. RSS can be sent once every X PRBs. RS transmission can be configured with a frequency hopping pattern corresponding to Y% of PRBs within a time instance.

[0177] The RSS configuration may be associated with a RACH configuration with a combination of different time and frequency parameters. For example, the configuration may be joint such that X PRBs are occupied in Y time instances.

[0178] Fig.13 An example of beam refinement is shown. The WTRU may receive configuration information (1310). The configuration may be received from a gNB. The configuration information may be a PRACH configuration. The configuration information may indicate an association between an SSB and a RO. The configuration information may indicate an association between a configured RSS and a RO. The WTRU may receive an SSB and an RSS associated with RO#0 and RO#63 (1320). The WTRU may receive an SSB and an RSS from a gNB. Fig.13 In the example shown in FIG. 64 , 64 SSBs are configured to link one RO per SSB. The RO can be configured in TDM mode. Fig.13 RSS in is configured for RO#0 and RO#63 to provide some resources for WTRUs that need more beam selection. For other ROs, only SSB is transmitted. RSS allows the gNB to provide different beams (e.g. narrower or more) with RSS compared to SSB.

[0179] The WTRU may wake up before the RO where only SSB is available without RSS (1330). Based on the RSS configuration, the WTRU may determine that it may wait until RO#63 to receive RSS that may provide an alternative beam selection. The WTRU may decide to wait based on a timer that has expired since the last beam selection or based on insufficient SSB beam quality measurement. The WTRU may perform measurements on the RSS and may determine the best RS based on signal quality (e.g., RSRP) (1340). As part of the RACH configuration, the RSS may be associated with the preamble within the corresponding RACH opportunity. The WTRU may send a preamble corresponding to the best measured RS (e.g., msgA preamble) followed by a PUSCH payload (e.g., msgA PUSCH payload) (1350). The gNB may receive msgA and may adjust its spatial transmission filters corresponding to the RSS linked to the detected preamble index. The gNB may send a msgB reply to the WTRU using the adjusted spatial transmission filters. The WTRU may monitor the msgB response. The msgB response may be scheduled on resources identified by the PDCCH addressed to the WTRU's identity or on resources linked to the RSS.The WTRU may receive a response (eg, a msgB response) based on the adjusted spatial transmit filter (1360).

[0180] Although the features and elements are described above in specific combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. In addition, the methods described herein can be implemented in a computer program, software, or firmware, which is incorporated into a computer-readable medium to be executed by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), the WTRU comprising: transceiver; as well as A processor, wherein: The transceiver and the processor are configured to receive configured permission information; The processor is further configured to select a configured grant based on the configured grant information and a measurement of a synchronization signal block (SSB) associated with the configured grant; and The transceiver is also configured to send a physical uplink shared channel (PUSCH) transmission using the selected configured grant.

2. The WTRU of claim 1 , wherein the configured grant information indicates uplink resource allocation.

3. The WTRU of claim 2, wherein the configured grant information indicates a time period and an offset associated with the uplink resource allocation.

4. The WTRU of claim 2, wherein the configured grant information indicates a frequency location associated with the uplink resource allocation.

5. The WTRU of claim 1 , wherein the PUSCH transmission comprises a radio resource control (RRC) connection request message.

6. The WTRU of claim 1, wherein the PUSCH transmission includes a WTRU identification (ID).

7. The WTRU of claim 1, wherein the PUSCH transmission is sent using a beam based on the SSB associated with the configured grant.

8. The WTRU of claim 1, wherein the transceiver and the processor are further configured to receive information indicating an association between the configured grant information and a synchronization signal block (SSB).

9. The WTRU of claim 1 , wherein the PUSCH transmission is used for small data transmission (SDT).

10. The WTRU of claim 1 wherein the measurement is reference signal received power (RSRP).

11. A method for use in a wireless transmit / receive unit (WTRU), the method comprising: receiving configured licensing information; selecting a configured grant based on the configured grant information and a measurement of a synchronization signal block (SSB) associated with the configured grant; as well as A Physical Uplink Shared Channel (PUSCH) transmission is sent using the selected configured grant.

12. The method of claim 11, wherein the configured grant information indicates uplink resource allocation.

13. The method of claim 12, wherein the configured grant information indicates a time period and an offset associated with the uplink resource allocation.

14. The method of claim 12, wherein the configured grant information indicates a frequency location associated with the uplink resource allocation.

15. The method of claim 11, wherein the PUSCH transmission comprises a Radio Resource Control (RRC) Connection Request message.

16. The method of claim 11, wherein the PUSCH transmission includes a WTRU identity (ID).

17. The method of claim 11, wherein the PUSCH transmission is sent using a beam based on the SSB associated with the configured grant.

18. The method of claim 11, further comprising receiving information indicating an association between the configured grant information and a synchronization signal block (SSB).

19. The method of claim 11, wherein the PUSCH transmission is used for small data transmission (SDT).

20. The method of claim 11, wherein the measurement is Reference Signal Received Power (RSRP).

Images