Initial access and channel access in new radio / new radio-unlicensed (nr / nr-u)

Abstract

To provide a method and a WTRU for dealing with possible random access channel (RACH) occasion collisions.SOLUTION: A wireless transmit / receive unit (WTRU) receives an indication of semi-static UL / DL information including a configuration of RACH occasions and an indication of one or more actually transmitted synchronization signal (SS) blocks in remaining minimum system information (RMSI), evaluates whether there are RACH occasions based on the configuration information, and determines whether any of the RACH occasions are valid. The RACH occasion is after all actually transmitted SS blocks for which the RACH occasion was indicated and is valid based on whether the SS block override is disabled or enabled. The WTRU transmits a RACH in one or more of the RACH occasions that have been determined to be valid.SELECTED DRAWING: Figure 2B

Description

[Technical Field]

[0001] This disclosure relates to initial access and channel access in New Radio / New Radio-Unlicensed (NR / NR-U). [Background technology]

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 62 / 590,936, filed November 27, 2017, and U.S. Provisional Patent Application No. 62 / 630,692, filed February 14, 2018, the contents of which are incorporated herein by reference.

[0003] Fifth-generation (5G) wireless systems are the next telecommunications standard beyond the fourth-generation (4G) standard. 5G generally aims for higher capacity than 4G, enabling support for a higher density of mobile broadband users, greater reliability, and device-to-device and large amounts of machine-to-machine communications. Based on general requirements set forth by the International Telecommunications Union Radiocommunication (ITU-R), Next Generation Mobile Networks (NGMN), and the Third Generation Partnership Project (3GPP), broad classifications of use cases for 5G systems may include enhanced mobile broadband (eMBB), massive machine-based communications (mMTC), and ultra-reliable and low-latency communications (URLLC). These use cases may focus on different requirements, such as high data rates, high spectral efficiency, low power and energy efficiency, low latency, and high reliability. A wide range of spectrum bands, ranging from 700 MHz to 80 GHz, may be considered for these various deployment scenarios.

[0004] As carrier frequencies increase, severe path loss can become a significant limitation in ensuring sufficient coverage for wireless devices. For example, transmissions in millimeter-wave systems can suffer from non-line-of-sight losses, such as diffraction loss, penetration loss, oxygen absorption loss, and foliage loss. During initial access, a base station (BS) and a wireless transmit / receive unit (WTRU) may need to overcome these high path losses and discover each other. Utilizing tens or hundreds of antenna elements to generate beamformed signals in 5G wireless systems is an effective way to compensate for severe path loss by providing significant beamforming gain. However, these beamformed signals may collide with each other during initial access or random access procedures. For example, synchronization signal (SS) blocks, random access channel (RACH) resources, control channels (DL / UL), and / or data channels (DL / UL) may collide with each other in 5G scenarios. Summary of the Invention

[0005] A method, system, and device are provided for addressing collisions of possible random access channel (RACH) occasions. A wireless transmit / receive unit (WTRU) may receive an indication of semi-static UL / DL information including a configuration of RACH occasions and an indication of one or more actually transmitted synchronization signal (SS) blocks in residual minimum system information (RMSI) via a PBCH. The WTRU may then evaluate whether there are RACH occasions based on the configuration information and determine whether any of the RACH occasions are valid, where the RACH occasion may be valid based on whether the RACH occasion is after all indicated actually transmitted SS blocks and / or whether SS block override is disabled or enabled. The WTRU may transmit the RACH during one or more of the RACH occasions determined to be valid. [Brief explanation of the drawings]

[0006] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate like elements and in which:

[0007] [Figure 1A] 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 1C] 1B is a system schematic diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 1D] FIG. 1B is a system schematic diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 2A] FIG. 1 is a schematic diagram illustrating an example of RACH / PRACH transmission. [Figure 2B] 10 is a flowchart illustrating an example process for RACH transmission without SS block collisions according to one or more embodiments described herein. [Figure 2C] FIG. 1 is a schematic diagram illustrating an example of PRACH transmission without SS block collision according to one or more embodiments described herein. [Figure 3] FIG. 1 is a schematic diagram illustrating an exemplary overlap of a preamble and a synchronization signal (SS) block. [Figure 4] A schematic diagram showing an example method of associating preambles and SS blocks. [Figure 5] 1 is a schematic diagram illustrating an exemplary method of associating RACH occasions (or RACH resources) and SS blocks. [Figure 6]1 is a schematic diagram illustrating an exemplary method of SS block association and mapping to RACH. [Figure 7] FIG. 10 is a schematic diagram illustrating another exemplary method of associating SS blocks and mapping them to RACH. [Figure 8] 1 is a schematic diagram illustrating an example configuration of a window length for each random access channel (RACH) occasion type, where the window length of the RACH occasion type is the same as the RACH configuration period. [Figure 9] FIG. 1 is a schematic diagram illustrating an example configuration of a window length for each random access channel (RACH) occasion type, where the window length for the RACH occasion type is twice the RACH configuration period. [Figure 10] FIG. 1 is a schematic diagram illustrating an example configuration of a window length for each random access channel (RACH) occasion type, where the window length of the RACH occasion type is shorter than the RACH configuration period. [Figure 11] A schematic diagram showing an exemplary redundant version of a preamble based on SS beam reporting. DETAILED DESCRIPTION OF THE INVENTION

[0008] 1A illustrates an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. The communication system 100 may enable the multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), etc.

[0009] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104 / 113, CNs 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of 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” and / or “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), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain contexts), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

[0010] The communications system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communications networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNodeB, a Home Node B, a Home eNodeB, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, etc. While the base station 114a, 114b is shown as a single element, it will be appreciated that the base station 114a, 114b may include any number of interconnected base stations and / or network elements.

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

[0012] 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 communications link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0013] More specifically, as noted above, the communication system 100 may be a multiple-access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a and WTRUs 102a, 102b, 102c in the RAN 104 / 113 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 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).

[0014] 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).

[0015] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as New Radio (NR) radio access, which may establish the air interface 116 using NR.

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

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

[0018] 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a workplace, a home, a vehicle, a premises, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. 1A, the base station 114b may have a direct connection to the Internet 110. Therefore, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0019] The RAN 104 / 113 may be in communication with the CN 106 / 115, 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, 102d. The data may have varying Quality of Service (QoS) requirements, such as different throughput, latency, error resilience, reliability, data throughput, mobility, etc. The CN 106 / 115 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 will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs employing the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0020] The CN 106 / 115 may also serve 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 Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or 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 that may employ the same RAT as the RAN 104 / 113 or a different RAT.

[0021] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a that may employ a cellular-based wireless technology and with a base station 114b that may employ an IEEE 802.2 wireless technology.

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

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

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

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

[0026] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as, for example, NR and IEEE 802.11.

[0027] 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 / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Furthermore, 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 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, etc. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown).

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

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

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

