Method for msg-b in two-step rach

Abstract

To provide methods and apparatuses for transmitting a hybrid automatic repeat request acknowledgment (HARQ-ACK).SOLUTION: A wireless transmit / receive unit (WTRU) 912 capable of transmitting a RACH message-A to a gNB 911 may receive a RACH message-B from the gNB 911 in response to a message-A. The message-B may comprise downlink control information (DCI). The WTRU may decode a PDSCH based on the DCI, determine that contention resolution is successful, and determine a resource for a physical uplink control channel (PUCCH). The WTRU may transmit a HARQ-ACK over the determined PUCCH resource and determine the resource for the PUCCH based on a PUCCH resource index. The PUCCH resource index may be based on a random access preamble index (RAPID) and a PUCCH resource indicator (PRI).SELECTED DRAWING: Figure 9

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 62 / 805,084, filed February 13, 2019, U.S. Provisional Patent Application No. 62 / 840,647, filed April 30, 2019, U.S. Provisional Patent Application No. 62 / 908,883, filed October 1, 2019, and U.S. Provisional Patent Application No. 62 / 930,911, filed November 5, 2019, the contents of which are incorporated herein by reference. [Background technology]

[0002] In wireless communication technology, there is a Random Access Channel (RACH) procedure for devices attempting to connect to a network. For example, the RACH procedure may be prompted by a trigger that initiates the RACH procedure, such as synchronization acquisition or handover. There is a need to improve this process. Summary of the Invention

[0003] A method and apparatus for transmitting a hybrid automatic repeat request acknowledgement (HARQ-ACK) is disclosed. A wireless transmit / receive unit (WTRU) may transmit a random access channel (RACH) message A to a gNB. The WTRU may receive a RACH message B from the gNB in ​​response to message A. Message B may include downlink control information (DCI). The WTRU may decode a physical downlink shared channel (PDSCH) based on the DCI. The WTRU may determine that contention resolution is successful. The WTRU may determine resources for a physical uplink control channel (PUCCH). The WTRU may transmit a HARQ-ACK via the determined PUCCH resources. The WTRU may determine resources for the PUCCH based on a PUCCH resource index. The PUCCH resource index may be based on a random access preamble index (RAPID) and a PUCCH resource indicator (PRI). The WTRU may determine a slot timing for transmitting the HARQ-ACK. The slot timing may be based on the PDSCH-HARQ feedback indicator and RAPID. [Brief description of the drawings]

[0004] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numbers indicate like elements, and in which: [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1A is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A, according to an embodiment. [Figure 1C] FIG. 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to an embodiment. [Figure 1D]FIG. 1B is a system diagram illustrating yet another exemplary RAN and yet another exemplary CN that may be used within the communication system illustrated in FIG. 1A, according to an embodiment. [Diagram 2] FIG. 13 is a process diagram illustrating an example information exchange between a WTRU and a gNB for a four-step RACH procedure. [Diagram 3] FIG. 1 illustrates an exemplary baseline for signal structure for two-step RA. [Figure 4] FIG. 13 is a process diagram illustrating an example of information exchange between a WTRU and a gNB for a two-step RACH procedure. [Diagram 5] 1 is a flow diagram illustrating an example of a WTRU behavior for an efficient ACK / NACK process. [Figure 6] 1 is a flow diagram illustrating an example of a WTRU behavior for an efficient ACK / NACK process. [Figure 7] 1 is a flow diagram illustrating an example WTRU procedure associated with a two-step RA, in which the UE detects, within the RAR window, a DCI associated with msgB that includes a DL allocation. [Figure 8] 11 is a flow diagram illustrating an example WTRU procedure associated with a two-step RA, in which the WTRU detects, within the RAR window, a DCI associated with msgB that includes an uplink grant. [Figure 9] FIG. 13 is a process diagram illustrating an example of beam failure recovery with multiple beam monitoring. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0005] 1A illustrates 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, broadcasts, etc., to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of 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-Tailed Unique Word Discrete Fourier Transform Spread OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multi-Carrier (FBMC), etc.

[0006] 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, the WTRUs 102a, 102b, 102c, 102d, all of which may be referred to as stations (STAs), may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, notebooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, IoT devices, watches or other wearables, head mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronic devices, devices operating on commercial and / or industrial wireless networks, etc. The WTRUs 102a, 102b, 102c, and 102d may all be referred to interchangeably as UEs.

[0007] The communications 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 configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communications networks, such as the CN 106, the Internet 110, and / or other networks 112. For example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNodeB (eNB), a Home Node B, a Home eNodeB, a Next Generation Node B (e.g., gNodeB (gNB)), a New Radio (NR) Node B, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each depicted as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0008] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b may be configured to transmit 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 licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for wireless services in a particular geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0009] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over 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).

[0010] More specifically, as noted above, the communications 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 stations 114a and the WTRUs 102a, 102b, 102c in the RAN 104 may implement a radio technology, such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using Wideband CDMA (WCDMA®). WCDMA may include communications 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).

[0011] In one 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 LTE Advanced (LTE-A) and / or LTE Advanced Pro (LTE-A Pro).

[0012] 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.

[0013] 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 implement LTE and NR radio access together using a dual connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to and from multiple types of base stations (e.g., eNBs and gNBs).

[0014] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), or the like.

[0015] The base station 114b in FIG. 1A 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 workplace, a home, a vehicle, a premises, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology, 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 a radio technology, such as IEEE 802.15, to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106.

[0016] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, application, and / or VoIP services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error resilience requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, billing services, mobile location services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high level security functions, such as user authentication. Although not shown in FIG. 1A, it will be understood that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs employing the same RAT as the RAN 104 or a different RAT. 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) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0017] 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 providing 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 TCP, UDP, and / or 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 other networks 112 may include another CN connected to one or more RANs that may employ the same RAT as the RAN 104 or a different RAT.

[0018] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications 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 over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a, which may employ a cellular-based wireless technology, and with a base station 114b, which may employ an IEEE 802 wireless technology.

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

[0020] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, other types of integrated circuits (ICs), 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 FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated in an electronic package or chip.

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

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

[0023] 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 mentioned 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, such as, for example, NR and IEEE 802.11.

[0024] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from the speaker / microphone 124, the keypad 126, and / or the 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 keypad 126, and / or the display / touchpad 128. Additionally, the processor 118 may access information and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include RAM, ROM, a hard disk, or any other type of memory storage device. The removable memory 132 may include a SIM card, a memory stick, a secure digital (SD) memory card, or the like. In other embodiments, the processor 118 may access information and store data in memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown).

[0025] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control the 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 batteries (e.g., nickel cadmium (NiCd), nickel copper (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0026] The processor 118 may also be coupled to a 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 instead of information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by way of any suitable location determination method while remaining consistent with an embodiment.

[0027] 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, functions, 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 videos), a USB port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors. The sensors 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 biosensor, a humidity sensor, and the like.

[0028] The WTRU 102 may include a full-duplex radio in which transmission and reception of some or all of the signals (e.g., associated with a particular subframe for both the UL (e.g., for transmission) and DL (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit whereby self-interference is reduced or nearly eliminated via hardware (e.g., a choke) or via signal processing via a processor (e.g., a separate processor (not shown) or processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio in which transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either the UL (e.g., for transmission) and DL (e.g., for reception)) is performed.

[0029] 1C is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As mentioned above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0030] The RAN 104 may include eNodeBs 160a, 160b, 160c, although it will be understood that the RAN 104 may include any number of eNodeBs while remaining consistent with an embodiment. The eNodeBs 160a, 160b, 160c may each comprise one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, the eNodeB 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0031] 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. As shown in FIG 1C, the eNodeBs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0032] 1C 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 elements are depicted as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0033] The MME 162 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attachment 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 radio technologies such as GSM and / or WCDMA.

