Adaptive Waveform Selection for Wireless Communications

Abstract

Systems, methods, and means for adaptive waveform selection for wireless communications are described herein. In an embodiment, a wireless transmit / receive unit (WTRU) may be initially configured for orthogonal frequency division multiplexing (OFDM). If a WTRU that may support dynamic waveform switching receives system information blocks (SIBs) from multiple cells, at least one of which supports dynamic waveform switching, the WTRU may prioritize initial access to the cell that supports dynamic waveform switching. If the WTRU supports dynamic waveform switching, the WTRU may transmit a physical uplink shared channel (RUSCH) in msg3 in a configured grant, which may be offset by a preconfigured number of slots with a waveform different from the preconfigured waveform type.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 327,640, filed April 5, 2022, U.S. Provisional Patent Application No. 63 / 395,395, filed August 5, 2022, and U.S. Provisional Patent Application No. 63 / 421,863, filed November 2, 2022, the disclosures of which are incorporated by reference herein in their entireties. [Background technology]

[0002] 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). The previous (conventional) generation of mobile communications RAT may be, for example, fourth generation (4G) long term evolution (LTE). Summary of the Invention

[0003] SUMMARY OF THE DISCLOSURE Described herein are systems, methods, and means for adaptive waveform selection for wireless communications.

[0004] 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., whether a second neighboring cell supports dynamic waveform switching). The first message may be received via a radio resource control (RRC) transmission or a system information block (SIB) transmission.

[0005] The WTRU may select a cell (e.g., a second cell) based on the cell supporting dynamic waveform switching. The WTRU may select a cell (e.g., a second cell) based (e.g., based on) a measurement (e.g., reference signal received power (RSRP)) of the cell (e.g., the second cell) falling below a threshold. The WTRU may be configured to transmit a preamble to the cell (e.g., to the second cell) indicated by the first message. The preamble transmission may indicate the WTRU's ability to support dynamic waveform switching. In an embodiment, the preamble transmission may indicate the WTRU's ability to support dynamic waveform switching via one of a resource used for the preamble transmission, a preamble sequence, or a transmission opportunity used for the preamble transmission.

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

[0007] 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) to use for transmitting a third message. The WTRU may transmit 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 transmit the third message may be switched from the 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., further used) to communicate with the first cell prior to receiving the first message. [Brief description of the drawings]

[0008] [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1 is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. [Figure 1C] FIG. 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1D]FIG. 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Diagram 2] 1 illustrates one example of reception of a scheduling PDCCH by a WTRU and a corresponding PUSCH. [Diagram 3] 1 illustrates one example of receiving waveform change instructions and WTRU behavior. [Figure 4] FIG. 1 illustrates an example PUSCH transmission after waveform switching. [Diagram 5] 1 illustrates one example of receiving waveform change instructions and WTRU behavior. [Figure 6] 1 illustrates an example of WTRU behavior when scheduled repetitions overlap with a switching window. [Figure 7] 1 illustrates an example of WTRU behavior when scheduled repetitions overlap with a switching window and repetition cancellation. [Figure 8] 1 illustrates an example of WTRU behavior when waveforms are switched midway through a PUSCH repetition. [Figure 9] 1 illustrates an example of WTRU behavior when waveforms are switched in the middle of a PUSCH repetition and transmission cancellation. [Figure 10] FIG. 1 illustrates an example of waveform switching and joint channel estimation. [Figure 11] FIG. 1 illustrates an example of waveform switching and joint channel estimation. [Figure 12] FIG. 13 illustrates an example of receiving a waveform modification instruction prior to setting a time window for joint channel estimation. [Figure 13] FIG. 13 illustrates an example of receiving a waveform modification instruction after time window setting for joint channel estimation. [Figure 14] FIG. 2 illustrates an embodiment of a four-step initial access random access channel (RACH) procedure. [Figure 15] A diagram showing one embodiment of a RACH procedure for two-step initial access. [Figure 16] FIG. 2 illustrates an example of an association between RACH occasions (Ros) and waveforms. [Figure 17] FIG. 2 illustrates an example of an association between RACH opportunities (Ros) and waveforms. [Figure 18] FIG. 1 illustrates an example of dynamic waveform switching. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0010] 1A, communications 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, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or “STA,” may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (loT) devices, watches or other wearable, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., for remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), consumer electronics devices, devices operating in commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

[0011] 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 station 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, etc. Although the base stations 114a, 114b are each depicted as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

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

[0014] More specifically, as noted above, the communications system 100 may be a multiple access system, but may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a and the WTRUs 102a, 102b, 102c in the RAN 104 / 113 may implement a radio technology, such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA may include communications protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

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

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

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

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

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

[0020] The RAN 104 / 113 may communicate with the CN 106 / 115, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as, for example, 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 high-level security functions such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may communicate directly or indirectly with other RANs employing the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

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

[0024] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuits (ASIC), a Field Programmable Gate Arrays (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0026] 1B 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.

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

[0028] The processor 118 of the WTRU 102 may be coupled to and may receive user-entered 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 non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown).

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

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

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

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

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

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

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

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

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

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

[0039] The SGW 164 may be connected to a 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.

[0040] 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 communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

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

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

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

[0044] When using an 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit a beacon 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 that is dynamically set via signaling. The primary channel may be the operating channel of the BSS, but may be used by STAs to establish a connection with the AP. In certain representative embodiments, for example, in an 802.11 system, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented. With CSMA / CA, STAs (e.g., all STAs), including the AP, may sense the primary channel. If the primary channel is sensed / detected 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.

[0045] A High Throughput (HT) STA may use a 40 MHz wide channel for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

[0046] A Very High Throughput (VHT) STA may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. A 40 MHz and / or 80 MHz channel may be formed by combining multiple adjacent 20 MHz channels. A 160 MHz channel may be formed by combining eight consecutive 20 MHz channels or by combining two non-adjacent 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data may pass through a segment parser that may split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing may be performed separately on each stream. The streams may be mapped to two 80 MHz channels and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed and the combined data may be sent to the Medium Access Control (MAC).

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

[0048] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be configured and / or limited by the STAs among all STAs operating in the BSS that support the smallest bandwidth operating mode. In an 802.11ah embodiment, the primary channel may be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) configuration may depend on the status of the primary channel. For example, if the primary channel is active due to a STA (that only supports the 1 MHz mode of operation) transmitting to the AP, the entire available frequency band may be considered active even though most of the frequency band may remain dormant and available.

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

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

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

[0052] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of different or scalable lengths (e.g., including different numbers of OFDM symbols and / or lasting different lengths of absolute time).

[0053] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing another RAN (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with and connect to a gNB 180a, 180b, 180c while also communicating with and connecting to another RAN, such as an eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0054] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

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

[0056] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may function as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. The network slices may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service utilizing the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services 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.

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

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

[0059] The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves 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 and / or wireless networks owned and / or operated by other service providers. In an embodiment, the WTRUs 102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

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

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

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

[0063] References herein to a timer may refer to determining a time or determining a period of time. References herein to a timer expiry may refer to determining that a time has occurred or that a period of time has expired. References herein to a timer may refer to a time, a period of time, tracking of a time, tracking of a period of time, 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, e.g., an earlier version / release of a technology (e.g., an earlier NR release) compared to a later version / release of the technology (e.g., a later NR release).

[0064] SUMMARY OF THE DISCLOSURE Described herein are systems, methods, and means for adaptive waveform selection in wireless communications.

[0065] 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., whether a second neighboring cell supports dynamic waveform switching). The first message may be received via a radio resource control (RRC) transmission or a system information block (SIB) transmission.

[0066] The WTRU may select a cell (e.g., a second cell) based on the cell supporting dynamic waveform switching. The WTRU may select a cell (e.g., a second cell) based (e.g., based on) a measurement (e.g., reference signal received power (RSRP)) of the cell (e.g., the second cell) falling below a threshold. The WTRU may be configured to transmit a preamble to the cell (e.g., to the second cell) indicated by the first message. The preamble transmission may indicate the WTRU's ability to support dynamic waveform switching. In an embodiment, the preamble transmission may indicate the WTRU's ability to support dynamic waveform switching via one of a resource used for the preamble transmission, a preamble sequence, or a transmission opportunity used for the preamble transmission.

[0067] The WTRU may be configured to prioritize one cell (e.g., a second cell) of the cells (e.g., neighboring cells indicated by the first message) over another cell (e.g., a third cell). The WTRU may prioritize a cell (e.g., the second cell) that supports dynamic waveform switching over another cell (e.g., a third cell) that does not support dynamic waveform switching (e.g., if the respective measurements of each of the second and third cells 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 (which may, for example, provide increased throughput).

[0068] 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) to use for transmitting a third message. The WTRU may transmit 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 transmit the third message may be switched from the 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., further used) to communicate with the first cell prior to receiving the first message.

[0069] In an embodiment, the waveform of the 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 embodiment, the WTRU may use either DFT-s-OFDM or OFDM for uplink transmission. In an embodiment herein, the OFDM waveform type may be a CP-OFDM waveform type. While OFDM may be compatible with single input single output (SISO) transmission or multiple input multiple output (MIMO) transmission, DFT-s-OFDM may be compatible with (e.g., only with) SISO transmission (e.g., in NR). With regard to PAPR performance, due to DFT spreading before OFDM modulation, DFT-s-OFDM may exhibit a lower PAPR than OFDM, which may be suitable for coverage-limited scenarios where high transmit power may be required for uplink transmission. There may be a trade-off between OFDM and DFT-s-OFDM (eg, a trade-off between throughput and coverage performance).