[0031] The WTRU 102 may include a full-duplex radio in which transmission and reception of some or all of the signals (associated with a particular subframe for both the uplink (UL) (e.g., for transmission) and the downlink (DL) (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit 139 to reduce or substantially eliminate self-interference through either hardware (e.g., chokes) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for transmission and reception of some or all of the signals (associated with a particular subframe for either the UL (e.g., for transmission) or the DL (e.g., for reception)).

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

[0033] The RAN 104 may include eNodeBs 160a, 160b, 160c, although it will be appreciated that the 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 for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, the eNodeB 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

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

[0035] 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the above elements is shown as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0036] The MME 162 may be connected to each of the eNodeBs 162a, 162b, 162c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM and / or WCDMA.

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

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

[0039] The CN 106 may facilitate communication with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communication between the WTRUs 102a, 102b, 102c and traditional fixed communication devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts 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.

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

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

[0042] 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 to or interface with a distribution system (DS) or another type of wired / wireless network that carries traffic into and out of the BSS. Traffic to a STA originating from outside the BSS may arrive through the AP and be sent to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP for delivery to the respective destination. 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 send traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between (e.g., directly between) a source STA and a destination STA using direct link setup (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS communication mode is sometimes referred to herein as an "ad hoc" communication mode.

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

[0044] A high-throughput (HT) STA may use a 40 MHz wide channel for communication, for example, via a combination of a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0045] A very high throughput (VHT) STA may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, sometimes referred to as an 80+80 configuration. In the 80+80 configuration, after channel encoding, the data may be passed through a segment parser that may split the data into two streams. Inverse fast Fourier transform (IFFT) processing and time-domain processing may be performed separately on each stream. The streams may be mapped onto two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed, and the combined data may be sent to the medium access control (MAC).

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

[0047] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In an 802.11ah example, the primary channel may be 1 MHz wide for a STA (e.g., an MTC-type device) that supports (e.g., only supports) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) setting may depend on the status of the primary channel. For example, if the primary channel is busy for a STA (that only supports 1 MHz mode of operation), it may be considered busy to transmit the entire available frequency band to the AP, even though most of the frequency band may remain idle and be available for use.

[0048] In the United States, the available frequency bands that can be used by 802.11ah are from 902 MHz to 928 MHz. In South Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total available bandwidth for 802.11ah is 6 MHz to 26 MHz depending on the country code.

[0049] 1D is a system schematic diagram showing the RAN 113 and the CN 115, according to one embodiment. As mentioned above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

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

[0051] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using scalable numerology-related transmissions. 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 varying or scalable lengths (e.g., including various numbers of OFDM symbols and / or lasting for varying lengths of absolute time).

[0052] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing another RAN (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize 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 unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with / connect to a gNB 180a, 180b, 180c while also communicating with / connecting to another RAN, such as an eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement 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 act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0053] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, dual connectivity, interconnection between NR and E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D , the gNBs 180a, 180b, 180c may communicate with one another via an Xn interface.

[0054] 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the above elements is shown as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0055] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service being utilized by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on highly reliable and low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services with machine-type communications (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

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

[0057] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks such as the Internet 110 to facilitate communication 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 anchoring, etc.

[0058] The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 115 and the PSTN 108. Additionally, the CN 115 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, the WTRUs 102a, 102b, 102c may be connected to the local data networks (DNs) 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

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

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

[0061] The one or more emulation devices may perform one or more functions, inclusive, without being implemented / deployed as part of a wired and / or wireless communications network. For example, the emulation devices may be utilized in a test laboratory and / or in a test scenario in an undeployed (e.g., test) wired and / or wireless communications network to perform tests of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, e.g., one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0062] The Radio Access Network (RAN) may be part of a mobile telecommunications system that provides wireless transmit / receive units (WTRUs) with their connection to the Core Network (CN). In fifth-generation (5G) or next-generation (NG) wireless systems, the RAN may be referred to as the New Radio (NR) RAN or Next-Generation RAN. Based on the general requirements set forth by ITU-R, NGMN, and 3GPP, broad classifications of use cases for NR may be enhanced mobile broadband (eMBB), massive machine-based communications (mMTC), and ultra-reliable low-latency communications (URLLC). Different use cases may focus on different requirements, such as higher data rates, higher spectral efficiency, low power and higher energy efficiency, lower latency, and higher reliability. A wide range of spectrum bands, ranging from 700 MHz to 80 GHz, may be considered for various deployment scenarios.

[0063] As carrier frequencies increase, severe path loss can become a significant limitation in ensuring sufficient coverage. Transmissions in millimeter wave systems can also suffer from non-line-of-sight losses, such as diffraction loss, penetration loss, oxygen absorption loss, foliage loss, etc. During initial access, the base station and the WTRU may need to overcome these high path losses and find each other, or the WTRU may need to find another WTRU. Utilizing tens or hundreds of antenna elements to generate beamformed signals is an effective way to compensate for severe path loss by providing significant beamforming gain. Beamforming techniques can include digital beamforming, analog beamforming, and hybrid beamforming.

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

[0065] Following successful synchronization and PCI acquisition, the WTRU may decode channels such as the Physical Broadcast Channel (PBCH) with the help of a cell-specific reference signal (CRS) to obtain Master Information Block (MIB) information regarding the system bandwidth, system frame number (SFN), and PHICH configuration. The LTE synchronization signal and PBCH may be transmitted continuously according to a standardized period.

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

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

[0068] In the case of a contention-free random access (RA) procedure, a PRACH preamble signaled by the network may be used, for example, by the WTRU. In the case of a contention-based random access procedure, the WTRU may autonomously select a preamble, where the preamble format and / or time / frequency resources available for preamble transmission may be based on an indication or index (e.g., a PRACH configuration index) that may be provided or signaled by the eNB.

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

[0070] In some situations of path loss, such as in NR, synchronization signal (SS) blocks (SSBs), RACH resources, control channels (DL / UL), and / or data channels (DL / UL) may collide with each other. Rules may be needed to avoid, mitigate, or handle these and other situations when collisions occur in order for a WTRU to perform initial access, perform channel access, maintain system operation, and / or maximize system efficiency. Also, in other situations, a WTRU transmission may collide with another WTRU transmission during random access. For example, PRACH preambles may collide with each other, such as when a multi-beam system is used. Extensions to collision mitigation in beam-based systems may be needed to address these and other path loss situations. Furthermore, PRACH preamble formats may not be sufficient due to the limited number of symbols to support multiple beams for beam sweeping. Therefore, it may be desirable to have a technique to support multiple beams. In one or more embodiments, PRACH resources, DL / UL control, and / or SS / PBCH blocks may be processed to address the problematic situations described herein.