[0034] The SGW 164 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions such as anchoring the user plane during handover between eNodeBs, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

[0035] The SGW 164 may be connected to a PGW 166 that provides 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.

[0036] 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 fixed communication devices. For example, the CN 106 may include or communicate 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. Additionally, 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.

[0037] Although the WTRU is depicted in FIGS. 1A-1D as a wireless terminal, it is contemplated that in some representative embodiments such a terminal may use a wired communications interface with the communications network (e.g., temporarily or permanently).

[0038] In an exemplary embodiment, the other network 112 may be a WLAN.

[0039] A WLAN in infrastructure basic service set (BSS) mode has an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or from the BSS. Traffic to the STA originating from outside the BSS may arrive through the AP and be sent to the STA. Traffic originating from the STA to a destination outside the BSS may be sent to the AP and delivered to the respective destination. Traffic between STAs in the BSS may be sent through the AP, e.g., a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs in the BSS may be considered or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent (e.g., directly) between the source and destination STAs using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all STAs) may communicate directly with each other. The IBSS communication mode is sometimes referred to herein as an "ad-hoc" communication mode.

[0040] When using 802.11ac infrastructure mode of operation or a similar mode of operation, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel may be an operating channel of the BSS and may be used by STAs to establish a connection with the AP. In certain representative embodiments, for example in an 802.11 system, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented. With CSMA / CA, STAs (e.g., all STAs), including the AP, may sense the primary channel. If the primary channel is sensed / detected by a particular STA and / or determined to be busy, the particular STA may back off. One STA (e.g., only one station) may transmit on a particular BSS at any time.

[0041] High throughput (HT) STAs may use 40 MHz wide channels for communication, for example, via combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0042] A Very High Throughput (VHT) STA can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, the latter sometimes referred to as an 80+80 configuration. For the 80+80 configuration, the data can be passed through a segment parser after channel encoding, which can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be performed separately for each stream. The streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to a medium access control (MAC).

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

[0044] A WLAN system may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, including a channel that may 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 that supports the smallest bandwidth operating mode of all STAs operating in the BSS. In an 802.11ah example, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) setting may depend on the status of the primary channel. If the primary channel is busy, for example because a STA (that only supports 1 MHz mode of operation) is transmitting to the AP, then all available frequency bands may be considered busy even if most of the available frequency bands remain idle.

[0045] In the United States, the available frequency bands for use with 802.11ah are 902MHz to 928MHz. In South Korea, the available frequency bands are 917.5MHz to 923.5MHz. In Japan, the available frequency bands are 916.5MHz to 927.5MHz. The total available bandwidth for 802.11ah is 6MHz to 26MHz depending on the country code.

[0046] 1D is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As mentioned above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0047] The RAN 104 may include gNBs 180a, 180b, 180c, although it will be understood that the RAN 104 may include any number of gNBs while remaining consistent with the embodiments. The gNBs 180a, 180b, 180c may each 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, 108b may utilize beamforming to transmit and / or receive signals to and from the gNBs 180a, 180b, 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit and / or receive wireless signals to and from the WTRU 102a. In one embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on an unlicensed spectrum, and the remaining component carriers may be on a licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement coordinated multipoint (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or 180c).

[0048] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the 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 transmission time intervals (TTIs) of different or scalable lengths (e.g., including different numbers of OFDM symbols and / or different lengths of absolute time lasting).

[0049] 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 accessing any other RAN (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with a gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as an eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c at approximately the same time. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as a mobility anchor 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.

[0050] Each of the gNBs 180a, 180b, 180c 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, support for network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards User Plane Functions (UPFs) 184a, 184b, routing of control plane information towards Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D , the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

[0051] 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although the foregoing elements are depicted as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0052] 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 act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions having different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating non-access stratum (NAS) signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service being utilized by the WTRUs 102a, 102b, 102c. Different network slices may be established for different use cases, for example, services relying on ultra-reliable low latency (URLLC) access, services relying on 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) employing other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies (e.g., WiFi).

[0053] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 106 via an N11 interface. The SMFs 183a, 183b may also be connected to the UPFs 184a, 184b in the CN 106 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184b. The SMFs 183a, 183b may also perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, etc. The PDU session types may be IP-based, non-IP-based, Ethernet-based, etc.

[0054] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an 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 UPFs 184a, 184b may also 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, etc.

[0055] The CN 106 may facilitate communication with other networks. For example, the CN 106 may include or communicate 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. Additionally, 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 local DNs 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0056] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0057] The emulation device may be designed to implement one or more tests of other devices in a lab environment and / or an operator network environment. For example, one or more emulation devices may be fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to implement one or more or all of the functions to test other devices in the communication network. One or more emulation devices may be temporarily implemented / deployed as part of a wired and / or wireless communication network to implement one or more or all of the functions. The emulation device may be directly coupled to another device for testing purposes and / or for testing using wireless communication over the air.

[0058] The emulation device(s) may also 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 emulation device may be utilized in a test scenario in a test lab and / or in a test scenario in a non-deployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. The emulation device(s) may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation device to transmit and / or receive data.

[0059] Generally, in a given wireless system (e.g., LTE, NR, etc.) as described in Figures 1A, 1C, and 1D, a WTRU may access the network using a random access procedure (e.g., handover synchronization after a cell is found, re-establishment of uplink synchronization, scheduling request, etc.). In some cases (e.g., in LTE), there may be a four-step random access channel (RACH) procedure, where four messages (msg) are exchanged between the WTRU and the base station (e.g., network / cell).

[0060] 2 is a process diagram illustrating an example exchange between a WTRU 211 and a gNB 212 for a four-step RACH procedure. At 201, the WTRU 211 may transmit msg1, which may be a randomly selected random access preamble sequence and may be transmitted during a physical RACH (PRACH) opportunity. The WTRU 211 may monitor the control channel for msg2 (e.g., a random access response).

[0061] Upon receiving msg1, the gNB 212 may send back msg2 at 202, which may include a random access response (RAR). The RAR may include downlink control information (DCI) scrambled with a random access-radio network temporary identifier (RA-RNTI) corresponding to the PRACH occasion on which the preamble is transmitted. The DCI may include an RAR grant, which may include a time and frequency resource allocation for the WTRU 211, along with a modulation coding scheme (MCS) and transmit power control (TPC) commands. The msg2 may also include a preamble index so that the WTRU 211 can determine that the RAR is intended for itself (the WTRU 211). Upon receiving msg2 containing the RAR, the WTRU 211 decodes it.

[0062] At 203, the WTRU 211 may proceed to transmit a data packet (e.g., a PDU) based on whatever has been processed from msg2. The WTRU 211 may scramble the data with a Temporary Cell-Radio Network Temporary Identifier (TC-RNTI) and send this as msg3 according to the scheduled resources given in the RAR grant.

