CN111406436A - Initial access and channel access in new radio/new radio-unlicensed (NR/NR-U) - Google Patents

Abstract

A Wireless Transmit Receive Unit (WTRU) may then evaluate whether a RACH opportunity exists based on the configuration information and determine whether any of the RACH opportunities is valid, wherein the RACH opportunity may be valid based on whether the RACH opportunity is after all actually transmitted SS block indications and/or whether SS block coverage is disabled or enabled.

Description

Initial access and channel access in New Radio/New Radio-Unlicensed (NR/NR-U)

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of US Provisional Application No. 62/590,936, filed November 27, 2017, and US Provisional Application No. 62/630,692, filed February 14, 2018, the contents of which are incorporated herein by reference.

Background technique

Fifth generation (5G) wireless systems are the next telecom standard beyond fourth generation (4G) standards. 5G is generally designed to provide higher capacity than 4G, allowing for higher densities of mobile broadband users, higher reliability, and support for device-to-device and large-scale machine communications. A broad classification of 5G system use cases may include enhanced mobile broadband (eMBB), Massive Machine Type Communication (mMTC), and Ultra Reliable and Low Latency Communication (URLLC). These use cases may focus on different requirements such as high data rate, high spectral efficiency, low power and high energy efficiency, low latency and high reliability. For various such deployment scenarios, various frequency bands ranging from 700MHz to 80GHz can be considered.

As the carrier frequency increases, severe path loss can become a critical limitation in ensuring adequate coverage of wireless devices. For example, transmission in mmWave systems may suffer from non-line-of-sight losses, such as diffraction losses, penetration losses, oxygen absorption losses, foliage losses, and the like. During initial access, the base station (BS) and wireless transmit receive unit (WTRU) may need to overcome these high path losses and discover each other. Utilizing dozens or even hundreds of antenna elements to generate beamforming 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 the initial access or random access procedure. 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 a 5G scenario.

SUMMARY OF THE INVENTION

Methods, systems and apparatus for resolving possible collisions of random access channel (RACH) occasions. A wireless transmit receive unit (WTRU) may receive an indication of semi-static UL/DL information including RACH occasion configuration and about one or more actually transmitted synchronization signal (SS) blocks in residual minimum system information (RMSI) via PBCH instructions. 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 based on the following: RACH occasions are after all actually transmitted SS block indications and/or Whether to disable or enable SS block overrides. The WTRU may transmit the RACH in one or more RACH occasions that have been determined to be valid.

Description of drawings

A more detailed understanding can be obtained from the following description given by way of example in the accompanying drawings, in which like reference numerals refer to like elements, and in which:

1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented.

FIG. 1B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communication system shown in FIG. 1A, according to one embodiment.

Figure 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system shown in Figure 1A, according to one embodiment.

1D is a system diagram illustrating another example RAN and another example CN that may be used within the communication system shown in FIG. 1A, according to one embodiment.

2A is a diagram illustrating an example of RACH/PRACH transmission;

2B is a flowchart illustrating an example process for RACH transmission without SS block collisions based on one or more embodiments described herein;

2C is a diagram illustrating an example of PRACH transmission without SS block collisions based on one or more embodiments described herein;

3 is a diagram illustrating an example overlap of preamble and synchronization signal (SS) blocks;

4 is a diagram illustrating an example method of preamble and SS block association;

5 is a diagram illustrating an example method of RACH occasion (or RACH resource) and SS block association;

6 is a diagram illustrating an example method of SS block association and mapping to RACH;

7 is a diagram illustrating another example method of SS block association and mapping to RACH;

8 is a diagram showing an example configuration of the window length for each RACH occasion type, where the window length of the RACH occasion type is the same as the RACH configuration period;

9 is a 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 twice the RACH configuration period;

10 is a diagram illustrating an example configuration of a window length for each random access channel (RACH) opportunity type, where the window length of the RACH opportunity type is less than the RACH configuration period; and

11 is a diagram illustrating an example redundancy version of a preamble based on SS beam reporting.

Detailed ways

FIG. 1A is a diagram illustrating an exemplary 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 voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may use 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 Multi-Carrier (FBMC), etc.

As shown in FIG. 1A, communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104/113, CN 106/115, public switched telephone network (PSTN) 108, Internet 110, and others Network 112, however, it should be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each WTRU 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. For example, any WTRU 102a, 102b, 102c, 102d may be referred to as a "station" and/or "STA", which may be configured to transmit and/or receive wireless signals, and may include user equipment (UE) , mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smart phones, laptops, netbooks, personal computers, wireless sensors, 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. telesurgery), industrial devices and applications (e.g. robotics and/or in industrial and and/or other wireless devices operating in an automated processing chain environment), consumer electronic devices, and devices operating on commercial and/or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, 102d may be referred to interchangeably as a UE.

Communication system 100 may also include base station 114a and/or base station 114b. Each base station 114a, 114b may be configured to facilitate access to one or more communication networks (eg CN 106/115, Internet 110, and/or other network 112) devices of any type. For example, the base stations 114a, 114b may be base transceiver stations (BTS), NodeBs, eNodeBs, Home NodeBs, Home eNodeBs, gNBs, NRNodeBs, site controllers, access points (APs) , and wireless routers, etc. Although each base station 114a, 114b has been described as a single component, it should be understood. Base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

The base station 114a may be part of the RAN 104/113, and the RAN may also include other base stations and/or network components (not shown) such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Wait. Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies called cells (not shown). These frequencies can be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a specific geographic area that is relatively fixed or may vary over time. A cell can be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, that is, each transceiver corresponds to a sector of the cell. In one embodiment, the base station 114a may use multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, by using beamforming, signals can be transmitted and/or received in a desired spatial direction.

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

More specifically, as described above, the communication system 100 may be a multiple access system and may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a and the 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 use Wideband CDMA (WCDMA) ) to establish the air interface 115/116/117. 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 UL Packet Access (HSUPA).

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

In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement some radio technology, such as NR radio access, that may use New Type Radio (NR) to establish the air interface 116.

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

In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (ie Wireless High Fidelity (WiFi)), IEEE 802.16 (Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Interim Standard for GSM Evolution Enhanced Data Rates (EDGE) and GSM EDGE (GERAN) and more.

Base station 114b in FIG. 1A may be a wireless router, Home NodeB, Home eNodeB, or access point, and may use any suitable RAT to facilitate wireless connectivity in localized areas, such as business premises, residences, vehicles, campuses, Industrial facilities, air corridors (e.g. for drones), and roads, to name a few. In one embodiment, the base station 114b and the WTRUs 102c, 102d may establish a wireless local area network (WLAN) by implementing a radio technology such as IEEE 802.11. In one embodiment, the base station 114b and the WTRUs 102c, 102d may establish a wireless personal area network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or millicell by using a cellular-based RAT (eg, WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) micro-community. As shown in FIG. 1A , the base station 114b may be directly connected to the Internet 110 . Thus, base station 114b does not need to access Internet 110 via CN 106/115.

The RAN 104/113 may communicate with the CN 106/115, which may be configured to provide voice, data, applications and/or voice over internet protocol (VoIP) to one or more of the WTRUs 102a, 102b, 102c, 102d. ) to serve any type of network. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106/115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and/or may perform advanced security functions such as user authentication. Although not shown in Figure 1A, it should be appreciated that the RAN 104/113 and/or CN 106/115 may communicate directly or indirectly with other RANs that use the same RAT or a different RAT as the RAN 104/113. For example, CN 106/115 can communicate with other RANs (not shown) using GSM, UMTS, CDMA 2000, WiMAX, E-UTRA or WiFi radio technologies in addition to connecting to RAN 104/113 using NR radio technologies .

The CN 106/115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). Internet 110 may include a global system of interconnected computer network devices using 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, which may use the same RAT or a different RAT as the RANs 104/113.

Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multimode capabilities (eg, the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers that communicate over different wireless links with different wireless networks ). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a, which may use a cellular-based radio technology, and with a base station 114b, which may use an IEEE 802 radio technology.

