Adaptive waveform selection for wireless communications

Abstract

Systems, methods, and tools for adaptive waveform selection for wireless communications are described herein. In an example, a wireless transmit / receive unit (WTRU) may be initially configured with Orthogonal Frequency Division Multiplexing (OFDM). If the WTRU that can support dynamic waveform handover receives a system information block (SIB) from a plurality of cells, where at least one of the plurality of cells supports dynamic waveform handover, the WTRU can prioritize initial access with the cell that can support dynamic waveform handover. If the WTRU supports dynamic waveform switching, the WTRU may transmit a Physical Uplink Shared Channel (RUSCH) in msg3 under a configured grant that may be offset from a waveform different from a pre-configured waveform type by a pre-configured number of slots.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of Provisional U.S. Patent Application No. 63 / 327,640 filed on April 5, 2022, Provisional U.S. Patent Application No. 63 / 395,395 filed on August 5, 2022, and Provisional U.S. Patent Application No. 63 / 421,863 filed on November 2, 2022, the disclosures of which are incorporated herein by reference in their entirety. Background Art

[0003] Mobile communications using wireless communications continue to evolve. The fifth generation of mobile communications radio access technology (RAT) may be referred to as 5G New Radio (NR). Previous generation (legacy) mobile communications RAT may be, for example, fourth generation (4G) Long Term Evolution (LTE). Summary of the invention

[0004] Systems, methods, and tools for adaptive waveform selection for wireless communications are described herein.

[0005] The WTRU may receive a first message from one or more cells (e.g., from a first cell). The first message may indicate whether a cell (e.g., a neighboring cell) supports dynamic waveform switching (e.g., may indicate whether a second cell in the neighboring cells supports dynamic waveform switching). The first message may be received via a radio resource control (RRC) transmission or a system information block (SIB) transmission.

[0006] The WTRU may select the cell (e.g., the second cell) based on the cell supporting dynamic waveform switching. The WTRU may select the cell (e.g., the second cell) based on (e.g., additionally based on) a measurement result (e.g., reference signal received power (RSRP)) of the cell (e.g., the second cell) being below a threshold. The WTRU may be configured to send a preamble to the cell indicated by the first message (e.g., to the second cell). The preamble transmission may indicate the WTRU's ability to support dynamic waveform switching. In an example, the preamble transmission may indicate the WTRU's ability to support dynamic waveform switching via one of: a resource for the preamble transmission, a preamble sequence, or a transmission timing for the preamble transmission.

[0007] The WTRU may be configured to prioritize one cell (e.g., the second cell) among the cells (e.g., neighboring cells) indicated by the first message over another cell (e.g., the third cell). The WTRU may prioritize a cell (e.g., the second cell) that supports dynamic waveform switching over another cell (e.g., the third cell) that does not support dynamic waveform switching (e.g., if respective measurements of each of the second cell and the third cell are below a threshold).

[0008] The WTRU may receive a second message. The second message may be received from the second cell. The second message may indicate a waveform type (e.g., a second waveform type) used to send a third message. The WTRU may send the third message to the second cell (e.g., via a physical uplink shared channel (PUSCH)) using the indicated second waveform type. The second waveform type may be a direct Fourier transform spread orthogonal frequency division multiplexing (DFT-s-OFDM) waveform type. The second waveform type (e.g., a DFT-s-OFDM waveform type) used to send the third message may be switched from a first waveform type (e.g., a cyclic prefix orthogonal frequency division multiplexing (CP-OFDM) waveform type) used to receive the first message and used (e.g., additionally used) to communicate with the first cell prior to receiving the first message. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0010] Figure 1B is a diagram showing that according to the embodiment Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within the illustrated communication system.

[0011] Figure 1C is a diagram showing that according to the embodiment Figure 1A System diagram of an example Radio Access Network (RAN) and an example Core Network (CN) for use within the illustrated communication system.

[0012] Figure 1D is a diagram showing that according to the embodiment Figure 1A System diagram of yet another example RAN and yet another example CN for use within the illustrated communication system.

[0013] Figure 2 An example of scheduled PDCCH reception and corresponding PUSCH by a WTRU is shown.

[0014] Figure 3 An example of reception and WTRU behavior of a waveform change indication is shown.

[0015] Figure 4 An example PUSCH transmission after waveform switching is shown.

[0016] Figure 5 An example of reception and WTRU behavior of a waveform change indication is shown.

[0017] Figure 6 An example of WTRU behavior is shown in the case where scheduled repetitions overlap with the switching window.

[0018] Figure 7 An example of WTRU behavior is shown in the case where scheduled repetitions overlap with the switching window and repetitions are cancelled.

[0019] Figure 8 An example of WTRU behavior in the case of a repeated mid-switching waveform of PUSCH is shown.

[0020] Fig. 9 An example of WTRU behavior in the case of repeated mid-switching waveform and cancellation of transmissions of PUSCH is shown.

[0021] Figure 10 to Figure 11 An example of waveform switching and joint channel estimation is shown.

[0022] Fig.12 An example of receiving a waveform change indication prior to time window configuration for joint channel estimation is shown.

[0023] Fig.13 An example of receiving a waveform change indication after time window configuration for joint channel estimation is shown.

[0024] Fig.14 An example of a 4-step initial access random access channel (RACH) procedure is shown.

[0025] Fig.15 An example of a 2-step initial access RACH procedure is shown.

[0026] Figure 16 to Figure 17 An example of association between RACH timing (RO) and waveform is shown.

[0027] Fig.18 Shows an example of dynamic waveform switching. DETAILED DESCRIPTION

[0028] Figure 1A 1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero 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.

[0029] like Figure 1A As shown, the 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 other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to send and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

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

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

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

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

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

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

[0036] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may together implement LTE radio access and NR radio access, for example using the dual connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to / from multiple types of base stations (e.g., eNBs and gNBs).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0051] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via hardware (e.g., a choke) or via signal processing performed by a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for uplink (UL) (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

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

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

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

[0055] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is depicted as being part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

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

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

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

[0062] 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 have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic away from the BSS. Traffic originating from outside the BSS and leading to the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and leading to a destination outside the BSS may be transmitted to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit traffic to the AP, and the AP may deliver traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between the source STA and the destination STA (e.g., directly between them) using direct link establishment (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (eg, all STAs in the STA) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

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

[0064] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0065] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and data can be sent by the transmitter STA. At the receiver of the receiver STA, the above-mentioned operation for the 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

[0066] 802.11af and 802.11ah support operating modes below 1 GHz. Relative to the channel operating bandwidth and carrier used in 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 the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument type control / machine type communication, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

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

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

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

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

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

[0072] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while not accessing other RANs (e.g., such as the 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 anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRU 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the evolved Node-B 160a, 160b, 160c. For example, the WTRU 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more evolved Node-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the evolved Node-B 160a, 160b, 160c may act as a mobility anchor for the WTRU 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRU 102a, 102b, 102c.

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

[0074] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0075] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized 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 mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0076] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

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

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

[0079] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more simulation devices (not shown): WTRU102a-d, base station 114a-b, evolved Node B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b and / or any other device described herein. The simulation device may be one or more devices configured to mimic one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0081] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas) can be used by the simulation device to send and / or receive data.

[0082] References to timers herein may refer to a determination of a time or a determination of a time period. References to expiration of a timer herein may refer to a determination that a time has occurred or a time period has expired. References to timers herein may refer to a time, a time period, tracking a time, tracking a time period, etc. References to legacy technology or legacy handover may refer to a legacy technology such as LTE compared to NR, or a legacy version of a technology, for example, an older version / release of a technology (e.g., an older NR release) compared to a newer version / release of the technology (e.g., a newer NR release).

[0083] Systems, methods, and tools for adaptive waveform selection for wireless communications are described herein.

[0084] The WTRU may receive a first message from one or more cells (e.g., from a first cell). The first message may indicate whether a cell (e.g., a neighboring cell) supports dynamic waveform switching (e.g., may indicate whether a second cell in the neighboring cells supports dynamic waveform switching). The first message may be received via a radio resource control (RRC) transmission or a system information block (SIB) transmission.

[0085] The WTRU may select a cell (e.g., a second cell) based on the cell supporting dynamic waveform switching. The WTRU may select the cell (e.g., the second cell) based on (e.g., additionally based on) a measurement result (e.g., a reference signal received power (RSRP)) of the cell (e.g., the second cell) being below a threshold. The WTRU may be configured to send a preamble to the cell indicated by the first message (e.g., to the second cell). The preamble transmission may indicate the WTRU's ability to support dynamic waveform switching. In an example, the preamble transmission may indicate the WTRU's ability to support dynamic waveform switching via one of: resources for preamble transmission, preamble sequence, or transmission timing for preamble transmission.

[0086] The WTRU may be configured to prioritize one cell (e.g., the second cell) among the cells (e.g., neighboring cells) indicated by the first message over another cell (e.g., the third cell). The WTRU may prioritize a cell (e.g., the second cell) that supports dynamic waveform switching over another cell (e.g., the third cell) that does not support dynamic waveform switching (e.g., if the respective measurement results of each of the second cell and the third cell are below a threshold). In an example, prioritizing the second cell that supports dynamic waveform switching may enable switching to a DFT-s-OFDM waveform (e.g., which may provide increased throughput).

[0087] The WTRU may receive a second message. The second message may be received from a second cell. The second message may indicate a waveform type (e.g., a second waveform type) used to send a third message. The WTRU may send the third message to the second cell (e.g., via a physical uplink shared channel (PUSCH)) using the indicated second waveform type. The second waveform type may be a direct Fourier transform spread orthogonal frequency division multiplexing (DFT-s-OFDM) waveform type. The second waveform type (e.g., the DFT-s-OFDM waveform type) used to send the third message may be switched from a first waveform type (e.g., a cyclic prefix orthogonal frequency division multiplexing (CP-OFDM) waveform type) used to receive the first message and used (e.g., additionally used) to communicate with the first cell prior to receiving the first message.

[0088] In an example, a waveform for uplink transmission may be semi-statically configured. The waveform that the WTRU may use for uplink transmission may be broadcast by the network (e.g., gNB) (e.g., during initial access). In an example, the WTRU may use DFT-s-OFDM or OFDM for uplink transmission. In the examples herein, the OFDM waveform type may be a CP-OFDM waveform type. While OFDM may be compatible with single-input single-output (SISO) or multiple-input multiple-output (MIMO) transmissions, DFT-s-OFDM may (e.g., may only) be compatible with SISO transmissions (e.g., in NR). In terms of PAPR performance, due to the DFT spreading prior to OFDM modulation, DFT-s-OFDM may exhibit lower PAPR than OFDM, which may be suitable for coverage-limited scenarios where high transmit power may be required for uplink transmissions. There may be a tradeoff between OFDM and DFT-s-OFDM (e.g., a tradeoff between throughput and coverage performance).

[0089] For UL transmissions, the UL transmit power may be limited, making the optimal choice of waveform important for maximizing coverage or throughput. In an example, for a WTRU located near a gNB, OFDM with MIMO may be configured. For a WTRU located far from a gNB, DFT-s-OFDM with SISO may be configured. In an example, the WTRU may be signaled to switch waveforms. In an example (e.g., in a coverage limited scenario), signaling from the network to switch waveforms may introduce signaling overhead (e.g., particularly when the WTRU moves back and forth frequently). In an example (e.g., additionally, during initial access), signaling from the network to switch waveforms may not be available at the gNB without establishing an initial connection with the WTRU. Timely signaling may be required to enable communication (e.g., seamless communication).

[0090] Transmission using a DFT-s-OFDM waveform may be equivalent to transmission with transform precoding enabled. Transmission using an OFDM or CP-OFDM waveform may be equivalent to transmission with transform precoding disabled.