[0063] At 204, the gNB 212 may return msg4, which may be a contention resolution message. When the WTRU 211 receives msg4, it may compare its TC-RNTI sent in msg3 with the WTRU identity received in msg4. A contention may occur when two WTRUs select the same preamble and both listen for the same RAR grant, which causes the WTRUs to transmit msg3 on the same resource. If a collision occurs, the WTRU may attempt another RACH procedure. The last two messages, msg3 and msg4, may assist with collision resolution.

[0064] In a different approach, the RACH procedure may be completed with only two messages, which may simplify the four-step RACH procedure to a two-step RACH procedure. As discussed herein, the RACH procedure may also be referred to as a random access (RA) procedure or a #-step RA (where # is 2 or 4).

[0065] In general, as described herein, the information associated with each msg# may be interchangeable (eg, msg1 refers to the random access preamble, and so on).

[0066] FIG. 3 illustrates an exemplary baseline signal structure for a two-step RACH. In this two-step RACH procedure, a first msgA 301 may include msg1 (e.g., preamble 311) and msg3 (e.g., payload 312) sent together. As shown, msgA may be composed of a preamble 311 (e.g., NR PRACH preamble) and a payload 312. Furthermore, msgA may be time division multiplexed (TDM) 313, and the payload 312 is transmitted on the NR PUSCH using the NR demodulation reference signal (DMRS). In a second step, msgB 302 may include msg2 and msg4. A single step of msgB may achieve the functions of msg2 and msg4 and may include control information. For example, the control information may be one or more of the following: namely, ACK / NACK, which may be in response to the preamble, payload, or both; Timing Advance (TA), which may require only an index according to a preconfigured table; PUSCH scheduling information, which may be defined according to a preconfigured table and require only an index; Preamble Selection, which may be a flag whose presence initiates preamble reselection; MCS, which may be limited to a few basic options; Power Adjustment, which may be in the form of TPC; and / or a flag whose presence indicates to increase the power by a preconfigured value.

[0067] In general, in a two-step RACH procedure, the msgB process and its indication mechanism may perform equivalent or similar functions to the four-step msg2 and msg4 and may address possible use cases of two-step RACH. However, in a two-step RACH approach, there may be one or more issues resulting from combining msg2 and msg4 into one step of msgB. These issues may include: a low-overhead indication mechanism to support contention resolution; a mechanism for ACK / NACK indication and decision for msgA; a mechanism for group-common / WTRU-specific ACK / NACK indication and decision; and / or a mechanism for monitoring msgB and switching between two-step RA and four-step RA. These issues may be addressed in one or more embodiments herein.

[0068] 4 is a process diagram illustrating an example of a two-step RACH. At 401, the WTRU 411 transmits msgA. Upon receiving msgA, the gNB 412 may process the preamble to determine the correct timing of the boundaries of the received payload. The gNB 412 may process the payload using the determined timing for detection and decoding. The gNB 412 may then send msgB at 402 in response to attempting or completely processing msgA.

[0069] If the payload is successfully decoded, the WTRU may receive an acknowledgement message in msgB indicating that msgA was successfully decoded.

[0070] In some cases, the WTRU may receive a TA update in msgB to be applied to a potential follow-up transmission. The WTRU may also receive other transmission parameters (e.g., a TPC command for the preamble portion of msgA, a TPC command for the payload portion of msgA, or a TPC command for both).

[0071] If the payload is not successfully decoded by the gNB, the WTRU may receive a control message in msgB and update its TA value. Such a control message may be directed to a preamble group. For example, the control message or a component thereof (e.g., CRC) may be scrambled using an identifier tied to the preamble group. In some cases, the preamble group may be defined based on an estimated distance inferred from WTRU measurements (e.g., path loss, etc.). In some cases, the control message may be broadcast and may include an identification of the preamble group. The WTRU may also or alternatively receive other control information (e.g., TPC commands for the preamble portion of msgA, the payload portion of msgA, or both).

[0072] In some cases, the WTRU may be configured with one or more CORESETs and / or search spaces (e.g., during initial access as part of a SIB), and one CORESET and / or search space may be dedicated to receiving a preamble group PDCCH. The WTRU may determine at least one parameter (e.g., its timing) of the CORESET and / or search space based on parameters of the preamble and / or parameters of the random access resource used to transmit the preamble. In some cases, the WTRU may retransmit the payload using the received configuration.

[0073] The WTRU may receive a message in msgB containing a grant for retransmission of the payload. The grant may indicate to the WTRU that the preamble was received without ambiguity but the payload needs to be retransmitted. In some cases, the network may provide parameters for the retransmission in msgB. The indicated parameters may be directly indicated or may be relative to the original transmission. For example, the retransmission grant may indicate to reduce the MCS from the MCS used in the original transmission.

[0074] As discussed herein, the payload of msgA may consist of at least two parts, such as UCI and data. The UCI may be used by the WTRU to indicate parameters of the transmission of the data (e.g., MCS, DM-RS configuration, resource allocation, TCI state, etc.). The gNB may be able to decode the UCI but determine a NACK for the data portion of the transmission. The WTRU may receive an indication in msgB to retransmit the data without the UCI. For example, the indication may provide a new transmission parameter set that overrides the transmission parameters selected by the WTRU for the original transmission.

[0075] In the case of unlicensed operation, the WTRU may receive an indication that a transmission failed due to a hidden node problem. Such an indication may be used to signal the WTRU to use a more robust Listen Before Talk (LBT) procedure or to retransmit at higher power.

[0076] If the WTRU does not receive the control message within a specified period, it may restart the process. For retransmission, the WTRU may modify parameters of the preamble and / or payload. For example, power ramping may be used for the preamble and / or payload.

[0077] The received msgB may include an information element. The information element may be in the form of a decoded DCI, a PDSCH message, a sequence, or a combination thereof. In some cases, the information element may be composed of at least one or more of the information discussed herein. In some cases, the content of the information element may be quantized or classified based on a dimension of its content to refer to a specific value or a combination of values ​​for multiple pieces of information.

[0078] In some cases, the information element is N The information element may be an N-bit binary message that may support M different dimensions or states. In some cases, the information element may be selected from a pool of M sequences supporting at most M different dimensions or states. In an example, different states of the information element may point to different values ​​of TA. In some cases, different states of the information element may determine different combinations of two or more of the contents (e.g., ACK / NACK, TA, etc.).

[0079] The success of msgA transmission depends on the preamble and payload portions being successfully transmitted. For a retransmission of msgA, it would be desirable to know which part of msgA failed so that the correct adjustments can be made for the retransmission. It would be possible to have separate ACK / NACK feedback for the preamble and the payload, but this may require excessive overhead and delays in the process.

[0080] FIG. 5 is a flow diagram illustrating an example of WTRU behavior for an efficient ACK / NACK process.

[0081] In general, the WTRU may receive one or more 2RA-RNTI values ​​that may be used for the two-step RACH. The 2RA-RNTI may be a subset of the RA-RNTI or a different set. In one example, at least one of the 2RA-RNTIs is reserved for preamble NACK. The WTRU may select one of the configured preambles for the msgA transmission. The selected preamble may be identified by a preamble ID. In one example, the WTRU may select one of the configured preambles according to one of the received RA-RNTIs and / or another system parameter.

[0082] First, the gNB may receive msgA from the WTRU. The gNB may send msgB back to the WTRU at 501. At 502, the WTRU may determine whether there is an ACK or a NACK in msgB.