[0070] For UL transmission, UL transmit power may be limited, making optimal selection of the waveform that is important to maximize coverage or throughput. In an embodiment, for a WTRU located near the gNB, OFDM with MIMO may be configured. For a WTRU located far away from the gNB, DFT-s-OFDM with SISO may be configured. In an embodiment, the WTRU may be signaled to switch waveforms. In an embodiment (e.g., in a coverage-limited scenario), signaling from the network to switch waveforms may introduce signaling overhead (e.g., especially when the WTRU frequently comes and goes). In an embodiment (e.g., even 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 achieve communication (e.g., seamless communication).

[0071] A transmission using a DFT-s-OFDM waveform may be equivalent to a transmission with transform precoding enabled, and a transmission using an OFDM waveform or a CP-OFDM waveform may be equivalent to a transmission with transform precoding disabled.

[0072] Examples of multi-PHR transmission to assist with waveform switching may be provided herein. In an embodiment, 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 two or more (e.g., two) power headroom reports (PHRs) to the network (e.g., gNB). The second waveform type (e.g., OFDM, DFT-s-OFDM) may be a different or the same waveform as the first waveform. In an embodiment, the WTRU may be configured with an OFDM waveform type via RRC as the first waveform type. If the condition is met (e.g., the change in RSRP in the CSI-RS is above a threshold), the WTRU may return a PHR (e.g., two PHRs, one for OFDM and another for DFT-s-OFDM).

[0073] The WTRU may be preconfigured with more than two waveform types (e.g., one or more waveform types in addition to DFT-s-OFDM and OFDM). The WTRU may be configured with at least OFDM and DFT-s-OFDM (e.g., single carrier waveform types), Frequency Shift Keying (FSK), a combination of DFT-s-OFDM and OFDM, or waveform types different from DFT-s-OFDM or variants of OFDM. The WTRU may be provided with an ID for the waveform type (e.g., each waveform type). 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 at least a configuration for the default waveform semi-statically (e.g., RRC), broadcast (e.g., SIB), or dedicated signaling.

[0074] The calculation of the PHR for the second (e.g., unconfigured) waveform may be based on the resources (e.g., number of symbols / slots / frames / RBs) allocated for the first waveform. 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, e.g., a DFT-s-OFDM waveform type and a CP-OFDM waveform type as described herein). The WTRU may be configured to use the UL OFDM first (e.g., the CP-OFDM waveform type). If a trigger condition for transmitting the PHR for a waveform type (e.g., both waveform types) is met (e.g., a CSI-RS measurement (e.g., RSRP) is below a preconfigured threshold), the WTRU may decide to calculate the PHR for the DFT-s-OFDM based on the resources allocated to 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 (eg, later transmit) multiple PHRs (eg, both PHRs) to the network.

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

[0076] The PHR may deliver the power headroom and actual Pcmax that may be calibrated in the WTRU for the defined UL grant. A flag / indicator (e.g., other flags / indicators) may be (e.g., may also be) present for the P-MPR to signal the state of the SAR or the state of the MPE.

[0077] The PHR may have a significant impact on the Base Station (BS) scheduler. The BS scheduler may have knowledge (e.g., initial knowledge) of the maximum power reduction (MPR) table and the A-MPR table. The values ​​in the tables may represent the maximum power reduction allowed for 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 the actual values ​​from the WTRU, the BS scheduler may learn the WTRU capabilities in terms of power reduction and converge to an optimized scheduling process. The MPR difference between the considered waveform types (e.g., CP-OFDM and DFT-s-OFDM) may be on the order of 2 dB or more depending on the frequency range (FR1 or FR2) and modulation.

[0078] The PHR calculation may be referred to as a real number (e.g., actual PHR) when it is based on the UL grant. The UL grant may include an RB allocation and a Modulation and Coding Scheme (MCS). Based on the RB allocation and modulation, the WTRU may determine a Pcmax,c for a Component Carrier (CC), which is the maximum configured power that the WTRU may use under the current UL grant conditions. The power allocated at the physical layer may be required to be less than or equal to the determined Pcmax,c. If the power allocated at the physical layer exceeds the determined Pcmax,c, the WTRU may be requested to scale down its allocated power (e.g., the initially allocated power) until the Pcmax,c limit is respected. The Pcmax,c in the CC may take into account the MPR requirement, the A-MPR (an additional MPR that may be related to geographical protection of the band or another radio service), 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 proximity of a human body detection by the WTRU sensor. The P-MPR may affect the waveforms (e.g., both waveforms) equally (e.g., in the examples provided herein).