[0071] 2A shows an example of RACH / PRACH transmission. Generally, the first DL 203 may be a first SS block, and the second DL 205 may be a second SS block. A slot may have both a DL portion (203 and 205) and a UL portion 206. Additionally, a flexible or unknown portion X 204 may be used in the slot and may be configured as either DL or UL. The DL signal / channel 203 may occupy the first K1 OFDM symbols of the slot 202, where K is any non-negative integer. The unknown / flexible portion X 204 may occupy K2 OFDM symbols. The second DL signal / channel 205 may occupy K3 OFDM symbols, which may be the same as or different from the first DL signal / channel 203 (e.g., DL signal / channel 203 may be the first SS / PBCH block, and DL 205 may be DL signal / channel 205, which may be the second SS / PBCH block). The UL signal / channel 206 may occupy the last K4 OFDM symbols of the slot 202. SS blocks and SS / PBCH blocks may be interchangeable as described herein. The slot 202 may be configured such that each or some symbol locations may contain a particular type of content; in the example shown in FIG. 2A, the DL signal / channel 203, K1, may be the first four symbols, and the UL signal / channel 206, K4, may be the last two symbols. The periodicity may also be configured by the gNB to avoid collisions, but some predetermined or predefined rules may be used when / if the PRACH collides with the SS block, such as block, signal, and / or channel dropping rules. The SS block, DL / UL control, and PRACH may have predefined rules that the WTRU may implement to handle these issues for when they collide with each other.

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

[0073] If the WTRU receives an indication of the SS block that is actually transmitted, the WTRU may use the actually transmitted SS block location to handle collisions. For example, in the case of a long sequence (e.g., a long preamble sequence for the PRACH), the WTRU may drop the RACH when there is a collision. Otherwise, the WTRU may transmit the RACH. In the case of a short sequence (e.g., a short preamble sequence for the PRACH), the WTRU may transmit the RACH in a non-slot (e.g., two symbols, four symbols), where the symbols are not occupied by the SS block. As described herein, a non-slot may be a slot of any irregular length (e.g., a mini-slot). Also, in the case of a short sequence, the WTRU may transmit a partial RACH in a non-slot (e.g., two symbols, four symbols), where the symbols are partially occupied by the SS block. The SS block may be the SS block that is actually transmitted, or the SS block may be a candidate SS block location.

[0074] If the WTRU does not receive an indication of the SS block that was actually transmitted, the WTRU may use a maximum number of SS block positions, L, to handle collisions. For example, the WTRU may use L=4 SS blocks below 3 GHz, L=8 SS blocks below 6 GHz and above 3 GHz, and L=64 above 6 GHz.

[0075] As described herein, there may be situations in which there is or may be a collision between a RACH resource or RACH occasion and an SS block. As described herein, references to a RACH occasion may be interchangeable with a RACH resource, and a RACH occasion may be one or more symbols in a slot in which a RACH / PRACH may be sent. A slot, non-slot, or mini-slot with an SS block may be configured as a RACH occasion according to the RACH configuration table. If a collision occurs between a RACH occasion and an SS block, the WTRU may still transmit a PRACH preamble or RACH message 3 by skipping the symbols occupied by the SS block. The gNB may perform partial correlation on the PRACH preamble or rate matching on the RACH message 3 PUSCH. The number of SS blocks may vary. For example, the number of SS blocks may vary from four to two. Two SS blocks may occupy the first SS block slot. Alternatively, the position of the two SS blocks may still be the same as when there are four SS blocks.

[0076] As described herein, there may be situations in which there is or may be a collision between the UL control channel and the RACH resource. To address such situations, the WTRU may drop the PRACH and transmit the UL control channel. Alternatively / additionally, the WTRU may drop the UL control channel and transmit the PRACH. Alternatively / additionally, the WTRU may partially transmit the PRACH or partially transmit the UL control. Collision handling for these and similar situations may be based on at least one of the UL control channel (e.g., whether it is a periodic UL control channel or an aperiodic UL control channel), latency requirements, service type (e.g., URLLC, eMBB, mMTC, etc.), predefined or predetermined rules (e.g., always transmit the UL control channel or always transmit the PRACH and drop other channels), channel priority, where priority may be predefined or configured, preemption indication, indication received from the gNB regarding what to transmit and what to drop, transmitting both or all channels when a collision occurs, and / or any combination of the above-mentioned approaches.

[0077] The gNB may configure the PRACH to avoid collisions between the UL control channel and the PRACH. If the PRACH collides with the uplink control, the WTRU may drop the RACH or drop the UL control.

[0078] Predefined rules may be used to handle collisions as described herein, for example, when the PRACH and the UL control channel collide, the WTRU may drop the UL control and transmit only the PRACH, or vice versa.

[0079] In one or more situations, an indication may be used to handle the collision. The WTRU may receive an indication regarding which elements of the collision should be dropped and which should be transmitted. For example, the WTRU may be indicated to drop the PRACH and transmit the UL control channel, or the WTRU may be indicated to drop the UL control channel and transmit the PRACH.

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

[0081] In one or more cases, the gNB may transmit and receive simultaneously. When the gNB is transmitting an SS block, the gNB may also be receiving using a particular Rx beam on the same or a different carrier. Then, the PRACH may be transmitted even if the gNB is transmitting an SS block.

[0082] There may be collisions between RACH occasions and semi-static scheduling and / or dynamic slot format indicators (SFIs). Downlink and / or uplink signals and / or channels in semi-static DL / UL assignments may not be overwritten in the other direction. DL and / or UL signals and / or channels in dynamic SFIs may not be overwritten by WTRU-specific control or data channels. RACH occasions that may collide with dynamic SFIs may be dropped. RACH occasions that may collide with semi-static DL / UL assignments may be dropped.

[0083] The gNB and WTRU may derive a valid RACH occasion (VRO) based on at least one of RACH occasion mapping to slots with SS blocks, semi-static DL and UL, dynamic SFI, and / or UL and / or DL ​​scheduling. A valid RACH occasion may be an occasion for transmitting in a time increment (i.e., one or more symbols of a slot) that is predetermined or determined to be collision-free.

[0084] In some situations, there may be a collision between the DL control channel and the RACH resources. In these situations, the WTRU may drop the PRACH and receive the DL control channel. Additionally / alternatively, the WTRU may drop the DL control channel and transmit the PRACH. Additionally / alternatively, the WTRU may partially transmit the PRACH or partially receive the DL control. Collision handling may be based on at least one of latency requirements, service type (e.g., URLLC, eMBB, mMTC, etc.), predefined or predetermined rules (e.g., always receive the DL control channel or always transmit the PRACH and drop other channels), channel priority, where priority may be predefined or configured, preemption indication, indication received from the gNB regarding what to transmit and what to drop, transmitting partial or all channels when a collision occurs, and / or some combination of the above-mentioned approaches.

[0085] The gNB may configure the PRACH to avoid collisions between the DL control channel and the PRACH. If the PRACH collides with the DL control channel, the WTRU may drop the PRACH or drop the DL control channel.

[0086] Predefined rules may be used to handle collisions, for example, when the PRACH and the DL control channel collide, the WTRU may drop the DL control and transmit only the PRACH, or vice versa.

[0087] In one or more cases, an indication may be used to handle the collision. The WTRU may indicate which elements in the collision should be dropped and which should be transmitted. For example, the WTRU may receive an indication to drop the PRACH and receive a DL control channel, or the WTRU may receive an indication to drop the DL control channel and transmit a PRACH.

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