FIG. 1B is a system diagram showing an example WTRU 102. FIG. As shown in FIG. 1B , WTRU 102 may include processor 118 , transceiver 120 , transmit/receive components 122 , speaker/microphone 124 , keyboard 126 , display/touchpad 128 , non-removable memory 130 , removable memory 132 , power supply 134 , global positioning system (GPS) chipset 136 , and other peripherals 138 . It should be appreciated that the WTRU 102 may also include any subcombination of the foregoing components while remaining consistent with the embodiments.

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 , Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuits (ICs), and state machines, among others. The processor 118 may perform signal encoding, data processing, power control, input/output processing, and/or any other function that enables the WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120 , which may be coupled to transmit/receive component 122 . Although FIG. 1B depicts processor 118 and transceiver 120 as separate components, it should be understood that processor 118 and transceiver 120 may also be integrated in one electronic component or chip.

Transmit/receive component 122 may be configured to transmit or receive signals to or from a base station (eg, base station 114a ) via air interface 116 . For example, in one embodiment, transmit/receive component 122 may be an antenna configured to transmit and/or receive RF signals. As an example, in another embodiment, transmit/receive component 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals. In yet another embodiment, transmit/receive component 122 may be configured to transmit and/or receive RF and optical signals. It should be appreciated that transmit/receive component 122 may be configured to transmit and/or receive any combination of wireless signals.

Although the transmit/receive component 122 is depicted in FIG. 1B as a single component, the WTRU 102 may include any number of transmit/receive components 122 . More specifically, the WTRU 102 may use MIMO techniques. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive components 122 (eg, multiple antennas) that transmit and receive radio signals over the air interface 116 .

The transceiver 120 may be configured to modulate signals to be transmitted by the transmit/receive component 122 and to demodulate signals received by the transmit/receive component 122 . As mentioned above, the WTRU 102 may have multimode capability. Accordingly, the transceiver 120 may include multiple transceivers that allow the WTRU 102 to communicate via multiple RATs (eg, NR and IEEE 802.11).

The processor 118 of the WTRU 102 may be coupled to the speaker/microphone 124, the keyboard 126, and/or the display/touchpad 128 (eg, a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive input from these components user input data. Processor 118 may also output user data to speaker/microphone 124 , keyboard 126 and/or display/touchpad 128 . Additionally, processor 118 may access information from, and store information in, any suitable memory, such as non-removable memory 130 and/or removable memory 132 . Non-removable memory 130 may include random access memory (RAM), read only memory (ROM), hard disk, or any other type of memory storage device. Removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located in the WTRU 102, such as a server or home computer (not shown), by way of example.

The processor 118 may receive power from the power source 134 and may be configured to distribute and/or control power for other components in the WTRU 102 . Power supply 134 may be any suitable device for powering WTRU 102 . For example, power source 134 may include one or more dry battery packs (eg, nickel-cadmium (Ni-Cd), nickel-zinc (Ni-Zn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, and fuel cells, etc.

The processor 118 may also be coupled to a GPS chipset 136 , which may be configured to provide location information (eg, longitude and latitude) related to the current location of the WTRU 102 . In addition to or in lieu of information from GPS chipset 136, WTRU 102 may receive location information from base stations (eg, base stations 114a, 114b) via air interface 116, and/or based on signals received from two or more nearby base stations timing to determine its location. It should be appreciated that the WTRU 102 may obtain location information via any suitable positioning method while remaining consistent with the embodiments.

模块、调频(FM)无线电单元、数字音乐播放器、媒体播放器、视频游戏机模块、因特网浏览器、虚拟现实和/或增强现实(VR/AR)设备、以及活动跟踪器等等。周边设备138可以包括一个或多个传感器，所述传感器可以是以下的一个或多个：陀螺仪、加速度计、霍尔效应传感器、磁强计、方位传感器、邻近传感器、温度传感器、时间传感器、地理位置传感器、高度计、光传感器、触摸传感器、磁力计、气压计、手势传感器、生物测定传感器和/或湿度传感器。The processor 118 may also be coupled to other peripheral devices 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, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and/or video), universal serial bus (USB) ports, vibration devices, television transceivers, hands-free headsets ,

modules, frequency modulation (FM) radio units, digital music players, media players, video game console modules, internet browsers, virtual and/or augmented reality (VR/AR) devices, and activity trackers, among others. Peripherals 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, Geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor and/or humidity sensor.

The WTRU 102 may include a full-duplex radio for which some or all signals (eg, with specific subframes for UL (eg, for transmission) and downlink (eg, for reception) associated) reception or transmission may be concurrent and/or simultaneous. A full-duplex radio may include signal processing by hardware (eg, choke coils) or by a processor (eg, a separate processor (not shown) or by processor 118 ) to reduce and/or substantially eliminate self Interfering with the interface snap-in. In one embodiment, the WTRU 102 may include a half-cycle for transmitting and receiving some or all signals (eg, associated with particular subframes for UL (eg, for transmission) or downlink (eg, for reception)). Duplex radio equipment.

Figure 1C is a system diagram illustrating the RAN 104 and CN 106 according to one embodiment. As described above, the RAN 104 may use E-UTRA radio technology over the air interface 116 to communicate with the WTRUs 102a, 102b, 102c. The RAN 104 may also communicate with the CN 106 .

The RAN 104 may include eNodeBs 160a, 160b, 160c, however it should be understood that the RAN 104 may include any number of eNodeBs while remaining consistent with an embodiment. Each eNodeB 160a, 160b, 160c may include one or more transceivers that communicate over the air interface 116 with the WTRUs 102a, 102b, 102c. In one embodiment, the eNodeBs 160a, 160b, 160c may implement MIMO techniques. Thus, for example, the eNodeB 160a may use multiple antennas to transmit wireless signals to and/or receive wireless signals from the WTRU 102a.

Each eNodeB 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and/or DL, and the like. As shown in FIG. 1C, the eNodeBs 160a, 160b, 160c can communicate with each other through the X2 interface.

The CN 106 shown in FIG. 1C may include a Mobility Management Gateway (MME) 162 , a Serving Gateway (SGW) 164 and a Packet Data Network (PDN) Gateway (or PGW) 166 . While each of the foregoing components are described as being part of CN 106, it should be understood that any of these components may be owned and/or operated by entities other than the CN operator.

The MME 162 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via the S1 interface and may act as a control node. For example, the MME 142 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, performing bearer activation/deactivation processing, selecting a particular serving gateway during the initial attach procedure of the WTRUs 102a, 102b, 102c, and so on. MME 162 may also provide a control plane function for handover between RAN 104 and other RANs (not shown) using other radio technologies (eg, GSM and/or WCDMA).

The SGW 164 may connect to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. Also, the SGW 164 may perform other functions such as anchoring the user plane during inter-eNB handovers, triggering paging processing when DL data is available for the WTRUs 102a, 102b, 102c, and managing and storing the WTRUs 102a, 102b, 102c context and so on.

The SGW 164 may be connected to a PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network (eg, the Internet 110) to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network (eg, the PSTN 108) to facilitate communications between the WTRUs 102a, 102b, 102c and conventional landline communications equipment. For example, CN 106 may include or communicate with an IP gateway (eg, an IP Multimedia Subsystem (IMS) server), and the IP gateway may act as an interface between CN 106 and PSTN 108 . Additionally, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers.

Although the WTRUs are depicted in Figures 1A-1D as wireless terminals, it should be appreciated that in certain exemplary embodiments, such terminals may use a (eg, temporary or permanent) wired communication interface with a communication network.

In typical embodiments, the other network 112 may be a WLAN.

A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STA) associated with the AP. The AP may access or interface to a Distributed System (DS) or other type of wired/wireless network that carries traffic to and/or out of the BSS. Traffic originating outside the BSS and destined for the STA may arrive through the AP and be delivered to the STA. Traffic originating from the STA and destined for a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Traffic between STAs within the BSS may be sent through the AP, eg, the source STA may send the traffic to the AP and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and/or referred to as point-to-point traffic. The point-to-point traffic may be sent with direct link setup (DLS) between the source and destination STAs (eg, directly therebetween). In some typical embodiments, DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Independent BSS (IBSS) mode may have no APs, and STAs (eg, all STAs) that are either inside the IBSS or use the IBSS may communicate directly with each other. Here, the IBSS communication mode may sometimes be referred to as an "ad hoc" communication mode.

When using the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP can transmit beacons on a fixed channel (eg, the primary channel). The main channel may have a fixed width (eg a bandwidth of 20 MHz) or a width set dynamically by means of signaling. The primary channel may be the working channel of the BSS and may be used by the STA to establish a connection with the AP. In some typical embodiments, what is implemented may be Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) (eg, in 802.11 systems). For CSMA/CA, STAs including the AP (eg, each STA) can sense the primary channel. A particular STA may back off if it senses/detects and/or determines that the primary channel is busy. In a given BSS, there may be one STA (eg, only one station) transmitting at any given time.