[0083] If the gNB successfully detects the preamble and payload, msgB contains an ACK indicating the success of the 2-step RACH 503.

[0084] If the gNB detects the preamble but fails to decode the payload, then at 504 the WTRU processes msgB including a NACK and the preamble ID indicating successful detection of the preamble but unsuccessful decode of the payload. The preamble ID of the detected preamble may be indicated explicitly or implicitly. In some cases, the preamble ID may be indicated directly as content of msgB. In some cases, the preamble ID may be used to scramble the CRC of the received msgB payload. Upon the indication of payload decoding failure, at 506 the WTRU may make adjustments to its payload transmission parameters. For example, the WTRU may make changes to one or more of the MCS, payload power, PUSCH resources, etc. The WTRU may not make any adjustments to its preamble portion of msgA.

[0085] If the gNB fails to detect both the preamble and the payload, the WTRU processes the NACK transmitted alone or scrambled with the reserved 2RA-RNTI for the preamble NACK at 504. Upon indication of preamble decoding failure, the WTRU may make adjustments to its preamble transmission parameters at 505. For example, the WTRU may make changes to one or more of the preamble sequence, preamble power, TA, etc. The WTRU may not make any adjustments to its payload portion of msgA.

[0086] After adjustment, whether the NACK type is preamble or payload, the WTRU may then retry 507 the two-step RACH process.

[0087] FIG. 6 is a flow diagram illustrating an example of WTRU behavior for an efficient ACK / NACK process. In one approach, instead of relying on having different preambles or payload NACKs that can be distinguished by RNTI, the WTRU may rely on one or more associated control information elements to distinguish between different NACK types. As shown, depending on the type of associated content (e.g., TA or MCS), two different outcomes may result. The presence of associated control information provides updated values ​​of TA and MCS in this example.

[0088] Initially, the gNB may receive msgA from the WTRU. In response to successful transmission of msgA, at 601, the gNB may send msgB back to the WTRU, where the WTRU may receive and decode different combinations of control information in msgB. The WTRU may use the received combination of information as an implicit indication of other events. Specifically, at 602, the WTRU may determine whether there is an ACK or a NACK in msgB by decoding the received information elements.

[0089] If the gNB is able to decode the received information element, msgB, contains an ACK and the two-step RACH is successful (603).

[0090] If the WTRU receives a NACK at 604 with new PUSCH scheduling information and / or MCS and / or power commands, it may determine at 608 that preamble detection was successful but PUSCH (e.g., payload) detection was unsuccessful. In the illustrated example, the WTRU has received the MCS. Thus, at 609, a new set of PUSCH resources and an updated MCS may be indicated for the next msgA PUSCH transmission. The WTRU may also increase the payload power. Adjustments of other parameters may be at the discretion of the WTRU.

[0091] If the WTRU receives a NACK with the TA and / or preamble and / or power command at 604, it may determine that preamble detection was not successful at 605. Thus, an updated TA, preamble change command, and power command for the preamble may be indicated for the next msgA PUSCH transmission at 606. Adjustments of other parameters may be at the discretion of the WTRU (e.g., a new set of PUSCH resources, and MCS).

[0092] In either case, if an update is indicated, at 607, the WTRU may retry the 2-RACH.

[0093] For a contention-based two-step RACH, when msgA containing a random access preamble (e.g., PRACH) and data (e.g., msg3 containing a WTRU ID, an RRC connection request, etc.) is transmitted, the WTRU may start a random access response (RAR) window at the first expected PDCCH monitoring occasion from the end of the msgA transmission. Within the RAR window, the WTRU may monitor for the presence of a PDCCH and corresponding PDSCH associated with msgB.

[0094] In some cases, during a two-step RACH procedure, the WTRU may assume that the gNB has successfully detected the random access preamble in msgA (e.g., ACK for the RACH preamble) but not successfully received the msg3 information (i.e., payload portion) of msgA (e.g., NACK for msg3) or contention resolution is not successful if one or more of the following conditions are met: (i) The WTRU can detect the PDCCH associated with msgB carrying DCI format 1_0 with CRC scrambled with RA-RNTI. Here, if the gNB successfully received msgA, it may already have knowledge of the WTRU-ID and may not need to address the WTRU using RA-RNTI; (ii) The WTRU may be able to detect the PDCCH associated with msgB but not be able to successfully decode and detect the corresponding PDSCH (e.g., msg2 and msg4) carrying WTRU contention resolution, timing advance, etc.

[0095] Detection of the PDCCH associated with msgB may be considered by the WTRU as an implicit signaling of an acknowledgment of the random access preamble from the gNB, or equivalently, a partial msgA reception.

[0096] In some cases, the WTRU may check the DCI field associated with msgB, and if the field is set to a pre-specified value (e.g., set to all "0"s or "1"), the WTRU may check whether the random access preamble in msgA (e.g., msg1) was successfully detected and / or whether msg3 for the two-step RACH was successfully received.

[0097] In an example, confirmation of successful reception of msgA for a detected DCI may be achieved if all or a subset of the fields of DCI format 1_0 associated with msgB are set, for example according to Table 1 below. The WTRU may consider that it has detected the PDCCH associated with msgB but has not successfully detected the scheduling information for the corresponding PDSCH carrying contention resolution for the two-step RACH.

[0098] [Table 1]

[0099] 7 is a flow diagram illustrating an example WTRU procedure associated with a two-step RACH, where the WTRU detects within the RAR window a DCI associated with msgB that includes a downlink assignment. During the two-step RACH procedure, the WTRU may detect within the RAR window 701 a PDCCH associated with msgB. If the WTRU determines at 702 that there is no DL grant in the DCI, the WTRU may follow at 703 a procedure related to a UL grant for the DCI associated with msgB. If there is a DL grant in the DCI at 702, and the DCI is addressed by the RA-RNTI at 704, the WTRU may follow the following: That is, at 705, the random access preamble transmitted in msgA is successfully received (e.g., ACK for msg1), at 706, the msg3 information (e.g., PUSCH payload) transmitted in msgA is not received or detected (e.g., NACK for msg3), at 707, contention resolution for the WTRU is not completed (e.g., the WTRU contention resolution identification transmitted in msgB does not match the WTRU-ID transmitted in msgA), and / or at 708, the two-step random access procedure is not successfully completed.

[0100] If, at 704, the DCI is not addressed by the RA-RNTI but is directed to an R-RNTI, a C-RNTI, a CS-RNTI, or a Temporary C-RNTI, and the WTRU successfully detects the corresponding PDSCH associated with msgB, then the following may follow: at 709, the WTRU may consider the random access preamble (e.g., msg1) transmitted in msgA to have been successfully detected by the gNB, the detected and decoded msg3 information was successfully transmitted in msgA, contention resolution for the WTRU has been successfully completed (e.g., the WTRU contention resolution identification transmitted in msgB matches the WTRU ID transmitted in msgA), and / or the two-step random access procedure has been successfully completed.

[0101] If the RAR window expires and the WTRU does not detect a PDCCH directed to either the RA-RNTI, C-RNTI, CS-RNTI, Temporary C-RNTI, or WTRU-ID, or if the WTRU does not correctly decode the corresponding transport block, the WTRU may assume that msgA was not received by the gNB and the two-step random access procedure was not successful (not shown). In this case, the WTRU may retransmit msgA while performing one or more of the following actions: incrementing a preamble transmission counter for msgA, selecting a new random access preamble for msgA, selecting a random backoff time for retransmitting msgA after the backoff time, performing a two-step random access resource selection procedure, flushing the HARQ buffers used for transmitting msg3, and / or retransmitting msgA.