[0089] The WTRU may receive an indication as to whether an NR-PDCCH is present, whether there is a configured search space, or whether there is a configured control resource set (CORESET) that may collide with the RACH resources.

[0090] The gNB and WTRU may determine or derive valid RACH occasions for the DL control channel based on at least one of semi-static DL and UL, dynamic SFI, and / or UL and / or DL ​​scheduling.

[0091] In one or more situations with a collision, rules and RACH resources may be used to address the collision. As described herein, a RACH resource or RACH occasion may collide with either the DL portion or the UL portion. A RACH resource or RACH occasion may also collide with an unknown portion, which may be configured as a DL portion or a UL portion. The DL portion may be an SS block, a DL control channel, another DL control channel, a signal, a transmission, etc. The UL portion may be an UL control channel, another UL control channel, a signal, a transmission, etc. The WTRU may simultaneously receive an indication for a semi-static UL / DL configuration and a RACH configuration. The WTRU may also receive an indication for a semi-static UL / DL configuration before RACH configuration. If the WTRU receives an indication for a semi-static UL / DL configuration simultaneously with or before RACH configuration, and if a RACH occasion collide with the DL portion, the RACH occasion that collide with the DL portion may not be transmitted, but the RACH occasion in the UL portion may be transmitted. If the WTRU is indicated for a semi-static UL / DL configuration after RACH configuration and the WTRU is unaware of the semi-static UL / DL configuration when a RACH occasion is transmitted, the WTRU may assume that the RACH occasion will not collide with the DL portion and therefore the RACH occasion may be used for transmission and is valid. If the unknown portion is not configured or if the unknown portion is configured as UL for RACH transmission, the RACH resource or RACH occasion may be used or transmitted in the unknown portion (i.e., portion X).

[0092] To avoid possible collisions, the WTRU may check the DL / UL configuration. The WTRU may transmit the RACH in the UL portion. If the DL portion is not used, the WTRU may transmit the RACH in the DL portion. An indication as to whether the DL portion is used may be received at the WTRU. If the DL portion is indicated as "used" (e.g., used for SS blocks indicated as SS blocks actually transmitted), the WTRU may not transmit the RACH in those DL portions. Alternatively or additionally, the WTRU may not transmit the RACH in any DL portion, regardless of whether it is used or not. Such or different alternatives may be configured.

[0093] In one embodiment, the WTRU may determine where and / or whether to transmit a RACH resource depending on the location of the SS block or the SS block transmission. For example, if the WTRU knows from an indication that an SS block is transmitted in a particular location (e.g., a particular location such as a slot, subframe, etc.), one or more RACH occasions (e.g., some or all of the RACH occasions) may or may not be transmitted. Additionally / alternatively, for a given increment, the RACH may not be transmitted before the SS block, but the RACH may be transmitted after the SS block. The RACH occasion or RACH resource may not be before the SS block, and the RACH occasion or RACH resource may be after the SS block. Additionally / alternatively, if the SS block is located in or transmitted within an earlier portion of a slot, the RACH occasion / resource in a later portion of the slot may be transmitted, and the RACH before the SS block may not be transmitted. If the SS block is located in or transmitted within a later portion of a slot, the RACH in the earlier portion of the slot may not be transmitted.

[0094] The WTRU may not transmit a RACH that would or may collide with an SS block in the slot, but the WTRU may still transmit a RACH that would or may not collide with an SS block in the slot. Alternatively / additionally, if one or more RACH occasions in the slot may collide with an SS block, the WTRU may not transmit all of the RACH occasions in the slot. The WTRU may transmit a RACH or use a RACH occasion based on a collision condition with an SS block. Additionally / alternatively, the WTRU may or may not transmit a RACH or use a RACH occasion based on a location (e.g., in time or frequency) where the SS block is configured, indicated, or scheduled to be transmitted. In some cases, a RACH occasion at a certain time, frequency, or location may be used even if it collide with an SS block. In other cases, a RACH occasion at a certain time, frequency, or location may not be used if it collide with an SS block.

[0095] An indication of the semi-static UL / DL configuration may be in the New Radio-Physical Broadcast Channel (NR-PBCH), Residual Minimum System Information (RMSI), Other System Information (OSI), paging, etc. Furthermore, if the WTRU is indicated for a dynamic UL / DL configuration, the dynamic UL / DL configuration may override the semi-static UL / DL configuration. If the dynamic UL / DL configuration is indicated simultaneously with or before the RACH configuration and the dynamic UL / DL configuration overrides the semi-static UL / DL configuration, the WTRU may follow the DL and UL portions in the dynamic UL / DL configuration. The WTRU may then follow the rules for RACH occasion transmissions as described herein.

[0096] 2B shows an example process for RACH transmission without SS block collisions based on one or more embodiments described herein. At 260, the WTRU may receive a semi-static UL / DL slot configuration, such as in the RMSI. At 262, the WTRU may determine the ROs for different portions of the slot (i.e., DL / X / DL / UL) based on the configuration information. At 264, the WTRU may receive a DL indication of the SS block actually transmitted (Txed). In some cases, the WTRU may also receive an indication that the SS block enables / disables override, which may enable / disable the WTRU to have an RO in the location where the SS block is indicated. Based on all or part of the received information, at 266, the WTRU may evaluate whether a given symbol is an occasion (i.e., an RO) for which a RACH may be sent. At 268, the WTRU may evaluate the ROs of the slots and determine whether they are valid ROs with no expected collisions, any rule or indication being considered such that the RACH may actually be sent / scheduled. At 270, the WTRU may transmit the RACH in the previously determined valid RO.

[0097] FIG. 2C illustrates an example of a PRACH transmission without SS block collisions according to one or more embodiments described herein. Each diagram (200, 220, 240) may be the result of one or more stages in any order of the process described in FIG. 2B, as well as any of the rules or conditions for dealing with collisions described herein. In this example, if there is an SS block in the DL control portion, the WTRU may not transmit the RACH in any of these symbols. Also, an RO may be valid if the occasion is after the indicated SS block but not before. Generally, the transmission example shows a single slot broken down into portions with various numbers of symbols (i.e., OFDM) that may be allocated to DL 213, X 214, DL 215, and UL 216. Each symbol may have a particular shading corresponding to what occupies or is indicated to occupy that resource; for example, each possible RO, such as RO 208, has a line going from the upper left to the lower right. No shading may mean unused or unscheduled for that resource.

[0098] In diagram 200, the WTRU may have completed 260, 262, and 264. The WTRU may have determined that SS block 207 occupies a portion of the DL control 213 portion of slot 202, and therefore the DL control portion 213 may not include any RO. Additionally, the remainder of the slot may have several ROs (208, 209, 210, 211) configured by RMSI, etc. There may be a table for the ROs that is not shown. An index that points to an entry in the table may indicate the RO. The WTRU may determine the RO based on the received index indicated by the index in the RMSI and a table known to the WTRU.

[0099] Diagram 220 shows process 266, evaluating whether an RO is a valid opportunity to transmit (i.e., a VRO), and may be similar to diagram 200 except that SS block 229 may be indicated to the WTRU, which in this example results in only UL portion 226 having a valid RO since X portion 224, which was a potential RO, cannot become valid because the WTRU may only have a valid RO after the indicated SS block.