High Throughput (HT) STAs may use 40MHz-wide channels for communication (eg, by combining a 20MHz-wide primary channel with a 20MHz-wide adjacent or non-adjacent channel to form a 40MHz-wide channel) .

Very high throughput (VHT) STAs may support channels with widths of 20MHz, 40MHz, 80MHz, and/or 160MHz. 40MHz and/or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining 8 contiguous 20MHz channels or by combining two non-contiguous 80MHz channels (this combination can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel encoding, the data can be passed through a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing as well as time domain processing can be performed independently on each stream. The streams may be mapped on two 80MHz channels, and data may be transmitted by the STA performing the transmission. At the receiver of the STA performing the reception, the above operations for the 80+80 configuration may be reversed and the combined data may be sent to the medium access control (MAC).

802.11af and 802.11ah support sub-1GHz operating modes. Compared with 802.11n and 802.11ac, the channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah. 802.11af supports 5MHz, 10MHz and 20MHz bandwidths in TV white space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz and 16MHz bandwidths using non-TVWS spectrum. According to typical embodiments, 802.11ah may support meter type control/machine type communications (eg, MTC devices in macro coverage areas). The MTC may have certain capabilities, such as limited capabilities including support (eg, only) of certain and/or limited bandwidths. The MTC device may include a battery with a battery life above a threshold (eg, to maintain a long battery life).

For WLAN systems that can support multiple channels and channel bandwidths (eg, 802.11n, 802.11ac, 802.11af, and 802.11ah), the WLAN system includes one channel that can be designated as the primary channel. The bandwidth of the primary channel may be equal to the maximum common working bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by a certain STA originating from all STAs operating in the BSS supporting the minimum bandwidth operating mode. In the example regarding 802.11ah, even though APs and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz and/or other channel bandwidth operating modes, for STAs that support (eg only support) 1MHz mode (eg MTC type of device), the width of the main channel can be 1MHz. Carrier sensing and/or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy (eg, because STAs (which only support 1 MHz operating mode) transmit to the AP), the entire available frequency band may be considered busy even though most of the frequency band remains free and available.

In the US, the available frequency bands for 802.11ah are 902MHz to 928MHz. In Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. Depending on the country code, the total bandwidth available for 802.11ah is 6MHz to 26MHz.

Figure ID is a system diagram showing the RAN 113 and CN 115 according to one embodiment. As described above, the RAN 113 may use NR radio technology over the air interface 116 to communicate with the WTRUs 102a, 102b, 102c. The RAN 113 may also communicate with the CN 115 .

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

The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with the scalable parameter configuration. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may be different for different transmissions, different cells, and/or different wireless transmission spectrum portions. The WTRUs 102a, 102b, 102c may use subframes or transmission time intervals (TTIs) of different or scalable lengths (eg, containing different numbers of OFDM symbols and/or varying absolute time lengths) to communicate with the gNBs 180a, 180b. , 180c to communicate.

The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in standalone and/or non-standalone configurations. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without access to other RANs (eg, eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may use signals in the unlicensed band to communicate with the gNBs 180a, 180b, 180c. In a non-standalone configuration, WTRUs 102a, 102b, 102c may communicate/connect with gNBs 180a, 180b, 180c at the same time as other RANs (eg, eNodeBs 160a, 160b, 160c). For example, a WTRU 102a, 102b, 102c may communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c in a substantially simultaneous manner by implementing DC principles. 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 the WTRUs 102a, 102b , 102c to provide services.

Each gNB 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and/or DL, support network slicing, implement dual connectivity control of interworking between NR and E-UTRA, routing user plane data to User Plane Functions (UPF) 184a, 184b, and routing to Access and Mobility Management Functions (AMF) 182a, 182b Flat information and more. As shown in Figure ID, gNBs 180a, 180b, 180c can communicate with each other through the X2 interface.

The CN 115 shown in Figure 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 foregoing components are described as being part of the CN 115, it should be understood that any of these components may be owned and/or operated by entities other than the CN operator.

The AMFs 182a, 182b may connect to one or more gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as control nodes. For example, AMFs 182a, 182b may be responsible for authenticating users of WTRUs 102a, 102b, 102c, supporting network slicing (eg, handling different PDU sessions with different needs), selecting specific SMFs 183a, 183b, managing registration areas, terminating NAS signaling, And mobility management and so on. The AMF 182a, 1823b may use network slicing processing to tailor the CN support provided to the WTRU 102a, 102b, 102c based on the type of service used by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access services, and/or services for machine type communication (MTC) access, and the like. AMF 162 may provide for handover between RAN 113 and other RANs (not shown) using other radio technologies (eg, LTE, LTE-A, LTE-APro, and/or non-3GPP access technologies such as WiFi) Control plane functionality.

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

The UPFs 184a, 184b may connect to one or more gNBs 180a, 180b, 180c in the RAN 113 via the N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network (eg, the Internet 110) to facilitate Communication between WTRUs 102a, 102b, 102c and IP-enabled devices, 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 , as well as providing mobility anchoring processing and so on.

CN 115 may facilitate communications with other networks. For example, CN 115 may include or may communicate with an IP gateway (eg, an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 115 and 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 connect to local data via the N3 interface docked to the UPFs 184a, 184b and the N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b and through the UPFs 184a, 184b Network (DN) 185a, 185b.

In view of Figures 1A-1D and the corresponding descriptions with respect to Figures 1A-1D, one or more or all of the functions described herein with respect to one or more of the following may be performed by one or more emulation devices (not shown): WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-ab, UPF 184a-b, SMF 183a-b, DN 185a-b and /or any other device(s) described herein. These emulated devices may be one or more devices configured to emulate one or more or all of the functions herein. For example, these simulated devices may be used to test other devices and/or simulate network and/or WTRU functionality.

The simulated device may be designed to perform one or more tests on other devices in a laboratory environment and/or in a carrier network environment. For example, the one or more emulated devices may perform one or more or all functions while being implemented and/or deployed in whole or in part as part of a wired and/or wireless communication network in order to test other devices within the communication network. The one or more emulated devices may perform one or more or all of the functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network. The emulated device may be directly coupled to other devices to perform testing, and/or may use over-the-air wireless communications to perform testing.

The one or more emulated devices may perform one or more functions, including all functions, while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the simulated device may be used in a test laboratory and/or test scenario of a wired and/or wireless communication network that is not deployed (eg, tested) in order to perform testing on one or more components. The one or more emulated devices may be test devices. The emulation device may transmit and/or receive data using direct RF coupling and/or wireless communication via RF circuitry (which may include one or more antennas, by way of example).

A radio access network (RAN) may be part of a mobile telecommunications system that provides a wireless transmit receive unit (WTRU) with a connection to its core network (CN). In Fifth Generation (5G) or Next Generation (NG) wireless systems, the RAN may be referred to as New Radio (NR) RAN or Next Generation RAN. According to the general requirements specified by ITU-R, NGMN and 3GPP, a broad classification of use cases for NR can be enhanced mobile broadband (eMBB), massive machine type communication (mMTC), and ultra-reliable and low-latency communication (URLLC). Different use cases may focus on different requirements, such as higher data rates, higher spectral efficiency, lower power and higher energy efficiency, lower latency and higher reliability. For various deployment scenarios, various frequency bands ranging from 700MHz to 80GHz can be considered.

As the carrier frequency increases, severe path loss can become a critical limitation to ensure adequate coverage. Transmission in mmWave systems may also suffer from non-line-of-sight losses such as diffraction loss, penetration loss, oxygen absorption loss, leaf loss, etc. During initial access, the base station and the WTRU may need to overcome these high path losses and discover each other, or the WTRU may need to discover another WTRU. Utilizing dozens or even hundreds of antenna elements to generate beamforming signals can be an effective way to compensate for severe path loss by providing significant beamforming gain. Beamforming techniques can include digital, analog, and hybrid beamforming.

Long Term Evolution (LTE) and other wireless systems may use initial synchronization and broadcast channels. The WTRU may use a cell search to obtain time and frequency synchronization with a cell and detect the cell ID of the cell. Synchronization signals such as LTE may be sent in the 0th and 5th subframes of each radio frame, and may be used for time and frequency synchronization during initialization. As part of the system acquisition process, the WTRU may synchronize sequentially to OFDM symbols, slots, subframes, fields, and/or radio frames based on synchronization signals. There may be two synchronization signals: a primary synchronization signal (PSS) and a secondary synchronization signal (SSS). PSS can be used to obtain slot, subframe and field boundaries. It can also provide physical layer cell identity (PCI) within the cell identity group. SSS can be used to obtain radio frame boundaries. It may also enable the WTRU to determine the set of cell identities, which may range from 0 to 167.

After successful synchronization and PCI acquisition, the WTRU may decode a channel such as a Physical Broadcast Channel (PBCH) with the aid of a Cell-Specific Reference Signal (CRS) and acquire Master Information Block (MIB) information about system bandwidth, system frame Number (SFN) and PHICH configuration. The LTE synchronization signal and the PBCH may be continuously transmitted according to a standardized period.

LTE and other wireless systems may use random access (RA) procedures. The base station (eg, eNodeB, eNB, gNB) and/or WTRU may use random access procedures for at least one of: WTRU initial access (eg, initial access to a cell or eNB); reset UL timing (eg, WTRU UL timing that is reset or aligned relative to a cell); and/or timing is reset during handover (eg, WTRU timing is reset or aligned relative to the handover target cell). The WTRU may transmit a certain physical random access channel (PRACH) preamble sequence on a certain power PRACH (which may be based on configured parameters and/or measurements), and the WTRU may transmit using a certain time-frequency resource or resources preamble. Configuration parameters that may be provided or configured by the eNB may include one or more of the following: initial preamble power (eg, preambleInitialReceivedTargetPower), preamble format-based offset (eg, deltaPreamble), random access response window (eg, deltaPreamble) , ra-ResponseWindowSize), power ramp factor (eg, powerRampingStep), and/or maximum number of retransmissions (eg, preambleTransMax). PRACH resources, which may include preambles or groups of preambles and/or time/frequency resources that may be used for preamble transmission, may be provided or configured by the eNB. The measurement may include path loss. The time-frequency resource(s) may be selected by the WTRU from an allowed set, or may be selected by the eNB and signaled to the WTRU. After the WTRU transmits the preamble, if the eNB detects the preamble, it may respond with a Random Access Response (RAR). If the WTRU does not receive the RAR for the transmitted preamble (eg, which may correspond to a certain preamble index and/or time/frequency resource) within the allotted time (eg, ra-ResponseWindowSize), the WTRU may Send another preamble at a later time at a higher power (eg, powerRampingStep above the previous preamble transmission), where the transmit power may be limited by the maximum power, which may be, for example, the WTRU configuration for the entire WTRU The maximum power (eg, PCMAX) or the maximum power for a certain serving cell of the WTRU (eg, PCMAX,c). The WTRU may again wait to receive the RAR from the eNB. This send and wait sequence may continue until the eNB can respond with RAR or until the maximum number of random access preamble transmissions (eg, preambleTransMax) may have been reached. The eNB may send the RAR in response to the single preamble transmission, and the WTRU may receive the RAR.

The random access procedure can be contention-based or contention-free. The contention-free procedure may be initiated by, eg, a request from the eNB. The request may be received via physical layer signaling, such as a PDCCH order, or by higher layer signaling, such as an RRC reconfiguration message (eg, an RRC connection reconfiguration message), which may include mobility control information and It may eg indicate or correspond to a handover request. For a contention-free procedure initiated by a PDCCH order in subframe n, the PRACH preamble may be sent in the first subframe or in the first subframe n+k2 available for PRACH, where k2 may be greater than or equal to 6 (ie, k2 >=6). When initiated by an RRC command, there may be other delays that may be specified (eg, there may be minimum and/or maximum required or allowed delays). As an example, the WTRU may autonomously initiate contention-based procedures for reasons including initial access, recovery of UL synchronization, and/or recovery from radio link failure. For certain events, such as events other than recovering from a radio link failure, it may not be defined or specified how long after such an event the WTRU may send the PRACH preamble.

For contention-free random access (RA) procedures, the network signaled PRACH preamble may be used, eg, by the WTRU. For contention-based random access procedures, the WTRU may autonomously select a preamble, where the preamble format and/or time/frequency resource(s) available for preamble transmission may be based on which may be provided or signaled by the eNB Indication or index of notification (eg, PRACH configuration index).

One of the preambles transmitted with progressively higher transmit power may be detected by the eNB. The eNB may send the RAR in response to a detected preamble. The PRACH preamble can be considered as a PRACH resource. For example, PRACH resources may include PRACH preamble, time and/or frequency resources. The terms RACH resource and PRACH resource are used interchangeably herein. Furthermore, the terms RA, RACH and PRACH are used interchangeably herein.

In some cases 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. In order for the WTRU to perform initial access, channel access, maintain system operation, and/or maximize system efficiency, rules may be required to avoid, mitigate, or handle these or other conflicting situations. Also, in other cases, a WTRU transmission may collide with another WTRU transmission during random access. For example, PRACH preambles may collide with each other, such as when using a multi-beam system. Enhanced collision reduction in beam-based systems may be required to address these and other path loss conditions. Furthermore, to support a large number of beams for beam scanning, the PRACH preamble format may not be sufficient due to the limited number of symbols. Therefore, it may be desirable to have a method to support a large number of beams. In one or more embodiments, PRACH resources, DL/UL control, and/or SS/PBCH blocks may be processed to address the problem scenarios discussed herein.

Figure 2A shows an example of RACH/PRACH transmission. Typically, the first DL 203 may be the first SS block and the second DL 205 may be the second SS block. A slot may have a DL (203 and 205) and a UL portion 206. Furthermore, the flexible or unknown part X204 can be used in time slots and can be configured as DL or UL. The DL signal/channel 203 may occupy the first K ₁ OFDM symbols of the timeslot 202, where K is some non-negative integer. The unknown/flexible part X 204 may occupy K ₂ OFDM symbols. The second DL signal/channel 205 may occupy K ₃ OFDM symbols, which may be the same as or different from the first DL signal/channel 203 (eg, the DL signal/channel 203 may be the first SS/PBCH block, the DL signal/channel 205 can be the second SS/PBCH block). The UL signal/channel 206 may occupy the last K ₄ OFDM symbols of the slot 202 . As discussed herein, SS blocks and SS/PBCH blocks may be interchangeable. Timeslots 202 may be configured such that each or some symbol positions may contain a specific type of content; for the example shown in Figure 2A, K1 may be the _first 4 symbols for DL signals/channels 203, and the first 4 symbols for UL signals/channels 206, K ₄ can be the last 2 symbols. The periodicity can also be configured by the gNB to avoid collisions, however some predetermined or predefined rules such as block, signal and/or channel dropping rules can be used when/if PRACH collides with SS blocks. SS blocks, DL/UL control and PRACH may have predefined rules when they collide with each other, which the WTRU may implement to handle these issues.

When SS/PBCH blocks and RACH resources collide, the WTRU may take one or more actions to resolve the issue, such as the WTRU discarding the PRACH and receiving the SS block, or the WTRU discarding the SS block and sending the PRACH. The WTRU may also send PRACH in part or receive SS blocks in part. These options for collision handling may be based on at least one of: actual or maximum SS blocks sent; delay requirements; service type (eg, URLLC, eMBB, mMTC, etc.); predefined or predetermined rules (eg, , always send SS blocks or always send PRACH and drop another channel); channel priorities, where priorities can be predefined or configured; preemption indications; indications received from the gNB about which to send and which to drop; in the event of a collision Send some or all of the channels using rate matching or puncturing; and/or a combination of the above.

If the WTRU receives an indication of the actually sent SS block, the WTRU may use the actual sent SS block position to handle the collision. For example, for long sequences (eg, long preamble sequences for PRACH), the WTRU may drop the RACH when there is a collision. Otherwise, the WTRU may send the RACH. For short sequences (eg, short preamble sequences for PRACH), the WTRU may transmit the RACH in non-slots (eg, 2 symbols, 4 symbols) where symbols are not occupied by the SS block. As discussed herein, a non-slot can be any unconventional length slot (eg, a mini-slot). Also, for short sequences, the WTRU may transmit the partial RACH in non-slots (eg, 2 symbols, 4 symbols) in which the symbols are partially occupied by the SS block. The SS block may be the actual transmitted SS block, or the SS block may be a candidate SS block location.

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

As discussed herein, there may be situations where there may or may be a conflict between RACH resources or RACH occasions and the SS block(s). As discussed therein, references to RACH occasions may be interchanged with RACH resources; RACH occasions may be one or more symbols in a slot in which RACH/PRACH may be transmitted. Slots, non-slots or mini-slots with SS blocks can be configured as RACH occasions according to the RACH configuration table. If there is a collision between the RACH occasion and the SS block, the WTRU may still send the PRACH preamble or RACH message 3 by skipping the symbols occupied by the SS block(s). The gNB may perform partial correlation for PRACH preamble, or perform rate matching for RACH message 3PUSCH. The number of SS blocks may change. For example, the number of SS blocks may be changed from 4 to 2. 2 SS blocks may occupy the first SS block slot. Alternatively, the position of 2 SS blocks may still be the same as when there are 4 SS blocks.

As discussed herein, there may be situations where UL control channel and RACH resources collide or may collide. To address this situation, the WTRU may drop the PRACH and send the UL control channel. Alternatively/additionally, the WTRU may drop the UL control channel and send PRACH. Alternatively/additionally, the WTRU may send the PRACH in part or the UL control in part. Collision handling for these and similar cases may be based on at least one of: UL control channel (eg, is it a periodic or aperiodic UL control channel); delay requirements; service type (eg, URLLC, eMBB, mMTC, etc.) ); predefined or predetermined rules (e.g. always send UL control channel or always send PRACH and drop another channel); channel priority, where priority can be predefined or configured; preemption indication; an indication of which to drop; send both or all channels in the event of a collision; and/or any combination of the above.

The gNB can configure PRACH to avoid collision between UL control channel and PRACH. If the PRACH collides with the uplink control, the WTRU may drop the RACH or drop the UL control.

As discussed herein, conflicts can be handled using predefined rules. For example, when the PRACH and UL control channels collide, the WTRU may drop the UL control and send only PRACH, and vice versa.

In one or more cases, an indication can be used to handle the conflict. The WTRU may receive an indication of which colliding element to discard and which element to send. For example, the WTRU may be instructed to drop the PRACH and send the UL control channel, or the WTRU may be instructed to drop the UL control channel and send the PRACH.

In one or more cases, implicit indications may be used to handle conflicts. The WTRU may determine which colliding element to discard and which element to send 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 send PRACH, and vice versa.

In one or more cases, the gNB can transmit and receive simultaneously. When the gNB is transmitting SS blocks, the gNB may also receive on the same or different carrier using a specific receive (Rx) beam. Then the PRACH can be sent even though the gNB is sending SS blocks.

There may be conflicts between RACH occasions and semi-persistent scheduling and/or dynamic slot format indicator(s) (SFI). Downlink and/or uplink signals and/or channels in semi-static DL/UL assignments may not be rewritten to the other direction. DL and/or UL signals and/or channels in dynamic SFI may not be overwritten by WTRU specific control or data channels. RACH occasions that may collide with dynamic SFI may be discarded. RACH occasions that may collide with semi-static DL/UL assignments may be dropped.

The gNB and WTRU may derive valid RACH occasion(s) (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 opportunity may be an opportunity to transmit in a time increment (ie, one or more symbols of a time slot) that has been predetermined or determined not to collide.

In some cases, there may be conflicts between DL control channels and RACH resources. In these cases, the WTRU may drop the PRACH and receive the DL control channel. Additionally/alternatively, the WTRU may drop the DL control channel and send PRACH. Additionally/alternatively, the WTRU may transmit PRACH in part or receive DL control in part. Collision handling may be based on at least one of: delay requirements; service type (eg, URLLC, eMBB, mMTC, etc.); predefined or predetermined rules (eg, always receive DL control channel or always send PRACH and drop another channel) ); channel priorities, where priorities can be predefined or configured; preemption indications; indications received from the gNB as to which to send and which to drop; some or all of the channel to be sent in the event of a collision; and/or some combination of the foregoing.

The gNB can configure PRACH to avoid collision between DL control channel and PRACH. If the PRACH collides with the DL control channel, the WTRU may drop the PRACH or drop the DL control channel.

Conflicts can be handled using predefined rules. For example, when the PRACH and DL control channels collide, the WTRU may drop the DL control and send only the PRACH, and vice versa.

In one or more cases, an indication can be used to handle the conflict. The WTRU may indicate which element in the collision to discard and which element to send. For example, the WTRU may receive an indication to drop the PRACH and receive the DL control channel, or the WTRU may receive the indication to drop the DL control channel and send the PRACH.

In one or more cases, implicit indications may be used to handle conflicts. The WTRU may determine which elements to discard and which elements to send 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 send PRACH, and vice versa.

The WTRU may receive an indication of whether there is an NR-PDCCH, a configured search space, or a configured control resource set (CORESET) that may collide with RACH resources.

The gNB and WTRU may determine or derive valid RACH opportunities 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.

In one or more cases with a conflict, rules and RACH resources can be used to resolve the conflict. As described herein, RACH resources or RACH occasions may collide with the DL part or the UL part. RACH resources or RACH occasions may also collide with unknown parts that may be configured as the DL part or the UL part. The DL part may be SS blocks, DL control channels, other DL control channels, signals or transmissions, and the like. The UL portion may be a UL control channel, other UL control channels, signals or transmissions, or the like. The WTRU may receive an indication of both the semi-static UL/DL configuration and the RACH configuration at the same time. The WTRU may also receive an indication of semi-static UL/DL configuration prior to RACH configuration. If the WTRU receives an indication of a semi-static UL/DL configuration at the same time as or before the RACH configuration, and if the RACH opportunity collides with the DL part, the RACH opportunity that collides with the DL part may not be sent, but the UL may be sent RACH timing within the section. If the WTRU is instructed to use the semi-static UL/DL configuration after the RACH configuration, and the WTRU is not aware of the semi-static UL/DL configuration when the RACH opportunity is sent, the WTRU may assume that the RACH opportunity will not collide with the DL part, so the RACH opportunity may be used for transmission and is valid. If the unknown part is not configured or if the unknown part is configured as UL for RACH transmission, then RACH resources or RACH occasions may be used or sent in the unknown part (ie, part X).

To avoid possible collisions, the WTRU may check the DL/UL configuration. The WTRU may send the RACH in the UL portion. If the DL part is not used, the WTRU may send the RACH in the DL part. An indication of whether the DL portion is used may be received at the WTRU. If the DL parts are indicated as "used" (eg, for SS blocks indicated as actually sent), the WTRU may not send the RACH in those DL parts. Alternatively or additionally, the WTRU may not transmit the RACH in any DL part, whether or not the DL part is used. This alternative or a different alternative can be configured.

In one embodiment, the WTRU may decide where and/or whether to send RACH resources based on the location of the SS block or SS block transmission. For example, one or more RACH occasions (eg, some or all) may or may not be sent if the WTRU knows from the indication to send the SS block at a particular location (eg, a particular location of a slot, subframe, etc.). Additionally/alternatively, for a given increment, instead of sending the RACH before the SS block, the RACH may be sent after the SS block. There may be no RACH opportunity or RACH resource before the SS block, and the RACH opportunity or RACH resource may be after the SS block. Additionally/alternatively, if the SS block is located in or is sent in an earlier part of the slot, then the RACH opportunity/resource in the later part of the slot may be sent and the SS may not be sent RACH before the block. The RACH in the earlier part of the slot may not be sent if the SS block is located or sent in the later part of the slot.

The WTRU may not send RACHs that will or may collide with SS blocks in a slot, but the WTRU may still send RACHs that do not collide with SS blocks in a slot. Alternatively/additionally, the WTRU may not transmit all RACH opportunities in a slot if one or more RACH opportunities in the slot may collide with the SS block. The WTRU may send the RACH or use the RACH occasion based on the collision condition with the SS block. Additionally/alternatively, the WTRU may transmit or not transmit the RACH, or use or not use the RACH opportunity based on the configured, indicated, or scheduled location (eg, in time or frequency) to transmit the SS block. In one case, the RACH occasion of a specific time or frequency location can be used even when the RACH occasion of the specific time or frequency location collides with the SS block. In another case, if the RACH occasion of a particular time or frequency location collides with the SS block, the RACH occasion of that particular time or frequency location may not be used.

The indication about the semi-static UL/DL configuration may be in the New Radio Physical Broadcast Channel (NR-PBCH), Remaining Minimum System Information (RMSI), Other System Information (OSI) or paging, etc. Additionally, if the WTRU is instructed for dynamic UL/DL configuration, the dynamic UL/DL configuration may override the semi-static UL/DL configuration. The WTRU may follow the DL part and the UL part in the dynamic UL/DL if indicated at the same time as or before the RACH configuration and the dynamic UL/DL configuration covers the semi-static UL/DL configuration. configuration. The WTRU may then follow the rules for RACH occasional transmissions as described herein.

2B illustrates an example procedure 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, eg, in RMSI. At 262, the WTRU may determine ROs for different portions of the slot (ie, DL/X/DL/UL) based on the configuration information. In 264, the WTRU may receive a DL indication of actually transmitted (Txed) SS blocks. In some cases, the WTRU may also receive an indication that the SS block enables/disables coverage (which may allow/disable the WTRU to have an RO at the location where the SS block is indicated). Based on some or all or some of the information received, at 266, the WTRU may evaluate whether a given symbol is an opportunity (ie, an RO) to transmit a RACH. At 268, the WTRU may evaluate the ROs for the slot and determine if they are valid ROs for which no collisions are expected and any rules or indications are considered so that the RACH can actually be sent/scheduled. At 270, the WTRU may send the RACH in the previously determined valid RO.

2C illustrates an example of PRACH transmission without SS block collisions based on 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 as described in Figure 2B and any rules or conditions for handling conflicts as described herein. For 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. Furthermore, the RO may be valid if the occasion is after the indicated SS block instead of before. Typically, the transmission example shows only one slot that is decomposed into parts with a variable number of symbols (ie OFDM), which can be allocated to DL 213 , X 214 , DL 215 and UL 216 . Each symbol may have a corresponding specific shading corresponding to what content occupies or is indicated to occupy the resource; for example, each possible RO has a line from the upper left corner to the lower right corner, eg, RO 208. No shading may mean that the resource is not being used or that there are no plans to use the resource.

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

Diagram 220 illustrates process 266 (evaluating whether an RO is a valid transmit opportunity (ie, a VRO)), and may be similar to diagram 200, except that the SS block 229 may be indicated to the WTRU, which results in that only the UL portion 226 has valid RO because the X portion 224 that is a potential RO may not be valid because for this example, the WTRU may only have a valid RO after the indicated SS block.

Diagram 240 shows process 266, and may be similar to diagram 200, except that there may be no SS blocks indicated for DL 245, which may result in every RO following DL control section 243 being a valid RO.

In one or more embodiments, overlapping preamble subsets may be used. The SS block index can be embedded in the RA-RNTI. RA-RNTI may be a function of SS block index. Alternatively or additionally, the SS block index may be included in the random access response (RAR). Also, the SS block index of the overlapping preamble can be embedded in the RA-RNTI and included in the RAR. For example, the SS block index (e.g., for overlapping preambles) can be embedded in the RA-RNTI (e.g., use different RNTIs for different SS block indexes, or use different CRC masks for different SS block indexes), And at the same time, the same SS block index (eg, for overlapping preambles) can be included in the RAR.

3 illustrates an example overlap of preamble and synchronization signal (SS) blocks in accordance with one or more embodiments described herein. In some cases, the associations 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 overlapping preambles can be embedded in the RA-RNTI. RA-RNTI may be a function of SS block index. Alternatively or additionally, the SS block index for overlapping preambles may be included in the random access response (RAR). By doing so, collisions between WTRUs as a result of overlapping may be avoided. Also, the SS block index of the overlapping preamble can be embedded in the RA-RNTI and included in the RAR. The WTRU may obtain the SS block index obtained in RA-RNTI and the SS block index obtained in RAR. The WTRU may compare the SS block index obtained in the RAR with the SS block index obtained in the RA-RNTI and determine the final SS block index.

For the case with gNB receive/transmit (Rx/Tx) beam correspondence, preamble subsets corresponding to different SS blocks in one RACH slot can be overlapped to increase the capacity of initial access and random access.

For cases without gNB Rx/Tx correspondence, if the preamble subsets corresponding to different SS blocks in one RACH slot overlap, multiple WTRUs transmitting the same overlapping preamble using different SS blocks may collide because the gNB may TAs associated with different SS blocks cannot be properly separated.

For the case with gNB Rx/Tx correspondence and there is overlap between gNB Tx beams, if the preamble subsets corresponding to different SS blocks in one RACH slot overlap, then multiple SS blocks of the same overlapping preamble are sent using different SS blocks. The WTRUs may be separated by the gNB sending the SS block index within the RAR, which may avoid collisions between these WTRUs.

For the case with gNB Rx/Tx correspondence and no overlap between gNB Tx/Rx beams, if the preamble subsets corresponding to different SS blocks in one RACH slot overlap, then use different SS blocks to transmit the same overlapping preamble Multiple WTRUs may be geographically separated by gNB Rx/Tx beams, and the gNB may not need to send the SS block index within the RAR.

Based on the antenna configuration, beam configuration and/or beam correspondence, the gNB may configure whether to include the SS block index in the RAR or RA-RNTI.

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

At the gNB, 305Tx beam 1 may be associated with 304SS block 1 and 307Tx beam 2 may be associated with 306SS block 2.

In case 1, 305Tx beam 1 and 307Tx beam 2 may overlap, which means that the WTRU may receive two signals from 305Tx beam 1 and 307Tx beam 2. In case 2, 305Tx beam 1 and 307Tx beam 2 do not overlap, which means that the WTRU may only receive signals from Tx beam 1 or Tx beam 2, but not both. Given these Case 1 and Case 2, the following four cases can be considered: Scenario 1, Case 1 - No gNB Tx/Rx beam correspondence; Scenario 2, Case 2 - No gNB Tx/Rx beam correspondence; Scenario 3, Case 1 - with gNB Tx/Rx beam correspondence; and Scenario 4, Case 2 - with gNB Tx/Rx beam correspondence.

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

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

When the gNB has Tx/Rx beam correspondence, a timing advance (TA) may be included in the RAR of the beam used to transmit the RAR. In this case, SS block specific TA and/or beam specific TA can be used. Since the gNB may receive preambles from different Rx beams for different SS blocks, the gNB may estimate the TA for each Rx beam even if two WTRUs transmit the same preamble. In RAR1, WTRU A's TA1 may be included in RAR1 transmitted in 305Tx beam 1 associated with 304SS block 1. WTRU B's TA2 may also be included in RAR2 transmitted in 307Tx beam 2 associated with 306SS block 2.

In some cases, 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 know that it is the same preamble but sent by two different WTRUs. If they are from different Rx beams, the gNB knows that the preamble was sent from two different WTRUs in two different Rx beams and can estimate the TAs corresponding to the two WTRUs. The gNB may not know which TA is for 304SS block 1 and which is for 306SS block 2 because there is no Tx/Rx correspondence. Therefore, TA can be a function of beam correspondence.

For scenario 3 with Tx/Rx correspondence, gNB can know 304 TA of preamble 2 of SS block 1 and it can be included in RAR 1. The gNB can also know the TA of preamble 2 and it can be included in RAR 2.

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

For scenario 3, TA can be estimated correctly. WTRU A may receive RAR1 via CORESET via RA-RNTI and check whether the preamble index (preamble 2) and the SS block index (304SS block 1) are for itself. Similarly, WTRU B may receive RAR2 via CORESET via RA-RNTI and check whether the preamble index (preamble 2) and the SS block index (SS block 2) are for itself.

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

For scenario 4, WTRU A may only receive its own RAR, and WTRU B may only receive its own RAR. The gNB may not need to include the SS block index in the RAR.

The gNB may be configured to include the SS block index in the RAR or not to include the SS block index in the RAR. Furthermore, 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 not to include or embed the SS block index in any of the RAR and RA-RNTI. The configuration for including the SS block index in the RAR and/or RA-RNTI may be indicated in NR-PBCH, RMSI, OSI or paging, etc.

The WTRU may receive a BC indication from the gNB regarding the beam correspondence (BC) of the gNB. If the BC indication indicates "BC" and PRACH preamble subset overlap 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 there is no SS block index in the RAR or RA-RNTI. A flag or 1-bit indicator can be used to indicate the presence/absence of SS block index in RAR, NR-PBCH or residual minimum system information (RMSI), etc.

For the RACH configuration of scenario 3, the WTRU may select 304 SS block 1 and transmit preamble 2; the gNB may utilize Rx beam 1 to receive preamble 2 and estimate TA accordingly. Due to the beam correspondence, 304SS block 1's TA may be known. The gNB may send the RAR with RA-RNTI and RAR with Random Access Preamble ID (RAPID) for Preamble 2 corresponding to 304SS Block 1 and corresponding TA and RACH Message 3 (Msg3) grant. The WTRU can successfully receive the RAR and obtain the RACH Msg3 grant.

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

In an embodiment for three WTRUs (not shown), WTRUs A, B, and C may transmit Preamble 2 simultaneously. WTRUA and C may select SS block 1 and WTRU B may select SS block 2. The gNB can receive the preamble through Rx beams 1 and 2, and can transmit 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 send RACH Msg3 by using the same UL grant and applying TA1. WTRU B may receive RAR2 and send RACH Msg3 through application TA2. The RACH Msg3s of WTRU A and WTRU C may collide with each other, and the gNB may successfully receive only one RACH Msg3 from one of the WTRUs whose TA is correct, and may fail to decode the other RACH Msg3 (ie, the gNB may fail to receive the Two RACH Msg3).

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

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

In one or more cases, the SS block may be the actual transmitted SS block. Alternatively or additionally, the SS blocks may be candidate SS blocks, nominal SS blocks, or all SS blocks including transmitted or untransmitted SS blocks. If the WTRU is instructed to actually send the SS block, the WTRU may use the actually sent SS block to associate with the RACH opportunity or resource. If the WTRU is not indicated to actually send SS blocks, the WTRU may use candidate SS blocks, nominal SS blocks, or all SS blocks including sent or unsent SS blocks to associate with RACH opportunities or resources. If the WTRU is instructed or configured to use candidate SS blocks, nominal SS blocks, or all SS blocks associated with RACH opportunities or resources, this may cover the use of actually transmitted SS blocks, even though the WTRU may have been instructed to actually transmit SS blocks piece. For example, such coverage indication or association configuration may be in RRC signaling or NR-PBCH. The actual transmitted SS block may be indicated within RMSI or OSI.

The techniques described herein can be applied to contention-based random access or contention-free random access, and/or to both contention-based random access and contention-free random access.

FIG. 4 shows an example of preamble and SS block association. As shown, the preamble is divided 401 into multiple subsets A, B, and C of two or more types. A first type of preamble subset may be associated with one SS block. The second type of preamble subset may be associated with more than one SS block. For example, preamble subsets A and B may each be a first type of preamble subset, which may be associated with one SS block, eg, SS block 402 and SS block 404, respectively. Preamble subset C may be a second type of preamble subset, which may be associated with more than SS blocks, eg, SS blocks 402 and 404 .

In one case, SS block 402 and SS block 404 may be adjacent to each other with respect to their associated transmit beams. SS block 402 may have index m and SS block 404 may have index n. In this case, m can be n+1 or n-1.

Figure 5 illustrates an example method of RACH resource and SS block association. For illustrative purposes, RACH resources and RACH occasions may be interchangeable as appropriate. As shown, RACH resources may be divided 501 into multiple subsets A, B, and C of two or more types. A subset of RACH resources of the first type may be associated with one SS block. The second type of subset of RACH resources may be associated with more than one SS block. For example, RACH resource subsets A and B may each be a first type of preamble subset, which may be associated with one SS block, eg, SS block 502 and SS block 504, respectively. RACH resource subset C may be a second type of preamble subset, which may be associated with more than one SS block, eg, SS block 503 and SS block 504.

In one case, SS block 502 and SS block 504 may be adjacent to each other with respect to their associated transmit beams. SS block 402 may have index m and SS block 404 may have index n. In this case, m can be n+1 or n-1.

Figure 6 shows an example process of SS block association and mapping to RACH. The WTRU may perform one or more of the disclosed phases. At 602, the actual transmitted SS block (SS block) may be indicated to the WTRU. At 604, the actually transmitted SS blocks may be divided into SS block groups. At 606, the SS block or group of SS blocks is mapped to RO or RACH resources. At 608, if there is more than one SS block per RO or RACH resource, the SS block may be mapped to a preamble for each RO or RACH resource in 612, after which there may be preamble type-based or non-preamble-based Type of preamble subset partitioning and mapping 614. If there is not more than one SS block per RO or RACH resource according to 608, the process may stop at 610.

7 is a diagram illustrating another example method of SS block association and mapping to RACH. The WTRU may perform one or more phases of this example. At 702, the number of SS blocks actually sent 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 the slot (TDMRO) 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 secondary mapping that maps the SS block to the frequency domain RO (FDM RO). At 718, there may be a temporal re-mapping that maps the SS block to the time domain RO (TDM RO). At 717, there may be the same slot-first mapping that maps the SS block to the time domain RO within the slot. At 719, there may be a cross-slot secondary mapping that maps the SS block to the time-domain RO across the time-slots. If same-slot mapping is sufficient, then cross-slot mapping may not be required. If same-slot mapping is not sufficient (eg, many SSBs need to be mapped to ROs), cross-slot mapping can be performed. At 720, if the mapping cycle is complete for all ROs, proceed to 724 and stop. Also at 720, if the RO's mapping cycle is not complete, then at 722 the remaining ROs are discarded.

In one or more embodiments, there may be beam scanning based on PRACH resource packets. The number of OFDM symbols in the PRACH preamble format or the number of repetitions of the PRACH preamble format may be less than the number of gNB Rx beams. The gNB may scan the Rx beam for PRACH using multiple RACH occasions. The plurality of RACH occasions may include one or more RACH resources (eg, one or more slots, non-slots, mini-slots, or OFDM symbols). The multiple RACH occasions may or may not be consecutive. Multiple RACH occasions may be configured to a WTRU. In one case, the WTRU may assume that there may be multiple RACH occasions as a packet. The WTRU may start PRACH preamble transmission using the first RACH opportunity, the second RACH opportunity, the third RACH opportunity, etc. until all beams have been scanned. Depending on the number of actually transmitted SS blocks or the number of beams at the gNB, multiple RACH opportunities (as packets) with K OFDM symbols may be configured to the WTRU for the actual transmitted K SS blocks or at the gNB beam. To further support WTRUTx beam scanning in addition to gNB Rx beam scanning, if the WTRU has M Tx beams, multiple RACH occasions (as a packet) with K by M OFDM symbols may be configured to 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. The preamble format C can be C0 and C1. The number of SS blocks can be marked as L. The number of gNB Rx beams can be denoted as N _rx . The number of repetitions of the configured preamble format can be marked as N _rp .

个类型的RACH时机。所有gNB Rx波束可以通过“RACH时机包”扫描。这可以针对每个SS块或针对所有SS块进行配置。不同类型的RACH时机可以对应于不同的N_rp个gNB Rx波束。

个类型RACH时机可以被定义为“RACH时机包”。If there is no beam correspondence, to ensure that the gNB can scan all Rx beams to receive multiple RACH trials from the WTRU, the gNB may configure the ceiling

types of RACH occasions. All gNB Rx beams can be scanned by "RACH opportunity packet". This can be configured per SS block or for all SS blocks. Different types of RACH occasions may correspond to different Nrp _gNB Rx beams.

This type of RACH opportunity may be defined as a "RACH opportunity package".

For RACH Msg1 retransmissions, the WTRU may pick up a different RACH occasion type that has not been used in previous RACH Msg1 (re)transmissions in order to complete the gNB Rx beam scan.

For RACH Msg1 retransmissions, it may be configured or determined by the WTRU to decide whether to change the WTRU UL Tx beam, ramp up power, or change the type of RACH occasion.

8 illustrates example configurations of window lengths for each random access channel (RACH) opportunity type, where the window lengths of RACH opportunities (eg, 806 and 808) may be the same as the RACH configuration period (eg, 804). The length of each RACH occasion type can be configured so that the window lengths of all RACH occasion types are the same. For example, the window length 806 may be the same as the RACH configuration period 804. Alternatively or additionally, the window length for all RACH occasion types may be N times the RACH configuration period (not shown), where N may be configured in the remaining minimum system information (RMSI). In one example, N may be an integer greater than one.

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

FIG. 10 shows an example configuration of the window length for each random access channel (RACH) occasion type, where the window length of the RACH opportunity is less than the RACH configuration period. As shown, the window length 1006 for each RACH occasion type may be less than the RACH configuration period 1004. All RACH occasion types can be within the RACH configuration period. In some embodiments, the window lengths may be different for different RACH occasion types. Predefined window length modes can be used. A WTRU may be configured with one of the modes in RMSI.

对于具有波束对应关系的gNB，Y＝1。对于具有部分波束对应的gNB，

其中

是与对应于SS块的gNB Tx波束重叠的gNB Rx波束的数量。例如，N_rx＝4；N_rp＝2；L＝4。每个SS块可能有两种类型的RACH时机。类型1RACH时机可以由gNB Rx波束0和1接收。类型2RACH时机可以由gNBRx波束2和3接收。The number Q of RACH occasion types may be indicated to the WTRU in the NR-PBCH or RMSI. Depending on the beam correspondence, Q may have different values. For example, for gNBs without beam correspondence,

For gNBs with beam correspondence, Y=1. For gNBs with partial beam correspondence,

in

is the number of gNB Rx beams that overlap the gNB Tx beams corresponding to the SS block. For example, N _rx =4; N _rp =2; L=4. There may be two types of RACH occasions per SS block. Type 1 RACH occasions may be received by gNB Rx beams 0 and 1. Type 2 RACH occasions may be received by gNBRx beams 2 and 3.

In one embodiment, N _rx may be set to 64, N _rp may be set to 12, and L may be set to 64 (ie, N _rx =64; N _rp =12; L=64). There may be 6 types of RACH occasions per SS block. Each type of RACH occasion may be received by 12 gNB Rx beams, and the subset of gNB Rx beams may be different for different types of RACH occasions.

In another embodiment, N _rx may be set to 2 and N _rp may be set to 2 (ie, N _rx =2; N _rp =2). There may be only one type of RACH opportunity in this embodiment.

Figure 11 shows an example redundancy version of the preamble based on SS beam reporting. The WTRU 1106 may perform listen before talk (LBT) and transmit the RACH preamble. gNB 1101 may perform LBT and transmit RAR. If gNB 1101 fails LBT in 1104 beam 1, it may not transmit RAR in 1104 beam 1. If the WTRU 1106 reports only one beam (eg, 1104 beam 1), the WTRU 1106 may not be able to receive the RAR due to the LBT failure of the gNB 1101.

In one embodiment, the WTRU 1106 may report on more than one beam (especially in overlapping regions of the beams), eg, 1104 beam 1 and 1105 beam 2. The WTRU 1106 may report SS blocks for the strongest beam as well as SS blocks for other beams. The WTRU 1106 may perform LBT and transmit the RACH preamble, which may be associated with SS block #1 (eg, 1104 beam 1) and SS block #2 (eg, 1106 beam 2). gNB 1101 may perform LBT on more than one beam (eg, 1104 beam 1 and 1106 beam 2) and may transmit RAR accordingly. If gNB 1101 fails LBT in 1104 beam 1, it can transmit RAR in other beams (eg, 1106 beam 2). On the other hand, if gNB 1101 fails LBT in 1106 beam 2, it can transmit RAR in other beams (eg, 1104 beam 1). Unless gNB 1101 fails LBT in two or all beams, gNB 1101 may need to continue performing LBT until the channel is clear before sending the RAR. This can cause severe delays and high latency. By reporting more than one SS block from the WTRU 1106, the gNB 1101 may be able to send the RAR without delay. The association of preamble and SS block can be one preamble to multiple 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.

However, when more than one WTRU is in the same beam overlap region, multiple WTRUs may report the same preamble (not shown) causing a collision. In NR or unlicensed NR, WTRUs in the same overlapping beam area may report the same preamble, which may result in a preamble collision if the WTRU selects the same RACH occasion.

In one embodiment, redundancy version based SS block reporting may be used and the gNB may be able to send the RAR without delay. The association of the preamble and the SS block may be based on the redundancy of the preamble.

In one embodiment, a redundant version of the preamble association may be used, where the association of the preamble and the SS block may be one preamble to multiple SS blocks, and the redundancy with respect to the same association of the preamble and the SS block may be used Version. For example, where preamble #1 is associated with SS blocks #1 and #2, preamble #2 may be a redundant version of preamble #1 and may also be associated with the same SS block (eg, SS Blocks #1 and #2). This may eliminate or reduce WTRU collisions since WTRUs in the same overlapping beam area may not report the same preamble.

In one case, the WTRU may use the preamble or RACH Msg3 to report more than one SS block. In the case of using preamble-based SS block reporting, one preamble can be mapped to multiple SS blocks (eg, preamble #1 is mapped to SS block #1 and SS block #2). To further reduce collisions, the same mapping can 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 one of: preamble #2, which may be mapped to the same SS block (eg, SS block #1 and SS block #2); or preamble #2 Sync code #3, which can be mapped to the same SS block (eg, SS block #1 and SS block #2). The gNB can perform directional LBT and send RAR. If LBT fails in SS block 1, the gNB can flexibly send RAR in SS block 2.

In case of using RACH Msg3 based SS block reporting, RACH Msg3 may include redundant versions for mapping in its payload as follows: 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.

Preamble-based redundancy version SS block reporting can be applied to initial access and channel access, including random access, beam management and/or control of data, mobility, and/or other use cases and scenarios. Preamble-based redundancy version SS block reporting can be applied to NR licensed or unlicensed bands and standalone or non-standalone systems.

Although features and components of the invention are described in specific combinations in preferred embodiments, each feature or component may be used alone or in combination with other features of the invention without the other features and components of the preferred embodiments Used in various combinations with components, or used without other features and components of the invention.

While the embodiments described herein contemplate LTE, LTE-A, New Radio (NR) or 5G specific protocols, it should be understood that the embodiments described herein are not limited to these scenarios and may be applicable to other wireless system.

Although features and components are described above in particular combinations, it will be understood by those skilled in the art that each feature or component may be used alone or in any combination with other features and components. Also the methods described herein can be implemented in a computer program, software or firmware introduced into a computer readable medium for execution by a computer and/or processor. Examples of computer-readable media include electrical 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, buffer memory, semiconductor storage devices, magnetic media (eg, internal hard disks and removable disks), Magneto-optical media, and optical media such as CD-ROM discs and digital versatile discs (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use at a WTRU, UE, terminal, base station, RNC, or any computer host.

Claims (10)

1. A method performed by a Wireless Transmit Receive Unit (WTRU), the method comprising:

receiving an indication of semi-static U L/D L information including Random Access Channel (RACH) occasion configuration;

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 are valid, wherein the RACH occasion is valid based on: whether the RACH occasion is behind all of the indicated actually transmitted SS blocks or whether the RACH occasion is located at the location of an actually transmitted SS block but the SS block has been indicated as disabled; and

transmitting a physical RACH in one or more of the RACH occasions that have been determined to be valid.

2. The method of claim 1, wherein the indication of semi-static U L/D L information is received in Remaining Minimum System Information (RMSI) via a Physical Broadcast Channel (PBCH).

3. The method of claim 1, wherein the indication of the actually transmitted SS blocks is in part D L.

4. The method of claim 1, further comprising: a dynamic indication is received as to whether SS block coverage is enabled or disabled.

5. The method of claim 4, wherein the RACH occasion validation is further based on the dynamic indication of whether SS blocks are disabled.

6. A Wireless Transmit Receive Unit (WTRU), comprising:

a processor operably coupled to the transceiver, the processor and the transceiver configured to receive an indication of semi-static U L/D L information including Random Access Channel (RACH) occasion configuration, receive an indication of one or more actual transmitted Synchronization Signal (SS) blocks, and receive an indication of the one or more actual SS blocks, and

the processor and transceiver are further configured to determine whether any of the RACH occasions are valid, wherein the RACH occasion is valid based on: whether the RACH occasion is behind all of the indicated actually transmitted SS blocks or whether the RACH occasion is located at the location of an actually transmitted SS block but the SS block has been indicated as disabled; and transmitting a physical RACH in one or more of the RACH occasions that have been determined to be valid.

7. The WTRU of claim 6, wherein the indication of semi-static U L/D L information is received in Remaining Minimum System Information (RMSI) via a Physical Broadcast Channel (PBCH).

8. The WTRU of claim 6 wherein the indication of the actually sent SS blocks is in part D L.

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

10. The WTRU of claim 9, wherein the RACH occasion validity is further based on the dynamic indication of whether SS blocks are disabled.

Images