[0091] An example of sending multiple PHRs to assist in switching waveforms may be provided herein. In an example, the WTRU may be preconfigured with a first waveform type (e.g., OFDM, DFT-s-OFDM). The WTRU may be preconfigured with one or more conditions that may trigger the WTRU to transmit more than one power headroom report (PHR) (e.g., two) to the network (e.g., gNB). The second waveform type (e.g., OFDM, DFT-s-OFDM) may be a waveform that is different from or the same as the first waveform. In an example, the WTRU may be configured with an OFDM waveform type as the first waveform type via RRC. If a condition is met (e.g., a change in RSRP in the CSI-RS is above a threshold), the WTRU may return multiple PHRs (e.g., two PHRs, one PHR for OFDM and another PHR for DFT-s-OFDM).

[0092] The WTRU may be preconfigured with more than two waveform types (e.g., waveform types other than DFT-s-OFDM and OFDM). The WTRU may be configured with at least a waveform type other than OFDM and DFT-s-OFDM (e.g., a single carrier waveform type), frequency shift keying (FSK), a combination of DFT-s-OFDM and OFDM, or a variant of DFT-s-OFDM or OFDM. An ID of a waveform type (e.g., for each waveform type) may be provided to the WTRU. The association between the ID and the waveform may be provided by the network in the RRC, MAC-CE, or DCI. The WTRU may determine which waveform type to use for UL transmission based on the ID indicated in the MAC-CE or DCI. If the WTRU is preconfigured with more than two waveform types, the WTRU may receive the configuration of at least a default waveform semi-statically (e.g., RRC) through broadcast (e.g., SIB) or dedicated signaling.

[0093] The PHR calculation for the second (e.g., unconfigured) waveform may be based on the resources allocated for the first waveform (e.g., the number of symbols / time slots / frames / RBs). The WTRU may be preconfigured with multiple waveform types (e.g., two waveform types, which may be a DFT-s-OFDM waveform type and an OFDM waveform type, such as the DFT-s-OFDM waveform type and the CP-OFDM waveform type as described herein). The WTRU may be configured to use OFDM (e.g., the CP-OFDM waveform type) for the UL first. If a trigger condition for transmitting a PHR for the waveform type (e.g., both waveform types) is met (e.g., the measurement result (e.g., RSRP) of the CSI-RS is below a preconfigured threshold), the WTRU may determine to calculate the PHR for the DFT-s-OFDM based on the resources allocated for the OFDM waveform type (e.g., the CP-OFDM waveform type). The WTRU may calculate the PHR for the OFDM waveform type (e.g., the CP-OFDM waveform type). The WTRU may transmit (e.g., subsequently transmit) the PHRs (e.g., both PHRs) to the network.

[0094] PUCCH and PUSCH may be used interchangeably herein. Waveform and waveform type may be used interchangeably herein.

[0095] The PHR may deliver the power headroom and the true Pcmax that may be calibrated in the WTRU for the defined UL grant.A flag / indicator (eg, other flags / indicators) may (eg, may also) be present for the P-MPR to signal a SAR or MPE situation.

[0096] The PHR may have an important impact on the base station (BS) scheduler. The BS scheduler may have knowledge (e.g., initial knowledge) of the maximum power reduction (MPR) and the A-MPR table. The values ​​in the table may represent the maximum power reduction allowed by the WTRU. Since the WTRU may have different implementations, the calibrated values ​​may be better than the listed power reduction. Since the PHR and Pcmax,c may represent real values ​​from the WTRU, the BS scheduler may learn the WTRU's capabilities in terms of power reduction and thus converge to an optimized scheduling process. Depending on the frequency range (FR1 or FR2) and the modulation, the MPR difference between the considered waveform types (e.g., CP-OFDM and DFT-s-OFDM) may be about 2dB or even higher.

[0097] The PHR calculation may be referred to as true (e.g., true PHR) when it is based on a UL grant. The UL grant may include RB allocation and modulation and coding scheme (MCS). Based on the RB allocation and modulation, the WTRU may determine the Pcmax,c of the component carrier (CC), which is the maximum configured power that the WTRU can use under the current UL grant conditions. The power allocated in the physical layer may be required to be less than or equal to the determined Pcmax,c. If the power allocated in the physical layer exceeds the determined Pcmax,c, the WTRU may be required to reduce its allocated power (e.g., the initially allocated power) until the Pcmax,c limit is reached. The Pcmax,c in the CC may take into account MPR requirements, A-MPR (additional MPR that may be related to geographic protection of the band or other wireless services), and other insertion losses due to the RF front-end architecture. The power reduction may be related to SAR or maximum permissible exposure (MPE) limits in the form of P-MPR. This reduction may be triggered by the WTRU sensor detecting body proximity. P-MPR may affect waveforms (eg, both waveforms) equally (eg, in the examples provided herein).

[0098] Pcmax,c may be the maximum configured power of the CC. Pcmax,c may be a function of MPR, A-MPR, PpowerClass, Pemax (WTRU maximum power for the cell, signaled by SIB), P-MPR, and other insertion losses ΔTc, ΔTib of the RF front end. P-MPR may be a power management reduction. This P-MPR may be applied when the WTRU sensor detects body proximity for SAR (FR1) and MPE (FR2). If applied, the P-MPR may be signaled by a flag in the PHR. The spectral absorption rate (SAR) may be a consistent limit on electromagnetic radiation per volume of human tissue (e.g., specific to FR1). MPE may be a consistent limit on electromagnetic radiation per body surface area (e.g., specific to FR2).

[0099] In the case of carrier aggregation, MPR, A-MPR, P-MPR can be intra-band contiguous or inter-band. For intra-band contiguous, the MPR can be common for the entire bandwidth. For inter-band, the MPR can be per band / CC (because CCs are in different bands). In the case of dual connectivity, MPR, A-MPR, P-MPR can be applied per CG or per band.

[0100] Examples of conditions for a WTRU to send multiple PHRs may be provided. In an example, a WTRU may be preconfigured with conditions that trigger the WTRU to transmit more than one PHR (e.g., a double PHR, a PHR for each waveform, two PHRs for a first waveform and a second waveform) to the network if at least one of the following conditions is met: The change in RSRP compared to the last opportunity of the RS (e.g., CSI-RS, DM-RS) or SSB is above a preconfigured threshold for a specific amount of time measured in time units or time slots / frames; the RSRP of the DL-RS or SSB is below or above a preconfigured threshold; the MPE is above a preconfigured threshold; the amount of data in the BSR is above or below a preconfigured threshold and the conditions for double PHR are met; the WTRU receives an indication from the network to report more than one PHR or one PHR for a specific waveform PHR-O or PHR-D; the PHR of the current waveform is below XdB (e.g., X can be a configurable threshold such as 0dB, 2dB, 3dB or 4dB); or the calculated PHR difference between the current waveform and another waveform of at least one serving cell is above or becomes above XdB, where X can be a network configurable value or a fixed value.

[0101] For conditions where the change in RSRP is above a preconfigured threshold for a certain amount of time measured in time units or time slots / frames compared to the last time the WTRU measured DL RS (e.g., CSI-RS, DM-RS) or SSB, a prohibit timer may be configured by the network to avoid flooding the network with multiple reports.

[0102] For the condition that the RSRP of the DL-RS or SSB is below or above a preconfigured threshold, the WTRU may determine to transmit a PHR for a preconfigured waveform (e.g., each preconfigured waveform) if the RSRP of the CSI-RS is below the preconfigured threshold. This condition may be required to persist for a certain amount of time measured in time units or slots / frames to trigger a PHR. The inhibit timer may be configurable by the network to avoid flooding the network with multiple reports.

[0103] Examples associated with thresholds (e.g., preconfigured thresholds) described herein are provided. The thresholds herein may be signaled by the MAC, configured by the RRC, or indicated in the DCI. The thresholds or conditions described herein may be broadcast or transmitted by the network via dedicated signaling (e.g., in a SIB). Based on the broadcasted information or dedicated signaling, the WTRU may determine a PHR for a preconfigured waveform or a waveform configured in broadcast information (e.g., via a SIB) transmitted via dedicated signaling in msg3, msg5, and / or msgA during initial access.

[0104] An example of a WTRU transmitting a PHR to the network may be provided. If a condition (e.g., one of the above conditions) is met, the WTRU may determine to send the PHR to the network. The WTRU may include the PHR in a scheduled PUSCH or PUCCH. If the size of the PHR exceeds the limit of the PUSCH or PUCCH, the WTRU may determine to include (e.g., in both) the PUCCH and the PUSCH.

[0105] If the calculated double PHR conditions configured by the network are met, the double PHR may take the form of a physical layer flag / indication. In an example, if the double PHR calculation shows a power limited situation and the delta PHR between waveforms is higher than XdB under the current UL grant, if the calculated double PHR conditions configured by the network are met, the double PHR may take the form of a physical layer flag / indication. The indication may be transmitted by UCI in PUSCH or PUCCH.

[0106] Examples of enhanced PHR formats for multiple waveforms may be provided herein. If dynamic waveform switching is configured for at least one serving cell, the WTRU may be configured to send a PHR report according to a new format (e.g., MAC CE). The report may include an indication of whether PHR information about at least one waveform type is included for a serving cell (e.g., for each serving cell or for all serving cells). The PHR information of the waveform type may be expressed as a difference relative to a reference waveform type. The reference waveform type may be a waveform type of a PUSCH (or SRS) used for an actual PHR or a waveform type configured for a reference format for a virtual PHR. If the WTRU prepares a PHR, then under the condition that the difference is above a threshold (e.g., only under this condition), the WTRU may include PHR information of a waveform type that is different from the reference waveform type of the serving cell. The threshold may be predefined or configured by a higher layer.

[0107] Examples of correspondence between PHRs and MCS / waveforms are provided herein. A WTRU may be preconfigured to transmit more than one PHR, where the PHRs (e.g., each PHR) may correspond to a different waveform type. In an example, multiple PHRs may correspond to different MCSs of the same waveform type. In an example, a WTRU may be preconfigured to transmit more than one PHR, where the PHRs (e.g., each PHR) may correspond to different MCSs (e.g., QPSK, 16QAM) of the same waveform (e.g., OFDM, DFT-s-OFDM).

[0108] In an example, the WTRU may be preconfigured to transmit a PHR for a preconfigured waveform (e.g., each preconfigured waveform) if a condition (e.g., one of the aforementioned conditions) is met. The WTRU may be instructed by the network to transmit a PHR for the indicated waveform if a condition (e.g., one of the aforementioned conditions) is met. In an example, the WTRU may be preconfigured to transmit a PHR for DFT-s-OFDM if the condition is met. The WTRU may determine to transmit a PHR for DFT-s-OFDM if the RSPR of the CSI-RS is below a preconfigured threshold.

[0109] A dual PHR may be calculated for the PHR of the current waveform type, and a delta (difference) for the second waveform type under the same UL grant is added. The delta value may be a quantized value in the form of a lookup table (LUT) or simply a flag / indicator, which indicates that a different waveform type (e.g., a waveform type not currently in use) has a PHR that is better than a certain value (e.g., better than 2 dB).

[0110] If triggered, the PHR triggered for waveform switching may be presented in a different format. For example, when a dual PHR is triggered, a specific marker for the dual PHR may be transmitted and (e.g., and then) only the waveform-related PHR may be transmitted. The WTRU may use the current mapping to transmit the real PHR (e.g., the real alternative PHR).

[0111] Examples of PHRs that use assumptions to allocate or spectrum shape within a carrier are provided herein. Under certain assumptions about the PUSCH allocation in the frequency domain, the WTRU may report a PH that is applicable to a specific waveform. Such a PH may be included in the PHR (e.g., in addition to the PH calculated using another solution or calculated according to tradition). For example, the WTRU may apply at least one of the following assumptions even if not met by the actual PUSCH transmission used to calculate the PH: the absolute difference between the highest frequency of the carrier and the highest frequency of the PUSCH allocation is lower (or higher) than X resource blocks (RBs); the absolute difference between the lowest frequency of the carrier and the lowest frequency of the PUSCH allocation is lower (or higher) than Y resource blocks (RBs); the PUSCH allocation is an edge allocation, an outer allocation, or an inner allocation; the number of RBs allocated by the PUSCH is lower or higher than a threshold Z; or the PUSCH allocation is contiguous (e.g., may have the same total number of RBs as the allocation of the actual PUSCH transmission).