[0100] Diagram 240 shows process 266 and may be similar to diagram 200 except that there is no SS block shown for DL ​​245, which may lead to any RO after DL control portion 243 being a valid RO.

[0101] In one or more embodiments, overlapping preamble subsets may be used. The SS block index may be embedded in the RA-RNTI. The RA-RNTI may be a function of the SS block index. Alternatively or additionally, the SS block index may be included in a random access response (RAR). Furthermore, the SS block index for the overlapping preamble may be embedded in the RA-RNTI and included in the RAR. For example, the SS block index (e.g., for the overlapping preamble) may be embedded in the RA-RNTI (e.g., using different RNTIs for different SS block indices or using different CRC masking for different SS block indices), while the same SS block index (e.g., for the overlapping preamble) may be included in the RAR.

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

[0103] When using gNB Rx / Tx beam correspondence, preamble subsets corresponding to different SS blocks in one RACH slot may overlap to increase capacity for initial access and random access.

[0104] Without gNB Rx / Tx support, if preamble subsets corresponding to different SS blocks in one RACH slot are overlapped, the gNB may not correctly separate the TAs associated with the different SS blocks, so multiple WTRUs using different SS blocks sending the same overlapping preamble may collide.

[0105] When using gNB Rx / Tx correspondence and overlap between gNB Tx beams, if preamble subsets corresponding to different SS blocks in one RACH slot overlap, multiple WTRUs using different SS blocks sending the same overlapping preamble can be separated by the gNB sending the SS block index in the RAR, which can avoid collisions between those WTRUs.

[0106] When using gNB Rx / Tx support and no overlap between gNB Tx / RX beams, if preamble subsets corresponding to different SS blocks in one RACH slot overlap, multiple WTRUs using different SS blocks sending the same overlapping preamble may be geographically separated by the gNB Rx / Tx beams, and the gNB may not need to send the SS block index in the RAR.

[0107] The gNB may configure whether the SS block index should be included in the RAR or the RA-RNTI based on the antenna structure, beam configuration, and / or beam correspondence.

[0108] As shown in FIG. 3, there may be a set or pool 301{1,2,3} of PRACH preambles that may be partitioned into one or more subsets called preamble subsets. An SS block, such as SS block 1 of 304 or SS block 2 of 306, may be associated with one or more preamble subsets. The preamble subsets may or may not overlap with each other. The preamble subsets may or may not share the same preamble. In one example, a RACH configuration may allow, within one RACH occasion (RO), preambles 1 and 2 may be associated with or mapped to SS block 1 of 304, creating subset {1,2}, and preambles 2 and 3 may be associated with or mapped to SS block 2 of 306, creating subset {2,3}. The first preamble subset {1,2} may be associated with or mapped to SS block 1 of 304, while the second preamble subset {2,3} may be associated with or mapped to SS block 2 of 306. As in this example, the preamble subsets may overlap with each other. Preamble 2 may be shared by SS block 2 of 304 and SS block 2 of 306.

[0109] In the gNB, Tx beam 1 of 305 may be associated with SS block 1 of 304, and Tx beam 2 of 307 may be associated with SS block 2 of 306.

[0110] In Case 1, Tx beam 1 of 305 and Tx beam 2 of 307 may overlap, meaning that a WTRU may receive signals from both Tx beam 1 of 305 and Tx beam 2 of 307. In Case 2, Tx beam 1 of 305 and Tx beam 2 of 307 do not overlap, meaning that a WTRU may receive signals only from either Tx beam 1 or Tx beam 2, but not both. Given Case 1 and Case 2, four scenarios may be considered: Scenario 1, Case 1—no gNB Tx / Rx beam support; Scenario 2, Case 2—no gNB Tx / Rx beam support; Scenario 3, Case 1—gNB Tx / Rx beam support; and Scenario 4, Case 2—gNB Tx / Rx beam support.

[0111] In one embodiment, WTRU A may measure the SS blocks, select SS block 1 of 304, and may randomly select a preamble in the preamble subset associated with SS block 1 of 304. The WTRU may select preamble 2. WTRU B may measure the SS blocks, select SS block 2 of 306, and may randomly select a preamble. WTRU B may also select preamble 2.

[0112] The gNB may receive a single preamble (i.e., Preamble 2) from both WTRUs (WTRU A and WTRU B). When the gNB receives Preamble 2, it may determine that the SS blocks (SS Block 1 in 304 and SS Block 2 in 306) are associated with the detected preamble (Preamble 2). The gNB may send two RARs, RAR1 in Tx Beam 1 in 305 and RAR2 in Tx Beam 2 in 307. RAR1 may carry SS Block Index 1 using the RA-RNTI, and RAR2 may carry SS Block Index 2 using the same RA-RNTI. Both WTRUs may decode the same RA-RNTI and decode the RARs accordingly. WTRU A may obtain the SS block index in RAR1 (sent in Tx beam 1 in 305), and WTRU B may obtain the SS block index in RAR2 (sent in Tx beam 2 in 307), and each WTRU may compare the received SS block index with its own selected SS block (WTRU A for SS block 1 in 304 and WTRU B for SS block 2 in 306). If they match, each WTRU may assume the RAR is intended for itself and may send message 3 based on the grant received in its own RAR. Otherwise, each WTRU may discard the received RAR. If WTRU A and WTRU B both select SS block 1 in 304 (or SS block 2 in 306), WTRUs A and B may obtain the SS block index in RAR1 (or RAR2) and a collision may occur. To reduce or eliminate potential collisions, a redundant version preamble method may be used.

[0113] When a gNB has Tx / Rx beam correspondence, a timing advance (TA) may be included in the RAR for the beam transmitting the RAR. In such a situation, SS block-specific TA and / or beam-specific TA may be used. Because the gNB may receive preambles from different Rx beams for different SS blocks, the gNB may estimate a TA for each Rx beam, even though the same preamble is sent by both WTRUs. In RAR1, TA1 for WTRU A may be included in RAR1 sent in Tx beam 1 of 305 associated with SS block 1 of 304. TA2 for WTRU B may also be included in RAR2 sent in Tx beam 2 of 307 associated with SS block 2 of 306.

[0114] In some situations, the gNB may not have Tx / Rx beam correspondence. For example, preamble 2 of WTRU A and preamble 2 of WTRU B may or may not be received from the same Rx beam. If they are received from the same Rx beam, the gNB may not be able to tell that it is the same preamble but sent by two different WTRUs. If they are from different Rx beams, the gNB knows that this preamble is sent from two different WTRUs in two different Rx beams, and the TAs corresponding to the two WTRUs can be estimated. Because there is no Tx / Rx correspondence, the gNB may not know which TA is for SS block 1 of 304 and which is for SS block 2 of 306. Therefore, the TA may be a function of beam correspondence.

[0115] For scenario 3 with Tx / Rx support, the gNB may know the TA of preamble 2 for SS block 1 of 304 and know that it may be included in RAR 1. The gNB may also know the TA of preamble 2 and know that it may be included in RAR 2.