[0102] In some cases, the WTRU may receive a flag in the DCI associated with msgB that indicates to the WTRU whether msgA for the 2-step RACH was fully or partially received at the gNB. If the WTRU successfully detects and decodes within the RAR window the RA-RNTI, C-RNTI, CS-RNTI, Temporary C-RNTI, or PDCCH associated with msgB directed to the WTRU-ID, the WTRU may use information in the DCI, such as the new data indicator (NDI) (e.g., toggled or not toggled), to determine whether the entire msgA or a portion of msgA (e.g., the random access preamble or msg3) was successfully received at the gNB.

[0103] If the NDI in the DCI associated with msgB is not toggled, the WTRU may assume that the entire msgA was not successfully received at the gNB and the two-step random access procedure was not successful. In an example, if the NDI in the DCI associated with msgB is toggled, the WTRU may assume that the entire msgA or a portion of msgA was successfully received at the gNB.

[0104] 8 is a flow diagram illustrating an example WTRU procedure associated with a two-step RACH, where the DCI may include an uplink grant. At 801, the WTRU detects a PDCCH within the RAR window and receives a DCI associated with msgB. If the DCI does not include an uplink grant at 802, the WTRU may detect and decode a corresponding PDSCH carrying msgB at 804. In some cases, the DCI at 802 includes an uplink grant (e.g., DCI format 0_1) rather than a downlink assignment associated with msgB (e.g., FIG. 7).

[0105] At 803, if the PDCCH associated to msgB carrying the uplink grant is addressed by the RA-RNTI, the following may apply: the msg3 information part of msgA was not successfully received at the gNB (e.g., HARQ NACK for msg3), the uplink grant is for a retransmission of msg3 on PUSCH, the two-step random access procedure was not successful, and the gNB switches the WTRU from a two-step RACH to a four-step RACH procedure.

[0106] If the PDCCH associated with msgB carrying the uplink grant at 803 is not addressed by the RA-RNTI, then the DCI may be directed to the C-RNTI, CS-RNTI, or WTRU-ID at 809. Then, the following may follow: the msg3 information part of msgA is successfully received at the gNB at 810 (e.g., HARQ ACK for msg3), contention resolution for this two-step random access procedure is successful at 811, and / or the two-step random access procedure is successful at 812.

[0107] In either case, the WTRU may determine what follows after step 803 based on the decision made at 803.

[0108] In general, the WTRU may detect the PDCCH and corresponding PDSCH associated with msgB, and the PDSCH may explicitly indicate to the WTRU that the random access preamble or msg3 information (e.g., for contention resolution) was not successfully received at the gNB.

[0109] In NR with 4-step RACH, when a packet is transmitted from a WTRU on PUSCH and not successfully decoded at the gNB, the gNB may send DCI format 0_1 ​​with CRC scrambled with RA-RNTI to request a retransmission from the WTRU. If many WTRUs are simultaneously involved in a 2-step RACH procedure over common or shared PUSCH resources, one or more WTRUs may complete their msgA preamble PRACH transmission during the same time occasion, but one or more WTRUs may fail the payload transmission portion of msgA. Some WTRUs may expect a response from the gNB via an individual msgB, but this may require a large downlink overhead. msgA may be received incorrectly at the gNB due to either preamble collisions or PUSCH detection failures.

[0110] In one approach, the content of msgB may be interpreted differently depending on whether it is transmitted in a common search space or a WTRU-specific search space, which may enable the gNB to reduce the amount of downlink signaling by addressing the preamble and PUSCH missed detection problems separately.

[0111] The WTRU may interpret msgB received in the group common search space as a preamble collision. Since a preamble collision affects multiple WTRUs, the group common search space may reduce the amount of signaling. When multiple WTRUs select the same preamble for msgA transmission, the gNB may detect the collision and may reply in the group common search space to trigger a preamble reselection procedure.

[0112] If the gNB does not detect a preamble collision, but the payload portion of msgA for one or more WTRUs fails, then msgB may be sent in a WTRU-specific search space. The WTRU-ID used by the gNB to transmit in the WTRU-specific search space may be derived from the preamble.

[0113] Since the WTRU may not necessarily be time aligned when transmitting the data payload portion of msgA, the gNB may be able to decode the preamble of msgA but not the PUSCH portion. Therefore, in some cases, it may be beneficial for the WTRU to fall back to a 4-step RA procedure. The WTRU may switch to the 4-step RA procedure and proceed to transmit msg3 if an uplink grant is provided, and / or after switching to the 4-step RA procedure, may select a RACH occasion and preamble associated with the 4-step RA procedure for msg1 retransmission. In some cases, the WTRU may switch from the 4-step RA procedure to the 2-step RA procedure.

[0114] In some cases, the WTRU may switch between 2-step RA and 4-step RA based on the legacy MAC RAR content in msgB or on receiving a legacy msg2 PDU. For example, if the WTRU receives a random access preamble ID (RAPID) and a legacy MAC RAR subPDU, the WTRU may switch to 4-step RA. If the WTRU does not receive a msgB PDU associated with a msgA transmission in a 2-step RA procedure, the WTRU may consider the receipt of a legacy msg2 PDU as a trigger for fallback.

[0115] In some cases, the WTRU may switch between 2-step RA and 4-step RA based on the contents of msgB or MAC RAR for 2-step RA. For example, if the contents of msgB include an uplink grant, the WTRU may switch to 4-step RA. An explicit bit in the contents of msgB may be used to indicate the switch to 4-step RA. For example, if the reserved bit "R" in the MAC RAR payload is flagged with a value such as "1", the WTRU may switch to 4-step RA. In an example, if the reserved bit "R" in the backoff MAC subPDU payload is flagged with a value such as "1", the WTRU may switch to 4-step RA.

[0116] In some cases, the WTRU may switch between 2-step RA and 4-step RA based on receiving only a RAPID MAC subPDU in msgB. For example, if the contents of msgB include only a MAC subheader with RAPID, the WTRU may switch to 4-step RA.

[0117] In some cases, the WTRU may switch between 2-step and 4-step RA based on receiving a backoff indication MAC subPDU in msgB or only receiving a backoff indication MAC subPDU in msgB. For example, if the contents of msgB include only a MAC subheader with backoff and the reserved bit in the MAC subPDU is flagged with a value such as "1", the WTRU may switch to 4-step RA.

[0118] In some cases, the WTRU may switch between 2-step RA and 4-step RA based on properties of the PDCCH scheduling msgB. For example, the WTRU may switch between 2-step RA and 4-step RA if msgB is received on a particular CORESET, search space, and / or RNTI. When separate RACH occasions are configured for 2-step RACH and 4-step RACH and the WTRU receives msgB on the PDCCH directed to the RA-RNTI associated with the RACH occasion for 4-step RA, the WTRU may switch to 4-step RA. Or vice versa, in which case it will switch to 2-step RA. The WTRU may monitor the RA-RNTI associated to fallback to 4-step RA and may monitor another RA-RNTI, or the C-RNTI if included in msgA, for continuation of the 2-step RA. If the WTRU includes its C-RNTI in msgA and msgB is scheduled on a PDCCH directed to the WTRU's C-RNTI, the WTRU may continue the RA procedure as a 2-step RA. If the WTRU includes its C-RNTI in msgA and msgB is scheduled on a PDCCH directed to the RA-RNTI associated with the RACH occasion (RO) on which the last preamble was transmitted, the WTRU may switch between 2-step and 4-step RA.