[0079] Pcmax,c may be the maximum set power of the CC. Pcmax,c may be a function of MPR, A-MPR, PpowerClass, Pemax (WTRU maximum power to 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 may be applied when body proximity is detected by WTRU sensors for SAR (FR1) and MPE (FR2). If applied, P-MPR may be signaled by a flag in the PHR. Spectrum Absorption Rate (SAR) may be a compliance limit of electromagnetic radiation per volume of human tissue (e.g., specific to FR1). MPE may be a compliance limit of electromagnetic radiation per surface area of ​​the human body (e.g., specific to FR2).

[0080] MPR, A-MPR, P-MPR can be intraband contiguous or interband in case of carrier aggregation. In case of intraband contiguous, MPR can be common for the whole bandwidth. In case of interband, MPR can be per band / CC (as CCs are in different bands). MPR, A-MPR, P-MPR can be applied per CG or per failure in case of dual connectivity.

[0081] Examples of conditions for a WTRU to transmit multiple PHRs may be provided. In an example, the WTRU may be preset with conditions that trigger the WTRU to transmit two or more PHRs (e.g., dual PHR, a PHR corresponding to each waveform, two PHRs corresponding to a first and second waveform) to the network if at least one of the following conditions is met: if the change in RSRP compared to the last time the WTRU measured a DL RS (e.g., CSI-RS, DM-RS) or SSB exceeds a pre-configured threshold over a specific amount of time measured in time units or slots / frames; if the RSRP of the DL-RS or SSB falls below or exceeds a pre-configured threshold; if the MPE exceeds a pre-configured threshold; if the amount of data in the BSR is above or below a pre-configured threshold and the dual PHR condition is met; if the WTRU receives an instruction from the network to report two or more PHRs or PHRs for a particular waveform PHR-O or PHR-D; if the PHR of the current waveform falls below X dB (e.g., X may be a configurable threshold as 0, 2, 3, or 4 dB); or if the calculated PHR difference between the current waveform and another waveform for at least one serving cell is greater than or exceeds X dB (where X may be a network configurable or fixed value).

[0082] If the condition of the change in RSRP compared to the last time the WTRU measured a DL RS (e.g., CSI-RS, DM-RS) or SSB exceeds a pre-configured threshold for a certain amount of time measured in time units or slots / flows, a prohibit timer may be set by the network to avoid flooding the network with multiple reports.

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

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

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

[0086] The dual PHR may take the form of a physical layer flag / indication if the calculated dual PHR condition set by the network is met. In an embodiment, if the dual PHR calculation indicates a power-limited situation and the ΔPHR between the waveforms of the current UL grant is greater than X dB, the dual PHR may take the form of a physical layer flag / indication if the calculated dual PHR condition set by the network is met. This indication may be sent by UCI in the PUSCH or PUCCH.

[0087] Examples of extended PHR formats for multiple waveforms may be provided herein. The WTRU may be configured to transmit a PHR report according to a new format (e.g., MAC CE) if dynamic waveform switching is configured for at least one serving cell. The report may include an indication of whether PHR information for 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 for a waveform type may be expressed in terms of a difference relative to a reference waveform type. The reference waveform type may be the waveform type used for the PUSCH (or SRS) of the actual PHR or the waveform type configured for the reference format of the virtual PHR. When the WTRU prepares the PHR, the WTRU may include PHR information of a waveform type different from the reference waveform type for the serving cell on (e.g., only on) the condition that the difference is higher than a threshold. The threshold may be predefined or configured by higher layers.

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

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

[0090] The dual PHR may be calculated for the PHR of the current waveform type and add the Δ (difference) of a second waveform type in the same UL grant. The Δ value may be a quantified value in the form of a look up table (LUT) or simply a flag / indicator that indicates that a different waveform type (e.g., a waveform type not currently being used) has a PHR better than a certain value (e.g., better than 2 dB).

[0091] The PHR triggered for waveform switching may be presented in a different format when triggered. For example, when a dual PHR is triggered, a specific flag for the dual PHR may be transmitted and (e.g., then) only the PHR associated with the waveform may be transmitted. The WTRU may transmit the actual PHR (e.g., actual alternate PHR) using the current mapping.

[0092] Provided herein are examples of PHRs that use assumptions for intra-carrier allocation or spectral shaping. The WTRU may report a PH applicable to a particular waveform under certain assumptions for PUSCH allocation in the frequency domain. Such a PH may be included in the PHR (e.g., in addition to a PH calculated using another solution or according to legacy). For example, the WTRU may apply at least one of the following assumptions even if they are not met by the actual PUSCH transmission used for the calculation of 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 of the PUSCH allocation is lower or higher than a threshold Z, or the PUSCH allocation is contiguous (e.g., possibly has the same total number of RBs as the allocation of the actual PUSCH transmission).

[0093] The assumptions and applicable values ​​of at least one of X, Y, and Z may be predefined or signaled by the RRC or MAC (e.g., as shown above). Such thresholds may be predefined or signaled by the RRC or MAC.

[0094] The WTRU may report upper and / or lower bounds on the frequency allocation of the PUSCH such that the difference in PH or Pcmax between the two waveform types is less than a threshold. The threshold and waveform type may be predefined or signaled by RRC or MAC. The WTRU may perform this reporting if requested by the network (e.g., as indicated in the MAC CE or DCI). The lower and upper bounds may be expressed in terms of RB index within the carrier, or in terms of the number of RBs between the applicable limit and the upper or lower edge of the carrier. In an embodiment (e.g., the latter case), the WTRU may report two values, X and Y. 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 embodiment, the WTRU may report a single value for both.

[0095] The WTRU may report the PH under the assumption that a spectral shaping technique such as frequency domain spectral shaping or peak reduction tone reservation is used. The WTRU may report this PH under the condition that the actual PUSCH transmission satisfies a certain condition. In an embodiment, the condition may be that the waveform type used for the actual PUSCH transmission is a DFT-S-OFDM waveform type.

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

[0097] An example of an L1 indication when the PH difference between the waveforms exceeds a threshold is provided herein. The WTRU may send an indication on L1, such as PUCCH or uplink control information, when a condition related to power headroom is met (e.g., this may have the advantage of quickly notifying the network when a change in waveform is appropriate).

[0098] The L1 indication may be transmitted using a scheduling request resource configured for this purpose using RRC signaling. The WTRU may follow the same procedure as for transmitting a scheduling request, except that cancellation of a pending SR is performed under conditions where a PHR or an extended PHR is included in the PUSCH transmission or where the PUSCH is transmitted using a specific waveform type (e.g., a DFT-S-OFDM waveform type).

[0099] The conditions for triggering transmission of the indication may include at least one of the following: the WTRU last transmitted a PUSCH using a particular waveform (e.g., a CP-OFDM waveform), the PH of the last transmitted PUSCH is below a threshold, the difference in PH or the difference in Pcmax between the PUSCH assumed to be transmitted under a first waveform type (e.g., a CP-OFDM waveform type) and the PUSCH assumed to be transmitted under a second waveform type (e.g., a DFT-S-OFDM waveform type) is higher than a threshold, or the path loss estimate is higher than a threshold or the path loss estimate has changed by more than a threshold since the last transmission of an L1 indication or PHR.

[0100] At least one trigger (eg, of the triggers listed above) may be used (eg, may also be used) for transmission of an extended PHR of multiple waveform types.

[0101] Examples of Carrier Aggregation (CA) and Dual Connectivity (DC) scenarios may be provided. In the intraband case, Dual PHR in a CC may trigger Dual PHR in the CC (e.g., all CCs). Dual PHR triggered in one CC may be considered in the CC that triggered Dual PHR (e.g., only in the CC), and the other PHR report may be based on the legacy format. Dual PHR may be a configurable report per CC or per Cell Group (CG). In the intraband case where dual Power Amplifiers (PAs) may be reported by the WTRU per CC or per CG, Dual PHR may be configurable as well.

[0102] In the inter-band case, Timing Advance Groups (TAGs) may be defined. In the inter-band case, the triggered dual PHR may be limited to CCs (e.g., active CCs) within the band, TAG, or CG. Full dual PHR may be triggered for (e.g., both) bands and may be a network configured report.

[0103] Examples of responses from the network to multiple PHRs may be provided. An indication associated with a grant type or PUSCH may be given. In an embodiment, the WTRU may receive a DCI or MAC-CE, which may include an indicator of which waveform to use. When the WTRU transmits a PHR to the network, the WTRU may receive an indicator. The indicator may be associated with a grant or a scheduled PUSCH. In an embodiment, the WTRU may receive an indication of a waveform associated with a configured grant (e.g., configured grant type 1 or 2, dynamic grant). In an embodiment, the WTRU may receive a scheduling DCI associated with a PUSCH transmitted by the WTRU. The DCI may include a waveform the WTRU may use for the associated PUSCH.

[0104] The network may send a waveform switch command to the WTRU without a PHR or dual PHR or (e.g., other) triggered indication from the WTRU. This may be relevant in a situation where the WTRU is using a DFT-s-OFDM waveform by default, is in good coverage (e.g., good UL SNR), the Buffer Status Report (BSR) indicates a significant amount of data in the UL, and UL MIMO may be a solution to improve UL throughput.

[0105] An example of reliably receiving a waveform switching command from the network is provided herein. In an example, the WTRU may receive an instruction to switch waveform types on 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 transmissions. Such an instruction may reduce the risk of false detection at the WTRU.

[0106] In an embodiment, a WTRU may be scheduled for an opportunity (e.g., slot number, symbol number, dynamic / configured grant) where the WTRU may expect to receive an indication (e.g., via a PDCCH / PDSCH) regarding 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 embodiment, the WTRU may be configured to use OFDM. The WTRU may receive an indication from the network that a PDCCH (e.g., the next PDCCH) that the WTRU receives 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 decide to use OFDM for UL transmission.

[0107] An indication in the form of a negative ACK (NACK) or an indication of retransmission after a PHR is transmitted (e.g., an implicit indication) is provided herein. The WTRU may decide to switch waveform types (e.g., when it receives a command to retransmit a PUSCH or PUCCH, or when the WTRU transmits a PHR (e.g., a dual PHR) to the network). In an embodiment, if the WTRU is configured for OFDM, the WTRU may transmit a PHR in OFDM and DFT-s-OFDM if one or more conditions (e.g., of the conditions described above) are met. If a PHR is transmitted to the network (e.g., after the PHR is transmitted to the network) and the WTRU decides to retransmit a PUSCH explicitly (e.g., by a command transmitted from the network) or implicitly (e.g., by not receiving an ACK from the network for a transmitted PUSCH), the WTRU may decide to switch to DFT-s-OFDM for retransmission.

[0108] In the case of CA or DC, the waveform switching instruction command may apply on CCs (e.g., all CCs) across active CCs in a CC (e.g., CCs in the same CG), TAG, or band (e.g., all bands). This waveform switching instruction may have information (e.g., additional information) about the CC to which it should be applied. In the case of CA or DC, 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 rest of the CCs in the CG, TAG, or Pcell / PSCell; include a specific instruction in the CC activation for the waveform to be used in the CC; include a CC activation with a waveform switching instruction that may switch the waveform of the entire CG, TAG (e.g., different from the active waveform with CG, TAG); and include a CC deactivation that may be bundled with a waveform switch (e.g., because more power may be available to the WTRU).

[0109] In an embodiment, the 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 code rate table. The code rate table may include code rates for multiple waveform types (e.g., two waveform types) and corresponding modulation and coding rates. The WTRU may measure whether the change in DL-RS (e.g., CSI-RS) and RSRP (e.g., compared to the last measurement occasion) is above a pre-configured threshold. If the WTRU is scheduled for a dynamic grant, the WTRU may decide to transmit multiple PHRs (e.g., two PHRs) to the network (e.g., one PHR for the first waveform type (e.g., OFDM) and another PHR for the second waveform type (e.g., DFTsOFDM)). The PHRs may be calculated based on the resources scheduled for the first waveform type. If the WTRU is not scheduled for a dynamic grant, the WTRU may return a PHR of the first waveform type. The WTRU may determine the waveform for the remaining UL transmission in the grant. If the WTRU receives a configuration of the waveform type over DCI from the network, the WTRU may decide to switch waveform type at the next transmission opportunity. Otherwise (e.g., if the WTRU does not receive a configuration of the waveform type over DCI from the network), the WTRU may complete the UL transmission of the grant with the first waveform type.

[0110] Examples of WTRU behavior upon (e.g., after) receiving a waveform switching instruction from the network are provided herein. Examples of ACK / NACK for waveform switching are provided herein. The BS and WTRU may agree on which waveform type is used by the WTRU for UL transmissions. This may be referred to as waveform state synchronization. Changes in waveform usage may be acknowledged if (e.g., after) commanded by the network. Network waveform switching command may be made via a MAC indication, an RRC indication, or a DCI indication.

[0111] The WTRU may send an ACK to the network (e.g., gNB) if the WTRU receives and / or correctly decodes an indication from the network via DCI or MAC-CE to switch waveform types or use the indicated waveform type. The WTRU may decide to switch to the indicated waveform type if the WTRU sends an ACK to the network.

[0112] For CA and DC where scheduling is per CC, the WTRU may switch waveforms if it accepts (e.g., only after acceptance) a waveform switching command from the BS and activates (e.g., thereafter) a second waveform type at a time that may be defined as at least as follows: the waveform switching activation time may be indicated by the network in the slot / frame by RRC configuration or may be dynamically indicated along with the waveform switching command, the waveform activation time may be set for the next UL grant on the CC (e.g., any CC) after the switching command Ack is verified, or in the case where the waveform switching indication is bundled with the CC activation command, the waveform switching time may be after a CC activation specified delay and may be set for the next valid UL grant of the CC.

[0113] An example of a time window for switching waveforms is provided herein. In an example, the WTRU may require a pre-configured time window to switch waveform types. The duration of the time window may depend on the WTRU capabilities of how fast the WTRU can switch waveform types. The time window may start from a specific time (e.g., one symbol, N symbols, one slot, M slots, one frame, K frames) after the PDCCH or PDSCH, which may contain an instruction to switch waveform types. The details of the time window (e.g., duration, start time / end time) may be included in the RRC or may be indicated in the DCI or MAC-CE. The duration of the window may be set semi-statically (e.g., via RRC) or dynamically (e.g., via DCI, MAC-CE).

[0114] Examples of WTRU behavior when a waveform switch command is received after a UL transmission is scheduled are provided herein. Examples of WTRU behavior when a waveform switch indication is received after scheduling a PDCCH are provided. In an example, the WTRU may decide to transmit a PUSCH after switching waveform types based on at least one of the following criteria: whether the PUSCH is scheduled before the WTRU receives an indicator over the PDCCH / PDSCH from the network, whether the scheduled PUSCH overlaps with a time window in which the WTRU is expected to switch waveforms while it is switching waveforms, or WTRU capabilities (e.g., whether the WTRU can transmit a PUSCH if the corresponding scheduling PDCCH / PDSCH is received before the waveform change indication).

[0115] In an embodiment, the WTRU may not transmit a PUSCH or PUCCH (e.g., during the window), so the WTRU may switch waveform types. The WTRU may transmit a PUSCH or PUCCH during the time window, but may use the previously configured waveform type. In an embodiment, 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 use OFDM to transmit a PUSCH or PUCCH during the time window. The WTRU may use DFT-s-OFDM to transmit a PUSCH or PUCCH (e.g., after the time window).

[0116] Depending on the 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 transmit a PUSCH or PUCCH scheduled by a PDCCH or PDSCH received during the time window. Depending on the capabilities, the WTRU may be expected to process a scheduled PDSCH or PDCCH received during the time window such that the WTRU can transmit the scheduled PUSCH or PUCCH after the waveform type is switched (e.g., after the end of the time window). In an embodiment, the WTRU may drop a scheduled PUSCH or PUCCH that was scheduled before receiving an instruction to switch the time window.

[0117] 2 illustrates one example of reception of a scheduling PDCCH by a WTRU and a corresponding PUSCH, where the scheduling PDCCH and a corresponding PUSCH are shown, and the PDCCH may include timings at which the WTRU may transmit the PUSCH.

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

[0119] FIG. 3 illustrates an example of receiving a waveform change instruction and WTRU behavior. In FIG. 3, the WTRU behavior is illustrated when the WTRU receives a waveform change instruction after the scheduling PDCCH. If the waveform change instruction is received after the scheduling PDCCH, the WTRU may decide to cancel the scheduled PUSCH transmission after the WTRU completes the waveform switch (e.g., because the PUSCH is scheduled based on the previously configured waveform). In FIG. 3, the WTRU may start a time window to switch waveforms N slots after the reception of the PDCCH, which may include an instruction to switch waveforms.

[0120] 4 illustrates an example of a PUSCH transmission after a waveform switch. As shown in FIG 4, the WTRU may determine to transmit a PUSCH if a PUSCH is scheduled after the WTRU switches waveforms.

[0121] 5 illustrates an example of receiving a waveform change instruction and WTRU behavior. In an embodiment, the WTRU may decide to transmit a scheduled PUSCH before receiving a waveform change instruction. The WTRU may decide to transmit a PUSCH if at least one of the following conditions is satisfied: the WTRU is capable of transmitting the scheduled PUSCH in a different waveform, the resources (e.g., number of symbols, number of slots, number of RBs, number of resource elements (REs)) of the scheduled PUSCH remain the same across different waveforms (e.g., PUSCH occupies the same time / frequency resources for OFDM and DFT-s-OFDM), or the parameters (e.g., MCS) of the scheduled PUSCH are supported by the switched waveform.

[0122] FIG. 6 illustrates an example of WTRU behavior when a scheduled repetition overlaps with a switching window. The WTRU may decide to cancel the transmission of a PUSCH that overlaps with the window for changing waveforms. In an embodiment (e.g., as shown in FIG. 6), the WTRU may schedule four PUSCH repetitions by the scheduling PDCCH. The first PUSCH in the four repetitions (e.g., only the first PUSCH) may be scheduled by the scheduling PDCCH. The WTRU may decide (e.g., in such a case) when to transmit the rest of the repetitions (e.g., PUSCH#2, PUSCH#3, and PUSCH#4 in FIG. 6). When the repetitions are scheduled (e.g., after the repetitions are scheduled), the WTRU may receive a PDCCH indicating to switch waveforms. If the time window overlaps with one of the repetitions (e.g., PUSCH), the WTRU may cancel the transmission of the PUSCH (e.g., PUSCH#1 in the embodiment shown in FIG. 6) that overlaps with the window.

[0123] 7 illustrates an example of a WTRU behavior when scheduled repetitions overlap a switching window and cancellation of repetitions. The WTRU may decide to cancel transmissions of PUSCH repetitions that overlap a window for changing waveforms and PUSCH repetitions that do not overlap the window (e.g., as shown in FIG. 7).

[0124] Examples relating to UL repetitions may include repetitions of PUSCH or PUCCH. The WTRU may decide to switch waveform types and complete transmission of the repetitions using the switched waveform type. In an example (e.g., as shown in FIG. 7), the WTRU may receive an instruction to switch waveform types after the WTRU transmits two of the four scheduled repetitions. Because the time window for switching waveform types may not overlap with the PUSCH repetition transmission opportunities, the WTRU may decide to use the switched waveform type to transmit Repetition #3 and Repetition #4.

[0125] FIG. 8 illustrates an example of WTRU behavior when a waveform is switched midway through a PUSCH repetition. The WTRU may decide to cancel the transmission of a repetition after receiving a command to switch waveform types. As shown in FIG. 8, the WTRU may receive an instruction to switch waveform types after the WTRU transmits two of the four scheduled repetitions. Even if the time window for switching waveform types does not overlap with the PUSCH repetition transmission opportunities, the WTRU may decide to cancel the transmission of repetitions #3 and #4 with the switched waveform. In an embodiment, if the WTRU receives an instruction to switch waveform types midway through a repetition, the WTRU may be configured to cancel the transmission of the repetition. In an embodiment, whether the WTRU continues to complete a transmission after a waveform switch (e.g., as shown in FIG. 7) or cancels the transmission (e.g., as shown in FIG. 8) may depend on the WTRU capabilities and / or settings from the network.

[0126] 9 illustrates an example of WTRU behavior when waveforms are switched midway through a PUSCH repetition and transmission cancellation. If the WTRU receives a DCI or MAC-CE before the WTRU completes the PUSCH repetition, the WTRU may decide to switch to the indicated waveform type before the WTRU completes the PUSCH repetition.

[0127] An example of WTRU behavior of waveform switching during joint channel estimation may be provided. Timing for scheduled PUSCH to maintain phase / power continuity / consistency may be provided.

[0128] FIG. 10 illustrates an example of waveform switching and joint channel estimation. The WTRU may be configured to maintain phase continuity and power consistency across PUSCH repetitions (e.g., such that joint channel estimation may be performed by the network). The WTRU may (e.g., in such a case) determine (e.g., may need to determine) an interval within which the WTRU may (e.g., may need to) perform continuity maintenance and consistency maintenance. As shown in FIG. 10, the WTRU may be configured by the network to maintain phase continuity and power consistency across PUSCH repetitions. If the WTRU receives an instruction to switch waveforms in a configured time window, the WTRU may determine to create a window (e.g., an actual window) to maintain phase continuity and power consistency if (e.g., after) the WTRU completes the waveform switch.

[0129] FIG. 11 illustrates an example of waveform switching and joint channel estimation. As shown in FIG. 11, the WTRU may receive a transmission schedule and a waveform switching indication for PUSCH repetitions in the same PDCCH. From the same PDCCH, the WTRU may determine the timing and duration for switching waveform types (e.g., indicated by "window for changing waveform" in FIG. 11). The WTRU may determine to create a window (e.g., two real windows) before or after switching waveform types while maintaining phase continuity and power consistency within the real window (e.g., each real window). Phase continuity and power consistency may not be guaranteed between real windows (e.g., phase continuity and power consistency between PUSCH#2 and PUSCH#3 may not be achieved).

[0130] Timing examples for phase / power continuity / consistency maintenance related settings are provided herein. In an example, the WTRU may receive, via RRC, joint channel estimation related settings for performing phase / power continuity / consistency maintenance (e.g., duration, start / end time for maintaining power consistency and / or phase continuity).

[0131] FIG. 12 illustrates an example of receiving a waveform change instruction before a time window configuration for joint channel estimation. If the WTRU receives an instruction to switch waveform types from the network before receiving a configuration related to joint channel estimation, the WTRU may determine to maintain phase continuity and power consistency for the PUSCH or PUCCH with the switched waveform type (e.g., the WTRU may be expected to maintain phase continuity and power consistency). As shown in FIG. 12, a PDCCH for setting the time window may be received by the WTRU after the waveform change instruction is received by the WTRU. The WTRU may maintain continuity and power consistency of the PUSCH repetition or PUSCH repetitions (e.g., as shown in FIG. 12) in the configured time window.

[0132] FIG. 13 is a diagram illustrating an example of receiving a waveform change instruction after setting a time window for joint channel estimation. After the WTRU receives RRC settings related to joint channel estimation, if the WTRU receives an instruction to switch waveforms, the WTRU may decide to cancel maintaining phase continuity and power consistency of the switched waveform for the scheduled PUSCH or PUCCH. In an example, the WTRU may receive a waveform change instruction within the boundary from the start of a set time window in which the WTRU may be expected to maintain phase continuity and power consistency over PUSCH / PUCCH repetitions. As shown in FIG. 13, the PDCCH for the waveform instruction and the corresponding window for changing the waveform may end M slots away from the start of the set window #1. If the boundary is B slots and M < B, the WTRU may decide to cancel maintaining phase continuity and power consistency within the set window. If the boundary is B slots and M < B, the WTRU may decide to cancel PUSCH transmission. After the WTRU receives RRC settings related to joint channel estimation, if the WTRU receives an instruction to switch waveform types, the WTRU may decide to cancel maintaining phase continuity and power consistency within the set window.

[0133] Examples of waveform switching application delays in the case of repetitions and / or joint channel estimation are provided herein. In an example, the WTRU may delay application of the waveform switching command until the end of a protected window defined by a set of PUSCH repetitions and / or an actual or nominal time window in order to maintain phase and / or power consistency. The protected time window may be defined by at least one of the following: between the start of the first repetition of the PUSCH (or the last symbol time of the PDCCH indicating a set of PUSCH repetitions) and the end of the last repetition of the PUSCH, or an actual or nominal time window in 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 transmissions 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 it 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).

[0134] The earliest application time may correspond to a delay after the reception of the last symbol of the PDCCH indicating the waveform change or after the transmission of the first or last symbol of the PUCCH or PUSCH containing the corresponding HARQ-ACK. The delay may be predefined or configured by higher layers.

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

[0136] For a WTRU configured with a timer that starts when the WTRU switches waveform types, the timer may start at the start of a PUSCH that the WTRU transmits with the switched waveform. The timer may start when the WTRU uses a PDSCH / PDCCH, which may include an instruction to switch waveform types. 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 was OFDM and a timer associated with the switched waveform type (e.g., DFT-s-OFDM) expires, the WTRU may switch back to OFDM.

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

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

[0139] If the WTRU determines to switch back to the previously configured / default waveform type when the switched waveform associated with the grant and the grant is terminated or expires, the WTRU may receive instructions from the network to switch waveform types and for the WTRU to continue using the waveform of the given / scheduled / allowed grant. In an embodiment, the WTRU may be configured with OFDM for UL transmission. The WTRU may receive a PDCCH from the network that may grant the WTRU a dynamic grant. The WTRU may receive (e.g., further receive) an instruction to switch to DFT-s-OFDM for the dynamic grant. When the dynamic grant is terminated or expires or expires, the WTRU may determine to switch back to the previously configured / default waveform type (e.g., OFDM).

[0140] Examples of whether to switch back to a default waveform type may be provided. In an example, if the WTRU receives an instruction from the network to change the waveform type, the WTRU may decide 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 be initially configured with OFDM. If the WTRU receives an instruction from the network (e.g., via PDCCH) to switch the waveform to DFT-s-OFDM, the WTRU may decide to continue using DFT-s-OFDM for UL transmissions until the WTRU receives a configuration or instruction to switch back to OFDM.

[0141] An example of waveform dependency on a TCI state instance or pool is provided herein. In an example, the WTRU may determine a PUSCH repetition or a waveform applicable to the PUSCH repetition based on a Transmission Configuration Indication (TCI) state, a TCI state instance, or a TCI state pool applicable to the transmission. The WTRU may be indicated with 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 perform (e.g., may then perform) a transmission of a set of PUSCH repetitions, where the PUSCH repetitions (e.g., each PUSCH repetition) may be associated with the first (or second) TCI state instance. Such transmission of the set of PUSCH repetitions may be indicated by a third DCI or may be configured by a higher layer as a configured grant. The indication or configuration may indicate a mapping between the PUSCH repetitions (e.g., each PUSCH repetition) and an associated TCI state instance. The WTRU may transmit (eg, may then transmit) a PUSCH using the first (second) waveform of the PUSCH repetition associated with the first (or second) TCI state instance.

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

[0143] A WTRU may determine that a cell supports waveform switching before accessing / camping on a cell. The WTRU may determine that a cell supports waveform switching using a SIB message broadcast from the cell. 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 embodiment, an RRC CONNECTED WTRU may receive from its serving cell a set of waveforms supported by neighbor cells. In an embodiment, the WTRU may be configured to associate a cell ID with a set of waveforms. The WTRU may be pre-configured with a mapping between cell IDs and sets of waveforms and / or waveform switching capabilities.

[0144] The WTRU may determine that a cell supports waveform switching / multiple waveforms based on the RACH resource configuration. In an embodiment, the WTRU may determine that a cell supports multiple waveforms (e.g., two waveforms) and / or waveform switching if the cell's RACH configuration includes PRACH formats of different waveforms. A PRACH format may be associated with a particular 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 partitioning of the PRACH resources and the associated waveforms with a subset of the PRACH resources. A subset of RACH opportunities may be associated with different waveform types (e.g., OFDM and DFT-s-OFDM). A BWP or band may be associated with different waveform types (e.g., band #1 to OFDM and band #2 to DFT-s-OFDM).

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

[0146] With regard to the 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). With regard to the WTRU's capabilities, the WTRU may select a cell based on which waveforms the WTRU can use / support. With regard to the cell's waveform / waveform switching capabilities (or indications), the WTRU may select a cell based on the cell's measured RSRP and supported waveforms / switches (e.g., as shown in FIG. 18). With regard to cell ID, if the WTRU determines that a group of cells have the same waveform / waveform switching capabilities or indications, the WTRU may prioritize the cells based on their cell ID. In an embodiment, the WTRU may select a cell with a smaller Cell ID value. With regard to the cell's bandwidth, the WTRU may prioritize a cell with a larger bandwidth over a cell with a smaller bandwidth. With regard to licensed or unlicensed cells, the WTRU may prioritize a cell with unlicensed spectrum over a cell with licensed spectrum.

[0147] In an example, prior to 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., via an RRC transmission or a SIB transmission) from a cell (e.g., from a first cell) (e.g., as shown in FIG. 18). The first message may indicate whether a cell (e.g., a neighboring cell) supports dynamic waveform switching (e.g., whether a second one of the neighboring cells supports dynamic waveform switching, as shown in FIG. 18). If the first message (e.g., a SIB transmission) includes an indication that the cell (e.g., the second cell) supports dynamic waveform switching, the WTRU may determine to prioritize establishing initial access (e.g., as shown in FIG. 18) with the second cell over a cell (e.g., a third cell) that does not support dynamic waveform switching, and in some examples, the decision to prioritize establishing initial access may further be based on a respective measurement value of each of the neighboring cells being below a threshold, as described herein (e.g., as shown in FIG. 18). Such prioritization may be achieved by applying an offset to the RSRP or RSRQ measurements of a cell if the WTRU supports a particular waveform type or switching between waveform types. The cell may be a serving cell or a neighboring cell. The offset applicable to a 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 for neighboring cells (e.g., all neighboring cells) for which a waveform or waveform switching is indicated.