[0116] For scenario 1 or 2, the TA may not be estimated correctly for the WTRU in one example.

[0117] For scenario 3, the TA may be correctly estimated. WTRU A may receive RAR1 over CORESET using RA-RNTI and check that the preamble index (Preamble 2) and SS block index (SS Block 1 of 304) are for itself. Similarly, WTRU B may receive RAR2 over CORESET using RA-RNTI and check that the preamble index (Preamble 2) and SS block index (SS Block 2) are for itself.

[0118] For scenarios 1 or 3, WTRU A may also receive RAR2, but the SS block index in RAR2 (SS block 2 of 306) may not match what it selected for the SS block (SS block 1 of 304), and therefore WTRU A may discard RAR2. Similarly, WTRU B may also receive RAR1, but the SS block index in RAR1 (SS block 1 of 304) may not match what it selected for the SS block (SS block 2 of 306), and therefore WTRU B may discard RAR1.

[0119] For scenario 4, WTRU A may only receive an RAR for itself, and WTRU B may only receive an RAR for itself. The gNB may not need to include the SS block index in the RAR.

[0120] The gNB may be configured to include the SS block index in the RAR or not include the SS block index in the RAR. Additionally, the gNB may be configured to include or embed the SS block index in the RAR and / or RA-RNTI. The gNB may be configured to not include or not embed the SS block index in either the RAR or the RA-RNTI. The configuration for inclusion of the SS block index in the RAR and / or RA-RNTI may be indicated in the NR-PBCH, RMSI, OSI, paging, etc.

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

[0122] For the RACH configuration of scenario 3, the WTRU may select SS block 1 of 304 and send preamble 2, and the gNB may receive preamble 2 using Rx beam 1 and estimate the TA accordingly. Due to beam correspondence, the TA may be known for SS block 1 of 304. The gNB may send an RAR using the RA-RNTI and RAR with the random access preamble ID (RAPID) for preamble 2 corresponding to SS block 1 of 304 and the corresponding TA and RACH Msg3 grant. The WTRU may successfully receive the RAR and obtain the RACH Msg3 grant.

[0123] In one embodiment, WTRU A may select SS block 1 of 304 and send preamble 2. At the same time, WTRU B may select SS block 2 of 306 and send preamble 2. The gNB may receive preamble 2 using Rx beam 1 and estimate TA1, and the gNB may receive preamble 2 using Rx beam 2 and obtain TA2. According to the beam correspondence, TA1 may be for SS block 1 of 304, and TA2 may be for SS block 2 of 306. The gNB may send RAR1 in Tx beam 1 of gNB 305 using information about preamble 2, SS block 1 of 304, TA1, and an RA-RNTI with an Msg3 grant. The gNB may also send RAR2 in Tx beam 2 of gNB 307 using information about preamble 2, SS block 2 of 304, TA2, and an RA-RNTI with another Msg3 grant. WTRU A may receive RAR1 because the SS block index in RAR1 is intended for WTRU A. WTRU B may receive RAR2 because the SS block index in RAR2 is intended for WTRU B.

[0124] In one embodiment for three WTRUs (not shown), WTRUs A, B, and C may send preamble 2 simultaneously. WTRUs A and C may select SS block 1, and WTRU B may select SS block 2. The gNB may receive the preambles over both Rx beams 1 and 2 and send RAR1 and RAR2, respectively. WTRU A and WTRU C may receive RAR1 because the SS block index in RAR1 is 1, and both WTRUs may use the same UL grant and send RACH Msg3 applying TA1. WTRU B may receive RAR2 by applying TA2 and send RACH Msg3. WTRU A's and WTRU C's RACH Msg3 may collide with each other, and the gNB may successfully receive only one RACH Msg3 from one of the WTRUs with the correct TA and fail to decode the other RACH Msg3 (i.e., the gNB may not be able to receive both RACH Msg3).

[0125] In one or more embodiments, the preamble type may be based on a hierarchical association of SS blocks with RACH. An SS block may be associated with a RACH occasion. For example, one SS block may be associated with one RACH occasion. All preamble indices for a RACH occasion may be associated with the same SS block. The WTRU may randomly select any one preamble and transmit the selected preamble in the RACH occasion associated with the selected SS block that the WTRU may wish to convey to the gNB.

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

[0127] In one or more cases, the SS block may be an SS block that is actually transmitted. Alternatively or additionally, the SS block may be a candidate SS block, a nominal SS block, or all SS blocks, including those that are transmitted or not transmitted. If the WTRU is indicated for an SS block that is actually transmitted, the WTRU may use the SS block that is actually transmitted for association with the RACH occasion or resource. If the WTRU is not indicated for an SS block that is actually transmitted, the WTRU may use all SS blocks, including candidate SS blocks, nominal SS blocks, or those that are transmitted or not transmitted for association with the RACH occasion or resource. If the WTRU is indicated or configured to use candidate SS blocks, nominal SS blocks, or all SS blocks for association with the RACH occasion or resource, this may override the use of an SS block that is actually transmitted, even if the WTRU may be indicated for an SS block that is actually transmitted. For example, such an override indication or association configuration may be in RRC signaling or NR-PBCH. The SS block that is actually transmitted may be indicated in RMSI or OSI.

[0128] The techniques described herein may apply to either contention-based random access or contention-free random access, and / or may also apply to both contention-based random access and contention-free random access.

[0129] 4 shows an example of preamble and SS block association. As shown, preambles may be partitioned into multiple subsets A, B, and C of two or more types 401. A first type of preamble subset may be associated with one SS block. A second type of preamble subset may be associated with two or more SS blocks. For example, preamble subsets A and B may each be a first type of preamble subset that may be associated with one SS block, such as SS block 402 and SS block 404, respectively. Preamble subset C may be a second type of preamble subset that may be associated with one or more SS blocks, such as SS blocks 402 and 404.

[0130] In some cases, SS block 402 and SS block 404 may be adjacent to each other with respect to their associated transmitted beams. SS block 402 may have index m and SS block 404 may have index n, where m is n+1 or n-1.

[0131] FIG. 5 illustrates an example method for associating RACH resources and SS blocks. For purposes of illustration, RACH resources and RACH occasions may be interchangeable where appropriate. As shown, RACH resources may be partitioned into multiple subsets A, B, and C of two or more types 501. A first type of RACH resource subset may be associated with one SS block. A second type of RACH resource subset may be associated with two or more SS blocks. For example, RACH resource subsets A and B may each be a first type of preamble subset that may be associated with one SS block, such as SS block 502 and SS block 504, respectively. RACH resource subset C may be a second type of preamble subset that may be associated with two or more SS blocks, such as both SS block 503 and SS block 504.

[0132] In some cases, SS block 502 and SS block 504 may be adjacent to each other with respect to their associated transmitted beams. SS block 402 may have index m and SS block 404 may have index n, where m is n+1 or n-1.