[0112] The at least one assumption and applicable values ​​for X, Y, and Z may be predefined or signaled by RRC or MAC (eg, as indicated above).Such thresholds may be predefined or signaled by RRC or MAC.

[0113] The WTRU may report an upper and / or lower limit on the frequency allocation for the PUSCH such that the difference in PH or Pcmax between the two waveform types is below a threshold. The threshold and waveform type may be predefined or signaled by the RRC or MAC. The WTRU may perform the reporting if requested from the network (e.g., such as indicated in a MAC CE or DCI). The lower and upper limits may be expressed in terms of RB indices within a carrier, or in terms of the number of RBs between the applicable limit and the upper or lower edge of the carrier. In an example (e.g., in the latter case), the WTRU may report two values, X and Y, where X may correspond to the number of RBs between the upper edge of the allocation and the upper edge of the carrier, and Y may correspond to the number of RBs between the lower edge of the allocation and the lower edge of the carrier. In an example, the WTRU may report a single value for both.

[0114] The WTRU may report the PH assuming that spectrum shaping techniques such as frequency domain spectrum shaping or peak reduction tone reservation are used. The WTRU may report this PH on the condition that the actual PUSCH transmission meets certain conditions. In an example, the condition may be that the waveform type used for the actual PUSCH transmission is a DFT-S-OFDM waveform type.

[0115] Under the condition that the PH applicable to the actual transmission becomes lower (or higher) than a threshold or lower (or higher) than a threshold, the WTRU may trigger a report including at least one additional PH (e.g., among the above-mentioned PH additional PHs) or include an additional PH in the PHR. The threshold may be predefined or signaled by MAC or RRC.

[0116] An example of an L1 indication is provided herein in the case where the PH difference between waveforms is above a threshold. The WTRU may send an indication at L1, such as a PUCCH or uplink control information, if conditions related to power headroom are met (e.g., there may be a benefit in quickly notifying the network whether a change in waveform is appropriate).

[0117] The L1 indication may be sent using a scheduling request resource configured using RRC signaling for this purpose. The WTRU may follow the same procedure for sending a scheduling request, except that cancellation of a pending SR will occur if a PHR or enhanced PHR is included in the PUSCH transmission or if the PUSCH is sent using a specific waveform type (e.g., a DFT-S-OFDM waveform type).

[0118] The conditions for triggering the sending of the indication may include at least one of the following: the WTRU last sent a PUSCH using a particular waveform (e.g., a CP-OFDM waveform); the PH of the last sent PUSCH is below a threshold; the difference in PH or Pcmax between a PUSCH assumed to be sent under a first waveform type (e.g., a CP-OFDM waveform type) and a PUSCH assumed to be sent under a second waveform type (e.g., a DFT-S-OFDM waveform type) is above a threshold; or the path loss estimate is above a threshold, or the change in the path loss estimate has exceeded a threshold since the last L1 indication or PHR was sent.

[0119] At least one trigger (eg, of the above triggers) may (eg, may also) be used for sending enhanced PHRs of multiple waveform types.

[0120] Examples for carrier aggregation (CA) and dual connectivity (DC) scenarios may be provided. For the intra-band case, a dual PHR in a CC may trigger a dual PHR on a CC (e.g., all CCs). A dual PHR triggered in one CC may be considered to be in the CC that triggered the dual PHR (e.g., only in that CC), while the other PHR report may be based on the legacy format. The dual PHR may be a configurable report per CC or cell group (CG). For the intra-band case where a dual power amplifier (PA) may be reported by the WTRU, the dual PHR may also be configurable per CC or CG.

[0121] For the inter-band case, a timing advance group (TAG) may be defined. For inter-band, the triggered double PHR may be limited to CCs (e.g., active CCs), TAGs, or CGs within the band. Full double PHR may be triggered for (e.g., two) bands and may be a network-configured report.

[0122] An example of a response from the network for multiple PHRs may be provided. An indication associated with a grant type or PUSCH may be provided. In an example, the WTRU may receive a DCI or MAC-CE that may include an indicator of which waveform to use. If the WTRU transmits a PHR to the network, the WTRU may receive the indicator. The indicator may be associated with a grant or a scheduled PUSCH. In an example, the WTRU may receive an indication of a waveform associated with a configured grant (e.g., a configured grant type 1 or 2, a dynamic grant). In an example, the WTRU may receive a scheduled DCI associated with a PUSCH sent by the WTRU. The DCI may include a waveform that the WTRU may use for the associated PUSCH.

[0123] The network may transmit a waveform switch command to the WTRU without any PHR or double PHR or (e.g., other) triggered indication from the WTRU. This may be relevant for a scenario where the WTRU defaults to the DFT-s-OFDM waveform, is in good coverage (e.g., good UL SNR), and the buffer status report (BSR) indicates a good amount of data for the UL, and UL MIMO may be a solution to increase UL throughput.

[0124] An example of securely receiving a waveform switching command from a network is provided herein. In an example, a WTRU may receive an indication to switch waveform type in a PDCCH (e.g., a dedicated PDCCH). In an example, the PDCCH may include information about which waveform and MCS the WTRU may use for uplink transmission. Such indications may reduce the risk of false detection at the WTRU.