[0119] When 2-step and 4-step RAs are configured to share an RO, the WTRU may be configured with separate CORESET, search space, and / or RA-RNTI to distinguish between RARs intended for legacy WTRUs and RARs intended for WTRUs supporting 2-step RA. If a fallback RAR or a legacy MAC RAR or msg2 RAR is received on a CORESET, search space, and / or RA-RNTI not associated with a 2-step RA, the WTRU may switch back to 4-step RA. In such an example, the WTRU may monitor the CORESET, search space, and / or RA-RNTI associated with the fallback to 4-step RA in addition to those configured for the 2-step RA if it has selected a PRACH resource associated with a 2-step RA.

[0120] In some cases, the WTRU may switch between 2-step and 4-step RA based on the timing advance. In an example, the WTRU may switch between 2-step and 4-step RA if a timing alignment timer expires. In another example, the WTRU may switch between 2-step and 4-step RA if a timing advance (TA) command is received in the MAC RAR and / or if the indicated TA value or TA adjustment delta is greater than a configured TA threshold.

[0121] In some cases, the WTRU may switch between 2-step and 4-step RA based on the RRC mode. For example, the WTRU may monitor conditions for falling back or switching between 2-step RACH and 4-step RA when not in connected mode and / or not providing the C-RNTI portion of the msgA payload.

[0122] In some cases, the WTRU may switch between 2-step RA and 4-step RA based on an RA counter. The WTRU may switch between 2-step RA and 4-step RA based on the value of a "msgA counter" and / or a preamble transmission counter that the WTRU maintains as part of a given RA procedure. In an example, the WTRU may maintain an additional new counter, "msgA counter," which may be incremented with each 2-step RA attempt and reset when a new procedure starts or when the WTRU switches to 2-step RA. In an example, the WTRU may switch to 4-step RA if the msgA counter is greater than a threshold that may be configured by RRC and / or if the preamble transmission counter is greater than a threshold that may be configured by RRC. The WTRU may report a problem to higher layers or trigger an RLF if the msgA counter is greater than a threshold that may be configured by RRC and / or if the preamble transmission counter is greater than a threshold that may be configured by RRC.

[0123] In an example, if a counter associated with counting LBT failures for msgA reaches a threshold, which may be configured by the RRC, the WTRU may switch between 2-step RA and 4-step RA. For example, the MAC entity may receive an indication from the physical layer each time an LBT fails to transmit msgA, the preamble portion of msgA, and / or the payload portion of msgA. The WTRU may then keep counting the number of LBT failure indications received from the physical layer to determine whether to switch between 4-step RA and 2-step RA.

[0124] In some cases, the WTRU may switch between 2-step and 4-step RA based on uplink transmit power or RF conditions, for example, if the power headroom is less than a configured value or if a power ramping counter reaches a predetermined value, which may be configurable by the RRC.