[0133] 6 shows an example process for SS block association and mapping to RACH. The WTRU may perform one or more of the stages as disclosed. At 602, SS blocks to be actually transmitted (SS blocks) may be indicated to the WTRU. At 604, the SS blocks to be actually transmitted may be partitioned into SS block groups. At 606, the SS blocks or SS block groups are mapped to RO or RACH resources. If there are more than one SS blocks per RO or RACH resource at 608, the SS blocks may be mapped to preambles for each RO or RACH resource at 612, followed by preamble type-based or non-preamble type-based preamble subset partitioning and mapping at 614. If there are not more than one SS blocks per RO or RACH resource according to 608, the process may stop at 610.

[0134] FIG. 7 is a schematic diagram illustrating another example method of associating SS blocks and mapping them to a RACH. A WTRU may perform one or more stages of this example. At 702, the number of SS blocks to be actually transmitted may be indicated to the WTRU. At 704, the number of preambles per SS block per RO may be indicated to the WTRU. At 706, the number of SS blocks per RO may be indicated to the WTRU. At 708, the number of ROs in the frequency domain (FDM ROs) may be indicated to the WTRU. At 710, the number of ROs in a slot (TDM ROs) may be indicated to the WTRU. At 712, the number of slots for the RACH may be indicated to the WTRU. At 714, there may be a preamble first mapping that maps SS blocks to preambles. At 716, there may be a frequency second mapping that maps SS blocks to frequency domain ROs (FDM ROs). At 718, there may be a time third mapping that maps SS blocks to time domain ROs (TDM ROs). At 717, there may be a same-slot first mapping that maps SS blocks to time-domain ROs within a slot. At 719, there may be a cross-slot second mapping that maps SS blocks to time-domain ROs across slots. If same-slot mapping is sufficient, cross-slot mapping may not be required. If same-slot mapping is not sufficient (e.g., there are many SSBs that need to be mapped to ROs), cross-slot mapping may be performed. If a mapping cycle is completed for all ROs at 720, proceed to 724 and stop. If a mapping cycle is not completed for an RO at 720, discard the remaining ROs at 722.

[0135] In one or more embodiments, there may be PRACH resource package-based beam sweeping. The number of OFDM symbols in the PRACH preamble format or the number of repetitions of the PRACH preamble format may be smaller than the number of Rx beams of the gNB. The gNB may sweep the Rx beam for the PRACH using multiple RACH occasions. The multiple RACH occasions may consist of one or more RACH resources (e.g., one or more slots, non-slots, minislots, or OFDM symbols). The multiple RACH occasions may be contiguous or non-contiguous. Multiple RACH occasions may be configured in one WTRU. In some cases, the WTRU may assume that there may be multiple RACH occasions as a package. The WTRU may start PRACH preamble transmission using the first RACH occasion, the second RACH occasion, the third RACH occasion, and so on until all beams have been swept. Depending on the number of actually transmitted SS blocks or the number of beams at the gNB, multiple RACH occasions (as packages) with K OFDM symbols may be configured in the WTRU for the K actually transmitted SS blocks or beams at the gNB. To further support WTRU Tx beam sweeping in addition to gNB Rx beam sweeping, if the WTRU has M Tx beams, multiple RACH occasions (as packages) with K × M OFDM symbols may be configured in the WTRU. Different PRACH preamble formats, such as preamble formats A, B, and / or C, may be used. For example, PRACH preamble format A may be A0, A1, A2, A3, and preamble format B may be B1, B2, B3, and B4. Preamble format C may be C0 and C1. The number of SS blocks may be symbolically represented as L. The number of Rx beams at the gNB may be N. rx The number of repetitions of the constructed preamble format is N rp It can be symbolically represented as

[0136] In the absence of beam support, to ensure that the gNB can sweep all Rx beams to receive multiple RACH trials from the WTRU, the gNB must limit the RACH occasion ceiling.

[0137]

number

[0138] The Rx beam of every gNB can be swept by a "RACH occasion package", which can be configured per SS block or for all SS blocks. Different types of RACH occasions can be configured with different N rp RACH occasion ceiling

[0139]

number

[0140] This type may be defined as a "RACH Occasion Package."

[0141] In the case of a retransmission of RACH Msg1, the WTRU may pick up a different RACH occasion type that was not used in the previous RACH Msg1 (re)transmission to complete the Rx beam sweep of the gNB.

[0142] In the case of a retransmission of RACH Msg1, the WTRU may be configured or decided to determine whether to change its UL Tx beam, whether to ramp up power, or whether to change the type of RACH occasion.

[0143] 8 shows an example configuration of window lengths for each random access channel (RACH) occasion type, where the window lengths, such as 806 and 808, of the RACH occasions may be the same as the RACH configuration period, such as 804. The window lengths for each RACH occasion type may be configured such that the window lengths for all RACH occasion types are the same. For example, window length 806 may be the same as the RACH configuration period 804. Alternatively or additionally, the window lengths for all RACH occasion types may be N times the RACH configuration period (not shown), where N may be configured in the residual minimum system information (RMSI). In one example, N may be an integer greater than 1.

[0144] 9 shows an example configuration of window lengths for each random access channel (RACH) occasion type where the window length for the RACH occasion is twice the RACH configuration period. As shown, the window length 906 for the RACH occasion type is configured to be twice the RACH configuration period 904.

[0145] 10 illustrates an example configuration of window lengths for each random access channel (RACH) occasion type, where the window length of the RACH occasion is shorter than the RACH configuration period. As shown, the window length for each RACH occasion type 1006 may be shorter than the RACH configuration period 1004. All RACH occasion types may fall within the RACH configuration period. In some embodiments, the window lengths for different RACH occasion types may be different. A predefined pattern of window lengths may be used. The WTRU may be configured with one pattern in the RMSI.

[0146] The number of RACH occasion types, Q, may be indicated to the WTRU in the NR-PBCH or RMSI. Depending on the beam support, Q may have a different value. For example, for a gNB without beam support, Y = ceiling.

[0147]

number

[0148] For gNBs with beam correspondence, Y = 1. For gNBs with partial beam correspondence, Y = ceiling

[0149]

number

[0150] where:

[0151]

number

[0152] is the number of gNB Rx beams that have overlap with the gNB Tx beams corresponding to the SS block. For example, N rx = 4, and N rp = 2 and L = 4. There can be two types of RACH occasions per SS block: Type 1 RACH occasions can be received by Rx beams 0 and 1 of the gNB; Type 2 RACH occasions can be received by Rx beams 2 and 3 of the gNB.

[0153] In one embodiment, N rx may be set to 64, and N rp may be set to 12, and L may be set to 64 (i.e., N rx = 64, and N rp = 12 and L = 64). There can be six types of RACH occasions per SS block. Each type of RACH occasion can be received by 12 gNB Rx beams, and the subset of gNB Rx beams can be different for different types of RACH occasions.

[0154] In another embodiment, N rx may be set to 2, and N rp can be set to 2 (i.e., N rx= 2, and N rp = 2). In this embodiment, there can be only one type of RACH occasion.

