Method for MSG-B in two-step RACH
阅读说明：本技术 两步rach中用于msg-b的方法 (Method for MSG-B in two-step RACH ) 是由 阿夫欣·哈吉卡特 沙罗克·纳伊卜纳扎尔 洛伊可·卡能尼-韦拉斯克兹 法里斯·阿尔法罕 J·帕 于 2020-02-13 设计创作，主要内容包括：本发明公开了用于传输混合自动重传请求确认(HARQ-ACK)的方法和装置。无线发射/接收单元(WTRU)可将随机接入信道(RACH)消息A传输到gNB。WTRU可从gNB接收响应于消息A的RACH消息B。消息B可包括下行链路控制信息(DCI)。WTRU可基于DCI来解码物理下行链路共享信道(PDSCH)。WTRU可确定争用解决成功。WTRU可确定用于物理上行链路控制信道(PUCCH)的资源。WTRU可在所确定的PUCCH资源上传输HARQ-ACK。WTRU可基于PUCCH资源索引来确定用于PUCCH的资源。PUCCH资源索引可基于随机接入前导码索引(RAPID)和PUCCH资源指示符(PRI)。(Methods and apparatus for transmitting hybrid automatic repeat request-acknowledgements (HARQ-ACKs) are disclosed. A wireless transmit/receive unit (WTRU) may transmit a Random Access Channel (RACH) message a to the gNB. The WTRU may receive RACH message B from the gNB in response to message a. The 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 the contention resolution is successful. The WTRU may determine resources for a Physical Uplink Control Channel (PUCCH). The WTRU may transmit a HARQ-ACK on the determined PUCCH resource. The WTRU may determine resources for the PUCCH based on the PUCCH resource index. The PUCCH resource index may be based on a Random Access Preamble Index (RAPID) and a PUCCH Resource Indicator (PRI).)
1. A method implemented by a Wireless Transmit Receive Unit (WTRU) for Beam Failure Recovery (BFR), the method comprising:
detecting a beam failure on a serving cell;
receiving reference signals corresponding to a set of beams;
determining a preferred subset of the reference signals based on measurements;
transmitting an msgA comprising a payload, wherein the payload comprises an index of the reference signal in the determined subset and a beam quality metric for each beam in the set of beams;
monitoring for a response to the msgA transmission;
receiving an msgB response to the msgA transmission, the msgB including a cell radio network temporary identity (C-RNTI) of the WTRU; and
determining BFR success based on the msgB.
2. The method of claim 1, wherein the beam quality metric comprises a Reference Signal Received Power (RSRP), a Received Signal Strength Indicator (RSSI), or a signal-to-interference-plus-noise ratio (SINR).
3. The method of claim 1, wherein the reference signal is a Synchronization Signal Block (SSB) or a channel state information reference signal (CSI-RS).
4. The method of claim 1, wherein the monitoring is performed on beams of the determined subset.
5. The method of claim 1, wherein the msgB comprises Downlink Control Information (DCI).
6. The method of claim 5, wherein the DCI is scrambled with the C-RNTI.
7. The method of claim 5, further comprising:
determining a resource for a PUCCH according to the DCI; and
slot timing for transmitting the HARQ-ACK on the determined PUCCH resource is determined.
8. A Wireless Transmit Receive Unit (WTRU), comprising:
a processor operatively connected to a transceiver, the processor and the transceiver configured to:
detecting a beam failure on a serving cell;
receiving reference signals corresponding to a set of beams;
determining a preferred subset of the reference signals based on measurements;
transmitting an msgA comprising a payload, wherein the payload comprises an index of the reference signal in the determined subset and a beam quality metric for each beam in the set of beams;
monitoring for a response to the msgA transmission;
receiving an msgB response to the msgA transmission, the msgB including a cell radio network temporary identity (C-RNTI) of the WTRU; and
determining a beam failure recovery success based on the msgB.
9. The WTRU of claim 8, wherein the beam quality metric comprises a Reference Signal Received Power (RSRP), a Received Signal Strength Indicator (RSSI), or a signal-to-interference-plus-noise ratio (SINR).
10. The WTRU of claim 8, wherein the reference signal is a Synchronization Signal Block (SSB) or a channel state information reference signal (CSI-RS).
11. The WTRU of claim 8, wherein the monitoring is performed on the beams of the determined subset.
12. The WTRU of claim 8, wherein the msgB includes Downlink Control Information (DCI).
13. The WTRU of claim 8, wherein the DCI is scrambled with the C-RNTI.
14. The WTRU of claim 8, the processor and the transceiver further configured to:
determining a resource for a PUCCH according to the DCI; and
slot timing for transmitting the HARQ-ACK on the determined PUCCH resource is determined.
Background
Within wireless communication technologies, there are Random Access Channel (RACH) procedures 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 a synchronization acquisition or handover. This process needs to be improved.
Disclosure of Invention
Methods and apparatus for transmitting hybrid automatic repeat request-acknowledgements (HARQ-ACKs) are disclosed. A wireless transmit/receive unit (WTRU) may transmit a Random Access Channel (RACH) message a to the gNB. The WTRU may receive RACH message B from the gNB in response to message a. The 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 the contention resolution is successful. The WTRU may determine resources for a Physical Uplink Control Channel (PUCCH). The WTRU may transmit a HARQ-ACK on the determined PUCCH resource. The WTRU may determine resources for the PUCCH based on the 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 slot timing for transmission of the HARQ-ACK. The slot timing may be based on the PDSCH-to-HARQ feedback indicator and RAPID.
Drawings
A more particular understanding can be obtained from the following description taken in conjunction with the accompanying drawings, in which like reference numbers indicate like elements, and wherein:
FIG. 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;
figure 1B is a system diagram illustrating an exemplary wireless transmit/receive unit (WTRU) that may be used within the communication system shown in figure 1A according to one embodiment;
fig. 1C is a system diagram illustrating an exemplary Radio Access Network (RAN) and an exemplary Core Network (CN) that may be used within the communication system shown in fig. 1A according to one embodiment;
figure 1D is a system diagram illustrating another exemplary RAN and another exemplary CN that may be used within the communication system shown in figure 1A according to one embodiment;
fig. 2 is a process diagram illustrating an exemplary information exchange between a WTRU and a gNB for a 4-step RACH procedure;
FIG. 3 is a schematic diagram showing an exemplary baseline of a signal structure for a 2-step RA;
fig. 4 is a process diagram illustrating an example of information exchange between a WTRU and a gNB for a 2-step RACH procedure;
figure 5 is a flow diagram illustrating an example of WTRU behavior for an efficient ACK/NACK procedure;
figure 6 is a flow diagram illustrating an example of WTRU behavior for an efficient ACK/NACK procedure;
fig. 7 is a flow diagram illustrating an exemplary WTRU procedure associated with a 2-step RA, where a UE detects DCI associated with MsgB within a RAR window containing DL assignments
Fig. 8 is a flow diagram illustrating an exemplary WTRU procedure associated with a 2-step RA, wherein the WTRU detects DCI associated with an msgB within a RAR window containing an uplink grant; and is
Fig. 9 is a process diagram illustrating an example of beam failure recovery with multiple beam monitoring.
Detailed Description
Fig. 1A is a schematic diagram illustrating an exemplary communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcast, etc., to a plurality of wireless users. Communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, 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), and so forth.
As shown in fig. 1A, the communication 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 is understood that any number of WTRUs, base stations, networks, and/or network elements are contemplated by the disclosed embodiments. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a Station (STA)) may be configured to transmit and/or receive wireless signals, and may include User Equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, Personal Digital Assistants (PDAs), smart phones, laptops, netbooks, personal computers, wireless sensors, hotspot or Mi-Fi devices, internet of things (IoT) devices, watches or other wearable devices, head-mounted displays (HMD), vehicles, drones, medical devices and applications (e.g., tele-surgery), industrial devices and applications (e.g., robots and/or other wireless devices operating in industrial and/or automated processing chain environments), consumer electronics, devices operating on commercial and/or industrial wireless networks, and so forth. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.
Communication system 100 may also include base station 114a and/or base station 114 b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114B may be Base Transceiver Stations (BTSs), nodebs, evolved node bs (enbs), home nodebs, home evolved node bs, next generation nodebs, such as a enode B (gNB), New Radio (NR) NodeB, site controllers, Access Points (APs), wireless routers, and so forth. Although the base stations 114a, 114b are each depicted as a single element, it should be understood that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.
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 Base Station Controllers (BSCs), Radio Network Controllers (RNCs), relay nodes, and so forth. Base station 114a and/or 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 a cell (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 to a particular geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, the cell associated with 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 per sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of a cell. For example, beamforming may be used to transmit and/or receive signals in a desired spatial direction.
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, etc.). Air interface 116 may be established using any suitable Radio Access Technology (RAT).
More specifically, as indicated above, communication system 100 may be a multiple-access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA), which may establish the air interface 116 using wideband cdma (wcdma). WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or evolved HSPA (HSPA +). HSPA may include high speed Downlink (DL) packet access (HSDPA) and/or high speed Uplink (UL) packet access (HSUPA).
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).
In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access that may use NR to establish the air interface 116.
In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may together implement LTE radio access and NR radio access, e.g., using Dual Connectivity (DC) principles. 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/from multiple types of base stations (e.g., eNB and gNB).
In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA 20001X, 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), and the like.
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 business, home, vehicle, campus, industrial facility, air corridor (e.g., for use by a drone), road, and so forth. 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-A, LTE-a Pro, NR, etc.) to establish the pico cell or the femto cell. As shown in fig. 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.
The RAN 104 may communicate with a CN 106, which may be any type of network configured to provide voice, data, application, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102 d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and so forth. The CN 106 may provide call control, billing services, mobile location-based 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 should be understood that the RAN 104 and/or the CN 106 may communicate directly or indirectly with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to connecting to the RAN 104, which may utilize NR radio technologies, the CN 106 may communicate with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technologies.
The CN 106 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the internet 110, and/or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides Plain Old Telephone Service (POTS). The internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and/or the Internet Protocol (IP) in the TCP/IP internet protocol suite. The network 112 may include wired and/or wireless communication networks owned and/or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.
Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks 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 radio technology, and with a base station 114b, which may employ an IEEE 802 radio technology.
Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in fig. 1B, the WTRU 102 may include 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 Global Positioning System (GPS) chipset 136, and/or other peripherals 138, among others. It should be understood that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.
The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), any other type of Integrated Circuit (IC), a state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120, which may be coupled to a transmit/receive element 122. Although fig. 1B depicts the processor 118 and the transceiver 120 as separate components, it should be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
Transmit/receive element 122 may be configured to transmit signals to and receive signals from a base station (e.g., base station 114a) over 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 RF and optical signals. It should be appreciated that transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
Although transmit/receive element 122 is depicted in fig. 1B as a single element, WTRU 102 may include any number of transmit/receive elements 122. More specifically, 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.
Transceiver 120 may be configured to modulate signals to be transmitted by transmit/receive element 122 and demodulate signals received by transmit/receive element 122. As noted 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 NR and IEEE 802.11.
The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker/microphone 124, a keypad 126, and/or a display/touch pad 128, such as 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. Further, the processor 118 may access information from, 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 Random Access Memory (RAM), Read Only Memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, a memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown).
The processor 118 may receive power from the power source 134 and may be configured to distribute and/or control power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, power source 134 may include one or more dry cell batteries (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, and the like.
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 the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) over the air interface 116 and/or determine its location based on the timing of the signals received from two or more nearby base stations. It should be appreciated that the WTRU 102 may acquire location information by any suitable location determination method while remaining consistent with an embodiment.
The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and/or hardware modules that provide additional features, functionality, and/or wired or wireless connectivity. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and/or video), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a microphone, and/or the like,A 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/or the like. Peripheral device 138 may include one or more sensors. The sensor may be one or more of: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, and a time sensor; a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, and the like.
The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with particular subframes for UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and/or simultaneous. A full-duplex radio may include an interference management unit to reduce and/or substantially eliminate self-interference via hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for which some or all signals are transmitted and received (e.g., associated with a particular subframe for UL (e.g., for transmission) or DL (e.g., for reception)).
Figure 1C is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the CN 106.
RAN 104 may include enodebs 160a, 160B, 160c, but it should be understood that RAN 104 may include any number of enodebs while remaining consistent with an embodiment. The enodebs 160a, 160B, 160c may each include one or more transceivers to communicate with the WTRUs 102a, 102B, 102c over the air interface 116. In one embodiment, the enode bs 160a, 160B, 160c may implement MIMO technology. Thus, for example, the enode B160 a may use multiple antennas to transmit wireless signals to the WTRU 102a and/or receive wireless signals from the WTRU 102 a.
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, and the like. As shown in fig. 1C, enode bs 160a, 160B, 160C may communicate with each other over an X2 interface.
The CN 106 shown in fig. 1C may include a Mobility Management Entity (MME)162, a Serving Gateway (SGW)164, and a Packet Data Network (PDN) gateway (PGW) 166. While the foregoing elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and/or operated by an entity other than the CN operator.
MME 162 may be connected to each of enodebs 162a, 162B, 162c in RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during initial attachment of the WTRUs 102a, 102b, 102c, and the like. MME 162 may provide a control plane function for switching between RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and/or WCDMA.
SGW 164 may be connected to each of enodebs 160a, 160B, 160c in RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102 c. The SGW 164 may perform other functions such as anchoring the user plane during inter-enode B handover, triggering paging when DL data is available to the WTRUs 102a, 102B, 102c, managing and storing the context of the WTRUs 102a, 102B, 102c, and the like.
The SGW 164 may be connected to a PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network (such as the PSTN 108) to facilitate communications between the WTRUs 102a, 102b, 102c and conventional landline communication devices. For example, the CN 106 may include or may 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.
Although the WTRU is depicted in fig. 1A-1D as a wireless terminal, it is contemplated that in some representative embodiments, such a terminal may use a wired communication interface (e.g., temporarily or permanently) with a communication network.
In a representative embodiment, the other network 112 may be a WLAN.
A WLAN in infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may have access or interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic to and/or from the BSS. Traffic originating outside the BSS and directed to the STA may arrive through the AP and may be delivered to the STA. Traffic originating from the STAs and directed to destinations outside the BSS may be sent to the AP to be delivered to the respective destinations. Traffic between STAs within a BSS may be sent through the AP, e.g., where a source STA may send traffic to the AP and the AP may pass the traffic to a destination STA. Traffic between STAs within a BSS may be considered and/or referred to as point-to-point traffic. Direct Link Setup (DLS) may be utilized to transmit point-to-point traffic between (e.g., directly between) a source and destination STA. In certain representative embodiments, DLS may use 802.11e DLS or 802.11z tunnel DLS (tdls). A WLAN using Independent Bss (IBSS) mode may not have an AP, and STAs within or using IBSS (e.g., all STAs) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.
When using an 802.11ac infrastructure mode of operation or a similar mode of operation, the AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may be a fixed width (e.g., a20 MHz wide bandwidth) or a dynamically set width. The primary channel may be an operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access with collision avoidance (CSMA/CA) may be implemented, for example, in 802.11 systems. For CSMA/CA, an STA (e.g., each STA), including an AP, may listen to the primary channel. A particular STA may back off if the primary channel is sensed/detected and/or determined to be busy by the particular STA. One STA (e.g., only one station) may transmit at any given time in a given BSS.
High Throughput (HT) STAs may communicate using a 40 MHz-wide channel, e.g., via a combination of a primary 20MHz channel and an adjacent or non-adjacent 20MHz channel to form a 40 MHz-wide channel.
Very High Throughput (VHT) STAs may support channels that are 20MHz, 40MHz, 80MHz, and/or 160MHz wide. 40MHz and/or 80MHz channels may be formed by combining consecutive 20MHz channels. The 160MHz channel may be formed by combining 8 contiguous 20MHz channels, or by combining two non-contiguous 80MHz channels (this may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel encoding, the data may pass through a segment parser that may split the data into two streams. Each stream may be separately subjected to Inverse Fast Fourier Transform (IFFT) processing and time domain processing. These streams may be mapped to two 80MHz channels and data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the above-described operations for the 80+80 configuration may be reversed, and the combined data may be transmitted to a Medium Access Control (MAC).
802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11 ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the television white space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using the non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter type control/Machine Type Communication (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., supporting only) certain bandwidths and/or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).
WLAN systems that can support multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah include channels that can be designated as primary channels. 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 STAs from all STAs operating in the BSS (which support the minimum bandwidth operating mode). In the 802.11ah example, for STAs (e.g., MTC-type devices) that support (e.g., only support) the 1MHz mode, the primary channel may be 1MHz wide, even though the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and/or other channel bandwidth operating modes. Carrier sensing and/or Network Allocation Vector (NAV) setting may depend on the state of the primary channel. If the primary channel is busy, for example, because STAs (supporting only 1MHz mode of operation) are transmitting to the AP, the entire available band may be considered busy even though most of the available band remains idle.
In the united states, the available frequency band for 802.11ah is 902MHz to 928 MHz. In korea, the available frequency band is 917.5MHz to 923.5 MHz. In Japan, the available frequency band is 916.5MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.
Figure 1D is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As indicated above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using NR radio technology. The RAN 104 may also communicate with the CN 106.
RAN 104 may include gnbs 180a, 180b, 180c, but it should be understood that RAN 104 may include any number of gnbs while remaining consistent with an embodiment. The gnbs 180a, 180b, 180c may each include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gnbs 180a, 180b, 180c may implement MIMO techniques. For example, the gnbs 180a, 108b may utilize beamforming to transmit signals to the gnbs 180a, 180b, 180c and/or receive signals from the gnbs 180a, 180b, 180 c. Thus, the gNB 180a may use multiple antennas to transmit wireless signals to the WTRU 102a and/or receive wireless signals from the WTRU 102a, for example. In one embodiment, the gnbs 180a, 180b, 180c may implement carrier aggregation techniques. 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 the unlicensed spectrum, while the remaining component carriers may be on the licensed spectrum. In one embodiment, the gnbs 180a, 180b, 180c may implement coordinated multipoint (CoMP) techniques. For example, WTRU 102a may receive a cooperative transmission from gNB 180a and gNB 180b (and/or gNB 180 c).
The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using transmissions associated with the set of scalable parameters. 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 various or extendable lengths (e.g., including different numbers of OFDM symbols and/or varying absolute lengths of time).
The gnbs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in an independent configuration and/or in a non-independent configuration. In a standalone configuration, the WTRUs 102a, 102B, 102c may communicate with the gnbs 180a, 180B, 180c while also not visiting other RANs (e.g., such as the enodebs 160a, 160B, 160 c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the 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 an unlicensed frequency band. In a non-standalone configuration, the WTRUs 102a, 102B, 102c may communicate or connect with the gnbs 180a, 180B, 180c, while also communicating or connecting with other RANs, such as the eNode-bs 160a, 160B, 160 c. For example, the WTRUs 102a, 102B, 102c may implement the DC principles to communicate with one or more gnbs 180a, 180B, 180c and one or more enodebs 160a, 160B, 160c substantially simultaneously. In a non-standalone configuration, the enodebs 160a, 160B, 160c may serve as mobility anchors for the WTRUs 102a, 102B, 102c, and the gnbs 180a, 180B, 180c may provide additional coverage and/or throughput for the serving WTRUs 102a, 102B, 102 c.
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 UL and/or DL, support of network slicing, interworking between DC, 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 through an Xn interface.
The CN 106 shown in fig. 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, 185 b. While the foregoing elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and/or operated by an entity other than the CN operator.
The AMFs 182a, 182b may be connected to one or more of the gnbs 180a, 180b, 180c via an N2 interface in the RAN 104 and may serve as control nodes. For example, the AMFs 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support of network slicing (e.g., processing of different Protocol Data Unit (PDU) sessions with different requirements), selection of a particular SMF 183a, 183b, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, and so forth. The AMFs 182a, 182b may use network slicing to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service used by the WTRUs 102a, 102b, 102 c. For example, different network slices may be established for different use cases, such as services relying on ultra-high reliable low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for MTC access, and so on. The AMFs 182a, 182b may provide control plane functionality for handover between the RAN 104 and other RANs (not shown) that employ other radio technologies (such as LTE, LTE-A, LTE-a Pro, and/or non-3 GPP access technologies, such as WiFi).
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 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 traffic routing through the UPFs 184a, 184 b. SMFs 183a, 183b may perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, etc. The PDU session type may be IP-based, non-IP-based, ethernet-based, etc.
The UPFs 184a, 184b may be connected via an N3 interface to one or more of the gnbs 180a, 180b, 180c in the RAN 104, which may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchors, etc.
The CN 106 may facilitate communications with other networks. For example, the CN 106 may include or may 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 one embodiment, WTRUs 102a, 102b, 102c may connect to DNs 185a, 185b through UPFs 184a, 184b via an N3 interface to UPFs 184a, 184b and an N6 interface between UPFs 184a, 184b and local DNs 185a, 185 b.
In view of the corresponding descriptions of fig. 1A-1D and 1A-1D, one or more, or all, of the functions described herein with reference to one or more of the following may be performed by one or more emulation devices (not shown): WTRUs 102a-d, base stations 114a-B, enodebs 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMFs 182a-B, UPFs 184a-B, SMFs 183a-B, DNs 185a-B, and/or any other device described herein. The emulation device can be one or more devices configured to emulate one or more or all of the functionalities described herein. For example, the emulation device may be used to test other devices and/or simulate network and/or WTRU functions.
The simulated device may be designed to implement one or more tests of other devices in a laboratory environment and/or an operator network environment. For example, the one or more simulated devices may perform one or more or all functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network to test other devices within the communication network. The one or more emulation devices can perform one or more functions or all functions while temporarily implemented/deployed as part of a wired and/or wireless communication network. The simulation device may be directly coupled to another device for testing purposes and/or perform testing using over-the-air wireless communication.
The one or more emulation devices can perform one or more (including all) functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the simulation device may be used in a test scenario in a test laboratory and/or in a non-deployed (e.g., testing) wired and/or wireless communication network to enable testing of one or more components. The one or more simulation devices may be test devices. Direct RF coupling and/or wireless communication via RF circuitry (which may include one or more antennas, for example) may be used by the emulation device to transmit and/or receive data.
In general, for any given wireless system (e.g., LTE, NR, etc.), such as those described in fig. 1A, 1C, and 1D, a WTRU may access the network using a random access procedure (e.g., switch synchronization once a cell is found, reestablish uplink synchronization, request scheduling, etc.). In some cases (e.g., LTE), there may be a 4-step Random Access Channel (RACH) procedure with four message (msg) exchanges between the WTRU and the base station (e.g., network/cell).
Fig. 2 is a process diagram illustrating an exemplary exchange between a WTRU 211 and a gNB 212 for a 4-step RACH procedure. At 201, the WTRU 211 may send msg1, which msg1 may be a randomly selected random access preamble sequence and may be transmitted during a physical rach (prach) opportunity. The WTRU 211 may monitor a control channel for msg2 (e.g., random access response).
Once msg1 is received by the gsb 212, the gsb 212 may reply with msg2 at 202, which msg2 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 a PRACH opportunity to transmit a preamble. The DCI may include RAR grants, which may include time and frequency resource allocations for the WTRU 211, as well as Modulation and Coding Schemes (MCS) and Transmit Power Control (TPC) commands. The msg2 may also include a preamble index so that the WTRU 211 may confirm that the RAR is intended for itself (WTRU 211). Once the WTRU 211 receives the msg2 including the RAR, the WTRU 211 decodes it.
At 203, the WTRU 211 may proceed with transmission of data packets (e.g., PDUs) based on all content processed from the msg 2. The WTRU 211 may scramble data using a temporary cell radio network temporary identifier (TC-RNTI) and send the data as msg3 according to the scheduled resources given in the RAR grant.
At 204, the gNB 212 may reply to msg4, which msg4 may serve as a contention resolution message. Upon receiving msg4, the WTRU 211 may compare its TC-RNTI sent in msg3 with the WTRU identity received in msg 4. Contention may occur when two WTRUs select the same preamble and both monitor the same RAR grant that causes the WTRU to transmit msg3 on the same resource. In case of collision, the WTRU may attempt another RACH procedure. The last two messages: msg3 and msg4 may facilitate conflict resolution.
In a different approach, the RACH procedure may be completed with only two messages, which may simplify the 4-step RACH procedure to a 2-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).
In general, the information associated with each message # may be interchangeable, as described herein (e.g., msg1 refers to a random access preamble, etc.).
Fig. 3 is a diagram illustrating an exemplary baseline of a signal structure for a 2-step RACH. In this 2-step RACH procedure, the first msgA 310 may include msg1 (e.g., preamble 311) and msg3 (e.g., payload 312) transmitted together. As shown, the msgA may be composed of a preamble 311 (e.g., an NR PRACH preamble) and a payload 312. Further, msgA may be a Time Division Multiplexed (TDM)313, where the payload 312 is transmitted on NR PUSCH using NR demodulation reference signals (DMRS). In a second step, msgB 320 may include msg2 and msg 4. The single step of msgB may implement the functionality of msg2 and msg4 and may include control information. For example, the control information may be one or more of: ACK/NACK that may be in response to the preamble, the payload, or both; timing Advance (TA) which may be indexed only according to a pre-configured table; PUSCH scheduling information which can be defined according to a pre-configured table and only needs to be indexed; may be a marked preamble selection, where its presence initiates a preamble reselection; MCS that may be limited to a few basic options; the power adjustment may be in the form of a TPC and/or a flag, where the presence of the flag indicates to increase the power by a preconfigured value.
Generally, in a 2-step RACH procedure, the msgB procedure and its indication mechanism may perform functions equivalent or similar to the 4-step msg2 and msg4 while addressing possible use cases for the 2-step RACH. However, in the 2-step RACH method, there may be one or more problems occurring due to one step of combining msg2 and msg4 into msgB. These problems may include: a low overhead indication mechanism to support contention resolution; a mechanism for ACK/NACK indication and determination for msgA; a mechanism for group common/WTRU-specific ACK/NACK indication and determination; and/or a mechanism for monitoring msgB and switching between 2-step RA and 4-step RA. These problems may be addressed in one or more embodiments herein.
Fig. 4 is a process diagram illustrating an example of a 2-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. Then, the gNB 412 may send an msgB at 402 in response to attempting or fully processing msgA.
If the payload is successfully decoded, the WTRU may receive an acknowledgement message in the msgB indicating that the msgA has been successfully decoded.
In some cases, the WTRU may receive an update of the TA in msgB to apply to potential subsequent transmissions. The WTRU may receive other transmission parameters (e.g., TPC commands for the preamble portion of msgA, TPC commands for the payload portion of msgA, or TPC commands for both).
The WTRU may receive a control message in msgB to update its TA value if the payload is not successfully decoded by the gNB. Such control messages may be addressed to a preamble group. For example, the control message or a portion thereof (e.g., a CRC) can be scrambled using an identifier bound to the preamble group. In some cases, preamble groups may be defined based on estimated distances 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 additionally or alternatively receive other control information (e.g., TPC commands for the preamble portion of the msgA, TPC commands for the payload portion of the msgA, or TPC commands for both).
In some cases, a WTRU may be configured with one or more CORESET and/or search spaces (e.g., configured as part of a SIB during initial access), where one CORESET and/or search space may be dedicated to receiving a preamble set PDCCH. The WTRU may determine at least one parameter of the CORESET and/or the search space (e.g., its timing) based on the preamble and/or parameters of the random access resource used to transmit the preamble. In some cases, the WTRU may retransmit the payload with the received configuration.
The WTRU may receive a message including a grant for retransmission of a payload in the msgB. The grant may clearly indicate to the WTRU that the preamble was received but that the payload needs to be retransmitted. In some cases, the network may provide parameters for retransmission in msgB. The indicated parameters may be directly indicated or they may relate to the original transmission. For example, the retransmission grant may indicate that the MCS is to be reduced relative to the MCS used in the original transmission.
As discussed herein, the payload of msgA may be made up of at least two parts, such as UCI and data. The UCI may be used by the WTRU to indicate parameters of data transmission (e.g., MCS, DM-RS configuration, resource allocation, TCI status, etc.). The gNB may decode UCI, but may determine NACK of the data portion of the transmission. The WTRU may receive an indication in msgB to retransmit data without UCI. For example, the indication may provide a new set of transmission parameters that overwrite those selected by the WTRU for the original transmission.
In the case of an operation not permitted, the WTRU may receive an indication of a transmission failure due to a hidden node problem. Such an indication may be used to indicate to the WTRU to use a more robust Listen Before Talk (LBT) procedure or to retransmit at a greater power.
The WTRU may restart the procedure if the WTRU does not receive the control message within the specified period. 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.
The received msgB may include an information element. The information element may be in the form of a decoded DCI, PDSCH message, sequence, or a combination thereof. In some cases, an information element may be comprised of at least one or more of the information discussed herein. In some cases, the content of an information element may be quantified or classified based on the dimensions of its content to point to a particular value or combination of values of pieces of information.
In some cases, the information element may be supportable 2NN-bit binary messages of different dimensions or states. In some cases, the information element may be selected to support up to M different dimensionsA pool of M sequences of degrees or states. In one example, different states of an information element may point to different TA values. In some cases, different states of an information element may determine different combinations of two or more contents (e.g., ACK/NACK, TA, etc.).
The success of msgA transmission depends on the successful transmission of the preamble and payload portions. For retransmission of msgA, it may be desirable to know which portion of msgA has failed so that appropriate adjustments can be made to retransmission. There may be separate ACK/NACK feedback for the preamble and payload, however, this may require excessive overhead and delay in the process.
Figure 5 is a flow chart illustrating an example of WTRU behavior for an efficient ACK/NACK procedure.
In general, a WTRU may receive one or more 2RA-RNTI values that may be used for a 2-step RACH. The 2RA-RNTI may be a subset or a different set of RA-RNTIs. In one example, at least one of the 2 RA-RNTIs is reserved for preamble NACK. The WTRU may select one of the configured preambles for msgA transmission. The selected preamble may be identified by a preamble ID. In one case, the WTRU may select one of the configured preambles based on one of the received RA-RNTI and/or another system parameter.
Initially, the gNB may receive msgA from the WTRU. At 501, the gsb may send msgB back to the WTRU. At 502, the WTRU may determine whether an ACK or NACK is present in the msgB.
If the gNB successfully detects the preamble and payload, then the msgB contains an ACK 503 indicating a successful 2-step RACH.
If the gNB detects a preamble but fails to decode the payload, the WTRU processes the msgB including a NACK and a preamble ID, indicating that the preamble was successfully detected but failed to decode the payload, at 504. The preamble ID of the detected preamble may be explicitly or implicitly indicated. In some cases, the preamble ID may be directly indicated as the content of msgB. In some cases, the preamble ID may be used to scramble a CRC of the received msgB payload. At 506, the WTRU may adjust its payload transmission parameters upon indication of a payload decoding failure. For example, the WTRU may change one or more of the MCS, payload power, PUSCH resources, etc. The WTRU may not make any adjustments in the preamble portion of its msgA.
If the gNB fails to detect both the preamble and the payload, the WTRU processes a NACK transmitted separately or scrambled with the reserved 2RA-RNTI of the preamble NACK at 504. At 505, the WTRU may adjust its preamble transmission parameters when a preamble decoding failure is indicated. For example, the WTRU may change one or more of the preamble sequence, preamble power, TA, etc. The WTRU may not make any adjustments in the payload portion of its msgA.
In either case, where the NACK type is preamble or payload, after the adjustment, the WTRU may then reattempt the 2-step RACH procedure at 507.
Figure 6 is a flow diagram illustrating an example of WTRU behavior for an efficient ACK/NACK procedure. In one approach, the WTRU may rely on one or more accompanying control information elements to distinguish different NACK types rather than having different preambles or payload NACKs that may be distinguished by RNTIs. As shown, two different results may be produced depending on the type of accompanying content (e.g., TA or MCS). In this example, the presence of accompanying control information provides updated values for the TA and MCS.
Initially, the gNB may receive msgA from the WTRU. Depending on the success of the msgA transmission, the gsb may send msgB back to the WTRU at 601, where the WTRU may receive and decode different combinations of control information in the msgB. The WTRU may use a combination of the received information as an implicit indication of other events. Specifically, at 602, the WTRU may determine whether an ACK or NACK is present in the msgB by decoding the received information element.
If the gNB is able to decode the received information element, then the msgB contains an ACK and there is a successful 2-step RACH 603.
At 604, if the WTRU receives a NACK and new PUSCH scheduling information and/or MCS and/or power command, the WTRU may determine that preamble detection has succeeded but PUSCH (e.g., payload) detection has failed at 608; in the illustrated example, the WTRU receives the MCS. Thus, at 609, a new set of PUSCH resources and updated MCS may be indicated for the next msgA PUSCH transmission. The WTRU may also increase the payload power. Other parameter adjustments may be determined by the WTRU itself.
At 604, if the WTRU receives a NACK along with a TA and/or preamble and/or power command, the WTRU may determine that preamble detection has not been successful at 605. Thus, at 606, an updated TA, preamble change command, and power command of the preamble may be indicated for the next msgA PUSCH transmission. The adjustment of other parameters may be decided by the WTRU itself (e.g., a new set of PUSCH resources and MCS).
In either case, once the update is indicated, the WTRU may reattempt the 2-RACH at 607.
For contention-based 2-step RACH, upon transmitting an msgA including a random access preamble (e.g., PRACH) and data (e.g., msg3 including a WTRU ID, an RRC connection request, etc.), the WTRU may start a Random Access Response (RAR) window at a first expected PDCCH monitoring occasion from the end of the msgA transmission. Within the RAR window, the WTRU may monitor the PDCCH and the corresponding PDSCH associated with msgB.
In some cases, during a 2-step RACH procedure, the WTRU may assume that the gNB has successfully detected a random access preamble (e.g., an ACK for a RACH preamble) within the msgA, but has not successfully received the msg3 information (i.e., payload portion) of the msgA (e.g., a NACK for msg3) or that contention resolution has not been successful, if one or more of the following conditions are met: (i) the WTRU may detect a PDCCH associated with an msgB carrying DCI format 1_0 with a CRC scrambled by an RA-RNTI, wherein if the msgA is successfully received by the gNB, the gNB may have obtained knowledge of the WTRU-ID and may not need to address the WTRU using the RA-RNTI; (ii) the WTRU may detect the PDCCH associated with msgB, but may not be able to successfully decode and detect the corresponding PDSCH carrying WTRU contention resolution, timing advance, etc. (e.g., msg2 and msg 4).
The detection of PDCCH associated with msgB may be considered by the WTRU as implicit signaling of acknowledgement of the random access preamble from the gNB or equivalently partial msgA reception.
In some cases, the WTRU may check the DCI fields associated with msgB and if these fields are set to pre-specified values (e.g., to all '0's or '1'), the WTRU may verify whether the random access preamble (e.g., msg1) in msgA has been successfully detected and/or whether the msg3 of 2-step RACH has been successfully received.
In one example, if all or a subset of fields of DCI format 1_0 associated with msgB are set, e.g., according to table 1 below, verification of successful receipt of msgA of a detected DCI may be achieved. The WTRU may assume that it has detected a PDCCH associated with msgB but has not successfully detected scheduling information for a corresponding PDSCH carrying 2-step RACH contention resolution.
DCI field
Value of
HARQ process number
Is provided as all '0' or '1'
Redundancy version
Is provided as all '0' or '1'
Modulation and coding scheme
Is provided as all '0' or '1'
Frequency domain resource allocation
Is provided as all '0' or '1'
Time domain resource allocation
Is provided as all '0' or '1'
Downlink allocation index
Is provided as all '0' or '1'
TPC commands for scheduled PUCCH
Is provided as all '0' or '1'
PUCCH resource indicator
Is provided as all '0' or '1'
PDSCH-to-HARQ feedback timing indicator
Is provided as all '0' or '1'
Table 1: special field for msgA successful reception validation in DCI format 1_0
Fig. 7 is a flow diagram illustrating an exemplary WTRU procedure associated with a 2-step RACH, wherein the WTRU detects DCI associated with an msgB within a RAR window containing a downlink assignment. At 701, during a 2-step RACH procedure, the WTRU may detect a PDCCH associated with msgB within a RAR window. At 702, if the WTRU determines that the DL grant is not in the DCI, at 703, the WTRU may follow procedures related to UL grant for the msgB related DCI. At 702, if the DL grant is in the DCI, and the DCI is addressed by the RA-RNTI at 704, where the WTRU successfully detects the corresponding PDSCH associated with msgB, the WTRU may follow: at 705, a random access preamble transmitted in msgA has been successfully received (e.g., an ACK for msg 1); at 706, msg3 information (e.g., PUSCH payload) transmitted in msgA has not been received or rejected (e.g., NACK for msg 3); at 707, contention resolution for the WTRU is not completed (e.g., the contention resolution identity of the WTRU transmitted in msgB matches the WTRU ID transmitted in msgA); and/or, at 708, the 2-step random access procedure has not been successfully completed.
At 704, if the DCI is not addressed by the RA-RNTI, but is addressed by the R-RNTI, C-RNTI, CS-RNTI, or temporary C-RNTI, and the WTRU successfully detects the corresponding PDSCH associated with msgB, the WTRU may follow: at 709, the WTRU may assume that the gNB has successfully detected a random access preamble transmitted in msgA (e.g., msg 1); the detected and decoded msg3 information was successfully transmitted in msgA; contention resolution for the WTRU has been successfully completed (e.g., the contention resolution identity of the WTRU transmitted in msgB matches the WTRU ID transmitted in msgA); and/or the 2-step random access procedure has been successfully completed.
If the RAR window expires and the WTRU does not detect a PDCCH addressed to any of 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 the gmb has not received msgA and the 2-step random access procedure is unsuccessful (not shown). In this case, the WTRU may perform one or more of the following actions while retransmitting msgA: increment a preamble transmission counter of msgA; selecting a new random access preamble for msgA; selecting a random back-off time for retransmitting msgA after the back-off time; executing 2 steps of random access resource selection process; flush the HARQ buffer for transmitting msg 3; and/or retransmit msgA.
In some cases, the WTRU may receive a flag in the DCI associated with the msgB indicating to the WTRU whether the msgA for the 2-step RACH has been fully or partially received at the gNB. If the WTRU successfully detects and decodes a PDCCH associated with an msgB addressed to RA-RNTI, C-RNTI, CS-RNTI, temporary C-RNTI, or WTRU-ID within an RAR window, the WTRU may use information in the DCI, such as a New Data Indicator (NDI) (e.g., handed over or not handed over), to determine whether the entire msgA or a portion of the msgA (e.g., random access preamble or msg3) has been successfully received at the gNB.
If the NDI in the DCI associated with the msgB is not handed over, the WTRU may assume that the entire msgA has not been successfully received at the gNB and the 2-step random access procedure is unsuccessful. In one example, if NDI in DCI associated with msgB is toggled, the WTRU may assume that the entire msgA or portion of msgA has been successfully received at the gNB.
Fig. 8 is a flow diagram illustrating an exemplary WTRU procedure associated with a 2-step RACH, wherein DCI may include an uplink grant. At 801, the WTRU detects PDCCH within a RAR window and receives DCI associated with msgB. At 802, if the DCI does not contain an uplink grant, the WTRU may detect and decode a corresponding PDSCH carrying msgB at 804. In some cases, at 802, the DCI does contain an uplink grant (e.g., DCI format 0_1) instead of the downlink allocation associated with msgB (e.g., fig. 7).
At 803, if the PDCCH associated with the msgB carrying the uplink grant is addressed by the RA-RNTI, then the following may apply: the msg3 information portion of msgA has not been successfully received at the gbb (e.g., HARQ NACK for msg 3); uplink grants are used to retransmit msg3 on PUSCH; the 2-step random access process is unsuccessful; the gNB has switched the WTRU from a 2-step RACH to a 4-step RACH procedure.
If the PDCCH associated with the msgB carrying the uplink grant is not addressed by RA-RNTI at 803, the DCI may be addressed to C-RNTI, CS-RNTI or WTRU-ID at 809. Then one can follow: at 801, the msg3 information portion of msgA has been successfully received at the gNB (e.g., HARQ NACK for msg 3); at 811, contention resolution of the 2-step random access procedure is successful; and/or, at 812, the 2-step random access procedure is successful.
In either case, based on the determination made at 803, the WTRU may determine the operation after step 803.
In general, a WTRU may detect a PDCCH and a corresponding PDSCH associated with msgB, and the PDSCH may explicitly indicate to the WTRU that a random access preamble or msg3 information has not been successfully received at the gNB (e.g., or contention resolution).
In NR with 4-step RACH, when a packet is transmitted from the WTRU on PUSCH and is not successfully decoded at the gNB, the gNB may send DCI format 0_1 with CRC scrambled by RA-RNTI to request retransmission from the WTRU. If multiple WTRUs participate in a 2-step RACH procedure simultaneously over a common or shared PUSCH resource, one or more WTRUs may complete their msgA preamble PRACH transmission during the same time opportunity, but one or more WTRUs may fail in the payload transmission portion of msgA. Several WTRUs may desire to respond from the gNB through a separate msgB, which may require a large downlink overhead. msgA may be received in error at the gNB due to preamble collision or PUSCH detection failure.
In one approach, the msgB content may be interpreted differently depending on whether it is transmitted in a common search space or in a WTRU-specific search space. This may allow the gNB to reduce the amount of downlink signaling by addressing the preamble and PUSCH detection failure issues, respectively.
The WTRU may interpret msgB received on the group common search space as a preamble collision. Since preamble collisions affect 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 collisions and may reply on a group common search space to trigger the preamble reselection procedure.
The msgB may be sent on the WTRU-specific search space if the gmb does not detect a preamble collision but the payload portion of the msgA of one or more WTRUs fails. The WTRU-ID used by the gNB for transmission on the WTRU-specific search space may be derived from the preamble.
Since the WTRU is not necessarily time aligned when transmitting the data payload portion of msgA, the gNB may be able to decode the preamble but not the PUSCH portion of msgA. Therefore, in some cases, it may be advantageous for the WTRU to fall back to the 4-step RA procedure. If an uplink grant is provided, the WTRU may switch to a 4-step RA procedure and continue to transmit msg3, and/or select a RACH occasion and preamble associated with the 4-step RA procedure for msg1 retransmission after switching to the 4-step RA procedure. In some cases, the WTRU may switch from a 4-step to a 2-step RA procedure.
In some cases, the WTRU may switch between 2-step RA and 4-step RA based on the conventional MAC RAR content in the received msgB or conventional msg2 PDUs. For example, if the WTRU receives a random access preamble id (rapid) and a legacy MAC RAR sub-PDU, the WTRU may switch to a 4-step RA. If the WTRU does not receive an msgB PDU associated with an msgA transmission in a 2-step RA procedure, the WTRU may treat the reception of a legacy msg2 PDU as a trigger for fallback.
In some cases, the WTRU may switch between a 2-step RA and a 4-step RA based on the contents of the msgB or MAC RAR of the 2-step RA. For example, if the contents of msgB include an uplink grant, the WTRU may switch to a 4-step RA. An explicit bit in the contents of msgB can be used to indicate a switch to a 4-step RA. For example, if the reserved bit "R" in the MAC RAR payload is marked with a value such as "1," the WTRU may switch to a 4-step RA. In one example, the WTRU may switch to a 4-step RA if the reserved bit "R" in the backoff MAC sub-PDU payload is marked with a value such as "1".
In some cases, the WTRU may switch between 2-step RA and 4-step RA based on receiving a RAPID MAC sub-PDU in msgB only. For example, if the contents of msgB only include MAC sub-headers with RAPID, the WTRU may switch to 4-step RA.
In some cases, the WTRU may switch between 2-step RA and 4-step RA based on receiving a backoff indicator MAC sub-PDU in msgB or receiving a backoff indicator MAC sub-PDU in msgB only. For example, if the contents of msgB only include a MAC sub-header with backoff and the reserved bits in the MAC sub-PDU are marked with a value such as "1," the WTRU may switch to a 4-step RA.
In some cases, the WTRU may switch between 2-step RA and 4-step RA based on the properties of the PDCCH that schedules msgB. For example, if an msgB is received on a specific coreset, search space, and/or RNTI, the WTRU may switch between a 2-step RA and a 4-step RA. When separate RACH occasions are configured for the 2-step RACH and the 4-step RACH, and the WTRU receives an msgB on a PDCCH addressed to the RA-RNTI associated with the RACH occasion of the 4-step RA, the WTRU may switch to the 4-step RA, or vice versa, will result in a switch to the 2-step RA. The WTRU may monitor the RA-RNTI associated with the fallback to 4-step RA and another RA-RNTI or C-RNTI (if it is included in the msgA) to continue the 2-step RA. If the WTRU includes its C-RNTI in msgA and schedules msgB on a PDCCH addressed to the WTRU's C-RNTI, the WTRU may continue the RA procedure as a 2-step RA. The WTRU may switch between 2-step RA and 4-step RA if the WTRU includes its C-RNTI in msgA and schedules msgB on a PDCCH addressed to the RA-RNTI associated with the RACH Occasion (RO) of the last preamble transmission.
When the 2-step RA and the 4-step RA are configured to share the RO, the WTRU may be configured with separate coreset, search space, and/or RA-RNTI to distinguish RARs intended for legacy WTRUs from RARs intended for WTRUs supporting the 2-step RA. The WTRU may switch back to the 4-step RA if a fallback RAR or a legacy MAC RAR or msg2 RAR is received on the coreset, search space, and/or RA-RNTI that is not associated with the 2-step RA. In such examples, the WTRU may monitor coreset, search space, and/or RA-RNTI associated with the fallback to 4-step RA, in addition to which if the WTRU has selected PRACH resources associated with the 2-step RA, the WTRU may monitor those coreset, search space, and/or RA-RNTI configured for the 2-step RA.
In some cases, the WTRU may switch between the 2-step RA and the 4-step RA based on timing advance. In one example, the WTRU may switch between a 2-step RA and a 4-step RA if the timing alignment timer expires. In another example, the WTRU may switch between a 2-step RA and a 4-step RA if a Timing Advance (TA) command received in the MAC RAR and/or an indicated TA value or TA adjustment difference is greater than a configured TA threshold.
In some cases, the WTRU may switch between 2-step RA and 4-step RA based on RRC mode. For example, if the WTRU is not in connected mode and/or if the WTRU does not provide the C-RNTI part of the msgA payload, the WTRU may monitor conditions for fallback or handover between 2-step RACH and 4-step RA.
In some cases, the WTRU may switch between a 2-step RA and a 4-step RA based on the RA counter. The WTRU may switch between 2-step RA and 4-step RA based on the value of the WTRU's maintained "msgA counter" and/or preamble transmission counter as part of a given RA procedure. In one example, the WTRU may maintain an additional new counter, "msgA counter," which may be incremented for each 2-step RA attempt and may be reset at the start of a new procedure or when the WTRU switches to a 2-step RA. In one example, the WTRU may switch to a 4-step RA if the msgA counter is greater than a threshold configurable by RRC and/or the preamble transmission counter is greater than a threshold configurable by RRC. The WTRU may report a problem or trigger RLF to higher layers if the msgA counter is greater than a threshold configurable by RRC and/or the preamble transmission counter is greater than a threshold configurable by RRC.
In one example, the WTRU may switch between a 2-step RA and a 4-step RA if a counter associated with counting LBT failures for msgA has reached a threshold configurable by RRC. For example, the MAC entity may receive an indication from the physical layer whenever the LBT fails to transmit the msgA, the preamble portion of the msgA, and/or the payload portion of the 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.
In some cases, the WTRU may switch between a 2-step RA and a 4-step RA based on uplink transmission power or radio frequency conditions. For example, the WTRU may switch between a 2-step RA and a 4-step RA if the power headroom is less than a configured value, or if the power ramp counter has reached a certain value that may be configured by the RRC.
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 a network device such as the gNB). For example, the WTRU may switch between a 2-step RA and a 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.
When switching between the 2-step RA and the 4-step RA, the WTRU may continue to transmit msg3 on the provided uplink grant. The WTRU may reset the msgA counter after a period of time or a number of 4-step attempts configured by RRC. The WTRU may reset the preamble transmission counter and/or the power ramp counter.
When configuring the mapping of multiple RACH occasions to one PUSCH resource, the gNB may decode PUSCH without decoding RACH, and may transmit an msgB indicating that 2-step RA of at least one WTRU whose identity was decoded on the data payload portion of msgA, but the gNB may not yet decode the RACH occasions used by such WTRU. When configuring the mapping of more than one RACH occasion to one PUSCH resource, the WTRU may monitor the PDCCH for msgB on all RA-RNTIs associated with RACH occasions of a selected PUSCH resource mapped to msgA. The WTRU may receive an msgB that concludes that a 2-step RA on an RA-RNTI is successful, which is different from the RA-RNTI associated with the selected RACH occasion of the msgA.
In selecting a RACH occasion and/or preamble configured for 2-step RA, the WTRU may monitor the PDCCH to receive msg2 for backoff in addition to msgB. Depending on the RRC configuration, the WTRU may monitor the PDCCH for msgB and msg2 on different coreset, search space, and/or RA-RNTI. In one example, after a certain number of 2-step RA attempts, or when the conditions for using 2-step RA no longer apply (e.g., if the channel conditions/measurements are below a threshold, or if the uplink timing is misaligned), the WTRU may monitor for coreset and/or RA-RNTI associated with the msg2 reception.
In some cases, the WTRU may be configured with two sets of initial backoff values and/or backoff scaling factors by RRC. For example, upon receiving a BI sub-PDU in msgB, the WTRU may apply a set of backoff 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 backoff values if msg1 is transmitted and/or a RACH occasion/preamble configured for 2-step RA is selected.
The WTRU may implicitly determine an alternative backoff value from the indicated Backoff Indicator (BI) value based on at least one of: attributes of the received msgB; msgB content; msgA content; an RA initiate trigger; and/or whether the WTRU transmitted a data payload (e.g., whether msg1 or msgA was transmitted). For example, if the WTRU already includes the C-RNTI portion of its msgA and/or if a subset of BI to RA-RNTIs is received on a PDCCH addressed to C-RNTI, the WTRU may ignore the indicated backoff, scale the backoff, or apply an alternative value mapped to the indicated BI. In another example, if the WTRU sends the data payload portion of msgA and/or if the data payload in msgA is from a Logical Channel (LCH) having a Logical Channel Priority (LCP) above a configured threshold, the WTRU may ignore the indicated backoff, scale the backoff, or apply an alternative value mapped to the indicated BI. In another example, if the WTRU has sent a preamble and/or has selected a RACH occasion configured for 2-step RA, and/or if a BI is received on a PDCCH associated with an RA-RNTI corresponding to the RACH occasion configured for 2-step RA, the WTRU may ignore the indicated backoff, scale the backoff, or apply an alternative value mapped to the indicated BI. As described above, the WTRU may apply an alternative backoff value on the indicator bits in the backoff sub-PDU.
In some cases, the WTRU may ignore the sub-PDU containing the RAPID or the legacy msg2 PDU if the WTRU has sent a preamble, has selected a RACH occasion configured for 2-step RA, has transmitted a payload on the PUSCH portion of msgA, and/or the WTRU has included the C-RNTI portion of msgA content. The WTRU may consider a 2-step RA successful if the WTRU receives a MAC RAR sub-PDU that includes the identity of the WTRU included in the msgA content for contention resolution. If no other MAC RAR sub-PDUs are received with the WTRU's identity included in the msgA's payload, the WTRU may consider the sub-PDU containing the RAPID or the legacy msg2 PDU for fallback to the 4-step RA. 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 determining or receiving an ACK for the PDU transmitted on the uplink grant. The WTRU may ignore the uplink and thus skip such uplink grants even if the WTRU has no buffered data to transmit.
Fig. 9 is a process diagram illustrating an example of a Beam Failure Recovery (BFR) process with multiple beam monitoring.
In general, a WTRU may perform BFR using a 2-step RA procedure. The 2-step RA procedure may be contention-based. In a portion of the msgA data payload, the WTRU may include an identification of a preferred SSB and/or a preferred channel state information reference signal (CSI-RS). The number of reported preferred identities may be pre-configured or predetermined by RRC. The WTRU may select any RACH occasion and/or preamble configured for 2-step RA regardless of the mapping of Synchronization Signal Blocks (SSBs) to RACH occasions and/or preambles configured on the condition that the WTRU provides identification of preferred SSBs and/or CSI-RSs. In a portion of the msgA data payload, the WTRU may include measurements associated with the preferred beam. For example, the WTRU may include a payload of msgA: RSRP, RSSI, signal to interference plus noise ratio (SINR), block error rate (BLER), or Bit Error Rate (BER) measurements.
Upon expiration of the BFR timer, the WTRU may exclude selection of SSBs and/or CSI-RSs selected prior to expiration of the timer portion of the RA procedure. Upon expiration of the timer, the WTRU may fall back to a 4-step RA or a contention-based random access (CBRA). Upon expiration of the timer, the WTRU may consider a particular set of PUSCH resources for transmitting the msgA payload.
If an uplink grant is received in the MAC RAR associated with the 2-step RA attempt, the WTRU may consider the BFR successful when determining or receiving an ACK for the PDU transmitted on the uplink grant. If no uplink grant is provided in the MAC RAR, the WTRU may consider the BFR procedure successful when it successfully receives an msgB with its C-RNTI (or an identity provided in msgA) included in the portion of msgB content and/or when the WTRU successfully receives a PDCCH addressed to its C-RNTI.
As shown in the BFR example of fig. 9, at 901 WTRU 912 may detect a beam failure from network/gNB 911. After a 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 configured Reference Signal (RS) resources (e.g., SSBs or CSI-RSs). The set of RS resources may include a set of RSs that may be configured for monitoring after beam failure detection. The set of RS resources may comprise a same or different set of RSs that the WTRU monitored before the beam failure. Each RS may be associated with a set of preambles, and each RS may correspond to a different beam.
In some cases, when a beam failure is detected, the WTRU may choose to 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 the measured signal quality (e.g., RSRP, SINR) being above a configured threshold. At 902, the WTRU may send an msgA payload to the gNB, where the WTRU may include a preferred subset of the msgA payload. The payload may also include a ranking of the measured signal quality metrics or measurements, such as from the strongest RS to the weakest RS.
The indication of the RSs in the preferred subset may include one or more CSI-RS Resource Indications (RIs) (CRI) 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 SSBs 1 and SSBs 2 that the gNB may send in TDM fashion. The WTRU may send a preamble of msgA associated with SSB1, and the msgA payload may include RSRP measurement results of SSB1 and RSRP measurement results of SSBRI and SSB2 of SSB2 (e.g., at 902). The gNB may receive the msgA preamble and the gNB may decode the msgA payload to determine whether the WTRU includes the preferred subset of RSs.
In some cases, if the payload includes additional RS indices, the gNB may decide to send an msgB response on either of the RSs by relying on the same spatial filter as, for example, SSB1 or SSB 2. The gNB may determine the RS to use from WTRU assistance based on the index received in msgA. If the payload does not include any additional indices, the gNB may transmit an msgB response by relying on the RS (e.g., beam) associated with the msgA preamble.
At 903, the WTRU may monitor PDCCH transmissions on configured RS resources associated with all indicated beams. This may correspond to the search space or CORESET associated with the RS transmitting the msgA preamble. The WTRU may monitor the PDCCH on any search space or CORESET associated with the RS reported in the msgA payload. After the WTRU detects the msgB response, the WTRU may stop monitoring the PDCCH.
For example, the WTRU may monitor for a response related to the SSB1 or SSB2 transmission opportunity. At 904, the BFR procedure may be considered successfully completed when the WTRU decodes the msgB containing the C-RNTI of the WTRU. In some cases, the PDCCH may be addressed using a common RNTI (e.g., a DCI scrambled with an RA-RNTI), and the WTRU may decode the msgB to determine whether its C-RNTI is included in the msgB payload. The PDCCH may contain an indication of the available time/frequency resources for PUCCH transmission. The WTRU may use the PUCCH resources to send (e.g., declare) UCI including an ACK acknowledging receipt of the msgB, thus acknowledging completion of the beam failure recovery procedure.
As previously discussed herein, in response to msgA, the WTRU may send msgA to the gbb and receive msgB from the gbb. The WTRU may determine whether contention resolution is successful based on the msgB response.
The msgB may include DCI scrambled with msgB-RNTI. The WTRU may monitor the msgB DCI to determine whether the gNB includes a payload in the PDSCH. After decoding the DCI, the WTRU may determine PDSCH resources containing msgB payloads. The WTRU may decode the payload and the WTRU may search its user identity to determine whether contention resolution was successful. The WTRU may send a HARQ-ACK response on the PUCCH resource if the contention resolution is successful.
The WTRU may determine PUCCH resources based on the PUCCH resource index. The PUCCH resource index may be determined based on a PUCCH Resource Indicator (PRI) and a PDSCH-to-HARQ feedback indicator, which may be included as part of a DCI payload included in the msgB (e.g., in DCI format 1_0 or DCI format 1_ 1).
The PDSCH-to-HARQ feedback indicator may be mapped to a value from the set {1, 2, 3, 4, 5, 6, 7, 8} corresponding to a slot offset from PDSCH reception. The WTRU may determine slot timing to transmit PUCCH resources.
The PUCCH resource index is defined as formula 1
Wherein r isPUCCHIs PUCCH resource index, RPUCCHIs the size of the PUCCH resource list, NCCE，pIs the number of CCEs in CORESET p received by PDCCH of DCI Format 1_0 or DCI Format 1_1, nCCE，pIs an index of the first CCE for PDCCH reception, and ΔPRIIs the value of the PUCCH resource indicator field in DCI format 1_0 or DCI format 1_ 1.
The WTRU may determine parameters for PUCCH transmission based on the PUCCH resource index.
RPUCCH，NCCE，pP and nCCE，pCan be an RRC configured value, andmay not be WTRU specific. DeltaPRIMay be explicitly included in the DCI for the WTRU to specifically define the PUCCH resources. If the msgB payload includes only one WTRU, a single PRI and PDSCH-to-HARQ feedback indicator value included in the DCI may uniquely determine a PUCCH resource for the WTRU. However, if more than one WTRU is multiplexed into the msgB, more than one WTRU may receive the same DCI addressed to the msgB-RNTI and may use a single PRI and PDSCH-to-HARQ feedback indicator to determine the PUCCH resources, which are the same for all WTRUs. This may result in collisions and HARQ-ACK feedback may not be received at the gbb.
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 according to the same parameters from equation 1 and also using RAPID as follows:
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 according to the same parameters from equation 1 and also using RAPID as follows:
wherein f (RAPID, Δ)PRI) Is from RAPID and ΔPRIMapping to WTRU-specific PRI.
RAPID can be used to randomize rPUCCHThe value is obtained. For example, multiple WTRUs may select different preambles and send msgA. The msgB may successfully receive all msgA and the responses to multiple WTRUs may be multiplexed in one msgB. The DCI may include a single PRI value addressed to multiple WTRUs. If the contention resolution is successful, the WTRU may randomize r using RAPIDPUCCHAnd (4) selecting. Each WTRU may be linked to a unique r determined by RAPIDPUCCHValue and can transmit HARQ-AC without collisionK。
The link between RAPID and PUCCH resources may be configured such that it is one-to-one mapped. May generate WTRU-specific rPUCCHA value, wherein RAPID may be a seed input to the generator function. May generate WTRU-specific deltaPRIA value, wherein RAPID may be a seed input to the generator function.
In some cases, the WTRU may implicitly determine the slot timing of the PUCCH feedback based on the PDSCH-to-HARQ feedback indicator and RAPID. Similar to the PUCCH resource index, the WTRU may randomize slot timing, which may avoid collisions, using RAPID based on a single PDSCH-to-HARQ feedback indicator.
The link between RAPID and PDSCH-to-HARQ feedback indicators may be configured such that it is one-to-one. A WTRU-specific PDSCH-to-HARQ feedback indicator value may be generated, where RAPID may be a seed input to the generator function.
The WTRU may determine r based on the abovePUCCHA PDSCH-to-HARQ feedback indicator, or both. For example, the PDSCH-to-HARQ feedback indicator may be a single value acquired from DCI, and rPUCHThe PRI and RAPID can be used for determination. Multiple WTRUs may transmit in the same slot but on different PUCCH resources. Similarly, the same PRI may be used by multiple users on different time slots, with the PDSCH-to-HARQ feedback indicator being generated by the WTRU specifically using RAPID.
Although features and elements are described above in particular combinations, one of ordinary skill 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 incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer readable media include electronic signals (transmitted over a wired or wireless connection) and computer readable storage media. Examples of computer readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and Digital Versatile Disks (DVDs). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.
As discussed herein, the WTRU, UE, and user may be used interchangeably. The gNodeB and gNB may be used interchangeably. Reference symbols may be used to denote symbols, such as complex numbers, that are fixed and known and are used as pilots. The reference signal may be used to represent a time domain signal generated after processing the reference symbols. For example, in OFDM, the reference symbols are complex numbers that are fed into the IDFT block, while the reference signals are the output of the IDFT block. Downlink Control Information (DCI) is a set of bits transmitted over the PDCCH for a user or a group of users. A Resource Element (RE) is one OFDM symbol on one subcarrier, and a Resource Element Group (REG) is a group of REs used as a building block of Control Channel Elements (CCEs) for allocating resource elements to users. REGs grouped together and adjacent in time or frequency with the same associated precoder are referred to as REG bundles. The 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 for a downlink control channel, configured by its frequency resources and its time length (e.g., in terms of symbols) and the type of its REG bundle. The search space (or set of search spaces) is a set of PDCCH candidates that is monitored by one WTRU or a group of WTRUs during blind measurement of PDCCH. As used herein, the word "some" may mean one, more or all.