[0125] In some cases, the WTRU may switch between 2-step RA and 4-step RA based on channel measurements (e.g., measured by the WTRU and / or by a network device such as a gNB. For example, the WTRU may switch between 2-step RA and 4-step RA if a reference signal received power (RSRP), a reference signal received quality (RSRQ), and / or a received signal strength indicator (RSSI) is greater than a threshold.

[0126] When switching between 2-step and 4-step RA, the WTRU may proceed to transmit msg3 on the provided uplink grant. The WTRU may reset the msgA counter after a time period or number of 4-step attempts configured by RRC. The WTRU may reset the preamble transmission counter and / or the power ramping counter.

[0127] When mapping of multiple RACH occasions to one PUSCH resource is configured, the gNB may decode the PUSCH but not the RACH, and the gNB may send msgB indicating two-step RA success for at least one WTRU whose identity was decoded in the data payload portion of msgA, but the gNB may not have decoded which RACH occasion was used by such WTRU. When mapping of more than one RACH occasion to one PUSCH resource is configured, the WTRU may monitor the PDCCH for msgB on all RA-RNTIs associated with RACH occasions mapped to the selected PUSCH resource for msgA. The WTRU may receive a msgB concluding two-step RA success on a different RA-RNTI than that associated with the selected RACH occasion for msgA.

[0128] Upon selecting a RACH occasion and / or preamble configured for 2-step RA, the WTRU may monitor the PDCCH for reception of msg2 for fallback in addition to msgB. The WTRU may monitor the PDCCH for msgB and msg2 over different CORESETs, search spaces, and / or RA-RNTIs depending on the RRC configuration. In an example, after a predefined number of 2-step RA attempts or when the conditions for using 2-step RA are no longer applicable (e.g., if channel conditions / measurements are below a threshold or uplink timing is not aligned), the WTRU may monitor the CORESET and / or RA-RNTI associated with msg2 reception.

[0129] In some cases, the WTRU may be configured by the RRC with two initial sets of back-off values ​​and / or back-off scaling factors. For example, upon receiving a BI subPDU in msgB, the WTRU may apply one set of back-off values ​​if msgA is transmitted and / or a RACH occasion / preamble configured for 2-step RA is selected. The WTRU may apply a second set of back-off values ​​if msg1 is transmitted and / or a RACH occasion / preamble configured for 2-step RA is selected.

[0130] The WTRU may implicitly determine an alternative back-off value from the indicated back-off indicator (BI) value, depending on at least one of the following: properties of the received msgB, msgB content, msgA content, RA start trigger, and / or whether the WTRU transmitted a data payload (e.g., whether msg1 for msgA was transmitted). For example, if the WTRU included its C-RNTI portion of msgA and / or a BI was received on a PDCCH directed to the C-RNTI or to a subset of the RA-RNTI, the WTRU may ignore the indicated back-off, scale it, or apply an alternative value that is mapped to the indicated BI. In another example, if the WTRU sent a data payload portion of msgA and / or the data payload in msgA is from a logical channel (LCH) with a logical channel prioritization (LCP) priority higher than a configured threshold, the WTRU may ignore the indicated back-off, scale it, or apply an alternative value that is mapped to the indicated BI. In another example, if the WTRU sent a preamble and / or selected a RACH occasion configured for 2-step RA and / or received a BI on a PDCCH associated with an RA-RNTI corresponding to a RACH occasion configured for 2-step RA, the WTRU may ignore the indicated back-off, scale it, or apply an alternative value that is mapped to the indicated BI. The WTRU may apply the alternative back-off value as described above on the indication bits in the back-off subPDU.

[0131] In some cases, the WTRU may ignore the subPDU containing RAPID or the legacy msg2 PDU if the WTRU sent a preamble, selected a RACH occasion configured for 2-step RA, transmitted a payload in the PUSCH portion of msgA, and / or included the C-RNTI portion of the msgA content. The WTRU may consider the 2-step RA successful if it receives a MAC RAR subPDU containing the WTRU's identity included in the msgA content for contention resolution. The WTRU may consider the subPDU containing RAPID or the legacy msg2 PDU for fallback to 4-step RA if no other MAC RAR subPDU with WTRU identity included in the payload of msgA is received. If an uplink grant is received in the MAC RAR associated with the 2-step RA attempt, the WTRU may further consider the 2-step RA procedure successful when an ACK is determined or received for the PDU transmitted on this uplink grant. The WTRU may ignore uplink skipping for such an uplink grant, even if the WTRU has no buffered data to transmit.

[0132] FIG. 9 is a process diagram illustrating an example of a Beam Failure Recovery (BFR) procedure with multiple beam monitoring.

[0133] In general, the WTRU may implement BFR using a two-step RA procedure. The two-step RA procedure may be contention-based. The WTRU may include an identification of a preferred SSB and / or a preferred channel state information reference signal (CSI-RS) in part of the msgA data payload. The number of preferred identities reported may be pre-configured or pre-determined by the RRC. The WTRU may select any RACH occasion and / or preamble configured for the two-step RA, regardless of the mapping of synchronization signal blocks (SSBs) to RACH occasions and / or preambles that is configured if the WTRU provided an identification of a preferred SSB and / or CSI-RS. The WTRU may include measurements associated with a preferred beam in part of the msgA data payload. For example, the WTRU may include RSRP, RSSI, signal-to-interference-and-noise ratio (SINR), block error rate (BLER), or bit error rate (BER) measurements in the payload of msgA.

[0134] When the BFR timer expires, the WTRU may remove the selection of SSB and / or CSI-RS that were selected before the expiration of the timer portion of the RA procedure. The WTRU may fall back to 4-step RA or contention-based random access (CBRA) when the timer expires. When the timer expires, the WTRU may consider a specific set of PUSCH resources for transmitting the payload of msgA.

[0135] If an uplink grant is received in a MAC RAR associated with a two-step RA attempt, the WTRU may consider the BFR procedure successful when an ACK is determined or received for the PDU transmitted on this uplink grant. If no uplink grant is provided in the MAC RAR, the WTRU may consider the BFR procedure successful when msgB is successfully received with the WTRU's C-RNTI (or the identity provided in msgA) as part of the msgB content and / or when the WTRU successfully receives a PDCCH directed to that C-RNTI.

[0136] As shown in the BFR example of FIG. 9, at 901, a WTRU 912 may detect beam failure from the network / gNB 911. After the beam failure, the WTRU may monitor a PDCCH search space, where a transmission configuration indication (TCI) associated with the search space may be from a set of already configured reference signal (RS) resources (e.g., SSB or CSI-RS). The RS resource set may include an RS group that may be configured for monitoring after beam failure detection. The RS resource set may include the same or a different set of RSs that the WTRU was monitoring before the beam failure. Each RS may be associated with a set of preambles, and each RS may correspond to a different beam.

[0137] In some cases, upon detecting a beam failure, the WTRU may select and send a preamble associated with one of the RSs to indicate which downlink beam to use for the gNB response. The WTRU may determine a preferred subset of RSs based on a measured signal quality (e.g., RSRP, SINR) being higher than a configured threshold. At 902, the WTRU may send a msgA payload to the gNB, where the WTRU may include the preferred subset in the msgA payload. The payload may also include the measured signal quality metric or a ranking of the measurements (such as from strongest to weakest RS).

[0138] The indication of the RSs in the preferred subset may include one or more CSI-RS resource indexes (RIs) (CRIs) or SSBRIs. The WTRU may also include quality measurements (e.g., RSRP, SINR) of the RSs in the preferred subset in the msgA payload. For example, the preferred subset may include SSB1 and SSB2, which the gNB may send in a TDM manner. The WTRU may send a preamble for msgA associated with SSB1, and the msgA payload may include RSRP measurements for SSB1 along with SSBRI for SSB2 with RSRP measurements for SSB2 (e.g., at 902). The gNB may receive the msgA preamble and may decode the msgA payload to determine whether the WTRU included a preferred subset of RSs.

[0139] In some cases, if the payload includes additional RS indices, the gNB may decide to send the msgB response on either RS, e.g., relying on the same spatial filter as SSB1 or SSB2. The gNB may determine which RS to use with WTRU assistance based on the index received in msgA. If the payload does not include any additional indices, the gNB may send the msgB response based on the RS (e.g., beam) associated with the msgA preamble.

[0140] At 903, the WTRU may monitor for PDCCH transmissions on configured RS resources associated with all indicated beams, which may correspond to the search space or CORESET associated with the RS to which the msgA preamble is sent. The WTRU may monitor for PDCCH on any of the search spaces or CORESET associated with the RS reported in the msgA payload. The WTRU may stop monitoring the PDCCH after detecting the msgB response.

[0141] For example, the WTRU may monitor for a response associated with the SSB1 or SSB2 transmission occasion. At 904, the BFR procedure may be considered successful and completed when the WTRU decodes msgB, which includes the WTRU's C-RNTI. In some examples, the PDCCH may be addressed using a common RNTI (e.g., DCI scrambled with the RA-RNTI), and the WTRU may decode msgB to determine whether its C-RNTI is included in the msgB payload. The PDCCH may include an indication of available time / frequency resources for PUCCH transmission. The WTRU may use the PUCCH resources to send (e.g., declare) a UCI including an ACK that acknowledges receipt of msgB, which confirms the completion of the beam failure recovery procedure.

[0142] As previously discussed herein, the WTRU may send msgA to the gNB and receive msgB from the gNB in ​​response to msgA. The WTRU may determine whether contention resolution was successful based on the msgB response.

[0143] The msgB may include a DCI scrambled with the msgB-RNTI. The WTRU may monitor for the msgB DCI to determine if the gNB included a payload in the PDSCH. After decoding the DCI, the WTRU may determine the PDSCH resource that contains the msgB payload. The WTRU may decode the payload, and the WTRU may look up its user identity to determine if the contention resolution was successful. If the contention resolution was successful, the WTRU may send a HARQ-ACK response on the PUCCH resource.

[0144] The WTRU may determine the PUCCH resource based on a PUCCH resource index, which may be determined based on a PUCCH resource indicator (PRI) and a PDSCH-HARQ feedback indicator, which may be included as part of the DCI payload included in msgB (e.g., in DCI format 1_0 or DCI format 1_1).

[0145] The PDSCH-HARQ feedback indicator may be mapped to a value from the set {1, 2, 3, 4, 5, 6, 7, 8}, which corresponds to a slot offset from the PDSCH reception. The WTRU may determine the timing of the slot for transmitting the PUCCH resource.

[0146] The PUCCH resource index is defined as Equation 1.

[0147]

number

[0148] In the above formula, r PUCCH is the PUCCH resource index, and R PUCCH is the size of the PUCCH resource list, and N CCE,p is the number of CCEs in CORESET p for PDCCH reception in the case of DCI format 1_0 or DCI format 1_1, and n CCE,p is the index of the first CCE for PDCCH reception, and Δ PRI is the value of the PUCCH resource indicator field in DCI format 1_0 or DCI format 1_1.

[0149] The WTRU may determine parameters for the PUCCH transmission based on the PUCCH resource index.

[0150] R PUCCH , N CCE,p , p, and n CCE,p may be a value configured by the RRC and may not be WTRU specific. PRImay be explicitly included in the DCI to define the PUCCH resource WTRU-specifically. If the msgB payload contains only one WTRU, then the single PRI and PDSCH-HARQ feedback indicator value included in the DCI may uniquely determine the PUCCH resource for the WTRU. However, if more than one WTRU is multiplexed into msgB, then more than one WTRU may receive the same DCI directed to msgB-RNTI and may use the single PRI and PDSCH-HARQ feedback indicator to determine the PUCCH resource, which may be the same for all WTRUs. This may cause collisions and the HARQ-ACK feedback may not be received at the gNB.

[0151] In one approach, the WTRU may implicitly determine the PUCCH resource index based on a random access preamble index or identifier (RAPID) and / or a PRI. The WTRU may determine the PUCCH resource index as a function of the same parameters as from Equation 1, and also using RAPID, as follows:

[0152]

number

[0153] In one approach, the WTRU may implicitly determine the PUCCH resource index based on RAPID and PRI. The WTRU may determine the PUCCH resource index as a function of the same parameters as from Equation 1, and also using RAPID, as follows:

[0154]

number

[0155] In the above equation, f(RAPID,Δ PRI ) is RAPID and Δ PRIto a WTRU specific PRI.

[0156] RAPID is PUCCH The DCI may serve to randomize the PRI value. For example, multiple WTRUs may send msgA with different preamble selections. msgB may successfully receive all msgA and multiplex responses to multiple WTRUs into one msgB. The DCI may contain a single PRI value intended for multiple WTRUs. If contention resolution is successful, the WTRU may use RAPID to PUCCH The selection may be randomized. Each WTRU is assigned a unique r PUCCH The HARQ-ACK may be sent without collision, and may be linked to a value.

[0157] The link between RAPID and PUCCH resources may be configured to be a one-to-one mapping. PUCCH A WTRU-specific Δ PRI may be generated, where RAPID may be a seed input to a generator function.

[0158] In some cases, the WTRU may implicitly determine the slot timing of the PUCCH feedback based on the PDSCH-HARQ feedback indicator and RAPID. Similar to the PUCCH resource index, the WTRU may use RAPID to randomize the slot timing, which may avoid collisions based on a single PDSCH-HARQ feedback indicator.

[0159] The link between RAPID and the PDSCH-HARQ feedback indicator may be configured to be one to one. A WTRU-specific PDSCH-HARQ feedback indicator value may be generated, where RAPID may be a seed input to a generator function.

[0160] The WTRU isPUCCH , the PDSCH-HARQ feedback indicator, or both, may be determined based on the above. For example, the PDSCH-HARQ feedback indicator may be a single value taken from the DCI, r PUCCH may be determined using PRI and RAPID. Multiple WTRUs may transmit in the same timeslot, but on different PUCCH resources. Similarly, the same PRI may be used by multiple users on different timeslots, with a PDSCH-HARQ feedback indicator generated by the WTRU specifically using RAPID.

[0161] Although features and elements are described above in a particular combination, one skilled in the art will understand that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) 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 in conjunction with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0162] As discussed herein, WTRU, UE, and user may be used interchangeably. gNodeB and gNB may be used interchangeably. Reference symbols may be used to refer to symbols such as complex numbers that are fixed and known as pilots and used. Reference signals may be used to refer to time domain signals that are generated after processing of reference symbols. For example, in OFDM, reference symbols are complex numbers that are fed into an IDFT block, and reference signals are the output of the IDFT block. Downlink control information (DCI) is a set of bits transmitted over the PDCCH to a user or group of users. A resource element (RE) is one OFDM symbol on one subcarrier, and a resource element group (REG) refers to a group of REs that are used as building blocks of control channel elements (CCEs) that assign resource elements to users. Adjacent REGs in time or frequency that are grouped together and have the same associated precoder are referred to as a REG bundle. NR-REG, NR-CCE, and NR-PDCCH may refer to REG, CCE, and PDCCH for NR in 5G. A control resource set (CORESET) is a set of resource elements used for the downlink control channel, configured by its frequency resources, its time length (e.g., represented in symbols), and its type of REG bundle. A search space, or set of search spaces, is a set of PDCCH candidates monitored by a WTRU or group of WTRUs during blind detection of the PDCCH. As discussed herein, the word several can mean one, multiple, or all.