[0155] 11 shows an example redundant version of a preamble based on SS beam reporting. The WTRU 1106 may perform listen-before-talk (LBT) and transmit a RACH preamble. The gNB 1101 may perform LBT and transmit an RAR. If the gNB 1101 fails the LBT in beam 1 of 1104, it may not transmit the RAR in beam 1 of 1104. If the WTRU 1106 reports only one beam (e.g., beam 1 of 1104), the WTRU 1106 may not receive the RAR due to the gNB 1101's LBT failure.

[0156] In one embodiment, the WTRU 1106 may report two or more beams, such as beam 1 of 1104 and beam 2 of 1105 (especially in the beam overlap area). The WTRU 1106 may report the SS block for the strongest beam along with SS blocks for the other beams. The WTRU 1106 may perform an LBT and transmit a RACH preamble that may be associated with SS block #1 (e.g., beam 1 of 1104) and SS block #2 (e.g., beam 2 of 1106). The gNB 1101 may perform an LBT for two or more beams (e.g., beam 1 of 1104 and beam 2 of 1106) and transmit an RAR accordingly. If the LBT fails in beam 1 of 1104, the gNB 1101 may transmit an RAR in the other beam (e.g., beam 2 of 1106). On the other hand, if the gNB 1101 fails the LBT in beam 2 of 1106, it may transmit an RAR in another beam (e.g., beam 1 of 1104). Unless the gNB 1101 fails the LBT in both or all beams, the gNB 1101 may need to continue performing the LBT until the channel is clear before transmitting the RAR. This may result in significant delay and high latency. By reporting two or more SS blocks from the WTRU 1106, the gNB 1101 may be able to transmit the RAR without delay. The association of preambles with SS blocks may be one preamble to many SS blocks. For example, preamble #1 may be associated with SS blocks #1 and #2, preamble #2 may be associated with SS blocks #3 and #4, and so on.

[0157] However, when two or more WTRUs are in the same overlapping area of ​​a beam, multiple WTRUs may report the same preamble, which results in a collision (not shown). In NR or NR-unlicensed, WTRUs in the same overlapping area of ​​a beam may report the same preamble, which may result in a preamble collision if the WTRUs select the same RACH occasion.

[0158] In one embodiment, redundancy version-based SS block reporting may be used, and the gNB may be able to transmit the RAR without delay. The association of preambles and SS blocks may be based on the redundancy of the preamble.

[0159] In one embodiment, a redundant version of preamble association may be used, where the association of preamble and SS block may be one preamble to many SS blocks, and a redundant version of the same association of preamble and SS block may be used. For example, if preamble #1 is associated with SS blocks #1 and #2, then preamble #2 may be a redundant version of preamble #1 and may also be associated with the same SS block (e.g., SS blocks #1 and #2). This may eliminate or reduce WTRU collisions, as WTRUs in the same overlapping area of ​​the beam may not report the same preamble.

[0160] In some cases, the WTRU may report two or more SS blocks using a preamble or RACH Msg3. When preamble-based SS block reporting is used, one preamble may be mapped to multiple SS blocks (e.g., preamble #1 is mapped to SS block #1 and SS block #2). To further reduce collisions, the same mapping may be repeated for another preamble. For example, a redundant version of preamble #1 may be generated for preamble #3. In another example, the redundant version of preamble #1 may be preamble #2, which may be mapped to the same SS block (e.g., SS block #1 and SS block #2), or preamble #3, which may be mapped to the same SS block (e.g., SS block #1 and SS block #2). The gNB may perform directional LBT and send an RAR. If the LBT fails in SS block 1, the gNB may have the flexibility to send an RAR in SS block 2.

[0161] When RACH Msg3-based SS block reporting is used, RACH Msg 3 may include redundancy versions for mapping in its payload so that preamble #1 may be mapped to SS block #1 and SS block #2, preamble #2 may be mapped to SS block #1 and SS block #2, and / or preamble #3 may be mapped to SS block #1 and SS block #2.

[0162] The redundancy version of the preamble-based SS block reporting may apply to initial access and channel access, including random access, beam management for data and / or control, mobility, and / or other use cases and scenarios. The redundancy version of the preamble-based SS block reporting may apply to NR licensed or unlicensed bands and standalone or non-standalone systems.

[0163] Although features and elements of the invention are described in preferred embodiments in specific combinations, each feature or element may be used alone without other features and elements of the preferred embodiments or in various combinations with or without other features and elements of the invention.

[0164] While the embodiments described herein consider protocols specific to LTE, LTE-A, New Radio (NR), or 5G, it should be understood that the embodiments described herein are not limited to this scenario and are also applicable to other wireless systems.

[0165] Although features and elements are described above in particular combinations, those skilled in the art will appreciate that each feature or element may be used alone or in any combination with the other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. 1. A method performed by a wireless transmit / receive unit (WTRU), comprising: receiving an indication of semi-static UL / DL information including a configuration of a random access channel (RACH) occasion; receiving an indication of one or more actually transmitted synchronization signal (SS) blocks; receiving an indication of one or more enabled or disabled SS blocks; determining whether any of the RACH occasions is valid, where the RACH occasion is determined to be valid based on whether the RACH occasion is after all indicated SS blocks that are actually transmitted, or whether the RACH occasion is in the position of an SS block that is actually transmitted but the SS block is indicated as unavailable; transmitting a physical RACH in one or more of the RACH occasions that are determined to be valid; A method comprising:

2. 2. The method of claim 1, wherein the indication of the semi-static UL / DL information is received over a physical broadcast channel (PBCH) in residual minimum system information (RMSI).

3. The method of claim 1, wherein the indication of the SS block actually transmitted is in the DL portion.

4. The method of claim 1 , further comprising receiving a dynamic indication of whether SS block override is enabled or disabled.

5. 5. The method of claim 4, wherein the RACH occasion is validated based on the dynamic indication of whether an SS block is unavailable.

6. 1. A wireless transmit / receive unit (WTRU) comprising a processor coupled to a transceiver, The processor and the transceiver are configured to receive an indication of semi-static UL / DL information including a configuration of a random access channel (RACH) occasion, receive an indication of one or more actually transmitted synchronization signal (SS) blocks, and receive an indication of whether the one or more actually transmitted SS blocks; The processor and the transceiver are further configured to determine whether any of the RACH occasions are valid, and determine that the RACH occasion is valid based on whether the RACH occasion is after all indicated SS blocks that are actually transmitted, or whether the RACH occasion is in the position of an SS block that is actually transmitted but the SS block is indicated as unavailable, and transmit a physical RACH in one or more of the RACH occasions that are determined to be valid.

7. The WTRU of claim 6 , wherein the indication of the semi-static UL / DL information is received in residual minimum system information (RMSI) over a physical broadcast channel (PBCH).

8. The WTRU of claim 6 , wherein the indication of an SS block actually transmitted is in a DL portion.

9. The WTRU of claim 6 , wherein the processor and the transceiver are further configured to receive a dynamic indication of whether SS block override is enabled or disabled.

10. The WTRU of claim 9 , wherein the RACH occasion is validated based on the dynamic indication of whether an SS block is unavailable.

Images