[0125] In an example, the WTRU may be scheduled with an opportunity (e.g., slot #, symbol #, dynamic / configured grant) at which the WTRU may expect to receive an indication (e.g., via PDCCH / PDSCH) as to which waveform type the WTRU should use for UL transmission. If the WTRU does not receive an indication from the network, the WTRU may continue to use the current waveform type. In an example, the WTRU may be configured to use OFDM. The WTRU may receive an indication from the network that the PDCCH received by the WTRU (e.g., the next PDCCH) may include an indication to switch to DFT-s-OFDM. If the WTRU receives a PDCCH and the WTRU does not find an indication to switch waveforms, the WTRU may determine to use OFDM for UL transmission.

[0126] Examples of indications in the form of negative ACK (NACK) or indications (e.g., implicit indications) for retransmission after transmitting a PHR are provided herein. The WTRU may determine to switch waveform types (e.g., if a command to retransmit a PUSCH or PUCCH is received or if the WTRU transmits a PHR (e.g., a double PHR) to the network). In an example, if the WTRU is configured with OFDM, the WTRU may transmit a PHR for OFDM and DFT-s-OFDM if one or more conditions (e.g., of the aforementioned conditions) are met. If a PHR is transmitted to the network (e.g., after the PHR), and if the WTRU determines to retransmit the PUSCH explicitly (e.g., a command transmitted from the network) or implicitly (e.g., no ACK is received from the network for the transmitted PUSCH), the WTRU may determine to switch to DFT-s-OFDM for retransmission.

[0127] For CA or DC cases, the waveform switching indication command may be applied to a CC (e.g., to CCs in the same CG), a TAG, or to a CC (e.g., all CCs) of active CCs across frequency bands (e.g., all frequency bands). The waveform switching indication may have information about the CC to which it is applied (e.g., additional information). In CA or DC cases, the cell may be active or inactive. When a CC is activated, the WTRU may follow at least the following rules for the waveform to be used: automatically use the same waveform as the remaining CCs in the CG, TAG, or Pcell / PScell; include a specific indication of the waveform to be used in the CC in the CC activation; include CC activation with a wave switching indication (e.g., different from the active waveform with the CG, TAG), which wave switching indication may switch the waveform of the entire CG, TAG; and include CC deactivation that may be bundled with waveform switching (e.g., because more power is available to the WTRU).

[0128] In an example, a WTRU may be configured with a first or default waveform type (e.g., OFDM) via RRC. The WTRU may transmit its capability information (e.g., dynamic waveform switching). The WTRU may be configured with a decoding rate table. The decoding rate table may include decoding rates for waveform types (e.g., two waveform types) and corresponding modulation and decoding rates. The WTRU may measure whether the DL-RS (e.g., CSI-RS) and RSRP change (e.g., compared to the last measurement opportunity) are above a preconfigured threshold. If the WTRU is scheduled with a dynamic grant, the WTRU may determine to transmit a PHR (e.g., two PHRs) to the network (e.g., one PHR for the first waveform type (e.g., OFDM) and the other PHR for the second waveform type (e.g., DFTsOFDM)). The PHR may be calculated based on the resources scheduled for the first waveform type. If the WTRU is not scheduled with a dynamic grant, the WTRU may return the PHR of the first waveform type. The WTRU may determine the waveform for the remaining UL transmissions under the grant. If the WTRU receives a configuration of the waveform type from the network via DCI, the WTRU may determine to switch the waveform type at the next transmission opportunity. Otherwise (e.g., if the WTRU does not receive a configuration of the waveform type from the network via DCI), the WTRU may complete the UL transmission using the first waveform type under authorization.

[0129] Examples of WTRU behavior are provided herein in the event that a waveform switch indication is received from the network (e.g., after receiving a waveform switch indication). Examples of ACK / NACK for switching waveforms are provided herein. The BS and WTRU may agree on which waveform type the WTRU uses for UL transmissions. This may be referred to as waveform state synchronization. If the network issues a command (e.g., after issuing a command), the change in waveform usage may be confirmed. The network waveform switch command may be implemented via a MAC, RRC, or DCI indication.

[0130] If the WTRU receives and / or correctly decodes an indication from the network via DCI or MAC-CE to switch waveform type or use the indicated waveform type, the WTRU may transmit an ACK to the network (e.g., gNB). If the WTRU sends an ACK to the network, the WTRU may determine to switch to the indicated waveform type.

[0131] For CA and DC cases with scheduling per CC, the WTRU may switch waveforms if the waveform switching command from the BS is acknowledged (e.g., only after acknowledgment) and (e.g., and then) the second waveform type is activated at a time that may be defined at least as follows: the waveform switching activation time may be indicated by the network through RRC configuration in time slots / frames, or dynamically indicated using the waveform switching command; after the switching command Ack is verified, the waveform activation time may be set for the next UL grant on the CC (e.g., any CC); or if the waveform switching indication is bundled with the CC activation command, the waveform switching time may be set after the CC activation specified delay and for the next valid UL grant in the CC.

[0132] Examples of time windows for switching waveforms are provided herein. In an example, the WTRU may need to preconfigure a time window to switch waveform types. The duration of the time window may depend on the ability of the WTRU to switch waveform types quickly. The time window may start at a specific time (e.g., one symbol, N symbols, one time slot, M time slots, one frame, K frames) after a PDCCH or PDSCH, which may include an indication of switching waveform types. The details of the time window (e.g., duration, start / end time) may be included in the RRC or indicated in the DCI or MAC-CE. The duration of the window may be configured semi-statically (e.g., via RRC) or dynamically (e.g., via DCI, MAC-CE).

[0133] An example of WTRU behavior is provided herein in the case where a waveform switch command is received after scheduling with an UL transmission. An example of WTRU behavior is provided in the case where a waveform switch indication is received after a scheduled PDCCH. In the example, the WTRU may determine to send PUSCH after switching waveform type based on at least one of the following criteria: whether the PUSCH is scheduled before the WTRU receives an indicator from the network via PDCCH / PDSCH; whether the scheduled PUSCH overlaps with the time window of the WTRU switching waveform where it is expected to switch waveforms; or WTRU capabilities (e.g., whether the WTRU is able to send PUSCH if the corresponding scheduled PDCCH / PDSCH is received before the waveform change indication).

[0134] In an example (e.g., during the window), the WTRU may not send PUSCH or PUCCH, so the WTRU may switch waveform types. The WTRU may send PUSCH or PUCCH during the time window, but using the previously configured waveform type. In an example, if the WTRU is currently configured with OFDM and the WTRU receives an indication from the network to switch to DFT-s-OFDM, the WTRU may send PUSCH or PUCCH using OFDM during the time window. The WTRU may send PUSCH or PUCCH using DFT-s-OFDM (e.g., after the time window).

[0135] Depending on capabilities, the WTRU may not be able to process a scheduled PDCCH or PDSCH during the time window. The WTRU may not be expected to send a PUSCH or PUCCH scheduled by a PDCCH or PDSCH received during the time window. Depending on capabilities, the WTRU may be expected to process a scheduled PDSCH or PDCCH received during the time window so that the WTRU may transmit a scheduled PUSCH or PUCCH after the waveform type is switched (e.g., after the end of the time window). In an example, the WTRU may discard a scheduled PUSCH or PUCCH scheduled before receiving an indication of switching the time window.

[0136] Figure 2 An example of scheduled PDCCH reception and corresponding PUSCH by a WTRU is shown. Figure 2 , scheduling of PDCCH and corresponding PUSCH is shown, where the PDCCH may include the timing at which the WTRU may send the PUSCH.

[0137] The WTRU may determine to cancel a PUSCH transmission scheduled before the waveform change if at least one of the following conditions is met: the WTRU is not capable of transmitting a PUSCH scheduled with a different waveform type; the resources (e.g., number of symbols, slots, RBs, REs) of the scheduled PUSCH are different between different waveform types (e.g., PUSCH occupies different time / frequency resources for OFDM and DFT-s-OFDM); or the parameters (e.g., MCS) of the scheduled PUSCH are not supported by the switched waveform type. If PUSCH is scheduled assuming π / 2 BPSK for DFT-s-OFDM and the WTRU is instructed to switch to OFDM, the WTRU may determine to cancel the scheduled PUSCH transmission because OFDM may not support π / 2 BPSK.

[0138] Figure 3 An example of reception and WTRU behavior of a waveform change indication is shown. Figure 3 , the WTRU behavior is shown in the case where the WTRU receives a waveform change indication after the PDCCH is scheduled. If the waveform change indication is received after the PDCCH is scheduled, the WTRU may determine that the transmission of the scheduled PUSCH is cancelled after the WTRU completes the waveform switch (e.g., because the PUSCH was scheduled based on the previously configured waveform). Figure 3 In the example, the WTRU may start the time window to switch waveforms N time slots after receiving the PDCCH, which may include an indication of the switching waveform.

[0139] Figure 4 An example PUSCH transmission after waveform switching is shown. Figure 4 As shown in , if PUSCH is scheduled after the WTRU switches waveforms, the WTRU may determine to send PUSCH.

[0140] Figure 5 An example of reception of a waveform change indication and WTRU behavior is shown. In the example, the WTRU may determine to send a PUSCH that was scheduled prior to receiving the waveform change indication. The WTRU may determine to send a PUSCH if at least one of the following conditions is met: the WTRU is capable of sending a PUSCH scheduled with a different waveform; the resources (e.g., number of symbols, slots, RBs, resource elements (REs)) of the scheduled PUSCH remain the same between different waveforms (e.g., the PUSCH occupies the same time / frequency resources for OFDM and DFT-s-OFDM); or the switched waveform supports the parameters (e.g., MCS) of the scheduled PUSCH.

[0141] Figure 6An example of WTRU behavior is shown in the case where the scheduled repetition overlaps with the switching window. The WTRU may determine to cancel the transmission of the PUSCH that overlaps with the window for changing the waveform. Figure 6 ), the WTRU may be scheduled by the scheduling PDCCH with 4 PUSCH repetitions. The first (e.g., only the first) PUSCH of the 4 repetitions may be scheduled by the scheduling PDCCH. The WTRU may determine (e.g., in this case) when to send the remaining repetitions (e.g., Figure 6 If these repetitions are scheduled (e.g., after these repetitions are scheduled), the WTRU may receive a PDCCH indicating the switching waveform. If the time window overlaps with one of these repetitions (e.g., PUSCH), the WTRU may cancel the PUSCH that overlaps with the window (e.g., Figure 6 Transmission of PUSCH#1) in the example shown in .

[0142] Figure 7 An example of WTRU behavior is shown in the case where scheduled repetitions overlap with a switching window and repetitions are cancelled. The WTRU may determine to cancel the transmission of PUSCH repetitions that overlap with a window for changing waveforms and PUSCH repetitions that do not overlap with the window (e.g., as Figure 7 shown).

[0143] Examples related to UL repetition may include repetition of PUSCH or PUCCH. The WTRU may determine to switch waveform types and use the switched waveform type to complete the repeated transmission. In an example (e.g., Figure 7 ), after the WTRU sends 2 of the 4 scheduled repetitions, the WTRU may receive an indication to switch waveform type. Since the time window for switching waveform type may not overlap with the PUSCH repetition transmission opportunity, the WTRU may determine to use the switched waveform type to send repetitions #3 and #4.

[0144] Figure 8 An example of WTRU behavior in the case of switching waveforms mid-repetition of PUSCH is shown. The WTRU may determine to cancel the repeated transmission after receiving a command to switch waveform type. Figure 8 As shown, after the WTRU transmits 2 of the 4 scheduled repetitions, the WTRU may receive an indication to switch waveform types. The WTRU may determine to cancel the transmission of repetitions #3 and #4 using the switched waveform even though the time window for switching waveform types does not overlap with the PUSCH repetition transmission opportunity. In the example, if the WTRU receives an indication to switch waveform types in the middle of a repetition, the WTRU may be configured to cancel the transmission of the repetition. In the example, the WTRU is to continue to complete the transmission after the waveform switch (e.g., as Figure 7 ) or cancel the send (for example, Figure 8 as shown) may depend on WTRU capabilities and / or configuration from the network.

[0145] Fig. 9 An example of WTRU behavior in the case of switching waveforms and canceling transmissions in the middle of repetitions of PUSCH is shown. If the WTRU receives a DCI or MAC-CE before the WTRU completes PUSCH repetitions, the WTRU may determine to switch to the indicated waveform type before the WTRU completes PUSCH repetitions.

[0146] Examples of WTRU behavior for waveform switching during joint channel estimation may be provided. Timing of scheduled PUSCH for phase / power continuity / consistency maintenance may be provided.

[0147] Fig.10 An example of waveform switching and joint channel estimation is shown. The WTRU may be configured to maintain phase continuity and power consistency across PUSCH repetitions (e.g., so that joint channel estimation may be performed by the network). The WTRU may (e.g., may need to) determine the intervals at which the WTRU may (e.g., may need to) perform continuity and consistency maintenance. Fig.10 As shown, the WTRU may be configured by the network to maintain phase continuity and power consistency across PUSCH repetitions. If the WTRU receives an indication to switch waveforms during a configured time window, then if the WTRU completes the switching waveform (e.g., after switching the waveform), the WTRU may determine to create a window (e.g., an actual window) to maintain phase continuity and power consistency.

[0148] Fig.11 An example of waveform switching and joint channel estimation is shown. Fig.11 As shown, the WTRU may receive the transmission schedule of the PUSCH repetition and the waveform switching indication in the same PDCCH. From the same PDCCH, the WTRU may determine the timing and duration of switching waveform types (e.g., the timing and duration in Fig.11 The WTRU may determine to create a window (e.g., two actual windows) before or after switching waveform types while maintaining phase continuity and power consistency during the actual windows (e.g., each actual window). Phase continuity and power consistency across actual windows may not be guaranteed (e.g., phase continuity and power consistency between PUSCH#2 and PUSCH#3 may not be achieved).

[0149] This document provides examples of the timing of configurations related to maintaining phase / power continuity / coherence. In the examples, the WTRU may receive joint channel estimation related configurations via RRC to perform phase / power continuity / coherence maintenance (e.g., the duration, start / end times for maintaining power coherence and / or phase continuity).

[0150] Fig.12 An example is shown where a waveform change indication is received before the time window configuration for joint channel estimation. If the WTRU receives an indication to switch waveform types from the network before receiving the configuration related to joint channel estimation, the WTRU may determine to maintain the phase continuity and power coherence of the PUSCH or PUCCH using the switched waveform type (e.g., for the switched waveform type, the WTRU may be expected to maintain phase continuity and power coherence). As Fig.12 shown, after the WTRU receives the waveform change indication, the WTRU may receive a PDCCH for configuring the time window. The WTRU may maintain the phase continuity and power coherence of the PUSCH or PUSCH repetition during the configured time window (e.g., as Fig.12 shown).

[0151] Fig.13 An example is shown where a waveform change indication is received after the time window configuration for joint channel estimation. If the WTRU receives an indication to switch waveforms after the WTRU receives the RRC configuration related to joint channel estimation, the WTRU may determine to cancel maintaining phase continuity and power coherence for the switched waveform of the scheduled PUSCH or PUCCH. In the example, the WTRU may receive the waveform change indication within the boundary starting from the start of the configured time window, during which the WTRU may be expected to maintain phase continuity and power coherence across PUSCH / PUCCH repetitions. As Fig.13 shown, the PDCCH for waveform indication and the corresponding window for changing the waveform may end M time slots from the start of the configured window #1. If the boundary is B time slots, where M < B, the WTRU may determine to cancel maintaining phase continuity and power coherence during the configured window. If the boundary is B time slots, where M < B, the WTRU may determine to cancel PUSCH transmission. If the WTRU receives an indication to switch waveform types after the WTRU receives the RRC configuration related to joint channel estimation, the WTRU may determine to cancel maintaining phase continuity and power coherence during the configured window.

[0152] Examples of delayed application of waveform switching in the context of repetition and / or joint channel estimation are provided herein. In an example, the WTRU may delay application of a waveform switching command until the end of a protected window defined by a PUSCH repetition set and / or an actual or nominal time window for maintaining phase and / or power consistency. The protected time window may be defined by at least one of: between the start of the first repetition of the PUSCH (or at the last symbol of the PDCCH indicating the PUSCH repetition set) and the end of the last repetition of the PUSCH; or an actual or nominal time window over which the WTRU maintains phase and / or power continuity. The WTRU may receive signaling to change the waveform type at a first time and apply the change in waveform type to a transmission occurring from a second time. The second time may be the earliest time that satisfies at least one of the following conditions: the earliest application if such earliest application does not occur during the protected time window; or the end of the protected time window (e.g., if the earliest application time falls within the protected time window).

[0153] The earliest application time may correspond to a delay after receiving the last symbol of the PDCCH indicating a waveform change or after sending the first or last symbol of the PUCCH or PUSCH including the corresponding HARQ-ACK. The delay may be predefined or configured by a higher layer.

[0154] Examples of fallback behavior are provided herein. Switch-back / fallback behavior conditions may be provided. In an example, the WTRU may determine to fall back to a previously configured waveform type if at least one of the following conditions is met: the WTRU is configured with a timer that starts when the WTRU switches waveform types; the WTRU is configured with a time window; the PUSCH or PUCCH transmission is associated with the indicated waveform type; or the switched waveform type is associated with a grant and when the grant terminates or expires, the WTRU determines to switch back to the previously configured / default waveform type.

[0155] For a WTRU configured with a timer that starts when the WTRU switches waveform type, the timer may start when the WTRU starts sending PUSCH using the switched waveform. The timer may start when the WTRU uses the PDSCH / PDCCH, which may include an indication of the switched waveform type. If the timer expires (e.g., after the timer expires), the WTRU may switch back to the previously configured / default waveform type. In an example, if the previously configured waveform type is OFDM and the timer associated with the switched waveform type (e.g., DFT-s-OFDM) expires, the WTRU may switch back to OFDM.

[0156] For a WTRU configured with a time window, during the time window, the WTRU may use the indicated waveform. After the time window, the WTRU may switch back to the first waveform type.

[0157] The WTRU may be configured with OFDM for PUSCH or PUCCH transmissions associated with the indicated waveform. The WTRU may receive a PDCCH from the network indicating the use of DFT-s-OFDM for scheduled PUSCH repetitions. After completing the scheduled PUSCH repetitions, the WTRU may switch back to OFDM.

[0158] For the switched waveform being associated with a grant and the WTRU determining to switch back to a previously configured / default waveform type when the grant terminates or expires, the WTRU may receive a command from the network to switch the waveform type and remain using the waveform under the grant that the WTRU was given / scheduled / granted. In an example, the WTRU may be configured with OFDM for UL transmission. The WTRU may receive a PDCCH from the network that may grant a dynamic grant to the WTRU. The WTRU may receive (e.g., additionally receive) an indication to switch to DFT-s-OFDM under the dynamic grant. If the dynamic grant is terminated, or the dynamic grant expires or ends, the WTRU may determine to switch back to a previously configured / default waveform type (e.g., OFDM).

[0159] An example of whether to switch back to a default waveform type may be provided. In an example, if the WTRU receives an indication from the network to change the waveform type, the WTRU may determine to continue using the switched waveform type until the WTRU receives another command (e.g., via DCI or MAC-CE) or configuration (e.g., via RRC) from the network to change to another waveform or the first waveform. In an example, the WTRU may initially be configured with OFDM. If the WTRU receives an indication from the network (e.g., via PDCCH) to switch the waveform to DFT-s-OFDM, the WTRU may determine to continue using DFT-s-OFDM for UL transmissions until the WTRU receives a configuration or indication to switch back to OFDM.

[0160] An example of waveform dependency on a TCI state instance or pool is provided herein. In an example, a WTRU may determine a waveform applicable to a PUSCH or a PUSCH repetition based on a transmit configuration indication (TCI) state, a TCI state instance, or a TCI state pool applicable to the transmission. The WTRU may indicate a first (or second) waveform indication in a first (or second) DCI or MAC CE, respectively, in a first (or second) TCI state instance. The WTRU may (e.g., may then) perform transmission of a PUSCH repetition set, wherein the PUSCH repetition (e.g., each PUSCH repetition) may be associated with a first (or second) TCI state instance. Such transmission of a PUSCH repetition set may be indicated by a third DCI or configured by a higher layer as authorized by configuration. The indication or configuration may indicate a mapping between a PUSCH repetition (e.g., each PUSCH repetition) and an associated TCI state instance. The WTRU may (e.g., may then) transmit a PUSCH using a first (or second) waveform of a PUSCH repetition associated with a first (or second) TCI state instance.

[0161] Examples of prioritization of waveform switching may be provided. Examples may apply to both dynamic waveform switching and semi-static waveform switching. Examples of waveform switching configuration per cell may be provided.

[0162] A WTRU may determine that a cell supports waveform switching before accessing / camping on a cell. The WTRU may use a broadcasted SIB message from a cell to determine that a cell supports waveform switching. The SIB message may include a set of supported waveforms and a switching mode between different waveforms (e.g., dynamic or semi-static waveform switching). The WTRU may determine that a cell supports waveform switching based on a configuration received from a serving cell. In an example, an RRC connected WTRU may receive a waveform set supported by a neighboring cell from its serving cell. In an example, the WTRU may be configured to associate a cell ID with a waveform set. The WTRU may be pre-configured with a mapping between a cell ID and a waveform set and / or waveform switching capability.

[0163] The WTRU may determine that a cell supports waveform switching / multiple waveforms based on the RACH resource configuration. In an example, if the RACH configuration of the cell includes PRACH formats for different waveforms, the WTRU may determine that the cell supports multiple waveforms (e.g., two waveforms) and / or waveform switching. A PRACH format may be associated with a specific waveform. A first PRACH format may be associated with a first waveform type and a second PRACH format may be associated with a second waveform type. The WTRU may determine that a cell supports waveform switching based on the PRACH resource allocation and the waveform associated with a subset of PRACH resources. A subset of RACH opportunities may be associated with different waveform types (e.g., OFDM and DFT-s-OFDM). A BWP or frequency band may be associated with different waveform types (e.g., band #1 for OFDM and band #2 for DFT-s-OFDM).

[0164] Features associated with cell selection / prioritization based on waveform configuration are provided herein. The WTRU may be configured to prioritize between cells during an initial access procedure and / or during measurement reporting of neighboring cells. The WTRU may prioritize one cell over another based on the set of supported waveforms and / or the availability of waveform switching functionality within the cell. In an example, during initial access, if the WTRU is in a coverage limited scenario relative to a cell with waveform switching functionality, the WTRU may be configured to prioritize that cell. In an example, if the measured RSRP of a reference signal is below a configured threshold and the cell does not support or indicate waveform switching, the WTRU may not select the cell. In an example, if the measured RSRP of its reference signal is below a configured threshold and the cell supports waveform switching (e.g., as Fig.18 ), the WTRU may select that cell. The reference signal of the cell may include a synchronization signal (SS) and / or a DMRS of the PBCH and / or a DMRS of CORESET 0. The WTRU may select / prioritize a cell based on a combination of one or more of the following: measured RSRP; capabilities of the WTRU; waveform / waveform switching capability (or indication) of the cell; cell ID; bandwidth of the cell; or licensed or unlicensed cell.

[0165] For measured RSRP, the WTRU may determine the RSRP of the cell (e.g., from SSB measurements during the initial access procedure or during RRM measurements). For WTRU capabilities, the WTRU may select a cell based on the waveform types that the WTRU is capable of using / supporting. For waveform / waveform switching capabilities (or indications) of a cell, the WTRU may select a cell based on the measured RSRP of the cell and the supported waveforms / switches (e.g., as Fig.18For cell ID, if the WTRU determines that a group of cells have the same waveform / waveform switching capability or indication, the WTRU may prioritize the cells based on their cell ID. In an example, the WTRU may select a cell with a smaller cell ID value. For the bandwidth of the cells, the WTRU may prioritize cells with a larger bandwidth over cells with a smaller bandwidth. For licensed or unlicensed cells, the WTRU may prioritize cells with unlicensed spectrum over cells with licensed spectrum.

[0166] In an example, before establishing initial access, the WTRU may communicate with a cell (e.g., a second cell) using a first waveform type. The WTRU may receive a first message (e.g., sent via RRC or SIB) from the cell (e.g., from the first cell) (e.g., such as Fig.18 The first message may indicate whether a cell (eg, a neighboring cell) supports dynamic waveform switching (eg, may indicate whether a second cell in the neighboring cell supports dynamic waveform switching, such as Fig.18 If the first message (e.g., SIB transmission) includes an indication that a cell (e.g., a second cell) supports dynamic waveform switching, the WTRU may determine that initial access to the second cell is prioritized over a cell (e.g., a third cell) that does not support dynamic waveform switching (e.g., as shown). Fig.18 ), where in some examples, the determination to prioritize initial access and establish initial access may be further based on the respective measurement results of each of the neighboring cells being below a threshold, as described herein (e.g., as Fig.18 ). If the WTRU supports a particular waveform type or switches between waveform types, such prioritization may be achieved by applying an offset to the RSRP or RSRQ measurements of the cell. The cell may be a serving cell or a neighboring cell. The offset applicable to the cell (e.g., each cell) and the corresponding waveform or waveform switching indication may be received by system information. The offset may be fixed or configured as a common offset to indicate the waveform or neighboring cells (e.g., all neighboring cells) for which the waveform switching is targeted.

[0167] During RRC_CONNECTED, the WTRU may receive a configuration from the network indicating resources for UL transmission of dynamically switched waveforms. Examples of such resources may include carrier components, bandwidth parts (BWPs), and / or frequency bands. The WTRU may be configured to start a random access procedure on multiple cells and select a cell based on a waveform switching configuration received in a random access response. In an example, the WTRU may initiate a random access (RA) procedure on two cells (cell 1 and cell 2). The WTRU may receive a first random access response (RAR) from cell 1 indicating that a single waveform supports or does not support waveform switching. The WTRU may (e.g., may also) receive a second RAR from cell 2 indicating support for waveform switching. The WTRU may select cell 2 to continue its RA procedure and stop the initial access procedure on cell 1.

[0168] An example of data selection and multiplexing based on a waveform associated with a UL grant may be provided. The WTRU may be configured by a higher layer (e.g., RRC signaling) or predefined using an association between an LCH and one or more applicable waveforms. The LCH may be a data radio bearer (DRB) or an SRB LCH. For a given UL grant for data transmission (e.g., an initial transmission), the WTRU may determine the applicable waveform type. The WTRU MAC may multiplex UL data (e.g., part of a logical channel prioritization procedure (LCP)) from an LCH (e.g., only from the LCH) configured with a waveform for the UL grant. The WTRU may be configured or predefined using an association between a waveform type and a priority index. The WTRU may determine the waveform type associated with the grant from a signal priority index associated with the grant. The WTRU MAC may multiplex UL data from an LCH (e.g., only from the LCH) configured with a priority index associated with a waveform for the UL grant.

[0169] The WTRU may be predefined by higher layer configuration (e.g., RRC signaling) or by using an association between certain MAC CEs or MAC CE formats and one or more applicable waveforms. The WTRU may multiplex a PHR MAC CE format associated with a specific waveform scheme (e.g., DFT-s-OFDM) and / or reflect the actual PHR if (e.g., only if) the grant to which the MAC CE is multiplexed belongs to that waveform type.

[0170] An example of waveform determination based on a HARQ process ID or grant type is provided herein. The WTRU may be configured (e.g., via RRC signaling) with an association between a waveform type and a subset of HARQ process IDs. In an example, the RRC may configure the WTRU such that waveform A (e.g., DFT-s-OFDM) may be associated with hybrid automatic repeat request (HARQ) processes 0 to 12, and waveform B (e.g., OFDM) may be associated with HARQ processes 13 to 15. If a UL grant is received for transmission, the WTRU may determine the waveform to use for the UL transmission under the grant from the associated HARQ process ID.

[0171] The WTRU may be configured or predefined with an association between a grant type and a waveform type. The WTRU may determine the waveform type to use for transmission under a UL grant from whether the grant is a configured grant type 1, a configured grant type 2, a dynamic grant, a grant for msg3, a grant for msgA, or a grant for msg5. Such an association may be specified rather than configured.

[0172] The WTRU may receive an indication to associate a waveform with a grant. In an example, the WTRU may receive an indication to switch the waveform type for a dynamic grant scheduled by the WTRU. The indication may be included in the PDCCH or PDSCH. Based on the indication, the WTRU may determine to switch the waveform type if the grant is scheduled / activated or configured.

[0173] By adaptively switching the waveform type of UL transmission, coverage performance or throughput performance may be improved. Examples of switching waveform types for initial access are provided herein. Examples of indication of WTRU capabilities during initial access are provided herein.

[0174] Fig.14 An example of a 4-step initial access RACH procedure is shown. Fig.15 An example of a 2-step initial access RACH procedure is shown. Dynamically switching waveforms may require hardware at the WTRU that may allow fast switching between waveform types (e.g., between DFT-s-OFDM and OFDM). During RRC_CONNECTED, the WTRU may communicate WTRU capability information to the network (e.g., that the WTRU is capable of switching waveforms directly). Since the network may not have the WTRU capability information until initial access is successfully established, the WTRU may be required to indicate its ability to dynamically switch waveforms during initial access.

[0175] The WTRU may initiate an initial access, which may allow dynamic waveform switching in at least one of the following configurations: The WTRU sends a preamble in a transmission opportunity for preamble transmission (e.g., a RACH opportunity that may be defined by time and / or frequency resources), which may be specified to indicate that the WTRU may support dynamic waveform switching (e.g., as Fig.18 as shown); the WTRU sends a preamble via resources used for preamble transmission; the WTRU sends a preamble without explicit indication of capability information by the WTRU; or the WTRU sends a preamble via a preamble sequence associated with a waveform that the WTRU is requesting for msg3 / msg5 / normal PUSCH transmission.

[0176] For a WTRU that does not explicitly indicate capability information, such a situation may occur if the network does not have sufficient time and / or frequency resources to allocate a RACH opportunity for the WTRU to indicate its ability to dynamically switch waveforms. The WTRU may send a preamble (for example, in this case) at a RACH opportunity that may be used for existing purposes (for example, indicating a request for msg3 repetition, coverage extension, WTRU's ability to be used for small data transmission). For a WTRU that sends a preamble sequence associated with the waveform type that the WTRU is requesting for msg3 / msg5 / normal PUSCH transmission, the parameters of the sequence may be broadcast or transmitted by the network in dedicated signaling. If the WTRU is pre-configured with a waveform type by the network before establishing initial access, the WTRU may determine to send the preamble sequence to request the waveform type. If the network receives the preamble (for example, in the examples herein), it may determine that the WTRU is capable of dynamically switching waveforms. The network may not know whether the WTRU is capable of dynamically switching waveforms (for example, in the examples herein, the WTRU does not indicate its ability to dynamically switch waveforms). In an example, the WTRU may include its capability information (for example, capable of directly switching waveforms) in msg3 or msgA.

[0177] An example of how to configure a default waveform type may be provided. The WTRU may determine the default waveform type based on broadcast information (e.g., SIB) or dedicated signaling from the network. If the WTRU does not receive broadcast information or dedicated signaling through the network, the WTRU may determine to use a predefined waveform type (e.g., OFDM).

[0178] An example of switching priority / when to instruct the WTRU to switch may be provided. If the WTRU is preconfigured with more than one waveform type (e.g., OFDM with different MCS, DFT-s-OFDM with different MCS), the WTRU may receive broadcast information or dedicated signaling from the network to switch waveform types on a priority list. In an example, the WTRU may be preconfigured with OFDM with QPSK, DFT-s-OFDM with QPSK, and DFT-s-OFDM with π / 2BPSK. The WTRU may receive a priority list from the network indicating the order of precedence, OFDM with QPSK, DFT-s-OFDM with QPSK, DFT-s-OFDM with π / 2BPSK, where OFDM with QPSK may be a first waveform type (e.g., a default waveform type) and MCS. If the WTRU determines to switch waveform type from a first waveform type and MCS, the WTRU may determine to switch to a second waveform type (e.g., DFT-s-OFDM) with QPSK based on the priority list received from the network. The priority list may be broadcast or transmitted by the network in dedicated signaling.The WTRU may be configured with this list when the WTRU is in RRC_CONNECTED and the configuration may be saved if the WTRU enters IDLE or INACTIVE state.

[0179] The WTRU may be configured with only a list of waveform types (eg, two waveform types). When the WTRU determines to switch waveform types, the WTRU may switch to a waveform type that the WTRU is not using for UL transmissions.

[0180] The WTRU may receive an indication of switching waveform type in msg2 or msg4 (e.g., Fig.18 As shown, where msg2 or msg4 may be the second message). If the WTRU indicates a request to switch waveform type in msg1, the WTRU may receive an indication of the switching waveform type from the network in msg2, and if the WTRU includes its ability to dynamically switch waveforms, the WTRU may receive an indication of the switching waveform type from the network in msg4.

[0181] An example of WTRU behavior for msg3 may be provided. If the network does not allocate a RACH opportunity for an indication of dynamic waveform switching, the WTRU may determine to perform at least one of the following: based on a condition (e.g., RSRP of the SSB is below a preconfigured threshold), the WTRU may determine to switch waveform type from the default waveform type for msg3 transmission; if msg2 (e.g., RAR) includes a grant offset (e.g., number of slots, frames, symbols), and if the WTRU determines to switch waveform type from the default waveform type, the WTRU may transmit msg3 with a grant that is the same as the grant offset configured in msg2; if msg2 (e.g., RAR) includes a fallback RAR, and if the WTRU determines to switch waveform type from the default waveform type, the WTRU may transmit msg3 with a grant that is a preconfigured offset value from the grant offset configured in msg2 (e.g., the WTRU may obtain the offset value from the broadcast or in dedicated signaling transmitted from the network); or if preconfigured by the network, the WTRU may monitor more than one search space for the RAR indicating the switching of waveform type for msg3 repetition. Based on the quality of the preamble (eg, RSRP), the network may determine to transmit the RAR in the search space allocated for configuring msg3 transmission parameters (eg, waveform, grant).

[0182] The WTRU may determine the default waveform type (eg, OFDM) to use during initial access based on an indication received on broadcast information (eg, SIB) from the network, dedicated signaling (RRC (re)configuration), or being pre-defined.

[0183] The WTRU may determine a non-default waveform type (e.g., DFT-s-OFDM) to use during initial access based on an indication received on broadcast information (e.g., SIB) or dedicated signaling (RRC (re)configuration) from the network. If the WTRU does not receive broadcast information (e.g., during initial access), the WTRU may determine to use a predefined waveform type (e.g., OFDM). The WTRU may have the ability to use a non-default waveform type or switch between different waveform types. A WTRU capable of such multiple waveforms may obtain a broadcast configuration (e.g., additional broadcast configuration) or system information (e.g., additional system information), possibly on a separate SIB, possibly before initiating a RA (e.g., during initial access). The WTRU may be configured via broadcast information, i.e., which waveform to use for msgA or msg3, possibly per PRACH resource (e.g., a subset of preambles and / or RACH opportunities).

[0184] Figure 16 to Figure 17 An example of the association between RO and waveform is shown. Fig.16As shown, the WTRU may request OFDM by transmitting a preamble in RO#1. A subset of ROs may correspond to different SSBs, and the WTRU may indicate the waveform type requested by the WTRU by sending a preamble at the associated RO. A subset of ROs may correspond to (e.g., also correspond to) SSBs from which the WTRU may measure RSRP above a preconfigured threshold. The RO (e.g., each RO) may indicate to the network the waveform type desired by the WTRU and the spatial direction and / or width of the SSB from which the WTRU observes a sufficiently large RSRP.

[0185] An example of an indication of waveform capabilities in msg1 may be provided. The WTRU may indicate (e.g., may implicitly indicate) a capability associated with supporting dynamic waveform switching (e.g., between DFT-s-OFDM and OFDM) through a msg1 PRACH resource selection. The WTRU may indicate this capability through a msg1 selection in a subset of (e.g., only in that subset of) RRC states (e.g., RRC IDLE and / or RRC inactive mode). If the WTRU is pre-configured with a waveform type by the network (e.g., prior to establishing initial access / RA), the WTRU may determine to send a PRACH sequence to request a specific waveform (e.g., on a RO associated with an indication of such capability).

[0186] A WTRU may be configured (e.g., via broadcast or dedicated signaling) with a partition of PRACH resources (e.g., a subset of preambles and / or ROs) that is selected by the WTRU during a RA procedure (e.g., as part of initial access). The partitions of PRACH resources may be configured to indicate the ability to support more than one waveform type, a non-default waveform, and / or waveform switching. In an example, the WTRU may indicate (e.g., also indicate) the capability of waveform switching using a msg1 PRACH resource partition (e.g., configured for the purpose of indicating coverage limitation), the partition including at least: the ability to indicate msg3 repetitions; and / or a partition indicating a coverage level (e.g., a measurement result (e.g., RSRP) less than a threshold configured for msg3 repetitions). If the WTRU is capable of multiple waveform types and / or waveform switching, the WTRU may be configured or predefined to select a msg1 or msgA PRACH resource partition (e.g., configured) for the purpose of indicating a small data transmission (SDT). If the measured RSRP is below a threshold, the WTRU may select a specific partition (e.g., a partition associated with an indication of waveform capability switching, coverage limitation, or SDT). Otherwise (e.g., if the measured RSRP is not below a threshold), the WTRU may select a legacy RACH resource.

[0187] If the WTRU is capable of waveform switching and / or if the WTRU selects an RO partition associated with an indication of a waveform (e.g., an alternative waveform) or a capability indicating multiple waveforms, the WTRU may be configured with parameters (e.g., alternative parameters) for the purpose of msg1 transmission or retransmission. Such parameters may be configured via broadcast or dedicated signaling. Specific parameters (e.g., alternative parameters) may include: differential transmit power; differential tx spatial filter; number of msg1 repetitions; differential backoff; differential power increase step size; different Zadoff Chu root sequences (or logical root sequence indices); or different sets of sequence shifts (e.g., different Ncs). If the WTRU initiates a RA on an RO associated with an indication of waveform switching capability and / or if a different waveform type is used to transmit the preamble, the WTRU may apply such differential parameters.

[0188] If a configured number of msg1 and msg3 are retransmitted (e.g., after a configured number of msg1 retransmissions and / or msg3 retransmissions) (e.g., using the first waveform / default waveform type), the WTRU may be configured to switch to a RA partition configured to indicate coverage limitation or waveform switching capability.

[0189] An example of an indication of waveform capabilities in a PUSCH payload (e.g., in msgA or msg3) may be provided. The WTRU may include its capability information (e.g., capable of switching waveforms, supporting multiple or different / non-default waveforms), a portion of the payload msg3, msgA, or a portion of a small data PDU multiplexed on a RA-SDT or CG-SDT resource. The WTRU may be configured with a partition of CG-SDT resources on which the WTRU may use a different waveform type (e.g., a non-default waveform type) for PUSCH SDT transmissions. If the WTRU is capable of having a different waveform type (e.g., a non-default waveform type), if msg3 is sent using a different waveform type (e.g., a non-default waveform type) and / or indicates the ability to support a different waveform type (e.g., a non-default waveform type), then the WTRU may multiplex a predefined or differential DMRS on a msg3 or msgA PUSCH transmission. The DMRS may be generated based on the signaled temporary C-RNTI or RA-RNTI.

[0190] Examples of signaling of waveform types in msg2 or msgB are provided herein. Examples of indicating waveform capabilities through grant selection / sending are provided herein. If the WTRU supports capabilities for multiple waveform types, and such capabilities are not indicated as part of msg1 / msgA, the network may not know whether the WTRU can dynamically switch waveforms just by receiving msg1 / msgA. The WTRU may receive grants that support more than one waveform type, multiple grant types for different waveform types in the same RAR, and / or multiple RARs that support msg3 grants for different waveform types.

[0191] If the WTRU is capable of waveform switching, the WTRU may receive the legacy RAR format but may interpret the UL grant parameters differently. The WTRU may receive the UL grant in the RAR but the resource allocation (in time and / or frequency) may be interpreted differently depending on the waveform capabilities of the WTRU. The WTRU may apply a predefined or configured shift or offset in the time domain and / or frequency domain to the UL grant allocation signaled in the RAR (e.g., if the WTRU uses a different waveform type (e.g., DFT-s-OFDM)). If a grant offset (e.g., number of slots, frames, symbols) is applied and if the WTRU determines to switch waveforms from a first waveform type (e.g., a default waveform type), the WTRU may send msg3 using a grant offset from the allocation indicated in msg2. The WTRU may obtain the offset value from a broadcast from the network. Such WTRU behavior may be applied by the WTRU (e.g., only for) a fallback RAR (e.g., msg2 received after sending msgA) or after multiple msg1 or msg3 retransmission attempts. If the WTRU reverts to a 4-step RA after N failed configuration attempts for a 2-step RA, the WTRU may select a RACH partition associated with an indication of coverage enhancement or a different waveform type (eg, a non-default waveform type).

[0192] In an example, a WTRU capable of multiple waveform types may monitor RARs on one or more search spaces, one or more core sets, and / or one or more RA-RNTIs. The WTRU may monitor RARs (e.g., additional RARs) on a search space (e.g., a search space separate from a search space configured for a legacy WTRU) to receive a RAR that may include a UL grant. The UL grant may be sent using a different (e.g., non-default) waveform (e.g., DFT-s-OFDM). Such a search space may be a common search space (e.g., for a WTRU capable of waveform switching) or a WTRU-specific search space.

[0193] The WTRU may monitor RARs (e.g., additional RARs) on a RA-RNTI that is separate from the RA-RNTI of the legacy WTRU for the selected RO. In an example, if the WTRU is capable of multiple waveforms, the WTRU may apply an offset to the determined RA-RNTI or msgB-RNTI. The WTRU may monitor such search spaces (e.g., additional search spaces) and / or RA-RNTIs if (e.g., only if) configured by the network or if the measured channel conditions are below a configured threshold. In the event that the WTRU receives multiple msg3 grants and / or RARs, the WTRU may select a grant or select to decode a RAR associated with a different waveform type (e.g., a non-default waveform type) if the measured channel conditions (e.g., RSRP) are below a configured threshold. If the grant size is the same for the grants (e.g., all grants) and / or if the coverage level is below a threshold, the WTRU may use the signaled (e.g., all signaled) msg3 grants associated with the WTRU's RA-RNTI to send potentially duplicate msg3 content. The WTRU may be configured with a subspace of TC-RNTI or C-RNTI such that if the temporary C-RNTI indicated in the RAR falls within such subspace, the WTRU may use a different waveform type (e.g., a non-default waveform type) for transmission of msg3 and UL transmission (e.g., subsequent UL transmission).

[0194] The WTRU may receive an indication in msg2 to switch waveform types (e.g., switch to a different / non-default waveform type) (e.g., as Fig.18 . In an example, if the WTRU indicates a request to switch waveforms in msg1 (e.g., by selecting a RA partition associated with such capabilities), the WTRU may receive an indication from the network to switch waveform types in msg2. The indication may be carried as a bit flag portion of the RAR PDSCH payload, a bit portion of the L2 MAC RAR sub-PDU, a bit in the MAC sub-header, a reserved bit in the MAC RAR sub-PDU, or an indication in PDCCH signaling of a scheduled RAR (e.g., determined from the DCI format, TDRA, FDRA, overloading the MCS field, or an explicit indication in the DCI). After the RA is successfully completed, the WTRU may apply the indicated waveform type in msg2 to the transmission or UL grant / transmission of msg5 (e.g., as shown in FIG. 1 ). Fig.18 If contention resolution is successful, the WTRU may continue to use the same waveform type as used in msg3 in msg5.

[0195] The WTRU may receive a DCI (e.g., DCI0_0) indicating a msg3 retransmission, which indicates to the WTRU (e.g., also indicates) which waveform type is used for the msg3 retransmission (e.g., determined from the DCI format, TDRA, FDRA, overloading the MCS field, or an explicit indication in the DCI). The WTRU may receive an indication of which waveform type is used for an UL transmission (e.g., a subsequent UL transmission), i.e., part of a PDCCH order for a contention-free RA.

[0196] An example of waveform selection for msg3 transmission may be provided. The WTRU may perform a dynamic determination of which waveform type to use for msg3 / msg5 transmission, possibly indicating the capability (e.g., only the capability) of multiple waveform support to the network portion of msg1, msgA, or a previous PUSCH transmission.

[0197] The WTRU may determine to switch waveforms from a first waveform type (e.g., a default waveform type of an OFDM waveform type) for msg3 transmission if at least one or more of the following conditions are met: based on channel conditions, if the RSRP of the SSB is below a preconfigured threshold; based on parameters signaled for UL grant, the WTRU may determine which waveform type to use for msg3 transmission from a value signaled for UL grant allocation, a value signaled for MCS, or other parameters associated with the UL grant; assuming OFDM is the first waveform type (e.g., the default waveform), if the number of resources (e.g., resource elements RB) is less than a preconfigured threshold, the WTRU may determine to switch to a DFT-s-OFDM waveform type for msg3 transmission; if the MCS configured for the grant is π / 2BPSK or any MCS applicable to (e.g., only applicable to) the DFT-s-OFDM waveform type, the WTRU may determine to switch to a DFT-s-OFDM waveform type for msg3 transmission; if the cumulative based on the number of msg3 repetitions signaled for msg3, if the number of msg3 repetitions signaled is higher than 1 or higher than a configured or predefined number, the WTRU may use a different (e.g., non-default) waveform type to send msg3; based on the signaled TA value, the WTRU may determine which waveform type to use for msg3 transmission from the value signaled for timing advance (or if some preconfigured value is signaled); if the TA value is higher than a threshold, the WTRU may determine to use the DFT-s-OFDM waveform type because, based on the TA value, the WTRU may determine that its location is relatively far away from the base station; or based on the number of retransmissions associated with msg3, if the first waveform type (e.g., the default waveform type) is OFDM and the number of retransmissions is greater than a preconfigured threshold, the WTRU may determine to switch to the DFT-s-OFDM waveform type for msg3 transmission.

[0198] An example of signaling of the waveform type in msg4 may be provided. The WTRU may receive an indication from the cell to switch waveforms in a second message (e.g., msg4 or msgB) (e.g., Fig.18s-OFDM waveform type) for UL transmission (e.g., a subsequent UL transmission). The WTRU may receive an indication from the network of a waveform type switch (e.g., from a CP-OFDM waveform type to a DFT-s-OFDM waveform type) in a second message (e.g., msg4 or msgB) for UL transmission (e.g., a subsequent UL transmission) if the WTRU indicates a request to switch waveforms in msg3 or msgA. The WTRU may receive an indication of a waveform portion of a payload of a contention resolution MAC sub-PDU or a payload of msgB. The WTRU may apply the indicated waveform type (e.g., DFT-s-OFDM waveform type) to the transmission of a third message (e.g., msg5 or UL grant / transmission) (e.g., after a successful completion of the RA) (e.g., as shown). Fig.18 5). The WTRU may receive an indication portion of msgB modulated for a PUCCH transmission associated with HARQ feedback for a msgB TB or UL transmission (e.g., a subsequent UL transmission). The WTRU may be preconfigured to return more than one PHR in msg3 or msg5 if one of at least one (e.g., aforementioned) condition for transmitting a PHR is met. The WTRU may be configured to transmit a PHR in a third message (e.g., msg5) via a PUSCH transmission so that the network can determine which waveform type is configured for a subsequent PUSCH transmission.

[0199] An example of fallback behavior may be provided. If the WTRU is unsuccessful in the initial access procedure with a preconfigured number of attempts, where the number of attempts may be broadcasted in the SIB or dedicated signaling, the WTRU may determine at least one of the following: if the WTRU does not successfully complete the 4-step RACH procedure, the WTRU may fall back to PRACH transmission in preconfigured PRACH resources if available (e.g., a coverage extended RACH opportunity indicating a request for msg3 repetition, the WTRU may select a preamble sequence from a preconfigured pool of preamble sequences); or if the WTRU does not successfully complete the 2-step RACH, the WTRU may fall back to PRACH transmission in a preconfigured RACH opportunity (e.g., a coverage extended RACH opportunity indicating a request for msg3 repetition) in the 4-step RACH procedure.

[0200] Fig.18An example of dynamic waveform switching is shown. If a WTRU receives a first message (e.g., sent via RRC or sent via SIB) from a plurality of cells (e.g., from a first cell of the plurality of cells), and if the WTRU determines (e.g., if the first message indicates) that a cell (e.g., a second cell of a neighboring cell) supports dynamic waveform switching, the WTRU may determine to perform initial access by prioritizing a cell that supports dynamic waveform switching (e.g., the second cell) over a cell that does not support dynamic waveform switching (e.g., the third cell) (e.g., if the WTRU is capable of dynamically switching waveforms), where in an example, the prioritization may be further based on a measurement result (e.g., RSRP) of the second cell being below a threshold. The WTRU may receive the first message via a first waveform type (e.g., a CP-OFDM waveform type). The WTRU may determine a RACH procedure to use. If the RSRP of the SSB is above a threshold, the WTRU may determine to initiate a 2-step RACH. The WTRU may determine from the SIB a first waveform type (e.g., a default waveform type (e.g., an OFDM waveform type or a CP-OFDM waveform type)), a grant offset (e.g., a number of slots), and a number of allowed attempts (N). The WTRU may send a preamble and msgA. The preamble may indicate the WTRU's ability to support dynamic waveform switching. The WTRU may receive a second message indicating a second waveform type (e.g., a DFT-s-OFDM waveform type) for sending a third message. If the WTRU receives a fallback RAR, the WTRU may determine the transmission parameters if the fallback RAR is received (e.g., after receiving the fallback RAR) (e.g., where the fallback RAR includes grant information). The WTRU may determine to send the second waveform type (e.g., a DFT-s-OFDM waveform type) in the third message, the third message having a grant offset from the grant indicated in the fallback RAR. The WTRU may determine to fall back to 4-step RACH and use the RACH partition for coverage extension of msg1 (preamble transmission) (e.g., after N RACH failures). If the WTRU does not receive the fallback RAR, the WTRU may continue with the RRC_CONNECTION procedure (e.g., a successfully established connection). If the RSRP of the SSB is not above the threshold, the WTRU may initiate a 4-step RACH.

[0201] Examples of transmissions on multiple time slots and waveform switching are provided herein. Prioritization between coverage enhancement techniques may be provided. The WTRU may be configured with multiple coverage enhancement techniques (e.g., such as transmission of TBs on multiple time slots, PUSCH repetition, and waveform switching). The WTRU may be configured with multiple configured grants for UL transmissions. The multiple configured grants for UL transmissions may include a first uplink grant configured with an OFDM waveform type on a single time slot, a second uplink grant configured with a DFT-s-OFDM waveform type on a single time slot, a third uplink configured grant with an OFDM waveform type on multiple time slots (e.g., multi-time slot TB (TBoMS)), and a fourth UL grant with a DFT-s-OFDM waveform type on multiple time slots. Such configured grants may overlap in the time domain. The WTRU may be configured to select one grant for UL transmission. The WTRU may select / prioritize between different coverage enhancement techniques by selecting a configured grant for UL transmission corresponding to a specific coverage enhancement technique. The WTRU may determine which coverage enhancement technique(s) to use based on one or more of the following: a gNB indication of the allowed waveform type for UL transmissions; a gNB indication that waveform switching is enabled; the number of UL timeslots within a configured duration is below a configured threshold; the number of consecutive UL timeslots is above a configured threshold; whether joint channel estimation (JCE) is enabled; the number of allocated timeslots for TBoMS; the configured number of timeslots for PUSCH repetitions; the configured maximum power of the waveform and the measured path loss of the reference signal; the required latency for UL transmissions; or a frequency hopping configuration.

[0202] For gNB indication of allowed waveforms for uplink transmissions, the gNB may transmit to the WTRU an indication / configuration of allowed waveforms for UL transmissions using at least one of RRC signaling, MAC CE, or DCI. If the WTRU determines that the allowed waveform type is OFDM, then the WTRU may use TBoMS instead of single-slot PUSCH transmission for the configured authorized transmissions. If CP-OFDM is allowed, then the WTRU may use single-slot PUSCH transmissions.

[0203] For a gNB indication of enabling waveform switching, the WTRU may receive a group-common DCI indicating that waveform switching is enabled. The WTRU may (e.g., in this case) autonomously determine the waveform type to use for UL configuration grant transmission.

[0204] For the number of UL timeslots within the configured duration being below the configured threshold, based on the received TDD configuration (dynamic or semi-static TDD configuration), the WTRU may determine that the number of UL timeslots within X ms is below the configured threshold X. thThe WTRU may (eg, may then) use DFT-s-OFDM instead of TBoMS transmission with OFDM on a single time slot.

[0205] For the number of consecutive UL timeslots being above the configured threshold, based on the received TDD configuration (dynamic or semi-static TDD configuration), the WTRU may determine that the number of consecutive UL timeslots is below the configured threshold. The WTRU may (e.g., may then) use TBoMS transmission with OFDM instead of DFT-s-OFDM on a single timeslot.

[0206] Regarding whether Joint Channel Estimation (JCE) is enabled, if JCE is enabled and is used for transmission, the WTRU may prioritize using the same waveform. If JCE is not enabled, waveform switching may prioritize.

[0207] Regarding the number of allocated time slots for TBoMS, the WTRU may determine that the number of allocated time slots for TBoMS is below a threshold and cannot meet the required reliability of the available TBS.

[0208] For the configured number of slots for PUSCH repetition, if the number of repetitions configured for the grant is above a threshold, the WTRU may use PUSCH repetitions. If the number of repetitions configured for the grant is below a threshold, the WTRU may use a different waveform (e.g., waveform switching).

[0209] For the required latency of UL transmission, the WTRU may choose to transmit on a single timeslot using waveform switching instead of using TBoMS transmission for low latency requirements.

[0210] For frequency hopping configuration, the WTRU may choose to configure a grant with frequency hopping over multiple time slots instead of using waveform switching.

[0211] Examples of debugging of multi-slot transmissions in the event of (eg, after) a waveform switch is received are provided herein.

[0212] The WTRU may receive a waveform switch indication from the gNB if (e.g., when) a TB is transmitted. Such a transmission may be a multi-slot transport block (TBoMS) or a transport block repetition (PUSCH repetition). In an example, the WTRU may receive a waveform switch indication / command from the gNB during the transmission of the TBoMS or PUSCH repetition using a group common DCI indicating a waveform switch for the UL transmission. In an example, the WTRU may be configured to switch waveform types during the transmission of the TBoMS / PUSCH repetition. In an example, if an indication to change waveform is received from the gNB (e.g., after), the WTRU may be configured to change waveform type in the next timeslot of the TBoMS / PUSCH repetition. The WTRU may be configured to change waveform type N timeslots after receiving an indication to change waveform type from the gNB. The WTRU may be configured to discard the ongoing transmission and use a different grant (e.g., an alternative grant). In an example, the WTRU may be configured with an alternative grant that may be used if the ongoing transmission is discarded due to a waveform switch. In an example, the WTRU may be configured to continue transmitting using the indicated waveform without changing the waveform type or ceasing to transmit.

[0213] The WTRU may be configured with an MCS table that may be used for multiple waveform types (e.g., the same table may be used for CP-OFDM and DFT-s-OFDM). In an example, the MCS table may have some MCS indices for (e.g., only for) CP-OFDM transmissions, other MCS indices for (e.g., only for) DFT-s-OFDM, and other MCS indices for both CP-OFDM and DFT-s-OFDM. If the WTRU receives a DCI scheduling an UL grant, and the DCI indicates MCS indices for both CP-OFDM and DFT-s-OFDM, the WTRU may desire (e.g., may) perform waveform switching during a transmission (e.g., a TBoMS transmission).

[0214] If the waveform type is switched (eg, afterwards), the WTRU may stop JCE. In an example, the WTRU may continue to perform JCE and delay waveform switching until the start of the next JCE window.

[0215] An example of power control adjustment in the event of (e.g., after) receiving a waveform switch indication is provided herein. A WTRU may be configured to transmit multiple UL transmissions using a first waveform type and may receive an indication to switch waveforms to transmit using a second waveform type. During transmissions using the first waveform type, the WTRU may receive a transmit power control (TPC) command from the gNB. The WTRU may adjust / convert a TPC value received in the event of (e.g., when) transmitting using the first waveform to calculate an "equivalent TPC". If the second waveform type is used, the "equivalent TPC" may be used to calculate the transmit power to be transmitted. In order to adjust / convert the TPC value, the gNB may provide a maximum power reduction (MPR) to the WTRU. The WTRU may be configured with a mapping table between TPC commands received in the event of transmitting using the first waveform and TPC commands to be used in the event of transmitting using the second waveform type. Such a mapping may be a table configured to the WTRU, depending on the configured MPR. If a waveform switch is indicated, an updated (e.g., new) TPC command may be provided from the gNB to the WTRU. In an example, the WTRU may receive an updated (eg, new) TPC command in a DCI indicating a waveform switch to the WTRU.

[0216] The WTRU may be configured to maintain the accumulated TPC regardless of the indicated waveform and scale with an updated (e.g., new) Pcmax depending on the indicated waveform. In an example, the WTRU may be configured with multiple Pcmax. Each Pcmax (e.g., of the multiple Pcmax) may be used for a different waveform and may be applied depending on the waveform used for UL transmission. The WTRU may be configured to reset the TPC if a waveform switch occurs.

[0217] Waveform indication examples are provided herein. A waveform may be determined from a combined MAC CE and DCI. The WTRU may (e.g., may first) receive signaling such as a MAC CE indicating an operating mode and associated parameters for waveform switching. The WTRU may (e.g., may further) receive a DCI sent by the UL and determine an applicable waveform to send based on at least one field of the DCI. The interpretation of at least one field of the DCI depends on the operating mode and associated parameters received from the MAC CE. The WTRU may (e.g., may also) send a PUSCH from a configured grant and determine an applicable waveform based on at least one attribute or configuration aspect of the MAC CE and the configured grant.

[0218] In an example, the MAC CE may indicate an operating mode for the WTRU to determine the waveform based on legacy.

[0219] In an example, the MAC CE may indicate that at least one field of the DCI explicitly indicates an operating mode of a waveform. Such a field may be a new field or an existing field that is reused to indicate (e.g., additionally indicate) a waveform. The field may include a time domain resource allocation field or a modulation and coding scheme field. The possible values ​​of the field (e.g., each possible value) may indicate a waveform (e.g., in addition to other information indicated by the field).

[0220] In an example, the MAC CE may instruct the WTRU to determine the operating mode of the waveform from at least one attribute of the transmission (e.g., such as RA type, RB allocation, MCS, number of repetitions or slots, DMRS, number of layers, etc.). The MAC CE may (e.g., may also) include parameters to support this determination, such as at least one of: an MCS threshold, wherein if the MCS is below the threshold, the WTRU may determine the DFT-S-OFDM waveform type; a layer number threshold, wherein if the layer number is below the threshold, the WTRU may determine the DFT-S-OFDM waveform type; a frequency spacing to the edge of the carrier or BWP, wherein the frequency spacing is defined as the number of RBs between the highest RB allocated and the highest RB of the carrier or BWP, and between the lowest RB allocated and the lowest RB of the carrier or BWP, wherein if this frequency spacing is below the threshold, the WTRU may determine the DFT-S-OFDM waveform type. In an example, at least one threshold (e.g., as described herein) may be determined by the WTRU and signaled to the network. The WTRU may determine a maximum frequency separation such that the difference in Pcmax or PHR between transmissions using different waveforms is above a signaled threshold. The WTRU may report this maximum frequency separation to the network in a MAC CE such as an enhanced PHR.

[0221] An example of a waveform switching configuration for a configured grant is provided herein. A WTRU may receive a configuration applicable to a configured grant. The configuration may indicate whether the waveform type to be applied to the configured grant transmission is determined based on (e.g., based only on) the configuration and / or activation of the configured grant, or whether the configured grant transmission is determined from the most recently received dynamic signaling indicating a waveform change for a subsequent transmission (e.g., a DCI or MAC CE). In the latter case, the configured grant configuration may (e.g., may also) include a set of parameters applicable to possible waveform types (e.g., each possible waveform type). For example, the configuration may include first and second sets of parameters for a DFT-S-OFDM waveform type and a CP-OFDM waveform type, respectively. The configuration may include an information element having a value indicating the waveform type (or whether transform precoding is enabled or disabled) or indicating "flexible" in the case of setting the waveform type based on dynamic signaling. In an example, if the configuration includes first and second sets of parameters applicable to first and second waveform types, respectively, the WTRU may determine to set the waveform type based on dynamic signaling. If the WTRU initiates transmission of a transport block using a first waveform type and subsequently receives dynamic signaling indicating a second waveform type, the WTRU may apply rate matching (e.g., puncturing or repetition) to the transmission using the second waveform type to ensure that the same transport block size is associated with the first waveform type and the second waveform type.

[0222] An example of DCI interpretation is provided herein in the event that the DCI size does not match the DCI size applicable to the indicated waveform. Assuming that the DCI size depends on the most recently received dynamic signaling (such as a DCI indicating a waveform), the WTRU may decode the PDCCH. In an example, the WTRU may receive (e.g., first receive) a DCI indicating a DFT-S-OFDM waveform type. If the waveform type is a DFT-S-OFDM waveform type, the WTRU determines (e.g., after receiving or confirming a DCI indicating DFT-S-OFDM) that a subsequent PDCCH is decoded assuming that the size of the DCI is determined from the applicable field size. The WTRU may (e.g., may then) receive a second DCI indicating a CP-OFDM waveform type. At least one field of the second DCI may have a size smaller than the size applicable to the CP-OFDM waveform type. In an example, the field "precoding information and number of layers" may have a size smaller than the size obtained from the PUSCH configuration when the CP-OFDM waveform type is enabled. The WTRU may perform at least one of the following to determine the applicable information from the DCI field (for example, if the size of the field "precoding information and number of layers" is smaller than the size obtained from the PUSCH configuration when the CP-OFDM waveform type is enabled): starting from the table applicable to the CP-OFDM waveform type (transform precoder disabled), remove entries of the table until the size of the reduced table matches the number of values ​​that can be indicated from the field, thereby maintaining the same order for the surviving entries, where entries may be removed using a priority order based on the number of layers (for example, the highest number of layers is removed first); or using a table applicable to the DFT-S-OFDM waveform type (transform precoder enabled).

[0223] Although the above features and elements are described in particular combinations, each feature or element may be used alone without the other features and elements of the preferred embodiment, or in various combinations with or without the other features and elements.

[0224] Although the implementation described herein may consider 3GPP specific protocols, it should be understood that the implementation described herein is not limited to this scenario and is applicable to other wireless systems. For example, although the solution described herein considers LTE, LTE-A, New Radio (NR) or 5G specific protocols, it should be understood that the solution described herein is not limited to this scenario and is also applicable to other wireless systems.

[0225] The processes described above may be implemented in a computer program, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (sent via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as, but not limited to, built-in hard disks and removable disks), magneto-optical media, and / or optical media (such as compact disk (CD)-ROM disks and / or digital versatile disks (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), the WTRU comprising: A processor, the processor being configured to: receiving a first message, wherein the first message indicates that the cell supports dynamic waveform switching; selecting the cell based at least on the cell supporting dynamic waveform switching; sending a preamble to the cell, wherein the preamble indicates a capability of the WTRU to support dynamic waveform switching; receiving a second message from the cell, wherein the second message indicates a waveform type used to send a third message; as well as The third message is sent using the waveform type.

2. The WTRU of claim 1 , wherein the preamble transmission indicates the capability of the WTRU to support dynamic waveform switching via one of: a resource used for the preamble transmission, a preamble sequence, or a transmission opportunity for the preamble transmission.

3. The WTRU of claim 1 , wherein the selection of the cell is further based on a measurement result of the cell being below a threshold.

4. The WTRU of claim 1 , wherein the waveform type is a Direct Fourier Transform Spread Orthogonal Frequency Division Multiplexing (DFT-s-OFDM) waveform type.

5. The WTRU of claim 1 , wherein the cell is a second cell, the waveform type is a second waveform type, and the processor is further configured to: Prior to receiving the first message, communicating with a first cell using a first waveform type.

6. The WTRU of claim 5, wherein the second waveform type is a DFT-s-OFDM waveform type.

7. The WTRU of claim 1, wherein the third message is sent via a physical uplink shared channel (PUSCH).

8. The WTRU of claim 1, wherein the first message is received via a radio resource control (RRC) transmission or a system information block (SIB) transmission.

9. The WTRU of claim 1 , wherein: The first message is received from a first cell, and The cell is a second cell, wherein the second cell is one of a plurality of adjacent cells.

10. The WTRU of claim 9, wherein: One of the plurality of adjacent cells is a third cell that does not support dynamic waveform switching, A respective measurement result of each of the plurality of neighboring cells is below a threshold, and the selection of the second cell is further based on the third cell not supporting dynamic waveform switching.

11. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: receiving a first message, wherein the first message indicates that the cell supports dynamic waveform switching; selecting the cell based at least on the cell supporting dynamic waveform switching; sending a preamble to the cell, wherein the preamble indicates a capability of the WTRU to support dynamic waveform switching; receiving a second message from the cell, wherein the second message indicates a waveform type used to send a third message; as well as The third message is sent using the waveform type.

12. The method of claim 11, wherein the preamble transmission indicates the capability of the WTRU to support dynamic waveform switching via one of: a resource used for the preamble transmission, a preamble sequence, or a transmission opportunity for the preamble transmission.

13. The method of claim 11, wherein the selection of the cell is further based on a measurement result of the cell being below a threshold.

14. The method of claim 11, wherein the waveform type is a Direct Fourier Transform Spread Orthogonal Frequency Division Multiplexing (DFT-s-OFDM) waveform type.

15. The method according to claim 11, wherein the cell is a second cell, and the waveform type is a second waveform type, the method further comprising: Prior to receiving the first message, communicating with a first cell using a first waveform type.

Images