Claims

1. 1. A method performed by a wireless transmit / receive unit (WTRU) for beam failure recovery (BFR), comprising: Detecting a beam failure associated with transmission or reception with a serving cell; receiving information indicative of a series of reference signals corresponding to a series of beams; determining information indicative of a subset of the set of reference signals based on one or more measurements; transmitting a first message including a preamble and a payload, the payload including an index of each reference signal in the subset of reference signals; receiving a second message of a physical downlink control channel transmission, the second message being a random access response to the first message, the second message including a Cell Radio Network Temporary Identifier (C-RNTI) of the WTRU, the inclusion of the C-RNTI in the second message indicating successful beam failure recovery, the second message being monitored on at least one beam associated with the first message; A method for providing the above.

2. The method of claim 1 , wherein the reference signal is a synchronization signal block (SSB) or a channel state information reference signal (CSI-RS).

3. The method of claim 1 , wherein the first message is transmitted based on detection of the beam failure on the serving cell as part of a random access procedure for beam failure recovery.

4. The method of claim 1 , wherein determining the subset of the set of reference signals is further based on the one or more measurements satisfying a threshold, the one or more measurements relating to signal quality.

5. 1. A wireless transmit / receive unit (WTRU), comprising: a processor operatively connected to the transceiver; The processor and the transceiver are configured to detect a beam failure associated with transmission or reception to or from a serving cell; the processor and the transceiver are configured to receive information indicative of a sequence of reference signals corresponding to a sequence of beams; the processor and the transceiver are configured to determine information indicative of a subset of the set of reference signals based on one or more measurements; The processor and the transceiver are configured to transmit a first message including a preamble and a payload, the payload including an index of each reference signal in the subset of reference signals; the processor and the transceiver are configured to receive a second message of a physical downlink control channel transmission, the second message being a random access response to the first message, the second message including a Cell Radio Network Temporary Identifier (C-RNTI) of the WTRU, the inclusion of the C-RNTI in the second message indicating successful beam failure recovery, and the second message being monitored on at least one beam associated with the first message. WTR U.

6. The WTRU of claim 5, wherein the reference signal is a synchronization signal block (SSB) or a channel state information reference signal (CSI-RS).

7. The WTRU of claim 5 , wherein the first message is transmitted based on detection of the beam failure on the serving cell as part of a random access procedure for beam failure recovery.

8. The WTRU of claim 5 , wherein determining the subset of the set of reference signals is further based on the one or more measurements satisfying a threshold, the one or more measurements related to signal quality.

9. The method of claim 1 , further comprising: sending a feedback message for the second message on a feedback resource, the second message further including an indication of the feedback resource.

10. The WTRU of claim 5 , wherein the processor and the transceiver are configured to transmit a feedback message for the second message on a feedback resource, the second message further including an indication of the feedback resource.

11. The method of claim 1 , wherein the radio network temporary identifier in a random access response is different from the C-RNTI.

12. The WTRU of claim 5, wherein the radio network temporary identifier of a random access response is different from the C-RNTI.

13. The method of claim 1 , wherein the second message is a DCI message.

14. The WTRU of claim 5 , wherein the second message is a DCI message.

15. The method of claim 1 , wherein the second message is designated as MsgB and the first message is designated as MsgA.

16. The WTRU of claim 5 , wherein the second message is denoted as MsgB and the first message is denoted as MsgA.

17. The method of claim 1 , wherein the wireless network temporary identifier of a random access response is used to decode the second message.

18. The WTRU of claim 5 , wherein the radio network temporary identifier of a random access response is used to decode the second message.

Images