[0148] While in the RRC_CONNECTED state, the WTRU may receive a configuration from the network indicating resources to be used for UL transmission to dynamically switch waveforms. Examples of such resources may include carrier components, bandwidth parts (BWPs), and / or bands. The WTRU may be configured to initiate a random access procedure in multiple cells and select a cell based on the waveform switching configuration received in the random access response. In an example, the WTRU may initiate a random access (RA) procedure in two cells (cell 1 and cell 2). The WTRU may receive a first random access response (RAR) from cell 1 indicating single waveform support or no support for waveform switching. The WTRU may receive (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 for cell 1.

[0149] An example of data selection and multiplexing based on a waveform associated with an UL grant may be provided. The WTRU may be configured by higher layers (e.g., RRC signaling) or may be predefined with 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 a transmission of data (e.g., an initial transmission), the WTRU may determine an applicable waveform type. The WTRU MAC may multiplex UL data from (e.g., only from) an LCH configured with a waveform (e.g., part of a logical channel prioritization procedure (LCP)) of the UL grant. The WTRU may be configured or predefined with an association between a waveform type and a priority index. The WTRU may determine the waveform type associated with the grant from a signaled priority index associated with the grant. The WTRU MAC may multiplex UL data from (e.g., only from) an LCH configured with a priority index associated with the waveform of the UL grant.

[0150] The WTRU may be configured by higher layers (e.g., RRC signaling) or the association between a particular MAC CE or MAC CE format and one or more applicable waveforms may be predefined. The WTRU may multiplex a PHR MAC CE format that is associated with a particular waveform scheme (e.g., DFT-s-OFDM) and / or reflects the actual PHR if (e.g., only if) the grant into which the MAC CE is multiplexed is of that waveform type.

[0151] Examples of waveform determination based on HARQ process ID or grant type are provided herein. The WTRU may be configured (e.g., by 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-12 and waveform B (e.g., OFDM) may be associated with HARQ processes 13-15. When receiving an UL grant for transmission, the WTRU may determine the waveform to use for UL transmission of the grant from the associated HARQ process ID.

[0152] The WTRU may have a configured or predefined association between grant types and waveform types. The WTRU may determine the waveform type to use for transmitting a UL grant from whether the grant is a configured grant type 1, a configured grant type 2, a dynamic grant, a msg3 grant, a msgA grant, or a msg5 grant. Such an association may be configured or specified.

[0153] The WTRU may receive an indication associating a waveform with the grant. In an embodiment, the WTRU may receive an indication to switch the waveform type of a dynamic grant scheduled for the WTRU. The indication may be included in the PDCCH or PDSCH. Based on the indication, the WTRU may decide to switch the waveform type when the grant is scheduled / activated or configured.

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

[0155] FIG. 14 illustrates an example of a RACH procedure for four-step initial access. FIG. 15 illustrates an example of a RACH procedure for two-step initial access. To dynamically switch waveforms, hardware in the WTRU may be required that may allow for rapid switching between waveform types (e.g., between DFT-s-OFDM and OFDM). During the RRC_CONNECTED state, the WTRU may send WTRU capability information (e.g., the WTRU may be able to directly switch waveforms) to the network. The WTRU may need to indicate the capability to dynamically switch waveforms during initial access because the network may not have the WTRU capability information before initial access is successfully established.

[0156] The WTRU may initiate initial access that may allow dynamic waveform switching in at least one of the following configurations: when the WTRU transmits a preamble on a transmission opportunity (e.g., a RACH opportunity, which may be defined by time and / or frequency resources) used for preamble transmission, which may be specified to indicate that the WTRU can support dynamic waveform switching (e.g., as shown in FIG. 18), when the WTRU transmits a preamble over resources used for preamble transmission, when the WTRU does not explicitly indicate capability information, or when the WTRU transmits a preamble over a preamble sequence associated with a waveform that the WTRU is requesting to use for msg3 / msg5 / general PUSCH transmission.

[0157] If the WTRU does not explicitly indicate capability information, such a situation may occur when the network does not have enough time and / or frequency resources to allocate a RACH opportunity for the WTRU to indicate its ability to dynamically switch waveforms. The WTRU may transmit a preamble (e.g., in this case) on a RACH opportunity that may be used for existing purposes (e.g., to request msg3 repetition, extend coverage, indicate WTRU capability for small data transmission). For a WTRU transmitting a preamble sequence associated with a waveform type that the WTRU is requesting to use for msg3 / msg5 / generic PUSCH transmission, the parameters of the sequence may be broadcast by the network or transmitted in dedicated signaling. The WTRU may decide to transmit a preamble sequence to request a waveform type if the waveform type has been preconfigured by the network before the WTRU establishes initial access. If the network receives the preamble (e.g., in the examples herein), the network may determine that the WTRU is capable of dynamically switching waveforms. The network may not know whether the WTRU can dynamically switch waveforms (e.g., in embodiments herein where the WTRU has not indicated its ability to dynamically switch waveforms). In embodiments, the WTRU may include its capability information (e.g., can directly switch waveforms) in msg3 or msgA.

[0158] An example of how the default waveform type is set 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 from the network, the WTRU may decide to use a predefined waveform type (e.g., OFDM).

[0159] Examples of switching priorities / when a WTRU is instructed to switch may be provided. If a 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 regarding a list of priorities for switching waveform types. In an example, the WTRU may be preconfigured with OFDM with QPSK, DFT-s-OFDM with QPSK, and DFT-s-OFDM with π / 2 BPSK. The WTRU may receive a priority list from the network indicating the order of priority: OFDM with QPSK, DFT-s-OFDM with QPSK, DFT-s-OFDM with π / 2 BSPK, where OFDM with QPSK may be the first waveform type (e.g., the default waveform type) and MCS. If the WTRU decides to switch waveform types from a first waveform type and MCS, the WTRU may decide to switch to a second waveform type (e.g., DFT-s-OFDM) with QPSK according to a priority list received from the network. The priority list may be broadcast or may be sent by the network in dedicated signaling. The WTRU may configure the list while the WTRU was in RRC_CONNECTED state and may save the configuration when the WTRU goes to IDLE or INACTIVE state.

[0160] The WTRU may only be configured with a list of waveform types (e.g., two waveform types). When the WTRU decides to switch waveform types, the WTRU may switch to a waveform type that the WTRU is not using for UL transmission.

[0161] The WTRU may receive an instruction to switch waveform types in msg2 or msg4 (e.g., msg2 or msg4 may be the second message as shown in FIG. 18). If the WTRU indicates a request to switch waveform types in msg1, the WTRU may receive an instruction from the network to switch waveform types in msg2. If the WTRU includes the capability to dynamically switch waveforms, the WTRU may receive an instruction from the network to switch waveform types in msg4.

[0162] An example of WTRU behavior for msg3 may be provided: If the network does not allocate a RACH opportunity for dynamic waveform switching indication, the WTRU may decide to do at least one of the following: Depending on the condition (e.g., the RSRP of SSB below a pre-configured threshold), the WTRU may decide to switch waveform types from the default waveform type for msg3 transmission; if msg2 (e.g., RAR) includes a grant offset (e.g., number of slots, number of frames, number of symbols) and the WTRU decides to switch waveform types from the default waveform type, the WTRU may transmit msg3 with a grant offset from the grant set in msg2; if msg2 (e.g., RAR) includes a fallback RAR and the WTRU decides to switch waveform types from the default waveform type, the WTRU may transmit msg3 with a grant offset by a pre-configured offset value from the grant set in msg2 (e.g., the WTRU may obtain the offset value from a broadcast or in dedicated signaling sent from the network); or, if pre-configured by the network, the WTRU may monitor two or more search spaces for an RAR indicating to switch waveform types for msg3 repetitions. Based on the quality of the preamble (e.g., RSRP), the network may decide to transmit the RAR within the allocated search space to set the msg3 transmission parameters (e.g., waveform, grant).

[0163] The WTRU may determine the default waveform type (e.g., OFDM) to use during initial access based on instructions received in broadcast information (e.g., SIB) from the network, dedicated signaling (RRC (re)configuration), or predefined.

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

[0165] 16-17 show examples of associations between ROs and waveforms. As shown in FIG. 16, a WTRU may request OFDM by transmitting a preamble on RO#1. A subset of ROs may correspond to different SSBs, and the WTRU may indicate the waveform type that the WTRU requests by transmitting a preamble on the associated RO. The subset of ROs may correspond to (e.g., correspond to) SSBs on which the WTRU may measure RSRP above a preconfigured threshold. The RO (e.g., each RO) may indicate to the network the waveform type that the WTRU desires and the spatial direction and / or width of the SSBs on which the WTRU observes a sufficiently large RSRP.

[0166] Examples of waveform capability indications in msg1 may be provided. The WTRU may indicate (e.g., implicitly indicate) a capability associated with supporting dynamic waveform switching (e.g., between DFT-s-OFDM and OFDM) via msg1 PRACH resource selection. The WTRU may indicate this capability via msg1 selection in a subset (e.g., only the subset) of RRC states (e.g., RRC IDLE and / or RRC inactive mode). The WTRU may decide to transmit a PRACH sequence to request a particular waveform (e.g., on an RO associated with an indication of such capability) if the waveform type has been preconfigured by the network (e.g., before the WTRU establishes initial access / RA).

[0167] The WTRU may be configured (e.g., by broadcast or dedicated signaling) with a partition of PRACH resources (e.g., a subset of preamble and / or RO) to be selected by the WTRU during a RA procedure (e.g., as part of initial access). The partition of PRACH resources may be configured to indicate a capability to support more than one waveform type, a non-default waveform, and / or waveform switching. In an embodiment, the WTRU may use a partition configured for an indication of capability of msg3 repetition and / or a msg1 PRACH resource partition (e.g., already configured for purposes of indicating coverage limitation) that includes at least an indication of a coverage level (e.g., a measurement value (e.g., RSRP) that is below a configured threshold for msg3 repetition) to indicate (e.g., also indicate) a capability of waveform switching. The WTRU may be configured or predefined to select a msg1 or msgA PRACH resource partition (e.g., already configured) for the purpose of indicating small data transmission (SDT) if the WTRU is capable of multiple waveform types and / or waveform switching. The WTRU may select a particular partition (e.g., one associated with an indication of waveform capability switching, coverage limitation, or SDT) if the measured RSRP is below a threshold, otherwise (e.g., if the measured RSRP is not below a threshold), the WTRU may select a legacy RACH resource.

[0168] If the WTRU is capable of waveform switching and / or selects an RO partition associated with indicating a waveform (e.g., an alternative waveform) or indicating multiple waveform capability, parameters (e.g., alternative parameters) to use for msg1 transmission or retransmission purposes may be set. Such parameters may be set by broadcast or dedicated signaling. Specific parameters (e.g., alternative parameters) may include an identified transmit power, an identified tx spatial filter, a number of msg1 repetitions, an identified backoff, an identified power ramping step, a different Zadoff Chu root sequence (or logical root sequence index), or a different sequence shift set (e.g., a different Ncs). The WTRU may apply such identified parameters when initiating a RA on an RO associated with an indication of waveform switching capability and / or when the preamble is transmitted using a different waveform type.

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

[0170] Examples of waveform capability indications in the PUSCH payload (e.g., in msgA or msg3) may be provided. The WTRU may include its capability information (e.g., support for multiple or different / non-default waveforms, capable of switching waveforms) in a portion of the payload msg3, msgA, or in a portion of a small data PDU multiplexed with the RA-SDT or CG-SDT resource. The WTRU may be configured with a partition of CG-SDT resources that may use different waveform types (e.g., non-default waveform types) for PUSCH SDT transmissions. The WTRU may multiplex a predefined or identified DMRS into the msg3 or msgA PUSCH transmission to indicate capability of supporting different waveform types (e.g., non-default waveform types), if different waveform types (e.g., non-default waveform types) are possible, if msg3 is transmitted using a different waveform type (e.g., non-default waveform type), and / or if different waveform types (e.g., non-default waveform types) are possible. The DMRS may be generated as a function of the signaled temporary C-RNTI or RA-RNTI.

[0171] Examples of signaling waveform type in msg2 or msgB are provided herein. Examples of indicating waveform capability via grant selection / transmission are provided herein. If a WTRU supports multiple waveform type capabilities and such capabilities are not indicated as part of msg1 / msgA, the network cannot know if the WTRU can dynamically switch waveforms by merely receiving msg1 / msgA. A WTRU may receive grants supporting more than one waveform type, multiple grant types for different waveform types in the same RAR, and / or multiple RARs supporting msg3 grants of different waveform types.

[0172] The WTRU may receive the legacy RAR format, but may interpret the UL grant parameters differently if the WTRU is capable of waveform switching. 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 WTRU's waveform capabilities. The WTRU may apply a predefined or configured shift or offset in the time 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, number of frames, number of symbols) is applied, and if the WTRU decides to switch waveforms from a first waveform type (e.g., a default waveform type), the WTRU may transmit msg3 using a grant that is 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 applicable by the WTRU for (e.g., only for) a fallback RAR (e.g., msg2 received following transmission of msgA) or after several retransmission attempts of msg1 or msg3. The WTRU may select a RACH partition associated with an indication of coverage extension or a different waveform type (e.g., a non-default waveform type) when reverting to a 4-step RA following N configured failed attempts for a 2-step RA.

[0173] In an embodiment, a WTRU capable of multiple waveform types may monitor RARs for 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 that configured for a legacy WTRU) for reception of an RAR that may include an UL grant. The UL grant may be transmitted using a different waveform (e.g., a non-default waveform (e.g., DFT-s-OFDM)). Such a search space may be a common search space (e.g., for WTRUs capable of waveform switching) or a WTRU-specific search space.

[0174] The WTRU may monitor an RAR on a RA-RNTI (e.g., an additional RAR) that is separate from the RA-RNTI used for legacy WTRUs for the selected RO. In an embodiment, the WTRU may apply an offset to the determined RA-RNTI or msgB-RNTI if multiple waveforms are possible. The WTRU may monitor such a search space (e.g., an additional search space) and / or RA-RNTI if (e.g., only if) configured by the network or if the measured channel conditions are below a configured threshold. If the WTRU receives multiple msg3 grants and / or RARs, the WTRU may select a grant or select to decode an 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. The WTRU may transmit using the signaled (e.g., all signaled) msg3 grant associated with the WTRU's RA-RNTI and may repeat the msg3 content 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 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 a subspace, the WTRU may use a different waveform type (e.g., a non-default waveform type) for the transmission of msg3 and for UL transmissions (e.g., subsequent UL transmissions).

[0175] The WTRU may receive an indication to switch waveform types (e.g., to a different / non-default waveform type) in msg2 (e.g., as shown in FIG. 18). In an embodiment, the WTRU may receive an indication to switch waveform types from the network in msg2 if the WTRU indicates a request to switch waveforms in msg1 (e.g., by selecting an RA partition associated with such capability). The indication may be conveyed 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 subheader, a reserved bit in the MAC RAR sub-PDU, or an indication in the PDCCH signaling that scheduled the RAR (e.g., an indication determined from DCI format, overloading of TDRA, FDRA, MCS fields, or an explicit indication in the DCI). The WTRU may apply the waveform type indicated in msg2 for the transmission of msg5 or UL grant / transmission following successful completion of the RA (e.g., as shown in FIG. 18). The WTRU may continue to use the same waveform type in msg5 that was used in msg3 if the contention resolution is successful.

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

[0177] An example of waveform selection for transmission of msg3 may be provided. The WTRU may perform a dynamic decision of which waveform type to use for a msg3 / msg5 transmission, possibly if a capability (e.g., only a capability) of multiple waveform support was indicated to the network part in msg1, msgA, or a previous PUSCH transmission.

[0178] The WTRU may decide to switch waveforms from the first waveform type (e.g., a default waveform type, which may be an OFDM waveform type) for msg3 transmission if at least one or more of the following conditions are met: If, based on the channel condition, the RSRP of the SSB is below a pre-configured threshold, If, based on the parameters signaled for the UL grant, the WTRU may determine which waveform type to use for the transmission of msg3 from a value signaled for the UL grant assignment, a value signaled for the MCS, or depending on other parameters associated with the UL grant, If, assuming OFDM is the first waveform type (e.g., a default waveform), the WTRU may decide to switch to a DFT-s-OFDM waveform type for msg3 transmission if the number of resources (e.g., resource elements, RBs) is less than a pre-configured threshold, If the MCS configured for the grant is less than π / 2If the WTRU determines to switch to the DFT-s-OFDM waveform type for msg3 transmission if the BPSK or any MCS applicable to (e.g., applicable only to) the DFT-s-OFDM waveform type, if the WTRU determines to switch to the DFT-s-OFDM waveform type for msg3 transmission if the accumulated TPC or corresponding power change for the TPC commands is below a pre-configured threshold, if the signaled number of msg3 repetitions is greater than 1 or greater than a configured or pre-defined number, if the WTRU may transmit msg3 with a different (e.g., non-default) waveform type based on the signaled number of msg3 repetitions for msg3, Based on the signaled TA value, from a linked value or if a specific pre-configured value is signaled, the WTRU may determine which waveform type to use for the transmission of msg3; if the TA value is higher than a threshold, the WTRU may decide to use the DFT-s-OFDM waveform type because, based on the TA value, the WTRU may determine that it is located relatively far 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 higher than a pre-configured threshold, the WTRU may decide to switch to the DFT-s-OFDM waveform type for the transmission of msg3.

[0179] An example of signaling of a waveform type in msg4 may be provided. The WTRU may receive an indication to switch waveforms in a second message (e.g., msg4 or msgB) from the cell (e.g., as shown in FIG. 18). If the WTRU indicates a request to switch waveforms in msg3 or msgA, the WTRU may receive an indication from the network to switch waveform types (e.g., from a CP-OFDM waveform type to a DFT-s-OFDM waveform type) for an UL transmission (e.g., a subsequent UL transmission) in a second message (e.g., msg4 or msgB). The WTRU may receive an indication in the payload of the contention resolution MAC sub-PDU or the waveform portion of the msgB payload. The WTRU may apply the indicated waveform type (e.g., DFT-s-OFDM waveform type) for the transmission of a third message (e.g., msg5 or UL grant / transmission) (e.g., following successful completion of the RA) (e.g., as shown in FIG. 18). The WTRU may receive the msgB TB or an instruction portion of msgB on which modulation to use for PUCCH transmissions for HARQ feedback for a UL transmission (e.g., a subsequent UL transmission). The WTRU may be pre-configured to return two or more PHRs in msg3 or msg5 if at least one of the conditions (e.g., described above) for transmitting a PHR is satisfied. The WTRU may be configured to transmit the PHR in a third message via a PUSCH transmission (e.g., msg5) so that the network can determine which waveform type to configure for a subsequent PUSCH transmission.

[0180] Examples of fallback behavior may be provided: If the WTRU is not successful in the initial access procedure in a preconfigured number of attempts, which may be broadcast in a SIB or dedicated signaling, the WTRU may determine at least one of the following: If the WTRU is not successful in completing the 4-step RACH procedure, the WTRU may fall back to PRACH transmission on preconfigured PRACH resources (e.g., RACH opportunities for coverage extension, indicating a request for msg3 repetition), if available (the WTRU may select a preamble sequence from a preconfigured pool of preamble sequences), or if the WTRU is not successful in completing the 2-step RACH, the WTRU may fall back to PRACH transmission on preconfigured RACH opportunities in the 4-step RACH procedure (e.g., RACH opportunities for coverage extension, indicating a request for msg3 repetition).

[0181] FIG. 18 illustrates an example of dynamic waveform switching. If a WTRU receives a first message (e.g., via an RRC or SIB transmission) from a plurality of cells (e.g., from a first cell of the plurality of cells) and if the WTRU determines (e.g., the first message indicates) that a cell (e.g., a second cell of the neighboring cells) supports dynamic waveform switching, the WTRU may decide to perform initial access by prioritizing a cell (e.g., the second cell) that supports dynamic waveform switching over a cell (e.g., a third cell) that does not support dynamic waveform switching (e.g., if the WTRU is capable of dynamically switching waveforms), and in an example, the prioritization may be further based on a measurement (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 decide a RACH procedure to use. If the RSRP of SSB is above a threshold, the WTRU may decide to initiate a two-step RACH. The WTRU may determine the first waveform type (e.g., a default waveform type (e.g., OFDM waveform type or CP-OFDM waveform type)), the grant offset (e.g., number of slots), and the number of attempts allowed (N) from the SIB. The WTRU may transmit 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) to use for transmitting the third message. If the WTRU receives a fallback RAR, the WTRU may determine transmission parameters if (e.g., after) receiving the fallback RAR (e.g., if the fallback RAR includes grant information). The WTRU may determine to transmit the second waveform type (e.g., a DFT-s-OFDM waveform type) in the third message with a grant that is offset from the grant indicated in the fallback RAR. The WTRU may decide to fall back to 4-step RACH and may use the RACH partition for coverage extension for msg1 (preamble transmission) (eg, after N RACH failures).If the WTRU does not receive the fallback RAR, the WTRU may proceed to the RRC_CONNECTION procedure (eg, connection successfully established). If the RSRP of the SSB is not above the threshold, the WTRU may initiate a 4-step RACH.

[0182] Examples of transmission over multiple slots and waveform switching are provided herein. Prioritization between coverage extension techniques may be provided. The WTRU may be configured with multiple coverage extension techniques (e.g., transmission of TB over multiple slots, PUSCH repetition, and waveform switching, etc.). The WTRU may be configured with multiple configured grants for UL transmission. The multiple configured grants for UL transmission may include a first uplink grant configured with an OFDM waveform type over a single slot, a second uplink grant configured with a DFT-s-OFDM waveform type over a single slot, a third uplink grant configured with an OFDM waveform type over multiple slots (e.g., TB over multiple slots (TBoMS)), and a fourth UL grant configured with a DFT-s-OFDM waveform type over multiple 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 extension techniques by selecting a configured grant for UL transmission that corresponds to a particular coverage extension technique. The WTRU may determine which coverage extension technique to use based on one or more of the following: one or more gNB indications of allowed waveform type to use for UL transmission, a gNB indication to enable a waveform switch, the number of UL slots in a configured duration being below a configured threshold, the number of consecutive UL slots being above a configured threshold, whether joint channel estimation (JCE) is enabled, the number of slots allocated for TBoMS, the configured number of slots for PUSCH repetitions, the configured maximum power for the waveform and the measured path loss of the reference signal, the waiting time required for UL transmission, or frequency hopping configuration.

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

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

[0185] If the number of UL slots within the configured duration falls below the configured threshold, then based on the received TDD configuration (dynamic or semi-static TDD configuration), the WTRU determines whether the number of UL slots within X ms falls below the configured threshold X th The WTRU may (eg, may then) use DFT-s-OFDM on a single slot instead of TBoMS transmission with OFDM.

[0186] If the number of consecutive UL slots is above a configured threshold, based on the received TDD configuration (dynamic or semi-static TDD configuration), the WTRU may determine that the number of consecutive UL slots is below a configured threshold, and the WTRU may (e.g., may then) use TBoMS transmission with OFDM instead of DFT-s-OFDM on a single slot.

[0187] Regarding whether joint channel estimation (JCE) is enabled or not, the WTRU may prefer to use the same waveform if JCE is enabled and used for transmission, and may prefer to switch waveforms if JCE is not enabled.

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

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

[0190] For the latency required for UL transmission, the WTRU may choose to transmit on a single slot with waveform switching rather than using TBoMS transmission due to the low latency requirement.

[0191] For frequency hopping configuration, the WTRU may select a grant with frequency hopping configured over multiple slots rather than using waveform switching.

[0192] Examples of adaptation of transmissions across multiple slots upon (eg, following) receipt of a waveform switch are provided herein.

[0193] The WTRU may receive a waveform switching indication from the gNB when (e.g., while) transmitting a TB. Such a transmission may be a transport block or a transport block repetition (PUSCH repetition) across multiple slots (TBoMS). In an embodiment, the WTRU may receive a waveform switching indication / command from the gNB during transmission of a TBoMS or PUSCH repetition using a group-common DCI indicating waveform switching for UL transmission. In an embodiment, the WTRU may be configured to switch waveform types during transmission of a TBoMS / PUSCH repetition. In an embodiment, the WTRU may be configured to change the waveform type in the next slot of a TBoMS / PUSCH repetition if (e.g., after) receiving an indication to change the waveform from the gNB. The WTRU may be configured to change the waveform type N slots after receiving an indication to change the waveform type from the gNB. The WTRU may be configured to drop an ongoing transmission and use a different grant (e.g., an alternate grant). In an embodiment, the WTRU may be configured with an alternate grant that can be used if an ongoing transmission is dropped due to waveform switching. In an embodiment, the WTRU may be configured to continue transmitting using the already indicated waveform without changing the waveform type or stopping transmission.

[0194] The WTRU may be configured with an MCS table usable for multiple waveform types (e.g., the same table can be used for CP-OFDM and DFT-s-OFDM). In an embodiment, 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 UL grant and the DCI indicates an MCS index corresponding to both CP-OFDM and DFT-s-OFDM, the WTRU may anticipate (e.g., the possibility of) a waveform switch during a transmission (e.g., a TBoMS transmission).

[0195] The WTRU may stop the JCE if (eg, after) switching waveform types. In an embodiment, the WTRU may continue to run the JCE and delay the waveform switch until the start of the next JCE window.

[0196] Examples of power control adjustments when (e.g., after) receiving a waveform switching indication are provided herein. The WTRU may be configured to transmit some UL transmissions using a first waveform type and may receive an indication to switch the waveform to transmit using a second waveform type. During transmissions using the first waveform type, the WTRU may receive transmit power control (TPC) commands from the gNB. The WTRU may adjust / convert the received TPC value when (e.g., while) transmitting using the first waveform to calculate an "equivalent TPC". The "equivalent TPC" may be used to calculate the transmit power to transmit when using the second waveform type. 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 the TPC commands received when transmitting using the first waveform and the TPC commands to use when transmitting using the second waveform type. Such a mapping may be a table configured for the WTRU that depends on the configured MPR. The WTRU may be provided with an updated (e.g., new) TPC command from the gNB when a waveform switch is indicated. In an embodiment, the WTRU may receive an updated (e.g., new) TPC command in a DCI indicating a waveform switch to the WTRU.

[0197] The WTRU may be configured to keep the accumulated TPC regardless of the indicated waveform and use an updated (e.g., new) Pcmax for scaling depending on the indicated waveform. In an embodiment, the WTRU may be configured with multiple Pcmax. Each Pcmax (e.g., of the multiple Pcmax) may be 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.

[0198] Examples of waveform indications are provided herein. The waveform may be determined from the combined MAC CE and DCI. The WTRU may (e.g., initially) receive signaling such as a MAC CE indicating an operating mode and associated parameters for waveform switching. The WTRU may (e.g., further) receive a DCI for an UL transmission and may determine an applicable waveform for the transmission based on at least one field of the DCI. The interpretation of the 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., also) transmit a PUSCH from a configured grant and may determine an applicable waveform based on the MAC CE and at least one characteristic or configuration aspect of the configured grant.

[0199] In an embodiment, the MAC CE may indicate an operating mode in which the WTRU determines the waveform based on the legacy.

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

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

[0202] 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 a waveform type applied to a 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 a most recently received dynamic signaling indicating a change in waveform for a subsequent transmission (e.g., DCI or MAC CE, etc.). In the latter case, the configured grant configuration may include (e.g., may also include) a parameter set applicable to a possible waveform type (e.g., each possible waveform type). For example, the configuration may include a first and second set 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 either a waveform type (or whether transform precoding is enabled or disabled) or a value indicating "flexible" if the waveform type is configured based on dynamic signaling. In an example, the WTRU may determine that the waveform type is configured based on dynamic signaling if the configuration includes first and second sets of parameters applicable to the first and second waveform types, respectively. If the WTRU begins transmitting a transport block using the 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 and second waveform types.

[0203] Examples of DCI interpretation in the case of a DCI size that does not match the DCI size applicable to the indicated waveform are provided herein. The WTRU may decode the PDCCH assuming a DCI size that depends on the most recently received dynamic signaling, such as a DCI indicating a waveform. In an example, the WTRU may receive (e.g., initially receive) a DCI indicating a DFT-S-OFDM waveform type. The WTRU determines (e.g., after receiving or acknowledging the DCI indicating DFT-S-OFDM) that if the waveform type is a DFT-S-OFDM waveform type, the subsequent PDCCH is to be decoded assuming a DCI whose size is determined from the applicable size of the field. The WTRU may receive (e.g., subsequently 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 embodiment, the field "Precoding information and number of layers" may have a smaller size than that resulting from the PUSCH configuration when the CP-OFDM waveform type is enabled. (e.g., if the field "Precoding information and number of layers" has a smaller size than that resulting from the PUSCH configuration when the CP-OFDM waveform type is enabled), the WTRU may do at least one of the following to determine the applicable information from the DCI field: Start with the table applicable to the CP-OFDM waveform type (transform precoder disabled) and remove entries from the table until the reduced table size matches the number of values ​​that can be indicated from the field, which may be removed using a priority based on the number of layers (e.g., remove the highest number of layers first) while maintaining the same order for the remaining entries, or Use the table applicable to the DFT-S-OFDM waveform type (transform precoder enabled).

[0204] Although the above-described 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 embodiments, or may be used in various combinations with or without the other features and elements.

[0205] It will be appreciated that while the implementations described herein may take into account 3GPP-specific protocols, the implementations described herein are not limited to this scenario and may be applicable to other wireless systems. For example, while the solutions described herein take into account LTE, LTE-A, new radio (NR), or 5G-specific protocols, it will be appreciated that the solutions described herein are not limited to this scenario and may be applicable to other wireless systems.

[0206] The processes described above may be implemented in a computer program, software, and / or firmware embodied in a computer readable medium for execution by a computer and / or a processor. Examples of computer readable media include, but are not limited to, electronic signals (transmitted over 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, internal hard disks and removable disks, magneto-optical media, and / or optical media such as Compact Disc (CD)-ROM disks, and / or Digital Versatile Disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, a terminal, a base station, a Radio Network Controller (RNC), and / or any host computer.

Claims

1. 1. A wireless transmit / receive unit (WTRU), comprising: receiving a first message, the first message indicating that a cell supports dynamic waveform switching; selecting the cell based at least on the cell's support of dynamic waveform switching; transmitting a preamble to the cell, the preamble transmission indicating an ability of the WTRU to support dynamic waveform switching; receiving a second message from the cell, the second message indicating a waveform type to use to transmit a third message; and transmitting the third message using the waveform type.

2. 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 used for the preamble transmission.

3. The WTRU of claim 1 , wherein the selection of the cell is further based on a measurement 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 cell is a second cell, the waveform type is a second waveform type, and the processor: The WTRU of claim 1 , further configured to communicate with a first cell using a first waveform type prior to receiving the first message.

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 transmitted over 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 first message is received from a first cell; The WTRU of claim 1 , wherein the cell is a second cell, the second cell being one of a number of neighboring cells.

10. one of the number of neighboring cells is a third cell that does not support dynamic waveform switching; a respective measurement value for each of said number of neighboring cells is below a threshold value; The WTRU of claim 9 , wherein the selection of the second cell is further based on the third cell not supporting dynamic waveform switching.

11. 1. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: receiving a first message, the first message indicating that a cell supports dynamic waveform switching; selecting the cell based at least on the cell's support of dynamic waveform switching; transmitting a preamble to the cell, the preamble transmission indicating an ability of the WTRU to support dynamic waveform switching; receiving a second message from the cell, the second message indicating a waveform type to use to transmit a third message; transmitting the third message using the waveform type.

12. 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 transmit opportunity used for the preamble transmission.

13. The method of claim 11 , wherein the selection of the cell is further based on a measurement 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 cell is a second cell and the waveform type is a second waveform type; 12. The method of claim 11, further comprising communicating with a first cell using a first waveform type prior to receiving the first message.

Images